📚 Course ContentsChapter 3 Solver interoperability standards

3. Solver interoperability standards

In an integrated automotive simulation workflow, the hardest engineering problem is rarely the physics inside a single solver. It is making a brake controller model authored in Simulink, a vehicle dynamics plant built in Adams, a thermal network from GT-SUITE, and a battery ECM written in Python exchange data correctly and at the right time. Solver interoperability standards exist to remove the need for one-off, tool-specific glue code. The dominant standard in automotive simulation is the Functional Mock-up Interface (FMI), maintained by the Modelica Association, with its packaged artifact, the Functional Mock-up Unit (FMU).

What FMI Standardizes — and What It Does Not

FMI defines a tool-independent API, a model description schema, and a packaging format. It does not define the internal equations, the numerical solver, or the physical semantics of your model. An FMU is a ZIP archive with a defined structure:

modelDescription.xml — declares every input, output, parameter, and internal variable, including units, data types, causality, and initial values.
binaries/<platform>/ — compiled shared libraries (.dll, .so, .dylib) for co-simulation or model exchange.
sources/ — optional C sources for source-code FMUs.
resources/ — optional data files referenced by the model.

The critical distinction is between the two interface types an FMU can implement. FMI for Model Exchange (ME) exports the model as a continuous-time system of differential, algebraic, and discrete equations. The importing tool supplies the numerical integrator and controls the step size. FMI for Co-Simulation (CS) exports the model together with its own internal solver; the importing tool only advances it via fmi2DoStep and exchanges data at communication points. A single FMU may support both, but the semantics differ substantially.

Selection rule of thumb: Use Model Exchange when the master algorithm must tightly control integration accuracy across coupled continuous dynamics (e.g., a stiff suspension model coupled to a chassis model). Use Co-Simulation when the subsystem has its own solver, contains event-heavy or hybrid logic, or is delivered by a supplier who will not expose equations.

Co-Simulation Interfaces and the Master Algorithm

In a co-simulation, the orchestrating tool is the master (or importer), and each FMU is a slave. The master drives the loop: set inputs, call fmi2DoStep, read outputs, repeat. The FMI 2.0 API calls that matter most in practice are:

fmi2Instantiate(...)          // create instance, choose CS or ME
fmi2SetupExperiment(...)      // start time, stop time, tolerance
fmi2EnterInitializationMode(...)
fmi2SetReal / fmi2SetInteger / fmi2SetBoolean / fmi2SetString
fmi2ExitInitializationMode(...)
fmi2DoStep(commStepSize, ...) // CS only: advance by commStepSize
fmi2GetReal / fmi2GetInteger / fmi2GetBoolean / fmi2GetString
fmi2Terminate(...) / fmi2FreeInstance(...)

Two parameters dominate correctness. The communication step size is how far the master advances all slaves before exchanging data. The internal step size is how the slave's own solver subdivides that interval. If the communication step is too coarse relative to the fastest dynamics, coupling error grows and the co-simulation can go unstable even when each FMU is individually stable. A practical diagnostic is to halve the communication step and observe whether the coupled result changes materially; if it does, the step is not yet converged.

FMI 2.0 also defines input extrapolation and output interpolation order. When a slave needs an input value between communication points, the master may hold the last value (zero-order hold) or extrapolate linearly. For stiff or oscillatory couplings, zero-order hold introduces a lag that can excite numerical instability; declaring first-order extrapolation in the master configuration often stabilizes the loop.

Model Exchange Protocols and Event Handling

With Model Exchange, the FMU exposes fmi2GetContinuousStates, fmi2GetDerivatives, and fmi2SetTime. The importer's integrator evaluates derivatives at its own stages. The subtlety is event handling: ME FMUs report state events via fmi2EnterEventMode, and the master must locate the event time, handle it, and return to continuous mode. Discrete states, sample-and-hold controllers, and mode switches all generate events. If the master ignores event indicators, a controller that should switch at t = 0.25 s may switch late, producing a visible phase error in the response.

FMI 3.0 extends the standard with clocks, arrays, and a clearer separation of scheduled execution, which matters for models with periodic control tasks. When integrating a mixed toolchain, verify that all tools support the same FMI major version; an FMI 3.0 FMU cannot be loaded by an FMI 2.0-only importer.

Practical Integration: A Brake-by-Wire Co-Simulation Example

Consider a brake-by-wire study where a Simulink brake controller FMU (CS) is coupled to a vehicle dynamics FMU (CS) in a master tool. The controller outputs brake pressure demand p_dem in bar; the plant outputs vehicle speed v in m/s and wheel slip lambda.

Declare the interface. In modelDescription.xml, p_dem is an input with causality="input", variability="continuous", unit bar. v and lambda are outputs. Mismatched units are the most common silent failure — a plant expecting Pa receiving bar produces a 100000× error that looks like a modeling bug.
Set the communication step. Start at 1 ms. The controller's sample time is 5 ms, so the master must not step the controller faster than its own discrete rate without accounting for it; a 1 ms comm step with a 5 ms controller sample means the controller holds its output for five master steps, which is correct only if the FMU declares that behavior.
Run and inspect. Plot p_dem and lambda on the same time axis. A healthy result shows pressure rising smoothly and slip peaking near the friction optimum (typically 0.1–0.2 for dry asphalt) before ABS modulation.
Verify convergence. Re-run at 0.5 ms and 0.25 ms. If peak slip shifts by more than a few percent, the coupling is not converged; reduce the step or switch the master to a higher-order extrapolation.

Common failure symptoms: (1) Instant divergence at t=0 — usually a unit mismatch or an uninitialized input read before fmi2ExitInitializationMode. (2) Slow oscillation growing over time — communication step too coarse for the coupling stiffness. (3) Correct steady state but wrong transient — event handling or extrapolation order issue. (4) FMU loads but outputs stay zero — the importer is reading outputs before the first fmi2DoStep, or the variable is declared with the wrong causality.

Interface Contract Checklist

Item	What to verify	Typical defect if wrong
FMI version	FMU major version matches importer support	Load failure or silent API mismatch
Interface type	CS vs. ME matches the coupling strategy	Wrong integration ownership, unstable loop
Units	All exchanged variables carry consistent SI or declared units	Scaling errors of orders of magnitude
Causality	Inputs/outputs/parameters correctly declared	Zero outputs, ignored inputs
Communication step	Converged under step halving	Growing oscillation, wrong transient
Event indicators	ME events handled by importer	Phase error in discrete control
Initialization	Initial values set before exit initialization mode	Divergence at t=0

The engineering payoff of FMI is that the interface contract becomes explicit and testable. Once units, causality, interface type, and communication step are validated, the same FMU can be reused across master tools, CI regression runs, and supplier exchanges without rewriting glue code. The discipline is in treating modelDescription.xml and the step-size convergence check as first-class verification artifacts, not as packaging afterthoughts.