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.
Preface
The method rests on a deliberately restricted internal block diagram of the system, read in a disciplined form built on a fixed set of ports through which signals, energy, and information propagate. From that description the fault tree is derived by following the propagation paths. The central claim: if the ibd is correct, the derived fault tree is complete and correct.
Introduction
A structurally wrong tree yields wrong results with full mathematical rigor, so the structure must be derived from an ibd rather than guessed. Because the tree mirrors real fault propagation, its minimal cut sets are real combinations, not artifacts of how it was drawn. Fully addressed events, common causes, cascading failures, safety-measure placement, and reuse then fall out of the correct structure.
Teil 1 — Grundlagen
Fünf Dinge, die feststehen müssen, bevor ein Gatter gezeichnet wird.
Functions and Systems
A clean separation of function and system is a matter of result quality, not vocabulary. The chapter distinguishes logical from technical interface descriptions, settles who owns which specification between customer and supplier, and carries the same split into the functional and technical safety concepts. The malfunction, owned by the customer, is what the fault tree takes as its top level event.
The Standard Model of a Function
A single generic model names the five categories of input signal — input data, trigger, resources, noise, and the development process itself — and two of output signal. Its value is to make explicit the influences that lie off the normal signal flow and are, for that reason, most easily forgotten. Kept as a checklist, it turns construction from invention into derivation along the signal path.
Locating the System Level
Functions and systems form a hierarchy from road traffic down to a component, and the same derivation applies at each. Safety goals and the hazard analysis belong to the base functions; every other function receives a functional safety concept for its own malfunctions. The main body fixes the system level — a supplier's ECU whose malfunctions are its trees' top level events.
The Running Example: The Windshield-Wiper ECU
The windshield-wiper control ECU is placed in the context that requires it and then examined from the inside, as a system of subsystems along an internal signal path. The example is deliberately simple, so its trees never grow past the point where their structure can still be seen. The block diagram is not an illustration but the ibd the fault tree is derived from.
Systematic Derivation of the Top Level Events
A malfunction that is never written down is a fault tree that is never built, so the failure modes of a function must be enumerated completely. From a state diagram they follow mechanically — one false positive per forbidden transition, three modes per specified one — and analog outputs yield the same once their range is divided into functional bands. The chapter derives the wiper's OffNotSlow malfunction.
Teil 2 — Konstruktion des Fehlerbaums
Das Herz des Buchs: der Baum, entlang des Signalpfads der ibd abgeleitet.
Initial Fault Trees
The first level maps the malfunction onto the failure cases of the system's output signals — and only those — joined by OR where any one suffices and by AND where several must coincide. Because each event is generated from the ibd, it carries a complete structured address: its kind, location, exact connection, fault mode, and rate. That is what later lets a cut set be a located combination of real faults.
The Standard Fault Tree Pattern
An output-signal failure has only two sources: the system processed correct inputs wrongly, or it passed through an already-faulty input — a system failure OR an input-signal failure. An input signal is some other system's output, so every leaf is again a function failure, the top of a fresh application of the same pattern. The tree grows in two directions at once, downward and backward.
Fault Tree of the System ECU
Applied subsystem by subsystem along the signal path, the pattern assembles the ECU's whole tree, with the microcontroller's transition condition telling a system failure apart from an input-signal failure at each node. Tracing the switch signal to the boundary and back reveals that the ECU both reads and powers the switch — so the microcontroller is, by construction, a common cause. The structure surfaced it.
Verification Fault Tree
Because a system is anything that processes information, the method that builds an ECU's tree builds a review meeting's, changing nothing but the kind of system. The chapter analyzes how a verification can miss a defect — a poor template, missing competence, time pressure, a misread sentence. These process sub-trees are product-independent, reused across projects almost unchanged, and reuse is itself a safety measure.
External Components and Input Signals
A modern system is assembled from many manufacturers' parts, so the tree routinely reaches an input someone else builds. The same standard pattern carries it across: the top level events handed to the component supplier, how the two trees join without losing structure, and how requirements and probability budgets cross the boundary. An interface basic event is a requirement.
Teil 3 — Analyse, Konzept, Qualität
Der fertige Baum wird beantwortet: Cut Sets, Quantitatives mit Vorsicht, Maßnahmen, Safety Case, Qualität.
Qualitative Fault Tree Analysis and Minimal Cut Sets
A minimal cut set is a combination of faults that together cause the malfunction, and its order tells single points from double faults at a glance. Because the tree was derived along the signal path, each cut set is a real fault-propagation combination that can be trusted. The chapter triages long lists with importance measures and argues the qualitative road matters most: it forces the questions safety turns on.
Quantitative Considerations
The Boolean structure turns basic-event rates into a PMHF, and the standard sets limits per ASIL — but the result must be treated with utmost caution, because the variance of its catalog-and-mission-profile inputs cannot be stated and so cannot be propagated. The number's honest job is ranking alternatives; what decides whether a product is safe is the qualitative structure, not a decimal place.
Safety Measures and Requirements Decomposition
A measure enters the tree not as a description but as its own failure event, ANDed at the point where it acts in the fault-error-failure chain — turning a single point into a double fault. Where the AND goes matters more than the AND itself. Requirements decomposition is the same move one level up, valid only where the two parts are genuinely independent, and it never relaxes the integration, verification, or FMEDA the original ASIL demands.
The Fault Tree in the Safety Case
A safety case must be an argument of claims and evidence, not a list of documents that proves nothing. The claim structure branches exactly as the tree does — per function, per malfunction, per root cause, per measure — with the remaining cut sets as the itemized residual risk. Completeness must itself be claimed at every level, where the book's construction-backed guarantee is spent honestly.
Quality Criteria of a Fault Tree
Measures read off a faulty tree can miss the real single point or guard a phantom, so the tree must be checked before it is trusted. Treating the tree itself as a system that implements the safety analysis, the chapter derives its quality criteria and condenses them into a reviewer's checklist. Most of those questions answer themselves when the tree was derived from a complete ibd.
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, Safety-Mechanismen.
Appendix A — A Wider Scope: Vehicle and Road Traffic
The identical procedure points one scale up at the vehicle within road traffic, with even the driver modeled by the standard ports. Safety goals become the top level events, and a two-second bound sits at the apex as a fault-tolerant time interval in all but name. The levels nest into one continuous tree from a hazard to a single component's basic event.
Appendix B — The Software Level
A clean system tree already hands the software its requirements, so a software fault tree is not a finer-grained re-run of it. It earns its place only for the internal interfaces the system level cannot express: shared dependencies that turn independent-looking elements into common causes, and interference across shared memory. The wiper example shows both.
Appendix C — The Hardware Level: A Headlight Driver
A headlight FET driver is analyzed across three designs for the same top event — both headlights out. One FET is an indefensible single point; splitting into two cuts the risk roughly threefold but moves the limiter to the shared supply and controller; a cyclic sense feedback leaves the aggregate unchanged yet is what makes the redundancy real. Redundancy and diagnosis answer different metrics.
Appendix D — Diagnostic Coverage from the Implementation
Diagnostic coverage is defined against a specific mechanism and its specific failure modes, not entitled by a class quoted from a standard's table. A range check catches an open circuit but not a plausible-but-wrong reading. Derived from the tree, coverage becomes readable: a covered mode moves off the order-1 list, an uncovered one stays a single point, and detection after the FTTI is no coverage at all.
Appendix E — Driving a Hazard Analysis with the Method
The hazard analysis is fragile at its very first step — naming, completely, the hazards a function can produce — and a whiteboard list is only as complete as the room's imagination. That step is the book's systematic malfunction derivation run at the vehicle base function. The method makes the hazard list complete and leaves the risk rating, honestly, to the people who must own it.
Appendix F — SOTIF: More Root Causes, Not a Second Framework
A vehicle function can be dangerous with nothing broken — a camera blinded by low sun, a classifier meeting an unseen shape. SOTIF needs no framework of its own: it supplies additional root causes for the very malfunctions the tree already analyzes, and the standard model's noise and world inputs already have slots for them. The tree makes the cause categories complete; validation remains SOTIF's to own.
Appendix G — The Fault-Tolerant Time Interval
The FTTI is read loosely because its start is disputed. It does not measure the age of a fault; it measures how long the malfunction may persist, so the clock starts when the fault first shows at the output. From that fixed start: one FTTI and safe state per malfunction, set by the customer, and a fault tree of its own whose top event is safe state not reached in time.
Appendix H — A Standardized Architecture for Safety Mechanisms
Safety mechanisms are all diagnostic functions — watch a signal, confirm a fault, react in time — yet scattered implementations share a processor, timebase, and scheduler no one ever drew. The chapter proposes one architecture of detectors and a central fault manager, then derives its fault tree: the residual single points are the safe-state actuation, and the manager and platform are common causes across every fault case.