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.
Glossary
MQTT Sparkplug

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
MQTT Sparkplug operates within a broader ecosystem of industrial communication and data management standards. Understanding these related concepts is essential for designing a complete, interoperable Industry 4.0 architecture.

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.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us