## Multi-Step Activities in EZStrobe — Part 2

### Non-Identical Multi-Step Activities

Certain repetitive activities, such as loading a flatbed truck with five prefabricated beams using a crane, are examples of multi-step activities that consist of *n* steps. A discussion of how to model multi-step activities when they have identically-distributed and consecutive steps appears in Multi-Step Activities in EZStrobe - 1, Identical and Consecutive Steps.

Occasionally, however, it may be necessary to model such multi-step activities at the 'step' level, i.e., as a series of several shorter activities. Described below is how to model this situation when

- The durations of the various steps are
*not**Independent and Identically Distributed*(IID), or - The number of steps required is
*variable*, or - The multi-step activity can be
*interrupted*between steps.

[When none of these conditions exist, a multi-step activity can can be modeled much more simply and efficiently as described in Multi-Step Activities in EZStrobe - 1, Identical and Consecutive Steps.]

### Modeling a Multi-step Activity at the Step Level

The best way to model a multi-step activity at the step level is to use just *one* Activity node which will represent the *'generic step*' for the multi-step activity. Multiple successive *instances* of this Activity would then represent each of the several required steps to perform the work.

The EZStrobe network below (click it to see in detail) includes two such multi-step activities: One for loading one beam to a flatbed truck at the fabrication site (*LoadBm*) and another for unloading one beam at the job site (*UnloadBm*). Each of *LoadBm* and *UnloadBm* represents one generic step.

Trucks do not circulate explicitly in this network. What circulates instead is the space required for (or occupied by) each beam in the truck. The *LoadBm* activity moves '*one unoccupied space waiting to load*' (from the *BmSpotsWtLd* queue) to '*one occupied space waiting to be transported*' (in the *BmSpotsLdd* queue). The link entering activity *Transport* requires five occupied spaces (i.e., one fully-loaded truck) to allow transportation to the jobsite. Similarly, the link entering activity *Return* requires five unoccupied spaces (i.e., one fully-unloaded truck) to return to the fabrication site.

The time to load one beam (*LoadTm*) and the time to unload one beam (*UnloadTm*) can be specified easily using EZStrobe **Results** that sample from the appropriate distributions, for example *Uniform[1,2]* (minutes).

As described up to now, the network above represents the exact same operation as the network in Multi-Step Activities in EZStrobe - 1, Identical and Consecutive Steps. Running simulations for both networks will produce the exact same *total simulation time*, the same system production in *transported beams per hour*, and the same utilization for the cranes that load and unload.

However, since this network does not explicitly represent trucks as single units, it is not capable of providing statistics related to the waiting time and utilization of trucks. To see the difference between 'queues containing trucks' and 'queues containing beam space in trucks', it is expedient to plot their contents as a function of time.

The plot below shows the contents of *TrucksWtLd* (the queue of trucks waiting to load) over the first 120 minutes when trucks are modeled as individual units:

In contrast, the plot below shows the contents of *BmSpotsWtLd* (the queue of beam space waiting to be occupied) for the exact same 120 minutes when 'truck space' is modeled instead:

The relationship between the two time-plots is easier to appreciate in the combined chart below:

As shown in the combined plot above, '4 or less beam spots' mean '0 trucks', '5 to 9 beam spots' mean '1 truck', '10 to 14 trucks' mean '2 trucks', and so on. Clearly, the number of trucks equals the integer part of 'the number of spots divided by 5', i.e., *Trucks==Int[Spots/5]*.

### Queue Integral Statistics

In most cases, statistics at the Truck level are much more useful than those at the Beam Spot level. To provide meaningful statistics in such situations, EZStrobe supports *Integral Statistics*, which allow the collection of queue statistics in terms of a *larger unit* than that modeled by the queue. The definition of *Integral Statistics* for a queue requires (a) that the statistics be given a 'name' and (b) the definition of the number of 'modeled units' in each 'larger unit' (this number is called the *Divisor*).

For the above model, *Integral Statistics* are defined for the *BmSpotsWtLd* and *BmsToUnl* queues. The names chosen for these statistics are *TrksWtLd* and *TrksWtUnl*, respectively. The Divisor for both *Integral Statistics* is the number *5*. The screen shot below shows how to define *Integral Statistics* for the *BmSpotsWtLd* queue:

The statistical results collected by *Integral Statistics* (from the perspective of 'the larger units'), appear separately in the EZStrobe simulation report under the section *Time Weighted Collectors*. For the above network model for example we have:

TmWgtCollector TtlTime CurVal Mean SD Min Max

=================================================

TrksWtLd 1718.68 3.00 0.07 0.29 0.00 3.00

TrksWtUnl 1718.68 0.00 0.04 0.19 0.00 1.00

The reported statistics include the following:

- Total Time: matches simulation time; can be accessed in formulas using the name of the
*Integral Stat*followed by .*TtlWgt*(e.g.,*TrksWtLd.TtlWgt*). - Current Content: the current content of the queue in terms of the larger unit; can be accessed in formulas using the name of the
*Integral Stat*(e.g.,*TrksWtLd*). - Average, Standard Deviation, Minimum, and Maximum Content: all in terms of the larger unit; can be accessed in formulas using the name of the
*Integral Stat*followed by:*.AveVal*,*.SDVal*,*.MinVal*and*.MaxVal*(e.g.,*TrksWtLd.AveVal*).

The EZStrobe report also includes a separate table that lists the average waiting time for each queue from the perspective of the larger unit. For example:

Integral Stat Ave. Wait

==========================

TrksWtLd 0.59

TrksWtUnl 0.34

Starting with EZStrobe version 3.9, the average waiting time for each queue can be accessed in formulas using the name of the *Integral Stat* followed by *_AveWait* (e.g., *TrksWtLd_AveWait*). Note that an underscore (rather than a period) separates the name of the *Integral Stat* and *AveWait*. In versions of EZStrobe prior to 3.9 there is no way to access this value directly in a formula. However, it can be calculated easily using other available values. For example, the average waiting time for trucks to unload can be calculated using the following formula:

*'TrksWtLd.AveVal * TrksWtLd.TtlWgt / (BmSpotsWtLd.TotCount / 5)*'

With the addition of *Integral Stats*, the EZStrobe model described above produces the same *type* of results and statistics as the EZStrobe model described in Multi-Step Activities in EZStrobe - 1, Identical and Consecutive Steps. Moreover, because the two models use the same seed and streams, the corresponding results and statistics have identical values.

The model for non-identical or non-consecutive steps, described above, can be obtained here. It has a seed and uses multiple random number streams so that it yields the exact same output as the simpler model (see EZStrobe Model Options for information on seed and streams).

### Non-Identical and Non-Consecutive Steps

The above model can also support multi-step activities when the durations of the various steps are not IID, or when the steps can be interrupted. However, the actual model presented does not have either characteristic. This was done deliberately, so that this model would produce the exact same results as the model used to illustrate identical and consecutive steps.

[In fact, the model presented here should never be used when the steps are identical and continuous since the alternative model is simpler, cleaner, and more than twice as fast in execution.]

### Non-IID cases

**Non-IID cases** can be represented by setting the duration of each step with a non-IID formula. As an example, consider an activity that exhibits learning effects. For such an activity, the duration of each step could be a function of 1) the number of times it has taken place, 2) the number of steps that have already taken place, or 3) any other situation that dynamically changes the parameters used to determine the duration of a step.

A model with **Non-Consecutive steps** can simply include other higher-priority activities that may utilize one of the resources needed for a step. For example, a crane may be needed for a high-priority lift that will temporarily halt the loading of beams unto a flatbed until that high-priority lift is complete.

The case of **'variable number of steps'** can be modeled by appropriately replacing the '>=5,5' in the link that precedes the Transport activity, with formulas that return the appropriate number of steps required to make a whole in the current situation.

*Stroboscope, EZStrobe, ProbSched, Vitascope and Vitascope++ are based upon work supported by the National Science Foundation under Grants No. 9733267, No. 0113890, and No. 0732560. Any opinions, findings, and conclusions or recommendations are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.*