Echtzeit-Simulation zur Validierung autonomer Systeme und ADAS-Systeme

Wichtigste Erkenntnisse

• Straßen- und Tests nicht die Vielzahl sicherheitskritischer Fälle Tests , sodass der Großteil der Validierung auf wiederholbare, instrumentierte Simulationsläufe verlagert werden muss.
• Zur Überprüfung des Zeitverhaltens, der Latenz und I/O bei Serien-Steuergeräten Tests deterministische Echtzeitausführungen und hardware Tests erforderlich.
• Wählen Sie ADAS-Simulationslösungen aus, die auf deterministischen Regelkreisen, Schnittstellengenauigkeit, Szenariosteuerung und nachvollziehbarer Nachvollziehbarkeit basieren, und führen Sie anschließend systematische Regressionsprüfungen durch, um falsches Vertrauen zu vermeiden.

Physikalische Tests spielen Tests eine Rolle, können jedoch nicht die gesamte Validierungslast für Fahrerassistenzsysteme und autonomes Fahren tragen. Die Kombination aus seltenen sicherheitskritischen Situationen, engen Markteinführungszeitplänen und komplexen Sensorstacks zwingt die Teams dazu, den Großteil des Lernprozesses in einen ADAS-Simulations-Workflow zu verlagern, der kontinuierlich läuft und bei Bedarf wiederholt werden kann. Eine RAND-Analyse aus dem Jahr 2016 schätzte, dass 11 Milliarden Meilen Fahrtage erforderlich wären, um mit hoher statistischer Sicherheit nachzuweisen, dass ein automatisiertes Fahrzeug sicherer ist als ein menschlicher Fahrer.

„Dank Echtzeit-Simulationen können Sie ADAS-Validierungen wiederholbar durchführen, ohne dass dabei ein Sicherheitsrisiko im Straßenverkehr entsteht.“

Die praktische Herangehensweise ist einfach: Tests auf der Straße sollten bestätigen, was man bereits weiß, während deterministische Echtzeitsimulationen und Tests , Fehler aufzudecken, die Steuerung zu optimieren und die Vorteil frühzeitig zu testen. Teams, die einen Simulator für autonomes Fahren als primäres Validierungswerkzeug einsetzen, kommen mit weniger späten Überraschungen, klareren Sicherheitsargumenten und einer lückenloseren Rückverfolgbarkeit von der Anforderung bis zum Nachweis aus.

Die Validierungsziele gehen über den Tests hinaus

Tests können nicht das Maß an Abdeckung, Wiederholbarkeit und Beobachtbarkeit bieten, das für die ADAS-Validierung erforderlich ist. Seltene Interaktionen lassen sich nicht nach Bedarf planen, dasselbe Szenario auf Zentimeter-Genauigkeit kann nach einer Codeänderung nicht wiederholt werden, und Fehler lassen sich nicht sicher bis an die Grenzen ausreizen. Physische Fahrzeugflotten verwischen zudem die Kausalität, da Verkehr, Wetter und Fahrereingaben niemals zweimal identisch zusammenfallen.

Die Validierungsziele gehen mittlerweile weit über die Prüfung der Funktionsfähigkeit bei sonnigem Wetter hinaus. Es wird erwartet, dass Sie die Leistung unter Berücksichtigung von Sensorabweichungen, Fahrzeugbeladung, Alterung der Aktuatoren und verschiedenen Betriebsbereichen nachweisen und dabei einen lückenlosen Prüfpfad führen. Aufgrund dieser Erwartungen geht es beim Problem der Laufleistung weniger um Kilometerzahlen als vielmehr um Kombinatorik, bei der eine kleine Anzahl von Variablen Tausende aussagekräftiger Testpunkte erzeugt.

Simulation schließt diese Lücke, wenn man sie als Messsystem und nicht als Videospiel betrachtet. Man misst jedes Signal, erfasst genaue Zeitstempel und verknüpft die Anforderungen mit einer Pass/Fail-Logik. Dadurch wird die Validierung zu einem technischen Regelkreis, den man jede Nacht ausführen kann, anstatt zu einem Kalendertermin, der von der Fahrzeit, den Fahrern und den Wetterfenstern abhängt.

Warum ADAS und Autonome Systeme eine deterministische Echtzeitsimulation Autonome Systeme

ADAS- und autonome Fahrsysteme benötigen deterministische Echtzeitsimulationen, da das Timing Teil der Funktion ist. Wenn Ihr Planer, Ihr Controller, Sensor-und Datenfusion sowie die Aktoren nicht synchronisiert bleiben, kann das System in der Offline-Wiedergabe einwandfrei erscheinen und dennoch im geschlossenen Regelkreis versagen. Dank der deterministischen Ausführung können Sie darauf vertrauen, dass eine Änderung der Ergebnisse stammte Ihre software stammte und nicht auf schwankende Rechenzeiten.

Echtzeit ist von entscheidender Bedeutung, sobald man sich mit Rückkopplungsschleifen befasst. Die Abstimmung von Reglern hängt von exakten Verzögerungen ab, die Wahrnehmungslatenz beeinflusst den Bremsweg, und Jitter bei der Ablaufsteuerung kann den Übergang zwischen Funktionen destabilisieren. Ein ADAS-Simulator, der schneller als in Echtzeit läuft, kann für Suchvorgänge und die Datengenerierung nützlich sein, doch benötigt man dennoch eine deterministische Schleife, um zu überprüfen, wie sich das Steuergerät tatsächlich verhält, wenn das Fahrzeug in Bewegung ist.

Der Determinismus ermöglicht zudem zuverlässige Freigabe-Workflows. Sie können eine Szenarioversion, eine Simulatorkonfiguration und einen ECU-Build-Hash festhalten und dann Monate später, wenn ein Sicherheitsnachweis überprüft wird, genau denselben Test erneut ausführen. Eine solche Rückverfolgbarkeit ist schwer zu erreichen, wenn die primären Nachweise aus Ad-hoc-Straßenfahrten und manuell als „erfolgreich“ gekennzeichneten Clips stammen.

Hardware schließt die Lücke zwischen Modellen und Steuergeräten

Tests bilden die Brücke zwischen Modellen, die korrekt aussehen, und eingebetteten Steuerungen, die sich unter Zeit- und I/O korrekt verhalten. Sie decken Überlauf-, Quantisierungs-, Scheduling-, Busauslastungs- und Watchdog-Verhalten auf, das bei Desktop-Simulationen nicht auftritt. Außerdem zwingen sie Ihre ADAS-Simulation dazu, dieselben Takte und Schnittstellen zu berücksichtigen, die auch das Fahrzeug verwendet.

Ein konkreter Arbeitsablauf sieht wie folgt aus: Die Produktions-ECU, auf der die Bremsfunktion läuft, ist über CAN oder Automotive Ethernet mit einem Echtzeit-Simulator verbunden, der Sensordaten und Fahrzeugdynamik generiert, während durch Fehlerinjektion Sensorausfälle und zeitliche Schwankungen simuliert werden. Ingenieur:innen dann überprüfen, ob die ECU auch bei einer Wiederholung desselben Szenarios mit kontrollierten Parameterdurchläufen die Anforderungen an Bremsweg und Stabilität erfüllt, ohne dabei einen Testfahrer zu gefährden.

Gerade bei diesem Schritt – hardwaregeschlossenen Regelkreis mit echter hardware– stoßen viele Autonome Systeme auf ihre kostspieligsten Probleme in der Endphase. Hier werden Latenzbudgets sichtbar, Annahmen zu Schnittstellen korrigiert und Sicherheitsmonitore anhand messbarer Auslöser statt auf der Grundlage von Vermutungen abgestimmt. OPAL-RT-Systeme kommen hier häufig zum Einsatz, da ihr Ausführungsmodell auf deterministischer I/O basiert – genau das, was Ihr Labor benötigt, wenn Steuergeräte so laufen müssen, wie sie es im Fahrzeug tun.

Wichtige Szenarien, die Simulatoren für eine zuverlässige Bewertung nachstellen müssen

Ein Simulator schafft Vertrauen, wenn er das System an seinen Grenzen belastet, nicht wenn er nominale Fahrzustände wiederholt. Sie benötigen eine umfassende Abdeckung über die Grenzen des Betriebsbereichs, der Sensorunsicherheit und der Interaktionskomplexität hinweg sowie die Möglichkeit, Fehlerinjektionen durchzuführen, ohne dabei den Determinismus zu verlieren. Vertrauen entsteht dadurch, dass unter kontrollierten Schwankungen ein stabiles Verhalten gezeigt und anschließend dieselben Muster in begrenzten physikalischen Tests bestätigt werden.

Die Qualität eines Szenarios hängt von drei Faktoren ab: Genauigkeit, Variabilität und Beobachtbarkeit. Genauigkeit bedeutet, dass die Sensor- und Fahrzeugmodelle so gut sind, dass Steuerungs- und Wahrnehmungsfehler aus den richtigen Gründen auftreten. Variabilität bedeutet, dass man Ausgangsbedingungen, das Verhalten der Akteure, Reibung und Sensorrauschen auf strukturierte Weise variieren kann. Beobachtbarkeit bedeutet, dass jedes interne Signal protokolliert wird, damit Fehler erklärt und behoben werden können.

Das menschliche Verhalten ist ein wesentlicher Faktor für die Situationen, mit denen ADAS-Systeme umgehen müssen, und die Statistiken verdeutlichen, warum. Menschliche Entscheidungen tragen zu 94 % aller schweren Unfälle. Ein guter Simulator für autonomes Fahren testet unter Druck, wie Ihr System auf unvorhersehbare Handlungen reagiert, und sorgt gleichzeitig dafür, dass der Test wiederholbar, messbar und für Ihr Team sicher bleibt.

Wie man einen ADAS-Fahrsimulator-Stack bewertet

„Es deckt Überläufe, Quantisierungen, Ablaufplanung, Busauslastung und das Verhalten des Watchdogs auf, die bei einer Desktop-Simulation nicht auftreten.“

Ein ADAS-Fahrsimulator-Stack ist nur so gut wie seine Fähigkeit, Closed-Loop-Tests durchzuführen, Ihre Toolchain zu integrieren und aussagekräftige Ergebnisse zu liefern, die Sie verteidigen können. Sie sollten ihn wie eine Laborinfrastruktur bewerten, nicht wie eine Demo. Konzentrieren Sie sich auf deterministisches Timing, Schnittstellenabdeckung, Szenariomanagement und Datenintegrität und stellen Sie dann sicher, dass Ihr Team ihn ohne übermäßigen Aufwand warten kann.

Gehen Sie von Ihren Validierungszielen aus und arbeiten Sie rückwärts zu den Anforderungen hinsichtlich Rechenleistung, Genauigkeit und Konnektivität. Wenn Ihr Ziel die Freigabe auf ECU-Ebene ist, muss der Simulator die Echtzeitausführung mit denselben Bussen und Timing-Budgets unterstützen, wie sie auf dem Prüfstand zum Einsatz kommen. Wenn Ihr Ziel die Entwicklung von Wahrnehmungsfunktionen ist, muss der Simulator Sensormodelle, Ground Truth und wiederholbare Annotationspipelines unterstützen, die Ihren Metriken entsprechen.

• Deterministische Echtzeit-Planung mit messbarer End-to-End-Latenz
• I/O für Ihre Busse, Sensor-und Datenfusion sowie Aktorschnittstellen
• Versionskontrolle für Szenarien, Parameterdurchläufe und Hooks für die Regressionsautomatisierung
• Eindeutige Gültigkeitsgrenzen für Sensor- und Dynamikmodelle, die für Audits dokumentiert sind
• Datenerfassung, die Anforderungen mit den Ergebnissen (bestanden/nicht bestanden) und rückverfolgbaren Builds verknüpft

Häufige Fehler, die Teams bei der ADAS-Simulation machen und dadurch Probleme übersehen

Teams übersehen Probleme, wenn sie Simulationen als Vorzeigeprojekt und nicht als diszipliniertes Testsystem betrachten. Glänzende Grafiken können eine mangelhafte Beobachtbarkeit, nicht wiederholbare Durchläufe und nicht nachverfolgte Konfigurationsabweichungen verschleiern. Simulationen sind nur dann hilfreich, wenn man Fehler reproduzieren, deren Ursachen ermitteln und nachweisen kann, dass eine Korrektur auch bei kontrollierten Abweichungen Bestand hat.

Ein häufiger Fehler liegt darin, Validierungsziele mit einer nicht passenden Genauigkeitsstufe zu vermischen. Tests auf hoher Planungsebene, die unter idealen Bedingungen Sensor-und Datenfusion durchgeführt werden, Sensor-und Datenfusion erfolgreich verlaufen, während der eingebettete Controller versagt, sobald zeitliche Schwankungen und Schnittstellenprobleme auftreten. Ein weiterer Fehler ist die unkontrollierte Ausweitung von Testszenarien, bei der Teams Tausende von Testfällen ohne Abdeckungsmodell ansammeln, sodass Lücken bestehen bleiben, selbst wenn die Anzahl der Tests steigt.

Die leistungsstärksten Teams sorgen für eine enge Verzahnung zwischen Anforderungen, Szenariodesign und Evidenzqualität und nutzen die begrenzten Fahrversuche auf der Straße ausschließlich zur Bestätigung und Kalibrierung. Genau diesen Ansatz möchte OPAL-RT in der Praxis unterstützen: eine deterministische Echtzeitsimulation, die sich in einen Labor-Workflow einfügt, wiederholbare Ergebnisse liefert und den Fokus auf den Nachweis des Systemverhaltens legt, anstatt Kilometer zu sammeln.