96> Control Issues, part II

Let’s demystify control with an overview. Background on this subject can be found in posts 75-77. I’ll start with navigation. Obviously the first choice in any navigation system is to simply go in a straight line. The mitigating factors are availability of track and traffic on it. If there is a possibility of some traffic being slower than other traffic, then that adds a third factor. Let’s start with the straight line. Imagine the network as a chessboard, with you at one corner and your destination at the other. It should be a simple matter to identify all squares directly between the two points and rate them highly. Squares less direct, but still nearly in the line would score a bit lower, and so forth. Now within those squares are actual tracks. Some go East/West, some North/South, or somewhere in between. Here again there can be a rating system based on how close the direction of a route segment comes to the direction that would be the optimum straight line. A final factor would be expected traffic and speed. Traffic can be derived from ticket data or real time reporting from the vehicles themselves. This data then is crunched, preferably by the vehicle, and it can set out. I say “preferably by the vehicle” because if the vehicle makes these decisions, the route can be refigured along the way. Every route is only a series of left or right turns separated by a straightaway. At each diverge point, the whole fastest route strategy can be recalculated. This information would be available wirelessly, possibly even via standard internet means.

Let me back up a bit and clarify the concepts of speed and traffic. I do not like the concept of line speed, except perhaps at merges. While line speed will probably be the inevitable result of having vehicles not holding each other up or rear-ending each other, there are arguments for allowing vehicles to decide their own speed where possible. If we are designing a control architecture from scratch, let’s start with a wish list and see if those wishes can be fulfilled. Personally, I like fast. I drive fast, and if I haven’t arrived yet, then I’m probably in a hurry. Hazard of years of self-employment, I guess. I want all timid, motion-sick wimps to get out of the way! Hey, I’m on the clock here! PRT can, and should be, fun, sexy and exiting. Why not? Also, one way to keep a track segment free of traffic congestion is for the people in front to speed up and make room for those bringing up the rear.

The stations, it seems to me, should talk to each other as the first level of traffic management. This would be where the vehicles would get information about expected traffic and speeds, and where they would report their prospective routes. Getting the OK, (or rather a confirmation that the trip is doable in a reasonable timeframe and the destination station is able to receive the vehicle) they would leave the station and drive themselves autonomously. If conditions change, they would be capable of changing routes, but since this would be a rare occurrence, the central system would generally be pretty accurate. This is after all, essentially a traffic reporting function, not so different than the morning “Jam Cam” on local TV.

A second system could be vehicle-to-vehicle communications, sort of like a trucker’s CB radio. (“Breaker Breaker, good buddy!”) Such a system would keep track of the positions and speeds of all vehicles within a relevant range. The most important aspect of this function would be at merges. Vehicles would negotiate for precise time-based “reservations” for crossing the merge point. Especially important would be communications between the vehicles equidistant from the merge that must adjust themselves to each other to avoid conflict. Early upstream communications between many vehicles would enable the traffic to be “shaped” so as to maximize throughput. For example, if track A has twice the vehicles as Track B and they are to merge, the best way to “shape” the traffic would be to get Track A’s vehicles in evenly dispersed groups of 2.

There must be a backup system for this. One idea is to enable a vehicle on track A to disable the power to the corresponding section of track B. The frontrunners would always get preference. This could be built into the track with a few Reed switches and relays, and would not tend to wear out because they would be switching off sections of track that are not supposed to have any power draw anyway. (When vehicles lose track power they slow to walking speed.) A final, emergency backup solution would be to slow everybody down and just take turns, the PRT equivalent of a malfunctioning traffic light. “Treat it as a four way stop.”

The vehicles’ headway control would work by each car reading its position on the track (optical bar codes, magnetic markers or RFID tags) and reporting its velocity by broadcasting it wirelessly through ordinary wireless LAN protocols. The position sensing would be enhanced and checked by counting wheel rotations. A back-up system would be to use a pair of overlapping wave guides, perhaps a hundred meters in length. (I am counting Leaky coaxial cable as one type of wave guide.) The limited length would limit communications to relevant traffic only, and would eliminate demultiplexing of many extraneous communications streams. In closer ranges optical or ultrasonic methods would be added. (The chip they use in cameras is under $50.)



So that’s pretty much it. It’s not a particularly difficult to avoid driving into a vehicle in front of you, nor taking the correct turn, nor maintaining a speed to cross a merge at an exact (to the second) time. So I say let the vehicles control themselves. That way control will automatically get updated as vehicles wear out and are replaced, except for station controls, which can be monitored and serviced very easily and need WiFi and line power for the kiosks anyway. Almost any task that can be done by a central wayside computer can be done by combining the computing resources of vehicles connected by a wireless LAN. In this architecture all control decisions come from the vehicles, although zone and station traffic is monitored and shared. The exception is the power scheme for merge points that I mentioned.

This architecture is designed for an open source system. It presumes that vehicles are designed and continually improved by a nonprofit organization (NPO) but built by independent contractors. The track and station construction would be contracted to locals, and the station communications and kiosks would be Open Source (NPO developed) but installed and maintained by local contractors. The role for a PRT company is minimized. I think this is a good thing, because no PRT companies have a long-term track record anyway. This is fundamentally different than having a PRT company design, build and operate an integrated system, which can blur control responsibilities between vehicles, stations, zone controllers, and even control room operators. No customers for anything want to be locked into a single vendor.

The other emphasis is on extensibility. Whereas the ordinary PRT model would have the vendor needing to quickly add staff and production capabilities to service a growing demand, this model minimizes these problems, which would only, in the end, make city officials look bad when they are forced to explain delays and problems to the public. In this model skill sets are organized in a way that allows much more rapid growth with minimal growing pains. The brains are in the cars, more than the track and stations. This is also a more familiar model just on its face, because it is more like traditional roads and automobiles. Hopefully this will make PRT somewhat easier to embrace. The last aspect to mention is that the model is nearly unbreakable. There are no parts that can malfunction that can affect whole groups of vehicles, except the merging track deactivation that I mentioned, and hopefully a better (in-vehicle) fail-safe can be devised.

That’s it. Oh! My laptop has recovered famously from yesterday’s surgery. Thanks for asking…