Simulating MQTT Sparkplug EON nodes
If you work with the Industrial IoT domain, you may have already heard about Sparkplug. It may sound a bit obscure for people already familiar with MQTT. This post will provide a 5-minute overview of the key concepts needed to grasp the sparkplug specification and get you started with a simulated Sparkplug EON node using IoTIFY.
What is Sparkplug?
MQTT Sparkplug B is a specification based on MQTT 3.1 (and now MQTT5) that can be used to securely transmit data between devices and applications in an industrial Internet of Things (IIoT) environment. As the specification is based on an already proven MQTT protocol, it’s easy to implement and operate in industrial settings, such as intelligent factory floors and industrial automation.
Why Sparkplug?
MQTT is flexible, and therein lies its biggest weakness. The protocol leaves the decision to the user to use any payload format and topic naming convention as long as it adheres to the specification. That creates a lot of room to play, and seeds incompatibility across vendors. E.g. a temperature sensor vendor could choose to publish the temperature of a machine on topic /temperature/machineA or /machineA/temperature. Similarly, it could use Fahrenheit or degree centigrade for the unit. This freedom seeds incompatibility across vendors.
The sparkplug extension brings a semantic layer on top of MQTT along with many other benefits. One of the key advantages of using MQTT Sparkplug B is that it allows for compatibility between devices of different vendors as long as they fully comply with the specification. This can be particularly useful in industrial environments, where collecting and analyzing data from a large number of devices from different vendors is often necessary. There are other benefits as well, e.g. using the last Will feature, node connection and disconnection are automatically announced to the network. This removes the requirement to poll the status continuously
Key Concepts
Sparkplug B includes support for named data topics and payloads and the ability to encode and decode data using common industrial data types, such as integers and floating point numbers.
Following are the key concepts for MQTT Sparkplug
- Fully based on MQTT 3.1 specification (and now MQTT 5), most MQTT brokers already have support for this.
- It has a strict topology for publication topics that all nodes must follow.
- The payload structure is formatted using google protobuf
- Two of the key nodes in Sparkplug are Edge of Network node (EON), which provides sensors data, and Primary Application node, which is typically a SCADA host.
- There can only be one active Primary application node at the given time in a network.
- There could be multiple EON nodes in the network.
- Each EON node must announce its arrival and disconnection in the network by NBIRTH and NDEATH messages. Important that it is the broker that transmits NDEATH message upon the node disconnection; that’s why it is essential to support the Last Will message in the broker.
- Each device behind the EON node must announce its arrival and disconnection with DBIRTH and DDEATH messages.
- The primary application must publish STATE birth certificate message upon connection and update its metric to ONLINE.
- The primary application should setup a last will message which will announce STATE death certificate and update the metric to OFFLINE.
Simulating EON Sparkplug node
Simulating other Sparkplug Nodes
Using a similar approach, other sparkplug nodes could be simulated as well. Please get in touch with your requirements and we will be happy to help.
