HiL-Testsysteme im Fahrzeugbau nach ISO 26262

Anbieter zum Thema

SET GmbH

SET Power Systems GmbH

MicroConsult Academy GmbH

ET System electronic GmbH

MES Electronic Connect GmbH & Co. KG

Multi-Domain-Simulationen mit HiL-Systemen sind in der Luftfahrt bereits Alltag. Auch die Automobilbauer profitieren von Echtzeitsimulationen. Dazu notwendig sind leistungsfähige und standardisierte Prüfsysteme.

Die Fahrassistenzsysteme oder auch Advanced Driver Assistance Systems, kurz ADAS, in modernen Fahrzeugen werden zunehmend komplexer und autonomer. Je mehr Autorität diese Systeme haben, desto mehr bewegen sie sich im Bereich hochkritischer Sicherheitsanwendungen. Das stellt die Automobilindustrie gerade bei der Sensor-Fusion vor Probleme. Damit die Daten zuverlässig qualifiziert werden können, müssen die Systeme nach den Normen der ISO 26262 getestet und validiert werden. Labortests in simulierten Hardware-in-the-Loop-(HiL-)Echtzeitszenarien, die in der Luftfahrt schon lange Standard sind, werden jetzt auch in der Automobilindustrie immer wichtiger. Analog zur wachsenden Komplexität der ADAS steigen auch die technischen und qualitativen Anforderungen an die Testsysteme.

Mit Hardware-in-the-Loop-Testsystemen können die Entwickler die erforderlichen Tests zur Qualifikation der Fahrassistenzsysteme schon vorab im Labor testen. Schließlich sind Testfahrten auf der Straße nicht nur teuer, zeitaufwendig und schwer veränderbar, sondern auch mit Risiken verbunden. Eine Validierung der Systeme vorab im Echtzeitszenario bietet verschiedene Vorteile: Sie ist zeitlich unabhängig, reduziert die Testzeiten auf der Straße und verkürzt damit auch die Entwicklungszyklen. Das spart Kosten und minimiert das Schadensrisiko.

Im Labor können Testfälle flexibel kreiert, Szenarien beliebig variiert und Fehler eingespielt werden. Grobe Fehler oder Fehlfunktionen kann man so bereits vorab beheben, um nach erfolgreicher Validierung im Labor reale Versuchsfahrten machen zu können. Denn solange nicht komplett nachgewiesen werden kann, dass die HiL-Simulationen zu 100% der Realität entsprechen, muss man zur finalen Validierung auch weiterhin auf die Straße. Je häufiger dort jedoch die gleichen Ergebnisse erzielt werden wie zuvor im Labor, desto stärker steigt auch das Confidence-Level der Labortests.

Multi-Domain-Simulationen in der Luftfahrt sind Standard

In der Luftfahrtindustrie gehören Multi-Domain-Simulationen mit HiL-Systemen schon lange zum Standard. Große Teile der Validierung und Verifikation werden durch Echtzeitsimulation am Originalequipment abgebildet. In der HiL-Simulation wird dort das Verhalten des Flugzeugs in Echtzeit gegenüber den Line Replacement Units (LRUs) abgebildet. In einem Flugzeug findet Sensor-Fusion ganz nativ statt: Jedes Flight-Control-System betreibt de facto Sensor-Fusion, indem es die unterschiedlichen Informationen der Sensoren validiert, überprüft und daraus die korrekte Reaktion ableitet und durchführt.

Auch im Automobilbau sind HiL-Simulationen zur Validierung schon lange üblich. Nie zuvor jedoch mussten die Szenarienmodelle der Fahrzeugumgebung so detailliert, komplex und präzise sein wie heute. Um Sensor-Fusion-Systeme in HiL-Umgebungen testen zu können, müssen die Modelle verschiedene Szenarien von Oberflächen und Trägheitssituationen des Fahrzeugs, der Straße, der gesamten Verkehrsumgebung und dem Verhalten der anderen Verkehrsteilnehmer präzise abbilden können.

Nicht jeder Hersteller verwendet das gleiche Szenarienmodell für die Simulationen. Daher müssen die HiL-Systeme auch in der Lage sein, mehrere Szenarienmodelle unterschiedlicher Hersteller parallel laufen zu lassen – beispielsweise IPG CarMaker als Szenarienmodell zusammen mit anderen Modellen wie TASS PreScan. Hier ist Flexibilität gefragt, denn auf allen Ebenen sollen Fehlermodi flexibel abgebildet und Szenarien beliebig verändert werden können.

Stärker vernetzte Domains, Schnittstellen und Interfaces

Auch die Komplexität der einzelnen Steuergeräte sowie die Vernetzung der Domains untereinander steigt massiv an. Um die Sensor-Fusion-Unit im Fahrzeug mit allen relevanten Daten für ihren Algorithmus zu versorgen, benötigen die Sensoren immer mehr und detailliertere Informationen über ihre Umgebung. Für den Test hochauflösender Sensoren müssen die Targetsimulatoren in den Szenarienmodellen des HiL-Testsystems immer komplexer und hochauflösender werden. Auch die physikalischen Domains, Schnittstellen und Interfaces nehmen exponentiell zu und verändern sich rapide. Darüber hinaus wandelt sich auch die Backbone-Kommunikation des Testings: Man nutzt nicht mehr nur CAN, sondern CAN-FD, Ethernet und BroadRReach oder MostBus für Entertainment-Funktionen.

Beim HiL-Testing von ADAS-Funktionen, insbesondere der Sensor-Fusion-Funktionen, liegt die besondere Herausforderung darin, diesen stärker vernetzten Funktionen synchron eine Echtzeitumgebung zu simulieren. Denn die Algorithmen der Sensor-Fusion-Unit, die die Fahrzeugumgebung auswerten, müssen die Simulationen als real wahrnehmen und überall synchron in Echtzeit das gleiche Szenario sehen. Dadurch ist die Komplexität der HiL-Systeme in allen Dimensionen rapide angestiegen. Um den neuen Herausforderungen begegnen zu können, bedarf es leistungsfähiger, standardisierter und modular aufgebauter Prüfsysteme, die flexibel anpassbar sind auf die jeweiligen Bedürfnisse und Testanforderungen.

Ein großer Vorteil offener Plattformen ist, dass sie modular erweiterbar und anbieterunabhängig sind. Über standardisierte Messtechnik-Plattformen wie PXI können sehr viele Signalarten abgebildet werden. Mit einer standardisierten Signalkonditionierung wie SLSC (= Switch Load and Signal Conditioning) lassen sich komplexe Funktionen wie Fault Insertion oder Sensorsimulation auf einer standardisierten Plattform realisieren – so müssen diese nicht mehr individuell pro Projekt entwickelt werden. Dank dieser zwei offenen Plattformen kann man auch individuell benötigte spezielle Funktionalitäten in die Plattform integrieren, ohne die Grundarchitektur zu verändern.

Closed-Loop-Testszenarien zur Validierung der Daten

Die gesamte Sensorik, die das Fahrzeug für ADAS-Funktionen benötigt, kann auf HiL-Systemen an der elektrischen oder physikalischen Schnittstelle nachsimuliert werden. Entweder werden die Sensoren auf Echtzeitsystemen elektronisch auf Schnittstellenebene simuliert oder die realen Sensoren physikalisch über Targetsimulatoren stimuliert. Das gleiche Szenario wird zeitsynchron in allen Schnittstellen auf der Sensor-Fusion-Unit abgespielt. Das geschieht mit Mulit-Level- und Multi-Domain-Simulationen, die beispielsweise gleichzeitig Radarsignaturen abspielen, den Lidarsensoren Targets simulieren und der Kamera ein Bild darstellen. Diese Informationen werden in Echtzeit aus der Umgebungssimulation extrahiert.

Synchron dazu werden die Reaktionen des Sensor-Fusion-Steuergeräts in die Simulationsumgebung zurückgespeist, um die Simulation entsprechend zu beeinflussen und somit Closed-Loop-Testszenarien zu ermöglichen. Durch vielfältige Möglichkeiten der Testumgebung zur Fehlerinjektion auf physikalischer, Protokoll- und Modellebene lassen sich komplexe Fehlerfälle reproduzierbar darstellen, um das Systemverhalten des Prüflings unter verschiedensten Fehlereinflüssen abzusichern.

Je autonomer die Fahrassistenzsysteme agieren, desto mehr werden sie zu hochkritischen Sicherheitsanwendungen. Um einen belastbaren Nachweis ihrer Zuverlässigkeit und Sicherheit zu erbringen, müssen die Systeme nach dem Standard ISO 26262 getestet und validiert werden. Risiken werden je nach Bedeutung mit einer ASIL-Einstufung von A bis D bewertet. Die ISO 26262 schreibt den OEMs und Zulieferunternehmen detailliert vor, welche Entwicklungsprozesse einzuhalten und wie diese Prozesse abzubilden sind. Das betrifft beispielsweise die Tiefe der Qualifikation und Validierung bis hin zur Beschreibung der Safety Items des sicherheitskritischen Systems. Das hat die Entwicklungsprozesse im Automobilbau massiv verändert.

Analog zu den steigenden Sicherheitsanforderungen für die Assistenzsysteme nimmt auch die Komplexität und Sicherheitsbeurteilung bei der Validierung der Testsysteme selbst zu. Dort muss nun mit hohen Wahrscheinlichkeiten sichergestellt werden können, dass die Abbildungen, Simulationen und Simulationswerkzeuge dem entsprechen, was das Steuergerät erwartet.

Wurzeln der Sicherheitsprozesse liegen in der Luftfahrt

Die Entwicklungs- und Testprozesse in der Automobilindustrie ähneln durch die ISO 26262 mittlerweile immer stärker den hochsicherheitskritischen Systemen in der Luftfahrt, die durch die hohe Autonomie der Flugsysteme nach den strengen Regularien der RTCA-DO-178 und RTCA-DO-254 getestet werden. Denn schon lange gibt es Flight-Control-Systems, die Flugzeuge autonom fliegen können. Im Automobilbau gibt es noch kein Steuergerät, das ein Fahrzeug völlig autonom fährt. Perspektivisch jedoch sollen autonome Systeme im Level 3 und 4 ganze Strecken autonom zurücklegen können und dabei 100% Lenk-, Beschleunigungs- und Bremseingriff haben. Die logische Schlussfolgerung: Die Systeme müssen mit steigender Komplexität auch deutlich sicherer werden.

Vergleicht man die Normen, finden sich große Ähnlichkeiten, beispielsweise bei den Entwicklungsprozessen in Soft- und Hardware, den Testfällen, Sicherheitslevels oder Anforderungen an die Zuverlässigkeit. Die Unterschiede stellen sich oft nur in den Wahrscheinlichkeiten dar. Hat in der Luftfahrt ein Flight-Control-System eine Autorität von 100%, muss es mit einer Sicherheit von 10^-12 zuverlässig funktionieren – im Automobilbau sind es 10^-8.

Nach ISO 26262 prüfen – bisher ohne Institution

In der Luftfahrtindustrie gibt es eine Autorität, welche die Einhaltung der vorgeschriebenen Prozesse überwacht. Hersteller von Luftfahrtelektronik benötigen eine Zulassung für die Entwicklung und auch danach prüft die zulassende Behörde bei jedem Projekt, ob die Prozesse im Unternehmen richtig angewendet werden. Das fehlt in der Automobilindustrie bisher: Es gibt keine Institution, die den OEMs und Zulieferern zur Seite steht, um die Prozesse nach ISO 26262 richtig zu etablieren. Offen ist, ob diese Überprüfung zukünftig auf freiwilliger Basis geschieht, mittels eigens implementierter Institution oder wirklicher Autorität, wie der FAA in der Luftfahrt. Sicher ist aber: Mit der Perspektive des autonomen Fahrens wird es unumgänglich, festzuhalten, dass die Sicherheitsrichtlinien der ISO 26262 richtig implementiert wurden.