RTOSVisor

RTOSVisor ist eine Software des Unternehmens acontis technologies, um gleichzeitig mehrere Echtzeitbetriebssysteme (RTOS, Real Time Operating System) und andere Betriebssysteme (GPOS, General-Purpose Operating System, z. B. Windows und Linux) auf einem Computer mit Multicore-Prozessor betreiben zu können. Damit werden sowohl Aufgaben der Steuerungs- oder Regelungstechnik in Echtzeit durchgeführt, als auch der Einsatz allgemeiner Techniken wie grafische Benutzeroberflächen und Netzwerk- oder Datenbank-Verbindungen ermöglicht. Die Verbindung beider Aufgabengebiete ist häufig in der industriellen Automatisierung, Medizintechnik oder in der Test- und Messtechnik notwendig.

Eigenschaften

RTOSVisor Übersicht

RTOSVisor stellt die fünfte Software-Generation dar und besteht hauptsächlich aus dem echtzeitfähigen RTOS-VM Hypervisor und den RTOS-Virtual Machines (VM). Diese sind im RTOS Virtual Machine Framework (VMF) zusammengefasst (siehe Bild). Der RTOS-VM-Hypervisor nutzt wie jeder andere Type-2-Hypervisor die Gerätetreiber des Betriebssystems, auf dem er abläuft. Wenn der Hypervisor wie bei der Vorgängergeneration direkt das Anwender-GPOS nutzt, kann dieses nicht unabhängig vom Hypervisor und den RTOS neu gestartet werden. Da diese Unabhängigkeit in der Praxis gelegentlich eine Anforderung darstellt, wurde 2009 von acontis technologies RTOSVisor vorgestellt. Dabei ist das Anwender-GPOS nicht identisch mit dem Hypervisor-Betriebssystem und die beiden Betriebssysteme sind somit voneinander unabhängig. Als Hypervisor-Betriebssystem kommt in der ersten Version ein auf ein Minimum reduziertes Linux-Betriebssystem ohne Grafikoberfläche („Headless“) zum Einsatz. Dieses wird als erstes gebootet, lädt und startet dabei die RTOS-Virtual Machines samt RTOS-VM-Hypervisor. Auf diesen Grundumfang aufbauend können zunächst eine oder mehrere Instanzen des gleichen oder unterschiedliche RTOS ablaufen.

Die erst in jüngerer Zeit in Intel- und AMD-Prozessoren eingeführten hardwareunterstützten Virtualisierungen Intel VT oder AMD-V sind für den alleinigen RTOS-Betrieb durch die zu den Vorgängerversionen kompatibel beibehaltene Paravirtualisierung der RTOS nicht erforderlich. Bei gefordertem harten Echtzeitbetrieb darf die hardwareunterstützte Virtualisierung auf die RTOS nicht angewendet werden, da die Echtzeitfähigkeit durch die „Vorspiegelung“ von Hardware und der sich daraus ergebenden notwendigen Verwaltungsarbeiten leiden würde. Daher muss den RTOS, welche Hardware in Echtzeit ansteuern soll, der Zugriff auf die jeweilige Hardware, Speicher und Prozessor-Cores direkt und exklusiv erlaubt werden. Dadurch entstehen für jedes RTOS sogenannte Partitionen. Diese Vorgehensweise kann mit der Aussage „Partition where we can, virtualize where we must“ treffend beschrieben werden. Intel VT oder AMD-V wird bei RTOSVisor erst notwendig, wenn zusätzlich zu den RTOS ein oder mehrere nicht echtzeitfähige GPOS (wie z. B. Windows oder Linux) betrieben werden sollen. Für diese Betriebsart wird das minimale Linux-Betriebssystem um die weit verbreiteten Open Source Software-Komponenten KVM und QEMU erweitert. Der Linux-Kernel, KVM und QEMU unterliegen der GPL und sind als solche kein kommerzieller Bestandteil von RTOSVisor. Sie bilden lediglich eine Infrastruktur, in denen nicht echtzeitfähige GPOS zusätzlich zu den echtzeitfähigen RTOSVisor-Komponenten inklusive der RTOS ablaufen können. In zukünftigen RTOSVisor-Versionen können Linux, KVM und QEMU gegen andere Mainstream GPOS-Virtualisierungslösungen wie beispielsweise Microsoft Hyper-V ausgetauscht werden.

Damit die Performance der GPOS trotz Virtualisierung akzeptabel bleibt, kommen Techniken wie PCI- oder VGA-Pass Through zur Anwendung. Dabei erhält das GPOS ebenso wie die RTOS direkten Zugriff auf anzusteuernde Hardware wie Grafik oder Festplatte.

Das erste Core kann wie bei der Vorgängergeneration zwischen einem GPOS- und einem RTOS-Betriebssystemen aufgeteilt werden. Dadurch können Windows oder Linux zusammen mit einem RTOS auf preiswerten Prozessoren mit nur einem einzigen Core betrieben werden.

Die Kommunikation zwischen dem GPOS und den RTOS kann durch direkte Shared Memory Zugriffe stattfinden, welche über entsprechende VMF-API-Aufrufe verwaltet werden. Eine weitere Möglichkeit besteht durch ein virtuelles Netzwerk, bei dem jedes Betriebssystem seine eigene IP-Adresse erhalten kann.

Der Name „RTOSVisor“ entstand aus „RTOSWin“ durch Beibehalten des Begriffes „RTOS“ und Austauschen von „Win“ gegen „Visor“. Das Weglassen von „Hyper“ aus „Hypervisor“ trug der Tatsache Rechnung, dass aus Marketing-Gründen von vielen neu aufkommenden Marktbegleitern ein großer Hype um dieses Thema entfacht worden ist, welches von der hier beschriebenen Produktfamilie bereits seit langem abgedeckt wird.

Im Rahmen eines Outsourcing-Vertrages erwirbt acontis technologies 2010 von KUKA Roboter die exklusiven Rechte, die KUKA Roboter Echtzeit-Software selbständig weiterzuentwickeln und zu vermarkten.

Entwicklungsgeschichte

Im Folgenden werden die Entwicklungsgeschichte von RTOSVisor, die damit verbundenen Firmenzusammenhänge und die Namensgebung erläutert.

Aktive Einsteckkarten

CAREEN 68k

CAREEN 68k

CAREEN 68k/PC Paket mit XT-Adapter

1987 stellte LP Elektronik GmbH, welche aus der 1986 gegründeten Leibinger & Partner GbR hervorgegangen war, einen Europe Card Bus (ECB) Einplatinen-Computer im 10 cm × 16 cm großen Europaformat mit dem 16-Bit Motorola 68000 Mikroprozessor vor. Der Name dieses ersten Produktes war CAREEN 68k, was für Computer für Allgemeinen Rechnereinsatz und Echtzeit-Nutzung mit Motorola-68000-Prozessor stand. Als Echtzeitbetriebssystem kam OS-9 des US-amerikanischen Unternehmens Microware zum Einsatz. CAREEN 68k konnte zusätzlich in ein ECB-Einschubgehäuse gesteckt werden, in dem sich ein auf Intel 8080 oder Zilog Z80 basierter CP/M-Rechner befinden musste. CP/M des US-amerikanischen Unternehmens Digital Research war zur damaligen Zeit ein weitverbreitetes Betriebssystem für allgemeine Computer Anwendungen. Für CP/M gab es leistungsfähige Programme, wie den Texteditor WordStar und andere für die Büroumgebung nützliche und leistungsfähig Programme. Die erste Intention von CAREEN 68k war es daher, die mächtigen CP/M-Software-Werkzeuge für OS-9 nutzen zu können. Zunächst nur für die Software-Entwicklung, später zusätzlich für Steuerungssysteme. In der OS-9-Welt waren Software-Entwicklungswerkzeuge und alles was in der frühen „Personal-Computer-Welt“ weit verbreitet war, sehr spärlich und speziell (z. B. vi oder Emacs als Editor). Diese Kombination von aus der Mainstream-Bürowelt stammenden, mächtigen und weit verbreiteten Software-Werkzeugen („allgemeiner Rechnereinsatz“) mit Echtzeitbetriebssystemen („Echtzeitnutzung“) blieb als Grundidee für alle folgenden Produktfamiliengenerationen erhalten.

CARREN 68k AT-Adapter ohne gesteckte CAREEN 68k

Mit dem Erscheinen IBM-PC-kompatibler Computer mit dem Microsoft-Betriebssystem MS-DOS und dem dadurch ausgelösten Niedergang von CP/M wurde eine Adaption sowohl der CAREEN 68k-Hardware-Karte als auch der Kommunikations-Software notwendig. Hardwareseitig wurde dies durch einen Adapter realisiert, mit dem eine ECB-Karte in einen IBM-PC XT oder kompatiblen eingesteckt werden konnte. Der Bus im XT-PC war lediglich 8 Bit breit, was ein gewisses Nadelöhr in der Kommunikation darstellte. Softwareseitig wurde die Kommunikations-Software von CP/M nach MS-DOS portiert, wobei der OS-9 Teil weitestgehend beibehalten wurde. Dieses Software-Paket erhielt den Namen „DOS-9“, was durch ein Zusammenfließen der beiden Betriebssystemnamen „DOS“ und „OS-9“ zustande kam. Das Bundle aus Hard- und Software wurde als CAREEN-68k/PC-Paket angeboten.

Um das Nadelöhr in der Kommunikation zu beseitigen, wurde für die IBM-PC/AT kompatiblen Computer der AT-Adapter aufgelegt. Mit diesem waren durch Busmastering bidirektionale Speicherzugriffe von dem jeweils einen System in das andere hinein auch auf Zusatzkarten und I/O-Ports des PC möglich. Der AT-Adapter wies zwei Steckplätze für bis zu zwei Eltec-IPIN-Erweiterungsmodule auf, welche der hardwarespezifischen Erweiterung dienten und deren Anschlüsse an den Steckkartenblechen nach außen geführt waren.

Diese, durch aktive Zusatz-Hardware herbeigeführte „Echtzeiterweiterung“ von herkömmlichen Computersystemen, stellte die erste Generation der Produktfamilie dar.

LC20

C20

C20

Die C20 (kurz für CAREEN 68020) kam 1989 auf den Markt und war eine lange PC-Einsteckkarte ohne ECB-Busanschluss, stattdessen mit einem direkten Stecker für den 16-bit-IBM-PC-AT-Bus. Als Prozessor kam der leistungsfähigere 32-Bit-Motorola-68020-Prozessor und weiterhin OS-9 als Betriebssystem zum Einsatz. Die C20 hatte zwei Steckplätzen für bis zu zwei Eltec IPIN-Erweiterungsmodule, welche zur Hardware-spezifischen Erweiterung der C20-Karte dienten und deren Anschlüsse an den Steckkartenblechen nach außen geführt waren.

LC20

LC20 war der Name des C20-Nachfolgers, welcher 1991 auf den Markt kam und einen Motorola-68EC020-Economy-Prozessor aufwies. Das „LC“ stand für „Low Cost“, was sich in der höheren Integrationsdichte und weniger Erweiterungssteckplätzen niederschlug.

Softwareseitig wurde dem aufkommenden Windows Rechnung getragen und der Produktname „DOS-9“ wurde zu „WinDOS-9“ erweitert. Mit diesem Produkt wurde es möglich, alle in Windows zur Verfügung stehenden Werkzeuge für OS-9 mit benutzen zu können. Zusätzlich zu OS-9 wurde ab 1992 begonnen, VxWorks als alternatives Echtzeitbetriebssystem anzupassen. Da VxWorks zum damaligen Zeitpunkt nur mittels sehr teuren Unix-Workstations entwickelt werden konnte, wurde zunächst die gesamte zur VxWorks-Entwicklung notwendige GNU Toolchain nach MS-DOS und dem 32-Bit-DOS-Extender DJGPP portiert.

VxWin LC20

Im Jahre 1994 wurde für die LC20 zusätzlich zu OS-9 auch VxWorks als alternatives Echtzeitbetriebssystem angeboten. Dafür wurde erstmals der Name „VxWin“ kreiert, der durch das Zusammenziehen von VxWorks und Windows generiert wurde. Der Name „WinDOS-9“ konnte jedoch naheliegender Weise nicht mehr beibehalten werden. VxWin LC20 bezeichnete sowohl die Hardware- als auch die Software-Komponenten.

Softwareseitig konnte der Windows-Anteil der Kommunikationssoftware „WinDOS-9“ weitestgehend beibehalten und erweitert werden.

Passive PC-Einsteckkarten

LP-Real-Time Accelerator

Um nach wie vor das Ziel erreichen zu können, die Office-Mainstream-Welt und die spezialisierten Welten von Echtzeitbetriebssystemen zusammenzubringen, wurde wegen der Krise im deutschen Maschinenbau im Jahre 1992 ein radikaler Neuansatz notwendig. Einsteckkarten mit aktiven Zusatzprozessoren wurden zu teuer. Es musste eine Lösung gefunden werden, das gleiche Ziel mit deutlich geringeren Kosten zu erreichen. Dank des Mooreschen Gesetzes war die Rechenleistung der PC-Prozessoren zum damaligen Zeitpunkt bereits so groß geworden, dass sie die Rechenarbeit der teuren Zusatzprozessoren mit übernehmen konnten. Dazu musste jedoch das Problem der fehlenden Echtzeitfähigkeit des Windows-3.11-Betriebssystems gelöst werden. Dieses wurde mittels der nicht sperrbaren Unterbrechungsanforderung (NMI, Non Maskable Interrupt) gelöst, der bei jedem PC-Prozessor vorhanden und über die Signale IOCHCK bei XT/AT- und über SERR bei PCI-Bussen über PC-Einsteckkarten zugänglich ist.

LP-Real-Time Accelerator Board (RTAcc)

Eine einfache und preiswerte Einsteckkarte mit nur einem einzigen passiven programmierbaren Logikbaustein konnte normale sperrbare Interrupts der PC-Busse in NMIs umwandeln und dadurch hartes und deterministisches Echtzeitverhalten unter dem Windows-Betriebssystem herbeiführen. Auf dieses Verfahren wurde 1994 ein Patent angemeldet, das im Jahre 2000 erteilt wurde. Die Karte und der zentrale Chip wurden LP-Real-Time Accelerator (LP-RTAcc) genannt („Echtzeitbeschleuniger“). Neben dieser Funktionalität eines Interrupt Controllers für ineinander verschachtelbare (nested) NMIs wies der RTAcc Chip einen programmierbaren Timer auf, um zusätzlich einen periodischen Echtzeitinterrupt mit programmierbarer Zykluszeit generieren zu können.

Nachdem die Hardware-Voraussetzungen erfüllt waren, wurde mit dem LP-RTWin Toolkit (Real Time for Windows Toolkit) ein Produkt geschaffen, mit dem die Kunden durch eigene Programmierung von echtzeitfähigen Interrupt-Behandlungsroutinen die harte Echtzeitfähigkeit von Windows selbst anwenden konnten. Zusätzlich wurde erstmals mit Linux experimentiert, um es über den NMI ebenfalls hart echtzeitfähig zu machen. Dies konnte aus Ressourcengründen jedoch nicht weiter verfolgt werden.

Alle auf LP-RTAcc basierenden Produkte bildeten die zweite Generation und es wurde den Produktnamen erstmals „LP“ vorangestellt. Dies geschah in Anlehnung an Microsoft, welches ebenfalls allen ihren Produkten „MS“ vorangestellt hatte (MS-DOS, MS-Windows, MS-Word etc.).

LP-VxWin RTAcc

Das Programmieren von echtzeitfähigen Interrupt-Behandlungsro utinen mittels des LP-RTWin Toolkit reichte für Anwendungsfälle nicht aus, bei denen die volle Leistungsfähigkeit eines Echtzeitbetriebssystems erforderlich war. Deshalb wurde 1994 mit der Portierung von VxWorks auf die Basisfunktionalität des LP-RTWin Toolkits begonnen, wodurch LP-VxWin RTAcc entstand. Anfang 1995 konnte das Unternehmen KUKA-Roboter- und Schweißanlagen GmbH für dieses, sich noch in Entwicklung befindliche Produkt als Kunde gewonnen werden. KUKA stellte 1996 auf der Hannover Messe Industrie als Weltneuheit erstmals eine auf Windows95-PC-basierende Steuerung für ihre Industrieroboter vor.

Diese auf LP-VxWin RTAcc aufbauende Robotersteuerung mit Windows-Benutzeroberfläche war der Begründer des immensen Geschäftserfolges, welchen KUKA Roboter seit 1996 aufweisen kann. Um diese Technologie für sich abzusichern, beteiligte sich KUKA Roboter noch im selben Jahr mit etwa 51 % an LP Elektronik GmbH.

Echtzeiterweiterungen

LP-VxWin Lite

Zustandsmaschine der Echtzeiterweiterungstechnik

Um LP-VxWin auf Computern einsetzen zu können, welche keine Steckmöglichkeit für die RTAcc-Technologie aufweisen konnten (z. B. tragbare Laptop-Computer), wurde 1997 mit der Entwicklung einer Echtzeiterweiterungstechnologie begonnen, die wie alle folgenden Generationen ohne jegliche Hardware auskam und damit die dritte Generation begründete. Diese Echtzeit-Erweiterung alleinig durch Software ist grundsätzlich nur auf der 32-Bit-Familie von Microsoft Windows, beginnend mit Microsoft Windows NT möglich. Während bei der Echtzeiterweiterungstechnik von 16-Bit-Windows (3.11, 95, 98 und Millennium) mittels des NMI-LP-Elektronik eine weltweite Monopolstellung innehatte, kamen ab 1996 mehrere andere Wettbewerber hinzu, welche ebenfalls Echtzeiterweiterungstechnologien für die 32-Bit-Windows-Familie anboten.

Der Zusatz „Lite“ sollte andeuten, dass die Echtzeitfähigkeit bei diesem Produkt zunächst nicht so hoch war, wie bei den anderen, auf Hardware-Technologien basierenden Produktfamilienmitgliedern. Dieses Manko wurde jedoch bald daraufhin eliminiert.

CeWin und VxWin

Im Jahre 2002 wurde mit CeWin ein Produkt vorgestellt, das statt VxWorks das Betriebssystem Windows CE von Microsoft verwendete. Windows CE stellt ab der Version 3 ein vollwertiges Echtzeitbetriebssystem dar. Da damit das GPOS Windows 2000 oder XP und das RTOS Windows CE zusammen auf einem Computer betrieben werden konnte, hatten die Anwender den Vorteil in beiden Welten ausschließlich mit Microsoft-Produkten und -Technologien arbeiten zu können.

Der Name CeWin entstand aus dem zusammenziehen von „Windows CE“ und „Windows 2000“ und basierte auf derselben Echtzeiterweiterungsbasistechnologie wie VxWin.

Da im selben Jahr KUKA Roboter LP Elektronik vollständig übernommen und in KUKA Controls umbenannt hatte, wurde auf die Voranstellung von „LP“ vor den Produktnamen verzichtet.

Virtual Machines mit Hypervisor

RTOSWin

RTOSWin Übersicht

Neben VxWorks und Windows CE gibt es eine ganze Reihe weiterer Echtzeitbetriebssysteme für Intel-X86-Prozessoren. Um diese ebenfalls als RTOS zusammen mit Windows und geringstmöglichen Anpassungsarbeiten nutzen zu können und um Neuentwicklungen im Prozessormarkt wie „Multicore“ Rechnung zu tragen, wurde 2006 mit der Entwicklung der vierten Produktgeneration begonnen. Diese erhielt den Familiennamen RTOSWin, was durch den allgemeinen Begriff „RTOS“ statt eines Echtzeitbetriebssystemkürzels zustande kam. RTOSWin basiert auf dem eigens hierfür entwickelten „Virtual Machine Framework“ (VMF), also einem domänenspezifischen Framework für virtuelle Echtzeit-Maschinen, wobei die Programmierschnittstelle des Frameworks, das „VMF-API“ zur Paravirtualisierung der Betriebssysteme verwendet wird. Der „Inhalt“ des Frameworks sind die „RTOS Virtual Machines“ und der „RTOS-VM Hypervisor“. Dabei handelt es sich um einen Hypervisor vom Typ 2 mit erforderlicher Paravirtualisierung der eingesetzten Betriebssysteme und Windows als gleichzeitigem Hypervisor-Betriebssystem und GPOS.

Die Entwicklung dieser Generation 4 und somit des Virtual Machine Framework (VMF) wurde nach der Standortschließung von KUKA Controls, Weingarten und der Eingliederung in KUKA Roboter Anfang 2006 an die ebenfalls in Weingarten ansässige acontis technologies GmbH komplett als Dienstleistungsauftrag vergeben. acontis technologies GmbH konnte als Spin Off der ehemaligen LP-Elektronik-Expertise mit den technischen Grundlagen aufweisen.

Neben den bereits auf den älteren Technologien eingesetzten RTOS VxWorks und Windows CE kam 2008 als weiteres RTOS QNX dazu, welches von der Königsbrunner Firma IBV an das VMF durch Paravirtualisierung angepasst wurde und unter dem Namen QWin vertrieben wird. Zusätzlich erfolgten 2008 Anpassungen von On Time RTOS-32 durch acontis (RTOS32Win) und durch EUROS Embedded Systems (EUROSWin).

RTOSLin

RTOSLin Übersicht

Mit RTOSLin wurde 2009 erstmals ein umgekehrter Weg beschritten: Statt wie bisher nur die Anzahl der RTOS zu erweitern, wurde erstmals mit Linux auch ein weiteres GPOS unterstützt. Die Basistechnologie VMF wurde beibehalten, so dass alle RTOS, welche bisher mit Windows kombiniert werden konnten, nun auch für den Echtzeiteinsatz unter Linux zur Verfügung stehen. Die Familienmitglieder im Einzelnen ergeben sich also zu VxLin, CeLin, QLin, RTOS32Lin und EUROSLin.

Der Name RTOSLin wurde dadurch generiert, dass „Lin“(von Linux) statt „Win“(von Windows) hinten angestellt wurde.

Weblinks

• Gerade echtzeitig, Linux-Magazin 6/2008
• KVM-Projekt
• QEMU opensource processor emulator
• acontis technologies GmbH
• KUKA Roboter