FlyWay® and Road Traffic

Like prayer, the small car brings the family closer together.

n the page "Cooperation with the Road-traffic", we showed some examples of how a developed beam traffic system could be of great assistance to the road traffic. In the page "How Weaving Nodes handle Traffic" we discussed how FlyWay´s "intelligent nodes" will direct the beamcarried traffic. At the cross roads of these two is the interesting problem of how to quickly and efficiently transport motorcars between two traffic places by using beams instead of tying those places together with a highway. That´s what we are going to look at here. This is a fairly technical page, but it can nevertheless be read by anyone.		Note: this page is still under construction! General Looking at the example How the node computer does it

1. General

et´s look at the art of transporting motor vehicles the FlyWay® way! The task Figure 1:1 shows a typical example: 2 highways which connect densely populated areas (shown in orange) need to be connected in-between, perhaps across a recreational area, approximately along the dotted grey line. The traditional solution: a 6-lane highway right across! Suppose we instead erect beams along this line, and loading terminals for road vehicles at each end (A and B resp.). For this to be a viable idea, we would need a traffic handling capacity of this connection at least around 75% of the expected traffic flow. When building highways, one usually dimension these well above the anticipated traffic flow, expecting the traffic volume to grow in the years to come. Let´s do the same for this beam connection, for good measure! If each lane can handle a through-flow of 50 vehicles a minute, we need to dimension this beam connection for 6 * 50 = 300 vehicles per minute, for both directions taken together. If we assume that: Lowering a beam-carried flatcar takes 15 seconds. Off-loading the motor vehicle takes 15 seconds. Loading a new vehicle takes likewise 15 seconds. Raising the flatcar to the beam takes15 seconds.

Figure 1:1

Figure 1:2

hen, this whole procedure will take 1 minute. Locking and unlocking of braces around the wheels, to hold the motorcar during transport, is done automatically, and is performed during the setting down resp. raising of the flatcar. Those who have observed the loading/offloading of car ferries will realize that this simple operation could be done even faster than 1 minute, especially considering the fact that car ferries have to off-load all their cars before they can take on the next bunch of cars, going back. The FlyWay flatcars, by contrast, can release a motorcar in one direction and load another from the opposite side, as shown in figure 1:2. It is true that the speed of loading/unloading cars depends on how confident the drivers are of the procedure. This is just a matter of experience. When you have done this 10 times, as a driver, it´s no big deal anymore.

Figure 1:3

If you have read the page "Cooperation with the road-traffic", you will recognize figure 1:3. This solution requires the flatcar to turn 90 degrees before and after loading, which of course could be arranged. But that is an extra procedure, which increase the time for offloading and loading, and also slightly increases the risk of malfunction. In addition, such car (with a swiveling capability) would inevitably be more expensive. Let´s keep this operation as simple and quick as possible. As you might guess from the figures given, our arrangement must have the capability to move quite a lot of motorcars. FlyWay proposes a procedure which is safe and quick and can be a real, viable option to more highways.

2. Looking at the Example

ith a one-minute reloading time at each berth, there would theoretically be a need of 1 * 300 = 300 reloading berths at each end (points A and B in figure 1:1). This is, of course, quite a lot of reloading berths. But each berth won´t take much more space than the length of two motor vehicles. 150 such places in a row, on each side of the road, maybe somewhat at an angle, each 5 meters sideways to its neighbor, would occupy a stretch of road equal to about 5 * 150 = 750 meters. How close they actually can come to each other is a matter of beam design, which will be described further down. This is the theoretical side. The practical side is of course a bit trickier. If this arrangement is to going to function as smooth as in this outline, then every new motorcar would have to arrive at a flatcar the very moment it arrives, and just possibly is in the process of unloading another motorcar. That would of course rarely be the case in practice. Rather, at high traffic times there will be queues of, at most, 4 motorcars at each berth. If every reloading takes 1 minute, then the queueing time will be at the most 4 minutes. The average queueing time should be less than 2 minutes. That is not so hard for most drivers to put up with. There are two other matters to consider: Traffic flow is rarely at a maximum for more than one hour in the morning, and maybe 2 hours in the afternoon. If it was more than that, the original highway would have been provided with more lanes. Traffic is as a rule un-equally divided during the day; there is often more traffic in one direction than in the other. Most berth will thus be unused most of the time.

Figure 2:1

ow, compare figure 1:3 with figure 2:1 to the left. The blue lines are of course the beams, some 4-5 meters above the ground. You will note that a 90-degree twist in every beam segment before and after the berth, which will allow the flatcars to land and load/unload road vehicles without needing the swiveling function. This calls for real smooth handling of the beam cars, because there are 2 shunts for every such berth. In figure 2:2, we have emphasized the beams. All traffic, both on the beams and on the accessroads, move from right to left. Beamcars with vehicles to unload enter on the beam marked 1. Buffered beamcars are kept in readiness at right on beam 2. Loaded cars travel off on beam 2 to the left, and empty cars are shunted off to the left on beam 1. A node computer is in charge of this traffic flow. It directs all traffic in a synchronous manner, alloting a time slot to each moving car. At times when all these berths are in operation, this node control will be rather busy. It will constantly monitor all berths. Its tasks: As soon as a beamcar announces that it´s leaving, an incoming car will be directed toward that berth. If no beamcar is coming, a car from the buffer will be directed to that berth, by way of beam 3. An incoming beamcar has to be directed to a berth at once, as soon as it passes the Booking point, without having to stop. A berth that will (hopefully) be empty by the time the car gets there. Loaded cars that wants to leave will get slot allotments right away, without having to wait. Platooning might have to be implemented now and then. Could this really be made to work that smoothly? Yes, it could. But it takes a computer to manage it all.

Figure 2:2

3. How the Node Computer does it

Figure 3:1

he node uses timeslots to control the traffic around these berths, to prevent cars from getting in each others´ way. But these timeslots cannot move very fast in the arrangement in figure 2:2, since beamcars entering and leaving the berths need a few seconds to slow down, and then pick up speed again, when leaving the berth. A typical slot frequency here would be about 3 seconds. If a beamcar takes one minute to load/unload, and slightly less time if it arrives or leaves empty, then a berth would "generate" a new, leaving car every 60 seconds. 20 berths in a row would generate a beamcar every 60/20 = 3:rd second, which is the reason why we have limited the number of berths to 20 in this group. The next group of 20 berths could then be placed about 100 meters further down the road, but they would have to be joined by trunk lines, so that beamcars have time to accelerate and decelerate (this is illustrated in figure 3:1.). How many such groups of 20 berths (in this example) could we have in a row? That depends entirely on the traffic capacity of the trunk beam. If this capacity is infinite, then we could also have an infinite number of berths, arranged in groups like this. Well, then, the capacity of the trunk is clearly not infinite. At one point, if traffic demands grow, the capacity of the trunk will hamper traffic, right? No, not quite. Trunk beams are like highways, insofar as you can have several beams in parallel, just as you can have parallel traffic lanes. A properly designed beam network can swallow as much traffic as there is room for new beams.

How would it work? These beamcars could of course operate around the clock. But let´s say, for the sake of argument, that a group of 20 berths have been closed for the night (maybe for maintenance?). As daybreak comes, and the station goes into service, the node would start directing incoming beamcars to the berth which is furtherst away first (i.e. number 1 in figure 2:2. Then it would fill berth number 2, then number 3 and so on, supplementing with buffered cars if loaded beamcars are not arriving in sufficient numbers. Sending off a new car every 3 seconds, as the first minute is up, all the berths would be filled. The beamcars will then start leaving in an entirely random fashion, some of them will have to wait several minutes before a motorcar arrives. Every time a departing beamcar asks for (and gets assigned) a timeslot, a new beamcar is sent out, to fill the berth. Two (or more) beamcars requesting a slot at the same time will be processed one at a time; real simultaneous does not exist in this context. If the beamcars use Bluetooth communication, call collision is automatically avoided. Traffic direction and control is shown in the overview in figure 3:2, where the trunkbeam has been included. Arriving beamcars with vehicles to unload leave the trunk by way of beams 6 and 3. Empty, arriving beamcars join the buffer by way of beam 5. Departing cars with cargo (or which have been assigned a destination) use beam 4 to join the trunk. These connecting beams (4, 5 and 6) are long and smooth enough to allow cars to join and leave the trunk beam at full speed.

How are motorists handled? The first question is: How do motorists select the "best" berth, to avoid queueing? Well, one could have visual aids, like a clearly visible digit on a high-placed sign at each berth. "Zero" would indicate "no cars queueing", "2" would indicate "two cars queueing", "4" would indicate "four cars queueing, go to another berth". The second question is: How do motorists pay for the trip? A convenient way would be a magnetic card in the windshield, coupled to a bank account. A scanner at the berth would automatically read this card as the motorcar enters the berth. An alternative would be a "smart" card reader, to be used while queueing. One could also let the driver use the same kind of Bluetooth interface as is envisioned for ordinary passengers. The third question is: How are passengers in the motorcar handled? No bif deal, they travel free of charge. The fourth question is: How do we deal with "freeloaders"? If a driver does not use any of these methods to pay the fare, he gets a "free" ride to the nearest manual control station, where he can pay in cash, or at least get identified. The fifth question is: How does the driver inform the beamcar where he wants to go? An easy method would be a button panel on the flatcar; one button, or combination of buttons, for each destination. He could also use his Bluetooth unit to communicate with the booking system, that directs the flatcar where he wants to go.

Figure 3:2

he "intelligent" node control could handle the traffic more efficiently by taking into account the actual distances between the berths. Cars that leave berths 1, 6, 11 and 16 could for instance leave almost simultaneously, and fall in behind each other.

Provided, of course, that any (or all) of them are ready to leave at about the same moment. Likewise could cars 2, 7, 12 and 17 leave at the same time, and so on. But, when directing the traffic in this manner, the node control has to take care that these "subgroups" are kept separate from other subgroups.

This is an example of successive weaving, which normally is handled by one node for each weaving point. The difference here is that we cannot have booking points in a row for beamcars that have already left their berths, just because they happen to pass other berths. That would generate too much communication overhead. But, by trimming its parameters, one node could handle all the weaving for these berths.