RTOSVisor

Das ist a) kein Artikel, da schon die Einleitung nicht erklärt worum es geht, sondern gleich irgendwelche unbgelegten Behauptungen aufstellt und b) die Relevanz des Themas wird nicht dargestellt. --WB 06:30, 24. Nov. 2009 (CET)

Aussagen von WB in die Artikel-Diskussion kopiert, wo sie hingehören. So viel habe selbst ich als Wikipedia Neuling schon verstanden... -- Hanky27 08:22, 24. Nov. 2009 (CET)

---

Beteilige dich an der Diskussion!

Dieser Artikel wurde wegen inhaltlicher Mängel auf der Qualitätssicherungsseite der Redaktion Informatik eingetragen. Dies geschieht, um die Qualität der Artikel aus dem Themengebiet Informatik auf ein akzeptables Niveau zu bringen. Hilf mit, die inhaltlichen Mängel dieses Artikels zu beseitigen, und beteilige dich an der Diskussion! (+) Begründung: Übergabe von QS --Jörg der Wikinger 11:54, 23. Nov. 2009 (CET)

Der Einsatz von zwei unterschiedlichen Betriebssystemen auf einem einzigen Computer-System ist immer dann sinnvoll, wenn Steuerungsaufgaben in Echtzeit durchgeführt werden müssen und gleichzeitig der Einsatz von herkömmlichen Informationstechnologien, wie z. B. grafische Benutzeroberflächen, Kommunikation über Netzwerke etc. notwendig ist. Dies ist z. B. in der industriellen Automatisierung, Medizintechnik oder in der Test- und Messtechnik der Fall. Da die Echtzeitbetriebssysteme (RTOS, Real-Time Operating System) hauptsächlich nur für ihren speziellen Einsatzzweck des Echtzeitbetriebes ausgelegt sind, fehlen ihnen meist die Eigenschaften von allgemeinnützlichen Betriebssystemen (GPOS, General-Purpose Operating System). Umgekehrt fehlt GPOS die Echtzeitfähigkeit. Die Kombination von beiden auf einem einzigen Computer-System bringt somit für den Anwender bei gleichen Computer Hardware-Kosten einen erheblichen Mehrwert.

Da die jeweiligen Betriebssysteme von ihren Herstellern grundsätzlich nur dafür ausgelegt sind, alleine auf einem Computer-System abzulaufen, bedarf es also Zusatztechnologien, um das Zusammenarbeiten von mehreren Betriebssystemen auf einem einzigen Computer-System zu ermöglichen.

RTOSVisor ist das jüngste Mitglied einer Familie von solchen Zusatztechnologien, welche seit 1987 die Aufgabe hat, den Einsatz von RTOS und GPOS zusammen auf einem Computer-System zu ermöglichen.

Historie

Im folgenden wird die Historie von RTOSVisor, die damit verbundenen Firmenzusammenhänge und die Namensgebung erläutert.

CAREEN

Die in Weingarten, Deutschland ansässige Firma LP Elektronik GmbH ging aus dem 1985 gegründeten Ingenieurbüro Leibinger&Partner GbR hervor und hat im Jahr ihrer Gründung 1987 einen ECB-Bus Einplatinen-Computer im 10cm x 16cm großen Europaformat mit dem 16Bit Motorola 68000 Microprozessor auf den Markt gebracht. Der Name dieses ersten Produktes war CAREEN, was für Computer für Allgemeinen Rechnereinsatz und Echtzeit-Nutzung stand und an „Karin“, dem Namen der damaligen Freundin eines Entwicklers angelehnt war.

Als Echtzeitbetriebssystem kam OS-9 der US-amerikanischen Firma Microware zum Einsatz. CAREEN 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 von der US-amerikanischen Firma Digital Research war zur damaligen Zeit ein weitverbreitetes Betriebssystem für allgemeine Computer Anwendungen, wofür es bereits damals schon leistungsfähige Programme, wie z. B. den Texteditor WordStar und andere für die Büroumgebung nützliche und leistungsfähig Programme gab. Die erste Intention von CAREEN war es daher, die mächtigen CP/M Software-Werkzeuge auch für OS-9 - zunächst hauptsächlich für die Software-Entwicklung, später auch für Steuerungssysteme - nutzen zu können. In der OS-9 Welt waren Software-Entwicklungswerkzeuge bzw. alles was in der frühen „Personal-Computer-Welt“ weit verbreitet war, sehr spärlich und sehr 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 insbesondere für Steuerungsaufgaben benötigten Echtzeitbetriebssystemen („Echtzeitnutzung“) blieb als Grundidee für alle folgenden Produktfamilienmitglieder erhalten.

Mit dem Erscheinen IBM-PC-kompatibler Computer mit dem Microsoft Betriebssystem MS-DOS und dem dadurch ausgelösten Verschwinden von CP/M wurde eine Adaption sowohl der Hardware (CAREEN-Karte) als auch der Kommunikations-Software notwendig. Hardware-seitig wurde dies durch einen Adapter realisiert, mittels dessen man eine ECB-Karte in einen IBM Personal Computer XT einstecken konnte. Der Bus im IBM 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.

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 16bittigen IBM-PC-AT-Bus. Als Prozessor kam der leistungsfähigere 32Bit 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 HW-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 ebenfalls einen Motorola 68020 Prozessor aufwies – allerdings nun in der Economy-Variante Motorola 68EC020. Das „LC“ stand für „Low Cost“, was sich auch in der höheren Integrationsdichte und weniger Steckplätzen – nur noch ein MEN MUMM-Modul – niederschlug.

Software-seitig wurde dem aufkommenden Microsoft 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 auch für OS-9 mit nutzen zu können. Zusätzlich zu OS-9 wurde ab 1992 begonnen, VxWorks als alternatives Echtzeitbetriebssystem anzupassen. Da VxWorks zum damaligen Zeitpunkt nur mittels UNIX-Workstations entwickelt werden konnte, welche aber aus Kostengründen nicht zur Verfügung standen, wurde zunächst die gesamte zur VxWorks-Entwicklung notwendige GNU Toolchain nach MS-DOS mit dem 32 Bit DOS-Extender DJGPP portiert.

LP-RTWin Toolkit und 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 – wenn das Problem der fehlenden Echtzeitfähigkeit des Windows 3.11 Betriebssystems gelöst werden konnte. MS-DOS war mittlerweile nahezu bedeutungslos geworden.

Das Problem der fehlenden Echtzeitfähigkeit von Windows wurde mittels der nicht sperr-baren Unterbrechungsanforderung (NMI, Non Maskable Interrupt) gelöst, welcher bei jedem PC-Prozessor vorhanden und über die Signale IOCHCK bei XT/AT- und über #SERR bei PCI-Bussen über PC-Einsteckkarten zugänglich sind. Eine einfache und dadurch preiswerte Einsteckkarte mit nur einem einzigen passiven aber programmierbaren Logikbaustein (kein Prozessor) konnte normale, sperr-bare Interrupts der PC-Busse in NMIs umwandeln und dadurch hartes und deterministisches Echtzeitverhalten unter dem Windows Betriebssystem herbeiführen. Diese Karte und der zentrale Chip wurden „LP-Real-Time Accelerator“ oder kurz „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. Auf dieses Verfahren wurde 1994 ein Patent angemeldet, das im Jahre 2000 erteilt wurde. Nachdem die Hardware-Voraussetzungen erfüllt waren, wurde mit dem „LP-RTWin Toolkit“ (Real Time for Windows Toolkit) ein Produkt geschaffen, damit die Kunden durch eigene Programmierung von echtzeitfähigen Interrupt-Behandlungsroutinen die durch Zusatz-Hardware herbeigeführte, harte Echtzeitfähigkeit von Windows selbst anwenden konnten. Erstmalig wurde den Produktnamen „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 LC20

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

Software-seitig konnte der Windows-Anteil der Kommunikationssoftware „WinDOS-9“ weitesthegend beibehalten und erweitert werden.

LP-VxWin RTAcc

Da das Programmieren von echtzeitfähigen Interrupt-Behandlungsroutinen mittels des „LP-RTWin Toolkit“ für Anwendungsfälle nicht ausreichte, bei denen die volle Leistungsfähigkeit eines Echtzeitbetriebssystems erforderlich war, wurde 1994 mit der Portierung von VxWorks auf die Basisfunktionalität des „LP-RTWin Toolkits“ begonnen. Anfang 1995 konnte die Firma KUKA Roboter- und Schweißanlagen (ab 1997 nur KUKA Roboter) für dieses, sich noch in Entwicklung befindliche Produkt als Kunde gewonnen werden. KUKA stellte 1996 auf der Hannover Messe Industrie als Weltneuheit erstmalig 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 immensens 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 ca. 51% an LP Elektronik.

LP-VxWin Lite

Um LP-VxWin auch 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 (generelle Versionsnummer 2.x), welche ohne jegliche Hardware auskam. Dies ist jedoch grundsätzlich nur auf der 32Bit Familie von Microsoft Windows, beginnend mit Windows NT möglich. Während bei der Echtzeiterweiterungstechnik von 16 Bit Windows (3.11., 95, 98 und Millennium) LP Elektronik eine weltweite Monopolstellung innehatte, kamen ab ca. 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 nicht so hoch war, wie bei den anderren, auf Hardware-Technologien basierenden Produktfamilienmitgliedern.

CeWin

Im Jahre 2002 wurde mit CeWin ein Produkt vorgestellt, welches statt VxWorks das Echtzeitbetriebssystem Windows CE von Microsoft verwendete. Da man damit das GPOS Windows 2000 oder XP und das RTOS Windows CE zusammen auf einem Computer betreiben 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, welche dafür umentwickelt werden musste und daher die Generationsversionsnummer 3.x erhielt. 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.

QWin, RTOS32Win, EUROSWin

Neben VxWorks und Windows CE gibt es eine ganze Reihe weiterer Echtzeitbetriebssysteme für Intel x86 Prozessoren. Um diese ebenfalls als Echtzeiterweiterungs-RTOS für Windows mit geringstmöglichen Anpassungsarbeiten nutzen zu können und um Neuentwicklungen im Prozessormarkt wie „Multicore“ und „hardware-unterstützte Virtualisierung“ Rechnung zu tragen (Intel VT-x und AMD-V), wurde 2006 mit der Entwicklung der Generation 4.x der Echtzeiterweiterungsbasistechnologie begonnen. Diese trägt den Familiennamen RTOSWin, was durch den allgemeinen Begriff „RTOS“ statt einem Echtzeitbetriebssystemkürzel zustande kam. RTOSWin basiert auf dem eigens hierfür entwickelten „Virtual Machine Framework“ (VMF), also einem domänenspezifisches Framework für virtuelle Echtzeit-Maschinen, wobei die Programmierschnittstelle des Frameworks, das „VMF-API“ zur Paravirtualisierung der Betriebssysteme verwendet wird. Der „Inhalt“ des Frameworks ist die „RTOS Virtual Machine“, wobei es sich wie bei den Vorgängerversionen um einen Hypervisor vom Typ2 mit erforderlicher Paravirtualisierung der eingesetzten Betriebssysteme handelt.

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

Neben den bereits auf den älteren Technologien eingesetzten RTOSen VxWorks und Windows CE kam 2008 als weiteres RTOS QNX dazu, welches von der Königsbrunner Firma IBV an das VMF durch Paravirtualisierung angepasst worden ist. Zusätzlich erfolgten 2008 Anpassungen von RTOS-32 durch acontis und durch EUROS Embedded Systems.

RTOSLin

Mit diesem Produktfamilienmitglied wurde 2009 erstmals der umgekehrte Weg beschritten: Statt wie bisher nur die Anzahl der RTOSe zu erweitern, wurde erstmalig mit Linux auch ein weiteres GPOS unterstützt. Die Basistechnologie VMF wurde beibehalten, so dass alle RTOSe, welche bisher zur Echtzeiterweiterung für Windows zur Verfügung standen nun auch für den Echtzeiteinsatz unter Linux zur Verfügung stehen.

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

RTOSVisor

Während die Vorgängerversionen einen Hypervisor vom Typ2 darstellten, welche ein vollwertiges Betriebssystem in Form des Desktop-Windows voraussetzten, wurde mit der 5ten Generation der Echtzeiterweiterungsbasistechnologie 2009 ein Hypervisor vom Typ 1 vorgestellt, welcher in das Virtual Machine Framework (VMF) integriert wurde. Dieser ist nicht mehr an Windows oder ein anderes Betriebssystem gebunden. Stattdessen wird das VMF mit dem Hypervisor stand alone gebootet und setzt direkt auf der Hardware auf. Darauf können dann mehrere Instanzen des gleichen RTOS bzw. unterschiedliche RTOSe gleichzeitig ablaufen. Das erste Core kann wie bei den Vorgängerversionen zwischen mehreren Betriebssystemen aufgeteilt werden, um z. B. auf preiswerten Ein-Core-Prozessoren nach wie vor Windows und ein angepasstes RTOS zusammen auf einem Prozessor mit nur einem einzigen Core ablaufen lassen zu können.

Die hardware-unterstützte Virtualisierung (Intel Intel Virtualization Technology|VT-x und AMD-V) ist durch die beibehaltene Paravirtualisierung für die RTOSe nach wie vor nicht erforderlich. Bei hartem Echtzeitbetrieb darf die hardware-unterstützte Virtualisierung für die RTOSe nicht angewendet werden, da die Echtzeit-Performance darunter bis zur Unbrauchbarkeit leiden würde. Vielmehr muss den RTOSen, welche Hardware-Geräte in Echtzeit ansteuern sollen, der Zugriff auf die jeweilige Hardware direkt erlaubt werden, was mit der Aussage „Partition where we can, virtualize where we must“ treffend beschrieben ist.

Die hardware-unterstützte Virtualisierung wird erst dann zwingend notwendig, wenn nicht paravirtualisierbare GPOSe (wie z. B. Windows oder Linux) zusätzlich betrieben werden sollen und bei diesen die Echtzeit-Performance keine wichtige Rolle spielt. Damit die Performance der GPOS dennoch akzeptabel bleibt, kommen Techniken wie PCI- oder VGA- Passthrough zur Anwendung.

Der Name RTOSVisor entstand 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 Marktbegeleitern ein großer Hype um dieses Thema entfacht worden ist, welches von dieser Produktfamilie bereits seit langem abgedeckt wurde.

Weblinks

• CPM
• acontis technologies
• KUKA Roboter
• KUKA Real Time