gestion du temps et des evenements en hla (synchronisation) a. nketsa laas, groupe ocsd
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
GESTION DU TEMPS ET DES EVENEMENTS EN HLA (SYNCHRONISATION)
A. NketsaLAAS, Groupe OCSD
7, Avenue du Colonel Roche31077 Toulouse Cédex
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
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
HLA Federation
Simulation(federate)
Runtime Infrastructure(RTI)Services to create and manage the execution of the federation• Federation setup / tear down• Transmitting data among federates• Synchronization (time management)
InterfaceSpecification
InterfaceSpecification
Federation
Simulation(federate)
Simulation(federate)
Interconnecting autonomous simulators
Interface Specification
Category Functionality
Federation ManagementCreate and delete federation executionsjoin and resign federation executionscontrol checkpoint, pause, resume, restart
Declaration ManagementEstablish intent to publish and subscribe to object attributes and interactions
Object Management
Create and delete object instancesControl attribute and interaction publicationCreate and delete object reflections
Ownership Management Transfer ownership of object attributes
Time ManagementCoordinate the advance of logical time and its relationship to real time
Data Distribution Management Supports efficient routing of data
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)
NOTIONS DE TEMPS ET MODES D'EXECUTION
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))
système physique
• Système physique: sytème actuel ou modélisé• simulation: émulation du système physique
simulation
main(){ ...double clock;...
}
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)
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
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)
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
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)
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
COMPLEMENT GESTION TEMPS DE SIMULATION
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 )
Lower Bound on Time Stamp (LBTS)
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
5 6 7 8 9 10 11 12 13 14 15 16
98
1510
7
H1
H2
H3
H3@6(non bloqué)
[email protected](bloqué)
H1@5
transient
Temps SimulationLBTS = ?
LBTS = min (6, 10, 7) ( zero lookahead)
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 messageOK 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)
TYPES DE MESSAGES
HLA Message Ordering Services
typical applications training, T&E analysis
Latency
reproduce before and after relationships?all federates see same ordering of events?
execution repeatable?
Property
low
no
no
no
ReceiveOrder (RO)
higher
yes
yes
yes
Time StampOrder (TSO)
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
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
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 ambassadorUpdate Reflect
Example: Receiving a Message
/* code sketch, receiving messages */Boolean: Waiting4Message;
{ …Waiting4Message := TRUE;while (Waiting4Message) Tick();
…}
/* Federate ambassador */Proc ReflectAttributeValues (…){
save incoming message in bufferWaiting4Message := FALSE;
}
Federate RTI
Tick
return (RAV)
return (Tick)
Tick(): transfer execution to RTI to perform RTI functions, perform callbacks
AVANCEMENT DU TEMPS SIMULE
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
federate
RTI
Time Advance Requestor
Next Event RequestTime Advance Grant
HLA Time Management Services
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
FIFOqueue
FIFOqueue
timestamp
orderedqueue
timestamp
orderedqueue
Runtime Infrastructure (RTI)
state updatesand interactions logical time advances
receiveorder
messages
time stamporder
messages
eventordering
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
fauxVrai
Vr
aiF
aux
Tem
ps
contrain
t
Régulateur du temps
Synchonisationtemporelle stricte Conservative Optimiste
Reception des événementsPas de génération
Synchronisation externepas de gestion de temps
GénérateurévénementsRégulateur
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
TSOmessages
TSOmessages
localevents
localevents
logicaltimecurrent
time
nextlocalevent
nextTSO
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)
NER(T)
RAV (T’)
RAV (T’)
TAG(T’)
NER(T)
TAG(T)
Federate RTI
no TSO events
Typical execution sequences
RTI
Wall clocktimeRTI delivers events
Federate
NER: Next Event RequestTAG: Time Advance GrantRAV: Reflect Attribute Values
Federate calls in blackRTI callbacks in red
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 simulatorWhile (simulation not complete)
T = time of next event in PESPendingNER = 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
ACCELERATION SIMULATION
Logical timeT+LT1. Current time is T, lookahead L2. Request lookahead decrease by ∆L to 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
Logical timeT+LT+ ∆T
L- ∆T∆T
3. Advance ∆T, lookahead, decreases ∆T
Logical timeT+L
L’∆L
T+∆L 4. After advancing ∆L, lookahead is L’
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
Federate0
network
TSO queue13118
Federate1
Current Time =8Lookahead = 2
Federate2
Current Time =9Lookahead = 8
Minimum Next Event Time and LBTS
• 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
LBTS0=10
MNET0=8
• 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
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)
FederateA
RTI
example
FederateB
1. RTI issues Time Advance Grant to time T
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.
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
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 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
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
Wallclock time
Vehicle
Observer
Sample execution sequence: NER: Next Event RequestUAV: Update Attribute Values)TAG: Time Advance Grant (callback)
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)
1. Vehicle schedules position update at time 100, ready to advance to time 100
1. NER (100)
1. Handle=UAV (100)
2. Receive Interaction (90)2. TAG (90)
2. receives interaction (break down event) invalidating position update at time 100
3. Retract(Handle)
3. Vehicle retracts update scheduled for time 100
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)
Optimistic Time Management
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
Optimistic Time Management in the HLA
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
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
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