As written on the official site (https://fmi-standard.org/) FMI is a free standard that defines an interface for exchanging dynamic simulation models.
The idea indeed is to have a well-known interface to a module containing the implementation of some logic that can be used in simulation environments like Process Simulate. In other words this is a typical black box that you get for granted and rely on to implement the desired behavior. In this post I would like to present how such modules can be used in the context of our product.
The FMI standard refers to such a module as a Functional Mock-up Unit (FMU). In essence this is a zip file containing the compiled version of the module's source code and an xml file providing some metadata related to it. Optionally the zip file can contain the source code of the module and some resources used by it.
There are different versions of the FMI standard. In Process Simulate (v2307) we support only version 2.0. There are already plans to support 3.0 but for this we rely on a third party component that is still on 2.0.
FMUs have inputs and outputs described in the metadata xml file that I already mentioned earlier. In v2.0 these can only be of primitive types. e.g. Booleans, Integers, Doubles and Strings. Structures and arrays are not supported. To use the FMU you need to create an instance of it and then communicate with this instance to make it run the model behind. I believe this pattern already sounds familiar to you right? If you recall the same is true for SCL function blocks. So instead of creating some fancy UI that will allow users to interact with FMUs we went for the variant of consuming FMUs in the SCL script directly.
e.g. you just create a static variable of a specific type just like timers and counters. The types however are introduced after you put the FMU in a specific folder under the PS installation folder. Once the FMUs are loaded they are registered in the SCL script engine as standard FB types. When the script calls the FB instance, it on turn calls the FMU instance redirecting all inputs to it. When the call is done the FB redirects all FMU outputs to the script. As an additional benefit we get auto completion and validation for granted since they already work for FBs. Isn't this lovely? Now you can use the FMU in your SCL logic. And we already know that it is quite powerful. Now it is even better!
So what is the difference between a script and an FMU? They both distribute logic. The script is even easier to distribute since it is only text. FMUs should be compiled first. I can imagine the script being supported on different platforms as well. So why bother with FMUs? Well the only downside of scripts is their performance. They tend to be slower compared to compiled code. This is where FMUs shine but when it comes to flexibility and ease of use the script is definitely the winner. So it is a trade-off like everything else in life. The industry seems to prefer the speed over the ease of use.
Lets move on.
The FMI 2.0 standard defined two types of FMUs
Model Exchange FMUs - these define the math behind the problem they address but the host application should provide a numerical solver for them to work. This unfortunately requires some knowledge about the FMU itself.
Co-simulation FMUs - these include everything needed for the simulation to run (including the solvers).
I think you can already guess which ones are supported by Process Simulate? Yes. We only support co-simulation v2.0 FMUs.
So. After all these boring details it is about time to get hands-on experience with the FMUs. The first step is to unzip the FMU (zip) file in a new sub folder under <installation folder>\Scripting\FMI\Vault. You should create this folder since by default it is not there. This had something to do with the setup not being able to create empty folders...
In the following example I am going to use a demo FMU generated with Open Modelica (https://openmodelica.org/). They provide some basic models with the application itself. I'll be using the 'BouncingBall' one. It simulates a ball falling and bouncing off the floor under the force of gravity.
After unzipping the FMU in my development build it looks like this:
Now you start Process Simulate, open/create a line simulation study, select/create a resource and start SCL Editor. Add a static variable and check the available types. There should be a new BouncingBall type in the list. The type name is the model name from the metadata file:
Once you have a variable that holds an instance of the FMU. You can use the variable to call the FMU and exchange data with it. The inputs and outputs are listed in the auto complete candidates for the FMU block. They all appear in the metadata as well.
To call the FMU simply use the variable as a FB providing the inputs and consuming the outputs. In the case of the bouncing ball this looks like this:
#b(h0:=100, e:=0.8, h=>#h);
Inputs are initialized with the assignment (:=) operator while outputs are initialized with the reference (=>) operator. Once this line is executed the FMU will use the inputs to make a single step and then return the current state in the outputs. You can call it multiple times if needed but this would mean that the time on the FMU will run faster than the time in Process Simulate. The length of the FMU step is equal to the logic (LB) update rate in options.
After calling the FMU we have the result of its calculations in a variable inside the SCL script. In the case of the bouncing ball this is the current altitude of the ball provided in millimeters (h). If I don't use it the script will simply do nothing but if I apply this value to a prismatic joint of a kinematic device then I can really see the movement of the ball. And this is actually the intent here. The script should be applied to the device itself to make it move.
To move the joint I rely on the JUMP_JOINT function.
JUMP_JOINT(NAME:='j1', VALUE:=#h*100);
Links should have some geometry assigned so you can really see the motion. Here is how it looks at the end:
Congratulations! Now you have one more tool on your master of simulation belt :)
FMUs are often used to simulate physical processes so having them in PS can be really useful.
Have a wonderful day!
Comments