Sichere Software für das Auto von morgen Autonomes Fahren benötigt zukunftssichere AUTOSAR-Basis-Software

Mit einem immer höher werdenden Grad an Automatisierung von Fahrfunktionen steigen die Anforderungen an die Zuverlässigkeit der Systeme und deren Hard- und Software. Insbesondere die Software lässt sich nur schwer mit den aktuell im Automobilbereich etablierten Methoden beherrschen.

Ein Wohnmobil fährt mit 100 km/h auf der Autobahn. Der Fahrer sitzt nicht hinter dem Steuer, sondern kocht sich im hinteren Teil des Fahrzeugs einen Kaffee. Das Fahrzeug steuert sich selbst. Dieses Szenario erinnert sehr an Fiktion, doch es soll irgendwann Wirklichkeit werden. Daher wird sich einiges für die Systeme im Fahrzeug ändern müssen: Es werden mehr Sensoren benötigt, um die Umwelt genau zu erfassen. Außerdem müssen die Steuergeräte im Fahrzeug breitbandig miteinander vernetzt werden, um der neuen Informationsflut Herr zu werden. Aber ist das alles? Welche Konsequenzen gibt es zum Beispiel für die Software-Entwicklung? Kann so weitergemacht werden wie bisher?

Heute sind nahezu alle Systeme im Fahrzeug einkanalig ausgelegt. Einkanalig bedeutet, dass, wenn ein Element in der Kette von Sensor über Logik zu Aktor ausfällt, auch das Gesamtsystem ausfällt. Redundanzen, also beispielsweise ein zweiter Sensor oder ein zweiter Mikrokontroller, dienen ausschließlich dazu, einen Fehler in der Kette hinreichend sicher erkennen zu können. Die übliche Reaktion im Fehlerfall ist, das Steuergerät neu zu starten oder das Gesamtsystem abzuschalten und den Fahrer zu informieren. Dieser kann sich dann auf die neue Situation einstellen und das Fahrzeug zur Not stoppen. Das Neustarten oder aber das vollständige Abschalten eines Systems gelten dabei als sichere Zustände. Das zugehörige System wird als fail-safe bezeichnet.

Die Software für Fail-Safe-Systeme muss Fehler in der Hardware und Software innerhalb einer Toleranzzeit erkennen. Das erfolgt oft durch eine Überwachung von Deadlines für die Ausführung von bestimmten Software-Funktionen oder durch zusätzliche Prüfungen der Korrektheit und Aktualität von empfangenen Daten wie auch bei der Ende-zu-Ende-Absicherung (E2E) für die Kommunikation.

Weiterfahren trotz Fehler

Damit der Fahrer nun in aller Ruhe seine Kaffee kochen und genießen kann, darf er nicht mehr die Rückfallebene im Sicherheitskonzept des Systems sein. Es muss also ein elektronisches Rückfallsystem geben (Bild 1). Eine Voraussetzung für ein derartiges System ist, dass jeder Kanal alle seine Fehler selbst erkennt. Im Fehlerfall des aktiven Kanals wird dieser abgeschaltet und der andere Kanal übernimmt die Steuerung des Fahrzeugs (Bild 2a). Ein System dieser Bauart wird als Fail-Operational bezeichnet.

In der System- und Hardware-Technik wird davon ausgegangen, dass jeder Teil eines Systems zu jedem Zeitpunkt mit einer gewissen Wahrscheinlichkeit ausfällt. Für die Berechnung dieser Wahrscheinlichkeit gibt es unterschiedliche Modelle, mit denen sich untersuchen und begründen lässt, warum ein System als sicher angenommen wird. Die Modelle haben eine gewisse Unsicherheit. Der entscheidende Punkt dabei ist aber, dass es Modelle gibt. Denn im Folgenden werden zwei Fehlerfälle betrachtet, die an die Grenzen dessen führen, was über Wahrscheinlichkeiten berechenbar ist.

Aus Gründen des Kostendrucks und der Komplexität werden Teile der Software in beiden Kanälen zukünftiger Systeme sehr wahrscheinlich identisch sein. Dadurch stellt sich natürlich sofort das Pro­blem der abhängigen Fehler, insbesondere der Fehler gemeinsamer Ursache – auch Common Cause Faults genannt. Wenn ein solcher Fehler im System vorhanden ist, dann führt dessen Eintritt dazu, dass beide, eigentlich unabhängigen Kanäle zum selben Zeitpunkt ausfallen (Bild 2b) und damit das Gesamtsystem seiner Aufgabe nicht mehr nachkommen kann. Eine Diversifizierung, zum Beispiel durch Nutzung von Software unterschied­licher Hersteller, kann eine Lösung hierfür sein. Die tatsächliche Unterschiedlichkeit muss jedoch sorgfältig überprüft werden. Oft ist eine Diversifizierung aus technischen oder kommerziellen Gründen nicht möglich oder weil es einfach keine zweite Implementierung gibt. Eine andere Möglichkeit wäre, zu argumentieren, dass ein Fehler gemeinsamer Ursache hinreichend unwahrscheinlich ist. Doch gibt es dazu ein Wahrscheinlichkeitsmodell?

Die gleiche Frage stellt sich bei einem weiteren möglichen Fehlerfall: Das Steuerungssystem des Wohnmobils funktioniert einwandfrei. Plötzlich wird ein zufälliger Hardware-Fehler im aktiven Kanal entdeckt. Das System reagiert richtig und deaktiviert den aktiven Kanal. Im selben Moment will der bis dahin im Hot-Standby laufende andere Kanal die Steuerung übernehmen. Durch die sich plötzlich ändernde Lastsituation auf dessen Controller, braucht zum Beispiel der Kommunikationsteil der Software unvorhergesehen lange. Es kann keine weitere Kommunikation mehr stattfinden. Dieser Folgefehler wird zwar direkt erkannt, eine vernünftige Fehlerbehandlung gibt es im Allgemeinen jedoch nicht. Ein Neustart führt zum Verlust aller Zustandsinformationen der Steuerungsapplikation. Bis die Informationen alle wieder vorliegen, ist es unter Umständen schon zu spät für den kaffeekochenden Fahrer.

Ein Argumentationsversuch könnte sein, dass es sich hierbei um eine sehr spezielle Art des Doppelfehlers handelt, der nicht weiter betrachtet werden muss. Allerdings ist es auch nachvollziehbar, einen solchen Folgefehler als latenten Fehler (Bild 2c) zu betrachten. Für den Automotive Safety Integrity Level (ASIL) D müssen 90 Prozent aller latenten Fehler erkannt werden. Doch gibt es eine quantitative Aussage zu Fehlern in Software?

Fehlervermeidung für die Software

Alle Fehler in Software sind systema­tische Fehler. Das Erstellen eines allgemein anerkannten Wahrscheinlichkeitsmodells für systematische Fehler ist bisher nicht gelungen. Daher muss Fehlervermeidung als Maßnahme getroffen werden, um die auf Wahrscheinlichkeiten basierenden Argumente einer Analyse auf Systemebene nicht wirkungslos zu machen. Eine Fehlererkennung ist nicht mehr ausreichend, weil es dem Wohnmobilfahrer wenig hilft, wenn das System erkennt, dass es keine Steuerkommandos mehr erzeugt. Der Fahrer verlässt sich darauf, dass das System auch im Fehlerfall sein Wohnmobil noch unter Kontrolle hat.

Wie kann nun Fehlervermeidung für eine komplexe Software gezeigt werden? Systematische Fehler können nur durch einen geeigneten Entwicklungsprozess vermieden werden. Die ISO 26262 legt für die notwendigen Aktivitäten und Methoden eine untere Schranke fest. Im Gegensatz zu Fail-Safe-Systemen sind bei Fail-Operational-Systemen wesentlich mehr Funktionen einer Software sicherheitsrelevant und nicht nur die Funktionen zur Fehlererkennung und -behandlung. In einer AUTOSAR-Basis-Software gibt es daher auch Sicherheitsanforderungen an die Kommunikation und weitere Basisfunktionen.

Üblicherweise resultiert mehr als die Hälfte der Aufwände für eine sicherheitsgerichtete Software-Entwicklung aus dem Test. Daher ist zu erwarten, dass der Aufwand für das Entwickeln eines Fail-Operational-Systems enorm steigt. Zudem lassen sich einige Software-Eigenschaften nur schwer testen. Wie bereits erwähnt, ist die maximale Ausführungszeit eine solche Eigenschaft. Aber auch das Verhalten bei Nebenläufigkeit erfordert intensive Analysen, um kritische Wettläufe (Race Conditions) zu verhindern. Beide Formen der Analyse sind nur mit modernen Werkzeugen überhaupt möglich. Zusätzlich unterstützen die in der ISO 26262 geforderten Sicherheits-, Daten- und Kontrollflussanalysen die Argumentation, dass hinreichend viel dafür getan wurde, das ursprüngliche Risiko auf ein akzeptables Maß zu reduzieren.

Sichere Software für die Zukunft

AUTOSAR-Basis-Software zum Erstellen von Fail-Safe-Systemen gibt es bereits seit einigen Jahren, wie die vollständig bis ASIL D zertifizierte AUTOSAR-Basis-Software Microsar von Vector (Bild 3). Durch eine intensive Daten- und Kontrollflussanalyse und einen ISO-26262-konformen Test ist die Rückwirkungsfreiheit im Speicher nachgewiesen. Eine E2E-Absicherung erkennt eine fehlerhafte Kommunikation in Fail-Safe-Systemen. Ein solches System ist, verglichen mit einem rein auf Partitionierung basierten System, bereits gut auf Fail-Operational-Anforderungen vorbereitet.

Zur weiteren Vermeidung von systematischen Fehlern müssen jedoch zusätzliche Analysen durchgeführt werden. Im Betriebssystem Microsar OS wurde beispielsweise bereits großer Wert darauf gelegt, die maximalen Laufzeiten bestimmbar zu machen und ein möglichst deterministisches Verhalten bereitzustellen. Doch auch hier zeigen erste Analysen, dass es einigen Aufwand braucht, realistische Obergrenzen mit Werkzeug­unterstützung zu ermitteln. Gleiches gilt für die Nebenläufigkeitsanalyse zur Vermeidung von Race Conditions.
Mit aktueller Software und Technologie können heute schon Systeme gebaut werden, die in Zukunft autonom auf der Straße agieren können. Der Weg dorthin wird allerdings noch einiges an Mühen kosten, sowohl bei Software-Lieferanten als auch bei Fahrzeugherstellern und deren Zulieferern. Der Wohnmobilfahrer wird sich also noch ein paar Jahre selbst hinter das Lenkrad setzen müssen, bis er sich in einem autonom fahrenden Fahrzeug Kaffee kochen kann.

Der Autor