You are on page 1of 97

Model Building

Week 05
Simulation Modeling & Analysis

1
Introduction
Modeling is more than knowing how to use a
simulation software tool.
Software cannot make decisions about how the
elements of a particular system operate and
how they should interact with each other.
This is a role of the modeler.

2
Modeling is an art or craft as much as a
science.
Knowing theory behind simulation and
understanding the statistical issues are the
science part.
Knowing how to effectively and efficiently
represent a system using a simulation tool is
the artistic part of simulation.

3
Converting a Conceptual Model to
Simulation Model
The conceptual model is the result of the data-
gathering effort and is a formulation in ones
mind of how a particular system operates.
Building a simulation model requires that this
conceptual model be converted to a simulation
model.

4
Making this translation requires two important
transition in ones thinking.
The modeler must be able to think of the system in
terms of the modeling paradigm supported by the
particular modeling software that is being used.
The different possible ways to model the system
should be evaluated to determine the most efficient
yet effective way to represent the system.

5
Modeling Paradigm
A simulation model is a computer
representation of how elements in a particular
system behave and interact.
How a user defines a model using a particular
simulation product is based on the modeling
paradigm of the product.
A modeling paradigm consists of the
constructs and associated language that dictate
how the modeler should think about the
system being modeled.
6
Modeling paradigms differ among simulation
products although different are minor.
Historically, simulation products required
models to be defined line by line, specifying a
list of instructions like a script for processing
entities.
Most modern products have a process
orientation and support object-based modeling.
Some product view a process as an activity
sequence, while others view it from the
standpoint of an entity routing.
7
Model Definition
A model is simplified representation of reality.
The exact way in which an operation is performed is
not so important as the way in which the operation
impacts the rest of the system.
An activity should be viewed in terms of its effect on
other system elements rather than in terms of the
detailed way in which it is performed.
The power of a model is more a function of its
simplicity rather than its complexity.
The relationship between model complexity and
model utility is described by the Laffer curve.

8
Relationship between model complexity and
model utility (also known as the Laffer curve)
Complexity

Optimum level
of model complexity

Utility
9
Structural Elements
Model objects represent the structural element in a
system such as machines, people, work items, and
work areas.
The object classification employed ProModel
includes:
Entities the items processed in the system.
Locations places where entities are processed or held.
Resources agents used in the processing of entities.
Paths the course of travel for entities and resources in
the system.
10
Not all simulation products provide the same
set or classification of modeling elements,
These elements can be further subdivided to
provide greater differentiation.
Location, for example, could be subdivided
into: workstations, buffers, queues, and storage
areas.
These model elements or objects have
behavior associated with them and attributes.

11
Entities
Entities are the objects processed in the model that
represent the inputs and output of the system.
Entities have special characteristics: speed, size,
condition, etc.
Entities follow one or more different routings in a
system.
Entities have processes performed on them.
Entities may arrive from outside the system or be
created within the system.
Usually, entities exit the system after visiting a
defined sequence of locations.
12
Simulation models often extensive use of entity
attributes
for determining where the entity gets routed in the system
for gathering information during the course of the
simulation
The statistics of interest that are generally collected
for entities include:
time in the system (flow time)
quantity processed (output)
value-added time
time spent waiting to be serviced
the average number of entities in the system

13
Entities to Include
When deciding what entities to include in a
model, it is best to look at every kind of entity
that has a bearing on the problem being
addressed.
The rule is that if you can adequately capture
the dynamics of the system without including
the entity, dont include it.

14
Entity Aggregating
Modeling each one of entity types individually
would be a painstaking task that would yield
little, if any, benefit.
A better approach is to treat entity types in the
aggregate whatever possible.
If statistics by entity type are not required and
differences in treatment can be defined using
attributes or probabilities, it makes sense to
aggregate entity types into a single generic
entity and perhaps cal it part or customer.
15
Treating different entity types as a single type

Type A

Type B

Type X
Type C

16
Entity Resolution
Each individual item or person in the system
need not always be represented by a
corresponding model entity.
A group of items or people can be represented
by a single entity.
Activity times or statistics that are a function
of the size of the group can be handled using
an attribute that keeps track of the items
represented by the single entity.
17
Treating multiple entities as a single entity

9 entities 1 entity

18
High-Rate Entity Processing
In some system, it is common to process
entities at a rate of hundreds per minute.
In such situations, modeling each individual
entity can significantly slow down the
simulation.
If individual entity tracking isnt tracking, it
may be preferable to merely track entity
production at various stages of a process using
variables or attributes.
19
Simulation languages having a tank or
accumulator construct can make this easier.
An alternative approach is to adjust the
resolution of the entity by making a number of
entities into a single entity.
This approach also works for continuously
flowing substances such as liquids or granules,
which can often be converted, for simulation,
into discrete units of measures such as gallons,
pounds, or barrels.

20
Locations
Locations are places in the system that entities
visit for processing, waiting, or decision
making.
Locations have a holding capacity, and may
have certain times that they are available.
They may also have special input and output:
input based on highest priority or output based
on first-in, first-out (FIFO).
21
In simulation, we are interested in the average
contents of a location such as the average
number of customers in a queue or the average
number of parts in a storage rack.
We might also be interested in how much time
entities spend at a particular location for
processing.
There are also location state statistics that are
of interest such as utilization, downtime, or
idle time.

22
Location to Include
Deciding what to model as a route location
depends largely on what happens at the
location.
If an entity merely passes through a location
and route to another without spending any
time, it probably isnt necessary to include the
location.

23
In considering what to define as a location, any point
in the flow of an entity where one or more of the
following actions take place may be a candidate
Place where an entity is detained for a specified period of
time while undergoing an activity (such as fabrication,
inspection, or cleaning).
Place where an entity waits until some condition is satisfied
(like the availability of a resource or the accumulation of
multiple entities).
Place or point where some action takes places or logic gets
executed, even though no time is required (splitting or
destroying an entity, sending a signal, incrementing an
attribute or variable).
Place or point where a decision is made about further
routing (a branch in conveyor or path, an area in a store
where a customers decide to which checkout counter they
will go),
24
Location Resolution
Depending on the level of resolution needed
for the model, a location may be an entire
factory or service facility at one extreme, or
individual positions on a desk or workbench at
the other.
The combination of locations into a single
location is done differently depending on
whether the locations are parallel or serial
locations.

25
When combining parallel locations having
identical processing times, the resulting
location should have a capacity equal to the
combined capacities of the individual location;
however, the activity time should equal that of
only one of locations.
When combining serial locations, the resultant
location should have a capacity equal to the
sum of the individual capacities and an activity
time equal to the sum of the activity times.

26
Example of combining three parallel stations into
a single station
Capacity = 1

Capacity = 1 Capacity = 1 Capacity = 1

Operation 10 Capacity = 1 Operation 30

Operation 20
1 min. each

Capacity = 1 Capacity = 3 Capacity = 1

Operation 10 Operation 20 Operation 30


1 min.
27
Example of combining three serial stations into
a single station

Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1 Capacity = 1

Station 1 Station 2 Station 3 Station 4 Station 5


1 min. 1 min. 1 min.

Capacity = 1 Capacity = 3 Capacity = 1

Station 1 Station 2-4 Station 5


3 min.
28
Resources
Resources are the agent used to process
entities in the system.
Resources may be either static or dynamic
depending whether they are stationary or move
about in the system.
Dynamic resources behave much like entities
in that they both move about in the system.
Like entities, resources may be either animate
or inanimate.
29
The primary difference between entities and
resources is that entities enter the system, have a
defined processing sequence, and in most cases,
finally leave the system.
Resources often respond to requests for their use,
whereas entities are usually the objects requiring the
use of resources.
In simulation, we are interested in :
how resources are utilized
how many resources are needed
how entity processing is affected by resource availability
response time for acquiring a resource
30
Resources to Include
The decision as to whether a resource should
be included in a model depends largely on
what impact it has on the behavior of the
system.
If the resource is dedicated to a particular
workstation, it is unnecessary to include in the
model.
If the resource may not always be available or
is a shared resource, it should be included.
31
Resource Travel Time
One consideration when modeling the use of
resources is the travel time associated with
mobile resources.
A modeler must ask whether a resources is
immediately accessible when available, or if
there is some travel time involved.
The time for the resources to move to a
location may also be a function of the distance.

32
Consumable Resources
Depending on the purpose of the simulation
and degree of influence on system behavior, it
may be desirable to model consumable
resources.
Consumable resources are used up during the
simulation and may include:
Services such as electricity or compressed air
Supplies such as staples or tooling

33
Consumable resources are usually modeled
either as a function of time or as a step
function associated with some event such as
completion of an operation.
This can be done by defining a variable or
attribute that changes value with time or by
event.

34
Transport Resources
Transport resources are resources used to move
entities within the system.
These resources are dynamic and often capable of
carrying multiple entities.
Sometimes there are multiple pickup and drop-off
points to deal with.
The transporter may even have a prescribed route it
follows.
In advanced manufacturing system, the most complex
element to model is often transport or material
handling system such as conveyor systems and
automated guided vehicle system (AGVS).
35
Paths
Paths define the course of travel for entities and
resources.
Paths may be isolated or they may be connected to
other paths to create a path network.
Paths linked together to form path networks are
common in manufacturing and service system.
In manufacturing systems : aisles, AGV tracks
In service systems: hallways
In transportation systems: roadways, tracks

36
Operational Elements
Operational elements define the behavior of the
different physical elements in the system.
These include routings, operations, arrivals, entity
and resource movement, task selection rules,
resources schedules, and downtimes and repairs.
Operational elements of a model can be defined
using constructs that are specifically provided for modeling
requiring the special logic such as if-then statements to
achieve the special operating behavior

37
Routings
Routing define the sequence of flow for
entities from location to location.
When entities complete their activity at a
location, the routing defines where the entity
goes next and specifies the criterion for
selecting from among multiple possible
locations.

38
A few typical rules for selecting the next
location in a routing decision:
Probabilistic
First available
By turn
Most available capacity
Until full
Random
User condition

39
Recirculation
Sometimes entities revisit or pass through the
same location multiple times.
The best approach to modeling this situation is
to use an entity attribute to keep track of the
number of passes through the location and
determine the operation or routing accordingly.

40
Unordered Routings
Certain systems may not require a specific
sequence for visiting a set of locations but
allow activities to be performed in any order as
long as they all eventually get performed.
In unordered routing situations, it is important
to keep track which locations have or havent
been visited.
Entity attributes are usually the most practical
way of tracking this information.
41
Entity Operations
An entity operation define what happens to an entity
when it enters a location.
For modeling purposes, the exact nature of the
operation is unimportant.
What is essential is to know what happens in terms of
the time required, the resources used, and any other
logic that impacts system performance.
For operations requiring more than a time and
resource designation, detailed logic may need to be
defined using if-then statements, variable
assignments, or some other type of statement. 42
Consolidation of Entities
Entities often undergo operations where they are
consolidated or become either physically or logically
connected with other entities.
Examples of consolidation:
Batching
Stacking
Entities are allowed to simply accumulate until a
specified quantity has been gathered, and they are
grouped together into a single unit.
Entity consolidation may be temporary or permanent.
In ProModel:
COMBINE command for permanent
GROUP command for temporary
43
Consolidation of entities into a single entity

(a) Permanent consolidation

before after

(b) Temporary consolidation

before after

44
Attachment of Entities
Entities can be attached to a specific entity at a
location.
Attachment may be temporary or permanent.
In ProModel,
LOAD command for temporary attachment
JOIN command for permanent attachment
LOAD/JOIN routings must be defined for entire to
be loaded or joined.

45
Attachment of one or more entities to another entity
(a) Permanent attachment

before after

(b) Temporary attachment

before after 46
Dividing Entities
A single entity is converted into two or more new
entities.
Entities are divided in one of two ways:
the entity of split up into two or more new entities and the
original entity no longer exists.
additional entities are created (cloned) from the original
entities, and the original entity continues to exists.
In ProModel, entities are split using
SPLIT statement
CREATE statement

47
Multiple entities created from a single entity
(a)The entity splits into multiple entities
(the original entity is destroyed)

before after

(b) The entity creates one or more entities


(the original entity continues)

48
before after
Entity Arrivals
Entity arrivals define the time, quantity,
frequency, and location of entities entering the
system.
Entities may arrive in one or several ways:
Periodic
Scheduled
Fluctuating
Event triggered
Entities can arrive individually or in batches.
49
Periodic Arrivals
Periodic arrivals occur more or less at the
same interval each time.
They may occur in varying quantities, and the
interval is often defined as a random variable.
Periodic arrivals are often used to model the
output of an upstream process that feeds into
the system being simulated.
Periodic arrival are defined in ProModel by
using the arrivals table.
50
Scheduled Arrivals
Scheduled arrivals occur when entities arrive at
specified times with possibly some defined
variation (i.e., a percentage will arrive early or
late).
Scheduled arrivals may occur in quantities
greater than one.
Scheduled arrivals sometime occur at intervals.
Each arrival occurs independently of the
previous arrival.

51
Fluctuating Arrivals
Entities are arrive at a rate that fluctuates with
time.
In ProModel, fluctuating arrivals are specified
by defining an arrival cycle pattern for a time
period.

52
Event-Triggered Arrivals
Entities are introduce to the system by some
internal trigger.
In ProModel, entity arrival can be triggered
using an ORDER statement.

53
Entity and Resource Movement
Entities move through the system from location to
location for processing.
Resources move to different locations where they are
requested for use.
Resources frequently move or escort entities in the
system.
Movement can be defined in three basic ways:
Ignore the movement
Model the move using a simple move time (which may
also defined by speed and distance)
Model the move using a path network that requires the
moving entity or resource to contend the traffic. 54
A path network essentially imitates the network of
aisles or hallways found on plant floor and in office
facilities.
A path network reduces the number of paths that need
to be defined if there are a lot of different routings yet
all movement shares common path segments.
The decision as to which method to use depends on
the level of detail needed for a valid model.
The following rules may be useful:
If the move time is negligible compared to activity times,
or if it makes sense to simply include it as a part of the
operation time, it may be ignored.
If move times are significant but traffic congestion is light,
a simple move time should be defined.
If move times are significant and traffic congestion is
heavy, a path network should be defined.
55
Accessing Locations and Resources
Much of the activity in a simulation is
governed by how entities are able to access
locations and resources for processing.
Entities may be given priorities when
contending with other entities for a particular
location or resource.
The location or resource might also be given
decision-making capability for selecting from
among multiple items awaiting input.
56
Use of Priorities
In ProModel, locations and resources may be
requested with a particular priority.
Priorities range from 0 to 999 with higher
values having higher priority.
If no priority is specified, it is assumed to be 0.
For simple prioritizing, you should use
priorities from 0 to 99.
Priorities greater than 99 are for preempting
entities and downtimes currently in control of
a location or resource.
57
Preemption
Sometimes, it is desirable to have a resource or
location respond immediately to a task,
interrupting the current activity it is doing.
This ability to bump another activity or entity
that is using a location or resource is referred
to as preemption.
Preemption is achieved by specifying a
preemptive priority (100 to 999) for entering
the location or acquiring the resource.
58
Task Selection Rule
Locations and resources are often
discriminating with respect to which waiting
entity or activity they next select to service.
Task selection rules determine which entities
waiting for a location or resource is actually
granted permission to use the location or
resource when it becomes available.

59
Task selecting plays a crucial role in
simulation-based scheduling.
Rules ranges from simple priority rules such as
shortest processing time, critical ratio, or
earliest due date to combinatorial rules and
user-defined decision logic.
User-defined decision logic provides the most
flexible means for defining task selection.
By default locations and resources in
ProModel respond to highest-priority request
that has been waiting the longest.
60
Resource Scheduling
Resources frequently have scheduled times during
which they are unavailable including off-shift
periods, breaks, and preventive maintenance.
Some of issues that need to be addressed include:
Deciding what to do with a task that is only half completed
when the end of a shift occurs.
Making sure that resource statistics are based only on
scheduled available time and not on the entire simulation
run.
Deciding what to do with arrivals that occur at a location
that is off shift.

61
Going off Schedule in the Middle of a Task
It is common when running a simulation with work
schedules to have a resource go off schedule in the
middle of a task.
For longer tasks that may take hours, it usually isnt
desirable to keep the resource until the task is
completed.
There are at least three options:
Dont start the task in the first place.
Interrupt the task and go off schedule.
If the task is nearly complete, go ahead and finish the task.

62
Basing Resource Statistics on Scheduled Time
It is desirable to gather statistics on the
resource such as utilization statistics, based on
the scheduled time available, not on total
simulation time.
ProModel automatically excludes off-
scheduled time when calculating statistics.

63
Handling Activities during Off-Shift Times
It is usually desirable to prevent arrivals from
occurrence during off-schedule times.
To turn off arrivals during off-shift times, the possible
solutions include:
to try synchronize the arrivals with the work schedule.
to have the arrivals enter a preliminary location where they
test whether the facility is closed and, if so, exit the system.
In ProModel, if a location where entities are
scheduled to arrive in unavailable at the time of an
arrival, the arriving are simply discarded.

64
Downtimes and Repairs
It is common for resources and locations to
unexpectedly go down or become unavailable
for one reason or another such as a mechanical
failure or a personal interruption.
Downtimes usually occur periodically as a
function of total elapsed time, time in use, or
number of times used.

65
Downtimes Based on Total Elapsed Time
Examples of a periodic downtime based on
elapsed clock time might be:
a worker who takes a break every two hours.
scheduled maintenance
The calculation of the interval between
downtimes takes into account not only busy
time, but also idle time and downtime.

66
Sometimes it may be desirable to use elapsed time to
define random equipment failures that is especially
true if this is how historical data were gathered on the
downtime.
When using historical data it is important to
determine if the time between failure was based on:
the total elapsed time from one failure to the next.
the time between the repair of one failure to the time of the
next failure (operational time between failures).
the time that the machine was actually in operation
(operating time between failures).

67
Resource downtime occurring every 20 minutes
based on total elapsed time

Start Interrupt Interrupt

6 10 4 6 14

Idle Busy Idle Down Busy


Time (minutes)

68
Downtimes Based on Time in Use
Most equipment and machine failures occur only
when the resource is in use.
A mechanical or tool failure, for example, generally
happens only when a machine is running, not while a
machine is idle.
The interval between downtimes would be defined
relative to actual machine operation time.
Any idle times and downtimes are not included in
determining when the next downtime occurs.
Because downtimes usually occur randomly, the time
to failure is most accurately defined as a probability
distribution.
69
Resource downtime occurring every 20 minutes
based on operating time

Start Interrupt
12 8

Idle Busy Idle Busy



Idle

Time (minutes)

70
Downtimes Based on the Number of Time Used
Downtimes occur based on the number of
times a location was used.

71
Downtimes Resolution
Data are rarely available on equipment downtime.
Data are often recorded overall downtime and seldom
broken down into number of times down and time
between failures.
Depending on nature of the downtime information
and degree of resolution required, downtimes can be
treated as follows:
Ignore the downtime.
Simply increase processing time to adjust for downtime.
Use average values for mean time between failures
(MTBF) and mean time to repair (MTTR).
Use statistical distributions for time between failures and
time to repair.
72
Ignoring Downtime
Several situations where it might make sense
to ignore downtimes:
No data are available on downtimes.
The downtimes are extremely infrequent and not
likely affect model performance for the period of
the study.
The occasional downtimes are very small
compared to activity times.

73
Increasing Processing Times
A common way of treating downtime is to
simply reduce the productive capacity of the
machine by the downtime percentage.
This spreads the downtime across each
machine cycle so that both the mean time
between failures and the mean time to repair
are very small and both are constant.
No consideration is given for the variability in
both time between failures and time to repair.
74
MTBF/MTTR
Two parts to any downtime should be defined:
Time between failure, defines the interval between
failure.
Time to repair, defines the time required to bring a
resource back online.
Downtimes are defined in terms of:
mean time between failure (MTBF).
mean time to repair (MTTR).
Using average times, it fails to account
variability.
75
Using Statistical Distribution
Time between failures and time to repair is
represented by statistical distributions that
reflect the variation that is characteristic of
these elements.
Studies have shown that:
the time until failure tends to follow a Weibull
distribution.
repair times often follow a lognormal distribution.

76
Elapsed Time or Usage Time?
When determining the distribution for time to failure,
a distinction should be made between
downtime events that can occur anytime whether the
resource is operating or idle
downtime events that occur only when a resource is in use
Downtimes that can occur anytime should be defined
as a function of clock time.
If the resource goes down only while in operation, it
should be defined as a function of time in use.

77
Handling Interrupted Entities
When a resource goes down, there might be entities that were
in the middle of being processed that are now left dangling
(i.e., they have been preempted).
Several alternatives may be chosen by modeler to decide what
to do with these entities:
Resume processing the entity after downtime is over.
Find another available resource to continue the process.
Scrap the entity.
Delay start of the downtime until the entity is processed.
The last option is the easiest way to handle downtimes and
may be adequate in situations where either the processing
times or downtimes are relatively short.
If the entity resumes processing later using either the same or
another resource, a decision must be made as to whether only
the remaining process time is used or if additional time must
be added.
By default, ProModel suspends processing until the location or
78
resource returns to operation.
Use of Programming Logic
Sometimes the desired model behavior cant
be achieved using a canned construct
provided by the software.
It is necessary to use programming logic that
tests probabilities, variables, and attributes to
make behavioral decisions.

79
Using Probabilities to Model Probabilistic
Behavior
Sometimes operational elements (routings,
operations, or others) exhibit random behavior.
To model a routing that occurs randomly, it is
easy just to select a probability routing rule
and specify the probability value.

80
For operation that occur randomly at a
particular location, however, a probability
function must be used in connection with if-
then logic.

81
At an inspection and rework station, for example,
suppose that a product is defective 10 percent of the
time and requires 3 1 minutes (uniformly
distributed) to correct the defect; then the code for
defining this behavior might be as follows:

if rand () <= .10


then wait U(3, 1) min

rand() is a function that return a random value


between 0 and 1.

82
When a machine goes down, 30 percent of the
time it takes Triangular(0.2, 1.5, 3) minutes to
repair, and 70 percent of the time it takes
Triangular(3, 7.5, 15) minutes, the logic for the
downtime definition might be:

if rand () <= .30


then wait T(0.2, 1.5, 3) min
else wait T(3, 7.5, 15) min

83
Another example is a multidistribution activity
(called as a call center) that handles three
different types of calls that it is designated as
A, B, and C. The time to handle calls is
exponentially distributed, but the mean time is
different depending on type of call.

84
The code might be

// set a real variable (rValue) to random number


real rValue = rand()
// test for call type
if rValue <= 0.20
then wait E(5) min
else if rValue <=0.70
then wait E(8) min
else wait E(12) min

The // is used to make a comment line


85
Using Attributes to Model Special Decision
Logic
Sometimes an item that has passed through the
same location a second time requires less time
to be reworked than it took for the initial
operation.
An attribute of the entity should be the basis of
the decision because it is needed to test how
many times that particular entity has visited
the location.

86
If a normal operation takes five minutes but a
rework operation takes only two minutes, the
following code would be entered in the
operation logic for the location:

// increment the value of Pass by one


INC Pass
if Pass = 1
then wait 5 min
else wait 2 min
87
Using Global Variables to Gather Statistics
Global variables are placeholders for values that may
change during the simulation.
They are accessible from any place in the model by
any object in the model.
They exist during the entire simulation.
Global variables are defined by the user for user-
defined purposes.
For example, a variable may be defined to keep track
of the total number of entities in a certain area of the
system (work in process) that is increased when the
entity enters the area and decreased when the entity
leaves.
Statistics of the global variables can be either the
simple or time-weighted average value.
A time series report showing all of the changes in the 88
variable over time can also be reported.
Using Local Variable for Looping
Local variable are variables that are declared within
the logic itself, either right before the point of use or
at the beginning of the logic block.
A local variable exists only for the current object
executing the block of logic.
A local variable can be thought of as a temporary
attribute of the object executing the logic.
Local variables are useful primarily for executing a
logic loop.

89
Suppose, for example, that you want to assign the
value of 4 to the first 10 elements of an array called
NumOfBins that was defined in the Array module. To
do this within operation logic (or in any other logic),
you would enter something like the following, where
Count is defined as a local variable:

int Count = 1
while Count < 11 do
{
NumOfBins[Count] = 4
inc Count
}

The braces { and } are the ProModel notation for


starting and ending a block of logic (begin and end). 90
Miscellaneous Modeling Issues
This section addresses special issues that may
be encountered in simulation.
Modeling rare occurrence
Large-scale modeling
Cost modeling

91
Modeling Rare Occurrences
Often there exist situations in the real world that
occur only rarely.
In simulation analysis, we are generally interested in
the normal behavior of the system, not extremely rare
behavior.
It is advisable to ignore rare situations and exclude
them from the simulation model.
This approach not only reduces modeling time but
also simplifies the model and helps maintain the
focus of everyone involved in the model on the key
input variables.
92
But some rare situations have a significant
impact on the operation of the system.
If the focus of interest is to evaluate the effects
of the rare occurrence, then it makes sense to
include the rare occurrence in the model.
The easiest way to model a rare event is to
continuously run until the event occurs.

93
Large-Scale Modeling
It may be desirable to model a large system
such as an entire factory or the entire activity
in an international airport.
It is always a good idea to partition the model
into several submodels and tackle the problem
on a smaller scale first.
Each submodels can be merged into a larger
composite model either as a single monolithic
model or a hierarchical model.
94
Three of the most common ways for
integrating submodels are:
Integrate all of the submodels just as they have
been built.
Use only the recorded output from one or more of
the submodels.
Represent the output of one or more of the
submodels as statistical distributions.

95
Cost Modeling
It is desirable to include cost in a model to
determine the most cost-effective solution to a
design problem.
Two approaches to modeling cost are:
to include cost factors in the model itself and
dynamically update cost collection variables
during the simulation
to run a cost analysis after the simulation, applying
cost factors to collected cost drivers such as
resource utilization or time spent in storage.
96
The first method is best when it is difficult to
summarize cost drivers.
The preferred way to analyze cost is to do a
postsimulation analysis and to treat cost
modeling as a follow-on activity to system
modeling rather than as a concurrent activity.

97

You might also like