Walk onto a factory floor or a flight test ramp and you'll often find two "models" of the same system that have never spoken to each other. One is the SysML architecture the systems team built during design, sitting in a modeling tool. The other is a live simulation fed by sensor data, running in an operations dashboard, that someone in a completely different group calls the "digital twin." Both claim to represent the product. Neither knows the other exists. Closing that gap is what the current interest in pairing MBSE with digital twins is really about, and it's messier than the marketing suggests.
Two things people call the same model
MBSE and digital twins get lumped together because both are "the model of the system," but they answer different questions.
An MBSE model is authoritative and prescriptive. It says what the system is supposed to be: its requirements, its architecture, its interfaces, the rationale behind each decision. It's built during design and it defines intent. A digital twin is descriptive and instance-specific. It mirrors one physical asset as it actually exists and behaves right now, updated from telemetry, and it's used to monitor, predict, and diagnose that specific unit in the field.
The confusion is understandable, because a good digital twin needs exactly the structure an MBSE model already contains. Where does this sensor sit in the architecture? What was this subsystem's designed operating range? What requirement does this measured value trace back to? Those answers live in the system model. When the twin can't reach them, engineers rebuild a thinner version of the same structure by hand, and now there are two descriptions of one system that will drift apart the moment either one changes.
A categorization that actually helps
A 2025 paper in Applied Sciences, "A Categorization of Digital Twin and Model-Based System Engineering Interactions," is useful here because it stops treating "MBSE plus digital twin" as one undifferentiated idea. It splits the relationship into two broad kinds: digital twins that are built from MBSE models, and digital twins that consume MBSE models as one input among several. It also separates the case where the physical thing is still being designed from the case where it's already operating. Those distinctions matter, because the integration you need is completely different depending on which quadrant you're in.
If the system is still in design, the "twin" is really a high-fidelity virtual prototype. The system model feeds simulation so you can test behavior before anything is built. If the system is already operating, the twin is fed by real telemetry from a specific unit, and the interesting direction of information flow reverses: data from the field wants to flow back toward the model.
The digital thread is the plumbing that makes any of this possible. It's the set of persistent links that connect a requirement to an architecture element to a simulation to a measured signal, so that a number coming off a sensor can be traced all the way back to the design decision it validates or violates.
Closing the loop from operations back to the model
The part teams underestimate is the feedback direction. Seeding a twin from a design model is the easy half. The hard, valuable half is letting what you learn in operation change your understanding of the design.
A fielded fleet generates evidence the design phase could only assume. A component runs hotter than its analysis predicted. A duty cycle turns out to be twice what the requirement baselined. An interface that looked fine in the model shows timing jitter under real load. In a document-centric world that knowledge stays trapped in maintenance logs and tribal memory. With a live link between the twin and the system model, those observations can update parameter estimates, flag requirements that no longer match reality, and inform the next block upgrade with measured numbers instead of guesses.
This is where the "authoritative source of truth" idea earns its keep. If operational data can flow back and quietly overwrite the model, you've lost the record of intent. If it flows back as a proposed change that a human reviews against the baseline, you get a system model that learns without lying about where it came from. Getting that governance right is harder than any of the data-plumbing.
Where the tooling sits today
No single tool spans the whole chain from requirements to operating telemetry, so real deployments stitch several together, and the seams are where projects stall.
On the MBSE side, the job is to hold the authoritative architecture and expose it as data other systems can query. Established modelers such as Dassault Systemes Cameo Systems Modeler, open-source environments like Eclipse Capella, and SysML v2-native tools including Dalus all produce system models, and they differ in how readily those models can be reached programmatically by a downstream twin. On the twin and simulation side you have the analysis and IoT platforms that ingest telemetry and run the physics. Between them sits the integration layer, usually a mix of the SysML v2 API, FMI or SSP for co-simulation, and whatever data bus carries the sensor stream. The SysML v2 API matters here for the same reason it matters everywhere else: a twin can pull the model as structured data instead of scraping a diagram.
The categorization above is worth keeping in mind when you evaluate tools, because a vendor demo almost always shows the easy design-time direction. Ask what happens when a hundred fielded units start sending data back.
What it won't solve
Connecting an MBSE model to a digital twin is an integration discipline, not a source of free insight, and a few limits are worth stating plainly.
It doesn't create fidelity you didn't model. A twin is only as good as the physics and the parameters behind it. Linking it to a system model that was never validated against test data just gives you a well-connected wrong answer.
It doesn't fix bad traceability. If your requirements aren't linked to architecture inside the model, there's nothing for a sensor value to trace back to, and the twin becomes a dashboard with no engineering meaning underneath it.
It adds real operational cost. A live twin means data pipelines, storage, model synchronization, and version control across two representations that both change over time. That's an ongoing engineering commitment, not a one-time integration.
And it raises governance questions most teams haven't answered. Who signs off when the field data disagrees with the model? What's the authoritative version when the twin and the model conflict? Without clear rules, the two representations drift and people quietly stop trusting both.
Bottom line
The value in pairing MBSE with a digital twin isn't the twin itself, it's the loop. A system model gives the twin the structure, requirements, and rationale it would otherwise have to reinvent, and the twin gives the model something design never has: evidence of how the real thing actually behaves. Get the digital thread and the governance right and you get a system description that improves as the fleet ages. Skip them and you get two expensive models of the same system that slowly stop agreeing. Start by asking which of the four cases you're actually in, design-time or operational, model-driven or model-consuming, because the integration you build depends entirely on the answer.