Funktionsweise des TraceRunners im Überblick

Das TraceRunner-Framework ist das Grundgerüst zur Analyse von Protokolldateien komplexer Datenströme von vernetzten Steuergeräten. Die folgenden Elemente bilden den Rahmen für das TraceRunner-Framework:

1. Prüfdefinition
Einmalige Festlegung der Prüfkriterien, Rahmenparameter und Toleranzbereiche.

2. Konfiguration
Festlegung der Analysekriterien und übergreifender Parameter.

3. Analyseauftrag
Durchführung einer Analyse mit Hilfe vorgefertigter Analysekonfigurationen.

4. Ergebnis
Sammlung und Aufbereitung der Ergebnisse zur weiteren Auswertung.

1. Prüfdefinition

Im Vorfeld einer Analyse werden einmalig die Prüfkriterien und die Prüflogik festgelegt. Diese Prüflogik wird als Parser-PlugIn in den TraceRunner integriert.
Dynamische Kriterien (z.B. Grenzwerte, Toleranzbereiche, beobachtete Botschaften) werden als Parameter gestaltet und können später im Rahmen der Konfiguration angepasst werden.

PARSER:
Die Parser bilden das Herzstück des TraceRunners und füllen diesen mit Leben.
Es kann eine beliebige Anzahl von Parsern bereitgestellt werden, welche vom TraceRunner-Controller als PlugIn dynamisch geladen werden. Ein Parser enthält Analysefunktionen, die konkret nach Kundenanforderungen entwickelt werden. Dazu gehören anwendungsspezifische Algorithmen, notwendige Konfigurationsoberflächen, sowie Art, Inhalt und Darstellung der Analyseergebnisse.

Praxisbeispiel

Eine praxisnahe Analysefunktion ist die Bewertung des korrekten zeitlichen Auftretens zyklischer CAN-Botschaften:

Es werden zyklische Botschaften ermittelt, deren Auftreten vom vorgegebenen Zeitraster abweichen oder ganz ausgefallen sind. Bei der Analyse wird besonderes Systemverhalten berücksichtigt. So ändert sich der Sendezyklus von Botschaften phasenweise, wenn durch enthaltene Signale eine Änderung des Sendemodus (OnChange, IfActive, ...) signalisiert wird. Ein Parser mit einer solchen Funktion wird keine "starre" Prüfung durchführen, sondern berücksichtigt konfigurierbare Parameter, z.B. den Toleranzbereich für zeitliche Abweichungen oder Signale, deren Wert einen Einfluss auf den Sendemodus haben.

Der Parser zur Zykluszeitprüfung berücksichtigt damit sowohl technische als auch fachliche Aspekte. Durch die Nutzung von Parametern ergibt sich die Möglichkeit, ein und denselben Parser in Verbindung mit verschiedenen Konfigurationen zu nutzen.

2. Analysekonfiguration

Die Analysebedingungen werden vorab in einer zweistufigen Analysekonfiguration festgelegt. Zuerst werden die variablen Parameter der Parser eingestellt - es entstehen "PARSER-Konfigurationen".
In einer zweiten Stufe werden diese PARSER-Konfigurationen und einige übergreifende Parameter in einer einzigen "TASK-Konfiguration" zusammengefasst.
Ist die TASK-Konfiguration einmal erstellt, kann jeder Anwender darauf zugreifen und beliebige Tracedateien analysieren, auswerten und interpretieren.

TASK-Konfiguration:
Eine TASK-Konfiguration vereint eine beliebige Anzahl von PARSER-Konfigurationen zu einem Analyseauftrag. Dazu werden Rahmendaten wie KanalbelegungenIn Tracedateien werden Kanäle anhand numerischer Kanal-IDs identifiziert, Konfigurationen basieren auf Kanalnamen. Die Kanalbelegung legt eine Verknüpfung zwischen Kanalname und Kanal-ID fest., FunktionskatalogeFür die einzelnen Kanäle muss jeweils ein Funktionskatalog (.dbc/.ldf/.xml) zur Verwendung in der Analyse festgelegt werden., SteuergerätekonfigurationDie Steuergerätekonfiguration bietet die Möglichkeit, einzelne Steuergeräte, Botschaften bzw. Signale von der Analyse auszuschließen. und Trigger Die Trigger ermöglichen es, einzelne Analyse-Funktionen während der Auswertung auf Basis von Zuständen im Trace dynamisch an- bzw. abzuschalten. beigestellt.

PARSER-Konfiguration:
Die im Parser enthaltenen Analysefunktionen sind konfigurierbar. In der Regel müssen Grenzwerte oder beobachtete Botschaften angepasst werden. Die Anpassungsmöglichkeiten hängen von den Analysefunktionen ab.

Praxisbeispiel

Eine praxisnahe Analysefunktion ist die Bewertung des korrekten zeitlichen Auftretens zyklischer CAN-Botschaften:

Im Rahmen der PARSER-Konfiguration wird festgelegt, für welche Botschaften die Zykluszeit geprüft werden soll und welche Zykluszeitwerte für jede dieser Botschaften Gültigkeit haben. Dafür wird ein passender Funktionskatalog (dbc-Datei) als Quelle verwendet und zusätzlich die maximal zulässige Abweichung hinterlegt.

Nach Speicherung der PARSER-Konfiguration wird sie mit den entsprechenden Einstellungen in einer TASK-Konfiguration verwendet.
Eine TASK-Konfiguration enthält die Steuergerätekonfiguration. Diese arbeitet prinzipiell wie ein Filter und gestattet den Ausschluss ausgewählter/aller Botschaften eines Steuergerätes von der Prüfung. Auf diese Weise kann der Anwender ganze Steuergeräte von der Prüfung ausschließen und damit berücksichtigen, dass diese z.B. nicht verbaut sind. Anderseits kann die Prüfung speziell für wenige Steuergeräte oder Botschaften durchgeführt werden, die im Verdacht fehlerhafter Zykluszeiten stehen.

Trigger ermöglichen die Konfiguration von (dynamischen) Einschränkungen der Prüfung auf bestimmte Bereiche des Traces, etwa eine Prüfung ausschließlich bei aktivierter Zündung (KL15) oder nur bei laufendem Motor.

3. Analyseauftrag

Für den Start einer Analyse wählt der Anwender eine der vordefinierten TASK-Konfigurationen aus. Optional können Daten zum Testobjekt, beispielsweise zum Testfahrzeug, angegeben werden.
Da die vollständige Konfiguration bereits in Form der TASK-Konfiguration vorliegt, ist für die eigentliche Durchführung der Analyse nicht zwingend ein Technologie-Experte erforderlich.

Nach Analysestart wird die Auswertung zur Abarbeitung an den zentralen TraceRunner-Controller auf dem Server übergeben. Es können beliebig viele Analyseaufträge gestartet werden, der Client-Rechner bleibt von der Abarbeitung selbst unberührt.

Praxisbeispiel

Eine praxisnahe Analysefunktion ist die Bewertung des korrekten zeitlichen Auftretens zyklischer CAN-Botschaften:

Ein Testfahrer hat die Tracedatei seiner letzten Testfahrt auf seinem Laptop gespeichert und möchte die Daten einer Zykluszeitanalyse unterziehen. Dazu öffnet er den TraceRunner-Client und wählt die passende TASK-Konfiguration. Danach wird er vom Starter-Assistenten durch die restliche Konfiguration geführt. Nachdem die eingegebenen Daten auf Vollständigkeit geprüft wurden, werden die Tracedatei und die Konfiguration an den TraceRunner-Controller zur Abarbeitung gesendet. Der TraceRunner-Client zeigt dem Testfahrer den Fortschritt seiner Analyse an.

4. Ergebnis

Die Analyseergebnisse werden vom TraceRunner-Controller auf zwei Wegen zurückgeliefert:

Übersichtsliste der Ergebnisse als PDF
Die Ergebnisse der Analyse werden in Form einer strukturierten Übersicht als PDF-Datei zurückgeliefert. Fehlverhalten in der analysierten Tracedatei sind anhand der Zeitstempel gekennzeichnet. Der konkrete Aufbau und Inhalt der Ergebnisübersicht wird von den Analysefunktionen der Parser definiert.
Der Detaillierungsgrad der Ergebnisübersicht wird nach Kundenanforderungen ausgestaltet.

Ausführliche Ergebnisse im TraceRunner-DataPool
Zur Weiterverfolgung von Fehlern liefert der TraceRunner-DataPool alle Werte der Analyse mit Zeitstempeln und ausführlichen Detailinformationen.

Praxisbeispiel

Eine praxisnahe Analysefunktion ist die Bewertung des korrekten zeitlichen Auftretens zyklischer CAN-Botschaften:

Die PDF-Datei zeigt die Gesamtzahl der Fehler für die Zykluszeitprüfung an. Zudem werden diese aufgeteilt nach Kanal, Steuergerät und Botschaft aufgelistet. Daraus lassen sich Schlüsse ziehen, welche Steuergeräte fehlerhaft arbeiten. Detailliertere Informationen zu den einzelnen Fehlern finden sich im DataPool. Dort wird jeder einzelne erkannte Fehler aufgeführt. Zu jedem Eintrag gibt es den genauen Zeitstempel sowie genaue Informationen zur Art des Fehlers, so zum Beispiel die Höhe der Abweichung bzw. ob die Botschaft zu früh oder zu spät aufgetreten ist.