A system architecture model can look complete and still tell you almost nothing about whether the thing will work. You have blocks, ports, requirements, and clean connections. What you don't have is behavior. Does the control loop stay stable when the sensor lags? Does the power budget hold when three subsystems draw current at once? A static SysML model can't answer that, and for years the answer arrived late, after the domain teams had built their own simulations in their own tools and someone tried to reconcile the results by hand.
Co-simulation is the attempt to close that gap without forcing everyone onto one tool. The idea is straightforward: let each discipline keep its own simulator, wrap each piece in a standard interface, and run them together against the architecture the systems team already defined. Two standards do most of the heavy lifting here, FMI and SSP, and recent work has focused on connecting them directly to MBSE so the system model becomes the thing you actually execute.
What co-simulation buys a systems team
The practical win is timing. If you can stand up a rough executable version of the architecture while it's still being argued over, you catch the bad assumptions when they're cheap to fix. A 2024 INCOSE International Symposium paper by Cederbladh and colleagues made exactly this case, showing how SysML architecture views can be extended with co-simulation using FMI and SSP to validate design decisions earlier than a traditional flow allows.
The second win is integration without consolidation. Co-simulation lets a logical architecture and a physical architecture, or a controls model and a plant model, run side by side even though they were built at different levels of abstraction in different tools. Nobody has to abandon their solver. The system model supplies the structure: which components exist, how their interfaces connect, and what each one is supposed to do. The simulators supply the dynamics.
FMI and SSP, briefly
The Functional Mock-up Interface (FMI) is a tool-independent standard for packaging a simulation component as a Functional Mock-up Unit, or FMU. An FMU is a self-contained black box with defined inputs, outputs, and parameters. FMI defines three ways these units interact: Model Exchange, where a central solver integrates the FMUs together; Co-Simulation, where each FMU carries its own solver and steps independently; and Scheduled Execution, aimed at real-time scenarios. For systems work, the Co-Simulation mode is usually the relevant one, because it lets components from genuinely different tools advance on their own and exchange data at defined points.
FMI handles one component at a time. To describe a whole system of connected FMUs, you need its companion standard, System Structure and Parameterization (SSP). SSP defines an open file format for the architecture: the components, their interfaces, how they're wired together, and the parameter values and variants that configure them. The split is clean. FMI exchanges individual simulation pieces, and SSP exchanges the complete assembled system, including its parameterization, so a whole co-simulation setup can move between tools rather than being rebuilt by hand. Cross-company efforts, including open-source ADAS work, have been built on FMI 3.0 and SSP, which signals these are the versions current digital engineering toolchains are converging on.
Wiring a SysML model into a co-simulation
The connection between the architecture and the executable model follows a repeatable shape. You start from the system model, identify the components and interfaces that need behavior, get each one as an FMU from whatever tool owns it, assemble those FMUs into an SSP description that mirrors the architecture, and run the co-simulation. Results flow back as evidence against the requirements the model already holds.
The reason this matters for MBSE specifically is the last step. When the architecture and the simulation share the same interface definitions, a co-simulation result isn't a stray number in someone's report. It maps back to a named element and the requirement it was meant to satisfy. The verification status becomes a property of the model instead of a line in a disconnected spreadsheet, which is the whole point of doing systems engineering with models in the first place.
Where the tools sit
No single product owns this pipeline end to end, which is part of why the standards exist. On the architecture side, tools like Dassault Systèmes Cameo Systems Modeler, Eclipse Capella, and Dalus let teams define system structure, interfaces, and requirements that a co-simulation can be built against. On the simulation side, environments such as MATLAB/Simulink, Modelica tools like Dymola and OpenModelica, and dedicated co-simulation masters export and orchestrate FMUs. The handoff between the two worlds is exactly where FMI and SSP earn their keep, because they keep the architecture tool and the solver from having to know anything about each other's internals.
That separation is a feature, but it also means you're maintaining a chain. The architecture has to stay in sync with the SSP description, the SSP has to reference FMUs that are current, and each FMU has to match what its source tool actually produces. The standards make the chain possible. They don't keep it consistent for you.
What co-simulation won't solve
It won't rescue a vague architecture. If interfaces are loosely defined or the requirements don't say what "correct" looks like, a co-simulation will run and produce confident garbage. The model has to be precise enough to wire up before any of this pays off.
It also won't make your FMUs trustworthy. An FMU is only as good as the model inside it, and co-simulation gives you no special insight into whether a given component's behavior was validated. Numerical issues compound too. When independent solvers exchange data at fixed communication steps, step size and coupling can introduce errors that have nothing to do with the physics and everything to do with how the co-simulation was configured. Those failures are subtle and easy to miss if you treat the green run as proof.
And it's not free to stand up. Wrapping legacy models as FMUs, agreeing on interface conventions, and maintaining the SSP assembly is real work. For a small system with one or two disciplines, a single integrated model may be the saner choice. Co-simulation earns its overhead when you have several teams, several tools, and no realistic path to merging them.
Bottom line
MBSE co-simulation is how a system model stops being a picture and starts being something you can run. FMI packages each discipline's behavior as an interchangeable unit, SSP describes how those units assemble into the architecture, and the link back to the SysML model turns simulation runs into traceable verification evidence. The payoff is catching bad assumptions early, while they're still cheap. The cost is a toolchain you have to keep coherent and a healthy skepticism about what a clean run actually proves. For teams spread across tools and disciplines, that's usually a trade worth making.