M2M-Kommunikation Der Feldbus 4.0

Der mit Industrie 4.0 einhergehende Einzug neuer Informations- und Kommunikationstechnik in die Automatisierungstechnik wird zukünftig die Vernetzung über die Grenzen der einzelnen Ebenen der Automatisierungspyramiden hinweg stark fördern. Das Ziel ist es, eine einzige einheitliche und herstellerunabhängige Kommunikationstechnologie in allen drei Kommunikationsebenen zu verwenden – in der Leitebene, der Maschinenebene und ebenso in der Feldebene.

Die Technologie Open Platform Communications – Unified Architecture (OPC UA) ist dafür ein vielversprechender Kandidat. OPC UA ist der Nachfolger von OPC Classic. Letzterer hat auf dem Distributed Component Object Model (DCOM) von Windows basiert. Bisher wird OPC UA vor allem in der Kommunikation zu den oberen Ebenen (Leitebene und HMI) genutzt, jedoch weniger in der Kommunikation zwischen Steuerungen, also in der Machine-to-Machine-Kommunikation (M2M), und zur Feldebene.

Ein Grund hierfür ist die geringere Eignung der Server-Client-Architektur für die Feldebene, da die Architektur auf dem Request-/Response-Mechanismus basiert. Bei diesem Mechanismus wird, um Daten zu übertragen, eine Verbindung zwischen Server und Client aufgebaut. Vor allem bei Szenarien mit vielen Kommunikationsteilnehmern können diese Verbindungen auf Serverseite sehr ressourcenintensiv sein.

Deshalb erweitert die OPC Foundation OPC UA um eine neue Architektur, dem sogenannten Publish Subscribe (PubSub). PubSub nutzt hier im Vergleich zur Server-/Client-Architektur einen anderen Ansatz, bei dem die Teilnehmer voneinander entkoppelt sind. Das heißt, die Teilnehmer müssen keine Verbindung untereinander aufbauen.

Verbindungslose Kommunikation

Es gibt prinzipiell zwei unterschiedliche Ansätze zur verbindungslosen Kommunikation in der aktuellen OPC UA PubSub Spezifikation 1.04. Bei der brokerbasierten Kommunikation kommt eine Zwischenschicht (der Broker) zum Weiterleiten von Nachrichten zum Einsatz. Das heißt, ein Publisher sendet seine Nachricht zunächst an einen Broker und ein Subscriber meldet sein Interesse an den Daten beim Broker an. Als Transportprotokolle werden Advanced Message Queuing Protocol (AMQP) und Message Queue Telemetry Transport (MQTT) eingesetzt. Beide Protokolle sind offene, standardisierte Netzwerkprotokolle auf Anwendungsebene für eine nachrichtenorientierte Zwischenschicht.

Der zweite Ansatz ist die brokerlose Kommunikation. Sie basiert rein auf der Netzwerkinfrastruktur zwischen Publisher und Subscriber. Hierbei werden die Protokolle OPC UA UDP und OPC UA Ethernet verwendet.

Protokolle und Message Mappings

Neben diesen Ansätzen sieht die Spezifikation die Verwendung von vier Protokollen und Message Mappings vor. Im Nachfolgenden sollen zuerst die Protokolle und anschließend zwei Mappings kurz beschrieben werden:

• OPC UA UDP basiert auf dem User Datagram Protocol (UDP). Als Zieladresse kann Unicast, Multicast oder Broad­cast genutzt werden. Der in IANA registrierte Port für OPC UA UDP Nachrichten ist 4840.

• OPC UA Ethernet ist ein auf Ethernet basierendes Protokoll mit einem eigenen Ethertype 0xB62C. Eine Nachricht besteht aus drei Teilen – dem Kopfzeilenrahmen, der Payload und dem Fußzeilenrahmen. Der Kopfzeilenrahmen enthält ausschließlich für die Sicherungsschicht relevante Informationen wie die Ziel-MAC. Die Payload kann etwa mit dem Message Mapping UADP kombiniert werden.

• Das Advanced Message Queuing Protocol (AMQP) ist ein offenes, standardisiertes Protokoll basierend auf einer nachrichtenorientierten Kommunikation über eine Zwischenschicht. Üblicherweise wird AMQP in Kombination mit einem Broker verwendet. Ein Broker ist dabei eine Zwischeninstanz, die Nachrichten zwischen Applikationen weiterleitet, die nicht direkt miteinander kommunizieren möchten oder sollen. Als Payload kann UADP Message Mapping oder JSON Message Mapping ausgewählt werden.

• Der Message Queue Telemetry Transport (MQTT) ist ein offenes, standardisiertes Protokoll basierend auf einer nachrichtenorientierten Kommunikation über eine Zwischenschicht. Das MQTT-Protokoll definiert ein binäres Protokoll zum Senden und Empfangen von Nachrichten.

• UADP Message Mapping nutzt optimiertes UA Binary Encoding und stellt Security-Funktionalitäten zum Verschlüsseln und Signieren von Nachrichten zur Verfügung. UADP wird primär für OPC UA UDP/Ethernet verwendet.

• JSON Message Mapping ist in RFC 7159 definiert. JSON bietet ein für den Menschen leicht lesbares Austauschformat, welches von Maschinen einfach zu parsen ist und vor allem bei Webapplikationen eingesetzt wird.

M2M-Anwendungsbeispiel

Die Abbildung auf dieser Seite zeigt ein Anwendungsbeispiel einer M2M-Kommunikation mit dem OPC UA PubSub Standard. Es sollen Prozessdaten, zum Beispiel Kommandos und Stellgrößen, der Maschine 1 an die Maschine 2 geschickt werden. Die Prozessdaten werden vom Publisher enkodiert, in eine Netzwerknachricht verpackt und etwa über UDP an das Netzwerk geschickt. Maschine 1 kennt dabei Maschine 2 nicht. Es wird auch zu keinem Zeitpunkt eine direkte Verbindung zwischen den Maschinen aufgebaut, da OPC UA PubSub auf einer entkoppelten Kommunikation basiert. Maschine 2 empfängt die Nachricht über den Subscriber, welcher die Daten dekodiert. Danach schickt Maschine 2 die eigenen Prozessdaten, beispielsweise Istwerte und Status, über einen eigenen Pub­lisher an Maschine 1.

Falls es der Anwendungsfall benötigt, kann hier auch die Ethernet-Erweiterung Time Sensitive Networking (TSN) verwendet werden, um Echtzeitmechanismen, wie Synchronisierung der Uhren dieser Maschinen oder zeitgesteuertes Senden der Nachrichten, zu nutzen.

Publisher und Subscriber können zum Beispiel über einen OPC-UA-Server konfiguriert werden. Im-OPC-UA-Server werden sämtliche Konfigurationsparameter der Publisher und Subscriber über das PubSub-Informationsmodell nach außen zugänglich gemacht. Außerdem werden Methoden im Informationsmodell zur Verfügung gestellt, um weitere Publisher und Subscriber zu erstellen und zu konfigurieren. Diese Parameter und Methoden können dann über einen OPC-UA-Client gelesen, beschrieben und ausgeführt werden.

Anwendungsfälle wie diese werden vermehrt in sogenannten Testbeds nachgestellt, etwa im TSN Testbed des Industrial Internet Consortiums (IIC). Ein Anwendungsfall ist eine M2M-Kommunikation, bei der zwei Steuerungen miteinander kommunizieren, um deren jeweilige Achsen synchron verfahren zu lassen. Diese Anwendung wurde über TSN und OPC UA PubSub realisiert. Die Applikation nutzt die Master-Slave-Konfiguration über Publisher und Subscriber. Hierzu wird das Protokoll OPC UA UDP mit UADP kombiniert.

Für die Umsetzung existieren verschiedene Ansätze. Welche der Konfigurationen besser ist, hängt stark vom Anwendungsfall ab. Je nach verwendeter Adressierung ergeben sich unterschiedliche Anforderungen an das Netzwerk und die Hardware der Maschinensteuerungen. Im Folgenden werden einige Möglichkeiten der Konfiguration vorgestellt.

Drei Ansätze für die Konfiguration

Master-Slave-Konfiguration: Die Master-Maschine hat einen Publisher, der eine Network-Message erstellt und an das Netzwerk schickt. Je nachdem ob man eine Multicast-Adressierung oder eine Unicast-Adressierung verwendet, ändert sich die Struktur der Network-Message.

Multicast-Adressierung: Nutzt man die Multicast-Adressierung, erstellt der Publisher eine Network-Message mit zwei Data-Set-Messages, welche die Daten für die Maschine 1 und Maschine 2 enthalten. Die Network-Message wird etwa über UDP an eine Multicast-Adresse geschickt. Maschinen, die auf diese Adresse registriert sind, erhalten die Network-Message und filtern über entsprechende IDs die für sie relevanten Daten heraus. Die DataSetMessage 1 enthält zum Beispiel die Daten für die Maschine 1 und umgekehrt.

Unicast-Adressierung: Bei der Unicast-Adressierung erzeugt der Publisher der Master-Maschine für jede Maschine eine eigene Network-Message mit den für die Maschine passenden Data-Set-Messages. Der Nachteil von Unicast ist eine größere Netzwerklast auf Seiten des Publishers.