105> A Voice from the Woods!

I think it is high time we talk about control with a bit more specificity. Here are some thoughts to ponder.

It seems to me that if everything else fails, PRT vehicles should still be capable of getting to the next station, at a reduced, uniform speed, without hitting each other. This implies a certain amount of autonomy. It also seems to me that PRT should certainly have full and speedy Internet, and also be networked for traffic management purposes.

As far as control goes, it gets a little more complicated. Because of safety concerns, certain aspects must be virtually instantaneous. One would not, for example, want to have to call a central server to suggest that a collision is imminent and an appropriate braking routine is needed.

 

Let’s take a look at who needs to talk to whom. Fig. 1 shows the obvious case of vehicle A needing to communicate with leading and tailing vehicles. What is not as obvious is that since this zone of needed communications is constantly moving, a centralized control system has no built-in way to keep the relationship between the vehicles special. A zone-based hierarchy (zone controller) would limit the number of vehicles that are communicating to a better number. (note: It is quite possible that an off-the-shelf Linux-based router can be hacked (in the firmware) to make a serviceable zone controller, something that would address most of my previously stated concerns) However that is all a bit off-topic, because I still do not think one is needed.

In Fig. 2, we address the matter of merges. Here I have used the same red zone to indicate where instantaneous communication is most important, with the blue arrows indicating the lines of communication. Here again, there is a special relationship between a small number of vehicles, and this relationship persists until there is an interchange. In this picture we have four little networks that must have very fast communications. It is not clear to me whether communications with any entity outside of this network needs to be particularly fast.

Here’s where all of this leads. First, as a last resort backup, (hurricanes, terrorists, sunspots, earthquakes, plane crashes) the lines of communication shown in blue must persist, or vehicles will be stranded. This is a big no-no if there is no easy way to exit the vehicle. Also it seems probable that regulatory approval would be easiest to approach with a slow, “failsafe” mode first. So… If we assume that we want such an autonomous mode underlying the rest then what “rest” are we talking about?

I, for one, have not identified any communications other than those shown in blue that need to be particularly fast at all. If that is the case, why not have the rest be internet-based, and take advantage of the existing cellular or satellite infrastructures? Such a scheme would isolate the high-speed from the safety portion of the problem in a way that would seem logical.

The fact is that the lines of communication that we are talking about are not even particularly well suited to normal TCP/IP communications in the first place. If such a task were easy, the military would certainly like to know, for such a thing would greatly enhance battlefield strategies. . Requiring ad hoc “mesh” networks are not great way to simplify a PRT system, in my opinion. It reminds me of my friends daughter, who likes to “text” with her friends, even when they are in the same room, and could simply talk instead. Maybe a better example is a fire alarm that alerts your smart phone instead of making it’s own audible signal.

Surgeons fix things with scalpels, carpenters with wood and nails. Is it possible there is a little of that going on here with my IT savvy readers? After all, working systems have been around since before TCP/IP was invented, based on direct switching and signaling. And, by the way, there is precedent for this in the form of current railroad practice. I’m not so sure where we stand on the other, in terms of gaining regulatory approval.

Don’t get me wrong. I believe that the last 10% or more of optimal throughput will absolutely require an advanced dedicated network infrastructure. This future capability must be baked in from the start. I believe though, that we must be careful not to lump real-time control issues (collision avoidance) with traffic management, which can easily have latencies of many seconds without consequence. I have analyzed what exactly would have to be communicated on those little blue arrows and it is amazingly little – less than a byte each way. If I told you how, though,.. well, I’d have to think of something else to write about next time!