Simio and simulation
-
Upload
rene-heisenberg-escobar-dinamarca -
Category
Documents
-
view
219 -
download
9
description
Transcript of 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
Chapter 1 Introduction to Simulation 3
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
Chapter 1 Introduction to Simulation 4
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.
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 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
Chapter 1 Introduction to Simulation 6
-
Kinds of Simulations
Chapter 1 Introduction to Simulation 7
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
Chapter 1 Introduction to Simulation 8
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
Chapter 1 Introduction to Simulation 9
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
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
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?
Chapter 1 Introduction to Simulation 15
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
Chapter 1 16 Introduction to Simulation
-
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!
Chapter 1 17 Introduction to Simulation
-
Simulation Process
Chapter 1 18 Introduction to Simulation
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.
Chapter 1 19 Introduction to Simulation
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.
Chapter 1 20 Introduction to Simulation
-
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 21 Introduction to Simulation
-
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.
Chapter 1 22 Introduction to Simulation
-
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 1 23 Introduction to Simulation
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.)