MQTT Sparkplug B explained: what it adds to plain MQTT

Why plain MQTT isn't enough on the plant floor

MQTT is a lightweight publish/subscribe protocol, but it deliberately says nothing about topic names or payload format. Sparkplug is an open specification, maintained under the Eclipse Foundation, that fills that gap for industrial use.

What Sparkplug B adds

• A standard topic namespace: spBv1.0/group/message type/edge node/device
• A binary payload encoded with Google Protocol Buffers
• Birth and death certificates, so consumers know when an edge node or device is online and what metrics it exposes

The trade-off

You gain interoperability and state awareness between Sparkplug-aware tools, but payloads are not human-readable JSON and the topic structure is fixed. Many Unified Namespace designs mix Sparkplug for device data with plain JSON topics for contextualized data. Check each vendor's documentation for its current Sparkplug support.

The three layers of a Sparkplug architecture

1. Edge publishers (edge nodes): gateways and edge platforms that read PLCs and publish Sparkplug messages.
2. MQTT brokers: Sparkplug runs over any compliant MQTT broker; some brokers add Sparkplug-aware features.
3. Host applications (consumers): SCADA, historians and hubs that subscribe, decode payloads and track node state.

Questions to answer before you adopt it

• Do all your consumers decode Sparkplug B, or do some need JSON?
• Which application acts as the primary host for state management?
• Will you keep a separate JSON namespace for contextualized data?
• How will you version and document metric names across sites?

---

Want to know which edge platforms, brokers, SCADA systems and historians work together? See the full compatibility directory at PlantWired, and subscribe to the newsletter there for new integrations and comparisons.