An overview of IIOT Edge Software Stack

In the era of IOT and IIOT(Industrial Internet of Things) there is a growing demand to deploy solutions at the edge and preferably on a edge device, which is a small device cable of running an lite OS and has enough computing power that is required for an edge computing device.

There are many vendors which provide different set of edge devices based on the customer need and use cases to be implemented. We will discuss about the edge device in another article.

Like the edge device(hardware) the equal importance is there for the software stack. Without a proper edge sw framework it is difficult to implement a proper I4.0 or for that matter any IOT use cases. The edge sw stack has an important role to play in the IIOT use case implementation.

Sometime back I was working for such an edge framework development for one of the customers where the need was to deploy nearly 300 edge devices which shall connect around two thousand machines on the plant shopfloor for various IIOT use cases implementation like predictive maintenance, real time KPI monitoring, alerts and notifications for critical machine parameters, data visualization etc.

There are many choices for us to go with, some are opensource and some COTS solutions. Some of the opensource edge SW frameworks which we explored are listed below.

• Azure IOT edge (https://learn.microsoft.com/en-us/azure/iot-edge/?view=iotedge-1.4)
• AWS Greengrass (https://aws.amazon.com/greengrass/)
• edgexfoundry (https://www.edgexfoundry.org/)

There are also COTS edge sw available and based on the requirements we can decide to use them, but for our use case the opensource frameworks were meeting our requirements. I will say almost all features required for a edge stack was available in those opensource solutions.

But for our requirement we wanted to built a custom edge sw stack with full control being with us and after going through all those available opensource frameworks we understood it is not a difficult task to develop one of our own.

In the following diagram we can see some of the critical components of an edge sw stack.

In the above diagram we see some of the edge sw components you will find in many frameworks as common. But there will be additional components based on the specific requirements. For example for an analytics or machine learning use case we may need to have a ML framework, ML Models, Rule Engines, Command and Control modules etc.

Lets have a look at the components and its features.

1. Edge Runtime is the core of the sw stack which basically provides the functionality to deploy, manage and smooth running of other components and custom apps. In my case it was a service running in the background and was exposing various REST APIs through which other apps are deployed and managed. It also provides the logging, monitoring and device health monitoring APIs, which can be consumes by the visualization apps to show the device status, health parameters etc. The run time can be developed using programming languages like Java, C++ or C# dot net framework.
2. Device connectors, these are the apps which are responsible to communicate to the controllers, PLC, IOT sensor devices etc. The connectors has the capability to communicate over ethernet, Serial communication(RS232), BLE etc. The connectors main responsibility is to communicate with the devices and collect the required data tags. Which then can be provided to other apps for consumption. The device connectors implement various industrial protocols like Modbus, Ethernet, Melsec, OPCUA, S7 etc.
3. Edge Management, this is another very critical component and provides the capability to manage the device remotely, It exposes certain REST APIs which provides the features like SW update, configuration management, remote controlling the device(Device On/Off, Reboot etc.) It periodically communicates over HTTPS channel with the server application(Hosted on cloud or on-premise) and sends and receives updates about the device status, firmware update, edge apps or any new connector updates etc.
4. Edge Apps, these are the custom developed apps for specific use cases. For example we can run a predictive maintenance app, OEE monitoring app, certain data analytics app, visualization apps(To show the real time status near the production machine) etc. These apps can be developed as web apps or background apps using any preferred programming language like NodeJS, java, python or C# and web frontend frameworks like angular.
5. Edge Historian, this component basically is a temporary data repository which is capable of storing data at the edge for a limited period of time. It is not suggested to put a high end database on an edge as the computing and memory are limited. We can use any file based DB like SQLite, lite DB kind of database to hold the data when there is a connection issue at the edge and the device is not able to send the collected data to either cloud or on-prem server. we can hold the collected data for a period and once the connectivity restores then the edge device can push the data to upper layer. In my case i have used Redis (https://redis.io/) as the temporary data storage and there is a reason behind this which we will talk next.
6. Messagebus, I call it as Databus also. This is an architectural style I mainly derived from the Microservice architecture. The edge SW components we deploy has to be loosely coupled so that the integration between different components and deploying applications from various vendors shall be easier. It is not restricted that the apps has to be developed in one technology stack, so when we have apps with different technology from different developers we need an uniform interface for communicating and exchanging data among those apps. The integration also should be easier so that we can quickly deploy apps from different vendors. So keeping these points in mind there is a Databus/Messagebus in place which facilitates high rate of data exchange with an event/message based system. Having said so the Messagebus component works on a publisher-subscriber mechanism.

The device connectors are mainly the data publishers(In some cases the edge apps also), connectors publish data to a certain topic defined for them and edge apps and other consumer apps subscribe to those topics to get the data.

In this way we achieved a highly decoupled system. I have used Redis as a message broker here as it has lower memory footprint and a very fast in-memory data store. So this can act as both a temporary data store and an event broker as well. There are other options like Eclipse Mosquitto Mqtt broker(https://mosquitto.org/) , but it has certain limitations.

We will discuss more about the Messagebus architecture in our next article.

We discussed some of the core components of an IIOT edge SW stack above and in my next article I will discuss some specific use cases related to deploying Machine learning modules , rule engine and analytics apps to an edge device.

Edge Device Choices: We have many vendors which supply edge devices based on the customer need, few of the vendors I have listed below.

• Siemens Industrial Edge Devices (https://www.siemens.com/global/en/products/automation/topic-areas/industrial-edge/industrial-edge-devices.html)
• Advantech UNO series(https://www.advantech.com/en/products/industrial-iot-edge-gateway/sub_9a0cc561-8fc2-4e22-969c-9df90a3952b5)
• Bosch Rexroth
• Dell etc.

Based on the use case and computing need we can choose any of those edge devices which all are industrial grade devices.

For example Siemens has a complete edge eco system for edge with a variety of edge device choices, edge apps it is a major player in this area.

Edge OS Options : Mainly a Linux based OS is the first choice for many of the edge devices, this is because the memory footprint of many Linux distros are less, they are easy to manage and maintain, secure and we get CLI based OS options(Without a GUI) which makes this OS more preferred.

Ubuntu Linux OS, Alpine Linux are some of the popular choices for the Edge device.

End Note:

In this article we discussed about some of the core edge SW components which are required to deploy any edge app on a device. It is not always required to develop our own custom edge SW framework as we discussed there are many opensource edge SW platforms are available. The intent of this article is to have the know how of a edge stack.

In my next article I will go little detail into a specific ML use case implementation.

Till then keep learning.