RTOSVisor

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)

RTOSVisor ist eine Software-Technologie, welche in der Fachsprache als Echtzeit-Hypervisor (bzw. Real-Time Hypervisor) bezeichnet wird und eine Untergruppe der Embedded Hypervisor darstellt, was wiederum eine Untergruppe der Hypervisor ist.

Im Allgemeinen ermöglicht ein Hypervisor den gleichzeitigen Einsatz von mehreren Betriebssystemen auf einem einzigen Computer-System. Da die jeweiligen Betriebssysteme von ihren Herstellern grundsätzlich dafür ausgelegt sind, alleine auf einem Computer-System abzulaufen, bedarf es bei gewünschtem gleichzeitigen Einsatz von mehreren Betriebssystemen der übergeordneten Verwaltungsinstanz "Hypervisor", welche diese Koexistenz mehrerer Betriebssysteme auf einem Computer-System organisiert und verwaltet.

Eine Spezialisierung ergibt sich, wenn eines oder mehrere der zum Einsatz kommenden Betriebssysteme ein Echtzeitbetriebssystem (RTOS, Real-Time Operating System) darstellen und dessen Echtzeiteigenschaften bei dem gemeinsamen Betrieb beibehalten werden sollen. Man spricht dann von einem so genannten Echtzeit-Hypervisor.

Einsatz

Der gleichzeitige Einsatz eines Echtzeitbetriebssystems zusammen mit einem "normalen" Betriebssystem (GPOS, General-Purpose Operating System) auf einem einzigen Computer-System ist immer dann sinnvoll, wenn Steuerungstechnik- oder Regelungstechnikaufgaben in Echtzeit durchgeführt werden müssen und gleichzeitig der Einsatz von herkömmlichen Informationstechnologien, wie z. B. weitverbreitete und akzeptierte grafische Benutzeroberflächen, Kommunikation über Netzwerke, Zugriff auf Datenbanken, etc. notwendig ist. Dies ist unter anderem in der industriellen Automatisierung, Medizintechnik oder in der Test- und Messtechnik häufig der Fall. Während die Echtzeitbetriebssysteme hauptsächlich für ihren speziellen Einsatzzweck des Echtzeitbetriebes ausgelegt werden, sind bei diesen die Eigenschaften von allgemeinnützlichen Betriebssystemen meist unterentwickelt. Umgekehrt ist die Echtzeitfähigkeit bei GPOS oft sehr schlecht ausgebildet, bzw. fehlt völlig. Die Kombination von beiden auf einem einzigen Computer-System, was dadurch zu einem Echtzeit-Computer-System wird, bringt somit für den Anwender einen erheblichen Mehrwert bei gleichen Hardware-Kosten .

RTOSVisor

RTOSVisor ist wie seine Vorgängerversionen aus der RTOSWin- und RTOSLin-Familie (siehe Entwicklungsgeschichte) eine Software, welche unter anderem einen Hypervisor vom Typ2 beinhaltet. Dieser Typ ist dadurch gekennzeichnet, dass er die Gerätetreiber eines Betriebssystems nutzt, unter dem er abläuft. Bei der RTOSWin- und RTOSLin-Familie läuft der Hypervisor direkt unter dem Anwender-GPOS ab und verwendet dessen Gerätetreiber. Dadurch ist das Anwender-GPOS nicht vom Hypervisor unabhängig und kann nicht unabhängig von diesem neu gestartet werden. Da diese Unabhängigkeit von Hypervisor und Anwender-GPOS jedoch in der Praxis gelegentlich eine Anforderung darstellt, wurde mit der 5ten Generation 2009 von acontis technologies ein Software-System vorgestellt, bei dem das Anwender-GPOS und das Hypervisor-Betriebssystem getrennt und voneinander unabhängig sein können. Als Hypervisor-Betriebssystem kommt ein auf ein Minimum reduziertes Linux-Betriebssystem zum Einsatz, welches stand alone gebootet wird und dabei die RTOS Virtual Machine der Vorgängerversion samt Hypervisor lädt und startet. Auf diesen Grundumfang aufbauend, können dann zunächst eine oder mehrere Instanzen des gleichen RTOS bzw. unterschiedliche RTOS gleichzeitig ablaufen.

Die erst in jüngerer Zeit in Intel- bzw. AMD-Prozessoren eingeführten hardware-unterstü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 und werden für die Vorgängerversionen auch nach wie vor nicht verwendet. Bei gefordertem harten Echtzeitbetrieb darf die hardware-unterstützte Virtualisierung auf die RTOS so wie so nicht angewendet werden, da die Echtzeitfähigkeit durch die "Vorspiegelung" von Hardware und der sich daraus ergebenden notwendigen Verwaltungsarbeiten leiden würde. Besser ist es, den RTOS, welche Hardware-Geräte in Echtzeit ansteuern sollen, den Zugriff auf die jeweilige Hardware direkt zu erlauben. 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 dann wirklich notwendig, wenn zusätzlich zu den RTOS ein oder mehrere nicht echtzeitfähige GPOS (wie z.B. Windows oder Linux) betrieben werden sollen. Damit die Performance der GPOS trotz Virtualisierung akzeptabel bleibt, kommen Techniken wie PCI- oder VGA- Passthrough zur Anwendung. Für diese Betriebsart wird das minimale Linux-Betriebssystem um KVM und QEMU erweitert

Das erste Core kann wie bei den Vorgängerversionen zwischen einem RTOS- und einem GPOS-Betriebssystemen aufgeteilt werden, um z.B. auf preiswerten Ein-Core-Prozessoren nach wie vor Windows bzw. Linux und ein angepasstes RTOS zusammen auf einem Prozessor mit nur einem einzigen Core ablaufen lassen zu können.

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

Entwicklungsgeschichte

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

CAREEN 68k

CAREEN 68k

1987 stellte LP Elektronik GmbH, welche aus der 1986 gegründeten Leibinger & Partner GbR hervorgegangen war, einen ECB-Bus Einplatinen-Computer im 10cm x 16cm großen Europaformat mit dem 16-Bit Motorola 68000 Microprozessor 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 der US-amerikanischen Firma 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 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 68k 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.

CARREN 68k AT-Adapter ohne gesteckte CAREEN 68k

CAREEN 68k/PC Paket mit XT-Adapter

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. Hardware-seitig wurde dies durch einen Adapter realisiert, mittels dessen eine ECB-Karte in einen IBM Personal Computer XT oder kompatible 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 Personal Computer/AT kompatiblen Computer der AT-Adapter aufgelegt. Mit diesem waren durch Bus Mastering 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 hardware-spezifischen Erweiterung dienten und deren Anschlüsse an den Steckkartenblechen nach außen geführt waren.

Diese, durch aktive Zusatz-Hardware herbeigeführte "Echtzeit-Erweiterung" von herkömmlichen Computer-Systemen, 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 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 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 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 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. Das Problem der fehlenden Echtzeitfähigkeit von Windows wurde mittels der nicht sperrbaren 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.

LP-Real-Time Accelerator Board (RTAcc)

Eine einfache und dadurch preiswerte Einsteckkarte mit nur einem einzigen passiven aber programmierbaren Logikbaustein konnte normale, sperrbare 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 (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, welches 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.

Alle auf LP-RTAcc basierende Produkte bildeten die zweite Generation.

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“ weitestgehegend 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, wodurch LP-VxWin RTAcc entstand . Anfang 1995 konnte die Firma 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 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 GmbH.

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, welche 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 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) mittels des NMI 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 zunächst nicht so hoch war, wie bei den anderen, auf Hardware-Technologien basierenden Produktfamilienmitgliedern. Dieses Manko wurde jedoch sehr bald eliminiert.

CeWin und VxWin

Im Jahre 2002 wurde mit CeWin ein Produkt vorgestellt, welches statt VxWorks das Betriebssystem Windows CE von Microsoft verwendete, welches seit der Version 3 auch ein vollwertiges Echtzeitbetriebssystem darstellt. 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.

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“ Rechnung zu tragen, wurde 2006 mit der Entwicklung der nächsten Generation 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ä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 ist die „RTOS Virtual Machine“, wobei es sich wie bei den Vorgängerversionen um einen Hypervisor vom Typ2 mit erforderlicher Paravirtualisierung der eingesetzten Betriebssysteme und Windows als Hypervisor-Betriebssystem und GPOS handelt.

Die Entwicklung dieser Generation 4 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 ebenfalls in Weingarten ansässige acontis technologies GmbH 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 On Time RTOS-32 durch acontis und durch EUROS Embedded Systems.

RTOSLin

Mit diesem Produktfamilienmitglied wurde 2009 erstmals ein umgekehrter Weg beschritten: Statt wie bisher nur die Anzahl der RTOS zu erweitern, wurde erstmalig mit Linux auch ein weiteres GPOS unterstützt. Die Basistechnologie VMF wurde beibehalten, so dass alle RTOS, 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 nun „Lin“(von Linux) statt „Win“(von Windows) hinten angestellt wurde.

Weblinks

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