Slide 1 of 46 Fundamental Simulation Concepts Chapter 2.

Slide 1 of 46

Fundamental Simulation Concepts

Chapter 2

Slide 2 of 46

Chicken and the Egg Issue

Slide 3 of 46

Or Egg and Chicken the Issue

Slide 4 of 46

Or Smoking Chicken and Smoking Egg Issue

Slide 5 of 46

What We’ll Do in Chapter 2

• Underlying ideas, methods, and issues in simulation

• Centered around an example of a simple processing system Discuss a sample problem Terminology Some basic statistical issues Overview of a simulation study

Slide 6 of 46

The System:A Simple Processing System

ArrivingBlank Parts

DepartingFinished Parts

Machine (e.g., Drill Press) (Server)

Queue (FIFO) Part in Service

4567

• General intent: Estimate expected production Waiting time in queue, queue length, proportion of time

machine is busy

• Time units Can use different units in different places … must declare Be careful to check the units when specifying inputs

Slide 7 of 46

Model Specifics

• Initially (time 0) empty and idle• Base time units: minutes• Input data (assume given for now …), in minutes:

Part Number Arrival Time Interarrival Time Service Time1 0.00 1.73 2.902 1.73 1.35 1.763 3.08 0.71 3.394 3.79 0.62 4.525 4.41 14.28 4.466 18.69 0.70 4.367 19.39 15.52 2.078 34.91 3.15 3.369 38.06 1.76 2.37

10 39.82 1.00 5.3811 40.82 . .

. . . .

. . . .

• Stop when 20 minutes of (simulated) time have passed

Slide 8 of 46

Goals of the Study:Output Performance Measures

•Total production of parts over the run (P)

• Average waiting time of parts in queue

• Maximum waiting time of parts in queue

Slide 9 of 46

Goals of the Study:Output Performance Measures (cont’d.)

• Time-average number of parts waiting in queue (i.e., average length of queue)

• Maximum number of parts in queue

• Average and maximum total time in system of parts (cycle time) (cycle time is time measured from arrival to departure)

Slide 10 of 46

Goals of the Study:Output Performance Measures (cont’d.)

• Utilization of the machine/server (proportion of time busy)

• Many other performance measures are possible (perhaps leading to information overload?)

Slide 11 of 46

Analysis Options

• Educated guessing Average interarrival time = 4.08 minutes Average service time = 3.46 minutes So (on average) parts are being processed faster than they arrive

– System has a chance of operating in a stable way in the long run, i.e., might not “explode”

– If all interarrivals and service times were exactly at their mean, there would never be a queue

– But the data clearly exhibit variability, so a queue could form If we’d had average interarrival < average service time, and this

persisted, then queue would explode Truth — between these extremes BUT, this type of guessing has its limitations (we need something better)

Slide 12 of 46

Analysis Options (cont’d.)

• Queueing theory (not all of this was part of assigned reading)

Requires additional assumptions about the model Popular, simple model: M/M/1 queue

– Interarrival times ~ exponential– Service times ~ exponential, indep. of interarrivals– Must have E(service) < E(interarrival) (i.e., average service time is

less than the average interarrival time, where “E” represents the “Expected Value.”)

– Steady-state (long-run, forever) (i.e., a stable line) – Gives exact analytic results through a mathematical formula

Problems: validity, estimating means, time frame (transientto steady state)

Often useful as first-cut approximation (helpful to move closer to a valid simulation model). Some formulas include:

time) E(service

time) ivalE(interarr 2

S

A

SA

S

,Ave. Waiting Time in Queue =

Slide 13 of 46

Mechanistic Simulation

• Individual operations (arrivals, service times) will occur exactly as in reality

• Movements, changes occur at the right “time,” in the right order

• Different pieces interact• Install “observers” to get output performance

measures• Concrete and clear approach- computer elements

parallel real world phenomena • Nothing mysterious or subtle

But a lot of details, bookkeeping Simulation software keeps track of things for you

Slide 14 of 46

Pieces of a Simulation Model

• Entities “Players” that move around, change status, affect and are

affected by other entities Dynamic objects — get created, move around, leave

(maybe) Usually represent “real” things

– Our model: entities are the parts Can have “fake” or “logic” entities for modeling “tricks”

– Breakdown demon (machine breakdown), break angel (server off duty)

Usually have many types of entities floating around Can have different types of entities concurrently Usually, identifying the types of entities is the first thing to

do in building a model

Slide 15 of 46

Pieces of a Simulation Model (cont’d.)

• Attributes Characteristic of all entities: describe, differentiate All entities have same attribute “slots” but different values

for different entities, for example:– Time of arrival– Due date– Priority– Color

Attribute value tied to a specific entity Like “local” variables (attributes can be assigned to specific

entities, and stick with the entities, or can even be changed) Some automatic in Arena, some you define

Slide 16 of 46

Pieces of a Simulation Model (cont’d.)

• (Global) Variables Reflects a characteristic of the whole model or system,

not of specific entities Used for many different kinds of things

– Travel time between all station pairs (like from bus stop to bus stop)– Number of parts in system– Simulation clock (built-in Arena variable)

Name, value of which there’s only one copy for the whole model (e.g., the queue length before the 3rd machine in an assembly line of 10 machines)

Not tied to entities, but could describe their group behavior (e.g., such as a queue consisting of entities, or parts, waiting to be serviced by a drill press)

Some built-in by Arena, you can define others

Slide 17 of 46

Pieces of a Simulation Model (cont’d.)

• Resources What entities compete for

– People– Equipment– Space

Entity seizes a resource, uses it, releases it Think of a resource being assigned to an entity, rather than

an entity “belonging to” a resource “A” resource can have several units of capacity

– Seats at a table in a restaurant– Identical ticketing agents at an airline counter

Number of units of resource can be changed during the simulation

Slide 18 of 46

Pieces of a Simulation Model (cont’d.)

• Queues Place for entities to wait when they can’t move on (maybe

since the resource they want to seize is not available) Have names, often tied to a corresponding resource Can have a finite capacity to model limited space — have

to model what to do if an entity shows up to a queue that’s already full

We usually watch the length of a queue, and the waiting time that entities are in it

Slide 19 of 46

Pieces of a Simulation Model (cont’d.)

• Statistical accumulators Variables that “watch” what’s happening Depend on output performance measures desired “Passive” in model — don’t participate, just watch Many are automatic in Arena, but some you may have to

set up and maintain during the simulation At end of simulation, used to compute final output

performance measures

Slide 20 of 46

Pieces of a Simulation Model (cont’d.)

• Statistical accumulators for the simple processing system (e.g.,) Number of parts produced so far Total of the waiting times spent in queue so far No. of parts that have gone through the queue Max time in queue we’ve seen so far Total of times spent in system Max time in system we’ve seen so far

Slide 21 of 46

Simulation Dynamics:The Event-Scheduling “World View”

• Identify characteristic events

• Decide on logic for each type of event to Effect state changes for each event type Observe statistics Update times of future events (maybe of this type, other

types)

• Keep a simulation clock, future event calendar which stores information

• Jump from one event to the next, process, observe statistics, update event calendar

Slide 22 of 46

Events for theSimple Processing System

• Arrival of a new part to the system Update time-persistent statistical accumulators (from last

event to now)– Current Max in queue, for example

“Mark” arriving part with current time (use later) If machine is idle:

– Start processing (schedule departure), Make machine busy, Tally waiting time in queue

Else (machine is busy):– Put part at end of queue, increase queue-length variable

Schedule the next arrival event

Slide 23 of 46

Events for theSimple Processing System (cont’d.)

• Departure (when a service is completed) Increment number-produced stat accumulator Compute & tally time in system (now - time of arrival) Update time-persistent statistics (as in arrival event) If queue is non-empty:

– Take first part out of queue, compute & tally its waiting time in queue, begin service (schedule departure event)

Else (queue is empty):– Make the machine idle

Slide 24 of 46

Events for theSimple Processing System (cont’d.)

• The End Update time-persistent statistics (to end of the simulation) Compute final output performance measures using current

(= final) values of statistical accumulators

Slide 25 of 46

Some Additional Specifics for theSimple Processing System

• Simulation clock variable (internal in Arena)

• Event calendar: List of event records: [Entity No., Event Time, Event Type] Initially, schedule first Arrival

• State variables: describe current status Server status B(t) = 1 for busy, 0 for idle Number of customers in queue Q(t) Times of arrival of each customer now in queue (a list of

random length)

Slide 26 of 46

Simulation by Hand

• Manually track state variables, statistical accumulators

• Use “given” interarrival, service times

• Keep track of event calendar

• “Lurch” clock from one event to the next

• Will omit times in system, “max” computations here (see text for complete details- but not assigned as a reading)

Slide 27 of 46

Event-Scheduling Logic via Programming

• Clearly well suited to standard programming

• Often use “utility” routines (built in) for: List processing Random-number generation Random-variate generation Statistics collection Event-list and clock management Summary and output

• Main program ties it together, executes events in order

Slide 28 of 46

Simulation Dynamics: The Process-Interaction World View

• Identify characteristic entities in the system• Multiple copies of entities co-exist, interact,

compete• Tell a “story” about what happens to a “typical”

entity• May have many types of entities, “fake” entities

for things like machine breakdowns*• Usually requires special simulation software

Underneath, still executed as event-scheduling

• The view normally taken by Arena

*A fake entity could act like a switch, used to turn something ON or OFF

Slide 29 of 46

Randomness in Simulation

• Need more than one “replication” — a sample of size one (not worth much, like a single coin flip)

• Made a total of five replications:

• Confidence intervals for expected values: In general, For expected total production,

)/()( 2/1,1 nstX n )/.)(.(. 56417762803

042803 ..

Notesubstantialvariabilityacrossreplications

(e.g., 95% confident)

Slide 30 of 46

Comparing Alternatives

• Usually, simulation is used for more than just a single model “configuration” (i.e., add a server, or compare draglines with bucket-wheel excavators)

• Often want to compare alternatives, select or search for the best (via some criterion)

• Simple processing system: What would happen if the arrival rate were to double? Cut interarrival times in half Rerun the model for double-time arrivals Make replications

Slide 31 of 46

Overview of a Simulation Study

• Understand the system

• Be clear about the goals

• Formulate the model representation

• Translate into modeling software

• Verify “program”

• Validate model

• Design experiments

• Make runs

• Analyze, get insight, document results