Inferensys

Glossary

MQTT Sparkplug

MQTT Sparkplug is an open-source specification that defines how to use the MQTT protocol for mission-critical industrial applications by standardizing the topic namespace, payload definition, and session state management for SCADA, IIoT, and real-time control systems.
Knowledge manager reviewing enterprise knowledge management system on laptop, document library visible, casual office.
INDUSTRIAL IIOT PROTOCOL

What is MQTT Sparkplug?

MQTT Sparkplug is a specification that defines how to use the lightweight MQTT messaging protocol for mission-critical industrial applications by adding a standardized topic namespace, payload definition, and state management system.

MQTT Sparkplug is an open specification that enhances the standard MQTT protocol for Industrial Internet of Things (IIoT) and SCADA environments. It mandates a strict topic namespace structure, a binary payload format using Google Protocol Buffers, and a session state awareness mechanism. This ensures that all participants—from edge gateways to MES applications—discover, interpret, and exchange real-time operational data with zero ambiguity.

The specification introduces a Report by Exception paradigm and a Birth/Death Certificate mechanism for stateful session management. When a device connects, it publishes a birth certificate detailing its metrics; upon disconnection, the broker automatically publishes a death certificate. This provides SCADA hosts with immediate, deterministic awareness of every node's online status without constant polling, enabling truly decoupled and scalable industrial architectures.

PROTOCOL SPECIFICATION

Key Features of MQTT Sparkplug

MQTT Sparkplug defines a stateful, interoperable communication framework for industrial IoT. It standardizes topic namespaces, payload formats, and session state management to ensure plug-and-play connectivity between SCADA hosts, MES systems, and edge devices.

01

Standardized Topic Namespace

Defines a rigid, well-known topic structure: spBv1.0/group_id/message_type/edge_node_id/device_id. This eliminates the ambiguity of custom MQTT topic designs, allowing any Sparkplug-aware application to automatically discover and interpret data from any vendor's device without manual mapping. The namespace enforces a logical hierarchy that mirrors the physical plant topology, enabling auto-discovery of new devices by SCADA hosts.

02

Session State Management

Introduces a formal stateful session concept on top of MQTT's stateless publish-subscribe model. Edge nodes publish BIRTH certificates upon connection, containing full device metadata and current values, and DEATH certificates upon graceful disconnection. This allows SCADA systems to instantly detect offline devices and know the last known state, solving the 'stale data' problem inherent in basic MQTT implementations.

03

Rich, Self-Describing Payloads

Uses Google Protocol Buffers (Protobuf) for payload encoding, providing a compact, binary, and schema-enforced data format. Unlike opaque JSON strings, Sparkplug payloads carry native data types (uint32, float, string, complex datasets) and metric metadata (name, timestamp, quality). This self-describing nature allows consumers to parse data without external documentation, enabling true semantic interoperability.

04

Report by Exception

Devices only publish data when a value changes beyond a configurable deadband, rather than polling on a fixed interval. This dramatically reduces network bandwidth and broker load in high-density sensor environments. Combined with periodic heartbeat messages, it guarantees both efficiency and freshness, ensuring the SCADA system is never uncertain about a device's silence.

05

Unified Namespace Integration

Serves as the canonical southbound protocol for a Unified Namespace (UNS) architecture. By structuring all factory-floor data into a single, Sparkplug-compliant MQTT broker, any authorized application—from HMI dashboards to cloud analytics—can subscribe to a live, contextualized data stream without point-to-point integrations. This decouples data producers from consumers, enabling scalable digital transformation.

06

Strict Quality of Service (QoS) Enforcement

Mandates specific MQTT QoS levels for different message types to guarantee delivery semantics. BIRTH/DEATH and command messages use QoS 1 (at least once) to ensure critical state changes are not lost, while telemetry data uses QoS 0 (at most once) for fire-and-forget efficiency. This explicit contract prevents the reliability ambiguity that plagues generic MQTT industrial deployments.

MQTT SPARKPLUG CLARIFIED

Frequently Asked Questions

Clear, technically precise answers to the most common questions about the MQTT Sparkplug specification for industrial IoT and SCADA systems.

MQTT Sparkplug is a formal specification that defines how to use the standard MQTT protocol for mission-critical industrial applications by adding a strict topic namespace, a binary payload definition using Google Protocol Buffers, and explicit state management. While standard MQTT is a generic, agnostic transport with no rules for topic structure or payload format, Sparkplug enforces a namespace/group_id/message_type/edge_node_id/device_id topic hierarchy. This standardization ensures that any Sparkplug-compliant subscriber can immediately interpret data from any producer without custom integration. The specification mandates a Report by Exception paradigm, where data is published only on change, and introduces a Session State mechanism using birth and death certificates to track device lifecycle, eliminating the ambiguity of standard MQTT's Last Will and Testament alone.

PROTOCOL COMPARISON

MQTT Sparkplug vs. OPC UA vs. Raw MQTT

A technical comparison of the three primary data transport paradigms for industrial interoperability, evaluating their suitability for mission-critical SCADA and IIoT architectures.

FeatureMQTT SparkplugOPC UA Client/ServerRaw MQTT

Standardized Topic Namespace

Payload Schema Enforcement

Google Protocol Buffers

OPC UA Binary/JSON

None (arbitrary bytes)

Session State Management

Birth/Death Certificates

Session Context Object

Discovery Mechanism

Automatic via State Messages

Endpoint Discovery Server

Transport Protocol

TCP/MQTT (Pub/Sub)

TCP/HTTPS (Client/Server)

TCP/MQTT (Pub/Sub)

Report by Exception

Typical Wire Overhead

< 10 bytes per metric

100 bytes per value

< 5 bytes per metric

Real-Time Determinism

Soft (broker-dependent)

Hard (with TSN extension)

Soft (broker-dependent)

Prasad Kumkar

About the author

Prasad Kumkar

CEO & MD, Inference Systems

Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.

His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.