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 mini|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., 24. Februar 2009, abgerufen am 21. November 2009
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 mini|CAREEN 68k mini|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.
mini|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.
mini|LC20 mini|hochkant|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., Dedicated Systems Magazine 1997, (PDF 95 kB), abgerufen am 21. November 2009
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.
mini|LP-Real-Time Accelerator Board (RTAcc)