Betriebssysteme in Kfz

Präsentation zum Thema: "Betriebssysteme in Kfz"—  Präsentation transkript:

1 Betriebssysteme in Kfz
OSEK OS und OSEK Time Betriebssysteme in Kfz

2 Probleme bei Eingebetteten Systemen in Kfz in den 80ern
Anzahl der Systeme steigt Hohe Entwicklungskosten durch inkompatible Hardware Geringe Wiederverwendbarkeit von Softwaremodulen auch innerhalb von Produktlinien Variantenmanagement Anstieg der Anforderungen an eingebettete Systeme (Komfort, Sicherheit, Ökonomie) 80er der ES autark, heute modular Hardware hat Hersteller abhhängige Protokolle implementiert Variantenmanagement war erforderlich um die Funktionalität einer Anwendung unter verschiedensten Umständen zu gewährleisten WS01/02 Daniel Kasmeroglu

3 Wozu einen Standard definieren ? (1)
Company 2000 Revenue 2000 Market Share % 1999 Revenue 1999 Market Share % Growth % Motorola 1,409 10.8 1,299 12.3 8.5 NEC 836 6.4 708 6.7 18.1 ST Microelectronics 807 6.2 558 5.3 44.6 Infineon 718 5.5 613 5.8 17.1 Philips 596 4.6 543 5.2 9.7 Others 8,712 66.6 6,802 64.6 28.1 Total Market 13,078 100.0 10,523 24.3 - Trotz Verkleinerung des Halbleitermarktes um 26 % in 2001, wird mit 7 % Wachstum im Automotive Sektor gerechnet - Angaben von Gartner (Dataquest) WS01/02 Daniel Kasmeroglu

4 Wozu einen Standard definieren ? (2)
- Projektion für die zukünftige Entwicklung - Hansen Report WS01/02 Daniel Kasmeroglu

5 Historisches 1993 „Initial Partners“ starten Projekt OSEK
Parallel dazu wurde VDX in Frankreich entwickelt 1994 OSEK und VDX schliessen sich zu OSEK/VDX zusammen 1995 Zusammenführung OSEK und VDX fertig 1997 Version 2.0 fertiggestellt Initial Partners sind : BMW, Bosch, Daimler-Benz, Opel, Siemens, VW und Uni Karlsruhe OSEK ist Abkürzung für „Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug“ VDX-Entwickler: PSA und Renault VDX = Vehicle Distributed eXecutive OSEK ist der Standard innerhalb Europa und zunehmends auch in USA WS01/02 Daniel Kasmeroglu

6 Was bezweckt man mit OSEK ?
Einführung einer Referenz-Architektur Reduktion der Entwicklungskosten Portabilität Wiederverwendbarkeit Skalierbarkeit WS01/02 Daniel Kasmeroglu

7 Der OSEK Standard (1) Betriebssystem: OSEK OS 2.2
Kommunikation: OSEK Communication 2.2.2 Netzmanagement: OSEK Network Management 2.5.1 Bericht bezieht sich nur auf OSEK OS, die anderen Komponenten werden später erwähnt WS01/02 Daniel Kasmeroglu

8 Der OSEK Standard (2) WS01/02 Daniel Kasmeroglu

9 OSEK OS (1) Funktionalitäten
Ein-Prozessor OS Echtzeitfähig Multitasking Statisch Standard API bestehend aus 35 Funktionen Ein-Prozessor OS, da man keinen Parallelrechner für ein ES bauen will Echtzeitfähigkeit ist erforderlich allein aufgrund der zu realisierenden Dienste Multitasking erlaubt das Betreiben mehrerer Prozesse auf einem Prozessor Statisch, da alle Betriebsmittel bereits zur Übersetzungszeit bekannt sein müssen (keine Speichergrösse entsprechend dem Worst-Case) Dynamische Speicherverwaltung kann aber implementiert werden WS01/02 Daniel Kasmeroglu

10 OSEK OS (2) Betriebsmittel
Grundlegende Betriebsmittel sind Tasks, Events und Interrupts Ferner gibt es noch Alarme und Counter Steuerung über Standard API (Version 2.2 = 35 Funktionen) WS01/02 Daniel Kasmeroglu

11 OSEK OS (3) Tasks Nutzungsmöglichkeiten sind durch Konformitätsklasse bestimmt WS01/02 Daniel Kasmeroglu

12 OSEK OS (4) Tasks Basic Tasks können nur folgendermassen beendet werden: - Task beendet sich selbst - OS wechselt zu Task mit höherer Prio - Interrupt muss behandelt werden WS01/02 Daniel Kasmeroglu

13 OSEK OS (4) Tasks Extended Tasks können durch Aufruf der Funktion ‚WaitEvent‘ in einen Wartezustand versetzt werden WS01/02 Daniel Kasmeroglu

14 OSEK OS (5) Task-Zustände
Running : Task ist im Besitz der CPU, kann maximal ein Task in diesem Zustand sein Ready: Task ist bereit zur Ausführung, der Scheduler entscheidet wann Suspended: Task ist passiv und kann wieder aktiviert werden WS01/02 Daniel Kasmeroglu

15 OSEK OS (6) Task-Scheduling
Abarbeitung der Tasks wird entweder über die Prioriät oder über die Scheduling-Politik (nicht-preemptiv, voll-preemptiv, gemischt-preemptiv) festgelegt Scheduler ist Resource und kann von Task belegt werden um Switch zu verhindern WS01/02 Daniel Kasmeroglu

16 OSEK OS (7) Tasks-Scheduling (nicht preemptiv)
Typischerweise für Tasks die kurze Lebensdauer haben WS01/02 Daniel Kasmeroglu

17 OSEK OS (8) Task-Scheduling
Typischerweise Tasks, die lange Lebensdauer haben Mischung aus preemptiv und non-preemptive wird mittels Attributtierung der Tasks erreicht WS01/02 Daniel Kasmeroglu

18 OSEK OS (9) Interrupts ISR Kategorie 1: Kein Aufruf von OS Funktionen
ISR Kategorie 2: Aufruf von OS Funktionen (eingeschränkt) - Interrupt Levels hängen von der Hardware bzw. der Implementation ab - Innerhalb der ISR kein Rescheduling WS01/02 Daniel Kasmeroglu

19 OSEK OS (10) Events Events sind Ereignisse, die nur von Extended Tasks empfangen werden können. Auslösung ist durch alle möglich. - Events sorgen für Zustandstransition (Running -> Waiting, Waiting -> Ready) WS01/02 Daniel Kasmeroglu

20 OSEK OS (11) Zeitmanagement
Alarme lösen zu bestimmten Zeiten Ereignisse aus oder starten Tasks Counter sind wie Uhren und können mit den Alarmen kombiniert werden API zur Steuerung von Alarmen und Countern ist NICHT Teil der Spezifikation WS01/02 Daniel Kasmeroglu

21 OSEK OS (12) Resourcen Resourcen sind Erweiterung zu Semaphoren um globale Daten Deadlock-frei zu behandeln. Freigabe in umgekehrter Reihenfolge der Anforderung Verwaltung mittels „Priority-Ceiling“ Protokoll Beendigung eines Tasks -> alle Resourcen frei - Vermeidung von Prioritätsumkehr (Task mit niedriger Priorität verhindert Ablauf eines Tasks mit hoher Priorität durch Belegung mittels Semaphore) - Deadlock = Gleichzeitiger Zugriff führt zu fehlerhaftem Systemzustand - Ceiling-Priority : Grösser oder Gleich der höchsten Priorität aller Tasks, die ein Betriebsmittel gebrauchen aber kleiner als die Prioritäten der Tasks, die ein Betriebsmittel nicht gebrauchen - Extended-Tasks dürfen kein Betriebsmittel belegen, wenn sie auf ein Event warten - Wenn Task Betriebsmittel anfordert, wird Task-Priorität auf Ceiling-Priorität gesetzt, damit alle anderen benutzenden Tasks kleinere Priorität haben und warten müssen - Bei Freigabe -> Wiederherstellung der Task-Priorität WS01/02 Daniel Kasmeroglu

22 OSEK OS (13) Hook-Routinen
Benutzer-Code aufgerufen durch OS Funktionen Vorrangig vor allen Tasks Keine Unterbrechung durch Kategorie 2 Interrupts Meist nicht portierbar - In OSEK gibt es Hooks fürs Hochfahren und Runterfahren (nach dem Hochfahren bevor der Scheduler startet) oder wenn Runterfahren angefragt wird - Tracing/Debugging - Fehlerbehandlung: Es gibt zwei Fehlerarten 1. Applikationsfehler - OS nimmt an, dass interne Daten trotz Fehlerhafter Anfrage korrekt sind. Globale Fehlerbehandlung wird aufgerufen. Fehlerinformation kommt der lokalen Fehlerbehandlung zu. 2. Fatale Fehler - OS nimmt an, dass interne Daten fehlerhaft sind. Globales Herunterfahren wird initiiert. - Keine rekursiven Aufrufe einer ErrorHook WS01/02 Daniel Kasmeroglu

23 Warum OSEK Time und nicht OSEK/VDX ?
Vorhersagbares Systemverhalten Systemstabilität (Fehlererkennung und –toleranz) Kompatibilität zu OSEK/VDX - Man will zu einem Zeitpunkt defini WS01/02 Daniel Kasmeroglu

24 OSEK Time (1) Architektur
WS01/02 Daniel Kasmeroglu

25 OSEK Time (2) Prozess-Behandlung
WS01/02 Daniel Kasmeroglu

26 OSEK Time (3) OSEKTime mit OSEK/VDX
OSEK/VDX Prios liegen unter denen von OSEKTime Mikrocontroller benötigt viele Interrupts Nicht-Preemptive Tasks in OSEK/VDX sind nur für OSEK/VDX NP, sonst preemptiv Resourcen können nicht geteilt werden Kommunikation nur über FTCom WS01/02 Daniel Kasmeroglu

27 OSEK Time (4) Tasks Keine Unterscheidung bei Tasks
Können nur durch die Dispatcher-Tabelle angestossen werden (Aktivierungsevent) WCET muss für jeden Task ermittelt werden können WCET = Worst Case Execution Time WS01/02 Daniel Kasmeroglu

28 OSEK Time (5) Task-Zustände
WS01/02 Daniel Kasmeroglu

29 OSEK Time (6) Task-Scheduling
Scheduling wird mittels einer Tabelle (dem sog. Dispatcher) vor dem Übersetzen festgelegt Dispatcher wird durch ein Tool erzeugt Komplette Abarbeitung eines Dispatchers bezeichnet man als eine Runde WS01/02 Daniel Kasmeroglu

30 OSEK Time (7) Task-Scheduling
Task muss sich beenden bevor die Deadline erscheint WS01/02 Daniel Kasmeroglu

31 OSEK Time (8) Systemstabilität
Deadlines der Tasks werden überwacht Monitor Einträge an den Deadlines Monitor Eintrag beliebig aber vor Beenden einer Runde Wenn globale Zeit verfügbar -> lokale anpassen WS01/02 Daniel Kasmeroglu

32 OSEK Time (9) Interrupts
ISR hat nur beschränkten Zugriff auf OS Interrupts dürfen in definierten Zeitintervallen nur einmal auftreten Abschaltung der Interrupts, sobald ISR beginnt Applikationen dürfen Interrupts nicht Ein/Ausschalten WS01/02 Daniel Kasmeroglu

33 OSEK Standard OIL steht für OSEK Implementation Language und wird benutzt um das OSEK/VDX Betriebssystem zu konfigurieren FTCom ist eine Spezifikation zur fehlertoleranten Kommunikation NM ist eine Spezifikation zur Organisation von Netzwerken WS01/02 Daniel Kasmeroglu

34 OSEK Implementationen / Tools
ERCOS ist eine Implementation der ETAS, die wiederum eine Tochter von Bosch ist. BMW Standard Core ist eine Implementation basierend auf ProOSEK von 3Soft. LEO stellt OSEK System als Prozess auf Desktop-System dar WS01/02 Daniel Kasmeroglu

35 Quellen OSEK/VDX Spezifikationen http://www.osek-vdx.org
Folie 3, Zuwachsraten, Gartner Dataquest September 2001 Folie 4, Zuwachsraten, Hansen Report Folie 8, Schematische Darstellung des OSEK Standards von 3Soft GmbH WS01/02 Daniel Kasmeroglu