Simulation Concepts

Dr. Jason Merrick

Simulation with Arena — A Quick Peek at Arena C3/2

• The above was just one “replication” -- a sample of size one (not worth much)

• We will do multiple replications:

• Confidence intervals on expectations

– e.g., 95% c.i. on E(avg. time in queue):

• What about your replications?

n

stX n ,

Replication 1 2 3 4 5 Average Std DevAverage time in queue 0.19 1.12 3.72 0 0 1.01 1.59Average number in queue 0.27 0.3 0.99 0 0 0.31 0.41Machine utilization 0.85 0.91 1 0.32 0.37 0.69 0.32Number of samples 5

Confidence IntervalLower Upper

Average time in queue 0.98 1.59Average number in queue 0.31 0.41Machine utilization 0.69 0.32

Randomness in Simulation

Simulation with Arena — A Quick Peek at Arena

Simulation Replications

• Inter-arrival Times– 9.84, 0.44, – 2.39, 2.63, 4.82, 3.98– 2.90, 2.54, 1.96, 3.29– 0.32, 3.54, 3.98, 0.49– 4.79, 1.45

• Service Times– 8.72, 3.05– 1.98, 1.60, 8.79, 16.23– 2.03, 10.46, 4.15, 0.90– 3.11, 1.42, 0.62, 3.70– 2.67, 2.77

Simulation with Arena — A Quick Peek at Arena C3/4

Comparing Alternatives

• Usually, simulation is used for more than just a single model “configuration”

• 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 inter-arrival times in half– Rerun the model for double-time arrivals– Make five replications

Simulation with Arena — A Quick Peek at Arena C3/5

Results: Original vs. Double-Time Arrivals

• Note variability

• Danger of making decisions based on one (first) replication

• Hard to see if there are really differences

• Need: Statistical analysis of simulation output data

0 1 2 3 4

Original Model

Double-Time Model1

1

Total Production

0 1 2 3 4

Original Model

Double-Time Model

Average Time in Queue5

1

1

3 54 8 9

Original Model

Double-Time Model

Average Flowtime11

1

1

76 10

0 1 2 3 4

Original Model

Double-Time Model1

Average Number in Queue

1

0.4 0.6 0.8 1.0

Original Model

Double-Time Model1

1

Machine Utilization

Simulation with Arena — A Quick Peek at Arena C3/6

Scheduling Dynamics: The Event-Scheduling World

View• Identify characteristic events—change state

• Decide on logic to: effect state changes for each event type, observe statistics

• Keep a simulation clock, future event calendar

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

• Stopping rule

• Usually done with general-purpose programming language (C, FORTRAN, etc.)

Simulation with Arena — A Quick Peek at Arena C3/7

Events for ourSimple Processing System

Arrival of a new part

Update timepersistent statisticsMark arrival time

Machinebusy?

Start processingMake machine busyTally time in queue

Go to end of queueIncrease queue length

Schedule next arrival

No Yes

Departure of completed part

Increment number producedCompute & tally flowtime

Update time-persistent stats

QueueEmpty

Start processing next partTally time in queue

Schedule departure eventMake machine idle

No Yes

Simulation with Arena — A Quick Peek at Arena C3/8

Events for Simple Processing System (cont’d.)

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

values of statistical accumulators

• After each event, the event calendar’s top record is removed to see what time it is, what to do

• Also must initialize everything

• This is not the only way to view a simulation

Simulation with Arena — A Quick Peek at Arena C3/9

Simulation Dynamics: The Process-Interaction World View

• Identify characteristic entities in the system

• Tell a “story” about what happens to a “typical” entity– Multiple copies of entities co-exist, interact, compete– “Code” is non-procedural

• Usually requires special simulation software

• This is the view normally taken by Arena

• Underneath, still SIMAN executes the simulation using event-scheduling

Simulation with Arena — A Quick Peek at Arena

Process View of theSimple Processing System

Entity enters the system

Entity goes toend of queue

Is the serverbusy?

Start processingSeize the machine

Stay in queue

No

Yes

• Mark departure time

• Calculate flow time

• Increment total production

• Increment queue length

• Mark arrival time at queue

When service time is finished release

the server

Entity leaves the system

• Mark arrival time

• Decrement queue length

• Calculate time in queue

Simulation with Arena — A Quick Peek at Arena

Process View

• Used in most simulation languages

• Much easier to think about

• Do not have to define separate event logic for each possible event

• Similar to flow charting in business process analysis

• Leaves the complicated event programming to the simulation software designer

Simulation with Arena — A Quick Peek at Arena

Simulation as a Tool

• Simulation can be used for– Comparison

• To compare system alternatives and their performance measures across various factors (decision variables) with respect to some objectives

– Prediction• To predict the behavior of the system at some future point in time.

– Investigation• To learn about and gain insight into the behavior of the system

given various inputs.

Simulation with Arena — A Quick Peek at Arena

Objectives of the Simulation Study

• These are given in the "To" + "Action verb" + "Qualifiers" format.

• The objectives will assist in identifying decision variables, output measures, and presentation requirements.

• Examples– To investigate how to improve system throughput. (rather

loose)– To compare the cost and throughput changes given an

increase from 2 to 3 machines available.

Simulation with Arena — A Quick Peek at Arena

Complex Systems

• A system is– a group of interacting elements functioning as a complex

whole (American Heritage Dictionary)– a group of objects that are joined together in some regular

interaction or interdependence towards the accomplishment of some purpose (B,C&N)

• Must decide on an artificial boundary for the system

• The system state is the collection of variables that “describe” the system at any given time

Simulation with Arena — A Quick Peek at Arena

System Description

• A verbal and/or pictorial representation of the major elements of the system under study– Especially the flow characteristics of entities passing

through the systems.

• Distill the system description down to a "text book" word problem for performing the study. – Graphical descriptions, flow charts, etc..

• Get buy in for the system description from– system experts– management– decision makers

Simulation with Arena — A Quick Peek at Arena

Simulation as a Decision Making Tool

• Input variables– List all input data and its form– e.g. if it needs to be extracted from a file in a certain format.– Pay close attention to the probability distributions and their parameters.

• Output variables– A formal listing and description of the outputs required including all

statistical measures to be observed.

• Decision variables– List the factors and their levels which are to be varied during the

experiments.

Simulation with Arena — A Quick Peek at Arena C3/17

Overview of a Simulation Study

• Understand the system– It is not possible to model a system without first observing and

understanding it– Visit the system and observe– Go to experts with a deep understanding of the system– ask them how the system works

• Be clear about the goals– What are the project objectives?– What do you want to get out of this study?

• understanding the system

• testing alternative configurations

– The simulation you build cannot do everything - time and money constraints

– Tell management what you will deliver ahead of time

Simulation with Arena — A Quick Peek at Arena

Overview of a Simulation Study

• Formulate the model representation– What level of detail is required for the project objectives– What needs to be modeled in detail?– What can be modeled at a higher level?– What is the system boundary?– What are the entities, attributes, global variables, output variables,

decision variables of interest?– Make the management/decision makers aware of the modeling

assumptions before building the model– To get buy in you will need to speak in English, not mathematics

Simulation with Arena — A Quick Peek at Arena

Overview of a Simulation Study

• Translate into modeling software– Represent the modeling assumptions in the simulation software– If there are difficulties, talk about them– It is often beneficial to go back and check how the system really works

to get past implementation problems– Show system experts an animation of the simulation as you go along

• Verify “program”– Try obvious inputs and look for the obvious outputs– Test extreme inputs to see what happens– Walk through the program logic– Structure any code to avoid confusion– Output your inputs to ensure they follow your assumed input processes

Simulation with Arena — A Quick Peek at Arena

Overview of a Simulation Study

• Validate model– Does model adequately represent real world system?– Are model generated behavioral data characteristic of real world

system's behavioral data?– Does the model's user have confidence in model's results? (credibility)– Turing Test - people knowledgeable about the system are asked to

examine one or more sets of system data as well as sets of model data without knowing which sets are which, (can they tell the difference)

• Design experiments– What input variables do you want to test the effect of?– What decision variables do you want to test the effect of?– What alternative configurations of the system do you want to test?

• Make runs– Go get a cup of coffee

Simulation with Arena — A Quick Peek at Arena

Overview of a Simulation Study

• Analyze– Carry out statistical analysis to make accurate and precise statement

about the results

• Get insight– Can you understand the results at a gut feeling level?– Can you explain the logic behind your results?– Remember there is a world outside your model– Be sensitive to the implications of what you are saying

• Document results– You cannot present your analysis to all interested parties– Good documentation is readable by a non-simulation expert– Put the technical stuff in appendices