Inductive Automation’s Ignition is one of the most widely used SCADA platforms in industry. Yet it reaches its full potential in a Unified Namespace (UNS) only together with MQTT. The combination of Ignition and MQTT turns a classic SCADA installation into an event-driven node. This node publishes and consumes data through a central broker. Instead of maintaining every connection by hand, Ignition speaks over a shared backbone.
This article shows how Ignition and MQTT work together in practice. It explains the producer and consumer roles, the three Cirrus Link MQTT modules, and the structure of Sparkplug B. The focus stays on a clean UNS architecture without point-to-point links. The examples are vendor-neutral and apply to any Ignition installation.
Ignition and MQTT – the Roles in the Unified Namespace
A Unified Namespace gathers all production data in one central place. Every system publishes its data there. Every consumer reads it on demand. The broker acts as the single source of truth. For the fundamentals, see our article What is a Unified Namespace.
In this architecture, Ignition takes on two roles at once. That is exactly what makes the platform such a good fit for the UNS. Both roles run over the same MQTT infrastructure.
- Producer (edge → broker): Ignition reads tags from PLCs, OPC UA, or Modbus. It then publishes those values to the broker as Sparkplug B.
- Consumer / SCADA node (broker → visualization): Ignition subscribes to topics on the broker. The values return as tags and feed dashboards, trends, and alarms.
The link between Ignition and MQTT replaces the classic OT silos. In the past, every target system queried the data directly at the source. Each new connection meant another direct link. In the UNS, that effort disappears. Ignition publishes once, and any number of consumers read along.
The difference from a classic HTTP query is fundamental. HTTP works on a request-and-response pattern. Every new consumer loads the source again. MQTT instead distributes the data through publish and subscribe. The broker handles distribution, not the source system. Our article MQTT vs. HTTP compares both patterns in more detail.
The table below summarizes Ignition’s two roles in the UNS. Both run in parallel and over the same broker.
| Aspect | Producer role | Consumer role |
|---|---|---|
| Module | MQTT Transmission | MQTT Engine |
| Data direction | Ignition tags to broker | Broker to Ignition tags |
| Task | publish field and OPC UA values | subscribe and visualize data |
| Position | at the edge, near the machine | central, as a SCADA node |
The Three Cirrus Link MQTT modules
Ignition does not speak MQTT out of the box. The bridge between Ignition and MQTT comes from three Cirrus Link modules. Each module covers a clear role. Together they form a producer, a consumer, and an optional broker. The graphic below shows the data direction of each module.
MQTT Transmission – the publisher
The MQTT Transmission module makes Ignition a producer. It reads the configured Ignition tags. Those tags come from OPC UA or Modbus, for example. Transmission encodes the values automatically as Sparkplug B. It then publishes them to the broker. The developer does not build the topic structure by hand. The module creates it according to the Sparkplug standard.
A typical data flow starts right at the machine. A PLC delivers its values to Ignition over OPC UA. Ignition stores those values as tags. MQTT Transmission then publishes the tags as Sparkplug B. Our guide OPC UA to MQTT integration shows how to connect OPC UA sources cleanly to MQTT.
MQTT Engine – the subscriber
The MQTT Engine module makes Ignition a consumer. It subscribes to the Sparkplug B topics on the broker. Then it decodes the incoming messages. The values reappear as clean Ignition tags. A SCADA developer sees data from other edge nodes as local tags. Engine also tracks the lifecycle of a Sparkplug session. When a device drops out, it marks the affected tags as stale.
MQTT Distributor – the embedded broker
The MQTT Distributor module brings an MQTT broker directly into Ignition. It builds on Cirrus Link’s Chariot technology. For smaller setups, this embedded broker is enough. That way, no separate broker server is needed. Larger architectures usually run a dedicated broker instead. It then operates separately from the SCADA platform.
The three modules sort cleanly by role and data direction. The overview below shows when each module fits.
| Module | Role | Data direction | Typical use |
|---|---|---|---|
| MQTT Transmission | Publisher | Ignition tags to broker | edge node that publishes field and OPC UA data |
| MQTT Engine | Subscriber | Broker to Ignition tags | SCADA node that visualizes the UNS |
| MQTT Distributor | Broker | central hub | embedded broker for smaller setups |
Sparkplug B – Structure and Lifecycle in the UNS
MQTT alone only defines the transport. Sparkplug B defines the meaning of the messages. This specification structures topics and payloads uniformly. That is exactly why producers and consumers understand each other without prior arrangement. For a deeper introduction, see our post What is Sparkplug B.
Every Sparkplug topic follows a fixed namespace. It reads spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}. The five segments assign each message clearly. The first segment is the fixed version. Then come group, message type, edge node, and device. This structure makes the topics predictable and machine-readable.
The message type drives the lifecycle of a session. Sparkplug B works statefully and uses birth and death certificates. The most important types at a glance:
NBIRTH/DBIRTH: node and devices come online. They send their full tag set as a birth certificate.NDATA/DDATA: during operation, Sparkplug sends only changes. This principle is called report-by-exception and saves bandwidth.NDEATH/DDEATH: on disconnect or loss, the death certificate applies. The broker reports the outage through the last-will message.
This session awareness is a core benefit of Sparkplug B. A consumer always knows whether a source is online. A silent value stays distinct from a real outage. For clean topic design, our guide MQTT topic namespace best practices offers practical rules.
Sparkplug B also knows a state topic for the primary host. A consumer such as MQTT Engine acts as the primary host. It publishes its online status to a STATE topic. When this host loses its connection, the edge nodes notice at once. They then buffer their data locally. After the host returns, they send the buffered values. So no value is lost during short network outages. This combination is what makes Ignition and MQTT reliable in the UNS.
Ignition as a SCADA Node in the Unified Namespace
In the consumer role, Ignition becomes the visualization layer of the UNS. Through MQTT Engine, it subscribes to the relevant topics. The data appears as tags and feeds Perspective or Vision screens. An operator sees values from many sources in one place. It makes no difference which edge node produced the data.
The key change is the removal of point-to-point coupling. In the past, SCADA held its own drivers to every PLC. Each source meant a separate, direct connection. In the UNS, Ignition instead subscribes only to the broker. New data sources appear automatically once their edge node publishes. Our article SCADA in the Unified Namespace describes this new role in detail.
A UNS also carries several consumers at once. Besides Ignition, a historian, an MES, or analytics services often read along. They all subscribe to the same broker and the same topics. Ignition is therefore just one consumer among many. A new service connects without the source noticing. This decoupling is the real win from Ignition and MQTT.
How i-flow fits in: i-flow can serve as a preconfigured UNS hub with an integrated broker and Sparkplug B support. Ignition connects to it as a producer and consumer, without teams setting up the broker infrastructure themselves. Responsibility for the namespace and scaling then sits centrally in the hub. Our post MQTT in the Unified Namespace explains why MQTT is the right backbone for this.
Best Practices and Common Mistakes
The combination of Ignition and MQTT is robust once a few rules are in place. The points below sum up the most important lessons.
Do
- Use the primary host state: Configure a primary host identifier. That way, edge nodes know whether the responsible consumer is reachable, and they buffer when needed.
- Design the namespace cleanly: Define
group_idandedge_node_idby site and asset. A clear structure stays maintainable long term. - Trust report-by-exception: Publish only relevant tags with sensible deadbands. That noticeably relieves the broker and the network.
Avoid
- Publishing every tag blindly: Sending thousands of tags without a deadband overloads the UNS. Choose deliberately what truly belongs in the namespace.
- Ignoring the Sparkplug state: Without the birth and death certificates, stale values look current. That leads to misreadings in SCADA.
Conclusion
The combination of Ignition and MQTT turns a SCADA platform into a full UNS node. Through MQTT Transmission, Ignition publishes data as Sparkplug B. Through MQTT Engine, it consumes and visualizes it again. Sparkplug B provides the uniform structure and the session awareness. The result is an architecture without fragile point-to-point links. Three key takeaways:
- Ignition is producer and consumer: the same platform publishes edge data and visualizes the whole namespace through a broker.
- Cirrus Link supplies the bridge: Transmission, Engine, and Distributor cover publish, subscribe, and an optional broker.
- Sparkplug B structures the UNS: a fixed topic namespace and lifecycle certificates make data predictable and outages visible.
