Kernprinzip des leichtgewichtigen Netzwerkprotokolls MQTT ist das Publish-Subscribe-Muster (Pub-Sub), das es einer beliebigen Anzahl von Datenkonsumenten ermöglicht, einzelne Themenbereiche oder Gruppen von Topics zu abonnieren und die darüber veröffentlichten Nachrichten zu empfangen. Aufgrund seiner Schlankheit eignet es sich besonders für ressourcenarme Geräte sowie für die Kommunikation in Netzwerken mit geringer Bandbreite, in unzuverlässigen Netzwerken oder Netzwerken mit hoher Latenz. Die Verwendung eines Pub-Sub-Protokolls wie MQTT stellt eine grundlegende Änderung in der Architektur dar. Alle Nachrichten werden über einen Broker als zentrale Komponente versendet, über den sich alle MQTT-Geräte für bestimmte Topics registrieren. Der Broker übernimmt die Aufgabe des Servers, über den jede Kommunikation zwischen beliebigen Clients abgewickelt wird. MQTT-Clients sind am Gateway, auf Geräten oder in Applikationen implementiert und stehen in keiner direkten Beziehung zueinander. In MQTT gibt es somit eine ‚Single Source of Truth‘, was ein wesentlicher Vorteil ist. Sichere Kommunikation lässt sich mit MQTT schnell und auf viele Arten realisieren. Der Client-Status, inhärent für die beteiligten Systeme, kann durch die MQTT-Funktionalität vollständig implementiert werden. Bleibt nur noch die Frage, wie sich das leichtgewichtige Protokoll elegant einsetzen lässt und was notwendig ist, um die Anforderungen für die industrielle Automatisierung zu erfüllen?
Sparkplug B
Sparkplug stellt eine offene und frei verfügbare Spezifikation zur Verfügung, die beschreibt, wie Edge Gateways oder native MQTT-fähige Endgeräte und MQTT-Applikationen über eine zentrale Komponente, den MQTT-Broker, bidirektional kommunizieren können. So entsteht ein Standard, der für Anwendungsfälle in industriellen Applikationen optimiert ist und beschreibt, wie die Funktionalität am besten in Echtzeit-Scada-Implementierungen genutzt werden können. Derzeit gibt es zwei mit Sparkplug definierte Schemata, wobei das zweite – Sparkplug B- die spezifische Lösung für eine Anwendung im Produktionsumfeld bietet: Der Zweck der Sparkplug-B-Spezifikation besteht darin, die Vorteile von MQTT, z.B. Einfachheit, Effizienz sowie Verständlichkeit sowohl in der Implementierung als auch im Betrieb mit den Anforderungen aus der OT zu paaren, eine Ontologie festzulegen, die allen Beteiligten bekannt ist, ein Session Management für Clients zu garantieren und schließlich Nachrichtengrößen auf ein Minimum zu beschränken. Dies bedeutet, dass Entwickler und Planer mit der Sparkplug-Spezifikation klare Richtlinien für den Entwurf des Topic-Namensraumes haben, wie die Payload-Daten zu strukturieren sind und wie der Client-Status zu halten und zu kommunizieren ist. Mit MQTT und Sparkplug B werden Nachrichtengröße und Frequenz verringert.
MQTT-Infrastruktur mit Sparkplug B im IIoT-Umfeld
Ein herkömmliches Scada-System im OPC-UA-Architekturbild interagiert immer direkt mit dem MQTT-Broker als spezifischem MQTT-Client. Der Broker ist dabei die zentrale Komponente. Er wird in einem Cluster, ausfallsicher und hochskalierbar betrieben und verfügt über Metrik-, Monitoring- und Alerting-Schnittstellen, damit alle beteiligten Systemkomponenten optimal überwacht werden können. In einer Sparkplug-Architektur hingegen verbinden sich Geräte, EoN-Knoten (End of Network) und der Scada/IIoT-Host mit einem zentralen MQTT-Broker und veröffentlichen und abonnieren Daten. Der Scada/IIoT-Host ist explizit nicht dafür verantwortlich, Verbindungen zu den Geräten direkt herzustellen oder aufrechtzuerhalten, sondern die EoN-Knoten verbinden Nicht-Sparkplug-/MQTT-fähige Geräte und Sensoren mit der Infrastruktur. Ein EoN-Knoten ist dabei für die Verwaltung seines eigenen Status sowie des Status der Geräte verantwortlich – und für den Empfang und das Senden von Daten der Geräte an die Sparkplug-Infrastruktur. Inzwischen bieten viele Hersteller native MQTT-Funktionen für ihre Geräte und Sensoren an. Ist das Gerät bereits mit Sparkplug ausgestattet, kann es direkt an der Infrastruktur teilnehmen. In diesem Fall identifiziert es sich als EoN-Knoten für die Sparkplug-Infrastruktur. Alle MQTT-Clients, insbesondere der Scada-Host und die IT-Applications, abonnieren bzw. setzen sich auf die Themenbereiche, von denen Informationen empfangen werden sollen. Dank der fest definierten Topic-Struktur und der Datenobjekte, weiß jeder MQTT-Client, wo und in welcher Form Informationen abgerufen werden können. Die MQTT-Clients sind zustandsbehaftet, so dass zu keiner Zeit ein Informationsverlust entsteht. Die jeweiligen Nachrichtentypen sind für bestimmte Informationen spezifiziert.
Fazit
Die Konzepte der MQTT-Spezifikation sind hervorragend geeignet für den Einsatz in der zunehmend digitalisierten Produktion. Ein wesentlicher Vorteil ist die Entkopplung der Daten durch den Einsatz einer zentralen Messaging-Komponente. MQTT ermöglicht sowohl die einfache Implementierung verschiedener Sicherheitsmechanismen sowie die Zustandsverwaltung der Clients und ist aufgrund seiner Eigenschaften wie Leichtgewichtigkeit und Geschwindigkeit ideal für den Echtzeitbetrieb von IIoT Infrastrukturen geeignet. Die Sparkplug-B-Spezifikation baut genau darauf auf: Sie gibt MQTT ein Framework, das in Anlehnung an die Anforderungen an IIoT-Systeme entwickelt wurde. Funktionalitäten wie Report by Exception, der Pub/Sub-Mechanismus, Session- und Statusmanagement sowie ein komprimierter Payload sorgen dabei für eine extreme Einsparung in puncto Netzwerkressourcen. Für den Einsatz von MQTT in Produktionsumgebungen gilt es, eine entsprechende Ontologie zu definieren, damit alle beteiligten Geräte und Anwendungen die Begriffe und die zwischen ihnen bestehenden Beziehungen im Themenraum kennen, verstehen und anwenden können. Das sorgt dafür, dass die gesendeten Informationen für die Komponenten der IT-Strukturen ohne weitere Metainformationen interpretierbar sind. Dieser Ansatz ermöglicht es Herstellern, Geräte schon mit dieser Spezifikation auszuliefern. Und nicht zuletzt ist es einfacher, Geräte in eine Architektur mit einer Nachrichten-orientierten Middleware – wie dem MQTT Broker – zu integrieren, als in eine Client-Server-Struktur.
