Wachsende Anforderungen

Wann das autonome Fahren zum Alltag im Straßenverkehr gehören wird, ist noch unklar. Es wird wahrscheinlich ein längerer, evolutionärer Prozess sein, da die Herausforderungen immens sind (Abb. 1) und alle parallel angegangen werden müssen:

• Hoher Software-Anteil: Die Kosten für Software werden im Vergleich zur Hardware immer dominanter. ADAS/AD-Funktionen werden größtenteils in Software implementiert und in ein Software-definiertes Fahrzeug (SDV) integriert, um ständige Verbesserungen durch Updates schnell an die Kunden weiterzugeben.
• Wachsende Bedeutung der künstlichen Intelligenz: Ein dominierender Teil des Software-Stacks wird auf KI basieren. Hier gibt es bereits ein breites Spektrum unterschiedlicher Ansätze, die von einem modularen AD-Stack mit einem KI-Perzeptionsanteil über durchgängige Visual-Language-(VL)-Blackbox-Modelle bis hin zu multimodalen und explorativen Visual-Language-Action-(VLA)-Modellen in fernerer Zukunft reichen.
• Zonale HPC-basierte Architekturen: Um den Anforderungen von SDV und AD gerecht zu werden, vollzieht sich auch in der E/E-Fahrzeugarchitektur ein revolutionärer Wandel, weg von vielen im Fahrzeug verteilten Steuergeräten für spezifische Aufgaben, hin zu zonalen Steuergeräte-Architekturen mit wenigen leistungsfähigen zentralen Hochleistungsrechnern (HPCs), die diese Vielzahl zentraler Fahrzeugfunktionen übernehmen, parallel verarbeiten und zudem Redundanz für einen sicheren Betrieb gewährleisten.
• Wachsende Integrationsanforderungen an Sensoren: Je nach AD-Level steigt der Integrationsgrad von Fahrzeugsensoren rapide an, oft mit einer großen Anzahl spezifischer Schnittstellen, insbesondere bei Kameras. Für Level 3 ist mit bis zu 30 Sensoren zu rechnen (6-8 Kameras, 3-5 Radaren, mindestens einem Lidar, bis zu 16 Ultraschallgeräten), für Level 4 mit weit über 40 (12 Kameras, 10 Radaren, 4 Lidaren, 20 Ultraschallgeräten).

Management des steigenden Validierungsaufwands

Aufgrund der wachsenden Herausforderungen werden die Kosten für die Validierung von ADAS/AD-Funktionen für Fahrzeughersteller und Zulieferer exponentiell ansteigen und in den kommenden Jahren schätzungsweise mindestens die Hälfte der gesamten Entwicklungskosten ausmachen. Verstärkt wird diese Entwicklung durch den enormen Druck, unter dem die Fahrzeughersteller stehen, neue Funktionen in immer kürzeren Abständen auf die Straße zu bringen.

Die Bewältigung des enormen Testaufwands in einem vertretbaren Zeitrahmen erfordert ein neues Konzept für das Validierungs- und Fahrzeugzulassungsverfahren. Dazu gehören unter anderem:

• Shift-Left-Tests: Beim Shift-Left-Testing finden die Testaktivitäten viel früher im Software-Entwicklungsprozess statt. Dies bedeutet eine deutliche Verlagerung von der traditionellen zur digitalen Validierung und Homologation. Ein Großteil der Tests und bis zu einem gewissen Grad auch die Sicherstellung der Konformität mit den geltenden Vorschriften verlagert sich von realen Testfahrten auf komplexe, aber wesentlich kostengünstigere physikalische Simulationsumgebungen. Die ADAS/AD-Validierungsstrategie umfasst SIL-, HIL/VIL- und Flottentests, die entsprechend ihrer jeweiligen Eignung parallel und bewusst überlappend eingesetzt werden.
• DevOps-basierte Entwicklung: Auf der Grundlage eines optimierten DevOps-basierten Entwicklungsprozesses (Entwicklungsschleife) mit durchgängiger Rückverfolgbarkeit, kontinuierlicher Software-Integration, Bereitstellung, Validierung, digitaler Zulassung und Over-the-Air (OTA)-Updates kann Software schneller, stabiler und kontinuierlicher bereitgestellt werden.
• Einhaltung von Normen und ISO-Standards: Neben der funktionalen Sicherheit nach ISO 26262 und der Cybersecurity (ISO/SAE 21434) liegt ein besonderer Schwerpunkt auf der risikobasierten Verifikation der Sicherheit nach SOTIF (ISO 21448). SOTIF (Safety of the Intended Functionality) konzentriert sich darauf, unbekannte Risiken auf ein akzeptables Niveau zu reduzieren, indem sie in bekannte und beherrschbare Risiken oder sogar in völlig sichere Zustände umgewandelt werden. Dies geschieht mit Hilfe von szenariobasierten Tests, die damit zunehmend an Bedeutung gewinnen und über Fahrzeugflotten sowie SIL und HIL Eingang in den Validierungsprozess finden.

Wie wird die Rollenverteilung zwischen SIL und HIL bei ADAS/AD-Tests aussehen?

Aufgrund der besseren Skalierbarkeit und Reproduzierbarkeit im Vergleich zu realen Testfahrten ist SIL, gefolgt von HIL, ein wesentlicher Bestandteil der ADAS/AD-Validierung. SIL-Tests, die für den Betrieb in einer Cloud-Umgebung ausgelegt sind, ermöglichen eine maximale Skalierbarkeit und werden übergreifend für Funktionstests der ADAS/AD-Wirkungskette von der Perzeption bis zur Bahnplanung eingesetzt. Die Testausführung kann leicht parallelisiert und parametrisiert werden, so dass eine große Anzahl von Szenarien in relativ kurzer Zeit bei entsprechender Verfügbarkeit von Cloud-Kapazitäten abgedeckt werden kann.

Wenn es jedoch darum geht, realistische Zeiteffekte zu modellieren und echte Hardware zu emulieren, stößt SIL heute an seine Grenzen. Die Modellierung von Hardware-Effekten ist zeitaufwendig, erfordert Expertenwissen und führt zu komplexen Modellen, die die Testausführung zur Laufzeit erheblich verlangsamen und damit die Vorteile von SIL zunichte machen. Die Verwendung echter Steuergeräte beseitigt dieses Problem bei HIL-Tests. Darüber hinaus bietet das HIL-Testen weitere Vorteile, z. B. die zuverlässige Echtzeit-Validierung von ADAS-Funktionalitäten und die Sicherstellung der Systemleistung, um nur einige zu nennen (siehe Abb. 3 für weitere Details).

HIL-Tests sind daher bereits ein etablierter und integraler Bestandteil der ganzheitlichen Validierungsstrategie für ADAS/AD und werden es auch in Zukunft bleiben, trotz der im Vergleich zu SIL höheren Kosten und Komplexität.
 

Was sind die wichtigsten Testansätze für die Validierung von ADAS/AD mittels HIL?

Für die Validierung von ADAS/AD auf dem HIL-Simulator gibt es zwei sich ergänzende Testansätze: Data Replay, auch bekannt als Hardware Reprocessing oder Open-Loop HIL, und Closed-Loop HIL, oft auch als ADAS HIL oder kurz als Raw Data HIL bezeichnet. Beide Testansätze greifen auf die gleichen Quelldaten zu, jedoch in unterschiedlichem Umfang. Die Quelldaten können sein:

• Die über den Fuhrpark erfassten realen Szenarien
• Reale Szenarien, die durch geeignete Augmentierungsmethoden wie KI erweitert werden, z. B. mit veränderten Wetterbedingungen wie Regen oder Schneefall
• Synthetische Szenarien, die von realen Bildern abgeleitet oder von Grund auf neu erstellt werden

Diese Rohdaten werden den zu testenden Systemen (SUT) über dieselben Sensorschnittstellen zugeführt, die später im Fahrzeug zur Verfügung stehen werden (Kamera, Radar, Lidar, Ultraschall). Darüber hinaus werden in der Entwicklungsphase häufig temporäre so genannte Design-for-Test (DfT)-Schnittstellen verwendet, die teilweise interpretierte oder abstrahierte Daten wie Objektlisten bereitstellen. Dies kann zu einer besseren Strukturierung und Vereinfachung der Testaufgabe beitragen und wird in modularen AD-Stacks verwendet, bei denen Perzeptions-, Sensorfusions- und Planungsalgorithmen unabhängig voneinander laufen.  

Data Replay und Closed-Loop-HIL werden aufgrund ihrer spezifischen Vorteile und je nach Art des ADAS/AD-Stacks mit unterschiedlichen Schwerpunkten eingesetzt. Data Replay wird überwiegend von der Perzeption bis zur Funktionsaktivierung genutzt, da hier der Fokus auf der Verwendung von realen aufgezeichneten Daten liegt. Closed-Loop-HIL hingegen ermöglicht die Validierung der gesamten Wirkungskette mit besonderem Augenmerk auf die Planung und die klassischen Regelungsungsalgorithmen.
 

 

Wie wird eine einheitliche Evaluierung sichergestellt?

Für die Evaluierung des Reifegrads des Testkandidaten und die Homologation der ADAS/AD-Funktionen ist es unerlässlich, die Testergebnisse einheitlich auswerten und vergleichen zu können, unabhängig vom Testansatz (SIL, HIL oder reale Testfahrt via Flotte) und über verschiedene Testmethoden (Data Replay, Closed-Loop-Test) hinweg. Dies geschieht vor allem auf der Grundlage von so genannten Key Performance Indicators (KPI). Dabei handelt es sich um SUT-spezifische Kriterien, die im Vorfeld von den verantwortlichen Funktionsträgern definiert werden und objektive Aussagen über die Leistungsfähigkeit, Robustheit etc. des SUT ermöglichen.

Effizientes Testen mit dSPACE

Für die Validierung von ADAS/AD in HIL bietet dSPACE ein umfassendes Lösungsspektrum (Abb. 5), das spezifische Anforderungen wie die synchrone Einspeisung von Sensordaten oder die physikbasierte Sensorsimulation in Echtzeit erfüllt. Weitere Details, insbesondere zu den vorgestellten Testansätzen und ein Ausblick auf die zukünftigen Herausforderungen der HIL-Validierung im Kontext von ADAS/AD, folgen im zweiten Teil dieses Artikels.