Annexe J de l'avis consultatif de l'ANT 2012-01

Guide d'élaboration pour les applications logicielles des OEPP

Préambule

La présente annexe livre de l’information sur les pratiques exemplaires et les orientations générales pour l’élaboration d’applications logicielles OEPP couramment utilisées. Les exemples cités n’excluent pas le recours à d’autres méthodes pouvant réaliser les mêmes objectifs. Les renseignements de base de cette annexe viennent du manuel OEPP de l’OACI, document 10020, révision 2. La terminologie employée dans ce document a été adaptée à la nomenclature propre au MDN et le FAC.

 Les fabricants, exploitants et fournisseurs devraient évaluer avec soin leurs besoins opérationnels propres au moment de la mise au point d’applications logicielles OEPP afin de respecter les normes les plus élevées en matière de sécurité et de fiabilité pour leur utilisation particulière.

1.       Applications de calcul des performances de décollage et d'atterrissage (TALP), et de masse et centrage (M et C) 

1.1.       Introduction

1.1.1       La validité et l’intégrité des données de TALP et de M et C sont essentielles pour la sécurité du vol. Ces types d’applications OEPP et les procédures relatives à leur utilisation doivent être correctement évalués avant que leur mise en service ne soit approuvée.

1.1.2       L’architecture de l’application, la HMI, les résultats des essais documentés, ainsi que les procédures et l’instruction relatives à l’OEPP de l’exploitant devraient être évalués avant l’approbation de l’utilisation opérationnelle des applications de TALP et de M et C de l’OEPP.

1.2       Architecture des applications de TALP

1.2.1       En général, les applications de calcul des TALP sont constituées d’un certain nombre de couches distinctes :

  1. HMI;
  2. module de calcul;
  3. information propre à l’aéronef;              
  4. base de données de l’exploitation aéroportuaire (AODB).

1.2.2       La figure A-1 donne un exemple d’architecture d’application de calcul des TALP. Les exploitants peuvent avoir recours à des solutions qui sont moins modulaires que l’exemple montré ici, et qui sont plutôt constituées d’éléments intégrés dans un seul logiciel. Dans d’autres cas, le niveau de modularité peut être poussé au point qu’une partie ou la totalité des éléments puissent provenir de différents fournisseurs.

Figure A-1.  Architecture d'application de calcul des TALP

Architecture d'application de calcul des performances de décollage et d'atterissage

Cette figure illustre une architecture où le pilote, ou une boîte avionique, fournit une entrée demandant au module de calcul de produire des données au sujet de la performance du décollage et de l’atterrissage pour une combinaison spécifique d’aéroport et d’aéronef. Le module de calcul prend une entrée de la base de données de l’aéroport, si celle-ci n’est pas incluse dans l’entrée du pilote ou de l’avionique. Il va ensuite prendre une entrée soit d’un logiciel de fabricant avec une base de données spécifique aux aéronefs, ou d’un tableau précalculé propre à l’aéronef, ou de données numérisées AFM ou FCOM propre à l’aéronef. Les résultats du calcul forment la sortie.

 

1.2.3       Interface humain-machine (HMI) d’entrée et de sortie. L’interface HMI de saisie prend les données entrées par le pilote (ou celles qui proviennent de l’avionique, le cas échéant) et les transmet au module de calcul. Les résultats sont ensuite transférés à l’interface HMI de sortie.

1.2.4       Module de calcul. Le module de calcul traite les données provenant de l’interface de saisie, puis transmet les résultats obtenus à l’interface de sortie.

1.2.4.1    Les données de la source de TALP proviennent généralement de tableaux précalculés (p. ex., tableaux du poids maximal autorisé sur les pistes), de cartes numérisées d’AFM ou de FCOM ou d’équations d’algorithmes et de données fondés sur les mouvements.

1.2.4.2    Dans le cas des données de source de TALP qui sont des données d’AFM numérisées ou qui sont fondées sur des équations de mouvements, les données sont généralement fournies dans un format qui respecte la spécification de normalisation des logiciels de calcul des performances d’aéronefs (SCAP) de l’Association du transport aérien international (IATA). La spécification SCAP de l’IATA offre aux fabricants, aux exploitants et aux tiers une manière normalisée d’échanger des données sur les performances des aéronefs.

1.2.4.3    Un logiciel courant qui utilise l’approche SCAP sera composé du module d’appel, d’un module SCAP (aussi appelé « module du fabricant »), et de données SCAP. Pour produire les résultats, le module de calcul assemble les données saisies dans la HMI et les données d’autres sources et peut faire appel au logiciel SCAP à plusieurs reprises, d’où l’expression « module d’appel », maintenant très répandue dans l’industrie.

1.2.4.4    Les résultats peuvent aussi être obtenus par interpolation des valeurs données dans des tableaux précalculés (p. ex., tableaux du poids maximal autorisé sur les pistes).

1.2.4.5    Dans certains cas, lorsqu’il n’y a pas de logiciel ou de données du fabricant ou que d’autres objectifs commerciaux existent, les tableaux figurant dans les AFM ou les FCOM sur papier peuvent être numérisés par des tiers qui produisent des données pour leurs propres produits commerciaux.

1.2.5       Sources de données de rendement aéronautique. Différentes sources de données sur les performances des aéronefs peuvent être exploitées par les applications TALP. Les données de rendement peuvent se présenter sous différents formats numériques :

  1. modules SCAP ou logiciel équivalent fourni par le fabricant;
  2. données de performance numérisées par l’exploitant à partir des données publiées dans le manuel de vol;
  3. données fondées sur les valeurs figurant dans les tableaux précalculés des performances au décollage et à l’atterrissage.

1.2.6       Base de données de l’exploitation aéroportuaire (« Airport, runway, obstacle database ou AODB). Le calcul des performances au décollage et à l’atterrissage nécessite des données sur les aéroports, les pistes et les obstacles. L’AODB devrait fournir cette information de manière appropriée. Généralement, il s’agit de la partie des applications de calcul des performances qui est le plus souvent mise à jour. La gestion de ces données est critique. Il incombe à l’exploitant d’assurer la qualité, l’exactitude et l’intégrité des données relatives aux pistes et aux obstacles, en collaboration avec le fournisseur de données.

1.3        HMI des applications de calcul des performances de décollage et d’atterrissage et de la masse et du centrage

1.3.1        Les erreurs de saisie du pilote ont joué comme facteur dans de nombreux incidents et accidents d’aviation. Une HMI bien conçue peut contribuer à réduire considérablement ces risques d’erreur. Les lignes directrices suivantes pour la conception suivantes sont à appliquer :

  1. les données d’entrée et de sortie (résultats) devraient être clairement séparées; toute l’information nécessaire à une tâche donnée devrait être présentée collectivement ou être facilement accessible;
  2. toutes les données requises par les applications de calcul des performances et de M et C devraient être demandées ou affichées, y compris les bons termes (noms) exempts d’ambiguïté et les unités de mesure (kg ou lb); les unités de mesure devraient correspondre à celles qui servent au même type de données provenant d’autres sources dans le poste de pilotage;
  3. les abréviations et les appellations de zones de données utilisées dans l’interface utilisateur graphique devraient correspondre à celles qui figurent dans les manuels et sur les étiquettes dans le poste de pilotage;
  4. lorsque l’application calcule les données de préparation du vol (réglementaires, ajustées) ainsi que d’autres données (en vol ou non ajustées), l’équipage de conduite doit être informé de la nature des résultats;
  5. l’application doit clairement faire la distinction entre les données saisies par l’utilisateur et les valeurs par défaut ou celles qui sont importées d’autres systèmes de l’aéronef;
  6. la marque de queue de l’aéronef devrait être clairement affichée à l’intention de l’équipage de conduite lorsque des différences significatives existent entre les marques de queue; si les marques de queue sont associées à différentes sous-flottes, la sous-flotte sélectionnée doit être clairement affichée à l’intention de l’équipage de conduite;
  7. des règles de saisie devraient être définies de sorte qu’il soit difficile d’entrer les données dans des zones inacceptables de la HMI;
  8. la HMI devrait accepter des données ayant des paramètres compris dans l’enveloppe opérationnelle de l’aéronef approuvée par l’exploitant (généralement plus restrictive que le domaine de vol certifié); il conviendrait de prendre en compte la vraisemblance des résultats qui se situent à l’intérieur de l’enveloppe AFM, mais en dehors des conditions d’exploitation normales;
  9. toutes les hypothèses de calcul des TALP (p. ex., utilisation des inverseurs de poussée, poussée/puissance pleine ou réduite) devraient être clairement affichées; les hypothèses utilisées pour les calculs devraient être au moins aussi claires pour le pilote que ne le serait toute information semblable présentée sous forme tabulaire;
  10. la HMI devrait informer le pilote lorsque les données saisies donnent lieu à une opération irréalisable (par exemple, une marge d’arrêt négative);
  11. l’utilisateur devrait être capable de modifier facilement les données saisies, en particulier pour tenir compte des changements de dernière minute;
  12. les résultats de calcul devraient être affichés en même temps que les paramètres de saisie servant au calcul;
  13. toute restriction spéciale/MEL/LEC en vigueur devrait être clairement affichée et compréhensible;
  14. en cas de choix de pistes multiples, les résultats devraient être clairement associés à la piste sélectionnée; et,
  15. les changements apportés par le pilote aux données sur les pistes devraient être clairement affichés et faciles à reconnaître

1.4        Essais des applications de TALP et de la masse et du centrage

1.4.1       La précision de ces calculs est essentielle à la sécurité des opérations aériennes. Les applications OEPP peuvent constituer des instruments de calcul efficaces à cet égard. On devrait vérifier à fond les applications OEPP qui font intervenir des algorithmes mathématiques ou des modules de calcul avant de les approuver à des fins opérationnelles.

1.4.2       Les applications conçues pour les calculs de performance de décollage et d’atterrissage et de masse et centrage doivent exploiter les données de l’AFM ou d’une autre source appropriée selon ce que l’ANT juge acceptable.

1.4.3       On devrait mettre les applications à l’essai en les faisant fonctionner avec un système d’exploitation et un matériel représentatifs.

1.4.4       Une évaluation appropriée de l’application OEPP de TALP ou de M et C comprend des essais documentés qui vérifient la précision des calculs, l’interface utilisateur et l’intégration de l’environnement au complet. La portée des essais et de la documentation de soutien devrait refléter la complexité et la fonctionnalité de l’application mise à l’essai.

 1.4.5       Vérification de l’exactitude des calculs : essais conçus pour vérifier comment une application calcule des résultats TALP et M et C qui correspondent aux données de l’AFM ou aux données consultatives fournies par le constructeur de l’aéronef.

1.4.5.1     De nombreux paramètres de saisie influent sur les résultats des applications de calcul des TALP, d’où l’impossibilité de vérifier l’exactitude de tous les résultats possibles. Les cas d’essai devraient être définis de façon à bien englober le domaine d’opérations de l’aéronef au moyen d’un échantillon représentatif des conditions prévues pour les applications de calcul des TALP (p. ex., état de la piste, pente de la piste, vent, température, altitude-pression, franchissement d’obstacles et configuration d’aéronef, y compris les défaillances et leur incidence sur les performances, etc.).

 1.4.5.2     De nombreux paramètres de saisie influent également sur les résultats des applications de calcul de la M et C, d’où l’impossibilité là encore de vérifier l’exactitude de tous les résultats possibles. Les cas d’essai devraient être définis de façon à bien englober le domaine d’opérations de l’aéronef au complet au moyen d’un échantillon représentatif des conditions prévues pour les applications de calcul de la M et C (p. ex., tableaux de charge de carburant, y compris les différentes densités de carburant ou la densité de carburant réelle, si elle est connue, les tableaux de charge passagers, les tableaux de charge de fret et les charges de fret uniques ou spéciales).

1.4.5.3      Les cas d’essai devraient également être définis de façon à bien englober un échantillon représentatif des aéronefs d’un exploitant (p. ex., différents types, modèles, configurations et modifications d’aéronef).

1.4.5.4      Les cas d’essai devraient comprendre une vérification détaillée permettant de déterminer si l’application produit des résultats qui correspondent aux résultats découlant de méthodes précédemment approuvées par l’Autorité de navigabilité opérationnelle (ANO) ou qui sont constants par rapport à ces résultats.

1.4.5.5      Les demandeurs devraient fournir une explication des méthodes utilisées pour l’évaluation d’un nombre suffisant de points de contrôle en ce qui concerne la conception de leurs applications logicielles et des bases de données.

1.4.5.6      Les cas d’essai devraient démontrer que l’application est stable et produit des résultats constants chaque fois que les mêmes paramètres sont saisis pour un processus donné.

 1.4.5.7     Les essais doivent être acceptables à l’ANO.

1.4.6         Vérifications d’interface utilisateur. Il s’agit des essais conçus pour vérifier l’acceptabilité de l’interface utilisateur de l’application.

1.4.6.1      Les cas d’essai devraient être définis de manière à démontrer la conformité avec les exigences relatives à la HMI à la section 1.3.1.

1.4.6.2      Les cas d’essai devraient être définis de façon à démontrer que l’application donne une réponse de système raisonnable lorsque des valeurs erronées sont saisies par inadvertance.

1.4.6.3      Les cas d’essai devraient être définis de façon à démontrer que l’application fournit des résultats faciles à interpréter ou des messages/instructions d’erreur en cas de saisie de valeurs erronées (valeurs en dehors de l’enveloppe, mauvaise combinaison d’entrées, etc.).

 1.4.6.4     Les cas d’essai devraient être définis de façon à démontrer que la saisie de valeurs erronées n’entraîne pas la défaillance de l’application ni la place dans un état qui exigerait des compétences ou des procédures spéciales pour la remettre en état de fonctionner

1.4.7         Essais d’intégration opérationnelle. Essais qui démontrent que l’application OEPP fonctionne correctement dans l’environnement opérationnel où elle doit être utilisée.

1.4.7.1      Des essais de cas démontrant que l’application fonctionne correctement sur la plateforme OEPP devraient être définis.

1.4.7.2      Des essais de cas démontrant que l’application ne crée pas d’interférence avec les autres applications OEPP ou systèmes d’aéronef ou vice versa devraient être définis.

1.4.7.3      Des essais de cas démontrant que l’application interagit correctement avec les autres applications au besoin (p. ex., performance au décollage, à l’aide des résultats fournis par l’application de calcul de la masse et du centrage) devraient être définis.

1.5        Procédures, gestion et instruction

                 L’évaluation des applications OEPP qui calculent les données de TALP et de M et C devrait prendre en compte les autres processus et procédures et l’instruction aux fins de l’utilisation de l’application.

1.5.1        Procédures d’utilisation en situation normale

1.5.1.1     Les procédures devraient assurer l’utilisation conforme des applications OEPP qui calculent les données de TALP et de M et C. Les procédures devraient s’appliquer à l’équipage de conduite et au personnel au sol (régulateurs de vol, agents d’opérations de vol, personnel d’exploitation, etc.) qui peuvent avoir des rôles définis dans l’utilisation des applications.

1.5.1.2    Les données TALP et M et C devraient être calculées de façon indépendante et contrevérifiées par les deux pilotes. Lorsqu’un système de régulation, décrit à l’annexe 6, partie 1, chapitre 3 de l’OACI, est utilisé pour le contrôle et la supervision des vols, le régulateur de vol (ou les autres membres du personnel au sol touchés) devrait vérifier quels résultats se situent à l’intérieur des limites de fonctionnement. Tout écart devrait faire l’objet de discussions avant de permettre l’utilisation opérationnelle des résultats. Tous les documents relatifs à la M et C devraient être accessibles au régulateur ou à la personne au sol responsable du contrôle et de la supervision du vol avant le décollage.

1.5.2       Procédures d’utilisation en situation anormale

1.5.2.1    Les procédures devraient assurer le maintien d’un haut niveau de sécurité conforme aux hypothèses utilisées pour l’évaluation des risques de l’OEPP en cas de perte de fonctionnalité de celui‑ci (p. ex., la défaillance d’une seule application ou la panne d’un dispositif hébergeant l’application).

1.5.3       Procédures en matière de sécurité

1.5.3.1    L’application ainsi que les données doivent faire l’objet d’un contrôle de leur intégrité et être protégées contre toute manipulation non autorisée, p. ex., par la vérification des valeurs du total de contrôle au démarrage du système OEPP et avant chaque opération de calcul.

1.5.4        Instruction

1.5.4.1     L’instruction doit mettre l’accent sur l’importance d’exécuter tous les calculs des TALP et M et C en conformité avec les PUN de sorte qu’on puisse s’assurer que les calculs sont totalement indépendants. Par exemple, un pilote ne devrait pas annoncer les valeurs à saisir dans l’interface HMI des applications de calcul des performances, car en cas d’erreur, les deux calculs pourraient produire les mêmes résultats trompeurs.

1.5.4.2       L’instruction devrait porter notamment sur les contre-vérifications (avec les données d’avionique ou du plan de vol) et les méthodes de vérification des erreurs « aberrantes » (p. ex., par pur calcul empirique) qui peuvent être utilisées par les pilotes pour repérer les erreurs d’ordre de grandeur, comme la saisie de la masse sans carburant (ZFM) au lieu de la masse au décollage (TOM) ou la transposition de chiffres.

1.5.4.3       L’instruction devrait souligner que l’utilisation des OEPP vise à faciliter le calcul des TALP et de M et C et n’élimine pas la nécessité pour les pilotes d’avoir de bonnes connaissances en matière de rendement aéronautique.

 1.5.4.4      L’utilisation des OEPP peut donner lieu à l’introduction de nouvelles procédures (p. ex., l’utilisation de plusieurs valeurs de sortie des volets au décollage) ; les pilotes devraient alors recevoir une instruction en conséquence.

1.5.5         Gestion des applications OEPP de calcul et performance de décollage et d’atterrissage et de masse et centrage

1.5.5.1      Les responsabilités relevant de la gestion des TALP et de la M et C et de la gestion des OEPP devraient être claires et bien documentées. Une ou plusieurs personnes désignées ayant reçu une instruction suffisante devraient se charger d’assurer le soutien des outils associés aux performances. Cette personne ou ce groupe doit avoir une connaissance exhaustive des règlements en vigueur, des données de TALP et M et C et des logiciels de calcul des TALP et M et C (p. ex., modules SCAP) utilisés dans les systèmes OEPP.

2.        Applications de cartes électroniques

2.1        Description

2.1.1        Il s’agit d’une application logicielle OEPP qui permet l’affichage d’informations nécessaires à la navigation et à la planification et la surveillance des routes, ainsi que l’affichage de cartes d’aérodrome et de navigation à vue et aux instruments.

2.2        Considérations pour les applications de cartes électroniques 

  1. les cartes aéronautiques électroniques doivent offrir, au minimum, un niveau d’information et de convivialité comparable à celui des cartes sur papier;
  2. dans le cas des cartes d’approche, l’application logicielle OEPP devrait pouvoir afficher l’intégralité de la procédure d’approche aux instruments sur un même écran, en offrant un degré de lisibilité et de clarté équivalant à celui des cartes sur papier;
  3. l’écran OEPP peut ne pas permettre l’affichage de toute la carte (schéma d’aéroport, procédures de départ et d’arrivée, etc.) lorsque celle-ci représente l’agrandissement d’un plan détaillé;
  4. les fonctions panoramique, zoom, défilement et rotation sont permises;
  5. dans le cas des cartes fondées sur les données, on devrait s’assurer que les symboles et les légendes demeurent très lisibles (p. ex., absence de chevauchement). On peut utiliser des couches de données comme moyen de désencombrement.

Nota

Voir aussi l’annexe 4 — Cartes aéronautiques, chapitre 20 sur l’affichage de cartes aéronautiques électroniques — OACI.

3.        Système de caméra au roulage (TACS)

3.1        Description

3.1.1        Le système TACS est une application logicielle OEPP qui permet d’améliorer la connaissance de la situation pendant la circulation au sol grâce à l’affichage d’images électroniques en temps réel de l’extérieur de l’aéronef.

3.2        Considérations relatives au système de caméra d’aide au roulage (TACS)

  1. les images reçues doivent être affichées en direct, en temps réel, et sans décalage dans le temps apparent;
  2. la qualité d’image doit être appropriée dans toutes les conditions de lumière ambiante prévues;
  3. l’affichage des aides au virage des aéronefs peut être fourni (rayon de rotation, largeur de cadrage pour le train d’atterrissage, etc.).  Dans un tel cas, on devrait vérifier l’exactitude de l’information livrée au pilote;
  4. l’application peut être connectée à un ou plusieurs systèmes de vision installés; ces systèmes de vision comprennent les caméras à fréquences visibles, les capteurs infrarouges à vision frontale, et les intensificateurs d’images à basse lumière;
  5. les exploitants devraient établir des PUN sur l’utilisation des TACS; l’instruction devrait souligner que les TACS doivent être utilisés comme ressource complémentaire et non comme moyen principal de navigation au sol ou d’évitement d’obstacles;
  6. l’utilisation de TACS ne devrait pas causer de désorientation au pilote.

4.         Affichage de cartes aéroportuaire défilantes (AMMD)

4.1         Description

4.1.1         La présente section donne des renseignements sur la façon de démontrer le caractère sécuritaire des opérations faisant appel à des applications AMMD hébergées sur les OEPP.

4.1.2         Les applications OEPP AMMD avec symbole de position propre sont conçues pour aider les équipages de conduite à s’orienter à la surface de l’aéroport, et ainsi, permettre au pilote d’avoir une meilleure connaissance de la situation pendant la circulation au sol. La fonction AMMD de cette application est d’une utilisation limitée aux opérations au sol.

 4.1.3         L’application AMMD a pour fonction d’indiquer la position de l’aéronef et le cap (lorsque le symbole de position propre est directionnel) sur les cartes dynamiques. Ces cartes représentent, sous une forme graphique, les pistes, les voies de circulation, et les autres entités des aéroports aux fins de la circulation au sol et des opérations connexes. L’application peut aussi donner aux équipages des avertissements au sujet de conditions pouvant être dangereuses, comme l’entrée par inadvertance sur une piste.

4.2        Considérations relatives à l'AMMD

  1. les applications AMMD ne doivent pas être utilisées comme moyen principal de navigation au sol ; le recours aux procédures normales et l’observation visuelle directe par la fenêtre du poste de pilotage demeurent les principaux moyens de manœuvre au sol;
  2. l’erreur totale du système de bout en bout devrait être spécifiée et caractérisée par le concepteur du logiciel AMMD, le fournisseur OEPP, l’équipementier, etc.; la précision devrait suffire à garantir que le symbole de position propre de l’aéronef figure sur la bonne piste ou voie de circulation;
  3. l’application AMMD devrait offrir un moyen de compensation des erreurs d’orientation d’antenne liées à l’installation, p. ex., erreur longitudinale liée à la position d’une antenne GNSS par rapport au poste de pilotage;
  4. le système devrait supprimer automatiquement le symbole de position propre lorsque l’aéronef est en vol (p. ex., contact de train, contrôle de la vitesse) et que l’incertitude sur la position dépasse la valeur maximale définie;
  5. l’application AMMD devrait pouvoir détecter toute perte ou dégradation des fonctions AMMD attribuable à des anomalies : altération de la mémoire, gel du système, latence, etc.; elle devrait en informer l’équipage de conduite et complètement supprimer la représentation des données de position propre;
  6. la base de données AMMD devrait être conforme aux normes applicables à l’aviation (voir l’annexe 6, partie I, 7.4 sur la navigation et la gestion des données électroniques de l’OACI);
  7. l’exploitant devrait examiner les documents et les données fournis par le créateur du logiciel AMMD et s’assurer que les exigences relatives à son installation sur la plate-forme OEPP ont été respectées.

4.3         Instruction des équipages de conduite

4.3.1        L’exploitant devrait définir une instruction particulière à suivre par l’équipage de conduite aux fins de la mise en œuvre d’un AMMD. Celle-ci devrait être intégrée au programme d’instruction d’ensemble sur l’OEPP.

 4.3.2        Le manuel d’exploitation ou le guide d’utilisation doit fournir suffisamment d’information aux équipages de conduite, y compris sur les limites et la précision du système et de toutes les procédures connexes.

5.        Application de liste de vérification électronique

5.1        Description

5.1.1        Une liste de vérification électronique (ECL) est une application OEPP qui affiche les listes de vérification à l’équipage de conduite au moyen d’une OEPP.

5.1.2        Ces directives sont applicables aux éléments suivants :

  1. les ECL affichant des renseignements précomposés ou comportant une HMI particulière pour l’affichage des renseignements avec optimisation pour l’équipage de conduite;
  2. les ECL ayant ou non la capacité d’interagir avec le pilote pour enregistrer la réalisation des mesures et des listes de vérification;
  3. les ECL n’ayant pas la capacité de traiter les données de l’aéronef (p. ex., les ECL indépendantes) (la capacité de traitement des données de l’aéronef est plus importante et n’est pas abordée dans le présent avis);
  4. les ECL affichant seulement les listes de vérification en situation normale (les listes et procédures de vérification en situation non normale ou d’urgence sont plus essentielles et ne sont pas traitées dans le présent avis).

5.1.3       Les autres fonctions des ECL, comme celles qui sont énumérées ci-dessous, peuvent être présentes. Dans certains cas, il incombe à la DNAST d’établir la base de conformité applicable.

  1. si l’ECL reçoit des renseignements de l’aéronef (les données captées sur l’état de système d’aéronef, les positions de commutateur, etc.) : l’état de l’élément capté peut être reflété dans la liste de vérification; par exemple, si une mesure d’une liste de vérification indique qu’un bouton devrait être enfoncé et que les capteurs de l’aéronef captent l’enfoncement du bouton, l’affichage de la liste de vérification indiquera que la mesure a été accomplie;
  2. si le contenu de l’ECL comprend les listes de vérification et procédures en situation non normale (en situation anormale ou en cas d’urgence)

5.2         Conception de la HMI et paramètres liés aux facteurs humains

5.2.1        Le système ECL (matériel, logiciel) devrait assurer au moins le même niveau d’accessibilité, d’utilité, et de fiabilité qu’une liste de vérification sur support papier.

5.2.2        Considérations liées à la HMI et aux facteurs humains :

  1. le délai d’accès à la liste de vérification ne devrait pas être supérieur à celui d’une liste de vérification sur papier.
  2. toutes les listes de vérification devraient être facilement accessibles aux fins de consultation ou d’examen.
  3. les mesures prises par un pilote indiquées par une ECL devraient être identiques à celles qu’indique une liste de vérification en format papier.
  4. le pilote devrait clairement reconnaître les éléments des listes de vérification qui sont pertinents pour le fonctionnement de l’aéronef sur le plan de la sécurité, et ceux qui sont à caractère supplémentaire.
  5. les listes de vérification devraient être présentées conformément à la séquence normale de vol.
  6. le titre de la liste de vérification devrait toujours être affiché de manière distincte durant l’utilisation de la liste.
  7. l’existence d’un contenu masqué de liste de vérification devrait être indiquée.
  8. la fin de chaque liste de vérification devrait être clairement indiquée.
  9. l’effet du passage d’une ECL à d’autres applications OEPP sur le même matériel devrait être évalué.

5.2.3       Paramètres supplémentaires liés à la HMI et aux facteurs humains pour les ECL ayant la capacité d’interagir avec le pilote pour enregistrer la réalisation des mesures et des listes de vérification :

  1. l’ECL devrait fournir un aperçu de la liste de vérification affichant celles qui sont achevées et celles qui ne le sont pas;
  2. l’ECL devrait afficher l’état de réalisation des éléments d’une liste de vérification;
  3. au besoin, il devrait être possible de recommencer une liste de vérification; l’équipage devrait pouvoir réinitialiser la liste de vérification avec une étape de vérification pour confirmer la réinitialisation;
  4. au besoin, il devrait être possible de décocher un élément dans une liste de vérification.

5.4        Procédures à suivre par l’équipage de conduite

5.4.1        L’exploitant devrait prendre en compte l’effet sur la charge de travail des pilotes lorsqu’il détermine la méthode d’utilisation de l’ECL.

 5.4.2       Les procédures d’équipage de conduite devraient être établies pour ce qui suit :

  1. veiller à ce que l’équipage de conduite vérifie la validité de la base de données de l’ECL avant son utilisation;
  2. définir la procédure de secours en cas de perte de l’ECL durant le vol de manière à assurer l’accès aux listes de vérification en tout temps (p. ex., inclure des scénarios sur les pannes d’alimentation, les mauvais fonctionnements de logiciels, etc.).

5.5        Administration

5.5.1        L’exploitant devrait également établir un processus uniforme et méthodique pour la modification des données de l’ECL et la transmission et la mise en œuvre de données mises à jour dans les OEPP. Ces processus devraient comprendre une méthode de vérification de l’applicabilité de la base de données par rapport aux divers aéronefs de la flotte de l’exploitant.

 5.5.2        Les données d’ECL générées automatiquement devraient :

  1. être concises, simples, claires, et sans ambiguïté;
  2. assurer une uniformité entre les données fournies par le constructeur d’aéronef et celles que personnalise l’exploitant (p. ex., langue, terminologie, abréviations).

5.6        Instruction de l’équipage de conduite et documentation

5.6.1       L’exploitant devrait définir une formation spécifique à suivre par l’équipage de conduite en soutien à la mise en œuvre d’une ECL. Celle-ci devrait être intégrée dans le programme d’instruction d’ensemble sur l’OEPP. Le manuel d’utilisation ou le guide de l’utilisateur devrait fournir des renseignements suffisants aux équipages de conduite, notamment sur les limites du système et toutes les procédures connexes.

6.0      Application météorologique en vol (IFW)

6.1.       Définition

6.1.1       Dans le contexte du présent avis, la station météorologique en vol est une fonction OEPP qui permet à l’équipage de conduite d’avoir accès à des données météorologiques.

6.2.       Utilisation prévue et limitations

6.2.1         L’ajout de la fonction IFW est complémentaire par rapport aux renseignements exigés en vertu de l’annexe 3 de l’OACI et ne les remplace pas. Cette fonction devrait permettre une amélioration de la connaissance de la situation et aider l’équipage de conduite à prendre des décisions stratégiques.

6.2.2         L’application IFW pourrait être utilisée pour accéder aux renseignements exigés à bord (p. ex., les données du centre mondial de prévisions de zone [CMPZ]), ainsi que les renseignements météorologiques supplémentaires.

6.2.3         L’utilisation des IFW ne devrait ni être critique pour la sécurité ni nécessaire pour l’exécution du vol.

6.2.4         Pour ne pas être critique pour la sécurité, l’IFW ne devrait pas servir à appuyer les décisions tactiques ni remplacer les systèmes d’aéronef certifiés (p. ex., le radar météorologique).

6.2.5         Les renseignements provenant de la documentation de vol officielle ou des systèmes d’aéronef principaux devraient toujours avoir préséance en cas de contradiction avec les renseignements IFW.

 6.2.6        Les renseignements météorologiques dans les applications IFW peuvent être superposés sur une carte aéronautique ou une carte géographique, ou ils peuvent être représentés de manière indépendante (p. ex., tracés radar, images satellitaires, etc.)

6.3.       Considérations relatives aux renseignements météorologiques

6.3.1        Les renseignements météorologiques peuvent être prévus ou observés, et ils peuvent être mis à jour au sol ou en vol. Ils devraient être fondés sur les données de fournisseurs de services météorologiques certifiés ou d’autres sources fiables évaluées par l’exploitant.

 6.3.2       Les renseignements météorologiques fournis à l’équipage de conduite devraient être aussi uniformes que possible par rapport à ceux qui sont fournis aux utilisateurs de renseignements météorologiques d’aviation basés au sol (p. ex., centre des opérations d’une compagnie aérienne, régulateur, etc.), afin d’établir une connaissance de la situation commune et de faciliter un processus décisionnel collaboratif.

6.4.       Considérations en matière d’affichage

6.4.1       Les renseignements météorologiques devraient être présentés à l’équipage de conduite selon un format qui convient au contenu des renseignements; une représentation graphique est à préférer autant que possible.

6.4.2       La présentation devrait comprendre ce qui suit :

  1. le type de renseignements figurant dans les renseignements météorologiques (observation ou prévision);
  2. l’actualité ou l’âge et la période de validité des renseignements météorologiques;
  3. les renseignements nécessaires pour l’interprétation des renseignements météorologiques (p. ex., légende);
  4. des indications positives et claires sur les renseignements ou données manquants, de sorte que l’équipage de conduite puisse déterminer les régions contenant de l’incertitude lorsqu’il prend des décisions sur l’évitement des conditions météorologiques dangereuses

6.4.3        Si les renseignements météorologiques sont superposés sur des cartes aéronautiques, une attention particulière devrait être accordée aux questions liées à la HMI afin d’empêcher les effets négatifs sur les fonctions de carte de base.

6.4.4        Les renseignements météorologiques peuvent nécessiter un reformatage pour être utilisés dans le poste de pilotage en fonction de la taille de l’affichage ou de la technologie de représentation. Toutefois, tout reformatage des renseignements météorologiques devrait préserver la géolocalisation et l’intensité des conditions météorologiques, peu importe la projection, la mise à l’échelle ou tout autre type de traitement.

6.4.5         L’affichage d’IFW devrait respecter autant que possible la philosophie de conception du poste de pilotage relativement à l’emplacement des titres, la disposition et la représentation visuelle des légendes, la taille des éléments, le marquage et les styles textuels, etc.

 6.4.6         Il est recommandé que lIFW puisse afficher les renseignements météorologiques liés à la route ou au plan de vol opérationnel afin de faciliter l’interprétation des renseignements prévus

6.5.       Instruction et procédures

6.5.1        L’exploitant doit préciser des procédures d’utilisation normalisées (PUN) précisant l’utilisation des renseignements d’IFW.

 6.5.2    Une instruction appropriée devrait être assurée pour l’utilisation des IFW. Elle devrait traiter des éléments suivants :

  1. les limitations des IFW, notamment présentées à la section 6.2.;
  2. la latence des renseignements météorologiques observés et les dangers liés à l’utilisation de vieux renseignements.
  3. les renseignements d’IFW qui vont au-delà des exigences de l’annexe 3 de l’OACI et qui complètent les renseignements exigés;
  4. l’utilisation de l’application;
  5. les différents types de renseignements affichés (prévision ou observation);
  6. la symbologie (p. ex., symboles, couleur).
  7. l’interprétation des renseignements météorologiques;
  8. la détermination des échecs (p. ex., liaisons montantes inachevées, pannes de liaison de données, renseignements manquants);
  9. l’évitement de la fixation;
  10. la gestion de la charge de travail.

Haut de la page

Retour à l'Avis de l'ANT 2012-01