Technische Universität Ilmenau

Faculty of Mechanical Engineering

Automotive Engineering

Projektseminar

Automotive Betriebsysteme

OSEK/VDX - OSEKTime

Bischof, René

Matrikelnummer: 33665 (INF 01)

Studiengang Informatik

Technische Universität Ilmenau

Wintersemester 2003/2004

---

Inhaltsverzeichnis

1 Motivation und Einleitung

3

2 OSEK

5

2.1 Grundlagen und Architektur .

5

2.2 Prinzipieller Aufbau des Betriebssystems .

5

3 Bestandteile

7

3.1 Tasks .

7

3.2 Interrupt Service Routinen (ISR) .

8

3.3 Counter und Alarme .

8

3.4 Ressourcenverwaltung .

9

3.5 Fehlerbehandlung .

9

4 OSEKTime

10

4.1 Scheduling bei OSEKTime 10

5 Zusammenfassung

12

2

---

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 Oene 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 deniert,

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 deniert. 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-

3

---

1 Motivation und Einleitung

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

deniert gleichzeitig die benötigten Betriebssystemdienste. Eine OIL-Datei wird mei-

stens mit Hilfe eines speziellen Kongurationstools 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 speziziert. Dieses ergänzt OSEK um eine Zeitsteuerung und eine fehlerto-

lerante Kommunikationsschicht.

Abbildung 1.1: Aufbau eines OSEK-konformen Betriebsystems

4

---

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 Spezikation erarbei-

tet. Nachdem im Oktober 1995 die Spezikation 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 Spezikation einer betriebsmittelezienten 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

5

---

2 OSEK

Konzept, welches im ersten Augenblick sehr unpraktisch und unexibel 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.

6

---

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 benden: 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

benden. Es gibt also keine echte Multitaskingunterstützung, sondern nur Quasi-Paralle

Abläufe. Bendet sich eine Task im Zustand Ready, so wurden alle Vorkehrungen (pre-

requisites) getroen, und sie wartet nur noch auf die Bereitstellung der CPU. In diesem

Zustand können sich mehrere Tasks zur gleichen Zeit benden. Von hier aus entscheidet

der Scheduler, welche Task zuerst in den Zustand running wechseln darf. Die Auswahl,

die vom Scheduler getroen 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. Bendet 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 bendet

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 bendet. Somit wird sichergestellt,

dass zu jedem Zeitpunkt die Task mit der höchsten Priorität arbeitet, vorausgesetzt die

laufende ist preepmtiv.

7

---

3 Bestandteile

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

8

---

3 Bestandteile

ist ein Counter nicht besonders hireich. 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 genutz-

te 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 de-

zentrale 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.

9

---

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! Schat

sie dies nicht, so werden diverse Fehlererkunnungsmechanismen, wie z.B. Stringent-task

deadline monitoring, und Nonstringent- task deadline monitoring, gestartet. Das Über-

10

---

4 OSEKTime

wachen der Deadlines, welche in einer weiteren Tabelle zu nden sind, übernimmt der

Dispatcher.

Abbildung 4.1: Scheduling bei OSEKTime

11

---

5 Zusammenfassung

Mit Hilfe von OSEK/VDX-OS ist ein bedeutender Schritt zur Schaung einer einheit-

lichen Softwareplattform auf Microcontrollern geschaen worden. Da durch diesen er-

schaenen 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.

12

---

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

13

---