Introduction to MQTT +Sparkplug For IIOT

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.

The specification provides:

1. A topic name space structure as shown below:

namespace/group_id/message_type/edge_node_id/[device_id]

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.

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)
• Devices

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
• QOS
• Last Will and Testament

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

namespace/group_id/message_type/edge_node_id/[device_id]

Namespace

There are only two options spAv1.0 or spBv1.0

group_id

You can divide devices into groups for management

message_type

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.

edge_node_id

This identifies the EON Node and must be unique

device_id

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

spBv1.0/plant1/message_type/rolling_mill_1/device1
spBv1.0/plant1/message_type/rolling_mill_1/device2
spBv1.0/plant1/message_type/rolling_mill_2/device1
spBv1.0/plant1/message_type/rolling_mill_2/device2

etc

The next post in this series will cover Sparkplug Payloads and Messages.

Resources

• Sparkplug FAQ
• MQTT + Sparkplug : What The Marriage Is All about
• Getting started with MQTT and sparkplug

Related Tutorials

MQTT Beginners course