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.
14 comments:
http://en.wikipedia.org/wiki/Automatic_Equipment_Identification
========
imagine the leaky RF cable as a chain; there'd be a tag reader where each pair of links interconnects.
as a vehicle passes, a reader waits to see how long until the next downstream reader reports the vehicle's passing. the reader can use that info to vary the leaked frequency in its upstream cable segment.
for merge points, the frequencies on the 2 approaches can be compared and adjusted, as appropriate.
Dan the Blogger doesn't get it...
Cmf, I’m a bit confused by the varying the frequency part… Is the cable discontinuous so the reader can take in one frequency and the change it? In fact, I guess I don’t get it at all. I understand the concept of measuring the time between “markers” along the track. That is just a basic servomotor feedback loop where the track and RFID tags act as the encoder. But why not have the reader in the vehicle, since that is where the motor speed adjustment is to take place?
All that is needed to merge, in my view, is a common clock signal. Vehicles can be programmed to align themselves with track markers on the strobe of the clock. The markers are, say, 10m apart. The markers on merging track A are at 5m, 15m, 25m. 35m etc. (measured from the merge point) The markers on merging track B are at 10m, 20m, 30m, etc. This way if the merging vehicles are, indeed synchronized with the markers and the clock they will weave together with perfect 5m spacing. The tricky part is when the traffic is thick and there are unequal numbers of merging “partners”. Then it would become necessary for the cars on the more heavily trafficked track to form clusters and spaces. Whole different topic, that one….
in effect, yes, the leaky cable would be physically discontinuous. i should have been more clear about the fact that the reader also encodes the info in the cable's signal. comms across the cable would be the primary method by which the guideway informs the vehicles. varying the frequency serves as a backup: the absence of a signal is the failsafe, higher frequencies indicate suggested speed. garbled data doesn't have to result in emergency procedures.
http://en.wikipedia.org/wiki/Continuous_Automatic_Warning_System#Technical_details
regarding merges, you and i are describing the same thing, except that if a vehicle isn't lining up correctly, frequency adjustments could allow more flexibility in avoiding a collision without resorting to an emergency stop. if communications are garbled, at least one of the two leaky cables (lining both sides of the guideway) would likely still be able to signal to other vehicles what speed will allow them to avoid a collision. if that fails, the vehicles should react to the lack of a signal by slowing to ~3mph. if the two signal frequencies are far enough apart, the vehicle should choose the slower one and report the fault.
on long stretches of guideway where line-of-sight is possible, other means of obstacle detection would probably be satisfactory (especially considering that they'd be useful as a backup for all of the above).
http://en.wikipedia.org/wiki/Continuous_Automatic_Warning_System#Technical_details
That should work nicely. I hope it wouldn't add significantly to the track cost (RFID detectors seem to be the most expensive component).
Dan,
On signaling:
I really like your analysis here. What do you think of making the signaling system completely wireless and not worrying about incorporating it into the track design? Would it be possible to have a redundant mesh network between cars and also a local wifi network so that the entire network would also be connected through the ground stations? If you give each car enough computational power to negotiate merging patterns this method should not pose much of a threat.
On Standards:
I think it is time to come up with some ideas about important criteria for a successful PRT system. We could start with track costs per mile. Safety should be second followed. Throughput should be third.
Is there a contest of any kind where different companies can submit proposals as to why their ideas are proven to be better than the others? Why don't we do that and get some sponsorship money for it??? I would bet that urban planners would pitch in to make this contest interesting.
On Speed:
In order for tracked PRT to work we need to figure out how to deal with peak loads without jamming.
One of the biggest problems of PRT systems is that they have inherently low traffic. I disagree with your statement that there should be a slower version for urban settings because the only solution to the traffic problem is increased mean speed. We need these vehicles to run over 80MPH in urban centers just to empty the lines during peak demand.
Getting serious:
Is anyone interested in trying to build an incentive structure into this site where contributors are able to benefit from the upside in some way? Anyone want to team up for the MIT Ignite Clean Energy contest??
I like the failsafe part, cmf, especially because it requires no microprocessors or other complex gear on either end. The traffic status is encoded and decoded by the same principles as enable the keys on any Touch-tone phone. (For any electronics hobbyists out there, it can be done with two eight-pin chips, a 555 to generate the tones and a 567 to decode them) Anyway, such a failsafe seems like a “must-have” in any system. It could cut power to the rails in the event of failure.
Most train control systems were designed in response to the long-held supposition that the moving vehicle can receive but not send communications. They are also mostly from an age before packet-based digital communication protocols. Back then messages from many sources would be indistinguishable from each other without giving them each a separate frequency or timeslot. These technologies seem perfect for backup systems to deal with computer failures in the system.
I am not sure I like the rest however. Putting the readers in the track and the tags on the vehicles presumes that the vehicle can’t broadcast, so it needs the RFID tag to do it. Using a bunch of in-track equipment to interpret and then hand off messages that could be a straightforward two-way communication seems needlessly complex.
Also the information capacity of the tags and their less than stellar reliability seems ill-suited for any critical function. If the main function is to get a foolproof velocity reading the same thing could be done with a simple magnet/reed switch arrangement, couldn’t it? I am also confused about the discontinuous leaky cable. I mean, isn’t the whole point of it to be a continuous medium that can be accessed for incoming/outgoing messages along its length? My gut feeling is that we need a good, fat, two-way data pipe. You never really say how long these “segments” are. Is this a second system just for junctions, or are you proposing cutting up the main com line? Anyway thanks putting some concrete ideas forward and making us think. I need to, at some point, make a table of ALL functions, potential control means, and backup/failsafe systems to see which technologies best fit, since many systems would probably piggy-back on other’s equipment. Maybe this summer when I get to the cabin…It seems like good pencil and paper work.
Alfransen, How are ya? I think I addressed your comment above. We don’t know how many RFID readers Cmfseattle has in mind, plus it sounds like it’s more than just readers.
Ben, I have an email for you that I never sent… mostly raging against the authors of that article (we’ve all read it) and that cartoonist I will not even mention by name, lest I up his Google rankings… I’ll try to dig it up and send it along soon.
Signaling – I would use the most up-and-coming and widely used protocols because the equipment will be cheap and widely understood. There may be problems with regular TCP/IP that limit it’s usefulness for real-time, mission critical uses, though. It is so ubiquitous, inexpensive and easy to use, however, I think it has a central role to play. I would not mind it doing almost all of the work, as long as the system could work at, say 70% efficiency on backup. I hesitate to speculate on some of this because it is evolving so rapidly. They are currently using that “leaky-cable” technique and repeaters to extend the range of Wi-Fi in big buildings for example. On speed – When I was talking about slower speed downtown, I was referring to the limits of physical comfort for the riders in a landscape of sharp turns and short rides. If you’re just cutting through, that’s a different matter.
It is not true that higher speed means higher throughput. With the same level of safety you get a max throughput at a rather low speed. At higher speeds the unavoidable differences in deceleration rates between adjacent emergency braking vehicles will increase the allowed headway while at lower speeds the vehicle's own length gets more important in the equation.
For typical values for reaction time, vehicle length etc. the optimum speed is around 20 km/h. As it happens this is also a typical maximum "comfort" speed in the curve radii you would expect in an intersection inside a city. This has the advantage that for a roundabout or cusp type of interchange you actually have more capacity where it is needed, i.e. between the merge and the succeeding diverge.
I understand what you are saying, Bengt, and it is a subtle point that many readers may not have thought about. If you have to increase the spacing between vehicles for faster speeds, then the number of vehicles passing a given point will not increase with that speed increase, as expected. But this is simply accepting a bunch of limitations without trying to change the underlying causes. If a cause is reaction time of brakes, let’s improve them. If it is crash-worthiness, let’s improve that too. Ride comfort, regulations…same thing. I can accept that there is an intrinsic speed on very tight turns but this only makes me want to change that radius if possible.
I can only speak about what I know, and that is U.S. traffic. We have suburban sprawl and choked freeways. The neighborhood “shortcuts” are also packed. I am currently getting stuck daily in traffic jambs that are 30 km from downtown. (where the traffic is not a bad problem, by the way) Here in the fast growing “Sunbelt” States, things are pretty spread out, so 20 km/hr sounds very, very slow. The key here is to connect the various hubs of development, especially where freeways cannot be widened further, perhaps adding a loop or two in each hub. These hubs tend to be about 4-10 km apart, and bring freeway traffic to a halt. It is very hard to get anywhere without going through at least one, but between these bottlenecks the driver can usually go over 100 km/hr. In other words the headway/velocity “sweet spot” you speak of is not so sweet for our newer, fast growing cities. I recently took a virtual tour of both Stockholm and Houston to compare the two via Google’s “street view” feature. Wow. What a difference. Just try and find a pedestrian, housing, or stores in downtown Houston. People come to work in the buildings and go back to the suburbs to do everything else. Maybe it’s the price of gas, which is currently .521 euros/liter.
Nice comment Dan. I agree with your approach. I would like to work with you to assess the "theoretical maximum" for speed and throughput while looking at the ride cost for each type of theoretical system. Anyone in? Dan, if you post this maybe we can get people to contribute.
Best all!
maybe we're asking the wrong questions. maybe, instead of asking, "How to keep the speeds up?" we should ask, "Why live so far from work?"
isn't it just that most people in Houston place a higher value on type and size of home than on that home's location? if you make it easier to live farther away, won't folks just max that method out, too (latent demand)?
however, if people really would be willing to pay more for an un-congested commute, then there's your biz plan; take it to a VC firm, but don't call it "transit."
a PRT system should reward those who are willing to change their behaviors. its potential is the ability to provide a better carrot than current transit.
then again, maybe high-speed PRT can also be low-cost PRT; that'd be a nice surprise.
I don't think autonomy is going to solve your vendor dependence issues. All of the vehicles would still need to talk to each other, and that system would, at least at first, need some very specific development.
Also, there is not the same intrinsic value in getting away from a single vendor with software as there is with hardware. Do you really want a custom piece of software built for every PRT system?
No, with software, the more important consideration is making sure that whoever the software vendor is, that does not drive the choice of hardware, or if you're making compromises, leaves you with a number of options.
The control system is essentially the operating system of PRT, and
truth is, there is no case I can think of where compatible operating system of any type has thrived as multi-vendor. The only question is whether it was free or charged for. Linux and Java are not multi-vendor, they are free software from a single vendor.
So, that leaves you with the possible objective of having a free
operating system for PRT. I commented on another article, where I suggested some improvements to your open-source licensing. If you do that right then maybe the basic kernel of the control systems communications could be free and standard and then one company could provide the vehicles, one company the wayside controllers, and another the central systems.
Also, by the way, I don't think leaky fiber is very practical. Fiber requires very tight tolerances on the transmission and reception of light. Any break in that is going to radically degrade it's usability, especially if being read by a vehicle travelling 40 mph.
If you really needed fiber then I'd probably use leaky RF and have fiber optic repeaters along the line that pick up the RF signal and transmit on the fiber. But then, not sure why you'd need fiber, the only thing of great distance would be the central systems, and those aren't doing anything so time sensitive that fiber vs. RF latencies would affect the outcome.
Probably best to just stick with leaky RF and have the wayside controllers be the fiber repeaters.
Bengt is right about maximum capacity at lower speeds. But all this means is to do the turns off a low speed ramp but form a group for high speed running. Implied is high speed has better alignment so there is a place for both roundabouts and interchanges in the network. Perhaps two levels for through traffic and a third level for the turns/roundabout.
Post a Comment