Startseite > Automotive > Software + Tools > Mit Trace32 vom realen zum virtuellen Target

Timinganalyse auf virtuellem Steuergerät

Mit Trace32 vom realen zum virtuellen Target

28. Februar 2024, 14:00 Uhr | Autor: Frank Riemenschneider, Redaktion: Irina Hübner

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Herausforderung Tracen über MCD-API

Trace-Quellen zur Verfügung stellt. Voraussetzung, damit dies funktioniert, ist, dass die Simulation erstens die Trace-Daten erzeugt und bereitstellt und zweitens die Möglichkeit bietet, über die API diese Trace-Daten abzurufen.

Zum Hintergrund: In der Praxis lieferte das VLAB-Modell zum Beginn des Projektes, bedingt durch eine nicht zu 100 % implementierte MCD-API, inkonsistente Trace-Daten. Was allerdings noch schwerwiegender war, war der nicht implementierte Daten-Trace, der für ARTI essenziell ist. Die Simulation zeichnete zwar den Programmablauf auf, aber keine Daten. Es wäre jedoch zwingend notwendig gewesen, dass Trace32 der VLAB-Simulation vorgeben kann, selektiv bestimmte Daten aufzuzeichnen, beispielsweise wenn auf eine bestimmte Speicherstelle geschrieben wird.

Im Gegensatz zum Debuggen funktionierte das Tracen des VLAB-Modells über die MCD-API zunächst nicht direkt, obwohl eine der Sub-APIs eine generische Trace-Schnittstelle mit vordefinierten

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

In der Folge hat Lauterbach im Interesse von ZF ab März 2022 mit ASTC zusammengearbeitet, um den fehlenden Daten-Trace zu implementieren sowie die Inkonsistenzen der MCD-API zu beseitigen. Im August 2022 war das überarbeitete Modell von ASTC inklusive Daten-Trace fertig. Bild 5 zeigt exemplarisch die Konfiguration zur Aufzeichnung von Variablen mit Lauterbachs PowerView-Software.

Allerdings können noch weitere Herausforderung auftreten. Der TC397XE beinhaltet bekanntlich sechs Cores, die beim Trace alle aufgezeichnet werden sollen. In dem Szenario bei ZF mit dem selektiven ARTI-Trace lieferte Core 0 Tausende relevante Nachrichten, während die anderen Cores fast keine lieferten, obwohl sie nicht im Idle-Modus waren, sondern ebenfalls Workloads abarbeiteten. Sie erzeugten eben nur nicht so viele relevante Trace-Nachrichten wie Core 0.

Bild 6 zeigt ein solches Szenario aus Vereinfachungsgründen reduziert auf drei Cores. Zum Zeitpunkt t0 liefern alle drei Cores eine Nachricht, zu den Zeitpunkten t1, t2 und t3 jedoch nur Core 0, während Core 1 und 2 ihre erste weitere Nachricht nach der zum Zeitpunkt t0 übermittelten erst später – nämlich zum Zeitpunkt t4 – liefern. Wenn nun zu den Zeitpunkten t0, t1, t2, t3 und t4 jeweils alle Cores nacheinander abgefragt wurden, kamen die Nachrichten in eine falsche zeitliche Reihenfolge (Bild 6 oben).

Die richtige Reihenfolge wären nach der Abfrage von Core 0, Core 1 und Core 2 zum Zeitpunkt t0 vier weitere Nachrichten von jeweils Core 0 bei t1, t2, t3 und t4 und erst dann wieder Core 1 und Core 2 ebenfalls bei t4 (Bild 6 unten). Lauterbach arbeitete in der Folge daran, die Timestamps vor dem Export in die richtige Reihenfolge zu bringen, die von Vectors TA Tool Suite für die Zeitanalysen zwingend erwartet wird. Im Januar 2023 lief der Trace dann wie gewünscht.

Laufzeitanalyse im Zeitalter von Multi-Core-SoCs

ZF nutzt nun erfolgreich VLAB Virtual Development Machines von ASTC, auf dem die eigene Applikation läuft. Lauterbachs PowerView kommt als Frontend für die Virtualisierung zum Einsatz. Mittels Programm- und Daten-Trace wird das Zeitverhalten aufgezeichnet und an Vectors TA Tool Suite exportiert.

Natürlich muss schon aus Zertifizierungsgründen vor der Auslieferung alles auch auf einem realen Target nachvollzogen werden. Hierzu nutzt ZF einerseits den On-Chip-Trace, da der Trace-Puffer bei ARTI bis zu einer Aufzeichnungsdauer von 1 Sekunde oder sogar noch länger ausreicht und andererseits Lauterbachs Hardwaremodul CombiProbe [5] für noch längere Aufzeichnungen.

Der Mehrwert für ZF ist offensichtlich: Zum einen wird zu Beginn eines Entwicklungsprojektes kein reales Target mehr benötigt, zum anderen können auf dem CI-Server nächtliche, automatisierte Tests mit ebenso automatischer Requirement-Analyse durchgeführt werden. Dies bedeutet, dass jede Softwareänderung automatisch sofort auf das Zeitverhalten überprüft wird.

Derzeit geht der Trend in der Automobilindustrie klar in Richtung Konsolidierung von mehreren Anwendungen auf einer ECU. Dabei ist es umso wichtiger, im Entwicklungsprozess ständig zu prüfen, ob die ECU die Last überhaupt noch mitmacht oder die Zeitvorgaben nicht mehr erfüllt werden können. Früher im Zeitalter der »einfachen« Single-Core-CPUs mit In-Order-Befehlsausführung gab es mathematische Methoden, mit denen man die Laufzeit einzelner Funktionen einfach berechnen konnte. Heute, im Zeitalter von Multi-Core-SoCs, mehrstufigen Cache-Architekturen und Out-of-Order-Befehlsausführung funktioniert das so nicht mehr. Hier hilft dann tatsächlich nur noch konkretes Messen. Dieses erfolgreiche Projekt bei ZF dürfte daher in ähnlicher Form in der gesamten Automobilindustrie Schule machen

Literatur

[1] Die TA Tool Suite von Vector: https://www.vector.com/ta-tool-suite
[2] Der virtuelle Aurix von ASTC: https://vlabworks.com/vlab-vdms/
[3] Lauterbach’s PowerView Debug- und Trace-Software: https://www.lauterbach.com/products/software/trace32-powerview
[4] Download der MCD-API: https:// www.lauterbach.com/products/software/ debugger-for-simulators/mcd-api#:~: text=Within%20the%20scope%20of%20this%20project%2C%20ARM%2C%20Infineon,interface%20to%20both%20real%20hardware%20and%20software %20simulations.
[5] Lauterbach’s TRACE32® CombiProbe: https://www.lauterbach.com/products/trace-extensions/combiprobe

Der Autor

Frank Riemenschneider

studierte Elektrotechnik mit dem Schwerpunkt Mikroelektronik an der Leibniz Universität Hannover. Als Senior Marketing Engineer ist er bei Lauterbach u. a. auch für die Erstellung von Print- und Online-Content auf allen relevanten Plattformen zuständig