Paper for Download - FKFS

Datenbankgestützte Szenario-Generierung
für das Testen aktiver kamerabasierter Fahrerassistenzsysteme
Florian Schmidt, Nico Hartmann
electronics solutions
MBtech Group GmbH & Co. KGaA
Wegenerstr. 5/1
71063 Sindelfingen
florian.schmidt@mbtech-group.com
nico.hartmann@mbtech-group.com
Abstract: Die Zunahme (teil-) autonom agierender und damit besonders
sicherheitskritischer Fahrerassistenzsysteme (FAS) stellt hohe Anforderungen
an die funktionale Absicherung. Aktive kamerabasierte FAS
können durch „Visual Loop“-Testsysteme bereits in frühen Entwicklungsphasen
in einem Closed-Loop-Verfahren verifiziert und validiert
werden. Um die erforderliche Vielzahl der möglichen Testfälle abdecken
zu können, müssen Test-Szenarien automatisch generiert werden. Dies
geschieht durch parametrierte Testklassen, die alle Parameter für die fotorealistisch
Darstellung der Fahrzeugumgebung berücksichtigen.
1 Testen aktiver kamerabasierter Fahrerassistenzsysteme
1.1 Automobilelektronik
In Fahrzeugen der Mittel- und Oberklasse sind typischerweise rund 40 bis 60 untereinander
vernetzte Steuergeräte verbaut, die verschiedenste Komfort- und Sicherheitsfunktionen
in Form von Embedded Software beinhalten. Die Komplexität ihrer
Funktionen steigert sich durch wachsende Kundenerwartungen, erhöhte Anforderungen
z. B. an Sicherheitsstandards, und neue technische Möglichkeiten [Gr05,
Ch09] kontinuierlich.
Die ständige Interaktion der Software mit den anderen Verkehrsteilnehmern und
besonders mit Menschen in ihrer Umgebung legen den benötigten hohen Qualitäts-
und Sicherheitsstandard fest. Dazu kommen vielfältige verschiedene rechtliche
Rahmenbedingungen, die Notwendigkeit einer einfachen Wartbarkeit, das Zusammenspiel
von Hard- und Software sowie vieler Zulieferer für die einzelnen Elektronik-Komponenten
sowie die Notwendigkeit von Ausfallsicherheit und Notlaufkonzepten
selbst im Fehlerfall.

Automotive Software ist also durch hohe Komplexität, komfort- und sicherheitsrelevante
fahrzeugspezifische Funktionen und daraus resultierend höchste Anforderungen
an die Softwarequalität gekennzeichnet. [Lig02]
1.2 Der Trend zu aktiven kamerabasierten Fahrerassistenzsystemen
Steuergeräte beinhalten Funktionen zur Entlastung des Fahrers, sei es durch Informationen,
Warnungen oder aktive Unterstützung. Aktive Fahrerassistenzsysteme 1
(FAS) unterstützen dabei in zunehmendem Maße durch autonome aktive Eingriffe.
Diese Systeme greifen im Notfall selbständig durch Lenken oder (Not-) Bremsen
direkt in die Längs- oder Querregelung des Fahrzeuges ein.
Die Umfelderfassung durch Sensoren wie Radar, Video oder Ultraschall ist dabei
der übliche Weg, um den Algorithmen Informationen zur Situationsanalyse und -
bewertung zu verschaffen. Die für eine aktive Fahrzeugreaktion verwendeten Aktoren
haben üblicherweise wiederum Einfluss auf die Umwelt und damit auf den
nächsten Sensormesswert, wodurch sich der Regelkreis schließt.
Beispiele für aktuell eingesetzte autonom aktiv eingreifende Systeme auf Basis von
Kamerasensorik sind Spurhalteassistenten, oder der sich noch in der Forschung befindliche
Ausweichassistent 2 , der je nach Beurteilung der Situation beim Erkennen
eines Fußgängers entweder bremst oder ausweicht um eine Kollision zu vermeiden
(Abbildung 1, links Notbremsung, rechts Ausweichen). Volvo bietet für den Stadtbereich
einen kamerabasierten Notbremsassistenten, Volkswagen parkt durch Kamerasensoren
unterstützt automatisch ein.
Die Sicherheit aller Verkehrsteilnehmer ist das höchste Ziel bei der Entwicklung
derart aktiv eingreifender Funktionen. Neben einer sorgfältigen und professionellen
Softwareentwicklung ist daher auch das Testen der Softwarequalität ein wichtiger
Schritt auf dem Weg zum Serieneinsatz eines mit diesen Helfern ausgestatteten
Fahrzeugs.
Abbildung 1: Ausweichassistent (Notbremsung, Ausweichen) [Quelle: Daimer AG].
1 engl. Advanced Driver Assistance Systems, ADAS
2 Im Juni 2009 von Daimler der Presse vorgestellt.

1.3 Funktionale Absicherung durch Hardware-in-the-Loop-Testverfahren
Eine während des Entwicklungsprozesses möglichst frühzeitige Absicherung der
implementierten Funktionen ist wünschenswert. Hardware-in-the-Loop (HiL) Tests
stellen die erste Möglichkeit der Validierung und Verifikation des gesamten Steuergeräts
oder kleinerer Steuergeräteverbünde dar. Dies geschieht im Labor noch bevor
die reale Umgebung des Steuergeräts, also das Fahrzeug, existiert. Das bedeutet, die
gesamte Umwelt auf die das Steuergerät durch seine Ausgänge Einfluss hat und die
darauf rückwirkt, muss simuliert werden 3 . Je exakter diese Simulation ausfällt, desto
realer wirken an den Eingängen die Stimulationen für die im Steuergerät eingebetteten
Funktionen.
Für aktive kamerabasierte Fahrerassistenzsysteme gibt es mehrere Möglichkeiten
der funktionalen Absicherung. Testfahrten mit realen Fahrzeugen durch die reale
Welt, oder das Wiedergeben aufgezeichneter Videos sind zwei herkömmliche und
erfolgreiche Methoden des Testens. Erstere erlauben jedoch nur eine stark eingeschränkte
Reproduzierbarkeit, sind aufwändig und ggfs. gefährlich. Zweitere sind
zwar reproduzierbar, die Rückkopplung der Reaktion eines aktiven FAS findet jedoch
nicht statt. Das gezielte Setzen oder Variieren von Parametern ist in beiden
Fällen kaum möglich. Wird beispielsweise ein FAS-System für eine Baureihe adaptiert,
so müssten alle Videos erneut aufgezeichnet werden, wenn die Kameraposition
im Fahrzeug bzw. relativ zur Straße nur um wenige Zentimeter verändert wird.
1.4 „Visual Loop” (VL)-Testsysteme
Um kamerabasierte Funktionen aktiver Fahrerassistenzsystemen nun in HiL-Tests
funktional abzusichern, muss deren Umwelt simuliert werden um die Kamerasensoren
zu stimulieren. Dies bedeutet, dass Bilder der Fahrzeugumgebung aus dem
Blickwinkel der entsprechenden Kamera(s) erstellt werden müssen. An diese Bilder 4
werden die konträren Anforderungen nach einer Berechnung in Echtzeit sowie nach
höchstem Realismus der Darstellungen gestellt.
Als Lösung stehen die „Visual Loop“ (VL) Testsysteme zur Verfügung, um durch
moderne Grafiksimulationen größtmöglichen Realismus bei geringstmöglichem Rechenaufwand
zu bieten [SS09]. „Visual Loop“ steht dabei für die visuelle Regelschleife
zwischen 3D-Grafik und Kamerasystem (vgl. Abbildung 2). Die (simulierte)
Umgebung löst eine aktive Reaktion des Steuergerätes aus, diese wiederum wirkt
auf die Umgebung und damit auf die als nächstes erzeugte Grafik. Typischerweise
werden hoch performante Grafik-Engines sowie Grafikkarten mit diversen visuellen
Optimierungsverfahren verwendet, um selbst auf PC-Hardware die geforderten
Bilddaten in Echtzeit zu erzeugen. Die Grafik wird entweder über die Anzeige an
einem Monitor und eine davon abfilmende Kamera oder direkt über bekannte Videoschnittstellen
in das FAS-Steuergerät eingespeist.
3 3
Um den Regelkreis zu schließen ist meist die Umweltsimulation in Echtzeit nötig.
4
Bei aktuellen Systemen fallen typischerweise 25 Bilder mit je rund 1 Megapixeln pro Sekunde zur Berechnung an, in einigen
Fällen auch deutlich mehr.

Steuergerät
Aktives FAS
Aktor
Kamera
Umgebungssimulation
3D-Grafik
Abbildung 2: Prinzip der „Visual Loop” (VL) Testsysteme.
1.5 Herausforderungen: Vielzahl der Testsituationen
Durch VL-Testsysteme können Testfälle unter Laborbedingungen frühzeitig im
Entwicklungszyklus getestet werden. Dabei ergeben sich zwei Herausforderungen:
• Zum einen können in VL-Systemen extrem viele Parameter beeinflusst werden.
Von der Position jedes einzelnen Objektes (wie bspw. Bäume, Häuser,
Verkehrsteilnehmer) über Wetterbedingungen (Tageszeit, Niederschlag) bis zu
einzelnen Eigenschaften wie Farbnuancen oder Geschwindigkeiten können beliebig
viele Details beliebig fein aufgelöst eingestellt werden. Aus dieser Fülle
an möglichen einzelnen Testfällen müssen die in der vorhandenen Zeit durchführbaren
nach gegebenen Kriterien sinnvoll ausgewählt werden.
• Zum anderen müssen die Testfälle üblicherweise manuell in für das jeweilige
VL-System spezifischen Editoren erstellt werden, was einen immensen Aufwand
bedeutet. Neben der Wiederverwendbarkeit und Durchgängigkeit der
Testfälle (was durch etablierte und offene Schnittstellenformate ermöglicht
wird) muss also die Erstellung automatisiert werden.
Dies lässt eine automatische Szenario-Generierung wünschenswert erscheinen.
2 Automatische Szenario-Generierung
In Abschnitt 2.1 werden die Elemente von Testfällen aus parametrierten Testklassen
für kamerabasierter FAS vorgestellt. Darauf folgt das Vorgehen der Testplanung
(2.2), die Szenario-Kombination (2.3) sowie die Szenario-Generierung (2.4).
Testplanung
Parametrierbare
Testklassen
Testszenario-
Generierung
Testfall am
VL-System
Abbildung 3: Überblick zur Anwendung eines VL-Systems.

In Abbildung 3 ist dies im Überblick dargestellt. Der gestrichelte Pfeil zeigt das ursprüngliche
Vorgehen an, manuell erstellte Testfälle direkt am VL-System umzusetzen.
Die durchgehenden Pfeile zeigen die durch die in Abschnitt 1.5 gezeigten Herausforderungen
motivierte automatisierbare Vorgehensweise.
2.1 Elemente von VL-Tests: parametrierbare Testklassen
Testfälle für umfelderfassende Systeme enthalten allgemein die folgenden 5 Kategorien
von Objekten, zusammengefasst zur „T-E-S-T-E“-Testfalldefinition:
• T – Test-relevant: spezielle Objekte, z.B. Verkehrszeichen / Fußgänger
• E – Environment: die Umwelt, das Wettersystem
• S – Surrounding: Umgebung, Straßenrand
• T – Track: die Straße
• E – Ego-Vehicle: Fahrzeug mit Blickwinkel der Kamera
Leere, d.h. unparametrierte „Testfall-Rahmen“ werden als „Testklassen“ bezeichnet.
Diese können auch bereits teilweise mit Parametern vorgefüllt werden, um dem
Anwender später die Erstellung von Testfällen mit Standard-Inhalten zu erleichtern.
2.2 Testplanung: Parametrierte Testklasse = Testfall
Eine Testklasse kann z. B. durch die Parametrierung mit den Informationen „T =
Fahrradfahrer, E = Nacht, S = Stadt, T = Nebenstraße, E = 30 km/h“ 5 als Testfall
erstellt werden.
Nun können Testfälle manuell geplant, erstellt und später umgesetzt werden. Eine
effektivere Möglichkeit stellt jedoch die bereits automatisiert erfolgende Testplanung
dar. Dazu wurde als Grundlage eine Datenbank konzipiert, die das o. g. T-E-S-
T-E-Gerüst für beliebig viele Objekte umsetzen kann. Das bedeutet, dass die entsprechende
Datenstruktur für Testfälle, ebenso wie die hierarchische Struktur aller
möglichen Parameter in einer erweiterbaren Datenbank angelegt wurde.
Ein Schwerpunkt lag hier auf der Erweiterbarkeit, da es später jederzeit möglich sein
muss, nicht nur z. B. einzelne Objekte, sondern auch komplett neue Umgebungen,
Wetterbedingungen, Straßeneigenschaften und Kameraparameter anzugeben. Wo
bisher bspw. die Umgebungstypen „Stadt“, „Dorf“, „Wald“ und „Wiese“ implementiert
wurden, wird langfristig „Küste“, „Gebirge“ etc. hinzu gefügt.
5 Dieses Beispiel ist stark vereinfacht, die Parameter der fünf Kategorien sind hierarchisch aufgebaut und detaillierter.

Die hierarchische Testfalldefinition erlaubt eine schnelle Angabe der Testfalldetails,
je nach Bedarf kann der Tester aber auch gezieltere Vorgaben zu relevanten Parametern
machen. Die exakte Angabe der Ausrichtung einer Laterne innerhalb der Stadt
mag z. B. für einzelne Testfälle wichtig sein. Meist möchte man diese Informationen
aber nicht für jedes Objekt angeben müssen, dann reicht die darüber liegende Information
aus um automatisch Standardwerte zu erhalten.
Ebenfalls Bestandteil aller Parameterwerte ist die Angabe ihrer Häufigkeit und
Wichtigkeit. Die Häufigkeit gibt dabei das Vorhandensein in der realen Welt 6 an, die
Wichtigkeit gibt eine Einschätzung 7 der Relevanz des Parameterwerts für die geplanten
Testsituationen an.
Durch Methoden der Versuchsplanung (engl.: Design of Experiments, DoE) folgte
daraufhin eine auf die Situation angepasste Testplanung. Sie verwendet eine aus
Häufigkeit und Wichtigkeit errechnete Priorität, sowie ggfs. je nach Test-Aufgabe
vorgegebene feste Parameterwerte um daraus die wichtigsten Testfälle zu generieren.
Mit der Möglichkeit, die Gesamtzahl der gewünschten Testfälle anzugeben,
sowie einem (Pseudo-) Zufallsgenerator zum Erhöhen der Testfallvarianz, ergibt
sich somit die für die jeweilige Teststrategie optimale Auswahl an Testfällen aus der
geradezu unendlichen Menge der theoretischen Möglichkeiten.
2.3 Kombinationsalgorithmik: Testfälle in Reihenfolge = Test-Szenario
Für die Umsetzung der in der Datenbank nur abstrakt vorliegenden Testfälle, müssen
diese in Form eines Szenarios angeordnet werden. Als Szenario wird die in VL-
Systemen üblicherweise rechteckige Terrain-Grundplatte bezeichnet, auf der später
alle 3D-Objekte dargestellt werden.
Um den zeitlichen Overhead durch das Laden vieler kleiner Szenarien zu minimieren
werden mehrere Testfälle in einem Test-Szenario angeordnet. Dabei ist es wichtig,
eine durchgängige Abfolge der Testfälle und damit eine durchgängige Fahrt des
Ego-Fahrzeug durch das Test-Szenario zu erreichen. Diese Anforderung ergibt sich
aus dem Wunsch, die Initialisierungs-Overheads des Testsystems und des Systemunder-Test
(also das Steuergerät des FAS) zu minimieren. Zusätzlich ergibt sich
dadurch der Vorteil, auch die Strecke „zwischen“ den Testfällen, sowie insgesamt
längere Streckenverläufe mitzutesten. Eine Voraussetzung für das Erreichen dieser
Durchgängigkeit ist es, dass sich die verschiedenen Parameter möglichst selten verändern
8 . Durch eine Gewichtung der Parameter und ihrer Unterschiede lässt sich
erreichen, dass (je nach Konfiguration) z.B. der Straßentyp seltener gewechselt wird
als die Umgebung der Straße, um damit den Eindruck einer realistischeren Fahrt
durch das Test-Szenario zu erzeugen. Ein Kombinationsalgorithmus geht nach diesen
Vorgaben durch die in der Datenbank abgelegten Testfälle und sortiert sie neu.
6 je nach geographischer Region ggfs. unterschiedlich
7 Entweder aus Expertenwissen, oder z. Β. abgeleitet von Verkehrs- und Unfallstatistiken
8 Mathematisch lässt sich dies durch die Minimierung der L1-Norm der Pfadlänge durch einen n-dimensionalen Raum vergleichen.
n steht dabei für die Anzahl Parameter auf der obersten Hierarchieebene.

2.4 Automatische Test-Szenario-Generierung zur Umsetzung am VL-
Testsystem
Nachdem die durch die Methoden der Versuchsplanung erzeugten und mit Hilfe des
Kombinationsalgorithmus in ihrer Reihenfolge optimierten Testfälle immer noch als
abstrakte Parametersätze in der Datenbank vorliegen, ist es wünschenswert sie auch
automatisch auf der Szenario-Grundplatte zu erzeugen. Dies ist üblicherweise bei
VL-Systemen ein sehr aufwändiger manueller Prozess, in dem jedes 3D-Objekt einzeln
positioniert werden muss.
Um die Testfälle möglichst effizient in dem Szenario zu platzieren und ihre Reihenfolge
beizubehalten, wurden verschiedene Ansätze untersucht. Die Platzierung innerhalb
realer Straßennetze 9 ergab keine günstige Ausnutzung des (durch technische
Randbedingungen beschränkten) Platzes innerhalb eines Szenarios (Abbildung 4
links). Ebenso erschien der Ansatz, die Testfälle auf Kacheln der Reihe nach im Szenario
zu platzieren als unbefriedigend, da der Aufwand der Berechnung und des Abfangens
von Problemen (wie Sackgassen) immens ist (Abbildung 4 Mitte).
Abbildung 4: Möglichkeiten der Anordnung von Testfällen in Test-Szenarien.
Realisiert wurde eine Lösung, die Testfall-Kacheln in einem Schachbrettmuster im
Szenario anordnet (Abbildung 4 rechts). Dabei hat jede Kachel einen definierten
Eingangs- und Ausgangspunkt, so dass ein durchgängiger Straßenverlauf unabhängig
vom Kachelinhalt gewährleistet ist. Innerhalb der Kacheln befindet sich die erzeugte
Testfallstraße (grau hinterlegt rechts in Abbildung 4) und eine als „Aorta“
bezeichnete Ringstraße, um wieder zum Ausgang der Kachel zu gelangen.
Am Rand der Straße wird ein durch den Straßenverlauf vorgegebenes Gebiet mit der
in der Datenbank zu dem jeweiligen Testfall hinterlegten Umgebung versehen,
bspw. wird für einen Wald der Boden des Terrains entspr. texturiert und es werden
typische 3D-Objekte eines Waldes wie Bäume und Sträucher platziert.
Die Informationen aller Testfälle zu Straße, Terrain, Umgebung und Wetter werden
durch ein Software-Werkzeug in einem für das VL-System verständlichen Szenario-
Format (z. B. in XML) abgespeichert und können damit entweder manuell nachbearbeitet
oder direkt im automatischen Testbetrieb kamerabasierter Fahrerassistenzsysteme
produktiv eingesetzt werden.
9 Die man bspw. aus Straßendaten der „Open Street Map“ Datenbank erzeugen kann

3 Zusammenfassung, Ergebnisse und Ausblick
Es wurde gezeigt, dass für die frühzeitige Absicherung aktiver kamerabasierter Fahrerassistenzsysteme
die VL-Testsysteme eine wichtige Säule darstellen. Um Testfälle
dafür effektiv und effizient zu erstellen, ist eine automatische Auswahl von Testfällen
durch die Parametrierung von Testklassen innerhalb einer Datenbank empfehlenswert.
Diese Testfälle können dann durch einen Kombinationsalgorithmus in eine
durchgängige Reihenfolge gebracht und automatisch als Test-Szenario abgespeichert
werden, wodurch das automatisierte Testen erheblich beschleunigt werden kann.
Erste Ergebnisse (vgl. Abbildung 5) zeigen, dass die gesamte Generierung eines
kompletten Test-Szenarios mit vielen tausend Objekten in mehreren Testfällen durch
die Anwendung von Werkzeugen der in diesem Beitrag beschriebenen Methoden
nur noch einen Aufwand von wenigen Sekunden verursacht.
Die nächsten Schritte liegen u. a. in der Vervollständigung der Datenbank, sowie in
der Übernahme bisher existierender Testfallkataloge.
Abbildung 5: Beispiel eines automatisch erstellten Testfalls mit Wald.
4 Literaturverzeichnis
[Ch09] Charette, R.: This Car Runs on Code. IEEE Spectrum Online,
http://www.spectrum.ieee.org, Feb. 2009.
[Gr05] Grimm, K.: Software-Technologie im Automobil. In (Liggesmeyer, P.;
Rombach, D., Hrsg.): Software Engineering eingebetteter Systeme.
Spektrum Akademischer Verlag, Heidelberg, Berlin, 2005.
[Lig02] Liggesmeyer, P.: Software-Qualität. Spektrum Akademischer Verlag,
Heidelberg, Berlin, 2002.
[SS09] Schmidt, F; Sax, E.: Funktionaler Softwaretest für aktive Fahrerassistenzsysteme
mittels parametrierter Szenario-Simulation. Jahrestagung der
Gesellschaft für Informatik 2009, Lübeck, September 2009.