Patent Grant
8332133
This invention relates to the field of air operations using crew-controller exchanges, routed by a CPDLC-type data link. More precisely, the invention concerns a method and a device for processing a request message received in an aircraft, from ground control, via a data transmission system.
Most of the oceanic zones and an increasing number of continental zones (Asiatic in particular, European as of late) provide aircraft with the capacity to exchange written, alphanumeric, climbing or descending messages with ground control, generally with a controller. To date, the air spaces concerned are essentially the upper spaces, that is to say above a certain flight level (typically, above 25,000 feet).
Communication frequencies and protocols are dedicated to these digital exchanges, the frequencies may vary with the zone over-flown, and in particular use satellite communications and/or borrow land networks.
This type of exchange of written messages between ground control and the pilot or the crew of the aircraft is designated by the abbreviation CPDLC denoting controller/pilot communications by data link (Controller/Pilot Data-Link Communications, in English).
The CPDLC communication mode makes it possible to communicate requests coming from the crew or control instructions from the ground called “clearances” (clearances in English), and more generally messages of different types, in the alphanumeric format, composed of plain text or else made up of codified messages with fields that may be parameterized if need be.
The CPDLC mode, which does not use the voice channel, is very advantageous in terms of reliability, quality and robustness as regards errors, in comparison with communication by a vocal channel.
To date, many climbing messages, originating from air control, presuppose the capacity of the aircraft to satisfy one or more of the required parameters, and very particularly when these parameters relate to flight performances of the aircraft, such as, for example, the speed, the altitude or the rate of climb. In certain cases, these climbing messages explicitly ask the pilot questions about the capacity of the aircraft to achieve certain performances.
An exemplary instruction contained in a CPDLC message from ground control is given below. This instruction is the following:
“CROSS [position] AT OR AFTER [time] AT [altitude]”
The above instruction CROSS means: “Pass through the precise point indicated in the field [position] at the precise altitude indicated in the field [altitude] starting from the time indicated in the field [time].”
As illustrated by the above example, it thus is possible for a controller to ask the pilot to reach a given altitude with constraints that the aircraft is unable to meet with the required safety margins, for reasons linked to the physical constraints of the flight, whether they are imposed by the construction features of the aircraft or else due to the flight conditions, such as the weight of the aircraft or the outside temperature at the moment. In other cases, it is arriving at a point at a precise time which will not be possible because it requires an acceleration and speeds physically unattainable by the aircraft.
Furthermore, according to a more basic type of messages, it is frequent for messages merely to ask the pilot for the state of the attainable performances of the aircraft. By way of example, a frequently transmitted message is the following: “WHEN CAN YOU ACCEPT FL [level],” meaning “At what time will you be able to reach the flight level indicated in the field [level],” for example, 350.
At present, considering the nature of the messages and the international standardization (standards of the Organisation de l'Aviation Civile Internationale (OACI) [International Civil Aviation Organization] under which they fall, the on-board systems for reception of CPDLC messages are able to identify the nature of a received message and, if need be, each of the variable parameters that constitute it, for purposes of a subsequent processing by the pilot.
Nonetheless, considering the various types of messages set forth above, it often is difficult for a pilot to respond to the questions asked or to look ahead to his capacity to respond to a maneuver instruction, because these questions or instructions generally require performing calculations.
These necessary calculations, when they are relatively simple, may be performed manually by the pilot, with the aid of basic calculation tools, such as data charts of paper type or electronic type, or else a hand-held electronic calculator. When they are more complex, however, these calculations may require the use by the pilot of computer resources such as tools integrated into the on-board instruments, such as a flight management system (in English Flight Management System—FMS).
All the same, despite the aforementioned tools available to the pilot, it is difficult for the latter to respond to numerous types of messages. In fact, the systems for reception of messages and the calculation tools mentioned above, even though they make it possible to respond punctually to the questions or queries from the crew, require on the part of the crew:
It is to be noted that the transmitted response may be of two types, depending on whether it follows a message relating to a maneuver request instruction or a message relating to a precise question linked to a capacity of the aircraft. In the first case, the response may indicate simply the pilot's agreement with the maneuver or on the contrary disagreement, if need be with a justification of the inability of the aircraft to carry out the requested maneuver.
In the second case, the response of the crew may consist of a precise, encoded response on the capacity requested of the aircraft—for example: “The 350 level can be reached at 7:56 a.m.”—or else a negative response, for example: “Not able to reach the requested level.”
It emerges from the foregoing that the workload to which the crew is subjected for processing the requests contained in the messages from air control is considerable.
At the present time, communications in the CPDLC context take place essentially when the flight is in cruising phase. This situation, however, may well deteriorate in the near future, since it is provided, within the framework of the European project SESAR (new generation European system for air traffic management) or of the American project Next Generation Airspace, that these exchanges be more frequent with more varied messages, and that they also take place in more dynamic flight phases, such as the phases of climbing or descent, phases during which the workload of the crew is greater than at cruising power. In this way, in this new CPDLC communications context, the workload to which the crew is subjected will be even heavier, thus likely to make the processing of such messages even more problematic.
It emerges from the situation set forth above that there is a real need for on-board systems for assistance in processing by the crew of climbing messages from ground control transmitted in a CPDLC environment, especially when these messages require the crew to carry out precise performance calculations, which considerably increases the workload of the crew.
In order to meet the need set forth above, this invention relates, according to a first aspect, to a method for processing a request message received in an aircraft, from air control, via a data transmission system. This method comprises the identification of a type of request contained in the received message and the extraction of parameters associated with the type of request identified, and it is noteworthy in that it further comprises steps of:
By virtue of such a method for automatic processing of a message from air control through a CPDLC link, the crew of the aircraft is relieved of the following tasks: recognition of the instruction or the question contained in the message, that is to say the analysis of the flight characteristics to be calculated; execution of calculations, manually or assisted by tools, as explained above, since according to the invention these calculation modules are automatically selected for calculating the characteristics necessary to processing of the message; retrieval, collation and analysis of the intermediate calculation results, with, if need be, manual retrieval of parameters linked to the aircraft or to the flight conditions; lastly, comparison of the final calculation results with the request from air control for a response, before drawing up of a response intended to be sent to air control. In this way, according to the method of the invention, a draft response to the request automatically is provided to the crew.
In this way, implementation of the method according to the invention provides the pilot of an aircraft, such as an airliner, for example, with an aid for processing of requests from air control, making it possible to considerably reduce the workload and attention usually demanded of the pilot for processing these requests.
Consequently, the invention contributes toward further improving safety in air transport. It also makes it possible to increase the efficiency of the air space through a faster and more reliable response given to the requests from control (rightly accepting a maneuver; refusing a clearance that cannot be met).
According to other characteristics of the invention:
According to a second aspect, the invention relates to a device for processing a request message received in an aircraft, from ground control, via a data transmission system. According to the invention, this device comprises:
According to another aspect, the invention relates to a computer program on an information medium, this program comprising instructions adapted for the implementation of a method for processing a request message received in an aircraft, from air control, according to the invention, such as briefly set forth above, when the program is loaded and run in a computer system.
The advantages obtained with the device for processing an aforementioned request message, as well as with the aforesaid computer program, are identical to those mentioned above in relation to the method for processing a request message, according to the invention, and consequently will not be repeated here.
The invention also has as an object an aircraft equipped with a device for processing request messages, according to the invention, such as set forth above.
The invention will be better understood with the aid of the detailed description that is going to follow, presented with reference to the attached drawings in which:
In connection with
As illustrated on
In step E11, climbing message M1 usually is received in the aircraft through a device, known in itself, for reception of CPDLC messages (
In the course of the following step (E13), the device for reception of CPDLC messages (21) usually identifies a type or category of the request contained in the message (this identification is standardized and deterministic), extracts from the message parameters associated with the type of request identified.
The different types of climbing messages are illustrated in Attachment 1 which appears at the end of the description and which provides a list of some climbing messages (clearances), extracted from document 4444 of the OACI (International Civil Aviation Organization), linked to a performance problem of the aircraft.
Attachment 2, which also appears at the end of the description, provides a list of response messages (descending) that may be used to respond to a performance problem (extract from document 4444 of the OACI), in response to the climbing messages.
Thus, as illustrated by the exemplary messages appearing in Attachment 1, six major categories or types of requests may be defined. These types are referenced marked 0, 1, 1 bis, 2, 3, and 4 in the three tables of Attachment 1.
The category of requests designated by “type 0” corresponds to basic and selective calculations of performances of the aircraft, for example the calculation of the speed envelope according to precise conditions. In this way, in table 3 of Attachment 1, messages bearing the numbers 111, 112, 113 belong to this category, and relate to the increase or decrease of the speed of the aircraft.
The category of requests designated by “type 1” correspond to the calculations involving the use of an electronic version of a draft flight plan, that is to say the direct use of a “flight plan” calculation module and its usual functionalities of prediction in time, speeds, altitudes, weights, of crossing various points of the flight plan, etc. This comes down to an integration modeling of the equations of the flight mechanics.
The category of requests designated by “type 1 bis” in table 2 of Attachment 1 (cf. message No. 58) also corresponds to the calculations involving the use of an electronic version of a draft flight plan, but differs from the aforesaid type 1 by the fact that the draft flight plan is used iteratively, that is to say by iterating its use according to the value of one or more input parameters, until finding the expected result.
The category of results designated by “type 2” in table 1 of Attachment 1 (see, for example, message No. 26) corresponds to calculations carrying out simulations referred to as “reverse.” A reverse simulation corresponds to a flight circumstance defined by “forced” conditions, which correspond to a final required situation, deduced directly from the parameters of the climbing message. It will be noted here that the advantage of this type of reverse, that is to say “in decreasing time,” algorithm is that it makes it possible to avoid having to implement iterations on an algorithm in “increasing time” when a final very precise flight circumstance is sought.
The category of requests designated by “type 3 in particular in table 1 of Attachment 1 (see, for example, messages No. 171 and 173), relates to requests involving calculations that more often than not are performed “manually” by the pilot, in other words calculations involving predominantly manual operations. These are calculations for which the last generation of flight management computers ((FMS, Flight Management System) do not always implement the algorithms that are at the root of these calculations.
In particular, it is a matter specifically of flight mechanics calculations. For example, instruction 171, in table 1, asks the airplane to climb at a minimum given vertical speed (CLIMB AT (vertical rate) MINIMUM). In order to be able to respond to the message, the pilot must use flight mechanics equations, or even data charts—in paper form or else electronic, when they exist in the electronic flight bags—as explained briefly in the box “Complements and comments” corresponding to this message.
Finally, the category of requests designated by “type 4” in table 2 of Attachment 1 (see, for example, messages No. 55, 56, 57 and 61), relates to requests involving calculations requiring the direct use of the active flight plan, that is to say the flight plan officially followed by the airplane.
Reverting to
In step E17 that follows, the flight characteristics to be calculated are determined according to the type of request identified and the associated parameters. Then, in step E19, the selection of at least one calculation module, from among a predetermined set of calculation modules is undertaken, according to the flight characteristics to be calculated which have been determined. Next, in step E21, the calculations of the flight characteristics necessary for constructing a response to the climbing message are carried out.
More precisely, these calculation modules are adapted respectively for implementing the operations necessary to the processing of each type of request identified, that is to say adapted for carrying out:
In step E23 that follows, the results of the calculations carried out by the selected calculation module or modules are retrieved and analyzed. Finally, in step E25, a draft response (PRI) to the request contained in the received message is automatically drawn up from the calculation results obtained.
In practice, the message processing method according to the invention may comprise, according to the embodiment chosen, one or more of the following steps (not shown on
Moreover, according to a specific embodiment, the identification of a type of request is preceded by the steps of:
It also may be provided that the received request message is communicated to the crew, via a man-machine interface, concurrently with the step of identifying a type of request.
As shown on
Module 37 for creation of a draft response thus automatically draws up a draft response message, according to the climbing message (originating from the controller) and the calculation results produced by the appropriate modules or modules. Such a draft response is in accordance with the standardized descending (downlink) response messages, indicated in the tables of Attachment 2.
Such a response message may consist of one or more descending messages provided for by the standardization (cf. Attachment 2). By way of examples, in Attachment 2:
Reverting to
According to a specific embodiment, processing device 3 according to the invention further comprises a module for submission (not shown) of the draft response drawn up, to the pilot or the crew of the aircraft, via an appropriate man-machine interface, for example cockpit display device 23.
As mentioned above, calculation modules 35(1-n) automate the processing usually implemented manually by the crew, or by means of calculation tools controlled or manipulated by the crew.
Thus, in practice, calculation modules 35(1-n) implement, at least in part, the detailed technical specifications (DTS) of the flight management system (Flight Management System—FMS), such as, for example, those relating to the calculation of speed envelopes, or else use known flight mechanics equations (propulsion equation, for example).
For “type 1” requests, the automatic processing implemented by the selected calculation module comprises in particular the following operations:
As a variant, for type 1, 1 bis or 2 messages, the simulation calculations may use simplified modellings—that is to say not using predictive calculations to start with, such as allowances or a Bréguet formula, for example—in order to improve the response times. In fact, the use of a predictive draft flight plan calculation already basically uses precise but more complex algorithms and may prove to be costly in calculation time.
For type 2 requests, the automatic processing performed by the selected calculation module consists in using a reverse simulation. To this end, the known laws of time regression are used to model in reverse order (in the sense of increase) the evolution of the weight, the lateral trajectory, the speeds and the altitude of the aircraft. The reverse simulation is interrupted for a given flight condition and the predictions are retrieved. Then, the items necessary to the drawing up of the response to the request message are extracted, for example the ability or inability to return to the flight level included in the draft. The response to the question finally is drawn up and displayed in the cockpit.
For type 3 requests, the automatic processing of the manual operations, mentioned above, usually required for type 3 requests, for example flight mechanics calculations.
For type 4 requests, the automatic processing carried out by the selected calculation module in particular consists in:
The functioning of the message processing system shown in
As a variant, as shown by successive arrows F1b and F2, the received message first is communicated (arrow F1b) to the crew, via an appropriate man-machine interface, here display device 23. Then, in response to a validation by the crew by means of an appropriate control interface, the identification operation is activated and the received message is transmitted to analysis module 31 (arrow F2).
According to one embodiment, the draft response drawn up by module 37 for creation of draft responses, is transmitted (arrow F6) systematically to display device 23 and in this way submitted to the crew. In this case, the crew may modify the response message via Creation/Modification device 25 (arrow F3)—as is the case in the state of the art—then activate sending thereof (arrow F4). The crew also may activate sending of the message immediately without modifying it (arrow F5).
In an implementation variant, message creation module 37 may transmit the response message immediately and automatically to transmission device 27, as shown by arrow F7.
In practice, the aforesaid modules making up a message processing device 3 according to the invention are implemented in the form of software modules, that is to say one or more computer programs forming a set and comprising instructions adapted for the implementation of the method for processing a request message, according to the invention. A method according to the invention consequently is implemented when this or these programs is/are loaded and run in an on-board computer system in the aircraft.
It likewise will be noted that a computer program according to the invention, the purpose of which is the implementation of the invention when it is run by an appropriate computer system, may be stored on an information medium of varying types. In fact, such an information medium may consist of any apparatus or device able to store a program according to the invention.
For example, the medium in question may comprise a hardware storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a diskette or a hard disk. As a variant, the information medium may be an integrated circuit in which the program is incorporated, the circuit being used for the implementation of the method considered.
From a design point of view, a computer program according to the invention may use any programming language and be in the form of source code, object code, or code intermediate between source code and object code (e.g., a partially compiled form) or in any other desirable form for implementing a method according to the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 09 58765 | Dec 2009 | FR | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 6313759 | Musland-Sipper | Nov 2001 | B1 |
| 6317659 | Lindsley et al. | Nov 2001 | B1 |
| 7418319 | Chen et al. | Aug 2008 | B2 |
| 20050181787 | Judd et al. | Aug 2005 | A1 |
| 20050203676 | Sandell et al. | Sep 2005 | A1 |
| 20060287781 | Bui | Dec 2006 | A1 |
| 20070215745 | Fleury et al. | Sep 2007 | A1 |
| 20080114504 | Goodman et al. | May 2008 | A1 |
| 20080154486 | Coulmeau | Jun 2008 | A1 |
| 20080163093 | Lorido | Jul 2008 | A1 |
| 20080167885 | Judd et al. | Jul 2008 | A1 |
| Number | Date | Country |
|---|---|---|
| 1 756 789 | Feb 2007 | EP |
| 1 923 851 | May 2008 | EP |
| 2 898 675 | Sep 2007 | FR |
| 2 910 124 | Jun 2008 | FR |
| 2 913 799 | Sep 2008 | FR |
| WO 2006001851 | Jan 2006 | WO |
| WO 2006001851 | Jan 2006 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20110166772 A1 | Jul 2011 | US |
