Problèmes avec les bases de données du GPS (TP 2228F-30)

Promotion et sensibilisation en matière de sécurité

C’est un fait bien établi que, de nos jours, les vieux ordinateurs et les nouveaux logiciels qui avalent gloutonnement des gigaoctets d’espace disque et de mémoire ne font pas très bon ménage. Le même problème survient lorsque de grosses bases de données sont entassées dans des récepteurs GPS de première génération dont l’espace mémoire est limité. Les bases de données de navigation grossissent continuellement et, dans certains cas, elles peuvent dépasser la capacité de stockage de certains récepteurs en place. Cette situation peut avoir de graves effets sur le fonctionnement des récepteurs GPS et, dans certains cas, pareils effets se sont déjà fait sentir. Les trois exemples suivants montrent ce qui peut arriver, habituellement au plus mauvais moment pendant le vol.

Printemps 2003

Pour installer une nouvelle base de données à l’intérieur d’un récepteur Trimble, le fournisseur de cette base de données a par mégarde créé une région géographique s’étendant de 40° N à 48° N et de 65,5° O à 76,5° O, à l’intérieur de laquelle le récepteur cessait de fonctionner, ce qui occasionnait une perte de guidage au GPS.

Été 2005

On a par inadvertance oublié d’introduire dans une base de données les points de cheminement commençant par la lettre « Z ». Quand l’un de ces points de cheminement faisait partie d’une procédure d’approche, le récepteur assignait la position 0° N et 0° O au point de cheminement manquant sans que le pilote ne reçoive le moindre avertissement. Une fois le problème porté à l’attention du fournisseur de la base de données, ce dernier s’est empressé de faire parvenir aux usagers une base de données acceptable.

Automne 2005

Les approches précision latérale et guidance vertical (LPV) (système de renforcement à couverture étendue [WAAS]) sont maintenant codées et entrées dans les bases de données de navigation. Dans un cas, deux approches de navigation de surface (RNAV) vers une seule de piste avaient été publiées — l’une en navigation latérale (LNAV) et l’autre en LPV. Pour économiser l’espace mémoire, on a codé la procédure LPV seulement, laquelle constituait la seule approche offerte. Malheureusement, comme on n’avait pas mis à jour le récepteur en fonction du WAAS, la seule approche dont le pilote disposait était celle qu’il ne pouvait pas effectuer légalement.

Les relations et la compatibilité entre les systèmes avioniques et leurs bases de données sont vérifiées lors de la certification initiale, mais il y a relativement peu de surveillance réglementaire des mises à jour des bases de données. La vérification avant vol de toutes les procédures requises (et de celles pouvant être utilisées légalement) au cours du vol constitue le seul moyen sûr d’éviter de se faire « piéger » par une erreur dans une base de données pendant une phase cruciale du vol. Les pilotes peuvent réduire le risque d’erreur dans une base de données pendant une phase cruciale d’un vol en vérifiant avant ce vol que toutes les approches raisonnablement envisageables ont été entrées dans ladite base de données, qu’elles peuvent être chargées correctement et qu’elles sont exactes. On peut vérifier l’exactitude des données en chargeant l’approche et en comparant la route et la distance de chaque étape avec les renseignements obtenus à partir de la carte sur papier.

Cette vérification risque d’augmenter le temps de préparation du vol, mais si elle peut servir à empêcher une seule mauvaise surprise, le jeu en vaudra la chandelle.