Simulation & Modeling

AHMED EZZAT LABIB

HELWAN UNIVERSITY
Text Books

 Simulation: The Practice of Model Development and Use,

Stewart Robinson, John Wiley & Sons Ltd, 2004.
 Modeling and Simulation in the Systems Engineering Life
Cycle, Margaret L. Loper, Georgia Tech Research
Institute, Atlanta, USA, Springer, 2015.
Introduction

 There are different points of views of teaching this course

(but each point of view concentrate on specific slice of
this discipline); for example:

1. Industrial and Systems Engineering teaches discrete

event simulation,

discrete-event simulation (DES) models the operation

of a system as a discrete sequence of events in time.
In contrasts with continuous simulation
 Different points of view

 College of Computing teaches parallel and distributed

simulation,
 Mechanical Engineering teaches model based design,
 Electrical and Computer Engineering teaches continuous
simulation,
 and Aerospace Engineering teaches surrogate (in exchange
for) modeling.
 Example: building discrete-event simulations to model
a queue, such as customers arriving at a bank to be
served by a teller.

(1) the system entities are:

i. Customer-queue′
ii. and Tellers
(2) The system events are:
i. Customer-Arrival
ii. and Customer-Departure.
iii. (The event of Teller-Begins-Service can be part of the
logic of the arrival and departure events.)
Components of discrete-event
simulation
(3) The system states, which are changed by these
events, are:
i. Number-of-Customers-in-the-Queue (an integer from 0 to n)
ii. and Teller-Status (busy or idle).
(3) The random variables that need to be characterized
to model this system:
i. Customer-Interarrival-Time
ii. and Teller-Service-Time
Remember: All of these methodologies are important to
understand, and each has a different purpose in
the systems engineering life cycle.

 In this course:
 put all this information in one place
 This course provides:
 an introduction to the fundamental concepts of M&S and systems
engineering, and how M&S is used in the systems engineering life
cycle.
 The contents are grouped into five Parts that cover:
1. foundational elements and processes,
2. methods and methodologies,
3. experimentation and execution,
4. systems engineering fundamentals,
5. and M&S in systems engineering case studies.
Part I
Fundamentals of Modeling and Simulation

 Part 1 introduces:
 foundational elements and processes that serve as the
groundwork for understanding M&S.
 Chapter 1 provides:
 a brief introduction to M&S, and defines concepts such as
model, simulation, and abstraction.
 Following this is a discussion of the relationship between the real
world, the model and the simulation,
Contents of chapter 1

 You will be introduced to:

 the M&S pyramid, which is a construct for describing levels of
resolution,
 as well as the term live, virtual, and constructive (LVC)
simulations, which is a way of describing how humans interact
with simulations.
 Chapter 1
Introduction to Modeling and Simulation
 Simulation is a multidisciplinary approach to solving
problems that includes:
 mathematics,
 engineering,
 physical science,
 social science,
 computing,
 medical research,
 business,
 economics,
 and so on.
History

 Simulation is not new; it dates back to the beginnings of

civilization where it was most commonly used in warfare.
 With the development of computers, simulation moved
from role-playing,
 where people represented the systems of interest, to computer-
based simulation,
 where software is developed to encode algorithms that
represent the systems of interest.
 While once referred to simply as simulation,
 today, the discipline is more often called modeling and
simulation (M&S or MODSIM),
 emphasizing the importance of first modeling the system of interest
before developing a computational representation.

 Today,
 M&S is considered a discipline of study and research on its own.
Terminology

 There are a number of definitions of:

 models, simulations, and M&S.
 The definitions published by the US Department of
Defense (DoD) in their online glossary (MSCO 2011) are
as follows:

Model is a physical, mathematical, or

otherwise logical representation of a
system, entity, phenomenon, or process.
Simulation is a method for implementing a model over
time.

M&S is the discipline that comprises the

development and/or use of models and
simulations.

Although the terms “modeling” and “simulation” are often used

as synonyms, within the discipline of M&S both are treated as
individual and equally important concepts.
Simplification and Abstraction

 The real world is too complex to be fully understood by

humans.
 To overcome this real-world complexity,
 we select from the real world those elements that form a reasonable
or adequate approximation required for the purpose at hand.
 This is accomplished through the process of simplification and
abstraction.
 Simplification is an analytical technique in which
unimportant details are removed in an effort to
define simpler relationships.
 Abstraction is an analytical technique that
establishes the essential features of a real system
and represents them in a different form.
 The resultant model should demonstrate the
behaviors of a real-world system that impact the
questions that the modeler is trying to answer.
Model – Def. and Attributes

 Model is a physical, mathematical, or otherwise logical

representation of a system, entity, phenomenon, or
process.
 A model is characterized by three essential attributes:
1) Reference,
A model has a referent, some real or imagined system.
2) Purpose,
A model should have purpose with respect to its referent;
- it is impossible to evaluate or use a model without understanding
its purpose.
3) Cost-Effectiveness.
 Simulation

 The execution of a model over time is understood as the

simulation.
 Simulation can be defined as an attempt to model a real-
life on a computer.
Why Simulations?

 Simulations are applicable in the following situations:

 When operating conditions change e.g. temperature., pressure,
etc
 When non-controllable factors change e.g. weather,
earthquake
 Other benefits: Useful in design, Increase understanding, saves
manpower and material, and new results not available before.
Simulation Types

 There are many different types of computer-based

simulations. Some of the most common approaches
include:
(1) discrete event,
(2) continuous system,
(3) agent-based,
(4) and system dynamics
(these will be described in later chapters)

 A common feature they share is:

 Generating or Predicting an artificial time history of the system
Simulation Components

 A simulation is the imitation of a process or system as it

evolves (develop/behave) over time.
 In simulation we typically focus on: objects, behavior,
interactions, environment, and time.
Simulation Components

 Objects refer to the individual components of the system

or process of interest.
 Quite often, nouns in the problem description represent
the objects in the system.
 The number of objects can vary from one to thousands,
depending on the system or process we are interested in
representing.
Simulation Components

 Objects can represent anything in the systems,

 e.g., people, vehicles, sensors, computers, and so on.

 Objects have behavior, which define their actions and

activities over time.
 the verbs represent behavior.

 Objects need to interact with each other

 An interaction is any action taken by an object.
Simulation Components

 In some types of simulations, objects need a notion of

place—where the objects are located.
 We often refer to this place as the environment
representation
(discussed in Chap. 7)
Simulation Components

 A clock is a construct that maintains and coordinates

time.
 A clock has two functions:
 it maintains a local notion of time
 and it is used to assign a time stamp to an event.
 Each simulation defines the type of clock used and
specifies how time advances in the simulation.
 Modeling time is discussed in Chap. 9.
Relationship of System, Model, and
Simulation
 A modeling process abstraction
Relationship of System, Model, and
Simulation
 The first item to tackle is the relationship between system
and model.
 In many situations, various models in the form of
differential equations already exist.
 Having a model is a necessary condition for a simulation
but other elements play a significant role.
 For example,
 most simulations need data to stimulate model inputs.
 computer architecture
 Relationship of System, Model, and
Simulation
 There are other elements must be considered in the
definition of a simulation.
 These elements directly affect performance and accuracy.

 Simulation Conceptual Definition:

Simulation = Model + Data + Method + Implementation + Realization
Simulation Conceptual Definition

 A model is a mathematical relationship that has well-

defined properties related to existence, uniqueness,
causality, etc.
 Data represent model inputs and are constrained so that
the combination of model plus data results in a unique
solution independent of method, implementation, and
realization. (Read more about data section in the text book)
 Simulation Conceptual Definition

 Method—In general, there are different numerical methods

that may be used to solve the model’s equations.
 For Ex., suppose the simulation needs to estimate the area
under a curve. Mathematically, the operation is called
integration
 There are a variety of estimation methods for this problem.
Simulation Conceptual Definition

 A simple, fast, but inaccurate method uses a series of

rectangles to sum up the area.
Simulation Conceptual Definition

 Other examples used to solve model equations include:

1. interpolation,
2. extrapolation,
3. root finding,
4. eigenvalue decomposition,
5. and matrix inversion among others.

 Many of these techniques are included in libraries.

(Task: Search at Home)
Simulation Conceptual Definition

 Realization—Model realization is the final act in the

modeling process.
 Realization includes:
1. Computing hardware,
2. Variable size (e.g., integer vs. float vs. double),
3. Coding language,
4. Operating system,
5. Run-time infrastructure,
6. and the other details involved in creating the code that realizes the
software model.

 Finally, we define a simulation run as an experiment or trial

To Be Continue,,,
Chapter 2
The Modeling and Simulation Life Cycle
Process

Margaret L. Loper

2.1 Introduction

A good way to understand modeling and simulation (M&S) is to look at the process
through which models and simulations are developed. There are different M&S life
cycles described in the literature (Sargent 1982; Kreutzer 1986; Balci and Nance
1987; Balci 2012). Despite emphasizing different aspects, most represent similar
concepts or steps. The process shown in Fig. 2.1 captures the basic ideas represented
in most processes.
In a simulation study, there is the person who has a problem that needs to be
solved (the client) and the person or group that will solve the problem by devel-
oping a simulation model (the simulation analyst). We use client and simulation
analyst in the following discussion of the process.

2.2 Steps in the Process

2.2.1 Establish Purpose and Scope

Every simulation study begins with a statement of the problem. Without an

understanding of the objectives to be addressed, it is likely the study will not be
successful (Law and Kelton 1999). If the client provides the problem statement
(i.e., the problem they want to answer with the simulation), the simulation ana-
lyst must insure that it is clearly understood. If the simulation analyst prepares the
problem statement, it is important that the client understands and agrees with the
problem formulation. A good approach is for the simulation analyst to develop a set

M. L. Loper ()
Georgia Tech Research Institute, Atlanta, GA, USA
e-mail: [email protected]

© Springer-Verlag London 2015 17

M. L. Loper (ed.), Modeling and Simulation in the Systems Engineering Life Cycle,
Simulation Foundations, Methods and Applications,
DOI 10.1007/978-1-4471-5634-5_2
18 M. L. Loper

Fig. 2.1 Modeling and simulation process. (Adapted from Benjamin 2006)

of assumptions about the real-world system associated with the problem statement,
and make sure that the client agrees with this problem definition. Even if this oc-
curs, it is possible that the problem will need to be reformulated as the simulation
study progresses, due to new information and requirements.
The simulation objectives are the questions to be answered by the simulation.
The questions could be described as different scenarios that will be investigated. The
simulation project plan is a document that includes how much time will be required,
people that will be used, hardware and software requirements if the client wants to
run the model and conduct the analysis, stages in the investigation, output at each
stage, cost of the study and billing procedures, if any. In other words, the proj-
ect plan documents how you are going to run the simulation project by itself. The
amount of detail needed in the project plan should be equivalent to the size of the
project, e.g., a large, complex simulation would need a very detailed project plan.
To illustrate how the M&S process works, we will use an example of a full-
service gas station (Birta and Arbez 2010). The station has two islands and four
service lanes, as shown in Fig. 2.2. Depending on time of day, one or two attendants
serve customers. Significant portions of the customers drive vans and light trucks,
which have larger gas tanks and take more time to fill. Drivers of passenger cars
wait longer for service behind the vans or light trucks, which leads to complaints.
The management of a full-service gas station is considering restricting the vans
and light trucks to two of the lanes to improve the flow of vehicles. They want to
use M&S to answer the question—will customer service time for passenger cars
improve by making this change?
2 The Modeling and Simulation Life Cycle Process 19

Fig. 2.2 Full service gas station. (Birta and Arbez 2010)

2.2.2 Formulate the Conceptual Model

The conceptual model is an abstraction of the real-world system under investiga-

tion. A simulation conceptual model is a living document that grows from an in-
formal description to a formal description and serves to communicate between the
diverse groups participating in the simulation’s development. It describes what is to
be represented, the assumptions limiting those representations, and other capabili-
ties (e.g., data) needed to satisfy the user’s requirements. It is commonly recom-
mended that you start with a simple model, adding detail and complexity as needed
until you reach the right representation for your problem.
An informal conceptual model may be written using natural language and con-
tain assumptions about what you are or are not representing in your model. An in-
formal model can help clients and simulation analysts understand the basic outline
of the model, from their perspectives, on how the real world is represented in the
model. A formal conceptual model is an unambiguous description of model struc-
ture. It should consist of mathematical and logical relationships describing the com-
ponents and the structure of the system. It is used as an aid to detect omissions and
inconsistencies and resolve ambiguities inherent in informal models, and used by
software developers to develop code for the computational model. Software imple-
mentation is not discussed in the formal conceptual model.
The first step in the gas station example is to simplify the problem by making
assumptions. For example, modeling the attendant’s mood or physical character-
istics is not important to answering the question of how to improve service time
for passenger cars. Therefore, only a simple representation of attendant behavior
might be needed. Similarly, assumptions about the importance of road geometry,
vehicle dynamics, or weather conditions will also need to be made. In addition to
20 M. L. Loper

these types of assumptions, behavioral information is needed to better define model

components. For example, the simplified attendant’s behavior might be represented
by three possible states: pumping gas, taking payment or idle; and vehicle dynamics
might be simplified to three characteristics: type of vehicle, size of gas tank, and the
location of the gas tank cap (left vs. right). These types of decisions are made based
on the purpose of the model and the questions the client would like the simulation
analyst to answer. The conceptual model is the place where this type of information
is documented; it is a living document and will evolve over time, as the problem is
better understood.

2.2.3 Acquire and Analyze Data

Having good data to drive a model is just as important as having sound model logic
and structure. Simulation analysts must decide what data are needed, what data are
available and whether it is pertinent, whether existing data are appropriate for the
required purpose, and how to gather the data. Even though data collection is iden-
tified as a separate step in the development process, constructing the conceptual
model occurs while data collection is taking place. In a real world simulation study,
the gathering and evaluation of input data is very time-consuming and difficult; a
significant amount of time used in the study is often consumed by this task.
Regardless of the method used to collect the data, the decision of how much to
collect is a trade-off between cost and accuracy. There are several potential sources
of data: historical records, observational data, similar systems, operator estimates,
vendor’s claims, designer estimates, and theoretical considerations. Systems differ
with regard to how much data are available to populate the system database. Data
rich refer to systems where data are abundant from prior experiments or obtained
from measurements. Data poor refer to systems where meager amounts of historical
data or low-quality data exist. In some cases, it is impossible to acquire better data
(e.g., combat), in others it is too expensive to collect (e.g., topography and vegeta-
tion of a forest).
In the gas station example, the simulation analyst will need to collect a variety
of data for the model. Some of the data will be used as input and some of it will
be used in the algorithms or equations used inside the simulation. Let us consider
traffic flow. How many vehicles will come into the gas station? Will the number be
constant or will it change with the time of day or the day of the week? What percent-
age of vehicles are passenger cars versus trucks or light vans? Data need to be col-
lected to answer all of these questions. In addition to traffic flow, we will need data
to represent the attendant’s behavior. How much time does it take for a particular
vehicle to have its gas tank filled? How long does it take for the attendant to process
a customer’s payment? Is it possible for customers to take longer in one of these
steps, maybe because they exited the vehicle to go to the restroom? The simulation
analyst can choose to gather empirical data (e.g., spend the day at the gas station
and count cars) or use probability distributions, based on real data, to represent
2 The Modeling and Simulation Life Cycle Process 21

these aspects of the model. Some of the data will be used as input and can be varied
during the simulation study (e.g., the number of cars visiting the gas station) and
some of the data may be used internal to the simulation as part of an equation and
be considered hardwired (e.g., size of the gas tank for each type of vehicle). The
data and any assumptions made during the collection process should be documented
with the conceptual model.

2.2.4 Develop Simulation Model and Program

In this step, the conceptual model is coded into a computer recognizable form,
an operational model. Translating the model into computer code and then into an
executable involves selecting the most appropriate simulation methodology (e.g.,
discrete event, continuous, agents, or system dynamics which are defined and dis-
cussed in later chapters) and an appropriate computer implementation (e.g., pro-
gramming or simulation language). Simulation analysts may choose to develop
the simulation using a programming language (e.g., C, Java, FORTRAN) or use a
simulation language (e.g., MATLAB®, Simio, NetLogo, STELLA®1). Simulation
languages are higher-level software packages than programming languages. They
are usually custom made for more specific purposes and come with additional tools
to facilitate their use. Programming languages are low-level software packages,
meaning the computer code using these languages is converted into computer code
using a compiler. Programming languages are used to write custom-made software.
For example, it will take a computer programmer a lot longer to put together an
agent-based simulation using a programming language as opposed to an agent-
based framework like NetLogo. NetLogo has many internal capabilities to facilitate
creating a simulation, whereas everything has to be developed from scratch using
a programming language. However, simulations using programming languages can
have advantages such as customization and faster execution.
There are different ways a simulation analyst might want to represent traffic
flow for the gas station, depending on the purpose of the model and questions the
client wants answered. For example, traffic can be represented in a simulation as
a queueing model, as a fluid flow model, or as cellular automata. Each of these
modeling methods has advantages and disadvantages and focus on different types
of mathematics and behavior representation. There is no single right way to select a
modeling method for a simulation, but once selected there are well-defined ways to
do the implementation. Simulation languages usually implement a selected subset
of modeling methods; so developing the simulation is about combining the appro-
priate techniques and libraries needed (e.g., discrete-event simulation languages,
such as NetLogo, all represent queueing models). However, simulation languages
may not have the specific capability required; so a simulation analyst may need to

1
MATLAB® http://www.mathworks.com/products/matlab/; Simio http://www.simio.com; Net-
Logo https://ccl.northwestern.edu/netlogo/; STELLA® http://www.iseesystems.com.
22 M. L. Loper

use a computer language to custom code the required algorithms. It is important to

recognize that the simulation implementation is closely related to the conceptual
model. In fact, the conceptual model should include enough information about the
gas station (i.e., vehicles, attendant behavior, traffic flow) that the simulation imple-
menter has all the information they need to choose the appropriate language and
modeling approaches.

2.2.5 Verify and Validate the Model and Simulation

Verification is the process of determining that a model or simulation implementa-

tion and its associated data accurately represent the developer’s conceptual descrip-
tion and specifications. It is often summarized as “Did we build the model right?”
Verification should be continuing process; the simulation analyst should not wait
until the entire model is complete to begin the verification process. Using interac-
tive tools, such as a debugger, can aid to the verification process.
Validation is process of determining the degree to which a model or simulation
and its associated data are an accurate representation of the real world. It is often
summarized as “Did we build the right model?” Can the model be substituted for
the real system for the purposes of experimentation? If there is an existing system,
an ideal way to validate the model is to compare its output to that of the existing
system. There are many methods for performing validation (Balci 1997).
As part of the verification and validation (V&V) process, the simulation analyst
will need to verify the requirements of the problem stated by the client, validate the
conceptual model, verify the design and implementation of the simulation, and then
validate the results of the simulation. In other words, even though V&V is depicted
in Fig. 2.1 as occurring halfway through the life cycle process, it actually occurs at
every step of the process.
In the gas station example, the simulation analyst will work with the manage-
ment of the gas station to verify they understand the question to be answered, the
purpose of the model, and any requirements defined by the client. In other words,
the simulation analysts should make sure that the requirements are associated with
changing the flow of vehicles with the two islands at the gas station, and not about
adding a third island. Clients and simulation analysts often use different words for
similar concepts, which can lead to a misunderstanding of requirements. Verifying
requirements ensures the client and analyst mutually understand the purpose of the
model.
When developing the conceptual model, the simulation analyst needs to examine
the assumptions, behavior, and data against the requirements of the problem. For
example, if the problem is focused on improving customer service time for pas-
senger cars by changing flow inside the gas station, then there is likely no reason to
be worried about representing weather conditions. Varying the number of vehicles
entering the gas station can easily represent the general idea of fewer cars visiting
the gas station on bad weather days. Similarly, if the conceptual model did not
2 The Modeling and Simulation Life Cycle Process 23

include the concepts of vehicles, traffic flow and attendants, there would be a real
disconnect with the requirements of the problem.
In the verification process, the analyst needs to ensure that the models have
been implemented correctly into the simulation. The question being answered in
the verification is: “are the equations being solved correctly?” In real-life projects,
sometimes an independent team is assembled to go through the software code and
examine the results to make sure the simulation is working. In complex projects,
it is not feasible to verify the code line by line. In this case, a second simulation
might be built by an independent team to verify the simulation. If the models have
been implemented correctly, the results of the two independent simulations should
match, otherwise the analyst needs to track down the cause of the discrepancy.
When verifying the design and implementation of the gas station simulation, the
simulation analyst needs to make sure that the simulation runs and does not produce
errors. If a simulation language is used for the implementation, the algorithms, for-
malisms, equations, etc. have already been verified. However, the specific use of
data and combination of the equations will still need to be tested to ensure that the
logic of the simulation works and is “bug free.” For example, if the simulation were
computing average traffic flow into the gas station, a divide by zero would cause a
“runtime error” and cause the simulation program to crash.
Once the simulation of the gas station is running, the analyst will need to validate
the results of the simulation. The simulation should be executed using the “as-is”
configuration of the traffic flow in the gas station (i.e., first come, first served in any
lane of the two islands). The simulation results for customer service time of pas-
senger cars should closely match what the service time is in real life. For example,
the number of cars entering the gas station is a function of bad weather. To validate
the model, the analyst needs to gather data on the percentage of traffic reduction
during bad weather, and making sure the model reflects this as best as possible. To
validate the simulation results does require knowing what the behavior of the real
system is and how it operates. This is part of data collection: to gather this type of
information. If the simulation results are not the same (or similar, within some error
bound) as the real gas station, then the simulation analysts and client will not be able
to trust the results of the simulation when the traffic flow (i.e., passenger cars one
island, vans and light trucks one island) is changed.

2.2.6 Design Experiments

For each scenario that is to be simulated, decisions need to be made concerning the
length of the simulation run, the number of runs (also called replications), and the
manner of initialization that is required. One approach to conducting experiments is
to vary the input data for each simulation run and observe the behavior of the sys-
tem. If there are only a few input parameters, this approach will work. However, if
the simulation has tens or hundreds of input parameters, conducting a run for each
combination of the parameters can be unmanageable. In this case, a formal process
24 M. L. Loper

called design of experiments (DoE) can be used to better define which runs are
needed. DoE is a statistical approach to experimental design (described in a later
chapter) that can help minimize the number of simulation runs needed to understand
the behavior of a system under investigation. The simulation analysts may also want
to use a technique called Monte Carlo analysis (described in a later chapter) that
relies on repeated random sampling to compute the results of the simulation.
Defining the experiments for the gas station model should be considered while
developing the conceptual model. The reason is that the simulation analyst needs to
make sure the right assumptions, behaviors, and data are collected and included in
the simulation in order to support the necessary experiments. A set of experiments
an analyst might run for the gas station management would be to vary the number
of vehicles that come into the station. This could include increasing the number of
passenger cars, light trucks, and vans separately, or increasing them in different
combinations.
To illustrate the importance of thinking through experiments during the concep-
tual model development, what would happen if you were presenting the results of
these runs to the client (i.e., gas station management), and they ask you whether
the results change if Sue is working as an attendant versus Bob? Since the behavior
of the attendant was simplified and does not include personal attributes of specific
people, the simulation cannot answer that question directly. The simulation analyst
will need to understand the difference between Sue and Bob’s performance and
how that can be included in the simulation as the service time of the attendant, and
then make changes in the simulation to include that as an input parameter and not
hardwired into the equations for the attendant. The changes needed may not be that
difficult, but it requires time and resources to change the conceptual model, col-
lect data, make the changes to the simulation, do the verification and validation,
and run the experiments again. Upon presenting the new results to the gas station
management, they ask if the results are different if there is a football game at the
stadium down the block. If the simulation does not allow traffic to be input hourly
(say it was originally implemented as a probability distributed), then more time and
resources will be needed to make the changes. Defining the sets of experiments
early in the simulation process can prevent many unnecessary hours or reworking
the simulation.

2.2.7 Execute Simulation and Analyze Output

The final runs, in which data are collected for analysis, are known as production
runs. They are used to estimate measures of performance (MOP) for the scenarios
that are being simulated. MOPs are a measure of a system’s performance expressed
as some quantifiable features, such as customer service time in the gas station. By
analyzing the MOP of the production runs, the simulation analyst determines if
additional runs are needed and if any additional scenarios need to be simulated. A
scenario is a description of the initial set of conditions and timeline of events used
2 The Modeling and Simulation Life Cycle Process 25

to evaluate the behavior of the system. For example, you may define one scenario to
look at the behavior of the gas station when the attendants are attentive to customers
(e.g., they are always standing at the gas pump so service can begin immediately
once a vehicle arrives) and when attendants are not attentive to customers (e.g., they
are inside waiting for a vehicle to arrive and take several minutes to get to the pump
to begin service).
In addition to determining if more runs are needed, analyzing the results could
indicate that the simulation needs to be modified. In this case, the simulation analyst
should go back to the beginning of the process to understand whether the modifica-
tions represent a change to the scope and purpose, or whether it is only a modifica-
tion to the simulation implementation.
Once the experiments have been defined, the simulation analyst will need to
decide how many times to run the simulation for each scenario in order to have
confidence in the results. Depending on the amount of uncertainty included in the
simulation, the analysts may want to run each experiment multiple times in order to
gain more insight into the impact of uncertainties on the overall results. For the gas
station, we may decide to run each experiment five times with the same input, and
then average the results. It is important for the analyst to examine the simulation
results and be on the lookout for outliers. Outliers are data points that are numeri-
cally distant from the rest of the data. Outliers need closer inspection to determine
why they numerically deviate from the rest of the data. Some outliers expose flaws
in the system uncovered by the simulation. In some instances, inputs can conspire
in such a way as to break the system. In such a case, the system design needs to be
reexamined and necessary modifications made. Such modifications usually make
the system more robust. Some outliers expose bugs in the simulation itself. In this
case, the simulation bugs need to be identified and fixed and the experiment rerun.
In addition to the number of runs, we may discover strange behavior in the results,
e.g., on Monday’s customer service time for passenger cars doubles. This would in-
dicate a behavior we would want to investigate further to understand if it is an error
in the simulation logic or if there is a valid reason for this behavior (e.g., everyone
waits until Monday to fill up their car for the week). There are many output analysis
techniques that can be used by a simulation analyst to help them analyze the results
(Nakayama 2006).

2.2.8 Configuration Control

A simulation package for a real-world project can be made up of thousands to mil-

lions of lines of computer code. Some computer simulation packages could be a col-
lection of several individual software packages linked together. What may seem like
a small change can lead to large excursions in the behavior of the overall simulation.
Thus, it is important to keep control of the package and its contents, known as its
“configuration.” The “configuration control” is practiced in most, if not all, real-
world projects that have a software component. Once it is decided that the simula-
26 M. L. Loper

tion works and has passed all the required tests, the configuration control manager
preserves the system in its current configuration and assigns a configuration control
number to it, so at any point in the future, it is possible to revert back to the last
saved configuration control version, in case future revisions do not work. The simu-
lation analyst must never change a parameter in the configuration-controlled ver-
sion of the program until given the authority and any changes must be documented.
Usually, the engineer develops a “working copy” until ready to incorporate and
document changes on the configuration-controlled copy. After enough changes are
made, the new configuration controlled version is created with a different configu-
ration control designation number to differentiate it from all previous releases. The
new configuration-controlled copy is typically identified by a “release” or “version”
number or date; for example, “Release 1.6” or “Version 2012_03_17” (March 17,
2012).

2.2.9 Develop Documentation

Documentation is a very important part of the simulation process. If the simulation

model is going to be used again by the same or different analysts, it may be neces-
sary to understand how the simulation model operates. Also, if the model is to be
modified, this can be greatly facilitated by adequate documentation.
It is important that all the simulation inputs are documented. All the simulation
interfaces need to be identified, and the format of all the input data, and their units
or dimensions, needs to be specified. The documentation needs to specify if an
input file is a regular text file, or in binary format. If the input file is in binary, the
documentation needs to explicitly spell out the format of the data byte by byte. If
the input file is in regular text format, documentation needs to specify the number
of columns, columns headers, how the columns are separated (comma, space, tab,
etc.), number of data points, etc.
The result of all the analysis should be reported clearly and concisely. This will
enable the client to review the final problem formulation, the alternatives that were
addressed, the criterion by which the alternative systems were compared, the results
of the experiments, and analyst recommendations, if any.
There are two types of documents we can envision for the gas station model. One
is a final report delivered to the gas station management documenting the project.
It will include a definition of the requirements and the questions being answered,
some aspects of the conceptual model that is understandable to the client, a descrip-
tion of the simulation developed, the experiments conducted, and the simulation re-
sults. The requirements for the final report will depend on the specific client, so the
simulation analyst will need to clarify how much detail the client wants. The second
type of document the simulation analyst will want to develop is a complete set of
documentation on the project itself. This will include all aspects of the conceptual
model, design and implementation of the simulation, the verification and validation
tests, and all of the data collected and analyzed. This is needed to fully understand
2 The Modeling and Simulation Life Cycle Process 27

the work that was performed and will enable the simulation analyst to look at the
simulation in the future and understand what was accomplished and if the simula-
tion can be reused for another study.

2.3 Summary

The simulation process is a framework for activities, actions, and tasks that are
required to develop a simulation. The process encourages the simulation analyst
and client to communicate at every step to ensure that the problem that needs to
be solved and the approach being used to solve the problem are clearly under-
stood by all parties. Some of the steps discussed above can be performed at the
same time, while some steps are dependent on a previous step being completed
first. Developing a simulation is an iterative process, which builds from simple to
complex, as more information is known about the real-world system that is being
investigated. This means that some steps of the process will be repeated to include
or revise information. It is important to follow each of the steps, to ensure that the
simulation has the needed characteristics and accuracy to address all of client’s
requirements.

References

Balci O (1997) Verification validation and accreditation of simulation models. In: Proceedings of
the winter simulation conference
Balci O (2012) A life cycle for modeling and simulation. Simul Trans Soc Model Simul Int
88(7):870–883
Balci O, Nance R (1987) Simulation development environments: a research prototype. J Oper Res
Soc 38(8):753–763
Benjamin P, Patki M, Mayer R (2006) Using ontologies for simulation modeling. In: Proceedings
of the winter simulation conference
Birta LG, Arbez G (2010) Modelling and simulation: exploring dynamic system behaviour.
Springer, New York
Kreutzer W (1986) System simulation—programming styles and languages. Addison Wesley, New
York
Law A, Kelton D (1999) Simulation modeling & analysis, 3rd edn. McGraw-Hill Higher Educa-
tion, Boston
Nakayama MK (2006) Output analysis for simulations. In: Proceedings of the winter simulation
conference
Sargent RG (1982) Verification and validation of simulation models. In: Cellier FE (ed) Progress
in modelling and simulation. Academic, London, pp 159–169