Sicherheit Fehlererkennung und -behebung in Multifunktions-Steuergeräten

Mit zunehmender Anzahl sicherheitskritischer bzw. sicherheitsrelevanter Software-Funktionen im Auto steigen auch die Anforderungen an den Umgang mit möglichen Fehlern in der Software, die während des Fahrzeugbetriebs auftreten. Die ISO 26262 fordert dazu eine systematische Analyse möglicher Fehlerursachen und deren Auswirkungen, die Umsetzung von Maßnahmen zur Fehlererkennung und geeigneten Reaktionen auf erkannte Fehler sowie die Vermeidung von Interferenzen zwischen verschiedenen Kritikalitätsstufen.

Maßnahmen zur Fehlererkennung müssen so entworfen werden, dass sich das System innerhalb einer zu definierenden Zeit entweder erholt oder ein sicherer Systemzustand (Safe State oder Fail Safe State) eingenommen wird, bevor sich der Funktionsausfall zu einem signifikanten Sicherheitsrisiko entwickelt.

Daraus lassen sich grundsätzlich drei Systemzustände bezüglich dieser Fehlerbehandlung herleiten (Bild 1):

  • Application: Die Anwendung läuft wie geplant (Nominalfall). Parallel dazu läuft die Fehlererkennung dauerhaft mit. Wird ein Fehler erkannt, wird die Fehlerbehandlung (Error Recovery) aufgerufen.
  • Error Recovery: Das Steuergerät behandelt einen aufgetretenen Fehler mittels speziell dafür entwickelter Software-Funktionen. Kann der Fehler behoben werden (das System erholt sich), kann in den Zustand Application zurückgewechselt werden. Anderenfalls wird der Zustand Safe State eingenommen.
  • Safe State: In diesem Zustand ist die fehlerhafte Funktion typischerweise deaktiviert oder wird durch eine andere, einfachere Funktion abgelöst (das System degradiert).

Eine sehr einfache und gleichzeitig sehr populäre Form der Fehlerbehandlung ist der Neustart des Steuergerätes. Als Warmstart umgesetzt kann dieser in Größenordnungen von 100 ms durchgeführt werden. Zur Veranschaulichung: Bei einer Geschwindigkeit von 120 km/h legt ein Fahrzeug in 100 ms genau 3,33 m zurück. Je nach Anwendung (z.B. Motor-Management) kann ein Ausfall des Steuergerätes für eine solch kurze Zeit akzeptiert werden. Für andere Anwendungen (z.B. ESP) wird auch auf andere Behebungsmaßnahmen zurückgegriffen, z.B. Teilabschaltung und Aktivierung eines Notbetriebs (inklusive Warnlampe im Kombiinstrument).

Bei klassischen Ein-Funktions-Steuergeräten steht üblicherweise für das Ausführen der eigentlichen Funktion (Application), die Fehlererkennung sowie die Fehlerbehebung jeweils die gesamte Rechenleistung der CPU zur Verfügung. Das Echtzeitverhalten der drei genannten Szenarien kann daher mit den etablierten Methoden der Scheduling-Analyse sehr zuverlässig abgesichert und optimiert werden.

In Zukunft werden mehr und mehr Multifunktions-Steuergeräte zum Einsatz kommen. Eine Integration mehrerer Funktionen in einem solchen Steuergerät führt einerseits zu großen Kosteneinsparungen und ist dank der immer leistungsstärkeren Prozessoren heute schon möglich. Erkauft wird diese Kostenreduktion jedoch durch eine komplexere Software-Architektur. In solchen Systemen unterliegt die Umsetzung von Erkennungs- und Behandlungsmaßnahmen von Fehlern zusätz-lichen Anforderungen, insbesondere in Bezug auf das Echtzeitverhalten. Denn nun arbeiten mehrere Anwendungen parallel und müssen sich die (nun zwar höhere, aber trotzdem nur einmal vorhandene) Rechenleistung des Prozessors untereinander aufteilen. Dazu sind angepasste Software-Architekturen notwendig, insbesondere geeignete Schedules, um das Risiko von unerlaubten Interferenzen nach ISO 26262 in solchen Mixed-Criticality-Systemen zu vermeiden.

Ein Fehler darf keine Fehlerkaskade auslösen

Besonders deutlich werden diese zusätzlichen Anforderungen bei der Fehlerbehandlung. Die ISO 26262 erwartet grundsätzlich, dass ein Fehler in einer Anwendung nicht zu einer Kaskade von Fehlern in anderen Anwendungen führt. Das heißt, die Fehlererkennung und -behandlung einer Applikation muss parallel zur normalen Ausführung anderer Applikationen möglich sein. Dies führt zu weiteren Systemzuständen, die abgesichert werden müssen (Bild 2). Die Zahl der Zustände steigt dabei exponentiell mit der Zahl der integrierten Funktionen: 3 n (Vergleiche: 3 × n bei Einzelfunktions-Steuergeräten).

Zwischenfazit: Nach strenger Auslegung der ISO 26262 kommen nur solche Recovery-Maßnahmen infrage, die keine (oder nur begrenzte) Auswirkungen auf weitere Applikationen haben. Dazu gehören z.B.: Neustart der Funktion oder von Teilen des Betriebssystems-Sche-dules, Abschalten der Funktion und/oder Start einer anderen Notlauffunktion. Auch diese Funktionen dürfen grundsätzlich keine Beeinflussung auf die anderen Funktionen ausüben; das gilt insbesondere für die Rechenleistungsanforderungen und das Echtzeitverhalten. Daraus folgt, dass diese kombinierten Echtzeitverhalten ebenfalls abgesichert werden müssen. Unter Umständen lassen sich einige der Zustände eliminieren, indem argumentiert wird, dass Recovery-Mechanismen einer Applikation Vorrang haben vor der normalen Ausführung anderer Applikationen. Dadurch wird eine Beeinflussung explizit in Kauf genommen, was applikationsabhängig begründet werden kann. Untersucht werden muss aber, was dies für die verdrängte Funktion bedeutet.

Will man durch Tests die notwendige Abdeckung erreichen, müsste man dazu sämtliche in Bild 2 gezeigten Kombinationen auf dem Prüfstand ausführen, d.h. Fehlerkombinationen gezielt und aus Rechenleistungssicht zu jeweils ungünstigen Zeitpunkten per Testmuster injizieren. Dies ist schon bei Einzelfunktions-Steuergeräten schwierig und man geht daher heute den Weg über Scheduling-Analysen. Deren Vorteil ist das gezielte Überprüfen von komplexen Situationen, für die nur wenige oder keine Testmuster existieren. Bei Multifunktions-Steuergeräten macht sich diese Vorgehensweise besonders bezahlt.