Hexagon: VTD¶

Herstellerinformationen

Kategorien

Plattform

Ports¶

Besonderheiten¶

Grundlegende Informationen zum Umgang mit Umfeldsimulationen findet man im Abschnitt Tab Umfeldsimulation.

Diese Toolanbindung ermöglicht das Laden von VTD-Szenarien sowie das Starten und Stoppen der Simulation. Nach dem Start eines Szenarios stehen dessen Signale für den Lesezugriff bereit und können für eine nachfolgende Traceanalyse aufgezeichnet werden.

Bitte beachten Sie, dass die Anbindung von RDB-Verbindungen über UDP nicht unterstützt wird.

Einrichtung¶

Toolkonfiguration

VTD ist nur in einer Linux-Umgebung lauffähig, der Tool Server erfordert jedoch eine Windows-Installation. Deshalb verläuft die Einrichtung einer VTD-Verbindung zu einem Remote-Computer anders als bei vergleichbaren Tools.

1. Legen Sie einen neuen, lokalen Toolhost an.

2. Navigieren Sie zu VTD und klicken Sie im Kontextmenü auf Tool hinzufügen.

3. Klicken Sie im gleichen Kontextmenü auf Neuer Port und passen Sie wenn benötigt die Port-ID an.

4. Konfigurieren Sie die TBC-Optionen.

5. Legen Sie eine neue Testkonfiguration an und wählen Sie dort den angelegten Modell-Port.

TBC-Optionen

Beachten Sie, dass der in Projektverzeichnis auf VTD-Toolhost angegebene Unix-Pfad zu einem Ordner zeigt, in welchem alle von der VTD-Installation verwalteten Projekte liegen und eine Ordnerverknüpfung „Current“ vorhanden ist. Die Anbindung bietet die Möglichkeit, beim Tool-Start ein lokales Projektverzeichnis auf den Remote-Computer zu kopieren. Dazu setzen Sie den zugehörigen Pfad in Lokales Projektquellverzeichnis. Der Inhalt dieses Ordners wird während des Aufstarts in den in Projektverzeichnis auf VTD-Toolhost angegeben Pfad übertragen. Des Weiteren kann ein Pfad zu einem auf dem Linux-System liegenden Startscript angegeben werden, welches VTD auf dem Remote-Computer startet.

Aufnahme von Sensoren

Mit dieser Anbindung können Sensordatenströme aufgenommen werden. In VTD gibt es mehrere Möglichkeiten, Sensoren zu konfigurieren. Einerseits erlaubt die Benutzeroberfläche die Erstellung neuer Sensoren, andererseits können diese auch über Konfigurationsdateien verwaltet werden. Die globale Konfiguration befindet sich unter [VTD]/Data/Distros/Distro/Config/ModuleManager/moduleManager.xml. Beide Möglichkeiten sind voneinander unabhängig. In der Benutzeroberfläche erstellte Sensoren werden jedoch nur aufgestartet, wenn auch die Simulation manuell in der GUI gestartet wird. Daher sollten Sensoren für die Automatisierung mit ecu.test in der Konfigurationsdatei spezifiziert werden.

Im Gegensatz zu normal in VTD verfügbaren Signalen können diese nicht während des Testfalls gelesen werden, auch erfolgt deren Aufnahme über die Tooljobs Start-, Stop- und FetchRdbRecording. Letzterer gibt den Pfad zur Aufnahme zurück, welcher in einem nachfolgenden „Add Trace“-Schritt in die Traceanalyse eingegliedert werden kann.

Start-Script

Aufgrund der Vielzahl von möglichen Konfigurationen und Startvarianten unterstützt diese Anbindung das nicht blockierende Ausführen eines Bash/Shell-Scripts während des Aufstarts. Falls Projektdateien kopiert werden, wird das Script erst nach erfolgreicher Übertragung getriggert. Ein Beispielscript ist im Folgenden gezeigt. Bitte beachten Sie, dass das Script ausführbar sein muss (Konsolenbefehl: chmod +x vtdStartScript.sh).

#!/bin/sh

# The VTD project to load
vtdProject=SampleProject

pathToVTDBin=~/VTD.2.1/bin
vtdStartupScript=./vtdStart.sh
vtdKillScript=./vtdStop.sh


# Possible workaround if the Linux system does
# not display the VTD GUI when starting via SSH
export DISPLAY=:0

cd $pathToVTDBin
# Stop a possibly still running VTD instance
$vtdKillScript
# Give VTD a few seconds to wrap up unfinished tasks
sleep 5s

# Start a new VTD instance
$vtdStartupScript -autoConfig -project="$vtdProject"

SSH-Zugang

Ein SSH-Zugang zum VTD-Rechner wird vorausgesetzt. Der SSH-Zugang wird unter anderem benötigt für das Abholen von Aufnahmen, den automatischen Projektupload und den Toolstart.

Zur Erstellung kann in einem Linux-Terminal der Befehl ssh-keygen aufgerufen werden. Die darauf folgenden Prompts können ohne weitere Eingabe per Enter bestätigt werden. Der Speicherort des Schlüsselpaars wird im Terminal angezeigt. Der Inhalt des öffentlichen Schlüssels muss nun in eine im selben Ordner befindliche Datei authorized_keys eingetragen werden. Sollte diese nicht vorhanden sein, muss sie manuell erstellt werden. Der private Teil des Schlüssels, welcher standardmäßig id_rsa benannt wird, sollte auf den Testhost übertragen und in der entsprechenden TBC-Option angegeben werden.

Alternativ ist eine Generierung eines Schlüsselpaars mit PuTTYgen möglich (Abschnitt 8.2.1), dessen öffentlicher Teil auch hier auf dem Linux-Rechner hinterlegt werden muss (Abschnitt 8.3). Bitte beachten Sie, dass ein privater Schlüssel ohne Passphrase (Abschnitt 8.2.7) benötigt wird, da in ecu.test keine Möglichkeit zur Eingabe der Passphrase vorgesehen ist. Das erstellte Schlüsselpaar muss anschließend in das OpenSSH-Format konvertiert werden (Abschnitt 8.2.12).

Parametrierung in ecu.test und OpenSCENARIO Workflow mit scenario.architect¶

Im Tutorial OpenSCENARIO Workflow mit scenario.architect wird beschrieben wie aus der VTD-Toolanbindung heraus XOSC-Szenarien mit dem scenario.architect erstellt und/oder bearbeitet werden können. Anschließend können die Szenarien in ecu.test parametriert werden.

Eigenschaften 🛈¶

Jobs 🛈¶

FetchRdbRecording¶

Holt die Aufnahme für einen RDB-Datenstrom ab und speichert diese ins Reportverzeichnis.

ReadScpCommand¶

Wartet auf ein vorgegebenes SCP-XML-Tag und gibt die empfangene SCP-Nachricht zurück.

RunScpCommand¶

Sendet eine benutzerdefinierte SCP-Nachricht und wartet optional auf eine Antwort mit einem angegebenen SCP-Tag.

StartRdbRecording¶

Startet die Aufnahme für einen RDB-Datenstrom

StopRdbRecording¶

Stoppt die Aufnahme für einen RDB-Datenstrom