M2M, IoT, Industrie 4.0
Cyber Physical Systems sinnvoll 'modellieren'
Cyber-Physical Systems – kurz CPS – spielen im Kontext von Industrie 4.0 und IoT eine bedeutende Rolle. Wie aber lassen sich die bewährten formalen Entwurfsmuster der Automatisierung mit dem dahinterstehenden, kooperativen Steuerungskonzept vereinen?
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 industriellen 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.
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.
- Cyber Physical Systems sinnvoll 'modellieren'
- Orchestrierung auf höherer Ebene
- Objekte beschreiben sich selbst
- Verteilte Steuerung – ein Beispiel
Lesen Sie mehr zum Thema
