Was ist MQTT und wie können Unternehmen der Industrieautomatisierung es nutzen?

Wenn Sie sich überhaupt mit dem Industrial Internet of Things (IIoT) beschäftigen, werden Sie bestimmt überall auf ein neues Akronym stoßen:MQTT. Während MQTT in der Automatisierung ziemlich neu ist, gibt es es schon seit mehr als 20 Jahren. Es wurde ursprünglich als Protokoll entwickelt, um Daten von abgelegenen Ölfeldern zu erhalten, aber bis vor kurzem hat es außerhalb dieser Nischenanwendung nie viel Akzeptanz gefunden. Es entwickelt sich jetzt zu einem der wichtigsten Protokolle für digitale Transformationsprojekte in der Fertigung.

Was ist MQTT?

MQTT steht für Message Queuing Telemetry Transport. Es ist ein Client-Server-Publish/Subscribe-Messaging-Transportprotokoll, das als leichtgewichtiges Messaging-Protokoll zum Senden kleiner Informationspakete in Anwendungen mit begrenzter Bandbreite gilt. Im Kern gilt es als OASIS-Standard im Herzen der IoT-Konnektivität.

Verlauf

In den späten 1990er Jahren bestand Bedarf an einem leichtgewichtigen Kommunikationsprotokoll, das in der Lage wäre, Daten von entfernten Ölstandorten mit extrem niedrigen Verbindungsgeschwindigkeiten zu übertragen, vielleicht so niedrig wie 300 Baud. Die Strategie bestand darin, die bereits in der Transportschicht angebotenen Fähigkeiten zu nutzen, die das TCP-Protokoll verwendeten. Das vorgeschlagene Anwendungsprotokoll würde jegliche Redundanz entfernen, die zu den Übertragungsnutzlasten hinzugefügt wird. Es musste auch zustandsbehaftet sein und nur ausnahmsweise berichten. Angesichts dieser Einschränkungen arbeitete Phillips 66 mit Arlen Nipper von Cirrus Link Solutions und Andy Stanford-Clark von IBM zusammen, um das zu entwickeln, was heute als MQTT-Protokoll bekannt ist.

Frühe kommerzielle Nutzung

Während Automatisierungsunternehmen Anfang der 2000er Jahre mit dem MQTT-Protokoll angesprochen wurden, war seine einzige andere kommerzielle Verwendung die Anwendungen Facebook Messenger und Apple Messages. Interessant war vor allem, dass das Protokoll den Zustand und die Qualität der Daten sicherstellt. Wenn ein Sender tippte, sah der Empfänger dann die mittlerweile allzu vertrauten drei Punkte auf dem Bildschirm. Es wurde auch in einigen Heimüberwachungs- und Wetterdatenanwendungen verwendet, aber zu diesem Zeitpunkt war die Verwendung von MQTT eher begrenzt.

Einführung der Automatisierung

Mitte der 2010er Jahre wandte sich Arlen Nipper erneut an Automatisierungsunternehmen, um den Einsatz von MQTT voranzutreiben. Es entstand die Notwendigkeit, zusätzliche Fertigungsdaten ohne nennenswerten Netzwerkbedarf zu aggregieren. Es gab jedoch einige zusätzliche Fähigkeiten, die entwickelt werden mussten, um die Akzeptanz in der Fertigung zu erreichen. Cirrus Link Solutions setzte zusammen mit Inductive Automation die Entwicklung des heutigen Sparkplug-Standards fort, der Attribute enthält, die für die Automatisierung erforderlich sind, nämlich einen definierten Satz von Themen, eine Standardnutzlast und Nachrichtenkomprimierung.

Strukturübersicht

MQTT verwendet eine Struktur, die der Ordnerstruktur eines Computers ähnelt. Ich werde den Windows-Desktop als Beispiel verwenden. Der Desktop hat einen Ordner namens Eigene Dateien. In Eigene Dateien gibt es einen weiteren Ordner namens Familie, und in diesem Ordner befindet sich ein Ordner für jedes Familienmitglied. Der Pfad zu meinem Ordner wäre Desktop/My Documents/Family/David. Ich würde alle meine Dokumente bei David speichern (veröffentlichen). Jeder, der meine Dokumente lesen wollte, würde David öffnen (abonnieren).

Geräte, die das MQTT-Protokoll verwenden, veröffentlichen und abonnieren einen ähnlichen Themenpfad, der Namespace genannt wird. Ähnlich wie ein Computer ist es vom allgemeinsten zum spezifischsten organisiert. Je höher das Level, das ich abonniere, desto mehr Daten erhalte ich. Es gibt auch Platzhalter, die verwendet werden können, um einen Themenpfad zu definieren. Ein Sternchen (*) schließt alles ab dem aktuellen Level und darunter ein. Ein Plus (+) verschiebt den Pfad um eine Ebene nach unten. Ich habe ein paar Beispiele weiter unten im Artikel eingefügt.

Ausrichtung auf ISA-Standards

Der ISA-95-Standard ist in der Fertigung gut bekannt. Es beschreibt ein Standardmodell und eine Terminologie für die Schnittstelle zwischen Unternehmens- und Steuerungssystemen. Während es im Allgemeinen als Hierarchie realisiert wird, beginnend mit einem ERP oben und Geräten unten, befasst sich der Standard hauptsächlich mit Fertigungsdaten und wie sie strukturiert sein sollten. Da MQTT einen Topic-Namespace verwendet, können diese problemlos an der ISA-95-Hierarchie ausgerichtet werden. Es wird empfohlen, dass ein Themen-Namensraum dem Unternehmen, dem Standort, dem Bereich, der Linie und der Zelle folgt, wenn er erstellt wird. Der Stammordner des Herausgebers/Abonnenten sollte ebenfalls auf der richtigen Ebene vorhanden sein. Beispielsweise sollte eine SPS, die eine Zelle steuert, ihre Daten in einem Thema von Unternehmen/Standort/Bereich/Linie/Zelle veröffentlichen. Wenn ein Process Historian spezifisch für einen Bereich ist, sollte er alle Daten auf Unternehmens-/Standort-/Bereichsebene abonnieren.

Architektur

Eine der häufigsten Fragen, die sich aus der Verwendung von MQTT ergeben, ist, was passiert, wenn die Verbindung unterbrochen wird. Es gibt mehrere Optionen, die verwendet werden können, um diese Situationen zu entschärfen. Eine übliche Lösung ist die Verwendung einer "Store-and-Forward"-Methode. Beispielsweise sammeln SCADA-Systeme auf der Steuerungsebene weiterhin Daten, bis die Verbindung zum MQTT-Broker wieder aufgenommen wird. Es ist zu beachten, dass bei Wiederaufnahme der Broker-Verbindung die Zeitstempel aller gespeicherten Daten erhalten bleiben.

MQTT unterstützt auch die Verwendung von Backup-Brokern. Wenn ein primärer Broker vorhanden ist, wechseln die verbundenen Knoten automatisch zu einem anderen Broker, wenn diese Verbindung unterbrochen wird. Die Beziehung wird im Allgemeinen durch eine Anwendung (wie ein SCADA-System) konfiguriert, die diese Funktion unterstützt.

Eine andere Lösung wird durch die Verwendung von Clustering erreicht. Dies ist typisch für Anwendungen, die sich keinen Datenverlust leisten können. Ein gängiges Setup besteht darin, mehrere MQTT-Broker in einem Cluster anzuordnen. Alle diese Broker kennen einander und teilen Nachrichten innerhalb des Clusters. Wenn die Konnektivität unterbrochen wird, leiten Herausgeber und Abonnenten von Daten Daten nahtlos und verlustfrei an einen anderen Broker weiter.

Es ist üblich, dass eine Unternehmensanwendung Daten aus allen ihren Werken verwendet. Für dieses Szenario unterstützt MQTT die Verwendung von Bridging, das einem Store-and-Forward-System ähnelt. In dieser Architektur veröffentlicht oder überbrückt ein Broker einige oder alle Namensräume an einen anderen Broker. Anders ausgedrückt, ein Anlagenmakler würde eine Brücke zu einem Unternehmensmakler bilden. Sowohl die veröffentlichten Themen als auch die Namensraumstruktur können definiert werden. Dies begrenzt sowohl die veröffentlichte Datenmenge als auch den Kontext für den empfangenden Broker.

Am einfachsten ist es, alle Daten unverändert mit einem Sternchen (*) zu veröffentlichen und keine Struktur zu definieren, aber dies kann zu vielen unnötigen und potenziell verwirrenden Daten führen. Um einen gewissen Datenkontext bereitzustellen, kann ein Thema am Anfang des Namensraums des veröffentlichten Themas hinzugefügt werden. Beispiel:Unternehmen/Standort könnte dem Namespace „Werksbereich/+/Zelle“ hinzugefügt werden, was dazu führen würde, dass Unternehmen/Standort/Bereich/+/Zelle an den Unternehmensbroker gesendet wird. Das Ergebnis ist, dass die Daten auf Zellenebene von allen Leitungen von diesem System verfügbar wären (beachten Sie die Verwendung des Platzhalters +).

Alle diese Szenarien können bereitgestellt werden. Ein SCADA-System kann Store-and-Forward an einen MQTT-Cluster verwenden. Es könnte primäre und Backup-Cluster geben, aber dies würde wahrscheinlich unnötige Komplexität hinzufügen. Schließlich kann ein Werkscluster eine Brücke zu einem Unternehmenscluster schlagen, um die Integrität der Daten zu maximieren. Dies eignet sich hervorragend für Unternehmensanalysen und maschinelles Lernen, da diese erhebliche Mengen an Daten in guter Qualität erfordern.

Sicherheit

Eines der Hauptanliegen beim Senden und Empfangen von Fertigungsdaten über das Internet ist die Cybersicherheit. Während die einzige Möglichkeit, wirklich sicher zu sein, die Verwendung eines Luftspalts ist, wird dies die Fähigkeit einer Organisation zur digitalen Transformation verhindern. Einer der Hauptvorteile von MQTT ist die Sicherheit. Während andere Kommunikationsprotokolle das Öffnen von Netzwerkports erfordern, erfordert MQTT nur eine ausgehende Verbindung zum Broker. Werke müssen keine eingehenden Ports öffnen, was für IT-Organisationen sehr attraktiv ist.

Zukünftige Überlegungen

In zukünftigen Artikeln werde ich allgemeine Anwendungen mit MQTT untersuchen. Während das Protokoll ziemlich Plug-and-Play sein soll, wird es wahrscheinlich Interesse an zusätzlichen technischen Details geben. Unternehmensleiter sollten überlegen, wie sich MQTT auf ihre aktuellen Bemühungen zur digitalen Transformation auswirken wird. Und natürlich werden führende Ingenieure auf jeden Fall wissen wollen, wie sich MQTT auf sie auswirken wird.

Abschließend sollte MQTT nicht als Ersatz für bestehende Architekturen betrachtet werden. Ausgerichtet auf die Anforderungen von Industrie 4.0 nutzt es das, was bereits vorhanden ist. OPC UA und andere Protokolle werden weiterhin benötigt, da sie für Steuerungsanwendungen ausführlicher sind. Wenn es jedoch darum geht, große Datenmengen zu aggregieren, ist MQTT eine ausgezeichnete Wahl.