FMI 3.0 Implementers' Guide

When planning on which versions of FMI to support in your implementation, support for the newest FMI version (currently FMI 3.0) is, of course, highly recommended.

It should be noted that there is no cross-version compatibility between major versions of FMI.

The life cycles of both simulation environments and generated FMUs can wildly differ and span many years in development projects. Therefore support for both legacy FMU integration and generation of legacy FMUs is crucial for flexible interoperation in development projects.

Currently, this means that support for the very widely supported FMI version 2.0 should be strongly considered. Similarly, support for the integration of FMUs using different FMI versions should also be strongly considered.

For FMI 1.0/2.0 and 3.0 interoperability the bridging between the different variable types of 1.0/2.0 and 3.0 and the handling of arrays needs to be taken into account. In projects that employ the SSP standard, the variant handling facilities of SSP can be used to package multiple versions of an FMU into one package.

When bugfix releases of the FMI standard become available, implementations should take these into account in a timely fashion to react to detected clarifications in the standard.

Generally, implementations should support all applicable FMI interface types: For FMI 3.0, this includes the Model Exchange, Co-Simulation, and Scheduled Execution interface types.

There are inherent trade-offs in the properties of interface types in terms of complexity, numerical accuracy, performance, ease-of-use, and reproducibility of results. For this reason, often not just one interface type is appropriate for the export of a given FMU.

FMI provides the ability to package multiple interface types in one FMU, allowing importers and users to select an appropriate interface type at the point of use. This also enables importers to fall back to a different interface type if an interface type is not supported or is not beneficial for the current use case.

Especially for a more specialized or complex interface type, like Scheduled Execution, which is only relevant in some use cases, implementing other interface types as a fallback is recommended.

There are, of course, cases where the generation of only certain interface types makes sense: For example, for FMUs generated from ECU software, the model exchange interface type is likely not sensible or possible to generate.

Importing implementations should usually support all interface types. Mixing FMUs with different interface types in one model or project should also be supported unless technical considerations make this impossible or not useful.

The FMI standard provides many optional features. These features are optional since support is not uniformly required for all use cases. However, for certain use cases, some optional features are often critically important. Therefore broad support for optional features is required to achieve acceptable simulation performance for a broad range of use cases.

The Modelica Association Project FMI and the prostep ivip SmartSE project provide a joint publication on FMI Feature Profiles, which gives use-case-based guidance on required and recommended optional features. The goal of this document is a more straightforward agreement between tool vendors and users on the required features for specific use cases.

This document can be found on the FMI standard homepage at https://fmi-standard.org/ and should be taken into account, among other considerations, when defining feature support for implementations.

All implementers are advised to participate widely in the FMI Cross-Checking Initiative to test compatibility with current implementations of other tools. Robust participation, including testing with a relevant selection of available releases, is recommended.

FMU exporting implementations should also use the FMU Compliance Checker [FMUCC] and VDMCheck [VDMCheck] to do basic validation of generated FMUs.

FMU importing implementations should make use of the Reference FMUs [RefFMUs] to do basic validation of FMU import.

Implementers should test FMU integration with complex test cases, including the behavior of multiple connected FMUs with actual and pseudo algebraic loops, iteration during initialization, handling of structured naming, handling of Unicode characters inside and outside the basic multilingual plane, license handling, etc.

If generated FMUs require licenses to run (FMU runtime licenses), the mechanism needed to supply these licenses to the FMU needs to be documented, ideally included in the FMU documentation.

The license handling should be tested widely as part of cross-implementation checks to ensure that the license handling works correctly in varied circumstances.

If an error or problem occurs in the license handling, e.g., a missing license, an informative message should be provided to the user through the FMU logging callback mechanism. This allows importing implementations to provide proper feedback to the user.

Exchange of FMUs can be eased tremendously if an option exists to generate FMUs that do not require license mechanisms at the receiving party.

If license mechanisms are used for IP protection, alternative approaches can be useful to consider (see, for example, Part D IP Protection of the prostep ivip SmartSE Recommendation 2022 PSI 11 V3.0 [SMARTSEV3]).

Common platforms in use today are available in 32bit and 64bit variants, for example Windows or Linux on Intel processors, or Linux ARM processors.

While these variants are usually closely related, and 64bit variants commonly support running 32bit and 64bit binaries side-by-side, this support is limited: Most platforms do not support running 32bit and 64bit inside one process image, but only in separate processes.

Since FMI is designed around the ability to run FMUs inside the host implementation process image for efficiency, this means that 32bit and 64bit variants of the same platform are usually not directly compatible.

For this reason exporting implementations should ideally generate FMUs that contain both 32bit and 64bit variants of the binaries, allowing importers to select an appropriate binary.

Since not all exporting implementations can generate both variants easily, importing implementations should consider providing the ability to bridge between 32bit and 64bit implementations, using either inter-process communication or system provided facilities where possible.

Going forward, this is likely to be less of a problem on desktop systems, which are migrating to 64bit only implementation spaces. For mobile or embedded platforms, this issue is likely to be still pertinent for some time.

FMU exporting implementations should strive to support common platforms out of the box. They should provide support for generating FMUs that contain multiple binary implementations, and where feasible, a source code implementation in one go.

Exporting implementations should document supported compilers, their versions, and required compiler flags and settings to compile generated source FMUs for common platforms.

For FMI 3.0, the languages, compilers and required compiler flags and settings should be placed in the buildDescription.xml file of the FMU to allow automated building from source as far as possible. The following are lists of commonly agreed upon names for languages and compilers, that should be used if no other values are more appropriate:

When generating binary FMUs directly, the supported and used compilers, compiler flags, and settings should also be documented. This allows users to troubleshoot integration issues when integrating binary FMUs into other environments.

Where possible, user-supplied compilers, compiler flags, and settings should be supported to automate the generation of binary FMUs for non-common targets or to support user-specific requirements in the binary FMU compilation/linking stage.

Importing implementations should correctly handle the import of multiple FMI 1.0 FMUs with identical model identifiers. In the case of FMUs with dynamic library implementations, this is supported by most platforms since symbol lookup can be performed scoped to one dynamic library namespace (see, for example, the dlsym and GetProcAddr functions for Linux and Windows, respectively).

Starting with FMI 2.0, FMUs with dynamic library implementations will always use identical symbols for the entry points in any case, so that this has to be supported correctly.

For source code or static library implementations, the problem of conflicting model identifiers can usually only be solved through compilation/linking to corresponding separate dynamic libraries or other similar mechanisms to deal with the relevant scoping issues.

For source code FMUs in FMI 3.0, the actual prefix that is used for the entry points is controlled through the mechanisms of the fmi3Functions.h header in the following way:

As the actual function symbols generated for an FMU are dependent on the implementation and its supplied fmi3Functions.h header any any other predefined preprocessor macros, FMU exporters must ensure that they only refer to the FMI API entry-points via the names generated from the fmi3Functions.h mechanisms. In other words, any references in the exported source code should be amenable to preprocessor expansion.

For FMI 2.0 source code FMUs a similar approach can be used, however there are fewer guarantees on pre-defined preprocessor macros, since this area was only clarified in later patch releases of 2.0.

Importing implementations should consider changing the working directory of the process to the relevant binary subdirectory of the unpacked FMU when loading the FMU dynamic library. This is to allow unsophisticated exporting implementations to load dependent dynamic libraries relative to this directory. It is, of course, the responsibility of the FMU to implement proper dependent dynamic library loading regardless of the current working directory of the process. However, in practice, a number of current or former implementations did not correctly implement this. They can thus fail to load when the current directory is not the directory that contains the FMU dynamic library.

Exporting implementations should ideally avoid reliance on additional dynamic libraries: Generated dynamic libraries should ideally be stand-alone.

Where this is not feasible, implementations should prefer to use manual dynamic loading of dependent libraries at runtime (for example, using dlopen or LoadLibrary). The load path of the libraries should be based on the path to the resources folder provided. When the resources path is not available (for example, in FMI 1.0 ME) or not valid, an implementation can use dynamic library-relative path derivation, either against the binary folder or the resources folder.

Relying on pre-linking, where the dynamic loading of the dependent libraries is automatically handled by the platform dynamic linker/loader, is not likely to work in all cases: For example, on Windows, the searched paths will be based on the location of the importer executable, not the location of the FMU DLL. Furthermore, in case of failure, automatic linking is unlikely to provide user-understandable error messages.

Note that simple calls to LoadLibrary or LoadLibraryEx on Windows, without specifying the full path to the library are also not going to work in general, for the same reasons: The search path will be based on the location of the importer executable and not the FMU DLL.

Importers should consider using flags like RTLD_LOCAL on POSIX platforms with dlopen, to avoid symbols from loaded shared objects being resolved against other loaded shared objects (i.e. other FMUs) by accident.

Note that for POSIX platforms, like Linux, dlclose is not required to unload a shared object, but it can, as specified in IEEE Std 1003.1-2017 (and earlier). In particular, shared objects compiled with GCC without the flag -fno-gnu-unique, can be marked as unloadable, and thus will not generally be unloaded upon dlclose. In many instances shared objects loaded with RTLD_GLOBAL cannot unload until all relocations of other objects to symbols in the shared object have been unloaded.

The FMU code will run in the process environment that the importer provides. This might be the same process as the importer, or it might be a separate process or processes. The FMU code cannot make any assumptions on this, but must rather be conservative in its behavior in the face of this.

Importing implementations should support the processing of physical unit information when present on the variables of an imported FMU, including support for unit consistency checks and optional automatic unit conversions, especially when FMI 2.0/3.0 SI-based unit information is available.

The unit information should be overridable by the user to account for exceptional circumstances: For example, when erroneous unit information on a variable has to be manually adjusted since changes to the FMU are not otherwise practicable.

Exporting implementations should generate physical unit information on all exported variables when such information is available in the model (or can be automatically derived).

On FMI 2.0 and later versions, the support for SI-based units, using the BaseUnit element should be used. This enables a number of important use cases:

Importing implementations should support the processing of min/max limit information when present on the variables of an imported FMU. This support should include support for limit consistency checks and optional runtime checking.

The limit information should be overridable by the user to account for exceptional circumstances: For example, when erroneous limits on a variable have to be manually adjusted since changes to the FMU are not otherwise practicable.

Exporting implementations should generate min/max limit information on all exported variables that support this information in FMI when such limit information is available in the model (or can be automatically derived). Ideally, it should be possible to generate FMUs that optionally check the limits (especially user-supplied limits) at runtime and produce suitable errors and diagnostic logging information when limits are breached.

Implementations are well-advised to heed the explanations in section 2.2.6.3 of the FMI 3.0 standard when implementing min/max checking and handling routines.

Importing and exporting implementations should support the structured naming convention for variables specified in the FMI standards to support the interchange of array/matrix and record/struct information.

Starting with FMI 3.0, FMI also supports array variables directly (called native arrays in the following discussion), i.e. without needing to use scalar variables and the structured naming convention. Hence, for FMI 3.0, implementations should support both native arrays and the structured naming convention. This support should include support for bridging between these two ways of expressing arrays, especially when supporting older versions of FMI as well as FMI 3.0. When exporting arrays, preference should be given to native arrays over structured naming convention mappings.

Importing implementations should map complex interfaces expressed via the structured naming convention to suitable internal data structures and formats, like vectors/arrays, records/structs, or busses.

Exporting implementations should map their internal data structures to suitable FMI structured names, mapping vectors to arrays, and records/structs or busses to hierarchical names.

If an implementation supports importing as well as exporting FMUs, the mapping of data structures should allow for efficient round-tripping: It should be possible to export (part of) a model as an FMU with complex data structures at its interface and have that FMU use structured naming in such a way that the resulting FMU can be imported into the same tool and support the same native interface.

Parameter editors and similar editing UIs and APIs should efficiently support complex data types so that a multi-dimensional array can be efficiently edited, both in terms of speed and user interface.

Exporting complex data structures through the structured naming convention can easily lead to 10,000 or more scalar variables. Implementations should therefore be prepared to deal with FMUs containing very many scalar variables efficiently.

In order to generate FMUs that are easily handled and also to guard against exposing too many internal details (for both IP protection reasons and reasons of clarity of interfaces), exporting implementations should allow the user to efficiently select which parameters or variables are to be exposed in the FMU as parameters and variables, and which should be kept hidden.

In the case of state variables, this must be done in accordance with the requirements of the standards: Certain state variables always have to be exposed in Model Exchange FMUs.

Importing implementations must pass valid values into the following instantiation calls for all of their arguments:

Note especially that null pointers are not valid for any of the string arguments to these functions, unless explicitly allowed in the respective standard. Implementations must pass proper values especially for the following fields:

If an importer tries to create a second instance of an FMU where the capability flag canBeInstantiatedOnlyOncePerProcess is true, the FMU should provide an error message and return NULL.

Exporting implementations should guard (by safely handling these cases without crashing) against common errors in calls to the instantiation functions, including:

When performing initialization of variable values, including parameters and initial values for other variables, importers should not rely on default values being already set in the FMU (i.e. burned into the binary so to speak): While the FMI standards specify that default values shall both be specified in the modelDescription.xml file and are already set in the FMU upon instantiation, some implementations generate FMUs where this is not true, i.e. the default values of variables when not set do not match the values as specified in the modelDescription.xml file. Since there is little effort in actually setting default values through the FMI API at initialization time, the more conservative approach is to always set default values through the API based on the modelDescription.xml file, or on the actual parameter/initial values as specified by the user, not relying on any burned-in default values.

Exporting implementations must ensure that any default values specified for variables in the modelDescription.xml file are actually “burned-in”: The values shall be set automatically as default values upon FMU instantiation, so that importing implementations can rely on the standard-mandated behavior that unset variables have their default values as specified in the modelDescription.xml.

Note that for all start values, especially the mandatory start values for input and parameter variables, it is the responsibility of the FMU — and hence the exporter or the user of the exporter — to provide suitable start values: An importer should be able to rely on these start values, i.e. it is always at liberty to use them unchanged, if no better start values are available to the importer.

If an FMU provides start values that e.g. result in a division-by-zero or some other error inside the FMU if unchanged, these are obviously not suitable start values, and should not have been selected.

Importers should however be aware of the existence of such FMUs, which can easily result from negligence during creation of an FMU: Importers should, if more suitable start values are available, set them at the earliest permissible point in time, to avoid uneccesarily triggering such errors in the FMU. For FMI 2.0/3.0, for example, different start values for inputs and parameters can and should already be set after instantiation, prior to entering initialization mode.

Importers should respect the different order of necessary function calls between FMI 1.0 and FMI 2.0/3.0 when performing initialization (this phase has seen larger changes between FMI 1.0 and 2.0/3.0 due to the introduction of explicit phases/modes in the FMI API, whereas these phases where only implicit in FMI 1.0).

For FMI 1.0 Co-Simulation FMUs importing implementations should honor the canHandleEvents capability of the FMU: If this capability flag is false, then the implementation cannot call the doStep function with zero communicationStepSize, even at time 0 (used e.g. for generating valid initial values). In these cases the integration environment must start simulation with the first simulation step, without any event iteration. With FMI 2.0 Co-Simulation FMUs do not support 0-size time steps in any case. With FMI 3.0, Co-Simulation FMUs can support event handling explicitly via the hasEventMode capability flag. Importers can make use of this feature by passing fmi3True for the eventModeUsed argument of the fmi3InstantiateCoSimulation call.

Importing implementations should support a wide variety of solver algorithms, in order to support Model-Exchange FMUs as fully as possible. Ideally this should include support for attaching external solvers through specified APIs, so that experienced users can extend the supported solver base for specific new domains where appropriate. Supporting the use of several different solvers in one model that integrates a number of FMUs, so that e.g. different Model Exchange FMUs can be solved through different solvers than other parts of the model – without resorting to Co-Simulation FMUs – can be beneficial in terms of performance and usability.

In any case the proper documentation of the employed solver algorithms and their configurable settings is very beneficial in understanding and handling differences between implementations.

Exporting implementations should offer all of their built-in solver algorithms (including solver settings like step-size, tolerance, etc.) for export when generating Co-Simulation FMUs, so that the same solvers can be used inside the environment as in exported FMUs. This should ideally also include the ability to export Co-Simulation FMUs using user-supplied solvers, where appropriate (e.g. where the environment supports the integration of external solvers for model evaluation).

Importing implementations should support mixing FMUs of different types (and different FMI versions) in one simulation model, ensuring proper semantics for connections between those FMUs and each other as well as the rest of the simulation model. This should also be checked in cross-checking with other implementations.

As a side issue, importing implementations should try to use as much of the fine-grained direct dependency information potentially present in FMI 1.0 (and even more so in FMI 2.0/3.0) as possible, in order to avoid algorithmic loops being detected where they are not really present.

Importing implementations should allow fine-grained selection of FMU logging output recording/display, either based on the new FMU-defined logging categories for FMI 2.0/3.0 or on the raw string category argument of the logging callback in FMI 1.0.

Note that since the logging callback type signature in FMI 1.0 and 2.0 uses a variable argument list, this can have implications for the calling convention of that function on platforms that have different calling conventions for C functions with variable argument lists than for functions with fixed argument lists.

Starting with FMI 3.0, the logging callback uses a fixed argument list.

Exporting implementations should support the fine-grained selection of logging categories in FMI 2.0/3.0 and should use fine-grained category names in the category argument for FMI 1.0 logging callback calls.

In FMI 1.0 they should try to not produce verbose logging output when the debug logging flag is fmiFalse.

FMI 2.0/3.0 provide comprehensive information about the structure of a model encapsulated as an FMU, as defined in the element ModelStructure of the modelDescription.xml.

This element defines the dependencies between variables, both during initialization as well as at runtime, which may differ.

The following examples demonstrate in more detail how this information can be understood and used.

Starting with FMI 3.0, co-simulation FMUs can optionally support early return from fmi3DoStep calls to allow more timely handling of internal events.

This capability can be used stand-alone, or in combination with Event-Handling in Co-Simulation, as described below.

An FMU indicates its early return capability through the mightReturnEarlyFromDoStep and canReturnEarlyAfterIntermediateUpdate capability flags in its modelDescription.xml file. Here mightReturnEarlyFromDoStep indicates the FMUs capability to return early on its own volition, whereas canReturnEarlyAfterIntermediateUpdate additionally indicates the FMUs capability to be forced by the importer to return early during intermediate update callbacks.

An importer indicates that it wants to use this capability by passing in fmi3True for the earlyReturnAllowed argument in the call to fmi3InstantiateCoSimulation.

An FMU can then return early from a call to fmi3DoStep, i.e. prior to fully completing its step to the full communication step, by setting the earlyReturn argument to fmi3True, and lastSuccesfulTime to the exact time the FMU computed up to, prior to returning from fmi3DoStep.

This allows an FMU to e.g. signal an internal event has occurred that the importer should take note of.

Note that if the FMU is used without external event handling enabled, any events will still be handled completely internally, and the early return is just used to give the importer a chance to take note of the event. If early return capability is used in conjunction with external event handling, as described in Section 6.2 below, then events are not only signalled but also need to be handled by the importer if so indicated by the FMU.

Starting with FMI 3.0, co-simulation FMUs can optionally support external event-handling, i.e. notifying the co-simulation algorithm of the importer about events, which the importer then handles by putting the FMU into event mode, where event iteration can take place. This is similar to the way model exchange has always supported external event handling.

An FMU indicates this capability through the hasEventMode capability flag in its modelDescription.xml file. An importer indicates that it wants to use this capability by passing in fmi3True for the eventModeUsed argument in the call to fmi3InstantiateCoSimulation.

The FMU then indicates that event handling is needed by setting the eventHandlingNeeded argument to fmi3True in the call to fmi3DoStep prior to returning.

Note that this can interact with Early Return in the following way: If an FMU supports early return, and the importer has signaled support for early return (through earlyReturnAllowed), then if an event occurs prior to the end of the communication step, the FMU would return early with both earlyReturn and eventHandlingNeeded arguments set to fmi3True, and lastSuccesfulTime giving the exact time of the event.

If however an FMU either does not support early return, or is instantiated with earlyReturnAllowed set to fmi3False, then even if an event occurs prior to the end of the communication step, the FMU must continue to the end of the communication step. It will indicate the event as usual through eventHandlingNeeded being set to fmi3True, and will have to expect the importer to enter event mode as usual. However the exact point in time when the event occured will have already passed, and is not available to the importer. This might require at least mitigative internal event handling by the FMU itself.

For this reason it is usually recommended to use event handling support and early return capabilities together, both for exporters and importers, as this will give the best event handling control.

Since the initial release, the FMI API provides a function of the FMU that the integrator is supposed to call at the end of every completed step.

However the exact semantics, capability flags, and rules when to call this function vary between all major releases of FMI:

Note especially that the name and logic of the capability flag controlling whether an importing implementation needs to call the function is changed between 2.0 and 3.0: Whereas in 1.0 the function must be called unconditionally, in 2.0 the function must be called unless the FMU actively disables this through the completedIntegratorStepNotNeeded capability flag, and in 3.0 the function must only be called if the FMU actively requests this through the needsCompletedIntegratorStep capability flag.

Implementers migrating between releases or supporting new ones should take this into account.

The scheduled execution interface type is intended for use cases, where the ability to directly control the scheduling of internal time partitions of multiple FMUs from the outside is considered necessary.

Note that in cases where the actual direct control of the runtime of internal time partitions is not required, the use of clocked co-simulation or model exchange interface types may be more appropriate.

In scheduled execution clocks must be assigned priority information through the priority attribute on the clock variable.

A clock’s priority information is required to support the scheduled execution of several model partitions, especially in a preemptive scheduling regime.

The clock priorities are local to an FMU. It is not possible for an exporting tool to know in advance the priorities of other FMUs that will be connected to an FMU in a simulation setup. It is the responsibility of the importer to derive a computational order for the computation of two or more distinct FMUs based on the local FMU clock priorities and input-output relationships of connected FMUs.

For periodic clocks it is recommended to derive the priorities based on a rate-monotonic scheduling scheme (smallest period leads to highest priority, that is, has the smallest priority value).

Although the priority attribute is defined as 32-bit unsigned integer type, in case this is mapped by implementations directly to target platform priority levels, it is recommended to restrict the number of distinct priority levels for an FMU to the available priority levels on the target platform. A common number of different priority levels is, e.g., 100 (0 to 99), as defined in Linux-based operating systems.

To support safe preemptive scheduling of model partitions in scheduled execution, FMI 3.0 provides the callbacks fmi3LockPreemptionCallback and fmi3UnlockPreemptionCallback so that FMUs can guard critical sections of its code against preemption.

An FMU’s code has to be prepared to correctly handle preemption of

among others.

In general this means that the FMU’s code has to secure access to its global states and variables wherever data inconsistencies due to potential preemptions are anticipated.

Note that in order to avoid data inconsistencies and safeguard predictable and deadlock-free behavior with fmi3Get{VariableType} and fmi3Set{VariableType} a unique assignment of variables to model partitions via its associated clock is strongly recommended. If every variable is assigned uniquely to a model partition it is usually not necessary to use preemption locks in the context of fmi3Get{VariableType} and fmi3Set{VariableType}:

The following example illustrates why every variable should be assigned uniquely to one model partition via its associated clock:

Similarly, for fmi3GetClock the FMU has to ensure that the active state of an output clock is securely reset and cannot be observed twice for the same clock tick in case this call is preempted.

For fmi3GetIntervalDecimal the FMU has to ensure that the countdown clock’s interval qualifier is reset to fmi3IntervalUnchanged and cannot be observed twice for the same clock tick in case this call is preempted.

Depending on their implementation, fmi3CallbackLockPreemption and fmi3CallbackUnlockPreemption have a non-negligible overhead, as well as a strong impact on the scheduler and therefore their use should be as rare and short as possible.

In general, it is recommended to reduce dependencies between different model partitions of one FMU by design. One may also consider if the code can be preempted by other parts of the same FMU: E.g. a model partition cannot be interrupted if it is the only model partition or if it holds the highest priority. Similarly, a model partition, while it might be interrupted, might not need to guard data accesses if it is the only model partition of the FMU, or the one with the highest priority. In such cases no locks may be necessary.

FMI 3.0 provides optional access to partial derivatives for variables of an FMU. Partial derivatives can be used:

To avoid expensive numeric approximations of these derivatives, FMI offers dedicated functions to retrieve partial derivatives for variables of an FMU:

with the Jacobian

where \(\mathbf{v}_{\mathit{known}}\) are the \(n\) knowns, and \(\mathbf{g}\) are the \(m\) functions to calculate the \(m\) unknown variables \(\mathbf{v}_{\mathit{unknwon}}\) from the knowns.

The functions can be used to compute Jacobian-vector products or to construct the partial derivative matrices column-wise or row-wise by choosing the seed vector \(\mathbf{v}_{\mathit{seed}} \in \mathbb{R}^n\) or \(\mathbf{\bar{v}}_{\mathit{seed}} \in \mathbb{R}^m\), respectively, accordingly.

For information on the call signature see the FMI specification.