Gemeinsam einsam

Inhaltsverzeichnis

Eingebettete Systeme unterliegen stets einem Kosten- und damit einem Ressourcendruck. Direkte Kosten wie die Stücklistenpreise spielen nach wie vor eine entscheidende Rolle bei der Budgetbildung und der kaufmännischen Kalkulation eines Projekts.

Entwickler setzen gern das lizenzkostenfreie Linux ein, wenn sie komplexe eingebettete Systeme wie Infotainmentgeräte bauen. Im Automobilsektor etwa erfüllt Linux aber ein K.o.-Kriterium nicht: Bei den vorherrschenden Bordnetzen CAN (Controller Area Network) und MOST (Media Oriented Systems Transport) müssen Steuergeräte innerhalb von 50 bis 200 Millisekunden nach dem Einschalten die erste Netzwerknachricht über den eigenen Status verschicken. Linux braucht deutlich länger zum Booten – trotz aller Bemühungen, die Startzeiten zu verkürzen. Selbst das Microkernel-basierte QNX muss die spezielle Technik "Instant Device Activation" bemühen, um die Anforderung zu erfüllen. Dabei wird der Gerätetreiber mit dem Startup-Code verlinkt und kann somit schon die ersten Statusmeldungen versenden, bevor das System die Anwendungen startet.

Dennoch kommt Linux in automobilen Steuergeräten zum Einsatz, etwa in TV-Tunern oder Handyvorbereitungen. Bei solchen Lösungen verwendet man zusätzlich einen Microcontroller mit einem klassischen RTOS wie OSEK, der die Bordnetzanbindung realisiert und Nachrichten für das dahinter geschaltete Linux-System umsetzt. Er startet aus dem ROM oder Flash-Speicher in weniger als 1 ms. Die zwei Systeme kommunizieren über Verbindungen wie I²C, SPI oder RS-232.

Eine kostensparende Variation des Themas besteht darin, beide Systeme auf demselben Prozessor laufenzulassen. Möglich wird das durch eine Virtualisierung, bei der sich zwei gänzlich unterschiedliche Betriebssysteme einen Prozessor teilen.

Vollständige oder Paravirtualisierung

Will man Betriebssysteme unverändert in einer virtuellen Maschine laufen lassen (Full Virtualization), braucht man entweder die Unterstützung des Prozessors oder eine aufwendige Emulation, die die Maschinenbefehle nach privilegierten Instruktionen durchsucht. QEMU etwa hat eine erstaunlich effiziente "Binary Translation"-Technik entwickelt, die den Großteil des Gast-Codes nativ ausführt – allerdings sinkt die Performance trotzdem erheblich.

Im Gegensatz dazu muss man bei der sogenannten Paravirtualisierung Eingriffe ins Betriebssystem vornehmen. Für eingebettete Systeme ist das aber unter Umständen nützlich. So kann der Scheduler des Virtual Machine Monitor (VMM) in das Geschehen eingreifen und eine verschachtelte Priorisierung von Tasks beider Systeme ermöglichen, oder eine Zusage über das Minimum an Rechenzeit für eine VM machen.

Unterstützung des Prozessors muss nicht unbedingt ein Vorteil sein. Eine Untersuchung von VMware-Entwicklern kommt zu gemischten Ergebnissen [1]. Zwar dauert bei Intels zweitem Anlauf, der Core-Architektur, ein Wechsel in den Hypervisor statt 2400 beim Pentium 4 nur noch 930 CPU-Takte – schnell ist das allerdings nicht. Ein VM-Exit nach einem Page Fault dauert ähnlich lange. Techniken wie Intels VT-d oder AMDs IOMMU erweitern die Hardwareunterstützung um Shadow- oder Nested Page Tables, um den Overhead zu verringern. Sie sind bislang aber noch nicht in Embedded-CPUs zu finden. Gerade bei häufigen Kontextwechseln und intensiven I/O-Operationen kann eine Softwarelösung daher ihre Stärken ausspielen.

Virtualisierung maßgeschneidert

Eine Anpassung in Software ist flexibel und erlaubt Optimierungen. In eingebetteten Systemen sind die Anforderungen jedoch unterschiedlich und immer mit der Frage der Kosten verknüpft. Deshalb wählt man in der Regel nicht die flexibelste und deshalb meist aufwendigste Lösung. Spielt zum Beispiel die Isolation zweier Systeme eine untergeordnete Rolle, muss man nur diejenigen Geräte virtualisieren, auf die beide zugreifen.

Ähnlich lässt sich beim Speicherschutz argumentieren. In komplexen Systemen möchte man ihn nicht missen. Der Linux-Kernel kann im privilegierten Modus laufen, den ihm zugewiesenen Speicher selbst verwalten und Prozesse dennoch voreinander schützen. Die Gefahr, das andere System zu "überschreiben", ist vernachlässigbar gering. Der Grad der Isolation ist niedrig, dafür fällt die Anpassung leichter: Die Handhabung der Page Tables kann man unverändert lassen, nur beim Scheduling muss der Hypervisor eingreifen können. Das RTOS zwingt man in einen eigenen Adressbereich, sodass Tasks, die die Grenzen ihres Speicherbereichs verletzen, eine Ausnahme auslösen.

Neben der Konsolidierung der Hardware oder der Unterstützung von Legacy-Systemen spielen zunehmend Sicherheitsaspekte eine Rolle, etwa in Mobiltelefonen, die zwei strikt voneinander getrennte SIM-Profile unterstützen, oder manipulationssicheren Bezahlsystemen. Außerdem wird der Schutz vor Malware, die der Nutzer unbeabsichtigt herunterlädt, immer wichtiger. Eine inzwischen etablierte Lösung bietet zum Beispiel Java. Allerdings zeigt die Erfahrung, dass es schwierig ist, die richtige Balance zwischen Flexibilität und dem Grad der Isolation zu finden.

Bei den quelloffenen Virtualisierern ist zunächst Xen zu nennen, das nicht nur auf Servern mit x86- oder PowerPC-Prozessoren läuft, sondern auch auf der ARM-Plattform. Allerdings ist der Xen-Hypervisor erst vollständig einsatzbereit, wenn die Master-Domain Dom0 läuft, also das Linux. Damit lässt sich nicht die kurze Startzeit eines RTOS erreichen.

Microkernel als Unterbau

Microkernel bieten sich für den Einsatz in der Rolle als Hypervisor an. Sie sind portabel und bereits auf typischen Embedded-Plattformen verfügbar. Die Kommunikation über Domain- oder Partitionsgrenzen hinweg bekommt man mitgeliefert. Ein bekannter quelloffener Vertreter ist der Microkernel L4. Er zeichnet sich durch ein effizientes synchrones Message Passing aus, ebenso wie der QNX-Microkernel. Beide gelten als Microkernel der zweiten Generation – obwohl QNX älter ist als etwa Mach, der bekannteste Vertreter der ersten Generation, der unter anderem die Grundlage für Mac OS X bildet.

Forscher der TU Dresden haben einen L4-kompatiblen Microkernel namens Fiasco neu implementiert. Er bildet die Grundlage für DROPS, das Dresden Real-time Operating System. Diverse weitere Forschungsprojekte beschäftigen sich mit Virtualisierung in eingebetteten Systemen. Das mittlerweile beendete ROBIN-Projekt etwa untersuchte die Machbarkeit eines Hypervisors mit ARMs Trustzone-Technik. Bei eMuCo (Embedded Multi-Core Processing for Mobile Communication) steht die zukünftige Verwendung von Mehrkernprozessoren wie dem ARM Cortex-A8 in mobilen Geräten im Mittelpunkt.

Kommerzielle Virtualisierungslösungen für eingebettete Systeme gibt es schon länger. So bietet Sysgo mit PikeOS einen Isolation Kernel an, der unterschiedliche Systeme voneinander abschottet. Sein Haupteinsatzgebiet ist die Avionik mit ihren hohen Sicherheitsanforderungen.

Auf den Markt für Mobiltelefone hat sich Open Kernel Labs spezialisiert und finanzielles Engagement von Xen-Besitzer Citrix erhalten. Das Unternehmen setzt unter anderem auf einen weiterentwickelten L4-Microkernel und eine Laufzeitumgebung, die den Zugriff mit Capabilities streng reguliert. Weitere Anbieter sind Trango – seit Ende 2008 im Besitz von VMware – und VirtualLogix.

WindRiver bietet für sein VxWorks schon länger einen Hypervisor an – zuerst für die Luft- und Raumfahrt. Jetzt vermarktet das Unternehmen ihn auch für den Automobilsektor. Unter anderem soll bald ein Infotainment-System von Hughes Telematics erscheinen. Außerdem gibt es gemeinsame Entwicklungen mit BMW. Bei beiden kommen VxWorks und Linux zum Einsatz. Für die Entwicklung komplexer Steuergeräte im Auto bietet OpenSynergy mit COQOS eine AUTOSAR-konforme Plattform, die ebenfalls einen Hypervisor nutzt.

Fazit

Nach der raschen Verbreitung der Virtualisierungstechnik in Servern wird man die Technik zunehmend in anderen Marktsegmenten finden. Neben dem großen Markt für Mobiltelefone gibt es Nischen in den Branchen Luft- und Raumfahrt sowie Automotive. Treibender Faktor ist meist die Kostenersparnis bei der Hardware, obwohl zunehmend andere Faktoren eine Rolle spielen, etwa die Sicherheit.

Peter Wächtler
ist freiberuflicher Softwareentwickler mit den Schwerpunkten Linux, QNX und Embedded Systems.

Literatur

[1] Keith Adams, Ole Agesen; A comparison of software and hardware techniques for x86 virtualization; Operating Systems Review, Volume 40, Ausgabe 5, S. 2-13, Dezember 2006 (PDF)

iX-Link (mr)