Contenido principal

Functional Mockup Interface Concepts

This page provides an overview of the Functional Mockup Interface (FMI) standard, explains the structure, benefits, and recommended use of Functional Mockup Units (FMUs), and describes the different versions and types of FMUs.

For more information about using FMUs in Simulink, see Generate and Simulate Standalone FMU in Simulink.

Functional Mockup Interface

Functional Mockup Interface (FMI) is a standard that defines the semantics for a container and interface that can be used to exchange and co-simulate dynamic system components across simulation environments and tools. The standard enables you to generate standalone tool-agnostic packages containing dynamic system component information in standardized XML files, compiled binaries, and C code. The package is distributed as ZIP file.

The FMI standard specifies two versions of compatibility for the packages. FMI 2.0 defines a standard for exchanging dynamic models using XML-based model descriptions and compiled C code packaged as FMUs. FMI 3.0 extends the standard with features such as scheduled execution for real-time and embedded systems, binary variable types for efficient data handling, and improved support for hybrid models with discrete events. FMI 3.0 also introduces standardized interfaces for clocks and more flexible communication between FMUs.

For more information about FMI standard, see Functional Mockup Interface.

Functional Mockup Unit

The package generated using the FMI standard is called a Functional Mockup Unit (FMU). Use FMUs as part of your large-scale modeling and simulation workflow to enable sharing and simulation of component across models and tools. An FMU package is:

  • Tool-agnostic and ready to run across simulation platforms.

  • Independent of a specific release of software that the package is generated or used in, enabling cross-release component sharing.

  • Compatible with a diverse set of toolchains and software packages.

  • Faster in compilation because of precompiled binaries that are only loaded at runtime.

The general file structure of an FMU is defined as:

MyModel.fmu
├── modelDescription.xml        # Mandatory: Describes the model interface
├── binaries/                   # Contains compiled binaries (DLLs, shared libs)
│   └── <platform>/             # Platform-specific folders
│       └── <model>.dll         # The actual binary for the FMU
├── sources/                    # Optional: Source code
│   └── *.c, *.h                # C source and header files
├── resources/                  # Optional: Additional resources (e.g., images, data files)
│   └── <user-defined files>    # Any files needed by the FMU
└── documentation/              # Optional: Documentation files
    └── *.pdf, *.html, *.txt    # User manuals, diagrams, etc.

FMU Types: Co-Simulation and Model Exchange

The FMI standards support two main types of FMU:

  • Co-Simulation FMU: The FMU package contains model information and the solver for simulation.

  • Model Exchange FMU: The FMU contains only model information, and the importing tool solves the equations.

A Model Exchange FMU provides the mathematical description of a system, such as differential and algebraic equations, but does not include a solver. The importing tool integrates these equations during simulation. A Co-Simulation FMU contains both the model and its own solver, allowing it to advance its internal state independently. The importing tool coordinates the simulation by exchanging data with the FMU at defined communication points, but does not solve the model equations itself.

This distinction affects how simulation time, accuracy, and tool interoperability are managed. In general, Model Exchange FMUs offer higher simulation fidelity for a tightly coupled system because they use the solver of the importing tool for integration. Co-Simulation FMUs are more suitable for integrating and simulating heterogeneous systems, as each FMU runs independently with its own solver. The simulation fidelity of a Co-Simulation FMU depends on the its communication step size.

FeatureModel ExchangeCo-Simulation
SolverDoes not include solverIncludes solver
Simulation fidelityHigh for tightly coupled systems; uses the solver of the importing tool for integrationDependent on communication step size; suitable for heterogeneous system simulation.
Execution and simulation controlImporting tool controls time stepping and integrationFMU controls its own execution; importer coordinates data exchange
PortabilityDependent on the importing toolHigh, as solver is contained in the package
FlexibilityMore flexible; solver settings can be tunedLess flexible; solver settings are fixed

See Also

Topics