Implementing the Behavioral Semantics of Diagrammatic Languages by Co-simulation

Due to the multidisciplinary nature of cyberphysical systems, it is impossible for an existing modeling language to be used effectively in all cases. For this reason, the development of domain-specific modeling languages is beginning to become an integral part of the modeling process. This diversification of modeling languages often implies the need to co-simulate subsystems in order to obtain the effect of a complete system. This paper presents how behavioral semantics of a diagrammatic DSML can be implemented by co-simulation. For the formal specification of the language we used mechanisms from the category theory. To specify behavioral semantics, we introduced the notion of behavioral rule as an aggregation between a graph transformation and a behavioral action. The paper also contains a relevant example and demonstrates that the implementation of behavioral semantics of a diagrammatic model can be achieved by co-simulating standalone FMUs associated to behavioral rules. Keywords—DSML; cyber-physical systems; behavioral semantics; standalone FMU; FMI; diagrammatic language


I. INTRODUCTION
In the context of moving the effort from writing code to writing models, the development of modeling tools, appropriate to the domain of modeling, becomes an essential factor for increasing the efficiency of the modeling process. The diagrammatic syntax of domain-specific modeling languages (DSML) seems to be the most accessible for all parties involved in the model specification, because it is intuitive and can provide support in all phases of model development, starting with the informal model and ending with the executable model [1,2].
Models specified with these DSMLs must, in turn, interact with other models specified in other languages. Often the models specified with these DSMLs assemble heterogeneous components, which must be modeled with other languages. All these components can be specified in various modeling languages. But there is a need for a specific language to assemble the system components into a workflow [3] and coordinate the behavior of these components. In our opinion, these interaction problems can be solved elegantly by cosimulation [4].
One of the main objectives of building a model is to study the behavior of a system in order to analyze and optimize the modeled system. Due to the complexity of the systems, classical optimization methods cannot be used and therefore must be replaced by methods based on simulation or genetic algorithms. To achieve these objectives the model will have to be executed by a simulator according to its behavioral rules to mimic the behavior of the system.
Complex systems such as Cyber-Physical Production Systems (CPPS) also have a high degree of heterogeneity and therefore involve components with different behaviors that cannot be efficiently specified in the same formalism. In these cases, we need a co-simulation environment that combines several simulators into one and that reproduces the behavior of the global system [5].
In order for these heterogeneous models to be coupled in the co-simulation process, they need to provide a common standardized interface. This interface is called Functional Mock-up Interface (FMI) [6] introduced in the European MODELISAR project, carried out in the period 2008-2011.
To achieve the goal of co-simulation, modeling tools must be able to generate co-simulation units with FMI interfaces, which are called Functional Mock-up Units (FMU). The orchestration of the components in order to obtain the behavior of the composite system is done by an orchestrator which is called master algorithm.
We believe that for the efficient implementation of a DSML, co-simulation mechanisms must be an integral part in the process of specifying and implementing a modeling tool. In this paper we present the methodology for specifying and implementing a DSML with FMU generation facility. To formalize the model, we use mechanisms from category theory. For co-simulation we used the INTO-CPS [7] tool chain. INTO-CPS is an EU-funded project that integrates a chain of tools for model-based CPS design and implementation by co-simulating components with an FMIcompatible interface.
In Section 2, we briefly specify the static metamodel of a diagrammatic model. In Section 3, we specify the behavioral syntax of the model and in Section 4, we deal with the semantic mapping of a model. In Section 5, we briefly present the mechanism for generating FMU components. Section 6 concludes the paper with original contributions and conclusions. All the mechanisms presented are exemplified with a simple model that was implemented on the ADOxx metamodeling platform.

II. THE STATIC MODEL
In essence, a visual model of a system first defines the syntax of the static and behavioral model that represents the virtual and physical entities of the model and then the (IJACSA) International Journal of Advanced Computer Science and Applications, Vol. 11, No. 9, 2020 530 | P a g e www.ijacsa.thesai.org semantics of the model represented by the significance of static constructions and a set of behavioral rules that represent the behavior of these entities.
Syntactically, a diagrammatic model is a graph with several types of nodes that represent different concepts in the domain of modeling and several types of arcs that represent links between these concepts [8,9]. When we want to associate models with a spatial representation, we can use a second graph, as a spatial dimension of them and thus we reach the notion of bigraph [10]. The models discussed in this paper have as syntactic representation a single graph. Example 1. We consider a modeling language SML (Simple Modeling Language) that has the following concepts: A buffer concept, which can store a single type of material, which we denote by B 1 , and endow it with two attributes, namely: the stock attribute which represents the current quantity stored in the buffer and capacity which represents the maximum quantity that can be stored in the buffer. We associate to this concept the following graphic notation: A buffer concept, which can store two types of materials, which we denote by B 2 , and endow it with four attributes, namely: the attributes stock1, stock2 which represents the current quantity of each type stored in the buffer and capacity1, capacity2 which represents the maximum quantity of each type, which can be stored in the buffer. We associate to this concept the following graphic notation: A processing or transfer activity concept, which we denote by W 1 , and which can process or transfer materials from a type B 1 buffer to a type B 2 buffer, and endow it with three attributes, namely, the StockIn attribute which represents the quantity of material fed from buffer B 1 , and the attributes Stock1Out, Stock2Out which represent the quantities of material of each type deposited in buffer B 2 . We associate to this concept the following graphic notation: A processing or transfer activity concept, which we denote by W 2 , and which can process or transfer materials from a type B 2 buffer to a type B 1 buffer, and endow it with three attributes, namely: the attributes Stock1In, Stock2In which represents the quantities of material fed from each type and the StockOut attribute which represents the quantity of material deposited in buffer B 1 . We associate to this concept the following graphic notation: The SML model that we will specify is a graphical DSML for describing simple models in conformity with the requirements specified above. SML models, therefore, are graphs with a set of syntactic restrictions on their components [11]. In the categorical model, the SML metamodel is a sketch that is composed of a graph and a set of constraints on the graph nodes [2,12,13]. Example 2. We will define a SML model as a graph G=(X,,,), on the components of which we introduce four restrictions, namely: 1) The nodes of the graph are of two types and these types determine a partition on X, i.e.: X=B1⊔B2; 2) The arcs of the graph are of two types and these types determine a partition on , i.e.: =W 1 ⊔W 2 ; 3) Graph G has to be a connected graph; 4) There must be at most one arc between any two components.
A categorical sketch is a tuple =( , ( )) where is a graph and ( ) is a set of constraints on the set of nodes and arcs of the graph [2]. A model of the sketch =( , ( )) is the image of this sketch through a functor in the Set category.
From the way of defining the SML model, from example 2 it results that the graph of the corresponding sketch =( , ( )) is the one from Fig. 1.
The categorical sketches are based on the observation that a labeled diagram is an analogous construction of a logical formula that is mapped to the components of a graph, i.e. to the nodes and arcs of a graph [2,14].
We denote with Graph the category of graphs, i.e. the category that has graphs as objects and as arcs the homomorphisms between these graphs. We will also denote with Graph 0 the set of objects of the Graph category and with Graph 1 the set of arcs of the Graph category.
Constraints on the models specified by the categorical sketch are defined by a predicate signature diagram, which is composed of a set of predicates , and an application are: Graph 0 , which maps the indeterminate predicates to the nodes of a graph in Graph 0 [2]. This predicate signature diagram, allows the definition of constraints on the models specified by a categorical sketch at the metamodel level.
For example, for the graph G to be connected we will put the condition that the pushout of  with  to be a terminal object in the Set category.
Therefore, the categorical sketch of the SML model has the following components: the graph of the sketch is the one from Fig. 1, and the set of constraints () is obtained by mapping the shape graphs corresponding to the predicates from  to the components of the sketch graph by means of diagrams, i.e. ()={ (P i ) | P i , i1}. The categorical sketch = ( , ()) represents the abstract syntax of the SML models and at the same time the SML metamodel.
Each model specified by the categorical sketch , is the image of the graph of the sketch through a functor M, in the Set category, which respects the constraints imposed by the predicates (). The predicates in the set () will be mapped, at the level of each model M, from the Set category to a set of predicates as follows: Thus, if we have the model M: Sets, where M(b 1 )=B 1 , M(b 2 )=B 2 , M(w 1 )=W 1 and M(w 2 )=W 2 , then the set of instances B 1 , B 2 , W 1 , W 2 , will respect the constraints defined by the set of predicates Set(P i ). We notice that the graph of the categorical sketch contains besides the concepts from the modeling domain, also auxiliary nodes useful for imposing constraints.
If in the above model we have: B 1 ={B 11 13 , then the SML model is like in Fig. 2.
We will consider that the nodes of the graph of the sketch are classes endowed with attributes. The graph nodes will be mapped by the functor M to sets of objects of the corresponding class type in the Set category, and the graph arcs will be mapped to functions between these sets. The semantics of such a static model is given by the significance of the attributes, the significance of the values of these attributes and the significance of the graph structure of the model.
A class defines a concrete modeling concept that can be used to specify a model in the modeling language. Therefore, each concrete concept of a model created with a tool implemented on the ADOxx platform is an instance of a class. Each concrete class has a distinct name.

III. BEHAVIORAL SYNTAX OF THE MODELING LANGUAGE
Model transformation is one of the key techniques in MDE used especially for automating model management operations, such as code generation, model optimization, translation from one DSML to another, simulation, etc.
The transformation of diagrammatic models is based on, most often, the graph transformations defined by graph rules, also called productions. Such a production is a tuple p=(L, R), consisting of two graphs; a left graph L, a right graph R and a mechanism that specifies the conditions and how to replace L with R.
In this paper we will use graph transformations to model the behavior of a diagrammatic model. Graph transformation rules are mechanisms that can express the local changes of a graph in successive transformation steps ordered by a relationship of causal dependence of actions and therefore can accurately define the behavior of a diagrammatic model.
In the approaches of implementing the transformations, of the left graph to the right graph, two distinct mechanisms are distinguished, namely, the double pushout (DPO) and single pushout (SPO) [15,16]. Graph transformations allow the simultaneous transformation of the structure of the diagrammatic model and of the attributes of the components. In this paper we will use the DPO variant to specify the behavioral dimension of a model.
The correct application of a production p is made under the conditions in which the squares in Fig. 3 are pushout squares. A set of productions related to each other form a graph transformation system and can be used in the process of transforming models without being integrated into a graph grammar [15,17,18].
The behavior of SML models is not based on structural transformations of the graph but only on changing attribute values and therefore we will use graph transformations only to specify the context necessary to locate the components involved in a behavioral rule and to locate critical regions in the simulation process.
We will define the graph transformations at the metamodel level and they will be applied for any static model specified by the sketch in the Set category.
In the case of our SML model we have two transformations at the level of the sketch from Fig. 1, namely, p1 (Fig. 4) and p2 (Fig. 5).

IV. SEMANTICS OF THE MODELING LANGUAGE
A diagrammatic model is characterized by two dimensions: a static dimension, specified syntactically by the categorical sketch, and a behavioral dimension, specified syntactically by behavioral signatures. The two dimensions have dependent but still distinct semantics. Defining the semantics of the static dimension involves mapping the attributes with which the components of the graph of the categorical sketch are endowed to data domains and the graph structures of the model to well defined semantically structures, and defining behavioral semantics involves mapping the behavioral signature to mathematical functions.
The semantics of a model involves mapping attributes to their set of values, interpreting the graph structure of the model, while behavioral semantics highlights the structural and value transformations of the model.
The behavioral dimension of a SML model is defined by states and transitions. The states of the model are represented, in our approach, by the static models of the categorical sketch, and the transitions are represented by a set of mathematical functions associated with the behavioral rules. A behavioral rule can be applied only in the context in which a set of conditions are realized, represented by logical predicates that verify the state of the model. Therefore, a behavioral rule is defined as an association between a graph transformation and an action.
We will define the behavioral rules at the metamodel level by behavioral signatures represented by predefined actions with formal parameters, which will be evaluated at the moment of execution of a model, when they will receive current parameters corresponding to the respective concrete model.
We denote with AGraph the category of graphs with attributes, i.e. the category that has as objects graphs with attributes and as arcs the homomophisms between these graphs. Also, if GAGraph 0 , we will denote with attr(G) the set of attributes associated with the nodes and arcs of the graph G.
A diagram actions signature is a tuple =( , ar) where is a set of actions and ar is a function ar: Graph 0 which maps each action Act to two objects in the AGraph category as follows: if (y 1 ,...,y m ):=Act(u 1 ,...,u n ) then the outputs y 1 ,...,y m will be mapped to the attributes of the graph R and the inputs u 1 , ...,u n will be mapped to the attributes of the graph L. The pair (L, R) of graphs is called shape graph arity of Act, ar(Act)=(L, R). We will sometimes denote the image of Act through ar in the category AGraph with Act(L, R).
The behavioral signature is a tuple =( ,C L ,,C R ) where is a set of graph transformation rules; C L =( L ,ar L ) is a diagram predicate signature such that ar L : L AGraph 0 , which we call the precondition signature; C R =( R ,ar R ) is a diagram predicate signature such that ar R : R AGraph 0 , which we call the postcondition signature and  is a diagram actions signature, with the property that for any Act there is p , p=L ←K →R with ar(Act)=(L, R), that specifies how to transform the attributes of graph L which is the domain of action into the components of graph R which composes the codomain of the action.
We now denote the graph in Fig. 7 with G 1 (x 1 , x 2 , x 3 ) and the graph with a single node in Fig. 8 we denote it with G 2 (x 1 ). The shape graphs represent the local structures of a model and represent the areas of action of the behavioral rules in the context of a concrete model. These shape graphs represent the local structure of the model, and the context in which a behavioral rule evolves. Behavioral signatures defined on the components of these shape graphs are mapped to behavioral transformations on the component elements of a model.
The behavior of the SML model can be specified by a behavioral signature that contains two behavioral rule signatures  1 and  2 . Since the set of behavioral rule signatures is equivalent to the behavioral signature, we will use the same notation  for the set of behavioral rule signatures.
So ={ 1 , 2 } where: The behavioral signatures thus defined will be transformed into behavioral rules at the level of the metamodel, by mapping them to the components of the sketch , and will represent the behavioral model at the level of the metamodel, i.e. the abstract behavioral semantics of the models. The behavioral rules at the level of the sketch will then be mapped by matches at the level of the models.
The behavioral rule signatures must be mapped to the components of the graph of the sketch by sets of three diagrams, one for each of the graph forms L, R and K. These will be defined by three functors d L , d K and d R , where d K is the restriction of the functors d L and d R at domain K; d k =d l /K=d r /K, l s and r s are monomorphisms that inject the graph K into L and R, respectively.
Diagrams are functors that map the formal parameters defined by graph shapes to the concepts specified by the nodes of the sketch graph. The same graph shapes are, on the other hand, mapped to the components of a concrete model through matching applications.
A behavioral rule of the sketch is a tuple t=(L ←K →R, d L (C L ),Act(d L (L);d R (R)),d R (C R )) where =(L ← K → R,C L , Act(L;R),C R ) is a signature of a behavioral rule. We used the following notations: d L (C L )=( L ,d L (ar L )); d R (C R )=( R ,d R (ar R )).
Thus, starting from a behavioral signature, we generate a set of behavioral rules at the level of the metamodel, i.e. at the level of the components of the graph of the sketch.
If we denote with (), the set of behavioral rules induced by the behavioral signature , then a behavioral metamodel is a tuple ( , ()) where is the graph of the sketch =( , ( )).
In order for the behavioral rules specified in the metamodel () to be applied at the level of a concrete model we will have to find the matches of each behavioral rule from () in a model from Mod( ,Set).
A match of a graph =(N, A, s, t) in the image of a functor : Set is a total monomorphism of graphs m: ( ) which maps the graph to the graph m =(m(N), m(A), m(s), m(t)) so that y i m(N) x i N with y i (x i ) and a i m(A) r i N with a i (r i ) respecting the conditions of homomorphism m(s(r i ))=m(s)(m(ri)) and m(t(r i ))=m(t)(m(ri)) for all r i A. We will denote the set of graph matches in ( ) with m(, ).
In this way the graph transformations and the actions on the attributes will be executed on a concrete model.
Under these conditions, a behavioral model, in the Set category, contains all the behavioral rules induced by the behavioral signature , in the Set category. We notice that the set of behavioral rules is specific to each concrete model, but they can be implemented generically at the metamodel level.
As we can see each behavioral rule  in Set, defines an application :M L M R , where M L ,M R : Set are functors which represents the domain and codomain of the rule  and all these behavioral applications together, maps the set () of behavioral rules of the sketch into a set of behavioral rules Set() in Set.
In the case of the SML language the atomic behavioral rules in Set,  are of the form =(t, , M L , M R ) () where t () is a behavioral rule t=(L ←K →R, d L (C L ),Act(d L (L); d R (R)), d R (C R )), M L , M R : Mod( , Set) there are two functors, and  is a tuple of match =(m L ,m K ,m R ), m L m(M L ,L), m R m(M R ,R), and m K is the restriction of m L to K, so that the diagram in Fig. 6 is a double pushout.
For the model from Fig. 2 we have 5 behavioral rules in Set(), two for ( 1 ) and three for ( 2 ): Set()={ 11 ,  12 ,  21 ,  22 ,  23 }. www.ijacsa.thesai.org   In our approach, behavioral rules are approached in two distinct phases. In the first phase, these rules are defined, at the metamodel level, by behavioral signatures, and in the second phase, these rules are applied at the level of each concrete model. If the behavioral rules of the model are faithful to the modeled system, then their successive application mimics the behavior of the modeled system.

V. IMPLEMENTATION OF THE FMU GENERATOR
From the formalization presented in this paper results the fact that a diagrammatic metamodel has two dimensions, a static dimension represented by the categorical sketch and a behavioral dimension represented by the behavioral rules. A behavioral rule, as we have defined it, is an aggregation between a graph transformation on the structure of a model and a local action on the attributes of the model. If the functionalities of a metamodeling platform are designed to specify the graph structure of a metamodel and can be endowed with graph transformation facilities, behavioral actions are often performed by complex systems with a high degree of heterogeneity which implies the need for modeling on various modeling platforms. A solution to this problem is the assembly through co-simulation of n+1 independent components where n is the number of behavioral rules. In other words, you can build an FMU component that manages the static dimension of the model together with the graph transformations on it and an FMU component for each behavioral rule that models the action corresponding to the behavioral rule.
Applying a transformation rule specified by a behavioral signature =(L ←K →R,C L ,Act,C R ) is done as follows: 1) We first consider the diagrams d L and d R which maps the behavioral signature  to the model sketch. In this way the components of the diagrams receive the types of components of the sketch.
When we are going to apply a behavioral rule =(t, ,M L ,M R ) () we have the first component M L , which represents the current state of the behavioral model, and we are going to determine the M R component which represents the state in which the transition is made. Therefore we can find the matches m L m(M L ,L) and m K m(M K ,K)=m(M L ,L) which are the first two components of a match. =(m L ,m K ,m R ) (Fig. 11).
2) The preconditions are verified, i.e. the fulfillment of the predicates defined by the C L signatures, among which is the gluing condition. If the C L conditions are met the graph transformation defined by the cospan L ←K →R is executed in two steps, 1 and 2.
a) We calculate the complement M L ( )\((m L (L)\m K (k)) of the pushout of l s with m k , from Fig. 9.
b) Now we can calculate the pushout of r with m k , from Fig. 10 and therefore the functor M R and the component m R m(M R ,R) of the match .
All these transformations are executed temporarily, i.e. with the possibility of being canceled.

3)
In this phase, the Act action is temporarily executed. 4) If the postconditions are also verified then the transformations described at points 2 and 3 are permanently executed, otherwise they are canceled by a rollback operation.
Obviously, independent behavioral rules can be applied simultaneously, and also the same behavioral rule can be applied simultaneously to several areas of the model if these areas do not contain common elements.
The model was implemented on the ADOxx metamodeling platform (see Fig. 12). In the case of the SML metamodel we defined, as it results from the analysis of the graph of the sketch , two classes, corresponding to nodes b 1 and b 2 and two classes' relations corresponding to nodes w 1 and w 2 . Defining classes in ADOxx is done visually, but the metamodel can be exported in ADL language or XML format. We used the ADL language to generate from classes, C structure types for standalone FMU.   The ADOxx metamodeling platform does not include behavior in classes and therefore we generated these classes as types of C structures. If the metamodeling platform would also include behavior this problem can be solved by function pointers. These structures were generated in a <ModelName>_fmu_types.h file, in our case SML_fmu_types.h. This type file is easy to write even manually, because it is written once and can then be used for all models specified with the implemented modeling tool.
We exported from ADOxx the model in ADL format from which we generated the FMU component corresponding to the static model, i.e. a graph structure corresponding to the specified model and with nodes that have corresponding types from the file <ModelName>_fmu_types.h and the name specified in the model. We put this graph structure in a file named <ModelName>_fmu_structure.h, in the case of the SML metamodel, SML_FMU_structure.h. Generating this graph structure is important because it is used in all specified models with the implemented modeling tool.
The behavioral part of the FMU component that manages the static dimension of the model was implemented manually in the C language. This is acceptable because it does not have a high complexity and is written only once for a modeling tool. The generation of this C code is possible but a translator from the ADOScript language to C should be implemented. To write this code we used FMU SDK [19] which can also be used in the case of generation from ADOScript.
FMU components corresponding to behavioral rules are usually written in another modeling tool. In the case of our SML metamodel, we specified the two components corresponding to the behavioral rules T 1 and T 2 in the VDM-RT language and exported them as standalone FMU.
Therefore, for the SML metamodel, we have 3 FMU components (Fig. 13) Which we briefly describe using the notations from [20]. In this sense an FMU is defined as a tuple T 1 =<S c ,U c ,Y c ,set c ,get c ,doStep c >; where: S c is the space of states; U c is the set of input variables; Y c , is the set of output variables; set c :S c U c S c and get c :S c Y c  are the input and output functions and doStep c :S c R + S c is a function that calculates the state after a given step. In the case of SML: S 2 =S 1 , U 2 =U 1 , Y 2 =Y 1 and PT 2 =PT 1 .
For component M we have the inputs and outputs identical to the inputs and outputs of the other two components in the case of the SML model. The doStep M function finds the matches in the model and implements the distribution of activities to the T 1 and T 2 components. Of course, for the T 1 and T 2 components there will be several instances, one for each match. In the case of the example in Fig. 2 we have 2 instances of the T 1 component and three instances of the T 2 component. The distinction between the two types of instances is made by the value of the variables initial_id and final_id. For the co-simulation of the three components we used INTO-CPS. We performed the co-simulation on an example of data and we obtained the output from

VI. ORIGINAL CONTRIBUTIONS AND CONCLUSIONS
In this paper we used the mechanisms of category theory to specify diagrammatic models with co-simulation facilities. We introduced the concept of behavioral rule as an aggregation between a graph transformation and a behavioral action. We defined these behavioral rules by graph signatures at the metamodel level. We also implemented a simple example of diagrammatic language using the ADOxx [21] metamodeling platform. In all the phases of specification and implementation we highlighted the implementation of the constituent components of such an FMU. We performed the co-simulation of a concrete model specified with the SML language on the INTO-CPS platform.
Model transformations, if any, must be implemented in component M (Fig. 13), otherwise they could not be executed in parallel. As a result, the preconditions and postconditions should also be executed in component M. In principle, this is acceptable.
As it results from the previous observations, there are some important problems to be solved that we will deal with in future work such as: the implementation of a more complex model containing graphical transformations or the implementation of the export facility of a tool-wrapper for DSMLs implemented with ADOxx.