MQTT Sparkplug B

What is MQTT Sparkplug B?

MQTT Sparkplug B is an open specification from the Eclipse Foundation that defines, on top of MQTT, a fixed topic structure, a binary payload format based on Google Protocol Buffers and rules for the online and offline state of edge nodes and devices, so that industrial systems from different vendors can exchange data without custom integration. MQTT only handles transport and leaves topics and message content open. Sparkplug B fills that gap with conventions suited to industrial automation and the Industrial Internet of Things. Since 2023, version 3.0 has also been an international standard, ISO/IEC 20237.

🧠 What problem does Sparkplug B solve?

Plain MQTT offers publish/subscribe, a lightweight broker-based architecture and good scalability. But MQTT says nothing about content. Every project therefore invents its own topic names, its own JSON formats and its own way of telling whether a device is still alive. That works in a pilot, but not with dozens of vendors and thousands of data points.

A SCADA, MES or historian system that subscribes to the broker thus immediately gets a reliable picture of which devices exist, which data points they have and whether their values are still valid.

🕰️ How did Sparkplug come about?

Sparkplug was developed by Cirrus Link Solutions, a company that supplies MQTT modules for the Ignition SCADA platform. A first payload definition (Sparkplug A) was based on the Eclipse Kura Protobuf model. Sparkplug B soon replaced it, and Sparkplug A was removed from the specification in version 3.0.

The Eclipse Foundation remains the steward of the specification. Eclipse Tahu is the associated open source implementation, with libraries for Java, C, C#, Python and JavaScript among others. Products that pass the free TCK may call themselves Sparkplug Compatible.

🔧 What are the parts of a Sparkplug architecture?

Field devices (PLC, sensor, meter)
        │
        ▼
Edge Node (gateway)  ── spBv1.0/... ──►  MQTT server (broker)
                                              │
                         ┌────────────────────┼──────────────┐
                         ▼                    ▼              ▼
              Primary Host (SCADA)       Historian          MES

A Sparkplug Compliant broker only needs to support QoS 0 and 1, retained messages and Will messages. A Sparkplug Aware broker additionally stores the latest NBIRTH and DBIRTH message of every node and offers them as retained messages on a $sparkplug topic, so late subscribers immediately know the metric list. Mosquitto, HiveMQ and EMQX are widely used brokers.

🧩 What does the Sparkplug topic structure look like?

Every Sparkplug client uses the same structure:

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

An example is spBv1.0/Plant1/DDATA/Line1/PLC01. The last element is omitted for node-level messages. The specification recommends short names, because the topic travels with every message.

This fixed structure is technical by nature. For a Unified Namespace, many organisations therefore combine Sparkplug with a readable ISA-95 hierarchy of site, area and line.

🔄 How do birth, death and state awareness work?

The strength of Sparkplug lies in its state management:

• Birth certificate - on start-up an edge node publishes an NBIRTH containing all its metrics, datatypes and current values. A host does not need any manual configuration.
• Death certificate - when connecting, the edge node registers an NDEATH as its MQTT Last Will. If the connection drops, the broker publishes that message and the host marks all values of that node as STALE.
• bdSeq and seq - a birth/death sequence number ties each NDEATH to the correct NBIRTH. The other messages from an edge node also carry a sequence number (seq) from 0 to 255 that then wraps back to 0, so a host notices missed messages.
• Rebirth - if a host misses messages, it sends an NCMD with the metric Node Control/Rebirth. The edge node then republishes all its birth messages. This is a form of automatic recovery.
• Primary host STATE - the primary host publishes a JSON message with online and a timestamp. An edge node can buffer data locally while the host is offline (store-and-forward) and send it later as historical values.

After the birth message, Sparkplug works on a Report by Exception basis: only changed values are sent. Compared with periodic polling via Modbus or SNMP, this reduces bandwidth and load and keeps latency low. For industrial processes it means an operator always sees whether a value is current.

📦 How is a Sparkplug B payload structured?

A payload is a Protobuf message with a timestamp, a sequence number and a list of metrics. Each metric has a name, an optional numeric alias, a timestamp, a datatype and a value. After the birth message, a node may use the alias instead of the full name, which shrinks messages further.

A metric also has the flags is_historical (buffered value) and is_null, plus optional properties such as engineering units. The Quality property has three values: 0 (BAD), 192 (GOOD) and 500 (STALE). With templates you define a type, for example “Pump”, once and reuse it for every pump.

🔄 How does Sparkplug B compare with OPC UA?

Sparkplug and OPC UA are often compared, but in practice they complement each other.

A common pattern: the edge gateway reads PLCs via OPC UA, Modbus TCP, S7 Comm or BACnet and publishes the data as Sparkplug to the broker. Because edge nodes only open outbound connections, no inbound port into the OT network is required.

🏭 Where is Sparkplug B used?

Typical applications include OEE monitoring and machine states in manufacturing, predictive maintenance and condition monitoring, remote telemetry of distributed pumping stations and tanks in the water sector, energy metering in the energy sector, and HVAC in building automation. Within edge computing, the edge node often also handles filtering and buffering, and the data can feed industrial AI models. Sparkplug thus fits OT convergence: OT data becomes available to IT applications without point-to-point integrations.

🔐 How do you secure a Sparkplug environment?

The Sparkplug specification itself sets no normative security requirements and defers to MQTT and TCP/IP. Cybersecurity therefore depends entirely on how you configure the broker and clients.

Mitigating measures:

• Encryption and identity - TLS on port 8883 with client certificates and sound certificate management
• Topic ACLs - the specification recommends that an edge node may only publish on topics of its own group and node; restrict NCMD/DCMD to the primary host, backed by RBAC
• Administrative access - MFA for the broker’s management console and hardening of the broker server
• Segmentation - network segmentation following the zones and conduits of IEC 62443, with the broker in an IDMZ behind an industrial firewall
• Detection - logging of connections and security monitoring for unusual publishing behaviour

For Dutch organisations covered by the Cybersecurity Act (Cyberbeveiligingswet), a broker that distributes OT data falls within the risk management measures the law requires.

🧭 How do you approach a Sparkplug implementation?

1. Pick a well-defined use case - for example OEE of one line or monitoring ten pumping stations.
2. Design the namespace - choose short, stable group_id and edge_node_id names that match your Purdue or ISA-95 layout.
3. Choose broker and redundancy - ensure high availability with a broker cluster or failover; the specification also describes edge nodes moving to the next available broker.
4. Define metrics and templates - one template per device type prevents inconsistency.
5. Set QoS and buffering - follow the Sparkplug QoS rules and configure store-and-forward at the edge.
6. Test for compatibility - choose components that pass the Sparkplug TCK.
7. Organise lifecycle management - define who changes topics, certificates and templates.

In production, watch for the familiar bottlenecks: without a cluster the broker is a single point of failure, uncontrolled growth of topics and metrics (topic explosion) loads both broker and hosts, and every rebirth of a large edge node resends the full metric list across the network. Monitor connection counts, messages per second and rebirths per node accordingly.

❓ Frequently asked questions

What is the difference between Sparkplug A and Sparkplug B?

Sparkplug A was the first payload definition, based on the Eclipse Kura Protobuf model. Sparkplug B followed shortly after with a richer data model including datasets, templates and properties. Sparkplug A is deprecated and has not been part of the specification since version 3.0.

Is MQTT Sparkplug B an official standard?

MQTT Sparkplug B version 3.0 was published in October 2023 as the international standard ISO/IEC 20237:2023. The ISO standard is identical in content to Sparkplug 3.0, and the Eclipse Foundation continues to maintain the specification. It intends to submit future versions to ISO/IEC through the same PAS procedure.

Which MQTT version does Sparkplug B use?

Sparkplug 3.0 works with MQTT 3.1.1 and MQTT 5.0. The broker only needs to support QoS 0 and 1, retained messages and Will messages. A Sparkplug Aware broker additionally stores the latest birth messages of every edge node.

What does STALE mean in Sparkplug B?

STALE means a value is no longer current because the edge node or device has gone offline. A Sparkplug host marks all metrics as STALE as soon as it receives an NDEATH or DDEATH. This way an operator sees immediately that they are looking at old data.

Do you need Sparkplug B for a Unified Namespace?

Sparkplug B is not mandatory for a Unified Namespace, but it does provide fixed conventions for topics, payloads and device state. Because Sparkplug topics are technical in structure, many organisations combine Sparkplug for connectivity with an ISA-95 topic structure for contextualised data.

Is MQTT Sparkplug B secure?

MQTT Sparkplug B contains no security mechanisms of its own and relies on MQTT and TLS. Secure use requires TLS with client certificates, topic ACLs per edge node, commands restricted to the primary host and segmentation of the broker in an IDMZ.

📌 In summary

MQTT Sparkplug B turns MQTT into an industrial standard by defining topics, Protobuf payloads and the state of edge nodes and devices. With birth and death messages, Report by Exception and ISO/IEC 20237 status, Sparkplug B delivers interoperable, efficient and reliable OT data for SCADA, historians and a Unified Namespace, provided you secure the broker and clients yourself.