What is the difference between MQTT and Sparkplug B?

MQTT is the transport protocol: it defines publish, subscribe and quality of service, but not what gets published. Sparkplug B is a specification built on MQTT that adds what industry needs: a fixed topic structure, a typed Protocol Buffers payload and a session lifecycle with birth and death certificates that make each node’s state explicit.

What are birth and death certificates?

The birth certificate (NBIRTH, plus a DBIRTH per device) is the message a node publishes on connecting, listing every metric with its type and initial value, which makes the system self-describing. The death certificate (NDEATH) is registered up front as the MQTT last will, so if the node drops it is the broker that announces the disconnection, with no consumer-side timeouts involved.

Is Sparkplug B required to build a Unified Namespace?

It is not mandatory. A Unified Namespace can be built with MQTT and a custom, human-readable topic hierarchy, and many installations run that way. Sparkplug B solves signal discovery, typing and dead-node detection out of the box, in exchange for a fixed topic structure and a binary payload that needs a decoder.

Can a PLC publish Sparkplug B directly?

Some recent controllers and edge devices include it, but in a plant with mixed equipment the usual pattern is an industrial gateway reading the PLC over OPC-UA or Modbus and acting as the Sparkplug edge node. That gateway builds the metric inventory, stamps timestamps, maintains the session and buffers data if the link drops, without modifying control logic.

What is Sparkplug B: definition and uses

Sparkplug B is an open Eclipse Foundation specification that defines how industrial devices publish data over MQTT: it fixes a topic namespace, a binary payload based on Protocol Buffers and a session lifecycle with birth and death certificates that make the state of every node explicit.

What it adds on top of MQTT

MQTT is deliberately agnostic: it defines how to publish and receive, not what is published or what it is called. Two plants can share a broker and remain incompatible, one sending JSON to plant/line1/temp and the other a bare number to L1/TT001/pv. Sparkplug B closes that gap with three decisions.

The first is the topic namespace. Every message follows the form spBv1.0/<group_id>/<type>/<edge_node_id>/[<device_id>], where the type comes from a closed set: NBIRTH and NDEATH for the lifecycle of an edge node, DBIRTH and DDEATH for each device behind it, NDATA and DDATA for values, and NCMD and DCMD for downward commands. The set is completed by STATE, which announces the availability of the primary host application and travels on its own topic. A consumer that knows nothing about the installation can still parse the structure, because the structure is part of the standard.

The second is the payload. Instead of free text, Sparkplug B encodes data with Protocol Buffers under a defined schema: every metric carries a name, a data type, its own timestamp and optional properties. Beyond the bytes saved against JSON, that means the receiver never has to guess whether a value is an integer, a float or a boolean.

The third is state, and it is both the least obvious and the most valuable.

Birth and death certificates

When an edge node connects to the broker it registers its NDEATH message up front as the MQTT last will and testament. From then on, if the node crashes, loses the network or powers off without saying goodbye, the broker itself publishes its death. No consumer timeout, no inferring absence from missing data: disconnection is an explicit event in the same stream as the values.

Immediately after connecting, the node publishes NBIRTH: a message listing every metric it will report, with its type and initial value, followed by a DBIRTH for each attached device. The result is a self-describing system: any consumer that subscribes learns which signals exist and what type they are, with no prior configuration or mapping tables. After birth, data messages may refer to each metric by a numeric alias rather than its full name, which keeps publications small.

A sequence number travels with the session messages so gaps and reordering can be detected, and a birth sequence number ties each NDEATH to the NBIRTH it belongs to, so a fast reconnection is never confused with the previous session. Sparkplug B also assumes report by exception: values are sent on change rather than every cycle, and current state is rebuilt from the birth certificate plus the stream that follows, not from retained broker messages.

Its role in the unified namespace

A Unified Namespace aims to keep the current state of the whole operation available in one place, so any new system can plug in without bespoke integrations. Plain MQTT provides the transport but leaves two questions open: how a newly arrived consumer learns what exists, and how it tells “the machine is stopped” apart from “the machine has said nothing for a while”. Sparkplug B answers both with the same mechanism: the birth certificate describes the inventory and the death certificate declares absence. That is why, in unified namespace architectures, Sparkplug usually covers the stretch from equipment to broker, while upper layers may keep consuming in freer formats.

Sparkplug B versus plain MQTT

The practical difference is contractual rather than technical. With plain MQTT you choose whatever topic hierarchy suits the site, usually ISA-95 inspired (enterprise, site, area, line, cell), and publish readable JSON that anyone can inspect with a basic client. It is flexible and easy to debug, but every installation invents its own dictionary and state has to be solved by hand with retained messages and heartbeats. Sparkplug B buys automatic discovery, typing and state, and pays with a fixed four- or five-level topic structure that forces the plant hierarchy into the group identifier, plus a binary payload that cannot be read without a decoder.

Neither option is universally better: the choice depends on how many independent consumers will exist and how much modelling discipline the organisation can sustain. What does not work is mixing both without criteria in the same namespace.

What it takes to consume Sparkplug B data

Subscribing to a Sparkplug topic and expecting to read a number does not work: the client must decode Protocol Buffers and, above all, keep state. A metric value is only interpretable together with its node’s birth certificate, which is where the name, the type and the alias-to-signal mapping live. A consumer that connects mid-session has none of that context, which is why the specification lets it ask the node to republish its birth through a control command. Any historian or analytics service hooked to a Sparkplug stream has to implement that negotiation; it is not optional.

Report by exception has a similar consequence: there is no traffic between changes, so silence is valid information rather than a fault. Timestamping also improves on classic polling, because each metric travels with the time the edge node stamped rather than the time of reception; in exchange, node clocks must be synchronised, typically over NTP, if events are to be correlated across equipment. Downstream, command messages make writing into the plant possible, which turns per-topic authorisation and the separation between data publishers and command issuers into a security design decision rather than a convenience.

On the equipment side, the Sparkplug speaker is rarely the PLC. Typically an industrial gateway reads the controller over OPC-UA or Modbus and acts as the edge node: it builds the metric inventory, stamps the timestamps, maintains the session and buffers locally while the link is down. Control logic is never touched.

Sparkplug B is a convention layer over MQTT and a common building block of the Unified Namespace in OT/IT convergence projects. The full architecture is developed in the OT/IT and Unified Namespace guide, and broker and topic-hierarchy deployment is the scope of MQTT integration.

What is Sparkplug B