Hello from the “off the grid” New Hampshire! As some of you know, I often get away to my cabin here, where it is, to put it mildly, rustic. Well, it’s always something. Now the folks here say they can’t give me a license plate without a “911 address.” That takes 5 weeks. That means my car (with expired Kentucky tags) is illegal to drive, which means I can’t keep its battery well charged, (I have no AC on site) which means everything that runs AC or is rechargeable has to be kept to an absolute minimum. I am building a garage, you see, near the road, which will provide a gateway for such utilities. If you can call it a garage… Actually it is an experimental structure, sort of a pregnant “A-frame” with a curved roof. It relies on the strength of curves and of laminations, and can be built single-handedly, even by a 56 year old. (me) It should cost less than half of a traditional structure. Anyway, the point is that the computer I am writing this on is one such energy drain, and is competing with my rechargeable tools. So I might not be around a lot, blog-wise. I am currently at the library, but that an option best suited for rainy days, and it is beautiful outside today.
Now on to some thoughts on PRT. The real obstacle to PRT is, and has always been, the business model. Without a lot of political will, it is hard to get the government funds needed, and that political will cannot exist while there is fear, uncertainty and doubt. Two “Fortune 500” companies have abandoned PRT after sinking millions into it for that very reason.
It is not the track or the stations, for steel companies and builders would love the contracts. After all, they will get paid regardless. Vehicle builders would love it too, although they have a bigger, longer lasting stake. But building vehicles (warranties included) is what they do. Everybody, so far, is within their core competencies, and structuring a deal would be similar to what they do every day.
Not so control. This is a little manufacturing, a little maintenance, a long-term service…
Business-wise, it’s a real mess. PRT companies can stand up bravely all day long and explain how they will always be there, but no one is going to listen. Bankruptcies are just part of the game these days, and all that leaves a city with is a bunch of useless hardware.
It stands to reason then, that the matter should be attacked directly. What can be done to get a handle on this “vendor-dependency issue? What I have endeavored to do, as a first step, is to make the problem smaller. In my last post, I detailed a time-based control system that could reside largely in cyberspace. It could be hosted by almost anybody. It could handle most traffic management and fare collection, things that are not affected by the inherent latency of the internet. On the other end, I have strived to give more control to the vehicles themselves. After all, not bumping into each other seems like a task well suited for those vehicles directly involved.
I do not claim that a global internet-based traffic management system along with autonomous cars is all that is required. As traffic density increases, the ability of vehicles to act with any kind of autonomy will all but vanish, just as it does in auto traffic. The combination I have described is inadequate for the job of high speed, high density, minimal headway traffic. But this does not change the fact that predicating a control architecture on the health of an untested company is a serious, probably fatal, drawback. At least with the combination I suggest, if the PRT company goes under and no longer provides any parts, training or support, the system would still work. Just not optimally. This would give the city some breathing room while they search for a fix. After all, the problem with PRT companies is that they are irreplaceable.
So, to recap, my objective is to structure a PRT construction and control architecture that cannot leave a city stranded, or come as close to that objective as possible. This may not make for the prettiest software code or networking structure, but it is, in my view, the only way forward. At the very least, we should all be looking at exactly what can be done to structure the control aspect of PRT into simple, definable businesses with ordinary equipment requiring minimal special training. What equipment, where? How many people? Is there scheduled maintenance? Replacement? What communications gear does the track need? Who will install that? You get the point. If we can divide and conquer this stuff, we will be a long way ahead.
Saturday, September 11, 2010
Subscribe to:
Post Comments (Atom)
5 comments:
Grandiose dreams are great, but the pragmatic approach is, indeed, the only way PRT will ever become reality. Kudos to Dan. I hope many others join you on your quest to make PRT achievable.
No matter what, there is going to be a control software. In your concept the complex bits are purchased as a bundle with the vehicle. Thus the purchase agreement is between the locality and the manufacturer. If that control system is incompatible with other vehicle manufacturers control system, you are locked into that manufacturer.
There's a big difference between the way software companies go bankrupt and vehicle manufacturers go bankrupt. Only unsuccessful software companies go bankrupt because the only way they can fail is to not have any customers. Big, huge, gargantuan vehicle manufacturers have and will go bankrupt because of costs getting completely out of control. These are companies that are "too big to fail".
So the fear that your software company will go bankrupt is a straw man. Some will, but they won't have many customers and so the impact will be minor. And in the process of trying to avoid that unlikely scenario a much more likely failure has been substituted.
In the scenario I posit, the control software could be bought in two ways. In once case it could be bundled with the system design.. i.e. the rights would be bought at the same time as paying for the services of a general contractor. That is a pretty standard type of construction deal in which one company brings or organizes the expertise, labor, etc., but generally much of the work, especially the labor intensive parts are subcontracted out to local contractors. Skyscrapers need architectural plans and all kinds of miscellaneous stuff (even software for security, water, heating, etc.).
Another method might be for the locality to run the project themselves, or parts of it, and acquire the software directly.
Either way, vehicle centric or not, it's probable that independent software vendors will arise. But the relationship between those vendors and their customers will be significantly different depending on the basic business model. In the vehicle centric
model, the end customer may barely know who the software vendor is. They can still go bankrupt.. in fact they are more likely to, because if they only provide software to a single vehicle manufacturer, they're only bargaining power in that relationship is the threat of going out of business, and to the degree that the manufacturer is inclined to play chicken with them, some actually will.
In the model that keeps the complex bits separate from the vehicle, the customers may have direct relationships with the software vendor, and when they don't the system is structured in such a way that barring any legal obstacles, they could form that relationship at any time. Software vendors are more likely to have a plethora of different customers, and their customers are going to have a strong motivation to ask for standardization.
Vehicle manufacturers have more demotivation than motivation toward standardization. Sure on one side, being able to switch providers is positive, but on the other side, having their systems compatible with their competitors systems gives them less leverage over their customers. Likely in this scenario the software vendors with multiple manufacturers as customers will develop multiple systems, designed to independent specs and share some proprietary common components between the two.
Have you really thought through all of these trade-offs in your assessment of the two business models?
I just finished the Market side of the upcoming website:
http://www.bmdesign.fi/beta3/market.shtml?lang=en
Ready for your comments.
Ryan, you DO know that this site is predicated on the concept of open standards, right? I hope that hasn't gotten lost in the shuffle. I also want to mention that I favor a strong role for a non-profit partner in all of this, and was going to post on it, but time is short...
Yes, Dan, I'm all for openness. If you were confounded by my discussion of software licensing, let me explain.
Open software isn't something you ask for and receive. Developers need motivation. This is doubly true when the deployment of software is non-personal, and triple true when it requires bypassing obstacles like regulatory approval.
The more layers you put between a developer and the end user the less likely that developer is going to be motivated without some financial incentive flowing back up that chain. This is especially true if any of those layers are large profit driven entities (i.e. vehicle manufacturers).
The best and most plentiful open source software is the software a developer can actually use. An operating system, a programming language, a text editor, development framework, etc.
In light of all those hurdles, it is wise to consider a hybrid approach. Maybe software vendors can share some of their work in an open source package. Maybe some pieces will be made available by motivated university students. But in the end someone is going to put it all together and be the first to surpass the regulatory hurdles, and that is probably a company that can pay lawyers and maybe even lobbyists, which probably requires them to have sales people to find the money to pay all those people.
Post a Comment