MQTT Transmission supports two different configurations to send data using MQTT:
To determine which one to use we need to understand the difference between MQTT and MQTT Sparkplug.
MQTT is a lightweight messaging protocol designed for efficient communication between devices. It was created to address the challenges of transmitting data reliably over low-bandwidth, high-latency, or unstable networks — conditions commonly found in industrial settings, remote monitoring systems, and embedded devices.
MQTT follows a publish-subscribe model. Devices (referred to as clients) connect to a central broker, which manages the flow of messages. Rather than devices communicating directly with each other, they publish data to specific topics. Other devices that have subscribed to those topics automatically receive updates. This design allows for scalable, flexible communication across numerous endpoints.
MQTT topic structures are flexible but unstructured and MQTT payloads are flexible but undefined.
MQTT runs on top of TCP, with minimal overhead. It uses lightweight headers and requires minimal processing power, making it ideal for environments where bandwidth, energy, or resources are constrained.
Additionally, a specific QoS (Quality of Service) can be set to the connection, so the client and broker know how hard they should try to deliver messages in case of failures. This ensures reliability even in unstable network conditions.
These characteristics have made MQTT a popular choice in IoT ecosystems, enabling everything from smart home automation to large-scale industrial control systems.
MQTT has become a key messaging protocol for Industrial IoT (IIoT) thanks to its lightweight design and efficient data delivery. Yet despite its strengths, MQTT lacks a standardized way to define and structure data, often leaving developers to build custom logic for every device type. This approach works — but it doesn’t scale easily.
Imagine a global manufacturing company with thousands of machines and sensors. In absence of a common terminology for MQTT reporting, the same data reported by various departments, production lines and machines might get reported differently. For example, here 3 machines are reporting the same data for produced units ("units"), but each machine manufacturer or systems integrator might have decided on a different structure. These inconsistencies may seem minor, but in large-scale Industrial (IIoT) deployments, they compound quickly. Data from hundreds or thousands of devices becomes difficult to organize, analyze, and trust. As Industrial (IoT) ecosystems grow, so does the risk of misinterpreted data, broken integrations, and costly downtime.
This is where MQTT Sparkplug comes in. Sparkplug builds on MQTT’s foundation, adding data standardization, state awareness, and improved scalability — all essential for complex IIoT environments.
MQTT Sparkplug is an open-source specification designed to bring structure and standardization to MQTT data in industrial environments. Built on top of MQTT, Sparkplug introduces a standardized payload format, a defined topic structure, and a set of state management rules. This ensures that devices, sensors, and software systems all speak the same language to seamlessly integrate data and improve scalability.
Sparkplug achieves this by defining three key elements:
By combining these features, Sparkplug transforms MQTT from a flexible data transport protocol into a robust, self-describing communication standard for IIoT. It eliminates the need for custom parsing logic, reduces integration headaches, and enables true plug-and-play scalability across industrial networks.
| Aspect | MQTT | Sparkplug |
|---|---|---|
| Data Format | Flexible but undefined. Devices may send data in JSON, plain text, or binary, requiring custom parsing logic | Flexible but undefined. Devices may send data in JSON, plain text, or binary, requiring custom parsing logic |
| Topic Structure | Flexible but unstructured. Topic naming conventions vary across devices, often requiring manual configuration | Uses a strict topic structure that organizes data consistently across devices |
| State Awareness | No built-in state management. Systems must rely on custom logic to track device connectivity | Introduces birth and death certificates to ensure systems always know which devices are online or offline |
| Device Integration | Adding new devices may require manual updates to data parsing logic or custom topic rules | Standardized structure enables plug-and-play scalability for new devices |
| Data Integrity | No built-in mechanisms to prevent stale data from being mistaken for live updates | Ensures stale data is removed when devices disconnect, reducing the risk of inaccurate insights |
| Bandwidth Efficiency | Supports efficient communication, but payload size can vary depending on data format | Uses Protobuf for compact, efficient payloads that minimize bandwidth usage |
| Discover Data Sources | No built-in mechanisms for discovering data sources and requires manual configuration | Built-in mechanism for finding new data sources within the network |
The design of Sparkplug revolves around three key system components: the Edge Node, the Host Application, and the MQTT Broker. Each plays a distinct role in managing data flow and maintaining system state.
Edge Node
An Edge Node is any device or system that collects data from sensors, machines, or other field devices. It acts as the primary data source in a Sparkplug environment.
Edge Nodes publish data to the MQTT Broker using Sparkplug’s defined topic structure and payload format. Crucially, they are also responsible for sending birth certificates when they come online and death certificates if they unexpectedly disconnect. These messages keep the system aware of device status — a critical feature for ensuring data integrity.
This is the MQTT Transmission module using Transmitter configuration
Host Application
The Host Application is the system that consumes data from Edge Nodes. Typically, this is an industrial control system, IoT platform, or data analytics tool.
The Host Application subscribes to Sparkplug-compliant topics, ensuring it receives data in a structured format. Additionally, Host Applications monitor device status messages (birth and death certificates) to maintain awareness of which devices are active or offline. This helps streamline alarm management, data visualization, and system diagnostics.
This is the MQTT Engine module
MQTT Broker
The MQTT Broker serves as the central hub for all data exchanges. Acting as a message router, it handles incoming data from Edge Nodes and distributes it to Host Applications based on Sparkplug’s standardized topic structure.
Unlike traditional MQTT brokers that only relay messages, a Sparkplug-enabled broker plays a vital role in maintaining system state. It stores session details for connected devices and ensures that death certificates are published when connections are lost, providing essential visibility within the Sparkplug system.
This is the MQTT Distributor module or Chariot® MQTT Server
By introducing standardized messaging rules, Sparkplug ensures that data is not only delivered efficiently but also consistently understood across devices and applications. At the core of this system are Sparkplug’s defined message types, topic structure, and state management mechanisms.
MQTT Topic Namespace and Hierarchy
Sparkplug enforces a strict topic structure that organizes data consistently across devices and systems. Each topic follows a predefined format of Sparkplug's topic format: spBv1.0/<Group ID>/<Message Type>/<Edge Node ID>/<Device ID> where:
This structure simplifies data organization, ensuring that all systems can identify device sources and message types without custom logic.
Payload Format
Sparkplug uses Google’s Protocol Buffers (Protobuf) to encode data efficiently. Protobuf structures data in a compact binary format that reduces bandwidth usage while maintaining flexibility for complex data models.
Each payload follows a consistent format that includes:
This structured payload eliminates the ambiguity seen in traditional MQTT deployments, where payloads can vary significantly between devices.
Birth and Death Certificates
To maintain system awareness, Sparkplug introduces birth and death certificates.
Real-Time State Awareness
Sparkplug’s state management goes beyond simple message delivery. By requiring devices to maintain active connections with the broker, Sparkplug ensures that system state is always known.
When devices disconnect, the broker automatically alerts Host Applications by publishing a death certificate — preventing stale or inaccurate data from being mistaken as live.
The MQTT Sparkplug Transmitter is designed for complex IIoT environments where data consistency, system state awareness, and scalability are critical.
It is generally used at the Edge of an OT infrastructure.
The UNS Transmitter is ideal for lightweight IT deployments where minimal data points are required by Enterprise consuming clients.
It is generally used on the IT side of an OT/IT infrastructure