What Is Sparkplug B? Industrial MQTT Explained

Sparkplug B is an open Eclipse Foundation specification that defines how industrial devices and applications use MQTT. It fixes three things MQTT leaves open: the topic structure, the payload format, and how every subscriber knows whether a device is online and its data is current. Plain MQTT moves messages. Sparkplug B makes those messages interoperable between vendors without custom mapping.

For plant and OT engineers, this is what turns an MQTT broker into a reliable backbone for SCADA, historians and analytics. It is also the most common way to feed a Unified Namespace (UNS) from the edge.

This guide explains how Sparkplug B works, where it fits next to OPC UA, its practical limits, and how to run it with the SIOTH® MQTT Universal Broker.

In short: Sparkplug B = MQTT + a standard topic namespace (spBv1.0/…) + a Protocol Buffers payload + birth and death certificates for state awareness.

Why plain MQTT is not enough on a plant

MQTT is a lightweight publish/subscribe protocol: publishers send messages to a broker on named topics, and subscribers receive the topics they ask for (see What is MQTT). It is efficient over low-bandwidth and unreliable links, which is why it spread quickly in IIoT. But MQTT deliberately defines only transport. On an industrial site, that leaves four gaps:

• No topic convention. One integrator publishes plant1/pump3/flow, another site-a/PU-03/FT101/value. Every consumer needs its own mapping.
• No payload format. The payload is just bytes: JSON, CSV, a raw float or a vendor format. Data types, units, timestamps and quality are not guaranteed.
• No state awareness. A subscriber that stops receiving values cannot tell whether the process is stable, the device is offline, or the link is down. For operations, a stale value shown as current is a safety and quality problem.
• No discovery. A new SCADA or historian client cannot ask what tags exist. Someone has to configure them by hand.

Sparkplug B closes these gaps without changing MQTT itself. Any standard MQTT broker can carry Sparkplug B traffic; the rules sit in the clients and, optionally, in a Sparkplug-aware broker.

How Sparkplug B works

Sparkplug B adds four elements on top of MQTT: defined roles, a topic namespace, a typed binary payload and a state-management sequence.

Roles

Topic namespace

Every Sparkplug B message uses the same structure:

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

Any compliant Host Application can parse it without project-specific mapping.

Message types

Payload

Sparkplug B payloads are encoded with Google Protocol Buffers, a compact binary format. Each metric carries a name, a data type, a value and a timestamp. Optional numeric aliases replace long metric names after the birth message, which cuts bandwidth further. Metrics can also carry properties (such as engineering units) and templates for reusable data structures.

A sequence number on every message lets the host detect a lost message and request a fresh birth.

State management: birth, data, death

This is the part that makes Sparkplug B suitable for operations:

1. The Edge Node connects to the broker and registers its NDEATH message as its MQTT Last Will.
2. It publishes NBIRTH, then a DBIRTH per device: the full, typed list of every metric and its current value.
3. After that, it publishes only changes (NDATA, DDATA).
4. If the Edge Node drops off the network, the broker publishes its NDEATH automatically.
5. Every Host Application then marks that node’s data as stale instead of showing the last value as current.
6. On reconnection, the Edge Node sends a new birth, and every consumer has a complete, current picture again.

Sparkplug B vs plain MQTT

Plain MQTT remains a good choice for simple telemetry to IT or cloud systems where JSON readability matters. Sparkplug B is the better choice when operations depend on knowing that the data is complete and current. For the broader protocol comparison, see MQTT vs OPC UA.

Sparkplug B and the Unified Namespace

Sparkplug B is a common transport for a Unified Namespace, but it is not a UNS by itself. A Unified Namespace is a single, event-driven source of truth, organized the way the business sees its assets, usually along ISA-95 levels (enterprise, site, area, line, asset).

The Sparkplug B namespace is organized by communication path: group, Edge Node, device. That suits the edge, but it does not describe where an asset sits in the plant hierarchy or what it means to the business. Most industrial UNS architectures therefore combine:

• Sparkplug B at the edge, for reliable, state-aware data collection from field devices and gateways.
• A contextual model above it, which maps raw metrics to an ISA-95 asset hierarchy with units, limits and relationships.
• Standard MQTT or other interfaces to IT, where consumers expect readable, structured topics.

The broker connects these layers. The modelling layer is what makes the namespace usable by SCADA, historians, analytics and AI applications.

Sparkplug B and OPC UA: where each fits

The two are complementary, and most brownfield plants run both.

A practical pattern: read field and control data over OPC UA, Modbus, DNP3 or vendor protocols at the edge, then publish it as Sparkplug B to a central broker. Clients that need OPC UA browsing or historical access keep an OPC UA endpoint.

CTA: More detail in combining OPC UA, MQTT and Sparkplug.

Design considerations and limits

Sparkplug B solves interoperability at the edge, but a production architecture still needs decisions in five areas:

• Binary payloads are not human-readable. Debugging needs a Sparkplug-aware client or decoder. IT consumers that expect JSON need a translation layer.
• The namespace is not an asset model. Group and Edge Node IDs follow the network, not the plant. Plan the ISA-95 context layer separately.
• The Primary Host matters. Define which application is the Primary Host and how Edge Nodes behave when it is offline, including local buffering.
• Security is not part of the specification. Sparkplug B relies on the MQTT layer: enable TLS, authentication and topic-level access control on the broker, and place it correctly across the IT/OT boundary.
• Not every “MQTT-capable” device speaks Sparkplug B. Many devices publish plain MQTT or JSON. A conversion layer at the edge brings them into the same namespace.

Sparkplug B with SIOTH® and the MQTT Universal Broker

SIOTH® (Smart IoT Highway) is Integration Objects’ industrial integration platform. It covers the full Sparkplug B architecture in one installation: field protocols, Sparkplug B publishing, the broker, the asset model and the applications that consume the data. Integration Objects is a member of the Eclipse Foundation, which maintains the Sparkplug specification.

MQTT Universal Broker

The MQTT Universal Broker is a configurable server within SIOTH® Data Flow. It provides:

• MQTT Standard and Sparkplug B on the same broker
• Eclipse Sparkplug B certified
• TCP and WebSocket endpoints
• TLS/SSL encryption, basic authentication and MQTT Last Will and Testament

SIOTH® as a Sparkplug B Edge Node

The MQTT connector in SIOTH® Data Flow publishes Sparkplug B. Devices that speak only Modbus, DNP3, OPC Classic, OPC UA, IEC 61850 or Siemens S7 can therefore join a Sparkplug B architecture through SIOTH®, with no extra gateway per device family.

The four SIOTH® modules in a Sparkplug B architecture

Outbound, SIOTH® writes to historians (native connectors for AVEVA PI, AVEVA PI AF and InfluxDB), relational databases, Apache Kafka, Azure Event Hub and REST APIs.

Security across the IT/OT boundary. SIOTH® supports DMZ architectures with a protocol break at the integration boundary, end-to-end TLS, role-based access control, Active Directory and OAuth 2.0 authentication and a full audit trail. The platform is IEC 62443-aligned. This addresses the point Sparkplug B leaves to the implementation: securing the broker and the path to it.

Getting started: a seven-step checklist

1. Inventory sources. List devices, PLCs, RTUs, OPC servers and their protocols, per site and network zone.
2. Define the group and Edge Node naming convention. Keep IDs stable; they appear in every topic.
3. Choose the Primary Host Application and define Edge Node behavior while it is offline.
4. Place the broker in the architecture. Decide its network zone, TLS certificates, authentication and topic access rights.
5. Design the asset model (ISA-95 levels, units, limits) that sits above the raw Sparkplug B metrics.
6. Pilot one area. Validate birth and death behavior by disconnecting an Edge Node and checking that every consumer marks the data stale.
7. Connect consumers: SCADA, historian, analytics, then scale site by site.

Frequently asked questions