## Multi-Step Activities in EZStrobe - 2

Non-Identical or Non-Consecutive Steps

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** 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.