Digital Systems Simulation 56:178 M. C. (Jothi) Jothishankar, Ph.D. Advanced Manufacturing...

Post on 02-Jan-2016

231 views 3 download

Tags:

Transcript of Digital Systems Simulation 56:178 M. C. (Jothi) Jothishankar, Ph.D. Advanced Manufacturing...

Digital Systems Simulation 56:178

M. C. (Jothi) Jothishankar, Ph.D.

Advanced Manufacturing Technology

Rockwell Collins

Course Website

css.engineering.uiowa.edu/~dss

Username: Not Necessary

password: Not Necessary

Grading Method

Homework 25%

Midterm Exam 20%

Term Project 30%

Final Exam 25%

Homework and Exams

Homework is due at the beginning of class

on the day it is due.

— Late submissions are not accepted.

Two in class exams

— Mid term, Final exams

— Exams are closed book.

Calendar

Project Proposal and presentation September

16

Mid Term October 7

Project Report December 1

Project Presentations December 2

and 9

Final Exam Final Exam Week

(December 16)

Course Communication

My email: mcjothis@rockwellcollins.com

319-295-2111 (O)

319-621-5637 (C)

Office Hours: Tuesdays: 5.00 pm to 6.30 pm. Room 1139 SC

TA: Chun-Ling Chuangcchua@engineering.uiowa.edu

Office Hours: Wednesdays: 10.30 am to 12.00 pm

(Or by appointment). Room 3217 SC

Natalie Vanosdel

nvanosde@engineering.uiowa.edu

Office Hours: Mondays & Fridays: 1.30 pm to 2.20 pm

(Or by appointment). Room 3217 SC

Goal of This Course

At the end of this course, you should:

— Be familiar with principles of discrete event simulation

— Be able to identify systems amenable to simulation

— Build models for such systems

— Be able to identify suitable performance metrics

— Design and implement simulation programs

— Have experience with a modern simulation tool

— Be familiar with basic statistical questions

— Be aware of common pitfalls

Emphasis is on practical problems and questions, not on theory

Course Topic

Evaluate performance of a system

Three classical approaches:

—Experiments - measure performance of an actual system at work

—Analytical Methods - Use mathematical equations to describe system performance

—Simulation - Build model of the system and use it to numerically evaluate system performance

Course Topic

What is a system?

What are operations of a system?

What is performance?

On what does performance depend?

What is a model?

How to build a model?

How to numerically evaluate it?

How to interpret the results of such an evaluation

Non-Goals of This Course

Mathematical analysis tools for performance evaluation

Experimental approaches

Statistics course

Programming course

What is a System?

A system is a group of components, that mutually affects each others behavior, working together toward a common goal taking inputs and producing outputs.

You can describe a system by:

Specifying the components the system consists of.

Describing the characteristics of the components.

And finally specifying the relations between these components.

Example: Transaction Processing System

SalesPurchases Supplier Customer

FactoryRaw Material Finished Goods

• Purchase Order• Invoice

• Work Orders• Pay checks

• Sales Order• Customer Payments

Purchasing Accounting Sales

Marketing Work In Progress

Inventory

Example: Information System

An organized combination of people, hardware, software,

communications network, and data resources that collects,

transforms, and disseminates information in an organization.

InformationSystems

PeopleTechnology

Organizations

Environment

System

We will describe, model, and analyze systems

System: A group of interacting elements

System is defined by its purpose or function

System can be in different states

State can be expressed by the values of a set of variables

Dynamic systems change their state over time

Types of Systems

State can be continuous or discrete

In continuous systems, the state of the system is continuous function of time (airplane flying, Earth turning, etc)

In discrete systems, the state of the system changes instantaneously in separate points of time

Which rules govern the process of state changes?

Which level to choose?

How to describe the system?

Models

If the actual system is not available for investigation, a model of the system can be constructed with approximations and assumptions.

Model is built to capture relevant properties of the original system

Models can be:

— Physical Models: scale representation of system (Flight simulators)

— Mathematical Models: Represent system with appropriate mathematical or logical formalism (an airplane is described by the laws of aerodynamics)

We will only consider mathematical models

Studying Logical Models

If model is simple enough, use traditional mathematical analysis … get exact results, lots of insight into model

— Queueing theory

— Differential equations

— Linear programming

But complex systems can seldom be validly represented by a simple analytic model

— Danger of over-simplifying assumptions … model validity?

Often, a complex system requires a complex model, and analytical methods don’t apply … what to do?

Computer Simulation

Broadly interpreted, computer simulation refers to methods for studying a wide variety of models of systems

— Numerically evaluate on a computer

— Use software to imitate the system’s operations and characteristics, often over time

Can be used to study simple models but should not use it if an analytical solution is available

Real power of simulation is in studying complex models

Simulation can tolerate complex models since we don’t even aspire to an analytical solution

The Bad News

Don’t get exact answers, only approximations, estimates

— Also true of many other modern methods

— Can bound errors by machine roundoff

Get random output from stochastic simulations

— Statistical design, analysis of simulation experiments

— Exploit: noise control, replicability, sequential sampling, variance-reduction techniques

— Catch: “standard” statistical methods seldom work

Models

Models can be:

— Static— a model where only a certain, fixed state of a system, is

considered; state changes are not taken into account (Ex: throwing dice)

— Dynamic— reflect the system state changes as it evolves over time

(Ex: Bank)

Models can be:

— Continuous Models— describes the system such that the states variables are a

continuous function of time (Ex: Chemical plants)

— Discrete Models— change of state only happens in discrete, well separated

instances of time; the state of the model can only change when an event occurs (but need not necessarily change at every event) (Ex: Parts manufacturing)

Models

Models can be:

— Deterministic Models: a model where the evolution of state is completely described such that it only depends on the initial state (Ex: reserved seats at Hancher)

— Stochastic Models: a model where the evolution of state depends on random events (random in both time of occurrence or nature); output/results for such model not only depend on initial state but also on the values of random variables; there is no a single (fixed) output for such models (Ex: seating at a restaurant)

Different Kinds of Simulation

Static vs. Dynamic

— Does time have a role in the model?

Continuous-change vs. Discrete-change

— Can the “state” change continuously or only at discrete points in time?

Deterministic vs. Stochastic

— Is everything for sure or is there uncertainty?

Most operational models:

— Dynamic, Discrete-change, Stochastic

Good Models

Appropriate representation of the system, depending on the goals

As simple and small as possible without impeding appropriateness

Reusable for similar systems

Parameterizable

System Overview

System

Static Dynamic

Continuous Discrete

Deterministic StochasticDeterministic Stochastic

Model Overview

Model

Static Dynamic

Continuous Discrete

Deterministic StochasticDeterministic Stochastic

Physical Mathematical

System Evaluation Goals

Gain insight into system operation and performance

Characterize parameter/metrics interrelationship

Use results to:

— Improve design

— Compare two systems with respect to particular metric(s)

— Evaluate the effects of system modification

— Reduce costs

Evaluation: Parameters and Metrics

Most systems have a set of parameters which set and select system behavior, and serve as input to system evaluation

System evaluation attempts to characterize a system using a set of metrics

Choice of appropriate parameters and metrics is of pivotal importance

Course Objective

Simulation of mathematical, dynamic, discrete models

Discrete Event Simulation

is the main focus of this course.

Simulation: A Simple Example

Perform a performance evaluation of a single server system

Performance criteria:

— Average customer waiting time

— Average number of customers in the line

— Server utilization

Model Description

System Entities

— Customers

— Server

Input parameters:

— Customer arrival pattern

— Service time

— Line (queue) organization

Model Description (Cont.)

System Operation:

— Server is idle:

— Customer arrives and is serviced immediately

— Server is then busy until the customer is served completely

— Server is busy:

— Customer arrives and joins the end of queue

— When server becomes idle, the first customer in the queue is now served; if not customer in queue, the server becomes idle

Manual Simulation

Simulation start time: t=0 (Time should be in same units)

Initially, the server is idle, no customers are waiting

Observe the model in its operation as customers enter and leave the model, as the model changes its state

Server

Manual Simulation

At some point of time, a customer A arrives, say t=2.1

The server is now busy

Assume this customer needs 1.2 time units to be served

Server

A is being served

Manual Simulation

At t=3.3, the customer leaves the system

The queue is empty, the server becomes idle again

Server

Manual Simulation

At t=4.5, the next customer B arrives

The queue is empty, the customer begins service immediately, the server is then busy

Assume this customer needs 3.7 time units for service

Server

B is being served

Manual Simulation

At t=4.9, the next customer C arrives

The server is then busy, customer C joins the queue

Assume this customer C will need 1.8 time units for service

Server

B is being served

Will finish: 8.2

Manual Simulation

At t=5.6, the next customer D arrives

Customer D enters the queue

Server

B is being served

Will finish: 8.2Clock: 5.6

Manual Simulation

The next customer E will arrive at t=9.3

First, have a look first what happens at t=8.2: customer B leaves the system, customer C is taken into service

Server

C is being served

Will finish: 10.0Clock: 8.2

Customer will arrive: 9.3

Manual Simulation

Compare the time the current customer will finish with the time the next customer will arrive

Next event that changes the state of the model is the arrival of a new customer at t=9.3

Set the clock to this time and update the state

Server

C is being served

Will finish: 10.0Clock: 8.2

Customer will arrive: 9.3

Manual Simulation

Customer E arrives at t=9.3 and is put into the queue

The arrival of the next customer is at t=12.2

Next event to process is completing service for customer C at t=10.0

Server

C is being served

Will finish: 10.0Clock: 9.3

Customer will arrive: 12.2

Manual Simulation

C finished, remove D from the queue and put it on the server

Set finish time for the customer D

Next event to process is arrival of new customer at t=12.2

Server

D is being served

Will finish: 13.5Clock: 10

Customer will arrive: 12.2

Manual Simulation

You got the idea!

We observed the model only at the points in time when the state of the model changed

These points in time were explicitly represented by the simulation clock variable

The state of the model changed due to two different kinds of events:

— Arrival of customers

— Customers finishing service and leaving the server

Next-Event Time Advance Algorithm

Initialize simulation clock to 0

Determine times of occurrence of future events

As long as there are events to be processed:

— Increment the simulation clock to the time of the next event

— Update the system state as required by the occurrence of this event

— Compute times for future events

System Parameters

Parameters are (not taken into account in this manual simulation):

— Pattern of customer arrival

— Deterministic modeling impossible

— Stochastic modeling: the time between customers is a random variable, choose a distribution for this variable

— Common case: interarrival time is exponentially distributed characterized by the distribution’s mean

— Pattern of service time

— Similar to arrival pattern

— Service time modeled as a random variable, e.g. also with an exponential distribution

System Metrics

Initial goal was to investigate:

— Server utilization (“what percentage of time is the server busy?”)

— length of the queue (“how much space do we need in the store?”)

— Waiting time of customers

How to capture such information from a simulation

Measuring Server Utilization

Directly measuring utilization is difficult

Instead, measure the absolute time the server has been busy, and at the end divide it by the total time that has been simulated:

— Introduce a counter “busytime”, initialize to zero

— At every event: if the server has been busy in the time before this event, add the time since the last event to “busytime”

— Additional counter “time_of_last_event” is necessary; before setting simulation clock to the new time store it in “time_of_last_event”

Measuring Customer Waiting Time

How much time does a customer spend in the queue?

When putting customer in queue, mark it with the time this was done

When retrieving customer from queue, take difference between current simulation clock and time of entry into queue

If customer does not enter queue, waiting time is 0

Measuring Customer Waiting Time

Example from simulation: waiting time for customer C

Server

B is being served

C4.9

Will finish: 8.2Clock: 4.9

Customer will arrive: 5.6

Server

C is being served

D5.6

Will finish: 10Clock: 8.2

Customer will arrive: 9.3

Waiting time for customer C is current simulation clock - time of enqueueing = 8.2 - 4.9 = 3.3

Measuring Customer Waiting Time

This yields waiting times for each customer

How to aggregate this information

Build the average!

— Let Di stand for the delay of customer i (possible 0)

— Computer the usual arithmetic average of the Dis

1/n SDiI=1

n

Measuring Queue Length

Discrete-valued function over time, changing at arbitrary points in time (customers joining and leaving)

Appropriate representation: average of this function over time

1

2

3

Nu

mb

er

of

cust

om

ers

in

q

ueu

e

Time

Computer the total area under the curve and divide by the total simulated time

Different Kinds of Metrics

Average waiting time for customers

— Average is taken over a discrete set of individuals

— Measured value is time

— Example for a discrete-time metric

Average queue length

— Average is continuously taken over time

— Measured value is a number, a discrete metric

— Example of a continuous-time metric

Meaning of Measurements

What is the correct interpretation of such simulation-based measurements?

Look e.g. at waiting time in queue

— Let Di represent the waiting time as measured for customer i

— This refers to one particular simulation run - or to observations on one particular day (for the real system)

— For different simulations, the Dis will be different

— Dis are averaged over n customers to obtain aggregate information

— Other possible aggregations: max, min, …

Both Dis and their aggregates will change from one set of observations to the next

How Long to Run Simulations?

Depends on the purpose

Sometimes (rarely): behavior of system for a well-defined finite amount of time is of interest

Sometimes: simulate for a certain fixed amount of simulated time, or a fixed number of events

Often: certain metrics (depending on input parameters) are of interest. Simulate as long as it takes for the estimation of these metrics to have reached a desired quality level

“Stopping rules” regulate when to stop a simulation

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” entities for modeling “tricks”

— Breakdown, time-off

— Usually have multiple realizations 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

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” (to entities) variables

— Some automatic in Arena, some you define

Pieces of a Simulation Model (cont’d.)

(Global) Variables

— Reflects a characteristic of the whole model, not of specific entities

— Used for many different kinds of things

— Travel time between all station pairs

— Number of parts in system

— Simulation clock (built-in Arena variable)

— Name, value of which there’s only one copy for the whole model

— Not tied to entities

— Entities can access, change variables

— Writing on the wall

— Some built-in by Arena, you can define others

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

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

— Usually watch the length of a queue, waiting time in it

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

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

Conclusion

A simple cashier queue served as example for many problems in simulation

Performed a manual simulation of such a model

Discussed parameters and metrics

Discussed relationship between statistical properties of the modes as such and estimations of these properties by simulation