Die meisten Risikoanalysen – egal ob FMEA, STPA oder eine interne Checkliste – beruhen an ihrem kritischsten Punkt auf einer einzigen Methode: einem Raum voller kluger Menschen, die sich fragen „Was könnte alles schiefgehen?" Das Ergebnis ist so vollständig, wie das Team kreativ war. Und Kreativität ist keine Vollständigkeits-Garantie – sie ist eine Hoffnung.
Es gibt einen Weg, aus dieser Hoffnung eine nachrechenbare Aussage zu machen. Er verlangt nicht mehr Workshops. Er verlangt drei Grenzen, die man ohnehin fast immer schon irgendwo aufgeschrieben hat – nur nie zusammen betrachtet.
Der Einwand, den ich ernst nehme#
Der naheliegende Einwand: STPA (Systems-Theoretic Process Analysis, die heute führende Methode zur Risikoanalyse steuerungsbasierter Systeme) ist längst Standard, gut erprobt, wird von erfahrenen Sicherheitsingenieuren angewendet. Braucht es wirklich noch ein neues Modell obendrauf?
Nein – und das ist der Punkt. Das hier vorgestellte Modell ersetzt STPA nicht. Es macht sichtbar, was STPA an einer Stelle bereits stillschweigend voraussetzt, aber nie explizit einfordert: eine vollständige Deklaration dessen, was erlaubt und was gewollt ist. Ohne diese Deklaration bleibt jede STPA-Analyse so vollständig, wie das Team im Workshop war – mit ihr wird sie nachrechenbar.
Das Bild: ein Schlauch durch die Zeit#
Stellt euch eine Fahrspur auf der Autobahn vor. Ein Auto fährt nicht auf einer Linie – es pendelt leicht, korrigiert, hält die Spur. Diese Spur hat zwei Eigenschaften: eine Mittellinie (wohin soll es fahren) und eine Breite (wie viel Abweichung ist erlaubt, ohne dass es gefährlich wird). Zusammen ergibt das über die Zeit einen Schlauch, durch den sich das Auto bewegt.
Übertragen auf jedes System – ein Bauteil, eine Software, eine Abteilung, einen Menschen in einer Rolle – lassen sich drei Größen fast immer schon getrennt voneinander finden, nur nie unter einem gemeinsamen Namen:
- AIA (Allowed Interference Actions, „erlaubte Störungen"): Wie viel Abweichung, wie viel Störung hält das System aus, ohne dass es gefährlich wird? Das ist die Breite des Schlauchs.
- DIA (Desired Interference Actions, „gewollte Zielwechsel"): Welche beauftragten Änderungen soll das System ausführen, wie schnell, wie lange? Das ist die Mittellinie des Schlauchs – und ihre Formänderungen.
- PIA (Physically possible Interference Actions, „physikalisch Mögliches"): Was kann auf diesem System überhaupt ankommen, bevor die Physik selbst sich ändert – Bruch, Durchschlag, ein komplett neues Regime? Das ist die äußere Wand, in der der ganze Schlauch überhaupt liegt.
Diese drei Größen stehen in fast jedem technischen Datenblatt bereits – nur unter anderen Namen. Die Operating Conditions sind die AIA. Die Kennlinien sind die DIA. Die Absolute Maximum Ratings sind die PIA. Man hat sie nur nie als dieselbe Deklaration gelesen.
Der eigentliche Trick: das vierte Wort, das niemand extra pflegen muss#
Und jetzt kommt der Teil, der den Unterschied zur klassischen Risikoanalyse macht.
UCA (Unsafe/Unwanted Control Actions – Levesons Begriff für „gefährliche Steuerungshandlungen") ist in diesem Modell kein viertes Element, das zusätzlich erhoben werden muss. UCA ist alles, was innerhalb der physikalischen Wand (PIA) liegt, aber weder erlaubt (AIA) noch gewollt (DIA) ist. Eine reine Restmenge.
Das bedeutet konkret: Sobald ein Team die Breite des Schlauchs (AIA) und seine gewollten Bewegungen (DIA) sauber deklariert hat, muss es die Liste der gefährlichen Fälle nicht mehr im Workshop erfinden. Sie ergibt sich als Komplement – rechnerisch, nicht kreativ. Levesons vier klassische Fehlermuster (eine nötige Handlung unterbleibt; eine Handlung führt in die Gefahr; falsches Timing; falsche Dauer) liegen alle vollständig in diesem Außenraum und lassen sich systematisch dorthin abbilden.
| Klassisches Vorgehen | Mit deklariertem Schlauch | |
|---|---|---|
| Was wird gepflegt | Endlose, kreative UCA-Listen | Nur Mittellinie + Breite + Wand |
| Vollständigkeit | „dem Team fällt nichts mehr ein" | Restmengen-Bildung, nachrechenbar |
| Prüfbarkeit | Experten-Urteil | Deterministisch |
Drei Prüfungen – und die dritte ist die eigentliche Pointe#
Mit diesen drei Größen lässt sich immer dieselbe eine Frage stellen – Ist der Verlauf innerhalb des erlaubten Raums? – nur auf drei verschiedene Paare angewendet.
Prüfung 1 – Betrieb: Läuft der Ist-Zustand gerade innerhalb des Schlauchs? Das ist normale Überwachung. Ihr frühestes Signal ist die Reserve – der Abstand zur Wand. Eine schrumpfende Reserve ist der früheste messbare Hinweis auf ein Problem, lange bevor tatsächlich etwas aus dem Schlauch herausläuft.
Prüfung 2 – Auftrag: Kann das System die gewünschte Veränderung überhaupt in der geforderten Geschwindigkeit leisten? Ein Kunstflugzeug rollt in Sekundenbruchteilen, ein Großraumflugzeug für dieselbe Wende braucht Minuten. Wird ein Auftrag erteilt, der schneller ist, als das System laut seiner eigenen Deklaration kann, ist das bereits vor der Ausführung als Fehler erkennbar – nicht erst danach, wenn es schiefgeht. Es gibt dann genau drei ehrliche Auswege: das Ziel langsamer takten, den Schlauch bewusst verbreitern, oder das System selbst ändern. Was es nicht gibt: den Auftrag trotzdem erteilen und hoffen.
Prüfung 3 – Zusammenspiel: Passt das, was Komponente A abgibt, in das, was Komponente B erlaubt oder erwartet? Das ist dieselbe Rechnung, nur an der Schnittstelle zwischen zwei Systemen angewendet. Genau hier liegt der klassische blinde Fleck vieler Analysen: Eine Motorvibration, die auf dem vorgesehenen Signalkanal harmlos ist, kann auf einem nie geplanten Kopplungskanal – etwa einer benachbarten Lötstelle – durchaus die Wand überschreiten. Diese Prüfung findet solche Fälle nur, wenn der Kanal überhaupt als solcher deklariert wurde. Ist er es nicht, bekommt er ein sichtbares Flag „Kanal nicht deklariert" – statt stillschweigend als „alles in Ordnung" gelesen zu werden.
Die ehrlichen Grenzen#
Dieses Modell ist kein Zauberwerkzeug. Drei Einschränkungen gehören dazu, unbedingt:
- Es ist nur so vollständig wie die Deklaration selbst. Fehlt die äußere Wand (PIA), ist die Restmenge unbegrenzt – und der Vollständigkeitsanspruch leer. Fehlende oder falsche Deklarationen bekommen deshalb ein sichtbares Flag statt eines stillen „passt schon".
- Es ersetzt keine System-Sicht. Komponentenweise sauber deklariert heißt nicht automatisch systemweit sicher. Wechselwirkungen über mehrere Ebenen bleiben eine eigene Aufgabe.
- In weichen Domänen ist es Denkdisziplin, kein Rechenwerk. „Liefertreue im Schlauch halten" oder „Beziehungsqualität im Schlauch halten" gewinnen durch die richtigen Fragen – wie groß ist die Reserve, wie schnell wird Drift erkannt, wie schnell kann überhaupt reagiert werden. Aber niemand sollte erwarten, eine Geschäftsbeziehung durch einen Solver zu schicken.
Was das für den Alltag heißt#
Der Unterschied zur klassischen Risikoanalyse ist nicht, dass hier mehr Aufwand betrieben wird. Es ist genau umgekehrt: Die Erfindungsarbeit – „was könnte alles schiefgehen" – entfällt fast vollständig. Was bleibt, ist die Disziplin, drei Grenzen sauber aufzuschreiben, die in den meisten Firmen ohnehin schon irgendwo stehen – nur nie unter einem gemeinsamen Dach.
Das vollständige Methodenpapier – mit der mathematischen Herleitung (Tube MPC, Erreichbarkeitsmengen, Levesons STPA), allen Definitionen und der vollständigen Begriffstabelle Deutsch/Englisch – gibt es hier als PDF zum Download.