Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA.

Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA Tom Lake InterGlossa, Ltd, UK Copyright: University of Arizona Arizona Center for Integrative Modeling and Simulation All rights reserved, SIW 2000

DEVS/HLA/CORBA TutorialSIW(fall 2000)2 Navigating Course Modules M&S in DoD & Industry Module 1 System Concepts Module 2 Basic DEVS Concepts Module 3 DEVS Formalism Module 4 DEVS OO Computational Environment Module 5 Creating DEVS-C++/Java Models Module 6 Part 2 HLA/CORBA

DEVS/HLA/CORBA TutorialSIW(fall 2000)3 Navigating Course Modules (Cont.) HLA Federation Development Module 8 HLA Basics Module 7 Creating Federations in DEVS/HLA Module 11 Efficient Large-Scale Distributed Simulation Module 17 DEVS/HLA Design & Implementation Module10 Modeling & Simulation Foundation (Modules 1:6) DEVS/HLA Requirements Module 9 DEVS/HLA Joint MEASURE Module 18 DEVS-based TOOLS Module 20 Zero Lookahead Simulation Module19

DEVS/HLA/CORBA TutorialSIW(fall 2000)4 Navigating Course Modules (Cont.) DEVS/CORBA Requirements, Design, Impl. Module13 CORBA Basics Module 12 Modeling & Simulation Foundation (Modules 1:6) SES Concepts Module14 Distributed Co-Design M&S Module 16 Collaborative/Distributed DEVS M&S Module 15 DEVS-based TOOLS Module 20 Efficient Large-Scale Distributed Simulation Module 17 DEVS/HLA Joint MEASURE Module18 Zero Lookahead Simulation Module19 Summary, More Info, AZ Center for M&S

u Rise of M&S in DoD u Rationale and Overview of HLA u M&S Current and Future: SBA u Enabling Role of Discrete Event M&S (DEVS) u Comprehensive Architecture for M&S Module1: M&S in DoD: Roles of HLA and DEVS

DEVS/HLA/CORBA TutorialSIW(fall 2000)6 u Provides full service access to the broad HLA user community –materials, software distribution, training registration HLA User Services:DMSO HLA Home Page

DEVS/HLA/CORBA TutorialSIW(fall 2000)7 Large scale Distributed training simulations Defense budget cuts Army ranks M&S as top ten priority DMSO (Defense M&S Office) DoD mandates HLA (High Level Architecture) SBA (Simulation-Based Acquisition) is latest push Simulation industry develops Education and Training of M&S Professionals The Rise of M&S in DoD

DEVS/HLA/CORBA TutorialSIW(fall 2000)8 US Defense HLA Policy. “Under the authority of [DoD Directive 5000.59], and as prescribed by [the DoD Modeling and Simulation Master Plan], I designate the High Level Architecture as the standard technical architecture for all DoD simulations.” HLA supersedes Distributed Interactive Simulation (DIS) and ALSP “No Can” Dates -“No Can Pay”- first day of FY99 u no funds for developing/modifying non-HLA-compliant simulations -“No Can Play”- first day of FY01 u retirement of non-HLA-compliant simulations Waivers must be decided on a corporate basis Source: Intro to HLA (JDITEC4_98.ppt) Dr. Paul Kaminski, USD(A&T) 10 September 1996

DEVS/HLA/CORBA TutorialSIW(fall 2000)9 Scope of HLA u Applicable to broad range of functional areas (e.g., training, contingency planning, analysis, and acquisition) u Applicable to simulations involving pure software representations, man-in-the-loop simulators, and interfaces to live components (e.g., instrumented- weapon systems and C3 systems) Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)10 HLA M&S Infrastructure Common tools Common Software Modules Communications Intellectual Model and Data Repositories Support for Collaboration HLA and Simulation Based Acquisition Concept Analysis Research, Development, & Engineering Test & Evaluation Policy Development Training On-line Control Source: NRC Modeling and Simulation, Vol. 9, National Academy Press

DEVS/HLA/CORBA TutorialSIW(fall 2000)11 Rationale for HLA Design u Basic premises: – No single, monolithic simulation can satisfy the needs of all users – All uses of simulations and useful ways of combining them cannot be anticipated in advance – Future technological capabilities and a variety of operating configurations must be accommodated u Consequence: Need composable approach to constructing simulation federations u Resulting design principles: – Federations of simulations constructed from modular components with well-defined functionality and interfaces – Specific simulation functionality separated from general purpose supporting runtime infrastructure Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)12 The High Level Architecture (HLA) Interface Architecture specifies -Ten Rules which define relationships among federation components Source: Intro to HLA (JDITEC4_98.ppt) -An Object Model Template which specifies the form in which simulation elements are described - FOM -- federation object model - SOM -- simulation object model Live Participants Support Utilities Interfaces to Live Players Simulations Architecture calls for a federation of simulations (federates) The HLA is not the RTI the RTI must support Rules, OMT and IF specifications commercial development of software/hardware implementations to address specific application and performance requirements C++ Ada 95 CORBA IDL Java -An Interface Specification which describes the way simulations interact during operation Interface Runtime Infrastructure (RTI) Federation Management Declaration Management Object Management Ownership Management Time Management Data Distribution Management

DEVS/HLA/CORBA TutorialSIW(fall 2000)13 Network RTI Executive DEVS Federate RTI Ambasador Joint Measure DEVS Federate RTI Ambasador OPNet Comm Model DEVS Federate RTI Ambasador DD21 (Warship Model) Example: HLA Distributed Simulation

DEVS/HLA/CORBA TutorialSIW(fall 2000)14 M&S Interoperability, Performance, & Reuse u Interoperability: –generic dynamic computer-based and non-computer-based systems »support a wide range of models and simulations –hierarchical construction »Well-defined functionality & interfacing –real time interoperability »Support design, testing and operational needs u Fundamental Premise –Modeling & Simulation are two distinct, yet complementary, activities. They provide the basis for building distributed simulation models.

DEVS/HLA/CORBA TutorialSIW(fall 2000)15 M&S Interoperability, Performance, & Reuse (Cont.) u Performance: –computational »local to each simulation –communication »among multiple simulations –both computational and communication efficiency issues underlie performance u Reuse: –model and simulation reuse (computer-based and otherwise) »centralized and distributed data and model repositories

DEVS/HLA/CORBA TutorialSIW(fall 2000)16 DEVS = Discrete Event System Specification Provides sound M&S framework Dynamic system representation capability Supports hierarchical, modular modeling DEVS/HLA User Friendly HLA-Compliant Environment DEVS Modeling & Simulation Framework HLA enables interoperability of existing simulations DEVS supports developing new simulation models

DEVS/HLA/CORBA TutorialSIW(fall 2000)17 Layered Architecture for M&S Network Supports all Hardware aspects of M&S Simulation Executes models Modeling Models::Attributes and Dynamics Search Searches, Evaluates Design Space Decision Decision Making in Application domains Collaboration Enable cooperation among participants Source: NRC Modeling and Simulation, Vol. 9, National Academy Press HLA DEVS

Module2: Fundamentals of Modeling & Simulation u Basic Systems Concepts u M&S Entities and Relations u Systems Models u DEVS Bus

DEVS/HLA/CORBA TutorialSIW(fall 2000)19 M&S Entities and Relations Real World Simulator modeling relation simulation relation Each entity is represented as a dynamic system Each relation is represented by a homomorphism or other equivalence Data: Input/output relation pairs structure for generating behavior claimed to represent real world Device for executing model Model

DEVS/HLA/CORBA TutorialSIW(fall 2000)20 M&S Entities and Relation(cont’d) Real World Simulator modeling relation simulation relation Simulator Distributed Simulation Model should be easily migrated from Single Workstation to Distributed Simulation Environment Model

DEVS/HLA/CORBA TutorialSIW(fall 2000)21 M&S Entities and Relation(cont’d) Real World modeling relation simulation relation Experimental frame specifies conditions under which the system is experimented with and observed Experimental Frame Simulator Model

DEVS/HLA/CORBA TutorialSIW(fall 2000)22 DESS: differential equation DEVS: discrete event DTSS: difference equation System Specification: Dynamic Systems System Simulator: Event Processor DEVS model time to next event, state at next event... Simulator: Recursive Algorithm System DTSS model: q(t+1) = a*q(t)+ b*x(t) System Simulator: Numerical Integrator DESS model: dq/dt = a*q +bx

DEVS/HLA/CORBA TutorialSIW(fall 2000)23 Continuous and Discrete System Models

DEVS/HLA/CORBA TutorialSIW(fall 2000)24 DEVS Bus Concept RTI message DEVS HLA DEVS HLA message DEVS HLA Diff Eq. Systems Diff Eq. Systems Discrete Time Systems Discrete Event Formalisms

Module 3: Basic DEVS Concepts u Atomic Models u Coupled Models u Dynamics u Components u Coupling

DEVS/HLA/CORBA TutorialSIW(fall 2000)26 Two Fundamental Model Types u Atomic: lowest level model, contains structural dynamics -- model level modularity  HLA federate u Coupled: composed of one or more atomic and/or coupled models  HLA federation

DEVS/HLA/CORBA TutorialSIW(fall 2000)27 Models Capture System’s Dynamic Behavior  Simulation models capture a systems’ dynamic behavior  how it organizes itself over time in response to imposed conditions and stimuli. u Such modeling is required in order to be able to predict how a system will react to external inputs and proposed structural changes.

DEVS/HLA/CORBA TutorialSIW(fall 2000)28 Components A component can be viewed as a system with inputs and outputs. An atomic component an internal structure which dictates how inputs/states are transformed to outputs. states functions INTERNAL STRUCTURE inputsoutputs components are coupled together to create coupled models which themselves can be components in larger systems

DEVS/HLA/CORBA TutorialSIW(fall 2000)29 Component Discrete Event Dynamics To capture system’s dynamics, we need to represent its states and how they change over time, autonomously and in response to external events:: »Inputs »States »Outputs »Time advance »Internal Dynamics

DEVS/HLA/CORBA TutorialSIW(fall 2000)30 Example of Atomic Component: Repair Shop A repair shop receives devices for repair from a customer. Each device requires a certain length of time for it to be repaired. Upon the repair of the device, it is sent to the customer. faulty device new parts States: busy idle Functions: seal-crack replace-part INTERNAL STRUCTURE repaired device order parts

DEVS/HLA/CORBA TutorialSIW(fall 2000)31 Component Discrete Event Dynamics(cont’d) External Event Transition Function: transforms a state and an input event into another state (e.g., when a faulty device arrives and if idle then start repairing It ) Output Function that maps a state into an output (e.g., when the number of parts available falls below a minimum number, issue an order to restock the part.) Time Advance Function: determines the time to remain in a state (e.g., schedule an operation to fix a device using available part.) Internal Event Transition Function: transforms a state into another state after the time advance has elapsed (e.g., given that there are 10 parts available and a broken part requiring 7 of them, after fixing the broken part, 3 parts will remain.)

DEVS/HLA/CORBA TutorialSIW(fall 2000)32 Experimental Frame Example: Coupled Model faulty device new parts States: busy idle Functions: seal-crack replace-part Repair Shop repaired device order parts TransducerGenerator Parts Supplier order parts

Module 4: DEVS Formalism u Discrete-event System Specification u Basic DEVS for atomic models u DEVS Coupled Models u Closure Under Coupling u Hierarchical Model Construction

DEVS/HLA/CORBA TutorialSIW(fall 2000)34 The DEVS Framework for M&S u Generic Dynamic Systems Formalism u Well Defined Coupling of Components u Hierarchical Construction u Stand Alone Testing u Repository Reuse u Event-Based, Efficient Simulation u Includes Continuous and Discrete Time Systems u Object-Oriented Implementation

DEVS/HLA/CORBA TutorialSIW(fall 2000)35 DEVS Atomic Model u input events u output events u state variables u state transition functions u output function u timing function Elements of an atomic model:

DEVS/HLA/CORBA TutorialSIW(fall 2000)36 DEVS =  X, S, Y,  int,  ext,  con, ta,  X: a set of input events Y: a set of output events S: a set of states ta: S  R + 0,  time advance function  int : S  S internal transition function  ext : Q x X b  S external transition function  con : Q x X b  S confluent transition function where X b is a set of bags over elements in X Q = {(s,e) | s   S, 0  e  ta(s)} : S  Y output function Atomic Model Specification

DEVS/HLA/CORBA TutorialSIW(fall 2000)37 Internal Transition Function/Output Function ta(s) s ( s ) y s ’ =  int ( s ) DEVS =  X, S, Y,  int,  ext,  con, ta, 

DEVS/HLA/CORBA TutorialSIW(fall 2000)38 ta(s) s DEVS =  X, S, Y,  int,  ext,  con, ta,  x s ’ =  ext ( s, e, x) External Transition Function e

DEVS/HLA/CORBA TutorialSIW(fall 2000)39 ta(s) s DEVS =  X, S, Y,  int,  ext,  con, ta,  x s ’ =  con ( s, ta(s), x) Confluent Transition Function e

DEVS/HLA/CORBA TutorialSIW(fall 2000)40 Coupled Model u Components u Interconnections –Internal Couplings –External Input Couplings –External Output Couplings Elements of coupled model:

DEVS/HLA/CORBA TutorialSIW(fall 2000)41 Coupled Model Specification DN =  X, Y, D, {M i }, {I i }, {Z i,j }  X : a set of input events. Y : a set of output events. D : an index set (names) for the components of the coupled model. For each i  D, M i is a component DEVS model. For each i  D  self, I i is the set of influencees of i. For each j  D  self, Z i,j is output translation mapping

DEVS/HLA/CORBA TutorialSIW(fall 2000)42 DN  X, Y, D, {M i }, {I i }, {Z i,j }  DEVS  X, S, Y,  int,  ext,  con, ta,  DEVS  X, S, Y,  int,  ext,  con, ta,  Every DEVS coupled model has a DEVS Basic equivalent Closure Under Coupling

DEVS/HLA/CORBA TutorialSIW(fall 2000)43 EFA ARCH EF GEN TRANSD EF ARCH COORD PROC Hierarchical Model Construction

DEVS/HLA/CORBA TutorialSIW(fall 2000)44 Coupled Model gpt processor (proc) out arrived solved outin generator (genr) transducer (transd) out stop start

DEVS/HLA/CORBA TutorialSIW(fall 2000)45 Hierarchical Coupled Model efP processor (proc) out arrived solved outin generator (genr) transducer (transd) out stop start ef solved start out

DEVS/HLA/CORBA TutorialSIW(fall 2000)46 Experimental Frame/Model Modularity efP Processor With Queue (procQ) out solved outin out start ef

Module 5: DEVS OO Computational Environment u Container Classes u Object Oriented DEVS u DEVS Simulator Principles u DEVS M&S Environments

DEVS/HLA/CORBA TutorialSIW(fall 2000)48 Heterogeneous Container Class Library container entity function relation set bag liststackqueue order is in? size? add ask_all tell_all num_of? remove add remove assoc_all? replace assoc? name? equal? max? greater_than? remove add remove front? push pop top? insert remove list_ref?

DEVS/HLA/CORBA TutorialSIW(fall 2000)49 ENTITY Object-Oriented DEVS Classes DEVS CONTAINER entity ATOMIC DIGRAPH devs MESSAGE content port, value  ENTITY Legend inherits can hold

DEVS/HLA/CORBA TutorialSIW(fall 2000)50 Simulator/Simulation Concepts u Simulator is responsible for executing a model’s dynamics (represented as instructions) in a given formalism. u Abstract simulator is a characterization of what needs to be done in executing a model’s instructions –atomic simulator –coupled simulator u Simulation engines enforce particular realizations of an abstract simulator u Simulations can be executed as: –Sequential –Parallel –Distributed (sequential/parallel)

DEVS/HLA/CORBA TutorialSIW(fall 2000)51 tL = tN tN = tN + ta() tL = 0 tN = ta() initialize Atomic DEVS Simulator simulation cycle External Event (Input) Elapsed Time tL = time of last event tN = time of next event Elapsed time enables user to inject input into the model at multiples of elapsed periods

DEVS/HLA/CORBA TutorialSIW(fall 2000)52 tL = tN tN = tN + ta() tL = 0 tN = ta() initialize Coupled DEVS Simulator Coupled Model simulation cycle tL = time of last event tN = time of next event

DEVS/HLA/CORBA TutorialSIW(fall 2000)53 1Compute the global next event time, t N : use reduce to get minimum of component times to next event (tN) 2Tell all components the global t N and if component is imminent (t N == global t N ), then generate output message(using ) 3Sort and distribute (using coupling) output messages. 4Tell all components if component is imminent (t N == global t N ) or has incoming mail (external events) or both then execute transition function (deltfunc). Coupled Model Simulation Cycle

DEVS/HLA/CORBA TutorialSIW(fall 2000)54 simulator Component tN tN. tL After each transition tN = t + ta(), tL = t simulator Component tN tN. tL simulator Component tN tN. tL coordinator Coupled Model 1. nextTN 2. outTN 3 getOut 4 getOut 5 applyDelt DEVS Simulation Protocol NOTE: Component can be a Coupled Model in which case coordindator would be needed instead of simulator.

DEVS/HLA/CORBA TutorialSIW(fall 2000)55 An object-oriented computational environment based on the DEVS formalism enabling users to construct flexible, complex, and multilevel models robust, user-friendly, reusable fashion and execute them in both desk-top and distributed simulation platforms DEVS M&S Environments

Module 6: Creating DEVS C++/Java Models u Atomic Models in DEVSJAVA u Coupled Models in DEVSJAVA u Examples: Job Processors, EF elements u Examples: DEVS mapping of explosion u Hierarchical Models

DEVS/HLA/CORBA TutorialSIW(fall 2000)57 Generator Atomic Model //Constructor for Generator Model public genr(String name,int Int_arr_time){ super(name); inports.add("stop"); inports.add("start"); inports.add("setPeriod"); outports.add("out"); phases.add("busy"); int_arr_time = Int_arr_time ; } //External Transition Function (  ext ) public void deltext(int e,message x){ Continue(e); for(int i=0; i< x.get_length();i++) if(message_on_port(x,"setPeriod",i)){ entity en = x.get_val_on_port("setPeriod",i); intEnt in = (intEnt)en; int_arr_time = in.getv(); } for(int i=0; i< x.get_length();i++) if(message_on_port(x,"start",i)){ ent = x.get_val_on_port("start",i); hold_in("busy",int_arr_time); } for(int i=0; i< x.get_length();i++) if(message_on_port(x,"stop",i)) passivate(); } Generator out stop start setPeriod //Internal Transition Function (  int ) public void deltint( ){ if(phase_is("busy")){ count = count +1; hold_in("busy",int_arr_time); } //Output Function: ( ) public message out( ){ message m = new message(); content con = make_content("out", new entity("job" + count)); m.add(con); return m; }

DEVS/HLA/CORBA TutorialSIW(fall 2000)58 Processor Atomic Model //External Transition Function (  ext ) public void deltext(int e,message x){ Continue(e); for(int i=0; i< x.get_length();i++) if(message_on_port(x,"setProcTime",i)){ entity en = x.get_val_on_port("setProcTime",i); intEnt in = (intEnt)en; processing_time = in.getv(); } if(phase_is("passive")){ for(int i=0; i< x.get_length();i++) if(message_on_port(x,"in",i)){ job = x.get_val_on_port("in",i); hold_in("busy",processing_time); state = 1; } Processor out in setProcTime //Output Transition Function ( ) public message out( ){ System.out.println("Output Function " + name); message m = new message(); if(phase_is("busy")){ content con = make_content("out",job); m.add(con); con = make_content("outName",new pair(this,job)); m.add(con); } return m; } //Internal Transition Function (  int ) public void deltint( ){ passivate(); state = 0; job = new entity("none"); }

DEVS/HLA/CORBA TutorialSIW(fall 2000)59 Generator/Processor/Transducer Coupled Model //Constructor for GPT Model //create components atomic am1 = new genr(“Generator”); atomic am2 = new proc(“Processor”); atomic am3 = new transd(“Transducer”); //add components add(am1); add(am2); add(am3); //Constructor for GPT Model (Cont.) //specify couplings show_state(); Add_coupling(am1,"out",am2,"in"); Add_coupling(am1,"out",am3,"arrived"); …. Add_coupling(am2,"out",am3,”solved"); …. Add_coupling(this,"start",am1,"start"); Add_coupling(am2,"out",this,"out"); gpt processor (proc) out arrived solved outin generator (genr) transducer (transd) out stop start

DEVS/HLA/CORBA TutorialSIW(fall 2000)61 Hierarchical Modeling (Cont.) //Constructor for EF Model public class EF extends digraph{ //create components atomic am1 = new genr(”Generator",procTime, numJobs); atomic am2 = new transd("transd"); //Specify Internal couplings Add_coupling(am1,"out",am2,”arrived"); //Specify External Input Couplings Add_coupling(this,”start",am2,”start"); Add_coupling(this,”solved",am2,”solved"); //Specify External Output Couplings Add_coupling(am1,”out",this,”out"); Add_coupling(am2,”out",this,”out"); …. } //Constructor for pQEF Model public class pQEF extends digraph{ //create components digraph cm1 = new EF(”EF",procTime, numJobs); atomic am1 = new pQ(”ProcessorWqueue"); add(am1); add(cm1); //Internal Couplings Add_coupling(cm1,"out",am1,”in"); Add_coupling(am1,”out",cm1,”solved"); …. } Components: Processor with Queue EF

DEVS/HLA/CORBA TutorialSIW(fall 2000)62 Explosion Example //Constructor for Coupled Model //create components atomic bomb = new bomb(“Bomb”); atomic counter = new counterM(“CM”); atomic target1 = new target(“Target1”); atomic target2 = new target(“Target2”); //add components add(bomb); add(counter); add(target1); add(target2); //specify couplings addCoupling(this, “start”, bomb, “fuse”);... addCoupling(counter, “defuse”, bomb, “defuse”); addCoupling(bomb, “explosion”, target2, “strike”);... addCoupling(taget1, “damage”, this, “damage”); CM target defuse fuse damagestrike CM bomb explosion damage start target strike damage

DEVS/HLA/CORBA TutorialSIW(fall 2000)63 fuse explosion Bomb defuse Explosion Example (Cont’d) a) defuse dormant dead live explode explosion External TransitionFn when receive fuse in phase dormanthold_in(live,5) when receive defuse in phase livehold_in(dormant,150) else continue Internal TransitionFn in phase live hold_in(explode,1) in phase explode passivate_in(dead) OutputFn in phase live output explosion 1501 10 fuse b)

Module 7: HLA Basics u HLA Highlights u Basic HLA terminology u Federation Rules u Run-Time Infrastructure (RTI) u RTI Services

DEVS/HLA/CORBA TutorialSIW(fall 2000)65 High Level Architecture : Highlights u Simulator interoperability and reuse u RTI implemented in C++,Java,Ada,... u live, simulated u humans, equipment, sensors u DoD mandated standard by 2001 Support Utilities Interface Interfaces to Live Players Runtime Infrastructure (RTI) Simulations

DEVS/HLA/CORBA TutorialSIW(fall 2000)66 Some Terminology u Federation: a set of simulations, a common federation object model, and supporting RTI, that are used together to form a larger model or simulation u Federate: a member of a federation; one simulation – Could represent one platform, like a cockpit simulator – Could represent an aggregate, like an entire national simulation of air traffic flow u Federation Execution: a session of a federation executing together Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)67 Some More Terminology u Object:: An entity in the domain being simulated by a federation that – is of interest to more than one federate – is handled by the Runtime Infrastructure u Interaction: a non-persistent, time-tagged event generated by one federate and received by others (through RTI) u Attribute: A named datum (defined in Federation Object Model) associated with each instance of a class of objects u Parameter: A named datum (defined in Federation Object Model) associated with each instance of a class of interactions Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)68 HLA Object Models and OMT u Federation Object Model (FOM) – A description of all shared information (objects, attributes, and interactions) essential to a particular federation u Simulation Object Model (SOM) – Describes objects, attributes and interactions in a particular simulation which can be used externally in a federation u Object Model Template (OMT) – Provides a common framework for HLA object model documentation – Fosters interoperability and reuse of simulations via the specification of a common representational framework Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)69 HLA Specification Elements Architecture specifies -10 Rules which define relationships among federation components – 5 for FOM – 5 for SOM -An Object Model Template which specifies the form in which simulation elements are described -An Interface Specification which describes the way simulations interact during operation Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)70 Federation Rules 1Federations shall have an HLA Federation Object Model (FOM), documented in accordance with the HLA Object Model Template (OMT). 2 In a federation, all representation of objects in the FOM shall be in the federates, not in the runtime infrastructure (RTI). 3During a federation execution, all exchange of FOM data among federates shall occur via the RTI. 4During a federation execution, federates shall interact with the runtime infrastructure (RTI) in accordance with the HLA interface specification. 5During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.

DEVS/HLA/CORBA TutorialSIW(fall 2000)71 Federate Rules 6Federates shall have an HLA Simulation Object Model (SOM), documented in accordance with the HLA Object Model Template (OMT). 7Federates shall be able to update and/or reflect any attributes of objects in their SOM and send and/or receive SOM object interactions externally, as specified in their SOM. 8Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution, as specified in their SOM. 9Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updates of attributes of objects, as specified in their SOM. 10Federates shall be able to manage local time in a way which will allow them to coordinate data exchange with other members of a federation.

DEVS/HLA/CORBA TutorialSIW(fall 2000)72 Interface Specification u Provides a specification of the functional interfaces between federates and the RTI – Interfaces are divided into six service groups u Each service specification includes: – Name and Descriptive Text – Supplied Arguments – Returned Arguments – Pre-conditions – Post-conditions – Exceptions – Related Services u Application Programmer Interfaces (APIs) in CORBA IDL, C++, Ada ’95 and Java

DEVS/HLA/CORBA TutorialSIW(fall 2000)73 Federation: A set of federates interacting via the RTI service and its FOM. Federate: A simulation component program and its SOM. FED (Federation Execution Data) file: It contains information derived from the FOM and used by the RTI at runtime. FedExec (Federation Executive): Responsible for federation management. Enables federates joining and resigning from the federation as well as facilitating data exchange among participating federates. RTIExec (RTI Executive): A global process managing the creation and destruction of federation executives. RID file: RTI Initialization Data. This data contains RTI vendor-specific information that is needed to run an RTI. RTI Components

DEVS/HLA/CORBA TutorialSIW(fall 2000)74 HLA RTI Service Categories CategoryFunctionality Create and delete federation executions Federation Management Join and resign federation executions Control checkpoint, synchronization, restart Establish intent to publish and subscribe Declaration Management to object attributes and interactions Create and delete object reflections Object Management Create and delete object instances Control attribute and interaction publication Transfer ownership of object attributes Ownership Management Time Management Coordinate the advance of logical time and its relationship to real time Data Distribution Mgmt Supports efficient routing of data

Module 8: HLA Federation Development u Federation Development & Execution Process (FEDEP) u HLA Tool Architecture u OMT u Object Model Development u Time management interoperability

DEVS/HLA/CORBA TutorialSIW(fall 2000)76 HLA Five Step Development Process Requirements Definition Conceptual Model Development Federation Design Federation Integration and Test Execute and Analyze Results Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)77 Federation Development & Execution Process Source: 99s-SIW-130.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)78 HLA Tool Architecture Object Model Development Tools RTIs FED Object Model Library Object Model Data Dictionary System DoD Data Dictionary System FOMs SOMs Data Dictionary FOMs SOMs DoD Data Stds. HLA Object Model Integrated Tools Suite Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)79 Object Model Development HLA Object Models: Describe Federate (Creating HLA SOM) PURPOSE: provide federate’s intrinsic capabilities (Note: Other means such as DEVS are needed to describe dynamics) Describe Federation (Creating HLA FOM) PURPOSE: provide inter-federate information exchange specification HLA Object Model Elements: object model identification object class structure interaction class structure attributes parameters routing space SOM/FOM lexicon

DEVS/HLA/CORBA TutorialSIW(fall 2000)80 Sample OMT Tables

DEVS/HLA/CORBA TutorialSIW(fall 2000)81 Object Model Development Attributes & parameters Information model contract Object classes Interaction classes HLA Object Models: Describe Federates (Creating SOM) other means are needed to describe federate design and functionality Describe Federation (Creating FOM) inter-federate information exchange

DEVS/HLA/CORBA TutorialSIW(fall 2000)82 Objects: HLA vs. Pure OO

DEVS/HLA/CORBA TutorialSIW(fall 2000)83 Challenge: Time Management Interoperability Run Time Infrastructure (RTI) training federate: real-time execution constructive federate: time-stepped execution Run Time Infrastructure (RTI) constructive federate: event driven execution Run Time Infrastructure (RTI) live component: real-time execution w/ hard deadlines Run Time Infrastructure (RTI) multiprocessor parallel simulation federate: optimistic Time Warp execution Run Time Infrastructure (RTI) Goal: provide services to support interoperability among federates with different local time management schemes in a single federation execution. Observation: RTI by itself cannot guarantee interoperability.

DEVS/HLA/CORBA TutorialSIW(fall 2000)84 Message Ordering Services Typical applicationstraining, T&Eanalysis Latency Reproduce before and after relationships? All federates see same ordering of events? Execution repeatable? Property low no Receive Order higher yes Time Stamp Order (TSO) The baseline HLA provides two types of message ordering: Receive Order: messages passed to federate in order of reception Time Stamp Order (TSO): successive messages passed to federate have non-decreasing time stamps u Receive order minimizes latency, does not prevent temporal anomalies u TSO prevents temporal anomalies, but has somewhat higher latency

Module 9: DEVS/HLA Requirements u HLA-compliant M&S environment u support model construction in C++/Java u support for FEDEP u integration with HLA Tool Architecture u layered architecture for flexibility u support for time management, logic and real time integration user orientation: shield user from HLA programming

DEVS/HLA/CORBA TutorialSIW(fall 2000)86 DEVS/HLA Support for FEDEP Requirements Definition Conceptual Model Development Federation Design Federation Integration and Test Execute and Analyze Results DEVS/HLA Source: Intro to HLA (JDITEC4_98.ppt)

DEVS/HLA/CORBA TutorialSIW(fall 2000)87 DEVS/HLA In Tool Architecture Object Model Development Tools RTIs FED Object Model Library Object Model Data Dictionary System DoD Data Dictionary System FOMs SOMs Data Dictionary FOMs SOMs DoD Data Stds. HLA Object Model Integrated Tools Suite DEVS/HLA

DEVS/HLA/CORBA TutorialSIW(fall 2000)88 DEVS coupled model * structure definition * component ~ attributes quantization * coupling DEVS/HLA Mapping Approach * State Updating * Interactions Object Declaration Initialization Registration P/S RTI-C++ Metadata Classes Attributes/Data Types Interactions OMDT

DEVS/HLA/CORBA TutorialSIW(fall 2000)89. Network Run Time Infrastructure Fedex RTI Ambasador DEVS Federate DEVS Federate RTI Ambasador RTI Executive DEVS Components as HLA Federates Internal transition function External transition function Output function Internal transition function External transition function Output function

DEVS/HLA/CORBA TutorialSIW(fall 2000)90 DEVS Parallel/ Distributed Simulation Protocol Network DEVS-C++DEVSJAVA MiddlewareCORBAHLA/RTI Time Warp Parallel DEVS Simulation Protocol WAN-Internet LAN Cluster Layer Alternatives (DEVS/HLA etc) DEVS Distributed Simulation Layers

DEVS/HLA/CORBA TutorialSIW(fall 2000)91 Time Management Integration & Migration High performance component PC workstation component live component: real-time execution w/ hard deadlines/windows RTI Operator Training: fast enough real-time Migration -- successively convert components of model from discrete event simulation to real time execution Integration -- enable real time execution to inter-operate with discrete event simulation High performance component PC workstation component

DEVS/HLA/CORBA TutorialSIW(fall 2000)92 DEVS/HLA High Level Automation Features Category Federation Management Declaration Management Object Management Ownership Management Time Management Data Distribution Mgmt DEVS/HLA Automates it: Yes No Yes: No: Yes No: Create and delete federation executions Join and resign federation executions Control checkpoint, synchronization, restart Establish intent to publish and subscribe to object attributes and interactions Create and delete object reflections Create and delete object instances Control attribute and interaction publication Transfer ownership of object attributes Coordinate the advance of logical time and its relationship to real time Quantization and Predictive Filtering Support efficient routing of data: HLA Routing Space

Module 10: DEVS/HLA Design and Implementation u augmented class hierarchy u interaction/updates u DEVS simulation protocol u migration and integration with real time

DEVS/HLA/CORBA TutorialSIW(fall 2000)94 DEVS/HLA Class Hierarchy entity Devs Atomicbase Atomic Digraph Coupledport HLAport quantizer attribute DevsFedAmb Federate Ambassador Federate

DEVS/HLA/CORBA TutorialSIW(fall 2000)95 Quantization is the mechanism used to automatically execute attributed updating Quantization and Attribute Updating Update triggered at threshold crossing

DEVS/HLA/CORBA TutorialSIW(fall 2000)96 DEVS/HLA:Pursuer-Evader Model in out Red Tank drive perceive Blue Tank Evader Evader Federate Pursuer Federate fireout firein Red Tank (Endo Model) position state update : quantized attribute (position) interaction: HLA port (fire ) + coupling fire Object class Object class

DEVS/HLA/CORBA TutorialSIW(fall 2000)97 Pursuer-Evader Model:Adding Viewer update(quantized attribute) interaction(HLA port coupling) in out Red Tank drive Red Tank Endo Model perceive Blue Tank Evader EvadWEndo PursWQuant position fireout firein Blue Tank Red Tank Transducer Viewer

DEVS/HLA/CORBA TutorialSIW(fall 2000)98 Attribute Communication Attribute quantizer value quant attrRtiId Devs value attributeList Send Attribute Interface attrRtiId value Attribute Message attrRtiId Attribute Set size Attribute Set Message attributeList Send Federate Receive Attribute Interface size DevsAttribute value attrRtiId Receive Federate

DEVS/HLA/CORBA TutorialSIW(fall 2000)99 Interaction Communication Devs Send Interaction Interface myDevs port address Devs Message Send FederateReceive Federate value Devs Receive Interaction Interface myClassId Parameters time Interaction Message tag

DEVS/HLA/CORBA TutorialSIW(fall 2000)100 Parallel/ Distributed Simulation Protocol DEVS Distributed Simulation Layers Network DEVS Middleware

DEVS/HLA/CORBA TutorialSIW(fall 2000)101 DEVS/HLA Simulation Protocol Create/join federation timeAdvGrant Event process DEVS cycle Request next time timeAdvGrant=FALSE Initialization create models add coupling setup object / interaction comm. Initialize time TRUE FALSE Compute input/output Send interactions Execute transition functions Update Attributes Time advance

DEVS/HLA TutorialUniversity of Arizona (1998)102 Communication Protocol between DEVS and RTI Initialization phase Devs RTI Models Create Models Setup Coupling initialize DevsRtiId instanceId attrRtiId myClassId,myParamId Time Advance Publish Object Class Register Object Pub/Sub Attributes Pub/Sub Interaction Create Fed. Execution Join Fed. Execution Federation Execution - Publish/Subscribe - Register Federation

DEVS/HLA TutorialUniversity of Arizona (1998)103 Communication Protocol between Devs and RTI Devs Internal Cycle - compute input output - internal transition - external transition - quantize attributes Cyclic Execution Phase Termin ate Devs Termin ate Fed. Ex. Time Advance Time Advance Req Update Update Attributes Update Interaction instanceId Termination Req Terminate Comm. Delete Models Time Advance Req Discover Object Update/receive Inter. Update/reflect Attr. (infinite) Grant Time Resign Fed. Execution Destroy Fed. Execution Federation Execution - advance Time - update Attributes - update Interactions

DEVS/HLA TutorialUniversity of Arizona (1998)104 DEVS/HLA Simulation Protocol Create/join federation timeAdvGrant Event process DEVS cycle Request next time timeAdvGrant=FLASE Compute input/output Send interaction Execute delta function Send Attributes Time advance Initialization create models add coupling setup object / interaction comm. Initialize time TRUE FALSE

DEVS/HLA TutorialUniversity of Arizona (1998)105 interactions = Output_funct(); Send interactions with time-stamp grantTime + epsilon; Int_tr_funct() ; Send timeAdvanceRequest (tN); Send tick(); apply quantizers to variables Send updateAttributeValues; } When receive timeAdvGrant(grantTime){ tL = grantTime; tN = grantTime + time_adv_funct(); Ext_tr_funct(e,x); When receive interactions (current time) { Extract input x from interactions e = current time - tL update variables When receive reflectAtributeValues{ } Send timeAdvanceRequest (tN); Send tick(); apply quantizers to variables Send updateAttributeValues; } tL = current time; tN = current time + time_adv_funct(); DEVS Cycle Logic- For Cancellation-Free DEVS

DEVS/HLA tutorialSIW, 99 University of Arizona F1 F2 NER(t1) NER(t2) F1 F2 TAG(t1) F1 F2 t1 t2 t1 NER(t2’) F1 F2 NER(t1’) NER(t2’) 1 2 RTI Time Req’t a) b) c)d) t1+g DEVS/HLA Simulation Protocol- Problem with Cancellation Behavior

DEVS/HLA tutorialSIW, 99 University of Arizona F1 F2 NER(t1) NER(t2) F1 F2 TAG(t1) t1 NER(t2) a) b) c) t1+g F1 F2 TAG(t1) NER(t1’) where t1’ depends on F2’s inputs so can’t immediately be sent as required t1+g NER(t2’) Deadlock for communicating imminents

DEVS/HLA tutorialSIW, 99 University of Arizona A Solution: DEVS w/Cancellation based on DEVS w/out Cancellation HLA/RTI DEVS without Cancellation* DEVS with Cancellation * is constrained by: ta(deltext(s,e,x)) = ta(s) - e for all s,e,x.

DEVS/HLA/CORBA TutorialSIW(fall 2000)109 RTI ExecFedex tN : Global DEVS Time tN i : Time of Next Event of Federate i System Models SimulatorEndo B CoordinatorEndo Simulator B User Models System Models Model C Model D CoordinatorEndo Simulator A User Models System Models Model A Model B Federate A Federate B Time Manager SimulatorEndo A tN tN 1 tN 2 Implementing DEVS Protocol in HLA Using Quantizers Coordinator

DEVS/HLA/CORBA TutorialSIW(fall 2000)110

DEVS/HLA/CORBA TutorialSIW(fall 2000)111

DEVS/HLA/CORBA TutorialSIW(fall 2000)112 Compute Input/Output Send Interactions Execute Transition Functions Update Attributes Send local time of next event (tN i ) of the i th Federate Coordinator tells Global DEVS time (tN) Federate 1Federate 2 Coordinator Coordinator receives local times of next events (tN i ) n n+0.1 n+0.2 n+0.3 n+1 t1t1 t2t2 RTI Time (Simulation Cycle) DEVS Time (Simulation time) Implementation (cont’d)

DEVS/HLA/CORBA TutorialSIW(fall 2000)113 Migrating DEVS Models to Real Time Operation Network Par DEVS Sim. Protocol HLA/RTI DEVS-RT-Simulator DEVS DEVS-RT Real Time RTI

Module 11: Creating Federations in DEVS/HLA u DEVS/HLA Development Process u C++ DEVS/HLA Component Templates u User Interface to DEVS/HLA u Examples: Pursuer/Evader C++ Implementations

DEVS/HLA/CORBA TutorialSIW(fall 2000)115 DEVS/HLA Development Process Requirements Definition Conceptual Model Development Federation Design Federation Integration and Test Execute and Analyze Results Source: Intro to HLA (JDITEC4_98.ppt) develop DEVS-C++ (or Java) atomic and coupled models store in model base decide mapping models to federates wrap models as Federate instances add HLA ports for inter-federate interaction add objects and attributes for state updates add predictive contract mechanisms compile model federate objects locate federates on network nodes start coordinator federate start model federates test Models in stage-wise bottom up fashion on workstation test federates test federations

DEVS/HLA/CORBA TutorialSIW(fall 2000)116 User Interface to DEVS/HLA Create FederateDEVS(FederationName) Run FederateDEVS Start main( ) End of main( ) Done by DEVS/HLA Done by User Constructor of FederateDEVS Constructor of FederateDevs Create RTIAmbasador Execute Federation Constructor of Federate Create Fedex Join Fedex Set Time Management Parameters executeFederation() of Federate End of executeFederation() Create DEVS Models Add them as components End of constructor( ) Create HLAports set up HLAports Coupling ports Create object classes Create their attributes set up classes and attributes Link these to DEVS models for attribute comm for interaction comm. Initialize models run( ) of Federate Start DEVS simulator End of run( ) Run Federate

DEVS/HLA/CORBA TutorialSIW(fall 2000)117 Federate *myFederate main( ) {........ } Public: set *components; set *classComponents; Public: static char *classname; /* Create FederateDevs */ myFdereate = new FederateDevs(federationName); /* Run FederateDevs */ myFederate->run ( ); /* Create instance of DEVS */ add (new devsModel (TopModelName)); /* Specify Interaction Communication */ /* for each interaction */ HLAport *hp = new HLAport (portName); add_outport(hp); or add_inport(hp); setup(hp); /* Specify Attribute Communication */ /* for each object class */ objectClass *oc = new objectClass(“atomicClassName”); /* for each attribute */ oc-> addAttribute (new attribute (…) ); classComponents->add(oc); setup(oc); /* setup env. for comm. atomic model */ /* Create component models */ setAtomicClassName( “atomicClassName”); main FederateDevs devsModel DEVS/HLA Model Templates

DEVS/HLA/CORBA TutorialSIW(fall 2000)118 DEVS/HLA Example: Pursuer-Evader-Viewer Model // constructor of FederatePursWQuant // create the highest component PursWQuant *PWQ = new PursWQuant(“PursWQuant”); // create objectclasses and register them to RTI objectClass *RedTKObj = new objectClass(“RedTank”); RedTKObj->addAttribute(new attribute(“position”,0,NULL); setUp(RedTKObj); // setup HLAport HLAport *hp = new HLAport(“fire”); addOutport(hp); setUp(hp); // coupling addCoupling(PWQ, “fireout”, this, hp); Sample code for a Federate RedTank (DEVS comp) FederatePursWQuant PursWQuant (DEVS comp) position firein update(quantizer) interaction(coupling) BlueTank Red Tank Viewer position RedTkObj Blue Tank position FederateEvadWEndo fire fireout RedTank EndoModel (DEVS comp)

DEVS/HLA/CORBA TutorialSIW(fall 2000)119 DEVS/HLA Example: Pursuer Model in out Red Tank Driver PursWQuant fout // Constructor of PursWQuant // create components RedTank *redtank = new RedTank (“RedTank”); Driver *drver = new Driver (“Driver”); // add components add (redtank); add (drver); // define interfaces (couplings) addCoupling (redtank, “out”,driver,”in”); addCoupling (drver, “out”,redtank,”in”); addCoupling (drver, “fout”,this,”fireout”); fireout // constructor of RedTank // create quantizers and attributes quantizer *qt = new quantizer(name,initValue, quantum); attribute *at = new attribute(“position”, &myPosition, qt); attributeList->add(at); myPosition

Module 12: Basic CORBA Concepts u CORBA - Common Object Request Broker Architecture u Basic Features and Services u Interfacing to Objects u Connecting to Distributed Objects via Naming Service u Event Channel and Real Time CORBA u Interoperability of Vendor Orbs u CORBA relative to other middleware

DEVS/HLA/CORBA TutorialSIW(fall 2000)121 CORBA Basic Features and Service CORBA: an open standard for distributed object computing defines a set of components that allow client applications to invoke operations with arguments on remote object implementations

DEVS/HLA/CORBA TutorialSIW(fall 2000)122 CORBA Overview (See Notes Below)

DEVS/HLA/CORBA TutorialSIW(fall 2000)123 Language Transparency Via Interface interface servant CORBA IDL (Interfacce Definition Language) Implementation --C++ --Java OBJECT invocation Internal call

DEVS/HLA/CORBA TutorialSIW(fall 2000)124 Example: Object Invocation Via Interface //java omg.omg.CORBA.Counter c; //get reference to c via //naming service using “cntr” int i = c.getCount(); getCount //IDL Module Example{ interface Counter{ int getCount() }; //C++ class Counter { int i; //methods public: int getCount(){return i++;} }; main (){ Counter c = new Counter(“cntr”); //give reference to naming //service }

DEVS/HLA/CORBA TutorialSIW(fall 2000)125 Connecting to Objects Through Naming Service ClientServer initialize ORB create new objects and connect to ORB get reference to naming service register objects with naming service get references to server objects via their names ORB Naming Service The Naming Service allows clients to find objects based on names using Naming Context specification --providing object location transparency.

DEVS/HLA/CORBA TutorialSIW(fall 2000)126 Event consumer Event supplier Event Channel 2 Event Channel 1 CORBA Event Service Common Object Service (COS) Event Service Event supplier Event consumer The Event Service provides basic asynchronous communication in ORB, de-coupling event suppliers from the event consumers. The supplier-consumer model allows an object to communicate an event to any other objects that might be interested in such an event. Both “pull” and “push” communication mechanism are specified.

DEVS/HLA/CORBA TutorialSIW(fall 2000)127 part of Real-Time CORBA Specification events go through one channel filtering at consumer is done by producer id priority and urgency-scheduling is supported ACE (Adaptive Communication Environment) TAO provides End-to-End QoS Event Channel Real-Time Event Service Scheduling Service CORBA Real Time Event Service Event consumer Event supplier Event supplier Event consumer

DEVS/HLA/CORBA TutorialSIW(fall 2000)128 TAO (The ACE ORB) ACE Naming Service Time Service Event Service Client Visibroker ORB CORBA NETWORK Server Visibroker ORB Example of CORBA Interoperabilty: TAO Real-Time ORB’s work with Visibroker ORB’s Internals of services are not standardized, but ORBs can use other ORBs services

DEVS/HLA/CORBA TutorialSIW(fall 2000)129 CORBA in relation to other Middleware u Java –Java Virtual Machine (JVM) »cross platform interoperability –JINI technology »alternative middleware to CORBA –both require Java as the primary programming language – can work with CORBA »to provide convenient development environment (e..g Visiboker) » to support lower layer to set up CORBA run-time environment u DCOM – For Microsoft components

Module 13: DEVS/CORBA Requirements, Design and Implementation u DEVS/CORBA Overview u Requirements for Distributed Simulation/Execution u DEVS and CORBA: complementary match-up u DEVS/CORBA Design and Implementation u Applications

DEVS/HLA/CORBA TutorialSIW(fall 2000)131 Basic DEVS/CORBA Overview DEVS : - Discrete Event System Specification - Sound formal modeling and simulation framework CORBA: - Common Object Request Broker Architecture - Open standard as a middleware (network software) DEVS/CORBA: - Parallel and distributed M&S environment - Improves performance (computing power, execution speed ) - Provides high scalability and availability (infinite resources) - Lowers the cost of development

DEVS/HLA/CORBA TutorialSIW(fall 2000)132 Open, Expressive Environment Distributed/Networked (Intra/Inter) Model Reuse Scalable Performance Requirements for DEVS/CORBA Distributed Simulation Environment

DEVS/HLA/CORBA TutorialSIW(fall 2000)133 Include Simulation as subset Interact with other business objects Extend to Real time control/management Model Continuity thru Development Phases Simplify Distributed Programing and Set-up Requirements for DEVS/CORBA Distributed Real Time Execution Environment

DEVS/HLA/CORBA TutorialSIW(fall 2000)134 Hierarchical federations Heterogeneous Federations: Logical, Real-time, speed-ahead Implement SES at CORBA level Automated mapping of pruned SES to hierarchical federations Automated distribution of components Requirements for DEVS/SES/CORBA

DEVS/HLA/CORBA TutorialSIW(fall 2000)135 DEVS and CORBA: The Match DEVS : a generic dynamic simulation formalism CORBA: a generic IDL for concretizing DEVS

DEVS/HLA/CORBA TutorialSIW(fall 2000)136 DEVS/CORBA Implementation DEVSCorba SimEngine System Util IDL FederationManager Federation CoordinatorImpl SimulatorImpl ActivatorImpl Deployer Daemon DEVSNamingService Launcher ObjectSerializer IOProcess Semaphore StreamThread AnyPort Component Examples = Java Packages

DEVS/HLA/CORBA TutorialSIW(fall 2000)137 DEVS/CORBA Implementation Genr Proc Control messages Simulator (ModelServer) Network Transd data messages Simulator (ModelServer) Simulator (ModelServer) Coordinator GPT DEVS/CORBA Interfaces DEVS models out in ariv solved out CORBA Name Server ------------------ ORB

DEVS/HLA/CORBA TutorialSIW(fall 2000)138 Example: Distribution over Internet Genr Proc Simulators LAN Transd Coordinator GPT CORBA Name Server ------------------ ORB Coord Thread Internet LAN ORB

DEVS/HLA/CORBA TutorialSIW(fall 2000)139 Distributed Real-Time DEVS Execution Environment Network ACE-TAO CORBA DEVS SEARCH RT-DEVS Execution Engine DEVS Processors/Activities Simulation/ execution layer

DEVS/HLA/CORBA TutorialSIW(fall 2000)140 Proc Event consumer Event supplier in out Transd Event supplier ariv stop Event consumer solv Event consumer Genr Event consumer Event supplier stop out Event Channel 3 Event Channel 2 Event Channel 1 CORBA Event Service Mapping DEVS coupling to COS EventService

DEVS/HLA/CORBA TutorialSIW(fall 2000)141 Proc Event consumer Event supplier in out Transd Event supplier ariv stop Event consumer solv Event consumer Genr Event consumer Event supplier stop out Coupling Mapping with TAO’s Real-Time EventService Event Channel Real-Time Event Service Scheduling Service SourceID 1 SourceID 2 Source ID 2 SourceID 3 Events are filtered by the associated SourceID

DEVS/HLA/CORBA TutorialSIW(fall 2000)142 Migrating Simulation Models to Real Time Operation Network Par DEVS Sim. Protocol Visibroker CORBA DEVS-RT-Simulator DEVS DEVS-RT TAO CORBA ACE Real Time

DEVS/HLA/CORBA TutorialSIW(fall 2000)143 Real-Time DEVS Formalism Implementation ~ activity simActivity ~tN ~myModel ~resultMessage activity: a wrapper class that specifies a job to be done, the time it requires, and the result (where the latter may be computed as a result of execution) the base class specifies the parameters explicitly procActivity: a devs model that can execute an activity as just described procActivity procAlwaysActivity ~ alwaysActivity inputActivity ~processing_time ~result simStepActivity ~tL ~iter ~myDevs ~resultMessage ~passivate alwaysAcivity: an activity that can be continually executed procAlwaysAcivity: processor for alwaysAcitivty that outputs its message inputActivity: an activity for responding to external events simActivity: an activity that is given a devs model. The model is executed until its first non-null output is obtained, which is the result of execution; the actual real time to execute is the time of the activity simStepAcivity: an activity that is executed in stepwise fashion atomic entity

DEVS/HLA/CORBA TutorialSIW(fall 2000)144 parSearch makeProcprocActivitys compActivity procActivity ~ activity simActivity ~myDevs makeProc : gets activity instances as inputs and creates procActivity instances to work on them compActivity : gets processed activities with their results and keeps track of the best so far, using metric specified in the activity. Outputs the best so far when its allowed time has elapsed. parSearch : coupled model for parallel search. SimActivity instances can be alternative devs models generated by automatically pruning an SES (or generated in some other manner) Real-time Execution of Parallel Search

DEVS/HLA/CORBA TutorialSIW(fall 2000)145 TAO (The ACE ORB) ACE Naming Service Time Service Event Service Coordinator Visibroker ORB CORBA NETWORK Simulator Visibroker ORB Simulator Visibroker ORB Interoperation between TAO Real-Time ORB’s and Visibroker ORB’s - ACE (Adaptive Communication Environment) Layer provides End-to-End QoS

DEVS/HLA/CORBA TutorialSIW(fall 2000)146 DEVSCORBA Federation Manager Activator Pool Federation Pool Activator@ 128.196.29.12 Activator@ 128.196.29.17 GPTFed TerraFed GenrProc Trans Coord @GPTFed TS TS”Coord @TerraFed DEVS-CORBA Naming Tree

DEVS/HLA/CORBA TutorialSIW(fall 2000)147 GPT Federation :FastSimulation TS1TS2 TS3 FactoryFederation: RTExecution EF DEVS-CORBA Naming Repository RTExec Coordinator DEVS-CORBA Federation Pool FedName Coord@GPTFedGPTFed Components Genr Proc Trans FactoryFed Coord@FactoryFed TS1 TS2 TS3 EF NSFFedCoord@TerraFed RT1 RT2 RT3 Type FastSimulation RTExecution RTSimulation GenrTransd Proc FastSim Coordinator EF@TerraFed FastSim Simulator RT Exec

DEVS/HLA/CORBA TutorialSIW(fall 2000)148 simulator Run Time System (RTS) Setup acims4.acims.arizona.edu acims11.acims.arizona.edu pisces.acims.arizona.edu.hosts RTS Manager daemon acims4.acims.arizona.edu Activator simulator 1 3 2 daemon acims11.acims.arizona.edu Activator simulator daemon pisces.acims.arizona.edu Activator simulator DEVS Naming and Directory Service 4 Create a daemon for a processor (using Java rsh) Create an activator Create Simulator pool Read a file containing host addresses run RTS Build DEVS NDS

DEVS/HLA/CORBA TutorialSIW(fall 2000)149 Deploy a Model to Federation Federation Reference User Deploy(gpt) 1 Activator @acims4 Activator @acims11 Activator @pisces Simulator (G) Simulator (P) Simulator (T) Coord @GPTFed G P T Model Partitioning And Dispatching 23 Assign a model to a simulator 5 register simulators to coordinator DEVS-CORBA Naming Service 4 Bind to DEVS-CORBA Naming Service Host Boundary GPT G P T

DEVS/HLA/CORBA TutorialSIW(fall 2000)150 Hierarchical Heterogeneous Federations RTExecutionFastSimulation Alternative 1 Alternative n Factory Component Model Candidate Schedules Best Schedule Supervisor

DEVS/HLA/CORBA TutorialSIW(fall 2000)151 Real world Model control Simulate faster then real-time Recommended values Observe in real-time Parameter settings Real-time, simulation-based control

DEVS/HLA/CORBA TutorialSIW(fall 2000)152 DEVS/CORBA Factory Data Base Control Model of Factory updates commands summaries recommendations Real-time, simulation-based control (cont’d) Son, Y., et al. (1999).A Multi-Pass Simulation-Based, Real-Time Scheduling and Shop Floor Control System. Trans. of SCS 16(4): 159-172.

DEVS/HLA/CORBA TutorialSIW(fall 2000)153 GPT Example executed in DEVS/CORBA Real-Time Environment GenrProcTransdLLC gpt HLC GenrProcTransdLLC gpEndo LLC (Low Level Control): queries Transd for TA and Thru incrementally adjusts Genr rate and Proc #machines toward given thruput goal Transd represents online DB Desired Thruput HLC (High Level Control): starts gpt and gptEndo with same conditions and thruput goal (gptEndo is executed faster than real time via simulation) waits for LLC in gptEndo to reach desired thruput and sends setting back to LLC in gpt

Module 14: System Entity Structure

DEVS/HLA/CORBA TutorialSIW(fall 2000)155 EFA ARCH EF GEN TRANSD EF ARCH COORD PROC Hierarchical Model Construction

DEVS/HLA/CORBA TutorialSIW(fall 2000)157 EFA EFA-DEC GENR COORD EF EFA-DEC TRANSDPROCSPROC ARCH ARCH-SPEC MULT MULT-DEC PROC SYSTEM ENTITY STRUCTURE specialization decomposition multiple decomposition

DEVS/HLA/CORBA TutorialSIW(fall 2000)158 PRUNINGGENR EFA EFA-DEC EF EFA-DEC TRANSD ARCH ARCH-SPEC PROC TRANSFORMING EFA PROC EF GENR TRANSD EFAEFA-DEC GENR COORD EF EFA-DEC TRANSD PROCS PROC ARCH ARCH-SPEC MULT MULT-DEC PROC Generating Family of Models

Module 15: Collaborative/Distributed DEVS M&S Environment u Distributed Modeling u Conceptual View for Collaborative/Distributed M&S

DEVS/HLA/CORBA TutorialSIW(fall 2000)160 HLA/OMT vs. DEVS/SES

DEVS/HLA/CORBA TutorialSIW(fall 2000)161 Simulation Engine HLA/OMT: FOM & SOM HLA/Object Model Template Federate A Dynamic Model Federate B Dynamic Model Network RTI

DEVS/HLA/CORBA TutorialSIW(fall 2000)162 Structure Frame (CDM) + DEVS Model (DEVS/HLA) Collaborative DEVS Modeling HLA Object Model yields translates into Legend Dynamics

DEVS/HLA/CORBA TutorialSIW(fall 2000)163 _ Setting: A Mountainous region of Yugoslavia. _ Objective: Maintain a track on the hyper-velocity Red Tank. _ Platform: Blue Helicopter is a standard variable speed air vehicle. uEquipped with a Ku band radar sensor with a constrained field of regard. _ Environment Models: Tank traverses the surface of a 1km resolution global terrain database. quantized Pitch/Altitude Updates Start/stop @ sensor scan rate Log-in messages Start/stop emissions High-Resolution Terrain GRASS GIS Red Tank Blue Helicopter Space Manager (Emission Propagation) Logger (Spatial Event Prediction) Endomorphic Red Tank HLA DEVS/HLA Simulation Scenario

DEVS/HLA/CORBA TutorialSIW(fall 2000)164 TANK EMMISION PROPAGATION HELICOPTER TERRAIN radar emission radar return radar return radar return Attributes: position pitch position elevation radar propagated estPosition radar return radar emission radar propagated elevation DEVS/HLA Federates

DEVS/HLA/CORBA TutorialSIW(fall 2000)165 position estPosition track quality EXPERIMENTAL FRAME Experimentation with Model

DEVS/HLA/CORBA TutorialSIW(fall 2000)166 TANKTERRAIN Endo TANK EMMISION PROP HELI COPTER TERRAIN TANK EMMISION PROPAGATION HELICOPTER Endo TANK Alternative Federations

DEVS/HLA/CORBA TutorialSIW(fall 2000)167 Modeling Collaborative DEVS Modeler (HLA/OMT) UA Federate LMSS Federate UA RTI-Executive Simulation DEVS/HLA Simulator UA Tucson, AZ UA Tucson, AZ GOSTOPSuspend LMSS Sunnyvale, CA GOSTOPSuspend

DEVS/HLA/CORBA TutorialSIW(fall 2000)168 CDM & DEVS/HLA Scenario Network UA/LMMS Simulation Federation Federate LMMS (Simulation Federate) Federate UA (Simulation Federate) Distributed Simulation UA/YVPG Simulation Federation Federate YVPG (Simulation Federate) Federate UA (Simulation Federate) DEVS/SES Model (Radar) Collaborative Modeling Model (Aircraft) Model (Terrain)

DEVS/HLA/CORBA TutorialSIW(fall 2000)169 Component-based M&S Architecture Network Hardware (Computing) Platforms Database (Persistence Object Store) Distributed Object Management Graphical User Interface Auxiliary Components (e.g., Genetic Algorithm) Collaboration Environment DEVS/DESS Simulation DEVS/DESS Modeling CDMS Environment Model ConstructionModel Composition Analysis

DEVS/HLA/CORBA TutorialSIW(fall 2000)170 Place differentsame Time same different conventional meeting synchronous collaboration asynchronous collaboration Basic Modes of Collaboration

DEVS/HLA/CORBA TutorialSIW(fall 2000)171 clarify objectives CM collect data AC Distributed Source build model build model CM, SC, AC validate model CM, SC CM: Conventional Meeting SC: Synchronous Collaboration AC: Asynchronous Collaboration Collaborative Model Construction

DEVS/HLA/CORBA TutorialSIW(fall 2000)172 clarify objectives CM search for components AC distributed repository sites build hierarchical model AC, SC execute hierarchical model AC CM: Conventional (Electronic) Meeting SC: Synchronous Collaboration AC: Asynchronous Collaboration Collaborative Model Composition

DEVS/HLA/CORBA TutorialSIW(fall 2000)173 Collaborative Configuration System Human Factors Div. San Francisco, CA  Development Div. Boston, MA  Collaborative DEVS Modeler Electronics Div. Tucson, AZ  XYZ Corporation  Four dispersed divisions collaborate to produce Model for “Aircraft Flight in a Synthetic Natural Environment” Manufacturing Div. Houston, TX 

DEVS/HLA/CORBA TutorialSIW(fall 2000)174 Collaborative Configuration System Sunnyvale CA GES NJ HLA/RTI UofA Tucson Sunnyvale CA GES NJ Collaborative Distributed Network System UofA Tucson UofA Tucson DEVS/HLA — Distributed Simulation Collaborative Configuration System — Configuration — Management/Monitoring

DEVS/HLA/CORBA TutorialSIW(fall 2000)175 CDM Architecture CDM environment Knowledge Worker DM CDNS Knowledge Worker DM CDNS Networking Tasks: connect client to server receive updates from server send model to server etc. Modeling Tasks: add component add link etc. Knowledge Manager DM CDNS Modeling Tasks: update model etc. Networking Tasks: grant/deny client access broadcst model updates etc. DM: DEVS Modeler CDNS: Collaborative Distributed Network System internet

DEVS/HLA/CORBA TutorialSIW(fall 2000)176 Client Window

DEVS/HLA/CORBA TutorialSIW(fall 2000)177 Graphical Model

DEVS/HLA/CORBA TutorialSIW(fall 2000)178 Modeling Window

DEVS/HLA/CORBA TutorialSIW(fall 2000)179 Distributed Object Computing (DOC) u Technologies enabling distributed software systems –DOC sits at the confluence of two major software technology areas: »Distributed computing systems »Object-oriented design and programming –DOC Challenges »Inherent complexities from the fundamental problem of distribution »Accidental complexities from limitations with tools and techniques used to build distributed software u DOC Design Problem –Even simple Client/Server DOC systems consist of multi-vendor and heterogeneous components that present non-deterministic performance and capacity planning behaviors –How to tractably evaluate design performance, alternatives, and tradeoffs

Module 16: Distributed Codesign Methodology u CORBA - Common Object Request Broker Architecture u Basic Features and Services u Interfacing to Objects u Connecting to Distributed Objects via Naming Service u Event Channel and Real Time CORBA u Interoperability of Vendor Orbs u CORBA relative to other middleware

DEVS/HLA/CORBA TutorialSIW(fall 2000)181 Distributed Cooperative Objects Object System Mapping arc Loosely Coupled Network processor link gate software object domain DEVS-DOC Models u DEVS: –Formal systems-theoretic M&S framework –Dynamic system representation –Hierarchical, modular modeling u DOC: –Distributed Codesign approach –Independent SW & HW modeling –Coupling SW & HW models (OSM) produces dynamic model

Distributed Cooperative Objects arc software object domain Distributed Cooperative Objects (DCO) u The software architecture component u Object-oriented paradigm –A set of attributes –A set of methods u Software objects interact via arcs –Peer-to-peer: messaging arcs –Client-server: invocation arcs u Software interactions invoke methods, which create jobs –Synchronous interactions block jobs –Software object thread mode setting dictates job execution concurrency »None:only one active job at a time »Object:only one active job per object method »Method:an active job for every interaction u Software objects “load” the LCN via –Active software objects: memory loading –Interactions: communications loading –Jobs: computational loading

DEVS/HLA/CORBA TutorialSIW(fall 2000)183 Modeling Software Objects u Defining software methods: –Quantum modeling »Name »Computational Workload »Invocation Probability –Directed modeling »Name »Task sequences of u Computational Workloads u Arcs u Defining software arcs: –Name –Destinations –Size –Return Size –Message Type synchronous, asynchronous, return, message –Time Out –Firing Frequency (quantum modeling) –Method Called (directed modeling) u Defining DCO software objects: –Name of object for reference –Size of object for memory loading –Thread Mode of object: none, object, method –Methods a set of methods –Arcs a set of interaction arcs –Duty Cycle for defining initializer objects –Initialization Method for directed modeling of initializer objects u Modeling concepts –Quantum modeling: for any one invocation, the method selected is irrelevant as long as the invocation is in correct proportion to the aggregate invocations of all methods –Directed modeling: each invocation specifies a method for execution

DEVS/HLA/CORBA TutorialSIW(fall 2000)184 Software Object Structure

DEVS/HLA/CORBA TutorialSIW(fall 2000)185 Software Object Dynamics

Loosely Coupled Networks (LCN) Loosely Coupled Network processor link gate u The hardware architecture component u Processors –Invoked software objects load memory –Software object jobs load cpu –Software object interaction messages converted to packets for routing across LCN u Gates –Interconnect two or more network links –Two types of gates »Routers switch LCN traffic between links »Hubs broadcast LCN traffic across links u Links –Provide a communications path between processors and gates

DEVS/HLA/CORBA TutorialSIW(fall 2000)187 Modeling Processors, Gates, & Links u Defining Processors –Name of processor –CPU Speed of processor –Memory Size of processor –Swap Time Penalty associated with memory swaps u Defining Gates –Routers »Name of router »Header Size for wrapping local packets »Link Speeds for each incident link »Bandwidth internal to router »Buffer Size internal to router –Ethernet Hubs »Name of hub »Link Speeds for each incident link »Bandwidth internal to router »Buffer Size internal to router u Defining Ethernet Links –Name of ethernet –Number of Segments for determining worst case propagation

DEVS/HLA/CORBA TutorialSIW(fall 2000)188 LCN Processor Structure u The processor is a DEVS coupled model –Transport component »Converts outgoing DCO messages into packets and incoming packets to DCO messages –Router component »Inspects destination of packets and routes accordingly –CPU component »Invoked DCO software loads memory »DCO jobs are received, executed, and released

DEVS/HLA/CORBA TutorialSIW(fall 2000)189 LCN Gate Structure

DEVS/HLA/CORBA TutorialSIW(fall 2000)190 Modeling Framework: OSM u Maps DCO objects onto LCN processors u Defines communication modes: message segmentation into packets –Packet size –Packet overhead –Packet acknowledgement size –Acknowledgement timeout u Maps invocation and message arcs onto communications modes Loosely Coupled Network link node Distributed Cooperative Objects software object arc Object System Mapping

DEVS/HLA/CORBA TutorialSIW(fall 2000)191 DEVS-DOC Experimental Frame

DEVS/HLA/CORBA TutorialSIW(fall 2000)192 DEVS-DOC Modeling Process Map software onto processors (OSM) Define processors, routers, hubs, links, and network topology (LCN) Define software objects and interactions (DCO) DOC Configure simulation control and data collection components (Experimental Frame) Run simulation and analyze results Desired performance & behavior? no Refine distribution? stop yes Refine software design? Refine hardware design? State M&S objectives

DEVS/HLA/CORBA TutorialSIW(fall 2000)193 DEVS/HLA and Predictive Contracts Case-Study u DEVS/HLA –DoD HLA-compliant M&S environment –Mapping of DEVS-C++ to DMSO RTI (C++) u Predictive Contract Research –How to reduce message traffic exchanged between distributed simulation federates with a marginal addition to computational overhead? u Three predictive contract mechanisms studied –Non-predictive quantization: send a real-valued variable update for each threshold crossing –Predictive quantization: send a single bit variable update to signal next higher, or lower, threshold crossing –Multiplexed predictive quantization: send a set of single bit variable updates in one message between federates »Applicability: large number of models per federate

DEVS/HLA/CORBA TutorialSIW(fall 2000)194 Pursuer-Evader Federation Pursuer FederateEvader Federate Pursuer Evader DEVS/HLA EvaderWEndo Pursuer Red Tank position Red Tank Endo Model position drive in out fireOut fireIn update (quantizer) interaction (coupling) Evader perceive Blue Tank out in

DEVS/HLA/CORBA TutorialSIW(fall 2000)195 DEVS/HLA Federation Infrastructure CoordinatorEndo Simulator A System Models User Models Federate P CoordinatorEndo Simulator B System Models User Models Federate E Coordinator SimulatorEndo A System Models Time Manager SimulatorEndo B tN tN 1 tN tN 2 RTI ExecFedex tN: Global DEV Time tN i : Time of Next Event of Federate i Model P1 Model P1 Model P1 Model P1 Model E1 Model E1 Model E1 Model E1

DEVS/HLA/CORBA TutorialSIW(fall 2000)196 Real System Predictive Contract Results

DEVS/HLA/CORBA TutorialSIW(fall 2000)197 DEVS-DOC Simulated Results For DEVS/HLA Predictive Contracts

DEVS/HLA/CORBA TutorialSIW(fall 2000)198 DEVS-DOC Runtime Performance

DEVS/HLA/CORBA TutorialSIW(fall 2000)199 DEVS Modeling Constructs Operating System Distributed Object Computing Modeling Constructs Persistent Object Store Middleware (CORBA) Auxiliary Modules (GUI) Distributed Simulation (DEVS/CORBA) Uniprocessor Simulation Parallel DEVS (DEVSJAVA) Modeling Layer Simulation Layer DEVS-DOC DEVS-DOC M&S Environment

Module 17: DEVS/HLA Support of Joint Measure TM * u Joint MEASURE TM : Motivations, Objectives, Applications u Joint MEASURE TM Background –Joint MEASURE Overview –The Distributed Joint MEASURE Architecture. u DARPA/ASTT Technology Demonstration u Joint MEASURE TM Benefits to Systems-of-Systems Analysis * Mission Effectiveness Analysis Simulator for Utility, Research and Evaluation developed by Lockheed Martin Missiles and Space Systems

DEVS/HLA/CORBA TutorialSIW(fall 2000)201 Mission Effectiveness u SBA: early assessment of new system’s expected mission effectiveness u Assess contribution to overall ability to counter an enemy threat:  ability to gather and share information,  survive  service hostile targets. u Difficulty: large impacts due  Subtle design decisions  modest alterations use of the system  minor modifications of the scenario

DEVS/HLA/CORBA TutorialSIW(fall 2000)202 Goals and Objectives: u Assist in evaluating a proposed system’s mission effectiveness, wrt  specified set of possible design variations  operational utilization patterns  engagement scenarios  Need for High Performance: It is easy to generate a requirement to simulate a multi-hour analysis scenario thousands of times.  Repeatability: based on DEVS, a logical model formalism with a well-defined state concept, Joint MEASURE TM has the ability to exactly replicate simulation runs  Maintainability and Reusability: The modular aspect of DEVS models enforces a software engineering practice that simplifies code reuse and simplifies the construction of new federations from existing components  Portability at a high level. The high-level of abstraction provided by the DEVS formalism subsequently facilitated porting the system to DEVS/C++ and later to DEVS/HLA

DEVS/HLA/CORBA TutorialSIW(fall 2000)203 Applications: u JCTN - Utility of measurement-based sensor fusion. –Access to remote (I.e., non-LMMS) Lockheed Martin models. –End run around ‘proprietary’ concerns. u DD21/Deepwater - Analysis of system-of-system options. –Complex scenario modeling requirements (with concomitant performance requirements). –Need to integrate/interface models developed by number of team mates. –Eventual need to integrate person-in-the-loop simulation with analytically simulation.

DEVS/HLA/CORBA TutorialSIW(fall 2000)204 RTI Executive DEVS Federate RTI Ambasador Joint MEASURE DEVS Federate RTI Ambasador OPNet Comm Model DEVS Federate RTI Ambasador DD21 (Warship Model) DEVS/HLA Joint MEASURE Federations Internet

DEVS/HLA/CORBA TutorialSIW(fall 2000)205 Joint MEASURE TM Overview Mission Effectiveness Simulator Generator –Intended for Monte-Carlo analytical work. –High performance is a priority. –Expected to be used by broad community. Provides an infrastructure composed of: –DEVS-Compliant Models/DEVS Simulation Engine -Emission Propagation -Spatial Encounter Prediction –Geographical Information System (GIS). –Data Modeling and Analysis Toolkit. –Graphical User Interface (GUI) Archives a library of reusable models: –Sensors –Weapons –C2 –Environment

DEVS/HLA/CORBA TutorialSIW(fall 2000)206 Scenario Specification Can be specified interactively. Specification includes: variable routes, behaviors and subsystems and the attributes of those subsystems. Scenarios can be stored, retreived and concatenated. Provides full access to underlying GIS. Provides most useful map projections. Runtime Visualization/Animation Optional 2d-3d run-by-run animation. Display clutter controls. Runtime data analysis updates. Start/Stop/Pause. Data Analysis Collects and displays a variety of mission effectiveness data. Integrated with Prophet (a statistical and modeling package with report generation capabilities.) Joint MEASURE TM Overview User Interface, Graphics and Animation

DEVS/HLA/CORBA TutorialSIW(fall 2000)207 Joint MEASURE TM Architecture Simulation Engine Infrastructure Components GIS GUI Data Analysis Reusable Models Alternative Models Hierarchical Decomposition Emission Propagation Encounter Prediction

DEVS/HLA/CORBA TutorialSIW(fall 2000)208 The Non-Distributed Joint MEASURE TM Architecture Logger Propagator Platform Sensors Weapons C3C3 Hull Platform Sensors Weapons C3C3 Hull GIS GIS dB

DEVS/HLA/CORBA TutorialSIW(fall 2000)209 The Non-Distributed Joint MEASURE TM Architecture u Platform(s) - Top Level Modeling Components – Encapsulate Sub System Models: (Hull, Sensors, Weapons, Comms, C 2 ) –Interact with other Platforms via ‘Emissions’ u Spatial Encounter Predictor (Logger) - Infrastructure Component –Calculates when events could occur. –Publish and Subscribe oriented. –Handles detection, firing and collision events. u Propagator - Infrastructure Component –Determines signal and noise strength and latencies. –Interfaces to GIS system for environment models.

DEVS/HLA/CORBA TutorialSIW(fall 2000)210 Parallel/ Distributed Simulation Protocol DEVS/HLA and Support of Joint Measure Network DEVS HLA/RTI Joint Measure

DEVS/HLA/CORBA TutorialSIW(fall 2000)211 Logger Propagator Platform Sensors Weapons C3C3 Hull Platform Sensors Weapons C3C3 Hull GIS GIS dB Logger Propagator Platform Sensors Weapons C3C3 Hull Platform Sensors Weapons C3C3 Hull GIS GIS dB Hull HLA/RTI over Internet Endomorphs LMMS The Distributed Joint MEASURE TM Architecture

u Infrastructure components are replicated. u Endomorphs are created in remote Federates. u Remote Loggers announce when updates are relevant via ‘events’. u Models update their endomorphs via ‘object updates’.

DEVS/HLA/CORBA TutorialSIW(fall 2000)213 The Goal of DEVS/HLA Joint MEASURE Validation Test Bed u Establish the practicality of using the DEVS/HLA approach in an industrial strength application. u Demonstrate that remote models can be accessed for analytically demanding purposes. u Explore the impact of alternative distribution strategies on performance and fidelity. u Quantify the resulting performance and fidelity improvements and/or tradeoffs.

DEVS/HLA/CORBA TutorialSIW(fall 2000)214 quantized: altitude pitch radar emissions radar Xsection LAN Space Model emissions prop agation spatial encounter prediction Endomorphic model preserves radar reflective properties Lockheed/UA Joint Measure: Space Based Radar Detection HLA Internet Federate UA Federate LM

DEVS/HLA/CORBA TutorialSIW(fall 2000)215 ASTT Test Bed Scenario Features (A Distributed HEL Weapon Architecture Evaluation Test Bed) u Approach –Distribute models to processors on the basis of affiliation. »Enemy Threat platforms execute on Processor ‘A’ »Friendly HEL Architecture(s) execute on Processor ‘B’. –All models are responsible for maintaining remote endomorph(s). –All detection/tracking is performed locally against endomorphs. –Other interactions (e.g. detonations) are transmitted over the network. u Model’s Update Algorithm for maintenance of Endomorphs –Models maintain their own (possible dynamic) signature databases. –Models monitor (with local logger support) position of possible detectors. –Models update selected signature cell values in response to: »Dynamic changes in their own signature cell values. »Motion derived changes in detector bearing and elevation. –Updates are quantized in order to control the update frequency. u Test Bed Support for Algorithm Evaluation –Quantization parameters can be easily manipulated. –Number of processors distributed over can be increased. –Endomorphs can be eliminated for baseline case

DEVS/HLA/CORBA TutorialSIW(fall 2000)216 Summary: DEVS Framework and DEVS/HLA u DEVS provides sound system-based modeling framework u DEVS/HLA (implemented in C++/Java) provides sound/user-friendly environment for developing HLA- Compliant simulations u DEVS/HLA supports integration of common modeling approaches u DEVS/HLA supports Hierarchical Modeling as well as efficient parallel/distributed simulation u DEVS/HLA supports Predictive Contract Methodology u Collaborative DEVS Modeler and other DEVS tools support FEDEP development

Module 18: Efficient Large Scale Distributed Simulation u Predictive Contract Methodology u DEVS Bus Concepts u Representing Discrete-time and Differential Equation Systems u Coupling Agents and Environments u Developing Efficient Distributed Simulations

DEVS/HLA/CORBA TutorialSIW(fall 2000)218 Component Model Simulator Messaging Coupled Model Coordinator Messaging Communication is bottleneck due to large number of interacting entities Limited bandwidth channel Bandwidth Constraints on Distributed Simulation Coordinator manages time and message routing Simulator interfaces model to coordinator HLA middleware Component Model Simulator Messaging Component Model Simulator Messaging

DEVS/HLA/CORBA TutorialSIW(fall 2000)219 Overcoming Bandwidth Constraints Simulators use local models of remote federates to reduce need for updates e.g. Dead Reckoning Publish/Subscribe routes updates within classes Spatial Encounter Prediction (routing space) reduces message exchange to pairs that are (dynamically) close Component Model Simulator Messaging Component Model Simulator Messaging Component Model Simulator Messaging Quantization reduces update message volume and size

DEVS/HLA/CORBA TutorialSIW(fall 2000)220 Local Computation Tradeoffs and Scalability Local computation overhead Communication reduction high low high Quantization Predictive quantization Spatial Encounter Prediction Local Models

DEVS/HLA/CORBA TutorialSIW(fall 2000)221 DEVS Bus Concept RTI message DEVS HLA DEVS HLA message DEVS HLA Diff Eq. Systems Diff Eq. Systems Discrete Time Systems Discrete Event Formalisms

DEVS/HLA/CORBA TutorialSIW(fall 2000)222 Quantization Predictive Filtering u quantization –non-predictive –predictive –scalability u error characterization – error/message reduction tradeoff

DEVS/HLA/CORBA TutorialSIW(fall 2000)223 Quantization

DEVS/HLA/CORBA TutorialSIW(fall 2000)224 Non-predictive Quantization sender generates fixed time step outputs quantizer demon is applied to sender output reduce number of messages sent but not their size quantizer incurs some computation sender’s computation unaffected receiver must persist attribute values Sender Receiver Quantizer

DEVS/HLA/CORBA TutorialSIW(fall 2000)225 Predictive Quantization sender employs own model to predict next boundary crossing sends one-bit message at crossings Advantage: reduce both number of messages and size multiplex messages together to exploit small message size prediction can also reduce sender’s computation time stamping: background (logical) or absent (real time) Receiver Sender (t1,1)(t2,1)(t3,1) t1t2t3

DEVS/HLA/CORBA TutorialSIW(fall 2000)226 X,Y: predictive attributes Z: non-predictive attribute X Y D Z DZDZ Combined Predictive/non Pred. Quantization Z X Y x:PxPx X: y:PyPy Y: z:QzQz Z: +1,-1 real x:PxPx X: z: Z: y:PyPy Y: D (when changed)

DEVS/HLA/CORBA TutorialSIW(fall 2000)227 Predictive Quantization: Detail employed model can be very simple –standard integrator :: linear extrapolation time = quantum size/input (derivative) boundary = up/down according to sign(derivative) map Diff. Eq. system component-wise using memory-less equivalents (see next figure) –double integrator :: 2nd order extrapolation (used in Dead Reckoning) (time, boundary) determined by smallest positive root of algebraic solution (quantum size, p, v, a)

DEVS/HLA/CORBA TutorialSIW(fall 2000)228 Scalability of Predictive Quantization Sender #computations(D) Receiver #messages(D) #bits(D) 0 Quantum size, D #messages(D) non-predictive predictive Quantum size, D 0 #computations(D) non-predictive 2-3 Orders of Magnitude

DEVS/HLA/CORBA TutorialSIW(fall 2000)229 Error Characterization local –federate-measured difference between hi fi and 2nd order model –cannot guarantee control on global error global –deviation from true global state –propagation, feedback –theory developed and validated –error can be reduced to below any given tolerance level with small enough quantum size – typically, require quantum size no smaller than 10% to 0.1% of range of variable

DEVS/HLA/CORBA TutorialSIW(fall 2000)230 Favorable Tradeoff in Quantization #messages Avg Transit Time Saturation level Execution Time CAN EXPECT extremely favorable tradeoff in execution time (or number of concurrent entities) near system saturation level If tolerance = 1% of Full Scale, D tol = Full Scale /100 c, ranging from Full Scale/1000 to Full Scale/50 #messages(D) = #messages(1)/D Error tolerance 0 1 Quantum size, D Error = c D D tol = tolerance / c Full Scale Experiments with a variety of examples show that c ranges from 0.5 to 10.

DEVS/HLA/CORBA TutorialSIW(fall 2000)231 Quantization Test Cases A variety of examples have been investigated u classical ODEs (orbiting body,predator/prey, slow/fast system, chaotic system) u spatially distributed system (heat seeker in diffusion field) u multi-entity systems (pursuer/evader pairs,urban traffic, follow the leader) Results confirm the theoretical predictions and provide estimates of parameters and tradeoff relations

DEVS/HLA/CORBA TutorialSIW(fall 2000)232 Visualized Examples of Quantization Heat Seeker in Diffusion Field source seeker (sensitivity =.05) temperature (colors) 0.00001 0.0001 0.001 0.04 0.1 K Messages 0 20 40 60 80 100 K Messages execution time Quantum size tolerable error level Can increase quantum size to seeker sensitivity level while still getting same qualitative behavior

DEVS/HLA/CORBA TutorialSIW(fall 2000)233 Mapping DESS Directly into DEVS DEVS F F F Component-wise mapping based on predictive quantization Persistent Function Element Predictive Quantizer Integrator

DEVS/HLA/CORBA TutorialSIW(fall 2000)234 Stress Test: Rossler Choatoic ODE

DEVS/HLA/CORBA TutorialSIW(fall 2000)235 Quantum size and DEVS/HLA Federate Assignment a) b) c) fire Out fire In a) fire Out fire In

DEVS/HLA/CORBA TutorialSIW(fall 2000)236 Baseline Quantization for Multi-entity Federates Q value Q Q Q Federate A Federate B model A n model A n-1 model A 2 model A 1 model B n model B n-1 model B 2 model B 1 double (64 bits) Network

DEVS/HLA/CORBA TutorialSIW(fall 2000)237 Predictive Quantization Multiplexer PQ value PQ network Federate A Federate B model A n model A n- 1 model A 2 model A 1 model B n model B n- 1 model B 2 model B 1 model Mmodel M’ 2bits for active/+1 /-1  D

DEVS/HLA/CORBA TutorialSIW(fall 2000)238 Predictive Multiplexer vs Baseline Performance

DEVS/HLA/CORBA TutorialSIW(fall 2000)239 Three types of component coupling physical to physical -> environment agents to environment agents to agent agents -- system components with perceptual, decision and usually mobility capabilities micro satellites urban traffic robot colonies mobots environment -- spatial layered variables with energy propagation capabilities Coupling Agents and Environments

DEVS/HLA/CORBA TutorialSIW(fall 2000)240 Component-to-component AtmosphereOcean Sea Surface Temps WindStress heat fluxes water fluxes Daily at noon Daily at midnight Coupling of physical components different resolutions synchronization load balancing

DEVS/HLA/CORBA TutorialSIW(fall 2000)241 Agents-to-Agents Spatial Model Agents locations couplings Agents interact through sensing each other communicating with each other Spatial Encouner Prediction reasons whether pairs of agents can interact Emissions Propagation Both kinds of interaction can employ endomorphic models, i.e., models of self or other components in the system

DEVS/HLA/CORBA TutorialSIW(fall 2000)242 Communicating Agent Interaction Sending Agent Endo model Sending Agent Receiving Agent Info About My State Receiving Agent Endo model Endomodels used within agents to enable them to communicate about their internal states

DEVS/HLA/CORBA TutorialSIW(fall 2000)243 Perceiving-Reflective Agent Interaction Reflective Agent Endo model Reflective Agent Perceiving Agent How I look Perceiving Agent Endo model LANInternet Endomodels used by simulators to reduce message traffic to overcome latency in real time operation

DEVS/HLA/CORBA TutorialSIW(fall 2000)244 Endo model Sending/Reflective Agent Experimental Frame defined by Needs of Receiving/Perceiving Agent Endo-morphism Sending/Reflective Agent Endo model State transition homomorphism Endomorphic Model Construction LEGEND

Summary u Scalability –local computation overhead –ability to reduce bandwidth requirements u Quantization, especially, predictive quantization –scalable mechanism –good message filtering properties –multiplexing can exploit the message size reduction for large numbers of entities, –providing high communication reduction –with low computation overhead. u Quantization methods can be combined with other schemes –local models –spatial encounter prediction –potentially provide greater load reduction –cost of increased local computation.

Module 19: Zero Lookahead Simulation: DEVS and HLA

DEVS/HLA/CORBA TutorialSIW(fall 2000)247 Mapping DEVS Models to HLA Maybe transform before mapping? Parallel DEVS model C++/HLA Java HLA Mapping must preserve Simulation logic in the mapped space for observables Tom. Lake(a)glossa.co.uk

DEVS/HLA/CORBA TutorialSIW(fall 2000)248 HLA Logical Simulation Constructs * The shared part of the simulation NOT the implementation* HLA provides a distributed whiteboard on which these things evolve * Objectsinstances of classes * Attributesof objects * Interactionsinstances of classes * Parametersof interactions All seen by all subject to Interest Mgmt

DEVS/HLA/CORBA TutorialSIW(fall 2000)249 Logical Evolution in HLA Ownership exchange Register ObjectDiscoverObject UpdateAttributeValues * ReflectAttributeValues * DeleteObject * RemoveObject * SendInteraction * ReceiveInteraction * * Only these have logical times attached Others must happen “early enough”

DEVS/HLA/CORBA TutorialSIW(fall 2000)250 What are Federates For? Federates host objects Federates keep time for objects Federates manage interest for objects Federates send and receive interaction for objects Federates send and receive object attribute changes One software system can have many federate interfaces to a federation Of course HLA started by assembling federates….

DEVS/HLA/CORBA TutorialSIW(fall 2000)251 Some surprising Things…. Interactions are not like messages. Interactions are seen by all subject to interest Mgmt Register object is not a timestamped operation in HLA Change of attribute value cause objects to be discovered

DEVS/HLA/CORBA TutorialSIW(fall 2000)252 Distributed Computing is HARD Heterogeneous platforms with different data formats Delays in networks make it costly and slow to coordinate the components Cause of delays: Speed of light Router delays, losses ATM queues, losses Telcos can switch routes….

DEVS/HLA/CORBA TutorialSIW(fall 2000)253 The time ordering problem We are committed to taking events in logical time order But events can happen remotely. How can we be sure that we have not missed any? RTI cannot advance beyond LBTS Least Bound on (incoming) Time Stamp

DEVS/HLA/CORBA TutorialSIW(fall 2000)254 Time Ordering -- Some Solutions Optimistic techniques -- correct ordering faults when they occur Conservative techniques -- don’t let problems arise Requires (for efficient large-scale operation):- Lookahead -- give output events to RTI early. Or Synchronous timestepping Smart mappings of the problem may help give lookahead

DEVS/HLA/CORBA TutorialSIW(fall 2000)255 Lookahead -- what is it? You have lookahead L if your output is complete up to time t-L at time t Output means output attribute changes (predicted) and interactions that you give rise to and object deletions that you perform. Can get lookahead in models as: reaction time, minimum travel time, processing time, inertia, etc. Sometimes transform models to move lookahead around ( Paper 160 this meeting).

DEVS/HLA/CORBA TutorialSIW(fall 2000)256 Conditional Advance With Lookahead I can go without smoking until 10pm but if someone else lights up I can only hold out 5 minutes I can hold out without smoking until 9pm SetLookahead(0min) TimeAdvanceRequest(9pm) Lights up at 9:00pm SetLookahead(5min) NextEventRequest(10pm) Lights up at 9:05pm Global LBTS is 9:00pm then 9:05pm

DEVS/HLA/CORBA TutorialSIW(fall 2000)257 Zero Lookahead Simulations, DEVS and HLA DEVS -- lookahead is not automatically present We can sometimes transform it in. E.g. map DEVS phases to RTI time, time to an interaction RTI -- Normally gives all events up to AND INCLUDING time t before giving TimeAdvanceGrant(t) and parallel DEVS needs this guarantee( in the obvious mapping) to output But RTI can only guarantee “up to time t” for federates with zero lookahead (and will only do this in response to NextEventRequestAvailable) Solution: Smart mapping or communicate “ output at time t complete” explicitly

DEVS/HLA/CORBA TutorialSIW(fall 2000)258 Without Lookahead? Not a problem for small scale simulations Not a problem if time is coarsely “chunked” so that many events are simultaneous.

DEVS/HLA/CORBA TutorialSIW(fall 2000)259 Mapping Models to HLA Some of the cases are hard because distributed computing is hard Where we need smart mappings it is essential to start with a sound definition of the model. The tools to solve the problems, whether through optimistic simulation or smart mappings can only arise in a well-defined framework for modeling AND simulation.

DEVS/HLA/CORBA TutorialSIW(fall 2000)260 Some Open Issues & Research Directions Characterize the class of logical-time models that HLA/RTI can support Simulation algorithms interoperability DEVS/HLA migration to real-time and its integration with its logical-time counterpart Predictive contract methodology model/simulation dependent characterization the best mix of schemes for a given application context

DEVS/HLA/CORBA TutorialSIW(fall 2000)261 Research Mission – basic for improved infrastructure – applied to challenging problems Education Mission – degree programs in M&S discipline – training of M&S professionals – short courses, tutorials Service Mission – support M&S needs of government and industry AZ Center for Integrative M&S

Module 20: DEVS-based Tools in Support of HLA-Compliant Simulations u DEVS/HLA C++/Java u DEVS/CORBA u Joint MEASURE TM u Collaborative DEVS Modeler u DEVSJAVA u DEVS-DOC

DEVS/HLA/CORBA TutorialSIW(fall 2000)263 DEVS-Based HLA Tools

DEVS/HLA/CORBA TutorialSIW(fall 2000)264 DEVS/HLA u Purpose: Generic Environment for DEVS-based M&S u Major Functions: – System-theory and formal M&S concepts – Enables developing components in DEVS C++/Java –Supports predictive contract methodology & parallel/distributed execution of federations –Industrial strength capability (e.g. Joint MEASURE TM ) u HLA FEDEP Support: Phases 3, 4, 5 and 6

DEVS/HLA/CORBA TutorialSIW(fall 2000)265 DEVS/HLA (cont.) u HW/SW Specification: –Computing HW platforms: Unix workstation & PC –OS: Unix Solaris & Windows NT –Languages: C++ & Java –Versions 1.3 (supports RTI 1.3) u Organization: University of Arizona (with help from Lockheed Martin) u POC: –Bernard Zeigler –Ph: 520-626-4846 –Email: zeigler@ece.arizona.edu –URL: www.acims.arizona.edu

DEVS/HLA/CORBA TutorialSIW(fall 2000)266 Joint MEASURE TM u Purpose: Assess Sensor-weapon, System of Systems Mission Effectiveness u Major Functions: –DEVS/HLA compliant hierarchical, modular models –Extensive model libraries (e.g., C4ISR, lasers and targets) –Integrates GIS, rich visualization, & statistical analysis –GUI supports analyst-friendly interactivity u HLA FEDEP Support: Phases 3,4,5 and 6

DEVS/HLA/CORBA TutorialSIW(fall 2000)267 Joint MEASURE TM (cont.) u HW/SW Specification: –Computing HW platforms: Unix workstations –OS: Solaris –Language: C/C++ –Version: 1.1 u Organization: Lockheed Martin Missile Space u POC: –Steven Hall –Ph: 407-742-2903 –Email: steve.hall@lmco.com

DEVS/HLA/CORBA TutorialSIW(fall 2000)268 Collaborative DEVS Modeler u Purpose: Anytime/anyplace model development u Major Functions: –Facilitates collaborative hierarchical, modular model development –Model-based modeling (component model reuse) –Supports single/multiple users –User-friendly Interface u HLA FEDEP Support: Phases 2 and 3

DEVS/HLA/CORBA TutorialSIW(fall 2000)269 Collaborative DEVS Modeler (cont.) u HW/SW Specification: –Computing HW platforms: Unix workstation, PC, & Mac –OS: Solaris, Windows, Mac-OS, Linux –Language: Java u Organization: University of Arizona u POC: –Hessam Sarjoughian –Ph: 520-626-4846 –Email: hessam@ece.arizona.edu –URL: www.acims.arizona.edu

DEVS/HLA/CORBA TutorialSIW(fall 2000)270 DEVSJAVA u Purpose: Prototyping of Distributed Simulations u Major Functions: –Enables design of HLA federates and federations –Seamless transition to DEVS/HLA and DEVS/CORBA –Supports M&S Education –Easy to use DEVS-Based M&S Environment –Object-oriented u HLA FEDEP Support: Phases 2, 3, and 4

DEVS/HLA/CORBA TutorialSIW(fall 2000)271 DEVSJAVA (cont.) u HW/SW Specification: –Computing HW platforms: Unix workstation & PC –OS: Unix Solaris & Windows u Organization: University of Arizona u POC: –Bernard Zeigler/Hessam Sarjoughian –Ph: 520-626-4846 –Email: {hessam|zeigler}@ece.arizona.edu –URL: www.acims.arizona.edu

DEVS/HLA/CORBA TutorialSIW(fall 2000)272 DEVS-DOC (Distributed Object Computing) u Purpose: Distributed M&S Co-Design Environment u Major Functions: –Supports distributed co-design (e.g., DEVS/HLA Federation Design) –Supports concurrent HW and SW layers u HLA FEDEP Support: Phases 2 and 3 u HW/SW Specification: –Computing HW platforms: Unix workstations and PCs –OS: Solaris and Windows –Language: Java u Organization: University of Arizona u POC: Daryl Hild, Hessam Sarjoughian u Email: d.hild@ieee.org, hessam@ece.arizona.edu

DEVS/HLA/CORBA TutorialSIW(fall 2000)273 DEVS/CORBA u Purpose: Generic Environment for DEVS-based M&S u Major Functions: –System-theory and formal M&S concepts –Enables developing components in DEVSJAVA –Business strength capability

DEVS/HLA/CORBA TutorialSIW(fall 2000)274 DEVS/CORBA (cont.) u HW/SW Specification: –Computing HW platforms: Unix workstation & PC –OS: Unix Solaris & Windows NT –Languages: Java –Visibroker (Version ?) u Organization: University of Arizona u POC: –Bernard Zeigler –Ph: 520-626-4846 –Email: zeigler@ece.arizona.edu –URL: www.acims.arizona.edu

DEVS/HLA/CORBA TutorialSIW(fall 2000)275 More Information Many more publications and downloadable software are available from Website: www.acims.arizona.edu u Committee on Technology for Future Naval Forces, N. R. C. (1997). Technology for the United States Navy and Marine Corps, 2000-2035 Becoming a 21st-Century Force: Volume 9: Modeling and Simulation. Washington, DC, National Academy Press. u Zeigler, B. P. (1998). A Framework for Modeling & Simulation. In Applied Modeling & Simulation: An Integrated Approach to Development & Operation. D. Cloud and L. Rainey, (Eds)McGraw Hill. u Zeigler, B. P., H. Praehofer, T. G. Kim (2000). Theory of Modeling and Simulation. Second Edition, New York, NY, Academic Press.

Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA.

Similar presentations

Presentation on theme: "Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA.

Similar presentations

Presentation on theme: "Creating Distributed Simulations: The Triad website: www.acims.arizona.edu Bernard P. Zeigler Hessam S. Sarjoughian University of Arizona, Tucson, USA."— Presentation transcript:

Similar presentations

About project

Feedback