Industrial IoT gateways are small servers at the edges of corporate networks that link the “Wild West” of IoT devices with the civilized world of IT. Because gateways connect directly with enterprise systems, you might expect them to be off-the-shelf, plug-and-play products. Today, this is not the case. Most gateways are customized, one-off systems that don’t always play nicely with IT infrastructure. This situation is impeding the growth of industrial IoT. Fortunately, new software and hardware are available that transform industrial gateways from tailor-made gadgets into managed, IT-friendly systems.

Customization is necessary because almost all industrial IoT installations require tailored gateway software that fits specific devices and applications. Customized gateways are not purchased, programmed, configured, deployed, managed or secured like other enterprise servers. Software tailoring also slows down IoT solution development and increases costs at every stage of the product lifecycle. In other words, it’s “one gateway per customer application” rather than “one gateway for all applications.”

Service-oriented edge software frameworks such as EdgeX and Pelion Edge are now available that download installation-specific capabilities onto each gateway without modifying the underlying software environment. Conceptually, it’s like adding apps to a phone. This is a game-changer because enterprises can significantly reduce IoT solution development time and cost by using the same enterprise-friendly edge server platforms across a wide variety of IoT installations–“one gateway for all applications.”

IoT solutions need gateways

Almost all industrial IoT solutions require gateways because small IoT devices like sensors and actuators cannot directly attach to IT infrastructure. Device constraints such as small physical size, extreme environmental conditions, remote locations, battery power, fast response time and low cost require fit-for-purpose IoT device platforms, protocols and networks that are quite different from mainstream IT systems. Gateways resolve this mismatch by combining these three functions:

1. Protocol translation – The principal function of a gateway is to translate the staccato dialects of IoT into the native languages of business applications.
2. Edge computing – Local applications running on gateways directly interact with attached IoT devices, thereby shortening response times, improving reliability and reducing upstream bandwidth.
3. IoT firewall – Welcome to the “Wild West,” where very few IoT devices have enterprise-grade security. Gateways insulate these vulnerable devices from enterprise assets and also from threats on the open Internet.

These gateway functions are essential for connecting, operating, and securing IoT devices within enterprise IT environments. Today, the protocol translation function is the main reason for using gateways. However, industry-standard IP protocols that do not require translation are already replacing IoT-specific protocols. Still, gateways aren’t going away. Instead, they morph into edge servers that host applications close to devices while providing IoT security services. Please refer to the appendix at the end of this blog for more about this trend.

Industrial IoT gateways need customization

Gateways have been around for over 30 years, dating back to the first “connected embedded” systems. Most industrial gateways are physically robust for installation in the real world. Inside these rugged boxes, you’ll find x86 or Arm-based server platforms designed for gateway workloads. Gateway software must be customized to support one or more IoT device protocols such as BLE, Zigbee, Thread, Z-Wave, MQTT, Modbus, BACnet, KNX and PROFINET, to name just a few. Hundreds of protocols and dialects have evolved to address the diversity of IoT devices across many vertical industries. Here in the “IoT frontier,” every device protocol needs a unique custom interface. In addition to handling diverse device protocols, gateways also need custom connectors for enterprise IoT services, both cloud and on-prem. Gateways sit in the middle between the lawless device frontier and the buttoned-down world of enterprise services.

Today, each custom gateway software configuration typically supports only a few combinations of device protocols and IoT services – often only one pair. That’s a big problem for two reasons. First, the combinatorial explosion of these protocols and services results in an enormous number of permutations. Integrators and solution developers typically address this diversity by creating custom, one-off gateway software configurations for each unique combination of devices and services. Second, custom gateway programming is done on a small scale by software teams with a combination of embedded and enterprise skills, a rare talent mix in enterprise IT shops. Slow, low-volume, complicated, expensive customization is why industrial gateways are not mass-produced, bolt-in, plug-and-play solutions. 

Service-oriented gateway frameworks solve the customization problem

One way to address the gateway customization problem is to replace monolithic gateway applications with service-oriented frameworks that deliver installation-specific functionality as plug-and-play microservices. Installed as ordinary applications with no platform or OS dependencies, these frameworks can run on just about any platform, from a Raspberry Pi to a rack-mounted server. There are many benefits to using microservice-based customization.

•  Service-oriented gateway computers are procured, deployed, secured, programmed, and managed like other mainstream IT servers.
• OEMs deliver these systems off-the-shelf with no system-level customization.
• Integrators and IT personnel add installation-specific gateway device connectors and applications via microservices (i.e., Docker).
• Developers write microservices using cloud-native software languages and tools. Embedded skills are not required.
• Microservices are deployed and managed using cloud-native orchestration frameworks (i.e., Kubernetes).
• Commonly used device and application microservices can be open-source and freely shared, reducing or eliminating customization costs.

The transition to service-oriented gateways is already underway. Standards bodies and IoT platform companies have been working on this problem for the past five years. Let’s take a look at two examples – EdgeX and Pelion Edge.

EdgeX Foundry

EdgeX Foundry is an open-source, vendor-neutral, hardware-independent, sensor and application-agnostic gateway project hosted by The Linux Foundation under the LF Edge umbrella. It’s a reference software framework that hosts plug-and-play microservices for devices, cloud IoT applications and local on-gateway applications.

EdgeX began at Dell in 2015 and was released to open source in 2017. Six releases and over seven million downloads later, adoption is still growing fast. The framework is incorporated into gateway products from Accenture, HP, Jiangxing, ThunderSoft, TIBCO and Home Edge (another LF Edge project). Dell also provides IoT solutions with EdgeX for Dell Gateway hardware.

Here’s a little more about how EdgeX works. As shown in the block diagram below, the framework consists of core services and SDKs. All gateway functions run within this framework as microservices packaged in loosely coupled containers (i.e., Docker). This flexible architecture simplifies the customization of all gateway-specific functions.

• Device services (“Southbound” interface) – Conceptually similar to hardware device drivers on a PC, there’s an IoT device service for each “Wild West” IoT protocol and network such as MODBUS, BACnet, KNX, Zigbee and MQTT. It’s easy to develop new ones using an SDK.
• Application services (“Northbound” interface) – These services communicate with the “civilized world” of IT, especially big cloud services like AWS, Azure, Google, IBM, Pelion and many others. EdgeX is cloud-agnostic, and there’s an SDK for building new northbound services.
• Management, security, supporting services – While EdgeX includes implementations of these capabilities, integrators can replace them if necessary. For instance, enterprises can use (or develop) a management service that is compatible with its standard system management platform. Likewise, developers can add higher levels of security without redesigning the whole EdgeX framework.

EdgeX is free and available now on GitHub. As adoption accelerates, a wide variety of open-source microservices for popular device networks and IoT frameworks are becoming freely available. It makes sense to build these services for one and all because there isn’t any product differentiation for a device connector or a cloud service interface.

For enterprises and integrators that don’t want to build EdgeX directly from the GitHub repository, IOTech Systems offer a commercially supported version called Edge Xpert. Jim White, the guy who wrote the original version of EdgeX while he was at Dell, brings considerable expertise to his role as CTO of IOTech Systems. Like EdgeX, Edge Xpert is hardware and OS agnostic. IOTech Systems has pre-configured “IoT-Ready” Edge Xpert solutions for Dell 3000 and 5000 industrial edge gateways.

Another option is HP’s “HP Engage Edge,” announced in August—the first off-the-shelf retail gateway product that ships with EdgeX already installed. IoT developers and integrators can now purchase enterprise-ready, service-oriented gateway platforms that host plug-and-play microservices as needed to handle the “Wild West” of little devices. These gateways are ready to install right out of the box because HP designs them for industrial environments, leverages existing enterprise server architecture, and factory-installs the EdgeX framework. Eliminating all pre-installation configurations reduces solution development costs and streamlines the supply chain. Meanwhile, it enables customers to shift development resources from “plumbing” device connectivity to ROI-generating projects. 

Pelion Edge

Arm’s Pelion Edge is a service-oriented gateway framework that is similar to EdgeX in many ways. It’s an open-source, vendor-neutral, commercially supported software suite written and maintained by Arm’s Pelion group. It is part of a much larger Pelion offering that includes a complete IoT management service, available either as a public cloud or as licensed, user-deployable, cloud-agnostic software. Now in its 4^thgeneration, this suite runs on Arm and x8- based gateways using any Linux distribution. The software uses Arm’s Platform Security Architecture as its security model. As shown in the diagram below, Pelion Edge consists of three major subsystems, plus core components:

• Edge systems management – This subsystem manage network interfaces, configuration, OS and application updates, and remote access.
• Device management – Similar to EdgeX, Pelion Edge uses a software bus architecture that allows applications running on the gateway to communicate directly with IoT devices. Implementations are available for Bluetooth, Wi-SUN, Zigbee, Z-Wave, BACnet, and Modbus. All are open-source, so it’s easy for customers to modify them or build new ones.
• Edge application management – Pelion’s cloud services enable customers to deploy Docker microservices across multiple gateways, orchestrated using standard Kubernetes APIs. Pelion Edge extends these features to enable customers to deploy legacy applications to the edge more quickly. For example, remote tunneling allows a cloud application to access a container as if it were on a local LAN.
• Core components – These components manage security, communication, configuration data, and device data.