EXAMPLE: A TOLL PLAZA

13.4 EXAMPLE: A TOLL PLAZA

This example concerns a transportation system consisting of a toll plaza on the New Jersey Turnpike, and aims to study the queueing delays resulting from toll collection. The system under study is depicted in Figure 13.28.

The toll plaza consists of two exact change (EC) lanes, two cash receipt (CR) lanes, and one easy pass (EZP) lane. Arriving vehicles are classified into three groups as follows:

1. Fifty percent of all arriving cars go to EC lanes, and their normal service time distribution is Norm(4.81, 1.01). Recall that only the non-negative values sampled from this distribution are used by Arena (see Section 4.2).

2. Thirty percent of all arriving cars go to CR lanes, and their service time distribu- tion is 5 þ Logn(4.67, 2.26).

3. Twenty percent of all arriving cars go to EZP lanes, and their service time distribution is 1.18

Toll Booths

Incoming Cars to Toll Plaza Exact Change (EC) Lanes

Cash Receipt (CR) Lanes

EZ Pass (EZP) Lane

Figure 13.28 A toll plaza system on the New Jersey Turnpike.

Modeling Transportation Systems 333 To simplify matters, we assume that an incoming car always joins the shortest queue

in its category (EC, CR, or EZP). We further assume that no jockeying between queues takes place. That is, once a car joins a queue in front of a tollbooth, it never switches to another queue.

Traffic congestion is distinctly nonstationary, varying widely by time of day. As expected, traffic is heavier during the morning rush hour (6 A . M .–9 A . M .) and the evening rush hour (4 P . M .–7 P . M .), and tapers off during off-peak hours. Table 13.1 summarizes vehicle interarrival time distributions over each 24-hour period.

The number of operating cash receipt booths varies over time. Since such booths must be manned, and therefore are expensive to operate, one of them is closed during the off-peak hours. Only during morning and evening rush hours do all cash receipt booths remain open.

Typical performance analysis objectives for the toll plaza system address the following issues:

What would be the impact of additional traffic on car delays? Would adding another booth markedly reduce waiting times? Could some booths be closed during light traffic hours without appreciably increasing waiting times? What would be the impact of converting some cash receipt booths to exact change booths or to easy pass booths? How would waiting times be reduced if both cash receipt booths were to be kept open at all times?

Of course, additional issues may be specific to particular toll plazas under study, but in our case we wish to address the last issue in the list, using the performance metrics of average time to pass through the system and booth utilization.

An Arena model for the toll plaza system presented here is depicted in Figure 13.29. The model can be decomposed into the following segments: creation of car entities from the appropriate distributions over various time periods, dispatching a car to the appro- priate tollbooth with the shortest queue, and serving incoming cars. To this end, we use the Set construct to facilitate modeling of module sets (model components) with analogous logic (e.g., multiple tollbooths). Consequently, the number of such compon- ents would be easily modifiable. The structure of the toll plaza model will be described next in some detail, along with simulation results.

Table 13.1 Interarrival time distributions by time of day

Interarrival Time

Time Period (hours) Distribution (seconds)

12 A . M .–6 A . M .

8 þ Gamm(4.4, 4.12)

Tria(1.32, 1.57, 1.76) 9 A . M .–4 P . M .

6 A . M .–9 A . M .

2.64 þ Weib(0.82, 4.5) 4 P . M .–7 P . M .

Tria(1.32, 1.57, 1.76)

7 P . M .–12 A . M .

4.2 þ Gamm(0.87, 8.24)

334 Modeling Transportation Systems

Figure 13.29 Arena model of the toll plaza system.

13.4.1 A RRIVALS G ENERATION

Car arrivals are generated in the Create module, called Cars Arriving, whose dialog box is displayed in Figure 13.30. Here, the Time Between Arrivals section specifies time-dependent sampling distributions for car interarrival times via the expression Int_Times(k). The variable Int_Times is a vector of sampling expressions, whose specification is displayed in Figure 13.31, and k is a variable representing an index between 1 and 5 for this vector.

Note that k and Int_Times correspond to entries in Table 13.1. In order to access the requisite distribution, the variable k is set to the appropriate row index by each arriving- car entity depending on the time of day of its arrival. This assignment takes place immediately following a car creation, when the car entity enters the Assign module, called Assign Type and Modify Congestion Period, whose dialog box is displayed in Figure 13.32. The assignment of k is made in the third line of the Assignments section, which partially displays the expression (the conditions in parentheses are in seconds and an asterisk denotes multiplication):

Modeling Transportation Systems 335

Figure 13.30 Dialog box of the Create module Cars Arriving.

Figure 13.31 Dialog spreadsheet for specifying a vector of sampling distributions for time-dependent interarrivals in vector Int_Times (top) and the Expression Values dialog spreadsheet for specifying sampling expressions (bottom).

k ¼1 ðt < 6 3600 Þþ

2 ðt > ¼ 6 3600 :and:t < 9 3600 Þþ

3 ðt > ¼ 9 3600 :and:t < 16 3600 Þþ

4 ðt > ¼ 16 3600 :and:t < 19 3600 Þþ

5 ðt > ¼ 19 3600 Þ

Note that the variable t is set to the simulation clock variable Tnow in the second row of the Assignments section. Consequently, precisely one predicate (condition) is true (evaluates to 1) at any given time Tnow, and all others are false (evaluate to 0), thereby yielding the requisite row index. In addition, the first line of the Assignments section samples each car , s type number (1 ¼ exact change, 2 ¼ cash receipt, 3 ¼ EZ pass) with the requisite probability (via the Arena DISC distribution), and assigns it to the car

336 Modeling Transportation Systems

Figure 13.32 Dialog box of the Assign module Assign Type and Modify Congestion Period.

entity s Type attribute. The fourth line saves the car entity s arrival time, Tnow, in its ArrTime attribute (for future use in computing its system time).

Recall the discussion in Section 5.8 concerning the Schedule module, and note that we have a similar problem here. More specifically, changes in the interarrival time distributions in our model do not take effect at interval boundaries, but rather when the first car arrives in the new interval, and consequently will apply only to subsequent cars in this interval. If changes at interval boundaries were desired, then an alternative model would use a single entity circulating between Assign and Delay modules (one set per interval) to assign the requisite time-dependent distribution to a variable.

13.4.2 D ISPATCHING C ARS TO T OLLBOOTHS

Once the assignments are made, the car entity proceeds to the Decide module, called Which Type, whose dialog box is displayed in Figure 13.33. This module dispatches a car entity to an appropriate tollbooth, in accordance with the car , s Type attribute.

The notion of a location is implemented via the Station module (from the Advanced Transfer template panel), which may represent a single station (location) or a set of stations (multiple locations), each modeling a physical or a logical location in the model. In our case, the single EZP tollbooth is modeled by a single Station module, and the multiple EC and CR tollbooths are modeled as sets of Station modules, since the logic for each tollbooth type is analogous.

To illustrate, Figure 13.34 displays the dialog box of the Station module set repre- senting EC tollbooths. To this end, the option Set is selected in the Station Type field (as opposed to the option Station, which defines a single Station module). The modeler then specifies the set member names in the Station Set Members field with the aid of the three buttons to its right.

Modeling Transportation Systems 337

Figure 13.33 Dialog box of the Decide module Which Type.

Figure 13.34 Dialog box of the Station module set for EC tollbooths.

In the Station module dialog box, the two EC tollbooths are named EC_1 and EC_2 (in a similar vein, the two CR tollbooths are named CR_1 and CR_2 in their Station module set). The name of this Station module set is specified in the Set Name field. The Save Attribute field is used to specify the attribute name in which to store the station ID

338 Modeling Transportation Systems when an entity enters a particular member of the Station module set. This ID is just the

rank (position) of the requisite Station name in the list of the Station Set Members field. In our case, the Station module ID is assigned elsewhere to attribute Current_Booth of the incoming car entity. Saving that ID can be useful, since it can be used to index the associated resource, queue, and so on.

While tollbooths are modeled by Station modules, dispatching cars to tollbooths by type is implemented in a PickStation module (from the Advanced Transfer template panel), which allows an entity to select a particular Station module among a set of such modules, based on some prescribed condition. Accordingly, module Which Type dis- patches car entities of type 1 (EC), type 2 (CR), and type 3 (EZP), respectively, to the PickStation modules Exact Change Cars, Cash Receipt Cars, and Station module Easy Pass Station, based on their Type attribute.

Each car entity that enters its PickStation module selects a station from a set of stations (tollbooths), as illustrated in the dialog box of Figure 13.35 for EC cars (type 1). Here, the list of Station modules and queues to choose from is constructed by the modeler in the Stations section with the aid of the three buttons to its right. Each entry specifies a Station module (recall that EC_1 and EC_2 label the two EC tollbooths) and an associated queue (ECSQ_1 and ECSQ_2 label the queues in the EC tollbooths).

Figure 13.35 Dialog box of the PickStation module Exact Change Cars.

Modeling Transportation Systems 339 The selected option Minimum in the Test Condition field and the check-marked option

Number in Queue in the Selection Based On section instruct the car entity to select

a tollbooth with the shortest queue. The modeler can alternatively specify option Maximum and base tollbooth selection on other quantities, including an arbitrary expression. In case of ties, the first tollbooth satisfying the condition is selected. The Transfer Type field has been set to option Route, since it allows the modeler to specify a travel time in the Route Time and Units fields. Other Transfer Type options are Connect (an ordinary logical connection), Transport (for modeling transporters, such as trucks or forklifts), and Convey (for modeling conveyors). Transporters will be treated in a separate example in Section 13.5.

CR cars (type 2) require a different treatment of the associated PickStation module Cash Receipt Cars, whose dialog box is displayed in Figure 13.36. We again select

option Minimum in the Test Condition field. Recall, however, that unlike EC booths, one of the CR booths (say, CR_1) is closed during off-peak hours, while the other one (say, CR_2) is always open. In order to account for this fact, we select the Expression option in the Selection Based On section, and specify a separate expression for each CR tollbooth in the Stations field. Let resource CRS_1 and queue CRSQ_1 be associated with Station module CR_1, and similarly, let resource CRS_2 and queue CRSQ_2 be associated with Station module CR_2.

Finally, recall that MR(R) and NQ(Q) are the Arena functions returning the current number of resource units in resource R and the current number of entities in queue Q,

Figure 13.36 Dialog box of the PickStation module Cash Receipt Cars.

340 Modeling Transportation Systems respectively, and suppose that queue CRSQ_2 can accommodate less than 1000 cars

(otherwise, replace 1000 by a sufficiently large number, which surely exists). Now, to ensure that the expressions in the Stations section are properly defined, consider the following two cases pertaining to the expression for CR_1:

1. If tollbooth CR_1 is open, then 1 - MR(CRS_1) ¼ 0, and the expression for CR_1 evaluates to NQ(CRSQ_1). The tollbooth selection will be made based on the minimum of NQ(CRSQ_1) and NQ(CRSQ_2), as required.

2. Conversely, if tollbooth CR_1 is closed, then 1 - MR(CRS_1) ¼ 1 and NQ (CRSQ_1) ¼ 0, and the expression for CR_1 evaluates to 1000. Since this number exceeds NQ(CRSQ_2) by assumption, tollbooth CR_2 is sure to be selected, as required.

13.4.3 S ERVING C ARS AT T OLLBOOTHS

Once a car entity is sent to its respective tollbooth, it (possibly) queues up in the associated resource queue, and eventually pays the toll and leaves the toll plaza. In particular, cars departing from the Station module Exact Change Stations enter the Seize module, called Proceed to EC Booth, whose dialog box is displayed in Figure 13.37.

In the Seize module, the car entity attempts to seize the corresponding Station module , s resource (tollbooth , s server). But in order to refer to that resource, we need to specify a set of resources (servers) in the Resources field corresponding to the station (tollbooth) set. For example, for the EC tollbooths, the resources at station EC_1 and EC_2 are named ECS_1 and ECS_2, respectively, and the corresponding queues are named ECSQ_1 and ECSQ_2.

To specify these constructs, the requisite sets are created first. More specifically, to create a set of queues, the Set option is selected in the Queue Type field, and its name is

Figure 13.37 Dialog box of the Seize module Proceed to EC Booth.

Modeling Transportation Systems 341 entered in the Set Name field. Next, the Add button is used to create the requisite

resource set, by popping up the Resources dialog box displayed in Figure 13.38. Here, the Set option is first selected in the Type field, and its name is entered in the Set Name field. Next, the Specific Member option is selected in the Selection Rule field, and the attribute name Current_Booth is entered in the Set Index field (recall that the latter will hold the appropriate ID of the resource to be seized). Other selection rules include random selection and cyclical selection.

To create resource members of the EC Servers set, the modeler uses the Set module from the Basic Process template panel to pop up the dialog spreadsheet at the bottom of Figure 13.39. More specifically, the bottom dialog spreadsheet pops up first,

Figure 13.38 Dialog box of resource set EC Servers.

Figure 13.39 Dialog spreadsheet views of the Set module (bottom) and the Members dialog spreadsheet for specifying of resource set EC Servers (top).

342 Modeling Transportation Systems with each row corresponding to a distinct set. Generally, if a requisite set is not yet

created, then it can be created as a new row in the spreadsheet by double clicking on the text message Double-click here to add a new row. The new set is specified in the Name column, and its type selected in the Type column. Once the set is created and appears as

a spreadsheet row, the modeler clicks the button under the Members column and pops up the dialog box at the top of Figure 13.39. New set members are then added as rows in the top spreadsheet, similarly to set addition.

The creation of queue sets and their members is analogous, except that the Advanced Set module (from the Advanced Process template panel) is used instead of the Set module. Figure 13.40 displays the spreadsheet views of the Advanced Set module (bottom) and the members of the queue set EC Queues (top), where the attribute Current_Booth holds the ID of the corresponding tollbooth queue.

Once a car entity succeeds in seizing its respective server resource (tollbooth), it enters a Delay module in its path for the duration of the toll payment activity. For example, Figure 13.41 displays the dialog box of the Delay module for toll payment by EC cars.

Recall that one CR tollbooth (specifically, CR_1) is closed during off-peak hours. This wrinkle is implemented by using the Schedule module spreadsheet from the Basic

Figure 13.40 Dialog spreadsheet views of the Advanced Set module (bottom) and the Members dialog spreadsheet for specifying queue set EC Queues (top).

Figure 13.41 Dialog box of the Delay module Pay Exact Change.

Modeling Transportation Systems 343 Process template panel to pop up the corresponding note insertion below spreadsheet

at the top of Figure 13.42. The association of the resource CRS_1 with the schedule CRS_1 Schedule is specified in the Resource module (not shown), by selecting the Based on Schedule option in the Type column, and entering the name CRS_1 Schedule in the Schedule Name column.

On payment completion, each car entity proceeds to a corresponding Release module in its path to release the tollbooth resource (again using its Current_Booth attribute to index into the resource set). For example, Figure 13.43 displays the dialog box of the Release module for EC cars.

At this point the car entity has completed the toll paying activity, and its only remaining task in the model before being discarded at the Dispose module (called

Dispose) is to tally its own flow time in the system. To this end, every car entity enters

Figure 13.42 Dialog spreadsheet of the Schedule module (bottom) and the Durations dialog spreadsheet for server CRS_1 at tollbooth CR_1 (top).

Figure 13.43 Dialog box of the Release module Leave EC Booth.

344 Modeling Transportation Systems

Figure 13.44 Dialog box of the Record module Record Flow Times.

the Record module, called Record Flow Times, whose dialog box is displayed in Figure 13.44. Here, the Type field is set to the Time Interval option, which records the

elapsed time from the value stored in the car s attribute specified in the Attribute Name field. Since that attribute (ArrTime) was previously arranged to store the car , s arrival time at the toll plaza, the requisite flow times are indeed collected.

Note that the check box Record into Set is marked in Figure 13.44. Note further that a name is specified in the Tally Set Name field (Flow Times), and that the option selected in the Set Index field is the car entity , s Type attribute. These data arrange to record flow

times separately by car type—EC, CR, and EZP. Arena uses a set of three tally statistics to manage system flow-time collection by car type.

An overall examination of the toll plaza model in Figure 13.29 reveals considerable similarity and minor variations in the logic sequence of the three types of cars. The model uses PickStation modules for both EC and CR cars but not for EZP cars, since there is only one EZP tollbooth. Although this difference simplifies the model, it essentially limits it to a single EZP booth. There is considerable merit in making the model more general, by repeating the logic of the EC and CR paths for the EZP path. The added generality would allow the analyst to easily vary the number of EZP tollbooths, thereby increasing the experimental range of the model.

13.4.4 S IMULATION R ESULTS FOR THE T OLL P LAZA M ODEL

the simulation results are displayed in Figure 13.45. The Queue section displays delay statistics for each of the five tollbooth queues (two EC queues, two CR queues, and one EZP queue). As expected, CR queues have the longest delays, EC queues have shorter delays, and the EZP queue has a tiny delay. Note that queue CRSQ_1 has a very large maximal delay, since our model shuts down tollbooth CR_1 at the onset of the off-peak period, leaving all cars waiting there at

Modeling Transportation Systems 345

Figure 13.45 Simulation results for the toll plaza model.

the time “stranded” until the onset of the next rush hour. Of course, in a realistic model, the modeler should include logic to empty queue CRSQ_1 before closing tollbooth

CR_1. The Resource section displays server utilizations for each of the five tollbooth servers. Since tollbooth CR_1 is closed during off-peak hours but tollbooth CR_2 always remains open, the utilization of server CRS_2 is understandably higher than

346 Modeling Transportation Systems that of server CRS_1. Furthermore, since tollbooth EC_1 is preferentially selected over

tollbooth EC_2 when neither is busy (it is listed as the first destination in the corres- ponding PickStation module), server ECS_1 has a higher utilization than that of server ECS_2.

The User Specified section summarizes tally results of car flow times through the toll plaza by car type. Again, flow times of type CR are much longer than all others, mainly due to the closure of tollbooth CR_1 during off-peak hours.

Note that we are dealing here with a terminating simulation (recall Section 9.1.1), with a modest replication length of merely 24 hours. Consequently, we can expect considerable variability in statistics across replications. The reader is urged to run multiple replications (say, five) of this model and observe the resulting variability in statistics, such as waiting and flow times. This would illustrate the need for running a sufficient number of replications to achieve reliable statistics. More specifically, the grand means of statistics across replications should stabilize, that is, the modeler needs to ensure that adding more replications does not appreciably change the aforementioned grand means.

The dramatic impact of the closure of tollbooth CR_1 during off-peak hours raises a natural question: To what extent would the flow times of CR cars be improved, if tollbooth CR_1 were to remain open at all times? It is easy to modify the Arena model of the toll plaza to reflect this improved operating rule: Merely set the capacity of server resource CRS_1 to 1 at all times.

The simulation results of the improved toll plaza model are displayed in Figure

13.46. As expected, the improved toll plaza yields dramatically lower average flow time and maximal flow time for CR cars, and higher utilization of the tollbooths. The slight variations in the statistics of EC and EZP cars and tollbooths from Figure 13.45 to Figure 13.46 are simply due to randomness, since cars of distinct types do not interact in the absence of jockeying.