Steinbeis-Team testet komplexe Fahrszenarien
Die Funktionen in Fahrzeugen werden immer umfangreicher: Sie reichen von einfachen Assistenzsystemen bis hin zur Möglichkeit des autonomen Fahrens. Bei allen offensichtlichen Vorteilen bringen diese Funktionen allerdings auch Risiken mit sich, die während der Entwicklung in einer Simulationsumgebung getestet werden. Innerhalb der Simulation werden verschiedene Fahrszenarien mit Beschreibungssprachen abgebildet. Dabei entsteht je nach Szenario eine hohe Komplexität, die abhängig von den benötigten Fahrmanövern ist. Je höher die Komplexität, desto mehr steigt die Gefahr, dass das Szenario nicht die gewünschten Testanforderungen abdeckt und der falsche Eindruck eines positiv verlaufenen Tests entsteht. Key Performance Indicators (KPI) können die Qualität und Komplexität von Szenarien bewerten. Das Team der Steinbeis Interagierende Systeme GmbH (IAS) hat anhand von mehreren KPI zwei verschiedene Beschreibungssprachen für Testszenarien verglichen.
Neben offenen Standards wie OpenSCENARIO 1 und 2 sind analog zur Entwicklung von Fahrerassistenzsystemen verschiedene Sprachen zur Beschreibung von Umgebungs- und Testszenarien entstanden. Die Experten der IAS unterstützen die Entwicklung solcher Domain Specific Languages (DSL) und deren Betrieb seit mehreren Levels des SAE-Automatisierungsgrads für automatisierte Fahrsysteme.
KPI: Zentrale Werte in Simulationen
KPI sind notwendig, um die Effizienz der DSL für Umgebungs- und Testszenarien im Hinblick auf Entwicklung, Anwendung und Skalierbarkeit zu bewerten. Das Steinbeis-Team verglich die KPI von zwei Beispielen mit identischem Szenario, die jeweils mit zwei unterschiedlichen DSL beschrieben wurden. Als Beschreibungssprachen wurden OpenSCENARIO 1 und die von IAS mitentwickelte Sprache EBTB genutzt. Dabei wurden zwei Notationen verwendet: XML und eine verkürzte Notation (VN), die von beziehungsweise nach XML transformiert wird. Sowohl OpenSCENARIO als auch EBTB beschrieben das Fahrzeugverhalten zur Laufzeit innerhalb einer Simulation.
Zwei Referenzszenarien stellten erste Vergleiche am Beispiel der beiden Sprachen dar. Ein simples Szenario bildete einen einfachen Spurwechsel ab, ein komplexeres erweiterte dieses Szenario um einen Stopvorgang und eine Beschleunigung. Die Verwendung zweier Szenarien sollte Abhängigkeiten aufzeigen, um zu erkennen, ob Ergebnisse aus einem Szenario zufällig sind oder sich auf andere Szenarien reproduzieren lassen.
Das IAS-Team verglich in der Simulation folgende KPI:
- Anzahl Codezeilen
- Anzahl Events und Actions: durch die Sprache benötigte Ereignisse und Aktionen, um das gewünschte Szenario zu modellieren
- Anzahl Wertzuweisungen: Anzahl der Zeilen, in denen ein fester Wert gesetzt wird, wie beispielsweise Geschwindigkeit oder Beschleunigungszeit
- Anzahl Zeichen (mit und ohne Leerzeichen/Tabs)
- Verschachtelungs-/Einrücktiefe (maximale Tiefe): Anzahl der Tabs oder Verschachtelungstiefe
Zwei Szenarien im konkreten Vergleich
Die erste Tabelle (siehe Galerie) zeigt die gemessenen KPI-Werte für das simple Szenario „Spurwechsel“. Geringe Werte zeigen eine einfachere Beschreibung der Szenarien. In Klammern sind die relativen Werte zur VN angegeben. EBTB und OpenSCENARIO 2 haben hierbei die geringsten Werte.
Die zweite Tabelle zeigt in gleicher Form die Metriken des komplexeren „SpurwechselStopAndGo“-Szenarios. Erkennbar ist ein Anstieg bei den Codezeilen und ein noch größerer Anstieg bei der Zeichenanzahl im jeweiligen Testfall.
Die dritte Tabelle macht dies noch deutlicher, sie zeigt das Wachstum der Sprachen vom simplen zum komplexeren Szenario: OpenSCENARIO 2 arbeitet mit den wenigsten Codezeilen und ermöglicht so eine Szenarienbeschreibung mit minimalem Code. EBTBs Kurznotation fällt auf den zweiten Platz, zeigt aber geringeres Wachstum. OpenSCENARIO 1 benötigt im Versuchsaufbau die meisten Codezeilen und Zeichen, um die jeweiligen Szenarien zu beschreiben. Im Vergleich von „Spurwechsel“- und „SpurwechselStopAndGo“-Szenario ist hier ein enormer Anstieg an Zeilen und Zeichen zu sehen.
EBTB-Szenarien sind in der VN kompakter und geringer in ihrer Komplexität. Das führt das IAS-Team auf die XML-Notation zurück, da OpenSCENARIO 1 eine enorme Anzahl an Strukturelementen aufweist. In EBTBs verkürzter Notation sind diese auf ein Minimum reduziert. Bei komplexeren Szenarien mit vielen Anweisungen, Aktionen und Events wird dieser Unterschied immer größer.
Simulation macht Komplexität sichtbar
Die Beispielszenarien zeigen deutlich, dass die Komplexität bei steigender Zahl von Anweisungen zunimmt. Dabei ist es für einen Testmanager von Vorteil sich der Komplexität bewusst zu sein: Durch eine quantitative Bewertung anhand von KPI können Entscheidungen getroffen werden, die künftige Testszenarien beeinflussen. Tests mit einer hohen Komplexität können dahingehend untersucht werden, diese präziser zu konzipieren, sodass möglichst keine unerwünschten Nebeneffekte auftreten. Vor allem im Hinblick auf die immer komplexer werdenden Fahrzeugfunktionen ist es wichtig, die genauen Testanforderungen abzudecken, ohne dass diese von Nebeneffekten beeinträchtigt werden.
Kontakt
Dr. Daniel Ulmer (Autor)
Geschäftsführer
Steinbeis Interagierende Systeme GmbH (Herrenberg)
www.interagierende-systeme.de
Jordi Beeck (Autor)
Mitarbeiter
Steinbeis Interagierende Systeme GmbH (Herrenberg)
www.interagierende-systeme.de
Daniel Elsenhans (Autor)
Mitarbeiter
Steinbeis Interagierende Systeme GmbH (Herrenberg)
www.interagierende-systeme.de
217079-44