What is Sparkplug B?
Sparkplug B is a specification created by Arlen Nipper (co-inventor of MQTT) and published as an open Eclipse Foundation standard under the Eclipse Tahu project. It defines how MQTT should be used in industrial IIoT environments, filling the gaps that MQTT's intentional flexibility leaves open: how topics should be structured, how payloads should be encoded, and how device connection state should be managed across the broker network.
MQTT was designed to be protocol-agnostic by design. The MQTT specification deliberately leaves topic naming, payload format, and application-level state management to the implementer. This flexibility made MQTT popular across many industries, but it created a fragmentation problem for industrial deployments: two devices both implementing MQTT could publish to completely different topic structures with incompatible payload formats, requiring custom integration code to reconcile them. Every vendor defined its own conventions, and every new device integration became its own project.
Sparkplug B solves this by defining a single set of conventions that any device or application claiming Sparkplug B compatibility must follow. A SCADA system or analytics platform that supports Sparkplug B can discover and subscribe to any Sparkplug B compliant device or gateway immediately, without any prior knowledge of that device's configuration, because all Sparkplug B devices follow the same topic structure and payload schema.
Sparkplug B is not a new protocol. It runs on top of MQTT 3.1.1 or MQTT 5.0 over standard TCP/IP. It does not replace MQTT; it defines how to use MQTT. Any standard MQTT broker (HiveMQ, EMQX, Mosquitto, N3uron's built-in broker) can carry Sparkplug B messages without modification. Sparkplug-aware applications add specific handling for birth/death messages and Protobuf payload decoding on top of normal MQTT client behavior.
Plain MQTT vs Sparkplug B: what changes
Understanding what Sparkplug B adds requires a clear picture of what plain MQTT leaves undefined and why that matters for multi-vendor industrial environments.
Flexible, but not interoperable by default
- Topic structure is entirely user-defined. Vendor A publishes to factory/line1/temp; Vendor B publishes to Plant_Floor/L1/Temperature_C. Both are valid MQTT.
- Payload format is undefined. Could be raw bytes, JSON, XML, CSV, or any proprietary binary format. Consumers must know the format in advance.
- No device state management. No standard way to know whether a device is online, what metrics it publishes, or what types those metrics are.
- No metric metadata. A value of 72.4 arrives with no information about what it represents, its engineering units, or its data type.
- New subscribers receive no data until the next change event if no retained messages are configured.
Standardized, self-describing, discoverable
- Topic structure is defined by the spec: spBv1.0/{group}/{msg_type}/{node}/{device}. Every Sparkplug B implementation uses this exact structure.
- Payload is always Google Protocol Buffers (Protobuf), a compact binary format with defined fields for name, data type, value, engineering units, and timestamp.
- Device state is managed through birth and death certificates. Subscribers always know whether a device is online and what metrics it will publish.
- Every metric is self-describing. The payload carries the tag name, data type (Float32, Int32, String, Boolean...), and metadata alongside the value.
- Birth certificates deliver the current state of all metrics immediately on subscription, so new consumers instantly have a complete picture.
The Sparkplug B topic namespace
The Sparkplug B topic namespace is the foundation of the specification's interoperability. Every Sparkplug B message is published to a topic that follows a fixed five-element structure:
The Group ID and Edge Node ID are user-configurable UTF-8 alphanumeric strings (forward slashes, plus signs, and hash symbols are reserved and cannot be used). The Message Type element is not user-configurable: it is one of nine values defined by the Sparkplug B specification. This is what allows a Sparkplug-aware broker or application to immediately classify any incoming message by type without parsing the payload.
The nine Sparkplug B message types
The message type element in the topic is the mechanism Sparkplug B uses to define different message behaviors within the same namespace. Each type has a specific purpose in the device lifecycle and state management model:
| Message type | Direction | Purpose |
|---|---|---|
| NBIRTH | Edge → Broker | Birth certificate for an Edge of Network (EoN) node. Published as the first message when a node connects or reconnects. Contains the complete list of all metrics the node will publish, their data types, engineering units, and initial values. |
| NDEATH | Broker (LWT) | Death certificate for an EoN node. Pre-configured as a Last Will and Testament message when the node connects. The broker publishes it automatically if the node disconnects ungracefully. |
| NDATA | Edge → Broker | Data message from an EoN node. Published after NBIRTH whenever a metric value changes (report by exception). Contains only the metrics that changed, not the full metric list. |
| DBIRTH | Edge → Broker | Birth certificate for a device behind an EoN node. Published when the EoN node establishes communication with a connected device. Contains the device's full metric list with types and initial values. |
| DDEATH | Edge → Broker | Death certificate for a device. Published by the EoN node when a connected device goes offline or loses communication, signaling to all subscribers that this device's data should no longer be considered current. |
| DDATA | Edge → Broker | Data message for a device. Published by the EoN node on behalf of a connected device when device metric values change. Same report-by-exception behavior and metric aliasing as NDATA. |
| NCMD | Host → Edge | Command message for an EoN node. Published by a Primary Host or application to send a write command to the node. Allows bidirectional communication. |
| DCMD | Host → Edge | Command message for a device behind an EoN node. The EoN node receives the command and translates it into the appropriate device-level write using the device's native protocol. |
| STATE | Host ↔ Broker | Primary Host Application state. Published by the Primary Host Application to signal its online/offline status to all EoN nodes. |
The Protobuf payload: self-describing data
The Sparkplug B payload format is defined using Google Protocol Buffers (Protobuf), a compact binary serialization format. This is one of the most practically significant differences between plain MQTT and Sparkplug B for industrial deployments.
A plain MQTT JSON payload carrying a temperature reading might look like: {"value": 72.4}. This tells the consumer one thing: a number. The consumer must already know what this topic publishes, what units the value is in, and what data type to expect.
A Sparkplug B Protobuf payload for the same reading carries: the metric name ("Temperature_degC"), an integer alias for compact encoding, a millisecond-precision timestamp, the data type (Float), the value (72.4), historical and transient flags, and properties including engineering units and range limits. The metric is completely self-describing.
Protobuf's binary encoding is also significantly more compact than JSON for the same data, which is important for deployments on cellular networks or satellite links where bandwidth is expensive. The metric aliasing feature adds further efficiency: after the initial NBIRTH establishes the full metric name, subsequent NDATA and DDATA messages can reference each metric by a short integer alias rather than the full string name, eliminating the largest overhead in repetitive telemetry messages.
Birth and death certificates: the state management model
The birth and death certificate mechanism is Sparkplug B's most important contribution to industrial MQTT deployments. It solves a fundamental problem: in a pub/sub architecture, consumers have no inherent knowledge of what devices exist, what they publish, or whether they are currently connected.
The result: a fully self-maintaining namespace. With birth and death certificates, the Sparkplug B namespace is always current. Every subscriber always knows which nodes and devices are online, what metrics they publish, and what the current value of each metric is. No polling, no out-of-band device registry, no manual configuration at the consumer. Add a new device, and the namespace automatically reflects it when the EoN node publishes the DBIRTH. Remove a device, and the DDEATH propagates immediately.
Edge of Network (EoN) nodes: the bridge for legacy devices
Most industrial devices do not speak MQTT natively. PLCs communicate via Modbus, EtherNet/IP, or proprietary vendor protocols. Historians expose OPC HDA. SCADA systems use OPC DA. An EoN node is the Sparkplug B component that bridges these devices into the Sparkplug namespace.
The EoN node connects to its downstream devices using whatever protocol they support: OPC UA client, Modbus TCP master, EtherNet/IP scanner, or any other. It collects the device data, translates it into Sparkplug B metrics with proper types and metadata, and publishes the birth certificate and subsequent data messages on behalf of each device. From the MQTT broker's perspective and from every subscriber's perspective, the device appears as a Sparkplug B entity with full birth certificate discovery and report-by-exception behavior, regardless of the underlying protocol.
This is why edge platforms like N3uron and Cogent DataHub are so important to Sparkplug B deployments in brownfield environments. They serve as EoN nodes for legacy OT infrastructure, translating decades of proprietary OT protocols into Sparkplug B without any changes to the underlying devices.