Simio And Simulation

Chapter 1

Introduction to Simulation

Simio and Simulation: Modeling, Analysis, Applications, © 2014 W. David Kelton, Jeffrey S. Smith, David T. Sturrock Most recent update to these slides: January 1, 2014

Chapter 1

Introduction to Simulation

1

Introduction

• In use since 1960s, continues to grow, strengthen • “Advanced analytics” (including simulation) is 2nd of top ten “strategic technologies” for 2010 (www.gartner.com) • Growth, popularity facilitated by hardware/software advances – Powerful, relatively cheap PCs – Simulation-software user interfaces, design, ease of use – Object-oriented technology in simulation software improves model flexibility, ability to model complex systems – Publicly available symbols promote 3D animation

• Book’s goals – General simulation knowledge (software-independent) – Practical introduction to the Simio simulation package

Chapter 1

Introduction to Simulation

2

About the Book II

• Simulation Concepts – Basis in underlying concepts and brief introduction to software – Chapter 1: Introduction to Simulation

About the book; systems, models, and applications; when to simulate (and when not to), managing simulation projects, stakeholder and simulationist bills of rights

– Chapter 2: Basics of Queueing Theory

Basic analytical queueing theory; terminology; Little’s law; some specific queueing models; queueing networks; strengths/limitations; use in verifying simulation models

– Chapter 3: Kinds of Simulation

Terminology, different kinds of simulation; manual simulation; using generalpurpose programming languages; spreadsheet simulation models; simulation software

– Chapter 4: First Simio Models

User interface; first model via Standard Library objects & processes; ATM model; basic output analysis via Simio Experiments & SMORE plots; exporting output data for post-processing via external stat packages; basic animation Chapter 1

Introduction to Simulation

3

About the Book

• Simulation Modeling With Simio – based on examples, integrated validation and output analysis – Chapter 5: Intermediate Modeling With Simio

Simio object framework; PCB assembly models; comparing alternative scenarios

– Chapter 6: Input Analysis

Specifying probability distributions/processes for input to simulation models with the external Stat::Fit software; generating random numbers, variates, vectors, and processes

– Chapter 7: Working With Model Data

Emergency-department model with Data & Sequence tables; importing/exporting data; Schedules; Rate & Function Tables; Lists; Changeovers, State Arrays

– Chapter 8: Animation and Entity Movement

2D/3D animation; entity movement; Links; Conveyors; assisted entity movement

– Chapter 9: Advanced Modeling With Simio

More advanced modeling examples; processes; seeking optimal scenarios

– Chapter 10: Customizing and Extending Simio

Defining new objects & libraries; add-on processes; base & hierarchical objects; sub-classing; extensions Chapter 1

Introduction to Simulation

4

About the Book

• Chapter 11: Case Studies Using Simio – descriptions of realistic systems of increasing complexity to facilitate modeling practice. • Appendix A: Simulation-based Scheduling – a brief overview of the state of the art in planning and scheduling and discussion of how the latest simulation technology can be used to address many of the existing problems.

Chapter 1

Introduction to Simulation

5

Systems and Models

• System – broad term, set of related components working together toward some purpose, usually over time – Simple ATM; complex airport; very complex global distribution network – May or may not exist; may or may not be possible to experiment with the real system directly

• Model of a system – Physical model – airplane cockpit for training, wind tunnels – Analytical model – exact mathematical analysis, limited domain/flexibility – Simulation model – • Imitation of system’s operation over time (dynamic) • Appropriate level of detail, draw conclusions about system behavior • Software to represent system components, behavior, interactions • Record artificial “history” of model, summarize characteristics • Used to predict effect of changes to existing system, or performance of new systems Chapter 1

Introduction to Simulation

6

Kinds of Simulations

• Stochastic vs. Deterministic

– Stochastic – random inputs to model to represent the realistic variation found in most systems (time to complete a task, time between successive arrivals of customers, machine uptimes and downtimes, branching probabilities) • Outputs random too, subject to proper statistical analysis – Deterministic – no random inputs to model, so outputs are always the same (unless you change something in the model)

• Discrete vs. Continuous

– Discrete – state variables describing the model change only at instantaneous discrete points in time (event times) • Number of customers in queue, server status (busy, idle, down) – Continuous – state variables can change continuously over time, described by differential equations that are solved numerically • Pressure in a tank, temperature in an oven, fluid flow – Mixed discrete/continuous models

• More detail on kinds of simulation in Chapter 3 Chapter 1

Introduction to Simulation

7

Discrete-Event Modeling Paradigms

• Events

– Model the points in time when the system state can change – Program to carry out instantaneous event logic, scheduling of future events, observing output and summaries

• Processes – Model a sequence of actions taking place over time (part in a manufacturing system seizes a worker, delays for service, releases worker)

• Objects – Describe model from the point of view of the facility

• Agent-based – Agents are a special case of objects – Give intelligence to objects to make them into agents – System behavior emerges from interaction of many autonomous agents Chapter 1

Introduction to Simulation

8

Areas Where Simulation Has Been Applied • • • • • • •

Chapter 1

Airports Hospitals Ports Mining Amusement Parks Call Centers Supply Chains

• • • • • • •

Manufacturing Military Telecommunications Criminal Justice System Emergency-response System Public Sector Customer Service

Introduction to Simulation

9

Why Simulation?

• Objects can influence each other • Every system has randomness Breakdowns, illness, late arrivals…

• The combination is complex. +

=

• Simulation is uniquely capable of managing this complexity.

Impact of Variation

• Most systems contain variation. – Demand by customers, parts – Equipment/personnel failures – Shortages of materials/supplies.

• Randomness is an important aspect of most systems. • Random processes cannot be analyzed with static tools.

The Performance Villain Average time between arrivals is 60 minutes

Average service time is 55 minutes

Photo Processing How will this system perform? Average waiting time when run 24x7? Arrival/Service Process Constant/Constant Random*/Constant Random*/Random* * Exponential Distribution

Result 0 Hours

Let’s Model That…

When to Simulate (and When Not To)

• If a valid model of the system is simple enough to model analytically and get exact results, then don’t simulate

– Key word: valid … probably possible for only the very simplest of systems

• If system becomes complicated, it’s tempting to over-simplify the assumptions to get to an analytically tractable model – Advantage is that you get exact answers, no uncertainty or noise – But what good is an exact answer to the wrong model? How to measure “how wrong” a model is? – Solving the (perhaps-unrealistic) model vs. solving the real problem

Chapter 1

Introduction to Simulation

13

When to Simulate (and When Not To) (cont.)

• Disadvantage of (stochastic) simulation – answers are just statistical estimates with uncertainty and noise

– Need to design, statistically analyze simulation experiments • These essential activities in a sound simulation project are interwoven with modeling throughout the book – Can measure uncertainty/noise, take steps to reduce to tolerable level • But you must be aware of this and consider it

• It’s better to get a sufficiently precise estimated answer to the right model, than an exact answer to the wrong model

– Some statistical variation in the answers can be expected when using different versions of the same software on the same model • e.g., Change in order of processing simultaneous events • But even for a stochastic model, should get the same results from multiple executions of the same model in the same software version – Random-number generators aren’t really random … desirable … Chapts. 3, 4

– Simulation is no longer the “method of last resort” to be used only “when all else fails” (Wagner, 1969) Chapter 1

Introduction to Simulation

14

Simulation Success Skills – Project Objectives

• Stakeholder – Someone who commissions, funds, uses, or is affected by a simulation project

– Conflicting objectives between different stakeholders are not uncommon

• There is no “single simulation model” for a system – the “right” model depends on a combination of the system and the study objectives: – – – –

What do you want to evaluate, learn, or hope to prove? What’s the scope of the project? What data are available or can be collected? In what form do you want the results?

• In fact all Models are “wrong”! Why? While models attempt to represent reality all require simplifying assumptions! Chapter 1

Introduction to Simulation

15

Functional Specification

“If you don’t know where you’re going, how will you know when you get there?”

Carpenter’s advice: “Measure twice. Cut once.”

• Functional specification – a document describing exactly what will be delivered, when, how, and by whom • From practical experience, approximately 10% of a project’s total time should be spent on developing the objectives and functional specification • For most models: – – – – – Chapter 1

Objectives System description and modeling approach Input data required Expected experimentation Deliverables Introduction to Simulation

16

Project Iterations

• Simulation novices often start modeling and keep adding to the model until it’s “complete,” and only then run the model.

Don’t do that! • Use an iterative model-building process – Add features/model components – Run/Test – Repeat

• “Save early, save often!”

Chapter 1

Introduction to Simulation

17

Simulation Process

Chapter 1

Introduction to Simulation

18

Bill of Rights

• For Simulation Stakeholder – What your stakeholder can expect from you. • For Simulationist – What you can expect from your stakeholders. In-Class Quiz two weeks from now on these Bill of Rights!

Chapter 1

Introduction to Simulation

19

•

•

•

•

•

•

Simulation Stakeholder Bill of Rights

Partnership – The modeler will do more than provide information on request. The modeler will assume some ownership of helping stakeholders determine the right problems and identify and evaluate proposed solutions. Functional Specification – A specification will be created at the beginning of the project to help define clear project objectives, deadlines, data, responsibilities, reporting needs, and other project aspects. This specification will be used as a guide throughout the project, especially when tradeoffs must be considered. Prototype – All but the simplest projects will have a prototype to help stakeholders and the modeler communicate and visualize the project scope, approach, and outcomes. The prototype is often done as part of the functional specification. Level of Detail – The model will be created at an appropriate level of detail to address the stated objectives. Too much or too little detail could lead to an incomplete, misunderstood, or even useless model. Phased Approach – The project will be divided into phases and the interim results should be shared with stakeholders. This allows problems in approach, detail, data, timeliness, or other areas to be discovered and addressed early and reduces the chance of an unfortunate surprise at the end of a project. Timeliness – If a decision-making date has been clearly identified, usable results will be provided by that date. If project completion has been delayed, regardless of reason or fault, the model will be re-scoped so that the existing work can provide value and contribute to effective decision-making.

Chapter 1

Introduction to Simulation

20

•

•

• •

• •

Simulation Stakeholder Bill of Rights (cont.)

Agility – Modeling is a discovery process and often new directions will evolve over the course of the project. While observing the limitations of level of detail, timeliness, and other aspects of the functional specification, a modeler will attempt to adjust project direction appropriately to meet evolving needs. Validated and Verified – The modeler will certify that the model conforms to the design in the functional specification and that the model appropriately represents the actual operation. If there is inadequate time for accuracy, there is inadequate time for the modeling effort. Animation – Every model deserves at least simple animation to aid in verification and communication with stakeholders. Clear Accurate Results – The project results will be summarized and expressed in a form and terminology useful to stakeholders. Since simulation results are an estimate, proper analysis will be done so that the stakeholders are informed of the accuracy of the results. Documentation – The model will be adequately documented both internally and externally to support both immediate objectives and long term model viability. Integrity – The results and recommendations are based only on facts and analysis and are not influenced by politics, effort, or other inappropriate factors.

Chapter 1

Introduction to Simulation

21

•

•

•

•

• •

•

Simulationist Bill of Rights

Clear Objectives – A simulationist can help stakeholders discover and refine their objectives, but clearly the stakeholders must agree on project objectives. The primary objectives must remain solid throughout the project. Stakeholder Participation – Adequate access and cooperation must be provided by the people who know the system both in the early phases and throughout the project. Stakeholders will need to be involved periodically to assess progress and resolve outstanding issues. Timely Data – The functional specification should describe what data will be required, when it will be delivered and by whom. Late, missing, or poor quality data can have a dramatic impact on a project. Management Support – The simulationist’s manager should support the project as needed not only in issues like tools and training discussed below, but also in shielding the simulationist from energy sapping politics and bureaucracy. Cost of Agility – If stakeholders ask for project changes, they should be flexible in other aspects such as delivery date, level of detail, scope, or project cost. Timely Review/Feedback – Interim updates should be reviewed promptly and thoughtfully by the appropriate people so that meaningful feedback can be provided and any necessary course corrections can be immediately made. Reasonable Expectations – Stakeholders must recognize the limitations of the tech-nology and project constraints and not have unrealistic expectations. A project based on the assumption of long work hours is a project that has been poorly managed.

Chapter 1

Introduction to Simulation

22

• •

• •

•

Simulationist Bill of Rights (cont.)

“Don’t shoot the messenger” – The modeler should not be criticized if the results promote an unexpected or undesirable conclusion. Proper Tools – A simulationist should be provided the right hardware and software appropriate to the project. While “the best and latest” is not always required, a simulationist should not have to waste time on outdated or inappropriate software and inefficient hardware. Training and Support – A simulationist should not be expected to “plunge ahead” into unfamiliar software and applications without training. Proper training and support should be provided. Integrity – A simulationist should be free from coercion. If a stakeholder “knows” the right answer before the project starts, then there is no point to starting the project. If not, then the objectivity of the analysis should be respected with no coercion to change the model to produce the desired results. Respect – A good simulationist may sometimes make the job look easy, but don’t take them for granted. A project often “looks” easy only because the simulationist did everything right, a feat that in itself is very difficult. And sometimes a project looks easy only because others have not seen the nights and weekends involved.

Chapter 1

Introduction to Simulation

23