Unterstützte Dateiformate¶

Momentan unterstützt trace.check die folgenden Dateiformate für die Traceanalyse:

Format	Dateiendung	Version	Hersteller	Softwareprodukte (Auswahl)
ASTRACE	.astrace		tracetronic	ecu.test, trace.check, auto.spy analyzer
AS3TRACE	.as3trace		tracetronic	ecu.test, trace.check, auto.spy analyzer
ASC	.asc		Vector	CANoe, CANalyzer
AUDIO	.wav, .flac, .mp3, .ogg
BLF	.blf		Vector	CANoe, CANalyzer
CarMaker	.erg, .erg.info		IPG	CarMaker
CSV	.csv
DLT	.dlt			ecu.test, COVESA DLT Viewer
ECAL	.hdf5	5.0, 5.1	Continental
GIN	keine	3, 4	G.i.N.	Datenlogger der GL-Familie
Matlab	.mat	Level 5 MAT-File Format	MathWorks	MATLAB/Simulink
	.mat		dSpace	ControlDesk
	.mat		tracetronic	ecu.test, trace.check
MDF	.dat	2.0, 3.0, 3.1, 3.2, 3.3	ETAS	INCA, MDA
	.dat		Vehinfo	LABCAR-OPERATOR
	.dat		ITK
	.mdf		Vector	CANape, CANoe, CANalyzer
	.mdf		IPETRONIK
	.mdf		tracetronic	ecu.test, trace.check
MDF4	.mf4	4.0, 4.1, 4.2	Vector	CANape, CANoe, CANalyzer
MDF4	.mf4	4.0, 4.1, 4.2	ETAS	INCA, MDA
OSI	.osi, .osi.info .txt, .txt.info	3.5.0	ASAM	ecu.test, OSI Visualizer
PARQUET	.parquet, .pqt		Apache Parquet
PCAP	.pcap, .pcapng			ecu.test, Wireshark
ROS2	.zip	4, 5, 6, 7, 8, 9
RDB	.rdb			VTD
STI / STZ	.sti, .stz-	2.0.1	ASAM AE XIL
TDMS	.tdms		National Instruments
TTL	.ttl		TTTech	TTX-DataLogger
VIDEO	.avi, .mp4, .mkv, .mts, .wmv	Generische Unterstützung durch OpenCV

Folgend sind nähere Informationen zu den Formaten aufgeführt. Der Punkt Parametrierung des Parsers beschreibt für jedes Format die Bedeutung des Gerätebezeichners und der Formatdetails.

ASC, BLF

Unterstützte Feldbussysteme

trace.check unterstützt die Bussysteme CAN, FlexRay sowie eingeschränkt CAN FD und LIN und Ethernet (nur BLF).

Außerdem wird die Extraktion und Interpretation von Diagnose-Botschaften (aktuell nur CAN (FD)) mittels DIAG-SERVICE-Größen unterstützt. Siehe Diagnostics related objects of trace analysis für den Aufbau der Werte.

Ausgelesene Frames

Bei CAN werden die in der Formatspezifikation definierten Ereignisse CAN (Extended) Message Event und CAN Error Frame ausgelesen, alle anderen Frames werden nicht betrachtet.

Bei ASC und BLF mit FlexRay wird das sogenannte FlexRay Message Event sowohl im „alten“, als auch im „neuen“ Format (in CANoe/CANalyzer ab Version 5.2.26) unterstützt. Null-Frames werden im MessageEvent-Signal und den veralteten Frame-Signalen grundsätzlich berücksichtigt.

Analog zu CAN können CAN-FD-Nachrichten analysiert werden. Die in der Formatspezifikation definierten Ereignisse CAN FD (Extended) Message Event, CAN FD Error Frame für ASC und CAN FD Message 64 für BLF werden ausgelesen, alle anderen Frames werden nicht betrachtet.

Es können LIN-Nachrichten analysiert werden. Die in der Formatspezifikation definierten Ereignisse LIN Message Event, LIN Sleep Mode Event, LIN Wakeup Frame und LIN Unexpected Wakeup werden ausgelesen, alle anderen Frames werden nicht betrachtet. Zu beachten ist, dass für BLF veraltete LIN-Loggings von CANoe/CANalyzer bis Version 6.0 nicht unterstützt werden.

Nur BLF: Aus BLF-Traces können Ethernet-Nachrichten ausgelesen werden. Das in der Formatspezifikation definierte Ereignis Ethernet Packet wird unterstützt. Wie im PCAP-Format kann auf Größen der service-basierten Kommunikation zugegriffen werden.

Multiplexing

Das Multiplexing von Frames wird sowohl bei CAN als auch bei FlexRay unterstützt. Das heißt, dass abhängig von der Multiplex-ID (diese befindet sich an einer definierten Stelle innerhalb des FramePayloads und wird nicht als Pseudosignal bereitgestellt) andere Signale in verschiedenen Frames derselben FrameID stehen. Welche Signale solch einem Multiplexing unterliegen, findet trace.check selbstständig anhand der angegebenen Signaldatenbank heraus.

Pseudosignale

Bei den Dateiformaten ASC und BLF werden durch trace.check – neben den eigentlichen Bussignalen – auch sog. Pseudosignale zur Analyse bereitgestellt (im Reiter Tracedateien in der jeweiligen Datei unter Signale). Pseudosignale erlauben den Zugriff auf Rohdaten der Datei, ohne dass eine Signaldatenbanken geladen sein muss. Ist diese geladen, kann trace.check anhand der im Reiter BUS gelisteten Einträge konkrete Signale aus den Rohdaten extrahieren und in der Analyse bereit stellen.

Info

Die Pseudosignale sind an die Formatspezifikationen für ASC und BLF angelehnt und stellen Inhalte bereit, welche sich unmittelbar aus den Rohdaten ergeben. Es findet keine weitere Interpretation der Daten statt (d.h. keine Berechnung der Busstatistik durch trace.check).

Info

Die Ethernet Pseudosignale unter BLF unterstützen analog zu PCAP den Zugriff auf höhere Layerschichten. Für Details, siehe PCAP Pseudosignale.

Je nach auszulesenden Medium stehen unterschiedliche Pseudosignale zur Verfügung:

Signal	Beschreibung	CAN	CANFD	FlexRay	LIN	Ethernet	Datentyp
MessageEvent	Alle Arten von Frames (z.B. auch Error- und CAN-Remote-Frames).	+	+	+	+	-	CanMessageEvent, FlexRayMessageEvent, LinMessageEvent
ErrorEvent	Nur ASC. Fehlereinträge durch Bushardware	+	+	+	-	-	CanErrorEvent, FlexRayErrorEvent
BusStatisticsEvent	Nur ASC. Statistik der Frames und Buslast	+	+	-	-	-	CanBusStatisticsEvent
OverloadFrameEvent	Nur ASC. Überlastung eines Busteilnehmers	+	+	-	-	-	CanOverloadFrameEvent
StartCycleEvent	Nur ASC. Start eines FlexRay-Zyklus	-	-	+	-	-	FlexRayStartCycleEvent
StatusEvent	Nur ASC. FlexRay-Statuseintrag	-	-	+	-	-	FlexRayStatusEvent
SleepModeEvent	Initialer Zustand oder Änderung des Sleep-Mode	-	-	-	+	-	LinSleepModeEvent
WakeupFrame	Anfrage Wakeup	-	-	-	+	-	LinWakeupFrame
UnexpectedWakeup	Von CANoe/CANalyzer erkannter Fehlerzustand, wenn ein unerwartetes Byte in der Bus-Idle-Phase des aktiven Bus ein Wakeup-Frame sein könnte.	-	-	-	+	-	LinUnexpectedWakeup
J1939Message	Benötigt ecu.test diagnostics. J1939-Nachricht	+	-	-	-	-	J1939Message
J1939DTCList	Benötigt ecu.test diagnostics. Liste von J1939-Fehlerspeichereinträgen	+	-	-	-	-	J1939DTCList
UdsMessage	Benötigt ecu.test diagnostics. Unified Diagnostics Services (UDS) Nachrichten	+	+	-	-	-	UdsCanMessage

FrameID	Veraltet. Wird bei FlexRay-Error-Frame auch ausgegeben	+	+	+	+	-	Integer
FramePayload	Veraltet. Wird bei FlexRay-Error-Frame auch ausgegeben	+	+	+	+	-	String
FrameLength	Veraltet. Wird bei FlexRay-Error-Frame auch ausgegeben	+	+	+	+	-	Integer
FrameCycle	Veraltet. Wird bei FlexRay-Error-Frame auch ausgegeben	-	-	+	-	-	Integer
ErrorFrame	Veraltet. Erzeugt genau dann ein Sample mit Wert 1, wenn ein Error-Frame vorliegt.	+	+	+	-	-	Integer
ErrorFrameECC	Veraltet. Analog zu „ErrorFrame“. Wert entspricht dem ECC-Register, falls vorhanden, sonst 0.	+	+	+	-	-	Integer

PacketEthernet	Nur BLF. Jeder beliebige Ethernet-Frame in der Aufnahme	-	-	-	-	+	PacketEthernet, EthernetProtocol
PacketIp	Nur BLF. Ethernet-Frame mit dem Protokolltyp IP, keine automatische Erkennung von IP-Fragmenten	-	-	-	-	+	PacketIp4, PacketIp6, Ipv4Protocol, Ipv6Protocol
PacketIcmp	Nur BLF. IP-Paket mit dem Protokolltyp ICMP	-	-	-	-	+	PacketIcmp
PacketTcp	Nur BLF. IP-Paket mit dem Protokolltyp TCP, keine Unterstützung von TCP-Reassembling	-	-	-	-	+	PacketTcp, TcpProtocol
PacketUdp	Nur BLF. IP-Paket mit dem Protokolltyp UDP	-	-	-	-	+	PacketUdp, UdpProtocol
PacketSomeIp	Nur BLF. TCP oder UDP-Paket mit dem Quell- oder Ziel-Port 30490 wird als SOME/IP-Paket interpretiert	-	-	-	-	+	PacketSomeIp, SomeIpProtocol
PacketSomeIpSd	Nur BLF. SOME/IP-Paket mit der Message-Id 0xFFFF8100	-	-	-	-	+	PacketSomeIpId
PTP/PacketPtpSync	Nur BLF. Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Sync	-	-	-	-	+	PacketPtpSync, PtpProtocol
PTP/PacketPtpFollowUp	Nur BLF. Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Follow_Up	-	-	-	-	+	PacketPtpFollowUp, PtpProtocol
PTP/PacketPdelayReq	Nur BLF. Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Req	-	-	-	-	+	PacketPdelayReq, PtpProtocol
PTP/PacketPdelayResp	Nur BLF. Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Resp	-	-	-	-	+	PacketPdelayResp, PtpProtocol
PTP/PacketPdelayRespFollowUp	Nur BLF. Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Resp_Follow_UP	-	-	-	-	+	PacketPdelayRespFollowUp, PtpProtocol

Info

Besonderheit bei Verwendung von ErrorFrame: Standardmäßig werden für FrameID, FramePayload, FrameLength und FrameCycle nur gültige Botschaften betrachtet. Liest man jedoch auch ErrorFrame ein, werden die als Error-Frame markierten Botschaften beachtet und FrameID, FramePayload, FrameLength und FrameCycle um Samples angereichert. Innerhalb der Traceanalyse muss man ggf. selbst darauf achten, dass nur die Samples von gültige Botschaften analysiert werden (Prüfung auf ErrorFrame hinzufügen).

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails dienen als Filter, um nur bestimmte Frames aus dem Trace zu lesen.

Aufbau:

%Medium%_%Kanal%_%Richtung%[_%OptionaleParameter%] (ASC) bzw. %Medium%_%Kanal%_%Richtung%_%Port%[_%OptionaleParameter%] (BLF)

Medium

Der Bus, der gefiltert werden soll.

Mögliche Werte:

AUTO .. Das erste Frame im ASC wird ausgewertet und der entsprechende BUS als Medium gesetzt. (Falls das erste Frame vom Typ „CANFD“ ist, wird „CAN“ als Medium gesetzt, um gemischte Aufnahmen zu unterstützen.)
CAN ..
- BLF-Format: Es werden Frames sowohl von CAN als auch CAN FD gelesen.
- ASC-Format: Wird für Kanal der Wert ALL angegeben, werden Botschaften sowohl von CAN als auch CAN FD gelesen. Andernfalls wird automatisch bestimmt, ob auf dem angegebenen Kanal ein CAN oder ein CAN FD aufgezeichnet wurde. Nur passende Einträge werden gelesen.
CANFD .. Es werden nur Frames vom CAN FD gelesen (nur ASC-Format).
FlexRay .. Es werden nur Frames von FlexRay gelesen.
LIN .. Es werden nur Frames von LIN gelesen.
Ethernet .. Es werden nur Ethernet-Frames gelesen (nur BLF-Format).

Kanal

Es werden nur Frames von diesem Kanal gelesen.

Mögliche Werte:

%Zahl% .. Die Nummer des Kanals. Gültige Werte für CAN sind 1-99; für LIN 1-64.
ALL .. Liest die Frames aller Kanäle und behandelt sie als einen einzigen Trace. Sollte nur verwendet werden, wenn mit Sicherheit davon ausgegangen werden kann, dass nur ein Kanal im ASC vorhanden ist.

Richtung

Es werden nur Frames gelesen, die in eine bestimmte Richtung gesendet wurden.

Mögliche Werte:

Rx .. Es werden nur empfangene Frames gelesen.
Tx .. Es werden nur gesendete Frames gelesen.
RxTx .. Es werden empfangene und gesendete Frames gelesen.

Port

UDP Port auf dem SOME/IP Service-Discovery Kontrollflussdaten versendet werden. Zum einen wird der Event-Absender anhand der in der Service-Datenbank (Fibex) hinterlegten IP-Adresse, des Transportprotokolls und des Ports gefiltert. Dabei wird der hier angegebene Port nicht betrachtet. Zum anderen wird durch Analyse der Kontrollflussdaten (SOME/IP Service-Discovery) ermittelt, von welchem Absender ein Event gesendet wird. Dabei wird der hier angegebene Port berücksichtigt.

Optionale Parameter

Liste optionaler Parameter (die eckige Klammern stehen für „optional“ und werden nicht mit eingegeben). Parameter müssen durch _ voneinader getrennt sein.

Mögliche Parameter:

idMask=%HexadezimaleZahl% .. Maske für CAN-IDs durch welche bestimmte Bits der CAN-IDs ignoriert werden können.
j1939mode .. Falls dieses Flag gesetzt ist und idMask nicht explizit gesetzt ist, wird idMask=0x3ffffff angewandt.

Standard:

AUTO_ALL_RxTx (ASC) bzw. AUTO_ALL_RxTx_30490 (BLF)

ASTRACE

Dateiarten:

Der Parser unterstützt alle Arten von ASTRACE-Dateien, d.h.

solche, die durch eine Traceanalyse zur Anbindung des trace.xplorers erzeugt wurden
solche, die mit dem auto.spy analyzer aufgenommen wurden

Signalarten:

Der Parser unterstützt alle Arten von Signalen, die in einer ASTRACE-Datei gespeichert werden können, einschließlich Videosignale.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

AS3TRACE

Dateiarten:

Der Parser unterstützt alle Arten von AS3TRACE-Dateien, d.h.

solche, die durch eine Traceanalyse zur Anbindung des trace.xplorers erzeugt wurden
solche, die in ecu.test mit dem Tool FEP aufgezeichnet wurden
solche, die mit dem auto.spy analyzer aufgenommen wurden

Signalarten:

Der Parser unterstützt alle Arten von Signalen, die in einer AS3TRACE-Datei gespeichert werden können, einschließlich Videosignale.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

CSV

Signalarten

Folgende Signalarten werden unterstützt:

Interpretiert (Zahl)
- Signalwerte werden in Fließkommawerte konvertiert
- Eine fehlerhafte Konvertierung führt zu einem Error
Rohwert
- Signalwerte werden in Unicode konvertiert
Interpretiert (Text)
- Signalwerte werden in Unicode konvertiert

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails enthalten Informationen über den Aufbau der CSV. Der Parser benötigt diese, um die Datei korrekt einlesen zu können.

Aufbau:

Die Zeichenkette setzt sich aus einem oder mehreren Schlüsselwort-Wert-Paaren zusammen, wobei die Reihenfolge keine Rolle spielt. Ein Schlüsselwort-Wert-Paar wird folgendermaßen angegeben:

%Schlüsselwort%: '%Wert%'

Vorsicht: Der Wert steht dabei immer in einfachen Anführungszeichen, unabhängig davon, ob der Wert ein Zeichen, eine Zeichenkette oder eine Zahl darstellt. Mehrere dieser Paare werden durch ein Komma getrennt. Folgende Schlüsselwörter können angegeben werden:

columnSeparator

Das Zeichen, das die einzelnen Spalten voneinander trennt. Um den Tabulator als Trennzeichen anzugeben, verwenden sie als Wert -->.

Standardbelegung: ;

decimalSeparator

Das Zeichen, das die Vor- und Nachkommastellen einer Fließkommazahl voneinander trennt.

Standardbelegung: .

thousandSeparator

Das Zeichen für die Zifferngruppierung.

Standardbelegung: ,

headLineNumber

Die Zeilennummer, in der die Spaltenüberschriften stehen (Zählung beginnt bei 0).

Wird als Wert eine -1 angegeben, so existieren keine Überschriften. Somit ist die erste Zeile in der Datei schon eine Datenzeile.

Wird ein Wert größer 0 angegeben, werden die Zeilen 0 bis headLineNumber - 1 ignoriert.

Standardbelegung: 0

timeColumn

Die Spalte, in der die Zeitstempel der Aufnahme stehen.

Handelt es sich bei dem Wert um eine Zahl, so repräsentiert sie die Spaltennummer (Zählung beginnt bei 0).

Ist der Wert eine Zeichenkette, repräsentiert er die Überschrift der Spalte.

Standardbelegung: 0

Standard:

columnSeparator: ';', decimalSeparator: '.', thousandSeparator: ',', headLineNumber: '0', timeColumn: '0'

DLT

Allgemein

DLT (AUTOSAR-Standard „Diagnostic Log and Trace“)-Dateien (.dlt) enthalten aufgezeichnete DLT-Botschaften. Bei DLT wird zwischen verbose und non-verbose Botschaften unterschieden.

Verbose Botschaften enthalten alle notwendigen Informationen, um deren Inhalt interpretieren zu können. Sie enthalten sogenannte Argumente, welche entweder über einen Namen oder ihren Index addressiert werden. Um den Inhalt von non-verbose Botschaften zu interpretieren, ist eine externe Datenbank notwendig - ähnlich zur Buskommunikation.

Zum Lesen von DLT ist das Erstellen eines Steuergeräts in der Testkonfiguration notwendig. Insbesondere der Bereich „Logging“ muss befüllt werden. Weitergehende Beschreibungen der einzelnen Felder kann man ihren Tooltips entnehmen.

Non-verbose DLT

Zum Lesen von non-verbose DLT wird eine DLT-FIBEX-Datenbank benötigt. Deren Aufbau weicht jedoch von einer regulären FIBEX ab. Siehe auch AUTOSAR Log and Trace Protocol Specification, Release 1.5.1, Seite 27. Der Dateipfad zur Datenbank muss in der Testkonfiguration hinterlegt werden.

Ist die Konfiguration gestartet, werden zur Verfügung stehende Signale im Reiter Logging aufgeführt und können per Drag-and-Drop in den Signalaufnahmen-Reiter für die Traceanalyse verfügbar gemacht werden.

Verbose DLT

Zum Lesen von verbose DLT wird eine DLT-Filterdatei (.dlf) benötigt. Der Pfad zur Filterdatei muss in der Testkonfiguration hinterlegt werden. Derzeit ist es notwendig, diese über den DLT Viewer (GitHub) anzulegen.

Ist die Konfiguration gestartet, stehen basierend auf den Filtern in der Filterdatei, sogenannte „gefilterte Loggingbotschaften“ zur Verfügung, welche wie Signale gelesen werden können. Die gelesenen Werte sind vom Typ DltMessage.

Aktuell unterstützt ecu.test den DLT-Standard in der Version 1. Um bestmögliche Kompatibilität mit dem DLT Viewer und dessen Filtermechanismus zu gewährleisten, wird zusätzlich das Feld Type Format (TYFM) aus dem DLT-Standard Version 2 unterstützt.

Pseudosignale

Zum allgemeinen Zugriff auf DLT-Botschaften wird ein Signal namens DltMessage bereitgestellt. Analog zu verbose DLT sind für dieses Signal die Werte vom Typ DltMessage. Es ist jedoch zu beachten, dass die Botschaften ungefiltert eingelesen werden. Somit werden verbose und non-verbose Botschaften gleichzeitig eingelesen. Eine Unterscheidung der Botschaften muss in der Traceanalyse von Hand unternommen werden. Für die Unterscheidung zwischen verbose/non-verbose kann man zum Beispiel auf das Attribut .verbose prüfen.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

Zeitstempelsortierung

Für Aufzeichnungen, die keine streng monotone Zeitachse aufweisen, kann folgende Workspace-Einstellung genutzt werden: ETHERNET, DLT: Zeitstempel über gleitendes Fenster sortieren

ECAL

Allgemein

eCAL-Aufnahmen werden im HDF5-Format gespeichert und besitzen als Einträge beliebige Datenstrukturen, welche durch Protobuf serialisiert sind. ecu.test zerlegt diese teils verschachtelten Datenstrukturen in ihre Grundbestandteile und bietet sie zur Analyse an. Zum Parsen wird ein installiertes eCAL-Framework in mindestens Version 5.0 benötigt. Da sich die Verfügbarkeit der Signale zeitlich verändern kann, wird bei der ersten Verwendung die Aufnahme vollständig geparst und alle vorkommenden Signale extrahiert. Je nach Aufnahmegröße kann dieser Prozess einige Zeit in Anspruch nehmen. Die so gewonnenen Metadaten werden anschließend in eine daneben liegende, gleichnamige .info-Datei geschrieben, welche bei nachfolgenden Analysen ausgelesen wird.

Signalarten

Folgende Signalarten werden unterstützt:

Interpretiert (Zahl)
- Es werden alle gängigen, primitiven Datentypen von Protobuf unterstützt. Dazu zählen Integer, Floating-Point und Long.
- Zusätzlich können auch Boolean-Werte nativ verwendet werden.
Interpretiert (String)
- Signale können entsprechend ihrer Protobuf-Definition als Unicode oder Bytestring ausgelesen werden.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

ERG

Für die Traceanalyse werden zwei Dateien benötigt. Die *.ERG Datei enthält die Aufnahmedaten, die *.erg.info enthält die Signalbeschreibungen. Beide Dateien müssen den gleichen Namensanfang haben. Die Aufzeichnung muss das Signal (Quantity) „Time“ beinhalten.

Signalarten

Folgende Signalarten werden unterstützt:

Rohwert

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

GIN

Allgemein

trace.check unterstützt das unmittelbar erzeugte Rohdatenformat der G.i.N. Datenlogger. Der Hauptordner mit den Datenordnern (z.B. !D1FX) der einzelnen Ringpuffer und zusätzlichen Ethernet-Loggern (parametriert als „Logger“) wird als einzelne GIN-Aufnahme angeboten. Der Hauptordner muss die Konfigurationsdateien ml_rt.ini und ml_rt2.ini beinhalten, um als einzelne GIN-Aufnahme erkannt zu werden.

Es werden sowohl die Rohdaten klassischer Busse als auch .gjf-Dateien mit Ethernet-Datenverkehr unterstützt.

Vorsicht

.clf-Dateien werden aus den Rohdateien mit dem Logger RAW File Decoder erzeugt, werden aber nicht unterstützt!

Unterstützte Feldbussysteme

trace.check unterstützt die Bussysteme CAN (FD), LIN, FlexRay und Ethernet. Analog zu anderen Formaten, wie PCAP wird die Extraktion diverser Protokolle unterstützt.

Vorsicht

Je nachdem wie die Diagnose-Datenbank aufgebaut ist, kann es passieren, dass das Signal zusätzliche Samples mit Botschaften, die eigentlich nicht zu dem ausgewählten Dienst gehören, enthält. In solchen Fällen wird eine zusätzliche Filterung in der Traceanalyse anhand der Rohdaten empfohlen.

Pseudosignale

Über sogenannte Pseudosignale wird der Zugriff auf Rohdaten auf Protokollebene realisiert. So ist es möglich auf Bus-Botschaften zuzugreifen, ohne dass eine Busdatenbank benötigt wird.

Signal	Beschreibung	CAN (FD)	FlexRay	LIN	Datentyp
MessageEvent	Alle Arten von Frames (z.B. auch Error- und CAN-Remote-Frames).	+	+	+	CanMessageEvent, FlexRayMessageEvent, LinMessageEvent
UdsMessage	Benötigt ecu.test diagnostics. Unified Diagnostics Services (UDS) Nachrichten	+	-	-	UdsCanMessage
FrameID	Veraltet. Wird bei Error-Frame auch ausgegeben	+	+	+	Integer
FramePayload	Veraltet. Wird bei Error-Frame auch ausgegeben	+	+	+	String
FrameLength	Veraltet. Wird bei Error-Frame auch ausgegeben	+	+	+	Integer
FrameCycle	Veraltet. Wird bei Error-Frame auch ausgegeben	-	+	-	Integer
ErrorFrame	Veraltet. Erzeugt genau dann ein Sample mit Wert 1, wenn ein Error-Frame vorliegt.	+	+	-	Integer
PacketEthernet					PacketEthernet
weitere Ethernet-Pseudosignale siehe PCAP Pseudosignale

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails dienen als Filter, um nur bestimmte Frames aus dem Trace zu lesen.

Aufbau:

%Medium%_%Logger%:%Kanal%_%Richtung%

Medium

Der Bus, der gefiltert werden soll.

Mögliche Werte:

CAN .. Es werden Frames sowohl von CAN als auch CAN FD gelesen.
LIN .. Es werden nur Frames von LIN gelesen.
FlexRay .. Es werden nur Frames von FlexRay gelesen.
Ethernet .. Es werden nur Ethernet-Frames gelesen.

Logger

Der Logger, von welchem die Daten gelesen werden sollen. Dieser wird anhand des Index m in den Datei- und Verzeichnisnamen dargestellt, z.B. ‚!D*m*FX‘.

Mögliche Werte:

%String% .. Der Logger 0 (Fahrtenschreiber), 1, 2, 3, E1, E2 oder E3

Kanal

Es werden nur Frames von diesem logischen Kanal gelesen. Der logische Kanal wird dann zum internen konvertiert unter Berücksichtigung der Konfiguration in ml_rt2.ini (z.B. CAN-Mapping).

Mögliche Werte:

%String% .. Die Nummer des Kanals. 1A, 1B, 2A oder 2B für FlexRay .

Richtung

Es werden nur Frames gelesen, die in eine bestimmte Richtung gesendet wurden.

Mögliche Werte:

Rx .. Es werden nur empfangene Frames gelesen.
Tx .. Es werden nur gesendete Frames gelesen.
RxTx .. Es werden empfangene und gesendete Frames gelesen.

Standard:

CAN_1:1_RxTx

MDF (Version 2.x, 3.x)

Ausgelesene Blöcke

Beim MDF-Format werden die in der Formatspezifikation definierten Blöcke IDBLOCK, HDBLOCK, TXBLOCK, DGBLOCK, CGBLOCK, CNBLOCK, CCBLOCK, CDBLOCK und CEBLOCK durch trace.check ausgelesen.

Interpretierte Werte

Der CCBLOCK (Channel Conversion Block) spezifiziert verschiedene Umrechnungsformeln zur Umwandlung von ausgelesenen Rohwerten in physikalische Werte. Momentan werden folgende Umrechnungsformeln der Formatspezifikation unterstützt:

Parametrisch, linear
Tabellarisch mit Interpolation
Tabellarisch
Polynomfunktion mit 6 Parametern
Exponentialfunktion
Logarithmusfunktion
Rationale Umrechnungsformel
Textuelle Umrechnungsformel (wie ASAM MCD-2 MC V1.6.0 Textformel)
Tabellarisch (Textuell)
Tabellarisch (Range)
1:1-Konvertierung

Nicht unterstützte Signaltypen

Signale vom Typ Curve und Map werden für von INCA-MDF-Dateien (Dateiendung .dat) nicht unterstützt.

Besonderheiten bei Kalibriergrößen in INCA-Aufnahmen

Beim Aufzeichnen von MDF3-Dateien mit INCA, werden Mess- und Kalibriergrößen standardmäßig unter dem gleichen Gerät gespeichert. Während Messgrößen in einem bestimmten Raster abgetastet werden, werden Kalibriergrößen eventbasiert aufgezeichnet: Nur wenn sich der Wert der Kalibriergröße ändert (bzw. zusätzlich zu Aufnahmebeginn und Aufnahmeende), wird ein Datenpunkt in die Aufnahmedatei geschrieben.

Wurde jedoch mit der Option „Kalibriergrößen als Messgrößen aufzeichnen“ aufgezeichnet, werden die Kalibriergrößen analog zu Messgrößen in einem bestimmten Raster abgetastet. Die als Messgrößen aufgezeichneten Kalibriergrößen befinden sich in der Aufnahme jedoch nicht mehr unter dem gleichen Gerät wie die Messgrößen: Werden die Messgrößen bspw. unter dem Gerät „CCP:1“ abgelegt, dann werden die als Messgrößen aufgezeichneten Kalibriergrößen unter dem Gerät „CCP:1#MeasureCal“ abgelegt. Eine Aufnahme kann sogar ein und dieselbe Kalibriergröße unter beiden Geräten enthalten (einmal eventbasiert und einmal abgetastet aufgezeichnet).

Trotz der unterschiedlichen Geräte ist beim Hinzufügen von INCA-MDF3-Aufnahmen in Packages nur eine Signal- bzw. Aufnahmegruppe notwendig. Es sollte nie das MeasureCal-Gerät verwendet werden, da trace.check unabhängig von der Angabe des Gerätes immer auf die Kalibriergrößen unter dem MeasureCal-Gerät zugreift, bei Angabe dieses Gerätes jedoch Messgrößen nicht mehr aufgelöst werden können.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Pflicht. Dient zur Auswahl eines in der Datei enthaltenen Gerätes. Signale werden entsprechend gefiltert bereitgestellt. Möchte man ein weiteres Gerät auslesen, muss die Aufnahme unter Angabe des anderen Geräts in einer zweiten Aufnahmegruppe eingefügt werden.

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nur für Multiprozessor-Aufnahmen von ControlDesk bei Angabe des speziellen Gerätebezeichners „multiprocessor“: Zuordnung der Gerätebezeichner innerhalb der Datei zu den Gerätebezeichnern in der Testkonfiguration.
Aufbau:: Plattform-Gerät-Paare der Form %Plattform1%=%Gerät1%##%Plattform2%=%Gerät2%...
Beispiel:: Platform=Master##Platform_2=Slave

MDF4

Grundlegende Features

MDF-Spezifikation: 4.2.0
Grundsätzlich unterstützt werden Signale aus den Reitern „Tracedateien“, „Buszugriff“, „Messung“, „Kalibrierung“, „Modell“ oder „Service“
Auslesen von Signalnamen und Signalquellennamen aus der Datei (nicht unterstützte Signale (siehe unten) werden von trace.check nicht angezeigt)
Auslesen von Signalwerten als Rohwerte oder als interpretierte Werte (siehe unten)
Lesen von komprimierten Signalwerten
Lesen von sortierten und unsortierten Dateien möglich
Lesen von Daten aus Buslogging-Traces und die Extraktion von Signalwerten anhand einer Busdatenbank
Invalidation-Bits: Signalwerte werden bei gesetztem Bit übersprungen
„Event“-Blöcke werden zur Bildung von Pseudosignalen verwendet (siehe unten)

Teilweise unterstützt

Neue Features von MDF 4.2.0 werden noch nicht vollständig unterstützt. Ausstehende relevante Features:
- Datentyp „complex number“
- Erweiterung von Event-Blöcken um „event signals“
- Konvertierungsvorschrift „bitfield text table“
Arrays (nach MDF4-Spezifikation „CN template“):
- Einfache Arrays ohne Achsen:
  - 1D -> wird als Vector gelesen
  - 2D -> wird als Matrix gelesen
- Arrays mit Achsen:
  - 1D mit einfacher 1D-Achse -> wird als Curve gelesen
  - 2D mit zwei einfache 1D-Achsen -> wird als Map gelesen
- Nicht unterstützt:
  - Arrays mit mehr als 2 Dimensionen
  - Arrays mit „komplexen Achsen“ (Achsen mit Achsen) -> führt zu Laufzeitfehler
  - Maps/Curves mit sich ändernden Achsen, aber fehlendem Zeitstempel -> führt zu Laufzeitfehler
„Nested Compositions“-Signale (Verschachtelung von Kompositionen - Structures/Arrays)
- Blattelemente lassen sich regulär einlesen.
- Es ist möglich den obersten Strukturknoten einzulesen. Dabei wird ein strukturiertes Signal eingelesen. Auf Unterelemente kann innerhalb der Traceanalyse mithilfe von Attributen zugegriffen werden. Zum Beispiel in einem Berechnungsschritt: MyStructuredSignal.subSignal > 5

Nicht unterstützt

Signale ohne Zeitachse
Arrays nach MDF4-Spezifikation „CG-Template“ sowie „DG-Template“
Signale aus Attachments (MDF4-Spezifikation: „synchronization channel“)
Signale der Datentypen „MIME sample/stream“

Nicht verwendete Dateiinhalte

trace.check ignoriert folgende MDF-Datei-Inhalte:

Meta-Daten des Header-Block
„Channel Hierarchy“-Block
„Attachment“-Block
„Sample Reduction“-Block und „Reduction Data“-Block
„Input/output/comparison channels“ von CA-Blöcken

Pseudosignale

Für MDF4-Dateien stehen aktuellen zwei unterschiedliche Arten von Pseudosignalen bereit.

Diese erste Art von Pseudosignal ordnet sich direkt auf Dateiebene ein und leitet seine Werte von sog. Event-Blöcken der MDF4-Datei ab:

Pseudosignal Events.isRecording
- Aus „Event“-Blöcken zur Aufnahmesteuerung (Aufnahme starten/pausieren) wird ein Pseudosignal „isRecording“ gebildet, das den Wert 1 hat, wenn die Aufnahme aktiv ist und den Wert 0 hat, wenn die Aufnahme pausiert. Prüfungen in der Traceanalyse können somit mithilfe eines Triggerblockes auf Bereiche, in denen die Aufnahme aktiv war, eingeschränkt werden.
- Selbst wenn keine „Event“-Blöcke zur Aufnahmesteuerung vorhanden sind, wird versucht, das Signal „isRecording“ mit Wert 1 zum ersten Zeitstempel anhand von Metadaten zu bilden.
- Die meisten Tools erzeugen bei der Verwendung des „Start/Stop Trace“-Testschrittes mehrere Aufnahmedateien. Eine Traceanalyse wird einmal je erzeugter Aufnahmedatei ausgeführt. Einen Sonderfall stellt die Aufzeichnung mit INCA dar. Wird im Format MDF3 aufgezeichnet, entstehen mehrere Aufnahmen innerhalb einer Datei. Es werden somit mehrere Traceanalysen ausgeführt. Mit MDF4 ändert sich dies. Es gibt nur noch eine Aufnahme mit Aufnahmepausen.
  
  Info
  
  Um Aufnahmepausen von INCA zu filtern, ist es ratsam das Signal „isRecording“ zu verwenden.
Pseudosignal Events.Marker
- Je Zeitpunkt ein Objekt, welches entweder einen Punkt, den Start eines Bereichs oder das Ende eines Bereichs markiert. Zur Unterscheidung stehen die Eigenschaften isPoint, isRangeStart, isRangeStop zur Verfügung.
- Genauere Informationen erhält man über die Attribute name und comment. Falls ein Marker über XIL-API gesetzt wurde, kann das Attribut xilId verwendet werden.
- Es ist möglich einzelne Attribute direkt als Signal zu addressieren, z.B. „Marker.name“.

Die zweite Art sind die Pseudosignale für Bus-Logging, welche Zugriff auf Botschaften bestimmter Protokollebenen erlauben. Für Ethernet werden Pseudosignale angeboten, die den Zugriff auf übergeordnete Protokollschichten, z.B. PacketSomeIp.udp.srcPort erlauben. Weitere Details zu den einzelnen Signalen und Protokollschichten können dem Abschnitt des PCAP-Formats entnommen werden. Für CAN stehen die Pseudosignale J1939Message und J1939DTCList für das Diagnoseprotokoll J1939 zur Verfügung.

Info

Für J1939 ist die Lizenzoption ecu.test diagnostics erforderlich!

Bus-Logging

Der MDF4-Standard erlaubt es, dass auch uninterpretierte Botschaften der Buskommunikation gespeichert werden können. trace.check ist in der Lage sowohl diese Botschaften zu lesen als auch Signalwerte anhand einer Busdatenbank zu extrahieren.

Unterstützt: CAN(-FD), FlexRay, LIN, Ethernet
Der MDF-Standard sieht drei Varianten für die Ablage von Buslogging-Daten vor: <NONE> ungefiltert, <BUS> strukturiert nach Bus-Channel sowie <ID> ID-basiert (nach Botschaft). Unterstützt werden die Modi <BUS> und <NONE>, wobei im Modus <NONE> die Gerätezuordnung um konkrete Busse mit Kanal-Nummer wie z.B. „CAN2“ (statt „CAN“) angereichert werden muss.
Für Ethernet-Busloggings, die - entgegen dem Standard - keine streng monotone Zeitachse aufweisen, kann folgende Workspace-Einstellung genutzt werden: ETHERNET: Zeitstempel über gleitendes Fenster sortieren
Im Ethernet-Bus-Logging werden die folgenden Protokolle unterstützt:
- SOME/IP
- DLT Verbose und Non-Verbose (Angabe des Gerätebezeichners in den Formatdetails zwingend notwendig)
- SocketAdaptor Frames mit MACsec

Besonderheiten bei Kalibriergrößen in INCA-Aufnahmen

Beim Aufzeichnen von MDF4-Dateien mit INCA, werden Kalibriergrößen standardmäßig unter dem Gerät „EtasCalibrationRecordingDevice“ abgelegt (Messgrößen dagegen unter dem vom Nutzer gewählten Gerät). Während Messgrößen in einem bestimmten Raster abgetastet werden, werden Kalibriergrößen eventbasiert aufgezeichnet: Nur wenn sich der Wert der Kalibriergröße ändert (bzw. zusätzlich zu Aufnahmebeginn und Aufnahmeende), wird ein Datenpunkt in die Aufnahmedatei geschrieben.

Wurde jedoch mit der Option „Kalibriergrößen als Messgrößen aufzeichnen“ aufgezeichnet, werden die Kalibriergrößen analog zu Messgrößen in einem bestimmten Raster abgetastet. Die als Messgrößen aufgezeichneten Kalibriergrößen befinden sich in der Aufnahme jedoch nicht mehr unter dem Gerät „EtasCalibrationRecordingDevice“: Werden die Messgrößen bspw. unter dem Gerät „CCP:1“ abgelegt, dann werden die als Messgrößen aufgezeichneten Kalibriergrößen unter dem Gerät „CCP:1#MeasureCal“ abgelegt. Eine Aufnahme kann sogar ein und dieselbe Kalibriergröße unter beiden Geräten enthalten (einmal eventbasiert und einmal abgetastet aufgezeichnet).

Trotz der unterschiedlichen Geräte ist beim Hinzufügen von INCA-MDF4-Aufnahmen in Packages in der Regel nur eine Signal- bzw. Aufnahmegruppe notwendig. Für diese sollte in den FormatDetails auf das Gerät der Messgrößen verwiesen werden, da trace.check Kalibriergrößen dann bevorzugt unter dem MeasureCal-Gerät sucht, wenn sie dort nicht vorkommen auch unter dem „EtasCalibrationRecordingDevice“.

Mit der Angabe des Gerätes „EtasCalibrationRecordingDevice“ in den FormatDetails kann jedoch auch explizit auf die eventbasierte Aufzeichnung einer Kalibriergröße zugegriffen werden, selbst wenn sich zusätzlich eine abgetastete Aufzeichnung der Kalibriergröße in der Datei befindet. In diesem Fall muss jedoch beachtet werden, dass sich Messgrößen und Kalibriergrößen dann in separaten Signal- bzw. Aufnahmegruppen befinden müssen.

Besonderheiten bei Busgrößen aus ControlDesk-Aufnahmen

Über den Bus-Port kann man mit Hilfe von ecu.test auch Busgrößen aufzeichnen, die im Modell abgebildet sind. Zur Auflösung des korrekten Modellpfads sind einige Parameter des Bus-Ports notwendig.

Um später aus der erzeugten Aufnahme Busgrößen lesen zu können, erzeugt ecu.test eine sog. Sidecar-Datei (.recsf). Diese enthält die aufgelöste Zuordnung von Buspfad zu Modellpfad des Signals. Ist diese Datei nicht vorhanden, ist es somit auch nicht möglich, eine Busgröße aus der Aufnahme zu lesen.

Busgrößen über AUTOSAR Socket Adaptor

Siehe PCAP Socket Adaptor

Info

Bei mehreren Systembezeichnern ist es notwendig, jeweils eine eigene Aufnahmegruppe anzulegen.

Info

Aktuell gibt es folgende Einschränkungen:

Es werden nur über IPv6 per UDP versendete Botschaften unterstützt.
IP Fragmentierung wird nicht unterstützt.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Optional. Dient zur expliziten Auswahl eines in der Datei enthaltenen Gerätes. Signale werden entsprechend gefiltert bereitgestellt. I.d.R. reicht die Angabe der Formatdetails, so dass die Gerätebezeichner in der Datei zu denen der Testkonfiguration korrekt zugeordnet werden können.

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Zuordnung der Gerätebezeichner innerhalb der Datei (so wie das Tool diese nennt) zu den Gerätebezeichnern in der Testkonfiguration (so wie trace.check diese nennt).
Aufbau:: Gerät-Gerät-Paare der Form %Gerät1 in Datei%=%Gerät1%##%Gerät2 in Datei%=%Gerät2%...
Beispiel:: CAN-Monitoring:1=A-CAN##XCP:1=DME1_DDE1
Beispiel:: Platform=Master##Platform_2=Slave

MAT

Aufbau

Dateien erzeugt durch MATLAB/Simulink, ecu.test bzw. trace.check weisen folgende Struktur auf:

MAT-File Format 5
Struct.Header.time = [0]
Struct.Header.signal = [1]
Struct.Data = [timeDataVector; signalDataVector]

Der Aufbau von MAT-Dateien aus ControlDesk / ControlDesk ist der entsprechenden Hilfe zu entnehmen.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Optional, nur bei MAT-Dateien von ControlDesk. Dient zur Auswahl eines in der Datei enthaltenen Gerätes. Signale werden entsprechend gefiltert bereitgestellt. Möchte man ein weiteres Gerät auslesen, muss die Aufnahme unter Angabe des anderen Geräts in einer zweiten Aufnahmegruppe eingefügt werden.

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nur für Multiprozessor-Aufnahmen von ControlDesk bei Angabe des speziellen Gerätebezeichners „multiprocessor“: Zuordnung der Gerätebezeichner innerhalb der Datei zu den Gerätebezeichnern in der Testkonfiguration.
Aufbau:: Plattform-Gerät-Paare der Form %Plattform1%=%Gerät1%##%Plattform2%=%Gerät2%...
Beispiel:: Platform=Master##Platform_2=Slave

OSI

Für die Traceanalyse werden zwei Dateien benötigt. Die *.osi bzw. *.txt Datei enthält die Aufnahmedaten, die *.osi.info bzw. *.txt.info Datei enthält zugehörige Metadaten um den Typ der OSI-Aufnahme zu bestimmen. Beide Dateien müssen den gleichen Namensanfang haben.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

PARQUET

Allgemein

Apache Parquet ist ein quelloffenes, spaltenorientiertes Dateiformat, welches vor allem im Bereich Big Data verwendet wird. Standardmäßig werden die enthaltenen Spalten als Signale angeboten.

trace.check bietet einige Optionen, mithilfe derer sich auch komplexere Usecases auf Basis des Parquet-Formats realisieren lassen.

Partitionierte Parquets, bei denen konstante Spaltenwerte in einer Ordnerstruktur modeliert sind, werden nicht unterstützt.

Zeitachse

Die für die Zeitachse zu verwendende Spalte kann konfiguriert werden. Zusätzlich ist es möglich die Einheit anzugeben, in der die Zeitstempel vorliegen. Beim Einlesen werden Zeitstempel automatisch in Sekunden umgerechnet, damit die Zeitachse kompatibel mit Signalverläufen anderer Formate ist. Zusätzlich lassen sich Zeitstempel optional normalisieren. Dabei werden relative Zeitstempel, beginnend mit 0.0, gebildet.

Gesplittete Parquet-Dateien

Gesplittete Parquet-Dateien, die entlang der Zeitachse in einzelne Part-Dateien getrennt sind, werden unterstützt. Dabei reicht das Hinzufügen eines Parts zu den Signalaufnahmen. Alle restlichen Parquet-Dateien in demselben Ordner, die gemäß dem nachfolgenden Namensschema benannt sind, werden zu einem Datensatz zusammengesetzt: part-<number>-<basename>.<file extention> Es wird erwartet, dass number bei Null beginnt und über alle Dateinamen die gleiche Anzahl an Ziffern besitzt.

Beispiel:

part-000-myfile.parquet
part-001-myfile.parquet

Eventlog-Modus

Regulär ist eine Parquet-Datei tabellarisch aufgebaut. Jede Spalte steht für ein Signal, jede Zeile für einen Zeitpunkt. Davon abweichend geht der Eventlog-Modus davon aus, dass sich alle Signale eine einzige Wertespalte teilen. Durch ein oder mehrere Schlüsselspalten wird zu jedem Zeitpunkt der Signalbezeichner bestimmt, der zu dem aktuellen Wert in der Wertespalte gehört. Die in trace.check angebotenen Signale werden anhand der Schlüsselspalten gebildet, indem die Spaltenwerte mit einem / verknüpft werden.

Bei gesplitteten Parquet-Dateien wird nur die als Stellvertreter verwendete Datei zur Ermittlung der verfügbaren Signale berücksichtigt.

Folgendes Beispiel zeigt mit "keyColumns":["ecu", "name"] und "valueColumn":"value" die Signale ECU1/Sig1 (Werte 42, 45) und ECU2/Sig1 (Wert -13):

Rohdaten aus Parquet-Datei¶
time	ecu	name	value
0.0	ECU1	Sig1	42
1.0	ECU2	Sig1	-13
2.0	ECU1	Sig1	45

Interpretiert via Eventlog-Modus¶
time	ECU1/Sig1	ECU2/Sig1
0.0	42
1.0		-13
2.0	45

JSON-Strukturen

Parquet unterstützt regulär keine komplexen Datentypen. Es ist jedoch möglich, strukturierte Signalwerte als JSON zu hinterlegen. Wählt man ein Signal dafür aus, es als Struktur einzulesen, wird statt einem einfachen Signal ein strukturiertes Signal eingelesen.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails beeinflussen, wie Inhalte der Datei verarbeitet werden.

Aufbau:

JSON-String mit einem Dictionary folgenden Aufbaus:

timeColumn:: [str] Name der Zeitspalte. Falls nicht gesetzt, automatisch bestimmt.
timeUnit:: [str] Einheit der Zeitachse: ns, µs, ms, s. Default: s.
normalizeTime:: [bool] Zeitachse normalisieren: true | false. Default: false.
mode:: [str] simple | eventlog. Default: simple.
keyColumns:: [list[str], nur falls "mode":"eventlog"] Liste von Schlüsselspalten
valueColumn:: [str, nur falls "mode":"eventlog"] Wertespalte

Beispiel:

{"timeColumn":"time", "timeUnit":"ns", "mode":"eventlog", "keyColumns":["ecu", "name"], "valueColumn":"value"}

PCAP

Allgemein: PCAP ist ein Format für Netzwerkdatenaufzeichnungen.

Pseudosignale

Für die Analyse dieses Datenformats werden sog. Pseudosignale bereitgestellt. Mit ihnen ist man in der Lage den entsprechenden Einstiegspunkt in den hierarchisch aufgebauten Netzwerkschichten festzulegen. Jedes dieser Pseudosignale wird beim Auftreten als Python-Datenstrukturen (siehe Ethernet API Dokumentation) zurückgeliefert. Zu beachten ist, dass als Signalart stets Rohwert anzugeben ist, da eine nähere Interpretation des Signals nicht möglich ist.

Die oben genannten Python-Datenstrukturen bieten zusätzlich die Möglichkeit, über .parent das direkt darüberliegende Protokoll oder mit FindParent(protocolName) ein spezifisches Protokoll zurückzugeben. Außerdem ist auch der direkte Attributszugriff möglich, z.B. PacketSomeIp.ip4.src. Im Gegensatz zu den „nativen“ Datentypen enthalten die Protocol-Typen aus Performancegründen nur Headerfields des jeweiligen Protokolls und keine Payloaddaten. Die vollständige API Dokumentation ist hier verfügbar: Ethernet.

Nachfolgend sind alle Pseudosignale und deren Beschreibung aufgeführt:

Signal	Beschreibung	Datentyp	Äquivalenter Protocol Typ
PacketEthernet	Jeder beliebige Ethernet-Frame in der Aufnahme	PacketEthernet	EthernetProtocol
PacketMka	Ethernet-Frame mit dem Protokolltyp MKA	PacketMka	Nicht unterstützt
PacketIp	Ethernet-Frame mit dem Protokolltyp IP	PacketIp4, PacketIp6	Ipv4Protocol Ipv6Protocol
PacketIcmp	IP-Paket mit dem Protokolltyp ICMP	PacketIcmp	Nicht unterstützt
PacketTcp	IP-Paket mit dem Protokolltyp TCP, keine Unterstützung von TCP-Reassembling	PacketTcp	TcpProtocol
PacketUdp	IP-Paket mit dem Protokolltyp UDP	PacketUdp	UdpProtocol
PacketIke	UDP-Paket mit dem Protokolltyp IKEv2. Per Default werden UDP-Pakete mit dem Quell- und Zielport 500 als IKEv2-Pakete interpretiert.	PacketIke	Nicht unterstützt
PacketSomeIp	TCP- oder UDP-Paket mit dem Protokolltyp SOME/IP. Per Default werden TCP- oder UDP-Pakete mit dem Quell- oder Ziel-Port 30490 als SOME/IP-Paket interpretiert.	PacketSomeIp	SomeIpProtocol
PacketSomeIpSd	SOME/IP-Paket mit der Message-Id 0xFFFF8100	PacketSomeIpSd	Nicht unterstützt
PTP	Ethernet-Frame mit dem Protokolltyp PTP	Nicht unterstützt	PtpProtocol
PTP/PacketPtpSync	Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Sync	PacketPtpSync	Nicht unterstützt
PTP/PacketPtpFollowUp	Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Follow_Up	PacketPtpFollowUp	Nicht unterstützt
PTP/PacketPdelayReq	Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Req	PacketPdelayReq	Nicht unterstützt
PTP/PacketPdelayResp	Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Resp	PacketPdelayResp	Nicht unterstützt
PTP/PacketPdelayRespFollowUp	Ethernet-Frame mit dem Protokolltyp PTP und dem PTP-Nachrichtentyp Pdelay_Resp_Follow_UP	PacketPdelayRespFollowUp	Nicht unterstützt

Info

Im Fall von IP-Fragmentierung wird ein PacketTcp bzw. PacketUdp zum Zeitpunkt des letzten Fragments erzeugt. Die einzelnen Fragmente stehen weiterhin per PacketEthernet und PacketIp zur Verfügung.

Service-basierte Kommunikation: Neben der Unterstützung zur Protokollanalyse können aus PCAP- und PCAPNG-Aufnahmen auch sogenannte Events und Methoden gelesen werden. Für die Analyse zur Verfügung stehen dabei Größen aus dem Reiter Service. Verwendet werden können die Event- bzw. Methoden-Signale sowie deren Blattknoten.

Logging-Signale

Des Weiteren können Logging-Botschaften des Protokolls „Diagnostic Log and Trace“ (DLT) eingelesen werden. Die Funktionsweise ist analog zum DLT-Format. Damit die ECU korrekt identifiziert werden kann, ist es jedoch zusätzlich notwendig IP und Port in der Testkonfiguration anzugeben.

Derzeit wird nur das Auslesen von Logging-Botschaften in UDP-Paketen unterstützt.

PLP (Probe Logger Protocol) / TECMP: Unterstützt werden auch Aufzeichnungen im PLP/TECMP-Format, die Nachrichten vom Typ „Ethernet“ enthalten. Die im PLP/TECMP enthaltenen Ethernet-Frames werden transparent entpackt und weiterverarbeitet. Die Filterung nach ProbeID/DeviceID und BusSpecID/InterfaceID ist nicht möglich. Andere Nachrichttypen als „Ethernet“ werden nicht unterstützt. Anstelle der äußeren PCAP-Zeitstempel werden die präziseren inneren Zeitstempel der PLP/TECMP Data Frames für die Zeitachsen der generischen Signale verwendet.
DTLS (Datagram Transport Layer Security): Es können mit DTLS 1.2 verschlüsselte SOME-IP Botschaften als PacketSomeIp eingelesen werden. Dafür ist es notwendig, dass eine Key-Log-Datei mit Dateiendung „.keys“ neben der gleichnamigen PCAP/PCAPNG-Datei liegt. Die Key-Log-Datei muss für jede zu entschlüsselnde Session einen passenden CLIENT_RANDOM-Eintrag enthalten. Key-Log-Dateien können mithilfe von Wireshark erzeugt werden.

Info

Bei der Verwendung einer NULL-Encryption ist die Key-Log-Datei optional. In diesem Fall werden die SOME-IP Botschaften ebenfalls eingelesen, können jedoch nicht auf Authentizität geprüft werden.

Busgrößen über AUTOSAR Socket Adaptor

Es ist möglich CAN-Botschaften einzulesen, die über das Socket Adaptor Modul versendet werden. Dafür ist es nötig, in der Testkonfiguration im Buszugriff-Reiter einen Datenbank mit einem SOCKET-ADAPTOR Kanal zu hinterlegen. Anschließend können die benötigten Bussignale aus dem Reiter Buszugriff im Aktionsfenster benutzt werden.

Es wird das Auslesen von CAN-Botschaften sowohl aus UDP als auch TCP unterstützt.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails dienen als Filter für Event-Signale und SOME/IP-Pseudosignale. Für die restlichen Pseudosignale sind diese Einstellungen nicht von Bedeutung.

Aufbau:

%Port%

Port: UDP Port auf dem SOME/IP Service-Discovery Kontrollflussdaten versendet werden. Zum einen wird der Event-Absender anhand der in der Service-Datenbank (Fibex) hinterlegten IP-Adresse, des Transportprotokolls und des Ports gefiltert. Dabei wird der hier angegebene Port nicht betrachtet. Zum anderen wird durch Analyse der Kontrollflussdaten (SOME/IP Service-Discovery) ermittelt, von welchem Absender ein Event gesendet wird. Dabei wird der hier angegebene Port berücksichtigt.

Standard:

30490

Filter

Zweck:

Anhand des Filters werden Einträge der Datei verworfen, falls sie nicht die Filterbedingung erfüllen.

Der Filter setzt sich aus einer Und-Verknüpfung von Vergleichen zusammen, welche sich auf Eigenschaften unterschiedlicher Busbotschaften oder Pakete im Ethernet-Protokoll-Stack beziehen können. Der Filter arbeitet somit ähnlich zur Filterung mit Wireshark, verwendet jedoch den Namensraum von trace.check.

Beispiel: PacketTcp.tcpSrc == 1234

Angenommen es sind nur Einträge zugelassen, die ein PacketTcp mit Port 1234 enthalten. Da die Filterung die komplette Botschaft der Aufnahme betrifft, wird auch ein, tiefer im Stack liegendes, PacketEthernet heraus gefiltert.

Zeitstempelsortierung

Für Aufzeichnungen, die keine streng monotone Zeitachse aufweisen, kann folgende Workspace-Einstellung genutzt werden: ETHERNET: Zeitstempel über gleitendes Fenster sortieren

ROS2

Allgemein

Info

Unterstützt werden rosbag2-Aufzeichnungen in Version 4 bis einschließlich 9. Rosbag2-Aufzeichnungen unterstützen unterschiedliche Serialisierungsverfahren. Diese Anbindung unterstützt derzeit nur Aufzeichnungen im Format CDR (Common Data Representation) in Version 1 in Little Endian ohne Kompression Es werden nur die Storage Plugins sqlite3 und mcap unterstützt.

sqlite3

Rosbag2-Aufzeichnungen im Format „sqlite3“ liegen in einem Ordner mit einer oder mehreren SQLite-Dateien mit der Endung .db3, sowie einer zugehörigen metadata.yaml. Um eine eindeutige Erkennung einer rosbag2-Aufzeichnung zu ermöglichen erwartet trace.check eine Zip-Datei. Für das Einlesen der Aufzeichnung werden zudem weitere Metainformationen erwartet, die ebenfalls in der Zip enthalten sein müssen.

Für die Verwendung von rosbag2-Aufzeichnungen, die nicht mit trace.check erzeugt wurden, sind einige manuelle Schritte notwendig:

Anlegen eines neuen leeren Ordners.
Kopieren der rosbag2-Aufzeichnung in diesen Ordner (alle .db3-Dateien, die zur Aufzeichnung gehören).
Kopieren der metadata.yaml in den angelegten Ordner
Bis einschließlich Humble Hawksbill ist das Sammeln und Ablegen aller benötigten Strukturinformationen notwendig, die zum Auslesen der Signale benötigt werden (Alle .msg-Dateien). Ab Iron Irwini kann dieser Schritt ausgelassen werden.
Erzeugen einer Zip-Datei mit dem Inhalt des gesamten Ordners.

Inhalt einer beispielhaften Zip-Datei:

../_images/ROS_2_recording_folder_structure.png

mcap

Rosbag2-Aufzeichnungen im Format „mcap“ liegen in einem Ordner mit einer oder mehreren MCAP-Dateien mit der Endung .mcap, sowie einer zugehörigen metadata.yaml. Um eine eindeutige Erkennung einer rosbag2-Aufzeichnung zu ermöglichen erwartet trace.check eine Zip-Datei.

Für die Verwendung von rosbag2-Aufzeichnungen, die nicht mit trace.check erzeugt wurden, sind einige manuelle Schritte notwendig:

Anlegen eines neuen leeren Ordners
Kopieren der rosbag2-Aufzeichnung in diesen Ordner (alle .mcap-Dateien, die zur Aufzeichnung gehören).
Kopieren der metadata.yaml in den angelegten Ordner
Erzeugen einer Zip-Datei mit dem Inhalt des gesamten Ordners.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

RDB

Allgemein

RDB ist ein binäres Format, welches einen von VTD erzeugten RDB-Strom enthält. Von VTD selbst wird es mit der Endung .dat gespeichert, zur Vermeidung von Verwechslungen werden die Aufzeichnungen von trace.check jedoch mit der Endung .rdb versehen.

Signalarten

Folgende Signalarten werden unterstützt:

Integer
Floating-Point
Unicode-Strings

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

STI

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails dienen der Angabe der Samplerate.

Aufbau:

%Samplerate%

Samplerate

Anzahl der Samples pro Sekunde.

Mögliche Werte:

%Zahl% .. Die Samplerate als Fließkommawert.

Standard:

50.0

TDMS

Allgemein

Jede Gruppe einer TDMS Aufnahme kann ihren eigenen Zeitkanal definieren. Wenn alle Zeiten als absolut gegeben sind, wird der früheste Zeitpunkt zu Null normiert und als Referenz für alle Zeitkanäle genutzt. Falls die Messung nur relative Zeiten beinhaltet, wird auch hier der kleinste Zeitstempel auf Null normiert und als Referenz genutzt. Für gemischte Zeittypen, wird der früheste absolute Zeitstempel als Referenz gesetzt, worauf sich alle relativen Zeiten beziehen.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Pflicht. Dient zur Auswahl eines in der Datei enthaltenen Gerätes. Signale werden entsprechend gefiltert bereitgestellt. Möchte man ein weiteres Gerät auslesen, muss die Aufnahme unter Angabe des anderen Geräts in einer zweiten Aufnahmegruppe eingefügt werden.

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

TTL

Unterstützte Feldbussysteme

trace.check unterstützt die Bussysteme CAN, CAN-FD, FlexRay und LIN, sowie Ethernet. Klemme 15 und Klemme 30 werden als analoge Signale unterstützt.

TAPs

Über Ethernet an den Hauptlogger angeschlossene Erweiterungskarten (extension boards) werden unterstützt. Deren TAP-Nummer (auch cascade) muss in den Formatdetails explizit ausgewählt werden (siehe unten).

Pseudosignale

Bei den Dateiformaten TTL werden durch trace.check – neben den eigentlichen Bussignalen – auch sog. Pseudosignale zur Analyse bereitgestellt (im Reiter Tracedateien in der jeweiligen Datei unter Signale). Pseudosignale erlauben den Zugriff auf Rohdaten der Datei, ohne dass eine Signaldatenbanken geladen sein muss. Ist diese geladen, kann trace.check anhand der im Reiter BUS gelisteten Einträge konkrete Signale aus den Rohdaten extrahieren und in der Analyse bereitstellen.

Je nach auszulesendem Medium stehen unterschiedliche Pseudosignale zur Verfügung:

Signal	Hinweis	CAN/CAN-FD	FlexRay	LIN	Datentyp
FrameID		+	+	+	Integer
FramePayload		+	+	+	String
FrameLength		+	+	+	Integer
FrameCycle		-	+	-	Integer
UdsMessage	Benötigt ecu.test diagnostics.	+	-	-	UdsCanMessage

Die verfügbaren Pseudosignale für Ethernet sind im Abschnitt PCAP Pseudosignale aufgelistet.

Service-basierte Kommunikation

Siehe PCAP Service-basierte Kommunikation

Logging-Signale

Siehe PCAP Logging-Signale

PLP (Probe Logger Protocol) / TECMP

Siehe PCAP PLP (Probe Logger Protocol) / TECMP

Busgrößen über AUTOSAR Socket Adaptor

Siehe PCAP Busgrößen über AUTOSAR Socket Adaptor

Parametrierung des Parsers

Gerätebezeichner

Zweck:

Pflicht. Dient zur Auswahl eines in der Datei enthaltenen Gerätes. Signale werden entsprechend gefiltert bereitgestellt. Möchte man ein weiteres Gerät auslesen, muss die Aufnahme unter Angabe des anderen Geräts in einer zweiten Aufnahmegruppe eingefügt werden.

Mögliche Werte:

Analoge Signale, CAN, Flexray, LIN, Ethernet

Formatdetails (siehe Verwaltung von Signalen)

Zweck:

Die Formatdetails dienen als Filter, um nur bestimmte Frames aus dem Trace zu lesen. Analoge Signale benötigen keine Formatdetails. In älteren Versionen wurde zusätzlich ein Aufnahmegerät (‚ANY‘, ‚Tricore‘, ‚FPGA‘) angegeben. Dies ist nicht mehr nötig.

Aufbau:

%Medium%_%Tap Nummer%:%Kanal%_%Richtung%_%Port%

Medium

Der Bus, der gefiltert werden soll.

Mögliche Werte:

CAN .. Es werden nur Frames vom CAN oder CAN-FD gelesen.
Flexray .. Es werden nur Frames von FlexRay gelesen.
LIN .. Es werden nur Frames von LIN gelesen.
Ethernet .. Es werden nur Ethernet-Frames gelesen.

TAP Nummer:

Es werden nur Frames von diesem Logger gelesen.

Mögliche Werte:

%Zahl% .. Die Nummer des TAPs. Gültige Werte sind 0 bis 7, wobei 0 der Hauptlogger ist.

Kanal

Es werden nur Frames von diesem Kanal gelesen.

Mögliche Werte:

%Zahl% .. Die Nummer des Kanals.
1. Gültige Werte auf dem Hauptlogger sind für:
  - CAN .. 1-24
  - LIN .. 1-12
  - FlexRay .. eine Kombination der FlexRay-Nummer 1-3 und des FlexRay-Kanals A, B oder AB
  - Ethernet .. A oder B
  - CAN-FD .. nicht unterstützt
2. Gültige Werte auf den TAPs sind für:
  - CAN .. 1-5
  - LIN .. 1-15
  - FlexRay .. eine Kombination der FlexRay-Nummer 1-2 und des FlexRay-Kanals A oder B
  - Ethernet .. eine Kombination der Nummern 1-6 mit A oder B
  - CAN-FD .. 1-15 (D.h. da CAN-FD unter das Medium CAN fällt, sind die Formatdetails der Kanäle 1-5 für beide identisch.)

Richtung

Es werden nur Frames gelesen, die in eine bestimmte Richtung gesendet wurden.

Mögliche Werte:

Rx .. Es werden nur empfangene Frames gelesen.
Tx .. Es werden nur gesendete Frames gelesen.
RxTx .. Es werden empfangene und gesendete Frames gelesen.

Port

Standard:

Flexray_1A_RxTx_30490

AUDIO

Allgemein

trace.check unterstützt die Dateiformate .wav, .flac, .mp3 und .ogg. Jeder enthaltene Audiokanal kann separat gelesen werden. Die Werte werden als 64-Bit-Gleitkommazahl gelesen, die typischerweise im Bereich von -1,0 bis 1,0 liegt.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet

VIDEO

Unterstützte Videoformate

trace.check verwendet zum Einlesen von Videos OpenCV 2.x. Unterstützt werden somit alle Videos, welche durch OpenCV eingelesen werden können. Entscheidend ist das Videoencoding. Derzeit werden folgende Dateiendungen als Video erkannt: .avi, .mp4, .mkv, .mts.

Vorsicht

OpenCV benötigt bestimmte Media-DLL-Dateien in der Windows-Installation. Diese sind zum Beispiel bei Windows 10 N und Windows Server 2012 R2 standardmäßig nicht installiert. Abhilfe kann man sich mit dem Media Feature Pack für Windows 10 N bzw. Windows Server Essentials Media Pack schaffen.

Info

OpenCV stellt eingelesene Bilder im Farbschema BGR bereit! Möchte man Bilder dem Report hinzufügen, muss z.B. folgender Aufruf zum Ändern des Farbschemas verwendet werden:

rgbArray = cv2.cvtColor(bgrArray, cv2.COLOR_BGR2RGB)

Pseudosignale

Zur Analyse von Frames wird ein Signal namens Frame bereitgestellt. Verwendet man dieses, bekommt man für jeden Zeitpunkt sogenannte Frame-Objekte. Hat man einen Medienzugriff konfiguriert, kann man alternativ das oberste Videosignal addressieren.

Die Schnittstelle des Frame-Objekts ist in der * API-Dokumentation zu finden.

Info

Es ist möglich, die Attribute number, data und time direkt einzulesen. Dazu addressiert man die Pseudosignale Frame.number, Frame.data bzw. Frame.time.

Wenn in den Einstellungen unter Analyseausführung die Rundung von Zeitstempeln aktiviert ist, wird Frame.time entsprechend gerundet.

Parametrierung des Parsers

Gerätebezeichner

Zweck:: Nicht nötig

Formatdetails (siehe Verwaltung von Signalen)

Zweck:: Nicht verwendet