In a previous post we covered EdgeX and its important role in building a standard platform for connecting edge computing systems, like Opto 22 SNAP PAC automation controllers, to the industrial Internet of Things (IIoT).

EdgeX connects OT and IT assets together, bridging between the physical world and the digital world through a loosely coupled microservice platform architecture. These microservices provide OT and IT devices, software, and services with a platform that provides connectivity and communications methods.

The microservice platform architecture is made up of four distinct service types.

We covered the first type of EdgeX microservices, called Device Services, in our last post. As a reminder, Device Services live at the very edge of the network, where information from the physical world is first digitized for transport and consumption by other IIoT systems, using methods like RESTful APIs to automation controllers.

In this post we’ll move up to the next layer of microservices, called Core Services.

• Core Services connect Device Services to higher-level services within EdgeX that are responsible for moving data to other applications and services outside of EdgeX.
• Core services essentially bridge between the OT-level services at the edge of the network and IT-level services.

The EdgeX specification refers to OT assets and devices at the edge (such as sensors, pumps, motors, and other electrical devices) as south-side devices or things. Devices and services that live in the IT realm are referred to as north-side devices. That's probably because typically in diagrams of the IIoT, the things that produce data are at the bottom of the diagram (south), and applications that use the data are at the top (north).

So south-side devices are the generators of our big data, which we’re trying to send up north to the cloud for data processing capabilities like artificial intelligence, predictive maintenance, and machine learning.

The EdgeX Core Services are made up of microservices that handle two important tasks in IIoT applications:

First, they are responsible for describing and transporting data.

And second, they handle command and control of OT systems, based on the data gathered and analyzed by north-side IT applications and services.

These Core Services microservices are:

• Core data—a persistent repository of data collected from the south-side things
• Metadata—a repository of metadata about the things connected to EdgeX 
• Registry/Configuration—centralizes and simplifies large numbers of services
• Command—facilitates and controls actuation requests from the north side to the south side 

Let's take the last one first. The Command microservice (often called the Command and Control microservice) manages commands or actions to the devices and sensors from all the other services within EdgeX, or from external systems that need to command those devices.

It exposes the commands in a common, normalized way to help simplify communications with south-side devices. The Command microservice uses simple GET (a request for data from the device/sensor) or PUT (a request to take action or receive new settings/data from EdgeX) requests to communicate with or control south-side devices.

The Command microservice pulls its knowledge about devices & sensors from the Metadata microservice (more about that later). The Command service always relays commands or actions to the devices & sensors through the Device Service(s)—it never speaks to a device or sensor directly.

So in a way, the Command microservice acts kind of like a protocol translator: it translates command or action requests from the north side of EdgeX to the protocol-specific device or sensor (and associated Device Service) attached to the south-side of EdgeX.

This is important, because the Command microservice can provide a layer of protection around devices & sensors by not allowing unwarranted interaction through the Device Service.

As you can imagine, though, the more Command microservices that are added to EdgeX, the more complicated managing all of those services becomes. Which is where the Registry/Configuration microservice comes in.

The Registry/Configuration microservice centralizes and simplifies the growing service configuration data. And in true-to-form open-source and open-standard style, the EdgeX project uses another open-source project called Consul for centralizing configuration data.

Consul serves out information on command services through RESTful APIs. (These RESTful APIs come up more and more with the IIoT stuff, don’t they?) Consul performs a whole bunch of useful things for EdgeX, including service discovery, health checking, and key/value storing. It also provides for multiple data center support, in case your IIoT application needs to share data across multiple geographies.

The Core Data microservice provides a centralized persistence facility for data collected by devices and sensors. Device Services that collect data from south-side devices call on the Core Data service to store the device/sensor data on the device running the EdgeX platform until it can be moved north—that is, until the data can be exported to Enterprise and cloud systems.

Other services (such as scheduling or scrubbing services) within EdgeX (and potentially outside of EdgeX) access the device/sensor data stored on EdgeX only through this Core Data service. In this way, Core Data offers a degree of security and protection while the data resides on the platform running EdgeX.

Today, Core Data offers a REST API for getting data into and out of the local persistent storage. In the future, there is no reason why Core Data could not be accessible via other message protocols like MQTT, AMQP, or others.

Metadata stores and manages information about the Device Services that serve as EdgeX interfaces to the actual devices and sensors.

Remember that Device Services communicate directly with devices or sensors using their protocol, normalizing communications with the device or sensor for the rest of EdgeX.

Typically, a device service is built to communicate via a particular protocol with one or more devices and sensors that use that protocol. So, for example, there is a Modbus Device Service today that facilitates communications between all types of Modbus devices (motor controllers, proximity sensors, thermostats, power meters, and so on).

So that’s an overview of how EdgeX moves data from the OT side to the IT side of IIoT applications. In our next post, we’ll talk about how EdgeX gets the data into those higher-level IT applications and services like machine learning and predictive analytics.