Safety Automotive
Fehlertolerante Systeme im Fahrzeug – von "fail-safe" zu "fail-operational"
Fortsetzung des Artikels von Teil 1
Fail-Safe-Systeme
Bei funktionalen Sicherheitssystemen im Fahrzeug herrschen heute im Wesentlichen Systeme vor, die einen sicheren Systemzustand – Safe System State– kennen, der bei einen Gesamtausfall des E/E-Systems eingenommen werden kann, und von wo aus keine Gefahr ausgeht. Solche Systeme werden auch als Fail-Safe-Systeme bezeichnet. Bei diesen Systemen wird davon ausgegangen, dass das E/E-System entweder eine fehlerfreie Funktion oder beim Gesamtausfall gar keine Funktion liefert. Diese Eigenschaft wird üblicherweise als Abschaltausfall – Fail-Silent – bezeichnet. Ein Beispiel hierfür ist eine elektrische Lenkkraftunterstützung bei einem Kleinfahrzeug. Im Wesentlichen wird die Lenkkraftunterstützung beim Rangieren benötigt. Ein Abschaltausfall der Unterstützungsfunktion ist somit ungefährlich, weil die Lenkfunktion noch mechanisch über das Ritzel erbracht werden kann. Eine Fehlfunktion, wie ein unerwartetes Drehmoment bei hoher Geschwindigkeit, ist jedoch gefährlich und muss daher durch entsprechende Gegenmaßnahmen, die im einfachsten Fall aus dem Abschalten der Lenkkraftunterstützung bestehen können, verhindert werden. Sollte die Fehlerursache transienter Natur gewesen sein, so steht die Lenkkraftunterstützung nach einem Reset und Selbsttestzyklus wieder unvermindert zur Verfügung.
Sollte das Abschalten jedoch zu häufig erfolgen oder die Fehlerursache nicht transienter Natur gewesen sein, nimmt der Fahrer erstmals ein Zuverlässigkeitsproblem und bei fortdauerndem Ausfall ein Verfügbarkeitsproblem wahr. Um dem entgegenzuwirken, werden deshalb auch bei Fail-Safe-Systemen häufig zusätzliche Fehlertoleranzmaßnahmen ergriffen.
Fail-Operational-Systeme
Bei einem System, wo das Abschalten des E/E-Systems im Fehlerfall gefährlich ist, weil es zumindest eine kritische Betriebsphase des E/E-Systems gibt, in der durch sein Abschalten ein oder mehrere Sicherheitsziele verletzt werden, müssen schon aus funktionalen Sicherheitsgründen Fehlertoleranzmaßnahmen vorgesehen werden, die im Fehlerfall zumindest einen Notbetrieb ermöglichen. Solche Systeme werden deshalb als Fail-Operational-Systeme bezeichnet. Aus ökonomischen Gründen geht man üblicherweise von einer Ein-Fehler-Annahme aus. Das bedeutet, dass das E/E-System hinsichtlich seiner Fehlertoleranzmaßnahmen so ausgelegt ist, dass bei der Annahme eines einzelnen fehlerhaften Bereichs innerhalb der kritischen Betriebsphase der notwendige restliche Funktionsumfang aufrechterhalten werden kann.
Die Abgrenzung zwischen Fehlertoleranzmaßnahmen zur Steigerung der Zuverlässigkeit und der Verfügbarkeit und denen, die zum Betrieb von Fail-Operational-Systemen notwendig sind, erscheint vorerst diffus. In beiden Fällen kommen verschiedene Redundanztechniken wie strukturelle Redundanz, funktionelle Redundanz, Informationsredundanz und Zeitredundanz als Fehlertoleranzmaßnahmen zum Einsatz. Ein wesentlicher Unterschied liegt jedoch in der Betrachtung abhängiger Fehler – Dependent Failures. Im Fall von zuverlässigen und hochverfügbaren Fail-Safe-Systemen sind abhängige Fehler, die zu einem Abschaltausfall – und damit sicheren Ausfall – des Systems führen können, hochgradig unerwünscht, letztlich aber akzeptabel. Inakzeptabel sind natürlich die abhängigen Fehler, die zu einem gefährlichen Ausfall führen. Im Falle von Fail-Operational sind abhängige Fehler, die durch Kopplung zu einem Abschaltausfall des Systems in der kritischen Systemphase führen, jedoch gefährlich und müssen deshalb ausreichend adressiert werden. Dieser Aspekt ist insbesondere bei der Auslegung von kritischen Ressourcen, zum Beispiel der Spannungsversorgung und der Taktversorgung, wesentlich, sofern nicht nachgewiesen werden kann, dass die Fehlerrate dieser Ressourcen hinreichend niedrig ist. Gerade bei der Spannungsversorgung müssen neben den intrinsischen Fehlerraten auch externe Effekte, wie elektromagnetische Interferenz (EMI), in Betracht gezogen werden. ISO 26262 [3] (Band 9, Kapitel 7 ff.) verlangt zur Vermeidung abhängiger Fehler die Betrachtung verschiedener Aspekte, wie die Kopplung auf Hardware-Ebene durch physikalische Defekte, Fehlerursachen, die in der Entwicklungsphase eingebracht werden, Herstellungsfehler, Installationsfehler, Reparaturfehler, Aspekte der Betriebsumgebung, wie Temperatur, EMI, Feuchtigkeit, und mechanische Belastung, die Nutzung kritischer Ressourcen, wie Takt, Reset und die Spannungsversorgung, und Aspekte der Systemalterung.
Jobangebote+ passend zum Thema
Beispiele für eine Fail-Safe-Architektur
Bild 1 zeigt eine typische Fail-Safe-Architektur. Das Grundprinzip besteht aus einer Überwachung mittels Monitoren, beispielsweise im Fall von Spannung durch diverse Spannungsmonitore, Taktmonitore und Sensormonitore auf Systemebene.
Alternativ oder ergänzend kommt strukturelle Redundanz in Kombination mit Vergleichsoperationen dort zur Anwendung, wo die Komplexität oder die physikalischen Begebenheiten ein einfacheres Monitoring nicht zulassen. Beispiele hierfür sind Lockstep-CPUs, wie sie zum Beispiel in Infineons Aurix-Familie zum Einsatz kommen. Schon heute kommen neben den Fehlererkennungsmaßnahmen auch zuverlässigkeits- und verfügbarkeitssteigernde Maßnahmen zur Anwendung. Die Mikrocontroller der Aurix-Familie beinhalten zum Beispiel spezielle Fehlerkorrektur-Codes für Speicherworte, um nebst Einfach- auch Zweifachfehler korrigieren zu können. Aus reiner Sicherheitsbetrachtung ist das nicht notwendig. Aus Sicht der Verfügbarkeit ist es gerade für Speicherbereiche, in denen hohe Informationsdichten vorherrschen, jedoch sinnvoll, das Fahrzeug auch mit Einfachbitfehlern im Feld belassen zu können. Des Weiteren sind eine Vielzahl hinreichend unabhängiger Peripheriemodule vorhanden, um systemweite Verfügbarkeitsstrategien in Software umsetzen zu können. Um die Abhängigkeit vom Quarz zu mindern, gibt es eine spezielle Überwachung des Quarzes, die durch automatische Umschaltung auf einen Chip-intern erzeugten Back-up-Takt auch bei Ausfall des Quarzes noch einen reduzierten Betrieb ermöglicht. Letztlich sind auch extensive Selbsttestmaßnahmen, die über eine in der Software implementierte SafeTLib angesteuert werden können, vorhanden, um zum Beispiel nach einem Fehlerfall zwischen transienten und permanenten Fehlern unterscheiden zu können.
Der Übergang von Fail-Safe auf Fail-Operational bedingt typischerweise eine entsprechend umfangreichere Systemarchitektur, wie nun an einigen Beispielen dargelegt werden soll.
- Fehlertolerante Systeme im Fahrzeug – von "fail-safe" zu "fail-operational"
- Fail-Safe-Systeme
- Beispiele für Fail-Operational-Architekturen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Forum Funktionale Sicherheit 2014
Fehler sind menschlich
Fahrerassistenz
Subaru bringt Eyesight nach Deutschland
Verkehrszeichenerkennung
Smartphone-App von Bosch im Google-Play-Store verfügbar
