Dymola and SIMULIA Interface
It is possible to interface Dymola with SIMULIA tools Abaqus, iSight and FIPER. This interface may lead up to a so-called co-simulation. The picture shows a yacht model on a swell, which control surfaces have been modeled in Dymola. A Dymola-Abaqus co-simulation example of an high fidelity anti blockage braking system has been presented in the following document, a part of the Modelica Conference 2009:
Functional Mock-up Interface (FMI)
The FMI defines an interface which works with executables files called FMU (Functional Mock-up Units). The function FMI are called from a simulator to create and execute one or more FMU instances, called models. An FMU may include its own integrator (co-simulation) or ask the simulator to execute the numerical integration
FMI is born to allow a model environment as Dymola (able to generate the C code of a model for a dynamic system) to be easily interfaced inside (or together) other models or simulation environments. Models are described by differential, algebraic or discrete equations, consisting of time, states and events. Models, to be treated with this interface, may be especially complex (use during online/offline simulations) or optimized to be used in micro-processor embedded control systems.
It is possible to use different instances of a model and to hierarchically connect all models. The exported model is independent from the target simulator.
All the necessary equations are solved calling C standard functions. C language is used since is the most exportable programming language, as of today the only one that can be used on all embedded control system.
Model scheme description:
The scheme defines the structure and the subject of XML file, generated from a modeling environment. This file contains the definition of all the model variables in a standardized fashion. It is thus possible to run the C code on an embedded system, without overloading variables (an alternative would be to memorize these information inside the C code, gaining access during function calling…but that’s not practical for embedded systems or for large models). Moreover, variable definition is a complex data structure. All the tools must be free to represent this structure inside their programs. The approach that has been chosen allows each tool to archive and gain access to the variable definitions (without use memory or standard access functions), in the programming language of the simulation environment, usually C++, C# or Java. A number of open source/commercial libraries are available in different programming languages, allowing the XML file to read inside the appropriate data structure. See the example
A dynamic model is distributed on a single zip file, containing:
- An XML file, with the definition of all model variables and information;
- C source files (including runtime libraries that the model needs), and/or DLL libraries for one or more different targets. This solution is particularly used in case the model provider wants to hide the source code to maintain the know-how. This way, a model can safely contain physical parameters or geometrical dimensions;
- Additional data may be included in the zip file, such as a model icon (bitmap file), documentation files, maps and tables needed by the model, and all the object or DLL libraries used by the model itself.