Durchgängige Entwicklung am Beispiel AEB-Systeme

Die moderne Automobilentwicklung wird zunehmend von einer zentralen Herausforderung beherrscht: Wie lassen sich hochkomplexe, sicherheitskritische Softwarekomponenten schneller bereitstellen, ohne dabei Qualitätsabstriche machen zu müssen? Besonders deutlich zeigt sich diese Herausforderung bei Fahrerassistenzsystemen (ADAS) wie dem automatischen Notbremsassistenten (AEB), bei denen bereits ein kleiner Fehler erhebliche Folgen haben kann.

Um zu veranschaulichen, wie diese Herausforderung bewältigt werden kann, folgt dieser Blogbeitrag einem durchgängigen Anwendungsfall über den gesamten Entwicklungsprozess, vom anfänglichen Ausfall bis hin zur Validierung, hinweg. Dabei wird hervorgehoben, wie eine Shift-Left-Strategie den Workflow grundlegend verändern kann.

Der Beispielfall beginnt in einem hochrealistischen Fahrsimulator, in dem ein Fahrzeug durch eine detaillierte Vorstadtumgebung fährt. Die Szene ist realitätsgetreu: eine Kreuzung, eingeschränkte Sicht und dann ein plötzliches, unerwartetes Ereignis. Kurz nachdem das Fahrzeug die Kreuzung passiert, tritt ein Kind aus einem nicht einsehbaren Bereich auf die Straße.

Auch wenn der Fahrer schnell reagiert, offenbart die Situation eine entscheidende Schwachstelle. Aufgrund eines Softwarefehlers greift das AEB-System nicht ein und führt beinahe zu einer Kollision, die in der Realität schnell in einem Unfall hätte enden können. Dieser Fehler löst in der Folge eine Rückrufaktion aus. Doch bevor ein Over-the-Air-Update bereitgestellt werden kann, muss der Fehler behoben und umfassend abgesichert werden.

Genau hier werden die Grenzen klassischer Absicherungsansätze deutlich. Reale Tests auf dem Prüfgelände sind teuer, zeitaufwendig und lassen sich nur begrenzt skalieren, wodurch sie sich zunehmend schwer mit den verkürzten Entwicklungszyklen moderner Fahrzeugprogramme vereinbaren lassen.

Um diesen Herausforderungen zu begegnen, werden mit dem Shift-Left-Ansatz Testaktivitäten in eine frühere Phase des Entwicklungszyklus verlagert. Potenzielle Probleme werden hierbei so früh wie möglich erkannt und behoben, anstatt auf die Absicherung in späteren Phasen zu warten.

Durch diese Umstellung wird der Entwicklungsprozess zu einer kontinuierlichen Absicherungspipeline, die sich in drei Hauptphasen

1. Model-in-the-Loop (MIL),
2. Software-in-the-Loop (SIL) und
3. Hardware-in-the-Loop (HIL) gliedert.

Jede Phase steigert das Maß an Realismus und Integration, ohne, dass die gemeinsame, einheitliche Testgrundlage verloren geht.

Nach der Behebung des AEB-Fehlers beginnt der Prozess mit der Absicherung des zentralen Bremsalgorithmus. Diese Phase, die als Model-in-the-Loop bezeichnet wird, konzentriert sich auf die funktionale Korrektheit des eigentlichen Algorithmus, der in der Regel in Umgebungen wie MATLAB entwickelt wird.

Ein wesentlicher Vorteil dieser Phase ist es, bereits frühzeitig realistische Testszenarien einbeziehen zu können. Genormte Testfälle, wie sie beispielsweise von NCAP definiert werden, können direkt in virtuellen Simulationsumgebungen wie CarMaker ausgeführt werden. Dadurch sind die Teststreckenbedingungen effektiv nachbildbar, ohne dass eine physische Infrastruktur erforderlich ist.

Um die Effizienz weiter zu steigern, wird die Simulation mithilfe von Cloud-basierten Plattformen wie VIRTO skaliert. So lassen sich große Mengen bedateter Testfälle – häufig auch über Nacht – parallel ausführen, wobei die Ergebnisse automatisch in die Entwicklungsworkflows zurückgespeist werden. Durch die Integration dieser Prozesse in CI/CD-Pipelines kann die Validierung durchgehend und hochautomatisiert erfolgen.

Am Ende dieser Phase ist der AEB-Algorithmus einzeln sowie unter einer Vielzahl von Bedingungen gründlich abgesichert worden, wodurch eine solide funktionale Grundlage entsteht.

Nachdem der Kernalgorithmus überprüft wurde, liegt der Fokus nun auf dem gesamten Software-Stack des Steuergerätes (ECU). In modernen Fahrzeugsystemen ist die AEB-Softwarekomponente Teil einer komplexen Architektur. Sie umfasst nicht nur die Anwendungssoftware, sondern auch die Laufzeitumgebung und grundlegende Softwareebenen, die häufig an die AUTOSAR-Standards angepasst sind.

In der Software-in-the-Loop-Phase bildet ein virtuelles Steuergerät diesen gesamten Software-Stack nach, sodass Tests in einer Closed-Loop-Simulation des Fahrzeugs und seiner Umgebung möglich sind. Plattformen wie Synopsys Silver ermöglichen die Ausführung virtueller Steuergeräte und deren nahtlose Integration in Simulationstools wie beispielsweise CarMaker.

In dieser Phase geht die Absicherung über die reine Funktionalität hinaus. Ingenieur*innen können analysieren, wie sich das System unter realistischen Kommunikations- und Fehlerbedingungen verhält. Um die Robustheit zu bewerten können Effekte wie z. B. Nachrichtenverzögerungen, verlorene CAN-Frames oder Prüfsummenfehler gezielt erzeugt werden. Je nach Systemkomplexität kommen hier unterschiedliche Integrationsmethoden zum Einsatz, die von der direkten Modellkopplung bis hin zur nachrichtenbasierten Kommunikation über virtuelle Bussysteme reichen.

Trotz dieser höheren Detailtiefe gewährleistet SIL die Effizienzvorteile eines virtuellen Tests: Simulationen können weiterhin schneller als in Echtzeit und parallel ausgeführt, sowie in automatisierte Pipelines integriert werden. Somit wird die umfassende Validierung des gesamten Softwaresystems möglich, noch bevor Hardware zum Einsatz kommt.

Auch wenn virtuelles Testen einen wesentlichen Teil der Validierung abdeckt, erfordern bestimmte Aspekte dennoch die Interaktion mit realer Hardware. Dazu gehören hardwarespezifisches Timing und in einer rein virtuellen Umgebung nicht vollständig erfassbare Integrationsmerkmale.

In der Hardware-in-the-Loop-Phase wird das reale Steuergerät mit einer in Echtzeit laufenden simulierten Fahrzeugumgebung verbunden. Bislang waren solche Konfigurationen teuer und nur begrenzt skalierbar – doch moderne Ansätze verringern diese Hürden erheblich.

Durch die Kombination einer Simulationslösung wie beispielsweise CarMaker mit einer Echtzeit-Hardwareplattform, z. B. Xpack, muss für die Simulation der weiteren Fahrzeugsysteme nur das Steuergerät an sich physisch vorhanden sein. Für eine effiziente Restbus-Simulation ist die gesamte Fahrzeug-Hardware also nicht erforderlich. Je nach Anwendungsfall reichen die Konfigurationen von umfassenden HIL-Prüfständen bis hin zu schlankeren Lösungen mit Standard-PCs und Kommunikationsschnittstellen.

Um die Effizienz weiter zu steigern, können mehrere HIL-Systeme als Teil einer HIL-Farm parallel betrieben werden: Die Testfälle werden dabei auf die Systeme verteilt, zentral verwaltet und in automatisierte Pipelines integriert. Dadurch wird die Skalierbarkeit mit der von virtuellen Umgebungen vergleichbar.

Was diesen Entwicklungsansatz auszeichnet ist seine Durchgängigkeit. In allen Prozessphasen kann das zu Beginn beschriebene kritische Szenario – ein Kind, das auf die Straße läuft – konsistent reproduziert und ausgewertet werden:

• MIL: Absicherung des Verhaltens des Algorithmus
• SIL: Testen der Interaktionen innerhalb des gesamten Software-Stacks
• HIL: Überprüfung des korrekten Systemverhaltens auf realer Hardware

Dieser nahtlose Übergang zwischen den Phasen stellt sicher, dass das Wissen und die Testabdeckung während des gesamten Entwicklungszyklus erhalten bleiben. An die Stelle einzelner Validierungsschritte tritt ein Prozess mit integriertem Workflow, bei dem jede Phase auf der vorherigen aufbaut. Zusätzlich werden redundante Validierungsmaßnahmen, die durch das mehrfache Testen von Anforderungen in verschiedenen Phasen entstehen, minimiert, und somit unnötige Doppelarbeit vermieden.

Dies ist ein wesentlicher Vorteil einer durchgängigen Teststrategie, die insbesondere in Kombination mit VIRTO ein hohes Maß an Transparenz und Rückverfolgbarkeit gewährleistet und es allen Beteiligten ermöglicht, genau nachzuvollziehen, welche Tests in welcher Phase, mit welchen Methoden und mit welchen Ergebnissen bereits durchgeführt wurden.

Die Shift-Left-Strategie verkürzt nicht nur die Entwicklungszeit. Sie verändert auf grundlegende Art und Weise, wie Qualität und Sicherheit in Automobilsystemen gewährleistet werden.

Durch eine frühzeitige und kontinuierliche Absicherung, die über mehrere Abstraktionsebenen hinweg erfolgt, werden Probleme nicht nur erkannt, sondern auch ihre Verbreitung über das gesamte System verhindert. Somit werden Risiken verringert, Kosten gesenkt und die Zuverlässigkeit insgesamt verbessert.

Zurück im Fahrsimulator wird die Wirkung greifbar. Das Szenario, das am Anfang einen kritischen Fehler offenbart hat, zeigt nun ein einwandfrei funktionierendes System: Sobald das Kind auf die Straße läuft, reagiert die AEB-Funktion sofort, und das Fahrzeug bremst rechtzeitig und sicher ab. Was zunächst beinahe schiefgegangen wäre, wird zu einer Erfolgsgeschichte – nicht, weil das Problem am Ende behoben wurde, sondern weil es gleich zu Beginn des Entwicklungsprozesses angegangen wurde.

Werfen Sie einen Blick ins Video für noch anschaulichere Eindrücke des beschriebenen Anwendungsfalls.