EdgeX Foundry

• By John D. H. Hose
• InTech

Summary

4.0 unifying architecture

By John D. H. Hose

The Linux Foundation EdgeX Foundry project is focused on creating a unifying open architecture for network edge devices to support the vision and goals of the Internet of Things (IoT), Industrial Internet of Things (IIoT), and Industry 4.0. EdgeX Foundry is a vendor-neutral, open-source software framework platform built for the edge of the network. It interacts with the physical, everyday working world of enabling devices, sensors, actuators, and other IoT end points and components to connect securely and operate efficiently. The intent is to build a common framework for IIoT edge computing. The EdgeX Foundry community encourages a rapidly growing number of IoT solution providers to work together in an ecosystem of interoperable components to reduce uncertainty, accelerate time to market, and facilitate scale.

By bringing this much needed interoperability, EdgeX Foundry makes it easier to monitor real-world sensors and actuators, send instructions to them, collect data from them, and move the data across the fog up to the cloud, where it may be stored, aggregated, analyzed, and turned into information. With EdgeX, data travels toward the cloud and laterally to other gateways, or back to devices, sensors, and actuators.

The initiative is aligned around a common goal: simplifying and standardizing the foundation for tiered edge computing architectures in the industrial IoT market while still supporting the ecosystem to provide significant value-added differentiation.

Founding members include Advanced Micro Devices (AMD), Alleantia, Analog Devices, Bayshore Networks, Beechwoods Software, Canonical, ClearBlade, CloudPlugs, Cloud of Things, Cumulocity, Davra Networks, Dell, Device Authority, Eigen Innovations, EpiSensor, FogHorn Systems, ForgeRock, Great Bay Software, IMS Evolve, IOTech, IoTium, KMC Controls, Kodaro, Linaro, MachineShop, Mobiliya, Mocana, Modius, NetFoundry, Neustar, Opto 22, relayr, RevTwo, RFMicron, Sight Machine, SoloInsight, Striim, Switch Automation, Two Bulls, V5 Systems, Vantiq, VMware, and ZingBox. Industry affiliate members include Cloud Foundry Foundation, EnOcean Alliance, Mainflux, Object Management Group, Project Haystack, and ULE Alliance.

"South side" and "north side"

EdgeX Foundry-based edge devices unify physical sensing and control devices with networks and systems.

South side: All IoT objects within the physical realm and the edge of the network that communicates directly with those devices, sensors, actuators, and other IoT objects-and collects the data from them-is known collectively as the "south side."

North side: The cloud (or enterprise system) where data is collected, stored, aggregated, analyzed, and turned into information and the part of the network that communicates with the cloud is referred to as the "north side" of the network.

The EdgeX architecture enables data to be sent "north," "south," or laterally in peer-to-peer architecture as required by applications.

EdgeX Foundry architectural tenets

EdgeX Foundry was conceived with the following tenets guiding the overall architecture:

• EdgeX Foundry must be platform agnostic with regard to:
  • Hardware
  • Operating system (e.g., Linux, Windows)
  • Distribution: It must allow the distribution of functionality through microservices at the edge, on a gateway, in the fog, on the cloud, etc.
  • Protocol and sensor
• EdgeX Foundry must be extremely flexible:
  • Any part of the platform may be upgraded, replaced, or augmented by other microservices or software components.
  • It must allow services to scale up and down based on device capability and use case.
  • It should provide "reference implementation" services but encourages best-of-breed solutions.
• EdgeX Foundry must have store and forward capability (to support disconnected/remote edge systems).
• EdgeX Foundry must support and facilitate "intelligence" moving closer to the edge in order to address:
  • Actuation latency concerns
  • Bandwidth and storage concerns
  • Remote operation concerns
• EdgeX Foundry must support brown and green device or sensor field deployments.
• EdgeX Foundry must be secure and easily managed.

Service layers

EdgeX Foundry is a collection of open-source microservices. Microservices are a new, architecture style of building systems using simple, lightweight, and loosely coupled services that can be developed and released independently of each other. Developers describe the term "loosely coupled" as a way to build code without a tight dependency on other code by developing an application as a suite of small services, each running in its own process and communicating with lightweight mechanisms. They may be written in different programming languages and use different data storage technologies.

These microservices are organized into four service layers and two underlying augmenting system services. The service layers traverse from the edge of the physical realm from the device services layer, to the edge of the information realm of the export services layer, with the core services layer at the center. The four service layers of EdgeX Foundry are:

• core services layer
• supporting services layer
• export services layer
• device services layer

The two underlying system services of EdgeX Foundry are:

• security
• system management

Core services layer

The core services (CS) layer separates the north side and south side layers at the edge. Core services include the following components:

• Core data: a persistence repository and associated management service for data collected from the south side objects.
• Command: a service that facilitates and controls actuation requests from the north side to the south side.
• Metadata: a repository and associated management service of metadata about the objects that are connected to EdgeX Foundry. It has the capability to provision new devices and pair them with their owning device services.
• Registry and configuration: provides other EdgeX Foundry microservices with information about associated services within EdgeX Foundry and micro­services configuration properties (i.e., a repository of initialization values).

---

---

Supporting services layer

The supporting services (SS) layer encompasses a wide range of microservices that provide the edge analytics and intelligence and provide service to EdgeX Foundry itself. Normal software application duties, such as logging, scheduling, and data clean up (scrubbing), are performed by microservices in the SS layer.

The rules engines and alerting and notification microservices are within the SS layer, because they operate on top of the core services layer. The local analytics capability (implemented today as a simple rules engine) is also located in this layer. At this time, the EdgeX Foundry supporting services layer includes the following microservices:

• architecture - supporting services - alerts and notifications
• architecture - supporting services - logging
• architecture - supporting services - scheduling
• architecture - supporting services - rules engine

Export services layer

EdgeX Foundry operates independently of other systems when necessary. Gateways often operate in isolated and sometimes disconnected environments and monitor and manage a collection of sensors and devices that have little or no outside monitoring or control. Therefore, EdgeX Foundry can operate and sustain itself over long periods without connection to the "north side" systems. The data and intelligence that is created at the edge should be collected often and transported to enterprise (cloud) systems. The transporting is done by the export services (ES) layer. The ES layer has a set of microservices that performs the following activities:

• enables off-gateway clients to register for data that interests them, coming from the south side objects
• informs where and when the data is to be delivered
• informs the format and shape in which that data is to be delivered

For example, the "where and when" could be sending temperature data to a REST address every hour, and the format and shape could be to supply JSON data in compressed form.

At this time, the export services layer includes the following microservices:

• architecture - export services - client registration
• architecture - export services - distribution
• export services - Google IoT core

Device services layer

The device services layer interacts with device services. Device services (DS) are the edge connectors interacting with the devices or IoT objects (the "things") that include, but are not limited to, alarm systems, heating and air conditioning systems in homes and office buildings, lights, machines in any industry, irrigation systems, drones, currently automated transit (i.e., some rail systems), currently automated factories, and appliances in homes. In the future, this may include driverless cars and trucks, traffic signals, fully automated fast food facilities, fully automated self-serve grocery stores, and devices taking medical readings from patients.

Device services may service one or a number of devices (i.e., sensor, actuator) at one time. A "device" that a DS manages could be something other than a single physical device. It could be another gateway (and all of that gateway's devices); a device manager; or a device aggregator that acts as a device, or collection of devices, to EdgeX Foundry.

The DS layer's microservices communicate with the devices, sensors, actuators, and other IoT objects through protocols native to each IoT object. The DS layer converts the data produced and communicated by the IoT object into a common EdgeX Foundry data structure, and sends that converted data into the core services layer, and to other microservices in other layers of EdgeX Foundry.

EdgeX Foundry provides a device service software developer kit (SDK) for generating the shell of a device service. It makes the creation of new device services easier and provides connector code to the core services layer. At this time, the EdgeX Foundry DS layer includes the following microservice: architecture - device services - virtual device.

Examples of device services

• A BACNet DS converts the BACNet device-supplied temperature and humidity readings into a common EdgeX Foundry object data structure.
• A DS receives and translates commands from other EdgeX Foundry services or enterprise systems and communicates those requests to the devices for actuation in a programming language that the device understands.
• A DS receives a request to turn off a Modbus PLC-controlled motor. The DS translates the generic EdgeX Foundry "shutoff" request into a Modbus serial command that the PLC-controlled motor understands for actuation.

Security elements both inside and outside of EdgeX Foundry protect the data and command of devices, sensors, and other IoT objects managed by EdgeX Foundry.

---

 

System management

System management facilities provide the installation, upgrade, start, stop, and monitoring of EdgeX Foundry microservices and BIOS firmware, operating system, and other gateway-related software. They can also support these functions from off-box, enterprise-based systems.

Ecosystems and flexibility

EdgeX Foundry enables the development of edge devices in an open architecture, multivendor, interoperable environment in the open-source technology community. This fosters an ecosystem of creative and innovative developers building the components for the realization of the IoT, IIoT, and Industry 4.0.

• Facebook
• Twitter
• Linked In