Législation communautaire en vigueur Document 300R2082 Chapitres du répertoire où le document peut être trouvé: [ 07.40.30 - Sécurité aérienne ] [ 07.40.20.20 - Répartition du trafic ] Actes modifiés: 397L0015 (Modification) 300R2082 Règlement (CE) nº 2082/2000 de la Commission du 6 septembre 2000 portant adoption de normes Eurocontrol et modification de la directive 97/15/CE portant adoption de normes Eurocontrol et modification de la directive 93/65/CEE Journal officiel n° L 254 du 09/10/2000 p. 0001 - 0234 Texte: Règlement (CE) no 2082/2000 de la Commission du 6 septembre 2000 portant adoption de normes Eurocontrol et modification de la directive 97/15/CE portant adoption de normes Eurocontrol et modification de la directive 93/65/CEE LA COMMISSION DES COMMUNAUTÉS EUROPÉENNES, vu le traité instituant la Communauté européenne, vu la directive 93/65/CEE du Conseil, du 19 juillet 1993, relative à la définition et à l'utilisation de spécifications techniques compatibles pour l'acquisition d'équipements et de systèmes pour la gestion du trafic aérien(1), et en particulier son article 3, vu la directive 97/15/CE de la Commission du 25 mars 1997 portant adoption de normes Eurocontrol et modification de la directive 93/65/CEE du Conseil relative à la définition et à l'utilisation de spécifications techniques compatibles pour l'acquisition d'équipements et de systèmes pour gestion du trafic aérien(2), considérant ce qui suit: (1) La directive 97/15/CE a adopté la norme Eurocontrol relative à l'échange de données en ligne (OLDI), édition 1.0, et la norme Eurocontrol relative à la présentation de l'échange de données ATS (ADEXP), édition 1.0. (2) Eurocontrol a adopté des versions plus récentes des deux normes susmentionnées, à savoir l'édition 2.2 de la norme OLDI et l'édition 2.0 de la norme ADEXP, ainsi qu'une nouvelle norme Eurocontrol intitulée "Document de contrôle d'interface pour l'échange de données de vol" (FDE-ICD). (3) Ces normes Eurocontrol relèvent du champ d'application de la directive 93/65/CEE et contribuent à l'harmonisation des systèmes nationaux de gestion du trafic aérien des États membres, notamment en ce qui concerne le transfert des vols entre centres de contrôle de la circulation aérienne (OLDI), la gestion des courants de trafic aérien (ADEXP) et les communications entre les systèmes nationaux (FDE-ICD). (4) L'édition 2.2 de la norme OLDI et l'édition 2.0 de la norme ADEXP remplacent et annulent les précédentes éditions en vigueur actuellement, conformément aux dispositions de l'article 1er de la directive 97/15/CE, ledit article devant dès lors être abrogé. (5) Les dispositions du présent règlement sont conformes à l'avis du comité institué conformément à la directive 93/65/CEE, A ARRÊTÉ LE PRÉSENT RÈGLEMENT: Article premier Les éléments obligatoires des spécifications Eurocontrol visées dans les documents de normes Eurocontrol suivants sont adoptés dans le cadre de la directive 93/65/CEE dans la mesure où ils sont nécessaires pour la mise en oeuvre d'un système européen intégré pour la gestion du trafic aérien: - la norme Eurocontrol relative à l'échange de données en ligne (OLDI), édition 2.2 (document de référence Eurocontrol DPS.ET1.ST06-STD), dont le texte figure à l'annexe I du présent règlement, - la norme Eurocontrol relative à la présentation de l'échange de données ATS (ADEXP), édition 2.0 (document de référence Eurocontrol DPS.ET1.ST09-STD), dont le texte figure à l'annexe II du présent règlement, - la norme Eurocontrol intitulée "Document de contrôle d'interface pour l'échange de données de vol" (FDE-ICD), édition 1.0 (document de référence Eurocontrol COM.ET1.ST12-STD), dont le texte figure à l'annexe III du présent règlement. Article 2 L'article 1er de la directive 97/15/CE est abrogé. Article 3 Le présent règlement entre en vigueur le troisième jour suivant celui de sa publication au Journal officiel des Communautés européennes. Le présent règlement est obligatoire dans tous ces éléments et directement applicable dans tout État membre. Fait à Bruxelles, le 6 septembre 2000. Par la Commission Loyola De Palacio Vice-Président (1) JO L 187 du 29.7.1993, p. 52. (2) JO L 95 du 10.4.1997, p. 16. ANNEXE I ÉCHANGE DE DONNÉES EN LIGNE (OLDI), ÉDITION 2.2 (document de référence Eurocontrol DPS.ET1.ST06-STD) TABLE DES MATIÈRES >EMPLACEMENT TABLE> AVERTISSEMENT/DROITS D'AUTEUR Le présent document a été élaboré par l'Agence Eurocontrol, qui en détient les droits d'auteur. Le contenu du présent document est librement accessible, en tout ou en partie, aux représentants des États membres, toute reproduction ou divulgation à des tiers toutefois subordonnée à une autorisation préalable de l'Agence Eurocontrol AVANT-PROPOS 1. Organe compétent La norme Eurocontrol pour l'échange de données en ligne (OLDI), Édition 2.2, a été établie par la Direction Développement (DED) du Programme européen d'harmonisation et d'intégration du contrôle de la circulation aérienne (EATCHIP) à Eurocontrol, qui en assure également l'actualisation. Toutes observations ou questions doivent être adressées au Directeur Général d'Eurocontrol, à l'attention de la Division DED-2, Rue de la Fusée, 96, B-1130 Bruxelles. 2. Lien avec le Programme de travail EATCHIP La présente Norme est un produit résultant de la tâche spécialisée DPS.ET1.ST06 du Domaine Traitement de données de l'ATM (DPS), qui est définie dans le Programme de travail EATCHIP (EWPD), Édition 2.0, en date du 30.09.94. 3. Approbation et amendements La présente Norme a été soumise à la procédure d'approbation ci-après, telle qu'elle est définie dans les Directives pour la Normalisation d'Eurocontrol: - approbation par le Groupe "Besoins opérationnels et traitement des données ATM" (ODT), par correspondance; - consultation de tous les États de la CEAC par l'intermédiaire de leurs représentants auprès du Comité de gestion ou du Comité directeur d'EATCHIP; - approbation par le Comité directeur d'EATCHIP et le Comité de gestion; - adoption par la Commission permanente. Les dispositions de la présente Norme prennent effet dès leur adoption par la Commission permanente. Afin de suivre l'évolution des procédures de contrôle de la circulation aérienne (ATC), des amendements et additifs pourront être proposés par l'intermédiaire de l'ODT, pour examen et approbation éventuelle. Les prescriptions seront ensuite intégrées soit dans un amendement, soit dans une nouvelle édition du document, à soumettre pour approbation et adoption suivant les procédures applicables. 4. Dispositions typographiques Afin de mettre en relief le caractère de chaque spécification, il a été décidé d'adopter les dispositions typographiques suivantes: les Éléments normatifs sont imprimés en lettres droites ordinaires; les Éléments recommandés sont imprimés en italiques non grasses, le statut étant indiqué par le préfixe Recommandation. Pour la rédaction des spécifications, il a été décidé d'adopter les dispositions suivantes: dans le cas des Éléments normatifs, on utilise la formule "doit" ("shall" en anglais), dans le cas des Éléments recommandés, on utilise la formule "il convient de" ("should" en anglais). Les notes sont imprimées en italiques ordinaires, précédées du préfixe "NOTE". 5. Lien avec l'Édition 1 de la Norme Eurocontrol pour l'échange de données en ligne Le présent document remplace les Parties 1 et 2 de l'Édition 1 de la Norme Eurocontrol pour l'échange de données en ligne. La Partie 3, qui décrit les protocoles techniques applicables est remplacée par la Norme Eurocontrol relative à l'échange des données de vol - Document de contrôle d'interface - Partie 1. 6. Modifications majeures par rapport à l'Édition 1 Les principaux changements et compléments apportés sont les suivants: 1. Intégration, dans la procédure de base, des messages complémentaires (non obligatoires) suivants: - Message d'abrogation de coordination (MAC); - Message d'assignation de code (COD) pour radar secondaire de surveillance (SSR) - Message d'information (INF). 2. Définition du contenu et du format du message à envoyer lorsqu'un vol franchit une limite sur une route qui n'est pas une route ATS définie mais qui est délimitée par le début et la fin du tronçon de route. 3. Intégration d'une procédure de dialogue permettant: - aux contrôleurs chargés de la planification d'identifier et de négocier des conditions de transfert non classiques; - à l'organisme acceptant de soumettre une contre-proposition sur les conditions de transfert; - la mise à disposition de moyens de transfert de communication dans le cadre de la procédure de transfert de contrôle. 4. Mise en service du format décrit dans l'Édition 2 de la Norme Eurocontrol de présentation de l'échange de données ATS (ADEXP). Tous les messages classés dans la procédure de base de même que ceux utilisés pendant la phase de coordination de la procédure de dialogue sont présentés à la fois selon le format de l'Organisation de l'aviation civile internationale (OACI) et suivant le format ADEXP. Les messages de transfert de communication entrant dans le cadre de la procédure de dialogue sont présentés à l'aide du seul format ADEXP. 5. Suppression des Annexes suivantes de l'Édition 1: A: Identification des organismes ATC B: Structure des messages OLDI (tous les messages de l'Édition 2.2 sont illustrés par des exemples) D: Rappel historique E: Plan de mise en oeuvre F: Degré de conformité respecté par les États G: Directives pour la mise en oeuvre H: Directives pour l'évaluation des liaisons. 6. Séparation de la Partie 3 - Exigences techniques - des spécifications se rapportant aux applications. 7. Lien avec d'autres documents Le présent document fait référence à deux types de format de champ à employer pour établir les messages, les formats OACI et ADEXP. Les formats de champ OACI sont décrits dans le Document cité en Référence 1 - Règles de l'air et Services de la circulation aérienne. Dans le cas où cette Référence 1 serait remplacée par un autre, la définition des catégories de champ OACI doit être telle que donnée dans le nouveau document. Les formats de champ ADEXP sont décrits dans le Document cité en Référence 2. NOTE La liste des Documents référencés est à la Section 2. 8. Langue La version originale du présent document a été établie en langue anglaise. 1. INTRODUCTION 1.1. Objectif 1.1.1. Les vols qui bénéficient du service ATC sont transférés d'un organisme ATC au suivant dans des conditions visant à garantir une sécurité totale. À cette fin, il est de règle que les deux organismes coordonnent entre eux, au préalable, le passage de chaque vol à la limite de leurs zones de responsabilité respectives et que le contrôle du vol soit transféré au moment où l'aéronef franchit ou s'apprête à franchir la limite en question. 1.1.2. Lorsqu'elle se déroule par téléphone, la transmission des données propres à chaque vol, dans le cadre du processus de coordination, constitue une tâche d'appui importante pour les organismes ATC, notamment pour les centres de contrôle régional (CCR). C'est dans le but de remplacer ces "estimations" verbales qu'a été lancée en Europe, au début des années quatre-vingt, l'exploitation opérationnelle de liaisons entre systèmes de traitement des données de vol (FDPS) dans les CCR, baptisée Echange de données en ligne (OLDI). 1.1.3. Afin d'en faciliter la mise en oeuvre, des règles et des formats de message communs ont été établis et adoptés par les organismes intéressés et inclus dans l'Édition 1 de la Norme Eurocontrol pour l'échange de données en ligne; la présente Édition 2.2 vise à prendre en compte l'évolution continue de ce dispositif conformément aux dispositions applicables du Programme EATCHIP. 1.2. Domaine d'application 1.2.1. Le présent document décrit le dispositif et les messages à mettre en oeuvre entre FDPS des organismes ATC dans le but d'assurer: - la coordination nécessaire préalablement au transfert des vols d'un organisme à un autre; - le transfert de communications des vols en question. 1.2.2. Il comprend: - une définition des formats de message et des règles pour leur contenu; - un descriptif du dispositif dont ces organismes doivent être pourvus et qui constitue un préalable indispensable à l'échange des données. 1.2.3. La présente Norme est applicable, entre les États membres d'Eurocontrol, au dispositif international OLDI reliant les organismes qui assurent un service de contrôle régional de la circulation aérienne. 1.2.4. Recommandation Il convient que les États membres de la Conférence européenne de l'Aviation civile (CEAC) appliquent la présente Norme: - au dispositif international OLDI reliant les organismes qui assurent un service ATC régional dans la zone de la CEAC; - au dispositif OLDI entre organismes assurant un service ATC régional au niveau national. 2. RÉFÉRENCES 2.1. Les documents et normes ci-après contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des dispositions de la présente Norme Eurocontrol. Les éditions indiquées sont celles qui étaient en vigueur au moment de la publication de la présente Norme Eurocontrol. Toute révision des documents de l'OACI cités en référence doit être immédiatement répercutée dans la présente Norme Eurocontrol. Les révisions des autres documents cités en référence ne peuvent pas faire partie des dispositions de la présente Norme Eurocontrol tant qu'elles n'ont pas été officiellement examinées et incluses dans le présent document normatif. En cas de conflit entre les prescriptions de la présente Norme et le contenu de ces autres documents de référence, c'est la présente Norme Eurocontrol qui prévaut. 2.2. Les documents suivants sont référencés dans le présent Document de Norme: 1. Procédures pour les Services de la Navigation Aérienne - Règles de l'Air et Services de la Circulation Aérienne, Document OACI 4444, 13ième Édition en date du 7 Novembre 1996, telle qu'amendée. 2. Édition 2.0 du Document de Norme Eurocontrol pour la Présentation des Échanges de Données ATS (ADEXP), référence DPS-ET1-ST09-STD-01-00, en date du June 1998. 3. DÉFINITIONS, SYMBOLES ET ABRÉVIATIONS 3.1. Définitions Aux fins de la présente Norme Eurocontrol, les définitions suivantes doivent s'appliquer: 3.1.1. Organisme acceptant: Organisme assurant un service ATC qui va prendre ou a pris en charge un vol lorsque le transfert d'un organisme au suivant va avoir ou a eu lieu. 3.1.2. Accusé de réception: Avis indiquant qu'un message a été reçu et qu'il peut être traité correctement. 3.1.3. Activation: Processus par lequel un organisme ATC recevant actualise le plan de vol de l'aéronef de référence en y incluant les données communiquées par l'organisme transférant dans le cadre de la coordination entre les deux organismes, et qui aboutit à la fourniture de données aux contrôleurs. 3.1.4. Altitude: Distance verticale entre un niveau, un point ou un objet assimilé à un point, et le niveau moyen de la mer. 3.1.5. Application: Partie d'un sous-système ATS conforme à la présente Norme qui est relié à des entités comparables dans d'autres systèmes ATS. 3.1.6. Zone de responsabilité: Espace aérien de dimensions définies dans lequel un organisme ATC fournit des services de circulation aérienne. 3.1.7. Association: Procédure par laquelle un système établit le lien entre un message OLDI reçu et un plan de vol introduit dans la base de données. 3.1.8. Organisme ATC: Organisme fournissant un service de contrôle de la circulation aérienne. 3.1.9. Disponibilité: Probabilité d'accessibilité d'une installation par un utilisateur à un moment donné. 3.1.10. Limite: Plans (latéral et vertical) délimitant la zone de responsabilité d'un organisme ATC. 3.1.11. Niveau de vol autorisé: Niveau auquel ou jusqu'auquel l'ATC a autorisé un aéronef à voler. 3.1.12. Coordination ATC: Processus par lequel des organismes ATC, dont les zones de responsabilité sont adjacentes, s'informent officiellement du passage prévu de vols à la limite de leur zone de responsabilité, afin de garantir la sécurité des vols par la cohérence des actions prévues. 3.1.13. Message de coordination: Terme générique désignant un message utilisé pour accomplir une coordination ATC. On y inclut le message CDN, message spécifique défini à l'alinéa 8.8. 3.1.14. Phase de coordination: Pour un vol donné, phase au cours de laquelle les organismes ATC transférant et recevant se mettent d'accord sur les conditions (niveau de vol, point de franchissement de limite, etc.) dans lesquelles le contrôle de l'aéronef sera transféré d'un organisme à l'autre. 3.1.15. Point de coordination: Point connu des organismes ATC dans une séquence de coordination, situé à la limite ou à proximité de la limite entre les organismes ATC et mentionné dans les messages de coordination. 3.1.16. Corrélation: Processus, fondé sur des critères définis, consistant à relier les données du plan de vol et la piste radar du même vol, normalement pour présentation sur l'écran du contrôleur. 3.1.17. Norme Eurocontrol: Toute spécification applicable aux caractéristiques physiques, à la configuration, au matériel, aux performances, au personnel ou aux procédures, dont l'application uniforme a été jugée essentielle à la mise en oeuvre de systèmes ATS dans les Etats membres d'Eurocontrol. Une Norme Eurocontrol ne doit pas être incompatible avec les normes de l'OACI, mais les compléter, le cas échéant. 3.1.18. Contrôleur exécutif: Contrôleur donnant des instructions directes aux vols dont il a la charge. Les contrôleurs assurant le service de contrôle radar régional entrent dans cette catégorie. 3.1.19. Niveau de sortie: Niveau auquel un vol a été autorisé, par voie de coordination, à franchir un point de transfert de contrôle. Un niveau de sortie peut être complété par des conditions de franchissement supplémentaires, qui définissent la fourchette d'altitudes à l'intérieur de laquelle se dérouleront la montée ou la descente. 3.1.20. Plan de vol: Ensemble de renseignements spécifiés au sujet d'un vol ou d'une partie de vol projeté, transmis aux organes des services de la circulation aérienne, ainsi que les renseignements, tirés du plan de vol d'un aéronef donné, que détient un FDPS. 3.1.21. Génération: Processus par lequel un système ATC extrait les informations utiles de la (des) bases(s) de données et crée un message pour transmission à un organisme ATC recevant. 3.1.22. Format OACI: Format utilisé pour la transmission sol-sol des messages ATS et qui utilise les types de champs et séparateurs décrits en Référence 1. 3.1.23. Niveau: Terme générique employé pour indiquer la position verticale d'un aéronef en vol; dans la présente Norme, niveau ou niveau de vol désigne également, l'altitude dans ceux des cas où elle est utilisée. 3.1.24. Notification: Processus par lequel l'organisme transférant transmet des données d'actualisation au système de l'organisme recevant en vue de la phase de coordination. 3.1.25. Organisme recevant: Organisme ATC auquel un message est envoyé. 3.1.26. Fiabilité: Période de disponibilité programmée pendant laquelle le service est exploitable. 3.1.27. Niveau de vol demandé: Niveau de vol demandé par l'aéronef dans le plan de vol. 3.1.28. Révision: Modification des données transmises précédemment par l'organisme ATC transférant à l'organisme ATC recevant. 3.1.29. Niveau de franchissement complémentaire: Niveau auquel ou au-dessus duquel, ou auquel ou au-dessous duquel un vol a été coordonné pour franchir le point de transfert de contrôle. Le niveau complémentaire, lorsqu'il existe, est un élément du niveau de sortie. 3.1.30. Plan de vol Système: Informations tirées du plan de vol d'un aéronef donné contenues dans un FDPS. 3.1.31. Temps de transaction: Intervalle de temps suivant le déclenchement d'un message, pendant lequel s'effectuent la transmission, le traitement initial dans le système recevant, la production et la transmission d'un message d'accusé de réception, ainsi que son identification dans le système transférant. 3.1.32. Point de transfert de contrôle: Point défini, situé le long de la trajectoire de vol d'un aéronef, où la responsabilité d'assurer les services de la circulation aérienne à cet aéronef est transférée d'un organisme ou d'un poste de contrôle à l'organisme ou au poste de contrôle suivant. Il ne coïncide pas nécessairement avec le point de coordination. 3.1.33. Phase de transfert: Phase du vol qui suit la phase de coordination, au cours de laquelle le transfert de communication est effectué. 3.1.34. Organisme transférant: Dans une séquence de coordination, organisme ATC chargé de fournir un service à un aéronef avant que la limite ne soit franchie et qui engage la phase de coordination avec l'organisme suivant. 3.1.35. Émettre/transmettre: Communiquer un message d'un système à un autre. 3.1.36. Unit: Organisme ATS. 3.1.37. Avertissement: Message qui s'affiche à un poste de travail en cas d'échec du processus automatisé de coordination. 3.2. Symboles et abréviations Aux fins de la présente Norme Eurocontrol, les symboles et abréviations ci-après doivent s'entendre comme suit: ABI Message de préavis de franchissement de limite ACP Message d'acceptation ACT Message d'activation ADEXP Présentation de l'échange de données ATS ATC Contrôle de la circulation aérienne ATM Gestion de la circulation aérienne ATS Service de la circulation aérienne CCR Centre de contrôle régional CDN Message de coordination CEAC Conférence européenne de l'aviation civile CNL Annulation de plan de vol COD Message d'assignation de code SSR COF Message de changement de fréquence COP Point de coordination DED Direction "Développement d'EATCHIP" à Eurocontrol EATCHIP Programme européen d'harmonisation et d'intégration du contrôle de la circulation aérienne ETO Heure estimée de survol (d'un point) ETOT Heure estimée de décollage EWPD Document "Programme de travail EATCHIP" FDPS Système de traitement des données de vol FRF Suite de la route du vol HMI Interface homme/machine HOP Message de proposition de transfert INF Message d'information LAM Message d'accusé de réception logique LoA Lettre d'accord MAC Message d'abrogation de la coordination MAS Prise en charge manuelle des communications NM Milles nautiques OACI Organisation de l'aviation civile internationale OLDI Échange de données en ligne ORCAM Méthode d'assignation des codes en fonction de la région d'origine PAC Message d'activation préliminaire RAP Message de proposition d'activation soumise pour accord REV Message de révision RJC Message de rejet de coordination ROF Message de demande de changement de fréquence RRV Message de révision soumis pour accord SBY Message d'attente de transfert SDM Message de données supplémentaires SSR Radar secondaire de surveillance SYSCO Coordination automatisée TI Déclenchement du transfert TIM Message de déclenchement du transfert TWR/APP Contrôle d'aérodrome et contrôle d'approche 4. CARACTÉRISTIQUES GÉNÉRALES 4.1. Introduction La présente section décrit les caractéristiques opérationnelles générales nécessaires à la mise en oeuvre d'un dispositif OLDI entre organismes ATC ainsi que les règles de classification et les caractéristiques de fonctionnement des divers types de message utilisés. 4.2. Caractéristiques requises du système de traitement des données de vol 4.2.1. Base de données de vol Les organismes qui ont recours aux moyens décrits dans le présent document doivent recevoir des données d'un FDPS contenant toutes les informations requises pour l'affichage, le traitement et la compilation des messages spécifiés. La principale source d'information sur chaque vol est le plan de vol déposé par le pilote ou en son nom. D'autres éléments d'information sont obtenus grâce au traitement des plans de vol en fonction de l'environnement de l'organisme concerné. 4.2.2. Fonctionnement en temps réel La procédure OLDI inclut les événements au sein de l'organisme ATC transférant qui déclencheront les fonctions nécessaires à la transmission, en temps voulu, des données de coordination au contrôleur transférant ainsi qu'à la transmission des données de coordination à l'organisme acceptant. À cette fin, le FDPS doit être en mesure de déclencher les fonctions en comparant le Temps universel coordonné et les paramètres de temps applicables, avec mention de l'heure de survol de points précis sur la route, selon les calculs effectués à partir de la base de données de vol. 4.2.3. Moyens de communication de données 4.2.3.1. Le FDPS doit être en mesure de recevoir et de transmettre des données de vol dans le format applicable au message, tel qu'il est indiqué dans le présent document, en utilisant un moyen de communication de données qui supportent la fonction OLDI. 4.2.3.2. Recommandation Il convient que le FDPS ait une capacité d'évolution suffisante pour permettre l'adjonction de nouveaux messages susceptibles de figurer dans des versions ultérieures de la présente norme. 4.2.3.3. Compte tenu des caractéristiques de fonctionnement spécifiées dans le présent document, le système de communication de données doit fournir un moyen rapide et fiable d'échange de données entre applications: - qui garantisse l'intégrité de la transmission des messages OLDI; et - qui suive les liaisons point à point ou l'état du réseau de communications, selon le cas. 4.2.3.4. Le FDPS doit envoyer un avertissement aux postes de travail lorsque des anomalies sont détectées par le système de communication de données. 4.2.4. Fonctions d'application 4.2.4.1. Les systèmes auxquels le dispositif OLDI fait appel doivent être en mesure d'assurer, de manière automatique, les opérations de réception, de stockage, de traitement, d'extraction ainsi que de livraison pour affichage, et de transmettre les données OLDI en temps réel. 4.2.4.2. Le FDPS doit: - contenir les données opérationnelles courantes correspondant à la fonction OLDI, ainsi que le prévoit la présente Norme, ces données étant mises à jour soit automatiquement, soit manuellement ou encore par ces deux moyens combinés; - être en mesure d'extraire ces éléments d'information de la base de données des plans de vol; - identifier l'organisme ATC suivant sur la route suivie par le vol. 4.2.4.3. Les points ci-après doivent faire l'objet d'accords bilatéraux: - points de coordination (COP); - points de référence utilisés pour indiquer le relèvement ou la distance servant à identifier les COP sur des segments hors route ATS, le cas échéant. NOTE Les COP peuvent ne pas coïncider toujours avec les points de transfert de contrôle. 4.2.5. Interface homme-machine (HMI) 4.2.5.1. L'HMI doit permettre: - d'afficher le contenu opérationnel des messages OLDI ainsi que les avertissements correspondant aux messages reçus, afin qu'ils soient pris en compte immédiatement; - d'acheminer les messages avertissant de la coordination et du transfert aux postes opérationnels responsables de la coordination des vols en question. 4.2.5.2. Le personnel ATC doit disposer des moyens nécessaires pour modifier les données dont le contenu opérationnel des messages est extraite, ainsi que le prévoit le présent document. 4.2.5.3. L'HMI doit indiquer que la transmission du message est en cours ou a été correctement accomplie, selon le cas. 4.2.5.4. Un avertissement ou avis au(x) poste(s) ATC ou technique(s) compétent(s) doit être produit automatiquement si aucun accusé de réception n'est reçu dans le délai fixé après la transmission d'un message de coordination ou de transfert. 4.2.5.5. La forme de cet avertissement ou avis doit permettre d'attirer immédiatement l'attention du poste de travail concerné. 4.2.5.6. Recommandation Il convient que l'HMI aux postes ATC ayant recours au dispositif OLDI produise un avertissement lorsque le service OLDI n'est pas disponible. 4.2.6. Déclenchement des messages 4.2.6.1. Chaque système doit comporter un ensemble de paramètres techniques garantissant le déclenchement automatique, au moment opportun, des messages OLDI. 4.2.6.2. Recommandation Il convient de prévoir que la transmission d'un message de coordination puisse être déclenchée manuellement avant l'heure calculée. 4.2.6.3. Le déclenchement automatique doit toujours être assuré, si le déclenchement manuel n'est pas exécuté. 4.2.6.4. Le système doit utiliser des paramètres de temps pour définir les éléments suivants: - délai, avant la transmission, pendant lequel la teneur opérationnelle des messages s'affiche sur les écrans de l'organisme transférant; - délai, global ou par COP, de transmission du message, le cas échéant; - délai, après la transmission d'un message, pendant lequel un accusé de réception au niveau application doit être reçu (temps imparti). 4.2.6.5. Un message doit être transmis sans retard lorsque les informations nécessaires ne sont disponibles qu'après le moment où elles auraient dû être transmises. Exemple: Un vol entame un tronçon IFR CAG à un point proche de la limite qu'il s'apprête à franchir; l'ETO au point en question est communiquée huit minutes avant le COP; à ce stade, la transmission du message ACT est déjà en retard compte tenu des paramètres de temps applicables; le message doit donc être envoyé sans attendre. 4.2.7. Réception des messages 4.2.7.1. Le système ATC doit être en mesure: - de recevoir les messages OLDI; - de les traiter automatiquement conformément aux dispositions de la présente Norme; - de produire les données de vol correspondant au message reçu et d'afficher les avertissements nécessaires en cas d'incohérence dans les données reçues; - de produire et de transmettre automatiquement des accusés de réception au niveau application. 4.2.7.2. Un message d'accusé de réception (Accusé de réception logique (LAM), Acceptation (ACP) ou Attente de transfert (SBY)) doit être produit et transmis lorsque le message correspondant a été traité et les résultats du traitement doivent être communiqués au(x) poste(s) intéressé(s), suivant les besoins.NOTE Les modalités exactes de production d'un accusé de réception sont précisées pour chaque message. 4.3. Actualisation à partir des données de surveillance Recommandation Afin de garantir l'exactitude des données se rapportant aux heures estimées, il convient d'utiliser les informations obtenues de la poursuite radar des vols ou par tout autre moyen de surveillance pour actualiser la base de données des plans de vol. 4.4. Enregistrement des données OLDI 4.4.1. Contenu Le contenu ainsi que l'heure de réception de tous les messages OLDI doivent être enregistrées. 4.4.2. Moyens Les moyens nécessaires doivent être fournis en vue de l'extraction et de l'affichage des données enregistrées. 4.5. Disponibilité, fiabilité, sécurité et intégrité des données 4.5.1. Disponibilité 4.5.1.1. Le dispositif OLDI doit être disponible pendant les périodes où le flux de trafic entre les deux organismes concernés est normal et pendant les périodes de pointe. 4.5.1.2. Recommendation Il convient que le dispositif OLDI soit disponible 24 heures sur 24 et 7 jours sur 7. 4.5.1.3. Toute période de mise hors service programmée (et, par conséquent, le temps de disponibilité prévu) doit être convenue bilatéralement entre les deux organismes concernés. 4.5.2. Fiabilité 4.5.2.1. La fiabilité de toute liaison OLDI doit être de 99,86 % au minimum (ce qui représente une durée de mise hors service ne dépassant pas 12 heures par an sur la base d'une disponibilité 24 heures sur 24). 4.5.2.2. Recommandation Lorsque la mesure se justifie sur le plan opérationnel, il convient de garantir une fiabilité d'au moins 99,99 % (ce qui représente un temps de mise hors service équivalant à 52 minutes maximum par an, sur la base d'une disponibilité 24 heures sur 24). 4.5.3. Sécurité des données Recommandation Il convient d'appliquer au dispositif OLDI les méthodes de sécurité de données (telles que les droits d'accès ou la vérification des sources) et, le cas échéant, d'assurer la gestion du réseau. 4.5.4. Intégrité des données Le taux de défaillance au niveau application ne doit pas dépasser une erreur de transmission pour 2000 messages. 4.6. Evaluation opérationnelle 4.6.1. Période d'évaluation Tout nouveau dispositif OLDI, y compris lorsqu'il s'agit d'un nouvel équipement sur une liaison existante, doit faire l'objet d'une évaluation afin de vérifier l'intégrité des données, leur précision, leur fonctionnement, la compatibilité avec les procédures ATC et la sécurité dans son ensemble avant la mise en service opérationnel. NOTE Une procédure facilitant l'évaluation d'un nouveau dispositif OLDI peut être communiquée par le Secrétariat OLDI d'Eurocontrol. 4.6.2. Date de mise en service opérationnel La date de mise en service opérationnel, qui suppose que la phase d'évaluation soit arrivée à son terme, doit être convenue expressément entre les deux organismes. 5. CATÉGORIES DE MESSAGE 5.1. Généralités 5.1.1. Objet La présente section a pour objet: - de définir les catégories de message; - d'indiquer les temps de transaction requis pour chaque catégorie; - de préciser quels sont les messages obligatoires et ceux qui sont complémentaires; - de classer les types de message par catégorie. 5.1.2. Catégories de message Les messages OLDI ont été répartis selon les catégories suivantes: - Catégorie 1: Transfert de communication; - Catégorie 2: Coordination; - Catégorie 3: Notification. 5.2. Temps de transaction 5.2.1. Temps de transaction - Conditions 5.2.1.1. Les temps de transaction indiqués comprennent la transmission, le traitement initial par l'organisme recevant, la création du message d'accusé de réception, sa transmission et sa réception par l'organisme transférant. Les messages d'accusé de réception automatique LAM et SBY n'ont donc été classés dans aucune catégorie. 5.2.1.2. Les temps de transaction maxima pour chacune des catégories de message doivent être conformes aux indications du Tableau 5-1. Tableau 5-1 Temps maxima de transaction >EMPLACEMENT TABLE> 5.2.1.3. Une valeur de temps imparti doit être définie pour chaque catégorie ou type de message. 5.2.1.4. En l'absence d'accusé de réception dans le délai fixé, la transmission ou le traitement du message doit être considéré comme ayant échoué et un avertissement doit être envoyé, conformément aux dispositions prévues à cet égard dans le présent document. 5.2.1.5. Recommandation Il convient que les valeurs de temps imparti pour les trois catégories ne dépassent pas 12 secondes, 30 secondes et 60 secondes respectivement. 5.3. Classification et classement des messages 5.3.1. Classification des messages - Obligatoires et complémentaires 5.3.1.1. Les messages définis dans le présent document sont répartis en messages obligatoires ou complémentaires. 5.3.1.2. Lorsqu'un message est classé dans la catégorie obligatoire (M) pour la transmission (TX), le traitement doit être inclus de façon que ces messages puissent être envoyés. 5.3.1.3. Lorsqu'un message est classé dans la catégorie obligatoire (M) pour la réception (REC), le traitement doit être inclus de façon que ces messages puissent être reçus.NOTE Dans des cas exceptionnels, lorsque le flux de trafic entre deux organismes est unidirectionnel, l'obligation peut ne s'appliquer qu'aux messages dans une seule direction. 5.3.1.4. Lorsqu'un message est classé dans la catégorie complémentaire (C) pour la transmission (TX), le traitement doit être inclus de façon que ces messages puissent, le cas échéant, être envoyés par l'organe expéditeur et il doit faire l'objet d'un accord entre ce dernier et l'organe recevant.NOTE Les messages complémentaires peuvent être utilisés dans un seul sens, en fonction des besoins opérationnelles. 5.3.1.5. Lorsqu'un message est classé dans la catégorie obligatoire (C) pour la réception (REC), le traitement doit être inclus de façon que les messages reçus puissent être traités, lorsqu'une telle possibilité a été convenue au niveau bilatéralement. 5.3.1.6. Les conditions exposées dans les Tableaux 5-3 et 5-4 sont uniquement applicables lorsque l'emploi de la procédure de dialogue pour la coordination et/ou le transfert de communications respectivement a fait l'objet d'un accord bilatéral entre les organismes ATC. 5.3.2. Classement des messages 5.3.2.1. Le classement des messages de la procédure de base figure au Tableau 5-2. 5.3.2.2. Le classement des autres messages de coordination pour la procédure de dialogue est présenté au Tableau 5-3. 5.3.2.3. Le classement des messages de transfert de communication pour la procédure de dialogue figure au Tableau 5-4. Tableau 5-2 Messages de la procédure de base >EMPLACEMENT TABLE> Tableau 5-3 Procédure de dialogue - Messages de la phase de coordination (en complément au Tableau 5-2) >EMPLACEMENT TABLE> Tableau 5-4 Procédure de dialogue - Messages de la phase de transfert >EMPLACEMENT TABLE> 6. PROCÉDURE DE BASE - MESSAGES OBLIGATOIRES 6.1. Généralités 6.1.1. Description des prescriptions Le present chapitre décrit les exigences minimales à satisfaire au niveau application pour la mise en oeuvre du dispositif OLDI. 6.1.2. Mise en oeuvre Les organismes ayant recours aux moyens OLDI pour assurer la coordination des vols doivent appliquer les messages ABI, ACT et LAM suivant les modalités exposées dans la présente section, excepté lorsqu'il a été convenu bilatéralement d'appliquer la procédure de dialogue exposée à la Section 8 du présent document, auquel cas l'utilisation des messages ACT et LAM doit se faire suivant les dispositions prévues dans cette section. 6.2. Message de préavis de franchissement de limite (ABI) 6.2.1. Objet du message ABI Le message répond aux besoins opérationnels suivants: - permettre la saisie des données de plan de vol manquantes; - fournir à l'organisme ATC suivant des informations anticipées sur les franchissements de limites et toute révision qui y est apportée; - actualiser les données des plans de vol de base; - faciliter la corrélation anticipée des pistes radar; - faciliter l'évaluation précise à court terme de la charge du secteur. L'ABI est un message de notification. 6.2.2. Composition du message Le message ABI doit comprendre les éléments suivants: - type de message; - numéro du message; - identification de l'aéronef; - mode et code SSR (le cas échéant); - aérodrome de départ; - données estimées; - aérodrome de destination; - nombre d'aéronefs et type; - route (facultatif); - autres données de plan de vol (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 6.2.3. Règles d'application 6.2.3.1. Généralités 6.2.3.1.1. Sauf dispositions contraires prévues aux alinéas 6.2.3.1.3 et 6.2.3.1.4 ci-dessous, un ou plusieurs messages ABI doivent être envoyés pour chaque vol devant franchir la limite des zones de responsabilité, conformément aux procédures OLDI. 6.2.3.1.2. Le message ABI doit précéder le message d'activation (ACT) ou le message de proposition d'activation soumis pour accord (RAP). 6.2.3.1.3. Un message ABI ne doit pas être établi si l'envoi d'un message d'activation préliminaire (PAC) est prévu. 6.2.3.1.4. Recommandation Il convient d'empêcher la transmission d'un message ABI si le message ACT ou RAP est prévu d'être transmis immédiatement ou dans un intervalle de temps agréé bilatéralement.NOTE Cette recommandation vise à éviter que différents postes de l'organisme recevant ne tentent simultanément de résoudre des anomalies concernant des messages ABI et ACT relatifs à un même vol. 6.2.3.1.5. Un message ABI révisé doit être envoyé si le message ACT ultérieur n'a pas été produit et si: - la route suivie par le vol a été modifiée et que le COP figurant dans le message ABI précédent n'est plus exact; - l'aérodrome de destination a été changé; ou - le type d'aéronef a été modifié. 6.2.3.1.6. Recommandation Il convient d'envoyer un message ABI révisé si le message ACT ultérieur n'a pas été établi et si l'une des données ci-après fait l'objet d'une modification: - Le niveau de franchissement de limite escompté; - Le code SSR escompté au point de transfert de contrôle; - L'heure estimée de survol (ETO) du COP diffère du message ABI précédent dans une mesure supérieure au délai spécifié dans la Lettre d'accord (LoA); - Toute autre donnée convenue bilatéralement. 6.2.3.2. Traitement par l'organisme recevant 6.2.3.2.1. Le système ATC qui reçoit un message ABI doit tenter de l'associer aux données du plan de vol correspondant. 6.2.3.2.2. Si la tentative est infructueuse, un plan de vol doit être créé automatiquement ou manuellement par le système recevant. 6.2.3.2.3. Si le système parvient à associer le message à un plan de vol mais qu'il décèle une différence entre les données du message et les données correspondantes du système recevant, qui imposerait une mesure correctrice dès réception du message ACT suivant, la différence doit être signalée au poste de travail approprié pour qu'une solution y soit apportée. 6.2.3.3. Paramètres de temps applicables à la transmission 6.2.3.3.1. Le délai (en minutes) s'écoulant entre la transmission du message et l'heure prévue de passage au COP doit être conforme au paramètre défini. 6.2.3.3.2. Le(s) paramètre(s) de production de l'ABI doit (doivent) être stipulé(s) dans la Lettre d'accord entre les organismes ATC concernés. 6.2.3.3.3. Recommandation Il convient que les paramètres de production du message ABI: - puissent varier en fonction des dispositions de la LoA; - soient définis séparément pour chaque COP. 6.2.4. Accusé de réception de l'ABI 6.2.4.1. Accusé de réception Il doit être accusé réception d'un message ABI par la production et la transmission d'un message LAM. NOTE Un message LAM est produit quels que soient les résultats de la tentative d'association du plan de vol. 6.2.4.2. Absence d'accusé de réception Recommandation En l'absence de message LAM accusant réception d'un message ABI, il convient qu'un avertissement s'affiche sur un poste de supervision. 6.2.5. Exemples "Air 2000" 253, un Boeing 757 reliant Malte à Birmingham, heure estimée d'arrivée au VOR BNE à 1221 UTC, niveau de vol FL350, vitesse propre de 480 noeuds, route prévue via UB4 BNE UB4 BPK UB3 HON, transpondeur réglé sur A7012 , niveau de vol demandé FL390. Les exemples ci-dessous sont les équivalents du message ABI envoyé par le CCR de Reims au CCR de Londres. 6.2.5.1. OACI (ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON) 6.2.5.2. ADEXP -TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON 6.3. Message d'activation (ACT) 6.3.1. Objet du message ACT Le message ACT répond aux besoins opérationnels suivants: - remplacer l'estimation verbale de franchissement de limite par la transmission automatique des informations relatives à un vol d'un organisme ATC au suivant avant le transfert de contrôle; - actualiser les données du plan de vol de base dans l'organisme ATC recevant, en fonction des informations les plus récentes; - faciliter la distribution et l'affichage des données du plan de vol sur les écrans des postes de travail intéressés de l'organisme ATC recevant; - accélérer l'affichage de la corrélation indicatif d'appel/code dans l'organisme ATC recevant; - communiquer les conditions de transfert à l'organisme ATC recevant. 6.3.2. Composition du message Le message ACT doit comprendre les éléments suivants: - type de message; - numéro du message; - identification de l'aéronef; - mode et code SSR; - aérodrome de départ; - données estimées; - aérodrome de destination; - nombre d'aéronefs et type; - route (facultatif); - autres données du plan de vol (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 6.3.3. Règles d'application 6.3.3.1. Généralités 6.3.3.1.1. Un message ACT doit être envoyé pour les vols remplissant les conditions requises qui franchissent la limite, excepté dans les cas prévus à l'alinéa 6.3.3.1.10. 6.3.3.1.2. Le message ACT doit être produit et transmis automatiquement, au moment calculé selon les modalités prévues dans la Lettre d'accord, sauf s'il a été déclenché manuellement auparavant. 6.3.3.1.3. Recommandation Il convient de fournir au personnel ATC le moyen de déclencher la transmission de messages ACT avant l'heure calculée de transmission. 6.3.3.1.4. La teneur opérationnelle du message ACT à transmettre doit s'afficher au poste de travail responsable de la coordination du vol avant que le message ne soit effectivement transmis. 6.3.3.1.5. Recommandation S'agissant du point 6.3.3.1.4, il convient que l'heure calculée de transmission automatique du message ACT soit affichée en même temps que la teneur du message. 6.3.3.1.6. Le message ACT doit contenir les informations les plus récentes sur le vol, qui rendent compte des conditions de sortie prévues. 6.3.3.1.7. La transmission du message ACT doit être notifiée au poste de travail concerné. 6.3.3.1.8. Dès réception d'un LAM, les données du message ACT ont force obligatoire, sur le plan opérationnel, pour les deux organismes ATC. Les conditions de transfert coordonnées et la réception du LAM doivent être portées à la connaissance du personnel ATC de l'organisme transférant. 6.3.3.1.9. L'organisme recevant est réputé avoir accepté les conditions de transfert prévues dans le message ACT, sauf s'il engage une coordination en vue de les modifier. 6.3.3.1.10. Un nouveau message ACT ne peut être envoyé au même partenaire de coordination que si le précédent a été annulé par un MAC. 6.3.3.1.11. Des informations sur la route et toute autre donnée du plan de vol doivent être mentionnées, s'il en a été convenu ainsi bilatéralement. 6.3.3.2. Traitement par l'organisme recevant 6.3.3.2.1. Le système ATC qui reçoit une message ACT doit tenter de l'associer au plan de vol correspondant. 6.3.3.2.2. Si un plan de vol correspondant est trouvé et si le message ne présente aucune anomalie susceptible d'empêcher qu'il ne soit traité correctement: - le contenu opérationnelle doit être inclus dans le plan de vol; - les données requises doivent être transmises aux positions opérationnelles ATC et d'autres, suivant les besoins; - un LAM doit être envoyé en retour. 6.3.3.2.3. Si un plan de vol correspondant ne peut être trouvé ou si une anomalie ne permet pas de traiter correctement le message: - s'il est possible de déterminer le secteur appelé à accepter le contrôle du vol: - le contenu opérationnel du message doit s'afficher sur les écrans de ce secteur; - un LAM doit être envoyé en retour; - un plan de vol doit être créé; - dans tous les autres cas, un LAM ne doit pas être envoyé en retour. 6.3.3.3. Paramètres de transmission 6.3.3.3.1. Le message doit être transmis dès que possible après la première des deux échéances calculées comme suit: - un nombre de minutes, calculé selon le paramètre défini, avant l'heure estimée de passage au COP; - le moment où le vol se trouve à une distance du COP qui aura été convenue bilatéralement. 6.3.3.3.2. Les paramètres de production du message ACT doivent figurer dans la Lettre d'accord entre les organismes ATC intéressés. 6.3.3.3.3. Les paramètres de production du message ACT doivent être variables et pouvoir être modifiés sur la base des dispositions de la Lettre d'accord. 6.3.3.3.4. Recommandation Il convient que les paramètres de production du message ACT soient définis séparément pour chaque COP. 6.3.3.3.5. Les paramètres stipulés doivent laisser suffisamment de temps pour: - permettre à l'organisme émettant d'actualiser le niveau de vol de transfert de contrôle, de façon à tenir compte des conditions prévues au COP; et - permettre à l'organisme recevant de traiter le message ACT ainsi que de produire et transmettre un message LAM tout en laissant la possibilité à l'organisme transférant d'effectuer une coordination verbale et à l'organisme acceptant de prendre les mesures qui s'imposent en cas d'échec de l'échange de données. 6.3.4. Accusé de réception du message ACT 6.3.4.1. Accusé de réception Il doit être accusé réception d'un message ACT par la production et la transmission d'un message LAM. 6.3.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'une message ACT, un avertissement doit s'afficher au poste ATC responsable de la coordination du vol. 6.3.5. Exemples Les exemples ci-après complètent ceux qui ont été donnés pour le message ABI à l'alinéa 6.2; toutes les indications sont les mêmes, à l'exception de l'ETO au COP, qui est de 1226 dans le message ACT ci-après. 6.3.5.1. OACI (ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON) 6.3.5.2. ADEXP -TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON 6.4. Message d'accusé de réception logique (LAM) 6.4.1. Objet du message LAM L'objet du message LAM est d'informer l'organisme émettant que le message transmis a été reçu et est sauvegardé par l'organisme recevant. La procédure d'un LAM donne au personnel ATC de l'organisme transférant: - un avertissement lorsqu'aucun accusé de réception n'a été reçu; - une indication que le message dont il est accusé réception a été reçu, qu'il a été soumis au traitement approprié, qu'aucune erreur n'y a été décelée, qu'il a été stocké et, le cas échéant, qu'il peut être communiqué aux postes de travail compétents. 6.4.2. Composition du message Le message LAM doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 6.4.3. Règles d'application 6.4.3.1. Généralités 6.4.3.1.1. Les règles d'envoi d'un LAM sont précisées individuellement pour chaque type de message dans la section correspondante du présent document. 6.4.3.1.2. Le message LAM doit être produit et transmis sans intervention humaine. 6.4.3.1.3. Le message LAM ne doit pas servir à éviter l'envoi de messages techniques destinés à vérifier l'intégrité des transmissions de données. 6.4.3.1.4. Le message LAM doit être produit et transmis immédiatement de façon que le délai de transaction du message dont il est accusé réception puisse être respecté. 6.4.3.1.5. Excepté dans le cas des messages ABI, le système ATC émettant doit informer le contrôleur responsable de la coordination lorsqu'un message LAM n'a pas été reçu dans le délai fixé. 6.4.4. Accusé de réception du LAM Le message LAM ne doit faire l'objet d'aucun accusé de réception. 6.4.5. Exemples 6.4.5.1. OACI (LAML/E012E/L001) 6.4.5.2. ADEXP -TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 7. PROCÉDURE DE BASE - MESSAGES COMPLÉMENTAIRES 7.1. Généralités 7.1.1. Description des prescriptions La présente section traite du dispositif applicable à la procédure de base qui complète les modalités exposées à la Section 6 - Messages obligatoires. 7.1.2. Mise en oeuvre 7.1.2.1. L'application de l'une des dispositions décrites dans la présente section doit faire l'objet d'un accord bilatéral préalable. 7.1.2.2. Lorsque l'application en est approuvée, les règles décrites ci-après doivent être respectées. 7.2. Message d'activation préliminaire (PAC) 7.2.1. Objet du message PAC Le message PAC répond aux besoins opérationnels suivants: - notification et coordination avant le départ d'un vol lorsque le temps de vol entre le point de départ et le COP est inférieur au délai qui serait nécessaire pour que les paramètres de temps fixés pour la transmission du message ACT soient respectés; - notification et coordination d'un vol avant le départ entre un organisme local (contrôle d'aérodrome/d'approche) et l'organisme suivant qui prendra le vol en charge; - saisie de données de vol manquantes en cas d'incohérences dans les données de plan de vol initialement diffusées; - demande d'assignation d'un code SSR émanant de l'organisme auquel la notification/coordination visée ci-dessus est adressée, le cas échéant. 7.2.2. Composition du message Le message PAC doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message (facultatif); - identification de l'aéronef; - mode et code SSR; - aérodrome de départ; - heure estimée de décollage ou données estimées; - aérodrome de destination; - type d'aéronef; - route (facultatif); - autres données du plan de vol (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 7.2.3. Règles d'application 7.2.3.1. Généralités 7.2.3.1.1. Un ou plusieurs messages PAC doivent être envoyés pour chaque vol censé franchir la limite des zones de responsabilité lorsque le temps de vol entre le départ et le COP ne permettrait pas l'envoi du message ACT au moment voulu. 7.2.3.1.2. Un ou plusieurs messages PAC doivent être envoyés par l'organisme de contrôle d'aérodrome/d'approche à l'organisme suivant pour chaque vol au départ devant faire l'objet d'une notification ou d'une coordination. 7.2.3.1.3. Recommandation Pour l'application des messages PAC/LAM entre organismes, il convient que les systèmes TWR/APP compétents aient les moyens d'introduire et de transmettre les données "start-up", "push-back", "taxi" ou toutes autres informations comparables à partir desquelles l'ETOT peut être déterminée, de façon à permettre le calcul de l'ETO au COP et la transmission du PAC. 7.2.3.1.4. Suivant les dispositions arrêtées bilatéralement, le message doit inclure: - soit l'heure estimée de décollage; - soit des données d'estimation. 7.2.3.1.5. Lorsqu'il a été convenu bilatéralement, d'inclure la référence du message, le PAC doit: - comprendre le numéro de référence du premier message PAC envoyé pour le vol en question; - être mentionné dans le second message PAC et les suivants. 7.2.3.1.6. Si nécessaire, l'utilisation de la procédure de demande de code doit faire l'objet d'un accord bilatéral. 7.2.3.1.7. Un message PAC révisé doit être envoyé si, avant le départ, l'une des circonstances ci-après se présente: - la modification de la route suivie par le vol est telle que le COP du message précédent n'est plus valable; - le type d'aéronef a été modifié; - l'aérodrome de destination indiqué dans le PAC précédent a été jugé inexact. 7.2.3.1.8. Recommandation Il convient d'envoyer un message PAC révisé si, avant le départ, les données suivantes diffèrent du message PAC précédent: - le niveau (s'il figure dans les données d'estimation); - le code SSR prévu au point de transfert de contrôle; - l'heure estimée de décollage ou l'heure estimée de passage au COP, si la variation dépasse le délai convenu bilatéralement; - toute autre donnée, suivant les dispositions arrêtées d'un commun accord. 7.2.3.2. Traitement du message par l'organisme recevant 7.2.3.2.1. Le système ATC qui reçoit un message PAC doit tenter de l'associer au plan de vol auquel il correspond. 7.2.3.2.2. Si le plan de vol correspondant est trouvé et qu'il n'y a pas de discordance dans le message de nature à faire obstacle à son traitement correct: - le contenu opérationnelle doit être incluse dans le plan de vol; - les données nécessaires doivent être produites aux postes opérationnels ATC et autres, suivant les besoins; - un LAM doit être envoyé. 7.2.3.2.3. Si le message ne peut être associé à aucun plan de vol ou s'il ne peut être traité correctement par suite d'une anomalie: - lorsque le secteur chargé d'accepter le contrôle du vol peut être identifié: - la teneur opérationnelle du message doit s'afficher sur les écrans dans le secteur en question; - un LAM doit être envoyé; - un plan de vol doit être créé; - dans tous les autres cas, un LAM ne doit pas être renvoyé. 7.2.3.2.4. Les données du deuxième message PAC ou tout autre message ultérieur doivent remplacer les données du message précédent. 7.2.3.2.5. Si le message PAC comporte une demande d'assignation de code SSR et peut être traité correctement, ainsi qu'il est prévu à l'alinéa 7.2.3.2.2 ci-dessus, un message COD doit être renvoyé en plus du message LAM.NOTE Étant donné que des informations détaillées sur la route indiquée dans le plan de vol sont nécessaires pour assigner des codes, l'organisme recevant n'est pas tenu par le présent document de renvoyer un message COD lorsque ces données ne sont pas disponibles. Cela n'exclut pas la possibilité de renvoyer un message en pareilles circonstances, si les moyens adéquats existent localement et si la procédure a fait l'objet d'un accord bilatéral. 7.2.3.3. Paramètres de temps applicables à la transmission Aucun paramètre de temps n'est applicable à la transmission puisque l'envoi du message fait suite à l'introduction manuelle d'un message signalant le départ imminent du vol. 7.2.4. Accusé de réception du PAC 7.2.4.1. Accusé de réception Les messages à envoyer en réponse à un PAC sont décrits à l'alinéa 7.2.3.2 ci-dessus. 7.2.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message PAC, un avertissement doit s'afficher au poste de travail de l'organisme ATC responsable de la coordination avec l'organisme suivant. 7.2.4.3. Absence de LAM En l'absence de LAM, la coordination doit se faire verbalement. 7.2.4.4. Absence de message COD 7.2.4.4.1. En l'absence de message COD faisant suite à une demande de code incluse dans le message PAC, un avertissement doit s'afficher au poste de travail compétent. 7.2.4.4.2. Lorsque la fonction de demande de code doit être utilisée, la valeur de temps imparti à appliquer doit faire l'objet d'un accord bilatéral. 7.2.5. Exemples 7.2.5.1. Heure estimée de décollage et demande de code 7.2.5.1.1. OACI (PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M) 7.2.5.1.2. ADEXP -TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA 7.2.5.2. Heure au COP 7.2.5.2.1. OACI (PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-EBBR-9/B737/M) 7.2.5.2.2. ADEXP -TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL F110A -ARCTYP B737 -ADES EBBR 7.3. Message de révision (REV) 7.3.1. Objet du message REV Le message REV sert à transmettre des révisions apportées aux données de coordination envoyées précédemment dans un message ACT, à condition que la modification n'entraîne pas de changement d'organisme acceptant. 7.3.2. Composition du message Le message REV doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message (facultatif); - identification de l'aéronef; - mode et code SSR (facultatif); - aérodrome de départ; - données estimées; - point de coordination (facultatif); - aérodrome de destination; - route (facultatif); - autres données du plan de vol (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 7.3.3. Règles d'application 7.3.3.1. Généralités 7.3.3.1.1. Un ou plusieurs messages REV peuvent être envoyés à l'organisme avec lequel la coordination d'un vol est en cours au moyen d'un message d'activation. 7.3.3.1.2. Les éléments suivants doivent faire l'objet de révisions: - ETO au COP; - niveau(x) de transfert; - Code SSR. 7.3.3.1.3. Un message REV doit être envoyé: - lorsque la variation de l'ETO au COP, par rapport à celle indiquée dans le message précédent, est supérieure à la valeur convenue bilatéralement, arrondie au chiffre entier le plus proche; - en cas de changement du ou des niveaux de transfert ou de code SSR. 7.3.3.1.4. Sous réserve d'accord bilatéral, un message REV doit être envoyé en cas de modification affectant: - le COP; - la route; - d'autres données du plan de vol (champs OACI 8, 10 et 18). NOTE Des règles opérationnelles peuvent imposer une coordination préalable entre organismes concernés en cas de modifications apportées après l'ACT. 7.3.3.1.5. Sous réserve d'accord bilatéral, la référence du message doit figurer dans le message REV. 7.3.3.1.6. La référence du message, lorsqu'elle est mentionnée, doit comprendre le numéro du message ACT précédent. 7.3.3.1.7. L'organisme ATC recevant doit être réputé avoir accepté les conditions de transfert entraînées par le message REV, à moins qu'il n'engage une coordination pour les modifier. 7.3.3.2. Format des messages de révision 7.3.3.2.1. Format OACI Tous les messages de révision comprennent les champs 3, 7, 13, 14 et 16 où sont consignées les révisions des catégories suivantes: - un changement d'ETO au COP ou de niveau de transfert doit figurer dans les données révisées du champ 14; - tout changement de code SSR doit apparaître dans le champ 7; - les changements de route, y compris de COP, doivent être mentionnés dans les données des champs 14 et 15 incluses dans le format de champ 22 après les cinq premiers champs. Ces messages doivent comporter deux champs 14, le premier étant réservé aux données de l'alinéa a), le COP par lequel le vol avait été précédemment coordonné. Les règles de coordination des changements de cette nature, y compris les acheminements directs, figurent à l'Annexe B, Prescriptions applicables au traitement des acheminements particuliers; - les modifications apportées aux champs 8, 10 et 18 figureront en tant que données du champ 22 après les cinq premiers champs. 7.3.3.2.2. Format ADEXP Tous les messages de révision présentés selon le format ADEXP doivent figurer dans les champs primaires suivants: TITLE REFDATA ARCID ADEP ADES. Les règles ci-après sont applicables: - un changement d'ETO au COP, ou de niveau de transfert doit apparaître dans les données révisées du champ primaire COORDATA; - les changements de route, y compris de COP doivent figurer dans les champs primaires COORDATA et ROUTE. Ces messages doivent comporter le champ primaire COP où apparaît le point de coordination par lequel le vol a été précédemment coordonné. Les règles de coordination des changements de cette nature, y compris les acheminements directs, sont précisées à l'Annexe B; - un changement de code SSR doit être indiqué dans le champ primaire SSRCODE; - les modifications apportées aux autres données de plan de vol doivent apparaître dans le(s) champ(s) primaire(s) appropriés, tels qu'ils sont définis dans l'Annexe A. Si un message de révision est envoyé simplement pour coordonner le code SSR et/ou d'autres données du plan de vol, le champ primaire COP doit remplacer le champ COORDATA. 7.3.3.2.3. Code SSR Le mode et le code SSR doivent figurer dans un message REV uniquement s'il est nécessaire de coordonner un changement de code SSR. 7.3.3.3. Traitement par l'organisme recevant 7.3.3.3.1. Un système ATC qui reçoit un message REV après avoir reçu également du même organisme ATC un message ACT concernant le vol en question doit tenter de l'associer au plan de vol correspondant. 7.3.3.3.2. S'il trouve un plan de vol correspondant et que le message ne présente aucune anomalie susceptible d'empêcher qu'il ne soit traité correctement: - le contenu opérationnelle du message doit être jointe au plan de vol; - les données nécessaires doivent être produites aux postes ATC opérationnels et aux autres postes de travail, suivant les besoins. 7.3.3.4. Déclenchement de la transmission 7.3.3.4.1. Le message REV est déclenché par un événement et doit être transmis immédiatement après l'introduction ou l'actualisation des données correspondantes. 7.3.3.4.2. Aucun changement ne doit être effectué au moyen d'un message REV,une fois que le vol a atteint un certaine distance du point de transfert ou après un délai déterminé. Les paramètres de temps et de distance doivent faire l'objet d'un accord bilatéral. 7.3.3.4.3. Recommandation Il convient de définir les paramètres REV séparément pour chaque COP. 7.3.3.5. Changement d'organisme ATC recevant Le message REV ne doit pas être utilisé lorsqu'une révision des données du plan de vol entraîne un changement d'organisme ATC recevant (voir le message d'abrogation de la coordination). 7.3.4. Accusé de réception du REV 7.3.4.1. Accusé de réception Si le message REV: - peut être associé à un plan de vol contenu dans le système recevant, un message LAM doit être transmis à titre d'accusé de réception; - ne peut être associé à un plan de vol contenu dans le système recevant, un message LAM ne doit pas être transmis. 7.3.4.2. Absence d'accusé de réception 7.3.4.2.1. En l'absence de message LAM accusant réception d'un message REV, un avertissement doit s'afficher au poste ATC responsable de la coordination des vols. 7.3.4.2.2. Lorsqu'aucun LAM n'est reçu, une révision verbale doit être engagée par l'organisme ATC transférant. 7.3.5. Exemples 7.3.5.1. OACI a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB) b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB) 7.3.5.2. ADEXP a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317 7.4. Message d'abrogation de coordination (MAC) 7.4.1. Objet du message MAC Un message MAC sert à indiquer à l'organisme recevant que la coordination ou la notification effectuée antérieurement pour un vol est abrogée. Le message MAC ne remplace pas un message d'annulation (CNL), tel que l'OACI l'a défini, et ne doit donc pas être utilisé pour effacer les données du plan de vol de base. 7.4.2. Composition du message Le message MAC doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message (facultatif); - identification de l'aéronef; - aérodrome de départ; - point de coordination; - aérodrome de destination; - état de la coordination et raison de l'abrogation (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 7.4.3. Règles d'application 7.4.3.1. Généralités 7.4.3.1.1. Un message MAC doit être envoyé à l'organisme auprès duquel la coordination d'un vol avait été effectuée antérieurement au moyen d'un message ACT ou RAP, lorsqu'une des situations ci-après se présente: - le niveau escompté au point de transfert est différent du niveau indiqué dans le message précédent, entraînant un changement de l'organisme suivant dans la séquence de coordination; - la route suivie par le vol a été modifiée, entraînant un changement de l'organisme suivant dans la séquence de coordination; - le plan de vol est supprimé du système de l'organisme émettant et la coordination n'est donc plus nécessaire; - l'organisme précédent a envoyé un message MAC concernant le vol. 7.4.3.1.2. Lorsque l'envoi d'un message MAC résulte d'une modification d'un niveau de vol ou de route, la notification et/ou la coordination, selon le cas, doivent être effectuées avec le nouvel organisme dans la séquence de coordination. 7.4.3.1.3. Un message MAC doit être envoyé en cas d'abrogation de la coordination, effectuée par un message PAC, pour un vol au départ. 7.4.3.1.4. Recommandation Il convient d'envoyer un message MAC lorsque la notification (message ABI) concernant un vol est annulée pour l'une des raisons mentionnées à l'alinéa 7.4.3.1.1 ci-dessus ou lorsque le vol est retardé en route et qu'une estimation révisée ne peut être déterminée automatiquement. 7.4.3.1.5. Une référence du message sera incluse, s'il en a été convenu bilatéralement. 7.4.3.1.6. La référence du message, si elle est indiquée, doit comprendre le numéro du dernier message ABI, PAC ou ACT concernant le vol qui a été transmis et dont il a été accusé réception. 7.4.3.1.7. Le point de coordination doit être le point de transition (COP) par lequel le vol était censé passer d'après la notification ou la coordination antérieure. 7.4.3.1.8. Recommandation Il convient que le message MAC indique le statut auquel la coordination ou la notification doit revenir et les motifs de l'abrogation. 7.4.3.1.9. Le statut et les motifs, s'ils sont indiqués, doivent être l'un des suivants: - lorsque l'organisme recevant n'est plus le partenaire de coordination suivant: - le statut est INI (initial); - le motif est l'un des suivants: - TFL en cas de changement de niveau de transfert; - RTE en cas de changement de route; - CSN en cas de changement d'indicatif d'appel; - CAN en cas d'annulation ; - OTH dans tout autre cas ou si le motif est inconnu; - lorsque l'une des situations suivantes se présente: - la coordination effectuée au moyen du message PAC or ACT précédent (éventuellement modifié par un message REV) est abrogée mais le vol devrait normalement faire l'objet d'une nouvelle séquence de coordination avec le même organisme; - après transmission d'un message ABI, le vol est en attente pour une durée indéterminée et devrait normalement donner lieu à l'envoi d'un message ABI ou ACT révisé, selon le cas: - le statut est NTF (notification); - le motif est l'un des suivants: - DLY en cas de retard; - HLD en cas d'attente; - OTH dans tout autre cas ou si le motif est inconnu. 7.4.3.1.10. Si le vol doit faire l'objet d'une nouvelle notification ou coordination: - une nouveau message de notification et/ou de coordination, selon le cas, doit être envoyé; - un message MAC ne doit avoir aucune incidence sur les données du plan de vol de base qui sont stockées dans le système de l'organisme ATC recevant; - le système doit rester à même de traiter correctement un nouveau message de notification et/ou de coordination émanant soit de l'organisme transférant précédent, soit d'un autre organisme, dans le cadre d'une nouvelle séquence de coordination. 7.4.3.2. Traitement par l'organisme recevant Le ou les poste(s) de travail de l'organisme ATC recevant au(x)quel(s) les informations sur le vol en question sont communiquées doivent être avisés de l'abrogation. 7.4.4. Accusé de réception du MAC 7.4.4.1. Accusé de réception 7.4.4.1.1. Si le message MAC peut être associé à un plan de vol contenu dans le système recevant et peut être traité, un message LAM doit être transmis à titre d'accusé de réception. 7.4.4.1.2. Si le message MAC ne peut être associé à un plan de vol contenu dans le système recevant ou ne peut être traité, un message LAM ne doit pas être transmis. 7.4.4.2. Absence d'accusé de réception 7.4.4.2.1. Si la coordination ATC est abrogée et qu'aucun message LAM n'est reçu, un avertissement doit s'afficher au poste ATC responsable de la coordination des vols. 7.4.4.2.2. Dans ce cas, l'organisme ATC transférant doit abroger verbalement la coordination. 7.4.5. Exemples Un message ABI a été envoyé par le CCR d'Amsterdam au CCR de Bruxelles pour le vol HOZ3188 - altitude prévue FL190; à la demande du pilote, le vol obtient ultérieurement l'autorisation de monter à FL 270 et entre donc dans l'espace aérien de Maastricht au lieu de pénétrer dans l'espace aérien de Bruxelles. Les exemples (7.4.5.1 a) et 7.4.5.2 a)) montrent comment le MAC envoyé à Bruxelles par Amsterdam figurerait à la fois dans le format OACI et dans le format ADEXP. Un message ABI puis un message ACT sont envoyés à Maastricht, mais quelques minutes avant que le vol n'atteigne le COP, l'aéronef retourne vers l'aéroport d'Amsterdam et le plan de vol est annulé dans le système de l'organisme émettant; un message MAC est envoyé à Maastricht, ainsi qu'il apparaît dans les exemples (7.4.5.1 b et 7.4.5.2 b). 7.4.5.1. OACI a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL) b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN) 7.4.5.2. ADEXP a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN 7.5. Message d'assignation de code SSR (COD) 7.5.1. Objet du message COD 7.5.1.1. La Méthode d'assignation des codes en fonction de la région d'origine (ORCAM) a été conçue pour permettre à un vol de répondre sur le même code aux organismes successifs au sein de la zone de participation. À défaut d'assignation centrale des codes, assurée par exemple par un CCR, une série de codes SSR individuels peut devoir être assignée à chaque aéroport, ce qui entraîne une grande dispersion des codes. 7.5.1.2. Le message COD répond à la nécessité opérationnelle de diffuser un code SSR en mode A à chaque organisme ATS successif pour un vol donné, en cas de demande. Un dispositif facultatif permet à l'organisme émettant d'inclure la route suivie par le vol, s'il en a été convenu bilatéralement. 7.5.2. Composition du message Le message COD doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message (facultatif); - identification de l'aéronef; - mode et code SSR; - aérodrome de départ; - aérodrome de destination; - route (facultatif). NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 7.5.3. Règles d'application 7.5.3.1. Généralités 7.5.3.1.1. Un message COD doit être produit et transmis automatiquement en réponse à une demande d'assignation de code contenue dans un message. 7.5.3.1.2. Le code SSR doit être le code assigné au vol. 7.5.3.1.3. Le code de saturation approuvé, tel qu'il est précisé dans le Plan de navigation aérienne pour la Région Europe, doit être indiqué en l'absence de code individuel. 7.5.3.1.4. S'il en a été convenu bilatéralement, la référence du message, comprenant le numéro du message auquel le COD répond, doit être incluse. 7.5.3.1.5. La route doit être mentionnée, s'il en a été convenu bilatéralement. 7.5.3.1.6. L'organisme qui reçoit le message COD est réputé avoir accepté le code SSR. 7.5.3.2. Traitement par l'organisme recevant 7.5.3.2.1. Un LAM doit être envoyé en retour, à condition que le message ne présente aucune anomalie empêchant qu'il ne soit traité correctement. 7.5.3.2.2. Si le message ne peut être associé à un plan de vol ou présente une anomalie empêchant qu'il ne soit traité correctement, un LAM ne doit pas être envoyé en retour. 7.5.3.2.3. Les données de route, si elles sont mentionnées, ne doivent pas constituer un motif d'empêchement d'envoi d'un LAM, à moins qu'elles ne soient pas conformes aux spécifications de présentation indiquées à l'Annexe A. 7.5.3.3. Paramètres de temps applicables à la transmission Aucun paramètre de temps n'est applicable à la transmission étant donné que l'envoi d'un message COD fait suite à la réception d'un message par lequel l'assignation d'un code SSR est sollicitée. 7.5.4. Accusé de réception du COD 7.5.4.1. Accusé de réception Il doit être accusé réception d'un message COD par la production et la transmission d'un message LAM. 7.5.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'une message COD, un avertissement doit s'afficher au poste de travail responsable. 7.5.5. Exemples 7.5.5.1. OACI (CODP/PO011-AAL905/A0767-LFPO-KEWR) 7.5.5.2. ADEXP -TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO -SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905 -SSRCODE A0767 7.6. Message d'information (INF) 7.6.1. Objet du message INF 7.6.1.1. Le message INF sert à communiquer des informations sur certains vols aux organes qui ne sont pas directement associés au processus de coordination entre deux organismes ATC se succédant sur la route suivie par le vol. 7.6.1.2. Le message INF peut servir à communiquer aux organes précités copie des messages et leur faire connaître les modalités de la coordination sur lesquelles les contrôleurs se sont entendus à l'issue de leur dialogue. À cet effet, les messages INF peuvent être produits par le système de l'organisme transférant ou celui de l'organisme acceptant. 7.6.1.3. Le message INF peut servir en outre à communiquer à un organisme des informations concernant n'importe quel point sur le trajet suivi par le vol. 7.6.1.4. Le format permet la communication des données initiales, des révisions et des annulations. 7.6.2. Composition du message Le message INF doit comprendre les éléments ci-après présentés selon le format de message décrit dans le présent document: - type de message; - numéro du message; - tous les éléments de données opérationnelles figurant dans le message initial ou résultant de la coordination relatée dans la copie du message; - type du message de référence. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 7.6.3. Règles d'application 7.6.3.1. Types de message Les types de message dont l'INF enverra copie seront fonction des besoins des utilisateurs et des moyens dont dispose l'organisme émettant. Les types de message et les règles d'application feront généralement l'objet d'un accord bilatéral. 7.6.3.2. Destinataires des messages Un ou plusieurs messages INF concernant un même vol peuvent être transmis à un ou plusieurs destinataires. 7.6.3.3. Teneur opérationnelle La teneur opérationnelle du message INF doit être présentée selon le format de l'un des messages existants. 7.6.3.4. Recommandations 1. Les conditions communiquées dans un message de dialogue initial (par exemple messages ACT, RAP, REV, RRV) peuvent être modifiées ou rejetées avant la fin du dialogue. Il convient que les organismes émettant soient en mesure de transmettre les conditions de coordination définitivement adoptées. 2. Il convient que le message INF soit envoyé immédiatement ou à un moment, en rapport avec l'heure de passage au COP, ayant fait l'objet d'un accord bilatéral avec l'organe recevant. 7.6.4. Accusé de réception de l'INF Recommandations 1. L'accusé de réception du message INF peut se faire, selon le partenaire de coordination, par la production et la transmission d'un message LAM. 2. Sous réserve d'accord bilatéral entre les organismes concernés, en l'absence de message LAM accusant réception d'un message INF, il convient qu'un avertissement s'affiche au poste de travail approprié. 7.6.5. Exemples Aéronef B747, ayant pour indicatif d'appel BAW011, se rendant de EGLL à OMDB, niveau de vol FL290; demande de monter à FL410; est attendu au VOR de Koksy (KOK) à 1905, transpondeur réglé sur A5437, suit les voies UG1 et UB6. Londres envoie à Maastricht un message ACT concernant le vol et en adresse copie à un organisme dénommé IT. On trouvera ci-après des exemples du message INF. 7.6.5.1. OACI (INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/MSG/ACT) 7.6.5.2. ADEXP -TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK NTM UB6 KRH -MSGTYP ACT 8. PROCÉDURE DE DIALOGUE - COORDINATION 8.1. Généralités 8.1.1. Introduction 8.1.1.1. La procédure de dialogue fournit des moyens de communication et de négociation entre contrôleurs pendant la phase de coordination et des moyens de communication pendant la phase de transfert. 8.1.1.2. La présente section décrit les messages utilisés dans le cadre de la procédure de dialogue en phase de coordination des conditions de transfert. Les messages utilisés pour la phase de transfert, lorsque la prise en charge du vol passe d'un organisme au suivant, sont exposés à la Section 9 - Procédure de dialogue - Transfert de communication. 8.1.1.3. Les procédures définies pour les deux phases ne sont pas interdépendantes; elles peuvent être appliquées individuellement ou conjointement. 8.1.1.4. Un certain nombre de messages supplémentaires sont introduits et la possibilité pour l'un ou l'autre des partenaires d'engager le dialogue est offerte. 8.1.1.5. La procédure de dialogue en phase de coordination permet de distinguer: - les transferts qui sont conformes aux lettres d'accord et peuvent être acceptés automatiquement; - les transferts qui doivent être soumis à l'approbation du contrôleur dans l'organisme recevant. 8.1.1.6. Cette procédure permet aussi de suivre l'interprétation des lettres d'accord dans les deux systèmes et de déceler d'éventuelles anomalies. 8.1.2. Le filtre 8.1.2.1. Généralités 8.1.2.1.1. La procédure de dialogue en phase de coordination impose aux systèmes de déterminer si les transferts sont ou non conformes aux lettres d'accord. 8.1.2.1.2. Le mécanisme de vérification de la conformité est appelé "filtre" dans le présent document. La base de données utilisée pour l'opération de filtrage doit comprendre, le cas échéant, les éléments suivants: - points de coordination agréés; - niveaux de vol admissibles (ou non admissibles) qui peuvent également être associés aux points de coordination; - aérodromes de départ; - destinations; - routes directes agréées; - limite, en temps et/ou en distance par rapport au COP, à partir de laquelle tout message de coordination est considéré comme non standard; - toute autre condition, selon les dispositions convenues bilatéralement. 8.1.2.1.3. Tous les éléments de cette liste peuvent être associés pour rendre compte de situations plus complexes. 8.1.2.1.4. Dans la présente Section 8, l'expression "conditions standard" doit être interprétée comme "conformes à la lettre d'accord", l'expression "conditions non standard" voulant dire "non conformes à la lettre d'accord". Sauf dispositions contraires convenues bilatéralement, les messages envoyés par les organismes transférants à des fins de coordination de transferts dont le caractère standard est connu doivent être d'une catégorie différente des messages se rapportant à des conditions non standard. 8.1.2.2. Mesures à prendre dans le centre transférant 8.1.2.2.1. Le filtrage opéré dans le centre transférant doit permettre de contrôler les conditions de transfert sur le point d'être communiquées au centre acceptant. 8.1.2.2.2. Recommandation Si les conditions de transfert sont jugées non standard, il convient de porter ce fait à l'attention du contrôleur transférant, pour confirmation ou modification. 8.1.2.3. Mesures à prendre au centre acceptant 8.1.2.3.1. Tous les messages ACT et REV doivent être vérifiés au moyen du filtre. 8.1.2.3.2. Si, après vérification, les conditions de transfert sont jugées non standard, elles doivent être soumises au contrôleur pour décision; autrement, elles sont acceptées automatiquement. 8.1.2.4. Synchronisation des filtres 8.1.2.4.1. L'emploi de messages différents pour les conditions de transfert standard et non standard permet de déceler d'éventuels écarts par rapport aux conditions standard détenues par les systèmes des organismes transférant et acceptant. 8.1.2.4.2. La mise en évidence, par l'organisme acceptant, de conditions de transfert non standard dans un message réservé à la coordination de transferts standard, signifie qu'il existe un écart entre les deux filtres. Les divergences doivent être résolues pour garantir l'efficacité de la procédure de dialogue. 8.1.3. Séquence des messages 8.1.3.1. Généralités 8.1.3.1.1. Il est nécessaire de suivre certaines règles pour s'assurer que la procédure de coordination est terminée avant d'effectuer certaines révisions ou échange de messages en vue du transfert de communication et éviter que les contrôleurs dans les deux organismes ne soumettent simultanément des propositions concernant le même vol. 8.1.3.1.2. Un organisme ATC doit transmettre un message de révision (REV or RRV) ou en accuser réception uniquement lorsque le vol a été coordonné, c'est-à-dire qu'un message LAM ou ACP a marqué la fin d'un dialogue ACT ou RAP. 8.1.3.1.3. Seul l'organisme acceptant doit être admis à envoyer des messages CDN. 8.1.3.1.4. Les messages CDN doivent uniquement être transmis et faire l'objet d'un accusé de réception: - dans le cadre d'un dialogue engagé après réception d'un message d'activation (ACT, RAP) ou de révision (REV or RRV); - lorsque le plan de vol en question a été coordonné. 8.1.4. Traitement simultané des messages 8.1.4.1. Généralités 8.1.4.1.1. Un organisme participant à un échange de messages de coordination ou de transfert pour un vol déterminé ne doit pas entreprendre un autre échange concernant le même vol avec le même organisme tant qu'il n'a pas reçu un message LAM, ACP ou RJC, ou qu'une temps imparti n'est pas arrivée à expiration. 8.1.4.1.2. Il est possible qu'un message CDN et un message REV, RRV ou MAC envoyé par l'organisme transférant concernant le même vol se croisent. L'organisme transférant peut le reconnaître au fait que le CDN lui parvient avant l'accusé de réception du message de coordination, l'organisme acceptant pouvant quant à lui le déduire du fait que le message de l'organisme transférant lui parvient avant l'accusé de réception du CDN. Dans ce cas, on ne doit pas accuser réception du CDN ni traiter les messages REV, RRV ou MAC. 8.1.5. Traitement des messages de rejet Le message RJC met fin à un dialogue entre systèmes. Une nouvelle coordination entre systèmes doit être engagée en tenant compte de la coordination téléphonique, le cas échéant. 8.1.6. Temps imparti pour réponse opérationnelle 8.1.6.1. Généralités 8.1.6.1.1. Un mécanisme de temps imparti doit être appliqué dans les centres émettant et recevants pour la réponse aux messages qui sont soumis à l'accord du contrôleur. 8.1.6.1.2. La durée de ces temps impartis doit être convenue bilatéralement. 8.1.6.1.3. L'expiration de la temps imparti dans le centre transférant doit donner lieu à un avertissement à l'intention du contrôleur du centre transférant pour lui indiquer qu'il doit engager une coordination par téléphone. 8.1.6.1.4. Recommandations 1. Il convient qu'un avertissement s'affiche au poste ATC du centre acceptant responsable du vol lorsque l'expiration du temps imparti dans le centre transférant est imminente. 2. Il convient que l'avertissement tienne compte du délai de transmission de la réponse. 8.1.6.1.5. Les systèmes doivent être en mesure de traiter les réponses parvenant après l'expiration du temps imparti. 8.1.7. Mise en oeuvre 8.1.7.1. Les procédures de dialogue s'appliquent à deux phases (coordination et transfert). Les messages et les temps de transaction nécessaires sont différents dans chacune des phases. Les messages de coordination sont présentés dans les formats OACI et ADEXP, les messages de transfert de contrôle le sont uniquement dans le format ADEXP. 8.1.7.2. Les caractéristiques HMI minimales requises pour le dialogue de coordination sont différentes de celles applicables au dialogue de transfert: - le dialogue de transfert traite principalement de la fonction de contrôle exécutif et nécessite une HMI rapide et conviviale; - le dialogue de coordination ne présente pas un caractère d'urgence aussi marqué et les caractéristiques HMI requises sont moins rigoureuses. 8.1.7.3. La procédure de dialogue doit être mise en oeuvre selon l'un des scénarios suivants: - procédure de dialogue pour la phase de coordination plus tout message complémentaire, suivant les dispositions arrêtées bilatéralement (Sections 7 et 8); - procédure de coordination de base et procédure de dialogue pour la phase de transfert (Sections 6, 7 and 9); - procédure de dialogue pour les phases de coordination et de transfert, plus tout autre message de coordination complémentaire, suivant les dispositions arrêtées bilatéralement (Sections 7, 8 and 9). Le message de préavis de franchissement de limite (ABI) doit être envoyé dans tous les scénarios précités. 8.1.7.4. Le scénario utilisé pour la mise en oeuvre doit faire l'objet d'un accord bilatéral. 8.2. Message d'activation (ACT) 8.2.1. Objet du message ACT L'objet du message ACT est décrit à l'alinéa 6.3.1. Dans une procédure de dialogue, le message ACT sert à répondre à ces besoins sous réserve que les conditions du vol soient standard et que le contrôleur transférant n'ait pas besoin de soumettre le vol au contrôleur acceptant, pour accord. 8.2.2. Composition du message La composition du message ACT utilisé dans la procédure de dialogue doit être conforme à celle décrite à l'alinéa 6.3.2. 8.2.3. Règles d'application 8.2.3.1. Généralités 8.2.3.1.1. Les règles d'application sont conformes à celles décrites pour les messages ACT à l'alinéa 6.3, à l'exception des dispositions particulières du présent paragraphe. 8.2.3.1.2. Un message ACT doit être envoyé dans le cas d'un vol dont les conditions de transfert sont standard et qui ne doit pas être soumis par le contrôleur transférant à l'accord du contrôleur acceptant.NOTE Si ces dispositions ne sont pas applicables, un message RAP est décrit à l'alinéa 8.3 Message de proposition d'activation soumis pour accord). 8.2.3.1.3. Recommandation Il convient qu'une nouvelle procédure de coordination soit engagée si un message de rejet de coordination (RJC) est renvoyé en réponse à un message ACT. 8.2.3.2. Traitement par l'organisme recevant 8.2.3.2.1. Le message est contrôlé au moyen du filtre afin de vérifier que les conditions proposées sont standard. 8.2.3.2.2. Il doit être traité en tant que message RAP si: - les conditions de transfert sont jugées non standard; - un plan de vol système correspondant ne peut être trouvé et que les informations disponibles sont insuffisantes pour déterminer si les conditions de transfert sont ou non standard. 8.2.3.2.3. Les messages ACT se rapportant à des conditions standard doivent être traitées conformément aux dispositions est décrit à l'alinéa 6.3.3.2. 8.2.3.2.4. Recommandation Si les conditions de transfert exposées dans un message ACT sont jugées non standard, il y a discordance entre les filtres des deux systèmes. Il convient de porter les messages ACT non standard à l'attention du personnel de supervision afin que ces discordances puissent être résolues. 8.2.4. Accusé de réception des messages ACT 8.2.4.1. Accusé de réception 8.2.4.1.1. Dans une procédure de dialogue, il est accusé réception d'un message ACT: - par un LAM, si les conditions de transfert sont jugées standard; - par un message SBY dans tous les autres cas. 8.2.4.1.2. Lorsqu'un LAM a été reçu, la teneur opérationnelle du message ACT doit devenir contraignante pour les deux organismes ATC. 8.2.4.1.3. Sous réserve d'accord bilatéral, un ACP peut remplacer un LAM pour indiquer qu'un ACT contenant des conditions de transfert standard a été accepté par l'organisme acceptant. 8.2.4.2. Absence d'accusé de réception En l'absence d'accusé de réception d'un message ACT, un avertissement doit s'afficher sur l'écran du poste ATC responsable de la coordination du vol. 8.3. Message de proposition d'activation soumise pour accord (RAP) 8.3.1. Objet du message RAP Le message RAP répond aux besoins opérationnels ci-après, en complément de ceux précisés pour le message ACT à l'alinéa 6.3: - permettre au contrôleur transférant de soumettre à l'accord du contrôlant acceptant des vols dont les conditions de transfert ne sont pas standard; - permettre au contrôleur transférant, si nécessaire, de forcer la présentation au contrôleur acceptant de conditions de transfert standard pour un vol donné. 8.3.2. Composition du message Le message RAP doit comprendre les mêmes données que celles décrites pour le message ACT (paragraphe 6.3) et peut comprendre, à titre facultatif, l'élément de données ci-après: - motif, avec indication de la présentation manuelle (uniquement possible en ADEXP). 8.3.3. Règles d'application 8.3.3.1. Généralités 8.3.3.1.1. Un message RAP doit être envoyé à la place du message ACT lorsque des vols franchissant la limite remplissent l'une des conditions suivantes: - le système de l'organisme transférant a déterminé que les conditions de transfert ne sont pas standard; - le contrôleur transférant a indiqué que les conditions de transfert proposées doivent être soumises à l'accord du contrôleur acceptant. 8.3.3.1.2. La teneur opérationnelle du message RAP sur le point d'être transmis doit s'afficher au poste de travail chargé de la coordination du vol avant la transmission effective. 8.3.3.1.3. Recommandation Il convient que l'heure de transmission et la teneur du message RAP s'affichent sur les écrans des postes de travail concernés. 8.3.3.1.4. Le poste de travail concerné doit être avisé de la transmission du message RAP. 8.3.3.2. Traitement par l'organisme recevant 8.3.3.2.1. Le système ATC qui reçoit un message RAP doit tenter de l'associer au plan de vol correspondant. 8.3.3.2.2. Si le plan de vol correspondant est trouvé et que le message ne présente aucune anomalie susceptible d'empêcher qu'il ne soit traité correctement: - la teneur opérationnelle du message doit être soumise à l'accord du contrôleur acceptant; - un message SBY doit être envoyé en retour. 8.3.3.2.3. Recommandation Il convient d'indiquer le motif (conditions non standard ou présentation manuelle) de la présentation pour accord. 8.3.3.2.4. Si le message ne peut être associé à un plan de vol ou s'il présente une anomalie susceptible d'empêcher qu'il ne soit traité correctement: - la teneur opérationnelle du message doit s'afficher sur les écrans dans le secteur concerné; - un message SBY doit être envoyé en retour; - un plan de vol doit être créé. 8.3.3.2.5. Dans tous les autres cas, le message ne doit pas faire l'objet d'un accusé de réception. 8.3.3.3. Déclenchement manuel 8.3.3.3.1. Lorsque le message RAP est utilisé pour forcer la présentation, au contrôleur acceptant, d'une proposition de coordination dans le cas de conditions de transfert standard, le message est déclenché manuellement par le contrôleur transférant et transmis immédiatement. 8.3.3.3.2. Recommandation Il convient d'autoriser le poste responsable de la coordination du vol à déclencher manuellement un message RAP avant l'heure prévue de transmission. 8.3.3.4. Paramètres de temps pour la transmission automatique Le délai ou la distance par rapport à la limite entre organismes auquel les messages RAP sont automatiquement transmis sont identiques à ceux des messages ACT. 8.3.4. Accusé de réception du RAP 8.3.4.1. Accusé de réception Il doit être accusé réception du message par la production et la transmission d'un message SBY. 8.3.4.2. Absence d'accusé de réception En l'absence de message SBY accusant réception d'un message RAP, un avertissement doit s'afficher au poste ATC responsable de la coordination du vol. 8.3.5. Réponse opérationnelle au RAP Le contrôleur acceptant peut soit accepter, soit rejeter les conditions de transfert, soit soumettre une contre-proposition. 8.3.5.1. Acceptation 8.3.5.1.1. Lorsque le contrôleur acceptant choisit d'accepter les conditions de transfert proposées, un message ACP doit être envoyé en retour. 8.3.5.1.2. Dès réception du message ACP, les données du message RAP deviennent contraignantes pour les deux organismes ATC. Le contrôleur transférant doit être informé des conditions de transfert coordonnées et de la réception de l'ACP. 8.3.5.2. Contre-proposition Lorsque le contrôleur acceptant choisit de soumettre une contre-proposition de conditions de transfert, un message CDN doit être envoyé. 8.3.5.3. Recommandation Lorsque le contrôleur acceptant choisit de rejeter les conditions de transfert proposées, il convient d'envoyer un message RJC en retour et d'engager alors un nouveau processus de coordination.NOTE En ce qui concerne la recommandation de l'alinéa 8.3.5.3, la nouvelle coordination se déroulera le plus souvent avec un organisme différent. 8.3.6. Exemples 8.3.6.1. OACI (RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M) 8.3.6.2. ADEXP -TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 8.4. Message de révision (REV) 8.4.1. Objet du message REV L'objet du message REV est décrit à l'alinéa 7.3.1. Dans une procédure de dialogue, le message REV sert à répondre à ces besoins, sous réserve que les conditions du vol soient standard et que le contrôleur transférant n'ait pas besoin de soumettre le vol au contrôleur acceptant, pour accord. 8.4.2. Composition du message La composition du message REV doit être conforme à celle décrite à l'alinéa 7.3.2. 8.4.3. Règles d'application 8.4.3.1. Généralités 8.4.3.1.1. Un ou plusieurs messages REV peuvent être envoyés à l'organisme avec lequel la coordination d'un vol est en cours au moyen d'un message d'activation ou d'un message RAP. 8.4.3.1.2. Les messages REV doivent être envoyés selon les modalités prévues à l'alinéa 7.3.3.1 dans le cas de vols dont les conditions de transfert sont standard et n'obligent pas le contrôleur transférant à les soumettre à l'accord du contrôleur acceptant. 8.4.3.2. Déclenchement de la transmission Le message REV doit être transmis immédiatement après détection d'un changement des données de coordination nécessitant une coordination, selon les modalités décrites à l'alinéa 7.3.3. 8.4.3.3. Traitement par l'organisme recevant 8.4.3.3.1. Si un plan de vol correspondant est trouvé en état "coordonné" et qu'aucune anomalie ne risque d'empêcher que le message ne soit traité correctement: - le message REV doit faire l'objet d'un accusé de réception; - dans tous les autres cas, aucun accusé de réception ne doit être envoyé. 8.4.3.3.2. Les conditions de transfert doivent être examinées afin de s'assurer qu'elles sont standard. 8.4.3.3.3. Si les conditions de transfert ne sont pas standard, elles doivent être soumises à l'accord du contrôleur acceptant. 8.4.3.3.4. Si les conditions de transfert proposées sont jugées standard, elles doivent être jointes au plan de vol ainsi qu'aux données nécessaires produites aux postes opérationnels ATC et autres, suivant les besoins. 8.4.3.3.5. Recommandation Si les conditions de transfert d'un message REV sont jugées non standard, il y a discordance entre les filtres des deux systèmes. Il convient de porter les message REV non standard à l'attention du personnel d'encadrement afin que ces discordances puissent être résolues. 8.4.4. Accusé de réception du REV 8.4.4.1. Accusé de réception 8.4.4.1.1. L'accusé de réception du message REV, s'il est nécessaire, doit prendre la forme suivante: - un message LAM si les conditions de transfert sont jugées standard; - un message SBY si les conditions de transfert sont jugées non standard. 8.4.4.1.2. Dès réception d'un LAM, la teneur opérationnelle du message REV devient contraignante pour les deux organismes ATC. 8.4.4.1.3. Sous réserve d'accord bilatéral, un ACP peut remplacer un LAM pour indiquer que l'organisme acceptant accepte un REV contenant des conditions de transfert standard. 8.4.4.2. Absence d'accusé de réception En l'absence d'accusé de réception d'un message REV, un avertissement doit s'afficher au poste ATC responsable de la coordination des vols. 8.4.5. Réponse opérationnelle au REV Comme le message REV sert à notifier des conditions de transfert standard, il sera normalement accepté par le système de l'organisme acceptant. Si, après l'opération de filtrage dans l'organisme acceptant, les conditions de transfert sont jugées non standard, le message doit être traité comme un message RRV. 8.5. Message de proposition de révision soumis pour accord (RRV) 8.5.1. Objet du message RRV Le message RRV doit permettre de réviser les conditions de transfert précédemment transmises et approuvées, dans les cas suivants: - lorsque les conditions de transfert proposées dans la révision sont non standard; - lorsque la révision proposée est standard mais que le contrôleur transférant souhaite soumettre la révision à l'accord du contrôleur acceptant. 8.5.2. Composition du message La composition du message RRV doit être conforme à celle du message REV (exposée à l'alinéa 7.3.2) et peut comporter, à titre facultatif, les éléments suivants: - motif, indiquant une présentation manuelle (uniquement possible en ADEXP). 8.5.3. Règles d'application 8.5.3.1. Généralités Un ou plusieurs messages RRV doivent être envoyés en remplacement des messages REV, pour chaque révision, dans l'un des cas suivants: - le système transférant a établi que les conditions de transfert sont non standard; - le contrôleur transférant a indiqué que les conditions de transfert proposées doivent être soumises à l'accord du contrôleur acceptant. L'emploi du RRV dans ce cas est facultatif. 8.5.3.2. Déclenchement de la transmission Le message RRV doit être transmis dès qu'un changement des données de coordination est constaté ou être déclenché manuellement. 8.5.3.3. Traitement par l'organisme recevant 8.5.3.3.1. Si un plan de vol correspondant est trouvé dans l'état "coordonné" et qu'aucune anomalie n'est décelée qui empêcherait que le message ne soit traité correctement: - le message RRV doit faire l'objet d'un accusé de réception; - dans tous les autres cas, aucun accusé de réception du message ne doit être envoyé. 8.5.3.3.2. Les conditions de transfert proposées doivent s'afficher sur les écrans du poste ATC responsable de la coordination du vol. 8.5.3.3.3. Recommandation Il convient d'indiquer le motif de l'accord sollicité (conditions non standard ou présentation manuelle). 8.5.4. Accusé de réception du RRV 8.5.4.1. Accusé de réception Le message doit faire l'objet d'un accusé de réception par la production et la transmission d'un message SBY. 8.5.4.2. Absence d'accusé de réception En l'absence de message SBY accusant réception d'un message RRV, un avertissement doit s'afficher au poste ATC responsable de la coordination du vol. 8.5.5. Réponse opérationnelle au RRV Le contrôleur acceptant peut soit accepter, soit refuser un message RRV, soit soumettre une contre-proposition. 8.5.5.1. Acceptation Lorsque le contrôleur acceptant choisit d'accepter la proposition de modification des conditions de transfert agréées, un message ACP doit être envoyé en retour. 8.5.5.2. Contre-proposition Lorsque le contrôleur acceptant choisit de soumettre une contre-proposition, un message CDN doit être envoyé en retour. 8.5.5.3. Rejet Lorsque le contrôleur acceptant choisit de rejeter la proposition de modification des conditions de transfert agréées: - un message RJC doit être envoyé en retour; - un nouveau processus de coordination doit être engagé. 8.5.6. Exemples 8.5.6.1. OACI (RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB) 8.5.6.2. ADEXP -TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB 8.6. Message d'attente de transfert (SBY) 8.6.1. Objet du message SBY Le message SBY accuse réception d'un message proposant des conditions de transfert et indique que la proposition est soumise au contrôleur, pour décision. 8.6.2. Composition du message Le message SBY doit comprendre les éléments de données suivants: - type de message; - numéro du message; - référence du message; NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 8.6.3. Règles d'application 8.6.3.1. Généralités Le message SBY doit être produit et transmis automatiquement dès réception: - d'un message RAP, RRV ou CDN; - d'un message ACT ou REV qui ne passe pas avec succès l'épreuve du filtre. 8.6.4. Accusé de réception du SBY Le message SBY ne doit faire l'objet d'aucun accusé de réception. 8.6.5. Exemples 8.6.5.1. OACI (SBYL/E027E/L002) 8.6.5.2. ADEXP -TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 8.7. Message d'acceptation (ACP) 8.7.1. Objet du message ACP Le message ACP répond aux besoins opérationnels ci-après, pendant les phases de coordination et de transfert ATC: - indiquer qu'un contrôleur d'un organisme accepte manuellement les conditions de transfert proposées par le contrôleur de l'autre organisme dans un message des catégories suivantes: - RAP; - RRV; - CDN; - ACT et REV, si l'un ou l'autre est jugé non standard; - sous réserve d'accord bilatéral, permettre l'acceptation automatique d'un message ACT ou REV qui a subi avec succès l'épreuve du filtre du centre acceptant (en remplacement du message LAM); - sous réserve d'accord bilatéral, indiquer l'acceptation manuelle d'un message HOP (en remplacement du message ROF). 8.7.2. Composition du message Le message ACP doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - référence du message; - Données facultatives: - fréquence; - Données facultatives au format OACI - le message peut aussi contenir tous les éléments suivants: - identification de l'aéronef; - aérodrome de départ; - aérodrome de destination. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 8.7.3. Règles d'application 8.7.3.1. Généralités 8.7.3.1.1. La référence du message ACP doit comprendre le numéro du message auquel l'ACP répond. 8.7.3.1.2. Le champ Fréquence, s'il est inclus, doit indiquer la fréquence sur laquelle l'aéronef doit contacter l'organisme acceptant au moment du transfert de contrôle. 8.7.3.1.3. Le message ACP doit être envoyé après acceptation manuelle, par le contrôleur, des conditions de transfert proposées dans un message ACT, RAP, REV, RRV ou CDN. 8.7.3.1.4. Le message ACP peut être envoyé à la place d'un message ROF en réponse à un message HOP. 8.7.3.1.5. Sous réserve d'accord bilatéral, le message ACP doit être produit et transmis automatiquement par le système en réponse à un message ACT/REV ayant subi avec succès l'épreuve du filtre. 8.7.3.1.6. Dès réception d'un ACP, les conditions de transfert agréées deviennent contraignantes pour les deux organismes. 8.7.3.2. Traitement par l'organisme recevant 8.7.3.2.1. Le système ATC qui reçoit un message ACP doit tenter de l'associer avec le plan de vol correspondant. 8.7.3.2.2. Si l'ACP peut être associé à un plan de vol, l'acceptation doit être indiquée au contrôleur. 8.7.3.2.3. Si l'ACP ne peut être associé à un plan de vol: - un avertissement doit être donné au poste de travail approprié; - un LAM ne doit pas être envoyé. 8.7.4. Accusé de réception de l'ACP 8.7.4.1. Accusé de réception 8.7.4.1.1. Un LAM ne doit pas être envoyé en retour lorsque l'ACP sert de réponse automatique pour un message ACT ou REV qui a subi avec succès l'épreuve du filtre. 8.7.4.1.2. Un message ACP envoyé à la suite d'une acceptation manuelle doit faire l'objet d'un accusé de réception par la production et la transmission d'un message LAM. 8.7.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message ACP envoyé à la suite d'une acceptation manuelle, un avertissement doit s'afficher au poste ATC responsable de la coordination du vol. 8.7.5. Exemples 8.7.5.1. OACI (ACPL/E027E/L002-18/FRQ/242150) 8.7.5.2. ADEXP -TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -FREQ 242150 8.8. Message de coordination (CDN) 8.8.1. Objet du message CDN Le message CDN répond aux besoins opérationnels suivants: - transmettre une contre-proposition soumise par le contrôleur acceptant au contrôleur transférant en réponse à un message ACT, RAP, REV ou RRV; - permettre au contrôleur acceptant de soumettre au contrôleur transférant une proposition de modification des conditions de transfert agréées. 8.8.2. Composition du message Le message CDN doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - référence du message (uniquement s'il s'agit d'une réponse à un autre message); - identification de l'aéronef; - aérodrome de départ; - aérodrome de destination; NOTE Le message doit également l'un, ou les deux, des éléments suivants: - données d'estimées (dans le cas d'un message au format OACI) ou niveau de transfert (s'il s'agit d'un message ADEXP); - demande d'acheminement direct. - Données agréées au niveau bilatéral. La donnée suivante peut aussi être incluse: - fréquence. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A 8.8.3. Règles d'application 8.8.3.1. Généralités 8.8.3.1.1. Seul le contrôleur acceptant peut envoyer des messages CDN. 8.8.3.1.2. Le message CDN doit servir à transmettre une contre-proposition soumise par le contrôleur acceptant au contrôleur transférant.NOTE Il peut s'agir d'un dialogue en réponse à une proposition transmise par un message ACT, RAP, REV ou RRV, ou bien du début d'un dialogue en vue de modifier les conditions de transfert précédemment agréées. 8.8.3.1.3. La référence du message ne doit figurer que lorsque le message CDN est envoyé en réponse à un autre message. 8.8.3.1.4. La référence du message, lorsqu'elle est indiquée, doit comprendre le numéro du message auquel le CDN répond. 8.8.3.1.5. Le service de demande d'acheminement direct (dont un descriptif détaillé figure en Annexe A): - ne doit être utilisé que si son emploi a fait l'objet d'un accord bilatéral; - si tel est le cas, les limites opérationnelles à son emploi doivent être définies. 8.8.3.1.6. Le message CDN ne doit pas être envoyé au-delà d'un délai ou d'une distance par rapport à la limite, dont la valeur est précisée dans la Lettre d'accord entre les organismes intéressés. 8.8.3.1.7. Si un CDN se trouve transmis en même temps qu'un message du centre transférant concernant le même vol, par exemple dans le cas d'une révision ou d'une abrogation de coordination, aucun accusé de réception ni réponse opérationnelle ne doit être envoyé en retour.NOTE Cela signifie que si deux messages se croisent, celui de l'organisme transférant a priorité et le CDN est abandonné par les deux parties. Les deux organismes peuvent pressentir une telle situation s'ils reçoivent le message de l'autre avant d'avoir reçu l'accusé de réception. 8.8.3.1.8. Dès réception de l'acceptation, les données du message CDN deviennent contraignantes sur le plan opérationnel pour les deux organismes ATC. Le personnel ATC concerné doit être informé des conditions de transfert coordonnées et de la réception de l'ACP. 8.8.3.2. Traitement par l'Organisme recevant 8.8.3.2.1. Si le système trouve un plan de vol correspondant et que le message ne présente aucune anomalie susceptible d'empêcher qu'il ne soit traité correctement: - le contenu opérationnel du message doit être soumise au poste ATC responsable de la coordination du vol; - un message SBY doit être envoyé en retour. 8.8.3.2.2. Si le CDN ne peut être associé ou si une anomalie est constatée qui empêche que le message ne soit traité correctement, aucun SBY ne doit être envoyé en retour. 8.8.4. Accusé de réception du CDN 8.8.4.1. Accusé de réception Dans les conditions précisées plus haut, il doit être accusé réception d'un message CDN par la production et la transmission d'un message SBY. 8.8.4.2. Absence d'accusé de réception En l'absence de message SBY accusant réception d'un message CDN, un avertissement doit s'afficher au poste ATC responsable de la coordination du vol. 8.8.5. Réponse opérationnelle au CDN Le contrôleur peut soit accepter, soit rejeter les conditions proposées dans un message CDN. 8.8.5.1. Acceptation Lorsque le contrôleur transférant choisit d'accepter les conditions de transfert proposées, un message ACP doit être envoyé en retour. 8.8.5.2. Recommandation Lorsque le contrôleur transférant choisit de rejeter les conditions de transfert proposées, il convient qu'un message RJC (rejet explicite) soit envoyé. NOTE La coordination proposée est implicitement rejetée si aucune acceptation n'a été reçue lorsque la temps imparti arrive à expiration. 8.8.6. Exemples 8.8.6.1. OACI (CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -EBBR) 8.8.6.2. ADEXP -TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -PROPFL -TFL F270 -SFL F110A 8.9. Message de rejet de coordination (RJC) 8.9.1. Objet du message RJC Le message RJC indique qu'un contrôleur d'un organisme donné a rejeté les conditions de transfert proposées par le contrôleur de l'autre organisme dans l'un des messages suivants: - RAP; - RRV; - CDN; - ACT et REV, si l'un ou l'autre est jugé non standard. Le message RJC ne peut être utilisé qu'en réponse directe à l'un des messages ci-dessus. 8.9.2. Composition du message Le message RJC doit comprendre les éléments suivants: - type de message; - numéro du message; - référence du message. NOTE Les règles d'introduction des données ainsi que les formats et la teneur des champs sont précisés à l'Annexe A. 8.9.3. Règles d'application 8.9.3.1. Généralités 8.9.3.1.1. Le RJC doit être envoyé, suivant les besoins, en réponse à un message RAP, RRV, CDN, ou à un message ACT ou REV jugé non standard par l'organisme acceptant. 8.9.3.1.2. Le message RJC met fin au dialogue système et toute coordination agréée auparavant demeure valable. 8.9.3.1.3. Recommandation Dès réception d'un message RJC, il convient qu'une nouvelle séquence de coordination soit engagée, tenant compte le cas échéant de la coordination par téléphone. 8.9.3.2. Traitement par l'organisme recevant 8.9.3.2.1. Si le système trouve un message correspondant au message auquel le RJC fait référence: - le rejet doit être indiqué au poste ATC responsable de la coordination du vol en question; - un LAM doit être envoyé en retour, à titre d'accusé de réception. 8.9.3.2.2. Si le système ne trouve aucun message de ce type en attente de réponse ou que le message présente une anomalie qui ne permet pas de le traiter, aucun accusé de réception ne doit être envoyé. 8.9.4. Accusé de réception du RJC 8.9.4.1. Accusé de réception Il doit être accusé réception d'un message RJC par la production et la transmission d'un message LAM. 8.9.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message RJC, un avertissement doit s'afficher au poste ATC responsable de la coordination des vols. 8.9.5. Exemples 8.9.5.1. OACI (RJCMC/E746E/MC324) 8.9.5.2. ADEXP -TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E -SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC MC -SEQNUM 324 9. PROCÉDURE DE DIALOGUE - TRANSFERT DE COMMUNICATION 9.1. Généralités 9.1.1. Introduction 9.1.1.1. La présente section traite des services et messages à l'appui des éléments radar de la procédure de transfert de contrôle. Les dispositions doivent être appliquées lorsqu'elles ont fait l'objet d'un accord bilatéral. 9.1.1.2. Les mécanismes de transfert de communication ne doivent pas être mis en oeuvre si l'organisme n'utilise pas, soit les mécanismes de coordination décrits à la Section 6 (Procédure de base - Messages obligatoires), soit ceux de la Section 8 (Procédure de dialogue - Coordination). 9.1.1.3. Les messages décrits dans cette section ne sont disponibles que dans le format ADEXP et il n'est pas prévu de les rendre disponibles en format OACI. 9.1.2. Séquence de messages 9.1.2.1. L'échange de messages de transfert de communication, en dehors du message de données supplémentaires (SDM), ne doit avoir lieu qu'une fois la coordination achevée, c'est-à-dire qu'un message LAM ou ACP a mis un terme à un dialogue ACT ou RAP. 9.1.2.2. Aucun accusé de réception ne doit être renvoyé tant que la coordination est en cours. 9.1.3. Transfert de communications 9.1.3.1. Les deux organismes intéressés doivent convenir ensemble de la méthode de notification du transfert réel des communications pour un vol donné. 9.1.3.2. L'une des conditions suivantes ou les deux doivent être réunies: - l'organisme transférant envoie un message de changement de fréquence (COF); - l'organisme acceptant envoie un message de prise en charge manuelle des communications (MAS); 9.1.3.3. Les deux organismes doivent s'entendre sur la méthode à appliquer pour chaque courant de trafic.NOTE D'autres méthodes peuvent être appliquées pour différents courants de trafic, par exemple un organisme peut produire des messages COF pour les vols quittant son espace aérien et des messages MAS pour ceux qui y entrent. Dans ce cas, l'autre organisme n'aurait pas besoin d'introduire de message pour signifier le transfert de communications. 9.2. Message de déclenchement de transfert (TIM) 9.2.1. Objet du message TIM Le message TIM a pour objet: - de signifier l'événement déclenchant le transfert (TI) (fin de la phase de coordination et début de la phase de transfert); - de transmettre simultanément les données de contrôle exécutif de l'organisme transférant à l'organisme acceptant. 9.2.2. Composition du message Le message TIM doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - identification de l'aéronef; - Données disponibles, le cas échéant: - niveau de vol autorisé; - cap assigné ou autorisation d'acheminement direct; - vitesse assignée; - vitesse ascensionnelle ou descensionnelle autorisée; - Données facultatives: - position. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.2.3. Règles d'application 9.2.3.1. Généralités 9.2.3.1.1. Le message TIM doit être produit et transmis par l'organisme transférant à l'organisme acceptant sans intervention humaine à une distance ou dans un délai par rapport à la limite dont la valeur est fixée bilatéralement. 9.2.3.1.2. Un message TIM doit aussi être envoyé automatiquement lorsque l'organisme transférant reçoit un message de demande de changement de fréquence (ROF). 9.2.3.1.3. Un message TIM ne doit pas être envoyé avant que le vol n'ait été coordonné. 9.2.3.1.4. Le message TIM doit comprendre les données les plus récentes dont le système dispose. 9.2.3.2. Paramètre de temps applicable à la transmission 9.2.3.2.1. Le paramètre de production du TIM doit être variable et pouvoir être modifié sur la base des dispositions de la lettre d'accord. 9.2.3.2.2. Recommandation Il convient que le paramètre système de production du message TIM soit défini séparément pour chaque COP. 9.2.3.2.3. Les partenaires de la coordination doivent inclure le paramètre de production du TIM dans leur lettre d'accord. 9.2.3.2.4. Le paramètre système déclenchant le message TIM peut être lié à la vitesse au sol de l'aéronef telle qu'elle est calculée. Toutefois, le message TIM doit toujours être initié avant que l'aéronef, selon le plan de vol en vigueur, n'atteigne une certaine distance du COP, d'une valeur minimale convenue bilatéralement. 9.2.3.2.5. Le paramètre système spécifié pour la transmission du TIM doit laisser suffisamment de temps pour qu'une coordination verbale ait lieu avant le transfert. 9.2.3.3. Traitement par l'organisme recevant 9.2.3.3.1. Les données reçues dans un message TIM doivent être communiquées au contrôleur acceptant. 9.2.4. Accusé de réception du TIM 9.2.4.1. Accusé de réception Si le message TIM: - peut être associé, sans ambiguïté, à un plan de vol, le système doit en accuser réception par la production et la transmission d'un message LAM; - ne peut être associé, sans ambiguïté, à un plan de vol, aucun accusé de réception ne doit être envoyé. 9.2.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message TIM, un avertissement doit s'afficher au poste de travail concerné. 9.2.5. Exemple -TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253 9.3. Message de données supplémentaires (SDM) 9.3.1. Objet du message SDM 9.3.1.1. Généralités 9.3.1.1.1. Le message SDM a pour principal objet la transmission, par l'organisme transférant à l'organisme acceptant, des données de contrôle et des changement qui y sont apportés; à condition qu'il ait été convenu bilatéralement que le contrôleur acceptant n'a pas besoin d'accuser réception des changements. 9.3.1.1.2. Le message SDM peut également être utilisé par l'organisme acceptant pour notifier à l'organisme transférant la fréquence radiotéléphonique sur laquelle le vol doit être transféré. 9.3.2. Composition du message 9.3.2.1. Message de l'organisme transférant Le message SDM doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - identification de l'aéronef; - Données supplémentaires: - cap assigné ou autorisation d'acheminement direct; - vitesse assignée; - vitesse ascensionnelle ou descensionnelle autorisée; - niveau de vol autorisé; 9.3.2.2. Message de l'organisme acceptant Le message SDM doit comprendre les éléments suivants: - type de message; - numéro du message; - identification de l'aéronef; - fréquence. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.3.3. Règles d'application 9.3.3.1. Message de l'organisme transférant 9.3.3.1.1. Les messages SDM doivent être transmis après engagement de la phase de transfert (voir TIM, paragraphe 9.2) lorsque l'un des éléments ci-après est modifié: - niveau de vol autorisé; - vitesse assignée; - vitesse ascensionnelle ou descensionnelle autorisée; - cap assigné; - autorisation ou changement d'autorisation permettant au vol de se rendre directement vers un point spécifié. NOTE Le message HOP doit être utilisé lorsque l'approbation du contrôleur acceptant est nécessaire avant le transfert de communication. 9.3.3.1.2. Le message ne doit comporter que les champs qui ont été modifiés. 9.3.3.1.3. Les messages SDM contenant les données décrites à l'alinéa 9.3.3.1.1 doivent être transmis avant le TI, s'il en a été convenu ainsi bilatéralement. 9.3.3.1.4. La transmission de ces messages doit commencer à un moment arrêté bilatéralement par rapport au TI, à condition qu'il s'agisse de données pour lesquelles le système dispose d'une valeur. 9.3.3.2. Messages de l'organisme acceptant 9.3.3.2.1. Des messages SDM peuvent être transmis pour indiquer la fréquence sur laquelle le vol doit contacter l'organisme acceptant.NOTE Les organismes peuvent convenir entre eux de s'échanger d'autres informations. Ces transferts n'étant pas définis, ils n'entrent pas dans le cadre de la présente Norme. 9.3.3.2.2. Les messages SDM de l'organisme acceptant doivent être transmis pendant la phase de coordination, s'il en a été convenu ainsi bilatéralement. 9.3.3.3. Traitement par l'organisme recevant 9.3.3.3.1. Le système ATC qui reçoit un message SDM doit tenter de l'associer au plan de vol correspondant. 9.3.3.3.2. Si un plan de vol correspondant en état "coordonné" est trouvé: - un LAM doit être envoyé en retour; - la teneur opérationnelle du message SDM doit être communiquée au contrôleur compétent. 9.3.3.3.3. Si un plan de vol correspondant ne peut être trouvé ou s'il existe une anomalie empêchant que le message ne soit traité correctement: - aucun message LAM ne doit être envoyé en retour; - un avertissement doit être donné au poste de travail concerné. 9.3.4. Accusé de réception du SDM 9.3.4.1. Accusé de réception Il doit être accusé réception d'un message SDM par la production et la transmission d'un message LAM. 9.3.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message SDM, un avertissement doit s'afficher au poste de travail concerné. 9.3.5. Exemple -TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290 9.4. Proposition de transfert de vol (HOP) 9.4.1. Objet du message HOP L'objet du message HOP est le suivant: - permettre au contrôleur transférant d'appeler l'attention du contrôleur acceptant sur un vol donné à des fins de transfert; - permettre au contrôleur transférant de proposer le transfert du vol au contrôleur acceptant au moment opportun; - transmettre les données de contrôle exécutif qui doivent être approuvées par le contrôleur acceptant, suivant les modalités convenues bilatéralement. Il n'est pas nécessaire d'utiliser le message HOP pour tous les vols, l'emploi en étant laissé à la discrétion du contrôleur transférant.NOTE En ce qui concerne l'alinéa c) ci-dessus, le SDM sert à transmettre les modifications apportées aux données de contrôle exécutif qui ne nécessitent pas l'approbation du contrôleur acceptant. 9.4.2. Composition du message Le message HOP doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - identification de l'aéronef; - Données disponibles - le message doit aussi contenir les données suivantes, si disponibles: - niveau de vol autorisé; - cap assigné / autorisation d'acheminement direct; - vitesse assignée; - vitesse ascensionnelle ou descensionnelle autorisée; - Données facultatives - le message peut aussi inclure: - position. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.4.3. Règles d'application 9.4.3.1. Généralités 9.4.3.1.1. Le message HOP, lorsqu'il est utilisé, doit être déclenché manuellement par le contrôleur transférant. 9.4.3.1.2. Le message HOP doit inclure toutes les données de vol décrites à l'alinéa 9.4.2 ci-dessus qui ont été modifiées par rapport aux informations précédemment transmises. 9.4.3.1.3. Si un message HOP est envoyé avant le TI, la phase de transfert doit être engagée. NOTE Un message TIM n'est pas nécessaire, en plus d'un message HOP. 9.4.3.1.4. Les organismes doivent convenir entre eux du moment (calculé en temps ou en distance par rapport au COP ou à la limite) à partir duquel un COP peut être envoyé, au plus tôt. 9.4.3.1.5. Recommandation Il convient de spécifier le délai/la distance séparément pour chaque COP. 9.4.3.2. Traitement par l'organisme recevant 9.4.3.2.1. Le système ATC qui reçoit un message HOP doit tenter d'associer le message avec le plan de vol correspondant. 9.4.3.2.2. Les données de vol reçues dans le message doivent s'afficher immédiatement sur l'écran du contrôleur acceptant. 9.4.3.2.3. Si le contrôleur acceptant décide d'accepter le vol selon les conditions proposées dans le message HOP, un message ROF peut être envoyé en réponse à l'organisme transférant. Un ACP peut être envoyé en réponse à un HOP sous réserve d'accord bilatéral. 9.4.3.2.4. Si le contrôleur acceptant n'est pas en mesure d'accepter le vol, le transfert doit faire l'objet d'un accord verbal.NOTE En raison de l'urgence de la procédure de transfert, un suivi automatisé du renvoi du ROF ( ou de l'ACP) n'est pas requis par la présente Norme; on suppose que le contrôleur transférant constatera l'absence de réponse de la part du contrôleur acceptant et prendra les mesures nécessaires. Toutefois, rien n'empêche que le contrôleur transférant en soit averti, si cela est nécessaire sur le plan opérationnel. 9.4.3.2.5. Dès réception d'un ROF (ou d'un ACP), les données du message HOP doivent avoir valeur contraignante sur le plan opérationnel pour les deux organismes ATC. 9.4.4. Accusé de réception du HOP 9.4.4.1. Accusé de réception Si le message HOP peut être associé à un plan de vol, il doit faire l'objet d'un accusé de réception automatique par un LAM. 9.4.4.2. Absence d'accusé de réception En l'absence de LAM accusant réception d'un message HOP, un avertissement doit s'afficher au poste de travail compétent. 9.4.5. Exemple -TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ 9.5. Message de demande de changement de fréquence (ROF) 9.5.1. Objet du message ROF Le message ROF est envoyé par l'organisme acceptant à l'organisme transférant pour demander, suivant les besoins, au contrôleur transférant d'inviter l'aéronef à passer sur la fréquence du contrôleur acceptant. Il peut être utilisé: - en réponse à un message HOP, pour signifier l'acceptation du vol dans les conditions proposées; - pour solliciter le transfert anticipé du vol. 9.5.2. Composition du message Le message ROF doit comprendre les éléments suivants: - Données obligatoires: - type de message; - numéro du message; - identification de l'aéronef; - Données facultatives: - fréquence. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.5.3. Règles d'application 9.5.3.1. Généralités 9.5.3.1.1. Le message ROF doit être déclenché manuellement par le contrôleur acceptant. 9.5.3.1.2. Le contrôleur acceptant peut déclencher un ROF, soit: - lorsque le contrôleur acceptant demande le passage anticipé de l'aéronef sur sa fréquence; - en réponse à un message HOP. 9.5.3.2. Traitement par l'organisme recevant 9.5.3.2.1. Le système ATC qui reçoit un message ROF doit tenter de l'associer avec le plan de vol correspondant. 9.5.3.2.2. La réception du ROF doit être signalée au contrôleur transférant sans retard. 9.5.3.2.3. Si le vol n'est pas en phase de transfert, celle-ci doit être déclenchée et un message TIM doit être transmis. 9.5.4. Accusé de réception du ROF 9.5.4.1. Accusé de réception 9.5.4.1.1. Si le message ROF peut être associé, sans ambiguïté, avec un plan de vol, le système doit en accuser réception par la production et la transmission d'un message LAM. 9.5.4.1.2. Si le message ROF ne peut être associé, sans ambiguïté, avec un plan de vol, aucun accusé de réception ne doit être envoyé. 9.5.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message ROF, un avertissement doit s'afficher au poste ATC compétent. 9.5.5. Exemple -TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.6. Message de changement de fréquence (COF) 9.6.1. Objet du message COF 9.6.1.1. Généralités 9.6.1.1.1. Le COF est envoyé par l'organisme transférant à l'organisme acceptant pour indiquer que le vol a reçu pour instructions de contacter le contrôleur acceptant. 9.6.1.1.2. Le message peut prévoir la possibilité pour le contrôleur transférant de libérer le vol des conditions de transfert agréées lorsqu'il a établi la radiocommunication avec le contrôleur acceptant. 9.6.2. Composition du message Le message COF doit comprendre les éléments suivants: - Données obligatoires: - type du message; - numéro de message; - identification de l'aéronef; - Données éventuellement disponibles: - indication de transfert anticipé; - fréquence; - niveau de vol autorisé; - cap assigné ou autorisation d'acheminement direct; - vitesse assignée; - vitesse ascensionnelle ou descensionnelle autorisée; - Données facultatives: - position. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.6.3. Règles d'application 9.6.3.1. Généralités 9.6.3.1.1. Le message COF doit être déclenché manuellement par le contrôleur acceptant. 9.6.3.1.2. L'utilisation du message COF est obligatoire si, par accord bilatéral, le message MAS n'est pas employé. 9.6.3.1.3. Si un message COF est envoyé avant le TI, la phase de transfert doit être engagée.NOTE Un message TIM n'est pas nécessaire, en plus du message COF. 9.6.3.2. Traitement par l'organisme recevant 9.6.3.2.1. Le système ATC qui reçoit un message COF doit tenter de l'associer avec le plan de vol correspondant. 9.6.3.2.2. La réception du COF doit être signalée au contrôleur acceptant sans retard. 9.6.4. Accusé de réception du COF 9.6.4.1. Accusé de réception 9.6.4.1.1. Si le message COF peut être associé, sans ambiguïté, avec un plan de vol, le système doit en accuser réception par la production et de la transmission d'un message LAM. 9.6.4.1.2. Si le message COF ne peut être associé, sans ambiguïté, avec un plan de vol, aucun accusé de réception ne doit être envoyé. 9.6.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message COF, un avertissement doit s'afficher au poste de travail ATC compétent. 9.6.5. Exemples -TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.7. Message de prise en charge manuelle des communications (MAS) 9.7.1. Objet du message MAS Le message MAS est envoyé par l'organisme acceptant à l'organisme transférant pour indiquer que le contact radio bidirectionnel a été établi avec le vol. 9.7.2. Composition du message Le message MAS doit comprendre les éléments suivants: - type de message; - numéro de message; - identification de l'aéronef. NOTE Les règles d'introduction des données ainsi que les formats et le contenu des champs sont précisés à l'Annexe A. 9.7.3. Règles d'application 9.7.3.1. Généralités 9.7.3.1.1. Le message MAS doit être déclenché manuellement par le contrôleur acceptant. 9.7.3.1.2. L'utilisation du message MAS est obligatoire si, par accord bilatéral, le message COF n'est pas employé. 9.7.3.2. Traitement par l'organisme recevant 9.7.3.2.1. Le système ATC qui reçoit un message MAS doit tenter de l'associer avec le plan de vol correspondant. 9.7.3.2.2. Le contrôleur doit être informé immédiatement de la réception du MAS. 9.7.4. Accusé de réception des MAS 9.7.4.1. Accusé de réception 9.7.4.1.1. Si le message MAS peut être associé, sans ambiguïté, avec un plan de vol, le système doit en accuser réception par la production et la transmission d'un message LAM. 9.7.4.1.2. Si le message MAS ne peut être associé, sans ambiguïté, avec un plan de vol, aucun accusé de réception ne doit être envoyé. 9.7.4.2. Absence d'accusé de réception En l'absence de message LAM accusant réception d'un message MAS, un avertissement doit s'afficher au poste de travail ATC compétent, selon les besoins. 9.7.5. Exemple -TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 ANNEXE A (Normative) RÈGLES D'INTRODUCTION DES DONNÉES TABLE DES MATIÈRES >EMPLACEMENT TABLE> A.1. Objet La présente Annexe décrit les règles générales d'introduction des données dans les messages qui sont définis dans la présente Norme. Ces règles s'appliquent à tous les messages, sauf lorsque d'autres formules ou des exceptions sont expressément indiquées dans les règles d'application d'un message donné. A.2. Formats génériques de message A.2.1. Tous les messages décrits dans les sections ci-après peuvent être transmis suivant le format de l'OACI: 6 Procédure de base - Messages obligatoires; 7 Procédure de base - Messages complémentaires; 8 Procédure de dialogue - Coordination. A.2.2. Les formats de champ de message sont définis par l'OACI dans les Procédures pour les services de la navigation aérienne - Règles de l'air et services de la circulation aérienne (Document 4444). Les types de champ OACI ci-après doivent, le cas échéant, être transmis avant tout autre type de champ dans l'ordre suivant: 3, 7, 13, 14 et 16. Étant donné qu'ils sont au format de champ de type 22, les autres types de champ OACI peuvent être transmis dans n'importe quel ordre, pour autant qu'ils ne précèdent pas les types de champ mentionnés ci-dessus. A.2.3. Tous les messages décrits dans le présent document peuvent être transmis selon le format ADEXP d'Eurocontrol. Le contenu, la structure et les règles d'usage des champs de données ADEXP doivent être conformes avec la Référence 2NOTES 1. Seuls les champs de données primaires ADEXP sont mentionnés dans la présente Annexe, excepté lorsque les sous-champs qui y sont associés appellent des observations particulières. La Norme ADEXP énumère tous les sous-champs facultatifs et obligatoires qui dépendent de chaque champ primaire. 2. Les messages de la Section 9 - Procédure de dialogue - Transfert de communication - sont uniquement décrits dans le format ADEXP. A.3. Type de message Le type de message doit être l'abréviation du message selon la liste ci-après: ABI: Préavis de franchissement de limite ACP: Acceptation ACT: Activation CDN: Coordination COD: Assignation de code SSR COF: Changement de fréquence HOP: Proposition de transfert de contrôle INF: Information LAM: Message d'accusé de réception logique MAC: Message d'abrogation de coordination MAS: Prise en charge manuelle des communications PAC: Activation préliminaire RAP: Proposition d'activation soumise à accord REV: Révision RJC: Rejet de coordination ROF: Demande de changement de fréquence RRV: Proposition de révision soumise à accord SBY: Attente de transfert SDM: Message de données supplémentaires TIM: Message de déclenchement de transfert A.3.1. OACI Champ de type 3, élément (a). A.3.2. ADEXP Champ primaire "title". A.4. Numéro du message Le numéro du message comprend les identificateurs des organismes émettant et recevant ainsi que le numéro d'ordre du message. Ce dernier va de 001 à 000 (représentant 1000), puis reprend à 001, pour tous les messages envoyés à un même destinataire, quel que soit le type de message. A.4.1. OACI Champ de type 3, élément (b). A.4.2. ADEXP Champ primaire "refdata". Le sous-champ "fac", entrant dans les sous-champs "sender" et "recvr", doit comprendre les identificateurs des organismes ATC, dont la longueur ne doit pas dépasser huit caractères. Le sous-champ "seqnum" doit comprendre le numéro de série. A.5. Référence du message A.5.1. OACI Champ de type 3, élément (c) (appelé "données de référence" dans le document 4444 de l'OACI). Le contenu de l'élément (c) doit être celui de l'élément (b) du champ de type 3 du message OLDI auquel il est fait référence. A.5.2. ADEXP Champ primaire "msgref". Les valeurs des sous-champs "sender", "recvr" et "seqnum", à l'intérieur du champ primaire "msgref", doivent être celles des mêmes sous-champs dépendant du champ primaire "refdata" du message OLDI auquel il est fait référence. A.6. Identification de l'aéronef A.6.1. OACI Champ de type 7, élément (a). A.6.2. ADEXP Champ primaire "arcid". A.7. Mode et Code SSR 1. S'il est connu, le mode/code SSR sur lequel l'organisme recevant peut escompter une réponse de l'aéronef au point de transfert de contrôle; 2. Si non une indication selon laquelle le code SSR a été demandé par l'organisme recevant. A.7.1. OACI Champ de type 7, éléments (b) et (c). Si aucun code SSR n'est assigné ou si le mode/code n'est pas connu, les éléments (b) et (c) doivent être omis. Lorsqu'un code/mode SSR est demandé, les éléments b) et c) doivent contenir la valeur "A9999". A.7.2. ADEXP Champ primaire "ssrcode". Si aucun code SSR valide n'est assigné ou si le mode/code n'est pas connu, le champ doit être omis. En cas de demande de code/mode SSR via le message PAC, le champ primaire "ssrcode" doit contenir l'indicateur "REQ". A.8. Aérodrome de départ A.8.1. OACI Champ de type 13, élément (a). A.8.2. ADEXP Champ primaire "adep". A.9. Données estimées A.9.1. Généralités A.9.1.1. Les données estimées doivent comprendre le COP, l'heure au COP et le niveau de transfert. A.9.1.2. Le point de coordination doit être défini, soit en tant que point de référence connu, soit en distance et en relèvement par rapport à un point de référence connu, soit en latitude et en longitude. A.9.1.3. Le niveau autorisé (de transfert) doit correspondre aux conditions de transfert proposées. A.9.1.4. Recommandation Pour les vols en montée ou en descente, il convient que les données estimées comprennent également des données de croisement supplémentaires ainsi que les conditions de croisement. A.9.1.5. Les données de croisement supplémentaires, lorsqu'elles sont indiquées, doivent comprendre le niveau supplémentaire de croisement au point de transfert de contrôle. Les conditions de croisement doivent être indiquées comme suit: - Lettre "A", - si le vol se situera au niveau ou au-dessus du niveau indiqué dans les données de croisement supplémentaires; - Lettre "B", - si le vol se situera au niveau ou en dessous du niveau indiqué dans les données de croisement supplémentaires. A.9.2. OACI Champ de type 14. A.9.3. ADEXP Champ primaire "coordata". Le sous-champ "ptid" à l'intérieur du champ primaire "coordata" doit comprendre: - soit un point de référence connu; - soit une distance et un relèvement par rapport à un point de référence connu, tel qu'il est défini dans le champ primaire "REF" or "GEO" du même message. A.10. Point de coordination A.10.1. Généralités A.10.1.1. Le point de coordination mentionné par les organismes ATC transférant et acceptant pour les besoins du transfert de contrôle en question. A.10.1.2. Le point de coordination doit être défini soit en tant que point de référence connu, soit en distance et en relèvement par rapport à un point de référence connu, soit en latitude et en longitude. A.10.2. OACI Champ 14, élément (a). A.10.3. ADEXP Champ primaire "cop" contenant: - soit un point de référence connu; - soit un relèvement et une distance par rapport à un point de référence connu, tel qu'il est défini dans le champ primaire "REF" ou "GEO". A.11. Aérodrome de destination A.11.1. OACI Champ 16, élément (a). A.11.2. ADEXP Champ primaire "ades". A.12. Nombre d'aéronefs et type Ce champ doit contenir le type d'aéronef, ainsi que le nombre d'aéronefs lorsqu'il s'agit de vols en formation. A.12.1. OACI Champ de type 9 au format de champ de type 22. L'élément c du champ de type 9 doit comprendre soit la catégorie de turbulence de sillage correspondant au type d'aéronef, soit la lettre "Z". A.12.2. ADEXP Champ primaire "arctyp". S'il y a plusieurs aéronefs, ajouter le champ primaire "nbarc". A.13. Route Les deux formats permettent la description de la route telle qu'elle est définie pour les messages de l'OACI, qui impose en premier élément la vitesse, le niveau de vol demandé ou l'altitude. Après le groupe vitesse, les données relatives à la route doivent comprendre au minimum les données spécifiées dans le paragraphe suivant. D'autres données relatives à la route peuvent être incluses après l'élément c), le cas échéant. Voir également les règles d'introduction des données relatives aux routes à l'Annexe B "Prescriptions applicables au traitement des acheminements particuliers": A.13.1. Teneur A.13.1.1. Vols passant par un COP défini - l'élément de la route avant le COP (route ATS, identificateur SID, DCT ou point significatif); - le COP; - l'élément de route après le COP (route ATS ou point significatif). A.13.1.2. Vols s'écartant de la route ATS - le point à partir duquel le vol suit le tronçon de route directe; - l'élément "DCT"; - le point vers lequel le vol se rend sur le tronçon de route directe. A.13.2. Format A.13.2.1. OACI Champ de type 15 au format de champ de type 22. A.13.2.2. ADEXP Champ primaire "route". A.14. Autres données de plan de vol A.14.1. OACI Champs de type 8, 10 et 18 au format de champ de type 22. A.14.2. ADEXP Champ primaires: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts", and "typz". A.15. Statut et motif de la coordination Le statut et le motif de la coordination doivent comprendre les éléments suivants: - un indicateur à trois lettres confirmant le nouveau statut du plan de vol dans le système, parmi les suivants: - INI, lorsque le plan de vol dans le système doit être en état initial, c'est-à-dire qu'aucun message de notification n'a été reçu; - NTF, lorsque le plan de vol dans le système doit être en état "avisé"; - CRD, lorsque le plan de vol dans le système doit être en état "coordonné", c'est-à-dire que l'ACT de base a été reçu ou que le dialogue de coordination initiale est achevé et que les conditions sont agréées. - un indicateur à trois lettres précisant le motif du statut, parmi les suivants: - TFL, si le motif est un changement de niveau de transfert; - RTE, si le motif est un changement de route; - HLD, pour indiquer que le vol est en attente pour une durée indéterminée et fera l'objet d'un nouveau message; - DLY, pour indiquer que le départ est retardé; - CAN, si le motif est une annulation; - CSN, en cas de changement d'indicatif d'appel; - OTH, pour tout autre motif ou si le motif est inconnu. A.15.1. OACI A.15.1.1. L'état et le motif de la coordination doivent être mentionnés selon le format de champ de type 18. A.15.1.2. L'état et le motif de la coordination doivent inclure les éléments suivants présentés sous forme de groupe de dix caractères: - STA suivie d'une barre oblique; - l'indicateur confirmant le nouveau statut de la notification/coordination; - l'indicateur précisant le motif. A.15.2. ADEXP Champ primaire "cstat". Les éléments auxiliaires "coordstatusident" et "coordstatusreason" doivent indiquer le nouveau statut et le motif, suivant les modalités exposées ci-dessus. A.16. Cap assigné (ADEXP uniquement) Le champ primaire "ahead" doit comprendre: - soit le cap assigné à un vol, exprimé en degrés; - soit, si aucun cap n'est assigné, l'indicateur "ZZZ", par exemple, lorsqu'un message SDM est envoyé pour indiquer qu'un cap assigné précédemment n'est plus applicable. A.17. Vitesse assignée (ADEXP uniquement) Le champ primaire "aspeed" doit comprendre: - soit la vitesse assignée à un vol, exprimée en noeuds, nombre de mach ou kilomètres/heure; - soit, si aucune vitesse n'est assignée, l'indicateur "ZZZ", par exemple lorsqu'un message SDM sert à indiquer qu'une vitesse assignée précédemment n'est plus applicable. A.18. Vitesse ascensionnelle/descensionnelle assignée (ADEXP uniquement) Le champ primaire "rate" doit comprendre: - soit, la vitesse ascensionnelle/descensionnelle assignée, exprimée en centaine de pieds par minute; - soit, si aucune vitesse ascensionnelle/descensionnelle n'est assignée, l'indicateur "ZZZ" dans la partie numérique du champ, par exemple lorsqu'un message SDM est envoyé pour indiquer qu'une vitesse ascensionnelle/descensionnelle précédemment assignée n'est plus applicable. A.19. Autorisation d'acheminement direct (ADEXP uniquement) Route directe, non définie comme route ATS, reliant deux points. Les points peuvent être définis soit comme un point de référence connu, soit comme une distance ou un relèvement par rapport à un point de référence. Tous les désignateurs de points terminaux qui seront utilisés doivent faire l'objet d'un accord bilatéral, c'est-à-dire qu'ils doivent être connus des deux systèmes. Champ primaire "DCT" comprenant: - le point auquel l'écart a commencé ou commencera, défini suivant l'une des méthodes suivantes: - un point de référence connu; - une distance ou un relèvement par rapport à un point de référence connu, défini dans le même message par le champ primaire "REF"; - la valeur "ZZZ", si l'organisme émettant ne demande pas la désignation du point où commence l'écart. - le point situé sur la route initialement prévue dans le plan de vol jusqu'auquel l'aéronef a été ou sera autorisé, défini selon l'une des méthodes suivantes: - un point de référence connu; - une distance ou un relèvement par rapport à un point de référence connu, défini dans le même message par le champ primaire "REF". A.20. Demande d'acheminement direct Demande de route directe, non définie comme route ATS, reliant deux points. Les points peuvent être définis soit comme un point de référence connu, soit comme une distance ou un relèvement par rapport à un point de référence. Tous les désignateurs de points terminaux utilisés doivent faire l'objet d'un accord bilatéral, c'est-à-dire qu'ils doivent être connus des deux systèmes. A.20.1. OACI Champ de type 15, à l'exclusion du groupe vitesse/niveau initial, au format de champ 22. Il doit comprendre: - le point à partir duquel il est demandé que le vol s'écarte de la route prévue, défini selon l'une des méthodes suivantes: - un point de référence connu; - une distance ou un relèvement par rapport à un point de référence; - la valeur "ZZZ", si l'organisme ATC recevant demande un acheminement direct. - l'abréviation "DCT", - suivie par le point situé sur la route initialement prévue dans le plan de vol, auquel l'aéronef demande l'autorisation, défini comme: - soit un point de référence connu; - soit une distance et un relèvement par rapport à un point de référence connu. A.20.2. ADEXP Le champ primaire "DCT" doit comprendre: - le point auquel l'écart a commencé ou commencera, défini suivant l'une des méthodes suivantes: - un point de référence connu; - une distance ou un relèvement par rapport à un point de référence connu défini dans le même message par le champ primaire "REF"; - la valeur "ZZZ" si l'organisme recevant reçoit une demande d'acheminement direct mais que le point de départ n'est pas connu avec précision. - le point situé sur la route initialement prévue dans le plan de vol, auquel l'autorisation est demandée et qui est défini: - soit comme un point de référence connu; - soit comme une distance ou un relèvement par rapport à un point de référence connu défini dans le même message par le champ primaire "REF". A.21. Position (ADEXP uniquement) A.21.1. Généralités A.21.1.1. La position actuelle du vol, exprimée soit par des coordonnées géographiques, soit par un relèvement et une distance par rapport à un point désigné. A.21.1.2. Le champ primaire "ref" ou "geo" doit définir la position actuelle de l'aéronef dans le plan horizontal. Les points utilisés pour l'indication des relèvement et distance dans le champ primaire "ref" doivent faire l'objet d'un accord bilatéral, c'est-à-dire qu'ils doivent être connus des deux systèmes. La "position" du champ primaire doit comprendre le sous-champ "ptid" qui renvoie au point de référence ou point géographique défini. Si des données de temps doivent être incluses, le sous-champ "to" (hhmm) ou "sto" (hhmmss) doit être employé, sous réserve d'accord bilatéral. A.22. Indication de transfert anticipé (ADEXP uniquement) Le champ primaire "transfert anticipé" doit comprendre l'un des éléments suivants: - C, s'il s'agit d'un transfert anticipé en montée; - D, s'il s'agit d'un transfert anticipé en descente; - T, s'il s'agit d'un transfert anticipé en virage; - F, s'il s'agit d'un transfert anticipé total pour toutes situations. A.23. Fréquence A.23.1. OACI Le champ de type 18 doit comprendre les éléments suivants au format de champ de type 22: - FRQ, suivi d'une barre oblique; - 6 chiffres indiquant la fréquence, exprimée en MHz jusqu'à trois décimales. A.23.2. ADEXP Champ primaire "freq". A.24. Motif (ADEXP uniquement) Champ primaire "reason", comprenant la valeur "MANUAL" pour les messages renvoyés manuellement. A.25. Niveau de vol autorisé (ADEXP uniquement) Champ primaire "cfl". A.26. Niveau de vol proposé pour le transfert (ADEXP uniquement) Champ primaire "propfl". A.27. Heure estimée de décollage A.27.1. OACI Champ de type 13, élément (b). A.27.2. ADEXP Champ primaire "etot". A.28. Type de message de référence Le champ comprend le type de message spécifié au paragraphe A.1 de la présente Annexe. A.28.1. OACI Champ de type 18 au format de champ de type 22. L'indicateur d'élément doit être "MSG". A.28.2. ADEXP Champ primaire "msgtyp". ANNEXE B (Normative) PRESCRIPTIONS APPLICABLES AU TRAITEMENT DES ACHEMINEMENTS PARTICULIERS B.1. Introduction B.1.1. Généralités B.1.1.1. La présente Annexe décrit les règles et prescriptions relatives à l'introduction de données dans les circonstances suivantes, sous réserve d'accord: - un vol suit une trajectoire directe, hors route, et franchit la limite en raison d'un segment de route directe figurant sur le plan de vol; - après transmission du message ABI ou ACT, un vol est réacheminé: - soit via une route ATS différente; - soit via une route directe de façon à rejoindre la route initiale à un point ultérieur. B.1.1.2. Pour ce qui concerne le réacheminement des vols (décrit à l'alinéa B.1.1.1), les modalités d'échange de données décrites dans la présente Annexe permettent de modifier la route indiquée pour le vol dans les deux systèmes au moyen de messages de notification et de coordination. B.2. Application des messages B.2.1. Règles de base applicables aux acheminements directs B.2.1.1. Les conditions applicables à l'échange OLDI pour la coordination des vols dans le cas d'acheminements directs doivent faire l'objet d'un accord bilatéral. B.2.1.2. Les données requises pour la notification et la coordination de vols en acheminement direct figurent aux rubriques point de coordination (données estimées (format OACI) et données de coordination (ADEXP)) et route des messages applicables. B.2.2. Route directe déposée Lorsque la route indique que le vol franchira la limite sur une route directe, le tronçon de route directe et le COP qui en résulte doivent figurer dans le(s) message(s) ABI. Ce COP est inclus dans le message ACT ou RAP ultérieur. Le COP et les données relatives à la route doivent être présentés selon le format décrit à l'alinéa B.3.2. B.2.3. Réacheminement après transmission du message ABI et avant la transmission de l'ACT Un nouveau message ABI doit être envoyé avec les données correspondant à la nouvelle route. B.2.4. Réacheminement après transmission du message ACT B.2.4.1. Un message REV doit être envoyé pour signaler les réacheminements intervenant après transmission d'un message ACT, avant l'expiration d'un délai, fixé bilatéralement, avant l'heure de survol prévue du COP précédemment coordonné.NOTE Un message REV est uniquement utilisé dans les cas où l'organisme acceptant ne change pas. Si l'organisme change, un message MAC doit être envoyé à l'organisme acceptant initial ou la coordination verbale doit être annulée. B.2.4.2. Le message doit contenir les éléments de données suivants: - point de coordination (COP précédent, à titre de référence); - données estimées; - route. B.2.4.3. Les messages établis selon le format OACI doivent comprendre les champs suivants: 3 Type et numéro du message; références du message, sous réserve d'accord bilatéral; 7 Identification de l'aéronef. Les éléments b et c ne doivent pas être inclus, à moins qu'une révision du code SSR ne soit coordonnée en même temps; 13 Aérodrome de départ; 14 Élément a uniquement, contenant le COP précédent à titre de référence; 16 Destination; 22 Champ 14 contenant les données estimées relatives aux nouvelles conditions de franchissement de limite dans le format de champ 22; 22 Champ 15 contenant les données relatives à la nouvelle route dans le format de champ 22. B.2.4.4. Les messages établis selon le format ADEXP doivent comprendre, outre le type et le numéro du message, l'identification de l'aéronef, l'aérodrome de départ et de destination et, sous réserve d'accord bilatéral, le numéro de référence du message: - le COP précédent dans le champ COP; - les nouvelles conditions de coordination dans le champ COORDATA; - la nouvelle route dans le champ ROUTE. B.2.4.5. Les révisions de route notifiées dans le cadre de la procédure de dialogue doivent être envoyées sous forme de messages RRV, sauf s'il a été convenu bilatéralement qu'il s'agissait de révisions "standard". B.3. Teneur des champs B.3.1. Routes ATS Pour les vols réacheminés via une route ATS de remplacement, les champs relatifs aux données estimées et à la route sont présentés selon les formats des messages ABI et ACT. B.3.2. Routes directes B.3.2.1. Le point de coordination dans les données estimées doit être le point de franchissement de la limite exprimé en relèvement et distance par rapport à un point de compte rendu. Ces points doivent être agréés bilatéralement. Lorsque la distance est nulle ou si un vol doit passer à distance de ce point dans une mesure agréée bilatéralement, seul l'identificateur du point doit être mentionné. B.3.2.2. Sous réserve d'accord bilatéral, le point de coordination pour un vol sur une route directe peut être exprimé en longitude et latitude. B.3.2.3. La route doit comprendre: - le point sur la route d'origine à partir duquel l'aéronef doit être acheminé directement; lorsque le vol est acheminé directement à partir de la "position du moment", le point peut être exprimé en relèvement et distance par rapport à un point de compte rendu. Sous réserve d'accord bilatéral, le point peut être exprimé par référence à la latitude et la longitude; - l'abréviation "DCT"; - le point vers lequel l'aéronef s'achemine directement; - le dernier tronçon de la suite de la route du vol (FRF), si le système le connaît. B.4. Exemples B.4.1. Routes directes B.4.1.1. Messages ABI et ACT B.4.1.1.1. Le vol (identification Jetset 253) doit franchir la limite sur une route directe entre le Point A (PTA) et le Point C (PTC), après quoi il suivra la route ATS UA134. Le système détermine un COP dont le relèvement est de 350 degrés par rapport au point B (PTB et la distance de 22 NM dudit Point B (PTB). >PIC FILE= "L_2000254FR.008401.EPS"> Le message ABI suivant est envoyé: - OACI (ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134) - ADEXP -TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB -BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT PTC UA134 B.4.1.1.2. Le message ACT a le même format que le message ABI, si ce n'est que la route à suivre est facultative. B.4.1.2. Message REV Le vol HZT2051 faisait précédemment l'objet du message ACT ci-après (ou son équivalent ADEXP): (ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M >PIC FILE= "L_2000254FR.008501.EPS"> Le vol est ensuite acheminé directement au point MYY à partir de 40 NM à l'ouest du point RQA. Le point le plus proche de l'intersection de la limite est TDS à partir duquel la distance jusqu'au point d'intersection réel est à la position 26 NM à 240 degrés. Le message de révision suivant est envoyé: (REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY) >PIC FILE= "L_2000254FR.008502.EPS"> L'équivalent ADEXP du message est le suivant: -TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG -SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310 -REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -ROUTE N0458F310 RQA270040 DCT MYY Un message de révision ultérieur indiquerait TDS240026 comme COP. B.4.2. Réacheminement par des routes ATS après transmission de l'ACT B.4.2.1. Message ACT Le vol GKP217 est censé passer par le point de coordination EMT. Le message ACT suivant est transmis: (ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M) >PIC FILE= "L_2000254FR.008601.EPS"> Le vol est ultérieurement réacheminé via la route ATS UM247 à l'intérieur de l'espace aérien du centre émettant vers un nouveau point de coordination XAT, puis doit suivre la route ATS UJ124. Le centre acceptant reste le même. Le message de révision suivant est envoyé: (REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124) >PIC FILE= "L_2000254FR.008602.EPS"> Le vol est ensuite autorisé à passer au FL290, ce qui donne lieu au message suivant (contenant le nouveau COP): (REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA) >PIC FILE= "L_2000254FR.008701.EPS"> B.4.2.2. Équivalents ADEXP Les équivalents ADEXP des deux messages de révision sont les suivants: a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -ROUTE N0430F290 UM247 XAT UJ124 b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTA ANNEXE C (Informatif) PHASES DE LA PROCÉDURE DE DIALOGUE (SYSCO NIVEAU 1) - SÉQUENCE DE MESSAGES Séquence de messages >PIC FILE= "L_2000254FR.008802.EPS"> ANNEXE II PRÉSENTATION DE L'ÉCHANGE DE DONNÉES ATS (ADEXP), ÉDITION 2.0 (document de référence Eurocontrol DPS.ET1.ST09-STD) TABLE DES MATIÈRES >EMPLACEMENT TABLE> AVERTISSEMENT/DROITS D'AUTEUR Le présent document a été élaboré par l'Agence Eurocontrol, qui en détient les droits d'auteur. Le contenu du présent document est librement accessible, en tout ou en partie, aux représentants des Etats membres, toute reproduction ou divulgation à des tiers étant toutefois subordonnée à une autorisation écrite préalable de l'Agence Eurocontrol. AVANT-PROPOS 1. Organe compétent La présente Norme a été élaborée par la Section "Besoins des utilisateurs" de l'Organisme central de gestion des courants de trafic aérien (CFMU) de l'Organisation européenne pour la sécurité de la navigation aérienne (Eurocontrol), qui en assure également la mise à jour. 2. Programme de travail EATCHIP La présente Norme constitue un produit du Programme de travail EATCHIP (EWPD), Domaine - Systèmes informatiques de l'ATM (DPS), Mission d'encadrement 09. 3. Approbation de la Norme 3.1. La présente Norme est adoptée conformément aux procédures décrites dans les Directives pour les activités de normalisation d'Eurocontrol, réf. 000-2-93, édition 1.0. 3.2. Les dispositions de la présente Norme ont pris effet suite à l'adoption, en 1995, de l'édition 1.0 par la Commission permanente d'Eurocontrol; elles entrent en application à compter du 1er décembre 1997. 4. Rectificatifs techniques et amendements La présente Norme fait l'objet d'un suivi aux fins d'y apporter les rectificatifs techniques et amendements requis. La procédure de mise à jour de la présente Norme est énoncée dans l'Annexe H des Directives relatives à la rédaction et à la présentation uniformes des Normes Eurocontrol. Les amendements ou ajouts touchant aux principes ou règles grammaticales de base du format ADEXP sont soumis à la procédure d'examen officiel prévue dans les Directives relatives à la rédaction et à la présentation uniformes des Normes Eurocontrol. Les propositions d'amendements ou d'ajouts à la présente Norme doivent être adressées, par écrit, à la Section "Besoins des utilisateurs" (ADEXP), CFMU, Agence Eurocontrol. 5. Conventions rédactionnelles 5.1. Le format de la présente Norme est conforme aux Directives relatives à la rédaction et à la présentation uniformes des Normes Eurocontrol; on relève toutefois certains écarts de formatage mineurs par rapport aux dites Directives: ils sont destinés à prévenir toute confusion avec la notation propre à l'ADEXP. 5.2. Pour indiquer le statut de chaque élément, il a été décidé d'adopter les règles typographiques suivantes: - les éléments normatifs se caractérisent par la forme verbale "doit" ou "doivent" et sont imprimés en caractères ordinaires; - les éléments recommandés se caractérisent par la forme verbale "devrait" ou "devraient"; ils sont imprimés en caractères italiques et précédés de la mention Recommandation. 6. Liens avec d'autres documents normatifs La présente Norme est liée au document suivant: Norme Eurocontrol pour l'échange des données en ligne (OLDI). 7. Statut des annexes au présent document >EMPLACEMENT TABLE> 8. Langue utilisée Le texte original de la présente Norme a été rédigé en langue anglaise. 1. CHAMP D'APPLICATION 1.1. L'ADEXP est un format et non un protocole. Il n'impose aucune restriction en ce qui concerne les supports ou les protocoles de transmission à utiliser, hormis le jeu de caractères. 1.2. Le format ADEXP est principalement destiné à l'échange de messages en ligne d'ordinateur à ordinateur. 1.3. Le présent document définit les principes et les règles syntaxiques du format ADEXP, sous la forme d'une définition complète des champs ADEXP. 1.4. Le format ADEXP a été spécifié pour l'échange de messages dans les domaines suivants (pour les références documentaires, se reporter à la Section 2, page 3): - Planification des vols: échange des données de plan de vol et des messages associés entre le Système intégré de traitement initial des plans de vol (IFPS), les Services de la circulation aérienne (ATS) et les exploitants d'aéronefs (AO) (Document réf. 3); - Gestion des courants de trafic aérien (ATFM): échange de messages entre le Système tactique (TACT) du CFMU, les AO et l'ATS (Document réf. 5); - Coordination du contrôle de la circulation aérienne: échange de messages de coordination tactique entre organismes de contrôle de la circulation aérienne (ATCU) (Document réf. 6); - Gestion de l'espace aérien: échange de données entre les organismes ATS nationaux, le CFMU et les AO concernant les disponibilités en matière d'espace aérien (Document réf. 7); - Coordination civile-militaire: messages relatifs aux données des vols civils et militaires et messages de traversée d'espace aérien (Document réf. 7). 1.5. Les spécifications détaillées concernant l'utilisation et la teneur des messages visés dans chacune des catégories précitées figurent dans les documents cités en référence. 2. RÉFÉRENCES 2.1. Les documents et normes ci-après contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des dispositions de la présente Norme Eurocontrol. Les éditions indiquées sont celles qui étaient en vigueur au moment de la publication de la présente Norme Eurocontrol. Toute révision des documents de l'Organisation de l'aviation civile internationale (OACI) mentionnés en référence doit être immédiatement répercutée dans la présente Norme Eurocontrol. Les révisions des autres documents cités en référence ne doivent faire partie des dispositions de la présente Norme Eurocontrol que lorsqu'elles auront fait l'objet d'un examen officiel et auront été incluses dans la présente Norme Eurocontrol. En cas de conflit entre les prescriptions de la présente Norme Eurocontrol et la teneur des autres documents de référence, c'est la présente Norme Eurocontrol qui doit être appliquée. 2.2. Les documents énumérés ci-après constituaient les ouvrages de référence au moment de la publication de la présente Norme Eurocontrol; les utilisateurs sont cependant invités à vérifier le mode d'utilisation et les tableaux de composition des champs de message dans les dernières éditions en date de ces documents. 1. OACI, Annexe 10 à la Convention de Chicago, Volume I, édition novembre 1985; 2. OACI, Annexe 10 à la Convention de Chicago, Volume II, édition juillet 1995; 3. IFPS& RPL Dictionnary of messages Edition 1.0 Mars 1998 4. "Règles de l'air et services de la circulation aérienne", PANS-RAC, Doc. 4444, édition novembre 1985 (y compris l'Amendement no 6 de novembre 1995); 5. Guide To ATFM Message Exchange, document Eurocontrol réf. TACT/USD/MSGGUID, édition 6.0, entrée en vigueur mars 1998. 6. Norme Eurocontrol pour l'échange de données en ligne, édition 2.0, octobre 1996. 7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, édition 1.0, mai 1996. 3. DÉFINITIONS, SYMBOLES, SIGLES ET ABRÉVIATIONS 3.1. Notation Le système de notation utilisé pour définir la syntaxe est appelé Backus Naur Form (BNF) ou forme normale de Backus. Ce système définit un ensemble de règles déterminant une catégorie de chaînes de caractères. En l'occurrence, la catégorie de chaînes correspond à l'ensemble des messages formant un message ADEXP syntaxiquement correct. 3.2. Définitions Les définitions ci-après sont d'application pour les besoins de la présente Norme Eurocontrol: entité ("token"): caractère ou ensemble de caractères pouvant être "extrait" par un analyseur lexical du fait de la présence de séparateurs; symbole: tout "terme" apparaissant dans une règle BNF et ne correspondant pas à un caractère; symbole terminal: symbole représenté en termes de séquence de caractères; symbole non terminal: symbole représenté par un ou plusieurs symboles terminaux. NOTE un symbole non terminal peut également être représenté sous la forme d'une combinaison de symboles terminaux et non terminaux. 3.3. Construction 3.3.1. La BNF consiste en un ensemble de règles ou de constructions du type: symbole ::= expression NOTES 1. "::=" signifie "peut être remplacé par". 2. L'élément "symbole" est non terminal. 3. L'élément "expression" contient des symboles terminaux et non terminaux. 3.3.2. Les symboles terminaux ont une représentation directe sous la forme d'une séquence de caractères susceptibles d'être identifiés en tant qu'entité ("token") par un analyseur lexical du fait de la présence de séparateurs. 3.4. Conventions Les conventions ci-après sont d'application pour les besoins de la présente Norme Eurocontrol: - Les symboles terminaux figurent en lettres capitales.NOTES Par convention, le symbole terminal NIL signifie "aucun symbole terminal". Ce symbole apparaît notamment dans des choix du type: a ::= b ( c | NIL ) où a peut être remplacé par (b suivi de c) ou par b seulement. - Les symboles non terminaux (par ex. la partie gauche d'une production grammaticale) figurent en minuscules. - Les caractères et symboles littéraux de chaîne apparaissant à l'intérieur des règles figurent respectivement entre apostrophes (') ou guillemets ("). Exemples 1. HYPHEN::= '-' 2. title::= '-' "TITLE" titleid Il peut s'avérer nécessaire, pour certaines applications de modélisation de données, d'opérer la distinction entre symboles terminaux et symboles non terminaux par d'autres moyens que l'emploi des majuscules ou des minuscules. Lorsqu'il y a lieu de distinguer de manière explicite les symboles terminaux des symboles non terminaux par un autre moyen que l'emploi des majuscules ou des minuscules, il est recommandé de recourir à l'adjonction d'un suffixe, comme suit: "_at" pour un terme auxiliaire, "_pf" pour un champ primaire et "_sf" pour un sous-champ. 3.5. Opérateurs Les opérateurs ci-après sont d'application pour les besoins de la présente Norme Eurocontrol: facultatif: lorsque certains symboles peuvent valablement apparaître ou non dans la grammaire. Les symboles facultatifs sont indiqués entre crochets "[" et "]". clôture: lorsqu'un groupe de symboles peut apparaître zéro fois ou plus. Les symboles apparaissent entre accolades "{" et "}". Si un chiffre est mentionné avant l'accolade "{", il indique le nombre minimal d'occurrences autorisées du groupe de symboles. Si un chiffre est mentionné après l'accolade "}", il précise le nombre maximal d'occurrences autorisées du groupe de symboles. choix: lorsqu'un certain nombre de symboles alternatifs peuvent apparaître dans la grammaire. Le choix est représenté par un trait vertical "|". concaténation: représentation de symboles ordonnés en séquence, indépendamment de la présence ou non d'un ou de plusieurs séparateurs. Il n'en existe pas de représentation explicite. On distingue deux types de concaténation: - concaténation stricte: au niveau lexical, certaines règles peuvent faire intervenir la concaténation de symboles terminaux indiquant qu'ils se succèdent strictement (aucun séparateur intermédiaire); dans ce cas, on utilise le point d'exclamation "!":Exemple datetime :: = date ! timehhmm par ex. "9912251200", qui signifie le 25 décembre 1997 à 12h00.: - concaténation souple: la présence de séparateurs entre symboles terminaux est autorisée. La représentation d'une concaténation souple au sein d'une règle peut être implicite ou explicite:Exemples 1. implicite: dct ::= '-' "DCT" point point 2. explicite: dct ::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point >EMPLACEMENT TABLE> NOTES 1. La concaténation a toujours la priorité sur le choix. Les parenthèses "(" et ")" sont utilisées pour modifier l'ordre d'évaluation de l'expression.Exemple >EMPLACEMENT TABLE> 2. Dans toutes les règles, la présence autorisée de séparateurs entre les symboles demeurera implicite, cela dans un souci de lisibilité. Recommandation Lorsqu'il y a risque de confusion du fait de la priorité à respecter entre les deux opérateurs susvisés, il est recommandé de recourir aux parenthèses pour clarifier l'ordre d'évaluation souhaité. 3.6. Sigles et abréviations >EMPLACEMENT TABLE> 4. PRINCIPES ADEXP 4.1. Texte à lecture directe 4.1.1. Le format ADEXP se présente sous forme de texte (caractères). 4.1.2. Il peut être lu directement par l'opérateur, ce qui facilite la mise au point ou l'examen des questions opérationnelles. 4.1.3. Ce format présente également l'avantage d'être à la fois plus ouvert et plus compréhensible. 4.2. Champs identifiés et récupérables 4.2.1. Chaque message en format ADEXP se compose de champs. 4.2.2. Ces champs sont délimités par un caractère spécial de début de champ, le trait d'union ("-"), et identifiés au moyen de mots-clés spécifiques.NOTE Il convient de noter que certains champs (ceux qui sont syntaxiquement définis comme comportant l'élément lexical "CHARACTER") peuvent valablement contenir un "-" dans l'énoncé du champ. 4.2.3. Une telle formule confère au format des possibilités d'extension et une robustesse accrues (si un champ est absent ou incorrect, il peut être négligé sans que cela nuise à l'interprétation du reste du message (cf. section 0). 4.2.4. Autre conséquence, l'ordre des champs n'a aucun rôle dans la détermination de la validité du message, à l'exception du premier champ (champ obligatoire intitulé "TITLE", qui détermine les champs admis. 4.2.5. Les champs peuvent être simples ou composés. 4.2.6. Les éléments constitutifs des champs composés sont appelés sous-champs; ils sont définis au moyen de mots-clés et délimités par un caractère de début de champ. 4.2.7. Les champs simples ne comportent aucun sous-champ. 4.2.8. Les champs simples et composés constituant le premier niveau de définition d'un message sont appelés champs primaires. 4.2.9. Tous les constituants de niveau inférieur sont, par définition, des sous-champs, qui peuvent être eux aussi simples ou composés. 4.2.10. Les champs composés sont de deux types: champs structurés ou champs de listage. 4.2.11. Les champs structurés ont un contenu prédéfini et se composent de sous-champs exclusivement. L'ordre des sous-champs dans un champ structuré n'est PAS déterminant. 4.2.12. Les champs de listage débutent par le mot-clé BEGIN et se terminent par le mot-clé END. Entre ces deux repères, on peut trouver plusieurs occurrences d'un même sous-champ ou une combinaison de sous-champs. L'ordre des occurrences au sein d'un champ de listage est sémantiquement déterminant. 4.2.13. Dans les paragraphes qui suivent, le terme "champ" sera utilisé pour désigner indistinctement des champs primaires et/ou des sous-champs, sauf indication contraire. 4.2.14. Les champs d'un message peuvent être facultatifs ou obligatoires, selon leur syntaxe. 4.3. Champs non identifiés 4.3.1. Tout champ inconnu apparaissant dans un message doit être négligé. 4.3.2. En d'autres termes, si le système qui analyse le message ne reconnaît pas un mot-clé, il négligera automatiquement l'intégralité du texte jusqu'au prochain champ primaire connu, qui ne se situe pas dans un champ de listage. 4.3.3. Selon l'intitulé du message, le champ négligé pourra entraîner ou non un rejet de l'ensemble du message.NOTE Il convient de noter que si l'ADEXP est conçu pour offrir une telle souplesse d'utilisation, il appartient aux responsables de la définition des besoins en matière d'interface de préciser, pour chaque message, la manière dont le système devrait réagir en présence d'un champ non identifié. 4.3.4. Si le champ inconnu est un champ de listage (il débute par le mot-clé BEGIN), son contenu (jusqu'au mot-clé END correspondant) est intégralement négligé. 4.3.5. Pour éviter toute ambiguïté au cours de la reprise consécutive au saut d'un champ non identifié, il est impératif qu'un même mot-clé introduise soit un champ primaire, soit un sous-champ (mais pas les deux). 4.3.6. On peut ainsi distinguer deux types de mot-clé: - mots-clés primaires; - mots-clés secondaires. 4.3.7. Une fois qu'il a été défini comme appartenant à l'une des deux catégories, le mot-clé ne peut plus être réutilisé dans un autre groupe de messages sous couvert de l'autre catégorie, sauf s'il se situe à l'intérieur d'un champ de listage. En effet, des occurrences internes d'un mot-clé primaire sont possibles au sein d'un champ de listage sans que cela ne crée d'ambiguïté, le mot-clé BEGIN indiquant que l'occurrence interne peut être considérée comme un sous-champ.Exemples (d'utilisation de types de mot-clé) 1. Champ primaire -RFL F330 2. Sous-champ: toujours au sein d'un champ composé -GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W où -GEO est un champ composé primaire et -GEOID, -LATTD et LONGTD sont des sous-champs. 3. Champ de listage -BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID ... -END RTEPTS où "-BEGIN" est l'indicateur de champ de listage et RTEPTS, un champ primaire. NOTE "-RFL" est défini comme un champ primaire. L'inclusion dans un champ de listage constitue le seul cas où un champ primaire peut être utilisé en tant que sous-champ (cf. exemple 3 ci-dessus). 5. RÈGLES SYNTAXIQUES ADEXP 5.1. Éléments lexicaux 5.1.1. Jeu de caractères 5.1.1.1. Le jeu de caractères à utiliser pour l'échange de messages en format ADEXP est l'alphabet international no 5 (IA-5), tel que défini en référence 1. 5.1.1.2. Le format ADEXP est conçu pour les échanges d'ordinateur à ordinateur par l'intermédiaire de différents réseaux informatiques ou de liaisons intercalculateurs spécialisées. Par ailleurs, certains messages ADEXP, notamment les messages ayant trait à la planification des vols et à l'ATFM, doivent pouvoir être échangés sur le Réseau du service fixe des télécommunications aéronautiques (RSFTA). 5.1.1.3. Le jeu de caractères des messages susceptibles de devoir être transmis via le RSFTA doit être limité aux caractères présentant une corrélation directe entre l'alphabet télégraphique international no 2 (ITA-2) et l'IA-5, tel que défini en référence 1.NOTE Outre les caractères graphiques et les commandes de mise en page énumérés ci-après, le jeu de caractères ITA-2 définit également une série de "signaux" (bande perforée par exemple). Ces signaux ne font pas partie des caractères admis pour les messages ADEXP. 5.1.1.4. Seuls les caractères graphiques et commandes de mise en page ci-après peuvent être utilisés dans les messages ADEXP susceptibles d'être transmis via le RSFTA: Caractères graphiques a. majuscules (A à Z) b. chiffres (0 à 9) c. caractères graphiques spéciaux suivants: 1. espace " " 2. parenthèse gauche "(" 3. parenthèse droite ")" 4. tiret "-" 5. point d'interrogation "?" 6. deux points ":" 7. point "." 8. virgule "," 9. apostrophe "'" 10. signe égal "=" 11. signe plus "+" 12. barre oblique "/" Commandes de mise en page a. retour de chariot b. changement de ligne 5.1.2. Unités lexicales de base La présente spécification admet les unités lexicales de base suivantes: - ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z' - DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' - ALPHANUM ::= ALPHA | DIGIT - SPACE ::= ' ' - HYPHEN ::= '-' - FEF ::= Carriage_return | Line_Feed - SEP ::= 1{ SPACE | FEF } - SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/' - CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN - LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF - START-OF-FIELD ::= HYPHEN NOTE LIM_CHAR représente n'importe quel caractère admis à l'exception du tiret ("HYPHEN"), qui sert exclusivement à indiquer le début d'un champ. En revanche, CHARACTER représente n'importe quel élément admis du jeu de caractères. 5.1.3. Lignes et séparateurs 5.1.3.1. La subdivision en lignes du texte d'un message n'a aucune incidence sur le plan syntaxique. 5.1.3.2. Un séparateur peut être un espace ou une commande de mise en page. 5.1.3.3. Les champs ne sont délimités que par la présence d'un caractère de début de champ suivi d'un mot clé. 5.1.3.4. Un message pourrait donc être valablement formulé en une seule ligne. 5.1.4. Valeurs affectées d'un signe 5.1.4.1. Il peut être nécessaire de mentionner une valeur numérique négative. 5.1.4.2. Les champs requis pour indiquer une valeur négative doivent, dans leur définition syntaxique, mentionner explicitement que la valeur est affectée d'un signe, positif ou négatif. Tout champ qui ne serait pas défini de la sorte ne peut représenter une valeur négative. 5.1.4.3. Une valeur affectée d'un signe doit toujours être précédée de la lettre "N", pour négatif, ou "P", pour positif. Une valeur zéro peut indistinctement être précédée de "N" ou de "P". 5.1.4.4. La syntaxe d'un champ qui admet une valeur affectée d'un signe doit se présenter comme suit: '-' "KEYWORD" ("P" | "N") ! 1{DIGIT} Exemple Un champ intitulé "NUMBER" pouvant contenir une valeur négative de un à huit chiffres se définirait comme suit: ''-' "NUMBER" ("P" | "N") ! 1{DIGIT}8 d'où: -NUMBER P5 - valeur correspondant à +5 -NUMBER N5 - valeur correspondant à -5 -NUMBER 5 - syntaxe non valable, il doit obligatoirement y figurer un "P" ou un "N" 5.1.5. Mots-clés 5.1.5.1. Un mot-clé est composé d'une séquence de majuscules ou de chiffres. Le mot-clé n'introduit un champ que s'il est précédé d'un caractère de début de champ («-«). keyword ::= 1{ ALPHANUM } 5.1.5.2. Les mots-clés doivent respecter la syntaxe suivante: '-'!{SEP}!"KEYWORD"!1{SEP}! < subfield/s or contained value > d'où il ressort qu'un mot-clé sera séparé de son caractère de début de champ par zéro séparateur ou plusieurs. Il sera immédiatement suivi d'un ou de plusieurs séparateurs, puis du ou des sous-champ(s) correspondant(s) ou de la valeur contenue. NOTE Il convient de noter qu'un mot-clé peut être séparé du caractère de début de champ qui le précède par un nombre indéterminé de séparateurs, y compris zéro. Exemples (Les séquences suivantes introduisent toutes valablement un champ) 1. -TITLE IFPL 2. - TITLE IFPL 3. - TITLE IFPL 4. - TITLE IFPL 5.1.5.3. Recommandation Il est recommandé d'éviter de placer un séparateur entre le caractère de début de champ "-" et le mot-clé qui suit.NOTE 1. Dans les exemples ci-dessus, la première occurrence constitue la solution recommandée. 2. Il est également important de noter qu'un mot-clé doit être immédiatement suivi d'un séparateur au moins. 5.1.5.4. Dans le présent document, la concaténation d'éléments séparés par un séparateur au moins est implicitement représentée par la notation de "concaténation souple" (cf.3.5).NOTE Ainsi qu'il est expliqué plus loin, les mots-clés introduisent également des champs de listage lorsque ceux-ci sont précédés du mot-clé BEGIN. 5.1.5.5. Les mots-clés doivent être aussi courts que possible tout en restant sémantiquement significatifs. 5.1.5.6. >EMPLACEMENT TABLE> 5.1.5.7. Pour prévenir toute ambiguïté (double emploi d'un même mot-clé dans des acceptions différentes) ou redondance (mots-clés différents ayant la même signification), un Tableau central de définitions des champs primaires (mots-clés primaires) figure à l'Annexe A (A3) de la présente Norme; un Tableau central de définitions des sous-champs (mots-clés secondaires) est également inclus à l'Annexe A (A4). 5.2. Champs 5.2.1. Syntaxe des champs field ::= basic_field | structured_field | list_field basic_field ::= '-' keyword contained_values contained_values ::= {CHARACTER} list_field ::= '-' "BEGIN" keyword {subfields} '-' "END" keyword structured_field ::= '-' keyword field_1 field_2 ...field_n NOTE Comme on le verra, dans le cas des champs de listage, le mot-clé n'est pas directement précédé d'un '-' mais de la construction '-' "BEGIN". 5.2.2. Composition des messages au niveau des champs 5.2.2.1. Le premier champ d'un message ADEXP doit toujours être un champ TITLE (c'est-à-dire un champ introduit par le mot-clé TITLE). 5.2.2.2. Les autres champs primaires constituant le message sont définis par son TITLE. 5.2.2.3. La syntaxe des messages correspondant à un TITLE donné est définie par les champs qui le composent (lesquels sont définis par leur mot-clé): - nom et contenu autorisé de ses champs primaires; - nom et contenu autorisé de ses sous-champs. 5.2.3. Champs simples 5.2.3.1. La syntaxe des champs simples se présente comme suit: basic_field ::= '-' keyword contained_values 5.2.3.2. L'expression "contained_values" définit le texte précisant la valeur du champ et ne peut introduire aucun sous-champ.Exemple de règle arctyp ::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")NOTES 1. Un équivalent explicite serait: arctyp ::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ"). 2. Exemple de portion de message: "-ARCTYP ZZZZ". 5.2.3.3. Recommandation Lorsqu'un champ simple comprend plus de deux valeurs contenues et qu'il y a lieu, par ailleurs, d'exprimer un choix ou une option parmi les valeurs, il est recommandé de convertir le champ en champ structuré et d'inclure les valeurs contenues dans les sous-champs. 5.2.4. Champs de listage 5.2.4.1. La syntaxe des champs de listage se présente comme suit: list_field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword 5.2.4.2. Les sous-champs peuvent se présenter sous la forme de n'importe quelle combinaison de sous-champs susceptible d'apparaître zéro fois ou plus dans le champ de listage. 5.2.4.3. La liste des sous-champs d'un champ de listage doit former un ensemble ordonné (l'ordre de succession des sous-champs est significatif).Exemple de règle addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"NOTES 1. Il ressort de l'exemple ci-dessus qu'un champ "addr" est un champ de listage contenant 0 occurrence ou plus d'un sous-champ "fac" (une installation ATS). 2. Exemple de portion de message où ADDR est un champ de listage comprenant des sous-champs FAC: -BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR. 3. Exemple de portion de message faisant apparaître une combinaison de sous-champs: xxx ::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX". 5.2.5. Champs structurés 5.2.5.1. La syntaxe des champs structurés se présente comme suit: structured_field ::= '-' keyword field_1 field_2...field_n 5.2.5.2. Les sous-champs admis dans un champ structuré sont exclusivement fonction du champ structuré lui-même. 5.2.5.3. L'ordre d'apparition des sous-champs dans un champ structuré n'est pas significatif, ce qui facilite les extensions ultérieures (addition de nouveaux sous-champs).Exemple de règle pt ::= '-' "PT" ptid [fl] [eto] NOTES 1. Dans l'exemple ci-dessus, "pt" est un champ structuré comprenant un point (sous-champ "ptid"), suivi, facultativement, d'un niveau de vol calculé (sous-champ "fl") et d'une estimée de passage à la verticale du point (sous-champ "eto"). 2. Un type d'occurrence de ce champ pourrait être: "-PT -PTID RMS -FL F250 -ETO 921225120000". 5.2.5.4. Recommandation Si le contenu d'un champ est appelé à évoluer avec le temps, il est souhaitable d'en faire un champ structuré: il sera alors possible de procéder à des extensions progressives de ses sous-champs. Au contraire, si un champ simple peut s'avérer plus aisé et plus courant à utiliser, il n'en impose pas moins une séquence fixe des éléments (valeurs) et offre très peu de possibilités d'extension. 5.2.6. Le champ COMMENT (observations) 5.2.6.1. Le champ COMMENT introduit une zone de texte libre dans laquelle tous les caractères, à l'exception du caractère de début de champ ('-'), peuvent être utilisés; cette zone s'étend jusqu'au champ suivant: comment ::= '-' "COMMENT" { LIM_CHAR } Exemple -COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA 5.2.7. Le champ TITLE (intitulé) 5.2.7.1. Un message ADEXP doit toujours commencer par un champ TITLE, dont la syntaxe se présente comme suit: title ::= '-' "TITLE" 1{ ALPHA }10 5.2.7.2. Les valeurs possibles du champ TITLE consistent en l'ensemble des intitulés de message répertoriés dans l'Annexe B de la présente Norme.Exemple -TITLE IFPL 6. DESCRIPTION NORMALISEE DES MESSAGES ADEXP 6.1. Introduction 6.1.1. Les paragraphes qui suivent définissent la façon dont le format ADEXP des différentes catégories de messages ATS doit être décrit de manière normalisée dans le cadre de présente Norme. 6.1.2. Cette description normalisée comprend: - la définition des termes auxiliaires; - la définition syntaxique et sémantique de chaque champ primaire; - la définition syntaxique et sémantique de chaque sous-champ; - la définition de chaque groupe de messages avec renvoi aux documents de spécification. 6.1.3. La présente Norme ne détaille ni la composition des champs, ni les règles d'insertion des données pour chaque intitulé de message. 6.1.4. Il convient de se référer aux documents de spécification (spécification d'interface) pour chaque groupe de messages (cf. section 6.5.7). 6.1.5. Les documents de spécification devraient fournir les informations ci-après pour chaque intitulé de message: - liste des champs primaires obligatoires; - liste des champs primaires facultatifs; - règles d'insertion des données pour chaque champ et, en particulier, règles d'utilisation des sous-champs définis comme facultatifs dans la présente Norme; - règles de reprise suite à la détection d'un champ non identifié. 6.1.6. Les champs actuellement définis et convenus, au niveau de l'ensemble des Etats membres d'Eurocontrol, pour être utilisés dans les différentes catégories de messages ADEXP sont répertoriés dans l'Annexe A du présent document. 6.1.7. Un champ ne peut être utilisé à d'autre fin que celle qui est spécifiée dans sa description sémantique. 6.1.8. Un index central des champs réservés figure à l'Annexe D. L'utilisation de champs réservés dans les messages ADEXP actuellement spécifiés n'a pas été approuvée. Il s'agit typiquement de champs définis en prévision d'une éventuelle utilisation future ou de champs utilisés à l'échelon local par des systèmes nationaux. Leur inclusion dans la présente Norme vise à faciliter l'unicité des intitulés de champ et à prévenir les redondances inutiles. 6.2. Termes auxiliaires 6.2.1. Pour obtenir une définition lisible des champs, il est souvent utile d'introduire des termes auxiliaires dans la description grammaticale. 6.2.2. Ces termes auxiliaires ne servent pas à introduire un champ ou un sous-champ et ne sont donc pas associés à un mot-clé particulier. Ils sont toutefois susceptibles d'apparaître dans la définition de plusieurs champs, sous-champs ou éléments auxiliaires. A titre d'exemple, un terme auxiliaire comme "date" peut apparaître dans la définition de nombreux champs. 6.2.3. Tous les termes auxiliaires nécessaires doivent être présentés dans l'ordre alphabétique; ils sont définis dans l'Annexe A (A2) de la présente Norme. 6.2.4. >EMPLACEMENT TABLE> 6.3. Définition des champs primaires 6.3.1. Tous les champs primaires utilisés dans les messages ADEXP doivent être conformes à la syntaxe et à la sémantique spécifiées à l'Annexe A (A3) de la présente Norme. 6.3.2. La syntaxe de chaque champ est donnée en premier lieu, suivie du contenu sémantique décrit en termes clairs et précis. 6.3.3. La syntaxe des champs est exprimée dans le système de notation BNF présenté à la section 3 de la présente Norme. 6.3.4. >EMPLACEMENT TABLE> 6.4. Définition des sous-champs 6.4.1. Tous les sous-champs utilisés dans les messages ADEXP doivent être conformes à la syntaxe et à la sémantique spécifiées à l'Annexe A (A4) de la présente Norme. 6.4.2. Pour faciliter les renvois, les champs primaires dans lesquels apparaît un sous-champ donné sont également mentionnés. 6.4.3. Etant donné qu'un sous-champ peut également être un sous-champ d'autres sous-champs, un renvoi à ceux-ci est également fait. 6.4.4. >EMPLACEMENT TABLE> 6.5. Groupes de messages 6.5.1. Les catégories opérationnelles (groupes) de messages à utiliser dans le format ADEXP sont présentées à l'Annexe E de la présente Norme. 6.5.2. Ces groupes sont définis par la nature opérationnelle des messages échangés et se caractérisent le plus souvent par les systèmes utilisés. 6.5.3. Il convient, pour chaque groupe de messages, de renvoyer aux documents de spécification correspondants. 6.5.4. Une valeur TITLE utilisée pour un groupe de messages ne peut en aucun cas être réutilisée pour un autre groupe dans une acception différente. 6.5.5. Un index central des intitulés de message figure à l'Annexe B de la présente Norme. 6.5.6. Chaque intitulé de message figurant dans cet index central est assorti d'un renvoi au groupe de messages correspondant de sorte que le renvoi aux documents de spécification s'opère via le groupe de messages. 6.5.7. Un index central des intitulés de message réservés figure également à l'Annexe C. L'utilisation de ces intitulés de message réservés dans les groupes de messages ADEXP actuellement spécifiés n'a pas été approuvée. Il s'agit typiquement de messages définis en prévision d'une éventuelle utilisation future au sein d'un des groupes ou de messages utilisés à l'échelon local par des systèmes nationaux. Leur inclusion dans la présente Norme vise à faciliter l'unicité des appellations de message et à prévenir les redondances inutiles. ANNEXE A (Normative) DEFINITIONS DES CHAMPS ADEXP A.1. Introduction La présente Annexe comporte la liste de tous les champs - termes auxiliaires, champs primaires et sous-champs - spécifiés pour le format ADEXP. A.2. Termes auxiliaires ADEXP >EMPLACEMENT TABLE> A.3. Champs primaires ADEXP >EMPLACEMENT TABLE> A.4. Sous-champs ADEXP >EMPLACEMENT TABLE> ANNEXE B (Normative) INDEX CENTRAL DES INTITULÉS DE MESSAGE ADEXP >EMPLACEMENT TABLE> ANNEXE C (Normative) INDEX CENTRAL DES INTITULES DE MESSAGE RESERVES C.1. Introduction La présente annexe comporte un index central des intitulés de message réservés, qui n'ont pas encore été définis pour être utilisés en ADEXP. Le fait que ces messages figurent dans la présente annexe signifie qu'ils sont appelés à être utilisés dans l'avenir ou qu'ils le sont déjà, mais à l'échelon local uniquement. C.2. Objet L'établissement d'une liste des intitulés n'ayant pas encore été adoptés officiellement aux fins d'utilisation dans le cadre de la présente Norme ADEXP vise à prévenir, dans toute la mesure possible, les risques de redondance, lorsqu'un nouvel intitulé est requis pour un besoin particulier, ou l'adoption d'un intitulé déjà utilisé au sein d'un système local. C.3. Intitulés de messages réservés >EMPLACEMENT TABLE> ANNEXE D (Normative) INDEX CENTRAL DES CHAMPS RESERVES D.1. Introduction La présente annexe comporte un index central des champs réservés - champs primaires, sous-champs et termes auxiliaires - qui n'ont pas encore été définis pour être utilisés en ADEXP. Leur inclusion dans la présente annexe signifie qu'ils sont appelés à être utilisés dans l'avenir ou qu'ils le sont déjà, mais à l'échelon local uniquement. D.2. Objet L'établissement d'une liste des champs n'ayant pas encore été adoptés officiellement aux fins d'utilisation dans le cadre de la présente Norme ADEXP vise à prévenir, dans toute la mesure possible, les risques de redondance, lorsqu'un nouveau champ est requis pour un besoin particulier, ou l'adoption d'un mot-clé déjà utilisé au sein d'un système local. D.3. Termes auxiliaires réservés >EMPLACEMENT TABLE> D.4. Champs primaires réservés >EMPLACEMENT TABLE> D.5. Sous-champs réservés >EMPLACEMENT TABLE> ANNEXE E (Informative) PRÉSENTATION DES GROUPES DE MESSAGES INTRODUCTION La présente Annexe présente les différents groupes ou catégories de messages qui peuvent être échangés en ADEXP. La liste complète des intitulés de message ADEXP figure à l'Annexe B. NOTE On se référera, pour ce qui est des conditions et règles précises d'application et d'utilisation des champs, en particulier l'emploi des champs facultatifs, à la documentation utile (par ex. Spécifications d'interface) des systèmes considérés. E.1. Messages de plan de vol E.1.1. Introduction Les messages relevant de cette catégorie sont échangés principalement entre les AO, l'IFPS et les organismes ATS compétents. E.1.2. Définition des intitulés de message Les messages relevant de cette catégorie portent les intitulés suivants: ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQS, ISPL, MAN, RCHG, RCNL, REJ. Tous les éléments de définition de ces messages figurent dans le document cité en réf. 3. E.1.3. Composition des champs primaires La définition détaillée de la teneur des messages, les règles d'insertion de données et le mode d'utilisation des champs obligatoires et facultatifs sont énoncés dans le document cité en réf. 3. Example Flight Plan Message -TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC EGZYTTTE -FAC EGTTZGZP -FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC LPPCIFPS -FAC LPPTYWYA -FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS -END ADDR -ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -CEQPT S -EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686 -ORGNID AZXRPLO -SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -SPEED N0400 -FLTRUL I -FLTTYP S -ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS UG41 FTM -BEGIN RTEPTS -PT -PTID EGKK -FL F000 -ETO 980305113000 -PT -PTID SAM -FL F196 -ETO 980305114012 -PT -PTID ASPEN -FL F288 -ETO 980305114658 -PT -PTID ORTAC -FL F311 -ETO 980305114959 -PT -PTID GUR -FL F330 -ETO 980305115617 -PT -PTID AKEMI -FL F330 -ETO 980305120118 -PT -PTID LARSI -FL F330 -ETO 980305120626 -PT -PTID QPR -FL F330 -ETO 980305121236 -PT -PTID ERWAN -FL F330 -ETO 980305123152 -PT -PTID LOTEE -FL F330 -ETO 980305124401 -PT -PTID AVS -FL F330 -ETO 980305125357 -PT -PTID KORET -FL F330 -ETO 980305130137 -PT -PTID BARKO -FL F330 -ETO 980305130734 -PT -PTID CANAR -FL F330 -ETO 980305131544 -PT -PTID VIS -FL F330 -ETO 980305132220 -PT -PTID FTM -FL F234 -ETO 980305133230 -PT -PTID LPPT -FL F000 -ETO 980305134529 -END RTEPTS -ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS -ATSRT UG41 AVS FTM E.2. Messages de gestion des courants de trafic aérien E.2.1. Introduction Les messages relevant de cette catégorie sont échangés principalement entre le système TACT du CFMU d'Eurocontrol, les exploitants d'aéronefs et les organismes ATS. E.2.2. Messages d'allocation de créneaux assistée par ordinateur (CASA) Les messages relevant de cette catégorie portent les intitulés suivants: DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR. E.2.2.1. Définition des intitulés de message Tous les éléments de définition de ces messages figurent dans le document cité en réf. 5. E.2.2.2. Composition des champs primaires La définition détaillée de la teneur des messages, les règles d'insertion de données et le mode d'utilisation des champs obligatoires et facultatifs sont énoncés dans le document cité en réf. 5. Example -TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945 -CTOT 010 -REGUL UZZU11 -TAXITIME 0020 E.2.3. Messages d'information Les messages relevant de cette catégorie portent les intitulés suivants: ANM, CNLCOND, CNLREG, EXCOND, FSA, MODCOND, MODREG, MRA, MRCNL, MRMOD, NEWREG, NTA, NTACNL, NTAMOD, OLRA, OLRCNL, OLRMOD. E.2.3.1. Définition des intitulés de message Les éléments de définition de ces messages figureront dans le document "AME System Interface Specification" (Spécification d'interface du système AME). Le mode d'utilisation du message ANM est décrit dans le document initulé "ATFM User Manual" (Manuel des utilisateurs ATFM). E.2.3.2. Composition des champs primaires La définition détaillée de la teneur des messages, les règles d'insertion de données et le mode d'utilisation des champs obligatoires et facultatifs seront énoncés dans le document "AME System Interface Specification". Example First System Activation Message -TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646 E.3. Messages de coordination ATC E.3.1. Introduction Les messages de coordination sont utilisés pour automatiser la coordination opérationnelle et l'échange d'informations entre organismes ATC. Ils assurent la transmission, dans les délais voulus, des informations opérationnelles requises pour la coordination au moyen de fonctions normalisées d'extraction et de transmission des données. E.3.2. Définition des intitulés de message Les messages relevant de cette catégorie portent les intitulés suivants: ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM. Tous les éléments de définition de ces messages figurent dans le document cité en réf. 6. E.3.3. Composition des champs primaires Tous les éléments de définition de ces messages figurent dans le document cité en réf. 6. Examples Hand-Over Proposal Message -TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN Activate Message -TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON E.4. Messages de gestion de l'espace aérien E.4.1. Introduction Messages utilisés pour la coordination de la gestion de l'espace aérien. Ils couvrent la gestion de l'environnement dans lequel évolue le trafic: routes permanentes et conditionnelles, zones de ségrégation temporaire, zones dangereuses et interdites, etc. E.4.2. Définition des intitulés de message Les messages relevant de cette catégorie portent les intitulés suivants: AUP, CRAM, UUP. Tous les éléments de définition de ces messages figurent dans le document cité en réf. 7. E.4.3. Composition des champs primaires Tous les éléments de définition de ces messages figurent dans le document cité en réf. 7. Example Conditional Route Availability Message -TITLE CRAM -PART -NUM 001 -LASTNUM 010 -FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600 -BEGIN LACDR -AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600 -AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730 -AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600 -AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730 -AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600 -AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530 -AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL -FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330 -END LACDR E.5. Messages de coordination civile / militaire E.5.1. Introduction Messages utilisés pour la coordination des données de vol et des demandes de traversée d'espace aérien entre organismes ATS civils et militaires. E.5.2. Définition des intitulés de message Les messages relevant de cette catégorie portent les intitulés suivants: ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ. Tous les éléments de définition de ces messages figurent dans le document cité en réf. 7. E.5.3. Composition des champs primaires Tous les éléments de définition de ces messages figurent dans le document cité en réf. 7. Example Crossing Clearance Request Message -TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ -SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP F111 -SECTOR SOUTH -BEGIN RTEPTS -PT -PTID GEO01 -TO 1630 -FL F250 -PT -PTID GEO02 -TO 1631 -FL250 -END RTEPTS -GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E -GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E Acceptance Message -TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ -SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ -SEQNUM 012 ANNEXE F (Informative) EXEMPLES DE FORMAT DE MESSAGES ADEXP Les exemples ci-après sont donnés à titre d'illustration du format ADEXP et non de la teneur du message. Le message utilisé en l'occurrence est un IFPL; bien que correcte au moment de la publication, l'exactitude de la composition des champs, notamment, n'est pas garantie. L'EXEMPLE N° 1 est présenté de manière très lisible grâce à l'emploi de retours chariot, de changements de ligne, de décrochements, etc. Ce format de présentation ne s'inscrit toutefois pas dans les règles de formatage ADEXP. La présentation du message est donc laissée à la discrétion du système récepteur. Les EXEMPLES No 2 et N° 3 constituent, tous deux, des représentations valables du même message que celui donné dans l'EXEMPLE No 1. EXAMPLE 1 -TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -CEQPT SDMRY -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M -TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO 9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS EXAMPLE 2 -TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M -TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO 9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS EXAMPLE 3 -TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS ANNEXE G (Informative) DEVELOPPEMENTS FUTURS G.1. Introduction La présente Annexe a pour objet de donner une indication du développement futur de l'ADEXP tel qu'il est envisagé, et d'en exposer les motifs et les objectifs. G.2. Objectifs L'un des objectifs majeurs poursuivis dans le cadre de la mise au point de l'ADEXP était le développement d'un format permettant à un système récepteur de "ne pas prendre en compte" ou de "sauter" un champ inconnu ou non identifié sans pour autant devoir invalider le message en cours de traitement. Il est ainsi possible d'ajouter un nouveau champ dans un message sans qu'il soit nécessaire de modifier à l'avance tous les systèmes récepteurs pour procéder ensuite à un transfert très soigneusement coordonné. La souplesse considérable qui en résulte est l'un des avantages du format ADEXP. Cet objectif est atteint dans le cadre de la présente Norme par le recours à des champs primaires et à des sous-champs prédéfinis, introduits par des mots clés uniques. Un analyseur lexical ou syntaxique qui ne "reconnaît" pas un mot clé doit sauter l'ensemble du texte jusqu'au prochain champ primaire connu, qui ne se situe pas dans un champ de listage ("List Field"). La reprise s'opère dès lors au niveau des champs primaires. Le développement actuel et futur de la définition de nouveaux messages donne à penser qu'un degré de complexité accru est requis dans certains domaines, où des emboîtements de champs de troisième, voire de quatrième niveau sont nécessaires. (Le message d'allocation de route conditionnelle (CRAM) constitue une illustration actuelle de ce besoin). Actuellement, l'ADEXP permet de construire un message avec n'importe quel niveau d'emboîtement. Il ne permet cependant pas encore une reprise consécutive à la détection d'un sous-champ non identifié au troisième ou au quatrième niveau d'emboîtement, sans risque d'interprétation erronée des données ou sans obligation d'invalider le message. Les modifications que l'on se propose d'apporter au format ADEXP visent à faire en sorte qu'un analyseur lexical ou syntaxique puisse, à tout moment, déterminer où il se situe dans la structure d'un message ou d'un champ particulier et ce faisant, à permettre une reprise à n'importe quel niveau d'emboîtement sans risque d'interprétation erronée des données. G.3. Proposition Pour atteindre l'objectif d'une reprise à n'importe quel niveau, il est nécessaire que l'analyseur lexical puisse repérer à la fois la fin et le début d'un champ. Le format actuel permet seulement d'indiquer le début du champ au moyen du signe "-". Il sera proposé, dans une version ultérieure de l'ADEXP, de recourir aux parenthèses pour indiquer respectivement le début et la fin d'un champ. Le signe actuel "-" de début de champ serait remplacé par la parenthèse gauche "(". La fin de champ, qui n'est pas représentée de manière explicite à ce stade, serait signalée par la parenthèse droite ")". Les exemples ci-après illustrent ce principe. Exemples >EMPLACEMENT TABLE> ANNEXE III DOCUMENT DE CONTRÔLE D'INTERFACE POUR L'ÉCHANGE DE DONNÉES DE VOL (FDE-ICD), ÉDITION 1.0 (document de référence Eurocontrol COM.ET1.ST12-STD) TABLE DES MATIÈRES >EMPLACEMENT TABLE> DROIT D'AUTEUR Le présent document a été élaboré par l'Agence Eurocontrol, qui en détient les droits d'auteur. Le contenu du présent document est librement accessible, en tout ou en partie, aux représentants des États membres, toute reproduction ou divulgation à des tiers étant toutefois subordonnée à une autorisation préalable de l'Agence Eurocontrol. AVANT-PROPOS 1. Organe compétent La présente Norme a été établie par le l'équipe spéciale "Échange de données relatives aux plans de vol" (FPDE) de l'Organisation européenne pour la sécurité de la navigation aérienne (Eurocontrol), qui en assure également l'actualisation. 2. Programme de travail EATCHIP La présente Norme se rapporte à la Tâche spécialisée no 12, Mission d'encadrement 01, Domaine Communications, du Programme de travail EATCHIP (EWPD). 3. Approbation de la Norme 3.1. La présente Norme est adoptée conformément aux procédures exposées dans les Directives pour la normalisation à Eurocontrol, réf. 000-2-93. 3.2. Elle prend effet dès son adoption par la Commission permanente d'Eurocontrol et remplace la Norme Eurocontrol relative à l'échange de données en ligne (OLDI), Edition 1, 3e partie: EXIGENCES TECHNIQUES (Document relatif au contrôle d'interface à court terme), réf. 001-3-92. 4. Rectificatifs techniques et amendements La présente Norme fait l'objet d'un suivi aux fins d'introduction des amendements ou rectificatifs techniques requis. La procédure d'actualisation est décrite à l'Annexe H des Directives pour la rédaction et la présentation uniformes des documents normatifs Eurocontrol, réf. 000-1-92. 5. Conventions rédactionnelles 5.1. Le format de présentation de la présente Norme est conforme aux Directives pour la rédaction et la présentation uniformes des documents normatifs Eurocontrol. 5.2. Afin de mettre en relief le statut de chaque élément, il a été décidé d'adopter les dispositions typographiques suivantes: - les éléments normatifs sont imprimés en caractères ordinaires; - les éléments recommandés sont imprimés en italiques, le statut étant indiqué par le préfixe Recommandation. 5.3. Pour la rédaction des spécifications, il a été décidé d'adopter les dispositions suivantes: pour les éléments normatifs, on utilisera la forme verbale "doit" ("shall" en anglais) dans le cas des éléments recommandés, on utilisera la formule "il convient de" ("should" en anglais). 5.4. À titre exceptionnel, les tableaux des pages E.7 et E.8 ne comportent aucun alinéa ni report sur la page suivante, de façon à garantir une présentation adéquate des Listes de spécifications de profil (PRL). 6. Lien avec d'autres documents normatifs 6.1. La présente Norme Eurocontrol remplace le Document relatif au contrôle d'interface à court terme (ST-ICD), 3e partie de l'Édition 1 de la Norme Eurocontrol OLDI [Référence 13]. 6.2. Elle constitue le premier volet d'une série de documents normatifs Eurocontrol concernant le contrôle d'interface (ICD) pour l'échange de données de vol. 7. Statut des Annexes Les Annexes à la présente Norme ont le statut suivant: - Annexe A - Normative - Annexe B - Normative - Annexe C - Normative - Annexe D - Normative - Annexe E - Normative - Annexe F - Informative - Annexe G - Informative - Annexe H - Informative 8. Langue utilisée Le texte original de la présente Norme a été rédigé en langue anglaise. 1. INTRODUCTION La présente Norme Eurocontrol s'appuie sur le Document relatif au contrôle d'interface à court terme établi par l'ancien Sous-groupe technique OLDI qui avait été chargé de définir les nouvelles normes d'interface pour l'exploitation future des échanges OLDI entre centres de contrôle régional. Auparavant, les liens OLDI reposaient sur des protocoles brevetés, tels que l'INTERCAUTRA ou le Datenübertragungs- und Verteilungssystem (DÜV), faisant appel à des circuits point à point ou à des réseaux limités et nécessitant l'emploi de matériel ou de logiciel spécialisé. Pour la plupart des nouvelles liaisons prévues, il a été jugé souhaitable de s'orienter vers une architecture de réseaux et d'adopter des normes de télécommunications internationales, les liaisons pouvant ainsi être exploitées de façon plus rentable, grâce à une réduction du nombre de connexions à chaque centre et à l'emploi de matériel et de logiciel disponibles sur le marché. La présente Norme Eurocontrol donne une forme définitive et complète à l'ICD à court terme qui a été remanié de façon à définir des spécifications plus rigoureuses devant permettre de renforcer l'interopérabilité. En outre, elle pourra servir de point de départ pour l'élaboration des futurs ICD destinés à répondre à l'évolution des besoins dans le domaine de l'échange des données de vol (FDE), notamment avec le recours accru aux réseaux partagés et l'introduction de normes nouvelles pour les couches inférieures. La présente Norme Eurocontrol offre un ensemble minimum de fonctions qui peuvent être exploitées par les réalisations OLDI existantes moyennant un minimum de modifications, en utilisant soit des liaisons point à point, soit des réseaux à commutation par paquets conformes à la recommandation X.25 du Comité consultatif international télégraphique et téléphonique (CCITT) de 1980 ou ses versions ultérieures. Pour les achats, d'autres possibilités peuvent être spécifiées. Le présent document relatif au contrôle d'interface ne fait pas obstacle à la poursuite des accords bilatéraux conclus. Les services souhaitant exploiter d'autres protocoles d'application en sus ou en remplacement de celui décrit dans le présent document peuvent, soit solliciter l'amendement du présent protocole, soit s'en démarquer en utilisant des circuits virtuels différents. 2. DOMAINE D'APPLICATION 2.1. La présente Norme Eurocontrol définit les spécifications d'une interface de communication de données en vue de l'échange, entre Centres de contrôle régional (CCR), de messages contenant des données de vol. Elle est présentée sous forme de profil d'interconnexion de systèmes ouverts (OSI), suivant la définition donnée dans le rapport technique (TR) 10000-2 de l'Organisation internationale de normalisation/la Commission électrotechnique internationale (ISO/IEC) [Référence 3]. Le profil traite à la fois des couches inférieures (Profil T) et des couches supérieures (Profil A). 2.2. Les dispositions de la présente Norme Eurocontrol s'appliquent dans les circonstances suivantes: - appui à OLDI tel qu'il est exposé dans la Norme Eurocontrol No 001-92 Edition 1; - appui à la transmission de messages d'application OLDI entre les CCR et les systèmes de l'Organisme central de gestion des courants de trafic aérien (CFMU). 2.3. Les dispositions de la Norme sont applicables aux connexions utilisant soit: - des liaisons spécialisées en point à point, - des circuits point à point du réseau téléphonique public commuté (RTPC), - des réseaux de données à commutation par paquets ou des réseaux interconnectés de données à commutation par paquets disposant d'une interface conforme à la recommandation X.25 du CCITT en date de 1980 ou à une version ultérieure. NOTES 1. Les modalités d'interface entre Systèmes de traitement des plans de vol (FPPS) sont représentées à la Figure 1. 2. La Figure 1 ne tient pas compte des éventuelles connexions de secours, tels que le RTPC, pour lesquelles des indications sont données dans l'Annexe H. Figure 1 Modalités d'interface >PIC FILE= "L_2000254FR.017801.EPS"> 2.4. Un examen détaillé des questions de sécurité de l'interface de communication de données spécifiée n'entre pas dans le cadre de la présente Norme. On trouvera cependant des dispositions générales au paragraphe 5.4 de l'Annexe C ainsi que d'autres indications à l'Annexe H. 3. RÉFÉRENCES 3.1. Introduction Les documents et normes ci-après contiennent des dispositions qui, par suite de la référence qui en est faite, constituent des dispositions de la présente Norme Eurocontrol. Les éditions indiquées sont celles qui étaient en vigueur au moment de la publication de la présente Norme Eurocontrol. Toute révision des documents de l'Organisation de l'aviation civile internationale (OACI) cités en référence doit être immédiatement répercutée dans la présente Norme Eurocontrol. Les révisions des autres documents cités en référence ne doivent faire partie des dispositions de la présente Norme Eurocontrol que lorsqu'elles auront été officiellement examinées et incluses dans le présent document normatif. En cas de conflit entre les prescriptions de la présente Norme et la teneur des autres documents de référence, c'est la présente Norme Eurocontrol qui prévaut. 3.2. Références 1. Recommandation X.25 (1993) (Rév. 1) de l'UIT-T, Interface entre équipement terminal de traitement de données (ETTD) et équipement de terminaison du circuit de données (ETCD) pour terminaux fonctionnant en mode-paquet et raccordés à des réseaux publics pour données par circuit spécialisé. 2. ISO/IEC TR 10000-1:1992 Technologies de l'information - Cadre et taxonomie des profils normalisés internationaux - Partie 1: Cadre (2e édition). 3. ISO/IEC TR 10000-2:1994 Technologies de l'information - Cadre et taxonomie des profils normalisés internationaux - Partie 2: Principes et taxonomie pour profils OSI (3e édition). 4. Recommandation X.21 (1992) (Rév. 1) de l'UIT-T, Interface entre l'équipement terminal de traitement de données (ETTD) et l'équipement de terminaison du circuit de données (ETCD) pour fonctionnement synchrone dans les réseaux publics pour données. 5. Recommandation X.21bis (1988) du CCITT, Utilisation, sur les réseaux publics pour données, d'équipements terminaux de traitement de données (ETTD) destinés à assurer l'interface des modems synchrones de la série V. 6. ISO/IEC 7776:1994, Technologies de l'information - Télécommunications et échange d'information entre systèmes - Procédures de commande de liaison de données à haut niveau - Description des procédures de liaison d'équipement terminal de transmission de données ETTD compatible X.25 (2e édition). 7. ISO/IEC 8208: 1993, Technologies de l'information - Communication de données - Protocole X.25 de couche paquet pour terminal de données (3e édition). 8. ISO/IEC ISP 10609-9:1992, Technologies de l'information - Profils normalisés internationaux TB, TC, TD et TE - Service de transport en mode connexion sur un service de réseau en mode connexion - Partie 9: Spécifications de la couche réseau, de la couche liaison de données et de la couche physique dépendant du type de sous-réseau, concernant l'accès permanent à un réseau de données à commutation par paquets utilisant des communications virtuelles. 9. ISO/IEC 7498-1: 1994, Technologies de l'information - Interconnexion de systèmes ouverts - Modèle de référence de base: Le modèle de base (2e édition). 10. ISO/IEC 8348:1993, Technologies de l'information - Interconnexion de systèmes ouverts - Définition du service de réseau (1re édition). 11. ISO/IEC 8072:1994, Technologies de l'information - Interconnexion de systèmes ouverts - Définition du service de transport (2e édition). 12. ISO/IEC 8878:1992, Technologies de l'information - Télécommunications et échange d'informations entre systèmes - Utilisation du protocole X.25 pour fournir le service de réseau OSI en mode connexion (2e édition). 13. Norme Eurocontrol pour l'échange de données en ligne (OLDI) No 001-92, Edition 1, 1992. 14. ISO/IEC 9646-1:1994, Technologies de l'information - Interconnexion de systèmes ouverts - Cadre général et méthodologie des tests de conformité OSI - Partie 1: Concepts généraux (2e édition). 15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10 May 1996 (disponible uniquement en langue anglaise). 16. Eurocontrol FDE ICD Part 1 - Reliability, Availability and Security - Technical Report Version 1.0, dated 20 April 1997 (disponible uniquement en langue anglaise). 17. Recommandation X.32 (1993) (Rév. 1) de l'UIT-T, Interface entre ETTD et ETCD pour terminaux fonctionnant en mode paquet et ayant accès à un réseau public de transmission de donnéees à commutation par paquet par l'introduction d'un RTPC, d'un RNIS ou d'un réseau puplic pour données à commutation de circuits. 18. Recommandation E.164 (1991) (Rév. 1) de l'UIT-T, Plan de numérotage pour le réseau numérique avec intégration des services (RNIS). 19. Recommandation X.75 (1993) (Rév. 1) de l'UIT-T, Système de signalisation commutation par paquets entre réseaux publics assurant les services de transmission de données. 20. Recommandation X.121 (1993) de l'UIT-T, Plan de numérotage international pour les réseaux publics pour données 4. DÉFINITIONS, SYMBOLES et ABRÉVIATIONS 4.1. Définitions 4.1.1. Aux fins de la présente Norme Eurocontrol, les définitions ci-après sont applicables: 4.1.2. Profil: un ensemble d'une ou plusieurs normes de base et, le cas échéant, l'identification d'un choix de classes, de sous-ensembles, d'options et de paramètres propres à ces normes de base, qui sont nécessaires pour accomplir une fonction donnée [Référence 2]. 4.1.3. Liste des spécifications de profil (PRL): Les spécifications de profil sont exprimées sous la forme de conditions de conformité et présentées sous forme de tableau [Référence 2]. 4.1.4. Profil T: Profil de transport fournissant un service de transport en mode connexion [Référence 3]. 4.1.5. Profil A: Profil d'application nécessitant un service de transport en mode connexion [Référence 3]. 4.1.6. Déclaration de conformité d'une instance de protocole (PICS): Déclaration par laquelle le fournisseur d'un système OSI indique les moyens qui ont été mis en oeuvre pour un protocole OSI donné [Référence 14]. 4.2. Symboles et abréviations >EMPLACEMENT TABLE> 4.3. Notation 4.3.1. Aux fins de la présente Norme Eurocontrol, les valeurs binaires ou une séquence de bits sont présentées sous forme hexadécimale à l'aide du symbole 'd'H, la lettre d représentant un chiffre ou une séquence de chiffres hexadécimaux. 4.3.2. Aux fins de la présente Norme Eurocontrol, la représentation hexadécimale d'une séquence de bits est constituée de 4 bits pris en même temps, en commençant par le bit de plus fort poids (MSB) jusqu'au bit de plus faible poids (LSB).NOTE Sauf avis contraire des normes internationaux en référence, une séquence de bits est transmise depuis le MSB jusqu'au LSB. 4.3.3. Aux fins de la présente Norme Eurocontrol, l'état de prise en charge des fonctions d'une norme de base ou de la présente Norme Eurocontrol est indiqué en majuscules (par exemple M, O, O.< n >, X). La signification exacte de chaque symbole d'état est précisée dans les annexes de la présente Norme Eurocontrol, préalablement à leur emploi. 4.3.4. Pour définir le profil de la 1re partie du FDE ICD dans la présente Norme Eurocontrol, l'état de prise en charge des fonctions d'une norme de base ou de la présente Norme Eurocontrol est indiqué en minuscules (par ex.: m, o, o.< n >, x).NOTE Les fonctions des normes de base qui sont conditionnelles, optionnelles ou dépendantes de la valeur sont ainsi mieux précisées (voir le paragraphe E.3.1). 5. APERÇU TECHNIQUE 5.1. Ensemble vertical des protocoles NOTE L'ensemble vertical des protocoles applicables au profil de la présente Norme Eurocontrol est illustré à la figure 2. Les protocoles sont présentés suivant le modèle de référence de base de l'OSI [Référence 9], l'ensemble vertical étant aligné sur les couches OSI correspondantes. Toutefois, l'ensemble vertical des protocoles constitue une spécification des systèmes pré-OSI et n'assure pas les multiples fonctions offertes par les protocoles OSI des couches OSI correspondantes. Figure 2 Ensemble vertical des protocoles >PIC FILE= "L_2000254FR.018201.EPS"> 5.2. Structure du profil NOTES 1. Comme le montre la figure 2, l'ensemble vertical combine plusieurs protocoles de couche inférieure, dont seuls le protocole X.25 en couche paquet (PCP) [Référence 1] et les protocoles X.21 [Référence 4] et X.21.bis [Référence 5], qui le complètent, sont définis dans les normes existantes de l'ISO/CEI et de l'Union internationale des télécommunications - Secteur de la normalisation des télécommunications (UIT-T). Les protocoles des couches supérieures sont définis dans les Annexes A, B et C de la présente Norme Eurocontrol. 2. Les conditions de conformité applicables au profil, qui peuvent renvoyer à ces spécifications au même titre qu'à des normes externes, sont indiquées à la section 5. Les spécifications détaillées sont présentées sous forme de tableau de PRL (Annexe E) et dans les formulaires PICS (les formulaires pour les protocoles définis dans les annexes figurent à l'Annexe D). L'utilisation de ces PRL et des formulaires PICS pour la mise au point et/ou l'acquisition est explicitée dans l'Annexe E. 5.3. Relation avec des versions antérieures des spécifications NOTES 1. Le présent profil s'appuie sur le Document ST-ICD établi par l'ancien Sous-groupe technique OLDI. Les protocoles et les modèles de paquet définis dans la présente Norme Eurocontrol sont un sous-ensemble compatible de ceux du Document ST-ICD, à la différence près que la présente Norme Eurocontrol définit de façon plus détaillée les conditions d'emploi du PCP X.25, y compris l'utilisation obligatoire du bit M, et remédie au manque de cohérence des spécifications de la valeur de l'identificateur d'autorité et de format (IAF) dans l'adresse du point d'accès au service de réseau (NSAP). 2. Les principales modifications de style apportées dans la présente Norme Eurocontrol portent sur la structure des spécifications de l'ICD. Le protocole de transfert de message (Annexe A) est dissocié du profil T qui le complète. Cela facilitera l'utilisation des autres profils T lorsqu'elle deviendra nécessaire pour faire face à l'évolution des besoins FDE. 3. Les sections des spécifications du ST-ICD traitant de la commande des circuits virtuels X.25 et délimitant les messages d'application figurent maintenant dans le protocole d'en-tête de message (Annexe B), qui constitue une couche de transport minimale pour le FDE. 6. SPÉCIFICATIONS DE PROFIL 6.1. Conditions de conformité 6.1.1. Une réalisation déclarée conforme à la présente spécification doit satisfaire à toutes les conditions stipulées aux sections 6.2 et 6.3 ci-dessous. 6.1.2. Une déclaration de conformité doit être accompagnée d'une Déclaration de conformité d'une instance de profil, telle qu'elle est décrite dans les Annexes D et E. 6.2. Conditions applicables aux couches supérieures 6.2.1. Une réalisation conforme doit satisfaire aux conditions de la norme de base, qui sont indiquées à l'Annexe A. 6.2.2. Une réalisation conforme doit satisfaire aux contraintes stipulées dans la liste des spécifications de profil figurant à l'Annexe E.7. 6.3. Conditions applicables aux couches inférieures 6.3.1. Couche transport 6.3.1.1. Une réalisation conforme doit satisfaire aux conditions de la norme de base, qui sont indiquées à l'Annexe B. 6.3.1.2. Une réalisation conforme doit satisfaire aux contraintes stipulées dans la liste des spécifications de profil figurant à l'Annexe E.8.1. 6.3.1.3. Une réalisation conforme doit satisfaire à la condition de capacité de l'unité de données du service de transport (TSDU), qui doit être de 4097 octets au plus.NOTE Le premier octet de la TSDU correspond à un champ d'en-tête de message (voir les alinéas A.4.10 et B.4.4), ce qui laisse 4096 octets au plus pour les données de l'utilisateur. 6.3.2. Couche réseau 6.3.2.1. Une réalisation conforme doit satisfaire aux conditions de la norme ISO/IEC 8208 [Référence 7], conformément à la mise en correspondance des protocoles figurant à l'Annexe C. 6.3.2.2. Une réalisation conforme doit satisfaire aux contraintes stipulées dans la liste des spécifications de profil figurant à l'Annexe E.8.2. 6.3.2.3. Une réalisation conforme doit, si un fonctionnement de type Equipement terminal de traitement de données (ETTD)-ETTD est assuré, être capable de configurer, par des mécanismes de gestion des systèmes, le choix du rôle de l'ETTD ou de l'équipement de terminaison de circuit de données (ETCD) pour le fonctionnement ETTD-ETTD. 6.3.2.4. Une réalisation conforme doit, dans l'un ou l'autre rôle défini au point 6.3.2.3, être capable de lancer une connexion conformément aux spécifications de l'Annexe C, c'est-à-dire que le protocole est totalement symétrique.NOTE Certaines réalisations déjà mises en place sur la base du ST-ICD peuvent ne pas être capables de lancer des connexions de réseau conformément au protocole de l'Annexe C. 6.3.2.5. Une réalisation conforme doit admettre, pendant une période donnée, le service de taille de paquets par défaut non standard, avec une valeur de 256 dans les deux sens de transmission. 6.3.2.6. Une réalisation conforme doit utiliser les adresses NSAP, telles qu'elles sont définies dans l'Annexe C. 6.3.2.7. Une réalisation conforme doit positionner le bit D à 0 dans les paquets d'APPEL, c et DONNÉES.NOTE Positionner le bit D à 0 dans les paquets d'APPEL et COMMUNICATION ACCEPTÉE équivaut à ne pas utiliser la confirmation de remise. 6.3.3. Couche liaison de données 6.3.3.1. Une réalisation conforme doit satisfaire aux conditions de conformité de la norme ISO/IEC 7776 [Référence 6] pour le protocole de liaison unique avec procédure d'accès à la ligne en mode symétrique (LAPB). 6.3.3.2. Une réalisation conforme doit également satisfaire aux contraintes stipulées dans la Liste des spécifications de profil figurant à l'Annexe E.8.3. 6.3.4. Couche physique Une réalisation conforme doit satisfaire aux conditions de conformité de la norme ISO/IEC ISP 10609-9, clause 7 [Référence 8]. 7. MÉTHODES D'ESSAI NOTES 1. On trouvera à l'Annexe F une introduction aux tests destinés à évaluer la conformité de réalisations aux présentes spécifications. 2. Les modalités d'emploi des PRL et des formulaires PICS prévus dans les présentes spécifications pour justifier la conformité sont exposées dans l'Annexe E. ANNEXE A (Normative) PROTOCOLE DE TRANSFERT DE MESSAGES A.1. Introduction Les présentes spécifications définissent un protocole pour la mise en oeuvre d'un service de transfert de messages simple en vue d'applications nécessitant l'échange de données de vol. A.2. Service utilisé Le protocole de transfert de messages (TM) utilise les services non-confirmés suivants: Association-TM: établit une association de transfert de messages d'application. Données-TM: transfère un message d'application composé de caractères ASCII (Code standard US pour l'échange d'informations). Abandon-TM: met fin à une association de transfert de messages d'application. A.3. Service requis Ce protocole de transfert de messages nécessite un sous-ensemble du service de transport en mode connexion, défini dans la norme ISO/IEC 8072 [Référence 11], tel que le propose le protocole défini dans l'Annexe B de la présente Norme Eurocontrol. A.4. Spécifications du protocole A.4.1. Introduction Le texte ci-après décrit uniquement le fonctionnement d'une association de transfert de messages lancée par l'application. D'autres associations peuvent être assurées sur la même interface de réseau en renouvelant ces procédures pour chaque connexion de transport de la couche de niveau inférieur. A.4.2. Types de données La présente Annexe définit quatre types de messages d'application qui sont équivalents à ceux définis dans la Norme Eurocontrol no 001-3-92 Édition 1: Messages de système: Ces messages doivent être utilisés pour la surveillance des liaisons (message PULSION) et la commande d'application (messages de DÉMARRAGE et d'ARRÊT). Messages opérationnels: Ces messages doivent être liés à un contexte opérationnel particulier et sont définis dans les Normes et Documents normatifs d'Eurocontrol qui font appel à la présente norme pour l'échange de données. La Norme Eurocontrol relative à l'échange de données en ligne inclut, dans sa définition des messages opérationnels, les messages d'activation (ACT), de préavis de franchissement de limite (ABI) et d'accusé de réception logique (LAM). Messages d'opérateur: Ces messages doivent comporter un texte libre. Leur emploi doit faire l'objet d'accords bilatéraux. Par exemple, ils peuvent servir à échanger des informations d'essai ou à informer l'autre partie des actions de l'opérateur. Messages d'état: Ces messages, dont l'emploi et la teneur font l'objet d'accords bilatéraux, peuvent notamment servir à l'échange d'informations sur la gestion du système. NOTES 1. L'emploi des messages de système fait partie des modalités du présent protocole et le format des messages est précisé au paragraphe A.4.10.3 de la présente Annexe. 2. L'utilisation et le format des messages d'état font l'objet d'accords bilatéraux et ne sont pas précisés davantage dans la présente Norme Eurocontrol. 3. L'état du protocole détermine le type de message pouvant être transmis, comme il est indiqué dans les paragraphes qui suivent. A.4.3. Établissement de l'association A.4.3.1. Au départ, le protocole est au REPOS. A.4.3.2. La primitive de demande d'Association-TM est exécutée afin d'établir une association d'application et d'amener le protocole à l'état DONNÉES_PRÊTES. La primitive doit être invoquée à la fois par l'application locale et par l'application distante. A.4.3.3. Il faut d'abord établir une connexion de transport de la couche de niveau inférieur, suivant les procédures de la primitive de connexion de transport décrites à l'Annexe B, paragraphe B.4.1, puis le protocole arrive à l'état PRÊT. À ce stade, seuls les messages de système (et éventuellement les messages d'opérateurs, selon les accords bilatéraux conclus) peuvent être transférés. Pour transférer un message de système ou d'opérateur, l'émetteur utilise la primitive de transport de données (voir le paragraphe B.4.4) avec le message en tant que paramètre. A.4.3.4. Un message de DÉMARRAGE (message de système) doit alors être transmis, le temporisateur Tr (voir le paragraphe A.4.7) doit être déclenché et le protocole passe à l'état ASSOCIATION_EN_ATTENTE. Si le temporisateur Tr arrive à expiration pendant que le protocole est encore à cet état, le message de DÉMARRAGE doit être retransmis et le temporisateur doit être relancé.NOTE Le protocole reste dans l'état ASSOCIATION_EN_ATTENTE jusqu'à la réception d'un message de DÉMARRAGE. Une expiration continue du temporisateur Tr peut être signalée localement. A.4.3.5. La réception du message de DÉMARRAGE doit entraîner les mesures suivantes: - à l'état ASSOCIATION_EN_ATTENTE, un nouveau message de DÉMARRAGE est transmis, le protocole passe à l'état DONNÉES_PRÊTES et la primitive indication d'Association-TM est signalée; - à tout autre état, le message est ignoré. A.4.3.6. La réception du message de DÉMARRAGE en état d'ASSOCIATION_EN_ATTENTE correspond: - soit à la primitive demande d'Association-TM de l'application distante et le protocole distant est passé à l'état ASSOCIATION_EN_ATTENTE; - soit le protocole de transfert de messages distant répond à la réception d'un message de DÉMARRAGE et est passé à l'état DONNÉES_PRÊTES. NOTE Cette incertitude est liée au fait que le même message est utilisé pour le DÉMARRAGE et pour la réponse au DÉMARRAGE. Par conséquent, le premier protocole à passer dans l'état DONNÉES_PRÊTES va recevoir un nouveau message de DÉMARRAGE. Comme indiqué au paragraphe A.4.3.5, ce message est ignoré. A.4.3.7. Une fois les messages de DÉMARRAGE échangés, l'association est établie et tous les types de message identifiés peuvent être transférés (état DONNÉES_PRÊTES). A.4.4. Transfert de données D'autres types de messages sont transférés de la même façon que les messages de système, en utilisant le service de Données de transport, avec le message en tant que paramètre. Cela correspond aux primitives demande de Données-TM et indication de Données-TM. NOTE Chaque message est envoyé sous forme de TSDU unique: il n'y a ni concaténation ni segmentation des messages à ce niveau. A.4.5. Libération normale de l'association A.4.5.1. L'association de transfert de messages entre deux applications peut être libérée par l'une ou l'autre des applications. Cela correspond à la primitive du service de demande d'Abandon-TM. A.4.5.2. Les mesures suivantes doivent être prises: - à l'état DONNÉES_PRÊTES, un message d'ARRÊT (message de système) doit être transmis, les temporisateurs Tr et Ts doivent être arrêtés et la connexion de transport doit être libérée; - à l'état ASSOCIATION_EN_ATTENTE, un message d'ARRÊT (message de système) doit être transmis, le temporisateur Tr doit être arrêté et la connexion de transport doit être libérée; - à l'état PRÊT la connexion de transport doit être libérée; - aucune autre mesure n'est prise par ailleurs. NOTE Le message d'ARRÊT n'est pas un préavis - il est mis fin à l'association immédiatement. Le message n'est pas confirmé par l'autre partie. A.4.5.3. La réception d'un message d'ARRÊT doit entraîner les mesures suivantes: - à l'état DONNÉES_PRÊTES, le temporisateur Ts (voir A.4.7) doit être arrêté, l'indication Abandon-TM est donnée et l'interface passe à l'état ASSOCIATION_EN_ATTENTE sans envoi d'un message de DÉMARRAGE; - à tous les autres états, aucune mesure n'est prise. A.4.6. Rétablissement de l'association L'application qui a pris l'initiative de la libération de l'association a la responsabilité, lorsqu'elle est prête, de rétablir l'association d'application et toute autre couche inférieure (si nécessaire).NOTE Si la libération de l'association a eu pour conséquence la libération de la connexion de réseau, la procédure d'établissement de l'association spécifiée au paragraphe A.4.3 doit être suivie. A.4.7. Intégrité de l'association A.4.7.1. L'intégrité de l'association entre deux applications est assurée par le service PULSION au repos. A.4.7.2. Au passage à l'état DONNÉES_PRÊTES et lors de la transmission de tout type de message sur la connexion transport, un temporisateur Ts configurable doit être (re)lancé. Si le temporisateur Ts arrive à expiration au cours de l'état DONNÉES_PRÊTES, un message PULSION (message de système) doit être transmis (et le temporisateur doit être relancé). A.4.7.3. De même, au passage à l'état DONNÉES_PRÊTES et lors de la réception de tout type de message, en dehors d'un message de DÉMARRAGE, sur la connexion transport, un temporisateur Tr configurable doit être (re)lancé. Si le temporisateur Tr arrive à expiration au cours de l'état DONNÉES_PRÊTES, l'indication Abandon-TM est donnée, la transmission de tous les messages est arrêtée, le temporisateur Ts est arrêté et le temporisateur Tr est relancé. L'interface est à l'état ASSOCIATION_EN_ATTENTE.NOTE Les applications seront rétablies et resynchronisées par l'échange de messages de DÉMARRAGE (voir paragraphe A.4.3). A.4.8. Libération anormale d'association A.4.8.1. Il peut y avoir une libération anormale d'association: - en cas de perte de la connexion de transport (par exemple, en raison d'une défaillance de la ligne ou d'une erreur de protocole); - en cas de défaillance de l'un des deux systèmes ou applications (imputable au matériel ou au logiciel; parfois, la connexion de transport de la couche de niveau inférieur peut néanmoins fonctionner). NOTE Selon la définition de la couche transport à l'annexe B, il n'y a pas de connexion de transport de bout-en-bout. Par conséquent, une perte de la connexion de transport est un résultat direct de la perte de la connexion de réseau. A.4.8.2. La défaillance d'un système ou d'une application peut être détectée à l'expiration d'une temporisation pour la réception d'un message PULSION attendu de cette application (voir paragraphe A.4.7). A.4.9. Reprise A.4.9.1. Deux cas doivent être envisagés: - après une défaillance de la connexion de transport; - après une défaillance d'application. A.4.9.2. Dans les deux cas, le rétablissement fait intervenir la procédure normale d'établissement de l'association (voir paragraphe A.4.3), y compris l'échange de messages de DÉMARRAGE.NOTE En cas de défaillance au niveau de l'application qui ne provoque pas la libération de la connexion de la couche de niveau inférieur, le système défaillant peut transmettre un message d'ARRÊT (c'est-à-dire que l'arrêt de l'utilisateur local est invoqué soit manuellement, soit dans le cadre d'une fonction logique d'application) avant toute tentative de rétablissement de la liaison. Cela ralentira le temporisateur Tr de l'application distante et pourrait se traduire par un rétablissement plus rapide, avec un moindre risque de perte de données. A.4.10. Formats des messages A.4.10.1. Structure générale des messages >EMPLACEMENT TABLE> A.4.10.2. Longueur du texte du message Des messages d'une longueur de texte allant jusqu'à 4096 octets doivent être admis. A.4.10.3. Format des messages de système >EMPLACEMENT TABLE> A.4.10.4. Autres formats de message >EMPLACEMENT TABLE> NOTES 1. Le format du corps du texte des messages d'état n'entre pas dans le cadre de la présente Norme Eurocontrol. 2. Le format des messages opérationnels est indiqué dans les Normes et Documents normatifs d'Eurocontrol définissant les applications de messagerie tels que l'échange de données en ligne [Référence 13]. 3. Les messages d'opérateur se composent d'un texte ASCII imprimable. Si ces messages sont acceptés, une interface utilisateur doit être fournie pour afficher les messages reçus et permettre la composition de messages en vue de leur transmission. A.5. Tableaux de transition des états de protocole A.5.1. Introduction Les tableaux d'état ci-dessous présentent les spécifications définitives du protocole. En cas de divergence avec le texte principal ci-dessus, les spécifications ci-après doivent prévaloir.NOTE La notation utilisée pour décrire les états, événements, temporisateurs et mesures s'appuie sur le ST-ICD. Toutefois, les définitions ci-après et les mesures qui en résultent ont été revues et peuvent donc s'écarter des dispositions antérieures. A.5.2. Définition des états Tableau 1 Définitions des états >EMPLACEMENT TABLE> A.5.3. Evénements possibles Tableau 2 Événements possibles >EMPLACEMENT TABLE> A.5.4. Temporisateurs Tableau 3 Temporisateurs >EMPLACEMENT TABLE> La valeur de ces temporisateurs doit être telle que Tr = 2Ts + délai de transit.NOTE Les valeurs types de ces temporisateurs sont les suivantes: Ts = 30s, Tr = 70s. A.5.5. Tableau de transition d'états Tableau 4 Transition d'états >EMPLACEMENT TABLE> A.5.6. Diagramme de transition d'états NOTE Le protocole est présenté à la Figure A.1 sous forme de digramme de transition d'états. Ce diagramme est fourni à titre d'information: en cas de divergence entre le diagramme et les tableaux d'états présentés plus haut, ce sont ces derniers qui prévaudront. Figure A.1 Protocole de transfert de messages: Diagramme de transition d'états >PIC FILE= "L_2000254FR.019301.EPS"> ANNEXE B (Normative) PROTOCOLE D'EN-TÊTE DE MESSAGE B.1. Introduction La présente Annexe définit le protocole d'en-tête de message, protocole de transport minimal destiné aux applications telles qu'OLDI. B.2. Service mis en oeuvre B.2.1. Le protocole d'en-tête de message correspond à un sous-ensemble du service de transport en mode connexion, tel qu'il est défini dans le document ISO/IEC 8072 [Référence 11], et comprend les primitives de service suivantes: Connexion de transport: établit une connexion de transport pour une application. Données de transport: assure le transfert de données ASCII Déconnexion de transport: met fin à la connexion de transport d'une application. B.2.2. Le service ne permet pas le multiplexage, le retour au fonctionnement normal ni la segmentation ou le réassemblage. B.3. Service requis Le protocole suppose un service fiable du réseau de base, tel qu'il est assuré par le protocole X.25 en couche paquet.NOTE Une seule connexion de transport est assurée sur chaque connexion de réseau. B.4. Spécifications du protocole B.4.1. Établissement de la connexion La primitive de Connexion de transport doit être mise en oeuvre au moyen du service de connexion de réseau du service réseau de la couche de niveau inférieur. Il y a une correspondance exacte entre les deux séries de primitives (de demande et d'indication). Autrement, il est possible d'utiliser une connexion de réseau existante (par exemple une connexion établie par les mécanismes de gestion du système).Recommandations 1. Dans le dernier cas ci-dessus, il convient de rétablir au préalable la connexion de réseau. La primitive de connexion de réseau peut être rediffusée automatiquement si aucune réponse n'est reçue dans un délai donné. 2. Si cette procédure de répétition d'appel est appliquée, il convient de répéter les appels toutes les 15 s environ. B.4.2. Mesures visant à éviter la redondance des connexions de réseau Si une primitive de demande de connexion de réseau est en attente (c'est-à-dire qu'aucune primitive correspondante de confirmation de connexion de réseau ou de déconnexion de réseau n'a été signalée) et qu'une indication de connexion de réseau est signalée, la tentative d'établissement de connexion de réseau à l'arrivée sera rejetée ou libérée, par l'envoi en réponse d'une primitive de demande de déconnexion de réseau, uniquement lorsque les deux conditions ci-après sont réunies: - l'adresse du NSAP appelant de l'indication de connexion de réseau est la même que l'adresse du NSAP appelé de la demande de connexion de réseau en attente; - l'adresse du NSAP appelant de la demande de connexion de réseau en attente est plus longue que l'adresse du NSAP appelé de la demande de connexion de réseau en attente, la comparaison s'établissant sur la chaîne de bits formée par le codage binaire préférentiel de chaque adresse NSAP, suivant la définition donnée dans le document ISO/IEC 8348 Annexe A [Référence 10] (une chaîne sera considérée comme plus longue que l'un de ses propres sous-ensembles initiaux, par exemple, '8800'H >'88'H). B.4.3. Libération de la connexion B.4.3.1. La libération de la Connexion de transport doit s'effectuer au moyen des primitives de service de déconnexion de réseau et de rétablissement de réseau du service de réseau de la couche de niveau inférieur. B.4.3.2. Pour mettre en oeuvre une demande de Déconnexion de transport, une demande de déconnexion de réseau doit être signalée. Autrement, si l'établissement des connexions de réseau à l'aide des primitives de connexion de réseau n'est pas possible, la connexion de réseau ne doit pas être expressément libérée.Recommendations Dans ce dernier cas, il convient de réinitialiser la connexion de réseau. B.4.3.3. Une indication de Déconnexion de transport doit être signalée dès réception de l'une ou l'autre primitive de service de réseau sur une connexion de réseau correspondant à une connexion entièrement ou partiellement établie: - indication de déconnexion de réseau; - indication de réinitialisation de réseau. B.4.4. Transfert de données B.4.4.1. La primitive de Données de transport doit être mise en oeuvre au moyen de la primitive de données de réseau du service de réseau de la couche de niveau inférieur. Il y a une correspondance exacte entre les deux séries de primitives (de demande et d'indication). La correspondance s'établit au moyen de l'unité de données de protocole de transport qui est transférée par le service de réseau. B.4.4.2. >EMPLACEMENT TABLE> NOTES 1. Cet en-tête est défini de façon à être identique à celui utilisé dans la procédure INTERCAUTRA adoptée pour l'échange de messages ACT entre CAUTRA Paris, le système 9020D du Centre de contrôle de la circulation aérienne de Londres et le Central d'échange de données numérique (DCTS) de Maastricht/Karlsruhe, lors du transport des formats de message définis en Annexe A; dans le cas présent, le champ "données(1)" correspond au champ TYP. 2. L'emploi des champs ADEST, DEST, AEMM, EMM, et ADR avec des valeurs autres que '40'H sort du cadre de la présente Norme Eurocontrol, mais peut faire l'objet d'accords bilatéraux. B.4.4.3. Le service de données de transport doit être limité au transfert de données imprimables en caractères ASCII. Plus particulièrement, aucun des octets de données ne doit avoir la valeur '03'H (désignant la fin de texte). B.4.4.4. Une réalisation conforme doit satisfaire à la condition d'exploitation d'unités de données du service de réseau (NSDU) d'une taille allant jusqu'à 4105 octets compris. B.4.4.5. Une réalisation conforme doit exclure la concaténation de TSDU multiples en une NSDU unique. B.4.4.6. Une réalisation conforme doit interdire la segmentation d'une TSDU unique en plusieurs NSDU. ANNEXE C (Normative) PROTOCOLE DE RÉSEAU C.1. Introduction La présente Annexe définit un protocole de réseau de base, s'appuyant sur le protocole X.25 en couche paquet, destiné aux réseaux point à point et à commutation par paquets, pour le transfert de données de vol. Le sous-ensemble de protocole est compatible avec celui défini dans le document [Référence 1] dans ses versions à compter de 1980. C.2. Service assuré C.2.1. Le protocole met en oeuvre le service de réseau OSI en mode connexion, tel qu'il est défini dans la norme ISO/IEC 8348 [Référence 10], sous réserve des exceptions suivantes: - les adresses NSAP sont limitées à la forme définie au paragraphe; - il n'y a pas de possibilité pour les utilisateurs du service de réseau et le fournisseur du service de réseau de convenir d'une certaine qualité de service associée à une connexion de réseau; - à l'exception de la procédure décrite au paragraphe C.5.3, le transfert de données de l'utilisateur de la connexion de réseau pendant l'établissement et la libération de la connexion de réseau n'est pas assuré. C.2.2. Les options suivantes du fournisseur du service de réseau ne sont pas offertes: - Confirmation de réception; - Transfert de données exprès. C.3. Service requis Le protocole suppose la fourniture d'un service de liaison de données OSI, tel qu'il est défini dans la norme ISO/IEC 7776 (LAPB) [Référence 6]. C.4. Adresses NSAP C.4.1. Introduction C.4.1.1. La structure des adresses NSAP est conforme à la définition donnée dans le document ISO/IEC 8348, Annexe A [Référence 10], comme l'illustre le schéma ci-dessous: >PIC FILE= "L_2000254FR.019702.EPS"> C.4.1.2. Les éléments de l'adresse NSAP sont les suivants: IDP: Partie initiale de domaine, comprenant les champs AFI et IDI AFI: Identificateur d'autorité et de format IDI: Identificateur de domaine initial DSP: Partie spécifique de domaine C.4.2. Structure de l'adresse NSAP C.4.2.1. Aux fins de la présente Norme Eurocontrol, l'adresse doit être limitée aux éléments suivants: C.4.2.2. La valeur d'AFI 48 doit être utilisée, indiquant un format local d'IDI avec une syntaxe abstraite décimale. C.4.2.3. L'IDI est égal à zéro, suivant le format local. C.4.2.4. Le DSP doit consister en deux paires de chiffres décimaux, comme suit: - la première paire est un identificateur d'organisme de contrôle de la circulation aérienne (ATC), qui identifie un système ATC et donc, indirectement, une implantation; - la seconde paire est un sélecteur d'organisme ATC, qui peut être utilisé pour identifier une extrémité donnée à l'intérieur d'un organisme ATC. C.4.2.5. >EMPLACEMENT TABLE> C.4.3. Assignation des identificateurs et des sélecteurs d'organisme ATC C.4.3.1. Il appartiendra à Eurocontrol d'assigner des identificateurs d'organisme ATC uniques à chaque système ATC tandis que l'assignation des sélecteurs incombera aux instances compétentes de l'administration ou de l'organisation dont relève l'organisme ATC. C.4.3.2. L'attribution des identificateurs d'organisme ATC au moment de l'établissement de la présente Norme est indiquée à l'Annexe G. C.5. Spécifications du protocole C.5.1. Aperçu Le protocole se fonde sur le Protocole de convergence dépendant du sous-réseau pour X.25 (1980), défini dans l'Annexe A du document ISO/IEC 8878 [Référence 12], sous réserve des exceptions suivantes: - le service de sélection rapide n'est pas utilisé; toutefois, le codage défini dans l'Annexe A du document ISO/IEC 8878 [Référence 12] pour le champ de données d'utilisateur en format étendu disponible avec le service de sélection rapide est utilisé ici avec le champ de données d'utilisateur en format de base dans les paquets d'APPEL et APPEL ENTRANT, étant donné que les restrictions appliquées aux paramètres admis pour le service de réseau garantissent que l'information codée tient dans 16 octets; - parmi les paramètres de service de réseau dont le codage est défini dans le document ISO/IEC 8878 [Référence 12], seules les adresses NSAP de l'appelé et de l'appelant (et uniquement sous la forme définie au paragraphe C.4.2) sont envoyées dans le paquet d'APPEL; - le champ de données d'utilisateur n'est pas employé dans les paquets COMMUNICATION ACCEPTÉE, COMMUNICATION ÉTABLIE, DEMANDE DE LIBÉRATION ou INDICATION DE LIBÉRATION; - les autres procédures d'établissement et de libération de connexion de réseau ne sont pas appliquées; - la confirmation de remise au moyen du bit D n'est pas assurée. NOTE Les trois premières restrictions visent à garantir que toutes les informations qui seront transmises entre deux ETTD respecteront les limites fixées pour le champ de données d'utilisateur dans le PCP X.25 (1980). C.5.2. Codage des adresses Les adresses NSAP de l'appelant et de l'appelé doivent être codées selon le mode de codage binaire préférentiel défini dans le document ISO/IEC 8348 Annexe A [Référence 10]. C.5.3. Codage du champ de données d'utilisateur C.5.3.1. Par suite des conditions énoncées ci-dessus, le champ de données d'utilisateur dans des paquets d'APPEL et APPEL ENTRANT doit être codé suivant le modèle ci-dessous. Les 16 octets doivent être transmis dans leur intégralité. Tableau 1 Codage du champ de données d'utilisateur >EMPLACEMENT TABLE> C.5.3.2. Les autres paramètres décrits dans le document ISO/IEC 8878 [Référence 12], ne doivent pas être utilisés. C.5.4. Traitement des adresses dans les paquets APPEL ENTRANT C.5.4.1. Adresses d'ETTD L'adresse de l'ETTD appelant dans un paquet APPEL ENTRANT doit être validée par comparaison avec une liste locale d'adresses d'ETTD distants valides pour le système. Si une adresse non valide est détectée, l'appel doit être libéré. NOTES 1. L'adresse de l'ETTD appelant dans un paquet APPEL ENTRANT, si elle y figure, peut également être validée par comparaison avec une liste (comportant généralement une rubrique) des adresses des ETTD locaux valides pour le système. 2. Dans certains cas, l'adresse de l'ETTD d'un organisme peut varier en valeur et/ou en longueur suivant que l'organisme est le système appelant ou appelé. Il convient donc d'accorder une attention particulière à cette question lorsque la fonction de validation de l'adresse de l'ETTD est spécifiée ou mise en oeuvre. C.5.4.2. Adresses des NSAP L'adresse du NSAP appelant, codée suivant les modalités exposées ci-dessus dans un paquet APPEL ENTRANT doit être validée par comparaison avec une liste locale d'adresses de NSAP distants valides pour le système. Si une adresse non valide est détectée, l'appel doit être libéré. NOTE L'adresse du NSAP appelé peut également être validée par comparaison avec une liste (comportant généralement une rubrique) des adresses locales des NSAP valides pour le système. C.5.5. Transfert de données C.5.5.1. Ainsi qu'il est exposé dans le document ISO/IEC 8878 Annexe A.5.3 [Référence 12], les NSDU sont transférées dans le champ de données d'utilisateur d'un paquet DONNÉES. NOTE En conséquence, il est interdit de transmettre plus d'un message d'utilisateur, tel qu'un message OLDI, par paquet X.25 ou séquence de paquets X.25 au moyen du bit M. C.5.5.2. Les NSDU dont la longueur est supérieure au maximum admis par le circuit virtuel pour les données d'utilisateur doivent être segmentés et transmis dans les champs de données d'utilisateur d'une séquence de paquets DONNÉES, qui auront tous, à l'exception du dernier, la longueur maximale, le bit M indiquant qu'il y a des données à suivre. C.5.5.3. Dès réception, les champs de données d'utilisateur d'une séquence de données à suivre sont réassemblés de façon à former le NSDU reçu. ANNEXE D (Normative) FORMULAIRES PICS DE CONFORMITÉ AU PROFIL D.1. Introduction D.1.1. Le fournisseur d'une instance de protocole déclarée conforme aux spécifications des Annexes A à C doit remplir les formulaires PICS ci-après.NOTE Droits d'auteur applicables à la diffusion des formulaires PICS: Les utilisateurs de la présente Norme Eurocontrol peuvent reproduire librement les formulaires PICS figurant dans la présente Annexe pour l'usage auquel ils sont destinés et peuvent publier ensuite le formulaire PICS rempli. D.1.2. Un formulaire PICS rempli est le PICS pour la mise en oeuvre en question. Le PICS est une déclaration indiquant les capacités et les options du protocole qui ont été mises en oeuvre. D.1.3. Le PICS peut avoir différents usages et notamment servir: - au réalisateur d'un protocole, comme liste de contrôle permettant de réduire le risque de non-conformité à la norme pour cause d'oubli; - au fournisseur et à l'acquéreur, effectif ou potentiel, d'une réalisation, en donnant des informations détaillées sur les capacités de la réalisation, par rapport à la base de référence commune fournie par le formulaire-type PICS; - à l'utilisateur, effectif ou potentiel, de la réalisation, comme moyen de contrôle initial de la possibilité d'interfonctionnement avec une autre réalisation (on remarquera que si l'interfonctionnement ne peut jamais être garanti, l'incompatibilité des PICS constitue souvent un indice de défaut d'interfonctionnement); - au réalisateur d'un essai de protocole, comme base de sélection des essais appropriés pour l'évaluation de la conformité de la réalisation. D.2. Comment remplir les formulaires PICS D.2.1. Structure générale des formulaires PICS D.2.1.1. L'identification de la réalisation et la synthèse du protocole forment la première partie de tout formulaire PICS, qui doit être remplie suivant les indications fournies, accompagnées des informations nécessaires à une parfaite identification du fournisseur ainsi que de la réalisation. D.2.1.2. La partie principale du formulaire PICS est constituée d'un questionnaire de format-type. Les réponses aux diverses questions doivent être données dans la colonne située à l'extrême droite, soit en cochant la case appropriée en cas de choix restreint (en général Oui ou Non), soit en inscrivant une valeur ou bien un ensemble ou une plage de valeurs.NOTES 1. Chaque élément est identifié par une référence propre dans la première colonne; le texte de la question posée figure dans la deuxième colonne; la troisième colonne indique la ou les références aux paragraphes de la présente Norme Eurocontrol dans lesquels l'élément est explicité. Les autres colonnes sont utilisées pour indiquer l'état de l'élément (prise en charge obligatoire, optionnelle, interdite ou conditionnelle) et répondre aux questions posées; voir également le paragraphe D.2.4 ci-dessous. 2. Un fournisseur peut également soumettre, ou être tenu de soumettre, d'autres informations qualifiées soit d'informations supplémentaires, soit d'informations sur les conditions d'exception. Le cas échéant, chaque information supplémentaire doit être fournie dans une sous-rubrique d'élément étiquetée A< i > or X< i > respectivement, aux fins de renvoi réciproque, < i > représentant toute identification non ambiguë de l'élément (par ex. un simple numéral): il n'y a aucune autre restriction de format ou de présentation. D.2.1.3. Un formulaire PICS dûment rempli, accompagné le cas échéant des informations supplémentaires et des conditions d'exception, doit être qualifié de Déclaration de conformité de l'instance de protocole pour la réalisation en question. NOTE Lorsqu'une réalisation admet plusieurs configurations, un seul PICS peut suffire à décrire toutes les configurations possibles. Toutefois, le fournisseur a la possibilité de soumettre plusieurs formulaires, traitant chacun un sous-ensemble de capacités de la configuration, si la présentation des informations doit gagner en simplicité et en clarté. D.2.2. Informations supplémentaires Les informations supplémentaires permettent à un fournisseur de soumettre d'autres renseignements de nature à faciliter l'interprétation du PICS.NOTES 1. Les informations supplémentaires fournies ne doivent pas nécessairement être nombreuses et un PICS peut être considéré comme complet même s'il ne comporte aucune information de ce type. Ces renseignements pourront par exemple servir à présenter les façons dont une réalisation (unique) peut être constituée pour fonctionner dans différents environnements et configurations; ou à donner une explication succincte (pouvant reposer sur les besoins d'une d'application particulière) des motifs d'exclusion de certaines fonctions qui, bien qu'elles soient optionnelles, sont néanmoins généralement présentes dans les réalisations du protocole en question. 2. Les références aux éléments d'information supplémentaires peuvent être inscrites en regard de toute réponse au questionnaire, et peuvent être incluses dans les éléments d'information sur les conditions d'exception. D.2.3. Informations sur les conditions d'exception D.2.3.1. Il peut arriver parfois qu'un fournisseur souhaite répondre à un élément de caractère obligatoire ou interdit (après application éventuelle de conditions) d'une façon qui n'est pas compatible avec l'exigence indiquée. Aucune réponse n'aura été prévue pour ce cas dans la colonne Prise en charge et le fournisseur doit l'inscrire lui-même dans cette colonne, en ajoutant la mention X< i > pour désigner un élément d'information sur les conditions d'exception. D.2.3.2. Le fournisseur doit donner le justificatif approprié à la rubrique de l'élément d'exception proprement dit. D.2.3.3. Une réalisation nécessitant un élément d'exception dans ces conditions n'est pas conforme aux présentes spécifications.NOTE La situation décrite ci-dessus peut s'expliquer par le fait qu'un défaut dans la norme à été signalé et qu'un correctif devrait modifier la condition non satisfaite par la réalisation. D.2.4. Éléments conditionnels D.2.4.1. Chaque élément conditionnel est indiqué par un symbole particulier de la forme "< élément >: < s >" dans la colonne État, "< élément >" désignant une référence qui figure dans la première colonne du tableau pour certains autres éléments et "< s >" étant un symbole d'état, M, O, O.< n > or X.NOTE Un formulaire PICS peut comporter plusieurs éléments conditionnels, pour lesquels tant l'applicabilité de l'élément proprement dit que son état, si l'élément est applicable (obligatoire, optionnel ou interdit) dépendent de la prise en charge de certains autres éléments. D.2.4.2. Si l'élément signalé par le symbole conditionnel est indiqué comme étant accepté, il est applicable et son état est représenté par le symbole "< s >": la colonne Prise en charge doit être remplie selon les règles habituelles. Si l'élément conditionnel n'est pas assuré, il convient de répondre par Non applicable (NA). D.2.4.3. Chaque élément affecté d'un symbole conditionnel est signalé par une astérisque dans la colonne Elément. D.3. Formulaire PICS pour le protocole de transfert de messages D.3.1. Abréviations et symboles spéciaux D.3.1.1. Symboles d'état M: obligatoire O: optionnel D.3.1.2. Références des éléments Les éléments du formulaire PICS sont désignés par des références mnémoniques. Une même lettre ou paire de lettres initiales (en majuscules) est attribuée aux éléments traitant de fonctions connexes. On trouvera ci-après une liste de ces initiales, présentées suivant l'ordre dans lequel les groupes d'éléments apparaissent dans le formulaire PICS. >EMPLACEMENT TABLE> D.3.2. Identification >PIC FILE= "L_2000254FR.020301.EPS"> D.3.3. Réalisation du protocole >PIC FILE= "L_2000254FR.020401.EPS"> D.4. Formulaire PICS pour le protocole d'en-tête de message D.4.1. Abréviations et symboles spéciaux D.4.1.1. Symboles d'état M obligatoire O optionnel O.< n > optionnel, mais au moins une parmi le groupe d'options identifiées par le même numéral < n > est requise X interdit < élément >: symbole d'élément conditionnel, qui dépend de l'appui indiqué pour l'< élément >: voir le paragraphe D.2.4 D.4.1.2. Abréviations NA non applicable D.4.1.3. Références des éléments >EMPLACEMENT TABLE> D.4.2. Identification >PIC FILE= "L_2000254FR.020501.EPS"> D.4.3. Réalisation du protocole >PIC FILE= "L_2000254FR.020601.EPS"> D.5. Formulaire PICS pour le protocole de réseau D.5.1. Abréviations et Symboles spéciaux D.5.1.1. Symboles d'état M obligatoire O optionnel D.5.1.2. Références des éléments >EMPLACEMENT TABLE> D.5.2. Identification >PIC FILE= "L_2000254FR.020701.EPS"> D.5.3. Réalisation du protocole >PIC FILE= "L_2000254FR.020702.EPS"> ANNEXE E (Normative) LISTE DES SPÉCIFICATIONS DE PROFIL E.1. Introduction E.1.1. Cette Annexe donne la Liste des spécifications de profil (PRL) pour le FDE ICD défini dans la présente Norme Eurocontrol. La Déclaration de conformité applicable à une réalisation déclarée conforme au présent profil doit être établie suivant les instructions ci-après.NOTE Les formulaires de la présente Annexe s'inspirent de ceux qui sont joints aux normes de base citées en référence. E.1.2. Une réalisation conforme doit remplir les conditions de conformité obligatoires des normes de base citées en référence dans le présent profil. E.2. Rôle de la PRL et des formulaires PICS La section E.2. a une valeur informative: elle ne constitue pas une disposition de la présente partie de la Norme Eurocontrol. - La présentation des conditions de conformité sous forme de tableaux de PRL et de PICS vise à donner une liste de contrôle des fonctions qui doivent ou peuvent être réalisées. Les principes directeurs sont définis et décrits dans le document ISO/IEC 9646-1 [Référence 14], dont la Recommandation X.290 de l'UIT-T est une équivalence, et dans le document ISO/IEC TR 10000-1 [Référence 2]. - Un profil propose une association d'options de plusieurs normes de base en vue de répondre à une fonction particulière de traitement de l'information. Les spécifications applicables à chaque norme de base sont définies au moyen d'un formulaire PICS. La PRL comprend le sous-ensemble des éléments du formulaire PICS de la norme de base qui sont imposés par le profil, ainsi que les conditions particulières du profil; elle définit les réponses qui doivent être données aux formulaires PICS de la norme de base pour que la réalisation soit conforme. En outre, la PRL comprendra des éléments de type PICS qui sont propres au profil (ou, tout au moins, un élément destiné à vérifier que tous les formulaires PICS requis ont été dûment remplis); ces rubriques doivent être remplies conjointement avec les formulaires PICS de la norme de base. L'ensemble des formulaires dûment remplis constituent la Déclaration de conformité d'une réalisation du profil (ICS). - Suivant la méthode exposée dans le document ISO/IEC TR 10000-1 [Référence 2], une déclaration de conformité à un profil doit être appuyée par des formulaires PICS remplis conformément à la PRL. L'utilisation de ces documents sera fonction de la méthode d'acquisition retenue pour une réalisation FDE ICD. - Plusieurs méthodes peuvent être envisagées pour une réalisation FDE: - Réalisation interne assurée par une administration ou un organisme national: il convient d'utiliser la PRL comme base de référence pour les spécifications des conditions et des essais de réception de la réalisation; il convient de produire l'ICS dûment rempli dans le cadre de la procédure de réception. - Réalisation du profil par un sous-traitant: le matériel sera utilisé et produit comme pour une réalisation interne, mais il convient que le sous-traitant fournisse l'ICS, cette condition devant faire partie des obligations contractuelles. - Réalisation du profil par un sous-traitant dans le cadre d'un marché clé en main ou d'un marché d'intégration de systèmes: le matériel sera utilisé et produit comme pour une réalisation interne mais le sous-traitant devra s'acquitter de cette tâche au niveau interne et fournir l'ICS dûment rempli. La conformité au profil permet d'éviter, par exemple, qu'un fournisseur travaillant pour deux administrations n'introduise ses protocoles privés pour répondre aux conditions du FDE et ne puisse ainsi contribuer à donner un contrôle aux administrations contractantes. - Intégration de produits disponibles sur le marché dans une réalisation du profil, dans l'un des cas précités: il convient que le fournisseur d'un produit présente les formulaires PICS relatifs au produit, dûment remplis conformément à la présente PRL, et garantisse la conformité du produit aux spécifications du profil qui sont applicables; ce PICS peut ensuite être transmis en tant qu'élément de l'ICS du profil. - Après la mise en oeuvre, il convient de conserver l'ICS dans la documentation de la réalisation; elle peut servir à déterminer le potentiel d'interopérabilité avec d'autres administrations et les modifications qui pourraient être nécessaires en cas d'adoption d'autres protocoles. E.3. Notation E.3.1. L'état des diverses fonctions est indiqué suivant la notation ci-après, reprise du document ISO/IEC TR 10000-1 [Référence 2]: m: obligatoire o: optionnel -: non applicable (c'est-à-dire logiquement impossible dans le cadre du profil) x: exclu NOTES 1. Des combinaisons de deux lettres peuvent être utilisées, auquel cas la première lettre désigne l'état (de réalisation) statique, et la seconde l'emploi dynamique; ainsi donc, "mo" signifie "réalisation obligatoire et à emploi optionnel". 2. La notation "o.< n >" désigne un ensemble d'options au choix (c'est-à-dire qu'au moins une option de l'ensemble doit être réalisée) avec le même identificateur n. 3. Une fonction signalée par la lettre "x" peut néanmoins faire partie d'une réalisation pour autant qu'elle ne soit pas utilisée lorsque la réalisation est exploitée dans le cadre du profil. 4. L'emploi de fonctions "x" nécessiterait un accord bilatéral. Dans ce cas, il convient de revoir l'état des fonctions étant donné leur incidence possible sur d'autres réalisations. E.3.2. Les prédicats sont utilisés sous la forme suivante: < prédicat >: introduit un groupe d'éléments qui sont tous conditionnels selon le < prédicat > (l'importance du groupe est indiquée par la présentation). < prédicat >: introduit un seul élément conditionnel selon le < prédicat >. NOTE Dans chaque cas, le prédicat peut être l'identificateur d'une fonction du profil ou une combinaison booléenne de prédicats ("¬" est le symbole de négation logique.) E.3.3. Les spécifications des normes de base sont indiquées suivant la même notation en majuscules (c'est-à-dire, M, O, O.< n >, X). E.4. Instructions pour remplir les formulaires PICS E.4.1. Pour établir l'ICS du profil, les formulaires PICS des normes de base citées en référence doivent être remplis et complétés par les autres éléments PICS relatifs au profil mentionnés dans la présente Annexe. E.4.2. Lorsque le profil apporte des affinements aux caractéristiques des normes de base, les conditions fixées par cette PRL doivent être appliquées (suivant les indications mentionnées pour l'élément dans la colonne "Caractéristiques du profil") afin de limiter les réponses admissibles dans les formulaires PICS de la norme de base. E.4.3. Lorsque le profil fixe des conditions supplémentaires, la colonne de réponse pour ces éléments doit être remplie. Dans cette colonne, la réponse doit soit être choisie parmi les solutions proposées, soit comprendre une valeur ou une gamme de valeurs de paramètre. E.4.4. Si une condition obligatoire n'est pas satisfaite, des informations sur les conditions d'exception doivent être jointes à un justificatif de non-conformité, au moyen d'une référence X< i >, < i > étant un identificateur unique.NOTE Un motif d'exception peut être le cas d'une réalisation pour laquelle un rapport de défaut est en cours concernant une disposition du profil; si le rapport de défaut est accepté, la réalisation est alors jugée conforme. E.5. Références E.5.1. Le présent profil renvoie aux spécifications des protocoles suivants: - Protocole de transfert de messages (Annexe A à la présente Norme Eurocontrol) - Protocole d'en-tête de message (Annexe B à la présente Norme Eurocontrol) - Protocole de réseau en mode connexion faisant appel à la norme ISO/IEC 8208 (Annexe C à la présente Norme Eurocontrol) - ISO/IEC 7776 [Référence 6] - Normes relatives à la couche physique mentionnées dans la clause 1 de la Recommandation X.25 (1993) de l'UIT-T [Référence 1]. E.5.2. En l'absence de formulaire PICS spécifiquement prévu pour les normes applicables à la couche physique, il convient d'utiliser les formulaires PICS provisoires pour la couche physique figurant dans le document ISO/IEC ISP 10609-9, clause A.4 [Référence 8]. E.6. Déclaration de conformité E.6.1. Présentation générale de conformité >PIC FILE= "L_2000254FR.021101.EPS"> E.6.2. Conditions de conformité dynamique >PIC FILE= "L_2000254FR.021201.EPS"> E.7. Conditions applicables aux couches supérieures Tableau 3 Protocole de transfert de messages >EMPLACEMENT TABLE> E.8. Conditions applicables aux couches inférieures E.8.1. Conditions applicables à la couche transport Tableau 4 Protocole d'en-tête de message >EMPLACEMENT TABLE> E.8.2. Conditions applicables à la couche réseau Les PRL de la présente section s'inspirent du formulaire PICS de la norme ISO/IEC 8208:1993 [Référence 7]. Les données de la colonne "Références" sous "Caractéristiques des normes de base" dans les tableaux qui suivent renvoient aux dispositions des normes correspondantes. E.8.2.1. Caractéristiques générales de l'ETTD Tableau 5 Caractéristiques générales de l'ETTD >EMPLACEMENT TABLE> E.8.2.2. Procédures, types et formats des paquets Tableau 6 Fonctions de la couche paquets indépendantes des voies logiques >EMPLACEMENT TABLE> Tableau 7 Établissement de communication >EMPLACEMENT TABLE> Tableau 8 Libération de communication >EMPLACEMENT TABLE> Tableau 9 Réinitialisation des voies logiques >EMPLACEMENT TABLE> Tableau 10 Procédures d'erreur >EMPLACEMENT TABLE> Tableau 11 Transfert des interruptions >EMPLACEMENT TABLE> Tableau 12 Émission de données >EMPLACEMENT TABLE> Tableau 13 Réception de données >EMPLACEMENT TABLE> Tableau 14 Confirmation de remise >EMPLACEMENT TABLE> E.8.2.3. Caractéristiques et options diverses Tableau 15 Valeurs des codes de cause et de diagnostic >EMPLACEMENT TABLE> E.8.2.4. Services complémentaires Tableau 16 Services complémentaires envoyés par les paquets d'APPEL >EMPLACEMENT TABLE> Tableau 17 Services complémentaires envoyés dans les paquets COMMUNICATION ACCEPTÉE >EMPLACEMENT TABLE> Tableau 18 Services complémentaires envoyés dans les paquets d'APPEL >EMPLACEMENT TABLE> Tableau 19 Services complémentaires reçus dans les paquets APPEL ENTRANT >EMPLACEMENT TABLE> Tableau 20 Services complémentaires reçus dans les paquets COMMUNICATION ÉTABLIE >EMPLACEMENT TABLE> Tableau 21 Services complémentaires reçus dans les paquets INDICATION DE LIBÉRATION >EMPLACEMENT TABLE> Tableau 22 Services complémentaires reçus dans les paquets CONFIRMATION DE LIBÉRATION >EMPLACEMENT TABLE> E.8.2.5. Valeurs et plages des paramètres Tableau 23 Valeurs et plages des paramètres >EMPLACEMENT TABLE> E.8.3. Conditions applicables à la couche liaison de données Les PRL de la présente section s'appuient sur le formulaire PICS de la norme ISO/IEC 7776:1994 [Référence 6]. Les mentions dans la colonne "Références" de la rubrique "Caractéristiques des normes de base" renvoient aux dispositions des normes visées. Tableau 24 Protocole de liaison de données >EMPLACEMENT TABLE> E.8.4. Conditions applicables à la couche physique Voir le document ISO/IEC TR 10609-9, clause A.4 [Référence 8]. ANNEXE F (Informative) MÉTHODES DE TEST DE CONFORMITÉ F.1. Introduction F.1.1. Il importe que les réalisations du présent ICD soient telles qu'elles engendrent un haut niveau de confiance, dans l'optique de l'interfonctionnement des centres de contrôle de la circulation aérienne (ATCC) au moyen de l'interface. F.1.2. Il est probable que les États membres utilisent plusieurs sources d'approvisionnement pour réaliser l'interface. Pour obtenir un niveau de confiance élevé dans l'interfonctionnement de ces réalisations, il est nécessaire d'établir un ensemble commun de conditions de test de conformité de façon à uniformiser la préparation et le déroulement des tests ainsi que la présentation des résultats. F.2. Objet et portée F.2.1. La présente Annexe définit les conditions applicables aux tests de conformité des réalisations de la présente Norme Eurocontrol, dont elle fait partie intégrante. F.2.2. Elle désigne les mécanismes par lesquels la confiance dans l'interface déclarée peut s'établir au moyen de tests de validation de la demande. F.3. Bibliographie Le document ci-après présente un intérêt pour les tests de réalisations de la présente Norme Eurocontrol: Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1, dated 10 May 1996 [Référence 15] (disponible uniquement en langue anglaise). F.4. Méthodes et procédés de mise au point F.4.1. Les réalisations de l'ICD peuvent faire appel à certaines options et versions de l'ICD proprement dit. Pour démontrer les possibilités d'interfonctionnement, un État membre réalisant l'interface doit faire connaître les éléments de l'ICD qui sont acceptés, en soumettant une déclaration précise sur les capacités, et les limites éventuellement applicables aux paramètres variables. F.4.2. Il convient de soumettre toute réalisation à un test de conformité tel qu'il est décrit ci-dessous. F.5. Tests F.5.1. Introduction F.5.1.1. Afin d'établir la confiance nécessaire et d'apporter l'appui voulu à l'interface FDE au sein d'un ATCC en vue de l'interfonctionnement d'applications FDE coopérantes, il est souhaitable que chaque réalisation soit soumise à des tests de conformité aux normes dont la présente Annexe fait partie. Ces tests, qui concernent le comportement extérieur du système à tester (SUT), sont destinés à mesurer la capacité d'interfonctionnement du système terminal et non son aptitude à fournir un service donné. F.5.1.2. Les résultats de ces tests peuvent servir de preuves à l'appui d'une déclaration de conformité soumise conformément à la Section 6.1 de la présente partie de la Norme Eurocontrol. Les formulaires PICS et les PRL évoqués dans les présentes spécifications de profil peuvent être utilisés comme de base de départ; en outre, les normes internationales (par exemple la norme ISO/IEC 8208 [Référence 7]) peuvent comporter des suites de tests abstraits définies qui peuvent être exploitées dans les tests de conformité. F.5.1.3. Le présent document vise à fournir un programme uniforme de tests qui s'appuie sur une suite de tests normalisés dont l'emploi devrait garantir la comparabilité des résultats et leur acceptation à un large niveau, ce qui permettrait de limiter au minimum les essais de conformité. La suite de tests normalisés a été établie en partie par Eurocontrol. F.5.1.4. Sur la base de la Figure 2, l'essai de l'ensemble du système terminal prend la forme de tests sur les 3 couches inférieures. Il est souhaitable d'inclure des essais sur les messages d'application FDE, d'état, de système et d'opérateur. F.5.1.5. Il convient de mener chacun des tests suivant l'ordre dans lequel il est présenté ci-dessous. Le dernier test ne pourra être fructueux que si les couches inférieures fonctionnement correctement, ce que les premiers tests devraient permettre de vérifier. F.5.1.6. Quoi qu'il en soit, les tests décrits dans la présente section sont volontaires. F.5.2. Tests des couches inférieures (Couches 1 à 3) Pour garantir l'interfonctionnement de tout ATCC avec ses homologues, il est recommandé que chaque test s'inspire du plan de tests d'intégration FDE ICD établi par Eurocontrol (Division Systèmes du Centre de contrôle de Maastricht). Les procédures de test doivent être convenues bilatéralement entre les ATCC coopérants. F.5.3. Test de la couche application Une série de tests décidée au niveau bilatéral doit être réalisée conjointement par les ATCC coopérants. F.5.4. Homologation Les résultats des tests doivent être consignés et approuvés par les parties coopérantes. F.5.5. Notification Il convient que les États membres communiquent à Eurocontrol toutes précisions sur les résultats des tests qu'ils ont menés. ANNEXE G (Informative) ASSIGNATION DES IDENTIFICATEURS D'ORGANISME ATC Le tableau ci-dessous donne la liste des identificateurs d'organisme ATC assignés au 22 avril 1997. Des données actualisées peuvent être obtenues auprès d'Eurocontrol. Le tableau indique également sous forme hexadécimale le codage binaire de l'identificateur qui fait partie du codage d'adresse NSAP défini à l'Annexe C. Tableau 1 Identificateurs des organismes ATC >EMPLACEMENT TABLE> ANNEXE H (Informative) DIRECTIVES SUR LA FIABILITÉ, LA DISPONIBILITÉ ET LA SÉCURITÉ H.1. Introduction Il est prévu que des applications ATC telles qu'OLDI vont utiliser les services de télécommunication fournis par des réseaux X.25 publics ou privés interconnectés. Par conséquent, il est considéré comme nécessaire de fournir des directives aux réalisations FDE ICD. H.2. Objet et portée H.2.1. La présente Annexe décrit des directives relatives à la fiabilité, la disponibilité et la sécurité. H.2.2. La présente Annexe s'appuie sur deux scénarios. Le premier correspond à une liaison point à point sur un liaison spécialisée. Le second est basé dans un environnement de réseaux X.25 interconnectés.NOTE Dans le cadre du second scénario, tout ce qui se rapporte à l'interconnexion des réseaux X.25 n'est pas pris en considération. H.2.3. Il est convenu qu'une protection soit assurée contre l'intrusion physique, les pannes d'alimentation et les autres menaces extérieures pouvant affecter les opérations normales. H.3. Bibliographie La présente annexe est une vue d'ensemble du document détaillé d'analyse technique mentionné ci-dessous: Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [Référence 16] (disponible uniquement en langue anglaise). H.4. Réalisation sur base de liaison spécialisée H.4.1. Fiabilité Afin d'accroître la fiabilité du service physique, les circuits des liaisons spécialisées, les circuits RTPC ainsi que les circuits du réseau numérique avec intégration des services (RNIS) doivent emprunter des chemins de câbles physiquement différents et être reliés à des commutateurs différents de l'opérateur de télécommunication (ceci doit être précisé à l'opérateur de télécommunication). H.4.2. Disponibilité H.4.2.1. En raison des délais d'établissement sur circuit RTPC qui sont incompatibles avec des applications à contrainte de temps, il convient d'utiliser RNIS comme moyen de secours. H.4.2.2. Dans le cas de basculement de l'ETTD, il est convient que l'ETTD de secours génère une trame DISC pour accélérer le rétablissement de la connexion. H.4.3. Sécurité H.4.3.1. Lors de l'utilisation de RNIS comme moyen de secours, il convient que l'adaptateur de terminal (TA) RNIS appelé valide l'adresse E.164 de l'appelant [Référence 18]. H.4.3.2. Il convient que l'ETTD appelant soit conforme à la Recommandation X.32 de l'UIT-T [Référence 17] en incluant l'information d'identification et d'authentification de l'appelant. H.4.4. Exemple de configuration Figure H.1 Exemple de configuration pour une liaison spécialisée >PIC FILE= "L_2000254FR.023301.EPS"> H.5. Réalisation sur base de réseau H.5.1. Fiabilité Afin d'accroître la fiabilité du service, il convient de connecter les systèmes d'un même site à deux ETCD appartenant à des commutateurs différents du réseau (ce besoin doit être spécifié à l'opérateur réseau). H.5.2. Disponibilité H.5.2.1. Il convient d'utiliser le service complémentaire de recherche de groupe afin d'assigner une seule adresse X.121 [Référence 20] aux ETCD d'un même site, ce qui optimise le routage réseau et limite le nombre d'appels non-établis. H.5.2.2. Dans le cas ou d'autres mécanismes sont utilisés qui entraînent une différence de valeur d'adresse ETTD appelé dans les paquets d'APPEL et COMMUNICATION ACCEPTEE, il convient de configurer l'ETTD appelant pour qu'il n'y ait aucun impact sur l'établissement de l'appel. H.5.2.3. Dans le cas d'une déconnexion de l'ETCD provoqué par une défaillance dans le réseau et qu'un second ETCD raccordé au réseau est disponible, il convient d'exécuter la reprise par l'intermédiaire de ce second accès. H.5.3. Sécurité Dans le cadre de cet Annexe il convient d'utiliser le service complémentaire groupe fermé d'usagés (GFU) qui est le seul service réseau applicable. H.6. Directives générales pour les réalisations liaison spécialisée et réseau H.6.1. Fiabilité H.6.1.1. Le basculement total d'un système peut être long, il est judicieux de considérer l'utilisation d'un processeur frontal (PF) pour pallier à ce type de panne. H.6.1.2. Une architecture sur base de processeur frontal peut accroître la fiabilité du service.NOTE L'inclusion d'une couche de transport dans la spécification du profil sera éventuellement développée dans le contexte du futur standard FDE ICD Partie 2. H.6.2. Disponibilité Lors d'un appel non-établi, il convient que le site appelant appelle une deuxième fois en utilisant la seconde adresse X.121 (si disponible). H.6.3. Gestion des systèmes H.6.3.1. Il convient d'utiliser lorsque que c'est possible, des commutateurs qui peuvent basculer automatiquement en scrutant les signaux d'interface. H.6.3.2. Pendant la phase de transfert de données, une indication d'erreur locale peut être utilisée pour déclencher le basculement des systèmes. H.6.3.3. Lors du basculement d'un PF, il convient de générer une libération-CT afin de s'assurer que le système local soit dans l'état REPOS. H.6.3.4. Lors de l'expiration des temporisateurs des couches liaison de données ou réseau X.25, il convient de libérer les couches supérieures. H.6.3.5. Il convient de générer une libération-CT lors d'une panne totale d'un PF H.6.3.6. À partir du système de gestion, il convient d'interroger la couche protocole de transfert de message (Annexe A) et de vérifier la machine état afin de faire la distinction entre une panne du protocole de transfert de message et une panne de l'application. H.6.4. Exemple de configuration Figure H.2 Exemple de configuration réseau >PIC FILE= "L_2000254FR.023401.EPS"> Fin du document Document livré le: 22/01/2001

[ Enregistrement ] - [ Plan du site ] - [ Recherche ] - [ Aide ] - [ Commentaires ] - [ © ]