Pre-Platooning and

Fixed-Origin/Flexible-Destination Pairs

Several comments have been made about problems associated with pre-platooning. These are thought-provoking issues, which need to be addressed by a Dual Mode system designer. Among them are:

Brian Dudson:
I also thought the very high capacities mentioned would require pre-platooning. I now believe (and hope) this is not the case, as pre-platooning greatly increases the complexity of a system's operation. (Say a mature guideway network had 50 exits, then, theoretically, it's necessary to form 50 platoons at each entry.

Remember what Dual Mode sets out to do:

Primarily, it enables safe and congestion-free point–to–point transit without leaving the vehicle.

Equally important, it does this while requiring only construction of the automated backbone – the endpoints of the journey are undertaken on conventional roads. Thus in an urban environment it is not required to construct a dense network of automated guideway. The maximum extent of the catchment/delivery areas is determined largely by the vehicle itself – for a small electric vehicle this might be quite limited, but in the order of 50km across.

Dual Mode’s other important function is to provide certain critical sectors of the journey under automated control. This might be required where congestion would otherwise easily occur, or over a hazardous stretch of terrain. For local, uncongested, short trips the car as we know it does just fine.

So Dual Mode uses the same metaphor as the existing highway system: a hierarchy of local roads collecting to a node, which acts as a better conduit to the delivery node.

The existing highway system is starting to fail in terms of capacity and desirable safety goals.

A successful Dual Mode deployment can be seen as a step up in the highway hierarchy, a kind of Super Highway complimentary to the existing highway system. This fits in with the notion that only the last few percent of traffic needs to be removed, to greatly improve traffic behaviour. It also provides a credible path for gradual implementation of the new system.

Pre-platooning sits well with these concepts. The automated sector is a kind of suspended animation, and the commuter is deposited on quite a coarse grid, in the vicinity of the desired destination. That the destination has to be pre-selected is not much different from entering a highway onramp. If you made a mistake, take the next off ramp and revise your travel plan. (FlexiTrain vehicles will be fitted with SatNav, which will make it easier for users to plan a journey, and navigate to and from guideway nodes. Entering a destination into the system would return step by step guidance to the departure node, and further guidance from the drop-off point.)

The question remains: how many destination slots should be allocated at the departure point? 50? 100? This could quite quickly become a real estate nightmare. The answer is: far less than you think. Take the 25km radius from the example above. There are few cities where anything near those numbers would be required. The biggest conurbation on the planet, New York, can be traversed and serviced with two O/D pairs. Distance is not the limitation. The destinations would be determined by desirability of location, and traffic management requirements, only.

In one FlexiTrain scenario for Auckland, independent travel was limited to only 10km. To serve the roughly 60km x 30km Greater Auckland area, you would need only six destination slots from each staging area. There was no congestion anywhere in the 2020 projection. Compared with the present three-hour mess at peak times, this is pretty amazing. Of course, once you realise that 12 000 vph have been removed from the traffic, into a single BRT/HOV lane, it all seems pretty obvious.

What is of equal importance is: what happens at the destination? A traffic nightmare awaits a Dual Mode system disgorging into the destination node at system peak capacity. FlexiTrain permits the destination point to be slightly altered according to traffic management feedback. All that is needed is a pre-empted red traffic light somewhere on the street near the destination, and the platoon dissolves, letting individuals proceed. It turns out to be a very powerful management tool, to be able to stagger arrivals slightly in both time and space.

In the Jetsons scenario, you would set up an appointment across town one week hence. On the day, your Personal Digital Assistant would start interacting with local traffic management software via the Enhanced Web. Anticipating a build-up of traffic two hours before you are due to depart, your PDA will download a best-guess route schedule and tell you to leave five minutes earlier. Your (wrist-borne) PDA will upload to the vehicle via Bluetooth link, all the information relevant to the journey, before you set off down the road. Having been SatNav guided to the best departure node, you sit back and let the platoon do the rest. The lead vehicle will interrogate each vehicle’s itinerary, and communicate with Traffic Management regarding routing priority. The platoon will leave the dedicated guideway and be dissolved at the least congested point nearest to the aggregated destinations. You would drive to a pre-booked temporary parking slot, and arrive with enough time for the cup of coffee you programmed into your trip preferences template under Business Meeting / Nose to Nose/ High-powered/ Minimise Trip Stress.