107> An App for that.

In the world of TCP/IP, and even Ethernet, and especially any wireless version of either, there are transmission delays that limit what such technologies can do for synchronizing PRT vehicles. That is not to say that such delays cannot be overcome. The problem is that off-the-shelf solutions are only just emerging. Building an IP-based PRT network infrastructure that doesn’t rely on proprietary techniques is, for the time being, still fairly complicated.

Modern computer networking involves lots and lots of flexibility, security, compatibility and legacy issues. After all, computers are used for all sorts of things that were developed over time by many players. Anything resembling a standard communication procedure needs to address many unknowns. Remarkably, the present systems are designed to handle messages of unknown length, coming in at unknown speed, which will be forwarded along an unknown route. The original designers of these systems wisely prioritized accuracy and completeness of the data being sent over speed, and the protocols reflect this. Hence these systems (as they analyze and sort bits of information like a postal worker sorting letters) produce the delays we refer to as latency.

Luckily PRT vehicle control is not the only application that requires minimal network latency. Two others come to mind. The first is industrial processes. Machinery must often interact with split-second precision. The ubiquity of Ethernet as a way to network computers has created a market for methods to achieve “real-time” process control using the same equipment. One interesting open-source project worth exploring is RTnet, which has advanced to the point of having suites of development tools written for it.

A second area driving change is VOIP. (Voice Over Internet Protocol)  You see, VOIP cannot tolerate latency. Unlike the data packets that will re-assemble into an Email or even a streaming movie, the packets that comprise your telephone conversation must arrive in order and on time. (relatively speaking)  With new “smart phones” appearing daily, higher quality VOIP is becoming essential. Getting there involves a reversal of the previous priority of completeness and accuracy. For example, if a split-second part of a conversation is lost or scrambled, it should just be tossed out, leaving a click or silent spot in the audio. In ordinary TCP/IP, the system would detect the damaged data and ask that it be resent, even if it came in two seconds late. The bottom line is VOIP is forcing a rethink of this and all of the other latency producing steps used in communication and networking. Furthermore, telephones are inherently mobile. When a person travels down the highway talking on the phone he is forcing the network to find a seamless way to “hand-off” his call from one antenna (network access point) to another. This is similar to the problem PRT designers face if they want to minimize the number of vehicles in any subnet and want to minimize the number of hops any transmission must take.

Telephone standards have been referred to in terms of which “generation” they come from. We are coming to the end of the 3G era. Aspects of 4G are already appearing. Whereas some 3G systems had legacy analog capabilities for better phone reception, 4G is 100% packet based. Previously cellular carriers had little incentive to adhere tightly to standards such as the various flavors of IEEE 802, preferring to compete with proprietary protocols. The convergence of corporate data networks, internet, smart phones and the like will surely lead to more “Plug-and-Play” solutions for mobile users interacting with private networks. And that means more standardization between carriers. And, speaking of IEEE 802.xx, the next generation of standards (such as 802.20) looks pretty awesome. But what is “state of the art” now?

There is a lot of activity surrounding the 802.16e standard, which is being commercialized as “WiMAX.” (successor to WiFi) Supposedly latencies are in the in the 40 ms range, but I’m skeptical as to whether real world performance is anything like that. I assume, for example that that is a one-way number, which would double in a round-trip message that included a confirmation. But I am no expert. 

I also am not sure what, specifically, can be done with a guaranteed round-trip transmission in, say, 50 ms that can’t be done with a turnaround time of a second or more. It seems to me that for real split-second control issues, 50 ms is still an eternity. It is possible that real-time Ethernet (like RT net) could be adapted for “leaky cable” but that seems like a lot of effort for the hypothetical portion of the PRT control that needs 10ms to one second access times. After all, there is still direct sensing and switching, which is essentially instantaneous. I guess it would be worthwhile to take a good look at the specific maneuvers that a PRT vehicle must make in terms of actual time requirements, from control signal to electro-mechanical response, before getting too far in terms of favoring one technology over another. More specifically, I question whether sub-second communications are really necessary for pre-merge maneuvers. This question leads to track layout and capacity considerations as much as anything else. Should vehicles be packed so closely together and run so fast between closely spaced merge points as to necessitate split-second communications? It seems to me that a little traffic management and prudent track design could go a long way toward allowing a bit of latency. And there is also my often-stated preference for putting more control at the vehicular level, limiting the need for top-down control.  Meanwhile, technology marches on. Maybe PRT should run on the Android OS!  

106> Simple Circuits

For those of you expecting, from the last post, for me to explain my method of requiring only a byte-sized communications to perform a merge, I’m afraid I have to retract that claim. What seemed, at first glance, to be a two-bit digital message is more accurately a couple of blips in an analogue signal, because the timing of the blips is part of the message. It is a moot point, though, because from a transmission point of view it is much smaller and simpler than preparing any sized packet, the usual way of sending it in digitized form.

I want to reiterate that I am not trying to reinvent the wheel. Some variant of ordinary digital networking technology is certainly the way to go as a primary system. I believe, however, that the following examination is worth doing for a number of reasons. For one thing, it forces us to look squarely at the details of the task at hand, which gives direction to what future PRT software and network structure might look like. Secondly, it relates more directly to the kind of systems that have gained regulatory approval in the past, such as trains or people movers. It is possible that it might be simpler to gain approval for a system that is built on top of the same kind of circuit-switched system logic that older, approved systems use. Thirdly, if there will be a back-up system, it would seem logical to have something dissimilar enough to be easily and completely partitioned from the primary. Lastly, this blog has some role to play as an educational resource. Exploration of the problems of control and safety can be simplified by doing so in an allegorical way, since most readers are not well versed in modern telecommunications methodologies. All that being said… 

 

This illustration shows the information accumulated over a few seconds by two proximity sensors positioned at corresponding locations on the two tracks leading to an upcoming merge point. The vertical lines represent units of time and the numbered “blips” represent PRT vehicles. In an animated version of this illustration everything would be traveling right to left, so that information gathered on the left of the picture is older than the information on the right. Imagine it like a window looking out on a highway with the traffic moving right to left, and a snapshot has been taken as the fourth vehicle crosses the midpoint of the field of vision.

Here a reference voltage drops with the breaking of a beam, although other schemes could be used. In this example the vehicles mark twice, once at the front of the vehicle and once at the back. This enables the calculation of velocity. This, then, gives all of the necessary information required to determine if the sampled vehicles will have a conflict at the merge point, and what routines can be used to solve it. Additional monitoring points can be used to create a complete picture of traffic, although from any particular vehicle’s point of view very little of that picture is actually relevant. The picture above represents the “view” of vehicle 4.

Below shows the required broadcast areas for such a system. Traveling through such an area gives each vehicle a chance to construct a representation like the illustration above by “listening” to the traffic cross the sensors in real time. Each vehicle would have a different “picture.”  I would suggest that sending the data directly in such a raw form through dedicated channels, fibers or circuits might well make more sense than digitizing it on the spot and directing it through a multicast addressing protocol, especially as a back-up system. In such a scheme normal attenuation (fading of the signal as distance from the transmission source increases) could limit the communications to the relevant vehicles. Note, however, that no communication between vehicles is actually required. If they all have the same information they would, in theory, move independently in the “faith” that neighboring vehicles would be moving as expected as well. This would be highly risky but for the fact that some form of headway distance monitoring is already required as part of a collision avoidance safety system.

I dislike, as is well known, the notion of complicating the track with sensors and controllers as a general rule, and this scheme doesn’t change that. But one can never weigh any trade-off without examining both sides. This round goes to the wayside control model, although a vehicle-based equivalent is doable. For example, the vehicles themselves could “sound-off” as they pass a marker or RFID tag, and a pair of non-interfering RF channels could be used in a leaky feeder system. (I believe I have been too worried about “cross-talk” with a leaky feeder system. There should be plenty of radio bands available that can coexist on one or more cables.)

 

On a personal note, I am back from New Hampshire, and will get to my Email backlog very soon. Besides making a portable shower stall that snaps together like Styrofoam Legos and a solar hot water heater, I made good progress on this 14x18’ experimental structure that will be a garage/shop/storage building and a place to hang an electrical meter. (My cabin is too far from the road for electric service, but I really need my power tools)  I have been a busy boy! I wish I had cleaned the site a bit before taking the picture, but it’s all clean and partially sheathed now. By the way, what’s shown is less than $1600. into the project, including everything – labor, delivery, and materials. (including the 25 tons of gravel under the insulated, pre-plumbed slab) I should have it completely dried in for under $8. sq. ft. Now that’s sweat equity!… and my excuse for posting so infrequently over the past 7 weeks. I thought you all might like to know where I’ve been.

105> A Voice from the Woods!

I think it is high time we talk about control with a bit more specificity. Here are some thoughts to ponder.

It seems to me that if everything else fails, PRT vehicles should still be capable of getting to the next station, at a reduced, uniform speed, without hitting each other. This implies a certain amount of autonomy. It also seems to me that PRT should certainly have full and speedy Internet, and also be networked for traffic management purposes.

As far as control goes, it gets a little more complicated. Because of safety concerns, certain aspects must be virtually instantaneous. One would not, for example, want to have to call a central server to suggest that a collision is imminent and an appropriate braking routine is needed.

 

Let’s take a look at who needs to talk to whom. Fig. 1 shows the obvious case of vehicle A needing to communicate with leading and tailing vehicles. What is not as obvious is that since this zone of needed communications is constantly moving, a centralized control system has no built-in way to keep the relationship between the vehicles special. A zone-based hierarchy (zone controller) would limit the number of vehicles that are communicating to a better number. (note: It is quite possible that an off-the-shelf Linux-based router can be hacked (in the firmware) to make a serviceable zone controller, something that would address most of my previously stated concerns) However that is all a bit off-topic, because I still do not think one is needed.

In Fig. 2, we address the matter of merges. Here I have used the same red zone to indicate where instantaneous communication is most important, with the blue arrows indicating the lines of communication. Here again, there is a special relationship between a small number of vehicles, and this relationship persists until there is an interchange. In this picture we have four little networks that must have very fast communications. It is not clear to me whether communications with any entity outside of this network needs to be particularly fast.

Here’s where all of this leads. First, as a last resort backup, (hurricanes, terrorists, sunspots, earthquakes, plane crashes) the lines of communication shown in blue must persist, or vehicles will be stranded. This is a big no-no if there is no easy way to exit the vehicle. Also it seems probable that regulatory approval would be easiest to approach with a slow, “failsafe” mode first. So… If we assume that we want such an autonomous mode underlying the rest then what “rest” are we talking about?

I, for one, have not identified any communications other than those shown in blue that need to be particularly fast at all. If that is the case, why not have the rest be internet-based, and take advantage of the existing cellular or satellite infrastructures? Such a scheme would isolate the high-speed from the safety portion of the problem in a way that would seem logical.

The fact is that the lines of communication that we are talking about are not even particularly well suited to normal TCP/IP communications in the first place. If such a task were easy, the military would certainly like to know, for such a thing would greatly enhance battlefield strategies. . Requiring ad hoc “mesh” networks are not great way to simplify a PRT system, in my opinion. It reminds me of my friends daughter, who likes to “text” with her friends, even when they are in the same room, and could simply talk instead. Maybe a better example is a fire alarm that alerts your smart phone instead of making it’s own audible signal.

Surgeons fix things with scalpels, carpenters with wood and nails. Is it possible there is a little of that going on here with my IT savvy readers? After all, working systems have been around since before TCP/IP was invented, based on direct switching and signaling. And, by the way, there is precedent for this in the form of current railroad practice. I’m not so sure where we stand on the other, in terms of gaining regulatory approval.

Don’t get me wrong. I believe that the last 10% or more of optimal throughput will absolutely require an advanced dedicated network infrastructure. This future capability must be baked in from the start. I believe though, that we must be careful not to lump real-time control issues (collision avoidance) with traffic management, which can easily have latencies of many seconds without consequence. I have analyzed what exactly would have to be communicated on those little blue arrows and it is amazingly little – less than a byte each way. If I told you how, though,.. well, I’d have to think of something else to write about next time!