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 an edge device—which is a small device cable of running a 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. 

Like the edge device(hardware), the equal importance is there for the software stack. Without a proper edge software framework, it is difficult to implement a proper I4.0 or for that matter any IOT use cases. The edge software 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. These devices connect around 2,000 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 to go with—some are opensource and some are COTS solutions. Some of the opensource edge software frameworks are listed below.

• Azure IOT edge 
• AWS Greengrass 
• Edgexfoundry 

There are also COTS edge software available, and based on the requirements we can decide whether or not to use them. For this use case, the opensource frameworks were meeting our requirements and all features required for an edge stack was available in those opensource solutions.

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

The following diagram shows some of the critical components of an edge software stack:

The above diagram shows some of the edge software components found 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.

1. Edge Runtime is the core of the software 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 have 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-premises) 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 can store data at the edge for a limited period. 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 also call this Databus. This is an architectural style I mainly derived from the Microservice architecture. The edge SW components we deploy must 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 must be developed in one technology stack, so when we have apps with different technology from different developers, we need a 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 also the edge apps )— 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, but it has certain limitations.

Edge Device Choices: We have many vendors which supply edge devices based on the customer need

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 is 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 and 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 software 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 software platforms are available. The intent of this article is to have the know-how of an edge stack.