The reality to most developers and software architects is that OPC-UA is not the silver bullet everyone hoped for. OPC-UA is extremely complex, heavyweight and is not always easy to integrate, especially in brownfield environments which you typically have in most manufacturing projects. So people felt there must be a better way.
The wish came true when the Sparkplug protocol, which is based on MQTT, was first released by one of the very founding fathers of MQTT: Arlen Nipper. The Sparkplug specification took the industry by storm and large companies like Chevron adopted it for operational efficiency gains and for creating next-generation manufacturing solutions.On the other hand, device-to-cloud communication for minimal latency and maximal throughput got easy with the MQTT protocol. And many developers wished for a simple solution like MQTT for manufacturing, but with the features required for the manufacturing industry like payload definitions and unified messaging behavior across machines and vendors.
But what is Sparkplug actually?
Sparkplug is an open-source software specification that provides MQTT clients the framework to seamlessly integrate data from their applications, sensors, devices, and gateways within the MQTT infrastructure in a bi-directional and interoperable way.
To have a common language for the IIoT, the Sparkplug specification defines the following three goals:
- Define an MQTT topic namespace
- Define MQTT state management
- Define the MQTT payload
It’s noteworthy that Sparkplug is actually designed to run 100% on MQTT since the publish/subscribe paradigm of MQTT allows for bi-directional and decoupled integration of all components of a system. When MQTT was invented in 1999, it was originally designed for SCADA systems but left out all specifications around how topics and the payload should be structured and how devices should behave. This allowed MQTT to be used in different industries like connected car, logistics and smart manufacturing. Sparkplug now fills the gap and provides a vendor-neutral specification for data formats, topic structures, state management, and how topologies should be structured in IIoT scenarios.
Sparkplug vs. plain MQTT
Sparkplug was designed for Industrial Internet of Things applications based on MQTT. Many vendors support MQTT out of the box for their PLCs (for example Siemens S7) and most Manufacturing Execution Systems (MES) and SCADA systems (like Ignition SCADA by Inductive Automation) support MQTT. Of course most professional gateway solutions used in manufacturing contexts support MQTT.
Why now add Sparkplug to the mix? For any non-Sparkplug MQTT communication you need to make sure that all participants who are interested in the data know where to subscribe to the data and you need to make sure all participants can interpret the data. This usually involves data transformation, which requires conventions, and creates a tight coupling between all the applications. With Sparkplug, all participants settle on a common data format, how to receive specific data, how to publish their data, and how data can be interpreted. And the best is: Sparkplug allows bringing in data from non-MQTT devices as well data from other protocols like OPC-UA or Modbus. Oh, and we get discovery of all these devices and applications out of the box.
Requirements for Sparkplug
In order to use Sparkplug, you need an MQTT broker that is responsible for distributing the data. It is important that the MQTT broker implements 100% of the MQTT 3.1.1 specification since Sparkplug requires the following:
- QoS 0 and 1
- Retained messages
- Last will and testament
- A flexible security system
For proof of concepts, Eclipse mosquito and HiveMQ Community Edition are popular choices. For professional use cases we recommend the HiveMQ Platform. Unfortunately, AWS IoT and Azure IoTHub are not suitable for Sparkplug as they lack basic MQTT functionality.
By Dominik Obermaier, HiveMQ CTO and co-founder
