Embedded Software Systeme systematisch und durchgängig Testen Stefan Lachmann, PikeTec GmbH, Andreas Steinlechner, Robert Bosch GmbH K urzfassung Moderne Fahrzeuge werden immer energieeffizienter, sicherer und komfortabler. Diese Verbesserung führt zu einer immer größeren Komplexität der Steuerungssysteme und erfordert zuverlässige Testverfahren. Der PC basierte Test ist ein Ansatz um Software bereits zu testen, bevor diese auf einem Steuergerät zum Einsatz kommt. Mit Tests, die unabhängig von der Testplattform entwickelt werden, aber quasi überall von MiL bis HiL ausführbar sind, wird der Entwicklungsprozess einfacher und effizienter, da Funktionen der Software bereits frühzeitig in der Modellierungsphase überprüft und die Ergebnisse dokumentiert werden können. Im Beitrag wird das Werkzeug Time Partition Testing vorgestellt. Mit dem Werkzeug kann eine Steuergerätefunktion am PC getestet werden. Später können die gleichen Tests mit dem Steuergerät selbst zum Einsatz kommen. Als Basis für die Modellierung dient eine graphische Notation der Testfälle, die auf der einen Seite mächtig genug ist, um komplexe automatisierte reaktive Tests zu beschreiben und auf der anderen Seite einen schnellen Überblick über die Funktionalität eines Testfalls ermöglicht. Für eine qualitative und quantitative Auswertung können die Testfälle auf zu erwartende Signalverläufe und Zustände ausgewertet werden und die Ergebnisse in einem Report zusammengefasst werden. Auf diese Weise kann der Stand des Entwicklungsprozesses jederzeit dokumentiert werden. 1. Motivation Im Beitrag wird eine Methode vorgestellt, mit der systematisch ausführbare Testfälle zum Test des kontinuierlichen Verhaltens eingebetteter sicherheitskritischer Softwaresysteme definiert werden können. Das Time Partition Testing (TPT) ist ein spezialisiertes Testverfahren und ein Testwerkzeug für den automatischen Funktionstest. Die Funktionstüchtigkeit von Software kann auf diese Weise abgesichert werden. Dabei wird das Verhalten des Systems mittels Simulation bestimmt. Das zu testende System kann in unterschiedlichen Testumgebungen untersucht werden. So können zum Beispiel die einzelnen Stufen MiL, SiL und HiL Berücksichtigung finden. Auf diese Weise kann die Funktionstüchtigkeit eingebetteter Systeme schon während der einzelnen Entwicklungsschritte getestet werden. Die Plattformunabhängigkeit der Testfälle ermöglicht es, die gleichen Testfälle in allen Entwicklungsschritten einzusetzen und so alle Schritte zu testen und zu dokumentieren. Ein Steuergerät
wird für diese ersten Tests nicht benötigt. Die Testzeiten auf HiL Systemen können so verkürzt werden. Charakteristisch für TPT ist die gemeinsame modellbasierte Entwicklung aller relevanten Testfälle für ein Testobjekt mittels einer graphischen Notation unabhängig von der Testplattform. Ein Beispiel aus dem Fahrzeugbereich ist der Test des Verhaltens einer Startrampe. Die Berechnung des Startmoments muss die Anforderung sicherer Kaltstart und Vermeidung von Rauchentwicklung erfüllen. Ein zur Vermeidung von Rauchentwicklung niedrig festgelegtes Startbasismoment kann bei bestimmten Betriebsbedingungen ein Starten des Motors erschweren bzw. verhindern. Hier muss deshalb das Startbasismoment erhöht werden. Die zu testende Steuergerätefunktion wird in eine auf dem PC ausführbare DLL übersetzt. Das Verhalten dieser DLL entspricht dem später auf dem Steuergerät verwendeten Softwarecode. Für die eigentlichen Tests wird eine DLL aus dem zu testenden System von TPT mit den notwendigen Signalen für den modellierten Testablauf stimuliert. Die Funktionstüchtigkeit der Startrampe gilt es hierbei sicherzustellen und die einzelnen Testschritte zu dokumentieren. Mit Time Partition Testing ist es möglich, diese Tests systematisch, intuitiv lesbar und dennoch automatisiert durchzuführen und die Ergebnisse zu dokumentieren. 2. Übers icht über Time Partition Tes ting In TPT können Tests modelliert, verwaltet, dokumentiert und ausgewertet werden. TPT ist für diese unterschiedlichen Anforderungen in verschiedene Bereiche unterteilt (Bild 1). Alle Testfälle für ein Testobjekt werden gemeinsam entwickelt. Dabei können alle testrelevanten Aspekte systematisch betrachtet werden. Die Modellierung erfolgt dabei unabhängig von der Testplattform. Verschiedene Testplattformen für ein Testobjekt können mit TPT ebenso verwaltet werden. Aktuell verfügbare Testplattformen sind zum Beispiel verschiedene HiL-Systeme, CAN-BUS, MATLAB/Simulink und ASCET.
Bild 1: Übersicht über Time Partition Testing Weiterhin bietet TPT die automatisierte Auswertung der Testfälle. So können die Tests auf zu erwartende Signalverläufe untersucht werden. Dabei ist die Auswertung nicht auf einfache Signalvergleiche beschränkt. Komplexe Berechnungen, die Auswertung von Signalbereichen und viele weitere Möglichkeiten stehen hier zur Verfügung. Dabei kann eine GUI-unterstützte Auswertung oder eine Skriptbasierte Auswertung (Python und eine spezielle Python-Spracherweiterung) verwendet werden. Die Ergebnisse der Auswertung werden in einem Report zusammengefasst. TPT bietet die Möglichkeit zu jedem Testfall und jedem Szenario Informationen als Dokumentation zu hinterlegen. Auf diese Weise ist der Test sowohl in TPT als auch automatisch in der Testauswertung dokumentiert. 3. Modellierung von Tes tfällen Mit TPT wird jeder Testfall mit Hilfe von hierarchischen hybriden Automaten modelliert. Hierbei wird ein Testfall in eine Folge von einzelnen Zeitphasen zerlegt (Bild 2). Der Zeitpunkt des Übergangs zwischen den einzelnen Phasen/Automaten wird an Transitionsbedingungen geknüpft, die sowohl reaktive Tests als auch zeitliche Abfolgen ermöglichen. Gehen von einem Zustand mehrere Transitionen ab, sind Verzweigungen möglich, so dass der Test je nach Systemverhalten verschieden ablaufen kann. Für den Test der Startrampe kann der Ablauf in zwei Phasen modelliert werden. Bild 2: Ablaufplan am Beispiel Startrampe Hinter jedem Zustand/Automaten verbirgt sich auf unterster Ebene eine formale Beschreibung von kontinuierlichen Verläufen der zu stimulierenden Größe. Dies kann eine Funktion über der Zeit sein (Bild 4) oder eine Definition zu bestimmten Zeitpunkten (Bild 3) oder ein vorhandenes Messsignal aus einer Datei. Bild 3: Definition an einzelnen Zeitpunkten
Eine Transition kann ein Wait in einer Liste (Bild 3) oder eine Line zwischen zwei Automaten (Bild 2) wein. Einer Transition ist eine formale Bedingung zugeordnet. Wenn diese Bedingung erfüllt ist, wird in den nächsten Zustand gewechselt. Bild 4: Beschreibung von über der Zeit Im Beispiel der Startrampe werden die Größen neng (Drehzahl), tfld (Motortemperatur) und trqbas (Basismoment) zur Stimulation des Testobjekts vorgegeben. So kann die Funktionalität des zu testenden Systems überprüft werden. Die Signale für die Startrampe sind phasenweise konstant. Für diesen Anwendungsfall steht in TPT eine listenbasierte Modellierung zur Verfügung (Bild 3). Durch die grafische Darstellung, sowie die Verwendung von Annotationen in natürlicher Sprache, können Testfälle auch von Nicht-Programmierern erstellt, gelesen und durchgeführt werden. TPT unterstützt die Modellierung weiterhin durch Techniken wie Actions an Transitionen, nicht-flüchtige Größen, finale Transitionen, benutzerdefinierte Funktionen, Signalverläufe, Funktionen u.v.m. 4. S ystematische S trukturierung von Testfällen Die Vorstellung von TPT konzentrierte sich bislang auf eine Sprache zur Modellierung von reaktiven, kontinuierlichen Testfällen. Die volle Mächtigkeit von TPT kommt erst dann zum Tragen, wenn zu einem Testobjekt die Menge aller relevanten Testfälle modelliert werden soll. Es lässt sich beobachten, dass sich Testfälle zu einem Testobjekt häufig in nur wenigen spezifischen, klar lokalisierbaren Details unterscheiden. Die Grobstruktur der Testfälle wiederholt sich dagegen. Das bedeutet für das Beispiel Startrampe, dass für verschiedene Anfangstemperaturen unterschiedliche Verhalten erwartet werden. So unterscheiden sich unter Anderem der Anstieg und der Maximalwert der Startrampe. Die Drehzahlabhängigkeit ist in allen Fällen gleich.
Für die Testmodellierung mit TPT bedeutet dies, dass der grundsätzliche Ablauf einzelner Phasen des Tests ( Init Test Step ) für alle Testfälle gleich ist. Für die Startrampe sind für die Phase Init unterschiedliche Varianten möglich ( cold, warm, hot ). In der Phase Test Step ist die Drehzahlvariation hinterlegt. Mögliche Szenarien wären hierbei: 1. Drehzahl zwischen nrelease und nfreeze 2. Drehzahl über nfreeze. Hinter dem Zustand eines Automaten verbirgt sich nicht nur eine formale Beschreibung, sondern beliebig viele unterschiedliche Varianten für diese Phase. Aus den unterschiedlichen Varianten der einzelnen Phasen können die einzelnen Testfälle zusammengestellt werden. Hierfür kann zum Beispiel die Klassifikationsbaum-Methode genutzt werden. Diese unterstützt die systematische Kombination von Varianten unterschiedlicher Aspekte. Jeder Testfall ist durch die Auswahl der verwendeten Variante eindeutig und formal präzise beschrieben, so dass die so definierten Testfälle bereits ausführbar sind. Jeder Testfall kann in TPT dokumentiert werden. Diese Dokumentation fließt später in den Ergebnisreport ein. Das bietet den Vorteil, dass einerseits der Testfall in TPT dokumentiert ist und diese Dokumentation automatisch in den Report übernommen wird. Weiterhin bietet TPT die Möglichkeit, zu einzelnen Testfällen vorgegebene Requirements zuzuordnen oder zu importieren. So kann unter Anderem sichergestellt werden, dass alle vorgegebenen Requirements durch Testfälle abgedeckt sind und welche Requirements in welchen Testfällen berücksichtigt sind. 5. Anbindung eines Testobjekts In den vorherigen Abschnitten wurde auf die Testmodellierung eingegangen. Alle Testfälle können in TPT automatisiert ausgeführt werden. Die mit TPT modellierten Testfälle haben eine präzise Semantik, die unabhängig von der konkreten Testumgebung oder der Plattform des Testobjekts ist. Dadurch kann TPT in den unterschiedlichsten Bereichen wie beispielsweise MiL, SiL und HiL zum Einsatz kommen. So können dieselben Tests in den einzelnen Entwicklungsschritten genutzt werden. Für die automatisierte Testdurchführung ist lediglich ein plattformspezifischer Testtreiber notwendig, der TPT Testfälle ausführen kann. Im gezeigten Beispiel der Startrampe wird der Steuergerätecode in eine auf dem PC ausführbare DLL überführt. Dies kann automatisch für jeden Teil des Steuergerätecodes erfolgen. Dieser Schritt ist nicht Bestandteil des Testtools TPT und erfolgt mit einem separaten Tool. Damit kann jedes Softwaremodul unabhängig vom Steuergerät getestet werden. Eine Kombination aus mehreren Teilmodulen ist ebenso möglich. Weitere Testplattformen stehen unter TPT zur Verfügung, unter anderem MATLAB/Simulink, ASCET, CAN-Bus, INCA und verschiedene HiL-Systeme. Der Umfang an Plattformadaptern wächst ständig.
6. T es taus wertung Ein Testobjekt wird von TPT mit Signalen stimuliert. Zusätzlich zeichnet TPT zu den Stimulationssignalen die Antworten des Testobjekts auf. Damit kann das Systemverhalten des Testobjekts bewertet werden. TPT beinhaltet Techniken für die automatische Testauswertung. Die Auswerteregeln können durch eine GUI-Eingabe (Abbildung 5) erfolgen, in die listenbasierte Modellierungen mit eingearbeitet werden (Abbildung 6) oder in der Skriptsprache Python verfasst werden. Hierfür stehen komplexe Hilfsmittel, wie beispielsweise zeitliche reguläre Ausdrücke, Minima- und Maxima-Überwachung, der Vergleich mit Referenzmessungen, Analysen der Dauer bestimmter Testphasen und vieles mehr zur Verfügung. Auf diese Weise können die Resultate der Durchführung hinsichtlich des Sollverhaltens bewerten werden. Die Auswerteregeln können über den gesamten Testfall oder einzelne Phasen erstellt werden. Außerdem ist es möglich, Auswerteregeln für jeden Testfall individuell oder für alle Testfälle festzulegen. Bild 5: GUI für die automatisierte Testauswertung Bild 6: Eingliederung der Überprüfungen in Listenbasierte Modellierung Die Testauswertung ist von der Durchführung entkoppelt und findet offline nach der Testausführung statt. Wie bereits bei der Testmodellierung ist es bei der Auswertung ebenso möglich, diese reaktiv auf Signale und Testphasen auszulösen. Dabei stehen dem Anwender schon während der Modellierung unterschiedliche Möglichkeiten zur Verfügung, für welche Testszenarien oder Testphasen die Auswer-
tung erfolgen soll. So können für die Auswertung zum Beispiel verschiedene Szenarien zu Gruppen zusammengefasst werden, wenn für diese die gleichen Ergebnisse erwartet werden. Für die Startrampe könnte zum Beispiel überprüft werden, ob nach überschreiten der Drehzahlschwelle nrelease die Startrampe aktiviert wird (Bild 5) oder der Maximalwert der Startrampe erreicht wird (Bild 6). Die Ergebnisse der Überprüfungen können zusammen mit einem Kommentar in speziellen Assessment-Signalen abgelegt und in die Testdokumentation übernommen werden. 7. Dokumentation der Testergebnisse Mit TPT können die Ergebnisse der Testauswertung in einem Ergebnisreport zusammengefasst werden. Der Report gliedert sich dabei in verschiedene Teile. Zum einen steht eine Übersicht über die Ergebnisse der Auswertung aller Testfälle zur Verfügung. Dieser Übersicht kann entnommen werden, welche Testfälle ausgeführt wurden, wie viele Testfälle erfolgreich waren und welche Auswerteregeln in den einzelnen Testfällen zu welchen Ergebnissen führten. Auf diese Art kann schnell ein Überblick über das Resultat aller Testfälle gewonnen werden. Die Ergebnisse jedes einzelnen Testfalls stehen ebenso detailliert zur Verfügung. Hier sind die Signalverläufe und Ergebnisse der Testauswertungen zusammengestellt. Mit enthalten ist die Dokumentation des Testfalls. Die verwendeten Parameter für den Testfall sind ebenso zu finden. Dieser Teil des Reports kann vom Benutzer individuell angepasst werden. So können zum Beispiel verschiedene Signalverläufe in Grafiken zusammengefasst und Teilergebnisse in unterschiedlichen Tabellen dargestellt werden. 8. P raktis cher E ins atz TPT ist nicht nur eine Methode, sondern ist gleichzeitig ein Testwerkzeug. TPT wird als eigenständiges Werkzeug von der PikeTec GmbH weiterentwickelt und vertrieben. Im Einsatz ist das Tool unter anderem bei der Robert Bosch GmbH, Geschäftsbereich DGS, und in unterschiedlichen Bereichen der Daimler AG.