COP 4300/CAP 5805: Discrete Systems Modeling and Simulation

Introduction (notes: textbook - Chapter 1)

A simulation of a system is the operation of a model that is a representation of the

system (the system being that which we wish to model); e.g.,

• a telephone communication system (message traffic)

• a traffic system
• a factory
• a production line
• the economy
• a military engagement as per offensive and defensive weapons
• an airport
• an operating system's behavior

The model is amenable to manipulation that would be impossible, too expensive,

or impractical to perform on the system it portrays.

By experimenting with the operation of the model, properties of the actual system
can be inferred, providing insight and explanations for system behavior, and
predictive capabilities of system behavior under known operational parameters.

It is useful to seek to classify models. Models can be classified as scale models,

mockups, analogs, or symbolic models.

• A scale model is a physical representation of smaller size, often with only

essential details (e.g., a globe or a map or a model airplane)
• A mockup is a full scale representation, usually omitting invisible detail
(e.g., a cabin interior, a control panel)
• An analog predicts behavior of an analogous system (e.g., ripples in a
pond vs. radio waves)
• Symbolic models (the subject of interest in this course) employ abstract
representations for the system of interest. A symbolic model can be
intuitive (e.g., this is how you hit a golf ball), or logical - the course
obviously will concentrate on symbolic, logical models, particularly those
suitable for computer implementation.

Remark: the model may be a hybrid; e.g., a flight simulator (especially now) is a
mock-up driven by a symbolic model.
Symbolic, Logical Models

We can further describe a symbolic, logical model via 5 characteristics (the

characteristic that typifies computer simulation models is emphasized).

1. prescriptive/descriptive

solves the problem

shows the behavior (note: observation and
experimentation can also produce an answer)

2. discrete/continuous [usually with respect to time]

events such as processes such

arrivals and as a steel rolling mill
departures

3. probabilistic/deterministic

uses random variables

variables guarantee outcome

4. static/dynamic

fixed point in
time such as a bomb model changes with time
dispersal pattern

5. open loop/closed loop

objects arrive
and depart outputs are fed back
such as heat (to adjust temperature)
Why Use Computer Simulation?

• a computer simulation allows the study of, and, more importantly,

experimentation on a complex system that is infeasible with the real
system (e.g., almost anything having to do with living things)
• the process of developing a computer simulation model in and of itself can
crystallize understanding of the real system and what its most important
elements really are
• a computer simulation model that reasonably mimics a system under study
allows observation of the potential effects of systematic changes to
protocols, environments, or other modeling elements subject to change in
the system under consideration
• operation of the simulation model in a series of trials may provide insights
that reinforce (or call into question) analytic methodologies being
employed
• a computer simulation model allows experiments designed to determine
how a system might be expected to behave under stress, which can guide
making preparations serving to assuage the effects of such situations
• observation of interaction among elements of the simulation model may
provide critically needed insight as to why the system under study exhibits
behaviors that might be deemed unexpected otherwise (e.g., traffic on a
road can pile up or run smoothly with loads that otherwise seem
comparable).
• dynamic simulation models inherently generate "rare" situations, and
produce the "Murphy's Law" kind of situations for study, that would be
undetectable when using static analysis.
 Computer Simulation

Advantages Disadvantages

• the real system is not being • modeling is an art, not a science;

experimented on two different modelers will likely
• simulation permits testing for a produce reasonable models of a
need without having to buy (e.g., system that have some marked
building a hospital) differences
• preliminary hypotheses can be • simulation results can be easily
studied and the ones with most misinterpreted in the same
promise pursued manner as statistical data; the
• time can be accelerated to inherent random characteristics of
observe long term issues the event generation processes
• unexpected interactions resulting employed means that outlying
from model inputs can be isolated cases will occur
and examined • since good simulation modeling
• relative importance of elements is time consuming (and
modeled on system behavior can expensive), a model that does not
be ascertained fit or is insufficient may be
• operation of the model can reused to get quick results and cut
determine system characteristics costs (e.g., Jacksonville's Butler
that cause "bottlenecks" resulting Boulevard fiasco)
in undesirable system behavior • Simulation may be employed
• New system design can be when analytical approaches are
facilitated by making adjustments more reasonable (of course, this
to a model that accurately reflects works the other way also)
the existing system.
Remarks:

Those parts of a system that are best understood tend to be the ones most
effectively modeled. It is often infeasible to verifiably model some system
components when there is no comparable real system to use for model validation
purposes. This is a chicken and egg issue. The model is needed to guide
implementation of system elements, but the model can only be best guess for those
elements for which there is no real-world basis for comparison. This is why
modelers often examine analogs.

Simulation packages such as Extend seek to improve modeling consistency by

providing templates and interactive tools that help in model generation.
Moreover, they provide a range of mechanisms for obtaining interpretive data
from the model that reduce the risk of inappropriate analyses.

Software improvements, vastly increased machine performance, and increasing

complexity of human systems has made computer simulation increasingly
attractive and feasible. In fact, rather than use analytic approaches to solve
problems, analytic techniques are folded into processes within much larger and
more complex simulation models.
Terminology:

A system is an organic structure of objects united by interactions and

interdependencies that govern and influence the behavior of the system as it
accomplishes its purpose.

At any point in time, the state of the system is described by the values of the
collection of variables, the state variables, which are needed to describe the
system as it is being modeled.

• a discrete system is one whose state variables change at discrete points in

time
• a continuous system is one in which the state variables change
continuously with time
• a hybrid system is one with both discrete and continuous elements

This course will focus on discrete systems.

System Components

In modeling a system, key components of the system need to be identified. An

entity
is an object in the system that is to be incorporated into the model. A typical
entity is a server such as a bank teller. Each entity is in turn described by its
properties, each of which is represented as an
attribute
of the entity. A typical attribute of a server such as a bank teller is the average
time to process a transaction. In modeling an entity, the modeler will need to
select a subset of the possible attributes for the entity. This is an issue of
module granularity. How much detail is too much? For example, the physical
characteristics of a bank teller are probably irrelevant in a banking system
model, but the physical characteristics of a firefighter in a fire station
deployment model might not be.

System behavior occurs across a period of (simulated) time. An

activity
represents a time period of specified length during which an entity is
performing some task being modeled. The activity of a server is typically
providing service (note that the amount of time service is provided is an
attribute). For a bank teller this might be processing deposits. Generally,
waiting in line is not considered to be an activity, even though time elapses,
since time spent waiting is not within specification control.

Discrete systems are controlled by instantaneous occurrences that change the

state of the system. Such an occurrence is called an
event.
The start of service for a customer by a server is an event. The completion of
service is also an event.

The time phenomena that activities and events represent are endogenous or
exogenous. Endogenous phenomena are ones occurring within a system.
Serving a customer is an endogenous activity. The completion of service for a
customer is an endogenous event. In contrast, exogenous phenomena are ones
in the external environment that affects the system. A time delay caused by an
external activity (e.g., weather) not otherwise modeled is an exogenous
activity. The arrival of a customer in the system is an endogenous event as is
departure from the system since both are within the system as modeled. A
disaster that causes a spike in arrivals to the system is exogenous; all the
system sees are the arrival events, not what caused them. An exogenous
activity such as a labor strike; might alter the state variables used to govern
server performance (managers take over the task).
Steps in a Simulation Study
It is never emphasized enough that user involvement in model development at
all stages is highly advisable.

1. Problem formulation
This is the statement of the problem, which may require reformulation as
the simulation evolves. It should be clear, concise, and understandable by
those responsible for the system being modeled (who also must agree that
the formulation provides an accurate representation of the system).

2. Setting of objectives and overall project plan

The idea is to determine what is wanted from the simulation (which might
lead to the conclusion that simulation is not the best approach to take). If
simulation is the approach to be taken, then the scope of the model, the
alternatives captured within it and how they are to be evaluated, the size of
the study in terms of personnel and cost, and project milestones are
projected at this point

3. Model conceptualization
This is where experience and the ability to abstract the essential features of
a system become important. Some form of prototyping with iterative
refinement is usually employed, working out from a simple model to one
with enough complexity to reasonably represent the problem domain. A
common failing is to over-model parts of a system that are understood in
detail and under-model those that are not.

4. Data collection
Usually some form of data is available to facilitate construction of model
elements. The model development inevitably points to additional data
collection needs (e.g., to provide an empirical distribution of widget failure
times).

5. Model translation
Implementation in Extend

6. Verified?
Implementation appears to do what it is programmed to do (debugging via
utilization of reasonable test data, not necessarily real)

7. Validated?
Does the model accurately represent the real system when operated with
real data? This is a step that is often neglected.
8. Experimental design
What alternatives are going to be simulated? (these were pre-established to
some degree in setting simulation objectives – at this point details are
possible; e.g., a 6 lane traffic artery, because an 8 lane artery is not
feasible)

9. Production runs and analysis

Execution of the alternatives and meaningful comparison of their
outcomes.

10. More runs?

Is enough determined to report recommendations based on the simulation
work or are additional runs/experiments required?

11. Documentation and reporting

There are two kinds of documentation needed:
• Standard program documentation for maintenance purposes
• Progress documentation – this is needed because it reflects model
elements considered, when added, and why; the chronology
documents system characteristics considered (and provides
rationale for any not implemented). In the real world, a system
characteristic unimportant at present could become vital
subsequently; progress documentation points to whether such a
characteristic was considered and if so, where it fit in under model
evolution.

Reports are the deliverables of a simulation project. These include the

technical material finalized during project development (starting from the
problem formulation onward), and reports that justify to decision makers
the credibility of the simulation for guiding decision processes.

12. Implementation
Extensive use of the model to produce outcome information that can be
used by decision makers in determining a course of action to follow or to
govern a user interaction for purposes such as training.
Text Figure 1.3