Autor: Kristian Trenkel, iSyst Intelligente Systeme GmbH<\/p>\n
Dieser Beitrag erl\u00e4utert den Einsatz von Debuggern f\u00fcr den Hardware-in-the-Loop (HIL)-Test. Es werden dabei zwei Einsatzbereiche vorgestellt: zum einen der Zugriff auf die Variablen der Software des zu testenden Steuerger\u00e4tes w\u00e4hrend der Laufzeit. Damit ist die Realisierung von White Box- und Grey Box-Tests im HIL-Test m\u00f6glich. Und zum anderen die Messung der Codecoverage der Testf\u00e4lle ohne Eingriff in die Software des Steuerger\u00e4tes. Durch die realisierte abstrakte Schnittstelle ist der Einsatz verschiedener Debugger ohne \u00c4nderung an den Testf\u00e4llen realisierbar. Es steht dabei einerseits eine generische Schnittstelle f\u00fcr den Zugriff auf die Variablen der Software zur Verf\u00fcgung. Auf der anderen Seite ist auch die Ausf\u00fchrung der Codecoverage von den eigentlichen Testf\u00e4llen getrennt.<\/strong><\/p>\n Die Entwicklung eingebetteter Systeme, wie sie beispielsweise im Automobilbereich eingesetzt werden, erfordert wegen deren st\u00e4ndig steigender Komplexit\u00e4t einen entsprechenden Einsatz von fortschrittlichen Entwicklungsmethoden und -verfahren. Mit der Komplexit\u00e4t steigt im gleichen Ma\u00dfe der Aufwand f\u00fcr den Test. Die n\u00f6tige Testtiefe l\u00e4sst sich nur durch eine h\u00f6chstm\u00f6gliche Automatisierung zeitlich und wirtschaftlich realisieren.<\/p>\n Die Testautomatisierung, wie sie zum Beispiel beim Hardware-in-the-Loop (HIL)-Test zum Einsatz kommt, ist vor allem im Automotive-Umfeld verbreitet. Zur Erreichung der n\u00f6tigen Testtiefe, vor allem im Hinblick auf sicherheitskritische Funktionen wie Fahrerassistenzsysteme, sind reine Black-Box-Tests nicht ausreichend. Es besteht die Notwendigkeit, auch White-Box- und Grey-Box-Tests mit der realen Hardware und Software in Echtzeit auszuf\u00fchren. F\u00fcr den Zugriff auf die Variablen des zu testenden Steuerger\u00e4tes kommt h\u00e4ufig das Protokoll XCP [1] zum Einsatz. Die Verwendung des Protokolls beeinflusst jedoch die Laufzeit der Software im Steuerger\u00e4t.<\/p>\n Durch Verwendung von Debuggern in Verbindung mit den Funktionen moderner Mikrokontroller ist es dagegen m\u00f6glich, in Echtzeit auf Steuerger\u00e4te-Variablen zuzugreifen und diese damit im Test zu lesen und zu schreiben. Dar\u00fcber hinaus ist die Ausf\u00fchrung von Codecoverage-Messungen ohne Instrumentierung des Codes m\u00f6glich. In der Praxis stellt sich damit die Herausforderung der Integration von Debuggern in die Testautomatisierungsumgebung.<\/p>\n Im Folgenden ist die Integration und Anwendung der Debugger BlueBox mit der Software winIDEA der Firma iSYSTEM [2] sowie der Debugger PowerDebug mit der Software Trace32 der Firma Lauterbach [3] in die Testautomatisierung iTestStudio dargestellt.<\/p>\n Das Testautomatisierungswerkzeug iTestStudio der iSyst Intelligente Systeme GmbH wird zur Erstellung und automatisierten Ausf\u00fchrung von Tests under Verwendung der Testsysteme, z.B. HIL-Testsysteme, eingesetzt. Dabei wird auf die verschiedenen Test-Tools, wie zum Beispiel CANape, CANalyzer und ControlDesk, \u00fcber Automatisierungsschnittstellen (z.B. COM) zugegriffen.<\/p>\n Die Software iTestStudio besteht aus verschiedenen Komponenten, welche in Abbilung 1 (siehe\u00a0PDF<\/a>) dargestellt sind.<\/p>\n Das Zusammenspiel der einzelnen Komponenten f\u00fcr die Testausf\u00fchrung ist in Abbildung 2 (siehe\u00a0PDF<\/a>) zu sehen.<\/p>\n Die Komponente iTestStudio TA (siehe Abbildung 3,\u00a0PDF<\/a>) stellt die eigentliche Benutzeroberfl\u00e4che dar. Diese umfasst die Organisation der Testf\u00e4lle mit der Zusammenstellung von Testserien und Testsequenzen (siehe Abbildung 4,\u00a0PDF<\/a>), das Ausf\u00fchren\/Starten der Testskripte und das Erstellen der Testreports.<\/p>\n Der zweite Teil beinhaltet die TestSupport-Bibliotheken. Diese Bibliotheken k\u00fcmmern sich um die Ausf\u00fchrung der Tests mit der zugeh\u00f6rigen Python-Version, welche nicht zwingend die Python-Version der iTestStudio TA GUI sein muss. Dar\u00fcber hinaus sind Funktionen zum Speichern der Ergebnisse enthalten.<\/p>\n Die dritte Komponente ist das TestToolkit. Dieses enth\u00e4lt spezielle Testfunktionen, Schnittstellen zu Tools (wie Vector, CANape oder dSPACE ControlDesk) sowie Container f\u00fcr Cal- und HIL-Variablen im Steuerger\u00e4t, auf welche zum Beispiel \u00fcber XCP mittels des Tools CANape zugegriffen werden kann. F\u00fcr die Anbindung der Debugger wurden entsprechende Adapter zwischen den Automatisierungsschnittstellen der Debugger un den Cal-Variablen geschaffen.<\/p>\n In Abbildung 5 (siehe\u00a0PDF<\/a>) ist der schematische Aufbau eines HIL-Testsystems zu sehen, wie er f\u00fcr die hier beschriebenen Tests eingesetzt wird. Eine ausf\u00fchrliche Beschreibung des Aufbaus ist in [4] zu finden.<\/p>\n Die zentrale Komponente des HIL-Testsystems ist der Echtzeitrechner, welcher die Umgebungssimulation f\u00fcr das Steuerger\u00e4t ausf\u00fchrt. Dar\u00fcber hinaus ist der Steuer-PC von zentraler Bedeutung. Dieser dient der Ausf\u00fchrung der Testf\u00e4lle\/Testskripte. Des Weiteren bindet er auf der einen Seite den Echtzeitrechner an. Auf der anderen Seite ist hier auch der Debugger angeschlossen.<\/p>\n F\u00fcr die Realisierung von White-Box- und Grey-Box-Tests im Rahmen des HIL-Tests ist der Zugriff auf Variablen im Steuerger\u00e4t notwendig. Das Debug-Interface (z.B. BDM oder Nexus) moderner Mikrokontroller erlaubt den Zugriff auf den Speicher des Mikrokontrollers und damit auf Variablen der Software w\u00e4hrend der Laufzeit, ohne dabei die Ausf\u00fchrungszeit der Software zu beeinflussen. Zu beachten ist, dass nur der Zugriff auf globale Variablen m\u00f6glich ist. Der Zugriff auf lokale Variablen ist nur innerhalb des jeweiligen G\u00fcltigkeitsbereiches der Variablen durchf\u00fchrbar, was ein Anhalten der Software an der entsprechenden Stelle notwendig machen w\u00fcrde.<\/p>\n Aus Sicht des implementierten Testfalles sollte der Variablenzugriff abstrahiert sein. Innerhalb des Testfalles sollen keine Abh\u00e4ngigkeiten vom eingesetzten Tool bzw. der eingesetzten Schnittstelle vorhanden sein. Diese Anforderungen wurden durch ein zweistufiges Abstraktionskonzept realisiert.<\/p>\n Die erste Stufe bildet eine Klasse, welche eine einzelne Variable repr\u00e4sentiert. Es existiert dabei eine allgemeine Basisklasse (VarBase<\/em>), die das Interface definiert, und jeweils eine Implementierung f\u00fcr die verschiedenen Quellen von Variablen (z.\u00a0B. CANape, winIDEA oder Trace32). In Abbildung 6 (siehe\u00a0PDF<\/a>) ist ein Ausschnitt des Codes f\u00fcr die Klasse\u00a0EcuVar<\/em>\u00a0zusehen, welche die Anbindung zu winIDEA realisiert. Hierbei ist nur der Parameter\u00a0context<\/em>\u00a0der Methode\u00a0__init__<\/em>\u00a0toolspezifisch. Dieser enth\u00e4lt die Referenz auf die Schnittstelle von winIDEA. Der Parameter\u00a0identifier<\/em>\u00a0enth\u00e4lt den Namen der Variablen. Die \u00fcbrigen Parameter erlauben es der Variablen weitere Informationen, wie zum Beispiel eine Ma\u00dfeinheit, mitzugeben, um diese beispielsweise f\u00fcr die Ausgabe in den Testreport zu verwenden.<\/p>\n Als Schnittstelle f\u00fcr den Test stehen die Methoden\u00a0set<\/em>\u00a0und\u00a0get<\/em>\u00a0zur Verf\u00fcgung, welche das Schreiben und das Lesen der jeweiligen Variablen unabh\u00e4ngig vom eingesetzten Tool erm\u00f6glichen.<\/p>\n Die zweite Stufe der Abstraktion bildet eine Container-Klasse, welche alle Variablen f\u00fcr ein Testprojekt bzw. ein Steuerger\u00e4t sammelt und das Handling toolspezifischer Eigenschaften (z.B. Starten des Tools) realisiert. In Abbildung 7 (siehe\u00a0PDF<\/a>) ist die Definition des Variablen-Containers zu sehen.<\/p>\n Innerhalb des Variablen-Containers wird dann f\u00fcr jede Variable, welche im Test verwendet werden soll, eine Instanz der Variablen-Klasse (z.\u00a0B.\u00a0EcuVar<\/em>) angelegt. In Abbildung 8 ist die Anwendung der beiden Klassen zu sehen. Die Klasse\u00a0EcuVars<\/em>\u00a0ist die projektspezifische Umsetzung des Variablen-Containers und enth\u00e4lt verschiedene Variablen. Im Beispiel in Abbildung 8 (siehe\u00a0PDF<\/a>) ist dies f\u00fcr eine Variable zu sehen. Im Testfall ist die Variable\u00a0„(((TDFM).dummy_module).dummy_structure).State_en“<\/em>\u00a0des Steuerger\u00e4tes als\u00a0state_en<\/em>\u00a0zugreifbar.<\/p>\n Im eigentlichen Testfall kann nun auch auf die Variable mit\u00a0set<\/em>\u00a0bzw.\u00a0get<\/em>\u00a0zugegriffen werden, ohne dass bekannt sein muss, welches Tool verwendet wird. In Abbildung 9 (siehe\u00a0PDF<\/a>) ist beispielhaft die Anwendung in einem Testfall zu sehen. Als Erstes wird eine Referenz auf den Variablen-Container erzeugt und in der Variablen\u00a0ecu<\/em>\u00a0gespeichert. Mittels\u00a0ecu.state_en<\/em>\u00a0kann dann auch auf die Steuerger\u00e4te-Variable zugegriffen werden.<\/p>\n F\u00fcr die Bestimmung der Testabdeckung ist die Messung des durchlaufenen Codes auf dem Steuerger\u00e4t wichtig. Vor allem im Kontext sicherheitskritischer Systeme (z.\u00a0B. ISO 26262) ist die Bestimmung der Codecoverage essenziell. F\u00fcr diese wird meist eine Instrumentierung der Software des Steuerger\u00e4tes verwendet. Dies hat aber Einfluss auf Laufzeit und Speicherverbrauch und somit unter Umst\u00e4nden auch auf die Testergebnisse.<\/p>\n Moderne Mikrokontroller erlauben es die durchlaufenen Codezeilen (durchlaufener Bin\u00e4rcode) mittels des Debug-Interfaces zur Laufzeit der Software in Echtzeit zu bestimmen. Diese Informationen k\u00f6nnen w\u00e4hrend der Testausf\u00fchrung aufgezeichnet und nach Abschluss aller Tests auf die Codecoverage des C-Codes des Steuerger\u00e4tes gemapped werden.<\/p>\n Bei der Umsetzung der Codecoverage-Messung f\u00fcr das iTestStudio hat sich gezeigt, dass die Integration ohne \u00c4nderungen an den Testf\u00e4llen m\u00f6glich ist. Das Test-Environment, wie es in Abbildung 2 (siehe\u00a0PDF<\/a>) zu sehen ist, stellt einheitliche Funktionen zum Einschalten und Ausschalten des Steuerger\u00e4tes zur Verf\u00fcgung. Diese werden durch die Implementierung der Testf\u00e4lle nur aufgerufen, w\u00e4hrend die Anbindung f\u00fcr die Codecoverage-Messung im projektspezifischen Teil der Funktionen erfolgen kann. Beim Einschalten des Steuerger\u00e4tes wird die Messung gestartet und beim Ausschalten des Steuerger\u00e4tes die Codecoverage-Information gespeichert.<\/p>\n Die eigentliche Auswertung der Codecoverage-Information erfolgt nach der Testdurchf\u00fchrung mit Hilfe des jeweiligen Tools des Debugger-Herstellers.<\/p>\n Test eines Lenkradschloss-Steuerger\u00e4tes<\/strong><\/p>\n In einem HIL-Testprojekt f\u00fcr das Steuerger\u00e4t eines Lenkradschlosses stand f\u00fcr den Variablenzugriff keine XCP-Unterst\u00fctzung zur Verf\u00fcgung. Es war innerhalb des Projektes auch nicht m\u00f6glich, dies zu implementieren. Da die Einstufung als sicherheitskritisches System eine tiefgehende Testabdeckung erforderte, war es n\u00f6tig, einen alternativen Weg f\u00fcr den Variablenzugriff zu finden.<\/p>\n Mit Hilfe der BlueBox und winIDEA konnte unter Verwendung der Python-Schnittstelle von winIDEA ein Zugriff in die Steuerger\u00e4te-Software realisiert werden. Die Integration in die Testumgebung erfolgt, wie im Kapitel\u00a0Variablenzugriff\u00a0<\/em>beschrieben.<\/p>\n Codecover-Messungen bei einem Steuerger\u00e4t f\u00fcr eine Wankstabilisierung<\/strong><\/p>\n Im Rahmen eines HIL-Testprojektes f\u00fcr eine Wankstabilisierung wurde die Messung der Codecoverage f\u00fcr die ausgef\u00fchrten HIL-Tests notwendig. Bedingt durch die Einstufung als sicherheitskritisches System kam eine Instrumentierung des Codes des Steuerger\u00e4tes nicht in Frage.<\/p>\n Als alternative L\u00f6sung wurde die Messung der Codecoverage mittels Debugger ausgef\u00fchrt. Dabei kamen sowohl winIDEA\/BlueBox also auch Trace32\/PowerDebug zum Einsatz. Die Einbindung in die Testumgebung erfolgte unter Verwendung der Automatisierungsschnittstellen der beiden Tools wie im Kapitel\u00a0Codecoverage\u00a0<\/em>beschrieben.<\/p>\n Es konnte damit ohne eine \u00c4nderung an den Testf\u00e4llen oder an der Steuerger\u00e4te-Software die Codecoverage der HIL-Testf\u00e4lle ermittelt werden. Der Implementierungsaufwand f\u00fcr die Umsetzung der Codecoverage-Messungen kann als gering bezeichnet werden. Des Weiteren kann die erarbeitete L\u00f6sung in jedem anderen HIL-Testprojekt, welches das iTestStduio verwendet, eingebunden werden.<\/p>\n Die Einbindung von Debuggern in den HIL-Test erweitert die M\u00f6glichkeiten des HIL-Tests auf White-Box- und Grey-Box-Tests, ohne dass Protokolle wie XCP verwendet werden m\u00fcssen und damit die Laufzeit der Steuerger\u00e4te-Software beim Test ver\u00e4ndert wird. Weiterhin erlaubt die Durchf\u00fchrung der Codecoverage-Messung mit Hilfe der Debugger die exakte Bestimmung der Testabdeckung auf Codeebene, ohne dass die Software des Steuerger\u00e4tes instrumentiert werden muss. Die Messung hat somit keinen Einfluss auf die Codegr\u00f6\u00dfe, den Speicherverbrauch und die Laufzeit. Bei der Realisierung der Einbindung der Debugger in die HIL-Umgebung und der Anbindung an die Testautomatisierung wurde von Anfang an auf eine generische Schnittstelle Wert gelegt. Es hat sich gezeigt, dass damit der Austausch der Debugger ohne Anpassung der Tests m\u00f6glich ist.<\/p>\n [1]\u00a0ASAM e.V., „ASAM MCD-1 XCP“, ASAM e.V., 27 05 2015. [Online]<\/a>\u00a0[Zugriff am 12 10 2016]<\/p>\n [2]\u00a0iSYSTEM AG, „iSYSTEM AG“, iSYSTEM AG, [Online]\u00a0<\/a>[Zugriff am 12 10 2016]<\/p>\n [3]\u00a0Lauterbach GmbH, „Lauterbach GmbH“, Lauterbach GmbH, 12 10 2016. [Online]<\/a>\u00a0[Zugriff am 12 10 2016]<\/p>\n [4] K. Trenkel, „From developer\u2019s tool to HIL test system“,\u00a0CAN Newsletter,\u00a0<\/em>Nr. 03\/2016, pp. 28-31, 03 2016<\/p>\n Beitrag als PDF downloaden Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nDas Tool iTestStudio<\/h2>\n
iTestStudio TA<\/h3>\n
TestSupport-Bibliotheken<\/h3>\n
TestToolkit<\/h3>\n
Einbindung ins HIL-Testsystem<\/h2>\n
Variablenzugriff<\/h2>\n
Codecoverage<\/h2>\n
Anwendungsbeispiele<\/h2>\n
Zusammenfassung<\/h2>\n
Quellenverzeichnis<\/h2>\n
\n<\/strong><\/a><\/p>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n