Method for planning route of vehicle

Abstract

The present disclosure relates to a device 200, 990 (e.g., a data processing device) for planning a route of a vehicle 10. The apparatus 200, 900 is configured to: determine 520 one or more target parameters for a trajectory solution TS1, TS2 for the vehicle based on the following; at least one scene SN, S1, S2 defined by one or more constraint parameters relating to the vehicle and / or the journey to be performed by the vehicle 10; and at least one situation N, ET, ER that the vehicle 10 may experience when performing the journey. The disclosure also relates to a computer-implemented method 500 for planning a route of a vehicle 10.

Description

Technical Field

[0001] The present disclosure relates to a computer-implemented method for planning a route (eg, a trajectory) of a vehicle (eg, an aircraft). Background Art

[0002] During routine operations of commercial aircraft (e.g., civilian aircraft), manual intervention by the aircraft's flight crew may be required to meet operational constraints and air traffic control (ATC) requirements. For example, if a given altitude constraint is expected to no longer be feasible at some point during flight, the pilot may be instructed to manually adjust the speed target or deselect thrust reduction profiles and subsequently reselect them. This can lead to complex in-flight procedures and increased workload for the flight crew. As a result, some operators default to the most conservative options. Consequently, conventional methods for managing flight and engine operations may be considered largely suboptimal.

[0003] Satisfying safety and / or operational constraints is the most important in daily operations, and in conventional trajectory planning methods, for safety reasons, the solutions usually generated are highly conservative. Yet, at the same time, such methods may comprise very few mechanisms to ensure that operational and safety requirements are actually met in subsequent specific implementations. In addition, in conventional system architectures, there may only be limited information exchange between onboard flight path planning and air traffic management (ATM) services. ATM is based on the typical performance characteristics of different aircraft categories and the typical vehicle behavior ordered by flight management and automatic flight control systems to the expectation of flight path. Under this framework, operational efficiency often yields to the preference of ATM human operators. For example, in order to ensure that any ongoing climb / descent manipulation can be easily identified, the flight path planning of aircraft often typically adheres to a minimum climb / descent rate. Therefore, a flight management system that can flexibly adapt to different generations of ATM systems is needed.

[0004] The present invention is designed in consideration of the above circumstances. Summary of the Invention

[0005] According to a first aspect, there is provided an apparatus (e.g., a data processing apparatus) for planning a route for a vehicle, the apparatus being configured to determine a trajectory solution for the vehicle based on: one or more target parameters; at least one scenario defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and at least one situation that the vehicle may experience while performing the trip.

[0006] Possibly, the apparatus is configured to determine a trajectory solution for the vehicle based on: one or more target parameters; at least one scenario defined by one or more constraint parameters relating to the vehicle and / or the trip to be made by the vehicle; and a plurality of situations, each of which the vehicle may experience while making the trip.

[0007] Possibly, the apparatus is configured to determine a trajectory solution for the vehicle based on: one or more target parameters; a plurality of scenarios, each of the plurality of scenarios being defined by one or more constraint parameters associated with the vehicle and / or the trip to be performed by the vehicle; and at least one situation that the vehicle may experience while performing the trip.

[0008] Possibly, the apparatus is configured to determine a trajectory solution for the vehicle based on: one or more target parameters; a plurality of scenarios, each of the plurality of scenarios being defined by one or more constraint parameters associated with the vehicle and / or the trip to be made by the vehicle; and a plurality of situations, each of the plurality of situations being situations that the vehicle may experience while making the trip.

[0009] The plurality of situations may include at least one of a non-emergency situation and an emergency situation, and optionally include each of the non-emergency situation and the emergency situation. Possibly, the plurality of situations includes at least two emergency situations.

[0010] It is possible that the device is configured to determine the trajectory solution based on the plurality of scenarios, and the plurality of scenarios comprises the device being configured to evaluate each of the plurality of scenarios according to each of the plurality of situations.

[0011] A difference between at least two of the plurality of scenarios may correspond, at least in part, to an uncertainty associated with the one or more constraint parameters.

[0012] Possibly, the apparatus is configured to determine the trajectory solution based on the relative importance of the or each target parameter.

[0013] Possibly, the device is configured to determine the trajectory solution based on a trade-off between a pair of target parameters.

[0014] Possibly, the apparatus is configured to determine the trajectory solution as a first trajectory solution based on a first trade-off between the pair of target parameters. The apparatus may be further configured to determine a second trajectory solution for the vehicle based on: a second trade-off between the pair of target parameters; the or each scenario associated with the vehicle and / or the trip to be performed by the vehicle; and the or each situation that the vehicle may experience while performing the trip.

[0015] The apparatus may be configured to determine the second trajectory solution based on the same pair of target parameters as the first trajectory solution.

[0016] The or each constraint parameter may relate to: characteristics of the vehicle; characteristics of a thruster coupled to the vehicle; operating environmental conditions of the vehicle; safety constraints; and operational constraints.

[0017] Possibly, the apparatus is further configured to: receive vehicle trip information; and determine the or each scenario based on the received vehicle trip information.

[0018] The vehicle trip information may describe an origin, a destination, and / or a path to be traversed by the vehicle from the origin to the destination. The vehicle trip information may include at least one of vehicle dynamics, powerplant dynamics, operating environment conditions, safety constraints, and operating constraints.

[0019] The or each target parameter may be associated with performance of at least one component of the vehicle during the trip.

[0020] The or each target parameter may be: the energy consumption of the vehicle; the fuel consumption of the vehicle; associated with degradation of components of the vehicle; the amount of chemicals emitted by the vehicle; the time taken by the vehicle to complete at least part of the journey; the performance of components of the vehicle; or the durability of components of the vehicle.

[0021] It is possible that the or each trajectory solution for the vehicle is determined such that the or each target parameter is optimised.The target parameter being optimised may comprise the target parameter being minimised or maximised.

[0022] The or each trajectory solution may define at least one of: a thrust profile provided to a propeller of the vehicle; an airspeed profile; a horizontal displacement profile or a horizontal velocity profile; a vertical displacement profile or a vertical velocity profile; and a position of one or more control surfaces provided to the vehicle. The horizontal displacement profile may define at least one or both of the latitude and longitude of the vehicle.

[0023] The or each constraint parameter may be: the weight of the vehicle; wind speed; wind direction; the braking coefficient associated with the braking system provided to the aircraft; the inclination of the external surface on which the vehicle will travel as part of the journey; the length of the external surface; the coefficient of friction associated with the interaction between the vehicle and the external surface.

[0024] Possibly, the device is further configured to provide information about the or each determined trajectory solution for consideration, approval and / or selection by a user.

[0025] Possibly, the device being configured to provide information about the or each determined trajectory solution for user approval and / or selection comprises the device being configured to cause information about the or each determined trajectory solution to be displayed to the user on a graphical user interface.

[0026] The apparatus may be configured to receive an indication from a user of a selected trajectory solution to be achieved.

[0027] It is possible that the information about the or each determined trajectory solution comprises an indication of the value of the or each target parameter at which the or each trajectory solution was determined.

[0028] Possibly, the device is configured such that the vehicle is controlled according to a selected trajectory solution.

[0029] Possibly, the apparatus is configured to provide information about the or each determined trajectory solution for consideration, approval, and / or selection by a user. The information about each determined trajectory solution may include an indication of the value of each target parameter used to determine each trajectory solution. The apparatus may also be configured to receive an input selecting one of the indications; and cause the vehicle to be controlled in accordance with the trajectory solution associated with the selected indication.

[0030] Possibly, the apparatus is configured to provide information about the or each determined trajectory solution for consideration, approval and / or selection by a user. The information about each determined trajectory solution may include an indication of the value of each target parameter with respect to which each trajectory solution is determined. The apparatus may further be configured to receive an input selecting a value for each target parameter that is not equal to the value of the corresponding target parameter with respect to which the first and second trajectory solutions are determined; determine a third trajectory solution for the vehicle based on: the selected value of each target parameter; a third trade-off between the pair of target parameters based on the input; the or each scenario associated with the vehicle and / or the journey to be undertaken by the vehicle; and the or each situation that the vehicle may experience while undertaking the journey; and cause the vehicle to be controlled in accordance with the third trajectory solution.

[0031] Possibly, the vehicle is an aircraft comprising a propeller. The propeller may comprise a gas turbine engine.

[0032] According to a second aspect, there is provided a vehicle comprising a data processing apparatus according to the first aspect.

[0033] According to a third aspect, there is provided a computer-implemented method for planning a route for a vehicle, the method comprising: determining a trajectory solution for the vehicle based on: one or more target parameters; at least one scenario defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and at least one situation that the vehicle may experience while performing the trip.

[0034] Possibly, the method includes determining a trajectory solution for the vehicle based on: one or more target parameters; at least one scenario defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and a plurality of situations, each of the plurality of situations being likely to be experienced by the vehicle while performing the trip.

[0035] Possibly, the method includes determining a trajectory solution for the vehicle based on: one or more target parameters; a plurality of scenarios, each of the plurality of scenarios being defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and at least one situation that the vehicle may experience while performing the trip.

[0036] Possibly, the method includes determining a trajectory solution for the vehicle based on: one or more target parameters; a plurality of scenarios, each of the plurality of scenarios being defined by one or more constraint parameters associated with the vehicle and / or the trip to be performed by the vehicle; and a plurality of situations, each of the plurality of situations being a situation that the vehicle may experience while performing the trip.

[0037] The plurality of situations may include at least one of a non-emergency situation and an emergency situation, and optionally include each of the non-emergency situation and the emergency situation. Possibly, the plurality of situations includes at least two emergency situations.

[0038] Possibly, the method comprises determining the trajectory solution based on the plurality of scenarios, and the plurality of scenarios comprises the device being configured to evaluate each of the plurality of scenarios according to each of the plurality of situations.

[0039] A difference between at least two of the plurality of scenarios may correspond, at least in part, to an uncertainty associated with the one or more constraint parameters.

[0040] Possibly, the method comprises determining the trajectory solution based on a relative importance of the or each target parameter.

[0041] Possibly, the method comprises determining the trajectory solution based on a trade-off between a pair of target parameters.

[0042] Possibly, the method comprises determining the trajectory solution as a first trajectory solution based on a first trade-off between the pair of target parameters. The method may further comprise determining a second trajectory solution for the vehicle based on: a second trade-off between the pair of target parameters; the or each scenario associated with the vehicle and / or the trip to be performed by the vehicle; and the or each situation that the vehicle may experience while performing the trip.

[0043] The method may include determining the second trajectory solution based on the same pair of target parameters as the first trajectory solution.

[0044] The or each constraint parameter may relate to: characteristics of the vehicle; characteristics of a thruster coupled to the vehicle; operating environmental conditions of the vehicle; safety constraints; and operational constraints.

[0045] Possibly, the method further comprises: receiving vehicle trip information; and determining the or each scenario based on the received vehicle trip information.

[0046] The vehicle trip information may describe an origin, a destination, and / or a path to be traversed by the vehicle from the origin to the destination. The vehicle trip information may include at least one of vehicle dynamics, powerplant dynamics, operating environment conditions, safety constraints, and operating constraints.

[0047] The or each target parameter may be associated with performance of at least one component of the vehicle during the trip.

[0048] The or each target parameter may be: the energy consumption of the vehicle; the fuel consumption of the vehicle; associated with degradation of components of the vehicle; the amount of chemicals emitted by the vehicle; the time taken by the vehicle to complete at least part of the journey; the performance of components of the vehicle; or the durability of components of the vehicle.

[0049] It is possible that the or each trajectory solution for the vehicle is determined such that the or each target parameter is optimised.The target parameter being optimised may comprise the target parameter being minimised or maximised.

[0050] The or each trajectory solution may define at least one of: a thrust profile provided to a propeller of the vehicle; an airspeed profile; a horizontal displacement profile or a horizontal velocity profile; a vertical displacement profile or a vertical velocity profile; and a position of one or more control surfaces provided to the vehicle. The horizontal displacement profile may define at least one or both of the latitude and longitude of the vehicle.

[0051] The or each constraint parameter may be: the weight of the vehicle; wind speed; wind direction; the braking coefficient associated with the braking system provided to the aircraft; the inclination of the external surface on which the vehicle will travel as part of the journey; the length of the external surface; the coefficient of friction associated with the interaction between the vehicle and the external surface.

[0052] Possibly, the method further comprises providing information about the or each determined trajectory solution for consideration, approval and / or selection by a user.

[0053] Providing information about the or each determined trajectory solution for user approval and / or selection may comprise causing information about the or each determined trajectory solution to be displayed to the user on a graphical user interface.

[0054] The method may include receiving an indication from a user of a selected trajectory solution to be achieved.

[0055] It is possible that the information about the or each determined trajectory solution comprises an indication of the value of the or each target parameter at which the or each trajectory solution was determined.

[0056] Possibly, the method comprises causing the vehicle to be controlled according to the selected trajectory solution.

[0057] Possibly, the method includes providing information about the or each determined trajectory solution for consideration, approval, and / or selection by a user. The information about each determined trajectory solution may include an indication of the value of each target parameter used to determine each trajectory solution. The method may also include receiving input selecting one of the indications; and causing the vehicle to be controlled in accordance with the trajectory solution associated with the selected indication.

[0058] Possibly, the method includes providing information about the or each determined trajectory solution for consideration, approval and / or selection by a user. The information about each determined trajectory solution may include an indication of the value of each target parameter with respect to which each trajectory solution is determined. The method may also include receiving an input selecting a value for each target parameter that is not equal to the value of the corresponding target parameter with respect to which the first trajectory solution and the second trajectory solution are determined; determining a third trajectory solution for the vehicle based on: the selected value of each target parameter; a third trade-off between the pair of target parameters based on the input; the or each scenario associated with the vehicle and / or the trip to be made by the vehicle; and the or each situation that the vehicle may experience while making the trip; and causing the vehicle to be controlled in accordance with the third trajectory solution.

[0059] Possibly, the vehicle is an aircraft comprising a propeller. The propeller may comprise a gas turbine engine.

[0060] According to a fourth aspect, there is provided a computer program comprising instructions which, when a computer executes the program, cause the computer to perform the method according to the third aspect.

[0061] According to a fifth aspect, there is provided a computer readable data carrier having stored thereon the computer program according to the fourth aspect.

[0062] The approach proposed in this invention can not only maximize the operational benefits of future vehicle designs and future air traffic management systems, but can also be easily adapted to produce customized solutions to improve the efficiency of current generation fleets and flight operations.

[0063] Those skilled in the art will understand that, unless mutually exclusive, the features described in any one of the above aspects may be applied to any other aspects as appropriately modified. In addition, unless mutually exclusive, any feature described herein may be applied to any aspect and / or combined with any other feature described herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Examples of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, which are schematic diagrams only and are not drawn to scale, and in which:

[0065] Figure 1 is a highly simplified schematic diagram of an aircraft including a gas turbine engine and an integrated flight and powerplant management system (IFPMS);

[0066] Figure 2 An example machine-readable medium / data carrier is shown;

[0067] Figure 3 Shown is suitable for Figure 1 the general arrangement of turbofan engines for use with aircraft;

[0068] Figure 4 is a representation of an example of a vertical navigation path for an aircraft;

[0069] Figure 5 is a flow chart illustrating an example method of planning a trip for a vehicle according to the present disclosure;

[0070] Figure 6 is shown as Figure 5 A block diagram of a set of example trajectory solutions determined as part of the illustrated example method;

[0071] Figure 7 It is shown in detail Figure 5 a flow chart of a portion of the illustrated example method;

[0072] Figure 8 Shown as Figure 5 An example format for displaying information as part of the example method shown;

[0073] Figure 9 is a block diagram illustrating the general structure of a formulation of an example single-scenario multi-case optimization problem using a multi-stage trajectory optimization process;

[0074] Figure 10 Schematic illustration of the balance of forces on an aircraft during the rotation phase of takeoff;

[0075] Figure 11 schematically illustrates the balance of forces on an aircraft during the liftoff phase;

[0076] Figure 12 Includes a plurality of graphs showing thrust F for an infinite segment of the net thrust profile relative to airspeed n , acceleration Airspeed v TAS and ground speed v g the relationship between each of them;

[0077] Figure 13 shows a diagram of trajectory profile geometry constraints across different phases with mismatched time intervals in different scenarios;

[0078] Figure 14 is a block diagram illustrating the general structure of a formulation of an example multi-scenario multi-case optimization problem using a multi-stage trajectory optimization process;

[0079] Figure 15 It shows that Figure 14 a graphical representation of a comparison of thrust profiles with respect to airspeed for one of the stages of the multi-scenario multi-case optimization problem shown;

[0080] Figure 16A The nominal takeoff condition is shown by Figure 14 Illustration of the position vs. altitude components of the trajectory solution for the multi-scenario, multi-case optimization problem shown;

[0081] Figure 16B In the case of an emergency, Figure 14 Illustration of the position vs. altitude components of the trajectory solution to the multi-scenario multi-case optimization problem shown, the example emergency corresponding to an engine failure at v1 during the takeoff roll and the subsequent decision by the flight crew to proceed with the takeoff;

[0082] Figure 16C In the case of an emergency, Figure 14Illustration of the position vs. altitude components of the trajectory solution to the multi-scenario multi-case optimization problem shown for an example emergency corresponding to an engine failure at v1 during the takeoff roll and the subsequent decision by the flight crew to abort / reject the takeoff;

[0083] 17A to 17F It is shown by Figure 14 A diagram of other components of the trajectory solution to the multi-scenario multi-case optimization problem shown; and

[0084] Figure 18 Including shown by Figure 14 Multiple illustrations of the thrust and airspeed planning aspects of the trajectory solution to the multi-scenario, multi-case optimization problem are shown. DETAILED DESCRIPTION

[0085] airplane

[0086] Figure 1 A schematic plan view of an aircraft 10 is shown. The aircraft 10 includes an integrated flight and powerplant management system (IFPMS) 200. The IFPMS 200 includes data processing equipment (e.g., a processor and memory). The aircraft 10 also includes a propeller 101 (e.g., a gas turbine engine 101) configured to generate thrust for propelling the aircraft 10 through the air. The gas turbine engine 101 may be generally described below with reference to Figure 3 The gas turbine engine 101 described herein is consistent with the gas turbine engine 101 described herein. Additionally, the aircraft 10 may be provided with (e.g., coupled to) an alternative type of propulsion (e.g., an alternative type of propulsion device), such as a propeller or fan configured to be driven by an electric motor. Such a propulsion device / propulsion device may be referred to herein as a power plant and / or engine. The processor of the IFPMS (which may also be referred to as a controller) may be configured to implement the method described herein for determining a route for the vehicle 1.

[0087] Machine-readable medium / data carrier

[0088] Figure 2 There is shown schematically, in a highly simplified manner, a machine-readable medium / data carrier 900 having stored thereon a computer program 90 comprising instructions which, when processed by a data processing device 990 (such as the one described above with reference to FIG. Figure 1 and / or Figure 5 When the IFPMS 200 described herein is executed, the data processing device 990 executes the Figures 5 to 8 And refer to the method 500 described in the section of this disclosure labeled "Appendix."

[0089] The data processing device 990 may include a controller and / or a processor. It should be understood that the functions referred to herein as being performed by a single controller and / or a single processor may be performed by multiple controllers and / or multiple processors. The data processing device, controller, and / or processor may include any appropriate circuitry to enable the execution of the methods described herein and as illustrated in the accompanying figures. As used herein, the term "circuitry" is intended to include any combination of digital and / or hardware circuitry, software, and / or firmware, including any blocks, modules, programs, or flow charts described herein, to achieve the desired output, function, and / or result. Thus, the data processing device, controller, or processor may include: at least one application-specific integrated circuit (ASIC); and / or at least one field-programmable gate array (FPGA); and / or a single-processor or multi-processor architecture; and / or a sequential (von Neumann) / parallel architecture; and / or at least one programmable logic controller (PLC); and / or at least one microprocessor; and / or at least one microcontroller; and / or a central processing unit (CPU) to execute the methods or stated functions for which the data processing device, controller, or processor is configured. Thus, a data processing apparatus, controller or processor may be embodied as code stored on any suitable carrier, such as a volatile or non-volatile medium, or programmed memory including software and / or firmware implemented on an ASIC or FPGA or the like, as described above.

[0090] The data processing device, controller or processor may include or communicate with one or more memories that store the data described herein and / or store machine-readable instructions (e.g., software) for performing the processes and functions described herein (e.g., determination of parameters and execution of control routines), including code that, when executed, causes one or more processes set forth in the appendix to be performed to thereby implement various examples of the present disclosure. The memory may be any suitable non-transitory computer-readable storage medium, one or more data storage devices, and may include a hard disk and / or solid-state memory (such as flash memory). In some examples, the computer-readable instructions may be transmitted to the memory via a wireless signal or via a wired signal. The memory may be a permanent, non-removable memory, or may be a removable memory (such as a universal serial bus (USB) flash drive). The memory may store a computer program comprising computer-readable instructions that, when read by the data processing device 990, processor or controller, causes the execution of the methods described herein and / or as illustrated. The computer program may be software or firmware, or may be a combination of software and firmware.

[0091] gas turbine engine

[0092] Figure 3The general arrangement of an engine 101 for an aircraft is shown. The engine 101 has a turbofan configuration and thus comprises a ducted fan 102 which receives inlet air A and generates two pressurized air flows: a bypass flow B which passes axially through a bypass duct 103 and a core flow C which enters a core gas turbine.

[0093] The core gas turbine includes a low-pressure compressor 104 , a high-pressure compressor 105 , a combustor 106 , a high-pressure turbine 107 , and a low-pressure turbine 108 in axial series.

[0094] In operation, core flow C is compressed by low-pressure compressor 104 and then directed to high-pressure compressor 105 for further compression. The compressed air discharged from high-pressure compressor 105 is directed to combustor 106, where it is mixed with fuel and the mixture is burned. The resulting hot combustion products then expand through and thereby drive high-pressure turbine 107, and are then discharged after driving low-pressure turbine 108 to provide a small portion of the total thrust.

[0095] High-pressure turbine 107 drives high-pressure compressor 105 via an interconnecting shaft. Low-pressure turbine 108 drives low-pressure compressor 104 via another interconnecting shaft. High-pressure compressor 105, high-pressure turbine 107, and associated interconnecting shafts together form part of the high-pressure spool of engine 101. Similarly, low-pressure compressor 104, low-pressure turbine 108, and associated interconnecting shafts form part of the low-pressure spool of engine 101. Such terminology will be familiar to those skilled in the art. Those skilled in the art will also understand that, although the illustrated engine has two spools, other gas turbine engines have different numbers of spools, such as three.

[0096] The fan 102 is driven by the low-pressure turbine 108 via a reduction gearbox in the form of an epicyclic gearbox 109 in a planetary configuration. Thus, in this configuration, the low-pressure turbine 108 is connected to the sun gear of the gearbox 109. The sun gear meshes with a plurality of planetary gears located in a rotating carrier, which in turn mesh with a stationary ring gear. The rotating carrier drives the fan 102 via a fan shaft 110. It will be appreciated that, in an alternative example, an epicyclic gearbox in a star configuration (wherein the planetary carrier is stationary and the ring gear rotates and provides the output) may be used instead, and indeed the gearbox 109 may be omitted entirely, such that the fan 102 is driven directly by the low-pressure turbine 108.

[0097] It may be increasingly desirable to facilitate a greater degree of electrical functionality on the airframe and engines. To this end, the engine 101 includes one or more rotary electric machines that are typically capable of operating both as motors and as generators. The number and arrangement of the rotary electric machines will depend to some extent on the desired functionality. Some examples of the engine 101 may include, for example, a single rotary electric machine 111 driven through a high voltage spool by a core mounted accessory drive 112 of conventional configuration. Such a configuration facilitates the generation of electrical power for the engine and aircraft, as well as driving the high voltage spool to facilitate starting the engine in lieu of an air turbine starter. Figure 1 Other examples of the illustrated example include both the first rotary machine 111 coupled to the high-pressure shaft and the second rotary machine 113 coupled to the low-pressure shaft. In addition to generating electricity and starting the engine 101, having both the first rotary machine 111 and the second rotary machine 113 connected by power electronics can facilitate the transmission of mechanical power between the high-pressure shaft and the low-pressure shaft to improve operability, fuel consumption, etc.

[0098] As mentioned above, in Figure 1 In the embodiment, the first rotary motor 111 is driven by a core mounted accessory drive 112 of conventional configuration through a high pressure shaft. In an alternative example, the first motor 111 may be mounted coaxially with the turbomachinery in the engine 101. For example, the first motor 111 may be mounted in axial alignment with the duct between the low pressure compressor 104 and the high pressure compressor 105. Figure 1 In the embodiment, the second electric machine 113 is mounted coaxially with the turbomachinery in the tail cone 114 of the engine 101 and is coupled to the low-pressure turbine 108. In an alternative example, the second rotary electric machine 113 may be positioned axially aligned with the low-pressure compressor 104, which may adopt a bladed disk or bladed drum configuration to provide space for the second rotary electric machine 113. Of course, those skilled in the art will understand that any other suitable locations for the first and second electric machines (if present) may be adopted.

[0099] The first electric machine 111 and the second electric machine 113 are connected to power electronics. Power extraction from the electric machines and power application to the electric machines are performed by a power electronics module (PEM) 115. In this example, the PEM 115 is mounted on the fan case 116 of the engine 101, but it should be understood that it can be mounted elsewhere, such as on the core of a gas turbine or in a vehicle to which the engine 101 is attached.

[0100] In this example, control of the PEM 115 and the first and second electric machines 111 and 113 is performed by an engine electronic controller (EEC) 117. In this example, the EEC 117 is a full authority digital engine controller (FADEC), the configuration of which will be known and understood by those skilled in the art. Thus, it controls all aspects of the engine 101, namely the core gas turbine and the first and second electric machines 111 and 113. In this manner, the EEC 117 can respond to thrust and electrical power demands in an integrated manner.

[0101] One or more rotating electrical machines 111, 113 and power electronics 115 can be configured to output power to or receive power from one, two, or more DC buses. These DC buses allow power to be distributed to other engine electrical loads and electrical loads on the airframe. The DC buses can also receive power from or deliver power to an energy storage system, such as one or more battery modules or battery packs.

[0102] Those skilled in the art will appreciate that the gas turbine engine 101 described above may be considered a “more electric” gas turbine engine because the role of the electric machines 111 , 113 is increased compared to the electric machines of conventional gas turbines.

[0103] Method for planning routes of vehicles

[0104] According to the present disclosure, a method and apparatus are provided for determining a vehicle trajectory based on parameters to be optimized and a plurality of conditions related to an aircraft and / or its route and / or factors internal and / or external to the aircraft, as will now be described.

[0105] A reference mission profile may be developed based on aircraft design specifications, outlining different phases of planned flight for the aircraft having different requirements on the aircraft's powerplant or one or more propulsors (eg, engines).

[0106] Based on such reference mission profiles and at least one characteristic of the engine, the engine may be granted different ratings for different flight phases and / or conditions. Different thrust modes of the engine may then be made available for use in operation accordingly, e.g., after selection by the flight crew.

[0107] Based on the performance of the aircraft and powerplant in different modes and under different conditions, de-rating / thrust reduction techniques can be used to design the thrust profile. The thrust reduction calculations can be based on linear and / or fixed ratios derived from pre-calculated trajectory optimization solutions for a reference mission profile, and / or real-time online calculations of the vehicle trajectory can be performed using predictive control methods.

[0108] In addition, a set of flight dispatch tools and electronic flight bags (EFBs) are used to inform the flight crew (associated with the aircraft) of the availability of different thrust reduction profiles based on the predicted flight conditions. The flight crew can then select the thrust reduction profile accordingly via the control display unit (CDU) in the flight management system (FMS). The FMS will then plan the aircraft's flight trajectory based on the selected thrust profile and a plurality of pre-programmed standard flight profiles. In other words, in some examples, within the FMS, thrust profile selection and flight path planning may occur sequentially rather than concurrently (although in other examples, they may occur concurrently).

[0109] Figure 4 The flight profile is shown graphically, wherein the vertical axis indicates vertical navigation (VNAV).During the climb of the aircraft, VNAV comprises at least two modes: VNAV SPD ("Speed") and VNAV PTH ("Path").

[0110] When no current path constraint is activated, VNAV SPD is used, where a path constraint is a constraint that requires the aircraft to pass through a waypoint at a specific altitude (and which may be referred to as a waypoint constraint). When VNAV SPD mode is used, the aircraft will climb at the target airspeed using the thrust at the standard / rated climb setting. Figure 4 In the example shown, there are three main airspeed targets for this purpose: V2+15kts before reaching the transition altitude, a speed limit of 250kts below 10,000ft, and an economic climb speed mode for climbing to higher altitudes.

[0111] On the other hand, if at least one path constraint is activated, the system will automatically switch to VNAV PTH mode to obey the waypoint constraints until the waypoint has been passed. Figure 4 Such a waypoint constraint is exemplified in FIG, where the aircraft is required to pass through the waypoint WPB at 6000 ft. During this process, the aircraft's autothrottle adjusts engine operation appropriately. That is, the aircraft's autothrottle adjusts the engine thrust demand based on the aircraft's flight parameters, and the engines respond according to the adjusted engine thrust demand and any selected climb thrust reduction. Also in Figure 4 In the 2015 flight, the aircraft is required to pass through the waypoints WPA and WPC at altitudes above 4,000 ft and 18,000 ft respectively, but these are less stringent constraints as the aircraft is not required to pass the relevant waypoints at these altitudes. Therefore, the VNAV SPD mode can be used during this part of the flight.

[0112] Figure 5is a flow chart illustrating an example method 500 for planning a route (e.g., a trajectory) of a vehicle (e.g., an aircraft) according to the present disclosure. The method 500 may generally be implemented by any suitable data processing device. For example, the method 500 may be implemented by an IFPMS such as the one described above with respect to Figure 1 The IFPMS 200 described herein (e.g., its controller or processor, for example, by executing the instructions described above with respect to Figure 2 Method 500 can be implemented using machine-readable instructions stored in a memory as discussed above. Method 500 can be used to plan a route for a vehicle before the vehicle has begun traveling / while the vehicle is stationary (e.g., planning an aircraft trajectory before flight) or after the vehicle has begun traveling / operating (e.g., updating a planned aircraft trajectory during flight). The description of method 500 herein is made with reference to the following appendix, which should be considered a part of this specification.

[0113] The method 500 includes, at block 520 , determining one or more trajectory solutions (eg, a set of trajectory solutions) for the aircraft 10 . Figure 6 is a block diagram schematically illustrating a set of example trajectory solutions STS that may be determined at block 520 of method 500. Figure 6 In the example of , the set of trajectory solutions includes a first trajectory solution TS1 (or, it can be simply referred to as trajectory solution TS1) and a second trajectory solution TS2 (or, it can also be referred to as an additional trajectory solution). An individual trajectory solution can be referred to as a "candidate trajectory". The set of trajectory solutions can be referred to as a "task set".

[0114] Each trajectory solution STS defines at least one, any combination, or each of the following: a thrust profile required by the propellers 101 of the aircraft 10 (e.g., a thrust schedule or a thrust trajectory profile); an airspeed profile (e.g., an airspeed schedule or an airspeed trajectory profile); a horizontal displacement profile (e.g., including / being a latitude profile and / or a longitude profile) or a horizontal velocity profile; a vertical displacement profile (e.g., an altitude profile) or a vertical velocity profile; and positions of one or more control surfaces provided to the aircraft 10 (e.g., flaps, horizontal stabilizer, ailerons, flaperons, spoilers, etc.). Thus, each trajectory solution may include a set of vehicle control parameters and / or control parameters for components of the vehicle, and block 520 may include determining such a set of parameters. Thus, each trajectory solution may be defined by a set of such parameters.

[0115] At box 520, each trajectory solution STS is determined based on at least one target parameter, at least one scenario, and at least one situation. In some embodiments of method 500, at box 520, each trajectory solution STS is determined based on a plurality of target parameters including at least a first target parameter and a second target parameter (e.g., at least one pair of target parameters). Specifically, in one example, each trajectory solution STS is determined based on the same plurality of target parameters (e.g., the same first-degree target parameter). In one example, at box 520, the trajectory solution or each trajectory solution is determined based on a function of the first target parameter and the second target parameter (e.g., based on a trade-off preference between the two target parameters, such as optimization of the first target parameter and the second target parameter (e.g., Pareto optimization)), which will be discussed in further detail below. Figure 6 In the example of , each trajectory solution TS1, TS2 is determined based on multiple scenarios SN, S1, S2 and multiple conditions N, ET, ER, which may be the same set of scenarios and conditions for each trajectory solution (although in other examples, it should be understood that the scenarios and conditions may be different in different trajectory solutions). Specifically, in Figure 6 In the example of FIG, each trajectory solution TS1, TS2 is determined such that each of the plurality of scenarios SN, S1, S2 is evaluated according to each of the plurality of situations N, ET, ER. Each situation may be affected by a scenario in the sense that a scenario may at least partially define a situation. For example, a wet or dry environment (scenario) may determine whether a given portion of a vehicle's route (e.g., its takeoff or landing) may be considered an emergency situation.

[0116] Generally speaking, the or each target parameter is associated with the performance of the aircraft 10 during at least a portion of a journey (e.g., a flight). More specifically, the or each target parameter for the vehicle may be: energy consumption of the aircraft 10 (e.g., electrical energy consumption); fuel consumption of the aircraft 10; associated with degradation of components of the vehicle (e.g., wear on the propeller 101 due to, for example, high temperatures within the propeller 101); the amount of chemical substances emitted by the aircraft 10 (e.g., aircraft 10 / propeller 101 emissions); or the time it takes for the aircraft 10 to complete at least a portion of the flight.

[0117] As discussed above, at block 520, the or each trajectory solution STS may be determined based on the relative importance of the or each objective parameter. For example, in examples where the or each trajectory solution STS is determined based on multiple objective parameters, at block 520, the or each trajectory solution STS may be determined based on the importance of a first objective parameter relative to a second objective parameter, which may be referred to as a trade-off (e.g., a trade-off preference). As will be appreciated by those skilled in the art, a first objective parameter may conflict with a second objective parameter. For example, if the first objective parameter is the fuel consumption of the aircraft 10 and the second objective parameter is the time taken to complete at least a portion of the flight, then a conflict may be considered to exist between these two objectives. Therefore, at block 520, one parameter may be optimized, or a trade-off preference may be determined between the two objective parameters such that each parameter, and therefore each objective associated with the parameters, is optimized simultaneously (at least partially), such that the output of block 520 is that no objective parameter can be improved without degrading another objective parameter in some way (e.g., a "non-dominated," "non-inferior," "Pareto-optimal," or "Pareto-efficient" solution may be determined in examples where there are at least two objective parameters). In other words, block 520 may include determining a solution to a multi-objective optimization problem involving two (or more) objective parameters.

[0118] The set of trajectory solutions STS may include a first trajectory solution TS1, determined at block 520 based on a first trade-off preference between a first target parameter and a second target parameter, and a second trajectory solution TS2, determined at block 520 based on a second trade-off preference between the first target parameter and the second target parameter, wherein the first trade-off preference is different from the second trade-off preference. That is, the set of trajectory solutions STS may be determined based on a set (e.g., a plurality) of trade-off preferences, wherein each trajectory solution STS is determined based on a corresponding trade-off preference. In some embodiments of method 500, the set of trade-off preferences may be a predetermined (e.g., preconfigured) set of trade-off preferences stored in a memory of a data processing device executing method 500. In other embodiments, as part of method 500, the set of trade-off preferences may be determined based on input received from an external system (e.g., from an application programming interface (API) or from a human-machine interface (HMI)). The or each trade-off preference may be stored or received (e.g., from a processor, such as a processor elsewhere on the aircraft or from a ground station).

[0119] In the specific example of method 500, the set of trajectory solutions includes two "extreme" trajectory solutions. Specifically, the first trajectory solution TS1 is determined with reference to a first trade-off preference that completely prioritizes the first target parameter over the second target parameter. In other words, the second target parameter is insignificant relative to the first target parameter. Conversely, the second trajectory solution TS2 is determined with reference to a second trade-off preference that completely prioritizes the second target parameter over the first target parameter. In other words, the first target parameter is insignificant relative to the second target parameter.

[0120] Thus, in this example, the first trajectory solution TS1 is determined such that the first target parameter is optimized (e.g., minimized or maximized, depending on which is appropriate in the relevant context). If there are more than one trajectory solution for which the first target parameter is optimized (e.g., the solution is not unique), then one of the trajectory solutions for which the second target parameter is optimal (e.g., highest or lowest, depending on which is appropriate in the relevant context) is selected as the first trajectory solution TS1. In this particular embodiment of method 500, the determination of the second trajectory solution TS2 can be performed in a similar manner, but with the necessary modifications.

[0121] As described above, additionally or alternatively, the set of trajectory solutions STS may include one or more "intermediate" trajectory solutions for the aircraft 10. That is, at block 520, each trajectory solution forming part of the set of trajectory solutions STS is determined based on a respective trade-off preference corresponding to a different level of relative importance between the first target parameter and the second target parameter. In some implementations of the method, a plurality of trajectory solutions may be determined, the plurality of trajectory solutions including two "extreme" solutions and at least one "intermediate" solution, as discussed above.

[0122] To determine such an "intermediate" solution, block 520 of the method may: specify the relative importance of each objective parameter using weighting coefficients, and determine the "intermediate" solution such that a cost function based on these weighting coefficients is optimized (e.g., minimized or maximized, depending on which is appropriate in the relevant context); or specify one of the two objective parameters as a threshold criterion (e.g., a minimum threshold criterion or a maximum threshold criterion, depending on which is appropriate in the relevant context), and then optimize the other objective parameter such that the threshold criterion is met. Such relative importance may be received as input, for example, from a memory or from a user interacting with a GUI of a data processing device implementing the method.

[0123] The or each scenario is defined by one or more constraint parameters associated with the aircraft 10 and / or the journey to be performed by the aircraft 10. Figure 6In the example of , the multiple scenarios include a hypothetical scenario SN (which may be referred to as a zeroth scenario), a first scenario S1 and a second scenario S2, as will be explained in further detail below.

[0124] The method 500 may include, at block 510, receiving flight information (e.g., vehicle itinerary information). The flight information may relate to conditions inside or outside the aircraft 10 and / or the itinerary to be performed by the aircraft 10. The flight information may describe an origin, a destination, and / or a path to be traversed by the aircraft from the origin to the destination. Additionally or alternatively, the flight information may include at least one, any combination, or each of the following:

[0125] (i) Vehicle dynamics (e.g., vehicle characteristics), such as aerodynamic coefficients from the manufacturer or obtained via modeling, aircraft configuration (e.g., deployment of landing gear, high-lift devices, spoilers) based on typical selections for different phases of flight or specific selections made by the flight dispatcher / crew, and / or aircraft weight and balance information from the flight dispatcher / crew;

[0126] (ii) powerplant dynamics (e.g., propeller characteristics), such as performance parameters received from the engine manufacturer or obtained via modeling, health parameters received from the engine manufacturer or maintenance / overhaul managers;

[0127] (iii) Operating environmental conditions, such as atmospheric conditions from sensor measurements and forecast systems (e.g., airport weather reports, terminal area forecasts, NOTAMs), airport and runway information from databases and operational reports (e.g., information on runway closures, runway status with respect to snow, ice, and water), and / or changes in standard operations due to volcanic ash or other dust contamination from operational reports;

[0128] (iv) safety constraints, such as the flight envelope of the aircraft 10 received from the aircraft manufacturer, the operating limitations of the powerplant received from the organization responsible for engine design; and

[0129] (v) Operational constraints, such as those related to fleet management and operator planning (e.g., flight time requirements to ensure network stability), flight path and / or performance limitations imposed by standard operating procedures or temporarily imposed by air traffic control instructions. Each of these constraints may be in the form of equality and / or inequality constraints that apply when:

[0130] - at the start and / or end of a flight, e.g. to arrive before a night flight restriction, or

[0131] - At certain times during the flight, for example, the aircraft 10 is required to pass certain waypoints along the route, and optionally has requirements regarding the altitude and airspeed of the aircraft 10 at the time of crossing the waypoints (e.g., an airspeed limit below a specified altitude) for at least part of the flight.

[0132] Method 500 may include determining the or each constraint parameter based on the received flight information, such that the or each scenario is determined based on the received flight information. Thus, each constraint parameter may relate to: (i) vehicle dynamics; (ii) powerplant dynamics; (iii) operating environmental conditions; (iv) safety constraints; and / or (v) operational constraints as discussed above. Additionally or alternatively, the or each constraint parameter may be: the weight of the aircraft 10 (e.g., takeoff weight); wind speed (e.g., on the runway or in mid-air); wind direction (e.g., on the runway or in mid-air); a braking coefficient associated with a braking system provided to the aircraft 10 (e.g., within the landing gear of the aircraft 10 and / or due to the effect of air brakes); a friction coefficient associated with the interaction between the aircraft 10 and the runway (e.g., between the landing gear and the runway); the inclination of the runway (e.g., the slope of the runway); or the available length of the runway. In some embodiments, determining the or each constraint parameter may also or alternatively include receiving the or each constraint parameter (e.g., from another source, such as a source on or outside the aircraft). Thus, it will be appreciated that the or each scenario may be defined by, for example, the weight of the aircraft, the direction of the wind, a braking coefficient associated with the braking system provided to the aircraft 10, a friction coefficient associated with the interaction between the aircraft 10 and the runway, the inclination of the runway, and / or the available length of the runway. In this way, any given scenario may be defined by a set of constraint parameters that may effectively be some representation of the vehicle and / or the environment in which the vehicle will operate. Of course, in some examples, the or each scenario and / or constraint parameter may be user input, received from another source, or retrieved from a memory (such as a memory that is part of a data processing device implementing the method).

[0133] Additionally or alternatively, existing operating procedures and flight rules may be expressed as additional constraints for defining the or each scenario. In this manner, method 500 may be used to generate suitable trajectory solutions that do not require changes to existing operating procedures of aircraft 10, if necessary. This advantageously allows for a smooth introduction of method 500 into routine operations of aircraft 10 in a manner that requires minimal retraining / reeducation of flight crew members.

[0134] As mentioned above, in Figure 6In the example of FIG, the plurality of scenarios includes a hypothetical scenario SN (which may be referred to as a zeroth scenario), a first scenario S1, and a second scenario S2. A difference between any pair (e.g., any two scenarios) of the plurality of scenarios SN, S1, and S2 may correspond, at least in part, to an uncertainty associated with the or each constraint parameter defining the respective scenario SN, S1, and S2, as will be discussed below.

[0135] The method 500 may further include, at block 515, determining the or each scenario upon which the or each trajectory solution will be determined at block 520. This may include selecting values for constraint parameters that will be used to define each scenario that may be used subject to a degree of uncertainty in the constraint parameters.

[0136] Figure 7 Is shown as Figure 5 A flowchart of an example of details for determining each of the multiple scenarios SN, S1, and S2 using uncertain constraint parameters, as represented by block 515 in the method 500, is provided. In this example, determining the or each scenario includes the following actions: identifying, at sub-block 610, which of the one or more constraint parameters to be used to define the scenario has an uncertainty associated therewith; evaluating, at sub-block 620, the uncertainty level associated with the or each constraint parameter identified in the previous step (e.g., at sub-block 610); and selecting, at sub-block 630, a value for the constraint parameter to be used to define the scenario. Analysis / processing of data from previous vehicle operations (e.g., flight operations) and / or sensitivity analysis of different trajectory solutions may be used to assist in these processes. Such "uncertain parameters" may be identified based on input received from an external system (e.g., from an application programming interface (API) or from a human-machine interface (HMI)) and / or based on statistical analysis of historical data collected or received by the data processing device 990 performing the method 500 (e.g., based on statistical analysis of predicted pre-trip values and post-trip determined values). Process 600 can be considered a process for handling uncertain parameters and can be performed automatically, for example, as part of process 500, or can be performed upon specific prompting (e.g., based on user input). In other words, a user may notice the level of uncertainty in a certain parameter and request that process 600 be performed, or certain parameters may be stored with metadata (or a flag) designating the parameter as uncertain, in which case (block 630) a value for such parameter is calculated and / or selected (e.g., retrieved from memory). To illustrate the process performed at subblocks 620 and 630, consider the following specific example.

[0137] When the surface condition of the runway is expected to be dry (e.g., when the flight information received at block 510 indicates that the runway is in dry conditions), the level of uncertainty associated with the coefficient of friction regarding the interaction between the landing gear of the aircraft 10 and the runway and / or the level of uncertainty associated with the braking system provided to the aircraft 10 may be relatively low. In this case, it is therefore identified at subblock 620 that the level of uncertainty associated with these constraint parameters is low.

[0138] In contrast, when the surface condition of the runway is expected to be wet and / or icy (e.g., when the flight information received at block 510 indicates that the runway is in wet and / or icy conditions), the level of uncertainty associated with the coefficient of friction regarding the interaction between the landing gear of the aircraft 10 and the runway and / or the level of uncertainty associated with the braking system provided to the aircraft 10 may be relatively high. In this case, it is therefore identified at subblock 620 that the level of uncertainty associated with these constraint parameters is high.

[0139] To accommodate the high level of uncertainty associated with these constraint parameters in the latter case, multiple values for each of these constraint parameters (e.g., friction coefficient and braking coefficient) can be used to define the scenarios. That is, at least two different values for each of the friction coefficient and braking coefficient (e.g., a nominal value and a worst-case value, such as those shown in Table 2 in Section 3.1 of the Appendix) can be used to define the multiple scenarios. However, in some examples, to reduce the computational burden in the latter case, a single value for these parameters can still be used.

[0140] In contrast, in the former case, for example, when the runway surface condition is expected to be dry, it is generally acceptable to use only a single value for these parameters given the low level of uncertainty associated with these parameters. In fact, doing so may be advantageous because the computational burden imposed on the data processing equipment executing method 500 is relatively reduced compared to using multiple values for these constrained parameters (as might be done when the runway is expected to be wet and / or icy).

[0141] At subblock 630, the selection of values for the constraint parameters used to define the scenarios may also depend on the properties of the system of dynamic equations used to determine the trajectory solution. That is, if the system of dynamic equations exhibits monotonic behavior with respect to the uncertain parameters (see subsection 2.1 of the Appendix for a discussion of monotonicity), then it may be sufficient to consider only "extreme" values (e.g., worst-case values) of the identified uncertain constraint parameters. Otherwise, scenarios defined using different intermediate values (e.g., between the best-case and worst-case values) of the identified uncertain constraint parameters may also be considered to further increase the robustness of the trajectory solution determined therefrom. If so, a limit on the total number of scenarios corresponding to such intermediate values to be included may be defined based on the amount of computing resources available within the data processing device configured to perform method 500 and / or to limit the computational burden on the data processing device in use. In summary, block 630 of the method may include determining representative values (e.g., fixed coefficients) for parameters associated with uncertainty levels exceeding a predetermined threshold.

[0142] Now back to the specific reference Figure 6 Description of method 500. Each situation is a nominal situation (e.g., a normal situation or a non-emergency situation) or an emergency situation that the aircraft 10 may experience while performing a trip (e.g., while performing a flight). Optionally, as Figure 6 As shown in the example of , the multiple situations include a nominal situation N and two different safety-critical situations ER, ET that the aircraft 10 may experience while making the trip. All situations N, ER, ET are considered simultaneously as part of determining a set of trajectory solutions STS for the aircraft 10. This is because the successful handling of a given emergency situation can be measured against the state of the aircraft 10 in the nominal situation. For example, during the takeoff roll portion of the flight, a safety-critical emergency situation to be considered would be an engine failure at a decision speed Vi. The safe operation of the aircraft 10 after such a failure (e.g., continuing with the takeoff or rejecting the takeoff) is directly affected by the distance the aircraft 10 has traveled along the runway during the takeoff roll. The or each situation N, ER, ET can be determined by accessing a memory provided to a data processing device performing the method 500 and / or based on signals received from an external system (e.g., a remote server). It will be understood that the scenario and more specifically the or each constraint defining the scenario can affect the behavior of the vehicle and any corrective action to be taken in the emergency situation, etc., which is why (e.g., Figure 6Each trajectory solution is based on a given situation (N, ER, ET, etc.) that the vehicle may experience and is subject to scenarios that may affect the vehicle when controlling the vehicle according to the given situation, such as constraints (SN, S1, S2, etc.). Of course, those skilled in the art who have fully read this disclosure will understand that the nominal / emergency situation associated with vehicle takeoff when approaching the decision speed described above is merely one example of a practical implementation of the present disclosure. Other situations in which the present disclosure may be used as an alternative and / or in addition to this situation will be apparent to those skilled in the art and include, for example, safety-critical emergencies occurring after takeoff (e.g., during the steep climb portion of flight (e.g., a bird strike incident) or the final approach portion of flight (e.g., a wind shear incident or a go-around order from an air traffic controller)).

[0143] As mentioned above, at block 520 , each trajectory solution TS1 , TS2 may generally be determined using one or a combination of the following methods: solving an optimization problem; solving a feasibility problem; simulating; and finding and adjusting a predetermined solution.

[0144] In the former case, the or each optimization problem can be formulated and solved using a variety of techniques (e.g., heuristic search, nonlinear programming, quadratic programming) to achieve different optimality levels (e.g., improved feasible solutions, local optimal solutions, global optimal solutions, etc.), as will be apparent to those skilled in the art after reading the entire disclosure. However, a multi-stage trajectory optimization setup for solving the optimization problem will now be outlined in detail. The concepts of multi-scenario optimization (e.g., where the or each trajectory solution is determined based on multiple scenarios at block 520) and multi-case optimization (e.g., where the or each trajectory solution is determined based on multiple scenarios at block 520) are described in detail below. The concepts of single scenario and single case optimization will be considered as special / simplified cases of the aforementioned.

[0145] Without being bound by theory, the appendix below provides an explanation of how such one or more optimization problems can be formulated and subsequently solved (e.g., by Figure 2 A detailed explanation of an example single-scenario, multi-case optimization process is provided in Section 1 of the Appendix below, while a detailed explanation of an example multi-scenario, multi-case optimization process is provided in Section 2 of the Appendix below. Section 3 of the Appendix presents multiple trajectory solutions obtained for an example optimization problem during takeoff of aircraft 10.

[0146] References to subsection 1.1 of the Appendix Figure 9The general structure of the formulation of an example single-scenario multi-case optimization problem using a multi-stage trajectory optimization process for a portion of a flight (e.g., for determining a single trajectory solution TS1) is described. In this example, the trajectory solution TS1 is determined based on only one scenario and three cases. These cases include Figure 6 A nominal takeoff condition corresponding to the nominal condition N in FIG. 1 (e.g., a nominal or non-emergency condition without any critical failure associated with the aircraft 10), and Figure 6 The first emergency situation corresponding to the first emergency situation ET in v1 (e.g., the emergency situation covering the failure of a critical engine under v1 and the subsequent decision to continue with the takeoff despite the engine failure), and Figure 6 The second emergency situation corresponding to the second emergency situation ER in v1 (e.g., an emergency situation covering a critical engine failure under v1 and a subsequent decision to reject takeoff). As illustrated in subsection 1.1 of the Appendix, each scenario may include multiple phases or sections, which may represent certain segments of the vehicle path according to each scenario. Some or all phases of one scenario may also exist in another scenario.

[0147] References to subsection 1.1 of the Appendix Figure 14 The general structure of the formulation of an example multi-scenario multi-case optimization problem using a multi-stage trajectory optimization process for a portion of an aircraft's flight (e.g., for determining a single trajectory solution TS1) is described. In this example, the trajectory solution TS1 is determined based on three scenarios and three cases. Similar to Figure 9 , these situations include Figure 6 A nominal takeoff condition corresponding to the nominal condition N in FIG. 1 (e.g., a nominal or non-emergency condition without any critical failure associated with the aircraft 10), and Figure 6 The first emergency situation corresponding to the first emergency situation ET in v1 (e.g., the emergency situation covering the failure of a critical engine under v1 and the subsequent decision to continue with the takeoff despite the engine failure), and Figure 6 The second emergency situation corresponding to the second emergency situation ER in v1 (e.g., the emergency situation covering the failure of a critical engine under v1 and the subsequent decision to reject takeoff). However, Figure 9 Different, the scene includes a nominal scene (eg, the zeroth scene), a first scene S1, and a second scene S2, as described above with reference to Figure 6 described.

[0148] To solve the example multi-scenario multi-case optimization problem, a trajectory solution TS1 can be found that not only optimizes the target parameter or each target parameter in the zeroth scenario, but also ensures that the aircraft is in all other scenarios (e.g., Figure 6 and Figure 14Thus, using a multi-scenario multi-case optimization problem to find (e.g., determine) a trajectory solution has the following benefits: it facilitates improving vehicle performance during the trip and ensuring that safety requirements are met regardless of the uncertainty associated with the one or more constraint parameters defining the multiple scenarios. To achieve this, each of the scenarios SN, S1, S2 is subject to an inter-scenario constraint. The inter-scenario constraint stipulates that the portion of the trajectory solution that is input to each scenario at each stage is the same. This can be referred to as providing a common input solution (or identical input solution) to each scenario, as also provided by Figure 14 As shown in and described in more detail in subsection 1.1 of the Appendix.

[0149] By having a common input solution, this means that different scenarios can have:

[0150] Common input trajectories as a function of time. For example, thrust schedules and / or

[0151] or airspeed planning;

[0152] Common schedules of input variables that are functions of state / input variables rather than time. For example, to achieve thrust based on the same schedule relative to airspeed; and / or

[0153] Common input strategy. The input strategy can include multiple different elements, with the key idea being that the actions / decisions required by the human operator and / or automated control system are the same in every scenario. For example, different scenarios can have the same input strategy in the following ways:

[0154] - first there is a segment where the scenarios have the same thrust plan as a function of time,

[0155] - then maintain the last thrust command from the human operator / automated control system until the specified airspeed target has been achieved, and

[0156] -The same thrust profile is then made a function of airspeed.

[0157] If no feasible solution can be found for the multi-scenario multi-case optimization problem, this implies that there is no trajectory solution that will satisfy the or each constraint parameter for all scenarios that have been considered. This, in turn, may indicate that the constraint parameters defining the scenarios are too stringent / conservative, and therefore different constraint parameters may be used to define at least some of the scenarios.

[0158] The method 500 also includes, at box 530, a step of providing (e.g., outputting) information about (e.g., associated with) the determined or each determined trajectory solution STS for consideration, approval, and / or selection by a decision maker. The decision maker may be a user of the aircraft 10 (e.g., a flight crew member of the aircraft 10) or another user (e.g., a flight dispatcher). The information may be provided / output to a trade support tool configured to assist the decision maker in planning the trajectory of the aircraft 10. In an embodiment of the method 500, this step includes causing the information about the determined or each determined trajectory solution STS to be displayed on a graphical user interface (GUI) forming part of the trade support tool. In another (e.g., additional or alternative) embodiment, this step includes causing the information about the determined or each determined trajectory solution STS to be displayed in the form of a readout, list, graph, contour map, schematic diagram, trajectory visualization, etc.

[0159] Figure 8 An example of a format is shown that enables information about the or each determined trajectory solution STS to be displayed on a GUI in an embodiment of method 500. The format is in the form of a graph 800 defined by an x-axis 801 corresponding to a first target parameter (labeled "Target 1") and a y-axis 802 corresponding to a second target parameter (labeled "Target 2"), for each of which the or each trajectory solution STS was determined at step 520. In this example, the first and second target parameters being optimized means that each target parameter has been minimized.

[0160] exist Figure 8 In the example of , information about each trajectory solution is shown as a plurality of data points DP1, DP2, DP3, DP4, each of which is associated with a corresponding trajectory solution in the set of trajectory solutions STS determined at step 520. Figure 8 In an embodiment of the related method 500, the set of trajectory solutions includes: a first trajectory solution, a second trajectory solution, a third trajectory solution, and a fourth trajectory solution, wherein each of these trajectory solutions has been described above with respect to Figure 6 The position of each data point DP1, DP2, DP3, DP4 corresponds to (eg, indicates) the value of the target parameter for which the corresponding trajectory solution was determined in the previous step of method 500. Figure 8As shown, each data point is a coordinate, where each ordinate is a value of a target parameter, and the display thus indicates to the user at least one trajectory where the first target parameter and the second target parameter are at specific (optimized in some manner) values. The user can then evaluate which trajectory they wish to select based on the at least one trajectory (e.g., based on a desired trade-off). In other words, it can be said that the information displayed at block 530 regarding each determined trajectory solution includes an indication of the value of each target parameter (e.g., both the first target parameter and the second target parameter) used to determine each trajectory solution. In yet another embodiment, a vehicle trajectory solution can be determined based on a target parameter (e.g., maintaining a fuel efficiency threshold level above a predetermined threshold during flight, minimum time to destination, etc.), and an indication of that trajectory can be displayed (in the form of data points), in which case the operator can see exactly one way (or, if multiple data points are displayed, multiple ways) in which the target parameter can be optimized to control the vehicle according to the trajectory defined by the trajectory solution. This display allows the operator to confirm that they wish the vehicle to be operated in such a manner to achieve the displayed value of the target parameter. Figure 8 An example of calculating at least one trajectory (and thus displaying at least one data point) based on a tradeoff between two target parameters is shown (hence the diagram being a 2-dimensional diagram). Thus, once the method has determined a vehicle trajectory for achieving certain tradeoffs between the target parameters, data points indicative of these tradeoffs can be displayed to the operator for confirmation that they wish the vehicle to be operated according to a trajectory that achieves a selected preference between the target parameters. In this manner, the operator can select a method for controlling the vehicle to achieve an acceptable tradeoff under various circumstances, such as between fuel consumption, fuel efficiency, time to destination, maintaining the useful life of one or more components, engine performance, engine durability, maintenance costs, other operating costs, and the like.

[0161] In this embodiment, the first trajectory solution is an "extreme" trajectory solution, in which the first objective parameter has been fully optimized (and, in this case, therefore minimized as desired), and therefore DP1 is positioned at the far left on the diagram 800. Conversely, in this embodiment, the fourth trajectory solution is also an "extreme" trajectory solution, but in which the second objective parameter has been fully optimized (and, in this case, therefore minimized as desired), and therefore DP4 is positioned at the far bottom on the diagram 800. Furthermore, in this embodiment, the second and third trajectory solutions are "intermediate" trajectory solutions, in which neither the first nor the second objective parameter has been fully optimized, but in which both the first and second objective parameters have been partially optimized according to different levels of relative importance attributed to each according to the trade-off preferences based on which the second and third trajectory solutions are determined at block 520. Thus, those skilled in the art will appreciate that one or more of these solutions may be Pareto efficient as discussed above.

[0162] exist Figure 8 In the example of , an optimal trade-off curve 810 is plotted on diagram 800. The optimal trade-off curve 810 may therefore include a Pareto front of the set of trajectory solutions STS relative to the first target parameter and the second target parameter. Therefore, the optimal trade-off curve 810 may be referred to as a Pareto curve. The optimal trade-off curve 810 can be generated in a variety of different ways, including, for example, directly interpolating between different trajectory solutions TS1, TS2 in the set of trajectory solutions STS. If so, the interpolation may utilize an approximate model (e.g., a fitted, machine-learned model) based on a broad set of previously determined optimization solutions and / or relevant historical data. Therefore, the example of method 500 may include: determining a Pareto front or a set of data points representing the trade-off between two (e.g., a pair of) target parameters for which each trajectory solution is determined, and it should be understood that each point on the Pareto front represents a vehicle trajectory.

[0163] Therefore, each trajectory solution in the group of the set of trajectory solutions STS, about which information is output at block 530, may comprise a Pareto efficient solution. This means that, for each trajectory solution forming part of the set of trajectory solutions STS, no other solution has been identified that is more optimal for both the first objective parameter and the second objective parameter. Consequently, each trajectory solution forming a group of the displayed set of trajectory solutions STS may be described as a non-dominated solution, where any dominant solution in the set of trajectory solutions STS is not displayed as such.

[0164] Method 500 also includes, at block 540, receiving an indication of a selection made by the decision maker regarding the information provided at block 530. The indication may be received from a trade support tool similar to that described above with reference to block 530. This step may include providing the flight dispatcher / flight crew with a selection regarding the final trade preferences and / or final trajectory solution to be followed by the aircraft 10. The indication may include an input indicating one of the trajectory solutions and may be an electronically transmitted signal or an electromechanical signal. A user may, for example, select a point on a touch screen (on which diagram 800 is displayed as part of a GUI) to select one of the displayed trajectories.

[0165] In some embodiments, the decision maker's choice may be a Figure 8 The described trade support tool may include verification / selection / approval of one of the set of trajectory solutions STS presented to the decision maker. For example, the decision maker may select one of the data points DP1-DP4, and this may correspond to a selection of a relevant trajectory solution (e.g., a corresponding set of trajectory parameters). In other words, the method 500 may include receiving, via the trade support tool, an input indicating a selection of one of the indications of the pair of target parameter values for each trajectory solution determined at block 520 (e.g., a selection of one of the data points DP1-DP4). A trajectory solution in the trajectory solution STS that is verified / selected / approved in this manner may be referred to as a selected trajectory solution.

[0166] In other embodiments, the selection may be a final trade-off preference, an indication of which is received from the trade-off support tool when the user provides input relating to a desired trade-off between a first objective parameter and a second objective parameter. For example, the user may indicate a position along the optimal trade-off curve 810 corresponding to their selection of the final trade-off preference (through interaction with the graphical user interface of the trade-off support tool, such as by using a touchscreen capability of the trade-off support tool or by using its cursor). This can be described as receiving input selecting a value for each objective parameter that is not equal to the value of the corresponding objective parameter for which the first, second, third, and fourth trajectory solutions were determined. In this case, as indicated by the dashed box, method 500 may include, at block 520, determining another trajectory solution based on the user input selecting a point on the curve that is not equal to one of the displayed data points. Given that the first and second trajectory solutions have already been determined at block 520, this further trajectory solution may represent a third trajectory solution for the aircraft 10, similar to the trajectory solutions described above with respect to block 520, but this time based on the user's selection of a final tradeoff preference, rather than based on the user's selection of a tradeoff preference for determining the or each trajectory solution determined at block 520. Information regarding the improved trajectory solution determined at block 520' may then be presented to the decision maker for confirmatory verification / selection / approval via a tradeoff support tool as discussed above. If subsequently verified / selected / approved by the user, the improved trajectory solution may be referred to as a selected trajectory solution. In this manner, the tradeoffs between the target parameters and the trajectory solutions according to which the vehicle may operate may be improved (e.g., on the fly).

[0167] Furthermore, the method 500 includes, at block 550, causing the aircraft 10 to be controlled according to the selected trajectory solution. To this end, block 550 may include causing the aircraft 10 to be controlled according to the trajectory solution associated with the indication selected at block 540 (such as the selection of one of the data points DP1-DP4). Otherwise, block 550 may include causing the aircraft 10 to be controlled according to another trajectory solution determined in response to receiving input selecting a value for each target parameter that is not equal to the value of the corresponding target parameter with respect to which the trajectory solution was determined at block 520. In some embodiments, the data processing device executing the method 500 may form part of an automatic flight control system (AFCS) configured to control the operation of the aircraft 10 during flight with or without human supervision and / or human intervention. For example, the AFCS may be configured to cause actuation of various control surfaces provided to the aircraft 10, operation of the thrusters 101, and / or other features of the aircraft 10 necessary to control its flight. To this end, the AFCS may be coupled to a separate electronic controller for the thrusters 101 (e.g., the controller described above with reference to FIG. ). Figure 2 The EEC 117 described above performs data communication.

[0168] A processor implementing the method may be configured to determine a trajectory solution for a given situation subject to constraints defined by the scenario by executing (e.g., solving) a dynamics optimization algorithm (e.g., as described in the Appendix). For example, a processor implementing the method may be configured to solve, for each scenario, an equation of the form (19a) subject to constraints similar to those described in (19b-i).

[0169] That is, the processor may be configured to solve equations of the form:

[0170]

[0171] Subject to similar constraints as set forth in equations (19b-i) of the Appendix, and where Φ is the general cost function. The symbols mentioned above are also defined in the Appendix.

[0172] The trajectory solutions discussed herein may be calculated on the fly in response to input or stored data, or may be calculated and stored in memory as discussed above. In the latter example, the method may include retrieving a stored trajectory solution and controlling the vehicle according to the retrieved trajectory solution.

[0173] In embodiments of the method 500 that do not include the features described above with respect to blocks 530, 540, and 550 (e.g., where the flight dispatcher / flight crew is not provided with a selection regarding the final trade-off preference and / or the final trajectory solution that the aircraft 10 will follow in this manner), the or each trade-off preference used as part of the features described above with respect to block 520 may be pre-configured by an operator of the aircraft 10 (e.g., a commercial operator such as an airline) or pre-determined / updated / managed by a service contract provider. However, in such embodiments, the flight crew and / or flight dispatcher may still be able to make a final selection regarding whether the aircraft 10 will follow the candidate trajectory or any of the candidate trajectories determined by the method 500, by making a final selection regarding which of the candidate trajectories the aircraft 10 will follow by appropriate means.

[0174] The methods described herein facilitate planning a route (e.g., a trajectory) for a vehicle (e.g., an aircraft) that can be customized based on specific conditions associated with a given trip (e.g., a flight). The methods described herein also enable updating a planned route (e.g., a trajectory) during travel (e.g., in flight) if any of the flight-related conditions change.

[0175] In addition, the determination of the or each trajectory solution in the method described herein need only comply with the at least one scenario and the at least one condition (e.g., the original set of mission requirements). This allows the method described herein to be unaffected by heuristically designed flight rules, as is the case in various previously considered methods. Furthermore, the method described herein enables any additional potential benefits associated with specific flight-related conditions to be automatically obtained and realized. These benefits may include reduced component wear, reduced fuel / energy consumption, reduced emissions, and / or reduced flight time.

[0176] In addition, the methods described herein can utilize a wide range of information regarding, for example, flight vehicle dynamics / characteristics, power plant dynamics / characteristics, operating limitations / constraints, safety limitations / constraints, atmospheric and environmental conditions (such as airport and runway conditions), and air traffic requirements to produce customized trajectory solutions / candidate trajectories for operation of the flight vehicle and its power plant.

[0177] Various embodiments of the method described herein meet the needs of flexible trade-off evaluation between multiple conflicting objectives. That is, the present disclosure considers the joint optimization of vehicle routes (e.g., flight trajectories) and power plant operations, which is essentially a multi-objective problem and may require trade-offs between conflicting objective parameters, and the best choice may also vary from flight to flight. Using "task groups" in the manner described herein allows calculation of trajectory solutions optimized for different trade-off preferences regarding these conflicting objectives. These optimized trajectory solutions are then concentrated in a task group and allowed to be used with trade-off support tools that relevant decision makers can use to select the most appropriate trajectory for a given single flight. This provides increased operational flexibility, which can be beneficial in flight planning at the fleet level, such as to assist in restoring network stability in the event of flight interruption due to various reasons.

[0178] Furthermore, the methods described herein can ensure robust satisfaction of safety and operational requirements. Unlike previously considered itinerary (e.g., flight) planning methods that attempt to manage safety considerations by adopting highly conservative solutions, the methods described herein allow for a more systematic approach to ensuring that safety and operational requirements are met.

[0179] The method described herein also provides for determining candidate trajectories using simultaneous consideration of (e.g., based on both) (i) multiple conditions, optionally including both nominal and emergency conditions, to ensure that feasible trajectory solutions exist for restoring the aircraft to safety in the event of some deemed safety-critical failures; and / or (ii) multiple scenarios, optionally with different definitions based on uncertain constraint parameters that may arise in real-world operations, to allow for more robust implementation of safety and operational considerations. Thus, time-varying candidate trajectories can be determined in a manner that takes into account a wide variety of relevant factors.

[0180] Various examples have been described, each featuring various combinations of features. Those skilled in the art will understand that, unless clearly mutually exclusive, any feature may be used alone or in combination with any other feature, and that the present invention extends to and includes all combinations and subcombinations of one or more features described herein.

[0181] It should also be understood that while the present invention has been described with reference to aircraft and aircraft propulsion systems, the methods described herein may be used in many other applications including, but not limited to, automotive, marine, and land-based applications.

[0182] appendix

[0183] 1 Example: Single Scenario Multiple Situation Optimization

[0184] When designing a takeoff trajectory, there are many safety-related considerations. To aid the flight crew's decision-making process, several safety-critical reference airspeeds (referred to as V-speeds) are calculated as part of the takeoff preparation procedure. Arguably the most important of these is the decision speed, V1.

[0185] An engine failure during takeoff is considered one of the most critical scenarios to consider, as the reduction in thrust will directly impact the aircraft's ability to accelerate and climb safely. Therefore, v1 is determined using the concept of balanced field length (BFL) based on this critical engine failure scenario. As the aircraft accelerates down the runway, the remaining runway distance required to complete the takeoff with one engine inoperative decreases, while the distance required to bring the aircraft to a complete stop on the runway increases. At some point, these two distances will be the same, and the corresponding airspeed is denoted as v1. This airspeed is called the decision speed for the following reasons:

[0186] If a critical failure occurs before v1, it is better to abort the takeoff (also known as a rejection), and

[0187] If a critical failure occurs after v1, it is best to continue takeoff in the presence of the failure.

[0188] Therefore, when designing a solution trajectory for a nominal takeoff, emergency scenarios must also be considered to ensure safety. A common choice is to consider the scenario of an engine failure occurring precisely at v1. By ensuring flight safety for the two subsequent decisions to continue or abort in this critical scenario, operational safety is maintained even if this engine failure occurs in all other takeoff scenarios.

[0189] This work focuses on the formulation and solution of a multi-stage dynamic optimization problem that systematically accounts for these critical situations by computing the corresponding trajectories and the trajectory for nominal takeoff. Having accurate solutions for these critical situations ensures safe aircraft operation while minimizing the impact on the optimality of the solution. However, as a flexible framework, these additional situations can be replaced by appropriately formulated constraints based on empirical formulas, if preferred.

[0190] 1.1 Problem Structure

[0191] Figure 9 The multi-stage structure of the takeoff trajectory optimization problem considered in this work is highlighted. The nominal (N) takeoff trajectory consists of 5 stages:

[0192] N1a: Accelerate from the starting position on the runway to the decision speed v1,

[0193] N1c: After passing v1, continue to accelerate to the nose-up speed v R ,

[0194] N2: Raise the nose of the aircraft until it is airborne, i.e. raise the nose of the aircraft through flight control inputs.

[0195] Until the plane leaves the ground,

[0196] N3a: Continue climbing over the runway and before reaching the end of the runway, cross the runway barrier altitude (AGL, i.e., altitude above ground level) by 35 ft.

[0197] N3b: Initial climb to acceleration altitude, usually 1500 ft AGL.

[0198] For an engine failure occurring under v1 and the subsequent decision to proceed (case ET), the remaining phase structure will be the same as in the nominal case, which requires the aircraft to cross the barrier altitude and climb to the acceleration altitude before the end of the runway. However, for the subsequent rejection decision (case ER), phase N1a will be followed by the following two phases:

[0199] ER1a: Despite the change in thrust output due to the engine failure, the aircraft continues to accelerate along the runway for an additional few seconds (e.g., 2 seconds) to allow for the time necessary for the flight crew to recognize the failure and take action.

[0200] ER1b: Throttle the engines back to idle and apply maximum brakes to bring the aircraft to a complete stop on the runway.

[0201] Therefore, based on different situations, the different stages in the single-scenario multi-scenario trajectory optimization problem can be classified by N, ET and ER accordingly. Figure 9 The stages are categorized by the progression of manipulation shown by dividing lines from left to right.

[0202] 1.2 Formulation of the dynamic optimization problem

[0203] Note that in this multi-stage setup, different kinetic equations and constraints will apply to different stages. To assist in presenting the mathematical equations, the time interval The time variable t (k) Define the stage index k, where and Represent the initial time and final time of the interval respectively. The stage index k is as follows Figure 9 An enumeration of the stage markers that are rendered. For example, the expression (in ) represents all time instances in phase N1a. If not specified, t is used instead of t (k) , and and are omitted in the expression for the sake of simplicity For example, the phases can be further grouped into different categories, e.g. for ground taxiing And for nominal takeoff, All nominal takeoff phases except phase N1a will be indicated.

[0204] 1.2.1 Kinetic equations

[0205] The dynamic equations for an aircraft rolling down a runway (i.e., for all )for:

[0206]

[0207] The state variable d is the distance traveled, v TAS is the true airspeed, m is the mass of the aircraft, F n is the net thrust, and the input variable F r is the requested thrust. In addition, v 风is the wind speed in the direction of travel, where the headwind is positive (only constant wind speed is considered in this work, as in the current takeoff calculation), D is the drag, g is the acceleration due to gravity, and w fi is the fuel flow rate (where w fi is the fuel flow of the i-th engine), n EG is the number of engines installed on the aircraft, T f is the time constant of the engine thrust response, and Here, we only consider the effect of runway slope on the acceleration performance of the aircraft, where It is usually small and the corresponding changes in the aircraft's altitude and pitch angle can be considered negligible.

[0208] During the nose-up period, that is, for all System dynamics will have additional elements,

[0209]

[0210] Where α is the angle of attack and θ is the pitch angle. Because the aircraft has not yet left the ground and the effect of the runway slope on altitude and pitch is ignored, α(t) = θ (k) (t) holds true. θ rot Indicates the rate of pitch angle change performed by the pilot during a nose-up, which is typically 3 degrees per second. Figure 10 A schematic diagram of an aircraft during this portion of takeoff is shown in FIG.

[0211] Once off the ground, that is, for all The kinetic equation is

[0212]

[0213] where γ is the flight path angle, and as a state variable, the pitch angle θ is now used as input, and the angle of attack is correspondingly defined as α(t) = θ (k) (t)-γ (k) (t).h, is the altitude of the aircraft, and L is the lift. Figure 11 A free-body diagram for this portion of the flight is illustrated.

[0214] The evaluation of the kinetic equations makes extensive use of a lookup table denoted by Ξ, which for the following atmospheric parameters: pressure p, speed of sound a, density ρ, and temperature T yields

[0215] p(t)=Ξ p (h (k) (t)),

[0216] a(t)=Ξ a (h (k) (t)),

[0217] ρ(t)=Ξρ(h (k) (t)),

[0218] T(t)=Ξ T (h (k) (t)).

[0219] And, for the following other aerodynamic and engine parameters: zero lift drag coefficient Zero angle of attack lift coefficient lift coefficient slope Change in lift coefficient per unit deflection of a high-lift device Change in drag coefficient per unit deflection of a high-lift device Maximum net thrust Minimum net thrust Reference value of engine speed for low-speed shaft Reference value of fuel flow w fref and reference values of turbine gas temperature (TGT)

[0220] will get

[0221]

[0222] M is calculated as Mach number, and is the reference value of net thrust.

[0223] The relationship between the reference engine parameters and the original parameters is as follows:

[0224]

[0225] where δ EG and θ EG is defined as

[0226]

[0227] p sl,ISA and T sl,ISA are the sea level pressure and temperature at International Standard Atmosphere (ISA) conditions, and κ is the ratio of specific heats of air.

[0228] Next, the lift and drag of an aircraft are defined as

[0229]

[0230] Among them S w,ac is the reference wing area of the aircraft, μ 滑跑 is the friction coefficient during sliding, and μ 制动 is the braking coefficient. C L and CD are the lift coefficient and the drag coefficient, respectively, and they are modeled as

[0231]

[0232]

[0233] where δ f is the deflection angle of the high lift device, φ is the factor considering the ground effect, b w,ac The wingspan of the aircraft

[0234]

[0235] and in is the aspect ratio, and e is the Osward factor.

[0236] 1.2.2 Constraints

[0237] The trajectory optimization method proposed in this disclosure is a flexible framework that allows specifying different regulatory and operational constraints directly in the problem formulation. Here, we use a simplified yet representative setting derived from airworthiness requirements.

[0238] The reference airspeed is defined as a preliminary step in the constraint definition

[0239]

[0240] where m TO is the mass of the aircraft at takeoff weight, ρ RW is the air density at the runway, and C Lmax is the maximum lift coefficient.

[0241] The solution to the optimization problem is subject to the following main path constraints:

[0242]

[0243] where d RWn is the nominal usable runway length. TGTmax is a static variable representing the maximum TGT and is part of the decision variables. min,T OCLB is the minimum flight path angle corresponding to the minimum climb gradient requirement during the initial climb. max is the maximum angle of attack the aircraft is allowed to achieve during nominal operation, and θ max is the maximum allowed pitch rate.

[0244] The rationale behind these path constraints is mostly straightforward. The one that requires some explanation is (9e). Following an engine failure, airworthiness requirements require that a safe takeoff be ensured without changing the throttle position for the remaining operating engine until the runway barrier is crossed. Similarly, reasonable delays in pilot action must be considered in the event of a rejection. The rate constraint (9e) ensures that no throttle adjustments are made initially after a failure.

[0245] Next, some key boundary constraints in the setting are given:

[0246]

[0247] where v LOF is the lift-off speed v FTO is the final takeoff speed, h RW is the altitude of the runway, h 屏障 is the runway barrier height, h acc is the acceleration altitude, t 动作 is the pilot action time after the engine failure. Except for the very beginning, all time variables are free.

[0248] Finally, there are connection constraints that link different stages. Figure 1 As shown, most of them simply enforce the continuity of state and input trajectories and time variables according to the overall structure. In the case of engine failure, that is, when connecting phase N1a with phases ET1 and ER1a, the following constraints are used:

[0249]

[0250] It assumes that immediately after an engine failure event, some thrust is lost Then (11b) and (9e) together ensure that after a failure, the thrust will converge to a condition where the failed engine is no longer functional and will remain in that condition until further action is taken by the flight crew. In addition, we have

[0251]

[0252] Forced nose lift speed v R same.

[0253] 1.2.3 Optimization settings for independent problems

[0254] With all components in place, the high-level abstraction of the single-scenario multi-case takeoff trajectory optimization problem can be expressed as

[0255]

[0256] Subject to,

[0257]

[0258] in is the continuous state trajectory of the system in one stage, is the input trajectory in stage , and For decision variables, x(·) represents the state trajectory segment in all stages, u(·) represents the input trajectory segment in all stages, t0 represents the vector of initial times in all stages, and t f A vector representing the final times of all stages.

[0259] In addition, f defines equality constraints related to the ODEs of the system in different stages (f: Define equality constraints related to the DAE of the system in different stages Define inequality path constraints in different stages Define the boundary conditions of the equations in different stages Define inequality bound constraints in different stages And Φ L Define connection constraints enforced across different stages In this single-scenario problem, the only static parameter is T TGTmax By minimizing this parameter in the objective subject to (9b), the goal of minimizing the maximum TGT along the nominal trajectory is achieved. The other terms in the objective are regularization terms, where the weights w r and w t is chosen so that In other words, with the same minimum T TGTmax Among the different possible solutions of The solution is preferred for smooth thrust variation, and the solution that will result in the shortest climb time after a critical engine failure is preferred for enhanced safety.

[0260] 1.3 Numerical solution of dynamic optimization problems

[0261] The continuous-time infinite-dimensional takeoff dynamics optimization problem (13) can be solved numerically using a choice of numerical methods. One of the most popular methods is called the direct transcription method, which first discretizes the continuous trajectory into multiple segments of piecewise approximation functions (e.g., polynomials) that can be described using multiple static parameters as optimization decision variables. Constraints are then formulated to enforce approximate satisfaction of the dynamic equations, path constraints, and boundary conditions. For example, one of the most commonly used methods is the direct collocation method, which forces the residual errors of the differential equations and the constraint violation errors to zero at a few selected locations (called collocations) on a discrete grid. Subsequently, a nonlinear programming problem (NLP) can be formulated and solved to produce an approximate solution to the original continuous problem.

[0262] 2 Examples of Multi-Scenario and Multi-Situation Trajectory Optimization

[0263] One of the main challenges in directly implementing trajectory optimization solutions in the real world is dealing with different uncertainties that may affect the actual performance and constraint satisfaction.

[0264] For nonlinear and non-regular problems, solving the optimization problem online in a closed loop is challenging due to the associated computational complexity and the lack of sufficiently general proofs regarding the convergence of the numerical solvers, the recursive feasibility of the problem formulation, and the stability in the closed loop. The takeoff trajectory optimization problem is further complicated by its multi-stage structure, which needs to accommodate changes in the system dynamics in different parts of the flight and allow for the simultaneous consideration of different fault scenarios.

[0265] More importantly, updating the solution online would require significant process changes. As one of the most safety-critical parts of the flight, the takeoff process requires the crew to plan ahead for different actions in different eventualities, typically in the form of a takeoff briefing. Therefore, it is important to keep the takeoff strategy fully transparent to the flight crew in advance and let them make the final decision. In this regard, multi-scenario optimization methods, which focus on enhancing the robustness of the solution without procedural changes, are considered the preferred approach for takeoff trajectory optimization.

[0266] In this section, we first demonstrate that the ground taxi portion of flight possesses a property known as monotonicity, which allows for the easy selection of several representative scenarios to be used in multi-scenario optimization. We then address the challenge of mismatched time intervals between corresponding phases of different scenarios by utilizing thrust scheduling as a function of airspeed. Finally, we present a robust formulation of the takeoff trajectory optimization problem, highlighting its differences from previously proposed standalone problems.

[0267] 2.1 Monotonicity Analysis

[0268] Arguably, the greatest computational cost of multi-scenario optimization is the number of scenarios to consider. For dynamical systems, adopting restrictive values for uncertain parameters and input trajectories often does not lead to extreme state trajectories. Therefore, to ensure performance and constraint satisfaction for all possible outcomes, a large number of scenarios with different configurations of uncertain parameters must be considered.

[0269] A special case arises when the dynamical system exhibits the property of monotonicity, where the number of scenarios regarding the uncertain parameters can be significantly reduced. A brief description is provided in this paper.

[0270] For n-dimensional dynamical systems

[0271] Two different initial conditions and Can be sorted To describe, where K is an ordered Banach space In a positive cone (e.g., the Euclidean space considered in this work), this ordered Banach space has the following properties:

[0272] Strict ordering instructions and Can be expressed as

[0273] Two different input trajectories u in the input space U * and Can be sorted To describe, where K u is an ordered Banach space The corresponding positive cone in Strict ordering can be expressed as For the input function in the typical Lebesgue measure for control problems,

[0274] Any static parameter p in (13) can be considered as an input whose rate of change is constrained to zero, so for ease of analysis, it will not be treated separately here. If the following conditions exist, then the dynamic system is considered monotonic:

[0275]

[0276] in In the initial state And the state x(·) obtained at time t when the input is u*(·).

[0277] exist and In the special case of , the system is called a cooperative system. For more general systems, states or inputs can have monotonic behavior, but with opposite trends. Therefore, it may be useful to define a higher-dimensional quadrant (orthant)

[0278]

[0279] where a binary vector σ=(σ1,...,σ n )∈{0,1} n and Then, to show that the system is monotonic, we need to find a high-dimensional quadrant where the following property holds:

[0280]

[0281] For the takeoff trajectory optimization problem, we first analyze the ground taxiing (1). To define the high-dimensional quadrant, we set: for all states in this phase, σ = (0, 0, 1, 0), that is, according to (1) d, v TAS , m and F n As for the input variables of the system, we expand the vector to include more variables that may be uncertain, and the effect of uncertainty on the state trajectory is of interest. Here, we choose the required thrust F r , friction coefficient μ 滑跑 or μ 制动 , wind speed v 风 and runway slope And set The system can then be shown to be monotonic based on the following relationship:

[0282]

[0283] It is based on the following assumptions:

[0284] If all else is equal, then v TAS The increase in will lead to an increase in fuel flow,

[0285] Runway slope angle Smaller.

[0286] The analysis can be extended to the nose-up phase of flight (2). For simplicity, a fixed deterministic but It can also be considered as a static uncertain parameter. If for state d, V TAS ,m,F n and θ, we set σ=(0,0,1,0,1), and for F r 、μ 滑跑 、v风 、 and We set We can obtain the following assumptions:

[0287] During nose-up, the reduction in frictional drag (and hence the increase in lift and hence the reduction in normal force) due to the increase in θ is the dominant effect in the acceleration performance of the aircraft.

[0288] When the system is monotonic, for the uncertain parameter μ 滑跑 、μ 制动 、v 风 、 and It will be sufficient to consider a single worst-case scenario. In other words, if all else (other problem parameters and input trajectory) is the same, the case for the longest accelerate-stop distance will be the following: During the acceleration, take μ 滑跑 and During deceleration, μ 制动 and The lowest value of v 风 The lowest value and Similarly, the worst-case initial conditions for the takeoff problem in terms of required runway length are the following: TAS (t0) takes the lowest value and m(t0) takes the highest value.

[0289] Furthermore, because the system is monotonic, the necessary corrections to the input trajectory to meet performance requirements are straightforward. For example, in a takeoff problem, the ground distance and time required to accelerate the aircraft to a given airspeed can be reduced by simply increasing thrust (unless the thrust is limited by the maximum available thrust). Therefore, safety risks can be easily mitigated even in situations where actual acceleration performance is more unfavorable than the considered worst-case scenario.

[0290] While monotonicity can be shown for the on-ground phase of a flight, this is typically not the case once the aircraft lifts off. However, when considering takeoff calculations, runway length requirements are often the most critical aspect, as it is highly unacceptable if the actual takeoff ground operations differ significantly from the predicted ones. Therefore, in this work, we primarily focus on designing worst-case scenarios for acceleration and deceleration performance in terms of required time and runway length.

[0291] 2.2 Handling of Mismatched Time Intervals

[0292] In traditional multi-scenario optimization design combined with monotonic system dynamics, the basic principle of the worst-case scenario is based on having the same fixed initial time t0 and end time t in all scenarios. f However, like many real-world applications, our takeoff trajectory optimization problem does not have a fixed end time in the problem structure; therefore, the time intervals for different scenarios will also be different. Therefore, the input trajectories across different scenarios may not be exactly the same (i.e., the "if all else is equal" principle described in the previous section becomes unrealistic), which in turn suggests the use of the monotonicity property.

[0293] In order to maintain the theoretical benefit of allowing a single worst-case scenario for a monotonic system, a new set of input trajectories can be designed for the worst-case scenario. For this new trajectory, u(SN)(t)≥u(SW)(t) must be constant for the shared time interval holds for all t above, where SN corresponds to the nominal scenario and SW corresponds to the worst-case scenario. Then, depending on the design of the endpoint conditions (e.g., meeting some airspeed requirements) and the signs of the variables in the high-dimensional quadrant in the monotonicity analysis, additional requirements will also apply to the worst-case scenario end times.

[0294] For example, for the takeoff optimization problem in this work, the input trajectory in the worst-case scenario must be chosen such that

[0295] in and in corresponds to the nose-up phase in the nominal scenario, and Corresponding to the nose-up phase in the worst-case scenario.

[0296] Despite having better theoretical properties, constraints such as (17) may be difficult to implement because at a given time instance and can belong to different instances occurring within different phases. Furthermore, implementing such constraints can lead to significantly different flight strategies in different scenarios when the time intervals vary widely. This violates the fundamental concept of multi-scenario optimization methods, which implement the same input solution for different scenarios with different uncertainty modeling.

[0297] 2.2.1 Thrust planning relative to airspeed

[0298] In actual takeoff executions, the aircraft trajectory solution (e.g., the aircraft's thrust and pitch angle) is not implemented in a typical open-loop fashion, where it is a time-dependent profile. Instead, thrust plans relative to airspeed and altitude are often used; therefore, the design of multi-scenario problems needs to accommodate these implementation differences. This also provides an excellent opportunity to help address the issue of time interval mismatch.

[0299] We adapt the key concept of multi-scenario optimal control design, "same input, different uncertainty, different output," to a specific implementation based on "same input strategy, different uncertainty, different output." Therefore, rather than focusing solely on identical input trajectories as a function of time, we can also consider other alternative formats, as long as the actions required by the human operator or the automated system are the same.

[0300] However, for systems with monotonicity properties, this design of input trajectories can potentially lead to situations where the worst-case scenario defined by the uncertain parameters may no longer correspond to the theoretical worst-case scenario for the state trajectory. In general, whether the scenario corresponding to the worst-case parameters will still be the theoretical worst-case scenario depends on how the strategy for the "same input strategy" is designed. For example, in the case of a takeoff roll, if different scenarios share the same thrust schedule relative to the aircraft's mass, the corresponding thrust may also be higher for the initial condition corresponding to the highest mass; therefore, the worst-case initial condition may not correspond to the longest accelerate-stop distance.

[0301] In contrast, if strategies are designed for different scenarios to have the same thrust schedule relative to airspeed, the analysis below shows that the worst-case scenario (SW), formulated in terms of extreme values of the uncertain parameters, will still result in longer acceleration times and distances than the nominal scenario (SN).

[0302] If the size of each segment is infinitesimal, the continuous thrust trajectory can be accurately discretized into piecewise constant segments. TAS,1 to v TAS,1 +δ v The acceleration of Figure 12 Because the scene SW will have, for example, a larger coefficient of friction and a higher mass, the acceleration The value of will be lower than the nominal scenario. Therefore, the acceleration time to reach the same final speed will be longer, which corresponds to Figure 12 The upper right illustration shows that the area under the line is equal in both scenarios.

[0303] Then, when examining the corresponding airspeed profiles over time, it can be seen that, based on the trapezoidal area formula, the area under the line for scenario SW is greater than the area under the line for scenario SN. Therefore, to accelerate to the same final airspeed, scenario SW will need to travel a longer distance in the air. If the wind speed is the same, this will correspond to a longer distance traveled on the ground.

[0304] For scenario SW, wind speed v 风 (positive for a headwind) may be even more unfavorable, for example, if the tailwind is stronger. In this case, the corresponding ground speed is will be higher than Therefore, the increase in ground distance traveled will be even greater for scenario SW compared to scenario SN.

[0305] In summary, this analysis shows that the worst-case scenario defined by the worst-case uncertainty parameters is guaranteed to result in a longer acceleration time and distance if, at all corresponding airspeeds, the corresponding thrust is equal to or lower than that of the nominal scenario.

[0306] 2.2.2 Constraints on trajectory profile geometry across different phases of the scenario

[0307] Since trajectory optimization problems are typically formulated based on time variables and solved numerically on a time grid, it is challenging to directly enforce the same thrust and airspeed schedules across scenarios in the problem formulation. As a possible option, time grid nodes are used as intermediaries to connect constraints associated with different variables in different scenarios.

[0308] We introduce a constraint that enforces the same trajectory profile geometry in different scenarios with mismatched time intervals. The main idea of this implementation is that for trajectories in different phases with mismatched time intervals, if the two phases share the same grid node distribution, then equality constraints can be enforced at the discretized grid nodes, such as Figure 13 As shown in the example. If we use the local coordinate τ∈[0,1] to calculate the time interval of each stage Normalized, each constraint will correspond to the same T value in both phases. In other words, if k1 and k2 are corresponding phases in different scenarios under the same N-node grid design, then the constraints are of the following form:

[0309]

[0310] This ensures that the trajectory profile geometry in one phase is identical to the trajectory profile geometry in another phase, but is scaled proportionally to the difference in time interval size. How this constraint formulation is applied to the multi-scenario takeoff trajectory optimization problem is shown in Section 2.3.2.

[0311] 2.3 Robustness-enhanced takeoff trajectory optimization problem

[0312] 2.3.1 Implementation strategy of trajectory optimization solution

[0313] Consider the following specific implementation, which is derived from real-world flight programs to better suit the execution of trajectory optimization solutions:

[0314] Because airspeed data can be very inaccurate at low speeds, the initial increase in thrust will be applied in an open-loop manner, i.e., on a schedule relative to time, until a reliable airspeed reading (above 30 knots) is achieved.

[0315] To achieve smooth application of engine thrust, open loop control will continue until the maximum thrust command F is applied. r or until the target airspeed corresponding to this maximum thrust command is achieved, whichever occurs first. We refer to this airspeed as the checkpoint airspeed v cpt If at the planned time instance, the airspeed is less than v cpt , the maximum thrust command will continue to be applied until v cpt .

[0316] From the time the checkpoint airspeed is reached until liftoff, thrust will be applied based on the profile relative to airspeed.

[0317] Once off the ground, thrust will be applied based on the profile relative to altitude. Simultaneously, the aircraft's pitch angle will be adjusted to achieve an airspeed profile also formulated relative to altitude.

[0318] 2.3.2 From Independent Problems to Joint Multi-Scenario Problems

[0319] In the formulation of the corresponding multi-scenario trajectory optimization problem (also expressed as a joint problem), we first make some modifications to the independent case. First, the first phase N1a from zero ground speed to the decision speed v1 is split into two parts to accommodate the takeoff procedure, where

[0320] N1a: Acceleration from the starting position on the runway to the checkpoint airspeed, where v cpt ≥

[0321] 30 knots. At this stage, we also need thrust along with additional constraints Increase monotonically.

[0322] N1b: from v cpt Accelerate to reach decision speed v1.

[0323] Next, we copy all the stages to create Figure 14The multi-scenario structure with 3 scenarios is shown in Figure 2. Here, we first focus on the 2-scenario case with a nominal scenario SN and another scenario named S1. Scenario SN will inherit all parameter values used for the original standalone setup, and scenario S1 will have the worst-case scenario (i.e., with the highest μ during acceleration) configured. 滑跑 and Minimum μ during deceleration 制动 and And has the lowest v from beginning to end 风 ) initial conditions and parameters.

[0324] Then, at the stage handover, add a constraint for both scenarios to have the same checkpoint airspeed v cpt , decision speed v1 and nose-up speed v R In this way, the flight crew will only need to work at a single set of decision support speeds. Additionally, we impose constraints of the form (18) across the different phases:

[0325] For liftoff phases N3a and N3b, the required thrust trajectory and airspeed trajectory profile geometries are constrained to be the same across both scenarios. Since these phases also have the same initial and final values of altitude h, the trajectory profile geometry constraints are sufficient to ensure that at each grid node, h, v TAS And the thrust is the same across both scenarios.

[0326] The required thrust trajectory profiles are constrained to be the same for the ground taxi phases N1b, N1c and N2. These phases all have the same airspeed v TAS The initial and final values of , due to explicit boundary constraints, or to the airspeed trajectory profile geometry constraints implemented during the subsequent liftoff phase. Similarly, due to the available degrees of freedom (DoF) of the aircraft on the ground, v TAS and the thrust at each grid node is the same across both scenarios.

[0327] Therefore, appropriate use of constraints of the form (18) ensures that the different scenarios in the takeoff problem (all nominal phases except N1a) share the same thrust schedule relative to airspeed while on the ground, and the same thrust and airspeed schedule relative to altitude once off the ground.

[0328] So far, scenario S1 has exactly the same formulation as the worst-case scenario, based on the worst-case values of the parameters. In conventional problems with matching time intervals, there is usually no practical reason not to use the worst-case setting itself, although any scenario that is no more favorable than the worst-case setting for a multi-scenario optimization setting can still be selected.

[0329] In the case of mismatched time intervals, the situation is slightly different: certain scenario designs can be shown to be slightly more unfavorable than the worst-case scenario, but are easier to implement within the trajectory optimization framework. Therefore, these designs are actually better candidates. Here, this "easier to implement" design is used for the first-stage thrust trajectory in scenario S1.

[0330] For phase N1a, because scenarios SN and S1 have different initial airspeeds due to wind, forcing the thrust trajectory profile geometry to be the same will result in different thrust schedules relative to airspeed, e.g. Figure 15 As shown. At the same time, the thrust trajectory corresponding to the worst case will also be different. This is because the thrust trajectory in this part of the flight will be implemented in an open loop manner with respect to time. We can observe

[0331] Scenario S1 and the worst case scenario share the same TAS Here, we express the initial conditions as

[0332] Even if wind speed is the only difference between the nominal scenario and the worst case scenario, where

[0333] After open-loop realization of the thrust trajectory for scenario SN, the airspeed corresponding to the worst-case scenario will still be less than v cpt The commanded thrust is then held at the last value of the trajectory until v cpt Thus, it can be shown that the worst case requires longer time and runway distance to reach the same final airspeed v cpt ,

[0334] Thrust command F during this phase r Constrained to be strictly monotonically increasing, it can be shown that at each airspeed, the thrust in scenario S1 (i.e., scenario SN trajectory profile geometry scaled based on the time interval of scenario S1) will be no higher than the worst case. Therefore, scenario S1 will require longer time and runway distance than the worst case to complete this portion of the flight.

[0335] In summary, the design of scenario S1 exploits a formulation that will be more easily implemented in a multi-scenario joint optimization problem while providing a tight bound on the worst-case acceleration performance. Therefore, scenario S1 is an appropriate alternative to the worst-case scenario in a multi-scenario optimization setting to ensure safe runway usage under worst-case conditions.

[0336] Further comments on the constraints on thrust trajectories across different scenarios:

[0337] If the actual engine has closed-loop control of net thrust or engine speed, then Fn Constraints between application scenarios,

[0338] If the engine is in open loop control, the F r Apply inter-scenario constraints. If necessary, the corresponding engine speed target plan can then be calculated. In order to use this setting, the following additional assumptions should hold: cpt The difference in thrust dynamic response thereafter (due to the different thrust trajectories previously) is negligible.

[0339] Another technical detail to be addressed is the nose-up portion of the flight. Due to the additional inter-scenario constraints on the airspeed trajectory profile geometry for the liftoff phase, the liftoff speed v LOF This also needs to be the same for all scenarios. To facilitate this, different nose-up rates will be required for phases N2 and ET2 in scenario S1. Therefore, the two static variables and is added to the joint optimization problem as a static decision variable. To ensure that the runway usage in scenario S1 is no more favorable than the worst case in this setting, we can explicitly implement and

[0340] For the initial climb, in the absence of the monotonicity property, the use of a single scenario S1 may not necessarily correspond to the theoretical worst-case scenario in terms of state trajectories. A few comments on this point:

[0341] Multi-scenario optimization design provides robustness enhancement to independent solutions, regardless of whether the additional scenarios are theoretical worst-case scenarios.

[0342] When the input policy remains the same, it is straightforward to set up numerical experiments to verify how the state trajectory is affected by different values of the uncertain parameters. If a monotonic relationship between the state trajectory and the value of the uncertain parameters can be observed in practice, then the scenarios with extreme values of the uncertain parameters can actually be considered as the worst-case scenarios in the multi-scenario optimization setting.

[0343] For many takeoff problems where the climb requirement is specified in relative terms, e.g., the climb gradient requirement (relative change in altitude w.r.t. relative change in position) as used in this work, the formula for the liftoff phase in scenario S1 will be sufficient to show that the aircraft has sufficient excess thrust / power to meet the climb requirement. Thus, even if scenario S1 does not correspond to the worst-case realization of the state trajectory, the climb performance requirement can be shown to be meetable.

[0344] If necessary, additional scenarios can be added to further enhance the robustness of the joint solution. This can be particularly useful when there are geometric constraints where the relationship between altitude and position trajectory becomes crucial (e.g., avoiding specific terrain at specific locations).

[0345] 2.3.3 Formulation of Joint Multi-Scenario Problem

[0346] In summary, we can formulate the multi-scenario takeoff trajectory optimization problem as

[0347]

[0348] Subject to,

[0349]

[0350] in corresponds to all phases in the nominal scenario, and Corresponding to all the stages in scene S1. If necessary, additional scenes (S2, S3, etc.) can be included similarly, where n s is the total number of scenarios in the problem formulation.

[0351] 3 Example Results

[0352] In this section, we present the trajectory optimization solutions obtained for an example takeoff problem on a 3049 m long runway located at an altitude of 98.45 m above sea level. We will first demonstrate the benefits of the multi-scenario approach before discussing the details of the flight trajectory to highlight the differences.

[0353] 3.1 Benefits of a multi-scenario approach

[0354] To demonstrate the advantages of the proposed multi-scenario approach over independent single-scenario solutions, consider example problems with different uncertain parameters and requirements as specified in Table 1. Based on this information, two single-scenario multi-case problems are formulated as in (13) and a single multi-scenario multi-case problem is formulated as in (19), where scenarios SN and S1 are solved jointly. The independent problem SN and scenario SN in the joint problem are configured under nominal conditions, and the independent problem S1 and scenario S1 in the joint problem are configured using the worst-case parameters. In the independent problems, a constraint is set that forces the allowable runway usage to be 95% of its full length to ensure that it is guaranteed to be met under nominal conditions as required. All problems are solved under standard atmospheric conditions.

[0355] Table 2 compares the accelerate-stop performance for the scenario v1, where takeoff is rejected due to a critical engine failure. First, it can be seen that the simulation results, obtained under the same conditions as the optimization setup, match the optimized solution very accurately. This indicates the good accuracy of the optimization results and the correct setup of the simulation environment. It is also interesting to note that the design of scenario S1, introduced in Section 2.3, has a very small impact on the solution itself, while providing theoretical guarantees that it is less favorable than the worst-case scenario—when the solution to the joint problem is achieved in simulation under the worst-case conditions, runway usage is reduced by only 1 meter compared to the optimized solution.

[0356] More importantly, the results presented in this table demonstrate the importance of the robustness enhancement process. If the independent solutions calculated based on nominal conditions are achieved under the worst-case conditions,

[0357] Table 1: Configuration of different uncertain parameters in the example solution for the takeoff trajectory optimization problem

[0358]

[0359] Table 2: Comparison of accelerate-stop performance under rejected takeoff (ER) at v1

[0360]

[0361] The aircraft would no longer be able to safely come to a complete stop on the 3049 m runway. In contrast, solving and implementing the independent problem S1 results in the desired accelerate-stop performance in both cases; however, upon inspection of the corresponding maximum TGT in Table 3, it can be seen that a substantial temperature penalty (2%) is associated with this solution. Given that critical failures are rare, optimizing for each takeoff based solely on the worst-case scenario could result in significant operational inefficiencies.

[0362] The advantage of a multi-scenario joint solution is clearly visible in this example: achieving the required takeoff performance under both conditions requires a much lower TGT penalty. This is primarily due to the much more flexible framework that allows for specifying different requirements for different scenarios, resulting in a less overly conservative solution with enhanced robustness. To further demonstrate this, consider the case where multiple sets of worst-case conditions exist, as certain combinations of parameter uncertainties do not need to be considered simultaneously. For illustrative purposes, an example with conditions 2 and 3 is shown in Table 4. The solution to the corresponding three-scenario joint problem results in a further reduction in the TGT penalty to only 0.1%.

[0363] Table 3: Comparison of typical takeoff targets for nominal takeoff trajectory (N)

[0364]

[0365] Table 4: Configuration of different uncertain parameters in the three-scenario example problem (SN+S2+S3)

[0366]

[0367] 3.2 Solution trajectory

[0368] In Figures 16 and 17, the solution trajectories for the two-scenario joint problem are presented alongside the independent solution SN for comparison. As can be seen from these figures, the solutions to the joint problem have very similarities to the independent solutions. Here, we highlight some key differences:

[0369] ·exist Figure 16A The nominal climb trajectory in the joint problem has a steeper path compared to the independent solutions. This is because scenario S1 requires a higher thrust to achieve the climb gradient requirement under the worst-case conditions.

[0370] ·exist Figure 17A In the , the airspeed profile during acceleration is similar in different scenarios, but the deceleration segment has significantly different slopes. This is because during acceleration, the thrust can be varied (e.g. Figure 17E During deceleration, the engines are at idle thrust; therefore, the difference in braking effect can be directly observed.

[0371] Figure 18 Presents the engine speed target plan relative to airspeed (when reaching v cpt and then on the ground) and the engine speed target and airspeed plan relative to altitude (when taking off). As can be seen, the trajectories for the two scenarios in the joint problem match exactly, showing that both solutions correspond to the same input strategy as previously discussed. In other words, if the flight crew or the automated system uses Figure 18 If the takeoff is carried out according to the procedure described in Section 2.3,

[0372] If the actual conditions at takeoff exactly match the nominal conditions, the flight will be completed with the lowest optimality penalty for the robustness enhancement process,

[0373] If the actual conditions are no more adverse than the worst-case scenario considered in the joint problem, the aircraft will take off safely or come to a complete stop on the runway even in the unlikely event of a critical engine failure.

Claims

1. An apparatus for planning a route of a vehicle, the apparatus being configured to: determine a trajectory solution for the vehicle based on: one or more target parameters; at least one scenario defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and A plurality of conditions, each of which the vehicle may experience while making the trip. 2 . The apparatus of claim 1 , wherein the plurality of situations include at least one of a non-emergency situation and an emergency situation. 3 . The apparatus of claim 1 , wherein the apparatus is configured to determine the trajectory solution based on a plurality of scenarios, and the plurality of scenarios comprises the apparatus being configured to evaluate each of the plurality of scenarios according to each of the plurality of situations.

4. The apparatus of claim 1 , wherein the apparatus is configured to determine the trajectory solution based on a plurality of scenarios, and wherein a difference between at least two of the plurality of scenarios corresponds at least in part to an uncertainty associated with the one or more constraint parameters.

5. An apparatus according to claim 1, wherein the apparatus is configured to determine the trajectory solution based on the relative importance of the or each target parameter. The apparatus of claim 5 , wherein the apparatus is configured to determine the trajectory solution based on a trade-off between a pair of target parameters.

7. The apparatus of claim 6 , wherein the apparatus is configured to determine the trajectory solution as a first trajectory solution based on a first trade-off between the pair of target parameters, and wherein the apparatus is further configured to: A second trajectory solution for the vehicle is determined based on: a second trade-off between a pair of target parameters; the or each scenario relating to the vehicle and / or the journey to be undertaken by the vehicle; and the or each condition to which the vehicle may be subjected while undertaking the journey. 8 . The apparatus of claim 7 , wherein the apparatus is configured to determine the second trajectory solution based on the same pair of target parameters as the first trajectory solution.

9. Apparatus according to claim 1 , wherein the or each constraint parameter relates to: the characteristics of the vehicle; characteristics of a propulsion system coupled to the vehicle; operating environmental conditions of the vehicle; safety restraints; and Operational constraints.

10. Apparatus according to claim 1, wherein the or each target parameter is associated with performance of at least one component of the vehicle during the trip.

11. Apparatus according to claim 1 , wherein the or each target parameter is: energy consumption of the vehicle; fuel consumption of the vehicle; associated with degradation of components of said vehicle; the amount of chemical substances emitted by the vehicle; the time it takes the vehicle to complete at least a portion of the trip; said performance of a component of said vehicle; or Durability of components of the vehicle.

12. The apparatus of claim 1 , wherein the trajectory solution defines at least one of: a thrust profile provided to a thruster of said vehicle; airspeed profile; Horizontal displacement profile or horizontal velocity profile; vertical displacement profile or vertical velocity profile; and The position of one or more control surfaces of the vehicle is provided.

13. Apparatus according to claim 1 , wherein the or each constraint parameter is: the weight of the vehicle; wind speed; wind direction; The braking coefficient associated with the braking system provided to the aircraft; the inclination of the exterior surface on which the vehicle will travel as part of the trip; the length of the outer surface; A coefficient of friction associated with the interaction between the vehicle and the exterior surface.

14. The device of claim 1 , wherein the device is further configured to: Information about the or each determined trajectory solution is provided for user consideration, approval and / or selection.

15. The device of claim 1, wherein the device is configured to: The vehicle is caused to be controlled according to the selected trajectory solution.

16. Apparatus according to claim 8, wherein the apparatus is configured to provide information about the or each determined trajectory solution for consideration, approval and / or selection by a user, and wherein the information about each determined trajectory solution comprises an indication of the value of each target parameter at which each trajectory solution was determined, and wherein the apparatus is further configured to: receiving input selecting one of the indications; and The vehicle is caused to be controlled according to the trajectory solution associated with the selected indication.

17. Apparatus according to claim 8, wherein the apparatus is configured to provide information about the or each determined trajectory solution for consideration, approval and / or selection by a user, and wherein the information about each determined trajectory solution comprises an indication of the value of each target parameter at which each trajectory solution was determined, and wherein the apparatus is further configured to: receiving an input selecting a value for each target parameter that is not equal to the value of the corresponding target parameter with respect to which the first trajectory solution and the second trajectory solution are determined; A third trajectory solution for the vehicle is determined based on: the chosen value for each target parameter; a third tradeoff between the pair of target parameters based on the input; the or each scenario relating to the vehicle and / or the journey to be undertaken by the vehicle; and the or each condition to which the vehicle may be subjected while undertaking the journey; and The vehicle is controlled according to the third trajectory solution.

18. The apparatus of claim 1, wherein the vehicle is an aircraft comprising a propeller, and wherein the propeller comprises a gas turbine engine.

19. A vehicle comprising an apparatus according to any preceding claim.

20. A computer-implemented method for planning a route of a vehicle, the method comprising: A trajectory solution for the vehicle is determined based on: one or more target parameters; at least one scenario defined by one or more constraint parameters associated with the vehicle and / or a trip to be performed by the vehicle; and A plurality of conditions, each of which the vehicle may experience while making the trip.

21. A computer program comprising instructions which, when a computer executes the program, cause the computer to perform the method according to claim 20.

22. A computer-readable data carrier having stored thereon a computer program according to claim 21.

Images