A Categorical Model of Process Co-Simulation

A set of dynamic systems in which some entities undergo transformations, or receive certain services in successive phases, can be modeled by processes. The specification of a process consists of a description of the properties of this process as a mathematical object in a suitable modeling language. The language chosen for specifying a process should facilitate the writing of this specification in a very clear and simple form. This raises the need for the use of various types of formalisms that are faithful to the component subsystems of such a system and which are capable of mimicking their varied dynamics. Often in practice, the development of domain specific languages is used to provide building blocks adapted to the processes. Thus, the concept of multi-paradigm modeling arises which involves the combination of different types of models, the decomposition and composition of heterogeneous specified models as well as their simulation. Multi-paradigm modeling presents a variety of challenges such as coupling and transforming the models described in various formalisms, the relationship between models at different levels of abstraction, and the creation of metamodels to facilitate the rapid development of varied formalisms for model specification. The simulation can be seen as a set of state variables that evolve over time. Co-simulation is a synthesis of all simulations of the components of the system, coordinated and synchronized based on interactions between them. The theory of categories provides a framework for organizing and structuring formal systems in which heterogeneous information can be transferred, thus allowing for the building of rigorous cohesion bridges between heterogeneous components. This paper proposes a new model of co-simulation of processes based on the category theory. Keywords—Process modeling; metamodel; modeling grammars; categorical grammars; category theory; categorical sketch; co-simulation, simulation


I. INTRODUCTION
Contemporary systems are, in most cases, integrated from subsystems with complex structures and behaviors from the real or virtual world with various behaviors.Given the diversity of the components and the resulting complexity of the systems, simulation plays an essential role in all phases of system development and optimization.Simulation models at the system level can be developed to help analyze requirements, evaluate potential architectural solutions, and develop detailed design, implementation, and simulation specifications.These models aim at meeting specific objectives of each phase [2,12,14].
The concept of process is one of the possible methods of mathematical modeling of dynamic systems behavior.A process is a mathematical model that represents the behavior of a dynamic system that performs actions.Many systems, especially technological systems, can be modeled as Discrete Event System (DES) driven by discrete events evolving in relation to the occurrence of asynchronous events over time.These systems in which certain entities undergo transformations or receive certain services in successive phases can be modeled by processes.
The purpose of building a process that represents the behavior of a dynamic system is to facilitate the verification of system properties, simulation and system optimization.Therefore choosing the level of detail of the system's actions depends on the analyzed properties.Because a process does not take into account all the details, a behavior of an analyzed system can be represented by several processes that reflect either different degrees of detail of actions performed by a system or different points of view in relation to the intended purpose [12,14].
Specifying a process consists of a description of the properties of this process in the form of a mathematical object.For this we need a proper modeling language.Therefore, the language chosen for specifying a process should facilitate the writing of this specification in a very clear and simple form.Thus, the need for the use of various types of formalisms that are faithful to the component subsystems of such a system and which are capable of mimicking their varied dynamics.Often in practice, the development of domain-specific languages, which provide building blocks adapted to DES models, is used in practice [4].This heterogeneity of the systems inevitably implies the use of heterogeneous processes that provide through specific facilities a greater capacity to describe behaviors and interactions between subsystems than homogeneous processes.Thus, the concept of multi-paradigm modeling arises which involves the combination of different types of models, the decomposition and composition of heterogeneous specified models as well as their simulation.
Multi-paradigm modeling presents a variety of challenges such as coupling and transforming the models described in various formalisms, the relationship between models at different levels of abstraction, and the creation of metamodels to facilitate the rapid development of varied formalisms for model specification.
The simulation can be seen as a set of state variables that evolve over time.The variation space of the states of a simulation can be defined by two axes, a time axis, and a space axis.The objective of the simulation thus becomes, the calculation, ordered in time, of the state variable values.Cosimulation is a synthesis of all simulations of the components of the system, coordinated and synchronized based on interactions between them.www.ijacsa.thesai.org The theory of categories provides a framework for organizing and structuring formal systems in which heterogeneous information can be transferred, thus allowing for the building of rigorous cohesion bridges between heterogeneous components [8,15].
Multi-paradigm modeling involves, among other things, the transformation of structures from a given form into a form required to achieve this cohesion, which is often complicated.The category theory is based on the manipulation of structures consisting of objects and formal functions that coexist and work together as well as the preservation of these structures and their properties when they are transformed from one form into another through functors.This paper proposes a new co-simulation model based on the category theory.In section 3 we present the construction of the simulation category, in section 4 we present the cosimulation model based on the categorical sketch and in section 4 we will see how the co-simulation category is built.

II. THEORETICAL FOUNDATIONS AND NOTES
A category  is an algebra of formal functions in which the operation is the partial formal composition of functions [9,10].The domains and codomains of functions form the set of objects of the category which we denote with ob() and the formal functions are the arcs of the category.We will denote these objects in uppercase A, B, .. X, Y, Z, ... The set of arcs between two objects f:XY will be denoted with  or Hom(X,Y).So, a category is a construct structured from two types of atomic elements, formal functions that we call arrows and objects that are the domains and codomains of formal functions.This structure, completed with the composition operation of arrows, forms an edifice with a remarkable expressivity called the category.Because the functions are formal and the objects of the category could be formal, which implies great flexibility that is essential for modeling.
A functor is an application between two categories: : which maps objects to objects, arrows to arrows, and preserves the structure, i.e. transfers certain properties from one category to another [9,10].
One very important thing for modeling is that a functor can also be viewed as the image of a category in another category, that is, it can be viewed as a substructure consisting of objects and arrows taken together as one entity in a larger structure.These substructures are models of a category in another category.The set of categories together with the functors between them and the composition operation of functors form a category that is called the functors category and is written with Cat.
Between two functors : and :, which have common domains and codomains, we define applications that take the image of  into the image of , respecting some naturality conditions in relation to the arrows in the two categories, which are called natural transformations [9,10].
The structure formed from the set of functors that have common domains and codomains, as objects, along with the set of natural transformations, as arrows, complemented by the composition of natural transformations is a category called the category of functors and natural transformations.
The essential difference between a graph and a category is the composition operation that exists in categories and does not exist in graphs [9,10].But any graph  can be extended to a category called the free category generated by  which has as objects the nodes from , as arrows the arcs from  plus the identity arrows added to each object, and the composition operation is the concatenation of the paths from .In this way, any graph homomorphism naturally extends to a unique functor between the free categories generated by the two graphs.Note that not every functor between two free categories can be restricted to a graph homomorphism.With this remark, we will use the notion of functor even when the domain and/or codomain are graphs.
The image of a graph  in another graph  through a functor D: is called the diagram of  in , and  is called the graph shape of the diagram D. Similarly, the diagram can also be defined if  is a category [9,10].
If we have a diagram D: where  is a graph and  a category then a natural transformation from a constant diagram  C : to D is a commutative cone with the vertex C and the base D [3,4, 9.10].
Among the cones we can define morphisms compatible with the natural transformations from the cone definition and so the set of cones together with these morphisms form the cone category generated by diagram D. The limit of a diagram D in a category  is a terminal element in the cone category generated by diagram D.
There are a series of particular limits, useful in modeling, such as the categorical product which is the limit of a discrete diagram or the limit of a cospan which is a pullback.The pullback for example is useful to characterize monomorphisms.
If we have a diagram D: where  is a graph and  a category then a natural transformation from diagram D to a constant diagram  C : is a commutative cocone with the vertex C and the base D [3,4 ,9,10].
Between cocones we can define morphisms compatible with the natural transformations from the definition of the cocones and so the set of cocones together with these morphisms form the category of cocones generated by the diagram D. The colimit of diagram D in a category  is an initial element in the cocone category generated by diagram D.
There are a series of particular colimits, useful in modeling, such as the disjoint union which is the colimit of a discrete diagram or the colimit of a span which is a pushout.The pushout for example is useful to characterize epimorphisms.
The notion of model exists also in logic.Its definition is based on the mathematical logic language.In the category theory a model can be specified by sketches.The major advantage of the sketches in modeling is that they can be defined by graphical notation for specifying visual modeling grammars.www.ijacsa.thesai.orgThus a sketch =(, , , ) consists of a graph  and three collections of diagrams, namely  which is a collection of commutative diagrams,  which is a collection of cones and  which is a collection of cocones [3,4,9,10].
The arrows of the graph  are sketch operators that can be implemented at the meta-metamodel level, possibly with small adjustments at the metamodel level.The three collections ,  and  can be fully implemented at the meta-metamodel level, thus ensuring the syntactic correctness of any metamodel specified by a sketch.
A model of a sketch =(, , , ) is the image of the graph  through a functor M in the Set category that complies with all the conditions imposed by the collections ,  and , i.e. it selects for each diagram in D a commutative diagram in Set, for each cone from  its limit and for each cocone from  its colimit [3,4,9,10].

III. THE SIMULATION CATEGORY
The simulation consists in reproducing the dynamic behavior of a system in order to obtain conclusions about the behavior of the system.Simulation is very important for analyzing the behavior of complex systems.Simulation of a process in a certain formalism (such as PN, EPC, UML, BPMN) calculates the trace of the process execution in time represented by states, inputs and outputs.The simulation conclusions can be useful for determining the proper structure of the model, identifying the optimum values of the parameters, imitating system behavior, etc. [12,13,14].In many cases, the model has predictive validity, i.e. it is able to predict the behavior of the system in the future [1,2].Simulation of a system (behavior trace) can be described as a language on the set of states (inputs and outputs) in which each word represents a trajectory followed by states (inputs and outputs) of the system.Co-simulation composes the trajectories described by a set of components that interact.Interaction of components is made through incoming and outgoing ports that must be specified in the sketch that generates the model [2,11].These will be associated to the nodes corresponding to the input and output constructs of the sketch.
Thus in [4], the sketch of the Medical Laser Manufacturing Systems (MLMS) metamodel specifies a model as a graph =(X,,,) with imposed restrictions.The imposed restrictions lead to the sketch MLMS [4], L 1 (MLMS)=(,,,) where:  is the graph from Fig. 1 The graph of the sketch contains the nodes corresponding to the atomic concepts of the modeling language such as: set of input buffers for the primary components (xi), set of output buffers for finished products (xo) stations (xw), set of test stations (xt) and nodes corresponding to the associations between them (Fig. 1).
The diagram D 1 defines the function :XX which will become a monomorphism provided that the pullback of  with  defined by cone L 3 is equal to .The Cartesian product is the limit of the discrete diagram L 2 .The function  wt : wt X w becomes a monomorphism provided that the pullback of  wt with  wt has to be  wt , which is imposed by the cone L 4 .The Cocone L 1 will require  to become a terminal object in Set.The condition that the graph is connected is imposed by the limit of the cocone K 1 which will become a terminal element in Set.The cocones K 2 and K 3 serve to partition the concepts of the model [4].
To these nodes we add the node  i in the graph of the sketch representing the input interface and the node  o which represents the output interface represented by the input and output ports of the model.These will be associated with the input and output concepts by the arrows  i and  o (Fig. 1), which will have to become bijective functions in each model.
For the arrow  i to become a surjective function, the pushout of  i with  i should be equal to x i , i.e. the diagram from Fig. 2 has to become a pushout diagram in the Set category.In order for the arrow  i to become an injective function, the pullback of  i with  i will have to be equal to  I , i.e. the diagram from Fig. 3  Therefore, the introduction of interfaces in the metamodel sketch implies in this case the addition of two more cones to the set of cones  according to Fig. 3 and Fig. 5 and adding two more cocones to the set  according to Fig. 2 and Fig. 4. Finally, it follows that the set of cones is ={L 1 ,L 2 ,L 3 ,L 4 ,L 5 ,L 6 } and the set of cocones is ={K 1 ,K 2 ,K 3 ,K 4 ,K 5 }.A model of the sketch  is a functor mapping the graph of the sketch in Set and all diagrams from D in commutative diagrams, all cones from L in cone limits and all cocones from K in cocone colimits.
The sketch  reflects the relation between the abstract definition of a class of models and the concrete models specified by the sketch.Therefore, the sketch is the formal object that specifies the metamodel that in turn represents a class of models and contains all the semantics necessary to express the syntactic constraints of the entities in this class of models.
Therefore, a concrete model of the sketch L 1 is a functor H 2 :L 1 Set that associates to the classes (nodes), in the sketch L 1 , set of extensions of these classes.The H 2 model associates to the nodes (classes) from L 1 with sets of extensions of these classes representing all types of objects that make up the model, as well as all types of relations that can be defined between the entities of the model and the arcs are the sketch operators.We will denote with L 2 =H 2 (L 1 ) a model of the sketch L 1 , i.e. a process constructed according to the grammatical rules imposed by the sketch L 1 .
The behavior of a process is based on the state idea determined by the values of the attributes.The simulation begins with an event initializing the process with the data describing its initial state.Values of attributes that constitute the state of the system at one time produce events that trigger the execution of some actions of the process.Execution of these actions changes the state of the process and as a result determine again the execution of some actions [3,4].
So if we know the state of a process at a certain moment we can simulate the evolution of the process without knowing the history of the previous states that determined the current state.This means that the current state of a process concentrates the entire previous evolution of the process.
In our case a state of the process is represented by an instance of the model [3,4].An instance of the L 2 model is a functor : Sets with the property that ∘H 2 is a model of the sketch L 1 , i.e. it complies with all the conditions imposed by the metamodel, and which associates to each set of classes from L 2 a set of instances, i.e. from each class one or more instances will be created.
If we have two instances ,: Set then we can define a natural transformation :.The set of all instances together with all the natural transformations between them form a category that we call the process reaction category L 2 and we denote it with PRC.Thus, the evolution of the process from one state to another is represented by a natural transformation.
But the process has an initial state that in our case is an initial instance that we denote with  0 .We consider a subcategory of the PRC category, which we call the process simulation category (PSC) that has the objects: Ob(PSC)={ k |Hom( o , k )}, and the arrows are all arrows from the RPC category that have domains and codomains in Ob(PSC).The paths from the PSC category that have as a starting point object the instance  o represent the traces of the model in the simulation or execution process.
In the context of our model, simulation traces are sequences of instances that can be obtained by natural successive transformations from the initial instant.Each trace represents an alternative to executing the process.Therefore, if =ob(PSC) then the set of simulation traces form a language L()* defined as follows: L()={  o  1 …  n * |  k =( k-1 ) for k≥1, and  is a natural transformation and  o is the initial instance}

IV. CATEGORICAL MODEL OF CO-SIMULATION
The modeling of a large system involves the disassembly of the system into several real or virtual components from different domains integrated into a single model.Thus, the model is divided into several submodels, and each of these submodels requires the use of a certain formalism to specify the process in optimal conditions of fidelity, robustness and simplicity.
A process describes the behavior of a natural or artificial entity, real or virtual, under conditions imposed by a particular context.The context can also be represented by other processes that interact with the considered process, which leads to processes composed of several subprocesses.Both the composed process and its individual components are characterized by inputs, outputs, and internal states between which transitions are made that define how inputs and states cause outputs.The overall behavior of a process is therefore a composition of the individual behavior of its subprocesses.
In this type of hierarchical modeling, in which each component is independently specified, a model is a collection of models that in the simulation process must work together to achieve the common goal.This results in a co-simulation process that integrates several independent simulation subprocesses that synchronize to interact with each other.The concept of co-simulation involves subprocess coupling techniques to build the behavior of the integrated process.
Each subprocess has to provide through its ports its functions for other subprocesses involved in co-simulation.Also, the outputs of a subprocess influence the evolution of other subprocesses, and therefore the evolution of each process, although it seems independent, also depends on the evolution of the other processes.
Combining dependent and independent behavior of subprocesses is essential to the optimum process evolution, but can cause major problems if it is not done correctly.Subprocesses must be coupled through their inputs and outputs to reproduce the behavior of the integrated process [8].Thus co-simulation of a process is the sum of the correlated simulations of the coupled subprocesses.
To coordinate the co-simulation, an orchestrator is required to control how components of the model are synchronized, translates and transfers data from subprocess outputs to inputs of other subprocesses, according to an appropriate cosimulation scenario.In our approach, the orchestrator is represented by a categorical sketch whose graph has as nodes the sketches generating the submodels involved and a series of association relations that will implement the interactions between the models.The other components of the sketch will impose submodel coupling conditions.We will call this sketch: the sketch of the co-simulation model or co-simulation sketch.
We will consider a co-simulation sketch =(, , , ), where the graph  has as nodes objects representing sketches of models and as arcs sketch operators.For example, the graph of a sketch with three models could be the one in Fig. 6.This graph already implies several conditions on the cosimulation model, namely: 1) The models of the sketchs s1 and s3 do not interact directly with each other.
2) The models of the sketch s 1 interact directly only with the models from s 2 , and the models from the sketch s 2 interact with those from the sketches s 1 and s 3 .
3) The models from the sketch s 3 can interact with each other.
We can then introduce a set of other restrictions on the cosimulation model through the other components of the cosimulation sketch such as: 4) The models of the sketch s 3 should not contain loops, meaning there are no associations in which the source and targhet coincide.This assumes that the coequalizer of the source and destination functions of the a 33 association is the empty set, i.e. there is no arc in the model for which the destination and source coincide.In categorical terms, the coequalizer of  33 and  33 (Fig. 8) is the colimit of the diagram from Fig. 7, which we denote with K 1 .This colimit will have to become, in the Set category, the empty set, so as in Fig. 3, i.e. the colimit of the void diagram that we denote with K 2 and which becomes the initial object in the Set category.
1) The commutative diagram from Fig. 9, which we denote with D 1 , ensures the connection of model pairs two by two.Commutativity implies  12 ∘ 21 =id 21 ,  21 ∘ 12 =id 12 , meaning that a 12 and a 21 are isomorphic.Similarly, a 23 and a 32 are also isomorphic.
2) Condition 5 does not assure us that there is only one pair of associations between two models.For this we have to put the condition that there is only one arc between any two models.Due to the isomorphism between a 12 and a 21 , it is sufficient to put the condition for one of them.We will put the condition for a 12 .In the metamodel sketch we will have to impose the condition that  12 and  12 be isomorphisms.But,  12 and  12 are epimorphisms if and only if the diagrams from Fig. 12 and Fig. 13 are pushout diagrams, i.e.  12 and  12 are epimorphisms.We denote these two diagrams with K 3 and K 4 .The functions  12 and  12 are monomorphisms if and only if the diagrams in Fig. 10 and Fig. 11 are pullback diagrams, i.e.  12 and  12 are monomorphisms.We denote with L 1 and L 2 these two limits.
For a 23 and a 32 the conditions are similar.So it also includes two more limits that we denote with L 3 and L 4 and two colimits that we denote with K 5 and K 6 .1) The models of the sketch s 3 form a connected graph.This assumes that the equivalence relation induced by the functions  33 and  33 on the set of models generated by the sketch s 3 will determine a single equivalence class on the set of models generated by the sketch s 3 .For this, the diagram from Fig. 14 has to be a pushout diagram.That is, the span colimit determined by  33 and  33 is a terminal object in Set.We will denote with K 7 this diagram.We also need a terminal element from Set that is the limit of an empty diagram that we denote with L 5 .
The graph of the co-simulation sketch is shown in Fig. 15.
A model a co-simulation sketch is a functor M:Set that associates to each node of type sketch from the co-simulation sketch a set of models according to the model sketch corresponding to the node, to each node of type association a set of functions between models and the arcs that are the sketch operators will be interpreted accordingly.Mapping will be done with respect to the restrictions imposed by the components ,  and  of the co-simulation sketch.
The functions corresponding to the association nodes will translate the source model outputs into inputs of the destination model, thus ensuring communication between the models involved in the co-simulation.Each model will therefore respect the conditions imposed by the sketch that generated it and the set of all the models that interact in the co-simulation process will respect the conditions imposed by the co-simulation sketch.
A co-simulation model of the sketch  from the example above could look like the one in Fig. 16 where we have denoted with hourglasses the models of the sketch s 1 , with rectangles the models of the sketch s 2 and with diamonds the models of the sketch s 3 .In this model we have 9 instances, 3 of each sketch.The arcs represented by lines in Fig. 16 are function types, images through the functor M of the association nodes in the co-simulation sketch.From them will create function instances that will do communication between the instances of the models.These functions, which we will call connection functions, map the outputs of a model to the inputs of another model.On the set of connection functions we can introduce the natural composing operation.The resulting construction generates a free category that has as objects the models and as arcs the connection functions.We will call this category: categorical model of co-simulation (CMCS).

V. THE CO-SIMULATION CATEGORY
The categorical model of co-simulation was created.The instances of each co-simulation model have as an interaction support an orchestrater provided by the co-simulation sketch.This sketch is a graphical specification of a co-simulation model provided by the category theory.
Let's see how an instance of the categorical model of cosimulation looks like.In the categorical model of cosimulation, the interaction is achieved through the connection functions.But in the co-simulation process, interaction occurs between models in certain represented states, as described in Section 3, through instance of component models.This means that interaction takes place between process simulation categories (PSC).It is natural that an instance of the categorical model of co-simulation will have to contain as objects process simulation categories (PSC) and as arrows connection functors between these categories that will be instances of the connection functions.
Therefore, an instance of the co-simulation model is a functor :CMCSSet mapping each subprocess model M i , i=1,2,..,n to the process simulation category corresponding to PSC i , i=1,2,..,n, as we saw in section 3, and each connection function f i,j for i,j∈{1,2, .. n} to a connection functor  i,j for i,j∈{1,2, .., n} between the appropriate categories.Obviously, the image of this functor in Set (Fig. 17) can also be structured as a category in which the objects are simulation categories, the arrows are the connection functors and the composition is the composition of the functors.We will name this category the Reactive Category of Co-Simulation (RCCS).
We denote the set of objects ob(PSC i )={ , ,…, ,…} for all i{1,2,..,n} and the arrows between two objects with and with  .A state  k of the co-simulation model is a tuple of the form  k =( , ,…, ) where ob(PSC i ) for all i{1,2,..,n}.
We first consider that processes are parallel and independent.Then there is a macrotransition between two states  k =( , ,…, ) and  l =( , ,…, ) if for every pair of instances , there is a transformation  :  .But the evolutions in the categories of cosimulation processes are not independent, some macrotransitions are independent and may evolve as above, other instances wait for rendezvous with instances of other subprocesses for information exchange that require synchronization [13,15].
For each process simulation category PSC i ,i=1,2,..n we will construct a subcategory that we call the rendezvous category of the process RCP i ,i=1,2,..n as follows: ob(RCP i )={ ob(PSC i ) |  j so that the execution of the transformation  depends on a rendezvous} and the arrows remain all from the PSC i category which have the domains and codomains in ob(RCP i ).
In this way, an instance of the co-simulation model becomes a functor :CMCSSet that maps each subprocess model M i , i=1,2,..,n to the rendezvous category of the process RCP i , i=1,2,..,n, and each connection function f p,q for p,q∈{1,2, .. n} to a connection functor  p,q :RCP p  RCP q for p,q∈{1,2, .., n} between the rendezvous categories of process as follows:  p,q ( = if and only if the instance needs as inputs the outputs of the instance to be able to evolve.Defining  p,q on arrows is implicit.Obviously, each resulting structure RCP i , i=1,2,..,n is a category.We will call this category the category of co-simulation (CCS). For each pair p and q there is a transformation from  p,q ( to in the RCP q category if and only if there is a transformation from to  q,p ( ) in the RCP p category.
Condition ii) is necessary to avoid the deadlook situation in the co-simulation flow, i.e. a state in which each member of the tuple waits for another member to send its outputs to an instance that is not in the tuple or to receive inputs from another instance that is not in the tuple.Of course, each instance can execute the identity transformation for a number of steps but not for infinite without the process evolving.The condition ii) ensures that all instances will have the rendezvous they are waiting for, and there will be no deadlook.But obeying this condition is related to the definition of functors  p,q for p,q{1,2,..,n}.For this, the functors  p,q and  q,p should be adjunct functors.
The functor  p,q :RCP p  RCP q is the left adjunct of the functor  q,p : RCP q  RCP p and  q,p is the right adjunct of  p,p and is denoted by  p,q ⊣  q,p if and only if the set of arrows Hom( p,q -, -) and Hom(-, q,p -) are naturally isomorphic as functors of two variables with values in Set.We denoted withthe place of a variable in the formula [9].This means, in our case, that for each pair p and q there is a transformation from  p,q ( to in the RCP q category if and only if there is a transformation from to  q,p ( ) in the RCP p category, i.e. exactly the condition ii) from above.
But the two functors are adjuncts [9,10] if there is a natural transformation  p : id p   p,q ○ q,p , where id p is the identity functor in the RCP p category and  p is the adjunct unit, so for any objects from RCP p and from RCP q and any arrow  :   q,p ( )= , there is a unique arrow  :  p,q ( ) =  so that the diagram in Fig. 18 commutes.
We also have the dual characterization that if two functors  p,q and  q,p have the property  p,q ⊣  q,p then there is a natural transformation  q :  p,q ○ q,p  id q called adjunct counity so that for any arrow  :  p,q ( )=  , there is a unique arrow  :   q,p ( )= so that the diagram in Fig. 19 commutes.
Therefore, if the natural transformations  p or  q exists with the above properties, the two functors are adjuncts.The natural transformation  p provides a way to associate each arrow  :  = from the RCP p category with an arrow  : p,q ( )=  from the RCP q category so that  = q,p ( )  p .
In our case, the natural transformation  p :id p  p,q  q,p can be constructed taking into account the way the categories RCP i i{1,2,..,n} have been defined as subcategories of the process simulation categories PSC i ,i{1,2,..,n} in section 3. From this it follows that each Hom( , ) contains a natural transformation  for all k0.We will define every component  :  p,q  q,p ( )= as follows: for each x we define  (x)=  ( (z)) = (z) where z ; x= (z) and  Hom( , );  Hom( , ).It is quite simple to prove that  p defined as such respects the naturality property and thus is a natural transformation.We observe that the component  of the natural transformation  p exists if and only if the number of elements from is greater or equal to the number of elements in .Similarly, the natural transformation  q : p,q ○ q,p id q can be constructed in the RCP q category.If the natural transformations  and  exist for all k≥0 then the two functors  p,q and  q,p are the adjuncts and the condition ii) is fulfilled.Otherwise we will have to try all the variants admitted by the model in question to define the functors  p,q and  q,p to obtain two adjunct functors.If there is no such option we will have to make changes at the model level.In principle, it should be observed that for each object from the RCP p category, the functor Hom( , q,p -):RCP q Set has a universal element [9].But we will deal with this problem in a future paper.

VI. CONCLUSION
Multi-formalism modeling aims to facilitate the use of more modeling formalisms in certain situations where it is necessary to compose heterogeneous models, thus allowing experts from different disciplines to collaborate more effectively in the development of increasingly complex systems.This approach involves specifying processes through different modeling grammars.
Many times the solution to this challenge is the development of grammars specific to the component subprocesses starting from a common meta-metamodel that facilitates their coupling in a co-simulation process that allows the study of the overall system behavior.There is a gap of remarkable results in the field of modular coupling, of simulators in dynamic structure scenarios at the state level [2].The concept of categorical modeling method along with the MM-DSL [3,4,5,6,7] language facilitates this approach.The present paper proposes a co-simulation category (CCS) as a model for the co-simulation state space.The categorical sketch for co-simulation can be specified in a graphical language provided by the category theory for specifying the syntax of the co-simulation model.This facilitates the separation of the model specification from the execution algorithms.Universal constructs offered by the category theory can be implemented as universal algorithms and mechanisms [6,7] at the meta-metamodel level and used in each model for process coupling.This type of algorithms reduce the complexity of syntax specification for coupling and provides support for domain specific modeling and distributed execution.Thus, the universal constructs from the category theory can be seen as a collection of tools for specifying and structuring the dynamic coupling of processes.
Synchronization can be elegantly modeled by adjunct functors.Composition of adjuncts is also an adjunct [9].We have seen in section 5 the determination of the adjunct unit, if it exist it can be relatively simple.We will have to find general criteria for characterizing the situations in which these adjuncts exist.This problem as well as the problem of finding practical and efficient algorithms for determining synchronization adjuncts will be addressed in a future paper.
has to become a pullback diagram in the Set category.Analogously, the arrow  o becomes a surjective function if the pushout of  o with  o is equal to  o , i.e. the diagram from Fig. 4 becomes a pushout diagram is the Set category.And the arrow  o becomes an injective function if the pullback of  o with  o will be equal to x o , i.e. the diagram from Fig. 5 will become a pullback diagram in the Set category.

Fig. 6 .
Fig. 6.The Graph of a Sketch with Three Models.
is the identity.In the simulation process this means that is waiting for a rendezvous.