Ausgangslage

In der industriellen Instandhaltung und bei Anlagenstillständen bleibt eine Statusänderung selten auf das einzelne Arbeitspaket beschränkt. Beginnt die Arbeit an einem Rohrleitungssystem, sind die zugehörigen Räume vorübergehend nicht nutzbar. Eine Kalibrierung, die diesen Raum voraussetzt, kann nicht starten. Eine weitere Aufgabe, die ihrerseits die Kalibrierung voraussetzt, ist ebenfalls blockiert. Tabellen und allgemeine Projektwerkzeuge erfassen Aufgaben. Die transitive Sperre berechnen sie nicht.

Das Modell beantwortet genau eine Frage: Welche weiteren Elemente müssen sich ändern, wenn der modellierte Graph und ein einzelnes Statusereignis gegeben sind? Es legt nicht fest, welches Arbeitspaket als Nächstes kommt, und es ist kein Nachweis über die Sicherheit der Anlage. Es berechnet die Kaskade.

Ein typisierter Graph aus Aktionen und Ressourcen

Das Netz ist gerichtet. Jeder Knoten ist entweder eine Aktion oder eine Ressource. Jede Kante hat einen von drei Typen:

Typ	Bedeutung	Rolle in der Kaskade
BLOCK	Aktion a sperrt Ressource b, solange a aktiv ist	Direkte Sperre: b führt a in blocked_by
REQUIRE	Element a setzt die Verfügbarkeit von Element b voraus	Rückwirkung: a führt b in required_from, sobald b gesperrt oder selbst abhängig ist
LOCATED	Element a liegt räumlich in b	Nur Lage im Modell, keine Kaskade

Aktionen lösen die Kaskade aus. Ressourcen sind passiv und starten keine eigene Kaskade. Wechselt eine Aktion in einen aktiven Status, werden ihre BLOCK-Kanten wirksam. REQUIRE-Kanten tragen die Markierung „nicht verfügbar“ anschließend entgegen der Kantenrichtung entlang der Abhängigkeitskette weiter.

LOCATED bleibt im Modell, weil eine Anlage räumlich gegliedert ist. Die Kante beschreibt eine Lage, keine Einschränkung. Würde sie kaskadieren, würde jede Raumzuordnung große Teile der Anlage sperren.

Zwei Statusebenen

Jedes Element führt zwei Statuswerte:

• Eigener Status (own) — der gesetzte oder voreingestellte Wert. Die Kaskade überschreibt ihn nicht.
• Ausgewerteter Status (evaluated) — die Anzeige nach Anwendung der Einschränkungen. Er ist eine reine Abbildung der aktuellen Markierung.

Die Auswertung folgt drei Regeln, in dieser Reihenfolge:

blocked_by ist nicht leer      → DepLock
sonst required_from ist nicht leer → DepReq
sonst                          → eigener Status

Sind beide Listen leer, fällt der ausgewertete Status auf den eigenen zurück. Die gesetzte Absicht bleibt unter einer vorübergehenden Sperre sichtbar.

Markierung und Referenzzählung

Auf der Markierung eines Elements liegen drei Listen:

• blocked_by — Aktionen, die das Element über eine BLOCK-Kante gerade sperren
• required_from — Elemente, deren Nichtverfügbarkeit dieses Element abhängig macht
• conflicts_with — andere Aktionen, deren Sperrziele sich mit Ressourcen überschneiden, die dieses Element transitiv voraussetzt

Die Listen wirken als Referenzzähler. Ein Element bleibt auf DepLock oder DepReq, solange die jeweilige Liste nicht leer ist. Mehrfachsperren sind der Normalfall: Zwei Aktionen auf derselben Ressource stehen beide in blocked_by. Das Freigeben der einen hebt die Sperre nicht auf, solange die andere besteht.

conflicts_with ist eine Warnung, kein ausgewerteter Status. Die Markierung erzeugt keine Kanten und legt keine Reihenfolge fest. Sie zeigt eine mögliche gegenseitige Beeinflussung, bevor eine zweite Aktion beginnt.

Die Kaskade als reine, tiefenbegrenzte Funktion

Operativ ist die Kaskade eine Funktion:

(Zustand, Statusereignis) → Menge der Markierungs- und Auswertungsänderungen

Dieselbe Eingabe ergibt dieselbe Änderung. Speichern und Benachrichtigen liegen außerhalb der Funktion. Die Rückverfolgung über REQUIRE endet bei einer konfigurierbaren Tiefe max_depth. Für zyklische Konfliktprüfungen werden bereits besuchte Knoten geführt. Zyklen im Graphen können die Berechnung daher nicht unbegrenzt fortsetzen.

Welche Statuswerte eine Kaskade auslösen, ist je Ebene und optional je Kante festlegbar:

• Aktive Statuswerte. Der Eintritt in einen solchen Wert kann eine Sperrkaskade starten.
• Immune Statuswerte. Diese Elemente übernehmen während der Ausbreitung keine Einträge in blocked_by oder required_from. Der typische Fall ist „erledigt“.

Immunität ist eine Entwurfsentscheidung. Öffnet man ein immunes Element erneut, ohne das Netz neu auszuwerten, kann es als frei erscheinen, obwohl die Sperre noch besteht. Sieht das Modell ein erneutes Öffnen vor, wird der aktuelle Netzzustand dafür neu eingelesen.

Ein kurzer Ablauf

1. Aktion A1 wird aktiv. BLOCK(A1 → R1) trägt A1 in R1.blocked_by ein. R1 wird als DepLock ausgewertet.
2. REQUIRE(A2 → R1) erkennt die Sperre von R1. A2 führt R1 in required_from und wird als DepReq ausgewertet. Setzt ein weiteres Element A2 voraus, setzt sich die Rückverfolgung fort, bis die Tiefe oder das Ende der Kette erreicht ist.
3. A1 endet oder verlässt den aktiven Status. Die Sperre entfernt A1 aus R1.blocked_by. Ist die Liste leer, fällt R1 auf den eigenen Status zurück. Die abhängigen required_from-Einträge werden auf dieselbe Weise entfernt.

Der Ablauf erzeugt keine Abhängigkeit. Der Graph ist vorgegeben. Die Kaskade wertet ihn aus.

Abgrenzung

Die Grenze des Verfahrens gehört zum Ergebnis:

• Es ist kein automatischer Planer und kein Optimierer. Es wählt nicht das nächste Arbeitspaket und minimiert keine Stillstandszeit.
• Es ist kein Sicherheitsnachweis und kein formal verifiziertes Anlagenmodell. Es ist eine Projektion der Einschränkungen für die operative Arbeit.
• Es ist keine Laufzeitumgebung zur Verifikation von Petri-Netzen. Markierungslisten können an Token erinnern. Das ausgelieferte Verhalten ist ein typisierter Durchlauf des Graphen mit Referenzzählern.
• Es erfindet keine Abhängigkeiten. LOCATED löst keine Kaskade aus.
• Es ist kein Verfahren des maschinellen Lernens. conflicts_with folgt aus der Struktur des Graphen.
• Es koppelt Ebenen nicht stillschweigend. Die Kaskade bleibt auf ihre Ebene beschränkt. Eine Verbindung zwischen Ebenen ist ein ausdrückliches, externes Muster.

Warum das Modell klein bleibt

Werkzeuge für den operativen Betrieb sammeln mit der Zeit Ausnahmen: manuelle Überschreibungen, administrative Kennzeichen, Sonderstatus, die die Regeln umgehen. Jede Ausnahme vermittelt, dass der Graph nicht verbindlich ist.

Eine verlässliche Kaskade lässt den eigenen Status unverändert. Sie bildet den ausgewerteten Status als Projektion. BLOCK und REQUIRE tragen die Einschränkungen. LOCATED bleibt bei der räumlichen Lage. Die Tiefengrenze hält den Durchlauf endlich.

Das genügt, um das Abbild einer Instandhaltung oder eines Stillstands konsistent zu halten. Terminplanung, Sicherheitsnachweis und Optimierung bleiben eigene Aufgaben.