The Guidance System

Ambition is a poor excuse for not having enough sense to be lazy.

Anfang he Guidance System is the most complex part of all those computerized systems that keep the beam network running. 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 component consists of:
Computers in the beamcars
Computers in the nodes
A central supervising computer
Sensors in the beams to keep the nodes informed about the whereabouts of the cars.
There are in principle three different ways to run a system such as this:

The Synchronous system
The Asynchronous system
The Point-Synchronous system
Further down on this page we will explain the concept of timeslots, that are an important part of all synchronous traffic guidance. The idea with the guidance system is to safely guide a car from start to destination as quickly as possible. For a big network with much traffic, this would entail lots of complicated calculations that goes on all the time in the various computers as long as the traffic is running.
This job is shared between the Central computer, the node computers and the computers in the vehicles, so good communication between these is of crucial importance in order for the system to function, except for the asynchronous system which is very resilient. The Guidance system must also work closely together with the Safety system.
Let´s take a look at the characteristics of the three guidance systems mentioned.

The Synchronous system
The Asynchronous system
The Point-synchronous system
The best system?
What is a timeslot?
Connection between timeslot and speed

1. The Synchronous System

The requests from the beamcars are served on a first-come first-served basis. The departing car tells the central computer where it is, where it wants to go and possibly also desired departure/arrival time. The computer checks in the table for booked slots which time slots are available. Next, the computer assigns a time slot for the vehicle, updates the nodes and the vehicle and enters this time slot 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, its entry is removed from this table. If requests for slots are pouring in faster than the vehicles can complete their journeys, it would be increasingly hard to find an empty slot, and delays would increase in the beam network.

As can be seen, this system works rather much like the time slot booking system for aircrafts. The idea is to provide each car with a booked free-transit all the way through to its destination, so that it can keep its speed all the way and not encounter queues. Its advantages:

Relatively simple to administrate
Quick and comfortable trips at an even speed

Disadvantages:

Likelyhood that there will be long waiting times before one gets under way (as in many airports nowadays)
Wasteful of the systems capacity
Totally dependent on good communications between computers.

To complete the picture, there must also be a possibility for the traveler to decide on a certain route, and also to make stops on the way. If he/she wants to stop, the journey would have to be booked as several trips, with different startpoints and destinations.

Here is a simple example of how it would work:
3 vehicles, A, B and C, enter their requests for bookings closely after each other. A wants to travel from A1 toA2, B wants to go from B1 to B2 and C wants to go.... you guessed it: from C1 to C2.

Example of synchronous booking of beamcars through a weaving node

Figure 1:1

And they all want to get going right away. Well, if A and B would arrive at the narrow section X at the same time, vehicle A gets to go first, because A:s request got processed by the computer before B:s requst. B would then get the next available time slot. C booked last, but C is closer to the narrow section X and can thus use an earlier unbooked slot.

But then, the routes of B and C cross each other at point Y, and if they were to arrive there at the same time, one of them would have to wait, and the synchronous system does not allow that. Thus, B might get to go first, and C might lose that time slot altogether because of this. So, this method can be quite wasteful of available capacity. An obvious conclusion from this example is that the synchronous system must avoid narrow sections as much as possible and strive to more resemble a spider´s web.

2. The Asynchronous System

The asynchronous system mostly resembles today's road traffic. Each car calculates the best route to its destination, taking into account the information about the traffic situation that pours in now and then. Thus: every car controls its own speed (within allowable speed limits) routing decisions are decentralized and made by the car and upcoming node traffic disturbances are compensated for locally the choice of travel route can be altered during the journey This means that there could be much stop-and-go during the journey, just as it is today in the road traffic. Collisions at the weaving points (where two beams meet) could be avoided in different ways. The best would probably be sensors in the beams at some distance before their confluence, that would alert cars on the adjoining beams of the traffic situation on the other beam.	In dense traffic, the cars would "weave" into the common beam like the hooks in a closing zipper, as shown in the illustration at right. The cars are here depicted as red or green to show from which direction they come. In not-so-dense traffic, the cars would gain access to the common beam in the order in which they arrive. Similar to road traffic-behavior at intersections without traffic lights, but a computerized system would be more "fair" insofar as beamcars, in queueing situations, would be alternately shunted, left-right-left-right, etc. into the common beam. One can see, though, that a sector such as A in the illustration could cause queues on all joining beams. The advantages of this system would be: Easy to administrate Makes good use of available network capacity Very resilient; the traffic could keep going even if communication between nodes should break down. Disadvantages: Risk for queueing and delays at the weaving nodes (in fact, queues are unavoidable unless the network is built to far exceed required capacity).	Figure 2:1

The asynchronous system mostly resembles today's road traffic. Each car calculates the best route to its destination, taking into account the information about the traffic situation that pours in now and then. Thus:

every car controls its own speed (within allowable speed limits)
routing decisions are decentralized and made by the car and upcoming node
traffic disturbances are compensated for locally
the choice of travel route can be altered during the journey

This means that there could be much stop-and-go during the journey, just as it is today in the road traffic. Collisions at the weaving points (where two beams meet) could be avoided in different ways. The best would probably be sensors in the beams at some distance before their confluence, that would alert cars on the adjoining beams of the traffic situation on the other beam.

In dense traffic, the cars would "weave" into the common beam like the hooks in a closing zipper, as shown in the illustration at right. The cars are here depicted as red or green to show from which direction they come. In not-so-dense traffic, the cars would gain access to the common beam in the order in which they arrive. Similar to road traffic-behavior at intersections without traffic lights, but a computerized system would be more "fair" insofar as beamcars, in queueing situations, would be alternately shunted, left-right-left-right, etc. into the common beam. One can see, though, that a sector such as A in the illustration could cause queues on all joining beams.

The advantages of this system would be:

Easy to administrate
Makes good use of available network capacity
Very resilient; the traffic could keep going even if communication between nodes should break down.

Disadvantages:

Risk for queueing and delays at the weaving nodes (in fact, queues are unavoidable unless the network is built to far exceed required capacity).

Handling traffic through several consecutive weaving points

Figure 2:1

3. The Point-synchronous System

In this system, the beam cars travel freely between the nodes and gets assigned to timeslots whenever they approaches weaving nodes (such as C in the illustration at right; figure 3:1). This net is a mixture of synchronous and asynchronous segments; at certain points on the joining beams, called Booking points, the beamcars leave the asynchronous portion of the beam and enter a synchronous portion, where they get assigned timeslots by the node they are approaching. The booking points are equi-distant from the shunt, as illustrated to the right. You can read about how this works on the webpage titled "How would it work?"

Thus, one takes the following attributes of the asynchronous system:

every car controls its own speed
routing decisions are decentralized and made by the car and upcoming node
disturbances are compensated for locally
the choice of travel route can be altered during the journey.

And the following attributes from the synchronous system:

time-slot allotment
controlled speed at the convergence points.

This makes for a rather complex system, where the cars can decide their own speed and pick their own route in between the convergence nodes and through the divergence nodes, but have to accept an assigned speed and book into a timeslot when approaching a weaving node.

All computers in the network should be addressable and able to communicate directly with one another.
Roughly speaking, one can say that:

The cars would keep track of where they are, where they are going and the traffic situation up to the next upcoming node.

The Nodes are basically of two kinds, with different functions.

The Convergence (or weaving) Nodes put arriving cars into time slots so that they won't have to stop altogether to avoid a collision when merging.
The Divergence (or shunting) Nodes are notified by each arriving car as to where it is destined. These nodes could then give directions to the car as to which way to shunt. This information is based in the shunt node computer's destination tables. In the SwedeTrack system we prefer to put this function in the beamcar. But the node computer should retain this capability to direct cars, if need be.

Figure 3:1

Advantages with the point-synchronous system:

Makes the best use of available traffic capacity
Total central control over where all beamcars are and how they are used
Reliable booking and traffic information

Disadvantages with the point-synchronous system:

Very complex to administrate
Totally dependent on good communications between computers.

4. The Best System?

The point-synchronous system could be viewed as "islands" of synchronous control in a "sea" of asynchronous traffic. The point-synchronous system has more total control over the network than either the synchronous or the asynchronous system. The Central computer has a coordinating function, receives and redistributes information about congestions or accidents and continually logs the journeys of all the cars. This logging includes keeping track of the mileage of various vehicles so they can be directed to the garage for overhaul every now and then. This computer also controls the pools of empty cars and directs them to where they are needed.

The node computers will be doing their share of the work in this network. Their assignments are different, depending on whether they are convergence or divergence nodes. This will be more detailed further on in this page. The main tasks of the central computers would thus be of an administrative nature, while computers in nodes and vehicles work in real time.

The simplest kind of nodes are of either the convergence or divergence kind, with only one shunt each. But since there will be several shunts within a small area to administer by the same node computer, there will also have to be nodes that:

administer several divergence shunts
administer several convergence shunts
are a combination of convergence and divergence nodes.

This would mostly be in those places where the shunts are close together, i.e. functionally several shunts will behave as one node. These nodes would mostly be found at terminals, vehicle depots, intersections and bigger traffic spots. Roundabouts would be plentiful in the network, and within them there would be synchronous traffic. While there, the vehicles would have to stay in their alloted timeslots, and request a new timeslot whenever they leave a berth.

5. What is a Timeslot?

he timeslot is the key to understanding how the synchronous (and the point-synchronous) traffic system works. Let´s look at synchronous data communication as a comparison. The difference between synchronous and asynchronous data communication is that asynchronous data blocks can be sent and received at any time, while synchronous datablock have to be "clocked". The asynchronous datablocks have startbits and stopbits so that the receiving computer can recognize the datablocks as such. In contrast, the synchronous datablocks come at regular intervals, so long as there is something to be sent. Both sender and receiver know about these intervals and how long they are, and because they can do without those startbits and stopbits that are needed in asynchronous communication, they can maximize throughput to the highest rate of sent/received datablocks that they can safely handle. Similarly, one can calculate the safe rate at which the vehicles can be dispatched on the beam network, taking into account their speed, sizes and safety distances.	There are 2 differences between data transfer and beam vehicle traffic: data travels practically instantaneously from start to destination, while the beam vehicles have a limited speed data is buffered in computers between every step of their transmission process, while the beam vehicles are travelling most of their time. In other words, in order to adapt to network capacity, data is buffered between transmissions while beamcars have their speed regulated. Thus, one way of looking at this is that one fills the beam network to its maximum capacity with "imaginary" vehicles that travel "everywhere" at the maximum allowed speeds designated for various segments of the beam network. The network computers then keep track of these vehicles, in a manner of speaking, insofar as the computers know where these "vehicles" are at all times. But "imaginary" vehicles don´t exist, so when a real vehicle wants to travel somewhere, it will be assigned the place that the corresponding imaginary vehicle for that particular destination would have traveled. These "imaginary" vehicles are called timeslots.

he timeslot is the key to understanding how the synchronous (and the point-synchronous) traffic system works. Let´s look at synchronous data communication as a comparison. The difference between synchronous and asynchronous data communication is that asynchronous data blocks can be sent and received at any time, while synchronous datablock have to be "clocked". The asynchronous datablocks have startbits and stopbits so that the receiving computer can recognize the datablocks as such. In contrast, the synchronous datablocks come at regular intervals, so long as there is something to be sent.

Both sender and receiver know about these intervals and how long they are, and because they can do without those startbits and stopbits that are needed in asynchronous communication, they can maximize throughput to the highest rate of sent/received datablocks that they can safely handle. Similarly, one can calculate the safe rate at which the vehicles can be dispatched on the beam network, taking into account their speed, sizes and safety distances.

There are 2 differences between data transfer and beam vehicle traffic:

data travels practically instantaneously from start to destination, while the beam vehicles have a limited speed
data is buffered in computers between every step of their transmission process, while the beam vehicles are travelling most of their time.

In other words, in order to adapt to network capacity, data is buffered between transmissions while beamcars have their speed regulated.

Thus, one way of looking at this is that one fills the beam network to its maximum capacity with "imaginary" vehicles that travel "everywhere" at the maximum allowed speeds designated for various segments of the beam network. The network computers then keep track of these vehicles, in a manner of speaking, insofar as the computers know where these "vehicles" are at all times. But "imaginary" vehicles don´t exist, so when a real vehicle wants to travel somewhere, it will be assigned the place that the corresponding imaginary vehicle for that particular destination would have traveled. These "imaginary" vehicles are called timeslots.

6. Connection between Timeslot and Speed

learly, travel speed cannot be the same everywhere in the beam network. Factors that influence maximum allowed speed on a beam segment are:

general speed regulations for the area
size of the beam
beam is passing station or parking area with many inlets and outlets
time of day, day of week
temporary situation, such as maintenance work on or nearby beam segments
sloping or curving beam
cars that change travel directions in diverging shunts might have to slow down as needed to adapt to situation immediately after the shunt.

heavy vehicles and heavily loaded vehicles have to slow down more at diverging shunts and in curves than light vehicles need to do
long vehicles might need longer headways to the vehicles ahead
heavy vehicles and heavily loaded vehicles might need longer headways to the vehicles ahead in order to brake
there might be different mandated speeds for goods transports and for people transports
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.

The virtual cars can be said to be "generated" at every node, travel on all beam segment, and then "disappear" when they arrive at the next node.

They would thus travel at the speed mandated by the conditions above. Since the last 6 conditions in the listing above depend on the vehicles and on the situation at hand, this "generation of virtual vehicles" is just a way of explaining how available timeslots travel along the beams.

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.

Managing timeslots in a beam network is thus potentially much more complex than handling a synchronous data network. We will provide a simple example below.

Example of offtrack beamcar stops in a street

Figure 6:1

onsider the illustration above (figure 6;1), of two beams passing a station with several berths (yellow squares). The orange squares represent the virtual vehicles and the dark blue squares are real cars. The distance between them is a function of allowable speed, and is regulated by the safety rules as detailed in the chapter about "Passenger Flows and Allowable Speeds". Vehicle number 7 has just left the thru-beam to berth at a stop. Had there been vehicles in slots 8 and 9, they would (in this example) have had to slow down, since number 7 had to slow down in order to either negotiate a sharp curve after the shunt or slowing down for docking. But since those slots were empty, the vehicles further away (i.e. 10 and 11) are not affected, they can keep going at the same speed. Empty slots behind a slowing-down vehicle are thus "eaten up" as required, for the vehicles further behind to be able to keep their cruising speeds.

A smooth beam shunt Note: Whenever possible, shunts should be so "smooth", i.e. have such a small divergence angle, that the beamcars would not have to slow down. Also, berths should ideally be so far removed from shunts on thru-traffic beams, that beamcars that are about to dock would not have to slow down until after the shunt, and beamcars that are leaving would have attained cruising speed by the time they reach the shunt.

Thus, if all timeslots are occupied, traffic will not be able to move as fast as it otherwise could be moving, unless this condition above is met everywhere in the network. One way to avoid severe speed disturbances among the vehicles (i.e. that too many vehicles have to slow down because of a congested traffic situation) is to reduce the allowable speed on beam segments that passes through station areas where there are many shunts. As detailed elsewhere, one could build parallel trunk beams for higher speeds, meant for vehicles that don´t want to stop in this particular area.

Trunk beams are like freeways; between the nodes, they would (in the point-synchronous system) be free from timeslot restrictions; they would move in a asynchronous fashion, as the topmost beam in this picture illustrates. Vehicles that are about to leave a berth will have to wait for at least one empty timeslot to come along. It is not reasonable for the traffic to stop to let such a vehicle enter the beam, even if this means that a departing vehicle might have to wait a rather long time. Such problems are essentially design issues; the beam network must be designed to have at least 50% empty timeslots on the average, during rush hour.

In our example, the waiting vehicle will occupy timeslot 7 when that timeslot comes along. That´s the timeslot that just got vacated by the vehicle we mentioned earlier (i.e. number 7). The local node computer is responsible for informing waiting vehicles when to get ready to leave, and the node should, if needed and if possible, wait for more than one empty slot to come along, so that the vehicles that come after should not have to slow down as the "new" nr. 7 picks up speed after passing the shunt.

One can thus see that various vehicles and the general traffic stuation constantly influence the speed and number of timeslots.

Although one has the ambition to build "smooth" shunts and long start/stop-distances between shunts and berths (as stated in the "Note" at left), the network will grow and change over time, and planners might suddenly face a situation where this condition of shunting at undiminished speed cannot easily be met. But smart engineering of shunts and cars should enable the cars to pass through the shunts at relatively high speeds whithout too jerky sideway movements of the cabin.

Copyright © 2004, SwedeTrack System.	Last Updated: 2007-01-17	Webmaster	This site is maintained by Johnson Consulting