Architecture
MBSE without the round-trip: SysML on the same thread as requirements
Why model-based systems engineering breaks down when SysML lives in one tool and requirements in another — and what “native MBSE on the thread” should mean for regulated programs.
Model-based systems engineering (MBSE) puts architecture in a formal model — often SysML — instead of only in documents. The round-trip problem appears when that model lives in Cameo, MagicDraw, or Rhapsody while requirements and tests live in DOORS, Jama, or another ALM. Every night (or every milestone) someone exports, imports, and reconciles. Drift is guaranteed; audits become archaeology.
“MBSE without the round-trip” means SysML elements are first-class records in the same database as requirements and tests, with satisfy/verify links that do not depend on a file exchange. That is the bet behind Architecture in traceunified.
Two jobs that get conflated
| Job | Tooling center of gravity |
|---|---|
| Deep simulation, formal analysis, code gen | Specialist MBSE (Cameo, Rhapsody, …) |
| Governed architecture on the assurance thread | System of record with native SysML |
Many programs need both. Hybrid is rational: keep specialist tools for fidelity work; put the regulated architecture baseline on the thread. See Cameo and Rhapsody alternatives and Migrate from Cameo or Rhapsody (including XMI import into traceunified).
What breaks in the round-trip
- Identity drift — the same block has different IDs after each exchange.
- Stale satisfy/verify — requirements changed; the model link was not regenerated.
- Evidence gaps — the audit asks for the model as approved; you have a file share of versions.
- Suspect blindness — changing a requirement cannot flag model elements if they are not the same graph.
What “native on the thread” should give you
- SysML elements versioned like requirements
- Direct links to requirements and tests (no ReqIF ping-pong for day-to-day trace)
- Participation in baselines, reviews, and Part 11 signatures when you enable them
- Suspect / impact analysis across model and specification
- Import path for existing models (XMI) so you are not redrawing the system from scratch
Evaluation questions
- Are blocks and requirements in one database, or connected by sync jobs?
- Show a block change that flags linked requirements and tests as suspect.
- Which diagram types are native, and how are they baselined?
- Can you import XMI from our current tool and map types?
- What are you not replacing (simulation, code gen)?
Related reading
See traceability work as one connected system.
Requirements, architecture, tests, risk, and SBOM on a single thread — audit-ready when you need it.