High Level Architecture

Time Management

Time Management

Time management is a difficult subjectThere is no real time management in DIS;

things happen as packets arrive. There are timestamps, but there is no concept of a shared clocktime between participants in the simulation

There’s no real way to express the concept of “wait until all participants are ready, then advance the simulation clock time”

Consistency-Throughput Tradeoff

There’s an inherent tradeoff in distributed systems between consistency and throughput

A host sends out an update of an entity position. Due to network latency, other machines will receive this update sometime later, say 100ms. But during that time the original entity has moved--there is no longer a consistent state among all hosts

Consistency-Throughput Tradeoff

You can make the state consistent among all hosts--send an update, wait for an ACK from all other hosts, something like a distributed database transaction/commit

But this affects simulator playability. Eg, you’re giving input to the joystick but the simulator doesn’t respond because it must first receive updates from all other hosts

DIS is “open loop”

Time Management

HLA can do continuous simulation, in which every participant advances in a time step (say, 1/10 of a second)

This is the difference between event-driven simulation and continuous simulation. In event-driven simulation we can advance the simulation time to the next scheduled event, because the state of the system does not change between events

HLA doesn’t necessarily have a single, global clock, but the federates can be constrained to be within a similar simulation clock time

Continuous

Advance simulation logical time by a fixed amount everyTime slice. The time slice may not correspond to wall clock time

Time

Event-Driven

Time

Event A B C D E F

The state of the simulation does not change betweenEvents. Simulation logical time may not be the same as wallclock time

Time Management

Different concepts of time:• Logical simulation time: the clock time in the

simulation• Wall clock time: how a human watching the

simulation sees timeYou could have a continuous simulation with a

logical simulation time that advances faster or slower than wall clock time

You could have an event-driven simulation that advances faster or slower than wall clock time

Real time vs Non-Real Time

Aside from the internal logical time of the simulation federates, we can also coordinate time with human observers

• Real time: events in the simulation happen at the same time scale as the humans interacting with it. Useful for human-in-the-loop simulations

• Scaled real time: sped up (say, 10X faster or 10X slower) than wall clock time

Time Management

Options for HLA• No time management• Conservative Synchronization• Optimistic Synchronization• Activity ScanA single federate can make its own choice

about participating in time managementNo official units on time; time is discrete,

well-ordered, etc

Time Management

No time management: turn it all offConservative: advance logical time only when

sure they will receive no events from the pastOptimistic: Go ahead and advance logical time,

but if an older event arrives, be prepared to roll back all events since that one

Activity Scan: federates exchange messages until they agree to advance logical time together

Optimistic

“Optimistic” is rarely used--gets into parallel discrete simulation (Warp et al) and is a very tricky subject

Most are either “conservative” or “no time management”

Time Constraints

A federate can be time regulating, which means that it can generate events that are time-stamped with the simulation clock time (time stamp ordered events)

A federate can be time constrained, which means it can receive time stamp ordered events

Regulating can constrain other federates via the timestamps of events

Constraining is limited in advancing the clock by the time stamps of events generated by other federates

Federates can be both regulating and constrained, either, or none

The default for new federates is neither

Time Ordered Events

Federates can send time ordered events:• Update attribute values• Send interaction• Delete object instanceAnd receive time-ordered events• Reflect attribute values• Reflect interaction• Remove object instance

Time Constraints

Time stamp ordered events are delivered to federates in time order, independent of the order in which they were sent. If a federate sends a time stamped event before another federate, it will still arrive at other federates in logical time order

No event can be delivered to a federate with at time stamp less than the current logical time of the federate

Time Management

No time regulation: Each federate can advance time at its own pace, without trying to coordinate clock advancement with other federates

This does not necessarily work well with real time simulations; fast computers advance at a greater rate than slow computers. Also creates simulation logic issues

In real time simulations intervals between events are perceived to be “normal”

Logical simulation time is tied (approximately) to wall clock time. The simulation slows down (usually) so that simulation time events are similar to wall clock time

Time

If a federate is time-regulating (sends time-ordered events) it should make requests of the RTI to advance its clock

The RTI time advance requests advance time, not the mere fact of sending events

With conservative sync, call timeAdvanceRequest() or nextEventRequest() on the RTI

Time

Federates can specify synchronization points, where all federates will stop and wait until some criteria is met; time, number of participants, etc