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

>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

>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

>TABLE>

Tableau 5-3

Procédure de dialogue - Messages de la phase de coordination

(en complément au Tableau 5-2)

>TABLE>

Tableau 5-4

Procédure de dialogue - Messages de la phase de transfert

>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 messa