Optimising data visualisation in the process control and IIoT environments

PLC/PAC systems have variables and tags already defined locally in these process-controlled systems. Plants that have local SCADA systems also have these tags mapped to the SCADA systems.

Some Modern process plants may also have a SQL database storing these data, especially in Water and Waste Water Treatment Plants. But this data does not get processed further than the plant, and there is an opportunity to make this data available to MES/high-level API. This data that is local to the plant can be aggregated and sent to the remote application server. In this paper, we demonstrate how some of the data from these plants can be a data source for MES/API to be translated to end-user/customer information to improve production KPI's and Customer perspective.

To provide additional data to the MES systems, it was necessary to implement a solution to provide the low-cost answer that is suitable to provide data to the MES without the need for complex hardware infrastructure to achieve this additional data. In Water or Wastewater treatment plants, these data points are sometimes more than 1200m from the nearest communication gateway or process control plant. Finding low-cost wireless technology was the clear plan but this technology needed to be adapted for the wastewater treatment environment. The wastewater environment is industrial, and as mentioned earlier, many LoRa-off-the-shelf devices offer only one analogue signal per end device. Added to this, the device does not conform to any rugged specifications like IP67 rating. The end device required to capture the data needed for the wastewater environment needs to conform to these specifications to endure extraordinary environmental challenges experienced in WWTP's.

Also, with as many as 20 additional standalone data points, GSM/LTE loggers can be a costly option. In South Africa, just the GSM data logger without sensors could retail around R15000 to R20000 each. To get this additional data to the MES would cost R400000 per plant for this option with additional monthly data cost for each of the twenty devices. With LoRa, on the other hand, it would require 20 LoRa nodes at R700 each plus one LoRa WAN Gateway of R5000, bringing the total cost of LoRa solution under R20000. Regarding the monthly data cost, the LoRa solution will have one device gateway logging data to a remote site putting the operational cost of GSM 20 times the cost of using the LoRa WAN option.

LoRa is a spread spectrum modulation technology (Orange, 2016). One of the most significant challenges in acquiring data in the environment like a wastewater treatment plant or a water treatment plant is the distance of the plants from the central control room, typically where all the SCADA is housed. There are several distributed process control plants, all relaying data to the central control centre.

Adding data points to these distributed plants utilising existing legacy process control systems can be very expensive, especially when there is no more capacity to adding these additional data points. Also, getting sensor data even when there is capacity can still be very expensive and labour-intensive because of the need to use fibre etc. In the modern era, wireless options seem to be the preferred choice. Fortunately, this is where options like LoRa can deliver on the needs of the system.

This paper presents a variation of the standard implementation of LoRa WAN. To get data to the Device gateway, it was necessary to implement a private LoRa WAN network with an MQQT bridge implemented on the LoRa WAN Gateway. The Typical LoRa WAN Implementation consists of multiple end nodes, LoRa gateway, LoRa Network server, LoRa application server. The LoRa gateway either has the legacy Semtech packet forwarder, or another popular UDP packet server is the LorIoT packet forwarder. Most of these packet forwarders have an Application server coupled to them for Visualisation purposes. The application server could be local to the Gateway or a remote location.

This research implements the LoRa end node with multiple sensors using the B-L072Z-LRWAN1 development board. The 4–20 ma was interfaced via SPI by mikroe Click board, and the 0–5V sensor was interface using the onboard ADC peripheral of the development board. All coding for these interfaces was done using the Mbed platform. There were fortunately many rapid development platform libraries that made this interfacing relatively seamless. The development process concerning interfacing of the LoRa radio module was done in a two-phase approach.

The first phase was to interface an STM32F4 discovery board to the two sensor variations mentioned above and the interface sx1276 LoRa radio module. During this 1st phase, the sensors and the LoRa radio module were connected with wire jumpers for proof of concept but were too cumbersome for actual testing.

In the 2nd phase, because we worked with radio technology, i.e. LoRa chirp spread spectrum, we wanted to limit the number of jumper connections and any factors that could negatively influence the results.

The above diagram Figure 2 illustrates the first phase of the hardware development for the LoRa End Node. The proof of concept and testing was carried out on an STM34F4 discovery board. Yongde et al. (2014) The coupling to the 4–20 mA interface was implemented using the microcontrollers SPI to read analogue values. The SX1276 LoRa radio module was also interfaced to the discovery board using SPI, whereas the 0–3.3V IOT sensor was interfaced directly to the microcontroller using its 12-bit resolution ADC interface.

Figure 2

All the coding and deploying in the 1st phase was done using the Keil μvision IDE and STM CUBEmax. This proved the concept before rolling out to the more expensive development board used in phase 2.

In the second phase, we used the B-L072Z-LRWAN1 development. This board has a built-in sx1276 LoRa radio module. Instead of interfacing the two sensor types directly to each product, as in phase one, dummy sensor data was added to the variables defined in phase one to test the multiple end nodes more robust and less robust cumbersome. The focus of the testing was to test the capability of the communication interface as well as data rates and latency. The B-L072Z-LORWAN1 board is mbed-enabled so all coding and deploying was done using the mbed rapid development platform.

There are many implementations of this LPWAN technology which also include public or private network options. Private LoRa WAN network is essentially a LoRa WAN Architecture where the LoRa WAN server and application server either is resident on the Gateway itself or the Local network. In other words, the visualisation and authentication are done local to the network and is not done via a WAN. The other differentiator separating these two variations is the LoRa WAN Server and LoRa application server implemented. The LoRa WAN server can further be made “more private” by deploying a LoRa UDP packet forwarder that is propriety and excludes the legacy option of the LoRa WAN server commonly referred to as the SEMTECH legacy packet forwarder.

The LoRa WAN gateway used for testing and proof of concept was the Robustel R3000 LoRa WAN Gateway. UDP packet forwarder installed on this Gateway was LoRa Server. LoRa packet forwarder is a program running on a LoRa gateway and interfaces to the LoRa concentrator to pull and push while interacting with the LoRa Network server, which could have a remote address or be running locally on the Gateway or the machine on the local network (Koon, 2020). The packet forwarder and LoRa WAN network server communicates with each other by a defined UDP packet forwarder. The legacy UDP packet forwarder has numerous shortcomings. It is not recommended for deployment on a large-scale network or an unreliable network, for that matter. Still, this does not apply because this implementation is local to a plant and does not function in the public domain.

Additional to this application, an MQTT bridge was installed to the Robustel gateway to parse the data from the LoRa Gateway to the COCT Device Gateway.

In this research, LoRa WAN implementation is simply 5 LoRa end node devices all 600m to 1200m away from the Robustel gateway. The LoRa WAN Implementation can be seen in Figure 3. Each of the devices for testing purposes had two analogue 4–20 mA dummy sensors interface to it (Koon, 2020).

Figure 3

Typically, it is possible to connect up to 2000 LoRa end nodes with multiple sensors transmitting to a LoRa WAN gateway. The LoRa WAN gateway is configured to have a LoRa network server and application server local to the plant and using MQTT to parse these data to the device gateway.

To receive the data acquired by the LoRa devices via the LoRa gateway, the device EUI was used as the device ID for the central device gateway for the web service. In line with parsing data to a standard gateway, we subscribed to the same format as shown in Table 2.

One of the most common types of data loggers out there is GSM/LTE loggers. They are prevalent in remote locations. These loggers are a microcontroller interfaced to a couple of digital and analogue inputs and coupled to a GSM modem via Uart or another Serial communication interface (SCI). These are usually some propriety type device parsing data via TCP or UDP using an IoT framework. So for this research and to add more context to this research, one of the data sources was the common GSM/LTE datalogger (Durkop et al., 2015). The code/firmware was also written in a similar LoRa end node, except the LTE logger transmitted data directly to the device Gateway. In contrast, the LoRa end node transmitted data First to LoRa WAN Gateway with a built-in UDP packet forwarder with other translations before transmitting to the device gateway (Artuso and Palladino, 2019).

The GSM/LTE data logger could also be implemented in very remote sites with minimal I/O requirement; this is also the most cost-effective way of adding these data points from remote locations.

The GSM logger (Figure 4) could also interface directly into the existing process control system to expose some data “tags” that the remote MES system might require. The GSM logger used in this research that was developed for this research had two hardware variations, namely: i

2 × 4 to 20 mA interfaced to GMS modem transmitting data to the remote site in a power-optimised way Azhari and Kaabi (2001).

Figure 4

The GSM logger forms two of the explicit device types that the device gateways receive data from. The data format from this data source also transmits in the prescribed COCT Gateway packet format, as seen in Table 2.

The firmware of this logger was written to parse data in the format as per CoCT packet format. This research also implemented two hardware variations of this data logger; one variation was where there was power available at the location and the other where the device was battery powered. The one that was battery operated, it was necessary to implement a circuit to boost the battery voltage to a voltage of greater than 12V to power the current loop for the 4–20 mA sensors (Azhari and Kaabi, 2001). The code written for the battery version of the hardware was also sensitive to optimise power consumption to allow the device to log data for long periods without changing batteries.

Seeing that this device was reading analogue sensor values, dead-banding was also incorporated in the code. The design made it possible to update the transmission intervals of data logged, but the default was set to 15 minutes. Data was also transmitted if the change was greater than a prescribed variation of the value last read.

Figure 5 captures the real-time raw data received by the device gateway as per CoCT packet format before it can be processed by Web API.

Figure 5

In a typical process plant environment, the architecture consists of many process control systems of PLCs, SCADA, and HMI's with a local SQL database that stores all the relevant data points of all the process control systems. These data points/tags are an essential source of data for the MES systems (Katti et al., 2018).

This is also another data source that the device gateway can receive data from. These data are aggregated data that the C# application makes available to an LTE modem from the transmission to the device gateway in the prescribed CoCT Gateway packet format. This aggregation will take place locally to the database server and will do all the heavy lifting in terms of data aggregations and queries. This aggregation will be achieved by an engine that essentially will perform all the database queries and aggregation.

The JSON Engine is merely a C# application that resides on the plant database server that is responsible for aggregating data and presenting it in a prescribed JSON format so that the device gateway can understand for use by the Web server system. The C# application will connect to the Microsoft SQL server and extract data using SQL queries. The data will appear as a virtualised hardware device, much like the GSM loggers.

Attached to this plant server is a physical hardware device accepting input data via Ethernet to submit/parse to the existing device gateway. Any updates and new data found will be timestamped and buffered for transmission immediately to the Device Gateway. Should connectivity be disrupted, the application will cache the timestamped data for transmission later.

The C# application will package the data according to the gateway packet format seen in Table 1. One of the fields of the header of the gateway packet format is a type that represents the data source type; the other field data the C# application will serialise the data is device ID will mean as specific aggregated KPI value from 0 to 255. So all data coming from the SQL data source will have a device ID of 0 to 255, which is reserved by the device gateway.

There are numerous ways of getting data from an OPC UA data source to an MES system. Still, for this research to demonstrate how OPC UA data is parsed to the Device Gateway for Visualisation To our WEB API, we will use a WAGO PLC with an EWON communication gateway. The data accessed from the WAGO PLC, which has an embedded OPC UA server, make the Tags available to the EWON communication interface, which exposes these tags using MQTT (Profanter et al., 2019). Not many PLCs presently have an embedded OPC UA server built into the process control system (Power and Kominek, 2013). Usually, any framework can be a client to this OPC UA data. Still, for this design, the data were parsed to the Gateway using EWON communication gateway where the EWON became the client, and the data were parsed to the CoCT gateway using MQTT in JSON format.

OPC Unified architecture is a connectivity framework that introduces a platform independence framework/architecture. OPC UA completely objects to orientation. OPC UA = IEC 62541. OPC UA is based on a client/server architecture that uses TCP/IP and HTTP/SOAP as the underlying frameworks (Cavalieri et al., 2017). It is important to understand that OPC UA is an architecture and not a Protocol on its own. It uses different protocols to complete its framework/architecture. In layman's terms, data are packed in a certain way, so the other side, when it sees this data-packed in this “sequence”, recognises this as OPC UA and can de-serialise this packed data according to the framework/architecture rules.

One of the key objectives is device interoperability independent of propriety protocols and API of device manufacturers. OPC UA was initially intended or had its roots in the factory automation of Large manufacturing plants within a LAN environment (Drahos et al., 2018). This protocol is quite heavy-weight in its make-up, and this is quite understandable due to its origins. The protocol has been implemented in various environments and is gaining considerable.

ground in its implementation in different environments. End devices will publish or render data to API's standard architecture that API can unpack without any datacasting. The addition of a” browseable” built-in information model includes executable services like read, write, method-call, subscribe, etc.

OPC UA essentially converts the hardware protocol of the device into a standardised device model. One of the modern evolutions of the OPC UA protocols is embedded OPC UA, which essentially means the OPC UA server is embedded in the SOC, and its tags can be exposed to any high-level client. PLC's like WAGO are presently using embedded OPC UA servers to Expose tags to high-level systems (Tel, 2012).

In the IoT space, lightweight and straightforward protocols are gaining ground, so if the requirement is to bypass complexity and move to a small footprint solution that guarantees a secure and reliable data exchange in industrial automation, you are bound to come across MQTT.

MQTT is messaging protocol, not a data communications protocol; it does not specify a particular format for the payload data. The data are determined by each client connecting. In the case of MQTT, the publisher and subscriber need to agree in the format in advance, or they will not have any clue what the payload means. MQTT is explicitly not interoperable but is used in industrial applications for lightweight data transfer.

MQTT is a lightweight protocol based on IP used by mainly IoT platforms. MQTT has PUB/SUB architecture (O. P. C. U., 2018).

Connection is always initiated by the client to the broker using port 1883 or 8883 for secure/encrypted,

The broker is usually publically accessible via the internet and acts as a communication bridge or central node/point between the different clients. There are, of course, options to install the broker locally without public access. Regarding the content of the message, MQTT does not care (Tao et al., 2014).

MQTT allows an unlimited number of clients/subscribers to listen to a published topic. It is up to the clients and broker to agree on the message format. The basic understanding of the MQTT architecture translates to the publisher publishes a topic, and whoever listens to that topic can see the message content.

Table 3 provides a snapshot comparison of the three protocols related to their applicability in different environments regarding data transfer.

Constrained Application protocol as defined by the RFC7252 standard is an open IoT standard. The protocol is completely asynchronous, which is essentially not connection orientated, making it very efficient for web applications.

COAP was designed to support the RESTFUL protocol synonymous with GET, PUT, POST, and DELETE verbs (Durkop et al., 2015).

COAP usually is associated with ports 5683 and 5684. COAP implements UDP binding and supports Uniform Resource Identifier(URI). COAP also 4byte binary header.