The Pennsylvania State University. The Graduate School. Harold and Inge Marcus Department of Industrial and Manufacturing Engineering

Transcription

1 The Pennsylvania State University The Graduate School Harold and Inge Marcus Department of Industrial and Manufacturing Engineering PiDES: A FORMALISM FOR COMPLEX ADAPTIVE DISCRETE EVENT SIMULATION A Dissertation in Industrial Engineering by Jianrui Wang 009 Jianrui Wang Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy May 009

2 The dissertation of Jianrui Wang was reviewed and approved* by the following: ii Richard A. Wysk Professor of Industrial Engineering and Leonhard Chair in Engineering Dissertation Advisor Chair of Committee Sanjay Joshi Professor of Industrial Engineering Akhil Kumar Professor of Supply Chain and Information Systems Vittal Prabhu Professor of Industrial Engineering Ling Rothrock Professor of Industrial Engineering Richard J. Koubek Professor of Industrial Engineering Head of the Harold and Inge Marcus Department of Industrial and Manufacturing Engineering *Signatures are on file in the Graduate School

3 ABSTRACT iii Formalism is a powerful tool for precisely defining and analyzing Discrete Event Simulation (DES). Many formalisms such as FSA GSMP DEVS Petri Net SPADE etc. have been proposed. These formalisms have proved useful for modeling individual systems. However they become ineffective for some large-scale systems. For instance modern simulation federations often involve many participants which are geographically distributed. Each participant may implement federates using different technologies. In addition existing federates may retire from the federation while new federates may enter into the federation. This may require a change in the control flow of the simulation to reflect a frequently changing business model. Therefore modern simulation federations have three unique characteristics: heterogeneous distributed and adaptive. As a result formalisms for modern simulations should also provide companion semantics such as: a) compositing heterogeneous systems into larger ones; b) coordinating distributed systems; and c) evolving existing systems into new ones without interrupting the current executions. This thesis proposes a new formalism called PiDES. It develops formal models for individual DES federates and runtime infrastructure based on stochastic π- calculus and High Level Architecture. In order to demonstrate the feasibility and potential benefits of the proposed formalism a language definition and an interpreter of PiDES along with a prototype implementation of PiDES-RTI are also developed. The major contribution of this research is to provide a unified approach to modeling and coordinating complex adaptive simulation systems with rigorous semantics high reconfigurability and seamless scalability.

4 TABLE OF CONTENTS iv LIST OF TABLES...ix ACKNOWLEDGEMENTS...x Chapter Introduction.... Background.... Motivation Research Objectives Research Scope Dissertation Overview...5 Chapter Literature Review...7. Formalisms for Discrete Event Simulation...7. Runtime Infrastructure for Parallel and Distributed Simulation....3 Discrete Event Simulation World Views and Software Implementation Chapter Summary...7 Chapter 3 Theoretical Foundation General Theory of Discrete Event Simulation π-calculus Classical π-calculus Stochastic π-calculus High Level Architecture Federations HLA Information Model HLA RTI HLA Rules Chapter Summary...33 Chapter 4 PiDES The Architecture of PiDES A PiDES World View of Discrete Event Systems PiDES Process Meta-Model PiDES Interaction Meta-Model PiDES Syntax and Semantics Stochastic Action Probabilistic Choice Coordination Context PiDES Process (Federate)...45

5 4..5 PiDES Operation Semantics Implicit Time Constraints on Receive Actions WAIT Operation PROB Operation RACE Operation Properties of PiDES Basic Definitions Name Co-Name Bound Name Free Name Transit Name Published Event Active Published Event Inactive Published Event Subscribed Event Active Subscribed Event Inactive Subscribed Event Reaction Stage Transition Open Process Closed Process Interface Congruence Basic Properties Liveness Deadlock Dead Terminated Blocking Validation A Case Study System Description System Models System Dynamics Deadlock Detection and Model Checking Summary...68 v Chapter 5 PiDES-RTI A Formal Model for PiDES Federation A Hierarchical Architecture for DES Federation Runtime Infrastructure Formal Models for HLA RTI Services Federation Management Declaration Management Time Management...79

6 5.4 A Case Study System Description System Models System Dynamics Federation Execution Creation Federates Join the Federation Execution Federates Publish/Subscribe Events Normal Operations Federates Resign from the Federation Execution Federation Execution Shutdown Deadlock Summary...93 Chapter 6 PiDES Toolbox Overview of π-calculus Tools π-calculus Model Checking Tools Logic Formula for Model Checking A Framework for Checking PiDES Models General Approaches for PiDES Model Checking Basic Property Formula Reachability Blocking Liveness Through Deadlock Model Verification Formula Case Study Summary...05 Chapter 7 Implementation Architecture PiDES Language Compilation Unit Federation Declaration Federate Declaration Statement Declaration Process Definition PiDES Interpreter Runtime Environment Case Study Summary...7 Chapter 8 Research Contribution and Conclusions...8 vi

7 8. Research Contributions Research Impact Possible Extensions Dissertation Contributions... Bibliography...3 Appendix A PiDES Language Grammar in BNF...6 TOKENS...6 NON-TERMINALS...7 Appendix B PiDES Runtime Environment Files...30 vii

8 LIST OF FIGURES viii Figure -: Interfaces of HLA RTI...3 Figure -: Service Oriented Architecture (W3C 00b)...5 Figure 3-: Structure of a federation...8 Figure 3-: Interfaces between RTI and federates...3 Figure 4-: PiDES world view of DES...35 Figure 4-: PiDES process meta-model...36 Figure 4-3: Coordination Context meta-model...37 Figure 4-4: Design a sequential control in CCC...38 Figure 4-5: Interaction Meta-Model...39 Figure 4-6: A two-machine two-part and one-robot FMS (Chang et al. 998)...60 Figure 5-: A hierarchical architecture RTI...7 Figure 5-: Event declarations...87 Figure 6-: The HAL Online Services...0 Figure 6-: A Deadlock Scenarios...0 Figure 6-3: Deadlock Free Scenario...04 Figure 7-: PiDES Implementation Architecture...07 Figure 7-: PiDES Interpreter... Figure 7-3: PiDES Processes Class Diagram... Figure 7-4: The FMS Case Java Code Structure...4 Figure 7-5: Running Demo Case...6

9 LIST OF TABLES ix Table 4-: System initial state...63 Table 4-: System state after performing nr...64 Table 4-3: System state after performing a...65 Table 4-4: System state after performing ar...65 Table 4-5: System state after performing b...66 Table 5-: System initial state...88 Table 5-: System state...89 Table 5-3: System state Table 5-4: System state Table 7-: Declaration Syntax...08 Table 7-: Federation Declaration Syntax...08 Table 7-3: PiDES ASCII Encoding...09 Table 7-4: Process Syntax...0 Table 7-5: The FMS Case Code...3 Table 7-6: FMS Case Execution Output...5

10 ACKNOWLEDGEMENTS x I would like to take this opportunity to express my gratitude and respect to my advisor Dr. Richard A. Wysk. Without his support and supervision this thesis could not have been accomplished. To me he is not only my supervisor in my research but also my mentor for the years to come. I am deeply grateful to Dr. Akhil Kumar advisor of my master degree at Smeal College of Business and member of my doctoral committee. He opened the door to academic research for me and become a mentor since the day I knew him. I thank Dr. Sanjay Joshi Dr. Vittal Prabhu and Dr. Ling Rothrock for being or having been a part of my doctoral committee. I appreciate their time and comments on my research. I heartily thank Dr. Albert Jones at NIST for his insightful suggestion of using π-calculus to model complex systems. I thank Dr. Henry H. Bi Dr. Dennis K. J. Lin Dr. John Spychalski and Dr. John Eugene (Gene) Tyworth for their enlightening teaching and discussions with me on the research. I also thank the faculty and staff in the Department of Industrial and Manufacturing Engineering at the Penn State University for their excellent teaching and services. I also should express my thanks to many of my friends at Penn State in particular Dr. Jing Fu Dr. Rong Pan Dr. Kaizhi Tang Mr. Zhi Yang Dr. Heng Zhao and Dr. Hao Zhu. Finally I thank to the members of my family my father my mother my brother my wife and my two sons for their endless love patient and support.

11 xi To my wife Jun and my sons Bill and Leonard

12 Chapter Introduction. Background Discrete Event Simulation (DES) is a powerful tool for modeling and controlling complex systems (Wysk et al. 99). In order to precisely capture the target system a specification the process of describing the target system and its desired properties is often developed. In general formal specifications also known as formalisms or formal methods use languages based on mathematical syntax and semantics to define the functional behavior timing behavior performance characteristics internal structures and other specifications of target systems (Clarke and Wing 996). In the DES arena many formalisms have been proposed such as: Generalized Semi-Markov Process (GSMP)(Glynn 989) Finite State Automata (FSA) (Ramadge and Wonham 989; Smith et al. 003) Discrete Event System Specification (DEVS) (Zeigler et al. 000) Petri Net (Zhou and Venkatesh 999) and stochastic process algebra (D Argenio et al. 998; Harrison and Strulo 000). Although the formalisms listed above have proved useful for modeling individual systems they become ineffective for some large scale complex adaptive systems. For instance modern simulation federations often involve multiple participants which are geographically distributed. Each modeling participant may implement their simulation federates using different software technologies. In addition existing federates may retire

13 from the federation while new federates may enter into the federation. This may require a control flow change of the simulation in order to reflect a frequently changing business model. Therefore modern simulation federations have three unique characteristics: a) heterogeneous b) distributed and c) adaptive. As a result formalisms for modern simulations should also provide companion semantics such as: a) compositing heterogenic systems into larger ones; b) coordinating distributed systems; and c) dynamically evolving existing systems into new ones. Unfortunately GSMP and FSA-based formalisms become quite inefficient for large systems because of the exponential growth of total states. In addition although federating multiple FSA models (a.k.a. composition) can be done through constructing productions of FSAs the process is difficult and requires a significant understanding of computation theory. Furthermore FSA lacks a mechanism to handle currency. A Petri Net based formalism is designed to model concurrent systems with rigorous mathematical foundations however it has three limitations: ) Like FSAs compositing Petri Net models is a difficult process. ) Petri Nets do not have a built-in re-configurability the models are statically linked by transitions and any changes may require substantial validation work. 3) Petri Nets do not provide unified semantics to model both internal and external behavior. The capability to model both internal and external behaviors is important for inter-organization systems such as supply chain systems. In such a system with multiple ownerships information sharing (external behaviors) and information hiding (internal behaviors) become critical.

14 DEVS supports composition through coupled-devs but is not a fully adaptive 3 formalism. Process algebra-based formalisms like SPADE (Harrison and Strulo 000) and (D Argenio et al. 998) may be improved to support large complex adaptive simulation systems however they are relatively new and need further study. In general the simulation purposes of the target systems fall into two classes: quantitative analysis and qualitative analysis. For quantitative analysis the emphasis is often centered on a key performance index (i.e. waiting time queue length and resource utilization) of the systems thus stochastic models such as GSMP become very useful. For qualitative analysis the focus is the behavior of the systems. Therefore it is often more important than studying how the components of the systems interact with each other. As a result logical models with little or no quantitative properties such as FSA DEVS Petri Net and process algebra become quite popular. However for large complex adaptive simulation systems composition and coordination become the dominant issues. Recently π-calculus (Milner 999) has emerged as a powerful formalism to model distributed and mobile systems. π-calculus provides an innovative perspective to deal with complex systems systems as processes. Systems are no longer viewed as static linked components. Instead systems are treated as a set of concurrent interactive and evolving processes. Thus π-calculus provides reconfigurability and strong compositionality. In addition π-calculus offers mechanisms for modeling both internal and external behaviors simultaneously. In this thesis a new DES formalism called PiDES is developed. The formalism consists of two parts:

15 ) A set of formal models for individual DES federates based on stochastic π- 4 calculus. ) A set of formal models for simulation Runtime Infrastructure (RTI) based on High Level Architecture (HLA). The major contribution of this research is to provide a unified approach to modeling and coordinating large complex simulation systems with rigorous semantics high re-configurability and seamless scalability.. Motivation This research is motivated by the demand of formalisms for complex adaptive simulation systems. The proposed formalism PiDES is a unified formal approach for modeling both federates and runtime infrastructure. PiDES provides rigorous semantics and powerful coordination mechanisms for distributed discrete event systems..3 Research Objectives This thesis contains two objectives: (a) to develop a complete set of formal models based on π-calculus called PiDES for modeling DES federates; and (b) to develop formal coordination models for parallel and distributed simulation systems based on HLA called PiDES-RTI. In order to demonstrate the feasibility and potential benefits of the proposed theory an interpreter of PiDES and a prototype implementation of PiDES-RTI are also developed.

16 .4 Research Scope 5 To limit the scope and to obtain a tangible research goal the following assumptions and constraints are applied:. Only Discrete Event Simulation is considered.. The PiDES formalism is aimed to achieve the same modeling capability as GSMP. 3. The PiDES-RTI formalism is limited to a subset of services defined by HLA. Only essential parts of federation management declaration management and time management are discussed. 4. The implementation focuses on the PiDES interpreter and runtime support for PiDES. The prototype is for demonstration only. It is not intended to be used in production. Therefore some features such as exception handling and performance optimization may be omitted..5 Dissertation Overview The remainder of the dissertation is organized as follows: Chapter Literature Review examines the related literature in order to address the issues that affect this work. Three categories of research are discussed: formal methods runtime infrastructure and software implementation. Chapter 3 Theoretical Foundation introduces the general theory of discrete event simulation π-calculus (classical and stochastic extension) and High Level Architecture.

17 Chapters 4 through 7 develop the main work of this thesis. First Chapter 4 6 PiDES presents the formalism for individual simulation federates. Second Chapter 5 PiDES-RTI develops the formalism Runtime Infrastructure based on HLA. Then Chapter 6 PiDES Toolbox presents a framework of using existing tools for PiDES model checking. Finally Chapter 7 Implementation illustrates the PiDES interpreter and runtime support. Chapter 8 Research Contribution and Conclusions concludes this thesis with a discussion of the contributions to the research and possible future extensions to this work.

18 Chapter Literature Review This chapter reviews literature related to this thesis. First a brief review of popular formalisms for discrete event simulation is presented in Section.. Then Section. discusses the runtime infrastructure for parallel and distributed simulation systems. Next Section.3 reviews world views concerning discrete event simulation as well as software implementation of discrete event simulation systems. Section.4 concludes the chapter with a short discussion of the capabilities and limitations of existing formalisms and runtime infrastructures.. Formalisms for Discrete Event Simulation Formalisms also known as formal methods or formal specifications are a class of methodologies used to accurately model the target systems. A formalism is a systematic technique using mathematic equations and rules to describe physical systems. There are many formal methods that generally fall into four categories: model-based logic statebased and algebraic (Clarke and Wing 996). In the DES context the most popular formalisms are: Stochastic Models Finite State Machine (FSM) or Finite State Automaton (FSA) Petri Nets and Process Algebra. Stochastic Models FSA and Petri Net are state-based formalisms. A Process Algebra is a class of algebraic formal methods

19 including Communicating Sequential Processes (CSP) (Hoare 985) Calculus of 8 Communicating Systems (CCS) (Milner 989) π-calculus (Milner 999) and others. The wildly accepted stochastic model of DES is a Generalized Semi-Markov Process (GSMP) (Glynn 989). A GSMP model is a 6-tuple (Eq..): GSMP = (S s 0 E P C F) (.) where: S is a set of all the states. s 0 is the initial state s 0 S. E is the set of all events. P: s i e s i+ is a set of probability of jumping from state s i to s i+ triggered by event e e E. C is a set of clocks; each clock corresponds to a state s and an event e. It continues to count down to zero. F is the probability function of scheduling a new event e in state s given the previous state is s and the triggered event is e. The commonly used FSA in practice is a Deterministic Finite Automaton (DFA) (Hopcroft et al. 00) and can be defined as a 5-tuple (Eq..): M = (Σ Q q 0 δ F) (.) where: Σ is the input alphabet (a finite non-empty set of symbols). Q is a finite non-empty set of states.

20 9 q 0 is an initial state an element of Q. δ is the state transition function: δ = Q Σ Q. F is the set of final states: F Q. In order to model DES classical automaton is extended to Timed Automaton (Alur and Dill 994). A timed automaton is a 6-tuple (Eq..3): TM = (Σ Q q 0 δ F V) (.3) where V = {v i : i Q } is a clock structure. FSA and its variations such as Moore and Mealy Machine (Hopcroft et al. 00) have been frequently used to model simulations of manufacturing systems. This research can be classified into two categories: modeling the behavior of a manufacturing cell and specifying the processing and communication protocols of manufacturing cells. A more detailed literature review of using FSAs can be found in (Smith 003). Another well-known FSA-based formalism of DES is Discrete Event System Specification (DEVS) (Zeigler et al. 000). The classical DEVS is defined as a 7- tuple (Eq..4): DEVS = (I O S δ ext δ int λ ta) (.4) where: I is the input set. O is the set of outputs. S is the set of sequential states. δ ext is the external state transition function: δ ext = Q I S.

21 0 δ int is the internal state transition function: δ int = S S. λ is the output function: λ = S Y. ta is the time advance function: ta = S R 0 +. Q is the set of all states: Q = { ( s t) s S 0 < t < ta(s) }. A Petri Net is a graphical and mathematical representation of discrete distributed systems. It depicts the structure of a distributed system as a directed bipartite graph with annotations: place nodes transition nodes and directed arcs connecting places with transitions. Petri Nets have been widely used in modeling and analyzing discrete event systems such as DES Flexible Manufacturing Systems (FMS) and Supply Chain Systems for more than 0 years. More details of modeling DES using Petri Net can be found in (Cassandras 993; Zhou and Venkatesh 999). A Petri Net Graph (PNG) is defined as a 4-tuple (Eq..5): PNG = (P T A w) (.5) where: P is the finite set of places (usually represented as a circle in the graph) T is the finite set of transitions (usually represented as a square box in the graph) A is the set of arcs from places to transitions or from transitions to places in the graph: A ( P T ) ( T P). w is the weight function on the arcs: w = A { 3... }. In order to model DES classical Petri Net is extended to a Timed Petri Net. A timed Petri Net is a 6-tuple (Eq..6):

22 TPNG = (P T A w x V) (.6) where: (P T A w x) is a marked Petri Net. V is a clock structure: V = {v i : i Td }. T d is a set of timed transactions: T d T. In the late 980s with the advancement of mobile and concurrent computing CCS and its successor π-calculus become popular formalism for modeling large and complex systems. A π-calculus process is defined as follows (Eq..7): m π i. Pi Pi νap! P i= n i= (.7) Where m π. i= n P i i= i P i : Only one of π i.p i can be activated. : All of the P i s are activated. νa P: The scope of name a is restricted to P.!P : Replication. π = x ( y) x < y > τ : o x ( y) : receives y through x; o x < y > : sends y through x; and o τ is an unobserved action.

23 Several DES formalisms based on π-calculus or its precedent CCS were proposed such as SPADE (Harrison and Strulo 000) and (D Argenio et al. 998). These approaches extend the classical CCS or π-calculus with some stochastic constructs a.k.a. stochastic process calculus (Priami 995).. Runtime Infrastructure for Parallel and Distributed Simulation The substantial computation power required by simulation fostered the research of Parallel and Distributed Simulation Systems (PDSS) (Fujimoto 00). PDSS delivers more power by running simulations on multiple processors or networked computers than a single processor computer. High Level Architecture (HLA) is the most well-known and adopted framework for PDSS (IEEE et al. 000). HLA has been designed to facilitate interoperability among simulations and to promote reuse of simulations. The integrated distributed simulation system is called as Federation and the participant simulations are called as Federates. HLA is composed of three major components: HLA rules: A set of ten basic rules that together describe the general principles defining HLA (IEEE et al. 000). HLA interface specification: A description of functional interfaces between simulations and runtime infrastructure (IEEE et al. 00a). HLA Object Model Template (OMT): A specification of the common format and structure for describing HLA object models(ieee et al. 00b).

24 HLA defines the architecture of a RTI. As can be seen from Figure - any 3 communication between two federates goes through RTI. RTI provides an interface call RTIambassador to federates. Thus any communication from a federate is sent to RTIambassador. Similarly federate provides an interface called FederateAmbassador and RTI always sends communication through FederateAmbassador to a federate. Federate Federate FederateAmbassador FederateAmbassador RTIambassador RTI Figure -: Interfaces of HLA RTI In recent years Service Oriented Architecture (SOA) (OASIS 006a; W3C 00b) and Grid Computing (Plaszczak and Wellner 006) have become the preferred infrastructure for integrating heterogeneous systems and coordination distributed systems. W3C defines a service as an abstract resource that represents a capability of performing tasks which represents a coherent functionality from the point of view of provider entities and requester entities(w3c 00b). SOA is a form of distributed systems architecture of loosely coupled systems built on Web Services (W3C 00a). The key specifications used by Web services include: a) extensible Markup Language (XML) (W3C 00a); b) Simple Object Access Protocol (SOAP) an XML-based protocol for communication (W3C 003); and

25 4 c) Web Services Description Language (WSDL) an XML-based language used to describe services (W3C 00b). Figure - shows a typical paradigm of SOA. As shown in the figure SOA consists of three components: service provider service requester and discovery agency. A service provider publishes services described in WSDL on some discovery agencies. The discovery agencies provide registries based on Universal Description Discovery and Integration (UDDI) (OASIS 004) which enable service requesters to search for services just like looking for phone numbers on Yellow Book (YellowBook 006). If the service requester finds the services it wants it may choose to use the services (called binding). From that point a direct communication between the service provider and the service requester is built. The communication between these three components is through SOAP. Grid Computing is another form of distributed computing using disparate resources. OASIS defines a resource as a logical entity which is identifiable has a set of zero or more properties described in XML infoset and may have lifecycle (OASIS 006b). There are two types of grids: a) compute grids which emphasize the shared use of computational resources; and b) data grids which support federation integration and mining of data resources. Recently the trend is to standardize and unify SOA Web Services and Grid Computing because of the considerable overlap among them (Srinivasan and Treadwell 005).

26 5 Figure -: Service Oriented Architecture (W3C 00b) The fast growth of SOA and Grid Computing provide alternative ways to design and implement PDSS. Brutzman and Tolk proposed the Extensible Modeling and Simulation Framework (XMSF) to build distributed modeling and simulation applications based on Web Services (Brutzman and Tolk 003). Tsai et al. developed a service-oriented modeling and simulation framework for rapid development of distributed applications (Tsai et al. 006). Other researchers presented approaches which implement HLA on Grid Computing (Chen et al. 006; Xie et al. 005). Since SOA and Grid computing offer all the functionalities available in HLA with additional capabilities and strong industry support Simulation Interoperability Standards Organization (SISO) is working on a standard of SOA-enabled HLA (SISO 008).

27 .3 Discrete Event Simulation World Views and Software Implementation 6 There are three popular world view of DES(Cota and Sargent 99): event scheduling world view activity scanning world view and process interaction world view. Process interaction world view models each activity as a process. It works well with modern computer systems which support multiple threading and parallel computing. In addition the code written under process interaction world view is more elegant and easier to maintain. Therefore it is the most popular world view (Matloff 006) and is adopted (with some modifications) by many commercial simulation software (Cassandras 993; Schriber and Brunner 005). Although they vary from one to another DES software based on process interaction world view often share the following common components (Cassandras 993; Schriber and Brunner 005):. Entity: or load is the object being processed. e.g. a piece of the part in a flexible manufacturing system.. Attribute: information which describes an individual entity. 3. Event: a reflection of a change of state in the system. 4. Function: an action performed on an entity. There are two types of functions: logical function (without time delay) and time delay functions. 5. Resource: objects providing service to entities (e.g. machines in a manufacturing system).

28 6. Queue: a set of entities or events with some common characteristics such as 7 waiting for the use of a resource. There are several types of queues: active entity queue current event queue future event queue delay entity queue etc..4 Chapter Summary DES is a promising technology for modeling and analyzing large complex systems such as supply chain systems. Formal methods such as GSMP FSA Petri Nets and π-calculus provide rigorous semantics to describe complex systems. They become very useful for modeling verifying and analyzing DES systems. The capabilities of these formalisms are not equal. GSMP and FSA can be difficult when used to model large systems due to state explosion and non-currency support. Petri Nets can handle currency well but lack the capability of re-configuration. π-calculus so far is the most powerful formal method which provides the capabilities of re-configurability and scalability needed by modern complex systems. The substantial computing power required by large DES systems has fostered the study of PDSS. HLA is thus far the most successful standard to support PDSS. Recently SOA and Grid Computing have emerged as preferred infrastructures for integrating heterogeneous systems and coordinating distributed systems. However the HLA standard only defines software architecture not a rigorous specification of PDSS. Therefore model analysis and verification of HLA systems is often difficult.

29 The world view is very important to the design and implementation of a DES. 8 Process interaction world view is the most popular world view and has been adopted by most commercial DES software. In the next chapter the theoretical foundation of this thesis the π-calculus and High Level Architecture are presented in detail.

30 Chapter 3 Theoretical Foundation This chapter introduces the systems theory and π-calculus fundamentals used in this thesis. First Section 3. briefly introduces the general theory of discrete event simulation. Special attention is given to the concept of stochastic and time modeling. Section 3. presents π-calculus including the original π-calculus invented by Milner et al. in 990s and the contemporary studies of stochastic π-calculus. Section 3.3 presents the basics of High Level Architecture. Finally Section 3.4 concludes the chapter with a short summary of the above theories. 3. General Theory of Discrete Event Simulation Discrete Event Simulation (DES) is a simulation perspective. In DES the operation of a system is represented as a series of chronological events. The system evolves from one state to the next state driven by a stochastic event. A DES model often has the following characteristics: Discrete state. The system consists of a set of discrete states. At any time it resides in one state and then may jump to another state. Discrete event. State change can only happen if an event is fired. Events occur in a discrete time way. Dynamic: The system evolves as time goes on.

31 0 Stochastic. The occurrence of events and changes of states may be random. In DES modeling a stochastic clock structure is used to model the stochastic and dynamic characteristics of DES. A stochastic clock structure consists of two substructures: a probability structure and a clock structure. The first structure is used to model randomness that is how to represent a random number in the DES model. The second structure is used to model the evolution of time. A probability structure is a sequence of random values (probabilities). A random value is often defined as a symbolic function as shown in Eq. 3.: σ( f p) = f p (3.) Where f is a probability distribution function (pdf) it samples a random number and passes the value to p. Thus a probability structure can be defined as Eq. 3.: P = {p p p 3 } (3.) A clock is a self counting down function starting from value t. A clock is exhausted when it reaches 0. The definition of a clock is shown in Eq. 3.3: Clock = λ(t) (3.3) A clock structure is a set of timed sequences. It is often associated with an event set. A typical definition of clock structure is shown in Eq. 3.4: V = {(e v) : e E } (3.4)

32 where E is the set of all events and v is a vector of clocks. Once a clock (v i ) is assigned to an event (e i ) it starts to count down. When the clock reaches 0 an associated event is fired. Thus a stochastic event can be represented in Eq. 3.5: [f p](e p): e E (3.5) Thus a stochastic clock structure is defined as Eq. 3.6: G = { G : e E f F} (3.6) e f Where E is the set of events F is the set of all pdf s and G ef is a vector of clock values. More details for modeling stochastic and clock structure can be found in (Alur and Dill 994; Cassandras 993; Glynn 989; Zhou and Venkatesh 999). 3. π-calculus This section introduces the theoretical foundation of PiDES the classical theory of π-calculus developed by Milner et al. (Milner 999) and stochastic π-calculus proposed by other researchers. 3.. Classical π-calculus In π-calculus everything is either a process or a name. A process is a computational unit running parallel to other processes. A process may also contain many independent sub-processes. Two processes can interact by exchanging a message or data

33 on a channel. A channel or a message is often denoted as a name. A name can also be a pronoun (similar to variable names or pointers in programming languages) of a process. The interactions in π-calculus are represented as a prefix π (Eq. 3.7): π = x ( y) x < y > τ (3.7) There are three types of actions: x ( y) : called receive action. It receives name y through channel x. x < y > : called send action. It sends y through x. τ: called internal action. It is an unobserved action which occurs inside a process. The simplest process is a Sequence Process. All components (i.e. sub-processes) in a sequence process are conducted in a sequential way. A sequence process can be recursively defined in Eq. 3.8: P = π.p 0 (3.8) where 0 is an inert process meaning no further action. Process π.p is also called guarded process because P is not enabled until π is performed. In general a π- calculus process can be one of the following four processes: ) Summation Process. A summation process is a set of sub-processes of which only one sub-process will be performed and all others are discarded. The choice is non-deterministic. ) Composition Process. A composition process is also a set of sub-processes; however all the sub-processes are running concurrently.

34 3 3) Restriction Process. A restriction process is a regular π -calculus process with additional construct defining the scope limitation of a name. Restricting a name to a process is semantically equivalent to creating a new name that is dedicated to a specified process. 4) Replication Process. A replication process is defined as a process that repeats a process infinitely. The syntax of a π-calculus process is defined is shown in Eq. 3.9: m i= n M i Pi νap! P i= (3.9) Where: M i ( i m) is a sequence process. m M i i= is a summation process only one of the sub-processes M i s ( i m) will be performed and the others are void. The choice is nondeterministic. n P i i= is a composition process. All the sub-processes P i s are activated. νa P is a restriction process. The scope of name a is restricted to P.!P is a replication process. In the above name a in the restriction process (νa P) is called a bound name. There are two ways to bind a name: a) by restriction prefix (i.e. νa P binds a to P) and b) by receive action (i.e. x(y).p binds y to P). If a name is not bound then it is a free name. For example name x and y in process x < y > are both free names. Substituting a bound

35 4 name with a fresh name is called an α-conversion. From a systems modeling perspective applying an α-conversion to a process results in an identical process. The formal definition of α-conversion is shown in Eq x( y). P = ν xq = x( z). P{ z / y} νy. Q{ y / x} (3.0) where: z is a bound name of P. y is a bound name of Q. The concepts of free names and bound names can be used to define the boundaries of modules in a system and therefore are very useful for building large systems. In order to perform an interaction between two processes the following conditions must hold: ) One process must conduct a send action. ) The other process must perform a receive action. 3) The two actions must act on the same channel. 4) The shared channel must be a free name in both processes. The dynamics of a process are formalized by a set of reduction rules. We say that a process P reduces to a process Q written as P Q if P contains two parallel subprocesses that interact with each other then P evolves Q. The five basic reduction rules are shown in Eq. 3.:

36 5 TAU τ. P + M P REACT ( x( y). P + M ) ( x( z). Q + N ) P{ z / y} Q PAR P P' P Q P' Q (3.) RES P P' νxp νxp' STRUCT P P' P Q P' Q' P' Q' TAU. A summation process τ.p+m evolves to P by performing an internal transition τ. The inactive component (M) is discarded. REACT. A composition process conducts reduction through an interaction between two components sharing the same channel name (one component send a name and the other receives a name through the same channel). PAR. If a process can evolve from P to P then any composition process that has P as a direct composition component can perform a reduction. RES. Restricting a name does not affect internal reductions of a process. STRUCT. Two structural congruence processes (Milner 999) have the same reduction behavior. It is important to determine if two processes are equivalent. There are many equivalence relationships. However behavior equivalence is the most important in system modeling. π-calculus provides two tools: bisimulation and structural congruence (Milner 999). A bisimulation is a symmetric relationship between two processes where one can simulate the behavior of another step by step and vice versa. In general two processes are considered equivalent if they can bisimulate each other. Congruence is a relationship between two processes P and Q if and only if that P congruence to Q also means C[P] congruence to C[Q] where C[] is process context defined in Eq. 3.:

37 6 C = [] π. C + M νac C P P C (3.) In practice structural congruence is obtained by applying any times of α- conversion as shown in Eq. 3.0 and structural congruence rules defined in Eq P Q Q P ( P Q) S P ( Q S) ν xp Q νx( P Q) (3.3)! P P! P P + Q Q + P One important application of bisimulation and structural congruence is that any process can be converted into a standard form of a restricted composition process shown in Eq P ν a La )( M L M! Q L! Q ) (3.4) ( k m n where all M i s are non-empty summation process and Q i s are also standard forms. More advanced treatments of π-calculus can be found in literature (Milner 989; 999; Sangiorgi and Walker 00). 3.. Stochastic π-calculus The classical π-calculus is synchronized. That is all transactions and reactions occur instantly without any delay. In addition the only non-deterministic construct in classical π-calculus summation implies uniform probability distribution. Recently several stochastic extensions have been proposed to handle probability and time duration

38 7 (D'Argenio and Katoen 005; D Argenio et al. 998; Harrison and Strulo 000; Priami 995) by introducing new probability and timed constructs. Stochastic π-calculus extends the classical π-calculus with two new constructs: a clock structure (or timer) and a probabilistic contracture (D'Argenio and Katoen 005). The clock structure is similar to that introduced by Alur and Dill for timed automata (Alur and Dill 994). In the context of stochastic π-calculus a clock structure is a value associated to action prefix π. Once initialized (often with a random non-negative number) a clock starts to count down and when it reaches 0 the associated action is fired. The probabilistic contracture is usually associated to a summation process. Instead of indeterminately choosing one of the sub-processes a probability (non-negative number between 0 and generated by a probability distribution function) is attached to each subprocess. More details about stochastic π-calculus and other stochastic process algebra can be found in (D'Argenio and Katoen 005; D Argenio et al. 998; Harrison and Strulo 000; Matthew 007). 3.3 High Level Architecture High Level Architecture (HLA) defines a component-based software architecture of distributed simulation systems (IEEE et al. 000). HLA is composed of three major components: HLA rules: A set of ten basic rules that together describe the general principles defining HLA (IEEE et al. 000).

39 8 HLA interface specification: A description of functional interfaces between simulations and Runtime Infrastructure (RTI) (IEEE et al. 00a). HLA Object Model Template (OMT): A specification of the common format and structure for describing HLA object models (IEEE et al. 00b) Federations In HLA a complete simulation system is called a Federation. Each participant simulation in a federation is called a Federate. The constituent of a federation is shown in Figure 3-. As shown a federation consists of several elements: A set of federates An implementation of RTI A Federation Object Model (FOM) that defines the information model of the federation. Federate..* Federation..* FederationObjectModel -participantin -define 0..* -run RuntimeInfrastructure Figure 3-: Structure of a federation

40 3.3. HLA Information Model 9 The OMT defines the information model for HLA. It prescribes the structure of an FOM. An FOM is the ontology of a federation. A federation execution must supply a FOM to RTI in order to facilitate any communication between federates. OMT has two main components: Object Class and Interaction Class. Object Classes are used to model entities interested by more than one federate and last for a specific time interval. Any user defined object classes must be inherited from a single root class called ObjectRoot. Interaction Classes are used to model actions which happen instantly and do not carry states. Any user defined object classes also must be inherited from a single root class called InteractionRoot. All OMT models associated with a federation are defined in a file called Federation Execution Data (FED). An FED file must be presented to RTI in order to create a federation execution HLA RTI HLA RTI is a collection of software providing common services to simulation federations. It provides services in six areas (Kuhl et al. 000):. Federation management. This service provides two functions. The first function defines how to create a federation and join or resign a federate from a federation. The second function defines how to save or restore the execution of a federation (checkpoint). In this thesis only the first function is examined.

41 30. Declaration management. This service defines how a federate can publish or subscribe events. RTI uses this service to facilitate the communication between federates. This service is the focus of this thesis. 3. Object management. This service defines ways of exchanging data between federates. It especially defines how to dynamically discover and receive new data. 4. Ownership management. This service provides a reliable and consistent way to update data. According to HLA a federate cannot change data (attribute) unless it has the ownership of the data and only one federate can own the data at the same time. 5. Time management. This service provides two functions: allowing a federate to advance its logical time in coordination with other federates in the same federation; and delivering time-stamped events in a time-constrained way (i.e. no past event). 6. Data distribution management. This service defines more specific ways of declaration management in terms of data exchanging. Among the above services only the first three - federation management declaration management and object management are essential to a HLA compliant federate. RTI provides implementation independent interfaces to heterogeneous simulation systems as shown in Figure 3-.

42 3 Federate +subscribe +publish «interface» FederateAmbassador «interface» RTIambassador 0..* 0..* +subscribe RuntimeInfrastructure +publish Figure 3-: Interfaces between RTI and federates According to HLA any communication between two federates goes through RTI. RTI provides an interface call RTIambassador to federates. Thus any communication from a federate is send to RTIambassador. Similarly a federate provides an interface called FederateAmbassador and RTI always sends communications through FederateAmbassador to a federate HLA Rules HLA has 0 rules in order to manage federates in a federation (IEEE et al. 000). These rules can be implemented in SOA without any difficulty: Rule : Federations shall have an HLA FOM documented in accordance with the HLA OMT. Rule : In a federation all simulation-associated object instance representation shall be in the federates not in the RTI.

43 3 Rule 3: During a federation execution all exchanges of FOM data among joined federates shall occur via RTI. Rule 4: During a federation execution joined federates shall interact with the RTI in accordance with the HLA interface specification. Rule 5: During a federation execution an instance attribute shall be owned by at most one joined federate at any given time. Rule 6: Federations shall have an HLA SOM documented in accordance with the HLA OMT. Rule 7: Federates shall be able to update and/or reflect any instance attributes and send and/or receive interactions as specified in their SOMs. Rule 8: Federates shall be able to transfer and/or accept ownership of instance attributes dynamically during a federation execution as specified in their SOMs. Rule 9: Federates shall be able to vary the conditions under which they provide updates of instance attributes as specified in their SOMs. Rule 0: Federates shall be able to manage local time in a way that will allow them to coordinate data exchange with other members of a federation. Among these ten rules rules to 5 are federation rules and the remaining 5 rules are federate rules.

44 3.4 Chapter Summary 33 This chapter presents the basic building blocks used in this research. First a brief introduction of modeling stochastic and time in DES is presented. Then a detailed discussion of π-calculus and its stochastic extension is provided. These two sections are the theoretical foundation of PiDES which will be discussed in the next chapter. Section 3.3 reviews the main theory of HLA. HLA is the foundation of PiDES-RTI which is presented in Chapter 5

45 Chapter 4 PiDES This Chapter presents a modeling formalism for a DES federate based on π- calculus called PiDES. Section 4. proposes the architecture of PiDES based on a modified process interactive world view. Section 4. develops the syntax and semantics of PiDES. Section 4.3 presents some important properties of PiDES models. Section 4.4 provides the validation of PiDES formalism through the translation of GSMP formalism into PiDES formalism. Section 4.5 demonstrates the capability of PiDES using a case study. Finally Section 4.6 concludes the chapter with a short discussion of the major advantages of PiDES. 4. The Architecture of PiDES This section presents the architecture for PiDES where the architecture consists of a world view of DES a meta-model of process and a meta-model of interaction. 4.. A PiDES World View of Discrete Event Systems Zeigler et al. proposed a System Specification Hierarchy (SSH) (Zeigler et al. 000) which defines five levels of system specification: a) level 0 observation frame b) level I/O behavior c) level I/O function d) level 3 state transition and e) level 4 coupled component. According to Zeigler et al. level 4 is the highest level

46 35 definition in SSH. SSH models the components of a system and how they are coupled. The components can be detailed at lower levels to form a hierarchical structure. PiDES uses a modified process-interactive world view of DES. In PiDES a system is defined as a set of concurrent processes which is equivalent to the level 4 definition of SSH. The interactions between these processes are modeled as Events. As shown in Figure 4- the major difference between PiDES world view and the conventional process-interactive world view is that PiDES also models internal transitions (which are unobservable from out side the process). System -consist of -internal 0..* Process -send Event -receive Figure 4-: PiDES world view of DES 4.. PiDES Process Meta-Model A Process is the corner stone entity of PiDES. As shown in Figure 4- a process may have many Behavior Models. A behavior model defines the internal and external behaviors of a process. There are three types of behavior models: Function Model

47 Management Model and Time Model. A process with no behavior model is called a Null Process. It is often the end of a process which has exhausted all behaviors. 36 CoordinationContext -coordinated by * Process BehaviorModel AbstractProcess 0..* * TimeModel ManagementModel FunctionalModel Action -LogicalTime Figure 4-: PiDES process meta-model A functional model defines the functional capability of a process. The capability of a process is provided by a set of Abstract Processes (APs) under the control of a Coordination Context (CC) (Figure 4-3). AP is an abstraction of Process and Action. A CC is a control schema that defines the execution sequence of APs that belong to the parent process. Using the concept of AP a CC can coordinate both processes and actions. PiDES offers two classes of CCs: Orchestration Coordination Context (OCC) and Choreography Coordination Context (CCC). An OCC provides a control flow based coordination mechanism. There are three types of OCC: Sequence Context in which all of the coordinated APs are executed sequentially;

48 37 Decision Context in which the execution of any coordinated APs depends on predefined conditions; and Loop Context in which the execution of the coordinated APs is repeated depending on predefined conditions. The above coordination contexts are similar to flow control statements (sequence if-then-else and for-loop) in most programming languages (i.e. C C++ and Java) and are capable of building many complicated control flows. CoordinationContext * AbstractProcess -coordinated by * ChoreographyContext OrchestrationContext SequenceContext DecisionContext LoopContext Figure 4-3: Coordination Context meta-model A CCC is a coordination context in which all of the coordinated APs are executed concurrently. Unlike an OCC there is no explicit control in a CCC. It relies on cooperation between the coordinated APs. However it is possible to design advanced control schema by designating an event routing to some APs in a CCC. Figure 4-4 shows an example of enforcing a sequential execution of two APs (AP before AP3) trough event re-routing in a CCC.

49 38 e e/e e AP AP AP3 Figure 4-4: Design a sequential control in CCC A time model has two functions: ) storing the current logical time of the process and ) performing time advance operations. The only state a PiDES process maintains is logical time. Logical time is used for only two purposes: ) providing a logical time stamp for any out going event and ) dealing with past events in the particular case in which time warp is used. However the handling of time warp and event compensation is beyond the scope of this thesis. As a result the evolution of a PiDES is only determined by the current behavior model not the previous behavior models. In the mean time it is possible that the process evolves due to a timed internal action. Therefore PiDES is a Semi-Markov process. A management model defines supporting functions of a process such as querying the restoring status of the process. Management models however are not the focus of this thesis. A time model and a management model are often provided by the simulation languages (or tools) but functional models are supplied by simulation developers.

50 4..3 PiDES Interaction Meta-Model 39 In PiDES interactions are modeled through Events and Actions. Events are modeled by two meta-models: Event Instance and Event Channel. An event instance is an occurrence of an event. An event channel defines a class of events and provides a mechanism for exchanging event instance. The exchange of an event instance is performed by an Action. Action ExternalAction InternalAction Receive EventChannel Send Tau TimeDelay..* -receive «uses»..* -send EventInstance Figure 4-5: Interaction Meta-Model Actions are atomic elements that define transitions of a process. As shown in Figure 4-5 there are two types of actions: Internal Action and External Action. Internal action is an action that cannot be observed from the outside of the process. Two internal actions are defined in PiDES:

51 40 Tau is an internal action which occurs instantly. Time Delay is an internal action that last for some time. As a result it advances the logical time. An external action can also be one of two types: Receive accepts an incoming event. Send generates an outgoing event. In PiDES external action occurs instantly and does not change the logical time of a process. 4. PiDES Syntax and Semantics This section presents the syntax and semantics of PiDES. It has four parts:. Stochastic action which defines the capability of PiDES;. Coordination context which provides rich control flow for PiDES processes; 3. Process definition which shows how the capabilities of PIDES can be put together; and 4. Operation semantics which illustrates the dynamics of PiDES processes. 4.. Stochastic Action actions: Actions define the capabilities of PiDES processes. There are two types of

52 a) Determinate instant actions as defined in classical π-calculus. 4 b) Non-determinate time duration actions. The latter is discussed in detail in this section. It is often unnecessary or even impossible to know how a system performs a time delay action. Thus it is natural to model time delay actions as internal actions. In PiDES the very basic time delay action is a Unit Delay Action (UDA). A UDA is an internal action with unit time duration. After a UDA is performed the system s logical clock is advanced by one unit. UDA is defined as Eq. 4.: UDA = τ () (4.) As a result the classical tau action τ is an internal action without any time delay. In other words τ is the same as τ(0). It is convenient to define an action with arbitral time delay t. This is shown in Eq. 4.: τ ( t ) = τ (). τ (). Lτ () t (4.) In Chapter 3 a clock is defined as a self-counting-down function starting from value t (Eq. 4.3). Clock = λ(t) (4.3) It is easy to show that a clock can be bisimulated by τ(t) (Eq. 4.4): λ( t) τ ( t) (4.4) Using the random number generation function defined in Eq. 3. a Stochastic Clock can be defined in Eq. 4.5:

53 StochasticClock = σ ( f t). τ ( t) (4.5) 4 After defining a stochastic clock it is easy to define a Stochastic Action δ (Eq. 4.6): δ = σ ( f t). τ ( t). π (4.6) where π is the classical π-calculus action prefix defined in Eq Probabilistic Choice The summation process defined in classical π-calculus implicitly uses a uniform probabilistic function. That is each sub-process has equal probability being chosen. This concept can be formalized in Eq. 4.7: M = n i= M i = n i= [ ] M i (4.7) n where [ ] is a condition prefix. [ i n n ]M means M i has the probability of being n chosen. Eq. 4.7 can extended into a more general case in which each M i has different probability (Eq. 4.8): M = n i= [ p i ] M i (4.8) n where p = and p i 0; i = i Eq. 4.8 is equivalent to Eq. 4.9:

54 43 M = n i = ( M i + M i ) 443 L (4.9) ap i where a is a sufficient large coefficient that makes the product of any a and p i an integer. Thus a summation with probabilistic choice can be defined as Eq Furthermore a stochastic summation process can be defined as Eq. 4.0: M = n i= [ p i ] M i (4.0) where: n p = and p i 0; i = i M i = 0 δ. P δ is defined in Eq. 4.6; if p i = it can be omitted Coordination Context A PiDES Coordination Context (CC) is based on the concept of Process Context. A process context is a process which contains place-holdings for other processes (Milner 999). The classical context Pi-calculus is defined as C π (Eq. 4.). C π provides the capability of compositing many processes in to a single larger process. However it does not provide much information about how to coordinate these processes. This process context concept is extended in PiDES into coordination context which provides coordination mechanisms for multiple simulation federates.

55 π [ ] π. Cπ + M νxcπ ( Cπ P) Cπ C =! (4.) As discussed in previous section a PiDES coordination context is defined in Eq. 4.: CC = CCC OCC (4.) 44 where CCC and OCC are Choreography Coordination Context (CCC) and Orchestration Coordination Context (OCC) respectively. There are two types of CCC: Finite CCC (CCC fin ) and Replication CCC (CCC rep ) as defined in Eq. 4.3 Eq. 4.4 and Eq. 4.5 respectively. CCC = CCC fin CCC rep (4.3) n CCC fin = Ci = C C L C i= n (4.4) CCC rep =!CC (4.5) where C i i= n are CCs. There are two differences between C fin and C rep :. The number of component CCs. C fin only accepts finite numbers of component CCs while C rep may have no unlimitation.. The nature of component CCs. The component CCs in a C fin can be either homogeneous or heterogeneous while C rep only accept homogeneous components. An OCC is defined in Eq. 4.6: OCC = OCC OCC OCC (4.6) seq dec loop

56 where OCC seq OCC dec and OCC loop are Sequential Coordination Context 45 Decision Coordination Context and Loop Coordination Context defined in Eq. 4.7 Eq. 4.8 and Eq. 4.9 respectively. OCC seq = ν ( a a L a C. C. L. C n OCC n dec )( C. a = n i= a. C. a i L a. C i i+. a i+ a n. C ) n (4.7) [ condition ] CC (4.8) OCC loop = [ condition] τ. CC + [ NOT condition] τ.0 (4.9) 4..4 PiDES Process (Federate) The syntax of a PiDES process is defined in Eq P = CC( FM CC( FM CC( FM CC( FM FM FM FM FM L FM L FM L FM L FM n n n n TM MM ) TM ) MM ) ) (4.0) where FM i (i= n) TM and MM are functional model time model and management model defined in Figure 4- respectively. In many systems it is undesirable to perform functional models when the time model or the management model has already begun (to avoid system state inconsistency). Therefore a PiDES process (with both a time model and a management model) is often defined as Eq. 4.: P = CC( FM FM L FM n ) + TM + MM (4.)

57 46 The summation in Eq. 4. guarantees that the functional models the time model and the management model cannot be performed simultaneously. Each of the functional models in Eq. 4.0 can be further formalized as a set of APs coordinated by a CC (Eq. 4.). FM = CC AP AP L AP ) (4.) ( n There are three basic functional models:. A functional model evolves as incoming events are triggered (Eq. 4.3). FM se n = a( x). [ p ] σ ( f t ). τ ( t ). FM (4.3) i= i i i i i. A functional model evolves by scheduling an outgoing event (Eq. 4.4). pe n FM = [ p ] σ ( f t ). τ ( t ). a ( x ). FM (4.4) i= i i i i i i i 3. A functional model evolves after some time without exchanging any events with other processes (Eq. 4.5). FM st = n i= [ p ] σ ( f t ). τ ( t ). FM (4.5) i i i i i The time model can be quite complicated as proposed in HLA. In this research a simplified HLA model is discussed. The simplified model has only two actions: time advance granted (tag) and time advance request (tar) (Eq. 4.6): TM = tag( t TM a a ). { t } + tar( ta ). TM (4.6) The management model can be defined in a way similar to the time model. However since this is not the focus of this thesis it is not discussed in detail here. t

58 As discussed in the previous sections a simulation federate is modeled as a 47 PiDES process. In addition the scholastic behavior of a federate is modeled in the functional models. The time model and management model are in fact stationary models PiDES Operation Semantics PiDES encompassed all of the operational semantics from classical Pi-calculus plus three new operations and an implicit time constraint of receive actions Implicit Time Constraints on Receive Actions Consider a PiDES process as shown in Eq. 4.7: P = a( e). Q (4.7) In order to perform receive action a the following conditions must be met:. The current logical time of P denoted by t c must be no larger that the timestamp of event instance e (denoted by t e ). This is a common assumption for DES: a federate cannot process a past event.. P must be able to advance it logical time to t e in order to process event instance e. It is important to keep time consistency so that an event is current when it is being processed. Therefore the receive action a(e) in Eq. 4.7 actually has the semantics of Eq. 4.8:

59 t = t ] a( e) + [ t < t ] TM ( t ) + [ t > t ].0 (4.8) [ c e c e e c e 48 where TM(t e ) is the action of the time model of advancing logical time to t e. Eq. 4.8 also demonstrates that a past event is ignored WAIT Operation The WAIT operation defines that action τ is enabled only after the associated clock runs down to 0 (Eq. 4.9). In other words process σ ( f t). τ ( t). P evolves to P after a random time t. WAIT: t σ ( f t). τ ( t). P P (4.9) PROB Operation The probabilistic choice introduced in Eq. 4.0 has several different semantics. Each component process M i of Eq. 4.0 may take one of the following forms:. 0 (null process). τ. P 3. τ (t). P (t>0) 4. a ( x). P and 5. a ( x). P. Forms and 4 can proceed immediately but forms 3 and 5 may not. Form 3 starts a clock and can not proceed until the clock counts down to 0. Form 5 cannot

60 proceed if there is no incoming event a. As a result the first operation semantics of 49 summation PROB is defined in Eq It simply means that M i includes the probability of p i being activated. PROB: n i= [ p ] M M (4.30) i pi i i where M i has form or 4. The second case is when some M i s have form 3 or 5 then the probabilistic prefix is no longer applicable. In addition a M i has form 5 will never be chosen if the corresponding incoming event is unavailable RACE Operation The last operation RACE indicates that two processes are competing for the opportunity to be executed (Eq. 4.3). The process with a smaller clock value is given the chance to run while the other process becomes void. If the two clocks have the same value the result is undefined. RACE: r < r P σ ( f t). τ ( t). P + σ ( f t ). τ ( t ). P (4.3) r = r P or P Such a non-deterministic behavior is fine in theory; however this kind of behavior often depends on runtime implementation and might not work as the designer expects. In practice a conditional RACE (meaning that there is a condition or PROB for each component of RACE) is more suitable to use to model non-deterministic behavior.

61 4.3 Properties of PiDES 50 This section presents the basic definition and properties of PiDES. Its application will be discussed in Section 4.5 and Chapter Basic Definitions Name Definition: Names are the simplest components of PiDES. Names appear in PiDES in one of the following ways: As an event channel name. For example a(x).p defines an event channel name a. As an event instance name. For example a(x).p defines an event instance name x. As a designator of a process an event an event message or other entity. For example a ( x). x( y). P defines a name x which is a designator of an event Co-Name Definition: Events occur in pairs in most cases. For example a ( x). P defines an event channel name a for sending out an event instance x; a(y).p defines an event

62 channel name a for receiving an event a and put it into name y. Thus a is a co-name 5 of a and vice versa Bound Name Definition: Terms a(x).p and νy P bind name x and y to the scope of process P. bn(p) is the set of all bound names of the process P. For example: bn ( ν c( a( x). x( y) + b( z) c( u))) = { c x} Free Name Definition: If a name is not bound it is a Free Name. fn(p) is the set of all free names of the process P. For example: fn ( ν c( a( x). x( y) + b( z) c( u))) = { a y b z u} Transit Name Definition: A Transit Name is a special bound name which becomes a free name when the process evolves. For example: x is transit name in process a ( x). x( y). The set of transit name of the process P is denoted as tn(p).

63 Published Event 5 Definition: A Published Event is an event that has been sent out from a process to the environment. It is a free name and the name designates to an outgoing event channel. pe(p) is the set of published events of process P. For example: pe ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { b d} Active Published Event Definition: An Active Published Event is a published event that has no prefix. ape(p) is the set of active published events of process P. For instance: ape ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { b} Inactive Published Event Definition: An Inactive Published Event is a published event that has at least one prefix. It is not fired until all of the prefixes are performed. ipe(p) is the set of active published events of process P. For instance: ipe ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { d}. It is obviously that pe( P) = ape( P) ipe( P).

64 Subscribed Event 53 Definition: A Subscribed Event is an event that a process might accept. It is a free name and the name designates to an incoming event channel. se(p) is the set of subscribed events of process P. For example: se ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { a d} Active Subscribed Event Definition: An Active Subscribed Event is a subscribed event that has no prefix. ase(p) is the set of the active subscribed events of process P. For example: se ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { a d} Inactive Subscribed Event Definition: An Inactive Subscribed Event is a subscribed event that has at least one prefix. ise(p) is the set of published events of process P. For example: ise ( ν c( a( x). x( y) + b( z). d( w) c( u))) = { d}. It is obviously that se( P) = ase( P) ise( P) Reaction Definition: A Reaction is the interaction within a process. ra(p) is the set of events that cause reactions of P. For example:

65 54 ra ( ν a( a( x) a( y))) = { a} Stage Transition Definition: A Stage Transition is either a reaction or a tau action (τ). st(p) is the set of events or tau actions that cause the stage transition of P. For example: ra ( νa( a( x) a( y) τ. N )) = { a π}. Multiple tau actions are counted as one Open Process fn(p) Ф. Definition: A process P is called an Open Process if it has at least one free name: Closed Process Definition: A process P is called a Closed Process if it has no free name: fn(p) = Ф. Closed processes will be discussed in detail in next chapter since most federations are in fact closed processes Interface Congruence Definition: A process P is called Interface Congruence to a process Q if and only if the following conditions hold:

66 55 pe ( P) = pe( Q) se ( P) = se( Q) 4.3. Basic Properties The basic properties of PiDES are Liveness Deadlock Dead and Blocking. The applications of these properties will be discussed in the next chapter Liveness Definition: An open process P is live if at least one the following conditions hold: ape (P) Φ ase (P) Φ st (P) Φ where Ф is an empty set. For a closed process Q it is live if and only if: ape (Q) Φ The difference between an open process P and a closed process Q is that P has potential interactions with the external environment however Q does not.

67 4.3.. Deadlock 56 Definition: An open process P is deadlocked if it is live but does not publish nor subscribe any event in finite time. In other words P has the following properties in any future time: ape(p) = Ф ase(p) = Ф st(p) Ф For a closed process Q it is deadlocked if and only if: st(q) = Ф Dead Definition: A process P is dead if it does not publish any event or subscribe event or have any stage transitions: ape(p) = Ф ase(p) = Ф st(p) = Ф Terminated Definition: A process P is terminated if the following condition holds: pe(p) U se(p) U st(p) = Ф It is obvious that terminated is a special case of dead.

68 Blocking 57 Definition: A process P is blocked if the following conditions hold: ape(p) U ase(p) Ф st(p) = Ф If P is blocked due to ape(p) Ф then P is starving; otherwise P is over-pacing (ase(p) Ф). 4.4 Validation This section proves that PiDES is capable of modeling DES. The proof is presented by using PiDES to bisimulate GSMP. As discussed in Chapter 3 bisimulation is an equivalent relation between State Transition Systems. Two systems are bisimilar if they match each other's every move. Thus the behavior of these systems cannot be distinguished from an outside observer (Milner 999). If PiDES can bisimulate GSMP then PiDES has the equivalent modeling power of GSMP. Since GSMP is a formalism of DES then PiDES is also a formalism of DES. 989) where: As introduced in Chapter a GSMP model is a 6-tuple (S s 0 E P C F) (Glynn S is a set all the states. s 0 is the initial state s 0 S. E is the set of all events.

69 58 P: s i e s i+ is a set of probabilities of jumping from state s i to s i+. triggered by event e e E. C is a set of clocks in which each clock is corresponding to a state s and an event e. It continues to count down to zero. F is the probability function of scheduling a new event e in state s given the previous state is s and the triggered event is e. In PiDES there are no states as each state in GSMP is transferred into a behavior model. GSMP events are modeled as published events and subscribed events. The probability jumping function P is modeled as probability summation in Eq Clocks in C are presented in Eq Finally probabilistic functions for scheduling new events in F are modeled as stochastic actions in Eq Thus a GSMP model can be bisimulated by a PiDES model through the following steps:. Each state of GSMP becomes a PiDES functional model.. The functional model corresponding to s 0 is the starting functional model for the system. 3. Each event becomes a pair including a published name and a subscribed name. 4. A jumping relation in P related to s i is modeled as a functional model FM se presented in Eq Clocks in C are modeled in Eq A probability function of scheduling a new event related to s i is modeled as a functional model FM pe defined in Eq. 4.4.

70 The above process does not involve any coordination context. This is because 59 GSMP has no explicit semantics for coordination. The execution of GSMP models is determined by transition rules which are implicitly captured by PiDES s CCC. 4.5 A Case Study This section demonstrates how to model a simplified Flexible Manufacturing System (FMS) using PiDES and how those models evolve through process reductions System Description The following case is a simplified two-machine two-part and one-robot FMS that has been adopted from (Chang et al. 998) with minor modifications as shown in Figure 4-6. This FMS uses one robot and two machines to process two parts (part and part ). Part is first sent to machine A processed for 4 units time and then send to machine B for another 5 units of time processing. Part is first sent to machine B then to machine A; the processing time are 5 units and 4 units respectively. All of the material handlings are done by the robot R with unit time delay. All of the resources: machine A machine B and robot R have one capacity only.

71 60 Figure 4-6: A two-machine two-part and one-robot FMS (Chang et al. 998) The system works as follows: a new part (part or ) arrives from an external system (not modeled here) then the robot handles the part over to one of the machines (A or B) depending on the routing shown in Figure 4-6. When a part finishes all of the processing the robot picks it up and sends it to an external system. The system is modeled as a closed system without any interactions with the external environment System Models The FMS presented in the previous section can be modeled by three federates: A B and C representing machine A machine B and robot R respectively. In order to simplify the syntax the time management operations are implicitly embedded into the

72 6 reductions (see Section 4..5 for detail semantics; more advanced time management will be discussed in Chapter 5). A accepts the following events: Event nr: new part is ready at robot R. Event br: part processed by machine B is ready at robot R A sends out two events: Event a: part is done. Event a: part is done. Thus A can be modeled as a PiDES process as shown in Eq. 4.3: nr( p ). τ (4). a( p ). A A = + br( p ). τ (5). a( p ). A (4.3) As observed time delay (process time) is modeled as an internal action. Similarly B accepts the following events: Event ar: part processed by machine A is ready at robot R Event nr: new part is ready at robot R B sends out two events: Event b: part is done. Event b: part is done. Thus B can be modeled as a PiDES process as shown in Eq. 4.33: ar( p ). τ (5). b( p ). B B = + nr( p ). τ (4). b( p ). B (4.33) Finally R accepts the following events: Event a: part is done at machine A.

73 6 Event a: part is done at machine A. Event b: part is done at machine B. Event b: part is done at machine B. R sends out two events: Event nr: new part is ready. Event nr: new part is ready. Event br: part processed by machine B is ready. Event ar: part processed by machine A is ready. Thus R can be modeled as a PiDES process as shown in Eq. 4.34: R = nr( p ). τ (). R nr( p ). τ (). R a( p ). τ (). ar( p ). τ (). R a( p ). τ (). R b( p ). τ (). R b( p ). τ (). br( p ). τ (). R (4.34) The whole system is modeled as three PiDES processes coordinated by a CCC fin as shown in below: FMS = CCC ( A B R) (4.35) fin System Dynamics The system dynamics are modeled by process reductions among all the PiDES processes. It starts as the state shown in Table 4- (assume logical time for all federates starts from 0):

74 63 Table 4-: System initial state Federate Logical Time Active Published Event Active Subscribed Event A 0 nr br B 0 ar nr R 0 nr a nr a b b It is easy to calculate the following: ape ( FMS) = { nr nr}. ase ( FMS) = { nr br ar nr a a b b}. st ( FMS) = { nr nr}. Since none of the above set is empty the system is live. In addition the system has two potential stage transitions: nr and nr. If nr is performed: A: A 0 nr τ 0 τ 4 (4). a( p ). A. a( p). A. A s logical time is advanced by to 4 (shown as a superscript of A same for B and R). B: no change. R: R 0 nr 0 τ τ (). R R. R s logical time advances to. The system then evolves to the states shown in Table 4-:

75 64 Table 4-: System state after performing nr Federate Logical Time Active Published Event A 4 a Active Subscribed Event B 0 ar nr R nr a nr a b b Following the same analysis as shown above the system has: ape ( FMS) = { a nr nr}. ase ( FMS) = { ar nr a a b b}. st ( FMS) = { a nr nr}. Thus the system is live with two potential stage transitions: a and nr. If a is performed: A: a( p). A A 4 a 4. B: no change. R: R a τ τ 4 τ 5 ( ). ar( p). (). R ar( p). (). R τ. R s logical time is advanced to 5 (event a has a timestamp 4 which is greater than R s current logical time so R advances to 4 after receiving a; then advances another unit for internal processing). The system then evolves to the states shown in Table 4-3:

76 65 Table 4-3: System state after performing a Federate Logical Time Active Published Event Active Subscribed Event A 4 nr br B 0 ar nr R 5 ar The system has: ape ( FMS) = { ar}. ase ( FMS) = { nr br ar nr}. st ( FMS) = { ar}. Thus the system is live with one potential stage transition: ar. After performing ar: A: no change. B: R: B R 0 ar 5 τ 0 τ ( 5). b( p ). B b( p). B. 5 ar 5 τ 6 τ ( ). R R. The system then evolves to the states shown in Table 4-4: Table 4-4: System state after performing ar Federate Logical Time Active Published Event Active Subscribed Event A 4 nr br B 0 b R 6 nr a nr a b b

77 The system has: 66 ape ( FMS) = { b nr nr}. ase ( FMS) = { nr br a a b b}. st ( FMS) = { b nr nr}. Thus the system is live with three potential stage transitions: b nr and nr. If b is performed: A: no change. B: R: b( p). B B R 0 b 0. 6 b 0 τ τ ( ). R R. R s logical time advances to. The system then evolves to the states shown in Table 4-5: Table 4-5: System state after performing b Federate Logical Time Active Published Event Active Subscribed Event A 4 nr br B 0 ar nr R nr a nr a b b The above transition can be summarized as Eq. 4.36

78 A 0 B 0 R 0 nr τ a τ ar τ b τ τ (4). a( p ). A a( p ). A A A A A A A B B B B τ (5). b( p ). B b( p ). B R B 0 0 ar( p ). τ (). R 0 τ (). R B R 0 τ (). ar( p ). τ (). R 0 5 R 6 τ (). R 5 τ (). R (4.36) 67 Thus the system starts over again Deadlock Detection and Model Checking It is possible for the above system to run into deadlock. For example if the system takes the following path (Eq. 4.37): A 0 B 0 R 0 nr τ nr τ a τ τ (4). a( p ). A a( p ). A 4 4 a( p ). A a( p ). A A A b( p b( p B 0 ). B ). B 0 b( p 5 5 B R 0 τ (4). b( p ). B τ (). R 5 ). B R τ (). ar( p ). τ (). R ar( p ). τ (). R 0 τ (). R 5 4 (4.37) Since the system is a closed process and st( A b( p ). B ar( p ). τ (). R ) = Φ it is deadlocked. Using process deduction and the properties provided in Section 4.3 it is fairly easy to detect deadlock. However more advanced treatments of deadlock issues are beyond the scope of this thesis. Related researches of deadlock problems in FMS can be found in (Chang et al. 998; Cho et al. 995; Fanti et al. 00; Wysk et al. 99; 994);

79 studies of design deadlock free π-calculus models can be found in (Kobayashi 006; 68 Milner 999). Chapter 6. More discussion about tools for PiDES model checking will be presented in 4.6 Summary This chapter presents PiDES a new formalism for federate modeling based on π- calculus. PiDES is a formalism of Semi-Markov Processes and has all the modeling power of GSMP. PiDES has many potential advantages such as models which are highly compositional as well as the benefits of concurrency and scalability. In the next chapter formal models of federations and the runtime infrastructure will be discussed.

80 Chapter 5 PiDES-RTI This Chapter presents PiDES-RTI a modeling formalism for a DES federation based on PiDES and HLA. The formalism consists of formal definitions of a federation an RTI and a federation execution. In Section 5. formal models for a federation are presented. Section 5. illustrates a hierarchical architecture for the RTI. Section 5.3 develops formal models for basic HLA RTI services presented in the RTIambassador and FederateAmbassador interfaces. Section 5.4 demonstrates the capabilities of PiDES-RTI using the case study introduced in Chapter 4. Finally Section 5.5 concludes the chapter with discussions of some of the advantages of using PiDES-RTI. 5. A Formal Model for PiDES Federation In HLA a Federation is a combined simulation system that consists of many constituent simulations (federates). The execution definition of an HLA federation is defined in a Federation Execution Data (FED) file. The most important parts of a FED file are the definitions of object classes and interaction classes which specify the data and communications of the federation. In PiDES-RTI a federation is formalized as a coordination context (PiFED) as shown in Eq. 5.. PiFED = CC F F L F ) (5.) ( n

81 where F i (i = n) are federates. 70 The definition of PiFED also implies the followings:. In order to join the federation a federate must Interface Congruence (as defined in Section 4.3.) to one of the F i s.. If a CCC rep is presented then multiple instances of the associated federate may be allowed. Otherwise only one instance of each federate (F i ) is permitted. 5. A Hierarchical Architecture for DES Federation Runtime Infrastructure As defined in Eq. 5. a PiDES federation is viewed as a set of processes (federates) running concurrently. The federation evolves as the processes interact with each other. However it would have a scalability problem if any process in the federation can interact with any other processes. Therefore PiDES-RTI follows the approach used by HLA: all processes can only interact with the RTI which itself is a process. As a result a PiDES Federation Execution (PiFE) which is a running instance of a PiDES federation consists of two types of processes: Federate Process and RTI Process. Thus a PiFE can be formalized as a combination of a PiFED and a RTI process (called PiRTI) as shown in Eq. 5.: PiFE = CCC fin ( PiFED PiRTI ) = PiFED PiRTI (5.) Since a PiFED consists of many federates a PiFE can have many federate processes. However a PiFE can only have one RTI process. In addition each federate

82 itself can be a federation of smaller federates. Thus the entire PiDES-RTI is a 7 hierarchical layered system as shown in Figure 5-. Root RTI Federation Federation Federation n Private RTI Federate A Federate B Private RTI B Federate B Federate B Figure 5-: A hierarchical architecture RTI In the above architecture a RootRTI must exist before any federation execution can be created. The main function of the RootRTI is to create a federation execution upon request. The recently created federation execution has its own RTI called a PrivateRTI. A PrivateRTI is only visible to the federates at the same level in the federation execution. For example Federate A and Federate B can interact with Private RTI but not Private RTI B. Similarly Federate B and Federate B can access Private RTI B but not Private RTI. Figure 5- can be formalized in Eq. 5.3: RootRTI = CCC rep (ν( pe( Federation ) se( Federation )) Federation ) Federation = PiFE = CCC fin ( PiFED PrivateRTI ) = PiFED PrivateRTI PiFED = CC (Federate Federate n ) (5.3) where Federate i and PrivateRTI are recursively defined in Eq. 5.4:

83 7 Federate = Federation PrivateRTI = RootRTI (5.4) It should be noted that ν( pe( Federation ) se( Federation ) restricts both the published events and subscribed events (see Section 4.3.) of a federation (Eq. 5.3) therefore federations are separated from each other. A detailed discussion of modeling the nested RTIs is beyond the scope of this thesis. In the following sections the formalism is limited to a single-layer RTI. 5.3 Formal Models for HLA RTI Services The HLA RTI services are wrapped in one interface called RTIambassador. An HLA complied federate must also implement an interface called FederateAmbassador which is a complement interface of RTIambassador. RTIambassador is formally defined in Eq. 5.5: RTIambassador = CCC fin ( FederationManagement DeclarationManagement ObjectManagement OwnershipManagement (5.5) TimeManagement DataDistributionManagement ) As mentioned earlier only Federation Management Declaration Management and Time Management will be discussed here. Thus the RTIambassador interface is simplified as Eq. 5.6:

84 73 RTIambassador = CCC fin ( FederationManagement DeclarationManagement (5.6) TimeManagement ) Similar to RTIambassador a FederateAmbassador can be modeled as Eq. 5.7: FederateAmbassador = FederationManagement + DeclarationManagement + (5.7) TimeManagement It should be noted that the three services of the FederateAmbassador are not coordinated by a CCC (to be more specific a CCC fin ) but an OCC (to be more specific a summation). The rationale is that these three services are mutually exclusive. In PiDES-RTI RTIambassador and FederateAmbassador are modeled as PiRTI (Eq. 5.8) and PiFederate (Eq. 5.9) respectively. PiRTI = PiRTIFM + PiRTIDM + PiRTITM (5.8) PiFederate = PiFedFM +PiFedDM + PiFedTM (5.9) It should be noted that Eq. 5.8 uses a summation instead of a CCC fin as defined in Eq This is a simplification to avoid complex syntax. More details will be discussed in Eq Federation Management Eq. 5.0: The formal model of HLA Federation Management service is presented in

85 74 FederationManagement = CCC fin ( create Federation Execution destroyfederationexecution joinfederationexecution resignfederationexecution registerfederationsynchronizationpoint confirmsynchronizationpointregistration announcesynchronizationpoint synchronizationpointachieved federationsynchronized requestfederationsave initiatefederatesave (5.0) federatesavebegin federatesavecomplete federationsaved requestfederationrestore confirmfederationrestorationrequest federationrestorebegin initiatefederaterestore federaterestorecomplete federationrestored ) As can be noted in Eq. 5.0 all the component services are coordinated by a CCC fin. This is because HLA RTI is not state dependent. In order to limit the scope of study only the first four services (createfederationexecution destroyfederationexecution joinfederationexecution and resignfederationexecution) will be discussed in detail here. Thus the HLA federation management service is simplified as Eq. 5.: FederationManagement = CCC fin ( create Federation Execution destroyfederationexecution joinfederationexecution (5.) resignfederationexecution )

86 In PiDES-RTI the federation management service is modeled differently in 75 RootRTI and PrivateRTI due to the limitation of single-layered RTI. The createfederationexecution service is only available from RootRTI as shown in Eq. 5.: RootRTI = create Federation Execution. ν pe( PiFE ) se( PiFE )) PiFE RootRTI ( (5.) The RootRTI receives a createfederationexecution event creates a new PiFE process (the subscript in PiFE denotes the number of federates a newly created PiFE is always a PiFE ) then continues itself. The restriction operator (ν) of PiFE makes sure that any PiFE is independent from other PiFE s. In general a PiFE with n federates (PiFE n ) can be modeled as Eq. 5.3: PiFE n PiRTI n = PiRTI CC( PiFederate L PiFederate ) = n PiRTIFM n + PiRTIDM + PiRTITM n (5.3) where the federation management service is modeled in PiRTIDM (Eq. 5.4): PiRTIFM n = ( destroyfederationexecution.0 joinfederationexecution( PiFederate n+ ).PiFE resignfederationexecution( PiFederate ). PiFE i n+ n + ) (5.4) As can be seen in Eq. 5.4 the PiRTIFM n of PiFE n has three capabilities:. Terminates PiFE n after receiving a destroyfederationexecution event.. Evolves PiFE n to PiFE n+ after receiving a joinfederationexecution event. 3. Evolves PiFE n to PiFE n- after receiving a resignfederationexecution event. When there is no federate (PiFE 0 ) the federation execution terminates (Eq. 5.5):

87 PiFE0 = τ.0 (5.5) 76 At the federate side the federation management interface is modeled in two processes: ) a federate not associated in a FE (Eq. 5.6) and ) a federate joined in a FE (Eq. 5.7): PiFedFM = ( create Federation Execution + joinfederationexecution ). PiFederate joined PiFedFM joined = ( destroyfederationexecution + resignfederationexecution ). PiFederate (5.6) (5.7) respectively. Where PiFederate and PiFederate joined are defined in Eq. 5.9 and Eq. 5.8 PiFederate joined = PiFedFM joined +PiFedDM + PiFedTM (5.8) 5.3. Declaration Management The HLA Declaration Management service is defined in Eq. 5.9: DeclarationManagement = CCC fin ( publishobjectclass unpublishobjectclass publishinteractionclass unpublishinteractionclass subscribeobjectclassattributes unsubscribeobjectclass subscribeinteractionclass (5.9) unsubscribeinteractionclass startregistrationforobjectclass stopregistrationforobjectclass turninteractionson turninteractionsoff )

88 In PiDES-RTI both HLA Objects and Interactions are modeled as events; 77 therefore the declaration management service can be simplified as Eq. 5.0: DeclarationManagement = CCC fin ( publishevent unpublishevent subscribeevent unsubscribeevent ) (5.0) Again the last four services in Eq. 5.9 are outside of the focus of this thesis and will not be discussed in detail here. In PiDES-RTI the declaration management service is modeled as a PiRTIDM (Eq. 5.): PiRTIDM PiRTIDM PiRTIDM n n+ 0 = ( ) = = = publishevent( e unpublishevent( e ).PiRTIDM subscribeevent( e ). PiRTIDM unsubscribeevent( e ). PiRTIDM n j= β n+ β. Q j. Q j n+ PiRTIDM. α j. α n + n+ ).v( α PiRTIDM β )( PiRTIDM publishevent( e ).v( α β )( PiRTIDM i i i n+ n n+ n- n n ) n+ ) (5.) where PiRTIDM n is a PiRTIDM with n published events. When n>0 it has the following behaviors:. Receives a publishevent event then performs the following: a. Evolves itself to PiRTIDM n+. b. Creates a private event channel β n+ for PiRTIDMs n+ and PiFederate pe (the sender of e n+ not shown in Eq. 5. but in Eq. 5.).

89 c. Creates a private event channel α n+ for the entire federation. 78. Receives an uppublishevent event and then removes the event channel created in the publishevent action. 3. Receives a subscribeevent event and then continues. 4. Receives an unsubscribeevent event and then continues. 5. Receives events (β j ) published by federates sorts events in a queue (Q j ) and makes them available to the entire federation. It should be noted that by supplying different Q j s a PiRTIDM will have different event delivery protocol. For example if Q j is a FIFO queue then event e j will be delivered as Receive Order (RO); if Q j is a priority queue with an ascending order of event times then event e j will be delivered as Time Stamp Order (TSO). However the implementation Q j s has little to do with the semantics of RTI services and is not the focus of this thesis. When n=0 a PiRTIDM n can only perform publishevent actions. The complementary part the declaration management interface of a federate is shown in Eq. 5.:

90 Time Management The HLA Time Management service is modeled in Eq. 5.3: PiFedTM PiFedDM PiFedFM PiFederate PiFedDM v e subscribeevent PiFedDM.v e publishevent PiFedDM PiFedDM PiFedDM PiFedDM PiFedDM e unsubscribeevent PiFedDM v e subscribeevent.pifeddm e unpublishevent PiFedDM.v e publishevent PiFedDM nm joined joined nm m n m n n j j nm- i nm n m n-m i m n n n nm + + = + = = = = = ) )( ( ). ( ) )( ( ) ( ) ). ( ) )( ( ). ( ) ( ) )( ( ) ( ( α β α β α α β (5.)

91 80 TimeManagement = CCC fin ( enabletimeregulation timeregulationenabled disabletimeregulation enabletimeconstrained timeconstrainedenabled disabletimeconstrained timeadvancerequest timeadvancerequestavailable nexteventrequest nexteventrequestavailable flushqueuerequest timeadvancegrant (5.3) enableasynchronousdelivery disableasynchronousdelivery querylbts queryfederatetime queryminimumnexteventtime modifylookahead querylookahead retract requestretraction changeattributeordertype changeinteractionordertype ) In order to simplify the case this research assumes all the federates are both time regulated and constrained. In addition time warp and look ahead are omitted. Thus the time management service can be simplified as Eq. 5.4: TimeManagement = CCC fin ( timeadvancerequest timeadvancegrant ) (5.4) (Eq. 5.5): In PiDES-RTI the time management service is modeled as a PiRTITM

92 8 PiRTITM = ( + timeadvancerequest( t ) timeadvancegrant( t ) g r ). PiRTITM (5.5) It can be seen from Eq. 5.5 that PiRTITM does not keep any states (i.e. current logical time). In fact HLA RTI computes current federation logical time based on all the federates logical time. Again how to compute the federation s logical time is beyond the scope of this thesis. At the federate side time management interfaces are modeled as a PiFedTM (Eq. 5.6): PiFedTM t = + timeadvancerequest( t ). PiFedTM. timeadvancegrant( t ). PiFedTM a a ta t (5.6) It should be noted that PiFedTM is stated it keeps the federate logical time. 5.4 A Case Study This section demonstrates how to build and execute a distributed simulation model based on PiDES-RTI. This case is based on the case presented in Chapter System Description The physical system of this case is the same as the FMS presented in Chapter 4 (see Section 4.5). However the three federates: A B and R which represent machine A machine B and Robot R no longer assume running inside one computer. Instead the simulation system is built on a PiDES-RTI. Therefore the federation is running in a distributed environment.

93 5.4. System Models 8 in Eq. 4.3: As defined in Section 5.3 the new FMS models are captured in a PiFED as shown FMS _ PiFED = = CCC fin A B R ( A B R) (5.7) Each individual model has the same functional behaviors as presented in Section 4.5 along with additional FederateAmbassador functions provided by PiDES-RTI. The whole system is shown in Eq (to make the equations short the PrivateRTI is denoted as P): FMS = A B R P (5.8) In PiDES-RTI a federate only interacts with the RTI thus from the federate perspective it looks like there are three executions running currently but without knowing each other (Eq. 4.34): A' s view B' s view R' s view : : : A P B P R P (5.9) System Dynamics following: The life cycle of a PiDES-RTI complied simulation system consists of the. Federation execution creation

94 . Federates join the federation execution Federates publish/subscribe events 4. Normal operations which includes: send/receive event and time management 5. Federates resign from the federation execution and 6. Federation execution shutdown Federation Execution Creation The federation execution was created when the first federate joins in the federation. Assume A is the first federate then the creation process is shown in Eq. 5.30: createfederationexecution A RootRTI PiFE PiFE = A joined P (5.30) The creation of a federation execution is through the RootRTI as discussed in the previous section. As a result a federation execution (PiFE ) has been created which consists of two processes: ) a private RTI (P ) and ) a federate (A joined ) Federates Join the Federation Execution The join process consists of two steps:. A federate sends a joinfederationexecution request along with the name of the target federation execution to the RootRTI; and

95 . The RootRTI delegates the request to the target federation execution 84 (which has a private RTI). The join processes of B and R are shown in Eq. 5.3 and Eq. 5.3 respectively: B RootRTI R RootRTI joinfederationexecution joinfederationexecution = joinfederationexecution joinfederationexecution = B PiFE PiFE B joined 3 A R PiFE PiFE R joined B joined joined P A joined P 3 (5.3) (5.3) Federates Publish/Subscribe Events After a federate joins a FE it starts publishing and subscribing events (the declaration management). For example the declaration management process for A is as follows (Eq and Eq. 5.34): A joined PiFedDM P publishevent ( a) publishevent ( a) subscribeevent ( nr) subscribeevent ( br) A = ( PiFedFM ( PiRTIFM PiRTIDM A joined v( α v( α + PiFedDM + PiFedTM + PiRTIDM + PiRTITM ) v( α β )( PiFedDM a v( α β a nr br a a )( PiFedDM )( PiFedDM A )( PiFedDM A A A 0 A 0 PiRTIDM PiRTIDM A ) ) ) PiRTIDM PiRTIDM ) ) (5.33) (5.34) Although the publishevent and subscribeevent have been shown in a specific order in the above example the order is not mandated in general. It also should be noted that events nr and br have not been published yet (since R has not joined yet).

96 85 However the information of both events is available in the PiFED. Thus it is up to the implementation how to handle such a situation. After all of the events of A have been published or subscribed the functional models (see Section 4.5.) will be re-labeled (Eq. 5.35): FM = α + α nr br A α { nr nr ( p ). τ (4). β ( p ). A ( p ). τ (5). β α br β a a b r β a a} α nr β a n r a} α br β a b r a = ( nr( p ). τ (4). a( p ). A){ + ( br( p ). τ (5). a( p ). A){ a a ( p ). A } (5.35) Similarly the declaration management processes for B and R can be defined as follows (Eq Eq Eq and Eq. 5.39): B joined PiFedDM P publishevent ( b) publishevent ( b) subscribeevent ( nr) subscribeevent ( ar) R joined PiFedDM B P R publishevent ( nr) publishevent ( nr) publishevent ( ar) publishevent ( br) subscribeevent ( a) subscribeevent ( a) subscribeevent ( b) subscribeevent ( b) = ( PiFedFM ( PiRTIFM PiRTIDM 3 ( PiRTIFM B joined v( α v( α = ( PiFedFM PiRTIDM 4 + PiFedDM + PiRTIDM v( α β )( PiFedDM b v( α β )( PiFedDM 3 v( α v( α v( α v( α b nr ar R joined b b )( PiFedDM )( PiFedDM + PiFedDM + PiRTIDM nr nr ar br β β β β nr ar br v( α )( PiFedDM a v( α )( PiFedDM a v( α )( PiFedDM b v( α )( PiFedDM b nr 4 B + PiFedTM + PiRTITM ) B B R B 0 B 0 PiRTIDM PiRTIDM 4 4 B ) ) ) PiRTIDM + PiRTITM ) )( PiFedDM )( PiFedDM )( PiFedDM )( PiFedDM R 4 R 4 R 43 R 44 PiRTIDM + PiFedTM R 0 R 0 R 30 R 40 PiRTIDM PiRTIDM PiRTIDM PiRTIDM ) ) ) ) R ) PiRTIDM PiRTIDM PiRTIDM 3 4 PiRTIDM 7 ) ) ) ) ) ) (5.36) (5.37) (5.38) (5.39)

97 86 Again the orders of the events are arbitrary. The re-labeled functional models of B and R are shown in Eq and Eq. 5.4: The whole federation execution is shown in Figure 4-6 after all the declarations are done. B p p B p p B p b p r n B p b p ar FM b r n b r a b b r n r n b b r a r a b b b b r n r n r a r a B ). ( (4). ). ( ). ( (5). ). ( } ){ ). ( (4). ). ( ( } ){ ). ( (5). ). ( ( } { β τ α β τ α τ τ β α β α β β α α + = + = (5.40) R p p R p R p R p p R p R p R p br p b R p b R p a R p ar p a R p nr R p nr FM r b b b a r a a r n r n r n b b r b r b b b a a a a r a r a r n r n r n r n b b b b a a a a r b r b r a r a r n r n r n r n R (). ). ( (). ). ( (). ). ( (). ). ( (). ). ( (). ). ( (). ). ( (). ). ( } ){ (). ). ( (). ). ( ( } ){ (). ). ( ( } ){ (). ). ( ( } ){ (). ). ( (). ). ( ( } ){ (). ). ( ( } ){ (). ). ( ( } { τ α τ β τ β τ β τ α τ β τ τ α τ τ τ τ τ τ τ τ α β α β β β α α α β β β β α α α α = = (5.4)

98 87 A ß a a nr aar B ß a a br a nr ß b ß b P ß br ß ar ß nr ß nr a a a a a b a b R Figure 5-: Event declarations private event public event federate boundary Figure 4-6 also shows that each federate only interacts with the RTI (P) not other federates as discussed in previous sections. The separation is achieved by the following: A federate subscribes public events announced by the RTI and A federate uses private channels to interact with the RTI Normal Operations The normal operations of the federation execution are similar to the one presented in Section However instead of performing reduction between federates reductions

99 are performed between a federate and the RTI. Table 5- shows the initial sate of the 88 system: Table 5-: System initial state Federate Logical Time Active Published Event Active Subscribed Event A 0 α nr α br B 0 α ar α nr R 0 β nr α a β nr α a α b α b RTI Event Queue α nr α nr α ar α br α a α a α b α b Events Timestamp Two events β nr and β nr are activated however in order to fire these two events federate R must be able to advance its logical time to the same time as the events (see Section 4..5). In the above table R has the same logical time as β nr and β nr. In other words the two events are current. Therefore both of the events can be fired. Assume β nr is fired. The system then evolves to the states shown in Table 5- (a τ() is also performed by R).

100 89 Table 5-: System state Federate Logical Time Active Published Event Active Subscribed Event A 0 α nr α br B 0 α ar α nr R β nr α a β nr α a α b α b RTI Event Queue Events Timestamp α nr 0 α nr α ar α br α a α a α b α b Now the RTI has an event α nr with a timestamp 0 which can be delivered to A since A s logical time is also 0. After A processes event α nr the system then evolves to the states shown in Table 5-3:

101 90 Table 5-3: System state 3 Federate Logical Time Active Published Event Active Subscribed Event A 4 α nr α br B 0 α ar α nr R β nr α a β nr α a α b α b RTI Event Queue Events Timestamp α nr α nr α ar α br α a 4 α a α b α b Now R has the potential to send out either β nr or β nr with time or to receive event α a with timestamp 4. According to RACE operation (see Section 4..5.) one of β nr or β nr will be sent out first and then α a will be received. Assuming β nr is chosen by R the system then evolves to the states shown in Table 5-4:

102 9 Table 5-4: System state 4 Federate Logical Time Active Published Event Active Subscribed Event A 4 α nr α br B 0 α ar α nr R 5 β ar RTI Event Queue Events Timestamp α nr α nr α ar α br α a 4 α a α b α b Using the above analysis the system can continue to evolve. However the system dynamics presented in this chapter differs from those in Chapter 4 in several ways: All federates only interact with the RTI only. An out-going event (send) can always be performed as long as the time is current. In other words for an out-going event with timestamp t if the federate can advance its time to t (through sending TAR the RTI and receiving TAG from the RTI) then the event can be sent. An incoming event (receive) can be performed if the corresponding event queue in the RTI is not empty and the time is current. In other words in

103 order to receive an event with timestamp t the federate must advance its time to t Federates Resign from the Federation Execution The resign process of federates A B and R is shown in Eq. 5.4 Eq and Eq respectively: A PiFE R B joined joined PiFE joined P 3 = B P = R resignfederationexecution PiFE joined R P joined P resignfederationexecution PiFE joined 0 (5.4) (5.43) resignfederationexecution P PiFE (5.44) Federation Execution Shutdown (Eq. 5.45): The federation execution is automatically shutdown when there are no federates PiFE 0 τ 0 (5.45) Deadlock The system can run into deadlock in a similar way as was presented in Section When a deadlock occurs no federate can send events receive events or advance its logical time. One solution for avoiding deadlock is to allow more robots. In order to

104 do so the PiFED presented in Eq. 4.3 should be modified to allow multiple instances of R which is provided in Eq. 5.46: 93 FMS _ PiFED = CCC ( A B CCC ( R)) (5.46) fin rep In general the system could be defined to allow multiple instances of any federate Eq. 5.47: FMS _ PiFED = CCC ( CCC ( A) CCC ( B) CCC ( R)) (5.47) fin rep rep rep This is actually a great advantage for PiDES which allows dynamic changes within a federation without changing the models. 5.5 Summary This chapter presented PiDES-RTI a new formalism for HLA RTI. It uses the same syntax and semantics that were developed in Chapter 4 to model HLA RTI. The advantages of using a single formalism for modeling federates federations and the RTI are significant: ) the whole system can use the same model validation and verification technology; ) the federates and RTI can be implemented in the same way; and 3) building large simulation systems becomes easy since no special treatments are required for the RTI. Therefore PiDES-RTI provides rigorous semantics flexibility and scalability for modeling complex simulation systems. In the next chapter a framework of using existing π-calculus tools to perform model checking will be presented.

105 Chapter 6 PiDES Toolbox This chapter presents a framework for utilizing existing tools to perform model checking and verification for PiDES models. Section 6. introduces the tools can be used for performing PiDES model checking. Section 6. presents a framework of performing PiDES model checking. Section 6.3 demonstrates how to use a tool called HAL to perform model checking. Finally Section 6.4 concludes the chapter with a short discussion of potentials and limitations of model checking tools used in this thesis. 6. Overview of π-calculus Tools 6.. π-calculus Model Checking Tools Many π-calculus model checking tools have been developed such as the Mobility Workbench (MWB) (Victor and Moller 994) the HD Automata Laboratory (HAL) (Ferrari et al. 003) etc. These tools use Model Logic or Temporal Logic to define formulae and then use the formulae to verify the models (Ferrari et al. 003; Victor and Moller 994). In the following sections HAL is used as an example to illustrate how to check and verify PiDES models.

106 6.. Logic Formula for Model Checking 95 HAL uses a variation of temporal logic called π-logic (Ferrari et al. 003). The syntax of π-logic is given by Eq. 6.: ω = true false ~ ω ω & ω' EX{ e} ω < e > ω EFω (6.) where: ω is a π-logic term; ~ ω: if and only if not ω; ω & ω : if and only if ω and ω ; EX{e} ω: for a process P if and only if there exists P e P' and ω holds for P ; <e> ω: if and only if there exists a set of process P 0 P P n and e such that P τ τ e = P0 P P n Pn L and ω holds for P n ; EF ω: if and only if there exists a set of process P 0 P P n and events e e e n such that P e e en = P0 P Pn L P and ω n holds for P n. Some useful derived operators can be defined: ω ω : means ~(~ω & ~ω ); AX{e}ω: means ~EX{e}~ω; [e]ω: means ~<e>~ ω; AG ω: means ~EF~ ω that is ω is always true.

107 More discussion about π-logic can be found in (Ferrari et al. 003) and on the 96 website In the next section definitions of basic PiDES properties in π-logic are presented. 6. A Framework for Checking PiDES Models 6.. General Approaches for PiDES Model Checking The general procedure for performing PiDES model checking can be defined as follows:. Define a set of properties to be investigated;. develop formulae of the properties (e.g. using π-logic); 3. verify the formulae against the PiDES model (e.g. using HAL) and improve the model accordingly; and 4. repeat step to 3 until all the properties been verified. 6.. Basic Property Formulae In this section π-logic formulae for basic properties of PiDES models such as reachability liveness blocking deadlock etc. are presented Reachability Eq. 6. defines the reachability of an action π.

108 97 Reachabili ty = EF π (6.) It returns true if action π will be performed at some time in the future Blocking There are two types of blocking: starving and over-pacing as defined in Eq. 6.3: Starving Overpacing = = EF < a?* > true & < a!* > EF < a?* > false) false & < a!* > true (6.3) where a is an event Liveness The formula for liveness is defined in Eq. 6.4: Liveness = AG( < a?* > true < a!* > true) a pe( P) se( P) (6.4) It basically means that for any published event there is a corresponding subscribed event. In other words there is no blocking Through Through means the expected resulting event e o of an input event e i will happen eventually as shown in Eq. 6.5: Through = AG([ e?*] EF( < e!* true)) (6.5) i o >

109 A typical application of through is to answer questions like: will a part entering a production line eventually leave out of the line? Deadlock Deadlock can take several forms; the definition presented in Section limits a deadlock to a situation of endless loop. This definition is fairly difficult to implement. Here a relaxed definition of deadlock is used which is: a deadlock is a situation that some expected output may not happen. Thus a deadlock is defined as Eq. 6.6: Deadlock = ~ Through (6.6) 6..3 Model Verification Formulae Some of the properties presented above may or may not be interested by a specific model. Form example it is perfectly fine for a model which can be blocked or deadlocked. In some cases it is the modeler s intent to design such a model. Besides the above commonly used properties many other properties can be defined using π-logic. The most important model checking question would be: how do we know if a model conforms to the specification? These model verification formulae vary from one model to another and can generalized as path formulae. A path formula is an invariant of a trajectory of certain events of a model. There are two types of path formulae:

110 99 Specify the trajectory of a sequence of events (through different event channels); and specify the order of a set of event instances (through the same event channel). For example queue/buffer models often pose constraints on the behavior of how an entity enters or leaves a queue/buffer. Some important behaviors like FIFO (first in first out) and LIFO (last in first out) can be defined as Eq. 6.7 and Eq. 6.8: FIFO = AG( [ e i?p][ e i?p ][ eo! p] true) (6.7) LIFO = AG( [ e i?p][ e i?p ][ eo! p ] true) (6.8) As can be seen Eq. 6.7 and Eq. 6.8 define two path formulae that mandate in what order the events should occur (including events from the same channel and events from different channels). For a queue model as long as it has the property defined in Eq. 6.7 it conforms to the FIFO queue design specification. If the model is also deadlock free then it can be concluded that the model is correct. More discussions about constructing formula can be found in (Ferrari et al. 003). 6.3 Case Study In this section HAL (Ferrari et al. 003) is used to demonstrate advanced model checking for PiDES models. The PiDES models in Eq. 4.3 Eq and Eq are rewritten in HAL s syntax without time delays (HAL does not support time delay):

111 define A(nrabrap) = nr?(p).a!p.a(nrabrap) + br?(p).a!p.a(nrabrap) 00 define B(arbnrbp) = ar?(p).b!p.b(arbnrbp) + nr?(p).b!p.b(arbnrbp) define R(nrnraarabbbrp) = nr!p.r(nrnraarabbbrp) + nr!p.r(nrnraarabbbrp) + a?(p).ar!p.r(nrnraarabbbrp) + a?(p).r(nrnraarabbbrp) + b?(p).r(nrnraarabbbrp) + b?(p).br!p.r(nrnraarabbbrp) (6.9) build A build B build R define F() = (nrnraarabbbrp) ( A(nrabrap) B(arbnrbp) R(nrnraarabbbrp)) build F The HAL online services webpage is shown in Figure 6-:

112 0 Figure 6-: The HAL Online Services The scenarios of deadlock can be obtained by checking the models against certain formula written in π-logic. For example Eq. 6.0 defines a conjunction that a part (send to machine A from robot R through name nr) will eventually leave the system (received by robot R through name b): define Through = AG([nr?p]EF(<b!p>true)) (6.0)

113 As can be seen in Figure 6- HAL returns a result FALSE which means the 0 conjunction is not true. Therefore the system is not deadlock free. Figure 6-: A Deadlock Scenarios Eq. 6.: Now consider introducing a controller M to the above model as shown in

114 M = r p ). bd( p ). r( p ). ad( p ). R (6.) ( 03 where event r i informs R to release a new part i into the system (i = or ); event bd receives the signal that a part has left the system; and event ad receives the signal that a part has left the system. Thus M imposes constraints on how R can release new parts. Accordingly model R and FMS are also modified as follows (Eq. 6. and Eq. 6.3): R = r( p ). nr( p ). τ (). R r( p ). nr( p ). τ (). R a( p ). τ (). ar( p ). τ (). R a( p ). τ (). ad( p ). R b( p ). τ (). bd( p ) R b( p ). τ (). br( p ). τ (). R (6.) FMS = C ( A B R M ) (6.3) CC fin As a result the system now releases part and alternately and always waits until the previous part exiting the system before releasing the next one. The through formulae are now defined in Eq. 6.4 and Eq. 6.5: define Through = AG([r!p]EF(<bd!p>true)) (6.4) define Through = AG([r!p]EF(<ad!p>true)) (6.5) Now the system is deadlock free because any part enters the system will eventually leaves the system. The checking result is shown in Figure 6-3:

115 Figure 6-3: Deadlock Free Scenario 04

116 6.4 Summary 05 This chapter presents a framework of using existing tools for performing PiDES model checking. The capability and performance varies from one tool to another. For example MWB provides high level operators such as deadlock bi-simulation etc. while HAL can only perform checking against formulae. However it seems HAL is faster and more reliable. In addition neither MWB nor HAL has direct support for some stochastic extensions of PiDES (e.g. time delay). Therefore the usage of MWB and HAL is limited. In the next chapter an implementation of PiDES and PiDES-RTI will be presented.

117 Chapter 7 Implementation This chapter develops a framework for implementing PiDES and PiDES-RTI as they were presented in Chapters 4 and 5. Section 6. gives an overview of the architecture of the implementation. Section 6. describes the PiDES language used to define PiDEFs. Section 6.3 presents the PiDES interpreter which translates PiDES models into Java code. Section 6.4 develops a runtime environment to execute the Java code generated by the PiDES interpreter. Section 6.5 illustrates the usage of the implementation through a case study. Finally Section 6.6 concludes the chapter with a short discussion of the capabilities and limitations of the implementation. 7. Architecture The implementation consists of a definition of PiDES language an Interpreter and a Runtime Environment. First a PiFED File written in PiDES language is interpreted by the Interpreter which produces Java Code. Then the Java Code is then linked to the pre-defined classes in the Runtime Environment. Finally the linked Java Code is executed by the Java Virtual Machine. The whole process is shown in Figure 7-:

118 07 PiFED File Interpreter PiDES Java Code Runtime Environment Java Code Java Virtual Machine Figure 7-: PiDES Implementation Architecture 7. PiDES Language As discussed in Chapter 5 the definition of a PiDES federation is captured in a PiFED which is represented using a sequence of compilation units of the PiDES language. 7.. Compilation Unit A compilation unit can be one of: ) a federation declaration ) a federate declaration or 3) a statement declaration. The syntax of compilation unit is shown in Table 7-:

119 08 Table 7-: Declaration Syntax Compilation Unit ::= Federation Declaration Declare a federation Federate Declaration Declare a federate Statement Declaration Declare a statement A typical PiFED has one federation declaration which in turn has many federate declarations. However it is possible that a PiFED has only federate declarations. A complete example of PiFED will be presented shortly Federation Declaration The syntax of federation declaration is shown in Table 7-: Table 7-: Federation Declaration Syntax Federation id [ CCC_FIN CCC_REP ] ( federate_id ( federate_id )* ) { ( Federate Declaration )* } Although OCC can be used for defining federations as discussed in Chapter 5 its usage is very limited. Therefore it is not included in the above definition. For example the FMS case presented in Chapter 5 can be written in PiDES language as follows: Federation F CCC_FIN ( A B R) { } where F is the identifier (name) of the federation A B and R are the identifiers of the federates and CCC_FIN is the coordination context being used.

120 7... Federate Declaration 09 The syntax of federate declaration is shown below: Federate = composition; A federate is defined as a composition process which will be discussed shortly Statement Declaration The syntax of statement declaration is shown below: Run federation_id [maximum_run_time]; There is only one statement used to start a federation. The optional maximum_run_time defines the maximum time a federation should run. If maximum_run_time is omitted a federation runs infinitely. 7.. Process Definition The mathematic symbols of PiDES are encoded in ASCII as shown in Table 7-3: Table 7-3: PiDES ASCII Encoding PiDES term ASCII encoding y) x ( y) #(x y) τ tau() νx new(x) φ ( p) prob(p) σ norm or con The syntax of defining a PiDES process is shown in Table 7-4.

121 0 Table 7-4: Process Syntax Composition ::= Summation ( Summation)* Summation ::= Sequence ( + Sequence )* Sequence ::= AtomicProcess (. AtomicProcess)* AtomicProcess ::= PiName Inaction Action ( Composition ) RestrictionProcess RestrictionProcess ::= new ( PiNameList ) ( Composition ) Action ::= (Tau Send Receive) Send ::= (Condition)? # PiName ( PiName ) Receive PiName ( PiName ) Tau ::= (ProbabilityTau DelayTau) ProbabilityTau ::= prob ( <NUMBER> ) tau DelayTau ::= tau ( ( (<NUMBER> Distribution) ) )? Inaction ::= nil PiName ::= <PINAME> PiNameList ::= <PINAME> ( <PINAME>)* Condition ::= [ (<PINAME> <NUMBER>) ComparisonOp ( <PINAME> <NUMBER> ) ] ComparisonOp ::= > >= < <= ==!= Distribution ::= ( DistNorm DistConst ) DistNorm ::= norm ( <NUMBER> <NUMBER> ) DistConst ::= con ( <NUMBER> ) To simplify the implementation the replication process is omitted. However a replication process can be defined recursively by using the above syntax. A complete collection of PiDES language can be found in Appendix A. 7.3 PiDES Interpreter The interpreter reads a PiFED file written in the above PiDES language and translates it into Java objects. The process of interpretation is shown in Figure 7-:

122 PiFED File Tokenizer (Token.java) Grammar (pi.jjt) PiDES Tokens Parser (PiParser.java) AST Tree Translator (PiParserVisitorAdaptor.java) PiDES Java Code (Process Tree) Figure 7-: PiDES Interpreter The Tokenizer (in file Token.java) and Parser (in file PiParser.java) are automatically generated by JavaCC (JavaCC 007) from the grammar file pi.jjt. The output of the Parser is an Advance Syntax Tree (AST) (JavaCC 007). Then the Translator visits each node of the AST tree and translates nodes into corresponding PiDES objects defined in the Runtime Environment. The Translator is implemented in the file PiParserVisitorAdaptor.java. The generated Java code is a collection of PiDES objects provided by the PiDES Runtime Environment. 7.4 Runtime Environment The Runtime Environment provides runtime supporting for PiDES Java code generated by the PiDES interpreter. It consists of three sets of Java classes:

123 . PiDES process related Java classes. These classes define executable PiDES classes such as process action etc. The class diagram of PiDES classes is presented in Figure RTI related Java classes. These classes implement a minimal set of services provided by HLA RTI. 3. Coordination related Java classes. These classes implement the three essential coordination mechanisms: composition summation and sequence. Entity -name : String..*..*..* Process -parent[] : Process PiName Channel Event -istimestamporder : bool Condition -has CoordinatedProcess -coordinationcontext[] : CoordinationContext 0..* AtomicProcess CompositinProcess SummationProcess SequenceProcess ProcessExpression Action Inaction -process : Process -condition : Event RestrictionProcess -restrictednames[0..*] : Entity CompositionContext SummationContext SequenceContext TauAction ExternalAction -channel[] : Channel CoordinationContext -owner[] : Process -processes[..*] : Process ProbabilityTau DelayTau ReceiveAction SendAction Figure 7-3: PiDES Processes Class Diagram All the source files are listed in Appendix B.

124 7.5 Case Study 3 The FMS case presented in Chapter 4 and 5 can be written in PiDES language as shown in Table 7-5: Table 7-5: The FMS Case Code federation F ccc_fin(abr) { federate A federate B federate R = #nr(p).tau().r + #nr(p).tau().r } Run F 00; Federation F will run for 00 units of logical time and then stop. The following code demonstrates how to parse the above PiDES code: PiFED pifed = PiParser.parsePiFED("fms.txt"); where fms.txt is a file contains the code presented in Table 7-5. The parser then generates an instance of class PiFED (pifed) which contains a PiProcess tree as shown in Figure 7-4:

125 Figure 7-4: The FMS Case Java Code Structure 4

126 To start the federation execution simply call the run method of pifed: 5 pifed.run(); One possible result is shown in Table 7-6: Table 7-6: FMS Case Execution Output R(9) 0.0 Send(nr) B() 0.0 Receive(nr) B() 4.0 Delay(4.0) B() 4.0 Send(b) R(9).0 Delay(.0) R(5) 4.0 Receive(b) R(5) 5.0 Delay(.0) R(5) 5.0 Send(br) R(5) 6.0 Delay(.0) A(3) 5.0 Receive(br) A(3) 0.0 Delay(5.0) A(3) 0.0 Send(a) The output is divided into three columns:. the first column is the name of the federate (e.g. R(9) which means federate R the number in the parenthesis is the current thread ID used by the federate execution which is for debugging only);. the second column is the federate s current logical time. 3. the third column is the nature of the action. It can be a receive action (i.e. Receive(nr) which means receiving an event from channel nr); a send action (i.e. Send(nr) which means sending an event through channel nr) or a tau action (i.e. Delay(.0) which means delaying one unit time).

127 The reactions shown in Table 7-6 can be verified using the same deduction 6 process presented in Section A screen shot of running the demo case is shown in Figure 7-5: Figure 7-5: Running Demo Case As mentioned in previous chapters this system can run into deadlock. In fact after try a few runs the demo program produces a deadlocked scenario as follows: R(9) R(9) R(3) 0.0 Send(nr).0 Delay(.0).0 Send(nr) The source code and detailed instruction manual for using PiDES are available in the companion CD or upon request.