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](../../../ikr/simlib/doc-files/IKRSimLib_Events.svg)
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.