Functional Mock-up Interface

Functional Mock-up Interface

Abbreviation	FMI
Status	Published
Year started	2010
Latest version	2.0.3 November 17, 2021 (2021-11-17)
Organization	Modelica Association Project (MAP)
Related standards	Co-simulation
Domain	Computer simulation
License	CC BY-SA-3.0
Website	FMI website

The Functional Mock-up Interface (or FMI) defines a standardized interface to be used in computer simulations to develop complex cyber-physical systems.

The vision of FMI is to support this approach: if the real product is to be assembled from a wide range of parts interacting in complex ways, each controlled by a complex set of physical laws, then it should be possible to create a virtual product that can be assembled from a set of models that each represent a combination of parts, each a model of the physical laws as well as a model of the control systems (using electronics, hydraulics, and digital software) assembled digitally. The FMI standard thus provides the means for model based development of systems and is used for example for designing functions that are driven by electronic devices inside vehicles (e.g. ESP controllers, active safety systems, combustion controllers). Activities from systems modelling, simulation, validation and test can be covered with the FMI based approach.

To create the FMI standard, a large number of software companies and research centers have worked in a cooperation project established through a European consortium that has been conducted by Dassault Systèmes under the name of MODELISAR. The MODELISAR project started in 2008 to define the FMI specifications, deliver technology studies, prove the FMI concepts through use cases elaborated by the consortium partners and enable tool vendors to build advanced prototypes or in some cases even products. The development of the FMI specifications was coordinated by Daimler AG. After the end of the MODELISAR project in 2011, FMI is managed and developed as a Modelica Association Project (MAP).

The four required FMI aspects of creating models capable of being assembled have been covered in Modelisar project:

• FMI for model exchange,
• FMI for co-simulation,
• FMI for applications,
• FMI for PLM (integration of models and related data in product life-cycle management).

In practice, the FMI implementation by a software modelling tool enables the creation of a simulation model that can be interconnected or the creation of a software library called FMU (Functional Mock-up Unit).

The FMI approach

The typical FMI approach is described in the following stages:

• a modelling environment describes a product sub-system by differential, algebraic and discrete equations with time, state and step-events. These models can be large for usage in off-line or on-line simulation or can be used in embedded control systems;
• as an alternative, an engineering tool defines the controller code for controlling a vehicle system;
• such tools generate and export the component in an FMU (Functional Mock-up Unit);
• an FMU can then be imported in another environment to be executed;
• several FMUs can – by this way – cooperate at runtime through a co-simulation environment, thanks to the FMI definitions of their interfaces.

License

The FMI specifications are distributed under open source licenses:

• the specifications are licensed under CC BY-SA (Creative Commons Attribution-Sharealike 3.0 Unported) CC BY-SA 3.0
• the C-header and XML-schema files that accompany this document are available under the BSD license with the extension that modifications must also be provided under the BSD license.

Architecture

Each FMU (Functional Mock-up Unit) is distributed in a zip file with the extension ".fmu" which contains:

• an XML file containing among other things the definition of the variables used by the FMU;
• all the equations used by the model (defined as a set of C functions);
• optional other data, such as parameter tables, user interface, documentation which may be needed by the model.

Example

Below is an example of an FMI model description issued from Modelica.

<?xml version="1.0" encoding="UTF8"?>
<fmiModelDescription
  fmiVersion="1.0"
  modelName="ModelicaExample"
  modelIdentifier="ModelicaExample_Friction">
...
  <UnitDefinitions>
     <BaseUnit unit="rad">
        <DisplayUnitDefinition displayUnit="deg" gain="23.26"/>
     </BaseUnit>
  </UnitDefinitions>
  <TypeDefinitions>
     <Type name="Modelica.SIunits.AngularVelocity">
        <RealType quantity="AngularVelocity" unit="rad/s"/>
     </Type>
  </TypeDefinitions>
  <ModelVariables>
     <ScalarVariable
        name="inertia1.J"
        valueReference="16777217"
        description="Moment of inertia"
        variability="parameter">
        <Real declaredType="Modelica.SIunits.Torque" start="1"/>
     </ScalarVariable>
...
  </ModelVariables>
</fmiModelDescription>

Comparison to Simulink S-Functions

FMI is often compared to Simulink S-Functions since both technologies can be used to integrate third-party tools together. S-Functions are used to specify a computer language description of a dynamic system. They are compiled as MEX-files that are dynamically linked into MATLAB when needed. S-Functions use a calling syntax that interacts with Simulink’s equation solvers. This interaction is similar to the interaction that takes place between built-in Simulink blocks and the solvers.

FMI proponents explain that FMI models have several advantages over Simulink S-Functions:

• S-Functions format is proprietary, whereas the FMI schema is licensed under a BSD license.
• The building blocks of S-Functions are much more complex than FMI, making it very difficult to integrate in simulators other than Simulink itself.
• Furthermore, the S-Functions format is specific to Simulink.
• S-Functions are not suited for embedded systems, due to the memory overhead of S-Functions.

There are also several limitations cited when using FMI/FMU:

• Memory - Parameters, states, inputs, and outputs are not exposed directly to the outside, which is in contrast to how ECU software is normally organized with respect to memory to allow transparency, simplicity, and efficiency.
• Event handling - Events could increase the runtime for real-time systems in an unpredictable manner.
• Potentially dangerous features can be included on ECU - Some features that make sense for offline simulations should not be present on the ECU. Examples of features that are either supported or not explicitly forbidden in the FMI include logging and I/O operations such as print().
• Data type support - More supported data types are necessary for optimized code. For example, there is not a way to distinguish between a uint8 and uint32 variable.

Accompanying standards and recommendations

In May 2014, the project group Smart Systems Engineering (SmartSE) of the ProSTEP iViP Association published its Recommendation PSI 11 for the cross-company behavior model exchange. FMI thereby is the technological basis. The PSI 11 specifies interaction scenarios, use cases, a reference process and templates, which thereby could ease the industrial application. End of 2016 the group published a movie, which should highlight the industrial benefits.

See also

• 20-sim
• Modelica
• Simulink

External links

• FMI main site