Derzeit sind autonome Fahrsysteme auf SAE-Level 4 und 5 reine Forschungsprojekte. Ihre Entwicklung erfolgt noch ohne serienreife Software- oder Hardwarekomponenten und sie erreichen ebenso wenig die für die Serienfertigung erforderliche Zuverlässigkeit. Unternehmen wie Ansys, Edge Case Research und Green Hills Software nehmen sich den Herausforderungen an, die mit dem Einsatz autonomer Fahrsysteme verbunden sind. Ziel ist es, die in den heutigen Forschungsprojekten erzielten Fortschritte zu realisieren und neue Sicherheitstechniken in allen Phasen der Entwicklung, Simulation, Testabläufe und der Umsetzung anzuwenden, um serienreife Systeme für autonomes Fahren zu ermöglichen.

Herkömmliche Sicherheits-Validierungsmethoden erweitern

Anforderungen des Systems fest, definieren die Softwarearchitektur und erstellen Subsysteme, um jede dieser Anforderungen für autonome Fahrsysteme zu erfüllen.

Bild 1: Anhand des V-Modells nach ISO 26262 legen Entwickler detaillierte Anforderungen des Systems fest, definieren die Softwarearchitektur und erstellen Subsysteme, um jede dieser Anforderungen für autonome Fahrsysteme zu erfüllen.

Die Validierung der bisher eingesetzten Automotive-Sicherheitssoftware, beispielsweise die Software zur Steuerung von Fahrerassistenzsystemen (ADAS), strukturiert sich nach dem in der ISO-26262 definierten V-Modell für den System- und Embedded-Software-Lebenszyklus. Anhand dieses Schemas legen Entwickler die detaillierten Anforderungen des Systems fest, definieren eine Softwarearchitektur und erstellen parallel Subsysteme, um jede dieser Anforderungen zu erfüllen. Die linke Seite des V-Modells (Bild 1) zeigt, dass sich das System in immer kleinere Subsysteme zerlegen lässt. Die rechte Seite beschreibt den Validierungsprozess der Software, beginnend mit den kleinsten Subsystemen und bis hin zur Validierung auf Systemebene ganz oben.

Eckdaten

Die hohen Sicherheitsanforderungen künftiger autonomer Fahrsysteme treiben herkömmliche Validierungsmethoden wie auch Testzeiten an ihre Grenzen. Eine leistungsfähige Sofwareplattform von Ansys, Green Hills und Edge Case Research kann bei Entwicklung, Simulation und Test effizient unterstützen. Sie kürzt beispielsweise 14 Milliarden Kilometern Testfahrt ab oder sucht über schwierige Simulationsszenarien nach kritischen Randfällen, welche Systemausfälle verursachen. Die integrierte Softwarelösung kann somit durchgehende Sicherheit in Deep-Learning-basierten und anderen autonomen Fahrsystemen erzielen.

Autonome Fahrsysteme sind aber viel mehr als nur eine Ansammlung von ADAS. Assistenzsysteme sind so ausgelegt, dass sie im Fall einer Fehlfunktion die Kontrolle an den Fahrer zurückgeben. Systeme mit SAE-Level 5 sind dagegen per Definition vom Fahrer unabhängig, sodass sie konstruktionsbedingt nicht auf den Fahrer zurückzugreifen können, wenn eine Fahrsituation automatisch nicht mehr zu bewältigen ist. Darüber hinaus erfüllen die eingesetzten Deep-Learning-Systeme weder die Voraussetzungen, noch die Architektur oder detaillierte Subsysteme, die zur Validierung konventioneller Sicherheitssoftware notwendig sind. Eine weitere Herausforderung besteht beim maschinellen Lernen darin, dass Deep-Learning-Systeme probabilistisch sind und somit bei wiederholt gleichen Eingangszuständen gelegentlich abweichend reagieren.

Straßentests sind daher ein wesentlicher Bestandteil der Entwicklung, bieten jedoch keine brauchbare Lösung für die Frage, wie autonome Fahrsysteme idealerweise zu validieren sind. Das Problem besteht darin, dass Tests auf der Straße in erster Linie aus Routinesituationen bestehen, die für menschliche Fahrer oder automatisierte Fahrsysteme nicht sonderlich schwierig sind. Akio Toyoda, President bei Toyota Motors, erklärte, dass sich die Funktionssicherheit von vollständig autonomen Fahrzeugen erst nach etwa 14 Milliarden Kilometern Testfahrt gewährleisten lässt. Außerdem würde dieses enorme Testfahrprogramm nur einen Entwicklungsstand eines einzelnen autonomen Fahrsystems absichern. Erfolgt eine Softwareänderung oder taucht ein Fehler auf, müsste der gesamte Test von vorn beginnen.

Bild 2: Regelkreis für das automatisierte Fahren.

Bild 2: Der Regelkreis für automatisiertes Fahren besteht aus der Wahrnehmung (was das Auto beobachtet), der Bewegungsplanung (welches Verhalten das Auto plant) und der Bewegungsausführung (wie das Auto den Plan umsetzt).

Den Fahrzeugregelkreis überarbeiten

Aktuelle Automotive-Entwicklung nutzt eine Kombination aus maschinellem Deep-Learning und Steuerlogik, um einen vollständig autonomen Fahrzeugregelkreis zu implementieren (Bild 2). Dieser besteht aus der Wahrnehmung (was das Auto beobachtet), der Bewegungsplanung (welches Verhalten das Auto plant) und der Bewegungsausführung (wie das Auto den Plan umsetzt). Der Regelkreis arbeitet zyklisch, sodass das Fahrzeug auf konstante Umgebungsveränderungen reagieren kann. Um die Funktionssicherheit der komplexen Algorithmen zur Wahrnehmung, Bewegungsplanung und Ausführung verifizieren zu können, müssen Entwickler die gesamte autonome Fahrzeugarchitektur in mehrere sinnvolle Komponentengruppen zerlegen.

Der Primärkanal erzeugt eine Langzeitmission ohne definierten Endzustand, während der Sicherheitskanal eine Mission von kurzer Dauer erzeugt, die in einem sicheren Zustand endet (Bild 3).

Während ihrer Zeit an der Carnegie Mellon University haben Mitglieder des Teams von Edge Case Research eine Architektur vorgeschlagen, die die Sicherheit für jede dieser Komponenten nach dem DOER-CHECKER-Prinzip garantiert. Der primäre Algorithmus (DOER) ist extrem komplex, wird häufig aktualisiert und ist schwer zu verifizieren. Der sekundäre Algorithmus (CHECKER) besteht aus einem Safing Gate, das die Ausgänge des primären Algorithmus überprüft und die Kontrolle übernimmt, wenn ein Problem auftritt und eine Aktion erfolgen muss, um zum Beispiel das Auto an den Straßenrand zu steuern.

Strengste Zuverlässigkeits- und Sicherheitsanforderungen

Bild 3: xxx

Bild 3: Der Primärkanal liefert zunächst einen undefinierten Endzustand, der vom nachgeschalteten Sicherheitskanal in einem sicheren Zustand überführt wird. Greenhills

Die detaillierten Sicherheitsanforderungen der Safing Gates sind so festzulegen, dass ihre Umsetzung die höchsten Sicherheitsanforderungen nach ASIL D in der ISO 26262 oder sogar den strengeren Avionikstandard nach Level A in der DO-178C erfüllt. Der DOER-Algorithmus hingegen braucht nicht eingehalten zu werden, um diese Anforderungen zu erfüllen. Er kann willkürlich ausfallen und falsche Dinge auf die denkbar schlechteste Art ausführen, da der CHECKER den DOER in eine fehlersichere Komponente verwandelt, die sich abschaltet, wenn sie keine korrekten Daten liefert. Erkennt das Safing Gate zum Beispiel einen Planungsfehler (der geplante Fahrweg schneidet ein in zweiter Reihe geparktes Auto), wird der DOER-Algorithmus deaktiviert.

Die DOER-CHECKER-Implementierung in einem serienreifen System erfordert daher eine Target-Software-Umgebung, die nicht nur strengste Zuverlässigkeits- und Sicherheitsanforderungen erfüllt, sondern auch eine strikte Trennung zwischen den sicherheitskritischen Komponenten im System und den unkritischen Komponenten bietet.

Autonome Fahrsysteme verlassen sich auf Sensoren, um Entscheidungen über die Umgebung zu treffen. Dabei ist nicht immer klar, wie sich das System verhalten soll, um absolute Sicherheit zu gewährleisten. Es ist also nicht möglich, ein Safing Gate zu erstellen, um zu überprüfen, ob die Ausgangsdaten der Wahrnehmungssysteme korrekt und sicher sind. Die hier aufgeführten Beispiele zeigen, wie Signalrauschen die Robustheit der Funktion, eine Situation richtig zu verstehen und Sicherheit zu garantieren, beeinträchtigen kann. Der Abschnitt „Safety of the Intended Functionality“ (SOTIF) der ISO 26262 behandelt das gefährliche Verhalten in Systemen mit diesen Einschränkungen.

Lesen Sie auf der nächsten Seite, wie Simulationsmodelle unterstützend bei der Sicherheitsvalidierung wirken können.

Seite 1 von 212