A Brief Introduction to Discrete-Event
Simulation Modeling and Analysis
Ming Zhou, PhD., Associate Professor
Indiana State University, Terre Haute, IN 47809, USA
(812)237-3983; imming@isugw.indstate.edu
Slide 1: Introduction to Simulation
Systems and models of a system
 Concept of a system (input, output, process,
resources, behavior, performance measures)
 Interest of studying a system (design, planning,
control, improvement, and optimization)
 Models of a system: representation of real systems
 Physical models
 Logical or mathematical models
System and models of system
System
Study/experiment
with the
actual system
Study/experiment
with a model of
the system
Physical
model
Mathematical or
logical model
Analytical
model
Simulation
model
Slide 2: Introduction to Simulation
Studying a system via analytical model v.s. simulation
model (prescriptive v.s. descriptive models)


Analytical model  Performance measures are
expressed as mathematical functions of input
parameters, result is exact and close form solution,
applicable only to simple problems.
Simulation model  a logical model that is
evaluated (numerically) over a time period of
interest, Performance measures are estimated from
model-generated data with statistical procedures,
applicable to systems of any complexity.
Slide 3: Introduction to Simulation
Why use simulation models?
It is often of interest to study a real-world system to
generate knowledge on its behavior or dynamics. However
it is usually necessary to use a simulation model for the
following reasons:
Experimentation with the real system is often disruptive
(e.g. study of a flow-line manufacturing process)
Experimentation with the real system is not cost-effective
(e.g. study of large logistic/distribution center)
Experimentation with the real system is simply impossible
(e.g. study of space rocket launching operations)
Slide 4: Introduction to Simulation
Definition of simulation
The process of designing and creating a computerized
model of a real or proposed system for the purpose of
numerical experiment to develop better understanding of
the behavior/dynamics of that system under a given set
of conditions.
Simulation is a powerful tool for design, modeling,
analysis, and optimization of systems. It is one of the
target technologies for the 21st century identified by the
NRC, NIST, NSF, IIE, SME, ASME and many others …
Slide 5: Introduction to Simulation
Types of simulation
 Static v.s. dynamic (Is time a factor?)
 Continuous v.s. discrete (nature of change along time)
 Deterministic v.s. stochastic (Is randomness
important?)
Application of simulation (See demos of application)
- Manufacturing
- Healthcare
- Military systems
- Entertainment
- Logistics & transportation system
- Service systems
- Telecommunication
- Robotics simulation
Slide 6: Introduction to Simulation
Application of simulation (in terms of decision making)
- System design and evaluation
- Process/system improvement and optimization
- Policy or strategy evaluation (“What-if” analysis)
Limitations of simulation: Simulation cannot:
- Provide exact solutions
- Find optimal solutions (in exact form)
- Compensate for inadequate data or poor
management decisions
- Provide fast and easy solutions to complex problems
Slide 7: Introduction to Simulation
Implementation of simulation
 By hand (for small problems, e.g. Buffon Needle
problem)
 By computers with software (3 levels of
abstraction):
 Programming in general-purpose language
(e.g., C/C++,Pascal, Fortran)
 Simulation language (SIMAN, GPSS, SLAM)
 High level simulators (GUI based, menu-driven,
such as ARENA©, AutoMod©, ProModel©)
Issues of modeling efficiency, flexibility and ease of
implementation, hierarchical structure.
Issues related to level of modeling constructs: modeling
efficiency versus modeling flexibility
Modeling flexibility
Modeling
efficiency
Level of modeling
abstraction hierarchy
Slide 8: Introduction to Simulation
Consider a simple example:
Simulation of a single server processing system (e.g.,
an M/M/1 queuing system)



System components and their relations (needs for
abstraction)
System states and constraints
Problem statement (goal of the study: what
output/performance measures to be collected or
computed?)
Slide 9: Introduction to Simulation
A graphical model of a M/M/1 system
Server
Arrivals
Departures
Waiting line
(queue)
Arrival time and service time are random variables
Slide 10: Introduction to Simulation
Elements of a simulation model:
Entities: items being processed by and flow through
the system, e.g. parts, cars, customers
Attributes: properties/characteristics assigned to
entities, e.g. part types, time arrived in a queue
Variables: changeable quantities defined to reflect the
characteristics of the system, e.g. we may define two
state variables for a M/M/1 system:
 Server status (states): idle or busy
 Number of items waiting in queue
Slide 11: Introduction to Simulation
Events: an event is an occurrence of something that
changes the state of the system (e.g. arrival or
departure of a customer in a M/M/1 system)
Resources: means by which to process entities (e.g.
machines, operators, fork-trucks)
Queues (buffers, waiting lines): storage space for
entities waiting for required resource)
Activities/processes: an activity is a period of time
during which an entity (entities) is serviced (e.g.
processed or transferred). The duration of an activity
is known a priori, and can be scheduled (e.g.
processing time, transfer time)
Slide 12: Introduction to Simulation
Statistical accumulators: variables that collect and
keep track of statistics during the progress of
simulation to obtain required output performance
measures.
Simulation clock: a mechanism to keep track of
current (simulated) time in a simulation. It lurches
from the time of one event to the time of next event.
arrival2
arrival3
departure1
t1
t2
t3
Jumps of simulation clock
Slide 13: Introduction to Simulation
Event-driven simulation: simulation is centered around
events that occur as a consequence of activities or
delays. Simulation keeps track of events that are
assumed to occur in (simulated) future, and update
system states and move the simulation clock as
events occur sequentially. Need a mechanism to
determine and control:
 What type of event to occur ? (adding new event)
 Which event should be scheduled to occur next?
 What to do when an event occurs? (e.g. updating
system states and statistical accumulators)
Slide 14: Introduction to Simulation
Event transition/interaction diagram
Arrival
Departure
Event-driven simulation logic flow chart
Slide 15: Introduction to Simulation
Process-oriented simulation: this approach emulates
the flow of an entity through the system, i.e. centers
on the process that the entity undergoes. Consider
main steps that an entity goes through a single server
M/M/1 simulation process:
 Create itself (mark the time-in)
 Wait in queue for a resource
 Seize the resource (take itself out of the queue)
 Delay a duration equal to its service time
 Release the resource
 Increment production-counter/accumulator and
tally flow time
 Dispose itself and leave the system
Slide 16: Introduction to Simulation
Process-oriented method is intuitive and simple for
understanding, and is popularly used in modeling.
Most simulation combines both approaches: using an
event-scheduling approach to control the execution
but allowing user to model the system in processoriented front-end (user interface), e.g. ARENA©.
Randomness in simulation
- Random input and therefore random output
- Replications of random experiment
Slide 17: Introduction to Simulation
General steps in a simulation study









Understand the system
Define problem (goals/objectives, constraints, scope)
Formulate a simulation model (conceptual design)
Implement the model (translate into modeling software)
Verify and Validate the model (Pilot runs)
Design the experiments
Run the experiments (Production runs) with the model
Analyze outputs/results
Interpret, document, present and implement the results
Slide 18: Simulation with ARENA©
What is ARENA©?
Arena is a Microsoft Windows based application
package for simulation modeling and analysis. It is a
product of Rockwell Software, Inc.
Current version: 7.0 (2003)
ARENA’s User interface: GUI, interactive and menu
driven.
Slide 19: Simulation with ARENA©
Structure of an ARENA simulation model: an ARENA
simulation model consists of two types of modules (i.e.
fundamental building blocks):
 Logic modules (flowchart modules): perform logical
functions of a simulation model, and control the
logic of how entities flow through the system
 Data modules: define the characteristics of process
elements (e.g. Entities and Resources), specify and
implement experimental conditions of simulation
models (number of replications, run length, etc.)
 Modules are placed in groups called “panels”
Slide 20: Simulation with ARENA
Some logic modules in the Basic Process Panel:
Create module: Create entities (generate arrivals of
entities) and define characteristics of entity arrivals
(time between arrivals, entity type, batch size, etc.)
Process module: Process entities through required
operations. This module includes a resource, its
queue and a processing time.
Dispose module: Represent entities leaving the
system and dispose the entities. It also
accumulates basic statistics for output reporting.
Slide 21: Simulation with ARENA
Some Data modules
 Entity data module: define detailed properties
associated with an entity type
 Resource data module: define characteristics of a
resource (capacity, capacity change pattern)
 Queue data module: define characteristics of a queue
associated with a resource (e.g. queuing discipline
FIFO, LIFO, etc.)
Connection of logic modules: logic modules must be
connected in right order through two types of connection:
Connect: instant transfer of entities between modules
(zero travel time), or Route: model non-zero travel time
transfer of entities
Slide 22: Simulation with ARENA
Animation utilities: ARENA© provides utilities to
animate entity flows and resources used in a
simulation model.
Dynamic plots (graphical representation of output
performance measures): select data object  select
information type  select display mode
Set up running conditions of a simulation model
through Run/Setup dialogue window
Slide 23: Simulation with ARENA
Generating (output) summary report on the results of
a simulation: 3 types of information/statistics are
collected and reported:
 Tally variables (e.g., flow/cycle-time, wait-in-queue
time, etc., time intervals)
 Discrete-Change Variables: time-persistent
statistics such as resource utilization, timeaverage number in queue, etc.
 Counters: integral counts by part status (e.g.
number of salvaged parts)
Slide 24: Simulation with ARENA
Output performance measures:
 Total production
 Average and maximum waiting time in queue
 Average and maximum flow time (cycle time) of
entities
 Average queue length (time-average number of
parts in queue)
 Maximum queue length
 Utilization of the machine (proportion of time busy)
Slide 25: Simulation with ARENA
Problem
Model-based
Problem solving
Establishing modeling
Purpose/objectives
System
data
Model
Modeler
Analyze
outputs
Decisions
Policies
Slide 26: Simulation with ARENA
A basic simulation modeling approach:






Dividing system into sub-models (functions or module
design to capture all the logical activities)
Developing a control/flow logic to define interactions
and the configuration of the modules
Specify input distribution and data structures
Selecting ARENA modules to model the activities of
the system at proper level of details.
Connecting logic modules in right order to establish
the logic flow of the simulation model
Selecting data module(s) to specify and implement
experimental conditions, data structure definitions, and
output requirement
Slide 27: Simulation with ARENA
An example: Simulation of an electronic assembly and
test system (EAT):




Two part types with different arrival rates
Two part types share one Sealer station, the
processing time at this station depends on part type
Parts are transferred between stations with nonzero travel time
Parts are routed (after Sealer or Rework station) to
different destinies based on inspection result (pass
or fail according to certain probabilities)
Slide 28: Simulation with ARENA
Part A
20%
Part A Prep
Expo(5)
Rework
9%
Tria(1,4,8)
Expo(45)
80%
Sealer
Part B
Part B Prep
Expo(30)
Batch 4
Tria(3,5,10)
Part A
TRIA(1,3,4)
Scrapped
Salvaged
and
shipped
91%
Part B
WEIB(2.5,5.3)
Example: an electronic assembly and testing system
Shipped
Slide 29: Simulation with ARENA
ARENA concepts
Attributes and assignment of attributes: attributes are
properties that can be defined to characterize an
entity type through a logic construct called Assign
module (e.g. we can define an attribute called Sealer
processing time for each part type, then use the value
of this attribute as processing time when the part
arrives in Sealer station)
Decision making: for simple binary decision making
(only two results possible), we can use a Decide
module to model the needs of routing parts based on
the result of a pass/fail inspection.
Slide 30: Simulation with ARENA
Decision making: route entities based on condition v.s.
based on probability; two-way v.s. N-way decision
making
Modeling strategy for the EAT system:
 Use two Create modules to model the two streams
(one for each part type) of arriving parts
 Use Assign module to define Sealer processing time
as an attribute for each part type created
 Use Decide module to model the binary decision
making after Sealer and Rework operations (routing
parts based on inspection result: pass or fail with
specified probabilities)
Slide 31: Simulation with ARENA
Demonstration
Constructing simulation model (Model4-01)
Running the model
Viewing results and some discussion
Slide 32: Enhanced Resource Representation
Assumptions about resource


Fixed capacity (single resource with capacity of 1)
Resource is 100% reliable (no failure/downtime)
Practical characteristics of resource (e.g. machines)


Capacity changes over time (e.g. number of
operators per shift, scheduled breaks …)
Failures/breakdown of resources (e.g. machine
failures that occur randomly)
Slide 33: Enhanced Resource Representation
Advanced resource representation:
Schedule: an ARENA’s built-in construct that allows
modeler to vary the capacity of a resource over
time, i.e. to model planned capacity changes.
A schedule is defined by a sequence of timedependent capacity changes.
A resource schedule can be defined in either
Resource or Schedule data module.
States: ARENA’s built-in constructs to represent the
status of a resource in terms of capacity,
particularly to model Failures and Downtimes.
Slide 34: Enhanced Resource Representation
ARENA defines a resource with 4 states:
 Idle: no entity has seized the resource, it is
available.
 Busy: some entity seizes the resource, it is not
available.
 Inactive: the resource is made unavailable for
allocation, e.g. scheduled break-time (capacity
decreases to zero)
 Failed: resource is unavailable and requires a
repair time
Slide 35: Enhanced Resource Representation
Failures of a resource can also be modeled as a
sequence of characterized random time intervals , e.g.
we can define a capacity of 1 for the uptimes and 0 for
repair or downtimes (both are random intervals)
Capacity
uptime
1
0
downtime
Time
Slide 36: Enhanced Resource Representation
Random failures (where uptime and downtime are
random variables) of a resource can be modeled
using “Failure” construct, a data module used to
model the random events that cause the resource
become unavailable (e.g. machine breakdown)
 Count-based v.s. time-dependent failures (e.g.
tooling/bulb failures, machine breakdowns)
 Uptime v.s. downtime distributions: time between
machine breakdowns is usually a random variable
following a probability distribution. We have to use
either a theoretical or an empirical distribution to
model the behavior of downtime (uptime).
Slide 37: Enhanced Resource Representation
Modify the example EAT system to incorporate resource
schedules:
 Define a resource Schedule for Rework station to
model the planned change of capacity (1 for first shift
and 2 for second shift)
 Use a Failure data module to model the random
failures of the resource at Sealer station (fail every
expo(120) with a repair time expo(4) minutes)
 Demonstration with Model 4-02
Data and information collection
Slide 38: Enhanced Resource Representation
Saving statistical data/information
 Needs for saving and post-processing data
generated from simulation runs.
 Mechanism: Statistics module  a data module
(from Advanced Process panel) that defines
statistical data to be collected and saved into
files (for post-analysis).
 Three types of data file (.dat files):
Time-persistent (or Discrete-Change) statistics
Tally observation data
Counters and frequency data
Slide 39: Enhanced Resource Representation
Practice with enhanced model (Model 4-02)
Results of running enhanced model (Summary report
from)
Output analyzer: post-run analysis of simulation data.
It analyze, display and draw statistical conclusions
based on the simulation results.
Slide 40: Modeling Entity Type Dependent Flow
A small manufacturing system example with new
characteristics:
 Different part types flow through the same system
 Entities flow based on their types (e.g. parts are
routed by different processing plans)
 Multiple resources with different capacities in the
same workstation
 Entities transfer between stations with nonzero
transfer time
Study objectives: Average flow time (cycle time) of each
part type, resource utilization, time and number in queue.
Slide 41: Modeling Entity Type Dependent Flow
Cell 1
Cell 2
Parts
Departure
arrival
Cell 4
Cell 3
A small manufacturing system
Slide 42: Modeling Entity Type Dependent Flow
Characteristics of this system:
Three different part types. Each has a different
sequence of station visitation (i.e. follow different
process plans)
Cell 3 has two machines that are NOT identical (multiple
resource with different capacity at the same station)
Different Part routings (process plans):
Part type 1: Cell 1  Cell 2  Cell 3  Cell 4
Part type 2: Cell 1  Cell 2  Cell 4  Cell 2  Cell 3
Part type 3: Cell 2  Cell 1  Cell 3
Entity transfers with a nonzero time between stations
Slide 43: Modeling Entity Type Dependent Flow
Performance measures
- Cycle times of three part types
- Utilization of resources
- Work-in-process (WIP) of parts
Slide 44: Modeling Entity Type Dependent Flow
New modeling concept: Create different entity/part
types using a Discrete distribution
 To create several types of entities according to
certain probabilities, ARENA assign each new
entity to an attribute called “Part Index” (or part
type) that follows a discrete distribution.
 Example: to create 3 part types according to
probabilities 0.31, 0.44, and 0.25, we randomly
assign Part Index 1, 2, and 3 to each arriving entity
according to a probability distribution:
DISC (0.31, 1, 0.75, 2, 1.0, 3)
 Enter values in pairs: cumulative probability and
part type
Slide 45: Modeling Entity Type Dependent Flow
New modeling concept/construct: Sequence

Sequence is a data module that can route entities
according to a predetermined sequence of station
visitations. We use Sequence to model parts flow with
different process plans.

Sequence consists of a list of destination stations and
optional assignment of attributes (e.g. processing time)
at each station in the sequence.
Slide 46: Modeling Entity Type Dependent Flow
New modeling concept: Stations and station transfers. To
model the sequence dependent flow, we need to clearly
define the boundary of a workstation (e.g. entry and leaving
points of a station) and a mechanism to route entities
between stations based on their sequencing requirements.
Station module (Advanced Transfer panel): model the
physical location of a process and define an entry point for
the station so that it can be recognized by different entity
routings (i.e. sequences) in a simulation model.
Route module (Advanced Transfer panel): model entity
routings based different sequencing requirements with
nonzero transfer time.
Slide 47: Modeling Entity Type Dependent Flow
How to implement Sequence dependent flow?
 Define Stations for all processes using Station
modules.
 Define sequences for all entity/part types using a
Sequence module.
 Associate each sequence (i.e. a process plan)
with each arriving entity through the assignment of
an entity attribute, i.e. assigning each entity a
sequence attribute (use an Assign module).
 Route entities between stations using a Route
module.
Slide 48: Modeling Entity Type Dependent Flow
Each work cell will be modeled as a
Station-Process-Route module sequence.
Cell 1 Station
(entry point)
Cell 1 Process
Cell 1 Route
(leaving point)
Example: logic modules for Cell 1 (also see Model5-01)
Slide 49: Modeling Entity Type Dependent Flow
How to model a station that has multiple machines of the
same type with different processing time? (e.g. Cell 3)
Use a Set of resource, not a single resource. Define a
resource set “Cell 3 Machines” with two members
(New machine and Old machine) for Cell 3. Default
rule for resource selection is “cyclical”.
Assign each machine an index and define a variable
Factor as a function of machine index.
Define processing time as variable using expressions,
e.g. Process time = ProcessingTime * Factor(Index),
where ProcessTime is defined through Sequence.
In Process module, select “Resource Set”
Slide 50: Modeling Entity Type Dependent Flow
Practice and demonstration with an Example:
Small Manufacturing System (Model 6-02)
 Define logic modules: part arrivals, stations/cells,
part departures;
 Define data modules: use Sequence module to
control parts flow; use a Record module and a Set
module to collect part cycle times.
 Define experimental conditions;
 Run the simulation model and discuss results.
Show BLOCK diagram of Model
Slide 51: Modeling Entity Type Dependent Flow
Cell 1
Cell 2
Arrival
Depart
Cell 4
A block diagram
model of SMS
Cell 3
Resource
set: Cell 3
machines
Member 1
Cell 3 New
Member 2
Cell 3 Old