What Is Sparkplug B? MQTT Topic, State, and Payload Rules

Sparkplug B defines how compliant MQTT clients name topics, express session state, and encode metric data. It does not replace MQTT. It adds a specified structure for communication among Sparkplug Edge Nodes, attached devices, and Sparkplug Host Applications in SCADA and IIoT systems (Eclipse Sparkplug 3.0 specification).

TL;DR: Sparkplug B uses the spBv1.0 namespace, defined message types, birth and death messages, and Google Protocol Buffer payloads. Birth messages establish an edge node's or device's metric model for the current session. Death messages let host applications mark affected metrics stale when that state ends.

What Is Sparkplug B?

Sparkplug B is the payload encoding defined by the Eclipse Sparkplug specification for MQTT-based SCADA and IIoT communication. The specification covers three connected concerns: an MQTT topic namespace, MQTT session-state management, and the payload carried by Sparkplug messages.

The B identifies the Sparkplug B encoding scheme. In a topic, spBv1.0 identifies that scheme and its payload version. The Sparkplug 3.0 specification governs the wider topic and session behavior while retaining spBv1.0 as the namespace token for Sparkplug B payloads.

How Is the Sparkplug B Topic Namespace Structured?

Sparkplug edge-node and device traffic follows this structure:

namespace/group_id/message_type/edge_node_id/[device_id]

For Sparkplug B, namespace is spBv1.0. The group_id logically groups edge nodes. The combination of group_id and edge_node_id identifies an edge node within the MQTT infrastructure. The optional device_id identifies a device attached, physically or logically, to that node.

Device topics include device_id for DBIRTH, DDEATH, DDATA, and DCMD. Node topics omit it for NBIRTH, NDEATH, NDATA, and NCMD. The specification also defines STATE messages for Sparkplug Host Application state (Eclipse Sparkplug 3.0 specification).

What Do the Sparkplug Message Types Mean?

Sparkplug assigns a purpose to each message type:

NBIRTH and DBIRTH establish node and device metrics. NDATA and DDATA update those metrics. NCMD and DCMD carry commands addressed to a node or device. NDEATH and DDEATH end the corresponding online state. STATE reports a Sparkplug Host Application's state.

These names are protocol terms, not suggested labels. Their placement in the topic tells a compliant client how to interpret the accompanying payload.

How Do Birth, Death, and Session State Work?

A Sparkplug session begins after an edge node establishes an MQTT connection and publishes NBIRTH. NBIRTH describes the edge node's metrics and current values. DBIRTH messages then establish the metrics and current values for attached devices. Data messages follow the birth sequence for that session.

NDEATH identifies the end of the edge node's session. The edge node registers NDEATH as the Will Message in its MQTT CONNECT packet, allowing the MQTT server to publish it if the connection is lost without a graceful disconnect. For an intentional disconnect, the edge node publishes NDEATH before ending the connection.

When a host application receives the matching NDEATH, the specification directs it to mark the edge node's metrics and the associated device metrics stale. DDEATH serves the device-level case: it tells host applications that the device is no longer providing current values through its edge node.

Birth and death are therefore session-state messages with defined effects. They do not, by themselves, prove anything about the physical health of a sensor beyond the state represented by the Sparkplug client and its MQTT session.

What Does a Sparkplug B Payload Contain?

Sparkplug B payloads use Google Protocol Buffers. The top-level payload definition includes a timestamp, a list of metrics, a sequence field, a UUID field, and an optional binary body. Which fields must appear depends on the message type.

A metric can include a name, alias, timestamp, datatype, value, and defined metadata or property fields. Birth messages establish metric definitions and current values. Later data and command messages can refer to metrics by alias when aliases were declared in the birth message.

The schema also defines datasets, templates, historical and transient flags, explicit null values, and file or byte data. These are payload capabilities. The specification does not attach a universal performance result, bandwidth percentage, cost outcome, or implementation recommendation to their use.

Frequently Asked Questions

How does Sparkplug B relate to MQTT?

Sparkplug B uses MQTT as its base messaging technology. The Sparkplug specification defines the topic namespace, message types, session-state behavior, and payload encoding used by compliant edge nodes and host applications.

What is the Sparkplug B topic namespace?

Sparkplug edge-node and device topics use namespace/group_id/message_type/edge_node_id/[device_id]. For Sparkplug B payloads, the namespace token is spBv1.0. Device-level topics include the device ID; node-level topics do not.

What are the Sparkplug message types?

NBIRTH, NDEATH, NDATA, and NCMD apply to edge nodes. DBIRTH, DDEATH, DDATA, and DCMD apply to devices. STATE carries Sparkplug Host Application state.

What do Sparkplug birth and death messages mean?

NBIRTH and DBIRTH establish the metrics and current values for an edge node and its devices during a Sparkplug session. NDEATH and DDEATH tell host applications to mark the affected metrics stale. An edge node registers NDEATH as its MQTT Will Message.

What is in a Sparkplug B payload?

Sparkplug B uses Google Protocol Buffers. Its top-level payload can carry a timestamp, metrics, a sequence field, a UUID, and a binary body. Metrics can carry names or aliases, timestamps, datatypes, values, and defined metadata fields.

Conclusion

Sparkplug B gives MQTT traffic a specified topic namespace, message vocabulary, session-state model, and payload schema. Its core sequence is straightforward: birth messages establish the metric model, data and command messages use that model, and death messages end the represented online state. Those are the claims supported here; deployment outcomes and selection advice require separate evidence.