Course Outline

• Introducing the Concepts

• Time Handling Mechanisms
• Discrete Event Simulation (DES)
• General Principles
• DES Case Study in SIMAN/Arena
• Continuous-Time Simulation
• DAE Solvers
• Random Numbers
• Usage, Generation, Validation, Pitfalls
• Queuing Systems

• Other Topics:
• Mixed-Signal Simulation
• Finite Element Modeling and Multi-physics
What is a system?
• System: set of objects, joined to accomplish some purpose.

• Entity: object of interest in the system.

• Process/Activity: predefined set of actions
in a specified time period.
• Resource: system element that provides
service to the entities.
• State of system: collection of variables that
describes the system at any time.
• Event: Instantaneous occurrence that may
be associated with change of system state.
• System Environment: region outside the
system that influences system behavior.
World Views
• A world view is the modeling framework that a modeler uses to represent a system and its
behavior.

1. Event-scheduling (a.k.a. Transaction Flow)

• We view the simulation as a sequence of events scheduled according to their event time.
• The simulation is proceeded by a sequence of snap-shots of the system.
• Each snap-shot is triggered by a event from the event list.

2. Process-interaction
• The simulation is considered as a collection of interactions among processes.
• It is similar to the object-oriented programming paradigm.
• Processes interact with each other by messages.
• Intuitive appeal: analyst can describe the process flow in terms of high-level blocks, while the
interaction between processes is handled automatically.
• Usually, many processes are simultaneously active
• Quite complex interaction
World Views (cont.)
3. Activity scanning
• With activity-scanning approach, a modeler concentrates on the activities of a model and those
conditions that allow an activity to begin.
• Simulation runs in fixed time increments
• At each clock advance, conditions are checked, and if met, the activity can begin
• Repeated scanning for activity conditions
• slows down the computer simulation

4. Hybrid activity-scanning/event-scheduling approach

• Two types of activities:
• B activities
• Primary events and unconditional activities
• Can be scheduled in advance
• C activities
• Conditional events or activities
• Cannot be scheduled in advance: depend on conditions being true
• Scan for them at the end of a time advance
The Transaction-Flow World View
• The “transaction-flow world view” often provides the basis for
discrete-event simulation.

• In this view, a system consists of discrete units of traffic that

compete with each other for the use of limited resources while
moving (“flowing”) from point to point in the system.

• The units of traffic are sometimes called “transactions,” giving rise to

the phrase “transaction flow.”

• Numerous systems fit the preceding description.

• Included are many manufacturing, health care, transportation, civil,
communication, defense and information processing systems, and
queuing systems in general.
More Terminology
• Entity: unit of traffic or a transaction
• Instigates and responds to events
• External entities: creation and movement are explicitly arranged by the
modeler.
• Internal entities: creation and manipulation are implicitly arranged by the
simulation engine itself.

• Event: instantaneous occurrence that may be associated with change

of system state

• Resource: a system element that provides service to the entities.

• Usually capacity limited
• Entities compete for their use and sometimes must wait to use them
experiencing delay as a result.
More Terminology

• Control Element: a construct that supports other types of delay or logical

alternatives based on the system state.
• Examples are switches, counters, user and system data values.

• Process Operation: a step carried out by or on an entity while it moves in

the system.
Model Execution
• Experiments:
• Differentiated by the use of alternatives in a model’s logic or data

• Replications (trials):
• Same model’s logic or data for a certain experiment.
• Differentiated by the use of a certain set of values for random variables.
• Statistical results can be analyzed for a set of such replications.

• Run:
• A replication consists of: initialization, run, results reporting.

• Clock:
• Internally managed and stored data value
• Tracks the passage of “simulated” time as opposed to real time.
• Advances automatically in discrete, typically unequal steps.
Model Execution (cont.)
• Execution of a run:

• Clock Update Phase (CUP)

Phase A • Advance the simulated clock until a modeler-specified run-ending
condition is met.
• Move entities with the same smallest move time from Future Event
List (FEL) to Current Event List (CEL).

• Entity Movement Phase (EMP)

Phase B • Change state of entities on CEL to active state one by one (B-type) .
• Check conditions that trigger entities on the delay and user lists.
Activate any C-type activity for which the conditions were met.
Phase C
Model Execution (cont.):
Entity States
• Active State
• The state of the currently moving (under processing) entity.
• There can be only one entity in the active state at any time.
• This entity progresses through all its operations until it encounters some type of delay and then changes state.
• Ready State
• The state of other entities waiting to enter the active state during the current EMP.
• Time-Delayed State
• The state of entities waiting for known future simulated time to enter the ready state.
• Condition-Delayed State
• The state of entities waiting for a specified condition to become true to enter the ready state.
• Dormant State
• A state from which there is no “automatic” escape by model condition changes.
• Relies on modeler supplied logic to transfer them to the ready state.
Model Execution (cont.):
Entity Management Structures
• The Active Entity
• Single-entity list.
• Moves non-stop until it encounters an operation that puts it onto another list or removes it
from the model.
• A ready-state entity becomes the next active entity.
• Eventually there is nothing to do at the current time
• EMP ends and CUP begins.

• Current Events List (CEL)

• Ready-state entities are kept on the CEL.
• Entities migrate to CEL from FEL, delays lists or user-managed lists.
• Uses a FIFO service mechanism or orders entities according to their priority attribute.
Model Execution (cont.):
Entity Management Structures
• Future Events List (FEL)
• Holds entities in the time-delayed state.
• Ranked by increasing entity move time (simulated time an entity is scheduled to move at).
• Move time is calculated
• At the time an entity is inserted on the FEL.
• By adding current simulation clock value to the known duration of the time-based delay.
• After EMP, CUP advances simulation clock to the time of the highest ranked (smallest move
time) entity on FEL.
• CUP moves this entity and all others that match its move time from the FEL to the CEL.
• Typically holds both external and internal entities.
Model Execution (cont.):
Entity Management Structures
• Delay Lists
• Holds entities in the condition-delayed state.
• These entities are waiting for a condition to occur to move to the ready state.
• Generally, created automatically by the simulation engine itself.
• Related waiting:
• Prevalent approach to manage conditional delay.
• If a delay can be easily related to model events.
• E.g., an entity waiting on a busy resource.
• Polled waiting:
• Delay condition is too complex to be related to model events that might resolve it.
• EMP checks routinely to see if entities in the delay list can be moved to CEL.
• E.g., complex Boolean combinations of state changes.
• Slows down the simulation.

• User-Managed Lists
• Holds entities in the dormant state.
• The modeler must establish such lists and supply the logic to transfer entities to and from the lists.
Model Execution (cont.)
• Execution of a run revisited:

• Clock Update Phase (CUP)

Phase A • Advance the simulated clock until a modeler-specified run-ending
condition is met.
• Move entities with the same smallest move time from Future Event
List (FEL) to Current Event List (CEL).

• Entity Movement Phase (EMP)

Phase B • Change state of entities on CEL to active state one by one (B-type) .
• Check conditions that trigger entities on the delay and user lists.
Activate any C-type activity for which the conditions were met.
Phase C
Discrete-Time Simulation
• Examples include:
• Logic-level simulators: including Switch-level and Gate-level simulators, network and protocol
simulators.
• Multiple-state simulators
• Functinal and behavioral simulators

• Replace the analog waveforms of DAE-solver simulators with the three or more values: 0, 1, and X
(undefined).
• E.g., In simulating digital designs, circuit elements are modeled as simple switches or gates
connected by wires (typically zero delay).
• Provides the ability to simulate larger designs than circuit-level simulators can, at the
expense of detail.
Discrete-Time Simulation (cont.)
• Often use simple table-driven models
• The behavior of a gate can be stored in a simple truth table.
• Its output can be looked up once the inputs are known.
• Device delay can be assumed to be a single time unit, or can be calculated
from a delay model that takes the actual device geometry into account.

• Efficient multiple-state simulators, augment truth-table with terms for each

undefined or transition state in table-driven models.
Discrete-Time Case Study (1):
Switch-Level Simulators
• The switch-level model describes the logical behavior of digital systems
implemented in metal oxide semiconductor (MOS) technology.

• Transistors are modeled as simple switches with each node having a state 0, 1, or X.

• Wires are modeled as idealized, zero-delay conductors.

• A simple delay model is incorporated into the transistor model.

• For example, unit-delay in switching.
Discrete-Time Case Study (1):
Switch-Level Simulators (cont.)
• Other delay information such as transistor delays derived in a previous circuit
simulation, may be incorporated if available.

• Processing is a matter of solving simplified equations based on approximate

circuit theory.

• Timing information may be still sufficient to determine overall system parameters

• such as worst-case delays and maximum clock rates.
Discrete-Time Case Study (2):
Gate-Level Simulators
• Use the same logic values as switch-level simulators.

• Circuit elements are modeled at the gate rather than the transistor level.

• Can be used to simulate still larger designs in terms of logic values.

• They cannot easily model some common VLSI structures (for example, pass
transistors).
Discrete-Time Case Study (2):
Gate-Level Simulators (cont.)
• Take a schematic or a netlist of the circuit in terms of wires and logic gates as an
input (for example, NAND, OR, D-flip flop).

• Some delay is associated with each gate.

• Truth tables, extended to include the undefined logic value, are used to model
each gate.

• Processing is similar to that in switch-level simulators but for larger designs.

Gate-Level Simulator: Full Adder
Consider a full adder circuit, where the AND and OR gates have a delay of 2.4 ns,
while the XOR gate has a delay of 4.2 ns. Assume all wires have a 1.0 ns delay. And
at time 0, A = 0, B= 1 and c_in = 0.
Show how these signals propagate through the circuit.
Show the sequence of state changes that occur during the simulation.
Discrete-Time Case Study (3):
Behavioral-Level Simulators
• Allow the use of sophisticated data and control representations.
• Offers the highest performance but the connection to the implementation is not
always obvious.
• May use the same logic values as logic-level simulators.
• May allow more sophisticated data representations (such as integers).
• Can be thought of as the generalization of gate-level simulators, where the design
can contain user-defined gates.
Discrete-Time Case Study (3):
Behavioral-Level Simulators (cont.)
• Behaviors are often specified in a simulation language that is similar to a modern programming
language (e.g., VHDL, Verilog, SystemC, Verilog-A, VHDL-AMS, Verilog-AMS,… etc).
• Offers good performance and ease of experimentation
• Can not catch many types of low-level problems.

• Allows the inclusion of more of the design for a given amount of computation time.
• Gives the designer confidence in the correctness of the design as a whole.
• Subtle errors (e.g., race conditions) can be missed because of the lack of detail.

• Mixed-mode simulators allow different parts of the design to be simulated at different levels of
abstraction.
Behavioral-Level Simulators: ATM machine
The following table shows both the arrival and service times for
customers at an ATM machine.
Show the sequence of state changes that occur during the simulation.
Cust. Arrival Service Departure
1 0 5
2 3 7
3 4 1
4 7 3
5 9 2
Course Outline
• Introducing the Concepts
• Time Handling Mechanisms
• Discrete Event Simulation (DES)
• General Principles
• DES Case Study in SIMAN/Arena
• Continuous-Time Simulation
• DAE Solvers
• Random Numbers
• Usage, Generation, Validation, Pitfalls
• Queuing Systems

• Other Topics:
• Mixed-Signal Simulation
• Finite Element Modeling and Multi-physics
SIMAN/Arena’s Terminology
• Entity: unit of traffic or a transaction
• Instigates and responds to events
• External entities: creation and movement are explicitly arranged by the
modeler.
• Internal entities: creation and manipulation are implicitly arranged by the
simulation engine itself.

• Event: instantaneous occurrence that may be associated with change

of system state
• Can be used interchangeably with an entity.

• Resource: a system element that provides service to the entities.

• Usually capacity limited
• Entities compete for their use and sometimes must wait to use them
experiencing delay as a result.
Evolution of Discrete-Event Simulations
• By hand
• Example: Buffon needle problem in 1733.
Evolution of Discrete-Event Simulations
• Programming in general purpose languages
• FORTRAN in the 1950s and 1960s.
• Highly customizable and flexible.
• Painfully tedious and error-prone.

• Simulation languages
• GPSS, SIMSCRIPT, SLAM, SIMAN,… etc.
• Better simulation framework but still a steep learning curve.

• High-level simulators
• Operate via an intuitive GUI and dynamic animation.
• Domain specific and generally less flexible than simulation languages.
Case Study in Arena
• The Smarts directory installed with the tool provides excellent tutorials: e.g.,
Smarts07 and Smarts059.

• Emergency Room Case Study

• Entity: arriving patients.
• Resources: Triage Nurse, Admin Staff, Nurses, Doctors, Rooms/Beds, ICU
Room/Bed.
• Sequence: Entrance, Triage Station, Admission Station, Triage Station (flag=1),
Bed Station
• Critical Sequence: Entrance, Bed Station
Time/Cost in Arena
• Time spent by an entity in the system is categorized as either
• Wait time, value-added time, non-value added time, transfer time or other time.

• Wait time is the time an entity spends in any activity where the allocation is specified as Wait.
• Similarly, other types are depending on the allocation.

• By default, all time spent in a queue (such as waiting for a resource in a Process module or
waiting for other group members in a Batch module) is specified as Wait.
• All time spent using material handling from the Advanced Transfer panel (such as a conveyor or
transporter) is specified as Transfer.
Time/Cost in Arena (cont.)

• Cost for a specific type is the cost accrued by the entity while it is in that type of time.
• E.g., wait cost is accrued by an entity while it is in a wait activity or waiting in a queue. This includes the
overhead cost of keeping the entity in the system as well as the cost of continuing to hold any resources
it owns.

• E.g., Wait cost is calculated at the end of the waiting activity/period using the formula:
Wait cost =
(Entity.HoldCostRate + ResCostRateEnt) * Wait Time

where ResCostRateEnt returns the sum of the busy cost rates for all resources held.
and Entity.HoldCostRate is specified in the Entity module and is user-assignable.
Time/Cost in Arena (cont.)
• Total cost is simply the sum of the costs incurred in the five allocation categories
(Value Added, Non-Value Added, Wait, Transfer, and Other) for an entity or
process.

• Total time for an entity is calculated based on the time the entity enters the
system until when statistics are generated (TNOW – Entity.CreateTime).

• Although often the total time will correspond to the sum of the times in the five
allocation categories, in some modeling situations such as using groups, this may
not be true.
Entity Animation
• There are two ways to show entities moving through the system:

• Connector of Flowchart Animation

• provides a mechanism for viewing the entity flow along connectors, the lines
that connect modules together graphically.

• Facility-based Animation
• uses stations to represent physical locations where specific processes or
events occur, and involves animating the physical relationships as they exist in
the real system.