Mission impossible: Rogue timing Erfolgreiche Virtualisierung harter Echtzeitsysteme

Anbieter zum Thema

Broadcom Corporation

ORACLE Deutschland B.V. & Co. KG

Real-Time Systems GmbH

Siemens AG

MicroConsult Academy GmbH

mehr weniger

emlix GmbH

RTI Real-Time Innovations

weniger

Wie lassen sich harte Echtzeitsysteme virtualisieren, ohne den Determinismus zu verlieren? Der Beitrag vergleicht den Einsatz von Containern sowie Hypervisoren von Typ 1 und 2 und zeigt an einem Praxisbeispiel aus der Automobilproduktion tragfähige Architekturen auf.

Der Trend zur Virtualisierung von Rechensystemen ist – zumindest in der IT (Information Technology) – schon einige Jahrzehnte alt. Die vorrangige Motivation war dabei die bessere Auslastung der vorhandenen Hardware. Davor war beispielsweise ein Web-Server immer ein dediziertes Gerät, auch wenn er softwaretechnisch die Rechenleistung nicht brauchte. Umgekehrt konnte der Web-Server auch nicht mehr Hardware nutzen, als ein einziger Rechner zur Verfügung stellt, so dass er bei viel Last nicht ausreichend dimensioniert war.

Mitte der 2000er Jahre wurde von Intel der letzte x86-Prozessor vorgestellt, der nur einen einzigen Rechenkern hat, da sich die Rechenleistung pro Kern aus physikalischen Gründen nur noch geringfügig steigern ließ. Die Skalierung und Erhöhung der Rechenleistung finden seitdem nur noch über die Anzahl der Kerne statt.

Damit diese zusätzlichen Rechenkerne sinnvoll genutzt werden können, müssen mehrere Web-Server-Instanzen auf einem Gerät konsolidiert werden, was mittels Virtualisierung erreicht wird, die Software und Hardware vollständig voneinander entkoppelt.

Virtualisierungstechnologien

Die Virtualisierung von Systemen wurde zunächst rein mit Software gelöst und war sehr kompliziert. Ab dem Jahr 2005 gewann sie erheblich an Verbreitung, nachdem die Technik in jedem Standard-Prozessor verfügbar war [1], wobei zwei Aspekte unterschieden werden. Der eine Aspekt ist die Virtualisierung der Rechenleistung und des Speichers ( Intel „VT-x“) und der andere die exklusive Zuordnung der Peripherie, die über PCI- bzw. PCI-Express angeschlossen ist, zu einer virtuellen Maschine (Intel „VT-d“). Analog lauten bei AMD die Begriffe „AMD-V“ und AMD-Vi“.

In der Verwendung dieser Technologien hat sich der Begriff Hypervisor als Bezeichnung der Software etabliert, die diese Hardware entsprechend ansteuert und die darauf laufenden virtuellen Maschinen (VM) verwaltet. Der Markt kennt zwei wesentliche Ausprägungen, die als Hypervisor Typ 1 und Typ 2 bezeichnet werden.

Eine weitere Möglichkeit, Software von der Hardware zu trennen, ist die Container-Technologie. Alle drei Varianten werden in den folgenden Abschnitten erläutert.

Hypervisor Typ 1

Die beiden wesentlichen Merkmale eines Typ 1 Hypervisors sind, dass er zum einen direkt auf der Hardware läuft und somit das zuerst bootende System darstellt, und dass er zum anderen in der reinen Lehre auf die Emulation nicht vorhandener Hardware verzichtet.

Als Produkt verfügbar sind beispielsweise der RTS Hypervisor der Firma Real-Time Systems [2] oder der Open-Source Hypervisor Jailhouse [3].

Die beiden obigen Eigenschaften führen dazu, dass der Typ 1 Hypervisor eine vorhandene Hardware nur in kleinere Partitionen aufteilt. Eine Partition besteht aus einer Anzahl an Rechenkernen, einer definierten Menge an Hauptspeicher und verschiedener physikalisch vorhandener Peripherie-Geräte. Dies hat implizit zur Folge, dass auf einer Hardware mit N Rechenkernen maximal N-1 virtuelle Maschinen laufen können, da der Hypervisor für seine internen Verwaltungsaufgaben einen Kern für sich behält.

Die Konfiguration mit Kernen, Speicher und Peripherie für die einzelnen Zellen ist statisch und kann nur bei einem Neustart der Hardware durch eine andere ersetzt werden. Dabei muss sichergestellt werden, dass die in den Zellen laufenden Betriebssysteme mit diesen dynamischen Veränderungen umgehen können und sich anpassen. Da der Typ 1 Hypervisor kein Host-Betriebssystem mit Benutzer-Interaktion darstellt, laufen nur Gast-Systeme.

Bild 1 zeigt den Typ 1 Hypervisor in einer definierten Konfiguration mit drei virtuellen Maschinen, die jede einen Rechenkern und verschiedene Peripheriegeräte enthält, die dieser VM fest zugeordnet sind.

Durch die feste Bindung einer virtuellen Maschine an einen oder auch mehrere Rechenkerne läuft das System darin quasi direkt auf der Hardware, als ob die anderen Systeme nebendran nicht existieren würden. Diese strikte Trennung bedeutet somit implizit, dass die Systeme sich deterministisch verhalten, und in den Zellen eines Typ 1 Hypervisors Echtzeit-Systeme ohne Einschränkungen laufen können. Durch die direkte Zuordnung der Hardware-Peripherie können diese Systeme auch deterministisch mit ihrer Umgebung kommunizieren, beispielsweise über einen Feldbus.

In realen Produkten sind manche der oben genannten Punkte nicht vollständig umgesetzt, was aber der verbesserten Nutzbarkeit dient. So bieten viele Typ 1 Hypervisor einfache virtuelle Geräte zur Kommunikation an wie serielle Schnittstellen oder virtuelle Ethernet-Ports.

Jailhouse weicht in mehreren Punkten von der reinen Lehre ab, bleibt aber dennoch ein Typ 1 Hypervisor. Zum einen bootet er nicht direkt auf der Hardware, sondern zunächst bootet ein normales Linux. Jailhouse läuft als Kernel-Modul und schiebt sich anschließend unter das laufende Linux, das somit zur ersten Zelle („root-cell“) wird. Zum anderen bietet seine Konfiguration eine gewisse Dynamik, da in ihr mehrere Zellen mit unterschiedlichen und überlappenden Eigenschaften (z.B. Nutzung der identischen Kerne) definiert sein können. Diese überlappenden Zellen können zwar nicht gleichzeitig laufen, aber dennoch kann im laufenden Betrieb eine Zelle beendet und eine andere neu gestartet werden. Dennoch müssen die anderen laufenden Zellen deswegen nicht beendet werden, sofern keine Konflikte in der Konfiguration der aktiven Zellen bestehen.

Hypervisor Typ 2

Die beiden wesentlichen Merkmale eines Typ 2 Hypervisors sind zum einen, dass er selbst als Applikation neben anderen auf einem vollständigen Betriebssystem wie Linux oder Windows läuft, und zum anderen, dass deutlich mehr virtuelle Maschinen gleichzeitig laufen können als physikalische Ressourcen wie Rechenkerne oder Speicher vorhanden sind, da die Hardware teilweise emuliert wird.

Bekannte Produkte des Typ 2 Hypervisors sind VMware Workstation [4], Oracle VirtualBox [5] oder KVM (Kernel Virtual Machine) unter Linux [6].

Während beim Typ 1 die Konfiguration meist durch manuelles Editieren bestimmter Dateien erfolgt, bieten Typ 2 Hypervisor eine graphische Oberfläche an, um die virtuellen Maschinen sowie die Netzwerk-Verbindungen zu erstellen und zu verwalten. Die Konfiguration ist somit vollständig dynamisch und kann ohne Neustart der Hardware jederzeit verändert werden.

Da die Anzahl der Rechenkerne aller virtueller Maschinen die der real vorhandenen Kerne übersteigt, werden im Hypervisor zunächst nur virtuelle Kerne als Prozesse oder Threads des Host Betriebssystems modelliert. Diese werden durch den normalen Scheduler auf die realen Kerne verteilt, so dass jede virtuelle Maschine eine gewisse Rechenzeit bekommt. Aufgrund der Tatsache, dass das Host-System ein normales Betriebssystem wie Windows oder Linux ist, bietet der Typ 2 Hypervisor keinerlei Determinismus und der Betrieb von Echtzeit-Systemen ist nicht möglich.

Bei den Peripherien erlaubt der Typ 2 Hypervisor zwei Möglichkeiten. Zum einen lassen sich ebenfalls physikalisch vorhandene Geräte einer VM dediziert zuweisen (PCI-Path-Through) oder die Geräte werden emuliert. Der Zugriff in einer VM auf ein emuliertes Gerät führt zu einem sogenannten Hypervisor-Exit, sprich die VM bzw. der virtuelle Rechenkern wird angehalten und der Hypervisor selbst bekommt Rechenzeit, um diesen Zugriff zu verarbeiten. Anschließend gibt er die Kontrolle wieder an den virtuellen Prozessor ab.

Gerade bei der Emulation einer Hardware auf Register-Ebene führen die permanenten Exits zu erheblichen Performance-Einbußen. In dem Standard „virtio“ werden virtuelle Geräte daher nicht auf Registerebene nachgebildet, sondern über ein Shared-Memory, so dass keine Hypervisor-Exits notwendig sind. Dies erfordert aber einen speziellen Treiber für dieses virtuelle Gerät im Gast-Betriebssystem der VM. Das Paradigma, dass die VM sozusagen weiß, dass sie eine VM ist, nennt man Paravirtualisierung.

Die obige Abbildung zeigt den Aufbau eines Typ 2 Hypervisor Systems. Dieser läuft als Applikation auf dem Host neben anderen Programmen und die VMs laufen innerhalb des Hypervisors. In diesem Beispiel hat die VM 1 außer einer virtuellen Peripherie auch eine reale zugewiesen bekommen.

Da die Verwaltung der virtuellen Maschinen als eigenständige Host-Applikation läuft, können manche Systeme sogar mehr als eine Rechenhardware kontrollieren (virt-manager für Linux KVM). Dennoch bleibt die Zuordnung der einzelnen VMs zu einer bestimmten Hardware eine manuelle Aufgabe des Benutzers. Soll dies automatisch erfolgen, muss auf größere Systeme gewechselt werden, die eine lokale Cloud-Infrastruktur mit mehreren Rechenknoten bieten wie VMware ESXi oder RedHat OpenShift.

Container

Mit virtuellen Maschinen lassen sich Applikationen leichter verwalten und die vorhandenen Rechen-Einheiten deutlich besser ausnutzen, speziell mit den Typ 2 Systemen. Dennoch belegt eine virtuelle Maschine durch das darin vorhandene Gast-Betriebssystem erheblich mehr Ressourcen als die reine Applikation, die darin läuft.

Daher hat sich eine weitere Methode etabliert, die speziell die reine „Virtualisierung“ einer Applikation bietet, sogenannte Container. Da nur die Applikation virtualisiert wird, ist keine spezielle Hardware im Prozessor notwendig, so dass der korrekte Begriff „Containerisierung“ lautet.

In einem Container laufen die Applikation auf dem Host-Betriebssystem und nutzen dessen Kernel, werden aber in eine eigene Hülle mit definierter Umgebung hinsichtlich Bibliotheken und Zusatzprogrammen gepackt. Dieses Konglomerat wird als „Userland“ bezeichnet, da es im Gegensatz zum Host-Kernel auch im sogenannten User-Mode des Prozessors läuft, der beispielsweise nicht direkt auf die Hardware zugreifen darf.

Des Weiteren hat jeder Container ein lokales Filesystem mit allen für ihn relevanten Dateien. Bei Bedarf kann auch ein Verzeichnis auf dem Host in den Container gespiegelt werden, beispielsweise für Konfigurationsdaten, so dass die festgelegte Applikation im Container dennoch flexibel gestartet werden kann. Zum Schutz des Host-Systems wird der Container zudem hinsichtlich Nutzung der Rechenleistung und des Speichers eingeschränkt.

In einem Container sind bei entsprechender Konfiguration nur die essentiellen Bibliotheken drin, damit die Applikation laufen kann. Daher ist sein Filesystem-Abbild erheblich kleiner als das einer vergleichbaren virtuellen Maschine. Durch die Nutzung des bereits laufenden Kernels des Host-Betriebssystem startet ein Container sehr schnell. Die minimale Auswahl an Programmen und Bibliotheken im Container verringert zudem die Anzahl möglicher Security-Probleme. Der direkte Zugriff auf Hardware ist in einem Container nicht möglich, sondern kann nur durch das Spiegeln des entsprechenden Kernel-Treibers erreicht werden.

Ein weiterer, sehr großer Vorteil von Containern ist, dass sie stapelbar sind und aufeinander aufbauen können, was die nachfolgende Abbildung verdeutlicht.

Die Container 1 und 5 sind vollständig und enthalten jeweils das Userland, alle Bibliotheken und die Applikation. Brauchen mehrere Container die gleiche Basis, kann diese als eigener Container (2) ausgebildet werden, der aber selbst keine Applikation enthält. Die Container 3 und 4 wiederum nutzen diese Basis und lassen darauf unterschiedliche Applikationen laufen. Das Userland von Container 2 wird damit nur ein einziges Mal in den Hauptspeicher geladen und von den Applikationen in den Containern 3 und 4 benutzt. Selbst wenn das Userland und die Bibliotheken der Container 1 und 5 identisch wären, wären sie dennoch zweimal im Speicher vorhanden, da diese Container disjunkt sind.

Da alle Applikationen in den Containern mit dem Kernel des Hosts laufen, lassen sie sich in gängigen Programmen zur Anzeige der Prozesse und Threads eines Linux-Systems (z.B. top) beobachten. Die Container-Technologie ist somit vollkommen transparent, während das Host-System die Prozesse innerhalb einer virtuellen Maschine nicht anzeigen kann.

Die bekannteste Container-Verwaltung ist Docker [7] mit Werkzeugen zum Erzeugen, Betreiben, Beobachten und Entfernen von Containern. Steigt die Anzahl der Container hilft die Erweiterung „docker-compose“, den Überblick über die vielen Konfigurationen der einzelnen Container zu behalten. Werden mehrere Recheneinheiten zum Betrieb von Containern genutzt, übernehmen Frameworks wie Kubernetes [8] das Management dieses Clusters an Rechenknoten.

Virtualisierung von Echtzeit-Systemen

Echtzeit-Systeme zeichnen sich durch eine deterministische Verarbeitung der Daten aus, da jedes Rechenergebnis sowohl vom Wert her als auch vom Zeitpunkt der Fertigstellung der Berechnung her korrekt sein muss. Deswegen bestehen solche Systeme meistens aus der sehr gut aufeinander abgestimmten Kombination von Hardware und Software, um jederzeit den geforderten Determinismus zu gewährleisten.

Die Verbindung dieser Systeme mit Virtualisierung erscheint zunächst ungewöhnlich und nicht sinnvoll, bietet aber große Vorteile. Da moderne Prozessoren vorwiegend über die Anzahl der Rechenkerne skalieren, sind sie für viele Anwendungen überdimensioniert, während die Leistung eines einzelnen Rechenkerns kaum noch zunimmt. Viele Echtzeit-Systeme können diese Skalierung nur unzureichend nutzen, weil die Applikation nicht mitskaliert.

Die Kombination mehrerer Echtzeit-Applikationen auf einem System mit mehreren Kernen ist nicht trivial, da gegenseitige Abhängigkeiten und Beeinflussungen das erforderliche Zeitverhalten massiv beeinträchtigen können. Die IT hat das Problem der unzureichend genutzten Rechenressourcen bereits gelöst, so dass diese Lösungen „nur“ noch um den Aspekt der Echtzeit erweitert werden müssen.

Die wichtigste Voraussetzung, um ein Echtzeit-System virtualisieren zu können, ist die Unabhängigkeit von bestimmten Hardwarebelangen. Gerade im Automatisierungsumfeld nutzen die Speicher-Programmierbaren-Steuerungen (SPS) inzwischen fast alle Ethernet-basierte Feldbus-System, um Daten mit der Peripherie einer Produktionsmaschine oder Anlage auszutauschen. Die weitere Betrachtung geht daher von einer SPS mit Feldbus aus.

Echtzeit bei Container

Container laufen auf Linux-Systemen, so dass sie auch auf Echtzeit-Linux-Systemen laufen können. Dennoch kann noch kein Determinismus garantiert werden, da die bei Containern wirksamen Schutzmechanismen verhindern, dass der Echtzeit-Prozess zu viel Rechenleistung verbraucht. Diese Einschränkungen lassen sich aber mit entsprechenden Rechten in der Container-Konfiguration lösen. Ebenso kann der Prozess eines Containers exklusiv auf einem dedizierten Rechenkern laufen, so dass der Determinismus der Applikation gewährleistet bleibt.

Das übliche Container-Netzwerk beruht auf der Netzwerk-Bridge im Linux-Kernel, die allerdings nicht in dessen Echtzeit-Teil integriert ist. Damit lassen sich keine zyklischen Feldbus-Daten zuverlässig versenden, zumindest nicht im niedrigen einstelligen Millisekunden-Bereich, der in der Automatisierung üblich ist. Eine mögliche Lösung ist der direkte Zugriff auf eine Netzwerk-Schnittstelle, die dann aber nicht von anderen, parallel laufenden Applikationen oder Containern genutzt werden kann.

Des Weiteren muss die Echtzeit-Applikation auf Linux (PREEMPT_RT) laufen und nicht auf einem anderen Echtzeit-Betriebssystem wie beispielsweise VxWorks.

Echtzeit bei Hypervisor Typ 1

Die Typ 1 Hypervisor werden explizit für den Betrieb von Echtzeit-Systemen angeboten, wobei davon ausgegangen wird, dass die Systeme mit den kleinen Einschränkungen der virtuellen Maschinen zurechtkommen. Peripheriegeräte und damit auch Netzwerkkarten können allen Systemen individuell zugeordnet werden. Jede virtuelle Maschine stellt eine eigene Hardware dar, so dass beliebige Echtzeit-Betriebssysteme virtualisiert werden können, die diesen Prozessortyp unterstützen.

Dennoch muss das Gesamtsystem manuell konfiguriert werden und nicht alle Hypervisor erlauben beispielsweise den Neustart einer einzelnen virtuellen Maschine. Des Weiteren können die dazugehörigen Programme nur eine einzige Rechen-Einheit verwalten, so dass diese für die Summe aller Systeme ausreichend dimensioniert sein muss.

Für eine kleine, überschaubare Anzahl an Echtzeit-Systemen auf einer einzigen Hardware-Einheit ist der Typ 1 Hypervisor dennoch eine gute Lösung, wenn die Konfiguration nicht ständig geändert werden muss.

Echtzeit bei Hypervisor Typ 2

Für größere Anlagen, die eine Vielzahl an virtuellen Steuerungen brauchen, bieten sich Typ 2 Hypervisor Systeme an, da sie zum einen viele virtuelle Maschinen verwalten können und zum anderen über mehrere Hardware-Einheiten skalieren.

Weil die Erweiterung um Echtzeit-Fähigkeiten zwingend Modifikationen an dem Host-System erfordert, wurde die Entwicklung auf Basis von OpenSource-Systemen betrieben. Als Basis wird ein echtzeitfähiges Linux (PREEMPT_RT) verwendet und als Hypervisor das Paket Linux-KVM inklusiver seiner Verwaltungsprogramme.

Zur echtzeitfähigen Virtualisierung der Rechenzeit müssen zwei Eigenschaften verändert werden. Wie alle Typ 2 Hypervisor nutzt auch KVM intern das Konzept der virtuellen CPU zur Abbildung eines Rechenkerns über das Emulationstoll Qemu. In der Konfiguration lassen sich diese virtuellen Kerne auf physikalische Kerne abbilden, was implizit auch zur Folge hat, dass diese Kerne dem Linux-Scheduler für andere Prozesse als der virtuellen CPU entzogen werden. Außerdem muss der Speicher der virtuellen Maschine vor dem Auslagern auf die Festplatte mittels „memlock()“ geschützt werden.

Dennoch können auf den nicht von Echtzeit-VMs blockierten Rechenkernen beliebig viele normale VMs laufen, so dass damit alle Geräte in einer typische Produktionszelle wie SPS, HMI (Human Machine Interface) und weitere IPCs (Industrial PC) mit Linux oder Windows virtuell betrieben werden können. Da ein Typ 2 Hypervisor virtuelle Netzwerke unterstützt, ist die Vernetzung dieser Geräte untereinander ebenfalls vorhanden. Die virtuellen Netzwerke und Switche erfüllen jedoch nicht die deterministischen Anforderungen Ethernet-basierter Feldbusse.

Echtzeit Netzwerke

Die Lösung bietet das OpenSource-Projekt DPDK (Data Plane Development Kit), mit dem sich eigene Software-Switche erstellen lassen. Um deterministisch Pakete bearbeiten zu können, läuft der DPDK-Switch ebenfalls auf einem dedizierten Kern. Des Weiteren verzichtet der Switch auf Interrupts zur Benachrichtigung, dass ein Paket an einem Port anliegt, da der damit verbunden Kontext-Wechsel zu viel Rechenzeit kostet. Stattdessen fragt er in einer Schleife alle Ports ab und bearbeitet pro Port allerdings nur das erste vorhandene Paket, so dass alle Ports in einem streng definierten Zyklus drankommen. Der maximale Jitter ist somit direkt proportional zur Anzahl der Ports.

Bild 4 zeigt das Prinzip des DPDK-Switches mit vier Ports. Auf dem Host-Rechner laufen vier virtuelle Steuerungen sowie der virtuelle Switch. Dabei werden die Ports streng zyklisch abgefragt, ob ein Paket vorliegt. Falls ja, versieht der vSwitch alle Pakete mit dem VLAN-Tag (virtual LAN), der zuvor für diese Steuerung definiert wurde.

Anschließend schickt er die Pakete über eine physische Gigabit-Verbindung in Richtung Shopfloor, wobei die zeitliche Reihenfolge aller Pakete aller Steuerungen korrekt widergespiegelt wird. Der reale Switch im Shopfloor wiederum kennt die VLAN-ID jedes Peripherie-Stanges und kann die Pakete nach Entfernen des Tags an den richtigen Port schicken. Umgekehrt versieht der reale Switch die Antwort-Pakete der Peripherie mit dem VLAN-Tag, so dass diese bei der richtigen Steuerung ankommen. Dies funktioniert auch in größeren Netzen mit mehreren Host-Rechnern und mehreren Switchen.

Sowohl für die virtuelle Steuerung als auch für die Peripherie-Geräte ist dieser Mechanismus vollkommen transparent, da die VLAN-Tags nie bei ihnen ankommen. Alle Maßnahmen sind zudem mit der Ethernet-Definition gemäß des Standards IEEE 802.3 kompatibel, so dass sie mit jedem Feldbus funktionieren, der diesen Standard erfüllt. Des Weiteren nutzen gängige Feldbus-Systeme nur Fast-Ethernet mit 100MB/s. Aufgrund der Technik des Gigabit-Ethernets gemäß IEEE 802.3ab lassen sich bis zu acht Fast-Ethernet-Stränge auf einer Gigabit-Leitung bündeln, ohne dass Latenzverzögerungen auftreten, was für den Echtzeit-Anspruch zwingend notwendig ist. Der maximale Durchsatz bei Gigabit spielt hingegen eine untergeordnete Rolle.

Somit ergibt sich für den Betrieb virtueller Steuerungen als ideale Anzahl an Rechenkernen die Zahl zehn. Diese setzt sich zusammen aus maximal acht Kernen mit echtzeitfähigen virtuellen Maschinen, einem Kern für den deterministischen virtuellen Switch und einem Kern für das Host-Betriebssystem selbst, wie Bild 5 zeigt.

Sollen zusätzlich auf dem gleichen Rechenknoten weitere, nicht echtzeitfähige virtuelle Maschinen laufen, kann die Anzahl der Rechenkerne entsprechend erhöht werden.

Reale Anwendung bei Audi

Die mit diesen Modifikationen mögliche Konsolidierung aller in einer Produktion vorhandenen Steuerungen in einem Rechen-Cluster stößt bei vielen Anlagenbetreibern auf großes Interesse. Sie versprechen sich sowohl eine schnellere Inbetriebnahme als auch weniger Zeitverlust bei Fehlern einzelner Geräte, da virtuelle Maschinen in Sekundenschnelle ersetzt werden können.

Audi hat in einem Pilotprojekt zusammen mit Siemens und VMware die virtuelle Steuerung in die Produktion am Standort Böllinger Höfe bei Neckarsulm gebracht. VMware hat dabei die oben genannten notwendigen Veränderungen in der Virtualisierung wie die feste Bindung eines virtuellen Rechenkerns an einen physikalischen und das Verhindern des Auslagerns des entsprechenden Speichers in ihr kommerzielles Produkt ESXi eingebaut. Ebenso wurde der darin enthaltene virtuelle Switch für Echtzeit-Datenverkehr ertüchtigt.

Diese softwaretechnische Lösung, die speicherprogrammierbaren Steuerungen in einem Rechenzentrum statt direkt an der Produktionslinie zu betreiben, will Audi sukzessive auf weitere Standorte und weitere Linien ausrollen [9].

Obwohl sich die Technologien Echtzeit-Systeme und Virtualisierung auf den ersten Blick eher auszuschließen scheinen, bringt die Kombination eine ganze Reihe an Vorteilen beim Betrieb größerer Produktionsanlagen. Die Konsolidierung der Speicherprogrammierbaren Steuerungen in einer lokalen IT-Infrastruktur erlaubt eine einfachere Bereitstellung und Wartung der einzelnen Steuerungen. Zudem bieten die IT-Systeme Sicherheit gegen Hardware-Ausfälle, indem virtuelle Maschinen auf andere, noch laufende Rechenknoten verschoben werden können.

Neben Siemens bieten inzwischen auch andere Hersteller ihre SPS als virtuelle Variante an, so dass die Kunden ihre vertraute Umgebung behalten können. Die Kombination klassischer OT-Geräte mit der IT-Infrastruktur bringt allerdings noch weitere, nicht zwingend technische Herausforderungen mit sich, vor allem im Bereich der Zuständigkeit im Fehlerfall. Ebenso müssen IT und OT mehr Verständnis für die Eigenheiten des jeweils anderen entwickeln. (sg)

Dieser Beitrag stammt aus dem Tagungsband desESE-Kongress2025.

Referenzen

[1] X86_Virtualization – Wikipedia
[2] https://www.real-time-systems.com/de/produkte/rts-hypervisor/
[3] Jailhouse Hypervisor – GitHub
[4] Workstation & Fusion – VMware
[5] Oracle Virtualbox
[6] Linux KVM
[7] Docker
[8] Kubernetes
[9] Virtuell gesteuerte Fertigung erstmals im Audi Karosseriebau

* Dr. René Graf hat an der Universität Karlsruhe Physik studiert und am Institut für Robotik der Fakultät Informatik im Jahr 2000 promoviert. Bei Siemens war er acht Jahre an der Entwicklung verschiedener Generationen der Steuerung Simatic S7 beteiligt. Als Principal Key Expert bei der Vorfeldentwicklung der Business Unit Digital Industries Factory Automation befasst er sich mit neuen Steuerungsarchitekturen und deren Anwendung in Automatisierung sowie Robotik. Im Jahr 2013 wurde Dr. René Graf als "Siemens Erfinder des Jahres" ausgezeichnet. Im Laufe seiner Forschung hat er über 80 Erfindungen auf verschiedenen Gebieten erstellt.

(ID:50814445)