Virtuelle SPS : Warum virtuelle Steuerungen gegen Lieferprobleme helfen

In dem Artikel Auf dem Weg zur Steuerung 5.0 wurde beschrieben, wie Industriesteuerungen durch die Nutzung moderner Technologien zunehmend abstrahiert werden und damit kompakter, flexibler und einfacher zu warten sind. Diese Entwicklung führt schließlich zur „Steuerung 5.0“, der virtuellen SPS. Wie sehen solche virtuellen Steuerungen in der Praxis aus und wie lassen sie sich verwenden? Dies erläutert der folgende Artikel anhand der marktführenden IEC-61131-3-Plattform Codesys.

Jeder kennt virtuelle Laufwerke und sogar virtualisierte Computer. Diese Abbilder von physikalischen Geräten, in diesem Fall Festplatten oder Windows-PCs, helfen uns, deren Funktion zu nutzen. Und zwar ohne, dass die Geräte tatsächlich vorhanden sind. Die Abbilder werden per Software auf Rechnerarchitekturen erzeugt, die leistungsfähig genug sind. In der IT sind solche Virtualisierungen nützlich, um die Datensicherheit von Systemen durch sinnvolle Grenzen des Zugriffs zu erhöhen, sowie voneinander unabhängige Konfigurationen für unterschiedliche Anwender und Anwendungen möglich zu machen.

Das gleiche gilt auch für virtuelle Steuerungen: Zunächst einmal ist eine leistungsfähige Hardware als Unterbau erforderlich. Auch wenn die SPS abstrahiert wird, muss sie natürlich irgendwo gehostet und ausgeführt werden. Insofern unterscheidet sich die virtuelle SPS zunächst nicht von einem Industriecomputer mit Betriebssystem und einer darauf installierten SoftSPS. Um aber auf einer Hardware solche virtuellen Steuerungen in beliebiger Anzahl und voneinander unabhängig betreiben zu können, muss noch eine weitere Abstraktion erfolgen. Dazu eignen sich Software-Container oder auch Hypervisor.

Sie trennen die Hardware und das darauf laufende Betriebssystem. Dazu definiert der Anwender vor dem Anlegen eines Containers oder einer virtuellen Maschine deren Funktionalität und Leistungsfähigkeit in Containerbeschreibungen bzw. Konfigurationsdateien – inklusive der entsprechenden Konfiguration für die SoftSPS, wie z.B. Codesys Virtual Control SL. Darüber hinaus wird festgelegt, auf welche Hardware-Ressourcen der Container zugreifen kann. Dies ist zwingend erforderlich, um von der Steuerung aus E/A-Zugriffe realisieren zu können. Insbesondere Ethernet-basierte Kommunikationsprotokolle und Feldbussysteme eignen sich sehr gut dafür. So lassen sich im Container virtuelle LAN-Ports definieren, die in der Containerbeschreibung mit physikalischen Ports verbunden sind.

Durch die hardware-unterstützte Virtualisierung ist das auf modernen Systemen hoch performant möglich. Das bedeutet: Durch eine bessere Abgrenzung der Prozesse und durch die Hardware-Unterstützung können sogar bessere Echzeitwerte erzielt werden als mit SoftSPSen, die nativ auf dem Host-System laufen.

Liegt die Konfigurationsdatei vor, so können daraus beliebige viele virtuelle Steuerungen angelegt - „deployed“ - werden. Im Gegensatz zur vorher genannten SoftSPS wird jetzt allerdings nicht eine Software installiert, sondern ein komplettes Image einer physikalischen Komponente erzeugt.

Das kann auf unterschiedliche Arten erfolgen:

• Durch die manuelle Ausführung von Funktionen des Betriebssystems bzw. der Virtualisierungsplattform, wie z.B. Docker Container – das ist eine Vorgehensweise, die vor allem Systemadministratoren volle Freiheiten beim Deployment geben. Diese Funktionen lassen sich auch als Skripte zusammenfassen und somit erheblich vereinfachen.
• Durch generische Softwareplattformen wie Kubernetes oder Open Shift, die eine automatisierte Konfiguration, Verwaltung und Koordinierung von Computersystemen, Anwendungen und Services ermöglichen, kurz Orchestrierung – sie sind als Produkte verfügbar und bieten die Möglichkeit nutzungsbasierte Abrechnungsmodellen („Plattform as a Service“) für die so angelegten virtuellen Steuerungen einzuführen.
• Durch proprietäre Plattformen mit Zusatznutzen für die Automatisierungstechnik, wie z.B. dem Codesys Automation Server – auch wenn die Funktion zum Deployment der virtuellen SPS in der Codesys eigenen Industrie-4.0-Plattform derzeit noch in der Entwicklung ist, so bietet sie sich dennoch dafür an. Denn neben dem Deployment von virtuellen Steuerungen lassen sich eine Reihe typischer Aufgaben für Automatisierer noch komfortabler ausführen.

Im SPS-Programmiersystem stellen sich die so erzeugten Steuerungen genauso dar, wie jede dedizierte, physikalisch verfügbare SPS. Das heißt: Sobald die gewünschte Gerätebeschreibung in einem SPS-Projekt eingestellt ist, kann der Anwender nach geeigneten Systemen im Netzwerk suchen.

Zwei Unterschiede zur dedizierten Steuerung gibt es jedoch:

• Durch die Einbettung der SPS in einen Container bzw. Hypervisor erfolgt auch eine Abkapselung nach außen. Das bedeutet im Fall von CODESYS: Das lokale Gateway als Kommunikationsdienst zwischen Projektierungs-PC und der SPS findet alle im Netzwerk befindlichen Steuerungen. Ist jedoch Hardware angeschlossen, auf der virtuelle SPSen per Container oder virtueller Maschine laufen, so werden diese Steuerungen nicht gefunden. „It's not a bug - it's a feature“: Ein unerwünschter bzw. unautorisierter Zugriff ist von vornherein ausgeschlossen. Erst wenn neben den Containern mit den virtuellen Steuerungen auch ein Gateway deployed wurde, wird der Zugriff ermöglicht (siehe Abbildung oben). Auf dem Projektierungs-PC wird statt des lokalen dann eben dieses Remote-Gateway für den Zugriff auf die Zielsystemplattform ausgewählt – entweder über deren IP-Adresse oder Hostname (siehe Abbildung unten).
• Hardware-spezifische Eigenschaften müssen generisch angesprochen, insbesondere wenn es sich um industrielle Geräte handelt, die z. B. über lokale E/As verfügen. Dazu müssen diese generischen Schnittstellen getrennt vom Prozess angesprochen werden.

Das war es aber auch schon mit den Unterschieden. Mit Geräte-Suche werden wie bisher alle verfügbaren virtuellen Steuerungen gefunden. Dem Codesys-Development System ist es dabei vollkommen gleichgültig, für welche Steuerung gerade programmiert oder projektiert wird. Wurden in der Konfigurationsdatei virtuelle Ethernet-Ports angelegt bzw. mit physikalisch verfügbaren Ports verbunden, so lassen sie sich auch im Codesys-Projekt einbinden und beispielsweise als EtherCAT, PROFINET oder EtherNet/IP konfigurieren und verwenden. Der Container bzw. Hypervisor schleift diese virtuellen Ports problemlos durch und sorgt für die deterministische Ausführung der Buszyklen – genauso wie bei einer „echten“ SPS.

Use Case 1: Ersetzen von dedizierten Steuerungen

In einer Demo-Anlage eines namhaften deutschen Unternehmens ersetzt ein einziger anlagennaher IT-Server mit 128 CPU-Kernen 32 herkömmliche Industriesteuerungen und kommuniziert unter Echtzeitbedingungen mit 320 Busteilnehmern. Die Applikation läuft dabei stabil über alle Steuerungsinstanzen mit einem 8 ms-Zyklus und einem Jitter unter 50 us. Die Vorteile des Anwendungsfalls liegen auf der Hand: Auch wenn die Anschaffung eines entsprechenden IT-Servers eine nicht unerhebliche Investition darstellt, so betragen die Kosten dafür nur einen Bruchteil des Gesamtvolumens der ersetzten SPSen. Hinzu kommen die vereinfachte Installation zum Beispiel im Hinblick auf die Spannungsversorgung und Verdrahtung, sowie eine zentrale Wartung, in diesem Fall durch IT-Spezialisten statt Automatisierer. So können Updates der Firmware und der SPS-Applikation für die virtuellen Steuerungen problemlos von zentraler Stelle ausgerollt werden. Und sollen aus irgendeinem Grund zusätzliche Funktionen per SPS realisiert werden, so lassen sich ganz einfach weitere virtuelle Steuerungen anlegen und einsetzen – ohne, dass es zu einer Rückwirkung mit den bereits laufenden Systemen gibt.

Use Case 2: Aufteilung der Applikation

In einer zweiten Applikation hat die Firma Voith Paper eine bestehende Applikation in mehrere logische Teile aufgetrennt und lässt auf einem IT-Server diese logischen Einheiten auf fünf prozesstechnisch isolierten Steuerungsinstanzen ausführen. Weil diese Instanzen mit anderen Diensten über definierte Schnittstellen einfach zusammenarbeiten können, werden sie zu „Microservices“, wie man sie in der IT kennt. Dadurch verfügt die Maschine über ein State-of-the-Art Security-Design, außerdem ist die Voith-Paper-Applikation jetzt flexibel anpassbar und einfach wartbar: Die einzelnen Teile der Applikation erfüllen unabhängig voneinander ihre Aufgaben, können zu- und abgeschaltet, ausgetauscht oder auch erweitert werden. Damit ist Voith Paper für alle zukünftigen Anforderungen ideal vorbereitet. Ein teurer und vor allem risikoreicher Umstieg auf verteilte Steuerungskonzepte etwa durch IEC 61499-Systeme ist vollkommen überflüssig.

Warum können nun virtuelle Steuerungen bei Lieferproblemen nützlich sein?

Ganz einfach: Weil Maschinen- und Anlagenbauer aufgrund der Abstraktion der Hardware wirklich ohne Aufwand auf andere verfügbare Plattformen umsteigen oder ausweichen können. Und dabei spielt es keine Rolle, ob diese Plattformen industriellen Anforderungen genügen. Natürlich kann das ein IPC im Schaltschrank sein - aber jetzt eben auch ein IT-Server, der in einem Serverraum in der Nähe der Anlage steht. Oder eben ganz flexibel heute so und morgen so.

Wichtig ist: Die Steuerungsfunktion wird dort abgearbeitet, wo entsprechenden Ressourcen verfügbar sind. Vorhandene Ressourcen lassen sich besser auslasten, weil sie nicht exklusiv zugeteilt, sondern flexibel nachrüstbar sind. Das schafft Freiheiten, die gerade bei den aktuellen Lieferproblemen von Steuerungshardware eine Lieferfähigkeit von Maschinen und Anlagen ermöglicht. Darüber hinaus lässt sich diese Hardware-Abstraktion für einen weitere interessanten Anwendungsfall nutzen ...