Automatische Multi-Core-Echtzeitvalidierung

Anbieter zum Thema

Tracing

Mittels Tracing kann das Verhalten von eingebetteten Systemen von der Hardware aufgezeichnet werden. Wie beim Simulieren ist das Result ein Trace, also eine Serie von Ereignisse die verschiedene Vorkommnisse im System repräsentieren. Nach Ferrari [3] gibt es dafür drei prinzipielle Möglichkeiten: softwarebasiertes, hybrides und hardwarebasiertes Tracing.

Beim softwarebasierten Tracing wird ein spezieller Code zur Applikation hinzugefügt. Diese sogenannte Instrumentierung sorgt dafür, dass Ereignisse die zur Analyse des Laufzeitverhaltes von Interesse sind mit zugehörigem Zeitstempel im Speicher geloggt werden. Nach der Ausführung kann der Trace via Debugger oder serieller Schnittstelle ausgelesen werden. Dieser Ansatz verändert jedoch das Laufzeitverhalten der Applikation [4]. Darüberhinaus ist die maximal mögliche Tracedauer durch den verfügbaren Speicherplatz auf der Hardware limitiert.

Hybrides Tracing ist ebenso auf die Instrumentierung der Applikation angewiesen und verändert damit das Laufzeitverhalten. Im Gegensatz zum softwarebasierten Ansatz werden die aufgezeichneten Ereignisse direkt über eine dedizierte Schnittstelle zur weiteren Analyse versendet. Dies bedeutet, dass bei ausreichender Bandbreite die maximal mögliche Tracedauer nicht vom verfügbaren Speicherplatz limitiert wird.

Für hardwarebasiertes Tracing, auch bekannt unter dem Begriff „On-Chip-Trace“ ist keine Softwareinstrumentierung notwendig. Stattdessen wird ein eigens dafür vorgesehener Bereich auf dem Prozessor dazu verwendet die Befehlsabarbeitung und die Datentransfers der CPUs aufzuzeichnen. Diese Ereignisse können nach nutzerdefinierten Regeln gefiltert werden um dann über ein spezielles Hardware-Trace-Interface vom Chip gesendet zu werden. Wird eine entsprechende Hochleistungsschnittstelle wie das AURORA Interface verwendet sind damit Aufzeichnungen von beliebiger Länge möglich [5].

Hardwarebasiertes Tracing ist die einzige Methode die eine sinnvolle Validierung von Echtzeitanforderungen auf der Hardware erlaubt. Wie erwähnt wurde verändern Ansätze die auf Instrumentierung beruhen das Laufzeitverhalten. Somit kann es besonders bei stark ausgelasteten Applikationen passieren, dass Anforderung die normalerweise erfüllt sind, aufgrund des zusätzlichen Rechenaufwands durch die Instrumentierung nicht mehr eingehalten werden. Darüberhinaus bedeutet es einen entwicklungstechnischen Mehraufwand Instrumentierung zur Applikation hinzuzufügen und zu pflegen.

Grundsätzlich kann hardwarebasiertes Tracing drei Arten von Traces erzeugen: Instruction-, Daten- und Signaltraces [6]. Instructiontraces bestehen aus Befehlen, die von der CPU abgearbeitet wurden. Zusammen mit den Debuginformationen kann daraus der komplette Programmpfad der Applikation rekonstruiert werden. Datentraces enthalten Speicherzugriffe der CPUs, also beispielsweise Schreib- und Lesezugriffe auf Variablen der Applikation. Signaltraces beinhalten Informationen über das Verhalten von Peripherals, wie zum Beispiel des Generic Timer Moduls (GTM) der Infineon AURIX™-Prozessor-Familie.

Das folgende Listing zeigt die textuelle Repräsentation eines Datatrace-Ereignis exportiert aus dem Tool TRACE32 der Lauterbach GmbH [7].

0.0013952200,EE_th_status[0],"wr-data",00000003,0

Jedes Ereignis besteht aus fünf Feldern. Das erste entspricht dem Zeitstempel zu dem das Ereignis aufgezeichnet wurde. Die Zeiteinheit ist Sekunden. Das zweite Feld repräsentiert die Variable, die von dem Datenzugriff betroffen ist. Das dritte Feld gibt an, ob ein Lese- oder ein Schreibzugriff stattgefunden hat. In diesem Fall handelt es sich um Letzteres (“write-data”). Das vierte Feld gibt den Wert an, der in die Variable geschrieben wurde. Das letzte Feld zeigt die ID des Prozessorkerns auf dem das Ereignis stattgefunden hat.

Das folgende Listing zeigt die textuelle Repräsentation eines Instructiontrace-Ereignisses, ebenso exportiert aus TRACE32.

+1408860; R_2_1; fstart; 0

Das erste Feld entspricht wieder dem Zeitpunkt zu dem das Ereignis aufgezeichnet wurde. Diesmal ist die Zeit in Nanosekunden angegeben. Das zweite Feld gibt den Namen des Softwareobjekts, das von dem Event betroffen ist, an. Das dritte Feld gibt an welche Aktion für das Softwareobjekt ausgeführt wird, in diesem Fall startet die Funktion R_2_1. Das letzte Feld repräsentiert wieder den Prozessorkern auf dem das Ereignis stattgefunden hat.

(ID:44202462)