In an earlier paper (3/27/01) W. Turnbull describes for us an operational concept, as he believes it could (or should) be organized for a dual-mode transportation system. On the same occasion he once more calls out for further discussion of operation and control issues. A principal discussion freed from hardware or specific technologies.

I have no quarrel with the operation and control proposal described. In fact it appears quite ingenious, even realistic if somewhat complicated, at least to the degree that I’m able to understand it. However, any discussion of operation and control issues are bound to be in the context of the hardware and technologies at hand; both with respect to hardware needed for any operational principle as well as hardware excluded by it. The system proposed by Turnbull proves this point.

Obviously the concept of packets (or platoons) that can be split and rearranged on the fly hinges on a great many (most likely vehicle mounted) sensors, just as every vehicle would need their own velocity control system. Hardware that need to be included in the design. The mentioned mechanical coupling devices must be considered hardware as well. Moreover this concept would not be viable if LSMs were employed as propulsive principle, as it would be impossible for an entering vehicle to catch up with a packet, just as it would be impossible to eliminate gaps in the packet, should one or more vehicles demerge from the packet. Thus, Turnbull’s operational concept requires certain hardware and excludes LSM (among others) as an option, and the proposal is therefore essentially hardware specific.

But Turnbull is correct in his assessment that operation and control need to be further discussed. Only is it unavoidable that more often than not will this discussion have to be in the context of a given technology or hardware choice. What is appropriate and advantageous for one system will often be totally inappropriate for or incompatible with another system. I don’t expect (e.g.) Palle Jensen (RUF) to have any interest in alternative methods to avoid (or achieve) split-second full-speed merging, nor will dr. Guadagno (InTranSys) be terribly interested in a discussion on the optimum number of vehicles in a multi-vehicle platoon. The following general observations are intended as merely initial thoughts on the subject and are not intended to be hardware related although they will often be. The observations should also pertain equally to pallet operating system and true dualmode systems alike. At least that is the intention.

One of the first choices we face, when we consider the operation of an automated transit system, is whether to platoon (operate vehicles in packets) or not. I can see five obvious incentives to group individual vehicles into platoons: Benefit from aerodynamic drafting; reduce the number of entities that need to be monitored and controlled; create larger gaps between platoons to facilitate emergency breaking, increase capacity (providing gaps between platoons are not excessive) and finally could platooning to a certain extent eliminate the need for split-second merge timing at guideway junctions. However platooning comes at a price, and if none of the incentives mentioned above carry any significant weight it would be advantageous to operate vehicles in singletons (see below).

Once platooning has been selected will we have to choose between pre-arranged platoons or dynamic platoons created and rearranged on the fly. Pre-arranged platoons (as proposed for FlexiTrain) are easier to manage but much more inflexible, as separate platoons need to be arranged for each destination. An impossible undertaking if a comprehensive network of origins and destinations were to be served by the system. Dynamic platoons (as proposed by Turnbull and for RUF) on the other hand require powerful on-board intelligence and will introduce new complications, as lots of real-time information about upcoming actions will need to be distributed to and from vehicles (or platoons) with split-second precision. Dynamic platoons could however be almost as flexible as individually operated vehicles.

If, on the other hand, we choose to operate vehicles individually (in packets of one!) would we obtain maximum flexibility with a minimum of waiting time for users, a very important objective if we want to gain acceptance from prospective users. Then again: The before-mentioned split-second timing would need to be assured as would maintenance of very short gaps between vehicles if traffic capacity were intended to be high. Emergency stopping in accordance with the so-called "brick-wall criterion" could (if deemed relevant) also be problematic.

Our next choice could be between "managed anarchy" or "perfect pre-planned order." In the "managed anarchy" variant will a vehicle be allowed onto the guideway even if it cannot be guaranteed that it can proceed all the way to its destination. Usually it could, but sometimes will it be necessary to "shunt-off" or temporarily stop a vehicle because there is no available guideway capacity. This concept is essentially identical to the one outlined by Turnbull. Contrary to this will a vehicle in the "perfect pre-planned order" variant only be accepted onto the guideway once a vacant time-slot has been identified and reserved all the way to its destination. This operational concept is identical to the one proposed for InTranSys (among others).

A combination of the two different concepts could prove a practicable solution. E.g.: It makes little sense to "pre-book" a complete coast-to-coast transcontinental trip. Instead will one or a few sectors be reserved in advance and the rest of the trip would be booked as the vehicle progressed towards its destination. Similarly would it be of little use to launch a vehicle onto a guideway (in a managed anarchy system) if bad fortune meant it would have to be shunted off at the very first interchange for need of guideway capacity.

A just as important distinction is the one between wayside intelligence and in-vehicle intelligence. Is vehicle control in the hands of numerous in-vehicle systems and sensors all working together to assure that an adequate level of safety are maintained or is some kind of (wayside) master "brain" responsible for operation of the system?

If in-vehicle systems and sensors are utilized it requires very reliable hardware, probably also duplication and self-diagnostification of many sensors and computers, as safety not only for a specific vehicle but for all other vehicles as well is only maintained if all sensors and systems in each and every vehicle are functional at all times. An impossible assumption, as any statistician could tell you.

It will therefore be necessary to duplicate many sensors if in-vehicle intelligence is utilized, as it must be assumed that at least one of the many thousands (or millions) sensors could malfunction at any given time. The situation will be more or less the same if wayside intelligence is chosen, but as the numbers of sensors, systems and computers are (probably?) much smaller will it be more practicable (economical) to duplicate all relevant systems.

The distinction between in-vehicle and wayside intelligence is more than just a question of where we place our computers, radars and so on. A wayside computer relying on input communicated from vehicle-mounted sensors effectively attains the characteristics of an in-vehicle system despite being physically placed wayside. This leads to another important consideration: Communication vehicle-to-vehicle and vehicle-to-wayside!

Again we must assume that a small proportion of the millions bits of information sent back and forth between vehicles and from vehicles to wayside computers and back will disappear, be distorted or maybe even manipulated by terrorists. What if this lost or unreadable information is crucial to the operation and safety of the system? A lost order to accelerate, slow down or stop could have catastrophic consequences if there were no back up system. Is it practicable to duplicate essential communication between vehicles or from wayside computers to vehicles?

I’m mentioning all these choices and considerations without making much of a conclusion. We all have our own preferences and opinions about important and irrelevant, and will probably therefore all arrive at different conclusions as to what is the best operation and control principle for an automated transit system (true dualmode, palletised dualmode and PRT are more or less the same in this context).

One bit of personal opinion though: I believe it is better to select technologies and hardware that will achieve near optimum operational characteristics from a user viewpoint and then let ingenious solutions and persistent engineering bridge the gap to a practicable system. If we can’t sell the idea to prospective users, what is it all good for then? I prefer we prioritise in that order, rather than expect users to accept services of a lesser quality on the grounds that the operation and control system dictated it.

The intense focus on user acceptance is the main reason why I so persistently argue for a system using Linear Synchronous Motors as the propulsive principle. Yes, I’m specifying a piece of hardware here, but that piece of hardware has a defining effect on the operation and control of the system. LSMs allow (maybe even require) that vehicles are operated in singletons rather than platoons. LSMs inherent and automatic position-keeping allow very short headway between vehicles and do so without any need for fault-prone sensors or in-vehicle velocity controls, thus LSM provides high capacity even without the use of platoons. LSMs are simple yet very efficient. There are other problems of cause, but I’m convinced they can be bridged.

An LSM based system will probably be more practicable if the "perfect pre-planned order" principle described earlier is adopted, providing that the concept is indeed viable at all. Last year (3/00) Jörg Schweizer posted a comment concerning the viability of the "perfect pre-planned order", in which he introduces a little mathematics to illustrate why such a concept could never work. While the example was very illustrative, it was also very simple and the conclusion may be a bit premature. Otherwise the example spells doom for all those claiming their pet project has incredible guideway capacity.

The example made two (related) claims. 1) A user would on average, depending on the length of his trip, have to wait a substantial number of time-slots before entry on the guideway would be possible, and 2) a single stoppage on any part of the network would quickly spread to the entire network, creating total gridlock. The first claim also suggest that a substantial amount of guideway capacity is lost as no one can make use of it unless it is available all the way to their destination. Jörg Schweizer’s example operated with 50% utilization of the guideways, but didn’t consider guideway network design or other variables. The following example will do just that, thus introducing clever network design as an important parameter that will define system performance.

If we imagine a network of guideways where junctions are configured, so that merging guideways are always preceded by guideways splitting into two (an entirely practical and realistic configuration.) This has the effect of reducing the average utilization on the short stretches of guideway between "splits" and "merges" to half what it is on the main line. In our example utilization will drop from 50% to 25%, and the corresponding probability of finding an empty slot in an upcoming merge will increase from 50% to 75%. This will reduce the average wait as described in Jörg Schweizer’s example from 1024 time-slots to slightly more than 26. Helps a lot, but it’s still not enough if we consider long trips crossing an even larger number of junctions.

Therefore will I here introduce short "guideway-sidings" A guideway siding will equal the exact "length" of one time-slot. Thus, a vehicle entering a siding will "drop" one time-slot before returning to the main guideway, and it will also be possible to make sidings where a vehicle could "gain" one time-slot relative to the main guideway. These guideway-sidings were originally conceived by Francis Reynolds (see the HiLoMag paper for a better explanation of guideway-sidings) and were intended to arrange strings of closely spaced vehicles for longer journeys, so that they could benefit from aerodynamic drafting. I believe however that these sidings will be much more useful, possibly even essential, if we want to squeeze as much capacity out of our guideway network as possible. Sidings will simply multiply with a substantial factor the number of possible time-slot allocations available, and the more sidings we build the more capacity (and shorter entry delay) will we get.

Returning to our example: If we place a siding shortly upstream off a merge, will it be possible to let a vehicle "drop" or "gain" if the corresponding time-slot on the other leg of the merge is unavailable. This reduces the probability that we cannot find a vacant time-slot in a merge to approx. 11% and reduces the before-mentioned entry delay to less than 6 time-slots. Moreover, this figure will only increase to 163 if we consider a trip crossing 100 merges (a tenfold increase over our original example). And if we build both a "gain" and a "drop" siding before each merge will our average entry delay drop to near zero while we could attain an average guideway network utilization approaching 50% or more of theoretical capacity (whatever that may be!).

There are however still an unanswered question: Will a single point stoppage aggregate to the network, creating gridlock? The easy answer to that is: It depends! Traffic density at that moment! How fast can the control system reprogram or shunt off vehicles? What is the capacity of exits before they are filled up? How far are exits apart? How many guideway-sidings are there? And so on. Calculations quickly become increasingly complicated as we introduce more variables, but my own simple and amateurish paper models suggest it can be done, so that a stoppage is confined to one or possibly a few branches of a network. Designing a proper functioning guideway network without to many bottlenecks will beyond doubt be a painful, time consuming challenge.

In the last few months have I noticed that a great many in the innovative transportation community consider the so-called "brick-wall-criterion" absolutely essential to any future transportation system, which puzzles me, as our most prominent transportation corridors; highways, freeways, expressways, autobahn, autostrada or whatever we choose to call them do not really abide by the brick-wall-criterion; far from it - in fact.

But what is the brick-wall-criterion actually? Something about a solid brick wall suddenly appearing in front of a vehicle at speed! And it is also clear to me that headway is an important parameter, but how do we define the brick-wall-criterion?

My own home-brewed definition goes something like this – If a vehicle at speed were suddenly and immediately stopped (by ramming a crossing truck with absolutely fatal consequences to all occupants of the vehicle), then a following vehicle would abide by the brick-wall-criterion if it managed to stop before hitting the first vehicle. I would be pleased to hear of it, if anyone knows of a better definition.

But does the brick-wall-criterion bear any relevance to our discussion on possible transportation system for tomorrow? If we consider a car at speed, then we know that it cannot suddenly stop. It can decelerate (brake) but it would take a violent collision with something like a solid brick wall to immediately stop a vehicle. Fortunately brick walls don’t appear in front of cars very often, especially not on a highway. On the rare occasion that they do, in the form of a heavy vehicle crossing the stream of traffic, they wreak havoc amidst travellers.

Highways are restricted access traffic corridors, without crossing traffic or other unforeseen obstacles. This is the basic attraction about highways, and the very reason why they are so relatively useful to us. But they do not abide by the brick-wall-criterion, yet they seem acceptable enough anyway.

Now we consider the construction of new automated traffic corridors, where access will be even more restricted, better managed and carefully monitored. Can anyone explain to me why the brick-wall-criterion has suddenly become so important? Vehicles on an automated guideway can no more than vehicles on a highway suddenly stop! And the rare and disastrous "brick wall" will be an even more unlikely occurrence on an automated guideway.