FMI Standard: Understand the two types of Functional Mock-up Units – CS v. ME

What is FMI?

The Functional Mock-up Interface (FMI) is a tool-independent standard used for model exchange and co-simulation of dynamic systems. It enables different simulation tools to integrate seamlessly, promoting interoperability and model reuse. 

As an expert in the standard it’s my goal to help users understand the commonalities and differences – getting you to a point in which you’re choosing the best possible technique to achieve your goal! Let’s first look at what the two kinds of FMUs have in common.

If the FMI standard is brand new to you, you may want to start here: What is FMI?

Functional Mock-up Unit Types

The FMI standard supports two types of Functional Mock-up Units (FMUs): Co-Simulation (CS) and Model Exchange (ME). While both are widely used, their differences often cause confusion. Let’s break down their similarities first before exploring what sets them apart.

What are the similarities?

Despite their names, both Model Exchange (ME) and Co-Simulation (CS) FMUs can be used for exchanging models and simulating multiple models together. More specifically

1. Both are packaged as files with the extension .fmu

2. Both represent dynamic systems with inputs, outputs, parameters, and variables

3. Both can be simulated to compute system state over time

4. Both support model exchange (exporting from one tool, importing into another)

5. Both support co-simulation (running multiple models together)

So, if they share so much in common…what’s the difference?

What are the differences?

The key distinction lies in how the importing tool advances the FMU in time.

Models that represent physical quantities such as temperature or velocity are generally described by differential equations. The way that the quantities change with time depend on the value of the quantities themselves (the state), and what external influence they are subjected to (the inputs).

Let’s take the following example: A very simple mathematical model for how the temperature of a house evolves can be written as:

dThouse/dt = k1*(Tout-Thouse) k2*BoilerPower k3

Here, the rate of change of the quantity (dThouse/dt) depends on the state (Thouse) and the inputs (Tout and BoilerPower). k1, k2, and k3 are parameters that do not change with time. To compute how the temperature in the house changes with time, the differential equation needs to be hooked up to a numerical solver.

When you simulate a CS FMU, the numerical solver is embedded and supplied by the exporting tool. The importing tool will set the inputs, tell the FMU to step forward a given time, and then read the outputs.

When you simulate an ME FMU, the numerical solver is supplied by the importing tool. The FMU provides functions to set the state and inputs, and to compute the state derivatives (i.e., the left hand side of the equation). The solver in the importing tool will determine what time steps to use, and how to compute the state at the next time step.

Model Exchange

Co-Simulation

Based on the FMI 2.0 standard, an FMU may be both an CS and ME FMU. That means that it provides both the ME functions that can be hooked up to a solver in the importing tool, and an internal solver if you choose to use the FMU as CS.

Functional Mock-up Unit: Which should I use?

This is a question that I get asked all the time. And the answer is: it depends. To understand the pros and cons of the two types, I like to compare to vector and bitmap graphics.

• CS is more like bitmap graphics (like .jpg or .png). The rendering is mainly determined by the exporting tool. You can extract data at a grid of points but not continuously. The solver settings can sometimes be changed through parameters in the FMU, but you cannot change to a different solver.
• ME is the equivalent of vector graphics (like .svg or .eps); it provides functions that directly access the underlying mathematical model and can be manipulated by the importing tool in a way that is adapted to the context where it is to be used. Zooming in or interpolating? No problem.

Does that mean that you should always use ME? No. Just like you don’t always use vector graphics formats. Some reasons to choose CS include:

• Not all tools support both types. Support for CS is more common than for ME.
• The numerics of the model may need a specific solver that is available in the exporting tool but not in the importing one.
• The FMU may represent a sampled data system (such as signal processing or control algorithms), that is not governed by differential equations and thus more naturally represented as a CS FMU.
• The exporting tool may have a more efficient implementation of the solver in terms of memory usage, execution time, etc.

A general guideline could be to try and see if ME works. If you work with “simple” models (small, linear, non-stiff), ME is often an excellent choice because it allows more flexibility. If you have models that take in the order of minutes or more to simulate (even in native tools with specialized solvers) ME could likely be challenging and you should consider CS instead.

Check with tool vendors for both importing and exporting tools in your intended tool chain to see what options are available. An overview for different tools is available here.

Learn more…

Modelon Deployment Suite: Learn about Modelon’s comprehensive suite of deployment products, designed to rapidly deploy system models across multiple platforms, varying tools, and organizations.

Training: Check out our one-day FMI course! Find a scheduled training session or talk to us about giving it on-site for your whole team.