OSEK/OSEKtime - ein Vergleich

Transkript

1 Technische Universität Ilmenau, Fakultät für Informatik und Automatisierung OSEK/OSEKtime - ein Vergleich Hauptseminar Wintersemester 2007/ April 2008 Angefertigt von: André Puschmann Matrikelnummer: andre.puschmann@stud.tu-ilmenau.de Betreuer: Dipl.-Inf. Johannes Klöckner johannes.kloeckner@tu-ilmenau.de

2 Inhaltsverzeichnis 1 Einleitung 3 2 OSEK/VDX-OS Architektur Tasks und Task-Management Task Konzept und Task-Kategorien Scheduling Resourcen-Verteilung Interrupt-Verarbeitung Kommunikation Fehlerbehandlung OSEKtime-OS Architektur Tasks und Task-Management Task Konzept Task-Zustandsmodell Dispatching Deadline Überwachung Interrupt-Verarbeitung Synchronisation und Kommunikation Hooks und Fehlerbehandlung Vergleich 21 5 Ausblick 23 6 Zusammenfassung 25 2

3 1 Einleitung Überblick Dieser Bericht soll die wesentlichen Merkmale der beiden Betriebssystem-Standards OSEK/VDX-OS und OSEKtime-OS herausarbeiten. Des Weiteren wird versucht, diese einander gegenüber zu stellen und zu vergleichen. Dabei bleibt zu bemerken, dass sich diese Arbeit wesentlich auf die den Betriebssystemen zugrunde liegenden Standards [6] und [4] bezieht. Ferner wird ein Ausblick auf die Betriebssystementwicklung im Bereich AUTOSAR gegeben. Historisches und Motivation Vor nicht einmal 20 Jahren war ein Automobil im Wesentlichen nur von mechanischen Teilen und Baugruppen dominiert. Heute ndet man in modernen Automobilen mehr und mehr teilweise rein elektronische, teilweise elektro-mechanische Systeme, welche im gesamten Fahrzeug verteilt sind. Diese werden durch eine Vielzahl von Mikrocontrollern überwacht und gesteuert. Diese Steuergeräte wiederum müssen auch untereinander kommunizieren, was zusätzliche Komplexität durch die aufwendige Verkabelung ins Gesamtsystem bringt. Als in den frühen 80er Jahren die ersten Mikrocontroller in Kraftfahrzeugen eingesetzt wurden, hatten diese dabei noch sehr begrenzte Aufgaben. Sie dienten beispielsweise zur Motorsteuerung oder zur Realisierung von Wegfahrsperren. Auÿerdem gab es keine oder zumindest nur eine geringe Notwendigkeit zur Kommunikation über die Steuergerätgrenzen hinaus. Software wurde damals fast ausschlieÿlich in Assembler oder C entwickelt. Sie lief natürlich auch ohne Betriebssystem direkt auf dem Mikrocontroller. Dies war Anfangs kein Problem. Doch als die Anzahl der verschiedenen Controller und damit auch deren notwendige Interaktion stieg, machte es sich mehr und mehr bemerkbar, dass es sich lohnen würde über einen einheitlichen Standard nachzudenken, welcher ganz grundsätzliche Konzepte zu regeln vermochte. Man erkannte, dass es sehr sinnvoll sein würde immer wiederkehrende Komponenten wie z.b. Betriebssystem und Kommunikationsstack zu standardisieren und somit zu vereinheitlichen. 3

4 Auÿerdem würde die Möglichkeiten zur Wiederverwendung dieser Systeme erheblich gesteigert werden. Dies wiederum spart enorme Kosten, man kann neue Entwicklungen schneller im Markt positionieren und sich somit einen Wettbewerbsvorteil verschaen. Auch Systeme verschiedener Hersteller würden somit besser zusammennden und sich leichter integrieren lassen. Diese Ziele versuchte man, zunächst getrennt in Deutschland und Frankreich, in zwei Initiativen Namens OSEK (Oene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug) und VDX zu erreichen. Im Jahr 1994 entstand durch dem Zusammenschluss beider mit OSEK/VDX ein neues industrielles Gremium mit dem Ziel Standards zu spezizieren, welche ihre hauptsächliche Ausrichtung in der Verwendung im Automobilbereich haben. Der gesamte OSEK/VDX-Standard beschreibt dabei eine Vielzahl an Komponenten moderner Automobilsteuergeräte. Den wohl wichtigsten Teil bildet hier OSEK-OS [6]. Da OSEK-OS dabei nur eine Betriebssystemspezikation beschreibt und damit keine konkrete Implementierung gemeint ist, hat sich im Umgang bei vielen Entwicklern nur der Begri OSEK eingeprägt. Man spricht in diesem Zusammenhang meist von der Implementierung, die man selbst einsetzt. Heute versucht man mehr und mehr mechanische und hydraulische Systeme fast komplett durch fehlertolerante elektronische Systeme zu ersetzen. In diesem Zusammenhang wird dabei oft von X-by-Wire-Anwendungen gesprochen. Ziel dabei ist es, ein Auto irgendwann einmal vollkommen autonom und somit ohne jegliches Zutun eines menschlichen Fahrers steuern zu können. Um diese Ziele zuverlässig verwirklichen zu können wird ein fehlertolerantes System benötigt, welches ein zeitlich korrektes und koordiniertes Interagieren gewährleistet. Diesen Anforderungen kann OSEK/VDX-OS nicht gerecht werden, da es beispielsweise die Ausführung eines bestimmten Tasks zu einem bestimmten Zeitpunkt nicht garantieren kann. Aus diesem Grund entschloss man sich zur Gründung der OSEKtime working group. Diese machte sich zur Aufgabe, ein streng zeit-gesteuertes Echtzeitbetriebssystem, inklusive einer fehlertoleranten Kommunikationsschicht, zu denieren. Der fertige Standard zu OSEKtime wurde im Jahr 2001 in der Version 1.0 veröffentlicht ([4]). 4

5 2 OSEK/VDX-OS 2.1 Architektur OSEK ist ein statisches Betriebssystem, d.h. es werden schon während der Entwicklung alle benötigten Betriebsmittel und Tasks deniert, konguriert und skaliert. Dynamische Heap-basierte Speicherverwaltung, die man heute bei fast allen modernen Desktop- und Serverbetriebssystemen ndet, sucht man in OSEK vergeblich. In OSEK-OS wird zwischen drei verschiedenen Prozesskategorien unterschieden. Der eine Typ entspricht den Interrupt-Service-Routinen, die entsprechend vom Betriebssystem selbst verwaltet werden. Typ zwei sind die s.g. Tasks. Diese Prozesse werden somit vom Scheduler betreut. Zwischen beiden genannten Entitäten existiert eine weitere Schicht, die des Schedulers. Dies ist aber nur ein logisches Konzept, welches dem Verteiler eine Priorität zwischen Interrupts und Tasks zu ordnet. Die unten aufgeführte Grak (2.1) verdeutlicht diese Architektur. Abbildung 2.1: Prozesskategorien in OSEK-OS (vgl. [7]) Überdies hinaus unterscheidet man noch vier Konformitätsklassen. Diese sagen etwas über die grundsätzliche Charakteristik bzw. Verwendungsmöglichkeiten der Tasks aus. Es wird dabei zwischen den verwendeten Task-Typen, einer möglichen Mehrfachaktivierung und der Anzahl von Tasks pro Priorität unterschieden. 5

6 2.2 Tasks und Task-Management Task Konzept und Task-Kategorien OSEK unterscheidet prinzipiell zwischen zwei unterschiedlichen Typen von Tasks. Zum einen gibt es die einfachen Tasks (engl. basic tasks). Diese sind, zumindest aus ihrer Sicht, ununterbrechbar. Das heiÿt es ist ihnen beispielsweise nicht möglich auf Ereignisse zu warten. Tatsächlich können auch einfache Tasks unterbrochen werden, dies ist z.b. der Fall wenn höher priorisierte Tasks ausgewählt werden oder Interrupts im System eintreen. Einfache Tasks können prinzipiell nur drei verschiedene Zustände an nehmen. Das entsprechende Zustandsmodell ist in Abbildung 2.2 dargestellt. Im Folgenden werden nun die Zustandsübergänge betrachtet. Ist ein Task lauähig und wurde vom Scheduler ausgewählt, so bendet er sich im Zustand Running. Wird er dabei von einem höher priorisiertem Task verdrängt, so wechselt er in den Zustand Ready. Hat er sich selbst beendet, ist also vollkommen abgelaufen, so wechselt er in den Zustand Suspended. Ob ein Task, welcher sich in diesem Zustand bendet noch einmal gestartet bzw. reaktiviert werden darf, hängt von der Konformitätsklasse ab, in der er sich bendet. Abbildung 2.2: Zustandsmodell der einfachen Tasks 6

7 Ferner existiert eine weitere Klasse, die der erweiterten oder komplexen Tasks (engl. extended tasks). Diese zeichnen sich im besonderen Maÿe dadurch aus, dass sie auf Ereignisse warten können und somit blockierbar sind. Erweiterte Tasks kennen zusätzlich zu den bereits angesprochenen Zuständen, wie in Grak 2.3 dargestellt, noch den Zustand Waiting. Versucht ein gerade laufender Task eine Nachricht zu empfangen, so gelangt dieser, falls die Nachricht zum gegenwärtigen Zeitpunkt noch nicht eingetroen ist, in diesen Zustand. Dies wird auch als blockierendes Warten bezeichnet. Ist die verlangte Ressource nun verfügbar, also bspw. die erwartete Nachricht eingetroen, so wechselt der Task wieder in den Zustand Ready und bleibt bis zum erneuten Start in diesem. Abbildung 2.3: Zustandsmodell der erweiterten Tasks Zusätzlich zu den beiden Kategorien werden Tasks aber auch wesentlich durch ihre Prioriät charakterisiert. 7

8 2.2.2 Scheduling OSEK ist ein Multitasking Betriebssystem. Tatsächlich kann auf einem Einkern- Mikrocontroller aber natürlich immer nur genau ein Prozess laufen. Das heiÿt es können sich nicht mehrere Tasks gleichzeitig im Zustand Running benden. Die Entscheidung, welcher der zur Verfügung stehenden Tasks CPU-Rechenzeit bekommt, trit dabei der Scheduler. Dieser zeichnet sich, im Vergleich zum Dispatcher (vgl. Kapitel 3) dadurch aus, dass er den zu aktivierenden Tasks bei jedem Aufruf neu bestimmt, die Reihenfolge also nicht vorgegeben ist. Um den korrekten Prozess zu wählen folgt er dabei einigen wichtigen Regeln. Zum einen werden also, wie schon erwähnt, allen Tasks Prioritäten zugeordnet. Dabei gilt: je höher der Zahlenwert, desto wichtiger ist der Task. Weiterhin gibt der OSEK-Standard drei verschiedene Algorithmen vor, welche die Verteilungscharakteristik des Schedulers beschreiben. Die einfachste Form ist die nicht-preemptive Zuteilung (vgl. Abbildung 2.4) des Prozessors, auch cooperative scheduling genannt. Diese Art lässt also einen aktiven Prozess vollständig bis zu dessen Abarbeitung laufen. Selbst wenn ein höher priorisierter Task lauähig ist, muss dieser nach der Aktivierung auf seinen Start warten. Abbildung 2.4: Taskzuteilung bei nicht-preemptivem Scheduling 8

9 Im Gegensatz dazu steht das preemptive Scheduling (Abbildung 2.5). Diese Form der Verteilung wählt immer genau den Task zur Ausführung, der die höchste Priorität hat. Somit würde also Task 2 bei dessen Aktivierung Task 1 verdrängen. Abbildung 2.5: Taskzuteilung bei preemptivem Scheduling Die dritte Art des Scheduling ist eine Mischform der beiden zuvor genannten Methoden. Dabei erhält jeder Task ein Flag, welches symbolisiert nach welchem Prinzip dieser Task zu behandeln ist. Wird diese Methode verwendet, trit der Scheduler unter Berücksichtigung dieser Eigenschaft seine Entscheidung. 9

10 2.3 Resourcen-Verteilung Eine groÿe Herausforderung bei prioritäts-basierten Systemen, auf denen gleichzeitig mehrere Tasks laufen, ist die korrekte Verteilung der Betriebsmittel. Schlieÿlich kann auf die meisten Ressourcen nur immer genau ein Prozess zugreifen. Es besteht die Gefahr eines Deadlocks. Dies sind Verklemmungen die wie folgt entstehen können: Ein niedrig-priorisierter Task (T1) belegt während seiner Ausführung eine Ressource (R1) und wird kurze Zeit später von einem höher priorisierten Prozess (T2) verdrängt. Dieser wiederum belegt während der Ausführung ein weiteres Betriebsmittel (R2). Fordert T2 nun auch noch R1 an, so wird dies nicht möglich sein, da diese Ressource bereits von Task 1 belegt ist: Task 2 blockiert folglich. Wird nun Task 1 reaktiviert und fordert seinerseits die durch Task 2 belegte Ressource 2 an, so wird auch dieser Prozess blockiert. Abbildung 2.6 veranschaulicht die Entstehung eines Deadlock. Zeit Task 1 Task 2 t1 wird aktiviert und gestartet t2 belegt Ressource 1 (R1) t3 wird verdrängt wird aktiviert und gestartet t4 belegt Ressource 2 (R2) t5 wird wieder gestartet möchte Ressource 1 (R1), wird blockiert t6 möchte Ressource 2 (R2), wird blockiert Abbildung 2.6: grasche Darstellung eines Deadlock (vgl. [7]) Weiterhin existiert das Problem der unkontrollierten Prioritätsumkehr (engl.: priority inversion). Dabei wird ein hoch-priorisierter Task T3 an seiner Ausführung durch einen nieder-priorisierten Task T1 behindert, weil dieser aktuell eine bestimmte Ressource R1 für sich reserviert hat. Normalerweise müsste T3 nun solange warten, bis T1 die Ressource freigibt. Wird nun aber eine weitere Task T2 vom Scheduler aufgerufen, so wird diese laufen, obwohl sie gegenüber 10

11 T3 niedriger priorisiert ist. Somit verzögert sich natürlich auch die Fortführung von Task T1. Erst nach Freigabe der Ressource durch T1 kann T3 seine Arbeit fortsetzen. Grak 2.7 veranschaulicht diese Problematik. Zeit Task 1 Task 2 Task 3 t1 wird aktiviert und gestartet t2 belegt Ressource t3 wird verdrängt wird aktiviert und gestartet t4 wird wieder gestartet möchte Ressource, wird verdrängt t5 wird aktiviert und gestartet t6 wird wieder gestartet beendet sich t7 gibt Ressource frei, wird verdrängt wird wieder gestartet und belegt Ressource t8 gibt Ressource frei t9 wird wieder gestartet beendet sich t10 beendet sich Abbildung 2.7: grasche Darstellung Prioritätsumkehr (vgl. [7]) In OSEK wird diesem Problem mit dem Priority-Ceiling-Protokoll entgegen gewirkt. Dieser Mechanismus behebt die ungewollte Prioritätsumkehr und verhindert dabei auch das Auftreten von Deadlocks. Dabei sind jedoch einige Regeln einzuhalten: ˆ Jeder Ressource wird eine Prioritätsobergrenze zugeordnet. Diese ist gleich der höchsten Priorität aller Tasks, die diese Ressource belegen. Gleichzeitig soll diese allerdings kleiner sein, als die Priorität anderer Tasks, welche die Ressource nicht belegen. ˆ Belegt eine Task nun ein Betriebsmittel, so steigt seine Priorität auf die Prioritätsobergrenze. Gibt sie die Ressource später wieder frei, so fällt ihre Priorität wieder auf den Ausgangswert. OSEK garantiert somit, dass eine Task nur dann in den Zustand Running versetzt wird, wenn alle benötigten Ressourcen auch zur Verfügung stehen. 11

12 2.4 Interrupt-Verarbeitung Interrupts sind kurzfristige Unterbrechungen des gerade auf einer CPU ablaufenden Programmcodes durch interne oder externe Signale. Während dieser Unterbrechung wird eine speziell zum Ereignis passende Interrupt-Service-Routine (ISR) abgearbeitet. In OSEK werden zwei Arten von Interrupt-Service-Routinen unterschieden: ISR der Kategorie 1 benutzen keine Systemfunktionen, d.h. sie kehren nach ihrer Beendigung zu der zuvor unterbrochenen Funktion zurück. Sie verursachen dabei sehr wenig Overhead. ISR der Kategorie 2 hingegen dürfen eingeschränkt Betriebssystemfunktionen aufrufen. Eine Besonderheit ist, dass nach ihrer Abarbeitung der Scheduler erneut gestartet wird und den als nächstes zu aktivierenden Task bestimmt, sofern kein weiterer Interrupt vorliegt. Es wird also nicht zwingenderweiÿe der zuvor unterbrochene Prozess wieder gestartet. Prioritäten, die den verschiedenen Interrupts zugeordnet werden können, hängen primär von der verwendeten Hardware-Plattform ab. Je feiner die Interrupts für einzelne Systemkomponenten ein- bzw. ausgeschaltet (maskiert) werden können, desto besser sind diese natürlich auch im Betriebssystem unterteilbar. Ferner besteht die Möglichkeit, mit Funktionen wie DisableAllInterrupts() und ResumeAllInterrupts(), schnell einmal alle Interrupts zu deaktivieren. Dies kann notwendig sein, wenn beispielsweise einmal sehr kurze kritische Abschnitte im System abzusichern sind. Dabei ist zu beachten, dass bei ausgeschalteten Interrupts keine weiteren Betriebssystemfunktionen, wie z.b. waitevent() aufzurufen sind. Das System würde in diesem Fall in einen Error-Hook gelangen. 2.5 Kommunikation Dieser Abschnitt beschreibt die Möglichkeiten zur Kommunikation und Synchronisation für Tasks gemäÿ OSEK/VDX-OS Version [6]. In OSEK besteht die Möglichkeit s.g. Events zur Task-Kommunikation einzusetzen. Events sind Objekte, die immer genau einem erweiterten Task zugeordnet sind und auch nur durch diesen empfangen werden können. Einfache Tasks oder 12

13 auch Interrupt-Service-Routinen können somit nur Events senden, diese aber nicht empfangen. Dies könnte bspw. die Signalisierung eines abgelaufenen Timers sein. Zusätzlich zu den hier angesprochenen, recht einfachen Mechanismen, existiert eine weitere Spezikation, welche speziell das Thema Kommunikation in eingebetteten Steuergeräten nach dem OSEK-Standard thematisiert [5]. Dieser Teil soll jedoch nicht Gegenstand dieses Berichts sein. 2.6 Fehlerbehandlung In OSEK wird dem Benutzer die Möglichkeit gegeben, vom Betriebssystem eine Reihe von Funktionen aufrufen zu lassen, um auf bestimmte Ereignisse zu reagieren. Diese Funktionen können vom Entwickler selbst implementiert werden. Sie werden Hook-Routinen genannt. Im Folgenden wird eine kleine Übersicht über einige verfügbare Hooks gegeben. Eine vollständige Liste können Sie selbstverständlich der OSEK-OS-Spezikation entnehmen. Systemstart: Kurz nach Einschalten des Gerätes wird bereits der StartupHook ausgeführt. Dieser kann beispielsweise für Initialisierungen genutzt werden. Vor dem Herunterfahren: Wird ein Steuergerät heruntergefahren, so wird kurz zuvor der ShutdownHook ausgeführt. Es ist grundsätzlich dem User überlassen, was in dieser Funktion geschieht. Eintreten/Verlassen einer Task: Wird eine Task vom Scheduler ausgewählt, so wird kurz vor der Aktivierung der passende PreTaskHook und kurz danach der PostTaskHook aufgerufen. Diese Hooks können z.b. für Zeitmessungen oder andere Debugging-Funktionalität genutzt werden. Fehlerfall: Tritt ein Fehler auf, so wird der ErrorHook aufgerufen. Eine nähere Erläuterung hierzu nden Sie im folgenden Abschnitt. Eine besondere Eigenschaft der Hook-Routinen ist, dass sie vom Betriebssystem aufgerufen werden und daher eine sehr hohe Priorität besitzen. Sie sind somit weder durch ISR noch durch Tasks unterbrechbar. Zusätzlich wird dem Benutzer eine Fehlerbehandlung zur Verfügung gestellt, die in der Lage ist, sowohl temporäre als auch permanente Fehler, ezient zentral 13

14 aber auch dezentral zu verarbeiten. Grundsätzlich werden zwei Sorten von Fehlern unterschieden: Applikationsfehler treten auf, wenn das Betriebssystem einen Systemaufruf nicht korrekt ausführen konnte, es aber trotzdem davon ausgeht, dass alle internen Daten korrekt sind. In diesem Fall ndet eine dezentrale Fehlerbehandlung statt, dabei wird es dem Benutzer überlassen, wie das Gesamtsystem mit dem Fehler umzugehen hat. Gravierende Fehler können durch OSEK nicht toleriert werden. In diesem Fall kann nicht mehr von der Korrektheit aller Daten ausgegangen werden. Ein weiterer Betrieb ist somit nicht mehr möglich, das System wird heruntergefahren. Sobald ein System-Service einen anderen Rückgabewert als E_OK liefert, wird die ErrorHook-Routine aufgerufen. Schlägt ein System-Aufruf im Error-Hook selbst fehl, so wird, um rekursive Aufrufe zu vermeiden, kein weiterer Hook ausgelöst. Tritt direkt bei der Aktivierung von Tasks oder beim Setzen von Events ein Fehler auf, so wird ebenfalls die ErrorHook-Routine gestartet. Um Fehler besser protokollieren und auswerten zu können wird weiterhin der Identier des Services gespeichert, der den Hook ausgelöst hat. Dieser kann später mit dem Makro OSErrorGetServiceId() abgerufen werden. In der Praxis existieren häug Fehlerspeicher, die eine gröÿere Anzahl an Fehlern sammeln, um diese später auswerten zu können. 14

15 3 OSEKtime-OS 3.1 Architektur OSEKtime ist ebenfalls ein Einprozessor-Betriebssystem für verteilte eingebettete Steuergeräte. Im Gegensatz zum ereignisorientierten OSEK/VDX-OS ist OSEKtime jedoch strikt zeitgesteuert. Das bedeutet, es gibt keine Tasks, die dynamisch während der Laufzeit vom Scheduler aufgerufen werden. Vielmehr wird bereits während der Entwicklung festgelegt, welche Tasks zu welchem Zeitpunkt laufen (Aktivierungszeitpunkt) und wie lange diese maximal laufen dürfen (Deadline). Dieses Konzept ermöglicht eine exakte Vorhersage, wann genau welche Task aktiviert wird. Um die im ersten Kapitel genannten Ziele, also die Realisierung von zuverlässigen X-by-Wire Anwendungen, zu erreichen, wird zusätzlich zum Determinismus auf Task-Ebene auch eine sichere Kommunikation benötigt. Aus diesem Grund wurde ein fehlertolerantes Kommunikationprotokoll namens FTCOM ( Fault Tolerant COMmunication [3]) entwickelt. Dieses regelt die Kommunikation und stellt weiterhin die Sychronität der globalen Zeit sicher. Nur gemeinsam mit FT- COM kann OSEKtime den geforderten Ansprüchen gerecht werden (vgl. [8], [10]). Abbildung 3.1 verdeutlicht diesen Ansatz. Abbildung 3.1: Architektur OSEKtime mit FTCOM-Schicht (vgl. [4]) 15

16 OSEKtime ist sicherlich eine Weiterentwicklung im Vergleich zu OSEK. Immerhin ermöglicht es Applikationen, die vorher undenkbar gewesen wären. Dabei bleibt allerdings festzustellen, das einige Aspekte moderner Multitasking-Betriebssysteme, bedingt durch die strikt zeitgesteuerte Architektur, nicht realisiert werden können. Man denke dabei beispielsweise an blockierendes Warten auf ein bestimmtes Ereignis, z.b. den Empfang einer Nachricht. Dies kann in OSEKtime nur nach dem einfachen Polling-Prinzip geschehen. Damit dieser Nachteil nicht all zu schwer wiegt, gibt es in OSEKtime die Möglichkeit ein normales OSEK quasi als Subsystem nebenher laufen zu lassen. Dieses übernimmt dabei einfach die nicht zeitkritischen Aufgaben mit allen Vor- und Nachteilen, die ein solches System dabei bietet. Es existieren somit zwei getrennte Betriebssysteme auf einem Mikrocontroller. Dabei fungiert OSEKtime jedoch als klar dominierendes Hauptelement. Grak 3.2 verdeutlicht diesen Architekturansatz. Damit die strengen zeitlichen Anforderungen weiterhin erfüllt werden können läuft OSEK dabei als niedrig-priorisierter eigenständiger Task im OSEKtime-Betriebssystemkern. Dieses Konzept sollte aus sicherheitstechnischen Gründen jedoch nur angewendet werden, wenn Interferieren durch geeignete Speicherzugrisbeschränkungen ausgeschlossen werden kann. Abbildung 3.2: OSEKtime mit integriertem OSEK (vgl. [4]) 16

17 3.2 Tasks und Task-Management Task Konzept In OSEKtime können Tasks keine statischen Prioritäten zugeordnet werden. Tatsächlich laufen sie immer nach einem zuvor vorgeschriebenen Muster strikt hintereinander ab. Sie werden zu ihrem Aktivierungszeitpunkt aufgerufen, können unter Berücksichtigung ihrer Deadline auch unterbrochen werden, laufen dann aber bis zu ihrer selbstständigen Beendigung Task-Zustandsmodell Prozesse müssen, wie in jedem Multitaskingsystem, auch in OSEKtime in der Lage sein ihren eigenen Zustand zu wechseln. Wie in Abbildung 3.3 zu erkennen ist, kann jeder Task dabei einen von drei Zuständen einnehmen, wobei sich immer nur genau ein Task im Zustand Running bendet. Da ein Warten auf Ereignisse nicht möglich ist, existiert dementsprechend auch kein Zustand Wartend. Sobald der Aktivierungszeitpunkt eines Prozesses ansteht, ist garantiert, dass dieser auch aktiviert wird. Beansprucht also eine Task dabei gerade die CPU, so wird diese in den Zustand Preempted versetzt. Zeitgesteuerte Tasks können somit stets die Ausführung anderer zeitgesteuerter Tasks unterbrechen. Dies stellt unter Berücksichtigung aller Task-Deadlines keinen Widerspruch dar. Abbildung 3.3: Taskzustandsmodell OSEKtime (vgl. [4]) 17

18 3.2.3 Dispatching Task Aktivierungen erfolgen stets durch den OSEKtime Dispatcher. Dieser arbeitet dabei nach einem zuvor festgelegten Schema, welches in der s.g. Dispatchertable hinterlegt ist. Da das Bestimmen des Tasks, welcher als nächstes in den Zustand Running versetzt werden soll, nicht vollständig dynamisch zur Laufzeit geschieht, spricht man in diesem Zusammenhang auch nicht von Scheduling. In der meist durch ein externes Tool erzeugten Dispatcher-Tabelle ist der genaue Ablaufplan des Systems enthalten. Dies betrit sowohl die spezischen Aktivierungszeiten aller Tasks, als auch deren Deadlines (Worst-Case-Execution-Time). Ein kompletter Durchlauf der gesamten Tabelle wird als Dispatcher-Round bezeichnet. Diese wird, initiiert durch einen Interrupt, stets zyklisch vollzogen. Da der Ablauf oline erstellt und überprüft wird, kann auch ein Einhalten der kritischen Zeiten bei hohen Lastsituationen gewährleistet werden. Eine besondere Stellung beim Dispatching nimmt der Idle Task ein. Dieser wird immer dann aufgerufen, wenn in einer Runde bereits alle anderen Tasks abgearbeitet sind. Wird OSEKtime parallel mit einem OSEK-Betriebssystem verwendet, so kann jenes in dieser Zeit laufen. Wie schon erwähnt, beeinträchtigt es dabei nicht die Ausführung der zeitkritischen Tasks. Grak 3.4 verdeutlicht die zeitgesteuerte Task-Aktivierung. Task 1 bis 3 werden jeweils an ihren Aktivierungszeitpunkten aufgerufen. Läuft keiner der zeitgesteuerten Prozesse so wird der Idle-Task bzw. das integrierte OSEK aufgerufen. Abbildung 3.4: zeitgesteuertes Scheduling in OSEKtime 18

19 3.2.4 Deadline Überwachung Ein wichtiger Parameter eines Tasks ist seine Deadline, also der Zeitpunkt, an dem er spätestens abgearbeitet sein muss. In OSEKtime wird daher für jeden Prozess die Deadline überwacht. Diese Aufgabe wird vom Dispatcher übernommen. Dazu wird für jeden Task in der Dispatching-Tabelle, an einer bestimmten Stelle, ein so genannter Beobachter installiert. Man unterscheidet dabei zwei verschiedene Varianten: Strenge Deadline Überwachung: Hierbei wird der Beobachter direkt am Zeitpunkt der Deadline platziert. Nicht-Strenge Deadline Überwachung: Der Beobachter wird nach der Deadline, aber noch in der aktuellen Runde, positioniert. Wird während das System läuft eine Verletzung der Deadline (engl.: deadline violation) festgestellt, wird sofort eine entsprechende Fehlerbehandlung gestartet. 3.3 Interrupt-Verarbeitung In zeitkritischen Systemen muss besonders sorgfältig mit unvorhersehbaren Situationen umgegangen werden. Interrupts können theoretisch zu jedem beliebigen Zeitpunkt ausgelöst werden. Wird jedes Mal sofort deren Bearbeitung durchgeführt, kann von Determinismus sicherlich keine Rede mehr sein. Die Einhaltung der Task-Deadline ist somit gefährdet. OSEKtime löst dieses Problem, indem es jedem Interrupt ein festes Intervall zur Verfügung stellt, in welchem dieser maximal einmal auftreten darf. Tritt dieser tatsächlich auf, wird er nach seiner Abarbeitung wieder ausgeblendet. Zu Beginn des angesprochenen Intervalls muss der Interrupt natürlich vom Betriebssystem wieder aktiviert werden. Etwas anders verhält es sich mit nichtmaskierbaren Interrupts. Man sollte sie bedacht einsetzen. Es könnte die zeitlich korrekte Ausführung anderer Prozesse beeinträchtigen, wenn unvorhergesehene Interrupts CPU-Rechenzeit beanspruchen. 19

20 3.4 Synchronisation und Kommunikation Wie einleitend bereits erwähnt, setzt sich ein vollständiges OSEKtime-System aus zwei unabhängigen Komponenten zusammen. Zum Einem das eigentliche Betriebssystem, OSEKtime-OS, zum Anderen die fehlertolerante Kommunikationsschicht FTCOM. Nur gemeinsam sind diese in der Lage, alle gestellten Anforderungen zu erfüllen. Die grundlegende, von FTCOM zur Verfügung gestellte, Funktionalität umfasst somit folgende Punkte: ˆ fehlertollerante Kommunikation zwischen Tasks eines oder mehrerer Knoten ˆ Bereitstellung einer globalen Zeit für alle Geräte Es ist zu bemerken, dass Fehlertoleranz dabei mehrere Aspekte umfasst. Dem Verlust von Nachrichten wird durch mehrmaliges Senden (Redundanz) vorgebeugt. Auch dem zu häugen Senden von Nachrichten oder dem Senden von falschen Nachrichten wird Sorge getragen. Für weiterführenden Informationen möchte ich an dieser Stelle auf die FTCOM- Spezikation [3] verweisen. 3.5 Hooks und Fehlerbehandlung Die Fehlerbehandlung in OSEKtime ist prinzipiell gleich zu der in OSEK/VDX- OS. Eine Besonderheit stellt jedoch eine Deadline-Verletzung dar. Wird diese vom Dispatcher festgestellt, ruft das System sofort die tterrorhook()-routine auf. Es wird ein spezieller Fehlercode TT_E_OS_DEADLINE übergeben. Dadurch ist der Benutzer in der Lage eine applikationsspezische Fehlerbehandlung zu implementieren. Sobald der ErrorHook verlassen wird, ruft das System die Funktion ttshutdownos() auf. 20

21 4 Vergleich Architektur Beides sind statische Systeme. Sie werden schon während der Entwicklungszeit deniert und konguriert. In OSEK wird zusätzlich jedem Prozess eine bestimmte Priorität zugeordnet. In OSEKtime wird der zeitliche Ablauf aller Tasks und möglicher ISR schon während der Entwicklung festgelegt. Der Fokus liegt somit klar auf der Einhaltung der zeitlichen Vorgaben. Task-Management OSEK unterscheidet zwei unterschiedliche Arten von Tasks. Einfache Tasks sind für Aufgaben gedacht, die ohne jegliche Synchronisationspunkte laufen können. Es wäre beispielsweise möglich, einen Debug-Task, der den aktuellen Systemstatus auf einem LCD-Display ausgibt, als einfachen Task zu denieren. Erweiterte Tasks hingegen können zusätzlich blockierend auf Ereignisse warten. In OSEK wird jedem Task eine Priorität zugeordnet. Der Scheduler bestimmt während der Laufzeit, welchem Prozess, zu welchem Zeitpunkt, Rechenzeit zugeteilt wird. OSEKtime- OS hingegen kennt nur eine Gruppe von Tasks. Diesen wird auch keine Priorität zugeordnet. Vielmehr wird vom Entwickler in einer Ablauftabelle statisch festgelegt, wann genau welcher Prozess laufen wird. Der Dispatcher koordiniert und überwacht dabei das Geschehen und achtet auf die Einhaltung der Zeitvorgaben. Resourcen-Verteilung Da auf OSEKtime-Systemen von vornherein feststeht, wann welcher Task läuft und welche Ressourcen diese benötigt, sind gesonderte Maÿnahmen, bspw. zur Vermeidung von Verklemmungen, nicht notwendig. In OSEK hingegen können diese prinzipiell ohne Weiteres auftreten. Dies wird jedoch durch das Priority-Ceiling- Protokoll verhindert. 21

22 Interrupt-Verarbeitung Um ein deterministisches Verhalten zu erlangen dürfen in OSEKtime selbst Interrupts nur zu bestimmten Zeiten verarbeitet werden. Zusätzlich wird dabei sogar die maximale Anzahl begrenzt. In OSEK hingegen können Interrupts zu jedem Zeitpunkt auftreten. Sie werden dabei sofort von der entsprechenden ISR bearbeitet. Kommunikation In OSEK besteht die Möglichkeit Events zur Kommunikation einzusetzen. So kann eine Applikation ereignisgesteuert realisiert werden, indem ISR oder Tasks Nachrichten an andere Tasks senden, wenn diese beispielsweise eine bestimmte Aufgabe erfüllt haben. Der Empfänger wartet somit blockierend auf ein Ereignis. OSEKtime stellt direkt keinen Mechanismus zur Kommunikation von Tasks untereinander zur Verfügung, da gerade das blockierende Warten ausgeschlossen ist. Dennoch bietet die FTCOM-Schicht auch im zeitgesteuerten Betrieb Möglichkeiten zur Kommunikation. Diese kann dann jedoch nur nach dem Prinzip des Polling funktionieren. Fehlerbehandlung Die Behandlung von Fehlern ist bei beiden Systemen vergleichbar. Durch den Einsatz im sicherheitskritischem Umfeld ist es selbstverständlich, dass selbst im Fehlerfall ein vorher bestimmtes Verhalten gewährleistet wird. Zielplattform Während der hauptsächliche Einsatzort von OSEK-OS eher bei klassischen Automotivesteuergeräten oder sogar im Infotainmentbereich liegt, so zielt OSEKtime- OS klar auf sicherheitsrelevante X-by-Wire Anwendungen oder andere zeitkritische Aufgaben. 22

23 5 Ausblick AUTOSAR (AUTomotive Open System ARchitecture) ist eines der aktuellen Schlagwörter in der Automobilindustrie. Es greift die Grundgedanken von OSEK und OSEKtime auf und versucht diese konsequent fortzuführen. Ziel ist die Komplexität moderner Systeme weiter herunterzubrechen. Es werden neue Software- Architekturen geschaen, welche eine weitgehende Entkopplung von Software und Hardware erreichen sollen. Um grundlegende Funktionen, wie etwa dem Nachrichtenaustausch, soll sich der Entwickler fortan keine Gedanken mehr machen müssen. Einzelne Applikationen werden zu so genannten Software-Komponenten zusammengesetzt. Dabei soll insgesamt auch für mehr Durchsichtigkeit in den Modulen gesorgt werden. Die Kooperation von Autohersteller und Zulieferrmen soll im Softwarebereich verstärkt und weiter vereinfacht werden. Zusätzlichen sollen Produkte über Ihren gesamten Lebenszyklus wartbar und updatebar sein. Der gesamte AUTOSAR-Standard umfasst eine ganze Reihe von Dokumenten. Es werden darin auch Themen wie Qualitätssicherung, Software-Integration und Kongurations- Management, aber auch technische Aspekte, wie Fehlerdiagnose und automatische Codegenerierung, besprochen. In diesem Abschnitt sollen die wesentlichen Kernelemente von AUTOSAR im Bereich des eigentlichen Betriebssystem AUTOSAR-OS [2] angesprochen werden (vgl. [9]). Um den stetig steigenden Hunger nach neuen Funktionen erfüllen zu können, versucht man ganz neue Wege zu gehen. Früher ging der Trend immer in Richtung zusätzlicher Steuergeräte. Da diese natürlich untereinander auch kommunizieren müssen, erhöht sich die Komplexität durch aufwendige Verkabelung mehr und mehr - ein Teufelskreis. Ein Ausweg aus diesem Dilemma könnte die Ausführung mehrerer autarker Anwendungen auf einem einzigen Mikrocontroller sein. Es wäre zwar auch möglich mehrere Tasks in einem OSEK-Betriebssystem laufen zu lassen. Da diese aber nicht strikt voneinander getrennt laufen, könnte im Ernstfall ein Fehler in einem System den gesamten Mikrocontroller zum Absturz bringen. Es fehlt also an geeigneten Schutzmechanismen. 23

24 Diese Lücke versucht AUTOSAR-OS, zusammen mit passender Steuergeräte- Hardware, denn diese muss die speziellen Methoden auch unterstützen, zu schlieÿen. Dazu werden alle Anwendungen (Tasks und ISR) in Vertrauenskategorien geordnet. Ist eine Task oder ISR bspw. als vertrauenswürdig (engl.: trusted) deniert, darf diese uneingeschränkt auf alle Ressourcen, bspw. Speicher oder Register, zugreifen. Nicht-vertrauenswürdige (engl.: non-trusted) Prozesse hingegen haben nur eingeschränkten Zugri und obliegen besonderen Schutzmechanismen. Diese Unterteilung soll bspw. die Integration von Softwareteilen anderer Anbieter in Steuergeräte vereinfachen. Es ist verständlich, dass das Betriebssystem selbst und deren Zusatzfunktionen als trusted eingestuft werden. Sollen Bibliotheksfunktionen aufgerufen werden, so laufen diesem in dem Kontext, in dem auch die aufrufende Applikation arbeitet. CallTrustedFunction() kann benutzt werden, um vertrauenswürdige Funktionen aus non-trusted Funktionen heraus aufzurufen. Wie schon aus OSEK bekannt, existieren zur Fehlerbehandlung auch in AUTOSAR so genannte Hook-Routinen. Neu ist hierbei der ProtectionHook. Tritt z.b. eine Speicherschutzverletzung auf, so wird dieser direkt aufgerufen. Hier kann der Benutzer das genaue Verhalten im Fehlerfall spezizieren. Auch Scalability Classes sind dem Leser dieses Berichtes bekannt. Diese beschreiben, ähnlich wie Konformitätsklassen, auch hier die verschiedenen Ausbaustufen des Betriebssystems. Die unterschiedlichen Schutzmechanismen der einzelnen Klassen werden in AUTOSAR besonders deutlich. Abbildung 5.1: AUTOSAR-OS Scalability Classes (vgl. [1]) 24

25 6 Zusammenfassung Abschlieÿend kann man sagen, dass sich die beiden hier vorgestellten Betriebssysteme grundsätzlich in Architektur und Verhalten unterscheiden. Das neuere OSEKtime soll jedoch keineswegs als Ersatz für OSEK verstanden werden. Vielmehr stellt es dem Benutzer ein, auf besondere Aufgaben und Anforderungen angepasstes, Betriebssystem zur Verfügung. AUTOSAR greift die Gedanken beider Systeme auf und versucht diese durch zusätzliche Verbesserungen fortzuführen. Ob die angestrebten Ziele durch die neuen Methoden wirklich erreicht werden können wird die Zeit zeigen. Der Fakt, dass nahezu alle groÿen Fahrzeughersteller und Lieferanten AUTOSAR auf breiter Front unterstützen wollen, spricht jedenfalls für den Erfolg des Systems. Auch wenn es sicherlich nicht das von vielen ersehnte Allheilmittel sein wird, so sind die Ansätze, die die Komplexität moderner Fahrzeugelektronik reduzieren sollen, vielversprechend, wenn auch nicht neu. Denn Aspekte wie Kapselung von sicherheitsrelevanten Funktionen in eigene Adressräume oder Abstrahierung, sind schon aus anderen Systemen bekannt. 25

26 Literaturverzeichnis [1] Denis Eberhard. Funktionskapselung in Steuergeräten, Dezember Vortrag beim Workshop PEARL 2007 zum Thema Mobilität und Echtzeit [2] AUTOSAR GbR. AUTOSAR Specication of Operating System, Juli [3] OSEK Group. OSEK/VDX fault tolerant communication Spezikation, Juli [4] OSEK Group. OSEK/VDX time triggered operating system Spezikation, Juli [5] OSEK Group. OSEK COM Spezikation, Juli [6] OSEK Group. OSEK OS Spezikation, Februar [7] Wilhelm Haas. OSEK / OSEKtime OS, Juli handout/osek.pdf. [8] Gregor Kaleta. OSEKtime - Time-Triggered OSEK/OS, [9] Martin Markert. Multiple Applikationen in Steuergeräten, multiple-applikationen-in-steuergeraeten/. [10] Dr. Jochen Schoof. OSEKtime - Betriebssystemstandard für X-by-wire,

27 Eidesstattliche Erklärung Ich versichere, dass ich diese Arbeit selbsständig verfasst, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und alle wörtlich und sinngemäÿ übernommenen Textstellen als solche kenntlich gemacht habe. Dies gilt auch für die in der Arbeit enthaltenen Zeichnungen, Skizzen und graphischen Darstellungen. André Puschmann