The FlyWay Guidance System

Previous page: Control and supervision To Main Page To Header Page for this section Index of terms used on this site Next page: How Weaving Nodes handle Traffic
There are philosophers: they see things as they are, and they ask "Why?"
And then there are inventors: they dream of things that never were, and they ask "Why not?"

FlyWay is SwedeTrack System´s own solution to the urban public transportation problem

Anfang he Guidance System is the most complex part of all those computerized systems that keep the FLYWAY network operational. As the name implies, the Guidance System is supposed to guide the beamcars safely and efficiently through the maze of beams, from start to destination.

This is a very technical page, intended for those actively involved in the steering and control of automatic vehicles. The process of "weaving" traffic is part of the Guidance System, and this is treated on a separate page.

  1. General
  2. The Point-synchronous system
  3. Functional division of the beam network
  4. Using the timeslots
  5. The connection between timeslot and speed
  6. How weaving nodes handle traffic
  7. The coordination between synchronous and asynchronous traffic control

1. General

A well functioning guidance system is so essential to the functioning of the beam network that most components whooly or partly fulfill tasks that are, in some way or other, also filled by other components. There is a considerable redundancy in the system, with the aim of keeping the traffic running safely even in the face of failing components or system parts. The hardware involved is:
    Courtesy Visulogik
  1. Computers in the beamcars
  2. Computers in the nodes
  3. Computers at some stations
  4. Regional computers (when the network gets big enough to motivate this)
  5. A central supervising computer
  6. Sensors in the beams to keep the nodes informed about the whereabouts of the cars
  7. Position markers inside the beams, to keep the beamcars informed about their positions
  8. Obstacle detectors preferably stationary).

 There are in principle three different ways to run a system such as this:
  1. The Synchronous system
  2. The Asynchronous system
  3. The Point-Synchronous system
These are all described elsewhere.
FlyWay will use the Point-Synchronous system, but this is not as clearcut as might seem. The implementation of such a system, with the ambition that it should be able to grow painlessly, and without alterations, as the network grows and becomes more complex, is a daunting task. It requires a thorough knowledge of the theory behind automatically controlled transportation systems such as this.

The object of this webpage is to dig into this, and see where we end up.

2. The Point-Synchronous System

Short Description of how it will be used by FlyWay

1) All beam segments belong to either of 2 categories:
  • The synchronous category, where beamcars are put into a timeslot, and travel within this slot at the speed mandated by the node computer in charge of the segment. It is, in principle, not permitted for a vehicle to stop on such a beam segment, although the speed can vary considerably.

  • The asynchronous category, where each beamcar controls its own speed, taking due consideration to speed limits, other beamcars and obstructing objects. The car is permitted to stop and performing other manoevres, provided it informs the regional computer or broadcasts to other nearby beamcars what it is doing.

2) Requests for Timeslots:
The request to a node computer for allocation of a timeslot from a beamcar is made while the car is still on an asynchronous beam segment, and is about to enter a synchronous beam segment via a booking point (see figure 3:3 below). All access to synchronous beam segments are made through such points. Beamcars always leave synchronous beam segments through diverging nodes. As stated, there is no stopping allowed on synchronous beam segments.

3) Allocation of Timeslots:
Allocation of timeslots are made on a first-come first-served basis. There are 2 general situations:

  1. The beamcar is already on a synchronous beam segment, about to enter a weaving point. In this case, it will be just keep its timeslot, but will be subject to speed regulation by the node.

  2. The waiting car is on an asynchronous beam segment, maybe about to depart from a stop. It tells the central computer and the upcoming node controll where it is, where it wants to go and possibly also desired departure/arrival time (there will be a parameter for "urgency" that can be set). The node computer checks in the table for booked slots which timeslots are available. Next, the node computer assigns a timeslot for the vehicle, updates central computer, other nodes and the vehicle, and also enters this timeslot into a table for booked slots. As the next request arrives, there is one more entry to add to this table.
As the vehicle reports that the journey is completed, or that it leaves a synchronous beam and enters an asynchronous beam, its entry is removed from this table.		 4) Congestion:
Courtesy Visulogik If requests for slots from waiting cars are pouring in faster than the vehicles which are out and running can complete their journeys, it would be increasingly hard for the node computers to find an empty slot, and delays would generally increase in the beam network. Such queueing would then occur only on asynchronous beam segments, while on synchronous segments the traffic would run in a normal fashion. This would be a sign that the network is too small in regard to both the number of beamcars and to the traffic demand.

5) The need for Regional Computers:
But beamcars need to be in constant contact with a network computer also when travelling in areas with asynchronous traffic. Thus, for every beam segment in the network, there has to be a stationary computer, responsible for this contact. Since the network would thus be divided into regions, it is logical to refer to these computers as regional computers, and that´s what we will do on this page (see figure 3:5 below).

6) Termination of beams:
From the definitions of synchronous and asynchronous beams (see next chapter) it can be concluded that:

  1. Asynchronous beams can terminate anywhere, since the vehicles take care of themselves.

  2. Synchronous beams cannot be allowed to just terminate A dead-end synchronous beam just would not function.

    Nor can they be re-classified as asynchronous beams at just any point. But this is just a computer-administrative definition. In reality, one treats such a situation as if there were a diverging node, where both the ensuing legs are asynchronous, and one leg is "virtual".

    But synchronous beams can form continuous loops, or both legs after a diverging node can be re-classified as asynchronous as mentioned (see figure 2:2, where the synchronous beam is blue) This last condition should reasonably be allowed to apply, since one of the ensuing legs after a diverging node can be re-classified as asynchronous.

Permitted and not permitted ways of terminating a synchronous beam
Figure 2:2: Terminating a synchronous beam

3. Functional Division of the Beam Network

How the beam network can be divided from a functional point of view
Figure 3:1
Using some drawings, we will here explain the principles governing how the beam segments are divided into synchronous and asynchronous categories.

Looking at figure 3:2, we could regard the asynchronous parts as isolated "islands" (shown in yellow) joined together by synchronous beams. If in future there comes a need for more stations or nodes along these stretches of beams, new "yellow" (asynchronous) areas will appear. Now, this representation is a bit ambigious, because;

  • When these connecting beams consist of trunk lines, the traffic is best served by being under synchronous control. There are 3 reasons for this:

    1. the cars would anyhow not be permitted to stop on trunk lines
    2. the node at the receiving end is best served by having the booking point as far removed rom the point of weaving as possible; it gives the node controller more time to plan traffic flow in the weaving point optimally
    3. the journey will be less "jerky" if the car is synchronically controlled.

  • When the connecting beams consist of other types of beams than purely for thru-traffic (as may well be the case), these beams should be asynchronous.

In figures 3:1, 3:2 and 3:4 we have depicted synchronous beams with blue and asynchronous beams with red. As figure 3:1 shows:

  1. All beams leading to a weaving node are synchronous from the booking points on, up to the weaving node
  2. After passing diverging nodes, the beams leading to on-line stations or station areas are asynchronous.

Similarly, figure 3:2 tries to show that:

  • Many synchronous beams "turn red", i.e. they become asynchronous when passing into the yellow area, by passing through a diverging node.

  • Many synchronous beams keep their synchronous status through the asynchronous (yellow) area. They could be likened by motor highways going right thru cities, having booking points to access beams at suitable places.

The booking points (figure 3:3) should ideally be equi-distant from the weaving node control, since this makes it easier for the computer to calculate the weaving. But this point should also be as far away from the weaving node as possible, for the reason stated above. The decision where to place these points is better made in each individual case.

In a closer look at the beams, figure 3:4 shows a blue (i.e. synchronous) trunk line, surrounded by station areas. For simplicity, only a one-way beam has been shown. Beamcars can reach the station area by leaving the trunk on a few places, whereupon they enter asynchronous beams. Likewise, when entering onto the beam, they will have to pass booking points and be alloted a timeslot by the node controller in charge. Note where (and why) the beam is blue resp. red!

Since the beamcars could (and should!) stop here and there, the beams containing berths, parking areas and car buffering zones are of course asynchronous. But, to avoid chaos and ensure smooth rides, the internally connecting beams, as well as the beams joining this area with the surrounding world have to by under synchronous control.

Nodal Control and Regional Controls

As defined on other pages:
  • A node computer is in charge of one or (maybe) more nodes. It controls in a synchronous fashion the beams leading up to those nodes.

    Courtesy Visulogik

  • A regional computer is in charge of a limited geographical area (in big networks), consisting of both synchronous and asynchronous beams. This computer have various administrative functions as well as traffic control, but could physically double as a node controller.

The control of, and communications with, the beamcars on synchronous beams is done by the node computer at the node which the car is approaching Thus the blue beams actually "belong" to the (yellow) node controllers they are leading to, while traffic on the asynchronous beams inside the yellow areas are controlled by the regional computer to which the nodal (yellow) area belongs. Confusing? Yes, but logical, if you think it through.

Figure 3:6 clarifies this matter somewhat. All lines leading up to a node are synchronous from the booking points to the node, and controlled by that node. After nodes B and D, the beams turn asynchronous and will be controlled by the regional computer. The beams after nodes A and C remain synchronous, and will thus remain under node computer control. But not by nodes A and C, but by the nodes that those beams are leading up to.

So, this overlapping of yellow and grey areas (as shown in figure 3:5) is not a cause for conflict, because the functions of these computers are different.

Here are simple examples of how it would work:

Principal division of beam networks into synchronous and asynchronous traffic areas
Figure 3:2

Network convergence and divergence points

Figure 3:3

Dividing the beam network into synchronous and asynchronous traffic areas

Figure 3:4

Dividing the beam network into traffic control areas

Figure 3:5

How booking points influence division of beam networks into synchronous and asynchronous traffic areas

Figure 3:6

4. Using the Timeslots

Animation showing how time slots (blue and orange) move along with the traffic
Figure 4:1
The timeslot concept is the key to understanding how the synchronous (and the point-synchronous) traffic system works. It is explained on the general page about the guidance system. One can calculate the safe rate at which the vehicles can be dispatched on the synchronous part of the beam network, taking into account their speed, cabin lengths and required safety distances.

Figure 4:1 provides a simplified view of how the timeslots travel on (in this example) a circular synchronous beam, which is joined at som places by asynchronous beams. As explained elsewhere, the timeslots could be considerad as imaginary beam vehicles. A vehicle that joins from an asynchronous beam will fill a vacant slot, and a vehicle that leaves the synchronous beam will vacata a timeslot and make it available for another vehicle. So far, so good. But there are complicating factors:
  1. Allowed speeds might vary along different parts of the beams.

  2. At divergent nodes, speeds might have to be adjusted to the fact that vehicles might have to slow down to negotiate sharp curves when entering one or both arms.

  3. Vehicles of varying lengths influence the safety distances.

  4. Vehicles of varying weights might influence the safety distances, insofar as they might need longer braking distances in order not to put undue longitudinal strain on beam supports.

  5. Safety distances might vary during a day, because of traffic demands.

5. The Connection between Timeslot and Speed

Courtesy Visulogik Clearly, travel speed cannot be constant everywhere and all the time in the synchronous beam network, if we are to make use of its full capacity. To set the speed limits everywhere equal to the lowest permitted speed would simplify the handling of the network, but it would be wasteful of capacity. Instead, the goal must be to eliminate or minimize as much as possible the factors that influence maximum allowed speed. The factors that influence speed on a synchronous beam segment are:
  1. general speed regulations for the area
  2. size of the beam
  3. beam is passing station or parking area with many inlets and outlets
  4. time of day, day of week
  5. temporary situation, such as maintenance work on or nearby beam segments
  6. sloping or curving beam
  7. cars that change travel directions in diverging shunts might have to slow down as needed to adapt to situation immediately after the shunt
  8. heavy vehicles and heavily loaded vehicles have to slow down more at diverging shunts and in curves than light vehicles need to do
  9. long vehicles might need longer headways to the vehicles ahead
  10. heavy vehicles and heavily loaded vehicles might need longer headways to the vehicles ahead in order to brake
  11. there might be different mandated speeds for goods transports and for people transports
  12. rescue vehicles and vehicles without passengers or goods would be allowed to travel faster than is regulated by "brickwall stop" demands, and maybe other safety limits as well.

It could be that a small or empty vehicle catches up with a vehicle that for one of the reasons above moves slower. The second vehicle would then (of course) have to adopt the same speed as the vehicle ahead.

Traffic Speed and Weaving Nodes

Generation and absorbtion of timeslots

Figure 5:1

A new timeslot is generated for a beam every Tts seconds, and the value of Tts comes from the obvious formula:
Tts = H / v

where:
H = headway between vehicles
v = the momentary speed on the beam segment.

Since v will vary according to the factors listed above, and since required headway depends on vehicle speed (and a few other factors), timeslot generation at a node can vary considerably. If several weaving nodes are connected with synchronous beams (as in figure 5:1), there will be much communications overhead between these nodes in order to keep coordinated timeslot speeds, and probably quite a few "wasted" timeslots at high traffic times. This could be avoided by letting the traffic travel asynchronologically along som stretches between these nodes. This need becomes bigger as traffic grows.

A succession of weaving nodes have the potential to, from time to time, create congestion-situations, where traffic cannot flow at top speed. If all the beams in figure 5:1 have the same traffic capacity, then it´s clear that confluent maximum traffic from nodes C and F can only move at half speed, due to the constraint on the beam between nodes B and A. The same applies to traffic joining up at node E. The successive confluences will then further reduce the overall speed, if the feeder traffic to each node is at or near capacity. This is of course primarily a design problem. But how do the node controllers deal with this?

If this were an asynchronous network, the beamcars would regulate their own speeds up to the booking points before each node, where the node controllers would allot timeslots, thus keeping the traffic moving. But if all the beams are synchronous all the way, all the nodes would have to adjust their timeslot speeds to the speeds of the "downstream" nodes. This could be accomplished by the "downstream" nodes continually keeping the "upstream" nodes informed of their own timeslot speeds. Since this information travells and is processed much faster than the vehicles moves, this would conceivable enable the nodes to adjust slot-speed so that the vehicles to stay in their timeslots. This could be trimmed so that the system would rather let some empty slots slip by, than take the risk of trying to fill all slots.

Just the same, there would need to be provisions for instances where beamcars cannot keep up with their timeslots, because they have other vehicles blocking the way. Trying to assign new timeslots to these vehicles would create an administrative mess! It would in such a case be better for the affected node to temporarily convert the beam to asynchronous mode, and then simply monitor traffic for an opportunity to reassert timeslot allotment to vehicles that have not yet passed the node´s booking points.

As an example, node E loses control of its traffic, and converts the beam to asynchronous mode (depicted in red), and then informs node D about the situation. Node D should then assist node E in regaining control of its beams by slowing down timeslot speed. Since the real reason for beamcars not being able to stay in their slots is downstream congestion, this slowing down will help beamcars to stay in their slots.

Proposed solutions for FlyWay

Considering the listing in the foregoing chapter:

A change in permitted speed on various synchronous beam sections, as in example A in figure 5:2 below, could be solved in 5 different manners. Variants of these solutions are also possible.

  1. One could change the low-speed part into an asynchronous beam section, as in example B, and let the beamcars regulate their own speed. Since synchronous beam sections cannot stop abruptly, one could make loops at each end, in connection with diverging nodes (D) and continue with the synchronous beam in other directions.

    If this is not a satisfactory solution, one could split the beam and thus divide up the traffic load, as in example C. This would not reduce traffic capacity, and would have the chance of leading one of these beams along a different street.

    A permitted way to terminate synchronous beams, if loops (as in B) is not a good solution, is to use virtual divergent nodes as in example D. The non-existent arm is treated by the computer as if it were permanently blocked by queued cars. Since both arms are asynchronous, congestion is a situation that can be handled here. The beam section with 40 km/h. is, as in B, asynchronous.

    Example E shows yet another solution. Virtual weaving nodes will require booking points (B), where traffic speed is altered to adapt for the "virtual" traffic from the "virtual" arm. Since traffic speed increases at the right virtual node, it could properly be treated as a divergent node. But it really should not matter which kind of node this is.

  2. Normally, diverging nodes should be so "smooth" that vehicles should not have to slow down when entering them. But such "smooth" conditions cannot always be guranteed; there might not be sufficient space for the beams. The best way to deal with this would probably be to have a booking point ahead of the node, where affected vehicles are provided with "new" timeslots at lower speed.

  3. Varying lengths of vehicles are best dealth with by assuming that all vehicles have the same length. At times and situations where brickwall stops are not strictly adhered to, this length could conceivably be a bit shorter than the maximum length.

  4. Heavier vehicles might need longer braking distances, if one does not want to spend money for sturdier beam supports. This will increase the required headway. There is always the theoretical possibillity of letting heavy (and also long) vehicles travel on their own beams. Since this might not always be practical, the problem has to be dealth with in another manner. The simplest way is probably to treat such vehicles as "platooned" ordinary vehicles, and allot them 2 timeslots. This is not efficient if there are many such vehicles, but if they constitute not more than 15-20% of the fleet, the loss in traffic efficiency is acceptable.

  5. Safety distances might vary from time to time. At low traffic times, brickwall safety could be adhered to, but this might not be the case during high traffic periods, as this would reduce network capacity. From a computerized viewpoint, there is no problem with altering timeslot spacing and speed according to schedules.

Permitted speed in various beam traffic situations

Figure 5:2

6. How Weaving Nodes Handle Traffic

In the point-synchronous system, the merging of two traffic streams into one is best accomplished by letting the node computer control traffic on the two guideways, from so-called "booking points, one on each guideway, up to the point of merger. This is done by allotment of timeslots, which is thus refered to as "synchronous control". Whether traffic is synchronous or asynchronous after this merger is not important to this node control.

This might sound simple, but the actual procedure, the handling of various contingencies and the possibility for various degrees of "intelligence" and forward planning in the merging process makes this a rather complicated task. We have therefore devoted a separate page for this.

 Courtesy Visulogik A beam traffic weaving node

Figure 6:1

7. The Coordination between Synchronous and Asynchronous Traffic Control

As explained above and on the page "The Guidance System", the point-synchronous traffic control system uses the best parts of two different traffic control technologies in conjunction. The FlyWay application includes these features:
  1. Synchronous control of weaving traffic together.

  2. Synchronous control of trunklines and long tretches of beams, to ensure smooth travel and better control of beamcars.

  3. Asynchronous traffic control at stations, loading places, along beams where cars are allowed to stop.

  4. Asynchronous traffic control in between successive weaving nodes to ease congestion and reduce coordination needs between weaving node controls.

  5. Flexible reassignment of beam segments between asynchronous and synchronous operation modes, to optimize performance.

  6. Treatment of shunts placed close together as one node, topologically.
Illustrating traffic cushions in asynchronous beam traffic
Figure 7:1
One could regard the asynchronous network segments as traffical "cushions". They take care of overflowing traffic, they can buffer beamcars and queue them, if need be. This makes it unnecessary for the synchronous node to synchronize timeslot generation over long distances. Thus, this "cushioning" is what makes the network scalable, and able to grow indefinitely. Figure 7:2 below illustrates the effect of having booking points close to the weaving point, respectively far off. If we assume the same traffic capacity on all three lines, it is clear that, as soon as the feeding traffic volume on beams 1 and 2 taken together exceeds half their beam capacity, traffic starts piling up.

Assuming that the length of beams for queued vehicles before the booking points is sufficiently long in both cases, one can see that in case A, the beamcars have much shorter distance in which to pick up speed than in case B. The node processor also has much shorter time to allocate timeslots in case A than in case B. Does that matter? Yes, as stated above, some cars might need 2 timeslots, and in case A, the node will be pretty "harried" to make that decision, since it won´t be told about that until the car in question has passed the booking point.

One can conclude from this that, both at low traffic intensity and in congestion situations, both beamcars and nodes are best off with their booking points as far away as possible.

As stated on other pages, the FlyWay® beamcars are intelligent enough to find their own way through the asynchronous network without outside communication, if need be.

To top of Page

Two examples of how queues can be handled at weaving nodes in a beam network
Figure 7:2
Copyright © 2004, SwedeTrack System.
Last Updated: 2007-01-17
 Webmaster
 This site is maintained by Johnson Consulting