Simulation

IB3200
Conceptual modelling

Design the model:

Simplifications &
Assumptions

Dr Katy Hoad
http://www.wbs.ac.uk/about/person/Kathryn-Hoad/
Conceptual Modelling Process
1. Understand the problem situation
2. Determine the modeling & project objectives
Design the model:
3. model inputs
4. model outputs
5. model content (scope and level of detail)
6. simplifications and assumptions
7. data requirements
2
 Identify simplifications and assumptions
• While making decisions about content of model you will
need to make assumptions and simplifications - always
list and clearly explain:

 Assumptions are made because of uncertainties or beliefs

about the real world system.
“I don’t know how the real world works so I decided to model it
this way (I don’t really know if the model is right or wrong).”

 Simplifications are made in order to reduce complexity.

“I know how the real world works, but I have chosen to model
it differently/more simply (I know the model is, marginally,
wrong)”
3
• Simplifications are made in order to:
– produce the model more quickly
– increase run speed
– reduce data requirements
– improve the understanding of the model

• Simplifications involve reducing model scope and/or level

of detail by
– Excluding components and interconnections that have
little effect on the model accuracy
– Representing components and interconnections more
simply while maintaining a satisfactory level of model
accuracy
4
 Example:
Bank of Granite

Can you think of any assumptions /

simplifications we may have made while
constructing our example Model Scope and
Level of detail tables earlier…?

For example…
5
 Example:
Bank of Granite
model scope
Component Include/ Justification
exclude

Entities:
Other customers (e.g. Do not interact with cashier
Exclude
mortgage, insurance,…) system
• Assumption: If we believe/have some uncertainty that in the real world
other customers do not interact with cashier service.
• Simplification: If we know they do interact but choose not to model it
because we think it has little effect on model outputs.
• If we know for sure they do not have any interaction with the cashier
service process then this is neither an assumption or simplification!
6
 Example:
Bank of Granite
Level of detail
Component Detail Include/ Comment
exclude
Entities:
Cashier Each entity
No significant grouping
customers represents one Include
observed.
individual
Assumption: Not sure if customers enter in groups sometimes but
will assume not.
Simplification: Know some customers do enter as groups but it was
deemed as not usual and not significant, so chose to model arrival
behaviour more simply with one entity representing one customer.
7
 Example:
Bank of Granite
Level of detail

Component Detail Include/ Comment

exclude
Entities:
Cashier Attribute: Exclude Represented in service
customers Transaction type time distribution.

Simplification: Chose to model this simpler as part of service time.

8
 Example:
Bank of Granite
Level of detail

Component Detail Include/ Comment

exclude
Resources:
Cashiers Skill level Exclude Included in service time
distribution.

Simplification: Chose to model this simpler as part of service time.

9
 Example:
Bank of Granite
Level of detail

Component Detail Include/ Comment

exclude
Activities:
ATM service Breakdowns Exclude Not a significant problem.
• Assumption: If we believe that breakdowns are not a significant issue
but (we do not have data on frequency etc…) don’t know for sure.
• Simplification: If we know the ATMs do sometimes breakdown, but
we choose not to model this, as we think it is not frequent or
disruptive enough to affect our model outputs significantly.

10
 Example:
Bank of Granite
Level of detail

Component Detail Include/ Comment

exclude
Queues:
Q for ATM
service Capacity Exclude Assume no limit.

• Simplification: In practice there is a limit (space in lobby, possible

baulking) but chosen to model queue more simply.

11
 Some ways to simplify model
• Start with simplest model possible – gradually add
scope and detail level till model can fulfil the
modelling objective(s). Then STOP!

• Black-box modelling: represent a section of the

operation as a time delay, e.g. a group of machines or
service desks, a complete factory or service operation.
PAINT
Service SHOP
X hours

X min
12
• Group entities: Instead of modelling individual items or
people as they move through the system, a simulation
entity can represent groups of items/people.

100

2 millions cans made in one day!

13
• Exclude components or details if their absence has little
effect on accuracy of model:

For example...
– If resources for an activity are always available then
they do not need to be modelled explicitly.
– Modelling machine breakdowns: If you use machine
down time data (i.e. total time that a machine is
broken and being repaired) – no need to explicitly
model repair operators / repair equipment. Availability
of these resources is already included in the data by
how long it takes to get the machines up and running
again.

14
• Reduce the rule set: Rules determine routes taken,
processing times, resource allocation, etc...
– Often 80% of the choices can be covered by 20% of the
rule set.
– Modelling human behaviour is extremely difficult and
complicated - so simplify the decision set...

Customers choose to join the

shortest queue

Customers will not join a queue if

there are more than 6 people in it.

15
• Exclude rare events: e.g. A&E departments rarely have to
deal with major disasters resulting in floods of patients.

• Rather than building one large model, split it into parts

and build two or more smaller models so that...

Output Input
Model A Model B

16
 Example of a real life modelling project
that failed to keep it simple....
 Problem: Car production plant had problems meeting
production targets.
 Objective: Investigate why an assembly line wasn’t
meeting a desired throughput level

Very complex real system:

 Many assembly points linked by
conveyors & vehicle systems
 Lots of different operations.
 Lots of variability – travel times,
set-up times, breakdown times
17
Modellers decided to…
• model the whole factory!
• build model so it would fit exactly over the floor plan
schematic of the factory!

This produced a very large model that ran very

slowly – slower than the real system!!!

• They failed to reduce scope and detail

• They failed to reduce the complexity
• They failed to sufficiently abstract the model
away from reality

18
Conceptual Modelling Process
1. Understand the problem situation
2. Determine the modeling & project objectives
Design the model:
3. model inputs
4. model outputs
5. model content (scope and level of detail)
6. simplifications and assumptions
7. data requirements
19
 Identify data requirements for model
3 types of data/information:
• Contextual: needed to understand the problem, e.g.
layout of the system.
• Model realization data: While considering the level of
detail of each component in the model you should also
note what data is needed to model this detail. E.g. Arrival
patterns, service times, routing decisions,...
(We will learn about model realization data next week.)
• Validation data: to compare with model output (e.g. Past
performance data – average waiting times, quarterly
production costs,…) to help validate the model.
(We will learn about validating a DES model in week 4).
20
 Representing the conceptual model
• Component list tables:
– Model Scope (as seen in previous slides)
– Level of detail (as seen in previous slides)
– Include detail of data requirements
– List of assumptions and simplifications with
explanations / justifications

• Diagrams of the model content and interconnections:

For example,
– Process cycle diagram (as seen in lecture 1)
– Logic flow diagram
21
 • Process Flow Diagram: Bank of Granite

Arrival rate data T = Carry out transaction

C = Dedicated resource: Cashier

Wait for Wait for

ATM Cashier
service service

Service time data

Service time data
Use
ATM T C T C
ATM

22
 Logic Flow Diagram
- Represents the logic of the model.
• Software independent

• Circles = queues

• Boxes = activities, arrivals and departures

• Logic decision points / questions:

• Direction entities take:

23
Summary of Modelling Objective
To reduce waiting times for cashier
customers, so that 95% of customers wait
less than 3 minutes to be seen.
• Inputs:
– Number of ATMs (1-2)
– Number of cashier counters (2-3)
– Number of extra cashier staff (1-3)

Let’s draw a LOGIC

Flow Diagram
for our Bank of
Granite example?

24
• Logic Flow Diagram: Bank of Granite

Customer
arrives

Queue YES Use NO Queue

for ATM? for
ATM cashier
NO NO
Is ATM Is cashier
free? free?
YES YES
Carry out
Use ATM Customer transaction
leaves 25
 Conceptual Modelling Summary
• Understand the problem situation
• Determine modelling & project objectives

• Design the model:

 Model inputs and outputs Outputs = Responses/KPIs
Inputs = experimental factors + range

 Model content (scope and level of detail)

• List simplifications and assumptions

• Identify the data requirements 26

 Coming Next…
• Representing variability in DES.
• Collection and use of realisation
data.

27