Maneuvering the Beamcars

Salesman, demonstrating a cellular phone: "Now, this model has a button for disconnecting during boring, pointless conversations."

unning automatically controlled vehicles means that all controls and maneuvers that is normally done by the human driver has to be taken over by computers and various sensors, and handled in a very reliable manner. The control and maneuver system that are described on this page are part of the FLYWAY® package, and this page can be regarded as fairly technical in nature. Whereas other technical pages on this website deal with specific features, this page will take a look at how these controls and functions work together and communicate information in an intelligent manner. Most of these functions deal with the safety of the beam system.

On this page we'll take a look at: Berthing at a stop Lowering the car at a stop Updating Network information The Ball-joint Arrangement Controlling the Elevators Emergency braking How to get where you want to go

A note about spelling The word in the header should properly be spelled "", but since that fourth letter is not part of english character repertoire, the English have adopted the spelling "Manoeuvring" and the Americans usually spell it "Maneuvering". Since American spelling usually is closer to actual pronounciation, you will most often find American varieties of many words on this site. Another example is the old-fashioned spelling "Programme" which on this site is spelled "Program".

1. Berthing at a stop

s stated elsewhere on this website, every node, every branch under that node and every stop on each branch needs its own address, so that an approaching beamcar knows when it has arrived. Considering the illustration at right, a beamcar approaching from the left and destined for, say, the 3:rd berth on branch 4, has to know how to get there and also when it has arrived. A sensor inside the beam directly above the berth, will be necessary, since it is essential that the car does not miss its target with more than an inch, at the most.

Figure 1:1

ut the car has to slow down in time, so it will also be necessary with an alert sensor in the beam at a predetermined distance before the stop, as indicated by A in figure 1:2. Beams that at different hours carries traffic in the opposite direction will need a corresponding sensor at B as well. This alert sensor will identify itself, and the beamcar´s computer will have a table where the positions of all these alert sensors are positioned. From this table, the car´s computer can read the exact distances to all the berths that follow within the same station area. Thus, the alert sensor A in figure 1:3 will (in the beamcar´s table) give the distances to all the berths (indicated by blue dots in the figure), and the car, knowing its destination, can adjust its speed accordingly. It´s worth noting that the buffering areas for parking the cars in readiness for the next assignments will also need sensors, indicating to the empty car that it has "arrived". As statet elsewhere, these sensors could be of the "intelligent" type that report to the system that the car has arrived at this place. But in the FLYWAY® system, the beamcar will take care of all its reporting to the system itself. These sensors would (most likely) be placed at the first available spot in the parking zone, as indicated by B in figure 1:3.

Figure 1:2 Figure 1:3 The difference here is that the car "knows" that it is queued in a buffering area, and will monitor other cars there. As they move forward, "our" car will follow suit, as one does in a moving queue. In addition, the node computer always knows which cars are in what queues, and will direct "our" car onto the next assignment when the time comes.

he car will thus know exactly how far it has to go to reach the berth, and can adjust its speed accordingly. Nevertheless, the car should also be able to back up a limited distance (not more than about 5 meters) should it overshoot its berth. A complex of berths, like the one in the illustration to the right, should manage with just one alert sensor for each beam. The car will then, from stored information regarding this particular alert sensor, know the distances to all the berths in the area, including the one that it is destined for. This is not all. The approaching car also needs to know: Whether it needs to switch into a parallel beam to reach the berth. If so, this switch would be positioned between sensor A and the stop. Whether there is a turn before the stop, where it is and how sharp it is. Speed will have to be adjusted accordingly. Whether the last stretch of the beam to the berth is sloping (or maybe rising), and at what length and inclination. Braking has to be adjusted according to this. Whether it has to turn sideways (swivel) and to what degree before lowering. Whether the berth of its destination is free or occupied. The best solution to these questions is to have all this information stored in the computer on all beamcars. This table should also contain general speed limits for different parts of the network. Together with the Routing Table and the destination information, the beamcar will thus have all the travel information it needs.

Figure 1:4

s we define our terms, a station can consist of one or more berths. A berth can only harbor one vehicle at a time. When a beamcar stops at a berth, it sends a message to the node computer responsible that this berth is now occupied. The node will add this information to its list of "currently occupied berths" and retransmit this update to all vehicles that are currently within the node´s jurisdiction. This list of "currently occupied berths" will also be sent in its entirety to all approaching vehicles, as they announce their presence to the node, and announce their intention to dock at a berth which is under the jurisdiction of this particular node. This exchange of information will, in the poin-synchronous system, occur when the vehicles pass the booking points for the node. The berth will be marked as occupied until the beamcar at that berth announces that it is leaving. The concerned vehicles will update their own lists of "currently occupied berths" in order to have an overview of the situation. Approaching cars that have passed the booking points and are about to stop at a berth will continously be kept informed by the node as new berths become occupied and free. The car waiting for a free berth will then have to make a decision "on the fly" how to handle this situation, depending on the instructions the car has received in connection with this particular journey. Those instructions would have to be relayed to the node computer, because the node has to make the decision as to allotment of berths. For every trip, the beamcar has a set of instructions of how to pick a berth at its destination: If the car can dock at any berth within the station area, it will take the nearest free berth. If all are occupied, the car will wait at the nearest "wait area" at the entrance to the berths for the information that a berth is now free. To prevent more than one car from darting towards the same free berth, the node computer needs to be in charge, and announce which car should have the free berth. Even if the cars are queued up, the node has to be in control of this.

If the car can dock at any of a specific number of berths, the wait might be shorter. The procedure for allotment of berth is the same, taking due regard to these restrictions. Some beamcars might for example be too big for certain berths. If the car has to stop in a street resembling the illustration above, with stops all along the street and all stops within a block belonging to the same station, the default will be a berth somewhere in the middle, with all the other berths available as a second option. In case of traffic congestion, it should be possible to interact with the passengers, insofar as they should be informed of the traffic situation. It will be in the form of a trade-off, shown on a screen in the cabin, stating, for instance, that the berth of preference will be available within 10 minutes (due to queueing), one of the berths within 200 yards will be available within 5 minutes, and if they can settle for any berth along the block, they could berth within 3 minutes. The trade-off here is the walking distance, and the passengers should be able to indicate their preference, which would then be relayed to the node computer, which will then direct the beamcar accordingly. Finally, it could be that only one particular berth will do. The car would then have to sit and wait for that berth to be free, but the node should take note of this fact, and avoid directing other cars, which have a freer choice of berths, to that particular berth. As can be seen, the node computer could be kept quite busy at a big station. The aim is of course to not keep the cars waiting longer than necessary, and to direct them to queues so that they won´t be in each others´ way.

2. Lowering the car at a stop

he beamcars will need a contact sensor under the floor, between its legs, to detect when there is contact with the ground, as shown in figure 1.2 above. A radar would serve this function better. This is because, while lowering the cabin or carriage, the remaining distance to the ground would continually be monitored, and this would enable the cabin to be lowered as quickly as is comfortable for the passengers, thus saving time, compared to lowering the cabin slowly so it won´t hit the ground too hard. Equipping the cabin with such a radar would also mean that shockabsorbers won´t be needed. For all stops in the network, the cars will need information about how far it is to the ground. This should be stored in the form of a table in every beamcar´s computer memory. But, for safety reasons, ground contact has to be verified at all berthings, since changes in ground conditions could occur now and then, without this being reported to the system computers. As a complement, each of the 4 feet of the vehicle cabin or carriage (see figure 2:2) should have a contact sensor. Whenever any one of the feet detect an object, the lowering of the cabin would immediately stop, and the control center would be alerted. It could happen that there is an object on the ground, and this needs to be detected in time. When the ground has been reached, the vehicle will offload its weight onto the ground. When the lift machinery has detected this offloading of its weight, the safety locks on the doors of both the booth on the ground and the passenger cabin will be released.

Figure 2:2 Then the doors may be opened, either automatically or manually (by pressing a button, either from outside the booth or from inside the cabin), depending on type of vehicle. The FLYWAY® concept includes booths at the stops, where the doors are always locked when there is no beamcar in place, denying entrance to the booth. Those doors will be automatically opened when a beamcar has landed, and a beamcar will not be able to leave the berth until those doors, and the doors of the vehicle as well, are closed and locked. This system is called "Platform Screen Doors" (PSD), and is used in the Singapore underground as well as in other places (it is considered for the Stockholm underground system as well), and it efficiently prevents accidents from happening. If a person makes a forced entrance into such a booth and then get injured by a beamcar, the network operators certainly cannot be held responsible. Read more about these booths.

3. Updating Network information

All information that is needed by the central computer, the node computers and the beam vehicles should be entered only at the central computer. It is then the responsibility of this computer to use the communication protocol available for the purpose to as speedily as possible distribute this information to nodes and beamcars.

The central computer must also keep tab on those nodes and beamcars that do not acknowledge this information. If need be, those nodes might be shut off from the system, and beamcars not answering in a proper manner should be taken out of traffic and directed to service depots. Read more about this.

Network	Source	Destination	Command/ Request	Comments
Nodes & Central computer	Central computer	All Nodes	Update information; Permanent alterations Dynamic changes	See "How would it work?"
	All Nodes	Central computer	Update information; Permanent alterations Dynamic changes	Generally, info about permanent alterations should come down from the central computer
Sensors & Nodes	Sensors	Regional Node	Time, speed, direction and identity of every passing vehicle	Only one-way communication
Vehicles & Nodes	Vehicle	Regional Node	Occupying a Berth	Node acknowledges
	Vehicle	Regional Node	Leaving a Berth	Node acknowledges
	Vehicle	Regional Node	Passing thru; destination information	When passing a booking point; Node acknowledges
	Vehicle	Regional Node	General information; Health report	When passing a booking point; Node acknowledges
	Vehicle	Regional Node	Stopping; desired berth information	When passing a booking point; Node acknowledges
	Weaving Node	Vehicle	Time slot allocation	When passing a booking point; Vehicle acknowledges
	Regional Node	Specific vehicle or general broadcast	Various traffic information for passengers	To be shown on screens in the vehicles
Vehicles & Central Computer	Central Computer	Vehicle	General Directives; what to do after the present trip	Vehicle acknowledges
	Central Computer	Specific vehicle or general broadcast	Various traffic information for passengers	To be shown on screens in the vehicles

4. The Ball-joint Arrangement

he technical details of the ball-joint arrangement are described elsewhere. The question here is how its maneuvering is to be handled. As described, hydraulic arms on the lower end of the lift will be able to swivel the cabin or carriage up to 90 degrees in any one direction prior to (or during) being lowered to the ground at a stop. The information on where and how much the carriage is to be swiveled is stored in the car´s computer. Thus, in the FLYWAY® system, the berths need not be parallell to the beams, if this is not desired for one reason or another. One such reason could be if conditions below are too crowded to allow the berth to be positioned any other way. The hydraulic arms would also allow for some outward tilting when the car is going through curves, to compensate for the centrifugal force (shown in figure 4:1 at right). This force would be detected by sensors in the elevator unit, and be directly translated into action by the arms. A more advanced design might also be able to tilt the passenger cabin in the direction of travel (shown in figure 4:2 at right). This could be useful in emergency braking situations, as an alternative to the passengers´ using seat belts. There is yet another use for these arms; they could keep the carriage level when the vehicle is negotiating sloping beams (shown in figure 4:3 below). The FLYWAY® system foresees that beams might slope up to 30 degrees. Figure 4:3

Figure 4:1 Figure 4:2

5. Controlling the Elevators

Only the beamcar itself should have control over its lift. No node computer or human should be able to directly interfere with its operation. That´s the general rule. Then there are (of course!) exceptions:

Service technicians should be able to manually lower the lift. Service technicians should be able to raise and lower the lift by remote control while standing on the ground (for instance). Passengers in the cabin should be able to indirectly lower a lift that is going up. This is subject to the beamcar´s approval, however. The car will not permit kids to play yo-yo with the cabin. This is further detailed elsewhere.

6. Emergency braking

Figure 6:1 The beamcars rely on 5 information sources when deciding to apply the emergency brakes: Radar beacons on both ends of the propulsion cars inside the beam that report an obstruction Radar on the carriage itself that reports an obstruction (figure 6:1) A malfunctioning beam vehicle directly ahead and dangerously close sends an alert Certain internal problems within the beamcar itself, such as the elevator going down Directives from the central computer or the nearest responsible node computer The central computer and node computers, in turn, get their information from manual input, messages from malfunctioning cars and from sensors that are placed at regular intervals and at strategic points inside the beams. These sensors continually report the time, speed, direction and identity of all passing cars to the node computer responsible for the area. How this can prevent accidents is best shown with an example. Figure 6:2 Imagine that car 1 in figure 6:2 suddenly stalls, and does not report this (for some reason). The car will have been reported by sensor A, so the node quickly calculates when a report from either B or C should be expected. When this report is not forthcoming from either sensor within "reasonable" time, the node sends a query to car 1. Simultaneously, an alert is sent to all local vehicles what has happened, and each vehicle will then make a quick decision, based on: where it is at the moment, how fast it is travelling and what options it has. It is clear, then, that vehicles 4, 5 and 6 are not affected. Vehicle 2 has no option but to stop before the shunt; it cannot know exactly where 1 is. Vehicle 3 can choose to stop or, preferably, switch into beam R2. In this latter case, it has to tell the node that it is approaching node X and has to be alloted a time slot so as not to risk collision with vehicle 4. It is to be noted here that sensor B will not report vehicle 5 as being number 1; their identity is checked by the sensor.

The Braking Emergency braking is normally performed by using the propelling system (whether rotary engines or MagLev) to feed the car´s live energy back into the poer supply system as electrical energy. This might have to be supplemented by physical friction-brakes. The propulsion vehicles would be equipped with computer-controlled disk brakes that do not lock the wheels. Mitsubishi and Totota have this as standard on some models of motor cars. One could also use disk brakes around the sides of the slot inside the beam - that would give a very efficient braking. SIPEM, for instance, uses that for emergency braking. Both these friction-based manner of braking causes a later strain on beams and supports, that they have to handle. Also, there is a minor drawback to this last system; it wears the inside of the beam. The inside of the beam thus has to be coated with a "braking layer" of some sturdy material. Releasing the emergency brake A vehicle that has used the emergency brake is an obstruction, as well as the vehicle that caused the situation in the first place. It is therefore proposed that all braked vehicles receive immediate instructions from the regional node which way to travel. The node can do this after a quick "reconfiguration" of the network, where the beam segment with the stalled vehicle is regarded as "no longer in existence". This information about the "temporarily altered network" is relayed to all cars, which accordingly update their routing tables. The braked vehicles will receive individual instructions from the node, which could conceivably mean that a vehicle has to travel a bit in the opposite direction from that allowed on the beam. That segment will thus be temporarily closed to other vehicles. Loss of Power The cars have batteries to slowly take them to the nearest available berth, where the cabins will be lowered. The passengers must not get trapped, so if necessary, the cabins could be lowered even where there is no berths, after permission from the regional node. This speed is so slow that the cars will be able to stop within their radar´s visibility field. Loss of Communication This situation is potentially dangerous in the point-synchronous system when travelling at high speed. But the cars will then rely on their radars and keep travelling at a safe speed to the nearest berth, and dock there. They might be permitted to continue to their destinations, provided that they do not cross any weaving nodes. It is suggested that the cars have two-way radio-communication in case the wave-guide system should not work at any time.

7. How to get where you want to go

When boarding a beamcar, it is of course of the highest interest of the passenger-to-be to know where the car is headed, and (sometimes) when it leaves and when it will arrive. Confining ourselves to passenger cars in this text (cargo vehicles are dealth with elsewhere), we have four kinds of services: Scheduled cars are usually the biggest cars. They run specific routes according to time-tables. Taxi-cars are usually smaller and can be used as today´s taxicabs. Booked vehicles can be any kind of car, depending on what is desired. Electric-car transports for carrying electrically driven cars using roof attachments. Taking one category at a time, here is how the traffic will (probably) be handled. Time-Scheduled Cars Bunching people together in big cars is a cheaper and more efficient way of transportation than having them travel one or two in small vehicles. This is true, even though the driver has been eliminated, but provided that the bigger vehicles do not have to stop along the way. Thus, persons who agree to travel in this manner should be able to travel considerably cheaper than those travelling by taxi-cars. Thus, there will be a need at certain times and places for cars that follow a timetable. They will follow the manner of today´s road buses; they have their own platforms where arrival/departure times and destinations are published. They will stop along their routes where passengers aboard indicate that they want off, and the passengers could indicate this at the time of boarding, with the aid of their smart cards. The car will also know where prospective passengers are waiting along the route, because the stops will be equipped with button panels for the purpose, where waiting travelers indicate where they want to go. This is rather similar to today´s regular bus-stops, that are frequented by several bus lines. In many countries, you are supposed to hail an approaching bus, if it happens to be the bus you want to go with. If nobody hails, and nobody in the bus want to get off, the bus will just whiz by. This is how the beam-buses will function as well, but with push-button panels; a button for each destination, or a code of buttons for each destination. The input from these panels will be fed to the regional node computer, and all nodes along the routes of scheduled vehicles will also be informed by these vehicles how many empty seats there will be for different segments along the route. With this information, the nodes will be able to plan for the vehicles; tell them which vehicle is to stop where to take on additional passengers. The nodes will also be in a position to quickly request more vehicles if those scheduled to go in traffic are not sufficient. Since this calculation requires much cooperation between the node computers involved, it might be advantageous de defer this task to the central computer.

Taxi-cars You might have missed a scheduled vehicle and you don´t care to wait for the next one. Or they are not running when you want to travel (in the middle of the night. Or... whatever; in this situation you call a taxicab, hopefully one that runs on the beams. All stops, and many other places, should have terminals where you can type in your request; time, place, type of vehicle (It should also be possible to use a telephone). You will have to identify yourself in some way; if you have an anonymous travel card of the "smart" kind, the system will get the serial number of that card. The purpose of this is that when the car arrives, you will once again use your card, and the beamcar will (hopefully) see that the serial numbers match. If they don´t, the car´s conclusion would be that it´s being hijacked by somebody else. How that situation is to be handled remains to be solved. The alternative is if you are near a depot with available cars, you will just ask for one from a terminal (or by phone). In this case there is no need for identification. In either case, the car will wait about 5 minutes after it has arrived at the agreed berth (or 5 minutes after the agreed time). It will wait suspended under the beam until somebody uses his/her card at the nearby terminal to call it. If required (and possible), the car will check the serial number of the card. In any case, it will take note of this number, and check that the card is valid for (at least) one more trip. Being satisfied, the cabin will lower itself and unlock the doors. You pay for the trip as you board and tell the car your destination. And that´s where the car will take you (hopefully). Booked vehicles Vehicles of any kind can be booked at any time by anyone, private person, club or company, and for any (legitimate) use. They will thus not be available to the public; they will travel anonymously (to the public) on the beams. They will not have access to berths at the expense of other kinds of vehicles, however. For big events, berths might have to be booked as well. Electric-car transports Owners (leasers) of specially adapted light, battery-powered road vehicles will have access to beamcars that consist of roof attachments, maybe combined with lifts, that could transport these vehicles along desired routes, and also provide charging of batteries during this transport. These cars could be booked like today´s taxicabs, and they could be available at depots. (Read more about these vehicles).