76> Autonomy

     Here are two criteria for a good, open source PRT control system. First is that it should be unbreakable. The second is it should be infinitely extensible.

    When I was a young boy, living in upstate New York, there was a blown fuse in the Power Plant near my home. It created a cascading effect that left twenty-five million people without power, including New York City. That is what we don’t want- interdependent software and hardware arrangements that control large areas or groups.  After all, eventually a support will get hit by a train, or there will be an earthquake, a tornado, terrorism, hackers, or whatever.

    Giving PRT vehicles the ability to act autonomously gives both extensibility and unbreakability, but might seem counter-productive. After all, won’t this result in the same traffic problems that PRT is supposed to address?

    I believe the model of automobile traffic is actually a pretty good one, except for the drivers. Because our reflexes are limited, we dare not tailgate. These spaces between vehicles reduce capacity. PRT can solve that. Another problem with traffic is that there is no sure way to know which route will be the fastest. PRT can solve that as well. Then there is the case of accidents and other delays caused by other drivers.  PRT cannot, however, solve the problem of simply having more vehicles wanting to use a road or track than can fit. Special care must be used to avoid having two packed tracks merge into one, but even this doesn’t necessarily require centralized control.

    One theoretical advantage of the old-style concept of strict central control is that every vehicle’s route and arrival time can, in theory, be known from the beginning of the trip and the projections used to plan other vehicles’ routes and so forth. The traffic is balanced from the beginning. Numbers of vehicles converging on a single bottleneck or destination would be known and could be cued to arrive in an ordered fashion. If delays are anticipated the passenger would be informed as to the length of the delay before boarding, or the destination could even be refused. This tack was largely abandoned in the early days of PRT research, however, because it was too computer intensive - especially since a single slipped schedule would throw the whole thing off. It was recognized, even back then, that more decentralized computers that managed smaller parts of the system would be more robust, and that strict synchronizing is not necessary, except for merging.

    Though I don’t seriously suggest it at this time, it is interesting to note that these days every vehicle will undoubtedly have much more processing power than it could ever use. Therefore, given high-speed communications, a PRT fleet could use distributed computing techniques to tackle advanced real-time traffic management, blurring the distinction between autonomy and centralized control. Just an observation. I get easily sidetracked… 

    It is my opinion that the logical progression toward decentralization should continue with the abandonment of the so-called “way-side computers” or “zone-controllers”. The vehicles themselves can perform these duties. Advances in communication technologies, it seems to me, render them obsolete.

Part of this decision rests on the concept of an open, standards-based approach. I do not think that it is beneficial to have PRT be developed, installed and managed by a single, “Swiss-army-knife” company. I think it will inhibit municipal sales. Even if there were some buyers, I think it would generally lead to poorly designed and executed systems over time, as is often the case when the only competition is with other departments over R&D funding.

    An approach that would inspire more confidence, competition and innovation would be to standardize and separate PRT in terms of Track, Stations, Vehicles, and Control/communications. A consortium of companies organized in this way would have other sources of income besides PRT and could stay within their core competencies. The control aspect in particular, though, seems to pervade all systems. It would be good to begin with an architecture that clearly and simply defines who has control when, where and why. The “zone controller” seems to be an odd orphan in this respect. I begrudgingly accept the possibility of such external control of vehicles at a station.

    With autonomous control, each vehicle is programmed with “behaviors”. This is analogous to bees or ants. The queen doesn’t plan the routes and objectives for the hive or mound. Individuals have separate behaviors that have a combined synergistic effect. With an autonomous PRT system, vehicles are externally informed but not controlled. As much of sensing, communicating, and computing is done by the vehicles themselves as possible. Such a system relies on extra redundancy. This has been made practical by the incredible and continuing drop in component prices. With several of everything, vehicles can react to a sensor, communication or computer problem by simply taking themselves  to the shop, though possibly with degraded performance. There is also redundancy in the information flow and delivery methods. If there is degraded communication in one system the message will be repeated anyway. If the fault is in the receiver there is another different type of system that delivers the same info. The methods I suggested in the last post are examples of such a redundant system that does not rely on, and is therefore a good compliment to, more ordinary communication means involving radio waves and microprocessors.

    It is also noteworthy that in the brief time a vehicle is docked for boarding a detailed up-to-date traffic “map” can be downloaded. This should include timetables of anticipated traffic and station usage as well. This would be where the vehicle would learn of possible track segments to avoid. These can be updated along the way in shorter transmissions. I envision the vehicle frequently rechecking for the fastest route along the way and broadcasting its updated ETA. The stations would share in the creation and distribution of the resultant updates, so this information, too, would be from redundant sources.