Full text
Study of navigation charges in Europe Document: Report Author: Daniel Cenador Garc´ıa Director/Co-director: Oriol Lordan Gonzalez Jos´e Mar´ıa Sall´an Leyes Degree: Master’s degree in Aerospace Engineering Examination session: Spring 2023
Study of navigation charges in Europe Abstract This study focuses on the development of a code capable of generating a 2D route (a series of waypoints with latitude and longitude coordinates) between two airports inside Eurocontrol Area, that minimizes the total cost of navigation charges and fuel. To achieve it, the code utilizes as database EUROCONTROL’s DDR2, to obtain the geographical frontiers of En-route Charging Zones and its Unit Rates, the airways and waypoints defining the air network and the historical traffic data to obtain general aircraft performances and to compare and validate results. A wind model is also applied, as the shortest route will be always the most fuel efficient in no wind conditions. To find the optimal route, the model first generates a graph representing the airway network, and generates several different connection paths between the airport of origin and the destination. Next, for each path obtained it is calculated the en-route charges and fuel estimated its fuel consumed. It is needed to create a vertical profile to compute fuel, and it is based on historical flight data. The result obtained is the list of waypoints that constitutes the route, its distance, time required and the costs calculated. This tool developed provides an easy approximation of two most important direct operating costs of an Airspace Operator when contemplating a new route, while also providing the route itself. I
Study of navigation charges in Europe Contents 1 Introduction 1 1.1 Object................................................. 1 1.2 Scope ................................................. 1 1.3 Requirements............................................. 2 2 State of the art 3 2.1 NavigationCharges.......................................... 3 2.2 DemandDataRepository ...................................... 3 2.3 FuelEstimation............................................ 4 3 Background 5 3.1 En-routeNavigationCharges .................................... 5 3.1.1 ParticipatingStates ..................................... 5 3.1.2 Calculation .......................................... 5 3.2 FuelEstimation............................................ 6 3.2.1 OpenAP............................................ 6 4 Methodology 9 4.1 Inputfiles............................................... 9 4.2 Packagefunctions........................................... 10 4.2.1 Adapter............................................ 10 4.2.2 Speedtablecreator...................................... 12 4.2.3 Enginetablecreator ..................................... 12 4.2.4 PathFinder.......................................... 12 4.2.5 PathFinder2......................................... 13 4.2.6 Navigationcharges...................................... 14 4.2.7 Fuelcalculation........................................ 14 4.2.8 Flightdispatcher....................................... 16 5 Results 17 5.1 Navigation Charges per business model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 II
CONTENTS CONTENTS 5.2 Generalmodelperformance ..................................... 18 5.3 Generationofsingleroutes ..................................... 19 6 Discussion of the results 24 6.1 Navigation Charges per business model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.2 Generalmodelperformance ..................................... 25 6.3 Generationofsingleroutes ..................................... 28 7 Budget summary and/or economic feasibility study 31 8 Analysis and assessment of environmental and social implications 32 9 Conclusions 33 9.1 Futurework.............................................. 33 III
Study of navigation charges in Europe List of Figures 3.1 The structure of OpenAP.[5] .................................... 7 3.2 Forces acting on the aircraft in the point-mass dynamic performance model. [5] . . . . . . . . 8 4.1 Plot of the ECZs over the European map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2 Shortest path from LEMD to LIRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3 Windeffectongroundspeed .................................... 15 5.1 Performance of the most common Airspace Operators for the study . . . . . . . . . . . . . . . 18 5.2 Error of the generated ECs respect M1 ECs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Cheapest trajectory generated for route LEPA - EDDL . . . . . . . . . . . . . . . . . . . . . 20 5.4 Cheapest trajectory generated for route EGLL - EHAM . . . . . . . . . . . . . . . . . . . . . 20 5.5 Cheapest trajectory generated for route EIDW - EDDF . . . . . . . . . . . . . . . . . . . . . 20 5.6 Cheapest trajectory generated for route LEMD - LPPT . . . . . . . . . . . . . . . . . . . . . 21 5.7 Cheapest trajectory generated for route EHAM - EKCH . . . . . . . . . . . . . . . . . . . . . 21 5.8 Cheapest trajectory generated for route EKCH - ESSA . . . . . . . . . . . . . . . . . . . . . . 21 5.9 Cheapest trajectory generated for route LGAV - LCLK . . . . . . . . . . . . . . . . . . . . . 22 5.10 Cheapest trajectory generated for route LTAI - EDDL . . . . . . . . . . . . . . . . . . . . . . 22 5.11 Cheapest trajectory generated for route GCTS - EGBB . . . . . . . . . . . . . . . . . . . . . 22 5.12 Cheapest trajectory generated for route LRAR - LTAI . . . . . . . . . . . . . . . . . . . . . . 23 5.13 Cheapest trajectory generated for route UMMS - UGKO . . . . . . . . . . . . . . . . . . . . . 23 6.1 Absolute error for the generated ECs respect M1 ECs . . . . . . . . . . . . . . . . . . . . . . 26 6.2 LROP-LRCL route, in red the generated route, in green the M1 routes . . . . . . . . . . . . . 27 6.3 Error of the generated ECs respect M1 ECs on west Europe . . . . . . . . . . . . . . . . . . . 27 6.4 Trajectory of the eastern route candidate (in red) compared with different filled flight plans (ingreen) ............................................... 28 6.5 Trajectory of the western route candidate (in red) compared with different filled flight plans (ingreen) ............................................... 29 IV
Study of navigation charges in Europe List of Tables 4.1 ICAOLTOcycledefinition ..................................... 15 5.1 Parameters of the generated routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1 Outliers per method (from 6275 routes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.2 Parameters of the three generated routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3 GCTS - EGBB results with different winds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.1 Budgetofthestudy ......................................... 31 V
Study of navigation charges in Europe List of abbreviations / Glossary ANS - Air Navigation Services AO - Aircraft Operator APM - Aircraft Performance Model ATM - Air Traffic Management CI - Cost Index CRCO - Central Route Charges Office DDR2 - Demand Data Repository v2 ECZ - En-route Charging Zone GHG - Greenhouse gas GS - Ground Speed ISA - International Standard Atmosphere MTOW - Maximum TakeOff Weight TAS - True AirSpeed VS - Vertical Speed ZFW - Zero Fuel Weight VI
Study of navigation charges in Europe Chapter 1 Introduction 1.1 Object The principal aim of this study is to understand how navigation charges are applied to Airspace Operators and estimate routes optimizing the reduction of this fare. 1.2 Scope To guarantee the achievement of the objectives, the following scope is established. •Understand Eurocontrol en-route charges methodology. • Create a code able to calculate the en-route charges for any flight reported inside Demand Data Repository (DDR2) traffic files. • Study en-route charges characteristics of the most busiest Aircraft Operators (AOs) during the available data. •Create a code capable of generating a route path minimizing the en-route charges applied. These objectives were accomplished earlier than expected, so the scope was widen to include a fuel estimation for the optimization of costs for generated routes: •Literature review for fuel estimation methodologies • Create a code that estimates fuel consumption for a 2D aircraft trajectory and integrate it on the route generator. 1
3.2. FUEL ESTIMATION CHAPTER 3. BACKGROUND Figure 3.2: Forces acting on the aircraft in the point-mass dynamic performance model. [5] The fuel flow model depends on the required thrust T and the altitude h . The definition of this model is derived based on the ICAO aircraft engine emissions databank [6]. 8
Study of navigation charges in Europe Chapter 4 Methodology The code developed during this project is grouped inside a R package. This section is meant to describe how the functions inside the package works and the methodology used to obtain a route path and its cost for navigation and fuel. 4.1 Input files The following external files are needed for the code to execute: DDR2 traffic files: The traffic data files used from the DDR2 (extension .so6) is divided in two files, M1 and M3. DDR2 Airway Network: This file (extension .ase) contains the data necessary to create a graph representing the European airway network. DDR2 SID and STAR: Two files (extension .sid and .star) contains a dictionary relating the SID and STAR that appear in the airway network with the airport ICAO code. CRCO ECZ map: This file (extension .are) contains the coordinates defining each ECZ around the glove. CRCO Unit Rates: This file (extension .ur) contains the Unit Rates for each European ECZ, source [7]. CRCO Aircraft Weights: This file (extension .mwc) contains the MTOW (in tonnes) of different aircraft models. All this files are included in the DDR2, which are classified and have been provided by the director of this thesis. Aircraft yaml files: They are obtained from the OpenAP source code [8], at /openap/data/aircraft. The multiple .yml files contain the technical characteristics for each aircraft model compatible. 9
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY 4.2 Package functions The code for this project is included in the separated Annex following the same order as this report. 4.2.1 Adapter The adapter is the part of the code in charge of reading the external files and modifying them into the data structure the code uses, and stored on .RDS files, a common format for saving R objects. Loading .RDS files is much faster, so the adapter has only to be used when updating the input files. It is composed by the following functions: DDR2 traffic loader This function transforms the raw data from the DDR2 traffic files (M1 and M3) into 3 separate data tables [9], one containing information about flights, other containing information about the segments flown and the last one contains the information of the points. This code was developed by Oriol Lordan and was given to the students of the subject Transport Aeri on this master degree. Data structure description •Flight table: – fl id: Flight identifier – fl ori: ICAO identifier for origin airport – fl des: ICAO identifier for destination airport – ac type: Aircraft type – call: Flight number – airl: Airline – plan: Boolean true for flight plan data (M1) and false for actual flown trajectories (M3) •Route table: – fl id: Flight identifier – plan: Boolean true for flight plan data (M1) and false for actual flown trajectories (M3) – id1: The identifier of the starting point of the segment – id2: The identifier of the ending point of the segment – time1: Start time of the segment – time2: End time of the segment – FL1: Flight level at the start of the segment – FL2: Flight level at the end of the segment 10
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY – stat: A factor, 0 for climb, 1 for descent, 2 for cruise. •Points table: – id: Point identifier – lat: Latitude in minutes – lon: Longitude in minutes Loader for ECZ map This function creates 2D polygons using the frontier data of the ECZ from the CRCO ECZ map file. The are stored in an object of class SpatialPolygons [10]. Figure 4.1: Plot of the ECZs over the European map Loader for charges This function reads the .ur file and creates a datatable storing the ID of the ECZ and its Unit Rate expressed in cents of EUR. The function ask to manually input of the Unit Rates for the Participating States (Egypt [11], Morocco [12] and Uzbekistan [13]), as their rate are not included in the .ur file. Loader for aircraft weights This function reads the .mwc file and creates a datatable storing the aircraft model and its MTOW in tonnes. Loader for the airway network This function reads the .SID,.STAR and .ase files and creates four datatables. The first one contains the information of all the segments that compose the graph of airways, the 5 letters ID for the starting and ending waypoint of a segment and its distance in meters. This graph is directed, the existence of the segment PERAL - NITBA does not imply that the connection NITBA - PERAL exists, and must be specified if it is the case. 11
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY The second and third datatables are the dictionaries for ICAO Airport to SID or STAR. For example, in the graph there is no point called LEBL, the end points are called BCN.D and BCN.A (OACI code plus Departure or Arrival). This is made to separate the start and ending points of the graph. The last datatable contains the latitude and longitude of each waypoint. Loader for Wind This function calls the package RWind to create a wind field, containing the velocity in meters per second, and the direction, in degrees respect north, of the wind. The reports are made every half of degree of latitude and longitude. The wind field data is stored in a datatable. 4.2.2 Speed table creator This function calculates the average ground speed (GS) and vertical speed (VS) per aircraft model based on the historical data of the M1 file. It is calculated independently for three flight phases: climb, cruise and descent. M1 contains the distance traveled each segment, the start and ending time and the start and ending flight level, to compute the GS and VS, and with the stat factor, segments are already separated by flight phase. The average GS and VS per phase of the flight is calculated by the mean value of the segments with the same stat value. For cruise values, the average GS and maximum FL per aircraft model is calculated. But for climb/descent, the average is calculated per aircraft and per airport of origin/destination, to take into account the departure/arrival procedure of the specific airport. The average GS and VS only per aircraft is also calculated with climb/descent, for the airport-aircraft pairings with little to no historical data. As the data used has multiple locations from different times of the day, it is assumed that the average effect of the wind is negligible, so GS values can be considered as TAS. The data obtained is stored on 5 datatable, inside a .RDS file, as recalculation is not necessary unless the M1 file is updated. 4.2.3 Engine table creator This function reads all the .yml files inside /aircraft folder, and stores a datatable inside a .RDS containing the default engine for a specific aircraft model. 4.2.4 Path Finder TThis part of the code is in charge of generating possible paths between the origin and destination airports. The first step is to build a directed and weighted graph using the package igraph [14], the weight is the length of the edge in meters. The package igraph has two functions to generate paths, shortest paths, that outputs the path with the 12
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY smallest weight using the Dijkstra algorithm, and all simple paths, that outputs all simple paths between two points (a simple path is a path in a graph which does not repeat vertices). Due to the size of the graph (21358 vertices and 54417 edges), the second option is unfeasible regarding its computational time. In order to generate more than one path with the function shortest paths, once obtained the shortest path, half of its edges are deleted from the graph, not the quarter first and last to respect the departure and arrival procedures. In Figure 4.2 can be seen the output route from the shortest paths function, the edges in red are the ones that will be deleted from the airways graph in the next iteration, to force the short path to be different. The edges in green, that constitutes the departure and arrival procedures, are preserved. Figure 4.2: Shortest path from LEMD to LIRF This algorithm is good to explore n different routes, being n an input of the function. The computational time scales linearly with n. 4.2.5 Path Finder 2 A second algorithm for finding multiple paths, also based on the function shortest path. The previous algorithm focused on exploration while this one is a heuristic algorithm focused on exploitation. The algorithm starts by calculating the shortest path of the original graph. For each edge of the shortest path, that edge is deleted from the original graph and a new shortest path is generated for this modified graph. On each iteration it may not find new paths, because it ends on a path previously found, or because the edge deleted disconnects the two points inside the graph. The amount of paths found with this method is not enough, so it has to run a wider search. From the already found paths, it is calculated the number of times an edge appears and n of the most common edges are taken. With these edges are generated all possible combinations of n 2 individual edges (rounding to the closest natural number), and for each combination, these edges are removed from the original graph and it is calculated as the shortest path on this modified graph. The value of nis an input, and the CPU time of the algorithm scales at an approximate rate of 2n 4. 13
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY 4.2.6 Navigation charges This function is in charge of calculating the navigation charges, defined in Section 3.1. The Weight Factor W F is common for all the flight, and is calculated from the certified MTOW (Equation 3.2). This MTOW value can be imputed by the user, otherwise it uses the default value from the DDR2 aircraft database loaded. The distance factor DF is more complicated to calculate, as it depends on how the ECZ were crossed during the flight. First, the array of waypoints that compose the route is converted into their latitude and longitude coordinates, and stored as a 2D line using an object SpatialLines. With the trajectory defined as a 2D line and the ECZs defined as 2D polygons, the function intersect from package raster is able to divide the trajectory in segments, for each ECZ crossed. The start and the end of each segment represents the entry and exit point of the ECZ for that flight. The DF is obtained by calculating the Great Circle Distance between entry and exit points (using package Geosphere and the function distHavesine), in kilometers, and then dividing by 100. It is also taken into account that each takeoff and landing performed on the ECZ subtracts 20 km to the great circle distance. The UR for the ECZs are already loaded from the DDR2 database. Finally, using Equation 3.1, the en-route navigation charges are calculated for the entirety of the flight. 4.2.7 Fuel calculation For the fuel calculation, after obtaining the 2D trajectory (the coordinates of the waypoints of the path), a vertical profile with time reports has to be estimated to obtain the 4D trajectory the APM asks for. The estimation is based on average speed values obtained from the historical data of the M1 file, stored on the Speed table (Section 4.2.2). Using the average TAS and VS at climb phase, for the specific aircraft and origin airport, it is calculated how much time the aircraft needs to reach cruise FL, and with this time and the TAS, the distance covered on the climb phase. The methodology for the descent phase is equivalent but using descent speeds at the airport of destination. By subtracting the distance covered in climb and descent from the total trip distance, the cruise distance is obtained, and with the cruise TAS, its obtained the time required. For short flights that do not reach average cruise FL of the aircraft, it is considered that the descent starts just after the climb at the middle of the trajectory. Now, for each waypoint of the path, it is known the altitude, latitude, longitude and time respect the take off, achieving a 4D trajectory. Furthermore, two new waypoints are defined on the trajectory, indicating the top of climb and top of descent. 14
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY Figure 4.3: Wind effect on ground speed Figure 4.3 shows the effect of the wind on the ground speed. The TAS without wind, that would equal to the GS, is shown in gray. When the wind speed is taken into consideration, a drift angle appears between the heading and the track, to compensate for the orthogonal wind component. The GS is the sum of the TAS and wind speed alongside the track. To compute the effect on the wind per flight segment, it is found the closest wind report to the starting and ending point on the segment, and these two wind reports are used on each half of the segment to calculate the new GS, then the new time required to fly that segment. This simple approach is chosen in behalf of keeping the computational time small. The fuel calculations are based on the OpenAP APM and on the LTO cycle (Landing and TakeOff) definition used by ICAO on Engine Emissions Databank [15]. Table 4.1: ICAO LTO cycle definition Mode Thrust Time Take-off 100% 0.7 min Climb 85% 2.2 min Approach 30% 4.0 min Taxi 7% 26 min From the OpenAP APM two functions from the fuel model are used to obtain the current fuel flow feed to the engines. The fuel model is defined with the aircraft model and engine type. The first function asks for the TAS, altitude and thrust (from 0 to 1), the second one is meant for cruise phase and its inputs are mass, TAS and altitude. For the fuel consumed on the take-off, the fuel flow is obtained for an altitude of 0, TAS of 0 and Thrust of 1, 15
4.2. PACKAGE FUNCTIONS CHAPTER 4. METHODOLOGY and the time used is defined by ICAO LTO (Table 4.1). For the climb, the fuel flow is obtained from the current altitude, the average TAS for climb and Thrust at 0.85. The fuel flow value is recalculated at a new altitude each 1000 ft. For the cruise phase, the specific function is used. It is required to keep track of the current mass of the aircraft. A initial mass is required as input, then the fuel consumed on take off and climb is subtracted. The fuel flow is calculated using the current mass, TAS for cruise and altitude. Each minute the variation of mass is calculated and the fuel flow updated. For the descent, the fuel flow is obtained from the current altitude, the average TAS for descent and Thrust at 0.3. The fuel flow value is recalculated at a new altitude each 1000 ft. Finally, fuel for 26 minutes of taxi at altitude 0, TAS of 15 kt and with a Thrust at 0.07. All fuel consumptions are added to obtain the total fuel consumption. The fuel computation depends on the mass of the aircraft, and the mass of the aircraft depends on the amount of fuel loaded. For this reason the fuel calculation needs to be recursive. It starts by using as an input the ZFW and it is calculated how much fuel it needs, then starts a new iteration for the initial mass of ZFW + the fuel result obtained. The iterations continue until the fuel required converges. An increase in fuel lower than 2% is considered as a convergence. 4.2.8 Flight dispatcher This is the final function that integrates all functionalities. It starts by generating a graph object (igraph package) containing the airway network. The input OACI airport codes to its SID/STAR equivalent, if an airport has multiple SID/STAR points, it is chosen the closest to the flight path. It calls one of the path finder algorithms to create multiple routes, and for each route, it is calculated the en-route charges and fuel consumption. The output is, for each route analyzed, an array containing the waypoints that define the route, its distance in kilometers, its flight time in minutes, the en-route charges, fuel consumption and the total cost (EC + fuel) in EUR. 16
Study of navigation charges in Europe Chapter 5 Results The data used for the calculations time window is between the 15th and 19th of September 2022, with the exception of the wind data. RWind contains data from November 2022 to the present-day. The time selected for the wind is the 18th of January 2023, 12:00, chosen arbitrarily, so wind results are inconclusive. Three different groups of results have been calculated. First, the EC for the historical traffic on the M1 has been obtained to generate a small picture of how navigation fees are charged depending on the business model of the AO. AOs keep this data confidential, so there is no real data to compare the output of the program to assess its accuracy. By obtaining behaviors on EC that relate to the differences between AOs business models is an approach to assess that the calculation of EC may be accurate. The second results aims to measure accuracy by comparing the model results to the historical data results. Furthermore, it is compared the result of a trajectory that is the GCD, the output of the model that is shortest route and the output of the model optimized to minimize the cost. The GCD is the simplest approach to calculate EC and the shortest route is obtained by just using the Dijkstra algorithm to the weighted graph of airways. Comparing these 3 method measures if the effort of building a more complex model has a meaningful effect on the accuracy of the results. Finally, a selection of single routes have been generated, a bunch of them trying to cover the most common intra-European routes while covering different parts of the territory, and compare them to the real data to assess if the output route of the program is feasible and detect errors. 5.1 Navigation Charges per business model To assess the relation of the En-route Charges (EC) with the Airspace Operator business model, the navigation charges of the actual flown trajectories (DDR2 M3) for the top 8 most common AO has been calculated. Only routes fully flown inside EUROCONTROL Participating States Charging Areas are taken into consideration. 17
Study of navigation charges in Europe Chapter 6 Discussion of the results In this section will be discussed the results obtained in Section 5. 6.1 Navigation Charges per business model The categorization of the business model of the AO will follow the study of Magdalina and Bouzaima [17], where airlines are grouped into four business models: full-service carriers (FSC), low-cost carriers (LCC), hybrid 1 (H1) and hybrid 2 (H2). •RYR: Ryanair LCC •DLH: Lufthansa FSC •THY: Turkish Airlines FSC •EZY: easyJet UK LCC •WZZ: Wizz Air LCC •VLG: Vueling H2 •EJU: easyJet Europe LCC •AFR: Air France FSC Vueling is considered a Hybrid due to its random radial network configuration. Its operation is based on a hub (LEBL) as a FSC, but its frequencies are not gathered in waves to fill a long-haul flight, they are distributed along the day similar to the point-to-point network of a LCC. The first indicator calculated is the average EC per operation, which shows a high relation with the AO business model (shown in Figure 5.1, top right). The 4 LCC have the higher charges per operation, followed by the hybrid, and finally the FSC. This effect is explained by the data selection, by only reviewing European flights, the long-haul flights of the FSC are outside the scope, remaining the short flights filling them, which tend to be short and domestic (the share of domestic flights analyzed is in Figure 5.1, middle left), where 24
6.2. GENERAL MODEL PERFORMANCE CHAPTER 6. DISCUSSION OF THE RESULTS Turkish Airlines and Air France have the highest share. Lufthansa is an exception due to the German political movements to reduce domestic flights [18]. The point-to-point network has higher EC per operation. The second indicator calculated is the EC per unit of distance. All AO have a similar value, around 1.3 euros per nautical mile, except Turkish Airlines. This indicator does not depend on the business model, rather on the location of the operation. Turkey is the second cheapest ECZ, with an UR of 17.10 €, and Turkish Airlines has 52% of local flights and 99.8% of flights starting or ending at Turkey. The two bottom graphs of Figure 5.1 contain the main metrics used to calculate the en-route charges, average leg distance and the average MTOW of the aircraft used. The leg distance is definitely correlated with the EC per operation, where Wizz Air and easyJet UK have the longer legs and highest EC per operation. The interesting case is Turkish Airlines, which has an on pair EC per operation with the other FSC when its EC per distance is nearly half. This is compensated with having higher average leg than the FCSs and the weightiest fleet, operating the A330-300 216 times (212 tonnes), the A330-200 132 times (230 tonnes), the B777-300ER 95 times (351 tonnes), etc. 6.2 General model performance Figure 5.2 represents the different errors obtained for each route, by showing their distribution in a box plot. The model performs better than the GCD approach, shown by having the median on 0 and low kurtosis (the Q1 and Q3 ,25% and 75% percentile frontiers, closer to each other). The skewness of the GCD error to the negative shows that most of the time it is flown a route with higher EC than the GCD. This is generated due to GCD route being a fully implementation of the free-route concept and the real data constructs segmented routes. From comparing the shortest route with the cheapest route, the cheapest ends performing slightly better. The diamond represents the average error value, but it is miss-leading as negative errors compensate positive ones. Figure 6.1 contains the absolute error for the same data. Now, the average error is lower for the GCD, while the median is lower for the two output models, which indicates a problem with outliers. 25
6.2. GENERAL MODEL PERFORMANCE CHAPTER 6. DISCUSSION OF THE RESULTS Figure 6.1: Absolute error for the generated ECs respect M1 ECs To identify outliers is used the interquartile range (IQR), which is the distance between the Q1 and the Q3. Any value at a distance of 1.5 IQR is considered an outlier. Tmin =Q1−1.5IQR Tmax =Q1+1.5IQR Where Tmin and Tmax are the thresholds for finding the outlier. Table 6.1: Outliers per method (from 6275 routes) Method Number of Outliers GCD 626 Generated Cheapest 1095 Generated Shortest 956 Some of those outliers have really high values, and by analyzing these routes individually, the limitations of the model can be assessed. The route from Bucharest Henri Coand˘a International Airport (LROP) to Cluj International Airport (LRCL) is the worst performing route, with an error for EC of 4.78. Figure 6.2 shows in red the path of the M1 flights for the route, and in red the route generated by the model. This route is actually the shortest between these two airports on the airways graph, showing a lack of airways in Romania airspace. 26
6.2. GENERAL MODEL PERFORMANCE CHAPTER 6. DISCUSSION OF THE RESULTS Figure 6.2: LROP-LRCL route, in red the generated route, in green the M1 routes Actually, the lack of airways on Romania airspace is not an error, by checking Eurocontrol regional upper airspace charts [19] it is shown that Romania has no airways in their upper airspace, due to its early implementation of Free Route Airspace (FRA). Romania is not the only exception, most of the south-east of Europe (Hungary, Slovakia, Croatia, Czech Republic, Bosnia and Herzegovina, Montenegro or Albania) have no airways on their upper airspace, and only contains airways on the lower level, and this code does not implement a distinction between upper and lower level airways. By selecting only airspace of west Europe (LP Portugal, LE Spain, LF France, LI Italy, LS Switzerland, ED Germany, EK Denmark, EG United Kingdom, EI Ireland, EB Belgium and EH Netherlands), the model obtains lower errors (shown in Figure 6.3). Figure 6.3: Error of the generated ECs respect M1 ECs on west Europe 27
6.3. GENERATION OF SINGLE ROUTES CHAPTER 6. DISCUSSION OF THE RESULTS 6.3 Generation of single routes To assess the quality of the routes generated by the program, optimizing the total cost (EC + fuel), will be compared with the DDR2 M1 traffic data. The first route selected to be optimized is Palma de Mallorca (LEPA) - D¨usseldorf International (EDDL), selected by the high frequency on the M1 file (73 flights), possible paths can cross different ECZ and its on a region of the map where the definition of the airway network adequate (problem detected in previous section). Figure 5.3 shows 20 of the M1 trajectories for the route (in green). There are clearly two different paths followed by the AO during the time of the study, an eastern and a western path. The reason why there are two distinct paths may be due to the time window of the study being 5 consecutive days, and multiple winds are faced. Furthermore, France has military restricted airspace north of the Pyrenees, reason why not middle paths are flown. The obtained route (in red) reassembles the eastern path on the early and late portions of the route. By looking at other route candidates, the model generated a route much more similar to the eastern paths (Figure 6.4). A candidate similar to the western routes is shown on Figure 6.5. The code is unable to find a candidate path equal to the western routes performed, showing a lack of exploration on the graph. Figure 6.4: Trajectory of the eastern route candidate (in red) compared with different filled flight plans (in green) 28
6.3. GENERATION OF SINGLE ROUTES CHAPTER 6. DISCUSSION OF THE RESULTS Figure 6.5: Trajectory of the western route candidate (in red) compared with different filled flight plans (in green) Table 6.2: Parameters of the three generated routes Fig. EC [€]Fuel [€]Total [€]Time [min] Dist. [km] 5.3 1135.48 4174.57 5310.05 132 1450.8 6.4 1179.05 4180.98 5360.00 133 1468.2 6.5 1158.90 4713.98 5872.88 148 1631.1 Table 6.2 contains the parameters of the three routes discussed. The routes from Figure 5.3 and 6.4 are quite similar in terms of fuel consumption, distance and flight time, but differ on EC, as the eastern one enters Switzerland ECZ, with the second highest UR. The third route has a much higher difference in cost and time to be considered competitive. A route much easier to generate correctly is London Heathrow (EGLL) - Amsterdam Schiphol (EHAM), with the result shown in Figure 5.4. It is not appreciated in the image, but there are 62 green trajectories representing the M1 data that are overlapped by the red generated path, as all of them are identical. The next route analyzed is Dublin (EIDW) - Frankfurt (EDDF). The path for the optimal route generated, the one with lowest cost, is shown in Figure 5.5 in red. It is hardly appreciated in the figure, but for M1 trajectories (shown in green), the southern is operated two times, the green one in the middle is operated once, and, under the generated path, there are 16 green trajectories, validating the generated one. Figure 5.6 contains the route Madrid (LEMD) - Lisbon (LPPT), with reports on the M1. The route seems to diverge when reaching LP airspace, still the branch generated by the program is the one most common one. The route Amsterdam Schiphol (EHAM) - Copenhagen (EKCH), in Figure 5.7, is a route generated on pair with the traffic data. Copenhagen (EKCH) - Stockholm Arlanda (ESSA) (Figure 5.8 have 52 flights on M1, most following the found trajectory, but can be seen as exceptions where the flight was performed north and south of the 29
6.3. GENERATION OF SINGLE ROUTES CHAPTER 6. DISCUSSION OF THE RESULTS obtained trajectory. The route from Athens International (LGAV) - Larnaca International (LCLK), in Figure 5.9, also covers the route most performed by the historical data (51 flights performed in M1). Figure 5.10, route Antalya (LTAI) - D¨usseldorf (EDDL), shows a clear route where the code under performs, the historical traffic goes all far east that the obtained route, over countries with lower navigation fares. As explained before, some countries overflown by the historical data have FRA, without airway definition, so the path finder algorithm never generated a path similar to the historical data, and the result differs from the M1 reports. The route from Tenerife (GCTS) to Birmingham (EGBB), shown in Figure 5.11, is an interesting result, as for the 11 operations it had, many different routes have been performed, even one through Atlantic airspace, that are outside the scope and the code can not generated. The many different routes performed could be caused by different winds. To test this hypothesis, the program has been run again with different wind data from another arbitrary day (18th of March, 2023, 12:00). The optimal route path did not change. Two winds has been tested but the optimal route continues to be the same. Table 6.3 shows the indicators for the route with different winds, distance and EC are equal as the trajectory, but the effect of the winds affects the fuel consumption and flight time. Table 6.3: GCTS - EGBB results with different winds Wind date EC [€]Fuel [€]Time [min] Dist. [km] 18/1/23 1851.66 9973.04 290 3055.2 18/3/23 1851.66 9742.06 284 3055.2 18/5/23 1851.66 9901.18 288 3055.2 18/6/23 1851.66 9631.76 281 3055.2 The route from Arad International (LRAR) to Antalya (LTAI), in Figure 5.12 is another example of not having airways over the countries with implemented FRA. The final route generated, Minsk (UMMS) - Kutaisi International (UGKO) is an interesting result, as the generated route goes straightforward while the historical data takes a high inefficient deviation. This is due to the date of the data, September 2022, Ukraine is at war and its airspace is closed to civil aviation. This is the reason for the flight deviation. Table 6.2 contains the indicators for the routes generated. Comparison with real data is unfeasible due to the rejection of AO to share this type of information, the only use this table has is to compare the the routes between them, and check that no route has an unexpected high fuel consumption or flight time compared with routes of similar distance. 30
Study of navigation charges in Europe Chapter 7 Budget summary and/or economic feasibility study The estimation of the cost of the study is presented in Table 7.1. The most and only relevant field is human resources, the amount of hours the student has dedicated sum up to 300 h. Free-source software has been the single tool used on the development of this study. Table 7.1: Budget of the study Resource concept Total Cost [€] Human resources 2400.00 Software resources 0.00 Energy resources 2.64 Hardware resources 30.00 Total 2432.64 31
Study of navigation charges in Europe Chapter 8 Analysis and assessment of environmental and social implications The route generation model of this study minimizes a cost composed by en-route charges and fuel consumption. Any optimal route that an increase of fuel cost generates a further decrease of the total cost, possible due to the different Unit Rates of the ECZ, will indicate that more fuel is burned and more CO2, NOx, SOx and HC are released to the atmosphere. The Aviation Industry Greenhouse Gas (GHG) emission corresponds to 3.8% of the global share. And 6% of the Aviation GHG are due to Air Navigation System (ANS) inefficiencies [20]. The emissions generated due to flying longer distances to reduce navigation charges correspond to this share. 32
Study of navigation charges in Europe Chapter 9 Conclusions The first objective of this study is to create a method to calculate the navigation charges for an AO. The objective has been achieved and demonstrated with a short analysis of the navigation charges applied during the time of the study (from 15th to the 19th of September 22). The second objective is to create a model to generate routes, represented using a list of waypoints, and these routes being optimized to minimize its navigation and fuel cost. The achievement of this objective is more difficult to detail. The only way to assess if the route obtained is feasible is to compare it with current AO routes, obtaining that for some routes the historical and generated routes coincide, while for others not, and the source of these discrepancies could be multiple. First, this model ignores the concept of Cost Index (CI), that takes into account the relation between the cost of a minute and the cost of a kg of fuel, and it is the key factor on trajectory optimization, even being a pilot input to flight in a fuel-saving or time-saving regime. Another source of error is the weather forecast AO uses to plan their flights, outside wind fields, that are implemented on the model, weather reports contain information about possible weather events, such as thunderstorms, which have to be avoided. The weak point of the model is the airways graph. First, it does not support free routing, so the routes that cross FRA are unoptimized, and even in some cases, there is no connection between to airports in the airway network. Secondly, the search algorithm for route candidates from the graph is the most CPU consuming process of the model, which is the reason why two different algorithms have been developed, one focused on fast exploration, mainly used for calculating multiple city pairs (example, the results obtained in Section 6.2), and a second algorithm, focused more on exploitation than exploration, with a high computational cost, used for single city pair studies. But the heuristic of this algorithms generates that the best possible route may not be ever a candidate, as shown in Figure 6.5, where a similar route has to be used to compare with the real traffic data as the same route never was generated to be evaluated. 9.1 Future work For a follow up to this study, the following extensions and improvements could be developed: 33