Functional Mockup Interface 2.0: the Standard for Tool Independent Exchange of Simulation Models

Functional Mockup Interface 2.0: The Standard for Tool independent Exchange of Simulation Models

Blochwitz, Torsten; Otter, Martin; Åkesson, Johan; Arnold, Martin; Clauss, Christoph; Elmqvist, Hilding; Friedrich, Markus; Junghanns, Andreas; Mauss, Jakob; Neumerkel, Dietmar; Olsson, Hans; Viel, Antoine Published in: Proceedings of the 9th International Modelica Conference

DOI: 10.3384/ecp12076173

2012

Link to publication

Citation for published version (APA): Blochwitz, T., Otter, M., Åkesson, J., Arnold, M., Clauss, C., Elmqvist, H., Friedrich, M., Junghanns, A., Mauss, J., Neumerkel, D., Olsson, H., & Viel, A. (2012). Functional Mockup Interface 2.0: The Standard for Tool independent Exchange of Simulation Models. In Proceedings of the 9th International Modelica Conference (pp. 173-184). The Modelica Association. https://doi.org/10.3384/ecp12076173 Total number of authors: 12

General rights Unless other specific re-use rights are stated the following general rights apply: Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal

Read more about Creative commons licenses: https://creativecommons.org/licenses/ Take down policy If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. LUND UNIVERSITY

PO Box 117 221 00 Lund +46 46-222 00 00

Download date: 27. Sep. 2021 Functional Mockup Interface 2.0: The Standard for Tool independent Exchange of Simulation Models

T. Blochwitz1, M. Otter2, J. Akesson3, M. Arnold4, C. Clauß5, H. Elmqvist6 M. Friedrich7, A. Junghanns8, J. Mauss8, D. Neumerkel9, H. Olsson6,, A. Viel10 Germany: 1ITI GmbH, Dresden; 2DLR Oberpfaffenhofen; 4University of Halle, 5Fraunhofer IIS EAS, Dresden; 7SIMPACK, Gilching; 8QTronic, Berlin;9Daimler AG, Stuttgart; Sweden: 6Dassault Systèmes, Lund; 3Modelon, Lund; France: 10LMS Imagine, Roanne

Abstract

The Functional Mockup Interface (FMI) is a tool independent standard for the exchange of dynamic models and for Co-Simulation. The first version, FMI 1.0, was published in 2010. Already more than Figure 1: Improving model-based design between OEM and 30 tools support FMI 1.0. In this paper an overview supplier with FMI. about the upcoming version 2.0 of FMI is given that combines the formerly separated interfaces for Mod- The MODELISAR project ended in Dec. 2011. The el Exchange and Co-Simulation in one standard. maintenance and further development is now per- Based on the experience on using FMI 1.0, many formed by the Modelica Association in form of the small details have been improved and new features Modelica Association Project FMI (see introduced to ease the use and increase the perfor- https://www.modelica.org/projects). FMI was initiat- mance especially for larger models. Additionally, a ed and organized by Daimler AG with the goal to free FMI compliance checker is available and FMI improve the exchange of simulation models between models from different tools are made available on suppliers and OEMs. The further FMI development the web to simplify testing. is performed by 16 companies and research institutes (see Annex). The FMI project is open for FMI inter- Keywords: Simulation; Co-Simulation, Model Ex- ested persons1 and for (Modelica and non-Modelica) change; Functional Mockup Interface (FMI); Func- tool vendors supporting FMI. tional Mockup Unit (FMU); In this article an overview about the upcoming version 2.0 of FMI is given. This new version combines the formerly separated interfaces for Model 1 Introduction Exchange and Co-Simulation in one standard. The specification document was clarified which increases The Functional Mockup Interface (FMI) standard the compatibility of implementations. New features version 1.0 (see [1]) was published in 2010 as one ease the use and increase the performance especially result of the ITEA2 project MODELISAR, see Fig- for larger models. ure 1. In a short time after this first release several modeling and simulation tools started to support FMI. Today, more than 30 tools support FMI 1.0, and it is heavily used in industrial and scientific projects, not only in the automotive sector.

1 Members of the MA project FMI need not be Modelica As- sociation members, with exception of the project leader. 2 The Functional Mock-Up Interface tems are solved independently from each other by their individual solver. Master algorithms 2.1 Main Design Ideas control the data exchange between subsystems and the synchronization of all slave simulation The FMI 2.0 standard consists of two main parts: solvers. The interface allows standard, as well as advanced master algorithms, e.g., the usage of 1. FMI for Model Exchange: variable communication step sizes, higher order The intention is that a modeling environment can signal extrapolation, and error control. generate C-Code of a dynamic system model in

the form of an input/output block, see Figure 2, tt00,pv ,inital values (a subset of ( )) v that can be utilized by other modeling and simu- Enclosing Model lation environments. Models (without solvers) are described by differential, algebraic and dis- t time crete equations with time-, state- and step- p parameters of type T events. u inputs of type T u v all exposed variables y 2. FMI for Co-Simulation: y outputs of type T The intention is to couple two or more models T Real, Integer, Boolean, or String with solvers in a co-simulation environment. The FMU instance data exchange between subsystems is restricted (model exchange or co-simulation) to discrete communication points. In the time between two communication points, the subsys- Figure 2: Data flow between the environment and the FMU Blue/red arrows: Information provided by/to the FMU.

Figure 3: Complete XML schema of upcoming FMI 2.0 (but without attributes and without time synchronization). 2.2 Distribution 2.4 C-Interface

A component which implements the FMI is called The execution interface of FMI 2.0 consists of three Functional Mockup Unit (FMU). It consists of one header files that define the C-types and –interfaces. zip-file with extension “.fmu” containing all neces- The header file “fmiTypesPlatform.h” contains all sary components to utilize the FMU either for Model definitions that depend on the target platform: Exchange, for Co-Simulation or for both: #define fmiTypesPlatform "standard32" 1. An XML-file contains the definition of all varia- #define fmiTrue 1 bles of the FMU that are exposed to the envi- #define fmiFalse 0 ronment in which the FMU shall be used, as well #define fmiUndefinedValueReference (fmiValueReference)(-1) as other model information. It is then possible to run the FMU on a target system without this in- typedef void* fmiComponent; formation, i.e., with no unnecessary overhead. typedef void* fmiComponentEnvironment; typedef void* fmiFMUState; 2. A set of C-functions is provided to execute mod- typedef unsigned int fmiValueReference; el equations for the Model-Exchange case and to typedef double fmiReal ; setup and run the slaves for the Co-Simulation typedef int fmiInteger; case. These C-functions can either be provided typedef char fmiBoolean; in source and/or binary form. Binary forms for typedef const char* fmiString ; different platforms can be included in the same typedef char fmiByte; model zip-file. The underlined, blue type definitions have been newly introduced into FMI 2.0. This header file must be 3. Further data can be included in the FMU zip-file, used both by the FMU and by the target simulator. If especially a model icon (bitmap file), documen- the target simulator has different definitions in the tation files, maps and tables needed by the mod- header file (e.g., “ ” in- el, and/or all object libraries or DLLs that are typedef float fmiReal utilized. stead of “typedef double fmiReal”), then the FMU needs to be re-compiled with the header file 2.3 Description Schema used by the target simulator. The header file platform, for which the model was compiled, as well as All information about a model and a co-simulation the version number of the header files, can be in- setup that is not needed during execution is stored in quired in the target simulator with FMI functions. an XML-file called “modelDescription.XML”. The The type fmiValueReference defines a handle benefit is that every tool can use its favorite pro- for the value of a variable: The handle is unique at gramming language to read this XML-file (e.g., C, least with respect to the corresponding base type C++, C#, Java, Python) and that the overhead, both (such as fmiReal) besides alias variables that can in terms of memory and simulation efficiency, is re- have the same handle. All structured entities, such as duced. The XML-file is defined by an XML-schema records and arrays, are “flattened” into a set of scalar file called “fmiModelDescription.xsd”. In FMI 2.0, values of type fmiReal, fmiInteger etc. A the XML-file contains the information both for fmiValueReference references one such scalar. Model-Exchange and for Co-Simulation. The coding of fmiValueReference does not need In Figure 2, the complete XML schema definition to be exposed by the modeling environment that is shown. All parts are the same for the two FMI- generated the model. The data exchange is per- cases, with exception of the elements “Mod- formed using the functions fmiSetXXX(...) and elExchange” and “CoSimulation” that contain defini- fmiGetXXX(...). XXX stands for one of the types tions specific to the respective case. If either one or Real, Integer, Boolean, and String. One argument of both of the two elements are present in the XML file, these functions is an array of fmiValueReference, then the respective C-functions are available in the which defines which variables are accessed. The zip-file (usually in binary form as DLL for Win- mapping between the FMU variables and the dows, and/or as shared object for Linux or Mac). fmiValueReferences is stored in the model de- Another essential difference to FMI 1.0 is the new scription XML file. element “ModelStructure” that exposes and provides For simplicity, a “flat” structure of variables is more details of the model structure. used. Still, the original hierarchical structure of the variables can be retrieved, if a flag is set in the XML-file that a particular convention of the variable names is used. For example, the Modelica variable If an FMU is shipped with a DLL/SharedObject, name “pipe[3,4].T[14]” defines a variable the constructed function name is “fmiGetReal”, in which is the (3.4) element of an array of records other words it is not changed. A simulation environ- “pipe” of vector T (“.” separates hierarchical levels ment will then dynamically load this library and will and “[...]” defines array elements). explicitly import the function symbols by providing Header-file “fmiFunctionTypes.h” contains the FMI function names as strings. The name of the typedef definitions of all function prototypes of an library is MyModel.dll on Windows or MyModel.so FMU. When dynamically loading the DLL or shared on Linux, in other words the function prefix attribute object of an FMU, these definitions can be used to is used as library name. type-cast the function pointers to the respective func- An FMU can be optionally shipped so that it ba- tion definition. Example for a definition in this head- sically contains only the communication to another er file: tool. This is particularly common for co-simulation typedef fmiStatus fmiSetTimeTYPE tasks. In FMI 1.0, the function names are always pre- (fmiComponent, fmiReal); fixed with the model name and therefore a This header file was newly introduced in FMI 2.0 to DLL/Shared Object has to be generated for every ease the dynamic loading. model. FMI 2.0 improves this situation since model Finally, header file “fmiFunctions.h” contains the names are no longer used as prefix in case of function prototypes of an FMU that can be accessed DLL/Shared Objects: Therefore one DLL/Shared in simulation environments. This header file includes Object can be used for all models in case of tool the other two header files from above. Example for a coupling. definition in this header file: DllExport fmiSetTimeTYPE fmiSetTime; The goal is that both textual and binary represen- 3 New Features of FMI 2.0 tations of models are supported and that several models using FMI might be present at link time in an In this section the main new features introduced by executable (e.g., model A may use a model B). For FMI 2.0 are sketched. Note, also many other minor this to be possible the names of the FMI-functions in improvements have been introduced, based on the different models must be different or function point- experience in using FMI 1.0. Especially: ers must be used. To support the first variant macros are provided in “fmiFunctions.h” to build the  When instantiating an FMU, the simulation envi- actual function names by using a function prefix that ronment must report the absolute path to the depends on how the FMU is shipped. Typically, FMU resource directory also in Model Ex- FMU functions are used as follows: change, in order that the FMU can read all of its resources (for example maps, tables, ...) inde- // FMU is shipped with C source code, pendently of the "current directory" of the simu- // or with static link library lation environment where the FMU is used. #define FUNCTION_PREFIX MyModel_ #include "fmiFunctions.h"  Enumerations have an arbitrary (but unique) < usage of the FMU functions > mapping to integers (in FMI 1.0, the mapping was automatically assigned to 1,2,3,...). // FMU is shipped with DLL/SharedObject #define FUNCTION_PREFIX  When enabling logging, log categories can be #include "fmiFunctions.h" defined, so that the FMU needs to only generate < usage of the FMU functions > logs of the defined categories (in FMI 1.0, logs had to be generated for all log categories and If an FMU is shipped with C source code, or with a they had to be filtered afterwards). static link library, then a function that is defined as  Explicit alias/antiAlias variable definitions have “fmiGetReal” is changed by the macros to the ac- been removed, to simplify the interface: If varia- tual function name “MyModel_fmiGetReal”. The bles of the same base type (such as fmiReal) function prefix is hereby defined in the XML file. A have the same valueReference, they have simulation environment can therefore construct the identical values. A simulation environment may relevant function names by generating code for the ignore this completely (this was not possible in actual function call. In case of a static link library, FMI 1.0), or can utilize this information to more the name of the library is MyModel.lib on Windows, efficiently store results on file. and libMyModel.a on Linux, in other words the function prefix attribute is used as library name.  Continuous state variables are explicitly listed as FMU variables, and an ordering is introduced for them, as well as for inputs, and outputs in the changing variables with causality = "parameter" XML file, in order that not an (arbitrary) order is or "input" (see explanation below). selected by the simulation environment. This is  discrete: The value of the variable is constant essential, for example when linearizing an FMU, between internal events (= time, state, step or when providing "sparsity" information (see events defined implicitly in the FMU). below).  continuous: No restrictions on value changes. The new value “tunable” introduced in FMI 2.0 al- 3.1 Unification of FMI for Model Exchange lows a modeling environment to expose independent and Co-Simulation parameters that can be manually “tuned” during simulation (for example, during simulation a modeler In FMI 1.0 the Model Exchange and Co-Simulation might change the gain of a PID controller, or the interfaces were defined in two different documents. load mass of a drive train in order to quickly improve The XML-description and function definitions were the design). slightly different. In version 2.0 both interfaces are “Tuning a parameter” during simulation does not combined in one document and unified. Now one mean to “change the parameter online” during simu- FMU can implement both interfaces at the same lation (since this might introduce Dirac impulses). time. The presence of the “ModelExchange” or “Co- Instead, this is a short hand notation for: Simulation” elements in the XML-description indi- cates which interface is implemented. Which inter- 1. Stop the simulation at an event instant (usually, a face is used by the environment is decided by calling step event, in other words after a successful inte- the appropriate instantiation function (fmiInstan- gration step). tiateModel or fmiInstantiateSlave). 2. Change the values of the tunable parameters. In this way the distributed use case (see [1]) 3. Compute all parameters that depend on the tuna- which was applicable for Co-Simulation in FMI 1.0 ble parameters. only is supported in the Model Exchange case too. In 4. Resume the simulation using as initial values the this use case only the ability of a tool to evaluate the current values of all variables and the new values model equations is used, not its solver. of the parameters. 3.2 Classification of Interface Variables With this interpretation, changing parameters online is “clean”, as long as these changes appear at an Variables exposed by the FMU are now categorized event instant. in a slightly different way in FMI 2.0: 3.3 Save and Restore of FMU state Attribute “causality” is an enumeration that defines the causality of the variable. Allowed values are: An FMU has an internal state consisting of all values  parameter: An independent variable that must that are needed to continue a simulation. This inter- be constant during simulation. nal state consists especially of the values of the con-  input: The variable value can be provided from tinuous states, discrete states, iteration variables, pa- another model. rameter values, input values, file identifiers and  output: The variable value can be used by an- FMU internal status information. With newly intro- other model. The algebraic relationship to the duced (optional) functions, the internal FMU state inputs is defined in element ModelStructure. can be copied and the pointer to this copy is returned  local: Local variable that is calculated from other to the environment. The FMU state copy can be set variables. It is not allowed to use the variable as current FMU state, in order to continue the simu- value in another model lation from it. This feature introduced in FMI 2.0 can be for example used: Attribute “variability” is an enumeration that defines the time dependency of the variable, in other  For iterative co-simulation master algorithms words it defines the time instants when a variable (get the FMU state for every accepted communi- can change its value. Allowed values are: cation step; if the follow-up step is not accepted,  constant: The value of the variable never chang- restart co-simulation from this FMU state). es.  For nonlinear Kalman filters (get the FMU state  fixed: The value of the variable is fixed after just before initialization; in every sample period, initialization. set new continuous states from the Kalman filter  tunable: The value of the variable is constant algorithm based on measured values; integrate to between externally triggered events due to the next sample instant and inquire the predicted continuous states that are used in the Kalman fil-  xfx()  d 112 ter algorithm as basis to set new continuous x  fx()3 p2  x  2 u  3 u  states). dt  221 213     xfxxuuu3313123(, ,, , )   For nonlinear model predictive control (get the ygxx (,) FMU state just before initialization; in every 123 sample period, set new continuous states from an where u1 and u2 are continuous-time inputs (variabil- observer, initialize and get the FMU state after ity=”continuous”), u3 is a discrete-time input (var- initialization. From this state, perform many iability=”discrete”), and p is a fixed parameter simulations that are restarted after the initializa- (variability=”fixed”). The structure of these equation with new input signals proposed by the op- tions can then be defined optionally in the following timizer). way in the XML file: Furthermore, the FMU state can be serialized and copied into a byte vector. This can, for example be used to perform an expensive steady-state initialization, copy the received FMU state in a byte vector and store this vector on file. Whenever needed, the byte vector can be loaded from file, can be deserial- ized and the simulation can be restarted from this puts could be defined by the element “DirectDe- information and the dependencies of outputs w.r.t. state variable and of derivatives w.r.t. inputs and state variables can be provided using the element iable names) and outputs are provided. At each output and derivative additional attributes define the dependency on inputs and state variables. Not only 3.5 Jacobian Matrices the dependency itself but also the kind of dependency is defined here. It can be indicated whether the Partial derivatives of FMU variables with respect to dependency is nonlinear, fixed (the dependency inputs or state variables (Jacobian matrices) are is linear, the factor is constant after initialization) or needed for implicit integration methods, for lineari- discrete (the factor might change after events). zation of FMUs, or for usage in extended Kalman Using this information a tool can decide at which filters. Especially for large models the numerical stage of the solution process the respective entries of computation of Jacobian matrices is time consuming. the Jacobian matrices are to be retrieved. For that reason FMUs can optionally provide func- The dependency information of outputs can be tions to retrieve partial derivatives (complete Jacobi- utilized for detection of algebraic loops when FMUs ans) or directional derivatives of some variables are connected with other parts of a model. In addi- w.r.t. some others. tion to that dependency information is necessary for The sparsity pattern defined under “ModelStrucu- usage of sparse matrix techniques on Jacobian matri- tre” (see section above) can be utilized for efficient ces. data storage and matrix operations on sparse Jacobi- Assume for example that the following equations ans. FMI does not define a specific storage schema. are defined: The calling environment is free to use its own schema by the following approach. The environment has to provide a function pointer to a call back function setMatrix as argument of fmiGetPartialDe- rivatives. The FMU calls this function to set respective matrix elements. The FMU internally is free to use efficient numerical methods for Jacobian computation, use a symbolically deduced algorithm or automatic differ- entiation.

3.6 Precise Time Event Handling

The details of precise time event handling in FMI were still under discussion before the editorial dead- line of this paper. Hence we cannot present a detailed description here. The development work is complicated since several aspects have to be considered:  The synchronous features of Modelica 3.3 [2] should be supported. In multi-body system terminology, this is called a  FMI should also be useable by tools that do not “force element”. Typically, FMU 1 would be a com- support synchronous time event handling. plicated device, e.g., a controlled electrical motor  The time event handling is to be defined in a with a gearbox, but the essential part is the force el- way that allows backward compatible exten- ement at the interface. The inputs to FMU 1 are the sions. angle phi and the angular velocity w of the end point of the spring/damper system. The output would be 3.7 Improved Unit Definitions the torque generated by the spring/damper. It is calculated with the simple equation The unit definitions have been improved in FMI 2.0: torque = c*(phi - inertia.phi) + The tool-specific unit-name can optionally be ex- d*(w – inertia.w) pressed as function of the 7 SI base units and the SI where c is the spring and d is the damper constant. derived unit “rad”. It is then possible to check units This FMU is then connected to a multi-body sys- when FMUs are connected together (without stand- tem FMU, for example a robot, and drives a revolute ardizing unit names as needed in FMI 1.0), or to joint. The FMU 2 provides phi and w as output convert variable values that are provided in different (from the relative joint coordinates) and gets the units (for the same physical quantity). In the specifi- torque as input. caiton it is sketched how to utilize this information for connection checks, dimensional checks, or unit The XML-file of FMU 1 has the following structure: propagation. The trick is to treat the derived unit

In this section two examples are shown that demon-

4.1 FMU as Force Element be used as interface of this FMU, see next figure: The XML-file for FMU 2 looks similar. We will concentrate only on the ModelStructure element: name="Modelica.SIunits.Torque"> ... ... name="phi" stateDependencies="1" stopTime="1.0" tolerance="0.0001"/> derivative="1" valueReference="335544320" description="Torque in flange" causality="output"> that the outputs phi and w do not directly depend on ... the input torque. As a result, when connecting FMU 2 to FMU 1, the outputs phi and w are provided by FMU 2. FMU 1 computes its output torque that is an input to FMU 2. Since the FMU 2 outputs do not depend on this input, there is no algebraic loop and the computation is simple. The second example is the more often occurring with a rotational inertia, see next figure: Most of the elements should be self-explanatory. The interesting part for the connection is element “ModelStructure” at the end. Output torque depends on the first and the second input, i.e. on phi and w. Furthermore, the attributes fixed define that the inputs enter the equation for the output with fixed linear factors: torque = p1*phi + p2*w + f(..) where p1 and p2 are constants that are fixed after Since FMU 1 is connected to a joint of FMU 2, the initialization. Additionally, for input w the attribute coupling leads to a constraint equation that states that derivative = ”1” is defined. The meaning is that the angle of the revolute joint of FMU 2 is identical w is the derivative of the first input, i.e. of phi. This to the angle of inertia2 in FMU 1. It is well- derivative information for inputs and outputs is es- known that such a model cannot be transformed by sential in order that a coupling tool can check that an purely algebraic transformations into a state space input is really the derivatives of another input by checking the derivative attributes of the outputs from another FMU. form (this is a so called higher index system2), and The ModelStructure of FMU 2 states that it’s 3rd that the first and second derivatives of this constraint output a depends on all of its inputs, i.e. on torque equation is needed. For this reason, FMU 2 provides (since no inputDependencies attribute is defined): the angle phi of the revolute joint, its first derivative a = f2(torque, ) w (the angular velocity) as well as its second deriva- Therefore, when the two FMUs are connected to- tive a (the angular acceleration) to FMU 1. In turn gether an algebraic loop in the angular acceleration a FMU 1 provides the reaction torque to FMU 2. The and in the reaction torque appears. The environ- “ModelStructure” elements of the two FMUs have ment has therefore to either use a differential- now the following structure: algebraic equation solver, or has to solve a non- FMU 1: linear algebraic loop over the two FMUs. The latter case can be improved by using Jacobian information: As will be explained below, it is possible to compute the factor J once after initialization and the term f1 at every model evaluation (which turns out to be a cheap operation for a drive train). It is then only nec- ... essary to solve a nonlinear algebraic loop over FMU equation depends linearly on the unknowns, a nonlinear solver will converge with the provided Jacobi- FMU 2: ans within one step. An often occurring situation is that FMU 1 is imported into a multi-body program and coupled to a joint. In such a case, the multi-body code gets the information about the linear equation of FMU 1. ... Since the multi-body program has to solve a linear linear equation of FMU 1 has to be added and in eve- comes more complicated and linear or non-linear encies and/or Jacobians are utilized. The partial derivatives of output variables with respect to input variables can be computed with The ModelStructure of FMU 1 states that its output function . For the depends on its 3rd input and that enters fmiGetDirectionalDerivative torque a a case of one output variable y as function of states x with a fixed factor. Therefore, the following equation and of one input u, this function assumes an equation is present: of the form: torque = J*a + f1() yg ((),(),)x tutt where J is a constant quantity that is fixed after ini- The function calculates: tialization (this is the inertia of component iner- g ) and is an additional functional de- yu tia2 f1(..) u pendency of the states of the FMU, but not of its in- where the seed Δu is given as an explicit input argu- puts. ment. Therefore, calling fmiGetDirectionalDe- rivative for the output torque with respect to input a and with Δa=1, the function will return the partial derivative, that is . The value of is computed 2 Simulating such a higher index system of index 3 directly J f1 will usually fail with an error message of the integrator that by providing an input a=0 and computing the output there is no convergence. torque, that is torque = f1(). Similari- ly, the partial derivative of the FMU 2 equation can In mechatronic gearshift simulations for commer- be computed. cial vehicles at Daimler AG FMI is utilized twice As a final remark: When FMU 1 is modeled in [4]. At first controller software is connected to a de- Modelica, then the derivative relationships between tailed 1D powertrain model in SimulationX. After- the inputs of the FMU must be defined, otherwise a wards this model is exported as FMU and imported Modelica translator cannot process the model. There to the multibody system simulation tool Simpack. is no direct Modelica language element available to There it is connected to a detailed truck model. This define this. However, with component Modeli- allows the holistic simulation and optimization of the ca.Mechanics.Rotational.Sources.Move from the shifting comfort. Modelica Standard library this relationship is ex- At IFP Energies Nouvelles, FMI for Model Ex- pressed (based on language elements to express that change is used to parallelize the execution of com- a function is a derivative of another function). plex internal combustion engine models in the tool xMOD (see [5]). The models have around 100 - 300 state variables, with integration step-sizes that can 5 Increasing Quality of FMI Imple- reach some microseconds. Their use is mainly in- mentations dented to validate engine controls. The final target is to enable the execution in real-time, for hardware in The FMI project provides an infrastructure to in- the loop simulations. crease the quality and compatibility of implementa- In [6], an algorithm is implemented for deriva- tions in different tools. A repository of FMUs gener- tive-free optimization implemented in Python and ated by different tools and reference results are pub- applied to parameter optimization of FMUs is intro- lically available at the svn server: duced. The FMUs are loaded and simulated using the PyFMI package (http://www.pyfmi.org). The opti- https://svn.fmi-standard.org/fmi/trunk/Test_FMUs mization algorithm is applied to a Volvo truck en- In this way tool vendors are able to cross check their gine to identify model parameters based on meas- implementations in an easy way. We hereby would urement data from a test cycle. like to ask tool vendors that export FMUs, to provide In [7] the FMI based co-simulation master from FMUs of their tools by sending an email with the Fraunhofer is used to develop, implement and test FMUs to [email protected]. sophisticated algorithms for the co-simulation of Additionally, the Modelica Association contract- FMUs generated by Dymola. ed the development of an open source FMI compli- Dassault Systèmes uses FMI for academically ance checker. This tool is now available for FMI 1.0 trainings. Student teams work with CATIA V6 and in source code, and as executable for Windows and define both a 3D CATIA representation of a NXT Linux under the svn address from above. It will be robot as well as the controller software. Practically, available for FMI 2.0 soon after FMI 2.0 is released. the real robot has sensors and actuators and is piloted from a smartphone remote command, while the FMU based logical control is executed in a CATIA ses- 6 FMI Usage sion. All these items are FMI and Bluetooth connected. FMI is used in industrial and scientific projects by The solution has been delivered to Georgia Insti- several companies and research institutions: tute of Technology and University of Detroit Mercy In all new gearbox projects for Mercedes-Benz (US High Schools), also related to a cooperation passenger cars FMI is used for software-in-the-loop with Ford Motors Foundation. simulations [3]. Control software and FMUs coming In the field of modeling and simulation of build- from different modeling environments run in closed- ing energy systems FMI is also used. In [8] FMI is loop in the virtual ECU tool Silver on Windows PC utilized to connect a building model with a Modelica in order to validate, test and debug control software. model of the heating system. Before FMI, vehicle models had to be imported In 2012, the International Energy Agency, under through various vendor and version specific import the implementing agreement on Energy Conserva- procedures into Silver. This was expensive and error tion in Buildings and Community Systems, approved prone. Thanks to the FMI, these bridges have now the five-year Annex 60 proposal "New generation been replaced by a uniform import interface, increas- computational tools for building and community en- ing thereby the cost-benefit ratio of simulation in this ergy systems based on the Modelica and Functional domain. Mockup Interface standards." Eleven countries are expected to participate in sharing, developing and deploying free open-source contributions for model- 8 Acknowledgements ing and simulation of energy systems of buildings and communities, based on Modelica and Functional The authors wish to thank all the contributors to the Mockup Interface standard. FMI specification (see Annex). The Lawrence Berkeley National Laboratory Parts of this work were supported by the German (LBNL) released an FMI for co-simulation import BMBF (Förderkennzeichen: 01IS08002), the French interface in version 7.1 of the EnergyPlus building DGCIS, and the Swedish VINNOVA (funding num- simulation program. Work is also in progress to ex- ber: 2008-02291) within the ITEA2 MODELISAR port EnergyPlus as a FMU for Co-Simulation. UC project Berkeley and LBNL have been developing JFMI, a (http://www.itea2.org/project/result/download/result/ Java Wrapper for FMI for Co-Simulation and Model 5533) The authors appreciate the partial funding of Exchange. JFMI will be used to integrate an FMI this work. import interface in Ptolemy II, a software environment for design and analysis of heterogeneous systems. 9 References The Institute for the Sustainable Performance of Buildings has been developing a web-based eLearn- [1] T. Blochwitz, M. Otter, M. Arnold, C. Bausch, C. ing tool, Learn Green Buildings Clauß, H.Elmqvist, A. Junghanns, J. Mauss, M. (http://learngreenbuildings.org), in which a Web in- Monteiro, T. Neidhold, D. Neumerkel, H. Olsson, J.- terface communicates with an FMU for Co- V. Peetz, S. Wolf: The Functional Mockup Inter- Simulation that computes the dynamic response of face for Tool independent Exchange of Simulation building energy and control systems. The tool will Models. 8th International Modelica Conference. Dresden 2011. Download: allow students to interactively operate a simulated, http://www.ep.liu.se/ecp/063/013/ecp11063013.pdf realistic building system, to test energy-saving [2] Modelica Association: Modelica – A Unified Ob- measures and to explore the effects of faults in ject-Oriented Language for Systems Modeling. equipment and controls. Language Specification, Version 3.3. May 9, 2012. [3] E. Chrisofakis, A. Junghanns, C. Kehrer, A. Rink: Simulation-based development of automotive con- 7 Conclusions and Outlook trol software with Modelica. 8th International Modelica Conference. Dresden 2011. Download: FMI is an established standard for Model Exchange http://www.ep.liu.se/ecp/063/001/ecp11063001.pdf and Co-Simulation. The upcoming version 2.0 im- [4] A. Abel, T. Blochwitz, A. Eichberger, P. Hamann, proves the compatibility of implementations by a U. Rein: Functional Mock-up Interface in Mecha- clarified specification. New features increase usabil- tronic Gearshift Simulation for Commercial Ve- ity and performance especially for large models. hicles. 9th International Modelica Conference. Mu- This version will be stable for the next years. If nich, 2012. necessary, minor backwards compatible releases will [5] Abir Ben Khaled, Mongi Ben Gaid, D. Simon, G. be available to improve and clarify the specification Font: Multicore simulation of powertrains using and to support new features. Current development weakly synchronized model partitioning. Accept- tasks are the exchange of structured data and arrays ed for 2012 IFAC Workshop on Engine and Power- of variable size and support of the new synchronous train Control, Simulation and Modeling. Rueil- Malmaison, 2012 features of the Modelica language [2]. The further development of FMI is organized un- [6] S. Gedda, C. Andersson, J. Åkesson, S. Diehl: De- der the hood of the Modelica Association. The FMI rivative-free Parameter Optimization of Func- tional Mock-up Units. 9th International Modelica Modelica Association Project is of course open for Conference. Munich, 2012. non Modelica tool vendors and organizations. From [7] T. Schierz, M. Arnold, C. Clauss: Co‐simulation the 16 members of the FMI Steering Committee and with Communication Step Size Control in an FMI Advisory Group, only five are Modelica Tool ven- Compatible Master Algorithm. 9th International dors. Modelica Conference. Munich, 2012. Companies and organizations which are interest- [8] S. Burhenne, M. Pazold, F. Antretter, F. Ohr, S. Her- ed to contribute to FMI development or request fea- kel, J. Radon: WUFI Plus Therm: Co-Simulation tures are invited to contact the FMI project via unter Verwendung von Modelica Modellen. [email protected]. Presentation at the Symposium „Integrale Planung und Simulation in Bauphysik und Gebäudetechnik.“ Dresden, March 2012. Annex Members of the FMI Modelica Association Project:

Project Leader Torsten Blochwitz (ITI GmbH Dresden, Germany) Steering Committee Atego, Daimler, Dassault Systèmes, IFP EN, ITI, LMS, Modelon, QTronic, SIMPACK Advisory Board Armines, DLR, Fraunhofer (IIS/EAS, First, SCAI), Open Modelica Consortium, TWT, University of Halle Guests Altair Engineering, Berkeley University, Bosch, ETAS, Siemens, Equa Simula- tion

The Steering Committee is open for additional members that actively support FMI. Requirements: Must have (a) participated at least at two FMI meetings in the last 24 months, (b) must either provided the FMI standard or part of it in a commercial or open source tool, and/or must actively use FMI in industrial projects, (c) the Steering Committee members agree with qualified majority. The Advisory Committee is open for additional members that proofed to actively support FMI. Require- ments: Must have (a) participated at least at two FMI meetings in the last 24 months, and (b) the Steering Committee members agree with qualified majority.

Contributors to the FMI 2.0 Specification: The following persons participated at FMI 2.0 design meetings and contributed to the discussion (alphabetical list): Martin Arnold, University Halle, Germany Johan Akesson, Modelon, Sweden Mongi Ben-Gaid, IFP, France Torsten Blochwitz, ITI GmbH Dresden, Germany Christoph Clauss, Fraunhofer IIS EAS, Germany Alex Eichberger, SIMPACK AG, Germany Hilding Elmqvist, Dassault Systèmes AB, Sweden Markus Friedrich, SIMPACK AG, Germany Peter Fritzson, PELAB, Sweden Andreas Junghanns, QTronic, Germany Petter Lindholm, Modelon, Sweden Kristin Majetta, Fraunhofer IIS EAS, Germany Sven Erik Mattsson, Dassault Systèmes AB, Sweden Jakob Mauss, QTronic, Germany Dietmar Neumerkel, Daimler AG, Germany Peter Nilsson, Dassault Systèmes AB, Sweden Hans Olsson, Dassault Systèmes AB, Sweden Martin Otter, DLR-RM, Germany Bernd Relovsky, Daimler AG, Germany Tom Schierz, University Halle, Germany Bernhard Thiele, DLR-RM, Germany Antoine Viel, LMS International, Belgium The following people contributed with comments (alphabetical list): Peter Aaronsson, MathCore, Sweden Bernhard Bachmann, University of Bielefeld, Germany Iakov Nakhimovski, Modelon, Sweden