Parallel and Distributed Simulation Distributed Virtual Environments (DVE) & Software Introduction

Outline Intro: DVE example Federated Simulations Basic Services –Class Based Subscription –Attribute updates –Tick –Synchronized delivery: Time management

Image Generator Other Vehicle State Table network interface control/ display interface own vehicle dynamics sound generator visual display system terrain database network controls and panels A Typical DVE Node Simulator Reproduced from Miller, Thorpe (1995), “SIMNET: The Advent of Simulator Networking,” Proceedings of the IEEE, 83(8): Execute every 1/30th of a second: receive incoming messages & user inputs, update state of remote vehicles update local display for each local vehicle compute (integrate) new state over current time period send messages indicating new state

Image Generator Other Vehicle State Table network interface control/ display interface own vehicle dynamics sound generator visual display terrain database Image Generator Other Vehicle State Table network interface control/ display interface own vehicle dynamics sound generator visual display terrain database Controls/panels Typical Sequence 1 1. Detect trigger press 2 2. Audio “fire” sound 3 3. Display muzzel flash Send fire message 5 5. Display muzzel flash 6 6. Compute trajectory, display tracer 7 7. Display shell impact Send detonation message 9 9. Display shell impact Compute damage Send Entity state message indicating damage

Federated Simulations Simulation (federate) Runtime Infrastructure(RTI) Services to create and manage the execution of the federation Federation setup / tear down Transmitting data among federates Synchronization Interface Specification Interface Specification Federation Simulation (federate) Simulation (federate) Interconnecting autonomous simulators

Federates not designed for a specific federation Internet gaming simulations –Plug ‘n play capability –Number, type of players change dynamically Department of Defense High Level Architecture –Model reuse: Federates may be used in different federations during its lifetime –Legacy simulations: not originally designed for inclusion in federations

Message Passing Alternatives Traditional message passing mechanisms: Sender explicitly identifies receivers –Destination process, port, etc. –Poorly suited for federated simulations Broadcast –Receiver discards messages not relevant to it –Used in SIMNET, DIS (initially) –Doesn’t scale well to large federations Publication / Subscription mechanisms –Analogous to newsgroups –Producer of information has a means of describing data it is producing –Receiver has a means of describing the data it is interested in receiving –Used in High Level Architecture (HLA)

Class-Based Data Distribution (simplified) Federation Object Model (FOM) defines type of information transmitted among federates –Object classes (e.g., tank) –Attributes (e.g., position, orientation of turret) Primitives (Federate/RTI interface) – Publish Object Class Attributes: Called by a federate to declare the object classes and attributes it is able to update – Subscribe Object Class Attributes: Declare the object classes and attributes that the federate is interested in receiving – Register Object Instance: Notify RTI an instance of an object has been created within the federate – Discover Object Instance: Notify federate an instance of an object of a subscribed class has been registered – Update Attribute Values: notify RTI one or more attributes of an object has been modified – Reflect Attribute Values: notify federate attributes to which it has subscribed have been modifed

Example OCA = Object Class Attributes OI = Object Instance AV = Attribute Values Federate 1 Federate 2 RTI PublishOCA (Tank, position) SubscribeOCA (Tank, position) handle := RegisterOI (Tank) DiscoverOI (Tank, instance) UpdateAV (handle, position, ) ReflectAV (instance, position, )

Federated vs. RTI Initiated Services Some services are initiated by the federate, others by the RTI Federate invoked services –Publish, subscribe, register, update –Not unlike calls to a library –Procedures defined in the RTI ambassador RTI invoked services –Discover, reflect –Federate defined procedures, in Federate Ambassador RTI Federate Federate ambassador RTI ambassador Update Reflect

Single vs. Multi-threaded Multi-threaded implementation –RTI software and federate code execute as separate threads of execution –Switching execution between RTI and federate largely transparent to the federate Single-threaded implementation –RTI and federate share a single thread of execution (like libraries) –Federate must explicitly pass control to the RTI, e.g., to deliver messages –Tick() procedure is defined for this purpose –Callbacks (Discover, Reflect) made within Tick

Example: Receiving a Message Boolean: Waiting4Message; { … Waiting4Message := TRUE; while (Waiting4Message) Tick(); … } /* Federate ambassador */ Proc ReflectAttributeValues (…) { save incoming message in buffer Waiting4Message := FALSE; } FederateRTI Tick ReflectAttributeValues return (RAV) return (Tick)

Synchronizing Message Delivery Goal: process all events (local and incoming messages) in time stamp order; To support this, RTI will Deliver messages in time stamp order (TSO) Synchronize delivery with simulation time advances RTI federate TSO messages TSO messages local events local events logical time current time next local event next TSO message T Federate: next local event has time stamp T If no TSO messages w/ time stamp < T, advance to T, process local event If there is a TSO message w/ time stamp T’ ≤ T, advance to T’ and process TSO message T’

Next Event Request (NER) Federate invokes Next Event Request (T) to request its logical time be advanced to time stamp of next TSO message, or T, which ever is smaller If next TSO message has time stamp T’ ≤ T –RTI delivers next TSO message, and all others with time stamp T’ –RTI issues Time Advance Grant (T’) Else –RTI advances federate’s time to T, invokes Time Advance Grant (T) Typical execution sequences RTI NER(T) RAV (T’) TAG(T’) NER: Next Event Request TAG: Time Advance Grant RAV: Reflect Attribute Values Federate calls in black RTI callbacks in red Wall clock time FederateRTI NER(T) TAG(T) RTI delivers eventsno TSO events Federate

sequential simulator T = current simulation time PES = pending event set While (simulation not complete) T = time of next event in PES process next event in PES End-While federated simulator While (simulation not complete) T = time of next event in PES PendingNER = TRUE; NextEventRequest(T) while (PendingNER) Tick(); process next event in PES End-While /* the following federate-ambassador procedures are called by the RTI */ Procedure ReflectAttributeValues (…) place event in PES Procedure TimeAdvanceGrant (…) PendingNER = False; Code Example: Event Stepped Federate

Time Advance Request (TAR) Typically used by time stepped federates Federate invokes Time Advance Request (T) to request its logical time (LT) be advanced to T RTI delivers all TSO messages with time stamp ≤ T RTI advances federate’s time to T, invokes Time Advance Grant (T) when it can guarantee all TSO messages with time stamp ≤ T have been delivered Grant time always matches the requested time Typical execution sequence Wall clock time FederateRTI TAR(20) RAV (14) RAV (18) TAG(20) TAR: Time Advance Request RAV: Reflect Attribute Values TAG: Time Advance Grant Federate calls in black RTI callbacks in red LT=10 LT=20

Code Example: Time Stepped Federate sequential simulator T = current simulation time While (simulation not complete) update local simulation state T = T + ∆T; End-While federated simulator While (simulation not complete) update local simulation state UpdateAttributeValues (…) PendingTAR = TRUE; TimeAdvanceRequest(T+ ∆T) while (PendingTAR) Tick(…); T = T + ∆T; End-While /* the following federate-defined procedures are called by the RTI */ Procedure ReflectAttributeValues (…) update local state Procedure TimeAdvanceGrant (…) PendingTAR = False;

Summary Distributed simulation: federates, RTI Federates –Model some subset of entities in virtual world –Send messages to other federates concerning aspects of entities that are “visible” to entities in other federates RTI services –Setting up and realizing communication among federates –Control and management of federation execution –Synchronizing message delivery (if needed)