Guideway Network Philosophy
by
Consider this: Two popular guideways carrying lots of traffic cross each other. Some of this traffic wants to transfer from one guideway to the other. Ramps, or whatever we call them, connect the two guideways, so this interchange should not constitute a problem. However, what happens if a large proportion of the traffic wants to transfer to the other guideway, and the traffic on the receiving guideway is already heavy? We could suddenly end up with a large number of vehicles that could not be immediately accommodated on the guideway. Vehicles would have to be slowed down, reprogrammed, stopped, shunted off or something else. How do we tackle such a scenario?
Replace ”guideway” with ”highway” in the above description and we recognize an everyday situation in many cities. The traffic from two highways join up and saturates the capacity of whatever highway lanes are available. This will surely also be common with any dual-mode system. This example is intended to illustrate an apparent difference in thinking between Reynolds and Turnbull on the one hand and me on the other, as explained below.
To the best of my understanding, Reynolds and Turnbull have in their various submissions on these pages described transport systems consisting of major high-capacity transport corridors criss-crossing the urban landscape, but with only relatively little traffic transferring from one corridor to another. I would submit that Reynolds and Turnbull think too narrowly in terms of highways and their possible replacements. Expecting the number of transfers to be relatively low easily leads to acceptance of an a priori limitation of the transfer capacity. That is, the capacity is severely limited by design and users would therefore have to behave accordingly or accept that their preferred destinations could not always be served.
The need to slow down, reprogram, stop or shunt-off large numbers of cars when traffic gets heavy is, in my view, not a viable option. The practical obstacles seem insurmountable, but maybe this is an issue that needs further clarification. How can hundreds or even a few dozen transferring vehicles be dealt with in case there are no immediate spaces available on the guideway? Apparently contrary to Reynolds and Turnbull, I envision a network of equally important guideways; not connecting endpoints nearly as much as they are covering a surface area; at times also functioning as busy transport corridors, but never impeded by any limitation of traffic going from one guideway to another beyond the guideway’s own inherent capacity.
This kind of system is probably only possible adopting a clear-path operation and control philosophy, and in this respect I disagree with Reynolds’ description of clear-path systems as inefficient, ineffective dictatorships. It’s a computer program, nothing more! And if it does the job required of it – then, what’s the problem?
(For a thorough explanation of the clear-path principle I recommend the one by Dr. Guadagno, posted on the InTransSys webpage under Technical Report: Control.)
This operation and control principle also has the advantage that the entire route and all necessary switch commands can be stored in a vehicle’s computer prior to a trip. Communication to and from a vehicle during a trip will therefore only be necessary in the - hopefully - very few cases where a travelplan has to be altered for some reason or other.
Clarification concerning switches: It is possible that I, in an earlier submission, created the impression, that I favour some sort of active guideway switch. This is definitely not the case, as it would be next to impossible for such a device to change position several times per second. On the contrary, I agree very much with the entirely passive switch that e.g. RUF has adopted, although I disagree with the much too low switching speed of that particular system.
Note on packets/platoons: In his submission of 7/30/01 Reynolds explains in an easily understandable way the reasons why packets/platoons are not a necessity for an LSM-driven system. I can only say that I agree entirely and will not attempt to compete with such clear talk.
Comment on top-down system design: In a 7/18/01 submission Turnbull explains he prefers a top-down system design. This includes developing an operational philosophy, choosing appropriate hardware afterwards. Fair enough, but surely this process should be preceded by a first step: Defining the job a system is supposed to do! User requirements, level of service, capacity and such things. Surely this first step will have a profound impact on operational concepts as well as hardware.
Last modified: August 18, 2002