Ignition und MQTT – Zusammenspiel im Unified Namespace

Inductive Automations Ignition ist eine der verbreitetsten SCADA-Plattformen im industriellen Umfeld. Ihre volle Stärke im Unified Namespace (UNS) entfaltet sie aber erst in Kombination mit MQTT. Das Zusammenspiel von Ignition und MQTT verwandelt eine klassische SCADA-Installation in einen ereignisgetriebenen Knoten. Dieser Knoten publiziert und konsumiert Daten über einen zentralen Broker. Statt jede Verbindung einzeln zu pflegen, spricht Ignition über ein gemeinsames Rückgrat.

Dieser Artikel zeigt, wie Ignition und MQTT praktisch zusammenwirken. Er erklärt die Rollen als Producer und Consumer, die drei MQTT-Module von Cirrus Link und den Aufbau von Sparkplug B. Der Fokus liegt auf einer sauberen UNS-Architektur ohne Punkt-zu-Punkt-Verbindungen. Die Beispiele sind herstellerneutral und lassen sich auf jede Ignition-Installation übertragen.

Ignition und MQTT – die Rollen im Unified Namespace

Ein Unified Namespace bündelt alle Produktionsdaten an einem zentralen Ort. Jedes System publiziert seine Daten dorthin. Jeder Consumer greift bei Bedarf darauf zu. Der Broker bildet dabei die Single Source of Truth. Wer die Grundlagen vertiefen möchte, findet sie in unserem Artikel Was ist ein Unified Namespace.

In dieser Architektur übernimmt Ignition zwei Rollen gleichzeitig. Genau das macht die Plattform so passend für den UNS. Beide Rollen laufen über dieselbe MQTT-Infrastruktur.

• Producer (Edge → Broker): Ignition liest Tags aus SPS, OPC UA oder Modbus. Anschließend publiziert es diese Werte als Sparkplug B an den Broker.
• Consumer / SCADA-Knoten (Broker → Visualisierung): Ignition abonniert Topics vom Broker. Die Werte fließen als Tags zurück und speisen Dashboards, Trends und Alarme.

Die Verbindung zwischen Ignition und MQTT ersetzt damit die klassischen OT-Silos. Früher fragte jedes Zielsystem die Daten direkt beim Quellsystem ab. Jede neue Anbindung bedeutete eine weitere direkte Verbindung. Im UNS entfällt dieser Aufwand. Ignition publiziert einmal, und beliebig viele Consumer lesen mit.

Der Unterschied zu einer klassischen HTTP-Abfrage ist grundlegend. HTTP arbeitet nach dem Muster Anfrage und Antwort. Jeder neue Consumer belastet die Quelle dabei erneut. MQTT verteilt die Daten stattdessen über Publish und Subscribe. Der Broker übernimmt die Verteilung, nicht das Quellsystem. Einen genaueren Vergleich beider Muster liefert unser Beitrag MQTT vs. HTTP.

Die folgende Tabelle fasst die beiden Rollen von Ignition im UNS zusammen. Beide laufen parallel und über denselben Broker.

Die drei MQTT-Module von Cirrus Link

Ignition spricht MQTT nicht ab Werk. Die Brücke zwischen Ignition und MQTT liefern drei Module von Cirrus Link. Jedes Modul deckt eine klare Rolle ab. Zusammen bilden sie Producer, Consumer und einen optionalen Broker. Die folgende Grafik zeigt die Datenrichtung je Modul.

MQTT Transmission – der Publisher

Das Modul MQTT Transmission macht Ignition zum Producer. Es liest die konfigurierten Ignition-Tags aus. Diese Tags stammen zum Beispiel aus OPC UA oder Modbus. Transmission kodiert die Werte automatisch als Sparkplug B. Danach publiziert es sie an den Broker. Der Entwickler muss die Topic-Struktur nicht von Hand bauen. Das Modul erzeugt sie nach dem Sparkplug-Standard.

Ein typischer Datenfluss beginnt direkt an der Maschine. Eine SPS liefert ihre Werte über OPC UA an Ignition. Ignition legt diese Werte als Tags ab. MQTT Transmission publiziert die Tags anschließend als Sparkplug B. Wie sich OPC-UA-Quellen sauber an MQTT anbinden lassen, zeigt unsere Anleitung OPC UA zu MQTT integrieren.

MQTT Engine – der Subscriber

Das Modul MQTT Engine macht Ignition zum Consumer. Es abonniert die Sparkplug-B-Topics am Broker. Dann dekodiert es die eingehenden Nachrichten. Die Werte erscheinen wieder als saubere Ignition-Tags. So sieht ein SCADA-Entwickler die Daten anderer Edge-Nodes wie lokale Tags. Engine kennt dabei den Lifecycle einer Sparkplug-Session. Fällt ein Gerät aus, markiert es die betroffenen Tags als veraltet.

MQTT Distributor – der eingebettete Broker

Das Modul MQTT Distributor bringt einen MQTT-Broker direkt in Ignition. Er basiert auf der Chariot-Technologie von Cirrus Link. Für kleinere Setups genügt dieser eingebettete Broker. So braucht es keinen separaten Broker-Server. Größere Architekturen setzen dagegen meist einen dedizierten Broker ein. Dieser läuft dann getrennt von der SCADA-Plattform.

Die drei Module lassen sich klar nach Rolle und Datenrichtung ordnen. Die folgende Übersicht zeigt, wann welches Modul zum Einsatz kommt.

Sparkplug B – Struktur und Lifecycle im UNS

MQTT allein definiert nur den Transport. Die Bedeutung der Nachrichten legt Sparkplug B fest. Diese Spezifikation strukturiert Topics und Payload einheitlich. Genau dadurch verstehen sich Producer und Consumer ohne Absprache. Eine tiefere Einführung bietet unser Beitrag Was ist Sparkplug B.

Jedes Sparkplug-Topic folgt einem festen Namensraum. Er lautet spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}. Die fünf Segmente ordnen jede Nachricht klar zu. Das erste Segment ist die feste Version. Danach folgen Gruppe, Nachrichtentyp, Edge-Node und Gerät. Diese Struktur macht die Topics vorhersehbar und maschinenlesbar.

Der Nachrichtentyp steuert den Lifecycle einer Session. Sparkplug B arbeitet stateful und mit Geburts- sowie Todes-Zertifikaten. Die wichtigsten Typen im Überblick:

• NBIRTH / DBIRTH: Node und Geräte melden sich an. Sie senden ihr volles Tag-Set als Geburts-Zertifikat.
• NDATA / DDATA: Im Betrieb überträgt Sparkplug nur noch Änderungen. Dieses Prinzip heißt Report-by-Exception und spart Bandbreite.
• NDEATH / DDEATH: Bei Abmeldung oder Verbindungsverlust greift das Todes-Zertifikat. Der Broker meldet den Ausfall über die Last-Will-Nachricht.

Diese Session Awareness ist ein zentraler Vorteil von Sparkplug B. Ein Consumer weiß jederzeit, ob eine Quelle online ist. Ein stiller Wert wird so von einem echten Ausfall unterscheidbar. Wer die Topic-Struktur sauber schneiden will, findet praktische Regeln in unserem Leitfaden MQTT Topic Namespace Best Practices.

Ergänzend kennt Sparkplug B ein State-Topic für den Primary Host. Ein Consumer wie MQTT Engine tritt darin als primärer Host auf. Er publiziert seinen Online-Status auf ein STATE-Topic. Verliert dieser Host die Verbindung, erkennen die Edge-Nodes das sofort. Sie puffern ihre Daten dann lokal. Nach der Rückkehr senden sie die gepufferten Werte nach. So geht im UNS auch bei kurzen Netzausfällen kein Wert verloren. Genau diese Kombination macht Ignition und MQTT im UNS zuverlässig.

Ignition als SCADA-Knoten im Unified Namespace

In der Consumer-Rolle wird Ignition zur Visualisierungsebene des UNS. Über MQTT Engine abonniert es die relevanten Topics. Die Daten erscheinen als Tags und speisen Perspective- oder Vision-Oberflächen. Ein Bediener sieht Werte aus vielen Quellen an einem Ort. Dabei spielt es keine Rolle, welcher Edge-Node die Daten erzeugt hat.

Der entscheidende Unterschied liegt im Wegfall der Punkt-zu-Punkt-Kopplung. Früher hielt SCADA eigene Treiber zu jeder SPS. Jede Quelle bedeutete eine separate, direkte Verbindung. Im UNS abonniert Ignition stattdessen nur den Broker. Neue Datenquellen erscheinen automatisch, sobald ihr Edge-Node publiziert. Die neue Rolle von SCADA im UNS beschreibt unser Artikel SCADA im Unified Namespace im Detail.

Ein UNS trägt zudem mehrere Consumer gleichzeitig. Neben Ignition lesen oft ein Historian, ein MES oder Analytics-Dienste mit. Alle abonnieren denselben Broker und dieselben Topics. Ignition ist damit nur ein Consumer unter vielen. Ein neuer Dienst dockt an, ohne dass die Datenquelle etwas davon merkt. Diese Entkopplung ist der eigentliche Gewinn aus Ignition und MQTT.

Wie i-flow ergänzt: i-flow kann als vorkonfigurierter UNS-Hub mit integriertem Broker und Sparkplug-B-Unterstützung dienen. Ignition dockt darüber als Producer und Consumer an, ohne dass Teams die Broker-Infrastruktur selbst aufsetzen müssen. Die Verantwortung für Namespace und Skalierung liegt dann zentral im Hub. Warum MQTT dafür das passende Backbone ist, zeigt der Beitrag MQTT im Unified Namespace.

Best Practices und typische Fehler

Das Zusammenspiel von Ignition und MQTT ist robust, wenn ein paar Regeln sitzen. Die folgenden Punkte fassen die wichtigsten Erfahrungen zusammen.

Do

• Primary Host State nutzen: Konfiguriere einen Primary-Host-Identifier. So wissen Edge-Nodes, ob der zuständige Consumer erreichbar ist, und puffern bei Bedarf.
• Namespace sauber schneiden: Lege group_id und edge_node_id nach Standort und Anlage fest. Eine klare Struktur bleibt langfristig wartbar.
• Report-by-Exception vertrauen: Publiziere nur relevante Tags mit sinnvollen Deadbands. Das entlastet Broker und Netzwerk spürbar.

Avoid

• Jeden Tag blind publizieren: Wer tausende Tags ohne Deadband sendet, überlastet den UNS. Wähle bewusst aus, was wirklich in den Namespace gehört.
• Sparkplug State ignorieren: Ohne Beachtung der Geburts- und Todes-Zertifikate wirken veraltete Werte wie aktuelle. Das führt zu Fehlinterpretationen im SCADA.

Fazit

Das Zusammenspiel von Ignition und MQTT macht aus einer SCADA-Plattform einen vollwertigen UNS-Knoten. Über MQTT Transmission publiziert Ignition Daten als Sparkplug B. Über MQTT Engine konsumiert und visualisiert es sie wieder. Sparkplug B liefert dabei die einheitliche Struktur und die Session Awareness. So entsteht eine Architektur ohne fragile Punkt-zu-Punkt-Verbindungen.

Drei zentrale Erkenntnisse

1. Ignition ist Producer und Consumer: Dieselbe Plattform publiziert Edge-Daten und visualisiert den gesamten Namespace über einen Broker.
2. Cirrus Link liefert die Brücke: Transmission, Engine und Distributor decken Publish, Subscribe und einen optionalen Broker ab.
3. Sparkplug B strukturiert den UNS: Fester Topic-Namensraum und Lifecycle-Zertifikate machen Daten vorhersehbar und Ausfälle sichtbar.