OSEK Deadline-Analyse GmbH Erlangen Jürgen Scherg 8. Juni 2001
Ein Programmtest muß unter verschiedenen Gesichtspunkten durchgeführt werden. verschiedene Testmethoden sind notwendig. Blackbox : Es wird das IO-Verhalten von Modulen und Teilsystemen getestet. Whitebox : Es wird getestet ob das Programm intern richtig abläuft und die richtigen Programmzustände einnimmt. Echtzeitverhalten : Es wird getestet ob das Programm die Zeitkriterien erfüllt. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 2
Um eine Applikation auf ihr Echtzeitverhalten hin zu testen ist eine statische Analyse der Applikation im Zusammenhang mit dem eingesetzten Betriebssystem notwendig. Bestehende Techniken RMA : (Rate Monotonic Analysis). Entstanden an der Carnegie Mellon University in Pittsburg. DMA : (Deadline Monotonic Analysis). Entwickelt von Ken Tindell, Mitarbeiter der Firma Northern Real-Time Applications. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 3
RMA und DMA sind i.a. nicht auf OSEK übertragbar, da sie starke Einschränkungen an die Applikation und Betriebssystem haben Entwicklung der OSEK Deadline-Analyse. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 4
Taskablauf und Definition Deadline act wait(1) set(1) wait(2) set(2) wait(3) set(n) termm τ i C 0 C 1 C 2 C n Deadlinezeit t Deadline τ i : Task Nr i - C i : Laufzeit von τ i - act: Aktivierung von τ i term: Terminierung der Task wait(k): Zeitpunkt zu dem die Task auf Events wartet. set(k): Zeitpunkt an dem Events gesetzt werden. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 5
Die Ausführung von τ i kann beeinflußt werden durch: 1: Eine niedriger priosierte Task τ k, die vor act gestartet wird. 2: Höher priorisierte Tasks, die während D aktiviert und vollständig abgearbeitet werden. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 6
Bestcase: Terminierung vor der Deadline Prio t 0 t 1 t 2 t n act wait(1) set(1) wait(2) set(2) wait(3) set(n) term B 0 B 1 B 2 B n C 0 C 1 C 2 C n τ i τ k A A A A V 0 V 1 V 2 V n D 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 7
Worstcase: Terminierung nach der Deadline Prio t 0 t 1 t j act wait(1) set(1) wait(2) set(j) set(j+1) set(j+2) set(n) term B 0 B 1 B j τ i C 0 C 1 Crest j A A A τ k V 0 V 1 V j D t Crest j : Restlaufzeit von nach set(j). Crest = n j C l l= j 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 8
Berechnung der Verzögerungszeit Prio set(j) B j t j Idle B j1 B j2 B j3 B j4 B j5 B j (m-1) B jm Crest j τ i τ k A V j D Bezeichnungen: B jl : Laufzeit einer einzelnen höherpriorisierten Task τ l. m B j : B j = l= 1 B j l = Summe der Laufzeiten der höher priorisierten Tasks. Idle : Verbleibende Laufzeit für τ i bis zur Deadline. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 9
OSEK Scheduling - Eigenschaft Zum Zeitpunkt set(j) gilt: A + B j + Crest j < t j dann kann τ i noch innerhalb der Deadline abgearbeitet werden. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 10
Abschätzung von A Es müssen folgende Fälle unterschieden werden: a(τ k ):= Verzögerung durch Task τ k prio(τ k ) < prio(τ i ) τ k ist nicht preemptive a(τ k ) = C(τ k ) prio(τ k ) < prio(τ i ) τ k ist preemptive τ k belegt Resourcen a(τ k ) = C(τ k ). prio(τ k ) < prio(τ i ) τ k ist preemptive τ k belegt keine Resourcen a(τ k ) = 0. A = max { a( τ ) prio( τ ) < prio( τ )} k k i 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 11
Beispiel: Verzögerung durch eine niederpriorisierte Task, die eine Resource belegt. GetResource() set(j) t j Prio ReleaseResource() B j Idle τ k Crest j τ i τ k A 1 A 2 V k D 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 12
Abschätzung von B i Unterscheidung in periodische und aperiodische Tasks B j := Summe der Laufzeiten der periodischen Tasks B j := Summe der Laufzeiten der aperiodischen Tasks B j = B j + B j 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 13
t k ist periodisch Basic-Task set(j) t j act act act act act act p k τ k C(τ k ) τ i D 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 14
Bezeichnungen: p k := Periode von τ k (Periode der Aktivierungen) m k := Höchstzahl der zulässigen Aktivierungen (Attribut MultipleActiviation ) τ k wird während t j maximal t j /p k mal aktiviert τ k wird während t j maximal t i /p k + m k mal abgearbeitet τ k benötigt während t j maximal ( t j /p k + m k )* C(τ k ) Zeit. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 15
Für alle τ k mit prio(τ k ) prio(τ i ) und τ k ist periodisch bestimme: B jk = t p j k + m k * C( τ k ) und berechne B ' = k j B jk 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 16
t k ist aperiodisch Für eine aperiodische Task kann man nicht deterministisch bestimmen wie oft sie während t j aktiviert und abgearbeitet wird. Theoretisch kann sie unendlich oft aktiviert werden. set(j) t j act act act act act act τ k C(τ k ) τ i D 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 17
Einfache Lösung: Schätze ab wie oft t k während t j höchstens aktiviert werden kann. Dieser Faktor sei mit α jk bezeichnet. Verzögerung durch t k beträgt: α jk * C(t k ) Zeiteinheiten. Für alle τ k mit prio(τ k ) prio(τ i ) und τ k ist aperiodisch bestimme: und berechne B j k B = α '' j k = k * C( τ k ) j B jk 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 18
Tasklaufzeiten Deadline-Analyse erfordert Wissen über Tasklaufzeiten: experimentelle Ermittlung z.b. in OSEK über Pre/PostTaskHook nur sinnvoll bei keinem oder geringem Jitter Abschätzung der maximalen Laufzeit z.b. durch Bestimmung des maximalen Pfades zweckmäßig bei komplexen Tasks Vorsicht: Abschätzung gefährdet Aussagekraft! Je ausgelasteter das System, desto genauere Werte erforderlich. 2000 3SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 19