Running the Simulation

To run the manual simulation, we need a way to generate exponentially distributed random variates for interarrival times [the function E (3.0)] and service times [the function E (2.4)]. Rather than using our calculators to generate a random number and transform it into an exponentially distributed random variate each time one is needed for the simulation, let’s take advantage of the work we did to build the spreadsheet simulation of the ATM system in Chapter 3. In Table 3.2 of Chapter 3, we generated 25 exponentially distributed interarrival times with a mean of

3.0 minutes and 25 exponentially distributed service times with a mean of 2.4 minutes in advance of running the spreadsheet simulation. So when we need a service time or an interarrival time for our manual simulation, let’s use the values from the Service Time and Interarrival Time columns of Table 3.2 rather than computing them by hand. Note, however, that we do not need to generate all random variates in advance for our manual discrete-event simulation (that’s one of its advantages over spreadsheet simulation). We are just using Table 3.2 to make our manual simulation a little less tedious, and it will be instructive to

compare the results of the manual simulation with those produced by the spread- sheet simulation.

Notice that Table 3.2 contains a subscript i in the leftmost column. This sub-script denotes the customer entity number as opposed to the simulation time step. We wanted to point this out to avoid any confusion because of the different uses of the subscript. In fact, you can ignore the subscript in Table 3.2 as you pick val- ues from the Service Time and Interarrival Time columns.

A discrete-event simulation logic diagram for the ATM system is shown in Figure 4.5 to help us carry out the manual simulation. Table 4.1 presents the re-sults of the manual simulation after processing 12 events using the simulation logic diagram presented in Figure 4.5. The table tracks the creation and schedul-ing of events on the event calendar as well as how the state of the system changes and how the values of the statistical accumulators change as events are processed from the event calendar. Although Table 4.1 is completely filled in, it was initially blank until the instructions presented in the simulation logic diagram were exe- cuted. As you work through the simulation logic diagram, you should process the information in Table 4.1 from the first row down to the last row, one row at a time (completely filling in a row before going down to the next row). A dash (—) in a cell in Table 4.1 signifies that the simulation logic diagram does not require you to update that particular cell at the current simulation time step. An arrow (↑) in a cell in the table also signifies that the simulation logic diagram does not require you to update that cell at the current time step. However, the arrows serve as a re- minder to look up one or more rows above your current position in the table to de- termine the state of the ATM system. Arrows appear under the Number of Entities in Queue, NQi column, and ATM Statusi column. The only exception to the use of dashes or arrows is that we keep a running total in the two Cumulative sub- columns in the table for each time step. Let’s get the manual simulation started.

i = 0, t₀ = 0. As shown in Figure 4.5, the first block after the start position indicates that the model is initialized to its starting conditions. The

simulation time step begins at i = 0. The initial value of the simulation clock is zero, t0 = 0. The system state variables are set to ATM Status₀ =

“Idle”; Number of Entities in Queue, NQ₀ = 0; and the Entity Attribute Array is cleared. This reflects the initial conditions of no customer entities in the queue and an idle ATM. The statistical accumulator Total Processed is set to zero. There are two different Cumulative variables in Table 4.1: one to accumulate the time in queue values of ti − Arrival Time, and the other to accumulate the values of the time-weighted number of entities in the queue, (ti − ti −1)NQi −1 . Recall that ti − Arrival Time is the amount of time that entities, which gained access to the ATM, waited in queue. Both Cumulative variables (ti − Arrival Time) and (t_i − ti −1)NQi −1 are initialized to zero.

Next, an initial arrival event and termination event are scheduled and placed under the Scheduled Future Events column. The listing of an event is formatted as “(Entity Number, Event, and Event Time)”. Entity Number denotes the customer number that the event pertains to (such as the first, second, or third customer). Event is the type of event: a customer arrives, a

i = i + 1

i = 0

Initialize variables and schedule initial arrival event and termination event (Scheduled Future Events).

i = i + 1

• Update Event Calendar: Insert Scheduled Future Events in chronological order.

• Advance Clock, t_i, to the Time of the first event on the calendar and process the event.

i = i + 1

• Store current customer entity’s Arrival Time in last position of Entity Attribute Array to reflect customer joining the queue.

• Add 1 to NQ_i, Number of Entities in Queue.

• Update Entity Attribute Array by deleting departed customer entity from first position in the array and shifting waiting customers up.

• Subtract 1 from NQ_i, Number of Entities in Queue.

• Schedule departure event for customer entity entering the ATM to occur at time t_i + E(2.4).

Discrete-event simulation logic diagram for ATM system.

Schedule arrival event Arrival Time in first position of Entity Attribute Array.

Event Calendar Processed Event System State Statistical Accumulators Scheduled Future Events

i

(Entity Number, Event, Time) Clock, ti Entity Number Event

Entity Attribute Array (Entity Number, Arrival

Time)

Number of Entities in Queue ATM Statusi

Entities Processed

*Entity Using ATM, array position 1 ———

Entities Waiting in Queue, array positions 2, 3, . . . Total Processed Time in Queue, ti – Arrival Time Cumulative,(ti – Arrival Time) (ti − ti−1)NQi−1 Cumulative,(ti − ti−1)NQi−1

0 — 0 — — *( )

Using ProModel, Second Edition

nt Companies,

84 Part I Study Chapters

customer departs, or the simulation ends. Time is the future time that the event is to occur. The event “(1, Arrive, 2.18)” under the Scheduled Future Events column prescribes that the first customer entity is scheduled to arrive at time 2.18 minutes. The arrival time was generated using the equation t0 + E (3.0). To obtain the value returned from the function E (3), we went to Table 3.2, read the first random variate from the Interarrival Time column (a value of 2.18 minutes), and added it to the current value of the simulation clock, t0 = 0. The simulation is to be terminated after 22 minutes. Note the

“( , End, 22.00)” under the Scheduled Future Events column. For the termination event, no value is assigned to Entity Number because it is not relevant.

i = 1, t₁ = 2.18. After the initialization step, the list of scheduled future events is added to the event calendar in chronological order in preparation for the next simulation time step i = 1. The simulation clock is fast forwarded to the time that the next event is scheduled to occur, which is t1

= 2.18

(the arrival time of the first customer to the ATM queue), and then the event is processed. Following the simulation logic diagram, arrival events are processed by first scheduling the future arrival event for the next customer entity using the equation t1 + E (3.0) = 2.18 + 5.73 = 7.91 minutes.

Note the value of 5.73 returned by the function E (3.0) is the second random variate listed under the Interarrival Time column of Table 3.2. This future event is placed under the Scheduled Future Events column in Table 4.1 as “(2, Arrive, 7.91)”. Checking the status of the ATM from the previous simulation time step reveals that the ATM is idle (ATM Status0 =

“Idle”). Therefore, the arriving customer entity immediately flows through the queue to the ATM to conduct its transaction. The future departure event of this entity from the ATM is scheduled using the equation t1 + E (2.4) = 2.18 + 0.10 = 2.28 minutes. See “(1, Depart, 2.28)” under the Scheduled Future Events column, denoting that the first customer entity is scheduled to depart the ATM at time 2.28 minutes. Note that the value of 0.10 returned by the function E (2.4) is the first random variate listed under the Service Time column of Table 3.2. The arriving customer entity’s arrival time is then stored in the first position of the Entity Attribute Array to signify that it is being served by the ATM. The ATM Status1 is set to “Busy,” and the statistical accumulators for Entities Processed through Queue are updated.

Add 1 to Total Processed and since this entity entered the queue and immediately advanced to the idle ATM for processing, record zero minutes in the Time in Queue, t1 − Arrival Time, subcolumn and update this statistic’s cumulative value. The statistical accumulators for Time-Weighted Number of Entities in the Queue are updated next. Record zero for

(t1 − t0)NQ₀ since there were no entities in queue during the previous time step, NQ0 = 0, and update this statistic’s cumulative value. Note the arrow “↑” entered under the Number of Entities in Queue, NQ₁ column.

Recall that the arrow is placed there to signify that the number of entities waiting

in the queue has not changed from its previous value.

i = 2, t2 = 2.28. Following the loop back around to the top of the simulation logic diagram, we place the two new future events onto the event calendar in chronological order in preparation for the next simulation time step

i = 2. The simulation clock is fast forwarded to t₂ = 2.28, and the departure event for the first customer entity arriving to the system is processed. Given that there are no customers in the queue from the previous time step, NQ₁ = 0 (follow the arrows up to get this value), we simply remove the departed customer from the first position of the Entity Attribute Array and change the status of the ATM to idle, ATM Status2 = “Idle”.

The statistical accumulators do not require updating because there are no customer entities waiting in the queue or leaving the queue. The dashes (—) entered under the statistical accumulator columns indicate that updates are not required. No new future events are scheduled.

As before, we follow the loop back to the top of the simulation logic diagram, and place any new events, of which there are none at the end of time step i = 2, onto the event calendar in chronological order in preparation for the next simula- tion time step i = 3. The simulation clock is fast forwarded to t3 = 7.91, and the arrival of the second customer entity to the ATM queue is processed. Complete the processing of this event and continue the manual simulation until the termination event “( , End, 22.00)” reaches the top of the event calendar.

As you work through the simulation logic diagram to complete the manual simulation, you will see that the fourth customer arriving to the system requires that you use logic from a different path in the diagram. When the fourth

Further, the Time-Weighted Number of Entities in the Queue statistical accumulators are updated by first computing (t6 − t5)NQ₅ = (15.17 − 15.00)0

= 0 and then recording the result. Next, this statistic’s cumulative value is updated. Customers 5, 6, and 7 also arrive to the system finding the ATM busy and therefore take their place in the queue to wait for the ATM.

The fourth customer waited a total of 3.08 minutes in the queue (see the fourth customer arrived to the queue, and that the value is stored in the Entity Attribute Array.

At time t12 = 22.00 minutes the simulation terminates and tallies the final values for the statistical accumulators, indicating that a total of five customer

entities were processed through the queue. The total amount of time that these five

customers waited in the queue is 7.84 minutes. The final cumulative value for Time-Weighted Number of Entities in the Queue is 13.21 minutes. Note that at the end of the simulation, two customers are in the queue (customers 6 and 7) and one is at the ATM (customer 5). A few quick observations are worth considering before we discuss how the accumulated values are used to calculate summary sta- tistics for a simulation output report.

This simple and brief (while tedious) manual simulation is relatively easy to follow. But imagine a system with dozens of processes and dozens of factors in-fluencing behavior such as downtimes, mixed routings, resource contention, and others. You can see how essential computers are for performing a simulation of any magnitude. Computers have no difficulty tracking the many relationships and updating the numerous statistics that are present in most simulations.

Equally as important, computers are not error prone and can perform millions of instructions per second with absolute accuracy. We also want to point out that the simulation logic diagram (Figure 4.5) and Table 4.1 were designed to convey the essence of what happens inside a discrete-event simulation program.

When you view a trace report of a ProModel simulation in Lab Chapter 8 you will see the simularities between the trace report and Table 4.1. Although the basic process presented is sound, its efficiency could be improved. For example, there is no need to keep both a “scheduled future events” list and an “event calendar.” Instead, future events are inserted directly onto the event calendar as they are created. We sepa- rated them to facilitate our describing the flow of information in the discrete-event framework.