Von |Februar 29, 2024|Kategorien: Industrie 4.0|

Vier TCP-basierte Kommunikationsprotokolle als Schlüssel für das IIoT – Teil 3: AMQP

Inhalt dieses Beitrags

Vier TCP-basierte Kommunikationsprotokolle als Schlüssel für das IIoT – Teil 3: AMQP

Im Zentrum von Industrie 4.0, IIoT, smarten Fabriken und intelligenten Geräten steht die Konnektivität über alle Ebenen hinweg. Die starren, hierarchischen Automatisierungspyramiden mit isolierenden Zwischenebenen werden zunehmend von umfassenderen Netzwerkstrukturen abgelöst, in denen einzelne Knotenpunkte miteinander verknüpft sind und Daten miteinander austauschen.

Um solch eine Vernetzung zu realisieren, müssen die Geräte IIoT-fähig sein. Das bedeutet, sie müssen standardisiert und skalierbar sein, die Fähigkeit zur Interoperabilität zwischen IT- und OT-Systemen aufweisen und eine sichere Kommunikation gewährleisten. Verschiedene Kommunikationsprotokolle stehen hierbei zur Verfügung wie MQTT, OPC UA, AMQP und REST API. In unserer mehrteiligen Blogartikel-Reihe erfahren Sie mehr über die charakteristischen Merkmale dieser IIoT-Kommunikationsprotokolle und für welche Anwendungsfälle sie besonders geeignet sind. Im dritten Teil dieser Artikelserie geht es um AMQP.

Was ist AMQP und wie funktioniert es?

Das Advanced Message Queuing Protocol (AMQP) ist ein interoperables asynchrones Publish/Subscribe-Kommunikationsprotokoll. Die Bank JPMorgan Chase entwickelte es ursprünglich 2003. Im Jahr 2005 bildete sich eine Arbeitsgruppe aus mehreren Unternehmen, darunter RedHat, Microsoft, Software AG und Cisco. Nach mehreren experimentellen Veröffentlichungen (0.8, 0.9.1, 0.10) wurde AMQP im Jahr 2011 schließlich in Version 1.0 veröffentlicht und zudem als OASIS-Standard festgelegt. Seitdem wird es durch OASIS weiterentwickelt. 2014 wurde es nach ISO/IEC zertifiziert (19464:2014).

AMQP wird in erster Linie im Unternehmens- und Wirtschaftssektor eingesetzt, hat aber das Potenzial, auch Teil des Industriesektors zu werden. Es wird sehr häufig mit MQTT verglichen. Auf höherer Ebene ähneln sich die Standards, aber unter der Oberfläche definiert AMQP im Gegensatz zu MQTT ein vollständiges Ökosystem (mehr dazu in folgenden Abschnitten). In der AMQP-Topologie werden sowohl die Clients als auch die Broker als Container (Abbildung 1) bezeichnet. Container sind Elemente, die mehrere Knoten bilden. Ein Knoten kann Producer, Consumer oder Queue sein. Die Producer generieren, die Consumer empfangen und die Broker speichern Nachrichten und leiten sie weiter. Das bedeutet, dass ein Client sowohl die Rolle als Consumer als auch als Producer einnehmen kann. Innerhalb einer Anwendung können diese Knoten entweder flach oder hierarchisch verbunden sein. Auf der Außenseite sind die Knoten über Links verbunden. Ein Link ist eine unidirektionale Route zwischen zwei Knoten, die einer Sitzung übergeordnet gebildet wird. Jeder Link hat seine eindeutige Kennung und falls die Verbindung zwischen den beiden Containern unterbrochen wird, können die Links nach der Wiederaufnahme wiederhergestellt werden.

typical-AMQP-application

Abbildung 1: Eine typische AMQP-Anwendung

typical AMQP application

Ein weiterer interessanter Aspekt von AMQP ist, dass neben Brokern auch Router im Netzwerk enthalten sein können. Die Router implementieren nur die AMQP-Transportschicht und führen die Übertragungsaufgaben aus, ohne die Nachrichten in die Warteschlange zu stellen. Das bedeutet, dass der Router eine synchrone Verbindung zwischen dem Producer und dem Consumer herstellt. Consumer und Producer kommunizieren dann auf einem standardmäßigen Request/Response-Weg miteinander. Diese Funktion ist nützlich, wenn Producer und Consumer geografisch voneinander getrennt sind. In einer AMQP-Topologie können Broker und Router parallel existieren und müssen nicht (können aber) in ein Gerät integriert werden. Bezüglich der Nachrichtenübertragung verfügt AMQP über zwei Übertragungsmechanismen: „settled“ (höchstens einmal) und „unsettled“ (mindestens einmal). Das Übertragungsformat für die gesamte (annotierte) Nachricht ist XML, aber der Nachrichtentext kann verschiedene Codierungsformate wie Binary, JSON, Avro oder XML verwenden.

Interoperabilität: AMQP vs. MQTT

AMQP ist ebenfalls relativ kompakt und die einzige Interoperabilitätsfunktion, die es definiert, sind Datentypen. Außerdem kann man durch Verwendung der Links sicherstellen, dass ein bestimmter Producer-Knoten verfügbar ist, wodurch sich dieser Standard etwas besser für Computer-Maschine-Interaktionen eignet. Das klingt jedoch eher wie ein Ratespiel und weniger wie ein Szenario, in dem die Geräte frei miteinander kommunizieren können. In Bezug auf die Mensch-Maschine-Interaktion sind AMQP und MQTT einander recht ähnlich. Der Mensch sollte im Handbuch nach den verfügbaren Producer- Daten suchen.

Echtzeitverhalten: AMQP vs. MQTT

Da AMQP auch ein Publish/Subscribe-Kommunikationsprotokoll ist sind ebenfalls relativ kurze Transportzeiten möglich. Wegen der größeren Payloads wird zwar nicht die Schnelligkeit von MQTT erreicht, aber „beinahe in Echtzeit“ sollte auch hier möglich sein.

Sicherheit von AMQP

AMQP bietet als Protokoll zwar keine integrierte Security, Sicherheit kann jedoch durch mehrere Maßnahmen erreicht werden. So kann die zugrunde liegende Netzwerkverbindung mit TLS verschlüsselt und eine Authentifizierung der Teilnehmer mit SASL angewendet werden.

Implementierung: AMQP vs. MQTT

AMQP basiert wie MQTT auf Publish/Subscribe, bietet jedoch mehr Möglichkeiten zur Übermittlung der Nachrichten. Dadurch ist zum einen der Ressourcenbedarf bei der Anwendung deutlich höher und zum anderen auch die Implementierung erheblich komplexer. Wenn der erweiterte Funktionsumfang die Verwendung von AMQP erfordert, wird zur Umsetzung die Nutzung von Bibliotheken empfohlen. Zumindest das AMQP-Transportprotokoll sollte auf diese Weise implementiert werden.

Anwendung von AMQP

AMQP wird hauptsächlich im Geschäfts- und Unternehmenssektor eingesetzt, hat jedoch seine Stärken in leichten Implementierungen, bei denen eine vollständige Lösung unabhängig von externen Anwendungsschicht-Protokollen wie HTTPS oder WebSockets implementiert werden soll. Ähnlich wie bei MQTT, aber etwas allgemeiner, eignet es sich beispielsweise für:

  • die Überwachung und globale Freigabe von Updates
  • die Bereitstellung von Daten für Offline-Clients zu einem späteren Zeitpunkt
  • die Überwachung von risikobezogenen Daten oder die Steuerung interner Vorgänge
  • die interne Verteilung von Ereignissen

White Paper: TCP-basierte Kommunikationsprotokolle

Sie wollen mehr über TCP-basierte Kommunikationsprotokolle erfahren? Die vier IIoT-Protokolle OPC UA, MQTT, AMQP und REST API im detaillierten Vergleich: Laden Sie sich unser kostenfreies Whitepaper herunter.

Abonnieren Sie unseren Newsletter und erhalten Sie regelmäßig Neuigkeiten und Wissenswertes aus der Welt der Automatisierung.

Abonnieren