online calibration of control code, and
addition of the new interface type "Scheduled Execution" (see Section 5) that allows activation of individual model partitions (or tasks)
by an external scheduler, e.g. on real-time platforms.
A second need of the simulation community was address by introducing the more advanced co-simulation interface type FMI for Co-
Simulation. New features, like
early return from a fmi3DoStep call,
the intermediate update, or
Clocks and clocked variables,
allow implementation of more robust and efficient co-simulation algorithms to handle the growing system simulations the community is
facing.
Parallel to the new standard features, the FMI Design Community has worked on improving the standard quality by:
modernizing the development methodology (e.g. moving to github) and a text-based source format,
publishing the FMI Standard now primarily as html to support easier navigation within the document and viewing on a wider range of
devices,
supplying a large set of continuously validated Reference FMUs, and
integrating within the FMI Standard only validated C-code, XML and XSD snippets to reduce redundancy and ensure correctness.
While a number of desirable features had to be postponed, the resulting FMI 3.0 is certainly a significant step forward towards meeting
the most important requirements of the system simulation community for the years to come.
The asynchronous mode for FMUs known from FMI 2.0 has been removed since this mode was not supported by tools and it can be
suitably replaced by Co-Simulation implementations that control the asynchronous computation of FMUs via separate tasks/threads
created for each FMU.
1.2. Overview
The Functional Mock-up Interface (FMI) defines a container and an aplication programming interface (API) to exchange dynamic models
using a combination of XML files, binaries and C code, distributed as a ZIP archive, the Functional Mock-up Unit (FMU). The API is used
by a simulation environment, the importer, to create one or more instances of an FMU and to simulate them, typically together with
other models. The FMI defines three interface types:
Co-Simulation (CS) where the FMU contains its own solver,
Model Exchange (ME) that requires the importer to perform numerical integration, and
Scheduled Execution (SE) where the importer triggers the execution of the model partitions.
This document does not describe how to generate an FMU from a modeling environment.
The interface types have large parts in common, defined in Common Concepts. In particular:
FMI Application Programming Interface (C) — Section 2.2
All required equations or tool coupling computations are evaluated by calling standardized C functions. C is used because it is the
most portable programming language today and is the only programming language that can be utilized in all embedded control
systems.
FMI Description Schema (XML) — Section 2.4
The schema defines the structure and content of an XML file generated by a modeling environment. This XML file contains the
definition of all variables of the FMU in a standardized way. It is then possible to run the C code in an embedded system without the
overhead of the variable definition (the alternative would be to store this information in the C code and access it via function calls, but
this is neither practical for embedded systems nor for large models). Furthermore, the variable definition is a complex data structure