ECU-TEST Release 2022.1

Im ADAS/AD-Bereich kommen in der Entwicklung sensorbasierter Fahrerassistenzsysteme zunehmend digitale Zwillinge zum Einsatz. Diese virtuellen Abbilder physischer Systeme können mithilfe von ROS (Robot Operating System) als Co-Simulationsplattformen oder auch als virtuelle Umgebungen für ein Testobjekt (Device Under Test) aufgebaut werden.

Im Anschluss lassen sich damit auf Basis unterschiedlicher Szenarien verschiedene Simulationen ausführen, um die zu testende (Sensor-)Software bereits frühzeitig im Entwicklungsprozess zu testen. Zur Prüfung der Software muss die Kommunikation im ROS-Netzwerk analysiert werden. Die manuelle Auswertung dieser ROS-Nachrichten ist jedoch sehr aufwendig.

Aus diesem Grund wurde eine ROS2-Anbindung an ECU-TEST geschaffen. Damit lassen sich Systeme auf Basis von ROS2 Foxy Fitzroy automatisieren.

Über diese Schnittstelle ist es ECU-TEST möglich, sogenannte ROS-Topics (aus rosbag-Dateien) aufzuzeichnen und zu analysieren. Zudem kann auf diese Weise auch das ROS-System selbst tiefgründig und automatisiert getestet werden.

Der zugrunde liegende Workspace eines Playbooks musste bislang aus einem Versionsverwaltungssystem (Git, SVN) gezogen werden. Um Playbooks auch ohne den Zugriff auf diese Systeme ausführen zu können, wurde der Export von Playbooks aus ECU-TEST erweitert.

Damit ist es nun möglich, den aktuellen Workspace als Artefakt nach TEST-GUIDE zu exportieren.

Der Export-Assistent erlaubt es, sich auf bereits in der Artefaktverwaltung hinterlegte Workspaces zu beziehen oder den aktuellen Workspace direkt hochzuladen.

Die Toolanbindung an den ASAM-Standard iLinkRT 3.0 ermöglicht die Kommunikation mit Mess- und Kalibrierwerkzeugen. Dabei handelt es sich um einen Ethernet-Standard, der Multi-Client- und Multi-Server-Verbindungen unterstützt.

Aktuell wird das Lesen und Aufzeichnen von Messgrößen unterstützt.

Durch die Optimierung des Einlese- und Schreibvorganges und der Parallelisierung beim Einlesen mehrerer A2L-Dateien in der Testkonfiguration wurde neben einer deutlichen Beschleunigung auch gleichzeitig eine Reduzierung des Speicherverbrauchs erzielt.

In modernen E/E-Architekturen werden zunehmend Security-Maßnahmen getroffen, um bekannte Angriffsmuster auf die Fahrzeugkommunikation zu unterbinden. Als eine Maßnahme können Teile der oder die gesamte Bordnetzkommunikation kryptographisch geschützt werden. Eine mögliche Umsetzung kann die Implementierung des IPsec-Protokolls im Bordnetz sein.

ECU-TEST kann nun auch zur Absicherung in kryptographisch geschützten Ethernet-Netzwerken eingesetzt werden. Dazu ermöglicht die eingebaute Netzwerklösung den Aufbau und die Kommunikation in IPsec vermittelten Netzen (für IPv4).

Die aktuelle Implementierung unterstützt den Transportmodus und den Schlüsselaustausch nach IKEv2. Aktive Verbindungen können so mittels Authentication Header (AH) geschützt werden.

Die Verschlüsselung (ESP) ist noch nicht Teil des Funktionsumfangs.

Im Release 2022.1 wurde ein neuer Triggermodus eingeführt:

• mit Zeitversatz wenn Starttrigger erfüllt (with time offset if start trigger is fulfilled)

Damit können zeitlich definierte Triggerbereiche erzeugt werden, die sich um ein Starttrigger-Event aufspannen.
Beispiel:

• Starttrigger: Edge(Signal, 0, 1)
• Start-Offset: -2s (Beginn des Triggers)
• Stop-Offset: 5s (Ende des Triggers)

Der Triggerbereich in diesem Beispiel wird 2 Sekunden vor einer 0-1-Flanke geöffnet und 5 Sekunden danach beendet. Daher ist es mit diesem neuen Modus möglich, dass sich weitere Triggerbereiche des gleichen Triggerblocks überlappen.

Gekürzte Triggerbereiche am Anfang und Ende des Traces oder des übergeordneten Bereiches können explizit (z.B. mit FAILED) bewertet werden. Die dazugehörige Einstellung befindet sich unter 'Erweiterte Optionen' des Triggerblocks.

Im interaktiven Signalbetrachter AutoSPY ist es nun deutlich einfacher, die korrekten Signale zu identifizieren:

• Die Unterstützung von Zahl-zu-Text-Zuordnungen (Enumerationen von z.B. Statussignalen auf einem Bus) erleichtert neben der Signalidentifikation auch die Interpretation der Signalwerte. Der zugehörige numerische Rohwert lässt sich weiterhin anzeigen.
• Beim Öffnen des AutoSPY Viewers aus einem statischen Plot des TRF-Reports werden Signalfarbe und Linienstil schon seit mehreren Releases übernommen. Ab ECU-TEST 2022.1 werden die Signalkurven ebenfalls automatisch formatiert, wenn eine astrace-Datei direkt mit dem Viewer geöffnet wird.
• Mit F11 lassen sich alle Andockfenster minimieren. So steht mit einem Tastendruck mehr Platz zur Verfügung. Mit Shift + F11 werden alle minimierten Toolboxen wieder hergestellt.

Außerdem wurde der Maus-Zoom (Z) verbessert:

• Linksklick: Vergrößerung des Zeitbereichs
• Shift + Linksklick: Vergrößerung des Wertebereichs
• Shift + Ctrl + Linksklick: Vergrößerung des Zeit- und Wertebereichs
• Rechtsklick: bewirkt jeweils die entsprechende Verkleinerung
• Gedrückthalten der linken Maustaste: Aufziehen eines Zoomfensters, das neuen sichtbaren Zeit- und Wertebereich festlegt

Im Online-Fall nutzt ECU-TEST bereits seit dem Release 2021.4 einen effizienten und intelligenten Filtermechanismus, um mit sehr hohen Datenraten performant umgehen zu können. Hierbei werden für den Testfall und die Analyse nicht relevante Anteile der servicebasierten Kommunikation im Rahmen einer Anlernphase erkannt und auf Ebene des Betriebssystems ressourcenoptimiert weggefiltert. So entstehen reduzierte PCAP-Traces, die nur die für den Testfall und die Analyse relevanten Daten enthalten.

In ECU-TEST 2022.1 wird nun auch die Offline-Filterung servicebasierter Kommunikation aus PCAP-Traces unterstützt. Hierbei werden die Traces abseits von ECU-TEST erstellt, z. B. von Loggern. Dies ermöglicht deutliche Performancegewinne bei der Traceanalyse dieser Daten.

Die Länge der Anlernphase kann in den ECU-TEST-Einstellungen im Bereich 'Traceanalyse' konfiguriert werden.

Die neue signalbasierte Zusammenführung von Traces erzeugt synchronisierte und interpretierte MDF4-Traces auf Basis beliebiger Aufnahmen eines Packages.

Konkret werden mittels der Trace-Zusammenführung alle Signale der verwendeten Signalgruppen, unter Berücksichtigung der jeweiligen Synchronisation, in eine gemeinsame MDF4-Datei übernommen.

Berücksichtigt werden dabei:

• Signale in den Signalgruppen
• Signale der speziellen Signalgruppe Automatisch zuordnen
• Signale der Option Alle Testgrößen aufnehmen
• Signale aus Analysepackages

Im Gegensatz zu botschaftsbasierten Originalformaten (wie z.B. ASC oder BLF), können die interpretierten Signaldaten auch ohne die zugehörigen Datenbasen (wie Bus- oder Servicebeschreibungen) weiterverwendet werden. Insgesamt wird die übergreifende Wiederverwendung von zusammengehörigen Trace-Daten deutlich erleichtert.

Wird aus einem Spezifikationspackage mit Versionsnummer ein Implementierungspackage abgeleitet, wird am Implementierungspackage automatisch die Verknüpfung zum Spezifikationspackage und auch die zugehörige Versionsnummer angezeigt.

Eine Änderung der Versionsnummer in der Spezifikation wirkt sich auch auf das implementierte bzw. abgeleiteten Package aus. Es erkennt, dass die Versionsnummern nicht mehr übereinstimmen und zeigt farblich markiert die neue Versionsnummer der Spezifikation eingeklammert neben der bis dato gültigen Versionsnummer an.

Über das Kontextmenü lässt sich die Verknüpfung zum Spezifikationspackage und damit auch die Versionsnummer aktualisieren.

Mit der Unterstützung ist es möglich, alle bekannten Bustestschritte auch über den Zugriff des IEEE 1722 (CAN) Ethernet-Protokolls zu nutzen.

Dafür stehen auf dem Ethernet-Tooladapter neue Ports für den Buszugriff und J13939 zur Verfügung.

Mit dem Testschritt Initialwert prüfen ist es möglich, auf den ersten Wert eines Signals seit dem Start der Messung (Portstart) bzw. seit dem letzten Aufruf von Initialwert zurücksetzen zuzugreifen.

Neu ist, dass in diesem Testschritt jetzt auch Zeitoptionen für die Bewertung konfiguriert werden können. Zudem kann auch die Repräsentation eines Signalwertes (Physikalischer Wert, Textwert, Rohwert, Implementierungswert) ausgewählt werden. Das Verhalten ist analog zum Testschritt Lesen.

Im Precondition-Block von ECU-TEST gibt es die Möglichkeit, die Bewertung der enthaltenen Testschritte per Checkbox mit NONE und ERROR zu überschreiben. Das führt dazu, dass SUCCES auf NONE abgebildet wird und INCONCLUSIVE sowie FAILED auf ERROR. Damit wurde jeder Testfall mit ERROR abgebrochen, wenn er im Precondition-Block mit INCONCLUSIVE bewertet wurde.

Um die Bewertung INCONCLUSIVE flexibler handhaben zu können, wurde der Precondition-Block speziell um die Möglichkeit erweitert, INCONCLUSIVE als Bewertung für einen Testfall beizubehalten und den Test so nicht abzubrechen.

Dafür gibt es zwei neue Optionen:

• Bewertung überschreiben: Über die Auswahlliste kann definiert werden, ob die Bewertung INCONCLUSIVE beim Überschreiben der Bewertung ausgenommen werden soll oder nicht.
• Variable Abbruchinformation: Mit dieser Option lässt sich einstellen, ob der Testfall bei einer Bewertung mit INCONCLUSIVE abgebrochen wird oder weiterlaufen soll.