Critique of the InTransSys Dualmode Concept

by  Joerg Schweizer

February, 2000

The development of InTranSys has begun in the 70's, probably as a reaction to the oil crises. It is therefore built for the problems at that time (shortage of fossil fuels) and it has been built with the technology that has been available at that time (synchronous motors). And I believe that InTranSys, once installed, is still a lot more energy efficient than the car and I think at least the concept is almost perfect for heavy and large goods that need to travel over long distances. And it probably makes some sense in the US, with its sparse heavy rail network.

But I'm asking myself if it is necessary to built up a nationwide InTranSys "just" for the purpose of heavy freight? I said "just" because if you open a truck you will find in many cases in carries freight pallets. Therefore, not all trucks that you see on the highway are heavy freight but freight that could be distributed in smaller units by smaller vehicles.

And let's say it clearly: InTranSys is a monster guideway with piers of approx. 3m (9 feet) diameter, 11m (33 feet) height, and a total width of 20m (60 feet) built for carriers of 12.000 kg !! A simple diverge is several hundred meters long! How much energy will you spend per km just for building it? Maybe less than for a 3 lane freeway, but freeways do already exist.

With regard to passenger transport, I do not see InTranSys as an optimum solution. Because people will still drive their car into town and will leave it there in some parking space. And, how extensive will be the grid inside a city ? Even if the grid is dense (neglecting visual intrusion problems), don't you think that you are putting huge capacities with huge guideways in streets where such a capacity is not really needed? And, the construction energy required would be high.

Then I do not think that it is such a good idea to move an InTranSys carrier of - about- several 1000 kg (I did not find more precise data) and a car of approximately 1000 kg for the purpose of transporting one person of, say, 90kg. This, in my opinion, is not energy efficient. You need considerable energy to accelerate all that mass during start up and for each maneuver ...and you have to build all the heavy carriers for all the cars and SUVs in the fleet.

Finally, the synchronous control, which is robust, simple, reliable, etc. as long as you have one line of track with carriers on it. But as soon as you have an entire network with interchanges and even different speeds you are in deep trouble. This is not only my conclusion. This is also what Jack Irvine wrote in his PRT book a couple of decades ago: the concept of predicting the entire traffic on the InTranSys network of California for a range of several hours with a precision of 3 milliseconds does not seem plausible to me. Just the fact that you need to accelerate a 36,000 kg (triple carrier) to 200km/h at such a precision is at least problematic. And what happens if the high power semiconductors quit working (e.g. burn) just at the moment when you would like to fit an accelerated carrier into a group of fast moving vehicles on the mainline guideway?

Furthermore, all carriers are constantly controlled by a central computer (this also this sounds like 1970's technology) that is connected by a digital communication system. Do you know the time it takes for a data package to go from the carrier to the central computer, be processed, and resent to the carrier? Even if you have a line that is super-fast and does not need error correction, the time that the algorithms take for the computer to process the carrier data is hard to estimate and certainly not constant with time. Remember there is not only one carrier but thousands. I'm not even sure if you can do the routing for one carrier, because routing is very time consuming (it's essentially a search process) and when you are finished the time slots are no longer located where they were when you started routing.

If I understand correctly the logistics of the system, then there might be a serious problems as well that are linked to the problem that you need to know everything exactly in advance:

Imagine the situation that one branch of the network is blocked for some reason (electricity blackout, vehicle breakdown, communication interruption, etc.) and no carrier can enter this branch any more (because it is blocked by the last carrier which entered and got stuck as well). In this case, following the logistic rules, the upstream vehicles that intended to diverge into the dead branch are rerouted ( by the central computer and hopefully in time) to exit at the first downstream stop (the one on the working branch). Now, if all the upstream vehicles are accessing the this first stop, it will fill up quickly. In this case, vehicles try the second stop and so forth.

But what happens if the track between the first and second stop has already been allocated by another carrier before the (other) branch went down. In other words, it is possible that the upstream carriers do not find a time slot to exit at one of the downstream stops! And this possibility is quite high on a busy network. What happens is that if only one of these carriers does not find a slot, it must be braked and stopped. But as a consequence, all upstream carriers behind it must halt as well. Clearly, the upstream branch is blocked ! And this means the back-propagation condition is satisfied, because what happened to the first blocked branch can also happen to the newly blocked upstream branch and so on...

In conclusion, if you have dense traffic on your InTranSys network, the probability is high that a block of one branch results in the deadlock of the entire network.

In my opinion, the only way to get finally rid of these timing problems is to introduce buffers at all interchanges. But this might cost some $$, considering the dimensions of the InTranSys guideway.

Another solution is that you allow for slot slipping. But this would mean having to throw away all the conveniences of a synchronous control system.

Sorry for my pessimism but this is the picture that I have gained from reading about the InTranSys in its current state of development.

Last modified: August 18, 2002