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.