Patent Description:
During takeoff of an aircraft, one or more conditions may occur that could result in a less than optimal flight experience. The decision of whether to continue the takeoff, in the event that one or more such conditions occur, is a time-sensitive decision. For example, a pilot of the aircraft has a relatively short amount of time to decide whether to complete the takeoff or reject the takeoff.

<CIT>, in accordance with its abstract, states an apparatus and method for an aircraft flight management system that is configured to analyze a takeoff sequence for an aircraft. The aircraft flight management system comprising a memory storing runway information associated with the runway from which the aircraft will depart, one or more inputs configured to receive variables comprising real-time aircraft variables and real-time condition variables that influence an actual velocity of the aircraft, sensors for sensing the actual velocity of the aircraft; and a processor configured to compare a real-time takeoff value to a takeoff requirement value.

According to one implementation of the present disclosure, an aircraft is defined in accordance with claim <NUM>.

According to another implementation of the present disclosure, a method is defined in accordance with claim <NUM>.

The features, functions, and advantages described herein can be achieved independently in various implementations or may be combined in yet other implementations, further details of which can be found with reference to the following description and drawings.

Particular embodiments of the present disclosure are described below with reference to the drawings. In the description, common features are designated by common reference numbers throughout the drawings.

The figures and the following description illustrate specific exemplary embodiments. It will be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles described herein and are included within the scope of the claims that follow this description. Furthermore, any examples described herein are intended to aid in understanding the principles of the disclosure and are to be construed as being without limitation. As a result, this disclosure is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

The techniques described herein enable generation of a takeoff performance alert (TPA) to enable an operator of an aircraft to determine, during a takeoff roll, whether to continue a takeoff of the aircraft or to reject the takeoff. According to an aspect, the TPA utilizes takeoff performance parameters that are based on All-Engine (AE) performance and that correspond to counterpart Engine-Out (EO) parameters such as Go Distance, Accel-Stop Distance, Time to VR, etc..

According to an aspect, the AE parameters are used to compare speeds and distances that the aircraft should be achieving versus the actual performance of the aircraft based on real-time measurements made during the takeoff roll. In an example, if the AE distance to achieve screen height is greater than the runway remaining when the takeoff is started, the TPA is annunciated. In another example, if the stop distance from the takeoff decision speed (V<NUM>) would result in a runway excursion, the TPA is annunciated. Annunciating the TPA can include communicating the TPA to an operator of the aircraft via one or more visual indicators, audible indicators, other indicators, or a combination thereof.

In some scenarios, calculated speeds such as the takeoff decision speed (V<NUM>), rotation speed (VR), and takeoff safety speed (V<NUM>) are incorrect due to an input error, such as a lighter-than-actual takeoff weight. In such scenarios, the TPA is annunciated if the predicted airspeed at the time of VR (VtVR) is significantly less than VR and the distance to achieve screen height (SGO-TPA) is greater than the runway remaining. The determination of the predicted airspeed at the time of VR and the distance to achieve screen height, as well as the decision to annunciate the TPA, can be made during the takeoff roll, such as when the groundspeed of the aircraft has reached <NUM> knots.

In other scenarios with similar errors as above (e.g., due to incorrect inputs of weight and/or thrust), the runway length may be very long. In such cases, the TPA can be annunciated in response to the predicted airspeed at the time of VR (VtVR) being significantly less than VR and the distance to achieve tire speed limit (SVtireLimit) (e.g., a safety criteria for ensuring tire integrity) is less than the distance to achieve screen height.

According to various examples, AE parameters that are used in conjunction with determining whether to generate the TPA include:.

According to some aspects, the V-speeds (parameters a, b, and c listed above) from a flight management computer (FMC) are separately calculated based on the crew inputs into a control display unit (CDU), and are made available for computations associated with the TPA. In an illustrative example, a crew enters V-speeds calculated from a separate application, such as an onboard performance tool (OPT). These crew-entered V-speeds do not overwrite the V-speeds calculated by the FMC. Parameters d-i listed above are newly introduced parameters and are based on all-engine performance. WFMC (parameter j, above) is the runway wind, which is not a new FMC parameter but is being utilized in a new and different way than in conventional systems.

Thus, techniques described herein utilize unconventional parameters and real-time measurements during a takeoff roll to enable a determination of whether an aircraft's performance deviates from its expected performance to an extent that warrants rejection of the takeoff. As a result, one or more conditions affecting aircraft performance can be quickly detected, enabling an improved flight experience.

<FIG> includes a first diagram <NUM> illustrating initial computed parameters <NUM> associated with a takeoff of an aircraft <NUM> at throttles-up and a second diagram <NUM> illustrating updated computed parameters <NUM> associated with the takeoff of the aircraft <NUM> during the takeoff roll. According to an aspect, the initial parameters <NUM> and the updated parameters <NUM> are determined based on All Engine (AE) performance, which corresponds to all engines of the aircraft <NUM> working during the takeoff roll.

The first diagram <NUM> depicts the aircraft <NUM> having a first position <NUM> on a runway <NUM> at throttles-up. A V<NUM> position <NUM> indicates an estimated position of the aircraft <NUM> when the aircraft <NUM> reaches a takeoff decision speed (V<NUM>) (e.g., the speed beyond which a takeoff cannot be rejected without overrunning an end <NUM> of the runway <NUM>). A rotation position <NUM> indicates an estimated position of the aircraft <NUM> when the aircraft <NUM> reaches a takeoff rotation speed (VR). A liftoff position <NUM> indicates an estimated position of the aircraft <NUM> when the aircraft <NUM> reaches a liftoff speed (VLO). The V<NUM> position <NUM>, the rotation position <NUM>, the liftoff position <NUM>, or a combination thereof, can be included in the initial parameters <NUM>.

The initial parameters <NUM> include an estimated distance (SV1) <NUM> to reach the takeoff decision speed, an estimated distance (SVR) <NUM> to reach the rotation speed, and an initial estimated distance (SLO) <NUM> to achieve the liftoff speed. The initial parameters <NUM> also include an estimated all-engine go distance (SGO-AE) <NUM> to achieve a designated screen height <NUM> (e.g., <NUM> feet above the runway <NUM>) and an estimated distance <NUM> to achieve a tire limit speed (e.g., an upper limit on ground speed to ensure the integrity of the tires of the aircraft <NUM>). An estimated initial amount of remaining runway (RR<NUM>) <NUM> indicates a distance from the first position <NUM> to the end <NUM> of the runway <NUM>. The initial parameters <NUM> also include an estimated distance (SV1STOP) <NUM> required to come to a stop from the takeoff decision speed (V<NUM>).

One or more of the initial parameters <NUM> can be computed prior to throttles-up based on user-entered data (e.g., the weight of the aircraft <NUM>, runway length, and runway winds entered into a flight management computer). Others of the initial parameters <NUM> are computed upon detection of throttles-up. For example, the estimated initial amount of remaining runway <NUM> can be computed upon detection of activation of a takeoff/go-around (TO/GA) control, or upon detection that an engine metric N1 (e.g., a rotational speed of a low pressure turbine spool) satisfies a threshold, to ensure that the aircraft <NUM> is no longer taxiing and has begun the takeoff roll, as illustrative, non-limiting examples.

One or more systems of the aircraft <NUM> performs one or more initial checks based on the initial parameters <NUM> at the first position <NUM>. In an example, the initial checks include determining that the all-engine go distance <NUM> is less than the estimated initial amount of remaining runway <NUM> (or is less than the estimated initial amount of remaining runway <NUM> by more than a threshold amount), indicating that the aircraft <NUM> can lift off and reach the screen height <NUM> by the end <NUM> of runway <NUM>. In another example, the initial checks include determining that the amount of remaining runway is not less than the sum of the distance to V<NUM> <NUM> and the distance to stop from V<NUM> <NUM>, as described in further detail with reference to <FIG>.

The second diagram <NUM> depicts the aircraft <NUM> having a second position <NUM> during the takeoff roll. During the takeoff roll, sensors in the aircraft <NUM> collect acceleration, position, and ground speed data, which are used to determine the updated parameters <NUM>. To illustrate, an updated V<NUM> position <NUM>, an updated rotation position <NUM>, and updated liftoff position <NUM> are calculated.

Some of the updated parameters <NUM> are determined relative to the second position <NUM>. For example, a remaining distance to V<NUM> <NUM> represents a distance between the second position <NUM> and the updated V<NUM> position <NUM>, a remaining distance to liftoff speed <NUM> represents a distance between the second position <NUM> and the updated liftoff position <NUM>, and an updated remaining runway <NUM> represents a distance between the second position <NUM> and the end <NUM> of the runway <NUM>.

Some of the updated parameters <NUM> are determined relative to the first position <NUM>. For example, an updated distance to rotation speed <NUM> indicates an estimate of the distance from the first position <NUM> to the updated rotation position <NUM>. An updated distance to liftoff speed <NUM> indicates an estimate of the distance from the first position <NUM> to the updated liftoff position <NUM>. An updated all-engine go distance <NUM> indicates an estimate of the distance from the first position <NUM> to achieve the designated screen height <NUM>. An updated distance <NUM> to tire limit speed indicates an estimate of the distance from the first position <NUM> to reach the tire limit speed.

During the takeoff roll, when the aircraft <NUM> reaches the second position <NUM>, one or more systems of the aircraft <NUM> perform a real-time check using the updated parameters <NUM>. For example, the real-time check can include one or more of: comparing the rotation speed (VR) to an estimated speed that the aircraft <NUM> will be traveling at the point in time that the rotation speed was originally estimated to occur, comparing the updated all engine go distance <NUM> to the estimated initial amount of remaining runway (RR<NUM>) <NUM>, comparing the updated all-engine go distance <NUM> to the updated distance <NUM> to tire limit speed, comparing how closely the updated distance to liftoff speed <NUM> matches the initial estimated distance <NUM> to achieve the liftoff speed, comparing the remaining distance to liftoff speed <NUM> to the updated remaining runway <NUM>, verifying that the updated remaining runway <NUM> is not less than the sum of the remaining distance to V<NUM> <NUM> and the distance to stop from V<NUM> <NUM>, one or more other checks, or any combination thereof.

As illustrated, the estimated positions at which the aircraft <NUM> reaches the takeoff decision speed (V<NUM>), the rotation speed (VR), and the liftoff speed (VLO) are further down the runway <NUM> in the second diagram <NUM> than in the first diagram <NUM>. One potential reason could be that the aircraft <NUM> is accelerating at a slower rate than was expected when generating computing the initial parameters <NUM>. Illustrative, non-limiting examples of conditions which may cause lower than expected acceleration can include a lower than expected thrust output, drag due to a brake that has not fully released, drag due to a runway surface condition (e.g., water, snow, ice, or slush), an incorrect takeoff weight or thrust of the aircraft <NUM> entered into a flight management computer, one or more other conditions, or a combination thereof. In another example, the estimated positions would be further down the runway <NUM> if the aircraft <NUM> began its takeoff roll at an incorrect position on the runway <NUM>, such as when the aircraft <NUM> entered the runway <NUM> at an intersection that does not match an intersection that was entered in the flight management computer. In some implementations, such an incorrect position on the runway <NUM> is detected as part of the initial check(s) performed upon detection of throttles-up.

In response to detection of an error during the initial check(s) at the first position <NUM> or during the real-time check(s) at the second position <NUM>, one or more systems of the aircraft <NUM> generate a takeoff performance alert to instruct an operator of the aircraft <NUM> to reject the takeoff. As a result, deviation from expected performance during the takeoff roll can be detected prior to the aircraft <NUM> reaching V<NUM>, and the aircraft <NUM> can safely abort the takeoff roll and exit the runway <NUM> for investigation into the cause of the deviation from the initial computed parameters <NUM>.

<FIG> depicts a system <NUM> that can be implemented in the aircraft <NUM> and that is configured to generate a takeoff performance alert (TPA) <NUM> during a takeoff. The system <NUM> includes a line replaceable unit (LRU) <NUM>. The LRU <NUM> is coupled to one or more sensors <NUM>, a user interface <NUM>, a takeoff/go around (TO/GA) control <NUM>, a display device <NUM>, one or more loudspeakers <NUM>, an engine <NUM>, an engine thrust controller <NUM>, a thrust reverser <NUM>, and a braking system <NUM>.

The sensor(s) <NUM> correspond to one or more sensing devices that can provide sensing data that is used to determine the initial parameters <NUM>, the updated parameters <NUM>, or both. In some implementations, the sensor(s) <NUM> can provide initial data <NUM> and data <NUM> collected during the takeoff roll. The initial data <NUM> can be used to generate the initial parameters <NUM> and can be used in conjunction with the data <NUM> collected during the takeoff roll to determine the updated parameters <NUM>. In a particular implementation, the sensor(s) <NUM> correspond to one or more of a location sensor (e.g., a global navigational satellite system (GNSS), global positioning system (GPS), or local positioning system to detect a position of the aircraft <NUM> on the runway <NUM>), a wind speed sensor, a ground speed sensor, an engine speed sensor, a clock or timer, a ground distance sensor, one or more other sensors, or a combination thereof.

The user interface <NUM> is coupled to the LRU <NUM> and configured to receive the initial data <NUM> as user-entered data <NUM>. In an illustrative example, the user interface <NUM> corresponds to or includes a control display unit (CDU) <NUM> that enables data to be input to a flight management computer (FMC). According to an implementation, the user-entered data <NUM> includes runway winds, runway length, temperature, aircraft weight, etc..

The TO/GA control <NUM> is configured to receive user input (e.g., actuation of a switch) instructing activation of take-off or go-around thrust. In an implementation, actuation of the TO/GA control <NUM> causes the engine <NUM> of the aircraft <NUM> to increase output to match N1 or another predetermined value.

In some implementations, the display device <NUM> corresponds to one or more visual display instruments, such as an engine-indicating and crew-alerting system (EICAS) display, a primary flight display (PFD), a master warning light, a head-up display (HUD), one or more other visual display instruments, or a combination thereof. The display device <NUM> is configured to output a visual indicator <NUM> to indicate the takeoff performance alert <NUM>. The loudspeaker(s) <NUM> correspond to one or more acoustic transducers configured to provide an audible indicator, such as an audible command <NUM>, to announce the takeoff performance alert <NUM>. Examples of the display device <NUM> and the loudspeaker(s) <NUM> are described in further detail with reference to <FIG>.

The engine thrust controller <NUM> is configured to control a thrust of the engine <NUM>, such as to increase or decrease speed of the aircraft <NUM>. The thrust reverser <NUM> is configured to selectively redirect the airflow of the engine <NUM> to create drag and reduce speed of the aircraft <NUM> while on the ground. The braking system <NUM> is configured to apply brakes to oppose rotation of wheels of the aircraft <NUM> and reduce speed of the aircraft <NUM> while on the ground.

The LRU <NUM> includes a parameter generator <NUM>, a takeoff roll detector <NUM>, an initial check computer <NUM>, a real-time check computer <NUM>, an alert generator <NUM>, an automatic takeoff rejector <NUM>, and a memory <NUM>. In some implementations, the LRU <NUM> corresponds to or includes a flight management computer (FMC). Although the LRU <NUM> is illustrated as including the parameter generator <NUM>, the takeoff roll detector <NUM>, the initial check computer <NUM>, the real-time check computer <NUM>, the alert generator <NUM>, the automatic takeoff rejector <NUM>, and the memory <NUM> in a single line replaceable unit, in other implementations functionality associated with the parameter generator <NUM>, the takeoff roll detector <NUM>, the initial check computer <NUM>, the real-time check computer <NUM>, the alert generator <NUM>, the automatic takeoff rejector <NUM>, and the memory <NUM> are distributed across a network of multiple line replaceable units, which are collectively referred to as the LRU <NUM>.

The parameter generator <NUM> is configured to generate (e.g., compute, look up, or otherwise obtain) values of parameters <NUM> based on the initial data <NUM> and based on the data <NUM> collected during a takeoff roll of the aircraft <NUM>. To illustrate, the parameter generator <NUM> is configured to generate the initial parameters <NUM> for use in an initial check <NUM> and the updated parameters <NUM> for use in a real-time check <NUM>.

The takeoff roll detector <NUM>, is configured to detect when the aircraft <NUM> is no longer taxiing and has commenced a takeoff roll. In a first example, the takeoff roll detector <NUM> is configured to detect actuation of the TO/GA control <NUM> to detect the start of a takeoff roll. In a second example, the takeoff roll detector <NUM> is configured to detect that the engine metric N1 of the engine <NUM> satisfies (e.g., reaches) an engine speed threshold, such as N1=<NUM>% in an illustrative, non-limiting example.

The initial check computer <NUM> includes one or more processing units programmed to execute instructions, dedicated hardware or circuitry, or a combination thereof. The initial check computer <NUM> is configured to perform the initial check <NUM> in response to the takeoff roll detector <NUM> detecting that the aircraft <NUM> has commenced its takeoff roll (e.g., in response to at least one of activation of the takeoff/go around control <NUM> or an engine speed metric reaching an engine speed threshold).

According to an aspect, the initial check <NUM> includes a determination of the estimated initial amount of remaining runway <NUM> and determination of whether the aircraft <NUM> is predicted to have sufficient runway to: reach the takeoff decision speed (V<NUM>), reject takeoff upon reaching the takeoff decision speed, and after rejecting the takeoff, come to a stop before reaching the end <NUM> of the runway <NUM>. In an illustrative example, the initial check computer <NUM> causes the parameter generator <NUM> to determine the estimated initial amount of remaining runway <NUM> in response to the takeoff roll detector <NUM> detecting commencement of the takeoff roll. The initial check computer <NUM> accesses the distance to V<NUM> <NUM>, the distance to stop from V<NUM> <NUM>, and the estimated initial amount of remaining runway <NUM> from the initial parameters <NUM> in the memory <NUM> and performs computations as to whether the aircraft <NUM> has sufficient runway to stop from V<NUM>, such as described further with reference to <FIG>. If the initial check computer <NUM> determines that the aircraft <NUM> does not have sufficient runway to stop from V<NUM>, the initial check computer <NUM> indicates an alert condition 238A.

According to an aspect, the initial check <NUM> includes determining an estimation of the all-engine go distance <NUM> (e.g., accessing the all-engine go distance <NUM> from the initial parameters <NUM> in the memory <NUM>) and determining whether the all-engine go distance <NUM> is less than the estimated initial amount of remaining runway <NUM>, such as described further with reference to <FIG>. If the initial check computer <NUM> determines that the aircraft <NUM> does not have sufficient runway to take off and achieve the screen height <NUM>, the initial check computer <NUM> indicates an alert condition 238A. In an alternative example, a determination can be made as to whether the all-engine go distance <NUM> is less than a threshold distance of the initial amount of remaining runway <NUM>, where the threshold distance corresponds to a safety margin (e.g., <NUM> feet). To illustrate, the threshold distance may be retrieved from threshold data <NUM> stored in the memory <NUM>.

The real-time check computer <NUM> includes one or more processing units programmed to execute instructions, dedicated hardware or circuitry, or a combination thereof. The real-time check computer <NUM> is configured to perform a real-time check <NUM> during the takeoff roll. In a particular implementation, the real-time check computer <NUM> performs the real-time check <NUM> in response to a ground speed of the aircraft <NUM> reaching a ground speed threshold (e.g., <NUM> knots), as described further with reference to <FIG>.

According to an aspect, the real-time check <NUM> includes determining, based on the initial data <NUM>, a takeoff rotation speed (VR) of the aircraft <NUM> and a rotation time tVR associated with VR. In an example, VR and tVR are determined by the parameter generator <NUM> and are retrieved, by the real-time check computer <NUM>, from the initial parameters <NUM> in the memory <NUM>. In some implementations, the real-time check computer <NUM>, upon determining that the ground speed of the aircraft <NUM> has reached the ground speed threshold, instructs the parameter generator <NUM> to generate the updated parameters <NUM> based on the initial data <NUM>, the data <NUM> collected during the takeoff roll, or combinations thereof. The updated parameters <NUM> include a predicted speed (VtVR_TPA) of the aircraft <NUM> at the rotation time tVR. The real-time check computer <NUM> determines whether an alert condition 238B is satisfied at least partially based on whether a disparity between the takeoff rotation speed VR and the predicted speed VtVR_TPA exceeds a rotation speed disparity threshold, as described further with reference to <FIG>. To illustrate, the rotation speed disparity threshold may be retrieved from the threshold data <NUM> in the memory <NUM>.

According to an aspect, the real-time check <NUM> includes determining (e.g., via the parameter generator <NUM>), at least partially based on the data <NUM> collected during the takeoff roll, the updated all-engine go distance <NUM> and the updated distance <NUM> to tire limit speed. In some implementations, the real-time check <NUM> includes determining whether the alert condition 238B is satisfied further based on whether the updated all-engine go distance <NUM> exceeds the estimated initial amount of remaining runway (RR<NUM>) <NUM>, whether the updated all-engine go distance <NUM> exceeds the updated distance <NUM> to reach the tire limit speed, or both. In some implementations, the real-time check <NUM> evaluates one or more other conditions when determining whether the alert condition 238B is satisfied, such as how closely the initial estimated distance <NUM> to achieve the liftoff speed matches the updated estimated distance <NUM> to achieve the liftoff speed, whether the remaining distance <NUM> to achieve the liftoff speed is within a safety margin of the updated amount of remaining runway <NUM>, whether the updated amount of remaining runway <NUM> is sufficient for the aircraft <NUM> to come to a stop if, when the aircraft <NUM> reaches the takeoff decision speed (V<NUM>), or any combination thereof. An illustrative example of the real-time check <NUM> is described further with reference to <FIG>.

The alert generator <NUM> is configured to generate a takeoff performance alert <NUM> in response to any one or more of the alert conditions <NUM> being satisfied. For example, if one or more alert conditions 238A are detected during the initial check <NUM>, the alert generator <NUM> generates the takeoff performance alert <NUM> at the first position <NUM> of <FIG> (at throttles-up) to cause an operator of the aircraft <NUM> to reject takeoff at the beginning of the takeoff roll. As another example, if no alert conditions 238A are detected during the initial check <NUM> and the takeoff roll continues, the alert generator <NUM> generates the takeoff performance alert <NUM> if one or more alert conditions 238B are detected during the real-time check <NUM> at the second position <NUM> of <FIG> to cause an operator of the aircraft <NUM> to reject takeoff during the takeoff roll.

In some implementations, such as when the aircraft <NUM> corresponds to a military aircraft or an unmanned aircraft, the automatic takeoff rejector <NUM> is configured to initiate performance of one or more operations to automatically (e.g., without being initiated by an operator of the aircraft <NUM>) reject the takeoff in response to the alert generator <NUM> generating the takeoff performance alert <NUM>. In an example, automatic rejection of the takeoff includes at least one of automatic adjustment of operation of the engine <NUM> to an idle forward thrust (e.g., via a control signal to the engine thrust controller <NUM>), automatic deployment of the thrust reverser <NUM>, or automatic initiation of braking of the aircraft <NUM> (e.g., via a control signal to the braking system <NUM>). In other implementations in which the aircraft <NUM> corresponds to a commercial aircraft, the automatic takeoff rejector <NUM> is omitted.

According to an illustrative aspect, operation of the system <NUM> to monitor aircraft performance and to generate the TPA <NUM> is active on every flight, from the selection of takeoff thrust to liftoff. In some implementations, if the TPA <NUM> is not active by <NUM> knots groundspeed, the TPA <NUM> will not annunciate. If the TPA <NUM> has been activated but an operator elects to continue the takeoff, an audible warning or command (e.g., "Reject") will be repeatedly played out until the aircraft accelerates up to V<NUM>, and visual indicators including a master warning light (MWL) will remain active until the aircraft <NUM> is in-air.

<FIG> illustrates a flow chart of a method <NUM> for generating a takeoff performance alert that may be performed using the system <NUM> of <FIG>.

Performance data is entered in a Control Display Unit (CDU), at block <NUM>. For example, the flight crew can enter data such as runway winds, active runway, runway length, temperature, aircraft configuration information, etc., which are received by the system <NUM> via the CDU <NUM> of <FIG>. After all requisite information is entered and pre-flight operations are complete, the flight management function (FMF) of the aircraft <NUM> calculates the parameters (e.g., the initial parameters <NUM>) for use in determining the takeoff performance alert and may publish the parameters so that a display and crew alerting (DCA) function can subscribe to and use those values, such as described in further detail with reference to <FIG>.

The aircraft <NUM> takes the active runway as entered in the CDU, at block <NUM>. The system <NUM> can verify that the runway taken, at block <NUM>, matches the runway entered into the CDU. If the taken runway does not match the runway entered into the CDU, the system <NUM> can generate an FMC RUNWAY DISAGREE alert, and the method <NUM> may terminate with the aircraft <NUM> exiting the runway and resolving the discrepancy.

When cleared for takeoff, the crew establishes thrust, at block <NUM>, and either selects TO/GA or manually selects takeoff thrust. The initial check <NUM> is performed in response to the TO/GA control <NUM> being actuated or in response to N1 reaching (e.g., equaling or exceeding) an engine speed threshold, such as N1=<NUM>%, at block <NUM>. The initial check <NUM> can determine one or more non-normal conditions that are dependent on the runway length, such as described in <FIG>.

At block <NUM>, a determination is made as to whether the initial check <NUM> determines an alert condition, such as the alert condition 238A of <FIG>. If an alert condition is detected, at block <NUM>, the method <NUM> advances to block <NUM>, where a takeoff performance alert <NUM> is generated. If no alert condition is detected, at block <NUM>, the takeoff roll continues, and the data <NUM> is collected during the takeoff roll. In an example, acceleration data is collected periodically (e.g., at <NUM> millisecond intervals), and the acceleration data is used to determine (e.g., extrapolate) speed and position data. In other examples, the data <NUM> collected during the takeoff roll also includes distance data, ground speed data, or a combination thereof.

Upon the ground speed (GS) reaching (e.g., equaling or exceeding) a ground speed threshold, the method <NUM> includes performing one or more checks, at block <NUM>. To illustrate, the LRU <NUM> performs the real-time check <NUM> as described in <FIG>. The ground speed threshold can be set to a value at which the aircraft acceleration, ground speed, or both are relatively well-behaved, such as relatively linear with time (or otherwise in accordance with one or more performance models), and measured over a sufficient time period to enable a substantially accurate prediction (e.g., extrapolation) of the ground speed and position of the aircraft <NUM> during the remainder of the takeoff roll. In an illustrative example, the ground speed threshold is set to a value in the range of <NUM> knots to <NUM> knots, such as <NUM> knots.

At block <NUM>, a determination is made as to whether the real-time check <NUM> determines an alert condition, such as the alert condition 238B of <FIG>. If an alert condition is detected, at block <NUM>, the method <NUM> proceeds to block <NUM>, where a takeoff performance alert <NUM> is generated. If no alert condition is detected, at block <NUM>, the takeoff roll continues, at block <NUM>.

<FIG> illustrates a flow chart of another example of a method <NUM> for generating a takeoff performance alert that may be performed by the system <NUM> of <FIG>. The method <NUM> includes obtaining initial values of parameters, at <NUM>. For example, the LRU <NUM> obtains the initial parameters <NUM> at least partially based on the initial data <NUM>, which may be received from the crew, via the CDU <NUM>, as user the user entered data <NUM>. The initial values include the estimated distance (SV1) <NUM> to reach the takeoff decision speed (V<NUM>), the estimated all-engine go distance (SGO-AE) <NUM>, and the estimated distance (SVISTOP) <NUM> required to come to a stop from V<NUM>, as described in <FIG>. The initial values also include the takeoff rotation speed (VR) <NUM> and an estimated time (tVR) <NUM> to reach VR.

The method <NUM> includes, at block <NUM>, determining whether either the engine metric (N1) <NUM> has reached a first threshold engine speed (NTR1) <NUM> or the TO/GA control <NUM> has been actuated. To illustrate, the first threshold engine speed (NTR1) <NUM> may be set to a value that is large enough to ensure that the aircraft <NUM> is no longer taxiing and that the takeoff roll has begun. However, too large a value of the first threshold engine speed (NTR1) <NUM> reduces the amount of available time for collecting data during the takeoff roll, as described below with reference to block <NUM>. In some implementations, the first engine threshold speed (NTR1) <NUM> is set to a value in the range of <NUM>% to <NUM>%, such as <NUM>%. Upon N1 reaching NTR1 or the TO/GA control <NUM> being actuated, the method <NUM> includes, at block <NUM>, computing the initial amount of remaining runway (RR<NUM>) <NUM> at throttles-up, and an initial check is performed, at block <NUM>.

In some implementations, the initial check corresponds to the initial check <NUM> and includes evaluating a first expression (<d1>) and a second expression (<d2>). The first expression determines whether there is insufficient runway to safely reach the designated screen height. To illustrate, the first expression can be expressed as:<MAT> corresponding to determining whether the estimated all-engine go distance (SGO-AE) <NUM> exceeds the initial amount of remaining runway (RR<NUM>) <NUM>. The first expression evaluates to FALSE if there is sufficient runway to reach the designated screen height <NUM> by the end <NUM> of the runway <NUM>, and evaluates to TRUE otherwise.

The second expression determines whether the aircraft <NUM> is predicted to have sufficient runway to reach the takeoff decision speed (V<NUM>), reject the takeoff upon reaching the takeoff decision speed (V<NUM>), and after rejecting the takeoff, come to a stop before reaching the end <NUM> of the runway <NUM>. For example, the second expression can compare the distance required to stop from the takeoff decision speed (V<NUM>) to the distance predicted to be remaining when the aircraft has reached the takeoff decision speed (V<NUM>). To illustrate, the second expression can be expressed as:<MAT> corresponding to determining whether the estimated initial amount of remaining runway (RR<NUM>) <NUM>, reduced by the first estimated distance (SV1) <NUM> to reach the takeoff decision speed (V<NUM>), exceeds the second estimated distance (SV1STOP) <NUM> required to come to a stop after reaching the takeoff decision speed (V<NUM>). The second expression evaluates to TRUE if there is insufficient runway to reach the takeoff decision speed (V<NUM>) and come to a stop from the takeoff decision speed (V<NUM>), and evaluates to FALSE otherwise.

A determination is made, at block <NUM>, as to whether either of the first expression or the second expression evaluates to TRUE. If the first expression evaluates to TRUE, the second expression evaluates to TRUE, or both the first expression and the second expression evaluate to TRUE, a takeoff performance alert is generated, at block <NUM>.

If both the first expression and the second expression evaluate to FALSE, the method <NUM> includes determining, at block <NUM>, whether the ground speed (GS) <NUM> of the aircraft <NUM> has reached a first ground speed threshold (GSTR1) <NUM>. In some implementations, the first ground speed threshold (GSTR1) <NUM> corresponds to a ground speed above which the ground speed and acceleration characteristics of the aircraft <NUM> are expected to be well-behaved, and therefore useful for accurate extrapolation as the aircraft <NUM> continues its takeoff roll. According to an aspect, the first ground speed threshold (GSTR1) <NUM> is selected to have a value in the range of <NUM> knots to <NUM> knots. In a particular, non-limiting example, the first ground speed threshold (GSTR1) <NUM> is <NUM> knots.

Upon determining that the ground speed (GS) <NUM> of the aircraft <NUM> has reached a first ground speed threshold (GSTR1) <NUM>, at block <NUM>, the method <NUM> includes collecting the data <NUM> (e.g., acceleration and time data) every T milliseconds, where T represents a time interval, such as <NUM> milliseconds, at block <NUM>. Collection of the data <NUM> continues until a determination is made, at block <NUM>, that the ground speed (GS) <NUM> has reached a second ground speed threshold (GSTR2) <NUM>, at block <NUM>.

In some implementations, the second ground speed threshold (GSTR2) <NUM> is selected to have a large enough value to provide enough time for sufficient data collection to enable accurate predictions of future speeds and positions of the aircraft <NUM>. However, larger values of second ground speed threshold (GSTR2) <NUM> introduce longer delays before a takeoff performance alert can be determined and provided to an operator of the aircraft <NUM>, which should occur well before the aircraft <NUM> reaches the takeoff decision speed (V<NUM>). According to an aspect, the second ground speed threshold (GSTR2) <NUM> is selected to have a value in the range of <NUM> knots to <NUM> knots. In a particular, non-limiting example, the second ground speed threshold (GSTR2) <NUM> is <NUM> knots.

Upon determining that the ground speed (GS) <NUM> of the aircraft <NUM> has reached the second ground speed threshold (GSTR2) <NUM>, at block <NUM>, the method <NUM> includes obtaining updated values, at block <NUM>, based on the data <NUM> collected during the takeoff roll. To illustrate, the updated values correspond to the updated parameters <NUM> and include an estimated speed (VtVR_TPA) <NUM> that the aircraft <NUM> will be traveling at the point in time (tVR) that the rotation speed (VR) was originally estimated to be reached, the updated all-engine go distance (SGO-TPA) <NUM>, and the updated distance (SVtireLimit) <NUM> to tire limit speed.

After obtaining the updated values at block <NUM>, the method <NUM> includes, at block <NUM>, performing a real-time check, such as the real-time check <NUM> of <FIG>. As illustrated, the real-time check includes evaluating three expressions labelled <s1>, <d3>, and <d4>. The expression <s1> is related to whether the aircraft <NUM> is lagging (in time) relative to the rotation speed (VR). For example, the expression <s1> determines whether the predicted speed (VtVR_TPA) <NUM> of the aircraft <NUM> at the rotation time (tVR) <NUM> is sufficiently close to the rotation speed (VR) <NUM>, or whether the data <NUM> collected during the takeoff roll indicates that, at the time (tVR) that the aircraft <NUM> was initially predicted to reach the rotation speed (VR) <NUM>, the aircraft <NUM> will instead be travelling at a significantly slower speed. To illustrate, <s1> can be expressed as:<MAT> corresponding to determining whether a disparity (VR - VtVR_TPA) <NUM> between the takeoff rotation speed (VR) <NUM> and the predicted speed (VtVR_TPA) <NUM> exceeds a rotation speed disparity threshold (VTR1) <NUM>, such as <NUM> knots. Expression <s1> evaluates to TRUE if the disparity <NUM> exceeds the rotation speed disparity threshold (VTR1) <NUM>, and evaluates to FALSE otherwise.

Expression <d3> is related to whether the aircraft <NUM> can reach the screen height <NUM> before the end <NUM> of the runway <NUM>. In particular, <d3> compares the updated all-engine go distance (SGO-TPA) <NUM> to the estimated initial amount of remaining runway (RR<NUM>) <NUM>. To illustrate, <d3> can be expressed as: <MAT>.

corresponding to determining whether the updated all-engine go distance (SGO-TPA) <NUM> is greater than the estimated initial amount of remaining runway (RR<NUM>) <NUM>. Expression <d3> evaluates to TRUE if the updated all-engine go distance (SGO-TPA) <NUM> exceeds the estimated initial amount of remaining runway (RR<NUM>) <NUM>, and evaluates to FALSE otherwise.

Expression <d4> is related to whether the tire limit speed will occur before the updated all-engine go distance (SGO-TPA) <NUM> is reached. In particular, <d4> compares the updated all-engine go distance (SGO-TPA) <NUM> to the updated distance (SVtireLimit) <NUM> to tire limit speed. To illustrate, <d4> can be expressed as:<MAT> corresponding to determining whether the updated all-engine go distance (SGO-TPA) <NUM> is greater than the updated distance (SVtireLimit) <NUM> to tire limit speed. Expression <d4> evaluates to TRUE if the updated all-engine go distance (SGO-TPA) <NUM> exceeds the updated distance (SVtireLimit) <NUM> to tire limit speed, and evaluates to FALSE otherwise.

A determination is made, at block <NUM>, as to whether any of the expressions <s1>, <d3>, or <d4> evaluates to TRUE. If the expression <s1> and either of the expressions <d3> or <d4> elevate to TRUE, a takeoff performance alert is generated, at block <NUM>. Otherwise, the performance of the aircraft <NUM> during the takeoff roll is evaluated as satisfactory in comparison to the initial estimates, and the takeoff roll continues without generating a takeoff performance alert, at block <NUM>. In an alternative implementation, the determination to generate the takeoff performance alert can be based on determining that any one or more of the expressions <s1>, <d3>, or <d4> evaluates to TRUE.

Thus, the method <NUM> enables enhanced monitoring of the performance upon initiation of, and during, the takeoff roll and the capability to generate a takeoff performance alert in response to initial checks and further in response to predicted aircraft performance based on real-time speed and acceleration data collected during the takeoff roll.

Although the method <NUM> illustrates evaluation of the expressions <d1> and <d2> as part of the initial check, in other implementations performance of the initial check may omit evaluation either of <d1> or <d2>. To illustrate, if one of the expressions <d1> or <d2> is evaluated as TRUE, the initial check can be terminated and an alert generated without completing the evaluation of the other of <d1> or <d2>. Similarly, in some implementations, performance of the real-time check may omit evaluation of one or more of the expressions <s1>, <d3>, or <d4>. The expressions <d1>, <d2>, <s1>, <d3>, and <d4> are provided as illustrative examples, and in other implementations one or more of <d1>, <d2>, <s1>, <d3>, or <d4> can be replaced with one or more logically equivalent expressions.

Although the method <NUM> illustrates that the real time check incudes the expressions <s1>, <d3>, and <d4>, in other implementations one or more other expressions can be evaluated as part of the real time check in place of, or in addition to, one or more of expressions <s1>, <d3>, and <d4>. In a first example, the real time check evaluates whether the aircraft <NUM> is lagging (in space) relative to the liftoff speed (VLO), such as by evaluating the expression SSF * SLO ≤ SVLO_TPA, corresponding to determining whether the initial estimated distance (SLO) <NUM> to achieve the liftoff speed (VLO), adjusted by a scaling factor (SSF) (e.g., <NUM>), is less than or equal to the updated estimated distance (SVLO_TPA) <NUM> to achieve the liftoff speed (VLO). In a second example, the real time check evaluates whether there will be sufficient runway for liftoff, such as by evaluating the expression SVLO@GS2 + STR2 > RRGS2, corresponding to determining whether a sum of the remaining distance (SVLO@GS2) <NUM> to achieve the liftoff speed (VLO) and a threshold distance (STR2) exceeds the updated amount of remaining runway (RRGS2) <NUM>. In a third example, the real time check evaluates whether there will be sufficient runway to stop upon reaching the takeoff decision speed (V<NUM>), such as by evaluating the expression (RRGS2 - SV1@GS2 ) < SV1STOP, corresponding to determining whether a difference between the updated amount of remaining runway (RRGS2) <NUM> and the remaining distance (SV1@GS2) <NUM> to achieve the takeoff decision speed (V<NUM>) is less than the estimated distance (SV1STOP) <NUM> required to come to a stop after reaching the takeoff decision speed (V<NUM>).

<FIG> illustrates an example of operations <NUM> that may be performed by the system <NUM> of <FIG>. A flight management function (FMF) <NUM> provides (e.g., receives or calculates) various takeoff parameters and data <NUM>. As illustrated, the takeoff parameters and data <NUM> includes runway winds (WFMC) (e.g., the headwind or tailwind component, along the runway) entered into an FMC, runway length (RL), ownship position (RMC_POS), tVR <NUM>, SGO-AE <NUM> (e.g., at <NUM>-foot screen height), VR <NUM>, V<NUM>, V<NUM>, SV1 <NUM>, VLO (e.g., speed at liftoff), SLO <NUM>, and SV1STOP <NUM>.

The takeoff parameters and data <NUM> are provided, via a display management system (DMS) input/output interface (I/O) <NUM>, to a display and crew alerting function (DCA) <NUM> for calculation of alert conditions. A first set of alert conditions <NUM> includes the expression: (TO/GA selected OR N1≥<NUM>) AND {(SGO-AE>RR<NUM>) OR (RR<NUM>-SV1<SV1STOP)}, corresponding to the determination of block <NUM> and the initial check of block <NUM> of <FIG>, implemented using NTR1 = <NUM>. A takeoff performance alert is generated if the first set of alert conditions <NUM> evaluates to TRUE.

A second set of alert conditions <NUM> includes the expression: (|W<NUM>-W<NUM>|<<NUM> kts) AND (<NUM> kts<GS<<NUM> kts) AND (VR-VtVR_TPA><NUM> kts) AND {(SGO-TPA > RR<NUM>) OR (SGO-TPA > SVtireLimit)}. The expression (|W<NUM>-W<NUM>|<<NUM> kts) corresponds to a check that the absolute value of the difference between measured windspeed when groundspeed of the aircraft <NUM> is at <NUM> knots (e.g., GSTR1 = <NUM> knots) and measured windspeed when the groundspeed of the aircraft is at <NUM> knots (e.g., GSTR2 = <NUM> knots) does not exceed <NUM> knots. The expression (<NUM> kts<GS<<NUM> kts) corresponds to a check that the groundspeed of the aircraft <NUM> is greater than <NUM> knots and less than <NUM> knots (e.g., upon completion of the data collection at block <NUM> of <FIG>). The expression (VR-VtVR_TPA><NUM> kts) corresponds to the expression <s1>, the expression (SGO-TPA > RR<NUM>) corresponds to the expression <d3>, and the expression (SGO-TPA > SVtireLimit) corresponds to the expression <d4>. A takeoff performance alert is generated if the second set of alert conditions <NUM> evaluates to TRUE.

In a particular implementation, the initial check computer <NUM> of <FIG> performs the checks included in the first set of alert conditions <NUM>, including evaluating <d1> and <d2>, using the all-engine takeoff parameters calculated by the FMF <NUM> as well as information about the departure runway at the time takeoff thrust is selected. These checks are independent of real-time acceleration.

In a particular implementation, the real-time check computer <NUM> of <FIG> performs the checks included in the second set of alert conditions <NUM>, including evaluating <s1>, <d3>, and <d4> based on real-time aircraft performance. For example, True Airspeed (TAS) at tVR cannot be predicted until some acceleration, distance, groundspeed (GS), and time data are collected (and/or computed based on collected data). The LRU <NUM> collects this data up until GS=<NUM> knots (e.g., in the data <NUM> collected during the takeoff roll). A comparison of the wind values at GS=<NUM> knots and GS=<NUM> knots is performed by taking the difference of TAS and GS measured at those stages of the takeoff roll. By conditioning the second set of alert conditions <NUM> on the difference being less than <NUM> knots (e.g., |W<NUM>-W<NUM>|<<NUM> kts), a possibility of inaccurate generation of a takeoff performance alert due to gusting conditions is reduced or eliminated.

In some implementations, real-time distance parameters, such as SGO-TPA and SVtireLimit, are determined using a first principles equation of motion: <MAT> where d<NUM> represents the distance at the previous time interval, v represents the TAS in feet per second (ft/s), a represents the acceleration in f/s<NUM>, and t represents time in seconds. The distance d can be computed during each measurement time period (e.g., every T ms as illustrated at block <NUM> of <FIG>).

In terms of indices representing such time intervals, the distance can be approximated as: <MAT> where di represents the distance traveled at the current time interval i; di-<NUM> represents the distance traveled at the previous time interval; vi-<NUM> represents the extrapolated velocity at the previous time interval; ti represents the time at the current time interval; ti-<NUM> represents the time at the previous time interval, and ai-<NUM> is the extrapolated acceleration at the previous time interval.

In some implementations, the GS is provided by airplane sensors and the TAS is calculated as: TAS = GS + Windspeed. TAS is derived from GS because of potential fluctuations based on instantaneous Windspeed. The average wind (Wavg) is calculated during the evaluation period (e.g., between <NUM> and <NUM> knots GS) and, at <NUM> knots GS, Wavg is added to the GS to calculate the TAS. The predicted TAS - VtVR_TPA - can be calculated as determined by: v = v<NUM>+at, which can be expressed in terms of indices representing intervals of time as: <MAT>.

According to an aspect, in the above equations for distance, velocity is converted from knots to ft/s and, in the equation for TAS, acceleration is converted based on a conversion from ft/s to knots. In both cases, the conversion factor <NUM> ft/s per knots can be used.

<FIG> is a diagram <NUM> illustrating an example of takeoff performance alert indicators that may be generated by the system <NUM> of <FIG>. Display devices that include visual takeoff performance alert indicators are illustrated as a master warning light <NUM> on a flight deck panel, a PFD including an indicator <NUM>, an EICAS display including an indicator <NUM>, and a HUD including an indicator612, each of which indicates the takeoff performance alert <NUM> and can correspond to an instance of the visual indicator <NUM> of <FIG>. An audible indicator includes a repeated command <NUM> ("Reject") played out via one or more loudspeakers <NUM>, which can correspond to the audible command <NUM> played out via the one or more loudspeakers <NUM> of <FIG>. Although <FIG> depicts four visual indicators and one audible indicator, in other implementations one or more other audible, visual, or other types of indicators (e.g., haptic) can be used in place of, or in addition to, one or more of the illustrated indicators to provide a takeoff performance alert to an operator. As an example, each of the visual indicators <NUM>, <NUM>, <NUM> can be duplicated and displayed on both sides of the fight deck panel. Thus, the alert indicators illustrated in the diagram <NUM> are to be understood as a non-limiting, illustrative example.

<FIG> illustrates a flow chart of a method <NUM> for generating a takeoff performance alert during a takeoff associated with an aircraft. In a particular implementation, the method <NUM> is performed by the LRU <NUM> of <FIG>.

The method <NUM> includes, at block <NUM>, determining, based on initial data collected prior to a takeoff roll of the aircraft, a takeoff rotation speed of the aircraft and a rotation time associated with the takeoff rotation speed <NUM>. For example, the LRU <NUM> determines the takeoff rotation speed (VR) <NUM> and the rotation time (tVR) <NUM> based on the initial data <NUM>. In some implementations, the initial data is received as user-entered data at an interface to a flight management computer prior to the takeoff roll, such as the user entered data <NUM> at the CDU <NUM>.

The method <NUM> includes, at block <NUM>, determining, during the takeoff roll and prior to the rotation time, a predicted speed of the aircraft at the rotation time, where the predicted speed is at least partially based on data collected during the takeoff roll. For example, the LRU <NUM> computes the predicted speed (VtVR_TPA) <NUM> at the rotation time (tVR) <NUM> based on the data <NUM> collected during the takeoff roll. In some implementations, collection of the data during the takeoff roll is initiated responsive to the aircraft reaching a first speed, and determination of the predicted speed is performed responsive to the aircraft reaching a second speed that is greater than the first speed. In an example, the LRU <NUM> initiates collection of the data <NUM> in response to the aircraft <NUM> reaching the first ground speed threshold (GSTR1) <NUM>, and computes the predicted speed (VtVR_TPA) <NUM> at the rotation time (tVR) <NUM> in response to the aircraft <NUM> reaching the second ground speed threshold (GSTR2) <NUM>.

The method <NUM> includes, at block <NUM>, determining whether an alert condition is satisfied at least partially based on whether a disparity between the takeoff rotation speed and the predicted speed exceeds a rotation speed disparity threshold. In an example, the LRU <NUM> determines whether the alert condition 238B is satisfied at least partially based on whether the disparity (VR-VtVR_TPA) <NUM> between the takeoff rotation speed (VR) <NUM> and the predicted speed (VtVR_TPA) <NUM> exceeds the rotation speed disparity threshold (VTR1) <NUM>.

The method <NUM> includes, at block <NUM>, in response to determining that the alert condition is satisfied, generating the takeoff performance alert. For example, the alert generator <NUM> of the LRU <NUM> generates the takeoff performance alert <NUM> in response to determining that the alert condition 238B is satisfied.

The method <NUM> includes, at block <NUM> and prior to the determining of the initial check described in the method <NUM> of <FIG>, performing an initial check, such as the initial check <NUM>. Performing the initial check includes, at block <NUM>, determining an estimated initial amount of remaining runway, such as the estimated amount of remaining runway (RR<NUM>) <NUM>, and determining whether the aircraft is predicted to have sufficient runway to: reach a takeoff decision speed (V<NUM>), reject the takeoff upon reaching the takeoff decision speed (V<NUM>), and after rejecting the takeoff, come to a stop before reaching an end of the runway, at block <NUM>. Performing the initial check also includes determining whether the aircraft is predicted to have enough runway to take off, at block <NUM>, and determining whether to generate the takeoff performance alert based on the initial check, at <NUM>. An example of performing of the initial check is described in further detail with reference to <FIG>.

After performing the initial check, and during the takeoff roll, a real-time check can be performed based on evaluating multiple conditions, illustrated at blocks <NUM>-<NUM>. To illustrate, the method <NUM> includes, at block <NUM>, determining whether a disparity between the takeoff rotation speed and the predicted speed of the aircraft at the rotation time exceeds a rotation speed disparity threshold, such as described previously in the method <NUM>. In an example, the LRU <NUM> determines whether the disparity (VR-VtVR_TPA) <NUM> between the takeoff rotation speed (VR) <NUM> and the predicted speed (VtVR_TPA) <NUM> exceeds the rotation speed disparity threshold (VTR1) <NUM>.

At block <NUM>, the method <NUM> includes determining whether the aircraft is predicted to have sufficient runway to achieve a designated screen height (e.g., the screen height <NUM>) before reaching an end of the runway. At block <NUM>, the method <NUM> includes determining whether the aircraft is predicted to achieve the designated screen height without reaching a tire limit speed.

The method <NUM> includes, at block <NUM>, determining whether the alert condition is satisfied. In an illustrative example, determining whether the alert condition is satisfied is based on: whether the disparity between the takeoff rotation speed and the predicted speed of the aircraft at the rotation time exceeds a rotation speed disparity threshold, whether the aircraft is predicted to have sufficient runway to achieve the designated screen height before reaching an end of the runway, and whether the aircraft is predicted to achieve the designated screen height without reaching a tire limit speed, corresponding to the determinations made at blocks <NUM>-<NUM>.

According to some implementations, the alert condition is determined to be satisfied in response to both: (A) the disparity between the takeoff rotation speed and the predicted speed of the aircraft at the rotation time exceeding the rotation speed disparity threshold; and (B) the aircraft being predicted to not have sufficient runway to achieve the designated screen height before reaching an end of the runway. According to another aspect, the alert condition is determined to be satisfied in response to both: (A) the disparity between the takeoff rotation speed and the predicted speed of the aircraft at the rotation time exceeding the rotation speed disparity threshold; and (C) the aircraft being predicted to reach the tire speed limit before achieving the designated screen height.

The method <NUM> also includes, in response to determining that the alert condition is satisfied, generating the takeoff performance alert, at block <NUM>. For example, the alert generator <NUM> of the LRU <NUM> generates the takeoff performance alert <NUM>.

<FIG> illustrates a flow chart of a method <NUM> for generating a takeoff performance alert based on an initial check during a takeoff associated with an aircraft. In a particular implementation, the method <NUM> corresponds to, or is included in, performing the initial check at block <NUM> of <FIG>. For example, the method <NUM> includes determining an initial amount of remaining runway, at block <NUM>.

The method <NUM> includes determining a first estimated distance (e.g., SV1 <NUM>) to reach the takeoff decision speed (V<NUM>), at block <NUM>. The method <NUM> also includes determining a second estimated distance (e.g., SV1STOP <NUM>) required to come to a stop after reaching the takeoff decision speed (V<NUM>), at block <NUM>. The method <NUM> further includes determining whether the estimated initial amount of remaining runway (e.g., RR<NUM> <NUM>), reduced by the first estimated distance (e.g., SV1 <NUM>), exceeds the second estimated distance (e.g., SV1STOP <NUM>), at block <NUM>. In a particular implementation, blocks <NUM>, <NUM>, and <NUM> are performed as part of determining whether the aircraft is predicted to have sufficient runway to reach the takeoff decision speed, reject the takeoff, and come to a stop, of block <NUM> of <FIG>.

The method <NUM> includes determining an estimated all-engine go distance (e.g., SGO-AE <NUM>) to achieve a designated screen height, at block <NUM>, and determining whether the estimated all-engine go distance is less than the estimated initial amount of remaining runway, at block <NUM>. In a particular implementation, blocks <NUM> and <NUM> are performed as part of determining whether the aircraft is predicted to have sufficient runway to take off, of block <NUM> of <FIG>.

The method <NUM> also includes determining whether to generate the takeoff performance alert based on the initial check, at block <NUM>. For example, a determination is made to generate the takeoff performance alert in response to the estimated initial amount of remaining runway, reduced by the first estimated distance, exceeding the second estimated distance. As another example, a determination is made to generate the takeoff performance alert in response to the estimated all-engine go distance being less than the estimated initial amount of remaining runway.

<FIG> illustrates a flow chart of a method <NUM> for generating a takeoff performance alert based on a predicted speed of an aircraft at a rotation time during a takeoff. In a particular implementation, the method <NUM> corresponds to, or is included in, determining whether a disparity between the takeoff rotation speed and the predicted speed of the aircraft at the rotation time exceeds a rotation speed disparity threshold, at block <NUM> of <FIG>.

The method <NUM> includes determining, based on initial data collected prior to a takeoff roll of the aircraft, a takeoff rotation speed (e.g., VR <NUM>) of the aircraft and a rotation time (e.g., tVR <NUM>) associated with the takeoff rotation speed, at block <NUM>. The method <NUM> also includes, at block <NUM>, determining, during the takeoff roll and prior to the rotation time, a predicted speed (e.g., VtVR_TPA <NUM>) of the aircraft at the rotation time, where the predicted speed is at least partially based on data collected during the takeoff roll (e.g., the data <NUM>).

The method <NUM> includes, at block <NUM>, determining whether an alert condition is satisfied at least partially based on whether a disparity (e.g., (VR-VtVR_TPA) <NUM>) between the takeoff rotation speed (e.g., VR <NUM>) and the predicted speed (e.g., VtVR_TPA <NUM>) exceeds a rotation speed disparity threshold (e.g., VTR1 <NUM>). For example, the real-time check computer <NUM> can evaluate the expression <s1> of <FIG>. In some implementations, the method <NUM> also includes generating the takeoff performance alert in response to determining that the alert condition is satisfied.

<FIG> illustrates a flow chart of a method <NUM> for generating a takeoff performance alert based on an all-engine go distance to achieve a designated screen height during a takeoff of an aircraft. In a particular implementation, the method <NUM> corresponds to, or is included in, determining whether the aircraft is predicted to have sufficient runway to achieve the designated screen height before reaching an end of the runway, at block <NUM> of <FIG>.

The method <NUM> incudes determining, at least partially based on initial data (e.g. the initial data <NUM>) collected prior to the takeoff roll, an estimated initial amount of remaining runway (e.g., RR<NUM> <NUM>), at block <NUM>. The method <NUM> also includes determining, at least partially based on data (e.g., the data <NUM>) collected during the takeoff roll, an updated all-engine go distance (e.g., SGO-TPA <NUM>) to achieve a designated screen height (e.g., the screen height <NUM>), at block <NUM>.

The method <NUM> includes determining whether the updated all-engine go distance to achieve the designated screen height is greater than the estimated initial amount of remaining runway, at <NUM>. For example, the real-time check computer <NUM> can evaluate the expression <d3> of <FIG>. In some implementations, the method <NUM> includes determining that an alert condition is satisfied in response to the updated all-engine go distance to achieve the designated screen height being greater than the estimated initial amount of remaining runway.

<FIG> illustrates a method <NUM> for generating a takeoff performance alert based on an all-engine go distance to achieve a designated screen height. In a particular implementation, the method <NUM> corresponds to, or is included in, determining whether the aircraft is predicted to achieve the designated screen height without reaching a tire limit speed, at block <NUM> of <FIG>.

The method <NUM> includes determining, at least partially based on data (e.g., the data <NUM>) collected during the takeoff roll, an updated all-engine go distance (e.g., SGO-TPA <NUM>) to achieve a designated screen height, at block <NUM>. The method <NUM> also includes determining, at least partially based on data (e.g., the updated data <NUM>) collected during the takeoff roll, an updated distance (e.g., SVtireLimit <NUM>) to reach a tire limit speed at least partially based on the data collected during the takeoff roll, an updated amount of remaining runway (e.g., RRGS2 <NUM>), at block <NUM>.

The method <NUM> includes determining whether a sum of the remaining distance to achieve the liftoff speed and a threshold distance (e.g., STR2 <NUM>) exceeds the updated amount of remaining runway, at block <NUM>. For example, the real-time check computer <NUM> can evaluate the expression <d4> of <FIG>. In some implementations, the method <NUM> includes determining that an alert condition is satisfied in response to the updated all-engine go distance being greater than the updated distance to reach the tire limit speed.

<FIG> illustrates a method <NUM> for generating a takeoff performance alert and automatically rejecting a takeoff of an aircraft. In a particular implementation, the method <NUM> corresponds to, or is performed as part of, generating the takeoff performance alert in any of the methods of <FIG>.

The method <NUM> includes at least one of: displaying a visual indicator (e.g., the visual indicator <NUM> of <FIG>) instructing an operator of the aircraft to reject takeoff, at block <NUM>, or generating an audible command (e.g., the audible command <NUM>) instructing the operator of the aircraft to reject takeoff, at block <NUM>.

If the aircraft includes at least one of a military aircraft or an unmanned aircraft, the method <NUM> also includes automatically rejecting takeoff in response to generation of the takeoff performance alert, at block <NUM>. For example, the automatic takeoff rejector <NUM> can reject takeoff in response to generation of the takeoff performance alert <NUM>. In a particular implementation, automatically rejecting the takeoff includes at least one of: automatically adjusting operation of an engine to an idle forward thrust, automatically deploying a thrust reverser, or automatically initiating braking of the aircraft, such as described further with reference to <FIG>.

<FIG> illustrates a method <NUM> for automatically rejecting a takeoff of a military or unmanned aircraft in response to generation of a takeoff performance alert. In a particular implementation, the method <NUM> corresponds to, or is performed as part of automatically rejecting takeoff in response to generation of the takeoff performance alert of block <NUM> of <FIG>.

The method <NUM> includes automatically adjusting operation of an engine to an idle forward thrust, at block <NUM>. For example, the automatic takeoff rejector <NUM> can cause the engine thrust controller <NUM> to adjust the engine <NUM> to an idle forward thrust. The method <NUM> includes automatically deploying a thrust reverser, at block <NUM>. For example, the automatic takeoff rejector <NUM> can cause the engine thrust controller <NUM> to deploy the thrust reverser <NUM>. The method <NUM> also includes automatically initiating braking of the aircraft, at block <NUM>. For example, the automatic takeoff rejector <NUM> can engage the braking system <NUM>,
Referring to <FIG> and <FIG>, examples of the disclosure are described in the context of an aircraft manufacturing and service method <NUM> as illustrated by the flow chart of <FIG> and the aircraft <NUM> as illustrated by the block diagram of <FIG>.

Referring to <FIG>, a flowchart of an illustrative example of a method associated with a takeoff performance alert system (e.g., the LRU <NUM>) is shown and designated <NUM>. During pre-production, the exemplary method <NUM> includes, at block <NUM>, specification and design of an aircraft, such as the aircraft <NUM>. During the specification and design of the aircraft, the method <NUM> includes specifying the LRU <NUM>, the engine <NUM>, the display device <NUM>, the loudspeaker(s) <NUM>, the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, the sensor(s) <NUM>, and the user interface <NUM>. At block <NUM>, the method <NUM> includes material procurement. For example, the method <NUM> may include procuring materials (such as materials for the LRU <NUM>, the engine <NUM>, the display device <NUM>, the loudspeaker(s) <NUM>, the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, the sensor(s) <NUM>, and the user interface <NUM>) for the takeoff performance alert system.

During production, the method <NUM> includes, at block <NUM>, component and subassembly manufacturing and, at block <NUM>, system integration of the aircraft. The method <NUM> may include component and subassembly manufacturing (e.g., the LRU <NUM>, the engine <NUM>, the display device <NUM>, the loudspeaker(s) <NUM>, the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, the sensor(s) <NUM>, and the user interface <NUM>) of the takeoff performance alert system and system integration (e.g., coupling the components) of the takeoff performance alert system. At block <NUM>, the method <NUM> includes certification and delivery of the aircraft and, at block <NUM>, placing the aircraft in service. In some implementations, certification and delivery includes certifying the takeoff performance alert system. Placing the aircraft in service may also include placing takeoff performance alert system in service. While in service, the aircraft may be scheduled for routine maintenance and service (which may also include modification, reconfiguration, refurbishment, and so on). At block <NUM>, the method <NUM> includes performing maintenance and service on the aircraft. The method <NUM> may include performing maintenance and service on the takeoff performance alert system. For example, maintenance and service of the sensor data storage and analysis system may include replacing one or more of the LRU <NUM>, the engine <NUM>, the display device <NUM>, the loudspeaker(s) <NUM>, the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, the sensor(s) <NUM>, and the user interface <NUM>.

Referring to <FIG>, a block diagram of an illustrative implementation of the aircraft <NUM> that includes components of a takeoff performance alert system is shown. In at least one implementation, the aircraft <NUM> is produced by at least a portion of the method <NUM> of <FIG>. As shown in <FIG>, the aircraft <NUM> includes an airframe <NUM>, the engine <NUM>, the display device <NUM>, aircraft deceleration equipment <NUM> (e.g., the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, or a combination thereof), a plurality of systems <NUM>, and an interior <NUM>. Examples of the plurality of systems <NUM> include one or more of a propulsion system <NUM>, an electrical system <NUM>, an environmental system <NUM>, a hydraulic system <NUM>, and a sensor system <NUM>. The sensor system <NUM> includes one or more sensors onboard the aircraft <NUM> and that are configured to generate sensor data during operation of the aircraft <NUM>, such as the one or more sensors <NUM>. The sensor data can indicate one or more parameter values of at least one operational parameter measured by the one or more sensors and one or more timestamps associated with the one or more parameter values.

The aircraft <NUM> also includes the LRU <NUM> including the parameter generator <NUM>, the takeoff roll detector <NUM>, the initial check computer <NUM>, the real-time check computer <NUM>, the alert generator <NUM>, the automatic takeoff rejector <NUM>, the memory <NUM>, or a combination thereof.

Any number of other systems may be included in the aircraft <NUM>. Although an aerospace example is shown, the present disclosure may be applied to other industries. For example, the LRU <NUM> may be used onboard a manned or unmanned aircraft (such as a satellite, a watercraft, or a land-based vehicle).

Apparatus and methods included herein may be employed during any one or more of the stages of the method <NUM> of <FIG>. For example, components or subassemblies corresponding to production process <NUM> may be fabricated or manufactured in a manner similar to components or subassemblies produced while the aircraft <NUM> is in service, at block <NUM> for example and without limitation. Also, one or more apparatus implementations, method implementations, or a combination thereof may be utilized during the production stages (e.g., stages <NUM>-<NUM> of the method <NUM>), for example, by substantially expediting assembly of or reducing the cost of the aircraft <NUM>. Similarly, one or more of apparatus implementations, method implementations, or a combination thereof may be utilized while the aircraft <NUM> is in service, such as during maintenance and service at block <NUM> for example and without limitation.

<FIG> is a block diagram of a computing environment <NUM> including a computing device <NUM> configured to support aspects of computer-implemented methods and computer-executable program instructions (or code) according to the present disclosure. For example, the computing device <NUM>, or portions thereof, is configured to execute instructions to initiate, perform, or control one or more operations described with reference to <FIG>. In some implementations, the computing device <NUM> includes components of LRU <NUM>.

The computing device <NUM> includes one or more processors <NUM>. The processor(s) <NUM> are configured to communicate with system memory <NUM>, one or more storage devices <NUM>, one or more input/output interfaces <NUM>, one or more communications interfaces <NUM>, or any combination thereof. The system memory <NUM> includes volatile memory devices (e.g., random access memory (RAM) devices), nonvolatile memory devices (e.g., read-only memory (ROM) devices, programmable read-only memory, and flash memory), or both. The system memory <NUM> stores an operating system <NUM>, which may include a basic input/output system for booting the computing device <NUM> as well as a full operating system to enable the computing device <NUM> to interact with users, other programs, and other devices. The system memory <NUM> stores data <NUM>, such the initial data <NUM>, the data <NUM> collected during the takeoff roll, the parameters <NUM>, and the threshold data <NUM>.

The system memory <NUM> includes one or more applications <NUM> (e.g., sets of instructions) executable by the processor(s) <NUM>. As an example, the one or more applications <NUM> include instructions executable by the processor(s) <NUM> to initiate, control, or perform one or more operations described with reference to <FIG>. To illustrate, the one or more applications <NUM> include instructions executable by the processor(s) <NUM> to initiate, control, or perform one or more operations described with reference to the LRU <NUM>, such as the parameter generator <NUM>, the takeoff roll detector <NUM>, the initial check computer <NUM>, the real-time check computer <NUM>, the alert generator <NUM>, or a combination thereof.

In a particular implementation, the system memory <NUM> includes a non-transitory, computer-readable medium storing the instructions that, when executed by the processor(s) <NUM>, cause the processor(s) <NUM> to initiate, perform, or control operations for generating a takeoff performance alert during a takeoff associated with an aircraft. The operations include determining, based on initial data collected prior to a takeoff roll of the aircraft, a takeoff rotation speed of the aircraft and a rotation time associated with the takeoff rotation speed. The operations include determining, during the takeoff roll and prior to the rotation time, a predicted speed of the aircraft at the rotation time. The predicted speed is at least partially based on data collected during the takeoff roll. The operations include determining whether an alert condition is satisfied at least partially based on whether a disparity between the takeoff rotation speed and the predicted speed exceeds a rotation speed disparity threshold. The operations include, in response to determining that the alert condition is satisfied, generating the takeoff performance alert.

The one or more storage devices <NUM> include nonvolatile storage devices, such as magnetic disks, optical disks, or flash memory devices. In a particular example, the storage devices <NUM> include both removable and non-removable memory devices. The storage devices <NUM> are configured to store an operating system, images of operating systems, applications (e.g., one or more of the applications <NUM>), and program data (e.g., the program data <NUM>). In a particular aspect, the system memory <NUM>, the storage devices <NUM>, or both, include tangible computer-readable media. In a particular aspect, one or more of the storage devices <NUM> are external to the computing device <NUM>.

The one or more input/output interfaces <NUM> enable the computing device <NUM> to communicate with one or more input/output devices <NUM> to facilitate user interaction. For example, the input/output devices <NUM> can include the user interface <NUM>, the display device <NUM>, the loudspeaker(s) <NUM>, or a combination thereof. As other examples, the one or more input/output interfaces <NUM> can include a display interface, an input interface, or a combination thereof. The processor(s) <NUM> are configured to communicate with devices or controllers <NUM> via the one or more communications interfaces <NUM>. For example, the one or more communications interfaces <NUM> can include a network interface. The devices or controllers <NUM> can include, for example, the sensor(s) <NUM>, the TO/GA control <NUM>, the engine thrust controller <NUM>, the thrust reverser <NUM>, the braking system <NUM>, one or more other devices, or any combination thereof.

In conjunction with the described systems and methods, an apparatus for generating a takeoff performance alert during a takeoff associated with an aircraft is disclosed that includes means for determining, based on initial data collected prior to a takeoff roll of the aircraft, a takeoff rotation speed of the aircraft and a rotation time associated with the takeoff rotation speed. In some implementations, the means for determining the takeoff rotation speed and the rotation time corresponds to the parameter generator <NUM>, the LRU <NUM>, the FMF <NUM>, the processor <NUM>, the computing device <NUM>, one or more other circuits or devices configured to determine the takeoff rotation speed and the rotation time, or a combination thereof.

The apparatus includes means for determining, during the takeoff roll and prior to the rotation time, a predicted speed of the aircraft at the rotation time, and the predicted speed is at least partially based on data collected during the takeoff roll. In some implementations, the means for determining the predicted speed corresponds to the parameter generator <NUM>, the real-time check computer <NUM>, the LRU <NUM>, the DCA <NUM>, the processor <NUM>, the computing device <NUM>, one or more other circuits or devices configured to determine the predicted speed of the aircraft at the rotation time, or a combination thereof.

The apparatus includes means for determining whether an alert condition is satisfied at least partially based on whether a disparity between the takeoff rotation speed and the predicted speed exceeds a rotation speed disparity threshold. In some implementations, the means for determining whether the alert condition is satisfied corresponds to the parameter generator <NUM>, the real-time check computer <NUM>, the LRU <NUM>, the DCA <NUM>, the processor <NUM>, the computing device <NUM>, one or more other circuits or devices configured to determine whether the alert condition is satisfied, or a combination thereof.

The apparatus includes means for generating the takeoff performance alert in response to determining that the alert condition is satisfied. In some implementations, the means for generating the takeoff performance alert corresponds to the alert generator <NUM>, the display device <NUM>, the visual indicator <NUM>, the loudspeaker(s) <NUM>, the LRU <NUM>, the master warning light <NUM>, the PFD including the indicator <NUM>, the EICAS display including the indicator <NUM>, the one or more loudspeakers <NUM>, the processor <NUM>, the computing device <NUM>, one or more other circuits or devices configured to determine generate the takeoff performance alert, or a combination thereof.

In some implementations, a non-transitory, computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to initiate, perform, or control operations to perform part or all of the functionality described above. For example, the instructions may be executable to implement one or more of the operations or methods of <FIG>. To illustrate, the instructions of the applications <NUM>, when executed by the processor(s) <NUM>, can cause the processor(s) <NUM> to initiate, perform, or control to for generating a takeoff performance alert during a takeoff associated with an aircraft. The operations include determining, based on initial data collected prior to a takeoff roll of the aircraft, a takeoff rotation speed of the aircraft and a rotation time associated with the takeoff rotation speed. The operations include determining, during the takeoff roll and prior to the rotation time, a predicted speed of the aircraft at the rotation time. The predicted speed is at least partially based on data collected during the takeoff roll. The operations include determining whether an alert condition is satisfied at least partially based on whether a disparity between the takeoff rotation speed and the predicted speed exceeds a rotation speed disparity threshold. The operations include, in response to determining that the alert condition is satisfied, generating the takeoff performance alert. In some implementations, part or all of one or more of the operations or methods of <FIG> may be implemented by one or more processors (e.g., one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more digital signal processors (DSPs)) executing instructions, by dedicated hardware circuitry, or any combination thereof.

Claim 1:
An aircraft (<NUM>) comprising:
at least one line replaceable unit (<NUM>) configured to:
collect initial data (<NUM>) prior to a takeoff roll of the aircraft received from at least one of: one or more sensors (<NUM>) of the aircraft coupled to the at least one line replaceable unit (<NUM>), and a user interface (<NUM>) coupled to the at least one line replaceable unit (<NUM>);
collect data (<NUM>) during the takeoff roll responsive to the aircraft reaching a first speed (<NUM>)(GSTR1),
determine, based on the initial data (<NUM>) collected prior to a takeoff roll of the aircraft, a takeoff rotation speed (<NUM>)(VR) of the aircraft and a rotation time (<NUM>)(tVR) associated with the takeoff rotation speed;
determine, during the takeoff roll and prior to the rotation time, a predicted speed (<NUM>)(VtVR) of the aircraft at the rotation time, wherein the predicted speed is at least partially based on the data (<NUM>) collected during the takeoff roll, wherein the determination of the predicted speed (<NUM>)(VtVR) of the aircraft is performed responsive to the aircraft reaching a second speed (<NUM>)(GSTR2) that is greater than the first speed (<NUM>)(GSTR1) and lower than a takeoff decision speed (V<NUM>);
determine whether an alert condition (238B) is satisfied at least partially based on whether a disparity (<NUM>)(VR-VtVR_TPA) between the takeoff rotation speed and the predicted speed exceeds a rotation speed disparity threshold (<NUM>); and
generate a takeoff performance alert (<NUM>) in response to the alert condition being satisfied.