Amity University

Discrete Event Simulation

Simulation

Prof M S Prasad, AISST

This lecture note is based on Open literature and text books . It is suitable for grad /Post
grad students and should be read in conjunction with Class room discussions.

Discrete Event Simulations

Discrete Event Simulation LN – 3
Most mathematical, statistical, and input-output models represent a system's
inputs and outputs explicitly, but represent the internals of the model with
mathematical or statistical relationships.

An example is the mathematical model from physics, Force = Mass x Acceleration

based on theory. Discrete-event simulation models a detailed representation of
the actual internals.

Discrete-event models are dynamic, i.e., the passage of time plays a crucial role.
Most mathematical and statistical models are static in that they represent a system
at a fixed point in time.

System State Variables: The system state variables are the collection of all
information needed to define what is happening within the system to a sufficient
level (i.e., to attain the desired output) at a given point in time. The determination
of system state variables is a function of the purposes of the investigation, so what
may be the system state variables in one case may not be the same in another case
even though the physical system is the same.

Determining the system state variables is as much an art as a science. However,

during the modeling process, any omissions will be known easily by observation
of results also unnecessary state variables may be eliminated.

The system state variables in a discrete-event model remain constant over

intervals of time and change value only at certain well-defined points called event
times.
Continuous models have system state variables defined by differential or
difference equations giving rise to variables that may change continuously over
time.

Some models are mixed discrete-event and continuous. There are also continuous
models that are treated as discrete-event models after some reinterpretation of
system state variables, and vice versa.

Discrete Event Simulations

Entities and Attributes:

An entity represents an object that requires explicit definition.

An entity can be dynamic in that it "moves" through the system, or it can be static
in that it serves other entities.

In the bank, the customer is a dynamic entity, whereas the bank teller is a static
entity.
An entity may have attributes that pertain to that entity alone. Thus, attributes
should be considered as local values. In the example, an attribute of the entity
could be the time of arrival.
Attributes of interest in one investigation may not be of interest in another
investigation

Resources: A resource is an entity that provides service to dynamic entities. The

resource can serve one or more than one dynamic entity at the same time, i.e.,
operate as a parallel server.

A dynamic entity can request one or more units of a resource. If denied, the
requesting entity joins a queue, or takes some other action (i.e., diverted to
another resource, ejected from the system). (Other terms for queues include files,
chains, buffers, and waiting lines.) If permitted to capture the resource, the entity
remains for a time, then releases the resource. In the banks example, the teller is a
resource.
There are many possible states of the resource. Minimally, these states are idle
and busy.
But other possibilities exist including failed, blocked, or starved.

List Processing: Entities are managed by allocating them to resources that provide
service, by attaching them to event notices thereby suspending their activity into
the future, or by placing them into an ordered list. Lists are used to represent
queues.
Lists are often processed according to FIFO (first-in-first-out), but there are many
other possibilities. For example, the list could be processed by LIFO (last-in-first-
out), according to the value of an attribute, or randomly, to mention a few. An
example where the value of an attribute

Discrete Event Simulations

may be important is in SPT (shortest processing time) scheduling. In this case, the
processing time may be stored as an attribute of each entity. The entities are
ordered according to the value of that attribute with the lowest value at the head
or front of the queue.

Activities and Delays: An activity is a duration of time whose duration is known

prior to commencement of the activity. Thus, when the duration begins, its end
can be scheduled. The duration can be a constant, a random value from a
statistical distribution, the result of an equation, input from a file, or computed
based on the event state.

For example, a service time may be a constant 10 minutes for each entity; it may
be a random value from an exponential

Discrete-Event Simulation Model:

A discrete-event simulation model can be defined as one in which the state
variables change only at those discrete points in time at which events occur.
Events occur as a consequence of activity times and delays. Entities may compete
for system resources, possibly joining queues while waiting for an available
resource. Activity and delay times may "hold" entities for durations of time.

A discrete-event simulation model is conducted over time ("run") by a mechanism

that moves simulated time forward. The system state is updated at each event
along with capturing and freeing of resources that may occur at that time.

STEPS IN A SIMULATION STUDY

1. Problem formulation.
Every simulation study begins with a statement of the problem.
If the statement is provided by those that have the problem (client), the simulation
analyst must take extreme care to insure that the problem is clearly understood. If
a problem statement is prepared by the simulation analyst, it is important that the
client understand and agree with the formulation. It is suggested that a set of
assumptions be prepared by the simulation analyst and agreed to by the client.
Even with all of these precautions, it is possible that the problem will
need to be reformulated as the simulation study progresses.

Discrete Event Simulations

2. Setting of objectives and overall project plan. Another way to state this step is
"prepare a proposal." This step should be accomplished regardless of location of
the analyst and client, viz., as an external or internal consultant.

The objectives indicate the questions that are to be answered by the simulation
study. The project plan should include a statement of the various scenarios that
will be investigated. The plans for the study should be indicated in terms of time
that will be required, personnel 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 any other issues.

3. Model conceptualization. The real-world system under investigation is

abstracted by a conceptual model, a series of mathematical and logical
relationships concerning the components and the structure of the system. It is
recommended that modeling begin simply and that the model grow until a model
of appropriate complexity has been developed.

For example,
consider the model of a manufacturing and material handling system. The basic
model with the arrivals, queues and servers is constructed. Then, add the failures
and shift schedules. Next, add the material-handling capabilities. Finally, add the
special features. Constructing an unduly complex model will add to the cost of the
study and the time for its completion without increasing the quality of the output.
Maintaining client involvement will enhance the quality of the resulting model and
increase the client's confidence in its use.

4. Data collection.
Shortly after the proposal is "accepted" a schedule of data requirements should be
submitted to the client. In the best of circumstances, the client has been collecting
the kind of data needed in the format required, and can submit these data to the
simulation analyst in electronic format.

Oftentimes, the client indicates that the required data are indeed available.
However, when the data are delivered they are found to be quite different than
anticipated.

Discrete Event Simulations

For example, in the simulation of an airline-reservation system, the simulation
analyst was told "we have every bit of data that you want over the last five years."
When the study commenced, the data delivered were the average "talk time" of
the reservationist for each of the years. Individual values were needed, not
summary measures.

5. Model translation. The conceptual model constructed in Step 3 is coded into a

computer recognizable form, an operational model.

6. Verified?
Verification concerns the operational model. Is it performing properly?
Even with small textbook sized models, it is quite possible that they have
verification difficulties.
It is highly advisable that verification take place as a continuing process. It is ill
advised for the simulation analyst to wait until the entire model is complete to
begin the verification process. Also, use of an interactive run controller, or
debugger, is highly encouraged as an aid to the verification process.

7. Validated? Validation is the determination that the conceptual model is an

accurate representation of the real system. Can the model be substituted for the
real system for the purposes of experimentation? If there is an existing system, call
it the base system, then an ideal way to validate the model is to compare its
output to that of the base system. Unfortunately, there is not always a base
system. There are many methods for performing validation.

8. Experimental design. 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, as required.

9. Production runs and analysis. Production runs, and their subsequent analysis, are
used to estimate measures of performance for the scenarios that are being
simulated.
10. More runs? Based on the analysis of runs that have been completed, the
simulation analyst determines if additional runs are needed and if any additional
scenarios need to be simulated.

Discrete Event Simulations

11. Documentation and reporting. Documentation is necessary for numerous
reasons. If
the simulation model is going to be used again by the same or different analysts, it
may be necessary to understand how the simulation model operates. This will
enable confidence in the simulation model so that the client can make decisions
based on the analysis. Also, if the model is to be modified, this can be greatly
facilitated by adequate documentation.
The result of all the analysis should be reported clearly and concisely. This will
enable us to review the final 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.

12. Implementation. The report prepared in step 11 stands on its merits, and is just
additional information that is used to make a decision. If the simulation analyst
has followed all of the steps rigorously, then the likelihood of a successful
implementation is increased.

---------------------------------------------------------------------------------------------------------

Discrete Event Simulations