Simio and Simulation
Simio and Simulation
Introduction to Simulation
Chapter 1
Introduction to Simulation
Introduction
Books goals
General simulation knowledge (software-independent)
Practical introduction to the Simio simulation package
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
Terminology, different kinds of simulation; manual simulation; using generalpurpose programming languages; spreadsheet simulation models; simulation
software
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
Defining new objects & libraries; add-on processes; base & hierarchical objects;
sub-classing; extensions
Chapter 1
Introduction to Simulation
Chapter 1
Introduction to Simulation
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
Kinds of Simulations
Introduction to Simulation
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
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
Why Simulation?
Impact of Variation
Randomness is an important
aspect of most systems.
Random processes cannot be analyzed
with static tools.
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
Lets
Model
That
Key word: valid probably possible for only the very simplest of systems
Chapter 1
Introduction to Simulation
13
Introduction to Simulation
14
Introduction to Simulation
15
Functional Specification
Chapter 1
Objectives
System description and modeling approach
Input data required
Expected experimentation
Deliverables
Introduction to Simulation
16
Project Iterations
Dont do that!
Use an iterative model-building process
Add features/model components
Run/Test
Repeat
Chapter 1
Introduction to Simulation
17
Simulation Process
Chapter 1
Introduction to Simulation
18
Bill of Rights
Chapter 1
Introduction to Simulation
19
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
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
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
Introduction to Simulation
22
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
Introduction to Simulation
23