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).