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.
10 Elektronik automot ive Entwicklungstools 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 Tracefä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 Tracefä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 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 ORTIbasierten 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 ORTIbasierte 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 AUTOSARbasierten Systemen ARTI definiert Bild 1 Schaubild für Real-Time Flow Trace mit Lauterbach Trace32 Bild Lauterbach