Laufzeit-Berechnung
Wie man die »Worst Execution Time« bestimmt
Fortsetzung des Artikels von Teil 1
Tool-Unterstützung für die Laufzeit-Analyse
Bei RapiTime von Rapita Systems Ltd. handelt es sich um ein Werkzeug zur Analyse der Worst-Case Execution Time, das nach dem beschriebenen kombinierten Ansatz funktioniert. Um die Arbeitsweise zu verdeutlichen, werden hier die einzelnen Schritte an einem kleinen Beispiel mit RapiTime illustriert. Dazu wird der gesamte CSource- Code durch das Programm cins instrumentiert. Hierzu wird an allen wichtigen Stellen (Funktionsanfang, -ende, Schleifenrümpfe etc.) der Aufruf RPT_IPoint(id) eingefügt, an dem jeweils eine eindeutige ID übergeben wird, anhand derer die entsprechende Code-Stelle später wieder identifiziert werden kann.
Die IPoint-Funktion wird z.B. so implementiert, dass sie den aktuellen IPoint-Wert über einen Port des Controllers ausgibt, der seinerseits wiederum von einem Logikanalysator oder Datenlogger mitgelesen wird. Der Code läuft zweimal durch die gegeben if-Statements durch (Bild 2). Dabei entsteht ein Trace aus IPoint- Zeit-Tupeln. Ergebnis: Der erste Durchlauf benötigte 110 μs, der zweite Durchlauf 85 μs. In Kombination mit dem durch statische Analyse erstellten Call-Tree und den gemessenen Zeiten lässt sich ein WCET durch den Code konstruieren (a == false und b == true). Auf Basis der gemessenen Zeit lässt sich errechnen, dass es sich hierbei um den WCET-Pfad durch das Programm handelt.
Die anschließende Analyse zeigt mit 110 μs längster gemessener Zeit gegenüber der WCET von 140 μs eine deutliche Differenz. An dieser Stelle ist nun zu überprüfen, welcher Teil des Worst-Case-Pfades nicht durchlaufen wurde und warum. Im Beispiel wurde der Fall (a == false und b == true) nie abgeprüft. Man könnte diesen Testfall dann ggf. noch hinzufügen oder, wenn er in der Realität nicht auftreten kann, dies dem RapiTime-Tool mitteilen, damit dieser Pfad nicht mehr als WCET-Pfad in Betracht kommt.
Jobangebote+ passend zum Thema
Interrupts und Echtzeit-Tasks
Ein Problem bei der tatsächlichen Messung der Zeiten ist, dass reale Anwendungen in der Regel mit Interrupts oder auch mit einem Echtzeit-Betriebssystem arbeiten. Daher kann es passieren, dass der zu messende Code ggf. durch einen Interrupt oder einen Taskwechsel unterbrochen und das Messergebniss drastisch verfälscht wird. RapiTime instrumentiert Interrupt- Routinen auf eine spezielle Weise, durch die sich Interrupt- Latenzen nachträglich wieder herausrechnen lassen, da genau ersichtlich ist, wann ein Interrupt auftrat und wann seine Bearbeitung abgeschlossen war. Ein ähnliches Verfahren kommt bei der Verwendung von Betriebssystemen zum Einsatz.
Hierbei wird ein spezieller Handler installiert, der im Fall eines Taskwechsels aufgerufen wird und die ID des neuen Tasks in den Trace schreibt. Dadurch kann der Trace getrennt nach den einzelnen Tasks ausgewertet werden, und für jeden kann die tatsächliche Netto-Laufzeit bzw. Netto- WCET ermittelt werden. Mit diesen Ergebnissen lässt sich dann eine Scheduling- Analyse vornehmen (Bild 3).
Sehen, was läuft
Die Analyse der Worst-Case Execution Time mittels eines kombinierten Ansatzes aus statischer Analyse, Instrumentierung und Zeitmessung auf dem Zielsystem stellt eine einfach zu implementierende, flexible Möglichkeit dar, ein genaues Verständnis des zeitlichen Verhaltens der eigenen Software zu bekommen. Dieses Wissen kann genutzt werden, um die Echtzeit- Anforderungen an eine Software zu verifizieren oder im Fall einer nötigen Optimierung die Stellen im Code zu identifizieren, bei denen sich eine Optimierung auch wirklich lohnt.
| Markus Barenhoff |
|---|
| studierte an der Hochschule für Angewandte Wissenschaften in Hamburg technische Informatik und ist seit 2007 bei der Embedded Tools GmbH in Münster für Beratung, Einführung und Schulung von Software-Entwicklungswerkzeugen als Field Application Engine |
markus.barenhoff@embedded-tools.de
- Wie man die »Worst Execution Time« bestimmt
- Tool-Unterstützung für die Laufzeit-Analyse
