Decoding the Operational Behavior of MQTT Sparkplug in IIoT Systems

In Part 6 of Sparkplug Essentials, Breaking Down MQTT Sparkplug Payload Structures in IIoT Messaging, we covered the challenges presented by inconsistent & non-standardized payload formats in IIoT & how to overcome them using MQTT Sparkplug Payload Structures. In part 7, we give an explanation of MQTT Sparkplug’s operational behavior, shedding light on the complex mechanisms essential for effective IIoT communication. Let’s dive in.

For effective IIoT architectural design and development based on MQTT Sparkplug, it’s essential to understand how its components operate — specifically, how they connect, publish, and receive data and disconnect from the network.

To illustrate the operational behavior of MQTT Sparkplug components within the IIoT network, we will explore the session life cycle of three key components: Sparkplug host applications, edge of network nodes, and devices to explain the connection mechanisms, data transmission methods, and the intricacies of session establishments.

MQTT Sparkplug Host Application Session Life Cycle

When the Sparkplug host application starts or re-establishes its connection, it promptly tries to initiate a session with the MQTT server, which has been pre-configured for this purpose.

Once a successful connection with the MQTT server is achieved, the host application takes two primary actions:

1. It subscribes to the designated Sparkplug topic namespace, specifically spBv1.0/#.

2. It also ensures that it subscribes to its own state through the topic named STATE/host_app_id.

Following these subscriptions, the Sparkplug host application takes the responsibility to notify others of its status by publishing a new STATE message.

MQTT Sparkplug host application taking the responsibility to notify others of its status by publishing a new STATE message

At this stage, the host application stands ready to receive MQTT messages from any edge node that’s part of the network. With each incoming message, particularly when edge nodes send their Sparkplug NBIRTH and DBIRTH notifications, the host application updates its metrics to show that it’s currently online and actively processing data.

However, if the host application ever experiences a disconnection from its associated MQTT server(s), all metric data associated with any Sparkplug edge node that was connected to that MQTT server and known by the host application will be updated to a STALE data quality.

MQTT Sparkplug Edge Node Session Life Cycle

Like any device in the Sparkplug network, an edge node initiates its connection to the MQTT broker by sending a connection request. This request will typically contain the node’s credentials and other necessary details.

When a Sparkplug edge node sends its MQTT CONNECT packet, it will include a “will message” under the following topic format:

spBv1.0/group_id/NDEATH/edge_node_id

Here, group_id is the Sparkplug group ID and the edge_node_id is the Sparkplug edge node ID for the edge node.

In a Sparkplug environment, edge nodes can be set up to recognize a primary host application. If configured this way, an edge node will only send its NBIRTH and DBIRTH messages once the primary host application is online and actively listening for Sparkplug messages. It’s optional to assign a primary host to an edge node, but it’s often a good idea. Consider a scenario with only one host application recording data: If the host isn’t online and ready to receive messages, it’s counterproductive for the edge node to send data. Instead, the edge node should hold onto its data when the host application is offline. As soon as the host reconnects, the edge node can send its accumulated data and then resume regular transmissions.

Upon successfully connecting to the MQTT server, the edge node will subscribe to NCMD and STATE topics. The NCMD subscription allows the edge node to address rebirth requests. Meanwhile, subscribing to STATE helps the edge node stay updated on the primary host application’s current status.

Subsequently, the edge node will broadcast an NBIRTH message using the following format:

spBv1.0/group_id/NBIRTH/edge_node_id

Here, group_id represents the Sparkplug group ID, while edge_node_id is the unique ID of the edge node.

MQTT Sparkplug Edge Node Session

With this message sent, the primary host application can now establish the edge node’s metric structure, displaying its online status.

However, should the edge node’s MQTT client ever lose its connection to the relevant MQTT server(s), the server will generate a death certificate (NDEATH) for the edge node. Also, if an edge node plans to disconnect deliberately, it will first send out an NDEATH message before severing the connection.

MQTT Sparkplug Device Session Life Cycle

At the state at which the edge node is ready to report all of its metric data to the MQTT server as defined in Sparkplug. It is the responsibility of the edge node (logical or physical) to publish devices birth messages, DBIRTH.

However, prior to sending a DBIRTH message, if the device supports writing to outputs the MQTT client associated with the Sparkplug device must subscribe to receive DCMD messages using the following topic format:

spBv1.0/group_id/DCMD/edge_node_id/device_id

Here, group_id is the Sparkplug group ID the edge_node_id is the Sparkplug edge node ID and the device_id is the Sparkplug device ID for the device.

Upon receiving the DBIRTH message, the primary host application can build out the proper metric structure and set the Sparkplug device to online.

From then on, all subsequent metrics are published to the primary host application on a Report by Exception (RBE) basis using the DDATA message format.

If at any time the Sparkplug device cannot provide real-time information, a DDEATH message will be published. This will inform the primary host application that all metric information associated with that Sparkplug fevice be set to STALE data quality.

Conclusion

In summary, this article provided an explanation of MQTT Sparkplug’s operational behavior, shedding light on the complex mechanisms essential for effective IIoT communication.

We hope you enjoyed our 7-part series on MQTT Sparkplug, which gives you a detailed walkthrough of the features, functionality, and benefits of using Sparkplug in your IIoT architecture.

If you would like to discuss your specific project and get answers to your questions about MQTT Sparkplug, please contact us today.

Additional Reading

• Publish/Subscribe vs. Poll/Response

• Understanding MQTT Sparkplug Topic Namespace in IIoT Architectures

• Exploring MQTT Sparkplug Session State Management in IIoT Communication

• Implementing UNS with MQTT Sparkplug