The Intelligent FlyWay® Beamcar

1. General

2. Navigation

Figure 2:2

igure 2:2 provides a very simplified overview of the information that has to be stored in each FlyWay vehicle, how it is updated and how it is used. The "System Information" symbol is used as a common source for all information from the outside, provided by various computers in the network.

In this context, the two routing tables are of interest. The dynamic routing table gets its original values from the basic routing table, values that are then continually updated with information from various system sources, and used as reference by the vehicle, when deciding upon a route. As shown, however, the riders can influence this routing by specifying certain parameters. This can be done both before and during the trip, just as when riding an ordinary taxicab.

The riders can decide: If they want to travel a specific route If they want to stop at certain stations along the way If they want other parameters than time to influence the choice of route. This is where some of the OSPF-parameters listed above come into play.

3. Communication with the Network

Figure 3:1 shows the 4 physical communication interfaces used by the vehicle: Between the propulsion car and beam transponders. The system of choice is Bluetooth, but there is a backup-system in the form of waveguides inside the beams. Between passengers´ Bluetooth units and the cabin control. Between door control on station cubicles and the cabin control, using Bluetooth interface. This option only on passenger vehicles. Between passenger terminals in the cabin and the cabin control. This option only on passenger vehicles. The logical communication interfaces are more complicated. It is detailed on the page "The FlyWay Communications Systems".

Figure 3:1

4. Controlling Speed and Shunting

very FlyWay vehicle has detailed on-board information about the network on which it travels. To facilitate speed control and shunting, it knows the address of every place where shunting and change-of-speed has to take place. The locations of all these addresses are identified with the aid of sensors and/or bar-coded strips on the inside of the beams. Such a strip at the proper distance before a diverging node, for instance, tells the vehicle when it´s time to perform the shunting. Information of left or right is obtained from shunting tables. And the vehicle knows which shunting tables that apply, from the route selected from the routing table. Likewise, such a bar-coded address strip or sensor tells the vehicle when it´s time to regulate its speed, and the applicable speed is obtained from the velocity tables. And the vehicle knows of course which velocity tables that apply, from the route selected from the routing table. We will use an example which can be found on the page "The FlyWay® Addressing System".

Figure 4:1

An Example n figure 4:1 we have a car which has to travel from point A to point B, and berthing at berth 18 on the way. This example is found on the page about FlyWay® addressing, which concerns itself with the destination addressing system. Here, we need to know how and where to shunt. The whole roundabout would reasonably be controlled by one node computer, which controls all moving traffic synchronously. Cars join this synchronous control by either entering the roundabout or leaving one of the berths inside it. Likewise, they will leave the synchronous control by either stopping at a berth or leaving the roundabout. Now, the car at A soon passes its first shunt, which is announced by a sensor or bar code shortly before the shunt, identifying itself to the car by a certain address. In figure 4:2 below, these addresses have been indicated by blue numbers. So, the car switches Eight, and soon arrives at the booking point for the weaving at 14. It gives the node its identity and destination (which is berth 18). The node quickly sees that the destination is within its own "jurisdiction", i.e. that the car is not just passing through.

The node identifies itself, allocates a timeslot for the car and sends this info in a message, which the car acknowledges. The car's computer calculates the right speed it should maintain from the booking point on, to arrive at the shunt at the proper time for the assigned time slot. Now, we have two possible scenarios, One is that the node checks that the route and the berth are both clear (if it has not already done so). That being the case, the node assigns the most suitable route (indicated by green in the illustration) to the car, by signaling the instruction "R-L-R-R-L-L" (L=Left, R=Right). This info gets stored in the car's computer memory. The other scenario is that the car relies on its stored routing information and dynamic updates from the node to get it to its destination. Both methods have their merits, and the one that generates the less data communication between node and vehicle is generally the best. Whichever methode is used, the car is guided to its berth by these Left/right instructions, and every one is triggered by the sensors or bar codes in the guideway before each diverging switch. Likewise, a sensor right above the berth would tell the car when the berth corresponding to address 18 has been reached.

When the car later on is ready to leave, it signals the node, which checks for a suitable route. Having decided on the best exit route for the car (marked in green in the illustration above), the node signals "L-L-L-R-L-R-R-R", and assigns a departure time and a free time slot to the car. Both when arriving and leaving, the car has to stay in the timeslot assigned to it, by keeping the correct speed. After passing point B, the car is once again free to set its own speed. In a similar manner, bar codes or similar indicators, having idividual identifications (or addresses) would tell the car when its time to adopt the speed that applies to that particular beam section. Figure 4:3: Example of bar code.

Figure 4:2

5. Platooning

Figure 5:1: Platooning

n a way, platooning belongs under the heading "Controlling Speed and Shunting", but it is enough heavy and complicated to warrant its own chapter. The benefits of platooning have been dealt with in a general way on the page "Platooning in FlyWay®". Two or more cars become "one" for a moment, from a data-logical point of view, by means of electronic coupling between cars (see figure 5:1 above). The following tasks have to be solved in a quick and reliable manner: Decision criteria for platooning. Informing and coordinating the affected cars. Assigning a temporary identity for the combined "car". Making and keeping a logical connection between this "leader car" and the cars that participate. Knowing when the new car (.ie. the platoon) cease to exist. Assigning a timeslot that fits the size of the platoon.

Let´s see how these tasks best can be solved. Figure 5:2

In this illustration (figure 5:2) we show an example of 5 beams coming together into one narrow sector A. We won´t discuss the wisdom of such planning here, just deal with the facts at hand. It is clear that, as traffic increases on any or all of these beams, sector A will be the first bottleneck. Decisions for, and handling of, platooning, is made locally, by the weaving nodes and the vehicles involved. We will treat the technicalities of this on two pages. The tasks of the nodes are treated under the chapter "Platooning" on this page, and the tasks of the vehicles are treated here. 5.1. Decision criteria for platooning Platooning is only motivated when the traffic demands exceed the capacity of the beams involved, and there is no other expedient way to solve this, except by platooning. This is a decision taken by the node computers involved, and is therefore tewated more in detail in chapter 6 on the page "How Weaving Nodes handle Traffic".

Figure 5:3

5.2. Informing and coordinating the affected cars There are 3 rules that apply for platooning: 1) The forming of a platoon can only take place on synchronous beam sections, leading to a weaving node, between booking point and node. Such a decision is only made by the weaving node. 2) Platoons can only travel on synchronous beam sections. 3) The dissolution of a platoon can only take place on synchronous beam sections leading to a divergence node. Such a decision is taken by every individual car by itself, and it will not affect the other cars in the group. When the remaining cars reach an asynchronous beam section, platooning will automatically cease, by every car, except the lead car, slowing down sufficiently to regain the safety interval to the car in front. The reason for these restrictions is, of course, that the platooned car (except for the lead car) does not have any safety distance worth talking about, to the car in front. Thus, the cars must move synchronously, at the command of an external source (the node computer, in this case). What happens is that several cars gets assigned the same timeslot. Looking at figure 5:4, where cars on the right arm gets platooned in groups of three because of queueing, you can see that cars 1:1, 1:2 and 1:3 travel together in the double slot consisting of S1 and S2. Slot S3 is occupied by a lone vehicle from the left arm (where there is no queueing, in this example), and then slots S4 and S5 get occupied by vehicles 2:1, 2:2 and 2:3 from the right arm, and so on.

Figure 5:4 These cars gets grouped together by the node already when they report at the booking point (Bo) on the right arm. Cars 1:1, 1:2 and 1:3 all gets assigned to slot S1 and told to adjust their speed to arrive at the node at the proper time. So, as they travel towards the node, the vehicles gradually group together, and will just slip through the weaving point at undiminished speed when they get there. It is here important that the cars get these instructions simultaneously, shortly after all three have reported at the booking point, so that they move together, as a train.

The chronology of this information exchange is illustrated in figure 5:5. Cars 1 and 2 have to wait for their slot assignment until Car 3 has passed the booking point. Meanwhile, they travel at the default speed applicable for this beam section. Figure 5:5

5.3. Assigning a temporary identity for the combined "car" This might not be necessary, it could be that the cars get to keep their identities although they are travelling in the same timeslot. 5.4. Making and keeping a logical connection The making and keeping of a logical connection between the "leader car" and the other cars that participate in the same 2 timeslots is not necessary, as long as the group travel along synchronous beams. There is a possibility that the "train" can keep together also on asynchronous beam sections, n which case the cars need to have direct contact with each other. But this is not a part of the FlyWay concept. Narrow sections in the network only appear as a result of weaving too much traffic, and in the point-synchronous network, weaving is always synchronous.

5.5. Knowing when the platoon cease to exist This will happen either because: one or more cars in the platoon are going in different directions at the next divergence node or one or more cars are stopping at a berth, or the platoon has passed the bottleneck, and platooning is no longer needed. Platoons are dissolved by the cars themselves, without any ado. Any car in the group can leave, when passing through a diverging node; that´s what happens in the first two instances. The cars cannot know, however, when they have passed the bottleneck that were the reason for platooning. In that case, one of two things will happen, if the cars stick together long enough:

They enter a asynchronous beam section, whereupon the platooning dissolves automatically. They pass a weaving node´s booking point. If there is no queueing, the node will dissolve the platoon by assigning the cars individual timeslots. 5.6. Assigning a timeslot that fits the size of the platoon Creating and handling timeslots with varying sizes is naturally trickier than handling timeslots having a standard size. In FlyWay®, this matter has been simplified by always assign two consecutive timeslots to a platoon, and then be satisfied with the limited number of cars that fit into that space.

6. Communication with Passengers

Figure 6:1

assengers travelling with the FlyWay beamcars will be able to interact both with the system control and with the beamcars themselves. There are 3 such logical interfaces: To contact a parked car in order to bring the cabin down on the ground. To make a cabin on the ground open its doors to let people in. To obtain traffic-related and other information from the information terminals in the cabin during the trip. To make alterations to the journey via the terminals in the cabin during the trip. There would be 3 physical interfaces for this purpose: Terminals with card readers near station berths. Terminals with card readers inside passenger cabins. Bluetooth-based communication units. Detailed information about the passenger interface can be found on the page "Using Bluetooth as Passenger Interface".

Figure 6:1 shows a general station layout, from a Bluetooth-point of view. Travelers arriving at such a station can generally fall into either of 3 categories: He/she can have a booked car waiting. He books a car as he arrives. He hopes to find a car as he arrives. He wants to travel on a scheduled tour. The first category of passengers might want a particular vehicle, or anyone of a particular type. In either case, he sends a request for a car, using his passenger id. This can be done either by using a station terminal or a private Bluetooth unit. This contact is made with the Booking System, which then orders forth the desired car, telling the passenger which berth to go to. The second category of passengers also contacts the Booking System, and hopes for luck. The next step, for both categories of passengers, is then to go to the assigned berth and identify himself, either by a card-reader at the berth or via Bluetooth. The booking system will in the meantime have alerted the assigned car to watch out for a passenger with this identity. It will thus open the doors and let the passenger in.

It is always a bit tricky for unmanned vehicles to know when all intended passengers have boarded the car. One option is for one of the passengers to press a "door-close" button inside the car. If the car finds that doors are free of objects, the door will close and the car sets off on its journey. The third category of passengers have two options. They can either walk to a waiting, unassignd car and request access, by using a stationary terminal or Bluetooth. When the car is satisfied as to the identity and validity of these passengers´ travel-card, it will open the doors and let the passengers in. They can find a parked car above a berth. Using a stationary terminal or Bluetooth, they will call the cabin down. If the car is satisfied as to the identity and validity of these passengers´ travel-card, it will lower the cabin and open the doors. The fourth category of passengers need only to find an empty seat in a waiting cabin, or wait for a car to arrive at the berth. How do they pay for the trip? Well, either by a toll gate in front of the berth, or by manual control.

7. Handling lift, doors and cargo

The carriage under the beam can be: a passenger cabin a combined passenger- and cargo cabin a container mover (grappling hooks) a flatcar (for moving motor vehicles and big freight) attachments for dual-mode vehicles emergency and maintenace vehicles other special vehicles which have intrefaces that function with the FLYWAY® system

Text will be forthcoming here!

8. Handling Safety

he FLYWAY® beamcars have all the built-in safety restrictions that common sense and experience mandates that they should have. Some obvious measures are: Automatic seatbelts for all cars travelling under certain conditions, such as: Going faster than 90 km/hour for more than 10 minutes, or Travelling without the Brickwall-stop required safety distances. Cabins cannot lift from the ground if not all doors are closed and, for cargo carriers, all safety locks are secured. Loss of power means that the cars will either stay where they are, or move by battery power to nearest berth, thus avoiding that passengers get stranded. Lifts can always be safely lowered without power.

Obstacle detectors see to it that collisions do not occur. Travelling beamcars always make sure that they functioning communications with the obstacle reporting system. Likewise; carriages are never lowered if not ground topology agrees with what staored information says it should look like. This is ascertained by vertical scanners. Communication channels are always monitored for functioning. Should they fail, the vehicle would assume that the fault is within the vehicle itself, and stop at a suitable place. Parked cars have alert sensors activated that are sensitive to vibrations. Interior and exterior surveillance cameras relay all pertinant information to manual control centers.

A detailed listing would be too long. Many safety measures are centered around the communication between system parts, and are of two kinds: Protocol-dependent dependent security, that sees to it the communication either works or alerts are given. Backup systems, which ensure that important information have alternative ways to travel to reach its destination.

9. Maintenance

he Administrative system keeps logs on every individual vehicle, based on the reports from the vehicles themselves. According to set parameters, vehicles will be ordered by the system to report to maintenace workshops for preventive maintenace. This will be done after specified time intervals, after certain mileages and also after having performed specific kind of duties. Fault logs will be reported to the system by the workshop, and vehicles that have recurring problems of a specific nature can thus be dealth with accordingly.

The Administrative system also decides when and how individual cars have to be refitted for alternative service. Thus, by removing some or all seats in a passenger cabin, there would be more room for cargo. The Administrative system is also responsible for care and maintenance of beams and surrounding buildings and equipment that are part of the network, ensure adequate and timely supplies of spareparts, etc.