Inferensys

Glossary

MQTT Sparkplug

An open specification defining how to use MQTT for mission-critical industrial applications, ensuring stateful session awareness, data typing, and topic namespace structure for plug-and-play interoperability.
Data scientist building training data pipeline on laptop, data preprocessing visible, technical workspace.
INTEROPERABILITY SPECIFICATION

What is MQTT Sparkplug?

MQTT Sparkplug is an open specification that defines how to use the MQTT protocol for mission-critical industrial applications, ensuring stateful session awareness, rich data typing, and a structured topic namespace for true plug-and-play interoperability between OT and IT systems.

MQTT Sparkplug enhances standard MQTT by mandating a strict topic namespace structure based on the ISA-95 asset hierarchy, enabling automatic discovery of devices and their metadata. It defines a stateful session awareness mechanism using birth and death certificates, allowing SCADA systems to instantly know when a device comes online or goes offline unexpectedly.

The specification enforces a rich, self-describing data model using Google Protocol Buffers for payload encoding, eliminating the ambiguity of raw byte streams. This ensures that every transmitted value carries its explicit data type, engineering units, and quality flags, enabling any subscribing application to correctly interpret the information without prior configuration.

INDUSTRIAL INTEROPERABILITY

Key Features of MQTT Sparkplug

MQTT Sparkplug defines a stateful, data-rich communication protocol on top of MQTT, ensuring plug-and-play interoperability for mission-critical industrial applications.

01

Stateful Session Awareness

Unlike standard MQTT, Sparkplug introduces the concept of stateful sessions. A Birth Certificate message is published when a client connects, detailing its identity and the metrics it will report. A Death Certificate, often a Last Will and Testament, is automatically published upon disconnection. This allows all network participants to know the exact online/offline status of every node, enabling deterministic failover and eliminating guesswork in supervisory control.

02

Strict Topic Namespace Definition

Sparkplug enforces a rigid, well-known topic structure: namespace/group_id/message_type/edge_node_id/device_id. This eliminates the ambiguity of free-form MQTT topics.

  • namespace: spBv1.0
  • group_id: A logical grouping of nodes (e.g., a production line).
  • message_type: NBIRTH, DBIRTH, NDATA, DCMD, etc. This structure enables any compliant subscriber to instantly parse the origin and purpose of any message without prior configuration.
03

Rich Data Typing with Protobuf

Sparkplug mandates the use of Google Protocol Buffers (Protobuf) as the payload encoding. This provides a strongly typed, compact, and binary data contract. Each metric includes metadata defining its datatype (e.g., uint32, float, string), engineering units, and quality flags. This eliminates the brittle string parsing common in legacy SCADA systems, ensuring that a temperature value of 150.0 is unambiguously interpreted as a float in degrees Celsius.

04

Auto-Discovery of Devices and Metrics

The combination of Birth Certificates and a defined topic namespace enables true plug-and-play auto-discovery. When an edge node comes online, it publishes its NBIRTH message, which contains a list of all its connected devices. Each device then publishes its own DBIRTH with its specific metrics. A consuming application can dynamically build its data model by listening to these birth messages, removing the need for manual tag mapping and drastically reducing integration time.

05

Report by Exception

To conserve bandwidth on constrained industrial networks, Sparkplug supports Report by Exception (RBE). A node only publishes data when a metric's value changes beyond a configured deadband threshold. If a pressure sensor remains stable at 100 PSI, it stays silent. This contrasts with polled protocols like Modbus, which waste cycles requesting unchanging data. The Birth Certificate establishes the initial state, and only deltas are transmitted thereafter.

06

Decoupled Command and Control

Sparkplug provides specific message types for command and control (DCMD, NCMD) that are fully decoupled from data reporting. A command is published to a specific device's command topic, and the device responds on its data topic. This publish-subscribe model allows multiple authorized applications to issue commands without a direct, point-to-point connection. It enables a cloud-based dashboard and a local HMI to both control the same actuator without conflict.

MQTT SPARKPLUG EXPLAINED

Frequently Asked Questions

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

MQTT Sparkplug is an open, interoperable specification that defines how to use the MQTT protocol for mission-critical industrial applications by adding stateful session awareness, a structured topic namespace, and a rich, typed data model. While standard MQTT is a lightweight, agnostic publish-subscribe transport that knows nothing about the payload's content, Sparkplug mandates a strict topic structure (spBv1.0/group_id/message_type/edge_node_id/device_id) and requires payloads to be encoded in Google Protocol Buffers (Protobuf). This enforces a known schema, enabling any Sparkplug-compliant subscriber to immediately understand the data's structure, type, and origin without prior configuration. Critically, Sparkplug introduces a session state mechanism managed by a central MQTT broker, tracking the online/offline status of every edge node and device via BIRTH and DEATH certificates. This transforms MQTT from a stateless message bus into a stateful, self-describing industrial data backbone, enabling true plug-and-play interoperability and automatic tag discovery across heterogeneous SCADA, MES, and cloud systems.

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.