Harrell−Ghosh−Bowden: I. Study Chapters 7.

Model Building © The McGraw−Hill

Simulation Using Companies, 2004
ProModel, Second Edition

C H A P T E R

7 MODEL BUILDING

“Every theory [model] should be stated [built] as simply as possible, but not
simpler.”
—Albert Einstein

7.1 Introduction
In this chapter we look at how to translate a conceptual model of a system into a
simulation model. The focus is on elements common to both manufacturing and
service systems such as entity flow and resource allocation. Modeling issues
more specific to either manufacturing or service systems will be covered in later
chapters.
Modeling is more than knowing how to use a simulation software tool.
Learning to use modern, easy-to-use software is one of the least difficult aspects
of modeling. Indeed, current simulation software makes poor and inaccurate mod-
els easier to create than ever before. Unfortunately, software cannot make deci-
sions about how the elements of a particular system operate and how they should
interact with each other. This is the role of the modeler.
Modeling is considered an art or craft as much as a science. Knowing the
theory behind simulation and understanding the statistical issues are the science
part. But knowing how to effectively and efficiently represent a system using a
simulation tool is the artistic part of simulation. It takes a special knack to be able
to look at a system in the abstract and then creatively construct a representative
logical model using a simulation tool. If three different people were to model the
same system, chances are three different modeling approaches would be taken.
Modelers tend to use the techniques with which they are most familiar. So the best
way to develop good modeling skills is to look at lots of good examples and, most
of all, practice, practice, practice! Skilled simulation analysts are able to quickly
translate a process into a simulation model and begin conducting experiments.

171
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

172 Part I Study Chapters

Consider the following statement by Robert Shannon (1998):

If you want to become proficient in an art you must take up the tools (palette, canvas,
paint, and brushes) and begin to paint. As you do so, you will begin to see what works
and what doesn’t. The same thing is true in simulation. You learn the art of simulation
by simulating. Having a mentor to help show you the way can shorten the time and
effort.

The purpose of this chapter is to provide a little mentoring by showing how

typical modeling issues are handled during simulation. Some of the questions an-
swered in this chapter include
• How do I convert a conceptual model to a simulation model?
• What is the relationship between model simplicity and model
usefulness?
• How do I determine which system elements to include in a model?
• How do I determine the best way to represent system elements in a
model?
• How are common situations modeled using simulation?
Because a simulation model relies on a simulation language for its expres-
sion, (and since this textbook is titled Simulation Using ProModel), ProModel
will be used to illustrate how system elements are modeled.
For the most part, the discussion of modeling issues in this chapter is kept at
a conceptual level. Specific modeling examples in ProModel can be found in
Lab 7 of Part II.

7.2 Converting a Conceptual Model to a Simulation Model

The conceptual model is the result of the data-gathering effort and is a formula-
tion in one’s mind (supplemented with notes and diagrams) of how a particular
system operates. Building a simulation model requires that this conceptual model
be converted to a simulation model. Making this translation requires two impor-
tant transitions in one’s thinking. First, 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. Second, the different possible ways to model the sys-
tem should be evaluated to determine the most efficient yet effective way to rep-
resent the system.

7.2.1 Modeling Paradigms

A simulation model is a computer representation of how elements in a particular
system behave and interact. The internal representation of a system may not be
radically different between simulation products. However, the way that model in-
formation is defined using a particular product may be quite different. How a user
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 173

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. In this regard, a modeling paradigm determines the particular
“world view” that one should have when modeling a system. Learning a simula-
tion product requires that one first learn the particular modeling paradigm used by
the product.
Modeling paradigms differ among simulation products—although many dif-
ferences are minor. Historically, simulation products required models to be de-
fined line by line, specifying a list of instructions like a script for processing enti-
ties. Most modern products have a process orientation and support object-based
modeling. Some products view a process as an activity sequence, while others
view it from the standpoint of an entity routing.
Conceptually, object-based modeling is quite simple. An object represents a
real-world object such as a machine, an operator, a process part, or a customer. An
object is defined in terms of attributes and behaviors. Attributes are essentially
variables that are associated with an object such as its size, condition, time in the
system, and so on. Attributes are used to carry information about the object, either
for decision making or for output reporting. Attributes may be modified during the
simulation to reflect changing values. Behaviors define the operational logic as-
sociated with the object. This logic gets executed either whenever certain events
occur or when explicitly called in the model. Examples of behavioral logic in-
clude operations, machine setup, routing decisions, and material movement.
Examples of events or conditions that may trigger a behavior might be the com-
pletion of an operation, the elapse of a specified period of time, or the drop of a
tank or inventory to a specified level.
Objects are organized into classes according to similarity of attributes and be-
havior. In this way, all objects of the same class inherit the attributes and behav-
iors defined for the class. This simplifies object definitions and allows changes to
be quickly made to a set of similar objects. It also allows objects that are defined
once to be reused in other models. In ProModel, predefined object classes include
entities, resources, locations, and paths.
While object-based modeling is consistent with modern object-oriented pro-
gramming (OOP) practices, OOP itself is quite complicated and requires a signif-
icant amount of training to become proficient. The easiest simulation languages
are object-based, but they are not pure OOP languages. Otherwise, a modeler
might as well pick up an OOP language like Java and begin programming his or
her models.
ProModel is object-based but also provides an intuitive entity-flow modeling
paradigm. The natural way to think about most systems being modeled is to think
of them from the perspective of the entity as it flows through each workstation,
storage area, or some other location. In fact, it actually helps when building the
model to put yourself in the place of the entity flowing through the system and de-
scribe what you do and what resources you require as you move from place to
place in the system. For modeling purposes, it is useful to think of a system in
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

174 Part I Study Chapters

terms of the same structural and operational elements that were described in
Chapter 6. This is essentially how models are defined using ProModel.

7.2.2 Model Definition

A model is a simplified representation of reality, with emphasis on the word sim-
plified. This means that 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 ac-
tivity should always be viewed in terms of its effect on other system elements rather
than in terms of the detailed way in which it is performed. Such detailed mechanics
are inconsequential to the overall flow of entities and utilization of resources.
Most models, especially those built by beginners, tend to err on the side of
being overly detailed rather than being too general. The tendency is to reproduce
the precise way that the system operates (sometimes referred to as emulation). Not
only is it difficult to create extremely detailed models, but it is also difficult to
debug and maintain them. Furthermore, all of the detail may obscure the key is-
sues being analyzed so that it actually weakens the model. The power of a model
is more a function of its simplicity rather than its complexity. A point can be made
more effectively when it is reduced to its simplest form rather than disguised in a
morass of detail. Lou Keller of PROMODEL Corporation has suggested that the
Laffer curve, borrowed from economics, effectively illustrates the relationship be-
tween model complexity and model utility (see Figure 7.1). Notice that a certain
degree of complexity is essential to capture the key cause-and-effect relationships
in the system. However, a system has many more cause-and-effect relationships
than should be included in a model. There is an optimum amount of complexity
for any given model beyond which additional utility begins to diminish.
The remaining sections in this chapter give recommendations on how to ef-
fectively yet minimally represent system elements in a simulation model using a
simulation language like ProModel.

FIGURE 7.1
Relationship between
model complexity and
model utility (also
known as the Laffer
Complexity

curve).

Optimum level of
model complexity

Utility
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 175

7.3 Structural Elements

For the most part, model objects represent the structural elements in a system
such as machines, people, work items, and work areas. For purposes of our
discussion, we will be using the simple object classification employed by
ProModel:
• 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.
Not all simulation products provide the same set or classification of modeling
elements. Even these elements could be further subdivided to provide greater dif-
ferentiation. Locations, for example, could be subdivided into workstations,
buffers, queues, and storage areas. From a system dynamics perspective, however,
these are all still simply places to which entities are routed and where operations
or activities may be performed. For this reason, it is easier just to think of them all
in the generic sense as locations. The object classification used by ProModel is
simple yet broad enough to encompass virtually any object encountered in most
manufacturing and service systems.
These model elements or objects have behavior associated with them
(discussed in Section 7.4, “Operational Elements”) and attributes. Most common
behaviors and attributes are selectable from menus, which reduces the time re-
quired to build models. The user may also predefine behaviors and attributes that
are imported into a model.

7.3.1 Entities
Entities are the objects processed in the model that represent the inputs and out-
puts of the system. Entities in a system may have special characteristics such as
speed, size, condition, and so on. Entities follow one or more different routings in
a system and have processes performed on them. They may arrive from outside
the system or be created within the system. Usually, entities exit the system after
visiting a defined sequence of locations.
Simulation models often make extensive use of entity attributes. For exam-
ple, an entity may have an attribute called Condition that may have a value of 1
for defective or 0 for nondefective. The value of this attribute may determine
where the entity gets routed in the system. Attributes are also frequently used to
gather information during the course of the simulation. For example, a modeler
may define an attribute called ValueAddedTime to track the amount of value-
added time an entity spends in the system.
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, and the average number of entities in the system.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

176 Part I Study Chapters

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. For example, if a
component part is assembled to a base item at an assembly station, and the station
is always stocked with the component part, it is probably unnecessary to model
the component part. In this case, what is essential to simulate is just the time delay
to perform the assembly. If, however, the component part may not always be
available due to delays, then it might be necessary to simulate the flow of compo-
nent parts as well as the base items. The rule is that if you can adequately capture
the dynamics of the system without including the entity, don’t include it.

Entity Aggregating
It is not uncommon for some manufacturing systems to have hundreds of part
types or for a service system to have hundreds of different customer types. Mod-
eling each one of these 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 whenever possible (see Figure 7.2). This works especially well when all
entities have the same processing sequence. Even if a slight difference in process-
ing exists, it often can be handled through use of attributes or by using probabili-
ties. 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 call it part or customer.

Entity Resolution
Each individual item or person in the system need not always be represented by a
corresponding model entity. Sometimes a group of items or people can be repre-
sented by a single entity (see Figure 7.3). For example, a single entity might be
used to represent a batch of parts processed as a single unit or a party of people
eating together in a restaurant. If a group of entities is processed as a group and
moved as a group, there is no need to model them individually. 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.

Type A

Type B

Type X
Type C
9 entities 1 entity

FIGURE 7.2 FIGURE 7.3

Treating different entity types as a Treating multiple entities as a
single type. single entity.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 177

High-Rate Entity Processing

In some systems, especially in the food and beverage industries, it is not uncom-
mon to process entities at a rate of hundreds per minute. In such situations,
modeling each individual entity can significantly slow down the simulation. For
high-rate processing in which individual entity tracking isn’t critical, it may be
preferable to merely track entity production at various stages of a process using
variables or attributes instead of individual entities. Simulation languages having
a tank or accumulator construct can make this easier. Having thousands of entities
in the system at one time (especially those with multiple attributes) can consume
lots of computer memory and may slow the simulation significantly.
An alternative approach to modeling high-rate entity processing is to adjust
the resolution of the entity, as discussed earlier. Using this approach, you might
model every carton of 48 bottles or containers in a beverage-processing facility as
a single entity. This approach also works for continuously flowing substances
such as liquids or granules, which can often be converted, for simulation, into dis-
crete units of measure such as gallons, pounds, or barrels.

7.3.2 Locations
Locations are places in the system that entities visit for processing, waiting, or de-
cision making. A location might be a treatment room, workstation, check-in point,
queue, or storage area. Locations have a holding capacity and may have certain
times that they are available. They may also have special input and output such as
input based on highest priority or output based on first-in, first out (FIFO).
In simulation, we are often 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.

Locations 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 en route to another with-
out spending any time, it probably isn’t necessary to include the location. For ex-
ample, a water spray station through which parts pass without pausing probably
doesn’t need to be included in a model. 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 place or logic gets executed, even
though no time is required (splitting or destroying an entity, sending a
signal, incrementing an attribute or variable).
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

178 Part I Study Chapters

• Place or point where a decision is made about further routing (a branch in

a conveyor or path, an area in a store where customers decide to which
checkout counter they will go).

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.
When combining parallel locations having identical processing times, the
resulting location should have a capacity equal to the combined capacities of the
individual locations; however, the activity time should equal that of only one of
the locations (see Figure 7.4). A situation where multiple locations might be com-
bined in this way is a parallel workstation. An example of a parallel workstation
is a work area where three machines perform the same operation. All three ma-
chines could be modeled as a single location with a capacity equal to three. Com-
bining locations can significantly reduce model size, especially when the number
of parallel units gets very large, such as a 20-station checkout area in a large shop-
ping center or a 100-seat dining area in a restaurant.
When combining serial locations, the resultant location should have a capac-
ity equal to the sum of the individual capacities and an activity time equal to the
sum of the activity times. An example of a combined serial sequence of locations

FIGURE 7.4
Example of combining
three parallel stations Capacity ⫽ 1
into a single station.

Capacity ⫽ 1 Capacity ⫽ 1 Capacity ⫽ 1

Operation 10 Operation 30
Capacity ⫽ 1

Operation 20
1 min. each

Capacity ⫽ 1 Capacity ⫽ 3 Capacity ⫽ 1

Operation 10 Operation 20 Operation 30

1 min.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 179

FIGURE 7.5
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 Stations 2–4 Station 5

1 min. 3 min. 1 min.

might be a synchronous transfer line that has multiple serial stations. All of them
could be represented as a single location with a capacity equal to the number of
stations (see Figure 7.5). Parts enter the location, spend an amount of time equal
to the sum of all the station times, and then exit the location. The behavior may
not be exactly the same as having individual stations, such as when the location
becomes blocked and up to three parts may be finished and waiting to move to
station 5. The modeler must decide if the representation is a good enough approx-
imation for the intended purpose of the simulation.

7.3.3 Resources
Resources are the agents used to process entities in the system. Resources may be
either static or dynamic depending on whether they are stationary (like a copy ma-
chine) or move about in the system (like an operator). Dynamic resources behave
much like entities in that they both move about in the system. Like entities, re-
sources may be either animate (living beings) or inanimate (a tool or machine). 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, however, usually don’t have a defined flow sequence and remain in the
system (except for off-duty times). 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 re-
sources are needed, and how entity processing is affected by resource availability.
The response time for acquiring a resource may also be of interest.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

180 Part I Study Chapters

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, for example, there may be little benefit in in-
cluding it in the model since entities never have to wait for the resource to become
available before using it. You simply assign the processing time to the workstation.
If, on the other hand, the resource may not always be available (it experiences
downtime) or is a shared resource (multiple activities compete for the same
resource), it should probably be included. Once again, the consideration is how
much the resource is likely to affect system behavior.

Resource Travel Time

One consideration when modeling the use of resources is the travel time associ-
ated with mobile resources. A modeler must ask whether a resource is immediately
accessible when available, or if there is some travel time involved. For example, a
special piece of test equipment may be transported around to several locations in
a facility as needed. If the test equipment is available when needed at some loca-
tion, but it takes 10 minutes to get the test equipment to the requesting location,
that time should be accounted for in the model. The time for the resource to move
to a location may also be a function of the distance it must travel.

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.
Consumable resources are usually modeled either as a function of time or as
a step function associated with some event such as the completion of an operation.
This can be done by defining a variable or attribute that changes value with time
or by event. A variable representing the consumption of packaging materials, for
example, might be based on the number of entities processed at a packaging
station.

Transport Resources
Transport resources are resources used to move entities within the system.
Examples of transport resources are lift trucks, elevators, cranes, buses, and air-
planes. These resources are dynamic and often are 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, similar to an entity
routing. A common example of this is a bus route.
In advanced manufacturing systems, the most complex element to model is
often the transport or material handling system. This is because of the complex
operation that is associated with these computer-controlled systems such as
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 181

conveyor systems and automated guided vehicle systems (AGVS). Modeling

advanced material handling systems can be simplified if the modeling language
provides special constructs for defining them; otherwise the logic describing their
behavior must be defined by the modeler. ProModel provides facilities for model-
ing material handling systems that are described in Chapter 13.

7.3.4 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. In ProModel
simple paths are automatically created when a routing path is defined. A routing
path connecting two locations becomes the default path of travel if no explicitly
defined path or path network connects the locations.
Paths linked together to form path networks are common in manufacturing
and service systems. In manufacturing, aisles are connected to create travel ways
for lift trucks and other material handlers. An AGVS sometimes has complex path
networks that allow controlled traffic flow of the vehicles in the system. In service
systems, office complexes have hallways connecting other hallways that connect
to offices. Transportation systems use roadways, tracks, and so on that are often
interconnected.
When using path networks, there can sometimes be hundreds of routes to take
to get from one location to another. ProModel is able to automatically navigate en-
tities and resources along the shortest path sequence between two locations. Op-
tionally, you can explicitly define the path sequence to take to get from one point
to any other point in the network.

7.4 Operational Elements

Operational elements define the behavior of the different physical elements in the
system and how they interact. These include routings, operations, arrivals, entity
and resource movement, task selection rules, resource schedules, and downtimes
and repairs.
Most of the operational elements of a model can be defined using constructs
that are specifically provided for modeling such elements. The operational rules
for each can usually be selected from menus. There may be situations, however,
that require the modeler to use special logic such as “if–then” statements to
achieve the special operating behavior that is desired.

7.4.1 Routings
Routings 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.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

182 Part I Study Chapters

Frequently entities may be routed to more than one possible location. When
choosing from among multiple alternative locations, a rule or criterion must be
defined for making the selection. A few typical rules that might be used for
selecting the next location in a routing decision include
• Probabilistic—entities are routed to one of several locations according to
a frequency distribution.
• First available—entities go to the first available location in the order they
are listed.
• By turn—the selection rotates through the locations in the list.
• Most available capacity—entities select the location that has the most
available capacity.
• Until full—entities continue to go to a single location until it is full and
then switch to another location, where they continue to go until it is full,
and so on.
• Random—entities choose randomly from among a list of locations.
• User condition—entities choose from among a list of locations based on a
condition defined by the user.

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 rout-
ing accordingly. When using an entity attribute, the attribute is incremented either
on entry to or on exit from a location and tested before making the particular op-
eration or routing decision to see which pass the entity is currently on. Based on
the value of the attribute, a different operation or routing may be executed.

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. An example is a document requiring signatures from several depart-
ments. The sequence in which the signatures are obtained may be unimportant as
long as all signatures are obtained.
In unordered routing situations, it is important to keep track of which
locations have or haven’t been visited. Entity attributes are usually the most prac-
tical way of tracking this information. An attribute may be defined for each possi-
ble location and then set to 1 whenever that location is visited. The routing is then
based on which of the defined attributes are still set to zero.

7.4.2 Entity Operations

An entity operation defines what happens to an entity when it enters a location.
For modeling purposes, the exact nature of the operation (machining, patient
check-in, or whatever) is unimportant. What is essential is to know what happens
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 183

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 des-
ignation, detailed logic may need to be defined using if–then statements, variable
assignment statements, or some other type of statement (see Section 7.4.8, “Use
of Programming Logic”).
An entity operation is one of several different types of activities that take
place in a system. As with any other activity in the system, the decision to include
an entity operation in a model should be based on whether the operation impacts
entity flow in some way. For example, if a labeling activity is performed on enti-
ties in motion on a conveyor, the activity need not be modeled unless there are sit-
uations where the labeler experiences frequent interruptions.

Consolidation of Entities
Entities often undergo operations where they are consolidated or become either
physically or logically connected with other entities. Examples of entity consoli-
dation include batching and stacking. In such situations, entities are allowed to
simply accumulate until a specified quantity has been gathered, and then they are
grouped together into a single unit. Entity consolidation may be temporary, al-
lowing them to later be separated, or permanent, in which case the consolidated
entities no longer retain their individual identities. Figure 7.6 illustrates these two
types of consolidation.
Examples of consolidating multiple entities to a single entity include
• Accumulating multiple items to fill a container.
• Gathering people together into groups of five for a ride at an amusement park.
• Grouping items to load them into an oven for heating.
In ProModel, entities are consolidated permanently using the COMBINE com-
mand. Entities may be consolidated temporarily using the GROUP command.

Attachment of Entities
In addition to consolidating accumulated entities at a location, entities can also be
attached to a specific entity at a location. Examples of attaching entities might be

FIGURE 7.6
Consolidation of
entities into a single before after
entity. In (a) (a)
permanent
consolidation, batched
entities get destroyed.
In (b) temporary
consolidation, batched
entities are preserved before
(b) after
for later unbatching.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

184 Part I Study Chapters

FIGURE 7.7
Attachment of one or
more entities to
another entity. In (a)
permanent attachment, after
the attached entities
get destroyed. In (b) before
temporary attachment, ( a)
the attached entities
are preserved for later
detachment.

after
before
(b)

attaching a shipping document to an order ready for delivery, assembling wheels

to a chassis, or placing items into a container. The difference between attaching
entities and consolidating entities is that entities become attached to an existing
base or main entity that must be present at the location. It is the presence of the
main entity at the location that triggers the routing of the entities to be attached. In
consolidation, entities are combined in whichever order they happen to enter the
location. Like consolidation, attachment may be temporary, where the attached
entities are later detached, or permanent, where the attached entities are destroyed
and only the initial entity to which they were attached continues. Figure 7.7 illus-
trates these two types of attachment.
Examples of attaching entities to another entity include
• Attaching component parts to a base assembly.
• Delivering a completed order to a waiting customer.
• Loading material into a container.
In ProModel, entities are attached to another entity using the LOAD command
for temporary attachments or the JOIN command for permanent attachments. Cor-
responding LOAD and JOIN routings must also be defined for the entities to be
loaded or joined.

Dividing Entities
In some entity processes, a single entity is converted into two or more new enti-
ties. An example of entity splitting might be an item that is cut into smaller pieces
or a purchase order that has carbon copies removed for filing or sending to
accounting. Entities are divided in one of two ways: either the entity is split up
into two or more new entities and the original entity no longer exists; or additional
entities are merely created (cloned) from the original entity, which continues to
exist. These two methods are shown in Figure 7.8.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 185

FIGURE 7.8
Multiple entities
created from a single
before after
entity. Either (a) the (a)
entity splits into
multiple entities (the
original entity is
destroyed) or (b) the
entity creates one or
more entities (the before
original entity
continues). after
(b)

Examples of entities being split or creating new entities from a single entity
include
• A container or pallet load being broken down into the individual items
comprising the load.
• Driving in and leaving a car at an automotive service center.
• Separating a form from a multiform document.
• A customer placing an order that is processed while the customer waits.
• A length of bar stock being cut into smaller pieces.
In ProModel, entities are split using a SPLIT statement. New entities are created
from an existing entity using a CREATE statement. Alternatively, entities can be con-
veniently split or created using the routing options provided in ProModel.

7.4.3 Entity Arrivals

Entity arrivals define the time, quantity, frequency, and location of entities enter-
ing the system. Examples of arrivals are customers arriving at a post office or cars
arriving at an intersection. Entities may arrive to a manufacturing or service sys-
tem in one of several different ways:
• Periodic—they arrive at a periodic interval.
• Scheduled—they arrive at specified times.
• Fluctuating—the rate of arrival fluctuates with time.
• Event triggered—they arrive when triggered by some event.
In any case, entities can arrive individually or in batches.

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. For example, computer monitors might
arrive from an assembly line to be packaged at an interval that is normally
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

186 Part I Study Chapters

distributed with a mean of 1.6 minutes and a standard deviation of 0.2 minute. Ex-
amples of periodic arrivals include
• Parts arriving from an upstream operation that is not included in the model.
• Customers arriving to use a copy machine.
• Phone calls for customer service during a particular part of the day.
Periodic arrivals are defined in ProModel by using the arrivals table.

Scheduled Arrivals
Scheduled arrivals occur when entities arrive at specified times with possibly some
defined variation (that is, a percentage will arrive early or late). Scheduled arrivals
may occur in quantities greater than one such as a shuttle bus transporting guests at
a scheduled time. It is often desirable to be able to read in a schedule from an ex-
ternal file, especially when the number of scheduled arrivals is large and the sched-
ule may change from run to run. Examples of scheduled arrivals include
• Customer appointments to receive a professional service such as counseling.
• Patients scheduled for lab work.
• Production release times created through an MRP (material requirements
planning) system.
Scheduled arrivals sometime occur at intervals, such as appointments that occur
at 15-minute intervals with some variation. This may sound like a periodic arrival;
however, periodic arrivals are autocorrelated in that the absolute time of each ar-
rival is dependent on the time of the previous arrival. In scheduled arrival inter-
vals, each arrival occurs independently of the previous arrival. If one appointment
arrives early or late, it will not affect when the next appointment arrives.
ProModel provides a straightforward way for defining scheduled arrivals
using the arrivals table. A variation may be assigned to a scheduled arrival to sim-
ulate early or late arrivals for appointments.

Fluctuating Arrivals
Sometimes entities arrive at a rate that fluctuates with time. For example, the rate
at which customers arrive at a bank usually varies throughout the day with peak
and lull times. This pattern may be repeated each day (see Figure 7.9). Examples
of fluctuating arrivals include
• Customers arriving at a restaurant.
• Arriving flights at an international airport.
• Arriving phone calls for customer service.
In ProModel, fluctuating arrivals are specified by defining an arrival cycle
pattern for a time period that may be repeated as often as desired.

Event-Triggered Arrivals
In many situations, entities are introduced to the system by some internal trigger
such as the completion of an operation or the lowering of an inventory level to a
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 187

FIGURE 7.9
A daily cycle pattern 120
of arrivals.
100
Arrival quantity
80

60

40

20

9A.M. 10A.M. 11A.M.12 NOON 1P.M. 2P.M. 3P.M. 4P.M. 5P.M. 6P.M.
Hour of day

reorder point. Triggered arrivals might occur when

• A kanban or delivery signal is received.
• Inventory drops to the reorder-point level.
• Conditions have been met to start processing a new entity.
Sometimes the signal to initiate an arrival or to begin production of an item is
triggered by some other arrival. An example of this is the arrival of a customer order
for a product. In such instances, it isn’t the order that flows through the system but
the product the order triggers. To model this situation, you define the characteristic
of the order arrival (frequency, type, or the like) and then have the arriving order
trigger production of the product.
In ProModel, entity arrivals can be triggered using an ORDER statement. This
statement can be used anywhere in the model so that any situation can cause a new
entity to be ordered into the model.

7.4.4 Entity and Resource Movement

Entities and resources seldom remain stationary in a system. Entities move through
the system from location to location for processing. Resources also move to differ-
ent locations where they are requested for use. Additionally, resources frequently
move or escort entities in the system.
Movement can be handled in three basic ways in a simulation:
1. Ignore the movement.
2. Model the move using a simple move time (which may also be defined
by speed and distance).
3. Model the move using a path network that requires the moving entity or
resource to contend with traffic.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

188 Part I Study Chapters

A path network essentially imitates the network of aisles or hallways found

on plant floors 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 once again on the level of
detail needed for a valid model. In making this determination, 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 part of the operation time, it may be ignored.
• If move times are significant but traffic congestion is light, a simple move
time (or speed and distance) should be defined.
• If move times are significant and traffic congestion is heavy, a path
network should be defined.

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

Use of Priorities
Locations and resources may be requested with a particular priority in ProModel.
Priorities range from 0 to 999, with higher values having higher priority. If no pri-
ority is specified, it is assumed to be 0. For simple prioritizing, you should use pri-
orities from 0 to 99. Priorities greater than 99 are for preempting entities and
downtimes currently in control of a location or resource. The command Get
Operator, 10 will attempt to get the resource called Operator with a priority of
10. If the Operator is available when requested, the priority has no significance. If,
however, the Operator is currently busy, this request having a priority of 10 will
get the Operator before any other waiting request with a lower priority.

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.
For example, an emergency patient requesting a particular doctor may preempt a
patient receiving routine treatment by the doctor. Manufacturing and service or-
ganizations frequently have “hot” jobs that take priority over any routine job
being done. Preemption is achieved by specifying a preemptive priority (100
to 999) for entering the location or acquiring the resource.
Priority values in ProModel are divided into 10 levels (0 to 99, 100 to 199, . . . ,
900 to 999). Levels higher than 99 are used to preempt entities or downtimes of a
lower level. Multiple preemptive levels make it possible to preempt entities or
downtimes that are themselves preemptive.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 189

The level of preemption to specify is determined by whether an entity or a

downtime is being preempted. To preempt an entity that is currently using a loca-
tion or resource, the preempting entity or downtime must have a priority that is at
least one level higher than the current entity. For example, a priority of 100 would
preempt any entity that had acquired a location or resource with a priority of
0 to 99. To preempt a downtime currently in effect at a location or resource, the
preempting entity or downtime must have a priority that is at least two levels
higher than the downtime (the exception to this is a setup downtime, which is pre-
empted using the same rules as those for preempting an entity).
The primary issue associated with preemption is what to do with the pre-
empted entity. The common way of handling a preempted entity is to simply put
it on hold until the resource or location becomes available again for use. Then any
remaining time is completed. This is the default way that ProModel handles pre-
emption. Alternatively, it may be desirable to get a different resource instead of
waiting for the one being used by the preempting entity. Sometimes it may be nec-
essary to delay the preemption or possibly even ignore it, depending on certain
circumstances in the model. For example, it may be unallowable to interrupt a ma-
chining cycle or a surgical operation. In such instances, a preemptive attempt may
just have to wait. ProModel allows you to write special preemption logic for
achieving these kinds of effects.

Task Selection Rules

Locations and resources are often discriminating with respect to which waiting
entity or activity they next select to service. While priorities determine the order
in which entities line up to use a location or resource, task selection rules deter-
mine which entity waiting for a location or resource is actually granted permission
to use the location or resource when it becomes available. For example, parts
waiting to be processed at a machine may also be competing with parts waiting to
be reworked on the same machine. In such a situation, it may be desirable to first
select the part requiring rework.
Task selection plays a crucial role in simulation-based scheduling (Thompson
1994). Rules range 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. It allows the user to define the logic for selecting the next task by
examining the nature of all of the tasks waiting to be performed, looking upstream
or looking ahead to see what entities or tasks will be coming along, and looking
downstream to see what tasks will best serve the needs of subsequent waiting
resources. By default locations and resources in ProModel respond to the highest-
priority request that has been waiting the longest. Other criteria may be defined,
however, to force a different response.

7.4.6 Resource Scheduling

Resources, as well as locations, frequently have scheduled times during which
they are unavailable. These include off-shift periods, breaks, and preventive
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

190 Part I Study Chapters

maintenance. If it is necessary to model periods of availability and unavailability

to have a valid model, some of the issues that need to be addressed when model-
ing scheduled availability 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 the scheduled
available time and not on the entire simulation time.
• Deciding what to do with arrivals that occur at a location that is off shift.

Going off Schedule in the Middle of a Task

It is not uncommon when running a simulation with work schedules to have a re-
source go off schedule in the middle of a task (the current task is preempted). For
short tasks, this is generally not a problem; you simply allow the resource to com-
plete the task and then allow the schedule to take control. For longer tasks that
may take hours, it usually isn’t desirable to keep the resource until the task is com-
pleted. There are at least three options to take:
1. Don’t start the task in the first place.
2. Interrupt the task and go off schedule.
3. If the task is nearly complete, go ahead and finish the task.
To determine whether to start the task in the first place, the modeler needs to test
for the time before the next schedule change and compare it with the anticipated
time to complete the task at hand. Interrupting a task usually requires only that a pre-
emptive priority be given to the schedule. To determine whether the task is almost
complete, a variable should be assigned to the completion time, which can be
checked at the time of the schedule change. A related situation is when several tasks
are waiting that must be processed before going off schedule (for example, a check-
out stand in a grocery store closes but must service current customers in line). This
situation is facilitated if some logic can be executed at the time a schedule is about to
be executed. This logic needs to be able to delay the schedule execution. ProModel
allows these types of delays to be defined.

Basing Resource Statistics on Scheduled Time

When including work schedules in a model, it is generally desirable to gather sta-
tistics 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. This way, statistics are reported for re-
sources and locations only for the time during which they were scheduled to be
available.

Handling Arrivals during Off-Shift Times

It is usually desirable to prevent arrivals (especially human entities) from occur-
ring during off-schedule times because you don’t want them to have to wait until
a location or resource is back on schedule. To turn off arrivals during off-shift
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 191

times, one solution is to try to synchronize the arrivals with the work schedule.
This usually complicates the way arrivals are defined. Another solution, and usu-
ally an easier one, is 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 is unavailable at the time of an
arrival, the arriving entities are simply discarded.

7.4.7 Downtimes and Repairs

It is not uncommon for resources and even 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.

Downtimes Based on Total Elapsed Time

An example of a periodic downtime based on elapsed clock time might be a
worker who takes a break every two hours. Scheduled maintenance is also a type
of downtime performed at periodic intervals based on elapsed clock time.
Figure 7.10 illustrates how a downtime based on elapsed time would be simu-
lated. Notice that the calculation of the interval between downtimes takes into ac-
count not only busy time, but also idle time and downtime. In other words, it is the
total elapsed time from the start of one downtime to the start of the next. Down-
times based on total elapsed time are often scheduled downtimes during which
operational statistics on the location or resource are suspended. ProModel allows
you to designate whether a particular downtime is to be counted as scheduled
downtime or unscheduled downtime.
Sometimes it may be desirable to use elapsed time to define random equip-
ment failures. This 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 (1) the total elapsed time from one failure to the
next, (2) the time between the repair of one failure to the time of the next failure
(operational time between failures), or (3) the time that the machine was actually
in operation (operating time between failures). ProModel accepts downtime defi-
nitions based on cases 1 and 3, but requires that case 2 be converted to case 1. This
is done by adding the time until the next failure to the repair time of the last failure.
For example, if the operational time between failures is exponentially distributed
with a mean of 10 minutes and the repair time is exponentially distributed with a

FIGURE 7.10 Start Interrupt Interrupt

Resource downtime 6 10 4 6 14
occurring every 20
minutes based on total
elapsed time. Idle Busy Idle Down Busy
Time (minutes)
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

192 Part I Study Chapters

FIGURE 7.11 Start Interrupt

Resource downtime 12 8
occurring every 20
minutes, based on
operating time. Idle Busy Idle Busy
Time (minutes)

mean of 2 minutes, the time between failures should be defined as xlast + E(10)
where xlast is the last repair time generated using E(2) minutes.

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. In this situation, the interval between
downtimes would be defined relative to actual machine operation time. A machine
that goes down every 20 minutes of operating time for a three-minute repair is
illustrated in Figure 7.11. Note that any idle times and downtimes are not included
in determining when the next downtime occurs. The only time counted is the ac-
tual operating time.
Because downtimes usually occur randomly, the time to failure is most accu-
rately defined as a probability distribution. Studies have shown, for example, that
the operating time to failure is often exponentially distributed.

Downtimes Based on the Number of Times Used

The last type of downtime occurs based on the number of times a location was
used. For example, a tool on a machine may need to be replaced every 50 cycles
due to tool wear, or a copy machine may need paper added after a mean of 200
copies with a standard deviation of 25 copies. ProModel permits downtimes to be
defined in this manner by selecting ENTRY as the type of downtime and then spec-
ifying the number of entity entries between downtimes.

Downtime Resolution
Unfortunately, data are rarely available on equipment downtime. When they are
available, they are often recorded as overall downtime and seldom broken down
into number of times down and time between failures. Depending on the nature of
the downtime information and degree of resolution required for the simulation,
downtimes can be treated in the following ways:
• Ignore the downtime.
• Simply increase processing times 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.

Ignoring Downtime. There are several situations where it might make sense to
ignore downtimes in building a simulation model. Obviously, one situation is
where absolutely no data are unavailable on downtimes. If there is no knowledge
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 193

of resource downtimes, it is appropriate to model the resource with no downtimes

and document it as such in the final write-up. When there are downtimes, but they
are extremely infrequent and not likely to affect model performance for the period
of the study, it is safe to ignore them. For example, if a machine fails only two or
three times a year and you are trying to predict processing capacity for the next
workweek, it doesn’t make sense to include the downtime. It is also safe to ignore
occasional downtimes that are very small compared to activity times. If, for ex-
ample, a downtime takes only seconds to correct (like clearing a part in a machine
or an occasional paper jam in a copy machine), it could be ignored.

Increasing Processing Times. A common way of treating downtime, due in part

to the lack of good downtime data, is to simply reduce the production capacity of
the machine by the downtime percentage. In other words, if a machine has an ef-
fective capacity of 100 parts per hour and experiences a 10 percent downtime, the
effective capacity is reduced to 90 parts per hour. 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. Thus no consideration is
given for the variability in both time between failures and time to repair that typ-
ifies most production systems. Law (1986) has shown that this deterministic ad-
justment for downtime can produce results that differ greatly from the results
based on actual machine downtimes.

MTBF/MTTR. Two parts to any downtime should be defined when modeling

downtime. One, time between failures, defines the interval between failures. The
other, time to repair, defines the time required to bring a resource back online
whenever it goes down. Often downtimes are defined in terms of mean time
between failures (MTBF) and mean time to repair (MTTR). Using average times
for these intervals presents the same problems as using average times for any ac-
tivity in a simulation: it fails to account for variability, which can have a signifi-
cant impact on system performance.

Using Statistical Distributions. Whenever possible, time between failures and

time to repair should be represented by statistical distributions that reflect the
variation that is characteristic of these elements. Studies have shown that the time
until failure, particularly due to items (like bearings or tooling) that wear, tends to
follow a Weibull distribution. Repair times often follow a lognormal distribution.

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 and downtime events that occur only when a resource is in use.
As explained earlier, 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.
Erroneously basing downtime on elapsed time when it should be based on
operating time artificially inflates time between failures by the inclusion of idle
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

194 Part I Study Chapters

time. It also implies that during periods of high equipment utilization, the same
amount of downtime occurs as during low utilization periods. Equipment failures
should generally be based on operating time and not on elapsed time because
elapsed time includes operating time, idle time, and downtime. It should be left to
the simulation to determine how idle time and downtime affect the overall elapsed
time between failures.
To illustrate the difference this can make, let’s assume that the following
times were logged for a given operation:

Status Time (Hours)

In use 20
Down 5
Idle 15

Total time 40

If it is assumed that downtime is a function of total time, then the percentage of

downtime would be calculated to be 5 hours/40 hours, or 12.5 percent. If, how-
ever, it is assumed that the downtime is a function of usage time, then the down-
time percentage would be 5 hours/20 hours, or 25 percent. Now let’s suppose that
the system is modeled with increased input to the operation so that it is never
starved (the idle time = 0). If downtime is assumed to be 12.5 percent, the total
time down will be .125 × 40 = 5 hours. If, on the other hand, we use the assump-
tion that it is 25 percent, then the time down will end up being .25 × 40 hours =
10 hours. This is a difference of five hours, which means that if downtime is
falsely assumed to be a function of total time, the simulation would realize five
extra hours of production in a 40-hour period that shouldn’t have happened.

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 (that is, they have been preempted).
For example, a machine might break down while running the seventh part of a
batch of 20 parts. The modeler must decide what to do with these entities. Several
alternatives may be chosen, and the modeler must select which alternative is the
most appropriate:
• Resume processing the entity after the 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, in fact, may be
adequate in situations where either the processing times or the downtimes are rel-
atively short. In such circumstances, the delay in entity flow is still going to
closely approximate what would happen in the actual system.
If the entity resumes processing later using either the same or another re-
source, a decision must be made as to whether only the remaining process time is
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 195

used or if additional time must be added. By default, ProModel suspends process-

ing until the location or resource returns to operation. Alternatively, other logic
may be defined.

7.4.8 Use of Programming Logic

Sometimes the desired model behavior can’t be achieved using a “canned” con-
struct provided by the software. In these instances, it is necessary to use program-
ming logic that tests probabilities, variables, and attributes to make behavioral
decisions. A brief explanation of how these elements can be used in developing a
simulation model is given here.

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 proba-
bilistic routing rule and specify the probability value. The routing is then randomly
chosen according to the probability specified. For operations that occur randomly
at a particular location, however, a probability function must be used in connection
with if–then logic. 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. Assuming rand() is a function that returns a
random value between 0 and 1, the code for defining this behavior might be as
follows:
if rand() <= .10
then wait U(3,1) min

A similar situation occurs in activity times that have more than one distribu-
tion. For example, 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 Trian-
gular(3, 7.5, 15) minutes to repair. The logic for the downtime definition might be
if rand() <= .30
then wait T(.2, 1.5, 3) min
else wait T(3, 7.5, 15) min

Another example of multidistribution activity is a call center that handles

three different types of calls that we will designate as A, B, and C. The time to
handle calls is exponentially distributed, but the mean time is different depending
on the type of call (see Table 7.1). To model this situation, the following code

TABLE 7.1 Table of Service Times for Different Call Types

Call Type Probability of Occurrence Service Time (Minutes)

A .20 E(5)
B .50 E(8)
C .30 E(12)
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

196 Part I Study Chapters

might be entered (“//” are used at the beginning of a comment line):

// set a real variable (rValue) to a random number
real rValue = rand()
// test for call type A
if rValue <=.20
then wait E(5) min
else if rValue <=.70
then wait E(8) min
else wait E(12) min

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. In this situ-
ation, an attribute of the entity should be the basis of the decision because we need
to test how many times that particular entity has visited the location. An attribute
we will call Pass will need to be defined in the attribute module. If a normal oper-
ation takes five minutes but a rework operation takes only two minutes, the fol-
lowing 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

Using Global Variables to Gather Statistics

Global variables are placeholders for values that may change during the simula-
tion. What makes them global is that they are accessible from any place in the
model by any object in the model, and they exist during the entire simulation.
Global variables are defined by the user for user-defined purposes. For exam-
ple, a variable may be defined to keep track of the total number of entities in a
certain area of the system (work in process). Each time an entity enters the area, it
increments the variable. Also, each time an entity leaves the area, it decrements
the variable. Because the user has the option of collecting statistics on global vari-
ables, either the simple or time-weighted average value of the variable can be
reported at the end of the simulation. A time series report showing all of the
changes in the variable over time can also be reported.

Using Local Variables for Looping

Local variables 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. When the object
finishes executing the logic block in which the local variable was defined, the
variable disappears. A local variable may be thought of as a temporary attribute of
the object executing the logic because multiple objects executing the same logic
at the same time would each have their own local variables assigned to them while
executing the block of logic. Local variables are useful primarily for executing a
logic loop. Suppose, for example, that you wanted to assign the value of 4 to the
first 10 elements of an array called NumOfBins that was defined in the Array
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 197

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 (also used in C++ and Java)
for starting and ending a block of logic. In this case it is the block of statements to be
executed repeatedly by an object as long as the local variable Count is less than 11.

7.5 Miscellaneous Modeling Issues

This section addresses special issues that may be encountered in simulation. They
don’t fit well under previous headings, so they are put in a collection here even
though they are not necessarily related.

7.5.1 Modeling Rare Occurrences

Often there exist situations in the real world that occur only rarely. For example, a
machine may break down once every two months, or only one in a thousand parts is
rejected at an inspection station. 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 key input variables.
But some rare situations have a significant impact on the operation of the sys-
tem. For example, a plant shutdown may bring the entire operation to a stop. If the
focus of interest is to evaluate the effects of the rare occurrence, such as how long
it takes for inventories to be depleted if a shutdown occurs, then it makes sense to
include the rare occurrence in the model. The easiest way to model a rare event is
not to let the model run for six months or a year before the event occurs, but to go
ahead and force the event to happen. The point of modeling the rare event is to see
what impact it has on system behavior, not to predict when it actually might occur.
So it really doesn’t matter when it happens as long as the state of the model is typ-
ical of what the system might be when it does occur.

7.5.2 Large-Scale Modeling

Occasionally it may be desirable to model a large system such as an entire factory
or the entire activity in an international airport. The tendency (especially for
novice simulators) is to painstakingly piece together a huge, complex model only
to find that it runs nowhere near the way that was expected and may not even run
at all. The disappointment of not getting the model to run correctly the first time
is soon overshadowed by the utter despair in trying to debug such an enormous
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

198 Part I Study Chapters

model. When faced with building a supermodel, it is always a good idea to parti-
tion the model into several submodels and tackle the problem on a smaller scale
first. Once each of the submodels has been built and validated, they can be merged
into a larger composite model. This composite model can be structured either as a
single monolithic model or as a hierarchical model in which the details of each
submodel are hidden unless explicitly opened for viewing. Several ways have
been described for merging individual submodels into a composite model
(Jayaraman and Agarwal 1996). Three of the most common ways that might be
considered for integrating submodels are
• Option 1: Integrate all of the submodels just as they have been built. This
approach preserves all of the detail and therefore accuracy of the individual
submodels. However, the resulting composite model may be enormous and
cause lengthy execution times. The composite model may be structured as
a flat model or, to reduce complexity, as a hierarchical model.
• Option 2: Use only the recorded output from one or more of the submodels.
By simulating and recording the time at which each entity exits the model
for a single submodel, these exit times can be used in place of the
submodel for determining the arrival times for the larger model. This
eliminates the need to include the overhead of the individual submodel in
the composite model. This technique, while drastically reducing the
complexity of the composite model, may not be possible if the interaction
with the submodel is two-way. For submodels representing subsystems
that simply feed into a larger system (in which case the subsystem operates
fairly independently of downstream activities), this technique is valid. An
example is an assembly facility in which fabricated components or even
subassemblies feed into a final assembly line. Basically, each feeder line is
viewed as a “black box” whose output is read from a file.
• Option 3: Represent the output of one or more of the submodels as
statistical distributions. This approach is the same as option 2, but instead
of using the recorded output times from the submodel in the composite
model, a statistical distribution is fit to the output times and used to
generate the input to the composite model. This technique eliminates the
need for using data files that, depending on the submodel, may be quite
large. Theoretically, it should also be more accurate because the true
underlying distribution is used instead of just a sample unless there are
discontinuities in the output. Multiple sample streams can also be
generated for running multiple replications.

7.5.3 Cost Modeling

Often it is desirable to include cost in a model to determine the most cost-effective
solution to a design problem. If, for example, two operators on an assembly line re-
sult in the same performance as using three robots, the decision may end up being
based on cost rather than performance. There are two approaches to modeling cost.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 199

One is to include cost factors in the model itself and dynamically update cost col-
lection variables during the simulation. ProModel includes a cost module for as-
signing costs to different factors in the simulation such as entity cost, waiting cost,
and operation cost. The alternative approach is to run a cost analysis after the sim-
ulation, applying cost factors to collected cost drivers such as resource utilization
or time spent in storage. The first method is best when it is difficult to summarize
cost drivers. For example, the cost per unit of production may be based on the
types of resources used and the time for using each type. This may be a lot of in-
formation for each entity to carry using attributes. It is much easier to simply up-
date the entity’s cost attribute dynamically whenever a particular resource has
been used. Dynamic cost tracking suffers, however, from requiring cost factors to
be considered during the modeling stage rather than the analysis stage. For some
models, it may be difficult to dynamically track costs during a simulation, espe-
cially when relationships become very complex.
The preferred way to analyze costs, whenever possible, is to do a postsimula-
tion analysis and to treat cost modeling as a follow-on activity to system model-
ing rather than as a concurrent activity (see Lenz and Neitzel 1995). There are
several advantages to separating the logic model from the cost model. First, the
model is not encumbered with tracking information that does not directly affect
how the model operates. Second, and perhaps more importantly, post analysis of
costs gives more flexibility for doing “what-if” scenarios with the cost model. For
example, different cost scenarios can be run based on varying labor rates in a
matter of seconds when applied to simulation output data that are immediately
available. If modeled during the simulation, a separate simulation would have to
be run applying each labor rate.

7.6 Summary
Model building is a process that takes a conceptual model and converts it to a sim-
ulation model. This requires a knowledge of the modeling paradigm of the partic-
ular simulation software being used and a familiarity with the different modeling
constructs that are provided in the software. Building a model involves knowing
what elements to include in the model and how to best express those elements in
the model. The principle of parsimony should always be followed, which results
in the most minimal model possible that achieves the simulation objectives.
Finally, the keys to successful modeling are seeing lots of examples and practice,
practice, practice!

7.7 Review Questions

1. How is modeling an art as well as a science?
2. What is a modeling paradigm?
3. Describe the modeling paradigm used in a specific simulation product.
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

200 Part I Study Chapters

4. Suppose you were modeling an inspection station as an object. Identify

two attributes and one behavior you might want to define for it.
5. Identify five different things an entity might represent in a
manufacturing or service simulation.
6. For a manufacturing operation that produces 300 different part types,
how would you represent the different part types?
7. A stand and power cord are assembled to a monitor at an assembly
station. Stands are produced in-house and are not always available
when needed. Power cords are purchased finished and are always
available at the station. What entity types (monitor, cord, or stand)
would you include in the model and, conceptually, how would you
model this assembly operation?
8. Every hour, a stack of purchase orders is delivered to the purchasing
department for processing. The stack is routed sequentially to three
different people who review, approve, and send out the orders. The
orders move together as a stack, although they are processed individually
at each station. The processing time at each activity is a function of the
number of orders in the stack. The number of orders in a stack can be
determined by a probability distribution. Conceptually, how would you
model this process and still capture the essence of what is happening?
9. What criteria would you use to identify the route stops or locations in a
flow sequence to include in a model?
10. Suppose you are modeling a system with bins in which parts are
transported. Would you model the bins as resources or entities? Justify
your answer.
11. How would you model a consumable resource such as energy
consumption that occurs based on the length of time a particular
machine is in operation?
12. What is the danger of using simple time values to model material
movement if the material handling system often encounters traffic
delays?
13. How would you use an entity attribute to model multiple routing passes
through the same location in which a different operation time is
required depending on the pass?
14. An operator must inspect every fifth part at a manual workstation.
Conceptually, how would you model this activity if the operation takes
five minutes and inspection takes two minutes?
15. When attaching entities to another entity, under what circumstances
would you want to preserve the identities of the entities being attached?
16. Define four types of arrivals and give an example of each.
17. A factory operates with two eight-hour shifts (changeover occurs
without interruption) five days a week. If you wanted to simulate the
system for four weeks, how would you set the run length in hours?
Harrell−Ghosh−Bowden: I. Study Chapters 7. Model Building © The McGraw−Hill
Simulation Using Companies, 2004
ProModel, Second Edition

Chapter 7 Model Building 201

18. What is the problem with modeling downtimes in terms of mean time
between failures (MTBF) and mean time to repair (MTTR)?
19. Why should unplanned downtimes or failures be defined as a function
of usage time rather than total elapsed time on the clock?
20. In modeling repair times, how should the time spent waiting for a
repairperson be modeled?
21. What is preemption? What activities or events might preempt other
activities in a simulation?
22. A boring machine experiences downtimes every five hours
(exponentially distributed). It also requires routine preventive
maintenance (PM) after every eight hours (fixed) of operation. If a
downtime occurs within two hours of the next scheduled PM, the PM
is performed as part of the repair time (no added time is needed) and,
after completing the repair coupled with the PM, the next PM is set
for eight hours away. Conceptually, how would you model this
situation?
23. A real estate agent schedules six customers (potential buyers) each day,
one every 1.5 hours, starting at 8 A.M. Customers are expected to arrive
for their appointments at the scheduled times. However, past experience
shows that customer arrival times are normally distributed with a mean
equal to the scheduled time and a standard deviation of five minutes.
The time the agent spends with each customer is normally distributed
with a mean of 1.4 hours and a standard deviation of .2 hours. Develop a
simulation model to calculate the expected waiting time for customers.

References
Jayaraman, Arun, and Arun Agarwal. “Simulating an Engine Plant.” Manufacturing Engi-
neering, November 1996, pp. 60–68.
Law, A. M. “Introduction to Simulation: A Powerful Tool for Analyzing Complex Manu-
facturing Systems.” Industrial Engineering, 1986, 18(5):57–58.
Lenz, John, and Ray Neitzel. “Cost Modeling: An Effective Means to Compare Alterna-
tives.” Industrial Engineering, January 1995, pp. 18–20.
Shannon, Robert E. “Introduction to the Art and Science of Simulation.” In Proceedings of
the 1998 Winter Simulation Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson,
and M. S. Manivannan. Piscataway, NJ: Institute of Electrical and Electronics
Engineers, 1998.
Thompson, Michael B. “Expanding Simulation beyond Planning and Design.” Industrial
Engineering, October 1994, pp. 64–66.