Fail-Operational-Plattform für vollautomatisiertes Fahren

TTTechWie wichtig Fail-Operational-Systeme sind, zeigt schon dieses Beispiel: Ein Auto fährt selbstständig mit 130 km/h auf der Autobahn. Das Steuergerät macht einen Rechenfehler, aber das System erkennt den Fehler und deaktiviert die Funktion. Ist damit das Problem gelöst? Keineswegs. Das Fahrzeug wird nach dem Deaktivieren der Funktion nicht mehr gelenkt und folglich besteht die Gefahr, dass es mit einem anderen Fahrzeug kollidiert oder in die Leitplanke kracht.

Bild 1: ASIL-D-Dekompositionen. TTTech

Im Gegensatz zu heutigen Systemen lässt sich ein Steuergerät für autonomes Fahren im Fehlerfall nicht einfach deaktivieren, weil es weiterhin eine gewisse Funktionalität ausführen muss; diese könnte darin bestehen, den Fahrer zur Übernahme aufzufordern und für eine gewisse Zeit die Spur zu halten. Sollte der Fahrer die Kontrolle nicht übernehmen wollen oder können, muss das Fahrzeug autonom an einem sicheren Ort anhalten. Ein Anhalten des Fahrzeuges auf einem Fahrstreifen, gar auf dem innersten, kann beispielsweise kein sicherer Zustand sein. Diese Notfallfunktion muss daher durchaus eine signifikante Zeitspanne lang aktiv sein.

Aus Sicht der ISO 26262 sind drei Klassen an Fehlern zu berücksichtigen: Zufällige Hardwarefehler wie ein Kurzschluss oder durch Strahlung verursachte Datenverfälschung, sowie systematische Hardware- und Softwarefehler, also Bugs in den Implementierungen. Bezüglich zufälliger Hardwarefehler muss nachgewiesen werden, dass die Wahrscheinlichkeit von sicherheitsrelevanten Fehlern ausreichend niedrig ist. Gegen systematische Fehler sind entsprechende Entwicklungsmethoden erforderlich, um Fehler in Spezifikation, Architektur und Implementierung hinreichend zu vermeiden.

Bei solchen Fail-Operational-Systemen liegt der Fokus im Gegensatz zu heute nicht mehr nur auf der Vermeidung oder Detektion von falschem Verhalten sondern explizit auch auf der Vermeidung von Nicht-Verfügbarkeit der Funktion.

Welche Ansätze gibt es heute, und was können wir von der Luftfahrt lernen?

Heutige Ansätze

Bild 2: Unzulässige ASIL-Dekomposition bei Fail-Operational-Architekturen. TTTech

Ein oft verwendetes Entwicklungsparadigma der ISO 26262, das es erlaubt, nicht die gesamte Software nach dem höchsten ASIL entwickeln zu müssen, ist die ASIL-Dekomposition. Hierbei wird die ursprüngliche Sicherheitsanforderung auf zwei unterschiedliche und sich ergänzende Anforderungen aufgespalten und nach unterschiedlichen ASILs umgesetzt. Dabei muss nachgewiesen werden, dass es keine Fehler gibt, die beide Komponenten betreffen können (Common-Cause-Fehler).

Ein Beispiel für eine solche Software-Architektur ist die End-to-End-Absicherung (E2E) der Kommunikation zwischen Komponenten. Hierbei kann der Kommunikations-Stack (Komm.-Stack) ohne spezielle Sicherheitsanforderungen entwickelt werden, während eine gemäß ASIL D entwickelte E2E-Absicherung dafür sorgt, dass im Kommunikations-Stack verfälschte Nachrichten erkannt werden.

Dieses Prozedere verhindert, dass eine fehlerhafte Nachricht vom Empfänger verwendet wird. Der große Vorteil dieses Ansatzes besteht darin, dass der E2E-Absicherungsmechanismus deutlich einfacher ist als der gesamte Kommunikations-Stack. Daher lässt sich mit weniger Entwicklungs- und Validierungsaufwand dennoch dasselbe Maß an Sicherheit erreichen, wie wenn der Kommunikations-Stack nach ASIL D entwickelt worden wäre.

Wenn eine derartige Kommunikationsarchitektur aber in einem Fail-Operational-System auf allen redundanten Hardware-Elementen identisch zum Einsatz kommt, lässt sich natürlich nicht ausschließen, dass ein Bug im Kommunikationsmodul dazu führt, dass die Funktion auf allen Knoten ausfällt, bevor das Fahrzeug sicher zum Stillstand kam. Dies könnte eintreten, weil zu viele Nachrichten korrumpiert werden oder weil der Kommunikations-Stack abgestürzt ist. Daher müsste diese Architektur streng genommen wie eine QM-Komponente behandelt werden – und zwar trotz des (als fail-silent konzipierten) ASIL-D-Sicherheitsmechanismus, der bezüglich Verfügbarkeit vollkommen wirkungslos ist. Die Fail-Operational ASIL-D-Anforderung ist dadurch nicht erfüllt. Dieses Problem gilt für viele andere Sicherheitsmechanismen auch. So ändert beispielsweise das Detektieren durch einen Watchdog, dass eine Komponente nicht mehr ordnungsgemäß arbeitet, nichts an der Tatsache, dass sie derzeit nicht verfügbar ist.

Lernen von der Luftfahrt?

Bild 3: Typische hochredundante Architektur der Luftfahrt. TTTech

In der Avionik gilt es schon immer, Fail-Operational-Anforderungen zu erfüllen. Der Ansatz der einschlägigen Standards wie der ARP4754A, ARP 4761 verlangt eine Analyse der Fehler der Funktionen und deren Bewertung, ähnlich wie bei der ISO 26262. Dabei legen die Verantwortlichen unterschiedliche Sicherheitsziele beispielsweise für die Integrität (Fähigkeit eines Systems, richtige Daten zu liefern), aber auch explizit für die Verfügbarkeit fest. Um diese Ziele zu erfüllen, müssen für die Hardware-Entwicklung der Standard DO-254 und für die Software-Entwicklung DO-178C beachtet werden. Als Beispiel für eine entsprechende Architektur dient hier eine (vereinfacht dargestellte) Architektur des Flight-Computers einer Boeing 777 (Bild 3).

Hierbei sind alle Ressourcen – von der Stromversorgung über die Sensoren und die Recheneinheiten bis zu den Aktuatoren – mindestens dreifach redundant vorgehalten. Durch 2-aus-3-Voting der Daten an mehreren Punkten lassen sich falsche Daten einzelner Komponenten unterdrücken. Deshalb müssen einzelne Komponenten nicht immer Fail-Silent sein, sondern können im Fehlerfall auch falsche Daten ausgeben. Die intern vorhandenen Fehlererkennungsmechanismen müssen nicht so stark ausgeprägt sein.

Fail-Operational-Betrieb ist ein Muss beim autonomen Fahren. TTTech/iStockphoto

Was geschieht, wenn der Aktuator selbst fehlerhaft ist? Hierfür ist durch  ein Mechanical Voting genanntes Verfahren vorgesorgt: Zwei Aktuatoren sind immer in der Lage, einen fehlerhaften Aktuator zu überdrücken, selbst wenn dieser mit maximaler Kraft in die falsche Richtung aktuiert.

Um systematische Fehler in der Hardware auszuschließen, besteht der Primary Flight Computer intern aus dreifach unterschiedlichen Komponenten (zum Beispiel drei Prozessorarchitekturen), deren Ergebnisse gevoted werden. Da durch deren Diversität nur eine dieser CPUs von einem Bug betroffen sein kann, unterdrückt ein derartiges System inkorrekte Ergebnisse.

Bei der Entwicklung der Software kommen Ansätze wie die ASIL-Dekomposition nur sehr eingeschränkt voran. Deshalb arbeiten die Software-Entwickler bei der Boeing 777 direkt entsprechend dem höchsten Design Assurance Level (DAL). Ausfälle durch Softwarefehler müssen dementsprechend ausgeschlossen sein.

Jeder der Flight Computer ist nochmals dreifach redundant ausgelegt. Dieser Hot-Standby-Ansatz dient primär der Verlängerung der Wartungsintervalle, da defekte Komponenten nicht sofort getauscht werden müssen. In der Minimum Equipment List (MEL) ist festgelegt, welche Funktionen (oder Subsysteme) ausfallen dürfen und ob das Flugzeug mit dem degradierten System nach wie vor in Betrieb sein darf.

Automotive: Zufällige Hardware-Fehler

Ein alternativer Ansatz gegenüber dem der Avionik besteht darin, nur zwei statt drei unabhängige Knoten einzusetzen. Dafür besitzen sie jeweils intern ausreichende Selbstüberprüfungsfunktionen, um alle Hardwarefehler erkennen und dann zuverlässig selbstständig abschalten zu können. Solange die Knoten unabhängig sind, kann die Funktion auf dem jeweiligen anderen Steuergerät aufrecht erhalten werden. Dieser Ansatz entspricht eher den aktuell in der Automobilbranche eingesetzten Architekturen. Hierbei verlagert sich allerdings Komplexität in die einzelnen Steuergeräte und Komponenten. Der Trade-Off aus der Avionik – zusätzliche Hardware-Redundanz, um die Wartungsintervalle zu verlängern – ist für Systeme im Automotive-Bereich nicht notwendig.

Und wie sieht es mit systematischen Fehlern im Automotive-Umfeld aus?

Automotive: Systematische Fehler

Was kann man nun tun, um Software fit für Fail-Operational-Anforderungen zu machen? Natürlich wäre die Entwicklung der gesamten Software direkt nach Fail-Operational-ASIL-D-Anforderungen, analog der Boeing 777, möglich. In diesem Fall könnte die Komponente auch auf allen redundanten Knoten zum Einsatz kommen, da sie als hinreichend fehlerfrei gelten kann.

Bild 4: Fehlertoleranz als einfaches Add-In. TTTech

Eine Fail-Operational-ASIL-D-Anforderung für Software bedeutet, dass systematische Fehler nicht dazu führen dürfen, dass eine Funktion nicht mehr ausgeführt werden kann. Heutzutage ist dies zwar ein Problem der Softwarequalität, aber aus Sicht der funktionalen Sicherheit war dies bisher nicht relevant.

Die ASIL-Dekomposition gibt aber auch schon eine alternative Lösung vor. Wenn es mehrere unabhängige (diversitäre) Implementierungen der überwachten Funktion gibt, können diese nach einem niedrigeren ASIL implementiert werden. Selbst wenn eine dieser Software-Komponenten fehlerhaft ist und unterdrückt werden muss, ist es möglich, durch die andere, noch fehlerfreie Funktion auf dem anderen Knoten die Funktion aufrecht zu erhalten. Dadurch lassen sich die heutigen Safety-Software-Architekturen teilweise weiterverwenden.

Fail-Operational Hardware- und Software-Plattform

Eine Lösung für solche Anwendungsfälle ist eine Plattform, die alle Vorteile der Ansätze Voting und Hot-Standby geschickt vereint. TTTech hat seine Erfahrungen aus der Luftfahrt in eine solche Hardware-Plattform einfließen lassen. Um Ausfälle durch Hardwarefehler tolerieren zu können, besteht das System aus zwei Knoten mit jeweils unabhängigen Stromversorgungen und Sensoren (Bild 4). (Haupt-)Knoten A besitzt starke Selbstüberwachungsmechanismen, um Fail-Silent-ASIL-D-Anforderungen zu erfüllen. Die Safety-Anforderungen für (Rückfall-)Knoten B sind geringer. Die Fail-Silent-Eigenschaft von Knoten A wird durch die Verwendung von unabhängigen und redundanten Teilfunktionen der Applikation erfüllt. Diese laufen jeweils auf unabhängigen Performance-SoCs; sie senden ihre Ergebnisse jeweils an ein Safety-SoC. Dieses Safety-SoC sendet nur dann einen Befehl an den Fail-Operational-Aktuator, wenn die Ergebnisse beider Funktionen konsistent sind. Parallel wird auf dem unabhängigen Knoten B die Rückfallfunktion ausgeführt, die ebenfalls Befehle über einen unabhängigen Kommunikationspfad an den Aktuator sendet. Solange er korrekte Befehle von Knoten A empfängt, wendet der Aktuator diese an und ignoriert die Befehle von Knoten B. Nur wenn der Aktuator keine Befehle mehr von Knoten A empfängt, verwendet er die Befehle vom Knoten B.

Bild 5: Plattform-Architektur der nächsten Generation. TTTech

Um die Fail-Operational-ASIL-D-Anforderung bezüglich systematischer Fehler zu erfüllen, kombiniert die Plattform die Ansätze Diversität und Entwicklung direkt nach Fail-Operational-ASIL-D-Anforderungen (ohne ASIL-Dekomposition). Für die unterschiedlichen Kommunikationsmedien sowie Hardware- und Software-Komponenten sind auch jeweils unterschiedliche Sicherheitskonzepte notwendig. Daher analysiert TTTech alle Komponenten und mögliche Sicherheitskonzepte und implementiert die jeweils am besten geeigneten.

Zusammen mit der Middleware ist dadurch die vorhandene Diversität für den Funktionsentwickler weitestgehend abstrahiert. Weder aus funktionaler noch aus Safety-Sicht ist es erforderlich, das unterschiedliche Verhalten der diversitären Komponenten weiter zu betrachten. Die aufwendige Analyse, ob sich Common-Cause-Fehler in den Details der Plattformimplementierung beider Knoten verstecken, entfällt komplett. Der Entwickler widmet sich rein der Funktionsentwicklung; die nötige Hardware, Software und Sicherheitskonzepte sind mit der Plattform schon vorhanden.

Die Steuergeräte-Plattform von TTTech erlaubt es nicht nur, Komfortapplikationen und sicherheitsrelevante Applikationen von QM bis ASIL D auf einem Steuergerät zu hosten, sondern auch mit gemischten Fail-Silent- und Fail-Operational-Anforderungen auf dem Plattformsteuergerät umzugehen, ohne dass erstere die Verfügbarkeit der Fail-Operational-Komponenten stören.