Mapping and Model Transformation

A set of mappings between models from different abstraction levels are established in Figure 2. These mappings can also be defined between models belonging to the same level. Below are some of the possible transformations:

• Mapping PIM to PIM. It is applied in order to optimize them for the duration of the development process. This mapping does not require any information on the implementation platform.
• Mapping PIM to PSM. It is applied in cases where it has a PIM resulting from a series of refinements of PIM to PIM. This mapping will be implemented in a dependent architecture of a specific platform.
• Mapping from PSM to PSM. It is applied during the encoding and component development. This mapping is linked to the refinement of PSM own models.
• Mapping from PSM to PIM. This transformation may be required to generate abstract models from existing implementations. It can be used in order to extract into generic models, desirable properties of a system.
• Mapping from PSM to code. Enables the generation of specific source code to a particular platform from a PSM.

The languages most commonly used to describe model-to-model transformations are QVT and ATL (Atlas Transformation Language) [44]. In the present work we opted for QVT-R (QVT-Relations) for its simplicity and clarity to define relationships between elements of the source and target metamodels.

Query/View/Transformation (QVT) The OMG defined the QVT standard [17] to work with software models. QVT consists of three parts: query, view and transformation. In particular, a transformation metamodel describes relationships between a source metamodel S, and a target metamodel T, specified in MOF [45]. The QVT specification 1.1 has a declarative/imperative hybrid nature. In this work the Relations declarative language is employed. The tool used for the definition of the transformations is called MediniQVT [46]. This tool implements the OMG QVT-R specification into a powerful engine QVT. Its interface is based on Eclipse, and use Eclipse Modeling Framework (EMF) [47] for representing models. MediniQVT requires that metamodels (and models) be written in a simplified version of the MOF standard, called Ecore [48], which is defined in the EMF. An Ecore metamodel is represented in XML; however has an EMF Ecore models graphic editor which facilitates the creation thereof.

Ecore and Ecplispe Modeling Framework Characteristics The metamodels and EMF models used are represented by XML documents; EMF has a graphical editor which facilitates the creation of Ecore models. There are tools that automatically treat these metamodels and models, including the Eclipse plug-in to transform these models, with the definition of QVT transformations. The features and elements of the modeling language Ecore are: the unifying element (root) is the package EPackage, which physically contains its elements (containment specification) and, in turn, these may be contained in other packages. There is a factory (EFactory) per package that allows the creation of model elements. Constructs that describe a set of elements (instances) are classifiers (EClassifiers): EClass and eDataType. Ecore specifies the characteristics of the classes (EClass), their structural characteristics (EStructuralFeatures), attributes (EAttributes), operations and relationships (inheritance, reference (EReference)). The EClass have a superclass and is composed of structural features (EStructuralFeatures: EReference and EAttribute). Both EAttributes and EReferences may be provided with multiplicity. The EDataTypes model basic or indivisible data model types, and the EReferences may be contained or be references (pointers). The Operations model the operations of the interface (although implementation is not provided for them). All elements inherit from ENamedElement (nameless) and EModelElement (model element). Moreover, every element of the model can have associated annotations (EAnnotation): name / value pairs for additional specifications; eg, OCL constraints or documentation strings.

3.2 State Machines

A SC is a visual representation of a finite state automata with hierarchy of states. These machines were introduced by Harel [16] and incorporated into the various versions of UML with some variations. The main feature of the SCs is that their states can be refined, thus defining a hierarchy of states. The decomposition of a state can be sequential or parallel, in the first, a state decomposes into an automaton, while in the second it breaks down into two or more automata running concurrently. Although this hierarchy is allowed, a SC with composite states has its equivalent using only simple statements. In this paper, we will rely on the definition and application of SCs containing only simple statements. There are many algorithms and tools that convert a SC with composite states to an equivalent SC with simple states [16, 49, 50]. Transitions are directed. A transition (t) is formed by its name, origin state, the event that “triggers” it (e), the trigger condition (c), the actions to be executed ([alpha]) and destination state. The graphical notation used is .

3.3 M&S and DEVS

A model is a representation of the construction and working of some system of interest. A model is similar to but simpler than the system it represents. One purpose of a model is to enable the analyst to predict the effect of changes to the system. On the one hand, a model should be a close approximation to the real system and incorporate most of its salient features. On the other hand, it should not be so complex that it is impossible to understand and experiment with it. Generally, a model intended for a simulation study is a mathematical model developed with the help of simulation software. Mathematical model classifications include deterministic (input and output variables are fixed values) or stochastic (at least one of the input or output variables is probabilistic); static (time is not taken into account) or dynamic (time-varying interactions among variables are taken into account). Typically, simulation models are stochastic and dynamic.

Simulation is a descriptive tool, allowing us to experiment with a model instead of the real system. The propose of simulating, generally falls into one of three categories as follows:

• Comparison. A comparison of simulation runs can be used to assess the effect of changing a decision variable. The results of the different runs can then be evaluated in terms of the objetives.
• Prediction. A simulation may be used for predictive proposes to determine the state of the system at some future point in time, subject to assumptions about how it behaves now and how it will continue to behave.
• Investigation. Some simulations are developed to provide an insight into the behavior of the system, rather than to perform detailed experimentation. It is of interest to see how the simulation behaves and reacts to normal and abnormal stimuli.

Simulation is used before an existing system is altered or a new system built, to reduce the chances of failure to meet specifications, to eliminate unforeseen bottlenecks, to prevent under or over-utilization of resources, and to optimize system performance.

During the last decades, the rapid evolution of technology has produced a proliferation of new dynamical systems of great complexity. Examples include computer networks, automated production systems, air traffic control, and general systems of command, control, communications and information. All the activities in these systems are due to the occurrence of asynchronous discrete events, some controlled (such as pressing a key) and some not (like spontaneous equipment failure). This feature is what leads to define the term: Discrete Event Systems (Discrete-Event Systems - DES) [51]. Among the most popular formalisms for representation of DES are Petri Nets, the SC, Grafcet, Event Graphs, and many generalizations and particularizations of them.

With the motivation of problem-oriented modeling and simulation of DES, in the decade of the ’70 Bernard Zeigler proposed a theoretical framework and a methodology for M&S systems. It is here that arises DEVS [10], a formalism for modeling with a solid semantic, based on a theoretical system basis. This formalism, sometimes pointed as universal, allows to describe dynamic discrete event systems. Its universality means that any formalism for these systems can be adjusted to DEVS. Because of its great adaptation for modeling complex systems and the simplicity and efficiency of the implementation of simulations, DEVS is currently one of the most used tools in modeling and simulation by mean of discrete events. In Section 4.2 the details of the formalism are presented.

4 From State Machines to DEVS Models

The main objective of this work is to provide a mechanism that achieves the execution of UML SCs, through a process that transform them to DEVS atomic models, to later be able of carrying simulations on them. To build this process of transformation is necessary to make a review of the elements of each formalisms. Subsequently, a mapping between them through a set of rules that indicate how information from one domain translates to another is defined. These rules are especially needed because although the domain elements of a SC has similar aspects from the DEVS ones, the specification of DEVS elements is more stringent.

4.1 Formal Definition of a SC

The UML SCs are based on the SCs defined by Harel. They are composed by a set of states, transitions and events. Formally, following [52], a SC is defined as a tuple , where:

•  : is a finite (non-empty) set of states.
•  : is a finite set of events.
• is a finite set of transitions represented by the tuple , where:
  • is the transition name;
  • is the origin state;
  • is the trigger event;
  • is a trigger condition;
  • A is an action to be executed when the transition occurs;
  • is the destination state.
• : is a set of actions, where represents the “null action” or “skip”.

For convenience, a life time (or residence time) can be associated to a state. These are used to describe a new behavior, that defines for how long the system can remain in a state. When time has elapsed, a special transition must be triggered. This behavior could also be implemented by associating a time event to a transition, which fires when the origin state reaches that time. On one hand, the association of time to each state is formalized, and secondly, a special event called time event to be used in transitions that are triggered upon reaching the time in his origin state. We refer to these transitions as time transitions. Only one time transition must be defined by each state, and the life time must be not equal to .

The SC formal definition is extended with the following components: , where:

• is a set of pairs that associates with each state a value in , that represents the life time.
• is the time event.
• Si then there must be a unique time transition with origin .

Figure 6 shows an example of a SC. Note that the transitions are triggered when the life time runs out in their origin state (time transition) are drawn simply by associating the life time of their origin state and action output; the event (event time ) and condition () are not drawn.

4.2 Definition of DEVS Formalism

A classic DEVS atomic model is defined as a tuple , where:

• is the set of input events (possibly ).
• is the set of output events (possibly ).
• is the set of states (possibly ).
• is the external transition function which defines how an input event changes a state of the system, where: is the set of total states, and theis the elapsed time since the last event.
• is the internal transition function which defines how a state of the system changes internally (when the elapsed time reaches to the lifetime of the state).
• is the output function. This function defines how a state of the system generates an output event (when the elapsed time reaches to the lifetime of the state).
• is the time advance function which is used to determine the lifespan of a state.

A system that is in a state will remain in it for a period of time, unless an input event with value occurs, after a time lower or equal to elapses. In this case, the system will experience an external transition to the state . However, if the elapsed time is equal to without external events have taken place, an internal event will occur leading to an internal transition. This will produce an output event with value and a transition to a new state . In both cases, the system will remain in the new state, by the time determined or until an external event occurs again.

Note that in the definition of DEVS filed, the time advance function supports associating a time or to a state . In the first case, the system may remain units of time in . Therefore, when is reached, an internal transition happen immediately generating an output event and a state change. Such a state is called transitory state. Moreover, when the system reaches s whose associated time is , no internal transitions will exist and will remain forever in this state unless an external event occurs. Such a state is called passive.

4.3 Element Mapping

Model transformations are defined as programs that take a model (or more than one) as input and returns another model (or more than one) as output.Consist of a set of rules describing how one or more source model elements are transformed into one or more elements of the target model. Below is formally defined the set of rules that describe how the elements of the source model are transformed into elements of the target model by extracting the necessary information from a SC to build a DEVS atomic model.

Given ME = a SC, and MA = a DEVS atomic model, the transformation rules are defined as follows:

1.

Rule 1: states from and their life time are transformed DEVS states, where: . On the other hand, the function is defined as: .

2.

Rule 2: an event is transformed into a DEVS input event with the same name; .

3.

Rule 3: an action is transformed into a DEVS output event with the same name; .

4.

Rule 4: to define the transitions mapping is necessary to distinguish particular cases, as in ME all the information is contained in the tuple that defines the transition, while on a DEVS model it is specified in various elements of the atomic model. This classification is to distinguish transitions according to their trigger (event time and the rest), and according to a certain action or null action attached to it.

• Rule 4.1: a transition that is triggered by the occurrence of a time event (), is transformed into an internal transition in MA.

  Given :

  , and

• Rule 4.2: a transition that is triggered by the occurrence of an event and contains the null action , it is transformed into an external transition in MA.

  Given , where :
  else 

• Rule 4.3: a transition that is triggered by the occurrence of an event and contains a non-null action , produce the following elements in MA.

  Given , where , and :

  (a)

  it is defined an intermediate state with life time 0, in order to produce as output of the model MA, the action : ;

  (b)

  an external transition from to : ;

  (c)

  an internal transition from to : ;

  (d)

  an element from the output function that maps to the output event (action) : .

5 Implementing the Transformation with QVT and Exporting to PowerDEVS

In this section an implementation of the transformation rules from UML statecharts to DEVS atomic models based on the QVT-R language is proposed. Subsequently, the exporting method of the resulting model is described, so that it can be interpreted by PowerDEVS.

A set of QVT relations that implement the rules detailed in Section 4.3 is defined. We make use of the UML 2.4.1 metamodel described in the official website of the OMG [8]. In function of this specification, the UML elements that are used to support the formalism of the SCs defined in 4.1 are described. Later, the DEVS formalism metamodel presented in Section 4.2, is defined in Ecore format.

An execution of rules in QVT receives a model (or instance) of a UML SC satisfies the UML metamodel in Ecore [47], and builds a DEVS atomic model that satisfies the respective metamodel in Ecore format.

Table 1 reflects briefly which UML elements are used to model the SCs defined in Section 4.1.

---

Table 1: Mapping between SC elements (formal definition) and UML 2.4.1 elements

---

DEVS Metamodel

The DEVS metamodel definition is based on the specification described in Section 4.2 and is built with the MediniQVT tool. Note that each element of the tuple that defines the DEVS models is defined by a metaclass. Figure 3 shows graphically that metamodel. Briefly, Table 2 describes the relationship between the elements from the formal definition of an DEVS atomic model and elements of the Ecore metamodel.

---

Table 2: Mapping between DEVS atomic model elements (formal definition) and its representation in Ecore

---

5.1 Transformation Rules in QTV-R

The definition of relationships (rules) in QVT-R implement the rules specified in 4.3. These transformation rules are written declaratively and describe consistent relationships between the set of elements of each model. This consistency can be verified by running the transformation in checkonly mode (read-only), with a satisfactory result if both models are consistent according to the relations. Similarly, it can be executed in enforce mode to modify or build one of the models, so that both satisfy the relations at the end of the execution. In this paper, QVT relationships are built by checking the UML model, and enforcing the DEVS one, thus the elements of first maps to elements of the second.

For space reasons, the relevant parts of the code relationships are shown. In particular, only the construction of states, input events and partly the construction of internal and external transitions from the DEVS atomic model are shown. In https://www.dropbox.com/sh/4e0zorfyvgdmdg3/dnfWO_ija9 it is possible to download the full definition of the rules. Note that a rule defined in Section 4.3 may be implemented by more than one relationship in QVT-R.

The relationship state2state builds the DEVS model states according to the following mapping: the name of the DEVS state corresponds to the name that has in the UML model and its lifetime specified on the UML (Constraint) time constraint.

The UML events SignalEvent are mapped to InputEvent elements of the DEVS metamodel. This is defined by the relationship signalEvent2inputEvent.

A UML transition that is triggered by the ocurrence of an external event and contains an action attached to it, creates various elements of the resulting DEVS atomic model, according to the last rule defined in Section 4.3.

5.2 Exporting to PowerDEVS

The DEVS model resulting from the transformation can be exported to various tools to perform simulations; among others, PowerDevs, DEVSJAVA [43], DEVS-C++ [53], DEVSim++ [54], CD++ [55], and JDEVS [56]. These software tools provide different features, which include graphical interfaces and advanced simulation functionalities for general purpose and domain-specific DEVS models. In this paper we have chosen PowerDEVS, being an open source tool and easy to use to implement these models; moreover, it has versions for both Windows and Linux and is widely used in academia for teaching M&S.

PowerDEVS is implemented in C++ (with QT graphics libraries) and DEVS models must also be defined in C++. It consists of several separate programs:

• Model Editor: contains the graphical interface that allows, among other high-level definitions, the hierarchical construction of the structure of DEVS (files .pdm) models, which have a special syntax.
• Atomic Editor: allows to define in C ++ (.h and .cpp files) the behavior of the DEVS atomic models, i.e. transition functions, the output function, lifetime, and other elements of these models.
• Preprocessor: translates files from the Model Editor in structures with information necessary to build the simulation code, and links files created with the Atomic Editor compiling a stand-alone executable file.
• Simulation Interface: runs the stand-alone executables, allowing to vary the parameters of the simulation.
• An instance of a Scilab execution where the simulation parameters are read and the results can be exported.

The export of a DEVS atomic model in Ecore produce, first, a file (.pdm) that defines the structure of the model and can be opened by the Model Editor, and secondly, the files that define the behavior (.h and .cpp) so that they can be interpreted by the Atomic Model. The algorithm that generates the code (XEP: XML Ecore to PowerDEVS) was implemented by the authors of the current work and is based on the Saxon XSLT library and the XQuery Processor [57], which is a collection of tools for processing XML documents.

The export process described is shown in Figure 4. In Section 7 two examples of application can be observed.

6 Validation of the Transformation

To validate the application of existing theories and tools about the DEVS models, we need to construct DEVS models from UML SCs models with equivalent behaviors.

In previous sections, we define the transformation by a systematic method and then develop their implementation, but these mechanisms need to be validated in order to increase the credibility of the results.

The validation of a model transformation typically includes properties which involve the syntactic correction of the transformation with respect to its specification language and syntactic correction of models produced by the transformation [58, 59], but few proposals focus on the semantic consistency of the transformation, i.e. the preservation of the correction of the target model in relation to the origin model. In order to do this we can apply both empirical and theoretical (formal) validation methods.

6.1 Empirical Validation

In the context of MDD, software development is based on the refinement of models until they become codes. An example of this is the theory of refinement of Dijkstra [60], widely applied in the area of formal methods. However, it is difficult to adapt the theory to the validation of the model transformation. [61] describes an agile formal proposal for semantic validation specifying the structures of refinement with OCL which are equivalent to those employed in the formal languages. This proposal has the support of the software engineering community, due to the fact that it uses known languages. Generally, refinement is verified by demonstrating that the actual system simulates the abstract system.

This paper does not specifically propose a refinement, it aims to obtain an equivalent or more general model in the context of simulation systems, in order to take advantage of existing analysis tools. The model validation mechanisms in the field of M&S are clearly suited to our proposal. The model validation methods try to show that the models actually represent the actual system which is one of the most important and difficult tasks faced by a modeler. Therefore, assuming that the validation of the state machine was made, in our proposal, empirical validation of the transformation is limited to the validation of the DEVS model, that is, to determine that the new model resulting from the transformation also models the real system. This is represented in Figure 5.

The modeler should work closely with end users during periods of model development and validation in order to increase the credibility of the model. We can find various model validation strategies in the current literature [62] [63] but the main goals of the validation process are common to all:

• To produce a model that represents a real system behavior, real enough to use it instead of the original system in experimentation and analysis.
• To raise the credibility of the model to an acceptable level so that it is used by those responsible for making decisions.

In the validation process it is important:

• To examine at the model outputs and determine its acceptability, under a variety of configurations of the input parameters. To make this model present a wide variety of statistical results, which should be examined carefully.
• To make the model print the input parameters while analyzing the simulation and verify that their values have not been changed.
• To document the model as much as possible.
• If the operational model is animated, to verify by means of the observation of the simulation that the model imitates the real system.
• To monitor the simulation: tracking specific entities, monitoring of the component values, etc.
• To review the acceptability of the model outputs in detail.
• To calculate certain measures of long-term performance analytically, if possible, and then compare these results with the values that the system provides. his is very important in validating models.
• To use both the real system and the model, the same sets of input data to compare the outputs.

6.2 Proposal for Theoretical Validation

Recent studies describe validation and verification techniques of model transformations. In [64], the idea is to convert a model transformation system into a relational logic specification. The Alloy model analyzer is used to check if any invalid target model is created by the transformation. Other strategies achieve the correction of the transformation by means of the correct-by-construction using transformation patterns [65] or using ontologies [66].

In the context of state transition systems there are simulation and/or bisimulation techniques [67, 39] that could be applied in this work. These techniques attempt to formally prove that a state transition system includes the behavior of another, and vice versa. In our proposal we must demonstrate, in particular, that the behavior of the resulting DEVS model preserves the behavior of the SC, in other words, that the DEVS models behave like the SCs.

A simulation is a binary relation between two systems associated state transition systems where the behavior of one includes the other. A bisimulation is a binary relation between two systems of state transition, which combines systems that behave in the same way. This means, a system simulates another system and vicerversa.

In this work the SCs and DEVS models are state transition systems including time constraints (TLTS). Considering [67], a timed simulation is a binary relation over a set of states of a TLTS defined as follows:

Where is an external event or permanence time associated with a state.

Two TLTSs are said to be bisimilar iff there exists a bisimulation between their state spaces.

In a TLTS the eventual transition relation defines a transition from state to state that may contain one or more direct transitions labeled. The eventual transition relation () between and on () is defined as follows:

iff there is an eventual transition relation from to (with or , which is composed of one or more direct transitions. This represents the following sequence of transitions: , proved that the only transition output is an even transition time with delay zero, where defines zero or more occurrences of transition .

Weak timed bisimulation

A weak timed simulation [67] is a binary relation over a set of states of a TLTS. If we have states and , is a weak timed simulation iff: if , then there is a transition .

We choose the weak bisimulation relation to validate the transformation from SCs to DEVS, as this relation allows two models to be in simulation relation even with if one of them has some different transitions from the other, provided that these extra transitions are time transition with delay zero.

Preservation of semantics

Given ME = a UML SC, and MA = the DEVS atomic model resulting of the transformation. If we define as: where and according to rule 1 defined in section 4.3, then is a weak timed bisimulation, which means that MA simulates ME.

Demonstration and a more detailed analysis of the proposal will be considered in the future.

7 Aplication Examples

Two examples are presented in this paper. The first case study shows the simplified operation of an Automatic Banking Machine (ABM). The purpose of this one is to give a general view of the mapping from a UML SC to a DEVS model, showing formal and graphical representations. The second example models the behavior of a control system of an elevator, in order to estimate certain performance variables, such as the average time of movement of each order, utilization factor, etc., or even plot the trajectory. Current available simulation tools for UML SCs do not provide adequate libraries to estimate these variables. This fact has motivated the development of the current work.

Simulations are developed to analyze complex systems. In this first version, the case studies allow the reader to understand the approach proposed in this paper to analyze dynamic systems from a UML diagram state machines. In future extensions contemplate complex systems in order to discover improvements in systems based on analysis by the DEVS simulation models. In Section 7.2, which corresponds to the example of elevator, we describe possible extensions to the case study.

7.1 Automatic Banking Machine (ABM)

The example shows the simplified operation of an ABM, a machine that allow a user to select different types of banking transactions by exchanging data through a magnetic card. In addition, the machine has mechanisms to diagnose failures and provide information to maintenance personnel to perform repairs. Due to space limitations, described below are only the most relevant ABM behaviors. It is considered that the ABM starts off and, once connected to the electrical power supply, a pre-launch automatic test begins, which lasts about 10 seconds. In case of failure the machine goes out of service, otherwise it will be ready for online banking (idle). When the user enters their card, he must authenticate his login with a password or PIN. If the authentication fails, after 30 seconds the ABM goes idle again, ejecting the card entered; otherwise presents an options menu to start a transaction. After the transaction the user decides to make, the user can return to the menu or exit the system. In case of failure, the ABM has a process of diagnosis and repair that maintenance staff is responsible for configuring and executing. This procedure can be performed when the ABM is idle or out of service.

Figure 6 ilustrates the SC of the ABM using the graphical representation of UML 2.4.1.

The formal specification of the ABM SC is as follows: (Sc_Cab) = , where:

:{Off, Try, Out of Service, Idle, Maintenance, Authentication, Menu, Transaction} ;

:{ButtonOn, ButtonOff, ButtonExit, Ok, ButtonMenu, InsertedCard, OptionSelect, Failure, Repair, Mant-OK} ;

:{(OffTry, Off, ButtonOn, true, TurnOn, Try), (TryOut Of Service, Failure, true, , Out Of Service), (IdleOff, Idle, ButtonOff, true, TurnOff, Off), (IdleAuthentication, Idle, InsertedCard, true, , Authentication), (Authentication Idle, Authentication, , true, , Idle), (TryIdle, Try, , true, , Idle), (IdleMaintenance, Idle, Repair, true, , Maintenance), (MaintenanceOut of Service, Maintenance, Failure, true, , Out of Service), (MaintenanceTry, Maintenance, Mant-OK , true, , Try), (Out of ServiceMaintenance, Out of Service, Repair, true, , Maintenance), (Authentication Menu, Authentication, Ok, true, RegisterUser, Menu), (MenuIdle, Menu, ButtonExit, true, EjectCard, Idle), (MenuTransaction, Menu, OptionSelected, true, , Transaction), (TransactionMenu, Transaction, ButtonMenu, true,, Menu), (Transaction Out of Service, Transaction, Failure, true,, Out of Service), (Transaction Idle, Transaction, ButtonExit, true, EjectCard, Idle) } ;

:{TurnOff, TurnOn, EjectCard, RegisterUser} ;

:{(Off, ), (Try, 10), (Out of Service, ), (Idle, ), (Maintenance, ), (Authentication, 30), (Menu, ), (Transaction, )} .

From UML ABM to DEVS ABM

The execution of the transformation rules in QVT-R takes as argument the ABM UML model in Ecore format and creates a DEVS atomic model. Figure 7 shows a diagram of the resulting DEVS atomic model. Although DEVS models do not have a standardized graphical notation, because the sets may have infinite cardinality, in this case it is possible to plot the model because the number of processed elements is finite. By convention, internal transitions are drawn with dotted lines and the output function is represented implicitly on internal transitions specifying the output as a function of the source state, for example, !EjectCard. The other elements are intuitive in the diagram.

Note that the transformation of the transitions that are triggered by the occurrence of external events, and that have actions as output, generate an intermediate state with life time , to produce immediate output action. For example, the transition going from state Off to state Try produces the intermediate state Off-Try; when this is reached an internal transition is triggered immediately (because the lifetime is zero) that changes the the ABM to the state Try, and also, launches out the action !TurnOn ((Off-Try) = TurnOn).

The formal specification of the resulting DEVS ABM atomic model (Devs_Cab) is as follows:

Devs_Cab = , where:

:{ButtonOff, ButtonExit, Ok, ButtonMenu, InsertedCard, OptionSelect, ButtonOn, Failure, Repair, Off-Try, Idle-Off, Authentication-Menu, Menu-Idle,Transaction-Idle}

:{TurnOff, EjectCard, RegisterUser, TurnOn}

:{(d, ) d {Off, Try, Out of Service, Idle, Maintenance, Authentication, Menu, Transformation} }

The external transitions are:

(((Off, ), t), ?ButtonOn) = (Off-Try, 0)

(((Try, ), t), ?Failure) = (Out of Service, )

(((Out of Service, ), t), ?Repair) = (Maintenance, )

(((Maintenance, ), t), ?Failure) = (Out of Service, )

(((Idle, ), t), ?Repair) = (Maintenance, )

(((Idle, ), t), ?ButtonOff) = (Idle-Off, 0)

(((Idle, ), t), ?InsertedCard) = (Authentication, 30)

(((Authentication, ), t), ?Ok) = (Authentication-Menu, 0)

(((Menu, ), t), ?ButtonExit) = (Menu-Idle, 0)

(((Menu, ), t), ?OptionSelect) = (Transaction, )

(((Transaction, ), t), ?ButtonMenu) = (Menu, )

(((Transaction, ), t), ?Failure) = (Out of Service, )

(((Transaction, ), t), ?ButtonExit) = (Transaction-Idle, 0)

The internal transition are:

(Off-Try, ) = (Try, 10)

(Try, ) = (Idle, )

(Idle-Off, ) = (Off, )

(Authentication, ) = (Idle, )

(Authentication-Menu, ) = (Menu, )

(Menu-Idle, ) = (Idle, )

(Transaction-Idle, ) = (Idle, )

The output function is defined as:

(Off-Try, ) = !TurnOn

(Idle-Off, ) = !TurnOff

(Authentication-Menu, ) = !RegisterUser

(Menu-Idle, ) = !EjectCard

(Transaction-Idle, ) = !EjectCard

From DEVS ABM in Ecore to PowerDEVS

The DEVS ABM atomic model in Ecore resulting from the transformation, it is translated into C++ code by the XEP algorithm developed by the authors in order to be interpreted and simulated by PowerDEVS. According to the description in Section 5.2, the files that define the structure (.pdm) and behavior (.h, .cpp) of the model are generated. The following code shows the ABM.pdm generated file:

The C++ code corresponding to the generated header file ABM.h is displayed below:

Finally, below are shown just the relevant parts of the generated C++ code corresponding to the behavior of the DEVS ABM in Ecore (CAB.cpp):

7.2 Control System of an Elevator

Consider a simple elevator that can be commanded by the events up and down. Each level of the building has a sensor that indicates the presence of the elevator, so that the output of the “system elevator” are the events produced by these sensors. The elevator goes up and down at constants speeds of 1 meter per second, the distance between one level and another is 2 meters and the building has 4 levels.

The elevator is commanded by a controller that receives events indicating the current level of the elevator. Whenever an event arrives, verifies if the elevator should continue going up or down. Upon reaching the target level, it doesn’t send any other signal to the elevator, making it to remain at the current level.

A possible extension to the problem is to attach a generator to the controller which generates the elevator destinations as Go to level i. Each time the controller sends a Free signal, the generator, after a short time (delay), must determine the new level to which the elevator should be directed. Collected data indicates that delays follows an exponential probability distribution with mean 4 seconds, and destination levels have equal probability of being selected.

It is of interest in this problem to get, through simulations, graphics of the elevator trajectory and know its utilization factor(usage time / total time). Future extensions may include the management of a queue of orders to the elevator and assess, for example, the average waiting time of orders (time between the occurrence of the order and the beginning of the movement towards the target); and even composing this operations to form a system of several elevators.

For clarity, we model the problem by designing three UML state machines: i) SC UML for the elevator, ii) SC UML for the controller, and iii) SC UML for the generator. Figure 8 and Figure 9 ilustrate the SCs of the elevator and controller respectively, using the graphical representation of UML 2.4.1.

After applying the transformation rules presented in Section 5.1, the resulting DEVS models in Ecore format are shown in Figure 10 and Figure 11. Then, through the algorithm XEP, C++ code is generated corresponding to PowerDEVS models (.pdm, .h and .cpp files) to be handled by this tool. We call PowerDEVS models to models that satisfy the metamodel of Figure 3.

Simulation tools, particularly PowerDEVS, contain a lot of libraries that help enrich the models to be analyzed and discover properties about them. In the present example, as an initial step, the generated models of the generator, controller and elevator are connected, and later, PowerDEVS libraries (StochasticLib1.h) are used to plot and generate samples of, an exponential distribution for the delays, and a uniform distribution for the building leves, as can be seen in Figure 12. The StochasticLib1.h library implements the generation of samples of a variety of probability distributions commonly used in discrete event simulation models.

After several runs of the system and using the technique of confidence interval for the outputs it was established that on average the utilization factor of the elevator is 0,34 (34%) and their confidence limits are . Likewise, analyzing the graphics and records (log files) determines that the elevator moves on average levels for each order, this corresponds to 2.64 sec. This measurement makes more sense in a possible extension of the case study, for example, considering waiting lines with different policies (disciplines) and multiple elevators working together. In this case, if the discipline of the queues changes, the amount of movement of the elevators will be modified. It is difficult to analyze this with current available execution tools for UML SCs.

8 Conclusion and Future Work

MDD is an approach with the potential to make development more efficient and obtain more reliable results, since, among other things, it enables the verification of systems in early stages of development offering greater control. Many of MDD techniques use UML, incorporated as a de facto standard language in academic and industrial areas, which allows the description of many aspects of a system. In particular, UML statecharts provide a mechanism to specify the behavior of systems using a graphical representation. These diagrams are compact, expressive and provide the ability to model not only simple but also complex reactive systems. Multiple tools support the latest versions of UML, which generally provide graphical features that facilitate the modeling of systems. However, they lack the ability to execute and simulate dynamic models. This limits the analysis of the behavior of systems in real scenarios. DEVS is founded on the principles of systems theory and its development through component-based engineering. With the advances of UML in recent years, the community around DEVS has devoted efforts to define a mapping between UML and DEVS elements. It is known that DEVS is more rigorous and expressive than UML, but due to the manipulation of potentially infinite sets which a model can contain, it lacks a graphical notation which is required by industry professionals. The combination of graphic virtues of UML with the powerful simulation tools of DEVS models led to the current proposal. Some research groups have addressed various proposals for this important relation between DEVS and UML, but none has a formal solution or an implementation based on the definition of metamodels using standards.

This work presents a mechanism for closing the gap between two formalisms with different tools and technologies, different theoretical bases, but united by a common purpose, which is to provide solutions to real problems through the creation and analysis of abstract models. A process of model transformation that maps elements from UML SCs to elements of DEVS models is defined. This is achieved by exploiting the graphic qualities of one, the specificity and rigor of the other, resulting in a simulation model that can be executed and analyzed by a large number of specific tools. The transformation was defined as a set of rules by cases and was implemented using QVT-R, a language standardized by the OMG. The UML 2.4.1 metamodel in Ecore format is used and the metamodel of the DEVS formalism, also in Ecore, is defined. The result of the transformation is a DEVS model in Ecore format that satisfies its corresponding metamodel. This model provides a sufficient set of information that can be exported and executed by different existing DEVS simulation tools and engines, in particular PowerDEVS. Furthermore, two examples of application to analyze the behavior of an automatic banking machine and a control system of an elevator are presented and analyzed. These case studies show the usefulness of the proposed approach.

This research is part of a comprehensive project that in the future will address the following extensions: i) development of a direct transformation of UML statecharts with composite states to DEVS models; ii) incorporation of more elements of UML to the SCs, including their transformations to elements of a DEVS model; iii) extension of the DEVS formalism with conditional transitions, in order to enable adding decision elements to the flow of the system; iv) exportation of the resulting Ecore DEVS models to other simulation tools; v) process evaluation with complex cases studies; vi) construction of a tool that covers the complete process of transformation, execution and analysis; vii) development of a deeper analysis of the validation mechanism of transformation; viii) implementation of the model-to-text (M2T) transformation using the OMG standards, in particular the MOF Model To Text Transformation Language (MOFM2T); and ix) development of an editor that allows the use of only those elements of the UML SCs that are considered in the transformation, preserving the semantics and design constraints defined in the latest version of UML.

References