Functional Mock-up Interface
The Functional Mock-up Interface 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 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. 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 .
The FMI Standard provides three interface types for different aspects of models:
- FMI for model exchange,
- FMI for co-simulation,
- FMI for scheduled execution
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 ;
- 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 specifications are licensed under CC BY-SA CC BY-SA 4.0
- the C-header and XML-schema files that accompany this document are available under the license with the extension that modifications must also be provided under the BSD license.
Architecture
- an XML file containing among other things the definition of the variables used by the FMU;
- all the equations used by the model ;
- optional other data, such as parameter tables, user interface, documentation which may be needed by the model.
Example
modelName="ModelicaExample"
modelIdentifier="ModelicaExample_Friction">
...
valueReference="16777217"
description="Moment of inertia"
variability="parameter">
...
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.
System Structure and Parameterization (SSP)
architecture, the interfaces of the system elements, and their connections and parameterization.
The aim of SSP is to simplify the exchange and integration of system elements that are used in the
distributed development of a system to be simulated using a wide variety of tools.
SSP is being developed as a project of the Modelica Association and is based
on the FMI specification. FMI enables the exchange of individual simulation
components, while SSP enables the exchange of complete simulation systems, their variants and
parameterization. The simulation components of a simulation system described in SSP can also be
independent of FMI and map to other implementations.
SSP is extensible to support specific requirements or domain-specific extensions: e.g. OSI, documentation of requirements, traceability or process steps, etc. SSP is open with regard to the component formats. Although it was based on FMI, it can also be used with components specifications of any other format.