If you’ve attended my training class before, worked on a project with me, or even sat in on a sales call in which I provided engineering support, I’m sure you’ve heard me stress the importance of building a functional specification.  This functional specification will be the road map for the project.

One of the issues we address during the development of the functional specification is the type of system we are to model. Is it terminating or steady state? And if it is a steady state system, we must decide not only the scope of the system to be modeled but how will we determine when the model will reach steady state in order to mimic the system.

With a steady-state system, there are no defined starting and ending points for the system. We are interested in the steady-state behavior, if such exists.

One of the first issues to be considered is the start-up bias. If the model starts empty and idle but the system does not, then the statistics for the overall model run will be biased by the start-up or warm-up period for the model. The warm-up period is the time necessary for the model to reach steady state and, therefore, mimic the actual system.

Arena allows the modeler to input a warm-up period in Run > Setup under Replication parameters. Of course, the question then becomes, how long should the warm-up period be?

There are a couple of ways to determine the length of the warm-up period.

1. The system designers or experts should have some idea of how long it would take to reach steady state if they started their system empty and idle. This would be a good starting point for determining the length.
2. Make some plots of key performance measures and eyeball when they appear to stabilize.

A combination of these two methods would be the best approach. Once the warm-up period has been determined, then we can begin the analysis of the steady-state system.

The following two methods can be used to look at steady-state systems:

The first method is called truncated replications. First is the question of how many replications are required to achieve a given confidence half width. In order to determine this, a pilot study or experiment can be performed using a small number of replications to achieve some half width. Five is a good number to use initially, but this is merely a recommendation. Once that pilot study has been performed, the user can use the number of runs and the half width from that study and the desired half width in order to determine the number of replications estimated to achieve that desired half width. The following formula will approximate that number of replications:

Another concern may be the execution or run time of a replication. Just because the formula said we needed 100 runs, it may not be practical to make 100 replications. In this case, the user may have to be satisfied with a larger half width. With today’s high-speed computers, this is usually not an issue, but the modeler should still be aware of this potential concern. And each replication will have the given warm-up period.

The second method is to run the model for a long period of time. This may be a better technique if the warm-up period is “long” so that you only pay the warm-up price once. In this case, Arena uses a technique in which batches are determined and used as the replications. The confidence interval for our performance measure of interest is generated from “batch averages” calculated from a single, long run. Note that if the run is not long enough, you will first get a half width that is insufficient or correlated. Once the model length is sufficiently long, the half width will be calculated.

Fun Fact: The batched means method of generating confidence intervals was critical when computing time was expensive because the user did not want to incur the cost of a warm-up period for each replication. The speed of today’s computers makes it computationally inexpensive to perform steady-state analysis via the truncated replications method.