RTOS nach Belieben

Die Steuerungstechnologie von Kuka basiert bereits seit über zehn Jahren auf der Windows-Echtzeit-Erweiterung VxWin. Diese macht VxWorks zusammen mit Windows XP oder Windows XP Embedded auf ein und derselben PC-Hardware lauffähig.

Die Steuerungstechnologie von Kuka basiert bereits seit über zehn Jahren auf der Windows-Echtzeit-Erweiterung VxWin. Diese macht VxWorks zusammen mit Windows XP oder Windows XP Embedded auf ein und derselben PC-Hardware lauffähig. Jetzt „öffnet“ der Robotik-Spezialist diese Plattform für beliebige andere Echtzeit-Betriebssysteme, wobei der Anwender die Anpassung mit einfachen Mitteln selbst vornehmen kann.

Echtzeit-Betriebssysteme gibt es viele. Noch größer ist die Anzahl von Applikationen, welche für diese Realtime Operating Systems – kurz RTOS – erstellt worden sind und immer noch erstellt werden. In der Regel laufen die Echtzeit-Anwendungen und Windows jeweils auf einer eigenen Hardware-Plattform. Mit ihrer PC-basierten Robotersteuerung hat Kuka schon 1996 diese Trennung aufgehoben und betreibt seither das RTOS VxWorks, welches für die eigentliche Robotersteuerung in harter Echtzeit mit Interrupt-Reaktionszeiten im Mikrosekundenbereich zuständig ist, zusammen mit Windows XP Embedded auf einem einzigen PC-System. Allerdings war es mit der Windows-Echtzeit-Erweiterungs-Software bislang nur möglich, eine einzige Instanz von VxWorks beziehungsweise seit 2003 auch Windows CE zusammen mit Windows zu verwenden. Dass bis dato keine weitere Echtzeit-Betriebssystem-Unterstützung angeboten wurde, lag daran, dass die Anpassungen eines neuen RTOS nur von Kuka selbst durchgeführt werden konnte, die Echtzeit-Erweiterungs-Software speziell an das neue RTOS anzupassen war und Kuka dazu letzlich das RTOS-Know-how und die Ressourcen fehlten.

Mit dem neuen Software-Tool „RTOS Virtual Machine“, welches auf der bevorstehenden Fachmesse „Embedded World 2008“ in Nürnberg vorgestellt wird, hebt Kuka diese Einschränkungen auf. Das heißt: Künftig sind nicht mehr nur VxWorks und Windows CE als RTOS verwendbar, sondern nahezu jedes beliebige x86-RTOS. Auch kann auf der gemeinsamen Steuerungs-Hardware dann nicht mehr nur eine einzige Instanz des RTOS ablaufen, sondern – sofern ein Multicore-Prozessor zur Verfügung steht – auch mehrere Instanzen. Eine weitere denkbare Variante ist, dass die eine Instanz eines Multicore-fähigen RTOS mehrere Cores nutzt.

Was ebenfalls neu ist: Mittels der vorhandenen Dokumentation und der Beispiel-Implementierungen können Anwender der neuen Steuerungsplattform die Anpassungen des RTOS an die VM selbst durchführen. Bei weniger anspruchsvollen Aufgaben ist es zudem vorstellbar, ganz auf ein Echtzeit-Betriebssystem zu verzichten und anhand der Beispiel-Implementierungen einfache Software, wie etwa Echtzeit-Interrupt-Handler, für Windows direkt zu erstellen.

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. gh