PROCEDE DE VALIDATION D'UNE BASE DE DONNEES TERRAIN

Abstract

 L'invention concerne un procédé de validation d'une base de données terrain (TerrDB) comprenant une étape de simulations de vols à partir de données de trajectoires d'un aéronef (200), lesdites simulations de vols étant réalisées en accéléré (Sim_acc), une étape de détermination de risques de collision terrain (Risqs) par un système de signalisation de risque de collision terrain (TAWS_sol) à partir des simulations de vols en accéléré (Sim_acc), une étape de détermination des origines de risques de collision terrain (Risqs) en vue de la validation (OK) ou de la non-validation (NOK) de la base de données terrain (TerrDB).

Description

Domaine technique

[0001] La présente invention se situe dans le domaine des systèmes de gestion et de monitoring du vol d'un aéronef et plus particulièrement d'un système de gestion de vol (FMS) et d'un système embarqué de signalisation des risques de collision terrain (TAWS).

Technique antérieure

[0002] Il est connu d'utiliser dans un aéronef un système de gestion de vol dit système FMS pour « Flight Management System » en anglais. Un tel système permet de calculer des trajectoires et des plans de vol de l'aéronef et de fournir des consignes de guidage adaptées au pilote ou au pilote automatique pour suivre la trajectoire calculée. Dans le domaine de la navigation aérienne, une trajectoire d'un aéronef comprend une dimension horizontale et une dimension verticale. Le squelette de la trajectoire horizontale est appelée route et elle est constituée d'une séquence de points de plan de vol joints par des segments. Chacun de ces segments est défini entre deux points de cheminement, le point de cheminement final d'un segment formant également le point de cheminement initial du segment suivant de la route. Ces points de cheminement peuvent, par exemple, être définis par l'emplacement de balises de radionavigation ou par des coordonnées géographiques.

[0003] Le système FMS calcule ainsi une trajectoire optimisée à partir de différents critères tels que la consommation de carburant, le confort passager, la précision vis-à-vis des performances de l'aéronef, etc. Cette trajectoire, bien qu'elle soit conforme à la procédure générale de gestion de vol, peut néanmoins varier de manière conséquente selon les configurations de l'aéronef ou la météo du jour. C'est pourquoi l'aéronef est monitoré en temps réel par rapport à son environnement et notamment par rapport à des conflits avec le terrain. Un tel monitoring est réalisé par un système de signalisation des risques de collision terrain dit système TAWS pour « Terrain Awareness and Alerting Systems ». Ce système TAWS est adapté pour être embarqué à bord des aéronefs en vue d'assurer la prévention des accidents aéronautiques, tels que des collisions avec le sol ou des parties de terrain en élévation. Les accidents de ce type, connus dans la littérature technique sous l'acronyme CFIT pour « Controlled Flight Into Terrain » constituaient dans le passé une proportion importante des catastrophes aériennes. Les collisions avec le terrain sont désormais évitées grâce à des manœuvres d'évitement du terrain effectuées par les équipages sous l'incitation d'alertes et d'alarmes provenant du système TAWS.

[0004] Pour réaliser sa mission de surveillance de l'aéronef par rapport au terrain, le système TAWS s'appuie sur une base de données terrain. De ce fait les générations d'alertes et d'alarmes sont fortement dépendantes de la qualité de cette base de données terrain. Or aujourd'hui, la base de données terrain est obtenue par agrégation de nombreuses sources hétérogènes. Des artefacts, telles que des montagnes invisibles au milieu de l'océan, peuvent alors apparaître et lever, en conséquence, des fausses alertes en opération. Afin d'éviter ces fausses alertes, il est connu de faire une revue d'ingénierie manuelle et une série limitée de tests pour garantir une qualité minimale de la base de données terrain. L'attention est alors apportée sur les zones fortement en delta mais la masse d'informations et de modifications étant tellement importantes qu'il est difficile d'être exhaustif.

[0005] Il existe donc un besoin d'assurer un niveau d'intégrité maximal avant la mise en service d'une nouvelle base de données terrain ou avant l'implémentation de nouvelles mises à jour dans cette base de données terrain.

Exposé de l'invention

[0006] La présente invention vise à remédier au moins en partie à ce besoin.

[0007] Plus particulièrement, la présente invention a pour objectif de valider le contenu d'une base de données terrain.

[0008] Pour cela un premier objet de l'invention concerne un procédé de validation d'une base de données terrain, ladite base de données terrain comportant une pluralité d'informations sur au moins une zone géographique apte à être survolée par un aéronef, ledit procédé de validation comportant des étapes mises en œuvre par des moyens informatiques telles qu'une étape de génération de données de trajectoires de l'aéronef sur la zone géographique, une étape de simulations de vols à partir des données de trajectoires, lesdites simulations étant réalisées en accéléré, une étape de détermination de risques de collision terrain par un système de signalisation de risques de collision terrain, à partir des simulations de vols en accéléré, une étape de détermination des origines de risques de collision terrain en vue de la validation ou de la non validation de la base de données terrain.

[0009] Classiquement le système de signalisation est embarqué dans un aéronef pour déterminer les risques de collision. Ces risques de collision sont identifiés au cours du vol et l'évolution future de ces risques est analysée sur un court laps de temps. C'est une alerte « temps réel immédiat ». Des erreurs dans l'émission de ces risques de collision, par exemple dues à la présence d'un artefact, peuvent être préjudiciables pour le pilotage de l'aéronef. Dans l'invention, les erreurs potentielles sont déterminées en amont d'un vol de l'aéronef par une validation de la base de données terrain. Il est ainsi déterminé une pluralité de trajectoires possibles de l'aéronef sur les zones géographiques couvertes par la base de données terrain. Ces trajectoires sont ensuite accélérées pour ne pas avoir à dérouler l'intégralité du vol à vitesse normale, au regard du nombre de vols que cela représente, puis traitées pour déterminer les origines des risques de collision soulevés par un système de signalisation des risques de collision terrain positionné au sol, c'est-à-dire non embarqué dans un aéronef. Par « trajectoire accélérée », on entend un échantillonnage de trajectoire supérieur ou égal à 60 ms.

[0010] Dans un mode de réalisation particulier, les données de trajectoires sont des vecteurs aéronefs instantanés.

[0011] Dans un mode de réalisation particulier, les vecteurs aéronefs instantanés sont obtenus par échantillonnage de trajectoires FMS_traj générées par un système de gestion de vol.

[0012] Dans un mode de réalisation particulier, les trajectoires FMS sont générées à partir d'une pluralité de scénarii, lesdits scénarii Sri étant basés sur au moins un paramètre appartenant à un ensemble de paramètres comprenant au moins une masse de l'aéronef, une force de vent, un taux de montée de l'aéronef, un taux de descente de l'aéronef, une température de décollage, une température d'atterrissage, une vitesse de croisière de l'aéronef, une altitude de croisière de l'aéronef.

[0013] Dans un mode de réalisation particulier, les scénarii sont générés à partir de routes opérationnelles, lesdites routes opérationnelles utilisant des procédures de départ et des procédures d'arrivée préalablement extraites.

[0014] Dans un mode de réalisation particulier, les procédures de départ et les procédures d'arrivée sont extraites d'une base de données de navigation.

[0015] Un autre objet de l'invention concerne un dispositif de validation d'une base de données terrain, ladite base de données terrain comportant une pluralité d'informations sur au moins une zone géographique apte à être survolée par un aéronef. Le dispositif de validation comprend un module de génération de données de trajectoires de l'aéronef sur la zone géographique, un simulateur de vols à partir desdites données de trajectoires, lesdites simulations de vols étant réalisées en accéléré, un système de signalisation des risques de collision terrain pour déterminer des risques de collision terrain à partir des simulations de vols en accéléré, un module de détermination d'origine des risques de collision terrain en vue de la validation ou de la non validation de la base de données terrain.

[0016] Un autre objet de l'invention concerne un programme d'ordinateur comportant des instructions adaptées pour l'exécution d'un procédé de validation selon l'objet précédent de procédé.

[0017] Un autre objet de l'invention concerne un système de signalisation de risques de collision terrain destiné à être embarqué dans un aéronef, ledit système embarqué de signalisation étant apte à avertir un équipage dudit aéronef d'un risque de collision terrain dans une zone géographique survolée par ledit aéronef, ledit système embarqué de signalisation comprenant tout ou partie d'une base de données terrain, ladite base de données terrain ayant été préalablement validée par le procédé de validation selon l'objet précédent de procédé.

[0018] Un autre objet de l'invention concerne un aéronef comportant un système embarqué de signalisation de risques de collision terrain selon l'objet précédent de système.

[0019] La présente invention sera mieux comprise à la lecture de la description détaillée de modes de réalisation pris à titre d'exemples nullement limitatifs et illustrés par les dessins annexés sur lesquels :

[Fig 1] la figure 1 illustre un exemple d'échantillons de points caractérisant une procédure d'arrivée, selon l'art antérieur ;

[Fig 2] la figure 2 illustre un dispositif de validation d'une base de données terrain selon l'invention ;

[Fig 3] la figure 3 illustre les étapes d'un procédé de validation mis en œuvre par le dispositif de validation de la figure 2 ;

[Fig 4] la figure 4 illustre un système embarqué de signalisation de risques de collision terrain comprenant tout ou partie d'une base de données terrain validée selon le procédé de validation de la figure 3.

[0020] L'invention n'est pas limitée aux modes de réalisation et variantes présentées et d'autres modes de réalisation et variantes apparaîtront clairement à l'homme du métier.

[0021] La figure 2 illustre, selon l'invention, un dispositif de validation d'une base de données terrain TerrDB selon l'invention.

[0022] La base de données terrain TerrDB est une base de données regroupant l'ensemble des informations topographiques d'une ou plusieurs zones géographiques couvertes par ladite base. Cette base est obtenue par agrégation de nombreuses sources hétérogènes, telles que des sources civiles ou des sources militaires.

[0023] Le dispositif de validation de la base de données terrain TerrDB comprend :

• une base de données de navigation NavDB ;
• un module d'extraction 110 de procédures ;
• un générateur 120 d'un ensemble de routes ;
• un générateur 130 de scénarii Sri ;
• un système FMS ;
• un générateur 140 de vecteurs aéronefs instantanés ;
• un simulateur de vol 150 ;
• un système TAWS_sol ;
• un module 160 de détermination d'origine des risques.

[0024] La base de données de navigation NavDB est une base de données qui comprend l'ensemble des procédures de départ et l'ensemble des procédures d'arrivée couvrant l'ensemble des aéroports mondiaux. Cela nécessite de respecter les règles d'enchaînement imposées par la norme A424. Classiquement une procédure de départ est composée d'un Runway, suivie d'une SID (pour « Standard Instrument Departure » en anglais), suivie d'une SID_TRANS. Réciproquement, une procédure d'arrivée est composée d'une STAR_TRANS, suivie d'une STAR (pour « Standard Terminal Arrivai Route » en anglais), suivie d'une VIA, suivie finalement d'une APPR (pour approche de précision). Toutes les Runway d'un aéroport ne sont pas compatibles de toutes les SID qui elles-mêmes ne sont pas compatibles avec toutes les SlS_TRANS. Il en est de même pour les procédures d'arrivée. Cette combinatoire restrictive permet néanmoins d'atteindre une exhaustivité d'environ 60 000 combinaisons de départ et 300 000 combinaisons d'arrivée pour une base de données actuelle. L'association de procédures de départ et des procédures d'arrivée arrive à un nombre de combinaisons d'au moins 18 milliards. Bien sûr, cette combinatoire maximale est fortement dépendante des capacités de vol de l'aéronef considéré. En considérant, la gamme opérationnelle maximale de l'aéronef, il est possible de réduire cette combinatoire. La base de données de navigation NavDB est une base partagée. Celle est mise à jour chaque mois.

[0025] A titre d'exemple, la figure 1 illustre une procédure d'arrivée 1. Celle-ci comprend un ensemble de parties de trajectoire Pi, chaque partie de trajectoire Pi s'étendant entre deux points de cheminement Ci-1, Ci. Pour cela, chaque point de cheminement Ci-1, Ci est défini dans un espace en trois dimensions.

[0026] Le module d'extraction 110 de procédures est adapté pour extraire de la base de données de navigation NavDB les procédures de départ Proc_dep et les procédures d'arrivée Proc_arr associées aux zones géographiques Z_G couvertes par la base de données terrain TerrDB.

[0027] Le générateur 120 d'un ensemble de routes est adapté pour générer des routes opérationnelles Roads à partir des procédures de départ Proc_dep et des procédures d'arrivée Proc_arr extraites. Cet ensemble de route est généré vis-à-vis de la gamme d'aéronef considéré permettant de couvrir l'intégralité des procédures extraites et en utilisant des autoroutes du ciel (ou airways en anglais) disponibles afin de relier la fin d'une procédure de départ et le début d'une procédure d'arrivée. La réglementation aérienne définit des autoroutes du ciel afin de gérer l'espacement des avions. Chaque autoroute du ciel est définie par une altitude donnée et une direction donnée (certaines peuvent être à double sens). Chercher à faire la combinatoire totale « chaque procédure Proc_dep » x « toutes les procédures d'arrivée Proc_arr » x « toutes les autoroutes du ciel » ne serait pas atteignable à moins d'utiliser de supercalculateurs et n'apporterait pas, de toute façon, d'intérêt de validation. On cherche ici à couvrir une seule fois chaque procédure de départ Proc_dep et chaque procédure d'arrivée Proc_arr en sélectionnant à chaque fois un couple espacé d'une distance cohérente du type d'aéronef considéré et en les reliant en utilisant un ensemble d'autoroutes du ciel disponibles construit avec un algorithme classique de recherche de chemin (par exemple l'algorithme A*).

[0028] Le générateur 130 de scénarii Sri est adapté pour générer des scénarii à partir des routes opérationnelles Roads. Ces scénarii sont basés sur au moins un paramètre appartenant à un ensemble de paramètres comprenant au moins :

• une masse de l'aéronef ;
• une force de vent ;
• un taux de montée de l'aéronef ;
• un taux de descente de l'aéronef ;
• une température de décollage ;
• une température d'atterrissage ;
• une vitesse de croisière de l'aéronef ;
• une altitude de croisière de l'aéronef.

[0029] Dans cette liste, certains paramètres sont directement liés à la gamme opérationnelle de l'aéronef. A titre d'exemple, il est possible de réaliser un scénario « masse faible, taux de montée élevée, sans vent ni écart de température au décollage ». Un autre exemple de scénario serait « masse élevée, taux de montée faible, fort vent de descente à l'arrivée ». La volonté ici est de ne pas couvrir l'ensemble de la gamme opérationnelle de l'aéronef mais plutôt de construire des scénarii aux limites afin de calculer des trajectoires « corridors ». L'idée est également de faire un grand nombre de tests mais néanmoins raisonnable et donc de limiter la combinatoire tout en conservant un bon niveau de confiance quant à la pertinence des résultats.

[0030] Le système FMS est adapté pour calculer pour chacun des scénarii une trajectoire FMS_traj associée. Cette trajectoire FMS_traj est multi-dimensions, les principales dimensions étant la latitude, la longitude, l'altitude et la vitesse. Il faut donc injecter l'ensemble du scénario (procédure de départ, liste des autoroutes du ciel, procédure d'arrivée, masses, vents, etc.) dans le système FMS. Celui-ci sera ainsi apte à calculer une trajectoire complète. Les trajectoires FMS_traj sont continues et stables notamment au niveau de leur comportement. Ainsi à paramètres constants, une trajectoire FMS_traj calculée à masse moyenne sera contenue entre la trajectoire à masse faible et celle à masse élevée. Les paramètres les plus dimensionnant à faire varier sont donc : la masse, le taux de montée/descente, le vent, la température au décollage/atterrissage, la vitesse et l'altitude de croisière.

[0031] Dans un mode de réalisation préférentiel, le système FMS est certifié selon la norme DAL-B (pour « Design Assurance Level » en anglais). Un tel système FMS peut bénéficier de capacités dites « ouvertes » permettant une communication et des interactions avec l'extérieur, par exemple avec un nuage informatique, en vue d'améliorer le traitement des données.

[0032] Le générateur 140 de vecteurs aéronefs instantanés est adapté pour échantillonner finement chacune des trajectoires FMS_traj préalablement générées par pas de temps ou de distance afin d'en obtenir « un vecteur aéronef instantané ». Il est ainsi possible de reconstruire une trajectoire à N dimensions, N étant le nombre de paramètres du vecteur aéronef calculé. Chaque trajectoire FMS_traj étant calculée selon des axes distincts, il y a d'un côté la trajectoire latérale « sol » de l'aéronef et d'un autre côté sa trajectoire verticale étendue (altitude, vitesse, masse, ...). Il faut alors combiner ces deux aspects et ensuite découper selon un pas fixe afin de simuler l'aspect « vecteur glissant ».

[0033] Le simulateur de vol 150 est adapté pour simuler des vols à partir de vecteurs aéronef instantanés. Le simulateur de vols 150 réalise cette simulation en accéléré de sorte à limiter les capacités de calcul nécessaires à cette simulation. Par exemple, au lieu de prendre un échantillon de points du vol réel tous les 5 ms, on traite des points toutes les 60 ms, ce qui permet d'accélérer la vitesse de traitement. Pour simuler en accéléré, l'échantillonnage est ici constant.

[0034] Dans un mode de réalisation préférentiel, il est possible d'améliorer la simulation par du « massive testing » ou par une distribution de calcul dans un nuage informatique.

[0035] Le système TAWS_sol est adapté pour signaler des risques de collision terrain Risqs à partir des simulations de vols.

[0036] Le module 160 de détermination d'origine des risques de collision est adapté pour stocker et traiter les risques de collision terrain en vue d'en déterminer l'origine. Pour cela les risques de collision terrain sont regroupés par typologie et par aéroport. En effet, si une erreur à l'origine d'un risque de collision est présente dans une zone géographique précise, il y a de fortes probabilités que la plupart des procédures de cette zone géographique soient génératrices d'un risque de collision. Il est possible de reboucler autant de fois qu'il est nécessaire par l'envoi d'une commande K au module d'extraction 110 de procédures. Cette commande K contient une liste des zones géographiques sur lesquels l'analyse va être effectuée. Cette liste peut varier entre deux rebouclages successifs.

[0037] Si après plusieurs rebouclage successifs, il est déterminé que l'origine du risque de collision provient de la base de données terrain TerrDB et que cette origine est une erreur, alors un message de non validation NOK est transmis à un module de contrôle 170. Ce module de contrôle 170 est adapté pour désactiver la base de données terrain TerrDB et/ou pour envoyer une requête de correction Corr1 à ladite base. Si il est déterminé que l'origine du risque n'est pas une erreur ou que cette origine ne provient pas de la base de données terrain TerrDB, un message de validation OK est alors transmis au module de contrôle 170 et la base de données terrain TerrDB est validée. On notera que dans ce cas le module de contrôle 170 peut transmettre une requête de correction Corr2 à la base de données de navigation NavDB si celle-ci est à l'origine de l'erreur. Dans un mode de réalisation préférentiel, le contrôle par le module de contrôle 170 est automatisé. Il est ainsi possible de valider des trajectoires « en erreur » avec un autre système que le système TAWS, en vérifiant simplement l'altitude à chaque point par rapport à la base de données terraine TerrDB ou une autre source extérieure. Dans le cas où l'alerte est justifiée par rapport aux performances de l'aéronef (il est possible que la procédure soit conforme mais que la configuration de l'aéronef soit inadaptée à la procédure) alors il serait opportun d'envisager de fournir à une compagnie aérienne une liste de procédures sur lesquelles une attention particulière devrait être portée par le pilote s'il sélectionne l'une d'entre elles.

[0038] La base de données terrain TerrDB peut alors être transmise partiellement ou en totalité à un système 20 de signalisation de risques de collision terrain embarqué dans un aéronef 200.

[0039] Un tel système 20 est, plus particulièrement, illustré à la figure 4. Il comprend :

• une base de données 210 ;
• des équipements de vol 220 ;
• un calculateur 230 ;
• un générateur d'alertes 240.

[0040] La base de données 210 est une partie de la base de données terrain TerrDB validée par le dispositif de validation de la figure 2. Cette partie de base de données couvre spécifiquement les zones géographiques qui vont être survolées par l'aéronef 200.

[0041] Les équipements de vol 220 sont adaptés pour déterminer les principaux paramètres de vol dont la position de l'aéronef en latitude, longitude et altitude ainsi que la direction et le module du vecteur vitesse de l'aéronef. Ces données sont transmises à un calculateur 230.

[0042] Le calculateur 230 est adapté pour déterminer les risques de collision terrain à partir des données de la base de données 210 et des paramètres de vol.

[0043] Le générateur d'alerte 240 est adapté pour générer une alerte sonore et visuel si le calculateur 230 détermine un potentiel risque de collision avec le terrain.

[0044] On notera que ce système 20 de signalisation de risques de collision terrain correspond au système de signalisation de risques de collision terrain TAWS_sol utilisé pour la validation de la base de données terrain TerrDB. En variante, les systèmes sont différents. Par exemple, le système 20 embarqué comporte moins de capacité de traitement que le système TAWS_sol au sol.

[0045] La figure 3 détaille les étapes d'un procédé de validation d'une base de données terrain TerrDB mis en œuvre par le dispositif de validation 10 de la figure 2. Ce procédé comprend une étape d'extraction E1 de procédures de départ Proc_dep et de procédures d'arrivée associées à des zones géographiques Z_G couvertes par la base de données terrain TerrDB. Dans une étape E2, un ensemble de routes opérationnelles Roads sont générées à partir des procédures de départ Proc_dep et des procédures d'arrivée Proc_arr extraites. Dans une étape E3, des scénarii Sri sont générés à partir des routes opérationnelles Roads. Ces scénarii sont ensuite traités dans une étape E4 par un système FMS pour former des trajectoires FMS_traj. Dans une étape E5, les trajectoires FMS_traj sont échantillonnées pour obtenir des vecteurs aéronefs instantanés. Les vecteurs aéronef instantanés constituent des données de trajectoires et des simulations de vols accélérés à partir desdites données sont réalisées dans une étape E6. Dans une étape E7, des risques de collision terrain Risqs sont déterminés par le système de signalisation de risques de collision terrain TAWS_sol à partir des simulations de vols en accéléré Sim_acc. Dans une étape E8, les origines de risques de collision terrain Risqs sont déterminées pour déterminer s'il existe une erreur dans la base de données terrain TerrDB. En fonction de cette analyse, un message de validation OK ou de non validation NOK de cette base de données terrain est transmise au module de contrôle 170 dans une étape E9. On notera que les étapes E1 à E8 peuvent être réalisées plusieurs fois selon plusieurs boucles successives selon les besoins d'analyse des origines de risques de collision terrain Risqs. On notera que les étapes E4, E6, E7 peuvent être réalisées, au moins en partie, par des moyens de traitement présents dans un nuage informatique.

[0046] Un autre objet de l'invention concerne un produit programme d'ordinateur comportant des instructions de programme exploitables par le dispositif de validation de la figure 2, qui lorsqu'elles sont exécutées ou interprétées par ledit dispositif de validation déclenchent la mise en œuvre du procédé de validation tel que décrit à l'appui de la figure 3.

L'invention apporte ainsi les avantages suivants :

[0047] Il est permis de valider le système TAWS_sol couplé à la base de données terrain TerrDB en utilisant les trajectoires FMS_traj calculées en DAL-B sur un ensemble de routes opérationnelles Roads utilisant l'ensemble de la base de navigation NavDB mondiale.

[0048] Le système TAWS_sol robustifie la levée d'alarmes inutiles à proximité des aéroports durant un décollage ou une phase d'approche.

[0049] Le système TAWS_sol détecte les artefacts avant la mise en opération d'une nouvelle base de données terrain TerrDB.

[0050] Le système TAWS_sol valide chaque nouvelle base de données terrain TerrDB ou chaque mise à jour de cette base de données afin d'assurer la qualité globale du produit TAWS.

[0051] Le système FMS valide l'ensemble des trajectoires calculées en terme d'excursion à l'aide du système externe TAWS_sol certifié.

[0052] Le système FMS valide de nouvelles procédures RNP (pour « Required Navigation Performance », en anglais) en fonction de la réalité FMS.

[0053] Le système FMS valide de nouvelles bases de donnée de navigation NavDB ou chaque mise à jour de cette base de données afin d'assurer la qualité globale du produit FMS.

[0054] Le système FMS valide les trajectoires LLF pour (« Low Level Flight » en anglais).

[0055] A plus long terme, il est possible d'utiliser ce procédé de validation pour un rebouclage FMS et ainsi permettre la construction d'une trajectoire sécurisée.

Revendications

1. Procédé de validation d'une base de données terrain (TerrDB), ladite base de données terrain comportant une pluralité d'informations sur au moins une zone géographique (Z_G) apte à être survolée par un aéronef (200), ledit procédé de validation comportant les étapes suivantes mises en œuvre par des moyens informatiques :

- une étape de génération de données de trajectoires de l'aéronef (200) sur la zone géographique (Z_G) ;

- une étape de simulations de vols à partir desdites données de trajectoires, lesdites simulations de vols étant réalisées en accéléré (Sim_acc) ;

- une étape de détermination de risques de collision terrain (Risqs) par un système de signalisation de risques de collision terrain (TAWS_sol), à partir des simulations de vols en accéléré (Sim_acc) ;

- une étape de détermination des origines de risques de collision terrain (Risqs) en vue de la validation (OK) ou de la non validation (NOK) de la base de données terrain (TerrDB).

2. Procédé de validation selon la revendication 1, dans lequel les données de trajectoires sont des vecteurs aéronefs instantanés (Vai).

3. Procédé de validation selon la revendication 2, dans lequel les vecteurs aéronefs instantanés (Vai) sont obtenus par échantillonnage de trajectoires FMS_traj générées par un système de gestion de vol (FMS).

4. Procédé de validation selon la revendication 3, dans lequel les trajectoires FMS sont générées à partir d'une pluralité de scénarii (Sri), lesdits scénarii (Sri) étant basés sur au moins un paramètre appartenant à un ensemble de paramètres comprenant au moins :

- une masse de l'aéronef ;

- une force de vent ;

- un taux de montée de l'aéronef ;

- un taux de descente de l'aéronef ;

- une température de décollage ;

- une température d'atterrissage ;

- une vitesse de croisière de l'aéronef ;

- une altitude de croisière de l'aéronef.

5. Procédé de validation selon l'une quelconque des revendications 3 ou 4, dans lequel les scénarii sont générés à partir de routes opérationnelles (Roads), lesdites routes opérationnelles (Roads) utilisant des procédures de départ (Proc_dep) et des procédures d'arrivée (Proc_arr) préalablement extraites.

6. Procédé de validation selon la revendication 5, dans lequel les procédures de départ (Proc_dep) et les procédures d'arrivée (Proc_arr) sont extraites d'une base de données de navigation (NavDB).

7. Dispositif de validation d'une base de données terrain (TerrDB), ladite base de données terrain (TerrDB) comportant une pluralité d'informations sur au moins une zone géographique (Z_G) apte à être survolée par un aéronef (200), ledit dispositif de validation comprenant :

- un module de génération (140) de données de trajectoires de l'aéronef (200) sur la zone géographique (Z_G) ;

- un simulateur de vols (150) à partir desdites données de trajectoires, lesdites simulations de vols étant réalisées en accéléré (Sim_acc) ;

- un système de signalisation des risques de collision terrain (TAWS_sol) pour déterminer des risques de collision terrain (Risqs) à partir des simulations de vols en accéléré (Sim_acc) ;

- un module (160) de détermination d'origine des risques de collision terrain (Risqs) en vue de la validation (OK) ou de la non validation (NOK) de la base de données terrain (TerrDB).

8. Produit programme d'ordinateur comportant des instructions adaptées pour l'exécution des étapes d'un procédé de validation selon l'une quelconque des revendications 1 à 6.

9. Système de signalisation de risques de collision terrain destiné à être embarqué dans un aéronef (200), ledit système embarqué de signalisation (20) étant apte à avertir un équipage dudit aéronef (200) d'un risque de collision terrain dans une zone géographique survolée par ledit aéronef (200), ledit système embarqué de signalisation (20) comprenant tout ou partie d'une base de données terrain (TerrDB), ladite base de données terrain (TerrDB), ayant été préalablement validée par le procédé de validation des revendications 1 à 6.

10. Aéronef comportant un système embarqué de signalisation de risques de collision terrain (20) selon la revendication 9.

Dessins