I want to add something to the discussion of autonomy, which I did not want to have buried deep in comments section. In that post I again touched on the theme of not wanting to have a PRT implementation be performed by a single company. As I was mulling over my problems with the concept of zone controllers, a good phrase for what I think should be avoided came to me…. “vendor-dependant architecture.”
“Vendor-dependant architecture” is what you get when nobody knows how the system works but the vendor, nobody can build the system but the vendor, nobody can fix a problem but the vendor, nobody can get spare parts but the vendor, nobody can remedy cost or schedule overruns but the vendor… The list goes on. In some cases even a continuing, active monitoring of the system is required and must be performed by the vendor into infinity.
Contrast this to a highway. The builder of the highway certainly doesn’t need to be called in if there is an accident. Once it is built, it is managed by the taxpayers through police, wreckers, road repair and street sweeper crews, etc. There is no question of needing the original contractor to come out to fix a damaged sign, for example. It is the safe choice.
With PRT, vender dependence is largely the result of the combined use of a number of arcane technologies. Everything is non-standard in size or use, if not downright experimental. In my view, having a centralized control architecture contributes to this vendor dependency because it essentially makes the track, stations, and vehicles into a single incomprehensible machine.
One thing I would like to see is for at least major portions of a PRT implementation to be a straightforward purchase/contract, with an actual endpoint. The obvious first candidate is the track. To do this, the track must be decoupled from the control system as much as possible. Any electronics or communications should be very easily serviceable.
The cars are the next big expense, and should be contractually decoupled as well. These could be purchased with a service contract or leased. Leasing has a good ring to it because it meters out money to the PRT system vender (or a separate vehicle maker) at a rate that would (hopefully) be proportional with revenue received from fares. Additionally it perpetuates the revenue stream to the vendor, but in a controlled way, helping to ensure that it can stay in business. (Including the repair business) This is obviously a huge concern for a municipality stepping out on a limb to buy a bunch of unproven technology.
Stations, at least as far as the architectural end is concerned, can be treated as an ordinary construction contract. Proprietary standards, materials or methods should be avoided, where possible, so that replacement and repairs may be accomplished by the municipality.
The sticky point is the control system. As recent history exemplifies, even very large companies fail. Who is to ensure that the system will be up and running in ten years?
This is where a “vendor-dependent” design is a real drawback.
Here is the basic problem as I see it. The first is that the system must pass various hurdles related to safety standards. The second is that “vendor dependency” issue. The third is that the communication and sensor hardware is rapidly changing and improving, and often has its own interfaces and software, which must be either bypassed or integrated.
The whole matter can be greatly simplified if a standardized control architecture can be created that can utilize a variety of sensing devices. I envision a system where the allowed velocity of the vehicle is contingent on the degree of consensus between redundant sensors and communications means. Whole sensor systems therefore, straight from the manufacturers, would be able to be swapped out within this general design architecture. If one manufacturer goes under, replace them and their sensors without redesigning the whole system. This design architecture would preferably utilize contrasting technologies with different strengths and weaknesses. Promising technologies include RFID tags, (used in 2getthere’s FROG navigation) Barcode readers, Hall effect sensors, object or color recognition software in conjunction with cameras, radar, ladar, and sonar.
As for communications, I think the “leaky RF cable” concept is hard to beat, especially if it can be done at frequencies that are compatible with wireless LAN protocols, such as Ethernet. I have it in my mind that it would be easy to create “leaky” fiber optics, as well, since “Leaky” fiber is a commodity item, used for decorative lighting. I haven’t ever heard of it being used in this way before, but then again this is an unusual application. Including a channel within the track for such communications is no harder than fitting it for ordinary electrical wire. Of course ordinary wireless technologies such as Bluetooth or even WiFi might be used to some effect as well. One of the benefits to beginning with the assumption that the vehicles can work anonymously is that it allows for some errors or spottiness in communications without adversely affecting the system. This allows use of inexpensive commodity components. It’s a lot cheaper to use a system that is reliable 99% of the time than it is to use a system that is a “mission critical” 99.999% reliable. With communications of traffic data, for example, the messages can be repeated along the way, so if one is missed it’s no big deal. Even missing all of them, the worst that can happen is a traffic jam.
