Der Blätterkatalog benötigt Javascript.
Bitte aktivieren Sie Javascript in Ihren Browser-Einstellungen.
The Blätterkatalog requires Javascript.
Please activate Javascript in your browser settings.
DESIGN ELEKTRONIK 03 2023 40 www designelektronik de Hardware Safety sobald die MPU aktiviert ist kann man die Software im Voraus vorbereiten Und das ohne die Software tatsächlich auf einer realen Hardware auszuführen Unit-Tests auf der Ziel-Hardware Der nächste Testschritt in der ECU-Entwicklung ist der Unit-Test In den meisten Fällen führen Entwickler Unit-Tests auf Quellcode-Ebene und auf einem Host-PC aus Das bedeutet dass man den zu testenden Quellcode in ein Test-Framework verpackt Hier lassen sich sogenannte Stubs hinzufügen Es handelt sich um zusätzlichen Code der während des Testablaufs eine andere Code-Komponente ersetzt zum Beispiel um eine noch nicht implementierte Komponente oder Hardwareabhängige Komponenten wie I Os zu simulieren Zusammen mit den Testfällen wird das gesamte Paket kompiliert und auf dem Host-Rechner wie einem Windowsoder Linux-PC ausgeführt Das Ergebnis ist ein Testbericht der im Wesentlichen ein »bestanden« »nicht bestanden« für alle Testfälle angibt normalerweise zusammen mit einem Code-Coverage-Report Weil das Ausführen auf dem PC erfolgt ist das grundsätzliche Ausführen auf der realen Hardware nicht mit abgedeckt Somit kann es sein dass die Tests unter Umständen keine identischen Ergebnisse liefern Deshalb empfiehlt die ISO26262 »Die Testumgebung für Software-Unit-Tests soll so weit wie möglich der Zielumgebung entsprechen « Warum also nicht den Test direkt auf dem Ziel ausführen? Entwickler setzen Hardware-Debug-Tools traditionell zum Entwickeln und der Fehlersuche bei Treibern Board Hardware Bringup Boot-Prozessen und vielem mehr ein Also für das »minimalinvasive« Hardwarenahe Entwickeln von Embedded-Software Neben diesen Standardmethoden bieten Hardware-Debugger ebenfalls Methoden zum Steuern von Softwaretests auf dem Zielsystem Hierbei verbindet der Debugger die eigentliche Ziel-Hardware über Standard-Debug-Schnittstellen mit dem Zweck Embedded-Software so nah wie möglich auf der eigentlichen Hardware zu entwickeln und zu testen Das hilft speziell im Hinblick auf die Sicherheitsanforderungen das heißt FFI Ausführung und Timing sowie Informationsaustausch Hierzu bieten sich einige spezifische Testanwendungsfälle an Beim Setup für einen Unit-Test wird der Quellcode der zu testenden Software für das Zielgerät crosscompiliert und nicht instrumentiert Somit lässt sich der ursprüngliche Produktionscode auf dem Zielgerät testen Die eigentliche Steuerung des Targets zum Ausführen des Tests also das Herunterladen des Codes der Aufruf der Unit also der zu testenden C-Funktion das Setzen der Testeingangsvektoren und das Rücklesen der Testergebnisse erfolgt über den zugrunde liegenden Debugger wie »winIDEA« mit »BlueBox« von Tasking Bild 2 Wie beim Ausführen auf einem Host-PC werden hier ähnliche Testergebnisse generiert Pass Fail-Ergebnisse für jeden Testfall und ein Code-Coverage-Report Allerdings wird hier die Codeabdeckung auf der Grundlage einer Hardware-Trace-Aufzeichnung und wie bereits erwähnt ohne jegliche Quellcode-Instrumentierung gemessen Für ein besseres Verständnis wie ein Unit-Test auf einem realen Ziel ohne Code-Instrumentierung ausgeführt wird soll der Unit-Test für die C-Funktion »calculateFuel-Efficiency« als konkretes Beispiel Bild 3 dienen Beim Einsatz eines Debuggers ist nicht die gesamte Applikation bis zum Funktionsaufruf auszuführen Der Debugger kann den Instruction Pointer der CPU direkt auf den Funktionseinstieg setzen Gemäß den C-Aufrufkonventionen richtet der Debugger den Stack-Frame für die Funktion ein und startet dann die CPU Ist ein Stubbing oder eine Dateninjektion erforderlich zum Beispiel wenn Unterfunktionen aufgerufen werden stoppt der Debugger die CPU Anstatt die Bild 3 Beispiel für Debugging im Unit-Test Eine C-Funktion »calculateFuelEfficiency« Bild 4 Mit injizierten Fehlern können die Auswirkungen auf ein System überprüft werden Bild Tasking Bild Tas ki ng