Sunday, August 22, 2010

100> One Hundred and Counting ...

Well folks, this is post number 100, and I have a sad announcement. I’m afraid I will no longer be posting on a weekly basis, at least that will no longer be a goal. There was a time when the subject matter was so simple and abundant that I could whip out a post in a few minutes. Now, frankly, I’m starting to repeat myself. And anything I haven’t already said probably takes a few pages to say. In research and design, the work is becoming more fine-grained as well, full of time-consuming details. So I will post only when I can do a quality job of it, and when the topic makes a significant contribution to the body of work that I have already posted. Maybe that will free up the time for some long overdue improvements to the site. One hundred posts. It’s been a long journey... Now on to the topic of the day.

Whenever I talk about PRT control, I am usually pointed toward the work of Dr. J. Edward Anderson. I want to take a minute explain what I don’t like about Dr. Anderson’s method of PRT control, why I think it was designed the way it was, and how I think it could be improved.

First of all, it is important to note that we are talking about a system that was created well over a decade ago. I do not want to imply that the later generation systems currently offered by Taxi 2000 or PRT International are anything but top-notch, although since they are proprietary I know nothing about them. From what I can gather from his 1998 paper, Anderson did a good job of working with what he had, and to understand his control methods, we must understand the technological limitations of the day and how his “Asynchronous Point Follower” system was designed to overcome them.

 At that time, “packet switched” data transfer was still in its infancy. The word “Internet” was just becoming a common term. There certainly wasn’t any good way to move information back and forth between a bunch moving of vehicles. Information was directed by “circuit switched” methods, so to direct information to its proper place, the various vehicles and a “zone-controller” would have to take turns sharing a dedicated line through a technique known as “time division multiplexing.” This multiplexing needed a hardware platform. The dominant computing architecture of the day was “client-server,” so a wayside server became the “zone controller” which played the role of both old-time telephone switchboard operator and commander-in-chief. These days such limitations are rapidly falling away. Many vehicles can talk directly to each other wirelessly, exchanging massive amounts of data, all at the same time.

Anderson was controlling vehicles that were comparatively “blind, deaf, and dumb.” Is it any wonder that he would “lead them by the hand?” That’s what “point following” essentially is. The zone controller extends its “hand” like someone leading a blind person across a street. Letting go, even for a few seconds, needed to be very predictable, so there were minimal adjustment moves, measured and known by both the controller and the vehicle. These days a vehicle could pretty much watch out for itself. Actually the whole concept can now be done in the negative. Instead of the safe spot that the “hand” (moving point) represents, the space close to other vehicles can be considered the “unsafe spots” and everything else can be fair game, as it is in ordinary auto traffic. Anderson’s variation from earlier point-following schemes was a move in this direction, because he allowed the stretching the distances between these points.

Greatly helping along the shift from “moving point” control is the proliferation of network-ready, “plug-and play” sensors, to give the vehicles “eyes.” It also doesn’t hurt that vehicles can continually update their positions in real time without over-burdening the system. 

In merges, Anderson’s zone controller would weave the safe zones together, keeping the vehicles constrained within them. The beauty of this whole scheme was that the vehicles did not need to have synchronized internal clocks. These days that is not a problem either, which enables an interesting alternative. Simply give each of the vehicles a specific, exact time to pass the merge point. This “appointment” could be set and reset, negotiated among vehicles approaching the merge point, something that would have been utterly impossible a decade ago.

Finally computers, back then, were big, heavy, slow, expensive energy hogs that generated a lot of heat. There was only so much that a vehicle’s computer could be expected to do, so much responsibility necessarily had to go to the zone controller. The moving points scheme was a good division of labor. The zone controller could weave many points but the vehicle just had to follow one. That has obviously changed. Now every thing that the zone controller knew or calculated can be known or calculated by each of the vehicles independently in a fraction of the time.

It has been mentioned that the simplicity of such a system is a good thing. If it works, why change it? Especially for something much more complicated, such as asynchronous, autonomous control?
I am not at all sure it IS more complicated. What must a vehicle do?  Wait, accelerate, decelerate, cruise and exit. There’s not a lot to it. With Anderson’s “Asynchronous Point Following,” acceleration and deceleration are handled by the vehicle executing equations that are meant to move the vehicle backward or forward by a precise amount, into a safe spot, double-checked by the zone controller. That does not seem simple to me. Why try to backwards engineer a system designed to overcome obstacles that no longer exist?

Autonomy has generally inferred limited outside influence, but with modern communications there is no clear line anymore. As our computing platforms have become more mobile, the relationship between those connected computers has changed. Once upon a time the only model was client-server, where a giant mainframe computer would perform tasks, often on a time-share basis, for people working at relatively dumb terminals. PRT control systems were born of that era, often designed to run linear motors mounted in the track itself, so that the vehicles were just objects being magnetically pushed around a giant machine.

Anderson’s designs pushed control much more toward the vehicle, (toward autonomy) especially by putting the linear motors in the vehicles themselves. Slow processing power and communications were limiting factors in that mobile environment. These days, the barriers have all but fallen, and the client-server model is just one of many. There is cloud computing, distributed computing, parallel computing, grid computing, P2P computing. And there are many types of networks, and they can even be overlaid with each other.

Perhaps the traditional definitions of PRT control (synchronous, asynchronous) have outlived their usefulness, since virtually all systems are hybrids between the two. More useful would be to analyze how the control responsibilities are divided and shared in terms of network structure(s).  For example, if all accelerating and braking is physically done at the vehicular level, how far away should that control be pushed? Certainly the closest vehicles should have some say in the matter, but what is the point in sharing the small maneuver details any farther than that? Yet how such maneuvers effect the vehicle’s ETA would certainly be of interest to the system globally, for traffic management. But that data is of a wholly different type, organized and accessed differently. An overlaid network. More localized traffic management might be best handled still differently. Its time for a fresh start, one that better leverages the qualities of recently emerging network, sensor, and communications technologies.

Lastly I would refer the reader to post 76, although it shows what I have been saying about repeating myself. I think it is important to get this right, to have an architecture that can evolve with the times with a minimum of disruption, and can be implemented without creating the poisonous “vendor dependency” that I have written about.  In upcoming posts I will try and lay out, more specifically, what kinds of networking and control structures I have in mind and why.


Anonymous said...

Thanks, Dan.

Perhaps the traditional definitions of PRT control (synchronous, asynchronous) have outlived their usefulness, since virtually all systems are hybrids between the two. More useful would be to analyze how the control responsibilities are divided and shared in terms of network structure(s).

As a computer guy, I agree with this. I never really grasped the use of those terms, anyways.

Andrew F said...

Hey Dan,

Maybe if you are looking to lesson your load in terms of generating content, it might make sense to transition to more of a forum format than a blog. Create a new post every now and then on the blog as the mood and inspiration strikes you, and lock comments here and link to a forum thread with that topic for discussion. Discussions with recent comments float to the top and tend to keep going and evolving rather than die off as they fall off the page. It also lets other people create topics, which further reduces the need for you to generate content.

Anonymous said...

Forum would certainly be nice but I'm a bit doubtful even that would work. PRT is very opinionated area and there is no one single "truth" to be found.

The best community site that comes to my mind is . Content is gathered around questions (issues) and there may be millions of those. They don't even try to link the issues together into a network - this is where wikis imho always fall short.

It's like Google search marries Wikipedia. And it is fast, useful, and FUN.

How about trying out stackoverflow for PRT? They do allow such licensing of the technology.

Anonymous said...

StackExchange seems to be boiling a soup of anything-under-the-sun question/answer forums.

There's one for Public Transportation, already opened.

I think it's actually better to join forces in such a more generic group than bring one on prt itself. Then again, "PRT design" could better be handled in a group of its own.

I joined.

Dan said...

Dan the Blogger Responds:
It has never been my purpose to host a weekly column or a special interest blog. I am a lot more interested in how useful this body of work will be to future developers of actual systems. Having to figure out something to write about each week is a distraction from my ongoing design work, work on the SMART standards, and the general exploration of how the technological advancements of the last decade might affect PRT in general. Having publishing deadlines will only result in a lot of useless fluff and lost productivity.

I do value your comments a lot. They bring a lot of perspective to the issues. I only hope I can eventually get a “recent comments” widget to work again, to point people to threads that are reawakening. I also plan to put in a table of contents with descriptions of what each post is about, so that the site is easier to use as a reference. After all, the stuff we debate here is the same stuff that any future PRT designers will debate. Let’s help them get it right. Quality over quantity!

Andrew F said...

Dan, I use google reader to monitor an RSS feed of comments from this blog. Not sure if blogger allows simple rss feeds to be shown in a sidebar. If so, there's your recent comment widget.

Andrew F said...

Here's the link to the feed:

Ryan Baker said...

On the topic of vendor dependency, I think that's a great thing to avoid, but you're going about it in what I suspect is the wrong way.

Lets say you have a bunch of independent vehicles. How do they communicate? Well they have to have a protocol. In addition to make decisions they need a set of rules about which decision is made. If they don't all respect the same rules there are conflicts and failures.

These protocols can be open or closed. If they are closed then you have a vendor dependency. If they are open, then you don't. In reality, effective open standards are usually far more than the written documentation. Almost all are represented by some actual implementation which becomes the defacto standard. At one point Internet Explorer represented the defacto HTML standard. Today it's a little more confusing, I think most designers don't consider IE the standard, but rather Firefox or Chrome. Sure there is an "official" HTML spec but that's more a theory guiding future evolution of the browsers than what people creating websites care about.

If by chance, that is the type of system you're trying to create, take another look. It's extremely complex and breaks all the time. That's marginally okay for browsers where they're trying to make trade-off gaining evolution speed while accepting many other undesirable side-effects, but it will not work for PRT control.

The way to insure a non-vendor dependent implementation of PRT control is through an open implementation.. i.e a full working piece of software.

Now you could have a system where this piece of software is installed in every vehicle manufactured, but that seems difficult to me. I'm sure a standard will emerge, but choosing it ahead of time requires a level of cooperation uncharacteristic of manufacturers.

I think your best bet is to have the simplest means of communication between the vehicles, and then create an open implementation of the central controllers (call them zone controllers if you like for familiarity, but I'm flexible on how they interact). Once you have that software and a communication protocol, then it's easy to replace any proprietary piece filling that role.

Anonymous said...

Good points, Ryan.

My info tells that China would be on the forefront of making autonomous (I mean: driving themselves) car transport in certain small cities. No manual driving would be allowed there (which simplifies the situation by orders of magnitude).

The distributed control model suits perfectly for such a case. Vehicles on roads are inherently multi-vendor, much more than PRTs on tracks.

I see PRT as a service, or a system. In that scenario changing from one deliverer to another would (simply) mean removing the system and building a new one. That sounds like a lot of work but if deals are 10+ years and the system is designed to be removed / altered / expanded, it's not really a problem.

So I'm for the "Apple" way of making business here. In order to guarantee smooth integration of everything, the system should come from one source.

I may be wrong.

Ryan Baker said...

There's really two big pieces here that fit into that discussion of business model. One is the control software/communication. The second is the track. With any standard for those two, the other design components tend to be more independent as long as they meet the requirements of the track and control systems.

These are different beasts and deserve different business models.

Track really needs some standards. Track will be a bulk commodity, much of the cost of which will involve installation. You really don't want market fragmentation.. that will drive up costs, and costs are very important here.

It is important to fully explore all the different possible designs. That may mean a few incompatible implementations, but it's important that a final choice is made.. at least on the continental level before you end up with some really ugly incompatibilities. I think this site is doing great things to help encourage the emergence of such a standard.

It's tempting to compare the control software to an operating system, but it's really not. Sure once the R&D is done it can be reproduced at very low costs. There's some installation costs, and some maintenance/monitoring, but compared to the ratios involved with physical infrastructure like track, it's very small. This definitely naturally encourages a limited number of implementations. Track doesn't have that same natural encouragement because while there are huge downsides to many different track designs, those costs are on the back-end rather than front-end. As a result it's totally feasible to think that some gross mistake could be made in the track area if we aren't careful.

But while the control software will trend toward very few implementations naturally, it's dissimilar from a operating system in that there isn't an unending area of feature expansion. Once control software meets the most basic requirements, there are only so many ways left to improve. It won't need to enable new applications each year, the main application will stay constant for it's entire lifetime.


Ryan Baker said...

I'd be happy enough with the Linux model but have my doubts about whether you'd find the right group of people to write that software. Unlike Linux they don't really get the chance to use it themselves. Also, they you'd need to do a lot more than just write the software, you'd have to put it through all kinds of hoops to satisfy legal requirements (including probably lobbying to make sure those requirements are clearly stated).

The equivalent of the Apple model in PRT would cover hardware and software. I think that's a losing game. I abhor the Apple model in the computer world. They have some good designers, but their business model, for consumers, is the worst one possible. If Apple had the market share of Microsoft, the world would be a much more dysfunctional place. Luckily, that business model, at least in the realm of operating systems, has a very hard time rising to the top, and seems most capable of some quick land grabs and holding a 5% niche.

The Microsoft model might fit well, but I'd be betting more on the late game UNIX model. In the UNIX model there were many separate proprietary implementations. They all had rather high price tags. They were generally very good at certain things, but did a very poor job of adapting to change quickly and bringing in new partners.

The high prices were a downside, but that mostly originated from the lack of scale since most of the volume went to DOS/Windows. The real Achilles heel was that for a software developer to create an application for UNIX he either had to do it for just one or do all kinds of crazy junk (plus testing.. don't forget the testing) on all 12 flavors. That made it very expensive to be a UNIX software vendor (low volume or high costs), so quite predictably there were far more Windows software developers, and since user's kind of buy computers and operating systems to run software...

But here in the PRT world, the need to evolve will be somewhat muted, the costs of control systems relative to the rest of the system will be trivial, and the need for really solid, but compatible implementations will be higher.

Dan said...

Interesting reading, guys.
Thanks for that feed link Andrew- wish they would refer the reader to which post the comments refer to.

akuappi, Ryan, I'd like here more specifics. Akuappi, I really don't get how a "service" model pays for right of way, excavation, etc. How much a kilometer does it work out to?
Ryan, I see 3 systems here, in vehicle, zonal, and the whole ticketing routing thing. That doesn't seem easier than 2 to me...Then each needs backup and to be integrated with the others. Would a zone controlled system ever be able to achieve advanced functions like platooning? And if so, are you thinking that these 3 systems will still be interesting enough projects to be "open sourced?"

Anonymous said...

Dan wrote:
"I really don't get how a "service" model pays for right of way, excavation, etc. How much a kilometer does it work out to?"

I exclude this to the customer.

It is the customer's (city, airport, private/public combo, ...) responsibility to have land usage rights. And to make the decisions on track routing.

Once the land rights are there and the routing has been shown to be good (enough) by simulations, the PRT company will "drop in" their service to the assigned area.

This model keeps the PRT company away from local disputes on land usage. They can be nasty, and time taking. Better do business somewhere else.

Some areas (s.a. China) don't really have much disputes. People are simply commanded to move out. With PRT, they won't have to since people can live, walk, bicycle and sleep underneath the track. It's only us westerners who put such immense focus on land ownership.

In practise, getting an effective, modern transport system in one's neighbourhood hikes up real estate prices. mentioned four times hike as an example (connected to the Portland, OR tram system). They should love and welcome PRT to their neighbourhood, but initially land usage will be an issue. Communities should deal with that themselves. They already have means to do so.