In this week’s blog post we have a closer look at the inner workings of the Functional Mock-up Interface (FMI) and focus our attention on what the standard entails and how it can be leveraged for a more all-encompassing analysis. Throughout this article, dynamic system simulation models from Simcenter Amesim are used as examples on how to configure for co-simulation, or model exchange, complying with the FMI standard. However, as more than 180 software tools currently support the FMI standard, among them Simcenter STAR-CCM+, Simcenter 3D and Simcenter HEEDS to name a few, the information and details concerning the FMI technology is hopefully still informative to other users as well. Read on to find out how you can use FMUs in your simulation to expand the analysis.
“With the ever increasing use of models in aircraft system development, tool interoperability and model reuse are central challenges. At Saab we see the FMI standard as an enabler for scalable and tool neutral integration of simulation models from different technical disciplines, developed by different internal teams or by external partners.”
– Göran Ancker, Technical Fellow Aircraft System Simulation, Saab AB
The functional mock-up interface is an open industry standard which provides a common standardized framework for co-simulation and model export between different software tools. Models are shared using so called FMUs, or Functional Mock-up Units, which follow a standardized way for packaging models and govern the data exchange between tools. This is done using a combination of XML files, binaries, and C code generated from one model, zipped into a single file with the extension .fmu, and then shared with the target machine.
To avoid any unnecessary confusion early on in this article, the typical models converted and packaged according to the FMI standard are dynamic simulations models usually representing a dynamic system containing various components or control logic. A simulation from for example Simcenter STAR-CCM+ is not converted to an FMU, however Simcenter STAR-CCM+ is able to import FMUs.
Having common standards throughout industry and academia tends to simplify things, and in this case allow different software vendors, or third-party tool creators, to focus their effort on a single solution and interface for co-simulation or model exchange rather than having to develop an interface for each possible simulation tool. The time spent on a single solution hopefully also results in a much simpler and robust process for setting up co-simulation and model exchange within each individual software tool.
Apart from a providing a means of transferring simulation models and performing co-simulation between tools, the central idea behind FMI is that the value of a simulation model is increased exponentially if more users within an organization can reuse the same model in a convenient way and repurpose it for use in other applications. Essentially sharing detailed models capable of simulating complex behavior for use in other analysis work, rather than just sharing results between colleagues.
To provide a simple example of what can be achieved through the standard: A heat-exchanger, modelled in Simcenter STAR-CCM+ with the purpose of studying possible internal geometry changes, can be used in a joint study where a FMU of the larger surrounding system can be added. This setup offers many benefits and for instance facilitates the use of proper boundary conditions in the CFD simulation, in addition to being able to assess the geometry changes impact on other components in the system as well as overall system performance.
The FMI standard defines two different kinds of interface:
- FMI for Model Exchange, which describes a standardized way for interfacing an exported model with another simulation environment. Here the numerical solver is provided by the importing tool, which dictates how to step forward in time during for a transient run. The FMU evaluates the differential equations of the exported model, defines states, state derivatives, inputs and outputs, as well as gives access to any exposed internal parameters and any embedded tables.
- FMI for Co-Simulation, deals with how simulation models are coupled together. A solver is supplied by the exporting tool and embedded in the FMU. Along with the solver, the differential equations and mathematical libraries contained in the original simulation model are also included. A Co-Simulation FMU can act as the master during a co-simulation and the importing tool does not necessarily have to have its own solver. A more typical scenario would however likely be that the importing tool acts as the master and governs the co-simulation, and that the importing tool solves its physics using its own solver. In this scenario the FMU acts as the slave and computes its equations using the solver embedded in the FMU.
As you can see both FMU types share a lot of common features but the main differentiator is whether the solver is included or not.
Concerning Model Exchange, it is important to note that Model Exchange FMUs can take many different forms in regard to what is actually placed inside them. Equations or mathematical libraries developed by a software vendor through various R&D endeavors may be used and this can restrict how a model may be shared or can come with its own licensing scheme for the FMU.
Simcenter Amesim – FMU Import and Export Assistants 
Importing an FMU of any type is done using the built in FMU Import Assistant. Once imported, an FMU behaves as an ordinary Simcenter Amesim submodel:
- Use the FMU Import Assistant to select the FMU, create and compile an import submodel.
- Drop the import submodel on the sketch, connect it to other components.
The assistant is opend from Interfaces –> FMU import assistant
As outlined in the workflow above, once the assistant is opened the user can point towards the location of the FMU and then provides a storage directory for the submodel that will be created by the tool and later used inside Simcenter Amesim. Next, import settings concerning which compiler was when the FMU was generated and type of FMU are set. During the last step, Simcenter Amesim generates a submodel which can be located from the library tree and then can be dragged onto the sketch area to be connected to other components. The submodel will then use the specified FMU or FMUs during simulation.
Creating and exporting a FMU is done by firstly creating a new interface block, selecting Functional Mock-up Interface (FMI), and adding this to your model.
We proceed by moving to Simulation Mode and compiling the model which contains the new interface block. Once this step is completed the FMU export assistant feature from the interface menu becomes available.
When opened, the first step in the assistant’s workflow is to define the export settings of the FMU. Here the type of FMU and version is selected as well as setting if all parameters and variables contained in the model should be exposed, or if only a subset of them should be visible to the end-user of the FMU. Next, which compiler to use for the export is selected. Depending on the target machine’s platform, a Windows based or Linux based compiler could be used. Once done the model is exported to a FMU by hitting next.
The FMU is now ready to be sent to the importing software to be used during a new analysis. Looking inside a FMU can be done by unzipping the file to expose its contents.
We hope you have found this article interesting. If you have any questions or comments, please feel free to reach out to us on support@volupe.com
Author
Fabian Hasselby, M.sc.
