Software Echtzeitverhalten in den Griff Bekommen

Transkript

1 Software Echtzeitverhalten in den Griff Bekommen B.Sc.Markus Barenhoff [ Dr. Nicholas Merriam [

2 Übersicht Reaktionszeit Nettolaufzeit Optimierung Worst-Case Analyse Automatisierung

3 Priorität Reaktionszeit Periodische ISR CAN ISR CAN Puffer Task Rechner Task CAN Nachricht kommt an Reaktionszeit Nettolaufzeit CPU berechnet Ergebnis Zeit (c) Rapita Systems Ltd

4 Scheduling Analyse maximale Nettolaufzeiten Scheduling policy zb. Prioritäten minimale Ereigniss Frequenzen Scheduling Analyse maximale Antwortzeiten Worst-Case Analyse

5 Worst-Case Nettolaufzeit (WCET) Längst gemessene Was heisst Worst-Case? Hybrid von gemessener und berechneter Modellbasiert d.h. rein berechnete

6 Einfaches Beispiel if a then f1; else f2; end if; if b then f3; else f4; end if; (c) Rapita Systems Ltd

7 Die Hybridanalyse Welcher Pfad führt zum Worst-Case? f1 f2 Grüner und blauer Pfad sind getestet Längste gemessene Laufzeit ist 110 Doch die eigentliche WCET ist grösser! f3 f Tests erreichen 100% MC/DC Abdeckung Aber das reicht nicht, um die WCET auf Einmal zu messen. (c) Rapita Systems Ltd

8 Wie funktionieren die Messungen? Instrumentierung Ipoints in den Code einfügen Trace Bei jedem Ipoint Wert und Zeitstempel speichern Analyse Nettolaufzeit analysieren mit Zeitintervalen und Codestruktur. if(x) { Ipoint(1); a(); } Automatisieren mit einem Tool (c) Rapita Systems Ltd

9 Optimieren

10 Nutzen Testabdeckung messen Zeitaufwand verstehen WCET optimieren Erlaubte Nettolaufzeit überprüfen

11 Ein Verfahren Task und ISR Laufzeiten analysieren oder schätzen Design machen Scheduling Analyse machen Bei Entwicklung der Software, regelmässig die Nettolaufzeiten analysieren Probleme früh entdecken Optimieren nur wenn es sich lohnt, und dann mit der maximaler Wirkung bei der WCET Das heisst Software Echtzeitsverhalten wirklich im Griff haben

12 Zusammenfassung Um Sicherheit im Bezug auf das Echtzeitverhalten einer Anwendung zu bekommen braucht es eine Scheduling Analyse Für eine Scheduling Analyse braucht es die Nettolaufzeiten der einzelnen Komponenten: Maximal gemessene Laufzeit ist unzureichend 100% MC/DC Abdeckung kann nicht ausreichend sein Man möchte eine Worst Case Analyse Manuelle Instrumentierung und Analyse sehr aufwendig und teuer Schnelle und einfache Wiederholbarkeit der Tests wichtig: Um Nettolaufzeiten im Auge zu behalten (schon während der Entwicklung) Um spätere Optimierungen zu planen und zu analysieren

13 ALL times

14 Report structure Outline Calltree. Blaue Pfeil weist auf den Worst-Case Pfad hin Detailierte Daten zum gewählten Objekt Tabs beinhalten verschiedene Ergenbnisse

15 WCET view of root function (Test_Harness.Cycle) Almost all WCET in root function is spent in subfunctions WCET is 690K cycles, Measured 300K cycles. Main contributors to WCET are just 3 functions!

16 Code Coverage view Nicht getestet

17 Outline Outline Shows summary of all functions, and call Tree of contexts Blue arrow -> In the worst-case path Red dot -> Not tested. Green dot -> tested but not on the worst-case path

18 Tabs Show different views of the selected entity: Code Analysis: Simple code metrics (lines of code, number of loops, conditionals etc) Coverage. coverage metrics. Statement coverage, percentages, etc. Min/Max: Maximum observed execution times of each function and its components. Considered in isolation from the rest of functions. Average: Average observed execution times (typical profiler) High Watermarks: Maximum observed execution time of each function and its components. When the root function is executed WCET. Worst-case execution time estimate of this function and its components. WCET optimisation. WCET hotspots and how to prioritise optimisations Comparison: Summary of data to compare between measured and computed values.

19 High Watermarks. Root function (Test_Harness.Cycle) End-to-end measured execution times of root function Maximum observed value is 328K cycles Rufbaum Summary info of Function cycle High Watermarks of functions called from Test_Harness.Cycle RapiTime views : High WM, Coverage, WCET, WCET Optimisation,...

20 WCET. Focus on Radar.Cycle function Main contributor to WCET is function Radar.Sweep

21 WCET. Analysis of Radar.Sweep Main contributor to WCET is a call to Radar.Derive_Grid

22 WCET: detailed analysis of Radar.Derive_Grid See precise call-stack f this call. This function does not make calls to other functions Main contributors to WCET are from these three blocks only. Click on location to see the source code.

23 Adding extra tests that hit the worst-case path Extra tests added to stress the worst-case path New measured high-watermark is now 511K (was 328K).

24 WCET has not changed. WCET of Test_Harness.Cycle has changed very little. (less 0.3%)

25 Kontakt Markus Barenhoff B.Sc Tech.Informatik FAE bei Embedded Tools GmbH Willy-Brandt-Weg 33 D Münster Fon: