Auf dem Weg hin zu Industrie 4.0 hat sich die Steuerungstechnik parallel weiterentwickelt. Ausgehend von Maschinen mit rein mechanischen Steuerungen über Wellen und Nocken der ersten industriellen Revolution konnten Materialaufwand und Komplexität der Steuerungstechnik später mit elektromechanischen Komponenten wie Motoren, Schütze oder Relais deutlich reduziert werden. Halbleiter und Mikroprozessoren machten den Weg frei für die SPS, wie man sie heute findet. Die Applikation kann flexibel geladen und geändert werden. Durch die Entkoppelung der Steuerung von ihrem Einsatzgebiet werden Geräte sehr vielseitig. Seit SPSen zunehmend mit Betriebssystem ausgestattet sind, ist eine weitere Abstraktion möglich: Der Einsatz eines Geräts muss nicht mehr vom Hersteller festgelegt werden, sondern flexibel nachladbare Software in Form von Apps bestimmt die Funktion und den Einsatzbereich. Konkret: Das SPS-Laufzeitsystem wird dazugeladen, wenn es eine Logik- oder Bewegungssteuerungen abarbeiten soll. Alternativ kann das Gerät z.B. auch als Umsetzer für Feldbusse dienen, oder als Bediengerät. Der Anwender bestimmt die Funktion mit der Software, die er darauf lädt.
Virtualisierung wird möglich
Nach wie vor sind die Geräte die Sonnen im System. Mit Hypervisor oder Container lässt sich die Hardware allerdings ebenfalls abstrahieren. Aber ob die Virtualisierung auf einem typischen Automatisierungsgerät mit 24VDC und Hutschienenmontage erfolgt, auf einem IPC mit integriertem Display oder auf einer beliebigen Serverplattform – für die Soft-SPS ist das nicht mehr relevant. Ist Linux mit Echtzeitkernel installiert, erben darauf aufgesetzte Container diese Eigenschaft mit. Das bedeutet: Mehrere Container können sich gleichzeitig die Hardware-Ressourcen teilen und isoliert voneinander ausführen. Ist im Container-Image ein SPS-Laufzeitsystem integriert, so wird der aufgesetzte Container sofort zur virtuellen SPS. Anwender können diese wie bisher mit einem Entwicklungssystem programmieren, z.B. dem Codesys Development System. Für sie ändert sich somit nichts bei der Projektierung der Steuerungsapplikation. Wenn ethernetbasierte I/O-Systeme wie Profinet, Ethercat oder Ethernet/IP verwendet werden, bleibt auch deren Nutzung wie gehabt. Wenn auf der unterliegenden Hardware nicht von vornherein mehrere Ethernet-Ports verbaut wurden, ist eine weitere Virtualisierung möglich: Mittels VLAN, erzeugt durch geeignete Switches, lässt sich ein Ethernet-Port in mehrere unabhängige Feldbusse aufteilen. Setzt man virtuelle Steuerungen ein, so entfällt aufgrund der Hardware-Abstraktion die Möglichkeit, sich zum Erreichen der Zweikanaligkeit für den Einsatz nach IEC61508 SIL3 auf weitere Hardware abzustützen. Stattdessen erzeugt man sie per Software mit dem sogenannten Diversified Encoding – ohne besondere Anforderungen an die darunterliegende Hardware. Die Technologie basiert auf dem bekannten Coded Processing. Durch eine redundante Betrachtung der Steuerungsinformationen erkennt dieses Verfahren Fehler im Daten- und Kontrollfluss von Programmen. Es teilt die Abarbeitung der Applikationssoftware in zwei logische Softwarekanäle auf: Der erste führt die realisierte Sicherheitsapplikation im Original aus. Der zweite nutzt dieselbe Applikation, führt sie aber mit den Algorithmen des Coded Processing aus und kann so bereits Fehler erkennen. Beide Kanäle laufen in einem Prozess sequenziell hintereinander auf einem CPU-Kern. Sie werden permanent verglichen, wie das auch bei den Hardwarelösungen zur funktionalen Sicherheit gemacht wird. Durch Diversified Encoding werden 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- bzw. Feldbusprotokolle erzeugt wurden. Das derart gestaltete Sicherheitskonzept der Firma Silistra Systems wurde vom Tüv Süd abgenommen, erste Produktzertifizierungen bis hin zu SIL3 sind erfolgt.
Virtuelle Steuerungen nutzen
Was muss ein Anwender tun, um virtuelle SPSen zu starten? Er benötigt dazu eine Konfigurationsdatei bzw. das Image einer physikalischen Komponente und deployed damit den oder die Container auf eine der folgenden Arten:
- Manuelle Ausführung von Funktionen des Betriebssystems. Diese Funktionen lassen sich auch als Skripte zusammenfassen und somit vereinfachen.
- Generische Softwareplattformen wie Kubernetes oder Open Shift, die eine automatisierte Konfiguration, Verwaltung und Koordinierung von Computersystemen, Anwendungen und Services ermöglichen.
- Proprietäre Plattformen für die Automatisierungstechnik, z.B. der Codesys Automation Server. Die Funktion zum Deployment der virtuellen SPS in der Codesys-eigenen Industrie 4.0-Plattform steht kurz vor der Freigabe.
Gründe für virtuelle SPSen
Werden physikalische SPSen durch eine Plattform mit virtuellen Steuerungen ersetzt, können Anwender bei der Hardware-Ausstattung ihrer Steuerungslandschaft sparen. Zudem müssen Anwender bei einer physikalischen Steuerung die Leistungsparameter im Vorfeld festlegen, für eine virtuelle SPS kann mit der Applikation entschieden werden. Außerdem werden für zusätzliche virtuelle Steuerungen auf einem Rechner weder neue Kabel noch Spannungsversorgungen benötigt. Auch Security-Updates lassen sich so deutlich leichter einspielen. Insgesamt lohnt sich die betriebswirtschaftliche Betrachtung immer häufiger, in welchen Anwendungen virtuelle Steuerungen sinnvoll sind.