Patent Description:
There are several busy airports around the world that have parallel runways that are closely spaced (less than <NUM> feet apart). To land on a closely spaced runway, a pilot may fly using visual flight rules or instrument flight rules, depending on environmental conditions. In VFR (Visual Flight Rules) conditions, visual approaches are authorized by the ATC. In visual approaches, the flight crew is primarily responsible for maintaining separation from other aircraft and maintain adequate wake turbulence separation. In IFR (Instrument Flight Rules) conditions, the ATC is responsible for maintaining separation between aircraft. Approaches can be simultaneously conducted to parallel runways when the centerline separation between the runways is at least <NUM> feet. As may be appreciated, a technical problem is presented in that, in IFR and marginal visual conditions, the runway throughput may drop significantly as aircraft maintain large separations between themselves while landing.

An available solution is a paired approach procedure, which was created to improve runway throughput in these IFR and marginal visual conditions. To facilitate a paired approach procedure (also referred to as a paired approach landing), the ATC detects compatible pairs of aircraft and directs them to the final approach course at a suitable altitude and lateral separation. The trailing aircraft is then expected to maintain a required separation by suitably adjusting its speed before reaching the Final Approach Fix (FAF). The determination of suitable aircraft for paired approach landing is handled by the ATC. Some technical problems remain with the available solution. For example, the aircraft that are descending and entering the terminal area are not aware of the aircraft ahead that they will be paired with, and late notification by ATC about the leading aircraft to be paired with can cause the flight crew to be rushed in their approach preparation during this critical phase of flight. The flight crew has very little time to determine where the spacing goal can be achieved to complete a paired approach while trailing a leading aircraft.

Accordingly, there is a need for pilots to have overview of paired approach feasibility with surrounding traffic and be armed with enough information to optimally negotiate with ATC. Pilots should also be able to do what-if analysis with respect to spacing achievability, speed selection and location for achieving spacing for any aircraft pair. Furthermore, other desirable features and characteristics of the present invention will be apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.

Document <CIT> discloses a Flight Deck Interval Management Paired Approach (FIMPA) system and methods that provide safe speed guidance to a trail aircraft.

Provided is a processor-implemented method for an aircraft to receive and process weather data and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft. The method includes: generating a trajectory of the aircraft as a function of received aircraft state data and weather data; determining that the aircraft is entering a terminal radar approach control (TRACON) airspace; filtering, by the processor, the received traffic data to identify a plurality of neighbor traffic that are entering the TRACON airspace or are within the TRACON airspace when the aircraft is entering the TRACON airspace; estimating, by the processor, concurrently, for each neighbor traffic of the plurality of neighbor traffic: a trajectory, a traffic arrival time at a location for a respective paired approach with the aircraft, a spacing interval between the neighbor traffic and the aircraft for the respective paired approach, and a respective target location for the aircraft to begin the respective paired approach, as a function of the spacing interval; identifying, by the processor, the number of feasible target traffic as those neighbor traffic for which the aircraft can achieve the respective target location within a prescribed amount of time, based on a current speed of the aircraft; identifying, when the aircraft is not permitted a speed change, infeasible target traffic as those neighbor traffic for which the aircraft cannot achieve the respective target location within the prescribed amount of time, based on the current speed of the aircraft; and presenting on a display unit, a lateral image having each feasible target and each infeasible target indicated with a respective icon depicting a location, a heading and distinguishing its feasibility or infeasibility.

Also provided is a system for an aircraft to receive and process weather data and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft, the system comprising: a display unit; and a controller circuit configured by programming instructions to: generate a trajectory of the aircraft as a function of received aircraft state data; determine that the aircraft is entering a terminal radar approach control (TRACON) airspace; filter the received traffic data to identify a plurality of neighbor traffic that are entering the TRACON airspace or are within the TRACON airspace when the aircraft is entering the TRACON airspace; estimate, concurrently, for each neighbor traffic of the plurality of neighbor traffic: a trajectory, a traffic arrival time at a location for a respective paired approach with the aircraft, a spacing interval between the neighbor traffic and the aircraft for the respective paired approach, and a respective target location for the aircraft to begin the respective paired approach, as a function of the spacing interval; identify the number of feasible target traffic as those neighbor traffic for which the aircraft can achieve the respective target location within a prescribed amount of time, based on a current speed of the aircraft and the respective estimations; identify, when the aircraft is not permitted a speed change, infeasible target traffic as those neighbor traffic for which the aircraft cannot achieve the respective target location within the prescribed amount of time, based on the current speed of the aircraft; and present on the display unit, a lateral image having each feasible target and each infeasible target indicated with a respective icon depicting a location, a heading and its feasibility.

In another embodiment, a method for an aircraft entering a terminal radar approach control (TRACON) airspace to identify a number of feasible target traffic for a paired approach for the aircraft is provided. The method includes: at a controller circuit programmed by programming instructions: receiving weather data; receiving traffic data from a plurality of traffic; filtering the received traffic data to identify a plurality of neighbor traffic that are entering the TRACON airspace or are within the TRACON airspace when the aircraft is entering the TRACON airspace; estimating, concurrently, for each neighbor traffic of the plurality of neighbor traffic that are entering the TRACON airspace or within the TRACON airspace: a trajectory, a traffic arrival time at a location for a respective paired approach with the aircraft, a spacing interval between the neighbor traffic and the aircraft for the respective paired approach, and a respective target location for the aircraft to begin the respective paired approach, as a function of the spacing interval; identifying, based on the estimations, the number of feasible target traffic as those neighbor traffic for which the aircraft can achieve the respective target location within a prescribed amount of time, based on a current speed of the aircraft; and presenting on a display unit, a lateral image having an icon depicting the aircraft, its location, and its heading and having each feasible target indicated with a respective icon depicting a location, a heading and its feasibility.

Furthermore, other desirable features and characteristics of the system and method will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the preceding background.

At least one example of the present invention will hereinafter be described in conjunction with the following figures, wherein like numerals denote like elements, and:.

The following Detailed Description is merely exemplary in nature and is not intended to limit the invention or the application and uses of the invention. The term "exemplary," as appearing throughout this document, is synonymous with the term "example" and is utilized repeatedly below to emphasize that the description appearing in the following section merely provides multiple non-limiting examples of the invention and should not be construed to restrict the scope of the invention, as set-out in the Claims, in any respect. As further appearing herein, the term "pilot" encompasses all users of the below-described aircraft system.

As mentioned, to facilitate a paired approach procedure (also referred to as a paired approach landing), the ATC detects compatible pairs of aircraft and directs them to the final approach course at a suitable altitude and lateral separation. The trailing aircraft is then expected to maintain a required separation by suitably adjusting its speed before reaching the Final Approach Fix (FAF). The determination of suitable aircraft for paired approach landing is handled by the ATC. Technical limitations of available solutions result in reduced runway throughput in IFR and marginal visual conditions.

The present disclosure provides a technical solution to the limitations of available solutions, in the form of systems and methods for an aircraft to identify a number of feasible target traffic for a paired approach for the aircraft. The present disclosure provides a pilot with an overview of paired approach feasibility with surrounding traffic and arms the pilot with enough information to optimally negotiate with air traffic control (ATC). Using the information provided by the present disclosure, pilots are able to do what-if analysis with respect to spacing achievability, speed selection and location for achieving spacing for pairing with any potential lead aircraft. The provided systems and methods automate the processes of receiving and processing weather data and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft and presenting this information on a display system. The display system may be onboard the aircraft of part of an electronic flight bag (EFB) or other portable electronic device.

<FIG> is a block diagram of a system <NUM> for an aircraft to receive and process weather data and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft (shortened hereinafter to "system <NUM>"), as illustrated in accordance with an exemplary and non-limiting embodiment of the present disclosure. The system <NUM> may be utilized onboard a mobile platform <NUM> to provide feasible target traffic for a paired approach for the aircraft, as described herein. In various embodiments, the mobile platform is an aircraft <NUM>, which carries or is equipped with the system <NUM>. As schematically depicted in <FIG>, system <NUM> may include the following components or subsystems, each of which may assume the form of a single device, system on chip (SOC), or multiple interconnected devices: a controller circuit <NUM> operationally coupled to: at least one display unit <NUM>; a user input device <NUM>; and ownship systems/data sources <NUM>. In various embodiments, the system <NUM> may be separate from or integrated within: a FMS computer and/or a flight control system (FCS). The system <NUM> may also contain a communications circuit <NUM> with an antenna, configured to wirelessly transmit data to and receive real-time data and signals from various external sources. In various embodiments, the external sources include traffic <NUM> for providing traffic data, air traffic control (ATC <NUM>), and a weather forecasting source that provides weather data <NUM>. These functional blocks are described in more detail below.

Although schematically illustrated in <FIG> as a single unit, the individual elements and components of the system <NUM> can be implemented in a distributed manner utilizing any practical number of physically distinct and operatively interconnected pieces of hardware or equipment. When the system <NUM> is utilized as described herein, the various components of the system <NUM> will typically all be located onboard the Aircraft <NUM>.

The term "controller circuit," as appearing herein, broadly encompasses those components utilized to carry-out or otherwise perform the processes and/or support the processing functionalities of the system <NUM>. Accordingly, controller circuit <NUM> can encompass or may be associated with a programmable logic array, and an application specific integrated circuit or other similar firmware, as well as any number of individual processors, flight control computers, navigational equipment pieces, computer-readable memories (including or in addition to memory <NUM>), power supplies, storage devices, interface cards, and other standardized components. In various embodiments, as shown in <FIG>, the controller circuit <NUM> may embody one or more processors operationally coupled to data storage having stored therein at least one firmware or software program (generally, a program product or program of computer-readable instructions that embody an algorithm) for carrying-out the various process tasks, calculations, and control/display functions described herein. During operation, the controller circuit <NUM> may execute an algorithm for receiving and processing weather data <NUM> and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft <NUM>, and thereby perform the various process steps, tasks, calculations, and control/display functions described herein. In various embodiments, the algorithm is embodied as at least one firmware or software program (e.g., program <NUM>).

Communications circuit <NUM> is configured to provide a real-time bidirectional wired and/or wireless data exchange for the processor <NUM> with the ownship data sources <NUM>, the user input device <NUM>, the display unit <NUM>, and the external sources to support operation of the system <NUM> in embodiments. In various embodiments, the communications circuit <NUM> may include a public or private network implemented in accordance with Transmission Control Protocol/Internet Protocol architectures and/or other conventional protocol standards. Encryption and mutual authentication techniques may be applied, as appropriate, to ensure data security. In some embodiments, the communications circuit <NUM> is integrated within the controller circuit <NUM> as shown in <FIG>, and in other embodiments, the communications circuit <NUM> is external to the controller circuit <NUM>.

A variety of ownship data sources <NUM> and systems may be operationally coupled to the controller circuit <NUM>. In various embodiments, the ownship data sources <NUM> includes an autopilot system (AP <NUM>), a flight management controller FMC <NUM>, on-board sensors <NUM>, and an autopilot <NUM>. In various embodiments, the ownship systems/data sources <NUM> additionally includes a traffic controller <NUM>. In various embodiments, a flight plan (FP <NUM>) may be provided by a flight management system (FMS). On-board sensors <NUM> include flight parameter sensors and geospatial sensors and supply various types of aircraft state data or measurements to controller circuit <NUM> during aircraft operation. In various embodiments, the aircraft state data (supplied by the on-board sensors <NUM>) include, without limitation, one or more of: inertial reference system measurements providing a location, Flight Path Angle (FPA) measurements, airspeed data, groundspeed data (including groundspeed direction), vertical speed data, vertical acceleration data, altitude data, attitude data including pitch data and roll measurements, yaw data, heading information, sensed atmospheric conditions data (including wind speed and direction data), flight path data, flight track data, radar altitude data, and geometric altitude data. In various embodiments, the aircraft state data (supplied by the on-board sensors <NUM>) additionally includes on-board sensed weather data associated with the immediate surroundings of the aircraft <NUM>.

External sources include one or more other aircraft (also referred to as neighbor traffic, or simply, traffic <NUM>), air traffic control (ATC) <NUM>, and a source of weather data <NUM>. With respect to the present invention, weather data <NUM> includes meteorological weather information and may be provided by any one or more weather data sources, such as, uplink weather (XM/SXM, GDC/GoDirect Weather), NOTAM/D-NOTAM, TAF, and D-ATIS.

Each traffic <NUM> of a plurality of traffic <NUM> encodes and transmits its own state parameters and other identifying information to the aircraft <NUM> using a traffic communication protocol, such as automatic dependent surveillance broadcast (ADS-B). In various embodiments, a traffic controller <NUM> receives the data from the plurality of traffic <NUM> and decodes it using the same communication protocol to thereby associate each neighbor traffic <NUM> with its respective state parameters. In an embodiment, the controller circuit <NUM> receives traffic data comprising, for a neighbor traffic, its respective traffic state parameters. In an embodiment, the traffic <NUM> is one of a plurality of traffic, and the controller circuit <NUM> receives neighbor traffic data comprising, for each neighbor traffic <NUM> of the plurality of neighbor traffic <NUM>, their respective traffic state parameters.

On-board the aircraft <NUM>, a flight management controller (FMC <NUM>) may generate commands, such as speed commands, for the autopilot <NUM>. In various embodiments, the controller circuit <NUM> generates commands for the FMC <NUM>. As will be described in more detail below, the controller circuit <NUM> may generate commands for the FMC <NUM> to command the autopilot <NUM> to increase or decrease speed.

A display unit <NUM> can include any number and type of image generating devices on which one or more avionic displays <NUM> may be produced. When the system <NUM> is utilized for a manned Aircraft, display unit <NUM> may be affixed to the static structure of the Aircraft cockpit as, for example, a Head Down Display (HDD) or Head Up Display (HUD) unit. Alternatively, display unit <NUM> may assume the form of a movable display device (e.g., a pilot-worn display device) or a portable display device, such as an Electronic Flight Bag (EFB), a laptop, or a tablet computer carried into the Aircraft cockpit by a pilot.

At least one avionic display <NUM> is generated on display unit <NUM> during operation of the system <NUM>; the term "avionic display" defined as synonymous with the term "aircraft-related display" and "cockpit display" and encompasses displays generated in textual, graphical, cartographical, and other formats. The system <NUM> can generate various types of lateral and vertical avionic displays on which map views and symbology, text annunciations, and other graphics pertaining to flight planning are presented for a pilot to view. In various embodiments, the display unit <NUM> is configured to continuously render at least a lateral display showing the Aircraft <NUM> at its current location within the map data. Specifically, embodiments of avionic displays <NUM> include one or more two dimensional (2D) avionic displays, such as a horizontal (i.e., lateral) navigation display or vertical navigation display; and/or on one or more three dimensional (3D) avionic displays, such as a Primary Flight Display (PFD) or an exocentric 3D avionic display.

In various embodiments, the avionic display <NUM> generated and controlled by the system <NUM> can include a user input interface, including graphical user interface (GUI) objects and alphanumeric displays of the type commonly presented on the screens of MCDUs, as well as Control Display Units (CDUs) generally.

In various embodiments, a human-machine interface is implemented as an integration of a user input device <NUM> and a display unit <NUM>. In various embodiments, the display unit <NUM> is a touch screen display. In various embodiments, the human-machine interface also includes a separate user input device <NUM> (such as a keyboard, cursor control device, voice input device, or the like), generally operationally coupled to the display unit <NUM>. Via various display and graphics systems processes, the controller circuit <NUM> may command and control a touch screen display unit <NUM> to generate a variety of graphical user interface (GUI) objects or elements described herein, including, for example, buttons, sliders, and the like, which are used to prompt a user to interact with the human-machine interface to provide user input; and for the controller circuit <NUM> to activate respective functions and provide user feedback, responsive to received user input at the GUI element.

With continued reference to <FIG>, in various embodiments, the controller circuit <NUM> may take the form of an enhanced computer processer and include a processor <NUM> and a memory <NUM>. Memory <NUM> is a data storage that can encompass any number and type of storage media suitable for storing computer-readable code or instructions, such as the aforementioned software program <NUM>, as well as other data generally supporting the operation of the system <NUM>. Memory <NUM> may also store one or more preprogrammed variables <NUM> and thresholds, for use by an algorithm embodied in the software program <NUM>. Examples of preprogrammed variables <NUM> include preprogrammed or prescribed amounts of time and distances described below.

In various embodiments, the system <NUM> may employ one or more database(s) <NUM>; they may be integrated with memory <NUM> or separate from it. In various embodiments, two- or three-dimensional map data may be stored in a database <NUM>, including airport features data, geographical (terrain), buildings, bridges, and other structures, street maps, and navigational databases, which may be updated on a periodic or iterative basis to ensure data timeliness. This map data may be uploaded into the database <NUM> at an initialization step and then periodically updated, as directed by either a program <NUM> update or by an externally triggered update.

In various embodiments, aircraft-specific parameters and information for aircraft <NUM> may be stored in the database <NUM> and referenced by the program <NUM>. Non-limiting examples of aircraft-specific information includes an aircraft weight and dimensions, performance capabilities, configuration options, and the like. In an embodiment, minimum radar separation requirements for various aircraft may be stored in the database <NUM> and referenced by the program <NUM>. Table <NUM>, which is referenced further below, provides an example of minimum radar separation requirements for various aircraft.

We turn now to <FIG> to describe the operation of the system <NUM>. The controller circuit <NUM> is configured by programming instructions to perform the functions and tasks attributed to the system <NUM>. The controller circuit <NUM> determines a feasible traffic for pairing based on a current speed of the aircraft <NUM>. The controller circuit <NUM> identifies the number of feasible target traffic as those neighbor traffic for which the aircraft <NUM> can achieve the respective target location within a prescribed amount of time, based on a current speed of the aircraft <NUM>. The controller circuit <NUM> identifies infeasible target traffic as those neighbor traffic for which the aircraft <NUM> cannot achieve the respective target location within the prescribed amount of time, based on the current speed of the aircraft <NUM> and when the aircraft <NUM> is not permitted a speed change.

<FIG> is a simplified illustration for the purpose of describing operations of the system <NUM>. In <FIG>, two neighbor aircraft are identified as feasible target traffic; in practice, there may be many more traffic and many more identified feasible target traffic. In various embodiments, a first neighbor aircraft (L1) is shown inside the terminal radar approach control (TRACON) airspace <NUM> and having a flight path <NUM> to a runway 28R. A second neighbor aircraft (L2) is shown outside the TRACON airspace <NUM>, but heading toward it, and having a flight path <NUM> to a runway <NUM>. Each of the neighbor aircraft L1 and L2 are referred to as leading aircraft, because they are ahead of the aircraft <NUM>. In an embodiment, an icon depicting the aircraft <NUM>, its location and heading, is shown entering a terminal radar approach control (TRACON) airspace <NUM>.

In order to perform the analysis, the controller circuit <NUM> generates a trajectory of the aircraft <NUM> as a function of available data from onboard ownship data sources <NUM>, such as the aircraft state data, the FP <NUM>, and weather data <NUM>. Comparing a current position of the aircraft to available map data, the controller circuit <NUM> can determine that the aircraft is entering the TRACON airspace. The controller circuit <NUM> receives traffic data and filters the received traffic data, using the traffic state parameters, to identify a plurality of neighbor traffic that are entering the TRACON airspace or are within the TRACON airspace when the aircraft <NUM> is entering the TRACON airspace (in this example, the plurality of neighbor traffic is illustrated with L1 and L2).

The system <NUM> employs a spacing requirement (the spacing requirement may include a spacing interval and a location) in the evaluation of the neighbor traffic for feasibility of pairing. The spacing interval may be referred to as an amount of time or as a distance. The system <NUM> can receive the spacing requirements from ATC commands or from a user, such as the pilot, such as, after hearing or reading an ATC command. The ATC spacing requirement can reflect traffic density, weight class of participating aircraft, expected turbulence, etc. If no entry is made for a spacing requirement, the system <NUM> will default to the final approach fix (FAF) as the location where spacing needs to be achieved.

In operation, the controller circuit <NUM> processes available data and estimates, concurrently, for each neighbor traffic of the plurality of neighbor traffic: a trajectory, a traffic arrival time at an ideal location for a respective paired approach with the aircraft, a spacing interval between the neighbor traffic and the aircraft for the respective paired approach, and a respective target location for the aircraft to begin the respective paired approach, as a function of the spacing interval (collectively referred to as the estimated information). With respect to <FIG>, the elements of the estimated information are defined as follows.

The estimated trajectory of L1 is <NUM> and the estimated trajectory of L2 is <NUM>. For the aircraft <NUM> to perform a paired approach landing (of the type target straight approach) with L1, that means L1 lands on runway 28R and the aircraft <NUM> lands on runway <NUM>, utilizing a first desired spacing interval <NUM>, indicated in distance from L1 at location <NUM>. In this example, location <NUM> is, for L1, an ideal location for a respective paired approach with the aircraft <NUM>. In the figure, the aircraft <NUM>, using trajectory <NUM>, is shown following L1 with the first desired spacing interval by the time aircraft <NUM> arrives at location <NUM>, which is prior to location <NUM>, which is a latest possible location for this paired approach. In this example, location <NUM> is a target location for the aircraft to begin the respective paired approach with L1. The target location <NUM> is a function of the spacing interval <NUM> and an estimated traffic arrival time of L1 at location <NUM>.

For the aircraft <NUM> to perform a paired approach (of the type SOIA, simultaneous offset instrument approach) with L2, this means L2 lands on runway <NUM> and the aircraft <NUM> lands on runway 28R, utilizing a second desired spacing interval <NUM>, indicated in distance from L2 at location <NUM>. In this example, location <NUM> is, for L2, an ideal location for a respective paired approach with the aircraft <NUM>. In the figure, the aircraft <NUM>, using trajectory <NUM>, is shown following L2 with the second desired spacing interval by the time aircraft <NUM> arrives at location <NUM>, which is prior to location <NUM>, which is a latest possible location for this paired approach. In this example, location <NUM> is a target location for the aircraft to begin the respective paired approach with L2. The target location <NUM> is a function of the spacing interval <NUM> and an estimated traffic arrival time of L2 at location <NUM>.

Turning now to <FIG>, the controller circuit <NUM> presents, on the display unit <NUM>, a lateral image <NUM>. In an embodiment, the controller circuit <NUM> presents, on the display unit <NUM>, a lateral image <NUM> having each feasible target (<NUM>, <NUM>, <NUM>, <NUM>) with a respective icon depicting a location, a heading and distinguishing its feasibility. In an embodiment, the controller circuit <NUM> presents, on the display unit <NUM>, a lateral image <NUM> having each feasible target (<NUM>, <NUM>, <NUM>, <NUM>) and each infeasible target (<NUM>, <NUM>, <NUM>, <NUM>) indicated with a respective icon depicting a location, a heading and distinguishing its feasibility or infeasibility. The system <NUM> employs a visualization technique that makes these three categories visually and intuitively distinguishable from each other. In the example of <FIG>, the neighbor traffic are each represented with triangles with their narrow point in the direction of their heading. The feasible traffic are each outlined with a solid line, and the infeasible traffic each have an X. Marginally feasible traffic (described below) are outlined with a dashed line. In other embodiments, other visualization techniques make be used, for example, using colors to indicate feasibility (for example, green for feasible, yellow for marginally feasible, and red for infeasible).

In some embodiments, the aircraft <NUM> may be permitted a speed change. When the aircraft <NUM> cannot achieve the respective target location within the prescribed amount of time, based on the current speed of the aircraft <NUM>, the controller circuit <NUM> may determine an interval error between the respective target location and an actual location of the aircraft at an expiration of the prescribed amount of time. The controller circuit <NUM> may then use the interval error to compute a speed change required for the aircraft <NUM> to achieve the respective target location within the prescribed amount of time; hence, the speed change required is a function of the interval error.

The controller circuit <NUM> determines whether the speed change is permissible. Factors considered in the determination of permissible speed change include aircraft-specific capabilities of aircraft <NUM>, traffic congestion in the area, weather, and the like. The controller circuit <NUM> may identify a given neighbor traffic as marginally feasible target traffic when the speed change is permissible. As shown in <FIG>, the controller circuit <NUM> may present, on the display unit <NUM>, each of the marginally feasible target traffic (e.g., <NUM>), indicated with a respective icon depicting its location, heading and that it is a marginally feasible target traffic.

In various embodiments, the controller circuit <NUM> further determines, for each feasible target traffic, an overall feasibility rank based on its weight class and its speed, with a ranking of <NUM> being the most suitable, and displays in the lateral image <NUM> a number alongside each icon for feasible target traffic, the number reflecting a rank in overall feasibility. In <FIG>, feasible target <NUM> is ranked <NUM>, feasible target <NUM> is ranked <NUM>, and feasible target <NUM> is ranked <NUM>. In various determinations, such as overall rank, and the previously described spacing intervals, a weight class of the lead aircraft (e.g. neighbor aircraft herein) and ownship aircraft <NUM> may be processed with other data. A table such as Table <NUM>, below, may be referenced to determine feasibility/infeasibility and for separation requirements. In various embodiments, the information of Table <NUM> may be stored in the memory <NUM>, potentially as preprogrammed variables <NUM>. As may be appreciated, the minimum radar separation may be converted between distance and time, using current speeds.

In various embodiments, the controller circuit <NUM> further determines, for the infeasible traffic, a reason for infeasiblity from among a plurality of reasons. For example, the infeasible traffic may be traveling too fast, traveling too slow, or be in too heavy of a weight class. The controller circuit <NUM> may indicate the infeasibility determinations on the lateral image <NUM> with a label that indicates the reason. In <FIG>, infeasible target <NUM> and infeasible target <NUM> are labeled H for too heavy, infeasible target <NUM> is labeled F for too fast and infeasible target <NUM> is labeled S for too slow.

In various embodiments, in addition to the lateral image described above, the system <NUM> generates and displays a graphical user interface (GUI) that provides alphanumeric information related to the above described determinations. The GUI may be rendered in a dedicated area on the lateral image, or on a separate display unit. The displaying of the GUI may be responsive to detecting a user selection of a neighbor traffic on the lateral image <NUM>, and then the system <NUM> responds to the user selection by displaying information including the estimated information for the selected neighbor traffic. Using the information provided by the GUI, pilots are able to do what-if analysis with respect to spacing achievability, speed selection and location for achieving spacing for pairing with any potential lead aircraft.

Turning now to <FIG> and <FIG>, GUI <NUM> and GUI <NUM> are described. Neighbor traffic UAL2345 has been selected. GUI <NUM> and GUI <NUM> display the identification of the selected traffic in the traffic identification text box <NUM> and a spacing interval of <NUM> seconds is displayed in the spacing interval box. A desired location of termination point plus <NUM> nautical miles is depicted in text box <NUM>. In text box <NUM>, the system <NUM> has determined that the spacing interval (text box <NUM>) for this traffic id (text box <NUM>) at this desired location (text box <NUM>) are feasible, and the word "feasible" is displayed. The achieved at location (text box <NUM>) is the same as the desired location. An active speed plan in text box <NUM> can be aligned with the distance remaining entries in text box <NUM> to view a ramp down in speed from <NUM> KTS with a distance remaining of <NUM> down to <NUM> KTS at a distance remaining of <NUM>.

In a contrasting example for the same traffic identification <NUM>, in <FIG>, the system <NUM> has determined that the interval status <NUM> is "not feasible," as shown. An amended speed plan is calculated by the system <NUM> and displayed in text box <NUM>. The amended speed plan indicates speed changes, determined by the processor, required to reach a required speed at a minimum distance remaining. In the example, the required speed at a minimum distance remaining is <NUM> KTS at <NUM>. A comparison of the entries in text box <NUM> to those in text box <NUM> for the distance remaining points in box <NUM>, shows the increase in speed required. Speed would have to be increased to <NUM> KTS at the distance remaining of <NUM> and to <NUM> KTS at the distance remaining of <NUM>; after that, the amended speed plan matches the active speed plan. However, the pairing could not occur at the desired location shown in box <NUM>, instead it would not occur until the termination point plus <NUM>. In the example of <FIG>, the increased speed was not determined permissible and therefore the traffic is identified as not feasible for pairing.

Turning now to <FIG>, the system <NUM> described above may be implemented by a processor-executable method <NUM>. For illustrative purposes, the following description of method <NUM> may refer to elements and modules mentioned above in connection with <FIG>. In practice, portions of method <NUM> may be performed by different components of the described system. It should be appreciated that method <NUM> may include any number of additional or alternative tasks, the tasks shown in <FIG> need not be performed in the illustrated order, and method <NUM> may be incorporated into a more comprehensive procedure or method having additional functionality not described in detail herein. Moreover, one or more of the tasks shown in <FIG> could be omitted from an embodiment of the method <NUM> as long as the intended overall functionality remains intact.

At <NUM>, the system <NUM> has already been initialized. Initialization may include loading instructions and program <NUM> into a processor within the controller circuit <NUM>, as well as loading preprogrammed variables <NUM>, map data, weight class specifications, and aircraft-specific features into one or more database(s) <NUM>.

At <NUM> the system <NUM> gathers or receives from external sources traffic data as well as weather data, and a flight plan. The system <NUM> may use ADS-B for traffic data transmissions. In some embodiments, at <NUM> the system <NUM> also receives ATC commands.

At <NUM>, the system <NUM> estimates and generates lateral and vertical trajectories for the neighbor traffic based on data collected at <NUM>. At <NUM>, after filtering the received traffic data to identify a plurality of neighbor traffic that are entering the TRACON airspace or within the TRACON airspace when the aircraft is entering the TRACON airspace, the system <NUM> computes arrival information for the traffic at the respective locations where the spacing interval needs to begin. At <NUM>, the system <NUM> computes the spacing interval based on the traffic arrival information and ownship capabilities. As one may appreciate, the spacing interval may be converted back and forth between a time and a distance, depending on how it is used. At <NUM>, the system <NUM> determines whether the spacing interval can be achieved at the desired location. If yes at <NUM>, the system <NUM> performs periodic assessments and refinements to the commands from the flight management controller <NUM> to the AP <NUM>. If no at <NUM>, the system <NUM> begins speed adjustment <NUM>.

Speed adjustment <NUM> includes computing a spacing interval error at the desired location at <NUM> and updating ownship speed plan by converting the spacing interval error into a delta speed change parameter (i.e., the increased speed that is needed) at <NUM>. At <NUM>, the ownship trajectory is regenerated with the updated speed plan. The Amended speed plan <NUM> of <FIG> is an example of an updated speed plan. At <NUM>, the spacing interval error at the desired location is re-computed. At <NUM>, the system <NUM> determines whether the re-computed spacing interval is within an acceptable tolerance. If yes at <NUM>, the system <NUM> switches back to periodic refinement <NUM>. If no at <NUM>, the system <NUM> may re-initiate speed adjustments by returning to <NUM>, or end.

Thus, enhanced systems and methods for an aircraft to identify a number of feasible target traffic for a paired approach for the aircraft are provided. By processing traffic data with the aircraft-specific ownship data (from ownship data sources <NUM>), the system <NUM> is able to not only identify a number of feasible target traffic for a paired approach for the aircraft, but also provide useful information such as a feasibility rank for feasible traffic, and reasons for infeasibility for other traffic, on an easy to comprehend visual display, providing an objectively improved human-machine interface.

Although an exemplary embodiment of the present disclosure has been described above in the context of a fully-functioning computer system (e.g., system <NUM> described above in conjunction with <FIG>), those skilled in the art will recognize that the mechanisms of the present disclosure are capable of being distributed as a program product (e.g., an Internet-disseminated program or software application that includes program <NUM>) and, further, that the present teachings apply to the program product regardless of the particular type of computer-readable media (e.g., hard drive, memory card, optical disc, etc.) employed to carry-out its distribution.

Claim 1:
A processor-implemented method for an aircraft (<NUM>) to receive and process weather data and traffic data to identify a number of feasible target traffic for a paired approach for the aircraft, the method comprising:
generating a trajectory of the aircraft as a function of received aircraft state data and weather data;
determining that the aircraft is entering a terminal radar approach control, TRACON, airspace;
filtering, by a processor (<NUM>) of the aircraft, the received traffic data to identify a plurality of neighbor traffic that are entering the TRACON airspace or are within the TRACON airspace when the aircraft is entering the TRACON airspace;
estimating, by the processor, concurrently, for each neighbor traffic of the plurality of neighbor traffic:
a trajectory, a traffic arrival time at a location for a respective paired approach with the aircraft, a spacing interval between the neighbor traffic and the aircraft for the respective paired approach, and a respective target location for the aircraft to begin the respective paired approach, as a function of the spacing interval;
identifying, by the processor, the number of feasible target traffic as those neighbor traffic for which the aircraft can achieve the respective target location within a prescribed amount of time, based on a current speed of the aircraft;
identifying, when the aircraft is not permitted a speed change, infeasible target traffic as those neighbor traffic for which the aircraft cannot achieve the respective target location within the prescribed amount of time, based on the current speed of the aircraft; and
presenting on a display unit (<NUM>), a lateral image for viewing by a pilot of the aircraft, the lateral image having each feasible target (<NUM>, <NUM>, <NUM>, <NUM>) and each infeasible target (<NUM>, <NUM>, <NUM>, <NUM>) indicated with a respective icon depicting a location, a heading and distinguishing its feasibility or infeasibility.