MQTT Sparkplug B Explained: Topics, Birth/Death and UNS (Video)

Sparkplug B is an open specification that sits on top of MQTT and tells every device and application how to use it for industrial data: a fixed topic structure, a typed binary payload, and birth and death messages so subscribers always know whether a value is live. Plain MQTT moves bytes; Sparkplug B makes those bytes mean the same thing to a PLC gateway, a SCADA system and a cloud historian from different vendors.

The specification is run by the Eclipse Foundation's Sparkplug working group. The current version is 3.0.0, and the Eclipse Foundation announced on 7 November 2023 that Sparkplug 3.0 had been published as the international standard ISO/IEC 20237. This guide explains the topic namespace and message types, how state awareness works, where Sparkplug fits in a unified namespace and next to OPC UA, and then hands over to a 4.0 Solutions video on the same subject.

What problem does Sparkplug B solve?

MQTT is a lightweight publish/subscribe protocol, now an OASIS standard in version 5.0. Clients connect to a broker, publish messages to topics, and subscribe to the topics they care about. It is efficient over poor networks and easy to scale, which is why it spread from oil and gas telemetry into IIoT. Our IIoT training guide shows where it sits in the data path from PLC to dashboard.

But MQTT deliberately says nothing about what is inside a message or how topics are named. Put three integrators on one site and you get three topic schemes and three JSON layouts. Worse, a subscriber cannot tell the difference between "the tank level has not changed" and "the gateway died an hour ago". Sparkplug B fixes both problems.

How the Sparkplug B topic namespace works

Every Sparkplug B topic has the same shape, defined in the Sparkplug 3.0.0 specification:

spBv1.0 / group_id / message_type / edge_node_id / device_id

• spBv1.0 is the namespace, fixed for Sparkplug B.
• group_id groups edge nodes, for example a site or a line.
• message_type is one of the defined types, such as NBIRTH or DDATA.
• edge_node_id is the gateway or edge device that talks MQTT.
• device_id (optional) is a device behind the edge node, such as a PLC.

A real topic might be spBv1.0/Bristol/DDATA/Line3-Gateway/Filler01: data from the filler PLC behind the Line 3 gateway at the Bristol site. Because every topic follows the same pattern, a host application can subscribe to spBv1.0/# and discover every edge node and device on the broker without configuration.

What are birth and death certificates?

This is the heart of Sparkplug B and the main reason to use it.

Birth. When an edge node connects, it publishes an NBIRTH listing every metric it will report, with its name, data type and current value. Each device behind it publishes a DBIRTH. After that, the node only sends NDATA and DDATA messages containing values that have changed. This is called report by exception, and it is why Sparkplug uses so little bandwidth.

Death. When the edge node connects to the broker, it registers its NDEATH as the MQTT Will message. If the connection drops without a clean disconnect, the broker publishes the NDEATH on the node's behalf. The specification ties birth and death together with a bdSeq number, so a host can match a death to the session it ends.

Sequence numbers. Every NBIRTH, DBIRTH, NDATA and DDATA carries a seq number from 0 to 255 that wraps back to zero. If a host sees a gap, it knows it missed a message and can send a Rebirth command (an NCMD) asking the node to republish all its births.

Primary host STATE. A SCADA or host application announces itself on spBv1.0/STATE/ followed by its host ID, using a retained message. Edge nodes can watch this and hold or buffer data while their primary host is offline.

The payload itself is encoded with Google Protocol Buffers, not JSON. Metrics carry a name, type, timestamp and value, and can use numeric aliases after the birth to keep messages small. The trade-off is that you cannot read a Sparkplug payload in a plain text MQTT client; you need a tool that decodes it.

Watch: What is Sparkplug B for MQTT?

In this lesson from 4.0 Solutions, about 19 minutes long, the presenter explains what Sparkplug B is and what it adds to plain MQTT, the subject in the video's title. 4.0 Solutions publishes widely on unified namespace architectures, so the lesson approaches Sparkplug from the IIoT architect's side.

For further watching, Opto 22's Intro to MQTT and Sparkplug B for use in IoT applications gives a shorter, device-side introduction, and 4.0 Solutions' What is the Unified Namespace? covers the architecture discussed below.

Sparkplug B and the unified namespace

A unified namespace (UNS) is an architecture pattern rather than a standard. Every system (PLCs, SCADA, MES, ERP, quality) publishes its current state into one shared hierarchy on a broker, and every other system subscribes to what it needs, instead of building point-to-point links. The hierarchy usually follows ISA-95 levels: enterprise, site, area, line, cell. Our guide to MES and ISA-95 explains those levels.

Sparkplug B and UNS fit well but not perfectly. Sparkplug gives you discovery, typed data and state awareness, which a UNS needs. But Sparkplug's topic structure is fixed at two levels (group and edge node, plus an optional device), so a deep ISA-95 hierarchy has to live in the group and node names or in the metric names. Many UNS designs use Sparkplug B for data coming up from the plant floor and plain MQTT with a documented JSON layout for higher-level business events. Neither is wrong; choose deliberately and write the naming rules down.

Should you use Sparkplug B or OPC UA?

They solve different parts of the problem. OPC UA shines at the machine and line level: rich information models, browsing, methods, and client/server access with strong built-in security. Our OPC UA explainer covers its address space and subscriptions. Sparkplug B shines at moving data from many edge nodes to many consumers through a broker, across sites and firewalls, with low bandwidth and clear online/offline state.

A common pattern is therefore both: an edge gateway reads PLCs over OPC UA, Modbus or native drivers, and publishes upward as Sparkplug B. If you have never pulled data out of a PLC, start with our Modbus TCP walkthrough.

Can a PLC talk MQTT or Sparkplug B directly?

Increasingly, yes, for plain MQTT. Siemens publishes an LMQTT client library for S7-1200 and S7-1500 CPUs, and HMI and edge platforms such as FactoryTalk Optix and Ignition support MQTT natively or through modules. Sparkplug B is less often written in PLC code, because Protobuf encoding, sequence numbers and rebirth handling are better done in an edge gateway or a SCADA module. Whichever route you take, secure the broker: use TLS on port 8883, require client authentication and keep the broker out of the control network's lower zones. Our OT cybersecurity guide explains zones and conduits.

Which MQTT broker should you use?

For learning, Eclipse Mosquitto is a small open-source broker that runs on a laptop or Raspberry Pi. In production, engineers commonly choose a clustered commercial or open-source broker, or one built into their SCADA platform. What matters more than the brand: high availability, TLS, access control by topic, monitoring, and a clear plan for what happens to retained messages and Will messages during a failover.

A worked example: one filler on Sparkplug B

Imagine a bottling plant in Rotterdam with a gateway on Line 3 reading a filler PLC. Configured for Sparkplug B, the message flow looks like this:

1. The gateway connects to the broker and registers its NDEATH as its Will message, with bdSeq 0.
2. It publishes an NBIRTH on spBv1.0/Rotterdam/NBIRTH/Line3-Gateway, with seq 0 and its own metrics, including the mandatory Node Control/Rebirth metric.
3. It publishes a DBIRTH on spBv1.0/Rotterdam/DBIRTH/Line3-Gateway/Filler01 listing the filler's metrics: for example Speed (Float, bottles per minute), State (String) and GoodCount (Int64), with their current values.
4. When the speed changes, it publishes a DDATA containing only Speed, with the next seq number.
5. If someone pulls the gateway's network cable, the broker publishes the NDEATH after the keep-alive timeout, and the SCADA marks every Filler01 tag as stale instead of showing the last value as if it were live.

That last step is the difference an operator notices: a frozen number on a screen is no longer mistaken for a steady process.

Try it yourself

You can build the whole chain on one PC. Start with plain MQTT from Node-RED so you can see readable messages, then switch to Sparkplug B and notice how the NBIRTH describes everything up front. Our Node-RED PLC dashboard walkthrough gets live PLC values into Node-RED first.

Learn it free

The free Node-RED for Industrial IoT course covers MQTT, PLC connections and dashboards. AI for Industrial Automation includes this Sparkplug B lesson alongside the unified namespace and historian lessons, and Ignition SCADA shows the host side with MQTT modules. When the data is flowing, Industrial Data with Python and our guide to data engineering for industrial AI show what to do with it. If you want to work on the host side, read how to become a SCADA engineer, and for the cell networks underneath, PROFINET vs EtherNet/IP.

Checked 5 October 2026 against the Eclipse Sparkplug 3.0.0 specification and the OASIS MQTT 5.0 standard.

Take the free course

IIoT · Beginner · Free

Node-RED for Industrial IoT

AI and machine learning · Intermediate · Free

AI for Industrial Automation

SCADA · Beginner · Free

Ignition SCADA by Inductive Automation

AI and machine learning · Intermediate · Free

Industrial Data with Python