SysWCET: Ende-zu-Ende-Antwortzeiten für OSEK-Systeme

Um Rechtzeitigkeit von Aufgaben in Echtzeitsystemen garantieren zu können ist die Bestimmung von schlimmstmöglichen Antwortzeiten unerlässlich. Hierbei ist die Herausforderung die präzise Analyse aller Aktivitäten des Gesamtsystems, wie synchrone Systemaufrufe und asynchrone Interrupts, ohne allzu pessimistische Annahmen zu treffen. Der Analyseansatz SysWCET kann hier weiterhelfen.

Anbieter zum Thema

Parasoft® Deutschland GmbH

RTI Real-Time Innovations

Die schlimmstmögliche Antwortzeit (engl. worst-case response time, WCRT) für die Abarbeitung einer Aufgabe ist eine entscheidende Größe von Echtzeitsystemen, die innerhalb bestimmter Zeitschranken Ergebnisse bereitstellen müssen. Die WCRT bemisst die Dauer vom Auftreten eines (physikalischen) Ereignisses (z.B. Eintreffen eines Hardwareinterrupts) bis zur Bereitstellung des Ergebnisses (z.B. Setzen eines Motorstellwertes). Sie kennzeichnet somit die Ende-zu-Ende-Antwortzeit einer Aufgabe.

Betrachtet man nun ein System das mehrere Aufgaben, mittels mehrerer Fäden (engl. Threads) abarbeitet, so ist die Berechnung der WCRT einer Aufgabe deutlich komplexer als die Berechnung der schlimmstmöglichen Ausführungszeit (engl. worst-case execution time, WCET) der Aufgabe unter Vernachlässigung anderer Threads. Beispielsweise können Hardwareinterrupts einen in Ausführung befindenden Thread asynchron unterbrechen, was zu einer Verlängerung der Antwortzeit des unterbrochenen Threads führt. Außerdem kann die Aktivierung des Echtzeitbetriebssystems (engl. real-time operating system, RTOS), mittels eines Systemaufrufs, zu einer Verdrängung führen, falls ein hochpriorerer Thread lauffähig wird.

Bildergalerie

Beide Fälle, asynchrone und synchrone Verdrängungen, können darüber hinaus auch kombiniert auftreten, wenn das RTOS in der Interruptbehandlung aktiviert wird. Folglich muss in jedem Fall für die korrekte Berechnung der WCRT einer Aufgabe immer das gesamte System (RTOS, Interrupts, andere Threads) berücksichtigt werden.

Probleme mit zusammengesetzter Antwortzeitanalyse

Traditionell wird die WCRT Analyse in zwei Schritten vollzogen. Zuerst wird jede Aktivität (Threads und Interruptbehandlungen) in Isolation betrachtet und eine WCET pessimistisch berechnet. Hierbei agiert das RTOS als eine Grenze, welche die Analyse nicht überschreiten kann. Im zweiten Schritt werden dann diese WCETs pessimistisch anhand der Schedulingstrategie akkumuliert. So werden, auf die WCET der betrachteten Aufgabe, die WCETs aller höherprioren Aufgaben aufgeschlagen.

Im Beispiel wird zunächst für beide Threads (A, B), die Interruptserviceroutine (ISR), und das RTOS eine WCET berechnet (ISR=300, A=103, B=200, RTOS=21). Will man nun die WCRT für Thread A berechnen, so startet man mit der WCET von A: 103 Zyklen. Hat nun Thread B eine höhere Priorität, so kommen die Kosten für B und die zweifache Aktivierung des RTOS (hin und zurück) hinzu: 103+2x21+200=345 Zyklen. Bei einer Aktivierung der ISR, kommt man auf insgesamt: 345+2x21+300=687 Zyklen.

Das Problem mit dieser zusammengesetzten WCRT Analyse ist zum einen ihre grobe Granularität auf Threadebene, sowie die fehlende Möglichkeit Beeinflussungen zwischen den Threads zu formulieren. In den wenigsten Echtzeitsystemen sind die einzelnen Aufgaben unabhängig voneinander. Der längste Pfad in einem Thread kann unter Umständen nicht zeitgleich mit dem längsten Pfad im anderen Thread auftreten. Dazu wird nun das vorherige Beispiel in größerer Detailtiefe betrachtet.

Aus dem Kontrollflussgraph von Thread A wissen wir, dass Thread B nur dann aktiviert werden kann, wenn der rechte Pfad, welcher nicht der längste Pfad durch A ist, abgelaufen wird. Außerdem ist anzunehmen, dass nicht jeder Pfad durch den Kernel die gleiche Ausführungszeit hat. Bereits mit diesem Wissen, das direkt aus der Struktur des Gesamtsystems ableitbar ist, kann eine präzisere WCRT Abschätzung vorgenommen werden.

Weiterhin haben Domänenexperten häufig weiteres Wissen über das Verhalten des Systems. Zum Beispiel kann das Auftreten von Interrupts eingeschränkt sein und nur im linken Pfad von Thread A auftreten. Außerdem ist es möglich, dass die ISR den ersten der beiden Ausgänge nimmt, wenn sie Thread A unterbricht.

Bringt man nun all dieses Wissen zusammen, so ist zu erkennen, dass der Pfad der die längste WCRT für dieses Beispielsystem ausmacht folgenden Verlauf hat: Start in Thread A, rechter Pfad, Aktivierung und Wechsel zu Thread B, Abarbeitung von B, Wechsel zu A, Ende in A. In Summe ergibt das eine WCRT von 1+10+14+200+11+2=238 Zyklen, welche deutlich präziser ist als die durch zusammengesetzte Analyse bestimmte WCRT von 687 Zyklen.

In unserer Forschung haben wir SysWCET[1] entwickelt: eine automatisierte Ende-zu-Ende Antwortzeitanalyse für OSEK Systeme. In einer integrierten Problemformulierung fangen wir nicht nur Anwendungs- und Kernelcode ein, sondern bieten zudem die Möglichkeit threadübergreifende Abhängigkeiten zu formulieren.

(ID:45658264)