The directed graph model of the holding area was introduced in section 2.7.1. As discussed in section 2.7, the decision support system presented in this thesis uses a directed graph model to represent each holding area. The creation of these models from a holding area plan, such as that in figure 6.1, is described in this section.
These holding area models are similar to those used in the research into airport ground movement, reviewed in section 3.8. Although most of the previous research, for example [143, 96, 94, 81, 169], used the nodes to represent the locations at which aircraft could be located, the arcs have instead been used to represent locations in the past, [56]. Nodes rather than arcs were chosen to represent the locations of aircraft for this research as this makes the holding area graph more intuitive and easier to produce.
Holding area plans were available for each of the holding areas. The holding area plans show the taxiways and holding areas as a series of numbered blocks. It is common to be able to hold aircraft at the edge of blocks, so the block positions are important.
6.2.1 Creating the holding area models
The first step in creating the holding area graphs is to plot the paths through the holding area. These paths will later be divided into arcs and nodes. When building these models, controller preferences should be of prime consideration. Where the holding area is already in use, the initial paths added should be those the controllers currently use as these are guaranteed to be acceptable to controllers. If the holding area is not already being used, problem domain knowledge will be needed to identify the acceptable paths for aircraft to follow.
6.2.2 Unusual circumstances or modes of operation
Some paths may be acceptable to controllers, but only used in extreme circumstances. A decision can be made about whether to make these paths available to the decision support system under normal circumstances or only when the controller explicitly permits them. Multiple different models can be produced for the same holding area to support different operating modes. In some models these less desirable paths will exist, in others they will not. Some models may, for example, be used if there is a blockage at a specific point in the holding area, so that paths through the blocked position are not available but paths which would not normally be used become available.
It is possible to use the path allocation system to handle special cases within the same model rather than using different models. Additional flexibility could be included in the models, beyond that which the controllers would normally utilise, but it is important that every included path is achievable. The path allocation system (described in sections 6.3 and 6.4) has to make decisions about which paths to use, and can apply a preference for specific (simpler or shorter)
paths rather than other longer/more complicated paths, or can ensure that less desirable paths are only ever allocated when specific circumstances dictate that it is sensible.
Using different models for different circumstances, rather than using a single combined model and handling special cases within the path allocation system hands control of the decision of when to change the mode of operation to the controller. The controller is deciding whether the situation justifies a change in operation rather than the system making the decision based on its perception of the situation. This is usually a good thing as long as this is done infrequently so that controller workload is not adversely affected. This also has the advantage that each holding area model will be simpler than the combined model, so the task faced by the decision support system will consequently be simpler.
6.2.3 Determining the nodes in the graph
Once paths have been determined, nodes on the paths need to be generated. Nodes should be added to paths at any point at which paths converge or diverge. If paths converge/diverge such that the nodes are very close together and there is insufficient room for aircraft to simultaneously occupy both nodes, then these can be combined into a single node. A node should also be added for each holding point, as these are the positions at which aircraft will usually hold. A node should be added for each exit from the holding area onto the runway (labelled R, T, V and Y in figure 6.2) and a node should be added for each entrance into the holding area (labelled D, G and K in figure 6.2).
Nodes should then be added between the existing nodes to represent the queueing positions between them. The number of such nodes added should be equal to the number of aircraft which can be queued between the nodes when there is an aircraft at each of the existing nodes. Finally, if desired, nodes can be added beyond the entrance nodes to represent aircraft queueing on the taxiways. The nodes labelled A to K in figure 6.2 are of this type.
If nodes are very close together, such that they cannot be simultaneously occupied by aircraft, then the two nodes should be replaced by a single node. This is important because the feasibility check will assume that each node can be simultaneously occupied and will use the number of nodes to determine the occupancy restrictions.
Once all of the nodes have been identified, arcs are added to join the nodes along the identified paths. The majority of arcs will be uni-directional, as aircraft usually head for the runway from the entrances. Some arcs may be bi-directional and will need special handling within the feasibility check described later. If the arcs are used in different directions only under different circumstances or modes of operation then the building of multiple models, one for each circumstance, should be considered. It is important to try to keep the holding area models as simple as possible, in order to reduce the complexity of the feasibility check.
As the graphs are used for determining whether re-sequencing is possible, it is important that the graphs represent the re-sequencing that can be done rather than strictly denoting the
positions at which aircraft can be held within the holding area. At times this may mean that nodes denote regions rather than specific positions, to model the fact that an aircraft in that area will block other paths. It is important to understand how the controllers use (or would use) the holding areas to re-sequence the aircraft. With this understanding, it is possible to ensure that the models for the holding areas allow them to be used in the ways that the controllers desire.
Once the initial model has been created, a number of simple tests can be applied. It should be possible to simultaneously have an aircraft at each position represented by a node in the graph. It should also be possible for an aircraft to perform the movement related to the traversal of each arc in the graph even when all other nodes of the graph that are not linked by the arc are occupied by aircraft.
Plans of the four holding areas are given below. Directed graphs for the three commonly used holding areas (09R, 27R, 27L) are provided for comparison between the physical layout and the directed graphs used in this research. The fourth holding area (09L) can be considered to be a cut-down version of the 09R holding area if a graph is required so will be ignored here.
6.2.4 The 27R holding area
Figure 6.1 shows a plan of the 27R holding area. There are three main entrances for aircraft, at blocks 32(O), 39(O) and 49 on the plan. There are two exits from the holding area onto the runway, entering the runway at blocks 18 or 19. Block 19 is preferred as it allows the entire runway to be used and permits an aircraft to be lined up more swiftly.
Figure 6.1: Plan of the 27R holding area
The 27R holding area can be thought of as having three take-off queues, with some limited opportunity for aircraft to move between queues, hold to be overtaken or overtake other
Figure 6.2: Directed graph model of the 27R holding area
aircraft in the queue.
The first take-off queue enters at block 136 and passes through blocks 137 and 134 before entering the runway. There is a possibility to overtake an aircraft that is holding at the front of 137 by turning right in 137 and passing down the right hand side of the holding aircraft, through the front of 133 and 134. Finally, an aircraft could turn left from 137 and enter the runway in block 18. This is not ideal, however, as the end of the runway is preferred.
The second queue runs from 132 to 133 then 134 and out to the runway. Aircraft may take a longer route if necessary, allowing them to be overtaken. For example, an aircraft which has to wait a long time for a CTOT take-off time-slot could be instructed to turn right at 133 into block 40. It could then taxi along to block 8 and wait. If necessary, the aircraft could be instructed to turn left at block 133, into the back of block 137 and enter the runway at block 18. Again this is not ideal.
Theoretically, an aircraft could turn left at block 133, into 137 then turn right and hold at the front of 137. It could then follow the normal route from 137 back into 134 and line up for the runway. Although possible (and playback of historic data shows it is used occasionally) a controller stated that the amount of manoeuvring this requires is prohibitive, so the path was eliminated from consideration.
The final runway queue uses the end of the third runway, labelled as blocks 49, 43, 40 and 8, before turning left onto the runway. If an aircraft using this queue has to overtake another aircraft in the queue it can turn left at block 40, allowing it to overtake anything queued at the front of block 40 or in block 8.
The way in which this behaviour has been modelled, as a directed graph, is shown in figure 6.2. The implementation of some nodes directly prohibits certain undesirable behaviour.
For example, node R on the graph denotes both the holding point between block 40 and block 19 and the south-west position of block 40 itself. Doing this prevents aircraft from taxiing from blocks 43 to 40 if there is an aircraft waiting to enter the runway from the holding point at block 40. If this behaviour is to be permitted then an additional node should be added to the graph between node R and the runway to represent this holding position.
6.2.5 The 27L holding area
The 27L holding area is more flexible and much bigger than the 27R holding area. A plan of the holding area is shown in figure 6.3 and a directed graph model in figure 6.4.
The 27L holding area consists of two disjoint holding areas, one north and one south of the runway. In normal operation, aircraft from terminal four will use the south side and aircraft from terminals one, two and three the north side. This reduces the number of runway crossings required.
South of the runway there is a single runway queue which splits into two queues (at block 95) which then converge again (in block 88). Aircraft can take the shorter route, or the longer route allowing holding at block 94. The entire queue can be bypassed by entering the runway from block 118 but as these aircraft do not enter the runway at the end this is not ideal. North of the runway, the situation is much more flexible. Aircraft can enter the holding area via blocks 73/74, 48/54, 48/50 or 49/51, depending upon where they are taxiing from and the route they take to get to the holding area. The main route through the holding area is via block 131, after which aircraft can queue on the left (block 138) or right (block 75) before entering the end of the runway. An alternative route allows entrance to the runway via block 130. This appears to be used more for aircraft from 73/74 than the other entrances. As it does not enter the runway at the end, it is not as useful, but it allows aircraft to overtake all those waiting at 75 or 138.
Any aircraft entering via blocks 50 or 51 can be directed into the main route via 54 and 131, or can take the path 141, 56 and 71 to the end of the runway. Taking the latter path is quite restrictive, however, as there is then no way to further re-sequence the aircraft. A common way to use this path is to use blocks 140 and 139 as holding positions and route the rest of the aircraft straight down 141, 56 and 76. This assumes that any aircraft which need a delay will be removed from the queue and the rest of the aircraft will then be able to leave in the order they are queued, by appropriate interleaving them with aircraft waiting at 75, 138, 87 and 130.
Figure 6.3 : Plan of the 27L holdin g area Figure 6.4 : Directed graph mo del of the 27L holding area
6.2.6 The 09R holding area
Figure 6.5 shows a plan of the 09R holding area. There is one long queue north and one long queue south of the runway. This holding area has undergone much change recently, with the building of terminal five. The new plan is more flexible and has a second entrance queue north of and parallel to the northern queue. The old plan was kept for this research as it provides an interesting example of how the decision support system algorithm performs in a more constrained situation.
From both of the existing queues, there is the possibility to enter the runway early, rather than at the end. Controllers sometimes use these entrances at quiet times if aircraft do not need the full runway for take-off. They can also be used to overtake aircraft waiting near the end of the runway and are valuable for increasing the re-sequencing opportunities.
One controller mentioned that, prior to the changes, the throughput was often kept high by performing partial sequencing of aircraft prior to entry at the holding area. The results in chapter 8 will show that the decision support system can cope well even without this pre- sequencing.
Figure 6.5: Plan of the 09R holding area
Figure 6.6: Directed graph model of the 09R holding area
A directed graph model is given for the holding area in figure 6.6. Even though a number of exits to the runway are shown there is no reason for a decision support system to
support them all. Indeed, the decision support system described here would not use all of them in normal operation.
Near the end of the runway, the northern queue opens out into an overtaking area in block 98. Effectively, this overtaking area allows one queue of aircraft to be held around the outside of the area while other aircraft overtake along the inner side, nearer to the runway. This behaviour could be implemented either as two queues (a long one around the outside of the turn and a shorter one around the inside) or a parking place for a number of aircraft to be overtaken and an overtaking path. The graph in figure 6.6 makes no assumptions about how block 98 will actually be used.
The southern path also has a limited ability for overtaking. It is possible to move an aircraft along to the end of the path and line up right at the end of the runway while another aircraft takes the other path and lines up in front of it on the runway. This is not ideal though, due to the manoeuvring involved. In this case, in the holding area graph, node Z should be considered to represent the end of the runway.
6.2.7 The 09L holding area
The 09L holding area is hardly ever used, in order to control noise for nearby residents. The plan is shown in figure 6.7. It can be thought of as a reduced version of the 09R holding area. The overtaking that can be performed is very limited compared with any of the other three holding areas. This holding area is ignored in this research, because it is very simple and because it is very rarely used in practice. The solution method for the 09R holding area will also work for the 09L holding area, which has a reduced subset of the 09R functionality.
Leese et al. showed in [124] that a dynamic programming approach is appropriate for this kind of holding area as the number of re-sequencing options is so small, although that research did ignore some of the other constraints and objectives of the re-sequencing and it ignored the runway entrance from block 116 to 113.