See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/341798839

Enabling Python Driven Co-Simulation Models With PythonFMU

Conference Paper · June 2020

DOI: 10.7148/2020-0235

CITATIONS READS

10 1,143

3 authors, including:

Lars Ivar Hatledal Houxiang Zhang

Norwegian University of Science and Technology Norwegian University of Science and Technology
32 PUBLICATIONS   310 CITATIONS    248 PUBLICATIONS   2,947 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

A Flexible and Common Control Architecture for Rolls-Royce Marine Cranes and Robotic Arms (2012-2013) View project

RFFMIDT project(2019): Dynamic Motion Planning Based on Trajectory Prediction View project

All content following this page was uploaded by Lars Ivar Hatledal on 22 July 2020.

The user has requested enhancement of the downloaded file.

 ENABLING PYTHON DRIVEN
CO-SIMULATION MODELS WITH
PYTHONFMU
Hatledal, Lars Ivar* Collonval, Frédéric
Zhang, Houxiang Modeling & Simulation
Department of Ocean Operations and Civil Engineering Safran Tech
Norwegian University of Science and Technology CS80112 Chateaufort
Postbox 1517, 6025 Aalesund, Norway 78772 Magny Les Hameaux, France

KEYWORDS • C-code implementing a set of functions defined by

Co-simulation; Modelling; FMI; FMU; Python the FMI standard.
• Other optional resources required by the model im-
ABSTRACT plementation.
The FMI standard consists of two main parts, both
This paper introduces PythonFMU, an easy to
of which a single FMU may support:
use framework for exporting Python 3.x code as co-
• FMI for ME: Models are exported without solvers
simulation compatible models compliant with version
and are described by differential, algebraic, and discrete
2.0 of the Functional Mock-up Interface (FMI). The
equations with time-, state-, and step-events.
framework consists of a set of helper classes and
• FMI for CS: Models are exported with a solver, and
a command line utility for transforming compliant
data is exchanged between subsystems at discrete com-
python source into ready to use cross-platform FMUs.
munication points. In the time between two communi-
PythonFMU seamlessly takes care of a number of low-
cation points, the subsystems are solved independently
level FMI functions such as getting and setting variable
from each other.
values, and state handling, including serialization and The work presented in this paper, however, is only
deserialization. Furthermore it provides pre-built bi- concerned about the co-simulation part of the standard.
naries for Windows and Linux 64-bits, generates the Many tools support importing co-simulation FMUs,
required modelDescription.xml containing meta-data however, fewer tools supports exporting such FMUs.
about the model and packages all related files into a Many of whom are commercial and or domain specific.
Functional Mock-up Unit (FMU) - ready to be im- Furthermore, FMUs generated with these tools may
ported into any FMI compatible simulation tool. The not support the optional parts of the standard such
framework can be effortlessly installed using de-facto as state handling, which are required by some more
standard Python package managers pip and conda. advanced co-simulation algorithms in order to achieve
While PythonFMU is more geared towards ease of use better numerical accuracy and stability during simula-
and enabling Python driven co-simulation models, it tions[Broman et al., 2013, Cremona et al., 2016, Tavella
is shown to have adequate performance compared to et al., 2016].
much more low-level alternatives targeting other pro-
gramming languages.

INTRODUCTION
The Functional Mock-up Interface (FMI) [Blochwitz
et al., 2012] is a tool independent standard managed
by the Modelica Association that supports both Model
Exchange (ME) and Co-Simulation (CS) of dynamic
models. A key goal of FMI is to improve the exchange
of simulation models between suppliers and original
equipment manufacturers (OEMs). The current ma-
jor version of the standard is 2.0, which was released in
2014. A minor revision, 2.0.1, was released in 2019.
Fig. 1: Possible use of PythonFMU in realizing complex
An FMU is a model that implements the FMI stan-
cyber-physical systems using FMI based co-simulation.
dard and is distributed as a zip-file with the extension
.fmu. This archive contains:
Python [Van Rossum et al., 2007] is one of the most
• An XML-file that contains meta-data about the
popular programming language today [O’Grady, 2020].
model, named modelDescription.xml.
The major reasons for that are the ease of learning the
*Corresponding author. E-mail: [email protected] language, the huge spectra of libraries covering fields
such as video game, machine learning, web server or ME and provides utilities for packaging the model as
scientific computing and the recent explosion of data an FMU, whereas CPPFMU only provides helper func-
science in which Python plays a central role. Of partic- tions to aid in development.
ular importance for scientific computing is the creation
JavaFMI [Galtier et al., 2017] is a set of compo-
of the Numpy[Oliphant, 2007] library that bridge the
nents for working with the FMI standard using Java,
gap between efficient code in C or Fortran languages
developed by SIANI institute (Las Palmas University)
and the ease of a scripting language. That library is
and funded by the European Institute for Energy Re-
now at the heart of all major scientific Python libraries
search (EIFER). It support both import and export
from Pandas for data analysis to Scipy for classical alge-
of FMUs. For export, it support FMI 2.0 for Co-
bra operators or Scikit-learn for machine learning anal-
simulation. Generated FMUs runs both on Linux and
ysis.
Windows. JavaFMI has been actively maintained since
This paper introduces PythonFMU, an easy to use its inception in 2013 and is licensed under the LGPLv3.
Python based framework that allows plain Python code
to be exported as FMI compatible co-simulation FMUs. FMI4j [Hatledal et al., 2018] is a MIT licensed soft-
Figure. 1 shows how PythonFMU could potentially be ware package for dealing with Functional Mock-up
used to implement complex cyber-physical systems that Units (FMUs) on the JVM. It support both import
are aggregates of models from different simulation do- and export of FMUs. For export, it support FMI 2.0
mains. for Co-simulation. FMI4j is written in Kotlin, which
The paper is organized as follows. Firstly some re- is 100% interoperable with Java. On the native side,
lated works are given. After which PythonFMU is in- FMI4j makes use of CPPFMU to implement the FMI
troduced. Then some benchmark results are presented. functions. FMUs generated using FMI4j can run on
Finally some concluding remarks and notes on future both Linux and Windows.
works are provided. While both JavaFMI and FMI4j allows FMUs to be
created using the Java language, they differ quite a
RELATED WORK bit in their implementation and usage. JavaFMI uses
A number of open-source software frameworks for ex- message-passing to bridge Java and the underlying C
porting FMUs from source-code have been developed in functions defined by FMI, while FMI4j relies on the
the recent years. While many more tools are capable of Java Native Interface (JNI) for this. Consequentially,
exporting FMUs like 20Sim, OpenModelica, MATLAB FMI4j generates much faster executables. Another key
and SimulationX, this paper is more focused on frame- difference is how users define their model. JavaFMI is
works that allows the generation of FMUs from plain imperative, e.g meta-data is defined using API func-
source-code. Each of these are described in more detail tions. FMI4j on the other hand is declarative, with
below. meta-data defined using annotations.
CPPFMU [SINTEF Ocean, 2017] is a set of inter- Evidently, some open-source software for generating
faces and helper functions for writing FMI-compliant FMUs from source code already exists. See Table. I
model/slave code in C++ using high-level features for a summary. However, only the ones targeting the
such as exceptions and automatic memory manage- JVM can be said to be easy to use as these manages
ment, rather than having to implement the low-level C everything related to the creation of an FMU. Still, the
functions specified by FMI. However, while CPPFMU JVM may not be a natural choice for many for imple-
makes implementing and compiling the shared library menting models and the barrier for using these tools are
required by an FMU, it does not handle generating high for non Java developers. CPPFMU and FMUSDK
the modelDescription.xml nor packaging of the FMU. both eases the process within the realm of C/C++, but
CPPFMU was developed as part of the R&D project still requires significant know-how in order to produce a
Virtual Prototyping of Maritime Systems and Opera- ready to use FMU. Furthermore, these tools only covers
tions (ViProMa) Hassani et al. [2016], and is currently a small subset of available programming languages.
maintained by SINTEF Ocean.
FMUSDK [QTronic, 2017] is a free, BSD licensed,
software development kit (SDK) provided by QTronic TABLE I: Open-source framework for exporting source-
to demonstrate basic use of FMUs for ME and for CS code as FMUs.
as defined by FMI version 1.0 and 2.0. The software is
written in C++, but models are to be implemented in Target Target FMI
Tool
C. The first version of FMU SDK was released already language platform version
in 2010, with the latest version, 2.0.6, being released in JavaFMI JVM Win, Linux 2.0
2018. FMI4j JVM Win, Linux 2.0
Like CPPFMU, FMUSDK does not auto-generate CPPFMU C++ Wina , Linuxa 1.0 & 2.0
the modelDescription.xml. The main difference be- Wina , Linuxa ,
FMUSDK C 1.0 & 2.0
tween these tools is that CPPFMU provides a more OSXa
high level and structured API in C++, whereas a
Binaries are only built for the current platform.
FMUSDK requires source-code to be written in quite
low-level C. On the other hand, FMUSDK supports
PYTHONFMU ing. 2 shows how to build an FMU from Python source
that implements the PythonFMU API using the accom-
PythonFMU is a MIT licensed framework that en-
panying CLI. Additional options may be specified, such
ables the packaging of Python 3.x code as co-simulation
as documentation and associated project files. The
FMUs, currently maintained in collaboration between
FMU built by PythonFMU contains pre-built binaries
NTNU and Safran Tech. The library required by users
for Windows and Linux 64-bit. This lowers the thresh-
to implement their own FMI co-simulation slaves as
old for using it tremendously compared to many ex-
well as the Command Line Interface (CLI) required
porting tools as a C++ compiler does not have to be
to build the actual FMU is easily retrieved using ei-
installed and the user does not have to figure out how
ther the pip or conda package managers. Unlike some
to cross-compile.
FMU exporters, FMUs built with PythonFMU runs
Like FMI4j, PythonFMU makes use of CPPFMU
out of the box on both Windows and Linux 64-bit sys-
for implementing the C functions required by the FMI
tems. PythonFMU has been implemented using the
standard. This shows a clear utility for CPPFMU as
limited Python API, which makes it compatible with
an enabler for higher-level applications to support the
any Python 3.x version. However, PythonFMU does
export of FMI compatible co-simulation models.
not bundle a Python distribution, which means that a
compatible Python distribution must be present on the
target system for the FMU to work. The same is true Listing 2: Building an FMU from Python source using
for any imported 3rd party libraries. Consequentially, the PythonFMU CLI.
if the slave makes use of e.g. the numpy package for sci- pythonfmu−b u i l d e r −f PythonSlave . py
entific computing, this library must already be present
on the target system. To remedy this, PythonFMU al-
lows users to specify any dependency it should have on
3rd party libraries. This information is bundled with RESULTS
the FMU as a standard requirements.txt for use with In the following some performance metrics for
one of Python’s package managers. Thus allowing end- PythonFMU is given.
users to easily figure out what kind of libraries that Table. II show the performance of PythonFMU com-
must be installed for it to run on a particular machine. pared to other similar tools. The FMUs used all imple-
ments the same model. The model does no computa-
tion during stepping, but defines a single real, integer,
Listing 1: Writing FMI 2.0 compatible slaves in Python boolean and string variable. These variables are read
using PythonFMU. by the importing tool after each iteration. 100.000 iter-
from pythonfmu im po rt ∗ ations were run. That makes for a total of 400.000 calls
through the FMI API. The benchmark was performed
c l a s s PythonSlave ( Fmi2Slave ) :
on a computer running Windows 10 fitted with an Intel
a u t h o r = ” John Doe” i7-8700k processor.
d e s c r i p t i o n = ”A s i m p l e d e s c r i p t i o n ”

def init ( s e l f , ∗∗ kwargs ) :

TABLE II: Time required to step a simple FMU with
super ( ) . init ( ∗ ∗ kwargs ) one integer, real, string and boolean variable 100.000
times. All variables are read after each step.
s e l f . realOut = 0.1
s e l f . r e g i s t e r v a r i a b l e ( Real ( ” r e a l O u t ” ,
c a u s a l i t y=F m i 2 C a u s a l i t y . ou tp ut ) ) Tool Version Time[s]
FMUSDK 2.0.6 4.6
def do step ( current time , s t e p s i z e ) :
r e t u r n True CPPFMU - 4.6
FMI4j 0.30.0 6.1
JavaFMI 2.6.0 40
Listing. 1 shows the minimal required code to write PythonFMU 0.6.0 7.9/7.3a
FMI 2.0 compatible co-simulation models in Python a
Using lambdas for getters, as
using PythonFMU. Additional FMI functions like e.g. demonstrated in Listing. 3.
setupExperiment, enterInitializationMode, exitInitial-
izationMode and terminate have default no-op im- From the results we can see that FMUSDK and
plementations and may be overridden on demand. CPPFMU are equally fast, and as expected, faster than
PythonFMU automatically handles getting and set- both FMI4j and PythonFMU. This is natural as both of
ting variables, logging, resetting, state handling, se- these uses CPPFMU internally and have an additional
rialization and deserialization as well as generating overhead from having to cross the native bridge using
the required modelDescription.xml. The fact that JNI and the Python C API respectively. JavaFMI is
PythonFMU handles state handling makes it possible by far the slowest contender, due to it’s choice of us-
to use with advanced co-simulation master algorithms ing message passing over direct API calls through JNI.
that depends on rollback capabilities, like variable step Note that PythonFMU provides two results. By sup-
algorithms. This is important in order to achieve nu- plying a lambda function to the optional getter and
merically stable and accurate simulation results. List- setter parameters of PythonFMUs ScalarVariable as
demonstrated in Listing. 3, users may increase per- International MODELICA Conference; September 3-5;
formance of variable read/write. When not specifying 2012; Munich; Germany, number 076, pages 173–184.
lambda functions for the getter and setter, PythonFMU Linköping University Electronic Press, 2012.
defaults to using the built in Python functions getattr D. Broman, C. Brooks, L. Greenberg, E. A. Lee,
and setattr respectively. Furthermore, the use of lamb- M. Masin, S. Tripakis, and M. Wetter. Determinate
das allows non Python fields to be used as variables. composition of fmus for co-simulation. In 2013 Pro-
ceedings of the International Conference on Embedded
Listing 3: Supplying a lambda for increased flexibil- Software (EMSOFT), pages 1–12. IEEE, 2013.
ity and performance at the cost of a slight increase in F. Cremona, M. Lohstroh, D. Broman, M. Di Natale,
verbosity. E. A. Lee, and S. Tripakis. Step revision in hybrid co-
s e l f . r e g i s t e r v a r i a b l e ( Real ( ” r e a l O u t ” , simulation with fmi. In 2016 ACM/IEEE International
c a u s a l i t y=F m i 2 C a u s a l i t y . ou tp ut
g e t t e r=lambda : s e l f . r e a l ) )
Conference on Formal Methods and Models for System
Design (MEMOCODE), pages 173–183. IEEE, 2016.
Note that the results presented here does not neces- V. Galtier, M. Ianotto, M. Caujolle, R. Corniglion, J.-
sarily translate to more complex models with more code P. Tavella, J. É. Gómez, J. J. H. Cabrera, V. Rein-
evaluation, as the presented benchmark it is mainly in- bold, and E. Kremers. Building parallel fmus (or ma-
terested in measuring the performance of raw FMI calls. tryoshka co-simulations). In Proceedings of the 12th
As Python is an interpreted language it is naturally International Modelica Conference, Prague, Czech Re-
slower to run than e.g. C/C++. public, May 15-17, 2017, number 132, pages 663–671.
Linköping University Electronic Press, 2017.
CONCLUSIONS V. Hassani, M. Rindarøy, L. T. Kyllingstad, J. B.
This paper introduces PythonFMU, an easy to use Nielsen, S. S. Sadjina, S. Skjong, D. Fathi, T. Johnsen,
framework for exporting Python code as FMI 2.0 for co- V. Æsøy, and E. Pedersen. Virtual prototyping of mar-
simulation compatible models. The framework is easy itime systems and operations. In ASME 2016 35th In-
to install and requires very little boilerplate code, allow- ternational Conference on Ocean, Offshore and Arc-
ing users to focus on the problem at hand. This coupled tic Engineering. American Society of Mechanical Engi-
with the fact that Python is an easy to use scripting neers Digital Collection, 2016.
language with a strong standard library and a rich set L. I. Hatledal, H. Zhang, A. Styve, and G. Hovland.
of 3rd party libraries makes it ideal for fast prototyping. Fmi4j: A software package for working with functional
Furthermore, the position Python has as a language for mock-up units on the java virtual machine. In The
scientific computing should make PythonFMU a nat- 59th Conference on Simulation and Modelling (SIMS
ural choice for data scientists that want to take ad- 59). Linköping University Electronic Press, Linköpings
vantage of or contribute to co-simulation technology. universitet, 2018.
In fact, PythonFMU was specifically developed to al- S. O’Grady. The redmonk programming lan-
low data scientist with little or no background from guage rankings: January 2020, 2020. URL
co-simulation or software engineering at NTNU to con- https://redmonk.com/sogrady/2020/02/28/
tribute with models related to the development of dig- language-rankings-1-20/. (Date accessed 08-
ital twins, as Python and it’s strong ecosystem of li- March-2020).
braries allows easy integration with e.g. models that is T. E. Oliphant. Python for scientific computing. Com-
connected to web services or utilizes neural networks. puting in Science & Engineering, 9(3):10–20, 2007.
While the focus of PythonFMU is ease of use and being QTronic. Fmusdk, 2017. URL http://www.qtronic.
an enabler for Python driven co-simulation models, the de/de/fmusdk.html. (Date accessed 06-March-2020).
performance is shown to be quite adequate compared SINTEF Ocean. Cppfmu, 2017. URL https://
to more low-level implementations. github.com/viproma/cppfmu. (Date accessed 06-
Future works includes adding more features, March-2020).
bug-fixes and improving documentation. The J.-P. Tavella, M. Caujolle, S. Vialle, C. Dad, C. Tan,
source is available at https://github.com/NTNU-IHB/ G. Plessis, M. Schumann, A. Cuccuru, and S. Revol.
PythonFMU, and users are encourage to contribute. Toward an accurate and fast hybrid multi-simulation
with the fmi-cs standard. In 2016 IEEE 21st Interna-
ACKNOWLEDGMENT tional Conference on Emerging Technologies and Fac-
tory Automation (ETFA), pages 1–5. IEEE, 2016.
The research presented in this paper is supported by
G. Van Rossum et al. Python programming language.
the Norwegian Research Council, SFI Offshore Mecha-
In USENIX annual technical conference, volume 41,
tronics, project number 237896.
page 36, 2007.
References
T. Blochwitz, M. Otter, J. Akesson, M. Arnold, AUTHOR BIOGRAPHIES
C. Clauss, H. Elmqvist, M. Friedrich, A. Junghanns,
J. Mauss, D. Neumerkel, et al. Functional mockup LARS IVAR HATLEDAL received the B.Sc. degree
interface 2.0: The standard for tool independent ex- in automation and the M.Sc. degree in simulation and
change of simulation models. In Proceedings of the 9th visualization from the Norwegian University of Science
and Technology (NTNU), Ålesund, Norway, in 2013
and 2017, respectively, where he is currently pursuing
the Ph.D. degree with the Department of Ocean Oper-
ations and Civil Engineering. Email: [email protected]

DR. FRÉDÉRIC COLLONVAL is the lead devel-

oper of a collaborative multi-systems and multi-physics
simulation tool, of the Collaborative System Design
team at Safran R&D center. He obtained his PhD
in numerical simulation and modeling in gas turbine
combustion chamber at TU Munich. He then joined
Safran Group to work on airplane engine performance
modeling and associated simulation tools. In 2018, he
co-founded a new kind of collaborative simulation tool
to target multi-physics simulation in pre-design phase
for rapid design evaluation at Safran. He is interested
in enhancing physical simulation tools by leveraging the
features of innovative open-source projects.

PROF. HOUXIANG ZHANG received the Ph.D.

degree in mechanical and electronic engineering, in
2003, and the Habilitation degree in informatics from
the University of Hamburg, in February 2011. Since
2004, he has been with the Department of Informat-
ics, Faculty of Mathematics, Informatics and Natural
Sciences, Institute of Technical Aspects of Multimodal
Systems (TAMS), University of Hamburg, Germany.
He joined the NTNU, Norway, in April 2011, where
he is currently a Professor of robotics and cybernetics.
His research interests lies on two areas: one is on bio-
logical robots and modular robotics and the other is on
virtual prototyping and maritime mechatronics.

View publication stats