Das grundsätzliche Problem für eine praktikable und industrietaugliche Umsetzung der Struktur nach Bild 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. Bild 4 zeigt die im Projekt entwickelte und auf der Struktur nach Bild 3 basierende 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 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 finden, 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.
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 insbesondere die in Bild 5 dargestellten 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 in Bild 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 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 gemäß Bild 4 ist ein
Logiccloud-Portal überlagert, das der Anwender als Anwendungsumgebung (Frontend) für Engineering, Management und Betrieb nutzen kann.