What Is Sparkplug B? The MQTT Spec for Industrial IIoT Explained
Sparkplug B explained for controls engineers — the standardized MQTT topic namespace, Protobuf payloads, birth/death certificates, and the Unified Namespace.
Sparkplug B is an open specification — originally developed by Cirrus Link Solutions and now stewarded by the Eclipse Foundation — that adds a standardized topic namespace, Google Protocol Buffers (Protobuf) payload encoding, and a session-state lifecycle (birth/death certificates) on top of plain MQTT 3.1.1. It is the dominant industrial IIoT messaging standard for moving PLC and edge-device data from the shop floor to historians, SCADA, and cloud applications over a single MQTT broker.
Introduction: Why Controls Engineers Need to Understand Sparkplug B
Plain MQTT is a lightweight, publish-subscribe transport that has been popular in consumer IoT for years. The problem for industrial deployments is that MQTT, by itself, says nothing about how to structure topics, what format to put in the payload, or how a subscriber knows whether the data it just received is fresh or stale from a device that went offline two hours ago. Every vendor solved those problems differently, which produced integration nightmares on the factory floor.
Sparkplug B solves all three problems with a single open specification. It defines a rigid topic hierarchy, mandates Protobuf-encoded payloads with rich metadata, and requires every MQTT edge node to publish a birth certificate at startup and a death certificate when it disconnects. The result is a self-describing, interoperable data stream that any conforming application can consume without vendor-specific adapters.
The specification reached version 3.0.0 in November 2022 under the Eclipse Sparkplug Working Group, making it a fully community-governed open standard. Understanding Sparkplug B is increasingly a baseline competency for controls engineers working on IIoT integration, Unified Namespace (UNS) architectures, and digital transformation projects.
What Is Sparkplug B?
Sparkplug B defines three things that plain MQTT deliberately leaves open:
- A mandatory topic namespace — every message lands on a deterministic, machine-parseable topic path.
- A standardized payload format — Google Protobuf encodes every tag value alongside its engineering metadata.
- A session-state lifecycle — birth and death certificates tell every subscriber exactly when a device is online, publishing live data, and when it is not.
The specification was first released by Cirrus Link Solutions (the company behind Ignition's MQTT modules) as version 1.0 in 2016. Version 2.2 formalized the spBv1.0 topic prefix that is still in production today. In 2022, Eclipse Foundation published version 3.0.0, opening governance to the broader industrial community.
Sparkplug B runs on top of MQTT 3.1.1 (with MQTT 5 support under active discussion in the working group). It does not replace MQTT; it constrains how MQTT is used so that any Sparkplug-compliant broker, publisher, or subscriber can interoperate without bespoke configuration.
Key Terms at a Glance
| Term | Sparkplug B Meaning |
|---|---|
| EoN (Edge of Network) Node | The software agent (often on a gateway or PLC edge module) that manages one or more devices and publishes their data |
| Device | A downstream field device — a PLC, sensor, drive — that the EoN Node represents |
| DCMD / NCMD | Device Command / Node Command — messages sent to the edge from the SCADA or application tier |
| Metric | A single named data point (tag) with value, timestamp, data type, and optional properties |
| Primary Application (PA) | The authoritative consuming application — typically a SCADA or historian — that issues STATE messages and tracks session state |
| spBv1.0 | The current production topic prefix, indicating Sparkplug B version 1.0 namespace |
Why Plain MQTT Is Not Enough for Industrial Use
MQTT was designed for constrained devices sending small payloads over unreliable networks. It is excellent at that job. What it does not specify:
- No topic structure — Two vendors publishing motor speed might use
plant1/motor42/speedandsensors/RPM/M42respectively. Neither is wrong; both are incompatible. - No payload schema — The payload is an opaque byte array. Without out-of-band documentation, a subscriber cannot know whether
0x41 0x42is ASCII, a 16-bit integer, or a float. - No device state awareness — MQTT's Last Will and Testament (LWT) can signal disconnection, but it carries no structured information about which tags were being published or what their last-known values were.
- No timestamp or quality metadata — A value of
72.4tells you nothing about when it was sampled or whether the source device flagged it as uncertain.
These gaps are manageable in small consumer IoT deployments. In an industrial plant with hundreds of PLCs, drives, and meters publishing thousands of tags, the lack of standards produces an unmaintainable tangle of custom parsers. Sparkplug B closes all four gaps explicitly.
For a deeper look at how MQTT compares at the transport level, see MQTT vs Sparkplug B.
The Three Pillars of Sparkplug B
Pillar 1 — Standardized Topic Namespace
Every Sparkplug B message is published to a topic that follows this exact structure:
spBv1.0 / {Group_ID} / {Message_Type} / {Edge_Node_ID} / [{Device_ID}]
spBv1.0— Literal namespace prefix; identifies the message as Sparkplug B.Group_ID— A logical grouping, typically a site, plant area, or logical cluster (e.g.,PackagingLine3).Message_Type— One of a fixed set:NBIRTH,NDEATH,NDATA,DBIRTH,DDEATH,DDATA,NCMD,DCMD, orSTATE.Edge_Node_ID— The identifier of the EoN Node (e.g.,Gateway_01).Device_ID— Present only for device-level messages (e.g.,ConveyorPLC).
Concrete examples:
| Topic | Meaning |
|---|---|
spBv1.0/PackagingLine3/DBIRTH/Gateway_01/ConveyorPLC |
ConveyorPLC is publishing its birth certificate (full tag list) |
spBv1.0/PackagingLine3/DDATA/Gateway_01/ConveyorPLC |
ConveyorPLC is publishing changed tag values |
spBv1.0/PackagingLine3/DDEATH/Gateway_01/ConveyorPLC |
ConveyorPLC has gone offline |
spBv1.0/PackagingLine3/DCMD/Gateway_01/ConveyorPLC |
SCADA is writing a value to ConveyorPLC |
Because every topic follows this pattern, any subscriber can filter with a single wildcard — spBv1.0/PackagingLine3/# — and receive all data from that line, knowing exactly which device each message originated from without parsing the payload.
Pillar 2 — Protocol Buffers Payload Encoding
Sparkplug B payloads are Google Protocol Buffers (Protobuf) binary messages. The specification defines a .proto schema that every Sparkplug B publisher and subscriber must use. A payload carries:
- A timestamp (Unix epoch milliseconds) for when the payload was assembled
- One or more Metrics — each metric has:
name— the tag path (e.g.,Conveyor/Speed_RPM)alias— a 64-bit integer alias assigned at birth to reduce repeated string overhead in subsequent DDATA messagestimestamp— when this specific tag value was sampleddatatype— explicit type enum (Int32, Float, Boolean, String, Dataset, Template, etc.)value— the actual value, typed to the declared datatypeis_historical— flag indicating a backfilled/buffered valueis_transient— flag for a value that should not be storedproperties— extensible key-value metadata (engineering units, min/max, description)
Because the schema is defined in the specification rather than agreed bilaterally between vendors, any Sparkplug-aware application can decode any Sparkplug B payload without configuration.
Compared to JSON, Protobuf is significantly more compact and faster to serialize/deserialize — an important consideration when an edge gateway is publishing hundreds of tag changes per second. In benchmarks published by the Sparkplug Working Group, Protobuf payloads run roughly 3-10x smaller than equivalent JSON for typical industrial tag sets.
Pillar 3 — Birth and Death Certificates
This is the pillar that makes Sparkplug B genuinely different from any ad-hoc MQTT convention, and the one most worth understanding deeply from the perspective of a controls engineer.
Birth certificates (NBIRTH / DBIRTH) are published immediately when an EoN Node or Device comes online and establishes a session with the MQTT broker. The birth certificate is a complete snapshot of the node's or device's entire tag database at that moment — every metric, its current value, its datatype, its properties, and its alias mapping.
What does your tag database look like in a DBIRTH?
Imagine a PLC program with 40 tags — motor speeds, temperatures, setpoints, alarm bits. When the Sparkplug edge agent starts up and connects to the broker, it publishes a DBIRTH payload containing all 40 metrics. Each metric carries:
- Its full string name as it appears in the PLC tag database (e.g.,
Motor1/SpeedFeedback_RPM) - Its initial value read directly from the PLC at birth time
- Its datatype (Float, Int16, Boolean, etc.)
- An alias integer — a compact numeric ID (e.g.,
1,2,3) that will substitute for the full string name in all subsequent DDATA messages to save bandwidth - Any engineering unit properties you configured (e.g.,
engUnit = "RPM",engLow = 0,engHigh = 1800)
Why this matters for state-from-the-PLC: Any application that subscribes to the broker after the PLC was already running can immediately request a rebirth (via NCMD with a Node Control/Rebirth metric set to true) and receive the complete current state of every tag in one message. There is no need to poll the PLC, no stale cache problem, and no ambiguity about data types.
Death certificates (NDEATH / DDEATH) are published when the EoN Node or Device disconnects — either cleanly or by timeout. Critically, the NDEATH is configured as MQTT's Last Will and Testament (LWT) when the MQTT session is established. This means the broker publishes the NDEATH automatically even if the edge node crashes, loses network, or is powered off without a clean shutdown. Every downstream application immediately knows the data is no longer live.
This birth/death lifecycle is what makes Sparkplug B a stateful protocol in a way that plain MQTT is not. Subscribers always know whether the data they hold is current, and they always have a complete tag list for every device without any side-channel configuration exchange.
Sparkplug B vs Plain MQTT: A Direct Comparison
| Feature | Plain MQTT | Sparkplug B |
|---|---|---|
| Topic structure | User-defined, no standard | Mandatory spBv1.0/Group/MsgType/EoN/Device |
| Payload format | Any format (JSON, CSV, raw bytes) | Protobuf, per published .proto schema |
| Device state | LWT (optional, unstructured) | Mandatory birth/death certificates |
| Tag metadata | None (out-of-band) | Embedded in every birth payload |
| Rebirth on reconnect | Not defined | Mandatory NBIRTH/DBIRTH on every session |
| Interoperability | Vendor-specific adapters required | Any conforming implementation works |
| Command messages | User-defined | Standardized NCMD / DCMD message types |
For a full protocol-by-protocol comparison including OPC UA, see Sparkplug vs OPC UA and our PLC communication protocols guide.
Report by Exception: How Sparkplug B Reduces Bandwidth
Report by Exception (RBE) is the principle that an edge node publishes a tag value only when that value changes, not on a fixed polling interval. Sparkplug B builds RBE in as the default behavior for DDATA messages.
After the birth certificate establishes the full tag snapshot, subsequent DDATA payloads contain only the metrics that changed since the last publish. If your 40-tag PLC typically has 3-5 tags changing at any given scan, DDATA messages carry 3-5 metrics instead of 40. Across hundreds of PLCs, this dramatically reduces broker throughput and network load compared to a polled scan-all approach.
RBE also works with the alias system. Once the birth certificate maps Motor1/SpeedFeedback_RPM to alias 7, every DDATA message carrying that tag uses the integer 7 instead of the full string — further compressing payloads.
The combination of RBE and Protobuf encoding is why Sparkplug B scales to thousands of edge nodes on commodity MQTT brokers where a polled JSON approach would saturate the broker at a fraction of that scale.
Where Sparkplug B Sits in a Unified Namespace
The Unified Namespace (UNS) is an architectural pattern — popularized by Walker Reynolds and widely adopted in industrial IIoT — in which a single MQTT broker acts as the central "single source of truth" for all operational data in a plant or enterprise. Every edge node publishes to the UNS; every consuming application subscribes from it.
Sparkplug B is the most widely used payload and topic standard for implementing a UNS because it provides the structure the UNS pattern requires:
- Self-describing data — any new application subscribing to the broker can discover what data exists and what it means without consulting external documentation, because the birth certificates carry full tag metadata.
- Consistent namespace — the
spBv1.0/Group/EoN/Devicehierarchy maps naturally to a plant hierarchy (site → area → cell → device). - Device lifecycle awareness — the UNS always reflects which devices are currently online and publishing live data vs. stale last-known values.
In a mature UNS implementation, Sparkplug B edge nodes publish PLC data from the OT layer, while IT applications (historians, MES, cloud analytics) subscribe and consume without any point-to-point OPC UA or proprietary driver connections. For a deeper guide on connecting PLCs to IIoT architectures, see the IIoT and PLC integration guide.
Sparkplug B and OPC UA in the Same Architecture
Sparkplug B and OPC UA are complementary rather than competing. A common pattern:
- OPC UA handles deterministic, request-response communication within the OT layer — a SCADA server reading a PLC address space in real time.
- Sparkplug B over MQTT handles the publish-subscribe, report-by-exception data flow from OT to the UNS broker and up to IT/cloud applications.
The Eclipse Foundation's UA-over-MQTT profile and OPC Foundation's joint work with the Sparkplug Working Group are aligning these standards further, but for most practical IIoT implementations they serve different layers of the architecture.
Current Sparkplug Version and Governance
The current specification is Sparkplug 3.0.0, published by the Eclipse Sparkplug Working Group in November 2022. Key changes from 2.2:
- Formal open-governance process under Eclipse Foundation
- Clarified conformance levels (Sparkplug Aware, Sparkplug Compliant, Sparkplug Certified)
- Explicit compliance test specifications to enable third-party certification
- Retained the
spBv1.0topic prefix for backward compatibility with 2.2 deployments
The spBv1.0 prefix refers to the original Cirrus Link versioning; the "B" in Sparkplug B distinguishes the current specification from the earlier, deprecated Sparkplug A variant. Current Eclipse documentation and tooling all target the spBv1.0 namespace regardless of the 3.0.0 governance version.
Major broker vendors with production Sparkplug support include HiveMQ, EMQX, and Cirrus Link's Chariot MQTT Server. Edge tooling includes Ignition's Sparkplug modules, the open-source Eclipse Tahu reference implementation, and a growing ecosystem of gateway firmware from vendors such as Sepasoft, Inductive Automation, and Canary Labs.
For broader protocol context, the OPC UA complete guide covers how OPC UA and MQTT-based approaches fit together in modern IIoT architectures.
Frequently Asked Questions
What is Sparkplug B?
Sparkplug B is an open specification maintained by the Eclipse Foundation that adds a standardized MQTT topic namespace (spBv1.0/Group/MessageType/EdgeNode/Device), Protocol Buffers payload encoding, and a birth/death certificate session lifecycle on top of MQTT 3.1.1. It enables interoperable, self-describing industrial IIoT data exchange between PLCs, edge gateways, historians, and cloud applications.
What is the difference between MQTT and Sparkplug B?
MQTT is a transport protocol — it defines how messages are delivered between publishers and subscribers but says nothing about topic naming, payload format, or device state. Sparkplug B is a specification built on MQTT that mandates a specific topic hierarchy, Protobuf payload schema, and birth/death certificate lifecycle. Using Sparkplug B without MQTT is not possible; using MQTT without Sparkplug B is common but produces non-interoperable, vendor-specific integrations.
What is a birth certificate in Sparkplug B?
A birth certificate (DBIRTH for devices, NBIRTH for edge nodes) is a Sparkplug B message published immediately when a device or edge node connects to the MQTT broker and establishes a live session. It contains every metric (tag) in the device's tag database along with current values, data types, alias mappings, and engineering metadata. Any subscribing application — including ones that connect after the device was already running — can request a rebirth at any time to receive a fresh complete tag snapshot. The corresponding death certificate (DDEATH/NDEATH), configured as MQTT Last Will and Testament, is published automatically by the broker if the edge node disconnects for any reason.
Do you need Ignition to use Sparkplug B?
No. Ignition (by Inductive Automation) was the platform that popularized Sparkplug B through its MQTT Transmission and MQTT Engine modules, but the specification is open and platform-independent. Conforming implementations exist in the Eclipse Tahu open-source reference library (Java, Python, C), HiveMQ's Sparkplug extension, EMQX's built-in support, and a range of third-party gateway firmware. Any application that implements the published .proto schema and follows the topic and lifecycle rules of the specification is a valid Sparkplug B client.
