A Universal Mechanism for Implementing Functional Mock-up Units

Christian Møldrup Legaard

, Daniella Tola

, Thomas Schranz

Hugo Daniel Macedo

and Peter Gorm Larsen

DIGIT, Department of Electrical and Computer Engineering, Aarhus University, Aarhus, Denmark

Graz University of Technology, Graz, Austria

{hdm, pgl}@ece.au.dk

Keywords:

Co-simulation, Functional Mock-up Interface, Functional Mock-up Unit, Tool.

Abstract:

Producing independent simulation units that can be used in a Functional Mock-Up Interface (FMI) setting

is challenging. In some cases, a modelling tool may be available that provides the exact capabilities needed

by exporting such units. However, there may be cases where existing tools are not suitable, or the cost is

prohibitive, thus it may be necessary to implement a Functional Mock-up Unit (FMU) from scratch. Correctly

implementing an FMU from scratch requires a deep technical understanding of the FMI speciﬁcation and the

technologies it is built upon. A consequence of FMI being a C-based standard is that an FMU must, generally,

be implemented in C or a compiled language that offers a binary-compatible with C such as C++, Rust, or

Fortran. In this paper we present UniFMU, a tool that makes it possible to implement FMUs in any language,

by writing an adapter that can be plugged in to our modular approach. UniFMU also provides both a graphical

user interface and command-line interface feature for generating new FMUs from a selection of programming

languages. We expect our tool and approach to be useful for the simulation community both when porting

simulators written in languages without FMI support, and when implementing or re-implementing such sup-

port.

1 INTRODUCTION

When modelling Cyber-Physical Systems (CPSs), it

is advantageous to model different parts using differ-

ent formalisms and tools and then combine the dif-

ferent models as simulation units using co-simulation

(Gomes et al., 2018). One of the most popu-

lar standards for co-simulation is called the Func-

tional Mock-up Interface (FMI) (Modelica Associa-

tion, 2019), which deﬁnes how different simulators

are coupled and a format for packaging simulation

units. A co-simulation combines a number of such

packaged simulation units, termed Functional Mock-

up Units (FMUs), using a master algorithm that com-

bines the simulation of each of the independent simu-

lation units (Thule et al., 2019a; Thule et al., 2019b)

into a joint simulation of the system.

A common way to obtain FMUs is to use FMI-

enabled modelling tools such as OMEdit (Asghar and

Tariq, 2010), Simulink (Simulink09, 2009) or 20-

sim (Controllab Products B.V., 2013) to create models

interactively using a GUI, which can subsequently be

exported as FMUs. While existing tools may cover

the needs of most modelling applications, the need

for specialized FMUs that can only be implemented

by hand will frequently arise. Unfortunately, the pro-

cess of creating an FMU from scratch is cumbersome

and difﬁcult as it requires:

• A deep understanding of the FMI speciﬁcation.

• The code to be implemented in a C-compatible

language.

• Cross-compilation to support multiple platforms.

• Manual creation and synchronization of the mod-

elDescription.xml ﬁle.

• Correct packaging of assets as an FMU archive.

Due to the many pitfalls of this process, it is impracti-

cal for anyone but experts to produce FMUs by hand.

This paper presents an extendable tool called Uni-

versal Functional Mock-up Unit (UniFMU) that facil-

itates the implementation of FMUs in any program-

ming language. Speciﬁcally, our contribution is a tool

that provides:

• Support for Python, C# and Java FMUs out of the

box.

Legaard, C., Tola, D., Schranz, T., Macedo, H. and Larsen, P.

A Universal Mechanism for Implementing Functional Mock-up Units.

DOI: 10.5220/0010577601210129

In Proceedings of the 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2021), pages 121-129

ISBN: 978-989-758-528-9

121

• An easy to use extension mechanism to provide

support for any language.

• CLI to generate template FMUs using a single

command.

• Pre-built binaries for Windows, Linux and ma-

cOS, eliminating the need for cross-compilation

and complex tool-chain setup.

• Flexible conﬁguration of the execution environ-

ment, such as running inside a Docker container

or activating a virtual environment.

• A work in progress GUI for modifying FMU’s

modelDescription.xml ﬁles, eliminating the need

to modify by hand.

The generated FMUs are fully FMI compliant

meaning they can be used in any FMI enabled

co-simulation tool, without making any modiﬁca-

tions. The tool is freely available and can be ac-

cessed in the GitHub repository: https://github.com/

INTO-CPS-Association/ unifmu/.

We expect our tool and approach to be useful for

the simulation community. As we describe in Sec-

tion 5, by implementing one of two available proto-

cols or using one of our language backends a user

porting simulators written in languages without FMI

support can focus on implementing the FMI standard

functionality in his favourite language. Our work

also lowers the complexity required to modeling tool

providers interested in implementing or improve tools

with FMI export capabilities. With our work the tool

can rely on a modular approach where UniFMU deals

with the C API and the export implementation can fo-

cus on providing the model semantics.

In the following, we provide a brief introduction

to related work in Section 2. Then, Section 3 pro-

vides an introduction to FMI with an emphasis on the

implementation of an FMU from scratch. Next, Sec-

tion 4 demonstrates the alternative implementation fa-

cilitated by UniFMU. Next, Section 5 provides the de-

tails of our approach that may be useful to adopters

interested to generate FMUs using our tool. Follow-

ing this Section 6 describes how UniFMU executes

the authors code inside the FMU as well as how the

tool can be extended to support a new language. Sec-

tion 7 then describes how the generated FMUs can be

ran inside a docker container. Finally, Section 8 pro-

vide a few concluding remarks including the planned

future work.

2 RELATED WORK

The difﬁculty of authoring FMUs by hand has led to

the development of several tools that support the au-

Table 1: Overview of tools that can: (i) import and simulate

FMUs, (ii) export models as FMUs.

Name Language Import Export

FMUSDK C x x

FMI++ C/C++ x x

FMI4j Java x x

JavaFMI Java x x

JFMI Java x

PythonFMU Python x

PyFMU Python x

OvertureFMU VDM x

thoring of FMUs. Typically, each tool focuses on sup-

porting a speciﬁc language and implements its own

workﬂow. A selection of this type of tool is seen in

Table 1.

A drawback of using language speciﬁc tools is that

it requires the user to install and learn how to use sev-

eral different tools. Another issue is that these tools

tend to cover only the most popular languages and/or

languages where interoperability with C is easy to im-

plement.

In addition to tools that allow authoring of FMUs,

some simulation tools allow user written code to be

mixed with the code implemented by FMUs. For ex-

ample (fmp, 2021; Widl et al., 2013) allow FMUs to

be imported and simulated in Python. This makes it

possible to insert additional Python code in the simu-

lation loop, essentially implementing a virtual FMU

without the hassle of packaging. Clearly, this ap-

proach for mixing in code is rather limited in terms

of reuse and the inability to mix different languages

in the simulation. Our tool provides a generic way to

generate FMUs that can be used in any FMI enabled

simulation tool.

More relevant are works that provide a separa-

tion between the FMI C-API and the implementation

of the FMU such Proxy-FMU developed in (Hatledal

et al., 2019). Here, the authors propose using remote

procedure calling (RPC) to allow FMUs to run in a

distributed setting, while at the same time removing

restrictions on the FMUs implementation language. A

further development by the same authors is the fmu-

proxify tool that allows existing FMUs to be wrapped

in a way such that it enables distributed co-simulation

in any FMI enabled simulation tool.

Similar to Proxy-FMU our tool also uses RPC as

a mechanism to enable the execution of arbitrary code

inside an FMU. The main contribution of UniFMU is

that the tool ships with support for several languages

that for which template FMUs can quickly be gener-

ated using the CLI. Another distinction is that our tool

makes it easy to run additional commands like select-

ing a speciﬁc virtual environment to run the FMU in-

SIMULTECH 2021 - 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

122

side or deploying it in a docker container as described

in section 7.

3 CREATING AN FMU IN C

One of the most difﬁcult and time consuming aspects

of FMI based co-simulation is implementing models

and packaging them as FMUs. In many cases, free

or commercial tools are available that automate the

conversion of the model into an FMU. However, in

practice there are situations where no tool covering

your particular needs exists. For instance consider use

cases where an FMU would need to:

• Capture input from a operator through a GUI.

• Interact with remote hardware.

• Integrate data-driven components such as neural-

networks.

In such cases it may be necessary to implement the

FMU from scratch in C. As a running example we in-

troduce a simple Adder-FMU that takes the sum of its

two inputs to form its output, as shown in ﬁg. 1. We

chose this example to illustrate the effort required to

implement even the simplest FMU from scratch. Ad-

ditionally, we omit details of how to implement many

of the specialized FMI methods, that require careful

considerations to memory management. Hopefully,

this will be enough to convince the reader that creat-

ing a more complex FMU from scratch would be even

more challenging and time consuming.

Adder

Figure 1: Adder FMU computes c = a + b.

To understand the challenges of generating an

FMU we ﬁrst examine the its structure. In plain terms

an FMU is a zip-archive containing a collection of

ﬁles that together deﬁne the interface and behavior of

a model. A minimal example of how the contents of

the adder FMU zip folder may look like is depicted in

ﬁg. 2.

The folder must contain the functional behavior

of an FMU, which is realized by a shared library

(unifmu.so) located in the binaries directory (one

for each operating system), and a conﬁguration ﬁle,

the modelDescription.xml, stored in the root of

the FMU that provides metadata about the unit. At

runtime, the master algorithm dynamically links the

binary for the speciﬁc platform allowing the mas-

ter to invoke the appropriate methods to get and set

adder c.fmu

binaries

linux64

adder.so

windows64

adder.dll

darwin64

adder.dylib

modelDescription.xml

Figure 2: Directory structure of adder’s C implementation.

variables of the model through the C-API. To obtain

this library several methods declared in the FMI’s C-

headers must be implemented in a C compatible lan-

guage and compiled separately for every platform that

the FMU is expected to be run on. A small selection

of these is seen in listing 1.

1 typ ede f str uct

2 {

3 fmi 2Rea l a ;

4 fm i 2R ea l b ;

5 fm i 2R ea l c ;

6 } Adde r ;

8 void * fm i2 In s t a n t ia te ( con s t c har *

name ,

9 ...)

10 {

11 Adde r * i n st an c e = ma llo c (. . .) ;

12 ret u rn in st a nc e ;

13 }

15 i n t f m i2 Do St ep ( void *c , ... )

16 {

17 Adde r * fmu = c ;

18 f mu -> c = fmu - > a + fmu - >b ;

19 ret u rn fmi 2OK ;

20 }

Listing 1: Implementation of Adder in C.

The code shown in the snippet represents a simpli-

ﬁed implementation of the many details and functions

that must be implemented, and in addition to it we

compile a binary for each architecture including the

FMI standard headers as shown in ﬁg. 3. In addition

to the sheer number of functions that have to be im-

plemented, low-level programming considerations of

memory management and ownership of strings makes

it difﬁcult to implement the functions correctly. This

has been described as one of the challenges of creat-

ing FMUs, as the documentation of the FMI standard

is insufﬁcient (Schweiger et al., 2019; Bertsch et al.,

2014).

The binaries provides the functional behavior of

the model, the modelDescription.xml declares the

A Universal Mechanism for Implementing Functional Mock-up Units

123

fmi2Functions.h

adder.c

compile

adder.so

Figure 3: FMI headers and their implementation compiled

into a shared library.

interface and capabilities of the model. Among other

things, this ﬁle declares inputs and outputs of the

model, their type and their default value. This in-

formation is used by the master algorithm to connect

pairs of inputs and outputs of models during the con-

ﬁguration of a co-simulation. It should be stressed

that in the general case the binary itself is oblivi-

ous to the contents of the modelDescription.xml

ﬁle. As such special care should be taken to en-

sure that the variables declared in the description are

consistent with the implementation. For example if

one of the inputs to the adder is declared as an in-

teger in the description rather than a ﬂoating point

number, the binary would still treat it as a ﬂoating

point number leading to an incorrect output value.

We discuss the issue of ensuring consistency of the

modelDescription.xml further in section 8.

4 CREATING AN FMU IN UniFMU

UniFMU provides a Command Line Interface (CLI)

that can be used to author FMUs in several popular

languages such as Python, C# and Java as shown in

Table 2, and we plan to expand the list of supported

languages in the future. We distinguish between a

backend and a language, since one language can im-

plement multiple backends. We deﬁne a backend as

the method of communication between the UniFMU

wrapper and the FMU. This is described in more de-

tail in Section 5.

Table 2: List of supported languages and backends, * de-

notes default backend.

Language Backends

Python gRPC*, ZeroMQ

C# gRPC

Java gRPC

The CLI is implemented in Python, but it should

be stressed that the generated FMUs do not depend

on Python during simulation (except for FMUs im-

plemented in Python). The tool can be installed using,

pip, the de-facto package manager for Python, using

a single command:

pip i ns t al l u nif m u

The package manager installs the CLI as well as

any resources needed during the generation and run-

time of the FMUs. Alternatively, the tool can be in-

stalled from source using the instructions found in the

associated GitHub repository

To generate an FMU you invoke the program

with the sub-command generate with arguments

specifying the language and name of the exported

FMU. For example to generate an FMU named

python adder.fmu in Python the following com-

mand can be used:

uni fmu ge ne rat e pyt h on py th on _a dd er . fmu

Executing this command creates an FMU with the

ﬁle structure shown in ﬁg. 4. The generated FMU is

fully functional and serves as a template that can be

modiﬁed to implement the desired behavior for the

model.

adder.fmu

binaries

darwin64

linux64

unifmu.so

windows64

resources

model.py

backend grpc.py

fmi2.py

launch.toml

modelDescription.xml

Figure 4: Python FMU directory tree.

denotes backend,

denotes implementation.

An important difference between an FMU imple-

mented in C and one implemented using UniFMU

is that the behavior of the model is not deﬁned by

the binaries, but rather by the ﬁle(s) stored in the

resources folder. This makes it possible to reuse the

same binaries for all FMUs, independently of the lan-

guage that they are implemented in. These binaries

are pre-compiled and shipped with the tool for Linux,

Windows and macOS. Two beneﬁts of this is that the

FMU can run on all platforms without any additional

effort from the author and that it is not necessary to

install a compiler tool-chain.

The model.py ﬁle shown in ﬁg. 4 implements the

functionality of the FMU. Inspecting the code inside

of the model.py FMU, the most relevant function is

do step shown in listing 2.

https://github.com/INTO-CPS-Association/unifmu

SIMULTECH 2021 - 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

124

1 clas s M odel ( Fm i 2F MU ):

2 de f _ _ in it_ _ ( se l f ) :

3 self .a = 0.0

4 self .b = 0.0

5 self . _u pd at e_ o u t p u t s ()

7 de f _ up da te _ o u t p ut s ( se l f ) :

8 self .c = sel f . a + s e lf . b

10 de f e x i t _i n i t ia l i z at i o n _m o d e (

self ):

11 self . _u pd at e_ o u t p u t s ()

12 re t urn F mi 2 S t at us . ok

14 de f do _st ep ( self , ... ) :

15 self . _u pd at e_ o u t p u t s ()

16 re t urn F mi 2 S t at us . ok

Listing 2: model.py implementation.

It contains the addition operation functionality

provided by the FMU, and the variables a and b are

the inputs to the FMU, and the variable c is an output

variable containing the result of the addition of the

two inputs. These variables and their types are all

deﬁned in the modelDescription.xml ﬁle.

In addition to the CLI, UniFMU can be launched

as a GUI, seen in ﬁg. 5, using the subcommand:

uni fmu gui

The GUI is currently work in progress, and can

so far be used to access the same functionality as the

CLI. The vision is to extend this GUI to be able to

declare and modify the variables corresponding to the

contents of the modelDescription.xml.

Figure 5: GUI for UniFMU.

5 HOW DOES IT WORK?

The main motivation behind UniFMU is to allow ar-

bitrary code written in any language to be executed

within an FMU. The mechanism used by the tool is

to provide a generic binary that spawns a separate

process for each instantiated slave during runtime.

Unlike the binary, the spawned processes aren’t re-

stricted to the narrow set of compiled languages that

are conventionally used to implement FMUs. This

opens the possibility for using interpreted languages

or languages that rely on a garbage collector to man-

age memory.

In order to forward the FMI calls from the mas-

ter algorithm to the concrete implementation provided

slave processes a remote procedure call (RPC) based

on gRPC

is used to pass commands from the binary

to the slave process. Seen from the perspective of the

master algorithm this additional layer of indirection

is totally opaque, meaning that FMUs produced by

the tool can be used in any FMI compliant simulation

tool.

Comparing this with the conventional approach,

we add an extra layer between the master algorithm

and the FMU itself. The comparison between the

conventional and UniFMU approach is illustrated in

ﬁg. 6. In both approaches the master algorithm com-

Master

algorithm

FMU

binary

Master

algorithm

UniFMU

wrapper

FMU slave

C API

RPC

Conventional

FMU

UniFMU

C API

Figure 6: Conventional versus UniFMU approach.

municates with the binary ﬁles through the C API that

implements the FMI standard. The difference is that

the UniFMU wrapper ”translates” these C API calls

to messages that can be exchanged through a RPC,

such as gRPC or ZeroMQ. Only one of these two

backends is necessary to implement when supporting

a new language. The speciﬁc backend used is deﬁned

in the conﬁguration ﬁle of the FMU, as shown in the

launch.toml ﬁle in listing 3. In addition to the back-

end, the launch.toml ﬁle speciﬁes the command used

to start the backend process. It is possible to spec-

ify different commands based on different OSs, since

they may require a different setup.

1 [grpc]

2 linux = ["python3", "backend_grpc.py"]

3 macos = ["python3", "backend_grpc.py"]

4 windows = ["python", "backend_grpc.py"]

Listing 3: launch.toml.

gRPC. Is a RPC that is based on HTTP/2 for trans-

porting messages, and Protocol Buffers (protobuf)

for describing the information in the messages as a

https://grpc.io/

https://developers.google.com/protocol-buffers

A Universal Mechanism for Implementing Functional Mock-up Units

125

schema. An example of the DoStep schema, deﬁned

in the protobuf ﬁle, is illustrated in listing 4.

1 se r vi c e Se nd Co mm an d {

2 rp c F m i 2 Do St ep ( DoS tep )

3 re tur ns ( S t a t u s Re tu rn ) {}

4 }

5 me s sa g e DoS t ep {

6 do u ble c ur re nt _t im e = 1;

7 do u ble s te p _s iz e = 2;

8 bool no _s te p_ p r i o r = 3;

9 }

Listing 4: Structure of DoStep message and Fmi2DoStep

call in protobuf schema.

ZeroMQ. ZeroMQ

is a networking library that al-

lows messages to be transmitted efﬁciently across

transport layers such as TCP or as Inter Process Com-

munication. Unlike the gRPC backend there is no

explicit schema-ﬁle that dictates the structure of the

messages. Instead, the messages are structured ac-

cording to a simple protocol described in the devel-

oper documentation found in the UniFMU repository.

The serialization of the messages is performed by the

Serde

library. This makes it possible to automati-

cally generate high-performance serialization for sev-

eral formats such as:

• JSON

• Pickle

• Flatbuffers

For dynamically typed languages such as Python or

JavaScript the schemaless approach may be simpler

to implement.

The main difference between these two backends

is that gRPC uses a protobuf schema, while ZeroMQ

is schemaless. Using a schema to deﬁne the messages

and calls between the UniFMU wrapper and the FMU

allows to declare the types of each message. This re-

duces the risk of using incorrect types when imple-

menting the functions, easing the process of creating

FMUs in statically-typed languages.

To understand the ﬂexibility of this approach, it is

useful to examine the process for creating an instance

of an FMU, and the forwarding of the FMI commands

from the binary to the slave instance, as depicted in

ﬁg. 7.

First the master algorithm invokes the

fmi2Instantiate function deﬁned by the binary.

Following this, the wrapper reads the launch.toml

ﬁle, which is present in any FMU generated by

UniFMU. This is the conﬁguration ﬁle which deﬁnes

https://zeromq.org/

https://serde.rs/

:unifmu.so

read launch.toml

:Master

slave started

:slave 1

python3

backend_grpc.py

fmi2Ok

fmi2Instantiate

[command.Grpc]

linux=["python3", "backend_grpc.py"]

macos = ...

windows = ...

fmi2EnterInitalizationMode fmi2EnterInitalizationMode

Figure 7: Instantiation of slave and forwarding of FMI

method calls.

the details about which communication backend is

used to communicate with the slave process and

even more importantly the speciﬁc command used

to spawn the process. The launch.toml ﬁle in ﬁg. 7

shows how the commands deﬁned in the ﬁle are used

to instantiate a Python FMU. For example an FMU

implemented in Python using the gRPC backend

would use the following command to launch the slave

process:

pyt ho n 3 ba ck en d_ gr pc . py

Here the backend grpc.py script serves as an im-

plementation by implementing the Fmi2DoStep com-

mand, deﬁned in the protobuf schema shown in list-

ing 4. The DoStep message declares the parameters

used in the Fmi2DoStep command. The complete

protobuf schema can be found in our GitHub repos-

itory.

6 HOW TO EXTEND SUPPORT

TO A NEW LANGUAGE?

There may be cases where a user would like to imple-

ment an FMU in a language not yet supported by the

tool. One of the advantages of UniFMU is that new

languages can be added without making any modiﬁ-

cation to the binaries of the FMU. This section shows

the steps followed to extend the UniFMU support to

include C# by implementing a gRPC backend. We

chose the gRPC option, because a schema based se-

rialization format like the one used by gRPC is es-

pecially suitable for compiled languages as it allows

SIMULTECH 2021 - 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

126

messages to be constructed using strongly typed ob-

jects. Following our running example, we will use the

adder introduced in section 3 as a concrete example.

The implementation of the gRPC backend in C#

amounts to implement the remote procedure calls de-

ﬁned in unifmu fmi2.proto ﬁle under schemas in the

repository

. The protobuf compiler, protoc, is then

used to compile the UniFMU protobuf schema into

C# code, as illustrated in ﬁg. 8.

unifmu_fmi2.proto protoc

UnifmuFmi2.cs

...

Figure 8: Generate C# ﬁles containing the protobuf schema.

The next steps are to create a base class of the

FMI2 functions and implement the functionality of

the adder. This can easily be done by translating these

implementations from Python to C# code. The adder

derives functions from the FMI2 base class, thus the

speciﬁc implementations of the FMI2 functions are

implemented in each FMU. After this, the gRPC

server is coded, implementing the functions that were

generated from the protobuf schema and calling them

on the adder. A snippet of the Fmi2DoStep function

implementation in the gRPC server is shown in ??.

1 pub lic ov er rid e Task < S t at u sRe tur n >

2 F m i2 Do St ep ( DoS tep request ,.. . )

3 {

4 F m i2 St at us st a tu s =

5 this . fmu . D o St e p (

6 re que st . C urr ent T ime ,

7 re que st . S t epSize ,

8 re que st . No St ep P r i o r ) ;

9 .. .

10 }

Listing 5: gRPC server implementation of Fmi2DoStep.

The Fmi2doStep implementation is the only nec-

essary function to implement in the adder, since this

is where the core functionality is described. Listing 6

shows the Fmi2doStep implementation of the adder.

https://github.com/INTO-CPS-Association/unifmu/

1 pub lic ov er rid e Fm i2 S t a tu s DoS t ep (

2 do u ble cu r ren tTi m e , ...)

3 {

4 this .c = thi s . a + t h is . b ;

5 re t urn F mi 2 S t at us . Ok ;

6 }

Listing 6: C# example of fmi2doStep implementation.

One of the last steps is to implement the hand-

shake connection that will be performed between the

UniFMU wrapper and the FMU itself. This can be

done in the backend grpc.cs ﬁle, where the speciﬁc

FMU to initialize can also be deﬁned. The last step is

to deﬁne the commands to be called for initialization

of the FMU in the launch.toml ﬁle.

When generating a new C# FMU, the ﬁle structure

will be as illustrated in ﬁg. 9, where the adder.cs ﬁle

can be exchanged for any other C# ﬁle.

adder csharp.fmu

binaries

resources

schemas

model.cs

backend grpc.cs

fmi2.cs

csharp.csproj

launch.toml

modelDescription.xml

Figure 9: C# FMU directory tree.

denotes backend,

denotes implementation.

As we have demonstrated in this section, there is

no need to write any C/C++ code when creating a new

backend for UniFMU. The work amounts to imple-

ment a gRPC server using the protobuf schema and

an abstract class containing the FMI2 function decla-

rations.

7 EXECUTING FMUs INSIDE

DOCKER CONTAINER

Invoking code from within an FMU needs the host

machine to provide the necessary runtime environ-

ment to do so. For example, running python scripts re-

quires that the host machine has a compatible python

interpreter and all libraries used in the scripts in-

stalled. This limits the portability of the FMUs, espe-

cially when shared between different host machines,

potentially running different operating systems.

To mitigate this issue runtime dependencies can

be packaged into a virtualization environment such

A Universal Mechanism for Implementing Functional Mock-up Units

127

as docker

. A detailed description of the extension

and more advanced topics, such as remote deploy-

ment, building and deployment settings can be found

in (Schranz et al., 2021). In essence, to dockerize

there is no need to change the wrapper code, all of the

necessary actions are performed using a short script

(run.sh for unix, run.ps1 for Windows), as seen in

Listing ??. The script builds a docker image using

the FMUs global unique identiﬁer and runs it. Once

the wrapper disconnects, the process terminates, the

container is stopped and disposed. The actions within

the Dockerﬁle depend on the choice of backend. An

adaptation to the framework to support all backends

is under development.

To dockerize the FMU, the commands given in the

launch.toml can be set to run a shellscript:

1 [grpc]

2 linux = ["/bin/bash", "run.sh" ]

3 macos = ["/bin/bash", "run.sh" ]

4 windows = ["powershell", ".\\run.ps1"]

1 # !/ bin / sh

2 . . .

3 # buil d i mag e

4 doc ker bui l d -t "$uid " .

5 # ru n co nt ai n er

6 doc ker run -- net = h o st - - rm .. .

Listing 7: Shell script, run.sh, used to deploy docker con-

tainer on unix.

8 CONCLUDING REMARKS AND

FUTURE WORK

In this paper we have introduced the tool UniFMU

that makes it possible to implement FMUs in several

languages with built-in support by the tool. We have

demonstrated the process of creating an FMU in a

supported language, Python, and have demonstrated

the process for extending the tool to support C#.

This makes it possible to produce FMUs with limited

knowledge of the internal workings and with limited

knowledge of C. In the future we hope to be able to

use a similar Java extension to enable the Overture

FMU (Thule et al., 2018) export to be moved over

to the Visual Studio Code VDM substantiation (Rask

et al., 2020).

One issue not discussed in the paper is perfor-

mance. Invoking functions of an FMU using RPC in-

stead of calling them directly through the C-ABI in-

curs a performance cost. As part of (Hatledal et al.,

https://www.docker.com/

2019) the authors provide the results of experiments

where the total simulation time of multiple FMUs is

measured for the two approaches. The results seem

to indicate that there is an almost constant overhead

per RPC call resulting in the largest impact on mod-

els that must be simulated with small step sizes. A

possible way to reduce the performance overhead is

to reduce the total number of RPC calls. For example

several FMI calls made in between two fmi2DoStep

calls could be grouped and sent as a single message,

since the outputs would not change in between.

UniFMU provides a way to package and execute

arbitrary code inside of an FMU. However, it does not

directly provide a way to ensure consistency between

the model description and the code. Other works

like (Legaard et al., 2020; Hatledal et al., 2020) solve

this issue by declaring the interface in the implemen-

tation of the FMU and using code generation targeted

for speciﬁc languages to export the model descrip-

tion. This approach cannot readily be applied for a

large number languages without implementing with-

out implementing code generation for each language

individually. There is a work in progress GUI, where

it is possible to import the FMU, and using the editor

manage the input and output variables of the model

description, as shown in ﬁg. 5.

In addition to the standalone GUI for the tool, it is

possible to bundle the offering in the INTO-CPS As-

sociation services, for instance in the front-end used

to setup and launch co-simulations using MAESTRO,

the INTO-CPS Application (Macedo et al., 2020; Ta-

lasila et al., 2020). It is also a possibility to enable

the Model-Based Design of Cyber-Physical Systems

community to use and make the tool available in the

HUBCAP project cloud platform (Larsen et al., 2020;

Kulik et al., 2020).

ACKNOWLEDGEMENTS

We acknowledge the funding from the Poul Due

Jensen Foundation for funding the project Digital

Twins for Cyber-Physical Systems (DiT4CPS).

REFERENCES

(2021). CATIA-Systems/FMPy. CATIA Systems.

Asghar, S. A. and Tariq, S. (2010). Design and implemen-

tation of a user friendly OpenModelica graphical con-

nection editor. page 81.

Bertsch, C., Ahle, E., and Schulmeister, U. (2014). The

Functional Mockup Interface – seen from an industrial

perspective. pages 27–33.

SIMULTECH 2021 - 11th International Conference on Simulation and Modeling Methodologies, Technologies and Applications

128

Controllab Products B.V. (2013). http://www.20sim.com/.

20-sim ofﬁcial website.

Gomes, C., Thule, C., Broman, D., Larsen, P. G., and

Vangheluwe, H. (2018). Co-simulation: a Survey.

ACM Comput. Surv., 51(3):49:1–49:33.

Hatledal, L., Zhang, H., and Collonval, F. (2020). Enabling

python driven co-simulation models with pythonfmu.

pages 235–239.

Hatledal, L. I., Styve, A., Hovland, G., and Zhang,

H. (2019). A Language and Platform Independent

Co-Simulation Framework Based on the Functional

Mock-Up Interface. IEEE Access, 7:109328–109339.

Hatledal, L. I., Styve, A., Hovland, G., and Zhang,

H. (2019). A Language and Platform Independent

Co-Simulation Framework Based on the Functional

Mock-Up Interface. IEEE Access, 7:109328–109339.

Conference Name: IEEE Access.

Kulik, T., Macedo, H. D., Talasila, P., and Larsen, P. G.

(2020). Modelling the HUBCAP Sandbox Architec-

ture In VDM – a Study In Security. In Fitzgerald, J. S.

and Oda, T., editors, Proceedings of the 18th Interna-

tional Overture Workshop, pages 20–34. Overture.

Larsen, P. G., Macedo, H. D., Fitzgerald, J., Pfeifer, H.,

Benedikt, M., Tonetta, S., Marguglio, A., Gusmeroli,

S., and Jr., G. S. (2020). An Online MBSE Collabo-

ration Platform. pages 263–270. INSTICC, Proceed-

ings of the 10th International Conference on Simula-

tion and Modeling Methodologies, Technologies and

Applications - Volume 1: SIMULTECH.

Legaard, C. M., Gomes, C., Larsen, P. G., and Foldager,

F. F. (2020). Rapid Prototyping of Self-Adaptive-

Systems using Python Functional Mockup Units.

SummerSim ’20. ACM New York, NY, USA.

Macedo, H. D., Rasmussen, M. B., Thule, C., and Larsen,

P. G. (2020). Migrating the INTO-CPS Application

to the Cloud. In Sekerinski, E., Moreira, N., Oliveira,

J. N., Ratiu, D., Guidotti, R., Farrell, M., Luckcuck,

M., Marmsoler, D., Campos, J., Astarte, T., Gonnord,

L., Cerone, A., Couto, L., Dongol, B., Kutrib, M.,

Monteiro, P., and Delmas, D., editors, Formal Meth-

ods. FM 2019 International Workshops, pages 254–

271, LNCS 12233. Springer-Verlag.

Modelica Association (2019). Functional Mock-up Inter-

face for Model Exchange and Co-Simulation. https:

//www.fmi-standard.org/downloads.

Rask, J. K., Madsen, F. P., Battle, N., Macedo, H. D., and

Larsen, P. G. (2020). Visual Studio Code VDM Sup-

port. In Fitzgerald, J. S. and Oda, T., editors, Pro-

ceedings of the 18th International Overture Workshop,

pages 35–49. Overture.

Schranz, T., Alfalouji, Q., Falay, B., Legaard, C., Wilﬂing,

S., and Schweiger, G. (2021). Coupling physical and

machine learning models: Case study of a residential

building. In 14th International Modelica Conference

(Submitted Manuscript).

Schweiger, G., Gomes, C., Engel, G., Hafner, I., Sch

oggl,

J.-P., Posch, A., and Nouidui, T. (2019). Functional

Mock-up Interface: An empirical survey identiﬁes re-

search challenges and current barriers.

Simulink09 (2009). Simulink - Sim-

ulation and Model-Based Design.

http://www.mathworks.com/products/simulink/.

Talasila, P., Sanjari, A., Villadsen, K., Thule, C., Larsen,

P. G., and Macedo, H. D. (2020). Introducing Test

Driven Development and Upgrades to the INTO-CPS

Application. In Cleophas, L. and Massink, M., editors,

Software Engineering and Formal Methods. SEFM

2020 Collocated Workshops, pages 311–317, Cham.

Springer International Publishing.

Thule, C., Lausdahl, K., Gomes, C., Meisl, G., and Larsen,

P. G. (2019a). Maestro: The INTO-CPS co-simulation

framework. Simulation Modelling Practice and The-

ory, 92:45–61.

Thule, C., Lausdahl, K., and Larsen, P. G. (2018). Over-

ture FMU: Export VDM-RT Models as Tool-Wrapper

FMUs. In Pierce, K. and Verhoef, M., editors, The

16th Overture Workshop, pages 23–38, Oxford. New-

castle University, School of Computing. TR-1524.

Thule, C., Palmieri, M., Gomes, C., Lausdahl, K., Macedo,

H. D., Battle, N., and Larsen, P. G. (2019b). To-

wards Reuse of Synchronization Algorithms in Co-

simulation Frameworks. In Co-Sim-19 workshop.

Widl, E., M

uller, W., Elsheikh, A., H

ortenhuber, M., and

Palensky, P. (2013). The FMI++ library: A high-

level utility package for FMI for model exchange.

In 2013 Workshop on Modeling and Simulation of

Cyber-Physical Energy Systems (MSCPES), pages 1–

A Universal Mechanism for Implementing Functional Mock-up Units

129