Mehr Sicherheit oder bessere Systemauslastung: das leistet Virtualisierung für Embedded-Systeme

Virtualisierung im Embedded-Umfeld

27. April 2007, 13:52 Uhr | Thomas Dietrich
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Zwei Betriebssysteme auf einer Maschine: ohne Virtualisierung aufwendig

Obwohl die grafische Benutzeroberfläche von Windows oder Linux die Steuerungsanforderungen für Medizin- oder Industriegeräte erfüllt, sind die Antwortzeiten der Applikationen oft nicht mehr akzeptabel. Die durchschnittliche Interrupt-Wartezeit eines General-Purpose-Betriebssystems liegt mit 5 bis 20 ?s durchaus noch im Rahmen. Doch ein System muss auf die Worst-Case-Wartezeit ausgelegt sein, die jedoch weder bei Windows noch bei Linux vorhersagbar ist. Der Scheduling-Algorithmus dieser Betriebssysteme bietet nicht genügend Echtzeit-Funktionen an.

Das Verhalten des Schedulers wirkt sich auch direkt auf die Bedienung der Interrupts aus. Wenn ein kritischer Prozess gesteuert werden soll, müssen die entsprechenden Geräte-Interrupts innerhalb einer vorgegebenen Zeitspanne bedient werden. Bei General-Purpose-Betriebssystemen kann das nicht garantiert werden, weil jederzeit andere Tasks oder Prozesse mit hoher Priorität Vorrang bekommen können. Die Kernel dieser Betriebssysteme enthalten auch kritische Segmente, die nicht unterbrechbar sind, so dass sämtliche Interrupts während dieser Zeit deaktiviert werden. Die Worst-Case-Wartezeit für einen Interrupt kann sich damit um die Ausführungszeit für das längste kritische Code-Segment verlängern.

Heute gibt es mehrere Lösungen, um Echtzeit und Visualisierung auf einem System gemeinsam zu betreiben. Ein Lösungsansatz ist ein Echtzeit-Kernel, wobei das echtzeit-unkritische Betriebssystem mit dem Benutzerinterface in einem kompletten Thread abläuft. Eine definierte Programmierschnittstelle erlaubt dem General-Purpose-Betriebssystem, mit dem Echtzeit-Kernel zu kommunizieren. Falls Thread-Scheduling benötigt wird, kann die Applikation im General-Purpose-Betriebssystem den Thread-Mechanismus des Echtzeit-Kernels benutzen.

Ein anderer Ansatz ist, einen kleinen Echtzeit-Kernel zusammen mit einem General-Purpose-Betriebssystem aufzusetzen. Beide Betriebssysteme teilen sich die CPU, den Speicher und den Interrupt-Controller. Hier jedoch hat jeder Kernel seinen eigenen Kontext (Descriptor-Tabellen, Speicherverwaltung etc.). Der Echtzeit-Kernel muss feststellen, wann bestimmte Prozesse abgearbeitet werden müssen, um die Deterministik zu wahren. Er überwacht auch die Interrupt-Zuweisung, damit das Verhalten des Systems nicht beeinflusst wird. Wenn ein Interrupt für das General-Purpose-Betriebssystem während der Ausführung einer Echtzeit-Task auftritt, dann wird der Echtzeit-Kernel diese Task zu Ende führen und anschließend das General-Purpose-Betriebssystem aufrufen, das dann den Interrupt bedienen kann.

Diese Ansätze haben sich zwar bewährt, dennoch kann man zusammenfassend sagen: Echtzeit-Fähigkeit auf diese Art und Weise mit einem General-Purpose-Betriebssystem zu verbinden, kann sehr kompliziert werden. Insbesondere, wenn eine neue Betriebssystem-Version freigegeben wird, kann diese oft nicht sofort eingesetzt werden, sondern muss erst an den Betrieb mit dem Echtzeit-Kernel angepasst werden.

passend zum Thema


  1. Virtualisierung im Embedded-Umfeld
  2. Kommerziell verfügbare Virtualisierungslösungen für Industriesteuerungen
  3. Zwei Betriebssysteme auf einer Maschine: ohne Virtualisierung aufwendig
  4. Echtzeit-sichere Interrupt-Verarbeitung
  5. Statische Virtual Machines
  6. Designentscheidung: Sicherheit oder Performance

Jetzt kostenfreie Newsletter bestellen!