What is the difference between Sparkplug B and plain MQTT?

MQTT is a transport: it moves opaque bytes between publishers and subscribers and prescribes nothing about topics or payloads. Sparkplug B adds the missing conventions — a defined topic namespace, a typed binary payload format, and birth/death session semantics — so compliant tools interoperate without custom integration code.

Is Sparkplug B required for a Unified Namespace?

No. It is one common option for the payload and state layer. Some UNS designs use structured JSON payloads on ISA-95-style topics instead, trading Sparkplug's compactness and built-in state model for human readability and easier ad-hoc consumption. What a UNS cannot skip is having one documented convention.

What happens when a device drops off the network?

The broker publishes the edge node's NDEATH — registered in advance as its MQTT last will — and consumers must mark all metrics from that node and its devices as stale. Fresh values resume with a new NBIRTH/DBIRTH. Consumers keep showing data, but flagged as no longer current.

Sparkplug B

MQTT moves bytes. Sparkplug B makes them mean something.

Sparkplug B is an open specification, maintained at the Eclipse Foundation, that defines how industrial devices should use MQTT: a fixed topic namespace, a compact Protocol Buffers payload encoding, and a session-state model built on birth and death certificates. It makes MQTT data self-describing and tells every consumer which publishers are online and which values are current.

How It Works

A fixed topic form, and messages that carry the protocol's logic.

spBv1.0/group/…

Topic form: spBv1.0/{group_id}/{message_type}/{edge_node_id}/[{device_id}] — the namespace is fixed by the specification, not invented per project.

NBIRTH / DBIRTH

An edge node or device comes online and declares its complete metric set: names, aliases, data types, engineering units.

NDATA / DDATA

Changes only — report by exception, with tiny alias-based payloads, because the birth certificate already declared everything.

NDEATH / STATE

The broker itself announces a lost node via its registered last will; consumers must mark those metrics stale instead of trusting the last value.

Strengths

Interoperability between compliant tools without custom parsing, low bandwidth on constrained networks, explicit types and units, and trustworthy online/stale semantics out of the box.

Limits

The topic namespace mirrors the network — groups, edge nodes, devices — not the business. Mapping into an ISA-95-shaped UNS is still your modeling work.

Binary

Payloads are Protobuf, not JSON. Generic MQTT consumers cannot read Sparkplug topics without a decoder — by design, not by accident.

Typical traps in real deployments.

Equating Sparkplug B with a UNS. It standardizes payloads and session state; it does not design your business hierarchy or governance.
Pointing plain MQTT/JSON consumers at Sparkplug topics and wondering why they show garbage.
Ignoring alias handling and rebirth: a consumer joining mid-stream must request a rebirth to learn the metric map, not guess.
Choosing group and node IDs casually — they are the top of your namespace, and renaming them later breaks every subscriber.

Related Concepts

Where Sparkplug B sits in the stack.

Sparkplug B is the payload-and-state layer many UNS deployments run on, and a clean fit with the Minimum Technical Requirements — edge driven, report by exception, open, lightweight. ISA-95 contributes the business hierarchy its device-centric topics lack, contextualization carries on where its units and properties stop, and reliable, freshness-aware data is one of the concrete markers AI readiness work checks. You can lint your own payloads and topics with the free Sparkplug B linter.