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 1 Introduction to Simulation

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

Books 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; Littles 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 general-purpose 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

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

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.


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 systems 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


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

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

Areas Where Simulation Has Been Applied


Airports Hospitals Ports Mining Amusement Parks Call Centers Supply Chains

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

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.

PresenterPresentation NotesNearly all systems are stochastic from a design perspective Many of the new economy companies have have moved to a direct channel build to order model forecast demand is replaced by actual demand. Randomness is the villain it is the critical driver in system performance.

The Performance Villain Photo

Processing

Average time between arrivals

is 60 minutes

Average service time is

55 minutes

How will this system perform? Average waiting time when run 24x7?

* Exponential Distribution

Random*/Random*

Constant/Constant Random*/Constant

Result Arrival/Service Process 0 Hours Lets

Model That

PresenterPresentation NotesA trivial system All of us can predict its behavior, right?

How will this system perform do I need a second server ? Should I buy better equipment to speed up the server?I given you structure and Ive given you the data but left out the single most important piece of information the randomness.

Show Sample01a-VariationThePerformanceVillian model--Run interactively for a few hours enough to explain model, but not give away answer--Go to experiment, run scenario 1 to confirm results, briefly show boring pivot table --Ask for expectation of scenario2. Set upper bound--Enable & run scenario2, explain about multi-processors, show SMORE--Ask for expectation of scenario3. --Enable & run scenario3, show SMOREIf run for infinite time, the answers for scenario 2 & 3 are 5 and 10 hours! You can never make up for lost time.--Go back to interactive, set scale factor to 10000, run enough to see plot rise and stabilize a bit

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 dont simulate Key word: valid probably possible for only the very simplest of systems

If system becomes complicated, its 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


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

Its 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 arent 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? Whats 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!

Functional Specification If you dont know where youre going, how will you know when you get there?

Carpenters 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 projects total time should be spent on developing the objectives and functional specification

For most models: Objectives System description and modeling approach Input data required Expected experimentation Deliverables


Project Iterations Simulation novices often start modeling and keep adding to the

model until its complete, and only then run the model.

Dont do that! Use an iterative model-building process

Add features/model components Run/Test Repeat

Save early, save often!


Simulation Process


PresenterPresentation NotesOften people think of a simulation project as building a model.As you can see by the diagram, model building is only one part of a typical project.

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!

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.


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.


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 simulationists 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.


Simulationist Bill of Rights (cont.) Dont 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 dont 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 1Introduction to SimulationIntroductionAbout the Book IIAbout the BookAbout the BookSystems and ModelsKinds of SimulationsDiscrete-Event Modeling ParadigmsAreas Where Simulation Has Been AppliedWhy Simulation?Impact of Variation The Performance Villain When to Simulate (and When Not To)When to Simulate (and When Not To) (cont.)Simulation Success Skills Project ObjectivesFunctional SpecificationProject IterationsSimulation ProcessBill of RightsSimulation Stakeholder Bill of RightsSimulation Stakeholder Bill of Rights (cont.)Simulationist Bill of RightsSimulationist Bill of Rights (cont.)

Documents

Simio and simulation