What SparkplugB Solves
SparkplugB (Eclipse Sparkplug) is a specification that standardizes how industrial data is published over MQTT. It solves real problems that plague generic MQTT deployments in OT environments:
- Payload structure - a defined binary encoding (Protobuf) with typed metrics, timestamps, and quality indicators. No more arbitrary JSON payloads with inconsistent schemas.
- Birth and death certificates - devices announce themselves on connect and are declared offline on disconnect. State management is built into the protocol, not bolted on.
- Metric aliasing - after the initial birth certificate, metrics are transmitted using numeric aliases instead of full string names. This reduces bandwidth significantly on constrained links.
- Rebirth logic - when a consumer detects it has missed state, it can request a full rebirth from the device. State recovery is a protocol-level capability.
- Sequence numbering - ordered delivery detection without relying on MQTT QoS alone.
For organizations standardizing on MQTT for OT communication, SparkplugB is a significant improvement over raw MQTT. It brings structure and lifecycle management to a protocol that otherwise leaves those problems to every implementer.
Where SparkplugB Stops
SparkplugB standardizes the payload and lifecycle on a single MQTT broker. It does not address:
- Multi-protocol environments - most industrial facilities run OPC UA, Modbus, S7, BACnet, and DNP3 alongside MQTT. SparkplugB covers the MQTT portion only.
- Edge transformation - SparkplugB defines what the payload looks like, not how to transform, filter, or enrich it before delivery. CEL expressions, RBE filtering, and derived value computation are outside its scope.
- Multi-destination routing - SparkplugB data lives on the MQTT broker. Routing that data to S3, Kafka, TimescaleDB, InfluxDB, or a data lake requires additional infrastructure.
- Durable buffering - if the MQTT broker or network is unavailable, SparkplugB does not define a local persistence and replay mechanism at the edge.
- Namespace scope - SparkplugB defines a topic namespace within MQTT. The Unified Namespace extends this concept across all protocols, all destinations, and the entire enterprise.
These are not limitations of SparkplugB - they are simply outside its scope. SparkplugB is a payload and lifecycle specification for MQTT. The data plane is the layer that handles everything else.
The UNS Beyond MQTT
The Unified Namespace is an architectural pattern - not an MQTT feature. It defines a canonical data model where every industrial signal carries identity, context, timestamp, quality, and provenance, structured into an ISA-95 hierarchy.
SparkplugB implements a version of this within the MQTT domain. But the UNS must extend beyond MQTT:
- OPC UA subscriptions from automation controllers need the same namespace context as SparkplugB metrics
- Modbus register values from legacy PLCs need the same quality indicators and provenance metadata
- Data delivered to S3, Kafka, or InfluxDB needs the same hierarchical structure regardless of how it was acquired
The UNS is protocol-agnostic. SparkplugB is MQTT-specific. Both are valuable. They operate at different layers of the architecture.
How They Work Together
KŌJŌ Stack ingests SparkplugB data natively - with full support for birth/death certificates, metric aliasing, rebirth logic, and sequence number handling. SparkplugB metrics enter the data plane with their native structure preserved.
From there, the data plane applies the same processing as any other protocol source:
- Namespace alignment - SparkplugB topic structure maps into the ISA-95 hierarchy alongside OPC UA, Modbus, and every other source
- Transformation - CEL expressions and RBE filtering apply to SparkplugB metrics just as they apply to any other data point
- Multi-destination delivery - SparkplugB data routes to MQTT, Kafka, S3, TimescaleDB, InfluxDB, or any other destination with independent buffering and delivery guarantees
- Durable replay - if a destination is unreachable, SparkplugB data is buffered locally and replayed in order when connectivity is restored
SparkplugB defines how data enters the MQTT broker. KŌJŌ Stack defines what happens to that data - and all other data - from that point forward.
What Changes
When SparkplugB operates alongside a first-mile data plane:
- SparkplugB environments gain multi-protocol ingestion without abandoning their MQTT investment
- Data from SparkplugB devices joins data from OPC UA, Modbus, S7, BACnet, and DNP3 in a single namespace
- Edge transformation, filtering, and derived value computation apply uniformly across all sources
- Multi-destination routing ensures SparkplugB data reaches analytics, historians, and data lakes - not just the MQTT broker
SparkplugB solves the MQTT payload problem. The data plane solves the industrial data problem. They are complementary layers in a well-structured architecture.