法国专利FR3067802A1 ALTERNATIVE ROAD MANAGEMENT FOR AN AIRCRAFT

专利PDF首页>>法国专利

专利附录

专利说明

权利要求

类似技术

同族专利

引用文献

法律状态

优先权

专利摘要:
Different modes of regulation and / or integration of avionic systems with non-avionic systems are described. An avionics system is generally associated with a lower physical failure rate and a logic check higher than that of a non-avionics type system. Developments of the invention describe in particular the use of: remote computing resources; steps of comparison, testing, verification and authorization before non-avionics data injection into avionics; man-machine interaction modalities; various parameters (meteorology, air traffic, etc.) for combinatorial optimization purposes; and electronic flight bags E.F.B. and F.M.S. flight management systems.
公开号:FR3067802A1
申请号:FR1700649
申请日:2017-06-16
公开日:2018-12-21
发明作者:Benoit DACRE-WRIGHT；Olivier Pineau；Francois Nefflier
申请人:Thales SA；
IPC主号:

专利说明:

MANAGEMENT OF ALTERNATIVE ROUTES FOR AN AIRCRAFT
Field of the invention
The invention relates to the field of avionics. In particular, the invention relates to methods and systems for managing alternative routes of an aircraft.
State of the art
In existing avionics systems, alternative air "routes" (flight plans) can be inserted into the flight plan of a flight manager, which is part of the aircraft (certified) avionics. This insertion can be done manually, for example by inserting an air / ground data link message from air traffic control (or the airline). The flight plan is then loaded into a so-called secondary flight plan to allow the pilot to check it, adjust it if necessary, and then insert it as the new flight reference.
These flight management techniques encounter limitations inherent in avionics systems. For example, the modalities of modification of the aircraft route are limited by the capacities offered by the avionic equipment (eg editing functionalities), as well as by the limitations in terms of computing power, storage and band busy, or even human-machine interaction (eg non-touch screens)
As a result, operationally, mission management of the aircraft is based on limited and limited factual information, by construction, due to the limitations inherent in avionics systems.
With regard to the management of sidings (for example of an unfavorable weather event), various methods of calculating a sidings (lateral or vertical) are known. For example, patent document FR2749686 entitled “Method of piloting an aerodyne for vertical avoidance of an area” discloses a system for lateral avoidance based on information supplied periodically. However, this type of approach has limitations. Existing processes are in fact generally based on relatively simple treatments intended to be integrated into avionics. Alternatively, complex calculations can be carried out, but the result of these calculations cannot be inserted directly or simply in the avionics (loading in the avionics requires either input by the pilot, or at least by a verification by the pilot, for which the on-board avionics display means are unsuitable). The technical problem of integrating avionics systems with non-avionics systems remains unresolved.
There is a need for advanced methods and systems for managing alternative routes of an aircraft.
Summary of the invention
Different methods of regulation and / or integration of avionics systems with non-avionics systems are described. An avionics system is generally associated with a lower physical failure rate and higher logical verification than those of a non-avionics type system. Developments of the invention describe in particular the use of: remote computing resources; comparison, testing, verification and authorization stages before injecting non-avionic data into the avionics; human-computer interaction modalities; various parameters (meteorology, air traffic, etc.) for combinatorial optimization purposes; and E.F.B. and F.M.S.
The proposed solution consists in proposing data loading capacities, manual and graphic editing, and calculation of the route of the airplane on calculation means external to the avionics (tablet, laptop, remote server) as well as the means of exchange and verification with the active route in the avionics, allowing the evaluation then the secure insertion of the alternative route in the avionics.
Advantageously, the invention makes it possible to determine one or more alternative routes, by exploiting enriched data (for example of context), computation capacities and modalities of human-machine interaction exhibiting qualities and performances which the only avionic type systems.
Advantageously, the invention makes it possible to take advantage of the generally higher capacities of non-avionic systems in terms of information processing (e.g. laptops, tablets and remote resources such as cloud computing).
Advantageously, the invention makes it possible to take advantage of numerous and diversified data. The choice of an alternative route can notably take into account data external to avionics (e.g. meteorology).
Advantageously, the invention allows access to data on open networks, minimizing the risks in terms of intrusion or injection of unreliable data.
Advantageously, the invention makes it possible to take advantage of modern man-machine interaction methods and systems, reliable, robust, proven or even de facto standards, with a rapid learning curve (eg touch screens, force feedback, reality augmented and / or virtual).
Advantageously, the use of one or more external computers makes it possible to benefit from enhanced mission management, accompanied by secure means of exchange, and means of comparison and verification, allowing a reliable and easy transition to the computer. avionics navigation and mission execution.
Advantageously, the invention can find application for the flight or mission management of an aircraft, whether before or during the flight.
Advantageously, the invention can be implemented on tablets which can be used on board or during a stopover outside the aircraft. It can be deployed on EFBs on board the aircraft. It can also be offered on the ground in company operational centers, ensuring exchanges with avionics through the ground-edge data link functions.
Description of the figures
Various aspects and advantages of the invention will appear in support of the description of a preferred mode of implementation of the invention but not limiting, with reference to the figures below:
Figure 1 illustrates the overall technical environment of the invention;
FIG. 2 illustrates examples of integration of the avionic type systems with non-avionic type systems;
FIG. 3 illustrates different embodiments of the open computer;
FIG. 4 shows examples of steps of an embodiment of the method according to the invention.
Detailed description of the invention
Mission management of an aircraft, whether it involves passenger transport, civil freight transport or a military mission, is becoming increasingly complex. This complexity is due to several factors, notably due to the quantity and diversity of the data handled (or manipulated) and to the computing power that can be called upon.
On the one hand, the information taken into account in the definition of the mission is more and more complex (eg evolution of atmospheric phenomena in space and time, surrounding air traffic, present and future along the flight , taking into account more sophisticated customer needs in terms of services or infrastructure availability, complex missions and tactical and geostrategic threats).
On the other hand, the determination of an optimal solution, or sometimes even simply satisfactory, relies on complex treatments, and may require, in addition to automation, manual adjustment of the proposed solution, or calculation hypotheses, by the operator.
This growing complexity of mission management is hardly compatible with the robustness and reliability requirements of on-board avionics systems, which can constitute a major obstacle to the implementation of operationally efficient solutions.
However, increasingly sophisticated and relevant operational data for mission optimization are or are becoming available, accessible through data networks whose performance is steadily increasing. The computing power also increases: computing capacities available on small format tablets allow the development of powerful and sophisticated optimization tools, but whose complexity would make their reliability too costly to consider integrating them into the avionics.
The methods and systems according to the invention provide an advantageous integration of avionics and non-avionics systems, in certain specific contexts and objectives.
Figure 1 illustrates the overall technical environment of the invention.
The figure shows examples of systems (or "equipment" or "instruments" or "materials" or "devices" or "means") of type "nonavionics" or "(open) world" and equipment of type "avionics" ( certified by the regulator).
An aircraft is a means of transport capable of evolving within the Earth's atmosphere. For example, an aircraft can be an airplane or a helicopter (or even a drone). The aircraft includes a cockpit or a cockpit 120. Within the cockpit are piloting equipment 121 (called avionics equipment, certified by the aeronautical regulator) and optional equipment (called non-avionics or "open world") . In the case of a drone, the aircraft includes on-board avionics equipment and the optional equipment and the interfaces with the operator are deported to the ground.
An “avionics system” (or “avionics type system”) is a system having specific technical characteristics in comparison with a “non-avionics” system (or “non-avionics type system” or “open world”), these technical characteristics being administratively certified by a trusted authority (in this case the aeronautical regulator). Technically, delegations of authorities may allow management of a technical nature from this administrative type in the future (e.g. crypto ledgers).
Concerning the distinctive technical characteristics of an avionics system, a system - generally, ie avionics or non-avionics - can present or be associated with a predefined failure rate (among a range of predefined failure rates), a rate of failure including or determining a predefined execution error rate. In one embodiment, the failure rate of an avionic type system is lower than the failure rate of a non-avionic type system. In one embodiment, the failure rate of an avionics system is significantly or substantially lower than that of a non-avionics system.
An avionics system designates a reliable system (or one with guaranteed reliability). It is a system whose failure has consequences that exceed accepted or acceptable limits, and therefore feared. A failure can be characterized by the loss of the considered function, or by the production of erroneous data, with or without detection of an error. Depending on the level of criticality of the feared consequences, the probability of occurrence must be kept below an acceptability threshold. Thus, the more critical the consequence, the lower the probability of acceptable occurrence. For example, in aeronautics, a catastrophic event (multiple deaths) should have a probability of occurrence less than 10 ^Λ -9 per flight hour, while a major incident (reduction of safety margins and operational capacities, discomfort or minor injuries) should have a probability of occurrence less than 10 ^Λ -5 per hour flown. To ensure these objectives, the architecture of the avionics system (made more reliable) as well as the design of each component guarantee this probability of occurrence by guarantees of failure rate of each equipment (physical failures) and levels of verification (functional coverage and structural test) software.
These requirements impose a significant design and verification effort, and impose a limitation in the complexity of the processing implemented.
Conversely, the failure of a system which is not reliable, or whose reliability is not guaranteed (non-avionics system) has consequences deemed tolerable, non-critical, or even without significant operational impact. The requirements on architecture, physical components or software processing are therefore lower, and allow more complex processing, and a reduced development and verification effort compared to a reliable system.
In general, an avionics system is associated with a lower physical failure rate and a higher logical verification than those of a non-avionics type system.
In order to use during flight operations data from an unreliable computer, since the reliability of the data is not guaranteed (or guaranteed with an error rate higher than the requirements of the reliable system), it is advantageous to use the method according to the invention. The steps of the process make it possible in particular to ensure that no erroneous data is used operationally by the reliable system. The steps can include verification by the human operator, following manual entry or automatic transmission, or various means of verifying the data transmitted. In certain embodiments, it is also possible to have steps for calculating or checking the consistency of the data of the non-avionic system made by the avionic system (for example, it can be verified that a trajectory is constructed with known points and that it stolen)
The failure of a system can be understood in a deterministic way but also in a probabilistic way.
In one embodiment, an additional completeness criterion allows nuance of the failure rate criterion. This completeness criterion designates the coverage of tests (excitations, challenges without necessarily a known response) and / or checks (eg comparison of the response produced with that which is known and expected) which have been previously carried out on the avionics system or non-avionics system in determining the failure rate. In one embodiment, the exhaustiveness of the tests and / or verifications carried out is greater in an avionic system in comparison with a non-avionic system.
In one embodiment, in addition to the overall failure rate of the avionics system or non-avionics system, the failure rates specific to the components of the avionics system or non-avionics system can be taken into account, as well as the propagation of the failures.
Avionics equipment (hereinafter "avionics") 121 for example includes one or more on-board computers (means of calculation, memorization and storage of data), including a flight management system ("Flight Management System" , acronym FMS), man-machine interface means, such as display means (eg screens incorporated into avionics equipment) and / or data entry (eg keyboards, buttons, cursors, rotators, etc.), means of communication or haptic feedback. By extension, avionics systems can include systems accessible remotely, for example air traffic control and / or operational center, which can be in communication (bilateral) via ground-board links. Furthermore, the air traffic control systems 1001 and / or of the operational center can access (eg receive, collect, select, cross, determine) sources of open type data (eg meteorological data of non-regulatory type), for example accessible from the Internet and whose coverage and depth covers the entire flight of the aircraft.
Non-avionic systems 122 designate on-board or ground devices which can, for example, include one or more computer tablets or EFBs (“Electronic Flight Bag” for electronic schoolbag), portable or integrated in the cockpit, display means ( eg additional screens, connected glasses, heads-up sights, projectors, holographic systems, virtual and / or augmented reality headsets called "wearable computers" or "head-mounted displays", etc.), as well as means interaction (eg laser projection keyboards, unfoldable, unrollable; haptic systems, force feedback, mechanical, pneumatic, electric; dictation or voice recognition means with noise cancellation, etc.).
An EFB or, in general, equipment of the non-avionic type can interact (unidirectional or bilateral communication 123) with the avionic equipment 121.
The avionics and / or non-avionics systems are in communication with an aircraft 110 (e.g. its cockpit, dashboard, etc.).
One or more non-avionics systems can also be in communication 124 with external computing resources, accessible by the network (for example cloud computing or Cloud computing 125. In particular, the calculations can be performed locally on the EFB or of partially or completely in the means of calculation accessible via or by or in the network.
The on-board equipment 121 is generally certified and regulated while the EFB 122 and the connected IT means 125 are generally not (or to a lesser extent). According to the embodiments (types of integration 123), the architectures which can be implemented make it possible to inject flexibility and functional capacities on the side of the open world (eg via the EFB 122) while ensuring security. (controlled) on the side of on-board avionics 121.
FIG. 2 shows examples of avionic type systems, examples of non-avionic type systems as well as examples of integration between these two types of system.
The avionics systems 121 may in particular comprise a digital shore-to-board link device 1211, HMI man-machine interfaces or IHS man-system interfaces 1212, one or more flight management systems of the aircraft 1213, one or more mission management 1214.
By extension, the avionics systems 121 may include systems accessible remotely, for example air traffic control 1001 and / or operational center 1002, which can be in communication (bilateral) via the ground-edge links. In addition, air traffic control systems 1001 and / or operational center 1002 can access (eg receive, collect, select, cross, determine) sources of open type data (eg meteorological data of non-regulatory type) , for example accessible from the Internet.
According to the embodiments of the invention, nonavionic type systems 122 can comprise one or more of the following systems: a comparator 231, for example of the secure type, man-machine and / or man-system interface equipment 232, one or more open type computers 233 and a gateway system 220.
Principles of regulation
The regulation of interactions between avionic systems 121 and non-avionic type systems 122, i.e. the rules for managing data exchanges, can be diverse, depending on the embodiments. They can be few and therefore fast and effective. They can also be complex and involve several actors, ie result from the joint intervention of man or machine.
Generally, the methods of communication between the two types of avionic system and non-avionic system cover various aspects or parameters:
a) directionality; communication between the two types of system (e.g. data flow, message passing, etc.) can be one-way or two-way. This directionality property can be static (invariant or course of time) but can also change over time (according to predefined time intervals and / or according to predefined events), for example according to the phase or the context of flight. For example, communication can be two-way when the plane is on the ground at its departure gate, and one-way when taxiing. In this example, when the aircraft is on the ground, any modification proposed by the non-avionics system to the avionics system can be checked, and, if it were wrong, it would not decrease safety to the extent that this modification could still be modified and corrected. As soon as taxiing and in flight, communication occurs initially only from the avionics system to the non-avionics system, any data produced by the non-avionics system cannot be automatically transferred to the avionics system.
b) form (e.g. data format, type of protocols, translation / bridging, etc.). For example, a WIFI or wired Ethernet protocol may be the most optimized on the ground (given the large volume that can be exchanged on the ground to initialize the mission) while a more secure protocol with lower speed may be preferable in flight , taking into account on-board communications architectures (AEEC ARINC 653) which may require guaranteeing bandwidth and integrity for all critical computers and can therefore de facto limit the speed and the type of data exchanged with the nonavionic system .
c) background (quality e.g. nature of the objects communicated e.g. flight plan points or 3D trajectory, etc.; data on the data i.e. metadata; raw or static data; executable data i.e. programs). A nonavionic system, in addition to the flight plans, can be the receptacle of numerous rich data of which only a part will be exploited by the avionic system: aeronautical maps, geographic maps of maximum resolution, complete weather maps. The avionics system can use a subset of the data, filtered for its needs (for example filtering along the flight plan, filtering the resolution adapted to its memory limitations, to its computing power limitations, etc.).
d) quantity (or volumes). A non-avionics system can use rich data (there is no real limitation in terms of processor, memory and storage; powerful multi-core processors can be used, while avionics system computers have a hardware architecture very robust but much more limited to guarantee the testability of the required performance, for example with properties of resistance to high energy particle events during flight (SEU, NSEU), resistance to vibration or to extreme temperatures. avionics generally have significantly less power than nonavionics computers.
e) privileges or priorities (eg global priorities can be allocated; for example the "master" avionics system will be associated with a priority at all times higher than the "slave" non-avionics system; "administrator" or "read / write" privileges writing ”will be allocated to the different parties, for example in terms of access, reading and / or writing in one or the other type of system.
The regulation of data exchanges can govern each of these aspects differently and combine them in a particular way. Depending on the embodiments, it will be obtained from master / slave systems (scalable or not) or from peer-to-peer networks (scalable or not), comprising various and varied feedbacks (e.g. feedforward, etc.)
As an example of a particularly advantageous combination in the avionics profession, the communication between the avionics system and the non-avionics system can be bidirectional but asymmetrical (more data escaped from the avionics system than data which is reinjected therein) , without control over the output of the avionics system but with a double control over data re-injections, in terms of i) nature of the data re-injected (eg only certain avionic objects are authorized) and ii) volume of data (eg in order to preserve the FMS over-stress core). Filtering mechanisms by type of object can be implemented. Beyond format tests, logical data tests can be performed. The volume of data handled by the avionics core can be controlled by a measurement of the load and / or the processing capacity of the avionics core (feedback control).
Gateway server
In one embodiment, a third entity (regulatory body) establishes the link between the avionics system (s) and the non-avionics system (s).
For example, an intermediate entity or “gateway server” 220 can regulate the exchanges.
In one embodiment, the gateway server 220 (eg techniques, stages, one or more dedicated systems, etc.) allows the loading of the alternative route of non-avionic origin into the avionics type computer (navigation computer) , for example via the gateway server 220.
In one embodiment, a gateway server is a passive storage space. It plugs in (queuing) the elements calculated by the non-avionic systems and ultimately transmits them to the avionic systems. The gateway server then serves as a buffer between the two types of systems. In one embodiment, the gateway server can order the queue, for example according to the priority associated with the different objects queued, according to the flight context and / or the use of the avionic resources which may be depending on the under-solicited or over-solicited cases, etc.
In one embodiment, the gateway server between the avionics system and the non-avionics system is an active storage space, i.e. which adds logical processing to the data received. The gateway server can carry out one or more of the following actions: carry out its own checks on the compliance of a route with respect to the avionics criteria, integrate by redundancy one or more of the functions assigned to the comparison blocks 231, of HMI 232, or FMS 233 (for double checking for example), receive instructions from a third party system, etc. In one embodiment, the gateway server 220 can check the conformity between the trajectory calculated in avionics and the trajectory resulting from calculation outside avionics.
In particular, the gateway server between the avionics system and the nonavionics system - as a critical component at the interface of the two types of systems - can be the subject of dedicated security measures (for example independently of other systems). The gateway server can be secured by various means, including in particular one or more of the mechanisms comprising data encryption (for example with asymmetric keys), authentication mechanisms (for example biometric), self-monitoring mechanisms (eg state machine, "watchdog"), anti-intrusion mechanisms (eg IDS), mechanisms for continuous verification of the integrity of the data handled in the gateway server, sharing of a prior secret, etc.
In one embodiment, the gateway server between the avionics system and the non-avionics system can be approved (or recognized or accepted or authorized) by the non-avionics systems on the one hand and the avionics systems on the other hand, intermittently , regular or on demand. In one embodiment, one or more voting mechanisms can make it possible to repudiate or reject on request the gateway server which would be considered to be corrupt (for example if at least one of the avionic systems determines it as such; other models can provide for majority votes, etc.).
Comparator
In one embodiment, the function of the comparator 231 (or comparison function or step) aims to compare the alternative route on the one hand and the route present in the avionics navigation computer on the other hand.
In one embodiment, the comparator aims to identify operational gains and / or to verify the conformity of the route loaded in the avionics.
The comparator 231 and / or the interfaces 232 and / or the open-type computer 233 and the gateway system 220 can interact in different ways.
The granularity or the scope of the comparisons is variable or configurable (only the final results can be compared and / or the intermediate results, the boundary conditions can also be compared, etc.). The comparison methods can be diverse (e.g. identical or modulo comparison of tolerances, according to predefined models).
In one embodiment, the FMS avionics code is executed in the computer 233, in exactly the same way as it would be in the native avionics system. The results obtained are then sent and analyzed by the comparator 231 which, if necessary, communicates to the pilot via the interface 232 the differences between the elements calculated in an avionic way on the one hand and in a non-avionic way on the other hand ( optionally, thresholds or ranges of thresholds can be applied, if models not represented allow the management of systemic risks, eg a difference of value of 1% for certain types of value can generate catastrophic consequences while other types parameters may be less sensitive; moreover combinations of such differential values may also be considered). After express authorization, for example, from the pilot, possibly secured by entering a code or authentication (for example biometric), the authorized data is transmitted to the avionic systems 121 via the gateway server 220.
Human-machine interfaces
In one embodiment, the HMI / IHS interface 232 can include one or more of the display screens and / or interaction systems 232 linked to this computer allowing the operator to view the results determined by the non-avionic systems. , and to manually adjust the solution or particular characteristics of this solution; for example, the pilot will be able to view the result of the calculations on the screen of the tablet (but in embodiments, this information may be projected or displayed as an overlay, by augmented reality, etc.).
The display devices may include or implement one or more devices such as virtual reality headsets and / or augmented reality glasses (eg head-mounted display, wearable computer, glasses or a head-mounted display) and / or projection devices (eg holographic). A virtual reality headset worn by the pilot can be opaque or semi-transparent or with configurable transparency). The display can be "high sight". The helmet can include one or more calculation and communication, projection, audio acquisition, projection and / or video acquisition devices (for example for the capture or scraping of data accessible analogically from the cockpit or the flight deck of the aircraft). The aircraft cockpit may also include voice control devices. The on-board instrumentation can advantageously allow the pilot to view his flight plan plan or his trajectory in 3D, in particular the different alternative routes according to the invention. For example, the pilot will be able to view - for example superimposed on his real environment - these alternative routes, the trajectory joins when these are still possible (to go from one route to another). Finally, haptic feedback devices incorporated into the system for the implementation of the invention can enrich the choice of routes, guidance / piloting (specific vibrations when actually crossing a crossing point, etc.). In one embodiment, the visualization of the different alternative routes can be enriched by an interaction over the predicted time, so as to change the predicted situation of the aircraft and of the context over time, from start to finish. of the mission. The interaction on the predicted time can be done for example by tactile interaction, pointing device, or mechanical device such as a rotator.
Regarding the display, the information can be displayed in one or more virtual and / or augmented reality headphones. The information can therefore be entirely virtual (displayed in an individual helmet), entirely real (for example projected on the flat surfaces available in the real environment of the aircraft cockpit) or a combination of the two (partly a virtual display superimposed or merged with reality and partly an actual display via projectors). The display can also be characterized by the application of predefined location rules and display rules. For example, human-machine interfaces (or information) can be distributed (segmented into separate portions, possibly partially redundant, then distributed) between the different virtual or real screens.
Open data
In one embodiment, the open computer 133 accesses (actively) and / or receives (passively) information from external sources 1251, which are provided by one or more external data networks 1252, these external networks also being in interaction with one or more operational centers.
Regarding the data collected on networks open to the outside (1251, 1252), these can be large (quantity, eg number, diversity), complex (quality, eg reliability, variable obsolescence, variable formats), multidimensional (in time and space, ie integrating the present and also the future, for example by including predictions of evolution over time, possibly accompanied by degrees of reliability, or even variants associated with probability or statistical criteria ).
These data may relate to meteorological data, such as wind and temperature sampled according to altitude, geographic position, and over different predicted times; and / or the state of air traffic, either in terms of the planned trajectories of the different aircraft over the sectors encountered, or traffic densities by sector, with forecasts over time, or statistical variations of traffic development ; and / or geometrical zones (polyhedra, or polygons by altitude sections) defining danger zones, avoidance zones, or phenomena influencing flight, and their temporal evolution: volcanic ash clouds, zones of atmospheric turbulence, convection (thunderstorms), icing, or zones of military exclusion or tactical risk; and / or discretized information in the form of digital maps: weather radar images, digital relief; and / or punctual, fixed or mobile obstacles: aircraft, aerostats, tactical threats, etc.
All this open data can influence the mission, and can potentially be taken into account in the development of an alternative route.
Their spatial extent and their temporal evolution can also be taken into account in an automatic route calculation. In addition, the raw and / or processed data can be displayed to the pilot for evaluation of the impact on the current route (or on the alternative route being developed).
In addition to this information, specific aeronautical data can be taken into account, for example air navigation databases, integrating airports, arrival and departure procedures, beacons, navigation point, air routes, in areas geographic to the mission, or across the globe; or the segmentation of airspace, with air traffic control zones, ocean air navigation rails, and state borders.
Another example of open data concerns the structure of airspace. In one embodiment, the so-called open computer 233 can take into account the structure of the air traffic control sectors, such as the TMA (from the English "Terminal Maneuvering Area") of different airports, the en route control sectors defined by geographical limits or altitude levels, as well as the borders between Air Navigation Route Centers (CRNA in France) or between countries, so as to allow the definition of a route that best integrates with air traffic, and which is likely to be accepted by local air traffic control.
The information listed above can be taken into account to determine an optimized route, which best integrates into the controlled airspace and / or which optimally exploits the areas of free navigation (known as "free routing").
In certain embodiments, the (i) communication interfaces external to the avionics (1251, 1252), and / or the (ii) computing means external to the avionics 233 and / or the (HMI) systems d Human-system interaction 232 external to avionics can be used as much as possible (maximum delegation mode). The use of these methods can therefore be optimized (and therefore maximized in particular).
FIG. 3 illustrates different embodiments of the open computer 233.
The figure shows in more detail examples of components of the computer 233. The open computer 233 includes hardware and software code executed on this hardware, implementing steps of determining one or more alternative routes.
Several types of complementary treatment can generally be distinguished within this calculator. These types or classes of processing are symbolized by search and optimization blocks 310, transcription steps 320 (adaptation, translation, etc.) in the avionics route, which lead to trajectory calculations and predictions 330. The trajectories produced are finally manipulated in the comparator (possibly secured 231).
The computer 233 performs (complex) treatments for searching or optimizing trajectories 310. The search spaces can be large, the search methods varied, deterministic or not, global or local, with forms of modeling the trajectory adapted to the research method.
The computer 233 can perform trajectory prediction calculations identical, or functionally equivalent, to those performed in the avionics system. The calculation and prediction processing are in particular intended to allow comparison with the trajectory calculations of the avionic system, either for the purpose of profit estimation or for the purpose of verification of conformity. They therefore reproduce as much as possible the treatments as they will be applied by the avionics system. In order to faithfully reproduce the calculations, several embodiments are described.
In one embodiment, a structurally identical code (same source code) is executed (possibly recompiled or transcribed for the non-avionic computer).
In one embodiment, functionally equivalent code is executed. The result of the execution of this code is representative of that produced by the avionics system.
The optimization steps of block 310 can use, without limitation, operational research steps including heuristics, such as A-star algorithms, or steps of probabilistic methods (such as genetic algorithms). Certain processing operations may call for massive processing of “big data” type data, or be based on highly parallel processing architectures. Computing resources accessed remotely or on-board (e.g. high performance GPU computing) can be requested, for example as a backup. A global search method, possibly imprecise, can be supplemented by local optimization, applying non-linear optimization techniques, or algorithms based on potential fields. These methods are characterized by combinatorics, and sometimes non-determinism, or convergence properties, which would not guarantee the reliability required by the avionics system. In addition, these search and optimization treatments take into account a wide variety and high complexity of input data from diverse and unsecured sources: real-time, predictive or statistical information, concerning meteorology, air traffic or any other element of the operational context. Such variability of the input data would make a guarantee of reliability on the result very complex, if not unattainable.
To allow the transition from search and optimization processing, to calculation and prediction processing identical to avionics, the search and optimization results are transcribed (block 320) in a format functionally equivalent to that manipulated by the avionics system.
Materially, the computer 233 can be implemented on a tablet or laptop (or on any other means of calculation external to the avionics, for example via remote accesses) making it possible to determine (eg search, evaluate, select, etc.) alternative routes . It can also be based on ground computing infrastructures, based on distributed or massively parallel architectures.
FIG. 4 shows examples of steps of an embodiment of the method according to the invention.
There is described a method for managing a route of an aircraft implemented in a system comprising an avionic type system and a non-avionic type system, comprising the steps: - determining an alternative route to the current route in the non-avionics type system; - receive authorization to insert said route into the avionics flight management system; - insert said route into the avionics flight management system.
The step of determining an alternative route in the non-avionic type system can be carried out in different ways (execution of software code strictly identical to that executed by the FMS, equivalent functional code, pseudo-code, etc.).
The term "insert" refers to a revised flight plan. The term "activate" means that the route becomes the servo reference and will actually be stolen. An insertion is therefore the prerequisite for activation, the very first operation to take into account the non-avionic origin calculation.
The step of receiving authorization to insert said alternative route into the avionics flight management system can be carried out in different ways (pilot and / or machine validation loop). A variant of the mission can be submitted to the pilot for assessment (e.g. correction, annotation, validation, modulation). Decision systems can assess (note, simulate, quantify, emulate, etc.) the criticality of the alternative route, before possible reinjection.
Once validated by humans and / or machines, the route of non-avionic origin is injected into non-avionic systems.
In one embodiment, the method comprises the step of inserting and / or activating the verified alternative route in the avionics flight management system. In one embodiment, there may be a prior insertion into the avionic system, then a verification, then finally an activation of the route as a flight reference.
In one embodiment, the step consisting in determining an alternative route in the non-avionic type system comprises the execution, in the non-avionic system, of software code identical to that implemented in the system flight management avionics.
In one embodiment, the step consisting in determining an alternative route in the non-avionic type system comprising the execution, in the non-avionic system, of software code functionally equivalent to that implemented in the avionics flight management system.
In one embodiment, the authorization to insert said alternative route being received from a man-machine interface and / or being authorized by an avionics type system.
The pilot has a privileged role in that he is responsible for injecting non-avionic data into avionic systems. The authorization can result from a joint man-machine action according to different configurations (machine pre-evaluation and human validation, or vice versa, voting mechanisms, etc.).
In one embodiment, the insertion authorization is conditional on a step consisting in comparing the alternative route determined in or by the non-avionic type system with the current route determined in or by the avionic type system.
In one embodiment, the comparison is relative, and "safe" because direct: the new route (candidate) is compared with the current or current route (validated by avionics).
The comparison, graphic or not, makes it possible to assess the operational gains (or losses) and therefore the relevance of inserting the route into the avionics system.
The criteria can include one or more of the criteria including an operational gain or loss in terms of flight time, fuel consumption, distance to a meteorological disturbance, exposure in duration and / or intensity to a meteorological disturbance.
In one embodiment, the method comprises the step of evaluating or verifying the alternative route determined according to predefined criteria.
In one embodiment, the comparison is "absolute" and indirect: the candidate alternative route is evaluated according to predefined criteria which themselves reflect the avionics requirements. It is understood that this step is carried out before the insertion or activation of said route (which can only take place if the evaluation is positive, i.e. exceeds a predefined threshold).
In one embodiment, the method comprises a step consisting in evaluating or verifying the conformity of the determined alternative route with predefined criteria. The assessment may consist of scoring or assigning a score to the candidate route.
This assessment or compliance verification step can be carried out at any time (creation of the route, submission via the HMI, including after validation by the pilot if necessary). The criteria can correspond to limits, limits or envelopes, as given by the FMS flight management system.
In one embodiment, the evaluation can be deterministic. In one embodiment, the evaluation can be probabilistic. The criteria may take into account the systemic risks of data injection.
The evaluation and verification functions invoked can be "qualified", ie verify the conformity of the calculations with coherent precision thresholds of the navigation precision required for the mission (RNP), and / or be coupled to the display means interactive to allow a visual comparison of the results.
In one embodiment, the method comprises the step of modifying the determined alternative route.
The route modification step can be iterative (e.g. undergoing optimization steps). It can be the result of a variety of actors (e.g. pilot, ATC) and / or machines. It can be performed before insertion or activation in the avionics. It can result from a set of predefined and / or dynamically calculated parameters. HMI means may or may not be used (modifications triggered by automatic processing, without graphic loop).
The modification operation may in particular include operations aimed at preselecting, filtering, partially modifying, validating or on the contrary censoring the determined route.
In one embodiment, the step consisting in modifying the determined alternative route comprises one or more steps of combinatorial optimization and / or multi-objective optimization, as a function of one or more parameters selected from among the parameters comprising the meteorological conditions. present and predicted in which the aircraft is evolving, the surrounding air traffic, the structuring of the airspace, the airport services of the destination or diversion airport, the load factor and / or passenger comfort estimated and associated with said route, fuel cost, flight time, flight punctuality, operational flight cost, availability of flight personnel, availability of maintenance equipment, environmental criteria, compliance with AOC company rules and ATC regulations , the probability of acceptance of the alternative route in terms of AOC and / or AT negotiation vs.
The optimization carried out by the method according to the invention can be of different natures. Optimization can be "combinatorial" (discrete optimization), consisting in finding in a discrete set one of the best achievable subsets (or solutions), the notion of best solution being defined by a (single) objective function. Optimization can also be "multi-objective" (i.e. seeking to optimize several objectives of the same problem simultaneously).
The criteria can be varied. Other additional parameters may also concern the consideration of NOTAM messages, the assessment of the cognitive load for the pilot, and more generally of the service infrastructure in and around the airport.
The number of parameters or constraints can for example gradually be incremented or decremented, the parameters can be of equal importance or hierarchical (e.g. weighted).
In one embodiment, the man-machine interface displays by juxtaposing the determined alternative route and the current route of the aircraft.
In one embodiment, the reference route from the avionics and the alternative route being developed are displayed simultaneously.
In one embodiment, the man-machine interface comprises at least one cursor configured to trigger the display of one or more flight parameters associated with the alternative route determined over time as a function of the movement of said cursor.
In one embodiment, the pilot can visualize the evolution of the situation over time along the route, by acting on a time parameter (for example by dragging a marker along a time scale of "slider" type), to display the state of the predicted contextual data (traffic, weather, danger or disturbance zones), as well as the predicted position of the aircraft on each of the trajectories.
In one embodiment, the method comprises the step of receiving data of non-avionic origin to determine an alternative route to the current route in the non-avionic type system.
The same remarks regarding the avionics versus non-avionics nature apply to the data. Data, whether of avionic or nonavionic origin, remains data. The origin or source of the data nevertheless reflects the confidence measured in terms of reliability and / or precision associated with said data (attribute of the data, data on the data i.e. metadata).
In one embodiment, one or more steps are triggered depending on the flight context.
For example, the presence or absence of an HMI interaction for the purpose of authorization of insertion and / or activation may be conditioned on a flight phase considered to be critical. The optimization stage can also be controlled by the flight phase (more or less criteria can be taken into account). More generally, each of the stages mentioned above can be modulated or influenced or configured according to the phase or the flight context.
Flight background
In certain embodiments, one or more of the steps of the process (eg type of test carried out to grant or refuse insertion and / or activation authorizations, selected moment to ask the pilot for an advisory opinion or a formal authorization, selection one or more criteria taken into account for determining the alternative route, etc.) can be controlled by the flight context of the aircraft (eg flight phases).
The flight context at a given time includes all of the actions taken by the pilots (and in particular the effective flight instructions) and the influence of the external environment on the aircraft. A flight context includes for example a situation among predefined or pre-categorized situations associated with data such as the position, the flight phase, the waypoints, the procedure in progress (and others). For example, the aircraft may be in the approach phase for landing, in the take-off phase, in the cruise phase but also in the ascending, descending, etc. stages (a variety of situations may be predefined). Furthermore, the current flight context can be associated with a multitude of attributes or descriptive parameters (current meteorological state, traffic state, pilot status comprising for example a stress level as measured by sensors, etc.). A flight context can therefore also include data, for example filtered by priority and / or based on flight phase data, meteorological problems, avionics parameters, ATC negotiations, flight status anomalies, problems related to traffic and / or relief. Examples of flight context include, for example, contexts such as cruising / no turbulence / nominal pilot stress or else landing phase / turbulence / intense pilot stress. These contexts can be structured according to various models (e.g. hierarchical in tree structure or according to various dependencies, including graphs). Context categories can be defined, in order to summarize the needs in terms of human-computer interaction (e.g. minimum or maximum interaction time, minimum and maximum quantity of words, etc.). There may also remain specific rules in certain contexts, in particular emergencies or critical situations. Context categories can be static or dynamic (e.g. configurable).
The method can be implemented in a system comprising means for determining a flight context of the aircraft, said determination means comprising in particular logic rules, which manipulate values as measured by physical measurement means. In other words, the means of determining the flight context include system or hardware or physical / tangible means and / or logical means (e.g. logical rules, for example predefined). For example, physical means include avionics instrumentation in the literal sense (radars, probes, etc.) which make it possible to establish factual measurements characterizing the flight. Logical rules represent all of the information processing used to interpret (e.g. contextualize) factual measures. Certain values can correspond to several contexts and by correlation and / or calculation and / or simulation, it is possible to decide on candidate contexts, by means of these logical rules. A variety of technologies makes it possible to implement these logical rules (formal logic, fuzzy logic, intuitionist logic, etc.)
There is described a system for managing an aircraft route comprising - a non-avionic type system configured to determine one or more alternative routes to the current route of the aircraft; - a gateway system configured to receive a authorization to insert an alternative route into an avionics system; - said avionics system comprising a flight management system configured to insert said route into the avionics flight management system; an avionics system being associated with a physical failure rate lower and a higher logical check than those of a non-avionic type system.
In one embodiment, an avionics type system includes an F.M.S. and / or an air navigation traffic control system and a non-avionics type system includes an electronic flight bag E.F.B. or a digital tablet.
Other embodiments or aspects of the invention are described below.
In step 410, an alternative or candidate route (or more generally an object) is determined (or created or developed) by one or more computers 233 whose material is of non-avionic type (i.e. not previously certified).
In one embodiment, a computer 233 allows a calculation of the aircraft trajectory prediction, for a chosen route, which is based on the same algorithms and the same flight performance models as the navigation computer of the avionics. Advantageously, the comparison of the results is in this way reliable and significant.
In one embodiment, a computer 233 executes (exactly) the same software code (source code) as that which is implemented in the avionics certified system. In one embodiment, the hardware is also identical. In one embodiment, a virtual machine is used (e.g. hypervisor).
In one embodiment, a computer 233 executes software code “functionally equivalent” (compiled code) to that which is implemented in the avionics certified system. In one embodiment, the pseudo-codes (non-avionics on the one hand, avionics on the other hand) are identical. In one embodiment, they are similar (the differences relating to non-critical elements).
In the optional step 420, the routes A (according to the non-avionic system) and B (according to the avionics, from the same input data) are compared and the result of the comparison conditions whether a verification loop by the pilot is required or only optional The comparison can be made identically or modulo tolerances (depending on the flight context, the presence of critical parameters, etc.).
In one embodiment, the route (or object) can be compared to the reference present in the avionics to evaluate the operational gains and the relevance.
In one embodiment, the variants of the mission (flight plans, trajectories, etc.) can be submitted to the pilot for appraisal (e.g. correction, annotation, validation, modulation), who can assess their relevance.
If necessary, a step of verifying and / or modifying 430 of the route (or of the object) can be carried out (open loop), for example by the pilot (or a group of people) and / or a system of machine decision (eg third party system, ATC etc).
The verification of one or more conditions can be accompanied by an authorization 460 (eg code, signal, request, etc.) if a predetermined subset of these conditions is satisfied (according to a model and thresholds or ranges of thresholds predefined).
In one embodiment, the route (or object) is modified 430 at one or more of its points, using a man-machine interface 461.
In step 430, the route unchanged, or possibly modified, can be explicitly validated (or authorized) by the pilot. This route or object of non-avionic origin is then plugged in (communicated, stored, manipulated) in the gateway server 220.
In one embodiment, the gateway server 220 is a passive storage space. It plugs in (queuing) the elements calculated by the non-avionic systems and ultimately transmits them to the avionic systems. The gateway server then serves as a buffer between the two types of systems. In one embodiment, the gateway server can order the queue, for example according to the priority associated with the different objects queued, according to the flight context and / or the use of the avionic resources which may be depending on the under-solicited or over-solicited cases, etc.
In one embodiment, the gateway server 220 is an active storage space, i.e. which adds logical processing to the data received. The gateway server can carry out one or more of the following actions: carry out its own checks on the compliance of a route with respect to the avionics criteria, integrate by redundancy one or more of the functions assigned to the comparison blocks 231, of HMI 232, or FMS 233 (for double checking for example), receive instructions from a third party system, etc.
In one embodiment, the gateway server 220 can check the conformity between the trajectory calculated in avionics and the trajectory resulting from calculation outside avionics.
In particular, the gateway server 220 - as a critical component at the interface of the two types of systems - can be the subject of dedicated security measures (for example independently of other systems). The gateway server can be secured by various means, including in particular one or more of the mechanisms comprising data encryption (for example with asymmetric keys), authentication mechanisms (for example biometric), self-monitoring mechanisms (eg state machine, "watchdog"), anti-intrusion mechanisms (eg IDS), mechanisms for continuous verification of the integrity of the data handled in the gateway server, sharing of a prior secret, etc.
In one embodiment, the gateway server can be approved (or recognized or accepted or authorized) by non-avionic systems on the one hand and avionic systems on the other hand, intermittently, regularly or on demand. In one embodiment, one or more voting mechanisms can make it possible to repudiate or reject on request the gateway server which would be considered to be corrupt (for example if at least one of the avionic systems determines it as such; other models can provide for majority votes, etc.).
The data transmitted or manipulated or modified by the gateway server 220 are then communicated to the avionic systems.
In one embodiment, the modified (or not) and validated / verified / authorized route is "inserted" 440 into the avionics system 121, that is to say that at this precise moment external data are taken into account in the certified flight management system (with a residual risk of malicious data injection). Later, the data can be activated in the reference flight plan.
In one embodiment, variants of the mission can therefore be injected or reintegrated into the avionics systems.
Regarding the human-machine interfaces HMI or human-system IHS 232, different embodiments are possible. Advantageously, the pilot can indeed assess the relevance of the solution proposed by the computer, but also can also modify or adjust the solution according to his own operational criteria, or to take into account operational constraints not taken into account by the automatic calculation. For this, modifications made to the existing graphic display screens can be implemented.
In one embodiment, the reference route from the avionics, and the alternative route being developed are juxtaposed and displayed simultaneously.
In one embodiment, the pilot can visualize the evolution of the situation over time along the route, by acting on a time parameter (for example by dragging a marker along a time scale of "slider" type), to display the state of the predicted contextual data (traffic, weather, danger or disturbance zones), as well as the predicted state of the aircraft on each of the trajectories.
In one embodiment, the pilot can be provided with additional criteria to improve decision making. For example, operational gains, in terms of flight time or fuel consumption, the minimum distance to the disturbance, or the maximum exposure in duration or intensity to a disturbance crossed may be displayed.
In one embodiment, the same graphical interface displays the route being developed on the open computer and the route defined in the avionics system.
The interface equipment can receive the trajectory data to be displayed directly from the avionics to compare it with the alternative route or else have a (reliable) import of the trajectory from the avionics, so as to manage and then display them from the alternative route computer.
According to the embodiments, the operator can act directly on the points of the proposed route, to - add, delete, move a point on the route; display and route the route through the points and air routes published in the navigation database; - display the air traffic control sectors and ocean navigation rails to adjust the route accordingly; - display or modify a heading or a flight distance on a segment of the proposed route; - or even propose the adjustment of a heading or a distance from the road according to a chosen criterion (flight time, slope to a constraint, ability to descend and stabilize before the runway).
Concerning the data exchanges between the non-avionic systems 122 and the avionic systems 121, the exchange of route information with the avionics can make it possible to have, in the open computer 233, reliable information on the current reference route, and reliably export the alternative route solution to the avionics to allow it to be taken into account and its subsequent execution.
Regarding the insertion of the alternative route determined by non-avionic type systems, various embodiments are described below.
In one embodiment, the insertion of the alternative route into the avionic systems is carried out by data link, for example by means of ground-edge links 1211 (protocols of route requests by the air traffic control centers 1001 or by 1002 company operational centers can be used). These requests make it possible in particular to load a new route into the navigation computer 1213/1214, which can allow the alternative route to be loaded, which is then loaded into a secondary flight plan, and can become the navigation reference after validation by the operator. Other requests are used to export the route loaded in the navigation computer, and therefore to provide it to the alternative route computer.
Insofar as the alternative route computer can integrate the same algorithms and the same flight performance models as the navigation computer, the recalculated trajectory on this route can be considered as being consistent with that present in avionics. However, road conformity cannot be systematically guaranteed, a priori. It is once the alternative route has been loaded into the avionics that the pilot will be able to check compliance, assess the expected operational gains, and finally activate the flight of the aircraft on this new reference.
In certain embodiments, the method may include a step consisting in displaying (intended for the pilot) an interactive route entry guide, presenting for example manual entry interfaces and various values to be entered, to guide it step by step when entering the alternative route, on the navigation interfaces available in the cockpit.
Different embodiments for importing and / or exporting a route are described below.
In one embodiment, the secure gateway 220 makes it possible to transmit data from the avionics to the outside (“to export”), without in any way compromising flight safety.
In one embodiment, the secure gateway 220 can export (or transfer or communicate) outside (i.e. to non-avionics systems) the result of the trajectory calculation performed by the avionics navigation computer. Using the calculation, a faithful representation of the navigation path can be obtained, which can be displayed to the operator (and serve as a later reference).
When an alternative route has been loaded into the avionics navigation computer and the associated “avionics” trajectory has been calculated, the reliable export of this trajectory allows its display to the operator and its verification of conformity with the calculated alternative trajectory and displayed by the alternative route computer excluding avionics.
Regarding the import of data, operations can be secured by different mechanisms.
In one embodiment, the secure gateway can be used to directly load a new route, which can be loaded into the avionics navigation computer. Such a request in general does not in any way compromise flight safety, since the route is loaded into an alternative flight plan, which must be validated by the pilot before being adopted or validated or authorized as a new active flight reference.
This validation can be facilitated by a compliance check, secure, performed outside of avionics but made reliable to be displayed to the pilot and facilitate validation of the new trajectory.
Concerning the comparison between alternative route and current route of the aircraft, several embodiments are described below.
The trajectories comparison allows to evaluate the operational gains in a reliable and significant way, not biased by variabilities in the trajectories calculation mode.
During the phase of taking into account (or importing or integrating) the alternative route, the trajectory calculated on this new route by the avionic navigation computer can be compared with the trajectory calculated in the alternative route computer. This comparison by a reliable function makes it possible to ensure the compliance of the route before its validation by the operator as a new flight reference.
In one embodiment, the verification function invoked can be “qualified”, ie verify the conformity of the calculations with coherent precision thresholds of the navigation precision required for the mission, and / or be coupled to interactive display means to allow a visual comparison of the results.
The present invention can be implemented using hardware and / or software elements. It may be available as a computer program product on computer-readable media. The support can be electronic, magnetic, optical or electromagnetic.
A computer program product is described, said computer program comprising code instructions making it possible to carry out one or more of the steps of the method, when said program is executed on a computer.
In one embodiment, the method is implemented by computer.
In one embodiment, the system for implementing the invention comprises a computer-readable storage medium (RAM, ROM, flash memory or another memory technology, for example disk medium or another storage medium non-transient computer-readable) encoded with a computer program (that is to say several executable instructions) which, when executed on a processor or several processors, performs the functions of the embodiments described above. By way of example of a hardware architecture suitable for implementing the invention, a device may include a communication bus to which a central processing unit or microprocessor (CPU, acronym for "Central Processing Unit" in English) is connected, which processor can be multi-core or many-core ·, a read only memory (ROM, acronym for "Read Only Memory" in English) which may include the programs necessary for the implementation of the invention; a random access memory or cache memory (RAM, acronym for "Random Access Memory" in English) comprising registers suitable for recording variables and parameters created and modified during the execution of the aforementioned programs; and a communication or I / O interface (I / O acronym for "Input / ouput" in English) adapted to transmit and receive data.
In the case where the invention is implemented on a reprogrammable computing machine (for example an FPGA circuit), the corresponding program (i.e. the sequence of instructions) can be stored in or on a storage medium removable (for example an SD card, or mass storage such as a hard disk eg an SSD) or non-removable, volatile or non-volatile, this storage medium being partially or completely readable by a computer or a processor. The computer-readable medium can be transportable or communicable or mobile or transmissible (i.e. by a 2G, 3G, 4G, Wifi, BLE, fiber optic or other telecommunications network).
The reference to a computer program which, when executed, performs any of the functions described above, is not limited to an application program running on a single host computer. On the contrary, the terms computer program and software are used here in a general sense to refer to any type of computer code (for example, application software, firmware, microcode, or any other form of computer instruction, such as web services or SOA or via API programming interfaces) which can be used to program one or more processors to implement aspects of the techniques described here. IT resources or resources can in particular be distributed (Cloud computing), possibly with or according to peer-to-peer and / or virtualization technologies. The software code can be executed on any suitable processor (for example, a microprocessor) or processor core or a set of processors, whether provided in a single computing device or distributed among several computing devices (for example example as possibly accessible in the environment of the device). Security technologies (crypto-processors, possibly biometric authentication, encryption, smart card, etc.) can be used.
In certain embodiments, the various steps of the method can be implemented in whole or in part on the FMS and / or on one or more EFBs (electronic flight bags or bags) and / or tablets and / or airline calculator or of mission.

权利要求:
Claims (15)
[1" id="c-fr-0001]
claims
1. A method for managing a route of an aircraft implemented in a system comprising an avionics type system and a nonavionics type system, comprising the steps:
- determine an alternative route to the current route in the non-avionic type system;
- receive authorization to insert said route into the avionics flight management system;
- insert said route into the avionics flight management system.
[2" id="c-fr-0002]
2. Method according to claim 1, the step consisting in determining an alternative route in the non-avionic type system comprising the execution, in the non-avionic system, of a software code identical to that implemented in the avionics flight management system.
[3" id="c-fr-0003]
3. Method according to claim 1, the step consisting in determining an alternative route in the non-avionic type system comprising the execution, in the non-avionic system, of a software code functionally equivalent to that implemented. in the avionics flight management system.
[4" id="c-fr-0004]
4. Method according to claim 1, the authorization to insert said alternative route being received from a man-machine interface and / or being authorized by an avionics type system.
[5" id="c-fr-0005]
5. Method according to claim 1, the insertion authorization being conditional on a step consisting in comparing the alternative route determined in or by the non-avionic type system with the current route determined in or by the avionic type system.
[6" id="c-fr-0006]
6. Method according to any one of the preceding claims, comprising the step of evaluating or verifying the alternative route determined according to predefined criteria.
[7" id="c-fr-0007]
7. Method according to any one of the preceding claims, comprising the step of modifying the determined alternative route.
[8" id="c-fr-0008]
8. The method as claimed in claim 7, the step consisting in modifying the determined alternative route comprising one or more steps of combinatorial optimization and / or multiobjective optimization, as a function of one or more parameters selected from among the parameters comprising the present and predicted meteorological conditions in which the aircraft operates, the surrounding air traffic, the structuring of the airspace, the airport services of the destination or diversion airport, the load factor and / or the estimated passenger comfort and associated with said route, the cost of fuel, flight time, flight punctuality, operational flight cost, availability of flight personnel, availability of maintenance equipment, environmental criteria, compliance with AOC company rules and ATC regulations, the probability of acceptance of the alternative route for negotiation A OC and / or ATC.
[9" id="c-fr-0009]
9. The method of claim 2, the man-machine interface displaying by juxtaposing the determined alternative route and the current route of the aircraft.
[10" id="c-fr-0010]
10. The method of claim 2, the man-machine interface comprising at least one cursor configured to trigger the display of one or more flight parameters associated with the alternative route determined over time as a function of the movement of said cursor. .
[11" id="c-fr-0011]
11. The method of claim 1, comprising the step of receiving data of non-avionic origin to determine an alternative route to the current route in the non-avionic type system.
[12" id="c-fr-0012]
12. Method according to any one of the preceding claims, one or more steps being triggered depending on the flight context.
[13" id="c-fr-0013]
13. A computer program product, said computer program comprising code instructions making it possible to carry out the steps of the method according to any one of claims 1 to 12, when said program is executed on a computer.
[14" id="c-fr-0014]
14. System for managing an aircraft route comprising
- a non-avionics type system configured to determine one or more alternative routes to the current route of the aircraft;
- a gateway system configured to receive an authorization to insert an alternative route in an avionics system;
- said avionics system comprising a flight management system configured to insert said route into the avionics flight management system;
an avionics system being associated with a lower physical failure rate and a higher logical verification than those of a non-avionics type system.
[15" id="c-fr-0015]
15. The system as claimed in claim 14, an avionics type system comprising an F.M.S. and / or an air navigation traffic control system and a non-avionic type system comprising an electronic flight bag E.F.B. or a digital tablet.

类似技术:

公开号 | 公开日 | 专利标题

FR3067802A1|2018-12-21|ALTERNATIVE ROAD MANAGEMENT FOR AN AIRCRAFT

FR3055958A1|2018-03-16|DECISION AID FOR THE REVISION OF A FLIGHT PLAN

FR3067803A1|2018-12-21|SYNCHRONIZATION OF A DUAL AVIONIC AND NON-AVIONIC SYSTEM

US9256994B2|2016-02-09|Unmanned aerial vehicle authorization and geofence envelope determination

FR3046273A1|2017-06-30|OPEN ARCHITECTURE FOR FLIGHT MANAGEMENT SYSTEM

EP2945062A1|2015-11-18|Method for performing services in real time, in particular flight management and real-time system implementing such a method

FR3046225B1|2019-06-28|DISPLAY OF WEATHER DATA IN AN AIRCRAFT

EP2975362A1|2016-01-20|Performance calculation for an aircraft

US11248930B2|2022-02-15|Microclimate wind forecasting

FR3020882A1|2015-11-13|OPTIMIZING THE TRACK OF AN AIRCRAFT

EP3340208A1|2018-06-27|Management of messages to flight crews

EP3671598A1|2020-06-24|Distributed registers for data sharing in aviation

Alves et al.2018|Considerations in assuring safety of increasingly autonomous systems

FR3030805A1|2016-06-24|QUALITY OF SERVICE OF A FLIGHT MANAGEMENT SYSTEM

WO2019082046A1|2019-05-02|Real-time identification and provision of preferred flight parameters

González-Arribas et al.2017|Robust optimal trajectory planning under uncertain winds and convective risk

FR3082829A1|2019-12-27|AIRCRAFT MANAGEMENT

Bergstra et al.2019|A promise theoretic account of the boeing 737 Max MCAS algorithm affair

EP3712798B1|2021-07-07|Distributed registers for managing the life cycle of data in aeronautics

FR3038751A1|2017-01-13|METHOD FOR INTEGRATING A CONSTRAINED ROAD OPTIMIZATION APPLICATION IN AN OPEN ARCHITECTURE AIRCRAFT SYSTEM OF CLIENT-TYPE SERVER

FR3067805A1|2018-12-21|DECISION AID FOR THE CONTROL OF AN AIRCRAFT

FR3082330A1|2019-12-13|AERONAUTICAL CYBERSECURITY

US20180088542A1|2018-03-29|Optimizing operations of an electronic system based on the quality of user device inputs

FR3107775A1|2021-09-03|MANIPULATION OF DATABASES BY DISTRIBUTED REGISTERS

WO2020127841A1|2020-06-25|Device and method for managing aircraft systems

同族专利:

公开号 | 公开日

US10699582B2|2020-06-30|

US20180366008A1|2018-12-20|

FR3067802B1|2019-12-13|

引用文献:

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

US20080195309A1|2006-04-13|2008-08-14|United States Of America As Represented By The Administrator Of The National Aeronautics|System And Method For Aiding Pilot Preview, Rehearsal, Review, and Real-Time Visual Acquisition Of Flight Mission Progress|

FR3020882A1|2014-05-09|2015-11-13|Thales Sa|OPTIMIZING THE TRACK OF AN AIRCRAFT|

FR3029619A1|2014-12-05|2016-06-10|Airbus Operations Sas|MANAGEMENT SYSTEM, ESPECIALLY FLIGHT MANAGEMENT SYSTEM, FOR AN AIRCRAFT.|

FR2749686B1|1996-06-07|1998-09-11|Sextant Avionique|METHOD FOR THE VEHICLE LATERAL AVOIDANCE OF A MOBILE AREA|

US6623089B2|2001-08-29|2003-09-23|Delphi Technologies, Inc.|Enhanced yaw rate estimation and diagnosis for vehicular applications|

JP3833982B2|2002-10-03|2006-10-18|株式会社東芝|Test pattern selection device, test pattern selection method, and test pattern selection program|

GB201005202D0|2010-03-29|2010-05-12|Fuel Matrix Ltd|Fueling arrangement and method|

GB201117278D0|2011-10-06|2011-11-16|Fuel Matrix Ltd|Method and system|

US9646503B2|2015-02-11|2017-05-09|Honeywell International Inc.|Cockpit display systems and methods for generating navigation displays including landing diversion symbology|EA032603B1|2015-10-22|2019-06-28|Таль Аления Спейс Италия С.П.А. Кон Унико Сочио|Method and systems for increasing capacity and safety of aeronautical safety-of-life services and data links|

US10616241B2|2017-06-05|2020-04-07|Honeywell International Inc.|Systems and methods for performing external data validation for aircraft onboard systems|

US11017678B2|2017-09-22|2021-05-25|Vianair Inc.|Terminal and en-route airspace operations based on dynamic routes|

US10490091B1|2018-09-21|2019-11-26|Rockwell Collins, Inc.|Systems and methods for avoidance traversal analysis for flight-plan routing|

FR3094810A1|2019-04-03|2020-10-09|Thales|System on chip comprising a plurality of master resources|

WO2020247147A2|2019-05-23|2020-12-10|Smartsky Networks LLC|Augmented reality in aircraft cockpit through bi-directional connectivity|

CN110119160B|2019-06-04|2020-05-08|中国人民解放军国防科技大学|Quick real-time dynamic task planning method for scouting and printing integrated unmanned aerial vehicle|

EP3893224A1|2020-04-07|2021-10-13|The Boeing Company|Systems, methods, and apparatus to improve aircraft traffic control|

US11250711B1|2020-08-04|2022-02-15|Rockwell Collins, Inc.|Maneuver evaluation and route guidance through environment|

US11258863B1|2020-11-06|2022-02-22|Ge Aviation Systems Llc|Systems, devices, and methods for establishing multiple electronic flight bag sessions with a flight management computer|

法律状态:
2018-12-21| PLSC| Search report ready|Effective date: 20181221 |

2019-06-03| PLFP| Fee payment|Year of fee payment: 3 |

2020-05-26| PLFP| Fee payment|Year of fee payment: 4 |

2021-05-27| PLFP| Fee payment|Year of fee payment: 5 |

优先权:

申请号 | 申请日 | 专利标题

FR1700649|2017-06-16|

FR1700649A|FR3067802B1|2017-06-16|2017-06-16|MANAGEMENT OF ALTERNATIVE ROUTES FOR AN AIRCRAFT|FR1700649A| FR3067802B1|2017-06-16|2017-06-16|MANAGEMENT OF ALTERNATIVE ROUTES FOR AN AIRCRAFT|

US16/009,017| US10699582B2|2017-06-16|2018-06-14|Management of alternative routes for an aircraft|

[返回顶部]