OSEK OS und OSEK Time

1. 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 Daniel Kasmeroglu

3. Wozu einen Standard definieren ? (1) Daniel Kasmeroglu

4. Wozu einen Standard definieren ? (2) 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 Daniel Kasmeroglu

6. Was bezweckt man mit OSEK ? • Einführung einer Referenz-Architektur • Reduktion der Entwicklungskosten • Portabilität • Wiederverwendbarkeit • Skalierbarkeit 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 Daniel Kasmeroglu

8. Der OSEK Standard (2) Daniel Kasmeroglu

9. OSEK OS (1)Funktionalitäten • Ein-Prozessor OS • Echtzeitfähig • Multitasking • Statisch • Standard API bestehend aus 35 Funktionen 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) Daniel Kasmeroglu

11. OSEK OS (3)Tasks • Nutzungsmöglichkeiten sind durch Konformitätsklasse bestimmt 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 Daniel Kasmeroglu

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

14. OSEK OS (5)Task-Zustände 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 Daniel Kasmeroglu

16. OSEK OS (7)Tasks-Scheduling (nicht preemptiv) Daniel Kasmeroglu

17. OSEK OS (8)Task-Scheduling Daniel Kasmeroglu

18. OSEK OS (9)Interrupts • ISR Kategorie 1: Kein Aufruf von OS Funktionen • ISR Kategorie 2: Aufruf von OS Funktionen (eingeschränkt) 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. 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 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 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 Daniel Kasmeroglu

23. Warum OSEK Time und nicht OSEK/VDX ? • Vorhersagbares Systemverhalten • Systemstabilität (Fehlererkennung und –toleranz) • Kompatibilität zu OSEK/VDX Daniel Kasmeroglu

24. OSEK Time (1)Architektur Daniel Kasmeroglu

25. OSEK Time (2)Prozess-Behandlung 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 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 Daniel Kasmeroglu

28. OSEK Time (5)Task-Zustände 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 Daniel Kasmeroglu

30. OSEK Time (7)Task-Scheduling 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 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 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 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 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 Daniel Kasmeroglu