Das Kommunikationsprotokoll Message Queuing Telemetry Transport (MQTT) wird häufig im Zusammenhang mit Buzzwords wie dem Internet of Things (IoT) oder Smart Home verwendet. Weshalb sich dieses Kommunikationsprotokoll speziell für diese Anwendungsgebiete eignet, wie es grundsätzlich funktioniert und wo es sich von etablierten Kommunikationssystemen abgrenzt, ist Thema dieses Beitrags.

‍

MQTT im Allgemeinen

Die Entwicklung von MQTT begann bereits 1999. Richtig fahrt aufgenommen hat das ganze Thema aber erst mit der voranschreitenden Digitalisierung und der zunehmenden Anzahl an Kommunikationsfähigen Geräten (Fensterkontakte, Temperatursensoren etc.). Genau in diesem Bereich, der Kommunikation zwischen einzelnen Endgeräten, finden sich nämlich die meisten Anwendungsgebiete von MQTT. Wenn sich zwei Geräte gegenseitig informieren, dann spricht man auch von einer sogenannten Machine-to-Machine-Kommunikation (M2M). MQTT zeichnet sich vor allem dadurch aus, dass es sehr „leichtgewichtig“ ist und dadurch sehr implementierungsfreundlich für weniger komplexe Anlagen ist. Was genau damit gemeint ist, erschließt sich wohl erst am Ende des Beitrags. Zuvor müssen, wie so häufig, die etablierten Technologien nochmal hervorgehoben werden damit die Vorteile von MQTT deutlich werden.

‍

Client-Server-Prinzip

Standardmäßig werden in einer Industrie-Kommunikation Informationen nach dem klassischen Client-Server Prinzip ausgetauscht. Der Client sendet dabei seine Informationen oder Anfragen an den Server und dieser Server speichert die Informationen oder stellt Informationen auf Anfrage bereit. Je nach Server-Struktur und verwendetem Kommunikationsprotokoll muss eine Client-Anfrage dann bestimmte „Knotenpunkte“ abfragen. In der Folgenden Grafik wird dieser Nachrichtenaustausch anhand zweier klassischen Industrie-PCs (auch Direct-Digital-Control – DDC – genannt) dargestellt.

Genau genommen arbeitet MQTT auch nach dem Client-Server-Prinzip. Jedoch gibt es den etablierten Client-Server Anwendungen häufig Problemstellungen, Unannehmlichkeiten und Hindernisse:

• Damit Client und Server die Daten gegenseitig verstehen, muss das jeweilige Datenformat dem anderen bekannt sein. Als Beispiel kann man hier den Internetbrowser verwenden. Der Browser ist der Client und fragt über das Internet bei einem Google-Server (oder von jedem anderen Serveranbieter) nach, ob dieser ihm die Inhalte zu einer bestimmten Website zur Verfügung stellen kann. Der Server sendet daraufhin das HTML-Dokument zurück. Der Client (Firefox, Chrome, Safari…) weiß, dass er nur ein HTML-Dokument zu erwarten hat und wurde explizit dafür programmiert, dieses zu verarbeiten. (Das Thema Internet-Kommunikation hatten wir beriets in diesem Beitrag erklärt.)
• In der Erklärung zu dem Client-Server-Prinzip wurde bereits der Begriff „Knotenpunkt“ verwendet. Wenn man beispielsweise das Kommunikationsprotokoll OPC DA verwendet, dann kann ein solcher Knotenpunkt bspw. wie folgt aussehen „NodeId: 21523“. Dies ist für den Menschen nicht besonders gut nachvollziehbar. Solange an der Kommunikation lediglich Maschinen beteiligt sind ist dies natürlich kein Problem. Jedoch sind solche Systeme weniger Wartungsfreundlich als dies mit MQTT umsetzbar ist.
• Es können immer beliebig viele Clients bei einem Server nach Daten fragen. Wenn viele Clients gleichzeitig eine Anfrage schicken, dann kann der Server zur Verarbeitung (je nach Performance) eine gewisse Verarbeitungszeit benötigen. MQTT löst dies anders. Hierzu aber im Folgenden mehr.

‍

MQTT – Client Broker Prinzip

MQTT überträgt die Daten in einer sogenannten Publish/Subscribe (im Folgenden veröffentlichen/abonnieren) Struktur. Jede einzelne Nachrichtenübertragung läuft dabei so ab, dass ein Client eine MQTT-Nachricht an einen zentralen MQTT Message Broker schickt. Dieser Message Broker vermittelt die Nachrichten an die anderen Netzwerkteilnehmer (Clients) und agiert somit als Server. Das hervorzuhebende hierbei ist, dass ein Client bei dem Broker die Nachrichten abonnieren kann. Das bedeutet, das ein Client dem Broker in einer initialen Nachricht mitteilt „Ich möchte alle Informationen erhalten die unter dem Schlagwort (in MQTT wird dies „Topic“ genannt) Raumtemperatur erscheinen“. Der Broker merkt sich dies und jedes Mal, wenn eine neue Nachricht unter diesem Schlagwort von einem Client veröffentlicht wird, leitet der Broker diese Nachricht sofort an besagten Client weiter. Es ist also nicht notwendig, dass Clients kontinuierlich bei dem Broker (Server) nachfragen, sondern der Broker ist dafür zuständig die Nachrichten weiterzuleiten.

In der folgenden Abbildung ist ein beispielhaftes Netzwerk zu sehen, bestehend aus sechs Teilnehmern. In der Mitte ist der Message Broker zu sehen. Die restlichen Komponenten stellen Clients dar und veröffentlichen und abonnieren verschiedene Nachrichten.

‍

MQTT - Nachrichtenaufbau

Schauen wir uns als nächstes einmal den Aufbau einer MQTT-Nachricht an. Bei einer Nachrichtenübertragung mittels MQTT werden von einem Client zwei Informationen übertragen. Zum einen enthalten die Nachrichten das sogenannte Topic und zum anderen die eigentlichen Nutzdaten. In dem vorherigen Abschnitt wurde der Begriff Topic noch mit „Schlagwort“ übersetzt. Dies ändert sich hier im Beitrag nun und wir reden von Topics.

• Ein Topic dient zur Identifizierung des Clients. Es setzt sich dabei aus verschiedenen Begriffen zusammen, welche durch Schrägstriche voneinander getrennt werden. Das Topic beinhaltet zum Beispiel Informationen über den Standort und die Funktion des Clients. Ein Beispiel für ein MQTT Topic ist:
  Gebäude_4/Etage_2/Raum_56//Sensor_1/Raumtemperatur
  Dieses Topic sagt aus, dass die übertragene Nachricht eine Raumtemperatur enthält welche von dem Sensor eins in einem Raum mit der Nummer 56 in der zweiten Etage von Gebäude vier gemessen wurde. Ein weiterer Client kann anschließend entweder genau dieses Topic abonnieren oder auch nur einen Teil des Topics. Das Abonnieren des Teiltopics „Gebäude_4/Etage_2/Raum_56/#“ würde dazu führen, dass der Client alle Informationen, welche unter dem Teiltopic veröffentlicht werden, erhalten würde. Die Raute am Ende der Nachricht ist in MQTT das Zeichen für „ich möchte alles von diesem Teiltopic abonnieren“. Somit würden alle Informationen aus Raum Nummer 56 abonniert werden und nicht nur die Raumtemperatur.
  Wie ein Topic strukturell aufgebaut ist liegt komplett in der Hand des Programmierers. Die einzige Vorgabe ist, dass das Topic durch Schrägstriche gegliedert wird. Es kann also auch etwas Kryptisches genutzt werden was nicht so leicht nachzuvollziehen ist wie das oben gewählte Beispiel. Allerdings wurde bei der Vorstellung des klassischen Client-Server-Prinzips erwähnt, dass kryptische Bezeichnungen zu wartungsintensiven Systemen führen.

• Die übertragenen Nutzdaten können sowohl aus binären Informationen als auch aus Texten oder ganzen Dateien bestehen. Was für ein Datenformat hier übertragen wird ist für MQTT irrelevant. Dies macht MQTT sehr implementierungsfreundlich. Was allerdings bleibt ist, dass ein Client der diese Nachrichteninhalte abonnieren möchte natürlich in der Lage sein muss dieses Dateiformat, sei es Text, eine Zahl oder eine PDF-Datei, verarbeiten können muss.

‍

Abschluss

Zu Beginn des Artikels wurde erwähnt, dass MQTT „leichtgewichtig“ ist. Die Eigenschaften Publish/Subscribe, Broker-Client-Prinzip, einfaches Handling der Informationsbezeichnungen und die Tatsache, dass es irrelevant ist welche Datenformaten mittels MQTT transportiert werden, verleihen MQTT eben diesen Ausdruck der „leichtgewichtigkeit“. Ebenfalls wurde zu Beginn des Beitrags erwähnt, dass MQTT häufig in IoT- und Smart Home-Szenarien zum Einsatz kommt. Dies ist damit zu begründen, dass es sehr übersichtlich und einfach zu implementieren ist. Ein Studium der Automatisierungstechnik und ein komplettes Verständnis über Client/Server Strukturen ist nicht notwendig um sich mittels MQTT bspw. eine kleine Heimautomatisierung zu bauen. Hierdurch ist auch die Frage in der Überschrift „MQTT – IoT, IIoT oder doch Smart Home?“ beantwortet. MQTT eignet sich für Umsetzungen in den Bereichen IoT und Smart Home. (Mancher würde behaupten, dass dies keine Unterschiede sind, weil jedes Smart Home ein Teil des IoTs darstellt. Dies ist aber eine andere Diskussion). IIoT steht für Industrial Internet of Things und zielt eher auf industrielle Anwendungen (Stichwort OPC UA) ab.

OPC UA bildet ein Stück weit das Gegenteil zu MQTT. Es basiert auf dem klassischen Client-Server-Modell und ist eher „schwergewichtig“. In OPC UA können semantische Beschreibungen für einzelne Komponenten integriert werden was die Entwicklung von (Vorsicht Buzzword!) Smart-Facturing-Szenarien unterstützt. OPC UA ist in der Implementierung verglichen mit MQTT sehr viel kryptischer und aufwendiger. Die Anwendungsfelder von OPC UA liegen aber auch eher in der Industrieautomatisierung womit OPC UA eher weniger für kleine Automatisierungen gedacht ist. Damit hätten wir aber auch den Teaser zu dem nächsten Artikel, OPC UA.

Dieser Beitrag kann als Crashkurs für MQTT verstanden werden. Viele Aspekte wurden zunächst außen vorgelassen. Beispielsweise zählen hierzu Security oder MQTT-spezifische Methodiken. Beispielhaft wurde hier das Zeichen „#“ in Topics erklärt, welches dazu dient mehr als nur einen einzelnen Wert zu abonnieren. Hiervon gibt es aber noch weitere Möglichkeiten. Aktuell planen wir in der nächsten Zeit ein kleines „Best-Practice“ Beispiel aufzusetzen zur Umsetzung eines MQTT-Projektes. Gleiches Projekt soll dann zukünftig auch als Basis für eine OPC UA Umsetzung dienen.

‍

‍

‍

‍