Sparkplug Essentials Part 1 - Introduction
Written by Dominik Obermaier
Published: September 1, 2020
Welcome to the Sparkplug Essentials Series!
This is the first part of the Sparkplug Essentials Series. We are going to dissect the industry standard Sparkplug and all relevant contents of the specification, so you get the gist and have everything you need to get started. If you want to implement Sparkplug on your own, integrate the specification into your product or just want to learn about it: This is the right starting point into your journey to one of the most important communication protocols for the Industrial Internet of Things.
Introduction to Sparkplug
Industrial Internet of Things (IIoT) and Industry 4.0 are key trends in the manufacturing industry and shopfloor operators are looking for operational efficiency gains, lot size one manufacturing capabilities and real-time manufacturing insights. However, the software and hardware stacks have traditionally been closed and proprietary and interoperability was never a key concern for the vendors. Protocols like OPC-UA promised to break up the silos and provide an industry-wide common language between devices, machines and software applications. 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.
On the other hand, device to cloud communication for minimal latency and maximal throughput got revolutionary 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.
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.
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 a 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 but also 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. In the next blog post we are going to look at all the components in detail.
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:
For Proof of Concepts, Eclipse mosquitto 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, see this blog post for more details.
The next post in this series will cover the basic architecture and participants in a Sparkplug system and how the general data flow is designed.
Don’t forget to subscribe to our newsletter to make sure you don’t miss an upcoming issue of the Sparkplug Essentials!