Welche Rolle spielt Codesys bei der Integration von Echtzeit-Anforderungen in moderne SPS-Systeme, besonders im Kontext von virtualisierten Steuerungen?
Roland Wagner: Wir sind Hersteller von Steuerungstechnik, kein Anbieter von virtualisierten Echtzeit-Lösungen. Daher ist es nicht unsere Kernaufgabe, ein Linux-System mit Echtzeiteigenschaften aufzusetzen – auch wenn wir beratend zur Seite stehen. Maschinenbauer sollten sich primär an Echtzeit-Software-Spezialisten wenden. Wir arbeiten z.B. mit Acontis zusammen und sind mit RedHat im Austausch. Zukünftig möchten wir mit Firmen, die ein Echtzeit-Betriebssystem betreuen, Bundles mit unserer Runtime anbieten.
Welche Herausforderungen gibt es denn bei der Migration von einer SPS zu virtuellen Steuerungen?
Auf Applikationsebene stellt sich eine virtuelle Steuerung für einen SPS-Programmierer, wie eine physische Steuerung dar. Er muss lediglich die Device Description je nachdem auswählen, auf welcher Plattform das Programm laufen soll. Anders sieht es für denjenigen aus, der die Steuerungstechnik einbaut und die Steuerungsarchitektur betreibt. Statt in Hardware zu denken, muss man nun ein leistungsfähiges System auf einem Betriebssystem mit Containerisierung einrichten, beispielsweise Debian Linux mit Dockier oder Red Hat Enterprise Linux mit Podman. Der Fokus verschiebt sich auf IT-Aufgaben sowie auf die Integration von Echtzeit und Work-load in einer virtualisierten Umgebung.
Was sind denn technische Basisvoraussetzungen?
Im Prinzip kann Codesys Virtual Control auf jeder Linux-Distribution mit Container-Technologie laufen. Wir arbeiten viel mit den Standard-Debian-Linux-Systemen und davon abgeleiteten Systemen wie Ubuntu oder Red Hat Enterprise Linux. Der Echtzeit-Patch ist mittlerweile im Standardkernel enthalten, was die Installation vereinfacht. Hardwareseitig entscheiden CPU-Leistung und Kernanzahl über die Kapazität. Wir unterstützen sowohl x86- als auch ARM-Systeme, wobei wir mit x86 die meiste Erfahrung haben.
Was ist denn der Unterschied zwischen virtueller SPS, Soft-SPS und klassischer SPS? Lediglich die Hardwareunabhängigkeit?
Die Programmierung ist bei allen Ausführungen die gleiche. Neben allen Programmiersprachen und Sprachmodellen sind auch die Debugging-Funktionen identisch. Das Laufzeitsystem, also die Kern-Software, die den SPS-Code ausführt, wird dann entweder auf ein dediziertes Hardware-Gerät, auf eine dedizierte Einsatzumgebung mit einem speziellen Prozessor und Betriebssystem oder eine standardisierte Linux- oder Windows-Umgebung angepasst. Der Hauptunterschied ist also die IT-Einbindung und die praktische Verwendung der Steuerungstechnik im Feld. Eine virtuelle SPS kann auf einem beliebigen PC in einem Schaltschrank laufen – muss aber nicht. Unser Pilotkunde Audi nutzt dafür beispielsweise Server aus dem IT-Bereich. Darauf lassen sich mehrere virtuelle SPSen aufsetzen, ohne sie physisch einbauen zu müssen. Das reduziert den Platzbedarf sowie den Wartungsaufwand. Es gibt wesentlich weniger Störungen bei der Verkabelung und der Hardware.
Wo macht denn dann eine klassische SPS überhaupt noch Sinn?
Für kleine, kompakte Maschinen mit einer einzigen Steuerung ist die klassische SPS oft die beste Wahl. Bei komplexeren Systemen können dagegen virtuelle Lösungen vorteilhaft sein. Die Entscheidung hängt vom Einzelfall ab und muss sorgfältig durchgerechnet werden, wobei Faktoren wie Verkabelungsaufwand und Flexibilität gegen den Mehraufwand für die Echtzeitumgebung abgewogen werden müssen. Ich bin überzeugt, dass die klassische SPS nicht verschwinden wird, aber virtuelle Lösungen zunehmend an Bedeutung gewinnen werden.
Neben der virtuellen SPS bietet ihr jetzt auch eine virtuelle Safety SPS an. Was zeichnet diese aus?
Unsere Anfang Januar vom TÜV Süd zertifizierte Codesys Virtual Safe Control ist hardwareunabhängig und erreicht SIL3 nach IEC61508. Sie kommt bereits als Prototyp zum Einsatz. Aktuell sind wir noch auf x86-basierte Systeme mit Profisafe beschränkt, aber das wird sich bald ändern. Damit erfordert die Safety-Applikation nicht mehr zwei unabhängige Hardwarekanäle. Stattdessen nutzen wir die Coded-Processing-Technologie von Silistra Systems, um zwei unabhängige Softwarekanäle zu erzeugen. Dies ermöglicht Sicherheitsfunktionen auf Standard-Hardware, reduziert den Hardwareaufwand und erhöht die Flexibilität. Der Zyklus dauert zwar etwas länger, aber bestimmte Vergleichsfunktionen lassen sich nun per Software einfacher durchführen. Anwender können theoretisch einen Standard-PC verwenden und die Software darauf installieren. Wie bei klassischen Sicherheitssteuerungen ist Codesys Virtual Safe Control vorzertifiziert, sodass nur noch die Applikation selbst zertifiziert werden muss.
Erster Anwender von Virtual Control sowie von Virtual Safe Control ist Audi. Was sind die ersten Erfahrungen aus der Pilotphase?
Dr. Malte Sommer, der das Projekt seitens Audi koordiniert, war sehr zufrieden. Schon früh in der Pilotphase konnten wir prototypisch zeigen, dass das System funktioniert. Wir waren in der Lage, Prototypen mit der Steuerung zu produzieren und die dedizierte Steuerung zu ersetzen. Im ersten Halbjahr 2025 sollen die ersten richtigen Produktionsanlagen für echte Fahrzeugteile mit Virtual Control in Betrieb gehen. Übrigens zeigen wir am 9. April auf dem Automatisierungstreff in Heilbronn in einem Workshop, wie sich Codesys Virtual Control bedienen und programmieren lässt.
Wurden die virtuellen Codesys-Steuerungen denn nach den ersten Erfahrungen noch angepasst?
Natürlich haben wir Kleinigkeiten verbessert, wie zum Beispiel den Prozess, wie man das Image der virtuellen Steuerung auf den Rechner bringt. Diese Optimierungsphase wird weitergehen. Wir arbeiten daran, die Inbetriebnahme zu vereinfachen. Auch bezüglich der Lizenzierung der Softwaresysteme haben wir noch einige Ideen.
Ein weiteres großes Trendthema ist KI. Welche Möglichkeiten bietet Codesys zur Integration von Datenanalyse sowie von KI-Funktionen?
Schon lange bieten wir Kommunikationsmöglichkeiten zur Anbindung an KI-Funktionen in der Cloud, zum Beispiel, um klassische Predictive Maintenance durchzuführen. Zudem wollen wir demnächst eine erste KI-Anwendung für den produktiven Betrieb freischalten: unsere Online-Hilfe. Dabei können User in Klartext mit einer KI-Engine kommunizieren. Es gibt auch erste Ansätze am Markt, bei denen KI bei der Programmierung unterstützt. Wir selbst bieten so etwas zwar noch nicht an, stehen aber diesbezüglich in engem Kontakt mit Technologiefirmen wie Intel. Allerdings sind nur wenige KI bisher mit genügend guten Daten trainiert, um vernünftige Ergebnisse zu liefern. Je kleiner und überschaubarer die Aufgabe ist, umso größer ist der Nutzen. Die Vorstellung, sich ein komplettes Applikationsprogramm von einer KI schreiben zu lassen und es ungeprüft zu verwenden, halte ich für die nächsten Jahre noch für utopisch. Eine KI ist im Prinzip ein Werkzeugkasten. Man muss das richtige Werkzeug auswählen und es entsprechend verwenden. Wie bei KI-generierten Grafiken, die manchmal anatomische Fehler aufweisen, ist eine sorgfältige menschliche Überprüfung der Ergebnisse unerlässlich.
Am 09. April findet im Rahmen des Automatisierungstreffs in Heilbronn von 10:30 bis 16:00 Uhr ein Workshop zur Bedienung und Programmierung von Codesys Virtual Control statt. Die Teilnehmer erhalten praxisnahe Einblicke in die Virtualisierung von Codesys-Steuerungen, von der Installation bis zur Projektierung. Der Workshop umfasst auch die Themen Safety-Steuerungen und die Nutzung eigener Hardware. Die Teilnehmer haben die Möglichkeit, auf bereitgestellter x86- und ARM-basierter Hardware ihre eigenen virtuellen Codesys-Steuerungen zu installieren, zu konfigurieren, in Betrieb zu nehmen und zu projektieren. Es wird demonstriert, wie selbst Safety-Steuerungen virtualisiert werden können, wodurch sie unabhängig von speziellen Hardwareplattformen werden. Jeder Teilnehmer erhält eine kostenlose Codesys-Lizenz, um die virtuelle Steuerung auch nach dem Workshop weiter nutzen zu können.
