M2M, IoT, Industrie 4.0
Cyber Physical Systems sinnvoll 'modellieren'
Fortsetzung des Artikels von Teil 1
Orchestrierung auf höherer Ebene
Der Ansatz der Cyber Physical (Production) Systems (CPS) trägt wesentlich zur Flexibilisierung der Steuerungsprogramme bei. Bei einem CPS handelt es sich um eine in ein Gerät integrierte Kombination aus Rechenleistung, (Internet-)Kommunikation und Zugriff auf den Prozess über entsprechende E/A-Schnittstellen.
Damit die in der Regel heterogen vorliegenden CPS auf Applikationsebene miteinander kooperieren können, müssen sie auf höherer Ebene orchestriert werden. Die eingangs beschriebene IEC 61131 stellt zusammen mit Austauschformaten wie PLCopenXML oder AutomationXML eine gute Ausgangsbasis dar, um kollaborative CPS zu entwerfen und Gesamtapplikationen zu orchestrieren. Allerdings ist die Nutzung unterschiedlicher Programmierwerkzeuge nicht für jeden Anwender eine Option. Einen Ausweg bietet die Nutzung einer Middleware, die eine Harmonisierung der heterogenen Knoten und der Engineering-Werkzeuge ermöglicht. Auf Basis dieser Middleware lassen sich Applikationen entwerfen und Funktionen auf die beteiligten CPS laden. Dieser Ansatz wird zum Beispiel auch von der IEC 61499 unterstützt, die ein Funktionsblock-Netzwerk als Gesamtapplikation auf verschiedene Knoten verteilen kann. Nachteilig ist bei diesem Konzept der Overhead der getrennten Daten- und Event-Verbindungen zwischen den Blöcken, was den Engineering-Aufwand enorm erhöht.
Geeigneter für eine Funktionsverteilung auf eine beliebige Anzahl von CPS scheint aus Sicht der Software-Architektur der Ansatz des Aktor-Modells (Bild 2) zu sein. Dieses sieht vor, Teilfunktionen des Gesamtsystems in eigenständigen Software-Objekten – den Aktoren – umzusetzen. Das Aktor-Modell beruht weiterhin auf dem Prinzip, dass die Aktoren untereinander über Nachrichten kommunizieren, die nicht blockierend versandt und asynchron verarbeitet werden. Es folgt damit auch dem ereignisgesteuerten Programmiermodell und sieht durch die rein nachrichtenorientierte Interaktion zwischen den Aktoren eine sehr lose Kopplung der Zusammenarbeit zwischen den Objekten vor. Ferner wird zunächst davon abstrahiert, auf welchem Computer ein Aktor zur Ausführung kommt. Durch diesen Ansatz lassen sich skalierbare Systeme aufbauen, die bei Bedarf leicht nachjustiert werden können.
Diesem Grundprinzip folgend sind Abwandlungen für eine geeignete Implementierung – etwa in Form von Active Objects – vorgenommen worden. Aktive Objekte verfügen über einen eigenen Ausführungskontext zum Beispiel in Form eines Betriebssystem-Threads. Eine weitere Variante wurde im ROOM-Ansatz (Real-Time Object-Oriented Modelling) bereits 1994 beschrieben: und zwar die Ausstattung der Aktoren mit Ports. Die Ports dienen als explizite Verknüpfungspunkte zwischen den Aktoren. Damit wird es möglich, Objekte analog zu Funktionsbausteinen vorzufertigen und in Form von Klassen(Typen) in Bibliotheken abzulegen. Während des Applikationsentwurfs werden die Objekte instanziiert und Daten- und Informationsflüsse über die Portverbindungen etabliert.
Das am Institut für Automation und Kommunikation (ifak) in Magdeburg entwickelte Konzept ‚Distributed Object Model Environment‘ (DOME) greift diese Architekturmuster auf und erweitert sie aus Sicht einer Laufzeitumgebung/Middleware für verteilte Applikationen um geeignete Mechanismen für die Portverbindungen. Innerhalb von DOME können Ports zwischen Objekten verknüpft werden, die entweder lokal auf dem gleichen CPS oder auf einem entfernten CPS zur Ausführung kommen. Die Middleware stellt dabei stets sicher, dass Verbindungen nur zwischen Ports gleichen Typs hergestellt werden können.
Dabei wird eine Selbstbeschreibung – sprich Reflexion – der Objekte genutzt. Jedes Objekt in DOME gibt Auskunft über sich selbst und damit auch über seine Ports. Die Ports wiederum sind auch selbstauskunftsfähig und beschreiben ihre Signatur, das heißt die Datentypen der Eingangs- und Ausgangsparameter oder den Rückgabewert bei einer blockierenden Abarbeitung. Alle Informationen zu Objekten oder Ports liegen sowohl zum Engineering-Zeitpunkt als auch zur Laufzeit der Applikation vor. Damit können Applikationen flexibel und dynamisch um neue Objekte ergänzt, zusätzliche Verbindungen zwischen Ports etabliert beziehungsweise Verbindungen oder Objekte entfernt werden.
- Cyber Physical Systems sinnvoll 'modellieren'
- Orchestrierung auf höherer Ebene
- Objekte beschreiben sich selbst
- Verteilte Steuerung – ein Beispiel
Lesen Sie mehr zum Thema
