OSEK Deadline-Analyse

Transkript

1 OSEK Deadline-Analyse GmbH Erlangen Jürgen Scherg 8. Juni 2001

2 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 2

3 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 3

4 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 4

5 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 5

6 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 6

7 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 7

8 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 8

9 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 9

10 OSEK Scheduling - Eigenschaft Zum Zeitpunkt set(j) gilt: A + B j + Crest j < t j dann kann τ i noch innerhalb der Deadline abgearbeitet werden SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 10

11 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 11

12 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 12

13 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 13

14 t k ist periodisch Basic-Task set(j) t j act act act act act act p k τ k C(τ k ) τ i D SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 14

15 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 15

16 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 16

17 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 17

18 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 18

19 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 SOFT GmbH / Jürgen Scherg: OSEK-Testkonzept 8. Juni 2001 Folie 19