Event Handling
The simulation library is based on the principle of event-driven simulation. Stemming from a
model in which state transitions take place at discrete points in time (therefore discrete time
simulation), the simulated time of the original system is represented by the real-time of the
simulation so that the "idle time" between state transitions is bridged and no further processing
time is needed (see Figure).
Events during the simulation
The state transitions are described with the help of events (see
Event
).
These events have two characteristics. One is a time stamp, which defines the simulated point in time at which the event
occurred. The other is, e.g., an event type, which defines the state transition cause, a change of
system parameters, generation of subsequent events, etc. An example of an event might be the
arrival of a request at the generator or the end of service for a request in a service unit.
Events
The term "event" as used in the simulation library does not mean a single time-stamped event,
rather a summary of single events e.g., the event "end of service in phase 1". The term "event"
is used on a higher level of abstraction.
All events are derived from class
Event
, which has the following characteristics:
- An integer field defines the event type.
- An event can contain a list of embedded events which can be added using
addEmbeddedEvent().
- The function processEvent() is called by the calendar (see
Calendar
) when the event
occurs. It will first call the handleProcessEvent() functions of all embedded events
and then its own handleProcessEvent() function.
- The function cancelEvent() is called by the calendar (see
Calendar
) when the event is
cancelled. It will first call the handleCancelEvent() functions of all embedded events
and then its own handleCancelEvent() function.
- A time stamp is
not a part of Event.