"Automotive Betriebsysteme OSEK/VDX - OSEKTime"

Inhaltsverzeichnis

1  Motivation und Einleitung  3

2  OSEK  5

  Grundlagen und Architektur 2 1  5

  Prinzipieller Aufbau des Betriebssystems 2 2  5

3  Bestandteile  7

  Tasks 3 1  7

  Interrupt Service Routinen (ISR) 3 2  8

  Counter und Alarme 3 3  8

  Ressourcenverwaltung 3 4  9

  Fehlerbehandlung 3 5  9

4  OSEKTime  10

10  Scheduling bei OSEKTime 4  1

5  Zusammenfassung  12

2

1 Motivation und Einleitung

In den letzten Jahren hat sich die Anzahl der elektronischen Steuergeräte in einem Automobil 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 kurzem 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 solche 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 Elektronik 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 Initiativen 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 Entwicklungsumgebung verwendet wird. Damit werden den beteiligten Firmen allgemein wiederkehrende Abläufe und Methoden zur Verfügung gestellt. Die Verwendung von standardisierten Schnittstellen zwischen verschiedenen Geräten und Einheiten ist ein weiteres wichtiges Ziel der OSEK/VDX. Somit ist eine Portabilität, der von verschiedenen Herstellern gelieferten Software erreichbar. Das Testen von Soft- und Hardware Komponenten 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 Ereignisse 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 hierbei 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 Netzwerkmanagement. 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 Beschreibungssprache 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 meistens 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 entsprechender 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 fehlertolerante Kommunikationsschicht.

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 standardisierte Schnittstellen (APIs = Application Programming Interface) zugreifen. Für jede dieser Funktionen wurde innerhalb von Arbeitskreisen jeweils eine Spezikation erarbeitet. 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 Software in Steuergeräten dar. Die Funktion Kommunikation bietet Schnittstellen und Protokolle 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. Detaillierter 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 normalen 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 Automobil, 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 Automobilindustrie durchsetzen kann, werden natürlich diverse Anforderungen gestellt. Zu einem soll es deterministisches Verhalten aufweisen können, d.h. nichts darf dem Zufall überlassen 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 konguriert 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 (prerequisites) 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 Programmierer 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 Ereignisses 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 terminieren, 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

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, statischen 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 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.

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 Kommunikation zwischen den Steuergeräten einer verteilten Andwendung. Es werden verschiedene 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 Suspended 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 unterbrochene 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 absoluten Muss. Hierfür sind drei verschiedene Strategien vorgesehen: Syncronisation StartUp async., StartUp hard Syncronisation und async. StartUp smooth Syncronisation. Die erste 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.

11

5 Zusammenfassung

Mit Hilfe von OSEK/VDX-OS ist ein bedeutender Schritt zur Schaung einer einheitlichen Softwareplattform auf Microcontrollern geschaen worden. Da durch diesen erschaenen 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 vergleichen, 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 Benutzerverwaltung. 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 zusammen noch nicht einmal 1kB! Der Durschnitt liegt jedoch bei 60 kbyte Rom und 2 kByte Ram.

12

Literaturverzeichnis

[BMBF] [OSEK]

[ELEK] [ALL] [OTIME]

13