The concept of lookahead in HLA is not explained much in HLA documentation. Here are some quotes that give a bit more info on it:
From HLA TIME MANAGEMENT AND DIS by Fujimoto himself:
The timestamp order service requires specification of a quantity called lookahead. To motivate the need for lookahead, consider a federation where timestamp order is specified for all communications. Consider the federate with the smallest logical time at some instant in the execution. Let this federate have a logical time of T. This federate could generate events relevant to every other participant in the federation with a timestamp of T. This implies the RTI cannot deliver any message with timestamp larger than T to any federate. In turn, this implies no federate can advance its logical clock beyond T because it is then prone to receiving an event in its past. This is a well-known problem that has been widely studied in the PDES community. The two principal approaches to circumventing it are:
- use the notion of lookahead, described below, to define conservative protocols that prevent out-of-order delivery of messages, or
- * use optimistic synchronization techniques that allow messages to be delivered out of timestamp order, and use a rollback mechanism within the federate to recover from errors introduced from out-of-order delivery.
HLA-TM supports both of these approaches. Optimistic synchronization is beyond the scope of this paper, but is described elsewhere [Fuji96]. Lookahead is elaborated upon next.
If one were to mandate that no simulation may schedule an event with timestamp less than the federate’s current time plus a value L, then the RTI can allow concurrent delivery and processing of messages in a time window L time units wide beginning at the minimum logical time of any simulation in the federation. This value L is referred to as the lookahead for the simulation because a federate must be able to “look ahead” L time units into the future, or in other words, predict attribute updates and interactions at least L time units “ahead of time”. Lookahead may, in general, be difficult to incorporate into certain classes of simulations, but nevertheless is very important for simulations requiring guaranteed message ordering services to achieve acceptable performance.
Lookahead is clearly very intimately related to details of the simulation model, and thus cannot be determined automatically by the RTI. Some examples of where lookahead may be derived are described below.
- Physical limitations concerning how quickly one federate can react to an external event. Suppose the minimum amount of time for a tank to respond to an operator’s command (e.g., to fire an ordnance) is 500 milliseconds. This means the simulation can guarantee that it will not schedule the results of any new operator actions until at least 500 milliseconds into the future, providing a lookahead of this amount.
- Physical limitations concerning how quickly one simulation can affect a second simulation. Suppose two tanks are ten miles apart, and there is also a maximum speed of a projectile fired from one tank to another. These constraints place a lower bound on how much time must elapse for the first tank to affect the second. Thus, events such as a projectile exploding at the second tank can be scheduled into the future, providing some degree of lookahead.
- Tolerance to temporal inaccuracies. Suppose a simulation produces an event at time T, but the receiver of the message for that event cannot distinguish between the event occurring at time T and T+100 milliseconds (e.g., in a training simulation, it might be the case that a muzzle flash occurring at time T is indistinguishable from one at time T+100 milliseconds). Then, the simulation may schedule events 100 milliseconds into the future, providing a lookahead of this amount.
- Time stepped simulations: In a time stepped simulation, the lookahead is normally the size of the time step. This is because a simulation can only schedule events into the next time step (or later), but not into the current time step.
- Non-preemptive behavior. Suppose a tank is moving north at 30 miles per hour, and nothing in the federation model could cause it to change any events produced by the tank over the next ten minutes. These events could therefore be scheduled immediately, resulting in a lookahead of 10 minutes.
- Precomputing simulation activities. If the events produced by a simulation over the next L units of time do not depend on external events, but only depend on internal computations, these computations can be performed in advance, enhancing lookahead. For example, if the time until the next interaction of a simulation with another simulation is drawn from a random number generator, the generator can be sampled ahead of time, and the computed value can be used to derive the simulation’s lookahead for this time instant.
Lookahead can change dynamically during the simulation. However, lookahead cannot instantaneously be reduced. At any instant, a lookahead of L indicates to the RTI that the federate will not generate any event (using timestamp ordering) with timestamp less than C+L, where C is the federate’s current time. If the lookahead is reduced by K units of time, the federate must advance K units before this changed lookahead can take effect, so no events with timestamp less than C+L are produced.
The RTI requires each simulation to specify lookahead information if any events utilizing the guaranteed event ordering service are generated. Care must be taken in developing the federate to maximize lookahead, as this can significantly affect performance.
From TIME MANAGEMENT IN DISTRIBUTED FACTORY SIMULATION, A CASE STUDY USING HLA:
In operation, federates interact through messages. A message from one federate to another may represent an event originating with the first federate but affecting the second. Thus, when the second federate receives the message, it can “experience” the corresponding event by placing it in its local event queue. Synchronization requires that the second federate’s local time should not be greater than the time stamp of the arriving message, otherwise the second federate experiences an event “now” that occurred in its “past” (McGinnis et al. 2005). HLA TSO service is designed to facilitate the message interactions between federates. It ensures that messages will be delivered to federates in time stamp order, and no TSO message contains a time stamp less than the federate’s current time will be delivered to it.
The TSO service requires specification of lookahead, where lookahead is defined as the minimum distance into the future that a TSO event will be scheduled (Fujimoto 2000). Lookahead is a guarantee from the federate that it will not generate any messages with a time stamp smaller than its current time plus the value of lookahead. Thus lookahead can be used to define a lower bound on the time stamp (LBTS) of messages produced by a federate later during the execution. By computing a minimum of this lower bound across all federates that can send messages to a given federate, call it federate S, one can derive a lower bound on the time stamp of messages that will be delivered to S in the future. This lower bound is important because it means S can process messages with time stamp smaller than this lower bound without fear of later receiving a smaller time stamped message (Fujimoto 1997).
The lookahead of a federate is bounded by the federate’s quickest response time to TSO messages it subscribes. If, for example, the federate should respond to messages from other federates instantly, it can only guarantee a zero lookahead. Lookahead value has great implication for simulation run time. If lookahead value is large, federates potentially can achieve a high degree of parallelism in processing events. However, if lookahead value is small, there will be a high level of synchronization overhead and little parallelism.
and
In this design, since the factory federate is mainly in charge of the behaviors at the tools, and the smallest processing time of a lot on the tools is more than 8.1 minutes, the lookahead value of the factory federate can be as large as 8.1 minutes. For the material handling federate, the lookahead value depends on how fast the fab can send the material to its destination, which in most cases is the summation of transportation time and load/unload time at the stockers. Detailed calculations show that lookahead value of the material handling federate can be up to 52 seconds in our case (Wang 2004).
From Cookbook to Adapting Simulations for the High Level Architecture by Murray Gamble for DND/SECO:
If you are using Time Management services, you will need to be extremely careful with the configuration that you have selected and the options that you have set. Specifically, the selection and use of “lookahead” will have significant implications on the performance of your federate. Using a larger “lookahead” value means that messages you send to other federates will be delivered to those federates much later than they will be processed locally.
From MPADES: Middleware for Parallel Agent Discrete Event Simulation:
The sensation and action latencies provide a lookahead value for that agents and allows the agents to think in parallel. When a sense event is realized for agent 1, it cannot cause any event to be enqueued before the current time plus the minimum action latency. Therefore it is safe (at least when only considering agent 1) to realize all events up till that time without violating event ordering.
So it looks like a possible interpretation of lookahead is a “time period during which the simulation (by federate) could not generate new events”. This would happen, e.g., during the computation period. E.g. if it takes a federate 1 ms to evolve itself by 10 ms, then the lookahead could be 1 ms.
The quotations indicate that the larger the lookahead, the more things can happen in parallel. This is because if the lookahead is large, so a federate says that during that large time slice ahead of its current time, it will not generate new events. This doesn’t mean that the federate can’t evolve during that time: it may do so and modify itself significantly; it just means that it won’t broadcast any updates during that time. This allows other federates to progress without regard for input from that federate.
HOWEVER, this also assumes that this federate discards any events that would come from other federates in that time span. This would be true in “steady state” since the RTI guarantees it will not deliver messages with a TSO (time stamped order) less than a federates current time plus lookahead. This in turn indicates that the federate will have been granted a move to its current time only when its LBTS was more than its current time plus its lookahead, which should itself delay things. So it is still not clear that increasing the lookahead is pure gain.
From the many PDF articles found by Google, with brief discussions related to lookahead, it is clear that good values for lookahead are in general difficult to compute yet can have significant impact on performance. Some articles mentione dynamic optimization of the value during runtime.
