Wie sich MQTT in industrielle Architekturen einfügt

In einer kürzlich erschienenen Folge des „Augmented Ops “-Podcasts haben wir gemeinsam mit Dominik Obermaier, Mitbegründer und CTO von HiveMQ, einen Blick auf die Landschaft der industriellen IoT geworfen und die Rolle von MQTT beleuchtet. Unter dem Titel„Building Industrial Architectures with MQTT“ beleuchtet das Gespräch mit Obermaier die Rolle von MQTT, wie es neue Architekturen wie Unified Namespace (UNS) unterstützt und warum viele Hersteller ihre digitale Infrastruktur neu gestalten, um die Vorteile dieser neuen Technologien und Ansätze zu nutzen.

Von der Gründung von HiveMQ direkt nach seinem Universitätsabschluss über seine mehr als zehnjährige Tätigkeit im technischen Ausschuss für MQTT bis hin zu seiner Mitwirkung an der Entwicklung des Standards – Obermaier bietet einen differenzierten Einblick in diese Technologie und ihre Anwendung in der Fertigungsindustrie. Insbesondere fordert er Hersteller dazu auf, MQTT einzusetzen, um industrielle Infrastrukturen im Unternehmensmaßstab aufzubauen.

Obermaier ging ausführlich auf die Geschichte von MQTT ein und erläuterte, wie es 1999 von IBM ursprünglich für einen Anwendungsfall in der Öl- und Gasindustrie entwickelt wurde, Anwendungsfall es 2010 als Open-Source-Projekt veröffentlicht wurde, wodurch jeder die Spezifikation implementieren konnte, ohne Lizenzgebühren zahlen zu müssen. Diese Veränderung gab den Anstoß für die Verbreitung von MQTT, das zunächst in Hausautomationssystemen zum Einsatz kam, bevor es sich zum bevorzugten Kommunikationsprotokoll für alle Bereiche entwickelte – von vernetzten Fahrzeugen bis hin zu Anwendungsfällen in Industrie und Fertigung. Doch was genau unterscheidet MQTT von der Vielzahl anderer zeitgenössischer Protokolle wie HTTP oder OPC UA?

In erster Linie folgt MQTT dem Kommunikationsmuster „Publish/Subscribe“ (oft als Pub/Sub abgekürzt). Das bedeutet, dass jeder Knoten in einer MQTT-Infrastruktur Daten an eine bestimmte Adresse (ein sogenanntes „Topic“) in einem zentralen Broker veröffentlichen und gleichzeitig Daten abonnieren kann, die von anderen Knoten an den Broker gesendet werden. Das Ergebnis ist, dass eine veröffentlichte Nachricht automatisch von allen Abonnenten empfangen wird – im Gegensatz zu Protokollen, bei denen ein Client in regelmäßigen Abständen kontinuierlich abgefragt wird, um aktualisierte Daten anzufordern. Wie Obermaier erklärt: „Das bedeutet, dass man die Datenproduzenten von den Datenkonsumenten entkoppelt.“ MQTT-Clients sind zudem in der Regel auf „Report-by-Exception“ ausgelegt, was bedeutet, dass sie nur dann eine Nachricht an den Broker senden, wenn sich die Datenwerte tatsächlich ändern.

Dies hängt mit einem weiteren charakteristischen Merkmal von MQTT zusammen – seinem schlanken Design, das es besonders für die oft in industriellen Umgebungen anzutreffenden Netzwerke mit begrenzten Ressourcen geeignet macht. Im Gegensatz zu ausführlicheren Protokollen, die einen erheblichen Paket-Overhead erfordern, nutzt MQTT ein binäres Format für die Kommunikation zwischen Clients und Brokern, mit einem festen Header von nur 2 Byte sowie einem variablen Header von höchstens 12 Byte. In Verbindung mit dem „Report-by-Exception“-Prinzip führt dies zu einer erheblichen Reduzierung des Netzwerkverkehrs, wodurch sich MQTT ideal für groß angelegte Anwendungen eignet, die einen hohen Durchsatz erfordern.

Der Schlüssel zur Verbreitung von MQTT liegt in seiner Einfachheit. Die Spezifikation wurde bewusst so konzipiert, dass „die Implementierung für die Clients extrem einfach ist“, sagt Obermaier. Da sie von der MQTT-Standardisierungsorganisation OASIS offen zugänglich gemacht wurde, kann jeder die Spezifikation von Grund auf mit der Programmiersprache seiner Wahl umsetzen. Darüber hinaus gibt es eine Reihe von Open-Source-MQTT-Bibliotheken in verschiedenen Sprachen, die es Entwicklern noch einfacher machen, MQTT in ihren Projekten einzusetzen.

Zwar bieten die Einfachheit und Flexibilität der MQTT-Spezifikation eine Reihe von Vorteilen gegenüber anderen Protokollen, doch sie bringt auch einige Herausforderungen mit sich. So erklärt Obermaier beispielsweise, dass „das Protokoll sich nicht um die Struktur der gesendeten Daten kümmert“ – diese können alles Mögliche umfassen, von Text über Bilder bis hin zu beliebigen anderen Daten, die in ein Binärformat umgewandelt werden können, und zwar bis zu einer Größe von satten 256 Megabyte. Zwar macht die Flexibilität hinsichtlich der Nutzdaten und vieler Details der Implementierung die Spezifikation äußerst vielseitig, doch erschwert sie gleichzeitig die Gewährleistung der Interoperabilität mit verschiedenen Systemen, die MQTT möglicherweise jeweils auf unterschiedliche Weise implementieren.

Die bloße Festlegung von MQTT als gewünschtes Datenprotokoll reicht nicht aus, um eine nahtlose Interoperabilität zwischen zwei Systemen zu gewährleisten, da dadurch nicht festgelegt wird, wie die Daten kodiert werden oder was die Nutzdaten tatsächlich enthalten. Dies macht die Spezifikation zwar für Datenproduzenten einfach zu implementieren, stellt jedoch eine größere Herausforderung für die Systeme dar, die diese Daten tatsächlich nutzen möchten. Obermaier nennt dies als Grund dafür, dass Frameworks wie Sparkplug B zunehmend an Beliebtheit gewinnen, da sie zahlreiche Aspekte von MQTT standardisieren und so die Interoperabilität erheblich vereinfachen.

Sparkplug B ist ein Open-Source-Framework, das die nahtlose, bidirektionale und interoperable Integration von Daten aus verschiedenen Quellen ermöglicht, indem es einheitliche Muster für die MQTT-Themenstruktur, die Nutzdaten, die Zustandsverwaltung und vieles mehr definiert. Obermaier erklärt, dass Frameworks wie Sparkplug durch die Festlegung eines Standards dafür, „wie die Nutzdaten aussehen sollten, wie die MQTT-Themenstruktur aussehen sollte und so weiter“, die Interoperabilität vereinfacht haben, ohne dass man sich um die Details der Umsetzung der MQTT-Spezifikation durch unterschiedliche Systeme kümmern muss.

Eine Architektur, für deren Umsetzung sich MQTT besonders gut eignet, ist das Konzept des „Unified Namespace“ (UNS), das in den letzten Jahren branchenweit an Bedeutung gewonnen hat. Obermaier hebt hervor, dass herkömmliche Technologien „mit Punkt-zu-Punkt-Protokollen oder manchmal auch mit Bus-Protokollen arbeiten, die nicht wirklich für den End-to-End-Datentransfer innerhalb einer Organisation ausgelegt sind“, was zu „vielen Datensilos“ führt. Mit einem UNS gebe es jedoch einen „zentralen Knotenpunkt, auf den sowohl OT- als auch IT-Mitarbeiter sowie Anwendungen zugreifen können“, sagt er. Dadurch entfallen Punkt-zu-Punkt-Verbindungen zwischen den Knoten, sodass jeder auf die Daten im Namensraum zugreifen und diese abfragen kann.

Aber warum MQTT? Die technischen Mindestanforderungen an ein UNS sind, dass es edge-gesteuert ist (d. h., Knoten am Netzwerkrand melden sich beim zentralen Hub), nach dem „Report-by-Exception“-Prinzip arbeitet, ressourcenschonend ist und auf einer offenen Architektur basiert. MQTT erfüllt all diese Anforderungen dank seines „Publish/Subscribe“-Kommunikationsmusters, seiner Fähigkeit zur Berichterstattung nur bei Ausnahmen, seines geringen Bandbreitenverbrauchs und der Tatsache, dass die Spezifikation offen ist und von jedem kostenlos implementiert werden kann. Obwohl es starke Synergien zwischen MQTT und UNS gibt, betont Obermaier: „Unified Namespace ist, um es ganz klar zu sagen, ein Konzept, keine Technologie.“ Und während „Sparkplug und MQTT Technologien sind, ist UNS ein Konzept“, das mit einer Reihe verschiedener Messaging-Technologien umgesetzt werden kann.