Sparkplug B: Namespace, Birth and Death Certificates, Metric Aliases and When to Use It

Sparkplug B is the open specification, maintained by the Eclipse Foundation, that defines how to use MQTT in industrial environments: it fixes the topic structure, types the payload with declared metrics and solves state management through birth and death certificates, so any consumer knows at all times whether a value is live or stale. It is the reference semantics of the Unified Namespace. In this article we look at exactly what it defines, how its namespace, birth and death certificates and metric aliases work, and when it is worth using over plain MQTT.

What Sparkplug B is

MQTT was born deliberately agnostic: a message is a topic and a payload of bytes, and the protocol holds no opinion about what is inside. That sobriety made it universal, but it left every industrial project inventing its own scheme: how to name topics, how to encode values, how to know whether a device is still connected. Sparkplug was created to close that gap with a common answer, and revision B of its payload is the one industry adopted.

Today the specification lives at the Eclipse Foundation as an open project, with published versions and a compatibility programme for implementations. In one sentence: Sparkplug B defines what things are called (the topic namespace), what shape they have (a binary payload with typed metrics, encoded with Protocol Buffers) and how state is managed (birth and death certificates) when MQTT is used for industrial data.

What it adds to plain MQTT

• Interoperability out of the box. A gateway and a platform that both speak Sparkplug B understand each other without agreeing anything further: the topic structure and payload format are already fixed by the specification.
• Strong typing. Each metric declares its type (integer, float, boolean, text) and can carry metadata and properties such as the engineering unit. The entire family of free-text interpretation errors disappears.
• Known state. The birth and death certificate mechanism makes the state of every node and device part of the protocol, not a convention each project reinvents.
• Link efficiency. A compact binary payload, report by exception and numeric metric aliases cut traffic compared with repetitive JSON over plain MQTT.

The underlying comparison between pub/sub transport and OPC UA's client-server model is covered in OPC UA versus MQTT; here we focus on what Sparkplug B adds once MQTT has been chosen.

The namespace: topic structure

Sparkplug B fixes a five-part topic structure, always the same:

spBv1.0/<group_id>/<message_type>/<edge_node_id>/[device_id]

spBv1.0/valencia-planta/NDATA/gateway-linea-2
spBv1.0/valencia-planta/DDATA/gateway-linea-2/cnc-07

• spBv1.0 identifies the version of the Sparkplug namespace.
• group_id groups logically related nodes, for example a plant or an area.
• message_type declares what the message is: NBIRTH and NDEATH (birth and death of an edge node), DBIRTH and DDEATH (of a device attached to that node), NDATA and DDATA (data on change), NCMD and DCMD (commands towards the node or the device) and STATE (the state of host applications).
• edge_node_id identifies the edge node within the group, and the optional device_id identifies each device that node represents, for example each machine read by a single gateway.

Note that the Sparkplug hierarchy is one of infrastructure (group, node, device), not of business. The ISA-95-style semantic hierarchy (plant, area, line, machine) lives inside the metric names or in the layer that organises the Unified Namespace: the two coexist and complement each other.

Birth and death certificates: state management

Sparkplug B's most distinctive contribution is that it turns session state into first-class information. The sequence goes like this:

• On connecting, the edge node registers a last will with the broker carrying its death message (NDEATH) and publishes its birth certificate (NBIRTH): the complete list of its metrics with name, type, current value and alias. It then publishes a DBIRTH for each device it represents.
• During the session, it publishes only NDATA and DDATA with the metrics that change, referenced by their alias.
• If the node drops without saying goodbye, the broker publishes the NDEATH registered as its last will on its behalf. Every subscriber knows instantly that the node and its devices are now offline, and that their last values are stale information rather than live data.
• On reconnecting, a fresh NBIRTH re-establishes the full state. A sequence number in every message lets consumers detect losses and request a rebirth if something does not add up.

The practical consequence is enormous: an application connecting to the broker obtains the complete, current picture of the plant without polling anyone, and never mistakes a frozen value for a valid one. Over plain MQTT, that entire mechanism has to be designed, documented and maintained by hand.

Metric aliases and report by exception

In the NBIRTH, each metric declares a numeric alias alongside its readable name. From then on, data messages can refer to the metric by that alias alone: instead of repeating linea-2/cnc-07/husillo/temperatura in every publication, an integer travels. Combined with report by exception (after the birth, only metrics whose value changes travel) and the Protocol Buffers binary payload, the result is a protocol that is very frugal with bandwidth, designed for slow, metered or unstable links.

The price of that frugality is that the stream only makes sense as a whole: anyone wanting to interpret a DDATA needs to have seen the DBIRTH that declared the aliases. That is why Sparkplug B consumers lean on the state sequence from the previous section, and why it matters to choose brokers and tools that respect it.

When to use Sparkplug B and when not to

Sparkplug B clearly pays off when:

• There is more than one producer and more than one consumer. Specification-level interoperability avoids negotiating a format with every new piece of the system.
• State matters. If telling a live value from a frozen one is relevant (and on the shop floor it almost always is), birth and death certificates solve out of the box the part that is hardest to do well by hand.
• The link is slow, metered or unstable. Aliases, report by exception and the binary payload are designed for exactly that case.
• The project is going to grow. A Unified Namespace that starts with two machines and aims to cover the plant benefits from a stable contract from day one.

And there are cases where plain MQTT or another option may be enough:

• Small, closed integrations, with one producer and one consumer under the same team, where documented JSON is sufficient and a dependency on Sparkplug tooling adds nothing.
• Consumers that require a readable payload. Sparkplug's binary format needs decoding; if the whole consumption chain expects JSON, that translation piece has to be added and is worth weighing up.
• Data that is not telemetry in nature, such as files or complex transactions, which fit better in other channels.

Sparkplug B in practice with Captia Connect

At Captia Connect we work with MQTT as one of the core protocols of the acquisition layer: the edge reads PLCs, sensors, meters and SCADA systems in their native protocols (OPC UA, Modbus TCP, Modbus RTU over RS-485, among others), normalises the signals at source and publishes them securely towards the broker, with persistent local buffering so a network outage opens no gaps in the history. On that foundation, applying Sparkplug B semantics is the natural route when the project needs state management and interoperability with several platforms; the specific design is part of each plant's MQTT integration.

Frequently asked questions about Sparkplug B

If you are defining your plant's data layer and weighing up whether Sparkplug B fits, at Captia Connect we design and implement the MQTT integration and full OT/IT integration. The wider architectural context is in our industrial data platform guide.