In our last post we covered how Core Services in the new EdgeX project from the Linux Foundation help engineers quickly build edge computing and IIoT applications. Core Services are the microservices EdgeX provides to convert physical electrical signals from industrial devices into digital information.

In this post, we’ll focus on how EdgeX makes digital data from industrial assets available to higher-level computing systems like predictive analytics and machine learning.

But before the data is made available to those systems, EdgeX uses what it calls Supporting Microservices to do some pretty high-tech stuff to package the data and make it easily accessible.

Supporting microservices encompass a wide range of processes and tasks that keep EdgeX running, while also providing analytics and intelligence for edge computing applications.

Normal software application duties such as logging, scheduling, service registration, and data cleanup (scrubbing) are facilitated by microservices at this layer. Additionally, the Rules Engine and Alerts/Notifications microservices are logically grouped within this layer of EdgeX and operate on top of the EdgeX Core Services.

EdgeX Alerts and Notifications

Sometimes humans or other systems need to be notified about a status or situation. Data from our industrial assets coming from a node running EdgeX or another microservice on the node may point out a problem or opportunity.

When that happens, the Alerts and Notifications microservice provides the means to deliver that information. 

Here are a couple of examples of Alerts & Notifications that other services might need to send:

• Sensor data outside of certain parameters (usually detected by the Rules Engine service)
• System or service malfunctions (usually detected by system management services)

Alerts and notifications are essentially the same thing in EdgeX. Both are system messages indicating something has happened and may need attention on the part of some administrator or operator. But alerts imply a type of notification message that is more critical—possibly requiring immediate action.

You might compare Alerts & Notifications on EdgeX to alarming on a traditional HMI.

The above image shows how Alerts & Notifications run and function on EdgeX at a high level. APIs are provided for microservices, local applications, and remote applications to use. These APIs could be in REST, AMQP, MQTT, or any standard application protocols.

In the current version of Alerts & Notifications, only the RESTful interface is provided (there’s that RESTful API stuff again).

The notification receiver could be a user or an application system in the cloud or in a server room or local data center.

When a user or application subscribes to the Alerts & Notifications microservice, the subscriber then receives notifications via defined receiving channels when events occur.

The receiving channels include SMS message, email, REST callback, AMQP, MQTT, and so on. In the first version of Alerts & Notifications, only email and REST callback channels are provided.

EdgeX Logging

Logging at the network edge also plays an essential role for all modern software applications, including EdgeX.

EdgeX Rules Engine

The Rules Engine microservice monitors incoming sensor and device data to make sure readings are within target ranges, and it triggers immediate device actuation. The engine provides "intelligence" at or near the edge for faster response times.

Drools is an open-source rules engine provided by the JBoss community.

It is anticipated that this microservice will be replaced or augmented by many other edge analytic capabilities provided by third parties, as the EdgeX project is more widely developed and adopted.

The Rules Engine microservice comes with a RESTful API that allows new rules to be added and removed. New rules, defined in JSON, can be dynamically added to the Rules Engine (via REST POST). The JSON data provided is translated into Drools Rules files (.drl files) under the covers by the microservice.

So that’s a bit more info about how EdgeX operates behind the scenes to help build and deliver edge computing applications.

Sign up for the Opto 22 blog to get the next part, where we’ll dive into how data is delivered to cloud-based applications.