Lässt sich eine SPS an beliebiger Stelle im Netzwerk auf Fog- oder Cloud-Rechner verteilen und als Smart Service über ein Pay-per-Use-Abrechnungsmodell nutzen? Erste Evaluierungen zeigen, dass ein solches Szenario alles andere als Utopie ist. – Das Unternehmen Logiccloud in Buchen hat sich die Umsetzung der Technologie in ein entsprechendes Produkt zum Ziel gesetzt.
Michael Böhrer, Produktmanager bei der Logiccloud AG in Buchen
Die Digitalisierung der Produktion wirkt sich auch auf die Automatisierungstechnik aus. Insbesondere die Nutzung von Cloud Computing und die Anwendung des Service-Paradigmas wird die zugrundeliegende Technologie stark verändern. Klassische Automatisierungssysteme gemäß der etablierten Automatisierungspyramide werden den wachsenden Anforderungen nicht gerecht.
Betrachtet man die Anforderungen von ubiquitärer Vernetzung, Cloud Computing und Service-Paradigma, so kristallisiert sich heraus, dass dagegen das CPS-basierte (Cyber Physical System) Automatisierungsmodell eine weitgehende Übereinstimmung mit den Anforderungen erfüllt. Es erscheint deshalb sinnvoll, diese Architektur als Grundlage für zukünftige Entwicklungen zu nehmen. Das Modell entstand 2012/13 in einem Arbeitskreis der VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik und setzt konsequent auf die Verteilung aller Funktionen auf allen Ebenen der Automatisierungspyramide als Dienste in einer domänenorientierten Netzwerkstruktur (Cloud). Als reale Automatisierungsgeräte verbleiben lediglich die Sensoren und Aktoren als CPS-Komponenten im technischen Prozess.
Die bisherigen Konzepte und Lösungen zur Umsetzung des Modells in der Echtzeit-Leitebene (Level 2) wurden bisher nur für prototypische Einzelsteuerungen nachgewiesen. Konzepte zur Umsetzung dieser Lösungen für eine hoch skalierbare, zuverlässige und sichere Cloud-basierte Automatisierungsumgebung liegen noch nicht vor. Ziel ist eine skalierbare und sichere SPS aus der Cloud mit dynamischen Ressourcenpools, die wesentliche Steuerungsfunktionalitäten nach IEC 61131-3 unter unkritischen Echtzeitbedingungen – über 50 ms – realisieren kann.
Konzept der domänenorientierten Netzwerkstruktur
Das Konzept einer SPS aus der Cloud geht unter dem Aspekt von Industrie 4.0 und IoT grundsätzlich davon aus, dass Webtechnologien die technische Basis für das Konzept bilden. Im Internet als globalem Rechnernetz stehen prinzipiell zwei Arten von Netzwerkrechnern zur Verfügung:
– Server-Rechner, die IT-Einheiten (Objekte, Dienste, Programme, Daten) bereitstellen und auch ausführen können.
– Client-Rechner, die IT-Entitäten lediglich ausführen können.
Das Arbeitsprinzip in diesem Server/Client-Rechnernetz ist das Client-Server-Prinzip. Ein Client muss also erst eine Anfrage stellen, damit eine IT-Einheit im Server ausgeführt werden kann. Das bedeutet, dass anwendungstechnische IT-Einheiten im Server nicht (automatisch) von selbst aktiv werden können. Als Client fungiert in der Regel ein Webbrowser auf dem Client-Rechner. Dies kann aber auch eine andere Client-Komponente sein.
Betrachtet man ein beliebiges anwendungsspezifisches Funktionssystem – etwa ein Leitsystem –, das mit Web-Technologie realisiert wird, so ergeben sich die Modelle für die Ausführung (RUN) dieses Systems:
- Das funktionale System ist nur auf dem Server gespeichert und wird auch nur dort ausgeführt. Die Ausführung des Systems auf dem Server startet der Client (Servermodus).
- Das funktionale System ist auf dem Server gespeichert und wird über eine Anfrage in den Client geladen. Das System wird nur im Client-Modus ausgeführt (Client-Mode).
- Das funktionale System ist auf dem Server gespeichert und Komponenten des funktionalen Systems werden ebenfalls auf dem Server ausgeführt. Weitere Komponenten werden über einen Request in den Client geladen und dort ebenfalls ausgeführt. Die Ausführung der Systemkomponenten im Server wird durch den Client gestartet (Mischbetrieb).
In allen drei Fällen kann das funktionale System auf mehrere Server (Cloud) oder mehrere Clients verteilt sein. Unter dem Aspekt der automatischen und einfachen Skalierbarkeit mit dynamischen Ressourcen spielt insbesondere der Servermodus nach Abb. 2a eine besondere Rolle, da hierfür bereits verschiedene Werkzeuge im Webbereich – etwa Containertechnologien – existieren. Das erläuterte Konzept der logiccloud baut daher auf dieser Grundstruktur auf. Daraus ergibt sich eine grundlegende Komponentenstruktur einer SPS aus der Cloud:
Im Server (Cloud) befinden sich beliebige Software-Instanzen einer SPS-Steuerung, auf denen unterschiedliche IEC 61131-3-Steuerungsprogramme ausgeführt werden können. Jede Steuerungsinstanz ist mit einem realen Automatisierungsgerät – Sensoren, Aktoren – über geeignete Netzwerkprotokolle (MQTT, OPC UA) verbunden. Die Automatisierungsgeräte sind als CPS-Komponenten aufgebaut und enthalten einen entsprechenden IP-Connector oder ein Gateway zur Kommunikation mit der Steuerungsinstanz. Die Verwaltung und Bedienung der Steuerungsinstanzen erfolgt über den Webbrowser (Client).
Das grundsätzliche Problem für eine praktikable und industrietaugliche Umsetzung der Struktur ist es nun, eine Möglichkeit zu schaffen, dass tatsächlich die Steuerungsinstanzen mit mit verschiedenen Automatisierungsgeräten und mehreren Steuerungsprogrammen im Netzwerk verteilt auf verschiedenen Knoten – Fog- oder Cloud-Knoten – verwaltet und bedient werden können. Dabei gilt es, Echtzeitbedingungen, Zuverlässigkeit und Sicherheit zu berücksichtigen.
Die Architektur besteht aus den folgenden fünf Hauptkomponenten:
– Die Systemadministration: Sie beinhaltet das Identity & Access Management, das Device & Location Management und alle Funktionen für die servicebasierte Abrechnung.
– Laufzeiten: Die Komponente Runtimes enthält alle Dienste, die zur Laufzeit in Logiccloud Verwendung, wie SPS-Laufzeitlogik, I/O-Laufzeit und I/O-Konnektoren.
– Bibliotheksdienste: Diese Komponente stellt Dienste zur Verfügung, die in den Design- und Laufzeitprozessen genutzt werden, wie den IEC 61131-3 Programmcompiler oder das Funktionsbibliotheksmanagement.
– Cluster-Infrastruktur: Sie ist das Rückgrat des gesamten Steuerungsclusters und stellt Werkzeuge für den Betrieb des gesamten Systems zur Verfügung. Dazu gehören die Datenbank, der Zertifikatsmanager, die Caching & Kommunikationsinfrastruktur.
– System-Überwachung: Sie ist für das Sammeln von Metriken und Protokollen aus der Infrastruktur verantwortlich und stellt Mittel zur Visualisierung der Systemleistung oder des Systemzustands bereit.
Die Eigenschaften der SPS-Steuerungsinstanzen bestimmen im Wesentlichen die beiden Komponenten Runtimes und Library Services.
Die Runtimes
In einer cloud-basierten Automatisierungsarchitektur – einem Cyber-Physical Production System (CPPS) – werden Daten, Dienste und Funktionen dort gespeichert, abgerufen und ausgeführt, wo sie im Sinne einer flexiblen und effizienten Entwicklung und Produktion am vorteilhaftesten sind. Dienste, Daten und Hardwarekomponenten lassen sich auf beliebige Knoten in einem Netzwerk verteilen und bilden funktionale Module, aus denen das Automatisierungssystem aufgebaut ist. Ziel sind global vernetzte und verteilte Systeme, die prinzipiell beliebige Kommunikationswege über alle Fabrikebenen hinweg erlauben. Zu diesem Zweck umfasst die Komponente Runtimes verschiedene Subsysteme.
Das Subsystem PLC Runtime ist für die Abarbeitung des IEC 61131-Steuerungsprogramms zuständig. Es arbeitet hauptsächlich im Zyklusmodus und nutzt das Subsystem I/O Broker, um I/O-Eingangsabbilder in I/O-Ausgangsabbilder zu konvertieren. Die Kommunikation mit den physikalischen Automatisierungsgeräten erfolgt über das Subsystem I/O Connectors.
Die Komponente Runtimes enthält auch ein Simulationssubsystem, mit dem sich ein SPS-Programm ohne reale E/A-Signale testen lässt. Für die Zukunft ist auch ein Digital Twin-Subsystem geplant, mit dem auf Basis der E/A-Abbilder der I/O-Runtime virtuelle Modelle als Abbild der realen physikalischen Realität verbunden werden können. Alle Subsysteme der Laufzeitkomponente sind als Dienste konzipiert.
Die Bibliotheksdienste
Die Kernelemente der Library Services sind die SPS-Programmcompiler für verschiedene IEC 61131-3 Programmiersprachen sowie ein Function Library Management, um Funktionsbibliotheken in den Steuerungsprogrammen nutzen zu können. Geplant sind außerdem ein Digital Twin Mapper zur Anbindung von 3D-Modellen an die SPS-Laufzeit und ein Logiccloud-Marktplatz (Market Place Services) zur Integration von Fremdkomponenten. Der Backend-Architektur ist ein Logiccloud-Portal überlagert, das der Anwender als Anwendungsumgebung (Frontend) für Engineering, Management und Betrieb nutzen kann.
Die Umsetzung und Bewertung
Das Logiccloud-Konzept basiert auf modernsten Webtechnologien. Dazu gehören:
– Die Containertechnologie mit Kubernetes für die automatisierte und beliebige Verteilung von Steuerungsinstanzen auf verschiedene Netzknoten
– JavaScript und C/C++ für die Backend-Programmierung
– HTML5 und das Responsive Design für das Frontend-Portal.
Darüber hinaus nutzt die Implementierung verschiedene Open-Source-Tools wie Keycloak für die Systemsicherheit, Grafana und Prometheus für Analytics, Logging und Metriken. Alle Funktionalitäten im Logiccloud-System sind als Microservices implementiert und lassen sich flexibel erweitern. Das Portal bietet die Erstellung von SPS-Projekten und Steuerungsprogrammen in den IEC 61131-3-Sprachen ST, LD, SFC und FBS im Rahmen einer integrierten Entwicklungsumgebung (PLC IDE).
Neben der Echtzeitfähigkeit der SPS-Instanzen liegt ein besonderes Augenmerk bei der Implementierung auf deren Security, Reliability und Safety. Im Hinblick auf die Sicherheitsmechanismen berücksichtigt die Implementierung die im Open Web Application Security Project identifizierten grundlegenden Bedrohungen und Risiken. Daher ist das Logiccloud-System von Anfang an sicherheitsorientiert konzipiert und nutzt bewährte Standardtechnologien wie
– Oauth2 mit 2FA
– Granulare rollen- und berechtigungsbasierte Zugriffskontrolle
– Verschlüsselte Kommunikation
– Laufzeitisolierung innerhalb des Kubernetes-Clusters.
Darüber hinaus integriert Logiccloud eine automatische Anomalie-Erkennung, mit der eine große Anzahl von Angriffen auf die Plattform identifiziert und verhindert werden kann. Um die Zuverlässigkeit der laufenden SPS-Instanzen zu gewährleisten, stehen eine Reihe von Maßnahmen bereit. Dazu gehören:
– Caching-Mechanismen für Laufzeit- und I/O-Images, Synchronisationsmechanismen zum schnellen Austausch einer fehlerhaften SPS-Laufzeitinstanz,
– die permanente Überwachung der Infrastruktur mit Hilfe von Selbstheilungsfähigkeiten,
– die Bereitstellung eines zusätzlichen Ressourcenpools, der in Notfällen als Puffer dienen kann.
Jede SPS-Instanz steuert reale physikalische Automatisierungsgeräte und muss mit diesen über das Netzwerk – Intranet oder Internet – zuverlässig verbunden sein. Netzwerkverbindungsprobleme allerdings kann das Logiccloud-System nicht abfangen, aber es sind einige Gegenmaßnahmen vorgesehen, die insbesondere die Maschinensicherheit gewährleisten sollen. Etwa die vorgesehene Verwendung von redundanten oder hybriden Netzwerkverbindungen mit schnellem Failover; die Verlagerung der SPS-Instanzen vor Ort an den Edge; die Einführung von Watchdog- und Ping-Signalen zur Erkennung von Stromausfällen und das Generierung von Warnungen bei abnormalem Verhalten, etwa erhöhten Latenzzeiten. Letztlich muss aber der Anwender einer Logiccloud-Steuerung eine Risikoanalyse bezogen auf den zu steuernden technischen Prozess durchführen und seine Anforderungen an diesen definieren.
Logiccloud wird im Laufe des Jahres 2022 zu einem vollständigen Steuerungsprodukt ausgebaut und ab Ende 2022 für erste industrielle Anwender zur Verfügung stehen. Interessierte können sich über den Stand der Arbeiten auf den logiccloud.com-Webseiten informieren.
Kontakt:
Logiccloud AG
Am Weinberg 16
74722 Buchen
Tel: +496281 56 24 781
info@logiccloud.de
logiccloud.com
