Airport surface traffic planning optimization: a case study of Amsterdam Airport Schiphol

Transcription

1 9th AIAA Aviation Technology, Integration, and Operations Conference (ATIO) <br>and<br>air September 2009, Hilton Head, South Carolina AIAA Airport surface traffic planning optimization: a case study of Amsterdam Airport Schiphol Paul C. Roling 1 Delft University of Technology, Delft, Netherlands Adding runways and taxiways is a way of solving capacity problems at major airport. As this also increases the intensity of airport ground operations, safety and efficiency might be compromised which is why significant amounts of research has been done in this field, such as research with respect to Advanced Surface Movement Guidance and Control Systems. A taxi planning model developed at the TU Delft uses MILP techniques, combined with pre and processing to allow simulation and optimization of the routing of aircraft on taxiways for major airports, such as Amsterdam Airport Schiphol. Introduction As most major airports are operating close to their maximum capacity and are already one of the main causes of delay in the air transport system, the capacity of airport infrastructure is one of the most constraining elements for growth of the system. One of the solutions to deal with these delays is increasing the capacity of airports, which entails enlarging terminals and adding runways and thus also taxiways. As this also increases the intensity and complexity of airport ground operations, concerns can be raised both with respect to safety and efficiency, especially under low visibility conditions. A significant amount of research has been conducted to enhance airport ground movement efficiency under all weather conditions, partially with respect to Advanced Surface Movement Guidance and Control Systems (A-SMGCS 1 ). The taxi planning model presented in this paper, based on earlier work, uses Mixed Integer Linear programming (MILP) through a commercial package called CPLEX 4. Whilst it has previously been shown to work for smaller hypothetical airport models, larger models pertaining to actual airports had not yet been implemented. Airport Model generator Operational plan MILP model builder MILP solution Output converter Airport Model Flight Schedule Route generator MILP problem Optimizer Flight Schedule generator Operational plan Traffic Simulator Operational plan Figure 1: Software components 1 Researcher, Faculty of Aerospace Engineering, [email protected], AIAA Member. 1 Copyright 2009 by P.C.Roling. Published by the, Inc., with permission.

2 Software design Figure 1 illustrates the main components of the taxi planning software, which are: Airport model generator Flight schedule generator Route generator MILP model builder Optimizer Output convertor Traffic simulator A. Airport Model Generator The airport model generator allows the user to create an airport model, as shown in Figure 2, by adding nodes and changing the properties of these nodes. These properties are location (x,y), connected nodes and distance to these nodes and whether these nodes are hold, start or end points for flights as part of a runway or apron. The location of a node is related to a user defined reference point of the airport model, possibly the first node that is entered. The distance to the other nodes is set by default by the relative position between to nodes, but can also be set manually to a different value. By setting a connection to another node this allows aircraft to travel from this node to the other node, simulating a taxiway. Travel in the opposite direction is enabled by setting the current node as a connection in the destination node, which should naturally only be done if travel is allowed in both directions on the same taxiway. Too many two way taxiways should be avoided, as it creates too many possible, but not substantially different, alternative routes. When a node is defined as a hold node this allows aircraft to stand still and wait on this node, which effectively splits the route an aircraft can take into segments. Whilst adding hold nodes allows more options, it also increases the complexity of the Figure 2: Example airport model problem and the number of decision variables, thus assigning hold nodes should be done with care. The best nodes to set as hold nodes are usually nodes just before a crossing or runway. When an aircraft has been defined as part of an apron or a runway it can also be defined as a start or an end point and routes are thus also calculated by the route generator to or from that node. These nodes can the also be selected in the flight schedule. When an aircraft comes from or enters a runway, all of the nodes belonging to this runway are blocked for 30 seconds. B. Flight Schedule Generator The flight schedule generator allows the user to define a schedule with respect to the arrival and departure times of aircraft. To do this, the user needs to add a flight, select a start node and an end node. A start node can belong to a runway, which defines it as an arriving flight, or belong to an apron, which defines it as a departing flight. A start time and an end time also have to be set. For an arriving flight the start time is the time that the arriving aircraft leaves the runway and the end time is then the latest time the aircraft should be at the apron. For a departing flight the end time is the scheduled take-off time at the runway and the start time is the earliest time the aircraft can depart the apron. Each flight can also be given a reduced maximum speed. For larger and more realistic scenarios, which use actual schedule data as a source, a flight schedule can be generated by the airside capacity and delay model of the Airport Business Suite 5 (ABS). The ABS assigns aircraft to the different runways at realistic time intervals, as it is fairly important that aircraft are not scheduled to land or 2

3 take off at the same time as this causes unnecessary conflicts. This then represents a start time for an arriving aircraft and an end time for a departing aircraft. A realistic taxi time buffer for the respective runway or apron distance needs to be applied to create a respective end or start time. Currently the schedule created by the ABS contains a departure and/or arrival runway instead of a node number, which needs to be changed manually. Also the apron nodes have to be set by the user. C. Route generator The route generator searches for all possible routes the aircraft can take in the airport model, as shown in Figure 3, and applies these routes to the flights in the flight schedule. All routes are found by using a brute force algorithm which starts searching at a start node and branches for each possible connecting node and does this until there aren't any connections from the current node, the current node is already part of the branch or the current node is the end node, which makes it a valid route to use from that start node to that end node. The process is also stopped when enough routes are found, a number or iterations has taken place after finding the first route or no more nodes can be added to the branch. The user has to select a maximum number of routes available between each flight and thus between each pair of nodes. When all routes have been found a selection must be made of the routes that are used. The first route is always the one with the shortest distance. To avoid getting only very similar routes in more expansive airport models, the next routes are selected on the product of their length with a factor which represents the difference with the previous routes. This factor is calculated by taking the number nodes that are different Figure 3: Possible route between each two routes divided by the total number of nodes of both routes. This factor, which always has a value between zero and one, is multiplied for every previously selected route. The total process of finding all routes for a model can take a number of minutes. A longer route would normally mean that an aircraft which departs a runway or gate at a certain time would arrive at the gate or runway later. As the departure and arrival times at the runway are fixed a longer route for departing aircraft is compensated by letting a departing aircraft depart from the gate earlier. When all routes are calculates and applied to flights, the time at which the flight is on a each node and link is calculated using the speed of that flight. When a hold-node is encountered, an extra segment is added for the remained of the route. The routes that are generated per flight can then either be sent to the MILP model builder for optimization, or be sent straight to the traffic simulator to show the unconstrained output, with conflicts. D. MILP Model builder The MILP model converts the routes per flight, as generated by the route generator, to the MILP input file problem for CPLEX. As further explained in Ref. 2 and 3, the MILP model consists of an objective function and a number of constraints. The objective function is currently based on the total taxi time for each aircraft, including delay and rerouting. The constraints include node and link occupancy constraints, a route and delay constraint and a waiting time constraint. The node and link occupancy constraints, which are set per node/link and time interval, block a node or link during the time a flight is using it to prevent other flights from using that node or link at the same period of time. Both nodes and links must be constrained as constraining only nodes would allow opposing aircraft to cross each other and constraining only links would allow aircraft to cross each other on crossings. The route and delay and the waiting time constraints fix of the route and delay selection. The route and delay constraint, which is set per flight and segment, forces the optimizer to allocate exactly one route and a specific amount of delay per segment of each flight, whilst the waiting time constraint forces each segment to be part of the same route and the delay of a next segment to be equal or higher than the delay of the segment before it, as delay can only increase, not decrease. To block a node whilst an aircraft is holding on that node, which amounts to incurring delay, an extra waiting variable is introduced. 3

4 E. Optimizer The optimizer is responsible for automatically running CPLEX with the correct parameters, including the input file and a time limit on the duration of the optimization. After CPLEX is started, it checks if the optimization is completed by regularly checking for the existence of the output file. When the output file is detected, the output converter is started. F. Output convertor The output convertor reads the output file with the problem solution, which formulates which route and delay per segment is chosen for each flight, and translates this back to the route, in node at links at a certain time for each flight. This is also saved to a database and can be sent to the traffic simulator to show and record an animation of the results. G. Traffic simulator The traffic simulator is able to present the routes per flight in time by drawing all aircraft present at their coordinates at every time interval onto a drawing of the airport model. If a conflict is present it will light up the conflicting aircraft. Study of Amsterdam Airport Schiphol A detailed model for Amsterdam Airport Schiphol (AMS) was created using the aerodrome chart 6, as show in Figure 4, and consists of a total of 136 nodes with 269 possible connections between them. Of the nodes 39 belong to a runway and two of these belong to two runways as they are the crossings of runway 18L/36R with runway 09/27 and runway 18L/36R with runway 06/24. In total there are 21 start nodes and 18 end nodes, of which 11 nodes are entrances to aprons. 18R 36L 18C 18L Terminal 22 36C Figure 4: Aerodrome chart 6 (left) and taxi planning model (right) of Amsterdam Airport Schiphol 06 36R 4

5 Aircraft operations AC/hr :00 6:00 12:00 18:00 0:00 time Figure 6: Flights over the day The flight schedule that was used was created by the ABS by extracting the busiest day of the year from official airline guide (OAG) data for This so called peak day flight schedule consists of a total of 1113 flights, which are assumed to all travel at an average speed of 12 meters per second, or about 23 knots. The runways are assigned to the flights by the ABS airside capacity and delay model on the basis of a runway configuration in which runways 18R and 18C are used simultaneously for arrivals and runways 18L and 24 are both used for departures. This configuration, which is one that has only been used as a trial, is used to enable a high runway capacity as not cause high amounts of delay and thus a reduction in the number of scheduled operations. The resulting number of flights throughout the day is shown in Figure 6. As there was no apron allocation available, the nodes belonging to the aprons are assumed to be allocated in alternating fashion, partially to reduce the number of possible unnecessary conflicts which would be caused by aircraft trying to use the same apron/node at the same time. Conflicts 250 Conflicts/Aircraft per hour Conflicts Aircraft 0 6:00 7:00 8:00 9:00 10:00 11:00 12:00 Time Figure 5: Number of conflicts during the investigated time interval 5

6 Due to long times needed to clear memory fragmentation and optimization times, the schedule has been reduced to all the flights between 6:00 and 12:00, the busiest time of the day, which reduces the flight schedule to 403 flights and acceptable preprocessing an optimization times. According to the route generator the average unconstrained travel time is seconds, if each aircraft uses the shortest route. As this is unconstrained, application The route generator also detects 320 intervals in which a conflict takes place. Figure 5, which shows the number of flights and the number of conflicts per 15 minute block, shows a slight relation between the number of flights and the number of conflicts. When the plan is optimized, which takes approximately 15 minutes, no conflicts are present and the average travel time per aircraft goes up to seconds, Of the 14.5 second average increase 13.4 seconds is delay. The remaining 1.1 seconds increase in average travel time per aircraft is caused by a total of 65 rerouted aircraft, which is more than 16% of the total of 403. Figure 7 shows a comparison of the unconstrained and the optimized situation at the same point in time (8:38:00) to illustrate the changes that are made during the planning. Flight 146 and 166 are only visible on the optimized are slightly delayed, and thus still on the airfield at that time in the optimized case and flights 164 and 170, which are having conflict with respectively flights 168 and 160 in the unconstrained case, are at completely different location due to rerouting to solve these conflicts. Figure 7: Unconstrained (left) and optimized (right) situation Concluding remarks The taxi planning system does seem to be able to handle more realistic and larger scale simulation. Whilst the calculation pre-processing times do prevent a whole day from being run at one time, a non-stop run of a few hours is possible, which makes an evaluation of changes to the taxiway system possible, even without using the re-planning option. A way of reducing the pre-processing time, which is mostly caused by memory fragmentation during the creation of node and link constraints from the routes, is still being looked at. It should be noted that building models requires special attention, especially with respect to the direction of the taxiways (links) and the availability of holding nodes, where aircraft can stand still as to many to few routes and hold nodes will lead to insolvable conflicts and too many can increase computation time. As shown in Figure 8 more taxi planning models of airports, such as Atlanta and London Heathrow, are being built and will be ready for analyses in the future. A first come first serve algorithm was hoped to be ready to demonstrate, but unfortunately the solutions generated by this algorithm still seem to have a few conflicts in them. The exact cause of these conflicts has not yet been found at time of this writing. 6

7 Figure 8: Models of London Heathrow (left) and Atlanta (right) References 1 International Civil Aviation Organization, Advanced Surface Movement Guidance and Control Systems (A-SMGCS) Manual, First Edition 2004, Doc 9830 AN/452 2 Visser, H. G. and Roling, P. C., Optimal Airport Surface Traffic Planning Using Mixed Integer Linear Programming, AIAA Aviation Technology, Integration and Operations (ATIO) Conference, P. C. Roling and H. G. Visser, Optimal Airport Surface Traffic Planning Using Mixed-Integer Linear Programming, International Journal of Aerospace Engineering, Volume 2008 (2008), Article ID ILOG, CPLEX release 9.1, P.C.Roling, Evaluation of Anchorage International Airport Using the Airport Business Suite, 26 th International Congress of the aeronautical sciences, 2008, AIAA Air Traffic Control the Netherlands, AIP Integrated package, [4 February 2009] 7