May 16, 2026 · Guide

MQTT Sparkplug B Explained: Industrial IoT Protocol Guide

MQTT is one of the most widely deployed messaging protocols in industrial IoT. It is lightweight, runs on constrained hardware, and handles unreliable networks gracefully. But MQTT by itself has a problem: it defines how to move bytes, not what those bytes mean. Every vendor invents their own topic structure, their own payload format, and their own approach to state management. The result is a fragmented ecosystem where no two MQTT deployments look alike.

Sparkplug B, developed under the Eclipse Foundation, fixes this. It is an open specification that adds a standard topic namespace, a typed payload format using Protocol Buffers, and a built-in mechanism for detecting when devices come online or go offline. If you are building industrial IoT or SCADA systems, Sparkplug B is the specification that makes MQTT actually interoperable. For foundational MQTT concepts like quality of service levels and retained messages, see our guide to MQTT QoS explained.

The Problem Sparkplug B Solves

Consider a typical industrial deployment: a PLC publishes temperature readings to factory/line1/oven/temp, a flow meter publishes to sensors/flowmeter/reading, and a vibration sensor publishes to vib/sensor01/rms. Three devices, three topic conventions, three payload formats. A SCADA system connecting to this broker has no way to discover what data exists, what the data types are, or whether a device is still alive. For guidance on setting up the broker itself, see our guide to running an MQTT broker on macOS.

Sparkplug B addresses three core gaps in plain MQTT:

• No standard topic structure. Every implementation uses ad-hoc topic hierarchies. Sparkplug B defines a strict topic namespace that all compliant applications can parse.
• No standard payload format. MQTT payloads are opaque byte arrays. One device sends JSON, another sends raw bytes, another sends CSV. Sparkplug B mandates Protocol Buffers with a defined schema that includes metric names, data types, timestamps, and metadata.
• No state awareness. Plain MQTT has no mechanism to know if a data source is still connected. A broker might deliver stale retained messages hours after the publishing device crashed. Sparkplug B introduces birth and death certificates that provide explicit online/offline state management.

Sparkplug B Topic Namespace

Every Sparkplug B message is published to a topic that follows this structure:

namespace/group_id/message_type/edge_node_id/device_id

Where:

• namespace is always spBv1.0 for Sparkplug B version 1.0.
• group_id is a logical grouping, typically a site, plant, or organizational unit (e.g., Factory-A).
• message_type identifies the kind of message: DBIRTH, DDEATH, NBIRTH, NDEATH, DDATA, NDATA, DCMD, NCMD, or STATE.
• edge_node_id identifies the edge gateway or EoN (Edge of Network) node (e.g., Gateway-01).
• device_id identifies a specific device behind the edge node (e.g., Motor-07). Host-level messages (for the edge node itself) omit this component.

Example topic for a device birth certificate:

spBv1.0/Factory-A/DBIRTH/Gateway-01/Motor-07

This structure means any Sparkplug-compliant application can subscribe to spBv1.0/Factory-A/# and receive all data from Factory A, or subscribe to spBv1.0/+/+/+ to receive data from the entire plant floor.

Payload Structure: Metrics, Timestamps, and Metadata

Sparkplug B payloads are encoded using Protocol Buffers (Protobuf), which makes them compact, fast to serialize, and self-describing. A payload contains:

• timestamp: Unix epoch milliseconds for when the payload was generated.
• metrics: A repeated list of metric objects, each containing a name, value, data type, and optional timestamp.
• seq: A sequence number (0-255, wrapping) for ordered delivery verification.
• uuid: Optional unique identifier for the payload.
• body: Optional raw byte array for extended data.

Each metric within the payload has:

• name: A hierarchical metric name (e.g., properties/temperature).
• value: The actual data value, typed according to the datatype field.
• datatype: An integer representing the Sparkplug data type (Boolean=1, Int8=2, Int16=3, Int32=4, Int64=5, UInt8=6, UInt16=7, UInt32=8, UInt64=9, Float=10, Double=11, String=12, DateTime=13, Text=14, DataSet=15, Bytes=16, File=17, Template=20, and more).
• timestamp: Per-metric timestamp, allowing different sampling times within a single payload.
• is_historical: Boolean flag indicating whether the metric is a real-time or historically backfilled value.
• is_null: Boolean flag for metrics that have no current value.
• metadata: Optional metadata including description, engineering units, and custom properties.
• properties: Key-value property set for extended metadata on individual metrics.

This structure means that a SCADA system receiving a Sparkplug B payload knows exactly what each metric represents, what type it is, when it was sampled, and whether it is current or historical. No out-of-band configuration files needed.

Birth and Death Certificates

The birth/death certificate mechanism is the most important contribution Sparkplug B makes to industrial MQTT. It solves the fundamental state awareness problem.

Edge Node Lifecycle

When an edge node connects to the broker, it follows this sequence:

1. NBIRTH (Node Birth): The edge node publishes its birth certificate to spBv1.0/group_id/NBIRTH/edge_node_id. This payload contains all metrics the node itself reports, including a full descriptor of capabilities. The broker stores this as a retained message on the node's state topic.
2. DBIRTH (Device Birth): For each device connected to the edge node, a device birth certificate is published to spBv1.0/group_id/DBIRTH/edge_node_id/device_id. This contains all metrics for that device with their current values, data types, and metadata. This is a full declaration of the device's data model.
3. NDATA/DDATA (Node/Device Data): After birth, subsequent value changes are published as data messages. These are deltas: only metrics whose values have changed are included.

Death Certificates

When a device or node goes offline, the system uses death certificates:

• DDEATH (Device Death): Published by the edge node when a device is no longer reachable. Informs all subscribers that the device is offline.
• NDEATH (Node Death): The edge node registers a will message (MQTT LWT, Last Will and Testament) at connection time. If the broker detects the TCP connection has dropped, it publishes the NDEATH on behalf of the node. This means even an ungraceful disconnect (power loss, network failure) triggers a death certificate.

Sparkplug B Data Types

Sparkplug B defines a comprehensive set of data types that map directly to industrial data sources:

Primitive Types

The basic types cover virtually all PLC and sensor outputs:

• Boolean (1): True/false values. Digital inputs, alarm states, running/stopped flags.
• Int8, Int16, Int32, Int64 (2-5): Signed integers. Register values, counters, setpoints.
• UInt8, UInt16, UInt32, UInt64 (6-9): Unsigned integers. Modbus register values, status words.
• Float, Double (10-11): Floating point. Analog sensor readings, temperature, pressure, flow rate.
• String (12): UTF-8 text strings. Device names, serial numbers, error messages.
• DateTime (13): Millisecond-precision timestamps.

Complex Types

Sparkplug B also supports structured data that goes beyond simple scalar values:

• DataSet (15): A table-like structure with columns of typed data. Used for multi-row query results, batch readings, or tabular configuration data.
• Template (20): A reusable, parameterized data structure. Templates allow you to define a metric type once and instantiate it multiple times. For example, a "Motor" template with speed, current, and temperature parameters can be applied to every motor on the plant floor without re-declaring the full metric set for each one.
• Bytes (16) and File (17): For binary payloads, firmware images, and configuration files.

The type system ensures that consumers do not have to guess whether a value is an integer or a float, whether a register is signed or unsigned, or whether a string is an ASCII label or a UTF-8 description. The Protobuf schema encodes all of this explicitly.

Sparkplug B vs Plain MQTT vs OPC UA

Understanding when to use Sparkplug B requires seeing how it fits between plain MQTT and OPC UA. Each has distinct strengths.

The practical takeaway: use Sparkplug B as your default for MQTT in industrial settings. Use plain MQTT only when you have complete control over both publishers and subscribers and do not need interoperability. Use OPC UA when you need rich information modeling, method calls, or complex security at the device level.

Integration with SCADA, Historians, and Cloud Platforms

Sparkplug B's standardized format makes integration with downstream systems straightforward:

SCADA Systems

A Sparkplug-aware SCADA system subscribes to spBv1.0/# and automatically discovers all groups, edge nodes, and devices. Birth certificates provide the data model. Data messages provide real-time values. Death certificates mark devices as offline. No manual tag configuration required. For a comparison of SCADA approaches, see our guide on SCADA vs IoT platforms.

Historians

Because every metric carries a timestamp, a data type, and an is_historical flag, historians can ingest Sparkplug B data directly without a translation layer. The typed payloads eliminate the parsing and type-conversion logic that historians normally need when consuming plain MQTT.

Cloud Platforms

AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all support MQTT. Adding Sparkplug B means your cloud functions receive structured, typed data instead of opaque payloads. The Eclipse Tahu project provides open-source client libraries and cloud connectors that translate Sparkplug B payloads into cloud-native formats when needed.

Testing MQTT with Sparkplug B on macOS

If you want to experiment with Sparkplug B before deploying to production, macOS provides everything you need.

Step 1: Install an MQTT Broker

Install Mosquitto via Homebrew:

brew install mosquitto

Start the broker:

mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf

Step 2: Publish a Sparkplug B Payload

Use a Sparkplug-aware client to publish to the correct topic namespace. The Eclipse Tahu project provides Python and Java client libraries. For quick testing, you can publish a simple NBIRTH message:

mosquitto_pub -t "spBv1.0/PlantA/NBIRTH/GW01" -f nbirth.payload

Where nbirth.payload is a pre-encoded Protobuf file. The Eclipse Tahu project includes example payload generators.

Step 3: Inspect with MQTT Explorer

Use MacTools MQTT Explorer to subscribe to spBv1.0/# and watch the topic structure, payload contents, and message flow in real time. The topic hierarchy will show groups, edge nodes, and devices in a navigable tree. You can verify that birth certificates are properly structured, data messages contain the expected metrics, and death certificates are published on disconnect.

Frequently Asked Questions

What is MQTT Sparkplug B?

Sparkplug B is an open specification by the Eclipse Foundation that defines a standard topic structure, payload format, and state management mechanism for MQTT in industrial environments. It uses Protocol Buffers for efficient binary payloads, defines a hierarchical topic namespace (namespace/group_id/edge_node_id/device_id), and introduces birth/death certificates so SCADA systems know when edge nodes and devices come online or go offline.

How does Sparkplug B differ from plain MQTT?

Plain MQTT is a generic pub/sub transport with no rules for topic naming, payload encoding, or state awareness. Sparkplug B adds three layers on top: a standardized topic namespace so all applications know where to find data, a Protocol Buffer payload schema with typed metrics and timestamps, and a birth/death certificate mechanism that provides automatic online/offline state detection. Plain MQTT cannot tell you if a device is still connected; Sparkplug B can.

Does Sparkplug B replace OPC UA?

No. OPC UA and Sparkplug B serve different purposes and are often used together. OPC UA provides rich information modeling, method calls, and complex security at the cost of heavier resource requirements. Sparkplug B provides lightweight, bandwidth-efficient data transport over MQTT with simpler semantics. Many architectures use OPC UA at the device level and Sparkplug B for edge-to-cloud communication, or use Sparkplug B where OPC UA is too resource-heavy for the edge hardware.

How do I test MQTT with Sparkplug B on macOS?

Install an MQTT broker like Mosquitto via Homebrew (brew install mosquitto), then use a tool like MacTools MQTT Explorer to publish and subscribe to Sparkplug B topics. Start the broker with mosquitto -c /opt/homebrew/etc/mosquitto/mosquitto.conf, connect with your client, and publish to the spBv1.0 topic namespace. MQTT Explorer lets you inspect the Protobuf payloads, verify topic structure, and monitor birth/death certificate exchanges.

Further Reading

• How to Run an MQTT Broker on macOS for Industrial Testing
• MQTT QoS Explained: Which Level to Use for Industrial Data
• SCADA vs IoT Platforms: What System Integrators Need to Know