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. So-genannte 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.

Entkoppelte Kommunikation

Beispiel eines Zustandsmodells für drei untereinander kommunizierende Steuerungen/Stationen

© Fraunhofer ESK

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 so-genanntes 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. 

Kritischer Punkt: Zeitvorgaben

Was für verteilte zustandslose Anwendungen sinnvoll ist, kann jedoch für verteilte Anwendungen mit zeitlichen Abhängigkeiten zu Problemen führen, zum Beispiel:

•    Race Hazards: Eine Nachricht kommt bei einem Teilnehmer früher an als eine andere, was zu unerwünschten Effekten führen kann und darüber hinaus schwer nachvollziehbar ist.
•    Einzelne Teilnehmer sind aufgrund zu geringer Resourcen überlastet und können eingehende Nachrichten nur verzögert verarbeiten.

Wesentliche Bestandteile der DANA-Plattform

© Fraunhofer ESK

Um dem Umstand Rechnung zu tragen, dass Pub/Sub-Protokolle immer mehr in M2M-Anwendungen zum Einsatz kommen, wurden in der aktuellen Version 5 des MQTT-Protokolls die Quality of Service(QoS)-Mechanismen erweitert. Diese bestanden bisher ausschließlich aus der Definition von drei QoS-Leveln, die zwar eine garantierte Übertragung der Nachrichten zwischen Publisher und Broker sowie Broker und Subscriber gewährleisteten, aber das zeitliche Verhalten nicht berücksichtigten. Mit der Version 5 wurde mit Hilfe einer Request/Response-Funktion nun eine Kontrollmöglichkeit für eine Ende-zu-Ende-Übertragung von Nachrichten zwischen Publisher und Subscriber eingeführt. Außerdem kann eine Nachricht mit einer Gültigkeitsdauer versehen werden.

Während Protokolle wie MQTT oder AMQP meistens Broker verwenden, kommt das Protokoll DDS ohne Broker aus. So verwendet DDS den sogenannten  RTPS-Discovery-Mechanismus. Das RTPS (Real Time Publish Subscribe)-Protokoll setzt auf UDP auf und ermöglicht den Teilnehmern eines Netzwerks, die jeweils gewünschten anderen Teilnehmer ausfindig zu machen.
Auch bei OPC UA ist der Einsatz einer Broker-basierten und einer Broker-losen Variante vorgesehen. Ob ein Broker zum Einsatz kommt, hängt von der Anwendung ab: Soll die Nachricht eines Publishers an sehr viele Subscriber gehen oder umgekehrt ein Subscriber Nachrichten von sehr vielen verschiedenen Publishern erhalten (One to Many), so lässt sich mit einem dazwischenliegenden Broker der Kommunikationsaufwand des sendenden Teilnehmers stark reduzieren. Wird Pub/Sub in einer stark vermaschten Anwendung verwendet, ist eine direkte Verbindung zwischen den Teilnehmern ohne Broker effizienter, da ein Broker hier zum Nadelöhr der gesamten Kommunikation werden würde.  

OPC UA geht den Weg der Abstraktion und definiert zunächst eine Pub/Sub-
taugliche ‚Umgebung‘, die dann auf eine  ‚Message oriented Middleware‘ beziehungsweise auf konkrete Pub/Sub-Protokolle wie MQTT oder AMQP gemapped werden kann. Es wird hier aber auch eine UDP-basierte (User Datagram Protocol) oder reine Ethernet-basierte Kommunikation im Sinne einer Brokerlosen Kommunikation unterstützt.

DANA checkt verteilte Anwendungen

Michael Stiller ist wissenschaftlicher Mitarbeiter des Fraunhofer-Instituts für Eingebettete Systeme und ­Kommunikationstechnik ESK.

© Fraunhofer ESK

Betrachtet man die beschriebenen Pub/Sub-Mechanismen und deren Ausprägung in den verschiedenen Protokollen, wird offensichtlich, dass darauf aufsetzende, verteilte komplexe Anwendungen mit definiertem Zeitverhalten nur mit Hilfe neuer Software-Werkzeuge zu bewältigen sind. Diese müssen dazu fähig sein, das Verhalten dieser Anwendungen – genauer gesagt deren Kommunikation untereinander – in Echtzeit zu überwachen, zu analysieren und bei der Behebung von Problemen zu helfen. Mit dem Software-Tool DANA (Description and Analysis of Networked Applications) hat das Fraunhofer ESK einen solchen Lösungsansatz entwickelt. Die auf Eclipse basierte und somit unter Linux und Windows lauffähige Werkzeugplattform ermöglicht die Analyse und Überprüfung von Interaktionsverhalten und Kommunikationsprotokollen bei vernetzten Systemen. 

DANA geht davon aus, dass eine vernetzte Anwendung aus einem Verbund verteilter Funktionen besteht. Neben der Absicherung jeder einzelnen Funktion muss die Interaktion zwischen den Funktionen überprüft werden. Um die Kompatibilität zwischen verschiedenen Kommunikations-Stacks der Teilnehmer sicher-zustellen, kann auf Conformance-Tests zurückgegriffen werden. Diese überprüfen mit speziellen Tests, ob ein System das jeweilige Pub/Sub-Protokoll korrekt umsetzt. Wenn ein System ausreichend konform implementiert ist, kann es mit anderen Standard-konformen Systemen funktionieren. 

Gute Conformance Tests zu erstellen, ist jedoch sehr aufwendig. Dementsprechend liegen sie nur für grundlegende, häufig verwendete Kommunikationsprotokolle vor. Die darauf aufbauenden Anwendungen sind aber so individuell, dass für diese keine allgemeinen Standards oder Test-Suiten existieren. Deshalb ist hier besonders die Absicherung der verschiedenen Funktionen bei deren Interaktion wichtig. Vor allem ist das dynamische Verhalten, also in welcher exakten Reihenfolge Funktionen mit anderen kommunizieren, zu definieren. Dazu verwendet DANA den modellgetriebenen Ansatz.

DANA lernt mit

Die Modelle von DANA beschreiben das gültige Kommunikationsverhalten von Software-Komponenten. Ein Abgleich von beobachtetem System-Verhalten mit den Modellen erlaubt es, Abweichungen durch sogenanntes Monitoring zu erfassen. Dabei lässt sich das System passiv beobachten, ohne dass gesonderte Tests entwickelt werden müssen. Spezielle Synchronisationsmechanismen erlauben es, dass DANA nach einem Fehlerfall – respektive einer Differenz zwischen Modell und tatsächlichem Verhalten – die weitere Überwachung des Systems nicht abbricht.

Um den hohen manuellen Aufwand für den Entwurf und die Wartung solcher Modelle zu verringern, kommen verschiedene Lernverfahren zum Einsatz. Damit können aus bereits existierenden Systemen Referenzmodelle teilautomatisiert abgeleitet werden. Dazu wird das reale Verhalten anhand der mitgeschnittenen Kommunikation als Zustandsautomat gelernt. Dieses Vorgehen bietet den Vorteil, dass die gelernten Automaten nachträglich anpassbar sind, um womöglich nicht gewollte Abweichungen oder nicht erfasstes Verhalten zu ergänzen.

Überwachung der verteilten Anwendung

Um eine verteilte Anwendung, die mit Hilfe von Pub/Sub-Protokollen kommuniziert, mit DANA überwachen zu können, sind eine allgemeine Beschreibung der Struktur der Protokoll-Schnittstellen sowie eine konkrete Beschreibung des Nachrichtenformats notwendig. Als Beschreibungssprache kommt Franca IDL zum Einsatz, wobei IDL für Interface Description Language steht. Außerdem muss das Sollverhalten der verteilten Anwendung mit Hilfe eines Interaktionsmodells beschrieben werden. 

Kommt ein Broker zum Einsatz, kann der DANA Message Feeder alle relevanten Topics der verteilten Anwendung abonnieren oder andernfalls die Rolle des ­Subscribers einnehmen. Wird kein Broker eingesetzt, muss der DANA Feeder ent­weder direkt in die Anwendung einge­bunden werden, oder er erhält über einen an das Netzwerk angeschlossenen Protokoll-Sniffer die von den Teilnehmern ausgetauschten Nachrichten. Die Nachrichten werden dann zeitlich und nach Publisher sortiert und an die DANA Runtime weitergereicht, die die eintreffenden Nachrichten mit dem Sollverhalten vergleicht. 
Läuft die Pub/Sub-basierte Anwendung nicht entsprechend dem Sollverhalten, erkennt DANA diese Abweichung und zeigt sie an. Da die Abweichung nicht modelliert wurde, ist der neue Zustand des Systems vorerst unbekannt. Das führt im Normalfall zum Abbruch des Analysevorgangs. DANA ist jedoch durch spezielle Algorithmen in der Lage, die Überprüfung in Echtzeit automatisch wiederaufzunehmen ohne die Anwendung vorher in einen bestimmten Zustand bringen zu müssen.

Beispiel-Anwendung und Ausblick 

Das Framework DANA hat in verschiedenen industriellen Anwendungen gezeigt, dass ein Monitoring mit integrierter Anomalie-Erkennung die Qualität verteilter Anwendungen sowohl in der Entwicklungsphase als auch im Betrieb deutlich verbessern kann. So kann es zum Beispiel beim Hochlaufen einer Maschine mit 
verteilten Steuerungen zu Problemen im Zeitverhalten kommen. Reagiert eine der Steuerungen anders als gewohnt oder werden Nachrichten zwischen den Steuerungen nicht im definierten Zeitfenster ausgetauscht, lässt sich der Fehler mit DANA schnell lokalisieren und analysieren.
Das Fraunhofer ESK arbeitet jedoch nicht nur an Methoden zur Analyse verteilter Anwendungen, sondern auch an Simulationsumgebungen, mit deren Hilfe Pub/Sub-basierte Anwendungen vor ihrer Umsetzung im Hinblick auf optimale Performance und Skalierbarkeit planbar sind. Dazu werden die gesamte Netzwerk-Infrastruktur und die in den einzelnen Teilnehmern laufenden sowie über Pub/Sub-
Protokolle kommunizierenden Softwarekomponenten modelliert, um dann mit Hilfe einer Simulation das erwartete zeitliche Verhalten (mit oder ohne Message Broker) vorhersehen zu können. Damit ist ein nahtloses Engineering vom Design bis hin zum Betrieb komplexer Pub/Sub-basierter Anwendungen möglich.