Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK)

Transkript

1 Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen Wege aufgezeigt werden um die kritischen Funktionen, welche den größten Anteil am Laufzeitverhalten haben, ins besondere an der Worst Case Execution Time (WCET), zu identifizieren. Eine Optimierung dieser Funktionen ermöglicht es die Anforderungen an das Echtzeitverhalten einer Software zu erfüllen und Freiraum für spätere Erweiterungen zu lassen ohne dass teure Hardware Upgrades nötig werden. Software Echtzeitverhalten in den Griff bekommen Markus Barenhoff Embedded Tools GmbH, Willy-Brand-Weg 55, Münster, Germany Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO 5DG (UK) Einführung Die Ausführungszeit ist eines der Hauptkriterien um beurteilen zu können, ob eine Software, die in einer Anwendung mit harten Echtzeitanforderungen eingesetzt wird, korrekt funktioniert oder nicht typischerweise wird das Laufzeitverhalten einer Software durch Messungen analysiert. Hierbei wird das zeitliche Verhalten der wichtigen Komponenten einer Software während der System Tests gemessen und analysiert. Die Messungen zeigen ob und wenn ja, wie oft die Anforderungen an die Lauf-, bzw. Reaktionszeit der Software überschritten werden um so eine gewisse Sicherheit zu haben, dass die Anwendung später im Einsatz die Anforderungen erfüllt. Diese Messungen werden meistens durchgeführt, in dem der Quelltext der Software an entschiedenen Stellen um Messpunkte erweiterter wird, die beim späteren Durchlaufen eine Zeitinformation (z.b. von einem internen Timer) im Speicher aufzeichnen. Anhand der so gemachten Aufzeichnungen können Aussagen über die Verteilung der Laufzeit über die Software Komponenten, sowie wie High Water Mark Läufe, welche den längsten gemessen Durchlauf darstellen, ermittelt werde. Dieses manuelle Verfahren ist zwar sehr aufwendig, liefert aber relativ gute Gewissheit über das Laufzeitverhalten der analysierten Software. Während der Entwicklung eines Systems, oder der Entwicklung späterer Erweiterungen, kann sich herausstellen, dass die Laufzeitanforderungen an die Software nicht erfüllt werden. Diesem Fall muss durch Anpassung der Anforderungen, Optimierung der Software oder Upgrade der Hardware z.b. durch einen schnelleren Prozessor begegnet werden.

2 Wie lassen sich detaillierte Laufzeit Messungen nutzen? Das Hauptproblem bei der Verwendung einfacher Anfang-bis-Ende-Messungen ist, dass es vorkommen kann, dass der längste mögliche Pfad durch das Programm (WCET) bei den verwendeten Tests nicht durchlaufen wird. Code Coverage Analyse Werkzeuge können eine Aussage darüber machen, ob die verwendeten Tests zum Durchlaufen des gesamten Codes führen, aber eben nicht, ob der Pfad mit der längsten Laufzeit am Stück durchlaufen wurde. Dies hängt damit zusammen, dass die längsten Laufzeiten für die einzelnen Codestellen zu unterschiedlichen Zeiten und abhängig von den Eingabe Daten sind. Daher sind 0% Statement-, Condition- und Decision Coverage unzureichend um beurteilen zu können, ob der WCET Pfad durchlaufen wurde. 20 (f1) 50 (f2) 60 (f3) 5 (f4) Abbildung 1: Gemessene Pfade (links, rechts), theoretischer WCET Pfad (mitte) Es ist sehr schwer für komplexe Software Systeme Tests zu entwickeln, die sicher stellen, dass der Pfad mit der längsten Laufzeit wirklich durchlaufen wird, da die Anzahl der möglichen Pfade exponentiell mit der Anzahl der möglichen Verzweigungen ansteigt. Einfache Anfang-bis-Ende-Messungen geben zwar eine gewisse Sicherheit, dass das geforderte Echtzeitverhalten eingehalten wird, sind aber bei weitem keine zuverlässiger Beweis, dass dies immer der Fall ist. Ein ausschließliches Verlassen auf diese Tests, kann zu dem Problem führen, dass sehr selten auftretende Fälle nicht getestet wurden und es bei deren Auftreten zu Problemen mit der Laufzeit kommen kann. Dies stellt das Hauptproblem bei der Laufzeitanalyse eines Softwaresystems dar. Trotz der erwähnten Probleme können auch diese einfachen Tests mit einem High Water Mark Ergebnis zeigen, dass die Laufzeitanforderungen nicht eingehalten werden. Allerdings ergibt sich dann das nächste Problem, festzustellen, welche Teile des Programms am meisten zur Laufzeit beigetragen haben, um so zu bestimmen wo eine Optimierung am besten anzusetzen ist. Leider geben High Water Marks hier keinen Hinweis. Klassische Profiler, die häufig zu Optimierungszwecken eingesetzt werden, helfen hier leider auch nicht weiter, da sie typischerweise nur den Beitrag einzelner Funktionen und Codestellen zur durchschnittlichen Laufzeit mitteilen und nicht zur WCET.

3 Sowohl für die Verifikation der Echtzeit Anforderungen wie auch für die eigentliche Code Optimierung werden mehr und genauere Laufzeit Messdaten benötigt. Dies ist bei komplexeren Systemen nicht mehr ohne die Unterstützung von entsprechenden Software Tools möglich, da der Aufwand der Instrumentierung, sowie Daten- Erhebung und Auswertung der manuell nicht mehr handhabbar ist. Tests Host Target Sources Compile link Executable Run +instrument +extract Data set Collect execution time data Automatic Manually analyse data analysis data timing reports Trace collection Abbildung 2: Instrumentierung, Datenerfassung und Auswertung mit RapiTime Werkzeuge zur automatischen Laufzeitanalyse wie RapiTime ermöglichen es auch bei sehr komplexen Softwaresystemen übersichtlich und detailliert das Laufzeitverhalten zu analysieren. RapiTime kann vorhanden Sourcecode auf verschiedenen Abstraktionsebenen, runter bis zu den Unterpfaden zwischen den einzelnen Entscheidungspunkten, automatisch instrumentieren (mit s.g. IPoints). Der so instrumentierte Code wird dann auf dem Ziel System ausgeführt. Während der Ausführung werden an jedem Ipoint die Ipoint Nummer und die Zeit gespeichert. void { void switch(x) f1() { { case 0: if (a > b) { while (c) { RapiTime Code Instrumentation Source Structure Source Structure void { RPT_Ipoint(1299); void f1() { RPT_Ipoint(1234); if (a > b) { RPT_Ipoint(1235); while (c) { RPT_Ipoint(1236); RapiTime Structural Analysis f1() g2() g3() Abbildung 3: Instrumentierung mit Ipoints und statischer Codeanalyse

4 Aus diesen Daten kann zusammen mit der ebenfalls von RapiTime erstellten statistischen Code Analyse ein sehr genaue statistische Analyse des Laufzeitverhaltens durchgeführt, sowie der theoretische WCET Pfad durch das Programm berechnet werden. Zu den wichtigsten der gewonnen Informationen zählen: Die worst case execution time (WCET) der Software, selbst wenn der WCET Pfad nie wirklich ausgeführt wurde. Welche Stellen im WCET Pfad eigenen sich, bzw. eignen sich nicht zur Optimierung Wie viel trägt jede Funktion und jeder Unterpfad zur gesamt WCET bei? Optimierungskandidaten Um eine Software Komponente die ein zu lange Ausführungszeit benötigt zu optimieren, sollte ein systematisches und wissenschaftliches Herangehen gewählt werden um das Problem zu lösen. Die einfachste und kostengünstigste Lösung wäre natürlich die Anforderungen anzupassen. Da dies aber meist nicht möglich ist bietet sich die Optimierung der Software als Lösung an. Optimierung stellt einen Kompromiss zwischen verschiedenen Faktoren da, im besonderen: Ausführungszeit, Code Größe, Speicherverbrauch, Wartbarkeit und Aufwand. Der Schlüssel zu einer guten Optimierungsstrategie ist, die Kandidaten für die Optimierung nach dem Verhältnis zwischen Aufwand und dem kleinsten Kompromiss zwischen den anderen Faktoren auszuwählen. Als erste muss herausgefunden werden welche Funktionen auf dem gesamt WCET Pfad liegen. In einer typischen Anwendung liegen die meisten Funktionen gar nicht auf dem WCET Pfad, daher würde eine Optimierung auch nicht zu einer Verbesserung der WCET beitragen. Aus den verbliebene n Funktionen tragen die meisten nur einen sehr kleinen Teil zur WCET bei und es lassen sich einige hot spots identifizieren. In der Praxis hat sich herausgestellt, dass die Funktionen, welche am meisten zur WCET beitragen, häufig Funktionen sind, die eher selten ausgeführt werden. Sie fallen daher in einem klassischem Profiler eher nicht auf. RapiTime zeigt den Beitrag jeder Funktion zum WCET Pfad an. So kann der Entwickler sehr einfach die oder 20 Funktionen identifizieren, welche am meisten beitragen und sie auf Optimierungsmöglichkeiten untersuchen. Allerdings ist es wichtig sich vor dem Optimieren einer Funktionen die Frage zu stellen, welchen Einfluss die Optimierung auf die gesamt Ausführungszeit hat. So kann es passieren, dass sich durch die Optimierung der WCET Pfad verändert. Solche Wass Wenn? Fragen lassen sich mit RapiTime sehr gut beantworten, noch bevor man mit der Optimierung beginnt. Nach dem die Optimierungen durchgeführt wurde sollten die Zeitmessungen erneut durchgeführt werden um die geplanten Verbesserung zu überprüfen.

5 Fallstudie BAE Systems Hawk Mission Computer Abbildung 4: BAE Hawk Die oben erwähnten Methoden u.a. wurden auf das Operational Flight Program des BAE Systems Hawk Mission Computer angewendet. Die in ADA geschrieben Software besteht aus mehreren hunderttausend Zeilen Sourcecode, der in 25 Modulen unterteilt ist, wovon jedes Modul aus mehreren Tasks besteht. Diese Tasks werden durch einen zyklischen Scheduler ausgeführt. Während der Analyse, die sich mit 4 der Module auseinander setzte, konnte herausgefunden werden, dass nur 1.2% des Sourcecodes 29% der gesamt WCET ausmachen. Am Ende wurden 1250 Zeilen Code identifiziert werden, die sich als gute Kandidaten für die Optimierung der WCET eigneten. Nachdem die Optimierungen durchgeführt worden waren, wurde das System erneut mit RapiTime analysiert. Insgesamt konnte die Geschwindigkeit durch die Optimierungen um 23% beschleunigt werden. Somit war wieder genug Freiraum geschaffen um neue Funktionalität implementieren zu können, ohne teure Hardware Updates durchführen zu müssen. Markus Barenhoff Markus Barenhoff arbeitet als Field Application Engineer bei Embedded Tools in Münster, wo er sich mit Software Werkzeugen für die Entwicklung von embedded Echtzeitsystemen beschäftigt. Nicholas Meriam Dr. Nicholas Merriam is Engineering Services at Rapita Systems Ltd, a company specialising in tools for Software Timing Analysis. For the last 12 years he has been involved in the development of software tools for embedded, real-time applications. He received his Ph.D. in Computer Science at the University of London's Imperial College.