"Automotive Betriebsysteme OSEK/VDX - OSEKTime"

Inhaltsverzeichnis

1 Motivation und Einleitung

2 OSEK
2.1 Grundlagen und Architektur
2.2 Prinzipieller Aufbau des Betriebssystems

3 Bestandteile
3.1 Tasks
3.2 Interrupt Service Routinen (ISR)
3.3 Counter und Alarme
3.4 Ressourcenverwaltung
3.5 Fehlerbehandlung

4 OSEKTime
4.1 Scheduling bei OSEKTime

5 Zusammenfassung

1 Motivation und Einleitung

In den letzten Jahren hat sich die Anzahl der elektronischen Steuergeräte in einem Auto- mobil stark erhöht. Dadurch hat sich die Automobilindustrie zu einem der wesentlichen Einsatzfeldern von Echtzeitanwendungen für eingebettete Systeme entwickelt. Zur Zeit sind zum Teil über fünfzig solcher Geräte in einem Kraftfahrzug zu nden. Bis vor kur- zem agierten all diese Geräte selbstständig ohne an ein Netzwerk angebunden zu sein. Dieses jedoch war nicht weiterhin wünschenswert, sondern alle Geräte sollten mitein- ander arbeiten und komunizieren können. Durch diesen Wunsch erhielt die Software in einem Automobil eine sehr bedeutende Rolle und es wurde nach Standards für eine sol- che Software gesucht. OSEK/VDX [OSEK] ist nun ein Standard für Kraftfahrzeuge, der ein einheitliches Echtzeit-Betriebssystem mit dem dazugehörigen Netzwerkmanagement und Kommunikationsdiensten beschreibt. OSEK steht für O ene Systeme für die Elek- tronik im Kraftfahrzeug und wurde von den deutschen Firmen BMW, Daimler Benz, Siemens, Bosch und Opel gegründet. Zeitgleich arbeiteten auch die französischen Firmen Renault und PSA an VDX oder auch Vehicle Distributed Executive . Da beide Initiati- ven das gleiche Ziel eines Betriebssystemstandards hatten, schlossen sich diese 1994 zu OSEK/VDX zusammen. Durch gemeinsame Standards lassen sich Entwicklungskosten und -zeiten einsparen. Dies ist möglich, da eine einheitliche standardisierte Entwick- lungsumgebung verwendet wird. Damit werden den beteiligten Firmen allgemein wie- derkehrende Abläufe und Methoden zur Verfügung gestellt. Die Verwendung von stan- dardisierten Schnittstellen zwischen verschiedenen Geräten und Einheiten ist ein weite- res wichtiges Ziel der OSEK/VDX. Somit ist eine Portabilität, der von verschiedenen Herstellern gelieferten Software erreichbar. Das Testen von Soft- und Hardware Kompo- nenten kann somit optimiert werden. Die Architektur ist plattformunabhängig de niert, hat geringe Grundanforderungen und ist skalierbar. OSEK ist statisch. Das bedeutet, dass während der Implementierung sämtliche Betriebsmittel bekannt sein müssen. Die Speicherverwaltung ist statisch, somit wird die Sicherheit erhöht. OSEKApplikationen bestehen aus einzelnen Tasks. Diese Tasks übernehmen voneinander unterschiedliche Aufgaben. Tasks können durch andere wichtigere Tasks unterbrochen werden. Interrupt Service Routinen (ISR) werden weiterhin genutzt, um sehr schnell auf externe Ereig- nisse reagieren zu können. Ein weiterer Fakt ist die Datenkapselung ähnlich wie bei der objektorientierten Programmierung. Das Betriebssystem ist in drei eigenständigen Komponenten de niert. OSEK-OS, das eigentliche Betriebssystem. Es handelt sich hier- bei um ein preemptives Multitasking- Betriebssystem. Sehr grob beschrieben laufen alle Programme ähnlich der objektorientierten Programmierung in gekapselten Tasks ab, die mit Hilfe von Events miteinander kommunizieren können. OSEK-OS übernimmt das Task- und Resourcenmanagement. OSEK-COM, das Kommunikations-Subsystem. Über diese Komponente ndet der Datenaustausch zwischen den Tasks und den Interrupt Ser-vice Routinen (ISR) statt. Hierfür werden Events verwendet. Ein Task kann auf einen Event warten oder auch von einer ISR geschickt werden. Ein Task kann nicht erkennen, wer diesen Event geschickt hat. Somit ist Wiederverwendbarkeit von Tasks möglich, da keine direkte Abhängigkeit zu anderen Tasks besteht. OSEK-NM übernimmt das Netz- werkmanagement. Es stellt die Aktivität aller im Netz vorhandenen Geräte sicher und kontrolliert deren Anbindung. Ein wichtiger Aspekt ist die Vermeidung von Deadlocks. Daher sind Datenstrukturen integriert, um dies zu gewährleisten. Um die einzelnen Teile eines solchen Projektes sicher zusammenzuführen, ist eine spezielle Beschreibungsspra- che sinnvoll. Für OSEK liegt eine solche mit der OSEK Implementation Language (OIL) vor. Sie erlaubt nicht nur die genaue Beschreibung der realisierten Funktionen, sondern de niert gleichzeitig die benötigten Betriebssystemdienste. Eine OIL-Datei wird mei- stens mit Hilfe eines speziellen Kon gurationstools erzeugt. Sie erlaubt es, einen genau auf die Erfordernisse der jeweiligen Anwendung abgestimmten Betriebssystem-Kern zu erzeugen. Dafür werden Techniken verwendet, die von der Bereitstellung entsprechen- der Header-Dateien bis zur komplett automatischen Generierung des C-Codes für den Kernel reichen. Weitere Information sind unter [OSEK] einzusehen. OSEK ist ein ereig- nisorientiertes Betriebssystem. Um es für zukünftige Anforderungen zu erweitern, wurde OSEKtime spezi ziert. Dieses ergänzt OSEK um eine Zeitsteuerung und eine fehlerto- lerante Kommunikationsschicht.

Abbildung 1.1: Aufbau eines OSEK-konformen Betriebsystems

Abbildung in dieser Leseprobe nicht enthalten

2 OSEK

2.1 Grundlagen und Architektur

Innerhalb von OSEK wurden drei rmenübergreifende und nicht wettbewerbsrelevante Softwarefunktionen realisiert. Auf diese Funktionen kann die Anwendung über standar- disierte Schnittstellen (APIs = Application Programming Interface) zugreifen. Für jede dieser Funktionen wurde innerhalb von Arbeitskreisen jeweils eine Spezi kation erarbei- tet. Nachdem im Oktober 1995 die Spezi kation OSEK 1.0 verö entlicht wurde, konnte zwei Jahre später eine grundsätzlich überarbeite Version im Oktober 1997 vorgestellt werden.

Der aktuelle Stand der Normung von OSEK 2.0 läÿt sich wie folgt angeben:

- Betriebssystem (OSEK Operating System): Ver. 2.0 r1
- Kommunikation (OSEK Communication): Ver. 2.1
- Netzmanagement (OSEK Network Management): Ver. 2.5

Das OSEK Betriebssystem stellt eine Spezi kation einer betriebsmittele zienten und einheitlichen Laufzeitumgebung in Form eines Multitasking-Betriebssystems für Softwa- re in Steuergeräten dar. Die Funktion Kommunikation bietet Schnittstellen und Pro- tokolle für den fahrzeuginternen Datenaustausch innerhalb (Intertaskkommunikation) und zwischen Steuergeräten (Transportprotokolle) an. Hierbei ist die Organisation des Datenbussystems nicht von Bedeutung. Das Netzwerkmanagement stellt Dienste zur Überwachung der Stationen (z.B. Ausfall eines Teilnehmers) und zum geordneten Ein- und Ausschalten (z.B. Sleep-Modus) des Kommunikationsmediums zur Verfügung. De- taillierter soll an dieser Stelle auf Funktionen des Betriebssystems eingegangen werden.

2.2 Prinzipieller Aufbau des Betriebssystems

OSEK /VDX-OS is ein unterbrechbares, statisches, echtzeitfähiges Betriebssystem. Es wurde bewuÿt statisch gehalten, da dies die gröÿte Stärke von OSEK/VDX-OS ist. Es gibt keine Untestützung für dynamische Betriebsmittel, wie man es von einem norma- len Betriebssystem für einen Personal Computer gewönht ist. Insbesondere heiÿt das, dass die Anzahl und die Reihenfolge der Tasks fest vorgegeben sind. Somit kann ein System, das für n Tasks kompiliert wurde, auch nur mit n Tasks umgehen. Werden n+1 Tasks erfordert, so muÿ der Kernel neu kompiliert / gerneriert werden. Die Anzahl der Tasks ist also während der Laufzeit nicht variierbar, wohl aber zur Kompilierzeit. Dieses Konzept, welches im ersten Augenblick sehr unpraktisch und un exibel erscheint, macht OSEK/VDX-OS aber gerade erst aus. Denn hierdurch kann eine erhebliche Optimierung des OSEKKernels erzielt werden. So kann ein Kernel für ein ganz bestimmtes Automo- bil, je nach Ausstattung, erstellt werden. Es werden also nicht einfach alle Worst-Case Fälle abgedeckt, sondern nur die, die physikalisch auch auftreten können. Hierdurch wird widerrum der Speicherverbrauch des Kernels minimiert. Oft darf ein Kernel nicht gröÿer als ein paar KiloBytes sein. Damit ein Betriebssystem sich in der Automobilindu- strie durchsetzen kann, werden natürlich diverse Anforderungen gestellt. Zu einem soll es deterministisches Verhalten aufweisen können, d.h. nichts darf dem Zufall überlas- sen werden, und es muss systemzuverläÿig sein. Das letztere wird durch Fehlertoleranz und Fehlererkunnungsmechanismen sichergestellt. Wie schon bereits erwähnt, muss auch stets auf den Ressourcenverbrauch geachtet werden, denn oft stehen neben dem knappen Speicher auch nur 8-Bit Microcontroller zu Verfügung. Nachdem der Kernel fertig kon - guriert ist, wird dieser zusammen mit dem gewünschten Applikationscode übersetzt und zu einem ausführbaren Programm gelinkt. Eine OSEK Applikation besteht aus Tasks, Interrupt-Service Routinen, Counter & Alarme sowie Messages & Events.

3 Bestandteile

3.1 Tasks

Bei OSEK/VDX-OS sind zwei verschiedene Arten von Tasks vorgesehen. Durch eine Erweiterung names OSEKTime kommt eine dritte hinzu. Es gibt die sogenannten 'Basic Tasks', 'Extended Tasks' und die 'TimetriggeredTask' (diese erst bei OSEKTime). Wie der Name bereits vermuten läÿt, sind die Extended Tasks eine Erweiterung der Basic Tasks. Basic Tasks können sich in drei verschiedenen Zuständen be nden: Suspended, Ready oder Running. Im Zustand Running wird die CPU diesem Task zu gewiesen. Oder anders ausgedrückt: Die Task bekommt vollen Zugri auf die CPU, so dass sie ausgeführt werden kann. Es kann sich zu jedem Zeitpunkt immer nur eine Task in diesem Zustand be nden. Es gibt also keine echte Multitaskingunterstützung, sondern nur Quasi-Paralle Abläufe. Be ndet sich eine Task im Zustand Ready, so wurden alle Vorkehrungen (pre- requisites) getro en, und sie wartet nur noch auf die Bereitstellung der CPU. In diesem Zustand können sich mehrere Tasks zur gleichen Zeit be nden. Von hier aus entscheidet der Scheduler, welche Task zuerst in den Zustand running wechseln darf. Die Auswahl, die vom Scheduler getro en wird, ist nicht willkürlich: Jede Task erhält eine vom Pro- grammierer fest vorgegebene Priorität (vgl. statisches Verhalten von OSEK/VDXOS), wobei 0 die niedrigste Priorität ist. Nun werden der Priorität nach die verschiedenen Tasks gestartet. Jede Task, die sich im Zustand Suspended aufhält, schläft. Sie kanns durch eine andere Task oder durch sogenannte Events aktiviert werden, wodurch sie in den Zustand ready übergeht. Eine extended Task wird durch einen Zustand names 'Waiting' erweitert. Be ndet sich eine Task in diesem Zustand, so wartet sie auf ein ganz bestimmtes Ereignis (Event), z.B. Autotür wird geö net. Sie kann in diesen Zustand nur von Running aus gelangen, und zwar genau dann, wenn sie an einer Stelle angelangt ist, an der sie auf ein Event warten muss. Von waiting aus wird beim Eintreten des Ereignis- ses in den Zustand Ready gewechselt. Ist eine Task fertig abgearbeitet, so terminiert sie sich selber und verfällt wieder in den Zustand suspended. Sie kann sich nur selbst termi- nieren, es ist also nicht möglich, dayy eine Task eine andere beendet ( self-termination ). Es sei angemerkt, daÿ eine Task niemals von Suspended direkt zu Running wechseln darf. Es muss immer einen Zwischenstopp bei Ready geben. Bei Systemstart be ndet sich jede Taks in Suspended. Ein weiteres, wichtiges Attribut von Tasks ist: Eine Task ist entweder preemptive oder non-preemptive. Eine unterbrechbare Task kann somit von Running aus in Suspended oder zurück zu Ready wechseln. Zu Ready wird gewechselt, wenn sich eine Task mit höherer Priorität in Ready be ndet. Somit wird sichergestellt, dass zu jedem Zeitpunkt die Task mit der höchsten Priorität arbeitet, vorausgesetzt die laufende ist preepmtiv.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: OSEK Architektur

3.2 Interrupt Service Routinen (ISR)

Interrupt Service Routinen sind Routinen, die durch einen Interrupt Requests (IRQ) der Hardware gestartet werden. Sie stellen die einzige Möglichkeit dar, den festen, sta- tischen Verlauf des Betriebssystems zu unterbrechen bzw. zu manipulieren. Es gibt drei verschiedene Kategorien von ISRs. Die erste ignoriert das Betriebssystem vollständig, als wäre es nicht vorhanden. Dies hat zur Folge, daÿ es keinerlei Syncronisation mit diesem geben kann. Die zweite Kategorie geht einer anderen Philosophie nach. Hier ist einer ISR das zu Grunde liegende OS wohl bekannt. Dies schaltet nun, vor Ausführung der Routine zwecks Syncronisation einige Aktionen zuvor. Nachteilhaft hier ist die höhere Reaktionszeit, da zuerst der Zusatzcode abgearbeitet werden muss. Die letzte Kategorie sieht eine Mischung aus beiden vor. So kann der Programmierer selbst entscheiden, wann der Zusatzcode ausgeführt werden soll. ISRs senden Events, um Tasks zu starten.

3.3 Counter und Alarme

Genau wie Events und Messages dienen Counter und Alarme der Kommunikation. Ein Counter zählt beliebige Ereignisse, wie z.B. die Umdrehungszahl im Motor. Denkbar wäre jedoch auch das Zählen von Fehlern innerhalb einer Anwendung. Allein aggierend ist ein Counter nicht besonders hi reich. Nun wird an je einen Counter genau ein Alarm gebunden; wird nun ein vorgegebener Wert vom Counter überschritten, so wird ein Alarm ausgelöst. Auch hier ist das Starten einer Taks oder das Auslösen eines Events denkbar. Durch dieses Konzept sind auch zyklische Tasks realisierbar. Es ist möglich, Counter wieder zu stoppen oder auf Null zurück zu setzen, wodurch widerum Time-Out- Mechanismen erzielt werden können.

3.4 Ressourcenverwaltung

Durch die Ressourcenverwaltung wird der Zugri mehrerer Tasks auf gemeinsam genutzte Ressourcen koordiniert. Zu diesem Zweck wird die Taskpriorität zur Laufzeit durch das Betriebsystem so verändert, daÿ konkurrierende Tasks nicht gleichzeitig auf eine Ressource zugreifen können.

3.5 Fehlerbehandlung

Das OSEK Betriebssystem stellt Mechanismen sowohl für eine zentrale als auch dezentrale Fehlerbehandlung in Form sogenannter HOOK-Routinen zur Verfügung. Diese stellen ein Gerüst dar, das es dem Anwender ermöglicht, durch eine eigene Auswertung die Fehler zu verarbeiten.

4 OSEKTime

OSEKTime stellt eine Erweiterung durch eine fehlertolerante Komunikationsschicht (FT- Com) und den timetriggered Tasks von OSEK/VDX-OS dar. Mittels OSEKTime wird OSEK/VDX-OS also zu einem Echtzeitbetriebssystem. FTCom übernimmt die Kommu- nikation zwischen den Steuergeräten einer verteilten Andwendung. Es werden verschiede- ne Protokolle unterstützt: Time-Triggered Protocol (TTP), FlexRay und TTCAN. Sie weisen ebenfalls deterministisches Verhalten auf. Genau wie OSEK/VDX-OS arbeitet auch OSEKTime statisch. Wie bereits erwähnt, bringt OSEKTime timetriggerd Tasks mit. Für sie gibt es, wie bei den Basic Tasks genau drei Zustände: Running, suspended und preempted. Im Gegensatz zu den beiden anderen Taks Typen existiert hier kein Zustand Ready. Dies hat zur Folge, dass eine Task durch eine Aktivierung von Suspen- ded direkt in Running sübergehen kann. Auch hier kann immer nur eine Task Zugri auf die CPU erhalten. Eine Task, die grade ausgeführt wird, kann durch eine andere unterbrochen werden (nicht aber beendet). Ist dies der Fall, so erreicht die unterbroche- ne Task den Zustand Preempted. Dieser Zustand wird genau dann verlassen, sobald die andere Task von Running zurück zu Suspended fällt, also sobald sie sich selbst beendet hat. Selbstverständlich spielt bei OSEKTime die Zeit eine sehr bedeutende Rolle, somit wird eine Syncronisation lokaler Prozesse bzgl. einer globalen Uhrzeit zu einem absolu- ten Muss. Hierfür sind drei verschiedene Strategien vorgesehen: Syncronisation StartUp async., StartUp hard Syncronisation und async. StartUp smooth Syncronisation. Die er- ste Strategie lässt eine Task erst dann ausführen, wenn die Uhrzeit syncronisiert wurde. Zweite und dritte richten sich nach der sogenannten Dispatcher Table (Siehe Abbildung).

4.1 Scheduling bei OSEKTime

Zu Beginn wird eine Tabelle, die sogenannte Dispatcher-Table, mit Startzeiten der Tasks berechnet und erstellt. Eine komplette Abarbeitung dieser Tabelle wird Dispatcher Round genannt. Die Zuteilung erfolgt strikt sequentiell nach dieser Tabelle. Es wird hier keine Unterbrechung der Tasks durch Events gestattet. Während alle Tasks passiv sind, also Suspended, wird die IDLE-Task ausgeführt. Durch sie kann OSEKTime auch ohne OSEK/VDX-OS arbeiten. Eine zeitgesteuerte Task muss sich ebenfalls selbst beenden. Dies muss spätestens vor ihrer sog. Deadline geschehen. Die Deadline ist nicht mit der Ausführungszeit einer Task zu verwechseln. Während es sich bei der Ausführungszeit um die Zeit handelt, die eine Task vom Start bis zu ihrer Terminierung benötigt, so handelt es sich bei der Deadline um die Zeit, in der eine Task beendet sein muss! Scha t sie dies nicht, so werden diverse Fehlererkunnungsmechanismen, wie z.B. Stringent-task deadline monitoring, und Nonstringent- task deadline monitoring, gestartet. Das Über-wachen der Deadlines, welche in einer weiteren Tabelle zu nden sind, übernimmt der Dispatcher.

Abbildung 4.1: Scheduling bei OSEKTime

Abbildung in dieser Leseprobe nicht enthalten

5 Zusammenfassung

Mit Hilfe von OSEK/VDX-OS ist ein bedeutender Schritt zur Scha ung einer einheitlichen Softwareplattform auf Microcontrollern gescha en worden. Da durch diesen erscha enen Standard enorme Zeit- und somit Geldeinsparungen ermöglicht werden, hat es in der heutigen Automobilindustrie bereits einen festen Platz eingenommen. Bereits im Mai 2000 fuhr das erste mit OSEK/VDX-OS ausgestattete Auto. Es handelte sich hierbei um die C-Klasse von Mercedens Benz. Neben Daimler Crysler setzt auch BMW voll und ganz auf OSEK/VDX-OS.

Möchte man OSEK/VDX-OS mit einem Betriebssystem eines Personal Computers ver- gleichen, so stellt man schnell fest, daÿ dies kaum möglich ist, denn OSEK ist statisch angelegt, ein OS für den PC , natürlicherweise, dynamisch. Ein statisches Betriebssystem für den PC würde natürlich wenig Sinn bringen. Man denke nur z.B. an die Benutzer- verwaltung. Auf der anderen Seite wäre eine Benutzerverwaltung in einem Automobil genauso sinnlos. OSEK liegt seit dem 5.Juli 2004 in seiner Aktuellen Version 2.2.22 vor. Erstellt werden OSEK/VDX-OS Applikationen im Übrigen mit Hilfe der Sprache OIL. Ein gut optimierter Kernel benötigt nur 736 Bytes ROM und 197 Bytes Ram, also zu- sammen noch nicht einmal 1kB! Der Durschnitt liegt jedoch bei 60 kbyte Rom und 2 kByte Ram.

Literaturverzeichnis

[BMBF] Jochen Schoof - OSEK/VDX- Betriebssystemstandard für Steuergeräte in Kraftfahrzeugen ; Geschäftsfeld OSEK 3Soft GmbH

[OSEK] http://www.osek-vdx.org

[ELEK] http://www.elektronik.de

[ALL] http://www.all-electronik.de

[OTIME] Bernd Hedenetz, Jens Ruh, Matthias Kühlewein, Anton Schedl, Emme-rich Fuchs, Andreas Krüger, Patrick Pelcat, Samuel Boutin, Elmar Dilger, Thomas Führer, Stefan Poledna, Martin Glück, Thomas Ringler. OSEK- time - the new fth OSEK/VDX group: A Depedable Fault-Tolerant Real- Time Operating System and Communication Layer for By-Wire Applica- tions. VDI-Verlag 2000