Q.

1) What is simulation and explain the

need for Simulation.
Q.2) What is simulation and list the
disadvantage for Simulation.
Simulation:

In its most general sense, a simulation can be defined as:

An imitation of a system.

Imitation implies mimicking or copying something else. For instance, a forger imitates the work of a
great artist.

 The Strip in Las Vegas is full of imitations: the Eiffel Tower, the New York skyline, Venice and
so on.
 In soccer, if a player imitates being the recipient of foul play, it is referred to as ‘simulation’.
 Computer aided design (CAD) systems provide imitations of production facility designs and a
business process map is an imitation of a business organisation.

All of these can be described as a simulation in its most general sense.

There is a difference between the concepts of a

o static simulation, which imitates a system at a point in time, and a

o dynamic simulation, which imitates a system as it progresses through time

Building on the previous definition, computer based dynamic simulation can be defined as follows:

An imitation (on a computer) of a system as it progresses through time.

In general terms a system is a collection of parts organised for some purpose. The weather system,
for instance, is a collection of parts including the sun, atmosphere, land and water, that is designed
for the purpose of maintaining life.

Four main classes of system:

1. Natural systems: systems whose origins lie in the origins of the universe e.g. the atom, the
Earth’s weather system and galactic systems.
2. Designed physical systems: physical systems that are a result of human design e.g. a house,
a car and a production facility.
3. Designed abstract systems: abstract systems that are a result of human design e.g.
mathematics and literature.
4. Human activity systems: systems of human activity that are consciously, or unconsciously,
ordered e.g. a family, a city and political systems.
Simulation is also defined as:

Experimentation with a simplified imitation (on a computer) of an operations system as it progresses

through time, for the purpose of better understanding and/or improving that system

The Need for Simulation

Many operations systems are interconnected and subject to both variability and complexity
(combinatorial and dynamic). Because it is difficult to predict the performance of systems that are
subject to any one of variability, interconnectedness and complexity, it is very difficult, if not
impossible, to predict the performance of operations systems that are potentially subject to all
three.

Simulation models, however, can explicitly represent the variability, interconnectedness and
complexity of a system. As a result, it is possible with a simulation to predict system performance, to
compare alternative system designs and to determine the effect of alternative designs and policies
on system performance.

The Disadvantages of Simulation

 Expensive. Simulation software is not necessarily cheap, and the cost of model development
and use may be considerable, particularly if consultants must be employed.
 Time consuming. It has already been stated that simulation is a time-consuming approach.
This only adds to the cost of its use and means that the benefits are not immediate.
 Data hungry. Most simulation models require a significant amount of data. This is not always
immediately available and where it is, much analysis may be required to put it in a form
suitable for the simulation.
 Requires expertise. Simulation modelling is more than the development of a computer
programme or the use of a software package. It requires skills in, among other things,
conceptual modelling, validation and statistics, as well as skills in working with people and
project management. This expertise is not always readily available.
 Over confidence. There is a danger that anything produced on a computer is seen to be
right. With simulation this is further exacerbated with the use of an animated display, giving
an appearance of reality. When interpreting the results from a simulation, consideration
must be given to the validity of the underlying model and the assumptions and
simplifications that have been made.
Q.3) When and where the simulation is
appropriate and in-appropriate?
When and Where Simulation is appropriate

When a system can be simulated:

1. To study the internal interaction among different components of system.

2. With the help of simulation system parameters can be adjusted.
3. To experiment new design prior to the implementation.
4. To verify analytical solution.
5. To determine the requirement of system.
6. To visualize the plan through animation.
7. To observe the effect of environment changes on the system.
8. To improve the system through the knowledge gained in designing simulation model.
9. To provide better understanding of system operation.
10. To perform bottle neck analysis.

Where a system can be simulated:

It is impossible to give a full list of applications for which simulation might be used. It is, however,
useful to give some indication of the range of systems that can be modelled.

The list is as follows:

1. Manufacturing systems
2. Public systems: health care, military, natural resources
3. Transportation systems
4. Construction systems
5. Restaurant and entertainment systems
6. Business process reengineering/management
7. Food processing
8. Computer system performance

When and Where Simulation is in-appropriate

When a system cannot be simulated:

There are ten rules for evaluating when simulation is not appropriate.

1. The first rule indicates that simulation should not be used if the problem can be solved by
common sense.
2. Simulation should not be used when the problem can be solved analytically.
3. Simulation should not be used if it is easier to perform direct experiments.
4. Simulation should not be used if the cost of simulation exceeds the savings.
5. Simulation should be avoided if resources are not available.
6. Simulation should not be used if time is not available.
7. Simulation takes data, sometimes lots of data. If no data is available, not even estimates,
simulation is not advised.
8. This rule concerns the ability to verify and validate the model. If there is not enough time or
if the personnel are not available, simulation is not appropriate.
9. If managers have unreasonable expectations, if they ask for too much too soon, or if the
power of simulation is overestimated, simulation might not be appropriate.
10. Last, if the system behaviour is too complex or can’t be defined, simulation is not
appropriate. Human behaviour is sometimes extremely complex to the system.

Where a system cannot be simulated:

I don’t know
Q.4) Explain time slicing approach based
on simple telephone call centre
simulation.
The Time-Slicing Approach

The simplest method for modelling the progress of time is the time-slicing approach in which a
constant time-step (Δt) is adopted. In a telephone call centre, calls arrive every three minutes and
are passed to one of two operators who take five minutes to deal with the customer (Figure 2.1). It is
assumed for now that there is no variation in the inter-arrival time and the service time.

Table 2.1 shows

 24 minutes of simulation of the call centre with Δt set to one minute.

 Column two shows the time remaining until a call arrives.
 Columns three and four show the time remaining until a customer service is complete.
 The number of calls completed by each operator is calculated.
It is relatively simple to set-up a time-slicing simulation for this situation. The same approach could
be used for more complex situations, although the table would soon become very large and possibly
unmanageable by hand. By devising a flow chart outlining the sequence of activities it would be
possible to develop a computer program to perform the simulation, making larger scale simulations
possible. The time-slicing approach can also be modelled easily in a spreadsheet.

There are two main problems with the time-slicing approach.

First, it is very inefficient. During many of the time-steps there is no change in the system state and
as a result many computations are unnecessary. In Table 2.1 the only points of interest are when a
call arrives, when an operator takes a call and when an operator completes a call. In total there are
22 such points as opposed to the 72 (24 time periods x 3 columns) calculations performed in Table
2.1. This problem is only likely to be worsened the larger the simulation becomes.

A second problem is determining the value of Δt. Although that a one-minute time step seems
obvious for the example above, in most simulations the duration of activities cannot be counted in
whole numbers. Also, there is often a wide variation in activity times within a model from possibly
seconds (or less) through to hours, days, weeks or more. The discrete-event simulation approach
addresses both issues.
Q.5) 3 Phase Approach of Simulation
The Three-Phase Simulation Approach

In the three-phase simulation approach events are classified into two types:

 B (bound or booked) events: these are state changes that are scheduled to occur at a point
in time. For instance, the call arrivals in the call centre model occur every three minutes.
Once a call has been taken by an operator, it can be scheduled to finish five minutes later.
This principle applies even when there is variability in the model, by predicting in advance
how long a activity will take. In general B-events relate to arrivals or the completion of an
activity.
 C (conditional) events: these are state changes that are dependent on the conditions in the
model. For instance, an operator can only start serving a customer if there is a customer
waiting to be served and the operator is not busy. In general C-events relate to the start of
some activity.

In order to demonstrate the three-phase approach a call centre example is now introduced (Figure
2.2).

Two types of customers (X, Y) make calls to the centre. Calls arrive from a customer type X every five
minutes and from a customer type Y every ten minutes. Arriving calls are placed in a queue (denoted
by a circle) before the call router (a touch tone menu system) directs the call to the right operator;
an activity that takes 1 minute. There are two operators, the first takes all customer X calls, the
second all customer Y calls. Operator 1 takes exactly four minutes to deal with a call and operator 2
exactly seven minutes.
As a first step all the B and C events for the system need to be defined. These are shown in Tables
2.3 and 2.4 respectively. Note the column that specifies which events are to be scheduled following
an event, for instance, the arrival of a customer type X leads to the next arrival being scheduled
(event B1). Since each C-event represents the start of an activity, they schedule the B-event that
represents the completion of that activity. For events B4 and B5 the calls are output to the ‘world’.
This term means that the calls are passed out of the model. Also note that for events B4 and B5,
statistics are collected on the number of customers served. For each C-event the conditions for it to
be executed are specified.

Having identified all the events, the system can be simulated. Figure 2.3 outlines the three-phase
approach. At the start of the simulation the initial state of the model is determined. This may involve
placing work-in-progress in the model in order to create a realistic initial condition. The initial B-
events are also scheduled, for instance, the arrival of the first customers. Scheduled events are
placed into an event list that keeps a record of all future events that have been scheduled. The
simulation then moves into three phases that are continuously repeated.
In the A-phase, which is also known as the simulation executive, the time of the next event is
determined by inspecting the event list. The simulation clock is then advanced to the time of the
next event. In the B-phase all B-events due at the clock time are executed. In the C-phase all C-
events are attempted and those for which the conditions are met are executed. Since the successful
execution of a C-event may mean that another C-event can now be executed, the simulation
continues to attempt C-events until no further events can be executed. The simulation then returns
to the A-phase unless it is deemed that the simulation is complete. Typically, a simulation is run for a
predetermined run-length or possibly a set number of arrivals.
Q.6) What is conceptual model? What are
the requirements?
Definition of a Conceptual Model

[A] non-software specific description of the computer simulation model (that will be, is or has been
developed), describing the objectives, inputs, outputs, content, assumptions and simplifications of
the model.

First, this definition highlights the separation of the conceptual model from the computer model.
The latter is software specific, that is, it represents the conceptual model in a specific computer
code. The conceptual model is not specific to the software in which it is developed. It forms the
foundation for developing the computer code.

Second, it is stated that the description is of a computer simulation model ‘that will be, is or has
been developed’. This serves to highlight the persistent nature of the conceptual model. It is not an
artefact that gets created and is then dispensed with once the computer code has been written. It
serves to document the basis of the computer model prior to development, during development and
after development.

Finally, the definition is completed by a list of what a conceptual model describes. It is vital that the
objectives of the model are known in forming the conceptual model. The model is designed for a
specific purpose and without knowing this purpose it is impossible to create an appropriate
simplification.

Requirements of a Conceptual Model

The key requirements are that the model should be valid, credible, feasible and have utility.

In other words, the model should:

 Produce sufficiently accurate results for the purpose at hand (validity).

 Be believed by the clients (credibility).
 Be feasible to build within the constraints of the available data and time.
 Have utility, that is, sufficiently easy to use, flexible, visual and quick to run.

Overarching all of this is the requirement to build the simplest model possible to meet the objectives
of the simulation study.

Simpler models are preferred because:

 Simple models can be developed faster

 Simple models are more flexible
 Simple models require less data
 Simple models run faster
 The results are easier to interpret since the structure of the model is better
understood
As such, the need to abstract a conceptual model from the system description becomes even more
pertinent. This does not, of course, mean that more complex models should never be developed, but
that we should only develop them if they are required to meet the modelling objectives. Conceptual
modelling is about creating an appropriate model, not simple models per se.

Q.7) Explain 4 methods for representing

the Conceptual Model.
Representing the Conceptual Mode (Any Four)
The five most popular methods of representation are:

 Component list
 Process flow diagram
 Logic flow diagram
 Activity cycle diagram
 List of assumptions and simplifications

These are not the only methods of representing a conceptual model.

Component List
This provides a list of the components in the model with some description of the detail included for
each. Table 5.1 provides an example for the single server queue. Although tables have the benefit of
being very simple, they do not provide a visual representation of the conceptual model and it is
difficult to capture complex logic and the process flow.

Process Flow Diagram (Process Map)

In this approach the conceptual model is represented as 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. Figure 5.5 is an example of a process flow
diagram for the single server queue. In this diagram the detail of the components is denoted in
brackets.

This is a simple approach and the visual representation is useful for showing the process flow. Since
many simulation packages use a similar representation, this approach is beneficial. It is still difficult,
however, to capture more complex logic.
Logic Flow Diagram
Logic flow diagrams use standard flow diagram symbols to represent the logic of the model rather
than the process flow. Figure 5.6 shows an example for the single server queue. These diagrams are
good for capturing logic and the nomenclature is likely to be familiar to the user. The process flow is
not always obvious, however, and these diagrams can quickly become large, complex and
cumbersome for models of any reasonable scale.

Activity Cycle Diagram

Activity cycle diagrams are used as a specific means for representing discrete-event simulation
models. Figure 5.7 shows an example for the single server queue.

 Circles represent dead states, where an entity waits for something to happen.
 Active states, represented by rectangles, are where an entity is acted upon.

This normally entails a time to process the entity before passing it on to the next state. In general,
active and dead states alternate.
A dead state of ‘outside’ the model is included in Figure 5.7 in order to create a complete activity
cycle, that is, customers come from and are returned to ‘outside’.

Activity cycle diagrams sit somewhere between process flow diagrams and logic flow diagrams in
that they describe, in part, the logic of a model while also giving a visual representation. They can
quickly become very complex, however, for models that are not moderate in scale. They provide a
convenient means for identifying the events in a simulation (Section 2.2.2) and so their main use has
been to act as a basis for programming simulation models. As a result, they are probably less useful
if a simulation package is to be employed.

List of Assumptions and Simplifications

It is useful to compile all the assumptions and simplifications into a bullet list or table. In this way the
full set of assumptions and simplifications are presented in one place. Table 5.2 presents an example
for the single server queue. The approach can be extended to document an assessment of the
confidence and impact of each assumption, and the impact of each simplification.

It is, of course, very beneficial to provide a list of the assumptions and simplifications in the model,
since it enables quick reference to them when understanding and validating the model, and when
interpreting the results of the model. The list, however, does not constitute full documentation of
the conceptual model and so should generally be used in conjunction with another method of
representation.
Q.8) Framework of Conceptual Model
with Diagram.
A Framework for Conceptual Modelling

Figure 6.1 provides an outline of Robinson’s framework for conceptual modelling. The framework
consists of five key activities:

1. Understanding the problem situation

2. Determining the modelling and general project objectives
3. Identifying the model outputs (responses)
4. Identifying the model inputs (experimental factors)
5. Determining the model content (scope and level of detail), identifying any assumptions and
simplifications

Iske aage tumse naa ho paaayega ye answer

Developing an Understanding of the Problem Situation

For the modeller to develop a good understanding of the problem situation if he/she is to develop a
model that adequately describes the real world. The approach to this process depends in large
measure on the extent to which the clients understand, and can explain, the problem situation. In
many circumstances the clients will be able to provide such an explanation, for instance, by
describing the operation of the (proposed) real world system that is at the heart of the problem
situation.

One issue is that the clients may not have a good understanding of the cause and effect relationships
within the problem situation.