1. Open Source Project Overview

Neuron is an open-source industrial Internet of Things (IIoT) edge protocol gateway software designed for modern big data technologies to leverage the power of Industry 4.0. It supports one-stop access to various industrial protocols and converts them into the standard MQTT protocol for accessing IIoT platforms.

Version 2.0 of Neuron has streamlined some non-essential features from version 1.x, focusing on the data collection and forwarding capabilities of industrial protocols, aiming to provide a more efficient and flexible one-stop protocol access and management solution for IIoT platform construction.

2. Open Source License

Licensed under LGPL-3.0

3. Interface Demonstration

4. Function Overview

Product Goals and Features

The design goal of Neuron is to focus on data collection, forwarding, and aggregation for IIoT: by converting data of various protocol types from complex industrial devices into unified standard IoT MQTT messages, it enables the interconnection of these independent devices, better integrating them into the larger IIoT system for remote direct control and information acquisition.

We hope Neuron can run on low-end embedded Linux devices as well as on larger memory Linux hosts to support a large number of connected devices and massive data points. Therefore, the design of Neuron needs to have minimal memory usage and very low CPU consumption while maintaining good scalability to meet the needs under different operating resource conditions.

The main functions and features of Neuron are as follows:

• Plug-in based southbound device drivers and northbound applications;

• Built-in lightweight web server for configuration, control, and monitoring of devices via a browser;

• Replaceable MQTT client for controlling and reading/writing devices via MQTT interface;

• Support for simultaneous connections to numerous industrial devices with different protocols;

• Highly integrated with other EMQ products, including EMQ X, NanoMQ, eKuiper (initiated by EMQ, now maintained by LF Edge Foundation);

• Support for runtime updates of device drivers in Neuron.

For a complete list of functions, please refer to the application and driver usage introduction.

For more information, please visit the official website.

5. Technical Selection

Architecture Design

Modern CPUs are mostly multi-core; even low-end ARM and Risc-V architecture CPUs used in embedded systems have multi-core chips. Therefore, we need to fully utilize these multi-core CPUs, meaning that Neuron needs to have excellent multi-core and multi-threading performance. To achieve this, we use NNG as the underlying messaging library, which is a multi-threaded IO processing and message handling asynchronous concurrency library that can fully utilize multiple CPU cores.

We adopted a star bus organizational form: there is a message routing center, which provides efficient message forwarding based on NNG. Message sending and receiving are inter-thread communications, using shared buffers and smart pointers, with no memory copying, achieving very high efficiency. Surrounding this routing center are nodes for specific functions, composed of Adapters and Plugins. These nodes can be inherent, such as the lightweight web server, or dynamically added, such as various device drivers, MQTT clients, eKuiper interfaces, etc. This design isolates the coupling between the functional modules of various device drivers and northbound applications, and uses a publish-subscribe mechanism to achieve distribution and aggregation of data flows, giving Neuron great flexibility. Users can dynamically add and remove device driver nodes based on on-site working conditions, providing good configurability. Moreover, when the hardware CPU running Neuron is powerful, multi-core, and has large memory, Neuron can support more device driver nodes, massive data points, higher data throughput, and lower response times, exhibiting good system scalability.

Neuron employs a plugin mechanism to support diverse user functional requirements; users can dynamically load different functional plugins based on application scenario needs, obtaining nodes with different functions. When a device driver has a bug that needs fixing or a new function needs upgrading, it can be resolved by dynamically updating the plugin, upgrading new functions. Each node runs independently, and when upgrading a node’s plugin, it does not affect the operation of other nodes, and Neuron does not need to restart.

The overall architecture overview of Neuron is shown in the figure below:

The bus topology and data flow distribution/aggregation of Neuron are shown in the figure below:

The hierarchical structure diagram of Neuron is shown in the figure below:

Installation

Install Dependencies

Install Required Dependencies

Compile

$ download neuron
$ cd neuron
$ mkdir build && cd build
$ cmake .. && make

Quick Start

$ cd build
$ ./neuron

Unit Testing

Run all unit tests

$ cd build
$ ctest --output-on-failure

Functional Testing

Run all functional tests

mosquitto -v &&
pip3 install -r ft/requirements.txt
python3 -m robot -P ft/ --variable neuron_api:http -d ft/http_reports ft

Stress Testing

Data sets for stress testing are stored in the directoryft/data/persistence/.

You can run the following commands for stress testing

# Install dependencies
pip3 install -r ft/requirements.txt

# Test on the dataset total-10k using http interface
python3 -m robot -P ft/ --variable neuron_api:http --variable dataset:total-10k -d ft/http-total-10k ft/pressure.test
# Test on the dataset total-50k using http interface
python3 -m robot -P ft/ --variable neuron_api:http --variable dataset:total-50k -d ft/http-total-50k ft/pressure.test

# If using mqtt interface, an MQTT server is required, this example uses mosquitto
mosquitto -v &&

# Test on the dataset simple-1k using mqtt interface
python3 -m robot -P ft/ --variable neuron_api:mqtt --variable dataset:simple-1k -d ft/mqtt-simple-1k ft/pressure.test

6. Source Code Location

Visit Fei Open Source: https://code.exmay.com/