Wie funktioniert das Publish/Subscribe-Modell in MQTT?
Die Rollenverteilung: Publisher, Subscriber und Broker
Stell dir vor, du abonnierst einen digitalen Newsletter zum Thema "Industrie 4.0". Die Redaktion (Publisher) veröffentlicht regelmäßig neue Artikel. Du als lesende Person (Subscriber) erhältst diese automatisch. Die Versandplattform (Broker) sorgt im Hintergrund dafür, dass die Artikel exakt an die richtigen Abonnierenden verteilt werden.
In Cyber-Physischen Systemen (CPS) funktioniert das Publish/Subscribe-Modell (Pub/Sub) des Netzwerkprotokolls MQTT nach genau diesem Prinzip:
- Publisher (Sender): Geräte, die Daten erzeugen und senden. Ein Temperatursensor an einer Maschine agiert hier als Publisher.
- Subscriber (Empfänger): Anwendungen oder Geräte, die bestimmte Daten benötigen. Ein Aktor (z. B. eine Kühlungssteuerung) oder ein Überwachungs-Dashboard agieren als Subscriber.
- Broker (Vermittler): Der zentrale Server. Er nimmt alle Nachrichten der Publisher entgegen und leitet sie gezielt an die passenden Subscriber weiter.
Topics: Die dynamische Adressierung von Nachrichten
Damit der Broker weiß, wer welche Nachricht bekommen soll, nutzt MQTT sogenannte Topics. Ein Topic ist vergleichbar mit einem Dateipfad und wird durch Schrägstriche (/) hierarchisch strukturiert. Ein Publisher sendet seine Daten immer an ein spezifisches Topic. Ein Subscriber abonniert genau die Topics, die für ihn relevant sind.
- Konkretes Topic: Ein Sensor sendet seine Daten exakt an
fabrik/halle1/maschine5/temperatur. - Single-Level Wildcard (
+): Ein Dashboard abonniertfabrik/halle1/+/temperatur. Es empfängt dadurch die Temperaturen aller Maschinen, die sich in Halle 1 befinden. - Multi-Level Wildcard (
#): Ein zentraler Server abonniertfabrik/#. Er empfängt alle Nachrichten aus der gesamten Fabrik, unabhängig von der genauen Unterkategorie.
Wie stellt MQTT die Zuverlässigkeit von Nachrichten sicher?
Quality of Service (QoS): Drei Stufen der Sicherheit
In industriellen Netzwerken ist die Verbindungsqualität nicht immer perfekt. MQTT löst dieses Problem durch Quality of Service (QoS). Publisher und Subscriber können für jede Nachricht festlegen, wie zuverlässig sie zugestellt werden muss:
- QoS 0 (At most once / Höchstens einmal): Die Nachricht wird einmal gesendet. Es gibt keine Empfangsbestätigung ("Fire and Forget"). Geht ein Wert verloren, wird er nicht erneut gesendet. Dies eignet sich für hochfrequente Sensordaten, bei denen sofort der nächste Wert folgt.
- QoS 1 (At least once / Mindestens einmal): Der Broker garantiert die Zustellung. Der Publisher sendet die Nachricht so lange wiederholt, bis der Broker den Empfang bestätigt. Dadurch kann eine Nachricht auch doppelt ankommen. Dies ist ideal für Befehle, die zwingend ankommen müssen (z. B. "Lüftung einschalten").
- QoS 2 (Exactly once / Genau einmal): Die höchste und langsamste Sicherheitsstufe. Ein vierstufiger Handshake garantiert, dass die Nachricht exakt ein einziges Mal verarbeitet wird. Dies ist essenziell für kritische Befehle wie den Stopp eines Fließbands.
Retained Messages: Den letzten Status sofort kennen
Stell dir vor, ein Temperatursensor sendet nur alle 30 Minuten einen Wert, um Energie zu sparen. Wenn du jetzt ein Dashboard startest (Subscriber), müsstest du im schlimmsten Fall 29 Minuten auf den ersten Wert warten.
Hier helfen Retained Messages (einbehaltene Nachrichten). Sendet ein Publisher eine Nachricht mit dem "Retained"-Flag, speichert der Broker diesen einen letzten Wert für das jeweilige Topic dauerhaft ab. Sobald sich ein neuer Subscriber mit diesem Topic verbindet, sendet ihm der Broker sofort diese gespeicherte Nachricht. So kennt das Dashboard unmittelbar den letzten bekannten Zustand der Maschine, ohne auf die nächste reguläre Übertragung warten zu müssen.
Wie unterscheidet sich MQTT vom klassischen Client-Server-Modell?
Die starre Kopplung im Client-Server-Modell
Beim klassischen Client-Server-Modell (z. B. beim Aufruf einer Webseite) kommunizieren zwei Systeme direkt miteinander. Der Client stellt eine Anfrage (Request) an eine bekannte Server-Adresse und wartet synchron auf die Antwort (Response).
Dieses Modell ist stark gekoppelt: Der Client muss zwingend wissen, wo der Server ist (IP-Adresse), und beide müssen zum exakt gleichen Zeitpunkt online und erreichbar sein. Für ein Cyber-Physisches System mit tausenden Sensoren, die unregelmäßig Daten senden, führt dieses ständige direkte Anfragen (Polling) schnell zur Überlastung des Netzwerks und verbraucht unnötig Energie.
Räumliche und zeitliche Entkopplung durch MQTT
Das Publish/Subscribe-Modell von MQTT löst diese Probleme durch eine vollständige Entkopplung der Teilnehmenden. Publisher und Subscriber kennen sich nicht einmal – sie kennen nur die IP-Adresse des Brokers. Diese Entkopplung findet auf zwei Ebenen statt:
- Räumliche Entkopplung: Ein Sensor (Publisher) muss nicht wissen, ob seine Daten von einem, hundert oder gar keinem Subscriber gelesen werden. Er sendet sie einfach an den Broker.
- Zeitliche Entkopplung: Publisher und Subscriber müssen nicht gleichzeitig online sein. Wenn ein Subscriber kurzzeitig die Verbindung verliert, kann der Broker Nachrichten (je nach QoS-Level) zwischenspeichern und später ausliefern.
Skalierbarkeit durch Viele-zu-Viele-Kommunikation
Durch diese Entkopplung eignet sich MQTT perfekt für die Viele-zu-Viele-Kommunikation in modernen Industrieanlagen. Ein einziger Sensorwert kann gleichzeitig von einer Datenbank, einem Überwachungsmonitor und einem Aktor genutzt werden. Du kannst jederzeit neue Sensoren oder Aktoren zum Netzwerk hinzufügen, ohne die Konfiguration der bestehenden Geräte ändern zu müssen. Das System skaliert mühelos und passt sich dynamisch an neue Anforderungen an.
Welche zentralen Aufgaben übernimmt der Message Broker?
Nachrichten-Routing und Verbindungsmanagement
Der Message Broker ist das absolute Herzstück der MQTT-Architektur. Ohne ihn findet keine Kommunikation statt. Seine primäre Aufgabe ist das Nachrichten-Routing: Er nimmt alle eingehenden Nachrichten der Publisher an, filtert sie anhand der Topics und leitet sie blitzschnell an alle berechtigten Subscriber weiter.
Gleichzeitig übernimmt er das Management der Client-Verbindungen. Er authentifiziert Geräte, die sich mit dem Netzwerk verbinden wollen. Zudem überwacht er, ob die Clients noch online sind. Dafür senden die Clients regelmäßige "Keep-Alive"-Signale an den Broker. Bricht die Verbindung zu einem Client unerwartet ab, registriert der Broker dies sofort und kann andere Systeme darüber informieren.
Entlastung der Endgeräte durch QoS-Management
Der Broker ist die Instanz, die das Publish/Subscribe-Modell technisch erst möglich macht. Er sorgt für die Entkopplung von Sensoren, Aktoren und Anwendungen, indem er als einziger Knotenpunkt alle Verbindungen hält.
Zudem ist der Broker für die Gewährleistung der Quality of Service (QoS) verantwortlich. Wenn eine Nachricht mit QoS 1 oder 2 gesendet wird, übernimmt der Broker die komplexe Aufgabe, Bestätigungen (Acknowledgements) einzufordern, Nachrichten bei Verbindungsabbrüchen zwischenzuspeichern und sie bei Wiederherstellung der Verbindung erneut zu senden. Er entlastet die oft kleinen, ressourcenschwachen Sensoren somit von aufwendiger Netzwerklogik.
Teste dein Wissen
Ein Vibrationssensor an einer Fräsmaschine sendet sekündlich Messwerte über MQTT. Welche Rolle nimmt dieser Sensor im Publish/Subscribe-Modell ein?