FMI FMU Co-Simulation for Digital Twins: Model Exchange vs Co-Simulation and When to Use Each

Last Updated: October 2026

A digital twin of a real machine is almost never one model. The battery comes from an electrochemistry tool, the cooling loop from a Modelica library, the controller from generated C code, and the mechanical structure from yet another vendor. Each tool has its own solver, its own notion of time and its own licence. FMI FMU co-simulation is the standard answer to how those pieces run together without anyone rewriting anyone else’s model, and the answer is subtler than “export an FMU and click run”.

The subtlety sits in one early choice. A Functional Mock-up Unit can ship as Model Exchange, exposing raw equations for your solver, or as Co-Simulation, shipping its own solver and exposing only a step function. That decision changes accuracy, stability, intellectual property exposure and how a twin can be kept in sync with a live asset. Much of the advice online gets it backwards, including an earlier version of this article.

This guide rewrites that treatment for October 2026. It covers the two modes at the interface level, the FMI 3.0 additions, the master algorithms that make coupled simulation stable, SSP system descriptions, and a runnable Python master. The thesis: pick the mode by who owns the numerical integration risk, and treat the master algorithm as the real product.

What this covers: FMI versions and status, Model Exchange versus Co-Simulation, FMU anatomy, clocks and events, Jacobi and Gauss-Seidel coupling, step-size control with rollback, SSP and DCP, tooling, runnable code, digital twin integration and failure modes.

Context and Background

The Functional Mock-up Interface is a tool-independent standard maintained by the Modelica Association. It began in the MODELISAR project and reached FMI 1.0 around 2010. FMI 2.0 followed in 2014 and became the widely supported baseline across commercial and open tools. FMI 3.0 was announced by the Modelica Association in May 2022 and added clocks, ports, new data types and features aimed at virtual electronic control units. FMI 3.0.1 appeared in October 2023, and on 27 November 2024 the project released FMI 3.0.2 and FMI 2.0.5, both described as maintenance releases with clarifications and bug fixes and no new features. An FMU built to 3.0.2 is valid under 3.0 and 3.0.1, and the reverse also holds. These facts come from the project’s own FMI release notes.

Correction to the previous edition of this post: it said FMI 3.0 was “finalized in 2023”. The first 3.0 release dates from 2022, with 3.0.1 in 2023. We also described Model Exchange as the better choice for tight coupling in single-vendor pipelines; that is defensible, but it understated how often Co-Simulation is the only practical option, which we correct below.

Around FMI sit companion standards. The System Structure and Parameterization standard, SSP, describes how many FMUs are connected and parameterized. SSP 2.0 was released in December 2024 and, per the Modelica Association, adds architecture exchange, support for FMI 3.0 features including virtual ECUs, Modelica components with causal and acausal connections, richer metadata and signatures, and more efficient parameter updates for model calibration. The Distributed Co-Simulation Protocol, DCP, is a separate Modelica Association project for real-time and distributed coupling over networks. Details on both are below.

Why does this matter for twins? A twin has to run beside the asset, take live inputs, and be recalibrated as the asset ages. That demands components that can be swapped, parameter sets that can be versioned, and a master that behaves predictably when a model misbehaves. Those are the properties FMI, SSP and a well-built master deliver. Related architecture context lives in our asset administration shell reference architecture and in the comparison of AAS, DTDL and OPC UA information models, because an FMU describes behaviour while those models describe identity and structure.

The primary reference for everything below is the FMI 3.0 specification on fmi-standard.org. Where this article states interface function names, they are taken from that specification; where it gives numbers, they are worked illustrations and labelled as such.

Model Exchange vs Co-Simulation: The Architecture Decision

Direct answer. In Model Exchange the FMU provides the model equations, derivatives and event indicators, and the importing tool supplies the numerical integrator. In Co-Simulation the FMU contains its own solver and the master only sets inputs, calls a step function and reads outputs. Model Exchange gives the importer control and accuracy. Co-Simulation gives encapsulation and solver freedom at the price of coupling error.

Figure 1: In Model Exchange the master owns the solver and sees continuous dynamics. In Co-Simulation each FMU owns a solver and the master sees only values at communication points.

Figure 1 compresses a large difference into two loops. On the left, the master integrates one combined system of equations. Because it holds all state, it can pick a single variable-step solver, detect events through event indicators, and treat the coupled system as one problem. On the right, the master never sees internal states. Each FMU advances alone between communication points, and the interaction between FMUs is approximated by holding or extrapolating inputs across each interval.

What Model Exchange actually exposes

A Model Exchange FMU is a function evaluator for a hybrid system. Conceptually it represents continuous-time dynamics, with states x, derivatives, inputs u and outputs y, plus discrete behaviour that switches at events. The importer calls functions to set time, set continuous states, set inputs, get derivatives and get event indicators. In FMI 3.0 these are the familiar calls such as fmi3SetTime, fmi3SetContinuousStates, fmi3GetContinuousStateDerivatives and fmi3GetEventIndicators.

The importer alternates between continuous-time mode and event mode. When an event indicator changes sign, the importer locates the event, enters event mode with fmi3EnterEventMode, lets the FMU update discrete states through fmi3UpdateDiscreteStates, and returns to continuous-time mode. After every accepted integrator step it calls fmi3CompletedIntegratorStep. This is the contract that lets one solver handle many models, and also the reason Model Exchange needs a capable importer: it must implement event location, state reinitialisation and step control correctly.

What Co-Simulation actually exposes

A Co-Simulation FMU wraps equations and solver together. The master calls fmi3DoStep with the current communication point and a communication step size, and the FMU integrates internally from the former to the latter, taking as many internal steps as it needs. Between calls the master reads and writes variables. In FMI 3.0 the call also returns flags such as whether event handling is needed, whether the FMU wants to terminate, and whether it returned early, with the last successful time reported.

The important consequence is the one most summaries miss. An FMU’s internal accuracy no longer protects the coupled result. Each FMU is individually integrated to its own tolerance, yet the interaction between FMUs is only as good as the coupling scheme. A perfectly accurate battery model and a perfectly accurate thermal model can still produce an inaccurate or unstable pair if the communication step is too large for the energy they exchange.

Decision rule

Choose the mode by who owns the integration risk, not by habit:

Pick Model Exchange when one tool will own the whole assembly, when models are non-stiff or you control the solver choice, when you need fine event timing, or when you must linearize or optimise around a trajectory. You absorb the risk, and you gain full visibility.
Pick Co-Simulation when a vendor ships a solver tuned to its model, when intellectual property demands a binary black box, when models are stiff in different ways, or when subsystems run on different time scales. The vendor absorbs solver risk and you absorb coupling risk.
Support both when you build a platform. Most FMU suppliers publish one or the other, rarely both, and a twin platform that rejects half of them is a weak platform. Many FMUs also include both interfaces in one file, which modelDescription.xml advertises.

A frequent myth is that Co-Simulation is “less accurate” than Model Exchange. It is better to say it moves error from the integrator into the coupling. With small enough communication steps, higher-order extrapolation of inputs, and an iterating master, the coupling error shrinks to the point where it no longer dominates.

Anatomy of an FMU and What FMI 3.0 Added

Direct answer. An FMU is a zip archive with a modelDescription.xml file describing variables, types, causality, variability and capabilities, a binaries directory with a compiled library per platform, optional sources, and optional resources and documentation. The XML is the contract; a master can validate and wire models from it without loading any binary.

Figure 2: An SSP archive references FMUs and wires their variables, while each FMU exposes its contract through modelDescription.xml.

The figure shows two layers. The lower layer is the FMU, a self-contained component. The upper layer is the SSP, a description of how components connect. Keeping them separate is what allows the same FMU to appear in different assemblies and keeps parameter sets versionable.

The modelDescription.xml contract

Every variable carries a name, a value reference (an integer handle used in calls), a type, a causality and a variability. Causality tells the master how the variable may be used: parameter, calculated parameter, input, output, local or independent. Variability describes how often it changes: constant, fixed, tunable, discrete or continuous. A master can reject illegal connections before running anything, for example an output wired to a parameter that must not change after initialisation.

The file also declares capabilities. In FMI 2.0 these include canGetAndSetFMUstate, canSerializeFMUstate, providesDirectionalDerivative, canHandleVariableCommunicationStepSize, canInterpolateInputs and maxOutputDerivativeOrder. These flags are not decoration. They decide which master algorithms are legal. An FMU that cannot get and set its state cannot be rolled back, so a master must either use a fixed step with a safety margin or reject the model for adaptive stepping. An FMU without directional derivatives cannot support Newton-style loop solving.

FMI 3.0 additions that matter for twins

The Modelica Association summary of FMI 3.0 names clocks, ports, new data types, advanced co-simulation features, virtual ECU support, layered standards, and more efficient parameter updates for calibrating models. Reading the specification gives concrete shape to these:

Clocks make discrete events first-class. FMI 2.0 forced controllers to be modelled by sampled variables and time events or state events. A clock can be periodic, or triggered from an input, and it ties discrete updates to explicit activations. For a sampled controller running at 100 Hz inside a plant model, the master knows exactly when that logic updates instead of discovering it through zero crossings.
Arrays and richer types. FMI 3.0 adds multi-dimensional arrays and more numeric types such as sized integers and 32-bit floats. Sensor frames, lookup tables and state vectors no longer need to be flattened into hundreds of scalar variables.
Binary variables carry opaque byte payloads. A bus frame, a serialized message or a compressed buffer can cross an FMU boundary without being broken into numbers. The layout is the vendor’s responsibility, and there is no unit or type checking inside the blob.
Terminals and ports group variables semantically in terminalsAndIcons.xml, so a tool can offer a connection between two physical connectors rather than six individual signals. This is the basis for graphical composition and automatic checks. Labelled limitation: terminal semantics are only as strong as the vendor’s naming, and cross-vendor automatic matching is not guaranteed.
Intermediate update and early return let a Co-Simulation FMU communicate during a long step. The master can supply updated inputs or accept an early return when an event happens, which reduces the delay in event-driven systems.
Scheduled Execution is a third interface type aimed at running model partitions under an external scheduler, relevant to virtual ECUs.
Layered standards allow other standards’ artefacts, for example network descriptions or manifests, to travel inside the FMU container.

For a twin, the practical headline is that FMI 3.0 narrows the distance between a simulation component and a control software component. A virtual ECU packaged as an FMU can be exercised with the same master that runs the plant.

Master Algorithms: Making Coupled Simulation Stable

Direct answer. A co-simulation master repeats four actions per communication step: set inputs, advance each FMU, read outputs, and decide whether to accept the step. The order of those actions defines the scheme. Jacobi advances all FMUs from the same inputs in parallel, Gauss-Seidel advances them in sequence using fresh outputs, and iterative variants repeat the step until coupled variables converge. Error and stability both depend on the communication step.

Jacobi versus Gauss-Seidel

In a Jacobi scheme every FMU receives inputs computed at the previous communication point and then steps forward. Because the FMUs do not depend on each other within a step, they can run in parallel on different cores or machines. The cost is a full step of delay on every coupling.

In a Gauss-Seidel scheme the FMUs step in a chosen order. The first receives old inputs, the second receives the first’s new outputs, and so on. The delay on forward couplings disappears, and information propagates faster, but the steps are serial and the order matters. Choosing the order well, by following the dominant physical causality, is a real engineering decision. A thermal model should usually run after the power-dissipation model it depends on, not before.

Both schemes treat inputs as constants across the interval unless told otherwise, the zero-order hold. That approximation is first order accurate in the step size. The local error then falls roughly in proportion to the step, and the global error grows with the number of steps in the way you would expect from a first-order method. FMI helps by letting FMUs that declare maxOutputDerivativeOrder provide output derivatives and accept input derivatives, so the master can extrapolate inputs linearly or quadratically across the step. That is why the capability flags in the previous section matter.

Algebraic loops and the loop-gain test

When FMU A’s output feeds B and B’s output feeds A in the same instant, you have an algebraic loop. Plain Jacobi or Gauss-Seidel stepping silently turns it into a delay. If the loop has direct feedthrough, the result can be wrong or unstable.

A worked illustration, with numbers chosen for clarity and not drawn from a real product. Let FMU A compute y = 2u + 1 and FMU B compute u = 0.6y. The exact algebraic solution satisfies y = 1.2y + 1, so y = -5 and u = -3. Now solve it by fixed-point iteration, repeatedly feeding outputs back as inputs, starting at y = 0. The iterates are 1, 2.2, 3.64, 5.37 and so on, growing by about a factor of 1.2 each pass. They diverge, even though a unique solution exists, because the loop gain 2 x 0.6 = 1.2 exceeds 1. A single Newton step using the directional derivatives of A and B finds y = -5 immediately, since the system is linear.

The lesson is general. Fixed-point iteration converges when the loop gain in magnitude is below 1. For anything stronger, a master needs either a different formulation (restructure the model, add a state to break the loop) or an FMU that provides directional derivatives so that a Newton-type or relaxation solver can be used. FMI 2.0 defines fmi2GetDirectionalDerivative, and FMI 3.0 retains the capability, but only if the FMU sets providesDirectionalDerivatives in its description. Many co-simulation FMUs do not, which is why masters often fall back on damped fixed-point iteration with a relaxation factor.

Step-size control and rollback

An adaptive master needs a local error estimate. One common technique, described in the co-simulation literature, is step doubling: from a saved state, advance one full step h, then restore and advance two half steps, and compare the outputs. The difference estimates the coupling error. This needs the ability to save and restore FMU state, fmi3GetFMUState and fmi3SetFMUState, and therefore the canGetAndSetFMUstate capability.

Figure 3: A master snapshots each FMU, steps them, estimates error, and either commits the step or restores state and retries with a smaller h.

Figure 3 shows the control flow. After the step the master compares an error estimate against a tolerance and, if it is exceeded, restores state and shrinks the step. A standard controller for a method of order p chooses the next step as h_new = h x clamp(0.9 x (tol / err)^(1/(p+1)), 0.2, 5). A worked illustration: with a zero-order hold, p = 1. Suppose h = 10 ms, tolerance 1e-3 and measured error 4e-3. The ratio is 0.25, its square root is 0.5, times the 0.9 safety factor is 0.45, so the step is rejected and retried at 4.5 ms. If the retry measures 2e-4, the ratio is 5, the square root about 2.24, times 0.9 is about 2.0, and the controller proposes 9 ms for the next step. These are illustrative numbers, but the arithmetic shows how quickly a controller backs off and recovers.

Two practical points deserve emphasis. First, if even one FMU cannot restore state, the entire master loses rollback, because partial rollback produces inconsistent time across components. Second, rollback is costly for large FMUs: serializing the state of a finite-element model can take longer than the step itself. A master should expose the cost of snapshots, not hide it.

Failure inside a step

Co-Simulation FMUs report a status from doStep: OK, warning, discard, error or fatal in FMI 2.0 terms. A discard means the FMU could not complete the requested step but its state remains valid, so the master can retry with a smaller step. An error means state is suspect and the FMU must be reset. A good master maps these to explicit policies rather than letting NaN values flow downstream. Another standard defensive check is to monitor energy or mass balance across coupled interfaces, because a drifting balance reveals instability before values explode.

Orchestration Tooling: SSP, DCP and Open Libraries

Direct answer. SSP describes the assembly, FMI describes each component, and a master tool executes it. Libraries such as FMPy, PyFMI and the Open Simulation Platform’s libcosim provide masters. DCP addresses distributed and real-time cases where components run on separate hardware connected by a network.

SSP: the system description

An SSP package is a zip file, conventionally with the .ssp extension. At its heart is a SystemStructure.ssd XML file that lists components (typically FMUs), their parameter bindings, and the connections between named connectors. Companion files hold parameter sets and mapping rules. The point is that the topology of the twin is data, not code. Swapping a battery model means changing a reference and rerunning, and a calibration job can update a parameter file without rebuilding the assembly. SSP 2.0, per the Modelica Association announcement of December 2024, extends this with architecture exchange, FMI 3.0 support and richer metadata, and positions SSP as the base for a future simulation traceability standard. The official SSP 2.0 announcement lists these changes.

Libraries and masters

FMPy is an open-source Python package that can inspect, validate and simulate FMUs, supporting FMI 1.0, 2.0 and 3.0 in both Model Exchange and Co-Simulation modes. At the time of writing its PyPI page lists version 0.3.32, released in September 2026.
PyFMI is a Python package from the Modelon ecosystem for loading and simulating FMUs. Check its current release notes before relying on specific FMI 3.0 behaviour. We have not verified its FMI 3.0 coverage for this article.
libcosim is the C++ co-simulation library from the Open Simulation Platform, published as open source under the Mozilla Public License 2.0. It was developed in the maritime-industry-oriented OSP programme. The repository mentions optional proxy-fmu support for running FMUs out of process, which helps isolate crashes and licence conflicts. We did not verify its supported FMI versions or algorithm list for this edition.
Commercial platforms. Many system-simulation and CAE tools import and export FMUs and include their own masters. Capability varies, in particular on rollback and variable step support.

Earlier editions of this article described a specific orchestrator as using ZeroMQ for inter-FMU communication. We could not verify that claim and have removed it.

DCP: distributed and real-time coupling

The Distributed Co-Simulation Protocol is a Modelica Association project aimed at coupling simulators and real-time systems, including hardware in the loop, over networks. Unlike FMI, which defines a library interface loaded into one process, DCP defines a protocol with slaves and a master that exchange messages, so components can run on different machines or on embedded targets. The protocol and its slave description are separate from FMI, though they can reuse the FMI variable concepts. Check the Modelica Association project page for its current release status, which we have not confirmed for this edition.

For many twins DCP is more than is needed. When all FMUs can run on one host, or in containers behind a thin RPC wrapper, a library master is simpler. DCP becomes attractive when a physical controller, a test rig or a real-time target must participate in the loop with predictable timing.

Runnable Example: A Minimal Master in Python

Direct answer. With FMPy you can run an FMU in one line using simulate_fmu, and you can write a small custom master for two FMUs by instantiating each as a slave, setting inputs, calling doStep and reading outputs. The custom loop is where you control coupling order, extrapolation and rollback.

First, the one-liner. simulate_fmu picks the FMU type and runs it with a built-in solver for Model Exchange or with the FMU’s own stepping for Co-Simulation. The fmi_type argument selects the interface when an FMU offers both.

from fmpy import simulate_fmu, read_model_description

path = "Battery.fmu"
md = read_model_description(path)
print(md.fmiVersion, [t for t in ("modelExchange", "coSimulation") if getattr(md, t)])

result = simulate_fmu(
    path,
    start_time=0.0,
    stop_time=600.0,
    step_size=0.1,                  # communication step for Co-Simulation
    start_values={"capacity_Ah": 50.0},
    output=["V_cell", "T_cell"],
    fmi_type="CoSimulation",        # or "ModelExchange"
)
print(result["T_cell"][-1])

Now a two-FMU Gauss-Seidel master, with the controller stepped after the plant so that it sees fresh outputs. Variable names and file names are placeholders to adapt to your own FMUs. The code follows the FMI 2.0 slave interface provided by FMPy; for FMI 3.0 FMUs the corresponding FMU3Slave class is used, and method names differ slightly.

from fmpy import read_model_description, extract
from fmpy.fmi2 import FMU2Slave

def load(path, name):
    md = read_model_description(path)
    d = extract(path)
    vr = {v.name: v.valueReference for v in md.modelVariables}
    fmu = FMU2Slave(guid=md.guid, unzipDirectory=d,
                    modelIdentifier=md.coSimulation.modelIdentifier,
                    instanceName=name)
    fmu.instantiate()
    return fmu, vr

plant, p = load("Plant.fmu", "plant")
ctrl, c = load("Controller.fmu", "ctrl")

t, h, t_end = 0.0, 0.01, 10.0
for f in (plant, ctrl):
    f.setupExperiment(startTime=t)
    f.enterInitializationMode()
    f.exitInitializationMode()

y_plant = 0.0
log = []
while t < t_end - 1e-12:
    # Gauss-Seidel order: plant first with last control input, controller second
    plant.doStep(currentCommunicationPoint=t, communicationStepSize=h)
    y_plant = plant.getReal([p["speed"]])[0]

    ctrl.setReal([c["measured"]], [y_plant])
    ctrl.doStep(currentCommunicationPoint=t, communicationStepSize=h)
    u = ctrl.getReal([c["command"]])[0]

    plant.setReal([p["command"]], [u])   # applied at the next step: one step delay
    t += h
    log.append((t, y_plant, u))

for f in (plant, ctrl):
    f.terminate()
    f.freeInstance()

Three details deserve comment. The command written after the plant step is applied only at the next step, so the loop still contains a one-step delay on that path, which is a deliberate and visible choice. The fixed h is a hostage to stability, so for production use you would add the step-doubling check from earlier, which requires getFMUstate and setFMUstate. And exceptions from doStep should be caught and mapped to policy, not allowed to crash the twin.

A useful test before trusting any master: run the same assembly at h, h/2 and h/4. If the output converges at roughly the rate the scheme predicts, halving the error per halving of h for a first-order scheme, the coupling is behaving. If it does not, you have an algebraic loop, a discontinuity, or an FMU that disagrees with its declared capabilities.

Integrating FMUs into a Digital Twin

Direct answer. In a digital twin, the FMU assembly runs as a service fed by live data. Sensors and controllers supply inputs through an adapter, the master is paced to wall-clock time, outputs are compared with measurements to produce residuals, and a calibration loop updates parameters. FMI standardizes the model boundary, not the data plumbing, so you must design the rest.

Figure 4: Live data enters through a gateway and estimator, the master runs FMUs against wall-clock time, and residuals drive calibration of SSP parameters.

Real time is a master concern

FMI does not define real time. A master that runs as fast as it can is a simulator; to make it a twin component it must pace each communication step against a clock. The simplest design computes the next deadline as start time plus simulated time, sleeps until it, and records the lateness. The twin then has to decide what to do about overruns: skip, shrink the model fidelity, or flag the output as stale. Variable-step masters complicate this, since a rejected step consumes wall time without advancing the twin. Fixed communication steps with pre-verified stability margins are common in the real-time part of a twin for exactly this reason.

If hard timing matters, as with hardware in the loop, the master should run on a real-time operating system, FMUs should be compiled without dynamic allocation in the step path, and DCP or a similar protocol should carry the external signals. Most monitoring and what-if twins do not need this.

Getting live data into the model

Inputs to an FMU are variables with input causality. The adapter must convert units, handle missing samples and decide how to fill gaps. A zero-order hold on the latest sample is simple but introduces lag; linear extrapolation using input derivatives is better when the FMU declares support. Protocol choice, MQTT or OPC UA among others, sits outside FMI. What matters is that each input has a freshness policy and that stale data is reported rather than silently reused.

State synchronization and calibration

A twin is only useful if its internal state tracks the asset. There are two levers. One is parameter calibration: an optimizer compares predicted and measured outputs over a window and updates tunable parameters, such as thermal resistances or friction coefficients. SSP parameter sets make this a data operation, and the Modelica Association explicitly cites efficient parameter updates for AI-driven calibration among the goals of the recent standards. The other lever is state correction: setting FMU states to match an estimate from a Kalman-type filter. FMI supports setting an FMU’s state only where the FMU declares the capability, and Co-Simulation FMUs typically expose only a serialized opaque state that the importer cannot meaningfully edit. In that case the practical approach is to restart from a consistent initial condition computed outside the FMU, or to expose the key states as input or parameter variables when you control the model.

Where AAS and information models fit

An FMU says what a model computes. It does not say which asset it represents, who owns it, or which version of a pump it was calibrated for. That is the job of a descriptive layer such as the Asset Administration Shell, which can reference the FMU and the SSP as submodel content and record calibration provenance. For the broader picture of AI-driven twins that consume such models, see our analysis of agentic digital twins. The separation of behaviour from identity keeps each layer replaceable.

Deployment and security

FMUs contain native code. Loading an FMU from an untrusted supplier runs that supplier’s binary inside your process, with your privileges. Treat FMUs like any other third-party executable: verify signatures where available (SSP 2.0 broadens digital signature support), run them in a separate process or container, and keep them off hosts with sensitive credentials. Out-of-process execution, such as the proxy approach noted in the libcosim repository, also isolates crashes, so a segfault in one vendor’s library does not kill the twin. Platform binaries are another operational concern: an FMU must contain a library for the architecture you deploy on, and an FMU built only for Windows will not run in a Linux container. Source-code FMUs avoid this at the price of IP exposure and a compile step.

Trade-offs, Gotchas, and What Goes Wrong

Direct answer. The common failures are instability from too-large communication steps, silent loops, FMUs that claim capabilities they lack, discontinuities mishandled across the interface, and licensing or platform surprises. Most can be caught by convergence tests, capability validation and a strict policy for FMU failure.

Stability depends on the step. Explicit coupling of stiff, tightly coupled subsystems, such as a thermal mass exchanging heat with a fast power electronic stage, can become unstable above a critical step even though each FMU is accurate. The only safe cure is a smaller step, an iterating scheme or restructuring the split. Choose the cut where coupling is weak, for instance across a long time constant, not across a stiff spring.
Energy leaks at the interface. With zero-order hold coupling, energy can be created or destroyed at each communication point. For mechanical or electrical coupling, monitoring a power balance across the boundary catches this early. Exchanging the integral of a flow, not the flow itself, or using a consistent mass-conserving split, reduces the leak.
Events do not cross the boundary. In Co-Simulation, an event inside one FMU is invisible to others until the step ends. A relay that trips mid-step affects a neighbour one step late. FMI 3.0 clocks and early return reduce the problem, but only for FMUs that implement them.
Capability claims can be wrong. Test rollback by saving state, stepping, restoring and stepping again, and compare results bit for bit. Some FMUs advertise state support yet restore incompletely, which breaks adaptive masters in confusing ways.
Non-determinism. Multi-threaded solvers, uninitialised memory and wall-clock dependence inside FMUs make reruns differ. For a twin used in audits, determinism is a requirement, so test it.
Licensing at runtime. Many exported FMUs need the authoring tool’s licence or a runtime licence server. Parallelising ten copies of such an FMU may require ten licences. Find out before architecture is fixed.
Version drift. FMI 2.0 remains the most widely supported version, and some commercial tools still lag on FMI 3.0. Do not assume your tool chain supports clocks or binary variables; check export and import support for each tool, and keep an FMI 2.0 fallback.
Unit and sign conventions. A declared unit in the XML is metadata, not enforcement. Sign conventions for flows across ports remain a modelling agreement. A single flipped sign produces a stable-looking, wrong twin.

None of these failures is exotic. They show up in the first serious integration, which is why the cheapest quality investment is a regression suite that runs the assembly at several step sizes and compares against a reference.

Practical Recommendations

Treat the choice of FMI mode as an organisational question first. If you buy models from vendors, you will receive mostly Co-Simulation FMUs, and your master must be strong. If you build models in one environment, Model Exchange may let a single integrator handle everything, with the best accuracy and event handling. Platforms should support both.

Invest in the master. A thin loop that calls doStep in a fixed order is fine for a prototype, and a liability once models disagree. Production masters need error estimation, rollback, loop handling, status policies, structured logging and deterministic replay. Use an existing library where you can, and write the policies yourself where your domain demands it.

Make the assembly data. Describe it in SSP, keep parameter sets under version control, and tie each calibrated parameter set to the data window and tool version that produced it. This gives you reproducibility, which is the foundation of trust in a twin.

Checklist:

Inventory each FMU: FMI version, ME or CS, capability flags, platforms, licence model.
Reject or wrap FMUs with undeclared platform support or unknown licence terms.
Choose the cut points of the system at weak couplings; draw the dependency graph and find loops.
Pick Jacobi for parallel throughput, Gauss-Seidel for faster information flow, and iteration for strong loops.
Run a step-halving convergence test and an energy-balance check before trusting any result.
Test state save and restore on every FMU you intend to roll back.
Run third-party FMUs out of process, with signature or checksum verification.
Pace the master against a wall clock and publish lateness as a metric.
Version SSP files and parameter sets, and record calibration provenance.
Keep an FMI 2.0 fallback until every tool you depend on supports FMI 3.0.

Frequently Asked Questions

What is the difference between Model Exchange and Co-Simulation in FMI?

In Model Exchange the FMU provides derivatives, event indicators and discrete-state updates, and the importing tool supplies the numerical integrator. In Co-Simulation the FMU includes its own solver and advances itself over a communication step when the master calls a step function. Model Exchange offers more control and visibility to the importer. Co-Simulation offers encapsulation, vendor-tuned solvers and IP protection, but introduces coupling error between FMUs because inputs are approximated across each communication step.

Which FMI version should I use in 2026?

FMI 2.0 remains the broadest common denominator across tools, and FMI 3.0 is the current generation, with 3.0.2 released in November 2024 as a maintenance update. Choose FMI 3.0 when you need clocks, arrays, binary variables or virtual ECU support, and when every tool in your chain supports it. Otherwise ship FMI 2.0 and plan the migration. FMUs built to 3.0.2 remain valid under 3.0 and 3.0.1.

How do I handle algebraic loops between FMUs?

First try to remove the loop by restructuring: introduce a state or delay at a physically justified point. If the loop must stay, use an iterating master and make sure the loop gain is below one for fixed-point iteration, or use damping. If FMUs provide directional derivatives, a Newton-type solve converges even with gain above one. Always cap iterations and reject the step with a smaller size if convergence fails.

Can a co-simulation master run in real time for a digital twin?

Yes, but real-time pacing is the master’s job, because FMI defines no clock-synchronized execution for Co-Simulation. Use fixed communication steps with verified stability, pace against a monotonic clock, and monitor overruns. For hard real-time loops with physical hardware, consider a real-time operating system and the Distributed Co-Simulation Protocol. Most monitoring and what-if twins only need soft real time and a clear policy for stale data.

What is SSP and how does it relate to FMI?

The System Structure and Parameterization standard describes how components, usually FMUs, are connected and parameterized. FMI defines each component; SSP defines the assembly, parameter sets and connections as a portable package. SSP 2.0, released in December 2024, adds architecture exchange, FMI 3.0 support, Modelica component support, richer metadata and signatures. It lets you swap models and update parameters without rewriting the orchestration code.

Are FMUs safe to run from third parties?

An FMU contains compiled native code, so it runs with the privileges of the process that loads it. Treat it like any third-party binary: obtain it from a trusted source, check signatures or checksums where provided, and execute it in a separate process or container with minimal permissions. Out-of-process execution also contains crashes. Also check licence terms, since many FMUs need the authoring tool’s runtime licence.