79> Somethin's Buggin' Me...

I would like to offer an update on the effort toward standardizing a track design for hanging, (gondola style) PRT. I have toyed with a few variations of the Acronym “SMART” which could stand for “Small-scale Modular Rapid Transit”, or “Standards-based Modularized Automated Rail Transport”, or some variation like that. Anyway I like the idea of a calling it the “SMART” system, and it will eventually describe an architecture that can broken down into separately contractible (and maintainable) parts, such as track, vehicles, controls and stations. This is to reduce the total vendor dependency, which municipalities have so far rejected. (post 77) In the last year I have shown many iterations of track for such a system, exploring various possible uses, including indoor and outdoor freight, high speed, group transport, platoons etc. trying to ascertain the most versatile dimensions and layout.

One “fly in the ointment” that I have recently identified is the matter of slope vs. overall height, from the bottom of the cab to the top of the track. In post 16 I show a vehicle being lifted vertically by an external chain. While complete vertical lift is not absolutely necessary, and is obviously less energy efficient than simply lifting passengers instead, I can still see where this might be advantageous. In a system that depends on pervasive local access for its usefulness, the need for inexpensive, barebones stations is great. Vertical travel capability permits the combination of the minimal footprint of elevator-equipped stations with the absolute station minimalism of bus stops. I don’t want to design that out. On the other hand, this requires a swing-arm of a height that is at least half as high as the passenger compartment is long. For example, an 8’ cab hung from the middle (4’ back) needs a 4’ pivot arm. If the vehicle has an auto-style “sit-down” cab, that is, say, only four 4’ high, that is still eight feet to the bottom of the track. Although this is advantageous from the point of view of keeping curious hands out of harm’s way, the problem is that I have previously identified a general track height of about 36 inches as a good minimum size for high speed, high-performance bogies. Add this to the 8’ previously noted and now we have a minimum overall height of 11’. Can this still go into buildings? My guess is yes, much of the time, although it is close enough that it would probably often be necessary to rework some of the support structure for the floor above. It would obviously be better to be able to simply hang track between floors.

 So what is a PRT designer to do? Well for one thing, perhaps recognize that 100 mph vehicles probably wouldn’t be docking in office buildings. That would be a lot of power (and motor weight) for getting around downtown. Can a slower system translate into something that can fit into buildings better? Perhaps. 

 

In the pictures above, note that the wheels have the flange typical of ordinary railroad cars. Whereas this high-wear part is normally made of steel, which is too loud for PRT use, in low speed environments I believe many abrasion resistant plastics would work. (Nylon comes to mind.) The flange can be separately replaceable. Note that this allows the elimination of the upper guide wheels. I considered a tilted wheel design instead, but with this design the wheels can span the track’s slot so that the bogie cannot physically fall out of containment on a “Y” or merge, provided there is a cantilevered “frog”. This continuous support also lessens strain on the reduced guide-wheel arrangement. The wheels are smaller, in this case being about 15”, and are based on readily available 3 kW hub motors for scooters. The top speed would be under 40 mph, but with dual-bogie designs (8 wheels, like a railroad car) the speed could be greater. Also 3 kW is not a magic number. There are a few more powerful hub motors out there in the same size range and none employ water-cooling, which boosts performance greatly. I want to note that do not know the nature of the structural differences between these low voltage, high amperage motors and the high voltage low amperage motors that would be better for electrified rail (rather than battery) systems… Can anyone shed some light on this? Anyway, this bogie style could run in the track for the high-speed and GRT designs I have previously shown. This design allows the track height to be reduced down to about 24 inches, enabling greater ease of installation in buildings.

More research needs to be done, though, on the average clearance between floors. There are a number of competitive building methods, and I imagine there are strong regional differences as well. For example, steel girder buildings tend to leave long (and tall) floor support trusses in place, supporting poured concrete floors, whereas concrete based building methods usually have more columns and therefore shorter spans for supporting the floor, which may be tensioned with cables in a more unified approach. I have never really spent much time poking around above the ceiling tiles in strange buildings. Perhaps I’ll pose as an exterminator sometime… “Bugs, Mam,” I’d say looking down from the step-ladder with a grim expression, “Big Ones!…”

I guess, if push came to shove, I would favor limiting the slope angle in lieu of building accessibility. In the meantime this gives reason to question any aspect of a standardized track design that adds unnecessary height. I have begun a study to determine how much angle is possible with how much swing-arm reduction and how that would affect station design. I’ll be keepin’ busy.

78> The Times, They Are a Changin....

I think it is time to acknowledge the obvious. The age of ubiquitous wireless digital communications has arrived, and largely rendered all previous methods obsolete. It is silly to not take advantage to technologies that have come of age. While these technologies are both powerful and inexpensive, they are not yet designed for safety- critical uses. Is there a way that these technologies can be harnessed for PRT in a way that is perfectly safe, yet extends the capabilities of a PRT system?

First let’s look at safety, and it’s cousin, reliability. For a system to really be perfectly safe it has to embrace the concept of a “fail-safe.” Alert reader and frequent contributor cmfseattle recently submitted this link, which demonstrated the fundamental principle of a fail-safe mechanism, that of being “always on.” This is opposed to a system that comes on in an emergency and is expected to do something, a far riskier proposition. A second concept that must be understood is that of “Mean Times Between Failures” (MTBF) and the concept of redundancy. Consider the tires on your car. It is rare to have a tire failure due to a manufacturing defect, but it occasionally does happen. But what are the odds of it happening to all four tires at once? From factory defects alone, essentially zero.

The MTBF for this scenario is probably in the tens of thousands of years, as it well should be. The MTBF must be correspondingly astronomical for critical PRT systems to pass regulatory scrutiny. 

Bringing all of this back to the subject of new technologies, it seems that a dividing line must be drawn between what can and cannot be controlled by such means. An argument can be made that these new technologies are not really essential. Indeed, the fundamental principles for PRT have been around for decades, and safe (and even approved) designs were attainable back then. Why change? The main reason is performance.

One factor limiting the performance of previous systems is the concept of line speed. Consider the case of two turns with a straightaway between them. If you are driving your car, in a hurry, you know just what to do. You round the first curve, step on the gas, and then decelerate for the second turn. With fixed line speed you only go as fast as the sharpest (slowest) turn allows. Many vehicles and track segments, of course, multiply this factor  so that it affects the throughput of the system as a whole. There is also the matter of passenger comfort. Previously the whole system would need to go at a speed dictated by the tendency of a small minority of passengers to get motion sick or alarmed by fast, automated travel. Having custom passenger speed preferences can greatly benefit passenger throughput as well. But it is more than many vehicles going a bit faster. It is also being able to route and merge more intelligently on a much larger scale. 

These and other factors call for a system of capable of managing extreme complexity, and so the fear is that this complexity would compromise safety and reliability. This is why I have called for system architecture that is flexible enough to advance with the times but has underpinnings that are fundamentally simple, perhaps even simpler than previous systems. Such an architecture, I would argue, should start with vehicles that can self-navigate and avoid collisions – The Autonomy I have spoken of in recent posts. Layered on that would be increasing capability and associated complexity. I envision a hierarchal system wherein a consensus of systems is needed to achieve peak performance, both in terms of individual vehicles and traffic management. Track or vehicles with some degree of problem would have the speed downgraded accordingly. This would enable an optimal condition where systems that may have MTBF of only a dozen years instead of millions can still contribute. This strategy is tailored to the benefits and shortcomings of wireless and networking technologies, which absolutely blow previous control methods out of the water by most metrics. These can be coupled with commodity computer parts and sensors to create a system that has stellar performance, yet is not the primary system, but an overlay upon it. It is better to design a safe, slow system that is endlessly improvable than a one with reasonable base performance but without an easy upgrade path. I would guess that this is also the easiest path toward high performance from a regulatory point of view as well.

The first step is to define the simplest system that can work safely and reliably. The second step would be to identify sensors and other systems that can be bump up this base speed to a reasonable level. The third step would be to overlay modern networking technology and sensor systems that support this third tier. The idea is that the “fail-safe” for the third tier is the second one, and the fail-safe for the second one is the first. If that one has a problem it is time to limp to the nearest station on battery power. 

What would this third tier look like? This would be one of those networking challenges that Cisco Systems and Google could really sink their teeth into. I have been trying to research networking models that would work but I must confess my relative ignorance in the field, although searching terms like “campus-wide LAN” or “Mobile WI-FI” are turning up some interesting technologies including VLANs,  Layer 2 and 3 switching, LECs, IEEE 802.16, mesh networking, ATM backbones, and a host of other concepts that I hope will make perfect sense to me someday.

77> I've Got Control Issues

I want to add something to the discussion of autonomy, which I did not want to have buried deep in comments section. In that post I again touched on the theme of not wanting to have a PRT implementation be performed by a single company. As I was mulling over my problems with the concept of zone controllers, a good phrase for what I think should be avoided came to me…. “vendor-dependant architecture.”

“Vendor-dependant architecture” is what you get when nobody knows how the system works but the vendor, nobody can build the system but the vendor, nobody can fix a problem but the vendor, nobody can get spare parts but the vendor, nobody can remedy cost or schedule overruns but the vendor…  The list goes on. In some cases even a continuing, active monitoring of the system is required and must be performed by the vendor into infinity.

Contrast this to a highway. The builder of the highway certainly doesn’t need to be called in if there is an accident. Once it is built, it is managed by the taxpayers through police, wreckers, road repair and street sweeper crews, etc. There is no question of needing the original contractor to come out to fix a damaged sign, for example. It is the safe choice.

With PRT, vender dependence is largely the result of the combined use of a number of arcane technologies. Everything is non-standard in size or use, if not downright experimental. In my view, having a centralized control architecture contributes to this vendor dependency because it essentially makes the track, stations, and vehicles into a single incomprehensible machine.

One thing I would like to see is for at least major portions of a PRT implementation to be a straightforward purchase/contract, with an actual endpoint. The obvious first candidate is the track. To do this, the track must be decoupled from the control system as much as possible. Any electronics or communications should be very easily serviceable.

The cars are the next big expense, and should be contractually decoupled as well. These could be purchased with a service contract or leased. Leasing has a good ring to it because it meters out money to the PRT system vender (or a separate vehicle maker) at a rate that would (hopefully) be proportional with revenue received from fares. Additionally it perpetuates the revenue stream to the vendor, but in a controlled way, helping to ensure that it can stay in business. (Including the repair business)  This is obviously a huge concern for a municipality stepping out on a limb to buy a bunch of unproven technology.

Stations, at least as far as the architectural end is concerned, can be treated as an ordinary construction contract. Proprietary standards, materials or methods should be avoided, where possible, so that replacement and repairs may be accomplished by the municipality.

The sticky point is the control system. As recent history exemplifies, even very large companies fail. Who is to ensure that the system will be up and running in ten years?

This is where a “vendor-dependent” design is a real drawback.

Here is the basic problem as I see it. The first is that the system must pass various hurdles related to safety standards. The second is that “vendor dependency” issue. The third is that the communication and sensor hardware is rapidly changing and improving, and often has its own interfaces and software, which must be either bypassed or integrated.  

The whole matter can be greatly simplified if a standardized control architecture can be created that can utilize a variety of sensing devices. I envision a system where the allowed velocity of the vehicle is contingent on the degree of consensus between redundant sensors and communications means. Whole sensor systems therefore, straight from the manufacturers, would be able to be swapped out within this general design architecture. If one manufacturer goes under, replace them and their sensors without redesigning the whole system. This design architecture would preferably utilize contrasting technologies with different strengths and weaknesses. Promising technologies include RFID tags, (used in 2getthere’s FROG navigation) Barcode readers, Hall effect sensors, object or color recognition software in conjunction with cameras, radar, ladar, and sonar.

As for communications, I think the “leaky RF cable” concept is hard to beat, especially if it can be done at frequencies that are compatible with wireless LAN protocols, such as Ethernet.  I have it in my mind that it would be easy to create “leaky” fiber optics, as well, since “Leaky” fiber is a commodity item, used for decorative lighting. I haven’t ever heard of it being used in this way before, but then again this is an unusual application. Including a channel within the track for such communications is no harder than fitting it for ordinary electrical wire. Of course ordinary wireless technologies such as Bluetooth or even WiFi might be used to some effect as well. One of the benefits to beginning with the assumption that the vehicles can work anonymously is that it allows for some errors or spottiness in communications without adversely affecting the system. This allows use of inexpensive commodity components. It’s a lot cheaper to use a system that is reliable 99% of the time than it is to use a system that is a “mission critical” 99.999% reliable. With communications of traffic data, for example, the messages can be repeated along the way, so if one is missed it’s no big deal. Even missing all of them, the worst that can happen is a traffic jam. 

Of note… Wheel motors for scooters are becoming a big business in Asia. I am starting work on a bogie designed around them that can work in the track I have shown as well as a more compact track for slower speed inner city use. That is why I have not shown any recent work on the track standards. I have been exploring these control issues with an eye on where communications and power strips should be placed that would be common to both designs. I have come to believe that the present track design is better for highway speeds and above, but is a bit oversized for the crowded downtown applications. Anyway it’s LATE and I’m outta here!

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.