EdgeX Support Services Provide the Foundation for IIoT

Posted by Matt Newton on May 4, 2017 8:33:04 AM

edgex-foundry-logo_w_ Art.jpg

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.

Get The Edge Computing Primer
EdgeX Alerts and Notifications

IIoT Alert 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.

EdgeX_detailed (1).jpg

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.

IIoT Developer Tools From Opto 22

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

Get IoT Resources

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 leverages open source projects and code

With proper logging, users can monitor and understand what systems are doing and how services interact with each other, so that problems can be detected and fixed quickly, and performance can be improved as well.
Logging helps expedite IIoT application troubleshooting, particularly when an application is first being designed, built, and rolled out.

The EdgeX Logging microservice utilizes LOGBack, an open-source Java-based logging utility, as its underlying logging framework. It can log data to either a local file or to a MongoDB database. And the EdgeX Logging service provides a RESTful API for other microservices to request log entries.

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.

This implementation uses a Drools rules engine at its core. 

EdgeX leverages open source projects and codeDrools 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.
Subscribe to the OptoBlog

Topics: Internet of Things, IoT, PACs, API, REST API, IIoT, Industrial Internet of Things, EdgeX

Written by Matt Newton

    Subscribe to Email Updates

    Recent Posts

    Posts by Topic

    see all