Design of IIoT device to parse data directly to scada systems using LoRa physical layer

Most industrial process control systems like PLCs or PAC connect field devices like sensors and actuators via 4 to 20 mA current loops directly into the process control system.

The 4 to 20 mA is a very rugged and robust way of processing signals in the industrial environment and has been found to stand the test of time in the worst industrial conditions. Due to this, it is so much popular in the industry today. The 4 to 20 mA current loop is one of the most common sensor signalling standards (Azhari and Kaabi, 2001).

Current loops are ideal for signal transmission because of their inherent insensitivity to electrical noise. In a 4 to 20 ma current loop, all signalling current flows through all components; the same current flows even if the wire terminations are not perfect. All components in the loop drop voltage due to the signalling current flowing through them. The signalling current is not affected by these voltage drops as long as the power supply voltage is greater than the sum of the voltage drops around the loop at the maximum signalling current of 20 mA.

The operation of the 4 to 20 mA loop is straightforward: a sensor's output voltage is first converted to a proportional current, with 4 mA representing the sensor's zero-level output, and 20 mA representing the sensor's full-scale output (Surachman et al., 2011).

Converting/translating the 4 to 20 mA current loop to a voltage signal is necessary as in the IoT space most universal IoT controllers are microcontroller-based systems either capable of processing 0 to 5 V or 0 to 3.3 V by its ADC controller peripheral. This design implemented a mikroe 4 to 20 mA data interface connected to the microcontroller via the micro's serial peripheral interface (SPI). The modules that form this 4 to 20 mA interface are the INA196 current shunt monitor, MCP3201 12-bit ADC, and TPS61041 DC/DC boost converter. It receives the output current (4–20 mA) from the transmitter and converts it into a voltage (0.4–2 V). Then through the ADC sends the signal to the built-in microcontroller. This built-in microcontroller then presents these data via an SPI interface to other devices that require these data.

The first phase of the design, which implements the proof of concept where the purpose was to test the LoRa Physical layer. Dummy data were transferred from the T_X buffer of the microcontroller (STM Nucleo board) and parsed to the LoRa radio module for transmission. The received LoRa CSS signal is received by the LoRa module, parsing the data into the R_X buffer in the microcontroller (STM34f4 discovery board). These data are visualised by Putty software via UART of the microcontroller.

In phase 2 of the development, the solution is implemented on a different development board (B-L072Z running STM32L072CZY6TR MCU), including a built-in LoRa radio module (SX1276) already interfaced with the microcontroller, which made working with the development board more convenient and less cumbersome. Only the 4 to 20 mA mikroe boards needed to be interfaced to the board in case of the transmitter node and the ENC28J60 Ethernet module had to be interfaced to the receiver node.

It is imperative to understand the differences between LoRa Phy over LoRa WAN. In LoRa WAN, the end node communicates with a gateway where the end node is already registered using its device EUI, app EUI to differentiate itself from the end nodes and authenticate itself by the gateway and the app server either via OOTA or APB methods (Orange, 2016).

With LoRa Phy, the LoRa end node communicates directly on one-to-to-one basis with another end node without any authentication by either node. It is merely a LoRa payload transfer from one node to the other using the LoRa radio like RM95, SX1276, SX1278, etc.

The LoRa®-protocol defines the link layer (Shrouf et al., 2014), describing how the data are modulated into the transmitted signal. The protocol is proprietary, and not all information is freely available. Nevertheless, it is enough to know that due to the Chirp Spread Spectrum (CSS), the power consumption does not depend on the content of the data. Therefore, the energy required for transmission only depends on the so-called time to air (ToA) and the output power. Time on air refers to the time it takes a signal to travel from the transmitter to the receiver.

LoRa uses orthogonal spreading factors. This allows the network to preserve the battery life of connected end nodes by optimising an individual end node's power level and data rate. This enhances LoRa footprint in the LPWAN technology when compared to its counterparts.

An end device located close to a gateway should transmit data at a low spreading factor since very little link budget is needed. However, an end device located several miles from a gateway will need to transmit with a much higher spreading factor. This relates to LoRa adaptive features. LoRa is a long-range radio at fairly low bit rates. LoRa is also very low bandwidth and consumes very little power, which makes it ideal for battery-powered operations.

LoRa operates in the license-free band. Either 433, 868, or 915 MHz LoRa has a substantial link budget. LoRa PHY is the best-effort transmission and, analogous to UDP, doesn’t care if it gets there. LoRa WAN works on the layer on top of LoRa PHY knows that the data get there like TCP. LoRa WAN also adds encryption, whereas LoRa node/LoRa PHY has no encryption. The payload of the standardised packet is fixed to 10 bytes, being close to the proposed 12 bytes maximum of TTN. For a package sent via the LPWAN, the payload increases by at least 13 bytes to a total length of 23 bytes.

The basic LoRa packet comprises three elements: the preamble, an optional header, and payload. There are essentially two types of LoRa packet transmission: explicit header mode and implicit header mode (Koon, 2020). The functional difference between these two modes is the presence or absence of the header, which contains information regarding the payload length, the coding rate, and the presence of 16 bits’ cyclic redundancy check. In the implicit mode where the header is absent, the header information must be manually configured on both sides of the radio link.

The robustness of the physical layer can be attributed to one significant parameter of the LoRa Physical Layer, i.e., forward error correction (FEC). FEC is where redundant bits are added to the transmitted data. These redundant bits help restore the data when it gets corrupted by interference. The higher the number of error correction bits added, the easier it is to correct the data. However, by doing this, the payload inherently increases, which increases the power consumption in the LPWAN transmission, adversely affecting battery life. The physical layer/radio interface provides an excellent conduit for low-power signal communications where a low data rate, low power, and long distant range is necessary (Bäumker et al., 2019).

The interfacing of the LoRa radio module to the microcontroller is easily interfaced to the microcontroller with the SPI interface as seen in Figure 3. In the modern era, rapid development tools like the ST CUBEmax make this interface quite simple to the seasoned low-level C-programmer. There are also many open source libraries available to adapt and to use to interface the LoRa radio with the microcontroller.

Figure 3

The node-to-to-node implementation, on the other hand, does not use a gateway and data are transmitted directly to a LoRa node which is essentially a transceiver. There are many off-the-shelf implementations of the LoRa PHY, but this paper implements using the SX1276 LoRa radio module, open-source libraries for the SX1278 module are also adaptable to use with SX1276. When implementing the code for the microcontroller to set up and implement the LoRa node, careful consideration must be given to comply with the guidelines/rules of the LoRa alliance. The interface between the LoRa radio module and the microcontroller is SPI (Qfix, 2012).

On the receiving end of the LoRa device, the data would then be parsed to the SCADA via a LoRa to IP wrapper. The LoRa to IP wrapper/bridge is merely a software bridge from LoRa PHY format to IP parsing data in the required format for the SCADA device driver to handle (Qfix, 2012). The serialisation of the data from LoRa to IP would be carried out by the microcontroller, which in this case is the STM32 device interfaced with an ENC28J60 Ethernet module. The output of this Ethernet module is UDP.

The bridge is simply a high-performance device to connect two dissimilar or similar networks. In this research, our specific need is to connect/translate the format of the LoRa message to the IP format for passing the acquired data to the SCADA system. Once the data are presented to the SCADA system with the familiar format that the SCADA device driver can recognise, it can be further deserialised/translated by the SCADA device driver to be processed by the SCADA system (Tel, 2012). The device driver of the SCADA system (Ignition in this research) will connect to one or more ports with a given IP address and bring in any data as a value of a tag. In this research, we will parse the data as UDP data, and thus the device driver of the ignition SCADA system will only listen/read the data from the LoRa device via the IP/LoRa bridge shown in Figure 4.

Figure 4

Both LoRa and Ethernet have different frame formats and practice other MAC mechanisms and routing algorithms. Because we are using the LoRa node-to-to-node implementation (LoRa physical layer and not LORAWAN communication, there are no routing algorithms used as opposed to if we had to implement LORAWAN to IP bridge. The embedded code needs to take care of CRC issues, arbitration, handling of errors, etc. As well as compliance with the LoRa specifications (D. Resources and D. Features, 2015).

The LoRa transceiver receives the LoRa format data from the transmitting LoRa device node. Both the LoRa radio modules SX1276 are interfaced to the microcontroller via SPI peripheral interface (D. Resources and D. Features, 2015). The low-level drivers/libraries move data either from the microcontroller buffer to the radio module in the case of the transmitter or from the radio module to the microcontroller buffer in the case of the receiver radio module. The data that are parsed to the microcontroller radio buffer is then encapsulated/serialised into an IP/UDP format by the LoRa to IP bridge.

The queued datagrams received from the LoRa receiver are presented as an IP/UDP frame, using the LoRa device as the unique network address and a dedicated SCADA port number. This, however, is not a direct translation from LoRa data buffer to IP. Still, initially, the data get serialised from the LoRa module's buffer of the LoRa module by the microcontroller and parses this serialised data to the Tx buffer of the ENC28J60 controller. The ENC28J60 controller (Figure 5 shows the physical circuit of the Ethernet controller) is interfaced to the microcontroller via the SPI. When data are available in the buffer of the microcontroller, the microcontroller initiates (via an interrupt routine) the transfer of these data via SPI commands to the TX buffer of the ENC28J60 controller (see Figure 6). The controller then adds the MAC and PHY components to the data to implement an IP data frame. There are numerous low-level functions written to carry out this implementation and can be summarised as follows.

Initialisation of the ENC28J60.

Figure 5

Figure 6

By researching different wireless platforms to transmit process data from plants, the two technologies were realised as the most appropriate and could provide a viable solution for getting data from standalone industrial instruments back into the processing system or SCADA system for local visualisation of data or remote visualisation and/or input into MES or ERP systems.

There were other technologies researched to make an informed decision to implement an appropriate wireless solution to transmit the acquired data from the field device to the SCADA system, but two wireless technologies that stood out in terms of robustness, bandwidth was NRF24L01 and LoRa node-to-to-node communication (LoRa PHY).

After researching and physically implementing the two technologies from an embedded perspective, interfacing both the LoRa and the NRF24L01 modules to an STM24F4 development board, it was discovered:

The NRF24L01 has far better data rate and bandwidth than the LoRa node, but it is significantly poorer in SNR and link budget and the distance it can cover for end-to-end wireless data transmission.

Once received from the wireless interface, data need to be converted by the IP bridge to parse data to the SCADA device driver/dll. LoRa node has significant bandwidth restriction but can be overcome or augmented by techniques like bit encoding to optimise data transmission. LoRa node/LoRa PHY can be likened to UDP transmission and LoRa WAN to TCP. This means some form of CRC needs to be implemented to ensure proper data integrity if this is at all a priority, especially when using just LoRa Phy.

The SCADA system can also store this time series database (historian), which can then be stored in a SQL database that can be used by high-level systems like an MES/ERP system. Now that these data are part of the SCADA data architecture, the SCADA system can also parse these data to the OPC server. The OPC UA server makes these data available for remote ERP/MES clients. These data can be further converted to a lightweight protocol like message queuing telemetry transport (MQTT) in the publisher/subscriber module for a cloud-based web solution.

The primary objective of an open platform communications Unified Architecture (OPC UA) server is to expose information that clients can use to manage an underlying real-time process. OPC UA is a non-agnostic architecture that is employed for seamless data interoperability solutions. This OPC UA technology of exposing data to high-level systems is fast gaining ground.

Information or data collected describes the process's state and behaviour, and the OPC server can transfer these data in both directions. Both the wireless options will need an IP bridge to get these data back into the SCADA system, which can also be passed to the OPC Ua server for further transportation (Calderón Godoy and Pérez, 2018). At the source of the instrument, there would be a need to convert the 4 to 20 mA signal to serial data format.

The LoRa to IP bridge can also have more than one level of implementation to achieve data portability. The data acquired by the LoRa device or the NRF24L01 module needs to be parsed to the SCADA system. For seamless portability in line with 4IR specifications, it is important to parse the data in a format like IP or any other common format. Depending on the level of integration, either a low-level implementation using the ENC28J60 or the W5500 which is an alternative implementation of this converter/wrapper. Many SCADA systems do have driver libraries to parse data from other vendors using their device drivers. In this research, the Ignition SCADA system integrated the data acquired from the LoRa node.

The principle of operation of this LoRa to IP bridge is pretty straightforward. The ENC280J60 controller has an industry-standard SPI interface that can be easily interfaced with a modern microcontroller. The T_X/R_X buffer is the data that need to be parsed from the microcontroller, these are the data that need to be transformed to an IP frame.

Measurements recorded by the LoRa Node TX are partitioned into small elements—called datagrams. The field device datagrams received by the device driver of the SCADA system are used by the SCADA engine can be visualised by the SCADA system (Figure 8). This translation of the data presented to the SCADA system is translated by the device driver of the SCADA system using the custom UDP device driver.

Each datagram is forwarded to the LoRa Node R_X via a LoRa physical layer wireless link.

Figure 8

The data transfer process through the network is explained by discussing each link below.

Data transfer between 4 and 20 mA and the LoRa Tx is over an SPI peripheral of the microcontroller. A timeout is used to determine the start and end of each frame (datagram). The LoRa T_X buffer has a queue that can store up to four datagrams (to be forwarded to the LoRa Rx Node). There is no handshaking between the 4 and 20 mA interface's buffer and the LoRa Tx Node to control the flow of datagrams. The latter will be silently discarded if the interface transmits more datagrams than the LoRa TX can transmit.

The data between the LoRa Node T_X and LoRa Node R_X are transmitted using the propriety CSS. Each of the respective nodes is configured to serve either as the LoRa Transmitter module or the LoRa receiver module. The LoRa modules are the interface to the microcontroller via SPI. There are many open-source libraries for the interface between specific microcontrollers and LoRa radio modules. The libraries used in this research with STM32F4 micro and LoRa SX1278 radio module.

The queued datagrams received from the LoRa Receiver Module are encapsulated in an IP/UDP frame, using the unique network address and a dedicated (SCADA) port number. The LoRa Node Rx has the interface ENC28J60 controller that is responsible for wrapping the LoRa data format into UDP format. The encapsulated datagram is forwarded to a Gateway (listener) on the Data Switch (Packet Manger). The data switch will strip the encapsulation and check the LoRa Node R_X datagram for conformity:

Start of frame

Any inconsistency will be treated as a malformed datagram and silently discarded. The IP addresses of the LoRa radio Module(receiver) on the SCADA network are static. The data switch gateway will maintain the relationship between the LoRa Radio Module (Transmitter) identifier and the wireless network IP address.

The Data Switch (packet manager) is resident to the same network, thus a private IP range as the SCADA Server will identify each LoRa Rx device using the same address convention used by the LoRa device to identify itself. The data switch packet manager is an application running on PC buffering the data acquired from different LoRa modules. However, in this research, the buffered is a straightforward buffer for transmission delay check. This identifier is in Switch Terminology, called the Subscriber Identifier (SID). The parsing of data to the Ignition SCADA system will be made using the UDP/TCP driver.

The TCP Client installed on the Ignition Master Server will transfer the datagrams received to the Ignition server for processing and handling. The datagram which the packet manager sends will be delivered to the Ignition Master Server. The packet transport mechanism will be completely transparent to the server, i.e., as if the packet manager had been directly connected to the server. The results of the data analysis will be accessible to ignition slave stations (terminals).

Figure 9 represents the system's architecture, including the IoT devices connected via an LTE link with a remote data centre. The Ignition SCADA system can also receive MQTT data via the MQTT broker installed on the ignition SCADA in the form of the MQTT transmission module. Therefore, that any topic that the Ignition server is configured to listen to will be translated/’heard”.

Figure 9