The FMI (Functional Mockup Interface) 3.0 standard and its support in Model.CONNECT?

The FMI (Functional Mockup Interface) 3.0 standard and its support in Model.CONNECT?

Every Saturday, Thomas Glatz and Michael Bambula are excited to bring the developers on stage and provide you an extended read into various simulation topics.


by Klaus Schuch

Eight years after the release of the well adopted FMI 2.0 standard, the FMI 3.0 standard was released in May 2022.

FMI 3.0 offers many new features to cover new (or improve already available) use-cases.

In this article, I will introduce some of these features and show how these are covered in Model.CONNECT?.

Array variables

In former versions of the FMI standard, only scalar variables were supported. Array variables could be expressed by using naming conventions and creating a scalar variable for each element of the array. The scalar variables x[1], x[2] and x[3] could be visualized as a vector x of length 3. Note that such a naming convention does not allow a resizing of the vector after the FMU was created. FMI 3.0 supports array variables natively: Each variable can have a constant number of dimensions (thus making the variable a multidimensional array variable). The size of a dimension can either be constant or may reference a so called structural parameter. A simple example for using arrays is a generic matrix multiplication FMU. Such an FMU exposes two structural parameters (m and n), defining the size of the 1-dimensional input variable u, the size of the 1-dimensional output variable y and the sizes of the 2-dimensional array (matrix) parameter variable A.?

Figure 1

A more practical FMU for typical simulation tasks is a generic FMU that represents a linear time invariant (LTI) system. Such an FMU can be parametrized by three structural parameters (number of inputs, outputs and states) and four matrices (A, B, C, D).

Figure 2

Intermediate Variable Access

FMI 3.0 introduces the Intermediate Update Mode, which allows the FMU to exchange intermediate values of variables with the importer tool. While executing a simulation step (within a fmi3DoStep() function call), the FMU can call back into the importer to enter this mode and ask the importer to update its continuous input variables and allow the importer to query its continuous output variables. This callback mechanism allows the FMU to maintain its internal solver state while new continuous inputs are being set. The intermediate values of an output of the FMU are used to improve the inter-/extrapolation of the inputs of other elements of the model connected to this output port.

Figure 3

Data Types

FMI 3.0 supports a large set of integer types (signed and unsigned, from 8 to 64 bit) and both 32-and 64-bit floating-point variables. Moreover, binary variables have been introduced to allow the efficient exchange of non-numeric values. Binary variables can be attributed in the modelDescription.xml with a mime Type to allow proper interpretation of their content. This opaque binary data supports, for example, the efficient exchange of complex sensor data in ADAS simulation models.

Figure 4

In Figure 4 you can see a show-case example where FMUs with binary variables are used to perform a face detection task.

Hybrid Co-Simulation (Co-simulation with events)

The importing tool calls the step function of a co-simulation FMU to instruct the FMU to make a step of size deltaT. An FMU can now return from a fmi3DoStep call early and inform the importer about the occurrence of an event. An event indicates a discrete change of the internal state or of outputs of the FMU. Such an event could for example be a gear shift or a clutch that switches from slipping to sticking. To ensure good simulation results, the connected elements of the co-simulation model should get informed as soon as possible about the changed values.

Figure 5

Terminals and Icons

An FMI 3.0 FMU can declare so called terminals in its description file. A terminal groups inputs and outputs into a named entity. Model.CONNECT reads the provided terminals and creates corresponding bundles. Additionally, an FMU can now contain an icon file.


As much as we love to nerd out about simulation and read lengthy articles about it, we have to cut it short at this point.

We want to thank Klaus Schuch for the insights and the impressive work that is performed day to day behind the scenes.

Real-world activities and their real-time limitations bring this Simulation Saturday to an end, but stay tuned for another one soon!

Cheers, Thomas and Michael


?What’s next:

You tell us!

Which simulation topic are you particularly interested?

What features would you love to see?

What do you love or hate most about the tool(s) you use?

We love to hear all of it in the comments and encourage you to: - learn more on our product sites:?AVL Advanced Simulation Technologies Tools - try it:?Rescale - simulate for free via?AVL University Partnership Program as a student and academic researcher. - get in contact via [email protected] and [email protected]

?

?


Thomas G.

?? Simulation Technologies Expert | AI & Startup Enthusiast | Biz Dev + Chemical Engineer + Software Dev | Driving Virtualization across Teams in Mobility & Energy | Austrian Mountains, Florida Nature and ??

11 个月

In a time before FMUs it was ridiculously hard to share and combine models from different users and various simulation tools. In a nutshell what USB did for hardware, FMI did for the simulation industry. ??

要查看或添加评论,请登录

AVL in North America Simulation的更多文章

社区洞察

其他会员也浏览了