Anwendungen der Industrie 4.0, das Internet of Things (IoT) und ähnliche Konzepte basieren auf der Verteilung verschiedener Funktionen auf unterschiedliche Steuerungen und der geregelten Zusammenarbeit der Komponenten. Der neue Ansatz geht deutlich über klassische Steuerungskonzepte hinaus, welche ihrerseits in der Regel auf dem Prinzip der Speicherprogrammierbaren Steuerung (SPS) basieren und für eine Dezentralisierung der Sensorik und Aktorik digitale industrielle Kommunikationssysteme nutzen.

Mit Unterstützung durch die Organisation PLCopen hat sich zur Programmierung industrieller Steuerungen der Standard IEC 61131 am Markt etabliert. Mit der dritten Edition des Teils IEC 61131-3 ist mittlerweile auch ein objektorientiertes Konzept der Funktionsblöcke inklusive abstrakter Schnittstellen vorgesehen. Ein weiterer Schritt in Richtung Austausch von Steuerungsprogrammen zwischen den Engineering-Werkzeugen wurde mit PLCopen-XML gegangen. Dieses Format wird gegenwärtig als Teil 10 der Normenreihe standardisiert.

Schwieriger sieht es mit dem Austausch von Daten zur Laufzeit zwischen Steuerungen aus. Diese Kommunikation muss stets explizit konfiguriert werden, wobei hierbei ebenfalls die indus­triellen Kommunikationssysteme wie Profinet mit dem Controller-to-Controller-Profil oder auch das zwischen PLCopen und der OPC Foundation gemeinsam entwickelte OPC-UA-Informationsmodell vereinfachend wirken. Der OPC UA Client kann mittlerweile auf der Steuerung implementiert sein. Ist dieser nicht vorhanden, muss noch eine zusätzliche Orchestrierung der ­Datenverbindungen zwischen den auf den Steuerungen laufenden OPC-UA-Diensten vorgenommen werden.

Aus Sicht der Steuerungsprogramme hat die oben erwähnte IEC 61131-3 einen wichtigen Schritt in Richtung Software-Qualität geleistet. Das darin eingeführte Funktionsblockkonzept erlaubt eine gute Kapselung der Programmteile und erhöht gleichzeitig die Testbarkeit und Wiederverwendungsfähigkeit vom Programmcode. Die Anforderungen an die Software-Qualität steigen allerdings weiter. So empfiehlt es sich, für die Erstellung von Programmen, die im Umfeld der funktionalen Sicherheit zum Einsatz kommen, formale Mittel bei der Programm-Erstellung einzusetzen. Bewährt haben sich Herangehensweisen, die auf dem Prinzip der Zustandsmaschine (Endlicher Automat) beruhen. Die Notation der Logik ist relativ einfach und das Ergebnis lässt sich formal darstellen. Nachteilig wirkt, dass große Netzwerke hinsichtlich der jeweiligen Zustände und Transitionen schnell unübersichtlich werden. Abhilfe schafft hier eine Hierarchisierung der Zustände. Aufbauend auf der Theorie der endlichen Automaten wurden zum Beispiel die Petrinetze entwickelt, die vorwiegend für diskrete, verteilte Verhaltensbeschreibungen genutzt werden.

Neben den erwähnten Entwurfsmitteln bedarf es aber einer Laufzeitumgebung, welche die so entworfenen Programme ausführen kann. Geht es um die Betrachtung einer einzelnen Steuerung, kann man entsprechende Werkzeuge in die Engineering-Umgebungen integrieren. Bei einem Verbund von heterogenen Steuerungen ist allerdings noch eine zusätzliche Abstraktionsschicht einzuführen. Die Informatik hat für diese neu hinzugefügte Schicht den Begriff ‚Middleware‘ geprägt. In VDI/VDE 2657 (Blatt 1) hat man sich der Thematik in der Art genähert, als dass Merkmale und Anforderungen hinsichtlich Auswahl und Einsatz dieser Software beschrieben wurden. Blatt 2 definiert ein Vorgehensmodell, das für Middleware-Engineering-Prozesse genutzt werden kann, wobei hier die unterschiedlichen Rollen vom Hersteller bis zum Anwender beleuchtet werden. Im Idealfall kommt eine Middleware ohne die Kenntnis des Endanwenders zum Einsatz. Jedoch stellt der Einsatz einer Middleware auch immer eine Systementscheidung dar.

Bild 1: Schichten einer Middleware: Dienste für zusammengehörende Aufgaben sind entsprechend dem Schichtenmodell geordnet.

© Ifak

Die Vorteile beim Einsatz von Middleware liegen neben der Abstraktion auf einer spezifischen Plattform in der Verbesserung der Interoperabilität zwischen heterogenen Systemen. Bild 1 zeigt eine mögliche Gestaltung einer Middleware, die aufsetzend auf der Plattform-Abstraktion mit Diensten wie Speichermanagement (zum Beispiel portable Auto-Pointer), Threads, Synchronisierung, Netzwerk/Sockets, Dateisystem-Mechanismen oder Zeichensatzbehandlung auch eine Verteilungsschicht bereithält. Auf eine Ausprägung dieser Schicht wird später noch gesondert eingegangen.

Zu den allgemeinen Diensten einer Verteilungs-Middleware zählen das Auffinden aller Rechner im Netzwerk, die Uhrzeitsynchronisation, das Starten/Stoppen/Beenden lokaler oder entfernter Prozesse oder die Introspektion (Selbstbeobachtung) von Knoten. Für den Einsatz von Middleware in der Automatisierung von Produktionsprozessen sind darüber hinaus domänenspezifische Dienste beispielsweise für die Einhaltung von Echtzeit-Anforderungen wichtig.

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.

Bild 2: Ein Aktor kann sowohl Nachrichten empfangen und darauf reagieren als auch selbst aktiv eine eigene Logik ausführen und Nachrichten versenden. Untereinander kommunizieren Aktoren nur über Nachrichten.

© Ifak

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 Ac­tive 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 Engineer­ing-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.

Objekte beschreiben sich selbst

Bild 3: Verteilte Applikation auf Basis von über Ports verknüpften Objekten.

© Ifak

Bild 3 zeigt schematisch eine verteilte Applikation, bei der das Objekt-Netzwerk auf drei CPS verteilt ist. Die Farben der Ports symbolisieren die ­unterschiedlichen Port-Typen. Die Middleware etabliert nur Verbindungen zwischen Ports mit gleichem beziehungsweise kompatiblem Typ. Je nach Lokalität des Kommunikationspartners werden automatisch die ‚richtigen‘ Verbindungen etabliert, das heißt bei einer Verbindung zu einem entfernten Objekt wird eine Netzwerk-Verbindung automatisch eingerichtet. Wichtig für die Etablierung solcher Systemaufbauten auf Basis von CPS (Systems of CPS) ist die Möglichkeit, die Fähigkeiten der CPS jederzeit zu erkunden. Das bedeutet, dass vorgefertigte Kompo­nenten mit statisch festgelegten Funktionen ­(entspricht heutzutage zum ­Beispiel Feldgeräten mit Funktionsvorverar­beitung) oder dynamisch ladbare Funktionen zur Laufzeit über ­offen ­gelegte Schnittstellen ermittelt werden können.

Diese Grundkonzepte in der Middleware DOME liefern die Basis für vielfältige Applikationsmuster. So lassen sich klassische Funktionsblock-Konzepte der IEC 61131 realisieren, IEC-61499-konforme Applikationen erstellen oder Applikationen auf Basis von formalen Zustandsmaschinen entwerfen, wobei diese verteilt auf den CPS abgearbeitet werden können. Unter Anwendung des so genannten ‚State ­Design Pattern‘ lassen sich Zustandsmaschinen in eine objektorientierte Darstellung überführen. Einzelne Zustände werden dabei als Klasse modelliert, welche die gleiche Basisklasse implementieren. In dieser sind alle möglichen Transitionen als Methode hinterlegt. Jeder Zustand implementiert die Transitionen, auf welche der Zustand schalten kann. Eine Klasse zur Verwaltung regelt den Zustandswechsel auf generische Weise, indem er Methoden für Transitionen (=> Signale) bereitstellt und den aktuellen Zustand mitführt.

Verteilte Steuerung – ein Beispiel

Bild 4: Beispiel Lichtsignalanlage: Die Sequenz der Phasen ist oben links dargestellt.

© Ifak

Als ein einfaches Beispiel dafür, wie sich eine Steuerung auf Basis von CPS beziehungsweise unter Verwendung der DOME-Middleware mit einer verteilten Zustandsmaschine realisieren lässt, soll die Steuerung einer Lichtsignalanlage (LSA) dienen. Die Applikation ist als verteilt arbeitende Zustandsmaschine implementiert. Das Steuerungssystem besteht aus zwei kooperierenden Steuerungen, die jeweils die LSA für eine Hauptfahrrichtung steuern. Die Steuerungsaufgabe sieht wie folgt aus: Jede der Fahrtrichtungen wird durch eine Signalgruppe bedient (s0 – s3 im Bild 4). Nachdem ein Umlauf komplett ist, also wieder im Zustand ‚Rot‘, wird ein Si­gnal zur nächsten Signalgruppe gesendet, welche daraufhin mit ihrem Umlauf beginnt. So steuern sich die LSA gegenseitig (kooperativ), ohne eine zentrale Steuerungseinrichtung zu benötigen.

Die LSA dieser Kreuzung ist in das Gesamtverkehrskonzept einer Stadt eingebunden. So wird neben dem Regel­betrieb der Modus ‚Nachtabschaltung‘ (gelb blinken in alle Richtungen) unterstützt. Für diesen Zweck besitzt jede der Signalgruppen einen Umschalter für den Betriebsmodus. Die Steuerung der Phasen ist wie folgt gelöst: Eine Transition vom Zustand ‚Rot‘ dieser Zustandsmaschine ist verbunden mit dem Zustand ‚RotGelb‘ der Zustandsmaschine der Gegenrichtung. Schaltet eine Signalgruppe von ‚Grün‘ über ‚Gelb‘ nach ‚Rot‘, wird beim Erreichen des Zustands ‚Rot‘ ein Ereignis ‚Weiterschalten‘ ausgelöst, welches die oben genannte Transition auslöst und dadurch die Gegenrichtung in ‚RotGelb‘ versetzt (siehe Bild 5). Die Steuerung der Phasen funktioniert so ohne zentrale Steuerungseinheit, sie wird durch die Komponenten kooperativ vorgenommen.

Die Zustandsmaschinen der einzelnen Signalgruppe sind zu einer Zustandsmaschine für die gesamte Lichtsignalanlage verbunden. Hier wurde auch die Anbindung zum Verkehrsmanagement der Stadt entsprechend hergestellt. Durch letzteres werden ‚ModusUmschalten‘-Ereignisse ausgelöst, die zu einem Wechsel zwischen Regelbetrieb und Nacht­abschaltung führen.

Die einzelnen Zustandsmaschinen werden für dieses Steuerungsbeispiel nicht kopiert. Vielmehr lassen sich Zustände zu wiederverwendbaren Gruppen verbinden. Eine Änderung in einer Version der Gruppe ist in allen Instanzen sofort sichtbar. Die Zustände können zwischen den verschiedenen Gruppen verbunden werden. Darüber hinaus erlauben die Gruppen eine Parametrierung. Beispiele hierfür sind die Grünphase oder die Festlegung der Phasenübergangszeiten. Zu den Parametern kann zudem die IP-Adresse oder eine Geräte-Identifikation eines CPS gehören, auf der eine Gruppe von Zuständen zur Ausführung kommt. Das ermöglicht die Abarbeitung von Teilen einer Zustandsmaschine auf verschiedenen CPS.

Kurzum: Durch das Modellieren mit Zustandsmaschinen können Steuerungen formal entwickelt und bewertet werden. Die Umsetzung durch das ‚State Design Pattern‘ macht sie automatisch zu einem modularen Algorithmus, welcher sich durch geeignete Dienste der Ver­teilungsschicht einer Middleware auf verschiedene CPS distribuieren lässt und letztendlich die Umsetzung kooperativer Steuerungen erleichtert. Durch Zusammenfassen von Zuständen zu parametrierbaren, individuell agierenden Gruppen wird zum einen die Wiederverwendbarkeit erhöht, andererseits lässt sich die Steuerung so flexibel gestalten. Parameter wie die Dauer der Phasen ­beziehungsweise das ausführende CPS können auf diese Weise zur Entwicklungszeit festgelegt und an die Laufzeit angepasst werden.

Autoren:
Marco Meier ist Wissenschaftlicher Mitarbeiter des Geschäftsfeldes IKT & Automation am ifak Magdeburg;
Dr. Matthias Riedl ist Leiter des Geschäfts­feldes IKT & Automation am ifak Magdeburg;
Holger Zipper ist Wissenschaftlicher Mitarbeiter des Geschäftsfeldes IKT & Automation am ifak Magdeburg.