Innovationen bei der ADAS-/AD-Validierung: Die Entwicklung der HIL-Architekturen bei Valeo mit NI

​Im Mittelpunkt der Mobilitätsrevolution

​Das Streben, menschliche Fahrer durch fortschrittliche autonome Systeme zu ersetzen, verspricht mehr Produktivität, mehr Komfort und weniger Unfälle auf unseren Straßen. Dieses ehrgeizige Ziel ist jedoch mit Herausforderungen und Bedenken verbunden, insbesondere in Bezug auf kritische Themen wie Systemversagen und Sicherheit. Um ein höheres Maß an Fahrzeugautomatisierung zu erreichen, sind umfassende Tests in einer nahezu unendlichen Anzahl von realen Szenarien erforderlich.

Um diese Herausforderung zu meistern, sind Automobilunternehmen bestrebt, Technologien und Validierungsteststrategien kontinuierlich weiterzuentwickeln. Eines dieser Unternehmen ist Valeo, ein weltweit führender Anbieter von Automobiltechnologielösungen. Valeo hat bei der Gestaltung der Elektrifizierung, der Entwicklung fortschrittlicher Fahrerassistenzsysteme (ADAS, Advanced Driver Assistance Systems) und des autonomen Fahrens (AD, Autonomous Driving) eine wegweisende Rolle gespielt. Die Zusammenarbeit zwischen Valeo und NI zeichnet sich durch Innovationen und Engagement aus. Es sollen innovative Lösungen für eine sichere Zukunft entwickelt werden.

Überblick – ADAS und automatisiertes Parken (AP, Automated Parking)

​Mit zunehmender Komplexität von ADAS-Systemen wird es immer herausfordernder, diese Systeme nur in echten Fahrzeugen zu testen. Die virtuelle Validierung ist ein Branchentrend, der durch die Notwendigkeit getrieben wird, Testzeiten und -kosten zu reduzieren. Außerdem sollen Extremszenarien getestet werden, die unter realen Bedingungen eine Herausforderung darstellen.

​Diese Herausforderung besteht insbesondere bei AP-Systemen, die auf Sensorverbindungen beruhen, um eine virtuelle Karte der Fahrzeugumgebung zu erstellen, mit der autonome Einparkmanöver ermöglicht werden. Angesichts der Komplexität dieser Systeme ist eine umfangreiche Validierung erforderlich, die Tausende von Testfällen für jede Softwareversion umfasst. Der Test des gesamten Systems im Zielfahrzeug ist jedoch oft unmöglich, weil das Fahrzeug vor der Markteinführung nicht verfügbar ist.

Abbildung 1: ^{ECU-Architektur für automatisiertes Einparken von Valeo}

​

​Um diese Herausforderungen zu meistern, verwendet das DVS-Team (Driving Vision Systems) bei Valeo einen umfassenden Testansatz, der auf dem Open- und Closed-Loop der Hardware-in-the-Loop-Technologie (HIL) basiert. Dieser Ansatz beinhaltet die Durchführung von Tests der Software, die an der elektronischen Steuereinheit (ECU) außerhalb des Fahrzeugs durchgeführt werden. Dies geschieht unter Verwendung einer speziellen Testbank in der Laborumgebung:

• ​Open-Loop Replay HIL – Bei dieser Methode werden aufgezeichnete Daten aus dem realen Straßengeschehen in die Steuereinheit eingespeist. Sie wird hauptsächlich zum Testen von Computer-Vision-Algorithmen und Erkennungsraten verwendet.
• ​Closed-Loop Virtual HIL – Synthetische Sensordaten werden erzeugt und in die Steuereinheit eingespeist. Dieser Aufbau ermöglicht die Rückmeldung von der Steuereinheit, um das Fahrzeugverhalten genau zu simulieren.

​Tests im Fahrzeug bieten zwar reale Dynamik und Umgebungen, sind jedoch teuer, zeitaufwändig und unterliegen verschiedenen Bedingungen. Auf der anderen Seite bieten virtuelle HIL-Tests Vorteile in Bezug auf Skalierbarkeit, Automatisierung und Kosteneffizienz, es fehlt ihnen jedoch die Wirklichkeitstreue. Es sollte aber beachtet werden, dass sich HIL-Tests mit zunehmender Genauigkeit der Simulationsumgebung der Realität annähern.

​Die Rolle von Valeo Driving Vision Systems (DVS)

Die DVS spielen eine entscheidende Rolle bei der Entwicklung von Rundum-Sichtbarkeitssystemen für Fahrzeuge, bei denen Fahrzeugkameras mit Fischaugenlinsen, Ultraschallsensoren und ECUs zum Einsatz kommen. Diese Systeme sind Teil der Funktionen für automatisiertes Parken und Fahrerassistenz. Das Team für Testtools und Infrastruktur von Valeo ist verantwortlich für die Bereitstellung von Validierungstools über den gesamten Produktentwicklungszyklus hinweg – vom F&E-Design bis hin zu Aufzeichnungen im Fahrzeug, HIL-Tests und End-of-Line-Prüfungen (EOL) in der Produktion.

Entwicklung der HIL-Architekturen in der ADAS-/AD-Validierung

​Die dynamische Landschaft in diesem Bereich hat die kontinuierliche Entwicklung von HIL-Architekturen vorangetrieben. Diese Systeme wurden an die sich ändernden Anforderungen der Branche angepasst, um sicherzustellen, dass sie an der Spitze der neuen technologischen Fortschritte und der ständig wachsenden Anforderungen stehen.

​Derzeit nutzt das DVS-Team von Valeo drei verschiedene HIL-Architekturen, die gemeinsam mit NI entwickelt wurden und von denen jede spezifische Testfunktionen besitzt.

​Multisystem eXtension Interface (MXI)-basiertes HIL

​Diese erste Generation des vom Valeo-DVS-Team entwickelten HIL-Systems verwendet eine interne Simulations-Engine namens Vosstrex, die auf das Sensorset von Valeo zugeschnitten ist. Das System besteht aus einer Reihe von Modellen einer Fischaugenkamera und Ultraschallsensoren, die die synthetischen Daten vom Windows-basierten Simulations-PC an das NI-PXI-System und die ECU weiterleiten.

​Insbesondere auf dem Kamerasensor werden die synthetischen Daten der Simulations-Engine gerendert. Die Daten werden über MXI Express durch eine Interprozesskommunikation mit einer LabVIEW-Anwendung an das NI-PXI-System weitergeleitet. Im PXI-System fungieren die FlexRIO-FPGAs als Schnittstelle zwischen Software und Hardware. Sie emulieren authentische Kamerasignale und Low-Level-Daten, die dann an die ECU übertragen werden.

^{Abbildung 2: Diagramm der Closed-Loop-MXI-basierten HIL-Architektur}

​Die Architektur eignet sich besonders für den primären Anwendungsfall, beispielsweise Manöver mit niedriger Geschwindigkeit (z. B. Einparken), womit sie den spezifischen Anforderungen entspricht. Darüber hinaus bietet die Vosstrex-Simulation sowohl eine ausreichend visuelle Genauigkeit als auch eine solide Grundlage für weitere Verbesserungen.

​Diese Architektur steht jedoch vor gewissen Herausforderungen. Die wichtigste dabei ist die Durchsatzbeschränkung der MXI-Schnittstelle, die die Datenübertragung einschränkt. Darüber hinaus stellt das Fehlen einer Zeitsynchronisation zwischen den drei Schlüsselkomponenten – Kameras, Ultraschalldaten und Fahrzeugmetriken – eine weitere Einschränkung dar. Trotz dieser Herausforderungen ist das System weiterhin für die beabsichtigten Anwendungen mit niedriger Geschwindigkeit funktionsfähig. Die Fortschritte bei den Simulations-Engines von Drittanbietern bieten außerdem Möglichkeiten für noch realistischere Simulationen in der Zukunft.

​Derzeit verfügt Valeo über rund fünfzig HIL-Tester, die neun Valeo-Standorte weltweit unterstützen und Tests für mehr als zwölf OEM-Projekte bereitstellen. Dieses HIL-System half in einer frühen Projektphase bei der Einrichtung eines Systemvalidierungs-Frameworks und ermöglichte Valeo das vollständige Eigentum am Quellcode. Dank der Möglichkeit der Entwicklung in LabVIEW können im Verlauf der Projekte Verbesserungen am gesamten System vorgenommen werden, einschließlich der FPGA-Implementierung und der Simulations-Engine.

^{​Abbildung 3: HIL-Ökonomie an Valeo-Standort}

​HDMI-basiertes HIL

​Die Notwendigkeit, das MXI-basierte HIL-Architektursystem weiterzuentwickeln, wurde durch die Anforderung eines erstklassigen europäischen Originalherstellers (OEM) angestoßen. Teil der Anforderungen war die Simulation von zwölf High-Megapixel-Kameras, was eine Vervierfachung der Bandbreite des vorherigen Systems bedeutete, und die Verwendung von zwei verschiedenen Simulations-Engines, die unter Linux betrieben werden. In Zusammenarbeit mit NI hat Valeo eine Lösung entwickelt, die diese Kriterien erfüllt.

^{Abbildung 4: Zwölf-Kamera-Simulationsarchitektur}

Die Konfiguration in Abbildung 4 umfasst vier PCs und zwölf Grafikkarten, wobei jeder Grafikprozessor (GPU) für die Simulation einer einzelnen Kamera vorgesehen ist. Ein Linux-basierter PC führt die Simulation aus und betreibt das Kamerasensormodell für jede der zwölf Kameras. Die physischen GPU-Ausgänge sind über HDMI-Verbindungen mit den PXI-FPGAs verbunden und es sind mehrere Konvertierungen auf diesem Übertragungspfad involviert. Konkret ist eine anfängliche Konvertierung von HDMI zu SDI (Serial Digital Interface) enthalten, gefolgt von einer anschließenden Konvertierung von SDI zu MIPI CSI. Um diesen Konvertierungsprozess zu erleichtern, wird ein zusätzlicher FPGA in den Arbeitsablauf eingefügt. Nachdem diese Konvertierungen abgeschlossen sind, können die Daten in die Fahrzeug-Video-Schnittstelle für FPD-Link III (PXIe-1486) und GMSL2 (PXIe-1487) eingespeist werden, wobei die FPGAs als entscheidende Software-zu-Hardware-Schnittstellen fungieren, um die Sensorsignale nachzubilden, die als Eingaben für die ECU dienen.

^{​Abbildung 5: HDMI-basierte Kamerasensorsimulation}

Hinsichtlich der Bandbreite arbeitet das System mit einer Rate von 4,5 Gigabyte pro Sekunde, um Videodaten in die ECU einzuspeisen. Ein bemerkenswerter Vorteil dieses Setups ist die Simulationsunabhängigkeit. Obwohl in diesem Fall die Linux-basierte Simulations-Engine verwendet wird, könnte der gleiche Datenpfad Daten von anderen Simulationsanbietern unterstützen. Der zusätzliche FPGA, der für die Konvertierung von HDMI zu SDI erforderlich ist, erhöht zwar die Kosten, bietet aber auch die Möglichkeit zur Weiterverarbeitung der Bilddaten in diesem neuen Datenpfad. 

Diese Konfiguration ist jedoch mit gewissen Einschränkungen verbunden. Erstens bringt die HDMI-Schnittstelle Herausforderungen mit sich, da sie eine recht komplexe Konvertierungs-Toolchain erfordert, um von HDMI zu SDI und dann zu CSI umzuwandeln. Letztendlich gibt es eine ähnliche Einschränkung wie beim vorherigen Setup, bei dem keine Synchronisation zwischen den Kameradaten und dem Ultraschall oder einer zusätzlichen Fahrzeugbussimulation vorliegt. Vor allem kann dieses HIL-System nicht effektiv als Open-Loop Replay HIL eingesetzt werden, sodass es für die Wiedergabe von vorab aufgezeichneten Daten mit den GPUs ungeeignet ist.

^{​Abbildung 6: Architektur der Video Injection Pipeline}

RDMA-basiertes HIL

Die neueste von NI angebotene Generation wird als RDMA-HIL-System bezeichnet und verwendet RoCE (Remote Direct Memory Access over Converged Ethernet). Dieses System basiert auf RDMA, einer Schnittstelle, die für den nahtlosen Datenaustausch zwischen dem Host-PC und NI PXI verwendet wird. RDMA stellt eine Ethernet-basierte Verbindung her, die die Übertragung von Videodaten mit geringer Latenz und hoher Bandbreite ermöglicht und Speicherkopien überflüssig macht, indem eine direkte Verbindung zwischen dem Speicher des Computers und dem Speicher des PXI-Real-Time-Controllers ermöglicht wird. Aus High-Level-Architekturperspektive beginnt der Datenfluss mit dem Simulations-PC und wird über RDMA an den PXI-Real-Time-Controller übertragen, der sich in einem PXI-Chassis befindet, in dem sich die notwendigen FPGAs befinden, die für die Versorgung der Steuereinheit verantwortlich sind. Dieses System kann als Open- und Closed-Loop-Konfiguration betrieben werden, sodass die Wiedergabe von aufgezeichneten Daten sowie die Integration des Feedbacks in den Real-Time-Controller ermöglicht werden.

^{Abbildung 7: RDMA Open-Loop Replay HIL}

Diese Architektur liefert die höchste bisher beobachtete Durchsatzleistung mit einem einzigen RDMA-Modul, das bis zu 6,25 Gigabyte pro Sekunde an Datenübertragung bereitstellen kann. Ein weiterer wesentlicher Vorteil liegt in der einheitlichen Architektur sowohl für Open-Loop- als auch für Closed-Loop-HIL-Setups. Der Unterschied bezieht sich in erster Linie auf die Auswahl der Datenquelle, unabhängig davon, ob diese nun aus Speicherdateien oder Simulationen stammt. Dadurch wird die Wiederverwendbarkeit ermöglicht. Der Hauptvorteil liegt jedoch in der Einführung präziser Synchronisationsmechanismen, mit denen Videodaten nahtlos mit Fahrzeugbussignalen abgeglichen werden können. Diese Synchronisierung erstreckt sich über Kameras hinaus und deckt verschiedene Sensoren ab, wodurch ein umfassender und synchronisierter Datensatz bereitgestellt wird. Valeo prüft beispielsweise aktiv die Einbindung dieser HIL-Systeme und ersetzt im Rahmen der zukünftigen Strategie möglicherweise vorhandene MXI-HILs.

Bei der Verwendung von RDMA sind jedoch einige Faktoren zu berücksichtigen. Ihre Simulations-Engine muss mit RDMA kompatibel sein, was das Aufrufen einer RDMA-Client-Bibliotheks-DLL von der Simulations-Engine erfordert. In Fällen, in denen die Integration einer externen DLL in Ihre Simulations-Engine nicht möglich ist, können als Alternative HDMI-zu-RDMA-Umwandler eingesetzt werden. Mit diesem Ansatz wird im Wesentlichen ein Hybrid-Setup geschaffen, das Elemente aus der vorherigen Konfiguration kombiniert, jedoch mit den Einschränkungen der Einführung zusätzlicher Latenz und Jitter aufgrund des zusätzlichen Konvertierungsschritts (HDMI zu RDMA).

Eine umfassende Lösung: NI AD Software Development Kit (SDK)

Das auf RDMA basierende HIL-System von NI ist so konzipiert, dass es unabhängig vom Simulator ist und alle Kundenanforderungen erfüllt. Diese Vielseitigkeit wird durch die Verwendung des NI AD Software Development Kit (SDK) ermöglicht. Das SDK ermöglicht eine schnelle Integration der Emulations- und Simulationssoftware für den Sensorbus. Das bereitgestellte AD SDK besteht aus einer Reihe von Plugins, die eine konsistente Schnittstelle bieten und die Integration zwischen dem Simulatoranbieter und dem AD-HIL-System vereinfachen. Das SDK nutzt LabVIEW und gRPC-Unterstützung und bietet eine Simulations-API mit einer klar definierten Schnittstelle für die nahtlose Integration. Dieser Ansatz ermöglicht es Drittanbieter-Simulatorherstellern, mit ihren vertrauten Tools zu arbeiten und einfache Testpunkte zu erstellen, die die Fehlerbehandlung und CI/CD-Prozesse unterstützen. Dies wiederum trägt dazu bei, dass die Systemkommunikation zwischen der Simulationssoftware und dem ADAS-HIL-System weniger komplex ist, sodass Endnutzer und Endnutzerinnen die Wahl haben, welchen Simulatoranbieter sie nutzen möchten.

Zusammenarbeit zwischen NI und Valeo

Die Partnerschaft zwischen NI und Valeo umfasst eine Zusammenarbeit im Bereich F&E, einen frühzeitigen Zugriff auf NI-Prototypen, technische Serviceleistungen und die Entwicklung schlüsselfertiger HIL-Systeme. Diese Zusammenarbeit hat es Valeo ermöglicht, an der Spitze der ADAS-Validierung zu bleiben.

Die NI-PXI-Plattform ermöglichte dem Valeo-Team, weltweit standardisierte Validierungssysteme zu erstellen und Testkomponenten wiederzuverwenden, indem es die Modularität, genaue Zeitsynchronisation und Unterstützung für wesentliche Fahrzeugschnittstellen der Plattform nutzte.

Fazit

Die Entwicklung der HIL-Systeme bei Valeo in Zusammenarbeit mit NI zeigt, wie wichtig es ist, Testmethoden anzupassen, um die Herausforderungen zu bewältigen, die die immer komplexeren ADAS-/AD-Systeme mit sich bringen. Das RDMA-basierte HIL-System stellt einen bedeutenden Fortschritt dar und bietet einen hohen Durchsatz und Synchronisationsfunktionen. Valeo setzt weiterhin auf die Nutzung der NI-Systeme, um die sich ändernden Anforderungen der ADAS-/AD-Validierung zu erfüllen und die Zufriedenheit seiner Kunden in der sich ständig verändernden Automobilindustrie sicherzustellen.

Die eingetragene Handelsmarke Linux® wird gemäß einer Unterlizenz von LMI verwendet. LMI ist der exklusive Lizenznehmer von Linus Torvalds, dem weltweiten Eigentümer der Marke.