UML-BASED MODELING AND SIMULATION METHOD FOR MISSION-CRITICAL REAL-TIME EMBEDDED SYSTEM DEVELOPMENT

Transcription

1 UML-BASED MODELING AND SIMULATION METHOD FOR MISSION-CRITICAL REAL-TIME EMBEDDED SYSTEM DEVELOPMENT KeungSik Choi, SungChul Jung, HyunJung Kim, Doo-Hwan Bae Department of EECS Korea Advanced Institute of Science and Technology (KAIST) Daejon , Korea {kschoi, scjung, hjkim, DongHun Lee Head of the 2 nd System Development Agency for Defense Development (ADD) Jinhae , Korea dhlee@add.re.kr ABSTRACT Mission-critical embedded system needs to satisfy quite stringent requirements and the cost of building and testing is high. DoD has recommended to apply M&S method to evaluate the requirements of the proposed system during the development. However, it is difficult to develop a simulation model because it needs both domain knowledge and simulation technique extensively, which also requires intensive communication among stakeholders. We, therefore, need an efficient method for requirements specification and simulation model development. We propose UML-based M&S method which uses UML2.0 as the requirements specification method as well as the simulation model development tool. We define constraints on UML diagrams to use them as a simulation modeling tool. We specify the structure and environment of the system with Class Diagram and the behavioral requirements with Sequence Diagram. The UML diagrams are then transformed to a simulation model by model transformation rules. The contribution of this approach is that it provides an efficient and error preventive way of developing simulation model for mission-critical embedded system development. We applied this approach to develop the Fire Control System (FCS) of the Navy s warship, which reduced the communication overhead and simulation model development errors. KEY WORDS UML-based Modeling and Simulation, Mission-critical Embedded System Development, Model Transformation Introduction The mission-critical system such as Fire Control System (FCS) of a warship has significant requirements of strict timing control among components in order to meet external I/O and of high level accuracy in the operation. The best way to validate the requirements of the FCS is through the live fire testing, however it costs a lot and is only possible after the system is developed. As a solution, the DoD (Department of Defense) has strongly recommended to apply Modeling and Simulation (M&S) technique to validate the requirements during the system development []. However, it is difficult to develop a simulation model in the early phase of the system development life cycle because the simulation model development usually takes long time and requires sound knowledge on simulation techniques. It also requires intensive cooperations among stakeholders of multiple organizations because the domain experts usually don t know what are the necessary elements for simulation and the simulation experts usually don t have the domain knowledge. Therefore, we need a more practical and efficient way of applying M&S to the development of mission-critical systems. We propose UML-based M&S method, which uses UML2.0 [2, 3], as the communication method between domain experts and simulation experts as well as the simulation model development tool. We use Sequence Diagram (SD) rather than State Machine (SM) to capture the behavioral requirements including timing constraints (e.g., the communication interval among radars, BCU, and guns) of a system because the SD is close to human understanding and usually remains rather abstract. Ziadi mentioned that designing a system behavior directly with SM is not a intuitive process, as the notion of state is often not natural in early stages of development [4] because SM considers an intra-object description and is closer to an implementation. To use the UML as the M&S tool, we characterize the differences between simulation modeling and general UML modeling, and define the needed constraints on UML diagrams for the simulation modeling. The constrained UML diagrams provide the basic elements for simulation modeling and make it possible to transform the system s requirements into a simulation model. The proposed UML-based M&S method takes three steps. First, we analyze the domain and specify the requirements with the Use Case (UC) and constrained SD. Second, we synthesize the SMs from the SDs to make the model transformation process easy. Finally, we transform the UML models into a simulation model which can be executed by the simulation engine. The model transformation eliminates the mistakes of human-beings and improves the efficiency in the development of the simulation model. Even though the UML CASE (Computer Aided Software Engineering) tool such as IBM Rational Rose or Telelogic Tau provides a simulation functionality, it is limited to trace the state change or signal invocation. We, therefore, need a specialized simulation engine which can take

2 over the details of the simulation algorithm (e.g., simulation time management, event management, etc.) and provides the libraries to analyze the numerical simulation data.we use a ready-to-use simulation environment, DE- VSim++ [5], which is based on the DEVS (Discrete Event System Specification) formalism [6]. The structure of this paper is as follows. In Section 2, we briefly introduce the DEVS and DEVSim++ simulation environment. Section 3 describes the UML-based M&S method. Section 4 demonstrates the application of this approach to the development of FCS of a warship and Section 5 introduces related work. Section 6 summarizes the main results of this paper and gives a plan for future work. 2 Background 2. DEVS Formalism and DEVSim++ Simulation Modeling Environment DEVS is a general formalism for discrete event system modeling based on set theory [6]. It allows representing any system by three sets and four functions: Input Set, Output Set, State Set, External Transition Function, Internal Transition Function, Output Function, and Time Advanced Function. DEVS formalism provides the framework for information modeling which gives several advantages to analyze and design complex systems: Completeness, Verifiability, Extensibility, and Maintainability [5]. DEVS has two kinds of models to represent systems. One is an Atomic Model (AM) and the other is a Coupled Model (CM) which can specify complex systems in a hierarchical way [6]. DEVS model processes an input event based on its state and condition, and it generates an output event and changes its state. Finally, it sets the time during which the model can stay in that state. An atomic DEVS model is defined by the following structure [6]: Formalism AM = X, Y, S, δ ext,δ int,λ,ta where: X is the set of input values, Y is the set of output values, S is the set of states, δ ext : Q X S is the external transition function, where Q = {(s, e) s S, 0 e ta(s)} is the total state set, e is the time elapsed since last transition, δ int : S S is the internal transition function, λ : S Y is the output function, ta : S R + 0, is the set positive reals bet. 0 and The behaviors of the atomic model are as follows: An atomic model can stay only in one state at any time The maximum time to stay in one state without external event is determined by ta(s) function When an atomic model is in a state (0 e ta(s)), it changes its state by δ ext if it gets an external event If possible remaining time in one state is passed, it generates output by λ and changes the state by δ int in in in2 M out in Coupled Model M2 out out2 Figure. Coupled DEVS model out Figure shows a coupled DEVS model. We implicitly use the port to couple the DEVS models. M and M2 are DEVS models. The M has two input ports ( in and in2 ) and one output port ( out ). The M2 has one input port ( in ) and two output ports ( out and out2 ). They are connected by input and output ports (e.g., out port of M is connected to in port of M2) internally, which is called Internal Coupling (IC). The M is connected by external input, in port of Coupled Model, to in port, which is called External Input Coupling (EIC). The M2 is connected to output port out of Coupled Model (e.g., out port of M2 is connected to out port of Coupled Model), which is called External Output Coupling (EOC). The DEVSim++ [5] is a C++ based DEVS simulation environment which is integrated with Microsoft Visual Studio.NET. It, therefore, provides the advantages of Objectoriented framework such as encapsulation, inheritance, etc. The DEVSim++ manages the simulation time, coordinates the event schedules, and provides APIs for simulation. 3 UML-based M&S Approach for Missioncritical Embedded System Development 3. Characteristics of Simulation Modeling The simulation modeling is simplification of real system to generate the behavior by specifying a set of instructions, rules, and equations to represent the structure and behavior of the system. The structural elements of a system include the components of the system and their interactions (e.g., input, output, and their connections). The behavioral elements include the sequence of the interactions, the timing constraint of the interactions, and the operation of each component. Therefore, the simulation modeling should provide the means of specifying the structure of a system, behavior of a system over time, and the mechanism for executing the instructions, rules, or equations. 3.2 Overview of the UML-based M&S Method To use the UML diagrams for simulation modeling, we constrain the SD and class diagram (CD) and adopt the Ziadi s approach [4] of synthesizing SMs from SDs to make it easy to transform the UML models into a simulation model which can be executed by a simulation engine.

3 STEP Domain Analysis & Simulation Modeling STEP 2 Synthesizing State Machine STEP 3 Model Transformation Constrained Class Diagram DEVS Structural Model Use Case Constrained Sequence Diagram State Machine DEVS Behavioral Model Synthesis Algorithm Time Event transformation Mapping Rule Mapping Rule Mapping Rule Figure 2. Overview of the UML-based M&S method We also define the mapping rules from SM and CD to simulation models. This mapping rules provide us the theoretical background for automatic model transformation which reduces the mistakes of developers and the overhead of too low-level specification work. Figure 2 illustrates the overview of the UML-based M&S method. We take three steps to develop a simulation model. First, we specify the system with a minimum set of modeling elements of UML to make the modeling process simple and efficient. We choose three UML diagrams: the Use Case (UC) diagram for requirements elicitation, the CD for specifying the structure of the system, and the SD with timing constraints for specifying the behavior of the system. Second, we synthesize the SMs from the SDs to specify the internal behavior of each component in the system, which makes the model transformation process clear and simple. We extend the algebraic approach of Ziadi by adding the timing constraints for simulation. Third, we transform the UML diagrams (CDs, CDs, and synthesized SMs) into a simulation model by using the mapping rules. 3.3 Domain Analysis & Simulation Modeling In domain analysis for simulation modeling, we have to concentrate on the requirements that the domain experts want to validate before real system is developed. We elicit the requirements with UCs, specify the inter-objects interactions with the constrained SDs, and describe the structure of the components with constrained CDs. A CD shows the static structure and the relationships between classes in the system [2]. The relationships can be association, dependence, specialization, package, etc. However, we don t need all the relationships in simulation modeling because simulation model is not for describing the detailed structure of a system, but mainly for generating input/output behaviors of interest. Therefore, we constrain the modelers to use only the association and composition relationships, which can represent the hierarchical structure of a system. We also need to distinguish classes which are directly executed by the simulation engine from supporting classes which are not. The supporting class can contain the specific algorithm for the system. For example, the ballistic calculation algorithm which is a supporting class is called by the class which is executed by the simulation engine. We define the CD for our purpose: Definition CD = C, SC, CR, AR where: C: asetof classes directly executed by the simulation engine, SC: a set of supporting classes, CR (C SC) (C SC): a set of composition relationships, AR (C SC) (C SC): a set of association relationships, A SD shows a dynamic collaboration and a sequence of message between a number of objects [2]. We extend the usage of SD in Ziadi s paper [4], which uses three operator (seq, alt, and loop), by adding the TimeEvent to explicitly specify the timing constraint among components of an embedded system. We only use relative time event to specify the behavior of a system, which is efficient because we can only consider the behavior of one object based on the external input and internal behavior and we can let the simulation engine take over the absolute time management. Definition 2 SD = E,,α,φ,A,I,TE where: E: a set of events, : a partial ordering imposed by lifelines and messages, α: an action name to an event, φ: a location (e.g., an object affected by the event) to an event, A: a set of actions (message emissions and receptions), I: a set of objects participating to the interaction, TE: a set of TimeEvents The TimeEvent specifies a point in time and the event occurs at the specified time [3]. For example, after(5sec) means the event occurs after 5 seconds. All the sending and receiving events should have TimeEvent, TE. If we don t specify the TE explicitly, the TE of the sending event is zero, which means the object sends out the message without taking any time. If the TE of the receiving event is infinity, it means the object waits the incoming event until the message is arrived. 3.4 Synthesizing SMs from SDs We extend the definition of the synthesizing algorithm of Ziadi s approach [4] to include the TimeEvent. While the SD captures interactions between a set of objects, the SM represents the internal behavior of a single object, which is essential to develop an executable simulation model. We follow the Ziadi s approach to synthesize the SM by combining basic SDs into one combined SD. The definition of the SM is as follows: Definition 3 SM = S, s 0,E,TE,A,δ,J where: S: a setofstates,s 0 : an initial state, E: a set of Events except TE, TE: a set of TimeEvents, A: a set of actions, δ S E TE A S : transition relation, (s,φ,te,a,s ): message emission labeled /a, (s,e,te,φ,s ): message reception labeled e, J S: a set of junction states

4 sd alt else Customer Coffee Sequence interaction Diagram{/} AvailableSignal () InsertCoin() PressButton() Coffee() Cancle() ReturnCoin() CoffeeMachine after(0.sec) CoffeeStateMachine statemachine Machine S S2 Insert Coin S3 } after(0.sec) /AvailableSignal PressButton S4 Cancle after(0sec) / Coffee S5 after(0sec) /ReturnCoin Figure 3. Synthesizing from SD to SM if I is not in CR if E is from external then X := E, EIC := I.C.E I.C.E else Y := E, EOC :=I.C.E I.C.E else IC := I.C.E I.C.E else AM := C Rule 3 Behavioral Trans(SM, M) - Input: SM - Output: M if δ of SM has message reception e then δ ext := e else δ int := a We also need to incorporate the TimeEvent into the Ziadi s synthesizing algorithm. If the message of a SD has a TimeEvent (e.g., after(0. sec) in Figure 3), the corresponding state of the SM has the same time value as the one in the SD. If TE is not explicitly specified and the message is receiving event, the corresponding state of the SM waits forever (TE := infinity) until the message is arrived but we will not represent the TE of infinity (e.g., after(infinity)) in SM for simplicity. And if TE is not explicitly specified and the message is sending event, the corresponding state of the SM has TE of zero (e.g., after(0 sec). This rule is defined as follows: Rule TE Trans(SD, SM) - Input: SD (sequence diagram with TimeEvent) - Output: SM (state machine with TimeEvent) if (TimeEvent in SD) TE in SM := a time value of TimeEvent else if (receiving event) TE in SM := infinity else if (sending event) TE in SM := 0 Figure 3 shows the example of synthesizing of coffee machine. All of the sending and receiving events are transformed to states and the TimeEvent of SD is transformed into TE of SM based on the Rule (). 3.5 Model Transformation As a final step, we transform the UML models into the structural and behavioral DEVS models to simulate using DEVSim++ simulation engine. Table shows the mapping table of UML diagrams to DEVS models. The Rule (2) and Rule (3) complement the Table. Rule 2 Structural Trans(CD, SD, CM) - Input: CD, SD - Output: CM if C is in CR if C is target then CM := C else AM := C 3.6 Validating Model Transformation The model transformation should keep the fundamental properties (i.e., termination, confluence, and behavioral equivalence) of the transformation process [7] for the transformed model to be validated. The termination means that the model transformation rule should be applied finitely. The transformation rules in our approach are basically one to one mapping except the class transformation. The number of rule application in the class transformation is less than total number of classes in the system because the Rule (2) is applied from target class (whole) to source class (part) sequentially through the composition relationship. Therefore, the transformation rules in our approach are applied finitely. The confluence means that the target model should be unique. The transformation rules in our approach keeps the confluence property because every rule in this approach is applied sequentially and each rule is mutually independent. The behavioral equivalence means the behavior of a source model is preserved in the transformed model. The behavior of DEVS model is described with the seven tuples of an atomic model, so if we can preserve the seven tuples, the behavior of a transformed model is equivalent with the source model. As shown in Table, every elements of SM is one to one mapped to atomic model of DEVS, so the behavioral elements of source model are preserved in the transformed model. Table. Mapping table from UML diagrams to DEVS UML Elements DEVS CD C CM, AM SD E CM X, Y, EIC, EOC, IC S, s 0, J S E X SM A AM Y δ δ ext,δ int TE ta

5 WarShip CD sd GenerateGunOrder 'GenerateGunOrder SD'{/} Target 0.. Radar GunOrderCalculator BattleShip MotionFilter Tracker Gun 4 Case Study Figure 4. CD of the system We applied the proposed approach to the patrol boat development project of Korea Navy [8]. The most important part of this project is developing the BCU which estimates the target position, predicts the future position of the target, and calculates the gun order. The BCU is a missioincritical real-time embedded system, which determines the accomplishment of the mission (function) of the system. We decided to take UML-based M&S approach to validate the requirements: the strict data processing timing among components, the architectural validity of the BCU, and the accuracy of the ballistic calculation algorithm. The domain experts have knowledge on the structure of the boat but they don t have enough knowledge on the simulation modeling and the ballistic calculation algorithm. Thus, the domain experts decided to apply our approach to develop simulation model and to work with experts group of ballistic algorithm. The project team was composed of one domain expert, two ballistic algorithm experts, and two simulation experts. The duration for simulation model development was one year. We will describe the project following the proposed three steps but some of the contents are changed and omitted because of the security problem. 4. Domain Analysis & Simulation Modeling In the domain analysis, we derived several UCs such as Get Target Data and FireMissile. We also elicited requirements such as the maximum tolerable miss rate of the ballistic algorithm and the data processing time interval (e.g., Radar scanning time interval, etc.). Figure 4 shows part of the CD which describes the architecture of the system. Figure 5 describes the SD which specifies the inter-object interactions and timing constraints of the Radar. The simulation model should represent this timing constraint exactly to evaluate the effects of the scanning interval on the hit ratio. The GunOrderCalculator calculates the gun order for intercepting the target based on the estimated target position data. We defined an interface for ballistic calculation algorithm which is modeled in supporting class and developed by another group. The simulation model provides the sim-..4 Target BattleShip Radar GunOrderCalculator Gun () Radar StateMachine statemachine WarShip :: StateMachine after(t sec) / Get after(0 sec)/ Estimated () () ShipData() after (t sec) SendEstimated Estimated() ShipData GunOrder() Figure 5. SD and the synthesized SM GetShipData {/} after(0 sec)/ ulated environments to run the algorithm before actually deploying the algorithm into the warship. Our approach enables us to work independently and reduces the communication burden by letting the domain experts specify the system using UML diagrams and algorithm developers work independently following the defined interface. 4.2 Synthesizing SMs Figure 5 shows the automatically synthesized SM, which specifies the behavior of each object with the TimeEvent. The transition which doesn t specify TimeEvent (e.g., after(t sec)) implies that the TimeEvent is infinity, which means it waits the input event forever. 4.3 Model Transformation Finally, the constrained UML models are transformed into the simulation models which are executed by DEVSim++. Figure 6 describes the high level view of the coupled model and the internal behavior of an atomic model. 5 Related Work Several approaches have performed to use the UML as simulation modeling tool. In [9], UML-RT (Real Time) and DEVS framework are introduced and the advantages and shortcomings of each model are analyzed. The main drawback of this approach is that there is no way to combine UML-RT and DEVS to reinforce their advantages. In [0], they introduce eight steps to make DEVS model using UML model. However, it is impossible to make DEVS model automatically because they need human decisions extensively to transform the model. In [], the formal

6 CoupledModel Target Battle Ship AtomicModel (ta()=t) ShipData Estimated Get (ta()=infinity) Radar Tracker... Motion Filter SendEstimated (ta()=0) Estimated ShipData (ta()=0) GunOrder Calculator Gun GunOrder GetShipData (ta()=infinity) We propose UML-based M&S method which uses UML2.0 as the requirements specification method as well as the simulation model development tool for a missioncritical embedded system. We defined constraints on UML diagrams to use them as a simulation modeling tool, extended the Ziadi s synthesizing algorithm to include the TimeEvent, and defined the transformation rules from UML diagrams to DEVS models for automatic model transformation. The contribution of our approach is that it provides efficient way of applying M&S to the development of a mission-critical embedded system. Out approach alleviates the burden of domain experts as well as simulation model developers by using the UML as the communication method and simulation modeling tool. This makes it possible to concentrate on their own work (e.g., domain experts work on system analysis, ballistic algorithm developers work on algorithm development, simulation developers work on simulation model development) by providing a common working environment. Our approach also provides a theoretical base for automatic simulation model generation, which can avoid model developer s mistakes. As a future work, we are going to use more expression power (e.g., inheritance) of UML2.0 and validate our model transformation rules more formally. We also plan to develop an automatic model transformation tool from UML to DEVS. 7 Acknowledgements This work was supported by the Ministry of Information & Communication, Korea, under the Information Technology Research Center (ITRC) Support Program. Figure 6. Transformed atomic and coupled model transformation of timed input/output automata into simulation model (DEVS) is provided. However, the timed automata is also hard to communicate and make simulation model. Borland et al. [2] deals with translating hierarchical statecharts into DEVS, but we don t need hierarchical statecharts because we use CD to represent hierarchical structure, which reduces the transformation complexity. In model transformation domain, there are two mainstreams of researches. One is model transformation using relationship of the source model and target model in metamodel level [3]. This approach is useful to make source code using UML model, but it doesn t provide the simulation modeling support. The other is model transformation using graph grammar [4, 7]. This approach is mainly for visual model transformation. 6 Conclusion and Future Work References [] Department of Defense, DoD Acquisition Guidebook V, [2] H. Eriksson, M. Penker, B. Lyons, and D. Fado, UML 2 Toolkit, Wiley Publishing, IN, [3] UML2.0 Superstructure Specification, Version 2.0, ptc/ , [4] T. Ziadi, L. Helouet, and J. Jezequel, Revisiting Statechart Synthesis with an Algebraic Approach, 26th International Conference on Software Engineering (ICSE 04), pp , [5] TagGon Kim, DEVSimHLA v2.2.0 Developer s Manual, download.htm, Korea Advanced Institute of Science and Technology (KAIST), [6] B. Zeigler, H. Pracehofer, and TagGon Kim, Theory of Modeling and Simulation, Second Edition, Academic Press, New York, 2000 [7] J. Lara and G. Taentzer, Automated Model Transformation and its Validation Using AToM 3 and AGG, LNCS No. 2980, pp , [8] K. Choi, D. Bae, J. Noh, and E. Kim, Design Simulation Framework for Weapon System of Warship, The 5th Seminar on Naval Weapon Systems Development, Agency for Defense Development, [9] D. Huang and H. Sarjoughian, Software and Simulation Modeling for Real-time Software-intensive System, Proceedings of the Eighth IEEE International Symposium on Distributed Simulation and Real-Time Applications (DS-RT04), [0] S. Hong and T. Kim, Embedding UML Subset into Objectoriented DEVS Modeling Process, Proceedigs of Summer Computer Simulation Conference, pages 6-66, San Jose, CA, July [] N. Giambiasi, From Timed Automata to DEVS Models, Proceedings of the 2003 Winter Simulation Conference, 2003 [2] S. Borland and H. Vangheluwe, Transforming Statecharts to DEVS, Society for Modeling and Simulation International, 2003 [3] D. Milicev, Automatic Model Transformations using Extended UML Object Diagrams in Modeling Environments, IEEE Transactions on Software Engineering, V.28, No.4, pp43-43, 2002 [4] G. Rozenberg, Handbook of Graph Grammars and Computing by Graph Transformations: Foundations, World Scientific, 997