Jeder kennt virtuelle Laufwerke und sogar virtualisierte Computer. Diese Abbilder von physikalischen Geräten, in diesem Fall z.B. 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 und voneinander unabhängige Konfigurationen für unterschiedliche Anwender bzw. 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.
Deployment bzw. Orchestrierung
Liegt die Konfigurationsdatei vor, so können daraus beliebige viele virtuelle Steuerungen angelegt und 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 gibt. Diese Funktionen lassen sich auch als Skripte zusammenfassen und somit 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 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. Das ist kein ‚Bug‘, sondern ein 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. 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.
- Hardware-spezifische Eigenschaften müssen generisch angesprochen werden, 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 gleichgültig, für welche Steuerung gerade programmiert bzw. 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 z.B. 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.
Typische Anwendungsfälle für virtuelle Steuerungen
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 8ms-Zyklus und einem Jitter unter 50µs. 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 z.B. 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 bestmöglich vorbereitet. Ein teurer und vor allem risikoreicher Umstieg auf verteilte Steuerungskonzepte, z.B. durch IEC61499-Systeme, ist dadruch überflüssig geworden.
Nutzen bei Lieferproblemen
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 bzw. 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 ganz flexibel heute so und morgen so.