Fehlerbäume ableiten,
nicht zeichnen.
Eine strukturierte und systematische Methode
Die Struktur eines Fehlerbaums entscheidet über den Wert der Analyse mindestens so sehr wie die Rechnung darauf. Dieses Buch leitet den Baum aus einem internen Blockdiagramm (ibd) des Systems ab — sodass seine minimalen Cut Sets reale Fehlerkombinationen sind, keine Artefakte der Zeichnung.
Zu jedem Kapitel eine freie Zusammenfassung. Für den Volltext — alle abgeleiteten Fehlerbäume, Cut-Set-Analysen, durchgerechneten Beispiele — hier direkt anmelden (Login und Konto in einem Schritt):
Vorspann
Die These und ihr Preis: warum ein Fehlerbaum abgeleitet und nicht gezeichnet wird.
Vorwort
Nicht zweite Auflage, nicht Übersetzung: eine Neufassung des Buchs von 2015, das beschreibt, wie ein Fehlerbaum *erstellt* wird — nicht, wie man ihn auswertet. Geschärft hat sich der Anspruch: ein durchgängiges Verfahren, das den Baum aus einer Systembeschreibung ableitet, statt ihn zu zeichnen. Für Verantwortliche der funktionalen Sicherheit und Systemarchitekten — und alle, die mit der FTA Ursachen finden.
Einleitung
Ein strukturell falscher Baum liefert falsche Ergebnisse mit voller mathematischer Strenge — die Struktur muss also aus einer ibd abgeleitet und nicht geraten werden. Weil der Baum die reale Fehlerfortpflanzung spiegelt, sind seine minimalen Cut Sets reale Kombinationen, keine Artefakte der Zeichnung. Vollständig adressierte Ereignisse, gemeinsame Ursachen, kaskadierende Ausfälle, die Platzierung von Sicherheitsmaßnahmen und Wiederverwendung fallen dann aus der korrekten Struktur heraus.
Teil 1 — Grundlagen
Die fünf Dinge, die feststehen müssen, bevor ein Gatter gezeichnet wird.
Funktionen und Systeme
Eine saubere Trennung von Funktion und System ist eine Frage der Ergebnisqualität, nicht des Vokabulars. Das Kapitel unterscheidet logische von technischen Schnittstellenbeschreibungen, klärt zwischen Kunde und Lieferant, wem welche Spezifikation gehört, und trägt dieselbe Trennung in das funktionale und technische Sicherheitskonzept. Die Fehlfunktion, die dem Kunden gehört, nimmt der Fehlerbaum als sein Top-Level-Event.
Das Standardmodell einer Funktion
Ein einziges generisches Modell benennt die fünf Kategorien von Eingangssignalen — Eingangsdaten, Trigger, Ressourcen, Störeinflüsse und den Entwicklungsprozess selbst — und zwei von Ausgangssignalen. Sein Wert liegt darin, die Einflüsse explizit zu machen, die abseits des normalen Signalflusses liegen und gerade deshalb am leichtesten vergessen werden. Als Checkliste geführt, macht es aus der Konstruktion eine Ableitung entlang des Signalpfads.
Die Systemebene verorten
Funktionen und Systeme bilden eine Hierarchie vom Straßenverkehr hinab bis zur Komponente, und auf jeder Ebene gilt dieselbe Ableitung. Sicherheitsziele und die Gefahrenanalyse gehören zu den Basisfunktionen; jede andere Funktion erhält ein funktionales Sicherheitskonzept für ihre eigenen Fehlfunktionen. Der Hauptteil legt die Systemebene fest — das Steuergerät eines Lieferanten, dessen Fehlfunktionen die Top-Level-Events seiner Bäume sind.
Das durchgehende Beispiel: das Scheibenwischer-Steuergerät
Das Steuergerät der Scheibenwischer wird in den Kontext gestellt, der es verlangt, und dann von innen betrachtet — als System von Teilsystemen entlang eines internen Signalpfads. Das Beispiel ist bewusst einfach, damit seine Bäume nie über den Punkt hinauswachsen, an dem ihre Struktur noch erkennbar bleibt. Das Blockdiagramm ist keine Illustration, sondern die ibd, aus der der Fehlerbaum abgeleitet wird.
Systematische Herleitung der Top-Level-Events
Eine Fehlfunktion, die nie aufgeschrieben wird, ist ein Fehlerbaum, der nie gebaut wird — die Fehlermodi einer Funktion müssen also vollständig aufgezählt werden. Aus einem Zustandsdiagramm folgen sie mechanisch: ein False Positive je verbotenem Übergang, drei Modi je spezifiziertem. Analoge Ausgänge liefern dasselbe, sobald ihr Bereich in funktionale Bänder geteilt ist. Das Kapitel leitet die Fehlfunktion OffNotSlow des Wischers her.
Teil 2 — Konstruktion des Fehlerbaums
Das Herz des Buchs: der Baum, entlang des Signalpfads der ibd abgeleitet.
Initiale Fehlerbäume
Die erste Ebene bildet die Fehlfunktion auf die Ausfälle der Ausgangssignale des Systems ab — und nur auf diese — verknüpft mit ODER, wo eines allein genügt, und mit UND, wo mehrere zusammentreffen müssen. Weil jedes Ereignis aus der ibd erzeugt wird, trägt es eine vollständige, strukturierte Adresse: seine Art, seinen Ort, die genaue Verbindung, den Fehlermodus und die Rate. Das macht später aus einem Cut Set eine verortete Kombination realer Fehler.
Das Standardmuster des Fehlerbaums
Ein Ausfall eines Ausgangssignals hat nur zwei Quellen: Das System hat korrekte Eingänge falsch verarbeitet, oder es hat einen bereits fehlerhaften Eingang durchgereicht — ein Systemausfall ODER ein Eingangssignal-Ausfall. Ein Eingangssignal ist der Ausgang eines anderen Systems, also ist jedes Blatt wieder ein Funktionsausfall, die Spitze einer neuen Anwendung desselben Musters. Der Baum wächst in zwei Richtungen zugleich: nach unten und nach hinten.
Fehlerbaum des Systems Steuergerät
Teilsystem für Teilsystem entlang des Signalpfads angewandt, setzt das Muster den ganzen Baum des Steuergeräts zusammen, wobei die Übergangsbedingung des Mikrocontrollers an jedem Knoten den Systemausfall vom Eingangssignal-Ausfall trennt. Verfolgt man das Schaltersignal bis zur Grenze und zurück, zeigt sich, dass das Steuergerät den Schalter zugleich liest und mit Strom versorgt — der Mikrocontroller ist also konstruktionsbedingt eine gemeinsame Ursache. Die Struktur hat sie zutage gefördert.
Fehlerbaum der Verifikation
Weil ein System alles ist, was Information verarbeitet, baut die Methode, die den Baum eines Steuergeräts erzeugt, auch den eines Review-Meetings — es ändert sich nur die Art des Systems. Das Kapitel analysiert, wie eine Verifikation einen Defekt übersehen kann: ein schlechtes Template, fehlende Kompetenz, Zeitdruck, ein falsch gelesener Satz. Diese Prozess-Teilbäume sind produktunabhängig, werden über Projekte hinweg fast unverändert wiederverwendet — und Wiederverwendung ist selbst eine Sicherheitsmaßnahme.
Externe Komponenten und Eingangssignale
Ein modernes System wird aus Teilen vieler Hersteller zusammengesetzt, also erreicht der Baum regelmäßig einen Eingang, den jemand anderes baut. Dasselbe Standardmuster trägt ihn hinüber: die Top-Level-Events, die an den Komponentenlieferanten übergeben werden, wie die beiden Bäume sich ohne Strukturverlust verbinden und wie Anforderungen und Wahrscheinlichkeitsbudgets die Grenze überschreiten. Ein Schnittstellen-Basisereignis ist eine Anforderung.
Teil 3 — Analyse, Konzept, Qualität
Der fertige Baum wird beantwortet: Cut Sets, das mit Vorsicht behandelte Quantitative, Maßnahmen, Safety Case, Qualität.
Qualitative Fehlerbaumanalyse und minimale Cut Sets
Ein minimales Cut Set ist eine Kombination von Fehlern, die zusammen die Fehlfunktion verursachen, und seine Ordnung unterscheidet auf einen Blick Einzelfehler von Doppelfehlern. Weil der Baum entlang des Signalpfads abgeleitet wurde, ist jedes Cut Set eine reale Fehlerfortpflanzungs-Kombination, der man trauen kann. Das Kapitel triagiert lange Listen mit Wichtigkeitsmaßen und argumentiert, dass der qualitative Weg am meisten zählt: Er erzwingt die Fragen, um die es der Sicherheit geht.
Quantitative Betrachtungen
Die boolesche Struktur macht aus Basisereignis-Raten einen PMHF, und die Norm setzt Grenzen je ASIL — doch das Ergebnis ist mit äußerster Vorsicht zu behandeln, weil die Varianz seiner Katalog- und Missionsprofil-Eingaben nicht angebbar und damit nicht fortpflanzbar ist. Die ehrliche Aufgabe der Zahl ist es, Alternativen zu ordnen; ob ein Produkt sicher ist, entscheidet die qualitative Struktur, nicht eine Nachkommastelle.
Sicherheitsmaßnahmen und Anforderungsdekomposition
Eine Maßnahme geht nicht als Beschreibung in den Baum ein, sondern als ihr eigenes Ausfallereignis, mit UND verknüpft an der Stelle, an der sie in der Fehler-Fehlzustand-Ausfall-Kette wirkt — aus einem Einzelfehler wird ein Doppelfehler. Wohin das UND kommt, zählt mehr als das UND selbst. Die Anforderungsdekomposition ist derselbe Zug eine Ebene höher, gültig nur, wo die beiden Teile wirklich unabhängig sind, und sie lockert nie die Integration, Verifikation oder FMEDA, die das ursprüngliche ASIL verlangt.
Der Fehlerbaum im Safety Case
Ein Safety Case muss ein Argument aus Behauptungen und Nachweisen sein, keine Dokumentenliste, die nichts beweist. Die Behauptungsstruktur verzweigt genau wie der Baum — je Funktion, je Fehlfunktion, je Grundursache, je Maßnahme — mit den verbleibenden Cut Sets als aufgeschlüsseltem Restrisiko. Vollständigkeit muss auf jeder Ebene selbst behauptet werden, und dort wird die konstruktionsgestützte Garantie des Buchs ehrlich eingelöst.
Qualitätskriterien eines Fehlerbaums
Maßnahmen, die aus einem fehlerhaften Baum abgelesen werden, können den echten Einzelfehler verfehlen oder ein Phantom absichern — der Baum muss also geprüft werden, bevor man ihm traut. Das Kapitel behandelt den Baum selbst als System, das die Sicherheitsanalyse umsetzt, leitet daraus seine Qualitätskriterien ab und verdichtet sie zu einer Reviewer-Checkliste. Die meisten dieser Fragen beantworten sich von selbst, wenn der Baum aus einer vollständigen ibd abgeleitet wurde.
Abschluss
Die gesamte Methode auf einmal, an zwei bewusst gegensätzlichen modernen Systemen.
Anhänge A–H
Dieselbe Methode auf weiteren Ebenen: Fahrzeug/Verkehr, Software, Hardware, Diagnoseabdeckung, HaRa, SOTIF, FTTI, Sicherheitsmechanismen.
Anhang A — Ein weiterer Rahmen: Fahrzeug und Straßenverkehr
Dasselbe Verfahren richtet sich eine Ebene höher auf das Fahrzeug im Straßenverkehr, wobei sogar der Fahrer über die Standard-Ports modelliert wird. Sicherheitsziele werden zu den Top-Level-Events, und eine Zwei-Sekunden-Schranke sitzt an der Spitze — ein Fault-Tolerant Time Interval in allem außer dem Namen. Die Ebenen schachteln sich zu einem durchgehenden Baum von einer Gefährdung bis zum Basisereignis einer einzelnen Komponente.
Anhang B — Die Softwareebene
Ein sauberer Systembaum übergibt der Software bereits ihre Anforderungen, ein Software-Fehlerbaum ist also kein feiner aufgelöster Wiederlauf davon. Er verdient seinen Platz nur für die internen Schnittstellen, die die Systemebene nicht ausdrücken kann: geteilte Abhängigkeiten, die scheinbar unabhängige Elemente zu gemeinsamen Ursachen machen, und Interferenz über geteilten Speicher. Das Wischer-Beispiel zeigt beides.
Anhang C — Die Hardwareebene: ein Scheinwerfertreiber
Ein FET-Scheinwerfertreiber wird über drei Designs für dasselbe Top-Ereignis analysiert — beide Scheinwerfer aus. Ein FET ist ein unhaltbarer Einzelfehler; die Aufteilung auf zwei senkt das Risiko rund um das Dreifache, verschiebt den Begrenzer aber auf die geteilte Versorgung und den Controller; eine zyklische Sense-Rückführung lässt die Summe unverändert und macht doch erst die Redundanz real. Redundanz und Diagnose beantworten unterschiedliche Metriken.
Anhang D — Diagnoseabdeckung aus der Implementierung
Diagnoseabdeckung ist gegen einen konkreten Mechanismus und dessen konkrete Fehlermodi definiert, nicht durch eine aus einer Normtabelle zitierte Klasse verbrieft. Eine Bereichsprüfung fängt einen Leitungsbruch, aber nicht einen plausibel-aber-falschen Messwert. Aus dem Baum abgeleitet, wird die Abdeckung lesbar: Ein abgedeckter Modus wandert von der Ordnung-1-Liste, ein nicht abgedeckter bleibt ein Einzelfehler, und Erkennung nach dem FTTI ist gar keine Abdeckung.
Anhang E — Eine Gefahrenanalyse mit der Methode treiben
Die Gefahrenanalyse ist an ihrem allerersten Schritt fragil — die Gefährdungen, die eine Funktion erzeugen kann, vollständig zu benennen — und eine Whiteboard-Liste ist nur so vollständig wie die Vorstellungskraft des Raums. Dieser Schritt ist die systematische Fehlfunktions-Herleitung des Buchs, angewandt auf die Fahrzeug-Basisfunktion. Die Methode macht die Gefährdungsliste vollständig und überlässt die Risikobewertung, ehrlich, den Menschen, die sie verantworten müssen.
Anhang F — SOTIF: mehr Grundursachen, kein zweites Rahmenwerk
Eine Fahrzeugfunktion kann gefährlich sein, ohne dass etwas kaputt ist — eine von tiefstehender Sonne geblendete Kamera, ein Klassifikator vor einer ungesehenen Form. SOTIF braucht kein eigenes Rahmenwerk: Es liefert zusätzliche Grundursachen für genau die Fehlfunktionen, die der Baum schon analysiert, und die Störeinfluss- und Welt-Eingänge des Standardmodells haben bereits Plätze dafür. Der Baum macht die Ursachenkategorien vollständig; Validierung bleibt SOTIFs Sache.
Anhang G — Das Fault-Tolerant Time Interval
Das FTTI wird lax gelesen, weil sein Start umstritten ist. Es misst nicht das Alter eines Fehlers; es misst, wie lange die Fehlfunktion bestehen darf — die Uhr startet also, wenn der Fehler zum ersten Mal am Ausgang sichtbar wird. Aus diesem festen Start: ein FTTI und ein sicherer Zustand je Fehlfunktion, vom Kunden festgelegt, und ein eigener Fehlerbaum, dessen Top-Ereignis lautet: sicherer Zustand nicht rechtzeitig erreicht.
Anhang H — Eine standardisierte Architektur für Sicherheitsmechanismen
Sicherheitsmechanismen sind allesamt Diagnosefunktionen — ein Signal beobachten, einen Fehler bestätigen, rechtzeitig reagieren — und doch teilen verstreute Umsetzungen einen Prozessor, eine Zeitbasis und einen Scheduler, die nie jemand gezeichnet hat. Das Kapitel schlägt eine Architektur aus Detektoren und einem zentralen Fehlermanager vor und leitet dann ihren Fehlerbaum ab: Die verbleibenden Einzelfehler sind die Ansteuerung des sicheren Zustands, und Manager und Plattform sind gemeinsame Ursachen über jeden Fehlerfall.
Anhang I — Eine Umsetzung des Konzepts: die FtaDSL
Die Methode braucht als Eingabe eine ibd — nicht ein bestimmtes Werkzeug. Dieser Anhang beschreibt eine konkrete, deterministische Umsetzung: die ibd als Text (FtaDSL), aus der ein Werkzeug den Baum mechanisch ableitet, die Cut Sets zählt und das IEC-Diagramm zeichnet. Es ist die Umsetzung, mit der jeder Baum dieses Buchs erzeugt wurde — aber eine von mehreren möglichen; ein vorhandenes Architekturmodell tut es ebenso.