FMEA (Risikoanalyse)

GENERATED from docs/graph/graphcodedemo.graph.json (SSOT). Render-Form von REQ kind=risk (severity/occurrence/detection nach FM-01). 16 Risiken. Deterministisch generiert.

Failure mode (REQ kind=risk)	S	O	D	RPN	Mitigation	verifiziert
Failure mode: a safety-relevant alarm is buried under a flood of uncritical messages. Effect: delayed reaction by the control center. Cause: no prioritization when messages arrive in bulk.	8	3	5	120	REQ-mit-alarm-prioritization	✗
Failure mode: while an escorted exit is under way, a close command from normal operation reaches the cabin door. Effect: the door closes onto the evacuation route and onto a passenger or a responder. Cause: FUNC-operate-cabin-door consumes FLOW-door-command, imported from FUNC-compute-speed-profile in the line-run chain and in another module, alongside FLOW-evacuation-release; the model states no precedence between the two.	9	2	4	72	REQ-mit-evacuation-overrides-door-command	✗
Failure mode: the cabin door unlocks while the cabin is in motion. Effect: a passenger falls onto the guideway. Cause: failure of the locking monitor, or faulty evaluation of the standstill signal.	10	2	2	40	REQ-mit-dual-channel-locking	✗
Failure mode: the operational picture shows a cabin with closed doors while FLOW-door-status reports them open, or the reverse. Effect: the control center grants a departure or a section release for a cabin whose doors are not proven locked. Cause: the door state is carried in SCHEMA-door-status and again in SCHEMA-cabin-state; the door controller and the cabin controller maintain two copies and FUNC-aggregate-fleet-state consumes both without a precedence rule.	9	3	4	108	REQ-mit-door-state-single-source	✗
Failure mode: FLOW-incident-situation reports the section as de-energized while FLOW-isolation-proof does not attest it, or attests it for a different section. Effect: emergency services enter an energized guideway section; electric shock. Cause: the energization state is carried in SCHEMA-isolation-proof and again in SCHEMA-incident-situation, produced by two functions in two different modules, with no rule that the second is derived from the first.	10	2	5	100	REQ-mit-isolation-proof-reference	✗
Failure mode: a cabin locked out for maintenance is dispatched despite the lockout. Effect: a trip with incompletely tested equipment. Cause: the lockout record is lost when the fleet control system restarts.	5	3	3	45	REQ-mit-lockout-survives-restart	✗
Failure mode: the cabin reports a normal operating state while the lockout record says the cabin is locked out. Effect: the cabin is counted as available in the readiness check and a trip is promised that cannot be served, or the cabin is moved with staff on board. Cause: the lockout state is carried in SCHEMA-lockout-record, held by the fleet control system, and again as operating state in SCHEMA-cabin-state, held by the cabin controller; the two are maintained separately. This is the divergence case, not the restart case already covered by RISK-locked-out-cabin-dispatched.	7	3	4	84	REQ-mit-operating-state-from-lockout	✗
Failure mode: the door closes onto an obstacle without reopening. Effect: injury to the passenger. Cause: contaminated or misaligned obstacle detection.	7	4	3	84	REQ-mit-anti-trap-selftest	✗
Failure mode: the cabin stops outside the stopping window and the gap to the platform screen door exceeds the permitted width. Effect: a fall while boarding or alighting. Cause: drift in positioning or braking deceleration outside its design range.	6	4	3	72	REQ-mit-stopping-window-enforced	✗
Failure mode: both positioning sources fail and the cabin position is undetermined. Effect: the affected section comes to a standstill, or an unsafe block clearance is granted. Cause: a common cause in the power supply of the positioning sensors.	7	3	2	42	REQ-mit-separate-power-for-positioning	✗
Failure mode: the block separation is violated and two cabins collide. Effect: injury to passengers. Cause: stale block occupancy or faulty positioning while no brake request is raised.	10	2	3	60	REQ-mit-wayside-block-check	✗
Failure mode: FUNC-compute-speed-profile accepts a continue decision although the guideway obstacle that caused the stop is still present. Effect: the cabin runs into the obstacle. Cause: FLOW-action-decision is handed over from the fault-handling chain into the line-run chain, where the effect lands; SCHEMA-action-decision carries the decision but no reference to the state of the fault it decides on.	9	2	3	54	REQ-mit-decision-references-alarm	✗
Failure mode: passengers leave a stranded cabin on their own initiative and step into the guideway area. Effect: electric shock or collision with a cabin still running. Cause: panic in the absence of information, combined with a door that can be unlocked.	10	3	4	120	REQ-mit-information-and-locking	✗
Failure mode: FUNC-check-service-readiness answers ready from an operational picture that is out of date. Effect: a cabin is dispatched to a station that has meanwhile gone out of service; the passenger waits at a closed platform and a platform slot is blocked. Cause: FLOW-operational-picture is imported from another chain; REQ-picture-freshness binds the age of the displayed picture, nothing binds the consumer to reject a stale one.	4	4	3	48	REQ-mit-readiness-freshness-check	✗
Failure mode: the door pair is released on a standstill proof that no longer holds. Effect: doors open while the cabin is still creeping; a passenger falls into the platform gap. Cause: the standstill proof is carried twice, in SCHEMA-door-command and in SCHEMA-door-release, produced in two different chains and two different modules; nothing requires the two copies to agree or bounds their age.	10	2	4	80	REQ-mit-single-standstill-proof	✗
Failure mode: a function receives a value in a state field that it does not expect and behaves in an undefined way. Effect: undefined behaviour inside a safety chain, and no test can tell a valid transition from an invalid one. Cause: all 32 SCHEMA elements describe their fields in prose and enumerate no values; fields such as occupancy state, operating state, door state, obstruction state, energization state, release state, lockout state, command type and display priority carry no value list. This is a single system-wide finding, not one per schema.	8	5	8	320	REQ-mit-enumerated-state-values	✗

RENDER der risk/mitigation-REQ, die se-fmea durchs Gate geschrieben hat. Attribute + Kanten exakt wie FM-01/FM-02/FM-03 sie prüfen: severity/occurrence/ detection, Mitigation über compose → REQ[kinds ∋ mitigation], „verifiziert” nur bei einem TEST mit testResult: passed. RPN = S·O·D (die FM-03-Zahl).