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

Das Verständnis des Laufzeitverhaltens einer Embedded-Anwendung ist entscheidend zur Optimierung der Leistungsfähigkeit und zur Erfüllung der Safety-Anforderungen. Zusammen mit Lauterbach konnte ZF Timing-Analysen für Automotive-Steuergeräte von realer Hardware auf virtuelle Targets verlagern.

▶ Diesen Artikel anhören

ZF mit Hauptsitz in Friedrichshafen ist mit seinen weltweit 160.000 Mitarbeitern einer der bedeutendsten Zulieferer für die Automobilindustie. Das Unternehmen arbeitet an fast allen aktuellen Mobilitätsthemen – von Nachhaltigkeit über Elektromobilität, automatisiertem und autonomem Fahren bis hin zu Software, Digitalisierung und Vehicle Motion Control. Zur umfangreichen Produktpalette von ZF gehören auch automobile Steuergeräte (Electronic Control Unit, ECU), die an nahezu alle bekannten Automobilhersteller gehen.

Bei der Entwicklung einer Embedded-Anwendung wie einer ECU ist nicht nur eine fehlerfreie Software essenziell, sondern auch das Verständnis des Laufzeitverhaltens der Anwendung für die Optimierung der Ressourcennutzung und der Performance sowie letztendlich für die Erfüllung aller Safety-Anforderungen von entscheidender Bedeutung.

Hierzu erfolgt mit entsprechenden Tools die Messung der Ausführungszeiten und die Überprüfung der Timing-Anforderungen. Dafür muss der Nutzer Hardwareereignisse mittels Trace auf Instruktionsebene aufzeichnen und die Trace-Daten zu Systemereignissen auf einem abstrahierten Level verarbeiten, was man als Profiling bezeichnet.

Um überhaupt Tracen zu können, muss der Nutzer Chips einsetzen, die Trace-fähig sind. Dies ist auch im Jahr 2023 aus ökonomischen Gründen noch nicht bei allen Mikrocontrollern oder Prozessoren der Fall. ZF hat diese Anforderung von Anfang an berücksichtigt und setzt neben anderen Chips auf den Aurix TC397XE, einen Mikrocontroller von Infineon mit sechs TriCore-CPUs, die jeweils mit 300 MHz getaktet sind. Die im TC397XE implementierte Multi-Core Debug Solution (MCDS) bietet einen parallelen und zeitlich abgestimmten Trace von Cores und Bussen, leistungsstarke Triggerbedingungen und On-Chip-Logik-Analyzer-Funktionen.

Die TriCore-CPU-Architektur ist insbesondere auch für hohe Interrupt-Lasten ausgelegt, wie sie zum Beispiel bei Motorsteuerungen auftreten. ZF ist dank der vorausschauenden Chip-Auswahl nicht gezwungen, eine rein softwarebasierte Analyse vorzunehmen, wie dies bei nicht Trace-fähigen Chips der Fall wäre. Die in diesem Fall erforderliche Code-Instrumentierung hätte erheblichen Einfluss auf das Zeitverhalten und würde die gewonnen Messergebnisse nur bedingt nutzbar machen.

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

Zudem achtete ZF auch von Anfang an darauf, dass die selbst entwickelte Software für entsprechende Timing-Analysen vorbereitet ist. Beim sogenannten »Real-Time Flow Trace« mit Lauterbachs Trace32-Tools werden die Informationen des Adress-/Datenbusses von den MCDS so übertragen, wie sie direkt am CPU-Kern anfallen (Bild 1).

Das Verfahren an sich ist keine »Raketenwissenschaft«, allerdings unterscheiden sich die Trace-Produkte unterschiedlicher Hersteller in Bezug auf Datenraten und Funktionsumfang. Auch wenn ein Flow Trace durch den Einsatz von Lauterbachs Trace32 bereits sehr mächtig ist, konnten die Analysefähigkeiten mit der Einführung von ARTI (AUTOSAR Runtime Interface) bei ZF im November 2021 durch eine gemeinsame ZF/Lauterbach-Projektgruppe nochmals erheblich ausgebaut werden. Lauterbach war von Anfang an Mitglied in den entsprechenden AUTOSAR-Gremien und hat an diesem neuen Standard wesentlich mitgearbeitet.

ARTI erweitert Analysemöglichkeiten in AUTOSAR

ARTI verwendet einen ähnlichen Ansatz wie sein Vorgänger ORTI (OSEK Runtime Interface), erweitert aber die Trace-Möglichkeiten und behebt einige Defizite der ORTI-basierten Analyse. Mit ORTI ist der Entwickler meist nicht in der Lage, im Trace zwischen Task-Beendigung, Unterbrechung und Warten zu unterscheiden, da nur Task-Wechsel aufgezeichnet werden können. Er kann somit keine detaillierte Timing-Analyse etwa zu Aktivierungsverzögerungen oder Gesamtantwortzeit durchführen.

Darüber hinaus werden Runnables nicht von der ORTI-Datei erfasst, ebenso wenig wie die Kommunikation zwischen Softwarekomponenten. Die ORTI-basierte Timing-Analyse konzentriert sich auf das Betriebssystem und ignoriert andere AUTOSAR-Module wie Softwarekomponenten (Software Components, SWCs) und die Laufzeitumgebung (Runtime Environment, RTE). Das Scheduling der AUTOSAR-Runnables (mittels OS-Tasks) ist oft der maßgebliche Untersuchungsgegenstand der Timing-Analyse.

ARTI bietet erweiterte, für die Automobilindustrie wichtige Informationen, zum Beispiel über Tasks, ISRs (Interrupt Service Routinen), Runnables, RTE-Kommunikation oder Spinlocks in einem ARXML-Format. So ermöglicht der ARTI-Support eine tiefgreifende Analyse des Laufzeitverhaltes von AUTOSAR-basierten Systemen. ARTI definiert eine umfangreiche, standardisierte Schnittstelle zwischen den Build-Tools sowie den Debug- und Trace-Werkzeugen und liefert neben detaillierten Debug-Informationen auch ein Modell zur detaillierten Laufzeitmessung und -analyse von Betriebssystem-Tasks und deren Runnables. Dies beinhaltet nicht nur einfache Zeitmessungen, sondern auch die möglichen Zustände der Tasks, Runnables und ISRs. Weil ARTI konsequent nur diese relevanten Informationen aufzeichnet, kommt man mit einer relativ geringen Bandbreite aus.

Die für das ARTI-Profiling (oft wird das Profiling des Laufzeitverhaltens einer AUTOSAR-basierten Anwendung auch der Begriff AUTOSAR-Profiling verwendet) erzeugten Trace-Daten können zur Programmlaufzeit auf den Host-Computer gestreamt werden, wodurch sehr lange Aufzeichnungszeiten möglich sind. Mit den Trace-Daten können neben dem hier im Mittelpunkt stehenden Anwendungsfall Validierung von Timing-Anforderungen auch CPU-Lastanalyse, Event-Chain-Analyse, Berechnung von OS-Metriken und vieles mehr abgedeckt werden. Lauterbachs Trace32-Trace-Tools sind ein etablierter Bestandteil der AUTOSAR Classic Timing-Toolkette und unterstützen das ARTI-Profiling auch für die AUTOSAR Adaptive Platform. Bild 2 zeigt exemplarisch einen decodierten ARTI-Trace in Lauterbachs PowerView-Software.

Trace32 nutzt das während des Build-Prozesses erzeugte ARTI-File (arxml), um alle relevanten Debug-Informationen in geeigneter Weise darzustellen. Die aufgezeichneten Trace-Daten lassen sich außerdem als ASAM MDF (Measurement Data Format) exportieren und dann mittels Timing-Tools weiterverarbeiten. Bild 3 zeigt den Workflow.

ZF hat diese Zeitmessungen und Analysen in den Entwicklungsprozess übernommen. Die erweiterten Analysemöglichkeiten ermöglichen es dem Entwickler, Auswirkungen funktionaler Änderungen auf das Zeitverhalten in einfacher Art und Weise zu prüfen. Dieses Vorgehen ist für Automotive-Anwendungen essenziell, weil Automotive-Software typischerweise in Zeitslots strukturiert wird – beispielsweise bekommt Task Eins 5 ms, Task Zwei 3 ms – die unbedingt eingehalten werden müssen.

Neben Trace32 nutzt ZF für eine automatische Requirement-Analyse auch die TA Tool Suite von Vector [1], für die Lauterbach ein entsprechendes Exportformat seiner Trace-Daten entwickelt hat. Wenn etwa eine Task 10 ms dauern darf, liefert Trace32 die tatsächlichen Laufzeitstatistiken (zum Beispiel 11 ms), während die TA Tool Suite auf höherer Ebene einen Verstoß gegen die Requirements (11 ms > 10 ms) meldet.

Der Schritt vom realen zum virtuellen Target VLAB

Im nächsten Schritt wollte ZF die zuvor beschriebenen Abläufe in einen Continuous-Integration(CI)-Prozess integrieren, damit ständig überwacht wird, inwiefern Änderungen der Software Reaktionen im Laufzeitverhalten hervorrufen. Das Ziel bestand darin, die Tests vollständig automatisiert auf einem Server laufen lassen zu können – gegebenenfalls 24 Stunden an 365 Tagen im Jahr. Wenn der Entwickler bei ZF Code in das Repository überträgt, initiiert ein CI-Server also nicht nur einen Build und dokumentiert die Ergebnisse des Builds, sondern überprüft auch automatisch die Auswirkungen auf das Zeitverhalten.

Einen zum Projekt passenden Prüfstand mitsamt aller benötigten Debug- und Trace-Werkzeuge für einen CI-Service dauerhaft verfügbar zu machen, erwies sich als große Herausforderung. Daher bot es sich an, den realen Prüfstand durch einen virtuellen Prüfstand inklusive virtuellem Steuergerät mit virtueller Aurix-MCU zu ersetzen. Erfreulicher Nebeneffekt: Durch die Virtualisierung des Mikrocontrollers entfallen Hardwarebeschränkungen hinsichtlich Trace, da ein Modell natürlich nicht auf Hardwareimplementierungen wie MCDS angewiesen ist, um Trace-Daten zu generieren. Somit ist ein solches Set-up sogar für Projekte nutzbar, die nicht über die entsprechende Hardware verfügen.

Die Aurix Virtual Development Machine (VDM) wird von der Firma Australian Semiconductor Technology Company (ASTC) geliefert. Das VLAB Aurix Toolbox genannte Produkt von ASTC [2] bietet eine Reihe von Simulationsmodellen für die Aurix TC2xx und Aurix TC3xx MCUs, die nicht nur die TriCore-CPUs, sondern auch die Peripherie und andere programmierbare Cores umfassen und erweitertes Debugging für GTM mit Disassemblierung, Tracing und Breakpoints unterstützen. VLAB läuft auf dem CI-Server und ZF wollte auch die Zeitmessungen darauf machen. Selbst wenn die Simulation natürlich langsamer als ein reales Target ist, spielt dies keine Rolle, weil die Messungen ja nachts durchlaufen können.

Für ZF ergaben sich dabei zwei Herausforderungen. Die erste bestand darin, dass Lauterbachs Trace32 in irgend- einer Weise an VLAB angebunden werden musste (Bild 4), um schlicht und ergreifend aus der PowerView-Software [3] die Simulation debuggen zu können. Die zweite, weitaus größere Herausforderung, war, das VLAB-Modell überhaupt tracen zu können.

Die PowerView-Anbindung konnte dank intensiver Zusammenarbeit zwischen den Entwicklungsteams von Lauterbach und ASTC zeitnah realisiert werden. Als Schnittstelle wurde die MCD-API herangezogen, die ASTC bereits standardmäßig im Simulator implementiert hatte.

Die MCD-API [4] wurde im Rahmen eines Gemeinschaftsprojekts von ARM, Infineon Technologies, Lauterbach, NXP Semiconductors, STMicroelectronics und TIMA Laboratory entwickelt. Sie wurde definiert, um Debugging-Tools eine einheitliche Debugging-Schnittstelle sowohl für reale Hardware als auch für Softwaresimulationen zu bieten. Dies ermöglicht es, mit der Anwendungsentwicklung schon früh im Designfluss einer SoC-Plattform zu beginnen, ohne beim Übergang von virtuellen Prototypen zu realer Hardware zu anderen Debug-Tools wechseln zu müssen.

Darüber hinaus unterstützt die MCD-API das Multi-Core-Debugging, das aufgrund der Komplexität heutiger SoC-Designs unvermeidlich ist. Die MCD-API ist eine leistungsfähige, aber einfache C-Schnittstelle. Sie verfügt über eine Reihe von Sub-APIs, die Funktionen unter anderem für die Target-Verbindung, Abrufen von Informationen des Zielsystems, Trigger-Unterstützung zum Beispiel für Breakpoints, Speicher- und Registerzugriffe sowie Kommunikationskanäle bieten