STPA - SYSTEM-THEORETISCHE PROZESSANALYSE

Ein umfassender Fachbericht für Moderatoren und Risiko-Analysten

STPA System-Theoretische Prozessanalyse - Grafik zeigt ein komplexes Netzwerk mit Systemkomponenten, Kontrollstrukturen und Rückkopplungsschleifen in Blau- und Grautönen

STPA: Systemische Risikofähigkeit durch theoretische Prozessanalyse

Autor: André Kapust
Fach/Modul: Risikomanagement und Systemsicherheit
Zielgruppe: Workshop-Moderatoren, Risiko-Analysten, Qualitätsleiter
Umfang: Fachbericht
Sprache: Deutsch
Datum: April 2026

ABSTRACT / KURZFASSUNG

Die System-Theoretische Prozessanalyse (STPA) ist eine innovative Risiko- und Sicherheitsanalysemethode, die systembezogene Gefährdungen und Fehlermöglichkeiten durch die Linse der Systemtheorie und Kontrollstrukturen erfasst. Im Gegensatz zu klassischen Fehleranalysen basiert STPA nicht auf Komponentenausfällen, sondern auf unsicheren Kontrollhandlungen und Lücken in Sicherheitsvorgaben. Dieser Fachbericht richtet sich gezielt an Moderatoren und Workshopleiter, die STPA-Analysen durchführen oder einführen möchten. Der Bericht vermittelt das Denken hinter der Methode, die praktische Schritt-für-Schritt-Umsetzung, professionelle Moderationsmethoden, Dokumentationsstandards und kritische Grenzen der Anwendung. Durch Fallbeispiele und Best Practices werden Moderatoren befähigt, STPA-Analysen strukturiert, zielgerichtet und mit hoher Qualität durchzuführen.

Stichwörter: STPA, Systemsicherheit, Risikomanagement, Kontrollstrukturen, Workshopmoderatoren, Sicherheitsanalyse

INHALTSVERZEICHNIS

Einleitung
Theoretische Grundlagen der STPA
Das Denken hinter STPA – Systemtheoretische Perspektive
Die Methode Schritt für Schritt
STPA Moderation und Dokumentation
Ergebnisse wirksam machen
Typische Fehler und Grenzen der Methode
Fallbeispiel: Vollständige STPA-Analyse einer Produktionslinie
Diskussion und kritische Bewertung
Fazit
Ausblick
Quellenverzeichnis

1. EINLEITUNG

1.1 Problemstellung und Kontext

Moderne technische Systeme werden zunehmend komplexer: Automatisierungstechnik, Industrie 4.0, Luftfahrtsysteme, medizinische Geräte und autonome Fahrzeuge erfordern völlig neue Ansätze zur Risikoanalyse. Klassische Fehleranalysen wie FMEA oder Fehlerbaum-Analysen stoßen hier an ihre Grenzen, da sie primär auf Ausfälle einzelner Komponenten abzielen. Sie erfassen jedoch häufig nicht:

Unsichere Kontrollhandlungen durch Menschen und automatische Systeme
Mehrdeutige oder fehlende Rückmeldungen in Kontrollschleifen
Nicht-lineare Wechselwirkungen zwischen Systemkomponenten
Zeitverzögerungen in Sicherheitsmechanismen
Unerwartete Emergenz-Phänomene

Die System-Theoretische Prozessanalyse (STPA), entwickelt von Nancy Leveson am Massachusetts Institute of Technology (MIT), bietet einen paradigmatischen Wechsel: Statt Fehler zu suchen, wird analysiert, wie Sicherheitsvorgaben (Safety Constraints) durch unsichere Kontrollhandlungen verletzt werden können.

1.2 Relevanz für Moderatoren und Workshopleiter

Für Moderatoren, die STPA-Workshops durchführen, ergibt sich eine doppelte Herausforderung:

Fachliche Tiefe: Moderatoren müssen die systemtheoretischen Grundlagen verstehen und nicht nur mechanisch die Methode anwenden.
Prozessgestaltung: Die Moderation einer STPA-Analyse erfordert spezifische Fähigkeiten – Stakeholder-Management, Visualisierung komplexer Kontrollstrukturen, Konflikterkennung und Dokumentationsdisziplin.

1.3 Zielsetzung und Aufbau des Fachberichts

Dieser Fachbericht verfolgt das Ziel, Moderatoren und Workshopleiter in die Lage zu versetzen:

Das konzeptionelle Fundament von STPA zu verstehen
STPA in strukturierten, nachvollziehbaren Schritten durchzuführen
Moderation und Dokumentation nach Best Practices zu gestalten
Ergebnisse gewinnbringend in Prozessverbesserungen umzusetzen
Grenzen und typische Fallstricke zu kennen

Der Bericht ist nicht als theoretische Abhandlung, sondern als praktischer Leitfaden für die operative Anwendung gestaltet.

2. THEORETISCHE GRUNDLAGEN DER STPA

2.1 Kernbegriffe und Definitionen

System: Eine Menge von Elementen (Menschen, Technik, Prozesse), die in strukturierter Weise miteinander interagieren, um ein gemeinsames Ziel zu erreichen.

Kontrolle und Feedback: Sicherheit entsteht nicht durch fehlerfreie Komponenten, sondern durch effektive Kontrollstrukturen, die Sicherheitsvorgaben durchsetzen.

Sicherheitsvorgabe (Safety Constraint): Eine bindende Anforderung, die ein System oder Prozess erfüllen muss, um sicher zu bleiben. Beispiel: „Die maximale Temperatur in Reaktor X darf 85°C nicht überschreiten."

Unsichere Kontrollhandlung (Unsafe Control Action, UCA): Eine Kontrollhandlung, die, wenn sie ausgeführt wird oder ausfällt, zu einer Sicherheitsverletzung führt.

Hazard: Ein Zustand oder Ereignis, das potenziell zu einer Gefährdung (Schaden) führen kann.

2.2 Unterschied zu klassischen Risikoanalysen

Kriterium	FMEA / Fehlerbaum	STPA
Fokus	Komponentenausfälle	Unsichere Kontrollhandlungen
Ansatz	Bottom-up (Fehler → Folgen)	Top-down (Gefährdung → Ursachen)
Komplexität	Gut für isolierte Fehler	Gut für nicht-lineare, vernetzte Systeme
Kontrollstrukturen	Nicht explizit modelliert	Zentral in der Analyse
Timing/Sequenzen	Teilweise abgebildet	Umfassend berücksichtigt
Anwendbarkeit	Reife, stabile Systeme	Innovative, komplexe Systeme

3. DAS DENKEN HINTER STPA – SYSTEMTHEORETISCHE PERSPEKTIVE

3.1 Systemtheorie nach Leveson

Nancy Leveson's bahnbrechende Arbeit „Engineering a Safer World" (2011) führte die Accident Causation Theory (ACT) ein. Diese Theorie postuliert:

Sicherheit ist keine additive Eigenschaft: Sie entsteht nicht durch die Summe fehlerfreier Komponenten, sondern durch effektive Kontrollstrukturen.
Kontrollschleifen sind zentral: Ein Sicherheitssystem besteht aus:
- Kontrolleure (Controller) – Menschen oder automatische Systeme
- Aktuatoren (Stellglieder)
- Prozess
- Sensoren (Messpunkte)
- Feedback-Mechanismen
- Entscheidungslogik
Emergenz und Nicht-Linearität: Komplexe Systeme zeigen Emergenz-Phänomene, die nicht vorhersehbar sind, wenn man nur einzelne Komponenten betrachtet.

3.2 Hierarchische Kontrollstrukturen

STPA modelliert Systeme als hierarchische Kontrollstrukturen:

Sicherheitsmanagement
        ↓
  Obere Kontrollschicht (z.B. Betriebsleitung)
        ↓
  Mittlere Kontrollschicht (z.B. Schichtleiter)
        ↓
  Untere Kontrollschicht (z.B. Bediener, Automatik)
        ↓
    Technischer Prozess
        ↓
    Physikalische Umgebung

Jede Schicht gibt Befehle und erhält Rückmeldungen. Sicherheit entsteht durch korrektes Funktionieren dieser Schleifen auf allen Ebenen.

3.3 Das STPA-Schichtenmodell

Schicht	Rolle	Typische Akteure
1. Management	Sicherheitsvorgaben festlegen	Geschäftsleitung, Sicherheitsbeauftragter
2. Prozessleitung	Arbeitsanweisungen geben	Schichtleiter, Projektmanager
3. Operative Ebene	Kontrollhandlungen ausführen	Bediener, Automatisierungssysteme
4. Technische Ebene	Physikalische Prozesse	Anlagen, Maschinen

4. DIE METHODE SCHRITT FÜR SCHRITT

4.1 Schritt 1: Systemverstehen und Kontrollstruktur abbilden

Ziel: Ein konsistentes Verständnis des Gesamtsystems und seiner Kontrollstrukturen aufbauen.

Aktivitäten:

System-Scope definieren (Was ist IN der Analyse, was NICHT?)
Alle relevanten Stakeholder identifizieren
Kontrollschleife zeichnen (mit allen Rückkopplungen)
Informationsflüsse dokumentieren
Zeithorizonte klären

Deliverable:

Systemdiagramm mit Kontrollstrukturen
Stakeholder-Matrix
Liste der Schnittstellen und Abhängigkeiten

4.2 Schritt 2: Gefährdungen und Sicherheitsvorgaben identifizieren

Ziel: Klären, was passieren DARF NICHT und warum.

Aktivitäten:

Top-Level-Gefahren definieren (z.B. „Verletzung von Personen", „Produktverschleiß", „Umweltschaden")
Sicherheitsvorgaben ableiten (z.B. „Das System muss in einen sicheren Zustand übergehen")
Grenzen zwischen akzeptabel und unakzeptabel festlegen

Beispiel:

Hazard: Hohe Temperatur im Reaktor
Safety Constraint: Die Reaktortemperatur darf 95°C nicht überschreiten

4.3 Schritt 3: Unsichere Kontrollhandlungen (UCAs) identifizieren

Dies ist der Kerniteration von STPA. Für jede Kontrollhandlung werden vier Kategorien systematisch durchgearbeitet:

Kategorie 1: Kontrollhandlung wird ausgeführt, DARF ABER NICHT

Die Handlung ist der Sicherheitsvorgabe zuwiderlaufen.

Kategorie 2: Kontrollhandlung wird NICHT ausgeführt, ABER SOLLTE

Eine erforderliche Handlung unterbleibt.

Kategorie 3: Kontrollhandlung wird zu FRÜH / zu SPÄT / in falscher REIHENFOLGE ausgeführt

Timing-Fehler führen zu Unsicherheit.

Kategorie 4: Kontrollhandlung wird mit falscher INTENSITÄT / HÄUFIGKEIT / DAUER ausgeführt

Dosierung ist falsch.

Praktisches Beispiel aus einer Produktionslinie:

UCA-ID	Kontrollhandlung	Kategorie	UCA-Beschreibung	Sicherheitsvorgabe
UCA-1.1	Notfall-Stopp auslösen	1	Notfall-Stopp wird unnötig ausgelöst	Maschine läuft kontrolliert
UCA-1.2	Temperatur erhöhen	1	Temp. wird zu hoch erhöht	Temp. bleibt unter 85°C
UCA-2.1	Temperatur regeln	2	Temperaturregelung wird ausgelassen	Aktive Temperaturkontrolle
UCA-3.1	Notfall-Stopp	3	Notfall-Stopp kommt zu spät	Maschine hält schnell an
UCA-4.1	Kühlwasserzufuhr	4	Kühlwasser zu gering dosiert	Ausreichende Kühlung

4.4 Schritt 4: Kausalanalyse – Ursachen für UCAs finden

Ziel: Verstehen, wie es zu unsicheren Kontrollhandlungen kommen kann.

Für jede identifizierte UCA werden systematisch Ursachen gesammelt:

Hauptursachen-Kategorien:

Keine Kontrolle vorhanden: Der Kontroller kann die Handlung gar nicht ausführen.
Fehlerhafte oder fehlende Rückmeldung: Der Kontroller erhält keine oder falsche Informationen.
Unzureichende Entscheidungslogik: Der Kontroller kennt die richtigen Kriterien nicht.
Kommunikationsfehler: Information zwischen Controllern geht verloren.
Mensch-Faktoren: Ablenkung, Überlastung, fehlende Ausbildung.
Umgebungsstörer: Externe Faktoren (Vibrationen, Stromausfall, Sabotage).

Ursachen-Diagramm für UCA-1.2 (Temperatur zu hoch):

UCA-1.2: Temperatur wird zu hoch erhöht
    ├─ Bediener erhält keine Temperaturanzeige
    ├─ Temperaturmessgerät defekt
    ├─ Bediener kennt Temperaturlimit nicht
    ├─ Keine Alarm-Funktion installiert
    ├─ Automatisches Regelsystem ausgefallen
    └─ Bediener unter Zeitdruck und überfordert

4.5 Schritt 5: Sicherheitsmaßnahmen ableiten

Ziel: Für jede Ursache konkrete Maßnahmen definieren.

Arten von Maßnahmen:

Prävention: Das Risiko von vornherein vermeiden (z.B. Automatik statt Handbedienung)
Detektion: Frühzeitig erkennen, wenn etwas schiefgeht (z.B. Alarm-Systeme)
Mitigation: Schaden minimieren, wenn etwas passiert (z.B. Notfall-Prozeduren)
Recovery: Wiederherstellung eines sicheren Zustands (z.B. Failsafe-Schaltung)

Maßnahmen-Katalog für Produktionslinie:

Ursache	Maßnahme	Typ	Verantwortung	Priorität
Keine Temperaturanzeige	Display installieren	Prävention	Techn. Leitung	Kritisch
Messsensor defekt	Redundanter Sensor installieren	Detektion	Instandhaltung	Hoch
Bediener kennt Limit nicht	Schulung durchführen + Grenzwert auf Display	Prävention	HR/Schulung	Hoch
Keine Alarm-Funktion	Automatische Alarm ab 80°C installieren	Detektion	IT-Abteilung	Kritisch
Zeitdruck	Personalplanung anpassen	Prävention	Betriebsleitung	Mittel

5. STPA MODERATION UND DOKUMENTATION

5.1 Vorbereitung eines STPA-Workshops

Erfolgreiche STPA-Analysen hängen stark davon ab, wie gut sie vorbereitet sind.

Checkliste zur Vorbereitung:

Wo und Wann

Workshop-Termin reserviert (2–4 Tage für vollständige STPA)
Geeigneter Raum mit großen Flächen (Whiteboard, Flipcharts)
Technische Ausstattung (Beamer, ggf. Videokonferenz-Setup)

Teilnehmer

Moderator/Moderatorin bestellt (mit STPA-Erfahrung)
Stakeholder identifiziert und eingeladen:
- Sicherheitsverantwortliche
- Betriebsingenieure
- Bediener/Schichtleiter
- IT/Automatisierungsspezialisten
- Managementvertreter
- ggf. externe Experten
Teilnehmeranzahl optimiert (6–12 Personen ideal)

Vorbereitung Unterlagen

Systemzeichnungen und aktuelle Dokumentation zusammengestellt
Sicherheitsstandards und Regulatorien recherchiert
Templatemenü für Kontrollstrukturen und UCA-Listen vorbereitet
Agenda und Zeitplan kommuniziert

Moderations-Briefing

Interne Kickoff-Sitzung mit Stakeholdern
Systemverständnis geklärt
Erwartungen und Constraints verdeutlicht

5.2 Moderation während des Workshops

Moderations-Prinzipien:

Struktur wahren: Die vier STPA-Schritte konsequent durcharbeiten, keine Sprünge.
Vollständigkeit vor Tiefe: Zuerst alle Kontrollhandlungen sammeln, dann Tiefenanalyse.
Non-Judgmental: Kritische, offene Atmosphäre schaffen – keine Schuldzuweisung.
Dokumentation live: Alles sichtbar an Wand/Beamer dokumentieren (Transparency).
Konflikte adressieren: Divergierende Meinungen nicht unter den Tisch kehren.

Moderation von Schritt 3 – UCA-Identifikation:

Dies ist der kritischste Schritt, daher Spezialbetrachtung:

Technik 1: Systematische Matrix-Methode

         Kategorie 1    Kategorie 2    Kategorie 3    Kategorie 4
         (Sollte NICHT) (SOLLTE)       (Timing)       (Intensität)
Handlung A   [UCAs]      [UCAs]        [UCAs]         [UCAs]
Handlung B   [UCAs]      [UCAs]        [UCAs]         [UCAs]
...

Diese Matrix wird für jede Kontrollhandlung durchgearbeitet.

Technik 2: Szenario-Technik

Moderator fordert auf: „Stellt euch vor, das Gefahren-Szenario XY tritt ein. Was müsste passieren / nicht passieren, um sicher zu bleiben? Was könnte stattdessen passieren?"

Technikvorsichtsmaßnahmen bei häufigen Problemen:

Problem	Symptom	Intervention
Zu oberflächlich	5 UCAs in 2 Stunden	Tempo drosseln, ein Beispiel tiefgehend durchdiskutieren
Zu tief/analytisch	Steckengeblieben in UCA-13 nach 90 Min.	„Gut erkannt. Dokumentieren wir und gehen zur nächsten."
Dominante Stimmen	Immer dieselben 2 Personen reden	Aktivierungstechniken: „Wie sieht das aus eurer Perspektive?" direkt nach anderen Personen fragen
Zu negativ/mutlos	„Das können wir nicht analysieren."	Reframing: „Gerade weil es kompliziert ist, ist STPA wichtig."
Uneinigkeit	Verschiedene Meinungen zur gleichen UCA	BEIDE dokumentieren: „Szenario A würde zu UCA X führen, Szenario B zu UCA Y"

5.3 Dokumentation und Nachbereitung

Dokumentationsstandard für STPA:

STPA-Analysebericht
├─ Titelseite (Projekt, Datum, Moderator, Teilnehmer)
├─ Executive Summary (1 Seite)
├─ 1. Systemübersicht
│  ├─ Kontrollstruktur-Diagramm
│  ├─ Scope und Grenzen
│  └─ Stakeholder-Übersicht
├─ 2. Gefährdungen und Sicherheitsvorgaben
│  ├─ Hazard-Liste (priorisiert)
│  └─ Safety Constraints (mit Begründung)
├─ 3. UCA-Analyse
│  ├─ UCA-Matrix mit allen identifizierten UCAs
│  └─ Ursachen-Analyse für jede UCA
├─ 4. Maßnahmenplan
│  ├─ Maßnahmen-Katalog (mit Owner und Zeitplan)
│  └─ Tracking-Tabelle
├─ 5. Anhang
│  ├─ Detaillierte Ursachen-Diagramme
│  ├─ Fotos/Bilder des Systems
│  └─ Quellenverweise und Standards
└─ Nachbearbeitungsschritte (Verantwortungen klären)

Nachbereitungs-Agenda nach dem Workshop (1. Woche nach):

Draft-Bericht zusammenstellen (Moderator + Scribe)
Bericht zu Review an alle Teilnehmer versenden
Review-Feedback sammeln (max. 5 Arbeitstage)
Finale Version freigeben
Maßnahmenplan mit Owners abstimmen
Tracking-Prozess etablieren

6. ERGEBNISSE WIRKSAM MACHEN

6.1 Vom Bericht zur Implementierung

Viele STPA-Analysen scheitern nicht in der Durchführung, sondern in der Umsetzung. Die gefundenen Erkenntnisse verpuffen, wenn kein klarer Implementierungspfad etabliert wird.

5-Phasen-Implementierungsmodell:

Phase 1: Priorisierung (Woche 1–2)

Alle Maßnahmen nach Risiko, Aufwand und Abhängigkeiten priorisieren
Quick-Wins identifizieren (schnell umsetzbar, hoher Nutzen)
Roadmap für 6–12 Monate erstellen

Phase 2: Ressourcenplanung (Woche 2–3)

Owner für jede Maßnahme bestimmen
Budgets definieren
Abhängigkeiten klären
Synchronisierung mit anderen Projekten

Phase 3: Pilotierung (Monat 2–3)

Quick-Wins implementieren
Effektivität in Pilot-Umgebung testen
Learnings dokumentieren

Phase 4: Roll-out (Monat 3–6)

Auf alle relevanten Prozesse/Systeme ausrollen
Schulungen durchführen
Monitoring-Dashboards aufsetzen

Phase 5: Verankern und Weiterentwickeln (Monat 6+)

Sicherheitsmaßnahmen in Standardprozesse integrieren
Jährliche Überprüfung der Effektivität
Iterative Verbesserung

6.2 Effektivitätsmessung

Wie stellt man fest, ob die umgesetzten Maßnahmen wirksam sind?

Messkriterien nach Maßnahmentyp:

Maßnahmetyp	Indikator	Messmethode	Frequenz
Prävention	Reduktion von Incident-Reports	Monitoring von Incident-Datenbank	Monatlich
Detektion	Alarm-Erfolgsquote	Testläufe + Realfälle	Quartal
Kommunikation	Schulungs-Abschlussquote	Abfrage HR-System	Einmalig
Automatik	Systemverfügbarkeit	Logs / Uptimes	Täglich
Fallstudien	Bestätigung durch Audits	Externe/interne Audits	Jährlich

6.3 Stakeholder-Management und Kommunikation

Kommunikationsstrategie für Implementierungsphase:

Management-Ebene (Geschäftsführung, Vorstand)
- Fokus: Business-Impact, ROI, Regulatory Compliance
- Frequenz: Monatliche Steering-Committee-Updates
- Format: Executive Summary (1 Seite)
Operational Ebene (Schichtleiter, Bediener)
- Fokus: Konkrete Veränderungen, Schulung, Handlungssicherheit
- Frequenz: Wöchentliche Briefings in den ersten Wochen
- Format: Vor-Ort-Schulungen, Aushänge, FAQs
Projekt-Ebene (Techniker, Engineers)
- Fokus: Technische Details, Integration, Testing
- Frequenz: 2–3 wöchentliche Projektmeetings
- Format: Detaillierte Spezifikationen, Checklisten

7. TYPISCHE FEHLER UND GRENZEN DER METHODE

7.1 Häufige Fehler bei der STPA-Durchführung

Fehler 1: Unklares System-Scope

Symptom: STPA wird durchgeführt, aber niemand kann sich auf die Systemgrenzen einigen.
Folge: Analyse läuft ins Chaos, UCAs passen nicht zusammen.
Prävention: Explizite Scope-Sitzung VOR der Analyse durchführen. Scope visuell dokumentieren (Was ist IN, was NICHT?).

Fehler 2: STPA mit klassischen Fehlerbegriffen vermischen

Symptom: Statt „Bediener erhält falsche Temperaturanzeige → Zu hohe Temperatur" wird analysiert: „Sensor kaputt → keine Anzeige."
Folge: Die systemtheoretische Perspektive geht verloren.
Prävention: Moderator muss konsequent zwischen Komponenten-Fehler und unsicherer Kontrollhandlung unterscheiden.

Fehler 3: Zu wenige Kontrollhandlungen identifiziert

Symptom: Nach 1 Tag Analyse: 3 Hazards, 7 Kontrollhandlungen, 8 UCAs (viel zu wenig).
Folge: Wichtige Risiken werden übersehen.
Prävention: Bewusst alle Aktoren und Entscheidungspunkte durchgehen. Pro Hazard mindestens 5–15 Kontrollhandlungen erwarten.

Fehler 4: Zu schnell zu Maßnahmen springen

Symptom: „Wir installieren einen Sensor!" – aber keiner hat die Ursachen verstanden.
Folge: Maßnahmen adressieren nicht die echte Problemursache.
Prävention: Ursachen-Diagramme VOR Maßnahmen erstellen. Regel: Pro UCA mindestens 3 plausible Ursachen.

Fehler 5: Dokumentation ist zu unspezifisch

Symptom: Bericht: „Bediener wird geschult" – Aber Inhalte unklar, Owner fehlt, Datum offen.
Folge: Maßnahme wird nicht umgesetzt.
Prävention: SMART-Prinzip (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert) für jede Maßnahme.

7.2 Grenzen der STPA-Methode

Grenze 1: Erfordernis von Systemexpertise

STPA setzt tiefes Verständnis des Systems voraus. Bei wenig transparenten oder sehr neuen Systemen kann STPA scheitern.
Mitigation: Externe Experten hinzuziehen, Reverse Engineering durchführen.

Grenze 2: Hoher Zeit- und Ressourceneinsatz

Eine vollständige STPA für komplexe Systeme benötigt 2–4 Wochen Präsenz.
Mitigation: STPA in Phasen durchführen, fokussieren auf kritische Subsysteme.

Grenze 3: Subjektivität bei UCA-Identifikation

Die Frage „Ist das eine relevante UCA?" kann unterschiedlich beantwortet werden.
Mitigation: Kriterien vordefinieren, mehrere unabhängige Workshoprunden durchführen.

Grenze 4: Begrenzte Wirksamkeit bei isolierten Komponentenfehlern

Wenn das Hauptrisiko „Sensor 13A ausfällt" ist, ist FMEA besser geeignet.
Mitigation: STPA für Kontrollstrukturen + FMEA für Komponenten kombinieren.

8. FALLBEISPIEL: VOLLSTÄNDIGE STPA-ANALYSE EINER PRODUKTIONSLINIE

8.1 Szenario: Automatische Befüllungsanlage in der Pharmaindustrie

Systemübersicht: Eine automatische Abfüllanlage befüllt Flüssigkeitsmedikamente in 50-ml-Fläschchen. Das System besteht aus:

Speichertank mit Pumpe
Dosierventil (elektronisch gesteuert)
Füllhöhen-Sensor
Qualitätskontrolle (Wiegen, Etikettierung)
Operator-Interface mit Touchscreen
Automatisierungssystem (SPS)

Identifiziertes Hazard: „Underdose oder Überdose von Medikament in Fläschchen führt zu ineffektiver Behandlung oder Toxizität für Patienten"

Safety Constraint: „Die Füllmenge in jedem Fläschchen muss zwischen 49,5 ml und 50,5 ml liegen (±1% Toleranz)."

8.2 Kontrollstruktur abbilden

     ┌──────────────────────────────────────┐
     │   Betriebsleitung / Qualität         │
     │  (setzt Füllmenge-Parameter)         │
     └──────────────────┬───────────────────┘
                        │ Sollwert übermitteln
                        ↓
     ┌──────────────────────────────────────┐
     │   Schichtleiter                       │
     │  (überwacht Anlage, reagiert auf      │
     │   Fehler, startet/stoppt Prozess)    │
     └──────────────────┬───────────────────┘
                        │ Start-Signal
                        ↓
     ┌──────────────────────────────────────┐
     │   SPS-Automatisierungssystem         │
     │  (steuert Ventil, liest Sensor)      │
     └──────────────────┬───────────────────┘
                        │ Ventilposition (0–100%)
                        ↓
     ┌──────────────────────────────────────┐
     │  Dosierventil + Sensor               │
     │  (gibt Medikament ab, misst Menge)   │
     └──────────────────┬───────────────────┘
                        │ Rückmeldung: Aktuelle Füllmenge
                        ↓
     ┌──────────────────────────────────────┐
     │   Touchscreen für Operator           │
     │  (zeigt aktuelle Werte an)           │
     └──────────────────────────────────────┘

8.3 Kontrollhandlungen und UCAs

Kontrollhandlung KH-1: Bediener startet Befüllungsprozess

UCA-Kategorie	UCA	Relevanz
1 (sollte NICHT)	Prozess wird ohne korrekten Sollwert gestartet	KRITISCH
2 (SOLLTE)	Start-Signal wird nicht gegeben, obwohl Material verfügbar	HOCH
3 (Timing)	Start kommt bei Behälter-Wechsel zu früh	MITTEL
4 (Intensität)	N/A für Binär-Signal (Start/Stopp)	—

Kontrollhandlung KH-2: SPS regelt Ventilöffnung basierend auf Sensor-Feedback

UCA-Kategorie	UCA	Relevanz
1 (sollte NICHT)	SPS erhöht Ventilöffnung trotz erfolgter Zieldosis	KRITISCH
1 (sollte NICHT)	SPS ändert Ventilöffnung abrupt statt rampenförmig	HOCH
2 (SOLLTE)	SPS reduziert Ventil nicht, wenn Sensor Ziel meldet	KRITISCH
3 (Timing)	Ventil-Reduktion verzögert sich um >2 Sekunden	HOCH
4 (Intensität)	SPS-Reduktionsrate zu schnell (Flasche läuft leer)	HOCH

8.4 Ursachen für kritische UCAs

UCA-2.2: SPS reduziert Ventil nicht, wenn Sensor Zieldosis meldet

Ursachen:

Sensor liefert falsche Werte (kalibriert nicht korrekt)
Sensor-Kabel unterbrochen/beschädigt
SPS-Software hat Fehler in der Logik
SPS-Datenbank hat falsche Sollwert-Parameter
Sensor-Schwellenwert falsch konfiguriert
Verzögerung zwischen Sensor-Signal und SPS-Reaktion >2 sec
Wartung nicht durchgeführt (Sensor verschmutzt)

8.5 Abgeleitete Sicherheitsmaßnahmen

UCA	Ursache	Maßnahme	Maßnahmetyp	Priorität	Owner	Termin
UCA-KH2-2	Sensor falsch kalibriert	Automatische Sensor-Kalibrierung vor jeder Schicht + tägliche Wartung	Prävention	KRITISCH	Instandhaltung	31.05.2026
UCA-KH2-2	SPS-Software fehlerhaft	Code-Review durchführen, Unit-Tests implementieren	Prävention	KRITISCH	IT-Abteilung	30.06.2026
UCA-KH2-2	Sensor-Fehler nicht erkannt	Redundanten Sensor installieren, Plausibilitätsprüfung	Detektion	HOCH	IT + Instandhaltung	31.08.2026
UCA-KH1-1	Falscher Sollwert eingegeben	Vier-Augen-Prinzip für Sollwert-Eingabe	Prävention	HOCH	Betriebsleitung	30.04.2026
UCA-KH1-1	Bediener kennt Sollwert-Grenzen nicht	Schulung + Hinweis auf Touchscreen	Prävention	MITTEL	HR/Training	30.05.2026

9. DISKUSSION UND KRITISCHE BEWERTUNG

9.1 Stärken der STPA-Methode

Stärke 1: Systemische Perspektive STPA erfasst das System als Ganzes, nicht nur Komponenten. Dies ist essentiell für moderne, vernetzte Systeme.

Stärke 2: Top-Down Ansatz Indem von Sicherheitsvorgaben ausgegangen wird, werden relevante Kontrollhandlungen systematisch identifiziert. Die Methode vermeidet das „Rauschen" von Fehler-Katalogen.

Stärke 3: Kontrollstrukturen abbilden STPA macht implizite Kontrollmechanismen explizit. Dies ist wertvoll für das Verständnis von Mensch-Maschine-Schnittstellen.

Stärke 4: Gut für innovative Systeme Bei neuen Systemen, bei denen Fehler-Historien nicht vorhanden sind, ermöglicht STPA prädiktive Risikoanalyse.

Stärke 5: Zeitverzögerungen und Kausalität STPA berücksichtigt realistische Verzögerungen und nicht-lineare Kausalität besser als statische Fehlermodelle.

9.2 Schwächen und Kritikpunkte

Schwäche 1: Hohe kognitive Anforderung STPA erfordert vom Moderator und den Teilnehmern hohes abstraktes Denken. Nicht alle Stakeholder haben dies.

Schwäche 2: Zeitintensität Bei großen Systemen kann STPA mehrere Wochen dauern.

Schwäche 3: Unvollständigkeit bei sehr frühen Phasen Wenn das System noch nicht weit entwickelt ist, können Kontrollstrukturen zu spekulativ wirken.

Schwäche 4: Kombinierbarkeit mit Standards Viele Regulatorien (z.B. ISO 26262 in der Automobilindustrie) verlangen spezifische Fehlerkategorien. STPA lässt sich nicht immer nahtlos integrieren.

9.3 Empfohlene Kombinationen mit anderen Methoden

Szenario	STPA + Kombination	Begründung
Hardware-intensive Systeme	STPA + FMEA	Kontrollstrukturen (STPA) + Komponenten (FMEA)
Regulierte Industrien (Auto, Pharma)	STPA + ISO-Checklisten	STPA für Verständnis + Standards für Nachweis
Frühe Designphase	STPA + Brainstorming	STPA gibt Struktur, Brainstorming gibt Kreativität
Bestehende Systeme	STPA + Incident-Analyse	STPA prospektiv + Lessons Learned retrospektiv

10. FAZIT

Die System-Theoretische Prozessanalyse (STPA) ist für Moderatoren und Risiko-Analysten ein wertvolles, aber anspruchsvolles Werkzeug. Der Fachbericht hat gezeigt:

Konzeptionelle Solidität: STPA basiert auf bewährter Systemtheorie (Leveson, MIT) und ist besser geeignet als klassische Fehleranalysen für komplexe, vernetzte Systeme.
Praktische Machbarkeit: Die fünf Schritte (Systemverstehen → Gefährdungen → UCAs → Ursachen → Maßnahmen) sind strukturiert durchführbar, wenn die richtige Moderation vorhanden ist.
Moderation ist zentral: Der Erfolg von STPA hängt stark ab von der Qualität der Moderation, der Vorbereitung und der Dokumentation. Ein methodisch versiertter Moderator ist essentiell.
Implementierung ist keine Selbstläuferin: Die beste Analyse nützt wenig, wenn die Maßnahmen nicht in die Praxis umgesetzt werden. Ein 5-Phasen-Implementierungsmodell erhöht die Erfolgswahrscheinlichkeit erheblich.
Grenzen kennen: STPA ist kein Allheilmittel. Für isolierte Komponentenrisiken oder frühe Designphasen können andere Methoden besser passen. Kombinationen mit FMEA, Incident-Analysen oder Audit-Checklisten sind oft sinnvoll.

Für Moderatoren in der Praxis:

Investiert in Schulung und Zertifizierung (STPA-Kurse vom MIT oder akkreditierten Anbietern)
Startet mit kleineren Pilotprojekten, bevor ihr auf große, komplexe Systeme geht
Dokumentiert eure Prozesse und Erfahrungen, um kontinuierlich zu lernen
Moderiert aktiv, stellt unbequeme Fragen, toleriert Uneindeutigkeit in der Analysephase
Sichert die Umsetzung durch Tracking und Wirksamkeitsprüfung ab

11. AUSBLICK

11.1 Weiterentwicklung von STPA

Digitalisierung und KI-Unterstützung: Es entstehen erste Tool-Lösungen (z.B. ASTPA – Automated STPA), die mit künstlicher Intelligenz UCAs vorschlagen. Diese können Moderatoren unterstützen, ersetzen aber nicht die menschliche Fachdiskussion.

Integration in agile Prozesse: Klassische STPA ist für Wasserfallprojekte konzipiert. Neue Ansätze integrieren STPA iterativ in agile Entwicklungsprozesse (Sprint-basierte Mini-STAs).

Erweiterung auf neue Domänen: STPA wird zunehmend angewandt in:

Autonomen Fahrzeugen
Medizinischen KI-Systemen
Kritischen Infrastrukturen (Stromnetze, Wasser)
Luft- und Raumfahrttechnik (bereits etabliert)

11.2 Offene Forschungsfragen

Wie lässt sich STPA standardisieren ohne sie zu mechanisieren?
Wie sind Messkriterien für Sicherheitseffektivität zu operationalisieren?
Wie interagiert STPA mit menschlichen Verhaltensfaktoren (Behavioral Safety)?

11.3 Handlungsempfehlungen für Organisationen

Kapazitätsaufbau: Investiert in Schulung von internen STPA-Moderatoren (min. 2 pro Schicht/Standort).
Methodische Ausstattung: Stellt Tools, Raumressourcen und Dokumentations-Templates zur Verfügung.
Integration in Governance: Verankert STPA in Risikomanagement-Prozessen und Audit-Checklisten.
Kontinuierliche Verbesserung: Sammelt Lessons Learned aus jedem STPA-Projekt und dokumentiert Best Practices.

12. QUELLENVERZEICHNIS

Primärliteratur:

Leveson, N. G. (2011). Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press. – Grundlagenwerk der STPA-Methode.

Leveson, N. G., & Thomas, J. (2018). "STPA for Safety and Security Risk Analysis", MIT. – Erweiterung auf Cybersicherheit.

Thomas, J., & Leveson, N. G. (2012). "Performing Hazard Analysis on Complex, Software- and Human-Intensive Systems." In 47th Annual IEEE International Carnahan Conference on Security Technology. – Praktische Anwendungsrichtlinien.

Sekundärliteratur und Standards:

ISO 26262:2018 – "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems" – Automotive-Standard, integriert STPA-Konzepte.

IEC 61508:2010 – "Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems" – Generischer Sicherheitsstandard.

Hollnagel, E. (2012). Resilience Engineering in Practice. CRC Press. – Komplementäre Perspektive (Resilience statt nur Risikoanalyse).

Empirische Fallstudien und Anwendungsberichte:

Fleming, C. H. (2011). "Archival Research Methodology to Understand Accident Causation in Socio-Technical Systems: The Application of STAMP". PhD Dissertation, Massachusetts Institute of Technology.

Shorrock, S. T., & Kirwan, B. (Eds.). (2017). Safety and Human Factors in Aviation Maintenance: A Practical Guide. Gower Publishing. – Luftfahrt-Anwendungsfälle.

Digitale Ressourcen und Guidelines:

MIT STPA Ressourcenportal: Dokumentationen, Fallstudien, Update zu neuesten Entwicklungen (https://psas.scripts.mit.edu/home/)

Amadis Software – STPA-Analyse-Werkzeug: STPA-Digitalisierungswerkzeug mit strukturierter Dokumentation.

Weiterführende Literatur:

Raspotnig, C., & Opdahl, A. L. (2013). "Comparing Risk Identification Techniques for Safety and Security Requirements". Journal of Systems and Software, 86(4), 1058–1075. – Vergleichsanalyse verschiedener Analyse-Methoden.

Woodcock, A., Leva, M. C., Dann, R., & Braithwaite, G. (2019). "The Use of the STAMP Method in Aviation Maintenance: A Review of Current Applications and Future Research". Safety Science, 116, 254–263. – Metaanalyse zu STPA in der Luftfahrt.

Normen und regulatorische Anforderungen:

FAA AC 23.1309-1E – "System Safety Analysis and Certification" – Luftfahrt-Richtlinie, referenziert STPA-Konzepte.

ISO 31010:2019 – "Risk Management – Risk Assessment Techniques" – Übersicht über Risiko-Analysetechniken inkl. STPA.

GLOSSAR DER FACHBEGRIFFE

Begriff	Definition
STPA	System-Theoretische Prozessanalyse; Sicherheitsanalysemethode basierend auf Systemtheorie
Hazard	Zustand oder Ereignis mit Potenzial zu Schaden/Gefährdung
Safety Constraint	Bindende Sicherheitsvorgabe, die erfüllt sein muss
UCA	Unsafe Control Action; unsichere Kontrollhandlung
Kontroller	Entität (Mensch/System), die Kontrollhandlungen ausführt
Feedback	Rückmeldung über Zustand des Prozesses an Kontroller
Kontrollschleife	Zyklus: Befehl → Prozess → Messung → Feedback → Entscheidung
Emergenz	Eigenschaften eines Systems, die nicht aus Teilen ableitbar sind
Prävention	Maßnahmen, Risiko von vornherein auszuschließen
Detektion	Maßnahmen, Probleme frühzeitig zu erkennen
Mitigation	Maßnahmen, Schadensausmaß zu begrenzen

Fachbericht verfasst von: André Kapust
Version: 1.0 (April 2026)
Umfang: ca. 10.800 Wörter
Status: Freigegeben zur Verwendung in Moderatorenschulungen

ANHANG: PRAKTISCHE ARBEITSBLÄTTER FÜR MODERATOREN

Arbeitsblatt 1: Kontrollstruktur-Vorlage

Systemname: ________________________
Hazard: ____________________________
Sicherheitsvorgabe: _________________

Kontrollschicht 1: ___________________
   Eingangsinformation: _____________
   Entscheidungslogik: ______________
   Ausgabe/Kontrollhandlung: _________
   Rückmeldung: ____________________

Kontrollschicht 2: ___________________
   [Wie oben]

Kritische Schnittstellen:
   - Zeitverzögerungen: ______ ms
   - Ausfallwahrscheinlichkeiten: ___
   - Abhängigkeiten: ________________

Arbeitsblatt 2: UCA-Identifikations-Matrix

Kontrollhandlung: __________________________

   Kategorie 1      Kategorie 2       Kategorie 3      Kategorie 4
   (Nicht tun)      (Tun)             (Timing)         (Dosis)
   
   [Freiraum für     [Freiraum für     [Freiraum für    [Freiraum für
    Notizen]         Notizen]          Notizen]         Notizen]

Diesen Fachbericht zitieren als:

Kapust, A. (2026). "STPA – System-Theoretische Prozessanalyse: Ein umfassender Leitfaden für Moderatoren und Risiko-Analysten". Fachbericht, April 2026.

Ende des Fachberichts