INSIDE DISCRETEEVENT SIMULATION SOFTWARE:

1
INSIDE DISCRETE-EVENT SIMULATION SOFTWARE HOW IT
WORKS AND WHY IT MATTERS BY Thomas J. Schriber
Daniel T. Brunner
Presented By- Sudhanshu Bhushan October 12, 2006
2
Presentation Outline

• Summary of the Paper
• -Purpose of the paper
• Terminology used in the concept.
• Entity States and Entity Management Structure.
• AutoMod- Version 9
• SLX Release 1
• Extend Version 4.1

3
Purpose of the paper

• Provides Simulation Practitioners and consumers
  with a grounding in how discrete-event simulation
  works.
• Learning and teaching only involves a black-box
  approach.
• Why it Matters

Describes the logical underpinning of
discrete-event simulation and illustrate this
material in terms of various implementations of
discrete-event simulation software.
4
Transaction Flow World View
This provides the basis for discrete-event
simulation. The system is visualized as
consisting of discrete units of traffic that move
from point to point in the system while competing
with each other for scarce resources. Nature of
Discrete-event Simulation In this kind of
simulation the state changes only at discrete
set of simulated time points so there are two or
more traffic (transaction) that are manipulated
at the same point of time which is then done
serially which raises the question of order in
which the traffic is manipulated at one time
point.
5
Terminology Used To Describe the Concept
Entity To designate the transaction. It
instigates and responds to a event. External
Entity is whose creation and movement is
explicitly arranged for the modeler. Internal
Entity are created and manipulated by the
simulation software itself. Resource It
provides some kind of service to the entities.
E.g.- Buffer Control Element Designates a
construct that supports other type of delays or
logical alternatives based on the systems state.
They are the form of switches, counters or data
values. Operation It is the step carried out
by or on a entity while it moves through the
system.
6
System In Action
Simulation project consist of a experiment. The
variation are caused due to alternatives in model
logic and/or the data. Replication is also
performed with the same model logic but different
data. Run is used to describe initilizing the
model, running it to the end condition is met.
Inside a run, the simulation clock tracks
passage of time. Clock increments after all
possible actions have been taken in a given
simulated time. So there are two phases Entity
Movement Phase (EMP) Clock Update Phase (CUP)
7
Entity States and Entity Management Structures
Active State- State in which the entity is
currently moving. Only one entity at a time is in
the active state. This is placed in a list called
the active entity list which moves non-stop until
encountering an operation that puts it into
another state. Ready State During a EMP, more
than one entity is ready to move but entities can
move one by one so the ready state is one in
which the entity is ready to enter the active
state. They are maintained in a list called
current event list (CEL). This list is received
entities from various stages. Time Delayed State
State of entities waiting for known future
simulated time to be reached so that they can
enter the ready state. They belong to the future
event list (FEL) and are arranged according to
move time (move time is the simulated time at
which entity is scheduled to move again).
Condition Delayed State These are the state
of entities delayed until some specified
condition comes about. A delay list (DL) is
maintained for the same. On satisfying the
condition they are removed automatically and
added to the CEL. Dormant State Entities
sometimes are needed to be put in some state from
which no escape will be triggered automatically.
They depend on the modelers logic to transfer
them to other states. A user managed list
maintains these entities.
8
AutoMod

• CEL is similar to conventional system except for
  the insertion in the list is first with priority
  and then FIFO.
• FEL list contains LOAD after a WAIT FOR
  statement executed in the time delayed state.
• DL contain Loads waiting to claim capacity of a
  finite capacity element (control element or a
  resource). Whenever a capacity is freed one load
  from the head of the elements DL and places it
  on the CEL.
• Condition Delay List has a WAIT UNTIL statement
  that results in polling waiting. After the CEL is
  empty the CDL is added to the CEL if the
  condition for the load was fulfilled.
• Order List implements the dormant state for
  which the Load when added to the list can be
  removed by another Load which executes a order
  action.

9
SLX- simulation Language with eXtensibility
Hierarchical Language in which built-in
primitives are at a lower level than most
simulation languages, facilitating user in
creating high level modeling tools because
definition of behavior is easy.

• CEC contains puck which is actually different
  form the active object in being that a single
  object can have more than one puck. The object
  with its puck composes the entity. Pucks from FEL
  and reactivated pucks are placed into CEC.
• FEL is like other software FEL so the CUP will
  remove multiple pucks form FEC and place them in
  CEC.
• DL contains pucks waiting for state change of
  control variables and clock value. The DL is
  ranked by order of insertion.
• User Managed waiting is a unique concept in SLX
  for dormant list. The operation of bringing the
  puck to dormant list and suspending it is done in
  2 steps. First involves removing it from the list
  and the second is to put it into a wait state.

10
EXTEND
This uses a message based architecture for
discrete event simulation i.e. Various types of
messages are used to schedule events, propel
items through the model etc. The sender and
receiver of the messages are called blocks. So
the block execution is the one that is scheduled
in this simulation.

• Block contains message passing connectors, dialog
  capability and item behavior-defining code. Model
  are constructed by selecting pre-programmed
  blocks from the Extend Block libraries.
• Time Array is used by Extend to schedule Block
  execution. For a given model, the time array
  contains exactly one element for each Block whose
  execution can potentially be scheduled. Future
  Block execution can also be scheduled with the
  Block execution.
• Next Time and Current Event Array manages the
  execution of blocks whose execution has been
  scheduled via time array. The current events
  array is used to manage the resumption of
  execution blocks whose execution has been
  temporarily suspended during BEP.
• Delay List contains the items delayed in the
  residence block waiting to be pushed into next
  block.
• User managed Lists contains list of work by
  modeler on user programmed blocks to create and
  manage lists of the modelers own design.

11
Why It Matters

• Different implementation in different simulation
  software, which would reflect differing
  implementation choices made by software
  designers.
• The modeler need to be aware of the alternative
  in effect in simulation software being used.

• Trying to re-capture a resource immediately
• Suppose a entity releases a resource and wants to
  recapture it. The modeler might not want that a
  more qualified waiting entity be the next to
  capture the resource.
• Ordering of events in 3 ways
• Coupled with the giving up of the resource is
  the immediate choosing of the next user of the
  resource, without the releasing entity having yet
  become a contender for the resource.
• The choosing of the next user of the resource is
  deferred until the releasing entity has become a
  contender.
• Neither of the above that is, without paying
  heed to other contenders, the releasing entity
  recaptures the resource immediately.
• SIMAN and Extend implement (1)
• ProModel Implements (2)
• GPSS/H and AutoMod and SLX implements (3)

12
Knowledge of Software Internals

• Simulation works in 2 modes
• Batch
• Interactive
• Interactive runs put a magnifying glass on a
  simulation model while it executes. The modeler
  can follow the active entity step by step and
  display the current and future events lists and
  the delay and user-managed lists as well as other
• aspects of the model.
• These activities yield valuable insights into
  model behavior for the modeler who knows the
  underlying concepts. Without such knowledge, the
  modeler might not take full advantage of the
  interactive tools provided by the software or,
  worse yet, might even avoid using the tools.

13
Strength of the Paper

• The paper gives a insight of how the
  discrete-event simulation software works.
• Makes a compares between different software in
  reference to how the modeler need to take care of
  the of the simulation software choice when he
  models the system.

Weakness of the Paper

• The author in description of each software
  restates the functionality of the lists because
  the naming convention changes which I think was
  not required.

14
Discussion