Patent Application
20210233412
This application claims priority to Indian Provisional Patent Application No. 202011003065, filed Jan. 23, 2020, the entire content of which is incorporated by reference herein.
The technical field generally relates to communications between aircraft and air traffic control (ATC), and more particularly relates to systems and methods for reducing controller-pilot rejection ratios.
Controller-pilot data link communication (CPDLC) is a means of communication between a controller at ATC and a pilot of an aircraft, generally using a data link for the communication. CPDLC systems include a set of predefined clearance/information/request message elements that correspond to voice phraseology employed during ATC procedures. The controller is provided with the capability to issue to the pilot level assignments, crossing constraints, lateral deviations, route changes and clearances, speed assignments, radio frequency assignments, and various requests for information. The pilot is provided with the capability to respond to the ATC messages, ATC request clearances and information, to report to ATC information, including declaring/rescinding an emergency. The pilot is, in addition, provided with the capability to request conditional clearances (downstream) and information from a downstream air traffic service unit (ATSU). A CPDLC system ‘dialogue’ includes a sequence of messages between the controller and a pilot relating to a particular transaction (for example a request for clearance and a receipt of a clearance grant). Moreover, one dialogue can include several sequences of messages, each of which is closed by means of appropriate messages, usually of acknowledgement or acceptance. Therefore, available CPDLC systems are burdened with the technical problem of requiring the continued involvement of a human at each end of the communication; from the pilot's perspective this can be very time-consuming and inefficient.
Accordingly, improved CPDLC systems and methods that reduce the amount of pilot involvement are desirable. It is desirable to make them adaptable, responsive to real-time environmental information and available cockpit data. The following disclosure provides these technological enhancements, in addition to addressing related issues.
This summary is provided to describe select concepts in a simplified form that are further described in the Detailed Description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Provided is a processor implemented method for reducing controller-pilot data link (CPDLC) rejection ratio on an aircraft, comprising: receiving, from a navigation system onboard the aircraft, navigation data for the aircraft; receiving sensor data from a sensor system; receiving traffic data from an external traffic data source; displaying a CPDLC window on a display system; receiving a tentative CPDLC request; processing the navigation data, traffic data, and tentative CPDLC request with airport features data to predict whether the tentative CPDLC request will be accepted; and displaying a dialogue box based upon the prediction, wherein the displayed dialogue box indicates: acceptance upon predicting that the tentative CPDLC request will be accepted; or rejected and an alternative CPDLC request upon predicting that the tentative CPDLC request will not be accepted.
Also provided is a system for reducing controller-pilot data link (CPDLC) rejection ratio on an aircraft, comprising: a navigation system providing navigation data for the aircraft; a sensor system onboard the aircraft; and a processor operationally coupled to the navigation system and sensor system and configured to: display a CPDLC window on a display system; receive a tentative CPDLC request; receive traffic data from an external traffic data source; process the navigation data, traffic data, and tentative CPDLC request with airport features data to predict whether the tentative CPDLC request will be accepted by air traffic control (ATC), and that air traffic control (ATC) will accept the tentative CPDLC request in a first amount of time; and upon predicting that the tentative CPDLC request will be accepted, display a dialogue box indicating acceptance; and display the first amount of time.
An embodiment of an aircraft is also provided. The aircraft includes: a navigation system providing navigation data for the aircraft; a sensor system onboard the aircraft; and a processor of a system for reducing controller-pilot data link (CPDLC) rejection ratio, the processor operationally coupled to the navigation system and sensor system and configured to: display a CPDLC window on a display system; receive a tentative CPDLC request; receive traffic data from an external traffic data source; process the navigation data, traffic data, and tentative CPDLC request with airport features data to predict whether the tentative CPDLC request will be accepted by air traffic control (ATC); and display a dialogue box based upon the prediction, wherein the displayed dialogue box indicates: accepted and a first amount of time upon predicting that the tentative CPDLC request will be accepted by ATC in the first amount of time; or rejected, an alternative CPDLC request, and a second amount of time upon predicting that the tentative CPDLC request will not be accepted, but the alternative CPDLC request will be accepted in the second amount of time.
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.
The present application will hereinafter be described in conjunction with the following drawing figures, wherein like numerals denote like elements, and:
The following detailed description is merely illustrative in nature and is not intended to limit the embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Thus, any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. The embodiments described herein are exemplary embodiments provided to enable persons skilled in the art to make or use the invention and not to limit the scope of the invention that is defined by the claims. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, summary, or the following detailed description.
CPDLC systems generally generate a CPDLC display window on an on-board display system (
Departure Clearance Action Message Box
Departure Clearance Uplink Example
Pre-Departure Clearance (PDC) Pop-up
CDR Pop-up
CDR Request Downlink Pop-up
Pushback Clearance Request Pop-up
Pushback/Taxi Pop-up
Taxi Clearance Request Downlink Pop-up
Oceanic Clearance Pop-up
Oceanic Clearance Request Pop-upc
As mentioned, one CPDLC system dialogue can include several sequences of messages, each sequence being closed by means of appropriate messages, usually of acknowledgement or acceptance. This presents a technical problem in that available CPDLC systems require the continued engagement of a human at each end of the communication. From a pilot's perspective, this continued engagement can be time-consuming and inefficient. Additionally, using the available CPDLC systems, the pilot can only choose the predefined CPDLC messages without being able to consider, or be informed by, the current conditions that the controller at ATC may be considering to approve/reject the request. This can increase a likelihood of a CPDLC rejection. Reacting to a CPDLC rejection from ATC introduces a time delay. The turnaround time for the pilot analyzing the rejection of the CPDLC request, particularly in single-pilot cockpit scenarios, can lead to transmitting further invalid CPDLC requests to ATC and unnecessary time delay for the pilot. Any of the above technical problems can cause an elevated rejection ratio of CPDLC requests. The proposed system for reducing CPDLC rejection ratios (
Turning now to
In operation, the controller 104 may be operationally coupled to any combination of the following systems and apparatus: one or more sources 106 of cockpit data 107 (including an inertial navigation system/navigation system 118; a flight management system (FMS) 119; an airport features database 120; and a sensor system 122); a communication system and fabric 124; a display system 116; and a user input device 114. In various embodiments, the controller 104 is also operationally coupled to external sources, such as air traffic control (ATC) 50 and external traffic, referred to as traffic data sources 52, each of which communicate wirelessly with the controller 104. These functional blocks are described in more detail below.
In some embodiments, the controller 104 may be integrated within a preexisting mobile platform management system, avionics system, cockpit display system (CDS), flight controls system (FCS), or flight management system (FMS). Although the controller 104 is shown as an independent functional block, onboard the aircraft 100, in other embodiments, it may exist in an electronic flight bag (EFB) or portable electronic device (PED), such as a tablet, cellular phone, or the like. In embodiments in which the controller is within an EFB or a PED, a display system 116 and a user input device 114 may also be part of the EFB or PED.
The inertial navigation system 118 provides real-time aircraft state data. Real-time aircraft state data may include any of: an instantaneous location (e.g., the latitude, longitude, orientation), an instantaneous heading (i.e., the direction the aircraft is traveling in relative to some reference), a flight path angle, a vertical speed, a ground speed, an instantaneous altitude (or height above ground level), and a current phase of flight of the aircraft 100. As used herein, “real-time” is interchangeable with current and instantaneous. The inertial navigation system 118 may be realized as including a global positioning system (GPS), inertial reference system (IRS) or AHRS, or a radio-based navigation system (e.g., VHF omni-directional radio range (VOR) or long-range aid to navigation (LORAN)), and may include one or more navigational radios, barometers, or other sensors suitably configured to support operation of a flight management system (FMS), as will be appreciated in the art. In various embodiments, the data referred to herein as the real-time aircraft state data may be referred to as navigation data. The real-time aircraft state data is made available, generally by way of the communication system and fabric 124, so other components, such as the controller 104 and the display system 116, may further process and/or handle the aircraft state data.
In various embodiments, the communications system and fabric 124 is configured to support instantaneous (i.e., real-time or current) communications between on-board systems, the controller 104, external traffic data sources 52, and ATC 50. As a functional block, the communications system and fabric 124 may represent one or more transmitters, receivers, and the supporting communications hardware and software required for components of the system 102 to communicate as described herein. In various embodiments, the communications system and fabric 124 has bidirectional pilot-to-ATC (air traffic control) communications via a datalink, and any other suitable radio communication system that supports communications between the aircraft 100 and various external source(s).
The user input device 114 and the controller 104 are cooperatively configured to allow a user (e.g., a pilot, co-pilot, or crew member) to interact with display devices in the display system 116 and/or other elements of the system 102, as described herein. Depending on the embodiment, the user input device 114 may be realized as a cursor control device (CCD), keypad, touchpad, keyboard, mouse, touch panel (or touchscreen), joystick, knob, line select key, voice controller, gesture controller, or another suitable device adapted to receive input from a user. When the user input device 114 is configured as a touchpad or touchscreen, it may be integrated with the display system 116. As used herein, the user input device 114 may be used by a pilot to communicate with external sources, to modify or upload the program product 166, etc. In various embodiments, the display system 116 and user input device 114 are onboard the aircraft 100 and are also operationally coupled to the communication system and fabric 124. In some embodiments, the controller 104, user input device 114, and display system 116 are configured as a control display unit (CDU).
The controller 104 may perform display processing. As such, the controller 104 generates display commands for the display system 116 to cause the display device 20 to render thereon the various graphical user interface elements, tables, icons, alerts, menus, buttons, and pictorial images, as described herein. The display system 116 is configured to continuously receive and process the display commands from the controller 104, and, based thereon, to display information in various forms, such as an airport moving map (AMM). The display system 116 includes a display device 20. In various embodiments described herein, the display system 116 includes a synthetic vision system (SVS). In exemplary embodiments, the display device 20 is realized on one or more electronic display devices, such as a multi-function display (MFD) or a multi-function control display unit (MCDU), configured as any combination of: a head up display (HUD), an alphanumeric display, a vertical situation display (VSD) and a lateral navigation display (ND).
The controller 104 may perform graphical processing. Responsive to display commands, renderings on the display system 116 may be processed by a graphics system, components of which may be integrated into the display system 116 and/or be integrated within the controller 104. Display methods include various types of computer-generated symbols, text, and graphic information representing, for example, pitch, heading, flight path, airspeed, altitude, runway information, waypoints, targets, obstacles, terrain, and required navigation performance (RNP) data in an integrated, multi-color or monochrome form. Display methods also include various formatting techniques for visually distinguishing objects and routes from among other similar objects and routes. The controller 104 may be said to display various images and selectable options described herein. In practice, this may mean that the controller 104 generates display commands, and, responsive to receiving the display commands from the controller 104, the display system 116 displays, renders, or otherwise visually conveys on the display device 20, various graphical images associated with operation of the aircraft 100.
Cockpit data 107 generally represents onboard data that is available to the pilot or crew in the cockpit of the aircraft. For example, sources of cockpit data may include the navigation system 118, an airport features database 120, a flight management system (FMS) 119, and sensor system 122. In various embodiments, cockpit data 107 is communicated to the pilot and crew via graphical displays on the display system 116. In practice, there are a multitude of cockpit data 107 providing a respective multitude of information and sourced by a multitude of onboard aircraft systems. A variety of types of sensors in sensor system 122 detect various aspects of aircraft performance and aircraft conditions, in addition to sensing external operating conditions, such as weather and other aircraft and objects. Sensor data is output from the sensor system 122 and made available on the communication fabric 124. The airport features database 120 stores airport maps with features such as runways, taxiways, and gates.
The controller 104 performs the functions of the system 102. As used herein, the term “controller” may be interchanged with the term “module;” each refers to any means for facilitating communications and/or interaction between the elements of the system 102 and performing additional processes, tasks and/or functions to support operation of the system 102, as described herein. In various embodiments, the controller 104 may be any hardware, software, firmware, electronic control component, processing logic, and/or processor device, individually or in any combination. Depending on the embodiment, the controller 104 may be implemented or realized with a general purpose processor (shared, dedicated, or group) controller, microprocessor, or microcontroller, and memory that executes one or more software or firmware programs; a content addressable memory; a digital signal processor; an application specific integrated circuit (ASIC), a field programmable gate array (FPGA); any suitable programmable logic device; combinational logic circuit including discrete gates or transistor logic; discrete hardware components and memory devices; and/or any combination thereof, designed to perform the functions described herein.
Accordingly, in
The rejection ratio reducing program (shortened to “program” 162), includes rules and instructions which, when executed by the processor 150, convert the processor 150/memory 152 configuration into the controller 104 that performs the functions, techniques, and processing tasks associated with the operation of the system 102. The program 162 specifically directs the processing of the cockpit data 107 and traffic data to predict whether a tentative CPDLC request will be accepted and causes a dialogue box to be displayed to prompt a user selection based on the prediction (displayed dialogue boxes and related functionality are described in connection with
As a program product 166, one or more types of non-transitory computer-readable signal bearing media may be used to store and distribute the program 162, such as a non-transitory computer readable medium bearing the program 162 and containing therein additional computer instructions for causing a computer processor (such as the processor 150) to load and execute the program 162. Such a program product 166 may take a variety of forms, and the present disclosure applies equally regardless of the type of computer-readable signal bearing media used to carry out the distribution. Examples of signal bearing media include: recordable media such as floppy disks, hard drives, memory cards and optical disks, and transmission media such as digital and analog communication links. It will be appreciated that cloud-based storage and/or other techniques may also be utilized as memory 152 and as program product time-based viewing of clearance requests in certain embodiments.
In various embodiments, the processor/memory unit of the controller 104 may be communicatively coupled (via a bus 155) to an input/output (I/O) interface 154, and a database 156. The bus 155 serves to transmit programs, data, status and other information or signals between the various components of the controller 104. The bus 155 can be any suitable physical or logical means of connecting computer systems and components. This includes, but is not limited to, direct hard-wired connections, fiber optics, infrared and wireless bus technologies.
The I/O interface 154 enables intra controller 104 communication, as well as communications between the controller 104 and other system 102 components, and between the controller 104 and the external data sources via the communication system and fabric 124. The I/O interface 154 may include one or more network interfaces and can be implemented using any suitable method and apparatus. In various embodiments, the I/O interface 154 is configured to support communication from an external system driver and/or another computer system. In one embodiment, the I/O interface 154 is integrated with the communication system and fabric 124 and obtains data from external data source(s) directly. Also, in various embodiments, the I/O interface 154 may support communication with technicians, and/or one or more storage interfaces for direct connection to storage apparatuses, such as the database 156.
In some embodiments, the database 156 is part of the memory 152. In various embodiments, the database 156 is integrated, either within the controller 104 or external to it.
Embodiments of the system 102 for reducing CPDLC rejection ratios on an aircraft generate an enhanced CPLDC window for pilot interaction. Responsive to viewing the displayed enhanced CPDLC window, a pilot or crew makes a CPDLC request; this may be made via a touch screen input or other user input device. Moving now to
Upon receiving the tentative CPDLC request, the system 102 automatically and without further user input, uses received information from surrounding aircraft (provided by one or more traffic data sources 52), and conditions in the airport (relevant airport conditions information is provided by sources 106 of cockpit data 107) to predict whether the tentative CPDLC request will be accepted by the controller at ATC. The system dedicates an area 206 on the CPDLC request window 200 to displaying a predicted acceptance or a predicted rejection. In an embodiment, a sub-area 208 within the area 206 is dedicated to predicting an acceptance and a different sub-area 210 within the area 206 is dedicated to predicting a rejection. By providing a dedicated area on the CPDLC request window for these predictions, the pilot can quickly view and ascertain the prediction.
Further, various embodiments illuminate, or make visually distinguishable (with respect to the background), the sub-area that corresponds to the prediction. For example, in
In
In various embodiments, responsive to predicting a rejection, the system 102 identifies one or more alternate requests that the pilot could make. In some embodiments, the system 102 renders a selectable dialogue box in the area 206 to indicate that potential alternate requests are available. When the pilot selects the alternate requests option 502, the one or more alternative requests is rendered on the window 600. In other embodiments, the one or more alternate requests are immediately rendered in the area 206, not requiring the user selection of an options button. In addition to providing this beneficial alternative request feature, the system can predict, for each of the one or more alternative requests, when the alternative request is available.
For each alternative request identified, the system 102 determines and displays an availability, which is an amount of time until the alternative request is predicted to be accepted; said differently, this is an amount of time the system 102 recommends pausing before sending the CPDLC request to air traffic control (ATC) to minimize a chance of a CPDLC rejection. As may be appreciated, the amount of time may be zero, meaning that there is no need to delay before transmitting the CPDLC request. In
Moving now to
Upon receiving a pilot selection of the send (704) button, the system 102 converts the tentative request into a CPDLC request. The system 102 is configured to provide an additional benefit of keeping track of the elapse of time, pausing the transmittal of the CPDLC request for the amount of time predicted (and displayed at 702), and sending the CPDLC request upon the elapse of the amount of time, without further user input. In various embodiments, the system 102 visually indicates a status of CPDLC transmission while an amount of delay time is counted down. For example, in
The system 102 described above may be implemented by a processor-executable method for reducing CPDLC rejection ratios 900, as shown in the flow chart of
The method starts, and at 902 the controller 104 is initialized. As mentioned above, initialization may comprise uploading or updating instructions and applications 160 and CPDLC rejection reducing program 162.
At 904, cockpit data is received. As mentioned before, cockpit data is data from onboard sources such as the navigation system 118, FMS 119, and sensor system 122. Also, as mentioned, the sensor system 122 provides some data about the immediate external environment of the aircraft 100, which is distinguished from the sources of external data, such as the ATC 50 and traffic data source 52, which the aircraft receives data from at 906. At 908, the enhanced CPDLC request window is rendered on display system 116. At 910, a pilot-specified tentative CPDLC request is received. As previously mentioned, the pilot or crew may provide input via various user input devices, and directly on a touch screen display, when implemented. At 912, the received inputs are processed with airport features data and the system 102 predicts, based thereon, whether the controller at ATC 50 will accept or reject the tentative request; the prediction may have associated therewith, prediction information.
At 914, an area 206 is rendered on the enhanced CPDLC request window, and a display dialogue box with the prediction and prediction information is rendered therein. As described above, in connection with
When the prediction is that the tentative CPDLC request will be rejected at 916, any available alternative requests may be indicated at 926. At 928, each alternative request is further evaluated as to whether there is a predicted delay time. When there is a predicted delay time, the method moves to 920 and when there is no predicted delay time, the method moves to 922. As mentioned, at 918 and at 928, the delay time may be zero; in which case, various embodiments of the system 102 do not display a zero.
Thus, the proposed system 102 for reducing controller-pilot data link (CPDLC) rejection ratio on an aircraft is a technologically improved CPDLC system that processes current conditions that ATC considers to predict a likelihood of acceptance of the CPDLC request. This beneficially averts sending CPDLC requests that are likely to be rejected and therefore reduces CPDLC rejection ratios overall. As is readily appreciated, the above examples of the system 102 are non-limiting, and many others may be addressed by the controller 104.
Those of skill in the art will appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. Some of the embodiments and implementations are described above in terms of functional and/or logical block components (or modules) and various processing steps. However, it should be appreciated that such block components (or modules) may be realized by any number of hardware, software, and/or firmware components configured to perform the specified functions. To clearly illustrate the interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the application and design constraints imposed on the overall system.
Skilled artisans may implement the described functionality in varying ways for each application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. For example, an embodiment of a system or a component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, or the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices. In addition, those skilled in the art will appreciate that embodiments described herein are merely exemplary implementations.
Further, the various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
The steps of the method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a controller or processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Numerical ordinals such as “first,” “second,” “third,” etc. simply denote different singles of a plurality and do not imply any order or sequence unless specifically defined by the claim language. The sequence of the text in any of the claims does not imply that process steps must be performed in a temporal or logical order according to such sequence unless it is specifically defined by the language of the claim. When “or” is used herein, it is the logical or mathematical or, also called the “inclusive or.” Accordingly, A or B is true for the three cases: A is true, B is true, and, A and B are true. In some cases, the exclusive “or” is constructed with “and;” for example, “one from A and B” is true for the two cases: A is true, and B is true.
Furthermore, depending on the context, words such as “connect” or “coupled to” used in describing a relationship between different elements do not imply that a direct physical connection must be made between these elements. For example, two elements may be connected to each other physically, electronically, logically, or in any other manner, through one or more additional elements.
While at least one exemplary embodiment has been presented in the foregoing detailed description of the invention, it should be appreciated that a vast number of variations exist. It should also be appreciated that the exemplary embodiment or exemplary embodiments are only examples, and are not intended to limit the scope, applicability, or configuration of the invention in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing an exemplary embodiment of the invention. It being understood that various changes may be made in the function and arrangement of elements described in an exemplary embodiment without departing from the scope of the invention as set forth in the appended claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202011003065 | Jan 2020 | IN | national |
