H Data Copy

Using open standards to solve Industry 4.0 data interoperability

Feb. 1, 2023
"Let’s explore how companies can set the right foundation for data movement in IIoT systems."

By Dominik Obermaier, co-founder and CTO of HiveMQ

Manufacturing data—everything from factory equipment data to SCADA, from MES to business planning—can be combined to improve operations and create a competitive advantage. You already know this. Industry 4.0 use cases range from measuring and increasing OEE (overall equipment effectiveness ) and performing predictive maintenance to improving quality with artificial intelligence. You already know this.

Recognizing the importance of operational data is one thing; getting IT and OT systems to talk to each other so that data can be put to use, however, can be very difficult. Some of the major challenges industrial customers face in moving their IoT data as they work to modernize include:

●     Heterogeneous devices and data sources

●      Lack of bi-directional connectivity

●      Unreliable networks and latency

●      Escalating costs of network bandwidth

●      Data silos prohibiting IT/OT convergence

Manufacturers need solutions that solve these challenges and enable them to deploy cohesive, future-proof data strategies. The top priority must be achieving seamless, bi-directional data flow and interoperability to bridge the IT-to-OT gap and enable data-driven use cases.

With that in mind, let’s explore how companies can set the right foundation for data movement in IIoT systems, specifically with MQTT Sparkplug.

A simple architecture for legacy IIoT systems

Legacy IT and OT systems are inherently siloed, as it wasn’t until recently that the two began to work together toward data-driven operations. As shown in Figure 1, on the OT side you have data sources like PLCs, devices and gateways generating data. On the IT side you have MES, historians, SCADA systems, analytics tools, and other applications that need to consume data, do something with the data, and then present it to stakeholders or other systems.

Figure 1: Sharing data from legacy OT systems to IT is not a simple task.

 With this complicated architecture and spiderweb of data paths, analyzing the data, changing processes, or setting up new facilities is extremely difficult. Large manufacturing companies with many factories worldwide need to gather data in one central layer inside of a modern architecture so they can access and analyze it as needed for any use case and then make improvements across the business.

As shown in Figure 2, a modern, streamlined architecture puts a central data broker in the middle that is able to decouple the varied data producers from the data consumers to move messages bi-directionally. Now, instead of having a single point-to-point connection from a gateway to an MES for instance, you have a data hub that makes it possible to get the data where you need it and when you need it, from any number of data sources to any number of data consumers.

Figure 2: A simple architecture decouples the data producers from the data consumers in the middle for a seamless flow of data.

So, how can manufacturers achieve this type of architecture? They need a data broker and they need the right protocols to move the data. MQTT is the leading modern protocol for device-to-cloud communication because it provides this decoupled architecture with a publish/subscribe messaging pattern designed for fast and reliable data transport.

MQTT is ideal in constrained environments that are common in manufacturing, such as unreliable network connectivity or limited bandwidth. The protocol is open source, data agnostic, lightweight and efficient. MQTT is built on top of TCP/IP and can also scale to millions of connections seamlessly.

MQTT is excellently suited for this kind of simple architecture and solves the spider web of OT and IT technologies, enabling the movement of data within a single factory, from factory to cloud, and from factory to other factories. However, devices and endpoints have different topics, payloads and data structures. MQTT by itself has no built-in workflows, state management or plug-and-play interoperability. 

Achieving interoperability with MQTT Sparkplug

Enter Sparkplug, a newer, open specification within the Eclipse Tahu project that sits on top of MQTT and adds additional functionality. Sparkplug enables the use of MQTT in a mission-critical, real-time environment by defining the topic namespace, payload, and state management. These features enable data-modeling capabilities, which is how organizations define and organize their business processes to unlock the value of their data.

Many vendors and applications are now supporting Sparkplug out-of-the-box (Figure 3), which enables true plug-and-play data interoperability in Industrial IoT. The architecture is again built around an MQTT data broker in the middle with devices, sensors and gateways on one side publishing data and applications on the other. The Sparkplug-enabled MQTT broker brings all of the data together for a single source of truth and any application or device can subscribe or publish data.

Figure 3: Sparkplug-enabled technology comes together to create a single source of truth for the data.

 The benefit of the MQTT broker in the middle, along with the Sparkplug-enabled host, is that any application can connect to the broker, consume all or a subset of the data, and do something meaningful with it without disrupting the other devices or applications in the system. Many MES systems, historians and analytics systems are now Sparkplug-enabled and there are also open-source libraries to help companies develop their own applications to make use of Sparkplug data.

Sparkplug has some other specific benefits for Industry 4.0 such as the report-by-exception principle and persistent connections. Traditional poll/response protocols like Modbus poll for data at set intervals, every few seconds or more, which uses a lot of bandwidth and computing power even if there is no state update or the tag value did not change. This is a big problem in remote-site locations or when data-storage costs are high. Sparkplug uses report-by-exception, meaning data is only published when something changes. As a result, companies can save up to 90% in bandwidth.

Another benefit of Sparkplug that makes it truly plug-and-play is auto-discovery, meaning any Sparkplug-enabled device, PLC or gateway can be brought into the system and recognized  automatically. Auto-discovery means no need to configure or connect new devices, which makes scaling fast and easy.

Getting started with MQTT Sparkplug

Sparkplug combines MQTT-decoupled devices and applications and adds context for Industry 4.0 use cases, giving customers the flexibility they need to modernize their factories. Most manufacturers start with one simple use case, bringing the data into the Sparkplug architecture and storing it in the cloud. Often after the initial proof of concept is done, adoption is high for mission-critical use cases. OPC UA, Modbus and other protocols don’t need to be abandoned, the existing devices can be brought into the new architecture and MQTT will bridge everything to the cloud as needed.

More information about Sparkplug can be found via the Eclipse Sparkplug Working Group. Version 3.0 of the specification has just been released, which enables vendors to use a Sparkplug Technology Compatibility Kit to get listed as a Sparkplug-compatible product, which will further encourage adoption and easy interoperability in Industry 4.0.