MQTT (message queueing telemetry transport) has been growing by leaps and bounds as a preferred method for data exchange between industrial devices and the applications that need data from those devices. Initially developed as a low-overhead data transport mechanism for Phillips 66 in the late 1990s, MQTT has since proliferated to applications ranging from Facebook Messenger, Amazon Web Services IoT Core, and Microsoft Azure IoT Hub to Deutsche Bahn Railways and connected home appliances, as well as manufacturing facilities and power plants.
And while numerous automation technology suppliers support MQTT, such as Aveva, IBM, Inductive Automation, Litmus, and Opto 22, its broader adoption for interoperability has been limited due to the fact the MQTT messaging was not designed to have a specific topic namespace or payload encoding. According to Arlen Nipper, co-inventor of MQTT and president and chief technology officer at Cirrus Link: “MQTT was designed to allow users to publish anything they wanted on any topic.”
In a video interview with Inductive Automation, Nipper says that, because the topic namespace and payload aspects of MQTT were developed to be data-agnostic, this meant there was no standard way to define SCADA process variable topics and payloads. “Many OEM hardware providers and software service providers were using MQTT, but each with their own definitions of topics and payloads,” says Nipper. “The result was that even though an MQTT infrastructure was being used, there was no level of plug-and-play or interoperability between the solutions on the market.”
That’s where Sparkplug comes in.
Standardizing MQTT communication
Sparkplug is an open-source software specification that defines an OT (operations technology)-centric topic namespace, an OT-centric payload definition optimized for industrial process variables, and MQTT session state management as required by real-time SCADA systems. Essentially, Sparkplug provides MQTT with the ability to integrate data from applications, sensors, devices, and gateways in an industrial Internet of Things (IIoT) infrastructure.
At the 2022 ARC Industry Forum, the launch of the Sparkplug Compatibility Program was announced. This program is designed to help end users know if their vendors’ systems are Sparkplug compatible. To be included in the program, products will need to pass the Sparkplug Technology Compatibility Kit (TCK), an open-source test suite validating conformance to the specification. Products passing the TCK will be featured in the official list of compatible products, available on the Sparkplug Working Group’s website. In addition, licensees of the Sparkplug Compatible trademark will be recognizable in the marketplace using the “Sparkplug Compatible” logo.
This list is expected to become available in Q3 2022.
Speaking to the value of this program for industrial end users, Todd Anslinger, IIoT & automation specialist at Chevron, says, "For a large enterprise like Chevron, automation engineers around the globe could be spending countless hours testing to see if something will work in their process control network or their IIoT network. Having the confidence that something will just work when you plug it in to your system via the Sparkplug compatibility program is a huge saver of time and money."
Frederic Desbiens, IoT (Internet of Things) and edge program manager at the Eclipse Foundation (which manages the Sparkplug specification), explains the Sparkplug IIoT infrastructure includes:
- MQTT Servers, which implement the subset of MQTT features to support Sparkplug;
- MQTT Edge Node, which is any MQTT v3.1.1 or v5.0 compliant MQTT client application that manages an MQTT session and provides physical and/or logical gateway functions;
- Device or sensor—any device connected to the MQTT Edge Node providing data, process variables or metrics;
- MQTT-enabled device—any device that directly connects to MQTT infrastructure using a compliant MQTT v3.1.1 or v5.0 connection; and
- Primary host application—MQTT client application that subscribes to MQTT Sparkplug Edge Node originated messages. The Primary Host Application is often also referred to as the SCADA Host or IIoT Host.
