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? Logiccloud will dies ermöglichen: Das Buchener Unternehmen arbeitet an der Umsetzung des Technologiekonzepts in ein marktreifes Produkt.

Die Digitalisierung der Produktion wirkt sich auch massiv auf die Automatisierungstechnik aus. Vor allem die Nutzung von Cloud Computing und die Anwendung des Service-Paradigmas wird die zugrundeliegende Technologie stark verändern. Klassische Automatisierungssysteme, die nach den bekannten Hierarchieebenen der Produktionsautomatisierung nach ANSI/ISA-95 aufgebaut sind, werden den neuen Anforderungen nicht gerecht.

Betrachtet man die Anforderungen von ubiquitärer Vernetzung, Cloud Computing und Service-Paradigma, so kristallisiert sich heraus, dass besonders das Automatisierungsmodell auf Basis von Cyber-Physical Systems (CPS) mit den Anforderungen weitgehend übereinstimmt (Abb. 1). 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 nach Abb. 1 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 Automatisierungsumgebung auf Cloud-Basis liegen noch nicht vor. Wie könnte nun ein Konzept für eine skalierbare und sichere SPS aus der Cloud mit dynamischen Ressourcenpools aussehen - eine SPS, die wichtige Steuerungsfunktionen nach IEC 61131-3 unter unkritischen Echtzeitbedingungen (über 50 ms) realisieren kann?

Das Konzept einer SPS aus der Cloud geht unter dem Aspekt von Industrie 4.0 und IIoT grundsätzlich davon aus, dass Webtechnologien die technische Basis bilden. Im Internet (Web) 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, und 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 meist ein Webbrowser im Client-Rechner. Dies kann aber auch eine andere Client-Komponente sein.

Betrachtet man ein beliebiges anwendungsspezifisches Funktionssystem, etwa ein Leitsystem, das mit Webtechnologie realisiert wird, so ergeben sich die in Abb. 2 dargestellten Modelle für die Ausführung (RUN) dieses Systems:

a) Das funktionale System ist nur im Server gespeichert und wird auch nur dort ausgeführt. Die Ausführung des Systems auf dem Server startet der Client (Servermodus). b) Das funktionale System ist im Server gespeichert und wird über eine Anfrage in den Client geladen. Das System wird nur im Client-Modus ausgeführt (Client-Mode). c) Das funktionale System ist im Server gespeichert, und Komponenten des funktionalen Systems werden ebenfalls im 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 der Servermodus eine besondere Rolle, weil hierfür bereits verschiedene Werkzeuge im Webbereich - etwa Containertechnologien - existieren. Das Konzept der Logiccloud baut daher auf dieser Grundstruktur auf. Daraus ergibt sich die in Abb. 3 dargestellte grundlegende Komponentenstruktur einer SPS aus der Cloud:

Im Server (Cloud) befinden sich n 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 nach dem Modell gemäß Abb. 1 aufgebaut und enthalten einen entsprechenden IP-Connector oder ein Gateway zur Kommunikation mit der Steuerungsinstanz. Verwaltung und Bedienung der Steuerungsinstanzen erfolgen über den Webbrowser (Client).

Das grundsätzliche Problem für eine praktikable und industrietaugliche Umsetzung der Struktur nach Abb. 3 ist nun, eine Möglichkeit zu schaffen, dass tatsächlich n Steuerungsinstanzen mit m Automatisierungsgeräten und p 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. Abb. 4 zeigt die im Projekt entwickelte und auf der Struktur nach Abb. 3 beruhende Backend-Architektur für eine SPS aus der Cloud, die unter der Bezeichnung Logiccloud gerade in eine marktreife Variante weiterentwickelt wird.

Die Architektur besteht aus fünf Hauptkomponenten:

- Die Systemadministration: Sie umfasst das Identity & Access Management, das Device & Location Management und alle Funktionen für die Abrechnung auf Service-Basis. - Runtimes: Die Komponente Runtimes enthält alle Dienste, die zur Laufzeit in Logiccloud Verwendung finden, wie SPS-Laufzeitlogik, I/O-Laufzeit und I/O-Konnektoren. - Library Services: Diese Komponente stellt Dienste zur Verfügung, die in den Design- und Laufzeitprozessen genutzt werden, wie den IEC-61131-3-Programmcompiler oder das Funktionsbibliotheks-Management. - 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 beiden Komponenten Runtimes und Library Services bestimmen im Wesentlichen die Eigenschaften der SPS-Steuerungsinstanzen.

In einer Automatisierungsarchitektur auf Cloud-Basis - 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 vor allem die in Abb. 5 dargestellten Subsysteme.

Das Subsystem PLC Runtime ist für die Abarbeitung des IEC-61131-3-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 in Abb. 6 dargestellten Library Services sind ebenfalls eine wichtige Komponente für die Logiccloud-SPS. Die Kernelemente der Library Services sind die SPS-Programmcompiler für verschiedene IEC-61131-3-Programmiersprachen und 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-Runtime und ein Logiccloud-Marktplatz (Market Place Services) zur Integration von Fremdkomponenten.

Der Backend-Architektur gemäß Abb. 4 ist ein Logiccloud-Portal überlagert, das der Anwender als Anwendungsumgebung (Frontend) für Engineering, Management und Betrieb nutzen kann.

Das Logiccloud-Konzept beruht auf aktuellen Webtechnologien. Hierzu 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 sowie HTML5 und Responsive Design für das Frontend-Portal. Darüber hinaus nutzt die Implementierung verschiedene Open-Source-Tools wie Keycloak für die Systemsicherheit sowie Grafana und Prometheus für Analytics, Logging und Metriken. Alle Funktionen im Logiccloud-System sind als Microservices implementiert und lassen sich flexibel erweitern.

Das Logiccloud-Portal ermöglicht die Erstellung von SPS-Projekten und Steuerungsprogrammen in den IEC-61131-3-Sprachen Strukturierter Text (ST), Kontaktplan (KOP), Ablaufsprache (AS) und Funktionsbausteinsprache (FBS) im Rahmen einer integrierten Entwicklungsumgebung (PLC IDE). Abb. 7 zeigt die PLC IDE für ein Steuerungsprogramm in ST.

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 Zugriffskontrolle auf Rollen- und Berechtigungsbasis, verschlüsselte Kommunikation sowie Laufzeitisolierung innerhalb des Kubernetes-Clusters. Integriert ist ferner eine automatische Anomalie-Erkennung, mit der sich eine große Anzahl von Angriffen auf die Plattform identifizieren und verhindern lässt.

Um die Zuverlässigkeit der laufenden SPS-Instanzen sicherzustellen, stehen eine Reihe von Maßnahmen bereit. Hierzu 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 sowie 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 ihnen über das Netzwerk - Intranet oder Internet - zuverlässig verbunden sein. Netzwerkverbindungsprobleme kann das Logiccloud-System nicht abfangen, aber es sind einige Gegenmaßnahmen vorgesehen, die vor allem die Maschinensicherheit gewährleisten sollen. Etwa die vorgesehene Verwendung redundanter oder hybrider Netzwerkverbindungen mit schnellem Failover, die Verlagerung der SPS-Instanzen vor Ort an die Edge, die Einführung von Watchdog- und Ping-Signalen zur Erkennung von Stromausfällen sowie das Generieren von Warnungen bei anomalem Verhalten wie längeren Latenzzeiten.

Letztlich muss aber der Anwender einer Logiccloud-Steuerung eine Risikoanalyse bezogen auf den zu steuernden technischen Prozess durchführen und seine Anforderungen an ihn 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 der Website https://logiccloud.com informieren.

Die Wurzeln von Logiccloud gehen auf ein Forschungsprojekt von Prof. Reinhard Langmann an der Hochschule Düsseldorf aus dem Jahr 2014 zurück. Das Projekt widmete sich dem Ansatz einer virtualisierten SPS in der Cloud. An dem Projekt beteiligt war auch der ZVEI, dem Bernhard Böhrer, damaliger Geschäftsführer und Gesellschafter der Firma WEBfactory, als Vorstand der Forschungsgemeinschaft Automation angehörte.

Bernhard Böhrer verfolgte die Idee der virtualisierten SPS weiter und gründete 2021 die Logiccloud AG, der er seither als CEO vorsteht. Aktuell besteht das Unternehmen aus sechs Mitarbeitern mit vielen Jahren Erfahrung in der Automatisierung und Softwareentwicklung.

Ziel des jungen Unternehmens ist, mit Logiccloud eine Cloudplattform für industrielle Steuerungen, die „SPS aus der Cloud“, bereitzustellen. Der Markteintritt mit einem serienreifen Produkt ist für November 2022 geplant.

Erhöhen Sie Ihre Sichtbarkeit, indem Sie Ihr Unternehmen in Artikeln dazu anzeigen! Buchen Sie noch heute Ihren Firmeneintrag!

© 2022 WEKA FACHMEDIEN GmbH. Alle Rechte vorbehalten.