Automotive Operating Systems: OSEK/VDX

Transkript

1 Automotive Operating Systems: OSEK/VDX Joshua Billert TU Kaiserslautern, Embedded Systems Group Einführung Im Automobilbereich wird Softwareentwicklung immer relevanter. Wo früher noch keine C Programme ihren Dienst verrichteten, steht heute ein großes Softwarepaket dahinter. Auch die Vielfalt der Hardware, welche in den einzelnen Automobilen verwendet wird, wächst stetig. Spezielle Hardware benötigt auch spezielle Software. Von Modellreihe zu Modellreihe werden andere Hardwareteile verwendet. Dies kann einen sehr großen Aufwand zum Portieren der Software bedeuten, der gleichzeitig mit hohen Kosten verbunden ist. Auch ein Wechsel der Bauteilen von Zulieferfirmen kann massive Änderungen in Software bedeuten. Um Kosten für das Portieren von Software zu reduzieren wurde im Mai 1993 das OSEK ( Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug ) Projekt als ein gemeinsamer Industriestandard von vielen deutschen Firmen ins Leben gerufen wurde das Projekt mit dem französischem VDX-Ansatz ( Vehicle Distributed executive ), welcher das gleiche Ziel verfolgte, zusammengelegt. In der folgenden Arbeit, werden zunächst kurz die Ziele und Vorteile von OSEK beschrieben. Anschließend folgt eine Übersicht des Standards. Kapitel 3 und 4 behandeln ausführlich das Betriebssystem und die wichtigsten Grundlagen. Während Kapitel 3 sich mit der ereignisorientierten Variante von OSEK auseinandersetzt, wird im 4. Kapitel die zeitgetriggerte und statisch konfigurierte Variante vorgestellt. Im darauf folgenden Abschnitt wird die kombinierte Umsetzung beider Varianten erklärt. Abschließend reißt diese Arbeit noch die Umsetzung des Standards mit der für OSEK entworfenen Implementierungssprache an.

2 1 Ziele und Vorteile Das Ziel des Projektes ist die Schaffung einer Basis für portierbare und wiederverwendbare Softwaremodule. Erreicht wird dies durch die Spezifikation von abstrakten und Anwendungsunabhängigen Interfaces [5]. Die daraus resultierenden Vorteile sind hauptsächlich Einsparungen von Entwicklungszeit und somit auch von Kosten. Durch das Festlegen von Entwicklungsstandards wird gleichzeitig auch ein gewisser Qualitätsstandard sichergestellt [5]. 2 Übersicht Die von OSEK Operating Systems bereitgestellte Spezifikation stellt eine einheitliche Umgebung für Software zur Verfügung. Über die Spezifikation wird eine effiziente Verfahrensweise zur Verwaltung von Ressourcen für Automobilsteuerungssoftware beschrieben [4]. Mit OSEK OS wird keine vollständige Kompatibilität zwischen Anwendungen erreicht, jedoch sind deren Teile recht einfach portierbar und wiederverwendbar. Auch durch die Nutzung von standardisierten Interfaces zwischen System und Anwendungssoftware, welche als Services zur Verfügung gestellt werden, können Aufwand und Kosten zur Wartung und Portierung gering gehalten werden. Zusätzlich zu dem System wurde auch eine Sprache zur standardisierten Beschreibung der Systemkonfiguration entwickelt. Durch die Sprache OIL ( OSEK Implementation Language ) können OSEK spezifische Objekte und Verhaltensweisen beschrieben und spezifiziert werden. 3 OSEK OS Das Betriebssystem OSEK stellt eine Menge von System-Services und Verfahrensmechanismen bereit. Zu den Services gehören unter Anderem Task-Management, Interrupt-Management sowie Fehler- Behandlung. Außerdem stellt es für voneinander unabhängige Anwendungen jeweils eine eigene Umgebung auf dem Prozessor her. OSEK unterscheidet beim Ausführen von Prozessen zwischen drei Ebenen. Basisprozesse werden auf dem Task-Level ausgeführt. Jeder Task kann vom Benutzer frei, aber statisch priorisiert werden. Über dem Task-Level liegt das logische Level für den Scheduler. Prozesse dieser Ebene sind für das Scheduling der Task vorgesehen. Als höchst priorisiertes Level gilt das Interrupt-Level. Prozesse auf dieser Ebene haben Vorrang vor allen Anderen. 3.1 Tasks Komplexe Steuerungssoftware kann in kleinere Teile abhängig von deren Echtzeitanforderungen zerlegt werden. Diese Teile werden in OSEK als (nebenläufige) Tasks realisiert [4]. Tasks können wiederum weitere Tasks aktivieren um so einen komplexen Prozess stückweise abzuarbeiten. Einzelne Tasks können in Konformitätsklassen eingeteilt werden. Hierzu wird zum einen zwischen Basis- (basic) und erweiterte (extended) Tasks unterschieden. Dies wird mit der Eigenschaft kombiniert, ob mehr als ein Task mit der gleichen Priorität aktiv sein kann. Daraus resultiren vier Klassifizierungsgruppen. Ziel der Klassifizierung ist die teilweise Implementierung anhand vorgegebenen Leitwegen und das Unterstützen von passenden Gruppen für Systemeigenschaften. Basistasks geben den Prozessor nur frei, wenn sie mit Ihrer Ausführung am Ende angelangt sind, oder wenn sie von einem höher priorisierten Task oder Interrupt verdrängt werden. erweiterte Tasks

3 running wait start terminate waiting release preempt activate suspended ready Abbildung 1: Lebenszyklus von Basis- und erweiterten Tasks hingegen bieten zusätzlich die Möglichkeit auf ein Systemevent zu warten. Hierzu wird nach Aufruf des Befehls WaitEvent der Prozessor freigegeben und er kann auch an niedriger priorisierte Tasks zugewiesen werden. Mittels der Möglichkeit auf Systemereignisse zu warten, ist es mit erweiterte Tasks möglich, Tasks untereinander zu synchronisieren, was bei Basistasks nicht möglich ist. Dafür haben Basistasks den Vorteil der sehr moderaten Nutzung des RAM [4]. Tasks können sich jeweils in einem der drei bzw. vier Zuständen, wie in Abbildung 1 beschrieben, befinden. Nach dem Initialisieren des Betriebssystems befinden sich alle Tasks im Zustand suspended. Durch aktivieren eines Tasks geht dieser in den Zustand ready über. Von dort aus kann der Scheduler den Task nun dem Prozessor zuweisen, wodurch er in den Zustand running kommt. Nach erfolgreicher Ausführung terminiert der Task und geht wieder zurück in den Zustand suspended über. Sofern der Task vor dem terminieren durch einen anderen unterbrochen wird, gelangt er wieder in den Zustand ready und wartet auf die nächste Prozessorzuteilung des Schedulers. Bei erweiterten Tasks können Tasks vom Zustand running noch in den Zustand waiting gelangen, wenn sie auf ein Ereignis warten. Nach eintreffen des Ereignisses, gelangen auch diese Tasks wieder in den Zustand ready. Ein Task kann sich ausschließlich selbst terminieren. Ein laufender Task kann zwar von einem Interrupt oder einem anderen Task unterbrochen werden, jedoch niemals terminiert werden. Jeder Task muss sich am Ende seines Codes selbst durch den Systembefehl TerminateTask oder ChainTask beenden. Andernfalls fährt das System mit einem undefinierten Verhalten fort. Das Aktivieren eines Tasks kann hingegen von jedem ausführenden Task geschehen. Dies wird durch den Systemservice ActivateTask bzw. ChainTask initiiert. Eine Übergabe von Parametern wie in anderen Programmiersprachen ist nicht vorgesehen. Die Umsetzung erfolgt über einen Nachrichtenaustausch oder über globale Variablen.

4 3.2 Scheduler Der Scheduler ist zuständig, für das Zuweisen des Prozessors, auf die einzelnen wartenden Tasks. Er wird vom Betriebssystem zu jedem Zeitpunkt aufgerufen, an dem ein Taskwechsel möglich ist. Der Scheduler entscheidet anhand der Priorität der einzelnen Tasks, welcher als Nächstes in den Zustand running übergehen darf. Die niedrigste Priorität wird durch den Wert 0 definiert. Größere Werte ergeben gleichermaßen höhere Prioritäten. Um möglichst effizient zu arbeiten, werden Prioritäten statisch vergeben und können zur Laufzeit nicht geändert werden [4]. Tasks der gleichen Priorität werden nach dem FIFO Queue Prinzip behandelt. Jeweils der am längsten wartende Task wird dem Prozessor zugewiesen. Tasks welche aus dem Zustand waiting kommen, reihen sich gleichermaßen wie neu aktivierte Tasks ein. Eine wichtige Eigenschaft beim Scheduling ist die Unterbrechbarkeit der Tasks. Bei voll unterbrechbaren Tasks kann der Scheduler nach jeder Anweisung den Task für einen höher priorisierten unterbrechen. Der Kontext des aktuellen Tasks wird gespeichert und der Task in den Zustand ready versetzt. Sobald der unterbrechende Task den Zustand running verlässt, wird der unterbrochene Task wiederhergestellt und weiter ausgeführt. Der Vorteil der vollen Unterbrechbarkeit liegt darin, dass ein höher priorisierter Task nicht von einem niedriger priorisiertem Task aufgehalten werden kann. Wenn ein Codefragment nicht unterbrochen werden darf, da sonst Inkonsistenzen auftreten könnten, kann dies durch das reservieren der Scheduler Ressource über den Service GetResource blockiert werden. Bei nicht unterbrechbaren Tasks wird der Scheduler jeweils nur nach erfolgreicher Terminierung der Tasks ausgeführt, oder wenn ein Task auf ein Event wartet. Wenn sich innerhalb eines Systems unterbrechbare sowie auch nicht unterbrechbare Tasks befinden, wird die Unterbrechbarkeit immer abhängig vom aktuell laufenden Task gewählt. Wenn also der laufende Task nicht unterbrechbar ist, so kann auch kein höher priorisierter unterbrechbarer Task diesen unterbrechen. Die nicht Unterbrechbarkeit ergibt dann Sinn, wenn Tasks eine kleine obere Laufzeitschranke haben, oder der RAM beim sichern des Kontextes stark beansprucht würde [4]. Eine Kombination der Unterbrechbarkeit und der nicht Unterbrechbarkeit kann auch durch das Bilden von Taskgruppen erreicht werden. Für Tasks mit der gleichen oder niedrigeren Priorität als der höchst priorisierte Task einer Gruppe verhalten sich die Task in der Gruppe als nicht unterbrechbar. Für Tasks mit einer höheren Priorität als alle Tasks in einer Gruppe sind die Tasks unterbrechbar. Taskgruppen können über interne Ressourcen realisiert werden. Besteht eine Taskgruppe zum Beispiel aus Tasks der Prioritäten 3,4 und 6, so kann ein anderer Task der Priorität 7 jederzeit Tasks der Gruppe unterbrechen. Ein Task der Priorität 5 könnte ohne Gruppe die Tasks mit den Prioritäten 3 und 4 unterbrechen. Da die Gruppe aber einen Task mit der Priorität 6 beinhaltet, kann der Task der Priorität 5 auch die niedriger priorisierten der Gruppe nicht unterbrechen. 3.3 Anwendungsmodi Das Betriebssystem kann unter verschiedenen Anwendungsmodi laufen. Die jeweiligen Modi müssen sich gegenseitig vollständig ausschließen, denn der Modus kann nur zum Systemstart gewählt werden und ist zur Laufzeit nicht veränderbar. Unter den verschiedenen Anwendungsmodi können komplett unterschiedliche Anwendungen laufen. So kann es zum Beispiel einen Modus zum Systemtest, einen zum Systemupdate und einen für das normale System geben. Es können aber auch ganz andere Modi gewählt werden. Die Systemstartzeit ist eine sicherheitsrelevante Eigenschaft, da während der Laufzeit ein Systemreset auftreten kann und dann das System so schnell als möglich wieder einsatzbereit sein sollte. Der

5 Anwendungsmodus wird vor dem Systemstart aus der OIL Datei ausgelesen und als Parameter an den API-Service StartOS weitergegeben. Erst dann wird der Kernel gestartet. 3.4 Interrupts OSEK unterscheidet zwischen zwei verschiedenen Interruptroutinen (Interrupt Service Routine: ISR). ISR Kategorie 1 Die ISR 1 verwendet keine Systemservices und hat somit keinerlei Einfluss auf das Taskmanagent. Nach dem Interrupt fährt das System exakt an der unterbrochenen Stelle fort. ISR Kategorie 2 OSEK stellt dem Interrupt eine komplette Umgebung zur Verfügung Während eines Interrupts wird kein weiteres Scheduling durchgeführt. Nach einem ISR der Kategorie 2 wird ein Scheduling durchgeführt, wenn ein unterbrechbarer Task unterbrochen wurde und kein weiterer Interrupt aktiv ist. Falls ein Interrupt einen Task aktiviert, nimmt der Task direkt im Anschluss an den Interrupt platz. Das Schedulen und priorisieren von Interrupts geschieht auf Hardwareebene und ist nicht in OSEK spezifiziert. Die einzelnen Interruptkategorien können von Tasks jeweils deaktiviert werden, um kritische Abschnitte zu schützen. Nach einem Deaktivieren einer ISR Kategorie in einem Task, muss exakt diese Kategorie auch wieder aktiviert werden, um ein undefiniertes Verhalten des Systems zu verhindern. 3.5 Events Der Eventmechanismus ist ausschließlich für extented Task verwendbar. Er kann zur Synchronisation von Tasks verwendet werden, wobei jeder Task eine konkrete Anzahl an Events besitzt. Die jeweiligen Events werden vom System verwaltet. Sie können genutzt werden um binäre Informationen an einen erweiterten Task zu übermitteln. Events können sowohl von dem Task dem das Event gehört, als auch von anderen Tasks verändert werden. Diese Modifikation kann auch von einem Basistasks, oder einem Interrupt der Kategorie 2 ausgehen. Events sind die Auslöser, um einen Task aus dem Zustand waiting in den Zustand ready zu überführen. Ein Task bleibt so lange im Zustand waiting, bis mindestens ein Event eingetroffen ist, auf welches der Task wartet. Sollte das Event schon eingetreten sein, bevor der Task darauf warten soll, bleibt dieser im Zustand running. 3.6 Ressourcenmanagement Das Ressourcenmanagement wird Verwendet, um einen Zugriff auf alle Ressourcen zentral vom System zu koordinieren. Dabei können auch verschiedene Prioritäten für die Ressourcen ausgewertet werden. Mittels Ressourcenmanagement kann verhindert werden, dass zwei Tasks gleichzeitig auf eine gemeinsame Ressource zugreifen. Des Weiteren wird verhindert, dass ein Anfordern einer Ressource in Zustand waiting endet. Auch Deadlocks werden somit verhindert [4]. Wenn das Konzept des Ressourcenmanagements verwendet wird, kann zusätzlich sichergestellt werden, dass auch Interrupts nur so auftreten, dass keine Ressourcenkonflikte entstehen. OSEK verbietet strikt den geschachtelten Zugriff auf gemeinsame Ressourcen. Sofern dies trotzdem ausdrücklich erwünscht ist, wird empfohlen, eine zweite Ressource mit dem selben Verhalten mit OIL als linked ressource zu spezifizieren. Die Befehle TerminateTask, ChainTask, Schedule, WaitEvent dürfen während eine Ressource verwendet wird, nicht aufgerufen werden [4]. Bei gleichzeitiger Nutzung mehrerer Ressourcen müssen die

6 Reservierungen und Freigaben nach dem LIFO Prinzip erfolgen. Ressourcen die als erstes reserviert wurden, dürfen auch erst als letztes freigegeben werden. Sofern ein Scheduling innerhalb eines unterbrechbaren Tasks verhindert werden soll, kann der Scheduler als Ressource reserviert werden. Interrupts werden weiterhin unabhängig von der Belegung der Schedulerressource ausgeführt. Typische Probleme die Auftreten könnten, sind zum Einen das Problem der Prioritätenumkehr und zum Anderen das Problem des Deadlocks. Bei der Prioritätenumkehr hält ein niedrig Priorisierter Task T 0 (z.b. Priorität 0 - kurz: P0) die Sperre auf eine Ressource. Wird sie nun von einem hochpriorisiertem Task T 2 mit P2 unterbrochen, welcher auf die selbe Ressource zugreifen möchte, muss dieser warten bis T 0 terminiert oder zumindest die Ressource wieder frei gibt. Sind in der Zwischenzeit aber noch Tasks mit der Priorität P1 hinzugekommen wird nun die Prioritätenreihenfolge P1 P0 P2 ausgeführt und T 2 wird von niedriger priorisierten Tasks undefiniert lange verzögert. Beim Deadlock spielen mindestens zwei Tasks T 1 (mit P1), T 2 (mit P2) und zwei Ressourcen R1, R2 eine Rolle. T 1 möchte R1 und R2 reservieren und T 2 möchte R2 und R1 reservieren, so kann es zur Situation kommen, dass T 1 R1 sperrt und T 2 nun wegen seiner höheren Priorität T 1 unterbricht. T 2 sperrt nun R2 und wartet auf die Freigabe von R1. Der Prozess T 1 möchte aber vor der Freigabe von R1 noch R2 reservieren und wartet nun auf T 2. Dieses Warten endet nun in einer Endlosschleife bzw. einem Deadlock. Um die beiden genannten Probleme zu vermeiden, verwendet OSEK das Ceiling Protokoll. Zum Zeitpunkt der Systemgenerierung wird jeder Ressource ihre eigene statische ceiling Priorität zugewiesen. Diese ist mindestens so hoch wie die Priorität des höchstpriorisieresten Tasks, welcher sie verwendet. Sie muss jedoch echt kleiner sein, als die Priorität aller Tasks, welche höherpriorisiert sind, als der höchstpriorisierte verwendende Task, und nicht auf die Ressource zugreifen [4]. Im einfachsten Fall also die Priorität des höchstpriorisiertesten Tasks, welcher auf die Ressource zugreift. Verwendet nun ein Task eine Ressource dessen Priorität niedriger als die ceiling Priorität der Ressource ist, so wird während der Dauer der Verwendung der Ressource die Priorität des Tasks auf die ceiling Priorität erhöht. Dieses Protokoll lässt sich auch auf Interrupts ausweiten, indem virtuelle Prioritäten für Interrupts verwendet werden, so dass für die ceiling Priorität auch die Interrupt Prioritäten mit betrachtet werden. Interne Ressourcen sind Ressourcen, welche für den User nicht sichtbar sind. Sie können nicht über GetResource oder ReleaseResource adressiert werden. Stattdessen werden sie mit Beginn des Tasks reserviert und mit dessen Unterbrechung oder Terminierung wieder freigegeben. Interne Ressourcen können nur von Tasks reserviert werden. Auch bei ihnen werden die Richtlinien des Ceiling Protokolls angewandt. Das daraus resultierende Ergebnis entspricht genau dem gewünschten Verhalten von Taskgruppen. Nicht unterbrechbare Tasks belegen die interne Ressource RES SCHEDULER. 3.7 Fehler Management OSEK stellt spezifische hook-routinen zur Verfügung, um auf bestimmte Systemaktionen mit definiertem Verhalten zu reagieren. So existieren neben dem StartupHook und dem ShutdownHook auch ein Hook für das Errorhandling. Das Betriebssystem unterscheidet zwei Arten von Fehlern, abhängig von ihrer Schwere. Anwendungsfehler sind die Fehler, bei denen ein Service nicht korrekt ausgeführt wurde, jedoch keine Inkonsistenzen im System aufgetreten sind. Das zentrale Fehlermanagement leitet den Fehlercode an die

7 dezentrale zugehörige Fehlerroutine weiter, in welcher der Anwender entscheiden muss, wie der Fehler zu behandeln ist. Fatale Fehler haben zur Folge, dass interne Daten nicht mehr korrekt sein können und das System somit gestört sein könnte. In diesem Fall führt das System automatisch ein Shutdown durch um schlimmere Folgefehler zu verhindern [4]. Die Error Hook Routine wird genau dann aufgerufen, wenn ein Systemservice einen StatusType Parameter 0 bzw. nicht E OK zurückgibt. Ein rekursiver Aufruf von der Error Hook Routine selbst kann allerdings nicht geschehen. Fehler, die innerhalb der Errorroutine auftreten, können lediglich durch das Auswerten des Rückgabeparameters erkannt werden. Um die Portierbarkeit zu vereinfachen werden Fehlercodes in Kategorien aufgeteilt. So hat jeder Teil von OSEK seinen eigenen Fehlercodewertebereich. Jeder Bereich besteht aus 32 Werten, wobei die jeweils ersten 16 Werte als Standardrückgabewerte definiert sind und die folgenden 16 Werte zur Erkennung von internen implementierungsspezifischen Fehlern dienen. Die einzige Ausnahme ist der Wert E OK = 0. Bei mehrfach vergebenen Fehlerwerten ist es die Aufgabe des Compilers einen Fehler zu werfen [3]. Nach einem Systemreset werden zunächst Hardwarespezifische Routinen aufgerufen, welche den Chip wieder in einen bestimmten Ausgangszustand versetzen. Diese Routine sollte aus Gründen der Sicherheit nicht auf der Historie des vorherigen Systemzustands basieren, sondern statisch konfiguriert sein. Da diese Routine hardwarespezifisch ist, ist sie eines der wenigen nicht portierbaren Softwareteile. Die Routine endet mit dem Starten des OSEK OS, also mit dem Aufruf von StartOS. Zum sicheren Herunterfahren des Systems, bietet OSEK den Befehl ShutdownOS an. Er kann sowohl von der Anwendung als auch vom System selbst (z.b. bei fatalen Fehlern) ausgeführt werden. Nach dem Aufruf des Befehls wird die Routine ShutdownHook aufgerufen, deren Verhalten vom User nach belieben angepasst werden kann. 4 OSEKtime OS Da das Betriebssystem OSEK für den Automobilbereich designt wurde, ist ein sehr wichtiger Faktor die Echtzeitfähigkeit, um die Sicherheit des Systems aufrecht zu erhalten. Das eigentliche OSEK OS ist vorteilhaft bei ereignisorientierten Systemen, kann jedoch bei periodischem Verhalten unvorteilhaft bezüglich der maximalen Taskverzögerung sein. Um der Anforderung an möglichst keine Verzögerungen bei periodischem Verhalten gerecht zu werden, entstand OSEKtime OS. 4.1 Tasks Tasks in OSEKtime werden sequentiell ausgeführt. Es ist möglich innerhalb eines Tasks Schleifen zu verwenden, jedoch muss sichergestellt werden, dass selbst im Worst Case Szenario eine festgelegte Ausführungszeit nicht überschritten wird. Der Zustandsgraph bei OSEKtime, welcher in Abbildung 2 zu sehen ist, unterscheidet sich in zwei Punkten maßgeblich von dem bei OSEK OS. Zunächst fällt auf, dass der Zustand waiting komplett entfallen ist. Für zeitgetriggerte Tasks ist es also nicht möglich, auf ein Ereignis zu warten. Auch das Ressourcenmanagement entfällt bei OSEKtime. Auch unterscheidet es sich beim Aktivieren der Tasks. Bei OSEK werden neu aktivierte Tasks zunächst als ready markiert und warten dann auf das Starten durch den Scheduler. OSEKtime erlaubt es

8 running terminate activate resume preempt suspended ready Abbildung 2: Lebenszyklus von zeitgetriggerten Tasks jedoch einen Task direkt beim Aktivieren vom Dispatcher starten zu lassen. Prioritäten von Tasks entfallen somit. Da jedoch immer nur ein Task gleichzeitig im Zustand running sein kann, wird folglich jeder laufende Task, von einem neu aktivierten unterbrochen. Unterbrochene Tasks werden nach dem Terminieren des unterbrechenden Tasks fortgesetzt. 4.2 Scheduling / Dispatching In OSEKtime ist es also nicht die Aufgabe des Schedulers Tasks zu ordnen und deren Ausführung zu koordinieren. Diese Aufgabe übernimmt direkt der Dispatcher. Die Auswahl erfolgt über eine vom User statisch konfigurierten Dispatchertabelle. Der Entfall von Events und Ressourcenmanagement ist durch die statische Konfiguration des Ablaufplans gerechtfertigt. Beim Erstellen der Dispatchertabelle muss also auch darauf geachtet werden, dass es nicht zu Ressourcenkonflikten kommt. Die Dispatchertabelle wird komplett sequentiell und periodisch abge1arbeitet. Eine Dispatcherrunde bezeichnet die vollständige Ausführung der Dispatchertabelle [1]. Innerhalb einer Dispatcherrunde darf ein Task mehrmals aktivert werden, sich aber in keinem Fall selbst unterbrechen. Der Dispatcher selbst wird durch Interrupts aufgerufen. Diese orientieren sich an einer lokalen Zeit, welche mit der globalen Zeit synchronisiert wird, sofern eine solche zur Verfügung steht. 4.3 Deadlines Mit der Periodizität von OSEKtime kommen auch Deadlines von Tasks zum Tragen. Jeder Task besitzt eine bestimmte Deadline. Bevor diese eintritt, muss sich der Task selbst terminiert haben. Das Einhalten der Deadlines wird vom Dispatcher überwacht. Wenn ein Task nicht innerhalb seiner eigenen Deadline terminiert, wird eine Fehlerbehandlung vom Dispatcher initiiert.

9 4.4 Leerlauf Task Die Ausnahme der Regel ist der Leerlauf Task (ttidletask). Dieser ist nicht in der Dispatchertabelle eingetragen und wird somit auch nicht von diesem periodisch aufgerufen. Auch hat er keine Deadline, die ihn zum Terminieren zwingt. Der ttidletask wird mit Start des OSEKtime OS gestartet und von jedem anderen Task unterbrochen. Wenn alle anderen Tasks terminiert sind, wird der vorher unterbrochene ttidletask wieder fortgesetzt. Da dieser nicht terminiert, ist dieser für die gesamte Systemdauer aktiv und wechselt nur zwischen den Zuständen ready und running. Bei Bedarf kann der Leerlauf Task beliebig vom Benutzer ersetzt werden um Hintergrundaktivitäten zu realisieren. 4.5 Anwendungsmodi Wie auch bei OSEK OS gibt es die Möglichkeit verschiedene Anwendungsmodi zu definieren. Diese unterscheiden sich in den Dispatchertabellen. Im Gegensatz zu OSEK OS lassen sich die Anwendungsmodi während des Betriebs umschalten. Hierzu wechselt der Dispatcher einfach die Tabelle am Ende einer Dispatcherrunde. Damit dies ohne Probleme funktioniert, müssen alle Dispatcherrunden der verschiedenen Anwendungsmodi gleich lang sein. Ein Beispiel für verschiedene Anwendungsmodi wäre die Definition von Initialisierung, Normal und Shutdown [1]. Während des Systemstarts wird der Anwendungsmodus über einen Parameter beim Aufruf von tt- StartOS übergeben. Das Umschalten des Anwendungsmodus im laufenden Betrieb übernimmt der Systemservice ttswitchappmode. Dieser sorgt dafür, dass der Modus ohne den Verlust der Synchronität zur globalen Zeit gewechselt wird. Die Synchronität zur globalen Zeit ist auch der Grund dafür, dass alle Dispatchertabellen gleich lange andauern müssen. 4.6 Interrupts Interrupts werden von OSEKtime limitiert, damit diese nicht den reibungslosen Ablauf der Dispatchertabelle stören. So wird ein Interrupt direkt nach seiner Ausführung deaktiviert. Innerhalb einer Dispatcherrunde liegen vorherbestimmte Zeitpunkte, zu denen der Dispatcher die einzelnen Interrupts wieder aktiviert. Somit kann eine maximale Anzahl an Interrupts sichergestellt werden. Sofern die Laufzeit der einzelnen Interrupts nach oben beschränkt ist, kann auch eine maximale Verzögerung innerhalb einer Dispatcherrunde garantiert werden. 4.7 Synchronisation Der Dispatcher arbeitet auf Basis der lokalen Systemzeit. Wenn jedoch eine globale Zeit zur Verfügung steht, sorgt eine Synchronisationsschicht dafür, dass die lokale Zeit an die Globale angepasst wird. Der Synchronisationsmechanismus wird beim Systemstart und nach jeder Dispatcherrunde ausgeführt. Für Anwendungen gibt es die Möglichkeit zu ermitteln, ob die lokale zeit mit einer globalen synchronisiert ist. Hierzu dient ein Systembefehl mit dem Namen ttgetossyncstatus [1]. Der Verlust der Synchronisation wird nicht explizit gemeldet. Er kann nur durch stetiges Abfragen des Synchronisationsstatus festgestellt werden. Zur Synchronisation nach dem Systemstart oder nach dem Verlust der Synchronität gibt es drei Methoden.

10 Beim Synchronen Start-up wartet der Dispatcher so lange, bis er einen geeigneten Zeitpunkt, zum starten der Dispatchertabelle, findet. Eine maximale Verzögerung ist somit nicht definierbar. Um eine maximale Verzögerung zu einzuhalten, dient der harte asynchrone Start-up. Der Dispatcher beginnt seine Arbeit, sobald er bereit ist. Wenn nun eine globale Zeit verfügbar ist, pausiert der Dispatcher nach einer Dispatcherrunde so lange, bis er mit der globalen Zeit synchron eine neue Runde starten kann. Die maximale Verzögerung entspricht also genau der Zeit einer Dispatcherrunde. Die dritte Variante ist der smooth asynchrone Start-up. Sie verläuft ähnlich zur harten Variante, wobei jedoch eine maximale Verzögerung zwischen den Runden vordefiniert ist. Die Synchronität wird dann über mehrere Runden hergestellt. Bei dieser Variante wird die Verzögerung zwischen den einzelnen Runden gering gehalten, dafür dauert aber die Synchronisierung insgesamt länger. Welche der Methoden die optimale ist, ist Anwendungsspezifisch und muss vom Benutzer gewählt werden. 4.8 Fehler Management Das Fehler Management wird analog zu dem von OSEK OS durchgeführt. Zusätzlich zu den normalen Fehlern müssen noch Deadlineverletzungen behandelt werden. Hierzu wird die tterrorhook Routine aufgerufen, in welcher der Benutzer eine eigene Fehlerbehandlung durchführen kann. Anschließend fährt das System mit einem ttshutdownos herunter. 5 Kombination von OSEKtime und OSEK OS Neben der ausschließlichen Nutzung der einzelnen Systemen, ist auch eine kombinierte Nutzung möglich. Die Spezifikation sieht vor, dass OSEK OS während des Leerlauftasks (ttidletask) ausgeführt wird. Die Priorität von OSEKtime ist also höher als alle Prioritäten von OSEK OS. Weder OSEK Tasks noch OSEK ISRs dürfen Tasks von OSEKtime verzögern [1]. Die Funktion von OSEK OS, zum Vermeiden von Interrupts, bleibt nur OSEK intern. So können Interrupts von OSEKtime auch eintreffen, während ein OSEK Task die Interruptsperre hält. Beim Systemstart wird der Service ttstartos initiiert. Erst nach dem erfolgreichen und vollständigen Start von OSEKtime, wird in dessen Idle Zeiten OSEK OS mit einem StartOS gestartet. OSEK OS darf in keinem Fall den Start von OSEKtime verzögern. Der Shutdown kann in zwei Varianten aufgeteilt werden. Zum Einen kann das OSEK OS Subsystem alleine heruntergefahren werden. Hierbei sind keine Besonderheiten zu beachten. Der ShutdownHook von OSEK OS wird aufgerufen und bearbeitet. Danach stoppt das System. OSEKtime läuft unbeeinflusst davon weiter. Der Shutdown kann durch das Abfragen des Systemstatus mittels ttgetosekosstate abgefragt werden. Die zweite Variante ist ein globaler Shutdown. Hier wird lediglich der ttshutdownhook aufgerufen. Sobald dieser terminiert, schaltet das System ab. Der ShutdownHook vom Subsystem wird nicht ausgeführt, um die Echtzeitfähigkeit von OSEKtime zu bewahren und keine Verzögerungen aufkommen zu lassen. Sofern ein Aufruf des ShutdownHooks explizit gewünscht ist, kann dieser im ttshutdownhook aufgerufen werden. Ein lokaler Shutdown des OSEK OS kann lediglich vom Subsystem selbst durch aufrufen des Befehls ShutdownOS eingeleitet werden. Der Globale Shutdown kann prinzipiell sowohl von OSEK OS als auch von OSEKtime ausgeführt werden. Die Spezifikation empfiehlt jedoch einen globalen Shutdown vom Subsystem zu vermeiden [1].

11 6 OIL Um portierbare Software zu erhalten, fehlt noch eine Möglichkeit das in OSEK spezifizierte Systemverhalten zu beschreiben. Diese Möglichkeit wurde mit der Sprache OIL (OSEK Implementation Language) festgelegt [3]. Ziel von OIL ist es, ein Verhalten von OSEK Anwendungen für eine bestimmte Hardware zu konfigurieren [2]. Folglich muss mit Anpassung der Hardware auch die OIL Beschreibung angepasst werden. Generell definiert OIL standardisierte Objekte mit bestimmten Attributen und Referenzen. Innerhalb der OSEK Implementierung können zusätzliche Attribute und Referenzen definiert werden. Das Erstellen oder Verändern von Objekten außerhalb von OIL ist jedoch nicht möglich. Dies bedeutet, dass jedes Objekt im System auch mit OIL beschrieben sein muss. Zur Identifizierung erhält jedes Objekt einen systemweiten eindeutigen Namen. Zur einfacheren Lesbarkeit und Wartbarkeit können OIL Dateien aufgeteilt werden und analog zur C Syntax included werden. Somit muss bei optimaler Verwendung beim Tausch von Hardware auch nur die entsprechende Konfigurationsdatei ausgetauscht werden. Literatur [1] OSEK/VDX group (2001): Time-Triggered Operating System Specification 1.0. Available at portal.osek-vdx.org/files/pdf/specs/ttos10.pdf. [2] OSEK/VDX group (2004): OSEK Implementation Language Specification 2.5. Available at osek-vdx.org/files/pdf/specs/oil25.pdf. [3] OSEK/VDX group (2004): Specification OSEK/VDX Specification. Available at osek-vdx.org/files/pdf/specs/binding142.pdf. [4] OSEK/VDX group (2005): Specification OSEK OS Available at files/pdf/specs/os223.pdf. [5] OSEK/VDX group (2014): OSEK VDX Portal - Goals and Motivation. Available at osek-vdx.org/index.php?id=4&itemid=4. [6] Jörg Schäuffele (2013): Automotive Software Engineering, 5., überarb. u. ak. aufl edition. Springer Fachmedien Wiesbaden, Wiesbaden. Available at term=idn%3dtt &local_base=klu01.