Wednesday, January 21, 2009

17> The Role of a PRT Standard

A good PRT standard would
1. Give all decision makers (city, state, federal) the security of knowing that the system design was not rushed, coerced, short changed, tailored by self-interest.
2. Give those decision-makers the assurance that the design is suitable for competitive bidding in initial construction, expansion, and maintenance and therefore they are not utterly dependent on the initial contractor.
3. Give PRT contractors a vetted design more likely to be accepted by the public.
4. Reduce PRT contractor’s liability risks.
5. Make a PRT project easier to manage and subcontract.
6. Give customers more faith in the system
7. Allow innovation in system components outside of the standard.
8. Be divisible so that variations can be introduced without scrapping the entire standard. (A proprietary car for a standard track, for example)
9. Be designed with altruistic intent, including benefit to the environment, local contractors and other vendors, as well as commuters and the communities they pass through.
10. Be continuously updated
Did I leave anything out? Anyway, A good set of open-source specifications would greatly enhance the chances of a truly ambitious implementation. Let’s remember, a scaled down test will always go from a place where people congregate to different, similar place. In other words, companies with millions tied up in engineering and marketing and testing and selling have to recoup costs by jacking the cost of track so high that only a loop is affordable. Meanwhile cities have to ensure usage by placing stations only in congested areas. Almost by definition, then, a simple shuttle service will always be more cost-effective. Only confidence and optimism can produce a first implementation that is scaled for success.

So what would a first standard be? I would think that the first stage would be (for example) to standardize a track profile, switching and control protocol and weight limits. If there are deep-seated divisions in these matters, there could branching specifications. For example, I outline, in the last post, a method of using external power to lift cars up very steep (to vertical) slopes. A “podcar” designed for the track, weight, and switching specifications but incapable of this adaptation might be called PRTSO 100.2 compliant, but not PRTSO 100.2.5 compliant. A city could look at a proposal and decide whether this would be an issue or not. At any rate, they would know what kind of track to buy.

It is interesting to consider that, for design Darwinism to occur, one needs a number of competing designs. It is therefore not the function of this site to design a single system, but a number of competing systems to see what common threads emerge. None-the-less, it is equally important that each idea be critiqued, as though it is the one and only alternative.

2 comments:

Bengt Gustafsson said...

The main problem with the standard here, which is not present in software or electronics to the same extent is the large development cost before the standard can be validated. In software or data-communications a standard can be validated by being examined by several experts. This is not the case with a mechanical standard of this complexity, which needs in-world verification with inherent costs in the order of tens of millions of dollars. This is my main critizism of the open development effort. Someone must build this test track and that someone must see a way of recouping the investment.

I have suggested previously a different level of standardization which relies on the cabin being detachable from the drive-truck. In this case only the cabin size/weight and its interface to the truch needs to be specified, along with some data protocols etc. The cabin can then be transferred (with passengers) at points where different track/drive truck systems connect.

The main advantage is of course that technical development of track and transportation systems can continue after the first part of a system has been delivered, and that buyers don't feel as locked in with one supplier.

Dan said...

Thanks for comment, Bengt. Sorry I haven't posted a response yet. I have something in the works, and it's pretty good, I think. Good comments call for good responses, and I am measuring my words a little more carefully than usual. Stay Tuned!