METHOD FOR VALIDATING A TERRAIN DATABASE

Abstract

A method for validating a terrain database includes a step of simulating flights based on trajectory data for an aircraft, the flight simulations being speeded up, a step of determining terrain collision risks by means of a system for signalling terrain collision risks based on the speeded-up flight simulations, a step of determining the origins of terrain collision risks with a view to validating or not validating the terrain database.

Claims

1. A method for validating a terrain database (TerrDB), said terrain database comprising a plurality of items of information on at least one geographical region (Z.sub.G) liable to be flown over by an aircraft, said validating method comprising the following steps implemented by computing means: a step of generating data on trajectories of the aircraft over the geographical region (Z.sub.G); a step of simulating flights based on said trajectory data, said flight simulations being speeded up (Sim.sub.acc); a step of determining terrain collision risks (Risqs) by means of a system for signalling terrain collision risks (TAWS.sub.sol) based on the speeded-up flight simulations (Sim.sub.acc); a step of determining the origins of terrain collision risks (Risqs) with a view to validating (OK) or not validating (NOK) the terrain database (TerrDB).

2. The validating method according to claim 1, wherein the trajectory data are instantaneous aircraft vectors (Vai).

3. The validating method according to claim 2, wherein the instantaneous aircraft vectors (Vai) are obtained by sampling trajectories FMS.sub.traj generated by a flight management system (FMS).

4. The validating method according to claim 3, wherein the FMS trajectories are generated based on a plurality of scenarios (Sri), said scenarios (Sri) being based on at least one parameter belonging to a set of parameters comprising at least: a mass of the aircraft; a wind strength; a climb rate of the aircraft; a descent rate of the aircraft; a takeoff temperature; a landing temperature; a cruising speed of the aircraft; a cruising altitude of the aircraft.

5. The validating method according to claim 3, wherein the scenarios are generated based on operational routes (Roads), said operational routes (Roads) using previously extracted departure procedures (Proc.sub.dep) and arrival procedures (PrOC.sub.arr).

6. The validating method according to claim 5, wherein the departure procedures (Proc.sub.dep) and the arrival procedures (Proc.sub.arr) are extracted from a navigation database (NavDB).

7. A device for validating a terrain database (TerrDB), said terrain database (TerrDB) comprising a plurality of items of information on at least one geographical region (Z.sub.G) liable to be flown over by an aircraft, said validating device comprising: a module for generating data on trajectories of the aircraft over the geographical region (Z.sub.G); a flight simulator based on said trajectory data, said flight simulations being speeded up (Sim.sub.acc); a system for signalling terrain collision risks (TAWS.sub.sol) to determine terrain collision risks (Risqs) based on the speeded-up flight simulations (Sim.sub.acc); a module for determining the origin of terrain collision risks (Risqs) with a view to validating (OK) or not validating (NOK) the terrain database (TerrDB).

8. A computer program product comprising instructions suitable for executing the steps of a validating method according to claim 1.

9. A system for signalling terrain collision risks intended to be installed on board an aircraft, said onboard signalling system being able to warn a crew of said aircraft of a terrain collision risk in a geographical region flown over by said aircraft, said onboard signalling system comprising all or part of a terrain database (TerrDB), said terrain database (TerrDB) having been previously validated by the validating method of claim 1.

10. An aircraft comprising an onboard system for signalling terrain collision risks according to claim 9.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The present invention will be better understood upon reading the detailed description of embodiments, taken by way of completely non-limiting example and illustrated by the appended drawings, in which:

[0021] FIG. 1 illustrates an example of samples of points characterizing an arrival procedure according to the prior art;

[0022] FIG. 2 illustrates a device for validating a terrain database according to the invention;

[0023] FIG. 3 illustrates the steps of the validating method implemented by the validating device of FIG. 2;

[0024] FIG. 4 illustrates an onboard system for signalling terrain collision risks comprising all or part of a terrain database validated according to the validating method of FIG. 3.

DETAILED DESCRIPTION

[0025] The invention is not limited to the embodiments and variants that are presented, and other embodiments and variants will be readily apparent to those skilled in the art.

[0026] FIG. 2 illustrates, according to the invention, a device for validating a terrain database TerrDB according to the invention.

[0027] The terrain database TerrDB is a database grouping together all of the topographical information on one or more geographical regions covered by said database. This database is obtained by aggregating many heterogeneous sources, such as civil sources or military sources.

[0028] The device for validating the terrain database TerrDB comprises:

a navigation database NavDB,
a procedure extraction module 110;
a route set generator 120;
a scenario Sri generator 130;
an FMS system;
an instantaneous aircraft vector generator 140;
a flight simulator 150;
a ground-based TAWS TAWS.sub.sol;
a module 160 for determining risk origin.

[0029] The navigation database NavDB is a database comprising all of the departure procedures and all of the arrival procedures covering all airports worldwide. This requires that the concatenation rules dictated by the A424 standard be observed. Conventionally, a departure procedure is composed of a runway, followed by a SID (standard instrument departure), followed by a SID_TRANS. Inversely, an arrival procedure is composed of a STAR_TRANS, followed by a STAR (standard terminal arrival route), followed by a VIA, followed lastly by an APPR (for precision approach). Not all runways at an airport are compatible with all SIDs which are in turn not all compatible with all SIS_TRANSs. The same applies for arrival procedures. Still, this restrictive combination reaches a limit of around 60 000 departure combinations and 300 000 arrival combinations for a current database. The combination of departure procedures and arrival procedures results in a number of combinations of at least 18 billion. Of course, this maximum combination is heavily dependent on the flight capabilities of the aircraft in question. By considering the maximum operational capability range of the aircraft, it is possible to reduce this combination. The navigation database NavDB is a shared database. It is updated monthly.

[0030] By way of example, FIG. 1 illustrates an arrival procedure 1. This comprises a set of trajectory portions Pi, each trajectory portion Pi running between two waypoints Ci-1, Ci. For this, each waypoint Ci-1, Ci is defined in a three-dimensional space.

[0031] The procedure extraction module 110 is designed to extract from the navigation database NavDB the departure procedures Proc.sub.dep and the arrival procedures Proc.sub.arr associated with the geographical regions Z.sub.G covered by the terrain database TerrDB.

[0032] The route set generator 120 is designed to generate operational routes Roads based on the extracted departure procedures Proc.sub.dep and arrival procedures Proc.sub.arr. This route set is generated in relation to the capability range of the aircraft in question allowing all of the extracted procedures to be covered while using available airways to link the end of a departure procedure to the beginning of an arrival procedure. Aviation regulations define airways in order to manage aircraft spacing. Each airway is defined by a given altitude and a given direction (some may be two-way). Seeking to produce the total combination “every procedure Proc.sub.dep”דall arrival procedures Proc.sub.arr”דall airways” would not be achievable unless supercomputers were used and would not be of validation interest anyway. It is sought here to cover each departure procedure Proc.sub.dep and each arrival procedure Proc.sub.arr once by selecting each time a pair spaced apart by a distance consistent with the type of aircraft in question and linking them using available airways constructed using a conventional pathfinding algorithm (for example the A* algorithm).

[0033] The scenario Sri generator 130 is designed to generate scenarios based on operational routes Roads. These scenarios are based on at least one parameter belonging to a set of parameters comprising at least:

a mass of the aircraft;
a wind strength;
a climb rate of the aircraft;
a descent rate of the aircraft;
a takeoff temperature;
a landing temperature;
a cruising speed of the aircraft;
a cruising altitude of the aircraft.

[0034] On this list, some parameters are directly linked to the operational capability range of the aircraft. By way of example, it is possible to produce a scenario of “low mass, high climb rate, without wind or temperature deviation on takeoff”. Another exemplary scenario might be “high mass, low climb rate, strong descent wind on arrival”. The idea is not to cover the entire operational capability range of the aircraft but rather to construct limit scenarios in order to compute “corridor” trajectories. The idea is also to conduct a large, but still reasonable, number of tests and therefore limit combinations while still retaining a high level of trustworthiness with regard to the relevance of the results.

[0035] The FMS is designed to compute an associated trajectory FMS.sub.traj for each of the scenarios. This trajectory FMS.sub.traj is multidimensional, with the main dimensions being latitude, longitude, altitude and speed. It is therefore necessary to inject the entirety of the scenario (departure procedure, list of airways, arrival procedure, masses, winds, etc.) into the FMS. It will then be able to compute a complete trajectory. The trajectories FMS.sub.traj are continuous and stable, in particular in their behaviour. Thus, with constant parameters, a trajectory FMS.sub.traj computed with medium mass will be situated between a low-mass trajectory and a high-mass trajectory. The most dimension-determining parameters to be varied are therefore: the mass, the climb/descent rate, the wind, the temperature on takeoff/landing, the speed and the cruising altitude.

[0036] In one preferred embodiment, the FMS is certified to the DAL B (Design Assurance Level B) standard. Such an FMS may benefit from “open” capabilities allowing communication and interactions with the outside, for example with a computing cloud, with a view to improving data processing.

[0037] The instantaneous aircraft vector generator 140 is designed to finely sample each of the trajectories FMS.sub.traj generated previously by time interval or distance in order to obtain an “instantaneous aircraft vector” therefrom. It is thus possible to reconstruct a trajectory with N dimensions, N being the number of parameters of the computed aircraft vector. Since each trajectory FMS.sub.traj is computed along distinct axes, on the one hand there is the lateral “ground” trajectory of the aircraft and on the other hand its extended vertical trajectory (altitude, speed, mass, etc.). These two aspects must therefore be combined and then divided according to a set pitch in order to simulate the “sliding vector” aspect.

[0038] The flight simulator 150 is designed to simulate flights based on instantaneous aircraft vectors. The flight simulator 150 carries out this simulation speeded up so as to limit the computing capacity required for this simulation. For example, instead of taking a real flight point sample every 5 ms, points are processed every 60 ms, which allows the processing speed to be accelerated. For the speeded-up simulation, the sampling is constant here.

[0039] In one preferred embodiment, it is possible to improve the simulation through “massive testing” or distributing computing via cloud.

[0040] The ground-based TAWS TAWS.sub.sol is designed to signal terrain collision risks Risqs based on the flight simulations.

[0041] The module 160 for determining the origin of terrain collision risks is designed to store and process the terrain collision risks with a view to determining the cause thereof. For this, the terrain collision risks are grouped together by type and by airport. Specifically, if an error that is the cause of a collision risk is present in a specific geographical region, there is a high probability that the majority of procedures in this geographical region result in a collision risk. It is possible to loop back as many times as necessary by sending a command K to the procedure extraction module 110. This command K contains a list of the geographical regions on which the analysis will be performed. This list may vary between two successive loops.

[0042] If, after multiple successive loops, it is determined that the cause of the collision risk originates in the terrain database TerrDB and that this cause is an error, then a non-validation message NOK is transmitted to a control module 170. This control module 170 is designed to deactivate the terrain database TerrDB and/or to send a correction request Corr1 to said database. If it is determined that the cause of the risk is not an error or that this cause does not originate in the terrain database TerrDB, a validation message OK is then transmitted to the control module 170 and the terrain database TerrDB is validated. It will be noted that in this case the control module 170 may transmit a correction request Corr2 to the navigation database NavDB if it is the cause of the error. In one preferred embodiment, control by the control module 170 is automated. It is thus possible to validate “erroneous” trajectories with a system other than the TAWS simply by verifying the altitude at each point with respect to the terrain database TerrDB or another external source. In the case that the warning is justified with respect to the aircraft's performance (it is possible for the procedure to be in accordance but the aircraft's configuration to be unsuitable for the procedure) then it would be appropriate to envisage providing an airline with a list of procedures to which particular attention should be paid by the pilot if they select one of them.

[0043] The terrain database TerrDB may then be transmitted partially or entirely to a system 20 for signalling terrain collision risks installed on board an aircraft 200.

[0044] Such a system 20 is, more particularly, illustrated in FIG. 4. It comprises:

a database 210;
flight equipment 220;
a computer 230;
a warning generator 240.

[0045] The database 210 is part of the terrain database TerrDB validated by the validating device of FIG. 2. This part of the database specifically covers those geographical regions which will be flown over by the aircraft 200.

[0046] The flight equipment 220 is designed to determine the main flight parameters including the position of the aircraft in terms of latitude, longitude and altitude, and direction, and the modulus of the aircraft's speed vector. These data are transmitted to a computer 230.

[0047] The computer 230 is designed to determine terrain collision risks based on data from the database 210 and the flight parameters.

[0048] The warning generator 240 is designed to generate a sound and visual warning if the computer 230 determines a potential risk of collision with the terrain.

[0049] It should be noted that this system 20 for signalling terrain collision risks corresponds to the system for signalling terrain collision risks TAWS.sub.sol used to validate the terrain database TerrDB. As a variant, the systems are different. For example, the processing capacity of the onboard system 20 is lower than the TAWS TAWS.sub.sol on the ground.

[0050] FIG. 3 details the steps of a method for validating a terrain database TerrDB implemented by the validating device 10 of FIG. 2. This method comprises a step E1 of extracting departure Proc.sub.dep and arrival procedures associated with geographical regions Z.sub.G covered by the terrain database TerrDB. In a step E2, a set of operational routes Roads is generated based on the extracted departure procedures Proc.sub.dep and arrival procedures Proc.sub.arr. In a step E3, scenarios Sri are generated based on the operational routes Roads. These scenarios are then processed in a step E4 by an FMS to form trajectories FMS.sub.traj. In a step E5, the trajectories FMS.sub.traj are sampled to obtain instantaneous aircraft vectors. The instantaneous aircraft vectors form data on trajectories and speeded-up flight simulations based on said data are produced in a step E6. In a step E7, terrain collision risks Risqs are determined by the system for signalling terrain collision risks TAWS.sub.sol based on the speeded-up flight simulations Sim.sub.acc. In a step E8, the causes of terrain collision risks Risqs are determined to determine whether there is an error in the terrain database TerrDB. Depending on this analysis, a validation OK or non-validation NOK message for this terrain database is transmitted to the control module 170 in a step E9. It will be noted that steps E1 to E8 may be carried out multiple times in multiple successive loops depending on the needs of the analysis of the origins of collision terrain risks Risqs. It will be noted that steps E4, E6 and E7 may be carried out, at least partly, by processing means present in a computing cloud.

[0051] Another subject of the invention relates to a computer program product comprising program instructions that are usable by the validating device of FIG. 2 which, when they are executed or interpreted by said validating device, trigger the implementation of the validating method as described with reference to FIG. 3.

[0052] The invention thus affords the following advantages: it makes it possible to validate the ground-based TAWS TAWS.sub.sol coupled to the terrain database TerrDB by using the trajectories FMS.sub.traj computed with DAL B over a set of operational routes Roads using the entire global navigation database NavDB.

[0053] The ground-based TAWS TAWS.sub.sol robustifies with respect to raising alarms needlessly close to airports during takeoff or approach.

[0054] The ground-based TAWS TAWS.sub.sol detects artefacts before a new terrain database TerrDB is brought into operation.

[0055] The ground-based TAWS TAWS.sub.sol validates each new terrain database TerrDB or each update to this database in order to ensure the overall quality of the TAWS product.

[0056] The FMS validates all of the trajectories calculated in terms of excursion with the aid of the certified external TAWS TAWS.sub.sol.

[0057] The FMS validates new RNP (required navigation performance) procedures according to the FMS reality.

[0058] The FMS validates new navigation databases NavDB or each update to this database in order to ensure the overall quality of the TAWS product.

[0059] The FMS validates LLF (low-level flight) trajectories.

[0060] Longer-term, it is possible to use this validating method for FMS feedback and thereby allow a safe trajectory to be constructed.