05/04/2022

Der Aufbau des MQTT Protokolls

MQTT ist ein Netzwerkprotokoll das häufig im IoT und IIoT Bereich Anwendung findet. MQTT steht dabei als Kurzform für Message Queuing Telemetry Transport und wird dazu genutzt Telemetriedaten (z.B. Sensorwerte, Stellgrößen, Ist-Werte, etc.) zwischen Maschinen auszutauschen (Stichwort: Machine-to-Machine-Kommunikation, M2M).

MQTT basiert auf TCP/IP und verwendet die von der IANA dafür reservierten Ports 1883 und 8883. Die Kommunikation zwischen den Clients und dem Server kann entweder unverschlüsselt oder verschlüsselt über SSL erfolgen.

Es existieren diverse Softwarebibliotheken in unterschiedlichen Programmiersprachen und Softwarelizenzen, welche auf einer Vielzahl von Systemen implementiert werden können, z.B. auf Notebooks, Embedded Systems, SPS/PLC Steuerungen uvm. Das MQTT Protokoll ist auch prädestiniert für den Einsatz auf Mikrocontrollern, da der Protokoll-Overhead recht gering ausfällt, Implementierungen für z.B. den Controllino / Arduino sind unter Open Source Lizenzen verfügbar.

Funktionsweise & Topics

MQTT implementiert das Publish-Subscribe Pattern, das allen verbundenen Clients ermöglicht mit recht geringem Ressourcenaufwand (CPU Zeit, Durchsatz) Daten untereinander auszutauschen. Im Mittelpunkt dabei steht der MQTT Broker (auch MQTT Server), über den die gesamte Kommunikation abläuft. Clients müssen somit nicht permanent beim Server "anfragen" (polling), sondern werden bei Ankunft neuer Daten bzw. Nachrichten entsprechend benachrichtigt.

Die Kommunikation findet nachrichten-basiert statt, indem die Daten bzw. Nachrichten (eng. Messages) in sog. Topics organisiert werden. Topics folgen oft einer logischen Hierarchie, um den realen Anwendungsfall bestmöglich abdecken zu können.

Die Clients können entweder die Rolle "Publisher" und/oder "Subscriber" übernehmen und sich damit an den Server (bzw. Broker) verbinden. Wenn ein Client / Publisher eine Nachricht absetzen möchte, wählt er ein passendes Topic und schickt die Nachricht darin an den Server / Broker. In dem Schaubild ist der Client eine SPS, der in das Topic controller1/temperature die Nachricht {"temperature_1": 22.4} pusht.

Der Client / Subscriber, der sich für die Nachrichten im Topic controller1/temperature interessiert, registriert sich beim Server / Broker und abonniert dieses Topic. Sobald dann neue Nachrichten beim Broker unter diesem Topic ankommen, bekommt der Client / Subscriber die Nachricht direkt zugestellt.

Ein Client kann auch die beiden Rollen Publisher und Subscriber zeitgleich übernehmen, er ist nicht nur auf eine einzige beschränkt. Der Nachrichtenaustausch entspricht der Beziehung n-zu-n, bedeutet, dass mehrere Clients das gleiche Topic "subscriben" bzw. auch mehrere Clients in das gleiche Topic "publishen" können.

In diesem Beispiel besteht die Nachricht aus einem json String, was nicht unbedingt notwendig ist, jedoch in diesem Kontext weit verbreitet. Die maximale Anzahl an Clients am Broker sowie die maximale Länge der Nachricht ist konkret abhängig von der Implementierung des Brokers.

SPS oder PLCs implementieren das MQTT Protokoll und können Publisher und/oder Subscriber sein

Quality of Service (QoS)

Da MQTT designed wurde, um auch in instabilen Netzen die Nachrichten zuverlässig zu übermitteln, besteht die Möglichkeit für jede Nachricht die "Quality of Service" zu definieren. Somit kann vorab festgelegt werden, wie eine Nachricht zu behandeln ist, wenn diese nicht sicher zugestellt werden konnte (z.B. wenn die Verbindung während der Kommunikation zwischen Client und Server unterbrochen wird). Wichtig an dieser Stelle ist anzumerken, dass sich die QoS immer auf die Nachricht zwischen Sender und Empfänger bezieht. Betrachtet man nun die Übermittlung von Publisher zu Subscriber, stellt man fest, dass mit zwei unterschiedlichen QoS gearbeitet werden muss:

Übertragung der Nachricht von Client / Publisher zum Broker
Übertragung der Nachricht vom Broker zum Client / Subscriber

In MQTT sind drei QoS-Prioritäten definiert:

0 - at most once: die Nachricht wird maximal ein einziges Mal zugestellt (auch keinmal), aka. "fire and forget"
1 - at least once: die Nachricht wird mindestens ein Mal zugestellt (auch mehrfache Zustellung möglich)
2 - exactly once: die Nachricht wird genau ein einziges Mal zugestellt

Die Implementierung des QoS wird alleine vom MQTT Protocol Stack gehandhabt, bei der Verwendung von MQTT Clients (Publisher oder Subscriber) wird der QoS durch den Benutzer bei der Konfiguration festgelegt.

QoS Adaption

Wie oben bereits erwähnt bezieht sich der festgelegte QoS immer nur auf die Nachricht zwischen Sender und Empfänger. Wenn der Publisher (zum Broker) seine Nachricht mit einer anderen QoS sendet, als sich der Subscriber beim Broker registriert hat, wird für die Übertragung vom Broker zum Subscriber genau die QoS verwendet, mit der er sich beim Broker registriert hat.

Der Publisher hat somit die Kontrolle über die Zuverlässigkeit der Zustellung seiner Nachricht bei der Übertragung zum Broker / Server, jedoch keinen direkten Einfluss auf die Zuverlässigkeit der Zustellung zu den Subscribern. Die Subscriber legen bei der Registrierung individuell fest, mit welcher Zuverlässigkeit sie die Nachrichten erhalten möchten.

Retained, Last Will & Testament Messages

Da MQTT in seiner Spezifikation und Implementierung berücksichtigt, dass Geräte ggf. auch über instabile Verbindungen kommunizieren müssen, kann über retained, last will und testament messages das Verhalten beeinflusst werden, wenn einzelne Clients Verbindungsabbrüche erleiden.

Last Will & Testament Messages

Publisher können bei ihrem Verbindungsaufbau am Broker sog. Last Will & Testament (LWT) Messages unter einem bestimmten Topic registrieren. Somit kann der Broker anderen Clients mitteilen, wenn ein Publisher einen ungewollten Verbindungsabbruch erleidet. Dies funktioniert folgendermaßen:

der Publisher registriert sich beim Broker mit einem Topic und gibt zusätzlich noch seine Last Will & Testament Message bekannt
andere Subscriber registrieren sich beim Broker und abonnieren u.a. das Topic von o.g. Publisher
der Publisher erleidet nun einen Verbindungsabbruch (der Broker erkennt dies, da der Publisher die Verbindung nicht sauber über ein disconnect() trennt) und veranlasst somit, dass die vom Publisher bei der Registrierung angegebene LWT Message an die Subscriber ausgeliefert wird

Retained Messages

Nicht alle am Broker registrierten Publisher senden ihre Nachrichten in einem zeitlich fest definierten Abstand oder gar zyklisch - dies ist von der konkreten Implementierung und Logik in den einzelnen Publishern abhängig. Je nach dem wie die Software ausgelegt ist und ohne deren konkrete Kenntnis, kann man keine Vorhersage treffen, wann ein Publisher das nächste Update sendet. Subscriber, die erst beigetreten sind, nachdem der Publisher das letzte Update gesendet hat, haben dementsprechend keine Information über dessen Status. Ist das letzte Update des Publishers jedoch sehr wichtig, sodass auch neue Subscriber direkt darüber informiert werden müssen, so kann der Publisher die betreffende Nachricht mit einem RETAINED Flag versehen. Dies führt dazu, dass neue Subscriber, die das entsprechende Topic abonnieren, direkt vom Broker die letzte Nachricht des Publisher zugestellt bekommen.

Beispiel: Eine dezentrale Steuerung ist als Publisher am Broker registriert und pusht Sollwerte über ein bestimmtes Topic an anderen Teilnehmer. Dies wird meistens nicht zyklisch erfolgen, sondern nur dann, wenn sich der Sollwert ändert. Neue Subscriber die hinzukommen, benötigen aber möglicherweise direkt nach deren Registrierung die Zustandsinformation des Publishers. Diese erhalten sie, indem der Publisher seine Nachricht mit gesetztem RETAINED Flag abschickt.

Anwendungsbeispiel

Eine dezentrale Lüftungsanlage regelt mit unabhängigen Steuerungen die Temperatur in unterschiedlichen Bereichen eines Gebäudes (vgl. Sektor in der Abbildung). In jedem zu regelnden Bereich in dem Gebäude gibt es einen Temperatursensor und einen Lüfter. In der Gebäudeleittechnik sollen nun die Messwerte aller Sensoren sowie die Sollwerte aller Aktuatoren in einer Datenbank persistent gespeichert und über einen PC visualisiert werden. Die Anwendung soll dabei die Betriebsdaten "möglichst in Echtzeit" anzeigen.

Da die Steuerungen der Lüftungsanlage über eine MQTT Client-Implementierung (publisher) verfügen, können somit die Betriebsdaten über MQTT übertragen werden. Dazu wird im Netzwerk ein Broker installiert und konfiguriert. Im Anschluss daran, muss ein Datenmodell entwickelt werden, welches die Betriebsdaten kategorisiert und somit in "Topics" aufteilt.

In dem gezeigten Beispiel ist die Kategorisierung der Betriebsdaten in Topics recht simpel, es wird folgendes Format vorgeschlagen: {anlagentyp}/{gebäudebereich}/{sensorwert_oder_stellgröße}. In einer konkreten Implementierung könnte eine Hierarchie folgendermaßen aussehen: ac/sektor1/temperature (ac: Air Conditioner)

Die Sensoren und Aktuatoren "publishen" ihre Daten entsprechend des festgelegten Topics an den Broker. Am Broker wiederum haben sich ein PC und ein Datenbank Server registriert und "subscriben" die Betriebsdaten der Lüftungsanlagen entsprechend der festgelegten Hierarchie. Der PC soll alle Betriebsdaten in "Sektor 1" des Gebäudes anzeigen, er hat alles in ac/sektor1/# abonniert und bekommt somit die Drehzahl und Temperaturen aus "Sektor 1" mitgeteilt. Der Datenbank Server soll nur die Drehzahl und Temperatur der Lüftungsanlagen persistent abspeichern, jedoch aus allen verfügbaren Sektoren. Aus diesem Grund hat er zwei Topics abonniert und der Bereich (Sektor) ist als Wildcard gekennzeichnet: ac/+/temperature, ac/+/fanrpm

Im Schaubild jetzt nicht dargestellt - jedoch genauso technisch umsetzbar - wäre die Möglichkeit der Lüftungssteuerung auch die Rolle "Subscriber" zu übernehmen und so über ein vorher festgelegtes Topic Prozessdaten zu empfangen. So könnten z.B. eine Solltemperatur oder eine Drehzahlbegrenzung als Stellgröße über die Gebäudeleittechnik vorgegeben werden.

Verschlüsselung und Authentication

MQTT unterstützt auch die Authentifizierung mittels Benutzername und Passwort, Verschlüsselung und Message Authentication kann optional durch SSL und X.509 Zertifikate erfolgen. Inwiefern diese Features von den einzelnen Clients unterstützt werden ist stark abhängig von der verwendeten Hardware sowie von der MQTT Implementierung. SSL auf 8 Bit Mikrocontrollern zu nutzen ist nicht selten eine Herausforderung.

Weiterführendes auf diesem Blog

Möchtet ihr mit eurem IoT Projekt starten und seid euch bei der konkreten Umsetzung jedoch etwas unsicher? Sprecht uns an , wir stehen euch mit Rat und Tat zur Seite.
Für mehr spannende Themen, abonniert unseren Siincos IoT Newsletter .