Wednesday, December 12, 2012

149> Tower of Babel




All PRT is not created equal. That fact benefits some systems (and proposed systems) and penalizes others. The system that has been evolving in this blog sufferers from this effect more than most because it offers a host of subtle benefits that other systems don’t. But it is also, in all fairness, probably the most expensive in terms of vehicle costs. I did not reject these extra expenses for three reasons. First, highly optimized designs can be scaled back to be more affordable, but designs in which affordability is “baked in” cannot generally be so easily supercharged after the fact. Second, manufactured items get cheaper with more volume and over time and a vehicle is such a manufactured item. Third, it is important to understand how system performance is compromised by various tradeoffs. How do you know if dumbing down a system was worth it unless you know what you would have gotten and what it would have cost if you hadn’t?

I could spend the rest of this post extolling the virtues of a multi-axis system but since that is not what this post is about, I will leave it at this:  A faster system that can perform tight radius and 3D maneuvers is a system that can be adapted to any city’s landscape much more easily. It provides the absolute minimal amount of track per covered area, maximum flexibility in station design and routing, and the fastest trip time for the passengers. (maximum throughput and highest revenue per vehicle/hour.) Thus what is difficult and expensive from a system development point of view translates into unprecedented advantages from a deployment point of view. It puts the customer, (local city and transit entities) the affected third parties (along the routes) and the passengers first.

I have previously written about the desirability of having standards for PRT. Proprietary track, in particular, seems worrisome because it would permanently lock cities into a relationship with a particular PRT company.  I can also see why many people would be very wary of standards, since they are frequently used to gain a competitive advantage (Blu-ray vs. HD DVD) or result in locked-in incompatibilities. (electrical plugs that don’t fit in the sockets in a different country)  Isn’t it WAY too early to start thinking about standards? Yes and no. It really depends on what you mean by “standards.”

When a standard becomes legally codified by an organization, given an ISO number etc., that is the last step of a long process. First, there must be some kind of common language – some kind of definition. Whether it is a description of a physical thing or a process, long before it can be defined legally it must be developed into something that can, at least, be discussed coherently.

This point was brought home by a recent discussion on the PRT innovators site. The subject was a project underway using the Vectus system, which is, by any measure, “standard” PRT. But it was revealed that the track configuration was a simple loop, and so it was questioned whether this is a PRT project at all, since “standard” PRT utilizes a network of off-line stations. Is a PRT vehicle, running on PRT track but only in a loop really PRT? Does an offline maintenance building count? Or is it, perhaps, simply unfinished, since PRT is inherently expandable? Another example is ULTra, where the traditionally assumed PRT model of a vehicle on a guiding track has been replaced by a robocar that could presumably free-roam on any paved surface. Is it PRT just because other vehicles and pedestrians are kept off the guideway?  PRT as a definable concept is becoming more and more vague. If I say “PRT” and I am thinking of one thing, and you are hearing me and picturing something completely different, we have a problem. Once upon a time, PRT only meant one thing to everybody but the formal definition has become increasingly irrelevant as additional contrasting PRT-like offshoots are added to the picture.  At a certain point the discussion needs to shift from the more inclusive “PRT” to those subsets, which themselves need to be better defined. Let’s use the analogy of dogs. Once upon a time, there was only a single general type of dog in a given region of the world and so the word “dog” was sufficient. Over time though, the addition of different breeds added increasing imprecision to the word. Toy Poodles and St. Bernards may both be dogs but making blanket statements about dogs with either as your example is confusing at best. At some point you need to call the breed by name or you are not speaking with clarity. Such informal “standardization” always precedes any type of legally binding definition. 

Recently it was suggested that, since PRT has not gotten very far in decades, it is human nature to interpret this as proof that the PRT concept is somehow inherently flawed, so perhaps the name should be abandoned in favor of something new. The term “ATN” (Automated Transit Network) was suggested. Whereas I think the term has merit, I have to point out that it is just as imprecise as “PRT.” It is unfortunate that “PRT,” “Podcar,” “PAT,”“ATN” or even “APM” (Automated People Mover) are such obscure terms.  When talking to a layman, first one needs to explain the genus, then one needs to explain the species.

A while back, (post 61) I suggested a shorthand system for classifying PRT. With such a system one could better weigh the pros and cons of the various systems generically. Of course there is no governing body to adopt such a system, and it would only be good for academic discussions between people who had already learned it. But there is a problem, it seems to me, when there is confusion between what is an inherent quality of some whole branch of PRT and what is decided upon by the designers of a specific system. Many people around Heathrow Airport, for example, no doubt believe that PRT is a system of battery powered vehicles. More troublesome is the growing army of people who now believe that PRT systems require winter snow removal.  Maybe a downloadable branching -tree type diagram would be a more useful way to start.  

The “breed” I personally advocate is a high-speed Suspended, Multi-axis, Automated Rail Transport network. We can shorten that to a SMART network. (or “HS SMART” network?) This clearly is a very specific subgroup of PRT, and establishing definitions and standards for such specific systems is much easier. Hey, I’m doing my part…it has a generic name! Now, how steep (in degrees) do we need to go to be considered “multi-axis?” Some particularly alert readers are already wondering, “Would systems like MISTER or FlyWay considered “SMART?” Whereas Mister could probably be adapted for completely 3D movement, Flyway has another take, which is a scissoring lift. This means the track doesn’t have to follow 3D routing for the actual passenger compartment to do so. The plot thickens!

Unfortunately, “SMART” only goes so far… It does not, for example, describe the power source, switching, or other important considerations.  Can this “standardization” make the leap from simple classification to defining certain interfaces, such as between the track and the vehicle, so that they may be described in precise enough language that vehicle makers and track makers don’t need to negotiate each and every detail before they can get on with their respective jobs? With all of the options that have been explored in this blog I am gaining confidence that there is some foundation for developing such standardized interfaces, not as SMART per se, but as some version-numbered subspecies. The trick is not to stifle creativity, innovation, or profitability in third party implementations while also ensuring that the project can’t be easily coopted into a fully proprietary system monopolized by a single company. There is considerable precedent for such “open source” standards in the software field.

As for PRT generally, though, I fear ever more confusion as spin-off and hybrid systems continue to blur the lines. Making the case for PRT has always required a patient audience because it is a synergetic combination of ideas that, if taken separately, are not particularly revolutionary. Unfortunately, limited startup capital forces equally limited implementations of PRT, redefining the technology downward in a quest for affordability.  In a perverse reversal of the “divide and conquer” strategy, we divide PRT into so many flavors that it is no longer distinguishable, even to ourselves. Alas, here we stand, like the confused architects of Babel, wondering how to advance, when we cannot understand each other, let alone pass along our vision. Classification, definition, and yes, standardization. It’s all about communication. And so is persuasion. We really need to sit down and assess, in this day and age, what it will take to put our collective best foot forward.

I wish I had the answers. Not only does the quest for affordability put practical PRT designs into a race to the bottom, capability-wise, but the PRT community is very forgiving. After all, this is a needed technology that must be encouraged, right? The problem with this approach is that it doesn’t separate conceptual pipe dreams or inherently handicapped designs from those that are more capable, practical or whose engineering is farther along.

Maybe it’s like politics. Lesser candidates can’t get too deep into specifics or their flawed platform will be revealed, while the better platform, if revealed in too much detail, will only confuse the voters and invite FUD. (Intentionally spread Fear, Uncertainty, Doubt)  Better, perhaps, that we do what politicians do, which is hone a simple, more thematic message. We can describe the results, rather than the means, at least when explaining PRT to a newbie. Keep it “back-of-a-business-card” simple. But meanwhile we need to have real answers on the tips of our tongues for those who want detail. We need to be able to recite the generic pros and cons of suspended vs. supported, track based vs. free-roaming, etc. Without some standardized definitions, the weak will continue to pull down the strong, and policy makers will continue to throw up their hands in confusion.  

2 comments:

cmf-seattle said...

"PRT is a service mode, not a type of network... " I remembered him saying "not a particular technology." (Scroll down for an interesting discussion of X intersections and headway vs. capacity).

So, "PRT" (et. al.) means traveling with others by choice and not having to stop mid-journey. How that's accomplished hasn't really been worked out, yet.

Also of interest:
http://ianology.wordpress.com/1999/01/25/prt-switch-design/

Dan said...

Dan the Blogger responds...
Thanks for the interesting reading, cmf. If I am not mistaken, that "Brad Templeton" fellow who Ian was responding to is a fan of robocars over PRT. Although I disagree, I have to say I generally side with him on the dumb networks/distributed intelligence part of his argument. I just think robocars have in inferior form factor for the problem at hand. An interesting question gets raised by that first statement though... If robotaxis were to pick you up at designated taxi stands, wouldn't that, by his argument, constitute PRT?

I really liked reading his thoughts on what should and shouldn't be initially included in a system. Coincidentally, I was just writing a post on extensibility and forward compatibility, so this fits right in. I was getting ready to make some of the same points.