Modelling passengers, buses and stops in traffic microsimulation: review and extensions

Transcription

1 JOURNAL OF ADVANCED TRANSPORTATION J. Adv. Transp. 2010; 44:72 88 Published online in Wiley InterScience ( Modelling passengers, buses and stops in traffic microsimulation: review and extensions Cristián E. Cortés 1 *, Vanessa Burgos 1 and Rodrigo Fernández 2 1 Department of Civil Engineering, Universidad de Chile, Casilla 228-3, Santiago, Chile 2 Faculty of Engineering, Universidad de Los Andes, San Carlos de Apoquindo 2200, Santiago, Chile SUMMARY In the last decade, significant research efforts and technology have been dedicated to the development of microsimulation tools for a better representation of traffic systems. As a result, several commercial packages appeared and they are used nowadays in the detailed modelling of different transportation systems and operations for specific project evaluations and local designs, mostly within the urban context. After reviewing the specialized literature, we realized that most of these microsimulation tools are oriented to the movement of cars, leaving the public transportation systems as a complement, just for a realistic representation of the transportation system as a whole, but always oriented to simulate cars. In this paper, the objective is to provide guidelines on how to incorporate the necessary entities and components for a proper simulation of public transport systems in a microsimulation environment. Thus, the different approaches to simulate transit systems at a microlevel are discussed, highlighting the necessity of including stops, passengers and transit vehicles explicitly as entities within the microsimulation environment, for modelling transfer operations, control strategies, etc. Several examples are then provided to quantify the impact of such representations, for different cases and potential simulation platforms. Copyright # 2010 John Wiley & Sons, Ltd. KEY WORDS: bus; microsimulation; passenger; station; bus stop 1. INTRODUCTION During the past years, the object oriented modelling has been used to simulate the traffic system. The traffic components can be represented as entities interacting among themselves. The main entities in a traffic network are vehicles, road segments, junctions and traffic signals, which can be modelled as agents. These agents have the ability to perceive changes in their environment and, as a result, modify their behaviour for a given objective. For example, the reaction of a driver to a given stimulus ahead can be to speed up to reduce his/her travel time. This is an old idea that had lead to the car-following models since the 1950s [1]. Nowadays, however, this idea has been translated into computer code to produce powerful microscopic traffic simulation models ( traffic microsimulators hereafter). An analysis of many of these traffic microsimulators can be found in reports of the European SMARTEST (simulation modelling applied to road transport European scheme tests) project, which analysed the characteristics of 32 traffic microsimulators [2]. Unfortunately, the efforts spent in the microsimulation of traffic operations have been oriented mainly to the movement of cars, and little interest has been devoted in developing proper tools for simulating transit system components for design purposes [3]. Recently, there has been increased interest in newer transit systems that may have promise in urban networks, relying on the recent development of technology information and real-time algorithms for transit scheduling and routing. The thrust of this article can be summarized in the following sentence taken from the introduction of *Correspondence to: Cristián E. Cortés, Department of Civil Engineering, Universidad de Chile, Casilla 228-3, Santiago, Chile. ccortes@ing.uchile.cl Copyright # 2010 John Wiley & Sons, Ltd.

2 MODELLING PASSENGERS, BUSES AND STOPS 73 the SMARTEST project: Public transport vehicles behave in a different way to other vehicles but are often not modelled in sufficient detail to reflect these differences [4]. Thus, the motivation of this research is to develop a review of the efforts for simulating transit operations at a microscopic level. As a result, firstly this article reviews how public transport is being considered in the traffic microsimulators found in the market. The use of default facilities for representing transit vehicles, ad hoc strategies, and external interfaces are then discussed. Next, we examine in some detail microsimulators developed to represent bus stop operations. Two of them were developed at the University College London Centre for Transport Studies. These were developed independently to deal with buses at either bus stops (PASSION) or traffic networks (BusSIGSIM). After that, we analyse the use of the commercial PARAMICS microsimulator to represent flexible transit systems via APIs [3], and the current development of a special module called MISTRANSIT (MIcroscopic Simulation TRANSIT) under the same PARAMICS platform to model fixed-route transit system operations in detail (bus stops, corridors, real-time strategies, etc.). In the course of this review we point out the key issues that need to be taken into account for a proper consideration of public transport vehicles in traffic microsimulation. 2. TRAFFIC MICROSIMULATION FACILITIES As mentioned in the previous section, work involving most commercial microsimulation packages has always been related to general traffic. Very few studies deal with the simulation of transit operations. In this section, we classify the transit simulation literature into three different approaches that cover most of the empirical work oriented to detailed transit system designs. First, we start with the simplest approach, that is to consider the default facilities for transit management in the commercial packages. This is of course a very restrictive scheme for managing complex simulation details, since the modeller can only use the default functions to control transit vehicles, normally bus lines with a predefined frequency and inflexible stop times for transferring passengers. The second option is what we called ad hoc strategies which goes beyond the default facilities, and allows researchers to represent more realistic operations by means of approximate techniques to overcome the deficiencies of commercial packages. In fact, they trick the package into doing transit simulation. Finally, the third alternative is definitely the most flexible option. The idea is that all routing-scheduling modules, as well as the different entities (such as passengers, stops, vehicles, etc.) are separately coded in the simulation environment through application programmer interfaces (APIs), allowing the modeller to control the different components of the transit system, leaving the simulation of the traffic operations under the control of the commercial package. The challenge is to generate a proper interaction between both simulation levels for a better representation of a real transit system, mostly for design purposes. Next, different experiences regarding the three aforementioned approaches are reviewed in detail Default facilities There exist a big number of commercial microsimulation packages available in the literature; nevertheless, only some of them model transit vehicles, and those that have such an option do not normally provide enough level of detail to account for the differences of behaviour between these particular vehicles and the rest of the traffic, as pointed out in SMARTEST [2] and Silva [5]. Buses are normally treated as longer cars that stop throughout a predetermined route and when they stop, they cause the same reaction in the following vehicle as any other vehicle stopping on the road. In reality, drivers know that buses will stop continuously and therefore they try not to follow them, and when they must do it, they are ready to pass them at the first sign of halting. In traffic microsimulators, vehicles that follow buses are in queue behind them trying not to change lane as soon as possible. This simplification produces an overestimation of the negative impacts of bus operations over the traffic. In what follows, we examine some fundamental aspects of how transit systems are incorporated into different commercial traffic microsimulation packages available in the market. We will focus the review in vehicle features, their generation and handling, as well as in modelling of bus stop operations,

3 74 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ as implemented in the following packages: AIMSUN/2 [6], CORSIM (CORridor SIMulation [7]), DRACULA (Dynamic Route Assignment Combining User Learning and microsimulation [8]), VISSIM (Verkehr In Stadten SIMulation [9]) and PARAMICS (PARAllel MICroscopic Simulation [10]). A previous review of models HUTSIM, SIGSIM and NETSIM can be found in Silva [11]. The kind of transit vehicles that can be represented in the selected traffic microsimulators are: buses, minibuses, light trains and street cars. Each type must be characterized in the same way as the rest of the traffic, i.e. with its length, terminal velocity, acceleration and braking rates, etc. In PARAMICS and VISSIM, the user must indicate in addition the capacity of the vehicle and the vehicle occupancy rate when initiating its route. Finally, the number and function of the doors only are recognized in VISSIM. These two last characteristics are used for the calculation of the dwell time at bus stops. In the five reviewed traffic microsimulators, the transit lines are defined by an ID label, the type of vehicle and its route. A route is a fixed sequence of links, nodes (or connectors in VISSIM) and bus stops. In AIMSUN/2 transit vehicles are grouped in a class that allows the definition of exclusive lanes. These vehicles are generated with equal frequency or following a given timetable for each line; in such a case, the user must define the standard deviation of the scheduled time. The bus stops can be located on the road or on a bay. Their length determines the storage capacity for the buses stopping at the same time. If vehicles do not fit, they must wait on the lanes assigned to the traffic, producing their blockage. CORSIM, DRACULA and VISSIM, on the other hand, generate the transit vehicles with a fixed frequency for each line. In DRACULA, the bus stops only can take care of one vehicle at a time. Finally in PARAMICS, the generation of transit vehicles can be carried out through a fixed frequency or a predefined schedule for each line. Buses initiate their routes at the first bus stop of the line to which they belong. The creation of a stop area in PARAMICS allows the attention of several vehicles simultaneously. The generation of vehicles using a fixed frequency would be valid only in a terminal station, because the effects of the congestion or delays produced in bus stops or intersections previous to the entry point generate a distortion that affects the flow and, therefore, they could vary the frequency. The interaction between two successive buses on links is controlled by the following and lane change models used for each package. PARAMICS allows (via API) to completely modify the car following and lane changing models according to the modeller goals. In order to give facilities to the displacement of public transport vehicles, exclusive lanes can be modelled. These lanes can be located as much as right or left side of the road. Priority at junctions is given through traffic lights actuated for buses. They work receiving the data generated by the located detectors of traffic in the links. AIMSUN/2 does not have a model to generate the passengers demand. Therefore, dwell times at stops follow a normal distribution, whose average and standard deviation must be given by the user for each line that uses the given bus stop. Consequently, one of the main deficiencies of the model is that it does not take into account the interactions between passengers and transit vehicles; thus, for example, indicators of the level of service of the system such as the passenger waiting time at bus stops cannot be obtained. CORSIM does not have a model of passenger demand; therefore the dwell time at bus stops must be defined before each simulation. This time can have a random fluctuation given by some distribution. In DRACULA the passenger demand at each bus stop is assumed to be an average hourly value. Thus, the dwell time is calculated as follows: T d ¼ a 1 ð1 p s ÞN þ a 2 p s N þ b (1) where N is the number of waiting passengers (independently of their destination), p s is the proportion of passengers using passes, a 1 is the boarding time for a cash payer, a 2 is the boarding time of pass user, and b is the time spent in opening and closing the doors of the bus. This simplified model assumes in addition no delay for alighting passengers and buses with unlimited capacity. In VISSIM the dwell time at stops can be calculated in three ways: following a normal distribution, a user defined distribution, or by explicit calculation. In the last option, the user must indicate the passenger demand by line (in passengers per hour) at each bus stop and the number of alighting passengers as a percentage of the occupancy rate of the vehicle. The model calculates the dwell time as a function of the marginal boarding and alighting times and the dead time spent when opening and

4 MODELLING PASSENGERS, BUSES AND STOPS 75 closing doors, and is able to discriminate whether the boarding and alighting operations are sequential or simultaneous. If the stop area is long enough, it can accommodate more than one vehicle stopped at the same time. In such a case, buses can pass each other to enter or to leave the bus stop. Additionally, priorities can be set on transit vehicles allowing buses to leave the bus stop bay. Finally, in PARAMICS the dwell time at stops depends on passengers demand. This only can be obtained by means of a constant arrival rate for each line. In addition, the number of alighting passenger at each stop must be defined for each line as a percentage of the occupation rate of the bus. Therefore, the dwell time of public transport vehicles at stops is calculated as: T d ¼ max P A t s 2 þ 5 ; ðp B t s þ 5Þ where P A and P B are the number of alighting and boarding passengers, respectively, and t s is the marginal boarding time. As it can be appraised, this model assumes that the marginal alighting time is half of the marginal boarding time and that the boarding and alighting operations are simultaneous. T d also can be modelled in PARAMICS through a constant value or normally distributed with an average and standard deviation given by the user Ad hoc strategies In this section we examine some examples on how researchers have tried to overcome the deficiencies of commercial software using sophisticated modelling to simulate transit systems. Some researchers have invented approximate techniques to overcome the deficiencies of commercial packages in simulating real transit systems by tricking the software. In Venglar et al. [12], for the simulation of light rail transit (LRT) using NETSIM (part of CORSIM), the network had to be modified in order to have fewer nodes and different configurations regarding the preferences in the intersections. For simulating a bus rapid transit (BRT) in Ref. [13] using VISSIM, the corridor had to be divided into shorter sections in order to model the centre-running guided bus way on an arterial street. A different vehicle type was coded for the buses as well. Another example of a BRT simulation using VISSIM can be found in Ref. [14]. The network was coded similar to the preceding case, and additional signals were coded to hold vehicles at some pre-specified locations in the network and maintain a constant headway. The control held a bus in a location if its headway to the bus ahead of it was less than the minimum time desired. Another interesting example is a simulation of the streetcar system using PARAMICS for the city of Toronto [15]. Tracks were coded on top of the existing network; stops were coded as additional nodes with virtual traffic lights affecting only streetcars. The traffic was trapped behind the streetcars during the red phase of the traffic light. In this case, the duration of the stop of the streetcar was a function of the demand. Note that in all the above cases the location of the stops has to be pre-specified. It is not clear how to simulate a system with uncertain demand occurring at any random point in the network. The struggle by the researchers and practitioners to attempt to simulate anything other than a car traffic system is cause for a careful look into the requirements for comprehensive microscopic simulation environments to be developed for the future. Finally, Chien et al. [16] found a way to generate passengers according to a Poisson or other empirical arrival distributions, using CORSIM. Despite this enhancement, the new model does not allow assigning passengers to different bus routes. This leads to the necessity of microscopic simulation of bus, passenger and traffic interactions at bus stops to understand this seemingly simple problem [17]. In the schemes discussed later in this paper, passengers are considered as new objects in the simulation with individual characteristics External interfaces Finally, we refer to the third approach based upon the use of external functions, using APIs, which allow us to model with much detail and great flexibility any type of operation the modeller wishes, depending on the possibility of the interaction between the software and the connected external components via application programming interface (API). The use of a more flexible and generic approach is product of the limitations observed and summarized in the previous points altogether with other aspects, such as: the necessary definition of (2)

5 76 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ predefined stop points (which is not realistic when modelling systems such as shared taxis, taxis, dial to ride, etc.); the impossibility to incorporate algorithms and routing-scheduling decisions in real-time; the inability to model and evaluate the performance on passengers and drivers; etc. All previous issues come from considering public transport systems as complementary components to the basic foundation of the traffic operation models, because finally the commercial simulation packages have been generated based on the operation of private cars [3,18]. Motivated by this necessity to generate a better simulation environment for flexible transit systems, Jayakrishnan et al. [18] proposed a hybrid approach of simulation (inspired by the original simulation scheme due to [19]) oriented to the microsimulation of customized transit systems of the type dial-toride (paratransist) at two levels. They define an abstract level, with a simplified network (ABSNET), and a series of data structures to control the position of vehicles and clients of the service. The microsimulation was performed more at a detailed level, connected with the abstract level via functions that are updated at each time step of the simulation, or when an event that affects the state of the system occurs (arrival of a new client, arrival of a vehicle to a shutdown, etc.). Cortés et al. [3] implemented this approach and evaluated several flexible systems combined with bus rapid transit (BRT) systems using PARAMICS for the traffic microsimulation. The simulation environments were connected via the use of APIs and its functions associated, available in the last versions of PARAMICS. Recent empirical works utilize the advantages of microsimulators to model transit signal priority (TSP) schemes. Li et al. [20] developed a heuristic that give signal priority to the buses and reduce the negative impacts to other users. Validation of this model is carried out with PARAMICS via API. TSP proposed in this work requires knowing continuously the location of buses to predict its intersection arrival time and to calculate the new signal programming. Lee et al. [21] use also PARAMICS to test another TSP strategy. This model predicts the arrival time using real-time information and selects the priority strategy between several predefined priority plans. Moreover, Kim and Rilett [22] studied a TSP algorithm with bus stops located close to intersections. The algorithm goal is to reduce negative impacts of having bus stops close to the intersections. The influence of bus stops is measured in terms of estimated arrival time of buses when reaching the next intersection. Specifically, through the uncertainty in dwell times at bus stop due to boarding and alighting passengers. This TSP algorithm was implemented in VISSIM via the interaction with an external program to control actuated signals vehicle actuated programming (VAP). In what follows, we describe two specific microsimulation approaches to study bus stop operations in detail. First of all, considering models independent of the rest of the traffic (BusSIGSIM, PASSION) and not included within any commercial package as those described above; and in a second option, using a module connected to PARAMICS via API (called MISTRANSIT) and currently ongoing. 3. MICROSIMULATION AT AND AROUND BUS STOPS As mentioned above, in this section we discuss two microsimulators developed at University College London (BusSIGSIM and PASSION), and one currently being developed by the authors at University of Chile (MISTRANSIT). BusSIGSIM is a traffic microsimulator developed for studying the interactions between buses and cars in networks [23,24]. PASSION is a microsimulator of interactions between buses, passengers and traffic at bus stops [25 27]. And finally, MISTRANSIT is a hybrid platform that allows the representation and control of fixed route transit systems connected with PARAMICS for traffic simulation details via API BusSIGSIM BusSIGSIM is based on modifications made to the microsimulator SIGSIM for a better representation of the interactions between buses and other traffic either in networks or arterial roads. Some of the features of SIGSIM, taken form Silva [23], are summarized next. SIGSIM was designed to evaluate real-time signal optimization. It was first developed to model traffic at a single junction. Afterwards, a version was developed to model networks [28]. The model continued its development as a parallel computing version. Thus, the work of Silva [23] was based on version 3.0 of parallel SIGSIM [29].

6 MODELLING PASSENGERS, BUSES AND STOPS 77 SIGSIM is a mix between fixed-time and event-based simulation built on Gipps car-following and lane-changing algorithms [30,31]. Each type of vehicle entering the network (cars, heavy and light good vehicles, buses and motorcycles) is assigned to a route (a set of consecutive one-way links connecting nodes) for which the traffic flow and traffic composition is defined. The generation of a vehicle is an event that produces an object with characteristics taken from a table of means and distributions. The kinematics of a vehicle are then updated every 2 / 3 seconds. Vehicles can be generated either at fixed or random intervals. Buses in SIGSIM have additional characteristics beyond the rest of the traffic: number of passengers on board, capacity of vehicles (88 passengers), and total boarding and alighting times at bus stops as a function of the number of passenger at bus stops. The model calculates the dwell time at a bus stop as the maximum of the total boarding or alighting time plus 4 seconds of dead time (typical characteristics of London s two-door, double-decker buses). SIGSIM assumes that during the dwell time a bus produces a temporary obstruction of the kerbside lane. In addition, The internal delay is a result of vehicular interactions, simulated by the car-following and lane changing models with no specific provision to represent bus stop operations [23] (p. 79). Passengers are produced in SIGSIM from an origin-destination matrix between bus stops; they are randomly generated from a distribution around average cells values in the matrix. In principle, all the passengers represented in SIGSIM start and end their journeys within the simulated network; however, the use of dummy bus stops outside the network can allow the user to overcome this limitation. Finally, for each passenger generated SIGSIM assigns his/her origin and destination stop and the marginal boarding time, which is taken from another distribution. In order to focus the analysis, it was decided that As BusSIGSIM is concerned with the simulation of vehicular interactions in traffic, the factors affecting the total and marginal passenger service times (PST) are not modelled further than in the original SIGSIM [23] (p. 93). An additional feature of the model with respect to bus stops is the following: In order to allow the model to work properly, users are advised to design the network in such a way that bus stops are positioned sufficiently far away from the junction boundaries, so that the relevant sight distances are entirely covered within one junction. This is a limitation in BusSIGSIM, imposed by the architecture of the parallel version of SIGSIM [23] (p. 100). As a result, of all the potential interactions between buses and traffic that take place around bus stops, BusSIGSIM considers three elements: stopping buses at bus stops, vehicles trying to overtake stopping buses and vehicles travelling in adjacent lanes. The aim was to understand how the operation of bus stops could affect general traffic. Thus, BusSIGSIM is able to calculate the lateral positions of buses operating in a wide range of stop types to replicate the real entering and leaving paths, as well as the actual gap between the stopped bus and the kerb (Figure 1). This relaxes the traditional assumption made in most traffic microsimulators in the sense that, with the exception of bus bays, a bus at a bus stop is an unavoidable obstruction for the upstream traffic. On the contrary, field observations and simulation experiments made with BusSIGSIM showed that traffic squeeze in the vicinity of a stopping bus. Tyler et al. [24] (p. 127) define this behaviour as follows: Squeeze is the use of temporary de facto lanes, narrower than the existing ones, in order to accommodate the traffic stream in the available street width and avoid stopping behind an obstacle (e.g. a stopped bus). This is shown in Figure 2. Therefore, the expected delays for cars are less than those calculated with most computational tools for traffic analysis. For example, comparing SIGSIM and BusSIGSIM outputs in a single carriageway road, Tyler et al. [24] reported an average 5.5-second/vehicle drop in car delays and an average 2.6-second/vehicle increase in bus delays. This new way of representing the behaviour near bus stops requires a modification of the carfollowing model. Details of the new behavioural model can be found in Silva [5,23]. Figure 1. Replication of a stopping bus path in BusSIGSIM.

7 78 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ Figure 2. Traffic squeezing at a bus stop as represented in BusSIGSIM PASSION The model developed for representing bus stops operations is called PASSION, for PArallel Stop SimulatION. The expression parallel in the name of the program does not mean a particular computing architecture at present. However, at the early stages of our research the complexity of the problem required a parallel design to represent all the various concurrent processes at the bus stops. Once this was understood, it was possible to represent the problem in a serial code. As a result, a PCbased microsimulator was written. Figure 3 shows the modular components of PASSION. These are a Bus Module that generates the characteristics of buses, such as route, arrival times at the bus stop, number of alighting passengers, average alighting time of passengers, spare bus capacity, and blocking times to leave the berth; a Passenger Module which generates the characteristics of the passengers, such as desired route, arrival time at the platform, and boarding time of each passenger; a Main Interaction Module that manages the relationships between the bus and the passenger modules, and considers the conditions of the bus stop design and the bus operation system; and a Performance Module, which summarizes the results of the interactions and allows the evaluation of the changes made in the inputs. Other inputs for the model are the bus stop design, which is related to the type of bus stops (e.g. on/off-line) and the bus operation system, which is related to the type of buses (e.g. one/two doors, ticketing system, boarding and alighting facilities). The model was developed as a virtual laboratory to experiment with the system under study (see Figure 4); that is a one-berth stop area, its adjacent platform, and its immediate traffic restraints. The aim is to reproduce the behaviour of the system under different cases of bus and passenger characteristics, bus stop design and bus operation. To provide flexibility to the simulation, the bus and passenger modules are able to produce any arrival pattern of buses and passengers, from constant to actual inter-arrivals (e.g. from video recordings). The outputs enabled to us the discovery of the influence of diverse factors on the performance of bus stops. This knowledge can then be used to derive rules to improve bus operations. Further details of the Figure 3. Components of the PASSION simulator.

8 MODELLING PASSENGERS, BUSES AND STOPS 79 Figure 4. The scope of the PASSION microsimulator. model can be found in Fernández [26] or Fernández and Planzer [27]. However, the two main internal models are the calculation of PST and bus stop capacity. These are described hereafter. The interactions between buses and passengers at a bus stop are represented by the PST; i.e. the time that a bus takes for boarding and alighting operations. This is calculated in PASSION with the following model. 8 ( ) Pp bi >< b o þ max b bj ; b ai p ai ; for parallel operations j¼1 PST i ¼ ( ) b o þ Pp bi >: b bj þ b ai p ai ; for sequential operations j¼1 where PST i is the passenger service time of the bus i (second), b o is the average dead time per stop (second), b bj is the marginal boarding time of passenger j (second), p bi is the boarding passengers to the bus i, b ai is the marginal alighting time from the bus i (second/pass) and p ai is the alighting passengers from the bus i. As can be seen, this model considers the possibility of parallel or sequential operations for boarding and alighting. This is because it is postulated that buses have either two doors one for boarding and one for alighting or just one door that allows passengers to alight and then board. In the model, two sources of variability in the boarding time are introduced: (a) characteristics of passengers and (b) characteristics of buses. The former can be included in the input file generating a boarding time for each arriving passenger from any given distribution (e.g. uniform). The second source of variability can be incorporated through the bus route, assuming the same type of vehicle for each route. Other ways of providing the b bj values could also be used, such as an average boarding time for all passengers. The alighting time, on the other hand, supports only one source of variation: type of bus. This is because the model does not consider individual alighting passengers, but the bulk of them. The variation in the alighting time can be done in the input file through the bus route, using the same value for each bus of the same route. As the alighting operation is simpler than the boarding one, this assumption infers that all the difficulty rests in the alighting facilities of buses. An average value for all buses can be assumed as well. Other times generated by the bus-bus and bus-traffic interactions are added to the PST to compute the occupancy time or dwell time; i.e. the total time spent by a bus at the berth. The dwell time is made of a user-defined clearance time of the berth, the PST, and an exit delay based on the state of the exit of the stop area. That is the time during which a bus, having completed its transfer operation, cannot leave the berth because of restrictions imposed by other traffic. This can be deterministic or stochastic depending on the type of phenomenon that controls the exit (e.g. a traffic signal or gaps in the adjacent lane). Once the interactions between buses, passengers, and traffic are computed the program calculates some statistics from the simulation. These are the average, maximum and standard deviation of waiting time of passengers; the mean and maximum number of passengers on the platform; the mean, maximum and standard deviation of delay to buses; the capacity and degree of saturation of the bus stop; and mean and maximum queue length of buses. (3)

9 80 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ PASSION calculates the capacity of the bus stop in the following way Q b ¼ P 1 Nb N b i¼1 t (4) c þ PST i þ t ei where Q b is the capacity of the bus stop (bus/hour), N b is the number of simulated buses, PST i is the passenger service time of the bus i (second), t ei is the exit delay for the bus i (second) and t c is the constant clearance time (second). The calculation of the capacity and other statistics indicate how busy a bus stop is and they are used to design bus stops; i.e. determining the number of stop points and queuing space required for any combination of bus flow and passenger demand. Results of the calibration and validation process at one Chilean bus stop are shown below [25]. Figure 5 shows a sketch of the site. The site was chosen in an attempt to cover the type of design and operating conditions that are enclosed in the model. A summary of the features of the bus stop is shown in Table 1. The data collection method consisted of filming the stop operations with a VHS camera. The video was then visually studied in laboratory. One set of the data was used for calibration and another for validation. Results of the calibration set of data are shown in Table 2. Parameters were obtained calibrating the model for parallel operations of Equation (3), according to local conditions. The clearance time t c was obtained as the average difference between the dwell time and the PST of each bus. The validation consisted of the application of the correlated inspection approach [32]. This requires the same set of historical system input data (i.e. actual observed inter-arrival times) to be applied to the calibrated version of the model. Two levels of validation were used. The first level consisted on comparing average outputs obtained from the model and field observations as a way of testing the overall predictive power of the model. The outputs considered are average steady-state statistics for the following variables: capacity of the bus stop and degree of saturation; mean delay to buses for passengers transfer, in queue and total; and mean queue length. Table 3 shows results of capacity, delays to buses and queues of buses at the stop and the differences with respect to field observations. As can be seen in the table, there is an overall similarity between the average system and PASSION outputs. On average, differences are within 10%. The output with more discrepancy is the delay in queue. It should be noted, however, that this means a discrepancy of less than half a second, which is irrelevant for any practical purpose. Figure 5. Santiago s calibration and validation site. Table 1. Study case for calibration and validation of PASSION. Site Pedro de Valdivia Francisco Bilbao Junction (Santiago) Period Peak evening (18:00 19:15) Stop design Single one-berth Bus flow 53 bus/hour Boarding demand 86 pass/hour Alighting demand 15 pass/hour Traffic signal 55 m upstream; cycle ¼ 120 seconds; effective green ratio ¼ 0.41

10 MODELLING PASSENGERS, BUSES AND STOPS 81 Table 2. Parameters calibrated for PASSION in Santiago. Parameters Clearance time t c (second) 7.0 Dead time b o (second) 1.0 Average boarding time b b (second/pass) 1.6 Average alighting time b a (second/pass) 1.0 Values Table 3. Average validation results at Santiago s bus stop. Output Field data PASSION Difference (%) Capacity of bus stop Mean (bus/hour) þ10 Saturation (%) Delays to buses (second/bus) Due to passenger transfer þ4 In queue Total þ1 Queues of buses (bus) Mean The next level of validation was statistical comparison of the outputs. There are several methods for comparing real-world observations and simulation output data [32]. The method used was a confidence interval and hypothesis test for the mean based on the t distribution. The hypothesis to be tested is that the mean values of the various outputs provided by the model and the actual system are not different with a given level of confidence (the null hypothesis). To that objective, the following statistic is defined: t n ¼ mðnþ m 0 p ffiffiffiffiffiffiffiffiffiffiffiffiffiffiffi (5) S 2 ðnþ=n where m 0 is the mean value of the system output, m(n) is mean value of the model output, S(n) is the standard deviation of the values of the model output and n is the number of observations. Therefore, the null hypothesis to be tested is H 0 : m ¼ m 0.Ifjt n jt n 1,1 a/2, the value of the t distribution with n 1 degrees of freedom and a level of confidence, H 0 cannot be rejected. Five mean output values were compared: passenger waiting time, number of waiting passengers, bus delay due to passengers, bus delay in queue, and total bus delay. For passenger outputs, observations corresponded to each passenger arriving at the bus stop. For bus outputs, observations were each bus which transfers passengers. Table 4 shows the results of the t-test at the 95% of confidence, where the accept H 0 actually means that the test fails to reject the null hypothesis. In parenthesis the critical values of the t distribution are shown [32]. In summary, in all cases the statistical tests demonstrated the resemblance of the model outputs with the reality for a good level of confidence. In addition, the magnitude of the differences with the actual system outputs has probably no practical consequences. Therefore, the evidence collected to date shows the adequacy of PASSION for simulation studies of stop operations. One of the approaches to evaluate the performance of bus stops has been the use of capacity models or formulae. Within these models, the most widespread method is the highway capacity manual (HCM) formula shown in the following equation [33]: 3600ðg=CÞ B s ¼ N eb (6) t c þðg=cþt d þ Z a c v t d where B s is the stop capacity (bus/hour), g/c is the effective green time of a downstream traffic signal (if any, otherwise g/c ¼ 1), t d is the average dwell time (second), which depends on the number of

11 82 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ Table 4. Statistical validation of PASSION at Santiago s bus stop. Output n m 0 m(n) S(n) jt n jj t n 1,1 a/2 Test result Waiting time (min) Accept H 0 Waiting pass (pass) Accept H 0 Queue delay (second) Accept H 0 Passenger delay (second) Accept H 0 Total delay (second) Accept H 0 alighting (P a ) and boarding passengers (P b ) per bus through the busiest door during a 15 minutes peak, according to the following equation: t d ¼ t a P a þ t b P b þ t oc (7) The rest are parameters of the model which values can be found in TRB [33]; these are: N eb, number of effective berths; t c, clearance time between successive buses (second); c v, coefficient of variation of dwell times; Z a, one-tail normal variate corresponding to probability that queues will form upstream the bus stop; t a, passenger alighting time (second/pass); t b, passenger boarding time (second/pass); t oc, door opening and closing time (second). It is therefore useful to contrast this formula and its consequences against those obtained with the PASSION approach. The HCM formula and PASSION were applied to one hypothetical case to derive the capacity of that bus stop. The case is a one-berth bus stop which characteristics are shown in Table 5. The resulting capacities are shown in Table 6. Four operational conditions were studied, according to the possibilities of the HCM formula: regular arrivals of buses and regular arrival of passengers (C v ¼ 0); random arrivals of buses and regular arrivals of passengers (C v ¼ 0.6); unobstructed exit (g/c ¼ 1.0); and exit obstructed by a traffic signal ahead (g/c ¼ 0.5). The random arrivals of buses were represented in PASSION by using the following negative exponential distribution [34] 1 1 u FðhÞ ¼ ð h t Þe q ð Þ ; if h t (8) 0; otherwise where F(h) is the distribution of bus headways, h is the bus headway (second), q is the mean arrival rate (flow) of buses (bus/second), t ¼ 1/S is the minimum headway between buses (second), u ¼ q/s is the proportion of buses arriving in platoons and S is the saturation flow of the bus stop lane (bus/second). It can be seen from the table that the HCM formula gives similar results than PASSION (about 6% different) in the case of free exits and regular arrivals of buses and uniform dwell times (i.e. regular arrival of passengers). However, in other circumstances discrepancies arise. In particular, in the case when traffic signals control the exit of the bus stop. In this case the capacity not only depends on the effective green ratio (g/c ¼ 0.5) as assumed in the HCM but also on the cycle time. Therefore, it seems that PASSION behaves better than the HCM model, which does not show sensitivity to the cycle time of the signal. In fact, some authors [35,36] have shown that a drop in bus stop capacity of up to 60% can be expected as a function of this variable as well as the effective green time and the distance from the bus stop to the downstream signal. Table 5. Operational characteristics of the hypothetical bus stop. Operational variable Value P b (pass) 2 P a (pass) 1 t c (second) 10 t oc (second) 1.0 t b (second/pass) 2.0 t a (second/pass) 1.5 Z a 0.675

12 MODELLING PASSENGERS, BUSES AND STOPS 83 Table 6. Comparison of PASSION with the HCM formula. 1.0 a (g/c) 0.5 b (g/c) C v 0 c 0.6 d Model PASSION HCM PASSION HCM PASSION HCM PASSION HCM Capacity (bus/hour) (50) e (50) (100) 154 (100) 108 (150) 121 (150) a Unobstructed exits. b Exits controlled by a traffic signal ahead with 0.5 effective green ratio. c Perfect schedule reliability and uniform distribution of dwell times. d Variations in bus arrivals and dwell times. e Cycle time MISTRANSIT MISTRANSIT is a tool that allows incorporating specific transit models in existing traffic microsimulators. This program adds changes in three aspects of the transit modelling in relation to the existing traffic microsimulators: the transit vehicles have new characteristics; passengers are incorporated in the microscopic simulation like new individual objects; and specific models to improve the representation of the interaction among passengers and vehicles at bus stops or terminals are also explicitly included. MISTRANSIT uses PARAMICS, connected via external applications using API. MISTRANSIT makes use of the transit vehicles and bus stops of PARAMICS. The external required data are arrival time and characteristics of transit vehicles and passengers. This data and statistics of transit vehicles and passengers are stored in arrays of data structures. In the following, we will describe the first module developed to model bus stops. When a bus arrives at a bus stop, MISTRANSIT looks for the passengers list of the bus and determines de number of alighting ones at such a bus stop. Then it searches in the bus stop passengers list for those that want to board that bus. These passengers get on board if the bus has spare capacity. Therefore, the Passenger Service Time will depend on the number of boarding and alighting passengers, the number and function of the doors and the bus capacity. When finishing these operations, transit vehicles leave the bus stop using the acceleration and lane change models of PARAMICS. The internal models for transfer of passengers at bus stops are the same as those detailed before in the description of PASSION. Therefore, the calibration and validation of MISTRANSIT models are stated by the procedure of calibration and validation of PASSION internal models, as shown in the previous section. In MISTRANSIT an additional feature was added, regarding the arrival of passenger distribution, and the way we can calibrate them. In the current implementation of MISTRANSIT, passengers can arrive deterministic, uniform, Poisson or Cowan M3 [34], the last one already described in the previous section for the case of bus arrivals. The chosen distribution will depend on how the data fits the patterns of each specific distribution. In the calibration of passenger arrival models we have to take into account the following considerations: (1) for choosing the arrival pattern, we could either fit the data to a distribution that minimize the error with respect to the observed data, or select the distribution that theoretically better represents the phenomenon. (2) The estimation techniques normally require data collected by event, either recording the arrivals during fixed intervals, or keeping the time at which each event occurs. The data collected in the field contains the difference in passenger arrivals between events (in this case, bus arrivals). At each event, we measure the transfer of passengers as well as the people waiting at stops. Times associated to such processes are also registered. By considering the previous facts, we will establish the following procedure for calibration of the passenger arrival models in MISTRANSIT, from data from the field: The passenger arrivals are grouped in intervals of, say 5 minutes, considering that the arrival pattern is stable within each interval. If we guess a Poisson behaviour of passengers showing up the stop, we group intervals until collect a fixed number of arrivals (say k ¼ 5), we then measure the total time spend until k arrivals; the interval

13 84 C. E. CORTÉS, V. BURGOS, R. FERNÁNDEZ to complete k Poisson events follows an Erlang distribution of parameters k and l, where l is the average rate associated with the associated Poisson distribution. For the case of calibration considering platoons of passengers, we have to define a threshold interval t p for two passengers to reach the stop in platoon. Both, the arrival rate g p within the platoon and the proportion of platoon arrivals u p are estimated by using maximum likelihood estimation [37,38]. Finally, fitness tests must be conducted to validate the significance of the estimated values from the observed distributions. The calibration and estimation of such passenger arrival models is a process currently ongoing, based on data taken in the field, during 2008, for different bus stops along major bus corridors in Santiago, Chile. Figure 6 shows a flowchart of the interaction between MISTRANSIT and PARAMICS. Arrows represent information passed from one environment to the other during the simulation, for example, updating statistics and computing dwell time at bus stops. As shown in the figure, MISTRANSIT contains two arrays of data structures, one for transit vehicles and the other for passengers. In what follows, we present a simple example of application of this program. The example shows the differences in system performance by using the original PARAMICS features and those obtained including the bus stop module of MISTRANSIT in a section of a street of the Santiago city. Intersections have traffic signals and the bus stops have one berth. This example shows one line whose buses are generated every 1 minute, and with bus stop demands of 60 pass/hour and 120 pass/ hour for the first and second stop, respectively. The arrival rate of passengers in PARAMICS can only be represented by a constant rate; however, using MISTRANSIT it is possible to specify an arrival time for each passenger at each bus stop (since passengers are controllable entities in the system). In order to reflect the differences in detail, the effect of modelling passengers arriving in platoons has been simulated in MISTRANSIT. Figure 7 shows the space-time diagram of two successive buses modelled in PARAMICS alone and PARAMICS-MISTRANSIT suite. Buses arrive at the network with 60-second headway which increases to 110 seconds when they arrive at the first bus stop. In PARAMICS, buses leave and arrive at the first bus stop with similar headways, because the associated dwell times are similar (12.5 and 14 seconds, respectively). On the other hand, in MISTRANSIT, although the difference between the arrival times of buses at the first bus stop is equal to that obtained by using PARAMICS, the exit Figure 6. Interaction between PARAMICS and MISTRANSIT.

14 MODELLING PASSENGERS, BUSES AND STOPS 85 Figure 7. Space-time diagram of two successive buses in PARAMICS and MISTRANSIT. headway varies. This is because the first bus that arrives at the upstream bus stop does not find passengers and therefore it does not stop. The second bus however finds passengers and must stop for 25 seconds. This difference causes an increase in the exit headway between the transit vehicles and this increase is translated into an increase in the arrival headway to the downstream bus stop and, therefore, in a more irregular service than that modelled with PARAMICS alone. This simple example shows that the implementation of a more flexible model of simulation allows better representing the simulation of complex operations of public transport, not contemplated in commercial packages available in the market. In fact, from the example we appreciate the potential benefits of a simulator tool (MISTRANSIT-PARAMICS connected via API) that properly calibrated, mainly regarding models for passenger transfer and arrival (the former described in the previous section in the context of PASSION), replicates realistic patterns and behaviour in bus stops and other infrastructure devices of the operation observed in Chile, unlike the use by default of a sophisticated microsimulation package such as PARAMICS. Other potentialities incorporated in MISTRANSIT are the possibility of evaluating real-time control strategies, such as holding buses at stations or skipping some stops according to what the controller is deciding dynamically. The strategies can easily be incorporated by determining an optimization module that gives instructions to the simulator every time and event occurs. In this particular cases, the events are associated with the arrival of buses to bus stops. When a bus reaches a bus stop, PARAMICS pass that information to MISTRANSIT. In the simulator, the optimization module is called; that module read the real-time information provides by both MISTRANSIT (regarding passenger demand mainly) and PARAMICS (regarding traffic congestion and bus positions), and decides if a control action has to be applied on that bus based on an optimization engine (with proper algorithms depending on the method: control, dynamic programming, heuristics, etc.) that recommends the best action to be made. Then, MISTRANSIT communicates that action to PARAMICS and the bus either remains at the station for a while, skip the station, or just operates normally. Signal priority control actions are also incorporated in the simulator by following the same procedure, but in this case the event is triggered when a bus reaches a loop detector when approaching to the signal position. Control actions are then applied after asking the optimization engine; actions such as extending the green phase or interchanging phases can be evaluated in this context. In summary, these kind of control actions can be evaluated by means of their performance (in terms of both operator and users costs) of their implementation compared with a benchmark system that does not consider real-time control (open loop system). The inclusion of sophisticated prediction methods to decide these control actions, fed from real-time information from the system during the simulation is something currently being systematized in the simulator. Table 7 shows a summary of the major advantages of the proposed model in the treatment of the interaction of buses and passengers at bus stops and other devices, with respect to existing models. 4. CONCLUDING REMARKS In this paper, we have shown the recent advances in microsimulation of generic and more specific transit system, which has been underestimated in commercial packages, mostly oriented to car traffic.