Scenario context
Platform screen doors (PSD) sit at the intersection of rolling stock, station civil works, and environmental control. This industry reference scenario imagines a typical metro platform door system that must satisfy door open/close timing, gap detection, anti-pinch, emergency release, fire linkage, and fault reporting. MagicGrid separates problem, solution, and implementation domains so the knowledge base can answer: what matters on this diagram right now?
Rail operators rarely publish detailed SysML models publicly, yet integrators still need repeatable structure: requirements that trace to behaviors, behaviors that expose interfaces, and parameters that feed verification. The reference scenario encodes that rhythm without naming any real line, door vendor, or contract.
Modeling focus
| View | Engineering focus | KB slice |
|---|---|---|
| Requirements | Door timing, gap and anti-pinch thresholds | Standard clauses + peer scenario metrics |
| Behavior | Door state machine, signaling interactions | Sequence templates + exception branches |
| Structure | Leaf, drive, controller, sensors | Naming conventions + interface profiles |
| Parameters | Response time, redundancy, diagnostic codes | Verification cases and trace links |
Stakeholders and concerns
Systems engineers care about end-to-end timing budgets and failure modes. Safety reviewers care about independent monitoring and manual override paths. Maintainability teams care about diagnostic visibility and replaceable modules. MagicGrid helps keep these concerns in the right domain instead of collapsing them into one overloaded package diagram.
How AI4MBSE uses this scenario
An engineer states the session goal: build the PSD door-close interlock sequence for this sprint. AI4MBSE retrieves MagicGrid behavior slices and project naming rules from the engineering knowledge base, proposes checkable candidates, and writes back only after human confirmation in MagicDraw, Cameo, Capella, or SysON hosts. The assistant follows one diagram at a time — human-in-the-loop write-back — rather than pretending to generate an entire station model in one shot.
Verification hooks
The reference ties parameters to test cases: door re-open on obstacle, loss of signal feedback, and emergency platform evacuation. Each hook becomes a trace edge the KB can surface when the user works on a given diagram type, which is the core of MBSE RAG versus generic chat retrieval.
MBSE RAG value in this scenario
Industry reference scenarios exist so the engineering knowledge base can store reusable slices — requirements phrasing, allowed diagram sequences, naming prefixes, and verification hooks — without exposing any real customer program. When AI4MBSE runs a one-diagram-at-a-time session, MBSE RAG should pull only the fragments that belong to the active methodology and view. That keeps conversational modeling honest: candidates stay checkable, human-in-the-loop write-back stays authoritative, and reviewers still own baselines under configuration management aligned with INCOSE practice and OMG SysML / SysML v2 vocabulary.