Eclipse recently announced a working group to drive the adoption of the Eclipse Sparkplug specification to standardise interoperability in the Industrial Internet of things arena.
The MQTT protocol has fast become the de facto standard for messaging in IOT applications.
However MQTT was designed to be as open as possible and didn’t provide any restrictions on topic names and message structures.
The Sparkplug specification was introduced by Cirrus link in 2016 as version A and upgraded shortly afterwards to version B.
It was created to overcome some or the perceived shortcomings of MQTT for the Industrial sector.
This is what the Sparkplug specification says about MQTT.
The MQTT message transport specification does not specify the Topic Namespace to use nor does it define the Payload representation of the data being published and/or subscribed to.
As with the Topic Namespace and Payload the way state information is implemented and managed within the MQTT infrastructure is not defined.
To overrcome this the specification provides:
- A topic name space structure as shown below:
2. A Mechanism for state management that uses birth messages and the existing last will and testament message.
3. A payload structure using Google protocol buffers.
It is important the note that the Sparkplug specification doesn’t change MQTT in any way it simply defines certain aspects of it they were left open for the end user to decide on.
The following schematic shows the relationship:
What Does it Mean?
It means that developers and planners have clear guidelines when designing there topic namespace, packaging their message payloads, and maintaining and communicating client state which will aid interoperability of systems.
Client state is important and was an inherent feature of polled systems which MQTT replaced.
MQTT partially catered for this with last will messages and keepalives but Sparkplug extends this to include birth messages.
Sparkplug Network Infrastructure Components
A reference infrastructure diagram is shown below:
There are 4 components
- MQTT Broker (Server)
- Management Application or Applications
- MQTT Edge of Network Nodes (MQTT EON)
MQTT Broker (Server)
Standard MQTT broker running standard compliant MQTT v3.1.1. All communication between applications and Sparkplug nodes goes through this broker/server.
The broker must support
- Retained messages
- Last Will and Testament
The screenshot is taken from the specification
You should note that for resilience you can utilise several MQTT brokers but we will restrict our discussion to a single broker for the time being.
Management Application or Applications
SCADA/IIoT Host Node
This is a often called the primary application and must be present. Other Applications e.g. data loggers etc can also access the broker to extract data without affecting the SCADA/IIoT Host Node.
The SCADA/IIoT Host Node receives data from Sparkplug nodes and sends control information to Sparkplug nodes.
Again for resilience you can have several SCADA/IIoT Host Nodes but only one can control the network at any given time (Primary Application).
MQTT Edge of Network Nodes (MQTT EON)
There are two types shown in the diagram.
A gateway device which sends and receives data from devices that don’t support the MQTT protocol and sends this to the MQTT broker.
An MQTT enabled device that supports Sparkplug and communicates directly with the MQTT broker just like a EON node. If the device doesn’t support Sparkplug then it needs to use a Sparkplug EON node.
Device Topic Addressing Plan and Topic Hierarchy
As mention earlier the Sparkplug namespace looks like this
There are only two options spAv1.0 or spBv1.0
You can divide devices into groups for management
This can be one of several
• NBIRTH – Birth certificate for MQTT EoN nodes.
• NDEATH – Death certificate for MQTT EoN nodes.
• DBIRTH – Birth certificate for Devices.
• DDEATH – Death certificate for Devices.
• NDATA – Node data message.
• DDATA – Device data message.
• NCMD – Node command message.
• DCMD – Device command message.
• STATE – Critical application state message.
This identifies the EON Node and must be unique
This identifies the device but may not be present when messages are destined for a EON node. When used it must be unique.
Example Topic Plan
Description – A steel factory with rolling mills and other plants. I’ve used terms plant1 but in real life it would be something more descriptive like mills,furnaces,workshops etc and devices would be lathe, polisher etc
The next post in this series will cover Sparkplug Payloads and Messages.
- Sparkplug FAQ
- MQTT + Sparkplug : What The Marriage Is All about
- Getting started with MQTT and sparkplug
I’m sending a birth messages to the broker from edge of network node, does it sufficient to tell broker that Eon is Online or do we have any special message type to call Eon is online. Because as soon as I send DData broker log a message that received Ddata for offline edge.
Yhe control application has to subscribe to the topic tree and process the birth message. The broker doesn’t monitor state it just sends messages between applications.
Thanks Steve. My broker logs a warning message as soon as it start receiving DData from my edge. Otherwise end-to-end communication and data exchange is good. May be I need to check with broker development team why it is throwing warnings.
Can you use the asksteve page and then you can send me the error message screen shot by email
Are there any ready to use Sparkplug libraries or do I have to use raw MQTT and read the specification?
There are libraries for Google protocol buffers but not sparkplug as far as I know.
Thank you for your excellent and concise information. Will there be a Sparkplug for MQTT 5.0 soon ? I am not able to find anything. Thanks again for your help, Clifton
It shouldn’t make any difference as it only defines a topic structure and payload structure and isn’t reliant on any MQTT features other tna retain messages and last will messages.