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, Appendix F IP Protection of the prostep ivip SmartSE Recommendation V2 [SMARTSEV2]).