Schwerpunkte

Verteilte Systeme

Licht ins Nachrichten-„Chaos“ bringen

21. November 2019, 13:48 Uhr   |  Günter Herkommer

Licht ins Nachrichten-„Chaos“ bringen
© Fraunhofer ESK

Immer mehr Komponenten in der Automatisierungstechnik senden ‚ungefragt‘ auf Basis der Pub/Sub-Mechanismen Nachrichten in das Netz. Mit Hilfe des Frameworks DANA lässt sich Licht in einen von außen ­chaotisch wirkenden Nachrichtenaustausch bringen.

Industrie 4.0 bringt einen Wandel der Kommunikationsstrukturen in der Produktion mit sich. So ermöglicht es die RAMI-4.0-Architektur (Referenzarchitekturmodell Industrie 4.0), die bisherige geordnete, pyramidenförmige Kommunikationsstruktur, bestehend aus technologisch unterschiedlichen Segmenten von klassischen Master/Slave- beziehungsweise Client/Server-Ansätzen, aufzulösen. Das Konzept sieht vor, dass beliebige Komponenten im Shop Floor – vom einzelnen Sensor bis hin zu ganzen Maschinen – untereinander, aber auch mit der Ebene der Unternehmens-IT (ERP-Anwendungen) kommunizieren können. Damit soll es jeder Komponente im Netzwerk eines Unternehmens möglich sein, sowohl Informationen bereitzustellen als auch abzufragen – und das möglichst ohne technologische Hürden.

Ein Beispiel hierfür ist das Life Cycle Management einer Maschinenkomponente mit Hilfe der Verwaltungsschale. Sogenannte Publish/Subscribe-Protokolle haben das Potenzial, dieses Konzept optimal zu unterstützen. Pub/Sub-Protokolle wie Message Queuing Telemetry Transport (MQTT), Advanced Message Queuing Protocol (AMQP) oder Constrained Application Protocol (CoAP) wurden ursprünglich für IoT-Anwendungen entwickelt, um Sensordaten in die Cloud zu transportieren und sie dort verarbeiten zu können. Neuerdings kommen diese Protokolle aber zunehmend auch bei M2M-Anwendungen (Machine-to-Machine) zum Einsatz. Und seit 2018 ist Pub/Sub auch im Standard OPC UA integriert.

Pub/Sub – Lösung und Problem zugleich

Pub/Sub bietet zwar viele Vorteile wie eine hohe Skalierbarkeit oder den Aufbau von Ad-hoc-Verbindungen. Bei sehr hoher Vermaschung, sprich einem sehr hohen Anteil an Peer-to-Peer-Verbindungen wie es bei M2M-Anwendungen der Fall ist, entstehen jedoch neue Probleme: Jeder Teilnehmer muss dafür sorgen, dass er seine Informationen in Form von Nachrichten korrekt veröffentlicht. Fehlt eine Nachricht oder wird eine Nachricht mehrmals gesendet, kann das Auswirkungen auf das gesamte verteilte System haben. Hinzu kommt: Je mehr Abhängigkeiten zwischen den Teilnehmern untereinander existieren, um so instabiler kann die verteilte Anwendung werden. Kommuniziert ein Teilnehmer mit vielen anderen Teilnehmern, ergibt sich unter Umständen ein Komplexitätsgrad, der den Nachrichtenaustausch und deren korrekte Abfolge in einem verteilten System nur schwer nachvollziehbar macht. Bei gewachsenen Anwendungen lässt sich das unter Umständen nicht vermeiden; bei einem Neudesign hingegen ist eine schlanke Architektur mit möglichst wenigen Abhängigkeiten zwischen den Teilnehmern (Vermeidung von gekoppelten Sternstrukturen) anzustreben. 

Die geschilderten Probleme werden umso deutlicher, wenn Eigenschaften einer strukturierten logischen Vernetzung notwendig sind, zum Beispiel ein definiertes Zeitverhalten in einer verteilten Anwendung mit definierten Zuständen. Bestehen darüber hinaus verkettete zeitliche Abhängigkeiten, kann die Umsetzung eines solchen Systems mit Hilfe von Pub/Sub-Protokollen eine große Herausforderung darstellen.

Publish/Subscribe beschreibt einen Mechanismus, der es Teilnehmern einer vernetzten Anwendung ermöglicht, untereinander Nachrichten auszutauschen, ohne dass die Teilnehmer sich vorab abstimmen müssen. Dies wird auch als entkoppelte Kommunikation bezeichnet. So wurden Pub/Sub-Protokolle ursprünglich dafür entwickelt, den Nachrichtenaustausch zwischen Teilnehmern zu ermöglichen, die untereinander über unzuverlässige Kommunikationskanäle – zum Beispiel solche mit Abbrüchen oder wechselnden Bandbreiten – verbunden sind. Auch die Kommunikation mit Teilnehmern, die sporadisch oder jedenfalls nicht dauerhaft in Betrieb sind, sollte möglich sein.

Umgesetzt wird dies durch sogenannte Nachrichten-Broker. Dabei meldet sich ein Teilnehmer, der eine Nachricht senden möchte (Publisher), bei einem Broker an und definiert für diese Nachricht ein sogenanntes Topic. Andere Teilnehmer, die diese Nachricht empfangen möchten (Subscriber), abonnieren das Topic und erhalten von dem Nachrichten-Broker entsprechende Nachrichten des Publishers, sobald dieser eine neue Nachricht an den Broker schickt.

Vor- und zugleich Nachteil der entkoppelten Kommunikation ist, dass Empfänger und Sender sich nicht kennen. Beide wissen nicht, wer von ihnen gerade in Betrieb ist und wie viele Empfänger das Topic abonniert oder die Nachricht bekommen haben. Es findet somit kein Hand Shake zwischen den Kommunikationspartnern statt, was eigentlich für eine zuverlässige Kommunikation zwischen den Teilnehmern notwendig wäre.

Seite 1 von 3

1. Licht ins Nachrichten-„Chaos“ bringen
2. Kritischer Punkt: Zeitvorgaben
3. DANA lernt mit

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Verwandte Artikel

Fraunhofer ESK (Institut für Eingebettete Systeme und Kommunikationstechnik)