Wie sich MQTT in industrielle Architekturen einfügt

In einer kürzlich erschienenen Folge des Augmented Ops Podcasts haben wir mit Dominik Obermaier, Mitbegründer und CTO von HiveMQ, die Landschaft der industriellen IoT Architekturen und die Rolle von MQTT untersucht. Unter dem Titel"Aufbau industrieller Architekturen mit MQTT" untersucht 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 umgestalten, um die Vorteile dieser neuen Technologien und Ansätze zu nutzen.

Von der Gründung von HiveMQ direkt nach dem Studium bis hin zur Mitarbeit im technischen Komitee von MQTT seit über einem Jahrzehnt und der Unterstützung bei der Entwicklung des Standards bietet Obermaier eine differenzierte Perspektive auf diese Technologie und ihre Anwendung in der Fertigung. Insbesondere ruft er die Hersteller dazu auf, MQTT zu übernehmen, um industrielle Infrastrukturen im Unternehmensmaßstab aufzubauen.

Obermaier ging ausführlich auf die Geschichte von MQTT ein und erklärte, wie es 1999 von IBM für ein Öl- und Gasunternehmen entwickelt wurde Anwendungsfall bevor es 2010 als Open Source veröffentlicht wurde, was es jedem ermöglichte, die Spezifikation zu implementieren, ohne dafür Lizenzgebühren zahlen zu müssen. Diese Änderung gab den Anstoß für die Verbreitung von MQTT, das zunächst in der Heimautomatisierung eingesetzt wurde, bevor es zu einem bevorzugten Kommunikationsprotokoll für alles von vernetzten Autos bis hin zu industriellen und Fertigungsanwendungen wurde. Aber was genau unterscheidet MQTT von den unzähligen anderen modernen Protokollen wie HTTP oder OPC UA?

In erster Linie folgt MQTT dem Publish/Subscribe-Kommunikationsmuster (oft abgekürzt als Pub/Sub). Das bedeutet, dass jeder Knoten in einer MQTT-Infrastruktur Daten an eine bestimmte Adresse (ein sogenanntes Topic) in einem zentralen Broker veröffentlichen kann und auch Daten abonnieren kann, die von anderen Knoten an den Broker veröffentlicht 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 abgefragt wird, um aktualisierte Daten anzufordern. Obermaier erklärt: "Das bedeutet, dass Sie die Produzenten von Daten von den Konsumenten der Daten entkoppeln. MQTT-Clients sind außerdem in der Regel so konzipiert, dass sie nur dann eine Nachricht an den Broker senden, wenn sich Datenwerte tatsächlich ändern.

Dies steht im Zusammenhang mit einem weiteren Merkmal von MQTT - seinem leichtgewichtigen Design, das es besonders für die eingeschränkten Netzwerkumgebungen geeignet macht, die häufig in industriellen Umgebungen zu finden sind. Im Gegensatz zu ausführlicheren Protokollen, die einen erheblichen Paket-Overhead erfordern, verwendet MQTT ein binäres Format für die Kommunikation zwischen Clients und Brokern, mit einem festen Header von nur 2 Byte und einem variablen Header von höchstens 12 Byte. In Verbindung mit Report-by-Exception führt dies zu einer erheblichen Reduzierung des Netzwerkverkehrs, wodurch MQTT ideal für große Anwendungen ist, die einen hohen Durchsatz erfordern.

Der Schlüssel zur Verbreitung von MQTT ist seine Einfachheit. Die Spezifikation wurde absichtlich so gestaltet, dass sie "für die Clients extrem einfach zu implementieren ist", sagt Obermaier. Da sie vom MQTT-Standardisierungsgremium OASIS offen zugänglich gemacht wurde, kann jeder die Spezifikation von Grund auf mit der Programmiersprache seiner Wahl implementieren. 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.

Während die Einfachheit und Flexibilität der MQTT-Spezifikation eine Reihe von Vorteilen gegenüber anderen Protokollen bietet, stellt sie auch eine Reihe von Herausforderungen dar. So erklärt Obermaier, dass "das Protokoll sich nicht um die Struktur der gesendeten Daten kümmert" - die von Text über Bilder bis hin zu allen anderen Daten reichen können, die in eine Binärdatei umgewandelt werden können, und zwar bis zu einer Größe von 256 Megabyte. Die Flexibilität in Bezug auf die Nutzlast und viele Details der Implementierung macht die Spezifikation zwar sehr vielseitig, aber sie macht es auch komplizierter, die Interoperabilität mit verschiedenen Systemen zu gewährleisten, die MQTT auf unterschiedliche Weise implementieren.

Die bloße Angabe von MQTT als gewünschtes Datenprotokoll reicht nicht aus, um eine nahtlose Interoperabilität zwischen zwei Systemen zu gewährleisten, da nicht spezifiziert wird, wie die Daten kodiert sind oder was die Nutzlast tatsächlich enthält. Dies macht die Spezifikation zwar für die Datenproduzenten einfach zu implementieren, stellt aber für die Systeme, die die Daten nutzen, eine größere Belastung dar, da sie die Daten tatsächlich verwenden müssen. Obermaier weist darauf hin, dass dies der Grund dafür ist, dass Frameworks wie Sparkplug B immer beliebter werden, da sie zahlreiche Aspekte von MQTT standardisieren und so die Interoperabilität erheblich erleichtern.

Sparkplug B ist ein Open-Source-Framework, das die nahtlose Integration von Daten aus verschiedenen Quellen auf bidirektionale und interoperable Weise ermöglicht, indem es konsistente Muster für die MQTT-Topic-Struktur, die Nutzlast, das Statusmanagement und mehr definiert. Obermaier erklärt, dass Frameworks wie Sparkplug durch die Festlegung eines Standards dafür, "wie die Nutzdaten aussehen sollten, wie die MQTT-Topic-Struktur aussehen sollte und so weiter", die Interoperabilität erleichtert haben, ohne dass man sich um die Details der Implementierung der MQTT-Spezifikation durch unterschiedliche Systeme kümmern muss.

Eine Art von Architektur, die sich mit MQTT besonders gut umsetzen lässt, ist das Konzept des Unified Namespace (UNS), das in den letzten Jahren in der gesamten Branche an Bedeutung gewonnen hat. Obermaier hebt hervor, dass herkömmliche Technologien "mit Punkt-zu-Punkt-Protokollen oder manchmal mit Busprotokollen arbeiten, die nicht wirklich für den durchgängigen Datenverkehr innerhalb eines Unternehmens konzipiert sind", was zu "einer Menge Datensilos" führt. Mit einem UNS hingegen gibt es einen "zentralen Knotenpunkt, auf den OT- und IT-Mitarbeiter sowie Anwendungen zugreifen können", sagt er. Dadurch werden Punkt-zu-Punkt-Verbindungen zwischen den Knoten überflüssig, so dass jeder auf die Daten im Namensraum zugreifen und sie abfragen kann.

Aber warum MQTT verwenden? Die technischen Mindestanforderungen an ein UNS sind, dass es Edge-gesteuert ist (d.h. die Knoten am Edge melden sich beim zentralen Hub), dass es nach Ausnahmen meldet, dass es leichtgewichtig ist und dass es auf einer offenen Architektur basiert. MQTT erfüllt alle diese Anforderungen, da es ein Publish/Subscribe-Kommunikationsmuster verwendet, die Möglichkeit bietet, nach Ausnahmen zu berichten, eine geringe Bandbreite benötigt und die Spezifikation offen ist und von jedem kostenlos implementiert werden kann. Obwohl es eine starke Synergie zwischen MQTT und UNS gibt, betont Obermaier, dass "Unified Namespace, um es ganz klar zu sagen, ein Konzept ist, keine Technologie". Und während "Sparkplug und MQTT Technologien sind, ist UNS ein Konzept", das mit einer Reihe von verschiedenen Messaging-Technologien implementiert werden kann.