MQTT Connection Settings im Unified Namespace (UNS)

Im Kontext von Industrie 4.0 und dem Industrial IoT (IIoT) etabliert sich der Unified Namespace (UNS) zunehmend als zentrale Kommunikationsplattform. Ziel ist ein einheitlicher Echtzeit-Datenraum, in dem IT- und OT-Systeme nahtlos integriert sind. Eine Schlüsselrolle übernimmt dabei das schlanke, eventbasierte Protokoll MQTT, das Sensoren, Steuerungen und IT-Systeme effizient vernetzt. Fabriksysteme – als MQTT Clients – stellen hierzu eine Verbindung (Connection) zum MQTT Broker her. Die dabei gewählten MQTT Verbindungseinstellungen (Connection Settings), wie etwa Clean Session oder Last Will, beeinflussen die Stabilität und Zuverlässigkeit der Kommunikation erheblich. Besonders im produktionskritischen Umfeld ist eine sorgfältige Konfiguration entscheidend. Dieser Artikel erklärt, wie zentrale Verbindungsparameter das Verhalten angebundener Systeme im UNS beeinflussen.

Was ist ein Unified Namespace (UNS)?

Ein Unified Namespace (UNS) bezeichnet einen zentralen Datenraum, welcher alle Daten einer Fabrik organisiert und in Echtzeit zugänglich macht. So entsteht ein Single Source of Truth für die Datenströme einer Fabrik. Details sowie weitere Vorteile finden Sie hier. MQTT wird dabei häufig als technologische Grundlage eingesetzt, da es eine asynchrone, eventbasierte und schlanke Kopplung von Datenquellen und -senken über MQTT Topics ermöglicht. Die Architektur ist hochgradig skalierbar, da beliebig viele Fabriksysteme (MQTT Clients) angebunden werden können.

Was ist MQTT?

MQTT (Message Queuing Telemetry Transport) ist ein Client-Server-Netzwerkprotokoll, das auf dem Publisher/Subscriber Modell basiert​. Ein zentrales Element ist der Broker (Server), über welchen angebundene MQTT-Clients Nachrichten austauschen: Ein Publisher-Client sendet Daten mit einem bestimmten Topic (Betreff), Subscriber-Clients können diese Topics abonnieren und empfangen die entsprechenden Nachrichten. Dabei ist der Nachrichtenaustausch sehr schlank und effizient (detailliertere Informationen zu MQTT finden Sie hier).

MQTT Connection im UNS: Aufbau und Verhalten

Um eine Verbindung mit dem MQTT Broker aufzubauen, verwendet MQTT Clients eine MQTT-Bibliothek. Diese sind für nahezu alle gängigen Programmiersprachen verfügbar. Dabei können im Produktionsumfeld dutzende, hunderte oder gar tausende Clients parallel an den Broker angebunden werden. Typische Beispiele für MQTT Clients sind:

1. CNC-Fräsmaschine: Die Maschine sendet als Publisher regelmäßig den Betriebsstatus („aktiv“, „Störung“, „Wartung“) an das zentrale Andon Board. Gleichzeitig empfängt sie neue Auftragsdaten des ERP als Subscriber.
2. Temperatursensor: Ein Sensor überträgt als Publisher kontinuierlich Prozesswerte wie „104,4 °C“ an ein übergeordnetes Condition-Monitoring-System. Das System nutzt die Daten zur Prozessüberwachung.
3. ERP-System (z. B. SAP): Das ERP agiert als MQTT Subscriber, um Produktionsdaten zu empfangen (z. B. Gutteile) und automatisiert Folgeprozesse wie Nachschub oder Materialbuchungen.

Integrationsszenarien

Hierbei gibt es zwei Integrationsszenarien für Fabriksysteme:

1. Nicht MQTT native Systeme, die MQTT nicht direkt unterstützen und über Gateways angebunden werden (z. B. SPS-Steuerungen). Diese fungieren als Übersetzer zwischen den angebundenen Systemen und MQTT.
2. MQTT native Systeme, die MQTT-Bibliotheken direkt nutzen (z. B. moderne Sensoren oder Applikationen).

Die Rolle des MQTT Brokers

Der MQTT Broker bildet das zentrale Steuerungselement im MQTT-Netzwerk. Er verwaltet alle Verbindungen, regelt den Nachrichtenaustausch und prüft Berechtigungen. Nur durch die korrekte Konfiguration und Verwaltung dieser Prozesse kann der reibungslose Betrieb eines produktionsnahen MQTT-Netzwerks im UNS gewährleistet werden. Zu seinen Kernaufgaben zählen:

1. Empfang und Weiterleitung von Nachrichten zwischen Clients
2. Prüfung der Publish- und Subscribe-Berechtigungen
3. Verwaltung von Nachrichten mit Quality of Service (QoS) Level 1 und 2
4. Zuordnung der Nachrichten an berechtigte Subscriber

MQTT Kommunikationsphasen

Eine MQTT Connection verbindet einen Client (z. B. Maschine, Sensor) mit einem MQTT Broker. Dabei erfolgt die Verbindung zwischen Client und Broker in folgenden Phasen:

1. Connect: Der Client sendet ein CONNECT-Paket an den Broker, das Verbindungsparameter wie Client ID, Clean Session, Last Will usw. enthält.
2. Der Broker antwortet mit einem CONNACK-Paket, das den Verbindungsstatus bestätigt oder ablehnt.
3. Zusätzlich sendet der Client regelmäßig PINGREQ-Pakete (Ping Request), um die Verbindung aktiv zu halten.
4. Der Broker antwortet darauf mit PINGRESP (Ping Response). PINGREQ und PINGRESP sind ein essenzieller Mechanismus zur Verbindungsüberwachung (siehe Keep Alive unten).
5. Disconnect: Der Client beendet die Verbindung kontrolliert über ein DISCONNECT-Paket. Erfolgt kein sauberer Disconnect (z. B. bei Stromausfall), greift der Broker auf den konfigurierten Last Will zurück.

MQTT Connection Settings

Zur Verbindung von Client und Broker sendet der Client zunächst einen MQTT CONNECT Anfrage an den Broker. Diese Anfrage besteht aus den drei obligatorischen Parametern clientID, cleanSession und keepAlive sowie den optionalen Parametern wie username, password, lastWillTopic, lastWillQos, lastWillMessage und lastWillRetain.

Client ID

Die Client ID ist ein zwingend erforderlicher Parameter bei jeder MQTT-Verbindung. Sie identifiziert den MQTT Client eindeutig gegenüber dem Broker. Die Wahl der Client ID hat direkten Einfluss auf die Sitzungsverwaltung, insbesondere in Verbindung mit dem Parameter Clean Session (siehe nächstes Kapitel).

• Eindeutigkeit ist Pflicht: Jeder Client, der sich mit einem Broker verbindet, muss eine eindeutige Client ID verwenden. Verbindet sich ein zweiter Client mit derselben ID, wird die bestehende Verbindung vom Broker getrennt.
• Persistente Sitzungen erfordern Konsistenz: Bei Clean Session = false ist eine gleichbleibende Client ID essenziell. Nur so kann der Broker die Session, inklusive Subscriptions und ausstehender QoS-Nachrichten, korrekt zuordnen und beim Reconnect wiederherstellen.
• Best Practices: Verwende systematisch generierte, sprechende IDs (z.B. iflow-edge-id124, plc123-gw).

Clean Session

Clean Session ist ein zentraler Parameter einer MQTT-Verbindung und beeinflusst die Sitzungsverwaltung zwischen Client und Broker. Diese Einstellung bestimmt, ob Broker und Client eine persistente Sitzung aufbauen, oder ob der Broker bei jeder Verbindung mit dem Client eine neue, temporäre Session startet.

Übersicht

MQTT Connection Settings: Keep Alive

Der Parameter Keep Alive definiert das maximale Zeitintervall (in Sekunden), das zwischen zwei Nachrichten eines Clients an den Broker vergehen darf. Auch wenn der Client keine Nutzdaten über Publish/Subscribe überträgt, muss der Client innerhalb dieses Intervalls ein Ping Request (PINGREQ) senden, um die Verbindung aktiv zu halten. Der Broker erwartet diese Lebenszeichen regelmäßig und antwortet mit einer Ping Response (PINGRESP). Bleiben diese Nachrichten aus, wird die Verbindung als inaktiv betrachtet und geschlossen.

• Verbindungsüberwachung: Der Keep-Alive-Wert dient dem Broker zur Erkennung abgebrochener Verbindungen, etwa durch Netzwerkprobleme oder unerwartete Client-Abstürze.
• Heartbeat-Funktion: Auch ohne Publish/Subscribe-Daten sendet der Client regelmäßig ein PINGREQ und erhält vom Broker ein PINGRESP, um die Verbindung aufrechtzuerhalten.
• Best Practice:
  • Wähle den Keep-Alive-Wert passend zur Anwendung: Niedrig (1–10 s) für zeitkritische Systeme (z. B. bei Steuerungen), höher (60–120 s) bei batteriebetriebenen oder bandbreitensensiblen Clients (z. B. mobile Geräte oder Sensoren).
  • Halte den Keep-Alive-Wert synchron mit Netzwerkinfrastruktur, Firewalls oder Proxies, die inaktive TCP-Verbindungen frühzeitig trennen könnten.

MQTT Username und Passwort

Die MQTT-Verbindungsparameter „username“ und „password“ dienen der Authentifizierung des Clients gegenüber dem Broker. Dies ist zwar optional, allerdings in sicherheitskritischen Umgebungen wie industriellen Netzwerken essentiell.

• Zugangskontrolle: Der Broker kann auf Basis von Benutzername und Passwort entscheiden, ob sich ein Client verbinden darf. Zusätzlich (optional) kann der Broker feststellen, welcher User auf welche Topics Publish- oder Subscribe-Rechte hat.
• Sicherheit: Der Client überträgt die Authentifizierungsdaten im Klartext, wenn keine Transportverschlüsselung (z. B. TLS) eingesetzt wird. Deshalb ist die Verwendung von TLS dringend zu empfehlen.

MQTT Connection Settings: Last Will

Der Last Will (vollständig: Last Will and Testament) ist ein optionaler, aber äußerst wichtig im Kontext von MQTT Connection Settings. Dieser definiert, welche Nachricht der Broker im Falle eines unerwarteten Verbindungsabbruchs im Namen des Clients veröffentlichen soll. Damit kann der Broker andere Systeme über den Ausfall informieren. Weitere Details zu Last Will finden Sie hier.

• Fehlertoleranz: Der Last Will dient als „Notfallnachricht“ und ermöglicht es, den Verlust eines Clients zu erkennen und automatisiert zu reagieren (z. B. Alarm, Rückfallstrategie, Anzeige im HMI).
• Auslöser: Der Broker veröffentlicht den Last Will, wenn ein Client nicht sauber disconnected (z. B. bei Stromausfall, Netzwerkfehler, Crash). Bei einem regulären Disconnect sendet der Broker den Last Will nicht.
• Konfiguration: Der Last Will wird beim Verbindungsaufbau im CONNECT-Paket mitgegeben. Er umfasst Topic, Nachricht, QoS und das Retain-Flag.

Last Will Topic

Das Last Will Topic bestimmt, auf welchem Topic der Broker die Last-Will-Nachricht veröffentlicht. Es sollte eindeutig und logisch benannt sein. So können andere Systeme gezielt auf Ausfallinformationen reagieren, indem sie gezielt diese Topics abonnieren. Zum Beispiel:

• status/iflow-edge-id123
• system/iflow-edge-id123/will

Last Will QoS

Der QoS-Level (Quality of Service) bestimmt die Zustellgarantie der Last-Will-Nachricht. Dabei sollte man in produktionskritischen Anwendungsfällen mindestens QoS 1 einsetzen, damit der Broker Nachrichten zuverlässig zustellen und auf Client-Ausfälle reagieren kann.

• QoS 0: „At most once“ – keine Zustellgarantie
• QoS 1: „At least once“ – kann doppelt ankommen
• QoS 2: „Exactly once“ – höchste Zustellqualität

Last Will Message

Die Last Will Message ist der Nachrichtentext, den der Broker im Falle eines unerwarteten Client-Ausfalls automatisch veröffentlicht (z. B. „offline“). Dabei kann der Client Inhalt und Format frei wählen, etwa als einfacher Text oder im JSON-Format.

Last Will Retain

Der Retain-Flag steuert, ob der Broker die Last-Will-Nachricht dauerhaft speichert:

• Retain = true: Der Broker speichert die Nachricht auf dem Topic und sendet sie aktiv an jeden neuen Subscriber, sobald dieser abonniert.
• Retain = false: Die Nachricht wird nur beim Eintreten des Ereignisses gesendet, aber nicht dauerhaft gespeichert.

Praxisbeispiel und Best Practices

Ein MQTT-Client einer Steuerung verbindet sich mit dem Broker und konfiguriert einen Last Will mit Topic status/plc001, Nachricht „offline“, QoS 1 und Retain = true. Fällt die Steuerung unerwartet aus, publiziert der Broker automatisch diese Nachricht. Ein HMI-System, das das Status-Topic abonniert hat, erkennt den Ausfall sofort und zeigt eine entsprechende Warnung an. Dabei gelten folgende Best Practices:

• Verwende klare, maschinenlesbare Nachrichtenformate (z. B. JSON) für einfache Auswertung.
• Setze QoS 1 oder 2 für kritische Systeme.
• Aktiviere das Retain-Flag, wenn neue Subscriber den Ausfallstatus direkt erkennen sollen.
• Wähle ein dediziertes Status-Topic, z. B. …/status/plc001.

Fazit

Die Wahl und Konfiguration der richtigen MQTT Connection Settings ist entscheidend für die Zuverlässigkeit, Stabilität und Transparenz von Echtzeitkommunikation im Unified Namespace (UNS). Parameter wie Client ID, Clean Session, Keep Alive, Username/Password sowie Last Will beeinflussen maßgeblich das Verhalten angebundener Systeme – insbesondere im Fall von Netzwerkausfällen, Reconnects oder Sicherheitsanforderungen.

Gerade in produktionskritischen Umgebungen lohnt sich eine bewusste und standardisierte Konfiguration dieser Verbindungsparameter. Nur so lässt sich sicherstellen, dass Daten zuverlässig fließen, Systemzustände korrekt erkannt werden und Integrationen auf MQTT-Basis im UNS robust und skalierbar betrieben werden können.