by J. Edward Anderson

Abstract

This paper describes a computer simulation program developed by the author to study the operation of personal rapid transit (PRT) systems of any size and configuration. The control scheme is asynchronous with maneuvers commanded by wayside zone controllers. The simulation runs on a PC, is accurate in every detail, and can be used to run an operational system, which would have dual-redundant computers on the vehicles, at wayside to manage specific zones, and in a central location to manage the flow of empty vehicles and to perform other system-wide functions. Some results are given.

1 Introduction

Pucher and Lefèvre¹ have shown that urban transport is much in need of a breakthrough. Recent studies add weight to the argument that Personal Rapid Transit (PRT) is the needed breakthrough.^{2, 3} PRT is an automated guideway transit system in which all stations are on by-pass guideways, the vehicles are designed for a single individual or a small group traveling together by choice on a network of guideways, and the trip is nonstop with no transfers.⁴ Its full development should be supported by governments. During a program initiated at the University of Minnesota in 1982 to develop a much-improved PRT system, the author developed the simulation program described in this paper. It is intended both for use in planning PRT systems and for operation of a real system.

A PRT system will employ computers on the vehicles, at wayside zones, and at a central location.⁵ Each zone controller and the vehicles in its zone communicate through a communication line in the guideway, and the central computer and zone controllers communicate through fiber-optic cables. The mathematical background needed to understand the simulation program described in this paper has been developed by the author.⁶ To achieve the necessary degree of safety and reliability, the computers are "dual-redundant," i. e., each is a pair of computers and each has two mother boards that check each other each time-multiplexing interval, which may be in the range of 40 to 100 msec. The output of each of the two pairs of mother boards is then checked to enable the vehicle to proceed normally. The details of dual-redundant operation and the outstanding safety and reliability thereby achievable were developed by Boeing Company for the U. S. Department of Transportation.⁷ In the Boeing work, a means was developed for communicating between each vehicle and a wayside zone controller through a three-wire line by time multiplexing, in which each vehicle under the supervision of a given zone is assigned a specific time slot for its communication.⁸

^{2 Guideway Layout}

The first step in developing a PRT simulation is to define the guideway, which can be of any practical configuration and is laid out over a map of the region of interest. An origin of coordinates is defined and the coordinates of the apexes (intersections of tangents) corresponding to all changes in direction are determined. Then the distance of each station along the guideway, measured from the nearest upstream apex, is specified. If the guideway is three-dimensional the layout process is substantially more complex, but is accomplished by means of a methodology developed by the author⁹ to determine the performance of high-speed vehicles or trains such as maglev operating along the hills and curves of an expressway.

The first of a series of guideway-layout programs accepts the coordinates of the apexes, the positions of the stations, the number of loading berths in each, and the desired line speed in each section of guideway. The program as currently written assumes series loading stations, i. e., stations in which there is a single by-pass guideway. This means that if one group takes extraordinarily long to load, the vehicles and passengers behind are held up, but the statistics of peak-period operation is such that this is not a serious problem, and parallel-loading stations are generally not worth the extra expense. In the next program, ride-comfort limits on acceleration, jerk, and roll-rate in superelevated turns are introduced and various parameters needed to calculate the guideway coordinates are determined. With this information, the next program calculates the guideway coordinates for each of a series of equally spaced values of arc length S, measured along the guideway. A value of S then uniquely defines a point on the guideway. The guideway configuration is completed by three additional programs in which the branch points and stations are numbered and all necessary relationships between them are defined. With this information available, the minimum distances and uncongested times between all station pairs are determined and stored in two arrays. In the same program a table of switch commands from each diverging branch point to each station is derived and stored.

For a given PRT system, the static input is the fixed facilities, which are defined in Section 2 to the degree needed in the simulation. The dynamic input is the demand in people per hour between all station pairs, i. e., the demand matrix. It is a function of the actual trip times, but they are outputs of the program. Thus, the true demand matrix must be calculated by iteration, beginning with the ride times and wait times calculated in Section 2. The program permits the demand to vary in steps as a function of time of day, but almost always the interest is in determining performance at peak demand.

The simulation takes into account the random nature of person flows with a given average by use of the random-number generator included with the programming language, which gives a pseudo random number between zero and one. For example, if the computation interval for program updates is half a second, as we currently use, 7200 computation intervals pass per hour. If the demand from station i to station j is D_ij passenger groups (riding together by choice) per hour then the average number of passenger groups per computation interval is D_ij/7200, so the program initiates a passenger if the random number calculated is less than D_ij/7200. Using the random-number generator, the program also simulates the passenger loading and unloading times as normal distributions, and for purposes of calculating power and energy use, it simulates the passenger mass as a normal distribution.

The operating PRT system consists of the vehicles and passengers plus the fixed facilities. The time varying state of the system is therefore stored in memory units called arrays related to vehicles, passengers, stations, and line-to-line branch zones, which are separated into diverge and merge zones. The number of quantities, some fixed and some time varying, needed to fully define the state of each vehicle is 35, each passenger 15, each station 31, and each branch point 12. Many of these quantities could not have been realized without the experience of developing the program. Additionally, for every merge zone, whether from a station to the main line or from one main line to another, a zone-control array is defined that gives the number of each vehicle in the zone in order of its distance from the merge point. This enables the program to determine when to release a vehicle from a station, and when to slip a line-to-line merging vehicle. On occasion station and line-to-line merge zones overlap in physical space, and the program distinguishes the zone in which each vehicle belongs.

At the beginning of each system-update time step, taken in the current program as one half second, the state of each vehicle is updated. Some vehicles are not ready to move, so their state of motion is unchanged, some are moving at constant line speed so their new position is simply the line speed multiplied by the time step, and some vehicles are maneuvering. Maneuvering vehicles may be moving from one line speed to another, accelerating from a station to line speed, decelerating to rest in a station, advancing through a station, or slipping to merge into another stream of traffic. To attain the greatest throughput, each of these maneuvers must be accomplished in minimum time consistent with given values of tolerable acceleration and jerk, and with predictable accuracy. To complicate the situation, the speed and acceleration at the start of each maneuver is variable because the vehicle can be maneuvering when a new maneuver is commanded.

Software has been developed that calculates all of these maneuvers exactly for given initial acceleration and speed in a form that can reside in each vehicle computer and in each station-zone and merge-zone computer. Each maneuver is commanded by one of these zone controllers. The maneuvers are divided into three classes: acceleration to line speed, deceleration to rest in a given distance, and slipping a given distance from a maneuver back to line speed. The zone controller needs to communicate through the communication line to a vehicle only the maneuver class, the final speed, and in the later two cases a distance. The vehicle computer then calculates the time-varying command speed and position as frequently as needed to obtain stable and accurate control (about once every 10 msec), and the wayside zone controller calculates it as frequently as needed to monitor the actual speed and position so that it may command the vehicles to slow to creep speed if an anomaly occurs. The key to successful merging is to compute in the merge-zone computer during each time step both the maneuver profile and the amount of slip remaining. Knowledge of slip remaining permits the merge-zone computer to command the correct amount of additional slip each time a vehicle reaches the Merge Command Point, which is discussed in the next section. When such a vehicle is commanded to slip, vehicles close enough behind to violate the minimum-headway criterion when the slip is complete are likewise commanded to slip enough to satisfy the criterion. When traffic is heavy, such slipping may propagate quite far upstream; and, to limit congestion, vehicles are not permitted to leave stations while mainline vehicles passing them are slipping. In this way congestion on the system is contained and the indication that the capacity limit is being approached is manifest in wait times increasing to unacceptable levels.

6.1 Command Points and Actions

The simulation is event driven. When a vehicle moving along the main line reaches a certain point in the guideway it is given a command if certain criteria are met; when a vehicle moving on a station by-pass guideway can either advance or go to line speed it is given a command; and when each stopped vehicle is loaded and ready to move it is given a command to move if the berth ahead is vacant. For vehicles moving along the main line, there are six command points. Their location along the guideway and action required is as follows:

For vehicles on a station by-pass guideway, there are four possible commands. These do not occur at specific points along the guideway, but when a certain event takes place wherever on the by-pass guideway the vehicle is located. These events and commands are as follows:

When an occupied vehicle reaches the Switch Command Point upstream of a particular station, the cognizant station-zone controller asks for its destination. If it is destined for this station, the zone controller must know if the station can accept an additional vehicle, and thus must keep track of the state of every vehicle on the station by-pass guideway. If the station cannot accept the vehicle, it is waved off and has to loop round and try again. A design parameter is the fraction of wave-offs acceptable. When an empty vehicle reaches a Switch Command Point, if the station does not need an empty vehicle it is switched away. If the station needs an empty vehicle; but, based on information from the central computer a station ahead has a greater need, it may also be switched away.

When a vehicle reaches a Merge Command Point, the merge-zone controller compares its position with the closest vehicle on the other leg of the merge. If it would be too close upon merging, the vehicle is commanded to slow down and then speed up thus falling back the necessary distance, called the slip distance. If the vehicles behind it would be too close after the slip maneuver is complete, they are also commanded to slip the necessary amounts.

When an occupied vehicle reaches a Diverge Command Point, it transmits its destination to the diverge-zone controller, which looks up the left-or-right switch command in a table of switch commands and returns the appropriate command. A function of the central computer is to keep track of the flow in every link so that it may modify a specific switch table if necessary to avoid excessive congestion. When an empty vehicle reaches a Diverge Command Point, it is switched in the most-needed direction based on continually up-dated information from the central computer.

6.5 Station Commands

At the Deceleration Command Point, the vehicle destined to enter the station is commanded to stop at the forward-most empty berth. As the vehicle advances, the berth or berths ahead of the assigned berth may empty, in which case the vehicle is reassigned to the new forward-most berth so that the previous berth may be available for the next vehicle. This reassignment may occur several times. When an occupied vehicle stops, it begins to unload with an unloading time picked from a normal distribution. When unloading is complete and a berth ahead clears, if incoming traffic conditions warrant, it is commanded to advance to a new forward-most free berth before being permitted to load. When a vehicle that has loaded at the subject station is ready to leave, the Station Zone Controller determines if there is a suitable opening in the mainline traffic. If so it is commanded to accelerate to line speed. If not and there is now an open berth ahead, it is commanded to advance. During the maneuver, the station-zone controller checks the mainline flow during each time step to determine if it could safely accelerate to line speed. If so, while it is moving, it is commanded to line speed. If there is an empty vehicle in the first berth and, based on a criterion, it is not needed, it is given the destination of the next station so that it can be commanded to line speed. Empty vehicles are similarly released from storage stations.

In addition to all information needed to define the guideway, stations, and demand, the input parameters relate to the above-mentioned ride-comfort parameters, to loading time, and to energy use. Loading-time parameters are the mean loading time, the standard deviation, and the minimum and maximum loading time. The energy-use parameters are all those needed to calculate instantaneous power and energy. The program can include as accurate a model of the propulsion system as is available.

The simulation may be observed graphically or, if not, it runs much faster. In either case, the output parameters include wait-time statistics, trip information, wave-offs, power and energy, and use of the loading berths. The wait-time statistics include for each station the average, maximum, and median wait time; the percent of wait times less than a given time such as three minutes; and the maximum number of passenger groups waiting. The trip information includes the number of passenger-groups entering the system, the number of completed trips, the passenger-km and vehicle-km traveled, and the average trip time with and without the average station wait time. The number of wave-offs is used to determine if it is necessary to increase the number of extra waiting berths ahead of each station platform to meet a given wave-off criterion. The peak power for the system is calculated every computation cycle and has been found to be useful to power engineers. The program also calculates the kW-hr used and the average kW-hr per vehicle-km. Finally, the program stores and displays the number of times each loading berth in each station is used. This information is useful to determine if the assumed number of loading berths in each station is to large or too small.

Using the subject program, simulations have been developed for a suburban village, two universities, a high-speed inter-city form of PRT, and a directed-vehicle automatic airport baggage-handling system. These simulations run on a PC using the Visual Basic 5.0 programming language. Table 1 shows some results for a PRT system designed for Seoul National University in Korea. The campus is 1.55 long and 0.5 km wide. The PRT system has 15 passenger stations and two vehicle-storage sidings, and is connected to a subway station 1.6 km away. The first column shows the number of vehicles tested. Five runs were made for each number of vehicles. The second column is the average of the average wait times for each of the five runs, and the third column is the maximum variation from the average wait. The fourth column is the average maximum wait time, and the fifth column is the maximum variation from the average maximum wait. It is seen that if a maximum wait time of say three minutes were specified, it would be necessary to use at least 339 vehicles, but that the variation from 327 vehicles to 343 is quite small.

Table 1. Wait-Time Data for a PRT System in Minutes

Conclusions

A simulation has been developed to determine the performance of PRT systems of any size and complexity, limited only by the memory and speed of the computer used. The program is complete and makes no compromises in any way, so it can be and is planned to be used in operational systems. All performance parameters needed to determine required station sizes, system throughput, system power and energy use, and system costs are calculated. Passenger-arrival times, and loading and unloading times are randomized to permit realistic bunching of flows to be studied. Optimization of empty-vehicle movement to minimize wait time can be studied. The results obtained thus far in several applications show that PRT systems are completely feasible, practical, and economical. Typical peak-period wait times are well under three minutes, and zero off-peak.

[1] Pucher, J., and Lefèvre, C., The Urban Transit Crisis in Europe and North America, MacMillan, London, 1996.

[2] Anderson, J. E. (ed.), Special Issue: Personal Rapid Transit, Infrastructure, 2, pp. 1-65, 1997.

[3] Special Issue: Emerging Systems for Public Transportation, Journal of Advanced Transportation, 32, pp. 1-128, 1998.

[4] Personal Rapid Transit (PRT): Another Option for Urban Transit? A report by the Technical Committee on PRT of the Advanced Transit Association, Washington, D. C., Journal of Advanced Transportation, 22, pp. 192-314, 1988.

[5] Anderson, J. E., Control of PRT Systems, Journal of Advanced Transportation, 32, pp. 57-74, 1998.

[6] Anderson, J. E., Transit Systems Theory, 2^nd edition, collected papers available from the author, 1998.

[7] Milnor, R. C. & Washington, R. S., Effects of System Architecture on Safety and Reliability of Multiple Microprocessor Control, 34^th Vehicular Technology Conference, IEEE Technical Paper, 1984.

[8] Nishinaga, E. I. and Colson, C. W., A Vehicle Collision Avoidance System Using Time Multiplexed Hexadecimal FSK (Frequency Shift Keyed), 31^st Vehicular Technology Conference, IEEE Technical Paper, 1983.

[9] Anderson, J. E., Maglev Performance Simulator, Contract No. DTRS-57-94-C-00004, Volpe National Transportation Systems Center, U. S. Department of Transportation, Cambridge, Massachusetts, 1994.

HOME

Last modified: December 09, 1999