Sunday, March 7, 2010

76> Autonomy

     Here are two criteria for a good, open source PRT control system. First is that it should be unbreakable. The second is it should be infinitely extensible.
    When I was a young boy, living in upstate New York, there was a blown fuse in the Power Plant near my home. It created a cascading effect that left twenty-five million people without power, including New York City. That is what we don’t want- interdependent software and hardware arrangements that control large areas or groups.  After all, eventually a support will get hit by a train, or there will be an earthquake, a tornado, terrorism, hackers, or whatever.
    Giving PRT vehicles the ability to act autonomously gives both extensibility and unbreakability, but might seem counter-productive. After all, won’t this result in the same traffic problems that PRT is supposed to address?
    I believe the model of automobile traffic is actually a pretty good one, except for the drivers. Because our reflexes are limited, we dare not tailgate. These spaces between vehicles reduce capacity. PRT can solve that. Another problem with traffic is that there is no sure way to know which route will be the fastest. PRT can solve that as well. Then there is the case of accidents and other delays caused by other drivers.  PRT cannot, however, solve the problem of simply having more vehicles wanting to use a road or track than can fit. Special care must be used to avoid having two packed tracks merge into one, but even this doesn’t necessarily require centralized control.
    One theoretical advantage of the old-style concept of strict central control is that every vehicle’s route and arrival time can, in theory, be known from the beginning of the trip and the projections used to plan other vehicles’ routes and so forth. The traffic is balanced from the beginning. Numbers of vehicles converging on a single bottleneck or destination would be known and could be cued to arrive in an ordered fashion. If delays are anticipated the passenger would be informed as to the length of the delay before boarding, or the destination could even be refused. This tack was largely abandoned in the early days of PRT research, however, because it was too computer intensive - especially since a single slipped schedule would throw the whole thing off. It was recognized, even back then, that more decentralized computers that managed smaller parts of the system would be more robust, and that strict synchronizing is not necessary, except for merging.
    Though I don’t seriously suggest it at this time, it is interesting to note that these days every vehicle will undoubtedly have much more processing power than it could ever use. Therefore, given high-speed communications, a PRT fleet could use distributed computing techniques to tackle advanced real-time traffic management, blurring the distinction between autonomy and centralized control. Just an observation. I get easily sidetracked… 
    It is my opinion that the logical progression toward decentralization should continue with the abandonment of the so-called “way-side computers” or “zone-controllers”. The vehicles themselves can perform these duties. Advances in communication technologies, it seems to me, render them obsolete.
Part of this decision rests on the concept of an open, standards-based approach. I do not think that it is beneficial to have PRT be developed, installed and managed by a single, “Swiss-army-knife” company. I think it will inhibit municipal sales. Even if there were some buyers, I think it would generally lead to poorly designed and executed systems over time, as is often the case when the only competition is with other departments over R&D funding.
    An approach that would inspire more confidence, competition and innovation would be to standardize and separate PRT in terms of Track, Stations, Vehicles, and Control/communications. A consortium of companies organized in this way would have other sources of income besides PRT and could stay within their core competencies. The control aspect in particular, though, seems to pervade all systems. It would be good to begin with an architecture that clearly and simply defines who has control when, where and why. The “zone controller” seems to be an odd orphan in this respect. I begrudgingly accept the possibility of such external control of vehicles at a station.
    With autonomous control, each vehicle is programmed with “behaviors”. This is analogous to bees or ants. The queen doesn’t plan the routes and objectives for the hive or mound. Individuals have separate behaviors that have a combined synergistic effect. With an autonomous PRT system, vehicles are externally informed but not controlled. As much of sensing, communicating, and computing is done by the vehicles themselves as possible. Such a system relies on extra redundancy. This has been made practical by the incredible and continuing drop in component prices. With several of everything, vehicles can react to a sensor, communication or computer problem by simply taking themselves  to the shop, though possibly with degraded performance. There is also redundancy in the information flow and delivery methods. If there is degraded communication in one system the message will be repeated anyway. If the fault is in the receiver there is another different type of system that delivers the same info. The methods I suggested in the last post are examples of such a redundant system that does not rely on, and is therefore a good compliment to, more ordinary communication means involving radio waves and microprocessors.
    It is also noteworthy that in the brief time a vehicle is docked for boarding a detailed up-to-date traffic “map” can be downloaded. This should include timetables of anticipated traffic and station usage as well. This would be where the vehicle would learn of possible track segments to avoid. These can be updated along the way in shorter transmissions. I envision the vehicle frequently rechecking for the fastest route along the way and broadcasting its updated ETA. The stations would share in the creation and distribution of the resultant updates, so this information, too, would be from redundant sources.  

13 comments:

cmfseattle said...

no guts, no glory, right?

please identify what technologies would be used for vehicle-to-vehicle and/or vehicle-to-station-computer communications. please explain how they are less susceptible to breakage, hacking, etc. than time-division multiplexed radio comms via leaky RF cable.

if the vehicles are truly autonomous, wouldn't they be continuously aware of all other vehicles? wouldn't that obviate the need for downloading a traffic report from a station computer?

if you were to make a pair of flowcharts, one for autonomous vehicles and another for a zone controller (a portion of which would also be for its non-autonomous vehicles), i think you'll find the former to be much more complex (and therefore, more difficult and time-consuming to develop and troubleshoot).

note that i'm not saying the vehicles should never become autonomous. i just think it'd be wiser to work on that later. is there something in the zone-control design that precludes vehicle autonomy in the future?

qt said...

cmfseattle:
"is there something in the zone-control design that precludes vehicle autonomy in the future?"

How about its mere existence?

Don't mean to sound cynical, but a system put into place has a tendency to stay there long after it's no longer needed. Consider how long after the last steam train railroads hired "firemen." Or all the cabooses you saw growing up, carrying "brakemen" on a vehicle with air brakes on every car--all of which were controlled from the engine.

Add to that inertia the local government's love of micromanagement--as well as its terror of changing anything at all that's already been put in place--and a zone-control design is likely to stay a zone-control design until transporter beams replace it. I suspect Dan would rather avoid setting the control system in stone for that reason.

cmfseattle said...

well qt, we could just leave the ZC in its cabinet and pretend to use it, no?

and, to answer your other questions:
U.S. locomotive cabs required a 3rd seat for the fireman until the late 70s, early 80s for some RRs (depended on labor agreements). cabooses were not phased out until End of Train Devices were shown to the FRA to be reliable. a few cabooses are still kept around, mostly for branchline ops with long backup moves.

sounds like you are equating gov't with unions, at least in some behaviors? i don't think software config (nor hardware config, for the most part) has the same problems.

cmfseattle said...

maybe it'd be useful to define/clarify a few things.

PRT = transport network
network = interconnected guideways

our goal is to allow as many trips/hour via the PRT as possible, at the lowest cost and without hurting anyone. we need to have "control" over what's happening on the network. we could also say that we need to "manage" network traffic.

at any given time, there is a most-efficient way to order the vehicles along the network's guideways.

what needs to be controlled? the vehicles, right? to be more specific:
1) speed and direction
2) door(s), HVAC and lighting
in this discussion we can safely neglect #2.

at this point, there are 2 basic options:
1) each vehicle's computer can communicate with other vehicles' computers, avoiding collisions by following a set of rules, or
2) have a computer, which is aware of all vehicles' locations and destinations, manage traffic by communicating with vehicle computers.

ideally, we'd like to keep the calculations simpler, which in turn makes the computer code easier/cheaper to develop and maintain.

to this end, i suggest (as others have) dividing the network into "zones." i propose we define a zone as:
- 1 merge point, and
- the upstream guideway until the next upstream merge point

a zone may or may not also contain 1 or more diverge points. however, if there is more than 1 diverge point in a zone, only 1 of them can have guideway connecting it to the zone's merge point. (this means that if a station has 2 or more parallel bays, it will contain at least 1 more zone than a station having only 1 bay.)

in simpler terms, a zone is a merge and some guideway or it's a siding.

dividing the network into many similar portions (zones) distributes the computational load according to the network's physical characteristics. since the maximum traffic to be handled by a zone, the number of interacting entities and the number and type of interactions can be known beforehand, it is relatively simple to predict software failure modes.

eventually, the above could also be true of the network as a whole; however, communications between vehicle computers is physically more difficult (and therefore, more expensive) than communications between zone management computers.

so, for the time being:
VMC = vehicle management computer
ZMC = zone management computer
NCC = network coordination computer

Dan said...

Dan the blogger responds-
Here is something I wrote in response to cmfseattle's first post. I see there's a lot more here to digest. I hope I can get to it soon. I'm petty busy, as usual.

I wish you or someone else could explain to me (and the readers) exactly how the zone controllers work and what they do. I get the impression that they have a bundle of functions involving both actual vehicular control and control of the system, as well as real time status reporting. I am compelled by logic to look at those required individual functions and place them as I see fit, which would be, in general, towards the vehicles themselves. To some degree I may be just “rearranging the furniture” so to speak.

I have stated before that I think computers external to the vehicles should inform but not control. Let me point out how fine the line is between the two. If a traffic cop holds up his hand to you, is he stopping you or informing you that you should stop? Maybe some of our disagreement is simply semantics. If there are condition-driven electronic speed limit “signs” in the track, for example, which the vehicles obey, is that a “controller” in your lexicon?

Because autos are autonomous, if a traffic light breaks, drivers can treat it as a four-way stop. If the traffic light were an actual traffic “controller,” if it broke all cars would be stuck until the light was fixed. If a zone controller goes out, what happens to the vehicles on that stretch of track? Can they be programmed to limp to a station? If they can, then that’s the introduction of autonomy. Consider this in regards to your first question, cmf… It’s not really the type of communications that is important, but rather the architecture. As to your third paragraph, about the flowchart… It is obvious that having redundancy is much more complex than not having it. It is far simpler to potentially leave multiple cars stranded than creating a whole alternative system to use if the first one fails. Once it’s there though, it enables cross checking for faulty systems or data.

I don’t want to get into exactly what the vehicles need to know where and when because I plan to post about it, but suffice it to say that they need very little data at any given time to go about finding their way, probably just a few kilobytes before each junction. They don’t need a whole map, just traffic updates to their “short-list” of routes. Autonomous control requires only rudimentary signaling between vehicles.

Dan said...

OK this is off the cuff, cmfseattle, as I haven’t thought about what you said all that deeply, but my gut reaction is this. Virtually everything you propose is to get the last little drop of track utilization. In my opinion, if you accept say, 90% capacity none the computer systems you describe is needed in the first place. Start there and let people figure out how to tweak it later to 95%.

My starting model is the automobile/road system. It has none of the computer systems you describe, yet countless millions manage to get to work every day. If you look at what is wrong with it, as a system, it isn’t the lack of the computer coordination but the humans at the controls, shape and weight of vehicles, size of roads, etc. I think you are letting the final 5-10 % drive the whole design process.

Skip knowing where every vehicle is or how fast it is going. As long as you can know the present traffic count (by “zone”) and estimate the anticipated traffic with reasonable accuracy you can easily program vehicles to avoid traffic with alternative routing. When an essential track segment gets totally saturated and there is no way around, the traffic will have no choice but to wait to merge. Big deal. Any system, no matter how many computers you add, will reach the same fate, or else you’ll wait at the station instead. Needing more lanes of PRT track is a problem I would like to see. By the way, without the human drivers there would be no “rubber-band” effect of reaction time, so that the system would simply slow evenly. Also, the bottlenecked cars can be programmed to know they are causing a slowdown and could be programmed to go much faster. Again, none of this requires anything other than a vehicular behaviors, other than synchronization at merge points.

Also there has been a tendency for PRT developers to concentrate on short trips in congested urban areas and competing with other forms of transportation in that arena. This leads to the desire to measure success in terms of people shuttled per hour and therefore systems of great technical complexity (and associated cost) can be justified to meet this end. At the same time we spend huge sums building HOV lanes that nobody uses when PRT would do the job much better and cheaper. More junctions per mile of track equals more benefit to your approach, more miles per junction equals more benefit to mine.

qt said...

Actually, the railroad analogy was my second choice (off the cuff--no doubt there are better ones) for an example. The first was the air traffic control system, but discussing the problems and inertia's involved there would have started a whole new (and irrelevant) thread. Otherwise I would have gone with it because the forces encouraging "more of the same" ARE governmental in that case.

My point was that once positive outside controls are introduced, there will be incentives to maintain them and (often) extend them. Neither bureaucracies nor directly-profiting parties (such as unions (or capitalists, in other circumstances--I'm an equal-opportunity cynic)) have much incentive to give the "customer" more autonomy. In this case, to "leave the ZC in its case and pretend to use it" won't likely be much of an option. If it's there, someone will insist on using it for something.

All that said, I won't comment either way on the advisability of zone-control arrangements. Not yet, anyhow. That wasn't my point. I was just answering your question about what in a zone-control arrangement might prevent future autonomy.

I have a tendency to focus on the logic in an discussion, figuring you'll come to an agreement (or an agreement to disagree) more quickly if you're not talking past each other. Sometimes it annoys people. Hope that's not true this time...

Dan said...

Not at all QT. I didn't mean to ignore your comment. Keep 'em coming. That was not my main concern though, although there is an element of truth in what you say, in that I prefer introducing a barebones framework where a certain amount of Darwinian improvements can be had. That would include trying to minimize highly specialized hardware/software systems where possible. I suppose you are right, in that it's not hard to imagine someone introducing regulations on what a zone controller must include...once it's there.

cmfseattle said...

Precision Station Stopping Progress Update

"Metro must get the problem under control so it can go forward with plans to run eight-car trains to ease crowding, Salpeas said. Because eight-car trains are 600 feet long -- the same length as the platform -- there is no room for error."


How would autonomous vehicles handle making room for a merging vehicle? What if one of the vehicle computers fails during the maneuvers?


"Since wayside zone controllers have in their memory exactly the same maneuver equations as the on-board computers, accurate safety monitoring is practical."

http://www.prtnz.com/component/option,com_docman/task,doc_download/gid,19/Itemid,37/

http://www.prtnz.com/component/option,com_docman/task,doc_download/gid,5/Itemid,37/

"All processing associated with AVP is performed in parallel by a pair of redundant safety processors which are cross-checked for agreement. This agreement is a condition for any vehicle motion."

http://faculty.washington.edu/jbs/itrans/avc.htm

Dan said...

First of all cmfseattle, I want to thank you for digging up this material, along with all of the other fine links you have contributed over time. It really helps elevate the discussion and the educational value of this blog.

Perhaps I am lucky that I came into this with zero knowledge of railroad practice, because once you start thinking of PRT in terms of moving objects around on a map, a whole different logic ensues. I come at it from the point of view of automating a really easy driving task and then providing tools to make the traffic management more efficient. I also want to point out that my main concern is still on track specifications, which is why I brought all of this up in the first place.

If you consider it from a “driver” point of view, there are just four controls, the start button, the gas pedal, brake, and a left/right switch. Besides navigating, the driver would only need to keep a safe distance behind the car in front, and negotiate merges. The navigation can all be broken down into simple left/right decisions at each junction, based on a combination of direction/distance and traffic density. I think the route (and alternatives) would be chosen at the station, but traffic updates would be available (just for track segments that lie ahead) prior to junctions.

I guess merging would be accomplished by using markers in the track and a common, track-based clock. Synchronizing the clock to the passing markers (and then maintaining speed) could ensure non-conflict. Each vehicle would establish communications (well in advance) with its merging “partner.” This would initiate a back-up clock. Track sensors could activate track-based brakes in the event of an imminent collision.

Ben said...

Anyone have any thoughts about how we could create trains of multiple cars linked together in a safe way? This approach would require very rapid coupling and decoupling but would offer advantages in both urban throughput efficiencies along with high-speed aerodynamic drag efficiencies.

Dan, have you done any thinking on this topic? Love to see your opinion here.

PS. What are the other major players in this space that have groups dedicated to PRT??

Ben said...

I really like the basic concept of having a system of track markers so that each car will have the ability to double-check their speed while also having a very safe way to communicate location to the other cars on the track.

Maybe each of these standard markers should convey two elements of information to the cars:
1) How many markers there are between them and the next merging junction
1.2) You don't need to signal the next exit junction because the train can just initiate the switch after you leave the second to last inlet junction (assuming the wisely chosen design of Dan's switching tech)
2) The absolute position in the network that the car is in, each segment of track could have a URL or a standard code.

All of this information should be redundant with cell tower triangulation and GPS for absolute location and speed sensing.

All of the car data should also be streamed via 3G or 4G directly to a central database where anyone can observe and monitor the grid in general. This would also allow the entire community to perform disaster response roles. This would also allow individuals in cars to perform active roles in managing the network. This activity would be analogs to driving in crisis or high traffic conditions.

Dan said...

Hi Ben- I did a little work on the subject in Post 56
It's called "platooning" and lot's has been written on the subject. I would start with bookmarking this site and make frequent use of the search bar. You can find most groups there as well.

I don't know that all that much data needs to be associated with the track markers per se. Hopefully there is also ongoing communications. The vehicle itself could be counting down from the onset. If it IS included in the marker info, I guess the markers would be bar codes or RFID tags. Otherwise simple magnetic markers would suffice, triggering hall effect sensors or simple reed switches.
There are all kinds of communications and positioning tools that were not available just a few years ago, and more everyday. Anything in the equipment field we decide on today will be outdated tomorrow... All of this texting and tweeting is bound to engender some interesting LAN technologies in the not to distant future.