MQTT Sparkplug B

MQTT Sparkplug B is a specification that makes MQTT production-ready for industrial and SCADA use cases. MQTT itself is a lightweight publish-subscribe protocol – but without additional conventions, a receiver has no way of knowing whether a data point is current, complete, or stale. Sparkplug B solves exactly this problem: it standardizes the topic namespace, payload structure, and most importantly the state management of nodes and devices.

The Core Principle: Birth and Death Instead of Arbitrary Topics

The defining mechanism in Sparkplug B is the distinction between Birth Certificates and Death Certificates.

A Birth Certificate is published when an edge node or device comes online. It contains the complete list of available data points including metadata – subscribers immediately know what to expect.

A Death Certificate is triggered when a connection is lost, via the MQTT Last Will mechanism. All subscribers immediately know: the data from this node is no longer trustworthy.

This is precisely why Sparkplug B is often described as "stateful MQTT for OT" – state is explicit, not implicit.

Topic Namespace and Message Types

Sparkplug B defines a fixed topic structure: spBv1.0/<group_id>/<message_type>/<edge_node_id>/<device_id>. The device_id is optional and only included when a message concerns a specific device under an edge node.

The most relevant message types in practice are NBIRTH and NDEATH for edge node state, DBIRTH and DDEATH for device state, NDATA and DDATA for payload and telemetry, and NCMD and DCMD for commands such as triggering a rebirth.

Why Sparkplug Is More Than Topic Standardization

Sparkplug B also standardizes the payload structure: which fields exist, how metrics are described, and how metric aliases and sequence numbers ensure efficient and robust transmission. Receivers gain consistency across vendor boundaries – without building custom parsing logic for every publisher.

Typical Use Cases in Manufacturing

Sparkplug B is used when an edge gateway or IoT gateway collects data from PLCs, Modbus, or OPC UA sources and publishes it in a standardized format over MQTT – with multiple systems such as historian, SCADA, and analytics consuming in parallel without the publisher needing to know about them.

It is also a common building block in Unified Namespace (UNS) architectures, because topics and state are clearly defined. And it solves a classic OT problem: the online/offline state of a device is immediately visible – not only after 30 minutes of missing data points.

For cloud-native MES platforms that want to integrate machine data without heavy on-premise middleware, Sparkplug B is a relevant component: it reduces integration effort at the edge because structure and state are standardized – instead of building custom adapter logic for every machine source.

Advantages Over Plain MQTT

Compared to unstructured MQTT usage, Sparkplug B delivers three concrete advantages: interoperability through unified topic and payload standards, state awareness through the Birth/Death mechanism, and scalability through the publish-subscribe model without consumer-specific custom logic.

Common Mistakes

Using Sparkplug topics without correctly implementing Birth and Death breaks the state management – the key advantage over plain MQTT disappears. Without a clear group_id strategy, a Unified Namespace quickly becomes chaotic. And username/password authentication alone is not sufficient in OT/IT networks – TLS, network segmentation, and granular broker permissions are required.

FAQ

What is the difference between MQTT and Sparkplug B? MQTT is the transport protocol. Sparkplug B is a specification built on top of MQTT that standardizes how topics are structured, how payloads are built, and how device states are communicated. MQTT without Sparkplug is flexible but lacks shared semantics across systems.

When should Sparkplug B be used instead of OPC UA? Both solve the OT data integration problem but with different strengths. OPC UA excels at complex information models, direct machine-to-machine communication, and established industry standards. Sparkplug B is stronger for lightweight, broker-based architectures with many sources and consumers. In practice, they complement each other: OPC UA at the device, Sparkplug B for edge-to-cloud transport.

Is Sparkplug B an official standard? Yes. Sparkplug B is being developed as a formal standard under the Eclipse Specification Process (currently Sparkplug 3.0). The reference implementation is Eclipse Tahu.

Does Sparkplug B work with any MQTT broker? In principle, yes, since Sparkplug builds on standard MQTT. However, some brokers natively support Sparkplug-specific features such as state management and Sparkplug-aware routing – which simplifies operations and debugging.