How Weaving Nodes handle Traffic

Experience gained is directly proportional to the amount of ruined equipment!

eaving is part of the Guidance System. It is, however, so complex that it merits a page of its own. 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.	This is a very technical page, intended for those actively involved in the steering and control of automatic vehicles. Contents of this page: General Timeslots and safety distances The weaving of automatic vehicles Placement of booking points "Intelligent" weaving Platooning Contingency situations

1. General

FlyWay® uses a system for merging traffic which is called "synchronous weaving". The main advantage is smoothness; no stop-and-go, as is often the case with road traffic. Synchronous weaving can more be likened to access and exit from a highway. There are two differences, though. If we consider a highway where traffic is heavy, and the motorcars keep a token safety distance (S in figure 1:1), then the weaving will be performed by the cars behind the merging vehicle (i.e. the yellow car) falling back into the "timeslot behind".

This is "asynchronous weaving", and leads to change in speed. The other difference is that the driver of the yellow car takes a calculated (but small) risk, by violating the safety distance requirement. By keeping a somewahat lower speed than Car 1, he will gradually attain the safety distance (S), and so will Car 2, but it takes a few seconds. The automatically controlled vehicles must not be allowed to violate the safety distances between them. But the good news is that, with synchronous weaving, they wonīt have to.

Figure 1:1

2. Timeslots and Safety Distances

Clearly, travel speed cannot be the same everywhere and all the time in a big 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. A new timeslot is generated for a synchronous beam segment every Tts seconds, and the value of Tts comes from the obvious formula: Tts = D / v where: D = headway between vehicles, in meters v = the momentary actual speed on the beam segment, in meters/second. From the page with traffic calculations we get the formula for the "brickwall stop" requirement: D = v * r + (v2)/(2 * a) + L D = distance in meters between the center of two cars v = speed (meters per second) r = reaction time = 0.15 seconds for FlyWay a = acceleration or decelleration (meter / s2) L = the length of the car in meters. In FlyWay, impact speed for a "brickwall stop" situation will be allowed to vary between zero and 15 m./sec. Decelleration will likewise be allowed to vary between 3g and 10g for this situation. "g" = 9.81 m/s2 which is the earth's acceleration at sea level. It is usually set to 10 m/s2. Passengers wearing seatbelts can handle 15 m./sec. at impact and a decelleration of 10*g without injury, and the passenger cabins will have 0.6 meter-long "crumple zones" at both ends, consisting of material that absorbes much of the live energy at impact. In so doing, they will get deformed, as shown i figure 2:1, but this is a storage area for luggage, no seats will be placed there. This variability alllows FlyWay to vary traffic flows within wide margins, as traffic demand requires. It should be pointed out here that automatic traffic systems are much safer than the road traffic, and yet, on the highways, safety distances are often disregarded by the drivers. Thatīs because a serious accident, to an individual driver, is extremely rare. And when it happens, he/she often doesnīt survive in order to alter his/hers driving behavior.

Figure 2:1 If we were to construct a table with these values, and for various speeds, assuming a vehicle length of 6 meters, we would get the table below. It should be noted that, when the requirements are "zero impact speed and 3*g retardation", the formula is: D = v * 0.15 + (v2)/(2 * a) + 6 and when the requirements are "max 15 m/sec. impact speed and 10*g retardation", the formula is: D = v * 0.15 + ((v-15)2)/(2 * a) + 6 which, for speeds below 15 m/sec. becomes: D = v * 0.15 + 6 The last two columns calculate the difference in safety distance resp. in speed for the two alternatives, i.e. how much do we gain in capacity by not adhering to the "brickwall stop"-requirement. As can be seen; by not adhering to this requirement when demand for traffic is high, FlyWay can considerably increase traffic capacity. For speeds above 90 km/hr. the traffic capacity is more than doubled.

Speed (km/h)	Speed (m/sec)	Safety dist. Zero impact speed & breaking at 3*g	Time betw. vehicles (seconds) for zero impact speed & 3*g		Safety dist. 15 m/sec. impact speed & breaking at 10*g	Time betw. vehicles (seconds) for 15 m/s impact speed & 10*g	Difference in safety dist.	Difference in time betw. vehicles (seconds)
10	2.78	6.55	2.36		6.00	2.16	0.55	0.20
20	5.56	7.35	1.32		6.00	1.08	1.35	0.24
30	8.33	8.41	1.01		6.00	0.72	2.41	0.29
40	11.11	9.73	0.88		6.00	0.54	3.73	0.34
50	13.89	11.30	0.81		6.00	0.43	5.30	0.38
60	16.67	13.14	0.79		8.52	0.51	4.62	0.28
70	19.44	15.22	0.78		9.02	0.46	6.20	0.32
80	22.22	17.57	0.79		9.60	0.43	7.97	0.36
90	25.00	20.17	0.81		10.25	0.41	9.92	0.40
100	27.78	23.03	0.83		10.99	0.40	12.04	0.43
110	30.56	26.15	0.86		11.80	0.39	14.35	0.47
120	33.33	29.52	0.89		12.68	0.38	16.84	0.51
130	36.11	33.15	0.92		13.65	0.38	19.50	0.54
140	38.89	37.05	0.95		14.69	0.38	22.36	0.57
150	41.67	41.20	0.99		15.81	0.38	25.39	0.61

3. The Weaving of Automatic Vehicles

The treatment of vehicles on synchronous beams is best explained by a few examples. Figure 3:1 Case 1: All beams have the same permitted speed. The booking points are the same distant away. Vehicle at "Bo1" books ahead of vehicle at "Bo2". Result: "First-come-first-served". Case 2: All beams have the same permitted speed. The booking points are the same distant away. Both vehicles book simultaneously. Result: Also "First-come-first-served". Their booking requests cannot both be processed at the same time. Case 3: Beam 1 perrmits 40 km/h, beam 2 perrmits 60 km/h. The booking points are the same distant away. Both vehicles book simultaneously. Result: Vehicle on beam 2 gets to go first, since it will be the first to arrive at the weaving point. Case 4: Beam 1 perrmits 40 km/h, beam 2 perrmits 60 km/h. Booking point 1 is 400 meters away, Booking point 2 is 600 meters away. Both vehicles book simultaneously. Result: The vehicle that is likely to first arrive at the node will get preferential treatment. Thus, vehicle 1 would require 400/11.1 = 36 seconds to arrive. Vehicle 2 would also require 600/16.7 = 36 seconds to arrive. In this no-win situation, the car whose booking was processed first gets the go-ahead. Case 5: Beams 1 and 3 constitute a synchronous thru-line, while beam 2 joins from a station area. A car leaving a station berth wants to join beam 3. Beam 2 is sufficiently long between booking point and weaving point to allow acceleration to cruising speed. Result: The booking behavior here is a bit different from foregoing examples. The car will stop and wait att the booking point for a timeslot allotment. If the traffic is heavy, this might take time. But when weaving control sees from the booking point on node 1 that there is an empty slot coming up (i.e. no car has requested and received a booking for that slot), then, the waiting car gets a slot assignment, in the shape of a time interval when it has to be at the weaving point. If the car calculates that it can make it in time, it will accelerate and join the main beam at cruising speed. If the beamcar calculates that it cannot make it to the weaving point in time, it will reject the timeslot assignment and ask for a new one. It is of course important that the booking point on beam 1 is so far away, relative to the speed on beams 1 and 3, that these timeslot assignments have a decent chans of arriving to the waiting car in time. Case 6: Again, beams 1 and 3 constitute a synchronous thru-line, while beam 2 joins from a station area. A car leaving a station berth wants to join beam 3. But beam 2 is not sufficiently long between booking point and weaving point to allow acceleration to cruising speed. Result: As before, the car will wait at the booking point for a timeslot assignment. It will here look for 2 consecutive empty timeslots, and adjust permitted speed on the thru-beam so that these 2 slots will be sufficient for the car to accelerate within. Thus, the car will receive a time interwal for joining the thru-beam within the first timeslot. During acceleration, it will be permitted to fall back to the second of these 2 empty slots, and the first slot will automatically, at the next booking point, be empty, since there wonīt be any car in that slot, asking for a timeslot allotment. "Officially", the first of these timeslots will not be regarded as occupied at any time; the node will treat the car as having been assigned the second of these slots. Heavy traffic: If traffic should be so heavy on one arm that a weaving node cannot find the empty timeslots needed (one or two) within a reasonable time (1 - 2 minutes) to expedite waiting cars on the other arm, it will have to act as a traffic cop, and simply create the empty slots needed. This is done by assigning the next car passing thru the booking point on beam 1 a later timeslot than it would have been entitled to, thereby creating the needed gap in the traffic. Likewise, if two slots are needed, it would first wait for one empty slot and, finding that, creating the next slot by letting the next car wait one slot. If need be (after waiting 3 minutes or more) the node could create two successive slots in the same fashion.

Figure 3:2 Weaving nodes that are physically close together (about 50 meters) are best handled logically as one node. The reduction in traffic capacity is marginal, and the gain (in this example) is that we would have only one node to administer instead of six. We can also eliminate 4 of the booking points. Only one timeslot (and beamcar) can pass all these nodes at a time, if this solution is implemented. Figure 3:3 A combination of weaving and diverging nodes close together (as in figure 3:3) might be harder to treat in the same manner. One could probably make the topological equivalence shown, notwithstanding the fact that not all cars can really enter the beams G, H and I. Figure 3:4 The topological equivalent in figure 3:4 is probably more realistic. Stations such as at C in figure 3:1 will often consist of many nodes of both kinds. Although the station as a whole is asynchronous, the weavings will have to be handled by booking points and timeslots at low speeds, according to the model in figure 3:2. More reading about weaving can be found in the chapter "How Weaving Affects Speed".

4. Placement of Booking Points

There are administrative advantages of placing the booking points on both arms equi-distant from the point where the beam merges. There will not be any emphasis on this in FlyWay. Rather, each booking point should be as far away as is feasible, to give the node as much time as possible to plan for the merging of traffic, and to provide a smoother ride. This complicates matter a bit, though. Letīs look at an example If we assume that the booking points are equi-distant from the shunt, as in figure 4:1, we can take a simple example: The feeder beams, A and B, have the same permitted speed as the common beam, C, where the traffic will join after the shunt. A bunch of cars, consisting of 10 vehicles, are approaching on beam A, and a similar bunch on beam B. They will both arrive at the shunt at the same time. With the term "bunch", we mean that the 10 cars are grouped so close together so that each group could occupy 10 timeslots in succession. The booking points are so far removed from the shunt that all 10 timeslots fit into the distance between the booking points and the shunt. In other words, all 20 vehicles have passed their booking points before the first vehicle reaches the node. What happens now is that when car number one on both beams pass their booking points, the node computer will allow one of them (letīs say the one on beam A) to proceed with undiminished speed. The other car (the one on beam B) would be commanded to slow its speed somewhat, so that it would enter the next timeslot on beam C. How is that speed calculated? Well, assuming a permitted speed of v (in meters per second, to simplify calculations), and the distance from booking point to shunt is d meters, the first car would take d/v = T1 seconds to arrive in time to land into timeslot 1. If the timeslots are t seconds apart, the first car from beam B (letīs call it B:1) would arrive just in time for slot number 2 if it adjusted its speed so that d/v = T + t, which gives v = d/(T + t) m/sec. Car A:2 would normally arrive t seconds later, just in time for slot 2. But since slot 2 just got occupied, it would have to wait t seconds for slot 3, and its speed would consequently have to be v = d/(T +t) m/sec. Car B:2 would suffer a further delay; its speed would be v = d/(T + 2*t) m/sec., and so would the speed of car A:3, and so on. We find that the speeed of the last cars would be: For car A:10: v = d/(T + 9*t) m/sec. For car B:10: v = d/(T + 10*t) m/sec. As can be seen, the travel time T2 for car A:10 from booking point to shunt is considerably longer than travel time T1 for car A:1. This can be shown graphically as in figure 4:2, where the slope of each line is proportional to the speed of the car, i.e. the more vertical the line, the faster the car travels. Thus, the last car on beam A would travel the same distance in the time T2 = T + 9*t, and, as can be seen in the diagram, T2 is much longer than T1. If the "bunch" of vehicles on beam B were to arrive at their booking point five cars ahead of the "bunch" on beam A, they would get to go ahead in the order they book, as is shown in the diagram in figure 4:3. Now, what if allowed (or actual) speed on one of the feeder beams were different from on the other feeder beam? Or if the distance from their respective booking points to the node were different? The resulting weaving would be a bit more complex, but it would still follow the same logic. Letīs take some examples. 1) Refering to figure 4:4, Letīs assume that Bo A is 1 000 meters away and Bo B 600 m. away. Allowed speed is 20 m/s. If we have one group of cars of 5 vehicles each, on the 2 beams, and they book simultaneously, then car A:1 would arrive at the node in tA1 = d/v = 1000/20 = 50 seconds. Car B:1 would arrive in tB1 = d/v = 600/20 = 30 seconds. Assuming less than a second between the cars (see table in chapter 2 above), it is clear that all cars on beam B will be long gone, by the time the cars from beam A arrive at the node. So, this was not so complicated. 2) Using the same assumptions as above, but say that the cars on beam A booked 25 seconds before the cars on beam B, as shown in 4:4. For simplicity, letīs say that safety distance through the node is 1 second (which, then, is the length of a timeslot). By the time car B:1 books, cars A:1 through A:5 have received slots T + 0 through T + 4, where T in this example is travel time to the node, i.e. 50 seconds. Here, car B:1 could be at the node at time T + 25 - 20 = T + 5, and car B:1 would get the slot right after car A:5. 3) If we assume that the groups booked simultaneously (with the lead cars booking at time = T0), as did the first group of 10 vehicles (above), the node computer would make this allotment, in chrnological order: Car Timeslot A:1 T0 + 50 B:1 T0 + 30 A:2 T0 + 51 B:2 T0 + 31 A:3 T0 + 52 B:3 T0 + 32 A:4 T0 + 53 B:4 T0 + 33 A:5 T0 + 54 B:5 T0 + 34 There is still no cause for conflict.

Figure 4:1 Figure 4:2 Figure 4:3 Figure 4:4 (Continued from left row) 4) But suppose the cars keep coming (rush hour has arrived!). Then, the table would soon look like this: Car Timeslot A:16 T0 + 65 B:16 T0 + 45 A:17 T0 + 66 B:17 T0 + 46 A:18 T0 + 67 B:18 T0 + 47 A:19 T0 + 68 B:19 T0 + 48 A:20 T0 + 69 B:20 T0 + 49 A:21 T0 + 70 B:21 T0 + 71 A:22 T0 + 72 B:22 T0 + 73 Car B:21, which "should" have received slot T0 + 50 suddenly finds that it has to wait an extra 20 seconds for a free slot, while 20 cars from beam A zip by at undiminished speed, since their slots are already booked! Although true weaving is taking place from now on, this 20-second delay will affect all successive cars on beam B, for the only reason that they booked 20 seconds later than the cars on beam A. Still, this is fair, according to the principle "first come, first served", were it not for this delay, which does not allow the B-cars to take advantage of their beamīs speed limit. The diagram in figure 4:5 below shows what happens. The vertical distance mirrors the real distances from the two booking points to the node, so the slopes of the lines are proportional to the speed of the individual cars. This is a consequence of not having the booking sites equally distant from the node! But; "intelligent weaving" should be able to remedy this. When it comes to situations where the speeds on beams A and B are different, this will in practice have the same effect as the above example, with booking points at different distances. If the booking points here are equi-distant from the node, then the beam having the faster traffic will be penalized in the same manner at high traffic times; with extra waiting time. This, too, could be fixed with "intelligent weaving". But a better remedy might be to simply design the network so that there will be 10-20% empty slots even at high traffic times.

Figure 4:5

5. "Intelligent" Weaving

The six examples in chapter 3 above were very simple examples. In real life, many additional parameters have to be considered, such as: Additional speed limits on individual vehicles, i.e. they can, for some reason, not travel as fast as other vehicles, and maybe not as fast as the guideway segment allows. If any of them is an emergency vehicle, and should get preferential treatment. In congested situations, some vehicles have preference before others. For instance, passenger-filled vehicles go before empty. They also (probably) would go before vehicles carrying cargo. Every vehicle has for every trip a preferential-treatment parameter. In congested situations, the node will modify speed on the beams to suit the current situation. Mandated safety distances can vary from time to time (see chapter 2 above). Platooned vehicles, long vehicles and heavy vehicles might need more than one timeslot, as explained above (In FlyWay, no vehicles gets more than 2 timeslots, not even platooned vehicles). If vehicles in one guideway arm cannot stay in their alloted timeslots due to congestions, the node will temporarily re-assign that guideway as asynchronous, and weave all traffic that has passed that booking point with the traffic from the other arm. At the same time, it will lower timeslot speed and resume timeslot allotment to vehicles that have not yet passed the booking point. During congestion times, the node will continually monitor traffic, and raise or lower timeslot speed as need be. Node controllers can be dynamically reconfigured to adjust timeslot speed and to give traffic on one arm preferential treatment. This is done by the Central computer. Node controllers can also follow a set time schedule and adjust timeslot speed and give traffic on one arm preferential treatment. Different speed limits on the access guideways have to be adequately dealth with. Different distances to the booking points have to be adequately dealth with. Advance notification of what happens up ahead should be possible to handle intelligently. Divergence nodes after booking points should, in some instances, be possible to handle intelligently. Figure 5:1 You can read more about weaving in the chapter "How Weaving Affects Speed".

Comments to some of these points: Some vehicels cannot travel as fast as other vehicles. If these vehicles cannot be re-routed, or kept waiting until there is less traffic, the only thing to do is to adapt traffic speed to this slow vehicle. It will (hopefully) be of short duration. Preferential treatment to some cars. Can only be accomplished be temporarily stopping traffic on the other guideway arm. The "intelligent" node would get advance notis of this vehicle, and can stop other weaving traffic in good time. In congested situations some vehicles have preference before others. This is a routing issue, not much that a singular weaving node can do anything about. In congested situations, the node will modify speed on the beams downward, to prevent potential queueing after the node from disrupt weaving. This is done automatically, but the "intelligent" node will know beforehand when heavy traffic will ensue. It can "plan ahead", and make use of previous experiences, in the form of stored traffic information. Platooned, long and heavy vehicles might need more than one timeslot. It is up to the system to ensure that not more than 2 timeslots will be needed. If vehicles in one guideway arm cannot stay in their alloted timeslots due to congestions, the node will re-assign that guideway as asynchronous, but the "intelligent" node plans ahead. If there is congestion after the weaving, the node will be informed about this, and reduce weaving traffic to a crawl, if necessary. In case of total stop, however, slot allotments breaks down, and both weaving arms will become asynchronous. In such a case, the node will just wait for traffic to easy up and resume a certain speed, at which time it will re-assert control of the vehicles that have not yet passed their booking points, as soon as they pass. Those vehicles affected will be informed of the situation, and will then report to the regional computer rather than the node computer, until the pass the next upcoming booking point. Different speed limits on the access guideways was examined in the previous chapter. Different distances to the booking points was examined in the previous chapter. Returning to our example above, where rush-hour traffic hits a weaving node where the booking points are 50 seconds resp. 30 seconds travel distance away. 50 seconds after a set "start"-time, both groups should be weaving, instead of traffic on one guideway arm having to wait for the other, as happened above. The node would be programmed to either trigger this after it notes a set traffic density has been exceeded, or between certain hours. Thus, at 1 second-intervals (which we choose here for simplicity), after 30 seconds, the first cars from arm B arrives at the node. The intelligent node could then be programmed to, ahead of time, leave some timeslots un-allocated, to be allocated later on. If, for instance, every third timeslot after car A:1 would be left empty, then the allotment table would like table 5:1 below (where many lines have been left out!), and the ensuing diagram would look like in figure 5:2, which should be compared to figure 4:5.

Figure 5:2

Figure 5:3

Table 5:1; Example of "intelligent" weaving of beamcars Car Timeslot A:1 T0 + 50 A:2 T0 + 51 left empty T0 + 52 A:3 T0 + 53 A:4 T0 + 54 left empty T0 + 55 A:5 T0 + 56 A:6 T0 + 57 left empty T0 + 58 A:7 T0 + 59 A:8 T0 + 60 left empty T0 + 61 -- T0 + -- A:15 T0 + 71 A:16 T0 + 72 left empty T0 + 73 A:17 T0 + 74 A:18 T0 + 75 left empty T0 + 76 A:19 T0 + 77 A:20 T0 + 78 left empty T0 + 79 B:20 T0 + 49 A:21 T0 + 80 B:21 T0 + 52 !! A:22 T0 + 81 left empty T0 + 82 B:22 T0 + 55 !! A:23 T0 + 83 B:23 T0 + 58 !! A:24 T0 + 84 left empty T0 + 85 B:24 T0 + 61 !! .. and so on.

These last 2 situations can appear independently of each other. Letīs look at an instance where they both occur together. As we showed in chapter 4, awkward situations can ensue when booking points are not equi-distant from the node, and the same situation applies for different speed limits. The node cannot allot timeslots for a car which cannot get to the node in time. But, the "intelligent" node can anticipate when the situation in figure 4:5 will ensue, and plan ahead, as shown above. Thus, refering to figure 5:1, on beam 1 we have a speed limit of v1, and the distance to the booking point is d1. Likewise, on beam 2 the speed limit is v2 and the booking point distant from the node is d2. Using these parameters, it should be possible to arrive at a general formula for optimizing traffic flow throughtb the node. The node would first calculate which car would first arrive at the weaving point; letīs say that this would be Car 2. The node would of course have to ensure that the apllicable safety distance is enforced. Thus, if car 2, travelling at speed v2 arrives at the node at time t0, and there is no impeding traffic ahead of car 2 on beam 3 to allow for, then car 2 is simply directed by the node to regulate its speed so that it will arrive at the node at time t0. After that, car 1 is directed by the node to likewise regulate its speed so that it will arrive at the node at time t1. The time interval between t0 and t1 will then be equal to the safety distance that applies for the speed that car 1 is given. More text will hopefully be forthcoming here! Continuing on our list, there are two items left to comment: Notification of what happens after the weaving point should be handled intelligently. This is a matter of communicating between nodes. If "our" node gets advance notis that traffic is piling up, before the queue gets to the node, it can slow traffic down so much so that queueing does not build up to reach the node. Because, as stated earlier, if the queue reaches the node, the synchronous weaving breaks down. Case B in figure 5:a shows how advance queueing-information from the node at right enables the left node to slow traffic, thereby preventing the queue to reach the left node. Traffic might move at a crawl, but it keeps moving. Divergence nodes after booking points should, in some instances, be possible to handle intelligently. An example of this technique is detailed under the heading Preventing Gridlock". Essentially, this means that beamcars which choose to diverge away from a weaving node, after having passed the booking point of that weaving node, should be able to tell the weaving node this. And the weaving node should be able to handle that car accordingly. Thus, car A in figure 5:5 would not receive a timeslot by the node, and that slot would thus be available to another car. Figure 5:5 But why would there be a diverging node after the booking point? Well, thats a simple matter of geography; at stations and other places with many guideways, there might be a need for all kinds of nodes close by. As we have seen, booking points should be as far removed as practicable from the weaving node. If they are too close to the node, the node wonīt have time to hand out timeslots to the cars, and the cars wonīt have time to regulate their speeds.

6. Platooning

In this illustration (figure 6:1) 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 vehicles are treated under the chapter "Platooning" on this page, and the tasks of the nodes are treated here. 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 handled by the "intelligent" weaving nodes. 6.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. In figure 6:1, node N4 will likely be the first to note such a situation, in the form of queues at its booking points and/or reports of queueing from "upstream" nodes about their queueing. Node N4 will then proceed with assigning double-size timeslots to 3 or more cars on one or both weaving arms, depending on where the queueing is.

Figure 6:1 It will start with 3 cars per group, and if the queueing doesnīt ease up within a couple of minutes, the node will increase platooning to 4 cars per group, and so on. The lengths of ingoing cars would of course be important, since number of cars might well reach the limit for what can fit into two successive timeslots. And the weight on the beam segments from an accumulation of beamcars will also have to be taken into account, and decide the upper limit to have many cars of varying weights will be included in a group. The node will get weight and length information from each car as it reports at the booking point. So, how many platooned cars can go into two successive time slots? Theoretically, as many as would fill one of these two slots. If we assume slot lengths of 50 meters, all cars being 6 meters in length and having a space of 5 meters in between when being platooned, we would get: X = 50/(6+5) = 4 cars. Thus, if queueing appears at one or both booking points, traffic from that point would be platooned by the "intelligent" node. Looking at figure 6:2, reports of queueing from node N2 would start N4 platooning on its right arm, and reports of queueing from node N3 would start N4 platooning on its left arm. This means that vehicles on the affected arms would have to adapt their speeds from the booking points on, so that they are "properly bunched" when they reach the weaving point.

Figure 6:2 If node N4 notes queueing at its own booking points, it will have to give proper orders regarding speed to the vehicles, but if the node gets queueing reports from upstream nodes, then they will in all likelihood have made the same platooning decision already. If the beams between these nodes are synchronous all the way, then vehicles will arrive "properly bunched" at the booking points of node N4, and it can treat these groups as being one vehicle each, requiring two timeslots. Figure 6:3 shows 5 examples. In view 1 we have ordinary weaving. In view 2, queueing on the right arm causes the node to platoon these (yellow) vehicles 3 by 3, assigning them 2 timeslots each, and interweaving them with single vehicles (of one timeslot each) from the left arm. Timeslots are indicated by S1 - S4. As can be seen, the first group occupies slots 1 and 2, and the single vehicle gets to stay in slot 3. View 3 shows queueing on both joining arms, and consequently, both arms are weaved by platooned vehicles, in groups of 3. View 4 shows persistent queueing, leading to platooning of 4 vehicles in each group, and in view 5 they are 5 in each group. When limits to group sizes are reached, nothing more can be done to ease traffic congestion. In SwedeTracks opinion, platooning is only a temporary measure to ease congestion, and if two timeslots per group is not enough to do the trick, then itīs high time to expand capacity on some beams on the network.

Figure 6:3

6.2. Informing and coordinating the affected cars 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. Platoons can only travel on synchronous beam sections. 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 car do 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).

6.3. Assigning a temporary identity for the combined "car" How to handle platooned cars logically is entirely a programming matter. It can be solved in different ways, and re-assigning the "lead" vehicles as "large", thus requiring two timeslots, is only one solution. It should not be forgotten here that platooning also can (theoretically) be solved in an entirely asynchronous manner. This means that when the queueing gets too big to handle, the node lets go of the synchronous control from the booking points, as detailed further up on this page, and only manage the weaving as the cars arrive at the node itself. This is a tricky part to handle with adequate security, and so, platooning should always be under the control of a weaving node. Another solution is to let the node handle all cars individually, and let them keep their identities. Instead, generated timeslots are reduced to the point where platooning takes effect.

6.4. Making and keeping a logical connection The making and keeping of a logical connection between the "leader car" and the cars that participate. 6.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. 6.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.

7. Contingency Situations

Contingencies are situations that should not normally occur. But they can occassionally happen, and the system has to be prepared for them, and be able to deal with them properly. Some examples: The idea is that the beamcar itself should take the initiative and announce its presence to the node, when the beam sensors tell the beamcar that it is passing a booking point. A simpler method would be that the node gets informed by the booking point sensors every time a car passes, together with the carīs identity, and then assign the car a certain speed to facilitate the weaving. But the car might have other parameters to convey about itself, as listed elsewhere, parameters that will be conveyed to the node and influence its decision. Figure 7:1

What if a car passes a booking point without announcing itself? What if such a transmission gets garbled, or is not of the proper format? It is proposed that the node will give the car about one second after passing the booking point, to send a proper request for a timeslot. After that, the node will forcibly assign the car 2 consecutive timeslots, to guard against the poosibility that the car might be bigger than most other cars (or platooned). The node will also send an error-report regarding this car to the administrative computer. The car will (hopefully) acknowledge this speed assignment, as all cars alloted a timeslot will have to do. If such an acknowledgement is not received at the node within a reasonable time, traffic on that arm will be stopped, and cars approaching from behind will be temporarily re-routed. The faulty car will be manually driven (by remote control) to a suitable place, and traffic will then commence at the node as before the incident. More text will be forthcoming here!