Automotive Embedded Systeme

4 Betriebssysteme

In frühen Embedded Systemen war kein Betriebssystem notwendig. Das Gerät basierte auf einer einfachen Hauptschleife, die nacheinander Bedienelemente abfragte und entsprechende Gerätefunktionen ansteuerte. Wegen zunehmender Funktionalitäten, sich ändernder Hardware-Plattformen und wegen der hohen Anforderungen an gefühlte Bedienbarkeit kam man bereits früh zur Notwendigkeit von Betriebssystemen, die eine scheinbare Parallelität erlaubten, so dass nun, wenn z.B. in einer Applikation auf eine Tastatureingabe gewartet wird, eine andere inzwischen weiterarbeiten kann. Betriebssysteme organisieren die

  quasi parallele Abarbeitung verschiedener Prozesse oder Threads;
  sie verwalten Hardware- und Software-Ressourcen;
  sie kapseln und abstrahieren Hardware-Funktionen und Schnittstellen;
  sie stellen zum Teil standardisierte Services zur Verfügung, wie z.B. Speicherverwaltung, Kommunikations-Schnittstellen, Lader, Fehlerroutinen, Synchronisations- und Kommunikationsmethoden. Im Zusammenhang mit der Framework-Diskussion im automotiven Umfeld sind gleichzeitig einige Betriebssysteme in der Diskussion. Diese Verknüpfung ist zunächst einmal unglücksselig, da die Begriffe Framework und Betriebssystem eigentlich verschiedene Schichten betreffen. Durch das Paket WinCE, das Betriebssystem und Framework fast untrennbar verbindet, kommt es zur Vermischung der Begriffe. Auch ein GUI-Builder (Graphical User Interface) wie Photon für QNX vermischt Framework und OS-Schichten.

Trotzdem sollten die weitgehend üblichen Betriebssysteme erwähnt werden.

Es sind: 
       VxWorks, das sehr erprobt und geeignet in der kleinen Multithread- Umgebung ist, für das es aber noch nicht viel Erfahrung in Multiprozess-Systemen gibt. In ähnlicher Weise ist I-Tron einzuordnen, das sehr häufig in japanischen Systemen eingesetzt wird.

Mit mächtigeren Prozessoren wie dem SH4 von Hitachi und dem Power- PC von Motorola und anderen kommen die Möglichkeit und die Forderung nach Multiprozess-OS auf. Hier greift im Moment QNX, dessen Entwicklungsumgebung (Momentics) allerdings speziell bei großen Projekten viele Schwächen haben. Die Stärken von QNX sind die Echtzeitorientierung und die POSIX-Konformität. WinCE kommt immer wieder in die Diskussion mit der Vorstellung eines Standards, genauso oft stellt sich aber auch heraus, dass die Verquickung von Framework und Betriebssystem bei WinCE von den Entwicklern nicht geliebt wird. Auch sind die Einschränkungen im Framework noch so groß, dass am Ende im Wesentlichen nur der OS-Teil genutzt und ein eigenes Framework drumherum implementiert wird. Dafür ist es dann aber zu aufwändig und teuer.

Die richtige Design-Entscheidung scheint deshalb hier zu sein, sich vom OS zu abstrahieren und mehrere Betriebssysteme zu unterstützen. Die vorgestellten Implementierungen werden deshalb in der Regel auf VxWorks, QNX und Windows lauffähig sein, dies zwingt auch wieder dazu, sich nicht zu sehr auf Spezialitäten nur eines Betriebssystems einzulassen. In späteren Kapiteln wird gezeigt, wie Programme wahlweise unter QNX, Windows und Linux laufen können, solange man sich bei der Auswahl der Betriebssystem-Mittel beschränkt. Deshalb werden wir hier auf Betriebssysteme nicht weiter eingehen, nur drei notwendige Begriffe kurz erläutern und später in den Implementierungsbeispielen von Betriebssystem-Funktionalität