Content and any diagrams are from a local test environment with simulated data — not a real enterprise engineering project. Technical illustration only. Interface labels such as Ark are experiment names only.
Scenario context
An intrinsically safe personnel positioning base station must operate continuously in explosive atmospheres: flameproof enclosures, strict power budgets, positioning accuracy, concurrent tag capacity, and auditable event logs. OOSEM aligns operational and engineering views so compliance clauses become verifiable model elements rather than orphaned document bullets.
This simulated experiment does not name any real mine, certification file, or vendor SKU. It encodes the kind of cross-disciplinary tension systems engineers face daily: radio performance vs. intrinsic safety limits, maintenance access vs. sealed enclosures, and real-time alarms vs. deterministic power failover.
Problem and solution domains
Operational stakeholders phrase needs as coverage, latency, and muster accuracy during emergencies. Engineering teams translate them into antenna patterns, location algorithms, battery chemistry, and fault codes. OOSEM keeps operational scenarios visible while structural and parametric decisions remain traceable — a pattern the MBSE knowledge base mirrors in retrievable slices.
Modeling and KB slices
| Area | Examples | Retrieval trigger |
|---|---|---|
| Requirements | IS parameters, positioning error, battery life | Requirement diagram session |
| Structure | RF front-end, power, barrier, enclosure | IBD / block definition |
| Behavior | Registration, heartbeat, alarm reporting | Sequence / state machine |
| Verification | Type-test items, trace matrices | Test case allocation view |
Working with AI4MBSE
When an engineer opens a session on alarm reporting behavior, AI4MBSE should not invent generic IoT patterns. MBSE RAG pulls OOSEM-aligned fragments from the engineering knowledge base — for example allowable latency classes, audit fields, and naming prefixes — then proposes candidates the reviewer can check before write-back. One diagram at a time preserves reviewability in regulated environments.
Governance and audit
Regulators and internal quality teams ask for evidence chains: which requirement drove which test, which software build sat on which hardware revision. The simulated experiment includes placeholder trace edges illustrating how conversational modeling must respect those edges instead of shortcutting them for fluent prose.
Why this scenario matters for MBSE RAG
Compliance programs punish hallucinated parameters. By encoding OOSEM views and verification hooks as reusable KB slices, the experiment explores how assistants can stay inside allowable ranges when someone asks for the next SysML diagram. That discipline — retrieval before generation, confirmation before write-back — is what separates knowledge-constrained modeling sketches from generic chat.