Testmethoden und tools in der modellbasierten Funktionsentwicklung

Transkript

1 Testmethoden und tools in der modellbasierten Funktionsentwicklung Dr.-Ing. Dipl.-Math. Klaus Lamberg Dipl.-Math. Michael Beine dspace GmbH, Paderborn Technologiepark Paderborn Phone Fax Zusammenfassung: Es besteht kein Zweifel, dass Elektronik und insbesondere Software den Schlüssel für innovative und marktgerechte Funktionalität moderner Fahrzeuge darstellen. Gleichzeitig müssen jedoch die Zuverlässigkeit, die Sicherheit und die Qualität der Fahrzeugelektronik in hohem Maße gewährleistet werden. Bei der Entwicklung von Software für das Automobil lassen sich derzeit zwei sehr wichtige Tendenzen erkennen: Die Entwicklung von Reglern und Funktionen erfolgt mithilfe von Simulationsmodellen. Der für das jeweilige Zielsystem notwendige C-Code wird auf Basis dieser Modelle automatisch generiert. Dabei hat die automatische Codegenerierung längst Einzug in die Serienentwicklung gehalten. Die zunehmende Komplexität der Software im Automobil und die immer kürzer werdenden Entwicklungszyklen erfordern es, dass die entstehende Software so früh und ausgiebig wie möglich getestet wird. Testen wird zunehmend als zentrale Maßnahme der Qualitätssicherung erkannt. Durch das modellbasierte Entwicklungsvorgehen verlagert sich das Testen von der Codeebene auf die Modellebene. Insbesondere in den früheren Entwicklungsphasen besteht ein großes Potenzial, das überwiegend experimentelle Entwicklungsvorgehen um Methoden des modellbasierten, automatisierten Testens zu ergänzen. Typische Testaktivitäten in der modellbasierten Funktionsentwicklung sind Model-, Software- und Processor-inthe-Loop-Simulation und darauf basierende Back-to-Back-Verfahren, Black-Box- Ansätze wie die Klassifikationsbaummethode und White-Box-Verfahren mit Überdeckungsmessungen auf Modell- und Codeebene, sowie die formale Verifikation. Durch die Kombination der modellbasierten Entwicklung mit dem automatisierten Testen ergibt sich eine mächtige und effiziente Sammlung von Tools und Methoden, angefangen vom Testprojektmanagement über die systematische Testfallerstellung bis hin zur automatisierten Testauswertung und der anschließenden Generierung von Testreports. Dieser Beitrag beschreibt diese Verfahren und ordnet sie hinsichtlich der zugrundeliegenden Methoden in den Gesamtkontext des Testens ein.

2 Funktionsentwicklung mit Automatischer Codegenerierung Die Software-Entwicklung für Steuergeräte wird in zunehmendem Maße mit modellbasierten Entwicklungswerkzeugen wie MATLAB /Simulink /Stateflow [1] durchgeführt. Steht die Spezifikation unter Zuhilfenahme dieser Werkzeuge fest, beginnt die Arbeit der Codierung. Die grafisch beschriebenen Funktionen müssen nun in C-Code umgewandelt und auf dem Steuergerät implementiert werden. Für diese Aufgabe werden vermehrt automatische Code-Generatoren eingesetzt. Entgegen den ersten Generationen von Code-Generatoren sind die Methoden der Code- Erzeugung heute so ausgereift, dass sie in der Lage sind, die Brücke vom modellbasierten Funktionsentwurf hin zur Seriensoftware-Entwicklung zu schlagen. Code-Generatoren wie TargetLink [2] erzeugen aus einem Blockdiagramm hocheffizienten und zuverlässigen C-Code in Produktionsqualität. Sie reduzieren dabei nicht nur die Entwicklungszeit, sondern bringen auch eine erhöhte Software-Qualität hervor und vermeiden menschliche Programmierfehler. Zurzeit werden automatische Code-Generatoren primär für neue funktionale Software- Bestandteile, also für die Steuerungs- und Regelungsfunktionen, in elektronischen Steuergeräten eingesetzt. Die hardwarenahe Software und die Software-Infrastruktur werden manuell erstellt. Da der Funktionscode in Steuergeräten einen Großteil der Software einnimmt, hat die Verwendung automatischer Code-Generatoren in der Automobilelektronik sehr an Bedeutung gewonnen. So steht z.b. TargetLink derzeit an der Schwelle zum breiten produktiven Einsatz mit entsprechenden Rollouts in großen Entwicklungsprojekten. Mit der Verlagerung der Entwicklungsaktivitäten von der Codeebene auf die Modellebene und mit der anschließenden automatischen Codegenerierung wird es notwendig, auch das Testen bereits auf Modellebene durchzuführen. Daher ist derzeit ein deutlicher Trend erkennbar, Methoden und Vorgehensweisen des klassischen Softwaretests auf die modellbasierte Entwicklung zu übertragen. Grundbegriffe des Testens Testen ist eine qualitätssichernde bzw. qualitätserhöhende Maßnahme mit dem Ziel, Fehler zu finden. Testen ist leicht zu erlernen und kann auch auf sehr komplexe Systeme angewendet werden. Obwohl Testen recht aufwändig sein kann, stellt sich das Kosten- Nutzen-Verhältnis in der Regel sehr positiv dar. Entsprechend dem jeweiligen Testziel wird zwischen Validierung und Verifikation unterschieden. Dabei entspricht die Validierung dem Test gegenüber den Anforderungen an das zu entwickelnde System. Die Anforderungen können funktional, also auf den eigentlichen Zweck des Systems ausgerichtet, oder nichtfunktional, d.h. z.b. bezogen auf Performance, Echtzeit, Speicherverbrauch usw. sein. Verifikation bedeutet, ein Testobjekt gegenüber seiner Spezifikation zu prüfen. Dabei beschreibt die Spezifikation die technischen Anforderungen an das Objekt, i.a. die Schnittstellen und das gewünschte Verhalten des Objekts an diesen Schnittstellen. Das Testobjekt kann auf allen Systemebenen (Unit, Modul, Komponente, Subsystem) liegen, je nachdem, auf welcher Ebene die Spezifikation vorliegt und überprüft wird. Die

3 Verifikation selbst ist jedoch kein Nachweis der Übereinstimmung des Testobjekts mit den ursprünglichen Systemanforderungen, da bereits die Spezifikation fehlerhaft sein kann. Die Vielzahl der für das Testen zur Verfügung stehenden Methoden lassen sich nach dem in Abbildung 1 gezeigten Schema klassifizieren. Abbildung 1: Klassifikation von Testmethoden. Grundsätzlich wird zwischen statischem und dynamischem Testen unterschieden. Der wesentliche Unterschied besteht darin, dass das Testobjekt beim dynamischen Testen ausgeführt wird, beim statischen jedoch nicht. Eine weitere Methodenklasse bildet die formale Verifikation. Im Folgenden wird nur auf das dynamische Testen und die formale Verifikation eingegangen, da diese im Rahmen der modellbasierten Entwicklung primär zum Einsatz kommen. Funktionales Testen Beim funktionalen Testen, also dem Testen des funktionalen Verhaltens des Testobjekts, wird das Testobjekt üblicherweise mit vorgegebenen Signalverläufen (Testdaten) stimuliert und das Antwortverhalten wird erfasst und hinsichtlich des Sollverhaltens (Erwartungswerte) bewertet. Dabei werden keinerlei Informationen über den internen Aufbau des Testobjekts benötigt und verwendet. Daher wird funktionales Testen auch als Black-Box-Testen bezeichnet. Beispiele für die Anwendung des funktionalen Testens sind Äquivalenzklassentest (Klassifikationsbaummethode) und Back-to-Back-Tests. Klassifikationsbaummethode Die Klassifikationsbaummethode ist eine Black-Box-Methode, bei der die Eingangsgrößen eines Testobjekts, zum Beispiel ein zu testendes TargetLink-Subsystem, nach bestimmten, testrelevanten Aspekten klassifiziert werden. Ziel der Partitionierung ist es, die einzelnen Klassen so zu wählen, dass sie sich einheitlich (uniform) in Bezug auf die Aufdeckung potenzieller Fehler verhalten [3]. Das heißt, das Testobjekt verhält sich für alle Werte einer Klasse entweder korrekt oder fehlerhaft (Uniformitätshypothese). Die schrittweise Partitionierung der Eingangsdaten wird grafisch in Form eines Baums dargestellt. Anschließend werden die entstehenden Klassen gezielt miteinander kombiniert, um daraus Testsequenzen zusammenzustellen.

4 Abbildung 2: Klassifikationsbaum für das Testobjekt VDC. Abbildung 2 zeigt einen Klassifikationsbaum. Der Name des Testobjekts (VDC) bildet die Wurzel des Baums, die Eingangssignale definieren die Klassifikationen unterhalb des Wurzelknotens. Darunter finden sich die Äquivalenzklassen. Basierend auf der so erfolgten Partitionierung des Eingaberaums lassen sich nun Testsequenzen definieren. Die Testsequenzen ergeben sich durch gezielte Kombination einzelner Klassen: jede Zeile der Kombinationstabelle beschreibt einen Testschritt innerhalb der Testsequenz. Die DaimlerChrysler AG hat die Klassifikationsbaum-Methode bereits Anfang der 90er Jahre entwickelt. Mit der Integration in MTest [2] wurde die Methodik an die Anforderungen des modellbasierten Entwicklungsprozesses angepasst. Model-in-the-Loop, Software-in-the-Loop, Processor-in-the-Loop Eine konsequente Ausnutzung der in der verwendeten Entwicklungsumgebung zur Verfügung stehenden Simulationsmöglichkeiten ermöglicht dem Anwender eine schnelle und einfache entwicklungsbegleitende Überprüfung der erzielten Ergebnisse sowie der vorgenommenen Änderungen und Anpassungen. In verschiedenen Modi können das Funktionsmodell, der generierte Code auf dem Entwickler-PC und der generierte Code auf einem Evaluierungsboard simuliert werden. Die Überprüfung kann somit schrittweise erfolgen (Abbildung 3): Die Simulation des Funktionsmodells als ausführbare Spezifikation wird üblicherweise als Model-in-the-Loop (MIL)-Simulation bezeichnet. Zur Simulation des generierten Codes auf dem Entwickler-PC, die als Software-inthe-Loop (SIL)-Simulation bezeichnet wird, wird der generierte Code mit einem Host-Compiler übersetzt. Die Simulation des erzeugten Codes auf einem Evaluierungsboard, das typischerweise den im Steuergerät verwendeten Prozessor enthält, wird als Processor-in-the-Loop (PIL)-Simulation bezeichnet. Der erzeugte Code wird mit dem entsprechenden Target-Compiler übersetzt.

5 Abbildung 3: Prinzip von Model-, Software- und Processor-in-the-Loop-Simulation Back-to-Back-Tests Beim Back-to-Back-Tests werden die Ergebnisse der unterschiedlichen Simulationsmodi direkt miteinander verglichen. Dazu werden beispielsweise das Simulinkmodell und der Programmcode mit denselben Testdaten stimuliert. Das Ausgangsverhalten des Programmcodes bezogen auf die Testdaten lässt sich dann unmittelbar mit dem der ausführbaren Spezifikation vergleichen Abbildung 4 links zeigt die Ergebnisse der Simulationsmodi Simulink, TargetLink MIL und TargetLink SIL, wie sie in einem von MTest generierten Testreport (s.u. Testmanagement) angezeigt werden. Abbildung 4: Vergleich unterschiedlicher Simulationsmodi Es ist deutlich erkennbar, dass die Simulationsergebnisse der einzelnen Modi weitgehend übereinstimmen, zumindest lässt sich visuell kaum ein Unterschied feststellen. Abbildung 4 rechts zeigt jedoch das während der Testdurchführung berechnete Differenzsignal zwischen der TargetLink MIL- und der TargetLink SIL- Simulation. Es zeigt eine Abweichung im Bereich bis 3 für das Ausgangssignal upi, die

6 betragsmäßig mit der Simulationsdauer zunimmt. Solche Abweichungen können wie z.b. in diesem Fall durch Festkomma-Quantisierungseffekte entstehen. Für die Bewertung der Differenz hinsichtlich einer Pass/Fail-Aussage des Tests stehen unterschiedliche Kriterien zur Verfügung. Häufig wird überprüft, ob sich das Differenzsignal innerhalb eines definierten Toleranzbandes bewegt. Dabei können sowohl absolute als auch relative Toleranzen von Interesse sein. Weiterführende Auswertealgorithmen können sogar zeitliche Verschiebungen oder Amplitudenabweichungen getrennt voneinander erkennen und bewerten [4]. Strukturelles Testen Im Gegensatz zum funktionalen Testen werden beim strukturellen Testen Informationen über den internen Aufbau (Struktur) und die Eigenschaften des zu testenden Systems berücksichtigt und für die Entwicklung von Testfällen verwendet. Aus diesem Grund wird strukturelles Testen auch als White-Box-Testen bezeichnet. Durch die Kenntnis des internen Aufbaus eines Systems ist es zum Beispiel möglich, gezielt Testfälle zu definieren, die dazu führen, dass bestimmte Strukturelemente des Testobjekts wie Anweisungen und Verzweigungen durchlaufen werden. Dadurch lassen sich bestimmte Teile des Testobjekts gezielt anregen und testen. Modell- und Code-Überdeckung Umgekehrt ist es möglich, während der Durchführung von Tests die Häufigkeit zu erfassen, mit der bestimmte Systemteile durchlaufen wurden. Werden derartige Messungen auf Modellebene durchgeführt, spricht man von Modellüberdeckung (Model Coverage); auf Programmcode-Ebene von Code-Überdeckung (Code Coverage). Während Simulink [1] verschiedene Überdeckungsmetriken auf Modellebene anbietet (Decision Coverage, Condition Coverage, Modified Condition Decision Coverage 1, Look-up Table Coverage), unterstützt TargetLink [2] die Messung der Anweisungsüberdeckung (Statement Coverage, C1) und der Zweigüberdeckung (Decision Coverage, C2) auf Code-Ebene während der Simulation bzw. Testdurchführung. Damit lassen sich zum Beispiel Modell- oder Programmteile identifizieren, die trotz einer Vielzahl von Tests gar nicht ausgeführt wurden. Für diese Teile können dann gezielt weitere Testfälle definiert werden. Im Einzelfall kann es sogar sein, dass bestimmte Modell- und Programmteile entfernt werden können, wenn sie nicht erreichbar und somit überflüssig sind (Dead Code). Formale Verifikation Während die Validierung und die Verifikation im obigen Sinne bestimmte Anregungssituationen erzeugen, um bestimmte Systemeigenschaften zu testen, dient die formale Verifikation dem Nachweis definierter Eigenschaften des Systems. Damit ist es 1 kurz MCDC. Eine vollständige MCDC erfordert, dass für eine zusammengesetzte Verzweigungsbedingung für jede in der Bedingung enthaltene logische Verknüpfung alle Kombinationen von Wahrheitswerten der Operatoren getestet werden müssen, für die eine Wertänderung des Operators den Wahrheitswert der Verknüpfung ändern kann.

7 zum Beispiel möglich, die Korrektheit eines Systems, das heißt, die Erfüllung der Anforderungen im mathematischen Sinne zu beweisen. Der Unterschied zum dynamischen Testen liegt demnach in der Vollständigkeit und Konsistenz der Methode. Für die formale Verifikation existieren zwei grundlegende Ansätze: Model Checking und Theorem Proving, die sich unter anderem in dem Grad der möglichen Automatisierung, den notwendigen Vorkenntnissen und der Art der verifizierbaren Modelle unterscheiden. Mit dem Tool EmbeddedValidator [5] ist eine Lösung für die formale, automatisierte Verifikation von Modellen eingebetteter Systeme in Simulink, Stateflow und TargetLink mithilfe von Model Checking verfügbar. Der EmbeddedValidator prüft ein Modell gegenüber formal beschriebenen Anforderungen, wie z.b. Fehlerzustand A wird niemals erreicht oder komplexeren Anforderungen mit kausalen Zusammenhängen, die z.b. mittels temporaler Logik beschrieben werden. In der Praxis der Entwicklung von Software im Automobil ist die Anwendung der formalen Verifikation noch eher selten. Sie wird vorwiegend bei der Entwicklung sicherheitskritischer Software eingesetzt. Methodenzuordnung Tabelle 1 enthält eine Übersicht der verschiedenen, für das Testen in der Funktionsentwicklung zum Einsatz kommenden Werkzeuge und deren methodische Zuordnung. Werkzeug Methodenzugehörigkeit MTest / CTE Äquivalenzklassentest, Grenzwertanalyse, Requirements-based Testing, Black-Box-Testing Model- / Software- / Processor-in-the-Loop Black-Box-Testing, Back-to-Back-Tests Simulink Model Coverage TargetLink Code Coverage Embedded Validator Strukturelle Tests (White-Box-Testing) Strukturelle Tests (White-Box-Testing) Formale Verifikation Tabelle 1: Methodische Zuordnung der Testwerkzeuge Für die Funktionsentwicklung mit MATLAB/Simulink/Stateflow und TargetLink steht mit MTest [7] eine Plattform für das systematische und automatisierte Testen bereit. Dabei kann die Testentwicklung z.b. auf Basis der integrierten Klassifikationsbaummethode erfolgen. Darüber hinaus ist es möglich, Testvektoren aus anderen Quellen einfach zu importieren und auf das zu testende Modell anzuwenden. Dabei unterstützt MTest das durchgängige Testen in der Simulink-Simulation und in der Model-in-the-Loop-, der Software-in-the-Loop- und der Processor-in-the-Loop- Simulation. Diese Ansätze sind eher Black-Box-orientiert. Die Anbindung der Simulink Model Coverage- und der TargetLink Code Coverage- Funktionalität an MTest ergänzt diese Ansätze in Richtung des White-Box-Tests. Auch die Anbindung an automatische Testvektor-Generatoren ist auf dieser Basis möglich.

8 Die Integration von TargetLink mit EmbeddedValidator und die Kombination mit MTest schließlich komplementieren die Toolpalette mit einer Unterstützung für das Model Checking mithilfe der formalen Verifikation. Testmanagement Schon für einzelne Funktionen sind eine Vielzahl von Tests durchzuführen. Die Laufzeit liegt dabei im Bereich von Minuten für einzelne Tests bis hin zu vielen Stunden bei der Durchführung ganzer Testreihen, z.b. über Nacht oder am Wochenende. Diese große Zahl von Tests, zusammen mit den Testdaten und den Testergebnissen, erfordert den Einsatz eines effizienten Testmanagements [6]. Aufgabe des Testmanagements ist es, einen einheitlichen und strukturierten Zugang zu der Vielzahl von Tests und der dazugehörigen Daten, Modelle, Dokumente und Testergebnisse zu schaffen. Abbildung 5: Testprojekt in MTest Abbildung 5 zeigt ein Testprojekt in MTest. Es dient der Administration und Darstellung sämtlicher Projektelemente in graphischer und hierarchisch strukturierter Form. Die wichtigsten Elemente im Projektbaum und ihre Bedeutung werden in Tabelle 2 erklärt.

9 Symbol Beschreibung / Funktion Testprojekt VDC Repräsentation der Simulink-Dateien mit dem Testobjekt Simulink- bzw. TargetLink-Subsystem als Testobjekt Test für das Testobjekt VDC_Subsystem Automatisch generierte Testrahmen in Simulink bzw. TargetLink Klassifikationsbaum-Datei (CTE) Testsequenz, beschrieben mittels Klassifikationsbaummethode Verschiedene Ausführungsmodi für die Testsequenz Sequence_1 Ergebnisobjekt Tabelle 2: Elemente des MTest-Projektbaums Auf Basis der Testergebnisse lassen sich schließlich Testreports in verschiedenen Formaten und mit unterschiedlichen Detaillierungsgraden erzeugen, die zur nachhaltigen Dokumentation von Testergebnissen, zum Beispiel für entsprechende Freigabeentscheidungen dienen. Abbildung 6: Ergebnisanzeige und automatisch generierter Report in MTest

10 Abbildung 6 zeigt links die Ergebnisdarstellung in MTest und rechts einen entsprechenden Testreport. Fazit Das Testen von Software und Steuergeräten spielt eine zentrale Rolle bei der Entwicklung von Automobilelektronik. In den späten Entwicklungsphasen, insb. für den Test von Steuergeräten mithilfe der HIL-Simulation hat sich das automatisierte Testen mittlerweile etabliert. In den früheren Entwicklungsphasen besteht jedoch ein großes Potenzial, das überwiegend experimentelle Entwicklungsvorgehen um Methoden des modellbasierten, automatisierten Testens zu ergänzen. Durch die Kombination der modellbasierten Entwicklung mit dem automatisierten Testen ergibt sich eine mächtige und effiziente Sammlung von Tools und Methoden, angefangen vom Testprojektmanagement über die systematische Testfallerstellung bis hin zur automatisierten Testauswertung und der anschließenden Generierung von Testreports. Testen bezieht sich immer auf die Anforderungen, die an das Testobjekt gestellt werden. Testen kann daher nur erfolgreich sein, wenn die Anforderungen bekannt und formuliert sind, und wenn sie bei der Testspezifikation und -entwicklung berücksichtigt werden. Ansonsten kann Testen nur durch Zufall zum Erfolg führen. Dies wird umso deutlicher, wenn man berücksichtigt, dass bis zu 40% der gefundenen Steuergerätefehler durch unzureichende und unvollständige bzw. unklare Spezifikationen verursacht wird [8]. Aus diesem Grund wird Testen in Zukunft immer weniger als letzter und lästiger Schritt innerhalb der Entwicklungsketten verstanden werden, sondern zunehmend als integraler Bestandteil im gesamten Entwicklungsprozess. Literatur [1] The MathWorks: Simulink /Stateflow Produktinformation, [2] dspace GmbH: Produktinformationen zu TargetLink, MTest, AutomationDesk, [3] Grochtmann, M.; Grimm, K.: Classification Trees for Partition Testing. Software Testing, Verification and Reliability, 3, 63-82, [4] Wiesbrock, H.-W.; Lim, M.: Automatische Signalanalyse Bessere Qualität durch automatisierte Testauswertung. Elektronik Automotive 2/2004. [5] OSC Embedded Systems AG: Embedded Validator Produktinformation, [6] Lamberg, K., Richert, J.; Rasche, R.: A New Environment for Integrated Development and Management of ECU Tests. SAE , Detroit, USA, [7] Lamberg, K.; Beine, M.; Conrad, M.; Eschmann, M.; Fey, I.; Otterbach, R.; Model-based testing of embedded automotive software using MTest. SAE-Paper No , Detroit, USA, [8] Hanselmann, H.: Vom Modell zum Seriencode. Electronic Automotive III/2003