Fehlerbaumanalyse (FTA) für Safety gemäß ISO 26262

Bei der verteilten Entwicklung ist eine gut definierte Schnittstelle von zentraler Bedeutung. Gleiches gilt für die im Rahmen der ISO 26262 notwendigen Analysen, um das verbleibende Restrisiko einer Verletzung der Sicherheitsziele (SZ) zu quantifizieren und nachzuweisen. Eine ganzheitliche und durchgehende Analyse von der obersten Hierarchie-Ebene (SZ) bis zur letzten Ebene (Hardware-Elemente) stellt bei der verteilten Entwicklung im Automobilsektor nach wie vor eine Herausforderung dar. Anstelle des Austauschs kompletter Analysedateien werden nur minimale Metriken übergeben – dies zeigt die aktuelle Praxis.

OEMs und Zulieferer wollen ihr Know-how schützen. Ein Austausch von Analysedateien würde für die Beteiligten quasi dem Öffnen der Black-Box gleichkommen. Auch wenn die Zulieferer sich bereit erklärten, die Analyse bis zu einem gewissen Detaillierungsgrad in Form eines Dokumentes zu übergeben, ist eine Nachbildung der Analysen bei der Bottom-Up-Integration zu aufwendig und daher nicht praktikabel.

Weiterhin besteht in der Praxis die Herausforderung, dass die Zielvorgaben der OEMs hinsichtlich der Metriken für die Zulieferer häufig kaum erreichbar sind. Zurückzuführen ist dies unter anderem auf eine ungeeignete Modellierung an der Schnittstelle.

Eine Metrik über das verbleibende Restrisiko im System ist die PMHF (Probabilistic Metric for Random Hardware Failures) beziehungsweise Restfehlerrate. Eine von der ISO 26262 empfohlene Methode, um diese Metrik zu bestimmen und nachzuweisen, ist die Fehlerbaumanalyse (FTA, Failure Tree Analysis; siehe ISO 26262-5, Abschnitt 9.2).

Eigensichere Systeme bleiben Wunschdenken

Der Gedanke von eigensicheren Systemen ist schön und würde die verteilte Entwicklung aus Perspektive der funktionalen Sicherheit (FuSi, Safety) stark vereinfachen. In der aktuellen Praxis, etwa in den Bereichen Elektrotechnik, Elektronik und Automobiltechnik, ist dies jedoch kaum praktikabel. Systeme im Fahrzeug sind miteinander so vernetzt wie noch nie – Tendenz steigend. FuSi-Funktionen benötigen oft mehrere externe Signale, die von verschiedenen Steuergeräten stammen. Da die Steuergeräte nicht für jedes Signal eine eigene physikalische Verbindung zu jedem Signalempfänger haben oder die Berechnung der Signale nicht durch unterschiedliche Module erfolgt, kann im Extremfall ein einziger Fehler in einem Steuergerät mehrere gefährliche Systemzustände hervorrufen.

In Bereich funktionaler Sicherheit spielen Ausfälle aufgrund einer gemeinsamen Ursache (Common Cause Failure oder CCF) eine große Rolle. Unabhängig von der notwendigen Integrität der Sicherheitsfunktionen sollte man sich damit auseinandersetzen, denn CCF können das richtige und vor allem sichere Zusammenspiel zwischen den Funktionen im Fahrzeug verhindern. Auf der anderen Seite bringt die Berücksichtigung von CCF bei der Quantifizierung des Restrisikos in den meisten Fällen Vorteile, weil ein CCF nur einmal in die Berechnung einfließt.

Verteilte Fehlerbaumanalyse

Eine geeignete Analysemethode, um CCF zu identifizieren und das Restrisiko einer SZ-Verletzung zu quantifizieren, ist die Fehlerbaumanalyse. Bei der verteilten Entwicklung ergibt sich zwangsläufig auch eine verteilte Fehlerbaumanalyse (Bild 1). Die Herausforderung besteht darin, dass alles, was man als Organisation nicht selber entwickelt, im Prinzip eine Black-Box darstellt. Eine definierte Schnittstelle, um CCF zu finden und in den verteilten Analysen zu berücksichtigen, ist unerlässlich.

Bild 1: Fehlerbaumanalyse in der verteilten Entwicklung. Invensity

Der Fehlerbaum-Integrator (FBI) in Bild 1 ist der Kunde der Black-Box-Zulieferer (BBZ). Er spezifiziert Anforderungen an Signale und Funktionalitäten, damit das Sicherheitskonzept auf Systemebene richtig funktioniert. Die Black-Box-Zulieferer liefern Signale oder Funktionalitäten, die der FBI wiederrum braucht, um die funktionale Sicherheit zu gewährleisten. Sie liefern auch die Restfehlerraten ihrer Black-Box in Bezug auf die Anforderungen des FBIs.

In der Praxis finden CCF-Anteile der Black-Box-Zulieferer vom Fehlerbaum-Integrator wegen einer nicht richtigen Definition der Schnittstelle oft keine Berücksichtigung. Im Extremfall kann dies auf der einen Seite dazu führen, dass die Sicherheitskonzepte systematische Lücken aufweisen. Auf der anderen Seite bleiben die Zielwerte der Metriken für Fahrzeugfunktionen (High-Level) unerreicht.

Analyse durch sicherheitsziel-orientierte Restfehlerraten

Die einfachste Möglichkeit, die Schnittstelle in Bezug auf Restfehlerraten zu definieren, zu analysieren und zu modellieren, sind SZ- beziehungsweise sicherheitszielorientierte Restfehlerraten. Hier erfolgt nur die Bildung und Übergabe einer gesamten Metrik pro SZ und Black-Box. Die Betrachtung der Signale und Funktionen erfolgt hier nicht isoliert, sondern als Gesamtpaket. Die Zusammenhänge zwischen den Signalen und Funktionen innerhalb einer Black-Box finden somit Berücksichtigung. Der Fehlerbaum-Integrator muss aber an dieser Stelle als Bindeglied und Kommunikationsschnittstelle zwischen den unterschiedlichen Black-Box-Zulieferern agieren.

Hierfür muss der Fehlerbaum-Integrator dem Black-Box-Zulieferer die Signale und Funktionen transparent kommunizieren, die am Erreichen des jeweiligen SZ beteiligt sind und sich innerhalb der Black-Box befinden. Die BBZ können dann die Zusammenhänge zwischen den Paketelementen pro SZ modellieren und eine Metrik für das Gesamtpaket übergeben. Diese Modellierung bildet die Realität deutlich besser ab, was dazu führt, dass die Gesamtmetrik meist besser ist als die Summe der Einzelbetrachtung. Der Fehlerbaum-Integrator fasst anschließend die Ergebnisse aller Black-Box-Zulieferer zusammen und errechnet die finale Metrik auf SZ-Ebene.

Modellierung bei der Bottom-Up-Fehlerbaum-Integration

Bild 2 zeigt ein Beispiel für eine Modellierung bei der Bottom-Up-Fehlerbaum-Integration. In der Regel werden dem Fehlerbaum-Integrator Metriken für Top-Events (gebildet von den BBZ) wie zum Beispiel „das Signal kommuniziert fälschlicherweise den gefährlichen Fehler“ oder „die Funktion nimmt einen gefährlichen Zustand an, ohne dass es bemerkt wird“ übergeben. Die Praxis zeigt, dass diese Schnittstellenebene nicht geeignet ist. Durch die hier vorgestellte Methode bilden Black-Box-Zulieferer eine Gesamt-Metrik für eine mit dem Fehlerbaum-Integrator abgestimmte Kombination an Top-Events. Aus dem Beispiel in Bild 2 geht hervor, dass die Gesamtmetrik kleiner ist als die Summe der Top-Events, da der µC-Fehler nur einmal Berücksichtigung findet.

Bild 2: Beispiel für eine Modellierung bei der Bottom-Up-Fehlerbaum-Integration. Invensity

Sollten Black-Box-Zulieferer externe Signale für ihre Sicherheitsfunktionen benötigen, müssen sie dies dem Fehlerbaum-Integrator mitteilen. Innerhalb einer Black-Box ist es möglich, externe Signale von der Betrachtung erstmals auszuschließen. Der Fehlerbaum-Integrator soll auch die Berücksichtigung von Diagnosen an den Kommunikationsschnittstellen zwischen den unterschiedlichen Black-Boxes koordinieren.

Diese Modellierungsmethode ist eine konservative Näherung, da Plausibilisierungen von internen mit externen Signalen innerhalb der Black-Boxes keine Berücksichtigung gemäß Fehlerbaum-Logik finden. CCF innerhalb der Black-Boxes finden jedoch Berücksichtigung, so dass am Ende die berechneten Restfehlerraten auf Fahrzeugfunktions-Ebene in der Regel die Vorgaben erreichen (für ASIL B und C).

Ist der Anteil an Plausibilisierungen mit externen Signalen groß oder erfolgt eine Dekomposition auf zwei unterschiedlichen Black-Boxes, stößt die SZ-orientierte Modellierung an ihre Grenzen. An dieser Stelle finden dann detailliertere Modellierungsmethoden Anwendung.

Analyse durch Analogmodelle

Die hier diskutierte Bildung eines Analogmodells ist zusammengefasst die quantitative Abstraktion von Zusammenhängen innerhalb einer Black-Box durch ein vereinfachtes Modell. Das vereinfachte Modell verhält sich aber an der Integrationsschnittstelle analog zum Gesamtmodell. Die Unterschiede zur SZ-orientierten Modellierung und zur aktuellen Praxis sind, dass hier weder die Übergabe einer gesamten Metrik, noch die einzelne Betrachtung der Signale und Funktionen erfolgt, sondern eine Mischung aus beidem.

Bild 3: Quantifizierung der Zusammenhänge innerhalb einer Black-Box. Invensity

Hierzu ein Beispiel: Ein BBZ (BBZ1) benötigt für sein Sicherheitskonzept (zum Beispiel für eine interne Plausibilisierung) zwei externe Signalen aus einer fremden Black-Box (BBZ2). In der aktuellen Praxis würde BBZ2 nur einzelne Restfehlerraten für jedes Signal (ω_Absolut ) bereitstellen. Die Zusammenhänge zwischen beiden Signalen könnten von BBZ1 bei dieser Vorgehensweise keine Berücksichtigung finden. Um hier entgegenzuwirken erfolgt die Bildung eines Analogmodells. Hierfür muss BBZ2, zusätzlich zu den einzelnen Signal-Restfehlerraten, den CCF-Anteil beider Signale berechnen und übergeben. Dies kann mit einem einfachen „Trick“ schnell und unkompliziert erfolgen: beide Signale werden mit einem UND-Gatter verknüpft (Bild 3). Das Ergebnis ist der CCF-Anteil beider Signale (ω_CCF ). Diese Information dient zur Bildung des Analogmodells.

Im Analogmodell setzt sich die Restfehlerrate von jedem einzelnen Signal aus dem CCF-Anteil des Signalpaketes und dem Eigenanteil des Signals zusammen (ω_Absolut + ω_Eigenanteil). Somit lässt sich der Restfehlerraten-Eigenanteil der Signale (ω_Eigenanteil ) durch die Differenz aus ω_Absolut und ω_CCF und berechnen.

Bild 4: Bildung des Analogmodells anhand der Ergebnisse aus Bild 3. Invensity

Das Analogmodell bildet eine neue Ebene im Fehlerbaum. In dieser Ebene findet eine Abstrahierung der Zusammenhänge innerhalb der Black-Box auf einem höheren Level statt (Bild 4). Die Betrachtung von Signalen erfolgt nicht mehr einzeln. Statt dessen finden die Zusammenhänge in den verteilten Analysen Berücksichtigung. Die Folge ist eine deutlich genauere Berechnung der Restfehlerraten innerhalb der gesamten Bottom-Up-Integration der Fehlerbaumanalyse.

Da meistens keine direkte Kommunikation zwischen den unterschiedlichen BBZ stattfindet, muss der Fehlerbaum-Integrator hier auch als Kommunikationsschnittstelle agieren. Er muss die Signal- und Funktionspakete definieren und die Modellierung auf den unterschiedlichen Black-Boxes koordinieren. BBZ müssen nur einen geringen Mehraufwand für die Bildung der CCF-Anteile der definierten Signal- und Funktionspakete investieren.

Auch die Zusammenhänge von gesamten Funktionalitäten innerhalb der Black-Box lassen sich dadurch modellieren. Diese Modellierung lässt sich theoretisch auf beliebig große Signal- und Funktionspakete anwenden.

(hb)