Was Sie schon immer über MQTT
im IIoT wissen wollten…

Obwohl das MQTT-Protokoll bereits seit fast drei Jahrzehnten existiert, eignet es sich aufgrund seiner Konzeption ideal für IIoT-Anwendungen, den neuesten Trend in der Automatisierungstechnik. Dies gilt insbesondere für Anwendungen, die sich auf eine aktive Benachrichtigung stützen, bei der Geräte nur bei Bedarf Daten bereitstellen, im Gegensatz zur passiven Benachrichtigung, in denen Geräte regelmäßig abgefragt werden. Warum MQTT im IIoT so erfolgreich ist und was man vor dem Einsatz des Übertragungsprotokolls wissen sollte, erläutert der folgende Beitrag.

Bild: Moxa Europe GmbH

Das MQTT-Messaging-Protokoll wurde erstmals 1999 von IBM und Cirrus Link entwickelt und ist ab Version 3.1 seit 2013 als ISO-Standard akzeptiert. MQTT verwendet ein Publish-Subscribe-Muster (siehe Abbildung unten), um Nachrichten auszutauschen. Wie in der Abbildung dargestellt, umfasst ein MQTT-System einen Broker und mehrere Clients, bei denen die Clients entweder Publisher oder Subscriber, also Abonnenten sein können. Publisher senden Daten an den Broker in Form von MQTT-Paketen, die aus einem ‚Thema‘ und einer ‚Nutzlast‘ bestehen. Der Broker verteilt die Daten dann an die Abonnenten, je nachdem, für welche Themen sie sich interessiert haben. Das MQTT-Protokoll legt kein Standardformat für die Datenübertragung fest, obwohl Anwendungen üblicherweise das JSON-Protokoll oder Nur-Text verwenden. Im Vergleich zu anderen Protokollen bietet MQTT Vorteile, die es ideal für IoT-Anwendungen machen.

MQTT ist das Top-Protokoll für IIoT-Anwendungen. Publish-Subscribe-Muster (Bild: Moxa Europe GmbH)

Messaging-Muster für Publish-Subscribe

Im Vergleich zu anderen Request-Response-Pattern-Protokollen ermöglicht das von MQTT verwendete Publish-Subscribe-Muster, dass IoT-Entwickler bestimmte häufige Verbindungsprobleme lösen können. Anfrage-Antwort-Muster (Request-Response-Muster) erfordern beispielsweise, dass Client und Server gleichzeitig online sind, um sicherzustellen, dass Daten erfolgreich übertragen und empfangen werden. Insbesondere für IIoT-Anwendungen kann es jedoch unmöglich sein, dass Geräte eine ausreichend starke Verbindung zum Netzwerk aufrechterhalten, um die erforderlichen Daten zu empfangen, und folglich ist das Anfrage-Antwort-Muster für solche Anwendungen nicht geeignet. Das MQTT-Muster für Veröffentlichungen und Abonnements ist auf Situationen zugeschnitten, in denen nicht garantiert wird, dass Geräte gleichzeitig mit dem Netzwerk verbunden sind. Der MQTT-Broker ist in dieser Hinsicht entscheidend. Der Broker fungiert als Informationszentrum, indem er Daten annimmt, die von als ‚Herausgeber‘ bezeichneten Clients an ihn gesendet wurden, und die Daten dann an als ‚Abonnenten‘ bezeichnete Clients gesendet werden. Wenn der Broker die Daten an einen Abonnenten sendet, prüft er zuerst, ob Zielclient online ist oder nicht. Wenn nicht, kann der Broker die Daten aufbewahren, bis der Abonnent online ist und diese dann senden. Ein Vorteil dieser Strategie ist, dass nur der Broker ständig online sein muss. Die Clients – sowohl Publisher als auch Abonnenten- müssen nur online sein, wenn eine Verbindung verfügbar ist oder wenn sie Daten senden oder empfangen müssen.

Abbildung 3: QoS 0: höchstens einmal (Bild: Moxa Europe GmbH)

Ereignisgesteuert

Bei Verwendung eines Publish-Subscribe-Musters veröffentlichen MQTT-Clients nur Daten an den Broker, wenn bestimmte Bedingungen erfüllt sind (z.B. könnte ein Warnsignal darauf hinweisen, dass die Temperatur eines bestimmten Geräts zu hoch ist). Eine andere Möglichkeit, diese Art von Vorgang zu beschreiben, besteht darin, dass Clients aktiv Daten aktualisieren, anstatt passiv darauf zu warten, dass ein anderes Gerät die Daten anfordert. Bei IoT-Anwendungen werden Kommunikationsgebühren abhängig von der Anzahl der übertragenen Datenpakete berechnet. Verglichen mit einem Anforderungs-Antwort-Muster spart MQTT Geld, da zur Durchführung der Datenübertragung nur unidirektionale Kommunikation erforderlich ist.

Abbildung 4: QoS 1: mindestens einmal (Bild: Moxa Europe GmbH)

Viele-zu-Viele-Kommunikation

Einer der Hauptvorteile von MQTT besteht darin, dass ein Publish-Subscribe-Muster verwendet werden kann, um auf einfache Weise eine Kommunikation zwischen vielen Benutzern herzustellen. Das Machine-to-Machine (M2M)-Konzept, bei dem die Kommunikation zwischen mehreren Teilnehmern realisiert wird, ist eines der heißesten Themen im IIoT. In werkseitigen M2M-Anwendungen teilen Maschinen an jeder Station ihren eigenen Prozessstatus mit Maschinen an anderen Stationen. Das Teilen von Informationen auf diese Weise dient zur Automatisierung der Produktionsoptimierung, ohne dass manuelle Eingaben von Bedienern erforderlich sind. Da MQTT zur Implementierung der M2M-Kommunikation verwendet wird, müssen Maschinen nur eine Verbindung mit dem Broker aufbauen, anstatt direkt miteinander zu kommunizieren, wodurch beim Handshaking eine erhebliche Zeitersparnis entsteht. Da ein Broker die Kommunikation zwischen allen Maschinen abwickelt, ist die Datenübertragung zuverlässiger.

Abbildung 5: QoS 2: genau einmal (Bild: Moxa Europe GmbH)

QoS-Design

Das MQTT-Protokoll verwendet drei QoS-Stufen, um Daten zu priorisieren:

QoS 0: höchstens einmal

In diesem Fall veröffentlicht der Client nur einmal eine Nachricht an den Broker. Der Broker bestätigt den Empfang der Nachricht nicht und übermittelt dem Kunden keine Benachrichtigung über die Kommunikation mit den Abonnenten. Die einzige Garantie ist, dass der Herausgeber weiß, dass er die Nachricht gesendet hat. Er weiß jedoch nicht, ob der Broker oder Abonnenten die Nachricht erhalten haben. Obwohl QoS 0 die mit Abstand schnellste Servicequalitätsrichtlinie ist, ist es auch die am wenigsten zuverlässige.

QoS 1: mindestens einmal

Wenn ein Client in diesem Fall eine Nachricht an den Broker veröffentlicht, erwartet der Client, dass der Broker erkennt, ob ein Client die Nachricht erhalten hat oder nicht. Wenn der Publisher innerhalb eines voreingestellten Zeitintervalls keine Bestätigung vom Broker erhält, wird er die Nachricht immer wieder neu veröffentlichen, bis die Bestätigung empfangen wird. Verglichen mit QoS 0 ist QoS 1 zuverlässiger, obwohl man davon ausgehen kann, dass es mit der Zeit langsamer wird.

QoS 2: genau einmal

In diesem Fall tauschen der Kunde und der Broker vier Nachrichten aus. Der Client veröffentlicht die Daten zunächst an den Broker, und dann tauschen der Client und der Broker drei Nachrichten aus: PUBREC, PUBREL und PUBCOMP, um sicherzustellen, dass die Daten nur einmal übermittelt werden. QoS 2 ist die verlässlichste, wenn auch langsamste MQTT-Servicequalitätsrichtlinie.

@Zwischenüberschrift: Sicherheit

Sicherheit ist für IIoT-Anwendungen ein Hauptanliegen. Bei immer mehr Geräten, die mit dem Internet verbunden sind, ist es von höchster Priorität, zu wissen, wie die Wahrscheinlichkeit, dass Daten gehackt werden, minimiert wird. In Bezug auf MQTT unterstützt der Broker Kontonamen und Kennwörter, um zu verhindern, dass nicht autorisierte Clients eine Verbindung zum Broker herstellen, um Themen zu abonnieren. MQTT unterstützt auch die TLS-Verschlüsselung für Datenübertragungen, um die Wahrscheinlichkeit zu minimieren, dass Daten während der Übertragung gehackt werden.

Architektur zur direkten Anbindung an die Cloud (Bild: Moxa Europe GmbH)

MQTT-Anwendungsarchitektur

Wie bereits zu Beginn dieses Artikels erwähnt, werden traditionelle OT-Anwendungen für IIoT-Anwendungen überarbeitet, die das beliebte MQTT-Protokoll verwenden. Es werden zwei Hauptsystemarchitekturen verwendet.

Direkte Verbindung zur Cloud

Die meisten öffentlichen Clouddienste (AWS, Azure, Google Cloud, Alibaba Cloud usw.) unterstützen das MQTT-Protokoll, damit Edge-Geräte eine direkte Verbindung zur Cloud herstellen können. Um wettbewerbsfähig zu bleiben und die Zukunft der Branche mitzugestalten, sollten Cloud-Dienste mindestens die folgenden Vorteile bieten:

Zeitersparnis

Da der Cloudservice die Hardware (Cloudserver, CPU, Arbeitsspeicher usw.) verwaltet, können die mehr spezialisierten Wartungsaufgaben den IT-Experten des Cloudservices überlassen werden, sodass Benutzer mehr Zeit für die Entwicklung eigener Lösungen aufwenden können.

Non-Stop-Service

Kunden erwarten von Cloudservice-Providern eine nahezu 100%-ige Zuverlässigkeit, weshalb Zuverlässigkeit und Netzwerkstabilität von größter Bedeutung sind. Jeder Cloudservice-Anbieter gibt eindeutig an, wie viel garantierte Service-Stabilität er in seinem Service Level Agreement (SLA) gewährleisten will. Beispielsweise verpflichtet sich Amazon in der Amazon Compute-SLA zu einer monatlichen Betriebszeit von 99,99 Prozent, was bedeutet, dass die Ausfallzeit eines Dienstes voraussichtlich weniger als 4,32 Minuten pro Monat beträgt. Es ist also keine Fantasie, diesen Service-Level als ‚Non-Stop-Service‘ zu bezeichnen.

Umfangreiche Reihe von Data Mining-Tools

Cloudservices bieten eine Vielzahl von Tools, darunter Datenvisualisierung, Datenalgorithmen, virtuelle Maschinen und maschinelles Lernen als Teil ihrer Plattformen. Durch den Zugriff auf solche Tools können Benutzer beliebig viele verschiedene Anwendungen implementieren. Zum Beispiel können Ingenieure einen Cloud-Service für Data Mining verwenden, um ihren Serverwartungsaufwand zu reduzieren und die Betriebseffizienz zu verbessern.

Verbindung zu einem lokalen Gateway herstellen

Der direkte Anschluss von Edge-Geräten an die Cloud hat Vorteile, man sollte jedoch auch die verschiedenen Probleme kennen, die mit der Einführung von Cloudservices für IIoT-Anwendungen zusammenhängen.

• Die erste Sorge sind die Kosten. Da Clouddienste den Benutzern die Anzahl der übertragenen Datenpakete in Rechnung stellen, ist es nicht kostengünstig, Daten von Edge-Geräten direkt an einen Cloudservice zu übertragen. Selbst wenn die Edge-Geräte über ein Mobilfunknetz mit der Cloud verbunden sind, muss man dennoch für den Mobilfunkdienst bezahlen.
• Die zweite Sorge ist die Datensicherheit. Obwohl Clouddienste gut geschützte Umgebungen zum Speichern von Benutzerdaten bieten, zögern einige Benutzer immer noch, sensible Daten in die Cloud hochzuladen.

Für die meisten IIoT-Anwendungen ist das Einrichten eines Gateways am Feldstandort zum Sammeln von Randgerätedaten und/oder zur Aktivierung der M2M-Kommunikation am Feldstandort eine Möglichkeit, diese Sorgen zu vermeiden. Das Gateway ist normalerweise ein Embedded Computer, und obwohl es nicht unbedingt für die Rolle des MQTT-Brokers und des MQTT-Clients konfiguriert werden muss, kann es auch als solches konfiguriert werden. Als MQTT-Broker kann das Gateway die M2M-Datenübertragung vor Ort durchführen. Als MQTT-Client kann das Gateway Feldgerätedaten sammeln und die verwendbaren Daten an ein Scada-System, eine HMI oder einen Cloudservice senden. Diese Gateway-Lösung senkt die Kosten noch weiter, indem MQTT verwendet wird, um die M2M-Kommunikation am Standort vor Ort und nicht über die Cloud zu ermöglichen.

Die Herausforderungen beim Konvertieren in eine IIoT-Anwendung

Bei der Umwandlung einer herkömmlichen OT-Anwendung in eine IIoT-Anwendung ist mit einigen oder allen der folgenden Herausforderungen zu rechnen. Derzeit verwendete ältere Geräte unterstützen MQTT nicht. In Fabriken verwenden Gebäudetechniker im Allgemeinen ein Remote-I/O-Setup für den Datenzugriff und die Umgebungsüberwachung. Darüber hinaus werden Protokoll-Gateways zur Erfassung von Leistungsmesserdaten und zur Überwachung des Energieverbrauchs verwendet. Wenn der IIoT-Trend nun in vollem Gange ist, und wenn das MQTT-Protokoll zur Übertragung von Daten in die Cloud verwendet wird, müssen die Ingenieure zunächst neue Remote-I/O-Produkte und Gateways, die MQTT unterstützen, begutachten und erwerben. Bei so vielen älteren Geräten, die immer noch an Feldstandorten rund um den Globus eingesetzt werden, kann die Umstellung einer Fabrik auf ein IIoT-basiertes Setup eine große Investition erfordern.

Das Zusammenführen der IT mit traditionellen Automatisierungsanwendungen ist einfacher gesagt als getan

Einer der grundlegendsten Aspekte einer IIoT-Anwendung besteht darin, OT-Daten zu sammeln und in die Cloud zu übermitteln, woraufhin die Daten verarbeitet und/oder analysiert werden können. Die Herausforderung ergibt sich aus der Tatsache, dass die IT- und OT-Industrie unterschiedliche Übertragungsprotokolle verwenden. Modbus, eines der meistverbreiteten Protokolle im OT-Bereich, verwendet Datenpakete mit kleinen Headern und Datenlasten, damit die Pakete über Netzwerke mit begrenzter Bandbreite übertragen werden können. Andererseits verwenden IT-Ingenieure IT-Protokolle wie MQTT, RESTful API und SNMP, um Daten zu sammeln. Viele IT-Ingenieure sind daher nicht mit Modbus vertraut.

Sicherheit ist ein Hauptanliegen

Die Aufrechterhaltung der Netzwerksicherheit ist für IIoT-Anwendungen ein vorrangiges Anliegen. Erfahrungsgemäß stammen Cyberangriffe von außerhalb der Fabrik. Daher besteht der erste Schritt zur Verbesserung der Cybersicherheit darin, einen sicheren Router zu installieren, die Firewall so zu konfigurieren, dass die Hacker ferngehalten werden, und im Allgemeinen die Netzwerksicherheit zu erhöhen, um Angriffe von außen zu verhindern. Edge-Geräte in einem Factory-Intranet unterstützen häufig nur eingeschränkte Sicherheitsfunktionen (sofern vorhanden) und verwenden weiterhin unverschlüsselte Protokolle. Modbus zum Beispiel wird üblicherweise verwendet, um Daten zu und von Edge-Geräten zu übertragen. In den letzten Jahren haben bestimmte hochkarätige Cyberangriffe die Sicherheit von industriellen Netzwerken in den Mittelpunkt gerückt. Beispielsweise war TSMC im August 2018 das Opfer eines Cyberangriffs einer WannaCry-Variante, was zu einem geschätzten Umsatzrückgang von etwa 200Mio.US$ führte. Der Angriff war darauf zurückzuführen, dass nicht alle Geräte im TSMC-Intranet den neuesten Sicherheitspatch installiert hatten. Dies bedeutet, dass der Angriff grundsätzlich leicht zu verhindern war. Die wichtige Lektion, die wir aus diesem Vorfall lernen können, ist, dass die Netzwerksicherheit in gewisser Weise auf der Ebene der Edge-Geräte implementiert werden muss.

Moxas Lösung

Moxas neue IoThinx 4510-Serie modularer Remote-I/O-Geräte verfügt über Funktionen, die sie ideal für IIoT-Anwendungen machen.

MQTT-Clientunterstützung

Die ioThinx 4510-Serie unterstützt MQTT-Clients, mit denen an das Gerät angeschlossene Geräte problemlos mit Cloudservices verbunden werden können. Die Benutzeroberfläche des ioThinx 4510 kann verwendet werden, um eigene MQTT-Themen zu definieren. Anschließend lässt sich anhand dieser Themen ermitteln, welche Clients welche Daten abonnieren. Zusätzlich zu den Kanaldaten kann die Geräteserie auch Abonnenten mit Datenattributen wie Kanalmodus, Maximal- oder Minimalwerte usw. versehen, sodass an das Netzwerk angeschlossene IT-Geräte immer den aktuellsten Status eines ioThinx 4510-Produkts über MQTT erhalten können. Die MQTT-Nutzlast verwendet das JSON-Format, das in der heutigen IT-Branche weit verbreitet ist. Wenn Abonnenten ein MQTT-Paket erhalten, können sie die Daten einfach nach einem bestimmten Schlüssel-‚Value‘ durchsuchen, um die Daten zu finden, nach denen sie in der Nutzlast suchen.

Eingebautes Modbus-Gateway

Die ioThinx 4510-Serie verfügt über eine integrierte serielle 3-in-1-Schnittstelle, mit der ein Modbus-Gateway implementiert werden kann. ioThinx 4510 kann mit wenigen Klicks konfiguriert werden, um Daten von einem seriellen Modbus-Gerät zu erfassen. Auf die seriellen Modbus-Daten wird wie bei den E/A-Daten über MQTT zugegriffen. Dank dieser Funktion können sowohl E/A- als auch serielle Daten mit einem einzigen Gerät erfasst werden, wodurch die Komplexität und die Kosten eines Systems erheblich reduziert werden. Neben Modbus-Daten kann die ioThinx 4510-Serie auch auf andere Protokolle zugreifen, darunter Modbus / TCP, RESTful-API und SNMP. Kurz gesagt, mit der ioThinx 4510-Serie ist die Bereitstellung serieller Daten in die Cloud einfach und unkompliziert.

Sicherheitsverbesserungen

Zum Schutz der Benutzerdaten unterstützt die ioThinx 4510-Serie TLS v1.2 zum Verschlüsseln von Daten, die per MQTT-Übertragung gesendet werden. Diese weit verbreitete und anerkannte Datenverschlüsselungstechnologie schützt Daten, die über ein Netzwerk übertragen werden, vor Hackern von Drittanbietern. ioThinx 4510 unterstützt auch Kontonamen und Kennwörter für den Broker, um zu verhindern, dass Daten an nicht autorisierte Broker veröffentlicht werden, und RESTful API über https und SNMPv3, sodass alle unterstützten IT-Protokolle mit Datenverschlüsselung übertragen werden können. Für das Modbus TCP-Protokoll, das Daten im Klartext überträgt, verfügt die ioThinx 4510-Serie über eine Zugriffskontrollfunktion, die auf einer Liste von IP-Adressen basiert, welche für den Zugriff auf den ioThinx 4510 autorisiert sind, wodurch die Betriebssicherheit erhöht wird. Mit diesen erweiterten Funktionen und der Unterstützung für eine Vielzahl von E/A-Modulen hilft die ioThinx 4510-Serie IT-Technikern nicht nur bei der Erfassung von Standortdaten, sondern auch OT-Technikern, die Daten sicher an Cloudservices zu liefern. Die ioThinx 4510-Serie schließt demnach die Lücke zwischen der IT- und der OT-Welt.