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é)

H2@6.1(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