RTOS-VM erlaubt die Koexistenz von Windows und einem oder mehreren RTOS durch die Verwaltung von Devices, Memory, Processor Cores und anderen Hardware-Ressourcen. Das RTOS und die VMF werden durch eine Windows-Applikation geladen, welche die Uploader-DLL verwendet. TCP/IPKommunikation wird durch virtuelle Netzwerktreiber auf beiden Seiten ermöglicht, direkter Shared Memory-Zugriff über die RTOS-Library.

Die Speicherverwaltung ermöglicht es, dem RTOS einen Speicher in beliebiger Größe zuzuweisen. Dieser Speicher steht nach dem nächsten Bootvorgang dem Windows-Betriebssystem nicht mehr zur Verfügung. Neben zwei Timern (System und Auxiliary) stellt das VMF dem RTOS eine Interrupt-Verwaltung zur Verfügung. Diese dient der Anmeldung, Abmeldung und der Bearbeitung von Echtzeit-Interrupts. Die Prozessor-Cores selbst lassen sich auf unterschiedliche Art und Weise aufteilen:

Beim „Shared-Core-Betrieb“ teilen sich Windows und das RTOS einen Prozessor-Kern, wobei das RTOS aus Echtzeit-Gründen die höhere Priorität hat und sich durch entsprechende Interrupts sofort aktivieren lässt. Windows hingegen erhält nur dann Rechenzeit, wenn das RTOS „freiwillig“ – zum Beispiel nach einem Interrupt oder in der Idle-Task – die Rechenzeit des Shared Core abgibt. Diese von der herkömmlichen Kuka-Echtzeit-Erweiterung bekannte Betriebsart funktioniert auch und gerade auf Single-Core-Prozessoren, was bei anderen neuen, am Markt verfügbaren Echtzeit-Virtualisierungslösungen meist fehlt. Sollten weitere Cores vorhanden sein, so sind diese konfigurierbar verwendbar – entweder von Windows oder vom RTOS. Während Windows mehrere Cores ausschließlich im SMP-Betrieb (Symmetric Multi Processing) nutzt, kann beim RTOS entweder je eine RTOS-Instanz pro Core ablaufen (AMP, Asymmetric Multi Processing) oder aber das RTOS ist ebenfalls SMP-fähig, wobei eine Instanz des Echtzeit-Betriebssystems mehrere Cores im SMP-Betrieb verwaltet.

Die Basic VMF ist die zentrale Verwaltungsstelle von RTOS-VM. Sie wird über das Board Support Package des RTOS über eine einfache Sprungtabelle angesteuert und verwaltet Memory, Processor Cores, Devices, Interrupts, Timer und mehr.

Beim „Exclusive-Core-Betrieb“ erhalten Windows und das RTOS per Konfiguration eine bestimmte Anzahl von exklusiven Cores zugeteilt. Was das RTOS betrifft, so kann hier ebenfalls entweder je eine Instanz pro Core ablaufen oder eine Instanz des RTOS mehrere Cores im SMP-Betrieb verwalten. Da jedes Operating System (OS) in dieser Betriebsart sein(e) Core(s) exklusiv verwenden kann, gibt es hier – anders als beim Shared Core – so gut wie keine Interferenzen zwischen dem RTOS und Windows, was die Echtzeit-Eigenschaft beziehungsweise die Laufzeit-Performance betrifft. Insbesondere Windows erhält immer die komplette Rechenzeit seiner Cores und wird nicht durch die Echtzeit-Aufgaben gebremst, wie dies bei Shared Cores der Fall ist.

Unabhängig von den Core-Betriebsarten besteht bei beiden die Möglichkeit, zusätzlich zu den geteilten Ressourcen exklusive Ressourcen zu bestimmen. Dabei handelt es sich in der Regel um PCIDevices, welche entweder nur vom RTOS oder nur von Windows angesteuert werden. Ersteres steuert dabei die exklusiven RTOS-Ressourcen durch direkte Hardware-Zugriffe genauso an, als liefe das RTOS alleine auf dem PC ab. Dadurch sind alle Gerätetreiber, die für das Echtzeit-Betriebssystem existieren, ohne Änderung – also im Binär-Code – auch innerhalb der VM verwendbar. Die Verwaltung und Konfiguration dieser exklusiven Ressourcen übernimmt das so genannte „Real Time Device Management“ innerhalb des VMF. Für diejenigen Devices, welche das RTOS ansteuern soll, werden unter Windows so genannte RtosPnp-Treiber installiert. Unter Windows haben diese keine Funktion, sondern stellen lediglich sicher, dass der Plug&Play-Mechanismus von Windows nicht andauernd nach einem Windows-Treiber für das Gerät frägt und dass die Geräte-Ressourcen von Windows freigehalten werden.

Die Kommunikation

Die RTOS-Devices werden unter Windows mit Dummy-Treibern installiert.

Auf der Grundlage der bisherigen Ausführungen ist das RTOS zusammen mit Windows grundsätzlich funktionsfähig – für die tägliche Arbeit fehlt allerdings noch etwas Entscheidendes: die Kommunikation zwischen Windows und dem Echtzeit-Betriebssystem. RTOS-VM bietet hierfür zwei grundsätzliche Mechanismen: TCP/IP-Kommunikation und direkte Zugriffe auf ein Shared Memory.

Die Realisierung der TCP/IP-Kommunikation erfolgt durch Netzwerktreiber, welche – anstatt einen realen Ethernet-Controller anzusteuern – auf ein gemeinsames Shared Memory arbeiten. Der NDIS genannte Treiber für Windows ist Bestandteil des Software-Framework, der RTOS-spezifische Treiber hingegen ist vom Anwender für das jeweilige RTOS selbst zu erstellen. Dies ist mit geringem Aufwand möglich, da das VMF einfache Funktionen für den Netzwerk-Packet-Transfer zur Verfügung stellt.

Die zweite Art der Kommunikation besteht aus direkten Zugriffen auf ein Shared Memory, dessen Größe per Konfiguration einstellbar ist. Durch entsprechende APIAufrufe sowohl auf der Windows- als auch auf der RTOS-Seite erhalten Applikationen auf User-Ebene direkte Zeiger in das Shared Memory hinein und können darüber direkt Daten austauschen. Unterstützt wird dies durch bidirektionale Events, also asynchrone Nachrichten, welche von einem OS zum anderen geschickt werden. Dadurch kann eine Applikation dem Gegenpart auf dem anderen Betriebssystem signalisieren, dass sich Daten im Shared Memory geändert haben.

Autor

Heinrich Munz ist Produktmanager für die Echtzeit-Betriebssystem-Sparte von Kuka, Augsburg.

Erste Implementierung: QNX

Ein erster Anwender von RTOS-VM ist die Königsbrunner Firma IBV – Echtzeitund Embedded. Als autorisierter QNX-Distributor hat IBV das SMP-fähige Echtzeit-Betriebssystem QNX an RTOS-VM angepasst und stellt dies ebenfalls auf der Embedded World 2008 vor. Lutz Vollbracht, Geschäftsführer von IBV, hierzu: „Schon seit längerer Zeit waren wir auf der Suche nach einer Lösung, die es ermöglicht, Windows und QNX auf einem Prozessor zu vereinen, und so die harte Echtzeit-Fähigkeit von QNX mit der Connectivity und den Grafikfähigkeiten von Windows zu kombinieren. Gerade unsere Kunden aus der Automatisierungs- und Messtechnik würden gerne auf den klassischen Ansatz verzichten, bei dem dafür zwei getrennte IPCs verwendet werden, die meist über ein proprietäres und schwer zu pflegendes Protokoll kommunizieren.“

Ausschlaggebend für die Entscheidung pro RTOS-VM war unter anderem, dass der Kuka-Ansatz basierend auf seinen vielseitigen Kommunikationsdiensten die Idee einer auf mehrere Betriebssysteme verteilten Gesamt-Applikation verwirklicht, bei der das RTOS der Master ist. Was anderen Lösungen nach Aussage des IBV-Geschäftsführers oft auch fehle, ist die Möglichkeit, im Shared-Core-Betrieb beide Betriebssysteme nur auf einem einzigen Core zu betreiben beziehungsweise bereits auf einem Dual-Core-Prozessor die SMP-Fähigkeiten des RTOS nutzen zu können.

Ergo hat sich IBV dazu entschlossen – basierend auf der Kuka-Technologie – ein eigenes Produkt zu entwickeln, genannt QWin. Gemeinsam mit den bei QNX vorhandenen Möglichkeiten des „Bound Multiprocessing“ und „Adaptive Partitioning“ bietet diese Lösung laut Anbieter IBV eine ideale Möglichkeit, ein System mit nur einem Prozessor – egal ob Single- oder Multicore – nahezu „stufenlos“ in sicherheitskritische, hart echtzeitfähige und nicht-echtzeitfähige Teile zu partitionieren.