MQTT

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 in Industrial IoT (IIoT) 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

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:

• Payload Structure: Sparkplug mandates a consistent data format using Google’s Protocol Buffers (Protobuf), which efficiently encodes structured data for faster transmission and minimal overhead.
• Topic Namespace: Sparkplug enforces a hierarchical topic structure, eliminating guesswork when organizing data across multiple devices and systems.
• State Awareness: Sparkplug introduces a birth and death certificate mechanism, allowing systems to track when devices connect, disconnect, or experience issues — a critical feature for industrial environments.

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.

Key Differences

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

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

How MQTT Sparkplug Works

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> where:

• spBv1.0 – Identifies the Sparkplug protocol version.
• Group ID – Represents a logical grouping of devices (e.g., production line, factory floor).
• Message Type – Defines the message purpose (e.g., NBIRTH, NDATA, NDEATH).
• Edge Node ID – Identifies the originating device.

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:

• Metrics – The actual data points being transmitted
• Timestamps – For precise data tracking
• Metadata – Additional details about the device or data source.

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.

• Birth Certificate (NBIRTH): Sent by an Edge Node when it comes online.
  • This message announces the node’s presence, publishes its available metrics, and signals to the system that the device is active.
• Death Certificate (NDEATH): Sent by the MQTT Broker if an Edge Node unexpectedly disconnects.
  • This ensures the system is immediately aware when a device goes offline.

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.

Which One to Use?

Plain MQTT is ideal for lightweight IoT deployments where flexibility is key, and devices produce minimal data points.

MQTT Sparkplug is better suited for complex IIoT environments where data consistency, system state awareness, and scalability are critical.

Transmitters

A Transmitter is an agent that monitor tags, converts them to Sparkplug Messages, and publishes to an MQTT Server. 

• Messages can be consumed by any Sparkplug Host Application such as MQTT Engine.
• Any MQTT client created by the agent will publish and subscribe to data using the Sparkplug B protocol.
  • Uses the namespace spBv1.0
  • Using the Sparkplug B protocol provides the benefits of session management including Primary Host ID
  • Understands Ignition UDTs and can be configured to publish UDT definitions in BIRTH messages
  • Is capable of publishing 10s of thousands data messages contain multiple tag change events

UNS Transmitters

A UNS Transmitter is an agent that monitors tags and publishes them as MQTT Messages with a JSON payload to an MQTT Server. 

The UNS Transmitter would be configured to read tags from a UNS structure, such as created by MQTT Engine, and publish tag changes over MQTT to any Enterprise consuming clients.

• Messages can be consumed by any MQTT client that can parse JSON messages.
• Any MQTT client created by the agent will only publish data using the MQTT protocol.
  • Uses the namespace unsAv1.0 (which can be disabled)
  • Publishes a single data message for each tag when QualifiedValue of the tag changes 
  • Publishes a single properties message is published for each tag on every client connection
  • Publishes the leaf tags of Ignition UDTs and the structure of the UDT (i.e. UDT name itself and folders in the UDT) become topic tokens.

Always less efficient than Sparkplug - orders of magnitude less