Friday, June 19, 2009

38> The 16th Rule

I was considering my response to alert reader cmfseattle’s comment on my June 7th post when I got to thinking about this addition to his comment. “Rules of engineering” (NIH) and what I was about to write seemed to warrant a post of it’s own and so here it is:

J Edward Anderson, for those who don’t know, is sort of the “grand elder statesman” of PRT. He holds patents, has written books, countless papers, and currently heads up PRT International. One of his papers is “15 Rules of Engineering”, and rule number 9 is “Recognize and Avoid NIH (Not Invented Here)”

So am I just re-inventing the wheel? A quick look at PRT patents would tend to support that case. Here is just one sample illustration. Look familiar?

Well here is my defense. Dr. Anderson left out one rule, one that I will call, “Think Super,” and it goes something like this.

All designs come up against natural constraints such as the laws of physics, social preferences, budgets, time, etc. All designs also carry the limitations implicit in the definition of project itself. Dan’s sixteenth rule of engineering would caution against accepting such restraints without being absolutely sure that there is no simple way to work around them. For example, how big should a PRT vehicle be? Answer. Somewhere between microscopic and celestial, until some factor forces constraint. I know what you’re thinking… (OK, not really…) “If it’s called “Personal Rapid Transit” It should be sized for its purpose, say big enough for 4 adults.” By that logic, it should be sized for one and one only. After all it says “personal”. But are we not designing an automated parcel delivery system where the parcels are people? If all else is equal why exclude the possibility of delivering anything? Now before someone starts writing about the downside of cargo delivery, understand that this is just an example. The downsides that that writer would list would be the constraints I have spoken about.
It is an unfortunate side effect of the profession that engineers are tasked with creating a design from decision-makers with time and budget constraints of their own. I know few engineers with the guts to really think “outside-the-box” in the critical initial stages of a project. Limiting the objectives of a task limits the work involved and speeds completion. That’s sound business practice in most cases but it leaves improvement for later models, making for slow, evolutionary change.
So why re-invent PRT? Because all of the designs I have seen are constrained, not by what is possible, but by what is expected. For example, 95% of PRT is track. It’s the permanent part. Yet it seems to me that precious little time has been spent considering the final form and function of this potentially enormous investment. To my knowledge, I am the only one (or at least one of precious few) suggesting designing-in the capability for carrying modernized street lighting and utilities or having a configuration that could be adopted for use in a warehouse. If functionality can be designed in with no additional cost, why not?

Near my camp in New Hampshire there is bike trail utilizing the remnants of a railroad track that went all of the way to Boston. It was built, however, for smaller trains than are standard today, with narrower track and bridges. Its present use speaks for itself. How did this standard get on the wrong side of history? How do we avoid making the same mistake? In a discussion about an existing PRT design I was reminded that vehicles need not corner quickly because it would buffet the passengers too much. What about a trip to the hospital or freight delivery at 3 am? Or repositioning empty vehicles? I was reminded that all of the vehicles travel at the same speed. Why? I will remind the reader that for most of the history of PRT, control without crashing was the issue. I think we’re moving to a place where the cars can have the intelligence to follow a much wider menu of directives.

So this is my philosophy on designing a PRT system. How fast? Lightning fast. How steep? Vertical. How tight the turns? On a dime. I say, let’s design SUPER PRT first and then back off from there, as required by current constraints, rather than putting time, thought and money into designs that perpetuate limitations simply to expedite a business model. Don't get me wrong. I have nothing but respect for the people trying to bring this technology to market. I just want to prevent track coming down in 20 years because better, newer systems and new uses require a slightly different design.

Lastly I would like to point out that I am endeavoring to create a set of standards first, not a set of blueprints. As I envision it, these standards would be useful for future designers, inventors, contractors and their customers as a means of simplifying navigation in a sea of complex functional concepts. Prioritizing the above-mentioned constraints inevitably leads to differing opinions on design options, and so a natural branching occurs. Such a branching has already occurred regarding PRT vehicles which hang and those that don’t. Have we ever really defined the trunk from which these branches emanate? Or are we just going to let it be defined by Wikipedia or Webster and design from that?


Anonymous said...

First I had difficulty seeing what you're saying. But this clarified it:

"So this is my philosophy on designing a PRT system. How fast? Lightning fast. How steep? Vertical. How tight the turns? On a dime."

I completely agree with such approach. But that alone is not enough. We also will need the business plan side of things, and funding. Once someone gets through all the hurdles, the mix will be obvious. It always is, in hindsight.

I seriously doubt an open source approach will be able to pass the business case hurdle. You can make a perfect plan and hope a company picks it up. But they won't think the way you do. Therefore, they will mess it up, one way or the other. So Dan, how do you think to solve this?

Anonymous said...

The link to "15 rules of engineering" fails.

Please edit, taking the prefix away, if you can.

Anonymous said...

It is somewhat sad to see J. Anderson writing:

"emotionally “locked in” to one approach as
others point out superior alternatives. All too
often such a designer causes more harm than
good in advancing a design."

Isn't this what has become of Taxi 2000, exactly?

(Disclaimer: I don't know the US background or current state well enough. But this is how it seems to me.)

Nathan Koren said...

Actually, I'm afraid that I very much have to disagree with this approach. Designers must always make trade-offs as part of the optimization process -- particularly with respect to cost -- and it is essential to know what, exactly, you are optimizing for. This is a point where *many* PRT ventures, in my opinion, have gotten it wrong.

Let's start with a basic principle about complex networks: they're inevitably heterogeneous. The internet is comprised of both low-speed and cheap modems, and high-speed, tremendously expensive fiber-optic backbones. Your brain is comprised of both dendrites and axons. Your circulatory system is comprised of both capillaries and arteries. Conventional transit networks are also divvied up into feeder infrastructure and arterial infrastructure.

There's a good reason for this: complex networks must accomplish multiple objectives, which in many cases mutually exclusive. Arteries are tasked with rapidly moving large quantities of blood from your lungs to your brain. Capillaries are tasked with diffusing small quantities of blood very nearly to the surface of your skin. The two functions are aiming for fundamentally different goal posts: on one side, you have speed and capacity, and on the other side, you have flexibility and pervasiveness. All of those objectives cannot be optimally met by a single system: rather, the only way to do this is to develop differentiated systems - each optimized for different conditions - which are highly interoperable.

I've made this argument many times in person, and probably ought to write a more formal paper on the subject, but here's the gist of it: transportation networks have two fundamentally different goalposts. As with biological circulatory systems, one set of goalposts relates to speed and capacity - and too many PRT designers have been seduced by trying to optimize for these criterion. But the other equally important set of goalposts relates to flexibility and pervasiveness - and, most importantly, economic viability at the lowest possible capacities.


Nathan Koren said...

That point is worth emphasizing for two reasons: 1.) It's not very sexy, and people tend to undervalue its importance, and 2.) It's the objective which is currently the least well-served by existing public transport systems; consequently, it offers the most promising niche where a new technology can take root. Therefore, this is the objective towards which I am constantly pushing my own PRT development efforts. If very high speed and very high capacity are your primary concern, there's already a technology which arguably does that: it's called a train. If you want pervasiveness, accessibility, and cost-effectiveness, then you've got to have PRT. If you want both, then the way to do that isn't to develop some middling compromise between the two, but to actually do both - just like any other complex network.

In the future, it may well come to pass that PRT vehicles become interoperable between (relatively expensive) high-speed, high-capacity infrastructure, and (very cheap) low-speed and flexible infrastructure - just like the same blood cells or data can operate in diverse conduits. Or, some sort of transfer may continue to be required. One interesting thing that will happen, as PRT systems begin acting as feeders for high-speed rail systems, is that it will actually improve both the speed and capacity of rail, as larger station spacing and off-peak-hour operation becomes more viable. This will make it harder to develop a non-transferring integrated network - but I'm okay with that. As long as each end of the system does its job, a brief transfer is permissible. (Your brain works perfectly well, for example, despite the synaptic gap.)

So in conclusion: if you try to optimize for all variables, then you'll inevitably have to make compromises which put you squarely in the middle of the field, unable to make it through either set of goal posts. That's a bad place to be. Better to select a single consistent set of goals and figure out how to accomplish them, mindful of how you also want to inter-operate with other systems that are accomplishing entirely different sets of goals.

Bengt Gustafsson said...

Regarding Nathans comment, it is of course true that it would be very hard to meet all objectives with a single system. But it is not only the infrastructure that needs to be different for a long haul, high speed system and a cheap suburban system. The drive system also has different requirements. To handle this I suggested a container-like approach, which is described here:

Dan said...

Dan the Blogger Responds-

Thanks Akauppi, as always.
I do not count myself as a business guru, nor do I consider anything I have proposed to be a business plan. I’ll let others worry about that. As was so wisely observed in that essay you posted, great ideas are completely different from great business models.

The link works now. Thanks.

I do not disrespect anyone for his or her take on what constitutes a product or business plan. I have a certain differences of opinion, that’s all. There’s also about 95% common ground.
I would also point out that I am not privy to the critical details of the LIMs they use for propulsion, specifically, their electrical efficiency and weight/power ratios. Don’t forget, their systems are pretty efficient compared with what I originally started with. (Chain driven) I have assumed that there are inefficiencies due to the comparatively large spacing between the LIMs and their reactor plates, compared with a rotary motor, and that maintaining those spacings limits turning radii. That’s a lot of assuming, so I’ll remain humble. Also, the wheel motors, which I favor, are very new to the market.

Dan said...

Dan the Blogger continues-

Nathan, thanks for your thoughts. I agree to some extent with what you say, though I don’t really see it as conflicting with my point. I see it more as a cautionary addendum to what I have said. I did not suggest creating a business plan around a “Super PRT” design, just not precluding ideas unnecessarily. I think you specifically misinterpreted my comments on size, which were ill chosen. The obsolete train track could have equally been too big, not too small. The point is that the designers built a single purpose system dependent on a single product, when adding six inches of width would have created lasting value and opportunity. About the PRT size, (and other design considerations) I talked about pushing the limits “until meeting constraints” You assume that that is code for compromising the objects and advantages of PRT. For the record, those “constraints” in my opinion, limit PRT size to the absolute minimum required for ADA compliance. I would like to see load capacities of less than 750 lbs. And when I speak of freight, I’m talking about the possibility of light freight, maybe private “pods” probably just at night. In other words, when I talk about being creative, bumping hard up against “constraints” and then backing off, I really mean it about the backing off part. I do not want to design a “Swiss army knife” system with oddball capabilities that negatively impact the main functionality.
I have to take issue with one of your points though. That is your coupling of “speed and capacity” on one hand, and “flexibility and pervasiveness” on the other. Why couple speed and capacity? In most mechanical situations, like transportation, or even nature, those two are traded off against each other. (bees vs. elephants, high gear vs. low gear, etc.) Does PRT need to be slow to be flexible? Or pervasive? I would say that PRT which can be fast would be more flexible and therefore more likely to be pervasive.

I would point out something here, which many readers might not know. That is that electric motors draw more power under load and essentially no power with no load. They do this so well that they exhibit tremendous torque at start-up (especially compared to gasoline engines) yet can have very strong high-speed performance as well. This is why electric vehicles need no transmissions. At the high end, once up to speed, they require only enough electricity to overcome mechanical and wind friction, and as such, even generate less waste heat.
I therefore argue that the capability for speed in PRT is not one that inherently requires a trade-off. This is particularly true with “smart” controlling software, which could adjust speed to meet multiple criteria just as individual drivers do instinctively.

I would say that capacity is exclusive to the other three, however, because of track size and cost, community acceptance, etc. Anyway, thanks for giving us all food for thought.

Bengt, I think, in the next few weeks, you’ll get a pretty good idea of what I mean by open-source, which, because mechanical things must be defined to be built, has the advantages of standardization built into the process. Are you trying to keep this idea of yours proprietary? Or do you care to share?

Nathan Koren said...

Hi Dan,

There are two primary limitations on "pervasiveness" -- physical flexibility and cost-effectiveness. Both of these do indeed create direct trade-offs against speed and capacity.

For example: a high-speed guideway cannot have sharp turns, due to passenger acceleration tolerances. (These tolerances, by the way, are considerably lower than in a car, where one can observe the driver's behavior and brace yourself accordingly). In many environments, sharp turns are required to be able to access a site. When I design highly-pervasive ULTra networks, I often find that even our nominal 10 m/s speed is too fast to wend its way into a site, as this requires a 40m turning radius. Throttling down to 5 m/s in places can really increase the pervasiveness of a network.

Now, of course you can always take a very high-speed system and throttle it down, where appropriate, to reduce the turning radii. But a very high-speed system is much more expensive to develop and certify, so that the increased amortization costs work against the "cost-effectiveness" criterion for pervasiveness.

Or, here's another trade-off to consider: the power system. A powered guideway is *really* expensive -- not many people have an appreciation for just how much hardware (transformers, substations, etc.) is required all along a guideway to support that. In the early days of ULTra's development, such an option was considered, and a detailed analysis found that it would increase the infrastructure costs by over 30%. So we opted for battery-powered vehicles instead -- increasing the vehicle cost slightly, and the weight by about 8%, but decreasing the fixed-infrastructure costs dramatically.

So, you have a choice to make: make the guideway a *lot* more expensive, or make the vehicles a *little* more expensive. The correct answer depends on your objective. If you're aiming for a very high-capacity system, then there will be a large number of vehicles relative to the amount of guideway, such that a small increase in vehicle cost will have a dramatic increase in the overall cost of the system. (Also, for high-capacity systems, powered guideways can achieve higher vehicle utilization rates, as there is no down-time for recharging.)

On the other hand, if you're going for a cost-effective low-capacity system, then there will be relatively few vehicles per unit of guideway, and a minor increase in the cost of the vehicles will be vastly preferable to a major increase in the cost of the guideway.

So you see, there's a direct trade-off here. If you had definitive costs for powered vs. unpowered vehicles and guideways, you could express this as a fairly straightforward equation, with the "right" answer dependent upon the desired capacity.

(Of course there is an "all of the above" solution, but this requires two different types of infrastructure, and a vehicle that is capable of interoperating between them, as Bengt alludes to. This again increases the development costs, however, once again diminishing the pervasiveness. So, the question becomes: should all these capabilities be developed simultaneously, or does it make sense to set out down an evolutionary path where they can be developed sequentially, bootstrapping forward? And if so, what should that evolutionary path look like? But that's a different discussion...)

Dan said...

Thanks for more food for thought, Nathan...And congratulations on actually getting a
PRT system deployed! That is a wonderful milestone.
I would only point out that I am trying to minimize many of the tradeoffs you mention though my designs. It is my belief that the self-banking gondola design alone will help immensely with the buffeting and/or motion sickness. It makes “throttling down” as you say, more practical, since acceleration and deceleration exert less force inside the cabin, and turns do not require a fixed radius or banking angle. Also the cost of development a high-speed network is less if the general architecture is inherently suitable for high speed in the first place. Such suitability, in my case, includes a fully captive drive train, so nothing is going to fly off of the track. You mention other tradeoffs as well, and I don’t have perfect answers for those either. I can only hope to minimize their effects. I maintain, however, that tradeoffs are often the result of other tradeoffs, which started with initial assumptions. Slow speed is not a foundational assumption I am willing to make as a starting point.
In large decentralized cities like Houston or Los Angeles, a person’s job might be on the other side of 50 km of urban sprawl. Local neighborhoods can be easily be traversed by bus, but buses get progressively less desirable as the number of stops and transfers add up. A “pervasive” network of hundreds of miles of track might begin in the form of a very large grid where the quadrants are later filed in. Travel on the main grid would have to be fairly fast. I am still not convinced that two separate infrastructures are required, as you say. More than one vehicle type can go on a track. Not all tracks need to accommodate the same speed or weight ranges. There are the many configurations already used in automotive-based transit, like passing lanes, bypass routes, etc. The very concept of off-line stations lends itself to a slow, or feeder lane. Anyway, there are lots of options to explore, many of them the result of affordable “on board” computer control and communications that were not available even a few years ago.
Finally, I would just note that this is something I do for fun, not profit. I have no timetable or business plan for these designs. Therefore I can follow up on alternatives that others might consider commercially too risky to pursue. As an inventor I do not take limitations lying down! I am looking forward to your thoughts on the specifics of this project as they develop.

Bengt Gustafsson said...

Dan, it seems that your development effort is very similar to mine, about two years later than me. Your solutions are also closing in on similar tracks...

Anyhow, what happened then was that I was able to form the company Beamways around these ideas, and now we have filed for our first patent. The initial cost of the patent was about $15 000 (I just got the invoice) but 2-3 times more money is required just to get the patent approved in the most important countries. So why bother with patents? The answer is obvious: To be able to attract the amounts of funding required to really take this type of product to a sellable, safety approved state costs lots of money. The people who control the money want to get their money back with interest. For this type of project with a high technical and political risk the interest must be potentially huge. Thus they bet their money on an immense success of the system (i.e. tens of installations). Tens of installations of a system of course attracts competitors, which don't have a large development cost to pay off, instead more cheaply can reverse-engineer the final product. Thus the investors, among a lot of other things (like a really major share of your company) want patents to fend these competitors off. With patents lasting 20 years and time to sale maybe 10 years (Vectus patent is from 2003, for instance) there is not much time to recuperate the investment.

The reason of unavoidable large cost for validating and safety approval is what makes me very skeptical to a open-source project. However, this does not preclude several companies from pooling their IP and other resources to be able to create a working system. Beamways would be interested in this type of arrangement, but somehow there must be a way to recoup even the petty investment that we have made so far.

The main problem, at this point, remains the development funding, and the IP may well be the key to getting any, along of course, with a succession of successful pilot tracks, like Heathrow and Masdar.

Dan said...

Bengt, I've got a cautionary tail to tell about patents, but it is not really subject matter that is pertinent to this blog.. I'll email you about it. Akauppi posted a link that is very relevant to this issue. It was a real eye-opener for me. It basically describes how good ideas can sit on the shelf for years in an environment where nobody in an industry has any immediate incentive to change. I am probably going to make a post on the issue soon.
What you (and all other PRT companies) are trying to do is extremely hard from business plan standpoint, at least from the U.S. point of view, where the government essentially plays no role. I think you need partners, publicity, and cheap intellectual resources. I believe it can be the role of open source to provide the latter, where needed.

qt said...

Interesting blog, this. Hope you don't mind a comment or two from someone who isn't an engineer...

About Mr. Koren's comments:

I don't think Dan is talking about building a Mach-2 system with a 50-ton capacity and then insisting everyone build to that spec. He seems to be saying "Don't design a system that makes something physically impossible unless there's a good reason."

High speed, for example. I'm sure there are things you have to give up to get 60mph podcars. The track structure may have to be heavier (and therefore more expensive). As you say, the turn radius will have to increase. But do the track DIMENSIONS have to change? Will designing the track so anything over 30mph requires a completely new design--for track and cars alike--cut the cost that much?

Or power. Just because I specify where a power rail would go, and we agree on AC vs DC and how many volts, doesn't mean you HAVE to put in the rail and the substations on every stretch of track. It does mean that if PRT takes off in those four neighborhoods (or corporate campuses or whatever) that tried out the low-budget version, and someone decides to upgrade the system, we won't have to tear down all the track and scrap the battery-powered cars. Just add the rails and the substations as needed. If we'd ruled that out in the initial design stage...

In other words--
Yes, you make trade-offs.

Some of them are hard limits--supersonic PRT is absolutely silly.
Others are limits on a particular implementation--if the podcar has to get into tight places it can't do 60mph while doing it.

If I'm reading Dan right, he's trying to design a system that can start small and THEN BE SCALED UP if the next implementation calls for it. For that reason, he doesn't want to "design out" any capability that can be left in.

In particular, he's working on a track (and drive) system that can be built cheaply enough to be pervasive, but can be beefed up and externally powered for faster, more heavily trafficked lines if the demand is there.

Did I get that right, Dan?

Dan said...

Dan The Blogger Responds
Thanks, qt. I couldn't say it any better I'll leave it there right there, especially since this same issue will come up again when I get deeper into into motor unit design for various hypothetical uses. One thing about a blog is that most people don't look too far back in the posts, so repeating one's self appears to be part of the game.