High Level Architecture Time Management

Time management is a difficult subject There is no real time management in DIS (usually); things happen as packets arrive. There are timestamps, but there is no concept of a constrained 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 time-step 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 time-step 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

Time Step Advance simulation logical time by a fixed amount every Time 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 between Events. Simulation logical time may not be the same as wall clock 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 time You could have a time step 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 Scan A single federate can make its own choice about participating in time management No official units on time; time is discrete, well- ordered, etc

Time Management No time management: turn it all off Conservative: advance logical time only when sure they will receive no events from the past Optimistic: 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 instance And 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”

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