How to Evaluate Interoperability for IoT

Successfully connecting devices from different suppliers has long been the goal in industry—and it’s imperative for the Internet of Things. Here are some key interoperability aspects to seek out to ease the integration process.

By connecting best-of-breed technologies in integrated systems, manufacturers and processors have been integrating disparate technologies for decades to improve production operations. Over the past few years, however, a new driver has arisen to further bolster this device and system integration push. That driver is the Industrial Internet of Things (IIoT). And since there is no complete IIoT system on the market—as the complex array of constituent parts will vary by facility and goal of the project—the need to integrate a variety of different technologies remains a fact of the IIoT.

To illustrate the complexity of necessary connections in an IIoT system, Leah Langston, product marketing engineer, data acquisition and control, National Instruments (NI), references the architecture of an IIoT system (see IoT architecture graphic accompanying this post). “Within this architecture, many different subsystems and technologies must come together to build a complete solution. An IIoT solution includes sensors and actuators, data acquisition, embedded computing, cybersecurity, data analytics, machine learning, visualization, data storage and management, and more.”

She adds that IIoT is “not just about increasing the number of ‘smart’ devices and sensors; it’s about how we communicate and manage a massive amount of data over a distributed network that includes edge nodes, on-premises IT, and the cloud.”

That’s why system designers have to integrate technology components from multiple vendors to create “application-specific systems to improve quality, yield, efficiency and safety,” Langston says.

Read about collaborative specifications that are helping industry tackle the interoperability challenge.

But managing communication between subsystems from multiple vendors is no small task, Langston says, as can be seen in the communication stack diagram from the Industrial Internet Consortium. “Not only must you manage multiple layers of communication standards and protocols, but many industrial verticals have their own set of industrial protocols to navigate,” she says. “In addition, there are many legacy machine-to-machine systems that are already deployed, which use a variety of proprietary protocols. These must be integrated into your system as well.”

For these reasons, the interoperability aspects of the technologies you choose are critical. And this first aspect to investigate is how the device or system you’re evaluating communicates information. Langston notes that there are four ways this occurs—via protocols, data files, web services and APIs (application programming interfaces).

“In IIoT systems, different methods will likely be used for different parts of your system,” says Langston. “However, the ultimate goal is to make this communication between subsystems as easy as possible, so that system designers can focus their efforts on solving true system problems, not problems created by tools.

Given this reality, Langston says there are two dimensions to consider: openness and technology partnerships.

“Openness relates to how easy it is to build and customize systems using the platform,” she says. Some of the beneficial features she suggests looking for include:

  • Support for many communication protocols, including the many vertical industrial protocols such as CAN, Fieldbus, OPC UA, EtherCat, Modbus, and IEC-61850;
  • Support for multiple data file types;
  • Software development kits (SDKs) and module development kits;
  • Open source real-time operating systems, such as NI’s Linux Real-Time; and
  • Plug-ins and add-ons. Langston notes that NI’s LabView Cloud Toolkit for Amazon Web Services is an example of the kind of plug-in or add-on she’s referencing here.

“Features like these prevent systems engineers from being designed into a corner as systems evolve, since they provide options for communicating data in and out of technology boundaries,” Langston says. “Open platforms also reduce the likelihood of being limited by technology that has restricted functionality or that supports a very narrow set of communication protocols.”

Partnerships between vendors also reduce risk involved in integrating technologies by having proven the interoperability aspects of their products. “Through collaborative efforts, such as the IIC testbeds, participating companies are working together to integrate technologies from multiple domains and creating reference architectures for typical IIoT use cases like predictive maintenance and smart grid communication and control,” says Langston.

Langston points out that, at NI’s Industrial IoT Lab, such partnerships are actively being demonstrated for industry. An example of one such demonstration at the Industrial IoT Lab performs asset health monitoring on a pump by combining technology from several vendors, including:

  • Flowserve, which provides the flow system technology;
  • Hewlett Packard Enterprise, which provides the edge computing and remote systems management;
  • NI, which provides the data acquisition and feature extraction capabilities;
  • PTC, whose ThingWorx IoT platform includes analytics and augmented reality; and
  • OSIsoft historian software for data management.

Through their collaboration at NI’s IoT Lab, these vendors have developed “validated APIs for communication between subsystems, such as NI’s measurement platform, OSI’s data management system and PTC's analytics platform,” Langston says. “Therefore, systems designers who are seeking to develop similar systems, can do so knowing that the risk of interoperability challenges between these subsystem is very low.”

More in Data