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 n Homework25% n Midterm Exam20% n Term Project30% n Final Exam25%
Homework and Exams n Homework is due at the beginning of class on the day it is due. — Late submissions are not accepted. n Two in class exams — Mid term, Final exams — Exams are closed book.
Calendar n Project Proposal and presentationSeptember 16 n Mid TermOctober 7 n Project ReportDecember 1 n Project PresentationsDecember 2 and 9 n Final ExamFinal Exam Week (December 16)
Course Communication n My (O) (C) Office Hours: Tuesdays: 5.00 pm to 6.30 pm. Room 1139 SC n TA: Chun-Ling Chuang Office Hours: Wednesdays: am to pm (Or by appointment). Room 3217 SC Natalie Vanosdel Office Hours: Mondays & Fridays: 1.30 pm to 2.20 pm (Or by appointment). Room 3217 SC
Goal of This Course n 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 n Emphasis is on practical problems and questions, not on theory
Course Topic n Evaluate performance of a system n 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 n What is a system? n What are operations of a system? n What is performance? n On what does performance depend? n What is a model? n How to build a model? n How to numerically evaluate it? n How to interpret the results of such an evaluation
Non-Goals of This Course n Mathematical analysis tools for performance evaluation n Experimental approaches n Statistics course n 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: n Specifying the components the system consists of. n Describing the characteristics of the components. n And finally specifying the relations between these components.
Example: Transaction Processing System SalesPurchases Supplier Customer Factory Raw Material Finished Goods Purchase Order Invoice Work Orders Pay checks Sales Order Customer Payments Purchasing AccountingSales 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. Information Systems People Technology Organizations Environment
System n We will describe, model, and analyze systems n System: A group of interacting elements n System is defined by its purpose or function n System can be in different states n State can be expressed by the values of a set of variables n Dynamic systems change their state over time
Types of Systems n State can be continuous or discrete n In continuous systems, the state of the system is continuous function of time (airplane flying, Earth turning, etc) n In discrete systems, the state of the system changes instantaneously in separate points of time n Which rules govern the process of state changes? n Which level to choose? n How to describe the system?
Models n If the actual system is not available for investigation, a model of the system can be constructed with approximations and assumptions. n Model is built to capture relevant properties of the original system n 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) n We will only consider mathematical models
Studying Logical Models n If model is simple enough, use traditional mathematical analysis … get exact results, lots of insight into model — Queueing theory — Differential equations — Linear programming n But complex systems can seldom be validly represented by a simple analytic model — Danger of over-simplifying assumptions … model validity? n Often, a complex system requires a complex model, and analytical methods don’t apply … what to do?
Computer Simulation n 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 n Can be used to study simple models but should not use it if an analytical solution is available n Real power of simulation is in studying complex models n Simulation can tolerate complex models since we don’t even aspire to an analytical solution
The Bad News n Don’t get exact answers, only approximations, estimates — Also true of many other modern methods — Can bound errors by machine roundoff n 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 n 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) n 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 n 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 n Static vs. Dynamic — Does time have a role in the model? n Continuous-change vs. Discrete-change — Can the “state” change continuously or only at discrete points in time? n Deterministic vs. Stochastic — Is everything for sure or is there uncertainty? n Most operational models: — Dynamic, Discrete-change, Stochastic
Good Models n Appropriate representation of the system, depending on the goals n As simple and small as possible without impeding appropriateness n Reusable for similar systems n Parameterizable
System Overview System StaticDynamic ContinuousDiscrete DeterministicStochasticDeterministicStochastic
Model Overview Model StaticDynamic ContinuousDiscrete DeterministicStochasticDeterministicStochastic PhysicalMathematical
System Evaluation Goals n Gain insight into system operation and performance n Characterize parameter/metrics interrelationship n 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 n Most systems have a set of parameters which set and select system behavior, and serve as input to system evaluation n System evaluation attempts to characterize a system using a set of metrics n 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 n Perform a performance evaluation of a single server system n Performance criteria: — Average customer waiting time — Average number of customers in the line — Server utilization
Model Description n System Entities — Customers — Server n Input parameters: — Customer arrival pattern — Service time — Line (queue) organization
Model Description (Cont.) n 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 n Simulation start time: t=0 (Time should be in same units) n Initially, the server is idle, no customers are waiting n Observe the model in its operation as customers enter and leave the model, as the model changes its state Server
Manual Simulation n At some point of time, a customer A arrives, say t=2.1 n The server is now busy n Assume this customer needs 1.2 time units to be served Server A is being served
Manual Simulation n At t=3.3, the customer leaves the system n The queue is empty, the server becomes idle again Server
Manual Simulation n At t=4.5, the next customer B arrives n The queue is empty, the customer begins service immediately, the server is then busy n Assume this customer needs 3.7 time units for service Server B is being served
Manual Simulation n At t=4.9, the next customer C arrives n The server is then busy, customer C joins the queue n Assume this customer C will need 1.8 time units for service Server B is being served Will finish: 8.2
Manual Simulation n At t=5.6, the next customer D arrives n Customer D enters the queue Server B is being served Will finish: 8.2 Clock: 5.6
Manual Simulation n The next customer E will arrive at t=9.3 n 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 n Compare the time the current customer will finish with the time the next customer will arrive n Next event that changes the state of the model is the arrival of a new customer at t=9.3 n 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 n Customer E arrives at t=9.3 and is put into the queue n The arrival of the next customer is at t=12.2 n 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 n C finished, remove D from the queue and put it on the server n Set finish time for the customer D n 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 n You got the idea! n We observed the model only at the points in time when the state of the model changed n These points in time were explicitly represented by the simulation clock variable n 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 n Initialize simulation clock to 0 n Determine times of occurrence of future events n 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 n 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 n 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 n How to capture such information from a simulation
Measuring Server Utilization n Directly measuring utilization is difficult n 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 n How much time does a customer spend in the queue? n When putting customer in queue, mark it with the time this was done n When retrieving customer from queue, take difference between current simulation clock and time of entry into queue n If customer does not enter queue, waiting time is 0
Measuring Customer Waiting Time n Example from simulation: waiting time for customer C Server B is being served C 4.9 Will finish: 8.2 Clock: 4.9 Customer will arrive: 5.6 Server C is being served D 5.6 Will finish: 10 Clock: 8.2 Customer will arrive: 9.3 n Waiting time for customer C is current simulation clock - time of enqueueing = = 3.3
Measuring Customer Waiting Time n This yields waiting times for each customer n How to aggregate this information n Build the average! — Let D i stand for the delay of customer i (possible 0) — Computer the usual arithmetic average of the D i s 1/n S D i I=1 n
Measuring Queue Length n Discrete-valued function over time, changing at arbitrary points in time (customers joining and leaving) n Appropriate representation: average of this function over time Number of customers in queue Time n Computer the total area under the curve and divide by the total simulated time
Different Kinds of Metrics n Average waiting time for customers — Average is taken over a discrete set of individuals — Measured value is time — Example for a discrete-time metric n 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 n What is the correct interpretation of such simulation-based measurements? n Look e.g. at waiting time in queue — Let D i 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 D i s will be different — D i s are averaged over n customers to obtain aggregate information — Other possible aggregations: max, min, … n Both D i s and their aggregates will change from one set of observations to the next
How Long to Run Simulations? n Depends on the purpose n Sometimes (rarely): behavior of system for a well-defined finite amount of time is of interest n Sometimes: simulate for a certain fixed amount of simulated time, or a fixed number of events n 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 n “Stopping rules” regulate when to stop a simulation
Pieces of a Simulation Model n 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.) n 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.) n (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.) n 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.) n 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.) n 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 n Understand the system n Be clear about the goals n Formulate the model representation n Translate into modeling software n Verify “program” n Validate model n Design experiments n Make runs n Analyze, get insight, document results
Conclusion n A simple cashier queue served as example for many problems in simulation n Performed a manual simulation of such a model n Discussed parameters and metrics n Discussed relationship between statistical properties of the modes as such and estimations of these properties by simulation