Technische Artikel

Implementierung einer hybriden Vehicle-in-the-Loop-Testmethode für automatisierte Fahrfunktionen

Von Selim Solmaz, Virtual Vehicle Research GmbH


„Model-Based Design … ermöglichte es uns, unsere Bemühungen auf die Validierung des Hybridtests als Ansatz zu konzentrieren, anstatt uns mit Low-Level-Codierung und Implementierungsdetails zu befassen.“

Fortschrittliche Fahrerassistenzsysteme (ADAS) und Systeme für automatisiertes Fahren (AD) erfordern umfangreiche Tests in einer Vielzahl von Fahrszenarien, bevor sie sicher in Serienfahrzeugen eingesetzt werden können. Aufgrund der Einschränkungen der beiden heute allgemein verwendeten Ansätze können diese Tests für Automobilingenieure eine erhebliche Herausforderung darstellen. Der erste Ansatz, bei dem die AD- und ADAS-Funktionalität ausschließlich durch Simulation getestet wird, ist für die frühe Algorithmenentwicklung effektiv, erfasst jedoch keine realen Fahrzeugdynamik- und Hardwareeffekte, die die Algorithmusleistung erheblich beeinträchtigen können. Diese Einschränkungen entfallen zwar bei der Durchführung von Tests in einem echten Fahrzeug, doch dieser zweite Ansatz ist zeitaufwändiger, teurer und schwieriger zu replizieren – ganz zu schweigen davon, dass er in bestimmten Fahrsituationen potenziell unsicher ist.

Um die Lücke zwischen reiner Simulation und Tests im Fahrzeug zu schließen, hat mein Team bei Virtual Vehicle Research einen hybriden Testansatz implementiert. Dieser Ansatz wird durch die Einbeziehung von Vehicle-in-the-Loop-Tests definiert, die ein reales Fahrzeug mit virtuellen Fahrzeugen in einem Co-Simulationsrahmen kombinieren und so ein sicheres, realistisches Testen der ADAS- und AD-Funktionalität in simulierten Verkehrsszenarien ermöglichen (Abbildung 1). In einem Szenario mit plötzlicher Bremsung kann dieser hybride Testansatz beispielsweise angewendet werden, um Tests eines automatischen Notbremssystems durchzuführen, bei denen die Masse des realen Fahrzeugs, die Dynamik des Bremssystems, Hardwareverzögerungen und andere Nuancen, die in Modellen nur sehr schwer oder gar nicht erfasst werden können, vollständig berücksichtigt werden – und das alles ohne das Risiko eines Auffahrunfalls in der realen Welt.

Dauer des Videos 0:28

Abbildung 1. Das Cosimulations-Framework ermöglicht sicheres, realistisches Testen der ADAS- und AD-Funktionalität.

Wir validierten unsere hybride Testmethodik, indem wir intern entwickelte ADAS-Funktionen mithilfe von Model-Based Design mit MATLAB ® und Simulink® testeten. Diese Funktionen umfassen Quer- und Längsverfolgung sowie Fahrspurwechselentscheidungsfunktionen zur Unterstützung der adaptiven Geschwindigkeitsregelung (ACC), des Spurhalteassistenten (LKA) und der Trajektorienplanung (TP). Durch Model-Based Design waren wir in der Lage, ADAS-Funktionen schnell zu modellieren, zu simulieren und Code dafür zu generieren. Dadurch konnten wir unsere Bemühungen auf die Validierung des Hybridtests als Ansatz konzentrieren und nicht auf Low-Level-Codierung und Implementierungsdetails.

So funktioniert ein Hybrid-Test

Bei Hybridtests wird ein reales Fahrzeug, das mit AD- oder ADAS-Software und -Hardware ausgestattet ist, auf einem geschlossenen Testgelände betrieben, das frei von anderen Fahrzeugen oder Hindernissen ist. Anstatt den realen Verkehr zu erfassen und darauf zu reagieren, interagiert die Steuerungssoftware mit einer virtuellen Umgebung, die kontinuierlich in Echtzeit aktualisiert wird, während sich das Fahrzeug über das Testgelände bewegt. In unserem Testaufbau ist das Testfahrzeug, ein Ford® Mondeo Hybrid, mit einem ADAS-Kit ausgestattet, das die vollständige Kontrolle über Gas, Bremse, Lenkung und Schaltung des Fahrzeugs ermöglicht. Als Testgelände dient die ÖAMTC-Teststrecke Lang/Lebring bei Graz, Österreich (Abbildung 2). Darüber hinaus basiert die virtuelle Umgebung auf der Simulation of Urban MObility (SUMO), einem Open-Source-Paket zur kontinuierlichen Verkehrssimulation, wobei die statische Umgebung – einschließlich Verkehrsschildern, Fahrspurkoordinaten und anderen Infrastrukturelementen – mithilfe der Formatspezifikation ASAM OpenDRIVE® definiert wurde.

Ein Blick von oben auf das Testgelände, der die Teststrecke des realen Fahrzeugs und eine virtuelle Darstellung des Testgeländes zeigt.

Abbildung 2. Vogelperspektive des Testgeländes (oben) und seine virtuelle Darstellung (unten).

Während sich das Testfahrzeug auf der mehrspurigen Strecke bewegt, werden seine Position, Geschwindigkeit und Ausrichtung über GPS und andere Bordsensoren erfasst. Diese Informationen werden an die virtuelle Umgebung im Fahrzeug weitergegeben, die auf einem Industrie-PC läuft. Dort dienen sie zur Orientierung des Testfahrzeugs (Ego-Fahrzeug) innerhalb der Verkehrssimulation. Basierend auf der Simulation des Ego-Fahrzeugs und seiner Position relativ zu virtuellen Fahrzeugen und statischen Infrastrukturelementen generiert die virtuelle Umgebung eine Reihe von Objektlisten und Fahrspurerkennungsinformationen, die über eine CAN-Bus-Schnittstelle an die auf dSPACE® MicroAutoBox Echtzeit-Hardware laufende ADAS-Steuerungssoftware gesendet werden. Anhand der Objektlisten und Fahrspurinformationen trifft die Steuerungssoftware Entscheidungen hinsichtlich Bremsen, Beschleunigung, Spurwechsel und Bahnplanung. Anschließend sendet sie die zur Umsetzung dieser Entscheidungen erforderlichen Signale über den CAN-Bus an die Lenk-, Gas- und Bremsaktoren des Fahrzeugs (Abbildung 3).

Ein architektonischer Überblick über den Hybrid-Testaufbau, der zeigt, wo verschiedene Hardwarekomponenten und das reale Fahrzeug in den Arbeitsablauf der Co-Simulationsplattform integriert sind.

Abbildung 3. Architektonischer Überblick über das Hybrid-Test-Setup.

Modellieren, Simulieren und Generieren von Code für ADAS-Funktionen

Wir begannen mit der Entwicklung der ACC-, LKA- und Trajektorienplanungskomponenten unserer ADAS-Funktion – die wir „Motorway Chauffeur“ (MWC) nannten – unter Verwendung einer Reihe von Simulink-Modellen, die unsere Kollegen für eine andere ADAS-Anwendung entwickelt hatten. Wir haben diese Modelle angepasst, um die Objektlisten und Fahrspurinformationen aus der virtuellen Umgebung zu verwenden, und haben eine Reihe von Closed-Loop-Simulationen auf dem Desktop ausgeführt, um die grundlegende Funktionalität des Systems zu überprüfen (Abbildung 4). Außerdem haben wir Simulationen unserer ADAS-Steuerungsmodelle mit IPG CarMaker unter Verwendung der Integrationsplattform Model.CONNECT durchgeführt.

Ein Screenshot des Simulink -Modells einer der ADAS-Funktionen, der zeigt, wie das Fahrzeug bremst, Gas- und Gangwechsel einleitet und die Geschwindigkeit anpasst.

Abbildung 4. Simulink-Modell einer der Fahrzeugfunktionen.

Nachdem wir unsere ADAS-Funktionen per Simulation getestet hatten, verwendeten wir Embedded Coder® um aus unseren Modellen C++-Code zu generieren und den Code dann zur Vorbereitung der Tests im Fahrzeug auf der Zielhardware der MicroAutoBox bereitzustellen.

Durchführen von Tests im Fahrzeug und Nachbearbeiten der Ergebnisse

Wir haben das gesamte Hardware-Setup, einschließlich der MicroAutoBox-Hardware und des Industrie-PCs, im Testfahrzeug installiert (Abbildung 5). Mit dieser Konfiguration haben wir auf dem Testgelände zahlreiche Tests durchgeführt, um verschiedene ADAS- und AD-Funktionen zu bewerten, darunter Spurwechsel und Geschwindigkeitsänderungen als Reaktion auf Infrastruktur-Fahrzeug-Informationsnachrichten (IVIM) bei virtuellem Verkehr.

Die MicroAutoBox-Hardware und der Industrie-PC, wie sie im Kofferraum des Testfahrzeugs aufgebaut sind, und eine Tabelle mit einer Beschreibung der verschiedenen beschrifteten Komponenten.

Abbildung 5. Die MicroAutoBox-Hardware und der Industrie-PC im Testfahrzeug.

Nach den Testfahrten analysierten wir mit MATLAB die von den Bordsensoren aufgezeichneten Daten und erstellten Diagramme, die Geschwindigkeit, Lenkwinkel und Position des Fahrzeugs im Zeitverlauf zeigten (Abbildung 6). Diese Analyse war für unsere Forschungsziele von zentraler Bedeutung, da sie es uns ermöglichte, die Vehicle-in-the-Loop-Tests zur Bewertung der wichtigsten Leistungsindikatoren (KPIs) der ADAS-Funktionalität zu nutzen.

Drei Diagramme zeigen die sich ändernden Fahrzeugparameter in einem Auffahrtsszenario, einschließlich der Fahrzeuggeschwindigkeit im Zeitverlauf, des Fahrzeuglenkwinkels im Zeitverlauf und der Fahrzeugposition.

Abbildung 6. Diagramme der Fahrzeugparameter während eines Auffahrtsszenarios. (Abbildung mit MATLAB erstellt.)

Die Nachbearbeitung der Daten in MATLAB war auch hilfreich bei der Analyse der Probleme, die wir während unserer Tests entdeckt haben. Beispielsweise haben wir in einem Test die Objektlistendaten aus der virtuellen Umgebung durch ähnliche Daten ersetzt, die direkt von einer MobilEye ADAS-Kamera stammten. Beim Austausch der simulierten Daten mit Daten des realen Sensors stellten wir Schwingungen in den Steuersignalen fest. Unsere Analyse ergab, dass das Problem auf eine Verzögerung von etwa 300 Millisekunden in den Spurerkennungsdaten zurückzuführen war. Nachdem wir diese gleiche Verzögerung in unser Simulink Modell eingeführt hatten, zeigten nachfolgende Simulationen ähnliche Schwingungen. Wir konnten dann unseren Steuerungsalgorithmus ändern, um diese Verzögerung zu berücksichtigen, und Code neu generieren, um das Problem zu beheben.

Nächste Schritte

Unser Team entwickelt die von uns implementierte Hybrid-Testmethodik weiter. Wir prüfen derzeit mehrere Verbesserungen, darunter die Verwendung von 3D-Visualisierungen für Verkehrsszenarien anstelle der aktuellen Visualisierungen aus der Vogelperspektive. Eine weitere geplante Erweiterung ist die Einbeziehung physikalischer Sensormodelle in das Simulationsframework. Dies wird die Entwicklung und Vehicle-in-the-Loop-Tests von Wahrnehmungsalgorithmen unterstützen und die weitere Integration von Bordsensoren in Hybridtests ermöglichen.

Veröffentlicht 2024

Eingesetzte Produkte

Weitere Informationen