Startseite » Steuerungstechnik »

Was steckt hinter virtuellen Steuerungen?

Industriesteuerungen – Teil 2
Was steckt hinter virtuellen Steuerungen?

Im ersten Teil dieses Beitrags mit dem Titel ‚Der Weg zur Steuerungstechnik 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. Der hier vorliegende Teil 2 erläutert, wie solche virtuellen Steuerungen in der Praxis aussehen und wie sie sich verwenden lassen – jeweils auf Basis der IEC-61131-3-Plattform Codesys.

Dipl.-Ing. (FH) Roland Wagner, Head of Product Marketing, Codesys GmbH, Kempten

Inhaltsverzeichnis

1. Deployment beziehungsweise Orchestrierung
2. Typische Anwendungsfälle für virtuelle Steuerungen
3. Virtuelle Steuerungen bei Lieferproblemen nutzen

Jeder kennt virtuelle Laufwerke und sogar virtualisierte Computer. Diese Abbilder von physikalischen Geräten, in diesem Fall zum Beispiel 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, diese Aufgabe zu übernehmen. In der IT sind solche Virtualisierungen nützlich, um

  • die Datensicherheit von Systemen durch sinnvolle Grenzen des Zugriffs zu erhöhen und um
  • voneinander unabhängige Konfigurationen für unterschiedliche Anwender beziehungsweise 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 beziehungsweise Konfigurationsdateien – inklusive der entsprechenden Konfiguration für die SoftSPS, wie etwa 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 hochperformant möglich! Das bedeutet: Durch eine bessere Abgrenzung der Prozesse und durch die Hardware-Unterstützung können sogar bessere Echtzeitwerte erzielt werden als mit SoftSPSen, die nativ auf dem Host-System laufen!

Container-Konfigurationsinformation_für_eine_virtuelle_Codesys-SPS
Abb. 1: Container-Konfigurationsinformation für eine virtuelle Codesys-SPS.
Bild: Codesys

Deployment beziehungsweise Orchestrierung

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 beziehungsweise der Virtualisierungsplattform, wie zum Beispiel 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 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 Abrechnungsmodelle (‚Plattform as a Service‘) für die so angelegten virtuellen Steuerungen einzuführen.
  • Durch proprietäre Plattformen mit Zusatznutzen für die Automatisierungstechnik, wie zum Beispiel 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.
Deployment_von_drei_virtuellen_Steuerungen_und_einem_Gateway_per_Linux-Script
Abb. 2: Deployment von drei virtuellen Steuerungen und einem Gateway per Linux-Script.
Bild: Codesys

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 beziehungsweise 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.
    Wichtig ist aber: ‚It‘s not a bug – it‘s a feature!‘ Ein unerwünschter beziehungsweise 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 auch Abb. 2). Auf dem Projektierungs-PC wird statt des lokalen dann eben dieses Remote-Gateway für den Zugriff auf die Zielsystemplattform ausgewählt – entweder über dessen IP-Adresse oder Hostname (siehe Abb. 3).
  • Hardware-spezifische Eigenschaften müssen generisch angesprochen werden, insbesondere wenn es sich um industrielle Geräte handelt, die etwa über lokale E/As verfügen. Dazu müssen diese generischen Schnittstellen getrennt vom Prozess angesprochen werden.
Auswahl_des_Gateways_im_Container_der_Basisplattform
Abb. 3: Auswahl des Gateways im Container der Basisplattform.
Bild: Codesys
Suchen_nach_geeigneten_Steuerungen_im_Codesys_Development_System
Abb. 4: Suchen nach geeigneten Steuerungen im Codesys Development System: Virtuelle SPSen lassen sich genauso finden und verwenden wie physikalisch verfügbare Geräte.
Bild: Codesys

Das war es dann 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 beziehungsweise projektiert wird. Wurden in der Konfigurationsdatei virtuelle Ethernet-Ports angelegt beziehungsweise mit physikalisch verfügbaren Ports verbunden, so lassen sie sich auch im Codesys-Projekt einbinden und zum Beispiel als Ethercat, Profinet oder EtherNet/IP konfigurieren und verwenden. Der Container beziehungsweise 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 8-ms-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 zum Beispiel im Hinblick auf die Spannungsversorgung und Verdrahtung sowie eine zentrale Wartung, in diesem Fall durch IT-Spezialisten anstelle von Automatisierern. 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 kommt.
  • Use Case 2 – Aufteilung der Applikation: In einer zweiten Applikation hat das Unternehmen 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, zum Beispiel durch IEC-61499-Systeme, ist vollkommen überflüssig.

Virtuelle Steuerungen bei Lieferproblemen nutzen

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 beziehungsweise 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!

Wichtig ist: Die Steuerungsfunktion wird dort abgearbeitet, wo entsprechende 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. Wenn das nicht bereits ein Mehrwert für sich ist!

Darüber hinaus lässt sich diese Hardware-Abstraktion für einen weitere interessanten Anwendungsfall nutzen. Mehr dazu in Teil 3 dieses Beitrags. (co)

codesys.com

Teil 1 dieses Beitrags mit dem Titel ‚Der Weg zur Steuerungstechnik 5.0‘ findet sich hier

Der Weg zur Steuerungstechnik 5.0

 



Hier finden Sie mehr über:
Systems Engineering im Fokus

Ingenieure bei der Teambesprechung

Mechanik, Elektrik und Software im Griff

Video

Im Gespräch mit mayr Antriebstechnik...

Aktuelle Ausgabe
Titelbild KEM Konstruktion Entwicklung Management 12
Ausgabe
12.2022
LESEN
ABO
Newsletter

Abonnieren Sie unseren Newsletter

Jetzt unseren Newsletter abonnieren

Webinare & Webcasts
Webinare

Technisches Wissen aus erster Hand

Whitepaper
Whitepaper

Hier finden Sie aktuelle Whitepaper

Top-Thema Spannvorrichtungen

Spannvorrichtungen

Alles über Spannvorrichtungen und welches Einsparungspotenzial sie bieten


Industrie.de Infoservice
Vielen Dank für Ihre Bestellung!
Sie erhalten in Kürze eine Bestätigung per E-Mail.
Von Ihnen ausgesucht:
Weitere Informationen gewünscht?
Einfach neue Dokumente auswählen
und zuletzt Adresse eingeben.
Wie funktioniert der Industrie.de Infoservice?
Zur Hilfeseite »
Ihre Adresse:














Die Konradin Verlag Robert Kohlhammer GmbH erhebt, verarbeitet und nutzt die Daten, die der Nutzer bei der Registrierung zum Industrie.de Infoservice freiwillig zur Verfügung stellt, zum Zwecke der Erfüllung dieses Nutzungsverhältnisses. Der Nutzer erhält damit Zugang zu den Dokumenten des Industrie.de Infoservice.
AGB
datenschutz-online@konradin.de