Lecture 5: Conceptual Modeling

 
This session will consider conceptual modeling, an activity that formulates the model of 
the real world. The amoun
t of detail that a model includes depends on the modeler and the clients.  For example  
fast­food  restaurant  can be modeled as only the queues and 
service desks. Each of these could also be modeled in more detail. 
Conceptual modeling is an important process
Conceptual  modeling is the most important aspect of the simulation modeling process. 
The process influences all aspects of the study, in particular: the data requirements, the 
speed with which the model can be developed, the validity of the model, the speed of 
experimentation and the confidence that is placed in the model results. It is even claimed 
that 50% of the benefit of simulation studies is obtained just from the development of the 
conceptual model. Usually the modeler must develop a thorough understanding of the 
operations   system   in   order   to   design   an   appropriate   model.   In   the   extreme   case   an 
effective conceptual modeling may lead to the identification of a suitable solution without 
the need for any further simulation work.

Some however, see no  need for conceptual modeling claiming the models can be built 
directly from the software and hardware that is available. However, the modern software 
and   hardware   only   provide   an   environment   for   rapid   development   and   prototyping. 
Distributed applications in particular require a thorough conceptual modeling. 

Conceptual modeling, however, is more of an ‘‘art’’ than a ‘‘science’’ and therefore it is 
difficult to define methods and procedures.

Defining a Conceptual Model
First consider the four terms [Zeigler,1976]:
• Real system:  is that which the simulation model is to represent.

• Experimental  frame:  is the limited  set of circumstances  under which the real 

• Base model:   is capable of accounting for the complete behaviour of the real 
system. However, such a model can be very complex such that it cannot be fully 
known. 
 • Lumped   model:  the   components   of   the   system   are   lumped   together   and   the 
interconnections are simplified. The structure of this model is fully known to the 
modeler. This is what we consider the conceptual model.

The  definition   of   the   conceptual   model:    a   non­software   specific   description   of   the 

Analysis of the definition of conceptual model
1. The conceptual model is independent on any computer implementation.
2. The conceptual model has the following components:
 Objectives: the purpose of the model and modeling project, usually to set the basis 
for computer model.
 Inputs: those elements of the model that can be altered to effect an improvement 
in,   or   better   understanding   of,   the   real   world;   otherwise   known   as   the 
experimental factors.
 Outputs: report the results from simulation runs, also called the responses.
 Content:   the   components   that   are   represented   in   the   model   and   their 
interconnections.
o The scope of the model: the model boundary or the breadth of the real 
system that is to be included in the model.
o The level of detail: the detail to be included for each component in the 
model’s scope.
 Assumptions:  made either when there are uncertainties or beliefs about the real 
world being modeled.
 Simplifications:  incorporated   in   the   model   to   enable   more   rapid   model 
development and use. 

Requirements of the Conceptual Model
A  set   of   requirements   for   the   conceptual   model   is   useful   in   that   the   model   can   be 
designed so as to meet these requirements.  There are four requirements of a conceptual 
model [Robinson, 2004]: validity, credibility, utility and feasibility.
• Validity: a perception, on behalf of the modeler, that the conceptual model will 
lead to a computer model that is sufficiently accurate for the purpose at hand.
• Credibility:  a perception, on behalf of the clients, that the conceptual model 
will lead to a computer model that is sufficiently accurate for the purpose at 
hand.
• Utility:   a  perception,   on   behalf   of   the   modeler   and   the   clients   that   the 
conceptual model will lead to a computer model that is useful as an aid to 
decision­making within the specified context.
• Feasibility: a  perception, on behalf of the modeler and the clients, that the 
conceptual model can be developed into a computer model.
Rule of thumb: Keep the model simple
Keep the model as simple as possible to meet the objectives of the simulation study. 
Simple models have a number of advantages such as: faster to develop, more flexible, 
require   less   data,   run   faster,   and   give   results   that   are   easier   to   interpret.     As   the 
complexity increases these advantages are lost.

Conceptual Model Report
A   report   that   is   giving   a   simulation   project   specification   should   have   the   following 
components: 
 Background to the problem situation
 Objectives of the simulation study
 Expected benefits
 The conceptual  model: inputs, outputs, content  (scope and level  of detail), 
assumptions and simplifications
 Experimentation: scenarios to be considered
 Data requirements: data required, when required, responsibility for collection
 Time­scale and milestones 
 Estimated cost

This report should be given to all involved in the simulation study. It should be a short 
document less than 10 pages. As the report is discussed changes are inevitable due to:
 Omissions in the original specification.
 Changes in the real world.
 An increased understanding of simulation on behalf of the clients.
 The identification of new problems through the development and use of the 
simulation model.

Representing the conceptual model
The conceptual model can be represented using the following:  Component list; Process 
flow diagram; Logic flow diagram; Activity cycle diagram. These are each described 
below.

Component list
This is a list of the components in the model and some description of the detail given for 
each component. 
Example of a component list for a single server queue [Robinson 2004, p.71] 

Process flow diagram (process map)
This is a representation of a process flow or process map, showing each component of the 
system   in a sequence and including  some  description  of the model detail.  A process 
might be shown as a box and a queue as a circle.

Example of a process flow diagram for the single server queue [Robinson, 2004, p. 72]

Logic flow diagram
This is the normal use of  standard flow diagram symbols to represent the logic of the 
model rather than the process flow.
Example for logic flow for the single server queue [Robinson, 2004, p. 73] 

Activity cycle diagram
Activity   cycle   diagrams   are   used   as   a   specific   means   for   representing   discrete­event 
simulation models. Circles represent dead states, where an item waits for something to 
happen. Active states, represented by rectangles, are where an item is acted upon. This 
normally entails a time to process the item before passing it on to the next state. Usually 
active and dead states alternate.
Example of Activity Cycle Diagram for the single server queue [Robinson, 2004 p. 73]

 
D E V E L O P I N G T H E C O N C E P T U A L MO D E L

Introduction
After looking at the basic concepts behind conceptual modeling, such as the definitions 
and requirements for a conceptual model, we now consider how the conceptual model 
can be developed. 

A Framework for Conceptual Modeling
Designing a conceptual model is generally seen very much as an art.  There is very little 
guidance   available.   However   conceptual   modeling   may   be   accomplished   using   a 
framework that consists of four key elements: 
1. Develop an understanding of the problem situation
2. Determine the modeling objectives
3. Design the conceptual model: inputs and outputs
4. Design the conceptual model: the model content

A Framework for Conceptual Modeling.

It is important to note that conceptual modeling is not linear but iterative. 

Developing an understanding of the problem situation
A good understanding of the problem situation is mandatory in order to develop a model 
that adequately describes the real world.

The  problem situation can be understood from the way the clients understand, and are 
able to explain, the problem situation. The clients can be helpful in this respect but they 
may also have limitations especially if they do not have a good understanding of the 
system. Sometimes, the clients have a different view of the world. It is important to re­
describe the model of the system to the clients to confirm that it is correct. In the process 
of learning the nature of the problem situation several face­to­face meetings, workshops, 
telephone conversations or email exchanges with clients may be necessary.

During the process of understanding the problem situation some areas where there is 
limited   knowledge   of   the   operations   system   are   likely   to   be   identified   and   the 
assumptions have to be made.  

Consider a fast­food restaurant that is experiencing problems with one of the branches in 
its network. Customers regularly complain about the length of time they have to queue at 
the service counters. It is apparent that this is not the result of shortages in food, but a 
shortage of service personnel.

Determining the modeling objectives

The modeling objectives are very important. They can be developed by considering the 
following questions:

By the end of this study what are the intended achievements? What do the clients 
wish   to   achieve?   Examples   of   possible   achievements   include   increasing 
throughput,   reducing   cost   or   improving   customer   service   (often   measured   by 
some queuing metric). Some less measurable objectives could include improving 
the clients’ understanding of the real world system, or reducing the risk of an 
investment.

What are the levels of performance that are required? It is important to identify 
the targets  of performance  for each objective.  The targets  can be specified   as 
increase or decrease by some percentages or absolute values. 

What are  the constraints  that the  clients  (or modeler) must work within?  The 

Example of modeling objective for Fast­Food Restaurant 
To determine the number of service staff required during each period of the day to ensure 
that 95% of customers queue for less than 3 minutes for service. Due to space constraints, 
a maximum of six service staff can be employed at any one time.

Designing the conceptual model: the inputs and outputs

The model’s inputs and outputs may also be referred to as the experimental factors and 
responses. Their design precedes  that of model details  and is generally in the outline 
form. The experimental factors may be qualitative (e.g. changes to rules or the model 
structure)   as   well   as   quantitative.   The   clients   should   be   encouraged   to   consider   the 
experimental factors that they have no control over such as the arrival rate of customers. 
By experimenting with such factors a greater understanding of the real system can be 
obtained.     Some   consideration   should   also   be   given   to   the   way   the   information   is 
reported, for instance, as numerical data (mean, maximum, minimum, standard deviation) 
or graphical data (time­series, histograms, Gantt charts, pie charts).

Examples of some experimental Factors
 Staff rosters (total number of staff at each hour of the day): Responses (to 
determine achievement of objectives)
 Percentage of customers queuing for less than 3 minutes; Responses (to identify 
reasons for failure to meet objectives)
 Histogram of waiting time for each customer in the queues, mean, standard 
deviation, minimum and maximum
 Time­series of mean queue size by hour
 Staff utilization (cumulative percentage)

Designing the conceptual model: the model content

The  model content must be able to accept the experimental factors and to provide the 
required responses. In this respect, the experimental factors and responses provide the 
basis   of   what   the   model   needs   to   include.   The   level   of   detail   must   be   such   that   it 
represents the components defined within the scope and their interconnection with the 
other components of the model with sufficient accuracy. This again can be considered 
with respect to the impact on the model’s responses.

For example, considering a single machine on a manufacturing line, the cycle time and 
breakdowns   are   very   likely   to   have   a   significant   impact   on   throughput.   Machine 
changeovers probably have sufficient impact to make them worth modeling. Beyond this, 
the small variations in the machine cycle, the type of machine failure, etc., are probably 
of little importance to accurately predicting throughput, and so can be excluded from the 
model.

Prototypes can provide useful insights for the clients. Their primary purpose is to provide 
an insight into the key variables and interconnections in order to help with the design of 
the conceptual model. See some example of a table of model detail below.
Example of model detail [Robinson, 2004, p.86]

The role of data in conceptual modeling
Initially  contextual   data   are   useful   for   developing   an   understanding   of   the   problem 
situation and so are central to the development of conceptual modeling. The data for 
model   realization   (developing   the   computer   model)   are   not   required   for   conceptual 
modeling, but are identified by the conceptual model. Sometimes it may be difficult to 
get the data in which case the model can be re­designed or some ways of dealing with 
missing data adopted.
Methods of Model Simplification
A framework for conceptual modeling is useful but the methods of model simplification 
are also important.  The simplifications are ways of reducing the complexity of a model. 
Model simplification is done by reducing the scope and level of detail in a conceptual 
model either by:
• removing   components   and   interconnections   that   have   little   effect   on   model 
accuracy and/or;
• representing more simply components and interconnections while maintaining a 
satisfactory level of model accuracy.

Model simplification is normally done when the conceptual modeling is complete and 
sometimes   during   the   model   coding.   This   is   done   by   identifying   opportunities.  An 
effective approach is to start with the simplest model possible and gradually add to its 
scope and level of detail [Pidd 1999]. Finding an appropriate point at which to stop, 
however, requires careful attention and discipline on the part of the modeler. Let us now 
consider some of the methods that are used for model simplification.

Aggregation of model components
This can be done in two ways:  black­box modeling and grouping entities.

Black­box modeling
This involves representing a section of an operation as a time delay. The model 
entities that represent such items as parts, people, and information enter the black­
box   and   leave   at   some   later   time.   This   approach   can   be   used   for   modeling 
anything  from a group of machines  or service desks  to a complete  factory or 
service operation. 

Black box approach
 Grouping entities
A  simulation  entity  is  used to represent a group of items. This  is  particularly 
useful   when   there   is   a   high   volume   of   items   moving   through   a   system,   for 
example, a confectionery wrapping process in which hundreds of chocolate bars 
are wrapped each minute. To model each chocolate bar individually would lead to 
hundreds of events per simulated minute, which would have a detrimental effect 
on simulation run­speed. It is beneficial in this case for an entity to represent, say, 
100 chocolate bars.

Excluding components and details
Some  components in a simulation can be omitted when their omission has little 
effect   on   the   accuracy   of   the   model   such   as   operators   on   specific   tasks   in 
manufacturing.  This is  a form of scope reduction.   Some details  may also be 
excluded from a model when they, are deemed to have little impact on model 
accuracy for example the dead times between shifts.

Replacing components with random variables
The   details   of   components   or   groups   of   components   may   be   excluded   by 
representing them as a set of random variables, sampled from some distributions. 
For example, modeling transportation systems such as fork­lift trucks, automatic 
guided vehicles, heavy goods vehicles or trains can be complex. Depending on the 
context,   allowance   needs   to   be   made   for   breakdowns,   punctures,   traffic 
congestion, weather conditions, turnaround times and driver shifts.

Excluding infrequent events
Infrequent events sometimes occur. For example a crane may break down only 
once every 2 years in a warehouse. Hospitals rarely deal with major disasters. 
These   infrequent   events   can   be   excluded.   Such   events   can   however,   be 
investigated specifically if need be. 

Reducing the rule set
Rules  can be used in simulation models to determine routes, processing times, 
schedules or allocation of resources. A model can be simplified by reducing the 
rule set, while maintaining a sufficient level of accuracy. In many cases, 80% of 
circumstances are covered by 20% of the rule set, for instance, routing decisions 
for automatic  guided  vehicles.  Judgment  is  required as  to  whether  it  is  worth 
modeling   the   other   80%   of   the   rule   set   for   a   small   improvement   in   model 
accuracy.

Modeling human interaction with an operations system is particularly difficult. 
For instance, it is very difficult to know how people behave when queuing in a 
service   system.   How   does   a   person   determine   which   queue   to   join   in   a 
supermarket? When does a person decide to jump from one queue to another? 
 When would someone decide to leave a queue? Consequently, a simplified set of 
rules are use, for instance, customers choose the shortest queue or they will not 
join a queue if there are more than five people in it.

Sometimes it is possible to exclude the rule set altogether. In the service system 
example   above   the   simulation   could   make   no   assumptions   about   queuing 
behaviour beyond perhaps assuming people join the shortest queue. 

Splitting models
A   large   model  can  be   beneficially   split   into  two  or  more   parts.  A   sub­model 
(model A) for example can be the input to another (model B) as shown below. As 
model A runs, data concerning the output from the model, such as output time and 
any entity attributes, can be written to a data file. Model B is then run and the data 
read such that the entities are recreated in model B at the appropriate time. The 
advantage of splitting models is that the individual models run faster. It is also 
quite probable that a single run of all the sub­models is quicker than one run of a 
combined. Another advantage of splitting models is that it is possible to speed 
development time by having separate modelers develop each model in parallel. 

Splitting models [Robinson, p. 91]

What is a good simplification?
Simplifications   are   beneficial,   but   a   poor   choice   of   the   simplification   method,   or 
oversimplifying a model, may seriously affect the accuracy of the simulation. A good 
simplification is one that brings the benefits of faster model development and run­speed 
(utility), while maintaining a sufficient level of accuracy (validity).

A modeler can determine whether a simplification is good or not by first using judgment 
in   deciding   whether   a   simplification   is   likely   to   have   a   significant   effect   on   model 
accuracy. This should be determined by the discussions between the modeler, client and 
other members of the simulation project team.   Secondly prototyping may be used in 
which   the   modeler   develops   two   computer   models,   one   with   and   one   without   the 
simplification. It is then possible to compare the results from the two models to see the 
effect   on   accuracy.   This,   of   course,   provides   much   greater   certainty   over   the 
appropriateness of a simplification, but the advantage of faster model development is lost.
1