The Internet of Things (IoT) promises open communication relationships between completely different systems and applications across provider and manufacturer boundaries in order to create added value for users. However, there are still countless technical hurdles for which we need practicable solutions. For example, a Smart Connected Sensor (SCS), as presented in issue 4/2016 of Computer&AUTOMATION, must be able to connect to virtually any IoT service platform on the internet. The SCS should also enable a local application to access the sensor data directly on site, for example with the help of an integrated OPC UA server. As an IoT front end, the SCS therefore requires a particularly flexible configuration interface that takes into account the special needs of the IoT world. It should meet the following requirements:

Prefabricated function blocks are placed in the editor according to the principle of data flow programming, configured with the appropriate inputs and wired with mouse clicks.

© SSV Software Systems

• SCS-IoT connection is preconfigured in an easily accessible abstraction level for the user: Under no circumstances should the IoT connection be 'permanently' isolated in the SCS firmware code and only be able to be changed by a firmware update. Such an SCS feature would be problematic from an IT security perspective alone. In a future Industry 4.0 SCS, for example, a public key infrastructure (PKI) could be used. The digital certificate must then be interchangeable via the abstraction level.
• Reload and configure the protocol and data interface code and execute the driver code: If the SCS is to be connected to another cloud as an IoT data front end, for example, and MQTT is now to be used for sensor data transmission instead of the REST-based communication previously used, a new 'IoT driver' must first be installed. The access data of the respective IoT service platform must be able to be set. The final result should be executed as a component in a runtime environment - preferably event-driven. This requirement can also be used to implement future IT security requirements.
• Create test and diagnostic options for the interface connection between the IoT front end and back end: A practical debug interface is required in order to be able to check the measured values sent from the sensor as an IoT data frontend to the backend and the responses received as a result during commissioning or in the event of a fault on site at the SCS.
• Align data formats between backend and frontend: If, for example, a different data format is required for sensor data transmission, the corresponding data structure must be able to be changed by the SCS user and adapted to requirements.
• Ease of use and long-term availability: Intuitive operation is essential in order to be able to make the necessary adjustments and changes without special programming knowledge, seminars and manual studies. Even after ten years, it must still be possible to connect the SCS to another IoT platform. No special software, such as apps or PC software requiring a license, should therefore be used.
• Duplicatable and largely device-independent configuration data: The respective configuration settings of an SCS must be easy to transfer to other SCSs in order to duplicate a tested IoT platform connection to other IoT devices. Furthermore, the IoT connection should be as independent as possible of a specific SCS hardware architecture so that complex configuration data such as protocol and data interface code or data conversions can be transferred to successor products even after several years. IT security requirements must be observed.

One tool that can be used to implement these requirements and that can be integrated directly into an SCS is the open source software 'Node-RED'. This relatively new tool was developed by IBM and released in 2013. Although Node-RED is still in its infancy, the developer, supporter and user community is growing at a rapid pace.

What is Node-RED?

Node-RED consists of an event-driven JavaScript runtime environment, an integrated web server and a web-based user interface that can be used with any modern HTML5-compliant browser. The software isolates almost the entire complexity of the interface connection between the IoT device and the IoT platform in ready-made graphical function blocks (so-called nodes). In the web interface, these are taken as individual graphic objects by copying and pasting from a supplied construction kit, placed on a workspace and connected (wired) together. This creates a Node-RED flow.

The illustration shows the simplest possible practical example with one input node and one output node in the editor workspace of the web interface. The input node on the left-hand side forms an MQTT subscriber that is connected to a broker via the Internet in order to receive messages (MQTT topics) and forward them to the output node on the right-hand side. A debug node is used as the output node. This outputs the messages received from the input node together with a timestamp and other information in a special window of the web interface. If, for example, you want to change the MQTT topic data format before passing it on to the output node, an additional function node from the function pool on the left-hand side of the web interface is inserted between the two nodes and the wiring is adjusted accordingly. JavaScript program code for data conversions of any kind and other tasks can then be stored in this node.

In addition to placing and wiring the function blocks, it is important to configure the individual nodes in a flow. To do this, double-click on the corresponding graphic object in the Node-RED flow editor to open a dialog window. The required data - for example the address of an MQTT broker or the JavaScript program code - is then entered in this window.

Data flow programming as a basis

The Node-RED methodology uses the concept of data flow programming (flow-based programming = FBP), which is widespread in the IT world. FBP is based on graphical modules with outputs for sending data (data sources), data receiver modules with inputs (data sinks) and modules with inputs and outputs that receive data on one side and send modified data on the other. The inputs and outputs of the modules are connected to form a network. The data of an application then flows via these predefined connections.

A Node-RED implementation is based on the very popular Java Script runtime environment 'Node.js', which is intended for the development and operation of server-side network applications. Node.js can be installed and used on embedded systems as well as on PCs. Node-RED is therefore platform-independent and can be used on intelligent sensors, IoT edge gateways, PCs and other automation modules.

The function blocks included in a Node-RED installation cover numerous IoT connections, for example via HTTP/REST and MQTT. Websocket functions, e-mail dispatch and Twitter connections are also available - additional modules can be installed later. An SCS provider can therefore provide its customers with special extension modules that can be installed relatively easily and expand the range of functions of the input, output and function nodes in the flow editor. This allows, for example, a complete OPC UA server to be isolated in a Node-RED function block and implemented in a flow by the user via copy & paste.

The flow created in a Node-RED editor can be exported as a JSON object, archived and imported into other IoT devices using special functions of the web interface. This means that all configuration data and other parameters of an IoT interface connection can be duplicated as often as required.

Although Node-RED is an expert solution, its simple structure means that it can be operated via a web browser with relatively little prior knowledge. Thanks to the expandability of the function pool and the flow import option, an IoT device provider can provide its customers with complex configurations that can be easily adapted and used.

Author:
Klaus-Dieter Walter is a member of the management board at SSV Software Systems.