FV609-Simulation Using ProModel - Charles Harrell
FV609-Simulation Using ProModel - Charles Harrell
FV609-Simulation Using ProModel - Charles Harrell
SIMULATION USING
PROMODEL
TM
www.mhhe.com
Charles Harrell
Charles Harrell is an associate professor of engineering and technology at Brigham
Young University and founder of PROMODEL Corporation. He received his
B.S. from Brigham Young University, M.S. in industrial engineering from the
University of Utah, and Ph.D. in manufacturing engineering from the Techni-
cal University of Denmark. His area of interest and expertise is in manufactur-
ing system design and simulation. He has worked in manufacturing and systems
engineering positions for Ford Motor Company and the Eaton Corporation. At
BYU he teaches courses in manufacturing systems, manufacturing simulation,
and manufacturing information systems. He is the author or coauthor of several
simulation books and has given numerous presentations on manufacturing system
design and simulation. He serves on the board of directors of PROMODEL Cor-
poration. He is a senior member of IIE and SME. He enjoys sports and playing
with his grandchildren.
Biman K. Ghosh
Biman K. Ghosh is a professor of industrial and manufacturing engineering at
the California State Polytechnic University, Pomona. He has been teaching and
consulting all over the United States for the past 25 years. Prior to that Dr. Ghosh
worked for such multinational companies as Tata, Mercedes Benz, Sandvik, and
Siemens. Dr. Ghosh has been a consultant to Northrop Grumman, McDonnell
Douglas, Boeing, Rockwell, Loral, Visteon, UPS, Sikorsky, Baxter, Paccar, John-
son Controls, Powersim, and Galorath. Dr. Ghosh has published extensively. His
teaching and consulting interests are in the areas of simulation, supply chain man-
agement, lean manufacturing, flexible manufacturing, cellular manufacturing,
computer-aided manufacturing, design for manufacturing, design of experiments,
total quality management, and work measurement. His passion is still and video
photography.
Royce O. Bowden
Royce Bowden is professor and head of Industrial and Systems Engineering
at Mississippi State University. Prior to joining Mississippi State, Dr. Bowden
worked in manufacturing engineering positions with Texas Instruments and Martin
Marietta Aerospace. His research program centers on the use, development, and
integration of simulation, artificial intelligence, and statistical techniques to solve
systems engineering problems and has been funded by organizations such as the
National Science Foundation, United States Department of Transportation, and
the National Space and Aeronautics Administration. Dr. Bowden’s research pro-
vided the foundation for the first widely used commercial simulation optimization
software. He is the author (or coauthor) of numerous research papers and two
simulation books. Dr. Bowden serves on the executive board of the Boy Scouts
of America Pushmataha Area Council and enjoys organizing and participating in
high adventure outdoor programs for the youth.
iv
PART I
STUDY CHAPTERS
1 Introduction to Simulation 3
2 System Dynamics 33
3 Simulation Basics 57
4 Discrete-Event Simulation 87
5 Data Collection and Analysis 115
6 Model Building 161
7 Model Verification and Validation 193
8 Simulation Output Analysis 211
9 Comparing Systems 243
10 Simulation Optimization 273
11 Modeling Manufacturing Systems 299
12 Modeling Material Handling Systems 323
13 Modeling Service Systems 345
PART II
LABS
1 Introduction to ProModel 365
2 Building Your First Model 379
3 ProModel’s Output Viewer 405
4 Basic Modeling Concepts 419
5 Fitting Statistical Distributions to Input Data 465
6 Intermediate Model Building 475
7 Model Verification and Validation 517
8 Simulation Output Analysis 527
9 Comparing Alternative Systems 549
10 Simulation Optimization with SimRunner 569
11 Modeling Manufacturing Systems 595
12 Material Handling Concepts 617
13 Modeling Service Systems 639
Appendix A Continuous and Discrete Distributions in ProModel 669
Appendix B Critical Values for Student’s t Distribution and Standard
Normal Distribution 674
Appendix C F Distribution for ␣ ⫽ 0.05 675
Appendix D Critical Values for Chi-Square Distribution 676
Index 677
McGraw-Hill offers this text as an ebook. To talk about the ebook options,
contact your McGraw-Hill sales rep or visit the site www.coursesmart.com to
learn more.
Online Supplements
In addition to the printed text, numerous supplemental materials are available
on the McGraw-Hill Web site at www.mhhe.com/harrell3e. These include case
studies, PowerPoint slides and ProModel software downloads. The case studies
are taken mostly from actual scenarios that can be assigned as simulation proj-
ects. They are intended as capstone experiences to give students an opportunity to
bring together what they have learned in the course to solve a real-life problem.
McGraw-Hill Create™
Craft your teaching resources to match the way you teach! With McGraw-Hill
Create™, www.mcgrawhillcreate.com, you can easily rearrange chapters, com-
bine material from other content sources, and quickly upload content you have
written like your course syllabus or teaching notes. Find the content you need
in Create by searching through thousands of leading McGraw-Hill textbooks.
Arrange your book to fit your teaching style. Create even allows you to personal-
ize your book’s appearance by selecting the cover and adding your name, school,
and course information. Order a Create book and you’ll receive a complimentary
print review copy in 3–5 business days or a complimentary electronic review
copy (eComp) via email in minutes. Go to www.mcgrawhillcreate.com today and
register to experience how McGraw-Hill Create™ empowers you to teach your
students your way.
I STUDY CHAPTERS
Chapters
1 Introduction to Simulation 3
2 System Dynamics 33
3 Simulation Basics 57
4 Discrete-Event Simulation 87
5 Data Collection and Analysis 115
6 Model Building 161
7 Model Verification and Validation 193
8 Simulation Output Analysis 211
9 Comparing Systems 243
10 Simulation Optimization 273
11 Modeling Manufacturing Systems 299
12 Modeling Material Handling Systems 323
13 Modeling Service Systems 345
1 INTRODUCTION
TO SIMULATION
“Man is a tool using animal. . . . Without tools he is nothing, with tools he is all.”
—Thomas Carlyle
1.1 Introduction
On March 19, 1999, the following story appeared in The Wall Street Journal:
Captain Chet Rivers knew that his 747-400 was loaded to the limit. The giant plane,
weighing almost 450,000 pounds by itself, was carrying a full load of passengers
and baggage, plus 400,000 pounds of fuel for the long flight from San Francisco
to Australia. As he revved his four engines for takeoff, Capt. Rivers noticed that
San Francisco’s famous fog was creeping in, obscuring the hills to the north and west
of the airport.
At full throttle the plane began to roll ponderously down the runway, slowly at first
but building up to flight speed well within normal limits. Capt. Rivers pulled the throt-
tle back and the airplane took to the air, heading northwest across the San Francisco
peninsula towards the ocean. It looked like the start of another routine flight. Sud-
denly the plane began to shudder violently. Several loud explosions shook the craft
and smoke and flames, easily visible in the midnight sky, illuminated the right wing.
Although the plane was shaking so violently that it was hard to read the instruments,
Capt. Rivers was able to tell that the right inboard engine was malfunctioning, back-
firing violently. He immediately shut down the engine, stopping the explosions and
shaking.
However this introduced a new problem. With two engines on the left wing at
full power and only one on the right, the plane was pushed into a right turn, bringing
it directly towards San Bruno Mountain, located a few miles northwest of the air-
port. Capt. Rivers instinctively turned his control wheel to the left to bring the plane
back on course. That action extended the ailerons—control surfaces on the trailing
edges of the wings—to tilt the plane back to the left. However, it also extended the
spoilers—panels on the tops of the wings—increasing drag and lowering lift. With
the nose still pointed up, the heavy jet began to slow. As the plane neared stall speed,
the control stick began to shake to warn the pilot to bring the nose down to gain air
speed. Capt. Rivers immediately did so, removing that danger, but now San Bruno
Mountain was directly ahead. Capt. Rivers was unable to see the mountain due to
the thick fog that had rolled in, but the plane’s ground proximity sensor sounded
an automatic warning, calling “terrain, terrain, pull up, pull up.” Rivers frantically
pulled back on the stick to clear the peak, but with the spoilers up and the plane still
in a skidding right turn, it was too late. The plane and its full load of 100 tons of fuel
crashed with a sickening explosion into the hillside just above a densely populated
housing area.
“Hey Chet, that could ruin your whole day,” said Capt. Rivers’s supervisor, who
was sitting beside him watching the whole thing. “Let’s rewind the tape and see what
you did wrong.” “Sure Mel,” replied Chet as the two men stood up and stepped out-
side the 747 cockpit simulator. “I think I know my mistake already. I should have used
my rudder, not my wheel, to bring the plane back on course. Say, I need a breather
after that experience. I’m just glad that this wasn’t the real thing.”
The incident above was never reported in the nation’s newspapers, even though
it would have been one of the most tragic disasters in aviation history, because it
never really happened. It took place in a cockpit simulator, a device which uses com-
puter technology to predict and recreate an airplane’s behavior with gut-wrenching
realism.
The relief you undoubtedly felt to discover that this disastrous incident
was just a simulation gives you a sense of the impact that simulation can have
in averting real-world catastrophes. This story illustrates just one of the many
ways simulation is being used to help minimize the risk of making costly and
sometimes fatal mistakes in real life. Simulation technology is finding its way
into an increasing number of applications ranging from training for aircraft pi-
lots to the testing of new product prototypes. The one thing that these applica-
tions have in common is that they all provide a virtual environment that helps
prepare for real-life situations, resulting in significant savings in time, money,
and even lives.
One area where simulation is finding increased application is in manufactur-
ing and service system design and improvement. Its unique ability to accurately
predict the performance of complex systems makes it ideally suited for systems
planning. Just as a flight simulator reduces the risk of making costly errors in
actual flight, system simulation reduces the risk of having systems that operate
inefficiently or that fail to meet minimum performance requirements. While this
may not be life-threatening to an individual, it certainly places a company (not to
mention careers) in jeopardy.
In this chapter we introduce the topic of simulation and answer the following
questions:
• What is simulation?
• Why is simulation used?
• How is simulation performed?
• When and where should simulation be used?
FIGURE 1.1
Simulation provides animation capability.
The power of simulation lies in the fact that it provides a method of analysis
that is not only formal and predictive, but is capable of accurately predicting the
performance of even the most complex systems. Deming (1989) states, “Man-
agement of a system is action based on prediction. Rational prediction requires
systematic learning and comparisons of predictions of short-term and long-term
results from possible alternative courses of action.” The key to sound manage-
ment decisions lies in the ability to accurately predict the outcomes of alterna-
tive courses of action. Simulation provides precisely that kind of foresight. By
simulating alternative production schedules, operating policies, staffing levels,
job priorities, decision rules, and the like, a manager can more accurately predict
outcomes and therefore make more informed and effective management deci-
sions. With the importance in today’s competitive market of “getting it right the
first time,” the lesson is becoming clear: if at first you don’t succeed, you probably
should have simulated it.
By using a computer to model a system before it is built or to test operating
policies before they are actually implemented, many of the pitfalls that are often
encountered in the start-up of a new system or the modification of an existing
system can be avoided. Improvements that traditionally took months and even
years of fine-tuning to achieve can be attained in a matter of days or even hours.
Because simulation runs in compressed time, weeks of system operation can be
simulated in only a few minutes or even seconds. The characteristics of simula-
tion that make it such a powerful planning and decision-making tool can be sum-
marized as follows:
• Captures system interdependencies.
• Accounts for variability in the system.
• Is versatile enough to model any system.
• Shows behavior over time.
• Is less costly, time consuming, and disruptive than experimenting on the
actual system.
• Provides information on multiple performance measures.
• Is visually appealing and engages people’s interest.
• Provides results that are easy to understand and communicate.
• Runs in compressed, real, or even delayed time.
• Forces attention to detail in a design.
Because simulation accounts for interdependencies and variation, it provides
insights into the complex dynamics of a system that cannot be obtained using
(Shannon 1998). Conducting experiments on a model reduces the time, cost, and
disruption of experimenting on the actual system. In this respect, simulation can
be thought of as a virtual prototyping tool for demonstrating proof of concept.
The procedure for doing simulation follows the scientific method of (1) for-
mulating a hypothesis, (2) setting up an experiment, (3) testing the hypothesis
through experimentation, and (4) drawing conclusions about the validity of the
hypothesis. In simulation, we formulate a hypothesis about what design or operat-
ing policies work best. We then set up an experiment in the form of a simulation
model to test the hypothesis. With the model, we conduct multiple replications of
the experiment or simulation. Finally, we analyze the simulation results and draw
conclusions about our hypothesis. If our hypothesis was correct, we can confi-
dently move ahead in making the design or operational changes (assuming time
and other implementation constraints are satisfied). As shown in Figure 1.2, this
process is repeated until we are satisfied with the results.
By now it should be obvious that simulation itself is not a solution tool but
rather an evaluation tool. It describes how a defined system will behave; it does
FIGURE 1.2
The process Start
of simulation
experimentation.
Formulate a
hypothesis
Develop a
simulation model
No
Run simulation
experiment
Hypothesis
correct?
Yes
End
not prescribe how it should be designed. Simulation doesn’t compensate for one’s
ignorance of how a system is supposed to operate. Neither does it excuse one from
being careful and responsible in the handling of input data and the interpretation
of output results. Rather than being perceived as a substitute for thinking, simula-
tion should be viewed as an extension of the mind that enables one to understand
the complex dynamics of a system.
not very useful in solving qualitative problems such as those involving technical
or sociological issues. For example, it can’t tell you how to improve machine
reliability or how to motivate workers to do a better job (although it can assess
the impact that a given level of reliability or personal performance can have on
overall system performance). Qualitative issues such as these are better addressed
using other engineering and behavioral science techniques.
Processes should be well defined and repetitive. Simulation is useful only
if the process being modeled is well structured and repetitive. If the process
doesn’t follow a logical sequence and adhere to defined rules, it may be difficult
to model. Simulation applies only if you can describe how the process operates.
This does not mean that there can be no uncertainty in the system. If random
behavior can be described using probability expressions and distributions, they
can be simulated. It is only when it isn’t even possible to make reasonable as-
sumptions of how a system operates (because either no information is available
or behavior is totally erratic) that simulation (or any other analysis tool for that
matter) becomes useless. Likewise, one-time projects or processes that are never
repeated the same way twice are poor candidates for simulation. If the scenario
you are modeling is likely never going to happen again, it is of little benefit to
do a simulation.
Activities and events should be interdependent and variable. A system
may have lots of activities, but if they never interfere with each other or are
deterministic (that is, they have no variation), then using simulation is prob-
ably unnecessary. It isn’t the number of activities that makes a system difficult
to analyze. It is the number of interdependent, random activities. The effect
of simple interdependencies is easy to predict if there is no variability in the
activities. Determining the flow rate for a system consisting of 10 processing
activities is very straightforward if all activity times are constant and activities
are never interrupted. Likewise, random activities that operate independently
of each other are usually easy to analyze. For example, 10 machines operating
in isolation from each other can be expected to produce at a rate that is based
on the average cycle time of each machine less any anticipated downtime.
It is the combination of interdependencies and random behavior that really
produces the unpredictable results. Simpler analytical methods such as math-
ematical calculations and spreadsheet software become less adequate as the
number of activities that are both interdependent and random increases. For
this reason, simulation is primarily suited to systems involving both interde-
pendencies and variability.
The cost impact of the decision should be greater than the cost of doing the
simulation. Sometimes the impact of the decision itself is so insignificant that it
doesn’t warrant the time and effort to conduct a simulation. Suppose, for example,
you are trying to decide whether a worker should repair rejects as they occur or
wait until four or five accumulate before making repairs. If you are certain that
the next downstream activity is relatively insensitive to whether repairs are done
sooner rather than later, the decision becomes inconsequential and simulation is a
wasted effort.
The cost to experiment on the actual system should be greater than the cost
of simulation. While simulation avoids the time delay and cost associated with
experimenting on the real system, in some situations it may actually be quicker
and more economical to experiment on the real system. For example, the decision
in a customer mailing process of whether to seal envelopes before or after they
are addressed can easily be made by simply trying each method and comparing
the results. The rule of thumb here is that if a question can be answered through
direct experimentation quickly, inexpensively, and with minimal impact to the
current operation, then don’t use simulation. Experimenting on the actual system
also eliminates some of the drawbacks associated with simulation, such as prov-
ing model validity.
There may be other situations where simulation is appropriate independent
of the criteria just listed (see Banks and Gibson 1997). This is certainly true in the
case of models built purely for visualization purposes. If you are trying to sell a
system design or simply communicate how a system works, a realistic animation
created using simulation can be very useful, even though nonbeneficial from an
analysis point of view.
prevent one from using simulation within the realm of one’s expertise. There
are both a basic as well as an advanced level at which simulation can be benefi-
cially used. Rough-cut modeling to gain fundamental insights, for example, can
be achieved with only a rudimentary understanding of simulation. One need not
have extensive simulation training to go after the low-hanging fruit. Simulation
follows the 80–20 rule, where 80 percent of the benefit can be obtained from
knowing only 20 percent of the science involved (just make sure you know the
right 20 percent). It isn’t until more precise analysis is required that additional
statistical training and knowledge of experimental design are needed.
To reap the greatest benefits from simulation, a certain degree of knowledge
and skill in the following areas is useful:
• Project management.
• Communication.
• Systems engineering.
• Statistical analysis and design of experiments.
• Modeling principles and concepts.
• Basic programming and computer skills.
• Training on one or more simulation products.
• Familiarity with the system being investigated.
Experience has shown that some people learn simulation more rapidly
and become more adept at it than others. People who are good abstract think-
ers yet also pay close attention to detail seem to be the best suited for doing
simulation. Such individuals are able to see the forest while still keeping an
eye on the trees (these are people who tend to be good at putting together
1,000-piece puzzles). They are able to quickly scope a project, gather the
pertinent data, and get a useful model up and running without lots of starts
and stops. A good modeler is somewhat of a sleuth, eager yet methodical and
discriminating in piecing together all of the evidence that will help put the
model pieces together.
If short on time, talent, resources, or interest, the decision maker need not
despair. Plenty of consultants who are professionally trained and experienced can
provide simulation services. A competitive bid will help get the best price, but one
should be sure that the individual assigned to the project has good credentials. If
the use of simulation is only occasional, relying on a consultant may be the pre-
ferred approach.
FIGURE 1.3
Iterative nature Define objective
of simulation. and plan study
Collect and
analyze system
data
Build model
Validate model
Conduct
experiments
Present
results
than it consumes. It is true that the initial investment, including training and start-
up costs, may be between $10,000 and $30,000 (simulation products themselves
generally range between $1,000 and $20,000). However, this cost is often recov-
ered after the first one or two projects. The ongoing expense of using simulation
for individual projects is estimated to be between 1 and 3 percent of the total
project cost (Glenney and Mackulak 1985). With respect to the time commitment
involved in doing simulation, much of the effort that goes into building the model
is in arriving at a clear definition of how the system operates, which needs to be
done anyway. With the advanced modeling tools that are now available, the actual
model development and running of simulations take only a small fraction (often
less than 5 percent) of the overall system design time.
Savings from simulation are realized by identifying and eliminating problems
and inefficiencies that would have gone unnoticed until system implementation.
Cost is also reduced by eliminating overdesign and removing excessive safety
factors that are added when performance projections are uncertain. By identifying
and eliminating unnecessary capital investments, and discovering and correcting
operating inefficiencies, it is not uncommon for companies to report hundreds of
thousands of dollars in savings on a single project through the use of simulation.
The return on investment (ROI) for simulation often exceeds 1,000 percent, with
payback periods frequently being only a few months or the time it takes to com-
plete a simulation project.
One of the difficulties in developing an economic justification for simulation
is the fact that it is usually not known in advance how much savings will be real-
ized until it is actually used. Most applications in which simulation has been used
have resulted in savings that, had the savings been known in advance, would have
looked very good in an ROI or payback analysis.
One way to assess in advance the economic benefit of simulation is to assess
the risk of making poor design and operational decisions. One need only ask what
the potential cost would be if a misjudgment in systems planning were to occur.
Suppose, for example, that a decision is made to add another machine to solve a
capacity problem in a production or service system. What are the cost and prob-
ability associated with this being the wrong decision? If the cost associated with
a wrong decision is $100,000 and the decision maker is only 70 percent confident
that the decision is correct, then there is a 30 percent chance of incurring a cost of
$100,000. This results in a probable cost of $30,000 (.3 ⫻ $100,000). Using this
approach, many decision makers recognize that they can’t afford not to use simu-
lation because the risk associated with making the wrong decision is too high.
Tying the benefits of simulation to management and organizational goals
also provides justification for its use. For example, a company committed to con-
tinuous improvement or, more specifically, to lead time or cost reduction can be
sold on simulation if it can be shown to be historically effective in these areas.
Simulation has gained the reputation as a best practice for helping companies
achieve organizational goals. Companies that profess to be serious about per-
formance improvement will invest in simulation if they believe it can help them
achieve their goals.
Cost
System stage
FIGURE 1.5
Comparison of
Cost without
cumulative system
simulation
costs with and without
System costs
simulation.
Cost with
simulation
The real savings from simulation come from allowing designers to make mis-
takes and work out design errors on the model rather than on the actual system.
The concept of reducing costs through working out problems in the design phase
rather than after a system has been implemented is best illustrated by the rule of
tens. This principle states that the cost to correct a problem increases by a factor
of 10 for every design stage through which it passes without being detected (see
Figure 1.4).
Simulation helps avoid many of the downstream costs associated with poor
decisions that are made up front. Figure 1.5 illustrates how the cumulative cost
resulting from systems designed using simulation can compare with the cost of
designing and operating systems without the use of simulation. Note that while
the short-term cost may be slightly higher due to the added labor and software
costs associated with simulation, the long-term costs associated with capital in-
vestments and system operation are considerably lower due to better efficien-
cies realized through simulation. Dismissing the use of simulation on the basis
of sticker price is myopic and shows a lack of understanding of the long-term
savings that come from having well-designed, efficiently operating systems.
Many examples can be cited to show how simulation has been used to avoid
costly errors in the start-up of a new system. Simulation prevented an unnecessary
expenditure when a Fortune 500 company was designing a facility for produc-
ing and storing subassemblies and needed to determine the number of containers
required for holding the subassemblies. It was initially felt that 3,000 containers
were needed until a simulation study showed that throughput did not improve sig-
nificantly when the number of containers was increased from 2,250 to 3,000. By
purchasing 2,250 containers instead of 3,000, a savings of $528,375 was expected
in the first year, with annual savings thereafter of over $200,000 due to the savings
in floor space and storage resulting from having 750 fewer containers (Law and
McComas 1988).
Even if dramatic savings are not realized each time a model is built, simula-
tion at least inspires confidence that a particular system design is capable of meet-
ing required performance objectives and thus minimizes the risk often associated
with new start-ups. The economic benefit associated with instilling confidence
was evidenced when an entrepreneur, who was attempting to secure bank financ-
ing to start a blanket factory, used a simulation model to show the feasibility of
the proposed factory. Based on the processing times and equipment lists supplied
by industry experts, the model showed that the output projections in the business
plan were well within the capability of the proposed facility. Although unfamiliar
with the blanket business, bank officials felt more secure in agreeing to support
the venture (Bateman et al. 1997).
Often simulation can help improve productivity by exposing ways of making
better use of existing assets. By looking at a system holistically, long-standing
problems such as bottlenecks, redundancies, and inefficiencies that previously
went unnoticed start to become more apparent and can be eliminated. “The trick
is to find waste, or muda,” advises Shingo; “after all, the most damaging kind of
waste is the waste we don’t recognize” (Shingo 1992). Consider the following ac-
tual examples where simulation helped uncover and eliminate wasteful practices:
• GE Nuclear Energy was seeking ways to improve productivity without
investing large amounts of capital. Through the use of simulation, the
company was able to increase the output of highly specialized reactor
parts by 80 percent. The cycle time required for production of each part
was reduced by an average of 50 percent. These results were obtained
by running a series of models, each one solving production problems
highlighted by the previous model (Bateman et al. 1997).
• A large manufacturing company with stamping plants located throughout
the world produced stamped aluminum and brass parts on order according
to solve real-world problems. Review questions at the end of each chapter help
reinforce the concepts presented.
Part II contains ProModel lab exercises that help develop simulation skills.
ProModel is a simulation package designed specifically for ease of use, yet it
provides the flexibility to model any discrete event or continuous flow process.
It is similar to other simulation products in that it provides a set of basic model-
ing constructs and a language for defining the logical decisions that are made in
a system. Basic modeling objects in ProModel include entities (the objects being
processed), locations (the places where processing occurs), resources (the agents
used to process the entities), and paths (the course of travel for entities and re-
sources in moving between locations such as aisles or conveyors). Logical behav-
ior such as the way entities arrive and their routings can be defined with little, if
any, programming using the data entry tables that are provided. ProModel is used
by thousands of professionals in manufacturing and service-related industries and
is taught in hundreds of institutions of higher learning.
It is recommended that students be assigned at least one simulation project
during the course. Preferably this is a project performed for a nearby company
or institution so it will be meaningful. If such a project cannot be found, or as
an additional practice exercise. An assortment of case problems are posted on
the McGraw-Hill Website (www.mhhe.com/harrell3e) that can be assigned. Stu-
dent projects should be selected early in the course so that data gathering can get
started and the project completed within the allotted time. The chapters in Part I
are sequenced to parallel an actual simulation project.
1.12 Summary
Businesses today face the challenge of quickly designing and implementing complex
production and service systems that are capable of meeting growing demands for
quality, delivery, affordability, and service. With recent advances in computing and
software technology, simulation tools are now available to help meet this challenge.
Simulation is a powerful technology that is being used with increasing frequency to
improve system performance by providing a way to make better design and manage-
ment decisions. When used properly, simulation can reduce the risks associated with
starting up a new operation or making improvements to existing operations.
Because simulation accounts for interdependencies and variability, it pro-
vides insights that cannot be obtained any other way. Where important system
decisions are being made of an operational nature, simulation is an invaluable
decision-making tool. Its usefulness increases as variability and interdependency
increase and the importance of the decision becomes greater.
Lastly, simulation actually makes designing systems fun! Not only can a
designer try out new design concepts to see what works best, but the visualiza-
tion makes it take on a realism that is like watching an actual system in operation.
Through simulation, decision makers can play what-if games with a new system
or modified process before it actually gets implemented. This engaging process
stimulates creative thinking and leads to good design decisions.
18. For each of the following systems, define one possible simulation
objective:
a. A manufacturing cell.
b. A fast-food restaurant.
c. An emergency room of a hospital.
d. A tire distribution center.
e. A public bus transportation system.
f. A post office.
g. A bank of elevators in a high-rise office building.
h. A time-shared, multitasking computer system consisting of a server,
many slave terminals, a high-speed disk, and a processor.
i. A rental car agency at a major airport.
CASE STUDY A
AST COMPUTES BIG BENEFITS USING SIMULATION
John Perry
Manufacturing Engineer
In the world of computer manufacturing and assembly, success is measured in terms of sec-
onds. The PC business poses some unique challenges: it is intensely competitive with thin
profit margins and is characterized by constantly changing technologies and products. The
race is to excel in rapid delivery to the marketplace through high-velocity manufacturing.
A manufacturer that can minimize the time needed to assemble a computer, move nimbly
to respond to change, and get maximum productivity out of its capital investment has an
edge. At AST Research, we use computer simulation to realize these goals and, so far, have
achieved significant benefits. The application area, which is product assembly, is an area
where almost anyone can benefit from the use of simulation.
The Problem
AST Research Inc., founded in 1980, has become a multibillion-dollar PC manufacturer.
We assemble personal computers and servers in Fort Worth, Texas, and offshore. For a
long time, we “optimized” (planned) our assembly procedures using traditional methods—
gathering time-and-motion data via stopwatches and videotape, performing simple arith-
metic calculations to obtain information about the operation and performance of the
assembly line, and using seat-of-the-pants guesstimates to “optimize” assembly line output
and labor utilization.
The Model
In December 1994 a new vice president joined AST. Management had long been commit-
ted to increasing the plant’s efficiency and output, and our new vice president had experi-
ence in using simulation to improve production. We began using ProModel simulation
as a tool for optimizing our assembly lines, and to improve our confidence that changes
proposed in the assembly process would work out in practice. The results have been sig-
nificant. They include
• Reduced labor input to each unit.
• Shortened production cycle times.
• Reduced reject rate.
• Increased ability to change assembly instructions quickly when changes become
necessary.
Now when we implement changes, we are confident that those changes in fact will improve
things.
The first thing we did was learn how to use the simulation software. Then we attempted
to construct a model of our current operations. This would serve two important functions: it
would tell us whether we really understood how to use the software, and it would validate
our understanding of our own assembly lines. If we could not construct a model of our
assembly line that agreed with the real one, that would mean that there was a major flaw
either in our ability to model the system or in our understanding of our own operations.
Building a model of our own operations sounded simple enough. After all, we had an
exhaustive catalog of all the steps needed to assemble a computer, and (from previous data
collection efforts) information on how long each operation took. But building a model
that agreed with our real-world situation turned out to be a challenging yet tremendously
educational activity.
For example, one of our early models showed that we were producing several thousand
units in a few hours. Since we were not quite that good—we were off by at least a factor
of 10—we concluded that we had a major problem in the model we had built, so we went
back to study things in more detail. In every case, our early models failed because we had
overlooked or misunderstood how things actually worked on our assembly lines.
Eventually, we built a model that worked and agreed reasonably well with our real-
world system out in the factory. To make use of the model, we generated ideas that we
thought would cut down our assembly time and then simulated them in our model.
We examined a number of changes proposed by our engineers and others, and then
simulated the ones that looked most promising. Some proposed changes were counter-
productive according to our simulation results. We also did a detailed investigation of our
testing stations to determine whether it was more efficient to move computers to be tested
into the testing station via FIFO (first-in, first-out) or LIFO (last-in, first-out). Modeling
showed us that FIFO was more efficient. When we implemented that change, we realized
the gain we had predicted.
Simulation helped us avoid buying more expensive equipment. Some of our material-
handling specialists predicted, based on their experience, that if we increased throughput
by 30 percent, we would have to add some additional, special equipment to the assembly
floor or risk some serious blockages. Simulation showed us that was not true and in prac-
tice the simulation turned out to be correct.
We determined that we could move material faster if we gave material movers a specific
pattern to follow instead of just doing things sequentially. For example, in moving certain
items from our testing area, we determined that the most time-efficient way would be to
move shelf 1 first, followed by shelf 4, then shelf 3, and so on.
After our first round of making “serious” changes to our operation and simulating them,
our actual production was within a few percentage points of our predicted production.
Also, by combining some tasks, we were able to reduce our head count on each assembly
line significantly.
We have completed several rounds of changes, and today, encouraged by the experience
of our new investor, Samsung, we have made a significant advance that we call Vision 5.
The idea of Vision 5 is to have only five people in each cell assembling computers. Although
there was initially some skepticism about whether this concept would work, our simulations
showed that it would, so today we have converted one of our “focused factories” to this
concept and have experienced additional benefits. Seeing the benefits from that effort has
caused our management to increase its commitment to simulation.
The Results
Simulation has proven its effectiveness at AST Research. We have achieved a number of
useful, measurable goals. For competitive reasons, specific numbers cannot be provided;
however, in order of importance, the benefits we have achieved are
• Reduced the reject rate.
• Reduced blockage by 25 percent.
• Increased operator efficiency by 20 percent.
• Increased overall output by 15 percent.
• Reduced the labor cost of each computer.
Other benefits included increased ability to explain and justify proposed changes to
management through the use of the graphic animation. Simulation helped us make fewer
missteps in terms of implementing changes that could have impaired our output. We were
able to try multiple scenarios in our efforts to improve productivity and efficiency at com-
paratively low cost and risk. We also learned that the best simulation efforts invite partici-
pation by more disciplines in the factory, which helps in terms of team-building. All of
these benefits were accomplished at minimal cost. These gains have also caused a cultural
shift at AST, and because we have a tool that facilitates production changes, the company
is now committed to continuous improvement of our assembly practices.
Our use of simulation has convinced us that it produces real, measurable results—and
equally important, it has helped us avoid making changes that we thought made common
sense, but when simulated turned out to be ineffective. Because of that demonstrable pay-
off, simulation has become a key element of our toolkit in optimizing production.
Questions
1. What were the objectives for using simulation at AST?
2. Why was simulation better than the traditional methods they were using to achieve
these objectives?
3. What common-sense solution was disproved by using simulation?
4. What were some of the unexpected side benefits from using simulation?
5. What insights on the use of simulation did you gain from this case study?
CASE STUDY B
DURHAM REGIONAL HOSPITAL SAVES $150,000
ANNUALLY USING SIMULATION TOOLS
Bonnie Lowder
Management Engineer, Premier
Durham Regional Hospital, a 450-bed facility located in Durham, North Carolina, has been
serving Durham County for 25 years. This public, full-service, acute-care facility is facing
the same competition that is now a part of the entire health care industry. With that in mind,
Durham Regional Hospital is making a conscious effort to provide the highest quality of
care while also controlling costs.
To assist with cost control efforts, Durham Regional Hospital uses Premier’s Customer-
Based Management Engineering program. Premier’s management engineers are very
involved with the hospital’s reengineering and work redesign projects. Simulation is one
of the tools the management engineers use to assist in the redesign of hospital services and
processes. Since the hospital was preparing to add an outpatient services area that was to
open in May 1997, a MedModel simulation project was requested by Durham Regional
Hospital to see how this Express Services area would impact their other outpatient areas.
This project involved the addition of an outpatient Express Services addition. The
Express Services area is made up of two radiology rooms, four phlebotomy lab stations, a
patient interview room, and an EKG room. The model was set up to examine which kind of
patients would best be serviced in that area, what hours the clinic would operate, and what
staffing levels would be necessary to provide optimum care.
The Model
Data were collected from each department with potential Express Services patients.
The new Express Services area would eliminate the current reception desk in the main
radiology department; all radiology outpatients would have their order entry at Express
Services. In fiscal year 1996, the radiology department registered 21,159 outpatients. Of
those, one-third could have had their procedure performed in Express Services. An aver-
age of 18 outpatient surgery patients are seen each week for their preadmission testing. All
these patients could have their preadmission tests performed in the Express Services area.
The laboratory sees approximately 14 walk-in phlebotomy patients per week. Of those,
10 patients are simple collections and 4 are considered complex. The simple collections
can be performed by anyone trained in phlebotomy. The complex collections should be
done by skilled lab personnel. The collections for all of these patients could be performed
in Express Services. Based on the data, 25 patients a day from the Convenient Care Clinic
will need simple X rays and could also use the Express Services area. Procedure times for
each patient were determined from previous data collection and observation.
The model was built in two months. Durham Regional Hospital had used simulation in
the past for both Emergency Department and Ambulatory Care Unit redesign projects and
thus the management team was convinced of its efficacy. After the model was completed,
it was presented to department managers from all affected areas. The model was presented
to the assembled group in order to validate the data and assumptions. To test for validity,
the model was run for 30 replications, with each replication lasting a period of two weeks.
The results were measured against known values.
The Results
The model showed that routing all Convenient Care Clinic patients through Express Ser-
vices would create a bottleneck in the imaging rooms. This would create unacceptable
wait times for the radiology patients and the Convenient Care patients. Creating a model
scenario where Convenient Care patients were accepted only after 5:00 P.M. showed that
the anticipated problem could be eliminated. The model also showed that the weekend
volume would be very low. Even at minimum staffing levels, the radiology technicians
and clerks would be underutilized. The recommendation was made to close the Express
Services area on the weekends. Finally, the model showed that the staffing levels could be
lower than had been planned. For example, the workload for the outpatient lab tech drops
off after 6:00 P.M. The recommendation was to eliminate outpatient lab techs after 6:00 P.M.
Further savings could be achieved by cross-training the radiology technicians and pos-
sibly the clerks to perform simple phlebotomy. This would also provide for backup during
busy times. The savings for the simulation efforts were projected to be $148,762 annu-
ally. These savings were identified from the difference in staffing levels initially requested
for Express Services and the levels that were validated after the simulation model results
were analyzed, as well as the closing of the clinic on weekends. This model would also be
used in the future to test possible changes to Express Services. Durham Regional Hospital
would be able to make minor adjustments to the area and visualize the outcome before
implementation. Since this was a new area, they would also be able to test minor changes
before the area was opened.
The results of the model allowed the hospital to avoid potential bottlenecks in the
radiology department, reduce the proposed staffing levels in the Express Services area, and
validate that the clinic should be closed on weekends. As stated by Dottie Hughes, director
of Radiology Services: “The simulation model allowed us to see what changes needed to
be made before the area is opened. By making these changes now, we anticipate a shorter
wait time for our patients than if the simulation had not been used.” The simulation results
were able to show that an annual savings of $148,762 could be expected by altering some
of the preconceived Express Services plan.
Future Applications
Larry Suitt, senior vice president, explains, “Simulation has proved to be a valuable tool for
our hospital. It has allowed us to evaluate changes in processes before money is spent on
construction. It has also helped us to redesign existing services to better meet the needs of
our patients.” Durham Regional Hospital will continue to use simulation in new projects to
improve its health care processes. The hospital is responsible for the ambulance service for
the entire county. After the 911 call is received, the hospital’s ambulance service picks up
the patient and takes him or her to the nearest hospital. Durham Regional Hospital is plan-
ning to use simulation to evaluate how relocating some of the ambulances to other stations
will affect the response time to the 911 calls.
Questions
1. Why was this a good application for simulation?
2. What key elements of the study made the project successful?
3. What specific decisions were made as a result of the simulation study?
4. What economic benefit was able to be shown from the project?
5. What insights did you gain from this case study about the way simulation is used?
References
Audon, Wyston Hugh, and L. Kronenberger. The Faber Book of Aphorisms. London: Faber
and Faber, 1964.
Banks, Jerry, and R. Gibson. “10 Rules for Determining When Simulation Is Not Appropri-
ate.” IIE Solutions, September 1997, pp. 30–32.
Banks, Jerry, and R. Gibson. “Selecting Simulation Software.” IIE Solutions, May 1997,
pp. 29–32.
Bateman, Robert E.; Royce O. Bowden; Thomas J. Gogg; Charles R. Harrell; and Jack
R. A. Mott. System Improvement Using Simulation. Utah: PROMODEL Corp., 1997.
Deming, W. E. Foundation for Management of Quality in the Western World. Paper read
at a meeting of the Institute of Management Sciences, Osaka, Japan, 24 July 1989.
Glenney, Neil E., and Gerald T. Mackulak. “Modeling & Simulation Provide Key to CIM
Implementation Philosophy.” Industrial Engineering, May 1985.
Hancock, Walton; R. Dissen; and A. Merten. “An Example of Simulation to Improve Plant
Productivity.” AIIE Transactions, March 1977, pp. 2–10.
Harrell, Charles R., and Donald Hicks. “Simulation Software Component Architec-
ture for Simulation-Based Enterprise Applications.” In Proceedings of the 1998
Winter Simulation Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson, and
M. S. Manivannan, pp. 1717–21. Institute of Electrical and Electronics Engineers,
Piscataway, New Jersey.
Harrington, H. James. Business Process Improvement. New York: McGraw-Hill, 1991.
Hoover, Stewart V., and Ronald F. Perry. Simulation: A Problem-Solving Approach.
Reading, MA: Addison-Wesley, 1989.
Kelton, W. D. “Statistical Issues in Simulation.” In Proceedings of the 1996 Winter
Simulation Conference, ed. J. Charnes, D. Morrice, D. Brunner, and J. Swain, 1996,
pp. 47–54.
Law, A. M., and M. G. McComas. “How Simulation Pays Off.” Manufacturing Engineer-
ing, February 1988, pp. 37–39.
Mott, Jack, and Kerim Tumay. “Developing a Strategy for Justifying Simulation.” Indus-
trial Engineering, July 1992, pp. 38–42.
Oxford American Dictionary. New York: Oxford University Press, 1980. [compiled by]
Eugene Enrich et al.
Perry, R. F., and R. F. Baum. “Resource Allocation and Scheduling for a Radiology
Department.” In Cost Control in Hospitals. Ann Arbor, MI: Health Administration
Press, 1976.
Rohrer, Matt, and Jerry Banks. “Required Skills of a Simulation Analyst.” IIE Solutions,
May 1998, pp. 7–23.
Schrage, Michael. Serious Play: How the World’s Best Companies Simulate to Innovate.
Cambridge, MA: Harvard Business School Press, 1999.
Schriber, T. J. “The Nature and Role of Simulation in the Design of Manufacturing
Systems.” Simulation in CIM and Artificial Intelligence Techniques, ed. J. Retti and
K. E. Wichmann. S.D., CA.: Society for Computer Simulation, 1987, pp. 5–8.
Shannon, Robert E. “Introduction to the Art and Science of Simulation.” In Proceed-
ings of the 1998 Winter Simulation Conference, ed. D. J. Medeiros, E. F. Watson,
J. S. Carson, and M. S. Manivannan, pp. 7–14. Piscataway, NJ: Institute of Electrical
and Electronics Engineers.
Shingo, Shigeo. The Shingo Production Management System—Improving Process Func-
tions. Trans. Andrew P. Dillon. Cambridge, MA: Productivity Press, 1992.
Solberg, James. “Design and Analysis of Integrated Manufacturing Systems.” In W. Dale
Compton. Washington, D.C.: National Academy Press, 1988, p. 4.
The Wall Street Journal, March 19, 1999. “United 747’s Near Miss Sparks a Widespread
Review of Pilot Skills,” p. A1.
2 SYSTEM DYNAMICS
2.1 Introduction
Knowing how to do simulation doesn’t make someone a good systems designer
any more than knowing how to use a CAD system makes one a good product
designer. Simulation is a tool that is useful only if one understands the nature of
the problem to be solved. It is designed to help solve systemic problems that are
operational in nature. Simulation exercises fail to produce useful results more
often because of a lack of understanding of system dynamics than a lack of know-
ing how to use the simulation software. The challenge is in understanding how
the system operates, knowing what you want to achieve with the system, and
being able to identify key leverage points for best achieving desired objectives.
To illustrate the nature of this challenge, consider the following actual scenario:
The pipe mill for the XYZ Steel Corporation was an important profit center, turning
steel slabs selling for under $200/ton into a product with virtually unlimited demand
selling for well over $450/ton. The mill took coils of steel of the proper thickness
and width through a series of machines that trimmed the edges, bent the steel into a
cylinder, welded the seam, and cut the resulting pipe into appropriate lengths, all on
a continuously running line. The line was even designed to weld the end of one coil
to the beginning of the next one “on the fly,” allowing the line to run continually for
days on end.
Unfortunately the mill was able to run only about 50 percent of its theoretical
capacity over the long term, costing the company tens of millions of dollars a year in
lost revenue. In an effort to improve the mill’s productivity, management studied each
step in the process. It was fairly easy to find the slowest step in the line, but additional
study showed that only a small percentage of lost production was due to problems at
33
this “bottleneck” operation. Sometimes a step upstream from the bottleneck would
have a problem, causing the bottleneck to run out of work, or a downstream step
would go down temporarily, causing work to back up and stop the bottleneck. Some-
times the bottleneck would get so far behind that there was no place to put incoming,
newly made pipe. In this case the workers would stop the entire pipe-making process
until the bottleneck was able to catch up. Often the bottleneck would then be idle
waiting until the newly started line was functioning properly again and the new pipe
had a chance to reach it. Sometimes problems at the bottleneck were actually caused
by improper work at a previous location.
In short, there was no single cause for the poor productivity seen at this plant.
Rather, several separate causes all contributed to the problem in complex ways. Man-
agement was at a loss to know which of several possible improvements (additional or
faster capacity at the bottleneck operation, additional storage space between stations,
better rules for when to shut down and start up the pipe-forming section of the mill,
better quality control, or better training at certain critical locations) would have the
most impact for the least cost. Yet the poor performance of the mill was costing
enormous amounts of money. Management was under pressure to do something, but
what should it be?
This example illustrates the nature and difficulty of the decisions that an op-
erations manager faces. Managers need to make decisions that are the “best” in
some sense. To do so, however, requires that they have clearly defined goals and
understand the system well enough to identify cause-and-effect relationships.
While every system is different, just as every product design is different,
the basic elements and types of relationships are the same. Knowing how the
elements of a system interact and how overall performance can be improved are
essential to the effective use of simulation. This chapter reviews basic system
dynamics and answers the following questions:
• What is a system?
• What are the elements of a system?
• What makes systems so complex?
• What are useful system metrics?
• What is a systems approach to systems planning?
• How do traditional systems analysis techniques compare with simulation?
discount prices or when you locate a health care organization that provides prompt
and professional service. The difference is between a system that has been well
designed and operates smoothly, and one that is poorly planned and managed.
A system, as used here, is defined as a collection of elements that function
together to achieve a desired goal (Blanchard 1991). Key points in this definition
include the fact that (1) a system consists of multiple elements, (2) these elements
are interrelated and work in cooperation, and (3) a system exists for the purpose
of achieving specific objectives. Examples of systems are traffic systems, politi-
cal systems, economic systems, manufacturing systems, and service systems. Our
main focus will be on manufacturing and service systems that process materials,
information, and people.
Manufacturing systems can be small job shops and machining cells or large
production facilities and assembly lines. Warehousing and distribution as well as
entire supply chain systems will be included in our discussions of manufacturing
systems. Service systems cover a wide variety of systems including health care fa-
cilities, call centers, amusement parks, public transportation systems, restaurants,
banks, and so forth.
Both manufacturing and service systems may be termed processing systems be-
cause they process items through a series of activities. In a manufacturing system,
raw materials are transformed into finished products. For example, a bicycle manu-
facturer starts with tube stock that is then cut, welded, and painted to produce bicycle
frames. In service systems, customers enter with some service need and depart as
serviced (and, we hope, satisfied) customers. In a hospital emergency room, for ex-
ample, nurses, doctors, and other staff personnel admit and treat incoming patients
who may undergo tests and possibly even surgical procedures before finally being re-
leased. Processing systems are artificial (they are human-made), dynamic (elements
interact over time), and usually stochastic (they exhibit random behavior).
FIGURE 2.1
Incoming entities Outgoing entities
Elements of a system. Activities
Resources Controls
System
2.3.1 Entities
Entities are the items processed through the system such as products, customers,
and documents. Different entities may have unique characteristics such as cost,
shape, priority, quality, or condition. Entities may be further subdivided into the
following types:
• Human or animate (customers, patients, etc.).
• Inanimate (parts, documents, bins, etc.).
• Intangible (calls, electronic mail, etc.).
For most manufacturing and service systems, the entities are discrete items. This
is the case for discrete part manufacturing and is certainly the case for nearly all
service systems that process customers, documents, and others. For some production
systems, called continuous systems, a nondiscrete substance is processed rather than
discrete entities. Examples of continuous systems are oil refineries and paper mills.
2.3.2 Activities
Activities are the tasks performed in the system that are either directly or indi-
rectly involved in the processing of entities. Examples of activities include ser-
vicing a customer, cutting a part on a machine, or repairing a piece of equipment.
Activities usually consume time and often involve the use of resources. Activities
may be classified as
• Entity processing (check-in, treatment, inspection, fabrication, etc.).
• Entity and resource movement (forklift travel, riding in an elevator, etc.).
• Resource adjustments, maintenance, and repairs (machine setups, copy
machine repair, etc.).
2.3.3 Resources
Resources are the means by which activities are performed. They provide the support-
ing facilities, equipment, and personnel for carrying out activities. While resources
facilitate entity processing, inadequate resources can constrain processing by limiting
the rate at which processing can take place. Resources have characteristics such as ca-
pacity, speed, cycle time, and reliability. Like entities, resources can be categorized as
• Human or animate (operators, doctors, maintenance personnel, etc.).
• Inanimate (equipment, tooling, floor space, etc.).
• Intangible (information, electrical power, etc.).
2.3.4 Controls
Controls dictate how, when, and where activities are performed. Controls impose
order on the system. At the highest level, controls consist of schedules, plans,
and policies. At the lowest level, controls take the form of written procedures and
machine control logic. At all levels, controls provide the information and decision
logic for how the system should operate. Examples of controls include
• Routing sequences.
• Production plans.
• Work schedules.
• Task prioritization.
• Control software.
• Instruction sheets.
While the sheer number of elements in a system can stagger the mind
(the number of different entities, activities, resources, and controls can easily
exceed 100), the interactions of these elements are what make systems so com-
plex and difficult to analyze. System complexity is primarily a function of the
following two factors:
1. Interdependencies between elements so that each element affects other
elements.
2. Variability in element behavior that produces uncertainty.
These two factors characterize virtually all human-made systems and make
system behavior difficult to analyze and predict. As shown in Figure 2.2, the de-
gree of analytical difficulty increases exponentially as the number of interdepen-
dencies and random variables increases.
2.4.1 Interdependencies
Interdependencies cause the behavior of one element to affect other elements in
the system. For example, if a machine breaks down, repair personnel are put into
action while downstream operations become idle for lack of parts. Upstream op-
erations may even be forced to shut down due to a logjam in the entity flow caus-
ing a blockage of activities. Another place where this chain reaction or domino
effect manifests itself is in situations where resources are shared between two
or more activities. A doctor treating one patient, for example, may be unable to
FIGURE 2.2
Analytical difficulty
Degree of analytical
as a function of
the number of
difficulty
interdependencies and
random variables.
Number of interdependencies
and random variables
immediately respond to another patient needing his or her attention. This delay in
response may also set other forces in motion.
It should be clear that the complexity of a system has less to do with the
number of elements in the system than with the number of interdependent rela-
tionships. Even interdependent relationships can vary in degree, causing more
or less impact on overall system behavior. System interdependency may be
either tight or loose depending on how closely elements are linked. Elements
that are tightly coupled have a greater impact on system operation and perfor-
mance than elements that are only loosely connected. When an element such
as a worker or machine is delayed in a tightly coupled system, the impact is
immediately felt by other elements in the system and the entire process may be
brought to a screeching halt.
In a loosely coupled system, activities have only a minor, and often delayed,
impact on other elements in the system. Systems guru Peter Senge (1990) notes
that for many systems, “Cause and effect are not closely related in time and space.”
Sometimes the distance in time and space between cause-and-effect relationships
becomes quite sizable. If enough reserve inventory has been stockpiled, a truck-
ers’ strike cutting off the delivery of raw materials to a transmission plant in one
part of the world may not affect automobile assembly in another part of the world
for weeks. Cause-and-effect relationships are like a ripple of water that diminishes
in impact as the distance in time and space increases.
Obviously, the preferred approach to dealing with interdependencies is to
eliminate them altogether. Unfortunately, this is not entirely possible for most
situations and actually defeats the purpose of having systems in the first place.
The whole idea of a system is to achieve a synergy that otherwise would be un-
attainable if every component were to function in complete isolation. Several
methods are used to decouple system elements or at least isolate their influence
so disruptions are not felt so easily. These include providing buffer inventories,
implementing redundant or backup measures, and dedicating resources to single
tasks. The downside to these mitigating techniques is that they often lead to ex-
cessive inventories and underutilized resources. The point to be made here is that
interdependencies, though they may be minimized somewhat, are simply a fact of
life and are best dealt with through effective coordination and management.
2.4.2 Variability
Variability is a characteristic inherent in any system involving humans and ma-
chinery. Uncertainty in supplier deliveries, random equipment failures, unpre-
dictable absenteeism, and fluctuating demand all combine to create havoc in
planning system operations. Variability compounds the already unpredictable
effect of interdependencies, making systems even more complex and unpredict-
able. Variability propagates in a system so that “highly variable outputs from
one workstation become highly variable inputs to another” (Hopp and Spearman
2000). Table 2.1 identifies the types of random variability that are typical of most
manufacturing and service systems.
Activity times Operation times, repair times, setup times, move times
Decisions To accept or reject a part, where to direct a particular customer,
which task to perform next
Quantities Lot sizes, arrival quantities, number of workers absent
Event intervals Time between arrivals, time between equipment failures
Attributes Customer preference, part size, skill level
times. For example, cycle times and throughput rates are going to have
some variance associated with them. Variance is reduced by controlling
activity times, improving resource reliability, and adhering to schedules.
These metrics can be given for the entire system, or they can be broken down by
individual resource, entity type, or some other characteristic. By relating these
metrics to other factors, additional meaningful metrics can be derived that are
useful for benchmarking or other comparative analysis. Typical relational metrics
include minimum theoretical flow time divided by actual flow time (flow time
efficiency), cost per unit produced (unit cost), annual inventory sold divided by
average inventory (inventory turns or turnover ratio), or units produced per cost
or labor input (productivity).
FIGURE 2.3
Cost curves showing
optimum number of
resources to minimize
total cost.
Total cost
Optimum Resource costs
Cost
Waiting costs
Number of resources
As shown in Figure 2.3, the number of resources at which the sum of the
resource costs and waiting costs is at a minimum is the optimum number of re-
sources to have. It also becomes the optimum acceptable waiting time.
In systems design, arriving at an optimum system design is not always re-
alistic, given the almost endless configurations that are sometimes possible and
limited time that is available. From a practical standpoint, the best that can be
expected is a near optimum solution that gets us close enough to our objective,
given the time constraints for making the decision.
FIGURE 2.4
Four-step iterative Identify problems
approach to systems and opportunities.
improvement.
Evaluate the
solutions.
variables. The activity of systems design and process improvement, also called
systems engineering, has been defined as
The effective application of scientific and engineering efforts to transform an opera-
tional need into a defined system configuration through the top-down iterative process
of requirements definition, functional analysis, synthesis, optimization, design, test
and evaluation (Blanchard 1991).
identify possible areas of focus and leverage points for applying a solution. Tech-
niques such as cause-and-effect analysis and pareto analysis are useful here.
Once a problem or opportunity has been identified and key decision variables
isolated, alternative solutions can be explored. This is where most of the design and
engineering expertise comes into play. Knowledge of best practices for common types
of processes can also be helpful. The designer should be open to all possible alterna-
tive feasible solutions so that the best possible solutions don’t get overlooked.
Generating alternative solutions requires creativity as well as organizational
and engineering skills. Brainstorming sessions, in which designers exhaust every
conceivably possible solution idea, are particularly useful. Designers should
use every stretch of the imagination and not be stifled by conventional solutions
alone. The best ideas come when system planners begin to think innovatively and
break from traditional ways of doing things. Simulation is particularly helpful in
this process in that it encourages thinking in radical new ways.
FIGURE 2.5
Simulation improves 100%
performance With
predictability. simulation
System predictability
50%
Without
simulation
They are important to cover here, not only because they sometimes provide a
good alternative to simulation, but also because they can complement simulation
by providing initial design estimates for input to the simulation model. They also
can be useful to help validate the results of a simulation by comparing them with
results obtained using an analytic model.
2.9.2 Spreadsheets
Spreadsheet software comes in handy when calculations, sometimes involving hun-
dreds of values, need to be made. Manipulating rows and columns of numbers on
a computer is much easier than doing it on paper, even with a calculator handy.
Spreadsheets can be used to perform rough-cut analysis such as calculating aver-
age throughput or estimating machine requirements. The drawback to spreadsheet
software is the inability (or, at least, limited ability) to include variability in activity
times, arrival rates, and so on, and to account for the effects of interdependencies.
What-if experiments can be run on spreadsheets based on expected values
(average customer arrivals, average activity times, mean time between equipment
failures) and simple interactions (activity A must be performed before activity B).
This type of spreadsheet simulation can be very useful for getting rough per-
formance estimates. For some applications with little variability and component
interaction, a spreadsheet simulation may be adequate. However, calculations
based on only average values and oversimplified interdependencies potentially
can be misleading and result in poor decisions. As one ProModel user reported,
“We just completed our final presentation of a simulation project and successfully
saved approximately $600,000. Our management was prepared to purchase an
additional overhead crane based on spreadsheet analysis. We subsequently built a
ProModel simulation that demonstrated an additional crane will not be necessary.
The simulation also illustrated some potential problems that were not readily ap-
parent with spreadsheet analysis.”
Prescriptive Techniques
Prescriptive OR techniques provide an optimum solution to a problem, such as the
optimum amount of resource capacity to minimize costs, or the optimum product
mix that will maximize profits. Examples of prescriptive OR optimization tech-
niques include linear programming and dynamic programming. These techniques
are generally applicable when only a single goal is desired for minimizing or maxi-
mizing some objective function—such as maximizing profits or minimizing costs.
Because optimization techniques are generally limited to optimizing for a single
goal, secondary goals get sacrificed that may also be important. Additionally, these
techniques do not allow random variables to be defined as input data, thereby forcing
the analyst to use average process times and arrival rates that can produce mislead-
ing results. They also usually assume that conditions are constant over the period of
study. In contrast, simulation is capable of analyzing much more complex relation-
ships and time-varying circumstances. With optimization capabilities now provided
in simulation, simulation software has even taken on a prescriptive roll.
Descriptive Techniques
Descriptive techniques such as queuing theory are static analysis techniques that
provide good estimates for basic problems such as determining the expected av-
erage number of entities in a queue or the average waiting times for entities in a
queuing system. Queuing theory is of particular interest from a simulation per-
spective because it looks at many of the same system characteristics and issues
that are addressed in simulation.
Queuing theory is essentially the science of waiting lines (in the United
Kingdom, people wait in queues rather than lines). A queuing system consists of
.
.
.
one or more queues and one or more servers (see Figure 2.6). Entities, referred to
in queuing theory as the calling population, enter the queuing system and either
are immediately served if a server is available or wait in a queue until a server
becomes available. Entities may be serviced using one of several queuing disci-
plines: first-in, first-out (FIFO); last-in, first-out (LIFO); priority; and others. The
system capacity, or number of entities allowed in the system at any one time, may
be either finite or, as is often the case, infinite. Several different entity queuing
behaviors can be analyzed such as balking (rejecting entry), reneging (abandon-
ing the queue), or jockeying (switching queues). Different interarrival time dis-
tributions (such as constant or exponential) may also be analyzed, coming from
either a finite or infinite population. Service times may also follow one of several
distributions such as exponential or constant.
Kendall (1953) devised a simple system for classifying queuing systems in
the form A/B/s, where A is the type of interarrival distribution, B is the type of
service time distribution, and s is the number of servers. Typical distribution
types for A and B are as follows:
M for Markovian or exponential distribution
G for a general distribution
D for a deterministic or constant value
An M/D/1 queuing system, for example, is a system in which interarrival times are
exponentially distributed, service times are constant, and there is a single server.
The arrival rate in a queuing system is usually represented by the Greek letter
lambda () and the service rate by the Greek letter mu (). The mean interarrival
time then becomes 1/ and the mean service time is 1/. A traffic intensity factor
/ is a parameter used in many of the queuing equations and is represented by
the Greek letter rho ( ).
Common performance measures of interest in a queuing system are based on
steady-state or long-term expected values and include the following:
L ⫽ expected number of entities in the system (number in the queue and in
service)
Lq ⫽ expected number of entities in the queue (queue length)
⫽ 20 per hour
⫽ 25 per hour
⫽ __
⫽ .8
Solving for L:
L ⫽ _______
( ⫺ )
20
⫽ _________
(25 ⫺ 20)
20 ⫽ 4
⫽ ___
5
L
W ⫽ __
4
⫽ ___
20
⫽ .20 hrs
⫽ 12 minutes
2.10 Summary
An understanding of system dynamics is essential to using any tool for planning
system operations. Manufacturing and service systems consist of interrelated ele-
ments (personnel, equipment, and so forth) that interactively function to produce
a specified outcome (an end product, a satisfied customer, and so on). Systems are
made up of entities (the objects being processed), resources (the personnel, equip-
ment, and facilities used to process the entities), activities (the process steps),
and controls (the rules specifying the who, what, where, when, and how of entity
processing).
The two characteristics of systems that make them so difficult to analyze are
interdependencies and variability. Interdependencies cause the behavior of one
element to affect other elements in the system either directly or indirectly. Vari-
ability compounds the effect of interdependencies in the system, making system
behavior nearly impossible to predict without the use of simulation.
The variables of interest in systems analysis are decision, response, and state
variables. Decision variables define how a system works; response variables in-
dicate how a system performs; and state variables indicate system conditions at
specific points in time. System performance metrics or response variables are
generally time, utilization, inventory, quality, or cost related. Improving system
performance requires the correct manipulation of decision variables. System op-
timization seeks to find the best overall setting of decision variable values that
maximizes or minimizes a particular response variable value.
Given the complex nature of system elements and the requirement to make
good design decisions in the shortest time possible, it is evident that simulation
can play a vital role in systems planning. Traditional systems analysis techniques
are effective in providing quick but often rough solutions to dynamic systems
problems. They generally fall short in their ability to deal with the complexity and
dynamically changing conditions in manufacturing and service systems. Simula-
tion is capable of imitating complex systems of nearly any size and to nearly any
level of detail. It gives accurate estimates of multiple performance metrics and
leads designers toward good design decisions.
References
Blanchard, Benjamin S. System Engineering Management. New York: John Wiley & Sons,
1991.
Hopp, Wallace J., and M. Spearman. Factory Physics. New York: Irwin/McGraw-Hill,
2000, p. 282.
Kendall, D. G. “Stochastic Processes Occurring in the Theory of Queues and Their
Analysis by the Method of Imbedded Markov Chains.” Annals of Mathematical
Statistics 24 (1953), pp. 338–54.
Kofman, Fred, and P. Senge. Communities of Commitment: The Heart of Learning
Organizations. Sarita Chawla and John Renesch, (eds.), Portland, OR. Productivity
Press, 1995.
Law, Averill M. Simulation Modeling and Analysis 4th ed. New York: McGraw-Hill, 2007.
Little, J. D. C. “A Proof for the Queuing Formula: L ⫽ W.” Operations Research 9, no. 3
(1961), pp. 383–87.
Lloyd, S., and K. Melton. “Using Statistical Process Control to Obtain More Precise
Distribution Fitting Using Distribution Fitting Software.” Simulators International
XIV 29, no. 3 (April 1997), pp. 193–98.
Pool, Robert. Beyond Engineering. Oxford University Press, 1997, p. 131.
Senge, Peter. The Fifth Discipline. New York: Doubleday, 1990.
Simon, Herbert A. Models of Man. New York: John Wiley & Sons, 1957, p. 198.
3 SIMULATION BASICS
3.1 Introduction
Simulation is much more meaningful when we understand what it is actually
doing. Understanding how simulation works helps us to know whether we are
applying it correctly and what the output results mean. Many books have been
written that give thorough and detailed discussions of the science of simulation
(see Banks et al. 2001; Hoover and Perry 1989; Law 2007; Pooch and Wall 1993;
Ross 1990; Shannon 1975; Thesen and Travis 1992; and Widman, Loparo, and
Nielsen 1989). This chapter attempts to summarize the basic technical issues
related to simulation that are essential to understand in order to get the greatest
benefit from the tool. The chapter discusses the different types of simulation and
how random behavior is simulated. A spreadsheet simulation example is given
in this chapter to illustrate how various techniques are combined to simulate the
behavior of a common system.
57
FIGURE 3.1
Examples of (a) a deterministic simulation and (b) a stochastic simulation.
7
12.3
3.4 Simulation Simulation
106
5
(a) (b)
1 …
Time
Start Event 1 Event 2 Event 3
Simulation (customer (customer (customer
arrives) arrives) departs)
FIGURE 3.3
Continuous-change
Comparison of a state variable
discrete-change
state variable and a
continuous-change Value
Discrete-change
state variable.
state variable
Time
Differential Equations
The change that occurs in some continuous-change state variables is expressed in
terms of the derivatives of the state variables. Equations involving derivatives of
a state variable are referred to as differential equations. The state variable , for
example, might change as a function of both and time t:
d (t)
_____ 2(t) t2
dt
We then need a second equation to define the initial condition of :
(0) K
On a computer, numerical integration is used to calculate the change in a par-
ticular response variable over time. Numerical integration is performed at the end
of successive small time increments referred to as steps. Numerical analysis tech-
niques, such as Runge-Kutta integration, are used to integrate the differential equa-
tions numerically for each incremental time step. One or more threshold values for
each continuous-change state variable are usually defined that determine when some
action is to be triggered, such as shutting off a valve or turning on a pump.
Difference Equations
Sometimes a continuous-change state variable can be modeled using difference
equations. In such instances, the time is decomposed into periods of length t. An
algebraic expression is then used to calculate the value of the state variable at the
end of period k 1 based on the value of the state variable at the end of period k.
For example, the following difference equation might be used to express the rate
of change in the state variable as a function of the current value of , a rate of
change (r), and the length of the time period (t):
(k 1) (k) rt
Batch processing in which fluids are pumped into and out of tanks can often
be modeled using difference equations.
.4
.2
0
0 1 2 3 4 5 6 7 x
Discrete Value
f (x) 1.0
.8
.6
(b )
.4
.2
0
0 1 2 3 4 5 6 7 x
Continuous Value
the parameters that describe the shape or density and range of the distribution.
For example, we might describe the time for a check-in operation to be normally
distributed with a mean of 5.2 minutes and a standard deviation of 0.4 minute.
During the simulation, values are obtained from this distribution for successive
operation times. The shape and range of time values generated for this activity
will correspond to the parameters used to define the distribution. When we gener-
ate a value from a distribution, we call that value a random variate.
Probability distributions from which we obtain random variates may be either
discrete (they describe the likelihood of specific values occurring) or continuous
(they describe the likelihood of a value being within a given range). Figure 3.4
shows graphical examples of a discrete distribution and a continuous distribution.
A discrete distribution represents a finite or countable number of possible
values. An example of a discrete distribution is the number of items in a lot or
individuals in a group of people. A continuous distribution represents a continuum
Variance ⫽ 2 ⫽ 1
12
0 1.0 x
0 13
1 276 4 0.2500
2 87 7 0.4375
3 150 6 0.3750
4 129 1 0.0625
5 24 8 0.5000
6 171 11 0.6875
7 234 10 0.6250
8 213 5 0.3125
9 108 12 0.7500
10 255 15 0.9375
11 318 14 0.8750
12 297 9 0.5625
13 192 0 0.0000
14 3 3 0.1875
15 66 2 0.1250
16 45 13 0.8125
17 276 4 0.2500
18 87 7 0.4375
19 150 6 0.3750
20 129 1 0.0625
Note that 4 is the remainder term from dividing 16 into 276. The value of U1 is
computed as
U1 Z116 416 0.2500
The process continues using the value of Z1 to compute Z2 and then U2.
Changing the value of Z0 produces a different sequence of uniform(0, 1) num-
bers. However, the original sequence can always be reproduced by setting the
seed value back to 13 (Z0 13). The ability to repeat the simulation experiment
under the exact same “random” conditions is very useful, as will be demonstrated
in Chapter 9 with a technique called common random numbers.
Note that in ProModel the sequence of random numbers is not generated
in advance and then read from a table as we have done. Instead, the only value
saved is the last Zi value that was generated. When the next random number in the
sequence is needed, the saved value is fed back to the generator to produce the
next random number in the sequence. In this way, the random number generator
is called each time a new random event is scheduled for the simulation.
Due to computational constraints, the random number generator cannot go on
indefinitely before it begins to repeat the same sequence of numbers. The LCG in
Table 3.1 will generate a sequence of 16 numbers before it begins to repeat itself.
You can see that it began repeating itself starting in the 17th position. The value
you may want to think of each stream as a separate random number generator to
be used in different places in the model. For example, see Figure 9.5 in Chapter 9.
There are two types of linear congruential generators: the mixed congruential
generator and the multiplicative congruential generator. Mixed congruential gen-
erators are designed by assigning c > 0. Multiplicative congruential generators are
designed by assigning c 0. The multiplicative generator is more efficient than the
mixed generator because it does not require the addition of c. The maximum cycle
length for a multiplicative generator can be set within one unit of the maximum
cycle length of the mixed generator by carefully selecting values for a and m. From
a practical standpoint, the difference in cycle length is insignificant considering
that both types of generators can boast cycle lengths of more than 2.1 billion.
ProModel uses the following multiplicative generator:
Zi (630,360,016Zi1) mod (231 1)
Specifically, it is a prime modulus multiplicative linear congruential generator
(PMMLCG) with a 630,360,016, c 0, and m 231 1. It has been exten-
sively tested and is known to be a reliable random number generator for simu-
lation (Law and Kelton 2000). The ProModel implementation of this generator
divides the cycle length of 231 1 2,147,483,647 into 100 unique streams.
Continuous Distributions
The application of the inverse transformation method to generate random variates
from continuous distributions is straightforward and efficient for many continu-
ous distributions. For a given probability density function f(x), find the cumula-
tive distribution function of X. That is, F(x) P(X x). Next, set U F(x),
where U is uniform(0, 1), and solve for x. Solving for x yields x F1(U). The
equation x F1(U) transforms U into a value for x that conforms to the given
distribution f(x).
As an example, suppose that we need to generate variates from the expo-
nential distribution with mean . The probability density function f(x) and cor-
responding cumulative distribution function F(x) are
1 ex/
__ for x 0
f(x)
0 elsewhere
1
x/
F(x)
e for x 0
0 elsewhere
U 1 ex/
e x 1 U
ln (e ) ln (1 U)
x
where ln is the natural logarithm
x ln (1 U)
x ln (1 U)
The random variate x in the above equation is exponentially distributed with mean
provided U is uniform(0, 1).
Suppose three observations of an exponentially distributed random variable
with mean 2 are desired. The next three numbers generated by the random
number generator are U1 0.27, U2 0.89, and U3 0.13. The three numbers
are transformed into variates x1, x2, and x3 from the exponential distribution with
mean 2 as follows:
0.50
U1 = 1 – e –x1/ 2 = 0.27
is the case for many continuous distributions. However, the normal distribution
is one exception. Thus it is not possible to solve for a simple equation to gener-
ate normally distributed variates. For these cases, there are other methods that
can be used to generate the random variates. See, for example, Law (2007) for a
description of additional methods for generating random variates from continuous
distributions.
Discrete Distributions
The application of the inverse transformation method to generate variates from
discrete distributions is basically the same as for the continuous case. The differ-
ence is in how it is implemented. For example, consider the following probability
mass function:
0.10 for x 1
p(x) P(X x) 0.30 for x 2
0.60 for x 3
The random variate x has three possible values. The probability that x is equal to 1
is 0.10, P(X 1) 0.10; P(X 2) 0.30; and P(X 3) 0.60. The cumulative
distribution function F(x) is shown in Figure 3.7. The random variable x could be
used in a simulation to represent the number of defective components on a circuit
board or the number of drinks ordered from a drive-through window, for example.
Suppose that an observation from the above discrete distribution is desired.
The first step is to generate U, where U is uniform(0, 1). Using Figure 3.7, the
value of the random variate is determined by locating U on the y axis, drawing
a horizontal line from that point until it intersects with a step in the cumulative
function, and then dropping a vertical line from that point to the x axis to read the
0.40
U 1 = 0.27
0.10
U 3 = 0.05
1 2 3
x3 = 1 x1 = 2 x2 ⫽ 3
value of the variate. This process is illustrated in Figure 3.7 for x1, x2, and x3 given
U1 0.27, U2 0.89, and U3 0.05. Equivalently, if 0 Ui 0.10, then xi 1;
if 0.10 < Ui 0.40, then xi 2; if 0.40 < Ui 1.00, then xi 3. Note that should
we generate 100 variates using the above process, we would expect a value of 3 to
be returned 60 times, a value of 2 to be returned 30 times, and a value of 1 to be
returned 10 times.
The inverse transformation method can be applied to any discrete distribution
by dividing the y axis into subintervals as defined by the cumulative distribution
function. In our example case, the subintervals were [0, 0.10], (0.10, 0.40], and
(0.40, 1.00]. For each subinterval, record the appropriate value for the random
variate. Next, develop an algorithm that calls the random number generator to re-
ceive a specific value for U, searches for and locates the subinterval that contains
U, and returns the appropriate value for the random variate.
Locating the subinterval that contains a specific U value is relatively straight-
forward when there are only a few possible values for the variate. However, the
number of possible values for a variate can be quite large for some discrete distri-
butions. For example, a random variable having 50 possible values could require
that 50 subintervals be searched before locating the subinterval that contains U.
In such cases, sophisticated search algorithms have been developed that quickly
locate the appropriate subinterval by exploiting certain characteristics of the dis-
crete distribution for which the search algorithm was designed. A good source of
information on the subject can be found in Law (2007).
Uniform
The continuous uniform distribution is used to generate random variates from all
other distributions. By itself, it is used in simulation models when the modeler
wishes to make all observations equally likely to occur. It is also used when little
is known about the activity being simulated other than the activity’s lowest and
highest values.
The continuous uniform probability density function is given by
1
_____ for a x b
f (x) b a
0 elsewhere
with min a and max b. Using the inverse transformation method, the resulting
equation for generating variate x from the uniform(a, b) distribution is given by
x a (b a) U
where U is uniform(0, 1).
Triangular
Like the uniform distribution, the triangular distribution is used when little is
known about the activity being simulated other than the activity’s lowest value,
highest value, and most frequently occurring value—the mode.
The triangular probability density function is given by
2(x a)
_____________ for a x m
(b a)(m a)
f (x) _____________
2(b x)
for m x b
(b a)(b m)
0 elsewhere
with min a, max b, and mode m. Using the inverse transformation method,
the resulting equation for generating variate x from the triangular(a, m, b) distri-
bution is given by
_______________ (m a)
a (b a)(m a)U for 0 U _______
(b a)
x ____________________ (m a)
b (b a)(b m)(1 U) for _______ U 1
(b a)
where U is uniform(0, 1). Note that when the probability density function of the
random variable x is defined over separate subintervals with respect to x, then
the equation for generating a variate will be defined over separate subintervals
with respect to U. Therefore, step one is to generate U. Step two is to determine
which subinterval the value of U falls within. And step three is to plug U into the
corresponding equation to generate variate x for that subinterval.
Normal
The normal distribution is used to simulate errors such as the diameter of a pipe
with respect to its design specification. Some use it to model time such as process-
ing times. However, if this is done, negative values should be discarded.
The normal probability density function is given by
1
f (x) _______
_____
22
e(x) /(2 )
2 2
for all real x
with mean and variance 2. A method developed by Box and Muller and re-
ported in Law (2007) involves generating a variate x from the standard normal
distribution (mean 0 and variance 2 1) and then converting it into a vari-
ate x
from the normal distribution with the desired mean and variance using the
equation x
x.
The method generates two standard normally( 0, 2 1) distributed vari-
ates x1 and x2 and then converts them into normally( , 2) distributed variates x1
and x2
. The method is given by
________
x1 2 ln U1 cos 2U2
x1
x1
and
________
x2 2 ln U1 sin 2U2
x2
x2
where U1 and U2 are independent observations from the uniform(0, 1) distribution.
1
_________
p ( x) b a 1 for x a, a 1, . . . , b
0 elsewhere
with min a and max b. Using the inverse transformation method, the result-
ing equation for generating discrete uniform(a, b) variate x is given by
x a Ñ(b a 1)UÅ
where U is continuous uniform(0, 1) and ÑtÅ denotes the largest integer t.
Bernoulli
The bernoulli distribution is used to model random events with two possible out-
comes (e.g., a failure or a success). It is defined by the probability of getting a suc-
cess p. If, for example, the probability that a machine produces a good part (one
that meets specifications) is p each time the machine makes a part, the bernoulli
distribution would be used to simulate if a part is good or bad.
The bernoulli probability mass function is given by
1p for x 0
p (x) p for x 1
0 elsewhere
with probability of success p. Motivated by the inverse transformation method,
the equation for generating bernoulli( p) variate x is given by
x 10 for U p
elsewhere
where U is uniform(0, 1).
Geometric
The geometric distribution is used to model random events in which the modeler
is interested in simulating the number of independent bernoulli trials with prob-
ability of success p on each trial needed before the first success occurs. In other
words if x represents failures, how many failures will occur before the first suc-
cess? In the context of an inspection problem with a success denoted as a bad
item, how many good items will be built before the first bad item is produced?
The geometric probability mass function is given by
p (x) p (1 p)x
0
for x 0, 1, . . .
elsewhere
with x number of independent bernoulli trials each with probability of success p
occurring before the first success is realized. Motivated by the inverse transforma-
tion method, the equation for generating geometric( p) variate x is given by
x Ñln Uln (1 p)Å
where U is uniform(0, 1).
FIGURE 3.8
Descriptive drawing of the automatic teller machine (ATM) system.
8 7 6 5 4 3 2 1
Interarrival time
4.8 minutes
the queue. Figure 3.8 illustrates the relationships of the elements of the system
with the customers appearing as dark circles.
Our objective in building a spreadsheet simulation model of the ATM system
is to estimate the average amount of time the 25 customers will spend waiting in
the queue and the average amount of time the customers will spend in the sys-
tem. To accomplish our objective, the spreadsheet will need to generate random
numbers and random variates, to contain the logic that controls how customers
are processed by the system, and to compute an estimate of system performance
measures. The spreadsheet simulation is shown in Table 3.2 and is divided into
three main sections: Arrivals to ATM, ATM Processing Time, and ATM Simula-
tion Logic. The Arrivals to ATM and ATM Processing Time provide the founda-
tion for the simulation, while the ATM Simulation Logic contains the spreadsheet
programming that mimics customers flowing through the ATM system. The last
row of the Time in Queue column and the Time in System column under the ATM
Simulation Logic section contains one observation of the average time customers
wait in the queue, 1.94 minutes, and one observation of their average time in the
system, 4.26 minutes. The values were computed by averaging the 25 customer
time values in the respective columns.
Do you think customer number 17 (see the Customer Number column)
became upset over having to wait in the queue for 6.11 minutes to conduct a
0.43 minute transaction at the ATM (see the Time in Queue column and the
Service Time column under ATM Simulation Logic)? Has something like this
ever happened to you in real life? Simulation can realistically mimic the behavior
of a system. More time will be spent interpreting the results of our spreadsheet
simulation after we understand how it was put together.
har01307_ch03_057-086.indd 76
Arrivals to ATM ATM Processing Time ATM Simulation Logic
Random Interarrival Random Service Customer Arrival Begin Service Service Departure Time in Time in
Stream 1 Number Time Stream 2 Number Time Number Tone Time Time Time Queue System
i (Z1i) (U1i) (X1i) (Z2i) (U2i) (X2i) (1) (2) (3) (4) (5) (3) (4) (6) (3) (2) (7) (5) (2)
0 3 122
1 66 0.516 2.18 5 0.039 0.10 1 2.18 2.18 0.10 2.28 0.00 0.10
2 109 0.852 5.73 108 0.844 4.46 2 7.91 7.91 4.46 12.37 0.00 4.46
3 116 0.906 7.09 95 0.742 3.25 3 15.00 15.00 3.25 18.25 0.00 3.25
4 7 0.055 0.17 78 0.609 2.25 4 15.17 18.25 2.25 20.50 3.08 5.33
5 22 0.172 0.57 105 0.820 4.12 5 15.74 20.50 4.12 24.62 4.76 8.88
6 81 0.633 3.01 32 0.250 0.69 6 18.75 24.62 0.69 25.31 5.87 6.56
7 40 0.313 1.13 35 0.273 0.77 7 19.88 25.31 0.77 26.08 5.43 6.20
8 75 0.586 2.65 98 0.766 3.49 8 22.53 26.08 3.49 29.57 3.55 7.04
9 42 0.328 1.19 13 0.102 0.26 9 23.72 29.57 0.26 29.83 5.85 6.11
10 117 0.914 7.36 20 0.156 0.41 10 31.08 31.08 0.41 31.49 0.00 0.41
11 28 0.219 0.74 39 0.305 0.87 11 31.82 31.82 0.87 32.69 0.00 0.87
12 79 0.617 2.88 54 0.422 1.32 12 34.70 34.70 1.32 36.02 0.00 1.32
13 126 0.984 12.41 113 0.883 5.15 13 47.11 47.11 5.15 52.26 0.00 5.15
14 89 0.695 3.56 72 0.563 1.99 14 50.67 52.26 1.99 54.25 1.59 3.58
15 80 0.625 2.94 107 0.836 4.34 15 53.61 54.25 4.34 58.59 0.64 4.98
16 19 0.148 0.48 74 0.578 2.07 16 54.09 58.59 2.07 60.66 4.50 6.57
17 18 0.141 0.46 21 0.164 0.43 17 54.55 60.66 0.43 61.09 6.11 6.54
18 125 0.977 11.32 60 0.469 1.52 18 65.87 65.87 1.52 67.39 0.00 1.52
19 68 0.531 2.27 111 0.867 4.84 19 68.14 68.14 4.84 72.98 0.00 4.84
20 23 0.180 0.60 30 0.234 0.64 20 68.74 72.98 0.64 73.62 4.24 4.88
21 102 0.797 4.78 121 0.945 6.96 21 73.52 73.62 6.96 80.58 0.10 7.06
22 97 0.758 4.26 112 0.875 4.99 22 77.78 80.58 4.99 85.57 2.80 7.79
23 120 0.938 8.34 51 0.398 1.22 23 86.12 86.12 1.22 87.34 0.00 1.22
24 91 0.711 3.72 50 0.391 1.19 24 89.84 89.84 1.19 91.03 0.00 1.19
25 122 0.953 9.17 29 0.227 0.62 25 99.01 99.01 0.62 99.63 0.00 0.62
Average 1.94 4.26
20/12/10 1:49 PM
Chapter 3 Simulation Basics 77
3.0 minutes. That is, the time that elapses between one customer arrival and the
next is not the same from one customer to the next but averages out to be 3.0
minutes. This is illustrated in Figure 3.8 in that the interarrival time between cus-
tomers 7 and 8 is much smaller than the interarrival time of 4.8 minutes between
customers 6 and 7. The service time at the ATM is also a random variable fol-
lowing the exponential distribution and averages 2.4 minutes. To simulate this
stochastic system, a random number generator is needed to produce observations
(random variates) from the exponential distribution. The inverse transformation
method was used in Section 3.4.2 just for this purpose.
The transformation equation is
Xi ln (1 Ui) for i 1, 2, 3, . . . , 25
where Xi represents the ith value realized from the exponential distribution with
mean , and Ui is the ith random number drawn from a uniform(0, 1) distribu-
tion. The i 1, 2, 3, . . . , 25 indicates that we will compute 25 values from the
transformation equation. However, we need to have two different versions of
this equation to generate the two sets of 25 exponentially distributed random
variates needed to simulate 25 customers because the mean interarrival time of
3.0 minutes is different than the mean service time of 2.4 minutes.
Let X1i denote the interarrival time and X2i denote the service time generated
for the ith customer simulated in the system. The equation for transforming
a random number into an interarrival time observation from the exponential
distribution with mean 3.0 minutes becomes
X1i 3.0 ln (1 U1i) for i 1, 2, 3, . . . , 25
where U1i denotes the ith value drawn from the random number generator using
Stream 1. This equation is used in the Arrivals to ATM section of Table 3.2 under
the Interarrival Time (X1i) column.
The equation for transforming a random number into an ATM service time
observation from the exponential distribution with mean 2.4 minutes becomes
X2i 2.4 ln (1 U2i) for i 1, 2, 3, . . . , 25
where U2i denotes the ith value drawn from the random number generator using
Stream 2. This equation is used in the ATM Processing Time section of Table 3.2
under the Service Time (X2i) column.
Let’s produce the sequence of U1i values that feeds the transformation equa-
tion (X1i) for interarrival times using a linear congruential generator (LCG)
similar to the one used in Table 3.1. The equations are
Z1i (21Z1i1 3) mod (128)
U1i Z1i 128 for i 1, 2, 3, . . . , 25
The authors defined Stream 1’s starting or seed value to be 3. So we will use
Z10 3 to kick off this stream of 25 random numbers. These equations are used
in the Arrivals to ATM section of Table 3.2 under the Stream 1 (Z1i) and Random
Number (U1i) columns.
Likewise, we will produce the sequence of U2i values that feeds the transfor-
mation equation (X2i) for service times using
Z2i (21Z2i1 3) mod (128)
U2i Z2i 128 for i 1, 2, 3, . . . , 25
and will specify a starting seed value of Z20 122, Stream 2’s seed value, to kick
off the second stream of 25 random numbers. These equations are used in the
ATM Processing Time section of Table 3.2 under the Stream 2 (Z2i) and Random
Number (U2i) columns.
The spreadsheet presented in Table 3.2 illustrates 25 random variates for both
the interarrival time, column (X1i), and service time, column (X2i). All time values
are given in minutes in Table 3.2. To be sure we pull this together correctly, let’s
compute a couple of interarrival times with mean 3.0 minutes and compare
them to the values given in Table 3.2.
Given Z10 3
Z11 (21Z10 3) mod (128) (21(3) 3) mod (128)
(66) mod (128) 66
U11 Z11128 66128 0.516
X11 ln (1 U11) 3.0 ln (1 0.516) 2.18 minutes
The value of 2.18 minutes is the first value appearing under the column,
Interarrival Time (X1i) To compute the next interarrival time value X12, we start
by using the value of Z11 to compute Z12.
Given Z11 66
Z12 (21Z11 3) mod (128) (21(66) 3) mod (128) 109
U12 Z12 128 109128 0.852
X12 3 ln (1 U12) 3.0 ln (1 0.852) 5.73 minutes
Figure 3.9 illustrates how the equations were programmed in Microsoft Excel for
the Arrivals to ATM section of the spreadsheet. Note that the U1i and X1i values
in Table 3.2 are rounded to three and two places to the right of the decimal,
respectively. The same rounding rule is used for U2i and X2i.
It would be useful for you to verify a few of the service time values with
mean 2.4 minutes appearing in Table 3.2 using
Z20 122
Z2i (21Z2i1 3) mod (128)
U2i Z2i 128
X2i 2.4 ln (1 U2i) for i 1, 2, 3, . . .
The equations started out looking a little difficult to manipulate but turned
out not to be so bad when we put some numbers in them and organized them in a
FIGURE 3.9
Microsoft Excel
snapshot of the ATM
spreadsheet
illustrating the
equations for the
Arrivals to ATM
section.
spreadsheet—though it was a bit tedious. The important thing to note here is that al-
though it is transparent to the user, ProModel uses a very similar method to produce
exponentially distributed random variates, and you now understand how it is done.
The LCG just given has a maximum cycle length of 128 random numbers
(you may want to verify this), which is more than enough to generate 25 interar-
rival time values and 25 service time values for this simulation. However, it is a
poor random number generator compared to the one used by ProModel. It was
chosen because it is easy to program into a spreadsheet and to compute by hand
to facilitate our understanding. The biggest difference between it and the random
number generator in ProModel is that the ProModel random number generator
manipulates much larger numbers to pump out a much longer stream of numbers
that pass all statistical tests for randomness.
Before moving on, let’s take a look at why we chose Z10 3 and Z20 122.
Our goal was to make sure that we did not use the same uniform(0, 1) random
number to generate both an interarrival time and a service time. If you look
carefully at Table 3.2, you will notice that the seed value Z20 122 is the Z125
value from random number Stream 1. Stream 2 was merely defined to start where
Stream 1 ended. Thus our spreadsheet used a unique random number to generate
each interarrival and service time. Now let’s add the necessary logic to our
spreadsheet to conduct the simulation of the ATM system.
processing of customers through the ATM system. The simulation program must
keep up with the passage of time to coordinate the events. The word dynamic
appearing in the title for this section refers to the fact that the simulation tracks
the passage of time.
The first column under the ATM Simulation Logic section of Table 3.2,
labeled Customer Number, is simply to keep a record of the order in which the
25 customers are processed, which is FIFO. The numbers appearing in parentheses
under each column heading are used to illustrate how different columns are added
or subtracted to compute the values appearing in the simulation.
The Arrival Time column denotes the moment in time at which each customer
arrives to the ATM system. The first customer arrives to the system at time 2.18 min-
utes. This is the first interarrival time value (X11 2.18) appearing in the Arrival to
ATM section of the spreadsheet table. The second customer arrives to the system at
time 7.91 minutes. This is computed by taking the arrival time of the first customer
of 2.18 minutes and adding to it the next interarrival time of X12 5.73 minutes that
was generated in the Arrival to ATM section of the spreadsheet table. The arrival
time of the second customer is 2.18 5.73 7.91 minutes. The process continues
with the third customer arriving at 7.91 7.09 15.00 minutes.
The trickiest piece to program into the spreadsheet is the part that determines
the moment in time at which customers begin service at the ATM after waiting in
the queue. Therefore, we will skip over the Begin Service Time column for now
and come back to it after we understand how the other columns are computed.
The Service Time column simply records the simulated amount of time re-
quired for the customer to complete their transaction at the ATM. These values
are copies of the service time X2i values generated in the ATM Processing Time
section of the spreadsheet.
The Departure Time column records the moment in time at which a customer
departs the system after completing their transaction at the ATM. To compute the
time at which a customer departs the system, we take the time at which the cus-
tomer gained access to the ATM to begin service, column (3), and add to that the
length of time the service required, column (4). For example, the first customer
gained access to the ATM to begin service at 2.18 minutes, column (3). The ser-
vice time for the customer was determined to be 0.10 minutes in column (4). So,
the customer departs 0.10 minutes later or at time 2.18 0.10 2.28 minutes.
This customer’s short service time must be because they forgot their PIN number
and could not conduct their transaction.
The Time in Queue column records how long a customer waits in the queue
before gaining access to the ATM. To compute the time spent in the queue, we
take the time at which the ATM began serving the customer, column (3), and sub-
tract from that the time at which the customer arrived to the system, column (2).
The fourth customer arrives to the system at time 15.17 and begins getting service
from the ATM at 18.25 minutes; thus, the fourth customer’s time in the queue is
18.25 15.17 3.08 minutes.
The Time in System column records how long a customer was in the system.
To compute the time spent in the system, we subtract the customer’s departure
time, column (5), from the customer’s arrival time, column (2). The fifth customer
arrives to the system at 15.74 minutes and departs the system at 24.62 minutes.
Therefore, this customer spent 24.62 15.74 8.88 minutes in the system.
Now let’s go back to the Begin Service Time column, which records the time
at which a customer begins to be served by the ATM. The very first customer
to arrive to the system when it opens for service advances directly to the ATM.
There is no waiting time in the queue; thus the value recorded for the time that
the first customer begins service at the ATM is the customer’s arrival time. With
the exception of the first customer to arrive to the system, we have to capture the
logic that a customer cannot begin service at the ATM until the previous customer
using the ATM completes his or her transaction. One way to do this is with an IF
statement as follows:
IF (Current Customer’s Arrival Time < Previous Customer’s
Departure Time)
THEN (Current Customer’s Begin Service Time Previous Customer’s
Departure Time)
ELSE (Current Customer’s Begin Service Time Current Customer’s
Arrival Time)
The Excel spreadsheet cell L10 (column L, row 10) in Figure 3.10 is the Begin
Service Time for the second customer to arrive to the system and is programmed
with IF(K10<N9,N9,K10). Since the second customer’s arrival time (Excel cell
K10) is not less than the first customer’s departure time (Excel cell N9), the logical
test evaluates to “false” and the second customer’s time to begin service is set to
his or her arrival time (Excel cell K10). The fourth customer shown in Figure 3.10
provides an example of when the logical test evaluates to “true,” which results in
the fourth customer beginning service when the third customer departs the ATM.
FIGURE 3.10
Microsoft Excel
snapshot of the
ATM spreadsheet
illustrating the IF
statement for the
Begin Service Time
column.
3.6 Summary
Modeling random behavior begins with transforming the output produced by a
random number generator into observations (random variates) from an appropri-
ate statistical distribution. The values of the random variates are combined with
logical operators in a computer program to compute output that mimics the per-
formance behavior of stochastic systems. Performance estimates for stochastic
simulations are obtained by calculating the average value of the performance met-
ric across several replications of the simulation. Models can realistically simulate
a variety of systems.
1
______
for x
f (x)
0 elsewhere
where 7 and 4.
b. Probability mass function:
x
___
for x 1, 2, 3, 4, 5
p (x) P (X x) 15
0 elsewhere
References
Banks, Jerry; John S. Carson II; Barry L. Nelson; and David M. Nicol. Discrete-Event
System Simulation. Englewood Cliffs, NJ: Prentice Hall, 2001.
Hoover, Stewart V., and Ronald F. Perry. Simulation: A Problem-Solving Approach.
Reading, MA: Addison-Wesley, 1989.
Johnson, R. A. Miller and Freund’s Probability and Statistics for Engineers. 8th ed.
Englewood Cliffs, NJ: Prentice Hall, 2010.
Law, Averill M. Simulation Modeling and Analysis 4th ed. New York: McGraw-Hill, 2007.
L’Ecuyer, P. “Random Number Generation.” In Handbook of Simulation: Principles,
Methodology, Advances, Applications, and Practice, ed. J. Banks, pp. 93–137. New
York: John Wiley & Sons, 1998.
Pooch, Udo W., and James A. Wall. Discrete Event Simulation: A Practical Approach.
Boca Raton, FL: CRC Press, 1993.
Pritsker, A. A. B. Introduction to Simulation and SLAM II. 4th ed. New York: John Wiley
& Sons, 1995.
Ross, Sheldon M.A. Simulation. 4th ed. Burlington, MA: Elsevier Academic Press, 2006.
Shannon, Robert E. System Simulation: The Art and Science. Englewood Cliffs, NJ:
Prentice Hall, 1975.
Thesen, Arne, and Laurel E. Travis. Simulation for Decision Making. Minneapolis, MN:
West Publishing, 1992.
Widman, Lawrence E.; Kenneth A. Loparo; and Norman R. Nielsen. Artificial Intelligence,
Simulation, and Modeling. New York: John Wiley & Sons, 1989.
4 DISCRETE-EVENT
SIMULATION
“When the only tool you have is a hammer, every problem begins to resemble a
nail.”
—Abraham Maslow
4.1 Introduction
Building on the foundation provided by Chapter 3 on how random numbers and
random variates are used to simulate stochastic systems, the focus of this chapter
is on discrete-event simulation, which is the main topic of this book. A discrete-
event simulation is one in which changes in the state of the simulation model
occur at discrete points in time as triggered by events. The events in the automatic
teller machine (ATM) simulation example of Chapter 3 that occur at discrete
points in time are the arrivals of customers to the ATM queue and the comple-
tion of their transactions at the ATM. However, you will learn in this chapter that
the spreadsheet simulation of the ATM system in Chapter 3 was not technically
executed as a discrete-event simulation.
This chapter summarizes the basic technical issues related to discrete-event
simulation to facilitate your understanding of how to effectively use the tool.
Questions that will be answered include these:
• How does discrete-event simulation work?
• What do commercial simulation software packages provide?
• What are the differences between simulation languages and simulators?
• What is the future of simulation technology?
A manual dynamic, stochastic, discrete-event simulation of the ATM example
system from Chapter 3 is given to further illustrate what goes on inside this type
of simulation.
87
state and statistical variables for the resource are updated, the graphical anima-
tion is updated, and the input waiting list for the resource is examined to see what
activity to respond to next. Any new events resulting from the processing of the
current event are inserted into either the event calendar or another appropriate
waiting list.
In real life, events can occur simultaneously so that multiple entities can be
doing things at the same instant in time. In computer simulation, however, espe-
cially when running on a single processor, events can be processed only one at
a time even though it is the same instant in simulated time. As a consequence, a
method or rule must be established for processing events that occur at the exact
same simulated time. For some special cases, the order in which events are pro-
cessed at the current simulation time might be significant. For example, an entity
that frees a resource and then tries to immediately get the same resource might
have an unfair advantage over other entities that might have been waiting for that
particular resource.
In ProModel, the entity, downtime, or other item that is currently being pro-
cessed is allowed to continue processing as far as it can at the current simulation
time. That means it continues processing until it reaches either a conditional event
that cannot be satisfied or a timed delay that causes a future event to be scheduled.
It is also possible that the object simply finishes all of the processing defined for
it and, in the case of an entity, exits the system. As an object is being processed,
any resources that are freed or other entities that might have been created as by-
products are placed in an action list and are processed one at a time in a similar
fashion after the current object reaches a stopping point. To deliberately suspend
the current object in order to allow items in the action list to be processed, a zero
delay time can be specified for the current object. This puts the current item into
the future events list (event calendar) for later processing, even though it is still
processed at the current simulation time.
When all scheduled and conditional events have been processed that are
possible at the current simulation time, the clock advances to the next scheduled
event and the process continues. When a termination event occurs, the simula-
tion ends and statistical reports are generated. The ongoing cycle of processing
scheduled and conditional events, updating state and statistical variables, and
creating new events constitutes the essence of discrete-event simulation (see
Figure 4.1).
FIGURE 4.1
Start
Logic diagram of
how discrete-event
simulation works.
Create simulation
database and schedule
initial events.
Advance clock to
next event time.
No
Stop
Process event and
schedule any new
events.
Update statistics,
state variables,
and animation.
No
FIGURE 4.2
Entity flow diagram for example automatic teller machine (ATM) system.
8 7 6 5 4 3 2 1
customers wait in line for the ATM) and the expected number of customers wait-
ing in the queue (the average number of customers waiting in the queue during
the simulated time period). If you are wondering why 22 minutes was selected
as the simulation run length, it is because 22 minutes of manual simulation will
nicely fit on one page of the textbook. An entity flow diagram of the ATM system
is shown in Figure 4.2.
Simulation Clock
As the simulation transitions from one discrete-event to the next, the simulation
clock is fast forwarded to the time that the next event is scheduled to occur. There
is no need for the clock to tick seconds away until reaching the time at which
the next event in the list is scheduled to occur because nothing will happen that
changes the state of the system until the next event occurs. Instead, the simula-
tion clock advances through a series of time steps. Let ti denote the value of the
simulation clock at time step i, for i 0 to the number of discrete events to
process. Assuming that the simulation starts at time zero, then the initial value of
the simulation clock is denoted as t0 0. Using this nomenclature, t1 denotes the
value of the simulation clock when the first discrete event in the list is processed,
t2 denotes the value of the simulation clock when the second discrete-event in the
list is processed, and so on.
Entity Attributes
To capture some statistics about the entities being processed through the system,
a discrete-event simulation maintains an array of entity attribute values. Entity
attributes are characteristics of the entity that are maintained for that entity until
the entity exits the system. For example, to compute the amount of time an entity
waited in a queue location, an attribute is needed to remember when the entity
entered the location. For the ATM simulation, one entity attribute is used to re-
member the customer’s time of arrival to the system. This entity attribute is called
the Arrival Time attribute. The simulation program computes how long each cus-
tomer entity waited in the queue by subtracting the time that the customer entity
arrived to the queue from the value of the simulation clock when the customer
entity gained access to the ATM.
State Variables
Two discrete-change state variables are needed to track how the status (state) of
the system changes as customer entities arrive in and depart from the ATM system.
• Number of Entities in Queue at time step i, NQi.
• ATM Statusi to denote if the ATM is busy or idle at time step i.
Statistical Accumulators
The objective of the example manual simulation is to estimate the expected
amount of time customers wait in the queue and the expected number of customers
waiting in the queue. The average time customers wait in queue is a simple aver-
age. Computing this requires that we record how many customers passed through
the queue and the amount of time each customer waited in the queue. The average
number of customers in the queue is a time-weighted average, which is usually
called a time average in simulation. Computing this requires that we not only
observe the queue’s contents during the simulation but that we also measure the
amount of time that the queue maintained each of the observed values. We record
each observed value after it has been multiplied (weighted) by the amount of time
it was maintained.
Here’s what the simulation needs to tally at each simulation time step i to
compute the two performance measures at the end of the simulation.
Simple-Average Time in Queue.
• Record the number of customer entities processed through the queue,
Total Processed. Note that the simulation may end before all customer
entities in the queue get a turn at the ATM. This accumulator keeps track
of how many customers actually made it through the queue.
• For a customer processed through the queue, record the time that it waited
in the queue. This is computed by subtracting the value of the simulation
clock time when the entity enters the queue (stored in the entity attribute
array Arrival Time) from the value of the simulation clock time when the
entity leaves the queue, ti – Arrival Time.
Time-Average Number of Customers in the Queue.
• For the duration of the last time step, which is ti – ti1, and the number of
customer entities in the queue during the last time step, which is NQi1,
record the product of ti – ti1 and NQi1. Call the product (ti – ti1) NQi1
the Time-Weighted Number of Entities in the Queue.
Events
There are two types of recurring scheduled events that change the state of the sys-
tem: arrival events and departure events. An arrival event occurs when a customer
entity arrives to the queue. A departure event occurs when a customer entity com-
pletes its transaction at the ATM. Each processing of a customer entity’s arrival
to the queue includes scheduling the future arrival of the next customer entity to
the ATM queue. Each time an entity gains access to the ATM, its future departure
from the system is scheduled based on its expected service time at the ATM. We
actually need a third event to end the simulation. This event is usually called the
termination event.
To schedule the time at which the next entity arrives to the system, the simu-
lation needs to generate an interarrival time and add it to the current simulation
clock time, ti. The interarrival time is exponentially distributed with a mean of
3.0 minutes for our example ATM system. Assume that the function E(3.0) re-
turns an exponentially distributed random variate with a mean of 3.0 minutes.
The future arrival time of the next customer entity can then be scheduled by
using the equation ti E(3.0).
har01307_ch04_087-114.indd 95
i=i+1
i=i+1 • Update Event Calendar: Insert Scheduled Future Events in chronological order. i=i+1
• Advance Clock, ti, to the Time of the first event on the calendar and process the event.
End
• Schedule departure event for • Store current customer • Update Entity Attribute Array by • Update Entity Attribute
current customer entity entering entity’s Arrival Time in last deleting departed customer entity Array by deleting departed
ATM to occur at time ti + E(2.4). position of Entity Attribute from first position in the array and customer entity from first
• Store current customer’s Array to reflect customer shifting waiting customers up. position of the array.
Arrival Time in first position of joining the queue. • Subtract 1 from NQi, Number of • Change ATM Statusi to Idle.
Entity Attribute Array. • Add 1 to NQi, Number of Entities in Queue.
• Change ATM Statusi to Busy. Entities in Queue. • Schedule departure event for
• Update Entities Processed • Update Time-Weighted customer entity entering the ATM
through Queue statistics to Number of Entities in Queue to occur at time ti + E(2.4).
reflect customer entering ATM. statistic. • Update Entities Processed
- Add 1 to Total Processed. - Compute value for through Queue statistics to reflect
- Record Time in Queue of 0 for (ti – ti – 1)NQi – 1 and customer entering ATM.
ti - Arrival Time and update update Cumulative. - Add 1 to Total Processed.
Cumulative. - Compute Time in Queue
• Update Time-Weighted Number value for ti - Arrival Time and
of Entities in Queue statistic. update Cumulative.
- Record value of 0 for • Update Time-Weighted Number of
(ti – ti – 1)NQi – 1 and update Entities in Queue statistic.
Cumulative. - Compute value for (ti – ti – 1)NQi –1
and update Cumulative.
95
FIGURE 4.3
Discrete-event simulation logic diagram for ATM system.
20/12/10 1:49 PM
96
TABLE 4.1 Manual Discrete-Event Simulation of ATM System
Event Calendar Processed Event System State Statistical Accumulators Scheduled Future Events
Entity Attribute Time-Weighted
Array (Entity Number, Entities Processed Number of
har01307_ch04_087-114.indd 96
Arrival Time) through Queue Entities in Queue
i
0 — 0 — — *( ) 0 Idle 0 — 0 — 0 (1, Arrive, 2.18)
( ) (_, End, 22.00)
1 (1, Arrive, 2.18) 2.18 1 Arrive *(1, 2.18) ↑ Busy 1 0 0 0 (2, Arrival, 7.91)
(_, End, 22.00) ( ) (1, Depart, 2.28)
2 (1, Depart, 2.28) 2.28 1 Depart *( ) ↑ Idle — — 0 — 0
(2, Arrive, 7.91) ( ) No new events
(_, End, 22.00)
3 (2, Arrive, 7.91) 7.91 2 Arrive *(2, 7.91) ↑ Busy 2 0 0 0 0 (3, Arrive, 15.00)
(_, End, 22.00) ( ) (2, Depart, 12.37)
4 (2, Depart, 12.37) 12.37 2 Depart *( ) ↑ Idle — — 0 — 0
(3, Arrive, 15.00) ( ) No new events
(_, End, 22.00)
5 (3, Arrive, 15.00) 15.00 3 Arrive *(3, 15.00) ↑ Busy 3 0 0 0 0 (4, Arrive, 15.17)
(_, End, 22.00) ( ) (3, Depart, 18.25)
6 (4, Arrive, 15.17) 15.17 4 Arrive *(3, 15.00) 1 ↑ — — 0 0 0 (5, Arrive, 15.74)
(3, Depart, 18.25) (4, 15.17)
(_, End, 22.00)
7 (5, Arrive, 15.74) 15.74 5 Arrive *(3, 15.00) 2 ↑ — — 0 0.57 0.57 (6, Arrive, 18.75)
(3, Depart, 18.25) (4, 15.17)
(_, End, 22.00) (5, 15.74)
8 (3, Depart, 18.25) 18.25 3 Depart *(4, 15.17) 1 ↑ 4 3.08 3.08 5.02 5.59 (4, Depart, 20.50)
(6, Arrive, 18.75) (5, 15.74)
(_, End, 22.00)
9 (6, Arrive, 18.75) 18.75 6 Arrive *(4, 15.17) 2 ↑ — — 3.08 0.50 6.09 (7, Arrive, 19.88)
(4, Depart, 20.50) (5, 15.74)
(_, End, 22.00) (6, 18.75)
10 (7, Arrive, 19.88) 19.88 7 Arrive *(4, 15.17) 3 ↑ — — 3.08 2.26 8.35 (8, Arrive, 22.53)
(4, Depart, 20.50) (5, 15.74)
(_, End, 22.00) (6, 18.75)
(7, 19.88)
11 (4, Depart, 20.50) 20.50 4 Depart *(5, 15.74) 2 ↑ 5 4.76 7.84 1.86 10.21 (5, Depart, 24.62)
(_, End, 22.00) (6, 18.75)
(8, Arrive, 22.53) (7, 19.88)
12 (_, End, 22.00) 22.00 End — ↑ ↑ 5 — 7.84 3.00 13.21 —
(8, Arrive, 22.53)
(5, Depart, 24.62)
20/12/10 1:49 PM
Chapter 4 Discrete-Event Simulation 97
cell in the table also signifies that the simulation logic diagram does not require
you to update that cell at the current time step. However, the arrows serve as a
reminder to look up one or more rows above your current position in the table to
determine the state of the ATM system. Arrows appear under the Number of Enti-
ties in Queue, NQi column, and ATM Statusi column. The only exception to the
use of dashes or arrows is that we keep a running total in the two Cumulative sub-
columns in the table for each time step. Let’s get the manual simulation started.
i ⴝ 0, t0 ⴝ 0. As shown in Figure 4.3, the first block after the start position indicates
that the model is initialized to its starting conditions. The simulation time step begins
at i 0. The initial value of the simulation clock is zero, t0 0. The system state
variables are set to ATM Status0 “Idle”; Number of Entities in Queue, NQ0 0;
and the Entity Attribute Array is cleared. This reflects the initial conditions of no
customer entities in the queue and an idle ATM. The statistical accumulator Total
Processed is set to zero. There are two different Cumulative variables in Table 4.1:
one to accumulate the time in queue values of ti Arrival Time, and the other to ac-
cumulate the values of the time-weighted number of entities in the queue, (ti ti1)
NQi1. Recall that ti Arrival Time is the amount of time that entities, which gained
access to the ATM, waited in queue. Both Cumulative variables (ti Arrival Time)
and (ti ti1)NQi1 are initialized to zero. Next, an initial arrival event and termina-
tion event are scheduled and placed under the Scheduled Future Events column. The
listing of an event is formatted as “(Entity Number, Event, and Event Time)”. Entity
Number denotes the customer number that the event pertains to (such as the first,
second, or third customer). Event is the type of event: a customer arrives, a customer
departs, or the simulation ends. Time is the future time that the event is to occur.
The event “(1, Arrive, 2.18)” under the Scheduled Future Events column prescribes
that the first customer entity is scheduled to arrive at time 2.18 minutes. The arrival
time was generated using the equation t0 E(3.0). To obtain the value returned from
the function E(3), we went to Table 3.2, read the first random variate from the Interar-
rival Time column (a value of 2.18 minutes), and added it to the current value of the
simulation clock, t0 0. The simulation is to be terminated after 22 minutes. Note the
“(__, End, 22.00)” under the Scheduled Future Events column. For the termination
event, no value is assigned to Entity Number because it is not relevant.
i ⴝ 1, t1 ⴝ 2.18. After the initialization step, the list of scheduled future events is added
to the event calendar in chronological order in preparation for the next simulation time
step i 1. The simulation clock is fast forwarded to the time that the next event is
scheduled to occur, which is t1 2.18 (the arrival time of the first customer to the ATM
queue), and then the event is processed. Following the simulation logic diagram, arrival
events are processed by first scheduling the future arrival event for the next customer
entity using the equation t1 E(3.0) 2.18 5.73 7.91 minutes. Note the value
of 5.73 returned by the function E(3.0) is the second random variate listed under the
Interarrival Time column of Table 3.2. This future event is placed under the Scheduled
Future Events column in Table 4.1 as “(2, Arrive, 7.91)”. Checking the status of the
ATM from the previous simulation time step reveals that the ATM is idle (ATM Status0
“Idle”). Therefore, the arriving customer entity immediately flows through the queue
to the ATM to conduct its transaction. The future departure event of this entity from
the ATM is scheduled using the equation t1 E(2.4) 2.18 0.10 2.28 minutes.
See “(1, Depart, 2.28)” under the Scheduled Future Events column, denoting that the
first customer entity is scheduled to depart the ATM at time 2.28 minutes. Note that the
value of 0.10 returned by the function E(2.4) is the first random variate listed under
the Service Time column of Table 3.2. The arriving customer entity’s arrival time is
then stored in the first position of the Entity Attribute Array to signify that it is being
served by the ATM. The ATM Status1 is set to “Busy,” and the statistical accumulators
for Entities Processed through Queue are updated. Add 1 to Total Processed and since
this entity entered the queue and immediately advanced to the idle ATM for processing,
record zero minutes in the Time in Queue, t1 Arrival Time, subcolumn and update this
statistic’s cumulative value. The statistical accumulators for Time-Weighted Number of
Entities in the Queue are updated next. Record zero for (t1 t0)NQ0 since there were
no entities in queue during the previous time step, NQ0 0, and update this statistic’s
cumulative value. Note the arrow “↑” entered under the Number of Entities in Queue,
NQ1 column. Recall that the arrow is placed there to signify that the number of entities
waiting in the queue has not changed from its previous value.
i ⴝ 2, t2 ⴝ 2.28. Following the loop back around to the top of the simulation logic
diagram, we place the two new future events onto the event calendar in chronological
order in preparation for the next simulation time step i 2. The simulation clock is
fast forwarded to t2 2.28, and the departure event for the first customer entity arriv-
ing to the system is processed. Given that there are no customers in the queue from
the previous time step, NQ1 0 (follow the arrows up to get this value), we simply
remove the departed customer from the first position of the Entity Attribute Array and
change the status of the ATM to idle, ATM Status2 “Idle”. The statistical accumu-
lators do not require updating because there are no customer entities waiting in the
queue or leaving the queue. The dashes (—) entered under the statistical accumulator
columns indicate that updates are not required. No new future events are scheduled.
As before, we follow the loop back to the top of the simulation logic diagram,
and place any new events, of which there are none at the end of time step i 2,
onto the event calendar in chronological order in preparation for the next simula-
tion time step i 3. The simulation clock is fast forwarded to t3 7.91, and the
arrival of the second customer entity to the ATM queue is processed. Complete the
processing of this event and continue the manual simulation until the termination
event “(__, End, 22.00)” reaches the top of the event calendar.
As you work through the simulation logic diagram to complete the manual simu-
lation, you will see that the fourth customer arriving to the system requires that you
use logic from a different path in the diagram. When the fourth customer entity arrives
to the ATM queue, simulation time step i 6, the ATM is busy (see ATM Status5) pro-
cessing customer entity 3’s transaction. Therefore, the fourth customer entity joins the
queue and waits to use the ATM. (Don’t forget that it invoked the creation of the fifth
customer’s arrival event.) The fourth entity’s arrival time of 15.17 minutes is stored
in the last position of the Entity Attribute Array in keeping with the first-in, first-out
(FIFO) rule. The Number of Entities in Queue, NQ6, is incremented to 1. Further, the
Time-Weighted Number of Entities in the Queue statistical accumulators are updated
by first computing (t6 t5)NQ5 (15.17 15.00)0 0 and then recording the result.
Next, this statistic’s cumulative value is updated. Customers 5, 6, and 7 also arrive to
the system finding the ATM busy and therefore take their place in the queue to wait
for the ATM.
The fourth customer waited a total of 3.08 minutes in the queue (see the
ti Arrival Time subcolumn) before it gained access to the ATM in time step
i 8 as the third customer departed. The value of 3.08 minutes in the queue for
Simple-Average Statistic
A simple-average statistic is calculated by dividing the sum of all observation
values of a response variable by the number of observations:
兺i1 xi
n
Simple average ______
n
where n is the number of observations and xi is the value of ith observation. Exam-
ple simple-average statistics include the average time entities spent in the system
(from system entry to system exit), the average time entities spent at a specific
location, or the average time per use for a resource. An average of an observation-
based response variable in ProModel is computed as a simple average.
The average time that customer entities waited in the queue for their turn on
the ATM during the manual simulation reported in Table 4.1 is a simple-average
statistic. Recall that the simulation processed five customers through the queue.
Let xi denote the amount of time that the ith customer processed spent in the
queue. The average waiting time in queue based on the n 5 observations is
兺 i1 xi _____________________
5
Average time in queue _____ 0 0 0 3.08 4.76
5 5
7.84 minutes 1.57 minutes
___________
5
The values necessary for computing this average are accumulated under the Enti-
ties Processed through Queue columns of the manual simulation table (see the last
row of Table 4.1 for the cumulative value 兺(ti Arrival Time) 7.84 and Total
Processed 5).
Time-Average Statistic
A time-average statistic, sometimes called a time-weighted average, reports the
average value of a response variable weighted by the time duration for each
observed value of the variable:
兺 i1 (Tixi)
n
Time average ________
T
where xi denotes the value of the ith observation, Ti denotes the time duration of
the ith observation (the weighting factor), and T denotes the total duration over
which the observations were collected. Example time-average statistics include
the average number of entities in a system, the average number of entities at a
location, and the average utilization of a resource. An average of a time-weighted
response variable in ProModel is computed as a time average.
The average number of customer entities waiting in the queue location for
their turn on the ATM during the manual simulation is a time-average statistic.
Figure 4.4 is a plot of the number of customer entities in the queue during the
manual simulation recorded in Table 4.1. The 12 discrete-events manually simu-
lated in Table 4.1 are labeled t1, t2, t3, . . . , t11, t12, on the plot. Recall that ti denotes
the value of the simulation clock at time step i in Table 4.1, and that its initial
value is zero, t0 0.
Using the notation from the time-average equation just given, the total simu-
lation time illustrated in Figure 4.4 is T 22 minutes. The Ti denotes the dura-
tion of time step i (distance between adjacent discrete-events in Figure 4.4). That
is, Ti ti ti1 for i 1, 2, 3, . . . , 12. The xi denotes the queue’s contents (num-
ber of customer entities in the queue) during each time Ti interval. Therefore, xi
NQi1 for i 1, 2, 3, . . . , 12 (recall that in Table 4.1, NQi1 denotes the number of
Simulation time, T 22
FIGURE 4.4
Number of customers in the queue during the manual simulation.
101
20/12/10 1:49 PM
102 Part I Study Chapters
customer entities in the queue from ti1 to ti). The time-average number of cus-
tomer entities in the queue (let’s call it Average NQ) is
12 12
兺i1 (Ti xi) 兺i1 (ti ti1)NQi1
Average NQ _______ _____________
T T
(2.18)(0) (0.1)(0) (5.63)(0) (4.46)(0) (2.63)(0) (0.17)(0) (0.57)(1) (2.51)(2) . . . (1.5)(2)
Average NQ _________________________________________________________________________________________
22
13.21 0.60 customers
Average NQ _____
22
You may recognize that the numerator of this equation (兺 i1(ti ti1)NQi1)
12
calculates the area under the plot of the queue’s contents during the simulation
(Figure 4.4). The values necessary for computing this area are accumulated under
the Time-Weighted Number of Entities in Queue column of Table 4.1 (see the
Cumulative value of 13.21 in the table’s last row).
4.3.5 Issues
Even though this example is a simple and somewhat crude simulation, it pro-
vides a good illustration of basic simulation issues that need to be addressed when
conducting a simulation study. First, note that the simulation start-up conditions
can bias the output statistics. Since the system started out empty, queue content
statistics are slightly less than what they might be if we began the simulation with
customers already in the system. Second, note that we ran the simulation for only
22 minutes before calculating the results. Had we ran longer, it is very likely that
the long-run average time in the queue would have been somewhat different (most
likely greater) than the time from the short run because the simulation did not
have a chance to reach a steady state.
These are the kinds of issues that should be addressed whenever running a
simulation. The modeler must carefully analyze the output and understand the
significance of the results that are given. This example also points to the need for
considering beforehand just how long a simulation should be run. These issues are
addressed in Chapters 8 and 9.
FIGURE 4.5
Typical components of
simulation software.
Simulation Simulation
processor processor
entering and editing model information. External files used in the simulation are
specified here as well as run-time options (number of replications and so on).
request snapshot reports, pan or zoom the layout, and so forth. If visual interactive
capability is provided, the user is even permitted to make changes dynamically to
model variables with immediate visual feedback of the effects of such changes.
The animation speed can be adjusted and animation can even be disabled by
the user during the simulation. When unconstrained, a simulation is capable of
running as fast as the computer can process all of the events that occur within the
simulated time. The simulation clock advances instantly to each scheduled event;
the only central processing unit (CPU) time of the computer that is used is what
is necessary for processing the event logic. This is how simulation is able to run
in compressed time. It is also the reason why large models with millions of events
take so long to simulate. Ironically, in real life activities take time while events
take no time. In simulation, events take time while activities take no time. To slow
down a simulation, delay loops or system timers are used to create pauses between
events. These techniques give the appearance of elapsing time in an animation. In
some applications, it may even be desirable to run a simulation at the same rate
as a real clock. These real-time simulations are achieved by synchronizing the
simulation clock with the computer’s internal system clock. Human-in-the-loop
(such as operator training simulators) and hardware-in-the-loop (testing of new
equipment and control systems) are examples of real-time simulations.
displayed during the simulation itself, although some simulation products create
an animation file that can be played back at the end of the simulation. In addition
to animated figures, dynamic graphs and history plots can be displayed during the
simulation.
Animation and dynamically updated displays and graphs provide a visual rep-
resentation of what is happening in the model while the simulation is running.
Animation comes in varying degrees of realism from three-dimensional animation
to simple animated flowcharts. Often, the only output from the simulation that is of
interest is what is displayed in the animation. This is particularly true when simula-
tion is used for facilitating conceptualization or for communication purposes.
A lot can be learned about model behavior by watching the animation (a pic-
ture is worth a thousand words, and an animation is worth a thousand pictures).
Animation can be as simple as circles moving from box to box, to detailed, real-
istic graphical representations. The strategic use of graphics should be planned in
advance to make the best use of them. While insufficient animation can weaken
the message, excessive use of graphics can distract from the central point to be
made. It is always good to dress up the simulation graphics for the final presen-
tation; however, such embellishments should be deferred at least until after the
model has been debugged.
For most simulations where statistical analysis is required, animation is no
substitute for the postsimulation summary, which gives a quantitative overview of
the entire system performance. Basing decisions on the animation alone reflects
shallow thinking and can even result in unwarranted conclusions.
FIGURE 4.6
Sample of ProModel
graphic objects.
FIGURE 4.7
ProModel animation provides useful feedback.
animation takes place. This background might be a CAD layout imported into
the model. The dynamic animation objects that move around on the background
during the simulation include entities (parts, customers, and so on) and resources
(people, fork trucks, and so forth). Animation also includes dynamically updated
counters, indicators, gauges, and graphs that display count, status, and statistical
information (see Figure 4.7).
Summary Reports
Summary reports show totals, averages, and other overall values of interest.
Figure 4.8 shows an output report summary generated from a ProModel simula-
tion run.
FIGURE 4.8
Summary report of simulation activity.
--------------------------------------------------------------------------------
Mfg_cost.MOD (Model Parameters - Rep. 1)
Run Date/Time 6/15/2010 15:14
Model Title Manufacturing Costing Optimization
Model Path/File C:\Program Files\Models\Mfg_cost.MOD
Warmup Time (HR) 5
Simulation Time (HR) 10
--------------------------------------------------------------------------------
LOCATIONS
Avg Time
Scheduled Total Per Entry Avg Maximum Current % Utili-
Name Time (HR) Capacity Entries (MIN) Contents Contents Contents zation
Receive 10 2 22 54.54545 2 2 2 100
NC Lathe 1 10 1 57 10.11647 0.961065 1 1 96.1065
NC Lathe 2 10 1 57 9.891842 0.939725 1 1 93.9725
Degrease 10 2 114 10.18895 1.9359 2 2 96.795
Inspect 10 1 113 4.690053 0.883293 1 1 88.3293
Bearing Que 10 100 90 34.51747 5.17762 13 11 5.17762
Loc1 10 5 117 25.64103 5 5 5 72.0184
RESOURCES
Sche- Avg Time Avg Time %
duled Work Number Avg Time Travel Travel Blocked In %
Time Time Times Per Usage To Use To Park Travel Utili-
Name Units (HR) (HR) Used (MIN) (MIN) (MIN) zation
CellOp.1 1 10 5.78 122 2.737648 0.1038017 0 0 57.7588
CellOp.2 1 10 5.57 118 2.726542 0.1062712 0 0 55.712
CellOp.3 1 10 5.07 115 2.541652 0.102 0 0 50.67
CellOp 3 30 16.41 355 2.670465 0.1040395 0 0 54.7136
ENTITIES
Avg Avg Time Avg
Current Time In In Move Avg Time Time In Avg Time
Total Qty In System Logic Waiting Operation Blocked
Name Exits System (MIN) (MIN) (MIN) (MIN) (MIN)
Pallet 20 2 63.0418 0 30.56155 1 31.48025
Blank 0 7 0 0 0 0 0
Cog 79 3 52.5925 0.849203 3.226911 33.533266 14.98313
Reject 33 0 49.5601 0.853636 2.488545 33.065636 13.15224
Bearing 78 12 42.1855 0.05 35.58995 0 6.54559
FIGURE 4.9
Time-series graph
showing changes in
queue size over time.
FIGURE 4.10
Histogram of queue
contents.
acquired the reputation of being easy to use but inflexible, while simulation lan-
guages were branded as being very flexible but difficult to use (see Figure 4.11).
Over time, the distinction between simulation languages and simulators
has become blurred as specialized modeling constructs have been added to
general-purpose simulation languages, making them easier to use. During the
same period, general programming extensions have been added to simulators,
making them more flexible. The most popular simulation tools today combine
powerful industry-specific constructs with flexible programming capabilities,
all accessible from an intuitive graphical user interface (Bowden 1998). Some
tools are even configurable, allowing the software to be adapted to specific ap-
plications yet still retaining programming capability. Rather than put languages
and simulators on opposite ends of the same spectrum as though flexibility
and ease of use were mutually exclusive, it is more appropriate to measure the
flexibility and ease of use for all simulation software along two separate axes
(Figure 4.12).
FIGURE 4.12
Easy
New paradigm
that views ease of Early
use and flexibility Current best-of-breed
simulators products
as independent
Ease of use
characteristics.
Early
languages
Hard
Low High
Flexibility
role in simulation. As 3-D and other graphic technologies advance, these features
will also be incorporated into simulation products.
Simulation products targeted at vertical markets are on the rise. This trend
is driven by efforts to make simulation easier to use and more solution oriented.
Specific areas where dedicated simulators have been developed include call cen-
ter management, supply chain management, and high-speed processing. At the
same time many simulation applications are becoming more narrowly focused,
others are becoming more global and look at the entire enterprise or value chain
in a hierarchical fashion from top to bottom.
Perhaps the most dramatic change in simulation will be in the area of soft-
ware interoperability and technology integration. Historically, simulation has been
viewed as a stand-alone, project-based technology. Simulation models were built
to support an analysis project, to predict the performance of complex systems, and
to select the best alternative from a few well-defined alternatives. Typically these
projects were time-consuming and expensive, and relied heavily on the expertise
of a simulation analyst or consultant. The models produced were generally “single
use” models that were discarded after the project.
In recent years, the simulation industry has seen increasing interest in ex-
tending the useful life of simulation models by using them on an ongoing basis
(Harrell and Hicks 1998). Front-end spreadsheets and push-button user inter-
faces are making such models more accessible to decision makers. In these
flexible simulation models, controlled changes can be made to models through-
out the system life cycle. This trend is growing to include dynamic links to
databases and other data sources, enabling entire models actually to be built
and run in the background using data already available from other enterprise
applications.
The trend to integrate simulation as a component in enterprise applications
is part of a larger industry effort to provide software components that can be
distributed over the Internet using cloud computing and other service-oriented
technologies. These technologies promise to enable parallel and distributed model
execution and provide a mechanism for maintaining distributed model repositories
that can be shared by many modelers (Fishwick 1997). The interest in Web-based
simulation, like all other Web-based applications, continues to grow.
4.8 Summary
Most manufacturing and service systems are modeled using dynamic, stochas-
tic, discrete-event simulation. Discrete-event simulation works by converting all
activities to events and consequent reactions. Events are either time-triggered or
condition-triggered, and are therefore processed either chronologically or when a
satisfying condition has been met.
Simulation models are generally defined using commercial simulation
software that provides convenient modeling constructs and analysis tools.
Simulation software consists of several modules with which the user interacts.
Internally, model data are converted to simulation data, which are processed
during the simulation. At the end of the simulation, statistics are summarized
in an output database that can be tabulated or graphed in various forms. The
future of simulation is promising and will continue to incorporate exciting new
technologies.
References
Bowden, Royce. “The Spectrum of Simulation Software.” IIE Solutions, May 1998,
pp. 44–46.
Fishwick, Paul A. “Web-Based Simulation.” In Proceedings of the 1997 Winter Simulation
Conference, ed. S. Andradottir, K. J. Healy, D. H. Withers, and B. L. Nelson. Institute
of Electric and Electronics Engineers, Piscataway, NJ, 1997. pp. 100–109.
Gottfried, Byron S. Elements of Stochastic Process Simulation. Englewood Cliffs, NJ:
Prentice Hall, 1984, p. 8.
Haider, S. W., and J. Banks. “Simulation Software Products for Analyzing Manufacturing
Systems.” Industrial Engineering, July 1986, p. 98.
Harrell, Charles R., and Don Hicks. “Simulation Software Component Architecture for
Simulation-Based Enterprise Applications.” Proceedings of the 1998 Winter Simula-
tion Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivan-
nan. Institute of Electrical and Electronics Engineers, Piscataway, New Jersey, 1998,
pp. 1717–21.
5 DATA COLLECTION
AND ANALYSIS
5.1 Introduction
Simulation is all about making better decisions based on accurate information. A
decision can be no better than the information on which it is based. In this chap-
ter, we look at the data-gathering phase of a simulation project that defines the
system being modeled. The result of the data-gathering effort is a conceptual or
mental model of how the system is configured and how it operates. This concep-
tual model may take the form of a written description, a flow diagram, or even a
simple sketch on the back of an envelope. It becomes the basis for the simulation
model that will be created.
Data collection is the most challenging and time-consuming task in simula-
tion. For new systems, information is usually very sketchy and only roughly esti-
mated. For existing systems, there may be years of raw, unorganized data to sort
through. Information is seldom available in a form that is directly usable in build-
ing a simulation model. It nearly always needs to be filtered and massaged to get it
into the right format and to reflect the projected conditions under which the system
is to be analyzed. Many data-gathering efforts end up with lots of data but little
useful information. Data should be gathered purposefully to avoid wasting not only
the modeler’s time but also the time of individuals who are supplying the data.
This chapter presents guidelines and procedures for gathering data. Statistical
techniques for analyzing data and fitting probability distributions to data are also
discussed. The following questions are answered:
• What is the best procedure to follow when gathering data?
• What types of data should be gathered?
115
records of repair times, for example, often lump together the time spent
waiting for repair personnel to become available and the actual time
spent performing the repair. What you would like to do is separate
the waiting time from the actual repair time because the waiting time
is a function of the availability of the repair person, which may vary
depending on the system operation.
4. Look for common groupings. When dealing with lots of variety in a
simulation such as hundreds of part types or customer profiles, it helps
to look for common groupings or patterns. If, for example, you are
modeling a process that has 300 entity types, it may be difficult to get
information on the exact mix and all of the varied routings that can
occur. Having such detailed information is usually too cumbersome to
work with even if you did have it. The solution is to reduce the data
to common behaviors and patterns. One way to group common data is
to first identify general categories into which all data can be assigned.
Then the percentage of cases that fall within each category is calculated
or estimated. It is not uncommon for beginning modelers to attempt to
use actual logged input streams such as customer arrivals or material
shipments when building a model. After struggling to define hundreds
of individual arrivals or routings, it begins to dawn on them that they
can group this information into a few categories and assign probabilities
that any given instance will fall within a particular category. This allows
dozens and sometimes hundreds of unique instances to be described in a
few brief commands. The secret to identifying common groupings is to
“think probabilistically.”
5. Focus on essence rather than substance. A system definition for
modeling purposes should capture the cause-and-effect relationships
and ignore the meaningless (to simulation) details. This is called system
abstraction and seeks to define the essence of system behavior rather
than the substance. A system should be abstracted to the highest level
possible while still preserving the essence of the system operation.
Using this “black box” approach to system definition, we are not
concerned about the nature of the activity being performed, such as
milling, grinding, or inspection. We are interested only in the impact
that the activity has on the use of resources and the delay of entity flow.
A proficient modeler constantly is thinking abstractly about the system
operation and avoids getting caught up in the mechanics of the process.
6. Separate input variables from response variables. First-time modelers
often confuse input variables that define the operation of the system
with response variables that report system performance. Input variables
define how the system works (interarrival times, activity times, routing
sequences, machine downtime, and the like) and should be the focus of
the data gathering. Response variables describe how the system responds
to a given set of input variables (amount of work in process, resource
operational information is easy to define. If, on the other hand, the process has
evolved into an informal operation with no set rules, it can be very difficult to
define. For a system to be simulated, operating policies that are undefined and
ambiguous must be codified into defined procedures and rules. If decisions and
outcomes vary, it is important to at least define this variability statistically using
probability expressions or distributions.
Station 3B
go and defines what happens to the entity, not where it happens. An entity flow
diagram, on the other hand, is more of a routing chart that shows the physical
movement of entities through the system from location to location. An entity flow
diagram should depict any branching that may occur in the flow such as rout-
ings to alternative work centers or rework loops. The purpose of the entity flow
diagram is to document the overall flow of entities in the system and to provide a
visual aid for communicating the entity flow to others. A flow diagram is easy to
understand and gets everyone thinking in the same way about the system. It can
easily be expanded as additional information is gathered to show activity times,
where resources are used, and so forth.
Using the entity flow diagram and information provided, a summary descrip-
tion of operation is created using a table format, as shown in Table 5.1.
Check-in counter N(1,.2) min. Secretary Waiting room None 0.2 min. None
Waiting room None None Exam room When room is 0.8 min.* Nurse
available
Exam room N(15,4) min. Doctor Checkout counter None 0.2 min. None
Checkout counter N(3,.5) min. Secretary Exit None None None
Notice that the description of operation really provides the details of the en-
tity flow diagram. This detail is needed for defining the simulation model. The
times associated with activities and movements can be just estimates at this stage.
The important thing to accomplish at this point is simply to describe how entities
are processed through the system.
The entity flow diagram, together with the description of operation, provides
a good data document that can be expanded as the project progresses. At this
point, it is a good idea to conduct a structured walk-through of the operation using
the entity flow diagram as the focal point. Individuals should be involved in this
review who are familiar with the operation to ensure that the description of opera-
tion is accurate and complete.
Based on this description of operation, a first cut at building the model can
begin. Using ProModel, a model for simulating Dr. Brown’s practice can be built
in a matter of just a few minutes. Little translation is needed as both the diagram
(Figure 5.2) and the data table (Table 5.1) can be entered pretty much in the same
way they are shown. The only additional modeling information required to build
a running model is the interarrival time of patients.
Getting a basic model up and running early in a simulation project helps hold
the interest of stakeholders. It also helps identify missing information and moti-
vates team members to try to fill in these information gaps. Additional questions
about the operation of the system are usually raised once a basic model is running.
Some of the questions that begin to be asked are “Have all of the routings been
accounted for?” and “Have any entities been overlooked?” In essence, modeling
the system actually helps define and validate system data.
At this point, any numerical values such as activity times, arrival rates, and
others should also be firmed up. Having a running model enables estimates and
other assumptions to be tested to see if it is necessary to spend additional time
getting more accurate information. For existing systems, obtaining more accurate
data is usually accomplished by conducting time studies of the activity or event
under investigation. A sample is gathered to represent all conditions under which
the activity or event occurs. Any biases that do not represent normal operating
conditions are eliminated. The sample size should be large enough to provide
an accurate picture yet not so large that it becomes costly without really adding
additional information.
For comparative studies in which two design alternatives are evaluated, the
fact that assumptions are made is less significant because we are evaluating rel-
ative performance, not absolute performance. For example, if we are trying to
determine whether on-time deliveries can be improved by assigning tasks to a re-
source by due date rather than by first-come, first-served, a simulation can provide
useful information to make this decision without necessarily having completely
accurate data. Because both models use the same assumptions, it may be possible
to compare relative performance. We may not know what the absolute perfor-
mance of the best option is, but we should be able to assess fairly accurately how
much better one option is than another.
Some assumptions will naturally have a greater influence on the validity of
a model than others. For example, in a system with large processing times com-
pared to move times, a move time that is off by 20 percent may make little or no
difference in system throughput. On the other hand, an activity time that is off by
20 percent could make a 20 percent difference in throughput. One way to assess
the influence of an assumption on the validity of a model is through sensitivity
analysis. Sensitivity analysis, in which a range of values is tested for potential im-
pact on model performance, can indicate just how accurate an assumption needs
to be. A decision can then be made to firm up the assumption or to leave it as is.
If, for example, the degree of variation in a particular activity time has little or no
impact on system performance, then a constant activity time may be used. At the
other extreme, it may be found that even the type of distribution has a noticeable
impact on model behavior and therefore needs to be selected carefully.
A simple approach to sensitivity analysis for a particular assumption is to
run three different scenarios showing (1) a “best” or most optimistic case, (2) a
“worst” or most pessimistic case, and (3) a “most likely” or best-guess case. These
runs will help determine the extent to which the assumption influences model
behavior. It will also help assess the risk of relying on the particular assumption.
FIGURE 5.3
Descriptive statistics
for a sample data set
of 100 observations.
distribution), and stationarity (the distribution of the data doesn’t change with time)
should be determined. Using data analysis software such as Stat::Fit, data sets can
be automatically analyzed, tested for usefulness in a simulation, and matched to the
best-fitting underlying distribution. Stat::Fit is bundled with ProModel and can be
accessed from the Tools menu after opening ProModel. To illustrate how data are
analyzed and converted to a form for use in simulation, let’s take a look at a data set
containing 100 observations of an inspection operation time, shown in Table 5.2.
By entering these data or importing them from a file into Stat::Fit, a descrip-
tive analysis of the data set can be performed. The summary of this analysis is
displayed in Figure 5.3. These parameters describe the entire sample collection.
Because reference will be made later to some of these parameters, a brief defini-
tion of each is given below.
Mean—the average value of the data.
Median—the value of the middle observation when the data are sorted in
ascending order.
Mode—the value that occurs with the greatest frequency.
TABLE 5.3 100 Outdoor Temperature Readings from 8:00 A.M. to 8:00 P.M.
57 57 58 59 59 60 60 62 62 62
63 63 64 64 65 66 66 68 68 69
70 71 72 72 73 74 73 74 75 75
75 75 76 77 78 78 79 80 80 81
80 81 81 82 83 83 84 84 83 84
83 83 83 82 82 81 81 80 81 80
79 79 78 77 77 76 76 75 74 75
75 74 73 73 72 72 72 71 71 71
71 70 70 70 70 69 69 68 68 68
67 67 66 66 66 65 66 65 65 64
Scatter Plot
This is a plot of adjacent points in the sequence of observed values plotted against
each other. Thus each plotted point represents a pair of consecutive observations
(Xi, Xi1) for i 1, 2, . . . , n 1. This procedure is repeated for all adjacent data
points so that 100 observations would result in 99 plotted points. If the Xi’s are
independent, the points will be scattered randomly. If, however, the data are de-
pendent on each other, a trend line will be apparent. If the Xi’s are positively cor-
related, a positively sloped trend line will appear. Negatively correlated Xi’s will
produce a negatively sloped line. A scatter plot is a simple way to detect strongly
dependent behavior.
Figure 5.4 shows a plot of paired observations using the 100 inspection times
from Table 5.2. Notice that the points are scattered randomly with no defined pat-
tern, indicating that the observations are independent.
Figure 5.5 is a plot of the 100 temperature observations shown in Table 5.3.
Notice the strong positive correlation.
Autocorrelation Plot
If observations in a sample are independent, they are also uncorrelated. Correlated
data are dependent on each other and are said to be autocorrelated. A measure of
the autocorrelation, rho (), can be calculated using the equation
_ _
(xi x)(xij x)
nj
il
______________
2(n j)
FIGURE 5.4
Scatter plot showing
uncorrelated data.
FIGURE 5.5
Scatter plot showing
correlated temperature
data.
where j is the lag or distance between data points; is the standard deviation of
–
the population, approximated by the standard deviation of the sample; and X is
the sample mean. The calculation is carried out to _5 of the length of the data set,
1
FIGURE 5.6
Autocorrelation
graph showing
noncorrelation.
FIGURE 5.7
Autocorrelation graph
showing correlation.
In the case of a time series, this implies that the time origin may be shifted without
affecting the statistical characteristics of the series. Thus the variance for the whole
sample can be used to represent the variance of any subset. If the process being
studied is not stationary, the calculation of autocorrelation is more complex.
The autocorrelation value varies between 1 and 1 (that is, between positive
and negative correlation). If the autocorrelation is near either extreme, the data
are autocorrelated. Figure 5.6 shows an autocorrelation plot for the 100 inspection
time observations from Table 5.2. Notice that the values are near zero, indicating
FIGURE 5.8
Runs test based on
points above and
below the median and
number of turning
points.
little or no correlation. The numbers in parentheses below the x axis are the maxi-
mum autocorrelation in both the positive and negative directions.
Figure 5.7 is an autocorrelation plot for the sampled temperatures in Table 5.3.
The graph shows a broad autocorrelation.
Runs Tests
The runs test looks for runs in the data that might indicate data correlation. A
run in a series of observations is the occurrence of an uninterrupted sequence of
numbers showing the same trend. For instance, a consecutive set of increasing or
decreasing numbers is said to provide runs “up” or “down” respectively. Two types
of runs tests that can be made are the median test and the turning point test. Both
of these tests can be conducted automatically on data using Stat::Fit. The runs test
for the 100 sample inspection times in Table 5.2 is summarized in Figure 5.8. The
result of each test is either do not reject the hypothesis that the series is random or
reject that hypothesis with the level of significance given. The level of significance
is the probability that a rejected hypothesis is actually true—that is, that the test
rejects the randomness of the series when the series is actually random.
The median test measures the number of runs—that is, sequences of num-
bers, above and below the median. The run can be a single number above or below
the median if the numbers adjacent to it are in the opposite direction. If there are
too many or too few runs, the randomness of the series is rejected. This median
runs test uses a normal approximation for acceptance or rejection that requires
that the number of data points above or below the median be greater than 10.
The turning point test measures the number of times the series changes direc-
tion (see Johnson, Kotz, and Kemp 1992). Again, if there are too many turning
points or too few, the randomness of the series is rejected. This turning point runs
test uses a normal approximation for acceptance or rejection that requires more
than 12 data points.
While there are many other runs tests for randomness, some of the most sen-
sitive require larger data sets, in excess of 4,000 numbers (see Knuth 1981). The
number of runs in a series of observations indicates the randomness of those ob-
servations. A few runs indicate strong correlation, point to point. Several runs may
indicate cyclic behavior.
Frequency of
downtimes indicating
occurrence
multiple causes.
Repair time
Testing to see if data are identically distributed can be done in several ways.
One approach is to visually inspect the distribution to see if it has more than
one mode. You may find, for example, that a plot of observed downtime values
is bimodal, as shown in Figure 5.9. The fact that there are two clusters of data
indicates that there are at least two distinct causes of downtimes, each producing
different distributions for repair times. Perhaps after examining the cause of the
downtimes, it is discovered that some were due to part jams that were quickly
fixed while others were due to mechanical failures that took longer to repair.
One type of nonhomogeneous data occurs when the distribution changes over
time. This is different from two or more distributions manifesting themselves over
the same time period such as that caused by mixed types of downtimes. An ex-
ample of a time-changing distribution might result from an operator who works
20 percent faster during the second hour of a shift than during the first hour.
Over long periods of time, a learning curve phenomenon occurs where workers
perform at a faster rate as they gain experience on the job. Such distributions
are called nonstationary or time variant because of their time-changing nature. A
common example of a distribution that changes with time is the arrival rate of cus-
tomers to a service facility. Customer arrivals to a bank or store, for example, tend
to occur at a rate that fluctuates throughout the day. Nonstationary distributions
can be detected by plotting subgroups of data that occur within successive time
intervals. For example, sampled arrivals between 8 A.M. and 9 A.M. can be plotted
separately from arrivals between 9 A.M. and 10 A.M., and so on. If the distribution
is of a different type or is the same distribution but shifted up or down such that
the mean changes value over time, the distribution is nonstationary. This fact will
need to be taken into account when defining the model behavior. Figure 5.10 is a
plot of customer arrival rates for a department store occurring by half-hour inter-
val between 10 A.M. and 6 P.M. Note that while the type of distribution (Poisson) is
the same for each period, the rate (and hence the mean interarrival time) changes
every half hour.
The second case we look at is where two sets of data have been gathered and
we desire to know whether they come from the same population or are identically
distributed. Situations where this type of testing is useful include the following:
• Interarrival times have been gathered for different days and you want to
know if the data collected for each day come from the same distribution.
FIGURE 5.10
Change in rate of
Rate of arrival
customer arrivals
between 10 A.M. and
6 P.M.
10:00 A.M. 12:00 noon 2:00 P.M. 4:00 P.M. 6:00 P.M.
Time of day
• Activity times for two different operators were collected and you want to
know if the same distribution can be used for both operators.
• Time to failure has been gathered on four similar machines and you are
interested in knowing if they are all identically distributed.
One easy way to tell whether two sets of data have the same distribution is to run
Stat::Fit and see what distribution best fits each data set. If the same distribution
fits both sets of data, you can assume that they come from the same population. If
in doubt, they can simply be modeled as separate distributions.
Several formal tests exist for determining whether two or more data sets can
be assumed to come from identical populations. Some of them apply to specific
families of distributions such as analysis of variance (ANOVA) tests for normally
distributed data. Other tests are distribution independent and can be applied to
compare data sets having any distribution, such as the Kolmogorov-Smirnov two-
sample test and the chi-square multisample test (see Hoover and Perry 1990). The
Kruskal-Wallis test is another nonparametric test because no assumption is made
about the distribution of the data (see Law 2007).
replication. Sample data sets tend to be used directly in a simulation when they
are sampled data from another related simulation model from which it receives its
input. This is a model partitioning technique sometimes used in simulating large
systems. The exit times for entities in one simulation become the arrival stream
used for the model into which it feeds.
Using an empirical distribution requires that the data be converted to either
a continuous or discrete frequency distribution. A continuous frequency distribu-
tion summarizes the percentage of values that fall within given intervals. In the
case of a discrete frequency distribution, it is the percentage of times a particular
value occurs. For continuous frequency distributions the intervals need not be of
equal width. During the simulation, random variates are generated using a con-
tinuous, piecewise-linear empirical distribution function based on the grouped
data (see Law 2007). The drawbacks to using an empirical distribution as input to
a simulation are twofold. First, an insufficient sample size may create an artificial
bias or “choppiness” in the distribution that does not represent the true underlying
distribution. Second, empirical distributions based on a limited sample size often
fail to capture rare extreme values that may exist in the population from which
they were sampled. As a general rule, empirical distributions should be used only
for rough-cut modeling or when the shape is very irregular and doesn’t permit a
good distribution fit. Within ProModel, an empirical distribution is called a user
distribution because the distribution is defined by the user rather than by selecting
a distribution from a menu of predefined theoretical distributions.
Representing the data using a theoretical distribution involves fitting a theo-
retical distribution to the data. During the simulation, random variates are gener-
ated from the probability distribution to provide the simulated random values.
Fitting a theoretical distribution to sample data smooths artificial irregularities
in the data and ensures that extreme values are included. For these reasons, it is
best to use theoretical distributions if a reasonably good fit exists. Most popular
simulation software provide utilities for fitting distributions to numerical data,
thus relieving the modeler from performing this complicated procedure. A mod-
eler should be careful when using a theoretical distribution to ensure that if an
unbounded distribution is used, the extreme values that can be generated are
realistic. Techniques for controlling the range of unbounded distributions in a
simulation model are presented in Chapter 6. Appendix A provides a list of the
theoretical distributions available in ProModel.
0 15 6 7
1 11 7 4
2 19 8 5
3 16 9 3
4 8 10 3
5 8 11 1
FIGURE 5.11
Histogram showing arrival count per five-minute interval.
20
15
Frequency
10
0
0 1 2 3 4 5 6 7 8 9 10 11
Arrival count
FIGURE 5.12
Frequency distribution for 100 observed inspection times.
take on any value within the interval specified. A frequency distribution for the
data has been constructed using Stat::Fit (Figure 5.12).
Note that a relative frequency or density is shown (third column) as well as
cumulative (ascending and descending) frequencies. All of the relative densities
add up to 1, which is verified by the last value in the ascending cumulative fre-
quency column.
A histogram based on this frequency distribution was also created in Stat::Fit
and is shown in Figure 5.13.
Note that the frequency distribution and histogram for our sample inspection
times are based on dividing the data into six even intervals or cells. While there
are guidelines for determining the best interval or cell size, the most important
thing is to make sure that enough cells are defined to show a gradual transition
in values, yet not so many cells that groupings become obscured. The number of
intervals should be based on the total number of observations and the variance in
the data. One rule of thumb is to set the number
1
of intervals to the cube root of
__
twice the number of samples—that is (2N)3. This is the default method used in
Stat::Fit. The goal is to use the minimum number of intervals possible without
losing information about the spread of the data.
FIGURE 5.13
Histogram distribution
for 100 observed
inspection times.
Binomial Distribution
The binomial distribution is a discrete distribution that expresses the probability
( p) that a particular condition or outcome can occur in n trials. We call an occur-
rence of the outcome of interest a success and its nonoccurrence a failure. For
a binomial distribution to apply, each trial must be a Bernoulli trial: it must be
independent and have only two possible outcomes (success or failure), and the
probability of a success must remain constant from trial to trial. The mean of a
binomial distribution is given by np, where n is the number of trials and p is the
probability of success on any given trial. The variance is given by np(1 p).
A common application of the binomial distribution in simulation is to test for
the number of defective items in a lot or the number of customers of a particular
type in a group of customers. Suppose, for example, it is known that the probabil-
ity of a part being defective coming out of an operation is 0.10 and we inspect the
parts in batch sizes of 10. The number of defectives for any given sample can be
determined by generating a binomial random variate. The probability mass func-
tion for the binomial distribution in this example is shown in Figure 5.14.
Uniform Distribution
A uniform or rectangular distribution is used to describe a process in which the
outcome is equally likely to fall between the values of a and b. In a uniform dis-
tribution, the mean is (a b)2. The variance is expressed by (b a)212. The
probability density function for the uniform distribution is shown in Figure 5.15.
The uniform distribution is often used in the early stages of simulation proj-
ects because it is a convenient and well-understood source of random variation. In
FIGURE 5.14 0.6
The probability mass
function of a binomial 0.5
distribution 0.4
(n 10, p 0.10).
p(x)
0.3
0.2
0.1
0
0 1 2 3 4 5 6 7 8 9 10
x
FIGURE 5.15
The probability density
function of a uniform f (x)
distribution.
a b
x
FIGURE 5.16
The probability
density function of a
triangular distribution.
f (x)
a m b
x
the real world, it is extremely rare to find an activity time that is uniformly distrib-
uted because nearly all activity times have a central tendency or mode. Sometimes
a uniform distribution is used to represent a worst-case test for variation when
doing sensitivity analysis.
Triangular Distribution
A triangular distribution is a good approximation to use in the absence of data,
especially if a minimum, maximum, and most likely value (mode) can be esti-
mated. These are the three parameters of the triangular distribution. If a, m, and b
represent the minimum, mode, and maximum values respectively of a triangular
distribution, then the mean of a triangular distribution is (a m b)3. The vari-
ance is defined by (a2 m2 b2 am ab mb)18. The probability density
function for the triangular distribution is shown in Figure 5.16.
The weakness of the triangular distribution is that values in real activity times
rarely taper linearly, which means that the triangular distribution will probably
create more variation than the true distribution. Also, extreme values that may be
rare are not captured by a triangular distribution. This means that the full range
of values of the true distribution of the population may not be represented by the
triangular distribution.
Normal Distribution
The normal distribution (sometimes called the Gaussian distribution) describes
phenomena that vary symmetrically above and below the mean (hence the bell-
shaped curve). While the normal distribution is often selected for defining activity
times, in practice manual activity times are rarely ever normally distributed. They
are nearly always skewed to the right (the ending tail of the distribution is longer
than the beginning tail). This is because humans can sometimes take significantly
longer than the mean time, but usually not much less than the mean time. Examples
of normal distributions might be
• Physical measurements—height, length, diameter, weight.
• Activities involving multiple tasks (like loading a truck or filling a
customer order).
FIGURE 5.17
The probability density
function for a normal
distribution.
f (x)
The mean of the normal distribution is designated by the Greek letter mu (). The
variance is 2 where (sigma) is the standard deviation. The probability density
function for the normal distribution is shown in Figure 5.17.
Exponential Distribution
Sometimes referred to as the negative exponential, this distribution is used fre-
quently in simulations to represent event intervals. The exponential distribution
is defined by a single parameter, the mean (). This distribution is related to the
Poisson distribution in that if an occurrence happens at a rate that is Poisson
distributed, the time between occurrences is exponentially distributed. In other
words, the mean of the exponential distribution is the inverse of the Poisson rate.
For example, if the rate at which customers arrive at a bank is Poisson distributed
with a rate of 12 per hour, the time between arrivals is exponentially distributed
with a mean of 5 minutes. The exponential distribution has a memoryless or for-
getfulness property that makes it well suited for modeling certain phenomena that
occur independently of one another. For example, if arrival times are exponen-
tially distributed with a mean of 5 minutes, then the expected time before the next
arrival is 5 minutes regardless of how much time has elapsed since the previous
arrival. It is as though there is no memory of how much time has already elapsed
when predicting the next event—hence the term memoryless. Examples of this
distribution are
• Time between customer arrivals at a bank.
• Duration of telephone conversations.
• Time between arrivals of planes at a major airport.
• Time between failures of certain types of electronic devices.
• Time between interrupts of the CPU in a computer system.
FIGURE 5.18
The probability
density function
for an exponential
distribution.
f(x)
FIGURE 5.19
Ranking distributions by goodness of fit for inspection time data set.
may be inferred. Looking at the histogram in Figure 5.13, and knowing the basic
shapes of different theoretical distributions, we might hypothesize that the data
come from a beta, lognormal, or perhaps even a triangular distribution.
After a particular type of distribution has been selected, we must estimate
the defining parameter values of the distribution based on the sample data. In the
case of a normal distribution, the parameters to be estimated are the mean and
standard deviation, which can be estimated by simply calculating the average
and standard deviation of the sample data. Parameter estimates are generally cal-
culated using moment equations or the maximum likelihood equation (see Law
2007).
Once a candidate distribution with its associated parameters has been defined,
a goodness-of-fit test can be performed to evaluate how closely the distribution fits
the data. A goodness-of-fit test measures the deviation of the sample distribution
from the inferred theoretical distribution. Three commonly used goodness-of-fit
tests are the chi-square (2), the Kolmogorov-Smirnov, and the Anderson-Darling
tests (see Breiman 1973; Banks et al. 2001; Law 2007; Stuart and Ord 1991).
Each of these goodness-of-fit tests starts with the null hypothesis that the fit
is good and calculates a test statistic for comparison to a standard. To test this
The alternate hypothesis (H1) is that the observations are not uniformly
distributed between 7 and 17 seconds.
Step 2: Create a frequency distribution of the data with equiprobable
cells based on the inferred distribution. To create a frequency
distribution, recall that a good 1rule of thumb for determining the appropriate
__
number of cells (k) is k (2n)3. Normally a frequency distribution is
divided into cells of equal intervals. When conducting a chi-square test,
however, it often works better if cell intervals have equal probabilities rather
than equal interval ranges. If, for example, you want to create a frequency
distribution with six cells for a particular data set, and you suspect that
the data come from a normal distribution, you would create equiprobable
intervals that each take in one-sixth of the population of the corresponding
normal distribution. 1 1
__ __
For this example, k (2n)3 (2 40)3 4.3 5. Because we are
assuming a uniform distribution in which equal interval widths also have equal
probabilities, we can divide the range into five equal intervals each with a
cell width of 105 2 and a probability of 15 .20. For each cell (i), the
resultant observed frequency (oi) is shown in Table 5.6 together with the
hypothesized probability (pi). That each cell has a probability of .2 based
9 9
p(7 x 9) f (x)dx ___ x 9 ___
1 dx ___ 9 ___
7 ___
2 .20.
7 7 10 10 7 10 10 10
For a uniform distribution the probabilities for all intervals are equal, so the
remaining intervals also have a hypothesized probability of .20.
Step 3: Calculate the expected frequency for each cell (ei). The expected
frequency (e) for each cell (i) is the expected number of observations that
would fall into each interval if the null hypothesis were true. It is calculated
by multiplying the total number of observations (n) by the probability
(p) that an observation would fall within each cell. So for each cell, the
expected frequency (ei) equals npi.
In our example, since the hypothesized probability (p) of each cell is
the same, the expected frequency for every cell is ei npi 40 .2 8.
Step 4: Adjust cells if necessary so that all expected frequencies are
at least 5. If the expected frequency of any cell is less than 5, the cells
must be adjusted. This “rule of five” is a conservative rule that provides
satisfactory validity of the chi-square test. When adjusting cells, the easiest
approach is to simply consolidate adjacent cells. After any consolidation,
the total number of cells should be at least 3; otherwise you no longer
have a meaningful differentiation of the data and, therefore, will need to
gather additional data. If you merge any cells as the result of this step, you
will need to adjust the observed frequency, hypothesized probability, and
expected frequency of those cells accordingly.
In our example, the expected frequency of each cell is 8, which meets
the minimum requirement of 5, so no adjustment is necessary.
Step 5: Calculate the chi-square statistic. The equation for calculating
the chi-square statistic is 2calc i1 (oi ei)2ei. If the fit is good the chi-
k
distribution with two parameters (mean and standard deviation) that are
estimated from the data, s 2. In Stat::Fit the number of degrees of
freedom is assumed to be k 1.
Step 7: Choose a desired level of significance (␣). The significance level is
the probability of rejecting the null hypothesis when it is true—that is, when
the hypothesized distribution is correct. A typical level of significance is
.05; however, it could also be .10 or any other desired value.
For our example we will use a level of significance () of .05.
Step 8: Find the critical chi-square value from the chi-square table. A
chi-square table can be found in Appendix D. The critical values in the chi-
square table are based on the number of degrees of freedom (k 1) and the
desired level of significance ().
For our example,
2kl, 24,0.05 9.488
FIGURE 5.20
Visual comparison
between beta
distribution and a
histogram of the 100
sample inspection time
values.
the data. Figure 5.20, for example, overlays a beta distribution (the distribution
with the highest fit ranking for this particular data set) on top of a histogram of
the data.
FIGURE 5.21
Normal distribution with mean 1 and standard deviation .25.
FIGURE 5.22
A triangular
distribution with
minimum 2,
mode 5, and
maximum 15.
2 5 15
to be the most realistic. Minimum, most likely, and maximum values closely re-
semble a triangular or a beta distribution. Examples of minimum, most likely, and
maximum values might be
• 2 to 15 with most likely 5 minutes to repair a machine.
• 3 to 5 with most likely 2.5 minutes between customer arrivals.
• 1 to 3 with most likely 1.5 minutes to complete a purchase order.
Minimum, most likely, and maximum values can be easily set up as a triangular
distribution. Looking at the first repair time example, if we fit these times to a
triangular distribution, it would produce a minimum of 2 minutes, a mode of
5 minutes and a maximum of 15 minutes (see Figure 5.22).
Because these values are still based only on estimates, it is a good idea to per-
form a sensitivity analysis, especially on the mode value (assuming the minimum
and maximum values represent best- and worst-case possibilities, respectively).
Objective
The objective of the study is to determine station utilization and throughput of
the system.
Entities
19" monitor
21" monitor
25" monitor
Workstation Information
Station 1 5 5%
Station 2 8 8%
Station 3 5 0%
Inspection 5 0%
Processing Sequence
Arrivals
A cartload of four monitor assemblies arrives every four hours normally distrib-
uted with a standard deviation of 0.2 hour. The probability of an arriving monitor
being of a particular size is
19" .6
21" .3
25" .1
Move Times
All movement is on an accumulation conveyor with the following times:
Station 1 Station 2 12
Station 2 Inspection 15
Inspection Station 3 12
Inspection Station 1 20
Inspection Station 2 14
Station 1 Inspection 18
Move Triggers
Entities move from one location to the next based on available capacity of the
input buffer at the next location.
Work Schedule
Stations are scheduled to operate eight hours a day.
Assumption List
• No downtimes (downtimes occur too infrequently).
• Dedicated operators at each workstation are always available during the
scheduled work time.
• Rework times are half of the normal operation times.
5.13 Summary
Data for building a model should be collected systematically with a view of how
the data are going to be used in the model. Data are of three types: structural, op-
erational, and numerical. Structural data consist of the physical objects that make
up the system. Operational data define how the elements behave. Numerical data
quantify attributes and behavioral parameters.
When gathering data, primary sources should be used first, such as historical
records or specifications. Developing a questionnaire is a good way to request in-
formation when conducting personal interviews. Data gathering should start with
structural data, then operational data, and finally numerical data. The first piece
of the puzzle to be put together is the routing sequence because everything else
hinges on the entity flow.
Numerical data for random variables should be analyzed to test for indepen-
dence and homogeneity. Also, a theoretical distribution should be fit to the data
if there is an acceptable fit. Some data are best represented using an empirical
distribution. Theoretical distributions should be used wherever possible.
Data should be documented, reviewed, and approved by concerned individu-
als. This data document becomes the basis for building the simulation model and
provides a baseline for later modification or for future studies.
Type A B C D E
Observations 10 14 12 9 5
20. While doing your homework one afternoon, you notice that you are
frequently interrupted by friends. You decide to record the times
between interruptions to see if they might be exponentially distributed.
Here are 30 observed times (in minutes) that you have recorded;
conduct a goodness-of-fit test to see if the data are exponentially
distributed. (Hint: Use the data average as an estimate of the mean. For
the range, assume a range between 0 and infinity. Divide the cells based
on equal probabilities (pi) for each cell rather than equal cell intervals.)
This exercise is intended to help you practice sorting through and organizing data on a
service facility. The facility is a fast-food restaurant called Harry’s Drive-Through and is
shown below.
Harry’s Drive-Through caters to two types of customers, walk-in and drive-through.
During peak times, walk-in customers arrive exponentially every 4 minutes and place their
order, which is sent to the kitchen. Nonpeak arrivals occur every 8–10 minutes. Custom-
ers wait in a pickup queue while their orders are filled in the kitchen. Two workers are
assigned to take and deliver orders. Once customers pick up their orders, 60 percent of the
customers stay and eat at a table, while the other 40 percent leave with their orders. There
is seating for 30 people, and the number of people in each customer party is one 40 percent
of the time, two 30 percent of the time, three 18 percent of the time, four 10 percent of
the time, and five 2 percent of the time. Eating time is normally distributed with a mean
Drive-through order
Kitchen
Drive-through
pickup
Pickup Order
Table area
of 15 minutes and a standard deviation of 2 minutes. If a walk-in customer enters and sees
that more than 15 customers are waiting to place their orders, the customer will balk (that
is, leave).
Harry’s is especially popular as a drive-through restaurant. Cars enter at a rate of 10 per
hour during peak times, place their orders, and then pull forward to pick up their orders. No
more than five cars can be in the pickup queue at a time. One person is dedicated to taking
orders. If over seven cars are at the order station, arriving cars will drive on.
The time to take orders is uniformly distributed between 0.5 minute and 1.2 minutes
including payment. Orders take an average of 8.2 minutes to fill with a standard deviation
of 1.2 minutes (normal distribution). These times are the same for both walk-in and drive-
through customers.
The objective of the simulation is to analyze performance during peak periods to see
how long customers spend waiting in line, how long lines become, how often customers
balk (pass by), and what the utilization of the table area is.
Problem
Summarize these data in table form and list any assumptions that need to be made in order
to conduct a meaningful simulation study based on the data given and objectives specified.
References
Banks, Jerry; John S. Carson II; Barry L. Nelson; and David M. Nicol. Discrete-Event
System Simulation. 5th ed. Englewood Cliffs, NJ: Prentice Hall, 2009.
Banks, Jerry, and Randall R. Gibson. “Selecting Simulation Software.” IIE Solutions, May
1997, pp. 29–32.
———. Stat::Fit. South Kent, CT: Geer Mountain Software Corporation, 1996.
Breiman, Leo. Statistics: With a View toward Applications. New York: Houghton Mifflin,
1973.
Brunk, H. D. An Introduction to Mathematical Statistics. 2nd ed. N.Y.: Blaisdell Publish-
ing Co. 1965.
Carson, John S. “Convincing Users of Model’s Validity Is Challenging Aspect of Mod-
eler’s Job.” Industrial Engineering, June 1986, p. 77.
Hoover, S. V., and R. F. Perry. Simulation: A Problem Solving Approach. Reading, MA,
Addison-Wesley, 1990.
Johnson, Norman L.; Samuel Kotz; and Adrienne W. Kemp. Univariate Discrete Distribu-
tions. New York: John Wiley & Sons, 1992, p. 425.
Knuth, Donald E. Seminumerical Algorithms. Reading, MA: Addison-Wesley, 1981.
Law, Averill M. Simulation Modeling & Analysis. 4th ed. New York: McGraw-Hill, 2007.
Stuart, Alan, and J. Keith Ord. Kendall’s Advanced Theory of Statistics. vol. 2. Cambridge:
Oxford University Press, 1991.
6 MODEL BUILDING
“Every theory [model] should be stated [built] as simply as possible, but not
simpler.”
—Albert Einstein
6.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. Learn-
ing to use modern, easy-to-use software is one of the least difficult aspects of
modeling. Indeed, current simulation software makes poor and inaccurate models
easier to create than ever before. Unfortunately, software cannot make decisions
about how the elements of a particular system operate and how they should inter-
act 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 sci-
ence 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 rep-
resentative 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 simula-
tion analysts are able to quickly translate a process into a simulation model
161
user defines a model using a particular simulation product is based on the model-
ing 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
differences are minor. Historically, simulation products required models to be
defined line by line, specifying a list of instructions like a script for processing en-
tities. 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 associated with the object. This logic gets executed either whenever certain
events occur or when explicitly called in the model. Examples of behavioral logic
include operations, machine setup, routing decisions, and material movement. Ex-
amples of events or conditions that may trigger a behavior might be the comple-
tion 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
behavior. 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 signifi-
cant 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
describe 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 terms of the same structural and operational elements that were described in
Chapter 5. This is essentially how models are defined using ProModel.
FIGURE 6.1
Relationship between
model complexity and
model utility (also
known as the Laffer
Complexity
curve).
Optimum level of
model complexity
Utility
6.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 de-
fine 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.
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 al-
ways be available due to delays, then it might be necessary to simulate the flow of
component 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 6.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 rep-
resented by a single entity (see Figure 6.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
Type A
Type B
Type X
Type C 9 entities 1 entity
FIGURE 6.2 FIGURE 6.3
Treating different entity types Treating multiple entities
as a single type. as a single entity.
6.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
without spending any time, it probably isn’t necessary to include the location. For
example, 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).
• 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 re-
sulting 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 6.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 machines
could be modeled as a single location with a capacity equal to three. Combining
locations can significantly reduce model size, especially when the number of par-
allel units gets very large, such as a 20-station checkout area in a large shopping
center or a 100-seat dining area in a restaurant.
FIGURE 6.4
Example of combining
three parallel stations Capacity ⫽ 1
into a single station.
Operation 10 Operation 30
Capacity ⫽ 1
Operation 20
1 min. each
FIGURE 6.5
Example of combining three serial stations into a single station.
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
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 6.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 approxi-
mation for the intended purpose of the simulation.
6.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.
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
including 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.
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 re-
sources 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 ex-
ample, 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. Exam-
ples of transport resources are lift trucks, elevators, cranes, buses, and airplanes.
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 trans-
porter may even have a prescribed route it follows, similar to an entity routing.
A common example of this is a bus route.
6.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
entities and resources along the shortest path sequence between two locations.
Optionally, you can explicitly define the path sequence to take to get from one
point to any other point in the network.
6.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.
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 select-
ing 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 loca-
tions have or haven’t been visited. Entity attributes are usually the most practical
way of tracking this information. An attribute may be defined for each possible
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.
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 6.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
situations 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,
allowing them to later be separated, or permanent, in which case the consolidated
entities no longer retain their individual identities. Figure 6.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 attaching a shipping document to an order ready for delivery, assembling
FIGURE 6.6
Consolidation
of entities into a before after
single entity. In (a)
(a) permanent
consolidation, batched
entities get destroyed.
In (b) temporary
consolidation, batched
entities are preserved before
(b) after
for later unbatching.
FIGURE 6.7
Attachment of one
or more entities to
another entity.
In (a) permanent after
attachment, the
attached entities before
get destroyed. (a)
In (b) temporary
attachment, the
attached entities are
preserved for later
detachment.
after
before
(b)
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 ac-
counting. 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 6.8.
FIGURE 6.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 before
(the original entity
after
continues).
(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 cre-
ated from an existing entity using a CREATE statement. Alternatively, entities can be
conveniently split or created using the routing options provided in ProModel.
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
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 external file, especially when the number of scheduled arrivals is large
and the schedule 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
arrival 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
simulate 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 6.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.
FIGURE 6.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
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
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.
3. Model the move using a path network that requires the moving entity or
resource to contend with traffic.
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.
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
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. 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 orga-
nizations 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.
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
location 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 preempted
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
preemption. 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
necessary 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
machining 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.
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 an-
ticipated time to complete the task at hand. Interrupting a task usually requires
only that a preemptive 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 situ-
ation is when several tasks are waiting that must be processed before going
off schedule (for example, a checkout 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.
failure. For example, if the operational time between failures is exponentially dis-
tributed with a mean of 10 minutes and the repair time is exponentially distributed
with a 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.
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
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.
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
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:
In use 20
Down 5
Idle 15
Total time 40
A similar situation occurs in activity times that have more than one dis-
tribution. 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
Triangular(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
A .20 E(5)
B .50 E(8)
C .30 E(12)
handle calls is exponentially distributed, but the mean time is different depend-
ing on the type of call (see Table 6.1). To model this situation, the following code
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
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 state-
ments to be executed repeatedly by an object as long as the local variable Count is
less than 11.
• 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.
6.6 Summary
Model building is a process that takes a conceptual model and converts it to a
simulation model. This requires a knowledge of the modeling paradigm of the
particular 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, to be successful at modeling you need to see lots of examples
and practice, practice, practice!
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.
7 MODEL VERIFICATION
AND VALIDATION
7.1 Introduction
Building a simulation model is much like developing an architectural plan for a
house. A good architect will review the plan and specifications with the client or
owner of the house to ensure that the design meets the client’s expectations. The
architect will also carefully check all dimensions and other specifications shown on
the plan for accuracy. Once the architect is reasonably satisfied that the right infor-
mation has been accurately represented, a contractor can be given the plan to begin
building the house. In a similar way the simulation analyst should examine the valid-
ity and correctness of the model before using it to make implementation decisions.
In this chapter we cover the importance and challenges associated with model
verification and validation. We also present techniques for verifying and validat-
ing models. Balci (1997) provides a taxonomy of more than 77 techniques for
model verification and validation. In this chapter we give only a few of the more
common and practical methods used. The greatest problem with verification and
validation is not one of failing to use the right techniques but failing to use any
technique. Questions addressed in this chapter include the following:
• What are model verification and validation?
• What are obstacles to model verification and validation?
• What techniques are used to verify and validate a model?
• How are model verification and validation maintained?
Two case studies are presented at the end of the chapter showing how verifi-
cation and validation techniques have been used in actual simulation projects.
193
Ve
r ific
at
io
n
Model
what changes need to be made to model new scenarios becomes difficult if not
impossible.
The solution to creating models that ease the difficulty of verification and
validation is to first reduce the amount of complexity of the model. Frequently
the most complex models are built by amateurs who do not have sense enough
to know how to abstract system information. They code way too much detail
into the model. Once a model has been simplified as much as possible, it needs
to be coded so it is easily readable and understandable. Using object-oriented
techniques such as encapsulation can help organize model data. The right simu-
lation software can also help keep model data organized and readable by provid-
ing table entries and intelligent, parameterized constructs rather than requiring
lots of low-level programming. Finally, model data and logic code should be
thoroughly and clearly documented. This means that every subroutine used
should have an explanation of what it does, where it is invoked, what the param-
eters represent, and how to change the subroutine for modifications that may be
anticipated.
techniques discussed here, such as event tracing and code debugging, can help
identify and correct semantic errors.
In the top-down approach, the verification testing begins with the main mod-
ule and moves down gradually to lower modules. At the top level, you are more
interested that the outputs of modules are as expected given the inputs. If discrep-
ancies arise, lower-level code analysis is conducted.
In both approaches sample test data are used to test the program code. The
bottom-up approach typically requires a smaller set of data to begin with. After
exercising the model using test data, the model is stress tested using extreme input
values. With careful selection, the results of the simulation under extreme condi-
tions can be predicted fairly well and compared with the test results.
FIGURE 7.2
Fragment of a trace
listing.
FIGURE 7.3
ProModel debugger
window.
state values as they dynamically change. Like trace messaging, debugging can
be turned on either interactively or programmatically. An example of a debugger
window is shown in Figure 7.3.
Experienced modelers make extensive use of trace and debugging capabili-
ties. Animation and output reports are good for detecting problems in a simula-
tion, but trace and debug messages help uncover why problems occur.
Using trace and debugging features, event occurrences and state variables
can be examined and compared with hand calculations to see if the program is
operating as it should. For example, a trace list might show when a particular op-
eration began and ended. This can be compared against the input operation time
to see if they match.
One type of error that a trace or debugger is useful in diagnosing is gridlock.
This situation is caused when there is a circular dependency where one action
depends on another action, which, in turn, is dependent on the first action. You
may have experienced this situation at a busy traffic intersection or when trying
to leave a crowded parking lot after a football game. It leaves you with a sense
of utter helplessness and frustration. An example of gridlock in simulation some-
times occurs when a resource attempts to move a part from one station to another,
but the second station is unavailable because an entity there is waiting for the
same resource. The usual symptom of this situation is that the model appears to
freeze up and no more activity takes place. Meanwhile the simulation clock races
rapidly forward. A trace of events can help detect why the entity at the second sta-
tion is stuck waiting for the resource.
real system. The modeler should have at least an intuitive idea of how the
model will react to a given change. It should be obvious, for example,
that doubling the number of resources for a bottleneck operation should
increase, though not necessarily double, throughput.
• Running traces. An entity or sequence of events can be traced through the
model processing logic to see if it follows the behavior that would occur
in the actual system.
• Conducting Turing tests. People who are knowledgeable about the
operations of a system are asked if they can discriminate between system
and model outputs. If they are unable to detect which outputs are the
model outputs and which are the actual system outputs, this is another
piece of evidence to use in favor of the model being valid.
A common method of validating a model of an existing system is to compare
the model performance with that of the actual system. This approach requires that
an as-is simulation be built that corresponds to the current system. This helps “cali-
brate” the model so that it can be used for simulating variations of the same model.
After running the as-is simulation, the performance data are compared to those of
the real-world system. If sufficient data are available on a performance measure
of the real system, a statistical test can be applied called the Student’s t test to
determine whether the sampled data sets from both the model and the actual system
come from the same distribution. An F test can be performed to test the equality
of variances of the real system and the simulation model. Some of the problems
associated with statistical comparisons include these:
• Simulation model performance is based on very long periods of time.
On the other hand, real system performances are often based on much
shorter periods and therefore may not be representative of the long-term
statistical average.
• The initial conditions of the real system are usually unknown and are
therefore difficult to replicate in the model.
• The performance of the real system is affected by many factors that may
be excluded from the simulation model, such as abnormal downtimes or
defective materials.
The problem of validation becomes more challenging when the real system
doesn’t exist yet. In this case, the simulation analyst works with one or more ex-
perts who have a good understanding of how the real system should operate. They
team up to see whether the simulation model behaves reasonably in a variety of
situations. Animation is frequently used to watch the behavior of the simulation
and spot any nonsensical or unrealistic behavior.
The purpose of validation is to mitigate the risk associated with making deci-
sions based on the model. As in any testing effort, there is an optimum amount
of validation beyond which the return may be less valuable than the investment
(see Figure 7.4). The optimum effort to expend on validation should be based
on minimizing the total cost of the validation effort plus the risk cost associated
Cost
risk cost.
Risk cost
Validation effort
informal and intuitive approach to validation, while the HP case study relies on
more formal validation techniques.
modeled). The animation that showed the actual movement of patients and use of
resources was a valuable tool to use during the validation process and increased
the credibility of the model.
The use of a team approach throughout the data-gathering and model devel-
opment stages proved invaluable. It both gave the modeler immediate feedback
regarding incorrect assumptions and boosted the confidence of the team members
in the simulation results. The frequent reviews also allowed the group to bounce
ideas off one another. As the result of conducting a sound and convincing simula-
tion study, the hospital’s administration was persuaded by the simulation results
and implemented the recommendations in the new construction.
assumptions were defined based on process information gathered from the pro-
cess owners. As the model development progressed, further assumptions were
made, and decisions were made and agreed upon regarding the level of detail
required to capture the essence of the process.
The flow logic and move times were built into the model, but processing and
setup times, since they were so varied and numerous, were put into a common
lookup table so they could be verified and modified easily. The particular board
sequence and batch size were also defined for the model.
The next step was to verify the model to ensure that it operated as intended.
The simulation output was reviewed for reasonableness and a trace was used to
check the model logic where it was complex. In reality, much of this verification
was performed as the model was built because it was necessary for getting the
model just to run. Note that the modeler was the one primarily responsible for
verifying or debugging the model. This makes sense inasmuch as the modeler had
a clear specification and was the one responsible for fashioning the model to fit
the specification.
After the modeler was satisfied that the model was running correctly, all of
the assumptions were reviewed again by the production operators, supervisors,
and engineers. These assumptions were more meaningful as they were able to
watch their impact on the simulation performance. Animation was used to com-
municate model behavior and demonstrate the scope of the model. Those who
were familiar with the operation of the real line were able to confirm whether
the model appeared to be working reasonably correctly. When explaining how
the model was built, it was important to describe the modeling constructs using
familiar terminology because the process owners were not versed in modeling
terminology.
At this point it would be easy to conclude that the model was valid and ready
for use in conducting experiments. The challenging question with the model be-
came “Is it the right model?” A simulation model is viewed much more critically
once it is running and it is realized that important decisions will soon be based
on the results of the simulation experiments. With the model running correctly
and providing output that was consistent with the assumptions that were made,
it was felt that the assumptions should be challenged more critically. Because
the initial data that were gathered—that is, processing times and setup times—
were based on average times with no reflection of variability, decisions had to be
made about how much more data should be gathered or what modifications in as-
sumptions needed to be made before there was sufficient confidence in the model.
Component placement times were studied using classical time-study techniques
to achieve more realistic time estimates. Next the average placement times were
used to calculate the average run time for a particular panel, and these were com-
pared to the recorded run times.
Historical data and further time studies were used to validate the output. A
particular sequence of panels was studied as it was processed, recording the batch
size, the start time, the finish time, and some intermediate times. The model was
then run using this exact same scenario, and the output was compared with the
output of the real process. The initial model predicted 25 shifts to complete a
specific sequence of panels, while the process actually took 35 shifts. This led
to further process investigations of interruptions or other processing delays that
weren’t being accounted for in the model. It was discovered that feeder replace-
ment times were underestimated in the model. A discrepancy between the model
and the actual system was also discovered in the utilization of the pick-and-place
machines. After tracking down the causes of these discrepancies and making ap-
propriate adjustments to the model, the simulation results were closer to the real
process. The challenge at this stage was not to yield to the temptation of making
arbitrary changes to the model just to get the desired results. Then the model would
lose its integrity and become nothing more than a sham for the real system.
The final step was to conduct sensitivity analysis to determine how model per-
formance was affected in response to changes in model assumptions. By changing
the input in such a way that the impact was somewhat predictable, the change in
simulation results could be compared with intuitive guesses. Any bizarre results
such as a decrease in work in process when increasing the arrival rate would
raise an immediate flag. Input parameters were systematically changed based on
a knowledge of both the process behavior and the model operation. Knowing
just how to stress the model in the right places to test its robustness was an art in
itself. After everyone was satisfied that the model accurately reflected the actual
operation and that it seemed to respond as would be expected to specific changes
in input, the model was ready for experimental use.
7.5 Summary
For a simulation model to be of greatest value, it must be an accurate representa-
tion of the system being modeled. Verification and validation are two activities
that should be performed with simulation models to establish their credibility.
Model verification is basically the process of debugging the model to ensure
that it accurately represents the conceptual model and that the simulation runs cor-
rectly. Verification involves mainly the modeler without the need for much input
from the customer. Verification is not an exact science, although several proven
techniques can be used.
Validating a model begins at the data-gathering stage and may not end until
the system is finally implemented and the actual system can be compared to the
model. Validation involves the customer and other stakeholders who are in a posi-
tion to provide informed feedback on whether the model accurately reflects the
real system. Absolute validation is philosophically impossible, although a high
degree of face or functional validity can be established.
While formal methods may not always be used to validate a model, at least
some time devoted to careful review should be given. The secret to validation is
not so much the technique as it is the attitude. One should be as skeptical as can
be tolerated—challenging every input and questioning every output. In the end,
the decision maker should be confident in the simulation results, not because he or
she trusts the software or the modeler, but because he or she trusts the input data
and knows how the model was built.
References
Balci, Osman. “Verification, Validation and Accreditation of Simulation Models.” In Pro-
ceedings of the 1997 Winter Simulation Conference, ed. S. Andradottir, K. J. Healy,
D. H. Withers, and B. L. Nelson, 1997, pp. 135–41.
Banks, Jerry. “Simulation Evolution.” IIE Solutions, November 1998, pp. 26–29.
Banks, Jerry; John S. Carson II; Barry L. Nelson; and David M. Nicol. Discrete-Event
System Simulation. 5th ed. Englewood Cliffs, NJ: Prentice Hall, 2009.
Baxter, Lori K., and Johnson, Eric. “Don’t Implement before You Validate.” Industrial
Engineering, February 1993, pp. 60–62.
Hoover, Stewart, and Ronald Perry. Simulation: A Problem Solving Approach. Reading,
MA: Addison-Wesley, 1990.
Neelamkavil, F. Computer Simulation and Modeling. New York: John Wiley & Sons, 1987.
O’Conner, Kathleen. “The Use of a Computer Simulation Model to Plan an Obstetrical
Renovation Project.” The Fifth Annual PROMODEL Users Conference, Park City,
UT, 1994.
Sargent, Robert G. “Verifying and Validating Simulation Models.” In Proceedings of the
1998 Winter Simulation Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson,
and M. S. Manivannan, 1998, pp. 121–30.
8 SIMULATION OUTPUT
ANALYSIS
8.1 Introduction
In analyzing the output from a simulation model, there is room for both rough
analysis using judgmental procedures as well as statistically based procedures for
more detailed analysis. The appropriateness of using judgmental procedures or
statistically based procedures to analyze a simulation’s output depends largely on
the nature of the problem, the importance of the decision, and the validity of the
input data. If you are doing a go/no-go type of analysis in which you are trying to
find out whether a system is capable of meeting a minimum performance level,
then a simple judgmental approach may be adequate. Finding out whether a single
machine or a single service agent is adequate to handle a given workload may be
easily determined by a few runs unless it looks like a close call. Even if it is a
close call, if the decision is not that important (perhaps there is a backup worker
who can easily fill in during peak periods), then more detailed analysis may not
be needed. In cases where the model relies heavily on assumptions, it is of little
value to be extremely precise in estimating model performance. It does little good
to get six decimal places of precision for an output response if the input data war-
rant only precision to the nearest tens. Suppose, for example, that the arrival rate
of customers to a bank is roughly estimated to be 30 plus or minus 10 per hour. In
this situation, it is probably meaningless to try to obtain a precise estimate of teller
utilization in the facility. The precision of the input data simply doesn’t warrant
any more than a rough estimate for the output.
These examples of rough estimates are in no way intended to minimize the
importance of conducting statistically responsible experiments, but rather to em-
phasize the fact that the average analyst or manager can gainfully use simulation
211
.60
.25
.66
Point Estimates
A point estimate is a single value estimate of a parameter of interest. Point esti-
mates are calculated for the mean and standard deviation of the population. To
estimate the mean of the population (denoted as ), we simply calculate the aver-
age of the sample values (denoted as x̄):
i 1 xi
n
x̄ _ n
where n is the sample size (number of observations) and xi is the value of ith
observation. The sample mean x̄ estimates the population mean .
The standard deviation for the population (denoted as ), which is a measure
of the spread of data values in the population, is similarly estimated by calculating
a standard deviation of the sample of values (denoted as s):
___
i 1 [xi x̄]
n 2
s __
n1
The sample variance s , used to estimate the variance of the population 2, is ob-
2
1 21
2 16
3 8
4 11
5 17
6 16
7 6
8 14
9 15
10 16
11 14
12 10
Interval Estimates
A point estimate, by itself, gives little information about how accurately it esti-
mates the true value of the unknown parameter. Interval estimates constructed
using x̄ and s, on the other hand, provide information about how far off the point
estimate x̄ might be from the true mean . The method used to determine this is
referred to as confidence interval estimation.
A confidence interval is a range within which we can have a certain level of
confidence that the true mean falls. The interval is symmetric about x̄, and the
distance that each endpoint is from x̄ is called the half-width (hw). A confidence
interval, then, is expressed as the probability P that the unknown true mean lies
within the interval x̄ hw. The probability P is called the confidence level.
If the sample observations used to compute x̄ and s are independent and nor-
mally distributed, the following equation can be used to calculate the half-width
of a confidence interval for a given level of confidence:
(tn1, ␣Ⲑ2)s
hw __ _
n
where tn1,␣2 is a factor that can be obtained from the Student’s t table in Appen-
dix B. The values are identified in the Student’s t table according to the value of
␣2 and the degrees of freedom (n 1). The term ␣ is the complement of P.
That is, ␣ 1 P and is referred to as the significance level. The significance
level may be thought of as the “risk level” or probability that will fall out-
side the confidence interval. Therefore, the probability that will fall within
the confidence interval is 1 ␣. Thus confidence intervals are often stated as
P( x̄ hw x̄ hw) 1 ␣ and are read as the probability that the true
but unknown mean falls between the interval ( x̄ hw) to ( x̄ hw) is equal to
1 ␣. The confidence interval is traditionally referred to as a 100(1 ␣) percent
confidence interval.
Assuming the data from the barbershop example are independent and nor-
mally distributed (this assumption is discussed in section 8.3), a 95 percent confi-
dence interval is constructed as follows:
Given: P confidence level 0.95
␣ significance level 1 P 1 0.95 0.05
n sample size 12
x̄ 13.67 haircuts
s 4.21 haircuts
From the Student’s t table in Appendix B, we find tn1,␣2 t11,0.025 2.201. The
half-width is computed as follows:
(t11,0.025 )s _(2.201)4.21
hw _ _ _ 2.67 haircuts
n 12
The lower and upper limits of the 95 percent confidence interval are calculated
as follows:
Lower limit x̄ hw 13.67 2.67 11.00 haircuts
Upper limit x̄ hw 13.67 2.67 16.34 haircuts
It can now be asserted with 95 percent confidence that the true but unknown mean
falls between 11.00 haircuts and 16.34 haircuts (11.00 haircuts 16.34). A risk
level of 0.05(␣ 0.05) means that if we went through this process for estimating
the number of haircuts given on a Saturday morning 100 times and computed 100
confidence intervals, we would expect 5 of the confidence intervals (5 percent
of 100) to exclude the true but unknown mean number of haircuts given on a
Saturday morning.
The width of the interval indicates the accuracy of the point estimate. It is
desirable to have a small interval with high confidence (usually 90 percent or
greater). The width of the confidence interval is affected by the variability in the
output of the system and the number of observations collected (sample size). It
can be seen from the half-width equation that, for a given confidence level, the
half-width will shrink if (1) the sample size n is increased or (2) the variability
in the output of the system (standard deviation s) is reduced. Given that we have
little control over the variability of the system, we resign ourselves to increasing
the sample size (run more replications) to increase the accuracy of our estimates.
Actually, when dealing with the output from a simulation model, techniques
can sometimes reduce the variability of the output from the model without chang-
ing the expected value of the output. These are called variance reduction tech-
niques and are covered in Chapter 9.
n _ (
(tn1,␣2)s
e )
2
However, this cannot be completed because n appears on each side of the equa-
tion. So, to estimate the number of replications needed, we replace tn1,␣2 with
Z␣2, which depends only on ␣. The Z␣2 is from the standard normal distribution,
and its value can be found in the last row of the Student’s t table in Appendix B.
Note that Z␣2 t,␣2, where denotes infinity. The revised equation is
(
(Z␣2)s
n _ e ) 2
where n is a rough approximation for the number of replications that will provide
an adequate sample size for meeting the desired absolute error amount e and sig-
nificance level ␣.
Before this equation can be used, an initial sample of observations must be
collected to compute the sample standard deviation s of the output from the system.
Actually, when using the Z␣2 value, an assumption is made that the true standard
deviation for the complete population of observations is known. Of course, is
not known. However, it is reasonable to approximate with the sample standard
deviation s to get a rough approximation for the required number of replications.
n _
(Z0.025)s 2
e
(1.96)4.21 2
_
2.00
17.02 observations
1 21
2 16
3 8
4 11
5 17
6 16
7 6
8 14
9 15
10 16
11 14
12 10
13 7
14 9
15 18
16 13
17 16
18 8
2
(z␣2)s
n _ _____
re
( (1re) )x̄
where re denotes the relative error. The re(1 re) part of the denominator is an
adjustment needed to realize the desired re value because we use x̄ to estimate
(see Chapter 9 of Law 2007 for details). The appeal of this approach is that we
can select a desired percentage error without prior knowledge of the magnitude
of the value of .
As an example, say that after recording the number of haircuts given at the
barbershop on 12 Saturdays (n 12 replications of the experiment), we wish to
determine the approximate number of replications needed to estimate the mean
number of haircuts given per day with an error percentage of 17.14 percent and a
confidence level of 95 percent. We apply our equation using the sample mean and
sample standard deviation from Table 8.1.
Given: P confidence level 0.95
␣ significance level 1 P 1 0.95 0.05
Z␣2 Z0.025 1.96 from Appendix B
re 0.1714
x̄ 13.67
s 4.21
n _ re
_____ (
(z0.025)s 2
( (1re) )x̄
__
(1.96)4.21 2
(0.1714
)
_______ 13.67
(10.1714)
17.02 observations
Thus n 18 observations. This is the same result computed earlier on page 219
for an absolute error of e 2.00 haircuts. This occurred because we purposely
selected re 0.1714 to produce a value of 2.00 for the equation’s denominator in
order to demonstrate the equivalency of the different methods for approximating
the number of replications needed to achieve a desired level of precision in the
point estimate x̄. The SimRunner software uses the relative error methodology to
provide estimates for the number of replications needed to satisfy the specified
level of precision for a given significance level ␣.
In general, the accuracy of the estimates improves as the number of replica-
tions increases. However, after a point, only modest improvements in accuracy
(reductions in the half-width of the confidence interval) are made through con-
ducting additional replications of the experiment. Therefore, it is sometimes nec-
essary to compromise on a desired level of accuracy because of the time required
to run a large number of replications of the model.
The ProModel simulation software automatically computes confidence inter-
vals. Therefore, there is really no need to estimate the sample size required for a
desired half-width using the method given in this section. Instead, the experiment
could be replicated, say, 10 times, and the half-width of the resulting confidence
interval checked. If the desired half-width is not achieved, additional replications
of the experiment are made until it is. The only real advantage of estimating the
number of replications in advance is that it may save time over the trial-and-error
approach of repeatedly checking the half-width and running additional replica-
tions until the desired confidence interval is achieved.
Actually, the observations were generated from a simulation of the shop by mak-
ing independent runs (replications) of the model using the method described in
section 8.2.1. Note, however, that had the observations been collected from the
real barbershop, we would have processed them in the same manner. Experimen-
tal results are generally handled in the same manner, regardless of their origin, if
the observations are unbiased, independent, and normally distributed.
Note that very different results could be obtained from the real barbershop
if the simulation model does not accurately mimic the behavior of the real shop.
Statistical statements, no matter how precise, derived from the output of a simula-
tion model provide estimates for the true but unknown population parameters of
the model and not of the real system. Whether or not the model behavior actually
corresponds to real-world behavior is a matter of model validity, which was dis-
cussed in Chapter 7.
simulated to estimate the mean time that entities wait in queues in that system.
The experiment is replicated several times to collect n independent sample obser-
vations, as was done in the barbershop example. As an entity exits the system, the
time that the entity spent waiting in queues is recorded. The waiting time is de-
noted by yij in Table 8.3, where the subscript i denotes the replication from which
the observation came and the subscript j denotes the value of the counter used
to count entities as they exit the system. For example, y32 is the waiting time for
the second entity that was processed through the system in the third replication.
These values are recorded during a particular run (replication) of the model and
are listed under the column labeled “Within Run Observations” in Table 8.3.
Note that the within run observations for a particular replication, say the
ith replication, are not usually independent because of the correlation between
consecutive observations. For example, when the simulation starts and the first
entity begins processing, there is no waiting time in the queue. Obviously, the
more congested the system becomes at various times throughout the simulation,
the longer entities will wait in queues. If the waiting time observed for one entity
is long, it is highly likely that the waiting time for the next entity observed is
going to be long and vice versa. Observations exhibiting this correlation between
consecutive observations are said to be autocorrelated. Furthermore, the within
run observations for a particular replication are often nonstationary in that they
do not follow an identical distribution throughout the simulation run. Therefore,
they cannot be directly used as observations for statistical methods that require
independent and identically distributed observations such as those used in this
chapter.
At this point, it seems that we are a long way from getting a usable set of
observations. However, let’s focus our attention on the last column in Table 8.3,
labeled “Average,” which contains the x1 through xn values. xi denotes the average
waiting time of the entities processed during the ith simulation run (replication)
and is computed as follows:
j 1 yij
m
xi _ m
where m is the number of entities processed through the system and yij is the time
that the jth entity processed through the system waited in queues during the ith
replication. Although not as formally stated, you used this equation in the last
row of the ATM spreadsheet simulation of Chapter 3 to compute the average
waiting time of the m 25 customers (Table 3.2). An xi value for a particular
replication represents only one possible value for the mean time an entity waits
in queues, and it would be risky to make a statement about the true waiting time
from a single observation. However, Table 8.3 contains an xi value for each of
the n independent replications of the simulation. These xi values are statistically
independent if different seed values are used to initialize the random number
generator for each replication (as discussed in section 8.2.1). The xi values are
often identically distributed as well. Therefore, the sample of xi values can be
used for statistical methods requiring independent and identically distributed
observations. Thus we can use the xi values to estimate the true but unknown
average time entities wait in queues by computing the sample mean as follows:
i 1 xi
n
x̄ _ n
You used this equation in Table 3.3 to average the results from the two replica-
tions of the ATM spreadsheet simulation of Chapter 3.
The standard deviation of the average time entities wait in queues is esti-
mated by the sample standard deviation and is computed by
___
i 1 [xi x̄]
n 2
s __
n1
The third assumption for many standard statistical methods is that the sample
observations (x1 through xn) are normally distributed. For example, the normality
assumption is implied at the point for which a tn1, 2 value from the Student’s
t distribution is used in computing a confidence interval’s half-width. The cen-
tral limit theorem of statistics provides a basis for making this assumption. If a
variable is defined as the sum of several independent and identically distributed
random values, the central limit theorem states that the variable representing the
sum tends to be normally distributed. This is helpful because in computing xi for
a particular replication, the (yij) waiting times for the m entities processed in the
ith replication are summed together. However, the yij observations are autocorre-
lated and, therefore, not independent. But there are also central limit theorems for
certain types of correlated data that suggest that xi will be approximately normally
distributed if the sample size used to compute it (the number of entities processed
through the system, m from Table 8.3) is not too small (Law 2007). Therefore, we
can compute a confidence interval using
(tn1, 2)s
x̄ _ _
n
where tn1,␣2 is a value from the Student’s t table in Appendix B for an ␣ level of
significance.
ProModel automatically computes point estimates and confidence intervals
using this method. Figure 8.2 presents the output produced from running the
ProModel version of the ATM simulation of Lab Chapter 1 for five replications.
The column under the Locations section of the output report labeled “Average
Minutes per Entry” displays the average amount of time that customers waited in
the queue during each of the five replications. These values correspond to the xi
values in Table 8.3. Note that in addition to the sample mean and standard devia-
tion, ProModel also provides a 95 percent confidence interval.
Sometimes the output measure being evaluated is not based on the mean, or
sum, of a collection of random values. For example, the output measure may be
the maximum number of entities that simultaneously wait in a queue. (See the
“Maximum Contents” column in Figure 8.2.) In such cases, the output measure
may not be normally distributed, and because it is not a sum, the central limit
FIGURE 8.2
Replication technique used on ATM simulation of Lab Chapter 1.
-------------------------------------------------------------------
General Report
Output from C:\Bowden\3rd Edition\ATM System Ch8.MOD [ATM System]
Date: Nov/26/2010 Time: 04:24:27 PM
-------------------------------------------------------------------
Scenario : Normal Run
Replication : All
Period : Final Report (1000 hr to 1500 hr Elapsed: 500 hr)
Warmup Time : 1000
Simulation Time : 1500 hr
-------------------------------------------------------------------
LOCATIONS
Average
Location Scheduled Total Minutes Average Maximum Current
Name Hours Capacity Entries Per Entry Contents Contents Contents % Util
--------- ----- -------- ------- --------- -------- -------- -------- ------
ATM Queue 500 999999 9903 9.457 3.122 26 18 0.0 (Rep 1)
ATM Queue 500 999999 9866 8.912 2.930 24 0 0.0 (Rep 2)
ATM Queue 500 999999 9977 11.195 3.723 39 4 0.0 (Rep 3)
ATM Queue 500 999999 10006 8.697 2.900 26 3 0.0 (Rep 4)
ATM Queue 500 999999 10187 10.841 3.681 32 0 0.0 (Rep 5)
ATM Queue 500 999999 9987.8 9.820 3.271 29.4 5 0.0 (Average)
ATM Queue 0 0 124.654 1.134 0.402 6.148 7.483 0.0 (Std. Dev.)
ATM Queue 500 999999 9833.05 8.412 2.772 21.767 -4.290 0.0 (95% C.I. Low)
ATM Queue 500 999999 10142.6 11.229 3.771 37.032 14.290 0.0 (95% C.I. High)
theorem cannot be used to imply that it is normally distributed. Some refuge may
be taken in knowing that the method given in the chapter for constructing a confi-
dence interval does not completely break down when the normality assumption is
violated. So if the normality assumption is questionable, use the confidence inter-
val with the knowledge that it is only approximate. However, you must not violate
the independence assumption. This is not an obstacle because it is easy to get a set
of observations that are statistically independent by replicating the simulation.
the steady-state period will have approximately the same distribution. For such
systems, a suitable length of time to run the model in order to collect statistics on
the steady-state behavior of the system must be determined.
Nonterminating systems begin with a warm-up (or transient) state and gradu-
ally move to a steady state. Once the initial transient phase has diminished to the
point where the impact of the initial condition on the system’s response is neg-
ligible, we consider it to have reached steady state. Once in a steady state, if the
operating rules change or an input variable like the rate at which entities arrive
changes, the system reverts again to a transient state until the system has had time
to start reflecting the long-term behavior of the new operating circumstances.
An example of a nonterminating simulation is a model of a manufacturing
operation in which automotive oil filters are produced continually. The operation
runs two shifts with an hour break during each shift in which everything momen-
tarily stops. Break and third-shift times are excluded from the model because
work always continues exactly as it left off before the break or end of shift. The
length of the simulation is determined by how long it takes to get a representative
steady-state reading of the model behavior.
Nonterminating simulations can, and often do, change operating character-
istics after a period of time, but usually only after enough time has elapsed to es-
tablish a steady-state condition. Take, for example, a production system that runs
10,000 units per week for 5 weeks and then increases to 15,000 units per week
for the next 10 weeks. The system would have two different steady-state periods.
Thus, you would want to segment observations from the two different steady-state
periods and compute statistics separately for each of the two steady-state periods.
Oil and gas refineries and distribution centers are additional examples of nonter-
minating systems.
are needed to handle peak periods whereas only one waitress is necessary during
off-peak hours. Therefore, statistics are also often gathered on performance mea-
sures for successive intervals during the period.
For terminating simulations, there are three important questions to answer in
running the experiment:
1. What should be the initial state of the model?
2. What is the terminating event or time of the simulation (i.e., run length)?
3. How many replications should be made?
FIGURE 8.3
Behavior of model’s output response as it reaches steady state.
Warm-up ends
Transient state Steady state
Averaged
output
response
measure
(y )
1 2 3 4 5 6
Simulation time
warm-up ends would be biased to the low side. Therefore, we delete these ob-
servations from the beginning of the run and use the remaining observations to
estimate the true mean response of the model.
While several methods have been developed for estimating the warm-up
time, the easiest and most straightforward approach is to run a preliminary simu-
lation of the system, preferably with several (5 to 10) replications, average the
output values at each time step across replications, and observe at what time the
system reaches statistical stability. This usually occurs when the averaged output
response begins to flatten out or a repeating pattern emerges. Plotting each data
point (averaged output response) and connecting them with a line usually helps
to identify when the averaged output response begins to flatten out or begins a
repeating pattern. Sometimes, however, the variation of the output response is
so large that it makes the plot erratic, and it becomes difficult to visually identify
the end of the warm-up period. Such a case is illustrated in Figure 8.4. The raw
data plot in Figure 8.4 was produced by recording a model’s output response for
a queue’s average contents during 50-hour time periods (time slices) and averag-
ing the output values from each time period across five replications. In this case,
the model was initialized with several entities in the queue. Therefore, we need to
eliminate this apparent upward bias before recording observations of the queue’s
average contents. Table 8.4 shows this model’s output response for the 20 time
periods (50 hours each) for each of the five replications. The raw data plot in Fig-
ure 8.4 was constructed using the 20 values under the ȳ i column in Table 8.4.
When the model’s output response is erratic, as in Figure 8.4, it is use-
ful to “smooth” it with a moving average. A moving average is constructed by
FIGURE 8.4
SimRunner uses the Welch moving-average method to help identify the end of the warm-up period
that occurs around the third or fourth period (150 to 200 hours) for this model.
calculating the arithmetic average of the w most recent data points (averaged out-
put responses) in the data set. You have to select the value of w, which is called
the moving-average window. As you increase the value of w, you increase the
“smoothness” of the moving average plot. An indicator for the end of the warm-
up time is when the moving average plot appears to flatten out. Thus the routine is
to begin with a small value of w and increase it until the resulting moving average
plot begins to flatten out.
The moving-average plot in Figure 8.4 with a window of six (w 6) helps to
identify the end of the warm-up period—when the moving average plot appears
to flatten out at around the third or fourth period (150 to 200 hours). Therefore,
we ignore the observations up to the 200th hour and record only those after the
200th hour when we run the simulation. The moving-average plot in Figure 8.4
was constructed using the 14 values under the yi (6) column in Table 8.4 that were
computed using
sw ȳ is
w
_ if i w 1, . . . , m w
2w 1
ȳ i (w)
s(i1) ȳis
i1
__ if i 1, . . . , w
2i 1
where m denotes the total number of periods and w denotes the window of the
moving average (m 20 and w 6 in this example).
TABLE 8.4 Welch Moving Average Based on Five Replications and 20 Periods
Average
Total Contents Welch
Observed Mean Queue Contents (Replications) Contents for per Period, Moving
Period, Average,
yi_Totali
Period (i) Time 1 2 3 4 5 Totali yi(6)
5
1 50 4.41 4.06 6.37 11.72 1.71 28.27 5.65 5.65
2 100 3.15 2.95 2.94 3.52 2.86 15.42 3.08 3.95
3 150 2.58 2.50 3.07 3.14 4.32 15.61 3.12 3.73
4 200 2.92 3.07 4.48 4.79 3.47 18.73 3.75 3.84
5 250 3.13 3.28 2.34 3.32 3.19 15.26 3.05 3.94
6 300 2.51 3.07 5.45 5.15 5.34 21.52 4.30 3.82
7 350 5.09 3.77 4.44 3.58 2.63 19.51 3.90 3.86
8 400 3.15 2.89 3.63 4.43 4.15 18.25 3.65 3.83
9 450 2.79 3.40 9.78 4.13 4.48 24.58 4.92 3.84
10 500 4.07 3.62 4.50 2.38 3.42 17.99 3.60 3.93
11 550 3.42 3.74 2.46 3.08 2.49 15.19 3.04 3.89
12 600 3.90 1.47 5.75 5.34 4.19 20.65 4.13 3.99
13 650 3.63 3.77 2.14 4.24 6.36 20.14 4.03 3.99
14 700 9.12 4.25 3.83 3.19 5.91 26.30 5.26 3.96
15 750 3.88 3.54 3.08 2.94 2.51 15.95 3.19
16 800 3.16 6.91 2.70 5.64 2.57 20.98 4.20
17 850 5.34 3.17 2.47 2.73 2.68 16.39 3.28
18 900 2.84 3.54 2.33 10.14 3.20 22.05 4.41
19 950 2.65 4.64 5.18 4.97 3.93 21.37 4.27
20 1000 3.27 4.68 3.39 2.95 3.46 17.75 3.55
ȳ 1 ȳ 2 ȳ 3 ȳ 4 ȳ 5 ȳ 6 ȳ 7 ȳ 8 ȳ 9 ȳ 10 ȳ 11
ȳ 6(6) _____ 3.82
11
Notice the pattern that as i increases, we average more data points together,
with the ith data point appearing in the middle of the sum in the numerator (an
equal number of data points are on each side of the center data point). This con-
tinues until we reach the (w 1)th moving average, when we switch to the top
part of the ȳ i(w) equation. For our example, the switch occurs at the 7th moving
average because w 6. From this point forward, we average the 2w 1 closest
data points. For our example, we average the 2(6) 1 13 closest data points
(the ith data point plus the w 6 closest data points above it and the w 6 closest
data point below it in Table 8.4 as follows:
y1 y2 y3 y4 y5 y6 y7 y8 y9 y10 y11 y12 y13
y7(6) ______
13
y7(6) 3.86
y8 y9 y10 y11 y12 y13 y14 y15 y16 y17 y18 y19 y20
y14(6) ______
13
y14(6) 3.96
Eventually we run out of data and have to stop. The stopping point occurs when
i m w. In our case with m 20 periods and w 6, we stopped when i
20 6 14.
The development of this graphical method for estimating the end of the warm-
up time is attributed to Welch (Law 2007). This method is sometimes referred to
as the Welch moving-average method and is implemented in SimRunner. Note that
when applying the method that the length of each replication should be relatively
long and the replications should allow even rarely occurring events such as infre-
quent downtimes to occur many times. Law (2007) recommend that w not exceed
a value greater than about m4. To determine a satisfactory warm-up time using
Welch’s method, one or more key output response variables, such as the average
number of entities in a queue or the average utilization of a resource, should be
monitored for successive periods. Once these variables begin to exhibit steady
state, a good practice to follow would be to extend the warm-up period by 20 to
30 percent. This approach is simple, conservative, and usually satisfactory. The
danger is in underestimating the warm-up period, not overestimating it.
should be based on time. If the output measure is based on observations (like the
waiting time of entities in a queue), then the batch interval is typically based on
the number of observations.
Table 8.5 details how a single, long simulation run (one replication), like
the one shown in Figure 8.5, is partitioned into batch intervals for the purpose of
obtaining (approximately) independent and identically distributed observations
of a simulation model’s output response. Note the similarity between Table 8.3
of section 8.3 and Table 8.5. As in Table 8.3, the observations represent the time
an entity waited in queues during the simulation. The waiting time for an entity is
denoted by yij, where the subscript i denotes the interval of time (batch interval)
from which the observation came and the subscript j denotes the value of the
counter used to count entities as they exit the system during a particular batch
interval. For example, y23 is the waiting time for the third entity that was processed
through the system during the second batch interval of time.
Because these observations are all from a single run (replication), they are
not statistically independent. For example, the waiting time of the mth entity exit-
ing the system during the first batch interval, denoted y1m, is correlated with the
waiting time of the first entity to exit the system during the second batch interval,
denoted y21. This is because if the waiting time observed for one entity is long, it
is likely that the waiting time for the next entity observed is going to be long, and
vice versa. Therefore, adjacent observations in Table 8.5 will usually be autocor-
related. However, the value of y14 can be somewhat uncorrelated with the value
of y24 if they are spaced far enough apart such that the conditions that resulted
in the waiting time value of y14 occurred so long ago that they have little or no
influence on the waiting time value of y24. Therefore, most of the observations
within the interior of one batch interval can become relatively uncorrelated with
most of the observations in the interior of other batch intervals, provided they are
spaced sufficiently far apart. Thus the goal is to extend the batch interval length
until there is very little correlation (you cannot totally eliminate it) between the
observations appearing in different batch intervals. When this occurs, it is reason-
able to assume that observations within one batch interval are independent of the
observations within other batch intervals.
With the independence assumption in hand, the observations within a batch
interval can be treated in the same manner as we treated observations within a
replication in Table 8.3. Therefore, the values in the Average column in Table 8.5,
which represent the average amount of time the entities processed during the ith
batch interval waited in queues, are computed as follows:
mj1 yij
xi _ m
where m is the number of entities processed through the system during the batch
interval of time and yij is the time that the jth entity processed through the system
waited in queues during the ith batch interval. The xi values in the Average column
are approximately independent and identically distributed and can be used to com-
pute a sample mean for estimating the true average time an entity waits in queues:
ni1 xi
x̄ _ n
where tn1,␣
2 is a value from the Student’s t table in Appendix B for an ␣ level of
significance.
ProModel automatically computes point estimates and confidence intervals
using the above method. Figure 8.6 is a ProModel output report from a single,
FIGURE 8.6
Batch means technique used on ATM simulation in Lab Chapter 1. Warm-up period is from 0 to 1,000 hours. Each
batch interval is 500 hours in length.
-----------------------------------------------------------------
General Report
Output from C:\Bowden\3rd Edition\ATM System Ch8.MOD [ATM System]
Date: Nov/26/2010 Time: 04:44:24 PM
-----------------------------------------------------------------
Scenario : Normal Run
Replication : 1 of 1
Period : All
Warmup Time : 1000 hr
Simulation Time : 3500 hr
-----------------------------------------------------------------
LOCATIONS
Average
Location Scheduled Total Minutes Average Maximum Current
Name Hours Capacity Entries Per Entry Contents Contents Contents % Util
--------- --------- -------- ------- --------- -------- -------- -------- ------
ATM Queue 500 999999 9903 9.457 3.122 26 18 0.0 (Batch 1)
ATM Queue 500 999999 10065 9.789 3.284 24 0 0.0 (Batch 2)
ATM Queue 500 999999 9815 8.630 2.823 23 16 0.0 (Batch 3)
ATM Queue 500 999999 9868 8.894 2.925 24 1 0.0 (Batch 4)
ATM Queue 500 999999 10090 12.615 4.242 34 0 0.0 (Batch 5)
ATM Queue 500 999999 9948.2 9.877 3.279 26.2 7 0.0 (Average)
ATM Queue 0 0 122.441 1.596 0.567 4.494 9.165 0.0 (Std. Dev.)
ATM Queue 500 999999 9796.19 7.895 2.575 20.620 -4.378 0.0 (95% C.I. Low)
ATM Queue 500 999999 10100.2 11.860 3.983 31.779 18.378 0.0 (95% C.I. High)
long run of the ATM simulation in Lab Chapter 1 with the output divided into
five batch intervals of 500 hours each after a warm-up time of 1,000 hours. The
column under the Locations section of the output report labeled “Average Minutes
Per Entry” displays the average amount of time that customer entities waited in
the queue during each of the five batch intervals. These values correspond to the
xi values of Table 8.5. Note that the 95 percent confidence interval automatically
computed by ProModel in Figure 8.6 is comparable, though not identical, to the
95 percent confidence interval in Figure 8.2 for the same output statistic.
Establishing the batch interval length such that the observations x1, x2, . . . , xn
of Table 8.5 (assembled after the simulation reaches steady state) are approxi-
mately independent is difficult and time-consuming. There is no foolproof method
for doing this. However, if you can generate a large number of observations, say
n 100, you can gain some insight about the independence of the observations
by estimating the autocorrelation between adjacent observations (lag-1 autocorre-
lation). See Chapter 5 for an introduction to tests for independence and autocor-
relation plots. The observations are treated as being independent if their lag-1
autocorrelation is zero. Unfortunately, current methods available for estimating the
lag-1 autocorrelation are not very accurate. Thus we may be persuaded that our ob-
servations are almost independent if the estimated lag-1 autocorrelation computed
from a large number of observations falls between −0.20 to 0.20. The word
almost is emphasized because there is really no such thing as almost independent
(the observations are independent or they are not). What we are indicating here is
that we are leaning toward calling the observations independent when the estimate
of the lag-1 autocorrelation is between −0.20 and 0.20. Recall that autocorrela-
tion values fall between 1. Before we elaborate on this idea for determining if an
acceptable batch interval length has been used to derive the observations, let’s talk
about positive autocorrelation versus negative autocorrelation.
Positive autocorrelation is a bigger enemy to us than negative autocorrela-
tion because our sample standard deviation s will be biased low if the observa-
tions from which it is computed are positively correlated. This would result in a
falsely narrow confidence interval (smaller half-width), leading us to believe that
we have a better estimate of the mean than we actually have. Negatively cor-
related observations have the opposite effect, producing a falsely wide confidence
interval (larger half-width), leading us to believe that we have a worse estimate
of the mean than we actually have. A negative autocorrelation may lead us
to waste time collecting additional observations to get a more precise (narrow)
confidence interval but will not result in a hasty decision. Therefore, an emphasis
is placed on guarding against positive autocorrelation. We present the following
procedure adapted from Banks et al. (2010) for estimating an acceptable batch
interval length.
For the observations x1, x2, . . . , xn derived from n batches of data assembled
after the simulation has researched steady state as outlined in Table 8.5, compute
an estimate of the lag-1 autocorrelation ^1 using
i1 (xi − x̄)(xi1 − x̄)
n−1
^1 __
s2(n − 1)
where s2 is the sample variance (sample standard deviation squared) and x̄ is the
sample mean of the n observations. Recall the recommendation that n should be
at least 100 observations. If the estimated lag-1 autocorrelation is not between
0.20 and 0.20, then extend the original batch interval length by 50 to 100
percent, rerun the simulation to collect a new set of n observations, and check
the lag-1 autocorrelation between the new x1 to xn observations. This would be
repeated until the estimated lag-1 autocorrelation falls between 0.20 and 0.20
(or you give up trying to get within the range). Note that falling below 0.20 is
less worrisome than exceeding 0.20.
Achieving ⴚ0.20 ^1 0.20: Upon achieving an estimated lag-1
autocorrelation within the desired range, “rebatch” the data by combining
adjacent batch intervals of data into a larger batch. This produces a
smaller number of observations that are based on a larger batch interval
length. The lag-1 autocorrelation for this new set of observations will
likely be closer to zero than the lag-1 autocorrelation of the previous set
of observations because the new set of observations is based on a larger
batch interval length. Note that at this point, you are not rerunning the
simulation with the new, longer batch interval but are “rebatching” the
output data from the last run. For example, if a batch interval length of
125 hours produced 100 observations (x1 to x100) with an estimated lag-1
Replication 1
Batch
Simulation time
8.7 Summary
Simulation experiments can range from a few replications (runs) to a large num-
ber of replications. While “ballpark” decisions require little analysis, more precise
decision making requires more careful analysis and extensive experimentation.
15. Given the five batch means for the Average Minutes Per Entry
of customer entities at the ATM queue location in Figure 8.6,
estimate the lag-1 autocorrelation ^1. Note that five observations are
woefully inadequate for obtaining an accurate estimate of the lag-1
autocorrelation. Normally you will want to base the estimate on at
least 100 observations. The question is designed to give you some
experience using the ^1 equation so that you will understand what the
Stat::Fit software is doing when you use it in Lab Chapter 8 to crunch
through an example with 100 observations.
16. Construct a Welch moving average with a window of 2 (w 2) using
the data in Table 8.4 and compare it to the Welch moving average with
a window of 6 (w 6) presented in Table 8.4.
References
Banks, Jerry; John S. Carson II; Barry L. Nelson; and David M. Nicol. Discrete-Event
System Simulation. 5th ed. Englewood Cliffs, NJ: Prentice Hall, 2010.
Bateman, Robert E.; Royce O. Bowden; Thomas J. Gogg; Charles R. Harrell; and Jack
R. A. Mott. System Improvement Using Simulation. Orem, UT: PROMODEL Corp.,
1997.
Hines, William W.; Douglas C. Montgomery; David M. Goldsman; and Connie M. Borror.
Probability and Statistics in Engineering. 4th ed. New York: John Wiley and Sons,
2003.
Law, Averill M. Simulation Modeling and Analysis. New York: McGraw-Hill, 2007.
Montgomery, Douglas C. Design and Analysis of Experiments. New York: John Wiley &
Sons, 1991.
Petersen, Roger G. Design and Analysis of Experiments. New York: Marcel Dekker, 1985.
9 COMPARING SYSTEMS
“The method that proceeds without analysis is like the groping of a blind man.”
—Socrates
9.1 Introduction
In many cases, simulations are conducted to compare two or more alternative de-
signs of a system with the goal of identifying the superior system relative to some
performance measure. Comparing alternative system designs requires careful
analysis to ensure that differences being observed are attributable to actual differ-
ences in performance and not to statistical variation. This is where running either
multiple replications or batches is required. Suppose, for example, that method A
for deploying resources yields a throughput of 100 entities for a given time period
while method B results in 110 entities for the same period. Is it valid to conclude
that method B is better than method A, or might additional replications actually
lead to the opposite conclusion?
You can evaluate alternative configurations or operating policies by perform-
ing several replications of each alternative and comparing the average results
from the replications. Statistical methods for making these types of comparisons
are called hypotheses tests. For these tests, a hypothesis is first formulated (for ex-
ample, that methods A and B both result in the same throughput) and then a test is
made to see whether the results of the simulation lead us to reject the hypothesis.
The outcome of the simulation runs may cause us to reject the hypothesis that
methods A and B both result in equal throughput capabilities and conclude that
the throughput does indeed depend on which method is used.
This chapter extends the material presented in Chapter 8 by providing statisti-
cal methods that can be used to compare the output of different simulation models
that represent competing designs of a system. The concepts behind hypothesis
testing are introduced in section 9.2. Section 9.3 addresses the case when two
243
alternative system designs are to be compared, and section 9.4 considers the case
when more than two alternative system designs are to be compared. Additionally,
a technique called common random numbers is described in section 9.5 that can
sometimes improve the accuracy of the comparisons.
FIGURE 9.1
Production system with
four workstations and
three buffer storage
areas.
.72 4.56
Suppose that Strategy 1 and Strategy 2 are the two buffer allocation strate-
gies proposed by the production control staff. We wish to identify the strategy that
maximizes the throughput of the production system (number of parts completed
per hour). Of course, the possibility exists that there is no significant difference in
the performance of the two candidate strategies. That is to say, the mean through-
put of the two proposed strategies is equal. A starting point for our problem is
to formulate our hypotheses concerning the mean throughput for the production
system under the two buffer allocation strategies. Next we work out the details
of setting up our experiments with the simulation models built to evaluate each
strategy. For example, we may decide to estimate the true mean performance of
each strategy (1 and 2) by simulating each strategy for 16 days (24 hours per
day) past the warm-up period and replicating the simulation 10 times. After we
run experiments, we would use the simulation output to evaluate the hypotheses
concerning the mean throughput for the production system under the two buffer
allocation strategies.
In general, a null hypothesis, denoted H0, is drafted to state that the value of
1 is not significantly different than the value of 2 at the level of significance.
An alternate hypothesis, denoted H1, is drafted to oppose the null hypothesis H0.
For example, H1 could state that 1 and 2 are different at the level of signifi-
cance. Stated more formally:
H0: 1 2 or equivalently H0: 1 2 0
H1: 1 2 or equivalently H1: 1 2 0
In the context of the example problem, the null hypothesis H0 states that the
mean throughputs of the system due to Strategy 1 and Strategy 2 do not differ.
The alternate hypothesis H1 states that the mean throughputs of the system due to
Strategy 1 and Strategy 2 do differ. Hypothesis testing methods are designed such
that the burden of proof is on us to demonstrate that H0 is not true. Therefore, if our
analysis of the data from our experiments leads us to reject H0, we can be confident
that there is a significant difference between the two population means. In our
example problem, the output from the simulation model for Strategy 1 represents
possible throughput observations from one population, and the output from the
simulation model for Strategy 2 represents possible throughput observations from
another population.
The level of significance in these hypotheses refers to the probability of
making a Type I error. A Type I error occurs when we reject H0 in favor of H1
when in fact H0 is true. Typically is set at a value of 0.05 or 0.01. However, the
choice is yours, and it depends on how small you want the probability of making
a Type I error to be. A Type II error occurs when we fail to reject H0 in favor of
H1 when in fact H1 is true. The probability of making a Type II error is denoted as
. Hypothesis testing methods are designed such that the probability of making
a Type II error, , is as small as possible for a given value of . The relationship
between and is that increases as decreases. Therefore, we should be care-
ful not to make too small.
We will test these hypotheses using a confidence interval approach to
determine if we should reject or fail to reject the null hypothesis in favor of the
alternative hypothesis. The reason for using the confidence interval method is
that it is equivalent to conducting a two-tailed test of hypothesis with the added
benefit of indicating the magnitude of the difference between 1 and 2 if they
are in fact significantly different. The first step of this procedure is to construct a
confidence interval to estimate the difference between the two means (1 2).
This can be done in different ways depending on how the simulation experiments
are conducted (we will discuss this later). For now, let’s express the confidence
interval on the difference between the two means as
P[(x̄ 1 x̄ 2) hw 1 2 (x̄ 1 x̄ 2) hw] 1
where hw denotes the half-width of the confidence interval. Notice the similari-
ties between this confidence interval expression and the one given on page 217 in
Chapter 8. Here we have replaced x̄ with x̄ 1 x̄ 2 and with 1 2.
If the two population means are the same, then 1 2 0, which is our
null hypothesis H0. If H0 is true, our confidence interval should include zero with
a probability of 1 . This leads to the following rule for deciding whether to
reject or fail to reject H0. If the confidence interval includes zero, we fail to reject
H0 and conclude that the value of 1 is not significantly different than the value
of 2 at the level of significance (the mean throughput of Strategy 1 is not sig-
nificantly different than the mean throughput of Strategy 2). However, if the con-
fidence interval does not include zero, we reject H0 and conclude that the value
of 1 is significantly different than the value of 2 at the level of significance
(throughput values for Strategy 1 and Strategy 2 are significantly different).
Figure 9.2(a) illustrates the case when the confidence interval contains zero,
leading us to fail to reject the null hypothesis H0 and conclude that there is no
significant difference between 1 and 2. The failure to obtain sufficient evidence
to pick one alternative over another may be due to the fact that there really is no
difference, or it may be a result of the variance in the observed outcomes being too
high to be conclusive. At this point, either additional replications may be run or
one of several variance reduction techniques might be employed (see section 9.5).
Figure 9.2(b) illustrates the case when the confidence interval is completely to the
FIGURE 9.2
Three possible
(a) [------|------] Fail to
reject H0
positions of a
confidence interval
relative to zero.
(b) [------|------] Reject H0
1 ⫺ 2 ⫽ 0
left of zero, leading us to reject H0. This case suggests that 1 2 0 or, equiva-
lently, 1 2. Figure 9.2(c) illustrates the case when the confidence interval is
completely to the right of zero, leading us to also reject H0. This case suggests that
1 2 0 or, equivalently, 1 2. These rules are commonly used in practice
to make statements about how the population means differ (1 2 or 1 2)
when the confidence interval does not include zero (Banks et al. 2010; Hoover
and Perry 1989).
1 54.48 56.01
2 57.36 54.08
3 54.81 52.14
4 56.20 53.49
5 54.83 55.49
6 57.69 55.00
7 58.33 54.88
8 57.19 54.47
9 56.84 54.93
10 55.29 55.84
because a unique segment (stream) of random numbers from the random number
generator was used for each replication. The same is true for the 10 observations
in column C (Strategy 2 Throughput). The use of random number streams is dis-
cussed in Chapters 3 and 8 and later in this chapter. At this point we are assuming
that the observations are also normally distributed. The reasonableness of assum-
ing that the output produced by our simulation models is normally distributed is
discussed at length in Chapter 8. For this data set, we should also point out that
two different sets of random numbers were used to simulate the 10 replications
of each strategy. Therefore, the observations in column B are independent of the
observations in column C. Stated another way, the two columns of observations
are not correlated. Therefore, the observations are independent within a popula-
tion (strategy) and between populations (strategies). This is an important distinc-
tion and will be employed later to help us choose between different methods for
computing the confidence intervals used to compare the two strategies.
From the observations in Table 9.1 of the throughput produced by each strat-
egy, it is not obvious which strategy yields the higher throughput. Inspection of
the summary statistics indicates that Strategy 1 produced a higher mean through-
put for the system; however, the sample variance for Strategy 1 was higher than
for Strategy 2. Recall that the variance provides a measure of the variability of the
data and is obtained by squaring the standard deviation. Equations for computing
the sample mean x̄, sample variance s2, and sample standard deviation s are given
in Chapter 8. Because of this variation, we should be careful when making con-
clusions about the population of throughput values (1 and 2) by only inspecting
the point estimates (x̄ 1 and x̄ 2). We will avoid the temptation and use the output
from the 10 replications of each simulation model along with a confidence inter-
val to make a more informed decision.
We will use an 0.05 level of significance to compare the two candidate
strategies using the following hypotheses:
H0: 1 2 0
H1: 1 2 0
where the subscripts 1 and 2 denote Strategy 1 and Strategy 2, respectively. As
stated earlier, there are two common methods for constructing a confidence inter-
val for evaluating hypotheses. The first method is referred to as the Welch confi-
dence interval (Law 2007; Miller 1986) and is a modified two-sample-t confidence
interval. The second method is the paired-t confidence interval (Miller et al.
1990). We’ve chosen to present these two methods because their statistical as-
sumptions are more easily satisfied than are the assumptions for other confidence
interval methods.
s21 __
s22
n1 n2
hw tdf,2 __
and tdf,2 is a factor obtained from the Student’s t table in Appendix B based on
the value of 2 and the estimated degrees of freedom. Note that the degrees of
freedom term in the Student’s t table is an integer value. Given that the estimated
degrees of freedom will seldom be an integer value, you will have to use interpo-
lation to compute the tdf,2 value.
For the example buffer allocation problem with an 0.05 level of signifi-
cance, we use these equations and data from Table 9.1 to compute
[1.8910 1.3610]2
df ____________________________________ 17.5
[1.8910] (10 1) [1.3610]2(10 1)
2
and
___________
_____
____
hw t17.5,0.025 1.89 1.36
____ 2.106 0.325 1.20 parts per hour
10 10
where tdf,2 t17.5,0.025 2.106 is determined from Student’s t table in Appendix B
by interpolation. Now the 95 percent confidence interval is
(x̄ 1 x̄ 2) hw 1 2 (x̄ 1 x̄ 2) hw
(56.30 54.63) 1.20 1 2 (56.30 54.63) 1.20
0.47 1 2 2.87
j1 x(12) j
n
j1 [x(12) j x̄ (12)]
n 2
Sample standard deviation s(12) _________________
n1
where tn1,2 is a factor that can be obtained from the Student’s t table in Appendix B
based on the value of 2 and the degrees of freedom (n 1). Thus the paired-t
confidence interval for an level of significance is
P(x̄ (12) hw (12) x̄ (12) hw) 1
Notice that this is basically the same confidence interval expression presented in
Chapter 8 with x̄ (12) replacing x̄ and (12) replacing .
Let’s create Table 9.2 by restructuring Table 9.1 to conform to our new
“paired” notation and paired-t method before computing the confidence interval
necessary for testing the hypotheses
H0: 1 2 0 or using the new “paired” notation (12) 0
H1: 1 2 0 or using the new “paired” notation (12) 0
where the subscripts 1 and 2 denote Strategy 1 and Strategy 2, respectively.
The observations in Table 9.2 are identical to the observations in Table 9.1.
However, we added a fourth column. The values in the fourth column (col-
umn D) are computed by subtracting column C from column B. This fourth
column represents the 10 independent observations (n 10) of our new random
variable x(12) j.
j1 x(12) j
10
j1 [x(12) j 1.67]
10 2
s(12) _________________ 1.85 parts per hour
10 1
)1.85 __________
(t9,0.025___ (2.262)1.85
hw __________ ___ 1.32 parts per hour
10 10
where tn1,2 t9,0.025 2.262 is determined from the Student’s t table in Appen-
dix B. The 95 percent confidence interval is
x̄ (12) hw (12) x̄ (12) hw
1.67 1.32 (12) 1.67 1.32
0.32 (12) 2.99
With approximately 95 percent confidence, we conclude that there is a signifi-
cant difference between the mean throughputs of the two strategies given that
the interval excludes zero. The confidence interval further suggests that the
mean throughput 1 of Strategy 1 is higher than the mean throughput 2 of
Strategy 2 (an estimated 0.35 to 2.99 parts per hour higher). This is basically the
same conclusion reached using the Welch confidence interval method presented
in section 9.3.1.
Now let’s walk back through the assumptions made when we used the paired-t
method. The main requirement is that the observations in the Throughput Dif-
ference column be independent and normally distributed. Pairing the throughput
observations for Strategy 1 with the throughput observations for Strategy 2 and
subtracting the two values formed the Throughput Difference column of Table 9.2.
The observations for Strategy 1 are independent because nonoverlapping streams
of random numbers were used to drive each replication. The observations for Strat-
egy 2 are independent for the same reason. The use of random number streams is
discussed in Chapters 3 and 8 and later in this chapter. Therefore, there is no doubt
that these observations meet the independence requirement. It then follows that the
observations under the Throughput Difference column are also statistically inde-
pendent. The assumption that has been made, without really knowing if it’s true,
is that the observations in the Throughput Difference column are normally distrib-
uted. The reasonableness of assuming that the output produced by our simulation
models is normally distributed is discussed at length in Chapter 8.
K(K1)
where i1 i and is the overall level of significance and m _____
m
2
and is
the number of confidence interval statements.
If, in this example for comparing four candidate designs, we set 1 2
3 4 5 6 0.05, then the overall probability that all our conclusions
are correct is as low as (1 0.30), or 0.70. Being as low as 70 percent confident
in our conclusions leaves much to be desired. To combat this, we simply lower
the values of the individual significance levels (1 2 3 . . . m) so
their sum is not so large. However, this does not come without a price, as we
shall see later in our example.
One way to assign values to the individual significance levels is to first estab-
lish an overall level of significance and then divide it by the number of pairwise
comparisons. That is,
i ___________ for i 1, 2, 3, . . ., K(K 1)2
K(K 1 )2
Note, however, that it is not required that the individual significance levels be as-
signed the same value. This is useful in cases where the decision maker wants to
place different levels of significance on certain comparisons.
Practically speaking, the Bonferroni inequality limits the number of system
designs that can be reasonably compared to about five designs or less. This is
because controlling the overall significance level for the test requires the assign-
ment of small values to the individual significance levels (1 2 3 . . .
m) if more than five designs are compared. This presents a problem because the
width of a confidence interval quickly increases as the level of significance is
reduced. Recall that the width of a confidence interval provides a measure of the
accuracy of the estimate. Therefore, we pay for gains in the overall confidence of
our test by reducing the accuracy of our individual estimates (wide confidence
intervals). When accurate estimates (tight confidence intervals) are desired,
we recommend not using the Bonferroni approach when comparing more than five
system designs. For comparing more than five system designs, we recommend that
the analysis of variance technique be used in conjunction with perhaps the Fisher’s
least significant difference test. These methods are presented in section 9.4.2.
Let’s return to the buffer allocation example from the previous section and
apply the Bonferroni approach using paired-t confidence intervals. In this case,
the production control staff has devised three buffer allocation strategies to com-
pare. And, as before, we wish to determine if there are significant differences
between the throughput levels (number of parts completed per hour) achieved by
the strategies. Although we will be working with individual confidence intervals,
the hypotheses for the overall level of significance are
H0: 1 2 3
H1: 1 2 or 1 3 or 2 3
where the subscripts 1, 2, and 3 denote Strategy 1, Strategy 2, and Strategy 3,
respectively.
To evaluate these hypotheses, we estimated the performance of the three
strategies by simulating the use of each strategy for 16 days (24 hours per day)
past the warm-up period. And, as before, the simulation was replicated 10 times
for each strategy. The average hourly throughput achieved by each strategy is
shown in Table 9.3.
The evaluation of the three buffer allocation strategies (K 3) requires that
three [3(3 1)2] pairwise comparisons be made. The three pairwise comparisons
TABLE 9.3 Comparison of Three Buffer Allocation Strategies (K ⴝ 3) Based on Paired Differences
x̄(ii ), for all i and i between 1 and 3, with i < i 1.67 1.09 2.76
s(ii ), for all i and i between 1 and 3, with i < i 1.85 1.58 1.37
are shown in columns E, F, and G of Table 9.3. Also shown in Table 9.3 are the
sample means x̄(ii ) and sample standard deviations s(ii ) for each pairwise comparison.
Let’s say that we wish to use an overall significance level of 0.06 to
evaluate our hypotheses. For the individual levels of significance, let’s set 1
2 3 0.02 by using the equation
____
i __ 0.06 0.02 for i 1, 2, 3
3 3
The computation of the three paired-t confidence intervals using the method out-
lined in section 9.3.2 and data from Table 9.3 follows:
Comparing (12): 1 0.02
tr1,12 t9,0.01 2.821 from Appendix B
(t9,0.01__)s(12) __________
(2.821)1.85
hw _________
n
___
10
hw 1.65 parts per hour
The approximate 98 percent confidence interval is
x̄ (12) hw (12) x̄ (12) hw
1.67 1.65 (12) 1.67 1.65
0.02 (12) 3.32
Comparing (13): 2 0.02
tn1,22 t9,0.01 2.821 from Appendix B
(t9,0.01__)s(13) __________
(2.821)1.58
hw _________
n
___
10
hw 1.41 parts per hour
Given that the confidence interval about (12) excludes zero, we conclude
that there is a significant difference in the mean throughput produced by Strate-
gies 1 (1) and 2 (2). The confidence interval further suggests that the mean
throughput 1 of Strategy 1 is higher than the mean throughput 2 of Strategy 2
(an estimated 0.02 parts per hour to 3.32 parts per hour higher). This conclu-
sion should not be surprising because we concluded that Strategy 1 resulted in a
higher throughput than Strategy 2 earlier in sections 9.3.1 and 9.3.2. However,
notice that this confidence interval is wider than the one computed in section
9.3.2 for comparing Strategy 1 to Strategy 2 using the same data. This is because
the earlier confidence interval was based on a significance level of 0.05 and this
one is based on a significance level of 0.02. Notice that we went from using
t9,0.025 2.262 for the paired-t confidence interval in section 9.3.2 to t9,0.01
2.821 for this confidence interval, which increased the width of the interval to
the point that it is very close to including zero. This is the price that you pay,
mentioned earlier, for reducing the level of significance.
Given that the confidence interval about (13) includes zero, we conclude
that there is no significant difference in the mean throughput produced by Strate-
gies 1 (1) and 3 (3). And from the final confidence interval about (23), we
conclude that there is a significant difference in the mean throughput produced by
Strategies 2 (2) and 3 (3). This confidence interval suggests that the throughput
of Strategy 3 is higher than the throughput of Strategy 2 (an estimated 1.54 parts
per hour to 3.98 parts per hour higher).
Recall that our overall confidence for these conclusions is approximately
94 percent. Based on these results, we may be inclined to believe that Strategy 2
is the least favorable with respect to mean throughput while Strategies 1 and 3 are
the most favorable with respect to mean throughput. Additionally, the difference
in the mean throughput of Strategy 1 and Strategy 3 is not significant. Therefore,
we recommend that you implement Strategy 3 in place of your own Strategy 1
because Strategy 3 was the boss’s idea.
In this case, the statistical assumptions for using the Bonferroni approach are
the same as for the paired-t confidence interval. Because we used the Student’s t
distribution to build the confidence intervals, the observations in the Throughput
Difference columns of Table 9.3 must be independent and normally distributed.
It is reasonable to assume that these two assumptions are satisfied here for the
Bonferroni test using the same logic presented at the conclusion of section 9.3.2
for the paired-t confidence interval.
of throughput for each strategy. Table 9.4 presents the experimental results and
summary statistics for this problem. The response variable x̄i j is the observed
throughput for the treatment (strategy). The subscript i refers to the factor level
(Strategy 1, 2, or 3) and j refers to an observation (output from replication j) for
that factor level. For example, the mean throughput response of the simulation
model for the seventh replication of Strategy 2 is 54.88 in Table 9.4. Parameters
for this balanced CR design are
Number of factor levels number of alternative system designs K 3
Number of observations for each factor level n 10
Total number of observations N nK (10)3 30
Inspection of the summary statistics presented in Table 9.4 indicates that
Strategy 3 produced the highest mean throughput and Strategy 2 the lowest.
Again, we should not jump to conclusions without a careful analysis of the experi-
mental data. Therefore, we will use analysis of variance (ANOVA) in conjunction
with a multiple comparison test to guide our decision.
Analysis of Variance
Analysis of variance (ANOVA) allows us to partition the total variation in the out-
put response from the simulated system into two components—variation due to the
effect of the treatments and variation due to experimental error (the inherent vari-
ability in the simulated system). For this problem case, we are interested in knowing
if the variation due to the treatment is sufficient to conclude that the performance of
one strategy is significantly different than the other with respect to mean throughput
of the system. We assume that the observations are drawn from normally distributed
populations and that they are independent within a strategy and between strategies.
Therefore, the variance reduction technique based on common random numbers
(CRN) presented in section 9.5 cannot be used with this method.
The fixed-effects model is the underlying linear statistical model used for the
analysis because the levels of the factor are fixed and we will consider each pos-
sible factor level. The fixed-effects model is written as
for i 1, 2, 3, . . . , K
xi j i ij
for j 1, 2, 3, . . . , n
where i is the effect of the ith treatment (ith strategy in our example) as a devia-
tion from the overall (common to all treatments) population mean and i j is the
error associated with this observation. In the context of simulation, the i j term
represents the random variation of the response xi j that occurred during the jth rep-
lication of the ith treatment. Assumptions for the fixed-effects model are that the
sum of all i equals zero and that the error terms i j are independent and normally
distributed with a mean of zero and common variance. There are methods for test-
ing the reasonableness of the normality and common variance assumptions. How-
ever, the procedure presented in this section is reported to be somewhat insensitive
to small violations of these assumptions (Miller et al. 1990). Specifically, for the
buffer allocation example, we are testing the equality of three treatment effects
(Strategies 1, 2, and 3) to determine if there are statistically significant differences
among them. Therefore, our hypotheses are written as
H0: 1 2 3 0
H1: i 0 for at least one i, for i 1, 2, 3
Basically, the previous null hypothesis that the K population means are all
equal (1 2 3 . . . K ) is replaced by the null hypothesis 1
2 3 . . . K 0 for the fixed-effects model. Likewise, the alternative
hypothesis that at least two of the population means are unequal is replaced by
i 0 for at least one i. Because only one factor is considered in this problem, a
simple one-way analysis of variance is used to determine FCALC, the test statistic
that will be used for the hypothesis test. If the computed FCALC value exceeds a
threshold value called the critical value, denoted FCRITICAL, we shall reject the null
hypothesis that states that the treatment effects do not differ and conclude that
there are statistically significant differences among the treatments (strategies in
our example problem).
To help us with the hypothesis test, let’s summarize the experimental results
shown in Table 9.4 for the example problem. The first summary statistic that we
will compute is called the sum of squares (SSi) and is calculated for the ANOVA
for each factor level (Strategies 1, 2, and 3 in this case). In a balanced design
where the number of observations n for each factor level is a constant, the sum of
squares is calculated using the formula
( j 1 xi j )2
n
( j 1 x1 j )
10
10
(563.02)2
SS1 [(54.48)2 (57.36)2 . . . (55.29)2] ________ 16.98
10
SS2 12.23
SS3 3.90
The grand total of the N observations (N nK) collected from the output response
of the simulated system is computed by
Grand total x . . i1 j1 xij i1 xi
K n K
The overall mean of the N observations collected from the output response of the
simulated system is computed by
i1 j1 xi j x . .
K n
1,683.27
x . . ________
Overall mean x̄ . . ___ 56.11
N 30
Our analysis is simplified because a balanced design was used (equal observa-
tions for each factor level). We are now ready to define the computational formulas
for the ANOVA table elements (for a balanced design) needed to conduct the hy-
pothesis test. As we do, we will construct the ANOVA table for the buffer allocation
example. The computational formulas for the ANOVA table elements are
Degrees of freedom total (corrected) df(total corrected) N 1
30 1 29
Degrees of freedom treatment df(treatment) K 1 3 1 2
Degrees of freedom error df(error) N K 30 3 27
and
Sum of squares error SSE i1 SSi 16.98 12.23 3.90 33.11
K
x2
Sum of squares treatment SST _1n ( i1 x2i ) __. .
K
K
1 ((563.02)2 (546.33)2 (573.92)2) __________
SST ___
10
(1,683.27)2
3
38.62
Sum of squares total (corrrected) SSTC SST SSE
38.62 33.11 71.73
and
SST
Mean square treatment MST ___________ 38.62 19.31
_____
df(treatment) 2
SSF _____
Mean square error MSE ________ 33.11 1.23
df(error) 27
and finally
Calculated F statistic FCALC _____ 19.31 15.70
MST _____
MSE 1.23
Table 9.5 presents the ANOVA table for this problem. We will compare the value
of FCALC with a value from the F table in Appendix C to determine whether to reject
or fail to reject the null hypothesis H0: 1 2 3 0. The values obtained from
the F table in Appendix C are referred to as critical values and are determined by
F(df(treatment), df(error); ). For this problem, F(2,27; 0.05) 3.35 FCRITICAL, using a signifi-
cance level () of 0.05. Therefore, we will reject H0 since FCALC FCRITICAL at the
0.05 level of significance. If we believe the data in Table 9.4 satisfy the assump-
tions of the fixed-effects model, then we would conclude that the buffer allocation
strategy (treatment) significantly affects the mean throughput of the system. We now
have evidence that at least one strategy produces better results than the other strate-
gies. Next, a multiple comparison test will be conducted to determine which strategy
(or strategies) causes the significance.
comparisons for K candidate designs is computed by K(K 1)2. The LSD test
statistic is calculated as _______
2(MSE)
LSD () t(df (error),2) _______
n
The decision rule states that if the difference in the sample mean response values
exceeds the LSD test statistic, then the population mean response values are sig-
nificantly different at a given level of significance. Mathematically, the decision
rule is written as
If xi xi LSD (), then i and i are significantly different at the level of
significance.
For this problem, the LSD test statistic is determined at the 0.05 level of
significance:
_______ _______
2(MSE) 2(1.23)
LSD(0.05) t27,0.025 _______
n 2.052 _______ 1.02
10
Table 9.6 presents the results of the three pairwise comparisons for the LSD analy-
sis. With 95 percent confidence, we conclude that each pair of means is different
(1 2, 1 3, and 2 3). We may be inclined to believe that the best strategy
is Strategy 3, the second best strategy is Strategy 1, and the worst strategy is Strategy 2.
Recall that the Bonferroni approach in section 9.4.1 did not detect a signifi-
cant difference between Strategy 1 (1) and Strategy 3 (3). One possible expla-
nation is that the LSD test is considered to be more liberal in that it will indicate
a difference before the more conservative Bonferroni approach. Perhaps if the
paired-t confidence intervals had been used in conjunction with common random
numbers (which is perfectly acceptable because the paired-t method does not re-
quire that observations be independent between populations), then the Bonfer-
roni approach would have also indicated a difference. We are not suggesting here
that the Bonferroni approach is in error (or that the LSD test is in error). It could
be that there really is no difference between the performances of Strategy 1 and
Strategy 3 or that we have not collected enough observations to be conclusive.
There are several multiple comparison tests from which to choose. Other
tests include Tukey’s honestly significant difference (HSD) test, Bayes LSD
(BLSD) test, and a test by Scheffe. The LSD and BLSD tests are considered to be
TABLE 9.6 LSD Analysis
Strategy 2 Strategy 1
x̄2 54.63 x̄1 56.30
liberal in that they will indicate a difference between i and i before the more
conservative Scheffe test. A book by Petersen (1985) provides more information
on multiple comparison tests.
FIGURE 9.3
Relationship between Factors (X1, X2, . . . , Xn) Simulation Output responses
factors (decision
variables) and output model
responses.
in the model. For this reason, most simulation software provides several unique
streams of uniformly distributed random numbers to drive the simulation. This
concept is illustrated in Figure 9.5 in that separate random number streams are
used to generate service times at each of the four machines. If an alternative de-
sign for the system was the addition of a fifth machine, the effects of adding the
fifth machine could be measured while holding the behavior of the original four
machines constant.
In ProModel, up to 100 streams (1 through 100) are available to assign to any
random variable specified in the model. Each stream can have one of 100 differ-
ent initial seed values assigned to it. Each seed number starts generating random
numbers at an offset of 100,000 from the previous seed number (seed 1 gener-
ates 100,000 random numbers before it catches up to the starting point in the
cycle of seed 2). For most simulations, this ensures that streams do not overlap.
If you do not specify an initial seed value for a stream that is used, ProModel will
use the same seed number as the stream number (stream 3 uses the third seed).
A detailed explanation of how random number generators work and how they
produce unique streams of random numbers is provided in Chapter 3.
Complete synchronization of the random numbers across different models is
sometimes difficult to achieve. Therefore, we often settle for partial synchroni-
zation. At the very least, it is a good idea to set up two streams with one stream
of random numbers used to generate an entity’s arrival pattern and the other
stream of random numbers used to generate all other activities in the model.
That way, activities added to the model will not inadvertently alter the arrival
pattern because they do not affect the sample values generated from the arrival
distribution.
and
)s(12) ___________
(t9,0.025__ (2.262) 1.16
hw __________ ___ 0.83 parts per hour
n 10
column. Without working through the mathematics, know that this occurs when a
negative correlation is created between the observations from each system instead
of a positive correlation. Unfortunately, there is really no way of knowing before-
hand if this will happen. However, the likelihood of realizing a negative correlation in
practice is low, so the ticket to success lies in your ability to synchronize the random
numbers. If good synchronization is achieved, then the desired result of reducing the
standard deviation of the observations in the Difference column will likely be realized.
9.6 Summary
An important point to make here is that simulation, by itself, does not solve a
problem. Simulation merely provides a means to evaluate proposed solutions by
estimating how they behave. The user of the simulation model has the responsibil-
ity to generate candidate solutions either manually or by use of automatic opti-
mization techniques and to correctly measure the utility of the solutions based on
the output from the simulation. This chapter presented several statistical methods
for comparing the output produced by simulation models representing candidate
solutions or designs.
When comparing two candidate system designs, we recommend using either
the Welch confidence interval method or the paired-t confidence interval. Also,
a variance reduction technique based on common random numbers can be used
in conjunction with the paired-t confidence interval to improve the precision of
the confidence interval. When comparing between three and five candidate sys-
tem designs, the Bonferroni approach is useful. For more than five designs, the
ANOVA procedure in conjunction with Fisher’s least significance difference test
is a good choice, assuming that the population variances are approximately equal.
Additional methods useful for comparing the output produced by different simu-
lation models can be found in Goldsman and Nelson (1998).
References
Banks, Jerry; John S. Carson II; Barry L. Nelson; and David M. Nicol. Discrete-Event
System Simulation. 5th ed. Englewood Cliffs, NJ: Prentice Hall, 2010.
Bateman, Robert E.; Royce O. Bowden; Thomas J. Gogg; Charles R. Harrell; and Jack R. A.
Mott. System Improvement Using Simulation. Orem, UT: PROMODEL Corp., 1997.
Goldsman, David, and Berry L. Nelson. “Comparing Systems via Simulation.” Chapter 8
in Handbook of Simulation. New York: John Wiley and Sons, 1998.
Hines, William W., and Douglas C. Montgomery. Probability and Statistics in Engineering
and Management Science. New York: John Wiley & Sons, 1990.
Hoover, Stewart V., and Ronald F. Perry. Simulation: A Problem-Solving Approach. Read-
ing, MA: Addison-Wesley, 1989.
Law, Averill M. Simulation Modeling and Analysis. New York: McGraw-Hill, 2007.
Miller, Irwin R.; John E. Freund; and Richard Johnson. Probability and Statistics for Engi-
neers. Englewood Cliffs, NJ: Prentice Hall, 1990.
Miller, Rupert G. Beyond ANOVA, Basics of Applied Statistics, New York: Wiley, 1986.
Montgomery, Douglas C. Design and Analysis of Experiments. 7th ed. New York: John
Wiley & Sons, 2008.
Petersen, Roger G. Design and Analysis of Experiments. New York: Marcel Dekker, 1985.
10 SIMULATION
OPTIMIZATION
“Man is a goal seeking animal. His life only has meaning if he is reaching out
and striving for his goals.”
—Aristotle
10.1 Introduction
Simulation models of systems are built for many reasons. Some models are built
to gain a better understanding of a system, to forecast the output of a system, or to
compare one system to another. If the reason for building simulation models is to
find answers to questions like “What are the optimal settings for to mini-
mize (or maximize) ?” then optimization is the appropriate technology to
combine with simulation. Optimization is the process of trying different combina-
tions of values for the variables that can be controlled to seek the combination of
values that provides the most desirable output from the simulation model.
For convenience, let us think of the simulation model as a black box that
imitates the actual system. When inputs are presented to the black box, it produces
output that estimates how the actual system responds. In our question, the first
blank represents the inputs to the simulation model that are controllable by the
decision maker. These inputs are often called decision variables or factors. The
second blank represents the performance measures of interest that are computed
from the stochastic output of the simulation model when the decision variables are
set to specific values (Figure 10.1). In the question, “What is the optimal number
of material handling devices needed to minimize the time that workstations are
starved for material?” the decision variable is the number of material handling
devices and the performance measure computed from the output of the simulation
model is the amount of time that workstations are starved. The objective, then, is
to seek the optimal value for each decision variable that minimizes, or maximizes,
the expected value of the performance measure(s) of interest. The performance
273
FIGURE 10.1
Optimization Decision variables (X1, X2, . . . , Xn)
Relationship between Simulation
optimization algorithm algorithm model
and simulation model.
Output responses
measure is traditionally called the objective function. Note that the expected value
of the objective function is estimated by averaging the model’s output over mul-
tiple replications or batch intervals. The simulation optimization problem is more
formally stated as
Min or Max E [ f (X1, X2, . . . , Xn)]
Subject to
Lower Boundi ⱕ Xi ⱕ Upper Boundi for i ⫽ 1, 2, . . . , n
where E [ f (X1, X2, . . . , Xn)] denotes the expected value of the objective function,
which is estimated.
The search for the optimal solution can be conducted manually or automated
with algorithms specifically designed to seek the optimal solution without evalu-
ating all possible solutions. Interfacing optimization algorithms that can automati-
cally generate solutions and evaluate them in simulation models is a worthwhile
endeavor because
• It automates part of the analysis process, saving the analyst time.
• A logical method is used to efficiently explore the realm of possible
solutions, seeking the best.
• The method often finds several exemplary solutions for the analyst to
consider.
The latter is particularly important because, within the list of optimized solutions,
there may be solutions that the decision maker may have otherwise overlooked.
In 1995, PROMODEL Corporation and Decision Science, Incorporated, de-
veloped SimRunner based on the research of Bowden (1992) on the use of modern
optimization algorithms for simulation-based optimization and machine learning.
SimRunner helps those wishing to use advanced optimization concepts to seek
better solutions from their simulation models. SimRunner uses an optimization
method based on evolutionary algorithms. It is the first widely used, commer-
cially available simulation optimization package designed for major simulation
packages (ProModel, MedModel, ServiceModel, and ProcessModel). Although
SimRunner is relatively easy to use, it can be more effectively used with a basic
understanding of how it seeks optimal solutions to a problem. Therefore, the pur-
pose of this chapter is fourfold:
• To provide an introduction to simulation optimization, focusing on
the latest developments in integrating simulation and a class of direct
optimization techniques called evolutionary algorithms.
FIGURE 10.2
SimRunner plots the
output responses
generated by a
ProModel simulation
model as it seeks the
optimal solution,
which occurred at the
highest peak.
several problems, Pegden and Gately concluded that their packages extended the
capabilities of the simulation language by “providing for automatic optimization
of decision.”
The direct search algorithms available today for simulation optimization are
much better than those available in the late 1970s. Using these newer algorithms,
the SimRunner simulation optimization tool was developed in 1995. Following
SimRunner, two other simulation software vendors soon added an optimization
feature to their products. These products are OptQuest, which was introduced in
1996 to be used with simulation models built with Micro Saint software, and WIT-
NESS Optimizer, which was introduced in 1997 to be used with simulation mod-
els built with Witness software. The optimization module in OptQuest is based
on scatter search, which has links to Tabu Search and the popular evolutionary
algorithm called the Genetic Algorithm (Glover 1994; Glover et al. 1996). In ad-
dition to SimRunner, ProModel also works with OptQuest. WITNESS Optimizer
is based on a search algorithm called Simulated Annealing (Markt and Mayer
1997). Today most major simulation software packages include an optimization
feature.
SimRunner has an optimization module and a module for determining the
required sample size (replications) and a model’s warm-up period (in the case
of a steady-state analysis). The optimization module can optimize integer and
real decision variables. The design of the optimization module in SimRunner was
influenced by optima-seeking techniques such as Tabu Search (Glover 1990) and
evolutionary algorithms (Fogel 1992; Goldberg 1989; Schwefel 1981), though it
most closely resembles an evolutionary algorithm (SimRunner 1996b).
Mollaghasemi (1991) suggest that GAs and Simulated Annealing are the algorithms
of choice when dealing with a large number of decision variables. Tompkins and
Azadivar (1995) recommend using GAs when the optimization problem involves
qualitative (logical) decision variables. The authors have extensively researched
the use of genetic algorithms, evolutionary programming, and evolution strategies
for solving manufacturing simulation optimization problems and simulation-based
machine learning problems (Bowden 1995; Bowden, Neppalli, and Calvert 1995;
Bowden, Hall, and Usher 1996; Hall, Bowden, and Usher 1996).
Reports have also appeared in the trade journal literature on how the EA-
based optimizer in SimRunner helped to solve real-world problems. For example,
IBM; Sverdrup Facilities, Inc.; and Baystate Health Systems report benefits from
using SimRunner as a decision support tool (Akbay 1996). The simulation group
at Lockheed Martin used SimRunner to help determine the most efficient lot sizes
for parts and when the parts should be released to the system to meet schedules
(Anonymous 1996).
FIGURE 10.3
Ackley’s function with noise and the ES’s progress over eight generations.
20 Ackley's Function
18
Generation 1
16
Measured response
Generation 2
14
12 Generation 3
10 Generation 4
8 Generation 5
6
Generation 6
4
2 Generation 7
0 Generation 8
⫺10 ⫺5 0 5 10
Decision variable X
The authors are not advocating that analysts can forget about determining
the number of replications needed to satisfactorily estimate the expected value of
the response. However, to effectively conduct a search for the optimal solution,
an algorithm must be able to deal with noisy response surfaces and the resulting
uncertainties that exist even when several observations (replications) are used to
estimate a solution’s true performance.
select the minimum number of statistics necessary to estimate the utility of a solu-
tion. ProModel products allow users to turn off statistical tracking for locations,
entities, resources, and variables that are not needed to estimate the performance
of a solution. If, for example, a model is to estimate an entity’s time in the system,
then only entity-based statistics need be recorded. Also, turning the animation
feature off generally reduces the time to run the model.
Step 1. The decision variables believed to affect the output of the simulation
model are first programmed into the model as variables whose values can be
quickly changed by the EA. Decision variables are typically the parameters whose
values can be adjusted by management, such as the number of nurses assigned to
a shift or the number of machines to be placed in a work cell.
Step 2. For each decision variable, define its numeric data type (integer or real)
and its lower bound (lowest possible value) and upper bound (highest possible
value). During the search, the EA will generate solutions by varying the values of
decision variables according to their data types, lower bounds, and upper bounds.
The number of decision variables and the range of possible values affect the size
of the search space (number of possible solutions to the problem). Increasing the
number of decision variables or their range of values increases the size of the
search space, which can make it more difficult and time-consuming to identify
the optimal solution. As a rule, include only those decision variables known to
significantly affect the output of the simulation model and judiciously define the
range of possible values for each decision variable. Also, care should be taken
when defining the lower and upper bounds of the decision variables to ensure that
a combination of values will not be created that lead to a solution not envisioned
when the model was built.
Step 3. After selecting the decision variables, construct the objective function
to measure the utility of the solutions tested by the EA. Actually, the foundation
for the objective function would have already been established when the goals for
the simulation project were set. For example, if the goal of the modeling project is
to find ways to minimize a customer’s waiting time in a bank, then the objective
function should measure an entity’s (customer’s) waiting time in the bank. The
objective function is built using terms taken from the output report generated at
the end of the simulation run. Objective function terms can be based on entity sta-
tistics, location statistics, resource statistics, variable statistics, and so on. The user
specifies whether a term is to be minimized or maximized as well as the overall
weighting of that term in the objective function. Some terms may be more or less
important to the user than other terms. Remember that as terms are added to the
objective function, the complexity of the search space may increase, which makes
a more difficult optimization problem. From a statistical point of view, single-term
objective functions are also preferable to multiterm objective functions. Therefore,
strive to keep the objective function as specific as possible.
The objective function is a random variable, and a set of initial experiments
should be conducted to estimate its variability (standard deviation). Note that there
is a possibility that the objective function’s standard deviation differs from one
solution to the next. Therefore, the required number of replications necessary to es-
timate the expected value of the objective function may change from one solution
to the next. Thus the objective function’s standard deviation should be measured
for several different solutions and the highest standard deviation recorded used to
compute the number of replications necessary to estimate the expected value of
the objective function. When selecting the set of test solutions, choose solutions
that are very different from one another. For example, form solutions by setting the
decision variables to their lower bounds, middle values, or upper bounds.
A better approach for controlling the number of replications used to estimate
the expected value of the objective function for a given solution would be to in-
corporate a rule into the model that schedules additional replications until the es-
timate reaches a desired level of precision (confidence interval half-width). Using
this technique can help to avoid running too many replications for some solutions
and too few replications for others.
Step 4. Select the size of the EA’s population (number of solutions) and begin
the search. The size of the population of solutions used to conduct the search
affects both the likelihood that the algorithm will locate the optimal solution and
the time required to conduct the search. In general, as the population size is in-
creased, the algorithm finds better solutions. However, increasing the population
size generally increases the time required to conduct the search. Therefore, a bal-
ance must be struck between finding the optimum and the amount of available
time to conduct the search.
Step 5. After the EA’s search has concluded (or halted due to time constraints),
the analyst should study the solutions found by the algorithm. In addition to the
best solution discovered, the algorithm usually finds many other competitive
solutions. A good practice is to rank each solution evaluated based on its utility
as measured by the objective function. Next, select the most highly competitive
solutions and, if necessary, make additional model replications of those solutions
to get better estimates of their true utility. And, if necessary, refer to Chapter 9
for background on statistical techniques that can help you make a final decision
between competing solutions. Also, keep in mind that the database of solutions
evaluated by the EA represents a rich source of information about the behavior,
or response surface, of the simulation model. Sorting and graphing the solutions
can help you interpret the “meaning” of the data and gain a better understanding
of how the system behaves.
If the general procedure presented is followed, chances are that a good course
of action will be identified. This general procedure is easily carried out using Pro-
Model simulation products. Analysts can use SimRunner to help
• Determine the length of time and warm-up period (if applicable) for
running a model.
• Determine the required number of replications for obtaining estimates
with a specified level of precision and confidence.
• Search for the optimal values for the important decision variables.
Even though it is easy to use SimRunner and other modern optimizers, do
not fall into the trap of letting them become the decision maker. Study the top
solutions found by the optimizers as you might study the performance records of
different cars for a possible purchase. Kick their tires, look under their hoods, and
drive them around the block before buying. Always remember that the optimizer
is not the decision maker. It only suggest a possible course of action. It is the
user’s responsibility to make the final decision.
that disruptions (machine failures, line imbalances, quality problems, or the like)
will shut down the production line. Several strategies have been developed for
determining the amount of buffer storage needed between workstations. However,
these strategies are often developed based on simplifying assumptions, made for
mathematical convenience, that rarely hold true for real production systems.
One way to avoid oversimplifying a problem for the sake of mathematical
convenience is to build a simulation model of the production system and use it
to help identify the amount of buffer storage space needed between workstations.
However, the number of possible solutions to the buffer allocation problem grows
rapidly as the size of the production system (number of possible buffer storage
areas and their possible sizes) increases, making it impractical to evaluate all so-
lutions. In such cases, it is helpful to use simulation optimization software like
SimRunner to identify a set of candidate solutions.
This example is loosely based on the example production system presented
in Chapter 9. It gives readers insight into how to formulate simulation optimiza-
tion problems when using SimRunner. The example is not fully solved. Its com-
pletion is left as an exercise in Lab Chapter 10.
FIGURE 10.4
Production system
with four workstations
and three buffer
storage areas.
.72 4.56
machine, where it waits to be processed. However, if the buffer is full, the part
cannot move forward and remains on the machine until a space becomes available
in the buffer. Furthermore, the machine is blocked and no other parts can move
to the machine for processing. The part exits the system after being processed by
the fourth machine. Note that parts are selected from the buffers to be processed
by a machine in a first-in, first-out order. The processing time at each machine is
exponentially distributed with a mean of 1.0 minute, 1.3 minutes, 0.7 minute, and
1.0 minute for machines one, two, three, and four, respectively. The time to move
parts from one location to the next is negligible.
For this problem, three decision variables describe how buffer space is al-
located (one decision variable for each buffer to signify the number of parts that
can be stored in the buffer). The Goal is to find the optimal value for each decision
variable to maximize the profit made from the sale of the parts. The manufacturer
collects $10 per part produced. The limitation is that each unit of space provided
for a part in a buffer costs $1,000. So the buffer storage has to be strategically al-
located to maximize the throughput of the system. Throughput will be measured
as the number of parts completed during a 30-day period.
Step 1. In this step, the decision variables for the problem are identified and
defined. Three decision variables are needed to represent the number of parts that
can be stored in each buffer (buffer capacity). Let Q1, Q2, and Q3 represent the
number of parts that can be stored in buffers 1, 2, and 3, respectively.
Step 2. The numeric data type for each Qi is integer. If it is assumed that each
buffer will hold a minimum of one part, then the lower bound for each Qi is 1. The
upper bound for each decision variable could arbitrarily be set to, say, 20. How-
ever, keep in mind that as the range of values for a decision variable is increased,
the size of the search space also increases and will likely increase the time to con-
duct the search. Therefore, this is a good place to apply existing knowledge about
the performance and design of the system.
For example, physical constraints may limit the maximum capacity of each
buffer to no greater than 15 parts. If so, there is no need to conduct a search with
a range of values that produce infeasible solutions (buffer capacities greater than
15 parts). Considering that the fourth machine’s processing time is larger than the
third machine’s processing time, parts will tend to queue up at the third buffer.
Therefore, it might be a good idea to set the upper bound for Q3 to a larger value
than the other two decision variables. However, be careful not to assume too much
because it could prevent the optimization algorithm from exploring regions in the
search space that may contain good solutions.
With this information, it is decided to set the upper bound for the capacity of
each buffer to 15 parts. Therefore, the bounds for each decision variable are
1 ⱕ Q1 ⱕ 15 1 ⱕ Q2 ⱕ 15 1 ⱕ Q3 ⱕ 15
Given that each of the three decision variable has 15 different values, there are
153, or 3,375, unique solutions to the problem.
Step 3. Here the objective function is formulized. The model was built to in-
vestigate buffer allocation strategies to maximize the throughput of the system.
Given that the manufacturer collects $10 per part produced and that each unit of
space provided for a part in a buffer costs $1,000, the objective function for the
optimization could be stated as
Maximize[$10(Throughput) ⫺ $1,000(Q1 ⫹ Q2 ⫹ Q3)]
where Throughput is the total number of parts produced during a 30-day
period.
Next, initial experiments are conducted to estimate the variability of the ob-
jective function in order to determine the number of replications the EA-based
optimization algorithm will use to estimate the expected value of the objective
function for each solution it evaluates. While doing this, it was also noticed that
the throughput level increased very little for buffer capacities beyond a value
of nine. Therefore, it was decided to change the upper bound for each decision
variable to nine. This resulted in a search space of 93, or 729, unique solutions, a
reduction of 2,646 solutions from the original formulation. This will likely reduce
the search time.
Step 4. Select the size of the population that the EA-based optimization al-
gorithm will use to conduct its search. SimRunner allows the user to select an
optimization profile that influences the degree of thoroughness used to search
for the optimal solution. The three optimization profiles are aggressive, moder-
ate, and cautious, which correspond to EA population sizes of small, medium,
and large. The aggressive profile generally results in a quick search for locally
optimal solutions and is used when computer time is limited. The cautious pro-
file specifies that a more thorough search for the global optimum be conducted
and is used when computer time is plentiful. At this point, the analyst knows the
amount of time required to evaluate a solution. Only one more piece of informa-
tion is needed to determine how long it will take the algorithm to conduct its
search. That is the fraction of the 729 solutions the algorithm will evaluate before
converging to a final solution. Unfortunately, there is no way of knowing this in
advance. With time running out before a recommendation for the system must be
given to management, the analyst elects to use a small population size by select-
ing SimRunner’s aggressive optimization profile.
Step 5. After the search concludes, the analyst selects for further evaluation
some of the top solutions found by the optimization algorithm. Note that this does
not necessarily mean that only those solutions with the best objective function
values are chosen, because the analyst should conduct both a quantitative and a
qualitative analysis. On the quantitative side, statistical procedures presented in
Chapter 9 are used to gain a better understanding of the relative differences in per-
formance between the candidate solutions. On the qualitative side, one solution
may be preferred over another based on factors such as ease of implementation.
Figure 10.5 illustrates the results from a SimRunner optimization of the buffer
allocation problem using an aggressive optimization profile. The warm-up time for
the simulation was set to 10 days, with each day representing a 24-hour production
period. After the warm-up time of 10 days (240 hours), the system is simulated for
an additional 30 days (720 hours) to determine throughput. The estimate for the
expected value of the objective function was based on five replications of the simu-
lation. The smoother line that is always at the top of the Performance Measures Plot
in Figure 10.5 represents the value of the objective function for the best solution
identified by SimRunner during the optimization. Notice the rapid improvement in
the value of the objective function during the early part of the search as SimRunner
identifies better buffer capacities. The other, more irregular line represents the value
of the objective function for all the solutions that SimRunner tried.
SimRunner’s best solution to the problem specifies a Buffer 1 capacity of
nine, a Buffer 2 capacity of seven, and a Buffer 3 capacity of three and was the
33rd solution (experiment) evaluated by SimRunner. The best solution is located
at the top of the table in Figure 10.5. SimRunner sorts the solutions in the table
FIGURE 10.5
SimRunner results for
the buffer allocation
problem.
from best to worst. SimRunner evaluated 82 out of the possible 729 solutions.
Note that there is no guarantee that SimRunner’s best solution is in fact the opti-
mum solution to the problem. However, it is likely to be one of the better solutions
to the problem and could be the optimum one.
The last two columns in the SimRunner table shown in Figure 10.5 display
the lower and upper bounds of a 95 percent confidence interval for each solution
evaluated. Notice that there is significant overlap between the confidence inter-
vals. Although this is not a formal hypothesis-testing procedure, the overlapping
confidence intervals suggest the possibility that there is not a significant differ-
ence in the performance of the top solutions displayed in the table. Therefore, it
would be wise to run additional replications of the favorite solutions from the list
and/or use one of the hypothesis-testing procedures in Chapter 9 before selecting
a particular solution as the best. The real value here is that SimRunner automati-
cally conducted the search, without the analyst having to hover over it, and re-
ported back several good solutions to the problem for the analyst to consider.
FIGURE 10.6
The two-stage pull Trigger ⫽ 1 Trigger ⫽ 2
Kanban posts
Final product Component
Subassembly Kanban card
Figure 10.6 illustrates the relationship of the processes in the two-stage pull
production system of interest that produces several different types of parts. Cus-
tomer demand for the final product causes containers of subassemblies to be pulled
from the Stage One WIP location to the assembly lines. As each container is with-
drawn from the Stage One WIP location, a production-ordering kanban card rep-
resenting the number of subassemblies in a container is sent to the kanban post for
the Stage One processing system. When the number of kanban cards for a given
subassembly meets its trigger value, the necessary component parts are pulled
from the Stage Two WIP to create the subassemblies. Upon completing the Stage
One process, subassemblies are loaded into containers, the corresponding kanban
card is attached to the container, and both are sent to Stage One WIP. The container
and card remain in the Stage One WIP location until pulled to an assembly line.
In Stage Two, workers process raw materials to fill the Stage Two WIP loca-
tion as component parts are pulled from it by Stage One. As component parts are
withdrawn from the Stage Two WIP location and placed into the Stage One process,
a production-ordering kanban card representing the quantity of component parts in
a container is sent to the kanban post for the Stage Two line. When the number of
kanban cards for a given component part meets a trigger value, production orders
equal to the trigger value are issued to the Stage Two line. As workers move com-
pleted orders of component parts from the Stage Two line to WIP, the corresponding
kanban cards follow the component parts to the Stage Two WIP location.
While an overall reduction in WIP is sought, production planners desire a
solution (kanban cards and trigger values for each stage) that gives preference to
minimizing the containers in the Stage One WIP location. This requirement is due
to space limitations.
discrete-event simulation model. The model assumes constant interarrival times for
customer orders to the assembly lines. However, workers at the assembly lines may
find defects in the subassemblies, which increases subassembly demand above that
needed for scheduled customer demand. The number of defective subassemblies
found on the assembly lines follows a stochastic function. Production times for the
Stage One process and Stage Two line are constant because they are automated pro-
cesses. Setup time, time between failures, and time to repair for the Stage Two line
are triangularly distributed. Each simulation run consists of a 10-day (two-week)
warm-up period followed by a 20-day (one-month) steady-state period.
The performance measure to be maximized is
f (a) ⫽ W1 (AvgPct ⫹ MinPct) ⫺ W2 (TK1) ⫺ W3 (TK2)
where AvgPct is the average throughput percentage (percentage of demand satis-
fied) for all product types coming off the assembly lines; MinPct is the minimum
throughput percentage for all product types coming off the assembly lines; TK1
is the total number of kanban cards in Stage One; TK2 is the total number of
kanban cards in Stage Two; and W1, W2, and W3 are coefficients that reflect the
level of importance (weighting) assigned to each term by production planners.
The weighting levels assigned to W1, W2, and W3 are 20.0, 0.025, and 0.015, re-
spectively. Using this performance function, the objective is to find a solution that
will maximize throughput while minimizing the total number of kanban cards in
the system.
The production planners decided to fix the trigger values in the Stage One
process to 1; therefore, the optimal number of kanban cards in the Stage One
process and the optimal number of kanban cards and corresponding trigger values
in the Stage Two line for each of the 11 different part types being produced need
to be determined. Thus the problem contains 33 integer decision variables. Each
solution is a vector a ⫽ (K11, K12, K13, . . . , K111; K21, K22, K23, . . . , K211; T 21,
T 22, T 23, . . . , T 211) where K1i represents the number of kanban cards for part type
i circulating in the Stage One process, K2i represents the number of kanban cards
for part type i circulating in the Stage Two line, and T2i represents the correspond-
ing trigger quantities for part type i used in the Stage Two line. Considering the
range of possible values for each of the decision variables (omitted for brevity),
there are 4.81 ⫻ 1041 unique solutions to this problem.
Kanbans ⫽
Monthly setups demand coefficient
Monthly demand
______________ ⫹
Daily
⫻
Safety
______________________________________
Container capacity
where the safety coefficient represents the amount of WIP needed in the system.
Production planners assumed a safety coefficient that resulted in one day of WIP
for each part type. Additionally, they decided to use one setup per day for each part
type. Although this equation provides an estimate of the minimum number of kanban
cards, it does not address trigger values. Therefore, trigger values for the Stage Two
line were set at the expected number of containers consumed for each part type in one
day. The Toyota equation recommended using a total of 243 kanban cards. The details
of the calculation are omitted for brevity. When evaluated in the simulation model,
this solution yielded a performance score of 35.140 (using the performance function
defined in section 10.7.2) based on four independent simulation runs (replications).
Measured response
solutions found by the
optimization module 37
are better than the
solutions generated 36
using the Toyota
method.
35
34
33
0 50 100 150
Generation
of the solutions. Both solutions achieved the required throughput using a substan-
tially different number of kanban cards.
An application of Fisher’s LSD statistical multiple comparison test presented
in Chapter 9 suggests that the performance scores for the methods in Table 10.1
are different at a 0.05 level of significance. Results indicate that the optimization
module produced a significantly better solution to the kanban sizing problem than
did the production planners using the Toyota technique. The solution that the op-
timization module found requires approximately 54 percent fewer kanban cards
(54 percent less WIP) than the solution generated using the Toyota technique—a
considerable reduction in inventory carrying costs.
Considering the time required to run the simulation model on a personal com-
puter and the fact that there are 4.81 ⫻ 1041 unique solutions to the problem, it
would take years to evaluate all solutions to the problem. Obviously, this is not a
practical alternative. The optimization module required only a few hours to com-
plete its search. It evaluated only a small fraction of the total number of solutions
and provided a much better starting point than the Toyota solution for making the
final decision regarding the actual pull production system, a noteworthy contribu-
tion to the decision-making process whether or not the solution found is the global
optimum.
10.8 Summary
In recent years, major advances have been made in the development of user-
friendly simulation software packages. However, progress in developing simu-
lation output analysis tools has been especially slow in the area of simulation
optimization because conducting simulation optimization with traditional tech-
niques has been as much an art as a science (Greenwood, Rees, and Crouch 1993).
There are such an overwhelming number of traditional techniques that only in-
dividuals with extensive backgrounds in statistics and optimization theory have
realized the benefits of integrating simulation and optimization concepts. Using
newer optimization techniques, it is now possible to narrow the gap with user-
friendly, yet powerful, tools that allow analysts to combine simulation and opti-
mization for improved decision support. SimRunner is one such tool.
Our purpose is not to argue that evolutionary algorithms are the panacea for solv-
ing simulation optimization problems. Rather, our purpose is to introduce the reader
to evolutionary algorithms by illustrating how they work and how to use them for
simulation optimization and to expose the reader to the wealth of literature that dem-
onstrates that evolutionary algorithms are a viable choice for reliable optimization.
There will always be debate on what are the best techniques to use for simula-
tion optimization. Debate is welcome as it results in better understanding of the
real issues and leads to the development of better solution procedures. It must be
remembered, however, that the practical issue is not that the optimization tech-
nique guarantees that it locates the optimal solution in the shortest amount of time
for all possible problems that it may encounter; rather, it is that the optimization
technique consistently finds good solutions to problems that are better than the
solutions analysts are finding on their own. Newer techniques such as evolution-
ary algorithms and scatter search meet this requirement because they have proved
robust in their ability to solve a wide variety of problems, and their ease of use
makes them a practical choice for simulation optimization today (Boesel et al.
2001; Brady and Bowden 2001).
References
Ackley, D. A Connectionist Machine for Genetic Hill Climbing. Boston, MA: Kluwer, 1987.
Akbay, K. “Using Simulation Optimization to Find the Best Solution.” IIE Solutions, May
1996, pp. 24–29.
Anonymous, “Lockheed Martin.” IIE Solutions, December, 1996, pp. SS48–SS49.
Azadivar, F. “A Tutorial on Simulation Optimization.” 1992 Winter Simulation Conference.
Arlington Virginia, ed. Swain, J., D. Goldsman, R. Crain and J. Wilson. Institute of
Electrical and Electronics Engineers, Piscataway, NJ: 1992, pp. 198–204.
Bäck, T.; T. Beielstein; B. Naujoks; and J. Heistermann. “Evolutionary Algorithms for the
Optimization of Simulation Models Using PVM.” Euro PVM 1995—Second European
PVM 1995, User’s Group Meeting. Hermes, Paris, ed. Dongarra, J., M. Gengler,
B. Tourancheau and X. Vigouroux, 1995, pp. 277–282.
Bäck, T., and H.-P. Schwefel. “An Overview of Evolutionary Algorithms for Parameter
Optimization.” Evolutionary Computation 1, no. 1 (1993), pp. 1–23.
Barton, R., and J. Ivey. “Nelder-Mead Simplex Modifications for Simulation Optimization.”
Management Science 42, no. 7 (1996), pp. 954–73.
Biethahn, J., and V. Nissen. “Combinations of Simulation and Evolutionary Algorithms
in Management Science and Economics.” Annals of Operations Research 52 (1994),
pp. 183–208.
Boesel, J.; Bowden, R. O.; Glover, F.; and J. P. Kelly. “Future of Simulation Optimization.”
Proceedings of the 2001 Winter Simulation Conference, 2001, pp. 1466–69.
Bowden, R. O. “Genetic Algorithm Based Machine Learning Applied to the Dynamic
Routing of Discrete Parts.” Ph.D. Dissertation, Department of Industrial Engineering,
Mississippi State University, 1992.
Bowden, R. “The Evolution of Manufacturing Control Knowledge Using Reinforcement
Learning.” 1995 Annual International Conference on Industry, Engineering, and
Management Systems, Cocoa Beach, FL, ed. G. Lee. 1995, pp. 410–15.
Bowden, R., and S. Bullington. “An Evolutionary Algorithm for Discovering Manufactur-
ing Control Strategies.” In Evolutionary Algorithms in Management Applications, ed.
Biethahn, J. and V. Nissen. Berlin: Springer, 1995, pp. 124–38.
Bowden, R., and S. Bullington. “Development of Manufacturing Control Strategies Using
Unsupervised Learning.” IIE Transactions 28 (1996), pp. 319–31.
Bowden, R.; J. Hall; and J. Usher. “Integration of Evolutionary Programming and Simula-
tion to Optimize a Pull Production System.” Computers and Industrial Engineering 31,
no. 1/2 (1996), pp. 217–20.
Bowden, R.; R. Neppalli; and A. Calvert. “A Robust Method for Determining Good
Combinations of Queue Priority Rules.” Fourth International Industrial Engineering
Research Conference, Nashville, TN, ed. Schmeiser, B. and R. Uzsoy. Norcross, GA:
IIE, 1995, pp. 874–80.
SimRunner Online Software Help. Ypsilanti, MI: Decision Science, Inc., 1996b.
SimRunner User’s Guide ProModel Edition. Ypsilanti, MI: Decision Science, Inc., 1996a.
Stuckman, B.; G. Evans; and M. Mollaghasemi. “Comparison of Global Search Methods
for Design Optimization Using Simulation.” 1991 Winter Simulation Conference,
Phoenix, AZ, ed. Nelson, B., W. Kelton and G. Clark. Piscataway, NJ: Institute of
Electrical and Electronics Engineers, 1991, pp. 937–44.
Tompkins, G., and F. Azadivar. “Genetic Algorithms in Optimizing Simulated Systems.”
1991 Winter Simulation Conference, Arlington, VA, ed. Alexopoulos, C., K. Kang,
W. Lilegdon, and D. Goldsman. Piscataway, NJ: Institute of Electrical and Electronics
Engineers, 1995, pp. 757–62.
Usher, J., and R. Bowden. “The Application of Genetic Algorithms to Operation Sequenc-
ing for Use in Computer-Aided Process Planning.” Computers and Industrial Engi-
neering Journal 30, no. 4 (1996), pp. 999–1013.
11 MODELING
MANUFACTURING
SYSTEMS
“We no longer have the luxury of time to tune and debug new manufacturing
systems on the floor, since the expected economic life of a new system, before
major revision will be required, has become frighteningly short.”
—Conway and Maxwell
11.1 Introduction
In Chapter 6 we discussed general procedures for modeling the basic operation of
manufacturing and service systems. In this chapter we discuss design and operat-
ing issues that are more specific to manufacturing systems. Different applications
of simulation in manufacturing are presented together with how specific manufac-
turing issues are addressed in a simulation model. Most manufacturing systems
have material handling systems that, in some instances, have a major impact on
overall system performance. We touch on a few general issues related to material
handling systems in this chapter; however, a more thorough treatment of material
handling systems is given in Chapter 12.
Manufacturing systems are processing systems in which raw materials are
transformed into finished products through a series of operations performed at
workstations. In the rush to get new manufacturing systems on line, engineers
and planners often become overly preoccupied with the processes and methods
without fully considering the overall coordination of system components.
Many layout and improvement decisions in manufacturing are left to chance
or are driven by the latest management fad with little knowledge of how much
improvement will result or whether a decision will result in any improvement
at all. For example, work-in-process (WIP) reduction that is espoused by lean
just-in-time (JIT) often disrupts operations because it merely uncovers the rocks
(variability, long setups, or the like) hidden beneath the inventory water level that
necessitated the WIP in the first place. To accurately predict the effect of lowering
299
WIP levels requires sonar capability. Ideally you would like to identify and re-
move production rocks before arbitrarily lowering inventory levels and exposing
production to these hidden problems. “Unfortunately,” note Hopp and Spearman
(2001), “JIT, as described in the American literature, offers neither sonar (models
that predict the effects of system changes) nor a sense of the relative economics of
level reduction versus rock removal.”
Another popular management technique is the theory of constraints. In this
approach, a constraint or bottleneck is identified and a best-guess solution is imple-
mented, aimed at either eliminating that particular constraint or at least mitigating
the effects of the constraint. The implemented solution is then evaluated and, if
the impact was underestimated, another solution is attempted. As one manufactur-
ing manager expressed, “Contraint-based management can’t quantify investment
justification or develop a remedial action plan” (Berdine 1993). It is merely a
trial-and-error technique in which a best-guess solution is implemented with the
hope that enough improvement is realized to justify the cost of the solution. Even
Deming’s plan–do–check–act (PDCA) cycle of process improvement implicitly
prescribes checking performance after implementation. What the PDCA cycle
lacks is an evaluation step to test or simulate the plan before it is implemented.
While eventually leading to a better solution, this trial-and-error approach ends up
being costly, time-consuming, and disruptive to implement.
In this chapter we address the following topics:
• What are the special characteristics of manufacturing systems?
• What terminology is used to describe manufacturing operations?
• How is simulation applied to manufacturing systems?
• What techniques are used to model manufacturing systems?
FIGURE 11.1
Decision range
in manufacturing
simulation.
Cell Job Resource Production Process System Technology
manage- sequen- loading scheduling change configu- assess-
ment cing studies ration ment
• Methods analysis.
• Plant layout.
• Batch sizing.
• Production control.
• Inventory control.
• Supply chain planning.
• Production scheduling.
• Real-time control.
• Emulation.
Each of these application areas is discussed here.
Operations
Semiautomated
n
io
at
rm Semiautomated
fo
In
FIGURE 11.3
Material flow system. Receiving Manufacturing Shipping
FIGURE 11.4
Comparison between Part
(a) process layout, A
(b) product layout, and
(c) cell layout. (a) Process
layout
Part
B
(c) Cell
layout
Family 1 Family 2
is best. Often a combination of topologies is used within the same facility to ac-
commodate mixed requirements. For example, a facility might be predominately
a job shop with a few manufacturing cells. In general, the more the topology
resembles a product layout where the flow can be streamlined, the greater the ef-
ficiencies that can be achieved.
Perhaps the greatest impact simulation can have on plant layout comes from
designing the process itself, before the layout is even planned. Because the pro-
cess plan and method selection provide the basis for designing the layout, hav-
ing a well-designed process means that the layout will likely not require major
changes once the best layout is found for the optimized process.
FIGURE 11.5
To
Illustration of production
(a) production batch,
(b) move batch, and
(c) process batch.
(a) Production batch
and moved together from one workstation to another. A production batch is often
broken down into smaller move batches. This practice is called lot splitting. The
move batch need not be constant from location to location. In some batch manu-
facturing systems, for example, a technique called overlapped production is used
to minimize machine idle time and reduce work in process. In overlapped produc-
tion, a move batch arrives at a workstation where parts are individually processed.
Then instead of accumulating the entire batch before moving on, parts are sent on
individually or in smaller quantities to prevent the next workstation from being idle
while waiting for the entire batch. The process batch is the quantity of parts that are
processed simultaneously at a particular operation and usually consists of a single
part. The relationship between these batch types is illustrated in Figure 11.5.
Deciding which size to use for each particular batch type is usually based on
economic trade-offs between in-process inventory costs and economies of scale as-
sociated with larger batch sizes. Larger batch sizes usually result in lower setup costs,
handling costs, and processing costs. Several commands are provided in ProModel
for modeling batching operations such as GROUP, COMBINE, JOIN and LOAD.
Push Control
A push system is one in which production is driven by workstation capacity and
material availability. Each workstation seeks to produce as much as it can, push-
ing finished work forward to the next workstation. In cases where the system is
unconstrained by demand (the demand exceeds system capacity), material can be
pushed without restraint. Usually, however, there is some synchronization of push
with demand. In make-to-stock production, the triggering mechanism is a drop
in finished goods inventory. In make-to-order or assemble-to-order production, a
master production schedule drives production by scheduling through a material
requirements planning (MRP) or other backward or forward scheduling system.
MRP systems determine how much each station should produce for a given
period. Unfortunately, once planned, MRP is not designed to respond to disrup-
tions and breakdowns that occur for that period. Consequently, stations continue
to produce inventory as planned, regardless of whether downstream stations can
absorb the inventory. Push systems such as those resulting from MRP tend to
build up work in process (WIP), creating high inventory-carrying costs and long
flow times.
Pull Control
At the other extreme of a push system is a pull system, in which downstream de-
mand triggers each preceding station to produce a part with no more than one or
two parts at a station at any given time (see Figure 11.6). Pull systems are often
associated with the just-in-time (JIT) or lean manufacturing philosophy, which
advocates the reduction of inventories to a minimum. The basic principle of JIT
is to continuously reduce scrap, lot sizes, inventory, and throughput time as well
as eliminate the waste associated with non–value added activities such as material
handling, storage, machine setup, and rework.
FIGURE 11.6
Push versus pull
Station Station Station
system.
1 2 3
buffer is the inventory needed in front of the bottleneck operation to ensure that
it is never starved for parts. The rope represents the tying or synchronizing of the
production release rate to the rate of the bottleneck operation.
As noted earlier in this chapter, a weakness in constraint-based management
is the inability to predict the level of improvement that can be achieved by elimi-
nating a bottleneck. Simulation can provide this evaluative capability missing in
constraint-based management. It can also help detect floating bottlenecks for situa-
tions where the bottleneck changes depending on product mix and production rates.
Simulating DBR control can help determine where bottlenecks are and how much
buffer is needed prior to bottleneck operations to achieve optimum results.
and so forth). The modeler can experiment with different replenishment strategies
and usage policies until the best plan is found that meets the established criteria.
Using simulation modeling over traditional, analytic modeling for inventory
planning provides several benefits (Browne 1994):
• Greater accuracy because actual, observed demand patterns and irregular
inventory replenishments can be modeled.
• Greater flexibility because the model can be tailored to fit the situation
rather than forcing the situation to fit the limitations of an existing model.
• Easier to model because complex formulas that attempt to capture the
entire problem are replaced with simple arithmetic expressions describing
basic cause-and-effect relationships.
• Easier to understand because demand patterns and usage conditions are
more descriptive of how the inventory control system actually works.
Results reflect information similar to what would be observed from
operating the actual inventory control system.
• More informative output that shows the dynamics of inventory conditions
over time and provides a summary of supply, demand, and shortages.
• More suitable for management because it provides “what if ” capability so
alternative scenarios can be evaluated and compared. Charts and graphs
are provided that management can readily understand.
Rule Definition
Shortest processing time Select the job having the least processing time.
Earliest due date Select the job that is due the soonest.
First-come, first-served Select the job that has been waiting the longest for this
workstation.
First-in-system, first-served Select the job that has been in the shop the longest.
Slack per remaining operations Select the job with the smallest ratio of slack to operations
remaining to be performed.
11.5.9 Emulation
A special use of simulation in manufacturing, particularly in automated systems,
has been in the area of hardware emulation. As an emulator, simulation takes
inputs from the actual control system (such as programmable controllers or mi-
crocomputers), mimics the behavior that would take place in the actual system,
and then provides feedback signals to the control system. The feedback signals
are synthetically created rather than coming from the actual hardware devices.
In using simulation for hardware emulation, the control system is essentially
plugged into the model instead of the actual system. The hardware devices are
then emulated in the simulation model. In this way simulation is used to test,
debug, and even refine the actual control system before any or all of the hardware
has been installed. Emulation can significantly reduce the time to start up new
systems and implement changes to automation.
Emulation has the same real-time requirements as when simulation is used
for real-time control. The simulation clock must be synchronized with the real
clock to mimic actual machining and move times.
unload times can be tacked onto the operation time. A precaution here
is in semiautomatic machines where an operator is required to load and/
or unload the machine but is not required to operate the machine. If the
operator is nearly always available, or if the load and unload activities are
automated, this may not be a problem.
• Model them as a movement or handling activity. If, as just described, an
operator is required to load and unload the machine but the operator is
not always available, the load and unload activities should be modeled
as a separate move activity to and from the location. To be accurate, the
part should not enter or leave the machine until the operator is available.
In ProModel, this would be defined as a routing from the input buffer
to the machine and then from the machine to the output buffer using the
operator as the movement resource.
FIGURE 11.7
Transfer line system.
Machine Buffer Station
Line
placed directly on the station fixture. In-line transfer machines have a load station
at one end and an unload station at the other end. Some in-line transfer machines
are coupled together to form a transfer line (see Figure 11.7) in which parts are
placed on system pallets. This provides buffering (nonsynchronization) and even
recirculation of pallets if the line is a closed loop.
Another issue is finding the optimum number of pallets in a closed, non-
synchronous pallet system. Such a system is characterized by a fixed number
of pallets that continually recirculate through the system. Obviously, the system
should have enough pallets to at least fill every workstation in the system but not
so many that they fill every position in the line (this would result in a gridlock).
Generally, productivity increases as the number of pallets increases up to a certain
point, beyond which productivity levels off and then actually begins to decrease.
Studies have shown that the optimal point tends to be close to the sum of all of the
workstation positions plus one-half of the buffer pallet positions.
A typical analysis might be to find the necessary buffer sizes to ensure that
the system is unaffected by individual failures at least 95 percent of the time. A
similar study might find the necessary buffer sizes to protect the operation against
the longest tool change time of a downstream operation.
Stations may be modeled individually or collectively, depending on the level
of detail required in the model. Often a series of stations can be modeled as a
single location. Operations in a transfer machine can be modeled as a simple
operation time if an entire machine or block of synchronous stations is modeled
as a single location. Otherwise, the operation time specification is a bit tricky
because it depends on all stations finishing their operation at the same time. One
might initially be inclined simply to assign the time of the slowest operation to
every station. Unfortunately, this does not account for the synchronization of
operations. Usually, synchronization requires a timer to be set up for each station
that represents the operation for all stations. In ProModel this is done by defining
an activated subroutine that increments a global variable representing the cycle
completion after waiting for the cycle time. Entities at each station wait for the
variable to be incremented using a WAIT UNTIL statement.
FIGURE 11.8
Continuous flow
system.
t1 t2 t1 t2
Time Time
t1
Q F * (t2 t1) Q =
∫t2
f dt
(a) (b)
11.7 Summary
In this chapter we focused on the issues and techniques for modeling manufactur-
ing systems. Terminology common to manufacturing systems was presented and
design issues were discussed. Different applications of simulation in manufactur-
ing were described with examples of each. Issues related to modeling each type of
system were explained and suggestions offered on how system elements for each
system type might be represented in a model.
References
Askin, Ronald G., and Charles R. Standridge. Modeling and Analysis of Manufacturing
Systems. New York: John Wiley & Sons, 1993.
Berdine, Robert A. “FMS: Fumbled Manufacturing Startups?” Manufacturing Engineer-
ing, July 1993, p. 104.
Bevans, J. P. “First, Choose an FMS Simulator.” American Machinist, May 1982,
pp. 144–45.
Blackburn, J., and R. Millen. “Perspectives on Flexibility in Manufacturing: Hardware
versus Software.” In Modelling and Design of Flexible Manufacturing Systems, ed.
Andrew Kusiak, pp. 99–109. Amsterdam: Elsevier, 1986.
Suzaki, Kiyoshi. The New Manufacturing Challenge: Techniques for Continuous Improve-
ment. New York: Free Press, 1987.
Wang, Hunglin, and Hsu Pin Wang. “Determining the Number of Kanbans: A Step Toward
Non-Stock Production.” International Journal of Production Research 28, no. 11 (1990),
pp. 2101–15.
Wick, C. “Advances in Machining Centers.” Manufacturing Engineering,October 1987,
p. 24.
Zisk, B. “Flexibility Is Key to Automated Material Transport System for Manufacturing
Cells.” Industrial Engineering, November 1983, p. 60.
12 MODELING MATERIAL
HANDLING SYSTEMS
“Small changes can produce big results, but the areas of highest leverage are
often the least obvious.”
—Peter Senge
12.1 Introduction
Material handling systems utilize resources to move entities from one location to
another. While material handling systems are not uncommon in service systems,
they are found mainly in manufacturing systems. Apple (1977) notes that mate-
rial handling can account for up to 80 percent of production activity. On average,
50 percent of a company’s operation costs are material handling costs (Meyers
1993). Given the impact of material handling on productivity and operation costs,
the importance of making the right material handling decisions should be clear.
This chapter examines simulation techniques for modeling material handling
systems. Material handling systems represent one of the most complicated fac-
tors, yet, in many instances, the most important element, in a simulation model.
Conveyor systems and automatic guided vehicle systems often constitute the
backbone of the material flow process. Because a basic knowledge of material
handling technologies and decision variables is essential to modeling material
handling systems, we will briefly describe the operating characteristics of each
type of material handling system.
323
systems are traditionally classified into one of the following categories (Tompkins
et al. 1996):
1. Conveyors.
2. Industrial vehicles.
3. Automated storage/retrieval systems.
4. Carousels.
5. Automatic guided vehicle systems.
6. Cranes and hoists.
7. Robots.
Missing from this list is “hand carrying,” which still is practiced widely if for no
other purpose than to load and unload machines.
12.4 Conveyors
A conveyor is a track, rail, chain, belt, or some other device that provides continu-
ous movement of loads over a fixed path. Conveyors are generally used for high-
volume movement over short to medium distances. Some overhead or towline
systems move material over longer distances. Overhead systems most often move
parts individually on carriers, especially if the parts are large. Floor-mounted con-
veyors usually move multiple items at a time in a box or container. Conveyor speeds
generally range from 20 to 80 feet per minute, with high-speed sortation conveyors
reaching speeds of up to 500 fpm in general merchandising operations.
Conveyors may be either gravity or powered conveyors. Gravity conveyors
are easily modeled as queues because that is their principal function. The more
challenging conveyors to model are powered conveyors, which come in a variety
of types.
Belt Conveyors. Belt conveyors have a circulating belt on which loads are car-
ried. Because loads move on a common span of fabric, if the conveyor stops, all
loads must stop. Belt conveyors are often used for simple load transport.
Roller Conveyors. Some roller conveyors utilize rollers that may be “dead”
if the bed is placed on a grade to enable the effect of gravity on the load to actuate
the rollers. However, many roller conveyors utilize “live” or powered rollers to
convey loads. Roller conveyors are often used for simple load accumulation.
Chain Conveyors. Chain conveyors are much like a belt conveyor in that one
or more circulating chains convey loads. Chain conveyors are sometimes used
in combination with roller conveyors to provide right-angle transfers for heavy
loads. A pop-up section allows the chains running in one direction to “comb”
through the rollers running in a perpendicular direction.
suited for applications where precise handling is unimportant. Tow carts are rela-
tively inexpensive compared to powered vehicles; consequently, many of them
can be added to a system to increase throughput and be used for accumulation.
An underfloor towline uses a tow chain in a trough under the floor. The
chain moves continuously, and cart movement is controlled by extending a drive
pin from the cart down into the chain. At specific points along the guideway,
computer-operated stopping mechanisms raise the drive pins to halt cart move-
ment. One advantage of this system is that it can provide some automatic buffering
with stationary carts along the track.
Towline systems operate much like power-and-free systems, and, in fact,
some towline systems are simply power-and-free systems that have been inverted.
By using the floor to support the weight, heavier loads can be transported.
Load Transport. A conveyor spans the distance of travel along which loads
move continuously, while other systems consist of mobile devices that move one
or more loads as a batch move.
Capacity. The capacity of a conveyor is determined by the speed and load spac-
ing rather than by having a stated capacity. Specifically, it is a function of the
minimum allowable interload spacing (which is the length of a queue position in
the case of accumulation conveyors) and the length of the conveyor. In practice,
however, this may never be reached because the conveyor speed may be so fast
that loads are unable to transfer onto the conveyor at the minimum allowable
spacing. Furthermore, intentional control may be imposed on the number of loads
that are permitted on a particular conveyor section.
Entity Pickup and Delivery. Conveyors usually don’t pick up and drop off
loads, as in the case of lift trucks, pallet jacks, or hand carrying, but rather loads
are typically placed onto and removed from conveyors. Putting a load onto an
input spur of a branching conveyor and identifying the load to the system so it can
enter the conveyor system is commonly referred to as load induction (the spur is
called an induction conveyor).
multidepth or deep lane storage systems are used. AS/RSs that use pallet storage
racks are usually referred to as unit-load systems, while bin storage rack systems
are known as miniload systems.
The throughput capacity of an AS/RS is a function of the rack configuration
and speed of the S/R machine. Throughput is measured in terms of how many
single or dual cycles can be performed per hour. A single cycle is measured as the
average time required to pick up a load at the pickup station, store the load in a
rack location, and return to the pickup station. A dual cycle is the time required
to pick up a load at the input station, store the load in a rack location, retrieve a
load from another rack location, and deliver the load to the output station. Obvi-
ously, there is considerable variation in cycle times due to the number of different
possible rack locations that can be accessed. If the AS/RS is a stand-alone system
with no critical interface with another system, average times are adequate for
designing the system. If, however, the system interfaces with other systems such
as front-end or remote-picking stations, it is important to take into account the
variability in cycle times.
locations, making the cycle time extremely difficult to calculate. The problem is
further compounded by mixed single (pickup and store or retrieve and deposit)
and dual (pickup, storage, retrieval, and deposit) cycles. Activity zoning, in which
items are stored in assigned zones based on frequency of use, also complicates
cycle time calculations. The easiest way to accurately determine the cycle time
for an AS/RS is by using a computer to enumerate the possible movements of the
S/R machine from the pickup and delivery (P&D) stand to every rack or bin loca-
tion. This produces an empirical distribution for the single cycle time. For dual
cycle times, an intermediate cycle time—the time to go from any location to any
other location—must be determined. For a rack 10 tiers high and 40 bays long,
this can be 400 400, or 160,000 calculations! Because of the many calculations,
sometimes a large sample size is used to develop the distribution. Most suppliers
of automated storage/retrieval systems have computer programs for calculating
cycle times that can be generated based on a defined configuration in a matter
of minutes.
Where picking takes place is an important issue achieving the highest pro-
ductivity from both AS/RS and picker. Both are expensive resources, and it is
undesirable to have either one waiting on the other.
12.7 Carousels
One class of storage and retrieval systems is a carousel. Carousels are essentially
moving racks that bring the material to the retriever (operator or robot) rather than
sending a retriever to the rack location.
response times, carousels may have capacity considerations. The current contents
may even affect response time, especially if the carousel is used to store multiple
bins of the same item such as WIP storage. Unlike large AS/RSs, storage capacity
may be an important issue in modeling carousel systems.
In zone blocking, the guide path is divided into various zones (segments) that
allow no more than one vehicle at a time. Zones can be set up using a variety of
different sensing and communication techniques. When one vehicle enters a zone,
other vehicles are prevented from entering until the current vehicle occupying the
zone leaves. Once the vehicle leaves, any vehicle waiting for access to the freed
zone can resume travel.
I J
Distanceij
Total vehicle minutes 2 __________ Pickupi Depositj
i1 j1 Avg. speedij
Deliveriesij
The expression
Distanceij
2 __________
Avg. speedij
implies that the time required to travel to the point of pickup (empty travel time)
is the same as the time required to travel to the point of deposit (full travel time).
This assumption provides only an estimate of the time required to travel to a point
of pickup because it is uncertain where a vehicle will be coming from. In most
cases, this should be a conservative estimate because (1) vehicles usually follow a
work search routine in which the closest loads are picked up first and (2) vehicles
frequently travel faster when empty than when full. A more accurate way of cal-
culating empty load travel for complex systems is to use a compound weighted-
averaging technique that considers all possible empty moves together with their
probabilities (Fitzgerald 1985).
AGV Selection Rules. When a load is ready to be moved by an AGV and more
than one AGV is available for executing the move, a decision must be made as
to which vehicle to use. The most common selection rule is a “closest rule” in
which the nearest available vehicle is selected. This rule is intended to minimize
empty vehicle travel time as well as to minimize the part waiting time. Other
less frequently used vehicle selection rules include longest idle vehicle and least
utilized vehicle.
Work Search Rules. If a vehicle becomes available and two or more parts are
waiting to be moved, a decision must be made as to which part should be moved
first. A number of rules are used to make this decision, each of which can be effec-
tive depending on the production objective. Common rules used for dispatching
an available vehicle include
• Longest-waiting load.
• Closest waiting load.
• Highest-priority load.
• Most loads waiting at a location.
Vehicle Parking Rules. If a transporter delivers a part and no other parts are
waiting for pickup, a decision must be made relative to the deployment of the
transporter. For example, the vehicle can remain where it is, or it can be sent to
a more strategic location where it is likely to be needed next. If several transport
vehicles are idle, it may be desirable to have a prioritized list for a vehicle to
follow for alternative parking preferences.
• Response time.
• Percentage of time blocked by another crane.
Decision variables that become the basis for experimentation include
• Work search rules.
• Park search rules.
• Multiple-crane priority rules.
Typical questions addressed in a simulation model involving cranes include
• Which task assignment rules maximize crane utilization?
• What idle crane parking strategy minimizes response time?
• How much time are cranes blocked in a multicrane system?
12.10 Robots
Robots are programmable, multifunctional manipulators used for handling material
or manipulating a tool such as a welder to process material. Robots are often clas-
sified based on the type of coordinate system on which they are based: cylindrical,
cartesian, or revolute. The choice of robot coordinate system depends on the ap-
plication. Cylindrical or polar coordinate robots are generally more appropriate for
machine loading. Cartesian coordinate robots are easier to equip with tactile sen-
sors for assembly work. Revolute or anthropomorphic coordinate robots have the
most degrees of freedom (freedom of movement) and are especially suited for use
as a processing tool, such as for welding or painting. Because cartesian or gantry
robots can be modeled easily as cranes, our discussion will focus on cylindrical
and revolute robots. When used for handling, cylindrical or revolute robots are
generally used to handle a medium level of movement activity over very short dis-
tances, usually to perform pick-and-place or load/unload functions. Robots gener-
ally move parts individually rather than in a consolidated load.
One of the applications of simulation is in designing the cell control logic for
a robotic work cell. A robotic work cell may be a machining, assembly, inspec-
tion, or a combination cell. Robotic cells are characterized by a robot with 3 to
5 degrees of freedom surrounded by workstations. The workstation is fed parts
by an input conveyor or other accumulation device, and parts exit from the cell
on a similar device. Each workstation usually has one or more buffer positions to
which parts are brought if the workstation is busy. Like all cellular manufacturing,
a robotic cell usually handles more than one part type, and each part type may not
have to be routed through the same sequence of workstations. In addition to part
handling, the robot may be required to handle tooling or fixtures.
12.11 Summary
Material handling systems can be one of the most difficult elements to model
using simulation simply because of the sheer complexity. At the same time, the
material handling system is often the critical element in the smooth operation of
a manufacturing or warehousing system. The material handling system should be
designed first using estimates of resource requirements and operating parameters
(speed, move capacity, and so forth). Simulation can then help verify design deci-
sions and fine-tune the design.
In modeling material handling systems, it is advisable to simplify wherever
possible so models don’t become too complex. A major challenge in modeling
conveyor systems comes when multiple merging and branching occur. A chal-
lenging issue in modeling discrete part movement devices, such as AGVs, is how
to manage their deployment in order to get maximum utilization and meet produc-
tion goals.
References
Apple, J. M. Plant Layout and Material Handling. 3rd ed. N.Y.: Ronald Press, 1977.
Askin, Ronald G., and C. R. Standridge. Modeling and Analysis of Manufacturing Systems.
New York: John Wiley & Sons, 1993.
“Automatic Monorail Systems.” Material Handling Engineering, May 1988, p. 95.
Bozer, Y. A., and J. A. White. “Travel-Time Models for Automated Storage/Retrieval
Systems.” IIE Transactions 16, no. 4 (1984), pp. 329–38.
Fitzgerald, K. R. “How to Estimate the Number of AGVs You Need.” Modern Materials
Handling, October 1985, p. 79.
Henriksen, J., and T. Schriber. “Simplified Approaches to Modeling Accumulation and
Non-Accumulating Conveyor Systems.” In Proceedings of the 1986 Winter Simula-
tion Conference, ed. J. Wilson, J. Henricksen, and S. Roberts. Piscataway, NJ: Insti-
tute of Electrical and Electronics Engineers, 1986.
Matthew, Stephens, and Fred E. Meyers. Manufacturing Facilities Design and Material
Handling. 4th ed. Englewood Cliffs, NJ: Prentice Hall, 2009.
Meyers, Fred E. Plant Layout and Material Handling. Englewood Cliffs, NJ: Regents/
Prentice Hall, 1993.
Pritsker, A. A. B. Introduction to Simulation and Slam II. West Lafayette, IN: Systems
Publishing Corporation, 1986, p. 600.
Tompkins, J. A.; J. A. White; Y. A. Bozer; E. H. Frazelle; J. M. A. Tanchoco; and J. Trevino.
Facilities Planning. 2nd ed. New York: John Wiley & Sons, 1996.
Zisk, B. “Flexibility Is Key to Automated Material Transport System for Manufacturing
Cells.” Industrial Engineering, November 1983, p. 60.
13 MODELING SERVICE
SYSTEMS
“No matter which line you move to, the other line always moves faster.”
—Unknown
13.1 Introduction
A service system is a processing system in which one or more services are pro-
vided to customers. Entities (customers, patients, paperwork) are routed through
a series of processing areas (check-in, order, service, payment) where resources
(service agents, doctors, cashiers) provide some service. Service systems exhibit
unique characteristics that are not found in manufacturing systems. Sasser, Olsen,
and Wyckoff (1978) identify four distinct characteristics of services that distin-
guish them from products that are manufactured:
1. Services are intangible; they are not things.
2. Services are perishable; they cannot be inventoried.
3. Services provide heterogeneous output; output is varied.
4. Services involve simultaneous production and consumption; the service
is produced and used at the same time.
These characteristics pose great challenges for service system design and man-
agement, particularly in the areas of process design and staffing. Having dis-
cussed general modeling procedures common to both manufacturing and service
system simulation in Chapter 6, and specific modeling procedures unique to
manufacturing systems in Chapter 11, in this chapter we discuss design and
operating considerations that are more specific to service systems. A description
is given of major classes of service systems. To provide an idea of how simula-
tion might be performed in a service industry, a call center simulation example
is presented.
345
be a powerful strategic and competitive weapon. Here are some typical internal
performance measures that can be evaluated using simulation:
• Service time.
• Waiting time.
• Queue lengths.
• Resource utilization.
• Service level (the percentage of customers who can be promptly serviced,
without any waiting).
• Abandonment rate (the percentage of impatient customers who leave the
system).
This entire realm of support processes presents a major area of potential ap-
plication for simulation. Similar to the problem of dealing with excess inven-
tory in manufacturing systems, customers, paperwork, and information often
sit idle in service systems while waiting to be processed. In fact, the total wait-
ing time for entities in service processes often exceeds 90 percent of the total
flow time.
The types of questions that simulation helps answer in service systems
can be categorized as being either design related or management related. Here
are some typical design and management decisions that can be addressed by
simulation:
Design Decisions
1. How much capacity should be provided in service and waiting areas?
2. What is the maximum throughput capability of the service system?
3. What are the equipment requirements to meet service demand?
4. How long does it take to service a customer?
5. How long do customers have to wait before being serviced?
6. Where should the service and waiting areas be located?
7. How can work flow and customer flow be streamlined?
8. What effect would information technology have on reducing non-
value-added time?
Management Decisions
1. What is the best way to schedule personnel?
2. What is the best way to schedule appointments for customers?
3. What is the best way to schedule carriers or vehicles in transportation
systems?
4. How should specific jobs be prioritized?
5. What is the best way to deal with emergency situations when a needed
resource is unavailable?
Because service systems are nearly always in a state of transition, going from
one activity level to another during different periods of the day or week, they
rarely reach a steady state. Consequently, we are frequently interested in analyz-
ing the transient behavior of service systems. Questions such as “How long is the
transient cycle?” or “How many replications should be run?” become very impor-
tant. Overall performance measures may not be as useful as the performance for
each particular period of the transient cycle. An example where this is true is in
the analysis of resource utilization statistics. In the types of service systems where
arrival patterns and staff schedules fluctuate over the activity cycle (such as by
day or week), the average utilization for the entire cycle is almost meaningless. It
is much more informative to look at the resource utilization for each period of the
activity cycle.
Most design and management decisions in service systems involve answer-
ing questions based on transient system conditions, so it is important that the
results of the simulation measure transient behavior. Multiple replications should
be run, with statistics gathered and analyzed for different periods of the transient
cycle. In an attempt to simplify a simulation model, sometimes there is a tempta-
tion to model only the peak period, which is often the period of greatest interest.
What is overlooked is the fact that the state of the system prior to each period and
the length of each period significantly impact the performance measures for any
particular period, including the peak period.
of the greatest changes in the methods used in service industries have come about
as a result of advances in information technology. Routine banking is being re-
placed by automated teller machines (ATMs). Shopping is being conducted over
the Internet. Electronic document management systems are replacing paper docu-
ment processing. Processing of orders and other documents that previously took
weeks now takes only days or hours.
Automation of service processes presents challenges similar to the automa-
tion of manufacturing processes. If automating a service process speeds up a
particular activity but does not minimize the overall processing time, it is not
effective and may even be creating waste (such as large pools of waiting entities).
After running the simulation, waiting times, abandonment counts, and resource
utilization rates can be evaluated to determine if the optimum conditions have been
achieved. If results are unacceptable, either the incoming pattern, the service force, or
the servicing policies and procedures can be modified to run additional experiments.
costs are low while equipment and facility costs are high. Service factories usu-
ally have both front-room and back-room activities with total service being pro-
vided in a matter of minutes. Customization is done by selecting from a menu of
options previously defined by the provider. Waiting time and service time are two
primary factors in selecting the provider. Convenience of location is another im-
portant consideration. Customer commitment to the provider is low because there
are usually alternative providers just as conveniently located.
Examples include banks (branch operations), restaurants, copy centers, bar-
bers, check-in counters of airlines, hotels, and car rental agencies.
has obtained the merchandise, he or she must get in line for the checkout process.
For large items such as furniture or appliances, the customer may have to order and
pay for the merchandise first. The delivery of the product may take place later.
Examples include department stores, grocery stores, hardware stores, and
convenience stores.
process, then the service time is short. If the service is a technical support process,
then the service time may be long or the call may require a callback after some
research.
Examples include technical support services (hotlines) for software or hard-
ware, mail-order services, and airline and hotel reservations.
13.7.1 Background
Society Bank’s Information Technology and Operations (ITO) group offers
a “help desk” service to customers of the ITO function. This service is offered
to both internal and external customers, handling over 12,000 calls per month.
The client services help desk provides technical support and information on a
variety of technical topics including resetting passwords, ordering PC equipment,
requesting phone installation, ordering extra copies of internal reports, and report-
ing mainframe and network problems. The help desk acts as the primary source of
communication between ITO and its customers. It interacts with authority groups
within ITO by providing work and support when requested by a customer.
The old client services help desk process consisted of (1) a mainframe help
desk, (2) a phone/local area network help desk, and (3) a PC help desk. Each of
the three operated separately with separate phone numbers, operators, and facili-
ties. All calls were received by their respective help desk operators, who manually
logged all information about the problem and the customer, and then proceeded to
pass the problem on to an authority group or expert for resolution.
Because of acquisitions, the increased use of information technologies, and the
passing of time, Society’s help desk process had become fragmented and layered
with bureaucracy. This made the help desk a good candidate for a process redesign.
It was determined that the current operation did not have a set of clearly defined
goals, other than to provide a help desk service. The organizational boundaries of
the current process were often obscured by the fact that much of the different help
desks’ work overlapped and was consistently being handed off. There were no pro-
cess performance measures in the old process, only measures of call volume. A pro-
posal was made to consolidate the help desk functions. The proposal also called for
the introduction of automation to enhance the speed and accuracy of the services.
call level. Level 1 calls are resolved immediately by the help desk, Level 1A calls
are resolved later by the help desk, and Level 2 calls are handed off to an authority
group for resolution.
Historically, calls averaged 2.5 minutes, lasting anywhere from 30 seconds
to 25 minutes. Periodically, follow-up work is required after calls that ranges
from 1 to 10 minutes. Overall, the help desk service abandonment rate was 4 to
12 percent (as measured by the percentage of calls abandoned), depending on
staffing levels.
The help desk process was broken down into its individual work steps and
owners of each work step were identified. Then a flowchart that described the
process was developed (Figure 13.1). From the flowchart, a computer simulation
model was developed of the old operation, which was validated by comparing ac-
tual performance of the help desk with that of the simulation’s output. During the
10-day test period, the simulation model produced results consistent with those
of the actual performance. The user of the model was able to define such model
parameters as daily call volume and staffing levels through the use of the model’s
Interact Box, which provided sensitivity analysis.
Joint requirements planning (JRP) sessions allowed the project team to col-
lect information about likes, dislikes, needs, and improvement suggestions from
users, customers, and executives. This information clarified the target goals of
the process along with its operational scope. Suggestions were collected and
prioritized from the JRP sessions for improving the help desk process. Internal
benchmarking was also performed using Society’s customer service help desk as
a reference for performance and operational ideas.
FIGURE 13.1
Customer problem, Client notification
Flow diagram of query, or change and escalation
client services.
Customer self-service
Automated resolution
will change when the average daily call volume or the number of operators varies.
The importance of this graph is realized when one notices that it becomes in-
creasingly harder to lower the abandonment rate once the number of operators
increases above seven. Above this point, the help desk can easily handle substan-
tial increases in average daily call volume while maintaining approximately the
same abandonment rate.
After modeling and analyzing the current process, the project team evaluated
the following operational alternatives using the simulation model:
• The option to select from a number of different shift schedules so that
staffing can easily be varied from current levels.
• The introduction of the automated voice response unit and its ability to
both receive and place calls automatically.
• The ability of the automated voice response unit to handle device resets,
password resets, and system inquiries.
• The incorporation of the PC and LAN help desks so that clients with PC-
related problems can have their calls routed directly to an available expert
via the automated voice response unit.
• The ability to change the response time of the ASIM problem-logging
system.
Additionally, two alternative staffing schedules were proposed. The alterna-
tive schedules attempt to better match the time at which operators are available
for answering calls to the time the calls are arriving. The two alternative schedules
reduce effort hours by up to 8 percent while maintaining current service levels.
Additional results related to the Alternative Operations simulation model were
• The automated voice response unit will permit approximately 75 percent
of PC-related calls to be answered immediately by a PC expert directly.
• Using Figure 13.2, the automated voice response unit’s ability to aid in
reducing the abandonment rate can be ascertained simply by estimating
the reduction in the number of calls routed to help desk operators and
finding the appropriate point on the chart for a given number of operators.
• Improving the response time of ASIM will noticeably affect the operation
when staffing levels are low and call volumes are high. For example,
with five operators on staff and average call volume of 650 calls per day,
a 25 percent improvement in the response time of ASIM resulted in a
reduction in the abandonment rate of approximately 2 percent.
13.7.3 Results
The nonlinear relationship between the abandonment rate and the number of op-
erators on duty (see Figure 13.2) indicates the difficulty in greatly improving per-
formance once the abandonment rate drops below 5 percent. Results generated
from the validated simulation model compare the impact of the proposed staffing
changes with that of the current staffing levels. In addition, the analysis of the
effect of the automated voice response unit can be predicted before implementa-
tion so that the best alternative can be identified.
The introduction of simulation to help desk operations has shown that it can
be a powerful and effective management tool that should be utilized to better
achieve operational goals and to understand the impact of changes. As the auto-
mation project continues to be implemented, the simulation model can greatly
aid management and the project team members by allowing them to intelligently
predict how each new phase will affect the help desk.
13.8 Summary
Service systems provide a unique challenge in simulation modeling, largely
due to the human element involved. Service systems have a high human con-
tent in the process. The customer is often involved in the process and, in many
cases, is the actual entity being processed. In this chapter we discussed the aspects
that should be considered when modeling service systems and suggested ways in
which different situations might be modeled. We also discussed the different types
of service systems and addressed the modeling issues associated with each. The
example case study showed how fluid service systems can be.
References
Aran, M. M., and K. Kang. “Design of a Fast Food Restaurant Simulation Model.” Simula-
tion. Norcross, GA: Industrial Engineering and Management Press, 1987.
Collier, D. A. The Service/Quality Solution. Milwaukee: ASQC Quality Press, 1994.
II LABS
1 INTRODUCTION TO
PROMODEL
Imagination is the beginning of creation. You imagine what you desire, you will
what you imagine and at last you create what you will.
—George Bernard Shaw
365
FIGURE L1.1
The ProModel
Shortcut Panel
(student package).
the menu bar (ProModel User’s Guide Chapter 4). The menu bar is located right
below the caption bar and contains the menu items described below.
1. File Menu allows the user to open a new model, open an existing model,
merge two or more submodels into one, save the current model, and
import models created in earlier versions of ProModel.
2. Edit Menu contains selections for editing the contents of edit tables
and logic windows. Importantly, data elements created when building a
model can only be deleted through the edit menu.
3. View Menu contains selections for setting up the model viewing
environment.
4. Build Menu consists of all of the modules for creating and editing a
model, which include the following basic and optional modules:
Basic Modules: Locations, Entities, Processing, and Arrivals.
Optional Modules: Path Networks, Resources, Shifts, Cost, Attributes,
Variables, Arrays, Macros, Subroutines Arrival Cycles, Table Functions,
User Distributions, External Files, and Streams.
5. Simulation Menu controls the execution of a simulation and contains
options for running a model, defining model parameters, and defining
and running scenarios.
6. Output Menu starts the ProModel Output Viewer for viewing model
statistics.
7. Tools Menu contains various utilities as follows:
a. Expression Search
b. Graphic Editor
c. Stat::Fit
d. 3D Animator
e. License Manager
f. Options
g. Customize
8. Window Menu allows you to arrange the windows (or iconized
window) that are currently displayed on the screen so that all windows
are visible at once.
9. Help Menu accesses the ProModel Online Help System.
For more detailed information on the items in the ProModel menu bar, please
refer to the ProModel User’s Guide.
are available in the toolbar space. These toolbars are listed below with short
descriptions for each.
1. File starts a new model, opens a previously saved model, saves an open
model, creates and installs model package.
2. Layout is used to show grids the layout, show hidden path networks, and
make routing paths visible.
3. View is used to define and access specific areas of the layout and
zooming the layout. It is also useful for resetting the window positions
back to a neatly tiled arrangement if moving them around has disheveled
them.
4. Build Basic is used to open basic build modules.
5. Build Advanced is used to open advanced build modules.
6. Simulation opens simulation options and scenarios dialog, plays, pauses,
and stops simulation, toggles animation on/off, and opens output viewer.
7. Simulation Information is used to access location, variable, and array
information. It is also used to define and view dynamic plots.
8. Debug allows the user to pause simulation, trace of filter the steps, and
open the debug dialog box.
9. Tools open the graphic editor, SimRunner, Stat::Fit, and 3D Animator.
For more detailed information on the items in the ProModel tool bar, please refer
to the ProModel User’s Guide.
FIGURE L1.2
Run-time Menus and Controls.
FIGURE L1.3
California Cellular
with one customer
service agent.
FIGURE L1.4
Customer waiting
time statistics with
one customer service
associate.
FIGURE L1.5
California Cellular
with two customer
service associates.
FIGURE L1.6
Customer waiting
time statistics with
two customer service
associates.
FIGURE L1.7
Number of calls waiting with one customer service agent.
If we have two CSAs (Figure L1.5), we would like to figure out what the av-
erage wait would be. The average wait drops down to 5.9 minutes (Figure L1.6),
which is clearly a much more acceptable result. Hence the decision recommended
to management will be to hire two CSAs.
With two CSAs working together, the results obtained are shown in Fig-
ure L1.8. The maximum number of customers waiting is 5. When we graph
the number of incoming calls waiting for the duration of the simulation run of
500 hours (Figure L1.9), there were only three occasions of as many as five
calls waiting. Hence, we recommend to management to have two CSAs working
together.
FIGURE L1.8
Number of calls waiting with two customer service agents.
FIGURE L1.9
Graph of number of customers waiting during the simulation run time.
Problem Statement
Customers arrive to use an ATM at an average interarrival time of 3.0 minutes
exponentially distributed. When customers arrive to the system, they join a queue
to wait for their turn on the ATM. The queue has the capacity to hold an infinite
number of customers. Customers spend an average of 2.4 minutes, exponentially
distributed, at the ATM to complete their transactions, which is called the service
time of the ATM.
The objective is to simulate the system to determine the expected waiting
time for customers in the queue (the average time customers wait in line for the
ATM) and the expected time in the system (the average time customers wait in
the queue plus the average time it takes them to complete their transaction at the
ATM).
This is the same ATM system simulated by spreadsheet in Chapter 3
but with a different objective. In Chapter 3 the objective is to simulate only
the first 25 customers arriving to the system. Here no such restriction is ap-
plied. This new objective provides an opportunity for comparing the simu-
lated results with those computed using queuing theory, which is presented in
Chapter 2.
Queuing theory allows us to compute the exact values for the expected time
that customers wait in the queue and in the system. Given that queuing theory can
be used to get exact answers, why are we using simulation to estimate the two
expected values? There are two parts to the answer. First, it gives us an opportu-
nity to verify the simulation model by comparing the simulation output with the
exact results produced using queuing theory. Second, most systems of interest are
too complex to be modeled with the mathematical equations of queuing theory.
In those cases, good estimates from simulation are valuable commodities when
faced with expensive decisions.
time, the system will begin to reach steady state, which means that the statistical
distributions that describe the output of the system stabilize. The steady state topic
is covered in detail in Chapter 8.
Using the queuing theory equations from Chapter 2, the expected time cus-
tomers wait in queue is 9.6 minutes and the expected amount of time customers
spend in the system is 12.0 minutes. Now, let’s use ProModel simulation to esti-
mate these values.
FIGURE L1.10
ATM system simulation
model.
FIGURE L1.11
Displaying a message after the 25th customer has been processed.
FIGURE L1.12
Displaying a message after the 150,000th customer has been processed.
expected values of 9.6 minutes in the queue and 12.0 minutes in the system
computed using queuing theory. You can get closer to the exact values, if needed.
Lab 8 discusses how to achieve a desired level of accuracy.
ProModel displays a prompt at the end of the simulation asking if you want
to collect statistics; select “No” for now (Figure L1.14). ProModel automatically
collects a multitude of statistics over the course of the simulation. You will learn
this feature in Lab 3.
The simulation required only a minute of your time to process 19,496
customers. In Lab 2, you will begin to see how easy it is to build models using
ProModel as compared to building them with spreadsheets.
FIGURE L1.13
Displaying the simulation results.
FIGURE L1.14
ProModel prompt at
the end of a simulation
run.
L1.6 Exercises
1. How do you open an existing simulation model?
2. What is SimRunner? How can you use it in your simulation analysis?
3. What does the Stat::Fit package do? Do you need it when building a
simulation model?
4. At the most, how many locations, entities, and types of resources can be
modeled using the student version of ProModel?
5. Open the Manufacturing Cost model from the Demos subdirectory and
run the model three different times to find out whether one, two, or
three operators are optimal for minimizing the cost per part (the
cost per part is displayed on the scoreboard during the simulation).
Selecting Model Parameters, you can change the number of operators
from the Simulation menu by double-clicking on the first parameter
(number of operators) and entering 1, 2, or 3. Then select Run from the
Model Parameters dialog. Each simulation will run for 15 hours.
6. Without knowing how the model was constructed, can you give a
rational explanation for the number of operators that resulted in the
least cost?
7. Go to the ProModel Web site on the Internet (www.promodel.com).
What are some of the successful real-world applications where
ProModel was used? What other applications are ProModel products
used for besides manufacturing?
8. Identify the ProModel menu where you will find the following items:
a. Save As
b. Delete
c. View Trace
d. Shifts
e. Index
f. General Information
g. Options
h. Printer Setup
i. Processing
j. Scenarios
k. Tile
l. Zoom
9. Which of the following is not a valid ProModel menu or submenu
item?
a. AutoBuild
b. What’s This?
c. Merge
d. Merge Documents
e. Snap to Grid
f. Normal
g. Paste
h. Print Preview
i. View Text
10. Which of the following are valid modeling elements found under the
Build menu?
a. Activities
b. Locations
c. Conveyors
d. Queues
e. Shifts
f. Subroutines
g. Station
h. Server
i. Schedules
j. Arrivals
k. Expressions
l. Variables
m. Create
n. Function
11. What are some of the valid logic statements in the ProModel logic
builder?
12. Describe the functions of the following items in the ProModel Edit
menu:
a. Delete
b. Insert
c. Append
d. Move
e. Move To
f. Copy Record
g. Paste Record
2 BUILDING YOUR
FIRST MODEL
As far as the laws of mathematics refer to reality, they are not certain; and as far
as they are certain, they do not refer to reality.
—Albert Einstein
In this lab we learn to start building simulation models using ProModel. In section
L2.1 we build our first model of a neighborhood barbershop. In section L2.2 we
build an automatic teller machine system model. In section L2.3 we build a model
for a small furniture factory using multiple locations and multiple entities. In sec-
tion L2.4 we add another location to the previous model. Section L2.6 introduces
the concept of blocking an entity. In section L2.7 we discuss the effects of traffic
intensity on the performance of the system.
379
FIGURE L2.2
Defining locations Waiting_for_Dan and BarberDan.
A name or identifier is any combination (up to eighty characters long) of letters, num-
bers, and underscores (“_”), used to identify model elements such as locations, enti-
ties, variables, and functions. Although any valid name can refer to any object, it
is best to use names which describe the object they identify (e.g., using “ClientA”
to describe an entity that represents a client). Names, like all words in ProModel,
are case insensitive, meaning that ProModel sees “PARKING_A,” “Parking_A,” and
“PaRkInG_a” as identical.
Names must use the following conventions:
• Names may contain the letters A through Z (upper or lower case), digits (0–9)
and the underscore “_”. Names may not contain spaces. When opening an older
model, ProModel flags improper use of these restricted characters.
• Do not use a digit as the first character of a name. After the first character, any
character may be a digit. For example, “2Var” is an invalid name, but “V2”, is a
valid name.
• Names may not be keywords, but names may contain keywords. For example,
“For” is an invalid name, but “Forklift” is a valid name. Similarly, “Queue2” and
“OrderQty” are both valid.
• No matter what they identify, every name in a model must be unique. For
example, you cannot name both a location and an entity “Server.” You may,
however, name one “Server1” or “Server_Location” and the other “Server2” or
“Server_Resource.”
Note that the first location is actually a region (it is the icon that looks like a square
box). A region is a boundary used to represent a location’s area. When the model
is running the region is not visible. Also, note that we changed the capacity of this
location to “infinite.” The icon selected for the second location is actually called
operator. We changed the name to BarberDan in the Name column of the Locations
table.
Uncheck the New checkbox on the Graphics panel (Figure L2.3) and click
the text button marked Aa. Click on the location icon in the Layout panel. The
name of the location (BarberDan) appears on the location icon.
Define the entity (Figure L2.4) and change its name to Customer. Define the
processes and the routings the customers go through at the barbershop. All custom-
ers arrive and wait at the location Waiting_for_Barber. Then they are routed to the
location BarberDan. At this location the barber performs the haircut, which takes an
amount of time uniformly distributed between 8 and 10 minutes or Uniform(9,1).
To create the processing and routing tables graphically we need to do the following:
a. Left-click on the entity name in the toolbar and then left-click on the
desired beginning location.
b. Left-click on the destination location. A processing record is created
(Figure L2.5).
c. To add multiple routing lines to the same record, left-click on the Add
Routing button in the toolbox.
d. To route the part to exit, left-click on the Route to Exit button in the
toolbox.
FIGURE L2.3
The Graphics panel.
FIGURE L2.4
Define the entity—Customer.
FIGURE L2.5
Creating the processing and routing tables.
FIGURE L2.6
Completed process and routing tables for Fantastic Dan.
FIGURE L2.7
Processing and routing tables for Fantastic Dan in text format.
FIGURE L2.8
The Logic Builder
menu.
The completed processing and routing tables are shown in Figure L2.6. A text
version of the same processing and routing tables (Figure L2.7) can be viewed by
going to File View Text.
To define the haircut time, click Operation in the Process table. Click the button
with the hammer symbol (Build). A new window named Logic Builder opens up. Se-
lect the command Wait. The ProModel expression Wait causes the customer (entity)
to be delayed for a specified amount time. This is how processing times are modeled.
Click Build Expression. In the Logic window, select Distribution Function
(Figure L2.8). In the Distribution Function window, select Uniform distribution.
Click Mean and select 9. Click Half-Range and select 1. Click Return. Click
Paste. Close the Logic Builder window. Close the Operation window.
Finally the customers leave the barbershop. They are routed to a default loca-
tion called EXIT in ProModel. When entities (or customers) are routed to the EXIT
location, they are, in effect, disposed from the system. All the information associated
with the disposed entity is deleted from the computer’s memory to conserve space.
The distribution functions are built into ProModel and generate random val-
ues based on the specified distribution. Some of the commonly used distribution
functions are shown in Table L2.1.
Now we will define the location and frequency at which customers enter
the model. Open the Arrivals table and click on the location in the layout called
Waiting_for_Barber. This creates an arrival record as shown in Figure L2.9. In
the frequency column, enter E(10), which is every 10 minutes exponentially
distributed.
Next we will define some of the simulation options—that is, run time,
number of replications, warm-up time, unit of time, and clock precision
(Figure L2.10). Let us select Options from the Simulation menu. The run time
is the number of hours the simulation model will run. The number of replica-
tions refers to the number of times the simulation model will be run using dif-
ferent seed values for the random number generator (each time the model will
run for an amount of time specified by run hours). The warm-up time refers
to the amount of time to let the simulation model run to achieve steady-state
behavior. Statistics are collected after the warm-up period is over. The run time
begins at the end of the warm-up period. The unit of time used in the model can
be seconds, minutes, or hours. The clock precision refers to the precision used
when either calculating or randomly generating times for all simulation event
timings.
FIGURE L2.9
Customer arrival table.
FIGURE L2.10
Definition of
simulation options.
FIGURE L2.11
Screen shot at run time.
Figure L2.11 shows a screen shot during run time. The button in the middle
of the scroll bar at the top controls the speed of the simulation run. Drag it right to
increase the speed and left to decrease the speed.
After the simulation runs to its completion, the user is prompted, “Do you
want to see the results?” (Figure L2.12). Click Yes. Figures L2.13 and L2.14 are
part of the results that are automatically generated by ProModel in the Output
Viewer. To view these tables and charts in a report, simply click on the desired
table or chart in the menu ribbon and drag them into the report space on top of one
of the position spots that appear.
Note that the average time a customer spends waiting for Barber Dan
is 22.95 minutes. The average time spent by a customer in the barbershop is
32.28 minutes. The utilization of the Barber is 89.15 percent. The number of cus-
tomers served in 480 minutes (8 hours) is 47. On average 5.875 customers are
served per hour. The maximum number of customers waiting for a haircut is 8,
although the average number of customers waiting is only 2.3.
FIGURE L2.12
Simulation complete
prompt.
FIGURE L2.13
The Output Viewer
for the Fantastic Dan
model.
FIGURE L2.14
Time Plot of the
number of customers
waiting for Fantastic
Dan.
FIGURE L2.15
General Information
for the Bank of USA
ATM simulation
model.
FIGURE L2.16
Defining locations ATM_Queue and ATM.
From the menu bar select Build Locations. For this model we will define
two locations—ATM_Queue and ATM (Figure L2.16). The icon for the first lo-
cation (a queue) is selected from the graphics panel. The icon (third from top)
originally looks like a “ladder on its side.” To place it in our model layout, first
left-click on the layout where you want the queue to start. Then move the mouse
pointer to the end of the queue and right-click (or double-click). (Hint: to make
the queue exactly horizontal or vertical, hold the shift key down before right-
clicking.) Change the name of this queue location from Loc1 to ATM_Queue.
Now double-click the ATM_Queue icon on the layout. This opens another win-
dow as shown in Figure L2.17. Make sure to click on the Queue option in the
Conveyor/Queue option window. This causes entities to move at their own speed
FIGURE L2.17
Click on the Queue
option in the
Conveyor/Queue
options window.
FIGURE L2.18
Define the entity—Bank of USA ATM_Customer.
FIGURE L2.19
Processing and routing tables for Bank of USA ATM model.
instead of the speed of the conveyor. However, let’s change the length of the
queue to zero feet as we do not want to model the time it takes to travel the length
of the queue (it is insignificant, anyway).
The icon selected for the second location is actually called brake. We changed
its name to ATM in the name column of the Locations table.
Display the names of each location in the Layout window (Figure L2.16),
using the procedure described in section L2.1.
Define the entity (Figure L2.18) and change its name to ATM_Customer.
Define the processes and the routings (Figures L2.19 and L2.20) the customers go
through at the ATM system. All customers arrive and wait at the location ATM_
Queue. Then they are routed to the location ATM. At this location the customers
deposit or withdraw money or check their balances, which take an average of
2.4 minutes exponentially distributed. Use the step-by-step procedure detailed in
section L2.1 to create the process and routing tables graphically.
FIGURE L2.20
Process and Routing tables for Bank of USA ATM model in text format.
FIGURE L2.21
Customer arrival table.
FIGURE L2.22
Definition of
simulation options.
After using the ATM, the customers route to EXIT causing them to leave
the Bank of USA ATM. All the information associated with the disposed entity is
deleted from the computer’s memory to conserve space. Now we will define the
entity arrival process, as shown in Figure L2.21.
Next we will define some of the simulation options following the procedure
outlined in section L2.1. We will set run time to 980 hours (Figure L2.22). The
FIGURE L2.23
Screen shot at run time.
FIGURE L2.24
The Output Viewer for
the Bank of USA ATM
model.
rest of the options are left at their default values. Figure L2.23 shows a screenshot
of the simulation model during run time.
Figures L2.24 and L2.25 are part of the results that are automatically gener-
ated by ProModel in the Output Viewer.
Note that the average time a customer spends waiting in the ATM Queue
is 9.47 minutes. The average time spent by a customer in the ATM system is
11.86 minutes. The utilization of the ATM is 79.35 percent. Also, 19,496 custom-
ers are served in 980 hours or 19.9 customers per hour. The maximum number
of customers waiting in the ATM Queue is 30, although the average number of
customers waiting is only 3.14. This model is an enhancement of the ATM model
in Lab 1, section L1.4.2. Results will not match exactly as some realism has been
added to the model that cannot be addressed in queuing theory.
FIGURE L2.25
Fluctuation in the
number of customers
waiting in the queue
the Bank of USA ATM
simulation model.
FIGURE L2.26
Locations in the USA Furniture Factory.
FIGURE L2.27
Entities in the USA
Furniture Factory.
FIGURE L2.28
Entity arrivals in the USA Furniture Factory.
FIGURE L2.29
Processing and routing tables in the USA Furniture Factory.
FIGURE L2.30
Routing Rule in
the USA Furniture
Factory.
into two pieces. To be able to model this, click on the Rule button in the routing
table. Change the quantity to two (Figure L2.30). This models the process of one
log going into the location splitter saw and two pieces coming out. Pieces are
routed to the lathe, where they are turned into round legs. Round legs are routed
to the paint booth, where they become painted legs. Painted legs are sent to the
painted legs store. Finally, the painted legs are sent to the default location EXIT
for disposal.
The time to move the material between processes is modeled in the Move
Logic field of the Routing table. Four choices of constructs are available in the
Move Logic field:
• MOVE FOR—to move the entity to the next location or in operation
logic, to the end of queue or conveyor, in a specific time.
• MOVE ON—to move the entity to the next location using a specific path
network.
• MOVE WITH—to move the entity to the next location using a specified
resource (forklift, crane). The resource may be freed after the move.
Define some of the simulation options: the simulation run time, the number
of replications, the warm-up time, and the clock precision (Figure L2.31).
Now we go on to the Simulation menu. Select Save & Run. This will save the
model we have built so far, compile it, and also run it. When the simulation model
finishes running, we will be asked if we would like to view the results. Select Yes.
A sample of the results is shown in Figure L2.32.
FIGURE L2.31
Simulation options
in the USA Furniture
Factory.
FIGURE L2.32
Sample of the results
of the simulation run
for the USA Furniture
Factory.
FIGURE L2.33
Locations and layout of the USA Furniture Factory.
FIGURE L2.34
Processing and routing tables at the USA Furniture Factory.
FIGURE L2.35
Customer arrival for haircut at Fantastic Dan.
FIGURE L2.36
Processing of customers at Fantastic Dan.
Average customer time at the barbershop 32.28 min. (Figure L2.13) 9 min.
Average waiting in line for the barber 22.95 min. (Figure L2.13) 0 min.
Average size of the waiting line 2.3 customers 0 customers
Maximum size of the waiting line 8 customers 1 customer
Average number of customers served per hour 5.875 customers/hr. 6 customers/hr.
L2.6 Blocking
With respect to the way statistics are gathered, here are the rules that are used in
ProModel (ProModel Users Manual, Report Data).
1. Average Time in System. The average total time the entity spends in the
system.
2. Average Time in Move Logic. The average time the entity spent
traveling between locations, including any delays incurred in move logic.
3. Average Time Waiting. The average time the entity spent waiting for
a resource or another entity (to join or combine). Also includes time
waiting in queue behind a blocked entity.
4. Average Time in Operation. The average time the entity spent
processing (i.e., WAIT or USE statements) at a location or traveling on a
conveyor/queue.
5. Average Time Blocked. The average time the entity spent waiting for
a destination location to have available capacity. Any entities held up
behind another blocked entity are actually waiting on the blocked entity,
so they are reported as “time waiting for resource, etc.”
FIGURE L2.37
Layout of the Socal
Machine Shop.
FIGURE L2.38
Processing and Routing tables for the Socal Machine Shop.
Example
At the Socal Machine Shop (Figure L2.37) gear blanks arriving to the shop wait in
a queue (Incoming_Q) for processing on a turning center and a mill, in that order.
A total of 100 gear blanks arrive at the rate of one every eight minutes. The pro-
cessing times on the turning center and mill are eight minutes and nine minutes,
respectively. Develop a simulation model and run it.
To figure out the time the “gear blanks” are blocked in the machine shop,
waiting for a processing location, we have entered “Move for 0” in the operation
logic (Figure L2.38) of the location Incoming_Q. Also, the decision rule for the
queue has been changed to “No Queuing” in place of FIFO (Figure L2.39). This
way all the entities waiting in the queue for the turning center to be freed up are
reported as blocked. When you specify FIFO as the queuing rule for a location,
only the lead entity is ever blocked (other entities in the location are waiting for
the lead entity and are reported as “wait for resource, etc.”).
From the entity activity statistics (Figure L4.40) in the output report we can
see the entities spend on average 66.5 minutes in the system, of which 49.5 min-
utes are blocked (waiting for another process location) and 17 minutes are spent in
operation (eight minutes at the turning center and nine minutes at the mill). Block-
ing as a percentage of the average time in system is 74.4 percent. The utilization
of the turning center and the mill are about 98 percent each.
FIGURE L2.39
Decision rules for
Incoming_Q.
FIGURE L2.40
Entity activity statistics at the Socal Machine Shop.
FIGURE L2.41
Entity activity statistics at the Socal Machine Shop with two mills.
Problem Statement
Atithi Restaurant has one drive-through window. The average number of cus-
tomers arriving per hour (exponentially distributed) is variable. The service time
is normally distributed with an average of 5 minutes and a standard deviation of
1 minute. We would like to investigate the effects of customer arrival rate on the
utilization of the server, the time a customer spends in the drive-through facility
of the restaurant (waiting for service and getting served) and also on the conges-
tion of customers in the drive-through facility. Figure L2.42 shows the processing
and routing tables for the simulation model of the drive-through facility of the
Atithi Restaurant. Figure L2.43 shows a snapshot of the simulation model of the
FIGURE L2.42
Processing and Routing tables for Atithi Restaurant model.
FIGURE L2.43
Snapshot of the
Simulation Model
of the drive-through
facility of the Atithi
Restaurant.
drive-through facility of the Atithi Restaurant. Table L2.3 shows the effects of
customer arrival rate on server utilization, time in system, and number of custom-
ers in the system.
As can be seen, as the traffic intensity () exceeds 0.8 (80%) server utiliza-
tion flattens out while the average time in system and the number of customers
in the system grows very rapidly to unacceptable levels. For server utilizations
higher than about 80 percent the time a customer spends in the system grows
to very high (and unacceptable) levels. All this analysis is meant to show that
a very high traffic intensity (or very high server utilization) is not necessarily a
good thing.
L2.8 Exercises
1. For the Atithi Restaurant example in section L2.7, make plots (in
EXCEL) to show the effects of:
a. Increasing traffic intensity (increasing arrival rates for a fixed service
rate) on the server utilization.
b. Increasing traffic intensity on the average time a customer spends in
the drive-through facility.
c. Increasing traffic intensity on the average number of customers in the
drive-through facility.
d. Increasing server utilization on the average time a customer spends in
the system.
What happens when the traffic intensity () exceeds 0.8 (80%)?
2. For the Fantastic Dan example in section L2.1, run the simulation model
for a whole year (250 days, 8 hours each day) and answer the following
questions:
a. On average how many customers does Dan serve each day?
b. What is the average number of customers waiting to get a haircut?
What is the maximum?
c. What is the average time spent by a customer in the salon?
d. What is the utilization of Barber Dan? Is it satisfactory?
e. How many chairs should Dan have for customers waiting for a
haircut? Why?
3. If Dan could take exactly 9 minutes for each haircut will it improve the
situation? Rework question 2 and answer parts a through e.
4. For the SoCal Machine Shop example in section L2.6, run the simulation
model for a whole year of operations (2,500 hours) and respond to the
following:
a. What is the average and maximum number of gear blanks in the
Incoming_Q? Is it satisfactory? Why or why not?
b. What are the utilizations of the Turning Center and the Mill? Are they
satisfactory? Why or why not?
c. What is the average time a gear blank stays in the shop?
d. What is the average time the gear blank is blocked (waiting for
another process location)?
e. How will all these results change when we decide to install a
second mill?
5. In the Arrivals element (Build menu), there are two items—occurrences
and frequency. What are the differences between these two items? What
is the significance of the Qty each column? What is the significance of
the First Time column? When and how can we use it in a simulation
model?
6. What are the various time units that you can use while developing a
model? Where do you provide this information?
7. The Processing element (Build menu) has two tables that need to be
edited. What are their names and their functions? How do we enter
information in those tables? How does the Processing editor work?
8. When an entity has completed all the processing in the system, what
should we do with it? Where should it be routed? Why?
9. Differentiate between the following:
a. Entity vs. Locations
b. Locations vs. Resources
c. Attributes vs. Variables
d. Subroutines vs. Macros
e. Table Functions vs. Arrays
f. Save vs. Save As
10. What are some of the differences between the following logic
statements?
a. Wait vs. Wait Until
b. Move vs. Move For
c. Pause vs. Stop
d. Accum vs. Group
e. End vs. Stop
f. Do Until vs. Do While
g. Inc vs. Int
11. Describe the differences between the following items in the ProModel
View menu:
a. Zoom vs. Zoom to Fit Layout
b. Show Grid vs. Snap to Grid
3 PROMODEL’S OUTPUT
VIEWER
In this lab we introduce you to the Output Viewer in ProModel. Section L3.1 de-
scribes the various menus in the Output Viewer. In sections L3.2 and L3.3 we de-
scribe the various tables and charts for comparing table information for particular
columns. In sections L3.4 and L3.5 we describe utilization and state charts. Sec-
tion L3.6 presents the different time-series charts available in the Output Viewer.
Section L3.7 is an introduction to the dynamic plots that can be displayed and
updated dynamically during simulation run time.
405
FIGURE L3.1
Output menu options
in ProModel.
FIGURE L3.2
Output Viewer in
Windows Program
Manager.
FIGURE L3.3
File menu in the
Output Viewer.
FIGURE L3.4
Charts menu in the
Output Viewer.
The Charts menu (Figure L3.4) allows the user to select the tables and charts to
display in a report. To place a table or chart in a report, select the desired table or
chart from the Chart menu and drag it to one of the position indicators that appear
on the report. You can create as many custom reports as you wish. Just click on a
new tab to create a new report. To move charts within a report, just click and drag
on the chart caption bar. To move charts to another report, drag it over the desired
report tab until the report opens and then drag it to the desired position in the report.
The filter that appears on the left side of the Output Viewer is used to cus-
tomize the content of a table or chart. In a Location Summary table, for example,
you can select which locations to display. You can also select which columns of
information to display for the table. The filter also allows you to select which
replications and scenarios to display. For multiple replications, you can display
average, minimum and maximum values, or a confidence interval value range.
Using the Format and Style tabs at the top of the Output Viewer can change
the appearance of tables and charts. These tabs only appear when a table or chart
is selected in a report. You can also right-click on a chart to display visual options.
Once you have a report or set of reports looking just the way you want, you
can save them using the Save or Save As options under the File menu. The next
time you run the model, the exact same report will be displayed as before, only
updated to reflect any model changes that have been made.
The Export menu allows data and charts to be copied to the clipboard to paste into
other applications. It also allows you to export reports directly into Microsoft Excel.
j. Resource Costs
k. Variable Summary
l. Simulation Information
m. Log Information
n. Node Entries
See the online help system for an explanation of the columns displayed in each
of these tables.
FIGURE L3.5
A column chart
showing average
contents for different
locations.
FIGURE L3.6
A column chart
showing average
time in the system for
different entities.
model. For example, you might want to compare the average contents of different
locations (Figure L3.5) or the average time in the system for different entities
(Figure L3.6). The examples given in these and the other figures that follow are
taken from the mfg_cost.mod model in the Demo subdirectory. This model was
run for 15 hours and five replications, so all of the charts represent values aver-
aged across all five replications.
FIGURE L3.7
Utilization chart for
locations.
FIGURE L3.8
Entity state chart.
FIGURE L3.9
Entity state pie chart.
Figure L3.9 shows an entity state pie chart for the entity Cog that was shown in
Figure L3.8.
• Single-Capacity Location States: Single-capacity location state graphs
show the percentage of time that each location in the system was either
in operation, being set up, idle, waiting for resources, blocked, or down
(Figure L3.10).
• Multicapacity Location States: This chart shows the percentage of
time that each multicapacity location in the system was empty, partially
occupied, or full (Figure L3.11).
• Resource States: This chart shows the percentage of time a resource
was in use, traveling to the point of use, traveling to park, idle, and down
(Figure L3.12).
FIGURE L3.10
Single-capacity
location state chart.
FIGURE L3.11
Multicapacity location
state chart.
FIGURE L3.12
Resource state chart.
FIGURE L3.13
Time plot of the
contents of a queue.
FIGURE L3.14
Histogram of contents
of a queue.
FIGURE L3.15
An hourly count of
entities processed.
FIGURE L3.16
Dynamic Plots Menu.
FIGURE L3.17
Dynamic Plots Menu.
FIGURE L3.18
Chart View in
Dynamic Plots—
Current Contents of
the Bearing Queue.
L3.8 Exercises
1. Customers arrive at the Lake Gardens post office for buying stamps,
mailing letters and packages, and so forth. The interarrival time is
exponentially distributed with a mean of two minutes. The time to
process each customer is normally distributed with a mean of 10 minutes
and a standard deviation of two minutes.
a. Make a time-series plot of the number of customers waiting in line at
the post office in a typical eight-hour day.
b. How many postal clerks are needed at the counter so that there are
no more than 15 customers waiting in line at the post office at any
time? There is only one line serving all the postal clerks. Change the
number of postal clerks until you find the optimum number.
2. The Lake Gardens postmaster in Exercise 1 wants to serve her customers
well. She would like to see that the average time spent by a postal
customer at the post office is no more than 15 minutes. How many postal
clerks should she hire?
3. For the USA Furniture Factory example in Lab 2, section L2.3,
a. Make a state graph and a pie graph for the splitter and the lathe.
b. Find the percentage of time the splitter and the lathe are idle.
4 BASIC MODELING
CONCEPTS
In this chapter we continue to describe other basic features and modeling con-
cepts of ProModel. In section L4.1 we show an application with multiple lo-
cations and multiple entity types. Section L4.2 describes modeling of multiple
parallel locations. In section L4.3 we introduce you to the concepts of resources.
Section L4.4 shows various routing rules. In section L4.5 we introduce the con-
cept of variables. Section L4.6 introduces the inspection process, tracking of
defects and rework. In section L4.7 we show how to permanently or temporar-
ily batch entities of the same type or different types. In section L4.8 we show
the process of making permanent and temporary attachments of one entity to
another. Section L4.9 describes how similar entities can be accumulated before
processing. Section L4.10 shows the splitting of one entity into multiple entities.
In section L4.11 we introduce various decision statements with appropriate ex-
amples. Finally, in section L4.12 we show you how to model a system that shuts
down periodically.
419
TABLE L4.1 Routing and Assembly Times for the Printed Circuit Boards
1 10 2 5 3 12
2 12 1 6 2 14
3 15 3 8 1 15
FIGURE L4.1
Three processing locations and the PCB Storage.
FIGURE L4.2
Layout of Pomona
Electronics.
each board is exponentially distributed with the mean times (in minutes) shown
in Table L4.1
Define three locations (area1, area2, and area3) where assembly work is
done and another location, PCB_Store, where all the printed circuit boards are
stored for future assembly (Figure L4.1). Assume each of the assembly areas
has infinite capacity. The layout of Pomona Electronics is shown in Figure L4.2.
Note that we used Background Graphics Behind Grid, from the Build menu,
to add the Pomona Electronics logo on the simulation model layout. Add the
robot graphics (or something appropriate). Define three entities PCB1, PCB2,
and PCB3 (Figure L4.3).
Define the arrival process (Figure L4.4). Assume all 1,500 boards are in stock
when the assembly operations begin. The process and routing tables are devel-
oped as in Figure L4.5.
FIGURE L4.3
Three types of circuit boards.
FIGURE L4.4
Arrival process for all circuit boards.
FIGURE L4.5
Processes and routings for Pomona Electronics.
Run the simulation model. Note that the whole batch of 1,500 printed circuit
boards (500 of each) takes a total of 2.46 hours to be processed.
entities that the location can hold at any time. The reserved word INF or INFINITE
sets the capacity to the maximum allowable value. The default capacity for a loca-
tion is one unless a counter, conveyor, or queue is the first graphic assigned to it.
The default capacity in that case is INFINITE.
The number of units of a location refers to the number of identical, inter-
changeable, and parallel locations referenced as a single location for routing and
processing. A multiunit location eliminates the need to create multiple locations
and multiple processes for locations that do the same thing. While routings to and
from each unit are the same, each unit may have unique downtimes.
A multiunit location is created by entering a number greater than one as the
number of units for a normal location. A corresponding number of locations will
appear below the original location with a numeric extension appended to each
copied location name designating the unit number of that location. The original
location record becomes the prototype for the unit records. Each unit will inherit the
prototype’s characteristics unless the individual unit’s characteristics are changed.
Downtimes, graphic symbols, and in the case of multicapacity locations, capacities
may be assigned to each unit. As the number of units of a location is changed, the
individual unit locations are automatically created or destroyed automatically.
The following three situations describe the advantages and disadvantages of
modeling multicapacity versus multiunit locations.
• Multicapacity locations. Locations are modeled as a single unit with
multicapacity (Figure L4.6). All elements of the location perform
identical operations. When one element of the location is unavailable due
to downtime, all elements are unavailable. Only clock-based downtimes
are allowed.
• Multiunit locations. Locations are modeled as single-capacity but
multiple units (Figure L4.7). These are locations consisting of two or
FIGURE L4.6
A single unit location of multicapacity.
FIGURE L4.7
A multiunit location with single-capacity.
FIGURE L4.8
Multiple single-capacity locations.
more parallel and interchangeable processing units. Each unit shares the
same sources of input and the same destinations for output, but each may
have independent operating characteristics. This method provides more
flexibility in the assignment of downtimes and in selecting an individual
unit to process a particular entity.
• Multiple, single-capacity locations. Locations are modeled as individual
and single capacity (Figure L4.8). Usually noninterchangeable locations
are modeled as such. By modeling as individual locations, we gain the
flexibility of modeling separate downtimes for each element. In addition,
we now have complete flexibility to determine which element will process
a particular entity.
Problem Statement
At San Dimas Electronics, jobs arrive at three identical inspection machines ac-
cording to an exponential distribution with a mean interarrival time of 12 minutes.
The first available machine is selected. Processing on any of the parallel machines
is normally distributed with a mean of 10 minutes and a standard deviation of
3 minutes. Upon completion, all jobs are sent to a fourth machine, where they
queue up for date stamping and packing for shipment; this takes five minutes nor-
mally distributed with a standard deviation of two minutes. Completed jobs then
leave the system. Run the simulation for one month (20 days, eight hours each).
Calculate the average utilization of the four machines. Also, how many jobs are
processed by each of the four machines?
Define a location called Inspect. Change its units to 3. Three identical parallel
locations—that is, Inspect.1, Inspect.2, and Inspect.3—are thus created. Also, de-
fine a location for all the raw material to arrive (Material_Receiving). Change the
capacity of this location to infinite. Define a location for Packing (Figure L4.9).
Select Background Graphics from the Build menu. Make up a label “San Dimas
Electronics.” Add a rectangular border. Change the font and color appropriately.
Define an entity called PCB. Define the frequency of arrival of the entity PCB
as exponential with a mean interarrival time of 12 minutes (Figure L4.10). Define
the process and routing at San Dimas Electronics as shown in Figure L4.11.
In the Simulation menu select Options. Enter 160 in the Run Hours box. Run
the simulation model. The average utilization and the number of jobs processed at
the four locations are given in Table L4.2.
FIGURE L4.9
The locations and the layout of San Dimas Electronics.
FIGURE L4.10
Arrivals of PCB at San Dimas Electronics.
FIGURE L4.11
Process and routing tables at San Dimas Electronics.
L4.3 Resources
A resource is a person, piece of equipment (viz. lift truck, pallet truck, etc.)
or some other discrete device that is used for one or more of the following
functions: transporting entities, assisting in performing a process on entities at
locations, performing maintenance on locations, or performing maintenance on
other resources. Resources consist of one or more units with common charac-
teristics, such as a pool of service technicians or a fleet of lift trucks. Resources
may be dynamic, meaning that they move along a path network, or static, in
which no movement occurs. Resources may also have downtimes. The follow-
ing is an example of the use of a static resource. We discuss dynamic resources
in Lab 12, section L12.2. The downtimes of resources are discussed in Lab 6,
section L6.4.
Static resources are resources that do not visibly move. A static resource may
be needed to perform an operation at only one location, such as an inspection
operator, and will appear during the entire simulation in the same place it was
defined graphically. Although a static resource is stationary and does not visibly
move between locations, it may be used at more than one location or to move
entities between locations. In the following example, an operator is used as an
example of a static resource.
At Ghosh’s Gear Shop, a small automotive OEM facility, there are two
NC lathes, a degreaser, and an inspection equipment. Blanks are received at the
receiving area. The blanks are machined either on NC Lathe 1 or NC Lathe 2
(machines are assigned by turn for successive blanks). After machining, the cogs
go to the degreaser for washing. Then the cogs are inspected. Ghosh (a static
resource) moves the parts between machines. The time to move parts between
machines is normally distributed (mean of 3 minutes and a standard deviation
of 1 minute). All the machines run on automated cycles. Figure L4.12 shows
the resource table. The process and routing tables for this simulation model are
shown in Figure L4.13. Figure L4.14 shows a snapshot of the simulation model
of Ghosh’s Gear Shop. Please note that there are no status lights for a static
resource. However, the resource graphic changes color to green when in use and
red when down.
FIGURE L4.12
Ghosh defined as a static resource.
FIGURE L4.13
Process and routing tables for Ghosh’s Gear Shop.
FIGURE L4.14
A snapshot of the
simulation model for
Ghosh’s Gear Shop.
• If JOIN request: Select the location that satisfies a JOIN request (see the
JOIN statement).
• If LOAD request: Select the location that satisfies a LOAD request (see the
LOAD statement).
• If SEND request: Select the location that satisfies a SEND request (see the
SEND statement).
• Longest: Select the location that has been unoccupied the longest.
• Unoccupied until FULL: Continue to select the same location until it is full.
• If EMPTY: Select the location only when empty and continue to select until
it is full.
• Probabilistic: Select based on the probability specified (such as 0.75).
• User condition: Select the location that satisfies the Boolean condition
specified by the user (such as AT2>5). Conditions may include any
numeric expression except for location attributes, resource-specific
functions, and downtime-specific functions.
• CONTINUE: Continue at the same location for additional operations.
CONTINUE is allowed only for blocks with a single routing.
• As ALTERNATE to: Select as an alternate if available and if none of the
above rules can be satisfied.
• As BACKUP: Select as a backup if the location of the first preference is
down.
• DEPENDENT: Select only if the immediately preceding routing was
processed.
If only one routing is defined for a routing block, use the first available, join, load,
send, if empty, or continue rule. The most available, by turn, random, longest
unoccupied, until full, probabilistic, and user condition rules are generally only
useful when a block has multiple routings.
Problem Statement
Amar, Akbar, and Anthony are three tellers in the local branch of Bank of India.
Figure L4.15 shows the layout of the bank. Assume that customers arrive at the bank
according to a uniform distribution (mean of five minutes and half-width of four min-
utes). All the tellers service the customers according to another uniform distribution
(mean of 10 minutes and half-width of 6 minutes). However, the customers prefer
Amar to Akbar, and Akbar over Anthony. If the teller of choice is busy, the custom-
ers choose the first available teller. Simulate the system for 200 customer service
completions. Estimate the teller’s utilization (percentage of time busy).
The locations are defined as Akbar, Anthony, Amar, Teller_Q, and Enter as
shown in Figure L4.16. The Teller_Q is exactly 100 feet long. Note that we have
checked the queue option in the Conveyor/Queue dialog box (Figure L4.17). The
customer arrival process is shown in Figure L4.18. The processes and routings
are shown in Figure L4.19. Note that the customers go to the tellers Amar, Akbar,
and Anthony in the order they are specified in the routing table.
FIGURE L4.15
Layout of the Bank of
India.
FIGURE L4.16
Locations at the Bank of India.
FIGURE L4.17
Conveyor/Queue
dialog box.
FIGURE L4.18
Customer arrival at the Bank of India.
FIGURE L4.19
Process and routing tables at the Bank of India.
% Utilization
Selection in Order of
Tellers Preference Selection by Turn
Amar 79 63.9
Akbar 64.7 65.1
Anthony 46.9 61.5
The results of the simulation model are shown in Table L4.3. Note that Amar
being the favorite teller is busier than Akbar and Anthony.
If the customers were routed to the three tellers in turn (selected in rotation)
the process and routing tables would be as in Figure L4.17. Note that By Turn was
selected from the Rule menu in the routing table. These results of the simulation
model are also shown in Table L4.3. Note that Amar, Akbar, and Anthony are now
utilized almost equally.
L4.5 Variables
A variable is something that is capable of changing or varying. Variables are
placeholders for either real or integer numbers that may change during simulation.
Variables are typically used for making decisions or for gathering data. Variables
can be defined to track statistics and monitor other activities during a simulation
run. This is useful when the built-in statistics don’t capture a particular perfor-
mance metric of interest. Variables might be defined to track:
• The number of customers waiting in multiple queues.
• Customer waiting time during a specific time period.
• Customer time in the store or bank or office.
• Work-in-process inventory.
• Production quantity.
In ProModel two types of variables are used—local variables and global variables.
• Global variables are accessible from anywhere in the model and at any
time. Global variables are defined through the Variables (global) editor
in the Build menu. The value of a global variable may be displayed
dynamically during the simulation. It can also be changed interactively.
Global variables can be referenced anywhere a numeric expression is
valid.
• Local variables are temporary variables that are used for quick convenience
when a variable is needed only within a particular operation (in the Process
table), move logic (in the Routing table), logic (in the Arrivals, Resources,
or Subroutine tables), the initialization or termination logic (in the General
Information dialog box), and so forth. Local variables are available only
within the logic in which they are declared and are not defined in the
Variables edit table. They are created for each entity, downtime occurrence,
or the like executing a particular section of logic. A new local variable is
created for each entity that encounters an INT or REAL statement. It exists
only while the entity processes the logic that declared the local variable.
Local variables may be passed to subroutines as parameters and are
available to macros.
A local variable must be declared before it is used. To declare a local variable,
use the following syntax:
INT or REAL <name1> {= expression}, <name2> {= expression}
Examples:
INT HourOfDay, WIP
REAL const1 ⫽ 2.5, const2 ⫽ 5.0
INT Init_Inventory ⫽ 170
In section L6.1.2 we show the use of a local variable in the simulation model
logic.
FIGURE L4.20
Layout of SoCal
Casting Inc.
FIGURE L4.21
Locations at SoCal Casting Inc.
FIGURE L4.22
Arrival of castings at SoCal Casting Inc.
one minute (normally distributed). The milled castings go to the grinder, where
they are ground for a duration that is uniformly distributed (four to six minutes)
or U(5,1). After grinding, the ground pieces go to the finished parts store. Run the
simulation for 100 hours. Track the work-in-process inventory and the production
quantity.
The complete simulation model layout is shown in Figure L4.20. The loca-
tions are defined as Receiving_Dock, Mill, Grinder, and Finish_Parts_Store (Fig-
ure L4.21). Castings (entity) are defined to arrive in batches of four (Qty each)
every 60 minutes (Frequency) as shown in Figure L4.22. The processing and rout-
ing tables are shown in Figure L4.23.
Define a variable in your model to track the work-in-process inventory (WIP)
of parts in the machine shop. Also, define another variable to track the production
(PROD_QTY) of finished parts (Figure L4.24). Note that both of these are integer
type variables.
FIGURE L4.23
Processing and routing tables for the SoCal Casting Inc.
FIGURE L4.24
Variables for the SoCal Casting Inc. model.
In the processing table, add the following operation statement in the Receiv-
ing location (Figure L4.23).
WIP ⫽ WIP ⫹ 1
Alternatively, these three statements could be written as INC WIP, DEC WIP, and
INC PROD_QTY.
Problem Statement
SoCal Casting Inc. in section L4.5 decides to add an inspection process after the
grinding operation. After inspection, 30 percent of the parts are sent back to the
mill and 10 percent are sent back to the grinder for rework. 5 percent parts are
scrapped. The balance (55 percent) passes inspection and goes on to the finished
parts store. The inspection takes a time that has a triangular distribution (min. 4,
mode 5, max. 6 minutes). The process times for rework are the same as those
for new jobs. Track the amount of rework at the mill and the grinder. Also, track
the amount of scrapped parts and finished production. Run the simulation for
100 hours.
The locations are defined as mill, grinder, inspection, finish parts store, receiv-
ing dock, scrap parts, mill rework, and grind rework as shown in Figure L4.25.
The last four locations are defined with infinite capacities. The arrivals of
castings are defined in batches of four every hour. Next we define five variables
(Figure L4.26) to track work-in-process, production, mill rework, grind rework,
and scrap quantities. The processes and routings are defined as in Figure L4.27.
Note the use of the probabilistic routing rule for Casting at the Inspector loca-
tion. The probabilistic routing rule selects a location listed in a block of routings
based on a probability. Several probability routings should be used together and
the sum of all probabilities must equal one. The entity will wait to be routed until
the selected location has available capacity.
FIGURE L4.25
Simulation model
layout for SoCal
Casting Inc. with
inspection.
FIGURE L4.26
Variables for the SoCal Casting Inc. with inspection model.
FIGURE L4.27
Processing and routing tables for the SoCal Casting Inc. model with inspection.
Problem Statement
El Segundo Composites receive orders for aerospace parts that go through cut-
ting, lay-up, and bonding operations. The bonding operation is done in an au-
toclave in batches of five parts. The processing times for these operations are
FIGURE L4.28
Layout of El Segundo
Composites.
FIGURE L4.29
Processing and routing tables for El Segundo Composites.
FIGURE L4.30
Work in process value history.
Problem Statement
At the Garden Reach plant of the Darjeeling Tea Company, the filling machine
fills empty cans with 50 bags of the best Darjeeling tea at the rate of one can every
1⫾0.5 seconds uniformly distributed. The tea bags arrive to the packing line with
a mean interarrival time of one second exponentially distributed. The filled cans
go to a packing machine where 20 cans are combined into one box. The packing
operation takes uniform (20⫾10) seconds. The boxes are shipped to the dealers.
This facility runs 24 hours a day. Simulate for one day.
The various locations at the Darjeeling Tea Company plant are shown in Fig-
ure L4.31. Three entities (Teabag, Can, and Box) are defined next. The processing
and routing tables are shown in Figure L4.32. The layout of the Darjeeling Tea
Company plant is shown in Figure L4.33.
FIGURE L4.31
Locations at the Darjeeling Tea Company.
FIGURE L4.32
Processing and routing tables at the Darjeeling Tea Company.
FIGURE L4.33
Layout of the
Darjeeling Tea
Company.
Problem Statement
At Shipping Boxes Unlimited computer monitors arrive at Monitor_Q at the rate
of one every 15 minutes (exponential) and are moved to the packing table. Boxes
arrive at Box_Q, at an average rate of one every 15 minutes (exponential) and are
also moved to the packing table. At the packing table, monitors are packed into
boxes. The packing operation takes normal (5,1) minutes. Packed boxes are sent
to the inspector (Inspect_Q). The inspector checks the contents of the box and tal-
lies with the packing slip. Inspection takes normal (4,2) minutes. After inspection,
the boxes are loaded into trucks at the shipping dock (Shipping_Q). The loading
takes uniform (5,1) minutes. Simulate for 100 hours. Track the number of moni-
tors shipped and the WIP of monitors in the system.
The locations at Shipping Boxes Unlimited are defined as Monitor_Q,
Box_Q, Shipping_Q, Inspect_Q, Shipping_Dock, Packing_Table, and Inspec-
tor. All the queue locations are defined with a capacity of infinity. Three entities
(Monitor, Empty_Box, and Full_Box) are defined next. The arrivals of monitors
and emptyboxes are shown in Figure L4.34. The processing and routing tables
are shown in Figure L4.35. A snapshot of the simulation model is captured in
FIGURE L4.34
Arrival of monitors and empty boxes at Shipping Boxes Unlimited.
FIGURE L4.35
Processing and routing tables for Shipping Boxes Unlimited.
FIGURE L4.36
A snapshot of the
simulation model for
the Shipping Boxes
Unlimited.
Figure L4.36. The plot of the work-in-process inventory for the 100 hours of
simulation run is shown in Figure L4.37. Note that the work-in-process inventory
rises to as much as 12 in the beginning. However, after achieving steady state, the
WIP inventory stays mostly within the range of 0 to 3.
Problem Statement
For the Shipping Boxes Unlimited problem in section L4.8.1, assume the inspec-
tor places (loads) a packed box on an empty pallet. The loading time is uniformly
distributed: U(3,1) minutes. The loaded pallet is sent to the shipping dock and
FIGURE L4.37
Time-weighted plot of the WIP inventory at the Shipping Boxes Unlimited.
FIGURE L4.38
Locations at the Shipping Boxes Unlimited.
waits in the shipping queue. At the shipping dock, the packed boxes are unloaded
from the pallet. The unloading time is also uniformly distributed: U(3,1) minutes.
The boxes go onto a waiting truck. The empty pallet is returned, via the pallet
queue, to the inspector. One pallet is used and recirculated in the system. Simulate
for 100 hours. Track the number of monitors shipped and the WIP of monitors.
The locations defined in this model are Monitor_Q, Box_Q, Inspect_Q,
Shipping_Q, Pallet_Q, Packing_Table, Inspector, Shipping_Dock (Figure L4.38).
All queue locations have infinite capacity. The layout of Shipping Boxes Unlim-
ited and a snapshot of the simulation model run are shown in Figure L4.39. Five
entities are defined: Monitor, Box, Empty_Box, Empty_Pallet, and Full_Pallet
FIGURE L4.39
A snapshot of the
simulation model at
the Shipping Boxes
Unlimited.
FIGURE L4.40
Entities at Shipping Boxes Unlimited.
FIGURE L4.41
Arrival of monitors, empty boxes, and empty pallets at Shipping Boxes Unlimited.
as shown in Figure L4.40. The arrivals of monitors, empty boxes, and empty
pallets are shown in Figure L4.41. The processing and routing tables are shown
in Figure L4.42. Note that comments can be inserted in a line of code as follows
(Figure L4.42):
/* inspection time */
The plot of the work-in-process inventory for the 100 hours of simulation
run is presented in Figure L4.43. Note that after the initial transient period
FIGURE L4.42
Processing and routing tables at Shipping Boxes Unlimited.
FIGURE L4.43
Time-weighted plot of the WIP inventory at Shipping Boxes Unlimited.
(艑20 hours), the work-in-process inventory drops and stays mostly in a range
of 0~2.
Note that like the UNGROUP statement, it is necessary to define an additional
process record after unloading for those entities that may have gotten unloaded.
Problem Statement
Visitors arrive at California Adventure Park in groups that vary in size from two
to four (uniformly distributed). The average time between arrivals of two succes-
sive groups is five minutes, exponentially distributed. All visitors wait in front of
the gate until five visitors have accumulated. At that point the gate opens and al-
lows the visitors to enter the park. On average, a visitor spends U(20⫾10) minutes
in the park. Simulate for 1,000 hours. Track how many visitors are waiting outside
the gate and how many are in the park.
Three locations (Gate_In, Walk_In_Park, and Gate_Out) are defined in this
model. Visitor is defined as the entity. The processes and the layout of the adven-
ture park are shown in Figures L4.44 and L4.45, respectively.
FIGURE L4.44
Processing and routing tables for California Adventure Park.
FIGURE L4.45
Layout of California
Adventure Park.
Problem Statement
The cafeteria at San Dimas High School receives 10 cases of milk from a vendor
each day before the lunch recess. On receipt, the cases are split open and individ-
ual cartons (10 per case) are stored in the refrigerator for distribution to students
during lunchtime. The distribution of milk cartons takes triangular (.1, .15, .2)
minute per student. The time to split open the cases is U(6,1) minutes. Moving
the cases from receiving to the refrigerator area takes five minutes per case, and
moving the cartons from the refrigerator to the distribution area takes 0.2 minutes
per carton. Students wait in the lunch line to pick up one milk carton each. There
are only 100 students at this high school. Students show up for lunch with a mean
interarrival time of 1 minute (exponential). On average, how long does a carton
stay in the cafeteria before being distributed and consumed? What are the maxi-
mum and the minimum times of stay? Simulate for one lunch period.
The layout of the San Dimas High School cafeteria is shown in Figure L4.46.
Three entities—Milk_Case, Milk_Carton, and Student—are defined. Ten milk
cases arrive at the beginning of a lunch period. One hundred students show up for
lunch each day. The arrival of students and milk cases is shown in Figure L4.47.
The processing and routing tables are shown in Figure L4.48.
FIGURE L4.46
Layout of the San
Dimas High School
cafeteria.
FIGURE L4.47
Arrival of milk and students at the San Dimas High School cafeteria.
FIGURE L4.48
Processing and routing tables at the San Dimas High School cafeteria.
Note that, like the UNGROUP and UNLOAD statements, a new process record
needs to be defined when using the SPLIT statement.
causes the program to take action1 if condition is true and action2 if condition is
false. Each action consists of one or more ProModel statements. After an action is
taken, execution continues with the line after the IF block.
FIGURE L4.49
Control statements
available in ProModel.
Problem Statement
The Bombay Restaurant offers only a drive-in facility. Consumers arrive at the
rate of six each hour (exponential interarrival time). They place their orders at
the first window, drive up to the next window for payment, pick up food from
the last window, and then leave. The activity times are given in Table L4.4. The
drive-in facility can accommodate 10 cars at most. However, customers typically
leave and go to the Madras Café across the street if six cars are waiting in line
when they arrive. Simulate for 100 days (8 hours each day). Estimate the number
of customers served each day. Estimate on average how many customers are lost
each day to the competition.
An additional location (Arrive) is added to the model. After the customers
arrive, they check if there are fewer than six cars at the restaurant. If yes, they join
the line and wait; if not, they leave and go across the street to the Madras Café.
An IF-THEN-ELSE statement is added to the logic window in the processing table
(Figure L4.50). A variable (Customer_Lost) is added to the model to keep track
of the number of customers lost to the competition. The layout of the Bombay
FIGURE L4.50
Processing and routing tables at the Bombay Restaurant.
FIGURE L4.51
Layout of the Bombay
Restaurant.
Restaurant is shown in Figure L4.51. Note that Q_1 and Q_2 are each 100 feet
long and Q_3 is 200 feet long.
The total number of customers lost is 501 in 100 days. The number of
customers served in 100 days is 4791. The average cycle time per customer is
36.6 minutes.
Problem Statement
The inspector in section L4.8.2 is also the supervisor of the shop. As such, she in-
spects only when at least five full boxes are waiting for inspection in the Inspect_Q.
FIGURE L4.52
An example of the WHILE . . . DO logic for Shipping Boxes Unlimited.
FIGURE L4.53
A plot of the contents of the inspection queue.
A WHILE...DO loop is used to check if the queue has five or more boxes waiting
for inspection (Figure L4.52). The loop will be executed every hour. Figure L4.53
shows a time-weighted plot of the contents of the inspection queue. Note how the
queue builds up to 5 (or more) before the inspector starts inspecting the full boxes.
Problem Statement
For the SoCal Casting Inc. example in section L4.5, we would like to assign an
upper limit to the work-in-process inventory in the shop. A DO...WHILE loop will
be used to check if the level of WIP is equal to or above five; if so, the incoming
castings will wait at the receiving dock (Figure L4.54). The loop will be executed
once every hour to check if the level of WIP has fallen below five. Figure L4.55
shows an hourly average plot of the value of WIP at SoCal Casting Inc. Note that
the level of WIP is kept at or below five.
FIGURE L4.54
An example of DO . . . WHILE loop.
FIGURE L4.55
An hourly average plot
of the WIP at SoCal
Casting Inc.
Problem Statement
The inspector in section L4.8.2 is also the supervisor of the shop. As such, she
waits an hour before checking if there are at least five full boxes waiting in the
Inspect_Q. A DO...UNTIL loop is used to wait 60 minutes and then finding out if
the queue has five or more boxes waiting for inspection (Figure L4.56). The loop
will be executed once every hour. Figure L4.57 shows a time-weighted plot of
the contents of the inspection queue. Note how the queue builds up to 5 (or more)
before the inspector starts inspecting the full boxes.
FIGURE L4.56
An example of DO...UNTIL loop.
FIGURE L4.57
An hourly average plot
of the contents of the
inspection queue.
Problem Statement
The Indian Bank has acquired the Bank of India (section L4.4). Anthony has
been given a golden handshake (that is, fired). As a result of new training pro-
vided to the two remaining tellers (Amar and Akbar) there has been a change in
their customer service time. Whenever more than three customers are waiting for
service, the service time is reduced to an average of five minutes and a standard
deviation of two minutes (normally distributed). The layout of the new Indian
Bank is shown in Figure L4.58. A GOTO statement is used to jump to the appropri-
ate wait statement depending on the number of customers waiting for service in
the Teller_Q, as shown in Figure L4.59.
FIGURE L4.58
The layout of the
Indian Bank.
FIGURE L4.59
An example of a GOTO statement.
This model illustrates one of the dangers of using a GOTO statement and why
its use is discouraged in computer science textbooks. In this example, the L1 and
L2 statements ALWAYS get executed. In other words, a GOTO statement doesn’t work
like an IF-THEN-ELSE.
FIGURE L4.60
A snapshot of the
simulation model for
Bombay Dining.
FIGURE L4.61
Process and routing logic for Bombay Dining.
FIGURE L4.62
Hourly average plot of the dining room contents.
check if the total number of customers in the dining room, cashier queue, and the
two cashier windows taken together is less than 20 to allow a newly arrived diner
in the dining room. The diner is open 24 hours a day, seven days a week. Simulate
for one week. Figure L4.62 shows a plot of the dining room contents.
Problem Statement
The Bank of India in section L4.4 opens for business each day from 9 A.M. until
4 P.M. (7 hours or 420 minutes). Assume that the customers arrive to the bank
according to an exponential distribution (mean of 3 minutes). All the tellers ser-
vice the customers according to a uniform distribution U(10,6) minutes. Custom-
ers are routed to the three tellers in turn (selected in rotation).
Each day at 12 noon after 180 minutes (3 hours) of operation, the front door
of the bank is locked for a lunch recess. Any new customers arriving at the bank
are turned away. Customers already inside the bank continue to get served. The
bank reopens the front door 60 minutes (1 hour) later to new customers. At 4 P.M.
each day (after 420 minutes of bank opening) the front door is closed again. No
new customers are admitted for business. The bank eventually closes when the
last customer in the bank has been served. Simulate the system for 5 days (120
hours). Make a time-series plot of the Teller_Q to show the effect of locking the
front door of the bank.
The logic for locking the front door is shown in Figure L4.63. The simulation
clock time clock(min) is a cumulative counter of minutes elapsed since the start of
the simulation run. The current time of any given day can be determined by modu-
lus dividing the current simulation time, clock(min), by 1,440 minutes (24 hours).
If the remainder of clock(min) divided by 1,440 minutes is between 180 minutes
and 240 minutes, the arriving customers are turned away (disposed). Otherwise,
they are allowed into the bank. Also, after 4 P.M. (420 minutes after bank opening)
each day the front door is closed again to new customers. An IF-THEN-ELSE logic
block as described in section L4.11.1 is used here.
A time-series plot of the contents of the Teller_Q is shown in Figure L4.64.
This plot clearly shows how the Teller_Q (and the whole bank) builds up dur-
ing the day; then, after the front door is locked after 3 hours of operation (180
minutes) into the simulated day, customers remaining in the queue are processed
and the queue length decreases. The queue length picks back up when the bank
reopens the front door after an hour.
The histogram of the same Teller queue (Figure L4.65) shows that ap-
proximately 79 percent of the time there are 2 or less customers waiting. What
FIGURE L4.63
Process and routing logic for the Bank of India.
FIGURE L4.64
Hourly average plot of Teller_Q contents at the Bank of India.
FIGURE L4.65
Histogram of Teller_Q contents at the Bank of India.
is the average time a customer spends in the bank? Would you recommend
that the bank not close the door after 5 hours of operation (customers never
liked this practice anyway)? Will the average customer spend more time in the
bank?
L4.13 Exercises
1. Visitors arrive at Kid’s World entertainment park according to an
exponential interarrival time distribution with mean 2.5 minutes. The
travel time from the entrance to the ticket window is normally distributed
with a mean of 3 minutes and a standard deviation of 0.5 minute. At the
ticket window, visitors wait in a single line until one of four cashiers is
available to serve them. The time for the purchase of tickets is normally
distributed with a mean of five minutes and a standard deviation of one
minute. After purchasing tickets, the visitors go to their respective gates
to enter the park. Create a simulation model of this system. Run the
simulation model for 2,000 hours to determine:
a. The average and maximum lengths of the ticketing queue.
b. The average number of customers completing ticketing per hour.
c. The average and maximum numbers of customers in the ticketing
system.
d. The average utilization of the cashiers.
e. Whether management should add more cashiers?
2. A consultant for Kid’s World recommended that four individual queues
be formed at the ticket window (one for each cashier) instead of one
common queue. Create a simulation model of this system. Run the
simulation model for 2,000 hours to determine:
a. The average and maximum lengths of the ticketing queues.
b. The average number of customers completing ticketing per hour.
c. The average and maximum numbers of customers in the ticketing
system.
d. The average utilization of the cashiers.
e. Whether you agree with the consultant’s decision. Would you
recommend a raise for the consultant or fire him/her?
3. At the Kid’s World entertainment park in Exercise 1, the operating
hours are 8 A.M. until 10 P.M. each day, seven days of the week. The
ticketing window closes at 9 P.M. each day. Any customers arriving to the
ticketing window after 9 P.M. are turned away. Simulate for a whole year
and answer questions a–e as given in Exercise 1.
4. At Southern California Airline’s traveler check-in facility, three types
of passengers arrive: passengers with e-tickets (Type E), passengers
with paper tickets (Type T), and passengers that need to purchase tickets
(Type P). The interarrival distribution and the service times for these
passengers are given in Table L4.5. Create a simulation model of this
system. Run the simulation model for 2,000 hours. If separate gate
agents serve each type of passenger, determine the following:
a. The average and maximum length of the three queues.
b. The average number of passengers of each type completing check-in
procedures per hour.
Type E Exponential (mean 5.5 min) Normal (mean 3 min., std.dev. 1 min.)
Type T Exponential (mean 10.5 min) Normal (mean 8 min., std.dev. 3 min.)
Type P Exponential (mean 15.5 min) Normal (mean 12 min., std.dev. 3 min.)
From To Probability
to get served. Simulate for a whole year and respond to the following
questions:
a. Figure out the utilization of each department.
b. What are the average and maximum numbers of patients in each
department?
c. Which is the bottleneck department?
d. What are the average and maximum times spent by a patient in the
nursing home?
7. United Electronics manufactures small custom electronic assemblies.
Parts must be processed through four stations: assembly, soldering,
painting, and inspection. Orders arrive with an exponential interarrival
distribution (mean 20 minutes). The process time distributions are shown
in Table L4.8.
The soldering operation can be performed three jobs at a time.
Painting can be done on four jobs at a time. Assembly and inspection
Number Number
Job of of jobs Time between
Type batches per batch Assembly Time Soldering Time Painting Time Inspection Time Batch Arrivals
Loader 1
Weighing
Loader queue Weighing queue scale
Loader 2
the same as during the first inspection. We assume in this model that an
assembly defect is eventually corrected and then it is passed on to the
next station. Simulate for 2,000 hours. Determine the number of good
appliances shipped in a year.
10. Salt Lake City Electronics manufactures small custom communication
equipment. Two differentjob types are to be processed within the
following manufacturing cell. The necessary data are given in
Table L4.10. Simulate the system for 200 days, eight hours each day, to
determine the average number of jobs waiting for different operations,
number of jobs of each type finished each day, average cycle time for
each type of job, and all jobs taken together.
11. Six dump trucks at the DumpOnMe facility in Riverside are used to
haul coal from the entrance of a small mine to the railroad. Figure L4.66
provides a schematic of the dump truck operation. Each truck is loaded
by one of two loaders. After loading, a truck immediately moves to
the scale to be weighed as soon as possible. Both the loaders and the
scale have a first-come, first-served waiting line (or queue) for trucks.
Travel time from a loader to the scale is considered negligible. After
being weighed, a truck begins travel time (during which time the
truck unloads), and then afterward returns to the loader queue. The
distributions of loading time, weighing time, and travel time are shown
in Table L4.11.
a. Create a simulation model of this system. Simulate for 200 days,
eight hours each day.
5 FITTING STATISTICAL
DISTRIBUTIONS
TO INPUT DATA
There are three kinds of lies: lies, damned lies, and statistics.
—Benjamin Disraeli
Input data drives our simulation models. Input data can be for interarrival times,
material handling times, setup and process times, demand rates, loading and un-
loading times, and so forth. The determination of what data to use and where
to get the appropriate data from is a complicated and time-consuming task. The
quality of data is also very important. We have all heard the cliché “garbage in,
garbage out.” In Chapter 5 we discussed various issues about input data collection
and analysis. We have also described various empirical discrete and continuous
distributions and their characteristics (Chapter 5). In this lab we describe how
ProModel helps in fitting statistical distributions to user-input data. In section
L5.1 we introduce you to the utility Stat::Fit. In section L5.2 we show the applica-
tion of Stat::Fit with an example problem. In section L5.3 we show you how to
use the Auto::Fit function in Stat::Fit to automatically fit an appropriate distribu-
tion to the input data.
465
FIGURE L5.1
Stat::Fit opening
screen.
to the data using conventional methods. Stat::Fit offers the capability to perform
input data analysis and fit probability distributions to empirical data. It allows
comparison among various distribution functions. It performs goodness-of-fit
tests using chi-square, Kolmogorov-Smirnov, and Anderson-Darling procedures.
It calculates appropriate parameters for distributions. It provides distribution ex-
pressions for use in the simulation model. When the amount of data is small, the
goodness-of-fit tests are of little use in selecting one distribution over another. It
is inappropriate to fit one distribution over another in such a situation. Also, when
conventional techniques have failed to fit a distribution, a frequency distribution
of the data is used directly as a user distribution (Chapter 5, section 5.9).
The opening menu of Stat::Fit is shown in Figure L5.2. Various options are
available in the opening menu:
1. File: This menu opens a new Stat::Fit project or an existing project or
data file. The File menu is also used to save a project.
2. Edit: The edit menu is used to access the Cut, Copy, Paste, Insert, Delete,
and Clear commands.
3. Input: The input menu is used to access various input options,
mathematical operations, transformations, and filters. It is also used to
repopulate the input data, generate distributions, and toggle between the
input data table and input graph.
4. Statistics: This menu is used to access descriptive statistics, binned data,
and run various independence tests for the input data.
5. Fit: This menu provides a Fit Setup dialog and a Distribution Graph
dialog. Other options are also available when a Stat::Fit project is
opened. The Fit Setup dialog lists all the distributions supported by
Stat::Fit and the relevant choices for goodness-of-fit tests. At least one
FIGURE L5.2
Stat::Fit opening
menu.
FIGURE L5.3
Stat::Fit data input
options.
TABLE L5.1 Times between Arrivals of Cars at San Dimas Gas Station
1 12.36
2 5.71
3 16.79
4 18.01
5 5.12
6 7.69
7 19.41
8 8.58
9 13.42
10 15.56
11 10
12 18
13 16.75
14 14.13
15 17.46
16 10.72
17 11.53
18 18.03
19 13.45
20 10.54
21 12.53
22 8.91
23 6.78
24 8.54
25 11.23
26 10.1
27 9.34
28 6.53
29 14.35
30 18.45
data and fit an appropriate continuous distribution to the data. Figure L5.4 shows
part of the actual data of times between arrivals of cars in minutes. The sample
data have 30 data points. Figure L5.5 shows the histogram of the input data, while
Figure L5.6 shows some of the descriptive statistics generated by Stat::Fit.
FIGURE L5.4
Times between arrivals
of cars at San Dimas
Gas Station.
FIGURE L5.5
Histogram of the times
between arrival data.
FIGURE L5.6
Descriptive statistics
for the input data.
FIGURE L5.7
The Auto::Fit
submenu.
FIGURE L5.8
Various continuous
distributions fitted to
the input data.
FIGURE L5.9
Goodness-of-fit tests performed on the input data.
FIGURE L5.10
Comparison of actual
data and fitted uniform
distribution.
in terms of the amount of fit. Both the Kolmogorov-Smirnov and the Anderson-
Darling goodness-of-fit tests will be performed on the input data as shown in Fig-
ure L5.9. The Maximum Likelihood Estimates will be used with an accuracy of
at least 0.00003. The actual data and the fitted uniform distribution are compared
and shown in Figure L5.10.
Because the Auto::Fit function requires a specific setup, the Auto::Fit view
can be printed only as the active window or part of the active document, not
as part of a report. The Auto::Fit function will not fit discrete distributions. The
manual method, previously described, should be used instead.
L5.4 Exercises
1. Consider the operation of a fast-food restaurant where customers arrive
for ordering lunch. The following is a log of the time (minutes) between
arrivals of 40 successive customers. Use Stat::Fit to analyze the data and
fit an appropriate continuous distribution. What are the parameters of this
distribution?
11 11 12 8 15 14 15 13
9 13 14 9 14 9 13 7
12 12 7 13 12 16 7 10
8 8 17 15 10 7 16 11
11 10 16 10 11 12 14 15
11 11 12 8 15 14 15 13
9 13 14 10 14 9 13 12
12 12 11 13 12 16 11 10
10 8 17 12 10 7 13 11
11 10 13 10 11 12 14 15
3. The following is the number of incoming calls (each hour for 80 successive
hours) to a call center setup for serving customers of a certain Internet
service provider. Use Stat::Fit to analyze the data and fit an appropriate
discrete distribution. What are the parameters of this distribution?
12 12 11 13 12 16 11 10
9 13 14 10 14 9 13 12
12 12 11 13 12 16 11 10
10 8 17 12 10 7 13 11
11 11 12 8 15 14 15 13
9 13 14 10 14 9 13 12
12 12 11 13 12 16 11 10
10 8 17 12 10 7 13 11
11 10 13 10 11 12 14 15
10 8 17 12 10 7 13 11
6 INTERMEDIATE MODEL
BUILDING
All truths are easy to understand once they are discovered; the point is to
discover them.
—Galileo Galilei
In this lab we expand on the basic ProModel concepts discussed in Lab 4. Sec-
tion L6.1 introduces the concept of attributes. Section L6.2 shows its application
in the calculation of cycle times. In section L6.3 we simulate the process of sorta-
tion, sampling inspection, and rework. Section L6.4 discusses various aspects of
machine breakdowns and maintenance; section L6.5 shows how to model shift-
working patterns; section L6.6 presents an application of ProModel in a job shop;
section L6.7 introduces the modeling of priorities; and section L6.8 has a couple
of examples of pull system applications in manufacturing. Costs are modeled and
tracked in section L6.9. Section L6.10 shows how to import background graphics
into a model, and section L6.11 shows how to define and display various views
of a model. Section L6.12 describes the creation of a model package for ease of
distribution to others.
L6.1 Attributes
Attributes can be defined for entities or for locations. Attributes are placeholders
similar to variables but are attached to specific entities or locations and usually
contain information about that entity or location. Attributes are changed and as-
signed when an entity executes the line of logic that contains an operator, much
like the way variables work. Some examples of attributes are part type, customer
number, and time of arrival of an entity, as well as length, weight, volume, or
some other characteristic of an entity.
475
Children 8 2
Women 12 3
Men 10 2
FIGURE L6.1
Attribute declaration.
FIGURE L6.2
Variable definitions.
FIGURE L6.3
Process and routing tables for Fantastic Dan.
FIGURE L6.4
Arrival of customers at Fantastic Dan.
FIGURE L6.5
A snapshot of the
simulation of model
for Fantastic Dan.
FIGURE L6.6
Tracking the number of male customers in the salon.
FIGURE L6.7
Layout of California Pipes and Tubes.
type of pipe it can hold. The packing worker loads pipes into the Box. Workers must
load the stainless steel pipes into the box designated to hold stainless steel pipes,
alloy steel pipes into the box designated to hold alloy steel pipes and so on. There-
fore, the attribute value of the Pipe, p_type, must match the attribute value of the
Box, b_type. We can use local variables to accomplish this modeling task. In this
example, we have defined X as a local variable and set it equal to b_type. Figure 6.8
shows the process and routing tables for California Pipes and Tubes.
After the pipes have been inspected and packed into respective boxes they are
sent to separate rack locations for eventual shipment to customers. Simulate for
2,000 hours of operation and track the various types of pipes shipped.
FIGURE L6.8
Process and routing tables for California Pipes and Tubes.
FIGURE L6.9
Setting the attribute Time_In and logging the cycle time.
FIGURE L6.10
The minimum, maximum, and average cycle times for various customers.
FIGURE L6.11
Keeping track of machined_qty and modeling probabilistic routings at the Inspect location.
FIGURE L6.12
A snapshot of the simulation model for Discs-R-Us.
inspection 70 percent of the discs pass and leave the system; 30 percent of the discs
fail and are sent back to the input queue for rework. Determine the following:
a. Number of discs of each type shipped each week (40-hour week)?
b. Number of discs machined each week?
c. Number of discs inspected each week?
d. Average cycle time for each type of disc?
e. Number of discs reworked each week?
f. Average number of discs waiting in the input queue and the inspection
queue?
Five locations (Mill, Input_Q, Lathe, Inspect, and Inspect_Q) are defined for
this model. Four variables (qty, machined_qty, inspect_qty, rework_qty) are de-
fined. Figure L6.11 shows how we keep track of the machined quantity as well as
model the probabilistic routings after inspection. Figure L6.12 shows a snapshot
of the simulation model with variables added for keeping track of the number of
discs machined, inspected, and reworked.
The mean time to repair (MTTR) refers to the time the location or resource
remains down for repair. The MTTR depends on the ease and/or cost with which
a location or resource can be maintained or repaired.
For single-capacity locations, downtime of a location or resource can be
scheduled at regular intervals based on the clock time that has expired, the number
of entities processed at a location, the usage of the machine (resource) in time, a
change in entity type, or whenever some event occurs in the simulation. Unsched-
uled breakdowns of a machine can also be modeled in a similar fashion.
To model preventive maintenance or breakdowns, use the following
procedure:
1. Go to the Build/Locations menu.
2. Click on the DT button for a particular location record and select the
type of downtime you want to define from the menu.
a. Clock based.
b. Number of entries based.
c. Usage based.
d. Call based.
3. Fill in the information for each of the fields in the table that appears.
4. In the logic field, enter any logic associated with downtime (this is where
you enter the duration of the downtime).
Example:
DISPLAY “The Lathe is Down for Preventive Maintenance”
WAIT N(10,2) min
FIGURE L6.13
Logic for preventive maintenance at Discs-R-Us Manufacturing Inc.
FIGURE L6.14
A snapshot of the simulation model for Discs-R-Us Manufacturing Inc.
FIGURE L6.15
Layout of the machine
shop—modeling
breakdown with TTF
and TTR.
Problem Statement
The turning center in this machine shop (Figure L6.15) has a TTF distribution that
is exponential with a mean of 10 minutes. The repair time or time to repair (TTR)
is also distributed exponentially with a mean of 10 minutes.
This model shows how to get ProModel to implement downtimes that use
TTF rather than time between failures (TBF) data. In practice, you most likely
will want to use TTF because that is how data will likely be available to you, as-
suming you have unexpected failures (breakdowns). If you have regularly sched-
uled downtimes (preventive maintenance), it may make more sense to use TBF.
In this example, the theoretical percentage of uptime is MTTF/(MTTFMTTR),
where M indicates a mean value. The first time to failure and time to repair are set
in the variable initialization section (Figure L6.16). Others are set in the downtime
logic (Figure L6.17). Note that the downtime is not scheduled.
FIGURE L6.16
Variable initializations.
FIGURE L6.17
Clock downtime logic.
FIGURE L6.18
Process and routing tables.
The processing and routing tables are shown in Figure L6.18. We will run
the simulation for 1,000 hours and collect batch mean statistics for analyzing
the output. The method of batch means, or interval batching, is a way to col-
lect independent samplesas an alternative to running multiple replications when
simulating steady-state systems. In batch means, the simulation is divided into
consecutive periods or intervals and statistics are collected on each period. Each
period is treated as though it were a replication. The advantage over running mul-
tiple replications is that the warm-up period runs only once (not a huge advantage
given modern computing speeds).
Batch mean statistics are collected by selecting the “batch mean” option in
the Simulation Options dialog (Figure L6.19). We will set the interval length to
1,200 minutes (20 hours) for batching the data. The number of intervals is deter-
mined by dividing the run length (1,000 hours) by the interval length. The batch
mean statistics for different states of the turning center (including the percent
down) are displayed by selecting the single-capacity state table as shown in Fig-
ure L6.20. The table that appears is shown in Figure L6.21 that automatically
displays the average of the interval means for each state. Additional statistics for
each state such as its min, max, std dev, and confidence interval values can be
displayed by selecting these options from the filter on the left (see Figure L6.22).
(Dr. Stephen Chick, INSEAD contributed this problem.)
FIGURE L6.19
Batch mean option
chosen in Simulation
dialog.
FIGURE L6.20
Output viewer showing selection of the single-capacity location states.
FIGURE L6.21
Average of all the batches in the ProModel Output Viewer.
FIGURE L6.22
Additional statistics for batch mean, single-capacity location state values.
Problem Statement
For the Discs-R-Us Manufacturing Inc. (section L6.3) an operator is used to
process the parts at both the lathe and the mill. The operator is also used to inspect
the parts. The operator is on a shift schedule from 8 A.M. until 5 P.M. with breaks
as shown in Table L6.3 and Figures L6.23 and L6.24.
Breaks From To
FIGURE L6.23
Weekly shift schedule at Discs-R-Us Manufacturing Inc.
FIGURE L6.24
Assigning the Shift File to the locations—Lathe, Mill, and Inspect.
We are using the DISPLAY statement to notify the user when the operator is
on a break (Figure L6.25). The process and the routing tables were shown in Fig-
ure L6.11. Determine the following:
a. The quantity of discs of each type shipped each week (40-hour week).
b. The cycle time for each type of discs.
c. The maximum and minimum cycle times.
d. The number of discs reworked each week.
e. The average number of discs waiting in the inspection queue.
A snapshot of the model using the shift breaks is shown in Figure L6.26. Run
the model with and without shift breaks. What difference do you notice in these
statistics? How can you improve the system?
FIGURE L6.25
Use the DISPLAY
statement to notify the
user when the operator
is on a break.
FIGURE L6.26
A snapshot of the Discs-R-Us model using shift break schedule.
FIGURE L6.27
Locations at Joe’s
Jobshop.
FIGURE L6.28
Variables to track jobs
processed.
FIGURE L6.29
Processing and routing tables at Joe’s Jobshop.
FIGURE L6.30
A snapshot of the
simulation model for
Joe’s Jobshop.
3. Selecting resources.
4. Prioritizing downtimes—discussed in section L6.4.
Problem Statement
At Singh’s Export Machine Shop in the suburbs of Mumbai, two types of jobs
are processed: domestic and export. All jobs are processed through a machin-
ing center and a lathe. The processing times for all jobs on the machining center
and the lathe are Triangular(10,12,18) minutes and Triangular(12,15,20) minutes,
respectively.
Export jobs are given priority over domestic jobs for shop release—that is, in
moving from the input queue to the machining center. Five locations are defined:
Lathe, Machining_Center, In_Q_Domestic, In_Q_Export, and Outgoing_Q. Two
entities (domestic and export) are defined. The rate of arrival of both type of
jobs is Exponential(30) minutes. The processing and routing tables are shown in
Figure L6.32. Note that the priority of domestic jobs is set at a value of 1 while
that of export jobs is set at 10. Higher priority numbers signify higher priority in
terms of selecting the upstream process. The priorities can range from 0 to 999.
The default priority is 0. Simulate for 100 days (800 hours).
FIGURE L6.31
A snapshot of the
simulation model
for Singh’s Export
Machine Shop.
FIGURE L6.32
Processing and routing tables for Singh’s Export Machine Shop.
FIGURE L6.33
Time plot of the input queue contents (domestic and export).
Note that the input queue for export jobs remains quite small because of
higher priority given to export jobs, while the input queue for domestic jobs
(lower priority) keeps growing to unsustainable levels (Figure L6.33).
send parts to downstream locations only when there is capacity available. In the
second type of pull system we model a kanban system using the Toyota Produc-
tion System (TPS) philosophy.
Problem Statement
At the Milwaukee Machine Shop (MMS), two types of aircraft parts are pro-
cessed in a machining cell. The cell consists of one lathe and one mill. Type A
jobs must be processed first on the lathe and then on the mill. Type B jobs are pro-
cessed only on the mill (Table L6.5). The aircraft manufacturer (customer) needs
a limited number of the two types of jobs (Table L6.5). All jobs are processed on
a first-in, first-out basis.
Brookfield Forgings is a supplier of forgings for MMS. Forgings are produced
in batches of five every day (exponential with a mean of 24 hours). However, the
forgings are supplied to MMS only on receipt of an order (for a batch of 5 forg-
ings) from the customer for a specific type of job. In other words, when customer
orders arrive at MMS, raw forgings are supplied by Brookfield Forgings (a pull
system of shop loading). The aircraft manufacturer (customer) needs only a lim-
ited number of the two types of jobs (Table L6.5). Track the work-in-process
inventories and the production quantities for both types of jobs using a simulation
model.
Six locations (Mill, Lathe, Brookfield_Forgings, Order_Arrival, Lathe_Q,
and Mill_Q) and four entities (Type_A, Type_B, Orders_A, and Orders_B) are
defined. The arrivals of various entities are shown in Figure L6.34. Five global
variables (wip_A, wip_B, wip_Total, prod_A, and prod_B) are defined to track
the work-in-process and production of the two types of jobs. The processes and
routings are shown in Figure L6.35. Note that as soon as a customer order is re-
ceived at the MMS, a signal is sent (SEND) to Brookfield Forgings to ship a forging
(of the appropriate type) to MMS. Thus the arrival of customer orders pulls the
raw material from the vendor. When the parts are fully machined, they are paired
(JOINed) with the appropriate customer order at the orders arrival location. Figure
L6.36 shows a layout of the MMS and a snapshot of the simulation model.
FIGURE L6.34
Arrival of entities at the Milwaukee Machine Shop.
FIGURE L6.35
Processing and routing tables for the Milwaukee Machine Shop.
FIGURE L6.36
A snapshot of the
simulation model
for the Milwaukee
Machine Shop.
Problem Statement
A consultant recommends implementing a production kanban system for the
Milwaukee Machine Shop (MMS) in section L6.8.1. Simulation is used to find out
how many kanbans should be used. Model the shop with a total of five kanbans.
The kanban procedure operates in the following manner:
1. As soon as an order is received by the MMS, they communicate it to the
Brookfield Forgings.
2. Brookfield Forgings holds the raw material in their own facility in the
forging queue in the sequence in which the orders were received.
3. The production of jobs at the MMS begins only when a production
kanban is available and attached to the production order.
4. As soon as the production of any job type is finished,
The locations at the MMS are defined as shown in Figure L6.37. A total of
five entities are defined—Type_A, Type_B, Orders_A, Orders_B, and Kanban.
Kanbans are defined as virtual entities for use in controlling the pull system
mechanism.
FIGURE L6.37
Locations at the Milwaukee Machine Shop.
FIGURE L6.38
Arrival of entities at Milwaukee Machine Shop.
The arrival of two types of jobs at Brookfield Forgings is shown in the arriv-
als table (Figure L6.38). This table also shows the arrival of two types of customer
orders at the MMS. A total of five kanbans are generated at the beginning of the
simulation run.
Figure L6.39 shows a layout of the MMS and a snapshot of the simulation
model. The process and the routing tables are shown in Figure L6.40. The arrival of
a customer order (Orders_A or Orders_B) at the orders arrival location sends a signal
to Brookfield Forgings in the form of a production kanban. The kanban is temporarily
attached (LOADed) to a forging of the right type at the Order_Q. The forgings are sent
to the MMS for processing. After they are fully processed, the kanban is separated
(UNLOADed). The kanban goes back to the kanban square. The finished part is united
(JOINed) with the appropriate customer order at the orders arrival location.
FIGURE L6.39
A snapshot of the simulation model for the Milwaukee Machine Shop.
FIGURE L6.40
Processing and routing tables at the Milwaukee Machine Shop.
Locations
The Locations cost dialog box (Figure L6.41) has two fields—Operation Rate and
Per. Operation rate specifies the cost per unit time to process at the selected loca-
tion. Per is a pull-down menu to set the time unit for the operation rate as second,
minute, hour, or day.
Resources
The Resources cost dialog box (Figure L6.42) has three fields—Regular Rate, Per,
and Cost Per Use. Regular Rate specifies the cost per unit of time for a resource
used in the model. This rate can also be set or changed during run time using the
SETRATE operation statement. Per is a pull-down menu, defined before. Cost Per
FIGURE L6.41
The cost dialog
box—Locations option.
FIGURE L6.42
The Cost dialog
box—Resources option.
FIGURE L6.43
The Cost dialog
box—Entities option.
Use is a field that allows you to define the actual dollar cost accrued every time
the resource is obtained and used.
Entities
The Entities cost dialog box (Figure L6.43) has only one field—Initial Cost. Ini-
tial cost is the cost of the entity when it arrives to the system through a scheduled
arrival.
Problem Statement
Raja’s Manufacturing Cell consists of two mills and a lathe. All jobs are pro-
cessed in the same sequence through the following locations—arriving station,
lathe, mill1, mill 2, and exit station. The processing times and operation costs are
shown in Table L6.6. The arrival rate of jobs is exponentially distributed with a
mean of 20 minutes. The initial cost of the raw material is $100 per piece. Track
the number of jobs produced, the total cost of production, and the cost per piece
of production. Simulate for 200 hours.
FIGURE L6.44
Processing and routing tables for Raja’s Manufacturing Cell.
FIGURE L6.45
A snapshot of the
simulation model for
Raja’s Manufacturing
Cell.
Five locations (Arrive Station, Lathe, Mill 1, Mill 2, and Exit Station) and
three variables (Total_Prod, Total Cost, and Cost_Per_Part) are defined. The pro-
cessing and routing tables are shown in Figure L6.44. A snapshot of the simula-
tion model is shown in Figure L6.45.
FIGURE L6.46
Importing a background for the Raja’s Manufacturing Cell.
2. Select Processing from the Build menu. Use the following statement in
the Operation field when the Pallet Empty arrives at the Pallet Queue
location (Figure L6.50).
Also, use the following statement in the Operation field when the box arrives
at the shipping dock:
View “Full View”
FIGURE L6.47
The Views dialog box.
FIGURE L6.48
Full View of the Shipping Boxes Inc. model.
FIGURE L6.49
General Information
for the Shipping Boxes
Inc. model.
FIGURE L6.50
Processing and routing tables for Shipping Boxes Inc. incorporating the change of views.
read files, arrival files, and shift files). The model package automatically includes
bitmaps imported into the background graphics. The package file can be subse-
quently unpackaged by the receiver to run.
Use the following steps to create a model package:
1. Select Create Model Package from the File menu.
2. Enter the name you wish to use for the model package. ProModel uses
the name of the model file as the default name of the package. So ATM.
mod will be packaged as ATM.pkg. You can also Browse . . . to select the
model name and directory path.
3. Check/uncheck the Exclude Graphics Library box, if you want to
include/exclude the graphics library.
4. Check the Protect Model Data box if you want to protect the data in
your model and prevent other users from changing and even viewing the
model data files. When you load a model package, ProModel disables
the View Text, Print Text, and Expression Search features, plus the Build
menu and portions of the run-time Options and Information menus.
5. Click OK.
Problem Statement
For the Discs-R-Us Manufacturing Inc. in section L6.5, make a model pack-
age that includes the model file and the shift file for thelocations. Name the
model package L6_12ShiftWorkSchedule.pkg (Figure L6.51) and save it on a
USB flash drive.
To unpack and install the model package, double-click on the package file
(on the USB drive). In the Unpack Model Package dialog select the appropriate
destination drive and directory path to install the model file and its associated
FIGURE L6.51
Create Model Package
dialog.
FIGURE L6.52
Unpack and install
Model package.
files (Figure L6.52). We chose the USB drive ( e:\ ) to install the model file, the
associated shift file, and the graphics library. Click OK. After completing the in-
stallation, ProModel prompts you for loading the model. Click Yes.
L6.13 Exercises
1. Five different types of equipment are available for processing a
special type of part for one day (six hours) of each week. Equipment 1
is available on Monday, equipment 2 on Tuesday, and so forth. The
processing time data is shown in Table L6.7.
Assume that parts arrive at a rate of one every 4 1 hours,
including weekends. How many parts are produced each week? How
large a storage area is needed for parts waiting for a machine? Is there a
bottleneck at any particular time? Why?
Time to Process
Equipment Available Day One Part (minutes)
1 Monday 52
2 Tuesday 42
3 Wednesday 3 1.5
4 Thursday 61
5 Friday 51
Haircut Time(min)
Children 8 2
Women 12 3
Men 10 2
choose the first available attendant. Simulate the car wash system for
1,000 service completions (car washes). Answer the following questions:
a. Estimate Ram’s, Shyam’s, and Gopal’s utilization.
b. On average, how long does a customer spend at the car wash?
c. What is the longest time any customer spent at the car wash?
d. What is the average number of customers at the car wash?
Embellishments:
The customers are forced to choose the first available attendant; no
individual preferences are allowed. Will this make a significant enough
difference in the performance of the system to justify this change?
Answer questions a through d to support your argument. Use the Paired-t
confidence interval approach (Lab 9, section L9.4) to compare the two
systems.
9. Amrita is a pharmacist and works at the Save-Here Drugstore. Walk-in
and drive-in customers arrive at a rate of 10 3 and 20 10 minutes
respectively. Drive-in customers are given higher priority than walk-in
customers. The number of items in a prescription varies uniformly from
1 to 5 [U(3,2)]. Amrita can fill one item in 6 1 minutes (uniform
distribution). She works from 8 A.M. until 5 P.M. Monday to Friday. Her
lunch break is from 12 noon until 1 P.M. She also takes two 15-minute
breaks: at 10 A.M. and at 3 P.M. Define a shift file for Amrita named
Amrita.sft. Model the pharmacy for a year and answer the following
questions:
a. Estimate the average time a customer (of each type) spends at the
drugstore.
b. What is the average number of customers (of each type) waiting for
service at the drug store?
c. What is the average number of customers (of each type) in the drug store?
d. What is the utilization of Amrita (percentage of time busy)?
e. Do you suggest that we add another pharmacist to assist Amrita? How
many pharmacists should we add?
f. Is it better to have a dedicated pharmacist for drive-in customers and
another for walk-in customers?
g. Create a package file called SaveHere.pkg that includes the
simulation model file and the shift file Amrita.sft.
10. A production line assembles a product on five workstations in sequence.
Parts arrive to the first workstation at random exponentially distributed
intervals with a mean of seven minutes. Service times at individual
stations are normally distributed (mean of 3 minutes and standard
deviation of 1 minute).
a. Develop a simulation model that collects data for time in the system
for each part. Determine the mean time in the system.
b. Additional analysis shows that products from three different priority
classes are assembled on the line and they appear in random order.
Assemble U(30,5)
Fire U(8,2)
the mean time in the system for all the loan applications. Does it seem
to make a difference to the mean time in the system for all the loan
applications?
14. Two types of jobs (regular and high-priority) arrive at two identical
assembly machines. Regular jobs arrive according to an exponential
distribution with a mean interarrival time of 10 minutes. High-priority jobs
arrive according to an exponential distribution with a mean interarrival
time of 20 minutes. One of the two machines is selected by turn.
Processing on either machine is uniformly distributed U(8,2) minutes.
Upon completion, jobs are sent to a third machine where they wait for
final assembly, which requires 5 minutes, normally distributed with a
standard deviation of 2 minutes. Jobs are selected from the waiting line
for assembly based on the estimated assembly time (jobs with shorter
assembly times having higher priority over jobs with longer assembly
times). Completed jobs are promptly shipped to the customer.
The final assembly machine is unreliable. It fails at intervals that may
be described by an exponential distribution with a mean of 60 minutes.
Repair time is uniformly distributed over the range 10 to 20 minutes.
The high-priority jobs have higher priority over regular jobs in terms of
processing on the three assembly machines. The processing times are
identical for both types of jobs. Simulate for 2,000 hours and determine:
a. Utilization of the three machines.
b. Average time in the shop for both types of jobs.
c. Average number of jobs (regular and high-priority) processed per
hour.
15. A production facility consists of four operations: milling, planing,
drilling, and inspection. There are two mills, a planer, two drills, and
one inspection station.Movement times associated with transfer of
parts between any pair of workstations and from workstations to the
scrap yard are triangularly distributed. The data for arrival, routing, and
processing are shown in Table L6.12.
Seventy percent of the jobs are type I, the others are type II. Type I
jobs arrive in batches of 5. Type II jobs arrive in batches of 10. A whole
batch of jobs is processed and moved together. Type I jobs are served
7 MODEL VERIFICATION
AND VALIDATION
Dew knot trussed yore spell chequer two fined awl yore mistakes.
—Brendan Hills
In this lab we describe the verification and validation phases in the development
and analysis of simulation models. In section L7.1 we describe an inspection and
rework model. In section L7.2 we show how to verify the model by tracing the
events in it. Section L7.3 shows how to debug a model. The ProModel logic, basic
and advanced debugger options are also discussed.
517
FIGURE L7.1
A snapshot of the
simulation model for
Bombay Clothing Mill
showing status lights
for the locations.
FIGURE L7.2
Locations at the Bombay Clothing Mill warehouse.
FIGURE L7.3
Processing and routing tables at the Bombay Clothing Mill.
labeled go back to the Relabel_Q. This type of branching was first introduced in
Lab 4, section L4.6.
We also used status lights for the various locations in this model (Figure L7.1).
A status light is a circle that lights up with different colors depending on the status
of the location. You can place a status light anywhere relative to a location for
showing the status or current state of the location. At run time, you can display
a window showing what status each color represents. For a single-capacity loca-
tion, the states displayed are idle/empty (deep blue), in operation (green), blocked
(pink), down (red), waiting (yellow), and in setup (light blue). For multicapacity
locations, the displayed states are up–operational (blank) and down–off-shift, on
break, disabled (red).
FIGURE L7.4
Trace modes in
ProModel.
FIGURE L7.5
Tracing the simulation model of the Bombay Clothing Mill warehouse.
The trace prompts are displayed at the bottom of the screen as shown in
Figure L7.5. Follow the trace prompts and verify that the model is doing what it is
supposed to be doing. Make sure through visualization and the trace messages that
the rework items are indeed given higher priority than the first-time items. Also,
from the garment and relabel queue contents shown in Figure L7.6, notice that the
relabel queue is always quite small, whereas the garment queue grows quite big at
times (as a result of it lower priority for the labeling operation).
FIGURE L7.6
Plots of garment and relabel queue contents averaged by hour.
FIGURE L7.7
The ProModel
Debugger menu.
within the model code or from the Options menu (Figure L7.4) during run time.
The system state can be monitored to see exactly when and why things occur.
Combined with the Trace window, which shows the events that are being sched-
uled and executed, the debugger enables a modeler to track down logic errors or
bugs in the model.
FIGURE L7.8
Debugger options
menu.
Global changes and user specified conditions can be tracked using the
Debugger options menu (Figure L7.8). The user conditions can be checked—
before each statement, at each thread switch, or at each thread initiation.
For example, for the ElSegundo Composites, from Lab 5, section L5.6.1,
suppose the GROUP quantity has been typed as 50 (typo) instead of 5. A debug
statement IF THREADNUM () > 30 THEN DEBUG has been added to the operation
logic at the Oven location that causes the error, as shown in Figure L7.9. The
simulation will run until the proper process and then bring up the debugger (Fig-
ure L7.10). The debugger can then be used to step through the process to find out
the particular statement causing the error.
FIGURE L7.9
An example of a DEBUG statement in the processing logic.
FIGURE L7.10
The Debugger window.
• Error display box: Displays the error message or reason why the
debugger is displayed, such as the user condition becoming true.
• Logic display box: Displays the statements of the logic being executed.
• Information box: Displays either the context of the logic or local
information.
• Context: Displays the module, operation, and line number in which the
debugger stopped.
• Local information: Displays local variables and entity attributes with
nonzero values for the thread in the information box.
• End Simulation: Choose this option to terminate simulation. This will
prompt for whether or not you would like to collect statistics.
• Run: Continues the simulation, but still checks the debugger options
selected in the Debugger Options dialog box.
• Next Statement: Jumps to the next statement in the current logic. Note
that if the last statement executed suspends the thread (for example, if the
entity is waiting to capture a resource), another thread that also meets
the debugger conditions may be displayed as the next statement.
• Next Thread: Brings up the debugger at the next thread that is initiated or
resumed.
• Into Subroutine: Steps to the first statement in the next subroutine
executed by this thread. Again, if the last statement executed suspends
the thread, another thread that also meets debugger conditions may be
displayed first. If no subroutine is found in the current thread, a message
is displayed in the Error Display box.
• Options: Brings up the Debugger Options dialog box. You may also bring
up this dialog box from the Simulation menu.
• Advanced: Changes the debugger to the advanced mode.
FIGURE L7.11
The ProModel
Advanced Debugger
options.
• New: Jumps over any resumed threads to the next initiated thread that is
not executing the same logic as the current thread. This will automatically
jump to a new thread.
• Disable: Temporarily disables the debugger for all threads executing the
current logic.
• Exclusive: The debugger displays only the statements executed in any
thread that are an instance of the current logic.
Enable disabled threads and logic: Enables the threads and logics that were
disabled previously.
For more information and detailed examples of how to use the various debugger
options, consult the online ProModel Help System.
L7.4 Exercises
1. For the example in section L7.1, insert a DEBUG statement when a garment
is sent back for rework. Verify that the simulation model is actually sending
back garments for rework to the location named Label_Q.
2. For the example in section L4.1 (Pomona Electronics), trace the model
to verify that the type B circuit boards are indeed following the routing
given in Table L4.1.
3. For the example in section L4.5 (SoCal Casting Inc.), run the simulation
model and launch the debugger from the Options menu. Turn on the
Local Information in the Basic Debugger. Verify the values of the
variables WIP and PROD_QTY. Use status lights for the Mill, Grinder,
and the Finish Parts Store to verify the operating, idle, and blocked status
for these locations.
4. For the example in section L4.4 (Bank of India), trace the model to
verify that successive customers are in fact being served by the three
tellers in turn.
5. For the example in section L4.8.1 (Shipping Boxes Unlimited), trace
the model to verify that monitors are indeed being packed (joined) into
boxes at the Packing_Table location.
6. For the example in section L4.8.2 (Shipping Boxes Unlimited), trace
the model to verify that the full boxes are in fact being loaded on empty
pallets at the Inspector location and are being unloaded at the Shipping
location.
7. For the example in section L4.11.1 (Bombay Restaurant), trace the
model to verify that customers are in fact leaving and going away when
there are six or more cars at the restaurant. Use status lights for all the
single capacity locations to verify the operating and idle status for these
locations.
8. For the example in section L4.11.2 (Shipping Boxes Unlimited), trace
the model to verify that the inspector is indeed only inspecting when at
least five or more full boxes are waiting in the Inspect_Q for inspection.
8 SIMULATION OUTPUT
ANALYSIS
Nothing has such power to broaden the mind as the ability to investigate
systematically and truly all that comes under thy observation in life.
—Marcus Aurelius
527
FIGURE L8.1
Layout of the Spuds-
n-More simulation
model.
is compared to the number of entities allowed into the Order_Q (see Move Logic).
If Processed Arrivals, then all entities that were allowed into the Order_Q have
been processed and the simulation is terminated by the Stop statement. Notice that
the combined capacity of the Entry and Order_Q locations is five in order to sat-
isfy the requirement that the waiting area in front of the restaurant accommodates
up to five customers.
L8.2.2 Replications
Run the simulation for five replications to record the number of customers served
each day for five successive days. To run the five replications, select Options from
under the Simulation main menu. Figure L8.3 illustrates the simulation options
set to run five replications of the simulation. Notice that no run hours are speci-
fied. After ProModel runs the five replications, it displays a message asking if you
wish to see the results. Answer yes.
In the Output Viewer, select Variable Summary from the Tables menu (Fig-
ure L8.4). From the Filter panel on the left, select <All> for Replications and
for Statistics select Average, Standard Deviation and 90 Percent Confidence
Interval to specify that you wish the output report to also include the sample
mean (average), sample standard deviation, and 90 percent confidence interval
of the five observations collected via the five replications (Figure L8.5).
FIGURE L8.2
The simulation model of Spuds-n-More.
The ProModel output report for variables is shown in Figure L8.6. The
number of customers processed each day can be found under the Current Value
column. The simulation results indicate that the number of customers processed
each day fluctuates randomly. The fluctuation may be attributed to variations in
processing times or customer arrivals. It is obvious that we cannot reliably use
the observation from a single day’s simulation to estimate the expected number
of customers served each day. The results from a single day could produce an es-
timate as small as 59 or as large as 67. Either value could be a very poor estimate
of the true expected number of customers served each day.
FIGURE L8.3
ProModel’s Simulation
Options window set to
run five replications of
the simulation.
FIGURE L8.4
Selecting variable
summary statistics
from the ProModel
Output Viewer.
The average number of customers processed over the five days is computed
_
as x 62.20 (Figure L8.6). This provides a much better point estimate of the ex-
pected daily service rate (number of customers processed each day), but it fails to
capture any information on the variability of our estimate. The sample deviation
of s 3.27 customers per day provides that information. The most valuable piece
of information is the 90 percent confidence interval computed by ProModel using
FIGURE L8.5
Statistical Options in
Output Viewer set to
the average standard
deviation, and
90 percent confidence
interval.
FIGURE L8.6
ProModel output report for five replications of the Spuds-n-More simulation.
the sample mean and sample standard deviation. With approximately 90 percent
confidence, the true but unknown mean number of customers processed per day
falls between 59.08 and 65.32 customers. These results convince Mr. Taylor that
the model is a valid representation of the actual restaurant, but he wants to get a
better estimate of the number of customers served per day.
n ______
e
(Z/2)s 2
______
e
(t,/2)s 2 (1.645)3.27 2
__________ 7.23 replications
2.0
The value of 7.23 is appropriately rounded up to 8 replications. The n 8 pro-
vides a rough approximation of the number of replications that are needed to
achieve the requested error amount e 2.0 customers at the 0.10 significance
level. Running an additional three replications of the Spuds-n-More baseline sim-
ulation and combining the output with the output from the original five replica-
tions produces a sample mean of 61.50 customers and an approximate 90 percent
confidence interval of 58.99 to 64.01 customers. You should verify this. Although
the confidence interval half-width of 2.51 customers is larger than the target value
of 2.0 customers, it is smaller than the half-width of the confidence interval based
on five replications. We could keep running additional replications to get closer to
the target half-width of 2.0 customers if we like.
FIGURE L8.7
Exporting a ProModel output report into Microsoft Excel.
pick 100 just because it is a round number and we can quickly generate them by con-
figuring ProModel to run 100 replications of the simulation. Try this now and open
the Variable Summary output report from the Tables menu when the simulation ends.
Notice that you get a very small confidence interval with this many observations.
It would take a while to enter the 100 observations into Stat::Fit one at a time. A
faster method is to export the ProModel output report with the results from the 100
replications into Microsoft Excel (MS). From MS Excel, copy the observations into a
Stat::Fit data table. To do this, select Summary Data from the Export menu and export
the file to MS Excel (Figure L8.7). Open the MS Excel file and select the Variable
Summary Worksheet (Figure L8.8). From MS Excel, highlight the 100 Current Value
observations of the Processed variable—making sure not to include the average, stan-
dard deviation, 90% C.I. Low, and 90% C.I. High values (the last four values in the
column)—and paste the 100 observations into a Stat::Fit data table (Figure L8.9).
After the 100 observations are pasted into the Stat::Fit Data Table, display a
histogram of the data. Based on the histogram, the observations appear somewhat
normally distributed (Figure L8.9). Furthermore, Stat::Fit estimates that the nor-
mal distribution with mean 59.30 and standard deviation 4.08 provides
an acceptable fit to the data. Therefore, we probably could have dropped the word
“approximate” when we presented our confidence interval to Mr. Taylor. Be sure
to verify all of this for yourself using the software.
Note that if you were to repeat this procedure in practice because the problem
requires you to be as precise and as sure as possible in your conclusions, then you
would report your confidence interval based on the larger number of observations.
Never discard precious data.
Before leaving this section, go to the ProModel Entity Failed Arrivals output
report. The Total Failed column in the Failed Arrivals section of the output report
indicates the number of customers that arrived to eat at Spuds-n-More but left
FIGURE L8.8
The ProModel output
report exported into
a Microsoft Excel
spreadsheet.
because the waiting line was full. Mr. Taylor thinks that his proposed expansion
plan will allow him to capture some of the customers he is currently losing. In
Lab Chapter 9, we will add embellishments to the as-is simulation model to reflect
Mr. Taylor’s expansion plan to see if he is right.
FIGURE L8.9
Stat::Fit analysis of the 100 observations of the number of customers processed per day
by Spuds-n-More.
happens, the simulation has reached a steady-state condition. Although the simula-
tion’s output will continue to be random, the statistical distribution of the simula-
tion’s output does not change after the simulation reaches steady state.
The period during which the simulation is in the transient phase is known as the
warm-up period. This is the amount of time to let the simulation run before gather-
ing statistics. Data collection for statistics begins at the end of the warm-up and
continues until the simulation has run long enough to allow all simulation events
(even rare ones) to occur many times (hundred to thousands of times if practical).
Problem Statement
A simulation model of the Green Machine Manufacturing Company (GMMC)
owned and operated by Mr. Robert Vaughn is shown in Figure L8.10. The interar-
rival time of jobs to the GMMC is constant at 1.175 minutes. Jobs require pro-
cessing by each of the four machines. The processing time for a job at each green
machine is given in Table L8.2.
A plentiful amount of storage is provided for waiting jobs in front of each
of the green machines. Our task is to conduct a nonterminating simulation to
estimate the time-average amount of work-in-process (WIP) inventory (the
FIGURE L8.10
The layout of the Green Machine Manufacturing Company simulation model.
FIGURE L8.11
The simulation model of the Green Machine Manufacturing Company.
FIGURE L8.12
Work-in-process (WIP)
inventory value history
for one replication
of the GMMC
simulation. (a) WIP
value history without
warm-up phase
removed. Statistics
will be biased low
by the transient WIP
values. (b) WIP value
history with 100- (a)
hour warm-up phase
removed. Statistics will
not be biased low.
(b)
as illustrated in Figure L8.12(a), and then visually determine the point at which
the initial transient phase is over. In this example, it seems that the transient phase
created by the initial condition of zero WIP inventory is over at around 20 hours.
Usually you will want to select a value beyond this to guard against underestimat-
ing the end of the warm-up phase. So we will pick 100 hours as the end of the
warm-up. Actually, you should not make this decision based on the output from
one replication of the simulation. We are doing this here to quickly illustrate the
need for allowing the model to warm up. We will use the preferred method to
estimate the end of the warm-up phase in a moment.
In most nonterminating simulation models, the quality of the results substan-
tially improves if we throw away the output generated during the warm-up phase
of the simulation. In Figure L8.12(a), the observations during the transient phase
of the first 100 hours of the simulation are alleged to be artificially low. As such,
we do not want them to bias our estimate of the time-average WIP inventory.
Therefore, in our next run of the GMMC simulation, we specify a warm-up time
of 100 hours (Figure L8.13). Notice how the simulation output during the 100-hour
warm-up has been discarded in Figure L8.12(b). The discarded output will no
longer affect the observations reported in the simulation output.
FIGURE L8.13
ProModel’s Simulation
Options window set
for a single replication
with a 100-hour
warm-up period
followed by a
150-hour run length.
The simplified process we just used to identify the end of the warm-up phase
should be avoided. The process can be substantially improved by running multiple
replications of the simulation and then combining the time-series output from
each replication into an average time-series plot. Averaging the time-series data
from multiple replications together will help filter out the large fluctuations (high
values from one replication are offset by small values from another replication)
and will give you a better estimate of the true but unknown time-series output.
In many cases, you may need to add an additional layer of filtering to smooth
the “averaged” time-series plot. This can be done by computing a Welch moving
average of the time-series data. Section 8.6.1 of Chapter 8 provides additional
details on this subject, and exercise 4 in Lab Chapter 10 illustrates how to use the
Welch method implemented in SimRunner.
Figure L8.14 was produced by SimRunner by recording the time-average
WIP levels of the GMMC simulation over successive one-hour time periods. The
results from each period were averaged across five replications to produce the
“raw data” plot, which is the more erratic line that appears red on the computer
screen. A 54-period moving average (the smooth line that appears green on the
computer) indicates that the end of the warm-up phase occurs between the 33rd
and 100th periods. Given that we need to avoid underestimating the warm-up,
let’s declare 100 hours as the end of the warm-up time. We feel much more com-
fortable basing our estimate of the warm-up time on five replications. Notice that
SimRunner indicates that at least 10 replications are needed to estimate the aver-
age WIP to within a 7 percent error and a confidence level of 90 percent using a
warm-up of 100 periods (hours). You will see how this was done with SimRunner
in Exercise 4 of section L10.4 in Lab Chapter 10.
FIGURE L8.14
SimRunner screen for estimating the end of the warm-up time.
Why did we choose an initial run length of 250 hours to produce the time-
series plot in Figure L8.14? Well, you have to start with something, and we picked
250 hours. You can rerun the experiment with a longer run length if the time-
series plot, produced by averaging the output from several replications of the
simulation, does not indicate a steady-state condition. Long runs will help pre-
vent you from wondering what the time-series plot looks like beyond the point
at which you stopped it. Do you wonder what our plot does beyond 250 hours?
Let’s now direct our attention to answering the question of how long to run
the model past its warm-up time to estimate our steady-state statistic, mean WIP
inventory. We will somewhat arbitrarily pick 100 hours not because that is equal
to the warm-up time but because it will allow ample time for the simulation events
to happen thousands of times. In fact, the 100-hour duration will allow approxi-
mately 5,100 jobs to be processed per replication, which should give us decently
accurate results. How did we derive the estimate of 5,100 jobs processed per
FIGURE L8.15
Specification of
warm-up hours and
run hours in the
Simulation Options
menu for running
replications.
FIGURE L8.16
Ten replications of the Green Machine Manufacturing Company simulation using a 100-hour
warm-up and a 100-hour run length.
FIGURE L8.17
Warm-up hours, run
hours, and batch
interval length in the
Simulation Options
menu for running
batch intervals. Note
that the time units are
specified on the batch
interval length.
FIGURE L8.18
Ten batch intervals of the Green Machine Manufacturing Company simulation using a
100-hour warm-up and a 100-hour batch interval length.
would produce the output in Figure L8.18. To get the output report to display the
results of all 10 batch intervals, you specify “<All>” Periods in the Report selec-
tion settings panel. We are approximately 90 percent confident that the true but
unknown mean WIP inventory is between 18.88 and 23.19 jobs. If we desire a
smaller confidence interval, we can increase the sample size by extending the run
length of the simulation in increments of the batch interval length. For example,
we would specify run hours of 1500 to collect 15 observations of average WIP
inventory. Try this and see if the confidence interval becomes smaller. Note that
increasing the batch interval length is also helpful.
FIGURE L8.19
Stat::Fit Autocorrelation plot of the observations collected over 100 batch intervals.
Lag-1 autocorrelation is within the –0.20 to 0.20 range.
21.04 (Batch 1)
19.40 (Batch 2)
21.12 (Batch 3)
20.29 (Batch 4)
20.33 (Batch 5)
20.41 (Batch 6)
22.38 (Batch 7)
22.02 (Batch 8)
19.93 (Batch 9)
22.23 (Batch 10)
20.92 (Average)
1.02 (Std. Dev.)
20.32 (90% C.I. Low)
21.51 (90% C.I. High)
this range of lag values, the highest autocorrelation is 0.192 and the lowest value
is 0.132 (see correlation (0.192, 0.132) at the bottom of the plot). Therefore,
we know that the lag-1 autocorrelation is within the 0.20 to 0.20 range rec-
ommended in section 8.6.2 of Chapter 8, which is required before proceeding to
the final step of “rebatching” the data into between 10 and 30 larger batches. We
have enough data to form 10 batches with a length of 1000 hours (10 batches at
1000 hours each equals 10,000 hours of simulation time, which we just did). The
results of “rebatching” the data in the Microsoft Excel spreadsheet are shown in
Table L8.3. Note that the first batch mean of 21.037 in Table L8.3 is the average
of the first 10 batch means that we originally collected. The second batch mean of
19.401 is the average of the next 10 batch means and so on. The confidence inter-
val is very narrow due to the long simulation time (1000 hours) of each batch. The
owner of GMMC, Mr. Robert Vaughn, should be very pleased with the precision
of the time-average WIP inventory estimate.
The batch interval method requires a lot of work to get it right. Therefore, if
the time to simulate through the warm-up period is relatively short, the replica-
tions method should be used. Reserve the batch interval method for simulations
that require a very long time to reach steady state.
L8.4 Exercises
1. An average of 100 customers per hour arrive to the Picayune Mutual
Bank. It takes a teller an average of two minutes to serve a customer.
Interarrival and service times are exponentially distributed. The bank
currently has four tellers working. Bank manager Rich Gold wants to
compare the following two systems with regard to the average time
customers spend in the bank.
System #1
A separate queue is provided for each teller. Assume that customers
choose the shortest queue when entering the bank, and that customers
cannot jockey between queues (jump to another queue).
System #2
A single queue is provided for customers to wait for the first available
teller.
Assume that there is no move time within the queues. Run 15
replications of an eight-hour simulation to complete the following:
a. For each system, record the 90 percent confidence interval using a
0.10 level of significance for the average time customers spend in the
bank.
b. Estimate the number of replications needed to reduce the half-
width of each confidence interval by 25 percent. Run the additional
replications for each system and compute new confidence intervals
using a 0.10 level of significance.
c. Based on the results from part b, would you recommend one system
over the other? Explain.
2. Rerun the simulation of the Green Machine Manufacturing Company of
Section L8.3 to produce 100 batch means with a 50-hour interval length.
Use a 100-hour warm-up. Check the lag-1 autocorrelation of the 100 time-
average WIP observations to see if it falls between ⫺0.20 and ⫹0.20. If
it does not, increase the batch interval length by 50 percent and continue
the process until an acceptable lag-1 autocorrelation is achieved. Once the
lag-1 autocorrelation is acceptable, check to see if the 100 observations
are normally distributed. After that, rebatch the 100 observations into
20 batch means and compute a 95 percent confidence interval. Are you
comfortable with the resulting confidence interval? Explain.
3. Use the simulation model created for the DumpOnMe facility presented
in Exercise 11 of Lab 4 section L4.13 to complete the following:
a. For a simulation run length of 60 minutes, record the 90 percent
confidence interval for the scale’s average utilization based on
30 replications.
b. For a 60-minute warm-up and a 60-minute simulation run length
beyond the warm-up time, record the 90 percent confidence interval
for the scale’s average utilization based on 30 replications.
c. Based only on the two confidence intervals, do you think that a
warm-up period is necessary for the DumpOnMe model? Explain.
4. See Lab Chapter 10 for exercises involving the use of SimRunner’s
implementation of the Welch moving average technique.
9 COMPARING
ALTERNATIVE SYSTEMS
In this lab we see how ProModel is used with some of the statistical methods
presented in Chapter 9 to compare alternative designs of a system with the goal
of identifying the superior system relative to some performance measure. We will
also learn how to program ProModel to use common random numbers (CRN)
to drive the simulation models that represent alternative designs for the systems
being compared. The use of CRN allows us to run the opposing simulations
under identical experimental conditions to facilitate an objective evaluation of
the systems.
549
Chapter 9 covers the paired-t confidence interval method and the Welch
confidence interval method for testing hypotheses about two alternatives. The
Bonferroni approach is used for comparing from three to about five alternatives.
Either the Welch method or paired-t method is used with the Bonferroni approach
to make the comparisons. The Bonferroni approach does not identify the best al-
ternative but rather identifies which pairs of alternatives perform differently. This
information is helpful for identifying the better alternatives, if in fact there is a
significant difference in the performance of the competing alternatives.
Chapter 9 recommends that the technique of analysis of variance (ANOVA)
be used when more than about five alternative system designs are being com-
pared. The first step in ANOVA is to evaluate the hypothesis that the mean perfor-
mances of the systems are equal against the alternative hypothesis that at least one
pair of the means is different. To figure out which means differ from which other
ones, a multiple comparison test is used. There are several multiple comparison
tests available, and Chapter 9 presents the Fisher’s protected least significant dif-
ference (LSD) test.
The decision to use paired-t confidence intervals, Welch confidence inter-
vals, the Bonferroni approach, or ANOVA with protected LSD depends on the
statistical requirements placed on the data (observations from the simulations) by
the procedure. In fact, simulation observations produced using common random
numbers (CRN) cannot be used with the Welch confidence interval method or the
technique of ANOVA. Please see Chapter 9 for details.
In this lab we will use the paired-t confidence interval method because it
places the fewest statistical requirements on the observations collected from the
simulation model. Therefore, we are less likely to get into trouble with faulty as-
sumptions about our data (observations) when making decision based on paired-
t confidence intervals. Furthermore, one of the main purposes of this lab is to
demonstrate how the CRN technique is implemented using ProModel. Out of the
comparison procedures of Chapter 9, only the ones based on paired-t confidence
intervals can be used in conjunction with the CRN technique.
Spuds-n-More. Mr. Taylor closes the entry to the waiting area in front of his res-
taurant after eight hours of operation. However, any customers already in the wait-
ing area by closing time are served before the kitchen shuts down for the day.
Mr. Taylor is thinking about expanding into the small newspaper stand next
to Spuds-n-More, which has been abandoned. This would allow him to add a
second window to serve his customers. The first window would be used for taking
orders and collecting payments, and the second window would be used for filling
orders. Before investing in the new space, however, Mr. Taylor needs to convince
the major stockholder of Spuds-n-More, Pritchard Enterprises, that the invest-
ment would allow the restaurant to serve more customers per day.
A baseline (as-is) model of the current restaurant configuration was devel-
oped and validated in Section L8.2 of Lab Chapter 8. See Figures L8.1 and L8.2
for the layout of the baseline model and the printout of the ProModel model.
Our task is to build a model of the proposed restaurant with a second window to
determine if the proposed design would serve more customers per day than does
the current restaurant. Let’s call the baseline model Spuds-n-More1 and the pro-
posed model Spuds-n-More2. The model is found in the Student folder installed
with ProModel.
The ProModel simulation layout of Spuds-n-More2 is shown in Figure L9.1,
and the ProModel printout is given in Figure L9.2. After customers wait in the
order queue (location Order_Q) for their turn to order, they move to the first win-
dow to place their orders and pay the order clerk (location Order_Clerk). Next
customers proceed to the pickup queue (location Pickup_Q) to wait for their turn
FIGURE L9.1
Layout of Spuds-n-
More2 simulation
model.
FIGURE L9.2
The Spuds-n-More2 simulation model.
FIGURE L9.3
Unique random number streams assigned to the Spuds-n-More model.
FIGURE L9.4
ProModel’s Simulation
Options set to run
25 replications using
Common Random
Numbers.
each restaurant design for 25 replications using the CRN option are shown in
Table L9.1.
The Bonferroni approach with paired-t confidence intervals is used to evaluate
our hypotheses for the three alternative designs for the restaurant. The evaluation
of the three restaurant designs requires that three pairwise comparisons be made:
Spuds-n-More1 vs. Spuds-n-More2
Spuds-n-More1 vs. Spuds-n-More3
Spuds-n-More2 vs. Spuds-n-More3
Following the procedure described in Section 9.4.1 of Chapter 9 for the
Bonferroni approach, we begin constructing the required three paired-t confi-
dence intervals by letting 1 2 3 /3 0.06/3 0.02.
The computation of the three paired-t confidence intervals follows:
(t24,0.01)s(12) (2.485)4.66
hw __________
冑n
__ __________
___
冑25 2.32 customers
TABLE L9.1 Comparison of the Three Restaurant Designs Based on Paired Differences
1 60 72 75 12 15 3
2 57 79 81 22 24 2
3 58 84 88 26 30 4
4 53 69 72 16 19 3
5 54 67 69 13 15 2
6 56 72 74 16 18 2
7 57 70 71 13 14 1
8 55 65 65 10 10 0
9 61 84 84 23 23 0
10 60 76 76 16 16 0
11 56 66 70 10 14 4
12 66 87 90 21 24 3
13 64 77 79 13 15 2
14 58 66 66 8 8 0
15 65 85 89 20 24 4
16 56 78 83 22 27 5
17 60 72 72 12 12 0
18 55 75 77 20 22 2
19 57 78 78 21 21 0
20 50 69 70 19 20 1
21 59 74 77 15 18 3
22 58 73 76 15 18 3
23 58 71 76 13 18 5
24 56 70 72 14 16 2
25 53 68 69 15 16 1
_
Sample mean x(ii), for all i and i between 1 and 3, with i i 16.20 18.28 2.08
Sample standard dev s(ii), for all i and i between 1 and 3, with i i 4.66 5.23 1.61
(t24,0.01__)s(13) __________
(2.485)5.23
hw _________ ___ 2.60 customers
冑n 冑25
The approximate 98 percent confidence interval is
_ _
x(13) hw µ(13) x(13) hw
18.28 2.60 µ(13) 18.28 2.60
20.88 µ(13) 15.68
TABLE L9.2 Shopping and Checkout Times for Customers at Apna Bazaar
FIGURE L9.5
A snapshot of the Apna
Bazaar supermarket
Simulation Model.
1 −1 −1 −1 −1 1 1 1 1 1 1 −1 −1 −1 −1 1
2 −1 −1 −1 1 1 1 −1 1 −1 −1 −1 1 1 1 −1
3 −1 −1 1 −1 1 −1 1 −1 1 −1 1 −1 1 1 −1
4 −1 −1 1 1 1 −1 −1 −1 −1 1 1 1 −1 −1 1
5 −1 1 −1 −1 −1 1 1 −1 −1 1 1 1 1 −1 −1
6 −1 1 −1 1 −1 1 −1 −1 1 −1 1 −1 −1 1 1
7 −1 1 1 −1 −1 −1 1 1 −1 −1 −1 1 −1 1 1
8 −1 1 1 1 −1 −1 −1 1 1 1 −1 −1 1 −1 −1
9 1 −1 −1 −1 −1 −1 −1 1 1 1 1 1 −1 1 −1
10 1 −1 −1 1 −1 −1 1 1 −1 −1 1 −1 1 −1 1
11 1 −1 1 −1 −1 1 −1 −1 1 −1 −1 1 1 −1 1
12 1 −1 1 1 −1 1 1 −1 −1 1 −1 −1 −1 1 −1
13 1 1 −1 −1 1 −1 −1 −1 −1 1 −1 −1 1 1 1
14 1 1 −1 1 1 −1 1 −1 1 −1 −1 1 −1 −1 −1
15 1 1 1 −1 1 1 −1 1 −1 −1 1 −1 −1 −1 −1
16 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
FIGURE L9.6
Pareto Chart of
Half-Effects of
Input Factors—Full
Factorial Design
Input Significant
Factors Abs(delta) MSB Feffect @95%
MSE 419.269
Fcritical(0.95,1,64) 3.99
1 1 1 1 1 1 1 1
2 1 1 1 1 1 1 1
3 1 1 1 1 1 1 1
4 1 1 1 1 1 1 1
5 1 1 1 1 1 1 1
6 1 1 1 1 1 1 1
7 1 1 1 1 1 1 1
8 1 1 1 1 1 1 1
factorial experiment are shown in Table L9.8. Figure L9.7 shows a Pareto chart
for the absolute values of the half-effects of all the input factors and their inter-
actions. It is interesting to note that factors D (customer arrival frequency), A
(number of shopping carts), and the AD interaction are most important in having
an effect on the customer time in the system (grocery store). An analysis of vari-
ance (ANOVA) was performed to determine which factor effects and/or interac-
tions are significant. The ANOVA results for the fraction factorial experiment
are shown in Table L9.9. The analysis of variance confirms what we had already
concluded from observing the Pareto chart. Factors D, A, and the AD interaction
are significant at 0.95 percent. Factors C and B and interactions AB, CD, AC,
and BD are all insignificant. We have arrived at very similar conclusions using a
fraction factorial design with only half the effort (8 runs
5 replications each
40 experiments) what we had concluded after running the full-factorial experi-
ment (16 runs
5 replications each 80 experiments).
FIGURE L9.7
Pareto Chart of
Half-Effects of Input
Factors—Fraction
Factorial Design.
MSE 32332.49
Fcritical(0.95,1,32) 4.149
L9.6 Exercises
1. Without using the Common Random Numbers (CRN) technique,
compare the Spuds-n-More1, Spuds-n-More2, and Spuds-n-More3
models with respect to the average number of customers served per
day. To avoid the use of CRN, assign ProModel Stream 1 to each
stochastic element in the model and do not select the CRN option from
the Simulation Options menu. Simulate each of the three restaurants for
25 replications.
a. Use the Bonferroni approach with an overall significance level of
0.06, and construct the confidence intervals using the paired-t method.
How do the half-widths of the confidence intervals compare to the
ones computed in section L9.4? Are the differences in half-widths
what you expected? Explain.
Number of operators 1 3
Capacity of Receive Location 2 4
Capacity of Loc1 1 5
Capacity of Degrease 2 4
Bearing Queue 20 100
Number of Pallets 2 6
TABLE L9.11 Input Factors for the Tube Distribution Supply Chain Model
Experiment
Capacity of Scrapln 5 15
Capacity of FurnaceQ 5 10
Capacity of Furnace 5 10
Capacity of Insp1 5 15
Number of Units—Transport1 1 3
Number of Units—Transport2 1 3
Number of Units—Transport3 1 3
Number of Units—Transport4 1 3
Number of Units—Transport5 1 3
TABLE L9.12 Input Factors for the Order Processing Simulation Model
Experiment
Capacity of Rework 1 4
Design—Number of Units 1 3
Review—Number of Units 1 3
Produce Drawings—Number of Units 1 3
Production Bob 1 3
10 SIMULATION OPTIMIZATION
WITH SIMRUNNER
569
FIGURE L10.1
Relationship between
SimRunner’s
optimization Optimization
Simulation
algorithms and
ProModel simulation
model.
Algorithms
Optimization
Input Factors
Step 2. Create a new SimRunner project and select the input factors you wish
to test. For each input factor, define its numeric data type (integer or real) and its
lower bound (lowest possible value) and upper bound (highest possible value).
SimRunner will generate solutions by varying the values of the input factors ac-
cording to their data type, lower bounds, and upper bounds. Care should be taken
when defining the lower and upper bounds of the input factors to ensure that a
combination of values will not be created that leads to a solution that was not
envisioned when the model was built.
Step 3. After selecting the input factors, define an objective function to measure
the utility of the solutions tested by SimRunner. The objective function is built
using terms taken from the output report generated at the end of the simulation
run. For example, the objective function could be based on entity statistics, loca-
tion statistics, resource statistics, variable statistics, and so forth. In designing the
objective function, the user specifies whether a term is to be minimized or maxi-
mized as well as the overall weighting of that term in the objective function. Some
terms may be more important than other terms to the decision maker. SimRunner
also allows you to seek a target value for an objective function term.
Step 4. Select the optimization profile and begin the search by starting the
optimization algorithms. The optimization profile sets the size of the evolution-
ary algorithm’s population. The population size defines the number of solutions
FIGURE L10.2
Generally, the larger the size of the population the better the result.
Max f(x)
Cautious
Moderate
Aggressive
Time
Step 5. Study the top solutions found by SimRunner and pick the best. SimRunner
will show the user the data from all experiments conducted and will rank each so-
lution based on its utility, as measured by the objective function. Remember that
the value of an objective function is a random variable because it is produced from
the output of a stochastic simulation model. Therefore, be sure that each experi-
ment is replicated an appropriate number of times during the optimization.
Another point to keep in mind is that the list of solutions presented by Sim-
Runner represents a rich source of information about the behavior, or response
surface, of the simulation model. SimRunner can sort and graph the solutions
many different ways to help you interpret the “meaning” of the data.
FIGURE L10.3
The ideal production Ideal Production System
system for Prosperity
Company. Milling Machine
FIGURE L10.4
ProModel model of Prosperity Company.
FIGURE L10.5
Relationship between
the mean processing Response Surface
time and the mean
number of entities
waiting in the queue 100
given a mean time 90 Location (Queue) Contents
between arrivals of 80
three.
No. in Queue
70
60
50
40
30
20
10
0
-10
0 1.5 3
Process Time
FIGURE L10.6
ProModel macro editor.
we can minimize the average number of plates waiting in the queue by setting the
mean processing time of the milling machine to zero minutes, which of course is a
theoretical value. For complex systems, you would not normally know the answer
in advance, but it will be fun to see how SimRunner moves through this known
response surface as it seeks the optimal solution.
The first step in the five-step process for setting up a SimRunner project
is to define the macros and their Run-Time Interface (RTI) in the simulation
model. In addition to defining ProcessTime as a macro (Figure L10.6), we shall
also define the time between arrivals (TBA) of plates to the system as a macro to
be used later in the second scenario that management has asked us to look into.
The identification for this macro is entered as TBA. Be sure to set each macro’s
“Text . . .” value as shown in Figure L10.6. The Text value is the default value
of the macro. In this case, the default value for ProcessTime is 2 and the default
value of TBA is 3. If you have difficulty creating the macros or their RTI, please
see Lab Chapter 11, section L11.1.
Next we activate SimRunner from ProModel’s Simulation menu. SimRunner
opens in the Setup Project mode (Figure L10.7). The first step in the Setup Project
module is to select a model to optimize or to select an existing optimization project
FIGURE L10.7
The opening SimRunner screen.
(the results of a prior SimRunner session). For this scenario, we are optimizing
a model for the first time. Launching SimRunner from the ProModel Simulation
menu will automatically load the model you are working on into SimRunner. See
the model file name loaded in the box under “Create new project—Select model”
in Figure L10.7. Note that the authors named their model ProsperityCo.Mod.
With the model loaded, the input factors and objective function are defined
to complete the Setup Project module. Before doing so, however, let’s take a mo-
ment to review SimRunner’s features and user interface. After completing the
Setup Project module, you would next run either the Analyze Model module or
the Optimize Model module. The Analyze Model module helps you determine
the number of replications to run to estimate the expected value of performance
measures and/or to determine the end of a model’s warm-up period using the
techniques described in Chapter 8. The Optimize Model module automatically
seeks the values for the input factors that optimize the objective function using
the techniques described in Chapter 10. You can navigate through SimRunner by
FIGURE L10.8
Single term objective function setup for scenario one.
selecting items from the menus across the top of the window and along the left
side of the window or by clicking the <Previous or Next> buttons near the bottom
right corner of the window.
Clicking the Next> button takes you to the section for defining the objective
function. The objective function, illustrated in Figure L10.8, indicates the desire to
minimize the average contents (in this case, plates) that wait in the location called
InputPalletQue. The InputPalletQue is a location category. Therefore, to enter this
objective, we select Location from the Response Category list under Performance
Measures by clicking on Location. This will cause SimRunner to display the list
of location statistics in the Response Statistic area. Click on the response statistic
InputPalletQue—AverageContents and then press the button below with the down
arrows. This adds the statistic to the list of response statistics selected for the objec-
tive function. The default objective for each response statistic is maximize. In this
example, however, we wish to minimize the average contents of the input pallet
queue. Therefore, click on Location:Max:1*InputPalletQue—AverageContents,
which appears under the area labeled Response Statistics Selected for the Objec-
tive Function; change the objective for the response statistic to Min; and click the
Update button. Note that we accepted the default value of one for the weight of
the factor. Please refer to the SimRunner Users Guide if you have difficulty per-
forming this step.
Clicking the Next> button takes you to the section for defining the input
factors. The list of possible input factors (macros) to optimize is displayed at the
top of this section under Macros Available for Input (Figure L10.9). The input
factor to be optimized in this scenario is the mean processing time of the milling
machine, ProcessTime. Select this macro by clicking on it and then clicking the
button below with the down arrows. This moves the ProcessTime macro to the
list of Macros Selected as Input Factors (Figure L10.9). Next, indicate that you
want to consider integer values between one and five for the ProcessTime macro.
Ignore the default value of 2.00. If you wish to change the data type or lower and
upper bounds, click on the input factor, make the desired changes, and click the
Update button. Please note that an input factor is designated as an integer when
FIGURE L10.9
Single input factor setup for scenario one.
the lower and upper bounds appear without a decimal point in the Macros proper-
ties section. When complete, SimRunner should look like Figure L10.9.
From here, you click the Next> button until you enter the Optimize Model
module, or click on the Optimize Model module button near the top right corner
of the window to go directly to it. The first step here is to specify Optimization
options (Figure L10.10). Select the Aggressive Optimization Profile. Accept the
default value of 0.01 for Convergence Percentage.
The convergence percentage controls how long SimRunner’s optimization
algorithms will run experiments before stopping. With each experiment, SimRunner
records the objective function’s value for a solution in the population. The evalu-
ation of all solutions in the population marks the completion of a generation. At
the end of a generation, SimRunner computes the population’s average objec-
tive function value and compares it with the population’s best (highest) objective
function value. When the best and the average are at or near the same value at
FIGURE L10.10
Optimization and simulation options.
the end of a generation, all the solutions in the population are beginning to look
alike (their input factors are converging to the same setting). It is difficult for the
algorithms to locate a better solution to the problem once the population of so-
lutions has converged. Therefore, the optimization algorithm’s search is usually
terminated at this point.
The convergence percentage controls how close the best and the average must
be to each other before the optimization stops. A convergence percentage near
zero means that the average and the best must be nearly equal before the optimiza-
tion stops. A high percentage value will stop the search early, while a very small
percentage value will run the optimization longer.
After you specify the optimization options, set the simulation options. Typi-
cally you will want to disable the animation as shown in Figure L10.10 to make the
simulation run faster. Usually you will want to run more than one replication to es-
timate the expected value of the objective function for a solution in the population.
When more than one replication is specified, SimRunner will display the objective
function’s confidence interval for each solution it evaluates. Note that the confi-
dence level for the confidence interval is specified here. Confidence intervals can
help you to make better decisions at the end of an optimization as discussed in sec-
tion 10.6.2 of Chapter 10. In this case, however, use one replication to speed things
along so that you can continue learning other features of the SimRunner software.
As an exercise, you should revisit the problem and determine an acceptable number
of replications to run per experiment. As indicated in Figure L10.10, set the simula-
tion warm-up time to 50 hours and the simulation run time to 250 hours. You are
now ready to have SimRunner seek the optimal solution to the problem.
With these operations completed, click the Next> button (Figure L10.10) and
then click the Run button on the Optimize Model module (Figure L10.11) to start
the optimization. For this scenario, SimRunner runs all possible experiments,
locating the optimum processing time of one minute on its third experiment. The
Experimental Results table shown in Figure L10.11 records the history of Sim-
Runner’s search. The first solution SimRunner evaluated called for a mean process-
ing time at the milling machine of three minutes. The second solution evaluated
assigned a processing time of two minutes. These sequence numbers are recorded
in the Experiment column, and the values for the processing time (ProcessTime)
input factor are recorded in the ProcessTime column. The value of the term used
to define the objective function (minimize the mean number of plates waiting in
the input pallet queue) is recorded in the InputPalletQue:AverageContents col-
umn. This value is taken from the output report generated at the end of a simula-
tion. Therefore, for the third experiment, we can see that setting the ProcessTime
macro equal to one results in an average of 0.162 plates waiting in the input
pallet queue. If you were to conduct this experiment manually with ProModel,
you would set the ProcessTime macro to one, run the simulation, display output
results at the end of the run, and read the average contents for the InputPalletQue
location from the report. You may want to verify this as an exercise.
Because the objective function was to minimize the mean num-
ber of plates waiting in the input pallet queue, the same values from the
FIGURE L10.11
Experimental results table for scenario one.
FIGURE L10.12
SimRunner’s process
for converting 100
minimization problems 90 Location (Queue) Contents
80
to maximization 70
problems. 60
50
1 x Contents
40
30
20
10
0
-10
0 1.5 3
0
-50 -1 x Contents
-100
-110
0 1.5 3
Process Time
FIGURE L10.13
SimRunner’s
Performance Plot
indicates the progress
of the optimization for
scenario one.
The last menu item of the Optimize Model module is the Response Plot (Fig-
ure L10.11), which is a plot of the model’s output response surface based on the
solutions evaluated during the search. We will skip this feature for now and cover
it at the end of the lab chapter.
FIGURE L10.14
Multiterm objective function for scenario two.
The highest reward is given to solutions that produce the largest number of gears
without allowing many plates to accumulate at the input pallet queue. In fact, a
solution is penalized by 100 points for each unit increase in the maximum number
of plates waiting in the input pallet queue. This is one way to handle competing
objectives with SimRunner.
Develop a SimRunner project using this objective function to seek the op-
timal values for the input factors (macros) TBA and ProcessTime, which are in-
tegers between one and five (Figure L10.15). Use the aggressive optimization
profile with the convergence percentage set to 0.01. To save time, specify one
replication per experiment. (Remember, you will want to run multiple replications
on real applications.) Also, set the simulation run hours to 250 and the warm-up
hours to 50 for now.
At the conclusion of the optimization, SimRunner will have run four genera-
tions as it conducted 23 experiments (Figure L10.16). What values do you recom-
mend to management for TBA and ProcessTime?
FIGURE L10.15
Multiple input factors setup for scenario two.
FIGURE L10.16
Experimental results table for scenario two.
your desires. Once the objective function takes its final form, rerun the optimi-
zation with the proper number of replications.
FIGURE L10.17
Experimental results table for scenario two with modified objective function.
Therefore, the statistic of interest is the average time that the gear entity is in the
system. Our task is to determine values for the input factors ProcessTime and
TBA that satisfy management’s objective.
The target range objective function is represented in SimRunner as shown
in Figure L10.18. Develop a SimRunner project using this objective function to
seek the optimal values for the input factors (macros) TBA and ProcessTime.
Specify that the input factors are integers between one and five, and use the
aggressive optimization profile with the convergence percentage set to 0.01. To
save time, set the number of replications per experiment to one. (Remember,
you will want to run multiple replications on real applications.) Also, set the
simulation run hours to 250 and the warm-up hours to 50 and run the optimi-
zation. Notice that only the solutions producing a mean time in the system of
between four and seven minutes for the gear received a nonzero value for the
objective function (Figure L10.19). What values do you recommend to manage-
ment for TBA and ProcessTime?
FIGURE L10.18
Target range objective function setup for scenario three.
L10.3 Conclusions
Sometimes it is useful to conduct a preliminary optimization project using only
one replication to help you set up the project. However, you should rarely, if ever,
make decisions based on an optimization project that used only one replication
FIGURE L10.19
Experimental results table with Performance Measures Plot for scenario three.
per experiment. Therefore, you will generally conduct your final project using
multiple replications. In fact, SimRunner displays a confidence interval about the
objective function when experiments are replicated more than once. Confidence
intervals indicate how accurate the estimate of the expected value of the objective
function is and can help you make better decisions, as noted in section 10.6.2 of
Chapter 10.
Even though it is easy to use SimRunner, do not fall into the trap of letting
SimRunner, or any other optimizer, become the decision maker. Study the top
solutions found by SimRunner as you might study the performance records of
different cars for a possible purchase. Kick their tires, look under their hoods, and
drive them around the block before buying. Always remember that the optimizer
is not the decision maker. SimRunner can only suggest a possible course of action.
It is your responsibility to make the final decision.
FIGURE L10.20
Surface response plot for scenario three.
L10.4 Exercises
Simulation Optimization Exercises
1. Rerun the optimization project presented in section L10.2.1, setting the
number of replications to five. How do the results differ from the original
results?
2. Conduct an optimization project on the buffer allocation problem presented
in section 10.6 of Chapter 10. The model’s file name is Lab 10_4 BufferOpt
Ch10.Mod and is found in the Student folder installed with ProModel. To
get your results to appear as shown in Figure 10.5 of Chapter 10, enter
Buffer3Cap as the first input factor, Buffer2Cap as the second input factor,
and Buffer1Cap as the third input factor. For each input factor, the lower
bound is one and the upper bound is nine. The objective is to maximize
profit. Profit is computed in the model’s termination logic by
Profit (10*Throughput)
(1000*(Buffer1Cap Buffer2Cap Buffer3Cap))
entered as an objective function term. Exercises 4 and 5 here involve this feature
of SimRunner.
4. This exercise will help you duplicate the SimRunner result presented
in Figure L8.14 of Lab Chapter 8, which was used to estimate the end
of the warm-up phase for the Green Machine Manufacturing Company
(GMMC) simulation model. Load the GMMC model into ProModel,
declare a dummy macro, and define its Run-Time Interface (RTI). Start
SimRunner. The purpose of the GMMC model was to estimate the
steady-state value of the time-average amount of work-in-process (WIP)
inventory in the system. Therefore, select the WIP—Average Value
response statistic from the Variable response category as a SimRunner
maximization objective. Select the dummy macro as an input factor.
Click the Next> button to move into the Analyze Model module, and fill
in the parameters as shown in Figure L10.22.
Percentage error in the objective function estimate is the desired
amount of relative error in our average WIP inventory estimate expressed
as a percentage (see section 8.2.3 of Chapter 8 for additional details on
relative error). In this case, we are seeking to approximate the number
of replications needed to estimate the average WIP with a percentage
error of 7 percent and a confidence level of 90 percent as we also
FIGURE L10.22
SimRunner parameters
for the GMMC
warm-up example.
estimate the end of the warm-up phase. Click the Next> button and then
the Run button on the Conduct Analysis window to start the analysis.
After SimRunner runs the simulation for five replications, your screen
should appear similar to Figure L8.14. Here you adjust the number of
periods for the moving average window to help you identify the end
of simulation’s warm-up, which seems to occur between periods 33
and 100. SimRunner computes that at least 10 replications are needed
to estimate the average WIP inventory with a 7 percent error and a
confidence level of 90 percent assuming a 100-period (hour) warm-up.
5. Use SimRunner’s Analyze Model module to determine the end of the
warm-up phase of the DumpOnMe simulation model with six dump
trucks as presented in Exercise 11 of Lab section L4.13. Base your
assessment of the warm-up phase on five replications of the simulation
with a run time of 300 minutes, and an output recording time interval of
one minute.
11 MODELING MANUFACTURING
SYSTEMS
595
Macros are also used to define a run-time interface. A run-time interface (RTI)
allows the user to change model parameters without directly editing the model itself.
Every time the simulation is run, the RTI allows the user to change model parameters
defined in the RTI. If you recall the Manufacturing Cost model from Lab 1, it had a
run-time interface defined for it that allowed you to select the number of operators to
use in the model. The RTI provides a user-friendly menu to change only the macros
that the modeler wants the user to change. An RTI is a custom interface defined by a
modeler that allows others to modify the model or conduct multiple-scenario experi-
ments without altering the actual model data. All changes are saved along with the
model so they are preserved from run to run. RTI parameters are based on macros,
so they may be used to change any model parameter that can be defined using a
macro (that is, any field that allows an expression or any logic definition).
An RTI is created and used in the following manner:
1. Select Macros from the Build menu and type in a macro ID.
2. Click the RTI button and choose Define from the submenu. This opens
the RTI Definition dialog box.
3. Enter the Parameter Name that you want the macro to represent.
4. Enter an optional Prompt to appear for editing this model parameter.
5. Select the parameter type, either Unrestricted Text or Numeric Range.
6. For numeric parameters:
a. Enter the lower value in the From box.
b. Enter the upper value in the To box.
7. Click OK.
8. Enter the default text or numeric value in the Macro Text field.
9. Use the macro ID in the model to refer to the run-time parameter (such
as operation time or resource usage time) in the model.
10. Before running the model, use the Model Parameters dialog box
(Figure L11.1) or the Scenarios dialog box to edit the RTI parameter.
FIGURE L11.1
Model Parameters
dialog box.
Problem Statement
Forgings R Us receives various kinds of forging orders. Raw_Forgings arrive in
batches of one every five minutes. Some forgings go from the raw material store
to the mill, and then on to the grinder. Other forgings go directly to the grinder.
After grinding, all forgings go to degrease for cleaning. Finally, all finished forg-
ings are sent to the finished parts store. The milling and grinding times vary de-
pending on the forging design. However, the degrease time is seven minutes per
forging. The layout of Forgings R Us is shown in Figure L11.2.
Define a run-time interface to allow the user to change the milling and grind-
ing times every time the simulation is run. Also, allow the user to change the total
quantity of widgets being processed. Track the work-in-process inventory (WIP)
of widgets. In addition, define another variable to track the production (PROD_QTY)
of finished widgets.
The macros are defined as shown in Figure L11.3. The run-time interface
for the milling time is shown in Figure L11.4. Figure L11.5 shows the use of the
parameters “Mill_Time” and “Grind_Time” in the processing and routing tables.
To view or change any of the model parameters, select Model Parameters from
the Simulation menu. The model parameters dialog box is shown in Figure L11.6.
To change the Grind_Time_Halfwidth, first select it from the model parameters
list, and then press the Change button. The Grind_Time_Halfwidth dialog box is
shown in Figure L11.7.
FIGURE L11.2
Layout of the Forgings
R Us.
FIGURE L11.3
Macros created
for Forgings R Us
simulation model.
FIGURE L11.4
The run-time interface
defined for the milling
operation.
FIGURE L11.5
The processing and routing tables showing the Mill_Time and Grind_Time Parameters.
FIGURE L11.6
Model Parameters
dialog box.
FIGURE L11.7
The Grind_Time_
Halfwidth parameter
dialog box.
FIGURE L11.8
Scenarios defined
for Shipping Boxes
Unlimited.
FIGURE L11.9
Editing the scenario
parameter.
FIGURE L11.10
Arrivals table for Shipping Boxes Unlimited.
FIGURE L11.11
Entity Summary Reports created for both scenarios.
change the parameter no_of_pallets to the values of 5 and 10, respectively, for
the two scenarios. In the Arrivals menu, change the occurrences for Pallet to the
parameter name no_of_pallets (Figure L11.10). This parameter will take on the
values of 5 and 10 in scenarios 1 and 2, respectively.
To run the scenarios, click on the Run Scenarios button in the Scenarios
dialog box. Both scenarios will be run in a sequential manner, and reports for
both scenarios created. Figure L11.11 shows the entity summary report for
both scenarios.
a. General Read File: These files contain numeric values read into a
simulation model using a READ statement. A space, comma, or end
of line can separate the data values. Any nonnumeric data is skipped
automatically. The syntax of the READ statement is as follows:
READ <file ID>, <variable name>
If the same file is to be read more than once in the model, it may be
necessary to reset the file between each reading. This can be achieved by
adding an arbitrary end-of-file marker 99999 and the following two lines
of code:
Read MydataFile1, Value1
If Value1=99999 Then Reset MydataFile1
The data stored in a general read file must be in ASCII format.
Spreadsheet programs (like Excel) can convert spreadsheets to ASCII
files (MydataFile1.TXT).
b. General Write: These files are used to write text strings and numeric
values using the WRITE, and WRITELINE statements. Text strings are
enclosed in quotes when written to the file, with commas automatically
appended to strings. This enables the files to be read into spreadsheet
programs like Excel for viewing. Write files can also be written using the
XWRITE statement, which gives the modeler full control over the output
and formatting. If you write to the same file more than once, either
during multiple replications or within a single replication, the new data
are appended to the previous data.
The WRITE statement writes to a general write file. The next item is
written to the file immediately after the previous item.
WRITE <file ID>, <string or numeric expression>
The WRITELINE statement writes information to a general write file and
starts a new line. It always appends to the file unless you have RESET the
file. Any file that is written to with the WRITE or WRITELINE statement
becomes an ASCII text file, and ProModel attaches an end-of-file marker
automatically when it closes the file.
The syntax of the WRITE, WRITELINE, and the XWRITE statements is as
follows:
WRITE MyReport, “Customer Service Completed At:”
WRITELINE MyReport, CLOCK(min)
The XWRITE statement allows the user to write in any format he or she
chooses.
XWRITE <file ID>, <string or numeric expression>
XWRITE MyReport2, “Customer Service Completed At:”
$FORMAT(Var1,5,2)
c. Entity Location: An entity-location file contains numeric expressions
listed by entity and location names. Entity names should appear across
top row, beginning in column 2, while location names should be entered
Column Data
A Entity Name
B Location Name
C Quantity per Arrival
D Time of First Arrival
E Number of Arrivals
F Frequency of Arrivals
G Attribute Assignments
External files can also be used to populate or extract data from a model array (see
Arrays further below).
Problem Statement
At the Pomona Castings, Inc. castings arrive for processing at the rate of 12 per
hour (average interarrival time assumed to be five minutes). Seventy percent of
the castings are processed as casting type A, while the rest are processed as cast-
ing type B.
For Pomona Castings, Inc., create an entity-location file named P11_4.xls
(Figure L11.12) to store the process routing and process time information. In the
FIGURE L11.12
An external entity-
location file in .xls
format.
simulation model, read from this external file to obtain all the process informa-
tion. Build a simulation model and run it for 100 hours. Keep track of the work-
in-process inventory and the production quantity.
Choose Build More Elements External Files. Define the ID as SvcTms.
The Type of file is Entity Location. The file name (and the correct path) is also
provided (Figure L11.13). In the Process definition, use the file ID (Figure L11.14)
instead of the actual process time—for example, Wait SvcTms(). Change the
file path to point to the appropriate directory and drive where the external file is
located. A snapshot of the simulation model is shown in Figure L11.15.
FIGURE L11.13
File ID and file name created for the external file.
FIGURE L11.14
Processing and routing tables referring to the file ID of the external file.
FIGURE L11.15
A snapshot of the
simulation model for
Pomona Castings, Inc.
L11.4 Arrays
An array is a collection of values that are related in some way such as a list of test
scores, a collection of measurements from some experiment, or a sales tax table.
An array is a structured way of representing such data.
An array can have one or more dimensions. A two-dimensional array is
useful when the data can be arranged in rows and columns. Similarly, a three-
dimensional array is appropriate when the data can be arranged in rows, columns,
and ranks. When several characteristics are associated with the data, still higher
dimensions may be appropriate, with each dimension corresponding to one of
these characteristics.
Each cell in an array works much like a variable. A reference to a cell in an array
can be used anywhere a variable can be used. Cells in arrays are usually initialized to
zero, although Initializing cells to some other value can be done in the initialization
logic. A WHILE...DO loop can be used for initializing array cell values.
Suppose that electroplating bath temperatures are recorded four times a day
at each of three locations in the tank. These temperature readings can be arranged
in an array having four rows and three columns (Table L11.2). These 12 data items
can be conveniently stored in a two-dimensional array named Temp[4,3] with
four rows and three columns.
An external Excel file (BathTemperature.xls) contains these bath temperature
data (Figure L11.16). The information from this file can be imported into an array
in ProModel (Figure L11.17) using the Array Editor. When you import data from
FIGURE L11.16
An external file
containing bath
temperatures.
FIGURE L11.17
The Array Editor in ProModel.
FIGURE L11.18
The Import File dialog
in the Array Editor.
TABLE L11.3 Data for Pending Orders TABLE L11.4 Process Routings and
at Joe’s Jobshop Average Process Times
A 25 A 2-3-1 45-60-75
B 27 B 1-2-3 70-70-50
C 17 C 3-1-2 50-60-60
an external Excel spreadsheet into an array, ProModel loads the data from left
to right, top to bottom. Although, there is no limit to the quantity of values you
may use, ProModel supports data import for only two-dimensional arrays. Fig-
ure L11.18 shows the Import File dialog in the Array Editor.
Value of an array can also be exported to an Excel spreadsheet (*.xls) during
the termination logic. Microsoft Excel must have been installed in your computer
in order to export data from an array at run time. Array exporting can be turned
off in the Simulations Options dialog.
Problem Statement
Table L11.3 shows the status of orders at the beginning of the month at Joe’s
Jobshop. In his shop Joe has three machines through which three types of jobs
are routed. All jobs go to all machines, but with different routings. The data for
job routings and processing times (exponential) are given in Table L11.4. The
processing times are given in minutes. Use a one-dimensional array to hold the
information on the order status. Simulate and find out how long will it take for Joe
to finish all his pending orders.
The layout, locations and the arrival of jobs at Joe’s Jobshop are shown in
Figures L11.19, L11.20, and L11.21. The pending order array is shown in Fig-
ure L11.22. The initialization logic is shown in Figure L11.23. The processes and
routings are shown in Figure L11.24. It took about 73 hours to complete all the
pending work orders.
FIGURE L11.19
Layout of Joe’s
Jobshop.
FIGURE L11.20
Locations in Joe’s
Jobshop.
FIGURE L11.21
Arrival of jobs at Joe’s Jobshop.
FIGURE L11.22
Pending order array in Joe’s Jobshop.
FIGURE L11.23
Initialization logic
in the general
information menu.
FIGURE L11.24
Processing and routing tables at Joe’s Jobshop.
L11.5 Subroutines
A subroutine is a defined block of code that can be called from anywhere in the
model. It can be called upon to perform a block of logic and optionally return a
value. Subroutines may have parameters or local variables (local to the subrou-
tine) that take on the values of arguments passed to the subroutine. There are three
variations of the use of subroutines in ProModel.
1. A subroutine is called by its name from some other logic in the model.
When the subroutine finishes executing, the calling logic resumes
execution.
2. A subroutine is processed independently of the calling logic so that
the calling logic continues without waiting for the subroutine to
finish. An ACTIVATE statement followed by the name of the subroutine
accomplishes this.
3. Subroutines written in an external programming language can be called
using the XSUB() function.
Subroutines are defined in the Subroutines Editor in the More Elements section of
the Build menu. For more information on ProModel subroutines, please refer to
the ProModel Help System.
Problem Statement
At California Gears, gear blanks are routed from a fabrication center to one of
three manual inspection stations. The operation logic for the gears is identical
at each station except for the processing times, which are a function of the indi-
vidual inspectors. Each gear is assigned two attributes during fabrication. The
first attribute, OuterDia, is the dimension of the outer diameter of the gear. The
second attribute, InnerDia, is the dimension of the inner diameter of the gear.
During the fabrication process the outer and inner diameters are machined with
an average of 4.015 0.01 and 2.015 0.01 inches (uniformly distributed).
These dimensions are tested at the inspection stations and the values entered
into a text file (Quality.doc) for quality tracking. After inspection, gears are
routed to a shipping location if they pass inspection, or to a scrap location if
they fail inspection.
Gear blanks arrive at the rate of 12 per hour (interarrival time exponentially
distributed with a mean of five minutes). The fabrication and inspection times
(normal) are shown in Table L11.5. The specification limits for the outer and
inner diameters are given in Table L11.6. The layout, locations, entities, and
arrival of raw material are shown in Figures L11.25, L11.26, L11.27, and L11.28
FIGURE L11.25
Layout of California
Gears.
FIGURE L11.26
Locations at the
California Gears.
FIGURE L11.27
Entities at the
California Gears.
FIGURE L11.28
Arrival of raw material at the California Gears.
FIGURE L11.29
Subroutines defining routing logic.
FIGURE L11.30
Processing and routing tables for California Gears.
FIGURE L11.31
External file for
California Gears.
FIGURE L11.32
Gear rejection report
(partial) at California
Gears.
Problem Statement
Salt Lake Machine Shop has two machines: Mach A and Mach B. A mainte-
nance mechanic, mechanic Dan, is hired for preventive maintenance on these
machines. The mean time between preventive maintenance is 120 10 minutes.
Both machines are shut down at exactly the same time. The actual maintenance
takes 10 5 minutes. Jobs arrive at the rate of 7.5 per hour (exponential mean
time between arrival). Jobs go to either Mach A or Mach B selected on a random
basis. Simulate for 2,000 hours.
The layout, resources, path network of the mechanic, processing and rout-
ing tables are shown in Figures L11.33, L11.34, L11.35, and L11.36. The ar-
rival of customers is defined by an exponential interarrival time with a mean of
three minutes. The downtimes and the definition of random number streams are
shown in Figures L11.37 and L11.38, respectively. Note that the same seed value
(Figure L11.38) is used in both the random number streams to ensure that both
machines are shut down at exactly the same time.
FIGURE L11.33
Layout of the Salt Lake
Machine Shop.
FIGURE L11.34
Resources at Salt Lake Machine Shop.
FIGURE L11.35
Path network of the mechanic at Salt Lake Machine Shop.
FIGURE L11.36
Processing and routing tables at Salt Lake Machine Shop.
FIGURE L11.37
Clock downtimes for machines A and B at Salt Lake Machine Shop.
FIGURE L11.38
Definition of random
number streams.
The Merge Model option in the File menu allows two or more independent
(complete or incomplete) models to be merged together into a single model. Entity
and attribute names common to both models are considered common elements in
the merged model. Duplicate locations, resources, or path networks must first be
renamed or deleted from the original merging model. If the graphic libraries are
different, the user has an option to append the merging model’s graphic library to
the base model’s graphic library. All other duplicate elements cause a prompt to
appear with a chance to delete the duplicate element.
Problem Statement
SoCal Casting Inc. (Lab 4, section L4.5) decides to merge with El Segundo
Composites (Lab 4, section L4.7.1). The new company is named El Segundo
Castings N’ Composites. Merge the model for section L4.5 with the model for
section L4.7.1. All the finished products—castings as well as composites—are
now sent to the shipping queue and shipping clerk. The model in section L4.5
is shown in Figure L4.20. The complete simulation model, after the model for
section L4.7.1 is merged, is shown in Figure L11.39. After merging, make the
necessary modifications in the process and routing tables.
We will make suitable modifications in the Processing module to reflect these
changes (Figure L11.40). Also, the two original variables in section L4.5 (WIP
and Prod_Qty) are deleted and four variables are added—WIPCasting, WIPCom-
posite, Prod_Qty_Casting, and Prod_Qty_Composite.
FIGURE L11.39
Merging the models from section L4.5 and section L4.7.1.
FIGURE L11.40
Changes made in the process and routing tables after merging.
L11.8 Exercises
1. Differentiate between the following:
a. Table functions versus arrays.
b. Subroutines versus macros.
c. Arrivals versus arrival cycles.
d. Scenarios versus replications.
e. Built-in distribution versus user distribution.
9. For Salt Lake City Electronics (Exercise 10, section L4.13), use
external files (arrivals and entity_location files) to store all the data. Read
this file directly into the simulation model.
10. For El Segundo Castings N’ Composites example in section L11.7,
create macros and suitable run-time interfaces for the processing time
parameters shown in Table L11.8.
12 MATERIAL HANDLING
CONCEPTS
With malice toward none, with charity for all, with firmness in the right, as God
gives us to see the right, let us strive on to finish the work we are in . . .
—Abraham Lincoln
L12.1 Conveyors
Conveyors are continuous material handling devices for transferring or moving
objects along a fixed path having fixed, predefined loading and unloading points.
Some examples of conveyors are belt, chain, overhead, power-and-free, roller,
skate, and bucket conveyors.
In ProModel, conveyors are locations represented by a conveyor graphic. A
conveyor is defined graphically by a conveyor path on the layout. Once the path
has been laid out, the length, speed, and visual representation of the conveyor can
be edited by double-clicking on the path and opening the Conveyor/Queue dialog
box (Figure L2.17). The various conveyor options are specified in the Conveyor
Options dialog box, which is accessed by clicking on the Conveyor Options but-
ton in the Conveyor/Queue dialog box (Figure L12.1).
617
FIGURE L12.1
The Conveyor Options
dialog box.
FIGURE L12.2
A snapshot of the
San Dimas Car Wash
system model.
FIGURE L12.3
Processing and routing tables at San Dimas Car Wash.
ConvA 100 30
ConvB 100 50
ShippingConv 200 20
FIGURE L12.4
Processing and routing tables for the Ship’n Boxes Inc. model.
FIGURE L12.5
A snapshot of the
simulation model for
the Ship’n Boxes Inc.
distributed). Both types of boxes are sent to the shipping dock by the shipping con-
veyor. The speed and length of the conveyors are shown in Table L12.1. Develop
a simulation model and run it for 10 hours. Figure out how many boxes of each
type are shipped in 10 hours.
Four locations (ConvA, ConvB, ShippingConv, and Shipping_Dock) and
two entities (BoxA and BoxB) are defined. The processing and routing tables are
shown in Figure L12.4. Figure L12.5 shows a snapshot of the simulation model
for the Ship’n Boxes Inc.
FIGURE L12.6
Processing and routing tables for PCBA Electronics with recirculating conveyor.
FIGURE L12.7
A snapshot of the
PCBA Electronics
simulation model.
Build a simulation model, run it for 2,000 hours, and determine how many
operators the shop should hire so that the work-in-process inventory remains at
stable and low levels.
Five locations (Receive, NC_Lathe_1, NC_Lathe_2, Inspect, and Degrease),
two entities (Blank and Cog), and a resource (Operator) are defined. The processes
and routings are shown in Figure L12.8. The blanks arrive with an interarrival
time that is exponentially distributed with a mean of 20 minutes. The simula-
tion run hours is set at 2000 in the Simulation Option menu. The model is titled
Ghosh’s Gear Shop in the General Information menu. The operator is defined as
a resource (Figure L12.9). Figure L12.10 shows the path network (Net1) specifi-
cations. All the paths in the path network (Net1) are defined with five nodes and
FIGURE L12.8
Processing and Routing Tables at Ghosh’s Gear Shop—Operator as Material Handler.
FIGURE L12.9
Operator as a resource.
FIGURE L12.10
Path Network for
Operator.
five interfaces (Figure L12.11). The layout of Ghosh’s Gear Shop is shown in
Figure L12.12.
We ran this model with one, two, or three operators working together. The
results are summarized in Table L12.3. The production quantities, average and
maximum WIP, and the average time in system (minutes) are obtained from the
output of the simulation analysis. Note that with one operator both the WIP levels
and the average time in system grow to unsustainable levels. With two or more
operators WIP levels and the average time in system remains at stable and reason-
ably low values. While there are slight improvements in the production rate, WIP
levels, and time in system by going from two to three operators, the improvements
are not large enough to justify hiring the third operator.
FIGURE L12.11
Paths defined in the Path Network.
FIGURE L12.12
Layout of Ghosh’s
Gear Shop.
Production Average
No. of Quantity in Time in
Operators 2,000 hrs Prod. Rate/hr. Average WIP Maximum WIP System
FIGURE L12.13
Processing and routing tables at Ghosh’s Gear Shop—operator as material handler plus machine operator.
Production
No. of Quantity in Average Time
Operators 2,000 hrs Prod. Rate/hr. Average WIP Maximum WIP in System
Problem Statement
Raja owns a manufacturing facility (Raja’s Manufacturing Cell) consisting of
two mills, and a lathe. All jobs are processed in the same sequence, consisting of
arrival station, lathe, mill1, and mill2, and exit station. The processing time on
each machine is normally distributed with a mean of 30 minutes and a standard
deviation of 10 minutes. The arrival rate of jobs is exponentially distributed with a
mean of 60 minutes. In this facility, an overhead crane system is used to handle all
the material movements between the stations. Job pickup and release times by the
crane are uniformly distributed [U(3,1) min]. The path network is shown in Fig-
ure L12.14. The coordinates of all the locations in the cell are given in Table L12.5.
The crane system resource, and processes and routings are shown in Figures L12.15
and L12.16. The crane can travel at the rate of 150 feet/minute with or without a
load. Simulate for 2,000 hours.
FIGURE L12.14
Path networks for the crane system at Raja’s manufacturing cell.
Arrive_station 10 100
Lathe 50 80
Mill1 90 80
Mill2 80 20
Exit_station 0 20
FIGURE L12.15
The crane system resource defined.
FIGURE L12.16
Processing and routing tables at Raja’s Manufacturing Cell.
Select Path Network from the Build menu. From the Type menu, select Crane.
The following four nodes are automatically created when we select the crane type
of path network: Origin, Rail1 End, Rail2 End, and Bridge End. Define the five
nodes N1 through N5 to represent the three machines, the arrive_station, and the
exit_station. Click on the Interface button in the Path Network menu and define
all the interfaces for these five nodes.
Select Resource from the Build menu. Name the crane resource. Enter 1 in
the Units column (one crane unit). Click on the Specs button. The Specifications
menu opens up. Select Net1 for the path network. Enter the empty and full speed
of the crane as 150 ft./min. Also, enter Uniform(180,60) seconds as the pickup
and deposit time.
L12.4 Exercises
1. Modify the example in section L6.11 by having a material handler
(Joe) return the Empty_Pallet from the shipping dock to the Inspector.
Eliminate the pallet queue. Also, let’s have Joe load the boxes onto
pallets and the loaded pallets onto the shipping conveyor [Uniform(3,1)
min]. Assume one pallet being recirculated in the system. Simulate for
2,000 hours and determine the following:
a. The number of monitors shipped per hour.
b. The utilization of the material handler (Joe).
2. Pritha takes over the manufacturing cell (section L12.3) from Raja. She
replaces the crane system and hires a material handler to move material
FIGURE L12.17
Forging
Layout of LA
Forge Inc. Loader
Machine 2
6. U.S. Construction Company has one bulldozer, four trucks, and two
loaders. The bulldozer stockpiles material for the loaders. Two piles of
material must be stocked prior to the initiation of any load operation.
The time for the bulldozer to stockpile material is Erlang distributed and
consists of the sum of two exponential variables, each with a mean of 4
(this corresponds to an Erlang variable with a mean of 8 and a variance
of 32). In addition to this material, a loader and an unloaded truck must
be available before the loading operation can begin. Loading time is
exponentially distributed with a mean time of 14 minutes, for loader 1
and 12 minutes for loader 2.
After a truck is loaded, it is hauled and then dumped; it must be
returned before the truck is available for further loading. Hauling time
is normally distributed. The average hauling time is 22 minutes when
loaded and 18 minutes when unloaded. In both cases, the standard
deviation is three minutes. Dumping time is uniformly distributed
between two and eight minutes. Following a loading operation, the
loader must rest for five minutes before it is available to begin loading
again. Simulate this system at the U.S. Construction Company for a
period of 2,000 hours of operation and analyze the results.
7. At Walnut Automotive, machined castings arrive randomly (exponential,
mean of six minutes) from the supplier to be assembled at one of
five identical engine assembly stations. A fork truck delivers the
castings from the shipping dock to the engine assembly department. A
recirculatingconveyor connects the assembly stations.
The forklift truck moves at a velocity of five feet per second.
The distance from the shipping dock to the assembly department is
1,000 feet. The conveyor is 5,000 feet long and moves at a velocity of
five feet per second.
At each assembly station, no more than three castings can be waiting
for assembly. If a casting arrives at an assembly station and there is
no room for the casting (there are already three castings waiting), it is
recirculated. The assembly time is normally distributed with a mean
of five minutes and standard deviation of two minutes. The assembly
stations are equally distributed around the belt. The load/unload station
is located halfway between stations 5 and 1. The forklift truck delivers
the castings to the load/unload station. It also picks up the completed
assemblies from the load/unload station and delivers them back to the
shipping dock.
Create a simulation model, with animation, of this system. Run the
simulation model until 1,000 engines have been assembled and analyze
the following:
a. Average throughput time for the castings in the manufacturing
system.
b. Utilization of the forklift truck and the conveyor.
Group of Sorters
Shipping
Dock
Crane 1 Crane 2
16. For the simulation model in Exercise 14, vary the minimum requirement
of trees that are loaded on a truck from 15 to 20 to 25 tons to determine
the effect on throughput of this decision variable.
17. Rancho Cucamonga Coil Company is considering implementing a
crane system as shown in Figure L12.19. Two cranes operate on separate
tracks. Crane 1 serves only input station A and is used to transport steel
cables to either output station C or D. Crane 2 transports copper cables
from input station B to either output station D or E. The distances
between the input and output stations are shown in Table L12.9.
The arrival of steel cables to input station A is four rolls per hour
(exponential), with 50 percent of the rolls sent to output station C and
50 percent to output station D. The arrival rate of copper cables to input
station B is two rolls per hour (exponential), with 40 percent of the rolls
sent to output station D and 60 percent to output station E. The travel
speeds of both the cranes are 20 feet/minute without load and 10 feet/
minute with load. The pickup and drop-off times are two minutes each.
Simulate the crane system and collect statistics on the throughput from
each input station to each output station.
18. For the Rancho Cucamonga Coil Company (Exercise 17), what will be
the impact on throughput if the cranes run on a single track with output
station D being on the common path of both the cranes? Model the
interference in reaching output station D.
19. For the Rancho Cucamonga Coil Company (Exercise 17), establish
a cost structure to evaluate and compare the single track (with
interference) versus the separate track crane systems. Use ProModel’s
cost tracking feature.
20. For the Rancho Cucamonga Coil Company (Exercise 17), evaluate the
impact of giving priority to jobs that do not require the common track—
that is, to jobs destined to output stations C and E.
21. Four operators are employed in the production facility described in
Lab 6, Exercise 15. An operator will be required to place a part on a
machine (mill, drill, planer, inspection), before the machine performs its
function, remove the part after machining or inspection, and move it to
the next operation. The part runs on the machine without the operator’s
presence.The scrap parts are placed in a box that can accumulate 10 parts
and is then thrown away by an operator. The set-up times (per batch) and
the throw away times are random variables with distributions as shown
in Table L12.10.
The system runs for three 8-hour shifts per day, 5 days per week.
Let the Type I part have higher priority over Type II parts at the drilling
machine. Let the operators go to lunch one at a time for 30 minutes each
in sequence. The lunch break begins 3.0 hours into an 8 hour shift.
There are electrical interruptions that occur independently with
times following a uniform distribution with mean ⫽ 240 minutes, and
half-range ⫽ 30 minutes. When one of these interruptions occurs, one
mill breaks down. A repair takes 20 minutes, exponentially distributed.
One of the operators performs the repair.
Simulate this system for 2,000 hours with an 8-hour warm-up of the
system.
Reference
Hoover, S. V., and Perry, R. F. Simulation: A Problem Solving Approach. Boston: Addison
Wesley, 1989, pp. B93–B95.
13 MODELING SERVICE
SYSTEMS
Be silent as to services you have rendered, but speak of favors you have received.
—Seneca (Roman dramatist, philosopher, & politician)
Problem Statement
All American Car Wash is a five-stage operation that takes 2 1 minutes for
each stage of wash (Figure L13.1). The queue for the car wash facility can hold up
to three cars. The cars move through the washing stages in order, one car not being
639
FIGURE L13.1
Layout of the All
American Car Wash.
FIGURE L13.2
Customer arrivals at the All American Car Wash.
FIGURE L13.3
Processing and routing tables at the All American Car Wash.
able to move until the car ahead of it moves. Cars arrive every 2.5 2 minutes for
a wash. If a car cannot get into the car wash facility, it drives across the street to
Better Car Wash. Simulate for 2,000 hours. Estimate the following:
a. How many customers does All American Car Wash lose to its
competition per hour (balking rate per hour)?
b. How many cars are served per hour?
c. What is the average time spent by a customer at the car wash facility?
The customer arrivals and the processing and routing tables are defined as shown
in Figures L13.2 and L13.3. The simulation run hours are set at 100. The total
FIGURE L13.4
Cars that balked.
FIGURE L13.5
Customers served.
number of cars that balked and went away to our competition across the street is
104 in 100 hours (Figure L13.4). That is about 1.04 cars per hour.
The total number of customers served is 2,377 in 100 hours (Figure L13.5).
That is about 24 cars per hour. We can also see that, on average, the customers
spent 14.45 minutes in the car wash facility.
Problem Statement
Customers arrive at the Save Here Grocery store with a mean time between ar-
rivals (exponential) that is a function of the time of the day as shown below in
Table L13.1. The grocery store consists of two aisles and a cashier. Once inside
the store, customers may choose to shop in one, two, or none of the aisles. The
probability of shopping aisle one is 0.75, and for aisle two it is 0.5. The number
of items selected in each aisle is described by a normal distribution with a mean
of 15 and a standard deviation of 5. The time these shoppers require to select an
item is five minutes. When all desired items have been selected, customers queue
up at the cashier to pay for them. The time to check out is a uniformly distributed
random variable that depends on the number of items purchased. The checkout
0 50
2 40
4 25
6 20
8 20
10 20
12 25
14 30
16 30
FIGURE L13.6
Locations in Save Here
Grocery.
FIGURE L13.7
Arrivals in Save Here Grocery.
FIGURE L13.8
Processing and routing
tables at Save Here
Grocery.
time per item varies from 0.6 0.5 minutes (uniformly distributed). Simulate for
10 days (16 hours/day).
The locations, arrival of entities, processes and the layout of the grocery store
are shown in Figures L13.6, L13.7, L13.8, and L13.9, respectively.
FIGURE L13.9
The layout of the Save
Here Grocery.
FIGURE L13.10
Arrival cycles edit
menu.
The arrival frequency derived from the table function arrival time(HR) as
follows:
e(arrival_time(CLOCK(HR)-16*TRUNC(CLOCK(HR)/16))) min
From To Percent
FIGURE L13.11
Locations at the
Newport Beach
Burger.
FIGURE L13.12
Processing and routing
tables at the Newport
Beach Burger.
The number of entities arriving for each interval of the cycle can be defined
cumulatively or non-cumulatively and expressed as a number or as a percentage
of total entities arriving for the complete cycle. Once the arrival cycles are de-
fined, they can be assigned to an arrivals record in the Arrivals edit table.
Problem Statement
At the Newport Beach Burger stand there are three peak periods of customer ar-
rivals: breakfast, lunch, and dinner (Table L13.2). The customer arrivals taper out
before and after these peak periods. The same cycle of arrivals repeat every day. A
total of 100 customers visit the store on an average day (normal distribution with
a standard deviation of five). Upon arrival, the customers take Uniform(5 2)
minutes to order and receive food and Normal(15, 3) minutes to eat, finish busi-
ness discussions, gossip, read a newspaper, and so on. The restaurant currently has
only one employee (who takes the order, prepares the food, serves, and takes the
money). Simulate for 2,000 hours.
The locations, processing and routing tables, arrivals, arrival quantities are
shown in Figures L13.11, L13.12, L13.13, and L13.14, respectively. The arrival
cycles and the probability density function of arrivals at Newport Beach Burger
are shown in Figure L13.15. A snapshot of the simulation model is shown in
Figure L13.16.
FIGURE L13.13
Arrivals at the Newport
Beach Burger.
FIGURE L13.14
Arrival quantity
defined for the arrivals
table.
FIGURE L13.15
Arrival cycles and
probability density
function of arrivals
defined at Newport
Beach Burger.
FIGURE L13.16
A snapshot of the
Newport Beach Burger.
Problem Statement
The customers at the Newport Beach Burger stand in section L13.3 arrive in
group sizes of one, two, three, or four with the probabilities shown in Table L13.3.
The mean time between arrivals is 15 minutes (exponential). The probability den-
sity function of ordering and eating times are shown in Tables L13.4 and L13.5,
respectively. Simulate for 2,000 hours.
The user distributions, group size distributions, order time distributions, and
eating time distributions are defined as shown in Figures L13.18, L13.19, L13.20,
and L13.21, respectively.
FIGURE L13.17
User distributions
menu.
1 .4
2 .3
3 .1
4 .2
TABLE L13.4 Probability Density Function TABLE L13.5 Probability Density Function
of Ordering Times of Eating Times
FIGURE L13.18
User distributions for
the Newport Beach
Burger.
FIGURE L13.19
Group size
distributions for
the Newport Beach
Burger.
FIGURE L13.20
Order time
distributions for
the Newport Beach
Burger.
FIGURE L13.21
Eating time
distribution for the
Newport Beach
Burger.
Once the students have visited the number of islands they have decided
they go to the dining area. Also, students have a tendency to not spend any more
than 15 minutes in the food court (getting food) before going to the dining area.
After students have finished their lunch in the dining area they dispose their
dishes and leave. Data on various service times were collected and summarized
in Table L13.8. Moving from one area to another takes 15 seconds. A total of
200 students eat lunch every day. They arrive to the cafeteria on average every
1/2 minute (exponentially distributed) as shown in Figure L13.22. Various loca-
tions defined for this cafeteria are shown in Figure L13.23.
We define two attributes Food Choices and Time In to keep track of the choice
of food students make and also to keep track of the student’s time of arrival to the
cafeteria (Figure L13.24). Figure L13.25 shows the processing and routing of stu-
dents at the cafeteria. Note the use of an If-Then-Else logic to model that students
do not wait any more than 15 minutes in the food court to get food. Also, note the
modeling of checking for space availability at any island and deciding whether
to wait or move on to another food island. Figure L13.26 shows a snapshot of the
State University Cafeteria simulation model. Run 10 replications of this simula-
tion model.
FIGURE L13.22
Arrival of students to
the cafeteria.
FIGURE L13.23
Locations for State
University Cafeteria.
FIGURE L13.24
Attributes defined for
the State University
Cafeteria model.
FIGURE L13.25
Processing and routing
tables for the State
University Cafeteria
simulation model.
FIGURE L13.26
A snapshot of the State
University Cafeteria
simulation model.
From the results of the simulation we can conclude that it takes little over
3 hours to serve these 200 students. The average time a student spends in the cafete-
ria (waiting, getting food, and eating) is about an hour although almost 48 percent
of that time they are blocked. It will be interesting to explore how we can improve
the operations of this cafeteria. What are some of the alternatives you would like to
explore? How will you model them? Which alternative will you recommend? Why?
How will your recommended solution improve the performance of the cafeteria?
Percentage within
Service Category Service Category
Customers’ first point of contact is one of the associates. The time to serve a
customer depends on the type of service and is shown in Table L13.11.
After 9 minutes of servicing a telephone call it is elevated to a supervisor.
After 7 minutes of servicing a live chat it is elevated to a supervisor. Ten per-
cent of all emails (complicated technical issues) are elevated to a supervisor, on
arrival.
Figure L13.27 shows all the locations defined for the Outsource2US call cen-
ter model. Figure L13.28 shows the processing and routings tables for this call
center.
Figure L13.29 shows a snapshot of the Outsource2US call center simulation
model. Run the simulation model for 2,000 hours.
FIGURE L13.27
Locations for the
Outsource2US model.
FIGURE L13.28
Processing and routing tables for Outsource2US call center.
FIGURE L13.29
A snapshot of the
Outsource2US call
center simulation
model.
TABLE 13.12 Time in System for Telephone Calls, Live Chats, and Emails
From analyzing the results of the simulation we conclude that the average
associate is busy about 80 percent of the time while the average supervisor is
busy for about 27 percent of the time. The average and maximum times the tele-
phone calls, live chats, and emails spent in the call center are summarized in
Table L13.12. While the average times are very reasonable, the maximum times
are quite large. How could we improve the quality of the service of the call cen-
ter? What alternatives can we explore? Which alternative would you recommend?
How will it improve the performance of the call center?
FIGURE L13.30
Locations at the
ED facility of the
Los Angeles County
Hospital.
FIGURE L13.31
Entities in the ED
facility model.
FIGURE L13.32
Processing and routing tables for the ED facility of the Los Angeles County hospital.
FIGURE L13.33
A snapshot of the
Simulation Model of
the ED facility of the
Los Angeles Country
Hospital.
Figure L13.31. Figure L13.32 shows the processing and routing tables for
this ED facility of the Los Angeles County hospital.
Figure L13.33 shows a snapshot of the simulation model ED facility of the Los
Angeles County Hospital. Run the simulation model for 24 hours, 365 days a year
(8,760 hours). How is this triage facility working? Do we have adequate capacity
in each area of the triage? Is the waiting time for various categories of patients
acceptable? What steps would you take to improve the performance of this facility?
TABLE L13.14 Process Steps and Distribution of Service Times at the DMV
Service Time
Type of Service Process Steps Distribution
FIGURE L13.34
Locations for the DMV
model.
FIGURE L13.35
Attributes defined for
the DMV model.
FIGURE L13.36
Global variables
defined for the DMV
model.
steps they go through for these services and the distribution of service times for
these processes. Figure L13.34 shows the various locations defined for this model.
Figures L13.35 and L13.36 show the attributes and variables (global) defined in
this model.
Seventy percent of the customers who take the written test for the driving per-
mit pass and go on to get their picture taken. The other 30 percent fail the written
test and need to come back at a later date. Eighty percent of the customers who
take the drive test pass, the remaining 20 percent fail the test and need to come
back again at a later date.
To abide by the local fire code the maximum number of customers in the
building is kept at or below 50. When the building reaches its capacity, any ar-
riving customers are turned away and asked to come back later that day or come
back another day. The front door of the building is closed to arriving customers
after six hours of operation and any remaining customers already in the building
are processed until the last customer has been served. Figure L13.37 shows the
FIGURE L13.37
Processing and routing tables for the DMV model.
(continued)
processing and routing tables for the DMV model. Figure L13.38 shows a snap-
shot of the simulation model of the DMV office.
Simulate for 30 replications (30 working days) and determine:
a. The 95 percent confidence interval for average waiting time in system
for customers with appointment.
FIGURE L13.38
A snapshot of the Simulation Model for the DMV Office.
L13.9 Exercises
1. San Dimas Bank and Loan has an ATM for drive-in customers. They also
have two tellers—current account and savings account. Thirty percent
of all customers use the drive-in ATM facility. Each teller has his/her
own waiting line of customers. The current account teller can serve a
customer from the savings line if there are no current account customers
waiting for service. Among the walk in customers 20 percent are current
account holders. The ATM use time depends on the type of service (cash
withdrawal, cash or check deposit, balance enquiry, buy stamps, etc.) and
is uniformly distributed between 6 to 12 minutes. The service time at the
teller counter is as follows:
time and checkout time of express and regular customers are as shown in
Table L13.15.
Regular customers always choose the shortest checkout line.
Once a customer joins a line, they cannot switch to another line. The
supermarket is open 24 hours/day, 365 days a year. Simulate for a whole
year and determine:
a. How many checkout counters should be kept open to keep the
checkout lines below five people?
b. Find the utilization of carts and checkout counters.
c. Average time in the supermarket for both types of customers.
3. Management of Apna Bazaar (Exercise 2) conducted a study and found
that both shopping time and checkout time correlates with the number
of items purchased. The number of items purchased by a customer is
uniformly distributed U(25,20). The shopping time per item is normally
distributed with an average of 3 minutes and a standard deviation of
1 minute. The checkout time per item is normally distributed with an
average of 30 seconds and a standard deviation of 10 seconds. The total
shopping times and total checkout times are given by the following
relationships:
Total Shopping Time No. of Items Purchased * Shopping Time / Item
Total Checkout Time No. of Items Purchased * Checkout Time / Item
The express counter only handles customers with 10 or less items to
checkout. All the other information is given in Exercise 2. Simulate for a
whole year and determine:
a. How many checkout counters should be kept open to keep the
checkout lines below five people?
b. Find the utilization of carts and checkout counters.
c. Average time in the supermarket for both types of customers.
4. Pritha’s Hair Salon employs three barbers—Puja, Prerana, and Pritha
(owner). On the average, the mean time between arrivals is exponentially
distributed with a mean of five minutes. The haircut times for various
types of customers are shown in Table L13.16. Thirty-five percent of
Percentage of
Types of Customers all Customers Haircut Time
FIGURE L13.39
San Dimas Mutual Bank
Layout of the San
Dimas Mutual Bank.
Parking Lot
ATM 1 ATM 2
Drive-In
6. San Dimas Mutual Bank has two drive-in ATM kiosks in tandem but
only one access lane (Figure L13.39). In addition, there is one indoor
ATM for customers who decide to park (30 percent of all customers) and
walk in. Customers arrive at intervals that are spaced on average five
minutes apart (exponentially distributed). ATM customers are of three
types—save money (deposit cash or check), spend money (withdraw
cash), or count money (check balance). The times for these services are
shown in Table L13.17. If both ATMs are free when a customer arrives,
the customer will use the “downstream” ATM 2. A car at ATM 1 cannot
pass a car at ATM 2 even if it has finished.
Create a simulation model of the bank. The ATM kiosks operate
24/7. Run the model until 2,000 cars have been served. Analyze the
following:
a. The average and maximum drive-in queue size.
b. The average and maximum time spent by a customer waiting in
drive-in queue.
b. What is the average waiting time for each type of patients? Develop
a 95 percent confidence interval on the average waiting time for each
type of patients.
c. What is the average time in the diagnostic lab for each type of
patients? Develop a 95 percent confidence interval on the average
time in the diagnostic lab for each type of patients.
d. What is the average number of patients in the diagnostic lab? Is
this at a reasonable level? Why or why not? Develop a 95 percent
confidence interval on the average number of patients in the
diagnostic lab.
e. What is the average utilization of the phlebotomists? Do we need to
hire additional phlebotomists? Why or why not?
In ProModel, distribution functions are built-in functions that return observations (random
variates) from various probability distributions. Common continuous and discrete prob-
ability distributions implemented in ProModel as callable functions are summarized in this
appendix. Note that ProModel includes a User-defined function that allows users to specify
a custom discrete or continuous distribution via entries to a table if none of the standard
ProModel built-in distribution functions can adequately model the situation.
In addition to required parameters, some ProModel distribution functions have optional
parameters denoted by {< >}. The symbols <s> denote the random number generator stream
used to generate observations from the distribution. If this option is omitted, ProModel
will use stream 1. The symbols <ax> denote an optional axis shift. The exponential (E),
Gamma (G), Weibull (W), Lognormal (L), Inverse Gaussian (IG), Pearson 5 (P5), and
Pearson 6 (P6) distributions all normally have a minimum value of zero. Use an axis shift to
alter the distribution’s minimum value and at the same time shift the entire distribution. Any
time an axis shift is specified, a random number generator stream must be specified also.
Any negative value returned by a distribution that is used for a time expression in
ProModel will be automatically converted to zero.
Application: The beta distribution is a continuous distribution that has both upper and
lower finite bounds. Because many real situations can be bounded in this way, the beta
distribution can be used empirically to estimate the actual distribution before many data
are available. Even when data are available, the beta distribution should fit most data in a
reasonable fashion, although it may not be the best fit. The uniform distribution is a special
case of the beta distribution.
Beta distributions have been used to model distributions of activity time in PERT analy-
sis, porosity/void ratio of soil, phase derivatives in communication theory, size of prog-
eny in Escherichia coli, dissipation rate in breakage models, proportions in gas mixtures,
steady-state reflectivity, clutter and power of radar signals, construction duration, particle
size, tool wear, and others. Many of these uses occur because of the doubly bounded nature
of the beta distribution.
Distribution: Erlang
Syntax: ER(a, b{,<s>}) a mean value, b parameter
Application: The Erlang distribution is a continuous distribution bounded on the lower side.
It is a special case of the gamma distribution and can be reduced to the exponential distribution.
*Adapted with permission from ProModel Users Guide and Stat::Fit Users Guide.
669
The Erlang distribution has been used to specify the time required for a task. It has
been used extensively in reliability and in queuing theory, and thus in discrete event
simulation, because it can be viewed as a sum of exponentially distributed random
variables.
Distribution: Exponential
Syntax: E(a{,<s>, <ax >}) a mean
Application: The exponential distribution is a continuous distribution bounded on the
lower side. Its shape is always the same, starting at a finite value at the minimum and con-
tinuously decreasing at larger x.
The exponential distribution is frequently used to represent the time between random
occurrences, such as the time between arrivals at a specific location in a queuing model or
the time between failures in reliability models. It has also been used to represent the service
times of a specific operation.
Distribution: Gamma
Syntax: G(a, b{,<s>, <ax >}) a shape value, b scale value
Application: The gamma distribution is a continuous distribution bounded at the lower
side. It can be reduced to the exponential distribution and the Erlang distribution.
The gamma distribution has been used to represent lifetimes, lead times, personal
income data, a population about a stable equilibrium, interarrival times, and service
times.
Distribution: Lognormal
Syntax: L(a, b{,<s>, <ax >}) a mean, b standard deviation
Application: The lognormal distribution is a continuous distribution bounded on the
lower side. By definition, the natural logarithm of a lognormal random variable is a normal
random variable.
The lognormal distribution is used in many different areas including the distribution
of particle size in naturally occurring aggregates, dust concentration in industrial atmo-
spheres, the distribution of minerals present in low concentrations, the duration of sick-
ness absence, physicians’ consulting time, lifetime distributions in reliability, distribution
of income, employee retention, and many applications modeling weight, height, and so
forth.
Distribution: Normal
Syntax: N(a, b{,<s>}) a mean, b standard deviation
Distribution: Pearson 5
Syntax: P5(a, b{,<s>, <ax >}) a shape value, b scale value
Application: The Pearson 5 distribution is a continuous distribution with a bound on
the lower side and is sometimes called the inverse gamma distribution due to the reciprocal
relationship between a Pearson 5 random variable and a gamma random variable.
The Pearson 5 distribution is useful for modeling time delays where some minimum delay
value is almost assured and the maximum time is unbounded and variably long, such as time
to complete a difficult task, time to respond to an emergency, time to repair a tool, and so forth.
Distribution: Pearson 6
Syntax: P6(a, b, c{,<s>, <ax >}) a shape value 1, b shape value 2, c scale value
Application: The Pearson 6 distribution is a continuous distribution bounded on the
low side. The Pearson 6 distribution is sometimes called the beta distribution of the second
kind due to the relationship of a Pearson 6 random variable to a beta random variable. It is
perhaps most often used to represent the time to accomplish a task.
Distribution: Triangular
Syntax: T(a, b, c{,<s>}) a minimum, b mode, c maximum
Application: The triangular distribution is a continuous distribution bounded on both
sides. The triangular distribution is often used when no or few data are available; it is rarely
an accurate representation of a data set (see Law 2007).
Distribution: Uniform
Syntax: U(a, b{,<s>}) a mean (minimum maximum)/2, b half range
maximum mean
Application: The uniform distribution is a continuous distribution bounded on both
sides. It is a special case of the beta distribution. Most random number generators provide
samples from the uniform distribution on (0,1) and then convert these samples to random
variates from other distributions.
The uniform distribution is used to represent a random variable with constant likelihood
of being in any interval between min and max. Note that the probability of either the min
or max value is 0; the end points do not occur. If the end points are necessary, try the sum
of two opposing right triangular distributions.
Distribution: Weibull
Distribution: Geometric
Distribution: Poisson
Syntax: P(a{,<s>}) a quantity
distributions of plants, shot noise, and so on. Note that the time between arrivals (defects)
is exponentially distributed.
References
Johnson, Norman L.; Samuel Kotz; and N. Balakrishnan. Continuous Univariate Distribu-
tions. Vol. 1. New York: John Wiley & Sons, 1994.
Law, Averill M. Simulation Modeling and Analysis, 4th ed. New York: McGraw-Hill, 2007.
Shooman, Martin L. Probabilistic Reliability: An Engineering Approach. Melbourne,
Florida: Robert E. Krieger, 1990.
0 tdf,␣
674
har01307_APPC_675.indd 675
Numerator Degrees of Freedom [df (Treatment)]
1 2 3 4 5 6 7 8 9 10 12 14 16 20 24 30 40 50 100 200
3 10.13 9.55 9.28 9.12 9.01 8.94 8.89 8.85 8.81 8.79 8.74 8.71 8.69 8.66 8.64 8.62 8.59 8.58 8.55 8.54 8.54
4 7.71 6.94 6.59 6.39 6.26 6.16 6.09 6.04 6.00 5.96 5.91 5.87 5.84 5.80 5.77 5.75 5.72 5.70 5.66 5.65 5.63
5 6.61 5.79 5.41 5.19 5.05 4.95 4.88 4.82 4.77 4.74 4.68 4.64 4.60 4.56 4.53 4.50 4.46 4.44 4.41 4.39 4.36
6 5.99 5.14 4.76 4.53 4.39 4.28 4.21 4.15 4.10 4.06 4.00 3.96 3.92 3.87 3.84 3.81 3.77 3.75 3.71 3.69 3.67
7 5.59 4.74 4.35 4.12 3.97 3.87 3.79 3.73 3.68 3.64 3.57 3.53 3.49 3.44 3.41 3.38 3.34 3.32 3.27 3.25 3.23
8 5.32 4.46 4.07 3.84 3.69 3.58 3.50 3.44 3.39 3.35 3.28 3.24 3.20 3.15 3.12 3.08 3.04 3.02 2.97 2.95 2.93
9 5.12 4.26 3.86 3.63 3.48 3.37 3.29 3.23 3.18 3.14 3.07 3.03 2.99 2.94 2.90 2.86 2.83 2.80 2.76 2.73 2.71
10 4.96 4.10 3.71 3.48 3.33 3.22 3.14 3.07 3.02 2.98 2.91 2.86 2.83 2.77 2.74 2.70 2.66 2.64 2.59 2.56 2.54
11 4.84 3.98 3.59 3.36 3.20 3.09 3.01 2.95 2.90 2.85 2.79 2.74 2.70 2.65 2.61 2.57 2.53 2.51 2.46 2.43 2.41
12 4.75 3.89 3.49 3.26 3.11 3.00 2.91 2.85 2.80 2.75 2.69 2.64 2.60 2.54 2.51 2.47 2.43 2.40 2.35 2.32 2.30
13 4.67 3.81 3.41 3.18 3.03 2.92 2.83 2.77 2.71 2.67 2.60 2.55 2.51 2.46 2.42 2.38 2.34 2.31 2.26 2.23 2.21
14 4.60 3.74 3.34 3.11 2.96 2.85 2.76 2.70 2.65 2.60 2.53 2.48 2.44 2.39 2.35 2.31 2.27 2.24 2.19 2.16 2.13
15 4.54 3.68 3.29 3.06 2.90 2.79 2.71 2.64 2.59 2.54 2.48 2.42 2.38 2.33 2.29 2.25 2.20 2.18 2.12 2.10 2.07
16 4.49 3.63 3.24 3.01 2.85 2.74 2.66 2.59 2.54 2.49 2.42 2.37 2.33 2.28 2.24 2.19 2.15 2.12 2.07 2.04 2.01
17 4.45 3.59 3.20 2.96 2.81 2.70 2.61 2.55 2.49 2.45 2.38 2.33 2.29 2.23 2.19 2.15 2.10 2.08 2.02 1.99 1.96
18 4.41 3.55 3.16 2.93 2.77 2.66 2.58 2.51 2.46 2.41 2.34 2.29 2.25 2.19 2.15 2.11 2.06 2.04 1.98 1.95 1.92
19 4.38 3.52 3.13 2.90 2.74 2.63 2.54 2.48 2.42 2.38 2.31 2.26 2.21 2.16 2.11 2.07 2.03 2.00 1.94 1.91 1.88
20 4.35 3.49 3.10 2.87 2.71 2.60 2.51 2.45 2.39 2.35 2.28 2.23 2.18 2.12 2.08 2.04 1.99 1.97 1.91 1.88 1.84
22 4.30 3.44 3.05 2.82 2.66 2.55 2.46 2.40 2.34 2.30 2.23 2.17 2.13 2.07 2.03 1.98 1.94 1.91 1.85 1.82 1.78
24 4.26 3.40 3.01 2.78 2.62 2.51 2.42 2.36 2.30 2.25 2.18 2.13 2.09 2.03 1.98 1.94 1.89 1.86 1.80 1.77 1.73
26 4.23 3.37 2.98 2.74 2.59 2.47 2.39 2.32 2.27 2.22 2.15 2.09 2.05 1.99 1.95 1.90 1.85 1.82 1.76 1.73 1.69
28 4.20 3.34 2.95 2.71 2.56 2.45 2.36 2.29 2.24 2.19 2.12 2.06 2.02 1.96 1.91 1.87 1.82 1.79 1.73 1.69 1.66
30 4.17 3.32 2.92 2.69 2.53 2.42 2.33 2.27 2.21 2.16 2.09 2.04 1.99 1.93 1.89 1.84 1.79 1.76 1.70 1.66 1.62
35 4.12 3.27 2.87 2.64 2.49 2.37 2.29 2.22 2.16 2.11 2.04 1.99 1.94 1.88 1.83 1.79 1.74 1.70 1.63 1.60 1.56
675
12/17/10 9:29 AM
APPENDIX D
CRITICAL VALUES FOR CHI-SQUARE DISTRIBUTION
2df,␣
676
677