Wegen der immens gestiegenen Leistungsfähigkeit der PC-Hardware ist es in Bezug auf die benötigte Rechenzeit längst möglich, Echtzeit-Betriebssysteme und deren Applikationen in harter Echtzeit zusammen mit einem Standard-Betriebssystem (GPOS: General Purpose Operating System) wie Windows oder Linux auf einem Industrie-PC zu betreiben. Da die Kombination mehrerer Betriebssysteme von den jeweiligen Herstellern nicht vorgesehen ist, braucht es eine Zusatzsoftware.

Begonnen hat diese Konvergenz von Automatisierungs- und IT-Welt bereits in den 80er Jahren. Damals wurden Co-Prozessor-Karten in IT-Computer gesteckt und übernahmen spezielle Aufgaben wie die Echtzeit-Steuerung der Abläufe oder sehr schnelle regelungstechnische Aufgaben.

In den 90ern folgten so genannte Echtzeit-Erweiterungen, zunächst für DOS, später auch für Windows und Linux: Die originalen Betriebssysteme wurden ergänzt und teilweise verändert, um mittels spezieller Treiber in Echtzeit auf externe Ereignisse reagieren zu können. Etwa ab dem Jahr 2000 begann die Entwicklung der so genannten Echtzeit-Virtualisierungstechnologien, welche durch die Einführung von Multicore-Prozessoren neue Anbieter von Echtzeit-Virtualisierungslösungen hervorbrachte.

Echtzeit-Virtualisierung löst Multicore-Problem

Das Virtual Machine Framework (VMF) erzeugt virtuelle Echtzeit-Maschinen, in denen – über „Board-Support Packages“ angepasst – verschiedene Echtzeit- Betriebssysteme (RTOS) paravirtualisiert laufen.

© Acontis, Kuka

Bei der Echtzeit-Virtualisierung werden mehrere Echtzeit- und Nichtechtzeit-Betriebssysteme auf einem Prozessor betrieben. Dies stellt eine Möglichkeit dar, dem durch die Multicore-Prozessoren ausgelösten Software-Dilemma zu entgehen: Während früher Software auf Singlecore- CPUs in gleichem Maße mit einem höheren Prozessortakt schneller wurde, funktioniert dieses Prinzip bei der Leistungssteigerung mittels Multicore-Prozessoren nicht mehr.

Da die Anpassung alter Software auf Multicore-Architekturen oft zu aufwendig ist, bietet es sich an, die bestehende Software samt Betriebssystem auf einzelne CPU-Cores zu verteilen. Dadurch lässt sich die Performance moderner CPUs effektiver nutzen und gleichzeitig Hardware einsparen. Die Echtzeit-Virtualisierung RTOSWin wird in Kombination mit dem Echtzeit-Betriebssystem VxWorks seit 1996 in allen Robotersteuerungen der Firma Kuka eingesetzt. Die Software stellt sozusagen den „Klebstoff" dar, um VxWorks zusammen mit Microsoft Windows auf einem Steuerungs-PC zu betreiben. Das Steuerungsprogramm auf dem RTOS sorgt dabei in Echtzeit für die Bewegung des Roboters, während die Bedienoberfläche auf Windows die Bedienung des Roboters ermöglicht.

Neben den konkreten Steuerungsaufgaben an der Maschine gibt es weitere Anwendungsfälle für die Kombination von RTOS und Desktop-Betriebssystem: Für Simulations-, Schulungs- oder Präsentationszwecke ist es von Vorteil, die Steuerungssoftware in einer Büro-Umgebung verfügbar zu haben. Auch Entwickler profitieren davon, wenn sich die Applikationssoftware direkt auf dem Entwicklungssystem testen lässt. RTOSWin basiert auf dem „Virtual Machine Framework" (VMF), deren Programmierschnittstelle (VMF-API) zur Paravirtualisierung der Betriebssysteme verwendet wird. Paravirtualisierung bedeutet: Die Echtzeit-Betriebssysteme müssen an die virtuelle Umgebung angepasst werden. Dies erfolgt jedoch nicht durch Änderung des eigentlichen Betriebssystem-Codes, sondern lediglich durch Anpassung der so genannten Board-Support-Packages (BSP).

Hypervisor stellt Koexistenz mehrerer Betriebssysteme sicher

In den BSP befinden sich die hardwareabhängigen Schnittstellen, mittels derer die verschiedenen Echtzeit-Betriebssysteme an die jeweilige Hardware anzupassen sind. Für das Framework stehen die aktuellen Versionen der Betriebssysteme VxWorks, Windows CE, RTOS32, QNX und EUROS paravirtualisiert und somit unter RTOSWin „ready to run" zur Verfügung. Über die offen gelegte RTOSWin-API können Anwender auch andere Systeme anpassen. Als Windows-Betriebssysteme sind Windows XP und Windows 7, jeweils in den 32-Bit-Versionen, spezifiziert. Durch Module wie die „RTOS Virtual Machines" und den „RTOS-VM Hypervisor" erhält das Framework (Rahmenprogramm) seine Funktionalität.

Die RTOSVM sind die virtuellen Umgebungen, in denen die jeweiligen Echtzeit-Betriebssysteme laufen. Die generelle Aufgabe eines Hypervisors ist es, auf unterster Software-Ebene die Koexistenz mehrerer Betriebssysteme und deren Applikationen sicherzustellen und ihnen die benötigten Ressourcen (Arbeitsspeicher, Prozessor-Cores, anzusteuernde Devices, Interrupts, Timer etc.) zur Laufzeit zuzuweisen. Beim Hypervisor der Firma acontis handelt es sich um einen Typ2-Hypervisor, auch „hosted Hypervisor" genannt, bei dem Windows gleichzeitig als Betriebssystem für den Hypervisor und als GPOS fungiert.

Ein Typ2-Hypervisor wird von seinem Host-OS geladen, nutzt dessen Gerätetreiber und „schiebt sich" dann zwischen das Host-OS und die Hardware. Dadurch ist er einfacher an neue Hardware anzupassen als ein Typ1-Hypervisor. Diese auch als „native" oder „bare-metal"-Hypervisor bekannten Lösungen kommen zwar ohne die Hilfe eines Host-Betriebssystems aus, müssen jedoch die Hardwaretreiber und Boot-Mechanismen selbst bereitstellen.

Hardware-Virtualisierung stört Echtzeit-Betrieb

Echtzeit-Virtualisierung unter Windows und Linux: Bei RTOSWin und RTOSLin greifen die Betriebssysteme auf die ihnen zugewiesenen Geräte direkt zu – ohne die bei Echtzeit- Anwendungen kritische Hardware-Virtualisierung von Multicore-CPUs zu nutzen.

© Acontis, Kuka

Die bei einigen - aber längst nicht allen - Intel- und AMD-Prozessoren verfügbare Virtualisierungstechnologien wie Intel VT-x und AMD-V sind für den RTOS-Betrieb nicht erforderlich, ja sogar störend: Bei einem harten Echtzeit-Betrieb darf die hardwareunterstützte Virtualisierung auf die RTOS nicht angewendet werden. Der Grund: Die Echtzeit-Fähigkeit leidet durch die „Vorspiegelung" von Hardware und der sich daraus ergebenden notwendigen Verwaltungsarbeiten.

Zudem schränkt die Notwendigkeit dieser Virtualisierungstechnologien die mögliche Prozessorauswahl ein. Beispielsweise unterstützt kein Atom-Prozessor mit zwei „realen" Cores VT-x. Einige Atom-Prozessoren mit VT-x haben lediglich zwei Threads (das so genannte Hyperthreading), für einen harten Echtzeit-Betrieb sind diese „halben" Dual-Cores jedoch ungeeignet. Statt die für einen harten Echtzeit-Betrieb problematischen Virtualisierungstechnologien einzusetzen, erlaubt RTOSWin den Echtzeit-Betriebssystemen den Zugriff auf die jeweiligen Ressourcen - Speicher, Devices, Interrupts und Prozessor-Cores - direkt und exklusiv.

Dadurch entstehen für jedes RTOS so genannte Partitionen mit genau den Ressourcen, die das RTOS benötigt. Auf den in der IT-Serverwelt gewünschten Effekt des höheren Abschottungsgrades der Betriebssysteme durch die hardwareunterstützten Virtualisierungstechnologien wird hierbei zugunsten der härteren Echtzeit-Fähigkeit bewusst verzichtet.

Es geht auch ohne Multicore

Durch Partitionierung lässt sich jede Systemkomponente den einzelnen Betriebssystemen zuweisen.

© Acontis, Kuka

Ursprünglich für Singlecore-Prozessoren ausgelegt, setzen die Echtzeit-Lösungen der Firma acontis nicht zwingend eine Multicore-CPU voraus. Im so genannten „Shared Mode" lässt sich der Singlecore- Prozessor beziehungsweise der erste Core einer Multicore-CPU zwischen GPOS und RTOS aufteilen. Um die Echtzeit-Fähigkeit des RTOS zu garantieren, wird hierbei das GPOS nach Eintreffen eines Echtzeit-Interrupts preemptiv unterbrochen und innerhalb weniger Mikrosekunden in das RTOS verzweigt.

Die Rückkehr zum GPOS erfolgt kooperativ: Erst wenn alle RTOS-Tasks ihre Arbeiten erledigt haben, wird wieder zum unterbrochenen GPOS zurückgekehrt. Dagegen bekommen beim „Exclusive Mode" von Multicore-Prozessoren ein oder mehrere RTOS und das GPOS die CPU-Cores exklusiv zugewiesen und beeinflussen sich dadurch überhaupt nicht. Die Kommunikation zwischen GPOS und den RTOS kann auf verschiedene Arten erfolgen, beispielsweise über direkte Shared-Memory-Zugriffe, die über entsprechende API-Aufrufe verwaltet werden. Zudem können die Systeme asynchrone Nachrichten generieren, um anzuzeigen, dass Daten im Shared-Memory bereitliegen.

Eine weitere Kommunikationsmöglichkeit besteht über ein virtuelles Netzwerk. Dazu erhält jedes Betriebssystem eine eigene IP-Adresse. Schließlich existiert noch eine ebenfalls über Shared- Memory abgebildete virtuelle serielle Schnittstelle über die beispielsweise Terminalprogramme wie „PuTTYtel" genutzt werden können. Daneben steht eine Vielzahl von Funktionen zur Verfügung, die sich mittels offengelegter API-Aufrufe in die Applikationen einbinden lassen.

Dazu zählen beispielsweise APIs für:

• Notification handling: Ereignisse wie Blue-Screen, RTOS-Stop-Anforderung werden darüber vom GPOS an das RTOS gemeldet.
• Date and Time Synchronization: Datum und Uhrzeit können vom GPOS zum RTOS oder umgekehrt synchronisiert werden.
• Timer adjustment: Die RTOS-Zeitgeber können nachjustiert werden, etwa um eine Zeitsynchronisation (IEEE 1588 oder Ethercat-Distributed Clock) zu realisieren.
• High Performance Event Timer (HPET): Ermöglicht Core-unabhängige submikrosekundengenaue Zeitmessungen.
• CPU utilization measurement: Messfunktionen, welche die momentane Rechenzeitbelastung der Cores auswerten.
• Remanent Data Handling: Daten lassen sich in einer RTOS-RAM-Disk verwalten, welche beim Beenden auf die Festplatte gespeichert wird.

Echtzeit-Plattform für Linux

Beim RTOSVisor kommen zwei Hypervisor-Systeme zum Einsatz, um das unabhängige Rebooten der GPOS zu ermöglichen: Der echtzeitfähige RTOS-VM für die RTOS und der nicht echtzeitfähige KVM für die GPOS.

© Acontis, Kuka

Nach Übernahme der exklusiven Weiterentwicklungs- und weltweiten Vermarktungsrechte Anfang 2010 von der Firma Kuka Roboter unterstützt acontis mit RTOSLin künftig ein zweites GPOS und zwar Linux. Damit wird erstmals ein weiteres GPOS unterstützt, anstatt wie bisher die Anzahl der paravirtualisierten Echtzeit-Betriebssysteme zu erhöhen. Die Basistechnologie des VMF wurde beibehalten, so dass sämtliche bisher mit Windows kombinierbaren Echtzeit-Betriebssysteme ohne Anpassungen unter Linux zur Verfügung stehen: VxLin, Ce- Lin, QLin, RTOS32Lin und EUROSLin.

Bei einem Typ2-Hypervisor wie RTOSWin und RTOSLin kann das GPOS nicht unabhängig von den RTOS neu gestartet werden - schließlich nutzt die Software dieses GPOS. Gelegentlich ist die Unabhängigkeit zwischen GPOS und RTOS notwendig beziehungsweise eine Anforderung der Anwender, die acontis mit Hilfe der Software RTOSVisor umsetzt. Bei dieser Variante ist das Anwender-Betriebssystem (GPOS) nicht mehr identisch mit dem Hypervisor-Betriebssystem. Somit sind die beiden Betriebssysteme wieder voneinander unabhängig und das GPOS lässt sich individuell booten. Als Hypervisor-Betriebssystem kommt in der ersten Version von RTOSVisor ein minimiertes Linux-System ohne Grafikoberfläche („Headless") zum Einsatz. Dieses wird wie bei RTOSLin zuerst gebootet, lädt und startet anschließend den Hypervisor, die RTOS-Virtual Machines und die darin laufenden Echtzeit-Betriebssysteme mit ihren Applikationen.

Bis zu diesem Zeitpunkt sind nur die RTOS geladen und noch keine der hardwareunterstützten Virtualisierungen (Intel VT oder AMD-V) notwendig. Diese werden erst benötigt, wenn neben den Echtzeit-Betriebssystemen ein oder mehrere Windows- oder Linux-Systeme betrieben werden sollen. Dazu wurde das headless Hypervisor- Linux um die Open- Source-Software-Komponenten KVM und QEMU erweitert. Der Linux-Kernel, KVM und QEMU unterliegen der GNU Public License (GPL) und sind als solche kein kommerzieller Bestandteil von RTOSVisor. Sie bilden lediglich eine Infrastruktur, in denen Windows und Linux zusätzlich zu den echtzeitfähigen Komponenten inklusive der Echtzeit- Betriebssysteme ablaufen können. Damit die GPOS trotz der Virtualisierung leistungsfähig bleiben, kommen auch hier teilweise paravirtualisierte Treiber für das Gastsystem zum Einsatz.

Somit werden beispielsweise sehr schnelle Zugriffszeiten auf die Hard-Disk des Hosts beziehungsweise bei der Netzwerkkommunikation erreicht. Über die Open- Source-Virtualisierungstechnik Spice stehen paravirtualisierte Treiber für Grafik und Audio zur Verfügung. In künftigen RTOSVisor-Versionen sollen Linux, KVM und QEMU auch gegen andere Mainstream GPOS-Virtualisierungslösungen wie Microsoft Hyper-V ausgetauscht werden können.

Autoren:

Heinrich Munz ist Senior Software Developer bei der Firma Kuka Roboter in Augsburg.

Stefan Zintgraf ist Geschäftsführer der Firma acontis technologies in Weingarten.