Functional Mock-up Interface

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.

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.

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

• 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.

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>

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.[3]

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

• 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:[5]

• 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.

System Structure and Parameterization (SSP)[7] is a companion standard to FMI that defines a standardized, open file format to describe complex, hierarchical (technical) systems, that can be simulated. An SSP file contains definitions for system 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. [8]

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.

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.[9] 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.[10]

• 20-sim
• Modelica
• Simulink

• FMI main site
• SSP main site