Das selbstständige Agieren von Fahrerassistenzsystemen und in Zukunft voll autonomen Systemen in sich stets ändernden Fahrumgebungen führt zum Erreichen immer höherer Komplexitätsstufen. Die Anforderungen an die E/E-Architektur im Fahrzeug wachsen und bewirken einen Wandel von unabhängigen Steuergeräten hin zu einer multizonalen Architektur für hochkomplexe, rechenintensiven Fahrzeugfunktionen. In diesem Zusammenhang ist die Einhaltung der Standards zur funktionalen Sicherheit (ISO 26262) und zur Sicherheit der vorgesehenen Funktionalität (SOTIF) von entscheidender Bedeutung.
Automobilhersteller und Zulieferer unterliegen zur Erhaltung der Typgenehmigung (Homologation), zahlreichen Regularien und Standards, um das Nichtvorhandensein eines unangemessenen Risikos entlang des Produktentwicklungsprozesses nachzuweisen.
Intelligente Umgebungssensoren und komplexe Wirkketten führen zu einem Paradigmenwechsel in der Absicherung neuer Systeme. Eine signifikante Erhöhung der Aufwände im Absicherungsprozess ist eindeutig ersichtlich. Um dem Rechnung zu tragen, ist nicht nur die Anzahl der Tests zu erhöhen, sondern eine ganzheitliche Betrachtung des Entwicklungs- und V&V (Verifikation und Validierung)-Prozesses erforderlich. Grundlegend und zentral für eine Entwicklung verlässlicher Systeme sind der datengetriebene Entwicklungsprozess und die enge Verbindung zu virtuellen Prüfmethoden, um verlässlich und effizient den Homologationsprozess durchlaufen zu können.
Dafür muss eine geeignete und umfassende Teststrategie gewählt werden, die den Einsatz von Simulation als zentrales Element nutzbar macht und die Messdaten konsequent in der Simulation nutzt – nicht nur um das zu entwickelnde System abzusichern, sondern auch um sicherzustellen, dass die virtuellen Prüfmethoden ihren Zweck erfüllen können. Simulation ist nicht nur ein Werkzeug für eine effiziente Entwicklung, sondern für die Homologation unabdingbar, um bekannte Risiken und neue Gefährdungen in (noch) ungelernten Fahrszenarien ganzheitlich abzusichern und somit das Nichtvorhandensein eines unangemessenen Risikos nachzuweisen.
Wie beweist man, dass ein System hinreichend sicher ist?
Diverse Standards und Regularien bilden die Rahmbedingungen, die während der Entwicklung berücksichtigt werden müssen. Standards für (Functional) Safety, Cyber Security und Anforderungen an den Prozess müssen erfüllt werden, um gemäß dem Vorsorgeprinzip nachzuweisen, dass alle notwendigen Maßnahmen ergriffen worden sind, damit ein System so sicher wie möglich ist, bevor es auf der Straße zugelassen wird. Zusätzlich basiert die Sicherheitsargumentation auf der Idee der Positiven Risikobilanz, die besagt, dass das zu prüfende System (System under Test, SUT) auf die Straße darf, wenn es nachweislich mindestens so gut abschneidet, wie ein aufmerksamer menschlicher Fahrer.
Der Bereich Safety wird durch die ISO 26262 und die SOTIF (ISO 21448) adressiert. Die ISO 26262 stellt das Nichtvorhandensein eines unangemessenen Risikos resultierend aus einem Fehlverhalten des Systems sicher. Darunter fallen sporadische Hardware-Ausfälle und technisch verschuldete Fehler auf Systemebene.
Eine sicherheitskritische Anwendung muss die Integrität der Umgebung gewährleisten. Die funktionale Einschränkung der Fahrfunktion hinsichtlich realer Anwendungsfälle und spezifischer Bedingungen, unter denen das System funktionieren soll (Operational Design Domain, ODD), werden im Kontext der ISO 26262 nicht berücksichtigt. Wird beispielsweise ein System mit einem Kamerasensor entwickelt, ist es möglich, dass die Sensorik technisch betrachtet einwandfrei funktioniert, jedoch nicht in der Lage ist, ein Objekt in einem bestimmten Szenario zu erkennen. Die Berücksichtigung realer Anwendungsfälle und potenzieller Fehlanwendungen motivierte daher zur Veröffentlichung der ISO 21448 – Safety of the Intended Functionality, die komplementär zur ISO 26262 wirkt.
Wann ist ein Szenario gefährlich?
Das System und seine Funktionalität sind auf einen konkreten Anwendungsfall ausgelegt, der mehrere Szenarien adressiert. Die Szenarien können Auslöser (Trigger) enthalten, die zu einer funktionalen Einschränkung und somit zu einem gefährlichen Verhalten führen.
Mit ansteigendem Automatisierungsgrad werden die Trigger zunehmend komplexer und schwieriger zu erkennen. Die SOTIF beinhaltet eine Risikobewertung von Szenarien, die im realen Anwendungsfall zu einer Gefährdung führen können. Zusätzlich wird die Wahrscheinlichkeit betrachtet, wann ein Szenario potenziell gefährlich ist. Es ergeben sich die folgenden vier Bereiche:
- Bereich 1: bekannte und sichere Szenarien
- Bereich 2: bekannte und unsichere Szenarien
- Bereich 3: unbekannte und unsichere Szenarien
- Bereich 4: unbekannt und sichere Szenarien
Die SOTIF-Aktivitäten zielen darauf ab, potenziell unsichere Szenarien (Bereich 2 und Bereich 3) systematisch zu identifizieren und iterativ zu bewerten. Die bekannten, unsicheren Risiken (Bereich 2) werden durch Kombinationen geeigneter Testumgebungen und Testmethoden, zum Beispiel anforderungsbasiertes Testen (Verifikation), evaluiert. Durch technische Maßnahmen im Systemdesign werden die Restrisiken im Sinne der Positiven Risikobilanz reduziert und erneut bewertet, um den Sicherheitsnachweis zu erbringen, dass das durch das Szenario verursachte Restrisiko hinreichend niedrig ist. Unsichere und unbekannte Szenarien werden durch Simulation und virtuelle Testverfahren, zum Beispiel szenariobasiertes Testen, identifiziert (Validierung). Die nun unsicheren, aber bekannten Risiken werden im Anschluss verifiziert.
Es resultiert eine Reduzierung des Restrisikos aus Bereich 2 und Bereich 3, während sich der Bereich der sicheren und bekannten Szenarien vergrößert und somit das Vertrauen in das Erreichen der SOTIF erhöht wird.
Verifizierung des zu erwartenden Verhaltens
Die Grundlagen für ein Best-Practice-Verfahren für die Entwicklung von ADAS/AD-Funktionen, das rechtliche und technische Anforderung erfüllt, bildet der ASAM Test Specification Study Group Report. Geeignete Testmethoden und -umgebungen werden unter Berücksichtigung konkreter Anwendungsfälle in einer Testmatrix angeführt.
Laut der ASAM-Testmatrix besteht eine Möglichkeit zum Testen der bekannten und unsicheren Szenarien im anforderungsbasierten Testen in einer Software-in-the-Loop-Simulation. Diese Szenarien stellen auf Basis der Akzeptanzkriterien die Anforderungen an das System, unter denen es sicher agieren muss. Anhand der Anforderungen werden die Testspezifikationen erstellt. Darunter fällt die Spezifikation von Szenario, Testfall und Parameter.
In der Software-in-the-Loop-Simulation wird ein virtuelles Steuergerät in eine PC-basierten Simulationsplattform integriert. Durch anforderungsbasiertes Testen kann somit die Reaktion des Systems auf ein bestimmtes Szenario überprüft werden. Darüber hinaus stellt anforderungsbasiertes Testen ein Werkzeug dar, mit dem die Effektivität der technischen Maßnahme im Systemdesign bewertet werden kann.
Validierung der unbekannten Risiken
Das übergeordnete Ziel der Validierung liegt in der Reduzierung unbekannter Gefährdungen innerhalb der ODD. Eine mögliche Methodik bildet szenariobasiertes Testen in einer Software-in-the-Loop-Simulationsumgebung.
Die grundlegende Idee des szenariobasierten Testens besteht im Sinne der positiven Risikobilanz in einem Vergleich des zu testenden Systems mit dem Verhalten eines menschlichen Fahrers. Durch das Integrieren von Daten aus der realen Welt in den Validierungsprozess werden abstrakte Szenarien generiert, die eine virtuelle Umgebung darstellen. Die abstrakten Szenarien werden anschließend verwendet, um logische und konkrete Szenarien für die Simulation zu generieren. Schnittstellen zum Fahrzeug sowie Kartenmaterial werden ebenfalls virtualisiert und in den Testaufbau integriert.
Durch eine intelligente Teststeuerung werden Parameterräume beliebig abgetastet, um potenziell gefährliche Szenarien zu identifizieren. Parallel werden Daten aus Realfahrten herangezogen, um die Repräsentativität der Testergebnisse in der ODD zu bewerten. Somit können unbekannte Risiken kontinuierlich identifiziert und reduziert werden, was die Gesamtsicherheit an das System erhöht.
Fazit – Wie sieht der optimale V&V-Prozess aus?
Um eine effektive V&V-Strategie zu definieren, müssen die übergeordneten Ziele der SOTIF-Aktivitäten adressiert werden:
- Was ist das Validierungsziel?
- Wie können Trigger-Events und funktionale Insuffizienzen identifiziert und evaluiert werden?
- Ist die Evaluierung der potenziell gefährlichen Szenarien ausreichend?
- Werden die relevanten Szenarien hinreichend abgedeckt?
- Welche Methoden unterstützt die Nachweiserbringung?
- Werden geeignete Verifizierungs- und Validierungsmethoden gewählt?
Auf diese Fragen gibt es keine allgemeingültige Antwort. Vielmehr müssen die Fragen für das jeweilige SUT unter Berücksichtigung des Testziels und einer Kombination von ausgewählten Testumgebungen und Testmethoden auf einer bestimmten Testebene beantwortet werden.
Es gilt, Risiken, die sich aus einem gefährlichen Verhalten ergeben, systematisch zu identifizieren und zu bewerten. Mit zunehmenden Automatisierungsgrad wird das Erkennen und Bewerten von Bedingungen, die zu einem potenziell gefährlichen Verhalten führen (Trigger), zunehmend komplexer, so dass mehrere Analysetechniken in Verbindung mit Realtestfahrten erforderlich sind, um gefährdende Szenarien zu ermitteln. Eine Möglichkeit, um die Auswirkung möglicher Trigger auf das System zu untersuchen, besteht beispielsweise in der Durchführung einer System-Schwächen-Analyse. Diese zielt darauf ab, für jedes identifizierte Systemelement und der dazugehörigen funktionalen Insuffizienz und dem Trigger eine Risikoanalyse durchzuführen, um Maßnahmen zur Verbesserung der SOTIF zu definieren, ihre Wirksamkeit zu prüfen und das Restrisiko mit einer angemessenen Begründung zu bewerten.
Darüber hinaus muss der SOTIF-Verifizierungs- und Validierungsprozess in die übergeordnete Freigabestrategie integriert werden.
Unter Berücksichtigung dieser Faktoren ist es möglich, eine SOTIF-Freigabeargumentation zu erbringen, die idealerweise in einen digitalen Homologationsprozess implementiert wird. Dadurch werden die theoretischen Rahmbedingungen für einen Prozess gesetzt, der es ermöglicht, dass komplexe autonome Systeme auf sich stets ändernde Fahrumgebungen reagieren können.
dSPACE Consulting unterstützt auf Grundlage der ISO 26262 und der ISO/PAS 21448 dabei, Teststrategien für szenario- und anforderungsbasierte Designs mit professioneller Risikoanalyse zu erarbeiten und diese nahtlos in etablierte Entwicklungsprozesse zu integrieren.
Veröffentlicht Februar 2024
