Scenario context
A portable infusion pump control unit must guarantee dose accuracy, bubble detection, run-dry alarms, battery behavior, and fail-safe states. OOSEM supports tracing from clinical usage scenarios down to software units and verification cases — the kind of rigor regulators expect and conversational AI must not shortcut.
This industry reference scenario excludes real registration numbers, hospital programs, or device trade names. It still captures authentic engineering pressure: ml/hr accuracy across temperature drift, sensor saturation during micro-bubbles, and alarm prioritization when multiple faults coincide.
Clinical to software chain
Nurses experience occlusion, air-in-line, and end-of-infusion situations. Systems engineers translate them into detectable events, alarm latencies, and UI prompts. OOSEM keeps clinical language attached to engineering artifacts so reviews do not devolve into disconnected software tickets.
Traceability example
- Clinical scenario → therapy requirement → software safety requirement
- Algorithm module → unit test → risk control link
AI4MBSE boundaries
AI4MBSE may accelerate drafting and cross-checking candidates against the KB, but human confirmation before write-back is mandatory; the assistant does not replace clinical or regulatory review. MBSE RAG surfaces known hazard mitigations and naming conventions instead of hallucinating new ones.
Verification emphasis
Parameter tables tie flow-rate error bands to bench tests and simulated bubble sizes. When the user edits a requirement diagram, retrieval emphasizes verification hooks — illustrating how Ark targets engineering assistants, not generic medical chatbots.
Risk and design control
OOSEM encourages explicit links between hazards, mitigations, and verification evidence. In this reference, a run-dry alarm is not an isolated software ticket — it connects to clinical harm scenarios, hardware sensor placement, and factory calibration records. That is the level of structure MBSE RAG must preserve when AI4MBSE proposes edits: no silent shortcutting of risk traces.
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.