Modelling and Simulation

UNIT1

Why Simulation Modelling?

 One reason is that we need to make decisions for an uncertain future. For organisations,
uncertainty can be caused by a wide variety of reasons, such as shorter product/service life
cycles, increasing system complexity with the use of IT systems and the increasing use of
performance metrics. Thus, in order to make decisions about the future, we need to be able
to predict the future as best we can.
 Another reason is that often ‘strategic aims’ are put forward in organisations without any real
notion of how they will be implemented in practice. Simulation can help convert these aims
into reality by providing specific workable implementations of change at an operational level.
Simulation can help specify how work should be done to successfully operate a system and
specify what tasks and what resources are needed. Addressing the operational issue of how
work will be done enables specific, workable implementations to be designed.

What Is a Simulation Model?

 A model is intended to represent a real system, either existing or planned.. Simulation refers
to the process of conducting experiments with the model to understand the behaviour of the
system and/or evaluate various strategies for the operation of the system.
Types of Mathematical Models
 Mathematical models represent a system as a number of mathematical variables (termed state
variables) with mathematical equations used to describe how these state variables change over
time. An important distinction between mathematical models is the classification between
static (fixed in time) and dynamic (change over time), with dynamics systems being modelled
using a continuous or discrete approach (figure).

1
Modelling and Simulation
Simulation Modelling Methods
There now follows a brief overview of the three main methods of dynamic simulation modelling.
These are system dynamics (SD), agent-based simulation (ABS) and discrete-event simulation
(DES). The three methods have their own philosophies, communities of users and main areas of
application.
System Dynamics (SD)
 SD has been used extensively in a wide range of application areas, such as economics, supply
chain, ecology and population dynamics, to name a few.
Agent-Based Simulation (ABS)
 ABS has been applied across a wide area, such as economics, human behaviour, supply chains,
emergency evacuation, transport and healthcare.
Discrete-Event Simulation (DES)
 DES evolves over time by a representation in which the state variables change instantaneously
at separate points in time. These points in time are the ones at which an event occurs, where
an event is defined as an instantaneous occurrence that may change the state of the system’.
Application Areas for DES
 Simulation modelling is a flexible tool and is capable of analysing most aspects of an organi-
sation. The two main areas of operations are the design and management of processes. In
terms of design, simulation has an obvious role in the testing of system designs for systems
that do not yet exist. Simulation is often used to assess large capital investments such as
equipment and plant, where it can reduce the risk of implementation at a relatively small
cost. Simulation can also be used in the management of business processes. For example, a
service operation may wish to ensure continued good customer service while meeting
increased demand. Making decisions around aspects such as staffing levels and job
priorities to meet increased demand requires the ability to predict changes in these areas of
performance. Simulation can be used to provide a predictive capability to help make better
decisions and ensure future service levels are maintained.
Manufacturing Systems
 In order to remain competitive, manufacturing organisations must ensure their systems can
meet changing market needs in terms of product mix and capacity levels while achieving
efficient use of resources. Because of the complex nature of these systems with many inter-
dependent parts, simulation is used extensively to optimise performance. Design decision
areas in manufacturing include estimating required resource capacity, layout design, bot-
tleneck analysis, machine setup time reduction, implementation of automation and production
lead time estimation. Management decision areas in manufacturing include estimating batch
size, determining parts sequencing, workforce scheduling and assessing preventative
maintenance policies.
Service Systems
 The productivity of service sector systems has not increased at the rate of manufacturing
systems, and as the service sector has increased, the potential increase in productivity from
improving services has been recognised. Simulation is now being used to help analyse many

2
Modelling and Simulation
service processes to improve customer service and reduce cost. For example, the emphasis on
performance measures in government services such as healthcare has led to the increased use
of simulation to analyse systems and provide measures of performance under different
configurations. Design decision areas include customer queuing time estimation, layout
planning and service capacity planning. Management decision areas include staff
scheduling, customer service priorities and emergency planning.

Supply Chain Management Systems

 Supply chain systems are a network of activities that entities flow through from raw materials
supply to production, distribution and then retail to the customers. The supply chain should
aim to minimise costs while maintaining service levels. Supply chains will incorporate
transportation systems such as rail and airline services as well as internal systems such as
automated guided vehicles (AGVs), which can be analysed using simulation. Many simulation
software packages have special facilities to model track-based and conveyor-type systems, and
simulation is ideally suited to analyse the complex interactions and knock-on effects that can
occur in these systems. Design decision areas include supply chain structure, process redesign,
supplier selection, facilities and capacity planning, supply chain integration, the bullwhip
effect, reverse logistics, replenishment control policies, supply chain optimisation, cost
reduction, system performance, inventory planning and management and customer service
levels.

Information Systems
 Simulation is used to predict the performance of the computerisation of processes. This
analysis can include both the process performance and the technical performance of the
computer network itself, often using specialist network simulation software. Design decision
areas include the effects of automation by IS on customer service levels, estimating IS capacity
requirements to meet customer transaction volumes and designing client-server systems.
 The case study ‘A simulation of an enterprise resource planning system’ concerns the use
of simulation to measure customer service performance when introducing an enterprise
resource planning (ERP) system into a customer order processing activity.
 The case study ‘A simulation of a road traffic accident process’ concerns predicting the cost
savings made on front-line road traffic officer staff when changes are made to the road traffic
accident reporting process. The changes were based on the use of mobile devices to record and
map the location of traffic accidents at the location of the incident.
Benefits of DES
1. Provides capability for descriptive analytics
2. Provides capability for predictive analytics
3. Provides capability for prescriptive analytics
 Simulation can address issues at the design stage before the new system exists.
 Simulation can help convert strategic aims into reality. Simulation can help specify how work
should be done to successfully operate a system and specify what tasks and what resources are
needed. Addressing the operational issue of how work will be done enables specific, workable
implementations to be designed.

3
Modelling and Simulation
UNIT2

2.1 Definitions
 The word ‘modelling’ has a meaning that is reasonably confined in its general usage,
the same cannot be said for the word ‘simulation’. Nevertheless, the phrase ‘modelling
and simulation’ does have an accepted meaning and implies two distinct activities.
 The modelling activity creates an object (i.e. a model) that is subsequently used as a
vehicle for experimentation. This experimentation with the model is the simulation
activity, the experimentation is carried out by a computer program.
 The word ‘simulation’ is sometimes used as a noun to imply a specialized computer
program (‘A simulation has been developed for the proposed system’). It is also
used frequently as an adjective (‘The simulation results indicate that the risk of
failure is minimal’), to measure the effectiveness for simulation programming’).

2.2 The Nature of a Model

 A model is a representation of the SUI’s behaviour and the modelling process is
concerned with the development of this representation.
 Modelling is a constructive activity, and this raises the natural question of whether the
product (i.e. the model) is ‘good enough’, from the point of view of the requirements
implied by the project goal. It is meaningless to undertake a modelling study without
a clear understanding of the purpose for which the model will be used.
 There are a variety of ways in which the representation of behaviour can be formulated.
Included here are: natural language, mathematical formalisms, rule-based formalisms,
symbolic/graphical descriptions and combinations of these. These alternatives are
generally created in formats that are best suited to capturing subtleties or providing
clarification. But the format of a computer program plays a very special role, because
that computer program provides the means for actually carrying out the experiments
that are central to the modelling and simulation approach.

2.3 An Example Project (Full-Service Gas Station)

• To illustrate, we consider a modelling and simulation project whose system context
(SUI) is a ‘full-service’ gas station with two islands and four service lanes (Fig.). A
significant portion of the customers at this station drive small trucks and vans which
have gas tank capacities that are larger than those of most passenger vehicles. Often,
the drivers of passenger cars find themselves queued behind these ‘large-tank’
vehicles which introduce substantially longer wait times when they arrive at the gas
station. This can cause aggravation and complaints. The station management is

1
Modelling and Simulation
proposing as a possible solution the restriction of these large-tank vehicles to two
designated lanes. The goal of the modelling and simulation project would be to
determine if this strategy would improve the flow of vehicles through the station.

• Upon arrival, drivers always choose the shortest queue. In the case where two or more
queues have the same length, a random choice is made. An exception is when it is
observed that a customer in one of the ‘shortest queues’ is in the payment phase of the
transaction in which case that queue is selected by the arriving driver.

• One or two attendants are available to serve the customers. The service activity has
three phases. During the first phase, the attendant determines the customer’s
requirement and begins the pumping of gas (shut off when the amount has been
delivered or the tank is full). Phase two is the delivery phase during which gas continues
to be pumped until delivery is completed. Phase three is the payment phase. The
duration of phase two is reasonably long, and an attendant typically has sufficient time
either to begin a new phase one (serving a newly arrived customer) or to return to handle
the phase three (payment) activity for a customer whose gas delivery is complete. The
protocol is to give priority to a payment function before serving a newly arrived
customer. It is standard practice for the payment function to be carried out by the same
attendant who initiated the transaction. The above text can be regarded as the initial
phase in the modelling and simulation project. It corresponds to a problem description.

2
Modelling and Simulation
UNIT3

3.1 Role of Modelling and Simulation

1. Comparison of control policy options;
2. Education and training;
3. Engineering design;
4. Evaluation of decision or action alternatives;
5. Evaluation of strategies for transformation or change;
6. Forecasting;
7. Performance evaluation;
8. Prototyping and concept evaluation;
9. Risk/safety assessment;
10. Sensitivity analysis;
11. Support for acquisition/procurement decisions;‫ الحصول‬-‫الدعم‬
12. Uncertainty reduction in decision-making.‫تقليل التردد والشكوك في القرارات‬

3.2 Historical Overview

• The birth of the modelling and simulation discipline can reasonably be associated with
the development of the Link Trainer by Edward Link in the late 1920s. The Link
Trainer is regarded as the first successful device designed for the training of
pilots(‫)المالحة الجوية‬and represents the beginning of an extensive array of training tools
called flight simulators.
• As might be expected, flight simulators quickly embraced(‫ )يتضمن‬computer
technology as it developed in the 1950s, flight simulators expanded, and they have
become indispensable(‫ )اساسي‬platforms for training not only aircraft pilots but also the
members of the Apollo Missions and, as well, the various space shuttle(‫)وسيلة نقل فضائية‬
teams.
• By the mid-1960s, the speed of digital computers and the software make important
contributions to the evolution of the modelling and simulation discipline. The Society
for Modeling and Simulation International (SCS) is one of many well-established
professional organizations devoted(‫يكرس‬-‫ )يتفرغ‬to the modelling and simulation
discipline (in fact, the SCS celebrated its 60th (1962) anniversary in 2012).
• Over the next two decades of the 1970s and the 1980s, a wide variety of software
support for modelling and simulation applications was developed. This made possible
the initiation of increasingly more ambitious projects which, by and large, fall into two
distinct realms, namely, the continuous (engineering design problems formulated

1
Modelling and Simulation
around differential equation models) and the discrete event (process design problems
incorporating stochastic phenomenon and queuing models).

3.3 Simulators
• A simulator can be viewed as a device that replicates(‫ )يستنسخ‬those operational
features of some particular system that are deemed(‫ )يعتبر‬to be important for the
training of operators of that system.
• The use of simulators has spread into a wide range of domains, for example, there exist
power plant(‫معمل‬-‫ )مصنع‬simulators (both nuclear and fossil), battlefield(-‫ميدان القتال‬
‫ )معترك‬simulators, air traffic control simulators and (human) patient simulators.
• The fundamental requirement of any simulator is the replication of system behaviour
within a physical environment that is as realistic as possible from the perspective of
an operator. Although the simulator incorporates(‫يضم‬-‫ )يشمل‬some physical features
of the system, substantial components of the system exist only in the form of models.
• The development of a simulator can be viewed as a modelling and simulation
project; whose goal is to achieve an effective training environment.
• Simulators can contribute in a variety of ways to enhancing the educational
experience of students especially in circumstances(‫الوضع المالي‬-‫ )ظرف‬where
alternatives are precluded(‫يعرقل‬-‫يقيد‬-‫يحدد‬-‫( )يمنع‬e.g. by budgetary constraints) or
alternatively when the devices being examined are either ‘hypothetical’ or are no
longer available in the marketplace. The areas of computer organization and operating
systems are well suited to this application,

3.4 Is There a Downside(‫سلبيات‬-‫ )عيب‬to the Modelling and Simulation

Paradigm?
• Like most tools, modelling and simulation must be used with a good measure of care
and wisdom. An appreciation for the limitations and dangers of any tool is a
fundamental prerequisite for its proper use. We examine some reasons why modelling
and simulation projects can fail
a) Inappropriate statement of a goal.
b) Inappropriate granularity of the model
c) Ignoring unexpected behaviour.
d) Inappropriate mix of essential skills.
e) Inadequate flow of information to the client.

There are a variety of reasons why experimentation directly with it could be inappropriate.
For example, such experimentation might be:
 Too costly

2
Modelling and Simulation
 Too dangerous
 Too time-consuming
 Too disruptive(‫مخرب‬-‫معطل‬-‫)مشوش‬
 Morally/ethically unacceptable
 Irreversible

3
Modelling and Simulation
UNIT4

4.1 Some Reflections(‫تأمالت‬-‫ )التفكير العميق‬on Models

• A model is a representation of an object, system or idea in some form other than itself.

• It is important to recognize a particular and distinctive(‫ )مميز‬class of models called

physical models. These provide the basis for experimentation activity within an
environment that mimics(‫ )يقلد‬the physical environment in which the problem
originates(‫ اوجدت‬-‫)نشأت‬. An example here is the use of scale models of aircraft or ships
within a wind tunnel to evaluate aerodynamic(‫ )ديناميكي هوائي‬properties; another is the
use of ‘crash-test dummies’ in the evaluation of automobile safety characteristics. A
noteworthy(‫جدير بالذكر‬-‫ )مهم‬feature of physical models is that they can, at least in
principle, provide the means for the direct acquisition of relevant experimental data.

• Some models are dynamic while others are static. A linear programming model for
establishing the best operating point for some enterprise under a prescribed set of
conditions, is a static model because there is no notion of time dependence embedded
in such a model formulation. Likewise, the use of tax software to establish the amount
of income tax payable by an individual to the government can be regarded as the
process of developing a (static) model of one aspect of that individual’s financial
affairs for the particular taxation year in question. The essential extension in the case
of a dynamic model is the fact that it incorporates the notion of ‘evolution over time’.

• Another important attribute of any model is the collection of simplifications and

assumptions that are incorporated into its formulation. A simplification is a choice
among alternative ways of dealing with an aspect of the SUI and is focused on reducing
complexity, while an assumption is an unsubstantiated(‫غير مدعوم‬-‫ )غير مثبتة‬choice to fill
a ‘knowledge gap’ that is preventing progress at the modelling or the simulation
phases of the project.
• Simplification is sometimes associated with abstraction or granularity(‫)تفاصيل الدقيقة‬
assessment. The issue here is identifying the correct balance between complexity and
credibility(‫)المصداقية‬, where credibility must always be interpreted in the context of the
goal of the project.
• A degree of information/knowledge deficiency is generally present in any model
development activity. It gives rise to outcomes based on the modeller’s awareness.
When the modeller is aware of the deficiency but nevertheless needs to move forward
with the model development, then an assumption is made about the missing (or
imperfect) information.

1
Modelling and Simulation
4.2 Exploring the Foundations
4.2.1 The Observation Interval
• A modelling and simulation project has two main constituents(‫عنصر‬-‫)مكون‬. The most
fundamental is the underlying ‘system context’, namely, the dynamic system whose
behaviour is to be investigated (SUI). The second essential constituent is the goal for
the project; this has a significant impact on the manner in which the model is
formulated and the experiments carried out with it. A subordinate, but important, third
constituent is the observation interval which is the interval of (simulated) time over
which the behaviour of the SUI is of interest. Often, the specification of this interval,
which we denote by Io, is clearly apparent in the statement of the project goal.
• The starting point of this interval (its left boundary) almost always has an explicitly
specified value. The endpoint (the right boundary) may likewise be explicitly specified,
but it is not uncommon for the right boundary to only be implicitly specified.
• The case where a service facility (e.g. a grocery store) closes at a prescribed time (say
9:00 p.m.) provides an example of an explicitly specified right boundary. Similarly, a
study of the morning peak-period traffic, by definition, to terminate at 10:00 a.m.
Consider, on the other hand, a study of a manufacturing facility that is intended to
end when 5,000 widgets(‫ )منتج‬have been produced. Here the right-hand boundary of
the observation interval is known only implicitly. Likewise, consider a study of the
performance of a dragster. Here a simulation experiment ends when the dragster
crosses the finish line of the racing track.
• Another case of implicit determination occurs when the right-hand boundary is
dependent on some integrity condition on the data that is being generated by the
model’s execution. The most typical such situation occurs when there is a need to wait
for the dissipation of undesired transient effects. Data collection cannot begin until this
occurs. As a result, what might be called the ‘data collection interval’ has an uncertain
beginning. The situation is further complicated by the fact that the duration of the data
collection interval (once it begins) is likewise uncertain because of the difficulty in
predicting when sufficient data of suitable ‘statistical quality’ has been accumulated.

2
Modelling and Simulation
4.2.2 Entities and Their Interactions
• Within the modelling and simulation context, dynamic behaviour is described in
terms of the interactions (over time) among some collection of entities that populates
the space that the SUI embraces. The feature of these interactions that is of particular
interest is the fact that they produce change.
• The entities fall into two broad types, one permanent (intrinsic(‫جوهرى‬-‫ )أساسي‬to the
SUI itself) and the other transient. Certain aspects of this environment have an impact
upon the behaviour that is of interest and these need to be identified.
• Some of these aspects(‫وجه‬-‫ )مظهر‬map onto transient entities. Examples here are the
ships that arrive at a port within the context of a port model developed to evaluate
strategies for improving the port’s operating efficiency or alternately, the features of
a roadway (curves, bumps‫ ) التعرجات والمطبات‬within the context of a model being used
to evaluate high-speed handling and stability properties of automobiles.
• Interaction among entities can occur in many ways. Frequently, this interaction
occurs because the entities compete for some set of limited resources e.g. servers
(banks, gas stations, restaurants), transport services (cranes, trucks, tugboats) or health
services (ambulances, operating rooms, doctors/nurses). This competition can give rise
to a type of entity (called a queue) in which some entities are obliged to wait for their
respective turn to access the resources.

3
Modelling and Simulation
UNIT5

5.1 Data Requirements

 Data requirements can exist in a variety of forms. Consider, for example, a customer
entity. Typically, the data requirement here is the characterization of the customer
arrival rate or, the time between successive arrivals.
 A similar example, a manufacturing process where a machine entity is subject to
failure. The characterization of such failure is typically in terms of rate of occurrence
and repair duration.
 As yet another example, consider the two-dimensional array of intercity flight times
that would likely be necessary for a study of an airline’s operational efficiency. In this
case, this data object would probably be shared by all ‘flight’ entities. These examples
demonstrate that data requirements can be associated with both permanent entities
(e.g. the machines) and transient entities (e.g. the customers).
 The detailed specifications for data requirement can be viewed as a data model. The
formulation of a data model can be a challenging task; furthermore, its correctness is
essential to the quality of the results flowing from the project.
 To illustrate the various notions introduced above, let’s return to the gas station
example. The permanent entities include the attendants and the queue in front of each
of the four pumps. There is only one transient entity, namely, the vehicles that enter
the gas station. Data models would have to be developed to deal with the
characterization of the arrival rate of the vehicles and their separation into vehicle types
and also the service times for each of the three phases of the service function.

5.2 Constants and Parameters

 The constants and parameters serve as names of features or properties within a model.
 In the case of a constant, the assigned value remains invariant over all experiments
associated with the project, e.g. the number of checkout counters in a supermarket.
 On the other hand, in the case of a parameter, the intent embedded in the project goal
is to explore the effect of a specified set of values for the parameter upon behaviour,
e.g. how the performance of an automobile is affected by the value of the parameter Cf
that represents the friction coefficient associated with a tire rolling over a road surface.
 Sometimes a parameter serves to characterize some ‘size attribute’, e.g. the number
of berths at a seaport. In many cases, such a size parameter might be associated with
a facet of a design objective, and the determination of the most appropriate value for
it may be one of the reasons for the modelling and simulation project.
 Often there exist alternate behavioural options to be considered within a model.
1
Modelling and Simulation
5.3 Time and Other Variables
 Variables provide an abstraction mechanism for features of the model whose values
change as the model evolves over the course of the observation interval. Variables fall
into a variety of categories, and some of these are examined below. As we shall see,
time itself is a very special variable that is common to all dynamic models.
Time
 Because our interest is exclusively with dynamic systems, there is one variable that is
common to all models that we consider, namely, time (denote t).
 The variable, t, represents ‘virtual time’ as it evolves within the model. Except for
certain special cases, this has no relation to ‘wall clock’ (i.e. real) time.
Time Variables
 If X is designated as a time variable, then this is usually made explicit by writing X(t)
rather than simply X. Standard mathematical convention associates with X(t).
Input Variables
 Input variables are intended to serve as the means for characterizing the inputs to a
SUI during the model building process.
State Variables
 The model’s dynamic behaviour can be entirely defined in terms of the state variables
together with input variables and parameters. The state variables capture the effects of
past behaviour as it impacts upon future behaviour.
Output Variables
 The output variables of a model reflect
those features of the SUI’s behaviour; in
other words, it is the project goal that
effectively gives rise to the model’s output
variables.
 The output variable y(t), for example,
𝐲(𝑡) = 𝐠(𝐱(𝑡), 𝐮(𝑡), 𝐩)
 Here the vector x(t) represents a candidate
set of state variables while u(t) and p are
the input variables and the parameters of
the model, M, whose behaviour is to be
observed over the observation interval
 We conclude this section by including Fig.
that illustrates how the parameters, input
variables, and the state variables interact
to generate behaviour and how the
observation of behaviour is provided via
the outputs of the model.

2
Modelling and Simulation
UNIT6

6.1 The Problem Description

 This key document evolves from the information received from the client concerning
the SUI and the problem of interest in whatever detail is deemed essential by the project
team. Possible solutions to be evaluated might also be provided. The intent is to ensure
that the problem description document can serve as a meaningful foundation for
undertaking a modelling and simulation study.
 The problem formulation phase is meant to provide a clear and complete statement of
the problem such that a model can be undertaken. We identify the outcome of
problem formulation phase with the problem description document.
 The document is not static but rather is subject to refinement as the model building
effort progresses. The main focus is on behavioural features which are typically
formulated in terms of the various objects that populate the space that the SUI embraces.
Particular emphasis is on the
interactions among these objects.
 Apart from its behavioural
features, the SUI’s structural
features are also included because
these provide the context for the
interactions among the objects
(e.g. the layout of the pumps at a
gas station or the topology of the
network of streets being serviced
by a taxi company).

6.2 The Project Goal

 The project goal is to evaluate a set
of possible solutions to the
problem, the first step in the
development of a model study is
the formulation of such a set.
These solution possibilities are,
almost always, expressed in terms
of values specified for parameters.
Strategies for achieving the goal
include details of the

1
Modelling and Simulation
experimentation process relating to the parameter variations together with the
identification of the output that produce, during experimentation, the data required
for analysis and evaluation. The project goal and the associated strategies have a
fundamental impact upon model development and must, be regarded as prerequisites
to that development process.

6.3 The Conceptual Model

 The information provided by the problem description is inadequate to support the
high degree of precision that is required for creating a credible model. A refinement
phase must be carried out in order to add detail where necessary, incorporate
formalisms wherever helpful and generally enhance the precision and completeness
of the information. The reformulation of the information within the problem
description in terms of parameters and variables is an initial step since these notions
provide a fundamental means for removing ambiguity and enhancing precision.
 There are a variety of formalisms can be used in the refinement process. Included
here are mathematical equations and relationships (e.g. algebraic and/or differential
equations), symbolic/graphical formalisms (e.g. Petri nets, finite state machines), rule-
based formalisms, structured pseudo code and combinations of these.
 The result of this refinement process is called the conceptual model for the modelling
and simulation project. The conceptual model may, in reality, be a collection of
partial models each capturing some specific aspect of the SUI’s behaviour.
 The conceptual model is a consolidation of all relevant structural and behavioural
features of the SUI in a format that is as concise and precise as possible. In addition,
it serves as a bridge between the problem description and the simulation model.
 A verification activity is associated with the transition from the problem description
to the conceptual model. Verification is included as part of the transition under
consideration because it involves a reformulation of the key elements of the model from
one form to another, and the correctness of this transformation needs to be confirmed.

6.4 The Simulation Model

 The essential requirement for the experimentation phase of a modelling and
simulation project is the existence of an executable computer program that embodies
the conceptual model. This is, in fact, a two-step process: the first step is to develop
the simulation model from the conceptual model and the second step is the creation
of the simulation program. The result of this transformation is the simulation model.
 The formulation of a simulation model can be undertaken in a variety of programming
environments, such as C++ and Java. Increasingly more common, however, is the use
of programming environments that has been specifically designed to support the special
2
Modelling and Simulation
requirements of simulation studies; some examples are SIMSCRIPT II.5, ProModel,
GPSS, SIMAN, ACSL, Modelica, Arena, CSIM and SIMPLE++. Such
environments generally provide features to support the management of time,
collection of data and presentation of output, generation of random variates,
management of queues and the statistical analysis of data are also provided.
 The transition from the conceptual model to the simulation model is associated with
two activities, namely, transformation and verification. As in the transition from
problem description to the conceptual model, verification is required here to confirm
that the transformation has been correctly carried out.

6.5 The Simulation Program

 When the programming environment used in developing the simulation model is
specifically designed for simulation studies,
 The services in question fall into two categories, one relates to fundamental
implementation issues while the other is very much dependent on the nature of the
experiments that are associated with the realization of the project goal. Included
within the first category are such basic tasks as initialization, assignment of the
observation interval, management of stochastic features, solution of equations, data
collection. The second category of functional services can include such features as
data presentation (e.g. visualization and animation), data analysis, database support,
optimization procedures.
 A verification activity needs to be carried out in the transition from the simulation model
to the simulation program. This need arises because this transition typically involves a
variety of decisions relating to the execution of the simulation model, and the
correctness of these decisions must be confirmed.

6.6 The Operational Phases

 The first of these is the validation phase, whose purpose is to establish the credibility
of each the model realizations, from the perspective of the project goal. The second
phase, is the simulation phase which can be regarded as the experimentation phase.
 This activity is presented as the task of ‘goal resolution’. This is achieved via a series
of experiments with the simulation program during which data is collected and analysed
until it is apparent that a ‘goal resolution database’ is sufficiently complete and
comprehensive to permit conclusions relating to the goal to be confidently formulated.

6.7 Verification and Validation

 Verification – are we building the product right?
 Validation – are we building the right product?

3
Modelling and Simulation
UNIT7

7.1 Introduction
7.1.1 Exploring Structural and Behavioural Requirements
Customers arrive in the department store and generally intend to make purchases at
various merchandise areas (departments) of the store. At each such area, a customer
browses/shops and may or may not make one or more selections to purchase. If selections
are made, they are paid for at one of several service desks located within the area.
Following each visit to a merchandise area, customers either move to another
department or, when their shopping task is completed, they leave the store.
 In this fragment of the description, each customer corresponds to an entity which we
might reasonably regard as a type of
‘consumer’ entity (generalization is,
in fact, an abstraction step).
 In a similar way, we could regard
each of the service desks within the
various merchandise areas as a
resource entity as the consumer
(customers) need to access these
resource in order to complete their
purchase transactions.
 Because the service at the resource
has a finite duration, there is a
possibility that some customer may
not receive immediate attention upon
arrival at the resource because it is
‘busy’ serving other customers.
Hence, it is reasonable to associate a
queue entity with each resource
where customer can wait for their
turn to access the resource.
 The merchandise areas where
customers evaluate merchandise Behaviour of three department store shoppers
(with possibly making a purchase) are
distinctive. On one hand, each can be regarded simply as a ‘holding’ area for a
collection of consumer (customers). With this perspective, a merchandise area can be
represented as a particular type of aggregate which we call a group (unordered
collection of entities). On the other hand, a merchandise area is a prerequisite for an
activity called ‘shopping’. Hence, it has features of a resource. In effect, then, the
merchandise areas within the department store have a dual role.

1
Modelling and Simulation
 Figure shows a possible interaction scenario for three shoppers all of whom enter
shopping area 1 upon their arrival. The three shoppers (called A, B and C) arrive in
the store at times A0, B0 and C0, respectively, and leave the store at times A5, B7 and C3,
respectively. There are a number of important observations that can be made about
Fig, Notice, in particular, that some type of transition occurs at each of the time points
such activities are (Shopping, Waiting in Queue, and Service at Desk)

,
Behaviour of three department store shoppers

7.1.2 Overview of the Constituents of the Activity-Based Conceptual modelling

(ABCmod Framework)

 The conceptual model provides a representation (abstraction) of the SUI’s behaviour

that is consistent with the requirements of the project goal.
 There are two collections of modelling required for the conceptual modelling. The first
deals with the abstraction of the objects that are interacting within the SUI (structure
of the SUI), and the second focuses on the nature of these interactions (behaviour of
the SUI).
 The SUI’s behaviour fall into two categories called activities and actions. An activity
encapsulates a ‘unit’ of behaviour that is to have relevance to the model-building task.
An activity is instantiated as the consequence of an event.

2
Modelling and Simulation
UNIT8

7.2 Model Structure

Entities
• An important step in the development of a conceptual model is the identification of a
collection of entity, this collection defines the structure of the conceptual model.
• Each entity has two properties which are called role and scope. The notion of role is
to provide a suggestive (intuitive) link between the features of the SUI and the
conceptual model-building environment provided by the ABCmod framework. There
are four basic alternatives (values for role), namely,
1. Resource: When the entity provides a service.
2. Consumer: When the entity seeks services (provided by a resource).
3. Queue: an ordered collection of other entities of the same entity category.
4. Group: an unordered collection of other entities of the same category.
• The scope of an entity category reflects upon the number and permanence of the
entities within that category. In the case where exactly one entity exists in a category,
that entity category is said to have scope = Unary. When an entity category contains a
finite (and fixed) number, N > 1, then scope = Many[N]. If the number of entities in the
category varies over time, then scope = Transient.
7.3 Structural View
A structural diagram, a high-level visual presentation of entities within these categories,
is of considerable help in carrying out this first stage in the conceptual modelling process.
A collection of icons, summarized in Table, is provided for this purpose. The structural
diagram is a collection of labelled icons as presented in Table below.

1
Modelling and Simulation
To illustrate, we consider the department store example introduced earlier. Recall the SUI
includes customers who shop in merchandise areas (three are available), possibly making
selections, paying for them at service desks (one is available in each department) and then
(possibly) moving on to another merchandise area. A structural diagram representation of
the entities appropriate for the department store example is given in Fig. Note that a
collection of three shopping areas is shown, each of which has a service desk and a line
(a queue of customers) in front of this desk. The Customer entities belong to a category
with scope = Transient and representative instances are shown by shaded circles.

2
Modelling and Simulation
UNIT9

7.4 Model Behaviour

• The characterization of behaviour in the ABCmod framework is carried out using a
collection of behavioural artefacts. Two principle types are activities and actions. The
notion of an ‘event’ is central to both these artefacts.
Events
• Our perspective in the ABCmod framework is that an event is an instantaneous change
in the status of the model. In effect, an event has a time of occurrence (its event time)
and an impact upon the status of the model (change in the model’s state). This impact
is outlined in the event’s status change specification (SCS).
• Two types of event can be identified based on a difference in the manner in which event
time is prescribed. The first is called a scheduled event. The essential feature of a
scheduled event is that its occurrence happens at some known point in time. Typically,
this time is specified relative to of the event time of another related event. To illustrate,
consider a scheduled event B which will happen following an event A. If we let 𝝉𝑨 and
let 𝝉𝑩 , denote event times of events A and B, respectively, then let 𝝉𝑩 = 𝝉𝑨 + ∆ is
known either explicitly (e.g. ∆ = 10).
• An alternate (and indirect) event time specification mechanism flows from the notion
of a precondition which is a Boolean condition typically formulated in terms of one or
more state and/or input variables. An event which has a precondition is called a
conditional event. Such an event will occur if and only if its precondition evaluates to
TRUE; The event time for a conditional event is the value of time when the event’s
precondition acquires a TRUE value.
Examples
• iC.Customer = SP.RemoveQue(Q.CustLine)
• SP.InsertGroup(RG.Counter, iC.Customer)
• SP.RemoveGroup(RG.Counter, iC.Customer)
Action: TankerArrivals
• iC.Tanker.startWait ← t // time of occurrence
• SP.InsertQue(Q.BerthingList, iC.Tanker) //status change increase queue
Activities
• The activity is the main modelling artefact for characterizing change or behavior. Each
activity serves to represent a unit of behaviour that is associated with a purposeful task
within the SUI.

1
Modelling and Simulation
• The generic representation for an activity is shown in Fig. a. It consists of a starting
event and a terminating event which are separated by a duration. As previously
pointed out, an event has two fundamental attributes, namely, its event time (the time
of its occurrence) and its status change specification (SCS) which is a specification of
its impact upon the model’s status. Figure b makes explicit the two attributes of each
of the events.

• We recognize four types of activity within the ABCmod framework.

• The conditional activity: In this case, the Initiator is a precondition, i.e. a Boolean
condition typically formulated in terms of one or more of the entity attributes/variables
that exist within the model.
• The scheduled activity: In this case, the Initiator is a time sequence. Each value in the
time sequence maps onto the event time of the starting event of an instance of the
scheduled activity.
• The sequel activity: Often there are circumstances where one identifiable unit of
behaviour follows immediately upon completion of another and circumstances require
a separation between these two units of behaviour.
• The scheduled sequel activity: This fourth activity type provides for scheduling the
sequel activity at some time point in ‘the future’ rather than having its initiation coincide
with the event time of the terminating event of the initiating activity instance. Note also
that it is possible to schedule a sequel activity as part of an action instance.

2
Modelling and Simulation
Examples
Activities:
• Serving: This activity represents the serving of a customer.
Activity: Berthing
starting event
• iC.Tanker ← SP.RemoveQue(Q.BerthingList) //status
• iC.Tanker.totalWait +← (t – iC.Tanker.startWait) //time
terminating event
• SP.InsertGrp(RG.Berths, iC.Tanker) //status
• SP.StartSequel(Loading, iC.Tanker) //status

Actions
• While activities serve to capture the various relevant tasks that are carried out within
the SUI, an action simply provides the means for characterizing relevant events that
are not embedded within activities. Because an action is simply an event, it unfolds at
a single point in time and consequently the concept of ‘instances’ is not meaningful.
• There are three types of action called the scheduled action, the scheduled sequel action
and the conditional action. The scheduled action consists of a particular event that is
scheduled at one or more points in time. The scheduled sequel action allows the
scheduling of an action at some time point in ‘the future’. The conditional action
corresponds to a conditional event.
Examples
• Actions:
Arrivals: This scheduled action generates the input entity stream of
customers.
StaffChange: The change in the number of employees behind the counter.
TankerArrival: This scheduled action generates the input entity stream of
tankers. With each arrival, tanker attribute values are assigned and the
tanker entity is placed into the Q.BerthingList entity.
7.5 Behavioural View
The entity of any particular becomes involved in a sequence of activity. This involvement
is an important behavioural feature. It is helpful to have a high-level presentation of this
essential feature. This presentation is called a life cycle diagram for the entity, which
provides the behavioural diagram for the project.
Each activity in a life cycle diagram is shown as a labelled rectangle. There are several
possible circumstances whereby an entity can transit from an activity A to an activity B.
Often, this transition encounters a delay. This delay can occur because of inhibiting

3
Modelling and Simulation
preconditions and we indicate this possible delay with a circle which we call a wait point.
The transition will ultimately be to the one whose precondition first becomes TRUE. Fig1.
There are two distinct possibilities as shown in Fig. In Fig a, the implication is that the
transition is direct because B is a sequel activity. In Fig. b, the divided circle is intended to
imply that the transition is direct even though B has a precondition.

Example
The Figure illustrates a life cycle diagram for the
Customer entity in the department store example.
The Customer entity category has scope = Transient
which implies that there is an entity stream
exogenous input which in turn implies the need for
an action (called Arrival). Upon arrival, the
Customer engages in the shopping activity in some
department. Shopping in any particular department
may not result in a purchase (hence, no payment
activity is required). In this circumstance, the
Customer may either leave the store or move on to
another department to continue shopping. If a
purchase is made, then the payment activity takes place followed (possibly) by further
shopping in another department or exit from the store.

4
Modelling and Simulation
UNIT10

10.1 Problem Description

Problem Statement
Tankers of various sizes are loaded with crude oil at a port that currently has berth
facilities for loading three tankers simultaneously. Empty tankers arrive in the harbour
entrance where they often wait for the necessary assistance from a tug (only one is
available) to move them into a berth where the loading takes place. After the loading
operation is complete, a tanker again requires assistance from a tug to move from the
berth back to the harbour entrance. The port authority wishes to address the increasing
number of complaints from tanker captains about excessive turnaround times. It is
considering the construction of a fourth berth and requires some insight into the likely
impact of such an expansion.
Processing of Tankers
1. An arriving tanker at the harbor entrance is added to the end of the list of tankers
needing to be berthed.

2. Each tanker must wait until all previously arrived tankers have been berthed by the
tug. When the tug becomes available for berthing, the tug moves the tanker from the
harbour entrance to the berth.

3. The loading procedure starts as soon as the berthing operation is complete at which
time the tug is released to carry out its next task. When the loading is completed, the
tanker is added to the end of a second list of tankers needing to be deberthed.

4. Each loaded tanker must wait until all previously loaded tankers have been deberthed.
When the tug becomes available for deberthing, the tug moves the tanker from the
berth back to the harbour entrance and the tanker leaves the port.

Schematic view of the port’s operation

1
Modelling and Simulation
Tug Operation
1. If the deberthing list is empty but the berthing list is not empty and a berth is available,
then the tug is requested to travel to the harbour entrance and begin berthing the tanker
at the top of the berthing list. When the tug finishes a berthing operation, the tug is
requested to deberth the tanker at the top of the deberthing list.
2. If the berthing list is not empty and a berth is not available, the tug remains idle in the
berth area.
3. When the tug finishes a deberthing operation and the berthing list is not empty (i.e.,
there are waiting tankers in the harbour), the tug is requested for a berthing operation.
If the berthing list is empty and there is at least one tanker in the berths, the tug begins
the journey back to the berth area without any tanker in tow (i.e., ‘empty’).
4. If the berthing list is empty and there are no occupied berths, the tug remains idle at
the harbour entrance waiting for the arrival of a tanker.

10.2 Project Goal and Achievement

Turnaround time has five components (a) waiting time at the harbour, (b) travel time
from harbour to berths, (c) loading time, (d) waiting time in the berths and (e) travel time
from berths to harbour. The addition of a fourth berth has no effect on travel times or
loading times but will impact the waiting times. The project goal is to evaluate how the
addition of a fourth berth will affect the waiting time of tankers and the usage of the
available berths. We compare two cases as specified by the parameter introduced for this
purpose. Its assigned values are given below:
RG.Berths.numBerths: The number of berths for loading tankers. The two values
of interest are 3 (base case) and 4 (alternate case).

10.3 Conceptual Model

High-Level Conceptual Model
Assumptions
• The time required for the tug to travel from the harbour to the berths or from the
berths to the harbour with no tanker in tow is a constant.
• The times required for berthing a tanker and for deberthing a tanker are both constants
that are independent of tanker size.
Simplifications
• The tankers fall into three size categories: SMALL, MEDIUM and LARGE.
• The berths are not actually modelled as individual entities but rather as a resource that
can simultaneously service several tanker entities; namely, 3 or 4.

2
Modelling and Simulation
Structural View
• The structural diagram shows the entities used to represent the tankers, tug, berths and
lists used by the harbour master.

Entity Categories
• BerthingList: A queue of empty tankers waiting to be berthed by the tug.
• DeberthingList: A queue of tankers loaded with oil ready for deberthing.
• Tug: A single resource that berths and deberths the tankers as it travels between the
harbour and berths.
• Berths: A resource group that represents the set of berths used for loading the tankers
with oil. The attribute numBerths of this entity is a parameter.
• Tanker: A consumer representing the tankers. Because of the transient existence of
tankers within the model, this entity has scope = Transient.
Behavioural View
Actions:
• TankerArrival: This scheduled action generates the input entity stream of tankers. With
each arrival, tanker attribute values are assigned and the tanker entity is placed into the
Q.BerthingList entity.

Activities:
• Berthing: This activity represents the Tug entity towing an empty Tanker entity from the
harbour to the berths.
• Deberthing: This activity represents the Tug entity towing a loaded Tanker entity from
the berths to the harbour (at which point the Tanker entity leaves the model).
• MoveToBerths: This activity represents the Tug entity moving to the berths area with no
Tanker entity in tow.
• MoveToHarbour: This activity represents the Tug entity moving to the harbor with no
Tanker entity in tow.
• Loading: This activity represents the loading of a Tanker. This is a sequel activityand is
initiated at the completion of the Deberthing activity.

3
Modelling and Simulation