TERMINATING AND STEADY-STATE SIMULATION MODELS

9.1 TERMINATING AND STEADY-STATE SIMULATION MODELS

Simulation models can be classified into two main classes based on their time horizon: terminating models and steady-state models. Each class gives rise to different statistical issues relating to their output analysis.

9.1.1 T ERMINATING S IMULATION M ODELS

A terminating simulation model has a natural termination time for its replications that is inherent in the system. In such models, the modeler is interested in short-term system dynamics and statistics within the system's natural time horizon. An example of

a terminating model is a bank that opens daily at 8:00 A . M . and closes at 4:00 P . M . Here, the modeler might be interested in short-term performance measures, such as the daily maximal waiting time, or the daily maximal number of customers waiting to be served.

Since each business day starts afresh at 8:00 A . M . with a new customer arrival stream, successive days cannot be juxtaposed to form a longer replication, say, of 1 week. It simply does not make sense to extend the replication beyond the natural termination time (in this case, beyond 4:00 P . M .).

In terminating simulation models, the number of replications is the critical parameter of the associated output analysis, since it is the only means of controlling the sample size of any given estimator. Recall that the sample size affects directly the estimator's variance, and consequently, its statistical accuracy (see Section 3.10).

9.1.2 S TEADY -S TATE S IMULATION M ODELS

A steady-state simulation model has no natural termination time for its replications, and could be potentially run “forever.” In such models, the modeler is interested in long-

term dynamics and statistics. An example of a steady-state model is an ATM (automatic teller machine) that remains open 24 hours a day, and is subject to failures. Here, the modeler might be interested in long-term (steady-state) performance metrics such as the long-term fraction of time (probability) the machine is up, or the mean economic loss incurred per day by foregoing ATM fees when the ATM is down.

In this book, we are more interested in steady-state simulation models than in terminating ones. For further information, see Law and Kelton (2000), Nelson (1992), Banks et al. (2004), and Kleijnen (1987).

Note that the initial state of a system tends to exert a bias on replication statistics, at least for a while. As an example, consider again an ATM at a busy airport, which almost always has a line of customers, day or night. Clearly, an empty waiting line is not a “typical” state in the sense that its long-term probability (fraction of time the line is

Output Analysis 167 empty) is quite small. Thus, if started with an empty waiting line, the simulated queue

statistics will be uncharacteristically low for a while, but will eventually tend to their long-term values. In simulation parlance, the simulated initial “atypical” history is

called transient state, as opposed to the simulated “typical” history that evolves later, which is called steady state. The reader is cautioned that this terminology is technically

a misnomer, and should be regarded as merely suggestive. In fact, the state of almost all systems is highly dynamic, and over time a stochastic system evolves and changes continually. What is actually meant is that state statistics, computed over progressively longer time periods, exhibit transient-state behavior or steady-state behavior, respect- ively. More precisely, the transient-state regime is characterized by statistics that vary as

a function of time, while the steady-state regime prevails when statistics stabilize and do not vary over time. In between these two regimes, there is typically a transition period when the system approaches the steady-state regime—a period characterized by small and generally decreasing variability of the statistics over time. For all practical purposes, the system may be considered to be approximately in steady state during that transition period, whereas true steady state is attained, with few exceptions, only asymptotically, as time tends to infinity. Steady-state simulations seek, however, to estimate such long- term steady-state statistics.

In steady-state simulation, only long-term statistics are of interest, but initial system conditions tend to bias its long-term statistics. Therefore, it makes sense to start statistics collection after an initial period of system warm-up, namely, after the biasing effect of the initial conditions decays to insignificance. In fact, if statistics are collected during warm-up, they should be discarded after warm-up, and their collection restarted at that point. In Arena, the warm-up period can be declared in the Replication Parameters tab of the Setup. . . option of the Run menu. Alternatively, if we do not wish to suspend initial statistics collection, then each replication length should be increased to reduce the biasing effect of initial conditions. This approach, while feasible, is not attractive, as it incurs an additional (and unnecessary) computational cost.

As an example, consider a workstation where jobs arrive with exponential inter- arrival times of mean 1 hour, and a fixed unit processing time of 0.75 hours. Figure 9.1 depicts the throughput of the workstation and the average job delay in the buffer as functions of time.

Note the high variability exhibited by both statistics in the time interval from 0 to 330 hours, followed by markedly more stable statistics thereafter. The system thus appears to be distinctly in transient state up until time t ¼ 330 or so, and to approach steady state

0.4 Average Time in Buffer

Time Figure 9.1 Workstation throughput and average job delay as functions of time.

168 Output Analysis thereafter. Indeed, the throughput tends to the arrival rate when computed over longer

and longer time intervals. The transient behavior of the average job delay seems to be in effect longer than that of the throughput. It is, therefore, advisable to run the system without statistics collection until perhaps time t ¼ 400, and to start collecting steady- state statistics thereafter.

Steady-state models have a number of important issues associated with their output analysis.

Since steady-state models have no natural termination time, how does one select a replication length? Since a warm-up period is advantageous, how does one select warm-up length?

The guiding principle of replication length is stabilization of the statistics of interest. In practice, one selects a convenient time increment, and records the statistics collected from the initial time until the end of each increment (note that the corresponding collection intervals are progressively longer). The replication is stopped when statistics at the end of several successive increments are sufficiently close (e.g., within a specific e, to be determined by the analyst). Another approach is to evaluate the two sides of a known relation (e.g., Little's formula, Eq. 8.8, applied to a queueing subsystem). The replication would be terminated when both sides of the relation yield sufficiently close values.

In a similar vein, the length of a warm-up period is determined by observing experimentally when the time variability of the statistics of interest is largely eliminated. However, unlike replication length, there is no point in waiting until the statistics are perfectly stabilized (in that case, the system is already in steady state). Note that warm- up is employed just to shorten the time it takes the statistics to stabilize. In practice,

a statistics plot over time, such as Figure 9.1, can be extremely helpful in determining the length of warm-up, simply by inspection. It should also be mentioned that this issue can be rendered moot by just increasing the overall replication length and foregoing warm-up altogether.

Generally, a replication can be terminated by time, number of observations, or triggered by a logical condition. In Arena, terminating a replication at a prescribed time is achieved by specifying a value for the Replication Length field in the Replication Parameters tab of the Setup. . . option of the Run menu. The Terminating Condition field on the same tab can also be used to terminate replications, typically utilizing event counts, such as a prescribed number of departures or failures. For instance, Arena might terminate a replication as soon as the value of the current counter in a Record module exceeds a prescribed value specified in the aforementioned Terminating Condition field.