GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION)

Présentation au sujet: "GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION)"— Transcription de la présentation:

1 GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION)
A. Nketsa LAAS, Groupe OCSD 7, Avenue du Colonel Roche 31077 Toulouse Cédex

2 PLAN  RAPPEL HLA  NOTIONS DE TEMPS ET MODES D'EXECUTION  DIFFERENTS MECHANISMES DE GESTION DU TEMPS EN SIMULATION  GESTION DU TEMPS EN HLA (RTI)  TYPES DE MESSAGES  AVANCEMENT DU TEMPS

3 High Level Architecture (HLA)
based on a composable “system of systems” approach no single simulation can satisfy all user needs support interoperability and reuse among DoD simulations federations of simulations (federates) pure software simulations human-in-the-loop simulations (virtual simulators) live components (e.g., instrumented weapon systems) mandated as the standard reference architecture for all M&S in the U.S. Department of Defense (September 1996) The HLA consists of rules that simulations (federates) must follow to achieve proper interaction during a federation execution Object Model Template (OMT) defines the format for specifying the set of common objects used by a federation (federation object model), their attributes, and relationships among them Interface Specification (IFSpec) provides interface to the Run-Time Infrastructure (RTI), that ties together federates during model execution

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

5 Interface Specification
Category Functionality Federation Management Create and delete federation executions join and resign federation executions control checkpoint, pause, resume, restart Declaration Management Establish intent to publish and subscribe to object attributes and interactions Object Management Create and delete object instances Control attribute and interaction publication Create and delete object reflections Ownership Management Transfer ownership of object attributes Time Management Coordinate the advance of logical time and its relationship to real time Data Distribution Management Supports efficient routing of data

6 A Typical Federation Execution
initialize federation Create Federation Execution (Federation Mgt) Join Federation Execution (Federation Mgt) declare objects of common interest among federates Publish Object Class (Declaration Mgt) Subscribe Object Class Attribute (Declaration Mgt) exchange information Update/Reflect Attribute Values (Object Mgt) Send/Receive Interaction (Object Mgt) Time Advance Request, Time Advance Grant (Time Mgt) Request Attribute Ownership Assumption (Ownership Mgt) Modify Region (Data Distribution Mgt) terminate execution Resign Federation Execution (Federation Mgt) Destroy Federation Execution (Federation Mgt)

7 NOTIONS DE TEMPS ET MODES D'EXECUTION

8 Notions de temps système physique
Système physique: sytème actuel ou modélisé simulation: émulation du système physique simulation main() { ... double clock; ... } temps physique: temps dans le système physique temps simulé : représentation du temps physique pendant la simulation temps absolu (horloge) : temps d'exécution de la simulation (fourni par une horloge matérielle (e.g., GPS))

9 Modes d'exécution d'une simulation
Aussi rapide que possible (As-fast-as-possible execution) : pas de relation directe dans l'avancement du temps entre le temps simulé et une horloge. synchronisation temporelle (respect du principe de causalité) Temps réel (Real-time execution) synchronisation événementielle (pas de temps explicite)

10 Différents mécanismes de gestion de temps en simulation
Simulation orientée événement : Evénements traités dans l'ordre des estampilles (Causalité) Avancement du temps = estampille Simulation orientée temps : Evénements traités par paquet Avancement par pas de durée fixée

11 Différents mécanismes de gestion de temps en simulation
Simulation distribuée : Evénements traités en parallèle Risque de violation du principe de causalité Nécessité de synchronisation synchronisation conservative (base HLA) synchronisation optimiste (Extension HLA) Simulation temps réel : Temps de réponse compatible avec l'exécution Synchronisation des horloges Ordonnancement temps réel compensation du temps (des délais)

12 CONCLUSIONS POUR HLA - RTI
Implémentation des fonctions de base de gestion du temps indépendante des modèles utilisés Proposition service minimal, délai de communication prédictif calcul minimal pour la synchronisation et la communication pas de traitement de synchronisation inutile

13 CONCLUSIONS POUR HLA - RTI
RTI (suite) Types de messages Receiver order (RO) Time stamp order (TSO) Services de gestion de temps: système d'ordre des messages estampillés protocole: - le fédéré : demande explicite d'avancement du temps - le RTI : accord d'avancement (butée simulation)

14 traitement du temps simulé coordination :
RTI (Suite) Services de gestion du temps : traitement du temps simulé coordination : avancement du temps simulé mise à disposition des données estampillées support de plusieurs types de gestion du temps pas de gestion explicite du temps (temps réel) synchronisation conservative synchronisation optimiste scrutation des activités (simulation orientée horloge) mélanges des types

15 COMPLEMENT GESTION TEMPS DE SIMULATION

16 Lower Bound on Time Stamp (LBTS)
Pas de null messages, chaque LP peut envoyer des messages à n'importe quel autre LP LP bloqué, calculer lower bound on time stamp (LBTS) des messages à recevoir plus tard (avec estampille < LBTS )

17 Lower Bound on Time Stamp (LBTS)
5 6 7 8 9 10 11 12 13 14 15 16 H1 H2 H3 (non bloqué) (bloqué) transient Temps Simulation LBTS = ? LBTS = min (6, 10, 7) ( zero lookahead) LBTS minimum parmi Estampille de tous les messages transitoires (envoyés, mais non encore reçus) LP non bloqués : temps courant de simulation + lookahead LP bloqués : Time of next event + lookahead

18 Lookahead LP A LP B LP C LP D Logical Time
problème: parallélisme limité Chaque LP consomme les événements dans l'ordre des estampilles TA possible message OK to process event not OK to process yet without lookahead TA+LA possible message OK to process with lookahead Each LP A using declares a lookahead value LA; the time stamp of any event generated by the LP must be  TA+ LA Used in virtually all conservative synchronization protocols Relies on model properties (e.g., minimum transmission delay) Lookahead is necessary to allow concurrent processing of events with different time stamps (unless optimistic event processing is used)

19 TYPES DE MESSAGES

20 HLA Message Ordering Services
The HLA provides two types of message ordering: receive order (unordered): messages passed to federate in an arbitrary order time stamp order (TSO): sender assigns a time stamp to message; successive messages passed to each federate have non-decreasing time stamps typical applications training, T&E analysis Latency reproduce before and after relationships? all federates see same ordering of events? execution repeatable? Property low no Receive Order (RO) higher yes Time Stamp Order (TSO) receive order minimizes latency, does not prevent temporal anomalies TSO prevents temporal anomalies, but has somewhat higher latency

21 Related Object Management Services
Sending and Receiving Messages Update Attribute Values … Reflect Attribute Values † Send Interaction … Receive Interaction † Message Order (Receive Order or Time Stamp Order) Preferred Order Type: default order type specified in “fed file” for each attribute and interaction Sent Message Order Type: TSO if preferred order type is TSO and the federate is time regulating and a time stamp was used in the Update Attribute Values or Send Interaction call RO otherwise Received Message Order Type TSO if sent message order type is TSO and receiver is time constrained † indicates callback to federate

22 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 Federate Federate ambassador Update Reflect RTI ambassador RTI

23 Example: Receiving a Message
Tick(): transfer execution to RTI to perform RTI functions, perform callbacks Federate RTI Tick /* code sketch, receiving messages */ Boolean: Waiting4Message; { … Waiting4Message := TRUE; while (Waiting4Message) Tick(); … } /* Federate ambassador */ Proc ReflectAttributeValues (…) { save incoming message in buffer Waiting4Message := FALSE; return (RAV) return (Tick)

24 AVANCEMENT DU TEMPS SIMULE

25 Advancing Logical Time
HLA TM services define a protocol for federates to advance logical time; logical time only advances when that federate explicitly requests an advance Time Advance Request: time stepped federates Next Event Request: event stepped federates Time Advance Grant: RTI invokes to acknowledge logical time advances federate RTI Time Advance Request or Next Event Request Time Advance Grant If the logical time of a federate is T, the RTI guarantees no more TSO messages will be passed to the federate with time stamp < T Federates responsible for pacing logical time advances with wallclock time in real-time executions

26 HLA Time Management Services
event ordering federate local time and event management mechanism to pace execution with wallclock time (if necessary) federate specific techniques (e.g., compensation for message latencies) wallclock time (synchronized with other processors) logical time FIFO queue time stamp ordered Runtime Infrastructure (RTI) state updates and interactions logical time advances receive order messages time stamp

27 Time Regulating and Time Constrained Federates
Federates must declare their intent to utilize time management services by setting their time regulating and/or time constrained flags Time regulating federates: can send TSO messages Can prevent other federates from advancing their logical time Enable Time Regulation … Time Regulation Enabled † Disable Time Regulation Time constrained federates: can receive TSO messages Time advances are constrained by other federates Enable Time Constrained … Time Constrained Enabled † Disable Time Constrained Each federate in a federation execution can be Time regulating only (e.g., message source) Time constrained only (e.g., Stealth) Both time constrained and regulating (common case for analytic simulations) Neither time constrained nor regulating (e.g., DIS-style training simulations) † indicates callback to federate

28 Régulateur du temps Vrai faux Reception des événements Pas de génération Synchonisation temporelle stricte Conservative Optimiste Temps contraint Vrai Synchronisation externe pas de gestion de temps Générateur événements Régulateur Faux

29 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 next TSO message RTI TSO messages next local event T’ federate local events logical time T current time 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

30 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 Wall clock time RTI delivers events Federate NER: Next Event Request TAG: Time Advance Grant RAV: Reflect Attribute Values Federate calls in black RTI callbacks in red Federate RTI no TSO events NER(T) NER(T) RAV (T’) TAG(T) RAV (T’) TAG(T’)

31 Code Example: Event Stepped 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;

32 ACCELERATION SIMULATION

33 Lookahead in the HLA Each federate must declare a non-negative lookahead value Any TSO sent by a federate must have time stamp at least the federate’s current time plus its lookahead Lookahead can change during the execution (Modify Lookahead) increases take effect immediately decreased do not take effect until the federate advances its logical time Logical time T+L T 1. Current time is T, lookahead L 2. Request lookahead decrease by ∆L to L’ Logical time T+L T+ ∆T L- ∆T ∆T 3. Advance ∆T, lookahead, decreases ∆T Logical time T+L L’ ∆L T+∆L 4. After advancing ∆L, lookahead is L’

34 Federate/RTI Guarantees
Federate at logical time T (with lookahead L) All outgoing TSO messages must have time stamp ≥ T+L (L>0) Time Advance Request (T) Once invoked, federate cannot send messages with time stamp less than T plus lookahead Next Event Request (T) Once invoked, federate cannot send messages with time stamp less than T plus the federate’s lookahead unless a grant is issued to a time less than T Time Advance Grant (T) (after TAR or NER service) All TSO messages with time stamp less than or equal to T have been delivered

35 Minimum Next Event Time and LBTS
Federate0 network TSO queue 13 11 8 Federate1 Current Time =8 Lookahead = 2 Federate2 Current Time =9 Lookahead = 8 LBTS0=10 MNET0=8 LBTSi: Lower Bound on Time Stamp of TSO messages that could later be placed into the TSO queue for federate i TSO messages w/ TS ≤ LBTSi eligible for delivery RTI ensures logical time of federate i never exceeds LBTSi MNETi: Minimum Next Event Time is a lower bound on the time stamp of any message that could later be delivered to federate i. Minimum of LBTSi and minimum time stamp of messages in TSO queue

36 Simultaneous Events Simultaneous events are events containing the same time stamp Ordering of simultaneous events often important RTI does not have sufficient information to intelligently order simultaneous events HLA: ordering simultaneous events left to the federate Grant to time T (after TAR/NER): all events with time stamp T delivered to federate Simultaneous events delivered to federate in an arbitrary order (may vary from one execution to the next) Federate must have a deterministic way to order simultaneous to ensure repeatable executions (e.g., sort events by type or other event properties)

37 Zero Lookahead Federate A RTI example B
Zero lookahead: a federate at time T can send TSO messages with time stamp T If zero lookahead is allowed, a Time Advance Grant to time T cannot guarantee delivery of all events with time stamp equal to T Federate A RTI example B 2. Federate A sends a zero lookahead message (time stamp T) requesting information from another federate 3. Federate B sends reply message with time stamp T (zero lookahead) to Federate A. 1. RTI issues Time Advance Grant to time T

38 Zero Lookahead in the HLA TAR Available and NER Available
Zero lookahead allowed in HLA federations Next Event Request (NER), Time Advance Request (TAR) grant to time T guarantees delivery of all TSO messages w/ time stamp T (or less) constraint: once a Time Advance Grant to time T is issued for these requests, subsequent messages sent by the federate must have time stamp strictly greater than T. Two new services: Time Advance Request Available (TARA) and Next Event Request Available (NERA) TARA (NERA) advance logical time, similar to TAR (NER) federate can send zero lookahead messages after receiving grant grant to time T does not guarantee all messages with time stamp T have been delivered, only those available at the time of the call order that TSO messages are delivered to the federate is arbitrary

39 Representation of Logical Time
Time represented as a federation-defined abstract data type Federation must agree upon a common representation of logical time during federation development Time value (e.g., 09:00, 12 May 1973) Time duration (e.g., 30 minutes) Federation specifies Data type of time values and duration (structure types allowed) Comparison (time values) and addition (value and duration) operators

40 Event Retraction Previously sent events can be “unsent” via the Retract service Update Attribute Values and Send Interaction return a “handle” to the scheduled event Handle can be used to Retract (unschedule) the event Can only retract event if its time stamp > current time + lookahead Retracted event never delivered to destination (unless Flush Queue used) Wallclock time Vehicle Observer Sample execution sequence: NER: Next Event Request UAV: Update Attribute Values) TAG: Time Advance Grant (callback) 2. Receive Interaction (90) 2. TAG (90) 2. receives interaction (break down event) invalidating position update at time 100 1. Vehicle schedules position update at time 100, ready to advance to time 100 1. NER (100) 1. Handle=UAV (100) 3. Retract(Handle) 3. Vehicle retracts update scheduled for time 100

41 Optimistic Time Management
Mechanisms to ensure events are processed in time stamp order: conservative: block to avoid out of order event processing optimistic: detect out-of-order event processing, recover (e.g., Time Warp) Primitives for optimistic time management Optimistic event processing Deliver (and process) events without time stamp order delivery guarantee HLA: Flush Queue Request Rollback Deliver message w/ time stamp T, other computations already performed at times > T Must roll back (undo) computations at logical times > T HLA: (local) rollback mechanism must be implemented within the federate Anti-messages & secondary rollbacks Anti-message: message sent to cancel (undo) a previously sent message Causes rollback at destination if cancelled message already processed HLA: Retract service; deliver retract request if cancelled message already delivered Global Virtual Time Lower bound on future rollback to commit I/O operations, reclaim memory HLA: Query Next Event Time service gives current value of GVT

42 Optimistic Time Management in the HLA
HLA Support for Optimistic Federates federations may include conservative and/or optimistic federates federates not aware of local time management mechanism of other federates (optimistic or conservative) optimistic events (events that may be later canceled) will not be delivered to conservative federates that cannot roll back optimistic events can be delivered to other optimistic federates individual federates may be sequential or parallel simulations Flush Queue Request: similar to NER except (1) deliver all messages in RTI’s local message queues, (2) need not wait for other federates before issuing a Time Advance Grant

43 Summary: HLA Time Management
Functionality: allows federates with different time management requirements (and local TM mechanisms) to be combined within a single federation execution DIS-style training simulations simulations with hard real-time constraints event-driven simulations time-stepped simulations optimistic simulations HLA Time Management services: Event order receive order delivery time stamp order delivery Logical time advance mechanisms TAR/TARA: unconditional time advance NER/NERA: advance depending on message time stamps