1 / 43

GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION) A. Nketsa LAAS, Groupe OCSD

GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION) A. Nketsa LAAS, Groupe OCSD 7, Avenue du Colonel Roche 31077 Toulouse Cédex. PLAN  RAPPEL HLA  NOTIONS DE TEMPS ET MODES D'EXECUTION  DIFFERENTS MECHANISMES DE GESTION DU TEMPS EN SIMULATION

benjy
Download Presentation

GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION) A. Nketsa LAAS, Groupe OCSD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 thatsimulations (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. 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. Federation Management Create and delete federation executions join and resign federation executions control checkpoint, pause, resume, restart Establish intent to publish and subscribe to object attributes and interactions Declaration Management 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 Interface Specification Category Functionality

  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. Système physique: sytème actuel ou modélisé • simulation: émulation du système physique système physique simulation main() { ... double clock; ... } Notions de temps • 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-timeexecution) • 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 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. 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. H3@6 (non bloqué) 8 9 H3 H2@6.1 (bloqué) 10 15 H2 5 6 7 8 9 10 11 12 13 14 15 16 7 transient H1 LBTS = ? Temps Simulation H1@5 Lower Bound on Time Stamp (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. problème: parallélisme limité Chaque LP consomme les événements dans l'ordre des estampilles event without lookahead LP D possible message OK to process LP C with lookahead possible message LP B OK to process LP A not OK to process yet TA TA+LA Logical Time • 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) Lookahead

  19. TYPES DE MESSAGES

  20. Property Receive Order (RO) Time Stamp Order (TSO) Latency low higher reproduce before and after relationships? no yes all federates see same ordering of events? no yes execution repeatable? no yes typical applications training, T&E analysis 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 • 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 • RO otherwise † 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. RTI Federate Tick return (RAV) return (Tick) Example: Receiving a Message Tick(): transfer execution to RTI to perform RTI functions, perform callbacks /* code sketch, receiving messages */ Boolean: Waiting4Message; { … Waiting4Message := TRUE; while (Waiting4Message) Tick(); … } /* Federate ambassador */ Proc ReflectAttributeValues (…) { save incoming message in buffer Waiting4Message := FALSE; }

  24. AVANCEMENT DU TEMPS SIMULE

  25. federate Time Advance Request or Next Event Request Time Advance Grant RTI 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 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. event ordering time stamp order messages receive order messages Runtime Infrastructure (RTI) FIFO queue time stamp ordered queue logical time state updates and interactions logical time advances 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) HLA Time Management Services

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

  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. 1. Current time is T, lookahead L 2. Request lookahead decrease by ∆L to L’ T+L Logical time T L- ∆T ∆T 3. Advance ∆T, lookahead, decreases ∆T T+L Logical time T+ ∆T L’ ∆L 4. After advancing ∆L, lookahead is L’ Logical time T+∆L T+L 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

  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. network TSO queue Current Time =8 Lookahead = 2 Current Time =9 Lookahead = 8 Federate0 Federate1 Federate2 13 11 8 Minimum Next Event Time and LBTS 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. example 2. Federate A sends a zero lookahead message (time stamp T) requesting information from another federate RTI 1. RTI issues Time Advance Grant to time T 3. Federate B sends reply message with time stamp T (zero lookahead) to Federate A. Federate A Federate B Zero Lookahead • 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

  38. Zero Lookahead in the HLATAR 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 notguarantee 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. Sample execution sequence: NER: Next Event Request UAV: Update Attribute Values) TAG: Time Advance Grant (callback) 1. NER (100) 2. TAG (90) 2. Receive Interaction (90) Vehicle 3. Retract(Handle) 1. Handle=UAV (100) Observer Wallclock time 1. Vehicle schedules position update at time 100, ready to advance to time 100 2. receives interaction (break down event) invalidating position update at time 100 3. Vehicle retracts update scheduled for time 100 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)

  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

More Related