Software takes the lead

Software löst in der Automatisierungstechnik zunehmend die Bedeutung von Hardware ab. Beispiele: Schalter und Taster werden zwar nach wie vor eingesetzt, jedoch werden heute die meisten industriellen Bedienoberflächen auf Touchdisplays mit Visualisierungssoftware realisiert. ‚Dumme‘ Frequenzumrichter zur Ansteuerung von AC-Motoren werden heute genauso wenig eingesetzt wie analoge Schnittstellen für die Geschwindigkeitsvorgabe. Und dass Funktionen einer Maschine in Elektronik oder gar mechanischen Einheiten ‚fest gecodet‘ sind, ist lange vorbei. Dennoch war es bislang immer die Hardware, die verkauft und verbaut wird.

Mit virtuellen Steuerungen bekommt die Software jetzt endgültig das Übergewicht. Zu deren Ausführung brauchen wir zwar nach wie vor physische Geräte – im Gegensatz zu ‚normalen‘ SPS ist die Hardware jetzt aber abstrahiert. Die Runtime-Software, die die Steuerungsfunktionen ausführt, muss gar nicht mehr wissen, auf welchem Gerät sie läuft. So sind einerseits dedizierte Industriesteuerungen einsetzbar – meist multifunktionale Plattformen mit Linux als Betriebssystem. Andererseits können aber auch Industrie-PCs oder Edge-Computing-Plattformen genutzt werden. Oder sogar IT-Serverplattformen – ob lokal ausgeführt oder in einem Rechenzentrum. Entscheidend ist die Abstraktion der Hardware durch Container oder Hypervisor. Darauf wird die virtuelle Steuerung ‚deployed‘ beziehungsweise per OT- oder IT-Tools orchestriert. Bei Bedarf lassen sich mehrere Instanzen parallel für unterschiedliche Steuerungsaufgaben anlegen, um Applikationen feingranular als Microservices aufzuteilen. E/A-Geräte und die daran angeschlossenen physikalischen Sensoren und Aktoren sind jedoch weiterhin erforderlich. Sie werden per Feldbussysteme über physikalische oder virtuelle LAN-Ports angesprochen. Während das Echtzeitverhalten in reinen IT-Systemen eine untergeordnete Rolle spielt, ist es für Automatisierungssysteme ein ‚Musthave‘. Aber auch dafür gibt es mit dem Preempt_RT-Echtzeitpatch eine etablierte Lösung, die mittlerweile Teil des Linux-Kernels ist. Ein damit ausgestattetes und für den Echtzeitbetrieb optimiertes System vererbt den virtuellen Steuerungen das Echtzeitverhalten beim Deployment.

Welche Vorteile bringen virtuelle Steuerungen? Zunächst einmal reduzieren sie ganz erheblich den Aufwand für Beschaffung, Verdrahtung, Instandhaltung, Ausrollen von Applikationen sowie für die Administration der Geräte. Der Schaltschrank als teuerster Platz in einer Maschine muss nicht mehr zwingend von einer oder mehreren Steuerungen belegt werden. Ebenso entfallen Netzteile und deren Verdrahtung. Statt viele Einzelgeräte zu beschaffen, zu montieren und zu warten, genügt es, eine verfügbare Edge- oder IT-Plattform im Netzwerk mit virtuellen Steuerungen zu bespielen und diese zentral zu verwalten. Und nachdem IT und OT dabei Hand in Hand zusammenarbeiten, können viele Aufgaben jetzt von IT-Spezialisten übernommen werden. Automatisierer können sich voll und ganz auf ihr Fachgebiet konzentrieren.

Anwendung virtueller Steuerungen – ganz praktisch

Im marktführenden, von Geräteherstellern unabhängigen IEC-61131-3-System Codesys lassen sich virtuelle Steuerungen recht einfach nutzen. Erforderliche Images findet man online zum Download. Sie werden im Codesys Development System als Package installiert. Für alles Weitere ist eine SSH-Verbindung zum Zielsystem erforderlich. Im sogenannten Deploy Tool gibt man dafür die entsprechenden Zugangsdaten ein, baut die Verbindung auf und installiert das oder die gewünschten Images. Jede Container-Instanz lässt sich mit individuellen Eigenschaften konfigurieren, um die virtuelle Steuerung bedarfsgemäß aufzusetzen. Die Bedienung erfolgt direkt in dieser Oberfläche.

Daneben gibt es weitere Möglichkeiten, um virtuelle Steuerungen auf dem Zielsystem bereitzustellen und zu verwalten:
Systemadministratoren haben durch manuelle Ausführung von Funktionen des Betriebssystems beziehungsweise der Virtualisierungsplattform die volle Freiheit beim Deployment, beispielsweise auf Docker- oder Podman-Containern. Die Funktionen lassen sich durch Skripte zusammenfassen und somit erheblich vereinfachen.

Generische Softwareplattformen wie Kubernetes oder Open Shift ermöglichen eine automatisierte Konfiguration, Verwaltung und Koordinierung von Computersystemen, Anwendungen und Services. Durch sogenannte Helm Charts auf Basis von *.yaml-Dateien lassen sich insbesondere komplexe Konfigurationen einfach verwalten.

Proprietäre Plattformen mit Zusatznutzen für die tägliche Arbeit in der Automatisierungstechnik wie der Codesys Automation Server ermöglichen ein komfortables Management virtueller Steuerungen.

Im SPS-Programmiersystem nutzt man die so erzeugten Steuerungen genauso wie jede dedizierte, physikalisch verfügbare SPS. Das heißt: Sobald die gewünschte Gerätebeschreibung in einem SPS-Projekt eingestellt ist, können User nach geeigneten Systemen im Netzwerk suchen. Dazu nutzen sie eine Container-Instanz mit installiertem Gateway auf dem Zielsystem, denn die Container werden nach außen abgekapselt. Das bedeutet im Fall von Codesys: Das lokale Gateway als Kommunikationsdienst zwischen Projektierungs-PC und der SPS findet alle im Netzwerk befindlichen Steuerungen, nicht aber die virtuellen Steuerungen. Somit ist ein unerwünschter beziehungsweise unautorisierter Zugriff von vornherein ausgeschlossen. Auf dem Projektierungs-PC wird statt des lokalen dann eben dieses Remote Gateway für den Zugriff auf die Zielsystemplattform ausgewählt. Mit der Gerätesuche werden somit alle verfügbaren virtuellen Steuerungen im Zielsystem gefunden – und nur dort. Wurden in der Konfiguration Ethernet Ports mit physikalisch verfügbaren oder virtuellen Ports im Netzwerk verbunden, so lassen sie sich im Codesys-Projekt einbinden und etwa als Ethercat, Profinet oder Ethernet/IP konfigurieren und verwenden. Der Container schleift diese virtuellen Ports problemlos durch und sorgt für die deterministische Ausführung der Buszyklen – genau wie bei einer ‚echten‘ SPS.

Wie sieht es mit Sicherheitssteuerungen aus?

Zur Steuerung potenziell gefährlicher Maschinen und Anlagen fordern EU-Verordnungen und nationale Gesetze zum Schutz des Menschen, dass Maschinen mit Gefährdungspotenzial für den gesamten Lebenszyklus abgesichert sein müssen – entweder durch konstruktive Maßnahmen oder sichere Steuerungstechnik. Gemäß dem Stand der Technik, unter anderem definiert in der IEC 61508, müssen Sicherheitsanforderungsstufen ‚SIL‘ (Safety Integrity Level) zwischen 1 und 4 erreicht werden. Diese Stufen basieren auf der Gefährdungslage, die unter anderem von der Schwere und Expositionshäufigkeit abhängt. Hersteller von Maschinen oder Anlagen mit Gefährdungspotenzial sind aufgrund der Gesetzeslage verpflichtet, ihre Systeme durch ein akkreditiertes Institut freigeben zu lassen – inklusive aller eingesetzten Komponenten für die Erreichung der Anforderungsstufe sowie der implementierten Steuerungsapplikation.

Um Systemfehler ausschließen zu können, müssen Steuerungen für SIL3-Anwendungen in industriellen Maschinen und Anlagen zweikanalig aufgebaut sein. Bislang bedeutete das: Zwei unabhängige Hardwarekanäle führen die Sicherheitsfunktionen aus und überwachen sich gegenseitig. Das geht natürlich nicht, wenn die Hardware durch Virtualisierung abstrahiert wird. Dennoch ist Zweikanaligkeit möglich: ‚Coded Processing‘ zusammen mit ‚Diversified Encoding‘ ermöglicht eine Aufteilung der Sicherheitssoftware in zwei unabhängige Softwarekanäle. Durch redundante Betrachtung der Steuerungsinformationen erkennt dieses Verfahren Fehler im Daten- und Kontrollfluss von Programmen, und zwar ohne besondere Anforderungen an die darunterliegende Hardware. Ausgeführt wird die realisierte Sicherheitsapplikation im ersten Kanal im Original, im zweiten Kanal in transformierter Form. So können bereits Fehler erkannt werden. Beide Kanäle laufen in einem Prozess hintereinander auf einem CPU-Kern. Sie werden permanent verglichen, wie das auch bei Hardwarelösungen zur funktionalen Sicherheit gemacht wird. Durch Diversified Encoding werden auf dieselbe Weise die sicheren Eingaben an beide Kanäle verteilt und umgekehrt die Ausgaben beider Kanäle zu sicheren Ausgaben zusammengeführt. Eingeschlossen sind Datenströme, die durch sichere Netzwerk- beziehungsweise Feldbusprotokolle erzeugt wurden. Ein weiteres Sicherheitskriterium ist eine feingranulare Überwachung des Kontrollflusses im kodierten Kanal, die zur Laufzeit der Sicherheitsapplikation durchgeführt wird. Das in Kooperation mit der Firma Silistra Systems GmbH erstellte Sicherheitskonzept wurde vom TÜV Süd abgenommen und Anfang 2025 für Anwendungen nach IEC 61508 SIL3 zertifiziert – und das ausdrücklich unabhängig von darunterliegenden Hardwarekomponenten. Zur Projektierung von Sicherheitsapplikationen benötigt man wie mit dedizierten Geräten ein zertifiziertes Add-on-Package für das Entwicklungssystem.

Beim Deployen ihrer Steuerungen auf dem Zielsystem entscheiden Codesys-Anwender und -Anwenderinnen, ob funktional sichere Applikationen ablau-
fen sollen. Dass es sich dabei um virtualisierte Geräte handelt, merken sie bei der späteren Projektierung nur bei der Konfiguration der Safety-E/A-Module in der Applikation.

Motion-, CNC- und Robotik-Anwendungen

Früher wurden koordinierte Verfahrbewegungen immer über dedizierte Controller, also spezifische Hardware, gesteuert. Einen Sonderfall stellen Robotiksysteme dar, die durch die SPS kommandiert werden können. Die Berechnung der Bewegungskoordinaten erfolgt dabei in der speziellen Robotiksteuerung, zu deren Projektierung jedoch keine speziellen Programmiersprachen wie Karel oder Rapid benötigt werden. Die SPS schickt Kommandos über Standard-Feldbussysteme wie Profinet an die Robotersteuerung, die für die gewünschte Bewegung sorgen. Mit dem Standard Robot Command Interface (SRCI) etabliert sich gerade ein übergreifender Standard dafür. Er enthält einen Satz aus 115 Befehlen beispielsweise für lineare Bewegungen bis hin zu komplexeren Befehlen wie Kraftsteuerung. In diesem Sonderfall spielt es keine Rolle, ob die SPS-Applikation auf einem Edge Device in der Nähe des Roboters oder remote in einem Serverraum ausgeführt wird.

Abseits dieses Sonderfalls ermöglicht die Rechenleistung moderner Systeme heute Einsparungen bei Hardware und Aufwand, indem die Anfahrpunkte der Antriebe mit ihren Dynamiken ebenfalls in der SPS per Software berechnet und per Feldbus übertragen werden. Gerade die Leistungsreserven von IPCs oder Servern mit mehreren CPU-Kernen als Zielsystem für virtuelle Steuerungen bieten meist mehr als ausreichend Kapazität dafür. So kann man einfach von einer virtuellen Logiksteuerung zu einem virtuellen Motion Controller ‚aufrüsten‘: Den Unterschied macht letztlich nur die Lizenz, die bei Bedarf die Nutzung von komplexen Achsgruppen und die zugehörigen aufgerufenen Bibliotheksbausteine freischaltet. Sie ist mit wenigen Klicks aufgespielt und vollzieht das Upgrade. Das ist bei physikalischen Geräten in vielen Fällen schlicht undenkbar – ein klarer Pluspunkt für virtuelle Steuerungssysteme! Entscheidend ist die Echtzeitkommunikation der Software mit den Antrieben über Feldbusse wie Ethercat. Sie ist durch das Protokoll auch für lange Distanzen bis maximal 100 m gewährleistet. Wird die virtuelle Steuerung noch weiter abseits der Motionanwendung betrieben, so kann man Lichtwellenleiter (LWL) einsetzen. Benötigt die virtuelle Steuerung darüber hinaus Daten von weiteren Feldbusprotokollen, so kann man alle Kommunikationsdaten in speziellen FPGAs zusammenfassen und gebündelt über den LWL verschicken. Genauso, wie das der Ansatz der Firma Missing Link Electronics unter dem Arbeitstitel ‚Robo/TSN‘ verspricht.

Fazit

Weiterhin ist natürlich Hardware erforderlich, um moderne Automatisierungssysteme zu steuern. Aber nicht zuletzt durch den Einsatz von virtuellen Steuerungen wird klar, dass es die Software ist, die Funktion, Komfort und Mehrwehrt definiert. Die Virtualisierung von Steuerungen befreit von der Abhängigkeit von spezifischer Hardware. Weitere Vorteile wurden eingangs genannt. Eine Softwareplattform wie Codesys bietet dafür alle erforderlichen Komponenten: virtuelle Steuerung, virtuelle Safety-SPS, aber auch Feldbusprotokolle, Motion Control und Visualisierung. Damit übernimmt die Software endgültig die Führung bei der Industrieautomation.