"Sparkplug is becoming the de facto common language of industrial IoT, packaging OT data in a standard way." — Eclipse Foundation
In November 2023, the Eclipse Foundation's Sparkplug 3.0 specification became a formal international standard as ISO/IEC 20237 — the first time an Eclipse project has ever been elevated to an ISO/IEC standard. Even before standardization, MQTT's lightweight publish-subscribe (pub/sub) model had cemented its position as the de facto standard messaging protocol on industrial sites, but "how to structure topics and what to put in the payload" still varied from vendor to vendor and site to site. Sparkplug B fills exactly this gap: a layer on top of MQTT that standardizes the meaning and state of industrial data.
So what exactly does Sparkplug B standardize, and why has it settled into a complementary rather than competitive relationship with OPC UA? And what should we make of the 2025 debate over whether Sparkplug can sit at the center of a Unified Namespace (UNS)? This article walks through the specification's core mechanisms, the latest architectural consensus, and the implications for real-world deployments.
From edge to cloud, Sparkplug B connects device state and data in a single consistent model.
1. The Three Pillars of Sparkplug B
The value Sparkplug B adds to MQTT boils down to three things. First, a defined topic namespace. By fixing the structure as spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}, you can tell which group, node, and device data came from just by looking at the topic. Second, a binary payload based on Google Protocol Buffers. It dramatically reduces message size compared to JSON while structurally carrying each metric's data type, timestamp, and quality information. Third, a device lifecycle model that lets the entire network consistently recognize when devices appear, disappear, and change state.
- Topic namespace: expresses data origin and hierarchy in a self-describing way
- Protobuf payload: compressed binary saves bandwidth, with type, timestamp, and quality built in
- Lifecycle model: maintains state consistency even in intermittently connected environments
2. Report-by-Exception and Bandwidth — The Mechanics of 90% Savings
The most industrial of Sparkplug's design philosophies is Report-by-Exception (RBE): data and device state are transmitted only when they change. This fundamentally reduces the unnecessary traffic that polling-based systems generate. On top of that comes metric aliasing. The initial NBIRTH and DBIRTH messages assign each metric an integer alias, and subsequent NDATA and DDATA messages send only the integer alias instead of the long string name.
- Metric aliasing cuts per-metric overhead for high-frequency telemetry by more than 90%
- Protobuf binary encoding dramatically shrinks message size compared to JSON
- Store-and-forward buffers data during network outages and retransmits on recovery
When these three combine, thousands of tags can be operated in near real time even over bandwidth-constrained, expensive links such as cellular or satellite. Bandwidth is cost, and the scalability of industrial IoT depends on "how little you can send and still have enough."
3. State Awareness — Birth and Death Certificates
In traditional polling systems it is hard to know whether a device is alive right now and whether its last value can be trusted. Sparkplug B solves this with Birth/Death Certificates. When an edge node connects, it declares its metadata and its full set of metrics with NBIRTH, and downstream devices report their configuration with DBIRTH. Conversely, whether through a graceful shutdown or an unexpected failure, when a node disappears, NDEATH and DDEATH notify the network.
The key is the combination with MQTT's Last Will and Testament (LWT) feature. When the broker loses its connection to a node, it automatically publishes the pre-registered NDEATH. As a result, every subscriber (SCADA, historian, analytics engine) immediately shares the fact that "this node's data is now stale." State consistency is guaranteed at the protocol level.
4. OPC UA vs Sparkplug B — Division of Labor, Not Competition
OPC UA is a request-response standard with a rich object model, a type system, and sophisticated StatusCodes. Its semantics are powerful, but it is correspondingly heavy, and it creates a tightly coupled structure in which applications depend directly on specific devices. Sparkplug B, by contrast, uses a publish-subscribe model in which devices and applications are loosely coupled through the broker, with no need to know each other directly.
The dominant pattern that has taken hold in the field is not choosing one or the other but a division of roles. The southbound leg — from PLCs to aggregation gateways — goes to OPC UA, where the type system and StatusCodes matter; the northbound leg — from gateways to enterprise systems — goes to MQTT/Sparkplug B, where fan-out and broker meshes matter. A typical configuration has OT middleware such as Inductive Automation's Ignition and PTC Kepware converting OPC UA and proprietary protocols to MQTT, with brokers like HiveMQ spreading the data across the enterprise and bridging into Kafka.
OPC UA southbound + Sparkplug B northbound — the dominant architecture pattern in the field in 2025.
5. The 2025 Debate — Limits as a UNS Protocol
The hottest discussion around Sparkplug has been whether it can be the central protocol of a Unified Namespace. In February 2025, HiveMQ's Jens Deters publicly walked back the position some had advocated, concluding that "Sparkplug is not suitable as a UNS protocol because it has no mechanism for selectively subscribing to only the metrics you care about." The limitation stems from Sparkplug's topic structure being bundled at the node and device level, which makes it difficult to pick out and subscribe to a single specific metric.
The implication of this debate is clear. Sparkplug B is excellent as an edge-telemetry transport standard, but it operates at a different layer from the UNS itself — the enterprise-wide semantic layer. In fact, only about 13% of respondents run a UNS in production, still early-adopter territory. Sparkplug B is therefore best understood not as "the whole of the UNS" but as "a robust pipeline that feeds the UNS."
Case in Point — Interoperability Born of Standardization
The Eclipse Foundation states that Sparkplug v3.0 and ISO/IEC 20237 are strictly equivalent, and that a product faithfully implementing either will pass the Technology Compatibility Kit (TCK) issued by Eclipse. This means standards conformance can be verified objectively, without vendor lock-in. Many suppliers including Opto22, Inductive Automation, and HiveMQ have adopted the standard, and the MQTT broker in Microsoft Azure Event Grid supports Sparkplug B as well. A common vocabulary linking cloud and edge, OT and IT, has been established at the level of a formal standard (sources: Eclipse Foundation, ARC Advisory Group, HiveMQ).
How PlantPulse Answers
PlantPulse from KOPENS (Korea Open Solution Co., Ltd.) builds this division of labor into the platform itself. Supporting more than 200 industrial protocols, it collects OPC UA, Modbus, and legacy protocols on the southbound side, and disseminates data across the enterprise via MQTT/Sparkplug B on the northbound side. Because ISA-95 asset modeling gives meaning to the collected data, the metrics delivered by Sparkplug B connect naturally into the semantic layer of the UNS.
PlantPulse also delivers store-and-forward and state awareness in practice on an edge-cloud hybrid architecture, and with governance and AI/ML/MLOps integration built in from day one, it takes organizations beyond "collecting data" toward "from operations to decisions." The meeting point of the transport layer that Sparkplug B defines as a standard and the platform layer responsible for semantics, governance, and analytics on top of it is exactly the territory PlantPulse targets.
Closing
Sparkplug B is the standard that elevated MQTT to industrial grade. Its three pillars — topic namespace, Protobuf payload, and lifecycle model — combined with Report-by-Exception, metric aliasing, and store-and-forward, enable reliable, state-aware data transport even over constrained bandwidth. ISO/IEC 20237 standardization freed the technology from vendor lock-in and made it a common vocabulary for the global ecosystem.
At the same time, the 2025 debate calls for a balanced view. Sparkplug B is a powerful standard for edge transport, but it is not the semantic layer of the UNS itself. A successful industrial data architecture therefore depends on designing OPC UA's semantics, Sparkplug B's transport efficiency, and the semantic and governance layer above them together. (References: Eclipse Foundation Sparkplug Specification v3.0 / ISO/IEC 20237:2023, ARC Advisory Group, HiveMQ "OPC UA vs MQTT Sparkplug", Kai Waehner "Unified Namespace vs Data Product 2025", Opto22 White Paper)
© KOPENS — Industrial DataOps & PlantPulse Platform