ADAS-Testen mit vereinten Kräften Der geschickte Griff in die Werkzeugkiste

Die richtige Werkzeugkiste in der modernen Fahrerassistenz spielt eine entscheidende Rolle.
Die richtige Werkzeugkiste in der modernen Fahrerassistenz spielt eine entscheidende Rolle.

Für den Einsatz moderner ADAS sowie später des automatisierten Fahrens sind komplexe Tests nötig. Hierfür spielen die richtigen Werkzeuge eine entscheidende Rolle. Der Beitrag stellt einen Beispielaufbau vor, dessen Ziel es ist, diverse Szenarien zum Testen einer Notbremsfunktion zu beschreiben.

Sich sprichwörtlich mit Vollgas in der neuen ADAS-Welt zu bewegen, sollte für alle Beteiligte besser kein Risiko darstellen. Doch wie mit dem derzeit stattfindendem IT-Paradigmenwechsel umgehen, damit das Testen aller Funktionen wirklich sicher ist? Sind noch komplexere oder ganz andere Werkzeuge nötig? Oder ist der geschickte Einsatz bestehender Werkzeuge ein passender Ansatz?

Autonomes Fahren (AD) ist ein wesentlicher Treiber für innovative Technologien und Methoden in der Steuergeräte-Entwicklung im Automobil. Dort werden leistungsfähige Sensoren unterschiedlichen Typs wie Kameras, Radar oder Lidar eingesetzt. Gleichzeitig sind viele dieser Sensoren notwendig, um das Fahrzeugumfeld möglichst genau und unter allen (Witterungs-)Bedingungen zu erfassen. Das Verarbeiten der Daten dieser Sensoren erfolgt in Echtzeit und zunehmend nach Fusion der Sensordaten. Dafür kommen leistungsfähige Prozessoren und Grafikchips zum Einsatz.

Solche AD-Steuergeräte werden typischerweise mit Posix-Betriebssystemen wie QNX, PikeOS oder Integrity OS betrieben. Diese Plattformen erlauben es, Software-Umgebungen aus anderen IT-Domänen zu nutzen, die bisher nicht in der Automobil-Steuergeräte-Entwicklung genutzt wurden. Beispielsweise lassen sich jetzt Frameworks für künstliche Intelligenz und maschinelles Lernen wie TensorFlow oder Robot Operating System (ROS) auch für das Implementieren autonomer Fahrfunktionen nutzen.

Diese komplexe Hard- und Software-Umgebung wirft die Frage auf, wie Freigabeprozesse für AD-Systeme gestaltet werden können. Selbst die reine Software – und damit die AD-Funktionen – impliziert ein nicht-triviales Test- und Absicherungsverfahren.

Absicherungsmethodik für AD-Funktionen

Verschiedenen Schätzungen zufolge sind für die Absicherung von AD-Funktionen Testfahrten im Umfang von vielen Millionen bis Milliarden Kilometern erforderlich – der Großteil davon im Verkehr auf öffentlichen Straßen. Zieht man weitere Aspekte, wie die Gefährdung von anderen Verkehrsteilnehmern sowie die Reproduzierbarkeit von Tests hinzu, ergibt sich leicht, dass dieser Testumfang mit Versuchs- und Prototypenfahrzeugen in der realen Verkehrsumgebung praktisch nicht zu bewältigen ist. Damit ist die Verlagerung von Tests in das Labor und damit in eine virtuelle Umgebung, im Sinne von Umgebung für das zu testende System, erforderlich. Gleichwohl ist ein völliger Verzicht auf reale Tests im Straßenverkehr nicht angezeigt, weil die im Labor verwendeten Simulationsmodelle stets nur eine Annäherung der Realität liefern können.

Das Verlagern von Tests von der Straße in das Labor kann in verschiedenen Schritten und Methodiken erfolgen. Die Einbindung des realen Steuergerätes und gegebenenfalls der realen Sensoren in eine simulierte Fahrzeugumgebung (Hardware-in-the-Loop) erfordert die elektrische Anbindung des Steuergerätes und der Sensoren an ein entsprechend leistungsfähiges Echtzeitsimulationssystem, wie das VT System von Vector Informatik.

Nachdem der Steuergeräte-Software speziell in AD-Systemen eine große Bedeutung zukommt, liegt der Fokus der nachfolgenden Betrachtungen auf dem Software-Test ohne die Steuergeräte-Hardware (Software-in-the-Loop). Dieser Ansatz erlaubt auch eine einfache Parallelisierung der Tests sowie eine automatische Testablaufsteuerung, sodass auch Tests über Nacht und am Wochenende automatisch durchführbar sind.

Für den Test der Steuergeräte-Software im Labor wird einerseits ein Betrieb der Steuergeräte-Software ohne die reale Hardware nötig sein. Andererseits ist die Umgebung der zu testenden Software zu simulieren, also das Fahrzeug und dessen Verhalten, die Umgebung außerhalb des Fahrzeugs sowie die verwendeten Sensoren. Zusätzlich sind weitere Aufgaben abzudecken, wie etwa die Testautomatisierung. Für die einzelnen Teilaufgaben sind spezialisierte Werkzeuge von unterschiedlichen Herstellern verfügbar, in denen viel Erfahrung und Spezialwissen eingearbeitet sind. Daher erscheint eine Kopplung dieser Spezialwerkzeuge zu einer Gesamttestumgebung sinnvoll. Bei der Kopplung der verschiedenen Werkzeuge sind standardisierte Schnittstellen, wie Functional Mock-up Interface (FMI), sehr wertvoll. Vorteil: Der Anwender muss sich bei deren Verwendung nicht mit technischen Einzelheiten der Kommunikation zwischen den Werkzeugen befassen.

Im Folgenden wird ein prototypischer Aufbau vorgestellt, mit dem das System Under Test (SUT) in einer virtuellen Umgebung stimuliert wird. Zudem wird aufgezeigt, welche Möglichkeiten und Werkzeuge sich hierfür anbieten. Der Testaufbau wird anhand verschiedener Szenarien zum Testen einer Notbremsfunktion beschrieben.

Für das Anforderungs- und Testdaten-Management ist beispielsweise PREE¬vision als Prozess-Tool von Vector geeignet. Es verwaltet die Testspezifikationen sowie die Testergebnisse. Das eigentliche Test-Design, das heißt das Erstellen der Testfälle, wird hingegen mit vTESTstudio umgesetzt. Von dort werden sogenannte ausführbare Test-Units erzeugt, die dann wiederum in CANoe geladen und ausgeführt werden. CANoe stellt neben dieser Ablaufumgebung für die Tests auch die Restbussimulation für das Target bereit. Nach Testausführung werden die Testreports erstellt und im Testdaten-Management-System hinterlegt. Auf diese Weise ist die Nachverfolgbarkeit von der Anforderung bis zum Testergebnis lückenlos erreicht (Bild 1).

Das SUT ist ein Steuergerät, auf dem eine Notbremsfunktion implementiert ist. Es kommuniziert per SOME/IP (Scalable service-Oriented MiddlewarE over IP) mit den Sensoren und Aktoren und liegt als AUTOSAR-Adaptive-Steuergerät unter Linux vor. Das Gesamtsystem besteht aus einem Sensor-Gateway, das per SOME/IP mit dem Notbremssteuergerät kommuniziert. Dieses Sensor-Gateway bekommt Daten vom Geschwindigkeitssensor und vom Abstandssensor. Das Notbremssteuergerät selbst kommuniziert ebenfalls über SOME/IP mit dem Aktor-Gateway, das das Brems- und Gaspedal ansteuert (Bild 2). Sowohl das Sensor-Gateway als auch das Aktor-Gateway liegen als simulierte Knoten in der CANoe-Simulation vor.

Testfall für Notbremsfunktion

Die ADAS-Testumgebung besteht aus einem virtuellen Testfahrzeug und einem virtuellen Testfahrer, der auf einer simulierten geraden Teststrecke fährt. Der Fahrer fährt 20 s entlang der ebenen Straße ohne Lenkeingriff. Er fährt mit einer Anfangsgeschwindigkeit von 26 m/s (~ 93 km/h); das Gaspedal ist zu 50 Prozent gedrückt.

Zu Beginn einer Testfahrt steht ein anderes Fahrzeug als Hindernis außerhalb der Radarreichweite des Testfahrzeugs. Das Hindernisfahrzeug steht zunächst und beschleunigt mit voller Gaspedalstellung, sobald das Testfahrzeug zum ersten Mal die Geschwindigkeit von 0 m/s erreicht. Das Hindernisfahrzeug fährt in dieselbe Richtung wie das Testfahrzeug.
Zu den Tests werden folgende Erwartungswerte formuliert:

1. Innerhalb von 20 s findet kein Zusammenstoß statt
2. Vor Anhalten des Testfahrzeugs:

  • Solange das Testfahrzeug einen größeren Abstand zum Hindernis hat als die „kritische“ Distanz, ist das vom Aktor-Gateway empfangene Bremsdrucksignal 0 bar sowie das empfangene Gaspedalstellungssignal 50 Prozent.
  • Sobald das Testfahrzeug den kritischen Abstand unterschreitet, beträgt das Bremsdrucksignal 150 bar und das Gaspedalstellungssignal 0 Prozent (Notbremsfunktion überschreibt Steuersignale vom Fahrer).

3. Nach Anhalten des Testfahrzeugs:

  • Solange das Testfahrzeug den kritischen Abstand zum Hindernis unterschreitet, beträgt das Bremsdrucksignal 150 bar und das Gaspedalstellungssignal 0 Prozent. Sobald der Abstand des Testfahrzeugs zum Hindernis größer als der kritische Abstand ist, beträgt das Bremsdrucksignal 0 bar und das Gaspedalstellungssignal 50 Prozent (Steuersignal vom Fahrer).

Diese Erwartungswerte gilt es nun in ausführbare Testschritte zu übersetzen, die mit den vorgestellten Rahmenbedingungen getestet werden. Hierzu wird der Gesamttest in drei Phasen aufgeteilt. Die Randbedingung für die erste Phase ist, dass der Abstand zum Hindernis größer ist, als die kritische Distanz. Die kritische Distanz meint hierbei den Abstand, bei dem es ohne Notbremsung zu einem Zusammenstoß kommen würde. Die Testbeschreibung für diese Phase lautet: „Fahrzeug fährt mit zu 50 Prozent gedrücktem Gaspedal und einem Bremsdruck von 0 bar. Die Notbremsung ist deaktiviert“.

Die zweite Phase betrifft den Fall, dass der Abstand zum Hindernis die kritische Distanz unterschreitet. In diesem Fall soll das Testfahrzeug mit einem Bremsdruck von 150 bar bremsen. Das Gaspedalstellungssignal beträgt 0 Prozent. Die Notbremsung ist aktiviert. In der dritten Phase fährt das Hindernisfahrzeug los, sobald das Testfahrzeug einmal bis zum Stillstand abgebremst hat. Das Testfahrzeug soll in dieser dritten Phase – genauso wie in der ersten Phase – mit einer Gaspedalstellung von 50 Prozent und 0 bar Bremsdruck weiterfahren. Die Notbremsung ist deaktiviert.

Zusammenspiel der Werkzeuge

Die Aufgabenteilung zwischen den beteiligten Werkzeugen ist so gewählt, dass die Umgebungssimulation mit den Szenarien des Tools PreScan von Tass bereitgestellt wird, während CANoe zum einen die Kommunikation mit den Steuergeräten übernimmt und zum anderen die Ausführung der Tests. Die Simulationszeit wird von CANoe als Timing-Master vorgegeben. In PreScan werden dabei detaillierte Modelle von Fahrzeugumwelt sowie Fahrzeug und Fahrer gerechnet und darauf aufbauend und konsistent der Radarsensor für die Abstandserfassung simuliert. Dabei sind die Sensormodelle in verschiedenen Detaillierungsgraden von idealisiert bis physikalisch basiert auswählbar. Außerdem wird das gesamte Szenario in PreScan visualisiert (Bild 3). Als weiteres Werkzeug in diesem Verbund ist vTESTstudio zu nennen. Es ist die Entwicklungsumgebung für das Testdesign, in der Tests mit Hilfe von CAPL, .NET oder grafisch entwickelt werden können.

Für die Kommunikation zwischen CANoe und PreScan ist ein Ansatz auf Basis von Functional Mock-up Interface (FMI) gewählt. Dieser Ansatz kapselt die eigentliche Kommunikationsschicht, die über Named Windows Pipes erfolgt. Ein separates Programm arbeitet als Container für die verschiedenen Functional Mock-up Units (FMU) und als Server für die Named Windows Pipes. Dabei repräsentieren die einzelnen FMUs verschiedene PreScan-Experimente, die sich durch das Laden der entsprechenden FMU auf einfache Weise umschalten lassen (Bild 4).

Der besondere Charme der FMI-Lösung ist, dass sowohl CANoe als auch PreScan im Rahmen ihres Standard-Feature-Umfangs in der Lage sind, FMUs zu laden und in ihrem jeweiligen Prozessraum auszuführen. Lediglich der FMU-Container ist eine eigens für dieses Projekt entwickelte Komponente.