This blog post will introduce newcomers to the difference between using co-simulation FMUs (Functional Mock-up Units) and Model Exchange FMUs.
FMI – Functional Mock-up Interface
FMU – Functional Mock-up Unit (a model, for example, which has been wrapped within the Functional Mock-up Interface).
For more information on FMI please visit the FMI – Functional Mock-up Interface website.
In Dymola, we can export and import both types of FMU:
- Model Exchange
When should we consider one option over the other?
If the model you are looking to export as an FMU does not require particularly specialised solvers to run, we would generally opt for the Model Exchange option. With this option the FMU will be run using the host environment solvers (for example if you were exporting a Dymola generated FMU into Simulink, you would end up using the Simulink solvers to run the FMU).
If on the other hand the model you are exporting as an FMU requires specialised solvers to run (for example a complex thermo-fluids model) it will be best to use the Co-simulation option and effectively also export the specialised solvers with it; for example the last option in the Type section of the list in Figure 1. If the solver Cvode is good enough you could also choose options 2 and 3. By doing this we are not relying on the host environment solvers to solve the FMU equations.
Figure 1. Dymola FMI export configuration menu.
We will need to set the communication step size which, to put it simply, defines how often information is exchanged between the FMU and any externally connected model. The smaller the communication step size, the slower the simulation can be, so it is down to us to find a good compromise here between how often the values of the inputs and outputs are updated (also related to model accuracy) and simulation performance.
As an example I have exported a simple plant model consisting of a torque actuator connected to a 1-d rotational inertia. Connected to the inertia is also a speed actuator which outputs the measured angular velocity of the inertia w for monitoring purposes.
Figure 2. Exported plant model
The test case (Figure 3) defines a torque-time profile that we feed into the FMU through the input tau.
Figure 3. Test scenario using the Model Exchange FMU.
Running the FMU as a Model Exchange FMU we get the following system response:
Figure 4. System response using the Model Exchange FMU.
If we now replace the Model Exchange FMU with the Co-simulation FMU using a communication time step of 0.1s (set in the parameter dialog of the FMU accessed by double clicking on the FMU object – Figure 5) we get the following system response shown in Figure 6.
Figure 5. Co-simulation FMU user dialog.
Figure 6. System response using the Co-simulation FMU. Communication time step 0.1s.
We can see that the torque input tau and the related output w are stepped. A straightforward way to overcome this issue is to reduce the communication time step so that the input torque updates more often and we should then get a smoother response:
Figure 7. System response using the Co-simulation FMU. Communication time step 0.001s
However, if you now look at the lower plot window in Figure 5 which displays CPU time (simulation time), we can see this has increased significantly vs. the case where we had a larger communication time step.
In conclusion and in very broad terms, if you can run with Model Exchange FMUs then all the better. However if you need to export your own solvers with the FMU then you will have to use Co-simulation FMUs and tune the communication time step to give you the optimal trade off between accuracy and performance.
Co-simulation FMUs also allow you to run them at a different rate to the other models they are connected to which might be advantageous depending on the situation.
Written by: Alessandro Picarelli – Engineering Director
Please get in touch if you have any questions or have got a topic in mind that you would like us to write about. You can submit your questions / topics via: Tech Blog Questions / Topic Suggestion