What is MQTT Sparkplug?
6 min read
Imagine meeting someone who speaks the same language, but they use different words than you to refer to the same objects. For instance, what you call a PLC, they call a PAC. There would be plenty of confusion, especially at key moments when we need to act quickly to correct a problem.
While it’s certainly possible that, given enough time and effort, you can align your languages, wouldn’t it just be a lot easier if you followed the same dictionary to begin with? In a nutshell, that’s what MQTT Sparkplug does for industrial control systems. It defines a specific way to structure messages within the MQTT protocol to promote interoperability and integration.
Sparkplug is an open source software specification that tells MQTT clients how to use the protocol in industrial settings. Without Sparkplug, MQTT’s inherent flexibility manifests as a curse rather than a blessing; a lack of uniformity creates tighter couplings within the control system architecture, slows new device integration, and simply leaves too much either unknown or undefined, creating a window for confusion or miscommunication to creep in.
That’s often the difference between a safe, efficient, highly available control system and one that’s plagued by downtime, waste, and vulnerability. There’s a reason why top companies like Chevron use it and OEMs are increasingly building native MQTT Sparkplug support into their products.
In a word, Sparkplug enables Industry 4.0 by creating plug and play interoperability for the industrial internet of things (IIoT).
Here’s how.
The Three Goals of MQTT Sparkplug
The official Sparkplug documentation begins by explaining that “the Sparkplug specification strives to accomplish the three following goals”:
Define an MQTT Topic Namespace
Define MQTT State Management
Define the MQTT Payload
Let’s break this down. Starting with the namespace, this specification tells us exactly how to structure the names of topics that MQTT clients publish and subscribe to. Specifically, Sparkplug specifies the following namespace structure:
namespace/group_id/message_type/edge_node_id/[device_id]Uniformity in the namespace simplifies IIoT integration via MQTT because engineers and system integrators no longer need to keep track of so many different topic names. Without Sparkplug, each device could have its own naming scheme, and keeping track of all of them becomes increasingly difficult as we scale throughout the factory. For instance, instead of having to subscribe to “temp_reading1”, “thermo-A”, and “reading_temp-5” to keep track of temperatures of different devices, we’d instead subscribe to “temp1”, “temp2”, and “temp3”. That’s a lot easier.
For industrial programmers familiar with Modbus registers, you understand the frustration of working with free name conventions. Every device requires extensive documentation to tell the users the communication registers, and it quickly becomes very confusing to keep track of multiple devices on the network. Especially if we don’t have the required documentation, there’s no way to even know what the register definition is. Sparkplug circumvents this problem by defining the topic namespace.
Second, Sparkplug gives us the tools to keep track of state management by using birth messages and the existing last will and testament from MQTT. Basically, when a device comes online or goes offline, it will broadcast that fact. That way the SCADA system will maintain complete awareness of what’s online and what’s offline without having to continuously poll any of the devices.
Third, Sparkplug defines a payload structure that can represent complex data as a string and functions in a similar way to JSON. Each Sparkplug payload contains a series of metrics, and each metric includes:
Name
Alias
Time stamp
Data type
Value
Just like how adding uniformity to the topic namespace simplified integration by stripping away unnecessary complexity, Sparkplug’s defined payload structure makes it easier for us to write clean code because our data sources will all present their messages with the same structure.
MQTT Sparkplug Architecture
Another key facet of any MQTT Sparkplug system is properly configuring the architecture. Just like vanilla MQTT, Sparkplug relies on a pub/sub messaging scheme where data producers publish to topics, data consumers subscribe to those topics, and a centralized MQTT broker conveys data from the publisher to the subscriber.
Speaking of the MQTT broker, this device is the hub around which everything else is centered. In addition to receiving publications and routing the messages to the appropriate subscribers, the broker is responsible for authentication, authorization, and state management. As a potential single source of failure, we recommend building redundancy into your Sparkplug architecture by running multiple brokers in parallel.
Now let’s take a closer look at a machine on the production line that’s collecting data on metrics like pressure, temperature, RPMs, etc. If that machine is enabled with Sparkplug, it’s considered an Edge of Network (EON) device, and it will continuously send data to the MQTT broker. However, even if it doesn’t have native Sparkplug support, it can still participate in the architecture by first sending data to a gateway device that acts at the EON.
It doesn’t even need to use MQTT at all; the machine can send data to the EON via older protocols like Modbus or OPC UA, and the EON will take that data, “translate it”, and feed it into the Sparkplug architecture. Whether it’s a gateway or the device itself, EON nodes are also responsible for maintaining state awareness.
Also referred to as the Primary Application, the SCADA / IIoT Host is the supervising application that monitors and controls the MQTT EoN nodes and their devices and sensors. It’s not too different from a traditional SCADA system, other than the fact that it doesn’t establish or maintain direct connections to any of the EoN nodes or devices. Instead, the SCADA application connects to the broker.
Lastly, there’s also MQTT Application Nodes. These applications use data that’s sent over MQTT, and sometimes they also produce messages as well. Historians, Manufacturing Execution Systems (MES), and Analytics are common Application nodes. For instance, an application that runs a Machine Learning (ML) algorithm that predicts machine failure to enable preventative maintenance will receive machine metrics, crunch the numbers, and, if necessary, publish a message such as “stop this motor for repair.” That message goes through the broker, back out to the EoN, and turns off the motor—and of course the SCADA application receives the report as well.
Advantages of MQTT Sparkplug
So, why use MQTT Sparkplug? This specification adds on top of the advantages of plain MQTT to create a solution that’s tailor-made for industrial use cases.
First, Sparkplug decouples consumers and producers of data. Instead of hard-wiring connections or hard-coding integrations between devices, Sparkplug’s universal structures for both namespaces and payloads adds a layer of abstraction that makes it much easier to add, remove, or change hardware.
Second, Sparkplug’s pub/sub model includes a feature called “report by exception” that saves bandwidth and computing power. Take state management, for instance. With the older polling style, the SCADA system would continuously ask devices if they were online at regular intervals. Not only does this waste time and energy, but it also means that a device could go down for a period without the system being aware of that fact unless we poll at an even greater frequency. With report by exception, we’ll know right away when a device goes down or another metric changes.
Third, Sparkplug offers flexibility and interoperability, including support for legacy equipment. Remember, even if an older device doesn’t support Sparkplug or MQTT, it can still participate in the network by transmitting data to a Sparkplug-enabled EoN node.
Fourth, the specification’s focus on uniformity enables auto discovery of both devices and data on the network. This is especially crucial for SCADA and other application nodes.
Fifth, the entire specification is open source technology. This means it’s free to use, doesn’t require any licensing, and can be easily customized if necessary.
Conclusion
Ready to get started with MQTT Sparkplug? Check out this demo, which includes a tutorial that gets into some of the more nitty gritty technical bits required for a successful Sparkplug integration and gives a demo showing this technology in action.
And, of course, Sparkplug is only one small part of the industrial technological revolution that is Industry 4.0 and the IIoT. It’s a key enabler, but it’s far from the end of the story. If you’re just setting down the road to updating your automation systems for the 21st century, you need someone on your side who brings both an understanding of the big picture and the technical expertise to get it done.
Outlier Automation is that trusted partner. Whether you need help getting started with MQTT Sparkplug, are planning a PLC upgrade, or just beginning to experiment with proof of concepts for cutting edge technology, Outlier Automation can help you achieve your automation goals and set you down the path to continued success. Contact us today to learn more.