... Neuerungen älterer Versionen

Die CarSim-Anbindung wurde überarbeitet und umgestellt. Der Zugriff erfolgt jetzt über den Tab Umfeldsimulation. Damit können die bereits aus anderen Anbindungen gewohnten Testschritte und -größen verwendet werden. Der Testaufbau wird damit flexibler, da jetzt das Laden und Starten eines Szenarios getrennt ist.

Abhängig vom Zeitmodus gibt es Tooljobs, die statt dem Starten und Stoppen der Simulation zu verwenden sind. Diese ermöglichen auch spezielle Aufgaben, z.B. das Modell an Simulink oder Scalexio zu senden.

Die Simulationsschnittstelle OSI ist eine generische Schnittstelle für die Umgebungswahrnehmung von automatisierten Fahrfunktionen in virtuellen Szenarien. Dabei definiert OSI Größen, die von ECU-TEST gelesen werden können. Das Einbeziehen von GroundTruth-, SensorData- und SensorView-Informationen erlaubt den Vergleich zwischen dem virtuellen Geschehen der Szenarien und Sensordaten mit der Reaktion der Fahrfunktion. Mit der neuen Anbindung von ECU-TEST an OSI hat der Testfallentwickler die Möglichkeit, basierend auf einem Standard, Umfeldinformationen wie GroundTruth- oder Sensordaten für Testaktivitäten zu erschließen. In der anschließenden Trace-Analyse können aufgezeichnete OSI-Traces mit den Aufnahmen rund um die Fahrfunktion automatisiert ausgewertet werden.

Technische Details:

• Anbindung über den Tool-Adapter ZeroMQ
• Kommunikation über die Netzwerkbibliothek ZeroMQ
• Unterstützung des Standards in der Version 3.2.0
• Lesen und Auswerten von GroundTruth, SensoData, und SensoView Informationen
• Automatisierte Aufzeichnung und Auswertung von OSI Traces

Während der Erstellung eines Packages oder Projektes ist es sinnvoll, eine Plausibilitätsprüfung durchzuführen und so Aufschluss über fehlerhafte Referenzen oder fehlende Variablen zu erlangen.

Zu den bereits integrierten Prüfmechanismen können jetzt Package-Überprüfungen und Projekt-Überprüfungen in Form von Skripten erstellt werden. Diese werden im Ordner UserPyModules als .py-Datei des aktuellen Workspaces hinterlegt und beim Ausführen der Funktionen Check package bzw. Check project automatisch angewendet.

(Damit Änderungen an diesen Skripten ohne einen ECU-TEST-Neustart wirksam werden, kann über Extras/Benutzerbibliotheken aktualisieren ein Neuladen veranlasst werden.)

Vor der automatisierten Ausführung eines Testauftrags aus einem ALM-System(*) sind viele vorbereitende Aufgaben zu erledigen, wie zum Beispiel:

• Geeignete Testbench für zugrunde liegende Metadaten des Testauftrags bestimmen
• Prüfplatz und Testobjekt einrichten: Konfigurationen vornehmen
• Testimplementierungen passend zum Auftrag wählen und ggf. parametrieren

(*) unterstützte ALM-Systeme: Microfocus ALM.NET und ALM Octane, Siemens Polarion, Rally / CA Agile Central

Der neue flexible Testauftrags-Import macht es nun möglich, diese vorbereitenden Aufgaben automatisieren zu können. Dafür wird ein Python-Skript im Workspace hinterlegt. Beim Import des Testauftrags über API oder das Workspace-Kontextmenü Test management/Import project wird das Skript automatisch ausgeführt und es bekommt dabei die Metadaten des Testauftrags sowie die Liste der geforderten Testfälle übergeben. Auf diese Weise kann ein vollständig passendes ECU-TEST Projekt generiert werden, welches sofort vollautomatisiert am Prüfplatz ausgeführt werden kann.

ECU-TEST kann Spezifikationen aus ALM-System (*) importieren und daraus das Grundgerüst für ein neues Testfall-Package erstellen. Mit dem neuen flexiblen Import ist es nun möglich, diese Erstellung so zu beeinflussen, dass das Testfall-Package bereits nach der Erstellung bestimmten Anforderungen genügt. Dafür muss ein Python-Skript im Workspace hinterlegt werden. Dieses Skript bekommt dann beim Import von Testfällen aus einem ALM-System die Liste von Schritten aus der Testfallspezifikation und die zum Testfall dazugehörigen Metadaten übergeben.

(*) unterstützte ALM-Systeme: Microfocus ALM.NET und ALM Octane, Siemens Polarion, Rally / CA Agile Central, Jama Connect

Bisher notwendige, wiederkehrende, manuelle Implementierungsaufgaben können mit diesem Skript automatisiert werden. Beispielsweise können folgende Aufgaben automatisiert werden:

• Einfügen immer wiederkehrender Testschritte in der Testfallvorbedingung
• Automatisches Einfügen von vordefinierten Implementierungsschritten für wiederkehrende Spezifikationsschritte
• Anlegen von immer benötigten Mappings oder Variablen

Für den Test einer grafischen Benutzeroberfläche steht jetzt neben JS Foundation: Appium die Anbindung zu froglogic: Squish zur Verfügung. Dieses Tool interagiert im Testfall über einen Squish-Server mit der Benutzeroberfläche von Anwendungen auf verschiedenen Plattformen (Desktop, Mobilgeräte oder Embedded Systems) und in den unterschiedlichsten Technologien.

Neben der Stimulation der Anwendung mit Hilfe von Job-Testschritten kann der aktuelle Bildschirminhalt gelesen und mit dem Bild-Lesen Testschritt und Filtern analysiert und bewertet werden. Dies ermöglicht den automatisierten Test sowohl von passiven Anzeigeelementen als auch von komplexen Bedienelementen mit Touch-Funktion, wie sie beispielsweise im Infotainment weit verbreitet sind.

Der Image-Port von ECU-TEST bietet nun die Option, das aktuelle Bild der Kamera oder den aktuell konfigurierten Video-Stream live in einem separaten Fenster anzuzeigen. Damit hat man den Prüfling ständig im Blick und die Fehlersuche wird deutlich vereinfacht.

Mit dem ECU-TEST Diagnose-Add-on ist es jetzt möglich, das Transportprotokoll "Diagnostics over IP" (DoIP) zu verwenden. Das Diagnose-Add-on verfügt dafür über zwei neue Ethernet-Ports:

• DOIP-SOCKET
• DOIP-PCAP

In der Testkonfiguration stehen dafür jeweils auch Verbindungseinstellungen zur Verfügung. DoIP bietet den gleichen Funktionsumfang wie die bereits bekannte UDS-Diagnose über CAN. In diesem Zusammenhang sind viele Verbesserungen in der Unterstützung der Diagnosedatenbanken ODX sowie CDD dazugekommen.

Für das Testen servicebasierter Kommunikation bietet ECU-TEST Zugriff auf strukturierte Daten wie sie in einer Service-Beschreibung im ARXML-Format definiert sind. Diese strukturierten Daten können nun auch in der Signalaufnahme und Trace-Analyse effizient genutzt werden.

Events und Methoden aus dem Tab Service können in die Signalaufnahme gezogen werden, um sie aufzuzeichnen. (Dabei kommt der bekannte ECU-TEST-Mapping-Mechanismus zum Einsatz.) In den entstehenden PCAP-Aufzeichnungen der Ethernet-Kommunikation können diese Events und Methoden dann mit der Trace-Analyse ausgewertet werden.

In der Trace-Analyse ist ein eingabeunterstützter Attributzugriff auf Substrukturen möglich. Ferner wird auch ein Indexzugriff auf die einzelnen Komponenten eines Vektors unterstützt.

Teams und Projekte, welche mit den gleichen Bus- und Service-Datenbanken arbeiten, können von nun an ihre Produktivität steigern. Beim erstmaligen Einlesen einer Bus- oder Service-Datenbank werden Caches generiert, die in ein gemeinsames Cache-Verzeichnis abgelegt werden können. Andere Team-Mitglieder können diese für ihr Projekt verwenden und sparen sich die bisweilen lange Wartezeit beim Einlesen der Datenbanken.

Das gemeinsame Cache-Verzeichnis wird in den Workspace-Einstellungen unter dem Punkt Verzeichnisse angegeben. Die Cache-Dateien werden verschlüsselt abgelegt.

Die FMI-Anbindung zur Simulation von FMUs bietet zahlreiche neue Möglichkeiten:

• Ausführung von SiL-Tests (FMI-Standard) Tool-unabhängig auch unter Linux
• Hierarchische Darstellung strukturierter Variablen im Modellbaum
• Verwendung von Vektoren und Matrizen im Testfall sowie in der Trace-Analyse
• Explizite Auswahl des Simulationsmodus Model Exchange oder Co-Simulation, insbesondere für FMUs die beides unterstützen

Use-Cases

• ECU-TEST als Teilnehmer einer Co-Simulation, die als Timing Master fungiert

• Virtuelle ECU als Testobjekt und Zugriff über weitere Schnittstellen und 3rd Party Tools

Neuer, kontinuierlicher Simulationsmodus

1. Testfälle in Simulationszeit
2. Plattform als Zeitquelle und Simulationssteuerung
3. Reporting der Simulationszeit und realen Zeit

• Zurücksetzen von Parametern nach Simulationsstopp
• Manipulation von Signalen über definierten Zeitraum
• Testen in Modellzeit
• Unterstützung von Einheiten in der Trace-Analyse

• Stimulation von Signalen und Parametern
• Zurücksetzen von Signalen und Parametern
• Kontinuierlicher Simulationsmodus
• Unterstützung von 32-Bit-FMUs

1. Unterstützung des Metamodell 2
2. Demultiplexing der FEP-VU ObjectStates und VehicleAppearance

1. Tool-Server unter Linux
2. REST-API zur Ausführungssteuerung unter Linux

Linux-kompatible Tools

• Multimedia
• FEP
• ADTF
• VTD
• SSH
• User ToolAdapter

1. Zugriff auf komplexe Rückgabewerte von DID, RoutineCtrl und IoCtrl direkt im Testschritt
2. Autovervollständigung für Unterelement und -strukturen

1. AUTOSAR PDUs via Socket Adaptor
2. Volle IPv6-Unterstützung
3. AUTOSAR SOME/IP mit optionalen Strukturelementen
4. Aufnahme, Analyse und Replay von PCAPNG

Aktualisierte und neue Formate

• BLF-Traces für LIN und Roh-Ethernet-Analysen
• ASC: Performance-Verbesserung
• PCAPNG

Neue Standards

• AUTOSAR-PDUs via Socket Adaptor

Aktualisierte Tools

• ATI VISION 6
• FEP 2.7.1
• NI LabView 2020
• NI VeriStand 2020
• OPAL RTLAB 2020.2
• Vires VTD 2019/2020
• VW ODIS 12.2

Motivation

• Analysen abhängig von Varianten des Prüflings/der Umgebung
• Parameterabhängige generische Analysen werden schnell unwartbar

„Der Weg zur Hölle ist mit generischen Lösungen gepflastert“

• Rollentrennung/Domänenverantwortung berücksichtigen

Wunsch: einen Analyse-Platzhalter auf eine konkrete Implementierung zu mappen

Workflow

1. Durch Testschritt "Analyse anfordern" definiertes Label
2. Konkrete Zuordnung durch globales Mapping

Testschritt: Analyse anfordern

• Definition eines Freitext-Labels (z.B. „CheckVelocity“)
• Analyseergebnis optional in den Testfallreport einpflegen
• Analysen bedingt anfordern und ausführen (z.B. im Then-Block eines If-Then-Else-Testschritts)
• Verlinkung im Projekt-Report

Package-Eigenschaft: Stimulations-Package

• Stimulations-Packages können ihre Aufnahmen zugeordneten Analyse-Packages zur Verfügung stellen
• Stimulanz-Packages werden beim Einfügen in ein Projekt entsprechend behandelt
• Auch über Object-API les- und schreibbar

1. Im Explorer nach Stimulations- oder Spezifikations-Packages filtern

1. Automatisch erstellter Platzhalter pro angeforderter Analyse
2. Kann direkt durch lokales Analyse-Package implementiert werden (Drag&Drop aus dem Explorer)

1. Validierung: Implementierung angeforderter Analyse
2. Analyse-Mappings für Platzhalter ohne Implementierung erstellen

1. Konkrete Implementierung zuweisen
2. Analyse-Mapping aus dem Viewer in den Testfall ziehen, um entsprechenden "Analyse anfordern"-Schritt zu erzeugen

1. Neue Mappings aus bestehenden Implementierungen erstellen

1. Erzeugt Parametersatz mit konfigurierter Aufnahme für jeden Trace in definiertem Verzeichnis
2. Generator kann einfach erweitert oder an eigene Anforderungen angepasst werden

Generator zur flexiblen und einfachen Erzeugung von Packages für den Signalvergleich zweier Traces (z.B. Referenz- oder Back-to-Back-Tests)

• Generierung von Packages oder Parametersätzen
• Konfigurierbare Zuordnung assoziierter Signale
• Individuelle Signalvergleichs-Ausdrücke
• Wahlweise GUI- oder codebasierte Konfiguration

In ECU-TEST können Testfallspezifikationen in Form von Spezifikations-Packages bearbeitet und gespeichert werden:

Aus einem Spezifikations-Package können Implementierungs-Packages abgeleitet werden:

Implementierungs-Packages sind mit ihrem Spezifikations-Packages verlinkt:

Ein Vergleich beider Packages, z.B. um Spezifikationsänderungen gegenüber der Implementierung zu erkennen, ist möglich:

Testausführungs-Playbook Übersicht

1) Vorbereitung und Implementierung mit ECU-TEST

• Projekt strukturieren: Setup, Tests, Teardown
• Projekt als Playbook nach TEST-GUIDE hochladen

2) Parallelisierung und Verteilung mit TEST-GUIDE

• Playbooks in einen oder mehrere Testausführungsaufträge überführen
• Testausführungsaufträge auf passende, freie Prüfstände verteilen

3) Ausführung mit ECU-TEST

• Testausführungsaufträge über den TEST-GUIDE ResourceAdapter mit ECU-TEST ausführen
• Die neue ECU-TEST REST-API ermöglicht die automatisierte Ausführung

Playbook in ECU-TEST vorbereiten

Konventionen

• Setupschritte werden vor dem ersten Test ausgeführt
• Teardownschritte werden nach allen Tests ausgeführt
• Die Tests sind unabhängig voneinander und können verteilt und in beliebiger Reihenfolge ausgeführt werden

Workspace

• Abgelegt im Source Code Management System: Git URL, Git Revision (commit hash)

Verteilte Testausführung

TEST-GUIDE kann Testausführungsaufträge auf eine Vielzahl physischer und virtueller Prüfstände verteilen

Grundansatz: ECU-TEST Report-Uploads zu TEST-GUIDE einfach auslagern, damit ECU-TEST sofort weitertesten kann!

TEST-GUIDE ResourceAdapter übernimmt die Arbeit. In ECU-TEST muss uploadThroughResourceAdapter konfiguriert werden.

Details: https://www.test-guide.info/changelog/#_version_1_84_2_released_2020_09_30

1. Verschiedene Gesten (Tap, Swipe) und Geräteinteraktionen
2. Aufnahme von Screenshots als Bild und Video für weitere Analysen
3. Unterstützung von iOS und Android
4. Plattform-, Geräte- und App-Einstellungen können in TBC gesetzt werden

CalculateBrightness

• Berechnung eines Helligkeitssignals
• Unterstützung von Masken

FindImage

• Berechnung eines logischen Signals ContainsImage
• Berechnung eines objektwertigen Signals zur API-Interaktion mit Match-Objekten
• Unterstützung von Masken

ReportFrameAtStartTrigger

• Frames eines Videos beim Start-Trigger eines übergeordneten Trigger-Blocks dem Report hinzufügen
• Optionale Angabe eines FrameOffsets, um z.B. den Frame vor dem Start-Trigger zu dokumentieren
• Optional die gefundenen Matches von FindImage oder eine parametrierte Maske im Report hervorheben

Numpy-Traceschrittvorlage ReduceVideo

• Beschleunigung nachfolgender Analyseschritte
• Reduktion von Auflösung
• Umwandlung in Graustufenvideo
• Reduktion der Bildrate (Downsampling)

Neue API-Methode FindImageByFeatures

• Nutzung von Merkmalerkennung, um Teilbilder in den Frames eines Videos zu finden
• Unabhängig von Größe, Drehung, Farbe oder Perspektive

Masken und Referenzbilder einfach aus Videos erstellen

1. Beliebige interne Daten (wie z.B. Frames) aus dem Steuergerät für Testfall und Analyse verfügbar machen
2. Beispiel-Usecase: Logging der Hardware-Auslastung während des Tests

1. ECU-TEST zeichnet im gleichen .dlt Dateiformat auf
2. Einzelne DLT-Botschaft

• AUTOSAR-standardisierte Schnittstelle zum Loggen und Tracing von Steuergeräten
• Unterstützung des Verbose-Modes (non-verbose mit Fibex bereits seit ECU-TEST 2020.1)
• Lösung unter Einbeziehung des GENIVI DLT-Viewers

1. Angabe in der Testkonfiguration liefert Zugriff über objektwertige Signale
2. Weiterverwendung der Filterdateien aus dem DLT-Viewer
3. API-Zugriff auf diverse Attribute, wie z.B. applicationId oder Argumente

1. Identisches Datenobjekt in der Traceanalyse
2. Offline-Analyse von DLT- und PCAP-Aufzeichnungen

1. Ablage von Szenarien und Attributen in der TEST-GUIDE-Artefaktverwaltung
2. Filterung und Download der Szenarien in ECU-TEST
3. Direkte Simulation in VTD und CarMaker

1. Migrationshilfe für den Umstieg auf neue Tool-Kategorie "Environment Simulation”

Motivation

• Szenariendatenbank + Testautomatisierungs-Workflow in ECU-TEST
• Ermöglicht methodische Weiterentwicklung spezifischer Features für Umfeld-Simulation

Unterstützte Tools

• VTD
• CarMaker

1. Generische Stimulation, Parameter
2. Analysen, um Requirement zu prüfen oder KPIs zu berechnen
3. Unabhängige Reports für jeden Lauf eines Analyse-Packages inkl. Rückgabewerten

• Simulations- und Testumgebung für Functional Mock-up Units (FMU) ohne weitere proprietäre Tool-Abhängigkeit
• Lesen, Schreiben, Aufzeichnen und Analysieren von FMU-Parametern und Signalen

Diagnose-Add-on

UDS-Service $2F "Input/Output Control by Identifier“

• Services "Return control to ECU", "Reset to default", "Freeze current state" und "Short term adjustment“ können als spezielle DIDs verwendet werden
• Zugriff auch via Job InputOutputControlByIdentifier

Weitere Highlights

• CANdela Diagnostic Data (*.cdd) kann als Diagnose-Beschreibung verwendet werden
• Unterstützung für ODX ECU-Variants

Neue und aktualisierte Tools und Standards

Neue Anbindungen

• Appium
• FMI

Neue Formate

• DLT
• FLAC
• MTS
• WAV

Neue Standards

• CANdela Diagnostic Data (CDD) 6.5 bis 9.1
• FMI 1.0 und 2.0
• Probe Logging Protocol (PLP) für Ethernet
• AUTOSAR DLT verbose Mode

Aktualisierte Tools

• dSPACE Release 2020-A
• ETAS INCA 7.3.1
• ETAS LABCAR 5.4.10
• FEP 2.7.1
• IPG CarMaker 9
• Lauterbach TRACE32 R.2019.09
• Softing DTS 9
• Vector CANape 18SP2
• Vector CANoe 13
• VW ODIS 11

Aktualisierte Standards

• ASAM XIL STI/STZ 2.1 und 2.2

Features:

• Unterstützung STI-Dateien in den Versionen 2.1 und 2.2
• Segmente können einfach in eine Wertetabelle umgewandelt werden
• Frei setzbarer Cursor

Usability

• STI- und STZ-Dateien können direkt aus dem Editor heraus geöffnet werden
• Höhe und Breite einzelner Signalpanels konfigurierbar
• Alle Signale auf einer gemeinsamen Zeitachse übersichtlich darstellbar

1. Frei setzbarer Cursor um konkrete Datenpunkte im Signalverlauf abzulesen
2. Verbesserungen der Performance

• Externer Python-Editor auch für UserPyModules
• Einfachere Signalzuordnung im Plot
• Konfigurierbare Signalbezeichner im Traceschritt Signalexport
• Performance-Optimierung der Trace-Analyse, insbesondere bei vielen Trigger-Bereichen und großer Anzahl an Zeitstempeln der verwendeten Signale

1. Verschiebung analog zu Blöcken: Strg + Shift + ↑
2. Mehrere Analyse-Packages über Drag-and-drop einer anderen Stimulation zuweisen

Ermöglicht:

• Suche passender Implementierung ja nach Kontext (Prüfling, Prüfumgebung) mittels Attributen
• Schnelle Navigation zwischen Packages
• Schneller Abgleich (Diff) bei Spezifikationsänderungen