Giovanni Liboni
email: giovanni.liboni@safrangroup.com

Julien Deantoni
email: julien.deantoni@univ-cotedazur.fr

A Semantic-Aware, Accurate and Efficient API for (Co-)Simulation of CPS

Keywords: co-simulation, API, behavioral semantics

To understand the behavior emerging from the coordination of heterogeneous simulation units, co-simulation usually relies on either a time-triggered or an event-triggered Application Programming Interface (API). It creates bias in the resulting behavior since time or event triggered API may not be appropriate to the behavioral semantics of the model inside the simulation unit. This paper presents a new semanticaware API to execute models. This API is a simple and straightforward extension of the Functional Mock-up Interface (FMI) API. It can be used to execute models in isolation, to debug them, and to co-simulate them. The new API is semantic aware in the sense that it goes beyond time/event triggered API to allow communication based on the behavioral semantics of internal models. This API is illustrated on a simple co-simulation use case with both Cyber and Physical models.

Introduction

Cyber-Physical Systems are a class of systems where computation parts (cyber) and the plant parts (physical) can not be developed in isolation since the behavior of one impacts the others. In this context, it is of prime importance that orchestration of software and physical processes are based on semantic models that reflect properties of interest in both [START_REF] Lee | Cyber physical systems: Design challenges[END_REF]. Echoing this, such systems are usually developed by multiple stakeholders, which use domain-specific languages, tailored both syntactically and semantically to the domain of expertise [START_REF] Combemale | Globalizing modeling languages[END_REF].

One solution to address the orchestration of different processes is the use of co-simulation, where processes are computed/solved by dedicated tools and kept in synchronization by a coordination algorithm. Usually, co-simulation makes use of a common Application Programming Interface (API) to communicate more easily with the various tools. For instance, the Functional Mockup Interface (FMI [START_REF]Modelisar: FMI for Model Exchange and Co-Simulation[END_REF]) proposes a homogeneous time-driven interface to realize a computation step on a solver; this is well suited to the simulation of continuous physical processes. Another well-known co-simulation approach is HLA [START_REF] Association | Ieee standard for modeling and simulation (m&s) high level architecture (hla)-framework and rules[END_REF], which proposes a homogeneous publish-subscribe event-based API well suited to discrete event processes.

However, in order to keep during the orchestration the behavioral semantics specificity of each modeling language, it is important to avoid using an API that hides semantic specificity in order to homogenize. Not taking care of internal semantics during the orchestration of such processes may lead to wrong results, lack of accuracy, and bad simulation performance [START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF][START_REF] Tavella | Toward an accurate and fast hybrid multi-simulation with the FMI-CS standard[END_REF][START_REF] Mustafiz | Modular design of hybrid languages by explicit modeling of semantic adaptation[END_REF][START_REF] Centomo | Using SystemC Cyber Models in an FMI Co-Simulation Environment[END_REF][START_REF] Cremona | Step Revision in Hybrid Co-simulation with FMI[END_REF].

In this paper, we presented a versatile API, which can be tailored to the internal model under simulation. By using this API, it is possible to communicate with the simulation unit according to different semantics (e.g, time-triggered, event-triggered, mix); according to the internal semantics of the simulation unit. Additionally, it is also possible to ask the simulation unit to stop under specific conditions like for instance when crossing a threshold or when it reaches breakpoint (for debugging purpose).

The next section explains the problems and overviews of the solutions proposed by other approaches. In Section 3, we present the semantic-aware API and in Section 4, we illustrate its use and benefits on a case study. Finally, before to conclude in Section 6, we propose a small discussion about the approach in Section 5.

Problem Statement and Related Work

Collaborative simulation of Cyber Physical Systems relies on the data and time synchronizations between various simulation units; where a simulation unit is, generally speaking, an encapsulation of a system part execution. Depending on the co-simulation, a simulation unit can encapsulate different entities amongst which (but not limited to): a model and its solver, a program together with its virtual machine, a compiled executable code, a proxy to an existing system part (hardware/software in the loop). A co-simulation actually implements the coordination that should ensure a correct 3 synchronization between the data produced and required by different simulation units. The goal is to be able to understand the behavior emerging from the coordination of the different parts of the system; either for simulation or analysis. Usually, such parts were developed by different domain experts, who are using domain specific languages and tools tailored syntactically and semantically to their needs. Also, most of the time, a simulation unit is seen as a black box by the coordination to ensure Intellectual Property preservation.

In this context, various algorithms were proposed to realize the coordination; well known classics like the Jacobi or Gauss-Siedel algorithms but also many others variants [START_REF] Schierz | Co-simulation with communication step size control in an fmi compatible master algorithm[END_REF][START_REF] Awais | The high level architecture rti as a master to the functional mock-up interface components[END_REF][START_REF] Wang | Hybridsim: A modeling and co-simulation toolchain for cyber-physical systems[END_REF][START_REF] Broman | Requirements for hybrid cosimulation standards[END_REF][START_REF] Van Acker | Generation of an optimised master algorithm for fmi co-simulation[END_REF][START_REF] Broman | Determinate composition of fmus for co-simulation[END_REF][START_REF] Savicks | Co-simulating event-b and continuous models via fmi[END_REF][START_REF] Bastian | Master for co-simulation using fmi[END_REF][START_REF] Neema | Model-based integration platform for fmi co-simulation and heterogeneous simulations of cyber-physical systems[END_REF]. It is worth noticing that all the proposed algorithms are time-triggered, i.e., simulation units are all executed for a specific predefined time-step. This is a surprising fact since from the 90's work 3 this notion is defined later in this section. about coordination languages and architecture description languages (ADLs) proposed more sophisticated techniques for the correct and efficient coordination among software components [START_REF] Papadopoulos | Coordination models and languages[END_REF][START_REF] Medvidovic | A framework for classifying and comparing architecture description languages[END_REF][START_REF] Garlan | An introduction to software architecture[END_REF]. Actually, using the same API, being time-triggered or event-triggered on all the simulation units creates bias in the understanding of what the simulation units do. For instance, [START_REF] Tavella | Toward an accurate and fast hybrid multi-simulation with the FMI-CS standard[END_REF][START_REF] Centomo | Using SystemC Cyber Models in an FMI Co-Simulation Environment[END_REF][START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF][START_REF] Thule | Towards the Verification of Hybrid Co-simulation Algorithms[END_REF] identified the problem introduced by the use of a time-triggered API on Cyber simulation units where sampling the behavior at specific point in times creates artificial delays and loss of information from the coordinator point of view. Such delay can lead to error in results, to bad performances of the co-simulation, or both [START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF].

In this paper, we consider a coordination algorithm as correct if it does not introduce any delays or lose information during the communication with the simulation unit. Consequently, delays and information loss that appear when using a time-triggered API on a piece-wise constant data are considered incorrect (see Figure 1). Three important things must be noticed at this point. First, sampling a piece-wise constant value can make sense and does not necessarily introduce major problem; however, this should be done on purpose and not be the result of an inappropriate API. Second, there exists in many API (e.g., the FMI standard [START_REF]Modelisar: FMI for Model Exchange and Co-Simulation[END_REF]) the possibility to avoid such delay, typically by roll-backing the simulation to a previous state and trying to locate the actual value change. This can be done only if the simulation can actually be rolled-backed; also this is costly in terms of simulation-time. Finally, third, it is worth noticing that the problem is broader than the simple illustrative case. As illustrated in [START_REF] Thule | Towards the Verification of Hybrid Co-simulation Algorithms[END_REF], the coordination algorithm can have an impact on the correctness of the system.

The core of the problem was identified in several papers: it is not appropriate for any simulation unit to communicate only through a time-triggered or event-triggered API. In the literature, some approaches proposed to extend some existing API to fix a particular problem. This was for instance the case in [START_REF] Tavella | Toward an accurate and fast hybrid multi-simulation with the FMI-CS standard[END_REF] where they proposed to add a new parameter to the FMI time-triggered doStep(∆t) function. The new parameter is nextEventT ime, a placeholder to store the time at which unpredictable events occurred. [START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF] went further by proposing to extend the FMI API with new functions that simulate until input and output ports are respectively ready to be read or just written. Finally, the new features of FMI3.0 for hybrid co-simulation tries to aggregate such propositions (see chapter 5 of FMI3.0 development version https://fmi-standard. org/docs/3.0-dev/#fmi-for-hybrid-co-simulation).

However, in all these related works, the problem is not handled in its generality and they make specific cases of something that should be straightforward. In order to speak correctly with a simulation unit, you should be aware of its behavioral semantics and adapt the way to realize the doStep accordingly. As an abstraction of a simulation unit behavioral semantics, previous works proposed to focus on the nature of the inputs and outputs of the simulation units [START_REF] Broman | Requirements for hybrid cosimulation standards[END_REF][START_REF] Tavella | Toward an Hybrid Co-simulation with the FMI-CS Standard[END_REF] like for instance continuous, piecewise-continuous, piecewise-constant or spurious. We believe this abstraction is very interesting and can be used as a basis for a semantics-aware API.

Proposition

We propose to consider the FMI time-triggered interface doStep(∆t) as a specific case where we ask a simulation unit to simulate until a specific predicate characterized by an amount of time spent in the simulation unit 4 . Following the same rationale, the proposed semantics-aware API can ask to a simulation unit to execute until a specific coordination predicate holds. The predicate must be expressed according to the information from the simulation unit behavioral interface (typically containing input/output nature, time representation, and solver capability [START_REF] Broman | Requirements for hybrid cosimulation standards[END_REF][START_REF] Tavella | Toward an Hybrid Co-simulation with the FMI-CS Standard[END_REF][START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF][START_REF] Liboni | Wip on a coordination language to automate the generation of co-simulations[END_REF]). Consequently, the general form of the proposed doStep API is:

StopCondition doStep(CoordinationPredicate p)

; where p expresses a condition under which the execution should pause, i.e., the condition under which the doStep function returns. For instance, considering the input and output nature as defined in [START_REF] Tavella | Toward an Hybrid Co-simulation with the FMI-CS Standard[END_REF] (i.e., continuous, piece-wise constant, piece-wise continuous or spurious), the concept of predicate for a correct coordination can be defined as shown in the class diagram Figure 2 If the simulation unit supports only temporal predicates, then it corresponds to the FMI API. However, other coordination predicates have been defined. Here is a brief description of their meaning and their typical use case.

1. TemporalPredicate is a predicate that becomes true when the internal time of the simulation unit reaches the value of the predicate. This is the classical FMI predicate. 2. UpdatedPredicate is a predicate that becomes true as soon as the referenced variable, which must be a piece-wise constant output, has been assigned. It typically corresponds to example from Figure 1, which can then be managed without data loss, delays, or very small communication step size; i.e., in a correct way. 3. ReadyToReadPredicate is a predicate that becomes true just before the simulation units actually read the referenced variable. It is typically used if there is a need to provide an input to a simulation unit that actually reads (non necessarily in a deterministic way) this input at specific points in time. Instead of periodically providing the input data (consequently with unavoidable delays), the data is provided only when needed by the simulation unit. 4. ThresholdPredicate is a predicate that becomes true when the referenced variable crosses the defined threshold (according to the crossing direction 5 ). It is typically used when a simulation unit is waiting for a specific threshold on a value from another simulation unit. Instead of periodically providing the input data (consequently with unavoidable delays) to be tested and possibly using rollback for more precision, the data is provided only when the condition is reached. 5. EventPredicate is a predicate that becomes true when the referenced event occurs. While this is in our implementation only used for cyber events, it may also be extended to encompass discontinuities or other kinds of events on (piecewise) continuous signals. 6. BinaryPredicate defines the disjunction of other predicates.

Finally, the proposed API also provides the classical function like for instance loadModel, get/set Variable, get/set State and terminate.

What is important is the (preliminary) definition of the coordination predicate, which is, according to our experiments, the minimal set of predicates to have an accurate coordination i.e., without loosing any data, events or signals. Note that for now, we are only using the disjunction of predicates since it is not clear about the meaning of their conjunction. For instance, existing works about Event constraints suggest using Union or Inf/Sup constraints instead of AND since they intrinsically embed a notion of order which is not existing into the classical Boolean operators [START_REF] André | Syntax and semantics of the clock constraint specification language[END_REF][START_REF] Deantoni | CCSL denotational semantics[END_REF].

To these predicates, many others could be added like for instance a discontinuity predicate that stops when a discontinuity is detected on a piece-wise continuous variable (see description of the Event predicate). Another more complex predicate could be a Büchi predicate, which is verified when a specific statebased observation occurs. There is no real reason to limit the kind of predicate that can be defined, as long as it makes sense according to the simulation unit execution semantics.

In other words, based on the simulation unit behavioral interface, one can speak about the simulation in terms of predicates which are relevant in the particular simulation units used in the co-simulation. For instance, considering a simulation unit interface of an untimed simulation unit, no temporal predicate can be used. In the same idea, if the simulation unit exposes only (piece-wise) continuous variable, then it should not be possible to refer to these variable updates (since it creates an undesired connection with the internal simulation unit discretization step). In short, the acceptable predicates for a specific simulation unit can be inferred from the simulation unit behavioral interface of such simulation unit. However, it is also important that each tool specifies the predicates it supports.

The value returned by the doStep function must allow the coordinator to understand why the simulation was actually paused, so that it can do the appropriate action. For instance, if the simulation unit was paused due to an UpdatedPredicate, then the variable that has been updated should be communicated to the appropriate simulation unit input (after being sure that the receiving simulation unit is at the same time than the emitting simulation unit, aligning the time if needed). For now, we used a simple form a StopCondition but it might be aligned with the Predicate class diagram. The Figure 3 shows a minimal proposition for a simple StopCondition. The StopReason is a predicate type defining why the simulation was paused; the elementName defines the referenced element link with the stop reason and the stopTime stores the internal time of the simulation unit when paused. Remarque 1 : This is not clear yet how the link should be made between the name of an exposed variable in the simulation unit behavioral interface and the actual variable inside the model under simulation. For now, we are using qualified names instead of simple names like in the simulation unit behavioral interface. Similarly, for experimental facilities, we are using a Double to encode time in the co-simulation. It does not mean that the time is internally a double (since it may be encoded by super dense time for instance) but it provides a helpful homogenization of the time from the coordination point of view.

Remarque 2 : According to our definition, FMI is a specific mold of our interface since it defines only (piece-wise) continuous variables and (and it does not allow for Threshold predicate injection). Consequently, the only acceptable predicate is a Temporal predicate.

We show in the next section how this API, implemented for language developed in the GEMOC studio [START_REF] Bousse | Execution framework of the gemoc studio (tool demo)[END_REF], provides a simple way to gain in term of accuracy and performance during the coordination of multiple simulation units. However, in the next subsection, we overview how it can be used for other usages, typically debugging.

Example of Extension of the API for Debugging

In this subsection, we show an implementation experimented in the GEMOC studio to use the very same API for debugging. Our goal was to implement the functionality of an API as defined in the usual debugger. We consider this useful for the developer of one simulation unit when she/he wants to debug the simulation unit in the context of the other simulation units. For this reason, we considered that breakpoints are defined with another interface and considered only the way to execute the simulation unit. To define the new use of the interface, we simply defined the necessary Predicate for debugging (see Figure 4) and implemented the corresponding management of the Predicate in a wrapper. Details can be found here: https://github.com/jdeantoni/ cosimulationOfCpuHeatManagement. Furthermore, it is interesting to realize that debugging equational simulation units could use a totally different notion of breakpoint. For instance, one could want to pause the simulation when the derivative of a specific output reaches a symptomatic threshold, in order to check different values in the system and try to understand what actually happens. In this case, Predicates should be defined accordingly.

Once again, we tried to provide an extendable simulation API, focused on co-simulation but suitable for different activities.

Case Study

We used the management of a CPU temperature as a simple but representative case study6 . This system is made up of 3 simulation units (see Figure 5). CPUin-BoxWithFan and fanControler have been developed in the OpenModelica tool 7to respectively define the CPU in a box which is cooled by a fan and the controller of the fan speed (a simple Proportional controller). The heat between the box and the CPU is transferred according to the fan speed. The overHeatController has been developed as a state machine in the GEMOC studio 8 .

In the CPUinBoxWithFan simulation unit, the CPU is activated as long as the stopWorking input is equal to false. When activated, the CPU produces heat, which is exchanged with the air of its box more or less rapidly depending on the fanSpeedCommand input (∈ [0..10] where at 0 the fan is stopped and at 10 the fan is at full speed).

In the overHeatController simulation unit, a state machine is defined. It monitors periodically (every 3 seconds) the cpuTemperature and if it exceeds a specific threshold, the switch event occurs and the state machine enters in a new state where it monitors the CPU temperature every 5 seconds. If it goes above a specific threshold, the switch event occurs and the state machine enters the first state (see Figure 6).

To connect the different simulation units we relied on strategies defined in [START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF]. Consequently the temperature from CPUinBoxWithFan to overHeat-Fig. 6: Over Heat Controller state machine.

Controller is only exchanged when the later simulation unit is ready to read the data. Similarly, the change of the stopWorking input is only done only when the switch event occurs. Between the two simulation units obtained from Modelica, the connectors define classical time trigger communication.

Of course, we handled these different cases by using different Predicates in the doStep function call. However, one can notice that the coordination algorithm will not be generic anymore but dedicated to the topology of simulation units and the information on the connectors. For this specific use case, the coordination algorithm is provided on Listing 1.1. Lines 4 to 6, the predicate for the overHeatController simulation unit is defined as "the variable cpuTemperature is ready or the switch event occurs". Line 7, the dostep function is called and lines 8 to 16 the result of the function is managed. If the simulation was paused due to the variable cpuTemperature which is ready to be read, then a function (simulateBoxAndFanControl defined line 19) is called to set the CPUinBoxWith-Fan simulation unit at the same time as the over heat controller simulation unit. Once done, the expected value is exchanged between the FMU. If the simulation was paused due to the occurrence of the switch event, then the receiving simulation unit is at the time when the event occurred, so the stopWorking variable is changed. The temporal connector between the fan controller and the CPU, as defined in Figure 5, requires to simulate both models until a specific point in time. In lines 21 to 36, the simulation units must reach an expectedTime. If there is one (or several) intermediate temporal steps in between now and the expected time (i.e., now%5 = 0 in our case), then the simulation units are simulated until this point in time and data are exchanged as expected.

Listing 1.1: Coordination Algorithm dedicated to the example on Figure 5 The results from the beginning of the co-simulation obtained with this setup are provided in Figure 7. The reader should notice that the points are only retrieved as specified in Figure 5, i.e., at the exact time it is needed to have a correct co-simulation. For instance on Figure 7, we can see that a first paused was realized by the overheat controller at time 2, i.e., which is the non deterministic time spent for the state machine to enter in the normalTemp state, where the guard of output transition is evaluated and consequently the CPU temperature is read. Then, pauses are realized every 5 seconds and every multiple of 3 (the reading period in the first state of overHeatController ). This way, we reduce the number of communication points to their strict minimum to have a correct cosimulation and we avoid the delays introduced by the classical sampling strategy.

In the Figure 8, the first point in time is the one when the state machine switch from the normalTemp state to the tooHot state. It occurred at time 14679. Consequently, as long as the state machine remains in this state, data are retrieved every 5 seconds as specified in the temporal connectors and in the reading period from the state machine. However, since the state machine entered in the tooHot state at time 14679, then the simulation unit was paused after 5 seconds, i.e., at 14684, while the temporal connectors induce a pause every 5 seconds. We can see here that the internal semantics of the simulation is consistently exposed and took into consideration. Finally, in Figure 9, the simulation is run for 8 hours and 20 minutes (30000 seconds). For this simulation, we obtained 15023 communication steps without sacrificing accuracy over performance. If we were using a time-triggered interface and allowed an error up to 100ms, then we would have 300'000 communication step and a loss of accuracy. Additionally, we believe that the proposed interface is intuitive to use and may be extended for different purposes. In the next section, before to conclude, a small discussion about implementation is made.

Discussion

We argued that the proposed interface is extendable, efficient, and intuitive to use. In this section, we discuss some of these points according to our experiment in implementing the API in the GEMOC studio.

Concerning the implementation of the predicates, two main points can be addressed. First, its efficiency strongly relies on how the API is internally implemented. In our case we modified the code generation to generate a pause when needed. For instance, for the Updated predicate, all assignments are instrumented to create a pause. This has only a minor impact on performance. However, if the implementation is done in a wrapper where all micro steps are checked to see if a variable has been updated, then the execution may suffer from a slowdown. The same phenomenon happens for the Threshold predicate. If one sample the variable to check the crossing, the execution will be slow down and the exact point in time when the crossing occurs may be missed. It is better to inject the actual zero crossing in the model (typically in the equation set) to ensure better performance and accuracy. This is what is expected to be done in collaboration with Safran. Also, the implementation of the predicates must actually follow the semantics of the simulation unit. For instance, if a simulation unit is executing a model developed in a synchronous language [START_REF] Benveniste | The synchronous languages 12 years later[END_REF], then all the assignments should NOT be caught since according to the synchronous semantics, data are latched at specific points in time. In our implementation, we relied on annotations to provide flexibility on the exposed semantics. Consequently, the tool developer is in charge of providing the expected semantics.

Concerning the extension of the predicate, there are two minors points to take care of. First, it is important to rely on a mechanism to clearly specify which predicate is supported for a specific simulation unit. This may for instance be done in an artefact equivalent of the FMI model description. Second, there is a risk of an uncontrolled evolution of predicates, leading to a predicate tower of Babel. This is a long term issue and we believe there are few risks it happens. If the road to this situation is taken, it may be interesting to provide an official set of predicate extension repository, where people can look for existing predicate before to create their own and where all predicates are put together.

Conclusion

We presented in this paper a new API, initially thought as a co-simulation interface. However, it can be used for different purposes. It uses the proposed notion of predicate to represent the condition under which a simulation unit must be paused. These predicates can be of different nature depending on the use of the API. In each case, it relies on the information provided about the simulation unit. In the co-simulation case, it relies on the data nature (continuous, piece-wise continuous, etc) exposed by the simulation unit. This information is an abstraction of the internal behavioral semantics of the simulation unit. We developed a case study where we showed how the API can be used in a semanticaware way. The use of the API adapts the number of co-simulation steps to the internal behavior of the simulation units, keeping only the communication points required for a correct co-simulation. We believe such communication between the coordination algorithm and the simulation unit provides the basis for an analysis of a co-simulation.

In future works, we first want to focus on the automated generation of the coordination algorithm. As shown in Listing 1.1, the coordination is dedicated to a specific simulation and it may be tricky to write it by hand for a more complex system. Additionally, it becomes important to allow for the distribution of co-simulation. Our approach, by limiting the number of co-simulation steps to the minimum, is well appropriate to distribution. This is why we are actually finishing the development of the generator of distributed coordination algorithm based on our interface. Another future work concern the integration of such approach into a system engineering approach but this is a longer term work.

Fig. 1 :

 1 Fig. 1: Time-triggered simulation considered as incorrect.

Fig. 2 :

 2 Fig. 2: Minimal but extendable set of predicates.

Fig. 3 :

 3 Fig. 3: Simple StopCondition, returned by the doStep function.

Fig. 4 :

 4 Fig. 4: Simple StopCondition, return by the doStep function.

Fig. 5 :

 5 Fig. 5: Simple but representative case study for co-simulation.

using the proposed interface 1 public 5 E 7 S 17 } 19 public

 1571719 void c o S i m u l a t e ( double e nd t im e ) { //now = 0 ; l o c a l I s S t o p p e d = f a l s e ; ReadyToReadPredicate r 2 r p ( " cpuTemperature " ) ; v e n t P r e d i c a t e ep ( " s w i t c h " ) ; B i n a r y P r e d i c a t e bp ( r 2 r p , ep ) ; t o p C o n d i t i o n s c = c o n t r o l e r S U . doStep ( bp ) ; i f ( s c . s t o p R e a s o n == READYTOREAD) { 9 simulateBoxAndFanControl ( s c . stopTime ) ; double cpuTemperature = c . boxSU . r e a d ( " cpuTemperature " ) ; 11 c o n t r o l e r S U . s e t V a r i a b l e ( " cpuTemperature " , cpuTemperature ) ; } e l s e { // e v e n t o c c u r e d 13 simulateBoxAndFanControl ( s c . stopTime ) ; l o c a l I s S t o p p e d = ! l o c a l I s S t o p p e d ; 15 boxSU . w r i t e ( " stopWorking " ) . w i t h ( l o c a l I s S t o p p e d ) ; } void simulateBoxAndFanControl ( double expectedTime ) { double d e l t a = expectedTime -now ; 21 while ( d e l t a + ( now % 5 ) >= 5 ) { // \ D e l t a t == 5 f o r e a c h c o n n e c t o r → from boxSU and f a n C o n t r o l l e r S U double stepToDo = (5 -(now % 5 ) ) ; 23 boxSU . doStep ( stepToDo ) ; f a n C o n t r o l l e r S U . doStep ( 5 ) ; 25 double cpuTemperature = boxSU . r e a d ( " cpuTemperature " ) ; f a n C o n t r o l l e r S U . w r i t e ( " cpuTemperature " ) . w i t h ( cpuTemperature ) ; 27 i n t fanCommand = f a n C o n t r o l l e r S U . r e a d ( " fanSpeedCommand " ) ; boxSU . w r i t e ( " fanSpeedCommand " ) . w i t h ( fanCommand ) ; 29 double boxTemperature = boxSU . r e a d ( " BoxTemperature " ) ; now += stepToDo ; 31 d e l t a = expectedTime -now ; } 33 i f ( d e l t a > 0 ) { boxSU . doStep ( d e l t a ) ; 35 now += d e l t a ; } 37 }

Fig. 7 :

 7 Fig. 7: Results obtained at the begin of the co-simulation.

Fig. 8 :Fig. 9 :

 89 Fig. 8: Results obtained when the controller enters in the tooHot state.

Note that, in reference to study on Model of Computations[START_REF] Tripakis | Bridging the semantic gap between heterogeneous modeling formalisms and fmi[END_REF] that this may be done only for timed simulation units.

It can be either from above to below, from below to above or both.

the associated code can be retrieved from http://i3s.unice.fr/ ˜deantoni/ cosim-cps2020.

https://openmodelica.org.

http://eclipse.org/gemoc.

while ( now < endTime ) {


Giovanni Liboni Safran

Julien Deantoni
email: julien.deantoni@univ-cotedazur.fr

CoSim20: An Integrated Development Environment for Accurate and Efficient Distributed Co-Simulations

Keywords: Coordination, Co-Simulation, Master Algorithm, Language Engineering

The development of Cyber-Physical Systems involves several disciplines and stakeholders, which use heterogeneous models and formalisms to specify the system and make early validation and verification. In order to understand the behaviour emerging from the heterogeneous models, a collaborative simulation (co-simulation) can be used. To make it happen, the system engineer must define a correct coordination of the different executable models, which can be distributed over different enterprises. This is an important but difficult (and error prone) task that can not be done without information about the behavioral semantics of each model. In this paper, we introduce an integrated development environment which allows 1) to import different executable models (named simulation units), 2) to graphically connect them with rich connectors and 3) to generate a dedicated, accurate and efficient distributed co-simulation. The framework is based on Eclipse EMF for the modeling part and on ∅MQ for the deployment. It is named CoSim20.

I. INTRODUCTION

The increasing complexity of Cyber-Physical Systems (CPS) makes their development a challenging multi-expert effort. Each expert focuses on a specific aspect of the system and uses dedicated tools and languages tailored to her or his domain of expertise [START_REF] Combemale | Globalizing modeling languages[END_REF]. The cooperation among these different stakeholders is necessary due to the strong inter-dependency between every parts of the system. Additionally, the emergence of extended enterprises [START_REF] Jagdev | The extended enterprise-a context for manufacturing[END_REF], where enterprises take advantage of their network organization with many partners to outsource some expertise, introduces Intellectual Property Rules between the different experts and their artifacts. Orthogonally, in order to speed up the time-to-market, Model-Based System Engineering promotes early verification and validation (typically by using simulation) [START_REF] Estefan | Survey of model-based systems engineering (mbse) methodologies[END_REF]. In this context, using distributed collaborative simulation is more and more common since it enables the coordination of heterogeneous models and simulators (i.e., simulation units), possibly without revealing Intellectual Work partially founded by the GLOSE bilateral project between INRIA and Safran.

Properties (e.g., by using black-box simulation units like in the FMI standard [START_REF] Modelisar | FMI for Model Exchange and Co-Simulation[END_REF]).

However, the heterogeneity of the languages and tools used by the different experts (from either the cyber and physical domain) makes the coordination between different simulation units a difficult task. A simple error in this task can lead to timing bias that corrupts the co-simulation results [START_REF] Thule | Towards the Verification of Hybrid Co-simulation Algorithms[END_REF]- [START_REF] Gomes | Hintco -hint-based configuration of co-simulations[END_REF].

Several approaches, mostly based on the FMI standard, were proposed to define the coordination of heterogeneous simulation units [START_REF] Schierz | Co-simulation with communication step size control in an fmi compatible master algorithm[END_REF]- [START_REF] Bastian | Master for cosimulation using fmi[END_REF]. However, due to the time-triggered nature of the co-simulation framework, they failed in ensuring a correct co-simulation embracing both cyber and physical models [START_REF] Tavella | Toward an accurate and fast hybrid multi-simulation with the FMI-CS standard[END_REF], [START_REF] Centomo | Using SystemC Cyber Models in an FMI Co-Simulation Environment[END_REF]. To embrace the cyber and physical models, some knowledge about the behavior of the models is essential. Such information allows to explicitly define a correct coordination, i.e., a coordination that does not introduce simulation time delays that can corrupt the results.

In this paper, we introduce CoSim20, an Integrated Development Environment (IDE) based on coordination interfaces and rich connectors, supported by advanced textual and graphical editors; and from which it is possible to automatically generate a distributed executable code of the co-simulation.

The next Section overviews other existing approaches and state the problem. In the Section III, we introduce the language and tool proposed to define an explicit coordination model. Then, in Section IV, we detail the distributed algorithm generated from the models. Finally, in Section V, we show a use case study, which shows the correctness and efficiency of the approach.

II. PROBLEM STATEMENT AND RELATED WORK

A collaborative simulation focuses on the orchestration among different simulation units that represent different parts of the same system, in order to better understand the emerging behavior of the system. A simulation unit is an executable entity, usually a black box, which may for instance encapsulate a model and its solver, a binary executable process or a proxy to a hardware device. The orchestration is of prime importance because it defines the instant when a simulation unit exchanges data with other simulation units, i.e., when it synchronizes its internal time in order to produce or consume data at the right timing.

Several approaches proposed different orchestrations (mainly based on the FMI Standard). A majority of them are variants of well-known Jacobi or Gauss-Seidel methods and are dedicated to (continuous) system of equations [START_REF] Schierz | Co-simulation with communication step size control in an fmi compatible master algorithm[END_REF], [START_REF] Wang | Hybridsim: A modeling and co-simulation toolchain for cyber-physical systems[END_REF]- [START_REF] Neema | Modelbased integration platform for fmi co-simulation and heterogeneous simulations of cyber-physical systems[END_REF]. All these algorithms implement a time-triggered coordination that does not correctly support the integration of heterogeneous simulation units as found in Cyber Physical Systems; i.e., they do not encompass Cyber simulation units which are based on discrete time / discrete event models. These simulation units usually embed so-called piece-wise constant data where sampling creates bias. For instance, Figure 1 shows that time triggered sampling can create either information loss or delays. As shown in [START_REF] Tavella | Toward an accurate and fast hybrid multi-simulation with the FMI-CS standard[END_REF]- [START_REF] Liboni | Beyond Time-Triggered Co-simulation of Cyber-Physical Systems for Performance and Accuracy Improvements[END_REF], such bias may invalidate the results of the co-simulation. Consequently, we consider a coordination as correct when no timing bias like the ones of Figure 1 are introduced.

Additionally, the emergence of extended enterprises implies that simulation units may be distributed in different locations, in particular where the expertise is. This is consequently important to reduce communication between the different simulation units to better support distributed coordination.

The reader should note that the problem in Figure 1 is not related to the sample rate but rather on an inappropriate communication schema between the simulation unit and the coordination. One can increase the sample rate but it decreases the performances (by introducing more message exchanges between simulation units) and reduces the delays due to the time-triggered API without removing them (see section V).

In order to define a correct communication schema, the system engineer must have some information about the behavioral semantics of the simulation units. To thwart such problem, several works on component based architecture description languages and coordination languages proposed to exhibit in an interface partial information from the (black box) components [START_REF] Crnkovic | Building reliable component-based software systems[END_REF]- [START_REF] Allen | A formal approach to software architecture[END_REF]. As an example, a nice proposition of behavioral interface has been recently published in [START_REF] Leroy | Behavioral interfaces for executable DSLs[END_REF]. Such interface must give enough information with respect to the use of the interface, without disclosing the internal model (to avoid Intellectual Property violation). In our case, it must provide enough information on how to coordinate the component. In the context of CPS, we proposed an assisted tool to easily import and define coordination specific interface, i.e., an abstraction of the simulation unit behavioral semantics which is suitable to define an appropriate coordination among simulation units. This coordination interface can be exploited to define a coordination algorithm. Coordination languages such as [START_REF] Allen | A formal approach to software architecture[END_REF], [START_REF] Arbab | Reo: A channel-based coordination model for component composition[END_REF]- [START_REF] Busi | On the expressiveness of linda coordination primitives[END_REF] proposed sophisticated techniques to define a correct and efficient coordination among software components. However, they focused only on discrete-event coordination and this make these approaches unsuitable to the coordination of CPS simulation units. In this paper, we proposed a language based on rich connectors explicitly tailored to the specification of CPS simulation unit coordination.

The proposed language and framework are detailed in the next sections. III. COSIM20 MODELING ENVIRONMENT Figure 2 gives an overview of the proposed framework. There are two distinct parts: one part dedicated to the modeling of the co-simulation by using the language provided in the CoSim20 modeling environment; and one part dedicated to the co-simulation itself in the distributed CoSim20 Runtime framework. In the modeling environment, the development starts by importing a set of existing simulation units with their native runtime API. A coordination interface is then defined for each simulation unit, exposing appropriate properties like input/outputs and their nature (see next subsection). Then, the interface is used to define rich connectors which specify the intention of the coordination (see section III-B). Based on such model, the framework automatically generates for each simulation unit a Runtime Coordination API and an algorithm that handles the model execution through its native runtime API. The runtime coordination API makes use of a set of distributed queues (generated and configured during the automatic generation phase) to exchange actions to be realized by other simulation units in order to realize the coordination. A distributed master algorithm emerges from such exchanges.

A. Coordination Interface

The proposed Coordination Interface consists in a set of ports with their properties e.g., direction, type and nature, and a temporal reference. Each port represents a point of interaction between the internal variable of a simulation unit and the external environment i.e., the coordination algorithm.

By looking at the various existing approaches and by realizing various systems, we realized that the information which is important from the coordination point of view depends on how and when the inputs and outputs are internally used (i.e., read and/or written) by the simulation unit. Such information is abstracted by the data nature of the simulation units inputs/outputs. The different natures of the data found in CPS have been introduced in several approaches but are nicely summed up in [START_REF] Tavella | Toward an Hybrid Cosimulation with the FMI-CS Standard[END_REF], [START_REF] Broman | Requirements for hybrid cosimulation standards[END_REF]. We adapted such specification and ended up with the following data natures:

Continuous : A variable is defined as continuous if its value is present for all t ∈ T , continuous and differentiable at any points of its range of definition; Piecewise-continuous : A variable is defined as piecewise-continuous if its value is present at each instant but it is not continuous and not differentiable at some points (it presents discontinuities); Piecewise-constant : The value is present at each instant but it presents discontinuities (typically due to internal or external assignments) and the value is constant between two discontinuities; Transient : The value is present only at specific points in time and absents at other points in time. Transient data are usually associated with the notion of event or signal as found in synchronous languages.

Associated with the direction of the data, the data nature, as defined above, gives information on important points in time at which coordination should be done. Typically, if the output of a simulation unit is declared as piecewise-constant, then the coordination model is interested in the points in time at which the data is written; so that it can be updated in the connected simulation unit input port(s). If the data nature is transient, then important points in time are the instants when the data is present. If the data nature is continuous, then there is no real interest in any point in time; what is important is to sample data fast enough to avoid losing quick variation (i.e., Nyquist-Shannon law should actually hold). Finally, in addition to the previous case, if the data nature is piecewise-continuous, then it is important to be noticed about any discontinuity in the signal. All in one, the data nature gives hints to the coordination of what is the event of interest on the data. Of course one can decide knowingly to sample piecewise-constant data, aware of potential problems as illustrated in Figure 1.

Due to the heterogeneity of formalism participating in the system, the time representation can be different across the simulation units. Even if physical time (with or without relativity effects) is mainly used in CPS simulation units it can also be polychronous. The temporal reference specifies the magnitude used to measure time (e.g., the angle of a camshaft [START_REF] André | Modeling Time(s)[END_REF] or a distance).

Other (less important) properties like, for instance, the initial Fig. 3: Screenshot of the interface definition in the tool, with properties of ports.

value of a port can also be defined.

An example of a coordination interface in the proposed framework is represented in textual and graphical form in Figure 3, together with the property windows of a port. Note that the properties are automatically imported if the SUPath point to a standard Functional Mockup Unit (FMU) [START_REF] Modelisar | FMI for Model Exchange and Co-Simulation[END_REF]. Also in the definition of this interface, the user can decide if the value must be plotted during the co-simulation or not (isMonitored attribute on Figure 3).

B. Model Coordination Language

Once the interfaces are defined, we propose to use rich connectors to specify how the coordination between the different simulation units must be realized. A rich connector defines the conditions and constraints under which data exchanges have to occur. Inspired by coordination languages REO [START_REF] Arbab | Reo: A channel-based coordination model for component composition[END_REF] and Wright [START_REF] Allen | A formal approach to software architecture[END_REF], the coordination model is defined by the behaviours defined in the rich connectors between ports from the coordination interfaces.

This section describes the basic syntax and semantics of these rich connectors, showing how they are combined to specify the coordination between simulation units in an unambiguous way.

The main element of MCL is a M CLSpecif ication that imports Coordination Interfaces and contains a set of Connectors. A connector is defined based on the ports defined in the interfaces of different simulation units. More precisely, a connector defines three main concepts: the actual interaction, defined as a directed-graph topology of the system, the triggering conditions, defined as a set of conditions that trigger the interaction, and the synchronization constraint, defined as a temporal constraint that must hold before to perform the interaction.

An Interaction defines a relation between two or more ports defined in different interfaces. Each interaction can specify one or more assignment defined as a directed edge that connects a source port (defined as output) with one or more target ports (defined as inputs). The global set of interactions is then used to generate the global topology of the system.

A Triggering Condition defines the condition at which the interactions must be realized. It is based on the data natures of the ports involved in the related interactions. For instance, if the data involved are all of continuous nature, so the triggering condition can specify a sample rate at which the data exchange occurs. As another example, if an interaction involves a piecewise-constant output port, the triggering condition can refer to each update of this port (instead of using a time-triggered approach). This coordination consequently removes delays or information losses (see Section V). The triggering conditions proposed in the framework are aligned with the expressiveness of predicates defined in [START_REF] Liboni | A semantic-aware, accurate and efficient api for (co-)simulation of cps[END_REF] and appropriated to the data nature defined earlier in this section. More precisely, we defined the following triggering conditions:

1) time condition: the interaction is (classically) triggered periodically. It can be used on data of any nature; 2) event condition: the interaction is triggered when an event occurs on the output port. This allows to react at the exact time an event occurs in the simulation unit. It can be on transient and piecewise-continuous data; 3) data update condition: the interaction is triggered each time the data of the output port is updated (i.e., written) by the simulation unit. This allows to propagate fresh data to the connected simulation units. It can be used on piecewise-constant data; 4) data read condition: the interaction is triggered each time the data of the input port is ready to be read by the simulation unit. This allows to provide fresh data to the simulation unit. It can be used on piecewise-constant data. Based on the triggering information, the framework is able to statically know if there exists a suitable coordination or not. For instance, if there is a loop between two simulation units linked with two connectors, both stating data update condition, then it is not possible to determine a suitable schedule for the simulation without forcing a rollback. Instead, the designer is proposed to sample one of the data, consciously introducing a possible coordination related delay. We believe this is an interesting feature to guide the designer in the coordination process. However, elaborated recommendations beyond noncorrect coordination models are left for future works.

The Synchronization Constraint defines the relation between the temporal references in different simulation units. It specifies when the actual interaction can be accomplished. Usually, the most used synchronization constraint specifies that the internal time must be equal i.e., synchronized, in order to exchange data between two models.

An example of rich connectors in the proposed framework are represented in textual and graphical form, as shown in Figure 4. In addition, the editor proposes completion, syntactic checking, etc.

From an implementation point of view, the modelling environment is defined on top of technologies from the Eclipse Modeling project 1 .

1 https://www.eclipse.org/modeling Fig. 4: Screenshot of the definition of rich connectors in the proposed tool.

IV. COSIM20 RUNTIME FRAMEWORK

In this section, we present a distributed algorithm generated from the information of the modeling environment introduced in the previous section. More specifically the source code implementing the algorithm is generated using the coordination specification contained in the rich connectors and the coordination interfaces.

Before falling into the details of the algorithm presented in Listing 1, we introduce the general idea.

The main idea is that a connector creates an Initiator/Follower relationships on the ports it connects, depending on its triggering conditions. An initiator port initiates the data exchange and choose the time at which it occurs. On the opposite, a follower port waits for the initiator and does not know about the time at which the data exchange must occur. For instance, the triggering condition of the connector cpuTemp2 in Figure 4 is "when value on overHeatController.cpuTemperature is ready to be read". This means that each time the overHeatController simulation unit internally reads the cpuTemperature variable, it pauses just before the reading so that a fresh value can be provided to it (see [START_REF] Liboni | A semantic-aware, accurate and efficient api for (co-)simulation of cps[END_REF] for details). In this case, the target of the connector initiates the data exchange by querying for a value at a specific point in time (to the related follower ports, i.e., the source of the connector). For this mechanism to work correctly, it requires that the simulation unit which exposes the follower ports did not simulate beyond the point in time at which the value is queried. More generally it means that each simulation unit that exposes a follower port should not simulate beyond the minimum point in time of the simulation units exposing the initiator ports. We name this point in time the Temporal Horizon of the simulation unit. Rephrased, it means that a simulation unit which has at least a follower port can never simulate beyond its temporal horizon to be able to correctly handle queries from its connected initiator ports. Sometimes, it is possible to take advantage of deterministic triggering conditions. For instance, the triggering condition of the fanSpeed connector on Figure 4 is "every 5 on CPUinBoxWithFan.time". In this case, statically, the follower ports know when the data exchange will happen (every 5 time units of the CPUinBoxWithFan simulation units). We refer to such ports as DeterministicFollowerPort.

The proposed algorithm runs in parallel for each simulation unit (in the runtime coordination interface of Figure 2). The list of initiator ports, follower ports and deterministic follower ports are parameters of this algorithm, generated from the modeling environment (see line 1 in Listing 1). The algorithm also relies on (1) the native runtime interface of the simulation unit to perform the computational concern and (2) on a distributed communication technology to exchange actions to be performed across the system by other simulation units. It means that an initiator port will send actions to be done by the simulation unit of the associated follower port. These actions are stored in the simulation todo list, which is a list of actions to be done, sorted according to the time at which action must be done. The next action in the todo list is the action with the smallest time. An action is a request to the simulation unit. There are three kinds of action: publish(data, time) to ask a simulation unit to publish a data on a port at a specific time, set(data, value, time) to ask a simulation unit to internally assign a data to value at a specific point in time and updateTH(time) to update the temporal horizon of the simulation unit.

Before to actually run the co-simulation, it computes, according to the list of its initiator port triggering conditions, the predicate at which it is mandatory to pause the simulation. For instance, if we consider the triggering condition of connector cpuTemp2 already explained, the predicate requires that the simulation must pause when the cpuTemperature variable is (internally) ready to be read. The conjunction of such predicates required by the initiator ports is then constructed (line 2).

After the initialization and while the simulation is running, the next action in the todo list is taken (line 4). Note that, a simulation unit can assign itself actions to do, typically if it possesses initiator ports for which actions to be done are a priori known (e.g., to publish a data on a port at every 5 time units).

Each action must be done at a specific point in time, this is the current action time attribute. If the time of the current action is the current simulation time (i.e., the time at which the simulation unit is actually paused) then it performs the action (see lines 5 and 6 of Listing 1).

If the current action is in the future, the simulation unit has to check if it can actually simulate or not (lines 7 and 8). For that, we first check, according to the current action, initiator predicates and deterministic follower ports, what we have to do in the future and how much we can simulate. If we cannot advance in time (the max step size is 0) it means that we have to wait for a new temporal horizon from another simulation unit (i.e., we wait for the temporal horizon from a simulation unit connected to the actual simulation unit through an initiator/follower relation) (line 10). Also, before to wait, we have to reschedule the current action by putting it in the todo list (line 9).

If the max step size is greater then 0, then it is add to the initiator predicates (line 12) and the simulation is restarted (doStep line 13). When the simulation pauses, the now variable is updated according to the stop condition of the doStep call. This stop condition makes explicit the reason why the simulation actually stopped. Pragmatically it refers to the part of the predicate that became true and the algorithm can consequently determine the actions to be submitted to other simulation units. For instance, if the stop condition tells that the simulation units are ready to read the cpuT emperature (see connector cpuT emp2) then the publish(cpuT emperature, now) action is sent to the simulation unit that contains the CPU temperature variable. Thanks to the temporal horizon mechanism (lines 8 to 10), the time in the simulation unit that will receive the action will be lower or equals to the local now sent in the publish action. Eventually, the emitter of the action will receive a set action with the requested value of the variable at the correct time. Finally, depending on the stop condition reason, the current action may be accomplished or not. If not, it is rescheduled (lines 16 and 17).

todo.add(action)

If the coordination defined by the rich connector does not violate constraints (see the previous section) then this algorithm ensures that no action in the past will be present in the todo list of a simulation unit. In other words, there is no need to rollback. Additionally, as shown in the next section, such an algorithm drastically reduce the number of required communication between simulation units and avoid timing bias like the one of Figure 1.

From an implementation point of view, the data exchanges are realized by using the ∅MQ library 2 . This allowed us to define runtime coordination API in different languages and to abstract the network stack by using ∅MQ distributed queues. Moreover, since the topology is static and a priori known (defined in the modeling environment), we chose a pointto-point communication to avoid having a router that may introduce performance bottleneck due to the single-point-ofrouting.

V. VALIDATION OF THE APPROACH AND RESULTS

As a representative case study, we used a CPU cooling system composed of 3 simulation units (see Figure 4). The BoxWithCPU and the FanController have been developed in OpenModelica 3 and then exported as two different FMUs. They define, respectively, a CPU in a box which is cooled by a fan, and the proportional controller of the fan speed. The heat is transferred according to the fan speed between the CPU and the box. These units represent the Physical part of our system. The overHeatController has been developed as a state machine in the GEMOC studio 4 and then exported as a simulation unit (see Figure 5). This unit represents the Cyber part of the system. This cyber part evaluates guards of outgoing transitions each time it enters a state. Consequently, in the normalT emp state the cpuT emperature variable is read every 3 seconds and in the tooHot state the CPU temperature is read every 5 seconds.

We defined for each simulation unit its coordination interface (according to their internal semantics) and the coordination by using rich connectors. In this experiment, we defined two different coordination models: a (classical) timetriggered coordination, in which data are exchanged periodically between the simulation units; and a hybrid coordination model that takes advantage of data nature and rich connector triggering conditions proposed in our approach.

2 https://zeromq.org/ 3 https://openmodelica.org/ 4 http://eclipse.org/gemoc

The hybrid coordination is defined in Listing V. There are four Connectors. The two first ones define a time triggered data exchange between the plant and the pid simulation units. Both sampling periods are 5 units of time (i.e., 5 seconds) as defined lines 6 and 12. For the third connector (line 17) the data exchange is done only when the ctrl is ready to read the cpuT emperature. Finally, for the fourth connector (line 23) the interaction is realized each time the switch internal event of the ctrl occurs. § ¤ 1 load "overHeatController.mbi" as ctrl 2 load "fanController.mbi" as pid 3 load "CPUinBoxWithFan.mbi" as plant

¦ ¥

In opposite in the time triggered coordination, all connectors exchange data with a fixed sample rate. We realized experiments with a sample rate (∆t) of 1 second, 5 seconds and 10 seconds. The framework automatically generated the executable codes (see https://project.inria.fr/icise2020/ for videos and screenshots). Table I reports some results from the experiments: the number of communication points between BoxWithCPU and OverHeatCTRL, and the associated CP U temperature delays between the production of the value by the plant and its reading by the ctrl. The CPU temperature delay is a cumulative delay caused by the non-synchronization between the internal sample rate of the ctrl and the delay introduced by the sampling rate. The elapsed time is the clock time spent to simulate 30'000 seconds of the system (about 8 hours and 20 minutes of simulated time). What we can learn from this table is that the delay decreases when the sampling rate increases. This is expected since the data is fresher when sampled internally by the controller. However, the number of communication points and the time needed to simulate increases since more time is spent to communicate. In the opposite, the proposed approach, taking advantage of the rich connector, allow to remove the temporal delay by exchanging data only when required by the internal semantics of the simulation unit. In this case, we can see that the number of communication between the simulation units is reduced to its strict minimum to have 0 delay in the CP U T emperature. Since communication points are reduced to their minimum, the performance is the one required to have correct results. Additionally, Figure 6 gives a graphical representation of the CP U T emperature delay on variables that measure the temperature (top) and the switch of the fan (bottom). Compared to the values obtained by the hybrid approach, Time-Triggered values are shifted on the right due to the introduced cumulative delay. As already explained, to minimize this issue it is possible to reduce the ∆ step size, but the number of communication points and the simulation time will respectively increase. It is important to see here that a coordination which does not consider the data nature of input/output can introduce delay and consequently provide erroneous results.

VI. CONCLUSION

In this paper, we proposed an integrated modeling environment dedicated to the modeling of co-simulation. It provides rich editors (with completion, syntax check, graphical editing, etc) to support a language based on rich connectors. Rich connectors enable the definition of correct coordination between simulation units of Cyber Physical Systems. Additionally, the IDE automatically generates code for distributed co-simulation. The generated code is based on point-to-point coordination between simulation units. A case study shows the different benefits of the proposed framework. First, by proposing appropriate connectors it allows the designer to define a correct coordination, i.e., coordination for which the co-simulation does not introduce unexpected delays. This is important since early V&V should not be biased due to the co-simulation framework. Second, it reduces the communication between the units to their strict minimum to ensure correctness. Less communication means better simulation performance. Finally, the high degree of automation in the framework removes the time-consuming task of writing a correct coordination. Many future works are envisioned for the framework. First, we are discussing with Safran to put the framework open source so that it helps to create a community beyond the company itself. Second, we plan to add features in the IDE to represent the actual network and help in the deployment of the different simulation units on the different nodes (according to the expected number of communications between nodes). Finally, amongst other future work, we would like to investigate how to embed rich connectors in existing model-based system engineering tools.

Fig. 1 :

 1 Fig. 1: Sources of errors in a time-triggered co-simulation algorithm.

Fig. 2 :

 2 Fig. 2: Overview of the Cosim20 framework.

Algorithm 1

 1 Pseudo-Code for the Wrapper Coordination Algorithm. if currentAction! = done then 17:

Fig. 5 :

 5 Fig. 5: Internal State Machine of the ctrl Simulation Unit.

Fig. 6 :

 6 Fig. 6: Comparison betweent the results obtained by using Time-Triggered (TT) and Hybrid coordination. The ∆ step size is set at 5 seconds.

TABLE I :

 I Experimental number of Communication Points and Delay on the CPU temperature variable for the Time-Triggered (TT) coordination and the Hybrid coordination.

				CPU Cooling System Simulation
			Communication Points	CPUTemperature	Elapsed
			Per Variable (#)	Delay (seconds)	Time
		∆Size	isStopped	T emp	Avg.	M ax (seconds)
		1	30000	30000	82	190	335
	TT	5	6000	6000	792.7	890	138
		10	3000	3000 2361.8	1969	89
	CoSim20	1	100	9022	0	0	210