Personal transportation has traditionally meant automobiles. Despite enduring hype from transit enthusiasts and social reimagineers, personal rapid transit (PRT) has remained Buck Rogers-quality science fiction. However, recent advancements in computational power, communication capabilities, and propulsion have suddenly made PRTs viable. A number of recent studies suggest that PRTs may actually be on the verge of being implementable.

Chief among the remaining questions about PRTs is the issue of train control. PRTs, if they are to provide reasonable capacity, must use a "moving block" system. Briefly, moving block control systems surround each vehicle with a buffer zone that no other vehicle can impinge. The controlling computers ensure that each vehicle will safely stop in the case that the vehicle in front comes to a stop. While questions remain about whether a "brick wall test" is required, the moving block control system itself is novel enough to require new computer models.

JKH Mobility Services (a division of Kimley-Horn & Associates) has a long tradition of innovative modeling tools, especially for train control simulations. It is hardly surprising then that when the City of SeaTac wanted to study PRTs, they turned to JKH Mobility Services to provide simulations. JKH is one of the few firms in the world to offer moving block simulations. This paper describes JKH's experience in simulating PRTs for the City of SeaTac.

One of the most interesting aspects of simulating PRTs is that no PRT systems—as currently defined—have ever been built! The current definition of PRT encompasses a small auto-sized vehicle that typically carries four seated passengers. These small vehicles travel directly from an origin station to a destination station on guideway, bypassing intermediate stops and using the most direct route. It has been likened to a taxi on guideway.

Because of the many novel features of PRTs, it was important to able to evaluate various aspects of the PRT's performance. JKH's PRT model—WinPRT—was used to assess the performance of the various PRT configurations contemplated.

The simulation model used was derived from a third-generation version of a destination-coded vehicle (DCV) model. This model had been previously used in order to assess package sortation systems using DCVs. It was updated to simulate PRTs, and included the following improvements:

• The acceleration and deceleration models were modified to correspond with the baseline PRT vehicle identified for the SeaTac project,
• Moving block train control was improved; crashes amongst cargo vehicles could be tolerated, but were clearly unacceptable for vehicles carrying humans,
• Various merging algorithms were tested
• Various empty-management techniques were tested
• Station dwell behavior was implemented (as opposed to the on-the-fly loading and unloading common to package systems)

Since the previous DCV model was created using object-oriented programming techniques, the subsequent PRT model was both easily extensible and robust. Consequently, many variations could be tested during the course of the project.

Of the many interesting aspects of the model, the moving block train control and the merging algorithms were the most novel.

As mentioned in the introduction, moving block train control is fairly novel in transit applications. As implemented in the PRT simulations, each vehicle is responsible to maintaining separation from the vehicle in front of it. Every time interval (one second in the simulation, but likely several times a second in real life) the vehicle determines how far it is from the vehicle in front of it. In a "brick wall test," the vehicle will adjust its speed so that there is sufficient distance for it to stop completely in the distance between the vehicles. That is, it uses the worse case scenario of the leading vehicle being completely stopped instantaneously, like it hit a brick wall. A brick wall test maintains a conservatively safe distance between vehicles. The brick wall test is currently the standard, because it is part of fail-safe design.

Most PRT manufacturers and enthusiasts insist that the brick wall test is overly conservative. The leading vehicle—they argue—will never go instantly to a zero velocity. Instead, it will decelerate. Therefore, the following vehicle needs only to maintain a distance equal to the distance it travels before learning the leading vehicle is decelerating (plus some margin of safety). This allows a much shorter distance between vehicles, thus increasing the capacity of the system.

The WinPRT model is capable of both the brick wall and "simultaneous stopping" trailing techniques. The brick wall test is much cleaner and easier to implement. The moving wall technique required special damping functions to eliminate over compensation. Interestingly, this over compensation is also a problem amongst PRTs on the test tracks.

The method of merging vehicles carrying humans is an important variable in system capacity. In DCV systems, the vehicles are able to merge more quickly (using higher accelerations since humans are not on board) and can be riskier. The effect of a minor bump is perhaps a damaged good, not an injury. Therefore, the merging technique required careful consideration.

In actual practice, several techniques were evaluated. In one case, a priority junction was used, similar to a yield sign on roadways. However, the final technique used was an implementation of the method actually used by the manufacturer of the baseline vehicle.

Once a vehicle reached a "check-in point" before the junction, it called to an intersection supervisory computer (implemented in the model as a special asynchronous function). It made a "reservation" and was placed in a queue behind a "phantom" vehicle. From there on, it used the normal trailing vehicle moving block controls to maintain adequate separation. Often, this meant the checking-in vehicle had to slow to reach the junction with adequate separation.

Because the model was implemented using object-oriented programming techniques, each vehicle could truly be modeled in a realistic way. Each vehicle "object" maintained its own status, just as an on-board computer inside a PRT vehicle will maintain itself.

The primacy of empty management among supervisory controls on PRTs is not a new concept. Simply stated, empty vehicles present a thorny problem. Empties need to be where they can be used, but to get there they use valuable network capacity. "Dead-heading" empties get in the way but necessarily move to where they are needed. An oversupply of empties traveling to waiting customers chokes capacity, but a dearth of empties creates huge wait times.

A large effort was made to improve the empty vehicle management in the SeaTac study. Even after using the baseline manufacturer's management technique, it was recognized that more capacity could be eked out of the system. This topic is probably where a great proportion of the implementation energy will be spent. Every implementation of a PRT system will require a custom tweaked empty management system.

The results of the SeaTac PRT simulations showed that PRTs are not practical for every application. In particular, remote, lightly used stations should be avoided. Routing empties to these remote stations consumes a great deal of time and system capacity. Also to be avoided are heavy "trunk line" applications, such as remote employee parking lots where a great many trips must be made in a short time. Such a usage requires great line capacity, which is not a PRTs strong point. As a result of the simulations, the overall network was reduced to focus on the most cost effective, heavily used sections. With such a system, the City of SeaTac has decided to pursue further the implementation of a PRT system.

One other result of the project was a confirmation of the wisdom of programming the simulation in an easily extensible manner. In order to provide an operations-level simulation, it was found necessary to nearly replicate the intricate train control system planned for PRT systems. Using an object-oriented approach, customizing the model to the specific system design was easy. In this regard, being the developer of the software—as well as a user—proved to be invaluable.

JKH Mobility Services' years of experience in train control found fresh application in this innovative technology. The consideration of PRTs as a viable mode may be new, but our ability to respond to innovative techniques is not.