More Interoperability in the IIoT

More Interoperability in the IIoT | SPONSORED

Why the manufacturing industry needs communication standards

The digital transformation has been underway on factory floors for some time now. As digital technologies emerges as a key factor for remaining competitive, the need for change gains focus. The sheer complexity of many existing systems makes data transparency and networking difficult and highlights why the production industry is still hesitant to implement digitalization strategies.

Given the increasing importance of interoperability in IIoT, solutions that can automatically integrate and analyze data across systems are essential. Until now, the transfer of even a single input/output signal from the factory floor to the cloud often required an unwieldy technological setup that was inefficient in terms of IT security, cost, and effort. Today, lean new technologies offer the manufacturing industry an attractive and profitable alternative to complex traditional systems.

Classic OT / IT Infrastructure with OPC UA

Typical architecture in production environments includes numerous devices, sensors, and gateways that potentially communicate via different protocols. Each entity provides its data or is controlled through direct bidirectional connections. This sort of design works well when there are only a few systems to integrate. However, it leads to a difficult-to-maintain architecture when there are a larger number of components since the systems  are connected point-to-point and the components are hardwired together. 

Modern IIoT architectures require more flexibility. Many companies look for adaptability, flexibility, and ease of implementation for their IT setup. But at the same time, businesses need maximum reliability, security, and predictability for their OT landscapes. Meeting these needs requires a new architecture.

If you want to bypass complexity and move to a lean solution that guarantees a secure and reliable data exchange in industrial automation, you invariably encounter the MQTT protocol.

As an OASIS standard, the MQTT 5 protocol offers a specification that is generally acknowledged as the de facto standard for IoT. The core principle of the exceptionally lightweight MQTT protocol is the publish-subscribe pattern. This pattern allows any number of data consumers to subscribe to individual topics or subject areas and receive the messages published about them.

The slimness of MQTT is particularly suitable for very low-resource devices and communication in low-bandwidth, unreliable, or high-latency networks. MQTT architecture enables communication with an unlimited number of clients via the publish-subscribe protocol.

MQTT Infrastructure in the Production Environment 

The use of a pub-sub protocol such as MQTT and a message broker as the central component represents a fundamental change in architecture. 

All messages are sent via a central MQTT broker, and all MQTT clients connect to the broker and can subscribe and publish to specific topics. The MQTT broker takes over the task of the server and handles communication with an unlimited number of MQTT clients. MQTT clients are implemented directly on gateways, devices, or within applications, and all of the clients are loosely coupled. There are no direct relationships between the clients. In addition to functional requirements, the MQTT broker should also handle needs such as redundancy, failover, high availability, and scalability within a given infrastructure.

Introduction to Sparkplug 

To fulfill interoperability requirements of industrial automation, implementation standards based on MQTT must be defined. Providing this definition is the goal of Sparkplug. Sparkplug provides an open and freely available specification that describes how edge gateways, native MQTT-enabled endpoints, and MQTT applications in the infrastructure can communicate bidirectionally through a central component, the MQTT broker. The Sparkplug specification defines how MQTT can be used in mission-critical, real-time OT environments. It establishes an optimized standard for use cases in industrial applications that utilize SCADA, tag, and metric representation. The specification describes how the principles can best be used in real-time SCADA implementations.

The purpose of the Sparkplug specification is straightforward:

• Pair the advantages of MQTT, such as simplicity, efficiency, and comprehensibility both in implementation and operation with the requirements from the OT.
• Establish an ontology that is known to all parties involved.
• Guarantee session management for clients.
• Keep traffic and message sizes to a minimum.

The Sparkplug specification gives developers and architects clear guidelines for drafting the topic namespace, structuring payload data, and how client status is to be maintained and communicated. 

MQTT Infrastructure with Sparkplug in IIoT Environments 

In Sparkplug architecture, devices, EoN nodes, and the SCADA/IIoT hosts connect to a central MQTT broker to publish and subscribe to data. In contrast to a traditional SCADA system architecture, with Sparkplug, the SCADA/IoT host is not responsible for directly establishing or maintaining connections to devices. The EoN nodes connect non-Sparkplug / MQTT-enabled devices and sensors to the infrastructure. The EoN node is responsible for managing its own state and the state of the devices as well as receiving and sending data from the devices to the Sparkplug infrastructure. Many vendors now offer native MQTT capabilities with their devices and sensors. If the MQTT-enabled device is already equipped with Sparkplug, it can participate directly in the infrastructure. In this case, the device identifies itself as an EoN node for the Sparkplug infrastructure.

All MQTT clients, particularly the SCADA host and the IT applications, subscribe to the topics from which information is to be received. Due to the firmly defined topic structure and the data objects, each MQTT client knows where and what form of information can be retrieved. Since MQTT clients are stateful, no loss of information occurs at any time. Message types are specified for specific information.

Conclusion 

The concepts of the MQTT specification are perfectly suited for the digitization of production. 

A major advantage of MQTT is the decoupling of the data through the use of a central messaging component. The MQTT protocol enables various security mechanisms to be implemented easily. And on-board resources are available for status management of the MQTT clients.

Due to its properties such as lightweight and speed, MQTT is ideally suited for the real-time operation of IIoT infrastructures that the Sparkplug specification is designed for. Sparkplug gives MQTT a framework that was developed based on the requirements of IIoT systems.

The following functionalities of the specification ensure extreme savings in terms of network resources:

• Send only data changes (report by exception)
• Publish / Subscribe mechanism
• Session and status management
• Compressed payload

For use in production environments, it is necessary to define an ontology so that all devices and applications involved know, understand, and can apply the terms and the relationships between them in the subject area. This means that the information sent can be interpreted by all the components of the IT structures without further meta information. This approach makes it possible for  manufacturers to deliver devices that comply with the specification. 

Last but not least, it is much easier to integrate devices into an architecture with message-oriented middleware – such as the MQTT Broker, than into a client-server structure. Since each component in the system only communicates with the broker, no further configurations are necessary. This ease of use saves a lot of time and expense.

About HiveMQ

HiveMQ helps companies connect devices to the Internet. Our HiveMQ MQTT platform makes it possible to move data from device to cloud in a secure, reliable and scalable manner. Over 130 customers, including many Fortune 500 companies, rely on HiveMQ in production for mission critical use cases like connected cars, transportation, logistics, Industry 4.0 and connected IoT products.

HiveMQ is an active participant in the Sparkplug Working Group. Visit hivemq.com/sparkplug for more details.

 

About the Author

This article was written by Anja Helmbrecht-Schaar, Senior IT Consultant at HiveMQ.