Modelica Digital Twin vs Simulink: Physics-Based Models, OpenModelica and FMI (2026)

Most digital twin projects do not fail because the data pipeline is wrong. They fail because the physics model at the centre of the twin cannot be reused, cannot be initialised from live sensor values, or cannot be handed to the next team without a licence conversation. A Modelica digital twin and a Simulink twin both promise a faithful virtual copy of a plant, yet they encode that copy in two very different ways, and the difference decides how painful your second and third model will be.

This matters in 2026 because the interchange layer has finally matured. FMI 3.0 and SSP 2.0 mean a model written in one tool can be packaged, parameterised and wired into a larger system in another, and neither language owns the twin any more. What you choose now is the authoring language, not a prison.

You will leave with a clear mental model of acausal versus causal modelling, a runnable thermal-tank example, an honest comparison of Modelica, Simulink and Simscape, and a practical path from model to calibrated, FMU-packaged twin.

What this covers: the two modelling paradigms, how the compilers turn equations into solvable code, FMI and SSP packaging, calibration against live data, licensing, and the failure modes (stiffness, initialisation) that bite in production.

Context and Background

Physics-based digital twins sit between two worlds. On one side are purely data-driven surrogates, which are cheap to build and brittle outside their training envelope. On the other are first-principles models that extrapolate sensibly because conservation laws do the heavy lifting, but demand engineering effort and careful parameter identification. A hybrid twin, which is where most industrial projects land, uses the physical model as the backbone and lets data correct what the physics leaves out. If you are building the surrounding plumbing, our post on the ISO 23247-5 digital thread reference architecture shows where a simulation model plugs into the wider observable-manufacturing-element picture.

Two tool families dominate physical system modelling. Simulink, from MathWorks, is a block-diagram environment: you draw signal flow, and each block computes outputs from inputs. Its physical-domain extension, Simscape, adds a network-style language for electrical, thermal, hydraulic and mechanical components. Modelica is different in kind: it is an open, object-oriented, equation-based language maintained by the Modelica Association, with several independent implementations. Commercial tools include Dymola, SimulationX and Modelon Impact; OpenModelica is the open-source reference implementation. The language specification is at version 3.6 in the current maintenance line, and per Hans Olsson’s paper on that release, its changes cover clearer parameter defaults, clearer start-value priority, selective model extension and multi-lingual support. The same paper cautions that the benefits only materialise once tools implement them, which is a recurring theme with any standard.

Around both languages sits the Functional Mock-up Interface (FMI), also stewarded by the Modelica Association. An FMU (Functional Mock-up Unit) is a ZIP archive with an XML description, compiled binaries or C sources, and optional resources. FMI 3.0, whose current documentation line is 3.0.2, defines three interface types: Model Exchange, where the importer integrates the equations; Co-Simulation, where the FMU carries its own solver; and the new Scheduled Execution, where the importer’s scheduler triggers model partitions. A companion standard, the System Structure and Parameterization format (SSP), describes how FMUs are wired together. SSP 2.0 was announced in December 2024 and was developed alongside FMI 3.0.

The practical consequence is that “Modelica or Simulink?” is rarely a final decision. A twin is a system of models: a plant model from the mechanical group, a controller from the automation group, a battery model from a supplier. The real question is which language you author your own physics in, and what you export. For the Python side of running such FMUs, see our FMI 3 co-simulation tutorial with FMPy.

Causal Blocks versus Acausal Equations: The Core Difference

A causal model fixes the direction of computation before the solver starts; an acausal model states relationships and lets the compiler choose directions. In a Simulink block diagram every connection carries a signal from an output to an input. In Modelica, a connection between two components generates equations, and the tool decides which variable to solve for. That single difference drives almost every downstream trade-off in reuse, initialisation and numerical behaviour.

Figure 1: Causal block-diagram flow (left path) versus acausal equation flow (right path). The acausal path adds symbolic processing that picks the computation order for you.

Figure 1 summarises the contrast. On the causal path, the modeller derives the equations by hand, chooses which quantity is the output, and wires blocks accordingly. On the acausal path, the modeller declares components and connections; the compiler assembles a global equation system, sorts it, reduces its index and emits solver code.

Why direction-free connections matter

Consider a pipe connected to a pump. In a block diagram you must decide up front that the pump imposes flow and the pipe returns pressure, or the reverse. Swap the pump for a fixed-pressure boundary and the diagram has to be rewired because the causality changed. In Modelica, both components expose a connector with a potential variable (pressure) and a flow variable (mass flow rate). Connecting them yields two equations: potentials are equal, flows sum to zero. Nothing in the model says who drives whom, so the same pipe component works against either boundary.

That is what makes the Modelica Standard Library (MSL) possible. It ships hundreds of reusable components across electrical, mechanical, thermal, fluid and magnetic domains, and a user composes them by dragging and connecting rather than rederiving. Simscape achieves a similar effect with its own physical-network semantics: ports carry Across and Through variables, and Simscape components are likewise non-causal inside a physical network. The honest framing is therefore not “acausal versus causal” but “open-language acausal versus a proprietary acausal sub-domain embedded in a causal host”.

Conservation laws are structural, not coded

Connector semantics encode Kirchhoff-style balance automatically. Across (potential) variables are equated at a connection; Through (flow) variables are summed to zero at a node. For a thermal network the pair is temperature and heat flow rate; for hydraulics it is pressure and volume or mass flow; for a rotating shaft it is angle and torque. Because balances are generated rather than hand-written, a whole class of modelling errors, such as energy that appears from nowhere because a sign was flipped, becomes much harder to make. This is a real advantage for twins that must stay trustworthy for years under maintenance by people who did not build them.

Where causal blocks still win

Causal block diagrams are the right tool for anything that is genuinely a signal-processing or control computation: PID loops, state machines, discrete-time filters, Kalman filters, code generation to a real-time target. Control engineers think in signal flow, the tooling for fixed-step code generation is deep, and discrete-time semantics are explicit. Modelica can express controllers (clocked synchronous language elements exist for sampled systems), but it is rarely where a controls team prefers to live. That split explains why the pragmatic industrial pattern is a Modelica plant plus a Simulink controller, joined by an FMU.

From Equations to Executable Code: What the Compiler Does

A Modelica compiler is a symbolic mathematics engine, and understanding its stages explains most of the behaviour you will see in practice. Given a flat set of differential, algebraic and discrete equations, it must produce code that a numerical integrator can step. The path is well established in the literature and in the OpenModelica documentation, and the stages are shared in spirit by Dymola and others even though each tool differs in detail.

Figure 2: Typical compilation pipeline. Flattening, causalisation, index reduction and tearing happen before any numerical step is taken.

Flattening and equation count

The front end instantiates the class hierarchy, expands connectors into equality and sum-to-zero equations, and produces one flat system of equations and variables. A well-posed model has as many equations as unknowns. Tools check this and report “structurally singular” or “over-determined” errors before simulation begins, which is a major quality gate: a bad model fails at compile time rather than producing silent nonsense.

Sorting, causalisation and tearing

Next the compiler builds a bipartite graph linking equations to the variables they contain and finds a matching, deciding which equation solves for which variable. Block lower triangular (BLT) transformation then orders the equations and isolates strongly connected components, the algebraic loops. Small loops can be solved by a nonlinear or linear solver; larger ones are reduced by tearing, which chooses a small set of “tearing variables,” iterates only on those and computes the remainder by explicit substitution. For a hydraulic network with 200 algebraic unknowns, good tearing can reduce the iterated unknowns to a handful, which is the difference between a real-time-capable twin and one that is not. This sorting is the thing a block diagram makes you do by hand.

Index reduction

Differential-algebraic equation (DAE) systems are classified by their differentiation index: roughly, how many times you must differentiate the constraints to turn the system into an ordinary differential equation. Index-1 systems are straightforward for standard DAE solvers such as the implicit methods in SUNDIALS IDA or DASSL. Mechanical systems with rigid joints produce index-3 formulations, and high-index systems cannot be integrated directly in a stable way. Compilers apply the Pantelides algorithm to find which equations to differentiate, then the dummy-derivative method to select states so that the resulting system is index-1 with consistent initial conditions. Users see this as certain variables being “demoted” from states, and as additional initialisation equations they must satisfy.

The cost is non-trivial. Index reduction makes initial conditions subtle, because a differentiated constraint is a hidden extra requirement on the start values. Hence the most common first-week error with a new mechanical model is an initialisation failure rather than a simulation failure.

Code generation and solver choice

The final stage emits C code for residual evaluation, Jacobians and event handling, and links a runtime. OpenModelica’s runtime offers solvers such as DASSL and the SUNDIALS CVODE and IDA families; its documentation describes exporting FMUs where Co-Simulation FMUs can use Forward Euler (the default) or CVODE. That detail matters: a Forward Euler default in an exported Co-Simulation FMU is cheap and deterministic, but it will be unstable on stiff plants unless you switch the solver or shrink the step.

Simulink works differently. Its engine takes the diagram, performs its own sorting for block execution order, and relies on the chosen variable-step or fixed-step solver. Simscape adds a local solver option for physical networks that is designed for fixed-step, real-time use, with a global solver handling the rest. The practical result is similar, a numerically integrated system, but the symbolic stage is lighter in Simulink, so more responsibility for avoiding algebraic loops sits with the modeller. The “Algebraic Loop” warning is a familiar Simulink experience that rarely arises in the same form in Modelica, because the compiler solves the loop symbolically or numerically on your behalf.

A Worked Example: A Heated Storage Tank as a Modelica Digital Twin

The fastest way to see why equation-based models suit a twin is to write one. The example below models a well-mixed hot-water storage tank with an electric heater and heat loss to ambient. It is deliberately small, yet it already shows parameters, a state, a boundary input and a clean separation between physics and control. All numbers are illustrative, chosen so the arithmetic is easy to follow, not measured from a real tank.

model HeatedTank "Well-mixed storage tank with heater and wall loss"
  import SI = Modelica.Units.SI;

  // Physical parameters (illustrative values)
  parameter SI.Volume V = 2.0 "Tank volume";
  parameter SI.Density rho = 983 "Water density near 60 degC";
  parameter SI.SpecificHeatCapacity cp = 4186 "Water specific heat";
  parameter SI.ThermalConductance UA = 20 "Overall loss coefficient";
  parameter SI.Temperature T_start = 313.15 "Initial temperature";

  // Inputs from the outside world
  Modelica.Blocks.Interfaces.RealInput Q_heater(unit="W") "Heater power";
  Modelica.Blocks.Interfaces.RealInput T_amb(unit="K") "Ambient temperature";

  // State and outputs
  SI.Temperature T(start = T_start, fixed = true) "Bulk water temperature";
  Modelica.Blocks.Interfaces.RealOutput T_out(unit="K") "Measured tank temperature";

protected
  parameter SI.HeatCapacity C = rho * V * cp "Thermal capacity";
equation
  C * der(T) = Q_heater - UA * (T - T_amb);
  T_out = T;
end HeatedTank;

The single physics line is the energy balance: thermal capacity times the rate of change of temperature equals heater power minus conduction loss. With the illustrative values, the capacity is C = 983 × 2.0 × 4186 ≈ 8.23 MJ/K, and the passive time constant is C / UA ≈ 4.1 × 10^5 s, close to 114 hours. Those are slow dynamics, which is realistic for a well-insulated tank. At a 60 degC set point (333.15 K) against 20 degC ambient, the steady-state loss is UA × 40 K = 800 W, so a heater delivering 800 W holds temperature, and anything above that raises it. Heating from 40 degC to 60 degC with a 3 kW heater, ignoring losses, takes about 8.23 MJ/K × 20 K / 3 kW ≈ 55,000 s, or roughly 15 hours. Those are easy numbers for an engineer to sanity-check, which is exactly the property you want in a model people must trust.

Notice what is absent. There is no manual rearrangement into state-space form, and no decision about whether temperature is an output or a state. Add a second node and a heat exchanger from the Modelica Standard Library or a commercial thermal library, and the compiler regenerates the sort. A Simscape equivalent uses a Thermal Mass block, a Conductive Heat Transfer block and a Heat Flow Rate Source, connected on a thermal network; the result is analogous, with the network semantics supplied by MathWorks rather than by an open specification.

Simulating with OpenModelica from Python

OpenModelica exposes a scripting interface that Python can drive through the OMPython package. A twin pipeline typically loads the model, sets parameters from a configuration, simulates, and reads results. The sketch below assumes the model above is saved as HeatedTank.mo and wrapped in a small test model TankTest that supplies constant inputs.

from OMPython import OMCSessionZMQ

omc = OMCSessionZMQ()
omc.sendExpression('loadFile("HeatedTank.mo")')
omc.sendExpression('loadModel(Modelica)')

# Override calibrated parameters without editing the source
omc.sendExpression(
    'simulate(TankTest, stopTime=86400, numberOfIntervals=500, '
    'simflags="-override=tank.UA=18.5")'
)
T = omc.sendExpression('val(tank.T, 43200)')
print(f"Tank temperature after 12 h: {T - 273.15:.2f} degC")

The -override runtime flag changes a parameter at simulation start without recompiling, which is the hook a calibration loop needs. For repeated runs you would instead export an FMU once and drive it from a Python FMI library, covered in the FMPy tutorial linked earlier.

Exporting an FMU

From OpenModelica, buildModelFMU(TankTest, version="2.0", fmuType="cs") produces a Co-Simulation FMU; by default the exported FMU supports both Model Exchange and Co-Simulation. According to the OpenModelica User’s Guide, FMI 2.0 export is supported for both interface types while FMI 3.0 export is marked experimental, and FMI 1.0 is deprecated. The guide also states that importing FMUs as Modelica components is described only for Model Exchange 2.0 and requires a non-standard flag, so check the current documentation before relying on import. These version details change between releases; the latest 1.26.x patch line shipped through mid-2026, so confirm against the release you install.

Modelica vs Simulink: A Decision Matrix for Twin Builders

The comparison below is organised by the questions that actually decide a twin project, not by feature checklists. Statements about vendor products reflect public documentation at the time of writing; verify licensing and version details with the vendor before committing.

Criterion	Modelica (OpenModelica, Dymola, SimulationX, Modelon Impact)	Simulink with Simscape
Language status	Open specification, several independent implementations	Proprietary language and tooling
Modelling style	Acausal, equation-based, object-oriented	Causal block diagrams; Simscape adds acausal physical networks
Multi-domain physics	Large open Modelica Standard Library plus commercial libraries	Simscape family of domain libraries, sold as add-on products
Algebraic loops, DAE handling	Compiler performs sorting, tearing and index reduction	Engine handles execution order; loops and high index need modeller attention
Controller design and code generation	Possible, less common in practice	Strongest area, mature code generation workflows
FMU export	Supported by tools; OpenModelica FMI 2.0 ME and CS, FMI 3.0 experimental	Simulink FMU Builder exports ME and CS FMUs, FMI 2.0 or 3.0
Licence cost for scaling a twin to many instances	OpenModelica free; commercial tools licensed	Licence per product and seat; check runtime and deployment terms
Ecosystem lock-in risk	Lower, because source is portable between tools within language limits	Higher for the model source, lower once exported as FMU

Reading the matrix honestly

Two cells deserve emphasis. First, “portable between tools” is true of the Modelica language but not perfectly of every library: a model that uses vendor-specific annotations, or non-standard extensions as OpenModelica’s own import flag illustrates, can lose portability. Second, the FMU escape hatch is available to both worlds. A Simscape plant exported through Simulink FMU Builder is a perfectly good black box for a Python orchestrator, as MathWorks documents that Simscape models can be exported with tunable parameters and internal variables. The caveat there is that some parameters may not appear as tunable, and MathWorks maintains a separate limitations page.

A third point is organisational. Mechanical, thermal and process engineers tend to find Modelica component diagrams read like the physical schematic. Controls engineers find block diagrams natural. Choosing the language that matches the dominant author community of your model is often worth more than any feature on the matrix, because a twin lives or dies on whether domain experts can maintain it.

When to choose which

Choose Modelica when the plant is multi-domain and large, when many variants of the same equipment must be generated from a common library, when you want to avoid licence cost per deployed instance, or when you want the model source to outlive any one vendor relationship. Choose Simulink and Simscape when your organisation already runs on MATLAB, the controller is the star of the project, you need the code-generation toolchain for embedded targets, or when your team’s existing models are the real asset. Choose both, joined by FMI, when the plant and controller come from different groups, which is the situation more often than either camp admits.

Packaging the Twin: FMI 3.0, SSP and Co-Simulation Architecture

An FMU is the unit of exchange, and SSP is the wiring diagram. FMI 3.0 added features that matter directly to physical twins: clocks for synchronising events across FMUs, array variables and structural parameters, a binary data type, directional and adjoint derivatives, early return from fmi3DoStep, and an Event Mode with an Intermediate Update Mode for Co-Simulation. Asynchronous Co-Simulation and the fmi2SetRealInputDerivatives function from FMI 2.0 were removed. Semantic versioning means features added in minor versions are optional, so an FMU stays valid across minor releases of the same major version.

Figure 3: A reference twin architecture. Plant and controller FMUs are wired by an SSP description, stepped by a co-simulation master, and fed by live sensor data through an adapter.

Model Exchange or Co-Simulation?

In Model Exchange the FMU exposes derivatives and event indicators, and the importer’s solver integrates it. This gives the importer control of accuracy and lets one solver integrate several coupled FMUs jointly, which is the right choice for tightly coupled physics. In Co-Simulation each FMU brings its own solver and the master exchanges values at communication points. This is simpler for black-box IP and for mixing tools, but introduces coupling error: inputs are held constant or extrapolated over each communication step.

A rule of thumb is to size the communication step well below the fastest coupled time constant. If a hydraulic FMU has a dominant dynamic near 50 ms and a controller samples at 10 ms, a 1 ms master step is a reasonable starting point; this is an illustrative guideline, not a standard, and you should verify by halving the step and confirming that outputs change by less than your tolerance. For weakly coupled slow systems, such as the 114-hour tank above, steps of tens of seconds are plenty.

Where SSP fits

SSP 2.0, announced in December 2024, extends the exchange of composite systems: it supports exchanging architecture specifications that are refined incrementally, handles Modelica-based components with causal and acausal connection semantics, maps structured interface types to binary connectors, supports FMI 3.0 virtual ECUs, and allows embedding other artifacts such as metadata, signatures and, for digital twins, 3D models alongside behavioural models. The announcement also highlights more efficient parameter updates for calibrating FMUs, using dynamic array sizes and enhanced parameter file formats. For twin builders that is the key idea: the system description, parameter sets and visual assets travel together, which is what a twin registry needs. Our post on robot description formats covers the geometric side of the same packaging problem.

The master algorithm

The co-simulation master is where many twins quietly go wrong. A fixed-step Gauss-Seidel master steps FMUs in sequence and is simple, but it introduces a one-step delay on some signals and can destabilise stiff couplings. A Jacobi master steps all FMUs in parallel from the same inputs, which parallelises well but increases coupling error. Iterative masters repeat a step until the coupling variables converge, which needs FMUs that can roll back state. FMI supports state serialisation for this, but not every FMU implements it. Before choosing an architecture, check which capability flags your FMUs declare in modelDescription.xml.

Calibration and State Estimation Against Live Plant Data

A physics model becomes a twin the moment it is tied to a specific asset and kept synchronised with it. Two distinct problems appear, and conflating them is a common mistake. Parameter calibration identifies slowly varying constants such as UA, friction coefficients or fouling factors. State estimation tracks fast-changing hidden variables, such as the temperature inside the tank, given noisy measurements.

Figure 4: Two nested loops. A slow outer loop re-identifies parameters; a fast inner loop corrects states with each new measurement.

Parameter calibration

Calibration minimises a mismatch cost between simulated and measured outputs over a window of data. For the tank, suppose the true UA is unknown. You log heater power, ambient temperature and tank temperature for 48 hours, simulate with a candidate UA, and compute the sum of squared errors. A gradient-free optimiser such as Nelder-Mead is a sensible start for one or two parameters; for larger sets, gradient-based methods benefit from FMI 3.0 directional derivatives, where the FMU supports them. Parameter identifiability is the real constraint: with a slow tank and a nearly constant heater, UA and heater efficiency can be indistinguishable, so excite the system. In practice that means varying the heater power in a planned way during commissioning, so the data contains information about each parameter.

import numpy as np
from fmpy import simulate_fmu
from scipy.optimize import minimize_scalar

def sse(UA, data):
    res = simulate_fmu(
        "TankTest.fmu",
        start_time=0, stop_time=data["t"][-1],
        output_interval=60,
        start_values={"tank.UA": UA},
        input=data["inputs"],          # structured array of Q_heater, T_amb
        output=["T_out"],
    )
    T_sim = np.interp(data["t"], res["time"], res["T_out"])
    return float(np.sum((T_sim - data["T_meas"]) ** 2))

fit = minimize_scalar(lambda ua: sse(ua, data), bounds=(5, 60), method="bounded")
print("Identified UA [W/K]:", round(fit.x, 2))

Two practical details make this robust. Set tunable parameters through FMI start values rather than recompiling, and note that only variables the FMU marks as tunable or fixed can be changed this way. And always fit on one window while validating on another; a twin that matches its calibration data but not a held-out week is overfitted.

State estimation

Between recalibrations, an observer keeps the states aligned. For the single-state tank, a scalar Kalman filter is almost trivial: predict with the model, then correct with the temperature sensor weighted by relative variances. For larger models an extended or unscented Kalman filter, or a moving-horizon estimator, is typical. An FMU in Model Exchange form with Jacobians helps; a black-box Co-Simulation FMU can still be used in an ensemble filter that runs many copies, at proportional computational cost. Check whether your FMU supports fmi3GetFMUState and fmi3SetFMUState, since ensemble and rollback methods depend on them.

Hybrid corrections

Residual error that persists after calibration often points to missing physics. A principled option is to keep the Modelica backbone and learn the residual with a small data-driven term, rather than replacing the model with a neural network. If you want to explore learned surrogates for expensive simulations, see our overview of neural operators for scientific simulation. The trade-off is explainability: every learned term is a place where conservation laws can silently be violated.

Trade-offs, Gotchas, and What Goes Wrong

Physics-based twins fail in repeatable ways. Knowing them in advance is cheaper than discovering them during a customer demo.

Stiffness

Stiffness appears when a model mixes very fast and very slow dynamics, for example a hydraulic valve resonating at kilohertz inside a thermal system evolving over hours. Explicit solvers need steps small enough to resolve the fast mode and therefore crawl. Implicit solvers such as CVODE’s BDF method or DASSL cope, at the price of Jacobian factorisations. The trap in FMU land is that a Co-Simulation FMU exported with a default Forward Euler integrator, as OpenModelica’s documentation describes for its default, can blow up on a stiff plant while the same model in the authoring tool, using an implicit solver, behaves fine. Check the solver embedded in the FMU, switch it via the documented flag if available, or export as Model Exchange and let your own solver handle it. If a fast mode is irrelevant to the twin’s purpose, remove it: replace the valve dynamics with a quasi-static relation. Model order should match the question the twin answers.

Initialisation

Initialisation is the single most common source of “it compiles but will not run.” A DAE has consistency conditions: algebraic variables and, after index reduction, hidden differentiated constraints must hold at time zero. Modelica lets you mark states fixed = true with start values, or declare initial equations such as steady state. Over-specifying produces an inconsistent system; under-specifying yields an undetermined one. Modelica 3.6 clarified start-value priority, per its release paper, which helps portability between tools. For a live twin, initialise from sensor data: set states from the latest estimate, then let the algebraic variables solve. Expect nonlinear initialisation to fail when the guess is far from the solution, and provide good start attributes for iteration variables, such as pressures in a network, as guesses.

Events and discontinuities

Thermostats, check valves, friction stick-slip and switching converters introduce events. Both ecosystems handle zero-crossings, but chattering, where a condition flips repeatedly in a step, can freeze a simulation in a loop of event iterations. Add hysteresis to switching logic and keep event-generating expressions free of noisy measured inputs. When a noisy sensor drives a threshold directly, filter it first.

Co-simulation errors and numerical delay

Splitting a tightly coupled system across FMUs introduces algebraic loops across the FMU boundary. The master cannot see inside black boxes and will treat the loop with a one-step delay unless the FMUs expose directional derivatives or support rollback. Energy can drift as a result. If drift appears in a conserved quantity, shrink the step, move the coupling to a Model Exchange boundary, or merge the two models into one authoring tool.

Model validity and the drift of reality

A calibrated model is valid only inside the operating envelope of its calibration data. Fouling, wear, firmware changes and reconfigured plants shift parameters. Treat residuals as a monitored signal: when the normalised innovation of your estimator trends away from zero-mean, trigger recalibration or flag the asset. That monitoring is itself valuable, since a persistent residual on a heat exchanger is often the earliest symptom of fouling.

Licensing and cost

Costs are not just seat licences. They include library licences, runtime or deployment rights for running thousands of twin instances in the cloud, FMU export options, and training. OpenModelica removes seat cost, though you absorb integration and support effort or buy support from the vendor ecosystem. Commercial Modelica tools and MATLAB-based products each have their own terms. I have not verified current price lists, and they vary by contract, so treat any quoted figure you meet as needing confirmation. The architectural advice is to price the deployment scenario you actually need: many headless instances in containers is a very different licence conversation from ten engineers on desktops.

Practical Recommendations

Start from the question, not the tool. Write one sentence describing what decision the twin supports, such as “predict hours until the tank leaves its band” or “tune a controller against a realistic plant.” That sentence sets the required fidelity and therefore the model order. A twin that needs minute-level thermal prediction does not need a computational fluid dynamics model, and a Modelica component model with a handful of states will usually outperform a heavyweight one in both accuracy and maintainability once calibrated.

Author physics in the language your domain experts read fluently, and export FMUs at the boundaries. Keep the controller in the toolchain the controls group uses. Standardise on SSP descriptions for the assembly so that structure, parameters and metadata are versioned together rather than hidden in scripts. Prefer FMI 2.0 where your tools’ FMI 3.0 support is experimental, and test FMI 3.0 on a non-critical model first. Verify every FMU on the target platform with a regression test that compares against stored reference trajectories.

Separate calibration from estimation, and automate both. Log inputs and outputs from commissioning so you can re-run identification, and hold back data for validation.

A short checklist:

Define the twin’s decision and the accuracy required before choosing fidelity.
Check each tool’s FMI version and interface type support in current documentation.
Inspect the solver embedded in each Co-Simulation FMU and the capability flags in its model description.
Write initial equations or start values that are consistent, and initialise from live data.
Choose a communication step by halving it until outputs stop changing within tolerance.
Calibrate on one window, validate on another, and monitor residuals in production.
Price licences for the deployment topology, not the desktop.

Frequently Asked Questions

What is a Modelica digital twin?

A Modelica digital twin is a physics-based simulation model written in the Modelica language, parameterised and synchronised with a specific physical asset using live data. Because Modelica is equation-based and acausal, components such as tanks, pumps and motors are reused across variants. The model is usually packaged as an FMU so that it can run inside a cloud service, a co-simulation with a controller, or a monitoring application alongside sensor streams.

Is Modelica better than Simulink?

Neither is universally better. Modelica excels at multi-domain physical plants, reusable component libraries and open, vendor-neutral model source. Simulink excels at controller design, signal processing and embedded code generation, and Simscape adds physical networks. Many teams combine them: a Modelica plant and a Simulink controller, joined by FMI. The better choice depends on who maintains the model, the deployment topology and the licence terms.

Can Simulink models be exported as FMUs?

Yes. MathWorks documents that Simulink FMU Builder can generate Co-Simulation and Model Exchange FMUs for FMI 2.0 or 3.0, with Co-Simulation FMUs compatible with both versions and Model Exchange export shown for FMI 3.0. Simscape models can be exported with tunable parameters and internal variables, although some parameters may not be exposed as tunable. Check the current documentation for toolbox and version requirements.

Is OpenModelica good enough for production digital twins?

OpenModelica is a mature open-source implementation with FMU export for Model Exchange and Co-Simulation under FMI 2.0 and experimental FMI 3.0 export, per its user’s guide. Patch releases continued through mid-2026 in the 1.26 line. Whether it suits production depends on your libraries, the solvers you need, support expectations and performance on your model. Benchmark your own model, and keep an FMU-level test suite so a tool change stays low-risk.

What is the difference between FMI and SSP?

FMI standardises a single model unit, the FMU: its interface, variables and how an importer runs it. SSP (System Structure and Parameterization) standardises the assembly of many FMUs and other components, including connections, parameter sets and metadata. SSP 2.0 was announced in December 2024 and was developed alongside FMI 3.0. Together they let a twin’s structure be exchanged and versioned independently of any one simulation tool.

Should I use Model Exchange or Co-Simulation FMUs?

Use Model Exchange when you want your own solver to control accuracy, when coupling is tight, or when you need Jacobians for estimation. Use Co-Simulation when the supplier wants to protect IP, when tools differ, or when the FMU’s embedded solver is better suited to the physics. Co-Simulation introduces coupling error governed by the communication step, so test sensitivity before trusting results.