Rapport d'enquête aéronautique A01P0126

Le Bureau de la sécurité des transports du Canada (BST) a enquêté sur cet événement dans le seul but de promouvoir la sécurité des transports. Le Bureau n'est pas habilité à attribuer ni à déterminer les responsabilités civiles ou pénales.

Consulter le document en PDF

Il faut un lecteur de PDF pour lire cette version. Détails dans notre page d'aide.

Perte d'espacement
Centre de contrôle régional de Vancouver
Exploité par NAV CANADA à 110 nm au
Nord-Ouest de l'intersection DUXAR
(Colombie-Britannique)
le 8 juin 2001

Résumé

Le Bœing 737 d'Air Canada avait quitté Vancouver (Colombie-Britannique) pour un vol régulier (ACA3584) à destination de Whitehorse (Yukon). L'appareil était en croisière au niveau de vol (FL) 310 sous le contrôle du centre de contrôle régional (ACC) de Vancouver. Un DC-10 d'Omni Air Express (OAE960), volant vers le sud-est en provenance d'Anchorage (Alaska) et à destination de Cherry Point (Caroline du Nord) sous le contrôle de l'ACC d'Edmonton, avait reçu l'autorisation de monter du FL290 au FL330. Environ 10 minutes après que le B737 a franchi la limite séparant l'espace aérien de Vancouver et de celui d'Edmonton à l'intersection DUXAR, une perte d'espacement s'est produite dans l'espace aérien non radar lorsque le DC-10 s'est retrouvé en conflit, au FL310, avec le B737. Les deux appareils ont reçu un avertissement de leur système de surveillance du trafic et d'évitement des collisions : le DC-10 est descendu au FL290 et le B737 est monté au FL335 avant de revenir au FL310, une fois le conflit résolu.

This report is also available in English.

Autres renseignements de base

Le B737 (ACA3584) se rendait à Whitehorse en passant par le VOR (radiophare omnidirectionnel VHF) de Houston et l'intersection DUXAR à l'altitude autorisée du niveau de vol (FL) 310. Il a croisé la route 10 de la Région de contrôle du Nord (NCA 10) à environ 110 milles marins (nm) au nord-ouest de l'intersection DUXAR. Cette intersection se trouve à la limite de l'espace aérien des centres de contrôle régionaux (ACC) de Vancouver et d'Edmonton (voir la figure 1). Entre le VOR de Houston et DUXAR, l'appareil se trouvait sous le contrôle du secteur Sandspit de l'ACC de Vancouver.

Figure 1 - Trajectoire des vols ACA3584 et OAE960


Figure 1. Trajectoire des vols ACA3584 et OAE960

La plupart du trafic de ce secteur vole à haute altitude, à destination ou en provenance des points d'entrée de l'espace aérien océanique. Le trafic du secteur était traité par un contrôleur radar et un contrôleur de données jusqu'à 15 minutes avant l'incident, heure à partir de laquelle il n'a plus été traité que par un seul contrôleur radar. La charge de travail avait été jugée modérée, avec une certaine complexité. Un certain nombre d'appareils pénétrant dans la portion Ouest du secteur ne faisaient pas l'objet d'un plan de vol dans le système de traitement des données radar (RDPS) et le numéro de vol de leur cible radar n'était donc pas affiché. Les contrôleurs étaient alors contraints, dans certains cas, de saisir manuellement cette donnée jusqu'à ce qu'il soit possible de mettre à jour le RDPS. L'attention du contrôleur radar de Sandspit était donc concentrée sur la portion Ouest de l'espace aérien. Le B737, quant à lui, transitait dans la portion Nord-Est du secteur où il était alors le seul appareil en vol.

L'heure estimée de passage du B737 à l'intersection DUXAR, à savoir 14 h 27, heure avancée du Pacifique1, avait été transmise par le contrôleur du secteur précédent (Haida) au contrôleur des données de Sandspit et avait été, peu avant, modifiée pour 14 h 22. Le contrôleur radar de Sandspit a accepté le transfert de contrôle radar du B737, alors à proximité de la limite du secteur de Haida et, à 14 h 6, a établi le contact avec l'appareil. Aucune autre communication n'a été échangée entre le B737 et le contrôleur de Sandspit. Contrairement aux procédures de l'ACC de Vancouver, le contrôleur de Sandspit n'a pas donné au B737 l'instruction d'entrer en contact avec l'ACC d'Edmonton au point de repère de la limite (DUXAR).

Un certain nombre de listes permettent aux contrôleurs d'afficher, sous forme alphanumérique, les données de vol sur l'écran radar. La liste d'arrivée affiche les données des vols qui relèvent actuellement du contrôleur, mais qui ne sont pas encore affichés en tant que cibles sur l'écran radar. Les appareils figurant sur la liste d'arrivée sont suivis par le système radar. La liste d'extrapolation affiche les données relatives aux appareils qui portent un indicatif de secteur (CJS), mais dont la cible a été perdue par le radar. Grâce à ces listes, les données de vol demeurent disponibles au contrôleur, quand bien même la cible radar n'est pas affichée à ce moment-là. Ces listes sont conçues comme des moyens d'éviter que les contrôleurs n'oublient les vols qui ne sont pas affichés. Le Manuel d'exploitation du contrôle de la circulation aérienne (MANOPS ATC) de NAV CANADA stipule que la liste d'extrapolation doit demeurer affichée en permanence, tandis que l'affichage des autres listes, telles que la liste d'arrivée, est laissée à la discrétion du contrôleur.

L'intersection DUXAR est un point de compte rendu obligatoire indiqué sur les cartes en route de haute altitude canadiennes. Les appareils passant par ce point doivent indiquer leur position à un service de circulation aérienne. Les appareils se trouvant sous contrôle radar, cependant, n'ont à signaler leur position à un point de compte rendu obligatoire que lorsque cela leur est expressément demandé. Le contrôleur radar de Sandspit n'a pas demandé au B737 de faire un compte rendu de position et le pilote n'en a pas fait.

À 14 h 19, la cible radar du B737 a disparu sur le bord nord-est de l'écran du contrôleur radar de Sandspit, juste au moment où le B737 pénétrait, à l'intersection DUXAR, dans l'espace aérien contrôlé par l'ACC d'Edmonton. La cible radar et le bloc de données ont disparu et le numéro de vol ainsi que le CJS, marqués d'un astérisque, ont été transférés à la liste d'arrivée affichée au bas de l'écran du contrôleur. Le contrôleur radar de Sandspit n'a pas remarqué que la cible radar du B737 n'était plus affichée. Le B737 est sorti de la couverture radar à 14 h 22, à environ 22 nm au nord-ouest de l'intersection DUXAR. Le numéro de vol de l'appareil a alors été transféré de la liste d'arrivée à la liste d'extrapolation. Le contrôleur radar de Sandspit n'a pas remarqué le transfert d'information d'une liste à l'autre et n'en a été alerté d'aucune façon par le système informatique.

Le DC-10 (OAE960) volait d'Anchorage à Cherry Point au FL290 sur la NCA 10. À 14 h 29, le pilote a demandé à l'ACC d'Edmonton l'autorisation de monter au FL330. Le contrôleur de l'ACC d'Edmonton lui a accordé l'autorisation d'effectuer cette montée et l'appareil a commencé à monter peu après. Deux minutes environ après avoir entamé sa montée, le pilote du DC-10 a averti le contrôleur de l'ACC d'Edmonton qu'il redescendait au FL290, puisqu'il venait de recevoir un avertissement du système de surveillance du trafic et d'évitement des collisions (TCAS) lui signalant un autre appareil à 2000 pieds au-dessus de lui.

À 14 h 37, le pilote du B737 a pris contact avec l'ACC d'Edmonton et a annoncé qu'il se trouvait à 177 nm de Whitehorse, en palier au FL310, et que 10 nm plus tôt (approximativement au moment où il croisait la NCA 10), il avait reçu un avis de résolution (RA) du TCAS lui intimant de monter en raison de l'intrusion d'un appareil s'approchant de lui par en dessous. Le pilote était monté de 2 500 pieds à un taux de 3 000 pieds par minute afin d'éviter l'intrus puis, une fois le conflit résolu, était redescendu au FL310. Les contrôleurs de l'ACC d'Edmonton, avant l'appel du B737, n'étaient pas au courant que ce dernier avait pénétré dans leur espace aérien, car l'ACC de Vancouver n'avait pas transmis d'estimée à l'ACC d'Edmonton. Les contrôleurs de Sandspit n'avaient pas coordonné le vol du B737 avec l'ACC d'Edmonton. L'entente passée entre les ACC d'Edmonton et de Vancouver stipule qu'une unité doit transmettre une estimée à l'autre unité 15 minutes avant que l'appareil ne pénètre dans l'espace aérien de cette dernière.

Le DC-10 et le B737 volaient dans un espace aérien sans couverture radar lorsqu'ils ont reçu les avertissements de leur TCAS. Le degré de proximité des appareils n'a pas pu être déterminé, mais les avis de résolution sont normalement émis par les TCAS lorsque les appareils se trouvent à environ 20 secondes de vol l'un de l'autre. L'espacement requis entre des appareils se trouvant sur des routes opposées dans un environnement non radar est, verticalement, de 2 000 pieds, et cela, de 10 minutes avant leur croisement jusqu'à 10 minutes après leur croisement prévu.

Les estimées des appareils pénétrant dans l'espace aérien du centre de contrôle de la circulation sur les routes aériennes (ARTCC) d'Anchorage sont transmises à cet organisme par des spécialistes de l'exploitation de la circulation aérienne (ATOS). Les estimées pour les appareils pénétrant dans l'espace aérien d'un ACC canadien adjacent sont directement transmises par le contrôleur. Le contrôleur des données de Sandspit avait reçu une estimée pour le passage du B737 à DUXAR et l'avait ensuite incluse dans un lot de neuf autres estimées qu'il a transmis à l'ATOS. Le contrôleur des données de Sandspit aurait dû transmettre l'estimée du B737 directement au contrôleur de l'ACC d'Edmonton et non à l'ATOS.

Quelques minutes après avoir reçu le lot d'estimées, l'ATOS a rappelé le contrôleur des données de Sandspit pour se faire confirmer le numéro de vol du B737, car il l'avait mal noté. Le contrôleur des données de Sandspit a confirmé que le numéro de vol était ACA3584 et a modifié l'estimée précédente pour 14 h 22. L'ATOS a alors demandé au contrôleur de confirmer que l'estimée était pour Houston et le contrôleur a, par erreur, confirmé que c'était bien le cas. Les procédures locales stipulent que les contrôleurs doivent, lorsqu'ils transmettent une estimée à un ATOS, indiquer le numéro de vol, le point de repère, l'heure et l'altitude. Un examen des communications du contrôle de la circulation aérienne (ATC) a révélé que, lorsque le contrôleur a transmis le lot d'estimées, il n'a indiqué le point de repère que pour trois des neuf estimées.

Lorsque le contrôleur a transmis l'estimée du B737 à l'ATOS, ce dernier a cru que l'information devait être transmise à l'ARTCC d'Anchorage parce qu'il n'a pas pour fonction de transmettre les estimées à l'ACC d'Edmonton. Dans la plupart des cas, les ATOS ne posent pas de questions aux contrôleurs quant à l'information à transmettre à un autre organisme ATC. Il n'est pas inhabituel qu'un ATOS reçoive une estimée pour Houston à transmettre à l'ARTCC d'Anchorage et c'est pourquoi il a accepté une estimée du B737 pour ce point.

L'ATOS qui avait reçu l'estimée originale du B737, puis sa modification, a alors été remplacé par un autre ATOS lors de la rotation normale des quarts. Le second ATOS a reçu un message de rejet pour le B737 indiquant que le plan de vol n'était pas dans les dossiers du système de l'ARTCC d'Anchorage. L'usage veut que l'ATOS, confronté à un tel problème, examine la route, fasse une correction mineure, généralement la suppression d'un des derniers points de repère avant la destination, puis renvoie l'information. L'ordinateur d'Anchorage continuait néanmoins de rejeter le plan de vol. Après trois nouveaux rejets, l'ATOS a décidé d'entrer directement en contact avec son homologue d'Anchorage. Ce dernier lui a indiqué que les données relatives au B737 avaient été transmises à un superviseur de la salle, alors même que les deux ATOS ne comprenaient toujours pas pourquoi l'estimée avait été, en fait, transmise à Anchorage. Cette mesure a été jugée satisfaisante par les deux ATOS et aucune autre mesure n'a été prise au regard du B737. Il n'a pas été possible de déterminer qu'elles ont été les mesures prises par le superviseur d'Anchorage concernant l'estimée de cet appareil.

NAV CANADA n'a pas publié de procédures précises quant aux mesures que doivent prendre les ATOS lorsqu'ils sont confrontés à des rejets multiples des données d'une estimée. Les ATOS n'ont pas à avertir les contrôleurs qu'une estimée a été transmise avec succès. NAV CANADA a récemment mis en place une nouvelle version du logiciel d'envoi des données de plan de vol et d'estimée, mais ce dernier a grandement augmenté le nombre de messages de rejet reçus de l'ARTCC d'Anchorage, ce qui a accru de façon non négligeable la charge de travail des ATOS. En raison du nombre de problèmes rencontrés avec le nouveau système, ce dernier a été désactivé peu après cet incident et ne sera remis en service qu'après que des améliorations lui auront été apportées.

Le contrôleur des données de Sandspit a saisi l'estimée du B737 pour DUXAR dans la case 7 de la fiche de progression de vol (FPS) lorsqu'il l'a reçue pour la première fois du secteur de Haida (voir la figure 2, Nota : Toutes les heures indiquées sur les documents ATC sont en temps universel coordonné). Il n'a pas indiqué que l'estimée portait sur DUXAR. Les procédures de rédaction des fiches qui, à l'ACC de Vancouver, complètent la Partie 9, Rédaction des fiches de progression de vol, du MANOPS ATC, indiquent que la case 14 peut être utilisée pour noter les estimées aux points de repère qui ne sont pas affichés sur le tableau de progression de vol. Dans le cas de cet incident, la FPS du B737 a été placée, sur le tableau de progression de vol, sous le point de repère de Houston, et cela quand bien même l'estimée reçue portait sur DUXAR. Étant donné que le point de repère DUXAR ne figure pas sur le tableau de progression des vols, la case 14 de la FPS peut être utilisée pour indiquer le point de repère (DUXAR) et l'estimée correspondante. Il est également possible d'inscrire l'estimée pour DUXAR au-dessus du nom du point de repère en route dans la case 6. Les pratiques des contrôleurs, en matière d'inscription des estimées sur la FPS, varient. Lorsqu'il a reçu l'estimée pour DUXAR, le contrôleur des données de Sandspit a transmis l'information à l'ATOS et il a annoté la FPS de façon à y consigner que l'estimée avait été transmise au prochain secteur concerné. Les deux traits obliques dans la case 7 indiquent que l'estimée, ainsi qu'une modification à cette dernière, ont toutes les deux été transmises conformément à la procédure normalisée pour cet itinéraire de vol.

Figure 2 - Fiche de progression du vol ACA3584.

Figure 2. Fiche de progression du vol ACA3584

Le contrôleur radar de Sandspit a permis au contrôleur des données de prendre une pause autour de 14 h 15 et a assumé seul la responsabilité du radar et des données. L'exposé de transfert de responsabilité des deux contrôleurs n'a pas comporté d'examen détaillé de la position de chacun des appareils volant dans le secteur, car les deux contrôleurs avaient, durant le quart, assuré ensemble le contrôle du trafic. Un peu plus tard, alors qu'il réarrangeait le tableau de progression des vols, le contrôleur radar de Sandspit a remarqué que la fiche du B737 n'indiquait pas que l'appareil avait été transféré à l'ACC d'Edmonton. À 14 h 31, le contrôleur radar de Sandspit a demandé au contrôleur de l'ACC d'Edmonton de lui confirmer qu'il était bien en communication avec le vol ACA3584. Le contrôleur de l'ACC d'Edmonton lui a répondu que tel n'était pas le cas et qu'il n'avait pas reçu d'estimée pour ce vol.

Le Système d'affichage de l'espace aérien du Nord (NADSJ) de l'ACC d'Edmonton disposait, dans sa banque de données, des données de vol requises concernant le B737, et une FPS avait été imprimée pour les secteurs en question. Néanmoins, pour qu'un appareil apparaisse sur l'affichage de la situation du NADS (NSiT), le contrôleur d'Edmonton doit d'abord saisir une estimée pour un point de repère dans le NADS. Ce point de repère aurait dû être, pour le B737, l'intersection DUXAR. Le contrôleur d'Edmonton n'a pas reçu d'estimée du contrôleur de Sandspit et, aucune estimée pour un point de repère n'ayant été saisie, la cible n'a pas été affichée sur le NSiT du contrôleur.

Analyse

Les procédures et les pratiques normalisées des ATC en matière de traitement et de suivi des données de vol sont conçues pour offrir plusieurs dispositifs de sécurité afin de garantir que la défaillance de l'un d'entre eux n'entraîne pas immédiatement un accident. Parmi ces dispositifs de sécurité, mentionnons :

  • les procédures de traitement et de rédaction normalisées des fiches;
  • les procédures de coordination et d'information normalisées;
  • les systèmes automatisés alertant les contrôleurs des situations inhabituelles.

Dans le cas de l'incident qui nous intéresse, tous ces dispositifs ont connu une défaillance, ce qui a entraîné un risque de collision entre deux appareils de transport gros porteurs.

Le contrôleur des données de Sandspit n'a pas respecté les conventions locales de rédaction des FPS consistant à placer l'estimée pour DUXAR au-dessus du point de repère en route dans la case 6 ou d'inscrire DUXAR et de consigner l'estimée dans la case 14. Le contrôleur a écrit l'estimée du B737 pour DUXAR à un endroit normalement réservé à une estimée pour Houston. La FPS du B737 était donc impossible à distinguer de celles des autres vols à transmettre à l'ATOS. Même lorsque l'ATOS lui a demandé par la suite de confirmer le numéro de vol du B737, le contrôleur n'a pas compris la nature du problème et a même confirmé que l'estimée donnée à l'ATOS était pour Houston plutôt que pour DUXAR.

Les procédures locales de NAV CANADA précisent les données à inclure lors de la transmission d'une estimée à un ATOS. Dans ce cas, le contrôleur n'a pas indiqué à quel point de repère s'appliquait l'estimée du B737. De plus, le nom du point de repère n'a été indiqué que pour trois des neuf estimées transmises au même moment que celle du B737. Cette omission dans la procédure déléguait de fait à l'ATOS la responsabilité de déterminer où l'appareil allait pénétrer dans l'espace aérien du prochain organisme de contrôle et de déterminer à quel organisme l'estimée devait être transmise. NAV CANADA n'a fourni aucune instruction spécifique à suivre par le personnel ATOS lorsque celui-ci est confronté à des erreurs de système telles qu'un message de rejet de plan de vol. Le contrôleur des données n'a pas été averti, et rien n'exigeait qu'il le soit, quand est apparu le problème d'estimée du B737.

Le contrôleur radar de Sandspit n'a pas remarqué que la cible du B737 avait disparu de son écran parce que, à ce moment-là, son attention était concentrée sur le trafic de la partie Ouest du secteur. Le contrôleur radar de Sandspit n'a pas remarqué le transfert automatique des données du B737 dans la liste d'arrivée et la disparition subséquente de la cible radar, pas plus que le transfert des données de vols de la liste d'arrivée à la liste d'extrapolation. Les dispositifs de sécurité que constituaient les listes n'ont pas réussi à attirer l'attention du contrôleur sur le fait que la cible du B737 n'était plus affichée. Le système n'émet aucun avertissement impérieux pour alerter le contrôleur du fait que la cible radar n'est plus affichée. Puisque le B737 n'était plus visible sur l'écran radar et que son attention était concentrée sur un autre endroit du secteur, le contrôleur avait moins de chance de se souvenir qu'il avait l'obligation de transférer le B737 à l'ACC d'Edmonton. Dans un environnement de contrôle radar, les FPS seules sont moins souvent examinées et, pour cette raison, constituent un dispositif de sécurité moins efficace contre le fait d'oublier un appareil donné. Les contrôleurs ont la possibilité, en contrôle radar, de demander aux appareils des comptes rendus de position, mais cette technique n'est pas souvent utilisée lorsque des services de contrôle radar sont disponibles.

Le transfert de responsabilité du contrôleur des données de Sandspit au contrôleur radar de Sandspit à un moment de regroupement des postes du secteur n'a pas comporté d'examen détaillé de la position de chaque vol se trouvant dans le secteur. Les deux contrôleurs ont présumé qu'ils étaient tous les deux au courant de tous les appareils présents dans le secteur et n'ont pas comparé les données des FPS avec celles affichées pour les cibles radar.

La zone entourant l'intersection DUXAR constitue une zone critique en matière d'affichage et de communication avec les appareils. C'est pourquoi les procédures de transfert des estimées et de suivi de la progression des vols sont, dans cette zone, essentielles pour garantir le maintien de l'espacement requis. Du fait que le B737 n'apparaissait pas sur l'affichage NSiT d'Edmonton et que le contrôleur de Vancouver n'avait pas remarqué que l'appareil avait quitté la zone affichée sur son écran pour ensuite quitter la zone de couverture radar, plus aucun dispositif de sécurité n'existait pour éviter une perte d'espacement. Les avis de résolution fournis par les TCAS embarqués constituaient le dernier dispositif de sécurité pour éviter une éventuelle collision en plein ciel.

Faits établis quant aux causes et aux facteurs contributifs

  1. Le contrôleur des données de Sandspit n'a pas transmis l'estimée du B737 au centre de contrôle régional (ACC) d'Edmonton. Pour cette raison, l'appareil n'est pas apparu sur le NSiT (affichage de la situation du système d'affichage de l'espace aérien du Nord) du contrôleur d'Edmonton. Ce dernier n'était donc pas conscient de créer un conflit de trafic lorsqu'il a autorisé le DC-10 à monter.
  2. Le contrôleur radar de Sandspit n'a pas transféré le B737 à la fréquence de l'ACC d'Edmonton avant de perdre la communication avec l'appareil. Ainsi, l'appareil a pénétré dans l'espace aérien contrôlé d'Edmonton sans que le contrôleur d'Edmonton ne le sache.
  3. Le nom du point de repère a été omis lors de la transmission de l'estimée du B737 aux spécialistes de l'exploitation de la circulation aérienne (ATOS), et une telle omission s'est produite à plusieurs reprises. Pour cette raison, l'ATOS était dans l'impossibilité de savoir que l'estimée aurait dû être transmise à Edmonton plutôt qu'à Anchorage.

Faits établis quant aux risques

  1. Les directives que doivent suivre les ATOS en cas de réception d'un message de rejet de plan de vol n'indiquent pas explicitement les mesures à prendre. Cet état de fait a conduit à l'élaboration par les ATOS de procédures locales non normalisées.
  2. Aucun avertissement impérieux n'alerte les contrôleurs qu'un appareil relevant de leur responsabilité a disparu de l'affichage. Le transfert de données de vol entre listes qui en résulte n'a pas été, dans le cas de cet incident, suffisant pour attirer l'attention du contrôleur. Il n'existe aucune obligation d'afficher toutes les listes.
  3. Le transfert de responsabilités entre le contrôleur des données et le contrôleur radar de Sandspit n'a pas comporté d'examen détaillé de chacun des appareils présents dans le secteur, ce qui a réduit les chances de détecter d'éventuelles erreurs de coordination ou de rédaction des fiches.

Mesures de sécurité prises

NAV CANADA a instauré, à compter du 15 mai 2002, des procédures bien définies que les ATOS devront suivre lors de l'échange de données de vol, tant à l'intérieur d'un centre qu'entre deux centres. Ces nouvelles procédures indiquent également aux ATOS quelles mesures particulières prendre en cas de réception d'un message de rejet.

Le 8 avril 2002, le BST a publié l'avis de sécurité aérienne A020002-1 suggérant que NAV CANADA pourrait souhaiter élaborer des mesures efficaces en vue de s'assurer que les contrôleurs soient immédiatement alertés lorsqu'une cible radar disparaît de leur écran en raison du réglage de la portée de l'affichage, des limitations de la couverture radar ou de toute autre raison. NAV CANADA a répondu à ces avis le 30 mai 2002 et a indiqué que :

  1. l'ACC de Vancouver a reçu un nouvel affichage de la situation radar (RsiT) amélioré assurant un meilleur traitement de la perte de cible radar au moyen d'un surlignage en couleur et d'un clignotement d'alerte;
  2. NAV CANADA a lancé une enquête sur la sécurité de l'exploitation (OSI) de niveau 3 en vue d'étudier les problèmes de sécurité entourant la perte de cibles radar;
  3. NAV CANADA va poursuivre le développement de technologies permettant d'assurer le soutien au personnel d'exploitation en vue de réduire sa charge de travail et d'améliorer la sécurité.

Le présent rapport met fin à l'enquête du Bureau de la sécurité des transports sur cet incident. Le Bureau a autorisé sa publication le 13 août 2002.

Appendice A - Glossaire

ACC Centre de contrôle régional
ARTCC Centre de contrôle de la circulation sur les routes aériennes
ATC Contrôle de la circulation aérienne
MANOPS ATC Manuel d'exploitation du contrôle de la circulation aérienne
ATOS Spécialiste de l'exploitation de la circulation aérienne
CJS Indicatif de secteur
FL Niveau de vol
FPS Fiche de progression de vol
NADS Système d'affichage de l'espace aérien du Nord
NCA Région de contrôle du Nord
nm Mille marin
NSiT Affichage de la situation du NADS
RA Avis de résolution
RDPS Système de traitement des données radar
TCAS Système de surveillance du trafic et d'évitement des collisions
VOR Radiophare omnidirectionnel VHF

1.   Les heures sont exprimées en heure avancée du Pacifique (temps universel coordonné [UTC] moins sept heures), sauf indication contraire.