Skip to content

Latest commit

 

History

History
26 lines (18 loc) · 2.53 KB

1___introduction.adoc

File metadata and controls

26 lines (18 loc) · 2.53 KB

Introduction

The Functional Mock-up Interface (FMI) has gained widespread acceptance in industrial usage both at the level of users and simulation tool vendors as a mechanism for the interchange of models for integration into other environments. During the initial adoption of FMI, several problems and omissions that have hindered the realization of the full potential of FMI adoption have been identified. Many of these issues have resulted in clarifications and enhancements in the FMI 3.0 standard. However, other considerations are less normative or require more deliberated guidance, so inclusion in the standard itself was deemed unwise.

This document provides best practice recommendations to implementers of FMI, focusing on FMI 3.0, derived from the industrial experience of the Smart SE project members and the MAP FMI community in employing FMI. The overarching goal of the recommendations is to aid interoperability of FMI implementations and ensure good ease-of-use for the user in employing FMI.

This document is intended for simulation tool vendors planning to support FMI in their products, either for importing FMUs or for exporting FMUs, or both. It assumes a technical audience familiar with the specification documents and tries to give further information and hints in areas where either the relevant specification documents have been found sometimes to be less clear than expected or where user expectations are relevant to implementation choices. It also considers errors and bugs encountered in the practical use of existing FMI implementations and guides to avoid common pitfalls.

This document will be maintained and expanded over time as new issues or needs for clarification appear.

Since interoperability of implementations is of crucial concern for FMI users, guidance is, where applicable, based on the general robustness principle (also often termed Postel’s law):

Be conservative in what you do, be liberal in what you accept from others.

Note that the guidance in this document does in no way supplant the standards themselves: What is standard-compliant or not is the sole domain of the official standard documents.

This guidance only expands on the content of the standards by giving advice on how to best deal with design decisions and the realities of diverging or not fully standard-compliant implementations: Even if erroneous implementations are fixed at a later date, they will affect users in the meantime, and with generated FMUs, probably a long time after the exporters are fixed if the FMUs are not regenerated regularly.