VTDx (Virtual Test Drive X)
Kunde
Hexagon (heute Cadence)
Zeitraum
2023-2024
Rolle
Designer
Aufgaben
Konzept, UX-Design, UI-Design, Prototyping
Auszeichnung
iF Design Award 2025, Kategorie Web Application
Projektübersicht
Virtual Test Drive X (VTDx) ist eine Umgebungssimulationssoftware zum Testen, Trainieren und Validieren von Fahrerassistenzsystemen und autonomen Fahrfunktionen.
Als Nachfolger von VTD setzt sie auf Unreal Engine 5 und cloudnative Lösungen. Weil sich damit bereits früh umfangreich testen lässt, sinkt der Bedarf an physischen Testfahrten.
Projektziele
Klarheit statt gewachsener Komplexität
Die Informationsarchitektur so strukturieren, dass komplexe Abläufe nachvollziehbar bleiben.Effizienter arbeiten
Simulationen einfacher konfigurieren, steuern und analysieren.Einstieg erleichtern
Schulungs- und Supportaufwand durch verständliche Bedienung reduzieren.Systematisch erweiterbar
Ein Designsystem, das Konsistenz sichert und mit dem Produkt mitwachsen kannLegacy VTD in neues VTDx weiterentwickeln
Vom Code zur Übersicht
In der Vorgängerversion führte der Weg zu einem Szenario über Code. Wer eine Simulation aufsetzen wollte, musste Konfigurationsdateien schreiben und kennen.
Der Einstieg entscheidet aber darüber, ob eine komplexe Anwendung überschaubar wirkt.
Die Projektübersicht zeigt Szenarien deshalb als Vorschaubilder statt als Dateinamen. Suche, Sortierung, Favoriten und zwei Ansichtsmodi erlauben unterschiedliche Arbeitsweisen.
Projekte, Testfälle, Szenarien
Ein Projekt bündelt Testfälle, und jeder Testfall wird mit einem Szenario simuliert. Angelegt werden sie aus der Testfall-Bibliothek, aus einem Szenario oder aus eigenen Dateien, sodass am Anfang eine Auswahl steht statt einer leeren Seite.
Die Listenansicht folgt derselben Systematik wie die Projektübersicht.
Suche, Sortierung und Favoriten funktionieren auf jeder Ebene gleich.
System under Test
System under Test benennt die Fahrzeuge, gegen die eine Testreihe läuft. In einem Projekt zur Notbremsassistenz können das mehrere Konfigurationen desselben Modells sein, die sich nur in einzelnen Parametern unterscheiden.
Jeder Eintrag zeigt deshalb drei Ebenen: das Modell als Vorschaubild, die Bezeichnung mit Farbvariante und darunter Kennung und Dateiname. Bei Fahrzeugen, die sich äußerlich kaum unterscheiden, ist die Datei oft das einzige eindeutige Merkmal.
Die Listenansicht ist hier die naheliegendere Wahl als das Raster, weil der Unterschied in den Angaben liegt und nicht im Bild. Beide Modi bleiben verfügbar, die Entscheidung liegt beim Nutzer.
Sensoren am Auto konfigurieren
Ein Fahrzeug trägt Kameras, Radare und Lidare an unterschiedlichen Positionen. Ihre Ausrichtung und Reichweite entscheidet darüber, was das System sieht, und lässt sich in einer Liste allein nicht beurteilen.
Die Konfiguration findet deshalb direkt am 3D-Modell statt. Orthografische Ansichten von vorn, hinten, oben und von der Seite zeigen jeweils, was aus dieser Perspektive relevant ist. Erfassungsbereiche werden als Flächen dargestellt, sodass Überschneidungen und Lücken in der Abdeckung sichtbar werden.
Liste und Modell sind miteinander verbunden. Jeder Sensor ist über Icon und Farbe seinem Typ zugeordnet und in beiden Darstellungen wiederzufinden. Gruppen halten auch umfangreiche Konfigurationen mit vielen Sensoren übersichtlich.
Viele Parameter und ein Muster
Jeder Sensortyp wird über eigene Größen beschrieben, und es sind viele. Über die Auffindbarkeit entscheidet die Reihenfolge, in der sie erscheinen.
Aufgeklappt wird ein Sensor in der Liste selbst, seine Einstellungen erscheinen direkt darunter. Der Aufbau bleibt über alle Typen hinweg gleich, mit Position und Ausrichtung oben, den typspezifischen Werten darunter und Ausgabe sowie Störeinflüssen am Ende.
Wer einen Sensor konfiguriert hat, muss sich beim nächsten nichts neu aneignen. Weil die Abschnitte an derselben Stelle stehen, bleiben Änderungen über Sensortypen hinweg vergleichbar.
Dichte Paramater und klare Ordnung
Die Parametergruppen folgen einem vorgegebenen Datenmodell. Die Aufgabe bestand nicht darin, eine eigene Ordnung zu erfinden, sondern eine fachliche Struktur navigierbar zu machen.
Drei Spalten zeigen so viele Werte gleichzeitig wie möglich, ohne dass Beschriftungen umbrechen oder Felder zu schmal werden. Weniger Spalten bedeuten mehr Scrollen, mehr Spalten gehen auf Kosten der Lesbarkeit.
Da sich die Spalten unabhängig scrollen lassen, bleiben Werte gleichzeitig im Blick, die im Datenmodell weit auseinanderliegen. Das Vergleichen ersetzt das Wechseln zwischen Ansichten.
Ein Szenario zusammenstellen
Ein Szenario besteht aus vielen Teilen: Verkehrsteilnehmer, Fußgänger, Ampelschaltungen, Straßennetz, Wetter und Zeit. Alle auf einer Seite zu zeigen wäre zu unübersichtlich.
Die Tab Bar hält beides zusammen. Sie zeigt jederzeit, woraus ein Szenario besteht, auch wenn gerade nur ein Teil bearbeitet wird. General bleibt der Einstieg mit den Angaben, die das Szenario als Ganzes beschreiben.
Szenario, Straßennetz und 3D-Umgebung sind als Dateien verknüpft, nicht fest eingebaut. Sie lassen sich ersetzen oder entfernen, ohne das Szenario neu anzulegen. Vorschaubilder machen die Auswahl visuell nachvollziehbar, Tags erlauben das Wiederfinden über eigene Kriterien statt nur über den Namen.
Wann ein Test bestanden ist
Ob ein Test bestanden ist, entscheidet ein Skript. Die Pass/Fail-Kriterien werden als Code definiert, weil sich Bedingungen wie Beschleunigungsverläufe nicht in Eingabefelder und Dropdowns abbilden lassen.
Die Aufgabe war nicht, den Code zu vereinfachen, sondern ihn einzuordnen. Jedes Kriterium erscheint als Zeile mit Name, Schalter und Quelltext daneben. Wer überfliegt, liest die Namen, wer prüfen will, liest den Code, ohne die Ansicht zu wechseln.
Die Aktionsleiste folgt demselben Muster wie bei den Test Cases. Sie wird erst bei einer Auswahl sichtbar und nennt die Anzahl der betroffenen Kriterien.
Die Skripte bleiben dabei austauschbar. Über den “Add” Button lassen sich neue Kriterien hochladen, über “Download all” oder die Auswahl einzelne exportieren. Was einmal geschrieben wurde, kann in anderen Test Cases weiterverwendet werden.
Jobs erstellen und überwachen
Simulationen laufen in der Cloud und brauchen Zeit. Bei mehreren Jobs muss erkennbar sein, welcher rechnet, welcher abgeschlossen ist und welcher fehlgeschlagen ist, ohne jeden einzeln zu öffnen.
Die Zählleiste fasst alle Zustände zusammen und filtert die Liste zugleich nach ihnen. Jeder Job trägt einen farbigen Status-Chip, der Fortschrittsbalken nimmt dieselbe Farbe auf. Neue Jobs entstehen an derselben Stelle, an der sie später verfolgt werden.
Fehler werden nicht in einen gemeinsamen Zustand zusammengefasst. Wo die Ursache liegt, entscheidet darüber, was als Nächstes zu tun ist.
Ergebnisse & Impact
Aus einer über Jahre gewachsenen Fachanwendung wurde eine klare, navigierbare Struktur
Szenarien und Testfälle lassen sich über die Oberfläche anlegen statt über Code, wodurch die Anwendung auch ohne Programmierkenntnisse zugänglich wird
Simulationen lassen sich einfacher konfigurieren, steuern und analysieren
Der Einstieg fällt leichter, der Aufwand für Schulung und Support sinkt
Ein Designsystem sichert die Konsistenz und lässt sich mit dem Produkt erweitern
Wiederkehrende Muster über alle Ebenen hinweg: Projekte, Test Cases, Bibliothek und Jobs folgen derselben Logik
Ausgezeichnet mit dem iF Design Award 2025 in der Kategorie Web Application
Zitat
"Die Kooperation mit UseTree war leicht und beeindruckend effizient. Unser Produkt wurde schnell modernisiert und optimal für heutige Anforderungen ausgerichtet. Vielen Dank an das gesamte UseTree-Team für die hervorragende Zusammenarbeit."
– Ramona Schwab, UX/UI Design Product Owner, Hexagon