Was vorher fertig sein muss
Eine ausreichend detaillierte Systembeschreibung mit Komponenten, Schnittstellen und Abhängigkeiten ist verfügbar (Architekturdiagramm, C4-Modell oder Wirkkette).
Mögliche Ausfallszenarien wurden grob skizziert, sodass das Top-Event und seine Plausibilität kontextualisiert sind.
Was vor Start vorliegen muss
Großes Whiteboard oder digitales Diagramm-Tool (z. B. draw.io, Lucidchart, OmniGraffle); FTA-Symbolik (AND-Gate, OR-Gate, Basisereignis, Top-Event); Systemdokumentation; Vorlage für Wahrscheinlichkeiten und Sub-Ereignisse.
Ein FTA-Coach mit Erfahrung in Reliability oder Safety Analysis; 3-6 Experten aus betroffenen Domänen (z. B. SW, HW, Netz, Daten, Ops); ein Scribe für Annahmen und Quellen; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.
Top-Event als ein präziser, unerwünschter Zustand (z. B. „Falsche Dosierung in Patient verabreicht“); Systemdiagramm; verfügbare Ausfallraten oder Schätzungen pro Komponente; Standards oder Normen, falls regulatorisch relevant.
Initial 4-8 h, danach iterative Refinements pro Subbaum
Top-Event groß oben am Board als Rechteck. FTA-Symbolik als Plakat sichtbar. Sektion „Annahmen“ separat führen, jede Annahme nummeriert. Regel: AND-Gates verbinden Ereignisse, die gleichzeitig zutreffen müssen; OR-Gates verbinden alternative Ursachen.
Die eine Frage, die diese Methode beantwortet
Welche logischen Kombinationen von Basisereignissen führen zum unerwünschten Top-Event, und welche minimalen Cut Sets sind so kritisch, dass sie Maßnahmen erfordern?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Top-Event und Systemgrenze | 30-45 min | Top-Event präzise formulieren: Zustand, Schwellwert, Zeitfenster, betroffenes System. Systemgrenze definieren: was gehört in den Baum, was wird als Black Box behandelt. | Wenn Top-Event nicht eindeutig (z. B. „System fällt aus“ ohne Definition), ist Baum beliebig. Definition mit Akzeptanzkriterien, am besten testbar. |
2Phase 2: Erste Verzweigungsebene | 45-60 min | Welche unmittelbaren Vorbedingungen müssen zutreffen, damit Top-Event eintritt. Unterscheiden: AND (alle gleichzeitig) oder OR (eine reicht). Diese Ebene als Sub-Ereignisse unter Top-Event. | Häufiger Fehler: zu schnelle Verfeinerung. Erste Ebene muss vollständig sein, sonst fehlt strukturelle Logik. Test: würde diese Ebene allein das Top-Event erklären, wenn voll geprüft. |
3Phase 3: Iterative Verfeinerung | 2-4 h | Jedes Sub-Ereignis weiter zerlegen, bis Basisereignisse erreicht sind (Komponentenausfall, Bedienfehler, externe Ursache). Annahmen und Datenquellen pro Ebene dokumentieren. | Stoppen, wenn weitere Verfeinerung keinen Wert mehr bringt oder keine Daten verfügbar sind. Bäume können theoretisch unendlich tief werden; praktischer Stop bei 4-6 Ebenen oder bei messbaren Basisereignissen. |
4Phase 4: Minimal Cut Sets | 45-90 min | Minimal Cut Sets identifizieren: kleinste Kombinationen von Basisereignissen, deren gleichzeitiges Auftreten das Top-Event auslöst. Manuelle Ableitung oder Tool-basiert. | Cut Sets der Größe 1 sind Single Points of Failure und meist kritisch. Cut Sets mit hoher kombinierter Wahrscheinlichkeit gleichermaßen. Priorisierung nach Wirkung mal Wahrscheinlichkeit. |
5Phase 5: Maßnahmen und Review | 45-90 min | Pro kritisches Cut Set Maßnahme(n) ableiten: Redundanz, Erkennung, Wiederherstellung, Vermeidung. Owner und Datum. FTA-Review durch unabhängige Person bei sicherheitskritischen Systemen. | Maßnahmen ohne unabhängigen Review sind anfällig für blinde Flecken. Bei regulierten Systemen ist Review Pflicht, nicht Optionalität. |
Was am Ende rauskommt
FTA-Diagramm mit Top-Event, vollständigen Verzweigungen, Symbolik (AND, OR, Basisereignisse), Annahmen-Tabelle, identifizierten Minimal Cut Sets und abgeleiteten Maßnahmen mit Owner und Datum. Bei regulierten Systemen Review-Vermerk.
Pro System und Top-Event eigene FTA. Versionsstand mit Datum, Autor und Reviewer. Bei Systemänderungen FTA-Update als neue Version mit Diff-Beschreibung, Vorgänger nicht löschen.
Kompakte Arbeitsvorlage für Fault Tree Analysis mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Fault Tree Analysis Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- Fault Tree:
- Critical Paths:
- Ursachenhypothesen:
- Kontrollmaßnahmen:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## FTA — Top-Event „Patient erhält falsche Insulindosis aus Smart-Pumpe“, V1.2, 30.04.2026
**Systemgrenze**: Smart-Pumpe inkl. Bedien-App, Pumpen-Mikrocontroller, Sensor, Wireless-Kanal. CGM-Sensor als Black Box.
### Erste Ebene (OR)
- Berechnungsfehler in App
- Übertragungsfehler zwischen App und Pumpe
- Mechanischer Fehler in Pumpe
- Sensordatenfehler
### Minimal Cut Sets (Auszug)
- **CS-1**: Falsche Formel in App AND Plausibilitätsprüfung deaktiviert. Wahrscheinlichkeit: 10⁻⁶/Jahr. Kategorie: kritisch.
- **CS-2**: Übertragungs-CRC-Fehler unerkannt. Wahrscheinlichkeit: 10⁻⁵/Jahr. Kategorie: kritisch.
- **CS-3**: Pumpenmotor läuft trotz Stop-Signal AND mechanischer Endschalter defekt. Wahrscheinlichkeit: 10⁻⁷/Jahr. Kategorie: tolerierbar mit Wartung.
### Maßnahmen
- CS-1: Plausibilitätsprüfung als Pflicht-Komponente, automatische Tests im CI. Owner @marlene, bis 30.06.
- CS-2: CRC-Verfahren auf Standard X erhöht, Pumpenseite prüft Sequenznummer. Owner @ben, bis 15.06.
- CS-3: Wartungsintervall reduziert auf 6 Monate, Endschalter im Selbsttest. Owner @sabine, bis 31.07.
### Review
Independent Reviewer Dr. Schulze, Freigabe 02.05.2026.Symptome erkennen, gegensteuern
Top-Event lautet „System fällt aus“ oder „Fehler tritt auf“, kein messbarer Zustand.
Top-Event mit Zustand, Schwellwert, Zeitfenster und betroffenem System präzisieren. Test: kann ein Beobachter eindeutig entscheiden, ob Top-Event eingetreten ist.
Gates sind nicht klar markiert, Logik des Baums ist mehrdeutig, Cut Sets können nicht abgeleitet werden.
Symbolik strikt nutzen, Gates eindeutig beschriften. Bei Unsicherheit fragen: muss A und B gleichzeitig vorliegen, oder reicht A oder B.
Verfeinerung geht bis zu Bauteilen, für die keine Ausfallraten verfügbar sind, Aufwand explodiert.
Stop-Kriterien definieren: Basisereignis ist erreicht, wenn Daten verfügbar oder direkte Maßnahme möglich. Tiefere Detaillierung nur bei nachweislichem Wertbeitrag.
Baum enthält Wahrscheinlichkeiten und Zusammenhänge, deren Quellen oder Annahmen nicht dokumentiert sind.
Annahmen-Tabelle parallel pflegen: pro Ebene mindestens eine nummerierte Annahme. Bei Review ist diese Tabelle Hauptquelle.
Maßnahmen sind allgemein („mehr Tests“, „bessere Doku“), kein Bezug zu identifizierten Cut Sets.
Pro priorisiertes Cut Set spezifische Maßnahme. Wenn keine spezifische Maßnahme ableitbar, Cut Set neu bewerten oder Tiefe nicht ausreichend.
FTA wird vom selben Team erstellt und genehmigt, blinde Flecken bleiben.
Bei regulierten Systemen Review durch unabhängige Person Pflicht. Bei nicht-regulierten Systemen mindestens eine Person außerhalb des Teams als Cross-Check.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.