One of the primary pain points in Industrial IoT (IIoT) is disparate systems with both modern and legacy assets. Companies in any industry ranging from oil and gas to manufacturing can hardly imagine a world where they can choose any vendor’s hardware, plug it into their network, and have the hardware 100 percent self-discovered by their SCADA system and every application in the enterprise. True vendor interoperability for both data producers and data consumers is the vision, and new open-source technology may be the answer.
Historically, operational technology (OT) and information technology (IT) lived far apart in the industrial enterprise. In recent years, the convergence of OT and IT has been well documented as IIoT evolves and companies work to digitally transform. OT functions need access to data to monitor things like asset health while IT may want to implement advanced solutions for machine learning and artificial intelligence to improve overall processes and efficiency. Digital transformation requires devices in the field to be connected, with data made available that can speak the language of both OT and IT for improved business intelligence. In order for this type of digital transformation to be successful, data must be decoupled from a single application so it can flow to enterprise applications in a one-to-many approach.
As a result, MQTT has become the dominant messaging protocol for IIoT as a lightweight, publish-subscribe network protocol that allows for multiple data consumers. MQTT enables companies to gain access to more data and then share it throughout the enterprise across both IT and OT teams, and is now natively supported by every major cloud provider.
Data easily understood by OT functions (temperature for example) may be unusable in the IT realm without more clearly defined parameters describing the data. The IT world may look at a piece of temperature data with no idea if it is scaled across a range like 0 to 4095, Celsius or Fahrenheit, and so on. Some enterprises are solving this problem by manually editing these tags in multiple applications outside of OT, but that process is time consuming, error prone, and inefficient.
While it provides an excellent engine for delivering IIoT data, MQTT doesn’t make the data interoperable across the enterprise. Thus, a new open source standard has been created and the IIoT industry should understand its importance for bridging the gap from OT to IT.
A Lack of Detail from OT Data
By design, MQTT does not dictate a Topic Namespace or payload encoding because it was developed to provide maximum flexibility across any solution sector. The lack of detail is both a benefit and a limitation, since it inhibits interoperability in the OT and IT worlds. OT data has always been collected on the factory floor for a specific purpose. The plant floor manager knows and understands how to use the data. Now that the IT team wants to see that data and make use of it – they need a better way to understand the data.
A simple example would be a message sent via MQTT from a global company’s factory in Japan to their IT department in Germany. Without knowing Japanese, the IT department cannot understand the message. MQTT publishes data to a broker and delivers it to multiple consumers – which solves a host of former challenges, but there is no methodology for data representation.
The Internet expanded rapidly thanks to two open technologies – first HTTP, a data exchange protocol, and then HTML, which was used to define the data sent by HTTP. Both were needed. MQTT has needed its “HTML” for years in order for IIoT to explode in growth and adoption. In order to solve this problem of OT-IT interoperability, the Eclipse Sparkplug working group was launched in February 2020 to bring device communications standardization to IIoT.
Sparkplug
According to the Eclipse Foundation, the Sparkplug Working Group was established to “improve the interoperability and scalability of IIoT solutions, and provide an overall framework for supporting Industry 4.0 for oil and gas, energy, manufacturing, smart cities, and other related industries.”
Sparkplug is an open source software specification that provides MQTT clients with a framework to integrate data. The specification articulates three goals:
- Define an MQTT Topic Namespace optimized for IIoT.
- Define MQTT State Management to take advantage of continuous session awareness.
- Define the MQTT Payload.
Sparkplug adds features including birth certificate and death certificate (session awareness) to help with contextualization of data. Sparkplug takes the aforementioned message in Japanese, and defines how to publish and represent it, so any subscriber knows what it is and how to utilize the data. With Sparkplug, if the IT department in Germany subscribes to a new topic for data from the Japanese factory, they learn everything about the device and data immediately.
Sparkplug makes this process fast, secure, and open standard so anyone can make use of the framework for MQTT interoperability. Many device manufacturers are supporting Sparkplug, which means it is built in natively on the device on the OT floor.
To further demonstrate the need for Sparkplug, consider a MODBUS protocol (common in the OT world) asking for register 40,027 would return a value of 2047. However, most data consumers have no idea what that 2047 represents. Is it a temperature, a pressure?
With Sparkplug the message would publish and instead of calling it register 40,027, it would say: compressor temperature, scale from 0 to 100 degrees Celsius, tied to x asset device, is 27 degrees Celsius. With all of the necessary textual information for the data object instead of one proprietary piece of data, it is shareable across the enterprise.
The Future of Sparkplug
As device manufacturers and application providers start to support Sparkplug, enterprise IIoT customers will see how easily they can add new tags and assets to their operation. Cirrus Link authored the Sparkplug specification and provided it to the Eclipse Foundation, and several other companies support the group as founding members including Chevron, Canary Labs, HiveMQ, Inductive Automation, and ORing. Now additional companies are developing their products using Sparkplug for interoperability.
With Sparkplug, machine learning and artificial intelligence applications can utilize the same standard interface for data without having to know and understand the entire OT environment. They can subscribe to the OT data, and use it immediately for IT functions. For more information about the Sparkplug Working Group visit https://sparkplug.eclipse.org.
About the author: Arlen Nipper brings over 42 years of experience in the SCADA industry to Cirrus Link as President and CTO.
Edited by
Ken Briodagh
