WO2016086278A1

WO2016086278A1 - Determining a preferred flight plan

Info

Publication number: WO2016086278A1
Application number: PCT/AU2015/050771
Authority: WO
Inventors: Zhe XU; Robert FITCH; Bertrand MASON; Salah Sukkarieh; Michael Carter; Leon POON; Seng Keat GAN; Nicholas LAWRANCE; Vsevolod Vlaskine
Original assignee: The University Of Sydney
Priority date: 2014-12-04
Filing date: 2015-12-04
Publication date: 2016-06-09

Abstract

A method and system for determining a preferred flight path is disclosed. In one aspect, a processing system constructs a probabilistic roadmap search graph 360 including PRM nodes (362) and PRM edges (370). Each PRM node 362 includes a latitude/longitude pair (364) and an altitude (366). Each PRM edge (370) extends between two PRM nodes (362). Departure and destination nodes (380, 390) for take-off and landing weights (384, 394) are connected to the search graph (360) thereby generating costed climb and descent edges (386, 396) to reachable PRM nodes (362). The search graph (360) is searched by the processing system (100) to determine one or more of a cost minimised potential flight path between the locations (382, 392). A cost of traversed PRM edges (370) are calculated during the search. A potential flight path is selected using an objective function for outputting a preferred flight plan.

Description

DETERMINING A PREFERRED FLIGHT PLAN

Technical Field

[0001] The present disclosure relates to a method, processing system and computer readable medium for determining a preferred flight plan for an aircraft.

Background

[0002] As the commercial airline industry becomes more competitive and the cost of fuel increases, there is a greater emphasis on evaluating potential flight paths between a departure location and a destination location.

[0003] Furthermore, this problem is complicated when airlines consider whether a new aircraft could be purchased to offer flights between the departure location and the destination location. In particular, the decision of which aircraft to purchase depends on a prediction of how well a candidate aircraft will perform overtime. Performing factors of interest are the quantity of passengers and cargo that the aircraft can transport (payload) and how much fuel the aircraft will consume (fuel consumption).

[0004] Purchasing decisions are often made by an airline at the time when the candidate aircraft is still under development by the manufacturer. Therefore, the airline must rely on the minimal data provided by the manufacturer in evaluating the candidate aircraft's performance. Currently, the information provided by the manufacturers is limited to performance estimates on isolated generic routes. The airline must extrapolate from this data the performance of the aircraft on its intended route pattern over a period of years. The intended route pattern is not known to the manufacturer but only by the airline.

[0005] Airlines generally use flight planning software to predict performance on desired routes but available software does not allow for large-scale analysis of many routes with fine grained estimates. These limitations in turn limit the accuracy of performance prediction.

[0006] The reference in this specification to any prior publication (or information derived from the prior publication), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from the prior publication) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates.

Summary

[0007] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Preferred Embodiments. This summary is not intended to identify key features or essential features of the claimed subj ect matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0008] In a first aspect there is provided a method for determining a preferred flight plan for an aircraft, wherein the method includes, at the processing system, steps of: constructing a probabilistic roadmap (PRM) search graph including:

PRM nodes, each including:

a latitude and longitude pair of a flight space; and

an altitude from an altitude set; and

PRM edges, each extending between two PRM nodes;

connecting, to the PRM search graph, departure nodes and destination nodes for a departure and destination location for various take-off and landing weights respectively thereby generating climb and descent edges connecting the departure and destination nodes to reachable PRM nodes, each climb and descent edge having a cost based on fuel consumption data;

searching the PRM search graph to identify one or more of a cost minimised potential flight path between the locations via a portion of the climb, PRM and descent edges, wherein a cost of traversed PRM edges are calculated during the search using the fuel consumption data; selecting one of the potential flight paths as a preferred flight path using an objective function; and

outputting a preferred flight plan based on the preferred flight path.

[0009] In certain embodiments of the first aspect, the search performed by the processing system includes traversing the PRM search graph from the destination node back to any of the departure nodes whilst calculating a weight of the aircraft at each traversed PRM node using the fuel consumption data. [0010] In a second aspect there is provided a method for determining a preferred flight plan for an aircraft, wherein the method includes, at the processing system, steps of: constructing a probabilistic roadmap (PRM) search graph including:

PRM nodes, each including:

a latitude and longitude pair of a flight space;

a weight from a weight set; and

an altitude from an altitude set; and

PRM edges, each extending between two PRM nodes and including a cost based on fuel consumption data;

connecting, to the PRM search graph, departure nodes and destination nodes for a departure and destination location for various take-off and landing weights respectively thereby generating climb and descent edges connecting the departure and destination nodes to reachable PRM nodes, each climb and descent edge having a cost based on the fuel consumption data;

searching the PRM search graph to identify one or more of a cost minimised potential flight path between the locations via a portion of the climb, PRM and descent edges;

selecting one of the potential flight paths as a preferred flight path using an objective function; and

outputting a preferred flight plan based on the preferred flight path.

[0011] In certain embodiments of the first and second aspect, the latitude and longitude pair of a flight space may be randomly sampled.

[0012] In certain embodiments of the first and second aspect, the step of searching the PRM search graph to identify may be performed for each landing weight.

[0013] In certain embodiments of the first and second aspect, the fuel consumption data is at least partially dependent upon weather prediction data.

[0014] In certain embodiments of the first and second aspect, the method includes: determining, by the processing system, one or more contingency paths for each potential flight path; and

determining, by the processing system, a contingency fuel consumption for each potential flight path based upon the one or more contingency paths and the fuel consumption data. [0015] In certain embodiments of the first and second aspect, the the objective function is at least partially dependent upon the contingency fuel consumption for each potential flight path.

[0016] In certain embodiments of the first and second aspect, the method includes connecting a plurality of diversion nodes for diversion locations to the PRM search graph for varying weights, wherein each potential flight path identified includes a diversion flight path to one of the diversion nodes from the respective destination node or a top of decline node, wherein the processing system calculates a fuel consumption for travelling along the diversion flight path which is at least part of the respective contingency fuel consumption.

[0017] In certain embodiments of the first and second aspect, each identified potential flight path includes an equi-fuel flight path from an equi-fuel point along the respective potential flight path which consumes the same amount of fuel to travel to a pair of the diversion locations, wherein the processing system calculates a fuel consumption for travelling from the equi-fuel point to one of the diversion locations which is at least part of the respective contingency fuel consumption.

[0018] In certain embodiments of the first and second aspect, each identified potential flight path includes an equi-time flight path from an equi-time point along the respective potential flight path which requires the same travel time to a pair of the diversion locations, wherein the processing system calculates a fuel consumption for travelling along the equi-time flight path which is at least part of the respective contingency fuel consumption.

[0019] In certain embodiments of the first and second aspect, after identifying the potential flight paths and prior to selecting one of the potential flight paths according to the objective function, the method includes, for each potential flight path:

connecting, by the processing system, a plurality of DPA (Designated Point All engines operating) nodes to the PRM search graph; and

searching the PRM search graph to identify a DPA flight path to one of the DPA nodes from one of the PRM nodes for each potential flight path, wherein the processing system calculates a fuel consumption for travelling along the DPA flight path which is at least part of the respective contingency fuel consumption.

[0020] In certain embodiments of the first and second aspect, the method includes applying, by the processing system, continuous optimisation to the preferred flight path, wherein the optimised preferred flight path is output as part of the preferred flight plan.

[0021] In certain embodiments of the first and second aspect, the processing system is a server processing system, wherein the method includes:

the server processing system receiving from a client processing system a request to determine the preferred flight plan for the aircraft, and

the server processing system transferring to the client processing system a response indicative of the preferred flight plan for the aircraft.

[0022] In certain embodiments of the first and second aspect, the method includes the server processing system receiving aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data.

[0023] In certain embodiments of the first and second aspect, the processing system is a multi-core processing system, wherein the method includes using multiple cores of the multi-core processing system simultaneously in order to search the PRM search graph for the various landing weights of the destination nodes.

[0024] In certain embodiments of the first and second aspect, the method includes: filling the aircraft with one or more of fuel and a payload such that the aircraft has a take-off weight substantially corresponding to the weight of the respective departure node of the preferred flight plan; and

operating the aircraft substantially according to the preferred flight plan.

[0025] In a third aspect there is provided a processing system for determining a preferred flight plan for an aircraft, wherein the processing system is configured to perform the method of the first or second aspect and certain embodiments thereof. [0026] In fourth aspect there is provided a computer readable medium including executable instructions for execution by a processing system, wherein the processing system is configured to perform the method of the first or second aspect and certain embodiments thereof.

[0027] In a fifth aspect there is provided a system for determining a preferred flight plan for an aircraft, wherein the system includes:

a processing system configured to perform the method of the first or second aspect and certain embodiments thereof, wherein the processing system is a server processing system; and

a client processing system in communication with the server processing system via a network;

wherein the client processing system transfers to the server processing system a request to determine the preferred flight plan, and the server processing system transfers a response to the client processing system indicative of the preferred flight plan.

[0028] In certain embodiments of the fifth aspect, the server processing system receives aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data.

[0029] In a sixth aspect there is provided a method for determining a preferred flight plan for an aircraft, wherein the method includes the steps performed by a processing according to the first or second aspect and certain embodiments thereof, wherein the processing system is a server processing system, wherein the method further includes steps of:

a client processing system transferring to the server processing system a request to determine the preferred flight plan, and

the client processing system receiving a response indicative of the preferred flight plan outputted by the server processing system.

[0030] In certain embodiments of the sixth aspect, the method includes the server processing system receiving aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data. [0031] Other aspects and embodiments will be appreciated throughout the detailed description.

Brief Description of the Drawings

[0032] Example embodiments should become apparent from the following description, which is given by way of example only, of at least one preferred but non- limiting embodiment, described in connection with the accompanying figures.

[0033] Figure 1 illustrates a functional block diagram of an example processing system that can be utilised to embody or give effect to a particular embodiment;

[0034] Figure 2 illustrates an example network infrastructure that can be utilised to embody or give effect to a particular embodiment;

[0035] Figure 3 A is a flowchart representing an example method of determining a preferred flight plan for an aircraft;

[0036] Figure 3B is a schematic representing an example data structure of the PRM search graph in relation to the method of Figure 3 A;

[0037] Figure 4A is pseudocode of Algorithm 1 representing a further example method of determining a preferred flight plan for an aircraft;

[0038] Figure 4B is a flowchart representing the example method of determining a preferred flight plan for an aircraft shown in Figure 4A;

[0039] Figure 5 is pseudocode of Algorithm 2 representing an example method of constructing an airmap;

[0040] Figure 6 illustrates the connection of high-level and low-level vertices as part of determining an airways portion of an airmap;

[0041] Figure 7 is pseudocode of Algorithm 3 representing an example method of determining an airways portions of an airmap; [0042] Figure 8 is pseudocode of Algorithm 4 representing an example method of determining a free-flight portion of an airmap;

[0043] Figure 9 illustrates an example method appending OTS routes to an airmap;

[0044] Figure 10 illustrates an example of an OTS route with a free-flight segment;

[0045] Figure 11 illustrates an example of two UPR directs connecting into a free- flight region;

[0046] Figure 12 illustrates an example of connecting free-flight gates in a UPR airmap to free-flight vertices in an airmap;

[0047] Figure 13 is pseudocode of Algorithm 5 representing an example method of stitching together a UPR airmap with an airmap;

[0048] Figure 14 illustrates an example approach to handling via point constraints;

[0049] Figure 15 is pseudocode of Algorithm 6 representing an example method of conducting a path search;

[0050] Figure 16 is pseudocode of Algorithm 7 representing an example method of finding a minimum cost path with respect to the airmap;

[0051] Figures 17 to 20 are pseudocode of Algorithms 8 to 11 respectively and represent exemplary methods of conducting a forward search;

[0052] Figure 21 is pseudocode of Algorithm 12 representing an example method of stitching the forward search with the reverse search;

[0053] Figure 22 is pseudocode of Algorithm 13 representing an example method of joining the forward and reverse graphs at a single point;

[0054] Figure 23 is pseudocode of Algorithm 14 representing an example method of determining the top-of-descent location for each decent path, after graphs have been stitched; [0055] Figure 24 is pseudocode of Algorithm 15 representing an example method involving a pruning algorithm;

[0056] Figure 25 is pseudocode of Algorithm 16 representing an example method of performing a continuous optimization;

[0057] Figure 26 is pseudocode of Algorithm 17 representing an example method involving a back-tracking line search algorithm used as part of a continuous optimization;

[0058] Figure 27 is pseudocode of Algorithm 18 representing an example method of managing the free-flight constraints;

[0059] Figures 28A and 28B illustrate an example method of generating an airmap graph from an existing path in order to meet free-flight constraints;

[0060] Figure 29 is pseudocode of Algorithm 19 representing an example method of generating an airmap graph from an existing path in order to meet free-flight constraints;

[0061] Figure 30 is pseudocode of Algorithm 20 representing an example method of generating an airmap;

[0062] Figure 31 is pseudocode of Algorithm 21 representing an example method of searching for mid-segment step climb and descent points;

[0063] Figure 32 is pseudocode of Algorithm 22 representing an example method of identifying equi-fuel and equi-time points for calculation of DPI, DPD and ETOPS CPE points;

[0064] Figure 33 is pseudocode of Algorithm 23 representing an example method of determining the best diversion airport;

[0065] Figure 34 is pseudocode of Algorithm 24 representing an example method of determining an alternate flight plan;

[0066] Figure 35 is pseudocode of Algorithm 25 representing an example method of finding the DP A; [0067] Figure 36 is pseudocode of Algorithm 26 representing an example method of conducting a fuel search;

[0068] Figure 37 is pseudocode of Algorithm 27 representing an example method of conducting fuel tankering;

[0069] Figure 38 is pseudocode of Algorithm 28 representing a further example method of determining a preferred flight plan for an aircraft;

[0070] Figure 39 is pseudocode of Algorithm 29 representing an example method of constructing of the PRM search graph;

[0071] Figure 40 is pseudocode of Algorithm 30 representing an example method of connecting the departure point to the PRM search graph constructed by Algorithm 2;

[0072] Figure 41 is pseudocode of Algorithm 31 representing an example method of searching the PRM search graph to determine the preferred flight plan for the aircraft;

[0073] Figure 42 is pseudocode of Algorithm 32 representing an example method of determining alternate paths;

[0074] Figure 43 is pseudocode of Algorithm 33 representing an example method of determining a DPA path;

[0075] Figure 44 is pseudocode of Algorithm 34 representing an example method of determining a DPD point;

[0076] Figure 45 is pseudocode of Algorithm 35 representing an example method of determining ETOPS point;

[0077] Figure 46A is a flowchart representing an example method of determining a preferred flight path for an aircraft;

[0078] Figure 46B is a schematic representing an example data structure of the PRM search graph in relation to the method of Figure 46 A; [0079] Figure 47 is pseudocode of Algorithm 36 representing an example method of constructing of the PRM search graph of Figure 46B;

[0080] Figure 48 is pseudocode of Algorithm 37 representing an example method of searching the PRM search graph of Figure 46B to determine the preferred flight path for the aircraft;

[0081] Figure 49 is pseudocode of Algorithm 38 representing an example method of determining alternate paths for the method of Figure 46 A; and

[0082] Figure 50 is a system diagram representing an example system for determining the preferred flight plan.

Description of the Preferred Embodiments

[0083] The following modes, given by way of example only, are described in order to provide a more precise understanding of the subject matter of a preferred embodiment or embodiments.

[0084] In the figures, incorporated to illustrate features of an example embodiment, like reference numerals are used to identify like parts throughout the figures.

1. Processing System and Infrastructure Example

[0085] A particular embodiment of the present disclosure can be realised using a processing system, an example of which is shown in Figure 1. In particular, the processing system 100 generally includes at least one processor 102, or processing unit or plurality of processors, memory 104, at least one input device 106 and at least one output device 108, coupled together via a bus or group of buses 110. In certain embodiments, input device 106 and output device 108 could be the same device. An interface 112 can also be provided for coupling the processing system 100 to one or more peripheral devices, for example interface 112 could be a PCI card or PC card. At least one storage device 114 which houses at least one database 116 can also be provided. The memory 104 can be any form of memory device, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc. The processor 102 could include more than one distinct processing device, for example to handle different functions within the processing system 100.

[0086] Input device 106 receives input data 118 and can include, for example, a keyboard, a pointer device such as a pen-like device or a mouse, audio receiving device for voice controlled activation such as a microphone, data receiver or antenna such as a modem or wireless data adaptor, data acquisition card, etc. Input data 118 could come from different sources, for example keyboard instructions in conjunction with data received via a network. Output device 108 produces or generates output data 120 and can include, for example, a display device or monitor in which case output data 120 is visual, a printer in which case output data 120 is printed, a port for example a USB port, a peripheral component adaptor, a data transmitter or antenna such as a modem or wireless network adaptor, etc. Output data 120 could be distinct and derived from different output devices, for example a visual display on a monitor in conjunction with data transmitted to a network. A user could view data output, or an interpretation of the data output, on, for example, a monitor or using a printer. The storage device 114 can be any form of data or information storage means, for example, volatile or non-volatile memory, solid state storage devices, magnetic devices, etc.

[0087] In use, the processing system 100 is adapted to allow data or information to be stored in and/or retrieved from, via wired or wireless communication means, the at least one database 116. The interface 112 may allow wired and/or wireless communication between the processing unit 102 and peripheral components that may serve a specialised purpose. The processor 102 receives instructions as input data 118 via input device 106 and can display processed results or other output to a user by utilising output device 108. More than one input device 106 and/or output device 108 can be provided. It should be appreciated that the processing system 100 may be any form of terminal, server, specialised hardware, or the like.

[0088] The processing system 100 may be a part of a networked communications system 200, as shown in Figure 2 of the drawings. Processing system 100 could connect to network 202, for example the Internet or a WAN. Input data 118 and output data 120 could be communicated to other devices via network 202. Other terminals, for example, thin client 204, further processing systems 206 and 208, notebook computer 210, mainframe computer 212, PDA 214, pen-based computer 216, server 218, etc., can be connected to network 202. A large variety of other types of terminals or configurations could be utilised. The transfer of information and/or data over network 202 can be achieved using wired communications means 220 or wireless communications means 222. Server 218 can facilitate the transfer of data between network 202 and one or more databases 224. Server 218 and one or more databases 224 provide an example of an information source.

[0089] Other networks may communicate with network 202. For example, telecommunications network 230 could facilitate the transfer of data between network 202 and mobile or cellular telephone 232 or a PDA-type device 234, by utilising wireless communication means 236 and receiving/transmitting station 238. Satellite communications network 240 could communicate with satellite signal receiver 242 which receives data signals from satellite 244 which in turn is in remote communication with satellite signal transmitter 246. Terminals, for example further processing system 248, notebook computer 250 or satellite telephone 252, can thereby communicate with network 202. A local network 260, which for example may be a private network, LAN, etc., may also be connected to network 202. For example, network 202 could be connected with Ethernet 262 which connects terminals 264, server 266 which controls the transfer of data to and/or from database 268, and printer 270. Various other types of networks could be utilised.

[0090] The processing system 100 is adapted to communicate with other terminals, for example further processing systems 206, 208, by sending and receiving data, 118, 120, to and from the network 202, thereby facilitating possible communication with other components of the networked communications system 200.

[0091] Thus, for example, the networks 202, 230, 240 may form part of, or be connected to, the Internet, in which case, the terminals 206, 212, 218, for example, may be web servers, Internet terminals or the like. The networks 202, 230, 240, 260 may be or form part of other communication networks, such as LAN, WAN, Ethernet, token ring, FDDI ring, star, etc., networks, or mobile telephone networks, such as GSM, CDMA or 3G, etc., networks, and may be wholly or partially wired, including for example optical fibre, or wireless networks, depending on a particular implementation. First example overview

[0092] Referring to Figure 3 A there is shown a flow chart representing an example method 300 performed by a processing system 100 for determining a preferred flight plan for an aircraft. The method of Figure 3 A will be described below in conjunction with Figure 3B which represents a data structure used in method 300.

[0093] In particular, at step 310 the method 300 includes constructing, at a processing system 100, a probabilistic roadmap (PRM) search graph 360. The PRM search graph 360 includes a plurality of PRM nodes 362 and PRM edges 370. Each PRM node 362 includes a randomly sampled latitude and longitude pair 364 from an flight space and an altitude 366 from a discretised altitude set. Each PRM edge 370 is fuel feasible according to fuel consumption data stored in memory 104 of the processing system 100 and extends between two of the PRM nodes 362 of the PRM search graph 360.

[0094] At step 320, the method 300 includes connecting, to the PRM search graph 360 by the processing system 100, one or more departure airport nodes 380 and one or more destination nodes 390 for a departure and destination location respectively. Generally, the departure location 382 is a departure airport and the destination location 392 is a destination airport. In addition to each departure and destination node having a latitude/longitude pair 382, and altitude 382, 392, each departure and destination node 380, 390 additionally has a unique take-off or landing weight 384, 394 associated therewith from a discretised weight set, which is made up of one or more weight values. Fuel feasible climb and descent edges 386, 396 are generated when connecting the departure nodes and the destination nodes 380, 390 to some of the PRM nodes 362 respectively. Each climb and descent edge 386, 396 that is connected to the PRM search graph 360 includes an associated cost which is determined by the processing system 100 using at least the fuel consumption data.

[0095] At step 330, the method 300 includes searching the PRM search graph 360 to identify a cost minimised potential flight path for each landing weight 394. Each potential flight path includes a climb edge 386 connected to a portion of the PRM edges 370 which in turn is connected to one of the descent edges 396 such that the flight path extends from one of the departure nodes 380 to one of the destination nodes 390. During the search, the cost of the traversed PRM edges 370 are calculated during the search using the fuel consumption data. This is known as "lazy evaluation". The result of the search is a plurality of cost minimised potential flight paths for the various landing weights 394.

[0096] At step 340, the method 300 includes selecting, by the processing system 100, one of the potential flight paths as the preferred flight path using an objective function stored in memory 104.

[0097] At step 350, the method 300 includes outputting, by the processing system 100, a preferred flight plan based on the selected flight path.

[0098] It will be appreciated that processing system 100 can be provided which is configured by a computer readable medium having executable instructions stored thereon or therein to perform the above method 300. Additionally, a computer program can be provided which includes executable instructions which when executed by the processing system 100 performs the above method 300.

[0099] The above-described method 300 can be considered a search problem of a high-dimensional state space. The state space is defined by, but not limited to, the tuple < X Y, Z, W, T, CI, GW>, where Χ, Υ, Ζ represent spherical coordinates (latitude, longitude, altitude), JFis a weather vector that represents air temperature, wind direction and wind magnitude, Jis time, CI is a velocity function, and GWis the gross weight of the aircraft. The search is subject to constraints that arise from physical limitations of the aircraft, government regulations, and business rules. The goal is to find a set of paths that minimises a cost function, where the cost function can depend on both fuel consumption and time. The set of paths includes the main route and sub-routes that lead to alternate destinations. This goal can also be viewed as a highly-structured control policy that maps state to action.

[00100] When the method 300 is performed by the processing system to determine a preferred flight path for an aircraft between a departure location 382 and a destination location 392, the processing system 100 can be provided input by a user indicative of a query type representing one or more spatial constraints for the search. In particular, these query types can include for example: 1. Fixed track: The main route path is constrained to follow a given lateral (latitude/longitude) path. Sub-routes to alternate destinations are also constrained to follow given lateral paths. The given path is constructed from airways segments and possibly non-airways segments.

2. Airways: The main route path and alternate paths are constrained to follow the defined airway structure.

3. Freeflight: The start and end of the path are constrained to follow the airway structure. The remaining path subset is not constrained in its lateral motion and is free to take any path with a defined lateral region (the freeflight region) where non-airways flight is permitted.

4. Fixed range: There are no lateral constraints. Instead, a fixed ground distance is given.

[00101] The processing system 100 uses the inputted query type to construct the PRM search graph 360 in memory 104 according to the spatial constraints corresponding to the query type input provided by the user.

[00102] It will be appreciated that an airways segment is the great-circle path connecting two waypoints along an airway. A waypoint is a latitude/longitude point. An airway is a sequence of waypoints that defines a lateral path. Waypoints and airways form the airway structure, are defined by governmental organisations for use in commercial aviation. A non-airways segment is the great-circle path between two waypoints that is not included in any airway.

[00103] In particular embodiments, as will be explained in more detail below, the processing system 100 can be configured to determine one or more contingency paths for each potential flight path. The processing system 100 then determines a contingency fuel consumption for each potential flight path based upon the one or more contingency paths and the fuel consumption data. The objective function applied by the processing system 100 for selecting the preferred flight path is at least partially dependent upon the contingency fuel consumption for each potential flight path.

[00104] Referring to Figure 4A there is shown example Pseudocode for Algorithm 1 which represents a main control algorithm to determine and output the preferred flight plan for an aircraft. Flight planning concerns the problem of finding a valid flight path that minimises a user defined cost function while carrying a target zero fuel weight (ZFW).

[00105] Mathematically, a flight plan can be described by the following tuple: <CI; TOW; X; Y; Z>, where C/ is the cost index function that sets the aircraft speed, TOW is the take-off weight and <X; Y; Z> represents the path followed by the aircraft in spherical coordinates (latitude, longitude, altitude). The aircraft follows this path according to a performance model; this model is a function of both the aircraft' s state as well as external, time-dependent variables such as air temperature and wind.

[00106] Figure 4B is a flowchart representing an example method 400 of determining a preferred flight plan for an aircraft in accordance with Algorithm 1 shown in Figure 3 A. As depicted in this flowchart, the flight planning problem is decomposed, to a large extent, into three nested search algorithms: (1) path-search, (2) fuel-search and (3) speed- search, which are described in general terms below and in greater detail later in the specification.

[00107] Path search finds the lateral route and vertical profile from the departure airport 382 to the destination airport 392 that minimises a given cost function (time, fuel, distance, operating cost) for fixed values of TOW and CI. If no path exists between the departure and destination airports 382, 392 for this combination of TOW and CI, then path search will not produce a path.

[00108] Fuel search relaxes the fixed TOW in the path search algorithm and finds the path and TOW that carries a target ZFW. The CI remains fixed. To compute the ZFW, fuel search must consider the fuel requirements for reserves, contingencies (DPI, DPD and ETOPS), diversion (i.e. alternates) and fuel/endurance over destination. If the flight plan cannot carry the target ZFW, a set of business rules known collectively as 'reversion' are applied to reduce the fuel requirement. If the target ZFW cannot be carried even after reversion, fuel search will return the TOW that results in the heaviest ZFW. The DPA is also computed at this point as it impacts the business rules governing reversion.

[00109] Finally, speed search relaxes the fixed CI in fuel search. The speed search algorithm searches through a discrete set of CIs to find the speed schedule that minimises the given cost function.

[00110] At line 1 of Algorithm 1, the method 400 involves constructing 410 a graph 372 (referred to herein as an 'airmap graph') that defines the lateral routes the flight plan can take. This graph 372 represents the airway structure and a sampling of any free-flight areas according to the PRM paradigm. This airmap graph 372 also respects constraints such as ETOPS operating areas. The structure of the airmap graph 372 also accounts for airway levels, UPR directs, OTS tracks and via points.

[00111] In the loop defined by lines 2 to 13 of Algorithm 1, illustrated by the solid boxes 420 shown in Figure 4B, a flight plan is generated for each cost index.

[00112] In the loop defined by lines 3 to 10 of Algorithm 1, illustrated by the dashed box 430 shown in Figure 4B, the system 100 iteratively searches for a take-off weight that achieves a target zero-fuel weight.

[00113] At line 6 of Algorithm 1, a path search 440 is conducted to identify a feasible, minimum cost lateral route and vertical profile for a given takeoff-weight 384, cost index and takeoff-time. A PRM search graph 360 is constructed from the airmap graph 372. This search graph 360 is searched to find the preferred flight path (i.e. the main route path between the departure airport 382 and the destination airport 392 that optimises the defined cost function (e.g. fuel, time) with respect to the fuel performance model, the weather prediction data and subject to the fuel policy and defined cost index. The path is post-processed such that it respects constraints on free-flight waypoints and edges. The path is post-processed to identify opportunities for mid-segment step climbs.

[00114] At line 7 of Algorithm 1, the processing system 100 calculates 450 a number of contingency paths for the preferred flight path for depressurization (DPD), loss of an engine (DPI) and ETOPS cases. The minimum cost alternates plan is also computed. Any fuel-over-destination constraints are also applied. The Decision Point All-engines operating (DP A), referred to line 11 of Algorithm 1, can also be found in this step.

[00115] At line 8 of Algorithm 1 , a fuel search 460 is conducted to find an appropriate TOW such that the target ZFW can be carried. The fuel policy is applied to the flight path, including flight fuel, fuel reserves, contingency fuel and diversion fuel and updates the take-off weight 384 in the flight path.

[00116] At line 11 of Algorithm 1, the processing system 100 identifies 470 the Decision Point All-engines operating (DP A), being the last enroute waypoint at which the aircraft can divert to at least one nominated DPA airport without requiring additional fuel.

[00117] At line 14 of Algorithm 1, a speed search 480 is conducted in order to determine the minimum cost speed schedule. The system 100 searches amongst the flight plans generated for each cost-index and selects the preferred flight plan.

[00118] Sub-processes performed by each line of Algorithm 1 will now be explained in further detail below. Airmap Construction

[00119] Step 410 of the method 400 involves constructing an airmap graph 372 that defines the lateral routes the flight plan can take. More specifically, the airmap defines the set of lateral routes that are considered in a flight plan. Formally, the airmap is a graph composed of vertices 364 defined by latitude-longitude pairs and directed edges 374 joining these vertices. The airmap is constructed so as to obey a number of constraints applicable to the lateral route such as, for example, the following constraints:

• ETOPS operating area constraints;

• Via points;

• User preferred routing (UPR) directs;

• Organised track system (OTS) routes;

• Use of high/low/both level airways and

• Free-flight regions, including the transition via free-flight gates. [00120] Pseudocode for constructing the airmap graph 372 is shown by Algorithm 2 of Figure 5, and elements of Algorithm 2 are detailed in the following sub-sections of the specification.

[00121] In broad terms, Algorithm 2 describes the construction of a graph called the airmap 372 that defines the set of valid lateral routes that can be taken by the preferred flight plan. The airmap graph 372 is produced by compositing vertices 364 and edges 374 from a number of route types in a manner that represents the valid set of lateral routes that can be followed. The first is the published airway route structure and company directs (Line 5 of Algorithm 2). Secondly, vertices364 and edges 374 in regions where airspace users are free to define their own preferred routes (free-flight regions) are formed using the PRM paradigm. The PRM paradigm randomly samples points and adds edges that connect each point with all others in a neighbourhood (Line 6 of Algorithm 2). Third, organised track structure (OTS) routes are added (Line 7 of Algorithm 2). Fourth, approved directs that are used to enter and exit free flight regions are added (Line 8 of Algorithm 2). The contents of the airmap graph 372 is limited to a defined search region (Line 4 of Algorithm 2) and the ETOPS area of operations (Line 9 of Algorithm 2) if applicable. If the flight plan query includes via points that the flight is forced to traverse through, an airmap graph 372 is generated from the departure point 382 to the first via point, from the first via point to the second and so on to the destination point 392 (loop in Lines 3, 12 of Algorithm 2). Each of these airmap graphs 372 are stitched to the previous one (Line 10 of Algorithm 2). Finally, the airmap 372 is pruned to remove edges that are unlikely to be part of the preferred flight plan to reduce the computational expense of the search process (Line 13 of Algorithm 2). Flight Region Calculation

[00122] At line 4 of Algorithm 2, the system 100 performs a calculation of the flight region, which is necessary when constructing the airmap to constrain its geographic extents. This region limits the size of the search space and thus limits computation time. The flight region is defined by the union of:

• An ellipse with foci at the departure and arrival vertices 382, 392 of the airmap 372, with a configurable eccentricity. In still air, this ellipse bounds the distance (and thus time and fuel) required to travel from the departure airport 382 to any point in the ellipse and then onto the arrival airport 392. • Two circles of configurable radii around the departure and arrival vertices 382, 392. These circles ensure that the search space considers a range of possible routes by which one can climb out of and descend into the departure and arrival airports 382, 392 respectively.

[00123] Only waypoints, Navaids and free-flight sample points that lie within the flight region are considered when constructing the airmap 372. Edges that lie outside the flight region are removed. Airways Airmap

[00124] At line 5 of Algorithm 2, the system 100 calculates the airways portion of the airmap 372 on airways that connect the departure airport 382 and arrival airport 392. The airway structure naturally forms an airmap 372; airports, Navaids and waypoints are the airmap vertices 364 while airways and company directs are the edges 374. Company routes are a special case of the airway structure; they contain a sequence of linearly connected vertices 364.

[00125] Each airways edge 374 is associated with a level that refers to the altitudes at which one can fly along an airway: at high level, low level or both levels. The airways portion of the airmap 372 is constructed such that the route is constrained to transition from low level airways to high level airways only through both level airways. When a plan requires the use of low level airways, airmap vertices 364 corresponding to airports, waypoints, Navaids and free-flight sample waypoints are duplicated: one set represents high level routes and the other set represents low level routes. The manner in which these sets of vertices 364 are connected is illustrated in Figure 6 of the drawings.

[00126] Low level airways are only used when necessary; otherwise, only high and both level airways are used to form airmap edges 374. The use of low level airways is generally only considered necessary when there is no path in the airmap 372 connecting the departure and arrival vertices 382, 392.

[00127] Pseudocode for determining the airways portion of the airmap 372 is shown by Algorithm 3 of Figure 7. In general terms, Algorithm 3 describes the way in which the published airway route structure is encoded in the airmap 372, specifically with regards to the use of low level airways. Published airways are classed into three categories: low, high and both. Use of high and both level airways is preferred. First, an airways portion of the airmap graph 372 is constructed using only high and both level airways. If the departure point 382 and destination point 392 are connected in this graph 372, the algorithm is complete and the airmap 372 is returned (Lines 1-3 of Algorithm 3). Otherwise, low level airways within a configurable radius of the destination point 392 are added; if departure point 382 and destination point 392 are connected in this graph, the algorithm is complete and the airmap 372 is returned (Lines 4-6 of Algorithm 3). Otherwise, low level airways within a configurable radius of the departure point 382 only are added; if departure point 382 and destination point 392 are connected in this graph 372, the algorithm is complete and the airmap 372 is returned (Lines 7-9 of Algorithm 3). Otherwise, low level airways within a configurable radius of both the departure and destination points 382, 392 are added and this airmap graph 372 is returned (Lines 10-12 of Algorithm 3). Free-flight Airmap

[00128] At line 6 of Algorithm 2, the system 100 calculates the free-flight portion of the airmap 372 for free-flight that connects the departure airport 382 and arrival airport 392. In areas where free-flight is permitted, an artificial airmap 372 is constructed by sampling the region using the PRM* paradigm. In the following paragraphs, and in accordance with the PRM* paradigm, the sampling method is described together with the methodology for connecting samples. Following that, the method by which the free-flight samples are connected to the airways portion of the airmap 372 to form a mixed airmap is described in further detail.

[00129] In the PRM* paradigm, the free-flight region is sampled using a random set of points that form the vertices of the airmap 372. Also included in the set of free-flight points are the gates used to transition from airways into free-flight regions and vice versa. The edges 374 of the free-flight portion of the airmap 372 connect each vertex 364 to all other vertices 364 within a certain neighbourhood, but only if the edge 374 lies wholly in the free-flight region. Pseudocode for generating the free-flight portion of the airmap 372 is shown by Algorithm 4 of Figure 8. [00130] Algorithm 4 describes the generation of the free-flight portion of the airmap 372. First, the free-flight region is randomly sampled with points defined by set of coordinates (latitude, longitude) 364 at a defined density (Line 1 of Algorithm 4). Free- flight gates that define the transition between the airways portion of the airmap 372 and free-flight regions are also added to the set of vertices (Line 2 of Algorithm 4). For each vertex in this set, the algorithm finds neighbouring vertices within a defined radius (Line 5 of Algorithm 4) and connect the vertex pair with an edge 374 if the edge 374 is wholly contained within the free-flight region (Line 8 of Algorithm 4)

[00131] In accordance with Algorithm 4, samples that are near each other are connected. More formally, this neighbourhood is defined by a circle of specified radius, referred to as the mesh radius. While this parameter can be defined independently of the sampling density, one option is to derive this radius in accordance with the PRM* paradigm (although it should be appreciated that other approaches achieving a similar result would also be acceptable). The PRM* paradigm sets the radius as a function of the sampling density - the number of sample points per unit area - and ensures that the resulting airmap 372 is computationally tractable to search.

[00132] Formally, the PRM* radius for two-dimensional problems - as is the case here - is defined in accordance with Equation 1 below:

Equation 1 where YPRM_* is the mesh radius, is the area of the free-flight region, ζ is the area of a unit circle and n the number of samples in the free-flight region. Defining the radius in accordance with Equation 1 ensures that the average number of edges 374 connecting sample points is O (log n).

[00133] Equation 1 is difficult to compute analytically owing to the complex geometry of the free-flight regions. Instead, one preferable option is to approximate the ratio free by the ratio of sample points in the free-flight region and the number of sample points in a unit circle. This simplification reduces Equation 1 to Equation 2 below:

Equation 2 where «_unit is the number of samples in a unit circle.

[00134] The free-flight portion of the airmap 372 can then be joined with the airways portion of the airmap 372 _airways, which also contain the gates, to form a mixed airmap. This mixed airmap forces routes to transition between airways and free-flight via gates, as shown below in Equation 3 :

Equation 3 OTS Routes

[00135] At line 7 of Algorithm 2, the system 100 adds organised track structure (OTS) tracks, being a special type of route composed of an entry gate, followed by a series of direct segments or airway segments and terminates with an exit gate. Once the OTS track is entered, it must be followed until one reaches the exit gate. Further, OTS routes must be entered and exited within a validity period.

[00136] An exemplary approach to handling OTS routes is to append them to the airmap 372. Temporal constraints are handled later during path search 440. The way in which OTS routes are appended to the airmap 372 is illustrated in Figure 9 of the drawings. In this example, there is illustrated an airways portion of the airmap 910, a departure vertex 920 on the left and an arrival vertex 930 on the right. There is an OTS route composed of two directs 940 and one airway segment 950 (last red segment that overlaps with the airways portion of the airmap 372). Initially, a separate airmap is created to represent the full OTS route. As an OTS route can only be traversed through its gates, vertices corresponding to its entry and exit gates are connected to the airways portion of the airmap 372 using special directed edges. These special edges have zero traversability cost, reflecting the fact that both ends of this edge are the same vertex. These edges create a unified airmap 372 that includes the OTS route and preserves the properties of the original airways portion of the airmap 372 segments.

[00137] In most cases, a flight has to enter and exit an OTS route at the entry and exit gates respectively. However, when an OTS contains free-flight transition segments, the flight is allowed to enter or exit the OTS through these transition gates without passing through the OTS entry and/or exit gates. This is illustrated in Figure 10 of the drawings, which is an example of an OTS route with a free-flight segment (it is possible to transition between the OTS and original airmap 372 at free-flight gates in addition to the OTS gates). In each of these cases, the special edges are connected at the free-flight transition gates in addition to the original OTS gates. UPR Directs

[00138] At line 8 of Algorithm 2, the system 100 adds UPR directs. A direct is an approved route between two points (i.e. waypoint, navaid or airport) on the airway structure. A User Preferred Route (UPR) direct is a direct that can only be used as part of a route that contains a free-flight segment. A conceptual illustration of UPR directs, depicting two UPR directs connecting into a free-flight region, is shown in Figure 11 of the drawings.

[00139] An exemplary approach to UPR directs is to augment the airmap 372 such that once a flight plan enters a UPR direct, it must continue into a free-flight region via a gate. The process for incorporating UPR directs into the airmap 372 begins with the construction of a baseline airmap that does not include UPR directs. A second airmap containing only UPR directs is also constructed. The two airmaps are then "stitched" such that a route containing a UPR direct must also contain at least one free-flight edge 374. This stitching process connects free-flight gates in the UPR airmap to free-flight vertices 364in the airmap 372. Further, any node 364at the end of (one or more) UPR direct (s) that is not a gate is connected to its corresponding vertex 364 in the baseline airmap. This stitching process is illustrated in Figure 12 of the drawings and is defined formally by the Pseudocode shown in Algorithm 5 of Figure 13.

[00140] Algorithm 5 first constructs an airmap comprised solely of UPR directs (Line 1 of Algorithm 5). Each vertex 364 in this airmap is: • Connected to free-flight vertices 364 that are in its neighbourhood if the vertex 364 is a gate (Line 7 of Algorithm 5);

• Connected to incoming edges 374 on the airways portion of the airmap 372 if there are no incoming edges 374 in the UPR airmap (Line 14 of Algorithm 5); and

• Connected to outgoing edges 374 on the airways portiong of the airmap 372 if there are no outgoing edges 374 in the UPR airmap (Line 21 of Algorithm 5). ETOPS Operating Area Constraint

[00141] At line 9 of Algorithm 2, the system 100 limits the airmap 372 to flight region and operating area constraint. The ETOPS operating area constraint limits the path of a twin-engine aircraft to lie within a fixed distance of ETOPS adequate airports or within a (typically smaller) distance of airports that define the non-ETOPS area. ETOPS operating area constraints are applied on construction of the airmap 372 by limiting airmap vertices 364 to lie within the intersection of the flight region and the ETOPS operating area. Airmap edges 374 that lie outside the ETOPS operating area are also removed. Via Points

[00142] At line 2, and in the loop defined by lines 3 to 12 of Algorithm 2, the system 100 uses via points to constrain the flight plan to fly through an ordered set of two- dimensional point(s) at any altitude before arriving at the destination. This constraint is applied by constructing the airmap 372 such that the only lateral route from the departure vertex 382 to the arrival vertex 392 is through the via point(s). This approach is illustrated in Figure 14 of the drawings, and illustrates the approach to handling via point constraints. In this example, there are shown two via points. The first step is to extract three sets of airmaps: (1) from the departure vertex 382 to the first via point, (2) from the first via point to the second and (3) from the second via point to the arrival vertex 392. Zero cost edges join the three airmaps. The only route from the departure vertex 382 to the arrival vertex 392 is through these zero cost edges.

[00143] Conceptually, each subset is connected to the next only at the via points through a zero-cost edge. This zero-cost edge means that the exit node has same state as the entry node. Thus, all valid flight paths from the departure vertex 382 to the arrival vertex 392 is guaranteed to pass through these via points in the specified sequence. In practice, these zero-cost edges do not exist in the airmap 372; rather, although the edges 374 leading into the via point in the first airmap are connected to the via point in the second airmap. Airmap Pruning

[00144] At line 13 of Algorithm 2, the system 100 undertakes airmap pruning, which is the process of removing infeasible edges from the airmap 372. A heuristic is applied in which (directed) free-flight edges that are not within a configurable field-of-view of the arrival vertex are removed. An edge (w; v), is pruned if the bearing from u to the arrival vertex does not lie within the field of view angle of the bearing from u to v. Airways edges are always retained.

Path Search

[00145] Step 440 of the method 400 involves conducting a path search to identify a feasible, minimum cost lateral route and vertical profile for a given takeoff-weight 384, cost index and takeoff-time. The search can be decomposed into four main steps. In the first step, the graph-search algorithm is applied to the previously constructed airmap 372 to find a minimum cost path with respect to the airmap 372. In the second step, continuous optimisation is applied to the path to further reduce path cost. The optimised path does not necessarily obey all constraints applicable to free-flight; modifying the path to obey these constraints is the third step. The second and third steps are preferably only required when the path includes free-flight segments. In the final step, the free-flight constraints are enforced and a search conducted for opportunities to perform mid-segment step-climbs and step descents. Pseudocode for conducting the path search is shown in Algorithm 6 of Figure 15. Each component of Algorithm 6 will be further detailed in the following subsections of the specification.

[00146] In general terms, Algorithm 6 first performs graph-search, which builds a search graph that represents the full state-space of the path search problem. The construction of this search graph 360 uses the airmap 372 as a template, but expands each lower dimensional airmap vertex 364 into multiple higher-dimensional vertices 362. This search graph is then searched to produce a flight path. The graph search algorithm is detailed in Algorithm 7 discussed below. The flight path found by graph search is then smoothed using continuous optimisation (Line 6 of Algorithm 6). The airmap 372 is then updated to include this smoothed path (Line 7 of Algorithm 6). Graph search is then rerun on the updated airmap (Line 8 of Algorithm 6) iteratively until the change in path cost is below a given threshold. Free-flight waypoint constraints are applied by adjusting the path found in the previous step (Line 17 of Algorithm 6). Finally, the path is searched for opportunities to make mid-segment step climbs and descents (Line 18 of Algorithm 6).

Graph Search

[00147] The graph search component of Algorithm 6 finds a minimum cost path with respect to the airmap 372. This component of the algorithm uses the airmap 372 as a template to build a higher-dimensional graph 360. Each vertex 362 in this higher- dimensional graph 360 represents a unique aircraft state (position, altitude, weight, time, constraints and costs), and is also known as a node 362. Each edge 370 in this graph 360 represents a valid transition from one state to another, accounting for the aircraft performance model, airspace restrictions and airway closures.

[00148] In accordance with a representative embodiment, the graph search problem is decomposed into two stages: (1) forward search, which moves from the departure airport 380 towards the arrival airport 390 and (2) reverse search, which moves in the opposite direction. In this two-stage approach, the forward search builds a higher-dimensional graph that models the climb-out and cruise portions of the flight, while the reverse search builds a graph that models the descent. The rationale for such a decomposition is to reduce the complexity of searching for the top-of-descent. Otherwise, the forward search must consider all possible descent paths for all edges 370 in the airmap 372 at all cruise flight levels. Instead, the set of possible descent trajectories are pre-computed by searching in reverse, and performing a "look-up" of the appropriate descent path when needed.

[00149] However, searching in reverse presents its own set of challenges, namely that the landing weight 394 and time are not known a-priori. An exemplary approach is to assume a fixed arrival time and to execute multiple reverse searches from a discretised set of landing weights 394. Weight, but not time, are discretised as the aircraft descent profile tends to be highly weight-dependent.

[00150] The graphs generated by the forward and reverse searches are stitched, forming a graph 360 that represents the entire graph search problem. In the stitching process, the descent trajectories are re-computed to eliminate errors introduced by the discretisation of weight 394 and the assumption on a fixed landing time. The minimum cost path is found by finding the node 390 at the destination with minimum cost and following its predecessors until the departure point 380 is reached. This approach to the graph search problem is summarized in the Pseudocode shown for Algorithm 7 in Figure 16.

[00151] Algorithm 7 finds a minimum cost path with respect to the airmap 372. The algorithm is decomposed into two stages: (1) forward search (Line 1 of Algorithm 7), which moves from the departure airport 380 towards the arrival airport 390 and (2) reverse search, which moves in the opposite direction. The reverse search generates descent trajectories for a range of weights (Lines 2-4 of Algorithm 7) 394 and is stitched with the forward graph (Line 5 of Algorithm 7), generating many potential paths. The preferred path is selected from this set of paths (Lines 6-7 of Algorithm 7).

F orward S earch

[00152] The forward search component of the algorithm builds and searches a higher- dimensional graph that extends the airmap 372 to represent the entire aircraft state: i.e. position (latitude/longitude coordinates and altitude), time, gross weight and operating- cost. In this higher-dimensional graph, a vertex 362 represents an aircraft state and an edge 370 represents a valid transition from a state to another. Initially, the vertex set contains only the starting node 380, which has a fully defined state. Forward search evaluates the full state of other nodes 362 by expanding this initial node 380 forward in time according to the airmap 372 structure. The forward search algorithm is formally defined in the Pseudocode for Algorithms 8 to 11 shown in Figures 17 to 20 respectively. In general terms, Algorithms 8 - 11 describe the forward search algorithm. Algorithm 8 is the core forward graph search algorithm. Algorithm 9 describes the transition model for moving from one vertex 362 in the search graph 360 to another. Algorithm 10 describes heuristics to cull infeasible edges from the search. Algorithm 11 describes the cost function for the search.

[00153] Central to forward search is the use of a priority queue. This queue actively maintains the frontier nodes that have been visited, but are yet to be expanded during the search. The queue initially contains the starting node 380. In each iteration of the search, the least-cost node is extracted to be the source node for forward expansion. This node is then removed from the queue. The target waypoints (latitude/longitude coordinates) for this expansion are extracted from the airmap 372 based on edges leading out of the source node. Expansions from the source node towards each of its targeted waypoints are independent processes - expansion of one does not affect the expansion results of the others. Because of this property, these edge expansions can be performed in parallel. This parallel expansion is illustrated specifically at line 7 of Algorithm 8.

[00154] Each of these target waypoints is associated a list of targeted cruise altitudes 366, representing different actions the aircraft can take: cruise, step-climb, step descent or a flight level change. The state of the source node is to be propagated towards each of these actions. Note that a flight-level-change is required when edge expansion requires a change in cruise flight-levels. Examples are directional changes due to east-west bound, north-south bound or crossing into a region with a different cruise flight level table. This identification of possible actions is illustrated specifically at line 8 of Algorithm 8. These actions are also independent of each other and thus can be processed in parallel, which is illustrated specifically at line 10 of Algorithm 8.

[00155] Once the possible actions for a target waypoint have been extracted, the following step is to propagate the state from the source node towards the waypoint through these actions. This is the advance function illustrated at line 12 of Algorithm 8, and is further detailed in Algorithm 9. This function is identified as the computational bottleneck of the edge expansion process and in fact the overall forward search algorithm. In the advance function, the higher dimensional state of a source node gets propagated towards a target coordinate at a target altitude. This involves a numerical integration process that successively accumulates the fuel-burned, time-taken, distance-cruised and operating-cost through a combination of performance-table lookups and spherical geometry calculations (to account for FIRs and airspace restriction crossings). The integration process is terminated when the forward integration arrives at the target coordinate or until no solution is found due to performance limitations, airspace restriction violations or violations of the ETOPS operating area. If this integration process succeeds, the higher-dimensional target state is updated.

[00156] Reducing the total number of calls to the advance function improves the search run-time. This reduction is preferably achieved through the design of a filtering algorithm called require-advance. Greater detail of this function are shown in Algorithm 10. Given a source node, a target position and the current vertex set, this algorithm first scans to see if there exists a vertex at the target position. State propagation is required only if the target node does not appear in the vertex set or if the cost of the source node is lower compared to the cost of the existing vertex. This is because the cost value can only either increase or remain constant during forward expansion - there is no benefit in propagating towards an existing vertex that has a lower cost value than the source node.

[00157] Similarly, there is no cost-benefit in propagating from a source node back to its best parent. This check is critical to avoid the forward search becoming trapped in an infinite loop, which could otherwise occur if there existed an edge expansion of zero cost (e.g. operating-cost with solely FIR cost).

[00158] After running advance in parallel, the propagated target nodes are inserted into the graph 360 collectively. This insertion function is described specifically in lines 16-31 of Algorithm 8. Nodes 362 that are new to the graph 360 are created and inserted directly into the graph 360. Otherwise, the state of existing nodes 362 would be updated whenever the new action results in a lower cost.

[00159] Finally, the propagated target nodes are inserted into one of two sets: the graph search priority queue or the terminal set. Inserting a node into the graph search priority queue allows this node to be the basis of further expansions in the graph search. Inserting a node into the terminal set indicates that this node should no longer be expanded from. The terminal set is used as a mechanism to prune infeasible nodes in the search in order to reduce computation time. Methods for pruning the graph will be described in detail in subsequent sections of the specification. No pruning occurs if all nodes are inserted into the priority queue. Reverse Search

[00160] The reverse search component of the algorithm is identical to the forward search algorithm, except it searches backwards in time from a given arrival time and landing weight 394 and ignores temporal airspace restrictions and airway closures. The reverse search begins at the destination node 390 and is propagated until the frontier reaches the waypoint before the top of descent. If the plan is constrained to have a minimum cruise distance before top of descent, the reverse search is further propagated until each point on the frontier satisfies this constraint.

[00161] In the reverse search, temporal airspace restrictions and airway closures are ignored as the assumed landing time from which the reverse search is initiated is unlikely to be correct. If temporal airspace and airway closures were considered, this error may lead to the search rejecting potentially feasible descent trajectories. Instead, these temporal constraints are considered in the stitching process, when errors in time and weight are corrected. Stitching

[00162] The stitching step connects the graphs generated by the forward search and the reverse search. This joined graph contains multiple valid paths from the departure node 380 to the arrival node 390. The stitching process is divided into two stages: (1) standard sectors, composed of climb, cruise and descent and (2) short sectors, composed of only climb and descent for situations where the aircraft never reaches cruising altitude. Each of these stages is described in detail in the subsequent sections of the specification.

[00163] When stitching standard sectors, the algorithm identifies nodes in the forward graph at the same position and approximately the same weight as nodes in the frontier set of the reverse graph. The matching on weight is approximated as the reverse search is run on a selected set of landing weights 394. Consequently, the weights in the forward and reverse graph are unlikely to match exactly. No matching is done on time, and nodes which satisfy these criteria are referred to as 'stitch nodes' . The process for stitching standard sectors is illustrated specifically at lines 3 to 16 of Algorithm 12 shown in Figure 21 of the drawings.

[00164] Algorithms 12 - 14 (as discussed in further detail below, and depicted in the drawings at Figures 21 to 23 respectively) describe the reverse search algorithm. Algorithm 12 describes the stitching of the forward search with the reverse search. Algorithm 13 describes the process for joining the forward and reverse graphs at a single point. Algorithm 14 describes the process of determining the exact top-of-descent location for each descent path after the graphs have been stitched.

[00165] When a stitch node is identified, the descent traj ectory from the stitch node to the arrival airport 390 is recomputed to remove errors in aircraft gross weight and ETA. Further, temporal airspace restrictions and airway closures are considered in this step - if the re-computed descent trajectory traverses closed airspace or airways, the trajectory is rejected. To re-compute a descent trajectory, the forward and reverse graphs are first joined, as shown in the Pseudocode of Algorithm 13 shown in Figure 22 of the drawings. Binary search is then used to find the TOD - the TOD may be in a different position from what the reverse descent search expected due to errors in the estimated landing time, as described in the Pseudocode of Algorithm 14 shown in Figure 23 of the drawings. Algorithm 14 handles two special cases when searching for the TOD. The first case is when a TOD occurs during a step-climb. In this case, a new descent search is performed by setting the step-climb edge (and all subsequent edges) to a normal cruise edge. The second special case is when the TOD occurs during a step-descent. In this case, this redundant TOD node is removed and the start of step-descent is set as the TOD.

[00166] When stitching short sectors, the algorithm identifies points at which the forward and reverse graphs cross over in altitude on the same airmap edge 374. The forward graph represents the climb portion of the path, while the reverse graph contains the descent portion. The cross over points (peak nodes) serve as the stitch nodes. This process is detailed in lines 17 to 27 of Algorithm 12. Again, the descent trajectory is recalculated to correct errors in weight and time. Pruning the search graph

[00167] Graph search is the most computationally expensive operation in the flight planning algorithm. In order to limit the computational expense of this operation, search graph is pruned. Pruning reduces the search run time by reducing the number of edges 370 that need to be evaluated.

[00168] The motivation behind this exemplary approach to pruning is to establish and update an upper-bound on the path cost during the forward search. All nodes 362 with cost greater than this upper bound are removed. Whenever the cost of all nodes 362 in the forward search graph exceeds a cost threshold, the graph 360 is pruned. Further, the upper-bound is updated and set to the cost of the best path that has been found. Finally, the cost threshold is increased and the process repeats until all nodes 362 have either been pruned or evaluated.

[00169] This pruning algorithm is illustrated by the Pseudocode in Algorithm 15 shown in Figure 24 of the drawings. Algorithm 15 defines an admissibility heuristic to speed up the forward search algorithm. First, the forward search is run until a valid path is found, which occurs when the forward search graph meets the reverse descent search graph (Line 5 of Algorithm 15). All other frontier nodes in the forward search graph are put in the terminal set J(Line 10 of Algorithm 15). As the algorithm proceeds, the cost upper bound u will decrease as better paths are found (Line 9 of Algorithm 15). The cost threshold t is initialised to the cost of the starting node, which is typically zero. During the search, this threshold increases towards u (Line 11 of Algorithm 15). The search terminates when t > u. Selection Criteria

[00170] The various flight planning selection criteria (minimum fuel, minimum time, minimum operating cost, minimum cost within schedule and maximum ZFW) are instantiated in the search through a combination of cost functions and constraints. These cost functions are constraints are outlined in Table 1 below.

Table 1 Minimum Fuel

[00171] The minimum fuel cost function minimises the flight fuel for a given take-off weight and is defined by c_min.f_uei = w_t- w„ where w_n is the aircraft gross weight at node n 362 and w_t is the take-off weight 384. Minimum Time

[00172] The minimum time cost function minimises the flight time for a given take-off weight 384 and is defined by c_min._time = t_n where t_n is ETA at node « 362. Minimum Operating Cost and Minimum Cost within Schedule

[00173] The minimum operating cost function minimises the operating cost of a flight for a given take-off weight 384 and is defined by c_mm._{operatmg cost} = c_overfllght + c_time (t_s- 1„) where c/_uei is the fuel cost, c_overfl_ight is the accumulated over-flight cost, and c_time (-) is a function describing the time-based crew and maintenance costs. Maximum ZFW

[00174] The maximum ZFW cost function searches for a path that minimises the total fuel uplift. For a fixed take-off weight 384, this cost function will maximise the payload that can be uplifted. The total fuel uplift is composed of flight fuel - which is consumed flying from the departure airport 380 to the destination airport 390 - and reserve fuel which is not consumed. While many components of the reserve fuel are independent of the flight path, there are some components which are affected and must be considered in the search. Specifically, the components of the reserve fuel affected by the path are:

• DPD: fuel carried to ensure that the aircraft can proceed along a great circle arc to at least one of a set of airports on a fixed vertical profile. The fuel requirement is defined by the most critical equi-fuel point along the route at which the fuel needed to proceed to two DPD airports is identical.

• DP 1 : fuel carried to ensure that the aircraft can proceed along a great circle arc to at least one of a set of airports after an engine failure. The vertical profile is comprised of a driftdown in which the aircraft descends to a level-off altitude followed by a cruise and descent into the DPI airport. As with the DPD case, the fuel requirement is defined by the most critical equi-fuel point.

• ETOPS : fuel carried to ensure that the aircraft can proceed along a great circle arc to at least one of a set of airports on a fixed vertical profile when the aircraft is more than 60 minutes flying time from these airports. Two cases are considered: the de-pressurised and one-engine inoperative cases. These cases differ only in the aircraft performance model used. Unlike the DPD and DPI cases, the ETOPS fuel requirement is defined by the most critical equi-time point. [00175] These fuel components are only required when the total fuel on-board is insufficient to meet their respective fuel requirements. In some paths, the total fuel uplift can be reduced by moving the path closer to the DPD, DPI and/or ETOPS airports. Moving the path closer to these airports reduces the reserve fuel requirements and thus reduces the total fuel uplift. However, moving the path away from the minimum fuel path will naturally increase the flight fuel component of the total fuel uplift.

[00176] Unlike cost functions that can be computed directly from properties of a graph node 362, the maximum ZFW selection criterion estimates the total fuel uplift. The total fuel required at a given node in the search graph is estimated using Equation 4 below:

» ^«= m ( *** Ι*», φ* , /_rfj>} , f^)

Equation 4

[00177] In Equation 4,f„ is the total fuel required at node n, f destination is an estimate of the fuel required to travel from the node 362 to the destination airport 390,f_dpd,f_dpdl and fetops is an estimate of the fuel required to divert from the node to its least fuel DPD, DPI and ETOPS airports respectively.

[00178] The fuel quantities are estimated as follows

• Destination: the fuel required to travel from the node 362 to the destination 390 is estimated by the fuel required to travel along the great circle arc from the node 362 position to the destination at the current altitude. While it is possible for this fuel requirement to be calculated in a more representative way by using the graph search algorithm to find the minimum fuel path from the node 362 to the destination 390, such an approach would be computationally complex. Specifically, such an approach will have a time complexity ϊθ ((E + VlogV)²) where E and V are the number of edges 370 and vertices 362 in the graph 360 respectively - the complexity of the graph search algorithm itself is O (E + VlogV). In practice, the E term dominates the complexity of the search and thus the complexity will increase quadratically. Further, the descent into the destination 390 is ignored as an iterative search would otherwise be required to find the top of descent. Again, this will result in slower response times. • DPD: the DPD fuel requirement is approximated by calculating the fuel required to travel from the node 362 to the least-fuel DPD airport. The fuel required for weather holding at the DPD airport is approximated by considering the holding requirements at the ETA. The descent into the DPD airport is ignored. To reflect the fact that the DPD fuel requirement is defined by an equi-fuel point, ^ is only updated at a node 362 if the least-fuel airport is different from the least-fuel airport for the node' s parent - a change in the least fuel airport indicates that there must be an equi-fuel point along the edge 370 between the node's parent and the node 362. In this case, fd_Pd, is set to the higher of the value calculated for the node 362 and for the node's parent. Otherwise, /^, is set to the value of the node's parent.

• ETOPS: the ETOPS fuel requirement is zero when within 60 minutes flying time of an ETOPS airport. Otherwise, the fuel requirement is approximated by calculating the fuel required to travel from the node 362 to the least-fuel ETOPS airport. The fuel required for weather holding at the ETOPS airport is also accounted for. Again, the descent into the airport is ignored. The effects of icing are also ignored. Though the ETOPS fuel requirement is defined by an equi-time point, fetops is only updated at a node 362 if the least-fuel airport is different from the least-fuel airport for the node's parent and the node 362 lies in the ETOPS area. Otherwise, f_etops is set to the value of the node's parent.

• DPI : the DP 1 fuel requirement can be approximated by modelling the driftdown and cruise at the level-off altitude. The descent into the airport is ignored. The logic for updating fd_pi at a given node is similar to fd_p. The naive approach to defining the maximum ZFW cost function is to use ,. However, there is a key limitation to such an approach. When a DPD, ETOPS or DPI fuel requirement is greater than the fuel required to travel to the destination, f_n 390 can take on the same value for all nodes 362 in between equi-fuel points along the path. Thus, the path taken between equi-fuel points can be arbitrary as all options are considered equal in cost. In order to rank path options, it is necessary to include a - w„lw_t. term to fd_Pd, fd_Pdi and f_et_ops- This term, which must lie in the range [-1; 0], ranks path options by least flight fuel when , would otherwise be equal for multiple path options. 79] The ZFW cost function is expressed by Equation 5 below: Cma*-*fw - am (/««ίία, fed^™ ΐ ~ ¾ , - «½/¾¾}

Equation 5

Contingency Optimisation

[00180] The contingency optimisation obj ective function minimises the flight fuel for a given ZFW. Unlike other cost functions, contingency optimisation uses heuristics in the cost function to provide a scalar metric for the "goodness" of a path option. The use of heuristics instead of computed properties of a node has two motivations:

• Unlike other cost functions, which are with respect to a given take-off weight 384, contingency optimisation is with respect to a ZFW. However, the structure of our algorithmic approach means that the graph search is initiated from a given take-off weight 384. Heuristics are required to estimate the ZFW.

• Contingency optimisation must consider two factors: minimising the reserve fuel required (and its associated cost of carriage) and minimising flight fuel. These considerations can oppose each other in cases where moving the path towards DPD, DPI or ETOPS airports to reduce reserve fuel also moves the path away from the minimum fuel path. In this sense, the contingency optimisation problem is a bi-criterion planning problem - consider the example when there are two path options, one of which requires less flight fuel and the other requires more flight fuel but less total fuel. Heuristics are used to combine the two considerations into a scalar cost function.

[00181] Two heuristics are proposed: the penalty heuristic and the equal ZFW heuristic, which are described in further detail in the specification below.

[00182] Penalty heuristic: this heuristic is based on the minimum fuel cost function and adds a penalty term that estimates the cost of carriage of reserve fuel to the node 362 and is shown in Equation 6 below.

^::::: - - max (0^, max j ^} - f gfm&idtm }—

Equation 6 [00183] In Equation 6, the w_t - w_n term is identical to the minimum fuel cost function. In the penalty term, max(0; max (f_dpd d_pdi and/_ei0/w) -f destination) is the estimated reserve fuel. Finally, the fuel fraction w_t/w_n estimates the cost of carriage of this fuel. The key limitation of this heuristic is that the cost function value does not correspond (even in an approximate sense) to a physical value or state of the aircraft

[00184] Equal-ZFW heuristic: this heuristic estimates the node weight had the aircraft taken off at a weight such that the ZFW at the end of the flight was the target ZFW, accounting for the estimated fuel reserve. In this cost function, it is first necessary to calculate the reserve fuel in accordance with Equation 7 below: f rese ve = max (0, m {/d i* fdpl, f<& ) ^~~ fd t i& on }

Equation 7

[00185] The landing weight 394 can then be estimated by w; = w_zf_w + f_reserve where w_z fw is the target ZFW. The estimated take-off weight to achieve this ZFW is then w'_t = w[w/(w_n -/destination), which was derived using the same approximations as is used in the fuel search algorithm. Finally, the node weight given this take-off weight can be estimated as w'_t = w_nw w , again using the same approximations as the fuel search algorithm. These approximations yield the cost function shown in Equation 8 below:

Equation 8

[00186] Though the approximations from the fuel search algorithm are used to derive the equal-ZFW heuristic, these approximations are relatively inaccurate. The accuracy can be improved by performing the fuel search algorithm on the path from the departure airport to the node in question for each node 362 in the search. However, this comes at a significant computational cost. Continuous Optimisation

[00187] The continuous optimisation algorithm modifies a path (a vector of higher- dimensional vertices) towards a local optimum with respect to the cost function. In this optimisation, the variables are the latitude and longitude of the free-flight nodes. These variables are iteratively updated using the Broyden-Fletcher-Goldfarb-Shanno (BFGS) algorithm, a well-known approach for solving high-dimensional non-linear unconstrained optimisation problems with continuous variables.

[00188] In the BFGS algorithm, the solution is iteratively moved in a search direction determined by the slope (gradient) and curvature (Hessian) of the cost function with respect to the node positions. The magnitude of movement along this search direction - called the step-size - is found using a standard back-tracking line search algorithm, as will be appreciated by those skilled in the art. The back-tracking line search algorithm finds a step size that meets the Wolfe condition, which requires that the step size reduces the cost function sufficiently. The change in path cost before and after an update is monitored in each iteration and the process is terminated once no further reduction in path cost is observed. When applying the BFGS algorithm, the cost function gradient is obtained numerically using central differencing techniques (including, for example, perturbation step-size settings) while the Hessian is estimated using the standard BFGS update.

[00189] The continuous optimisation algorithm applies BFGS optimisation in two stages. In the first stage, all freeflight nodes are optimised simultaneously. That is, the optimisation variable is composed of all the free-flight nodes. The second stage optimises the free-flight nodes one at a time while holding other nodes fixed. The motivation for this two-stage approach is the presence of non-convex constraints such as restricted airspace and the need to keep free-flight nodes and legs within the free-flight region. The first stage moves free-flight nodes into the vicinity of these constraints. The second stage further refines the path by moving nodes that are far from any constraints.

[00190] The continuous optimisation algorithm applies normalisation to both optimisation variables as well as the cost function to ensure robustness across different cost functions (e.g. time, fuel). The cost function is normalised such that the value is always in the range [0; 1]. This normalisation is achieved by dividing the cost function value by the path cost before any optimisation - since the continuous optimisation algorithm minimises cost, the cost function value should always decrease. The optimisation variables are normalised by their maximum absolute values (π/2 for latitude and π for longitude) and thus always lies in the range [-1; +1]. [00191] In the continuous optimisation algorithm, the vertical profile constraints are relaxed. These constraints include constraints on step-climb/step-descent lookdown distances and the requirement to arrive at a valid cruise altitude at each waypoint. The removal of these constraints during optimisation increases the feasible space of the optimisation variables. Doing so enhances the flexibility of the algorithm to move free- flight nodes which in turn increases the likelihood of converging to a lower cost solution. It is possible to ensure that the final flight plan respects all vertical profile constraints by adding the locally-optimal 2D node coordinates found by the continuous optimisation algorithm to the airmap 372. Graph search is then re-run on this modified airmap to find a feasible solution. The continuous optimisation algorithm is formally represented by the Pseudocode for Algorithm 16 shown in Figure 25 of the drawings. In general terms, Algorithm 16 defines the instantiation of the Broyden-Fletcher-Goldfarb-Shanno (BFGS) algorithm for gradient descent optimisation on the flight plan in order to perform path smoothing. In addition, the back-tracking line search algorithm is represented by the Pseudocode for Algorithm 17 shown in Figure 26 of the drawings. Algorithm 17 defines the instantiation of a back-tracking line search algorithm used as part of the continuous optimisation (defined in Algorithm 16). Free-flight Constraints

[00192] Previous steps of the path search algorithm generated a minimum-cost path by creating a random airmap through free-flight airspace, searching for the optimal path and then performing local continuous optimisation on free-flight vertices to find the locally optimal path. However, there are additional constraints on free-flight waypoint vertices that cannot be captured by this process. In particular, the following constraints must be met:

• Free-flight waypoints must be integer latitude / longitude pairs;

• Free-flight edges may be limited by a user-specified maximum length (great circle distance);

• Free-flight edges may be limited by a user-specified minimum length (great circle distance); and

• The total number of free-flight waypoints may be limited to a user-specified maximum. [00193] A two-stage solution to modifying the path to meet these constraints is preferably adopted. The first stage takes an existing path and re-builds an airmap 372 that contains only integer free-flight vertices and only edges that meet the length constraints. The path found by applying the graph-search algorithm on this airmap 372 is guaranteed to comply with the first three criteria listed above.

[00194] The second stage is a path pruning process where vertices are successively removed from an existing path to meeting the constraint on the maximum number of waypoints. The reason for adding these constraints as post-processing steps is to allow the continuous optimisation to have sufficient flexibility to generate minimum cost paths, and then introduce these constraints to select paths that meet the free-flight constraints. This two-stage approach is represented by the Pseudocode for Algorithm 18 shown in Figure 27 of the drawings. Algorithm 18 defines a two-stage solution to modifying the path to meet free-flight waypoint constraints. The first stage takes an existing path and re-builds an airmap 372 that contains only integer free-flight vertices and only edges 374 that meet the length constraints (Lines 1-2 of Algorithm 18). The second stage is a path pruning process where vertices are successively removed from an existing path to meeting the constraint on the maximum number of waypoints (Lines 3-6 of Algorithm 18). First Stage: Integer Waypoints and Segment Length Constraints

[00195] The first stage of the approach to modifying the path simultaneously constrains free-flight waypoints to be on integer latitudes and longitudes and enforces segment length constraints. This stage accepts a path generated from an unconstrained path planner, builds a new 2D airmap 372 and re-runs the graph search algorithm. In essence, the algorithm parses the incoming path and searches for sections of free-flight. For each free-flight vertex, the algorithm creates additional vertices at the four integer latitude/longitude points that surround the original waypoint. The original (non-integer) points are removed. The algorithm then connects the first fixed vertex before a free-flight vertex to the four points created around the first free-flight vertex and from the last free- flight vertex to the first fixed vertex immediately following a free-flight vertex (as shown in Figure 28A of the drawings). Between the newly created integer free-flight vertices, edges 374 are added densely (connecting all created vertices to all other created vertices) when they meet the following constraints (as shown in Figure 28B of the drawings):

• The edge length is less than the maximum specified edge length; • The edge length is greater than the minimum specified edge length; and

• The edge is within the field-of-view of the local origin vertex, that is, the azimuth of the edge is within a fixed angular tolerance of the azimuth from the local origin vertex to the final destination vertex 392. This rule is identical to one used to prune the free-flight airmap 372 and ensures that edges 374 connect towards the goal.

[00196] The process for generating the 2D airmap 372 is formally presented in the Pseudocode for Algorithm 19 shown in Figure 29 of the drawings. Algorithm 19 takes the flight path and searches for sections of free-flight. For each free-flight vertex, the algorithm creates additional vertices at the four integer latitude/longitude points that surround the original waypoint (Line 6 of Algorithm 19). Between the newly created integer free-flight vertices, edges are added densely (connecting all created vertices to all other created vertices) when they meet the following constraints (Line 8 of Algorithm 19). The algorithm then connects the first fixed vertex before a free-flight vertex to the four points created around the first free-flight vertex and from the last free-flight vertex to the first fixed vertex immediately following a free-flight vertex (Lines 11-12 of Algorithm 19). The original (non-integer) points are removed (Lines 14-17 of Algorithm 19).

Second Stage: Maximum Number of Free-Flight Waypoints

[00197] The second stage of the approach to modifying the path requires that the total number of free-flight waypoints is less than or equal to a user-specified maximum. It is difficult to impose a vertex count limit during the graph search algorithm. Instead, a relatively straightforward approach to solving this problem is to take an existing path and determine which vertices can be removed whilst minimising the total path cost. Removing an arbitrary number of vertices is an NP-hard problem. Thus, a sub-optimal sequential removal algorithm is preferably employed. From an existing path, a free-flight vertex (connecting the previous vertex directly to the following vertex) is bypassed, the resulting path cost is evaluated, this is then repeated for all free-flight vertices, and the vertex which results in the lowest path cost is removed. This is repeated until sufficient vertices have been removed. Note that in some extreme cases this may be impossible, such as when this constraint would require a breach of the maximum path length constraint. [00198] In practice, this algorithm is implemented by constructing an airmap 372 that enumerates all valid ways in which a free-flight point can be removed from the flight plan. The graph search algorithm will naturally select the minimum cost path when run on this airmap 372. The construction of such an airmap 372 is defined by the Pseudocode for Algorithm 20 shown in Figure 30 of the drawings. Algorithm 20 limits the number of free-flight waypoints by bypassing a free-flight vertex (connecting the previous vertex directly to the following vertex) (Lines 5-7 of Algorithm 20), evaluating the resulting path cost and repeating for all free-flight vertices until sufficient vertices have been removed (Loop in lines 3, 9 of Algorithm 20). In practice, this algorithm is implemented by constructing an airmap 372 that enumerates all valid ways in which a free-flight point can be removed from the flight plan. The graph search algorithm will naturally select the minimum cost path when run on this airmap 372. Mid-segment Step Climbs and Descents

[00199] Step climbs and descents are performed to maximise performance of the aircraft or to exploit favourable weather conditions. The graph search algorithm assumes that step climbs or descents are performed immediately following a waypoint. However, this may not be the optimal climb position. The continuous optimisation has some flexibility to move waypoints and hence optimise climb position, but this is limited to free-flight nodes and to within other constraints on the vertex locations. To overcome these limitations, a post-processing stage to identify improved step climb/descent positions in the middle of existing segments is preferably proposed. Whilst it may be possible to include mid-segment climb during the graph search, step climb/descent evaluations can be very computationally expensive, and increasing the number of these evaluations performed during the search could be prohibitively expensive. Thus, the goal of this stage is to determine the improved mid-segment step climb positions for an existing path. This method does not move any of the existing waypoints but attempts to find improved positions for step climbs along existing segments.

[00200] It is possible to have multiple local and global optima in a segment. Thus, creating a finite discrete set of possible climb positions along a segment, evaluating these discrete options and selecting the lowest cost candidate is the preferred approach.

[00201] Given a certain discretisation of a single segment, an efficient graph connection structure that evaluates performing a step climb at each discrete climb location and then cruising at a constant altitude for the rest of the segment is a preferred approach. This system does not allow multiple climb or descents in a single segment. To create the new edges for a particular segment, the segment origin vertex is connected to each of the discrete points along the great circle path of the segment. Each point is then connected to the segment destination vertex. The resulting graph is searched using the existing search routine to find the optimal path which meets airspace and other constraints. An outline of the method is provided in the Pseudocode for Algorithm 21 shown in Figure 31 of the drawings.

[00202] Algorithm 21 searches for mid-segment step climb and descent points. To create the new edges for a particular segment, the segment origin vertex is connected to each of the discrete points along the great circle path of the segment (Lines 7-9 of Algorithm 21). Each point is then connected to the segment destination vertex (Line 6 of Algorithm 21). The resulting graph 372 is searched using the existing search routine to find the optimal path which meets airspace and other constraints (Lines 11-12 of Algorithm 21). DPD/DP1/ETOPS

[00203] Step 450 of the method 400 involves calculating a number of contingency paths for the preferred flight path for depressurization (DPD), loss of an engine (DP 1 ) and ETOPS cases. Three additional considerations in the flight planning problem are DPD, DPI and ETOPS contingencies. These contingencies are similar in the sense that their impact on the flight plan is the need to carry contingency fuel such that the aircraft is able to divert from a critical point to a diversion airport chosen amongst a set of nominated airports. The critical point is the highest-cost (i.e. worst case) equi-cost point; an equi-cost point is a point along the planned path where the cost of diverting to the "closest" two airports (in cost-space) is equal.

[00204] The key differences between DPD, DPI and ETOPS lie in the profile followed by the aircraft from the critical point to the diversion airport, the cost function used to calculate the critical point and the portion of the planned path where the critical point can lie. Specifically, the differences are as follows: • Profile: the exemplary approach described herein does not make strong assumptions on the profile followed by the aircraft from the critical point to the diversion airport, simply that one can evaluate the fuel and time required to divert from any point to any diversion airport. Thus, the same algorithm can be applied though each contingency case follows a different profile;

• Cost function: DPD and DPI critical points are equi-fuel points while ETOPS critical points are equitime points; and

• Path portion: DPD and DPI critical points can lie at any point between the top of climb and top of descent. ETOPS critical points can only lie between an ETOPS entry point (EEP) and an ETOPS exit point (EXP). There may be multiple pairs of EEPs and EXPs along a path.

[00205] Algorithm 22 (shown by the Pseudocode in Figure 32) is used to identify equi-fuel and equi-time points for calculation of DPI, DPD and ETOPS CPE points. The algorithm linearly finds the least cost diversion airport for each waypoint along the flight path (Loop in Lines 4, 17 of Algorithm 22). The exemplary approach described herein is directed to linearly finding the least cost diversion airport for each waypoint along the planned path. If the least cost diversion airport changes from one waypoint to another, then an equi-cost point must lie between the two waypoints a ' and a* (Lines 7-15 of Algorithm 22). Binary search is then applied to find the equi-cost point e (Line 8 of Algorithm 22). Further, it is ensured that the lowest cost diversion airport from this equi- cost point is not a third diversion airport; if this is the case, the approach recursively applies the binary search again between the equi-cost point e and each of a ' and a* (Line 11 of Algorithm 22). Optionally, the approach requires a linear search along the entire path at a user-defined sampling interval (for example, five minutes), calculating the fuel required to divert to the lowest cost diversion airport. If a diversion requiring more fuel than the most critical equi-cost point is found, the contingency fuel calculations will use this diversion instead of the most critical equi-cost point (Lines 19-24 of Algorithm 22). This approach is summarised in the Pseudocode for Algorithms 22 and 23 shown in Figures 32 and 33 respectively. Algorithm 23 is an auxiliary algorithm that supports this search. Alternates [00206] The alternate flight plan is a separate flight plan that departs from the alternate commencement point and arrives at one of the nominated alternate airports. The alternate commencement point is user-configurable to be either be the top of descent or 1500' above the arrival airport. Only the airmap 372 construction and path search algorithms is required for this flight plan as the TOW, ETD and CI are fixed:

• TOW is the aircraft gross weight at the alternate commencement point;

• ETD is time of arrival at the alternates commencement point; and

• CI is the cost index used for the main plan.

[00207] The algorithm for computing the alternate flight plan is represented in the Pseudocode for Algorithm 24 shown in Figure 34 of the drawings. Algorithm 24 defines the search for alternates performed by the processing system 100. Full alternates are described in this algorithm. The TOD alternate case is implemented similarly to the method described above in relation to the destination location, wherein the start of the alternate flight path begins at the TOD node rather than the destination location 392. DPA

[00208] Step 470 of the method 400 involves identifying the Decision Point All- engines operating (DPA), being the last enroute waypoint at which the aircraft can divert to at least one nominated DPA airport without requiring additional fuel The DPA is the last enroute waypoint at which the aircraft can divert to at least one nominated DPA airport without requiring additional fuel . The search for the DPA begins at the last enroute waypoint and progresses in reverse towards the departure airport. At each waypoint, a plan to each of the DPA airports is generated. The DPA point is the first waypoint at which a feasible DPA flight plan can be found. A DPA flight plan is considered feasible if:

• The landing weight 394 at the DPA airport is less than the maximum landing weight; and

• The DPA flight plan carries the planned zero fuel weight while complying with the defined fuel policy. [00209] An exemplary approach to finding the DPA is outlined in the Pseudocode for Algorithm 25 shown in Figure 35 of the drawings. Algorithm 25 defines the search for the decision point all-engines operating.

[00210] In particular embodiments, after identifying the potential flight paths and prior to selecting one of the potential flight paths according to the objective function, the processing system 100, connects a plurality of DPA (Designated Point All engines operating) nodes to the PRM search graph 360 for each potential flight path. The processing system 100 then searches the PRM search graph 360 to identify a DPA flight path to one of the DPA nodes from one of the PRM nodes for each potential flight path, wherein the processing system 100 calculates a fuel consumption for travelling along the DPA flight path which forms part of the respective contingency fuel consumption. Fuel Search

[00211] Step 460 of the method 400 involves conducting a fuel search in order to find an appropriate TOW 384 such that the target ZFW can be carried. The path search 440 algorithm searches from a given take-off time and take-off weight (TOW) 384. However, in the flight planning problem, the zero-fuel weight (ZFW) is often a more important variable as it determines the amount of payload that can be carried. Thus, it is necessary to find an appropriate TOW 384 such that the target ZFW can be carried. In this section, the algorithmic approach to finding a TOW384 that achieves the target ZFW will first be described, followed by a description of the fuel policy implementation that is used to compute the ZFW from a given TOW 384. Finally, the algorithm for fuel tankering will be described. Approach

[00212] An exemplary approach to the fuel search problem begins with estimating the TOW 384 required to cany the target ZFW. This TOW 384 estimate is set to the MTOW. Path search 440 is run at this TOW 384 to produce a path. The flight fuel, fuel reserves, contingency fuel and diversion fuel required by the fuel policy are subtracted from the TOW 384 to derive the achieved ZFW. The TOW estimate is then adjusted, and the process repeats until the achieved ZFW is sufficiently close to the target ZFW.

[00213] The TOW estimate is adjusted by approximating the flight fuel requirement by the Breuget fuel-range equation. The Breuget fuel-range predicts an aircraft' s still-air range given its airspeed, fuel-fraction and basic aircraft performance characteristics, as shown in Equation 9 below:

Equation 9

[00214] Here, R is the aircraft still air range, Fits velocity, u its TOW 384, v its ZFW, I_sp its engine specific impulse and L/D its lift-to drag ratio. w_r is the sum of the reserve, contingency and diversion fuel requirements, which is approximated as being weight independent. Further, the still air range and aircraft performance characteristics (velocity, engine specific impulse and lift-to-drag ratio) are approximated as being constant for each iteration of fuel search. Under these approximations, it is possible to derive a constant c = R/VI_sp (L/D) such that:

Equation 10

[00215] In order to apply Equation 10 (shown above) to the flight planning problem, it is also necessary to consider two aircraft weight limits: (1) the maximum landing weight w_mtgw and (2) the tank capacity w_cap. The landing weight constraint can be trivially applied by limiting the value of v + w_r to M- ^. The tank capacity constraint is applied by solving Equation 9 for the case where u - v = w_tcap - w_r:

« .... ^; ; —

exp'-— .i

Equation 11

[00216] By considering the analytic fuel burn model and weight constraints in each fuel search update, it is observed empirically that fuel search converges in fewer iterations that other approaches (binary search, gradient descent), thus reducing system response time. The fuel search algorithm is formally defined in the Pseudocode for Algorithm 26 shown in Figure 36 of the drawings. Fuel Tankering [00217] Fuel tankering is a business policy in which aircraft flying from airports where fuel is cheap to airports where fuel is expensive carry additional fuel to offset the price of purchasing fuel at the destination. An exemplary approach to tankering is to establish a baseline plan without tankering. A plan with tankering is compared against this baseline and the minimum cost plan selected (accounting for the fuel price differential at the destination and departure airports 382, 392). This plan with tankering is subject to a number of constraints:

• It uses the same lateral route as the baseline plan. This constraint is to limit the system performance impact of the tankering algorithm, and can be removed in situations where system performance is less important.

• The maximum landing weight is limited to a user defined buffer below the aircraft maximum landing weight.

[00218] An exemplary approach to fuel tankering is outlined in the Pseudocode for Algorithm 27 shown in Figure 37 of the drawings. Algorithm 27 defines the algorithm for revising a preferred flight plan to add tankering fuel. Speed Search

[00219] Step 480 of the method 400 involves conducting a speed search in order to determine the minimum cost speed schedule. The speed search determines the minimum cost speed schedule, expressed as a cost index value for the aircraft flight management computer. The speed search algorithm runs a flight plan at a discrete set of cost indices, and selects the one with minimum cost. If there are two or more CIs that result in the same performance with respect to the nominated cost function, the highest CI will be chosen. If one or more CIs result in reversion, speed search will protect payload at the expense of the cost function by rejecting the CIs that cannot carry the target ZFW. If no CI carries the target ZFW, the speed search algorithm will select the CI that results in the heaviest ZFW.

Second Example Overview

[00220] Referring to Figure 38, and again to the method 300 shown in Figure 3A of the drawings, there is shown example Pseudocode for Algorithm 28 which represents an alternative main control algorithm to determine and output the preferred flight plan for an aircraft.

[00221] At line 1 of Algorithm 28, a number of inputs are obtained by the processing system 100 including an airways graph G, fuel performance model F, fuel policy FP, weather prediction WP, departure airport A_dept, destination airport _^4^, diversion airports A_other, and cost function C. These inputs can be obtained from memory 104 of the processing system 100 or another memory device and/or input by the user.

[00222] At line 2 of Algorithm 28, the PRM search graph 360 is constructed according to the spatial constraints of the input query type.

[00223] At line 3 of Algorithm 28, a search is performed by the processing system 100 in relation to the PRM search graph 360 to determine the preferred flight path (i.e. the main route path) between the departure airport 382 and the destination airport 392 that optimises the cost function C with respect to the fuel performance model F, the weather prediction data WP and subject to the fuel policy FP.

[00224] At line 4 of Algorithm 28, the processing system 100 calculates a number of contingency paths for the preferred flight path for the diversion airports A_other.

[00225] At line 5 of Algorithm 28, the processing system 100 checks for terrain avoidance and fuel freeze for the preferred flight path.

[00226] At line 6 of Algorithm 28, the processing system 100 outputs the preferred flight plan based on the preferred flight path. In particular, the preferred flight plan can include the preferred flight path and the take-off weight of the aircraft at the corresponding departure node. Preferably, the flight plan can additionally include at least one of the landing weight of the aircraft, the one or more contingency flight paths, the one or more alternate airports used for the one or more contingency flight paths, contingency points along the flight path, total fuel consumption and a portioned fuel consumption for the main route and the one or more contingency paths (i.e. flight buckets). Other data may also be output as part of the preferred flight plan. [00227] Sub-processes performed by each line of Algorithm 28 will now be explained in further detail below. PRM Structure and Construction

[00228] The PRM graph construction is instantiated at Line 2 of Algorithm 28 as shown in Figure 38. A probabilistic roadmap (PRM) approach is adopted by the processing system 100. PRM is a multi-query approach, where the graph structure is constructed as a pre-processing step before any queries are selected by the user. To perform a query, the given start and end points 382, 392 are connected to the graph 360 and then graph search is used to find a path. In this way, a portion of the computational effort is re-used during each query.

[00229] PRM is a sampling-based approach designed for planning in continuous high- dimensional state space. The choice of PRM is motivated by the freeflight query type, where lateral position is considered in the continuous domain. This configuration exploits the advantage of the sampling-based approach in the X, Y (latitude, longitude) dimensions, and the remaining state variables are computed during the search which is generally referred to as "lazy evaluation". The selected preferred flight path can be smoothed by the processing system 100 using continuous optimisation, wherein the optimised preferred flight path is output as part of the preferred flight plan.

[00230] The other three query types fit within this PRM framework as special cases where the sampling is determined by reference to the airway structure (Airways, Fixed track) stored in memory 104, or a given ground distance (Fixed range) which is input by the user. Path smoothing is not necessary in these cases due to the spatial constraints associated with these query types. State Space

[00231] The PRM search graph 360 is represented as G = (V, E), where Fis a vector of PRM nodes 362 and E is a vector of PRM edges 370. The PRM search graph 360 is stored in memory 104 of the processing system 100. PRM nodes 362 of F are labelled with a latitude and longitude pair 364 and altitude 366, and then later with a gross weight in a lazy manner using lazy evaluation at the time the search visits the respective PRM node 362. An equivalent view is that J⁷ represents values < X, Y, Z, GW>, where spatial variables (Xand Y) are defined according to the query type, altitude variable Z is defined by a finite set of discrete available altitudes stored in memory 104 of the processing system 100, and gross weight GW is a continuous value computed by the processing system 100 during the search process. The PRM edges 370 of E includes cruise and step climb edges that obey the spatial constraints specified in the query type. Cruise edges connect PRM nodes 362 of equal altitude 366 and step climb edges connect PRM nodes 362 of unequal altitude. During the search, PRM edges 370 are labelled with a scalar cost value that represent fuel burn incurred whilst travelling between the endpoints represented by the respective PRM nodes 362 and also based on the calculated gross weight of the aircraft. During the search, PRM edges 370 of E which are fuel feasible are only considered in the sense that the aircraft can travel between the respective PRM nodes 362 without violating physical constraints. For example, physical constraints restrict the available altitude range and gross weight range. Climb and descent edges 386, 396 are not added to the PRM search graph 360 during the construction phase as these are computed at query time.

[00232] Pseudocode for constructing the PRM search graph 360 is shown by Algorithm 29 of Figure 39. In particular, lines 1 to 4 generate a plurality of PRM nodes (i.e. vertexes as expressed in the pseudocode) 362 in vector V for all latitude and longitude pairs 364 defined by the query type together with all altitude values 366 defined by the discretised altitude set stored in memory 104. Lines 7 to 11 then generate and store in vector £ all valid PRM edges 370 according to the query type between PRM nodes 362 in V. Vector £ of the PRM search graph 360 includes all valid climb and cruise edges 386, 396. Fuel Burn Calculation

[00233] The fuel consumption data F can be represented in tabular form and stored in memory 104 of the processing system 100. The table lists instantaneous fuel burn rate by altitude, temperature, gross weight, and mach number. Mach number can be computed according to a fixed cost index and is also represented in tabular form. Rates are interpolated by the processing system 100 from tabular values using linear interpolation. Mach numbers are interpolated similarly by the processing system 100. Due to the fuel consumption data F being at least partially dependent upon the temperature which is partially dependent upon the weather prediction data WP, the fuel consumption data F is at least partially dependent upon the weather prediction data.

[00234] Fuel burn is computed by the processing system 100 via numerical integration over time. This accounts for decreasing rate of fuel burn as the aircraft consumes fuel (and gross weight decreases) during the flight. Temperature is computed by the processing system 100 from weather prediction data. Wind correction is included during integration as a correction to ground distance. Weather Data Structures

[00235] Weather model JF is represented in grid form provided in standard GRIB2 format and stored in memory 104 of the processing system 100 or an accessible data store. Tri -linear interpolation is used by the processing system 100 to compute wind direction and magnitude at a given point in space. Temperature is interpolated similarly by the processing system 100. Plan Search and Fuel Policy

[00236] Following the PRM construction, at line 3 of Algorithm 28, the departure airport Ad_ept and the destination airport Ad_est 382, 392 are attached to the PRM search graph 360 by the processing system 100 and then a search of the graph 360 is performed by the processing system 100. The departure airport 364 is attached by connecting it through a sequence of PRM nodes (i.e. vertices) 362 to all reachable PRM nodes 362. In contrast to the PRM edges 370, these connecting edges 386 are climb edges where endpoints increase in altitude. Thus, the second endpoint of a climb edge 386 has a higher altitude than its first endpoint. State labels and edges labels are of the same form as the PRM nodes 362. The destination airport 392 is connected in similar fashion, although edges 396 represent descent as opposed to climb. Edge costs are computed from fuel consumption data stored in memory 104 of the processing system 100.

[00237] Pseudocode for this process is listed as Algorithm 30 which is provided in Figure 33. Lines 2 to 4 generate a plurality of departure or destination nodes 380, 390 for a known longitude, latitude and altitude for the respective location, wherein each node 380, 390 varies according to a weight value 384, 394 from the discretised weight set. The weight 384 that is associated with each respective departure node 380 is a unique take-off weight. Similarly, the weight 394 that is associated with each respective destination node 390 is a unique landing weight. For each new departure or destination node 380, 390, lines 6 and 7 are performed. In particular, in the event that Algorithm 30 is being performed in relation to a departure node 380, lines 6 and 7 of Algorithm 30 ensure that climb edges 386 connect the respective departure node 380 to all reachable PRM nodes 362 in the PRM search graph 360. The algorithm for connecting the destination airport is the reverse process, except descent edges 396 are connected from each destination airport node 390 back into the PRM search graph 360. Each climb and decent edge 386, 396 includes a cost value which is calculated by the processing system 100 using the fuel consumption data. Path Search

[00238] Due to the manner which the destination and departure nodes 380, 390 are connected to the PRM search graph 360, forward and backwards searches can be performed by the processing system 100 in relation to the PRM search graph 360. Backwards search begins at the destination location 392 and searches backwards in time. Forwards search begins at the departure 382 and searches forwards in time. The relevance of the connection process is in relation to how the set of gross weights GW are defined. In backwards search, a single gross weight 394 is used at the destination node 390, and the full set of gross weights over the range of the set are used at the departure nodes 380. In forwards search, a single weight 384 is used at the departure 382 and the full set of weights 394 are used at the destination 392.

[00239] For finding a path from the departure location 382 to destination location 392 (also known as the main route), backwards search is used. In particular, after the departure and destination nodes 380, 390 are connected to the PRM search graph 360, the processing system 100 computes single-destination shortest paths with respect to fuel burn using dynamic programming. Note that because a single gross weight is connected to a destination node 390, the result of this operation is a path from one valid take-off weight 394 to the given landing weight 384. The gross weight value of each PRM node 362 is initially empty, but can be calculated by the processing system 100 using the fuel consumption data during the search in the event that the search traverses to the respective PRM node 362. When the search traverses to a particular PRM node 362, the gross weight of the aircraft is determined by subtracting the estimated fuel burned from the gross weight of the previously traversed node 362 in the PRM search graph 360.

[00240] Pseudocode for the search process is listed as Algorithm 31 which is shown in Figure 34. The algorithm converges at line 6 when no updates are performed in the inner loop starting at line 7. The update test in line 10 is implemented by comparing the new value of q' with the current value, if one exists. If the new value is lower, the update is performed. Values q represent the cost-to-go in terms of fuel burn. Algorithm 31 is guaranteed to complete in polynomial time (in the size of J⁷ plus the size of £), although in practice it typically completes in linear time due to the update structure that computes updates backwards from the goal.

[00241] It will be appreciated that forward search is performed in the reverse manner to that of backwards search. Fuel Search

[00242] To choose the best path according to the obj ective function, the path search is performed by the processing system 100 for a range of landing weights 394, starting from a suitably large value such as maximum take-off weight 394 and proceeding in small increments until the processing system 100 reaches a suitably small landing weight value 394 (e.g. operational empty weight). Prior to each search, the gross-weight values of the PRM nodes 362 are re-initialised by the processing system 100 in PRM search graph 360 since these values are determined during the search itself. For each potential path found, the processing system 100 applies the fuel policy FP to derive the zero-fuel weight. If the objective is to maximise zero fuel weight, the processing system 100 returns the maximal path along with fuel policy values (also known as fuel buckets). Alternates

[00243] When required by business rules and government regulations, the main route path can be augmented with paths to alternate locations (e.g. diversion locations such as alternate airports). There are two cases considered: 1) Full alternate, where the alternate path originates from Ad_est and 2) TOD (top of decline) alternate, where the alternate path originates from a TOD (top of decline) node of the flight path. [00244] In one form, the processing system 100 can be configured to connect a plurality of diversion nodes for diversion locations to the PRM search graph 360 for varying weights, wherein each potential flight path identified includes a diversion flight path to one of the diversion nodes from the respective destination node or a top of decline (TOD) node. The processing system 100 calculates a fuel consumption for travelling along the diversion flight path which is at least part of the respective contingency fuel consumption.

[00245] More specifically, given a set of alternate airports, the processing system 100 computes a set of paths from either TOD or the main route destination. The processing system 100 re-uses some of the algorithms for finding main route paths, but this time uses forward search. First, an alternate airport is connected by the processing system 100 to the PRM search graph 360. Then, the landing weight at the main route destination (or TOD) is used to connect to the PRM search graph 360. A single source shortest path is then computed by the processing system 100 from the main route destination (or TOD) to the alternate airport using the forward search version of Algorithm 31. During the fuel search over landing weights, the complete path from departure location to the destination location and then to alternate location is considered when the processing system 100 selects the preferred flight path according to the objective function. Such a path is computed for each alternate airport independently.

[00246] This augmentation process performed by the processing system 100 is listed as Algorithm 32 provided in Figure 35. Full alternates are described in this algorithm. The TOD alternate case is implemented similarly to the method described above in relation to the destination location, wherein the start of the alternate flight path begins at the TOD node rather than the destination location 392. DPA (Designated Point All Engines Operating)

[00247] When required by business rules and government regulations, the processing system 100 augments the main route path with paths to DPA airports, where the alternate path originates from some point along the main route. In this case, the main route path is not affected. Therefore, DPA computations are treated as a post-processing step by the processing system 100. [00248] In particular embodiments, after identifying the potential flight paths and prior to selecting one of the potential flight paths according to the objective function, the processing system 100, connects a plurality of DP A (Designated Point All engines operating) nodes to the PRM search graph 360 for each potential flight path. The processing system 100 then searches the PRM search graph 360 to identify a DP A flight path to one of the DPA nodes from one of the PRM nodes for each potential flight path, wherein the processing system 100 calculates a fuel consumption for travelling along the DPA flight path which forms part of the respective contingency fuel consumption.

[00249] More specifically, given a set of potential DPA airports as provided as input at Line 1 of Algorithm 28 as A_oiAer, the processing system 100 re-uses the method that computes main route paths, but this time forward search is performed to find a set of paths from waypoints along the main route to each DPA airport. In the free flight case, waypoints are defined at minimum intervals along the freeflight path - this minimum interval is defined in government regulations. For each DPA airport, the DPA point is chosen as the fuel feasible waypoint closest to the main destination. This point must be feasible according to the processing system 100 with respect to the fuel policy FP. Example pseudocode for this algorithm is listed as Algorithm 33 as shown in Figure 36. DPD (Designated Point Depressurised) and ETOPS (Extended Twin Operations)

[00250] Two further extensions include DPD and ETOPS. Both of these can affect the choice of the main route path. The processing system 100 is configured to implement DPD and ETOPS calculations during main route computation.

[00251] In particular, each identified potential flight path can include an equi-fuel flight path from an equi-fuel point along the respective potential flight path which consumes the same amount of fuel to travel to a pair of the diversion locations. The processing system 100 is configured to calculate a fuel consumption for travelling from the equi-fuel point to one of the diversion locations which is part of the contingency fuel consumption for the respective flight path..

[00252] The objective of the DPD algorithm is to find the most fuel critical point along the main route that is equi-fuel with respect to a pair of alternate airports. The DPD airports are referred to as A' , where i is an arbitrary index. Point p is equi-fuel with respect to {A_d ^l _pd , A_dpd } if the fuel required along the great circle path from p to A_d ^l _pd is equal to the fuel required from p to A² _dpd. The path is constrained to a low altitude determined by aircraft type. Therefore, these great circle paths require more fuel than a path at normal cruise altitudes.

[00253] It is assumed that the most fuel critical point is the equi-fuel point closest to the destination. The rationale for this assumption is that other equi-fuel points will have more fuel available (since less fuel has been consumed). Therefore, the problem is formulated in terms of a Voronoi diagram, with the distance metric defined by fuel consumption. The DPD point is the last point along the main route where a main route segment crosses a Voronoi edge.

[00254] It is not necessary for the processing system 100 to compute the full Voronoi diagram to solve this problem. Rather, the processing system 100 need only be configured to test for Voronoi edge intersection, It is convenient for the processing system 100 to implement this test during dynamic programming. Because the process updates backwards from the destination 392, intersection tests are performed until an intersection is found. This process is listed as Algorithm 34 provided in Figure 37. Line 3 is implemented by comparing fuel burn requirements.

[00255] The objective of ETOPS is also to find critical points, but in this case the criterion is equi-time. However, because the plan must consider forecast winds, the processing system 100 is configured to compute the full great-circle path in order to derive the time-cost. ETOPS plans assume a fixed velocity, so this is actually equivalent to the equi-fuel requirement.

[00256] The other challenge in computing ETOPS is that all path segments must lie within a fixed radius of at least one ETOPS airport A_e'_t , and the processing system 100 must also compute the portion of the main route path that lies outside a fixed distance from A_dept and A_dest.

[00257] In particular embodiments, each identified potential flight path can include an equi-time flight path from an equi-time point along the respective potential flight path which requires the same travel time to a pair of the diversion locations. The processing system 100 is configured to calculate a fuel consumption for travelling along the equi- time flight path which is at least part of the respective contingency fuel consumption.

[00258] This process is similar to Algorithm 34, and is listed as Algorithm 35 provided at Figure 38. The main difference is that the processing system 100 tracks all equi-time points and returns the maximum. Fuel Policy

[00259] The fuel policy FP defines fuel requirements for many different conditions and is stored in memory 104 of the processing system 100. Given a path, FP returns the total fuel requirement divided into a number of fuel buckets. These buckets are computed by the processing system 100 using logical rules.

[00260] Fuel buckets are used in two cases. First, FP is applied by the processing system 100 during DP A, alternates, DPD, and ETOPS computations to determine the total fuel requirement of a contingency path. Second, application of the FP by the processing system 100 returns the total fuel requirement of a flight considering all fuel buckets.

[00261] The FP fits naturally into the flight planning framework described herein. The PRM considers gross weight, which is the total weight of the aircraft including fuel. By subtracting the fuel requirement defined by FP, the processing system 100 can derive the zero-fuel weight. Thus the processing system 100 can search all take-off weights 394 to choose a main route path that maximises the desired cost function, whether this is zero- fuel weight, total fuel consumption, time, or some weighted combination. Terrain avoidance and fuel freeze

[00262] As shown in line 5 of Algorithm 28 (see Figure 38), the processing system 100 may compute whether one or more of the flight paths can be excluded due to a potential collision with terrain or may experience temperatures causing fuel freeze.

[00263] Terrain data may be used by the processing system 100 to determine that the preferred flight path does not collide with terrain, wherein in the event that a collision is detected, the preferred flight path discarded by the processing system 100 and the next cost minimised potential flight path is selected according to the objective function as the preferred flight path. The terrain data may be stored in memory 104 of the processing system 100 or alternatively may be accessed from another source.

[00264] Additionally, as discussed earlier, temperature can be computed by the processing system 100 from weather prediction data. The processing system 100 can compare the temperature along the preferred flight path against a fuel freeze threshold stored in memory 104, wherein in the event that a fuel freeze condition is identified (i.e. the computed temperature is less than the fuel freeze threshold), the preferred flight path is discarded and the next cost minimised potential flight path is selected according to the objective function as being the preferred flight path. Third example overview

[00265] Referring to Figures 46 A and 46B there is shown a flow chart representing another example method 1200 performed by the processing system 100 for determining a preferred flight plan for an aircraft. The method of Figure 46A will be described below in conjunction with Figure 3B which represents a data structure used in method 300.

[00266] In particular, at step 1210 the method 1200 includes the processing system 100 constructing the PRM search graph 360. The PRM search graph 360 includes a plurality of PRM nodes 362 and a plurality of PRM edges 370. Each PRM node 362 includes a randomly sampled latitude and longitude pair 364 of a flight space, a weight 1268 from a weight set, and an altitude 366 from an altitude set. This contrasts to the method 300 of Figure 3 A where the weight for traversed PRM nodes 362 during the search are calculated using lazy evaluation. Each PRM edge 370 extends between two PRM nodes 362 and includes a cost based on fuel consumption data. It should also be appreciated that unlike method 300, the PRM edges of the current method include a cost at the time of construction due to the weight value 1268 being assigned to the PRM nodes 362.

[00267] At step 1220, the method 1200 includes the processing system 100 connecting, to the PRM search graph 360, departure nodes and destination nodes 380, 390 for a departure and destination location 382, 392 for various take-off and landing weights 380, 394 respectively thereby generating climb and descent edges 386, 396 connecting the departure and destination nodes 380, 390 to reachable PRM nodes 362. Each climb and descent edge 386, 396 includes a cost based on the fuel consumption data.

[00268] At step 1230, the method 1200 includes the processing system 100 searching the PRM search graph 360 to identify, for each landing weight 394, a cost minimised potential flight path between the departure location 382 and the destination location 392 via a portion of the climb, PRM and descent edges 386, 370, 396.

[00269] At step 1240, the method 1200 includes the processing system 100 selecting one of the potential flight paths as the preferred flight path using the objective function.

[00270] At step 1250, the method includes the processing system 100 outputting the preferred flight plan based on the preferred flight path.

[00271] It will be appreciated that processing system 100 can be provided which is configured by a computer readable medium having executable instructions stored thereon or therein to perform the above method 1200. Additionally, a computer program can be provided which includes executable instructions which when executed by the processing system 100 performs the above method 1200.

[00272] It will be appreciated that Algorithm 28 can still be utilised for performing method 1200, but modification to some of the sub-processes performed by other algorithms is required as explained below.

[00273] Referring to Figure 47 there is shown example pseudocode listed as Algorithm 36 for constructing the PRM search graph 360. Whilst there is some commonality with Algorithm 29 (see Figure 39), a number of differences for the current method are due to the additional weight values 1268 assigned from a discretized weight set for each PRM node 362. In particular, at step at line 4 each vertex (i.e. PRM node 362) is assigned a gross weight value 1268. Effectively, all combinations of the latitude/longitude pair 364, the altitude 366 and the gross weight 1268 are defined as the PRM nodes 362 of the PRM search graph 360. Additionally, at line 12 each new edge 370 that is added to the vector E is assigned a cost which is determined by the processing system 100 using the fuel consumption data ⁷. [00274] The connection of the departure and destination locations 382, 392 to the PRM search graph 360 is performed using Algorithm 30 as discussed above in relation to the previous example.

[00275] Referring to Figure 48 there is shown example pseudocode listed as Algorithm 37 for searching the PRM search graph 360. Algorithm 37 operates similarly to that of Algorithm 31 except this process does not require the calculation of the cost of each edge 370 as this has been performed at construction in Algorithm 36. The processing system 100 can be configured to choose the best path, wherein the processing system 100 considers each take-off weight 384 and applies the fuel policy FP to derive the zero-fuel weight. If the objective is to maximise zero fuel weight, the processing system 100 returns the maximal path along with fuel policy values.

[00276] Contingency paths can also be calculated for this process although the contingency paths for alternate airports are calculated differently to that discussed above.

[00277] In particular, example pseudocode for the processing system 100 to compute the alternate paths is provided at Figure 49 and listed as Algorithm 38. The initial part of the process is similar to that of Algorithm 32. However, once an alternate airport is connected to the PRM search graph 360, the set of main route paths are matched to the set of alternate paths by linking landing weight 394 (or weight at TOD) to take-off weight 380 (or again, weight at TOD). The final path choice is determined considering the full path from departure 382 through to the alternate airport.

[00278] In relation to DPA airports, DPD and ETOPS contingency paths, Algorithms 33, 34 and 35 as previously discussed in relation to the prior example can be used. Computing Implementation

[00279] The methods and computer executable instructions are configured to preferably be implemented using modern computer architecture having multiple processors 102 with a large amount of memory (RAM) 104. Multiple processors 102 means that tasks can be executed in parallel. In particular, multiple plans can be identified simultaneously. Because the PRM search graph 360 is constructed as a pre-processing step, the data can be replicated in the local memory 104 of each computing node (set of processors or cores) without creating a cache-coherence problem. Additionally, the search process can also be parallelised.

[00280] For example, searching across multiple CI values can be implemented by assigning a given CI (or set of CI values) to each core 102. In an additional or alternate form, each core 102 of the multi core system can be assigned a given landing weight at the destination location to search such that at least some of the plurality of potential flight paths are determined substantially simultaneously.

[00281] In this way, a desired level of run-time performance can be achieved by adding hardware. This is a significant advantage compared to a non-parallel implementation. In a preferred embodiment, the algorithms are implemented on a computing cluster. This approach is flexible because clusters can be expanded by adding more computing nodes.

[00282] Referring to Figure 50 of the drawings, the set of algorithms can be implemented using as a client-server system 1600. The server processing system 1630 performs the operation of processing system 100 and accepts requests from a client processing system 1610 that communicates via a standard computer network 1620 such as the Internet, an Intranet and/or the like. The client processing system 1610 provides description data indicative of the input parameters, and the server processing system 1630 returns preferred flight plan data including the preferred flight path, the take-off weight and other relevant details of the preferred flight plan as described above. The preferred flight plan can be returned in a structured format that is designed for easy post-hoc analysis using standard software tools.

[00283] In certain embodiments, the server processing system 1630 can be configured to receive the fuel consumption data for a particular aircraft from the client processing system 1610. For example, a particular instance of an aircraft may have been monitored based on current operating conditions to generate the current fuel consumption data. In alternate examples, a new plane may have been modeled, wherein the fuel consumption data models the fuel consumption of the modeled aircraft. As such, different fuel consumption data for different aircraft result in potentially different preferred flight paths due to different operational characteristics. In additional or alternate embodiments, the server processing system 1630 may have stored in memory 104 a plurality of different types of fuel consumption data for different aircraft, wherein the user at the client processing system 1610 may provide input to select one of the types of fuel consumption data for use in determining the preferred flight plan. Other Commercial Uses

[00284] In certain embodiments, the executable instructions can be provided in the form of a software tool that produces many flight plans simultaneously to represent a wide range of operating conditions. The inputs that the software tool can accept include weather predictions, a fuel consumption model for the aircraft, the desired routes (i.e. departures and destinations) and the fuel policy parameters. The software tool can then output fuel consumption and payload data optimised with respect to the input data.

[00285] In particular applications, the tool can be used to perform a comparison between two or more aircraft for a particular time period (e.g. three years) for a particular airline. For example, the airline or the manufacturer can use the software tool to compare a current aircraft against a newly proposed aircraft for current routes serviced. The output can help aid the airline in their decision as to whether to purchase the aircraft. This type of output is significantly more meaningful than the information which is currently available.

[00286] In addition, the software tool could be used by airlines to discover new optimised flight paths and take-off weights for current routes. Additionally or alternatively, the software tool can be used to discover new routes and corresponding flight paths (and corresponding take-off weights) which may not currently be serviced which are financially viable. Conclusion

[00287] Optional embodiments of the present invention may also be said to broadly consist in the parts, elements and features referred to or indicated herein, individually or collectively, in any or all combinations of two or more of the parts, elements or features, and wherein specific integers are mentioned herein which have known equivalents in the art to which the invention relates, such known equivalents are deemed to be incorporated herein as if individually set forth. [00288] Although a preferred embodiment has been described in detail, it should be understood that many modifications, changes, substitutions or alterations will be apparent to those skilled in the art without departing from the scope of the present invention.

[00289] The present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, firmware, or an embodiment combining software and hardware aspects.

Claims

1. A method for determining a preferred flight plan for an aircraft, wherein the method includes, at the processing system, steps of:

constructing a probabilistic roadmap (PRM) search graph including:

PRM nodes, each including:

a latitude and longitude pair of a flight space; and/or

an altitude from an altitude set; and

PRM edges, each extending between two PRM nodes;

outputting a preferred flight plan based on the preferred flight path.

2. The method according to claim 1, wherein the search performed by the processing system includes traversing the PRM search graph from the destination node back to any of the departure nodes whilst calculating a weight of the aircraft at each traversed PRM node using the fuel consumption data.

3. A method for determining a preferred flight plan for an aircraft, wherein the method includes, at the processing system, steps of:

constructing a probabilistic roadmap (PRM) search graph including:

PRM nodes, each including:

a latitude and longitude pair of a flight space;

a weight from a weight set; and

an altitude from an altitude set; and PRM edges, each extending between two PRM nodes and including a cost based on fuel consumption data;

outputting a preferred flight plan based on the preferred flight path.

4. The method according to any one of claims 1 to 3, wherein the method includes: determining, by the processing system, one or more contingency paths for each potential flight path; and

determining, by the processing system, a contingency fuel consumption for each potential flight path based upon the one or more contingency paths and the fuel consumption data..

5. The method according to claim 4, wherein the objective function is at least partially dependent upon the contingency fuel consumption for each potential flight path.

6. The method according to either claim 4 or claim 5, wherein the method includes connecting a plurality of diversion nodes for diversion locations to the PRM search graph for varying weights, wherein each potential flight path identified includes a diversion flight path to one of the diversion nodes from the respective destination node or a top of decline node, wherein the processing system calculates a fuel consumption for travelling along the diversion flight path which is at least part of the respective contingency fuel consumption.

7. The method according to claim 6, wherein each identified potential flight path includes an equi-fuel flight path from an equi-fuel point along the respective potential flight path which consumes the same amount of fuel to travel to a pair of the diversion locations, wherein the processing system calculates a fuel consumption for travelling from the equi-fuel point to one of the diversion locations which is at least part of the respective contingency fuel consumption.

8. The method according to either claim 6 or claim 7, wherein each identified potential flight path includes an equi-time flight path from an equi-time point along the respective potential flight path which requires the same travel time to a pair of the diversion locations, wherein the processing system calculates a fuel consumption for travelling along the equi-time flight path which is at least part of the respective contingency fuel consumption.

9. The method according to any one of claims 1 to 8, wherein, after identifying the potential flight paths and prior to selecting one of the potential flight paths according to the objective function, the method includes, for each potential flight path:

10. The method according to any one of claims 1 to 9, wherein the method includes applying, by the processing system, continuous optimisation to the preferred flight path wherein the optimised preferred flight path is output as part of the preferred flight plan.

11. The method according to any one of claims 1 to 10, wherein the processing system is a multi-core processing system, wherein the method includes using multiple cores of the multi- core processing system simultaneously in order to search the PRM search graph for the various landing weights of the destination nodes.

12. The method according to any one of claims 1 to 11, wherein the processing system is a server processing system, wherein the method includes:

13. The method according to claim 12, wherein the method includes the server processing system receiving aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data.

14. The method according to claim 1 to 13, wherein the method includes:

filling the aircraft with one or more of fuel and a payload such that the aircraft has a take-off weight substantially corresponding to the weight of the respective departure node of the preferred flight plan; and

operating the aircraft substantially according to the preferred flight plan.

15. A processing system for determining a preferred flight plan for an aircraft, wherein the processing system is configured to perform the method of any one of claims 1 to 13.

16. A computer readable medium including executable instructions for execution by a processing system, wherein the processing system is configured to perform the method according to any one of claims 1 to 13.

17. A system for determining a preferred flight plan for an aircraft, wherein the system includes:

a processing system configured to perform the method of any one of claims 1 to 11, wherein the processing system is a server processing system; and

18. The system according to claim 17, wherein the server processing system receives aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data.

19. A method for determining a preferred flight plan for an aircraft, wherein the method includes the steps performed by a processing according to any one of claims 1 to 11, wherein the processing system is a server processing system, wherein the method further includes steps of:

20. The method according to claim 19, wherein the method includes the server processing system receiving aircraft model data from the client processing system, wherein the fuel consumption data is dependent upon the aircraft model data.