Choosing the Middle Path for Industrial IoT Standards

The IoT has a standards problem. In home automation and the industrial IoT (IIoT), new standards are frequently created and current ones continue to evolve at a rapid pace.

This leaves IoT developers with a dilemma: How do they make sure their hardware and software are not made obsolete by shifting IoT standards?

The answer requires a flexible system, one that can accommodate changes. Traditional engineering solutions like customizable hardware or software applications work in some cases, but a more encompassing solution is middleware.

Why are middleware solutions perhaps more attractive than in the past? Answering that question requires a basic understanding of relevant IoT standards and today's technology.

The Industrial IoT (IIoT) Challenge

Like the IoT, the IIoT connects smart sensors to the Internet. Unlike the IoT, its main goal is to capture vital information so business can make better mission-critical decisions. Where the IoT focuses on things, the IIoT really deals with how those things communicate with one another and the data they create. This focus is why interoperability standards are so important.

Earlier versions of the industrial IoT dealt with Machine-to-Machine (M2M) systems that tended to silo data with proprietary and industry-specific standards. For the industrial IoT to work, standards must evolve to allow open access and interoperability to all required data.

Interoperability and Data Drive Standards

To standardize data sharing from varying sensors across differing production line machines, several organizations are working together on interoperability specifications. These groups include the Organization for Machine Automation and Control (OMAC), OPC Foundation (PLC-specific protocols such as Modbus, Profibus, etc.), and PLCopen. Such specifications will allow their existing automation standards to share IIoT information.

The recently formed Open Connectivity Foundation (OCF) arose from the earlier Open Interconnect Consortium. The mission of the OCF is simply to create a single, open IoT interoperability specification. Early results include a common connectivity framework for embedded developers for device discovery, a common interaction and data model, and a robust security framework while abstracting away the physical connectivity hardware (and related protocols).

Other groups, like the Industrial Internet Consortium (IIC), focus on connectivity technologies. The IIC's framework consists of three-tier architecture patterns where each tier plays a specific role in processing the data flows and control flows. They are connected by three networks, as shown in Figure 1. In this framework, the middleware portion would be contained mainly in the Platform Tier.

Another connectivity standard that overlaps into several IoT segments is Thread. It is a networking protocol for IoT "smart" devices to communicate on a local wireless mesh network. When paired with ZigBee 3.0 and other application layer protocols, Thread helps establish secure, distributed, short-range RF networks.

With so many existing connectivity standards from the earlier M2M world, many companies and organizations dominant in that former space are evolving their standards to the new realities of the industrial IoT. Examples include the existing Modbus protocols, the HART Communication protocol standards, and the International Society of Automation (ISA) standards.

Middleware For Flexibility

Middleware is software that provides services to applications beyond those provided by a device's embedded operating system. Some consider middleware to include all software between the device and the application, but most see it as the layer above the network. The middleware acts as an abstraction layer, making it easier for software developers to implement communications and thus focus exclusively on developing their application.

As such, middleware helps IoT developers by acting as the software bond that joins different standards and heterogeneous devices together. For example, middleware provides an API for physical (radio) layer communications as well as required services to the applications – two major platform areas for which the software developer need not worry, thanks to middleware.

Machine-to-Machine Overlap

Many existing machine-to-machine (M2M) communications overlap with home automation applications, e.g., a thermostat networking with windows and doors to maximize temperatures. A number of existing protocols are used by devices to commutate sensor or related data, including MQTT, AMQP, HTTP, etc. The Open Mobile Alliance (OMA) LightweightM2M (LWM2M) can be used in many scenarios as an alternative to some of these protocols.

LWM2M provides remote device management protocol designed for sensor networks and the machine-to-machine (M2M) environment. Device management deals with all kinds of device issues, from access control, to changing the parameters of a device to software updates and bug fixing.

Hardware-Software Shortcomings

Most of the above-mentioned applications and platforms are considered middleware for the IoT – Google Weave, Apple Homekit, and OCF IoTivity. Each has an API framework to enable communications and interoperability among smart home devices.

Middleware is not the only way to deal with evolving standards, but it may be the most expedient. In the past, software-configurable hardware devices known as Field Programmable Gate Arrays (FPGAs) and even software applications have been used to update devices to accommodate changes in standards.

The shortcomings with these approaches is that they require device manufacturers to spend considerable engineering effort to incorporate new standards and protocols, from reprogramming FPGAs (sometimes manually) to writing new software stacks and applications, notes Sushmita Sharma, head of marketing at Altiux Innovations.

"In contrast, middleware solutions can incorporate multiple standards, hiding their complexities and providing unified APIs for application development," explains Sharma. That way, if OEMs need to move to a different standard, they don't need to incorporate that new standard. Instead, it will be part of the middleware package or easily pluggable via unified APIs – saving them time and cost of new development.

Benefits of the Middle Way

One example of IoT middleware framework is provided by Altiux. This package is integrated with Intel^® hardware platforms based on Intel^® Quark^™ microcontrollers, Intel Atom^® processors, and Intel^® Core^™ processors. It addresses the challenge of technology obsolescence by enabling IoT device and gateway OEMs to future-proof investments. The abstraction framework provides plugins for various evolving standards such as OCF, OMA LWM2M, Apple Homekit, etc., and provides a unified API to developers writing applications.

The middleware benefit means that device OEMs can migrate from one communication standard to the other without any changes in application layer software. Similarly, gateway manufacturers can ensure they enable interoperability among the heterogeneous devices from differing standards without risking technology obsolescence.

Conclusion

The industrial IoT is still a relatively new set of technologies built on older M2M systems. As such, there is an abundance of existing, evolving standards and newer consortium-based ones. This creates a problem for developers as to which standards they base their development projects on. How do they make sure their hardware and software are not made obsolete by dynamically shifting IoT standards? Thanks to the continuing cost-efficiencies of semiconductor systems, middleware has become a more attractive solution in terms of performance and accessibility.