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 41 www designelektronik de Unterfunktionen aufzurufen überspringt die CPU beide Funktionen und injiziert stattdessen den gewünschten Rückgabewert direkt in das dafür vorgesehene CPU-Register Anschließend wird die CPU bis zur Funktionsrückgabe ausgeführt – hier liest der Debugger den Ergebniswert aus der sich anhand einiger Pass Fail-Kriterien überprüfen lässt All das funktioniert mit unverändertem Produktionscode Fehlerinjektion Nach dem Unit-Test geht es weiter zu den Tests auf Systemebene zum Beispiel innerhalb einer Hardwareinthe-Loop-Konfiguration In diesem Fall kann ein Debugger sehr nützlich sein um Fehler in das System zu injizieren und so die Auswirkungen auf die FFI in Bezug auf Speicherkorruption Ausführung und Informationsaustausch zu testen Man nutzt den Debugger um Onthefly-Manipulationen an On-Chip-Ressourcen wie CPU-Kernregistern sowie Speicher vorzunehmen und anschließend die Auswirkungen zu untersuchen Bild 4 Aber auch an externen Schnittstellen können Fehler eingespeist werden Addon-Module für CAN LIN und Analog Digital-Signale die Entwickler direkt an die Debugger-Hardware und das Zielsystem anschließen können sie fehlerhafte Daten in einen Analog-Digital-Konverter ADC oder in externe über CAN oder SPI angeschlossene Sensoren injizieren So lässt sich beispielsweise überprüfen ob eine Fehlfunktion einer QM-Software Auswirkungen auf die Ausführung einer ASIL-Funktion haben kann Wie das System auf solche Manipulationen reagiert beobachten Entwickler zum Beispiel mithilfe von On-Chip-Traces dem Aufzeichnen von Abläufen in der Software in Echtzeit über Protokollieren von Ausführungszeiten im Bereich von Taktzyklen Die Hardware-Debugger-Verbindung zwischen PC und realer Ziel-Hardware ist dabei essenziell Sprich eine entsprechende On-Chip-Debug-Trace-Schnittstelle auf dem in der ECU verbauten Prozessor muss vorhanden und herausgeführt sein Timing-Analysen Doch On-Chip-Traces ermöglichen nicht nur das Verhalten der Software zu überwachen Weil Hardware-Traces absolut nonintrusive sind also keinen Einfluss auf die Laufzeit haben eignen sie sich ideal für die Timing-Analyse Timing-Tests sollten Entwickler unbedingt als Teil der Systemintegrationstests durchführen Die zunehmende Last auf die Betriebssystem-Tasks wirkt sich auf die gesamte Timing-Planung aus und später lassen sich kritische Zeitvorgaben nicht mehr einhalten Bei Timing-Analysen in Hinblick auf Sicherheit und FFI ist es zudem sinnvoll einen Blick auf die Timing-Margins zu werfen Im Grunde lässt sich die Robustheit des gesamten Software-Timings überprüfen An einem Anwendungsfall lässt sich zeigen was ein kombiniertes Debugund Trace-Tool leisten kann Auf einer CPU laufen drei Tasks ein 100-ms-50-msund ein 10-ms-Task – der 10-ms-Task hat die höchste Priorität Hierbei werden der Runnable des 10-ms-Task immer mehr Funktionen hinzugefügt und dabei die Auswirkung auf die Antwortzeit der 100-ms-Task gemessen Ein solcher Test lässt sich recht einfach durch Hinzufügen von Instrumentierungscode zur Runnable realisieren um die Laufzeit zu verlängern Ein Debugger ist in der Lage den Instrumentierungscode Referenzen [1] Markt Technik Trend Guide »Industriecomputer Embedded-Systeme« April 2022 Seite 38ff [2] Design Elektronik Ausgabe 08-09 21 Oktober 2021 Seite 6ff Armin Sting ist Chief Solutions Officer bei iSystem einem Tasking-Unternehmen Bild 5 Mit Hardware-Traces lassen sich die Timing-Bedingungen verschiedener Tasks messen während des Testlaufs zu ändern So lässt sich die Laufzeit der Runnable variieren ohne die Software neu zu erstellen Ein beispielhaftes Ergebnis ist in Bild 5 dargestellt Die grüne Kurve zeigt die Antwortzeit des 100-ms-Task gegenüber der Laufzeit der 10-ms-Runnable Angenommen der 100-ms-Task hat die zeitliche Einschränkung dass die Antwortzeit 85 ms nicht überschreiten darf Die Zeitbeschränkung lässt sich erreichen solange die Laufzeit der 10-ms-Runnable unter 4 5 ms bleibt Interessant ist außerdem dass die Antwortzeit an einem bestimmten Punkt fast exponentiell ansteigt und an dem Punkt auch die CPU-Last nicht mehr zunimmt Das ist ein klares Indiz dafür dass das Betriebssystem-Scheduling nicht mehr wirklich zuverlässig funktioniert da das System bereits überlastet ist Hardware-Debugger als Prozesswerkzeug Der Hardware-Debugger ist zunehmend ein Prozesswerkzeug – die Basisfunktionen eines Debuggers finden ihre gewohnte Anwendung und lassen sich mit mächtigen Analysefunktionen ergänzen Alle vorgestellten Anwendungsfälle und Tools können Entwickler zu einer Continuous-Integration-Pipeline zusammenführen die explizit auf das Testen der Softwaresicherheit ausgerichtet ist So lässt sich ein Testablauf erstellen von der statischen Code-Analyse über Unit-Tests auf dem Zielsystem bis zu Debugund Trace Timing -Tests Natürlich ist es nicht sinnvoll all die Tests bei jedem Commit durchzuführen Möglich wäre zum Beispiel eine Strategie die vorsieht dass die Tests auf Codeebene lediglich nachts laufen oder lediglich bei Software Releases und die Integrations-Tests jedes Mal wenn Softwarezweige im Master-Trunk zusammengeführt werden ts Bild Tas ki ng