• Check random number generator: i.e. comparing prespecified parameters (e.g. mean and variance) of the input probability distribution with that calculated from the random numbers generated to see if they are correctly generated.
• Visualization and animation: Through visualization of the simulation program behavior one can see whether or not the logic of the conceptual model is correctly implemented (e.g. that a job arrives before it is handled) and if there are bugs (e.g. if jobs miraculously disappear).
• Simulation language: The use of a simulation language or simulation libraries for general purpose languages not only reduces code lines and programming time, but also these lan- guages or libraries provide special features that relieve the programmer of programming these components himself and therefore also avoids possible bugs unless the simulation software contains bugs itself.
2.6
Simulation program
Though discrete-event simulation has many applications for diverse problems typical and basic features can be identified in all of them. The simulation program in any kind of discrete-time simulation not only has to keep track of the states of the system but the essence of a simulation is that the simulation program has to change the system states over time i.e. relates the state of a system (its static structure) to the state changes over time (its dynamic behavior) (Page, 1991; Pidd, 1992). In this section we will therefore first consider approaches how a computer program can handle and represent time in discrete-event simulations (Section 2.6.1) and afterwards the simulation program’s routines to relate state changes to time (Section 2.6.2).
2.6.1
Time advance in discrete-event simulation
In discrete-event simulation the computer program must keep track of the current value of simu- lation time as the simulation proceeds, moreover a mechanism to advance simulation time from one value to the next is necessary. The variable in a simulation model that provides the current value of simulation time is called simulation clock and there is generally no relationship between simulation time and the time needed to run the simulation on the computer (Law and Kelton, 1991). The two principal approaches for the advancement of the simulation clock that are dis- tinguished in literature are the time-slicing approach (or fixed-increment time advance) and the next-event approach (or variable-increment time advance) (Maisel and Gnugnoli, 1972; Law and Kelton, 1991; Pidd, 1992). Note that in both approaches, due to the discrete-event type of the simulation and in contrast to system dynamics simulation, the state changes of the simulation, resulting from discrete events, are only considered at the discrete time points of inspection and updating of the system and that the system state remains ’unchanged’14in the meanwhile.
14Note that in the time-slice approach the states of the system can actually change within a time slice, but only
2.6.1.1 Time-slice approach
Time-slicing is maybe the simplest approach to represent time and the dynamic behavior of a system in a simulation (Pidd, 1992).
The fixed increment discrete-time system simulates time advance by a method similar to the way motion is represented in a cinema film. A motion picture consists of the reel of film containing a series of still scenes which are projected on a screen at a rate of 24 frames per second. The rapidity of the projection and the correlation between successive frames deceives the eye into interpreting the whole effect as continuous motion. (Evans, 1988, p. 25)
In the time-slicing approach, the system is considered as changing in all of its aspects over time and therefore its status is updated and examined in usually fixed and equal time increments – i.e. in regular intervals – until a prescribed amount of simulation time has elapsed. Thus, for an interval (time slice) of ∆t the model is updated at time t + ∆t for the changes occurring in the interval t to t + ∆t (Maisel and Gnugnoli, 1972; Pidd, 1992).
In the time-slicing approach for time advance the determination of the length of the time slice – measured in simulation time – is critical. If the time slice is too large then some state changes of the system could be missed or actually non-simultaneous events must be handled simultaneously by employing prioritization rules, otherwise if it is too small then the model could be examined unnecessarily often, which negatively affects computer performance (Bratley et al., 1987; Pidd, 1992). These problems can be circumvented by using the more common next-event time advance approach, however, time-slicing is more appropriate for complex models where many events occur simultaneously (Maisel and Gnugnoli, 1972).
2.6.1.2 Next-event approach
In the next-event approach, in contrast to the time-slicing approach, the system is not updated and examined at predetermined fixed intervals, but the system is considered to proceed from one event to another until a prescribed sequence of events is completed or stopping conditions become true. Thereby the model is only examined and updated when it is known that an event occurs and therefore a state change is due and periods of inactivity are skipped by advancing the simulation clock from event time to event time (Maisel and Gnugnoli, 1972; Law and Kelton, 1991; Pidd, 1992). The slack periods between two events are varying in length in many systems – but need not for the applicability of the next-event time advance approach – and the simulation time is moved from one event time to the closest event time of future events (the next event) at which point the state of the system is updated. Thereby the next-event time approach has two advantages over the time-slicing approach. It avoids unnecessary and wasteful inspection of the state of a system when no changes are possible anyway and it clearly determines when events occur in the simulation – which refers to the problem of simultaneous treatment of actually non-simultaneous events during an interval of the time-slicing approach (Pidd, 1992).
2.6. Simulation program 31
2.6.2
Programming styles
Independent of the approach to advance time the program has to relate state changes of the system to simulation time. This can be done by various approaches each focusing on another building block of the dynamic behavior of a system (see Figure 2.5). The classical modeling styles differ primarily in their view of the dynamics of the system behavior (Page, 1991). Which style is appropriate depends on which of the building blocks of the dynamic behavior is perceived as the most appropriate to study the operations of the system. This interpretation can also be seen as a world-view, as it is not always the problem that determines the choice of a programming approach but also different simulation schools (different styles are prevalent in Northern America and Europe for example) or preferences for particular simulation languages (which in turn often favor particular programming styles), due to availability or prior experience, influence this choice (Page, 1991; Liebl, 1992).
Figure 2.5: Events, activities, and processes (adopted from Page, 1991, p. 22)
As illustrated in Figure 2.5 the dynamic behavior of a system can be divided into (i) events, (ii) activities, and (iii) processes (Page, 1991; Pidd, 1992; Liebl, 1992):
• Event: An event is an instant of time at which a significant state change occurs in the system. Such events can be state changes due to temporary entities entering or leaving the system, the beginning or ending of some operations, or state changes of an entity (e.g. from idle to occupied for a machine). Events can be subdivided into environmental or exogenous events that are independent of the model (e.g. a job arrival) and internal or endogenous events that are caused by other events (e.g. an event ’start job execution’ causally determines the event ’finished job execution’ for some simulation time in the future).
• Activity: An activity is a set of operations performed on some temporary entity of the system. These activities cause changes in the state of the system. Thus the operations and procedures on a temporary entity in a period of simulation time initiated by an event and terminated by another event are termed activity (events determine the time when an activity is started and finished).
• Process: A process is a group of events and activities for some certain temporary entity in chronological order of their occurrence (i.e. the life-cycle of a temporary entity in the system).
How these basic building blocks of the dynamic behavior of a system are combined and how important they are considered for the system determines which programming approach to use. The three major approaches (Page, 1991; Liebl, 1992; Pidd, 1992) (i) event scheduling, (ii) activity scanning, and (iii) process interaction are discussed in detail subsequently. These approaches embody distinctive programming style, as each requires to divide the operations of the system into different parts that ideally occupy their own program segment: event routines in case of the event scheduling approach, activities in the activity scanning approach, and processes in the process interaction approach, respectively (Page, 1991; Liebl, 1992; Pidd, 1992).
2.6.2.1 Event scheduling approach
In the event scheduling approach the dynamic behavior of the system is implemented by event routines. This programming style for simulation is used for example in the simulation language SIMSCRIPTand is more popular in the US than in Europe. The event routines are the dynamic part of the simulation program which change the attributes of the temporary and permanent entities of the system (e.g. jobs and machines). Each event routine is ideally implemented as an separate modular program segment (e.g. a function) that changes the attribute values of entities or schedules other events when called. For example the state of a machine could be set from ’idle’ to ’occupied’ in the event routine ’start processing’ and could schedule the event ’finished processing’ for some simulation time in the future. At this simulation time the event ’finished processing’ changes the occupation attribute of the machine back to ’idle’ (Liebl, 1992; Pidd, 1992).
Though time advance in event scheduling simulation could be done by time-slicing, the approach most often used is the next-event approach, which is more appropriate for this programming style. The next-event approach is implemented by simply using a future event list as simulation controlling device, where all future events are registered with the name of the event and the event time. Starting the simulation clock at time zero, at any point in simulation time the simulation is inspected, this future event list is ordered increasingly in event time by the simulation program’s main routine. The event routine of the event scheduled for this time is called, which changes the system state – in changing attributes of the entities – and/or schedules new future events. For the case of multiple events scheduled for the same simulation time prioritization rules have to be provided to determine the processing order of event routine. Processed events are deleted from the future event list, the list is reordered, and the system time is set to the event time of the earliest next event (Liebl, 1992; Pidd, 1992).
Using the event scheduling approach not only allows a clear distinction between the static struc- ture (temporary and permanent entities and their attributes) and dynamic behavior (events changing system states – i.e. entity attributes – and causing other future events) (Page, 1991), but also results in faster simulation programs opposed to the use of the activity-scanning or the process-interaction approach for systems with low complexity of the system components’ interactions, like reservation and release of work stations (Liebl, 1992).
2.6. Simulation program 33
2.6.2.2 Activity scanning approach
The activity scanning approach structures the dynamic behavior of a system and therefore the simulation program into activities that occur in the system. This approach was popular in the UK and is implemented in the simulation language CSL. Due to the subsequently mentioned deficiencies of this approach it is of minor practical relevance only. Same as for event routines in the event scheduling approach, the activities – the central concept for program structuring in this approach – of the activity scanning approach should be separated in modular program segments. These program segments, one for each activity, have to determine all the necessary conditions that have to be fulfilled for performing the particular activity. If the preconditions for an activity are met then the activity is performed and the state of the system is changed accordingly. For example to process a product on a machine it is necessary that there is a product in the queue in front of the specific machine and that the machine is idle at the simulation time when the conditions for the activity ’process product’ are controlled. The program segments representing activities are best divided into a test head, which tests if the conditions for the activity are met, and an operations part which executes the operations that are part of the activity only if the tests of the test head are passed (Liebl, 1992; Pidd, 1992).
At any simulation time (may it be advanced by the time-slicing or next-event approach) the simulation program’s main routine has to test all activities and check whether the conditions for these activities are met, and in case these tests are passed execute the activity. This highlights the importance of the correct ordering of the activities in the simulation program, which is more problematic than that of the event routines in the event-scheduling approach, as it is more difficult to correctly implement the logic of the simulated system. The necessity to scan through all possible activities for fulfillment of their conditions at each inspection of the system, which consumes more computer performance than the event-scheduling approach, and the more difficult structuring of the simulation program are the main disadvantages of the activity scanning approach compared to other approaches (Liebl, 1992).
2.6.2.3 Process interaction approach
From the discussion above it can be derived that the event-scheduling and activity scanning approach segment the whole life-cycle of an entity into its fundamental parts and implements these parts as separate program modules – events and event routines or activities and their execution conditions. The process interaction approach on the other hand deviates from this fragmentation and considers the whole life-cycle of entities instead. In the process interaction approach all the events and activities a (normally temporary) entity traverses during its life-cycle in the simulated system are combined into a process. Both, the active phases – during which state changes occur – and passive phases – during which the process waits for its reactivation – of entities are represented in these processes, which again should form separate segments of the simulation program (Page, 1991; Pidd, 1992).
The essence of the process interaction approach is closely related to object-oriented programming and actually the simulation language Simula, that follows the process interaction approach, was the first object-oriented programming language. Each class of entities (e.g. different kinds of jobs) has its own process and each entity created as a member of a particular class inherits this
process. The ’life’ of a focal entity can be traced by checking its progress through and its current position in its process. As entities entering the system during the simulation are initiated as members of their class and inherit their class’ process – as a template for their future ’life’ in the system – as many processes as entities run concurrently in the system and the number of processes fluctuates with the number of entities entering and leaving the system (Page, 1991; Pidd, 1992).
If entities interact so do their processes, activities of different processes for example can overlap and run parallel, if there are no conflicts, or only sequentially if they block each other. In the later case passive waiting times have to be modeled explicitly and active operation times implicitly through the change from one event and activity to another (Page, 1991). The main routine in a process interaction simulation program – which itself can be seen as a process – has to keep track of all running processes at any point in time, which is difficult as this number might be unknown in advance and fluctuating with the entities in the system. Each process has to be moved forward as far as possible by the main routine, which also needs functionalities to interrupt a process – unconditionally when an delay is determined in advance or conditionally when the movement of an entity through its process is halted until specific conditions in the simulation are satisfied – and to restart it again later. These additional requirements make the process interaction approach more complex and difficult to implement in a simulation program compared to the other programming styles discussed above (Pidd, 1992).
For the purpose of the process interaction approach the main routine has to maintain a record of each process which contains the reactivation time and the reactivation point of the process i.e. when and where the process of an entity has to be continued. If one considers the reactivation of a process as an event then the executive part of the simulation program can be implemented much like the future event list of the event-scheduling approach, with the distinction that it contains the next reactivation times of the processes ordered increasing in time. In contrast to event routines however the processes are not processed from their beginning and do not terminate but can be interrupted before they completed and re-activated later to further proceed from this point. For this reactivation it is necessary to save the process state – all attribute values as well as information on reactivation points of the process – before the deactivation (Page, 1991; Liebl, 1992; Pidd, 1992).