=Paper=
{{Paper
|id=Vol-2019/gemoc_3
|storemode=property
|title=Modeling Co-simulation: A First Experiment
|pdfUrl=https://ceur-ws.org/Vol-2019/gemoc_3.pdf
|volume=Vol-2019
|authors=Renan Leroux,Ileana Ober,Marc Pantel,Jean-Michel Bruel
|dblpUrl=https://dblp.org/rec/conf/models/LerouxOPB17
}}
==Modeling Co-simulation: A First Experiment==
https://ceur-ws.org/Vol-2019/gemoc_3.pdf
Modeling co-simulation: a first experiment
Renan Leroux1,2 Ileana Ober1 Marc Pantel1 Jean-Michel Bruel1
1 IRIT / University of Toulouse
[firstName.lastName]@irit.fr
2 Institute of Research and Technology (IRT) Saint Exupery, Seconded from Altran
Renan.Leroux@irt-saintexupery.com
Abstract—Model-Based Systems Engineering plays a key role be defined beforehand and properly included in a holistic
in managing the complexity in the development of modern systems engineering methodology while protecting the IP
cyber-physical systems. Model simulation allows conducting of all the partners. Thus, full models will never be available
early validation and verification activities. In the context of to all partners but only the minimal amount of data required
Extended Enterprises, systems are built out of components to conduct an efficient development.
developed in different companies as black boxes to protect Simulation is often used to help the system architect
the company Intellectual Property. Simulation activities then assessing the adequacy of his/her architecture. In an EE,
rely on co-simulation that combines the black box simulation partners only develop parts of the whole system and must
of each component to assess the quality of the whole system. thus provide a simulator for each part. Then, all these
Such activities are difficult to harness as the simulation results simulation components are integrated in a co-simulation in
depend on black box co-simulation frameworks that coordi- order to assess the whole system. Such frameworks rely
nate the simulations of each component. Our work targets on co-simulation framework that integrate the components
the modeling of these simulations including the co-simulation in a black box manner to protect the partners IP. The
framework in order to: a) make explicit all the simulation FMI (Functional Mockup Interface) [3] 2.0 co-simulation
choices and have a better understanding of the simulation standard and the associated tools are currently the most ad-
results and b) benefit from model-driven engineering facil- vanced technologies for building such co-simulators taking
ities including automatic code generation. This contribution
into account the constraints of EE including IP protection
during the integration of FMU (Functional Mockup Unit)
describes an early experiment based on the classical bouncing
simulation components. The framework provides a so called
ball game example.
master algorithm that coordinates the various simulation
components.
1. Introduction We target the development of complex cyber physical
systems for the transportation domain. We rely on het-
Nowadays the development of an important number of erogeneous simulations (cross-domains, involving different
real-life applications is done by organizations structured as kinds of models, possibly mixing continuous and discrete
EE (Extended Enterprise). In an EE, a contracting authority execution models, . . . ) to verify that the various functions
and several subcontractors cooperate in complex work-flows in an architecture are activated according to the expected
for the development of complex systems such as cars, air- scenarios. Each function simulator is given as a black box
planes, power plants, etc. A key issue is the protection of FMU to protect the provider IP. A master algorithm is then
the IP (Intellectual Property) of the various partners. SE used to coordinate the execution of these function simulators
(System Engineering) [1] is an interdisciplinary approach during each simulation step relying on the very restricted
used to harness the development of such systems early in the data provided to describe the FMU. Most FMI frameworks
V cycle, aiming at correct by construction processes. MDE provide a generic black box master algorithm that drives
(Model Driven Engineering) [2] relies on formal models the simulation according to the architecture of the simulator
to abstract the complexity of such systems using domain and the properties of each component. But, the various
specific languages. On a wider scope, MBSE (Model-Based frameworks make different undocumented choices that may
Systems Engineering) can be seen as the collection of related lead to quite different simulation results. Indeed, the precise
processes, methods, and tools used to support the discipline management of time and function simulators execution order
of systems engineering with an intensive use of models. plays a key role in the quality of the simulation of such
In the context of EE, MBSE allows the use of various systems. For example, in hybrid systems that involve dis-
kinds of models as core artifacts during the product devel- crete behaviors, if the state of an FMU changes between two
opment. The exchanges between the various collaborators simulation steps, it may be important to compute the precise
are based on models, whose nature and content have to date when the state changed and to restart the simulation at
this exact date (rollback). • the velocity parameter is protected by intellectual
Our work targets a system modeling and simulation property – Thus, it cannot be exchanged between
methodology that takes into account concerns related to the the two simulation components ;
EE, in particular the IP protection, and ensures precise and • the bouncing ball model is split into two functions
deterministic simulation results. This paper contributes ques- – (i) Each function is dedicated to a subcontractor,
tions and some model based preliminary answers derived (ii) this separation should highlight the difficulties
from a simple bouncing ball example implemented with the of the coordination for the co-simulation.
JavaFMI framework[4]:
3. Current practices and related works
• When are rollback required in simulation?
• Should the rollback be managed inside or outside
The FMI is an industry standard for co-simulation that
the FMU?
provides a tool-independent approach for model exchange
• In which order should the function simulators be
and cross-company collaboration [5]. FMI-CO (Functional
executed in case of algebraic loops (data dependence
Mockup Interface for Co-simulation) is designed for the
loops)?
coupling of simulation components for subsystem models,
• How can a simulation model ease the management
which have been exported from their modeling toolsets
of these issues?
together with their solvers as executable software [3] as
• Can the master algorithm be generated easily from
illustrated by the following figure.
such simulation model?
The remaining of this paper is as follows. In section 2,
we provide a short description of the use case. In section 3,
we explore some existing practices and state of the art for
building simulators. In section 4, we explain the need for
distinguishing the system model and the simulation model
to provide a clear separation of concern. We conclude in
section 5 and provide future work directions.
2. A simple example: the bouncing ball
We rely on a very simple example to illustrate the need
for a simulation model and its relation with the system Figure 1. A schematic view of an FMU [3].
model. This example should comprise several parts that
could be provided by several stakeholders and requires the A master algorithm is then used to coordinate all the
use of co-simulation frameworks. We consider a simple FMUs. Generic master algorithms are usually provided in
bouncing ball where one part is the free fall of the ball closed source by tool vendors providing the know-how of
and the other part is the collision with the ground. When the company participating in the popularity of the simulation
the ball is left free above the surface, it accelerates due software. Very little information and control about what is
to gravitational forces. When the ball eventually comes in going on inside is given to the user. The same simulation
contact with the surface, it bounces off the surface, at a driven by different master algorithms may produce different
velocity that is a fraction of the velocity prior to contact. The simulation results. It is thus sometime difficult for a systems
up and down movement will continue several times until the engineer to understand the results of a co-simulation with
ball reaches eventually a resting position. This use case is respect to the simulation of the same system executed in a
a classic example of hybrid dynamic systems, that involves single tool. These differences can come from the values of
both continuous dynamics (the up and down movement of parameters used to perform the co-simulation, the absence or
the ball), as well as discrete transitions where the system not of a rollback mechanism, how the algorithm handles the
dynamics can change and the state values can change in hybrid continuous/discrete time model, or how the algorithm
a discrete manner (during the bouncing). A bouncing ball works with algebraic loops in model. These key-points are
is one of the simplest models that can exhibit the Zeno not always enough documented.
phenomenon – an infinite number of events occurring in a In order to overcome these issues, we propose to model
finite time interval – if it is not well handled. Thus, it is explicitly the expected behaviour of the master algorithm
inherently difficult to simulate on a computer, yet obviously for each system model simulation.
present in real life. MDE provides several open frameworks for heteroge-
For the sake of simplicity, we provide a single model neous co-simulation like Ptolemy II [6], ModHel’X [7]
for the bouncing ball. The velocity is the core parameter or GEMOC [8] that experimented the connection with
of the simulation of the physical behaviour. We adapted the FMI/FMU. The first one allows to program in Java various
example to our needs and consider that: models of computation (called actors) and their combination
Figure 2. System side, Functional view with data flow and State Machine
(called directors). The second provides a more component- 4.1. System model
aware framework still relying mainly on programming lan-
guages. The last one targets the definition of xDSML (eXe- From the point of view of the systems engineer, the
cutable Domain Specific Modeling Language). Our proposal bouncing ball movement is composed of two simple func-
could be implemented using these frameworks especially tions: (i) the Flying Ball (up or down) and (ii) the Ground
the BCOoL (Behavioral Coordination Operator Language) Detect.
proposal from GEMOC [9]. This will be the purpose of The coordination between both is such that : (i) The
future work. Flying Ball function sends the ball position to the Ground
The Distributed Architecture for Controlled CO- Detect function. (ii) The Ground Detect function receives
SIMulation, DACCOSIM, [10] is an FMI-compatible Master the ball position and detects if it touches the ground. In
Algorithm generator. DACCOSIM targets FMI-based simu- response, the Ground Detect function returns a rebound
lation and the cooperation of multiple FMI simulation units. flag at true if there is still enough energy or false otherwise.
To support variable step size, the necessary error control and In that last case, the ball enters the ”StayOnGround” state,
rollbacks are achieved through a hierarchical and distributed as illustrated in the following figure Fig. 2.
control architecture. At each step, simulation data commu- At the system level, the actual behaviour corresponding
nications also occur, but directly between FMU pairs in a to states such as Free Fly or Rebound is not important.
fully decentralized fashion. With respect to this approach, We are only focusing in this paper on the overall (system)
we feel the need for a few improvements: (i) integrate the view of this behaviour.
co-simulation in a wider model-based systems engineering
approach; (ii) make explicit the parameters of the simulation 4.2. Simulation model
and (iii) isolate the rollback and have it controlled by the
master algorithm. In this section, we start with the system model described
previously and we aim at building the operational simulation
model. The purpose is to make explicit all the elements
4. Modeling co-simulation needed to conduct a co-simulation that are usually hidden
in the co-simulation frameworks. The simulation model pro-
vided in Fig. 3 is constructed based on the functions issued
In this section we present a modeling of the bouncing from the system model. All these functions are directly
ball example that distinguishes between the system model written with the help of the JavaFMI framework [4]. We
and the simulation model in a manner that complies to the would therefore need to express the Flying Ball and Ground
FMI/FMU standard directives, while allowing for a clean Detect functions. However, as the simulation has to handle
separation of concerns between the system related issues the heterogeneous nature of the movement corresponding to
and the co-simulation concerns. these two functions, we need to combine the two behaviour
We start with the design of the system model that models. In order to do so, we define a Master Algorithm,
contains the description of the bouncing ball behaviour. This whose role is to drive the switch between the two movement
model is split into two functions : the ”Flying Ball” and the modes corresponding to each of these functions.
”Ground Detection”. Further on, we overview the simulation Moreover, the hybrid nature of the overall system (con-
model, that embeds components that give a fine description tinuous during the Free Fly phase and discrete at Re-
of the various phases of the bouncing ball behaviour, and bound) requires a dedicated mechanism to manage the time
rises the need for a master algorithm that coordinates the according to the expected simulation data precision. This
simulation and ensures the coherent information exchanges mechanism should allow the Master Algorithm to properly
between the various components, even in the presence of IP adjust the size of the simulation step, based on the charac-
protection. teristics of the movement while avoiding the Zeno effect. In
Figure 3. Model Simulation side, Functional view with data flow
this context, the rollback mechanism is typically used. We other side, if the rebound zone is narrow with respect to
briefly overview in the following the characteristics of these the simulation step, it may happen quickly that the ground
components. detection is activated while the theoretical ball position is
under the ground. In reality, a good compromise between the
two values is needed, and anyway the size of the simulation
step is rarely only depending on this part of the system. As
a consequence, we need a mechanism capable of handling
the “under the ground” situation of the ball. One way to do
it, is through a rollback process.
Figure 4. Bouncing Ball, Model Simulation side, State Machine Ball
Figure 5. Bouncing Ball, Ground Detection zones
4.2.1. Flying Ball. The behaviour of the flying ball consists
in a uniformly accelerated motion in a uniform gravitational
field. The up and down movement takes place on the vertical 4.2.3. Rollback. Once an “under the ground” ball position
and is described by simple physical laws. The ball can either is identified, the rollback mechanism is activated and it
be in Free Fly, Rebound or StayOnGround mode. At consists in going back to the previous simulation step and
rebound, a horizontal symmetry is applied to the ball speed running again the simulation with a smaller simulation step.
vector and the ball energy decreases, thus decreasing the This is a general strategy that can be applied in any
velocity, to eventually reach a situation where the ball stays simulation in which the simulation step size may vary:
on the ground. perform a simulation step and check whether the system
state is coherent or not. If not go back to the previous step
4.2.2. Ground Detection. Given that we simulate the and re-run the simulation with a smaller step until the system
bouncing ball – which is a continuous process – in a discrete state is coherent.
manner, it may lead to situations where the ball appears to In our case, with a new step, one of the followings may
be under the ground if the ball crossed the ground between happen as shown in the previous figure:
two simulation instants. The ground detection behaviour
• the ball is underground – we have to go back again
identifies whether the ball touches the ground or not, based
and consider an even smaller simulation step;
on the ball position. For the simulation, we consider that
• the ball is in the rebound zone – the master algorithm
the ball touches the ground if its position is lower than
will have to take care of the rebound;
a predefined parameter, that defines a rebound zone, as
• the ball is in the free fly zone.
opposed to the free fly zone located above it as shown in
the following figure. During the simulation, the activation In order to avoid the Zeno effect, we need to intro-
of the ground detection is discretized. If the rebound zone duce constraints on the physical model. More precisely, the
is very large with respect to the simulation step, then the derivative of the position (i.e., the speed) must be bounded
ball would prematurely rebound, and the ball would never which is the case with finite energy systems. In our case,
actually touch – or get really close to – the ground. On the energy is not bounded as we consider uniform gravity which
Figure 6. Overview of the Master Algorithm
is a coarse approximation at the level of the ground of the 5. Future work and conclusion
real gravity behavior. But, as the ball will reach the ground,
the maximum speed is the one at ground level and thus the In this work-in-progress paper we have illustrated,
derivative is bounded. For a given precision, we can compute through a simple case study, some of the difficulties that
iteratively the simulation step value in a finite number of arise when building co-simulations as required in the devel-
iteration and thus avoid the Zeno effect. opment of a complex system. Even when a dedicated frame-
work such as FMI/FMU is available a number of questions
remain: (i) how to model the simulation components; (ii)
how to define the master algorithm; (iii) how to take into
account the rollback function.
4.2.4. Master Algorithm. The master algorithm orches- This proposal illustrates that it is possible to include the
trates the calls towards the components handling the fly- co-simulation in a holistic, model-based, systems engineer-
ing ball, the ground detection, and the rollback. These ing approach. In particular, it is possible to go from the
components are implemented as FMUs whose execution is system model to the co-simulation model by adding two
managed by this algorithm. The data flows describing the main functions: Master algorithm – for orchestrating the
exchanges taking place at this level are described by the individual simulations; and the Rollback – for adjusting the
activity diagram in Fig. 6. simulation step size of the various isolated simulations.
Beyond the obvious goal of having a master algorithm In addition, we have explored the possibility to export
that works correctly we aim at (i) keeping this master the rollback function outside the concerned model (i.e., the
algorithm as simple as possible and investigate whether Flying ball function). We have also created a specific and
it is possible to automatically generate it (completely or efficient code for the Master algorithm function. Finally,
partially), and (ii) considering IP protection concerns. At we had the ability to choose the execution order of the
this level, the IP protection is ensured by the fact that a FMU different functions.
is an executable code. Although it is in principle possible Based on these results, there are several paths where
to reverse engineering this executable code. This is both ex- this work will be taken over. One direction would be to go
pensive and hard to exploit, given the important size of such further with the integration of the requirements specific to
applications. Moreover it would lead to structure flattening the EE and eventually allow for the existence of two (or
that would make it practically impossible to exploit. more) master algorithms that cooperate. In order to do so,
beyond the necessity to enable communication mechanisms
The master algorithm is specific to each system, in par- between the master algorithms, there needs to be a way to
ticular ours is specific to the example of the bouncing ball. coordinate the rollbacks performed in various parts. Coor-
Nevertheless, the need to orchestrate rollbacks is present in dinating several rollbacks could induce major performance
most of the systems and through it the example helped us increases at simulation time, as it could avoid performing
to gain experience on this aspect. useless rollbacks.
Some of the co-simulations are done in the context of the [4] T. S. U. of Las Palmas. SPAIN, “Java Functional Mock-up Interface
development of applications that are subject to certification. for Co-Simulation,” available at https://bitbucket.org/siani/javafmi/
wiki/Home.
Currently the certification process related to aeronautics
systems does not look into the preliminary results obtained [5] C. Bertsch, E. Ahle, and U. Schulmeister, “The Functional Mockup
Interface - seen from an industrial perspective,” 2014, in: Proceedings
through simulation. One of the reason for this is that there of the 10th International Modelica Conference 2014, Lund, Sweden.
is no formal link between the simulated model and the
[6] J. Eker, J. W. Janneck, E. A. Lee, J. Liu, X. Liu, J. Ludvig,
generated code. One of our future work directions is to S. Neuendorffer, S. R. Sachs, and Y. Xiong, “Taming heterogeneity -
establish traceability links between the system model, the the Ptolemy approach,” Proceedings of the IEEE, vol. 91, no. 1, pp.
co-simulation model and the execution code. This would 127–144, 2003.
be a first step towards including the simulation into the [7] C. Hardebolle and F. Boulanger, “Modhel’x: A component-oriented
certification process. approach to multi-formalism modeling,” in Models in Software Engi-
neering, Workshops and Symposia at MoDELS 2007, Nashville, TN,
USA, September 30 - October 5, 2007, Reports and Revised Selected
Acknowledgements Papers, 2007, pp. 247–258.
[8] B. Combemale, C. Brun, J. Champeau, X. Crégut, J. Deantoni, and
The authors would like to thank the MOISE project J. L. Noir, “A Tool-Supported Approach for Concurrent Execution
members for its support as well as the French Commissariat of Heterogeneous Models,” in 8th European Congress on Embedded
Real Time Software and Systems (ERTS 2016), Toulouse, France,
Général à l’Investissements (CGI) and the Agence Nationale 2016. [Online]. Available: https://hal.inria.fr/hal-01258358
de la Recherche (ANR) for their financial support in the
[9] M. E. V. Larsen, J. DeAntoni, B. Combemale, and F. Mallet, “A be-
frame of the Programme d’Investissement d’Avenir (PIA). havioral coordination operator language (bcool),” in 18th ACM/IEEE
International Conference on Model Driven Engineering Languages
and Systems, MoDELS 2015, Ottawa, ON, Canada, September 30 -
References October 2, 2015, 2015, pp. 186–195.
[10] V. Galtier, S. Vialle, C. Dad, J. Tavella, J. Lam-Yee-Mui, and
[1] I. 24765:2010, “Systems and Software Engineering – Vocabulary.” G. Plessis, “FMI-based distributed multi-simulation with DAC-
COSIM,” in Proceedings of the Symposium on Theory of Modeling
[2] D. C. Schmidt, “Guest Editor’s Introduction: Model-Driven Engineer-
& Simulation: DEVS Integrative M&S Symposium, part of the 2015
ing,” Computer, vol. 39, no. 2, pp. 25–31, Feb 2006.
Spring Simulation Multiconference, SpringSim ’15, Alexandria, VA,
[3] M. Association, “Functional Mock-up Interface for Model Exchange USA, April 12-15, 2015, 2015, pp. 39–46.
and Co-Simulation,” 2014, available at http://fmi-standard.org.