Die Konsolidierung mehrerer Systeme auf einem Multicore-Prozessor kann Kosten, Stromverbrauch und Platzbedarf reduzieren, aber aufgrund der gemeinsamen Ressourcesnnutzung auch zu Herausforderungen bei der Echtzeitleistung führen. Diese Situation lässt sich durch die Trennung von Kernel-Hypervisoren meistern. Und indem man die zweite Schicht der Automatisierungspyramide – die Überwachungsschicht – softwaregesteuert neu definiert.
Industriepyramide und Netzwerkperipherie
Der Einsatz moderner Rechenressourcen mit Cloud-nativen Modellen des Software-Lifecycle-Managements wird sich in der Automatisierung immer mehr durchsetzen. Die Platzierung von virtualisierten Ressourcen näher an dem Ort, an dem mehrere Datenströme erzeugt werden, ist eindeutig von Vorteil. Doch es bleiben Herausforderungen in Bezug auf Systemlatenz, Datenschutz, Kosten und Ausfallsicherheit, die ein reiner Cloud-Computing-Ansatz nicht bewältigen kann. Hier kommt Edge Computing ins Spiel und prägt eine neue Hierarchie – die Industriepyramide – gerade in den unteren, OT-fokussierten Ebenen. Dazu gehören:
- Heterogene Hardware: Typische industrielle Automatisierungsumgebungen haben unterschiedliche Architekturen, x86, Arm, sowie eine Vielzahl von Rechen-Konfigurationen.
- Sicherheit: Die Sicherheitsanforderungen und deren Abmilderungen sind von Gerät zu Gerät unterschiedlich und müssen sorgfältig gehandhabt werden.
- Innovation: Während einige industrielle Anwendungen mit dem alten Paradigma weitermachen können, erfordert der Großteil der industriellen Welt nun zusätzlich moderne Datenanalyse und Überwachung der Anwendungen in ihren Anlagen.
- Datenschutz: Wie in anderen Bereichen der IT wird die Verwaltung von Datenberechtigungen in vernetzten Maschinen immer komplexer und muss bereits bei der Entstehung der Daten geregelt werden.
- Echtzeit und Determinismus: Der von Steuerungen bereitgestellte Echtzeit-Determinismus bleibt für die Sicherheit des Betriebs entscheidend.
Das Konzept Mission Critical Edge entsteht aus der Einbindung von Embedded-Anforderungen in virtualisiertes Lifecycle-Management sowie datenreiches Computing. Es geht die Herausforderungen der IT/OT-Schnittstelle frontal an, indem es wesentliche, aber fragmentierte Legacy-Systeme durch ihre sichere Konsolidierung und Orchestrierung unterstützt und ihre Anreicherung mit Analytics und KI fördert. Daraus resultiert die Vision eines Multicore-Rechenknotens, der als Architektur folgendes bietet: Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
- Verteilte und zusammengeschaltete, gemischtkritische, virtualisierte Multicore-Rechenknoten (System of Systems).
- Netzwerkunterstützung für traditionelle IT-Kommunikation (z. B. Ethernet, WiFi) und deterministische Legacy-Feldbusse, die sich in Richtung eines verbesserten Determinismus durch Ethernet TSN bewegen, sowie öffentliche und private 4G/5G.
- Unterstützung für die Datenverteilung innerhalb und zwischen den Knoten, basierend auf Standard-Middleware (OPC UA, MQTT, DDS und mehr) wird ebenfalls Determinismus anstreben (z. B. OPC UA über TSN).
- Als virtuelle Maschinen (VMs) und Container verpackte Anwendungen, die das Lebenszyklusmanagement erleichtern.
Testbed und vorläufige Ergebnisse
Mit dieser Vision im Hinterkopf haben sich Lynx, Exor, Codesys und Next Stel zusammengetan, um ein industrielles Testbed aufzubauen. Exor ist sowohl Hardware-Ausrüster als auch Edge-Software-Anbieter mit Spezialisierung auf Data Ingestion und Analyse-Frameworks. Codesys bietet virtuelle SPS-Ökosysteme, die unter Debian Linux laufen, oder als eigenständige Bare-Metal-Lösung. Next-Stel hat als Systemintegrator viel Erfahrung in Entwicklung und Einsatz von industriellen Steuerungssystemen. Im Rahmen des Testbeds wurde LynxSecure mit vier Gästen (bzw. Subjekten) konfiguriert. Damit eine solche Konfiguration praktikabel ist, muss ihre Performance innerhalb der anspruchsvollen Parameter der OT-fokussierten Ebenen liegen. Das hängt vor allem von der Leistungsfähigkeit der virtualisierten Anwendungen ab.
Da eine typische industrielle Steuerung auf einer zyklischen Regelung basiert, muss sie gewährleisten, dass alle Berechnungen an den beiden Endpunkten des Regelkreises und alle in jedem Regelzyklus erforderlichen Kommunikationen zwischen diesen Punkten vor Beginn des nächsten Zyklus abgeschlossen sind. Es wurden drei Messreihen mit Codesys durchgeführt: auf Bare-Metal-Hardware, auf LynxSecure und schließlich auf LynxSecure mit störenden Workloads. In allen drei Fällen wurde die Codesys-Kontaktplananwendung mit einer Zykluszeit von 250µs betrieben. Es gab nur eine geringe Verschlechterung der Echtzeit-Performance, wenn die Codesys-Anwendung von der Bare-Metal- auf die LynxSecure-Umgebung migriert wird, und keine nennenswerte Verschlechterung wenn Codesys auf LynxSecure läuft (mit oder ohne störenden Workloads).
Echtzeit-Leistungsanalyse
Anschließend hat Next-Stel Tests durchgeführt, wie gut die gewählte Architektur den Echtzeit-Netzwerkverkehr bewältigt. Die umfangreiche Analyse unter Berücksichtigung von Jitter, Scheduling- und Stack-Latenz kam zu dem Schluss, dass der LynxSecure-Hypervisor kritische Echtzeit-Aktivitäten effektiv von anderen Aktivitäten isoliert, die auf demselben System gehostet werden, und fügte gleichzeitig bis zu 50µs zum Jitter hinzu, der im äquivalenten Aufbau, aber ohne Virtualisierung, beobachtet wurde. Es wurde gefolgert, dass die minimale Zykluszeit, die mit dieser Lösung gehandhabt werden kann, 250µs sowohl für Ethercat als auch für Profinet beträgt. Noch schnellere Zykluszeiten sind wahrscheinlich möglich, wenn Para-Virtualisierung und/oder ein anderes RTOS als Debian RT eingesetzt wird.
