← graphcode-Demo

Anforderungsspezifikation (SRS)

Alle 64 Anforderungen unter dem Element, das sie erfüllt — Akteure, Anwendungsfälle, Funktionen, Bausteine.

Aus dem Modell generiert — Snapshot vom 22.08.2026, graphcode 0.17.0. Modellsprache ist Englisch.

GENERATED from docs/graph/graphcodedemo.graph.json (SSOT). Textuelle Spezifikation (29148-Anlehnung): compose=Hierarchie, io=Reihenfolge, REQ unter ihrem satisfy-Element. 64 REQ. Deterministisch generiert.

1 Scope

SYS-people-mover — Driverless cabin transit system for inner-city passenger transport on a dedicated guideway. Eight stations, cabins run fully automatically at block separation, one control center supervises the fleet and intervenes only when something goes wrong.

REQ-mit-enumerated-state-values — Every state field names its permitted values

Mitigation: every state or status field in a SCHEMA enumerates its permitted values and names the transitions between them. A value outside the list is rejected at the interface and reported, not interpreted.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-state-value-enumeration (integration) · satisfy ◀ SYS-people-mover · allocate ▶ —

2 Akteure

2.1 ACTOR-control-center — Control Center Operator

Trained operator who supervises the fleet, acknowledges faults and, in an emergency, grants the release for an evacuation.

io ▶ FLOW-acknowledgement · FLOW-clearance-order · FLOW-line-release · FLOW-picture-configuration · UC-evacuate-cabin · UC-handle-fault · UC-supervise-operation · io ◀ FLOW-control-center-display

2.2 ACTOR-emergency-services — Emergency Services

External responders who work on the guideway during an evacuation.

io ▶ UC-evacuate-cabin · io ◀ FLOW-incident-situation

2.3 ACTOR-maintenance-technician — Maintenance Technician

Technician who takes cabins out of service as scheduled, services them and releases them back into operation.

io ▶ FLOW-maintenance-request · UC-service-cabin · io ◀ FLOW-release-confirmation

2.4 ACTOR-passenger — Passenger

Person who wants to travel between two stations. Not trained staff; operates only the platform terminal and the app.

io ▶ FLOW-doorway-obstruction · FLOW-trip-request · UC-board-and-alight · UC-evacuate-cabin · UC-request-trip · UC-run-the-line · io ◀ FLOW-cabin-assignment · FLOW-cabin-motion · FLOW-door-motion · FLOW-passenger-announcement

3 Use Cases & Verhalten

3.1 UC-board-and-alight — Boarding and alighting at the platform

The stopped cabin releases boarding and alighting by opening cabin door and platform screen door only in synchrony and only while the cabin stands still.

io ◀ ACTOR-passenger

3.1.1 FCHAIN-door-cycle — Door cycle at the platform

Proof that the cabin is at a standstill, proof that the platform screen door is locked, synchronous release of both doors, anti-trap protection while closing, proof of locking before departure is released.

3.1.1.1 FUNC-determine-position — Determine position on two channels

auch in: FCHAIN-line-run

Determines the cabin position from two independent sources and reports the loss of one source as a restriction of service.

io ◀ FLOW-cabin-motion · io ▶ FLOW-cabin-position · allocate ▶ MOD-cabin-controller

REQ-dual-channel-positioning — Positioning is dual-channel

auch unter: FUNC-report-block-occupancy

Position determination rests on two independent sources; if one fails, the cabin runs on sight to the next station and reports the failure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-single-channel-position-loss (integration) · satisfy ◀ FUNC-determine-position · FUNC-report-block-occupancy · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

REQ-pre-cabin-at-standstill — Cabin stands in position

Precondition: the cabin reports standstill and a longitudinal position within the permitted stopping tolerance.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-door-cycle (acceptance) · satisfy ◀ FUNC-determine-position · allocate ▶ MOD-cabin-controller

REQ-stopping-accuracy — Stopping accuracy below 50 mm

auch unter: FUNC-synchronize-door-pair

The cabin stops with a longitudinal deviation of at most 50 millimeters from the platform screen door, so that the gap does not exceed the permitted width.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-stopping-accuracy (system) · satisfy ◀ FUNC-determine-position · FUNC-synchronize-door-pair · allocate ▶ MOD-cabin-controller · MOD-platform-door-system

3.1.1.2 FUNC-synchronize-door-pair — Synchronize door pair

Interlocks cabin door and platform screen door so that neither of them can open on its own.

io ◀ FLOW-cabin-position · FLOW-reopen-command · io ▶ FLOW-door-release · allocate ▶ MOD-platform-door-system

REQ-doors-open-in-sync — Doors open only in synchrony

auch unter: FUNC-operate-cabin-door · FUNC-operate-platform-door

Cabin door and the matching platform screen door open exclusively together, and only while the cabin is reported to be standing in position.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-doors-open-only-together (integration) · satisfy ◀ FUNC-operate-cabin-door · FUNC-operate-platform-door · FUNC-synchronize-door-pair · allocate ▶ MOD-door-controller · MOD-platform-door-system

REQ-mit-single-standstill-proof — One standstill proof, referenced not copied

Mitigation: the standstill proof is produced once by FUNC-determine-position and referenced by identifier and timestamp in the door command and in the door release. A reference older than the release validity is invalid and blocks the release.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-stale-standstill-proof (safety) · satisfy ◀ FUNC-synchronize-door-pair · allocate ▶ MOD-platform-door-system

REQ-stopping-accuracy — Stopping accuracy below 50 mm

auch unter: FUNC-determine-position

The cabin stops with a longitudinal deviation of at most 50 millimeters from the platform screen door, so that the gap does not exceed the permitted width.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-stopping-accuracy (system) · satisfy ◀ FUNC-determine-position · FUNC-synchronize-door-pair · allocate ▶ MOD-cabin-controller · MOD-platform-door-system

3.1.1.3 FUNC-operate-cabin-door — Operate cabin door

auch in: FCHAIN-evacuation

Opens and closes the cabin door only on command and only while a standstill is reported.

io ◀ FLOW-door-command · FLOW-door-release · FLOW-evacuation-release · FLOW-reopen-command · io ▶ FLOW-door-motion · allocate ▶ MOD-door-controller

REQ-doors-open-in-sync — Doors open only in synchrony

auch unter: FUNC-operate-platform-door · FUNC-synchronize-door-pair

Cabin door and the matching platform screen door open exclusively together, and only while the cabin is reported to be standing in position.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-doors-open-only-together (integration) · satisfy ◀ FUNC-operate-cabin-door · FUNC-operate-platform-door · FUNC-synchronize-door-pair · allocate ▶ MOD-door-controller · MOD-platform-door-system

REQ-mit-evacuation-overrides-door-command — Evacuation release overrides the door command

Mitigation: while a valid evacuation release exists, FUNC-operate-cabin-door ignores FLOW-door-command. The precedence is explicit in the door controller and holds until the release is withdrawn by the control center.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-door-command-during-evacuation (safety) · satisfy ◀ FUNC-operate-cabin-door · allocate ▶ MOD-door-controller

REQ-no-self-evacuation — No self-evacuation

auch unter: FUNC-grant-evacuation-release

On the open guideway the cabin door can be unlocked only after release by the control center; without that release it stays locked even when the emergency release handle is pulled.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-emergency-handle-without-release (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-operate-cabin-door · allocate ▶ MOD-control-center-dashboard · MOD-door-controller

3.1.1.4 FUNC-detect-obstruction — Detect obstruction

Detects an obstacle in the doorway while closing and triggers the door to reopen.

io ◀ FLOW-door-motion · FLOW-doorway-obstruction · io ▶ FLOW-reopen-command · allocate ▶ MOD-door-controller

REQ-anti-trap-protection — Anti-trap protection while closing

An obstacle in the doorway makes the door reopen within 200 milliseconds; after three attempts the control center is alerted.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-anti-trap-reopen (safety) · satisfy ◀ FUNC-detect-obstruction · allocate ▶ MOD-door-controller

3.1.1.5 FUNC-operate-platform-door — Operate platform door

Drives the fixed platform screen door and refuses to open it without a cabin at a standstill.

io ◀ FLOW-door-release · FLOW-reopen-command · io ▶ FLOW-door-motion · allocate ▶ MOD-platform-door-system

REQ-doors-open-in-sync — Doors open only in synchrony

auch unter: FUNC-operate-cabin-door · FUNC-synchronize-door-pair

Cabin door and the matching platform screen door open exclusively together, and only while the cabin is reported to be standing in position.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-doors-open-only-together (integration) · satisfy ◀ FUNC-operate-cabin-door · FUNC-operate-platform-door · FUNC-synchronize-door-pair · allocate ▶ MOD-door-controller · MOD-platform-door-system

3.1.1.6 FUNC-prove-door-locking — Prove door locking

Establishes the read-back proof that both doors are closed and locked, as the precondition for releasing departure.

io ◀ FLOW-door-motion · io ▶ FLOW-door-status · allocate ▶ MOD-door-controller

REQ-post-doors-locked — Doors are reported locked

Postcondition: both doors are closed and the locking proof is available to the fleet control system.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-door-cycle (acceptance) · satisfy ◀ FUNC-prove-door-locking · allocate ▶ MOD-door-controller

3.2 UC-evacuate-cabin — Evacuate cabin

Passengers leave a cabin stranded on the open guideway only after an explicit release by the control center and escorted by the emergency responders.

io ◀ ACTOR-control-center · ACTOR-emergency-services · ACTOR-passenger

3.2.1 FCHAIN-evacuation — Release to cleared cabin

Confirming that the cabin cannot move, isolating the affected section, blocking adjacent block sections, release by the control center, escorted exit, report of the cleared cabin.

3.2.1.1 FUNC-prove-isolation — Prove isolation

auch in: FCHAIN-maintenance-window

Establishes the proof that a guideway section is de-energized and secured against being switched back on.

io ◀ FLOW-action-decision · FLOW-clearance-order · FLOW-lockout-record · io ▶ FLOW-isolation-proof · allocate ▶ MOD-wayside-sensors

REQ-pre-cabin-in-depot — Cabin is in the depot

Precondition: the cabin stands on the depot track and is secured against movement.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-maintenance-window (acceptance) · satisfy ◀ FUNC-prove-isolation · allocate ▶ MOD-wayside-sensors

REQ-section-de-energized — Section is de-energized

auch unter: FUNC-grant-evacuation-release

Before exit is released, the affected guideway section is provably de-energized and secured against being switched back on.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-release-requires-isolation-proof (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-prove-isolation · allocate ▶ MOD-control-center-dashboard · MOD-wayside-sensors

3.2.1.2 FUNC-announce-situation — Announce situation

Gives passengers inside the cabin an understandable situation announcement at the prescribed interval.

io ◀ FLOW-clearance-order · FLOW-evacuation-release · FLOW-isolation-proof · io ▶ FLOW-passenger-announcement · allocate ▶ MOD-passenger-app

REQ-passenger-information — Information without staff on site

Passengers in the cabin receive an understandable situation announcement within 30 seconds of the stop, and an update at least every two minutes thereafter.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-announcement-interval (acceptance) · satisfy ◀ FUNC-announce-situation · allocate ▶ MOD-passenger-app

3.2.1.3 FUNC-grant-evacuation-release — Grant evacuation release

Grants the release to unlock a cabin on the open guideway only once the isolation proof is available.

io ◀ FLOW-isolation-proof · io ▶ FLOW-evacuation-release · FLOW-incident-situation · allocate ▶ MOD-control-center-dashboard

REQ-mit-isolation-proof-reference — Incident situation cites the isolation proof

Mitigation: FLOW-incident-situation carries the identifier and timestamp of the isolation proof it is derived from. Without a valid, current reference the energization state is reported as unknown, never as de-energized.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-energization-state-divergence (safety) · satisfy ◀ FUNC-grant-evacuation-release · allocate ▶ MOD-control-center-dashboard

REQ-no-self-evacuation — No self-evacuation

auch unter: FUNC-operate-cabin-door

On the open guideway the cabin door can be unlocked only after release by the control center; without that release it stays locked even when the emergency release handle is pulled.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-emergency-handle-without-release (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-operate-cabin-door · allocate ▶ MOD-control-center-dashboard · MOD-door-controller

REQ-post-cabin-cleared — Cabin is reported cleared

Postcondition: all passengers have been escorted out of the cabin and the clearance has been reported to the control center.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-evacuation (acceptance) · satisfy ◀ FUNC-grant-evacuation-release · allocate ▶ MOD-control-center-dashboard

REQ-pre-cabin-immobilized — Cabin is immobilized

Precondition: the cabin has been classified as no longer able to clear the line under its own power.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-evacuation (acceptance) · satisfy ◀ FUNC-grant-evacuation-release · allocate ▶ MOD-control-center-dashboard

REQ-section-de-energized — Section is de-energized

auch unter: FUNC-prove-isolation

Before exit is released, the affected guideway section is provably de-energized and secured against being switched back on.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-release-requires-isolation-proof (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-prove-isolation · allocate ▶ MOD-control-center-dashboard · MOD-wayside-sensors

3.2.1.4 FUNC-operate-cabin-door — Operate cabin door

auch in: FCHAIN-door-cycle

Opens and closes the cabin door only on command and only while a standstill is reported.

io ◀ FLOW-door-command · FLOW-door-release · FLOW-evacuation-release · FLOW-reopen-command · io ▶ FLOW-door-motion · allocate ▶ MOD-door-controller

REQ-doors-open-in-sync — Doors open only in synchrony

auch unter: FUNC-operate-platform-door · FUNC-synchronize-door-pair

Cabin door and the matching platform screen door open exclusively together, and only while the cabin is reported to be standing in position.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-doors-open-only-together (integration) · satisfy ◀ FUNC-operate-cabin-door · FUNC-operate-platform-door · FUNC-synchronize-door-pair · allocate ▶ MOD-door-controller · MOD-platform-door-system

REQ-mit-evacuation-overrides-door-command — Evacuation release overrides the door command

Mitigation: while a valid evacuation release exists, FUNC-operate-cabin-door ignores FLOW-door-command. The precedence is explicit in the door controller and holds until the release is withdrawn by the control center.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-door-command-during-evacuation (safety) · satisfy ◀ FUNC-operate-cabin-door · allocate ▶ MOD-door-controller

REQ-no-self-evacuation — No self-evacuation

auch unter: FUNC-grant-evacuation-release

On the open guideway the cabin door can be unlocked only after release by the control center; without that release it stays locked even when the emergency release handle is pulled.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-emergency-handle-without-release (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-operate-cabin-door · allocate ▶ MOD-control-center-dashboard · MOD-door-controller

3.3 UC-handle-fault — Handle fault

When a fault is detected, the affected cabin takes itself into the safe state and the control center decides how to proceed.

io ◀ ACTOR-control-center

3.3.1 FCHAIN-fault-handling — Fault detection to acknowledgement

Detection of the fault on board or along the guideway, transition into the safe state, alerting of the control center, assessment of the situation, acknowledgement and decision to continue or to clear the cabin.

3.3.1.1 FUNC-detect-guideway-obstacle — Detect obstacle on the guideway

Detects foreign objects and people inside the clearance envelope and reports them as a safety-relevant fault.

io ◀ FLOW-cabin-motion · io ▶ FLOW-alarm · allocate ▶ MOD-wayside-sensors

REQ-alarm-latency — Alarm within two seconds

auch unter: FUNC-display-alarm

A safety-relevant fault appears on the control center dashboard no later than two seconds after it was detected.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-alarm-latency (performance) · satisfy ◀ FUNC-detect-guideway-obstacle · FUNC-display-alarm · allocate ▶ MOD-control-center-dashboard · MOD-wayside-sensors

REQ-safe-state-unattended — Safe state without intervention

auch unter: FUNC-trigger-emergency-brake

Every detected safety-relevant fault brings the affected cabin to a stop with locked doors, without any action by the control center.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-safe-state-without-control-center (safety) · satisfy ◀ FUNC-detect-guideway-obstacle · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

3.3.1.2 FUNC-display-alarm — Display alarm

Brings safety-relevant faults to the control center workstation immediately and unmissably.

io ◀ FLOW-alarm · io ▶ FLOW-control-center-display · allocate ▶ MOD-control-center-dashboard

REQ-alarm-latency — Alarm within two seconds

auch unter: FUNC-detect-guideway-obstacle

A safety-relevant fault appears on the control center dashboard no later than two seconds after it was detected.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-alarm-latency (performance) · satisfy ◀ FUNC-detect-guideway-obstacle · FUNC-display-alarm · allocate ▶ MOD-control-center-dashboard · MOD-wayside-sensors

REQ-pre-fault-classified — Fault is classified

Precondition: the fault has been detected and assigned to a severity class.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-fault-handling (acceptance) · satisfy ◀ FUNC-display-alarm · allocate ▶ MOD-control-center-dashboard

3.3.1.3 FUNC-record-acknowledgement — Record acknowledgement

Accepts the acknowledgement from the control center and records it immutably with time and person.

io ◀ FLOW-acknowledgement · FLOW-alarm · io ▶ FLOW-action-decision · allocate ▶ MOD-control-center-dashboard

REQ-acknowledgement-attributable — Acknowledgement is attributable

Every acknowledgement is recorded with time, person and the fault it refers to, and cannot be altered afterwards.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-acknowledgement-immutable (integration) · satisfy ◀ FUNC-record-acknowledgement · allocate ▶ MOD-control-center-dashboard

REQ-post-situation-decided — Situation has been decided

Postcondition: the control center has ordered continuation, clearance or evacuation, and the decision is recorded.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-fault-handling (acceptance) · satisfy ◀ FUNC-record-acknowledgement · allocate ▶ MOD-control-center-dashboard

3.3.1.4 FUNC-trigger-emergency-brake — Trigger emergency brake

auch in: FCHAIN-line-run

Triggers braking on its own as soon as the block separation is about to be violated or a safety-relevant fault is detected.

io ◀ FLOW-alarm · FLOW-block-clearance · FLOW-cabin-position · io ▶ FLOW-brake-request · allocate ▶ MOD-cabin-controller

REQ-block-separation — Block separation is never violated

auch unter: FUNC-grant-block-clearance · FUNC-report-block-occupancy

The cabin never falls below the block separation assigned by the fleet control system; if a violation is imminent, it brakes on its own.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-block-separation-holds (safety) · satisfy ◀ FUNC-grant-block-clearance · FUNC-report-block-occupancy · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-fleet-control-system · MOD-wayside-sensors

REQ-safe-state-unattended — Safe state without intervention

auch unter: FUNC-detect-guideway-obstacle

Every detected safety-relevant fault brings the affected cabin to a stop with locked doors, without any action by the control center.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-safe-state-without-control-center (safety) · satisfy ◀ FUNC-detect-guideway-obstacle · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

3.4 UC-request-trip — Request a trip

The passenger selects a destination station at the terminal or in the app and is assigned a cabin together with a binding waiting time.

io ◀ ACTOR-passenger

3.4.1 FCHAIN-trip-request — Trip request to cabin assignment

Destination entry at the terminal, check that the destination station is in service, dispatch of a free cabin by the fleet control system, waiting time reported back to the passenger.

3.4.1.1 FUNC-capture-destination — Capture destination

Accepts the destination station at the terminal or in the app and hands it to the fleet control system as a trip request.

io ◀ FLOW-trip-request · io ▶ FLOW-dispatch-request · allocate ▶ MOD-passenger-app

REQ-destination-entry — Destination entry without prior knowledge

auch unter: FUNC-dispatch-trip-order

The passenger selects one of eight stations in at most two operating steps, without prior registration and without knowing the line structure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-destination-entry-steps (acceptance) · satisfy ◀ FUNC-capture-destination · FUNC-dispatch-trip-order · allocate ▶ MOD-fleet-control-system · MOD-passenger-app

3.4.1.2 FUNC-check-service-readiness — Check service readiness

Checks before dispatch whether the destination station is released and at least one cabin is available in normal operating state.

io ◀ FLOW-dispatch-request · FLOW-operational-picture · io ▶ FLOW-service-readiness · allocate ▶ MOD-fleet-control-system

REQ-mit-readiness-freshness-check — Readiness check rejects a stale picture

Mitigation: FUNC-check-service-readiness rejects an operational picture older than three seconds and answers readiness unknown instead of ready; the dispatch is withheld and the passenger is told the wait is unknown.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-stale-readiness-picture (integration) · satisfy ◀ FUNC-check-service-readiness · allocate ▶ MOD-fleet-control-system

REQ-pre-line-in-service — Line is in service

Precondition: the destination station is released and at least one cabin is in normal operating state.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-trip-request (acceptance) · satisfy ◀ FUNC-check-service-readiness · allocate ▶ MOD-fleet-control-system

3.4.1.3 FUNC-dispatch-trip-order — Dispatch trip order

Picks the most suitable free cabin for a trip request, binds it and creates the trip order with destination station and time window.

io ◀ FLOW-dispatch-request · FLOW-lockout-record · FLOW-service-readiness · io ▶ FLOW-trip-order · allocate ▶ MOD-fleet-control-system

REQ-destination-entry — Destination entry without prior knowledge

auch unter: FUNC-capture-destination

The passenger selects one of eight stations in at most two operating steps, without prior registration and without knowing the line structure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-destination-entry-steps (acceptance) · satisfy ◀ FUNC-capture-destination · FUNC-dispatch-trip-order · allocate ▶ MOD-fleet-control-system · MOD-passenger-app

REQ-post-cabin-assigned — Cabin is bindingly assigned

Postcondition: exactly one cabin is assigned to the trip request and recorded as bound in the fleet control system.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-trip-request (acceptance) · satisfy ◀ FUNC-dispatch-trip-order · allocate ▶ MOD-fleet-control-system

REQ-waiting-time-promise — The promised waiting time holds

auch unter: FUNC-show-waiting-time

The waiting time shown to the passenger is met in at least 95 percent of cases in normal operation; deviations of more than 60 seconds are actively reported.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-waiting-time-promise (integration) · satisfy ◀ FUNC-dispatch-trip-order · FUNC-show-waiting-time · allocate ▶ MOD-fleet-control-system · MOD-passenger-app

3.4.1.4 FUNC-show-waiting-time — Show waiting time

Shows the passenger the promised waiting time and actively reports deviations of more than 60 seconds.

io ◀ FLOW-trip-order · io ▶ FLOW-cabin-assignment · allocate ▶ MOD-passenger-app

REQ-waiting-time-promise — The promised waiting time holds

auch unter: FUNC-dispatch-trip-order

The waiting time shown to the passenger is met in at least 95 percent of cases in normal operation; deviations of more than 60 seconds are actively reported.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-waiting-time-promise (integration) · satisfy ◀ FUNC-dispatch-trip-order · FUNC-show-waiting-time · allocate ▶ MOD-fleet-control-system · MOD-passenger-app

3.5 UC-run-the-line — Cabin runs the line

The cabin runs an issued trip order driverless and keeps the block separation prescribed by the fleet control system from the cabin ahead at all times.

io ◀ ACTOR-passenger

3.5.1 FCHAIN-line-run — Trip order to stop at the destination station

Acceptance of the trip order, computation of the speed profile, continuous comparison of positioning and block occupancy, brake control, stop within the target window.

3.5.1.1 FUNC-compute-speed-profile — Compute speed profile

Turns a trip order into a speed profile that respects block clearance, stopping window and comfort limits.

io ◀ FLOW-action-decision · FLOW-block-clearance · FLOW-brake-request · FLOW-cabin-position · FLOW-trip-order · io ▶ FLOW-cabin-motion · FLOW-door-command · allocate ▶ MOD-cabin-controller

REQ-mit-decision-references-alarm — Continue decision is bound to a cleared alarm

Mitigation: the action decision carries the identifier of the alarm it answers. A continue decision is accepted only while the referenced alarm is cleared; otherwise the cabin stays in the safe state and the control center is told why.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-resume-with-active-alarm (safety) · satisfy ◀ FUNC-compute-speed-profile · allocate ▶ MOD-cabin-controller

REQ-post-inside-target-window — Cabin stands inside the target window

Postcondition: the cabin stands at the destination station within the permitted stopping window.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-line-run (acceptance) · satisfy ◀ FUNC-compute-speed-profile · allocate ▶ MOD-cabin-controller

REQ-ride-comfort — Acceleration below 1.2 m/s2

Longitudinal acceleration and deceleration stay below 1.2 meters per second squared in normal operation, so that standing passengers can hold on safely.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-ride-comfort-acceleration (system) · satisfy ◀ FUNC-compute-speed-profile · allocate ▶ MOD-cabin-controller

3.5.1.2 FUNC-determine-position — Determine position on two channels

auch in: FCHAIN-door-cycle

Determines the cabin position from two independent sources and reports the loss of one source as a restriction of service.

io ◀ FLOW-cabin-motion · io ▶ FLOW-cabin-position · allocate ▶ MOD-cabin-controller

REQ-dual-channel-positioning — Positioning is dual-channel

auch unter: FUNC-report-block-occupancy

Position determination rests on two independent sources; if one fails, the cabin runs on sight to the next station and reports the failure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-single-channel-position-loss (integration) · satisfy ◀ FUNC-determine-position · FUNC-report-block-occupancy · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

REQ-pre-cabin-at-standstill — Cabin stands in position

Precondition: the cabin reports standstill and a longitudinal position within the permitted stopping tolerance.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-door-cycle (acceptance) · satisfy ◀ FUNC-determine-position · allocate ▶ MOD-cabin-controller

REQ-stopping-accuracy — Stopping accuracy below 50 mm

auch unter: FUNC-synchronize-door-pair

The cabin stops with a longitudinal deviation of at most 50 millimeters from the platform screen door, so that the gap does not exceed the permitted width.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-stopping-accuracy (system) · satisfy ◀ FUNC-determine-position · FUNC-synchronize-door-pair · allocate ▶ MOD-cabin-controller · MOD-platform-door-system

3.5.1.3 FUNC-trigger-emergency-brake — Trigger emergency brake

auch in: FCHAIN-fault-handling

Triggers braking on its own as soon as the block separation is about to be violated or a safety-relevant fault is detected.

io ◀ FLOW-alarm · FLOW-block-clearance · FLOW-cabin-position · io ▶ FLOW-brake-request · allocate ▶ MOD-cabin-controller

REQ-block-separation — Block separation is never violated

auch unter: FUNC-grant-block-clearance · FUNC-report-block-occupancy

The cabin never falls below the block separation assigned by the fleet control system; if a violation is imminent, it brakes on its own.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-block-separation-holds (safety) · satisfy ◀ FUNC-grant-block-clearance · FUNC-report-block-occupancy · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-fleet-control-system · MOD-wayside-sensors

REQ-safe-state-unattended — Safe state without intervention

auch unter: FUNC-detect-guideway-obstacle

Every detected safety-relevant fault brings the affected cabin to a stop with locked doors, without any action by the control center.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-safe-state-without-control-center (safety) · satisfy ◀ FUNC-detect-guideway-obstacle · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

3.5.1.4 FUNC-report-block-occupancy — Report block occupancy

auch in: FCHAIN-operational-picture

Reports the occupancy of every block section from wayside sensors, independently of on-board positioning.

io ◀ FLOW-cabin-motion · io ▶ FLOW-block-occupancy · allocate ▶ MOD-wayside-sensors

REQ-block-separation — Block separation is never violated

auch unter: FUNC-grant-block-clearance · FUNC-trigger-emergency-brake

The cabin never falls below the block separation assigned by the fleet control system; if a violation is imminent, it brakes on its own.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-block-separation-holds (safety) · satisfy ◀ FUNC-grant-block-clearance · FUNC-report-block-occupancy · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-fleet-control-system · MOD-wayside-sensors

REQ-dual-channel-positioning — Positioning is dual-channel

auch unter: FUNC-determine-position

Position determination rests on two independent sources; if one fails, the cabin runs on sight to the next station and reports the failure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-single-channel-position-loss (integration) · satisfy ◀ FUNC-determine-position · FUNC-report-block-occupancy · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

3.5.1.5 FUNC-grant-block-clearance — Grant block clearance

Releases a block section for exactly one cabin and maintains the block separation from the cabin ahead.

io ◀ FLOW-block-occupancy · FLOW-line-release · io ▶ FLOW-block-clearance · allocate ▶ MOD-fleet-control-system

REQ-block-separation — Block separation is never violated

auch unter: FUNC-report-block-occupancy · FUNC-trigger-emergency-brake

The cabin never falls below the block separation assigned by the fleet control system; if a violation is imminent, it brakes on its own.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-block-separation-holds (safety) · satisfy ◀ FUNC-grant-block-clearance · FUNC-report-block-occupancy · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-fleet-control-system · MOD-wayside-sensors

REQ-pre-valid-trip-order — A valid trip order exists

Precondition: the fleet control system has issued a trip order with destination station and block clearance.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-line-run (acceptance) · satisfy ◀ FUNC-grant-block-clearance · allocate ▶ MOD-fleet-control-system

3.6 UC-service-cabin — Service cabin

The maintenance technician takes a cabin out of service as scheduled, works through it and releases it again only after a passed function test.

io ◀ ACTOR-maintenance-technician

3.6.1 FCHAIN-maintenance-window — Withdrawal from service to re-release

Request for the maintenance window, moving the cabin into the depot, lockout against dispatch, execution of the work, function test, re-release by the control center.

3.6.1.1 FUNC-lock-out-cabin — Lock cabin out of dispatch

Takes a cabin out of dispatch and releases it again only after a passed function test.

io ◀ FLOW-maintenance-request · io ▶ FLOW-lockout-record · FLOW-release-confirmation · allocate ▶ MOD-fleet-control-system

REQ-lockout-effective — A locked-out cabin is not dispatched

A cabin locked out for maintenance receives no trip order from the fleet control system, not even when cabins are scarce in normal operation.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-lockout-under-cabin-shortage (integration) · satisfy ◀ FUNC-lock-out-cabin · allocate ▶ MOD-fleet-control-system

REQ-post-cabin-dispatchable — Cabin is dispatchable again

Postcondition: the cabin is listed as dispatchable in the fleet control system again.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-maintenance-window (acceptance) · satisfy ◀ FUNC-lock-out-cabin · allocate ▶ MOD-fleet-control-system

REQ-release-after-function-test — Release only after a function test

Re-release requires a fully passed function test of brake, door and positioning; partial results are not sufficient.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-partial-result-blocks-release (integration) · satisfy ◀ FUNC-lock-out-cabin · allocate ▶ MOD-fleet-control-system

3.6.1.2 FUNC-prove-isolation — Prove isolation

auch in: FCHAIN-evacuation

Establishes the proof that a guideway section is de-energized and secured against being switched back on.

io ◀ FLOW-action-decision · FLOW-clearance-order · FLOW-lockout-record · io ▶ FLOW-isolation-proof · allocate ▶ MOD-wayside-sensors

REQ-pre-cabin-in-depot — Cabin is in the depot

Precondition: the cabin stands on the depot track and is secured against movement.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-maintenance-window (acceptance) · satisfy ◀ FUNC-prove-isolation · allocate ▶ MOD-wayside-sensors

REQ-section-de-energized — Section is de-energized

auch unter: FUNC-grant-evacuation-release

Before exit is released, the affected guideway section is provably de-energized and secured against being switched back on.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-release-requires-isolation-proof (safety) · satisfy ◀ FUNC-grant-evacuation-release · FUNC-prove-isolation · allocate ▶ MOD-control-center-dashboard · MOD-wayside-sensors

3.6.1.3 FUNC-report-cabin-state — Report cabin state

auch in: FCHAIN-operational-picture

Reports position, operating state and current trip order cyclically to the fleet control system.

io ◀ FLOW-brake-request · FLOW-cabin-position · FLOW-lockout-record · io ▶ FLOW-cabin-status-report · allocate ▶ MOD-cabin-controller

REQ-mit-operating-state-from-lockout — Operating state is derived from the lockout record

Mitigation: the cabin operating state is derived from the lockout record rather than maintained as a second copy. A disagreement between the two is treated as locked out and raised as a deviation.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-lockout-state-divergence (integration) · satisfy ◀ FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller

REQ-picture-freshness — Operational picture no older than three seconds

auch unter: FUNC-aggregate-fleet-state · FUNC-present-operational-picture

Every displayed state value is at most three seconds old; older values are marked as stale.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-picture-freshness (performance) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller · MOD-control-center-dashboard · MOD-fleet-control-system

REQ-pre-status-reports-running — Status reports are running

Precondition: at least one cabin is sending cyclic status reports to the fleet control system.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-operational-picture (acceptance) · satisfy ◀ FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller

3.7 UC-supervise-operation — Supervise operation

The control center sees the state of every cabin, station and block section in one picture and spots deviations without having to ask for them.

io ◀ ACTOR-control-center

3.7.1 FCHAIN-operational-picture — Status report to operational picture

Cyclic status reports from cabins and wayside sensors, aggregation in the fleet control system, display as an operational picture, highlighting of deviations.

3.7.1.1 FUNC-report-block-occupancy — Report block occupancy

auch in: FCHAIN-line-run

Reports the occupancy of every block section from wayside sensors, independently of on-board positioning.

io ◀ FLOW-cabin-motion · io ▶ FLOW-block-occupancy · allocate ▶ MOD-wayside-sensors

REQ-block-separation — Block separation is never violated

auch unter: FUNC-grant-block-clearance · FUNC-trigger-emergency-brake

The cabin never falls below the block separation assigned by the fleet control system; if a violation is imminent, it brakes on its own.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-block-separation-holds (safety) · satisfy ◀ FUNC-grant-block-clearance · FUNC-report-block-occupancy · FUNC-trigger-emergency-brake · allocate ▶ MOD-cabin-controller · MOD-fleet-control-system · MOD-wayside-sensors

REQ-dual-channel-positioning — Positioning is dual-channel

auch unter: FUNC-determine-position

Position determination rests on two independent sources; if one fails, the cabin runs on sight to the next station and reports the failure.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-single-channel-position-loss (integration) · satisfy ◀ FUNC-determine-position · FUNC-report-block-occupancy · allocate ▶ MOD-cabin-controller · MOD-wayside-sensors

3.7.1.2 FUNC-aggregate-fleet-state — Aggregate fleet state

Merges the cyclic status reports of all cabins and of the wayside sensors into one consistent operational picture and marks missing reports.

io ◀ FLOW-block-occupancy · FLOW-cabin-status-report · FLOW-door-status · io ▶ FLOW-operational-picture · allocate ▶ MOD-fleet-control-system

REQ-mit-door-state-single-source — Door state for decisions comes from one source

Mitigation: every release decision reads the door state only from FLOW-door-status, which carries the locking proof. The copy in the cabin state report is marked indicative and a disagreement between the two raises a deviation in the operational picture.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-door-state-divergence (integration) · satisfy ◀ FUNC-aggregate-fleet-state · allocate ▶ MOD-fleet-control-system

REQ-picture-complete — Operational picture is complete

auch unter: FUNC-present-operational-picture

The operational picture shows every cabin with position, operating state and trip order; a missing status report is shown as such and not as the last known value.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-missing-report-shown-as-gap (integration) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · allocate ▶ MOD-control-center-dashboard · MOD-fleet-control-system

REQ-picture-freshness — Operational picture no older than three seconds

auch unter: FUNC-present-operational-picture · FUNC-report-cabin-state

Every displayed state value is at most three seconds old; older values are marked as stale.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-picture-freshness (performance) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller · MOD-control-center-dashboard · MOD-fleet-control-system

REQ-post-deviation-visible — Deviations are visible

Postcondition: every deviation from the target state is highlighted on the operational picture.

priority: must · status: n/a · kinds: postcondition

Verification ◀ TEST-scenario-operational-picture (acceptance) · satisfy ◀ FUNC-aggregate-fleet-state · allocate ▶ MOD-fleet-control-system

3.7.1.3 FUNC-present-operational-picture — Present operational picture

Shows the control center cabins, stations and block sections in one picture and highlights deviations.

io ◀ FLOW-operational-picture · FLOW-picture-configuration · io ▶ FLOW-control-center-display · allocate ▶ MOD-control-center-dashboard

REQ-picture-complete — Operational picture is complete

auch unter: FUNC-aggregate-fleet-state

The operational picture shows every cabin with position, operating state and trip order; a missing status report is shown as such and not as the last known value.

priority: must · status: n/a · kinds: functional

Verification ◀ TEST-missing-report-shown-as-gap (integration) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · allocate ▶ MOD-control-center-dashboard · MOD-fleet-control-system

REQ-picture-freshness — Operational picture no older than three seconds

auch unter: FUNC-aggregate-fleet-state · FUNC-report-cabin-state

Every displayed state value is at most three seconds old; older values are marked as stale.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-picture-freshness (performance) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller · MOD-control-center-dashboard · MOD-fleet-control-system

3.7.1.4 FUNC-report-cabin-state — Report cabin state

auch in: FCHAIN-maintenance-window

Reports position, operating state and current trip order cyclically to the fleet control system.

io ◀ FLOW-brake-request · FLOW-cabin-position · FLOW-lockout-record · io ▶ FLOW-cabin-status-report · allocate ▶ MOD-cabin-controller

REQ-mit-operating-state-from-lockout — Operating state is derived from the lockout record

Mitigation: the cabin operating state is derived from the lockout record rather than maintained as a second copy. A disagreement between the two is treated as locked out and raised as a deviation.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-lockout-state-divergence (integration) · satisfy ◀ FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller

REQ-picture-freshness — Operational picture no older than three seconds

auch unter: FUNC-aggregate-fleet-state · FUNC-present-operational-picture

Every displayed state value is at most three seconds old; older values are marked as stale.

priority: should · status: n/a · kinds: non-functional

Verification ◀ TEST-picture-freshness (performance) · satisfy ◀ FUNC-aggregate-fleet-state · FUNC-present-operational-picture · FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller · MOD-control-center-dashboard · MOD-fleet-control-system

REQ-pre-status-reports-running — Status reports are running

Precondition: at least one cabin is sending cyclic status reports to the fleet control system.

priority: must · status: n/a · kinds: precondition

Verification ◀ TEST-scenario-operational-picture (acceptance) · satisfy ◀ FUNC-report-cabin-state · allocate ▶ MOD-cabin-controller

4 Schnittstellen

4.1 FLOW-acknowledgement — Acknowledgement

Acknowledgement of a fault by the control center.

io ◀ ACTOR-control-center · io ▶ FUNC-record-acknowledgement · schema ▶ SCHEMA-acknowledgement

4.2 FLOW-action-decision — Action decision

Decision of the control center to continue the trip or to clear the cabin, taken after a fault has been acknowledged.

io ◀ FUNC-record-acknowledgement · io ▶ FUNC-compute-speed-profile · FUNC-prove-isolation · schema ▶ SCHEMA-action-decision

4.3 FLOW-alarm — Fault alarm

Safety-relevant fault sent from the fleet control system to the control center workstation.

io ◀ FUNC-detect-guideway-obstacle · io ▶ FUNC-display-alarm · FUNC-record-acknowledgement · FUNC-trigger-emergency-brake · schema ▶ SCHEMA-alarm

4.4 FLOW-block-clearance — Block clearance

Release of a block section for exactly one cabin, with the permitted maximum speed.

io ◀ FUNC-grant-block-clearance · io ▶ FUNC-compute-speed-profile · FUNC-trigger-emergency-brake · schema ▶ SCHEMA-block-clearance

4.5 FLOW-block-occupancy — Block occupancy

Occupancy report for a block section from wayside sensors.

io ◀ FUNC-report-block-occupancy · io ▶ FUNC-aggregate-fleet-state · FUNC-grant-block-clearance · schema ▶ SCHEMA-block-occupancy

4.6 FLOW-brake-request — Brake request

Request for a service or emergency brake application, with trigger reason and target deceleration.

io ◀ FUNC-trigger-emergency-brake · io ▶ FUNC-compute-speed-profile · FUNC-report-cabin-state · schema ▶ SCHEMA-brake-request

4.7 FLOW-cabin-assignment — Cabin assignment

Assigned cabin together with the promised waiting time, returned to the passenger.

io ◀ FUNC-show-waiting-time · io ▶ ACTOR-passenger · schema ▶ SCHEMA-cabin-assignment

4.8 FLOW-cabin-motion — Cabin motion

Physical motion of the cabin within the block section as the effect of the speed profile; captured independently by on-board positioning and by wayside sensors.

io ◀ FUNC-compute-speed-profile · io ▶ ACTOR-passenger · FUNC-detect-guideway-obstacle · FUNC-determine-position · FUNC-report-block-occupancy · schema ▶ SCHEMA-cabin-motion

4.9 FLOW-cabin-position — Cabin position

Dual-channel cabin position, with quality indication and reference to the stopping window.

io ◀ FUNC-determine-position · io ▶ FUNC-compute-speed-profile · FUNC-report-cabin-state · FUNC-synchronize-door-pair · FUNC-trigger-emergency-brake · schema ▶ SCHEMA-cabin-position

4.10 FLOW-cabin-status-report — Cabin status report

Cyclic status report from a cabin to the fleet control system.

io ◀ FUNC-report-cabin-state · io ▶ FUNC-aggregate-fleet-state · schema ▶ SCHEMA-cabin-state

4.11 FLOW-clearance-order — Clearance order

Order from the control center to isolate a section and clear a cabin.

io ◀ ACTOR-control-center · io ▶ FUNC-announce-situation · FUNC-prove-isolation · schema ▶ SCHEMA-clearance-order

4.12 FLOW-control-center-display — Control center display

Presentation of the operational picture and of alarms at the control center workstation.

io ◀ FUNC-display-alarm · FUNC-present-operational-picture · io ▶ ACTOR-control-center · schema ▶ SCHEMA-control-center-display

4.13 FLOW-dispatch-request — Dispatch request

Trip request handed from the terminal to the fleet control system as a dispatchable request.

io ◀ FUNC-capture-destination · io ▶ FUNC-check-service-readiness · FUNC-dispatch-trip-order · schema ▶ SCHEMA-dispatch-request

4.14 FLOW-door-command — Door command

Command from the cabin controller to the door controller.

io ◀ FUNC-compute-speed-profile · io ▶ FUNC-operate-cabin-door · schema ▶ SCHEMA-door-command

4.15 FLOW-door-motion — Door motion

Physical motion and end position of the door leaves while opening and closing.

io ◀ FUNC-operate-cabin-door · FUNC-operate-platform-door · io ▶ ACTOR-passenger · FUNC-detect-obstruction · FUNC-prove-door-locking · schema ▶ SCHEMA-door-motion

4.16 FLOW-door-release — Door release

Interlocked release of cabin door and platform screen door once the cabin is proven to be at a standstill.

io ◀ FUNC-synchronize-door-pair · io ▶ FUNC-operate-cabin-door · FUNC-operate-platform-door · schema ▶ SCHEMA-door-release

4.17 FLOW-door-status — Door status

Feedback of door state and locking proof.

io ◀ FUNC-prove-door-locking · io ▶ FUNC-aggregate-fleet-state · schema ▶ SCHEMA-door-status

4.18 FLOW-doorway-obstruction — Doorway obstruction

Person or object inside the door envelope while the door is closing.

io ◀ ACTOR-passenger · io ▶ FUNC-detect-obstruction · schema ▶ SCHEMA-doorway-obstruction

4.19 FLOW-evacuation-release — Evacuation release

Release to unlock a cabin stranded on the open guideway.

io ◀ FUNC-grant-evacuation-release · io ▶ FUNC-announce-situation · FUNC-operate-cabin-door · schema ▶ SCHEMA-evacuation-release

4.20 FLOW-incident-situation — Incident situation

Situation report to the emergency responders during an evacuation.

io ◀ FUNC-grant-evacuation-release · io ▶ ACTOR-emergency-services · schema ▶ SCHEMA-incident-situation

4.21 FLOW-isolation-proof — Isolation proof

Proof that a section is de-energized and secured against being switched back on.

io ◀ FUNC-prove-isolation · io ▶ FUNC-announce-situation · FUNC-grant-evacuation-release · schema ▶ SCHEMA-isolation-proof

4.22 FLOW-line-release — Line release

Release of the guideway for revenue service by the control center.

io ◀ ACTOR-control-center · io ▶ FUNC-grant-block-clearance · schema ▶ SCHEMA-line-release

4.23 FLOW-lockout-record — Lockout record

Persistent record that a cabin must not be dispatched until it has passed its function test.

io ◀ FUNC-lock-out-cabin · io ▶ FUNC-dispatch-trip-order · FUNC-prove-isolation · FUNC-report-cabin-state · schema ▶ SCHEMA-lockout-record

4.24 FLOW-maintenance-request — Maintenance request

Request for a maintenance window raised by the maintenance technician.

io ◀ ACTOR-maintenance-technician · io ▶ FUNC-lock-out-cabin · schema ▶ SCHEMA-maintenance-request

4.25 FLOW-operational-picture — Operational picture

Aggregated operational picture built from cabin states and section occupancy, marking any missing reports.

io ◀ FUNC-aggregate-fleet-state · io ▶ FUNC-check-service-readiness · FUNC-present-operational-picture · schema ▶ SCHEMA-operational-picture

4.26 FLOW-passenger-announcement — Passenger announcement

Situation announcement to the passengers inside a stranded cabin.

io ◀ FUNC-announce-situation · io ▶ ACTOR-passenger · schema ▶ SCHEMA-passenger-announcement

4.27 FLOW-picture-configuration — Picture configuration

Map extent and highlighting thresholds of the operational picture, set by the control center.

io ◀ ACTOR-control-center · io ▶ FUNC-present-operational-picture · schema ▶ SCHEMA-picture-configuration

4.28 FLOW-release-confirmation — Release confirmation

Confirmation to the maintenance technician that a cabin has been re-released after a passed function test.

io ◀ FUNC-lock-out-cabin · io ▶ ACTOR-maintenance-technician · schema ▶ SCHEMA-release-confirmation

4.29 FLOW-reopen-command — Reopen command

Command to reopen both doors immediately after an obstruction has been detected.

io ◀ FUNC-detect-obstruction · io ▶ FUNC-operate-cabin-door · FUNC-operate-platform-door · FUNC-synchronize-door-pair · schema ▶ SCHEMA-reopen-command

4.30 FLOW-service-readiness — Service readiness

Release state of the destination station and number of cabins available for service, as the precondition for dispatch.

io ◀ FUNC-check-service-readiness · io ▶ FUNC-dispatch-trip-order · schema ▶ SCHEMA-service-readiness

4.31 FLOW-trip-order — Trip order

Binding trip order from the fleet control system to a cabin.

io ◀ FUNC-dispatch-trip-order · io ▶ FUNC-compute-speed-profile · FUNC-show-waiting-time · schema ▶ SCHEMA-trip-order

4.32 FLOW-trip-request — Trip request

Origin and destination station as the passenger enters them at the terminal or in the app.

io ◀ ACTOR-passenger · io ▶ FUNC-capture-destination · schema ▶ SCHEMA-trip-request

5 Schemata

5.1 SCHEMA-acknowledgement — Acknowledgement schema

Fault reference, person, time, action ordered.

schema ◀ FLOW-acknowledgement

5.2 SCHEMA-action-decision — Action decision schema

Fault reference, decision to continue or to clear, deciding person, time.

schema ◀ FLOW-action-decision

5.3 SCHEMA-alarm — Alarm schema

Fault identifier, severity class, affected cabin or section, time of detection.

schema ◀ FLOW-alarm

5.4 SCHEMA-block-clearance — Block clearance schema

Section identifier, cleared cabin, permitted maximum speed, end of validity.

schema ◀ FLOW-block-clearance

5.5 SCHEMA-block-occupancy — Block occupancy schema

Section identifier, occupancy state, source of the reading, timestamp.

schema ◀ FLOW-block-occupancy

5.6 SCHEMA-brake-request — Brake request schema

Brake type, trigger reason, target deceleration, time of the request.

schema ◀ FLOW-brake-request

5.7 SCHEMA-cabin-assignment — Cabin assignment schema

Cabin identifier, platform, promised waiting time in seconds, end of validity.

schema ◀ FLOW-cabin-assignment

5.8 SCHEMA-cabin-motion — Cabin motion schema

Cabin identifier, direction of travel, target speed, section being traversed, timestamp.

schema ◀ FLOW-cabin-motion

5.9 SCHEMA-cabin-position — Cabin position schema

Cabin identifier, position, source per channel, deviation between the channels, reference to the stopping window, timestamp.

schema ◀ FLOW-cabin-position

5.10 SCHEMA-cabin-state — Cabin state schema

Cabin identifier, position, speed, operating state, door state, timestamp of the reading.

schema ◀ FLOW-cabin-status-report

5.11 SCHEMA-clearance-order — Clearance order schema

Cabin identifier, affected section, ordering person, time, urgency.

schema ◀ FLOW-clearance-order

5.12 SCHEMA-control-center-display — Control center display schema

Display object operational picture or alarm, display priority, acknowledgement state, time of display.

schema ◀ FLOW-control-center-display

5.13 SCHEMA-dispatch-request — Dispatch request schema

Origin and destination station, terminal identifier, accessibility need, time of entry.

schema ◀ FLOW-dispatch-request

5.14 SCHEMA-door-command — Door command schema

Command type open or close, door side, standstill proof as a precondition.

schema ◀ FLOW-door-command

5.15 SCHEMA-door-motion — Door motion schema

Door side, direction of motion, position of the door leaf, closing force, end position, timestamp.

schema ◀ FLOW-door-motion

5.16 SCHEMA-door-release — Door release schema

Door pair identifier, type of release, standstill proof as a precondition, end of validity.

schema ◀ FLOW-door-release

5.17 SCHEMA-door-status — Door status schema

Door state, locking proof, counter of reopening events.

schema ◀ FLOW-door-status

5.18 SCHEMA-doorway-obstruction — Doorway obstruction schema

Door side, obstruction state, detecting sensor, time of detection.

schema ◀ FLOW-doorway-obstruction

5.19 SCHEMA-evacuation-release — Evacuation release schema

Cabin identifier, isolation proof, releasing person, time.

schema ◀ FLOW-evacuation-release

5.20 SCHEMA-incident-situation — Incident situation schema

Location of the cabin, number of passengers, energization state of the section, access route.

schema ◀ FLOW-incident-situation

5.21 SCHEMA-isolation-proof — Isolation proof schema

Section identifier, energization state, securing against re-energization, attesting person, time.

schema ◀ FLOW-isolation-proof

5.22 SCHEMA-line-release — Line release schema

Block sections, release state, releasing person, time.

schema ◀ FLOW-line-release

5.23 SCHEMA-lockout-record — Lockout record schema

Cabin identifier, reason for the lockout, time of the lockout, condition for release, lockout state.

schema ◀ FLOW-lockout-record

5.24 SCHEMA-maintenance-request — Maintenance request schema

Cabin identifier, time window, scope of work, requesting person.

schema ◀ FLOW-maintenance-request

5.25 SCHEMA-operational-picture — Operational picture schema

Cabin list with position and operating state, section occupancy, list of missing reports, time of the reading.

schema ◀ FLOW-operational-picture

5.26 SCHEMA-passenger-announcement — Passenger announcement schema

Message text, urgency, time of output, time of the next announcement.

schema ◀ FLOW-passenger-announcement

5.27 SCHEMA-picture-configuration — Picture configuration schema

Map extent, filters, highlighting thresholds, configuring person.

schema ◀ FLOW-picture-configuration

5.28 SCHEMA-release-confirmation — Release confirmation schema

Cabin identifier, result of the function test, releasing person, time.

schema ◀ FLOW-release-confirmation

5.29 SCHEMA-reopen-command — Reopen command schema

Door side, trigger reason, time of detection, requested opening width.

schema ◀ FLOW-reopen-command

5.30 SCHEMA-service-readiness — Service readiness schema

Destination station, release state, number of cabins in normal operating state, time of the check.

schema ◀ FLOW-service-readiness

5.31 SCHEMA-trip-order — Trip order schema

Cabin identifier, destination station, cleared block sections, time window.

schema ◀ FLOW-trip-order

5.32 SCHEMA-trip-request — Trip request schema

Origin and destination station, timestamp, optional accessibility note.

schema ◀ FLOW-trip-request

6 Architektur

6.1 MOD-cabin-controller — Cabin Controller

On-board computer of a cabin: turns trip orders into speed profiles, monitors speed and positioning, triggers the emergency brake.

allocate ◀ FUNC-compute-speed-profile · FUNC-determine-position · FUNC-report-cabin-state · FUNC-trigger-emergency-brake

6.2 MOD-control-center-dashboard — Control Center Dashboard

The control center workstation: fleet overview, alarm list, acknowledgement, and release of special operating states.

allocate ◀ FUNC-display-alarm · FUNC-grant-evacuation-release · FUNC-present-operational-picture · FUNC-record-acknowledgement

6.3 MOD-door-controller — Door Controller

Safety-related control of the cabin door, including anti-trap protection and locking proof.

allocate ◀ FUNC-detect-obstruction · FUNC-operate-cabin-door · FUNC-prove-door-locking

6.4 MOD-fleet-control-system — Fleet Control System

Central dispatch: knows position and state of every cabin, issues trip orders, maintains the block separation and is the only authority that grants clearance to move.

allocate ◀ FUNC-aggregate-fleet-state · FUNC-check-service-readiness · FUNC-dispatch-trip-order · FUNC-grant-block-clearance · FUNC-lock-out-cabin

6.5 MOD-passenger-app — Passenger App

Mobile application and platform terminal: destination entry, waiting time display, fault information for the passenger.

allocate ◀ FUNC-announce-situation · FUNC-capture-destination · FUNC-show-waiting-time

6.6 MOD-platform-door-system — Platform Screen Door System

Fixed platform screen doors that separate the platform from the guideway and open only in synchrony with a cabin at a standstill.

allocate ◀ FUNC-operate-platform-door · FUNC-synchronize-door-pair

6.7 MOD-wayside-sensors — Wayside Sensor System

Fixed sensors along the guideway: axle counters, obstacle detection, status reports from the switches.

allocate ◀ FUNC-detect-guideway-obstacle · FUNC-prove-isolation · FUNC-report-block-occupancy

7 Cross-cutting Requirements

REQ-mit-alarm-prioritization — Safety alarms are set apart

Mitigation: safety-relevant alarms are held in their own area of the dashboard that cannot be hidden, and each has to be acknowledged individually.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-alarm-missed (performance) · satisfy ◀ — · allocate ▶ —

REQ-mit-anti-trap-selftest — Anti-trap protection with self-test

Mitigation: obstacle detection runs a self-test before every entry into service; a failed self-test locks the cabin out.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-obstacle-detection-selftest (safety) · satisfy ◀ — · allocate ▶ —

REQ-mit-dual-channel-locking — Door locking monitored on two channels

Mitigation: door locking is monitored over two independent channels; any disagreement between the channels brings the cabin to a stop.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-door-unlock-in-motion (safety) · satisfy ◀ — · allocate ▶ —

REQ-mit-information-and-locking — Information before unlocking

Mitigation: the door stays locked without a release from the control center, and passengers receive a situation announcement naming the expected waiting time within 30 seconds.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-emergency-handle-and-information (safety) · satisfy ◀ — · allocate ▶ —

REQ-mit-lockout-survives-restart — Lockout record survives a restart

Mitigation: the lockout record is stored persistently and read back when the fleet control system starts up, before the first dispatch.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-lockout-after-restart (integration) · satisfy ◀ — · allocate ▶ —

REQ-mit-separate-power-for-positioning — Positioning channels on separate power

Mitigation: the two positioning sources are fed from separate power supplies, so that one supply failure cannot take out both channels.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-positioning-power-loss (integration) · satisfy ◀ — · allocate ▶ —

REQ-mit-stopping-window-enforced — Release only inside the stopping window

Mitigation: the door release is granted only if the measured longitudinal position lies inside the stopping window; otherwise the cabin re-positions.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-door-release-outside-window (safety) · satisfy ◀ — · allocate ▶ —

REQ-mit-wayside-block-check — Block occupancy cross-checked from the wayside

Mitigation: block occupancy is determined from wayside sensors in addition to on-board positioning; if the two sources contradict each other, the occupied state prevails.

priority: must · status: n/a · kinds: mitigation

Verification ◀ TEST-risk-rear-end-collision (safety) · satisfy ◀ — · allocate ▶ —

RISK-alarm-missed — Alarm is lost in the alarm list

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-alarm-missed (performance) · satisfy ◀ — · allocate ▶ —

RISK-door-command-during-evacuation — Normal-operation door command arrives during an evacuation

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-door-command-during-evacuation (safety) · satisfy ◀ — · allocate ▶ —

RISK-door-opens-in-motion — Door opens while the cabin is moving

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-door-unlock-in-motion (safety) · satisfy ◀ — · allocate ▶ —

RISK-door-state-diverges — Operational picture and door status report different door states

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-door-state-divergence (integration) · satisfy ◀ — · allocate ▶ —

RISK-energization-state-diverges — Energization state reported to emergency services diverges from the isolation proof

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-energization-state-divergence (safety) · satisfy ◀ — · allocate ▶ —

RISK-locked-out-cabin-dispatched — A locked-out cabin receives a trip order

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-lockout-after-restart (integration) · satisfy ◀ — · allocate ▶ —

RISK-lockout-state-diverges — Cabin operating state and lockout record disagree

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-lockout-state-divergence (integration) · satisfy ◀ — · allocate ▶ —

RISK-passenger-trapped — Passenger is trapped in the door

Failure mode: the door closes onto an obstacle without reopening. Effect: injury to the passenger. Cause: contaminated or misaligned obstacle detection.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-obstacle-detection-selftest (safety) · satisfy ◀ — · allocate ▶ —

RISK-platform-gap — Gap between cabin and platform too wide

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-door-release-outside-window (safety) · satisfy ◀ — · allocate ▶ —

RISK-position-lost — Position of the cabin unknown

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-positioning-power-loss (integration) · satisfy ◀ — · allocate ▶ —

RISK-rear-end-collision — Cabin runs into the cabin ahead

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-rear-end-collision (safety) · satisfy ◀ — · allocate ▶ —

RISK-resume-with-fault-active — Trip resumes while the fault that stopped it is still active

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-resume-with-active-alarm (safety) · satisfy ◀ — · allocate ▶ —

RISK-self-evacuation — Passenger steps unescorted onto the guideway

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-emergency-handle-and-information (safety) · satisfy ◀ — · allocate ▶ —

RISK-stale-readiness-dispatch — Cabin dispatched on a stale operational picture

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-stale-readiness-picture (integration) · satisfy ◀ — · allocate ▶ —

RISK-standstill-proof-stale — Door pair released on a stale standstill proof

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-stale-standstill-proof (safety) · satisfy ◀ — · allocate ▶ —

RISK-states-not-enumerated — No state field in the model has an enumerated value range

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.

priority: must · status: n/a · kinds: risk

Verification ◀ TEST-risk-state-value-enumeration (integration) · satisfy ◀ — · allocate ▶ —

8 Verifikation

8.1 TEST-acknowledgement-immutable — Acknowledgement is recorded immutably

After an acknowledgement, an attempt is made to change or delete the log entry; both must be refused and the attempt itself recorded.

verify ▶ REQ-acknowledgement-attributable

8.2 TEST-alarm-latency — Alarm within two seconds

Timestamps of fault detection and of display on the dashboard are compared over 100 events; the 99th percentile must stay below two seconds.

verify ▶ REQ-alarm-latency

8.3 TEST-announcement-interval — Announcement within 30 seconds

After an emergency stop, the time of the first announcement and the intervals of the following ones are measured; first message below 30 seconds, then at most two minutes apart.

verify ▶ REQ-passenger-information

8.4 TEST-anti-trap-reopen — Reopening within 200 ms

A test body is introduced while the door closes; measured are the time until the door motion reverses and the behaviour after the third attempt.

verify ▶ REQ-anti-trap-protection

8.5 TEST-block-separation-holds — Block separation holds even under misuse

The fleet control system deliberately issues contradictory trip orders; the cabin must brake on its own before the block separation is violated.

verify ▶ REQ-block-separation

8.6 TEST-destination-entry-steps — Destination entry in two steps

The operating path at the terminal is exercised against all eight stations; the operating steps up to the confirmed destination are counted. Failure from the third step onwards.

verify ▶ REQ-destination-entry

8.7 TEST-doors-open-only-together — Doors open only together

Every combination of cabin door, platform screen door and standstill state is exercised; opening without a reported standstill or without the partner door must not occur.

verify ▶ REQ-doors-open-in-sync

8.8 TEST-emergency-handle-without-release — Emergency release handle has no effect without a release

The emergency release handle is pulled on the open guideway without a release from the control center; the door must stay locked and the attempt must be reported.

verify ▶ REQ-no-self-evacuation

8.9 TEST-lockout-under-cabin-shortage — A locked-out cabin stays locked out

Dispatch is observed under an artificially created cabin shortage; the locked-out cabin must not receive a trip order.

verify ▶ REQ-lockout-effective

8.10 TEST-missing-report-shown-as-gap — A missing report is shown as a gap

The status report of one cabin is interrupted; the operational picture must mark the gap instead of continuing to show the last known value.

verify ▶ REQ-picture-complete

8.11 TEST-partial-result-blocks-release — A partially passed test does not release

The function test is completed with one result missing; the re-release must be refused.

verify ▶ REQ-release-after-function-test

8.12 TEST-picture-freshness — Display no older than three seconds

Over one operating cycle the age of every displayed state value is logged; values older than three seconds must be marked as stale.

verify ▶ REQ-picture-freshness

8.13 TEST-release-requires-isolation-proof — Release only with a proven isolation

The exit release is requested while the section is still energized; it must be refused until the isolation proof is available.

verify ▶ REQ-section-de-energized

8.14 TEST-ride-comfort-acceleration — Acceleration below 1.2 m/s2

Longitudinal acceleration is recorded over a complete line profile; peak values in normal operation must not exceed 1.2 meters per second squared.

verify ▶ REQ-ride-comfort

8.15 TEST-risk-alarm-missed — Safety alarm under message load

With 200 uncritical messages per minute, a safety alarm is injected; it must appear in the separated area within two seconds.

verify ▶ REQ-mit-alarm-prioritization · RISK-alarm-missed

8.16 TEST-risk-door-command-during-evacuation — Close command during an escorted exit

A close command is injected while a valid evacuation release is held; the door must stay open and the ignored command must be reported.

verify ▶ REQ-mit-evacuation-overrides-door-command · RISK-door-command-during-evacuation

8.17 TEST-risk-door-release-outside-window — Door release outside the stopping window

The cabin is deliberately stopped outside the stopping window; the door release must not be granted and re-positioning must start.

verify ▶ REQ-mit-stopping-window-enforced · RISK-platform-gap

8.18 TEST-risk-door-state-divergence — Contradictory door states in the operational picture

The cabin state report and the door status are fed with opposing door states; the operational picture must show the deviation and no release may be granted from the indicative copy.

verify ▶ REQ-mit-door-state-single-source · RISK-door-state-diverges

8.19 TEST-risk-door-unlock-in-motion — Door unlocking while in motion

An unlock command is injected while the cabin is moving and one channel of the locking monitor is disturbed; the door must stay locked and the cabin must stop.

verify ▶ REQ-mit-dual-channel-locking · RISK-door-opens-in-motion

8.20 TEST-risk-emergency-handle-and-information — Emergency release handle and information during an emergency stop

Emergency stop on the open guideway followed by pulling the emergency release handle; tested are that the door stays locked and when the first announcement is made.

verify ▶ REQ-mit-information-and-locking · RISK-self-evacuation

8.21 TEST-risk-energization-state-divergence — Incident situation without a valid isolation proof

An incident situation is produced while the isolation proof is missing, expired, or refers to another section; the reported energization state must read unknown and the release must not be granted.

verify ▶ REQ-mit-isolation-proof-reference · RISK-energization-state-diverges

8.22 TEST-risk-lockout-after-restart — Lockout record after a restart

The fleet control system is restarted while a cabin is locked out; after startup that cabin must not receive a trip order.

verify ▶ REQ-mit-lockout-survives-restart · RISK-locked-out-cabin-dispatched

8.23 TEST-risk-lockout-state-divergence — Operating state against a standing lockout

A cabin reports a normal operating state while its lockout record stands; the readiness check must not count it and the divergence must appear in the operational picture.

verify ▶ REQ-mit-operating-state-from-lockout · RISK-lockout-state-diverges

8.24 TEST-risk-obstacle-detection-selftest — Self-test of the obstacle detection

The obstacle detection is deliberately misaligned before entry into service; the self-test must fail and the cabin must be locked out.

verify ▶ REQ-mit-anti-trap-selftest · RISK-passenger-trapped

8.25 TEST-risk-positioning-power-loss — Power failure of one positioning channel

The power supply of one positioning channel is switched off; the second channel must keep working and the failure must be reported.

verify ▶ REQ-mit-separate-power-for-positioning · RISK-position-lost

8.26 TEST-risk-rear-end-collision — Collision protection under contradictory positioning

On-board positioning and wayside sensors are deliberately brought into contradiction; the following cabin must brake and report the contradiction.

verify ▶ REQ-mit-wayside-block-check · RISK-rear-end-collision

8.27 TEST-risk-resume-with-active-alarm — Continue decision on an alarm still standing

A continue decision is issued for an alarm that is still active; the speed profile must stay at zero and the refusal must reach the control center.

verify ▶ REQ-mit-decision-references-alarm · RISK-resume-with-fault-active

8.28 TEST-risk-stale-readiness-picture — Readiness check with an aged operational picture

The readiness check is offered a picture older than three seconds while a station is out of service; the answer must be readiness unknown and no trip order may be issued.

verify ▶ REQ-mit-readiness-freshness-check · RISK-stale-readiness-dispatch

8.29 TEST-risk-stale-standstill-proof — Door release on an expired standstill proof

A door release is requested with a standstill proof older than its validity, and with a door command carrying a newer proof; the release must be refused and the divergence reported.

verify ▶ REQ-mit-single-standstill-proof · RISK-standstill-proof-stale

8.30 TEST-risk-state-value-enumeration — Unknown value in a state field

Every schema that carries a state field is fed a value outside its enumeration; the consuming function must reject it and report it, and must not fall back on a default.

verify ▶ REQ-mit-enumerated-state-values · RISK-states-not-enumerated

8.31 TEST-safe-state-without-control-center — Safe state without the control center

Safety-relevant faults are injected while the link to the control center is cut; the cabin must still stop and keep the doors locked.

verify ▶ REQ-safe-state-unattended

8.32 TEST-scenario-door-cycle — Scenario test door cycle

Complete door cycle with the cabin at a standstill; tested are standstill and position as the entry condition and the locking proof of both doors as the result.

verify ▶ REQ-post-doors-locked · REQ-pre-cabin-at-standstill

8.33 TEST-scenario-evacuation — Scenario test evacuation

Exercise on the guideway with emergency responders; tested are the confirmed immobilization as the entry condition and the reported clearance as the result.

verify ▶ REQ-post-cabin-cleared · REQ-pre-cabin-immobilized

8.34 TEST-scenario-fault-handling — Scenario test fault handling

Injected fault through to acknowledgement; tested are the classification as the entry condition and the recorded decision as the result.

verify ▶ REQ-post-situation-decided · REQ-pre-fault-classified

8.35 TEST-scenario-line-run — Scenario test line run

Trip over the full line; tested are the valid trip order as the entry condition and the stop inside the target window as the result.

verify ▶ REQ-post-inside-target-window · REQ-pre-valid-trip-order

8.36 TEST-scenario-maintenance-window — Scenario test maintenance window

Maintenance run in the depot; tested are the secured cabin as the entry condition and the restored dispatchability as the result.

verify ▶ REQ-post-cabin-dispatchable · REQ-pre-cabin-in-depot

8.37 TEST-scenario-operational-picture — Scenario test operational picture

Operating cycle with status reports running; tested are incoming reports as the entry condition and the highlighting of every deviation as the result.

verify ▶ REQ-post-deviation-visible · REQ-pre-status-reports-running

8.38 TEST-scenario-trip-request — Scenario test trip request

Run from destination entry to the bound cabin; tested are service readiness as the entry condition and the unambiguous cabin binding as the result.

verify ▶ REQ-post-cabin-assigned · REQ-pre-line-in-service

8.39 TEST-single-channel-position-loss — Behaviour when one positioning source fails

One of the two positioning sources is switched off during operation; the cabin must continue on sight, report the failure and stop at the next station.

verify ▶ REQ-dual-channel-positioning

8.40 TEST-stopping-accuracy — Longitudinal deviation below 50 mm

Longitudinal deviation is measured over 200 stops per station; no single value may exceed 50 millimeters.

verify ▶ REQ-stopping-accuracy

8.41 TEST-waiting-time-promise — Promised waiting time in normal operation

Promised against actual waiting time is compared over 500 simulated trip requests; the compliance rate must be at least 95 percent.

verify ▶ REQ-waiting-time-promise

9 Traceability summary

64 REQ · 64 verified · 0 without a verifying TEST (R-01).