101> PRT Merge Control

Well, I didn’t say I wouldn’t post… Part of not having to post every week is to give me the time to explore ideas more fully before I write about them.  The matter of PRT control, however, is something that I have already written about extensively in draft form, both to clarify it in my own mind and to try to figure out a way to explain it.  Here is a little sample for your consideration that cuts right to the heart of the matter.

Consider the most critical maneuver in PRT, the merge.  Weaving PRT traffic can be done through exact scheduling, direct sensing/communications between merging vehicles or through an intermediary. Over a decade ago, When J. Edward Anderson wrote about the problem, using an intermediary was the only practical solution.  I believe that paradigm is no longer the only game in town.

Let’s compare a similar type of system, also designed many years ago, air traffic control.  Here, airplanes are controlled by an intermediary, the control tower, which I think is roughly analogous to Anderson’s “zone-controllers.”  Could we cut this intermediary out?  Consider what would happen if the tower went dark but the planes could communicate with each other directly, and they all had the airport’s schedule.  It would be a fairly simple matter for the first plane on the schedule to call the second when it was about to touch down, and again when it was clearing the runway, with the second giving similar guidance to the third, etc.  Moreover, if they synchronized their watches, they could simply make a schedule for themselves, landing a plane, say, every minute, so that the first might touch down at 4:00, the second at 4:01, and so fourth.  If they all knew who was in the air around them and what the landing order was, they could speed the process by all advancing their schedules each time the landing plane beat the scheduled time.

This is the essence of what I propose for PRT.  With PRT, at the inception of every trip, it is necessary to know if the trip can be completed and if so, by what route.  Since any trip can be broken down into pieces, dividing the trip into segments beginning and ending at merge points makes as much sense as anything else.  Since the travel time between merge points can be estimated, there should be, at the beginning of any trip, a knowledge of what time each merge point will be encountered.  This would be an opportune time to assess the traffic load through the various merge points and to consider alternative routing.

Furthermore, upon logging these plans at the boarding kiosk, a system-wide database can be generated which may be divided and sorted in different ways.  One such way would be to list all vehicles scheduled to pass through a given merge point, sorted by time of arrival.  A group of such lists (one for each merge point on a route) could be downloaded to every vehicle upon leaving the station and updated.  In this way, every vehicle in every stretch of track knows the identities of every other vehicle on that track segment, as well as those on the corresponding track segment that is connected at the next merge.  Now a  LAN can be established.  Furthermore, every vehicle knows which vehicles are the most relevant from that list, those being the ones that are closest chronologically.  This is not very different from the example of the pilot-to-pilot communication described above, with the most important conversations being between those first in line.

Now all of the vehicles in the two connected segments have each other’s “phone numbers” (so to speak) and can initiate communication as needed. There are a number of things that might be done to help things along, such as either distributing or “clumping” vehicles together, prioritizing vehicles by swapping merge schedules, or even pushing vehicles faster through the merge than would normally be acceptable, to help avoid an upcoming traffic jam, or even switching routes if there is a diverging track.

Listing all of the ways traffic could be shaped is too involved to get into here, and traffic shaping software would probably evolve over time anyway. 

It is worth noting that this system consists of smaller, faster, shorter distance, and more critical networks overlaid upon larger, slower, potentially less timely ones. For example, the kiosk booking and initial routing, it seems to me, could be done via the web, while last second communications between vehicles about to enter the merge should probably be circuit-switched (“hard-wired”) instead of packet based, and would include only those vehicles directly involved. Such a general architecture could offer excellent fault tolerance through the redundancy of multiple networks and independence from central control.

Two points to add  –  First, in regards to previous posts and comments about cameras and sensors and seeing around corners … I want to point out that if vehicles can broadcast location updates more or less continuously, this is functionally equivalent. “Dark” vehicles can be detected as missing from the network, and in the scheme above their relative location is also known. Second, in regard to previous discussions about variable speed, I used the example of catering to people who are prone to motion sickness as one benefit.  I think a far better example is that of empty vehicles. In a rush-hour situation, great numbers might need to be shuttled back empty to pick up new passengers.  These empties have no issues to restrict speed at all, and their lighter weight means they can have less headway.  In fact, I see no regulatory obstacles to coupling them into platoons.  (Platooning occupied vehicles would be a lot easier to sell after it has been widely used for empties.)  This is easily accommodated by the control system outlined above.  Anyway, it is adaptive, variable speed I am advocating, not gentle rides or fast empties or platooning or prioritized traffic.  These incremental improvements can evolve later, as long as the system architecture supports such tweaking.