A Model-Driven Based Environment for Automatic Model Coordination Matias Ezequiel Vara Larsen∗ , Julien DeAntoni∗ , Benoit Combemale† , and Frédéric Mallet∗ ∗ Université Nice-Sophia Antipolis, I3S, INRIA, France † INRIA and University of Rennes 1, France Abstract—We present the integration of the Behavioral Co- e.g., editing, graphical representation, animation and execution ordination Operator Language (B-CO O L) into the GEMOC of domain-specific tools, B-CO O L adds coordination facili- Studio. B-CO O L enables the system designer to automate the ties. While the main paper [3] introduces the main research coordination of models by specifying Operators between Domain- Specific Modeling Languages. In this demonstration, we present challenges, this demonstration focuses on the technical choices how B-CO O L is used to coordinate the heterogeneous model of and implementation difficulties. a video surveillance system. To this propose, we define operators This paper is organized as follows. Section II motivates between timed finite state machines and activity diagrams. These our work by comparing with state of art approaches. This operators are used to generate an explicit model of coordination section also presents the background needed to understand that can be executed and verified 1 . This demonstration comes as a support for the paper accepted into the main conference. the approach. Section III presents B-CO O L and how it is Index Terms—Heterogeneous Modeling, Coordination Lan- integrated into the GEMOC studio. In Section IV, we describe guages, DSMLs the demonstration, which relies on B-CO O L to capture three coordination patterns between two languages: TFSM and I. I NTRODUCTION fUML Activities. The patterns are captured as four operators The development of complex software intensive systems in- later used to coordinate the model of a surveillance video volves interactions between different subsystems. For instance, system. Section V gives a comparison with related work. embedded and cyber-physical systems require the interaction II. M OTIVATION AND BACKGROUND of multiple computing resources (general-purpose processors, The coordination between models can be explicitly modeled DSP, GPU), and various digital or analog devices (sensors, by using a coordination language (e.g., Linda [4], Esper [5]). actuators) connected through a wide range of heterogeneous A system designer can define one or more coordination communication resources (buses, networks, meshes). The de- specifications to specify how models interact. This results in sign of complex systems often relies on several Domain a global behavior that is explicit and amenable for reasoning Specific Modeling Languages (DSMLs) that may pertain to (for instance for Verification and Validation activities). The different theoretical domains with different expected expres- major drawback of these approaches is that the coordination siveness and properties. As a result, several models conforming is done manually by the system designer. With the increasing to different DSMLs are developed and the specification of the number and heterogeneity of the model behavior, this task can overall system becomes heterogeneous. quickly become difficult and error prone. To ease the development of such complex systems, tools More recent approaches [1], [2], [6], [7] identified that the must allow system designers to edit, execute, simulate, and coordination of models can be a systematic activity the system animate their models. Furthermore, to verify and validate the designer repeats many times and can consequently be defined system as a whole, they should be able to specify how mod- as a pattern. Such a pattern is based on the know-how of the els interact/coordinate with each other. Current Coordination system designer and sometimes on naming or organizational frameworks [1], [2] propose an environment to develop and conventions adopted by the models. Thus, they have captured coordinate heterogeneous models. However, they are bound the specification of such a behavioral coordination pattern into to a fixed set of coordination patterns (e.g., hierarchical a tool. They specify the coordination between heterogeneous coordination of models in Ptolemy). languages instead of specifying it between particular models. In this demonstration, we present the integration of B- Such specification is then applied on a set of models to CO O L [3] into the GEMOC studio2 . B-CO O L is a dedicated automatically instantiate a model of coordination. This is the language that allows for capturing coordination patterns for case of Ptolemy [1], a framework that enables the system a given set of DSMLs. These patterns are captured at the designer to hierarchically coordinate heterogeneous models. language level, and then used to derive a coordination spec- However, these approaches embed the coordination pattern ification automatically for models conforming to the targeted inside a tool by using a general-purpose language (GPL). This DSMLs. While the GEMOC studio supports several facilities has mainly two drawbacks: 1 https://youtu.be/skXrpKlv6C4 • The semantics of the coordination is hidden into a tool 2 http://www.gemoc.org and is not made explicit thus potentially leading misun- derstanding and errors. In addition, since the coordination ECL BCOoL CCSL ECL relies on GPL, the validation and verification of the coordinated system remains limited. Language 1 BCOoLLib Language 2 • The system designer cannot change the coordination 1 specification without altering the core of the tool. This Interface1.ecl Interface1.ecl MyOperator.bcool Interface2.ecl Interface2.ecl work needs a good knowledge of the language itself (e.g., Java in Ptolemy), which is beyond the expected 2 skills of a system designer. MyOperator.qvto In our approach, we propose B-CO O L: a (meta)language to Model 1 capture behavioral coordination patterns between DSMLs. B- Model 2 Model 3 3 Model A Model B Model C CO O L is a dedicated language to system designer that eases Exec Exec Exec Exec the understanding and adaptation of coordination patterns. Model.ccsl Model.ccsl Coordination.ccsl 4 Model.ccsl Model.ccsl By instantiating a coordination pattern, models are automat- ically coordinated. The generated coordination specification Generates Conforms To Imports Parameter Of conforms to a formal language, thus enabling verification and validation activities. To be able to specify the coordination Fig. 1. B-CO O L Language Workbench between languages, a partial representation of the language behavioral semantics is mandatory. In our approach, the se- mantics of languages is abstracted by using a language behav- B-CO O L is developed as a set of plugins for Eclipse4 ioral interface made of Domain Specific Events (DSE) [8]. DSE as part of the GEMOC studio5 . B-CO O L is itself based on act as coordination points on the behavioral semantics of lan- EMF and its abstract syntax has been developed using Ecore guages. Coordination patterns are thus captured as constraints (i.e., the meta-language associated with EMF). The textual at the language level on the DSE. When models conformed concrete syntax has been developed by using Xtext6 thus to the coordinated languages are known, the coordination providing advanced editing facilities. between them can be automatically generated. The B-CO O L specification is defined between languages In the following, we first present the current integration of by relying on its language behavioral interface made of DSE. B-CO O L into the GEMOC studio3 , and then we demonstrate B-CO O L takes advantage of the ECL (standing as Event how the approach is used to: Constraint Language [9]) specification of a DSML to extract the language behavioral interface. ECL is an extension of • capture explicitly the specification of coordination pat- OCL [10] with events that allows augmenting AS metaclass terns between the TFSM and fUML Activity languages. and add DSE. To get the DSE, the ECL specification of each • generate the coordination specification for a video language must be imported (step 1 in Figure 1). Once defined, surveillance system. the B-CO O L specification is used to generate an executable • execute the coordinated system. coordination model used to simulate the coordinated execution of some input models. From a B-CO O L specification, the III. D ESCRIPTION OF THE A PPROACH automatic generation of the coordination is made in two steps (step 2 and step3 in Figure 1). To ease this task, the studio B-CO O L is a dedicated (meta)language that enables system provides two plug-ins. designers to capture coordination patterns between DSMLs. The first step consists in the automatic generation of a In B-CO O L, the coordination is specified between languages transformation by using a higher order transformation written by relying on a language behavioral interface made of DSE. in acceleo7 (step 2 in Figure 1). The acceleo transformation Coordination patterns are captured by using Operators that translates the B-CO O L specification into a QVTo transforma- specify how the DSE of different language behavioral in- tion. Then, the second step (step 3 in Figure 1) consists in terfaces are related. Operators rely on a Correspondence applying the QVTo transformation between the models. matching and a Coordination rule. The correspondence match- The QVTo transformation takes as an input any models ing identifies what elements from the behavioral interfaces conforming to the languages used in the operator and generates (i.e., what instance of DSE) must be selected. The coordination as an output the coordination model for these models. The rule operates on elements of the semantics (i.e., instances of resulting coordination model is a CCSL [11] specification, DSE ), and it specifies the, possibly timed, synchronizations which is a formal language dedicated to define the possibly and causality relations between the selected instances of DSE. timed synchronizations and causality relationships between From a B-CO O L specification, the coordination specification some events. Note that CCSL is also used to specify the is automatically generated as constraints between instances of DSE of specific models. Therefore, the generated coordination 4 http://www.eclipse.org specification is an instance of a given coordination pattern. 5 http://gemoc.org/studio/ 6 http://www.eclipse.org/Xtext/ 3 http://www.gemoc.org 7 http://www.eclipse.org/acceleo/ 1 2 3 Fig. 2. Definition of Coordination Operators between the TFSM and fUML Fig. 3. Generation of the coordination specification for a surveillance camera languages system execution model of a model. This is convenient in our case system is composed of a camera (CameraControl in Figure 3) since eases the execution of the coordinated model. and a battery control (BatteryControl in Figure 3). The camera The GEMOC studio can then be used to execute this takes pictures by using either the JPEG2000 (HighBattery in coordination specification (step 4 in Figure 1). For instance, Figure 3) or JPG (LowBattery in Figure 3) algorithm and is it is possible to obtain a timing output of the execution of the powered by a battery. When the battery is low, the battery coordinated system by using TimeSquare 8 . The workbench control makes the camera use the JPG algorithm, thus reducing also offers the possibility to obtain by exploration quantitative the quality of the picture but also the energy consumption [13]. results on the scheduling state-space. When the battery is high, the JPEG2000 algorithm is used instead. IV. D ESCRIPTION OF THE D EMONSTRATION To coordinate the models, we have to specify a timing In the demonstration, we use the integrated workbench to and hierarchical coordination between the states of the TFSM automatically coordinate the model of a video surveillance sys- CameraControl and the activities doJPEG and doJPEG2000. tem. To do so, we use B-CO O L to define four operators. Each In addition, we have to synchronize the activity BatteryControl operator captures a given coordination pattern between two and the TFSM CameraControl by coordinating the correspond- different languages: TFSM and fUML activity language [12]. ing Actions and TFSM events. Then, we use these operators to generate the coordination for To generate the coordination for these models, we first gen- the video surveillance system. A more precise description of erate the corresponding QVTo transformation by invoking the this example is presented in [3]. plug-in provided by the studio (step 2 in Figure 2)9 . Then, we In a B-CO O L specification named TFSMandfUMLopera- apply the qvto transformation on these models. We select the tors, we define four coordination operators between the TFSM models, and then, we invoke the plug-in (step 3 in Figure 3). and fUML language. The first operator, named SyncProduct, The generated coordination specification corresponds to eight coordinates the occurrences of TFSM events with the start CCSL relations that can be executed and analyzed by using of fUML Actions. In the second and third operators, named TimeSquare. Figure 4 shows the resulting timing execution of StateEntering and StateLeaving, we specify a hierarchical the coordinated system. coordination between the TFSM and fUML language. In our A video presenting the whole demonstration (definition, case, we chose the semantics in which entering a specific state compilation, execution) can be found on the companion web- of a TFSM model triggers the execution of a given fUML page10 . In addition, the webpage contains other examples. All activity. The fourth operator deals with the temporal aspects examples are hosted in Github11 at BCOoLExamples12 of the coordination. It specifies how the time in the TFSM elapses during the execution of the activities. This coordination A. Take-Away Lessons is also hierarchical but only considers the timing aspects. The The coordination of the surveillance camera system requires operator enforces the execution of the “internal” activity to be the specification of eight CCSL relations. By manually coordi- atomic with respect to the time in the TFSM model. nating the models, this would require specifying each relation We use the operators previously defined to coordinate the manually. The reader can notice that the number of relations heterogeneous model of a surveillance camera system. The increases with the number of model elements involved in the model of the system has been developed by using the graphical coordination. For instance, for a system with N cameras, the tooling proposed in the GEMOC studio. Figure 3 illustrates the whole model of the video surveillance system by using TF- 9 In this example, the generated QVTo contains 846 lines SMs and Activities. Roughly speaking, the video surveillance 10 http://timesquare.inria.fr/BCOoL 11 http://www.github.com 8 http://timesquare.inria.fr 12 http://matiasvara.github.io/BCOoLExamples/ the execution order among internal actors. Based on a fixed 44 syntax, these approaches provide a dedicated environment to develop heterogeneous models. In addition, they enable the system designer to hierarchical coordinate models. The environments include a graphical editor, an execution engine, plotters and so on. These environments, however, are ad-hoc solutions to manage both the development and the coordination of heterogeneous models. Differently, in our approach, the workbench is the integration of several plug-ins that deal with different aspects of the heterogeneous development of models, e.g., the GEMOC studio for the design and implementation of DSMLs, the Sirius animator for graphical representation, Fig. 4. Execution of the coordinated system by using TimeSquare TimeSquare for the analysis of model execution. Our approach takes advantages of this collaborative environment, and it system designer would need to specify 8*N relations. Our provides the means for model coordination. proposition is to leverage this task for the system designer ACKNOWLEDGMENT at the language level and then to generate all the required relations accordingly. This work is partially supported by the ANR INS Project We want to highlight that variations of the semantics of GEMOC (ANR-12-INSE-0011). the resulting coordination can be done by only modifying R EFERENCES the coordination rules of the operators. In frameworks like [1] B. Evans, A. Kamas, and E. A. Lee, “Design and simulation of Ptolemy, such a variation is only supported by changing the heterogeneous systems using ptolemy,” in Proceedings of ARPA RASSP current implementation of a director written in Java. The Conference, 1994. same problem appears in ad-hoc translational approaches [6], [2] F. Boulanger and C. Hardebolle, “Simulation of Multi-Formalism Mod- els with ModHel’X,” in ICST, 2008. where the transformation needs to be changed. Since this state [3] M. E. Vara Larsen, J. Deantoni, B. Combemale, and F. Mallet, “A of the art approach is using general-purpose transformation Behavioral Coordination Operator Language (BCOoL),” Aug. 2015. frameworks, this work needs a good knowledge of coordinated [Online]. Available: https://hal.inria.fr/hal-01182773 [4] D. Gelernter and N. Carriero, “Coordination languages and their signif- languages as well as a good knowledge of the transformation icance,” Commun. ACM, 1992. language itself. This is beyond the expected skills of a system [5] Esper, “Espertech,” 2009. designer. In our approach, we are using a language dedicated to [6] M. Di Natale, F. Chirico, A. Sindico, and A. Sangiovanni-Vincentelli, “An MDA approach for the generation of communication adapters system designer thus easing the understanding and adaptation integrating SW and FW components from Simulink,” in ACM/IEEE of the B-CO O L specification. Models, 2014. [7] P. Bjureus and A. Jantsch, “Modeling of mixed control and dataflow V. R ELATED W ORK systems in MASCOT,” VLSI Systems, IEEE Transactions on, 2001. [8] B. Combemale, J. Deantoni, M. Vara Larsen, F. Mallet, O. Barais, We consider as related work the coordination frameworks B. Baudry, and R. France, “Reifying Concurrency for Executable Ptolemy [1] and ModHel’X [2] that provide a dedicated Metamodeling,” in SLE, 2013. environment to develop and coordinate heterogeneous models. [9] J. Deantoni and F. Mallet, “ECL: the Event Constraint Language, an Extension of OCL with Events,” INRIA, Research report, 2012. These frameworks rely on a common syntax based on actors [10] UML Object Constraint Language (OCL) 2.0, OMG, 2003. and a semantics given by Models of Computation (MoC). [11] C. André, “Syntax and Semantics of the Clock Constraint Specification Models are represented as actors that can be atomic or Language (CCSL),” Tech. Rep., 2009. [12] Semantics of a Foundational Subset for Executable UML Models composite, i.e., made of internal actors. Each composite actor (fUML), Version 1.0, OMG, 2011. follows an explicit model of computation implemented as a [13] M. Rhepp, H. Stgner, and A. Uhl, “Comparison of jpeg and jpeg 2000 Domain. A domain defines the communication semantics and in low-power confidential image transmission,” in SPC, 2004.