Methodology for Automatic Synthesis of Wargame Simulator using DEVS

Transcription

1 Methodology for Automatic Synthesis of Wargame Simulator using DEVS Kim Ju Young, Shim Kwang Hyun ETRI Abstract In specific domain such as wargame, simulator developers may not well understand domain knowledge, which domain experts know. In such a case, the developers may leave detail domain knowledge within simulation models as a black box which is filled by domain experts. Thus, a simulator can be synthesized by filling the black box with algorithms for domain specific objects. This paper proposes a methodology for automatic synthesis of wargame simulators which are developed by the DEVS(Discrete Event Systems Specification) framework. For the synthesis the co-modeling methodology is employed in which specification and implementation of discrete event models. Keywords Wargame, DEVS, Simulator Synthesis, Co-modeling Methodology, Shared Library 1. Introduction As to a discrete event simulator developer (M&S expert) such as wargame simulator, the case of being short of the knowledge about the military affairs domain which is target system is a most. Therefore, a simulator is completed by M&S expert based on after the modeling process while the simulator requirement is made by the domain expert (Figure 1). A change can be generated in the user requirements after the development of a simulator is finished after this kind of a procedure. According to the changed requirements, if M&S expert develops a simulator again, a solution seems to be simple. In case the change of requirements is frequent, the cost and the time will be considerable. In the user requirements, it can include the contents that are satisfied with changing parametric value such as speed and shooting time interval, on the other hand, changing algorithms such as flight and detection. Figure 1. Discrete Event Simulator Development Process Real, in a domain, the research about the simulator in which an algorithm was frequently redefined, but the research about the simulator which exchange algorithms easily without the simulator correction has been little or nothing. The object of this research devises the plan that the domain expert or the user changes the detail algorithm of a model without the change of the developed simulator. For this, the simulation modeling adopted the Co-modeling Methodology. The Co-modeling Methodology is the detailed model of the object level designed by the domain expert and the DEVS model which is made by M&S expert, and the methodology separated according to these two models.[2] This paper is organized as follows. Section 2 discusses the co-modeling methodology. Section 3 introduces UML modeling and DEVS formalism. Section 4 introduces wargame model. Section 5 presents the proposed automatic synthesis of DEVS simulator. In Section 6, an example of a navy wargame model is developed within the proposed method. Conclusion is made in Section Co-modeling Methodology In this section, we briefly review the co-modeling methodology proposed in [2]. 2.1 Modeling Process using UML and DEVS The co-modeling methodology is analogous to HW/SW co-design in VLSI system design. HW/SW co-design means the meeting of system-level objectives by exploiting the trade-offs between hardware and software in a system through their concurrent design. To do so, system specification is partitioned in hardware and software parts for concurrent job. After that, each part is implemented and then integrated for co-simulation [6][7]. Co-modeling methodology is analogous to HW/SW co-design and the process is shown by Figure 2. At first, we design the simulator architecture from requirements and specification for a system to be simulated. If M&S experts do not need detailed knowledge on an object in atomic DEVS modeling, they define three sets and four functions according to DEVS formalism. On the hand, if atomic DEVS modeling needs detail knowledge on the object, domain experts defines such knowledge in forms of operations on the object using UML. Then, M&S experts employ the operations as services. Specifications of DEVS and UML models are implements by DEVSim++ and C++, respectively Feb , 2007 ICACT2007

2 of use cases and actors and relationships between them. As a behavioral classifier the diagram defines a sequence of actions, performed by one or more actors and a system, which results in an observable value to one or more actors. For system developers, this is a technique for gathering system requirements from a user s point of view Class Diagram A class diagram is a structure diagram that shows a set of classes, interfaces, and/or collaborations and the relationships among these elements. A class includes name, attributes and operations. This diagram is a central modeling technique that runs through nearly all object-oriented methods and represents the static part of a system. Figure 2. Simulator Development Process using Co-modeling Methodology 2.2 Advantage Within the proposed methodology M&S experts and domain experts design simulation models in a closely-coupled manner. The methodology should identify which objects are modeled only at the DES layer and which are modeled at both DES layer and the OM layer. Modeling at the DES layer does not requires specific knowledge of objects which only domain experts understand. However, if M&S experts do not understand detail operations of an object then operations should be provided by domain experts. In this sense, DEVS modeling is viewed as software and UML modeling viewed as hardware in the HW/SW co-design methodology. Thus, the main advantage of the proposed methodology is a concurrent process in models development. 3. UML and DEVS Formalism OO modeling provides a natural and powerful paradigm for representing the elements of a discrete event system and their behavior. In this section, we describe an instruction of UML as an OO modeling language and DEVS formalism for OO discrete event system modeling. 3.1 UML Modeling The Unified Modeling Language (UML) is a standard language for specifying, visualizing, and documenting the artifacts of an object-oriented system under development. It simplifies the complex process of software design, making a blueprint for construction. This sub-section describes only three diagrams in UML, which are used for modeling of an object at the OM layer. They are use case diagram, class diagram, and sequence diagram Sequence Diagram A sequence diagram is an interaction diagram that focuses on the time-ordering of a message between objects. A sequence diagram depicts a sequence of actions that occur in a system which is a very useful tool to easily represent the dynamic behavior of the system. This diagram includes objects and messages in two-dimensional form in nature. On horizontal axis, it shows the life of objects that it represents, while on the vertical axis, it shows the sequence of the creation or invocation of these objects. 3.2 DEVS Formalism The DEVS formalism specifies discrete event models in a hierarchical and modular form [1]. With this formalism, one can perform modeling more easily by decomposing a large system into smaller component models with coupling specification between them. There are two kinds of models: atomic model and coupled model. 3.1 Atomic Model Expression An atomic model is the basic model and has specifications for the dynamics of the model. Formally, a 7-tuple specifies an atomic model M as follows. AM = <X, Y, S, δ int, δ ext, λ, ta> X: Input Event Set Y: Output Event Set S: State Set δ int: Q Q: Internal Transition Q = {(s, e) s S,0 e ta(s)}: total state of M δ ext: Q X S: External Transition λ: Q Y: Output Function + ta: S R 0, : Time Advanced Function Use Case Diagram A use case diagram is a behavior diagram that defines a set Feb , 2007 ICACT2007

3 X δ ext M λ S ta R Figure 3. Atomic Model δ int 3.2 Coupled Model Expression A coupled model provides the method of assembly of several atomic and/or coupled models to build complex systems hierarchically. Formally, a coupled model is defined as follows. CM = <X, Y, {M i }, EIC, IC, SELECT> X: Input Event Set Y: Output Event Set Mi: Set of all component models in DEVS EIC X X : External Input Coupling Relation EOC Y i Y : External Output Coupling Relation IC Y i X i : Internal Coupling relation SELECT : 2 Mi - φ M i An overall system consists of a set of component models, either atomic or coupled, thus being in hierarchical structure. Each DEVS model, either atomic or coupled model, has correspondence to an object in a real-world system to be modeled. Within the DEVS framework, model design may be performed in a top-down fashion; model implementation in a bottom-up manner. in in1 in2 M1 out M12 in M2 out1 out2 Y out With the object of military training, the simulator for the training is used for the simulator for the major training of the Korean armed forces including an army, the air force, the Marine Corps, and etc. Moreover, in Korea U.S. combination training, it is mutually interlocked in the Korean Armed Forces - army, navy - models and U.S. Armed Forces - army, and navy - models through the HLA / RTI and is used for the training. The framework of a wargame simulator is comprised of the maneuver, detection, engagement and damage assessment. According to the used weapons system and the troop organization, above each step is expressed as the respectively different algorithm. For example, in case it is the navy wargame, maneuver, detection, engagement and damage assessment using a warship and the weapons system carried in the warship have to be modeled. 5. Automatic Synthesis Methodology 5.1 Simulator Development Process using Co-modeling Methodology The simulator development is initiated by the domain expert in the process of making the user requirements from the target domain. The simulator structure is completed based on a requirement. It is divided into the DEVS model which M&S expert designs after the model course of division and the object model part which the domain expert designs. (Figure 5) An M&S expert describes the schematic flow participating in a simulation of the models to three sets input, output, state - and 4 functions internal transition, external transition, output and time advanced of DEVS within the DEVS model. On the other hand, a domain expert defines the detail of each model as operations. Specifications of DEVS and object models are implements by DEVSim++ and C++, respectively. After the development of a simulator is finished, the case of the new user requirements being generated is considered. It does not correspond to under the parametric value and corresponds to under the algorithm of a model. If it is the case, since it redefines the object model which is the part in which a self takes charge the domain expert has to design the object followed the new algorithm. The algorithm of the objects was separated from a simulator so that the domain expert was able to make this kind of task easy and this used the shared library. Figure 4. Coupled Model 4. Wargame Simulator It is the impossible task to actually apply the defense system to the military and conduct an experiment on an effect. Therefore, the need of mathematical model which reflects actual war environment and its implemented simulator has been increasing. According to a use, wargame simulator can be divided into the training and analysis. Figure 5. Proposed Methodology Feb , 2007 ICACT2007

4 The domain expert implements the new algorithm of an object according to defined API as C. It is compiled to the shared library form and the algorithm is added in the DEVSim model and the previously developed runtime and the new simulator is completed. 5.2 Algorithm implementation Figure 6. Implementation: Shared Library The operations of the object model define in the simulator external file. In this way, after a simulator and algorithm are separated, the algorithm correction is possible by the domain expert in which it does not have the M&S knowledge by establishing this algorithm with the shared library form. The modified algorithm can be applied to the preexistence simulator. An algorithm is little more looked into about the process of making the shared library form in detail. The part corresponding to an algorithm is found in the object model and the prototype of the algorithmic function is declared. It is variables in which at this time is used for an algorithm given to an input parameter. For example such as the maneuver algorithm of a warship, the maneuver of a warship is expressed as the update of the location coordinate value. It is the maneuver algorithm function role to decide the next coordinate. It is variables which are used in order to find the next coordinate the current coordinate value and speed of a warship, the traveling direction, the maximum moving distance, and etc. (figure 6) If it computes according to an algorithm by using these variables as the input parameter, the next coordinate of a warship which is the return value is determined. A coordinate which is the return value of the algorithmic function is delivered to the DEVS model by the request of the DEVS model in which simulation is progressing (Figure 7). 5.3 Simulator automatic synthesis In co-modeling methodology, M&S experts develop DEVS models that represent system behaviors in state transition level. Domain experts are responsible for developing specific algorithms as individual functions. These algorithms typically require domain-specific knowledge. Majority of co-work between M&S experts and domain experts in co-modeling is to specify function prototypes. The functions should be designed independently and self-contained as possible. DEVS models call associated functions inside each state transition functions. The contents of the function, or specifically the level of abstraction of equations used to implement the function, does not affect the model behavior as long as the I/O types of the function is consistent. Domain experts are able to supply set of behavior functions in the form of a dynamically linked library. Combined with implemented DEVS models, a complete simulator is synthesized by selecting supplied dynamically linked libraries. This selection can be done at run-time. Therefore simulator users easily compare different combination of algorithms. Figure 8 describes these procedures. Figure 8. Simulator Automatic Synthesis: DEVS + Object Algorithm In the model of the simulator inside, it does not have a change. However, it can refer that a simulator is automatically synthesized since the algorithm library is defined since a simulation is performed according to the new algorithm. The number participating in a simulation of a model is n. When it has the algorithm candidate of m, the effect of the simulator of m n is obtained a user from one simulator. The total process referred in front of can refer to the method for being comprised of the execution file without the source code of a simulator that even on top rather than the benefit is more bigger. 6. Case Study: Navy s warship-engagement simulator Figure 7. Algorithm Implementation Process For example, the simplified navy game simulator be illustrated in order to demonstrate the effectiveness of the proposed methodology and confirm automatic synthesis of simulator. The marine engagement simulator is a series of combat which it performs in order to preserve the alive of the our army s warship from the threat of the missile attack of an occasion. A warship has 3 step barriers for preventing the Feb , 2007 ICACT2007

5 Figure 9. Simulation Scenario attack of the ASM (Anti-Ship Missile) which is the animosity missile.(figure 9) The maneuver of our army s warship is commenced according to the start-up algorithm if the simulation start instruction drops by a gamer. According to the detection algorithm of a warship, the command that it begins the engagement if ASM is detected comes down. According to the engagement algorithm, each barrier engages ASM. In case our army s warship received the attack of ASM, the damage potential is evaluated and in case the damage condition is light, it participates again in the battle. However, a simulation is terminated in case the damage potential is serious. In this way, a simulation is progressed. And the interrogation which it confronts whether it most effectually can enhance the survival rate of the subclass when performing any kind of algorithm at each step or not appears. A simulation was performed while giving a change to the start-up algorithm of the middle warship. The present example selected a type while being implemented in the Microsoft Visual C 2003 environment of the Windows XP base 'Regular DLL using shared MFC DLL' [4]. As shown in Figure 10, the survival rate change of a warship could be confirmed according to an algorithm while experimenting on 3 start-up algorithms. For example, whole 8 algorithms is used for the resolution canon simulator giving. Each algorithm has 3 candidate functions. The result of the simulator of 6561s which is 3 8 being altogether automatically synthesized is brought. And as to the total process where a simulator is synthesized, an algorithm and the synthesis which the simulator developed in a preexistence does not go through the process of a recompilation since being the generating process of the algorithmic function file and is freshly made as the execution file occur. Figure 10. Simulation Result 7. Conclusion This paper proposes an automatic synthesis modeling methodology using co-modeling methodology. The main objective of the framework is to provide a flexible ways to change model behaviors to simulator users. The co-modeling methodology partitions model specifications into two modeling parts; discrete event modeling and object modeling. The M&S experts define time associate output and transition function using DEVS formalism by use of operations defined in the object modeling. The discrete event models are specified regardless of the algorithms used to implement object modeling operations. The object modeling operations are implemented as a dynamically linked library which is dynamically loaded after the simulator application starts. The methodology enables for simulator users to alter model behaviors or algorithms without recompiling the simulator. A case study demonstrated effectiveness of the proposed approach. This approach may be applied to more complex war game modeling projects. REFERENCES [1]Bernard P. Zeigler, H. Praehofer, and Tag Gon Kim. Theory of Modeling and Simulation, ACADEMIC PRESS, [2]Chang Ho Sung, Su Youn Hong and Tag Gon Kim, "Layered Approach to Development of OO War Game Models Using DEVS Framework," in Proceedings of the Summer Computer Simulation Conference, Philadelphia, PA,USA, July 2005, pp [3]Su Youn Hong and Tag Gon Kim, "Embedding UML Subset into Object-oriented DEVS Modeling Process," in Proceedings of the Summer Computer Simulation Conference, San Jose, California, USA, July 2004, pp [4]Kwang Woo Park, Woo Kyoung Kang and Young Chul Jin. Visual C++.Net Programming Bible, Samyang Media, 2003 [5]Tag Gon Kim. EE612 Lecture Note, EECS, KAIST, [6]Jay K. Adams and Donald E. Thomas, The Design of Mixed hardware/software, in Proceedings of the 33 rd annual Conference on Design automation, Las Vegas, Nevada, USA, June 1996, pp Feb , 2007 ICACT2007

6 [7] David W. Franke and Martin K. Purvis, Hadeware/Software CoDesign: A Perspective, in Proceedings of the 13 th international conference on Software engineering, Austin, Texas, USA, June 1991, pp Feb , 2007 ICACT2007