1 Introduction

Traditional military simulation models are usually represented by UML which has not precise and unambiguous semantics defined using a mixture of OCL (Object Constraint Language) and informal text, or the semantics of simulation models are left to model interpreters or simulators which are defined by general-purpose programming languages, which is clearly unacceptable for formal analysis [1]. Meanwhile, although the syntax of current domain specific modeling languages (DSML) are formally described with a lot of general metamodeling tools like UML Profile [2], EMF [3], and GME [4] etc., the semantics are left toward other less than desirable means [5]. All of these accompanying with the lack of formal model transformations contribute to difficult formal analysis at a model level. Hence, it is a real challenge to describe simulation models formally, and to improve the model continuity that exist between different models in different development stages at different levels of abstraction [6], so as to reuse existing model assets and simulation services to a great degree.

This paper proposes a set of formal theories of model transformations for engineering model continuity, transforming models represented by various modeling languages into other formalisms that have precise definitions of semantics until they reach final executable simulation models [7]. A motivating example named group fire control channel system (GFCCS) is used through this paper, commencing with its customization of DSML and transforming its conceptual models represented in this DSML to final executable simulation models. After that, a military simulation system in support of engineering modeling and composable simulating is capable of integrating those executable simulation models and reusing them for multiple simulation applications.

2 Background

Inconsistent terminology in the model-driven engineering (MDE) context [8] means it is necessary to define basic meanings of important frequently used terms to provide a common understanding. Many of these terms are used alternatively in specific contexts, but providing their definitions and/or subtle distinctions is helpful to understand the methodologies, techniques, and tools used in model-driven development. For different modeling goals, there exist three typical issues, i.e. model composability, model heterogeneity, and model continuity.

Firstly, model composability [9, 10] concentrates on the syntactical matching and semantic relations between different simulation models. Unlike the other two issues, it is usually discussed in a MDE context and emphasizes the integration of multiple simulation models to form an effective and meaningful simulation application [11, 12].

Secondly, model heterogeneity comes from the joint use of several DSMLs dedicated to particular domains or applications. In many cases, it refers to the syntactical incompatibility between different used DSMLs during the language customization process and has four sources in general [13, 14]. Firstly, the different technical or application domains involved in a simulation system under design require different model specifications, modeling formalisms, or simulation protocols. Secondly, the different levels of abstraction need suitable modeling techniques. Thirdly, a simulation system is always studied from different points of view, and lastly different stages of a development cycle may use different languages for different activities.

Thirdly, model continuity refers to the generation of an approximate morphism relation between different phases of a development process [15]. In general, model continuity is obtained if the initial and intermediate models are effectively consumed in the later steps of a development process and the modeling relation is preserved. In a sense, model continuity is similar to the consistency between the source and target models, involving the syntactical correctness of target model, the completeness of source model consumed in model transformation, and the semantic relations preserved in target model [16].

3 Model transformations

Model transformation is a process that takes a source model in a specific form as an input and outputs another form of the target model according to a set of predefined rules. This process does not build new models from scratch, but reuse existing information when conducting a model transformation. A formal model transformation requires that the models involved in the transformation are represented clearly by well-defined modeling languages that have accurate syntax and unambiguous semantics. Furthermore, it requires that the transformation rules are written by a well-defined transformation language to ensure the transformation is conducted under a well-defined transformation template [17]. To ensure model continuity, the target model should preserve as much as possible the initial model information and modeling relations that are embedded in the source model [18].

3.1 The basic model transformation mode

Figure 1 shows the basic mode of model transformation. In this mode, each node at a certain layer conforms to or is an instance of the node at a higher layer. The middle column is the transformation mechanism that inputs the left source nodes and outputs the right target nodes. For example, the transformation engine is an instance of the transformation template which is further an instance of the transformation language, which means the transformation template is written by the transformation language and prescribes the internal mechanism of the transformation engine. This engine inputs the source model which is an instance of the source metamodel and outputs the target model which is an instance of the target metamodel, and both metamodels are respectively taken as the inputs and outputs of the transformation template [19, 20].

Fig. 1
figure 1

The basic model transformation mode

Full size image

According to the concrete form of target model, model transformation has two typical categories: model to model (M2M) and model to text (M2T). In practice, M2T transformation is also called code generation when the text is in the form of source code. In general, a model-driven development process contains a sequence of M2M transformations and a final code generation. In addition, model transformation is endogenous when the source metamodel is similar to the target metamodel, and exogenous when they are different [21].

3.2 MDA based model transformations

MDA (model-driven architecture) introduces three model development roles, and two transform mechanism types [22]. Using these MDA models, i.e. conceptual independent (CIM), platform independent (PIM), and platform specific models (PSM), developers can be classified into comparable roles, i.e. conceptual and simulation modelers, and simulation programmers, respectively, where later stages only can commence when developers for the former stages reach a consensus on an artifact. For example, once the problem owner and the conceptual modeler agree on a conceptual model, the simulation modeler can transform it into a formal model. In addition, M2M and M2T model transformation mechanisms are used as a bridge to reduce the gap between these roles. We adopt the formal MDA process as depicted in Definition 1 [15].

Definition 1

AMDA process is defined as \(mda = \left\{ {n,MML,ML,MO,SL,pl,MTP,STP,MT,SM,TO} \right\}\)

  • \(n = 3(CIM,PIM,PSM)\),

  • \(MML = \left\{ {ll_{0} ,ll_{1} ,ll_{2} } \right\}\) is an ordered set of metamodeling languages,

  • \(ML = \left\{ {l_{0} (mm_{CIM} ),l_{1} (mm_{PIM} ),l_{2} (mm_{PSM} )} \right\}\) such that

    \(\begin{aligned} & confromTo(mm_{CIM} ,ll_{0} ), \\ & confromTo(mm_{PIM} ,ll_{1} ), \\ & confromTo(mm_{PSM} ,ll_{2} ), \\ \end{aligned}\)

    This means metamodels must conform to their corresponding metamodeling languages.

  • \(MO = \left\{ {CIM,PIM,PSM} \right\}\) such that \(CIM\) is the initial model, \(PSM\) is the final model, and

    \(\begin{aligned} & instanceOf(CIM) = mm_{CIM} , \\ & instanceOf(PIM) = mm_{PIM} , \\ & instanceOf(PSM) = mm_{PSM} , \\ \end{aligned}\)

    This means models must conform to their corresponding metamodels.

  • \(SL\) is a set of model transformation languages,

  • \(pl\) is a programming language with simulation capabilities,

  • \(MTP = \left\{ {p_{CIM} ,p_{PIM} ,p_{PSM} } \right\}\) such that

    \(\begin{aligned} & p_{CIM} = \left\{ {l_{0} (mm_{CIM} ),l_{1} (mm_{PIM} ),r_{0} } \right\}, \\ & p_{PIM} = \left\{ {l_{1} (mm_{PIM} ),l_{2} (mm_{PSM} ),r_{1} } \right\}, \\ & p_{PSM} = \left\{ {l_{2} (mm_{PSM} ),pl,r_{2} } \right\}, \\ \end{aligned}\)

    This represents model transformation patterns that a source language to a target language through some rules.

  • \(STP\) is a set of other supplementary formal model transformation patterns,

  • \(\begin{aligned} & MT = \{ \\ & transformTo(CIM,p_{CIM} ) = PIM, \\ & transformTo(PIM,p_{PIM} ) = PSM, \\ & transformTo(CIM,p_{PSM} ) = SM \\ & \} , \\ \end{aligned}\)

    This means model transformations that a source model to a target model using some patterns.

  • \(SM\) is the final executable simulation model,

  • \(TO\) is a set of tools to ease the activities.

Above definition is suitable for general model development base on the MDA principles. Given this definition, we can conclude a process for the GFCCS development as Definition 2, which will be illustrated by later sections. In the GFCCS process, we take the GFCCS DSML as the conceptual modeling language to describe CIM, P-DEVS [23] as the modeling formalism to define PIM, and JAVA as the programming language to build PSM. Hence, the GFCCS process involves the following types of metamodels and model transformations.

  • The CIM metamodel is GFCCS metamodel.

  • The PIM metamodel is P-DEVS metamodel.

  • The PSM metamodel is JAVA metamodel.

  • The CIM–PIM transformation is GFCCS to P-DEVS transformation.

  • The PIM-PSM transformation is P-DEVS to JAVA transformation.

  • The PSM-SM transformation is JAVA to java code transformation.

Definition 2

A GFCCS simulation modeling process is defined as \(gfccs = \left\{ {n,MML,ML,MO,SL,pl,MTP,STP,MT,SM,TO} \right\}_{instance}\)

  • \(n = 3(CIM,PIM,PSM)\),

  • \(MML = \left\{ {Ecore,Ecore,Ecore} \right\}\) is an ordered set of metamodeling languages,

  • \(ML = \left\{ {l_{0} (mm_{GFCCS} ),l_{1} (mm_{DEVS} ),l_{2} (mm_{JAVA} )} \right\}\) such that

    \(\begin{aligned} & confromTo(mm_{GFCCS} ,Ecore), \\ & confromTo(mm_{DEVS} ,Ecore), \\ & confromTo(mm_{JAVA} ,Ecore), \\ \end{aligned}\)

  • \(MO = \left\{ {CIM,PIM,PSM} \right\},\) and

    \(\begin{aligned} & instanceOf(CIM) = mm_{GFCCS} , \\ & instanceOf(PIM) = mm_{DEVS} , \\ & instanceOf(PSM) = mm_{JAVA} , \\ \end{aligned}\)

  • \(SL = \{ ATL,Acceleo\}\) is a set of model transformation languages,

  • \(pl = JAVA\) is the final programming language

  • \(MTP = \left\{ {p_{CIM} ,p_{PIM} ,p_{PSM} } \right\}\) such that

    \(\begin{aligned} & p_{CIM} = \left\{ {l_{0} (mm_{GFCCS} ),l_{1} (mm_{DEVS} ),gfccs2devs.atl} \right\}, \\ & p_{PIM} = \left\{ {l_{1} (mm_{DEVS} ),l_{2} (mm_{JAVA} ),devs2java.atl} \right\}, \\ & p_{PSM} = \left\{ {l_{2} (mm_{JAVA} ),JAVA,java2code.mtl} \right\}, \\ \end{aligned}\)

  • \(STP = \emptyset\) dictates there exists no other supplementary formal model transformation patterns,

  • \(\begin{aligned} & MT = \{ \\ & transformTo(CIM,p_{CIM} ) = PIM, \\ & transformTo(PIM,p_{PIM} ) = PSM, \\ & transformTo(CIM,p_{PSM} ) = SM \\ & \} , \\ \end{aligned}\)

  • \(SM\) is the final executable simulation model,

  • \(TO = \{ ATL,Acceleo,EMF,GMF,Eclipse\_IDE\}\).

3.3 Criteria for evaluating model continuity

Model transformation is an automated process of modifying and creating one or several target models from one or several source models. The aim of model transformation is to save effort and reduce information loss as much as possible by automating model building and modification where possible [24, 25]. The key to designing a successful model transformation is a set of formal transformation rules to improve model continuity. Although there is no general guidance to define a good model transformation, we can evaluate model continuity according to the following criteria.

  1. 1.

    Correctness A model transformation is syntactically correct if the target model conforms to the target metamodel specification [26], and semantically correct if the target model contains information as much as possible from the source model [27].

  2. 2.

    Completeness A model transformation is complete if the target model has a corresponding element for each element in the source model.

  3. 3.

    Uniqueness A model transformation is unique if there are no two identical elements in the generated target model [28].

  4. 4.

    Determinism A model transformation is determinate if it produces a uniquely defined target model output for each specific source model input [29].

4 Customizing a DSML based on metamodeling

4.1 Metamodeling based on EMF

Metamodeling is an important mean to design DSMLs [30, 31], especially for EMF usually has close relationships with a set of OMG standards, like UML, MOF, XMI, and MDA, etc. Firstly, UML is widely used to capture various concerns of a certain system by an object-oriented method, emphasizing multi-view to describe the structure, behavior, function, and deployment, etc. While, EMF as a way of defining metamodels is only concerned with one aspect of a system, i.e. class structure. Secondly, EMF/Ecore focuses on the tool sets not the metadata warehouse management, thus avoiding some of the complex issues such as data structure, package relationships, and associations compared to MOF. Thirdly, XMI is a widely accepted serializing standard which is not only used as the format for serializing EMF models, but also suitable for serializing the metamodel, i.e. Ecore itself. This method is very different with the UML profiling mechanism because it defines metamodels from scratch without considering the UML rules [32]. Hence, it has the potential for the most direct and succinct expression of domain concepts. Furthermore, it has a collection of supporting tools (e.g. GEF and GMF) thanks to the Eclipse open source architecture. Recently, some researches also have identified the need of domain specific metamodeling to avoid the general metamodeling facilities like UML and EMF [33].

Using EMF, we take the GFCCS as a motivating example to illustrate how to design and develop a DSML for this domain. This language is able to directly use the domain concepts and relationships to build a model. For this purpose, it is necessary for a language engineer to have a good background of GFCCS. Many of today’s GFCCS often combine multiple subsystems. A group of air defense, for example, combines the command and control center, sensor, weapon, and a variety of countermeasures.

Figure 2 shows the metamodel of GFCCS. This metamodel consists of a basic diagram node named GroupFireControlSystem and two mutually related nodes named Node and Connection respectively. The Node derives a set of domain concepts such as Group, GroupNode, Weapon, Target, and Channel, which are connected by specific relationships. For example, two groups can share common information by the relation tagged as COPShare that represents common operation picture (COP) [34]. A group can have one or multiple members and zero or multiple weapons which can also be equipped by a group member. A group member may be disjoint with or affiliated by itself, and can control zero or multiple fire control channels. Each channel may be mutually exclusive with itself. It embraces two dynamic entity lists, i.e. weaponList and targetList. These two lists are used to manage weapons and targets that are alive or may be already ruined [35, 36].

Fig. 2
figure 2

The GFCCS metamodel

Full size image

In fact, except the abstract syntax as described above, there are other aspects need to be detailed for a well-defined metamodel [37]. Table 1 defines the static semantics of GFCCS metamodel, written by OCL [38], explaining how those elements of the abstract syntax model can be organized as a valid GFCCS metamodel.

Table 1 GFCCS domain specific constraints using OCL
Full size table

4.2 Graphical definitions of GFCCS using GMF

This subsection presents a guidance of the definition, mapping, and generation of a graphical editor for GFCCS using GMF. According to the GMF dashboard, one can define the domain model, domain gen model, tooling model, graphical model, mapping model, and gmf gen model step by step, then generate the diagram editor. Due to the domain model and gen model belong to the field of abstract syntax definition as already given before, so we describe the definition of concrete syntax as follows [39].

  1. 1.

    Tooling model As usual, the tooling model definition provides six ways to define a tool palette of a graphical editor, including creation tool, standard tool, generic tool, tool group, palette separator, and image. In GFCCS, we created a tool for each element of the domain model except the abstract element Node, and bundled a representative image for each element.

  2. 2.

    Graphical model It defines the concrete display of modeling elements that will be used in the graphical editing environment. In general, GMF provides default display based on the domain model, but one usually needs to define the figure gallery, figure descriptor, and polyline decoration in practice. In GFCCS, we set the Group and GroupNode as compartments to be able to contain other elements, for example, Group can contain GroupNode and Weapon, and GroupNode can contain Weapon. Additionally, we set the Channel as a scalable polygon, adding template points (0, 0), (40, 0), (40, 30), (30, 30), (30, 40), (40, 30), (30, 40), (0, 40).

  3. 3.

    Mapping model When the domain model, tooling model, and graphical model are ready, it is necessary to map them into a whole. Usually, we need to select the corresponding tooling nodes and diagram nodes for each node mapping, and provide the correct compartment figure for each compartment node. In the properties of Channel node, for example, we select the Node Channel (Channel Figure) for the diagram node, and the Creation Tool Channel for the tooling node.

  4. 4.

    GMF gen model If the mapping model is defined correctly, it can generate correct gmf gen model without much modifications. In many cases, it is possible to modify some parameters, such as the fixed background, the list layout, and the suffix of a diagram project.

4.3 The GFCCS DSME

Figure 3 shows a simple example of building an engagement scenario using the GFCCS DSML. On the tool palette, this domain specific modeling environment (DSME) contains a set of buttons decorated with professional denotations, including the basic language elements such as GroupFireControlSystem, Group, GroupNode, Channel, Weapon, and Target as well as various relationships. Using this environment, it is possible for domain experts to use these language elements intuitionally and friendly. For example, one can draw an arrow from Channel List 1 to Enemy Fighter 1 BLUE only by ChannelTargetList, disabling the use of other relationship buttons.

Fig. 3
figure 3

The GFCCS DSME

Full size image

In the editor, we create a scenario of many to many combat between two opposite sides RED and BLUE. The RED side consists of two defense groups, i.e. Defense System RED and Remote Surveillance System RED, which refers to the local defense system (e.g. air defense base) and the remote surveillance system (e.g. satellite). The local system is composed of a warship platform, a ground-to-air missile base, and a helicopter platform, which are armed with two surface-to-air missiles, a ground-to-air missile, and a homing torpedo, respectively. The BLUE side consists of three coming threats which are denoted by Enemy Fighter 1 BLUE, Enemy Fighter 1 BLUE, and Enemy Submarine BLUE. In addition, there exist two lists of fire control channel which are denoted by Channel List 1 and Channel List 2, respectively. The former list is managed by the warship platform and has a weapon-target pair, i.e. Surface2AirMissile1-Enemy Fighter 1 BLUE. The latter list is managed by the helicopter platform and has two weapon-target pairs.

5 GFCCS implementations

5.1 The rules of GFCCS to P-DEVS to JAVA transformations

The matching rules of GFCCS to P-DEVS transformation is defined by using the GFCCS metamodel and P-DEVS metamodel, as detailed in Table 2. The basic diagram node GourpFireControlSystem matches with the DEVSModel element. The compartmental nodes like Group and GroupNode match with coupled components named DEVSCoupledComp. The connections that connect the modeling elements of the same layer are transformed into internal transitions named DEVSOutToIn_ICConnection, while those across different layers are transformed into external transitions and output functions with a set of ports.

Table 2 The matching rules of GFCCS to P-DEVS transformation
Full size table

The matching rules of P-DEVS to JAVA transformation is defined by using the P-DEVS metamodel and JAVA metamodel, as detailed in Table 3. The basic element DEVSModel matches with a JAVA package named JAVAPackage which includes javaClasses, javaConstructors, and javaExpressions. Both the coupled component DEVSCoupledComp and the atomic component DEVSAtomicComp match with JAVA classes which inlude JAVAVariables, javaConstructors, and javaExpressions. DEVSInputPort, DEVSOutputPort, and StateVariable are all transformed into JAVAVariables. The connections like DEVSOutToIn_ICConnection, DEVSInToIn_EICConnection, DEVSOutToOut_EOCConnection as well as Expression are transformed into JAVAExpressions. The remaining functions like DeltaIntFunction, DeltaExtFunction, LambdaFunction, TimeAdvanceFunction, DeltaConFunction are all transformed into JAVAMethods.

Table 3 The matching rules of P-DEVS to JAVA transformation
Full size table

Such transformation rules are written in ATL, as proposed in Definition 2. ATL, the Atlas Transformation Language, is a model transformation language specified as both a metamodel and a textual concrete syntax. In the MDE field, ATL provides developers with a means to specify the way to produce a number of target models from a set of source models. An ATL transformation program is composed of rules that define how source model elements are matched and navigated to create and initialize the elements of the target models. Besides, ATL Integrated Development Environment (IDE) provides a number of standard development tools (syntax highlighting, debugger, etc.) that aim to ease the design of ATL transformations. The ATL development environment also offers a number of additional facilities dedicated to models and metamodels handling. These features include a simple textual notation dedicated to the specification of metamodels, but also a number of standard bridges between common textual syntaxes and their corresponding model representations.

5.2 Automatic code generation

Based on ATL, the transformations of GFCCS to P-DEVS to JAVA instances contains two projects named GFCCS2P-DEVS and P-DEVS2JAVA, each of which includes three packages, i.e. Metamodels, Models, and TransoformationEngine. In the edit area includes three instances for the GFCCS, P-DEVS, and JAVA metamodel respectively, and two ATL files for the GFCCS to P-DEVS and to JAVA transformations.

For the M2T transformation, it contains a source model and the generated code framework. Take the node Defense_System_RED as an example, the transformation model design should incorporate all the source model required information to satisfy completeness. The target code framework is automatically generated, but the concrete logic details must be manually implemented. In practice, not every concrete detail should be considered when designing M2T transformation models, because they may heavily burden the design phase.

Following the M2T transformation principles, the general source model is some instance models that must conform to a certain metamodel, and the target model can be text, e.g. java, C++, python, etc. Transformation model design is vital to implement the M2T transformation. This paper performed M2T transformation using Acceleo, a template based code generator incorporating a code generation editor with syntax highlighting, completion, real time error detection, and refactoring. The source model was a collection of JAVA instance models, represented by an instance file named JAVAcase.xmi, and the target model was described in Java programming text.

5.3 Model continuity in GFCCS implementations

The process of GFCCS implementation showed that model continuity between different development stages is obtained when applying the formal transformation definition successfully. As stated earlier, it is possible to provide model continuity in a development process when transforming the initial and intermediate models, and preserving the modeling relations during the transformations. To evaluate model continuity, we already presented the criteria for model transformations before. According to these criteria, we describe how the model continuity is obtained for the process of GFCCS implementation when the formal transformation rules are applied. In fact, except these criteria as listed, there are some other non-functional requirements such as termination and readability satisfied. Also note that maintainability, scalability, reusability, evolvability, efficiency, etc. are partially supported since these requirements need more experiments for a better evaluation [40, 41].

The process of GFCCS implementation has two kinds of model transformation, with different expressions and output types. As the source input or target output of model transformations, the formal definition gives three model types: independent of computing details, independent of the computing platform, and specific to a particular computing platform, and two model transformation categories.

In the M2M category, the transformation focuses on the design of a set of formal rules to ensure model continuity when transforming CIM to PIM and to PSM. The transformation usually incorporates three steps.

  1. 1.

    All source concepts, relationships, and domain specific rules are transformed into particular target elements, connections, and domain specific constraints, respectively.

  2. 2.

    Compare all target elements, connections, and constraints to delete identical expressions.

  3. 3.

    Check the target model conforms to the target metamodel.

Completeness can be ensured in step (1) since all source elements are transformed, and a corresponding target element can be found for each source element. Step (2) is helpful and necessary to reduce target element redundancy, thus uniqueness is guaranteed. Syntactical correctness can be satisfied in step (3) since the target model will be expressed in a given formalism, and its semantic correctness will be evaluated in later stages of model transformation. Determinism is guaranteed implicitly in the model transformation editor that eases development and execution of ATL transformations [42].

In the M2T category, the transformation converts a source model into a text file, i.e. PSM to source code. If the text is in source code form, then the transformation is also called code generation, and the transformer is also called a code generator. The process of a M2T transformation is similar to that of a M2M transformation. The only difference is that step (2) in the M2M transformation can be skipped in a M2T transformation, since uniqueness has already been checked. Therefore, the three criteria listed above are achieved according steps (1) and (3). Similarly, determinism is satisfied because model transformation editors, such as Acceleo [43], implicitly guarantee a unique output for each particular input.

5.4 Simulation results and analysis

Once the code is generated and verified correctly, it needs to be integrated into a powerful simulation platform to validate the effectiveness and superiority of the proposed MDE techniques. The WESS (Weapon Effectiveness Simulation System), an engagement-level effectiveness simulation platform that has been applied successfully in many institutes and industries, is chosen. This platform contains a tool suite including scenario editing, data preparation, Python-based script decision modeling, experiment design, 2D/3D displayer, and evaluation analysis, etc. In general, WESS has two workflows. One is to design and development simulation models from the professional simulation modeler’s perspective, and the other is to apply WESS to develop a simulation application for certain requirements. More details about how to use WESS can be seen in [44, 45].

Consider the GFCCS simulation, we set the total logical running time to 1500 s for a simulation and run 150 rounds of Monte Carlo simulations. Figure 4 displays the 2D view. A benefit of the simulation display is that it assists us in a visual way to grasp the whole real-time situation of the battlefield, releasing us from thousands of lines of codes or texts. From the main window of this figure, we can see the overall situation of an engagement between two sides. The red side is a fighter which is equipped with radars and missiles, and the blue side contains an airfield, a warship, and also a fighter. At the simulation time 1160 s, the warship finds the enemy fighter and prepares to launch a surface to air missile. Below the main window we can see two charts, each of which contains couples of curves over time. Once an object is selected in the main window, the left one shows the corresponding elevation and velocity curves, while the right one shows curves for the yaw, roll, and pitch angles.

Fig. 4
figure 4

The 2D display of GFCCS simulation

Full size image

Table 4 presents the simulation data of a missile prototyped SM2New_1 in terms of its key states such as Start, Boost, Guide, and Terminal. The surface to air defense missile, SM2New_1, is prepared at 1172 s, launched and goes into boost phase by 3 s, then switches to guide phase at 1183 s, finally to terminal phase at 1201 s. Its velocity initially rises sharply then reaches a peak at the end of boost phase, afterwards, descends slowly. Unlike the velocity line, the elevation always rises smoothly, except approaching the target.

Table 4 Simulation data of the SM2New_1 missile
Full size table

6 Conclusions

In general, a formal transformation requires that the models are specified in well-defined modeling languages and the transformation rules are defined with a well-defined transformation language. To ensure model continuity, the target model should contain as much as possible from the source model and the modeling relations should be preserved during the transformations. Consider the semantic gap between the different stages of a simulation modeling process, this paper defines a formal model transformation based on MDA and uses the GFCCS implementation as a motivating example through the overall transformation process. This process consists of GFCCS to P-DEVS and to JAVA transformations, accompanying with the initial DSML design based on EMF and the final source code generation. Before the transformation process, some criteria, i.e. correctness, completeness, uniqueness, and determinism, are listed to evaluate the model continuity during the transformation. The transformation results showed that model continuity is obtained when the transformations are conducted successfully according to the formal definition. Currently, there are little guidelines to instruct the explicit use of conceptual model in later stages of a simulation model development lifecycle [46,47,48]. A benefit of this study is that the formal definition of model transformation can be viewed as a referenced experience to guide other practices that have the needs of formal analysis. However, as a drawback some effort for further experiments and evaluations are required.