OSEK OS und OSEK Time Betriebssysteme in Kfz. WS01/02Daniel Kasmeroglu 2 Probleme bei Eingebetteten Systemen in Kfz in den 80ern Anzahl der Systeme steigt

OSEK OS und OSEK Time

Betriebssysteme in Kfz

WS01/02 Daniel Kasmeroglu2

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


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 100.0 24.3


Wozu einen Standard definieren ? (2)


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


Was bezweckt man mit OSEK ?

Einführung einer Referenz-Architektur Reduktion der Entwicklungskosten Portabilität Wiederverwendbarkeit Skalierbarkeit


Der OSEK Standard (1)

Betriebssystem: OSEK OS 2.2 Kommunikation: OSEK Communication 2.2.2 Netzmanagement: OSEK Network

Management 2.5.1


Der OSEK Standard (2)


OSEK OS (1)Funktionalitäten

Ein-Prozessor OS Echtzeitfähig Multitasking Statisch Standard API bestehend aus 35 Funktionen


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)


OSEK OS (3)Tasks

Nutzungsmöglichkeiten sind durch Konformitätsklasse bestimmt


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


OSEK OS (4)Tasks

Extended Tasks können durch Aufruf der Funktion ‚WaitEvent‘ in einen Wartezustand versetzt werden


OSEK OS (5)Task-Zustände


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


OSEK OS (7)Tasks-Scheduling (nicht preemptiv)


OSEK OS (8)Task-Scheduling


OSEK OS (9)Interrupts

ISR Kategorie 1:Kein Aufruf von OS Funktionen

ISR Kategorie 2:Aufruf von OS Funktionen

(eingeschränkt)


OSEK OS (10)Events

Events sind Ereignisse, die nur von Extended Tasks empfangen werden können.

Auslösung ist durch alle möglich.


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


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


OSEK OS (13)Hook-Routinen

Benutzer-Code aufgerufen durch OS Funktionen

Vorrangig vor allen Tasks Keine Unterbrechung durch Kategorie 2

Interrupts Meist nicht portierbar


Warum OSEK Time und nicht OSEK/VDX ?

Vorhersagbares Systemverhalten Systemstabilität (Fehlererkennung und –

toleranz) Kompatibilität zu OSEK/VDX


OSEK Time (1)Architektur


OSEK Time (2)Prozess-Behandlung


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


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


OSEK Time (5)Task-Zustände


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


OSEK Time (7)Task-Scheduling


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


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


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


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


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

Documents

OSEK OS und OSEK Time Betriebssysteme in Kfz. WS01/02Daniel Kasmeroglu 2 Probleme bei Eingebetteten Systemen in Kfz in den 80ern Anzahl der Systeme steigt