2000R2082 — FR — 15.06.2002 — 001.001 — 1
Ce document constitue un outil de documentation et n'engage pas la responsabilité des institutions
►BRÈGLEMENT (CE) No2082/2000 DE LA COMMISSION
du 6 septembre 2000
portantadoptiondenormesEurocontroletmodificationdeladirective97/15/CEportantadoption
de normes Eurocontrol et modification de la directive 93/65/CEE
(JO L 254 du 9.10.2000, p. 1)
Modifié par:
Journal officiel
nopage date
►M1Règlement (CE) no980/2002 de la Commissiondu 4 juin2002 L 150 38 8.6.2002
▼B
RÈGLEMENT (CE) No2082/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'acquisitiond'équipemen ts et de systèmes pour la gestiondu traficaérien(
1), et enparticulier sonarticle 3,
vu la directive 97/15/CE de la Commissiondu 25 mars 1997 portan t
adoption de normes Eurocontrol et modification de la directive 93/65/CEE du Conseil relative à la définition et à l'utilisation de spécifica-tions techniques compatibles pour l'acquisition d'équipements et de
systèmes pour gestiondu 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 normeEurocontrol relative à la présentation de l'échange de données
ATS (ADEXP), édition1.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'édi-
tion 2.0 de la norme ADEXP, ainsi qu'une nouvelle norme
Eurocontrol intitulée «Document de contrôle d'interface pourl'é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 Étatsmembres, notamment en ce qui concerne le transfert des volsentre centres de contrôle de la circulation aérienne (OLDI), lagestion des courants de trafic aérien (ADEXP) et les communi-cations entre les systèmes nationaux (FDE-ICD).
(4)L'édition 2.2 de la norme OLDI et l'édition 2.0 de la normeADEXP remplacent et annulent les précédentes éditions envigueur actuellement, conformément aux dispositions de
l'article 1
erde 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 ducomité 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œuvre d'unsystème européenin tégré pour la gestiondutrafic 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ésentrèglement,
— la norme Eurocontrol relative à la présentation de l'échange de
données ATS (ADEXP), édition 2.0 (document de référence Euro-2000R2082 — FR — 15.06.2002 — 001.001 — 2
(1) JO L 187 du 29.7.1993, p. 52.
(2) JO L 95 du 10.4.1997, p. 16.
▼B
control 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 (docu-ment 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 1
erde 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 publicationau Journal officiel des Communautés européennes .
Le présent règlement est obligatoire dans tous ces éléments et directe-
ment applicable dans tout État membre.2000R2082 — FR — 15.06.2002 — 001.001 — 3
▼B
ANNEXE I
ÉCHANGE DE DONNÉES EN LIGNE (OLDI), ÉDITION 2.2
(document de référence Eurocontrol DPS.ET1.ST06-STD)2000R2082 — FR — 15.06.2002 — 001.001 — 4
▼B
TABLE DES MATIÈRES
AVERTISSEMENT/DROITS D'AUTEUR
AVANT-PROPOS1. INTRODUCTION
1.1. Objectif1.2. Domaine d'application
2. RÉFÉRENCES3. DÉFINITIONS, SYMBOLES ET ABRÉVIATIONS
3.1. Définitions3.2. Symboles et abréviations
4. CARACTÉRISTIQUES GÉNÉRALES
4.1. Introduction4.2. Caractéristiques requises du système de traitement des données de vol4.2.1. Base de données de vol4.2.2. Fonctionnement en temps réel4.2.3. Moyens de communication de données4.2.4. Fonctions d'application4.2.5. Interface homme-machine (HMI)4.2.6. Déclenchement des messages4.2.7. Réceptiondes messages4.3. Actualisation à partir des données de surveillance4.4. Enregistrement des données OLDI4.4.1. Contenu4.4.2. Moyens4.5. Disponibilité, fiabilité, sécurité et intégrité des données4.5.1. Disponibilité4.5.2. Fiabilité4.5.3. Sécurité des données4.5.4. Intégrité des données4.6. Évaluation opérationnelle4.6.1. Période d'évaluation4.6.2. Date de mise en service opérationnel
5. CATÉGORIES DE MESSAGE
5.1. Généralités5.1.1. Objet5.1.2. Catégories de message5.2. Temps de transaction5.2.1. Temps de transaction — Conditions5.3. Classificationet classemen t des messages2000R2082 — FR — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Classificationdes messages — Obligatoires et complémen taires
5.3.2. Classement des messages
6. PROCÉDURE DE BASE — MESSAGES OBLIGATOIRES
6.1. Généralités6.1.1. Descriptiondes prescription s6.1.2. Mise enœuvre6.2. Message de préavis de franchissement de limite (ABI)
6.2.1. Objet du message ABI
6.2.2. Compositiondu message6.2.3. Règles d'application6.2.4. Accusé de réceptionde l'ABI6.2.5. Exemples6.3. Message d'activation(ACT)
6.3.1. Objet du message ACT
6.3.2. Compositiondu message6.3.3. Règles d'application6.3.4. Accusé de réceptiondu message ACT6.3.5. Exemples
6.4. Message d'accusé de réceptionlogique (LAM)
6.4.1. Objet du message LAM6.4.2. Compositiondu message6.4.3. Règles d'application6.4.4. Accusé de réceptiondu LAM6.4.5. Exemples
7. PROCÉDURE DE BASE — MESSAGES COMPLÉMENTAIRES
7.1. Généralités
7.1.1. Descriptiondes prescription s7.1.2. Mise enœuvre7.2. Message d'activationprélimin aire(PAC)7.2.1. Objet du message PAC7.2.2. Compositiondu message
7.2.3. Règles d'application
7.2.4. Accusé de réceptiondu PAC7.2.5. Exemples7.3. Message de révision(REV)7.3.1. Objet du message REV
7.3.2. Compositiondu message
7.3.3. Règles d'application7.3.4. Accusé de réceptiondu REV7.3.5. Exemples2000R2082 — FR — 15.06.2002 — 001.001 — 6
▼B
7.4. Message d'abrogationde coordin ation(MAC)
7.4.1. Objet du message MAC7.4.2. Compositiondu message
7.4.3. Règles d'application
7.4.4. Accusé de réceptiondu MAC7.4.5. Exemples7.5. Message d'assignation de code SSR (COD)
7.5.1. Objet du message COD
7.5.2. Compositiondu message7.5.3. Règles d'application
7.5.4. Accusé de réceptiondu COD
7.5.5. Exemples7.6. Message d'information (INF)7.6.1. Objet du message INF
7.6.2. Compositiondu message
7.6.3. Règles d'application7.6.4. Accusé de réceptionde l'INF
7.6.5. Exemples
8. PROCÉDURE DE DIALOGUE — COORDINATION
8.1. Généralités8.1.1. Introduction
8.1.2. Le filtre
8.1.3. Séquence des messages8.1.4. Traitement simultané des messages8.1.5. Traitement des messages de rejet
8.1.6. Temps imparti pour réponse opérationnelle
8.1.7. Mise enœuvre8.2. Message d'activation(ACT)
8.2.1. Objet du message ACT
8.2.2. Compositiondu message8.2.3. Règles d'application
8.2.4. Accusé de réceptiondes messages ACT
8.3. Message de propositiond'activationsoumise pour accord (RAP)8.3.1. Objet du message RAP8.3.2. Compositiondu message
8.3.3. Règles d'application
8.3.4. Accusé de réceptiondu RAP8.3.5. Réponse opérationnelle au RAP
8.3.6. Exemples
8.4. Message de révision(REV)2000R2082 — FR — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Objet du message REV
8.4.2. Compositiondu message8.4.3. Règles d'application
8.4.4. Accusé de réceptiondu REV
8.4.5. Réponse opérationnelle au REV8.5. Message de propositionde révisionsoumis pour accord (RRV)8.5.1. Objet du message RRV
8.5.2. Compositiondu message
8.5.3. Règles d'application8.5.4. Accusé de réceptiondu RRV
8.5.5. Réponse opérationnelle au RRV
8.5.6. Exemples8.6. Message d'attente de transfert (SBY)8.6.1. Objet du message SBY
8.6.2. Compositiondu message
8.6.3. Règles d'application8.6.4. Accusé de réceptiondu SBY
8.6.5. Exemples
8.7. Message d'acceptation(ACP)8.7.1. Objet du message ACP
8.7.2. Compositiondu message
8.7.3. Règles d'application8.7.4. Accusé de réceptionde l'ACP8.7.5. Exemples
8.8. Message de coordination (CDN)
8.8.1. Objet du message CDN8.8.2. Compositiondu message
8.8.3. Règles d'application
8.8.4. Accusé de réceptiondu CDN8.8.5. Réponse opérationnelle au CDN8.8.6. Exemples
8.9. Message de rejet de coordination (RJC)
8.9.1. Objet du message RJC8.9.2. Compositiondu message
8.9.3. Règles d'application
8.9.4. Accusé de réceptiondu RJC8.9.5. Exemples
9. PROCÉDURE DE DIALOGUE — TRANSFERT DE COMMUNICATION
9.1. Généralités
9.1.1. Introduction2000R2082 — FR — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Séquence de messages
9.1.3. Transfert de communications9.2. Message de déclenchement de transfert (TIM)
9.2.1. Objet du message TIM
9.2.2. Compositiondu message9.2.3. Règles d'application9.2.4. Accusé de réceptiondu TIM9.2.5. Exemple9.3. Message de données supplémentaires (SDM)9.3.1. Objet du message SDM9.3.2. Compositiondu message9.3.3. Règles d'application9.3.4. Accusé de réceptiondu SDM9.3.5. Exemple9.4. Propositionde tran sfert de vol (HOP)9.4.1. Objet du message HOP9.4.2. Compositiondu message9.4.3. Règles d'application9.4.4. Accusé de réceptiondu HOP9.4.5. Exemple9.5. Message de demande de changement de fréquence (ROF)
9.5.1. Objet du message ROF
9.5.2. Compositiondu message9.5.3. Règles d'application9.5.4. Accusé de réceptiondu ROF9.5.5. Exemple9.6. Message de changement de fréquence (COF)9.6.1. Objet du message COF9.6.2. Compositiondu message9.6.3. Règles d'application9.6.4. Accusé de réceptiondu COF9.6.5. Exemples9.7. Message de prise en charge manuelle des communications (MAS)9.7.1. Objet du message MAS9.7.2. Compositiondu message9.7.3. Règles d'application9.7.4. Accusé de réceptiondes MAS9.7.5. Exemple
ANNEX A (NORMATIVE) RÈGLES D'INTRODUCTION DES DONNÉES
ANNEX B (NORMATIVE) PRESCRIPTIONS APPLICABLES AU TRAITEMENT DES ACHEMI-
NEMENTS2000R2082 — FR — 15.06.2002 — 001.001 — 9
▼B
ANNEX C (INFORMATIVE) PHASES DE LA PROCÉDURE DE DIALOGUE (SYSCO NIVEAU 1)
— SÉQUENCE DE MESSAGES2000R2082 — FR — 15.06.2002 — 001.001 — 10
▼B
AVERTISSEMENT/DROITSD'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 divulga-
tion à des tiers toutefois subordonnée à une autorisation préalable de
l'Agence Eurocontrol2000R2082 — FR — 15.06.2002 — 001.001 — 11
▼B
AVANT-PROPOS
1. Organe compétent
La norme Eurocontrol pour l'échange de données en ligne
(OLDI), Édition2.2, a été établie par la DirectionDéveloppemen t
(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'Eurocon-
trol, à 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), Édition2.0, endate 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 Norma-
lisationd'Eurocon trol:
— approbation par le Groupe «Besoins opérationnels et traite-
ment 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;
— approbationpar 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.
Afinde suivre l'évolutiondes procédures de con trôle de la circu-
lation aérienne (ATC), des amendements et additifs pourront être
proposés par l'intermédiaire de l'ODT, pour examen et approba-
tion éventuelle. Les prescriptions seront ensuite intégrées soit
dans un amendement, soit dans une nouvelle édition du docu-
ment, à soumettre pour approbation et adoption suivant les
procédures applicables.
4. Dispositions typographiques
Afinde mettre enrelief 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édactiondes spécification s, 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» enan glais).
Les notes sont imprimées en italiques ordinaires, précédées du
préfixe «NOTE».
5. Lienavecl'Édition1delaNormeEurocontrolpourl'é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.2000R2082 — FR — 15.06.2002 — 001.001 — 12
▼B
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'abrogationde coordin ation(MAC);
— Message d'assignation de code (COD) pour radar secon-
daire de surveillance (SSR)
— Message d'information (INF).
2. Définition du contenu et du format du message à envoyer lors-
qu'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
findu tron çonde 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-proposi-
tion sur les conditions de transfert;
— la mise à disposition de moyens de transfert de communi-
cation dans le cadre de la procédure de transfert de
contrôle.
4. Mise enservice du format décrit dan s l'Édition2 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 coordina-
tion 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 trans-
fert 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'Édition2.2 son t illustrés par des
exemples)
D: Rappel historique
E: Plande mise enœuvre
F: Degré de conformité respecté par les ÉtatsG: Directives pour la mise enœuvreH: Directives pour l'évaluationdes liaison s.
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é
enRéféren ce 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
unautre, la défin itiondes 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é
enRéféren ce 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.2000R2082 — FR — 15.06.2002 — 001.001 — 13
▼B
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 orga-
nismes 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. Afind'enfaciliter la mise enœuvre, 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 confor-
mé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 œuvre entre FDPS des organismes ATC dans le but d'assurer:
— la coordination nécessaire préalablement au transfert des vols
d'unorgan isme à unautre;
— 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 orga-
nismes 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 Eurocon-
trol.
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.2000R2082 — FR — 15.06.2002 — 001.001 — 14
▼B
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, Docu-
ment 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 orga-
nisme 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 unsystè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 responsabi-
lité d'unorgan isme ATC.
3.1.11. Niveau de vol autorisé : Niveau auquel ou jusqu'auquel l'ATC a
autorisé unaéron ef à voler.
3.1.12. Coordination ATC : Processus par lequel des organismes ATC,
dont les zones de responsabilité sont adjacentes, s'informent offi-
ciellement 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 franchisse-
ment 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.2000R2082 — FR — 15.06.2002 — 001.001 — 15
▼B
3.1.17. Norme Eurocontrol : Toute spécificationapplicable aux caractéris-
tiques 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 œuvre de systèmes
ATS dans les Etats membres d'Eurocontrol. Une Norme Eurocon-
trol 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 unvol 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 fran-
chissement 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 servi-
ces 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 unsystè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 enRéféren ce 1.
3.1.23. Niveau: Terme générique employé pour indiquer la position verti-
cale 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 unvol a été coor-
donné 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éclenche-
ment 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 coordina-
tion, au cours de laquelle le transfert de communication est
effectué.
3.1.34. Organisme transférant : Dans une séquence de coordination, orga-
nisme 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.2000R2082 — FR — 15.06.2002 — 001.001 — 16
▼B
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 à unposte de travail encas
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'acceptationACT Message d'activation
ADEXP Présentation de l'échange de données ATS
ATC Contrôle de la circulation aérienneATM Gestion de la circulation aérienne
ATS Service de la circulation aérienne
CCR Centre de contrôle régionalCDN Message de coordination
CEAC Conférence européenne de l'aviation civile
CNL Annulation de plan de volCOD Message d'assignation de code SSR
COF Message de changement de fréquence
COP Point de coordinationDED Direction «Développement d'EATCHIP» à Eurocon-
trol
EATCHIP Programme européen d'harmonisation et d'intégra-
tion du contrôle de la circulation aérienne
ETO Heure estimée de survol (d'unpoin t)
ETOT Heure estimée de décollageEWPD Document «Programme de travail EATCHIP»
FDPS Système de traitement des données de vol
FRF Suite de la route du volHMI Interface homme/machine
HOP Message de propositionde tran sfert
INF Message d'informationLAM Message d'accusé de réceptionlogique
LoA Lettre d'accord
MAC Message d'abrogationde la coordin ationMAS Prise en charge manuelle des communications
NM Milles nautiques
OACI Organisation de l'aviation civile internationaleOLDI Échange de données en ligneORCAM Méthode d'assignation des codes en fonction de la
régiond'origin e
PAC Message d'activationprélimin aire
RAP Message de propositiond'activationsoumise pour
accord
REV Message de révision
RJC Message de rejet de coordination
ROF Message de demande de changement de fréquenceRRV Message de révisionsoumis pour accord
SBY Message d'attente de transfert
SDM Message de données supplémentairesSSR Radar secondaire de surveillance
SYSCO Coordination automatisée2000R2082 — FR — 15.06.2002 — 001.001 — 17
▼B
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ÉRISTIQUESGÉNÉRALES
4.1. Introduction
La présente section décrit les caractéristiques opérationnelles
générales nécessaires à la mise en œuvre 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 conte-
nant 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 applica-
bles, 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 enmesure de recevoir et de tran smettre 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 communi-
cation 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,2000R2082 — FR — 15.06.2002 — 001.001 — 18
▼B
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.
NOTELes 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 coordina-
tiondes vols enquestion .
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 unen semble de paramètres tech-
niques 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éra-
tionnelle 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éceptionau n iveau applicationdoit être reçu
(temps imparti).
4.2.6.5. Un message doit être transmis sans retard lorsque les informa-
tions 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 trans-
missiondu message ACT est déjà enretard compte ten u des
paramètres de temps applicables; le message doit donc être
envoyé sans attendre.2000R2082 — FR — 15.06.2002 — 001.001 — 19
▼B
4.2.7. Réception des messages
4.2.7.1. Le système ATC doit être enmesure:
— 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. Unmessage d'accusé de réception(Accusé de réceptionlogique
(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.
NOTELes 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 informa-
tions 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 disponi-
ble 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 liaisonOLDI 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 équiva-
lant à 52 minutes maximum par an, sur la base d'une
disponibilité 24 heures sur 24).
4.5.3. Sécurité des données
RecommandationIl 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.2000R2082 — FR — 15.06.2002 — 001.001 — 20
▼B
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.
NOTEUne procédure facilitant l'évaluation d'un nouveau dispo-
sitif 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ÉGORIESDE 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'orga-
nisme 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
Catégorie de message 90 % 99,8 %
1 4 sec 10 sec
2 10 sec 25 sec
3 15 sec 45 sec
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 transmis-
sion 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.2000R2082 — FR — 15.06.2002 — 001.001 — 21
▼B
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'unmessage est classé dan s 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'unmessage est classé dan s 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.
NOTEDans 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.
NOTELes messages complémentaires peuvent être utilisés dans
un seul sens, en fonction des besoins opérationnelles.
5.3.1.5. Lorsqu'unmessage est classé dan s 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 possi-
bilité 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 communica-
tions 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
TYPE DE MESSAGE ABR CAT TX REC
Préavis de franchissement
de limiteABI 3 M M
ActivationACT 2 M M
RévisionREV 2 C (1)C (1)
Activationprélimin aire PAC 2 C C
Abrogationde la coordin a-
tionMAC 2 C C
Assignation de code SSR COD 2 C C
Information INF 3 C C
Message d'accusé de
réceptionlogiqueLAM M M
NOTE
(1) Obligatoire pour TX et REC dans le cadre de la procédure de dialogue2000R2082 — FR — 15.06.2002 — 001.001 — 22
▼B
Tableau 5-3
Procédure de dialogue — Messages de la phase de coordination
(encomplémen t au Tableau 5-2)
TYPE DE MESSAGE ABR CAT TX REC
Propositiond'activation
soumise pour accordRAP 2 C M
Révisionsoumise pour
accordRRV 2 C M
Coordination CDN 2 M M
Attente de transfert (1) SBY M M
AcceptationACP 2 M M
Rejet de coordination (2) RJC 2 C C
NOTES
(1) Voir l'alinéa 5.2.1.1 sur les conditions applicables aux temps de transaction.
(2) N'est pas utilisé dans toutes les configurations de l'espace aérien.
Tableau 5-4
Procédure de dialogue — Messages de la phase de transfert
TYPE DE MESSAGE ABR CAT TX REC
Déclenchement de trans-
fertTIM 1 M M
Données supplémentaires SDM 1 (1)(1)
Propositionde tran sfert HOP 1 M M
Changement de
fréquence (2)COF 1 C M
Demande de changement
de fréquenceROF 1 C M
Prise encharge
manuelle (2)MAS 1 C M
NOTES
(1) M lorsqu'il est envoyé par l'organisme transférant; C lorsqu'il est envoyé par l'organisme accep-
tant.
(2) Les procédures arrêtées au niveau bilatéral doivent préciser que lorsque le transfert a lieu dans
une direction donnée de trafic, il faut au minimum que, soit l'organisme transférant envoie unmessage COF, soit l'organisme acceptant envoie un message MAS.
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 œuvre du dispositif OLDI.
6.1.2. Mise en œuvre
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 Section8 du présen t docu-
ment, 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;2000R2082 — FR — 15.06.2002 — 001.001 — 23
▼B
— 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élationan ticipée des pistes radar;— faciliter l'évaluationpré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,
— numéro d'aéronef et type,
— type de vol,— aptitude et état des équipements,
— 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.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, unou plusieurs messages ABI doiven t ê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 propositiond'activationsoumis pour accord (RAP).
6.2.3.1.3. Un message ABI ne doit pas être établi si l'envoi d'un message
d'activationprélimin aire (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 transmisimmédiatement ou dans un intervalle de temps agréé bilatérale-
ment.
NOTECette 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. Unmessage ABI révisé doit être en voyé 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 figu-
rant 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 .2000R2082 — FR — 15.06.2002 — 001.001 — 24
▼M1
▼B
▼B
6.2.3.2. Traitement par l'organisme recevant
6.2.3.2.1. Le système ATC qui reçoit unmessage ABI doit ten ter de l'asso-
cier 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éé auto-
matiquement 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 transmission6.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 para-
mètre défini.
6.2.3.3.2. Le(s) paramètre(s) de productionde l'ABI doit (doiven t) ê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éceptiond'unmessage ABI par la production
et la transmission d'un message LAM.
NOTEUn message LAM est produit quels que soient les résul-
tats 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écep-
tion 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 nœuds, 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. O A C I
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.2.5.2. A D E X P
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 -FLTTYP N -BEGIN EQCST -EQPT W/
EQ -EQPT Y/NO -END EQCST-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;2000R2082 — FR — 15.06.2002 — 001.001 — 25
▼M1
▼B
▼B
— 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'orga-
nisme ATC recevant;
— accélérer l'affichage de la corrélationin dicatif 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,— numéro et type d'aéronef,— type de vol,— aptitude et état des équipements,— 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és6.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 coor-
dination en vue de les modifier.
6.3.3.1.10. Un nouveau message ACT ne peut être envoyé au même parte-
naire 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érale-
ment.2000R2082 — FR — 15.06.2002 — 001.001 — 26
▼M1
▼B
▼B
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;
— unLAM doit être en voyé enretour.
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;
— unLAM doit être en voyé enretour;
— unplande 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 productiondu message ACT doiven t figurer
dans la Lettre d'accord entre les organismes ATC intéressés.
6.3.3.3.3. Les paramètres de productiondu message ACT doiven t ê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 condi-
tions 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éceptiond'unmessage 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'exceptionde l'ETO au COP, qui est de 1226 dan s le message
ACT ci-après.2000R2082 — FR — 15.06.2002 — 001.001 — 27
▼M1
6.3.5.1. O A C I
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.3.5.2. A D E X P
-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 -FLTTYP N-BEGIN EQCST-EQPT W/
EQ -EQPT Y/NO -END EQCST-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.
NOTELes 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és6.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éceptionpuisse ê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 lors-
qu'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écep-
tion.
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 0012000R2082 — FR — 15.06.2002 — 001.001 — 28
▼B
▼B
7. PROCÉDURE DE BASE — MESSAGES COMPLÉMEN-
TAIRES
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 Section6 —
Messages obligatoires.
7.1.2. Mise en œuvre
7.1.2.1. L'application de l'une des dispositions décrites dans la présente
sectiondoit faire l'objet d'unaccord bilatéral préalable.
7.1.2.2. Lorsque l'applicationenest 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'orga-
nisme 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).
NOTELes 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és7.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'orga-
nisme 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.2000R2082 — FR — 15.06.2002 — 001.001 — 29
▼B
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'unaccord 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 modificationde 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 recevant7.2.3.2.1. Le système ATC qui reçoit unmessage PAC doit ten ter de l'asso-
cier au plande vol auquel il correspon d.
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 trai-
tement 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;
— unLAM doit être en voyé.
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;
— unLAM doit être en voyé;— unplande 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, unmessage COD doit être ren voyé enplus 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 assi-
gner 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.2000R2082 — FR — 15.06.2002 — 001.001 — 30
▼B
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, unavertissemen t 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'affi-
cher 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'unaccord
bilatéral.
7.2.5. Exemples
7.2.5.1. Heure estimée de décollage et demande de code7.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,
— identification de l'aéronef,
— aérodrome de départ,— données estimées et/ou point de coordination,
— aérodrome de destination,
— référence du message (facultatif),
— mode et code SSR (facultatif),2000R2082 — FR — 15.06.2002 — 001.001 — 31
▼M1
▼M1
— route (facultatif),
— aptitude et état des équipements (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és7.3.3.1.1. Un ou plusieurs messages REV peuvent être envoyés à l'orga-
nisme avec lequel la coordination d'un vol est en cours au
moyend'unmessage 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,— aptitude et état des équipements.
7.3.3.1.3. Unmessage REV doit être en voyé:
— lorsque la variationde l'ETO au COP, par rapport à celle in di-
quée dans le message précédent, est supérieure à la valeur
convenue bilatéralement, arrondie au chiffre entier le plus
proche,
— pour tout changement concernant les niveaux de transfert, le
code SSR ou l'aptitude et l'état des équipements.
7.3.3.1.4. Sous réserve d'accord bilatéral, unmessage REV doit être en voyé
encas de modificationaffectan t
— le COP,
— la route.
NOTE: Des règles opérationnelles peuvent imposer une coordi-
nation 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 I C A O
Tous les messages de révision comprennent les champs 3, 7, 13,
14 et 16. Les règles suivantes s'appliquent:
— 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 comme
éléments b) et c) dans le champ 7.
Tous les autres changements doivent être inclus dans le format de
champ 22 après les cinq premiers champs. Les règles suivantes
s'appliquent:
— les champs inclus dans le format de champ 22 peuvent être
placés dans n'importe quel ordre les uns par rapport aux
autres,
— les changements de COP doivent être mentionnés dans les
données du champ 14 incluses dans le format du champ 22
(voir annexe B — Prescriptions applicables au traitement des
acheminements particuliers),
— les changements de route doivent être mentionnés dans les
données du champ 15 incluses dans le format de champ 22.
Les règles de coordination des changements de cette nature,
y compris les acheminements directs, figurent à l'annexe B2000R2082 — FR — 15.06.2002 — 001.001 — 32
▼B
▼M1
▼B
▼M1
▼M1
— «Prescriptions applicables au traitement des achemine-
ments particuliers»,
— aptitude et état des équipements. Seules les aptitudes modi-
fiées doivent être introduites. Un message indiquant un
changement d'aptitude qui oblige à introduire des données
concernant une aptitude supplémentaire conformément au
paragraphe A.30 de l'annexe A doit inclure la mention de
l'aptitude supplémentaire.
7.3.3.2.2. Format A D E X P
Tous les messages de révisionprésen tés selonle format ADEXP
doivent figurer dans les champs primaires suivants: TITLE
REFDATA ARCID ADEP ADES. Les règles suivantes s'appli-
quent:
— 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,
— le champ primaire COP doit être inclus sauf si un changement
d'ETO ou de niveau de transfert oblige à utiliser le champ
primaire COORDATA. Il doit mentionner le COP par lequel
le vol est coordonné ou, en cas de changement de COP, le
COP par lequel le vol a été précédemment coordonné,
— les changements de COP doivent être mentionnés dans les
données du champ primaire COORDATA (cf. Annexe B,
Prescriptions applicables au traitement des acheminements
particuliers). Ces messages doivent également comporter le
champ primaire COP comme indiqué ci-dessus,
— les changement de route doivent être mentionnés dans les
données du champ primaire ROUTE. Les règles de coordina-
tion des changements de cette nature, y compris les
acheminements directs, figurent à l'annexe B — «Prescrip-
tions applicables au traitement des acheminements
particuliers»,
— un changement au code SSR doit être indiqué par l'inclusion
du champ primaire SSRCODE,
— tout changement concernant les aptitudes et l'état des équipe-
ments doit être mentionné dans le champ primaire EQCST.
Seules les aptitudes modifiées doivent être introduites. Un
message indiquant un changement d'aptitude qui oblige à
introduire des données concernant une aptitude supplémen-
taire conformément au paragraphe A.30 de l'annexe A doit
inclure la mention de l'aptitude supplémentaire.
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 recevant7.3.3.3.1. Unsystème ATC qui reçoit unmessage REV après avoir reçu
également du même organisme ATC un message ACT concernant
le vol enquestiondoit ten ter de l'associer au plande vol corres-
pondant.
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.2000R2082 — FR — 15.06.2002 — 001.001 — 33
▼B
▼B
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éception7.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. O A C I
a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
EGBB)
c) (REVE/L019-AMM253-LMML-BNE/1237F350-EGBB-81/W/
NO)
d) (REVBC/P873-BAF4486-EBMB-NEBUL/2201F250-LERT-
81/W/NO U/EQ)
7.3.5.2. A D E X P
a) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COOR-
DATA -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
c) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 019 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -BEGIN EQCST -EQPT W/NO -END
EQCST
d) -TITLE REV -REFDATA -SENDER -FAC BC -RECVR -
FAC P -SEQNUM 873 -ARCID BAF4486 -ADEP EBMB -
COP NEBUL -ADES LERT -BEGIN EQCST -EQPT Y/NO -
EQPT U/EQ -END EQCST
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);2000R2082 — FR — 15.06.2002 — 001.001 — 34
▼M1
▼B
▼B
— 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).
NOTELes 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és7.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 chan-
gement de l'organisme suivant dans la séquence de
coordination;
— la route suivie par le vol a été modifiée, entraînant un change-
ment de l'organisme suivant dans la séquence de coordination;
— le plande vol est supprimé du système de l'organ isme émet-
tant 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 coordina-
tion, selon le cas, doivent être effectuées avec le nouvel
organisme dans la séquence de coordination.
7.4.3.1.3. Unmessage MAC doit être en voyé encas d'abrogationde 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 estima-
tion 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 bila-
té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 coor-
dination 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 coordi-
nation suivant:
— le statut est INI (initial);
— le motif est l'undes suivan ts:
— 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;2000R2082 — FR — 15.06.2002 — 001.001 — 35
▼B
— 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é,
selonle cas:
— le statut est NTF (notification);
— le motif est l'undes suivan ts:
— DLY encas de retard;
— HLD encas d'atten te;— 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 coordina-
tion:
— une nouveau message de notification et/ou de coordination,
selonle cas, doit être en voyé;
— 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 commu-
niqué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 respon-
sable de la coordination des vols.
7.4.4.2.2. Dans ce cas, l'organisme ATC transférant doit abroger verbale-
ment la coordination.
7.4.5. Exemples
Unmessage ABI a été en voyé 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 exem-
ples (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 à Maas-
tricht, 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 exem-
ples (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 -ADES2000R2082 — FR — 15.06.2002 — 001.001 — 36
▼B
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 descodes, assurée par exemple par unCCR, un e 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
uncode SSR enmode A à chaque organ isme 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).
NOTELes 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és7.5.3.1.1. Un message COD doit être produit et transmis automatiquement
en réponse à une demande d'assignation de code contenue dans
unmessage.
7.5.3.1.2. Le code SSR doit être le code assigné au vol.7.5.3.1.3. Le code de saturationapprouvé, tel qu'il est précisé dan s 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érale-
ment.
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 recevant7.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é correc-
tement.
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ésenta-
tion indiquées à l'Annexe A.2000R2082 — FR — 15.06.2002 — 001.001 — 37
▼B
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éceptiond'unmessage 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 respon-
sable.
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 enoutre à commun iquer à unorga-
nisme 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.
NOTELes 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'orga-
nisme é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.2000R2082 — FR — 15.06.2002 — 001.001 — 38
▼B
7.6.3.3. Teneur opérationnelle
La teneur opérationnelle du message INF doit être présentée selon
le format de l'undes messages existan ts.
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
Recommandations1.L'accusé de réception du message INF peut se faire, selon le
partenaire de coordination, par la production et la transmis-
sion 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, transpon-
deur 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.
Ontrouvera 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 coordina-
tion 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 Section9 — Procédure de dialogue — Tran sfert 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.2000R2082 — FR — 15.06.2002 — 001.001 — 39
▼B
8.1.1.5. La procédure de dialogue enphase de coordin ationpermet 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és8.1.2.1.1. La procédure de dialogue enphase de coordin ationimpose 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, entemps et/ou endistan ce 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 orga-
nismes 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érant8.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 communi-
qué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'effi-
cacité de la procédure de dialogue.2000R2082 — FR — 15.06.2002 — 001.001 — 40
▼B
8.1.3. Séquence des messages
8.1.3.1. Généralités8.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 commu-
nication 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 find'undialogue 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'unaccusé 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és8.1.4.1.1. Un organisme participant à un échange de messages de coordina-
tion 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'unmessage CDN et unmessage 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éceptiondu CDN n i 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és8.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 coordi-
nation 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 parve-
nant après l'expiration du temps imparti.
8.1.7. Mise en œuvre
8.1.7.1. Les procédures de dialogue s'appliquent à deux phases (coordina-
tion et transfert). Les messages et les temps de transaction
nécessaires sont différents dans chacune des phases. Les2000R2082 — FR — 15.06.2002 — 001.001 — 41
▼B
messages de coordination sont présentés dans les formats OACI
et ADEXP, les messages de transfert de contrôle le sont unique-
ment 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œuvre selonl'undes
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émen-
taire, 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 œuvre 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 compositiondu message ACT utilisé dan s 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 parti-
culiè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.
NOTESi 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 coor-
dination 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é entan t 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éter-
miner 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.2000R2082 — FR — 15.06.2002 — 001.001 — 42
▼B
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éception8.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 stan-
dard;
— par unmessage SBY dan s 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, unACP peut remplacer unLAM
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
Enl'absen ce d'accusé de réceptiond'unmessage ACT, unavertis-
sement 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 (unique-
ment possible en ADEXP).
8.3.3. Règles d'application
8.3.3.1. Généralités
8.3.3.1.1. Unmessage RAP doit être en voyé à la place du message ACT
lorsque des vols franchissant la limite remplissent l'une des condi-
tions 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 trans-
fert 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 coordina-
tion 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 unmessage RAP doit ten ter de l'asso-
cier au plan de vol correspondant.2000R2082 — FR — 15.06.2002 — 001.001 — 43
▼B
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;
— unmessage SBY doit être en voyé enretour.
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é;
— unmessage SBY doit être en voyé enretour;
— unplande 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édiate-
ment.
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éceptiondu message par la productionet 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 condi-
tions 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.
NOTEEn 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.2000R2082 — FR — 15.06.2002 — 001.001 — 44
▼B
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 compositiondu message REV doit être con forme à celle
décrite à l'alinéa 7.3.2.
8.4.3. Règles d'application
8.4.3.1. Généralités8.4.3.1.1. Un ou plusieurs messages REV peuvent être envoyés à l'orga-
nisme avec lequel la coordination d'un vol est en cours au
moyend'unmessage d'activationou d'unmessage 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étec-
tion 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 recevant8.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'unaccusé 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éces-
saires 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éception8.4.4.1.1. L'accusé de réceptiondu message REV, s'il est n écessaire, doit
prendre la forme suivante:
— un message LAM si les conditions de transfert sont jugées
standard;2000R2082 — FR — 15.06.2002 — 001.001 — 45
▼B
— 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, unACP peut remplacer unLAM
pour indiquer que l'organisme acceptant accepte un REV conte-
nant des conditions de transfert standard.
8.4.4.2. Absence d'accusé de réception
Enl'absen ce d'accusé de réceptiond'unmessage REV, unavertis-
sement 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'orga-
nisme 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. Messagedepropositionderévisionsoumispouraccord(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évisionproposée est stan dard mais que le
contrôleur transférant souhaite soumettre la révision à l'accord
du contrôleur acceptant.
8.5.2. Composition du message
La compositiondu message RRV doit être con forme à celle du
message REV (exposée à l'alinéa 7.3.2) et peut comporter, à titre
facultatif, les éléments suivants:
— motif, indiquant une présentation manuelle (uniquement
possible enADEXP).
8.5.3. Règles d'application
8.5.3.1. Généralités
Un ou plusieurs messages RRV doivent être envoyés en rempla-
cement des messages REV, pour chaque révision, dans l'un des
cas suivants:
— le système transférant a établi que les conditions de transfert
sont non standard;
— le contrôleur transférant a indiqué que les conditions de trans-
fert proposées doivent être soumises à l'accord du contrôleur
acceptant. L'emploi du RRV dans ce cas est facultatif.
8.5.3.2. Déclenchement de la transmission
Le message RRV doit être transmis dès qu'un changement des
données de coordination est constaté ou être déclenché manuelle-
ment.
8.5.3.3. Traitement par l'organisme recevant
8.5.3.3.1. Si un plan de vol correspondant est trouvé dans l'état «coor-
donné» et qu'aucune anomalie n'est décelée qui empêcherait que
le message ne soit traité correctement:
— le message RRV doit faire l'objet d'unaccusé de réception ;
— dans tous les autres cas, aucun accusé de réception du
message ne doit être envoyé.
8.5.3.3.2. Les conditions de transfert proposées doivent s'afficher sur les
écrans du poste ATC responsable de la coordination du vol.
8.5.3.3.3. Recommandation Il convient d'indiquer le motif de l'accord
sollicité (conditions non standard ou présentation manuelle).2000R2082 — FR — 15.06.2002 — 001.001 — 46
▼B
8.5.4. Accusé de réception du RRV
8.5.4.1. Accusé de réception
Le message doit faire l'objet d'unaccusé de réceptionpar la
productionet la tran smissiond'unmessage SBY.
8.5.4.2. Absence d'accusé de réception
En l'absence de message SBY accusant réception d'un message
RRV, un avertissement doit s'afficher au poste ATC responsable
de la coordination du vol.
8.5.5. Réponse opérationnelle au RRV
Le contrôleur acceptant peut soit accepter, soit refuser un
message RRV, soit soumettre une contre-proposition.
8.5.5.1. Acceptation
Lorsque le contrôleur acceptant choisit d'accepter la proposition
de modification des conditions de transfert agréées, un message
ACP doit être envoyé en retour.
8.5.5.2. Contre-proposition
Lorsque le contrôleur acceptant choisit de soumettre une contre-
proposition, un message CDN doit être envoyé en retour.
8.5.5.3. Rejet
Lorsque le contrôleur acceptant choisit de rejeter la proposition
de modification des conditions de transfert agréées:
— unmessage RJC doit être en voyé enretour;
— un nouveau processus de coordination doit être engagé.
8.5.6. Exemples
8.5.6.1. OACI
(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)
8.5.6.2. ADEXP
-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA
-PTID BNE -TO 1226 -TFL F310 -ADES EGBB
8.6. Message d'attente de transfert (SBY)
8.6.1. Objet du message SBY
Le message SBY accuse réceptiond'unmessage proposan t des
conditions de transfert et indique que la proposition est soumise
au contrôleur, pour décision.
8.6.2. Composition du message
Le message SBY doit comprendre les éléments de données
suivants:
— type de message;
— numéro du message;
— référence du message;
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à
l'Annexe A.
8.6.3. Règles d'application
8.6.3.1. Généralités
Le message SBY doit être produit et transmis automatiquement
dès réception:
— d'unmessage RAP, RRV ou CDN;
— d'unmessage ACT ou REV qui n e passe pas avec succès
l'épreuve du filtre.
8.6.4. Accusé de réception du SBY
Le message SBY ne doit faire l'objet d'aucun accusé de réception.2000R2082 — FR — 15.06.2002 — 001.001 — 47
▼B
8.6.5. Exemples
8.6.5.1. OACI
(SBYL/E027E/L002)
8.6.5.2. ADEXP
-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002
8.7. Message d'acceptation (ACP)
8.7.1. Objet du message ACP
Le message ACP répond aux besoins opérationnels ci-après,
pendant les phases de coordination et de transfert ATC:
— indiquer qu'un contrôleur d'un organisme accepte manuelle-
ment les conditions de transfert proposées par le contrôleur
de l'autre organisme dans un message des catégories
suivantes:
— RAP;
— RRV;— CDN;
— ACT et REV, si l'un ou l'autre est jugé non standard;
— sous réserve d'accord bilatéral, permettre l'acceptationauto-
matique d'unmessage ACT ou REV qui a subi avec succès
l'épreuve du filtre du centre acceptant (en remplacement du
message LAM);
— sous réserve d'accord bilatéral, indiquer l'acceptation manuelle
d'unmessage HOP (enremplacemen t du message ROF).
8.7.2. Composition du message
Le message ACP doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;
— référence du message;
— Données facultatives:
— fréquence;
— Données facultatives au format OACI — le message peut
aussi contenir tous les éléments suivants:
— identification de l'aéronef;
— aérodrome de départ;— aérodrome de destination.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à
l'Annexe A.
8.7.3. Règles d'application
8.7.3.1. Généralités
8.7.3.1.1. La référence du message ACP doit comprendre le numéro du
message auquel l'ACP répond.
8.7.3.1.2. Le champ Fréquence, s'il est inclus, doit indiquer la fréquence sur
laquelle l'aéronef doit contacter l'organisme acceptant au moment
du transfert de contrôle.
8.7.3.1.3. Le message ACP doit être envoyé après acceptation manuelle, par
le contrôleur, des conditions de transfert proposées dans un
message ACT, RAP, REV, RRV ou CDN.
8.7.3.1.4. Le message ACP peut être envoyé à la place d'un message ROF
enrépon se à unmessage HOP.
8.7.3.1.5. Sous réserve d'accord bilatéral, le message ACP doit être produit
et transmis automatiquement par le système en réponse à un
message ACT/REV ayant subi avec succès l'épreuve du filtre.
8.7.3.1.6. Dès réception d'un ACP, les conditions de transfert agréées
deviennent contraignantes pour les deux organismes.2000R2082 — FR — 15.06.2002 — 001.001 — 48
▼B
8.7.3.2. Traitement par l'organisme recevant
8.7.3.2.1. Le système ATC qui reçoit unmessage ACP doit ten ter de l'asso-
cier avec le plan de vol correspondant.
8.7.3.2.2. Si l'ACP peut être associé à unplande vol, l'acceptationdoit être
indiquée au contrôleur.
8.7.3.2.3. Si l'ACP ne peut être associé à un plan de vol:
— un avertissement doit être donné au poste de travail approprié;
— un LAM ne doit pas être envoyé.
8.7.4. Accusé de réception de l'ACP
8.7.4.1. Accusé de réception
8.7.4.1.1. Un LAM ne doit pas être envoyé en retour lorsque l'ACP sert de
réponse automatique pour un message ACT ou REV qui a subi
avec succès l'épreuve du filtre.
8.7.4.1.2. Un message ACP envoyé à la suite d'une acceptation manuelle
doit faire l'objet d'unaccusé de réceptionpar la productionet la
transmission d'un message LAM.
8.7.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
ACP envoyé à la suite d'une acceptation manuelle, un avertisse-
ment doit s'afficher au poste ATC responsable de la coordination
du vol.
8.7.5. Exemples
8.7.5.1. OACI
(ACPL/E027E/L002-18/FRQ/242150)
8.7.5.2. ADEXP
-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002 -FREQ 242150
8.8. Message de coordination (CDN)
8.8.1. Objet du message CDN
Le message CDN répond aux besoins opérationnels suivants:
— transmettre une contre-proposition soumise par le contrôleur
acceptant au contrôleur transférant en réponse à un message
ACT, RAP, REV ou RRV;
— permettre au contrôleur acceptant de soumettre au contrôleur
transférant une proposition de modification des conditions de
transfert agréées.
8.8.2. Composition du message
Le message CDN doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;— référence du message (uniquement s'il s'agit d'une réponse
à unautre message);
— identification de l'aéronef;
— aérodrome de départ;
— aérodrome de destination;
NOTELe message doit également l'un, ou les deux, des
éléments suivants:
— données d'estimées (dans le cas d'un message au format
OACI) ou niveau de transfert (s'il s'agit d'un message
ADEXP);
— demande d'acheminement direct.
— Données agréées au niveau bilatéral. La donnée suivante peut
aussi être incluse:
— fréquence.2000R2082 — FR — 15.06.2002 — 001.001 — 49
▼B
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à
l'Annexe A
8.8.3. Règles d'application
8.8.3.1. Généralités
8.8.3.1.1. Seul le contrôleur acceptant peut envoyer des messages CDN.
8.8.3.1.2. Le message CDN doit servir à transmettre une contre-proposition
soumise par le contrôleur acceptant au contrôleur transférant.
NOTEIl peut s'agir d'un dialogue en réponse à une proposition
transmise par un message ACT, RAP, REV ou RRV, ou
bien du début d'un dialogue en vue de modifier les condi-
tions de transfert précédemment agréées.
8.8.3.1.3. La référence du message ne doit figurer que lorsque le message
CDN est envoyé en réponse à un autre message.
8.8.3.1.4. La référence du message, lorsqu'elle est indiquée, doit
comprendre le numéro du message auquel le CDN répond.
8.8.3.1.5. Le service de demande d'acheminement direct (dont un descriptif
détaillé figure en Annexe A):
— ne doit être utilisé que si son emploi a fait l'objet d'un accord
bilatéral;
— si tel est le cas, les limites opérationnelles à son emploi
doivent être définies.
8.8.3.1.6. Le message CDN ne doit pas être envoyé au-delà d'un délai ou
d'une distance par rapport à la limite, dont la valeur est précisée
dans la Lettre d'accord entre les organismes intéressés.
8.8.3.1.7. Si unCDN se trouve tran smis enmême temps qu'unmessage du
centre transférant concernant le même vol, par exemple dans le
cas d'une révision ou d'une abrogation de coordination, aucun
accusé de réception ni réponse opérationnelle ne doit être envoyé
enretour.
NOTECela signifie que si deux messages se croisent, celui de
l'organisme transférant a priorité et le CDN est aban-
donné par les deux parties. Les deux organismes peuvent
pressentir une telle situation s'ils reçoivent le message de
l'autre avant d'avoir reçu l'accusé de réception.
8.8.3.1.8. Dès réception de l'acceptation, les données du message CDN
deviennent contraignantes sur le plan opérationnel pour les deux
organismes ATC. Le personnel ATC concerné doit être informé
des conditions de transfert coordonnées et de la réception de
l'ACP.
8.8.3.2. Traitement par l'Organisme recevant8.8.3.2.1. Si le système trouve un plan de vol correspondant et que le
message ne présente aucune anomalie susceptible d'empêcher
qu'il ne soit traité correctement:
— le contenu opérationnel du message doit être soumise au poste
ATC responsable de la coordination du vol;
— unmessage SBY doit être en voyé enretour.
8.8.3.2.2. Si le CDN ne peut être associé ou si une anomalie est constatée
qui empêche que le message ne soit traité correctement, aucun
SBY ne doit être envoyé en retour.
8.8.4. Accusé de réception du CDN
8.8.4.1. Accusé de réception
Dans les conditions précisées plus haut, il doit être accusé récep-
tiond'unmessage CDN par la productionet la tran smissiond'un
message SBY.
8.8.4.2. Absence d'accusé de réception
En l'absence de message SBY accusant réception d'un message
CDN, un avertissement doit s'afficher au poste ATC responsable
de la coordination du vol.2000R2082 — FR — 15.06.2002 — 001.001 — 50
▼B
8.8.5. Réponse opérationnelle au CDN
Le contrôleur peut soit accepter, soit rejeter les conditions propo-
sées dans un message CDN.
8.8.5.1. Acceptation
Lorsque le contrôleur transférant choisit d'accepter les conditions
de transfert proposées, un message ACP doit être envoyé en
retour.
8.8.5.2. Recommandation Lorsque le contrôleur transférant choisit de
rejeter les conditions de transfert proposées, il convient qu'un
message RJC (rejet explicite) soit envoyé.
NOTELa coordination proposée est implicitement rejetée si
aucune acceptation n'a été reçue lorsque la temps imparti
arrive à expiration.
8.8.6. Exemples
8.8.6.1. OACI
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A
8.9. Message de rejet de coordination (RJC)
8.9.1. Objet du message RJC
Le message RJC indique qu'un contrôleur d'un organisme donné a
rejeté les conditions de transfert proposées par le contrôleur de
l'autre organisme dans l'un des messages suivants:
— RAP;
— RRV;— CDN;— ACT et REV, si l'un ou l'autre est jugé non standard.
Le message RJC ne peut être utilisé qu'en réponse directe à l'un
des messages ci-dessus.
8.9.2. Composition du message
Le message RJC doit comprendre les éléments suivants:
— type de message;
— numéro du message;
— référence du message.
NOTELes règles d'introduction des données ainsi que les
formats et la teneur des champs sont précisés à
l'Annexe A.
8.9.3. Règles d'application
8.9.3.1. Généralités8.9.3.1.1. Le RJC doit être envoyé, suivant les besoins, en réponse à un
message RAP, RRV, CDN, ou à unmessage ACT ou REV jugé
non standard par l'organisme acceptant.
8.9.3.1.2. Le message RJC met finau dialogue système et toute coordin a-
tionagréée auparavan t demeure valable.
8.9.3.1.3. Recommandation Dès réception d'un message RJC, il convient
qu'une nouvelle séquence de coordination soit engagée, tenant
compte le cas échéant de la coordination par téléphone.
8.9.3.2. Traitement par l'organisme recevant8.9.3.2.1. Si le système trouve un message correspondant au message
auquel le RJC fait référence:
— le rejet doit être indiqué au poste ATC responsable de la coor-
dination du vol en question;
— unLAM doit être en voyé enretour, à titre d'accusé de récep-
tion.2000R2082 — FR — 15.06.2002 — 001.001 — 51
▼B
8.9.3.2.2. Si le système ne trouve aucun message de ce type en attente de
réponse ou que le message présente une anomalie qui ne permet
pas de le traiter, aucun accusé de réception ne doit être envoyé.
8.9.4. Accusé de réception du RJC
8.9.4.1. Accusé de réception
Il doit être accusé réceptiond'unmessage RJC par la production
et la transmission d'un message LAM.
8.9.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
RJC, un avertissement doit s'afficher au poste ATC responsable
de la coordination des vols.
8.9.5. Exemples
8.9.5.1. OACI
(RJCMC/E746E/MC324)
8.9.5.2. ADEXP
-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E
-SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC
MC -SEQNUM 324
9. PROCÉDURE DE DIALOGUE — TRANSFERT DE
COMMUNICATION
9.1. Généralités
9.1.1. Introduction
9.1.1.1. La présente section traite des services et messages à l'appui des
éléments radar de la procédure de transfert de contrôle. Les
dispositions doivent être appliquées lorsqu'elles ont fait l'objet
d'unaccord bilatéral.
9.1.1.2. Les mécanismes de transfert de communication ne doivent pas
être mis en oeuvre si l'organisme n'utilise pas, soit les méca-
nismes de coordination décrits à la Section 6 (Procédure de base
— Messages obligatoires), soit ceux de la Section8 (Procédure
de dialogue — Coordination).
9.1.1.3. Les messages décrits dans cette section ne sont disponibles que
dans le format ADEXP et il n'est pas prévu de les rendre disponi-
bles enformat OACI.
9.1.2. Séquence de messages
9.1.2.1. L'échange de messages de transfert de communication, en dehors
du message de données supplémentaires (SDM), ne doit avoir lieu
qu'une fois la coordination achevée, c'est-à-dire qu'un message
LAM ou ACP a mis unterme à undialogue ACT ou RAP.
9.1.2.2. Aucun accusé de réception ne doit être renvoyé tant que la coor-
dination est en cours.
9.1.3. Transfert de communications
9.1.3.1. Les deux organismes intéressés doivent convenir ensemble de la
méthode de notification du transfert réel des communications
pour un vol donné.
9.1.3.2. L'une des conditions suivantes ou les deux doivent être réunies:
— l'organisme transférant envoie un message de changement de
fréquence (COF);
— l'organisme acceptant envoie un message de prise en charge
manuelle des communications (MAS);
9.1.3.3. Les deux organismes doivent s'entendre sur la méthode à appli-
quer pour chaque courant de trafic.
NOTED'autres méthodes peuvent être appliquées pour différents
courants de trafic, par exemple un organisme peut
produire des messages COF pour les vols quittant son
espace aérien et des messages MAS pour ceux qui y
entrent. Dans ce cas, l'autre organisme n'aurait pas
besoin d'introduire de message pour signifier le transfert
de communications.2000R2082 — FR — 15.06.2002 — 001.001 — 52
▼B
9.2. Message de déclenchement de transfert (TIM)
9.2.1. Objet du message TIM
Le message TIM a pour objet:
— de signifier l'événement déclenchant le transfert (TI) (fin de la
phase de coordination et début de la phase de transfert);
— de transmettre simultanément les données de contrôle exécutif
de l'organisme transférant à l'organisme acceptant.
9.2.2. Composition du message
Le message TIM doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;
— identification de l'aéronef;
— Données disponibles, le cas échéant:
— niveau de vol autorisé;
— cap assigné ou autorisation d'acheminement direct;
— vitesse assignée;
— vitesse ascensionnelle ou descensionnelle autorisée;
— Données facultatives:
— position.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.2.3. Règles d'application
9.2.3.1. Généralités
9.2.3.1.1. Le message TIM doit être produit et transmis par l'organisme
transférant à l'organisme acceptant sans intervention humaine à
une distance ou dans un délai par rapport à la limite dont la
valeur est fixée bilatéralement.
9.2.3.1.2. Un message TIM doit aussi être envoyé automatiquement lorsque
l'organisme transférant reçoit un message de demande de change-
ment de fréquence (ROF).
9.2.3.1.3. Un message TIM ne doit pas être envoyé avant que le vol n'ait
été coordonné.
9.2.3.1.4. Le message TIM doit comprendre les données les plus récentes
dont le système dispose.
9.2.3.2. Paramètre de temps applicable à la transmission
9.2.3.2.1. Le paramètre de productiondu TIM doit être variable et pouvoir
être modifié sur la base des dispositions de la lettre d'accord.
9.2.3.2.2. Recommandation Il convient que le paramètre système de
production du message TIM soit défini séparément pour chaque
COP.
9.2.3.2.3. Les partenaires de la coordination doivent inclure le paramètre de
productiondu TIM dan s leur lettre d'accord.
9.2.3.2.4. Le paramètre système déclenchant le message TIM peut être lié à
la vitesse au sol de l'aéronef telle qu'elle est calculée. Toutefois,
le message TIM doit toujours être initié avant que l'aéronef, selon
le plan de vol en vigueur, n'atteigne une certaine distance du
COP, d'une valeur minimale convenue bilatéralement.
9.2.3.2.5. Le paramètre système spécifié pour la transmission du TIM doit
laisser suffisamment de temps pour qu'une coordination verbale
ait lieu avant le transfert.
9.2.3.3. Traitement par l'organisme recevant
9.2.3.3.1. Les données reçues dans un message TIM doivent être communi-
quées au contrôleur acceptant.2000R2082 — FR — 15.06.2002 — 001.001 — 53
▼B
9.2.4. Accusé de réception du TIM
9.2.4.1. Accusé de réception
Si le message TIM:
— peut être associé, sans ambiguïté, à un plan de vol, le système
doit enaccuser réceptionpar la productionet la tran smission
d'unmessage LAM;
— ne peut être associé, sans ambiguïté, à un plan de vol, aucun
accusé de réception ne doit être envoyé.
9.2.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
TIM, un avertissement doit s'afficher au poste de travail concerné.
9.2.5. Exemple
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM253
9.3. Message de données supplémentaires (SDM)
9.3.1. Objet du message SDM
9.3.1.1. Généralités9.3.1.1.1. Le message SDM a pour principal objet la transmission, par
l'organisme transférant à l'organisme acceptant, des données de
contrôle et des changement qui y sont apportés; à condition qu'il
ait été convenu bilatéralement que le contrôleur acceptant n'a pas
besoin d'accuser réception des changements.
9.3.1.1.2. Le message SDM peut également être utilisé par l'organisme
acceptant pour notifier à l'organisme transférant la fréquence
radiotéléphonique sur laquelle le vol doit être transféré.
9.3.2. Composition du message
9.3.2.1. Message de l'organisme transférant
Le message SDM doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;— identification de l'aéronef;
— Données supplémentaires:
— cap assigné ou autorisation d'acheminement direct;
— vitesse assignée;
— vitesse ascensionnelle ou descensionnelle autorisée;— niveau de vol autorisé;
9.3.2.2. Message de l'organisme acceptant
Le message SDM doit comprendre les éléments suivants:
— type de message;
— numéro du message;— identification de l'aéronef;— fréquence.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.3.3. Règles d'application
9.3.3.1. Message de l'organisme transférant9.3.3.1.1. Les messages SDM doivent être transmis après engagement de la
phase de transfert (voir TIM, paragraphe 9.2) lorsque l'un des
éléments ci-après est modifié:
— niveau de vol autorisé;
— vitesse assignée;
— vitesse ascensionnelle ou descensionnelle autorisée;
— cap assigné;— autorisation ou changement d'autorisation permettant au vol
de se rendre directement vers un point spécifié.2000R2082 — FR — 15.06.2002 — 001.001 — 54
▼B
NOTELe message HOP doit être utilisé lorsque l'approbation
du contrôleur acceptant est nécessaire avant le transfert
de communication.
9.3.3.1.2. Le message ne doit comporter que les champs qui ont été modi-
fiés.
9.3.3.1.3. Les messages SDM contenant les données décrites à l'alinéa
9.3.3.1.1 doivent être transmis avant le TI, s'il en a été convenu
ainsi bilatéralement.
9.3.3.1.4. La transmission de ces messages doit commencer à un moment
arrêté bilatéralement par rapport au TI, à condition qu'il s'agisse
de données pour lesquelles le système dispose d'une valeur.
9.3.3.2. Messages de l'organisme acceptant
9.3.3.2.1. Des messages SDM peuvent être transmis pour indiquer la
fréquence sur laquelle le vol doit contacter l'organisme acceptant.
NOTELes organismes peuvent convenir entre eux de s'échanger
d'autres informations. Ces transferts n'étant pas définis,
ils n'entrent pas dans le cadre de la présente Norme.
9.3.3.2.2. Les messages SDM de l'organisme acceptant doivent être
transmis pendant la phase de coordination, s'il en a été convenu
ainsi bilatéralement.
9.3.3.3. Traitement par l'organisme recevant
9.3.3.3.1. Le système ATC qui reçoit unmessage SDM doit ten ter de
l'associer au plan de vol correspondant.
9.3.3.3.2. Si un plan de vol correspondant en état «coordonné» est trouvé:
— unLAM doit être en voyé enretour;
— la teneur opérationnelle du message SDM doit être communi-
quée au contrôleur compétent.
9.3.3.3.3. Si un plan de vol correspondant ne peut être trouvé ou s'il existe
une anomalie empêchant que le message ne soit traité correcte-
ment:
— aucun message LAM ne doit être envoyé en retour;
— un avertissement doit être donné au poste de travail concerné.
9.3.4. Accusé de réception du SDM
9.3.4.1. Accusé de réception
Il doit être accusé réceptiond'unmessage SDM par la production
et la transmission d'un message LAM.
9.3.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
SDM, unavertissemen t doit s'afficher au poste de travail
concerné.
9.3.5. Exemple
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4. Proposition de transfert de vol (HOP)
9.4.1. Objet du message HOP
L'objet du message HOP est le suivant:
— permettre au contrôleur transférant d'appeler l'attention du
contrôleur acceptant sur un vol donné à des fins de transfert;
— permettre au contrôleur transférant de proposer le transfert du
vol au contrôleur acceptant au moment opportun;
— transmettre les données de contrôle exécutif qui doivent être
approuvées par le contrôleur acceptant, suivant les modalités
convenues bilatéralement.
Il n'est pas nécessaire d'utiliser le message HOP pour tous les
vols, l'emploi en étant laissé à la discrétion du contrôleur transfé-
rant.
NOTEEn ce qui concerne l'alinéa c) ci-dessus, le SDM sert à
transmettre les modifications apportées aux données de2000R2082 — FR — 15.06.2002 — 001.001 — 55
▼B
contrôle exécutif qui ne nécessitent pas l'approbation du
contrôleur acceptant.
9.4.2. Composition du message
Le message HOP doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;— identification de l'aéronef;
— Données disponibles — le message doit aussi contenir les
données suivantes, si disponibles:
— niveau de vol autorisé;
— cap assigné / autorisation d'acheminement direct;— vitesse assignée;— vitesse ascensionnelle ou descensionnelle autorisée;
— Données facultatives — le message peut aussi inclure:
— position.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.4.3. Règles d'application
9.4.3.1. Généralités9.4.3.1.1. Le message HOP, lorsqu'il est utilisé, doit être déclenché manuel-
lement par le contrôleur transférant.
9.4.3.1.2. Le message HOP doit inclure toutes les données de vol décrites à
l'alinéa 9.4.2 ci-dessus qui ont été modifiées par rapport aux
informations précédemment transmises.
9.4.3.1.3. Si un message HOP est envoyé avant le TI, la phase de transfert
doit être engagée.
NOTEUn message TIM n'est pas nécessaire, en plus d'un
message HOP.
9.4.3.1.4. Les organismes doivent convenir entre eux du moment (calculé
entemps ou endistan ce par rapport au COP ou à la limite) à
partir duquel unCOP peut être en voyé, au plus tôt.
9.4.3.1.5. Recommandation Il convient de spécifier le délai/la distance
séparément pour chaque COP.
9.4.3.2. Traitement par l'organisme recevant9.4.3.2.1. Le système ATC qui reçoit unmessage HOP doit ten ter d'associer
le message avec le plan de vol correspondant.
9.4.3.2.2. Les données de vol reçues dans le message doivent s'afficher
immédiatement sur l'écran du contrôleur acceptant.
9.4.3.2.3. Si le contrôleur acceptant décide d'accepter le vol selon les condi-
tions proposées dans le message HOP, un message ROF peut être
envoyé en réponse à l'organisme transférant. Un ACP peut être
envoyé en réponse à un HOP sous réserve d'accord bilatéral.
9.4.3.2.4. Si le contrôleur acceptant n'est pas en mesure d'accepter le vol, le
transfert doit faire l'objet d'un accord verbal.
NOTEEn raison de l'urgence de la procédure de transfert, un
suivi automatisé du renvoi du ROF ( ou de l'ACP) n'est
pas requis par la présente Norme; on suppose que le
contrôleur transférant constatera l'absence de réponse de
la part du contrôleur acceptant et prendra les mesures
nécessaires. Toutefois, rien n'empêche que le contrôleur
transférant en soit averti, si cela est nécessaire sur le
plan opérationnel.
9.4.3.2.5. Dès réception d'un ROF (ou d'un ACP), les données du message
HOP doivent avoir valeur contraignante sur le plan opérationnel
pour les deux organismes ATC.2000R2082 — FR — 15.06.2002 — 001.001 — 56
▼B
9.4.4. Accusé de réception du HOP
9.4.4.1. Accusé de réception
Si le message HOP peut être associé à unplande vol, il doit faire
l'objet d'unaccusé de réceptionautomatique par unLAM.
9.4.4.2. Absence d'accusé de réception
En l'absence de LAM accusant réception d'un message HOP, un
avertissement doit s'afficher au poste de travail compétent.
9.4.5. Exemple
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ
9.5. Message de demande de changement de fréquence (ROF)
9.5.1. Objet du message ROF
Le message ROF est envoyé par l'organisme acceptant à l'orga-
nisme transférant pour demander, suivant les besoins, au
contrôleur transférant d'inviter l'aéronef à passer sur la fréquence
du contrôleur acceptant. Il peut être utilisé:
— en réponse à un message HOP, pour signifier l'acceptation du
vol dans les conditions proposées;
— pour solliciter le transfert anticipé du vol.
9.5.2. Composition du message
Le message ROF doit comprendre les éléments suivants:
— Données obligatoires:
— type de message;
— numéro du message;
— identification de l'aéronef;
— Données facultatives:
— fréquence.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.5.3. Règles d'application
9.5.3.1. Généralités
9.5.3.1.1. Le message ROF doit être déclenché manuellement par le
contrôleur acceptant.
9.5.3.1.2. Le contrôleur acceptant peut déclencher un ROF, soit:
— lorsque le contrôleur acceptant demande le passage anticipé
de l'aéronef sur sa fréquence;
— enrépon se à unmessage HOP.
9.5.3.2. Traitement par l'organisme recevant9.5.3.2.1. Le système ATC qui reçoit unmessage ROF doit ten ter de l'asso-
cier avec le plan de vol correspondant.
9.5.3.2.2. La réception du ROF doit être signalée au contrôleur transférant
sans retard.
9.5.3.2.3. Si le vol n'est pas en phase de transfert, celle-ci doit être déclen-
chée et unmessage TIM doit être tran smis.
9.5.4. Accusé de réception du ROF
9.5.4.1. Accusé de réception
9.5.4.1.1. Si le message ROF peut être associé, sans ambiguïté, avec un
plande vol, le système doit enaccuser réceptionpar la produc-
tionet la tran smissiond'unmessage LAM.
9.5.4.1.2. Si le message ROF ne peut être associé, sans ambiguïté, avec un
plan de vol, aucun accusé de réception ne doit être envoyé.
9.5.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
ROF, un avertissement doit s'afficher au poste ATC compétent.2000R2082 — FR — 15.06.2002 — 001.001 — 57
▼B
9.5.5. Exemple
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6. Message de changement de fréquence (COF)
9.6.1. Objet du message COF
9.6.1.1. Généralités
9.6.1.1.1. Le COF est envoyé par l'organisme transférant à l'organisme
acceptant pour indiquer que le vol a reçu pour instructions de
contacter le contrôleur acceptant.
9.6.1.1.2. Le message peut prévoir la possibilité pour le contrôleur transfé-
rant de libérer le vol des conditions de transfert agréées lorsqu'il a
établi la radiocommunication avec le contrôleur acceptant.
9.6.2. Composition du message
Le message COF doit comprendre les éléments suivants:
— Données obligatoires:
— type du message;
— numéro de message;
— identification de l'aéronef;
— Données éventuellement disponibles:
— indication de transfert anticipé;
— fréquence;
— niveau de vol autorisé;
— cap assigné ou autorisation d'acheminement direct;
— vitesse assignée;
— vitesse ascensionnelle ou descensionnelle autorisée;
— Données facultatives:
— position.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.6.3. Règles d'application
9.6.3.1. Généralités9.6.3.1.1. Le message COF doit être déclenché manuellement par le
contrôleur acceptant.
9.6.3.1.2. L'utilisationdu message COF est obligatoire si, par accord bila-
téral, le message MAS n'est pas employé.
9.6.3.1.3. Si un message COF est envoyé avant le TI, la phase de transfert
doit être engagée.
NOTEUn message TIM n'est pas nécessaire, en plus du message
COF.
9.6.3.2. Traitement par l'organisme recevant
9.6.3.2.1. Le système ATC qui reçoit unmessage COF doit ten ter de l'asso-
cier avec le plan de vol correspondant.
9.6.3.2.2. La réception du COF doit être signalée au contrôleur acceptant
sans retard.
9.6.4. Accusé de réception du COF
9.6.4.1. Accusé de réception9.6.4.1.1. Si le message COF peut être associé, sans ambiguïté, avec un
plande vol, le système doit enaccuser réceptionpar la produc-
tionet de la tran smissiond'unmessage LAM.
9.6.4.1.2. Si le message COF ne peut être associé, sans ambiguïté, avec un
plan de vol, aucun accusé de réception ne doit être envoyé.
9.6.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
COF, unavertissemen t doit s'afficher au poste de travail ATC
compétent.2000R2082 — FR — 15.06.2002 — 001.001 — 58
▼B
9.6.5. Exemples
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7. Message de prise en charge manuelle des communications
(MAS)
9.7.1. Objet du message MAS
Le message MAS est envoyé par l'organisme acceptant à l'orga-
nisme transférant pour indiquer que le contact radio
bidirectionnel a été établi avec le vol.
9.7.2. Composition du message
Le message MAS doit comprendre les éléments suivants:
— type de message;
— numéro de message;— identification de l'aéronef.
NOTELes règles d'introduction des données ainsi que les
formats et le contenu des champs sont précisés à l'Annexe
A.
9.7.3. Règles d'application
9.7.3.1. Généralités9.7.3.1.1. Le message MAS doit être déclenché manuellement par le
contrôleur acceptant.
9.7.3.1.2. L'utilisationdu message MAS est obligatoire si, par accord bila-
téral, le message COF n'est pas employé.
9.7.3.2. Traitement par l'organisme recevant9.7.3.2.1. Le système ATC qui reçoit unmessage MAS doit ten ter de
l'associer avec le plan de vol correspondant.
9.7.3.2.2. Le contrôleur doit être informé immédiatement de la réception du
MAS.
9.7.4. Accusé de réception des MAS
9.7.4.1. Accusé de réception
9.7.4.1.1. Si le message MAS peut être associé, sans ambiguïté, avec un
plande vol, le système doit enaccuser réceptionpar la produc-
tionet la tran smissiond'unmessage LAM.
9.7.4.1.2. Si le message MAS ne peut être associé, sans ambiguïté, avec un
plan de vol, aucun accusé de réception ne doit être envoyé.
9.7.4.2. Absence d'accusé de réception
En l'absence de message LAM accusant réception d'un message
MAS, unavertissemen t doit s'afficher au poste de travail ATC
compétent, selon les besoins.
9.7.5. Exemple
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — FR — 15.06.2002 — 001.001 — 59
▼B
ANNEXE A (Normative)
RÈGLES D'INTRODUCTIONDES DONNÉES
TABLE DES MATIÈRES
A.1. Objet
A.2. Formats génériques de messageA.3. Type de message
A.4. Numéro du message
A.5. Référence du messageA.6. Identification de l'aéronef
A.7. Mode et code SSR
A.8. Aérodrome de départA.9. Données estimées
A.10. Point de coordination
A.11. Aérodrome de destinationA.12. Nombre d'aéronefs et type
A.13. Route
A.14. Autres données de plan de volA.15. Etat de coordination et motif
A.16. Cap assigné (ADEXP uniquement)
A.17. Vitesse assignée (ADEXP uniquement)A.18. Vitesse ascensionnelle/descensionnelle assignée (ADEXP unique-
ment)
A.19. Autorisation d'acheminement direct (ADEXP uniquement)A.20. Demande d'acheminement direct
A.21. Position (ADEXP uniquement)
A.22. Indication de transfert anticipé (ADEXP uniquement)A.23. Fréquence
A.24. Motif (ADEXP uniquement)
A.25. Niveau de vol autorisé (ADEXP uniquement)A.26. Niveau de transfert de contrôle (ADEXP uniquement)
A.27. Heure estimée de décollage
A.28. Type du message de référence
A.29. Type de vol
A.30. Aptitude et état des équipements
A.1.Objet
La présente Annexe décrit les règles générales d'introduction des
données dans les messages qui sont définis dans la présente Norme.
Ces règles s'appliquent à tous les messages, sauf lorsque d'autres
formules ou des exceptions sont expressément indiquées dans les
règles d'application d'un message donné.
A.2.Formats génériques de message
A.2.1. Tous les messages décrits dans les sections ci-après peuvent être
transmis suivant le format de l'OACI:
6 Procédure de base — Messages obligatoires;
7 Procédure de base — Messages complémentaires;8 Procédure de dialogue — Coordination.2000R2082 — FR — 15.06.2002 — 001.001 — 60
▼M1
▼B
▼B
A.2.2. Les formats de champ de message sont définis par l'OACI dans les
Procédures pour les services de la navigation aérienne — Règles de
l'air et services de la circulation aérienne (Document 4444). Les
types de champ OACI ci-après doivent, le cas échéant, être transmis
avant tout autre type de champ dans l'ordre suivant: 3, 7, 13, 14 et
16. Étant donné qu'ils sont au format de champ de type 22, les
autres types de champ OACI peuvent être transmis dans n'importe
quel ordre, pour autant qu'ils ne précèdent pas les types de champ
mentionnés ci-dessus.
A.2.2bisDans certains cas, un numéro factice de type de champ OACI est
utilisé lorsqu'il n'existe pas de champ OACI approprié. Ces numéros
contiennent des nombres de deux chiffres égaux ou supérieurs à 80.
A.2.3. Tous les messages décrits dans le présent document peuvent être
transmis selon le format ADEXP d'Eurocontrol. Le contenu, la
structure et les règles d'usage des champs de données ADEXP
doivent être conformes avec la Référence 2
NOTES
1.Seuls les champs de données primaires ADEXP sont mentionnés
dans la présente Annexe, excepté lorsque les sous-champs qui y
sont associés appellent des observations particulières. La Norme
ADEXP énumère tous les sous-champs facultatifs et obligatoires
qui dépendent de chaque champ primaire.
2.Les messages de la Section 9 — Procédure de dialogue — Trans-
fert de communication — sont uniquement décrits dans le format
ADEXP.
A.3.Type de message
Le type de message doit être l'abréviationdu message selonla liste
ci-après:
ABI: Préavis de franchissement de limite
ACP: Acceptation
ACT: Activation
CDN: Coordination
COD: Assignation de code SSR
COF: Changement de fréquence
HOP: Proposition de transfert de contrôle
INF: Information
LAM: Message d'accusé de réceptionlogique
MAC: Message d'abrogationde coordin ation
MAS: Prise en charge manuelle des communications
PAC: Activationprélimin aire
RAP: Propositiond'activationsoumise à accord
REV: Révision
RJC: Rejet de coordination
ROF: Demande de changement de fréquence
RRV: Propositionde révisionsoumise à accord
SBY: Attente de transfert
SDM: Message de données supplémentaires
TIM: Message de déclenchement de transfert
A.3.1. OACI
Champ de type 3, élément (a).
A.3.2. ADEXP
Champ primaire «title».
A.4.Numéro du message
Le numéro du message comprend les identificateurs des organismes
émettant et recevant ainsi que le numéro d'ordre du message. Ce2000R2082 — FR — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
dernier va de 001 à 000 (représentant 1000), puis reprend à 001,
pour tous les messages envoyés à un même destinataire, quel que
soit le type de message.
A.4.1. OACI
Champ de type 3, élément (b).
A.4.2. ADEXP
Champ primaire «refdata».Le sous-champ «fac», entrant dans les sous-champs «sender» et
«recvr», doit comprendre les identificateurs des organismes ATC,
dont la longueur ne doit pas dépasser huit caractères.
Le sous-champ «seqnum» doit comprendre le numéro de série.
A.5.Référence du message
A.5.1. OACI
Champ de type 3, élément (c) (appelé «données de référence» dans
le document 4444 de l'OACI).
Le contenu de l'élément (c) doit être celui de l'élément (b) du champ
de type 3 du message OLDI auquel il est fait référence.
A.5.2. ADEXP
Champ primaire «msgref».Les valeurs des sous-champs «sender», «recvr» et «seqnum», à
l'intérieur du champ primaire «msgref», doivent être celles des
mêmes sous-champs dépendant du champ primaire «refdata» du
message OLDI auquel il est fait référence.
A.6.Identification de l'aéronef
A.6.1. OACI
Champ de type 7, élément (a).
A.6.2. ADEXP
Champ primaire «arcid».
A.7.Mode et Code SSR
1. S'il est connu, le mode/code SSR sur lequel l'organisme recevant
peut escompter une réponse de l'aéronef au point de transfert de
contrôle;
2. Si non une indication selon laquelle le code SSR a été demandé
par l'organisme recevant.
A.7.1. OACI
Champ de type 7, éléments (b) et (c).Si aucun code SSR n'est assigné ou si le mode/code n'est pas connu,
les éléments (b) et (c) doivent être omis.
Lorsqu'un code/mode SSR est demandé, les éléments b) et c)
doivent contenir la valeur «A9999».
A.7.2. ADEXP
Champ primaire «ssrcode».Si aucun code SSR valide n'est assigné ou si le mode/code n'est pas
connu, le champ doit être omis.
Encas de deman de de code/mode SSR via le message PAC, le
champ primaire «ssrcode» doit contenir l'indicateur «REQ».2000R2082 — FR — 15.06.2002 — 001.001 — 62
▼B
A.8.Aérodrome de départ
A.8.1. OACI
Champ de type 13, élément (a).
A.8.2. ADEXP
Champ primaire «adep».
A.9.Données estimées
A.9.1. Généralités
A.9.1.1. Les données estimées doivent comprendre le COP, l'heure au COP
et le niveau de transfert.
A.9.1.2. Le point de coordination doit être défini, soit en tant que point de
référence connu, soit en distance et en relèvement par rapport à un
point de référence connu, soit en latitude et en longitude.
A.9.1.3. Le niveau autorisé (de transfert) doit correspondre aux conditions de
transfert proposées.
A.9.1.4.Recommandation Pour les vols en montée ou en descente, il
convient que les données estimées comprennent également des
données de croisement supplémentaires ainsi que les conditions de
croisement.
A.9.1.5. Les données de croisement supplémentaires, lorsqu'elles sont indi-
quées, doivent comprendre le niveau supplémentaire de croisement
au point de transfert de contrôle. Les conditions de croisement
doivent être indiquées comme suit:
— Lettre «A», — si le vol se situera au niveau ou au-dessus du
niveau indiqué dans les données de croisement supplémentaires;
— Lettre «B», — si le vol se situera au niveau ou en dessous du
niveau indiqué dans les données de croisement supplémentaires.
A.9.2. OACI
Champ de type 14.
A.9.3. ADEXP
Champ primaire «coordata».Le sous-champ «ptid» à l'intérieur du champ primaire «coordata»
doit comprendre:
— soit un point de référence connu;
— soit une distance et un relèvement par rapport à un point de réfé-
rence connu, tel qu'il est défini dans le champ primaire «REF»
or «GEO» du même message.
A.10.Point de coordination
A.10.1. Généralités
A.10.1.1. Le point de coordination mentionné par les organismes ATC trans-
férant et acceptant pour les besoins du transfert de contrôle en
question.
A.10.1.2. Le point de coordination doit être défini soit en tant que point de
référence connu, soit en distance et en relèvement par rapport à un
point de référence connu, soit en latitude et en longitude.
A.10.2. OACI
Champ 14, élément (a).
A.10.3. ADEXP
Champ primaire «cop» contenant:
— soit un point de référence connu;
— soit un relèvement et une distance par rapport à un point de réfé-
rence connu, tel qu'il est défini dans le champ primaire «REF»
ou «GEO».2000R2082 — FR — 15.06.2002 — 001.001 — 63
▼B
A.11.Aérodrome de destination
A.11.1. OACI
Champ 16, élément (a).
A.11.2. ADEXP
Champ primaire «ades».
A.12.Nombre d'aéronefs et type
Ce champ doit contenir le type d'aéronef, ainsi que le nombre
d'aéronefs lorsqu'il s'agit de vols en formation.
A.12.1. OACI
Champ de type 9 au format de champ de type 22. L'élément c du
champ de type 9 doit comprendre soit la catégorie de turbulence
de sillage correspondant au type d'aéronef, soit la lettre «Z».
A.12.2. ADEXP
Champ primaire «arctyp». S'il y a plusieurs aéronefs, ajouter le
champ primaire «nbarc».
A.13.Route
Les deux formats permettent la description de la route telle qu'elle
est définie pour les messages de l'OACI, qui impose en premier
élément la vitesse, le niveau de vol demandé ou l'altitude. Après le
groupe vitesse, les données relatives à la route doivent comprendre
au minimum les données spécifiées dans le paragraphe suivant.
D'autres données relatives à la route peuvent être incluses après
l'élément c), le cas échéant. Voir également les règles d'introduction
des données relatives aux routes à l'Annexe B «Prescriptions appli-
cables au traitement des acheminements particuliers»:
A.13.1. Teneur
A.13.1.1. Vols passant par un COP défini
— l'élément de la route avant le COP (route ATS, identificateur
SID, DCT ou point significatif);
— le COP;— l'élément de route après le COP (route ATS ou point signifi-
catif).
A.13.1.2. Vols s'écartant de la route ATS
— le point à partir duquel le vol suit le tronçon de route directe;
— l'élément «DCT»;
— le point vers lequel le vol se rend sur le tronçon de route directe.
A.13.2. Format
A.13.2.1. OACI
Champ de type 15 au format de champ de type 22.
A.13.2.2. ADEXP
Champ primaire «route».
A.14. Ce champ offre la possibilité d'inclure dans des messages particu-
liers des données du plan de vol qui ne sont normalement pas
comprises dans la procédure de coordination et qui ne sont pas
décrites ailleurs dans la présente annexe. Il est permis d'inclure les
points suivants comme indiqué dans le document de référence 1,
annexe 2, types de champs 8 et 18.
— Règles de vol
— Marques d'immatriculation— Nom de l'exploitant— Motif de traitement spécial par l'ATS2000R2082 — FR — 15.06.2002 — 001.001 — 64
▼M1
▼M1
— Type
— Performance— Nom des aérodromes de départ, de destination, et de dégage-
ment
— Remarques enlan gage clair.
A.14.1. OACI
Type de champ 8, élément a) «Règles de vol» dans le format de
champ de type 22.
Un ou plusieurs des éléments du type de champ 18 dans le format
de champ de type 22.
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Champs primaires: «fltrul», «depz», «destz», «opr», «per», «reg»,
«rmk», «altrnt1», «altrnt2», «sts», and «typz».
A.15.Statut et motif de la coordination
Le statut et le motif de la coordination doivent comprendre les
éléments suivants:
— un indicateur à trois lettres confirmant le nouveau statut du plan
de vol dans le système, parmi les suivants:
— INI, lorsque le plande vol dan s le système doit être enétat
initial, c'est-à-dire qu'aucun message de notification n'a été
reçu;
— NTF, lorsque le plande vol dan s le système doit être enétat
«avisé»;
— CRD, lorsque le plande vol dan s le système doit être enétat
«coordonné», c'est-à-dire que l'ACT de base a été reçu ou
que le dialogue de coordination initiale est achevé et que
les conditions sont agréées.
— un indicateur à trois lettres précisant le motif du statut, parmi les
suivants:
— TFL, si le motif est un changement de niveau de transfert;
— RTE, si le motif est un changement de route;— HLD, pour indiquer que le vol est en attente pour une durée
indéterminée et fera l'objet d'un nouveau message;
— DLY, pour indiquer que le départ est retardé;
— CAN, si le motif est une annulation;
— CSN, en cas de changement d'indicatif d'appel;— OTH, pour tout autre motif ou si le motif est inconnu.
A.15.1. OACI
A.15.1.1. L'état et le motif de la coordination doivent être mentionnés selon le
format de champ de type 18.
A.15.1.2. L'état et le motif de la coordination doivent inclure les éléments
suivants présentés sous forme de groupe de dix caractères:
— STA suivie d'une barre oblique;
— l'indicateur confirmant le nouveau statut de la notification/coor-
dination;
— l'indicateur précisant le motif.
A.15.2. ADEXP
Champ primaire «cstat».
Les éléments auxiliaires «coordstatusident» et «coordstatusreason»
doivent indiquer le nouveau statut et le motif, suivant les modalités
exposées ci-dessus.
A.16.Cap assigné (ADEXP uniquement)
Le champ primaire «ahead» doit comprendre:
— soit le cap assigné à un vol, exprimé en degrés;2000R2082 — FR — 15.06.2002 — 001.001 — 65
▼B
▼B
— soit, si aucun cap n'est assigné, l'indicateur «ZZZ», par exemple,
lorsqu'un message SDM est envoyé pour indiquer qu'un cap
assigné précédemment n'est plus applicable.
A.17.Vitesse assignée ( ADEXP uniquement )
Le champ primaire «aspeed» doit comprendre:
— soit la vitesse assignée à un vol, exprimée en nœuds, nombre de
mach ou kilomètres/heure;
— soit, si aucune vitesse n'est assignée, l'indicateur «ZZZ», par
exemple lorsqu'un message SDM sert à indiquer qu'une vitesse
assignée précédemment n'est plus applicable.
A.18.Vitesse ascensionnelle/descensionnelle assignée (ADEXP unique-
ment)
Le champ primaire «rate» doit comprendre:
— soit, la vitesse ascensionnelle/descensionnelle assignée, exprimée
en centaine de pieds par minute;
— soit, si aucune vitesse ascensionnelle/descensionnelle n'est assi-
gnée, l'indicateur «ZZZ» dans la partie numérique du champ,
par exemple lorsqu'un message SDM est envoyé pour indiquer
qu'une vitesse ascensionnelle/descensionnelle précédemment
assignée n'est plus applicable.
A.19.Autorisation d'acheminement direct (ADEXP uniquement)
Route directe, non définie comme route ATS, reliant deux points.
Les points peuvent être définis soit comme un point de référence
connu, soit comme une distance ou un relèvement par rapport à un
point de référence. Tous les désignateurs de points terminaux qui
seront utilisés doivent faire l'objet d'un accord bilatéral, c'est-à-dire
qu'ils doivent être connus des deux systèmes.
Champ primaire «DCT» comprenant:
— le point auquel l'écart a commencé ou commencera, défini
suivant l'une des méthodes suivantes:
— un point de référence connu;
— une distance ou un relèvement par rapport à un point de
référence connu, défini dans le même message par le champ
primaire «REF»;
— la valeur «ZZZ», si l'organisme émettant ne demande pas la
désignation du point où commence l'écart.
— le point situé sur la route initialement prévue dans le plan de vol
jusqu'auquel l'aéronef a été ou sera autorisé, défini selon l'une
des méthodes suivantes:
— un point de référence connu;
— une distance ou un relèvement par rapport à un point de
référence connu, défini dans le même message par le champ
primaire «REF».
A.20.Demande d'acheminement direct
Demande de route directe, non définie comme route ATS, reliant
deux points. Les points peuvent être définis soit comme un point
de référence connu, soit comme une distance ou un relèvement par
rapport à un point de référence.
Tous les désignateurs de points terminaux utilisés doivent faire
l'objet d'un accord bilatéral, c'est-à-dire qu'ils doivent être connusdes deux systèmes.
A.20.1. OACI
Champ de type 15, à l'exclusion du groupe vitesse/niveau initial, au
format de champ 22.
Il doit comprendre:
— le point à partir duquel il est demandé que le vol s'écarte de la
route prévue, défini selon l'une des méthodes suivantes:
— un point de référence connu;
— une distance ou un relèvement par rapport à un point de
référence;2000R2082 — FR — 15.06.2002 — 001.001 — 66
▼B
— la valeur «ZZZ», si l'organisme ATC recevant demande un
acheminement direct.
— l'abréviation«DCT»,— suivie par le point situé sur la route initialement prévue dans le
plan de vol, auquel l'aéronef demande l'autorisation, défini
comme:
— soit un point de référence connu;
— soit une distance et un relèvement par rapport à un point de
référence connu.
A.20.2. ADEXP
Le champ primaire «DCT» doit comprendre:
— le point auquel l'écart a commencé ou commencera, défini
suivant l'une des méthodes suivantes:
— un point de référence connu;
— une distance ou un relèvement par rapport à un point de
référence connu défini dans le même message par le champ
primaire «REF»;
— la valeur «ZZZ» si l'organisme recevant reçoit une demande
d'acheminement direct mais que le point de départ n'est pas
connu avec précision.
— le point situé sur la route initialement prévue dans le plan de
vol, auquel l'autorisation est demandée et qui est défini:
— soit comme un point de référence connu;
— soit comme une distance ou un relèvement par rapport à un
point de référence connu défini dans le même message par le
champ primaire «REF».
A.21.Position (ADEXP uniquement)
A.21.1. Généralités
A.21.1.1. La position actuelle du vol, exprimée soit par des coordonnées
géographiques, soit par un relèvement et une distance par rapport à
un point désigné.
A.21.1.2. Le champ primaire «ref» ou «geo» doit définir la position actuelle
de l'aéronef dans le plan horizontal. Les points utilisés pour l'indica-
tion des relèvement et distance dans le champ primaire «ref»
doivent faire l'objet d'un accord bilatéral, c'est-à-dire qu'ils doivent
être connus des deux systèmes. La «position» du champ primaire
doit comprendre le sous-champ «ptid» qui renvoie au point de réfé-
rence ou point géographique défini. Si des données de temps
doivent être incluses, le sous-champ «to» (hhmm) ou «sto»
(hhmmss) doit être employé, sous réserve d'accord bilatéral.
A.22.Indication de transfert anticipé (ADEXP uniquement)
Le champ primaire «transfert anticipé» doit comprendre l'un des
éléments suivants:
— C, s'il s'agit d'un transfert anticipé en montée;
— D, s'il s'agit d'un transfert anticipé en descente;— T, s'il s'agit d'un transfert anticipé en virage;— F, s'il s'agit d'un transfert anticipé total pour toutes situations.
A.23.Fréquence
A.23.1. OACI
Le champ de type 18 doit comprendre les éléments suivants au
format de champ de type 22:
— FRQ, suivi d'une barre oblique;
— 6 chiffres indiquant la fréquence, exprimée en MHz jusqu'à trois
décimales.
A.23.2. ADEXP
Champ primaire «freq».2000R2082 — FR — 15.06.2002 — 001.001 — 67
▼B
A.24.Motif(ADEXP uniquement)
Champ primaire «reason», comprenant la valeur «MANUAL» pour
les messages renvoyés manuellement.
A.25.Niveau de vol autorisé (ADEXP uniquement)
Champ primaire «cfl».
A.26.Niveau de vol proposé pour le transfert (ADEXP uniquement)
Champ primaire «propfl».
A.27.Heure estimée de décollage
A.27.1. OACI
Champ de type 13, élément (b).
A.27.2. ADEXP
Champ primaire «etot».
A.28.Type de message de référence
Le champ comprend le type de message spécifié au paragraphe A.1
de la présente Annexe.
A.28.1. OACI
Champ de type 18 au format de champ de type 22. L'indicateur
d'élément doit être «MSG».
A.28.2. ADEXP
Champ primaire «msgtyp».
A.29.Type de vol
Cette donnée doit être indiquée comme dans le plan de vol ou
correspondre à une donnée équivalente provenant d'une autre
source. Si le type de vol n'est pas indiqué dans le plan de vol, ou
s'il n'est pas connu pour une autre raison quelconque, cette rubrique
est remplie par l'insertion de la lettre «X».
A.29.1. OACI
Le type de vol doit être identifié par une seul lettre dans le format
de champ de type 22 en utilisant le numéro de type de champ
factice 80.
A.29.2. ADEXP
Champ primaire «flttyp»
A.30.Aptitude et état des équipements
Cette rubrique indique l'aptitude et l'état des équipements qui sont
requis pour des vols dans certains espaces aériens ou sur des routes
particulières, ou qui ont une incidence importante sur la fourniture
du service ATC. La présence d'une aptitude est signalée dans le
plan de vol, mais l'indication peut se révéler inexacte ou la situation
peut avoir changé en cours de vol. La rubrique «Aptitude et état des
équipements» spécifie l'état actuel des équipements.
L'état doit être indiqué pour les éléments suivants:
— aptitude pour vol enRVSM,
— équipement RTF 8,33kHz.
L'état de l'équipement suivant doit être mentionné pour les vols
d'État indiqués comme tels dans «Type de vol» pour lesquels on
ignore si un équipement RTF de 8,33 kHz peut être utilisé:
— équipement UHF.2000R2082 — FR — 15.06.2002 — 001.001 — 68
▼M1
▼M1
A.30.1. OACI
Les données doivent être introduites dans le format de champ de
type 22 en utilisant le numéro de champ factice 81.
Deux éléments doivent être introduits pour chaque aptitude:
— l'aptitude de l'équipement exprimée par une seul lettre comme
précisé dans le champ de type 10 «Équipements» du plan de
vol OACI (annexe 3 du document de référence 1), suivie immé-
diatement
— par unélémen t séparateur [barre oblique (/)], suivi immédiate-
ment
— par deux lettres indiquant l'état de l'équipement.
L'état est exprimé par les indicateurs suivants qui s'appliquent au
vol:
a) EQ signifie que l'aéronef est équipé et que l'équipement peut être
utilisé pendant le vol;
b) NO signifie que l'aéronef n'est pas équipé ou que pour l'une ou
l'autre raison l'équipement ne peut pas être utilisé pendant le vol;
c) UN signifiant qu'on ignore si les conditions d'aptitude sont
réunies.
Le premier groupe d'aptitude est inséré immédiatement après la
barre oblique suivant le numéro de champ. Les groupes suivants
sont séparés par une espace. L'ordre des aptitudes indiquées n'a pas
d'importance.
A.30.2. ADEXP
Champ primaire «EQCST».2000R2082 — FR — 15.06.2002 — 001.001 — 69
▼B
ANNEXE B (Normative)
PRESCRIPTIONS APPLICABLES AU TRAITEMENT DES ACHEMINE-
MENTS PARTICULIERS
B.1. Introduction
B.1.1. Généralités
B.1.1.1. La présente Annexe décrit les règles et prescriptions relatives à
l'introduction de données dans les circonstances suivantes, sous
réserve d'accord:
— un vol suit une trajectoire directe, hors route, et franchit la
limite en raison d'un segment de route directe figurant sur le
plande vol;
— après transmission du message ABI ou ACT, un vol est réache-
miné:
— soit via une route ATS différente;
— soit via une route directe de façon à rejoindre la route
initiale à un point ultérieur.
B.1.1.2. Pour ce qui concerne le réacheminement des vols (décrit à l'alinéa
B.1.1.1), les modalités d'échange de données décrites dans la
présente Annexe permettent de modifier la route indiquée pour le
vol dans les deux systèmes au moyen de messages de notification
et de coordination.
B.2. Application des messages
B.2.1. Règles de base applicables aux acheminements directs
B.2.1.1. Les conditions applicables à l'échange OLDI pour la coordination
des vols dans le cas d'acheminements directs doivent faire l'objet
d'unaccord bilatéral.
B.2.1.2. Les données requises pour la notification et la coordination de vols
en acheminement direct figurent aux rubriques point de coordina-
tion (données estimées (format OACI) et données de coordination
(ADEXP)) et route des messages applicables.
B.2.2. Route directe déposée
Lorsque la route indique que le vol franchira la limite sur une route
directe, le tronçon de route directe et le COP qui en résulte doivent
figurer dans le(s) message(s) ABI. Ce COP est inclus dans le
message ACT ou RAP ultérieur.
Le COP et les données relatives à la route doivent être présentés
selonle format décrit à l'alin éa B.3.2.
B.2.3. Réacheminement après transmission du message ABI et avant la
transmission de l'ACT
Un nouveau message ABI doit être envoyé avec les données corres-
pondant à la nouvelle route.
B.2.4. Réacheminement après transmission du message ACT
B.2.4.1. Un message REV doit être envoyé pour signaler les réachemine-
ments intervenant après transmission d'un message ACT, avant
l'expiration d'un délai, fixé bilatéralement, avant l'heure de survol
prévue du COP précédemment coordonné.
NOTEUn message REV est uniquement utilisé dans les cas où
l'organisme acceptant ne change pas. Si l'organisme
change, un message MAC doit être envoyé à l'organisme
acceptant initial ou la coordination verbale doit être
annulée.
B.2.4.2. Le message doit contenir les éléments de données suivants:
— point de coordination (COP précédent, à titre de référence);
— données estimées;
— route.2000R2082 — FR — 15.06.2002 — 001.001 — 70
▼B
B.2.4.3. Les messages établis selon le format OACI doivent comprendre les
champs suivants:
3 Type et numéro du message; références du message, sous
réserve d'accord bilatéral;
7 Identification de l'aéronef. Les éléments b et c ne doivent pas
être inclus, à moins qu'une révision du code SSR ne soit coor-
donnée en même temps;
13 Aérodrome de départ;14 Élément a uniquement, contenant le COP précédent à titre de
référence;
16 Destination;22 Champ 14 contenant les données estimées relatives aux
nouvelles conditions de franchissement de limite dans le
format de champ 22;
22 Champ 15 contenant les données relatives à la nouvelle route
dans le format de champ 22.
B.2.4.4. Les messages établis selon le format ADEXP doivent comprendre,
outre le type et le numéro du message, l'identification de l'aéronef,
l'aérodrome de départ et de destination et, sous réserve d'accord
bilatéral, le numéro de référence du message:
— le COP précédent dans le champ COP;
— les nouvelles conditions de coordination dans le champ COOR-
DATA;
— la nouvelle route dans le champ ROUTE.
B.2.4.5. Les révisions de route notifiées dans le cadre de la procédure de
dialogue doivent être envoyées sous forme de messages RRV, sauf
s'il a été convenu bilatéralement qu'il s'agissait de révisions «stan-dard».
B.3. Teneur des champs
B.3.1. Routes ATS
Pour les vols réacheminés via une route ATS de remplacement, les
champs relatifs aux données estimées et à la route sont présentés
selonles formats des messages ABI et ACT.
B.3.2. Routes directes
B.3.2.1. Le point de coordination dans les données estimées doit être le
point de franchissement de la limite exprimé en relèvement et
distance par rapport à un point de compte rendu. Ces points doivent
être agréés bilatéralement. Lorsque la distance est nulle ou si un vol
doit passer à distance de ce point dans une mesure agréée bilatéra-
lement, seul l'identificateur du point doit être mentionné.
B.3.2.2. Sous réserve d'accord bilatéral, le point de coordination pour un vol
sur une route directe peut être exprimé en longitude et latitude.
B.3.2.3. La route doit comprendre:
— le point sur la route d'origine à partir duquel l'aéronef doit être
acheminé directement; lorsque le vol est acheminé directement
à partir de la «position du moment», le point peut être exprimé
en relèvement et distance par rapport à un point de compte
rendu. Sous réserve d'accord bilatéral, le point peut être exprimé
par référence à la latitude et la longitude;
— l'abréviation«DCT»;
— le point vers lequel l'aéronef s'achemine directement;
— le dernier tronçon de la suite de la route du vol (FRF), si le
système le connaît.
B.4. Exemples
B.4.1. Routes directes
B.4.1.1. Messages ABI et ACT
B.4.1.1.1. Le vol (identification Jetset 253) doit franchir la limite sur une
route directe entre le Point A (PTA) et le Point C (PTC), après
quoi il suivra la route ATS UA134. Le système détermine un COP2000R2082 — FR — 15.06.2002 — 001.001 — 71
▼B
dont le relèvement est de 350 degrés par rapport au point B (PTB et
la distance de 22 NM dudit Point B (PTB).
Le message ABI suivant est envoyé:
— OACI
(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-
EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)
— ADEXP
-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L
-SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP
LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -
ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB
-BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT
PTC UA134
B.4.1.1.2. Le message ACT a le même format que le message ABI, si ce n'est
que la route à suivre est facultative.
B.4.1.2. Message REV
Le vol HZT2051 faisait précédemment l'objet du message ACT ci-
après (ou sonéquivalen t ADEXP):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
2000R2082 — FR — 15.06.2002 — 001.001 — 72
▼B
Le vol est ensuite acheminé directement au point MYY à partir de
40 NM à l'ouest du point RQA. Le point le plus proche de l'inter-
sectionde la limite est TDS à partir duquel la distan ce jusqu'au
point d'intersection réel est à la position 26 NM à 240 degrés. Le
message de révision suivant est envoyé:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
L'équivalent ADEXP du message est le suivant:
-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG
-SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -
ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310
-REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -
ROUTE N0458F310 RQA270040 DCT MYY
Unmessage de révisionultérieur in diquerait TDS240026 comme
COP.2000R2082 — FR — 15.06.2002 — 001.001 — 73
▼B
B.4.2. Réacheminement par des routes ATS après transmission de l'ACT
B.4.2.1. Message ACT
Le vol GKP217 est censé passer par le point de coordination EMT.
Le message ACT suivant est transmis:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
Le vol est ultérieurement réacheminé via la route ATS UM247 àl'intérieur de l'espace aérien du centre émettant vers un nouveau
point de coordination XAT, puis doit suivre la route ATS UJ124.
Le centre acceptant reste le même. Le message de révision suivant
est envoyé:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
2000R2082 — FR — 15.06.2002 — 001.001 — 74
▼B
Le vol est ensuite autorisé à passer au FL290, ce qui donne lieu au
message suivant (contenant le nouveau COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. Équivalents ADEXP
Les équivalents ADEXP des deux messages de révision sont les
suivants:
a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -
ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -
ROUTE N0430F290 UM247 XAT UJ124
b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA
-PTID XAT -TO 1225 -TFL F290 -ADES DTTA2000R2082 — FR — 15.06.2002 — 001.001 — 75
▼B
ANNEXE C (Informatif)
PHASES DE LA PROCÉDURE DE DIALOGUE (SYSCO NIVEAU 1) — SÉQUENCE DE
MESSAGES
Séquence de messages
2000R2082 — FR — 15.06.2002 — 001.001 — 76
▼B
ANNEXE II
PRÉSENTATION DE L'ÉCHANGE DE DONNÉES ATS (ADEXP),
ÉDITION 2.0
(document de référence Eurocontrol DPS.ET1.ST09-STD)2000R2082 — FR — 15.06.2002 — 001.001 — 77
▼B
TABLE DES MATIÈRES
AVERTISSEMENT/DROITS D'AUTEUR
AVANT-PROPOS1. CHAMP D'APPLICATION2. RÉFÉRENCES3. DÉFINITIONS, SYMBOLES, SIGLES ET ABRÉVIATIONS
3.1. Notation3.2. Définitions3.3. Construction3.4. Conventions3.5. Opérateurs3.6. Sigles et abréviations
4. PRINCIPES ADEXP
4.1. Texte à lecture directe4.2. Champs identifiés et récupérables4.3. Champs non identifiés
5. RÈGLES SYNTAXIQUES ADEXP
5.1. Éléments lexicaux5.2. Champs
6. DESCRIPTION NORMALISÉE DES MESSAGES ADEXP
6.1. Introduction6.2. Termes auxiliaires6.3. Définition des champs primaires6.4. Définition des sous-champs6.5. Groupes de messages
ANNEXE A (NORMATIVE) DÉFINITIONS DES CHAMPS ADEXP
ANNEXE B (NORMATIVE) INDEX CENTRAL DES INTITULÉS DE MESSAGE ADEXPANNEXE C (NORMATIVE) INDEX CENTRAL DES INTITULÉS DE MESSAGE RÉSERVÉSANNEXE D (NORMATIVE) INDEX CENTRAL DES CHAMPS RÉSERVÉSANNEXE E (INFORMATIVE) PRÉSENTATION DES GROUPES DE MESSAGESANNEXE F (INFORMATIVE) EXEMPLES DE FORMAT DE MESSAGE ADEXPANNEXE G (INFORMATIVE) DÉVELOPPEMENTS FUTURS2000R2082 — FR — 15.06.2002 — 001.001 — 78
▼B
AVERTISSEMENT/DROITSD'AUTEUR
Le présent document a été élaboré par l'Agence Eurocontrol, qui en détient
les droits d'auteur.
Le contenu du présent document est librement accessible, en tout ou en
partie, aux représentants des Etats membres, toute reproduction ou divulga-
tion à des tiers étant toutefois subordonnée à une autorisation écrite
préalable de l'Agence Eurocontrol.2000R2082 — FR — 15.06.2002 — 001.001 — 79
▼B
AVANT-PROPOS
1. Organe compétent
La présente Norme a été élaborée par la Section «Besoins des
utilisateurs» de l'Organisme central de gestion des courants de
trafic aérien (CFMU) de l'Organisation européenne pour la sécu-
rité de la navigation aérienne (Eurocontrol), qui en assure
également la mise à jour.
2. Programme de travail EATCHIP
La présente Norme constitue un produit du Programme de travail
EATCHIP (EWPD), Domaine — Systèmes informatiques de
l'ATM (DPS), Mission d'encadrement 09.
3. Approbation de la Norme
3.1. La présente Norme est adoptée conformément aux procédures
décrites dans les Directives pour les activités de normalisation
d'Eurocontrol, réf. 000-2-93, édition 1.0.
3.2. Les dispositions de la présente Norme ont pris effet suite à
l'adoption, en 1995, de l'édition 1.0 par la Commission perma-
nente d'Eurocontrol; elles entrent en application à compter du
1erdécembre 1997.
4. Rectificatifs techniques et amendements
La présente Norme fait l'objet d'un suivi aux fins d'y apporter les
rectificatifs techniques et amendements requis. La procédure de
mise à jour de la présente Norme est énoncée dans l'Annexe H
des Directives relatives à la rédactionet à la présen tation
uniformes des Normes Eurocontrol.
Les amendements ou ajouts touchant aux principes ou règles
grammaticales de base du format ADEXP sont soumis à la procé-
dure d'examenofficiel prévue dan s les Directives relatives à la
rédaction et à la présentation uniformes des Normes Eurocontrol.
Les propositions d'amendements ou d'ajouts à la présente Norme
doivent être adressées, par écrit, à la Section «Besoins des utilisa-
teurs» (ADEXP), CFMU, Agence Eurocontrol.
5. Conventions rédactionnelles
5.1. Le format de la présente Norme est conforme aux Directives rela-
tives à la rédaction et à la présentation uniformes des Normes
Eurocontrol; on relève toutefois certains écarts de formatage
mineurs par rapport aux dites Directives: ils sont destinés à
prévenir toute confusion avec la notation propre à l'ADEXP.
5.2. Pour indiquer le statut de chaque élément, il a été décidé
d'adopter les règles typographiques suivantes:
— les éléments normatifs se caractérisent par la forme verbale
«doit» ou «doivent» et sont imprimés en caractères ordinaires;
— les éléments recommandés se caractérisent par la forme
verbale «devrait» ou «devraient»; ils sont imprimés en carac-
tères italiques et précédés de la mention Recommandation .
6. Liens avec d'autres documents normatifs
La présente Norme est liée au document suivant:Norme Eurocontrol pour l'échange des données en ligne (OLDI).
7. Statut des annexes au présent document
La présente Norme comporte 7 annexes ayant respectivement le
statut suivant:
Annexe A Normative;
Annexe B Normative;Annexe C Normative;Annexe D Normative;Annexe E Informative;Annexe F Informative;2000R2082 — FR — 15.06.2002 — 001.001 — 80
▼B
Annexe G Informative.
8. Langue utilisée
Le texte original de la présente Norme a été rédigé en langue
anglaise.2000R2082 — FR — 15.06.2002 — 001.001 — 81
▼B
1. CHAMP D'APPLICATION
1.1. L'ADEXP est un format et non un protocole. Il n'impose aucune
restriction en ce qui concerne les supports ou les protocoles de
transmission à utiliser, hormis le jeu de caractères.
1.2. Le format ADEXP est principalement destiné à l'échange de
messages en ligne d'ordinateur à ordinateur.
1.3. Le présent document définit les principes et les règles syntaxiques
du format ADEXP, sous la forme d'une définition complète des
champs ADEXP.
1.4. Le format ADEXP a été spécifié pour l'échange de messages dans
les domaines suivants (pour les références documentaires, se
reporter à la Section2, page 3):
— Planification des vols: échange des données de plan de vol et
des messages associés entre le Système intégré de traitement
initial des plans de vol (IFPS), les Services de la circulation
aérienne (ATS) et les exploitants d'aéronefs (AO) (Document
réf. 3);
— Gestion des courants de trafic aérien (ATFM): échange de
messages entre le Système tactique (TACT) du CFMU, les
AO et l'ATS (Document réf. 5);
— Coordination du contrôle de la circulation aérienne: échange
de messages de coordination tactique entre organismes de
contrôle de la circulation aérienne (ATCU) (Document réf. 6);
— Gestion de l'espace aérien: échange de données entre les orga-
nismes ATS nationaux, le CFMU et les AO concernant les
disponibilités en matière d'espace aérien (Document réf. 7);
— Coordination civile-militaire: messages relatifs aux données
des vols civils et militaires et messages de traversée d'espace
aérien(Documen t réf. 7).
1.5. Les spécifications détaillées concernant l'utilisation et la teneur
des messages visés dans chacune des catégories précitées figurent
dans les documents cités en référence.
2. RÉFÉRENCES
2.1. Les documents et normes ci-après contiennent des dispositions
qui, par suite de la référence qui en est faite, constituent des
dispositions de la présente Norme Eurocontrol.
Les éditions indiquées sont celles qui étaient en vigueur au
moment de la publication de la présente Norme Eurocontrol.
Toute révision des documents de l'Organisation de l'aviation
civile internationale (OACI) mentionnés en référence doit être
immédiatement répercutée dans la présente Norme Eurocontrol.
Les révisions des autres documents cités en référence ne doivent
faire partie des dispositions de la présente Norme Eurocontrol que
lorsqu'elles auront fait l'objet d'un examen officiel et auront été
incluses dans la présente Norme Eurocontrol.
En cas de conflit entre les prescriptions de la présente Norme
Eurocontrol et la teneur des autres documents de référence, c'est
la présente Norme Eurocontrol qui doit être appliquée.
2.2. Les documents énumérés ci-après constituaient les ouvrages de
référence au moment de la publication de la présente Norme
Eurocontrol; les utilisateurs sont cependant invités à vérifier le
mode d'utilisationet les tableaux de compositiondes champs de
message dans les dernières éditions en date de ces documents.
1. OACI, Annexe 10 à la Convention de Chicago, Volume I,
éditionn ovembre 1985;
2. OACI, Annexe 10 à la Convention de Chicago, Volume II,
éditionjuillet 1995;
3. IFPS&RPL Dictionnary of messages Edition 1.0 Mars 19984. «Règles de l'air et services de la circulation aérienne», PANS-
RAC, Doc. 4444, édition novembre 1985 (y compris l'Amen-
dement n
o6 de novembre 1995);
5. Guide To ATFM Message Exchange, document Eurocontrol
réf. TACT/USD/MSGGUID, édition6.0, en trée envigueur
mars 1998.2000R2082 — FR — 15.06.2002 — 001.001 — 82
▼B
6. Norme Eurocontrol pour l'échange de données en ligne,
édition2.0, octobre 1996.
7. Functional Specifications for System Support to Airspace Data
Distribution and Civil Military Co-ordination, édition 1.0, mai
1996.
3. DÉFINITIONS,SYMBOLES, SIGLES ET ABRÉVIATIONS
3.1. Notation
Le système de notation utilisé pour définir la syntaxe est appelé
Backus Naur Form (BNF) ou forme normale de Backus. Ce
système définit un ensemble de règles déterminant une catégorie
de chaînes de caractères. En l'occurrence, la catégorie de chaînes
correspond à l'ensemble des messages formant un message
ADEXP syntaxiquement correct.
3.2. Définitions
Les définitions ci-après sont d'application pour les besoins de la
présente Norme Eurocontrol:
entité («token» ):: caractère ou ensemble de caractères pouvant
être «extrait» par un analyseur lexical du fait de la présence de
séparateurs;
symbole: tout «terme» apparaissant dans une règle BNF et ne
correspondant pas à un caractère;
symbole terminal : symbole représenté en termes de séquence de
caractères;
symbole non terminal : symbole représenté par un ou plusieurs
symboles terminaux.
NOTEun symbole non terminal peut également être représenté
sous la forme d'une combinaison de symboles terminaux
et non terminaux.
3.3. Construction
3.3.1. La BNF consiste en un ensemble de règles ou de constructions du
type:
symbole::= expressionNOTES1.«::=» signifie «peut être remplacé par».
2.L'élément «symbole» est non terminal.
3.L'élément «expression» contient des symboles terminaux et
non terminaux.
3.3.2. Les symboles terminaux ont une représentation directe sous la
forme d'une séquence de caractères susceptibles d'être identifiés
en tant qu'entité ( «token») par unan alyseur lexical du fait de la
présence de séparateurs.
3.4. Conventions
Les conventions ci-après sont d'application pour les besoins de la
présente Norme Eurocontrol:
— Les symboles terminaux figurent en lettres capitales.
NOTES Par convention, le symbole terminal NIL signifie
«aucun symbole terminal» .
Ce symbole apparaît notamment dans des choix du
type:
a::= b ( c | NIL ) où a peut être remplacé par (b
suivi de c) ou par b seulement.
— Les symboles non terminaux (par ex. la partie gauche d'une
production grammaticale) figurent en minuscules.
— Les caractères et symboles littéraux de chaîne apparaissant à
l'intérieur des règles figurent respectivement entre apostrophes
(') ou guillemets (”).2000R2082 — FR — 15.06.2002 — 001.001 — 83
▼B
Exemples
1. HYPHEN::= '-'
2. title::= '-' ”TITLE” titleid
Il peut s'avérer nécessaire, pour certaines applications de modéli-
sation de données, d'opérer la distinction entre symboles
terminaux et symboles non terminaux par d'autres moyens que
l'emploi des majuscules ou des minuscules.
Lorsqu'il y a lieu de distinguer de manière explicite les symboles
terminaux des symboles non terminaux par un autre moyen que
l'emploi des majuscules ou des minuscules, il est recommandé
de recourir à l'adjonction d'un suffixe, comme suit: «_at» pour
unterme auxiliaire, «_pf» pour unchamp primaire et «_sf» pour
unsous-champ.
3.5. Opérateurs
Les opérateurs ci-après sont d'application pour les besoins de la
présente Norme Eurocontrol:
facultatif: lorsque certains symboles peuvent valablement appa-
raître ou non dans la grammaire. Les symboles facultatifs sont
indiqués entre crochets «[» et «]».
clôture:lorsqu'ungroupe de symboles peut apparaître zéro fois
ou plus. Les symboles apparaissent entre accolades «{» et «}».
Si un chiffre est mentionné avant l'accolade «{», il indique le
nombre minimal d'occurrences autorisées du groupe de symboles.
Si un chiffre est mentionné après l'accolade «}», il précise le
nombre maximal d'occurrences autorisées du groupe de symboles.
choix:lorsqu'un certain nombre de symboles alternatifs peuvent
apparaître dans la grammaire. Le choix est représenté par un trait
vertical «|».
concaténation: représentation de symboles ordonnés en séquence,
indépendamment de la présence ou non d'un ou de plusieurs sépa-
rateurs. Il n'en existe pas de représentation explicite. On distingue
deux types de concaténation:
—concaténation stricte: au niveau lexical, certaines règles
peuvent faire intervenir la concaténation de symboles termi-
naux indiquant qu'ils se succèdent strictement (aucun
séparateur intermédiaire); dans ce cas, on utilise le point
d'exclamation«!»:
Exemple datetime:: = date ! timehhmm
par ex.:
”9912251200”, qui signifie le 25 décembre 1997 à 12h00.
—concaténation souple: la présence de séparateurs entre
symboles terminaux est autorisée. La représentation d'une
concaténation souple au sein d'une règle peut être implicite
ou explicite:
Exemples
1. implicite:
dct::= '-' ”DCT” point point
2. explicite:
dct::= '-'!{SEP}!”DCT”!1{SEP}!point!1{SEP}!point
par ex.: ”-DCT NTM RMS”.
NOTES
1.La concaténation a toujours la priorité sur le choix. Les
parenthèses «(» et «)» sont utilisées pour modifier l'ordre
d'évaluation de l'expression.
Exemple a::= B C | D équivaut à: a::= (B C) | D
et NON à: a::= B (C | D).
2.Dans toutes les règles, la présence autorisée de séparateurs
entre les symboles demeurera implicite, cela dans un souci de
lisibilité.2000R2082 — FR — 15.06.2002 — 001.001 — 84
▼B
Recommandation Lorsqu'il y a risque de confusion du fait de la
priorité à respecter entre les deux opérateurs susvisés, il est
recommandé de recourir aux parenthèses pour clarifier l'ordre
d'évaluation souhaité.
3.6. Sigles et abréviations
Les sigles et abréviations ci-après sont d'application pour les
besoins de la présente Norme Eurocontrol:
ACH Message de modificationde plande vol
ATC
ADEG Groupe de l'échange des données ATSADEXP Présentation de l'échange de données ATSAFIL Plande vol déposé envolAFP Propositionde plande vol ATCANM BulletinATFMAO Exploitant(s) d'aéronefsAPL Plande vol ATC
ATC Contrôle de la circulation aérienne
ATCU Organisme(s) de contrôle de la circulation
aérienne
ATFM Gestiondes couran ts de trafic aérienATS Services de la circulation aérienneBNF Backus Naur Form ou forme normale de
Backus
CAG Circulation aérienne générale
CASA Allocation de créneaux assistée par ordina-
teur
CEAC Conférence européenne de l'aviation civileCIDIN Réseau OACI commund'échan ge de
données
CFL Niveau de vol autoriséCFMU Organisme central de gestion des courants
de trafic aérien
CNL Message d'annulation
COM Circulation opérationnelle militaire
CTOT Heure calculée de décollageDPS Domaine «Systèmes informatiques de
l'ATM»
EFL Niveau de vol estiméEOBT Heure estimée de départ de l'aire de
stationnement
ETO Heure estimée de passage à la verticaleEUROCONTROL Organisation européenne pour la sécurité
de la navigation aérienne
EWPD Document «Programme de travail
EATCHIP»
FIR Régiond'in formationde vol
FIW Poste d'entrée des plans de volFMP Poste de gestiondes couran ts de trafic
FNM Message de notification de vol
FPL Message de plande vol (format OACI)
IA Alphabet internationalIAFP Propositionde plande vol ATC
IFPD Données de plan de vol individuelIFPS Système intégré de traitement initial des
plans de vol
IFPU Unité IFPSIFR Règles de vol aux instrumentsISO Organisation internationale de normalisa-
tion
ITA Alphabet télégraphique internationalLAM Accusé de réceptionlogiqueLRM Message de rejet logique2000R2082 — FR — 15.06.2002 — 001.001 — 85
▼B
MAC Message d'annulation de coordination
MFS Message de Shanwick
OACI Organisation de l'aviation civile internatio-
nale
OLDI Echange de données en ligne
PCMT Plancommunà moyenterme
RFL Niveau de vol demandé
RFP Plande vol de remplacemen t
RFPD Données de plan de vol répétififRPL Plande vol répétitifRSFTA Réseau du service fixe des télécommunica-
tions aéronautiques
RVR Portée visuelle de piste
SFL Niveau de vol supplémentaire
SRD Document relatif aux besoins en logicielsSSR Radar secondaire de surveillance
TACT Système tactique du CFMU
TOS Dispositif d'orientation du trafic
UIR Régionsupérieure d'in formationde volVFR Règles de vol à vue
4. PRINCIPES ADEXP
4.1. Texte à lecture directe
4.1.1. Le format ADEXP se présente sous forme de texte (caractères).
4.1.2. Il peut être lu directement par l'opérateur, ce qui facilite la mise
au point ou l'examen des questions opérationnelles.
4.1.3. Ce format présente également l'avantage d'être à la fois plus
ouvert et plus compréhensible.
4.2. Champsidentifiés et récupérables
4.2.1. Chaque message enformat ADEXP se compose de champs.
4.2.2. Ces champs sont délimités par un caractère spécial de début de
champ, le trait d'union («-»), et identifiés au moyen de mots-clés
spécifiques.
NOTEIl convient de noter que certains champs (ceux qui sont
syntaxiquement définis comme comportant l'élément
lexical «CHARACTER») peuvent valablement contenir un
«-» dans l'énoncé du champ.
4.2.3. Une telle formule confère au format des possibilités d'extension et
une robustesse accrues (si un champ est absent ou incorrect, il
peut être négligé sans que cela nuise à l'interprétation du reste
du message (cf. section0).
4.2.4. Autre conséquence, l'ordre des champs n'a aucun rôle dans la
détermination de la validité du message, à l'exception du premier
champ (champ obligatoire intitulé «TITLE», qui détermine les
champs admis.
4.2.5. Les champs peuvent être simples ou composés.
4.2.6. Les éléments constitutifs des champs composés sont appelés sous-
champs; ils sont définis au moyen de mots-clés et délimités par
uncaractère de début de champ.
4.2.7. Les champs simples ne comportent aucun sous-champ.4.2.8. Les champs simples et composés constituant le premier niveau de
définition d'un message sont appelés champs primaires.
4.2.9. Tous les constituants de niveau inférieur sont, par définition, des
sous-champs, qui peuvent être eux aussi simples ou composés.
4.2.10. Les champs composés sont de deux types: champs structurés ou
champs de listage.2000R2082 — FR — 15.06.2002 — 001.001 — 86
▼B
4.2.11. Les champs structurés ont un contenu prédéfini et se composent
de sous-champs exclusivement. L'ordre des sous-champs dans un
champ structuré n'est PAS déterminant.
4.2.12. Les champs de listage débutent par le mot-clé BEGIN et se termi-
nent par le mot-clé END. Entre ces deux repères, on peut trouver
plusieurs occurrences d'un même sous-champ ou une combinaison
de sous-champs. L'ordre des occurrences au sein d'un champ de
listage est sémantiquement déterminant.
4.2.13. Dans les paragraphes qui suivent, le terme «champ» sera utilisé
pour désigner indistinctement des champs primaires et/ou des
sous-champs, sauf indication contraire.
4.2.14. Les champs d'unmessage peuven t être facultatifs ou obligatoires,
selonleur syn taxe.
4.3. Champsnon identifiés
4.3.1. Tout champ inconnu apparaissant dans un message doit être
négligé.
4.3.2. En d'autres termes, si le système qui analyse le message ne
reconnaît pas un mot-clé, il négligera automatiquement l'intégra-
lité du texte jusqu'au prochain champ primaire connu, qui ne se
situe pas dans un champ de listage.
4.3.3. Selon l'intitulé du message, le champ négligé pourra entraîner ou
non un rejet de l'ensemble du message.
NOTEIl convient de noter que si l'ADEXP est conçu pour offrir
une telle souplesse d'utilisation, il appartient aux respon-
sables de la définition des besoins en matière d'interface
de préciser, pour chaque message, la manière dont le
système devrait réagir en présence d'un champ non iden-
tifié.
4.3.4. Si le champ inconnu est un champ de listage (il débute par le
mot-clé BEGIN), son contenu (jusqu'au mot-clé END correspon-
dant) est intégralement négligé.
4.3.5. Pour éviter toute ambiguïté au cours de la reprise consécutive au
saut d'un champ non identifié, il est impératif qu'un même mot-
clé introduise soit un champ primaire, soit un sous-champ (mais
pas les deux).
4.3.6. On peut ainsi distinguer deux types de mot-clé:
— mots-clés primaires;
— mots-clés secondaires.
4.3.7. Une fois qu'il a été défini comme appartenant à l'une des deux
catégories, le mot-clé ne peut plus être réutilisé dans un autre
groupe de messages sous couvert de l'autre catégorie, sauf s'il se
situe à l'intérieur d'un champ de listage. En effet, des occurrences
internes d'un mot-clé primaire sont possibles au sein d'un champ
de listage sans que cela ne crée d'ambiguïté, le mot-clé BEGIN
indiquant que l'occurrence interne peut être considérée comme
unsous-champ.
Exemples (d'utilisationde types de mot-clé)
1.Champ primaire
-RFL F330
2.Sous-champ: toujours au seind'unchamp composé
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W
où -GEO est unchamp composé primaire et -GEOID, -
LATTD et LONGTD sont des sous-champs.
3.Champ de listage
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTS
où «-BEGIN» est l'indicateur de champ de listage et RTEPTS,
unchamp primaire.
NOTE«-RFL» est défini comme un champ primaire. L'inclusion
dans un champ de listage constitue le seul cas où un2000R2082 — FR — 15.06.2002 — 001.001 — 87
▼B
champ primaire peut être utilisé en tant que sous-champ
(cf. exemple 3 ci-dessus).
5. RÈGLES SYNTAXIQUESADEXP
5.1. Éléments lexicaux
5.1.1. Jeu de caractères
5.1.1.1. Le jeu de caractères à utiliser pour l'échange de messages en
format ADEXP est l'alphabet international no5 (IA-5), tel que
défini en référence 1.
5.1.1.2. Le format ADEXP est conçu pour les échanges d'ordinateur à
ordinateur par l'intermédiaire de différents réseaux informatiques
ou de liaisons intercalculateurs spécialisées. Par ailleurs, certains
messages ADEXP, notamment les messages ayant trait à la plani-
fication des vols et à l'ATFM, doivent pouvoir être échangés sur
le Réseau du service fixe des télécommunications aéronautiques
(RSFTA).
5.1.1.3. Le jeu de caractères des messages susceptibles de devoir être
transmis via le RSFTA doit être limité aux caractères présentant
une corrélation directe entre l'alphabet télégraphique international
no2 (ITA-2) et l'IA-5, tel que défini en référence 1.
NOTEOutre les caractères graphiques et les commandes de
mise en page énumérés ci-après, le jeu de caractères
ITA-2 définit également une série de «signaux» (bande
perforée par exemple). Ces signaux ne font pas partie
des caractères admis pour les messages ADEXP.
5.1.1.4. Seuls les caractères graphiques et commandes de mise en page ci-
après peuvent être utilisés dans les messages ADEXP susceptibles
d'être transmis via le RSFTA:
Caractères graphiques
a. majuscules (A à Z)
b. chiffres (0 à 9)
c. caractères graphiques spéciaux suivants:
1. espace « »
2. parenthèse gauche «(»3. parenthèse droite «)»4. tiret «-»5. point d'interrogation «?»
6. deux points «:»
7. point «.»8. virgule «,»9. apostrophe «'»
10. signe égal «=»
11. signe plus «+»
12. barre oblique «/»
Commandes de mise en page
a. retour de chariot
b. changement de ligne
5.1.2. Unités lexicales de base
La présente spécification admet les unités lexicales de base
suivantes:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
— ALPHANUM ::= ALPHA | DIGIT
— SPACE ::= ' '
— HYPHEN ::= '-'
— FEF ::= Carriage_return| Lin e_Feed— SEP ::= 1{ SPACE | FEF }
— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'2000R2082 — FR — 15.06.2002 — 001.001 — 88
▼B
— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF
— START-OF-FIELD ::= HYPHEN
NOTELIM_CHAR représente n'importe quel caractère admis à
l'exception du tiret («HYPHEN»), qui sert exclusivement
à indiquer le début d'un champ. En revanche,
CHARACTER représente n'importe quel élément admis
du jeu de caractères.
5.1.3. Lignes et séparateurs
5.1.3.1. La subdivision en lignes du texte d'un message n'a aucune inci-
dence sur le plan syntaxique.
5.1.3.2. Un séparateur peut être un espace ou une commande de mise en
page.
5.1.3.3. Les champs ne sont délimités que par la présence d'un caractère
de début de champ suivi d'unmot clé.
5.1.3.4. Un message pourrait donc être valablement formulé en une seule
ligne.
5.1.4. Valeurs affectées d'un signe
5.1.4.1. Il peut être nécessaire de mentionner une valeur numérique néga-
tive.
5.1.4.2. Les champs requis pour indiquer une valeur négative doivent,
dans leur définition syntaxique, mentionner explicitement que la
valeur est affectée d'un signe, positif ou négatif. Tout champ qui
ne serait pas défini de la sorte ne peut représenter une valeur
négative.
5.1.4.3. Une valeur affectée d'un signe doit toujours être précédée de la
lettre «N», pour négatif, ou «P», pour positif. Une valeur zéro
peut indistinctement être précédée de «N» ou de «P».
5.1.4.4. La syntaxe d'un champ qui admet une valeur affectée d'un signe
doit se présenter comme suit:
‘-' “KEYWORD” (“P” | “N”) ! 1{DIGIT}Exemple Un champ intitulé «NUMBER» pouvant contenir une
valeur négative de un à huit chiffres se définirait
comme suit:
‘-' “NUMBER” (“P” | “N”) ! 1{DIGIT}8
d'où: -NUMBER P5 — valeur correspondant à +5
-NUMBER N5 — valeur correspondant à –5-NUMBER 5 — syntaxe non valable, il doit obliga-
toirement y figurer un «P» ou un
«N»
5.1.5. Mots-clés
5.1.5.1. Un mot-clé est composé d'une séquence de majuscules ou de
chiffres. Le mot-clé n'introduit un champ que s'il est précédé
d'uncaractère de début de champ («-«).
keyword::= 1{ ALPHANUM }
5.1.5.2. Les mots-clés doivent respecter la syntaxe suivante:
'-'!{SEP}!”KEYWORD”!1{SEP}! <subfield/s or contained value>d'où il ressort qu'unmot-clé sera séparé de soncaractère de début
de champ par zéro séparateur ou plusieurs. Il sera immédiatement
suivi d'unou de plusieurs séparateurs, puis du ou des sous-
champ(s) correspondant(s) ou de la valeur contenue.
NOTE Il convient de noter qu'un mot-clé peut être séparé du
caractère de début de champ qui le précède par un
nombre indéterminé de séparateurs, y compris zéro.
Exemples (Les séquences suivantes introduisent toutes vala-
blement un champ)
1. -TITLE IFPL
2. - TITLE IFPL2000R2082 — FR — 15.06.2002 — 001.001 — 89
▼B
3. - TITLE IFPL
4. -
TITLE IFPL
5.1.5.3. Recommandation Il est recommandé d'éviter de placer un sépa-
rateur entre le caractère de début de champ «-» et le mot-clé qui
suit.
NOTE1. Dans les exemples ci-dessus, la première occurrence constitue
la solutionrecomman dée.
2. Il est également important de noter qu'un mot-clé doit être
immédiatement suivi d'un séparateur au moins.
5.1.5.4. Dans le présent document, la concaténation d'éléments séparés
par un séparateur au moins est implicitement représentée par la
notation de «concaténation souple» (cf.3.5).
NOTEAinsi qu'il est expliqué plus loin, les mots-clés introdui-
sent également des champs de listage lorsque ceux-ci sont
précédés du mot-clé BEGIN.
5.1.5.5. Les mots-clés doivent être aussi courts que possible tout en
restant sémantiquement significatifs.
5.1.5.6. Les mots-clés prédéfinis du format ADEXP énumérés ci-après ne
peuvent être redéfinis ou utilisés dans un autre rôle dans le cadre
d'applications spécifiques du format:
TITLE: identifie une catégorie de messages et définit
l'ensemble correspondant de champs primaires
admis;
BEGIN: identifie le début d'un champ de listage;
END: identifie la fin d'un champ de listage;
COMMENT: identifie un champ COMMENT (observations).
5.1.5.7. Pour prévenir toute ambiguïté (double emploi d'un même mot-clé
dans des acceptions différentes) ou redondance (mots-clés diffé-
rents ayant la même signification), un Tableau central de
définitions des champs primaires (mots-clés primaires) figure à
l'Annexe A (A3) de la présente Norme; un Tableau central de
définitions des sous-champs (mots-clés secondaires) est égale-
ment inclus à l'Annexe A (A4).
5.2. Champs
5.2.1. Syntaxe des champs
field::= basic_field | structured_field | list_fieldbasic_field::= '-' keyword contained_valuescontained_values::= {CHARACTER}list_field::= '-' ”BEGIN” keyword {subfields} '-' ”END” keyword
structured_field::= '-' keyword field_1 field_2 ….field_n
NOTE Comme onle verra, dan s le cas des champs de listage, le
mot-clé n'est pas directement précédé d'un '-' mais de la
construction '-' ”BEGIN”.
5.2.2. Composition des messages au niveau des champs
5.2.2.1. Le premier champ d'unmessage ADEXP doit toujours être un
champ TITLE (c'est-à-dire unchamp in troduit par le mot-clé
TITLE).
5.2.2.2. Les autres champs primaires constituant le message sont définis
par sonTITLE.
5.2.2.3. La syntaxe des messages correspondant à un TITLE donné est
définie par les champs qui le composent (lesquels sont définis
par leur mot-clé):
— nom et contenu autorisé de ses champs primaires;
— nom et contenu autorisé de ses sous-champs.2000R2082 — FR — 15.06.2002 — 001.001 — 90
▼B
5.2.3. Champs simples
5.2.3.1. La syntaxe des champs simples se présente comme suit:
basic_field::= '-' keyword contained_values
5.2.3.2. L'expression «contained_values» définit le texte précisant la
valeur du champ et ne peut introduire aucun sous-champ.
Exemple de règle arctyp::= '-' ”ARCTYP” (icaoaircrafttype |
”ZZZZ”)
NOTES1. Unéquivalen t explicite serait:
arctyp::= '-'!{SEP}!”ARCTYP”!1{SEP}!(icaoaircrafttype |
”ZZZZ”).
2. Exemple de portionde message:
”-ARCTYP ZZZZ”.
5.2.3.3. Recommandation Lorsqu'un champ simple comprend plus de
deux valeurs contenues et qu'il y a lieu, par ailleurs, d'exprimer
un choix ou une option parmi les valeurs, il est recommandé de
convertir le champ en champ structuré et d'inclure les valeurs
contenues dans les sous-champs.
5.2.4. Champs de listage
5.2.4.1. La syntaxe des champs de listage se présente comme suit:
list_field::='-' ”BEGIN” keyword { subfields } '-' ”END” keyword
5.2.4.2. Les sous-champs peuvent se présenter sous la forme de n'importe
quelle combinaison de sous-champs susceptible d'apparaître zéro
fois ou plus dans le champ de listage.
5.2.4.3. La liste des sous-champs d'unchamp de listage doit former un
ensemble ordonné (l'ordre de succession des sous-champs est
significatif).
Exemple de règle addr::= '-' ”BEGIN” ”ADDR” { fac } '-'
”END” ”ADDR”
NOTES
1. Il ressort de l'exemple ci-dessus qu'unchamp «addr» est un
champ de listage contenant 0 occurrence ou plus d'un sous-
champ «fac» (une installation ATS).
2. Exemple de portionde message où ADDR est unchamp de
listage comprenant des sous-champs FAC:
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.
3. Exemple de portion de message faisant apparaître une combi-
naison de sous-champs:
xxx::= '-' ”BEGIN” ”XXX” { yyy | zzz } '-' ”END” ”XXX”.
5.2.5. Champs structurés
5.2.5.1. La syntaxe des champs structurés se présente comme suit:
structured_field::= '-' keyword field_1 field_2…field_n
5.2.5.2. Les sous-champs admis dans un champ structuré sont exclusive-
ment fonction du champ structuré lui-même.
5.2.5.3. L'ordre d'apparitiondes sous-champs dan s unchamp structuré
n'est pas significatif, ce qui facilite les extensions ultérieures
(additionde n ouveaux sous-champs).
Exemple de règle pt::= '-' ”PT” ptid [fl] [eto]
NOTES
1. Dans l'exemple ci-dessus, «pt» est un champ structuré compre-
nant un point (sous-champ «ptid»), suivi, facultativement, d'un
niveau de vol calculé (sous-champ «fl») et d'une estimée de
passage à la verticale du point (sous-champ «eto»).
2. Untype d'occurren ce de ce champ pourrait être:
”-PT -PTID RMS -FL F250 -ETO 921225120000”.2000R2082 — FR — 15.06.2002 — 001.001 — 91
▼B
5.2.5.4. Recommandation Si le contenu d'un champ est appelé à évoluer
avec le temps, il est souhaitable d'en faire un champ structuré: il
sera alors possible de procéder à des extensions progressives de
ses sous-champs. Au contraire, si un champ simple peut s'avérer
plus aisé et plus courant à utiliser, il n'en impose pas moins une
séquence fixe des éléments (valeurs) et offre très peu de possibi-
lités d'extension.
5.2.6. Le champ COMMENT (observations)
5.2.6.1. Le champ COMMENT introduit une zone de texte libre dans
laquelle tous les caractères, à l'exceptiondu caractère de début
de champ ('-'), peuvent être utilisés; cette zone s'étend jusqu'au
champ suivant:
comment::= '-' ”COMMENT” { LIM_CHAR }
Exemple -COMMENT THIS IS THE BEGINNING OF A FREE
ROUTE TEXT AREA
5.2.7. Le champ TITLE (intitulé)
5.2.7.1. Unmessage ADEXP doit toujours commen cer par unchamp
TITLE, dont la syntaxe se présente comme suit:
title::= '-' ”TITLE” 1{ ALPHA }10
5.2.7.2. Les valeurs possibles du champ TITLE consistent en l'ensemble
des intitulés de message répertoriés dans l'Annexe B de la
présente Norme.
Exemple -TITLE IFPL
6. DESCRIPTIONNORMALISEE DES MESSAGES ADEXP
6.1. Introduction
6.1.1. Les paragraphes qui suivent définissent la façon dont le format
ADEXP des différentes catégories de messages ATS doit être
décrit de manière normalisée dans le cadre de présente Norme.
6.1.2. Cette description normalisée comprend:
— la définition des termes auxiliaires;
— la définition syntaxique et sémantique de chaque champ
primaire;
— la définition syntaxique et sémantique de chaque sous-champ;— la définition de chaque groupe de messages avec renvoi aux
documents de spécification.
6.1.3. La présente Norme ne détaille ni la composition des champs, ni
les règles d'insertion des données pour chaque intitulé de
message.
6.1.4. Il convient de se référer aux documents de spécification (spécifi-
cationd'in terface) pour chaque groupe de messages (cf.
section6.5.7).
6.1.5. Les documents de spécification devraient fournir les informations
ci-après pour chaque intitulé de message:
— liste des champs primaires obligatoires;
— liste des champs primaires facultatifs;— règles d'insertion des données pour chaque champ et, en parti-
culier, règles d'utilisationdes sous-champs défin is comme
facultatifs dans la présente Norme;
— règles de reprise suite à la détection d'un champ non identifié.
6.1.6. Les champs actuellement définis et convenus, au niveau de
l'ensemble des Etats membres d'Eurocontrol, pour être utilisés
dans les différentes catégories de messages ADEXP sont réperto-
riés dans l'Annexe A du présent document.
6.1.7. Unchamp n e peut être utilisé à d'autre finque celle qui est spéci-
fiée dans sa description sémantique.
6.1.8. Un index central des champs réservés figure à l'Annexe D. L'uti-
lisationde champs réservés dan s les messages ADEXP
actuellement spécifiés n'a pas été approuvée. Il s'agit typiquement
de champs définis en prévision d'une éventuelle utilisation future
ou de champs utilisés à l'échelonlocal par des systèmes n atio-
naux. Leur inclusion dans la présente Norme vise à faciliter2000R2082 — FR — 15.06.2002 — 001.001 — 92
▼B
l'unicité des intitulés de champ et à prévenir les redondances
inutiles.
6.2. Termes auxiliaires
6.2.1. Pour obtenir une définition lisible des champs, il est souvent utile
d'introduire des termes auxiliaires dans la description grammati-
cale.
6.2.2. Ces termes auxiliaires ne servent pas à introduire un champ ou un
sous-champ et ne sont donc pas associés à un mot-clé particulier.
Ils sont toutefois susceptibles d'apparaître dans la définition de
plusieurs champs, sous-champs ou éléments auxiliaires. A titre
d'exemple, unterme auxiliaire comme «date» peut apparaître
dans la définition de nombreux champs.
6.2.3. Tous les termes auxiliaires nécessaires doivent être présentés dans
l'ordre alphabétique; ils sont définis dans l'Annexe A (A2) de la
présente Norme.
6.2.4. La description peut être présentée en tableau, comme ci-dessous, dans l'ordre alphabé-
tique:
Terme
auxiliaireSyntaxe SémantiqueUtilisé dans
champ
primaireUtilisé dans
sous-champUtilisé
dans
terme
auxi-
liaire
adexpmsg { CHARACTER } Texte libre
conforme à la
syntaxe décrite
pour un
message
ADEXPifpdlong
rfpdlong
preproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipement de
radio-commu-
nication, de
navigation et
d'approcheceqpt
aircraftid 1{ ALPHANUM
}7Identification
d'aéronefarcid
arcidkarcidoldprevarcid
6.3. Définition des champs primaires
6.3.1. Tous les champs primaires utilisés dans les messages ADEXP
doivent être conformes à la syntaxe et à la sémantique spécifiées
à l'Annexe A (A3) de la présente Norme.
6.3.2. La syntaxe de chaque champ est donnée en premier lieu, suivie
du contenu sémantique décrit en termes clairs et précis.
6.3.3. La syntaxe des champs est exprimée dans le système de notation
BNF présenté à la section 3 de la présente Norme.
6.3.4. La description peut être présentée en tableau, comme ci-dessous, dans l'ordre alphabé-
tique:
— la première colonne correspond à la partie gauche d'une règle BNF (c.-à-d. à l'élé-
ment situé à gauche du symbole «::=»), la troisième colonne, à la partie droite;
— la deuxième colonne («Type») indique s'il s'agit d'un champ simple («b» pour
«basic») ou d'unchamp composé («c» pour «compoun d»).
Primaire Type Syntaxe Sémantique
eobt b '-' ”EOBT” timehhmm Heure estimée de départ de
l'aire de stationnement2000R2082 — FR — 15.06.2002 — 001.001 — 93
▼B
6.4. Définition des sous-champs
6.4.1. Tous les sous-champs utilisés dans les messages ADEXP doivent
être conformes à la syntaxe et à la sémantique spécifiées à
l'Annexe A (A4) de la présente Norme.
6.4.2. Pour faciliter les renvois, les champs primaires dans lesquels
apparaît un sous-champ donné sont également mentionnés.
6.4.3. Etant donné qu'un sous-champ peut également être un sous-
champ d'autres sous-champs, un renvoi à ceux-ci est également
fait.
6.4.4. La description peut être présentée en tableau, comme ci-dessous, dans l'ordre alphabé-
tique:
Sous-champ Type Syntaxe SémantiqueUtilisé dans
champ
primaireUtilisé
dans
sous-
champ
brng b '-' ”BRNG”
refbearingRelèvement d'un
point par rapport
à une aide à la
navigation (en
degrés magnéti-
ques)ref
6.5. Groupes de messages
6.5.1. Les catégories opérationnelles (groupes) de messages à utiliser
dans le format ADEXP sont présentées à l'Annexe E de la
présente Norme.
6.5.2. Ces groupes sont définis par la nature opérationnelle des
messages échangés et se caractérisent le plus souvent par les
systèmes utilisés.
6.5.3. Il convient, pour chaque groupe de messages, de renvoyer aux
documents de spécification correspondants.
6.5.4. Une valeur TITLE utilisée pour un groupe de messages ne peut
en aucun cas être réutilisée pour un autre groupe dans une accep-
tiondifféren te.
6.5.5. Un index central des intitulés de message figure à l'Annexe B de
la présente Norme.
6.5.6. Chaque intitulé de message figurant dans cet index central est
assorti d'un renvoi au groupe de messages correspondant de sorte
que le renvoi aux documents de spécification s'opère via le
groupe de messages.
6.5.7. Un index central des intitulés de message réservés figure égale-
ment à l'Annexe C. L'utilisation de ces intitulés de message
réservés dans les groupes de messages ADEXP actuellement
spécifiés n'a pas été approuvée. Il s'agit typiquement de messages
définis en prévision d'une éventuelle utilisation future au sein
d'undes groupes ou de messages utilisés à l'échelonlocal par
des systèmes nationaux. Leur inclusion dans la présente Norme
vise à faciliter l'unicité des appellations de message et à prévenir
les redondances inutiles.2000R2082 — FR — 15.06.2002 — 001.001 — 94
▼B
ANNEXE A (Normative)
DEFINITIONSDES CHAMPS ADEXP
A.1.Introduction
La présente Annexe comporte la liste de tous les champs — termes auxi-
liaires, champs primaires et sous-champs — spécifiés pour le format
ADEXP.
A.2.Termes auxiliaires ADEXP
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
adexpmsg { CHARACTER } Texte libre
conforme à la
syntaxe décrite pour
unmessage ADEXPifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipement de
radio-communica-
tion, de navigation
et d'approcheceqpt
aircraftid 2{ ALPHANUM }7 Identification
d'aéronefarcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Format joker
(symboles de
remplacement)
d'identification
d'aéronef à utiliser
dans les messages
d'interrogation:
«?» remplace un
caractère «+»
remplace unn ombre
quelconque de
caractèresarcidk
atsroute 2 {ALPHANUM} 7 Indicatif de route
ATSatsrt refatsrte
century 2{DIGIT}2 Deux premiers chif-
fres du sièclefulldate
cfmucode 2{ALPHA}3 Indicatif CFMU qui
donne la cause ou la
raisond'un e régula-
tion.regcause
coorstatusident 3 {ALPHA} 3 Indication du statut
de coordination d'un
volstatid
coorstatus-
reason3 {ALPHA} 7 Justificationd'un
changement à
opérer au niveau du
statut de coordina-
tiond'unvolstatreas-
on
country 2{ALPHA}2 Indicatif OACI du
pays endeux lettresrefatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4Indicatif OACI
d'équipement de
liaison de données;
peut contenir les
valeurs S, H, V or
M dans n'importe
quel ordre mais sans
répétitiondat2000R2082 — FR — 15.06.2002 — 001.001 — 95
▼B
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
date year ! month ! day Indication de la date
enformat
YYMMDD
(AAMMJJ)
ex.:
930424 = 24 avril
1993ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm Bloc date tel que
défini ci-dessus
suivi de l'heure en
format HHMM
ex.:
9304240930=09h3-
0Z le 24 avril 1993origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6Bloc date, éventuel-
lement en format
jokervalfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITNombre à deux
chiffres, de 00 à 31endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicateur du type
d'équipement radio
de secours
embarqué; peut
contenir un ou
plusieurs des carac-
tères spécifiés, dans
n'importe quel ordre
mais sans répétitionsplr
eqptcode 1 {ALPHANUM} 2 Code identifiant une
aptitude d'équipe-
ment. Peut être
identique au code
équipementeqpt
eqptstatus 2 {ALPHA} 2 Deux lettres indi-
quant l'état des apti-
tudes de l'aéronefeqpt
equipmentcode 1 {(‘A' | ‘B' | ‘C' |
‘D' | ‘E' | ‘F' | ‘G' |
‘H' | ‘I' | ‘J' | ‘K' |
‘L' | ‘M' | ‘O' | ‘P' |
‘Q' | ‘R' | ‘T' | ‘U' |
‘V' | ‘W' | ‘X' | ‘Y' |
‘Z' )} 24Code lettre OACI
désignant le type
d'équipement
embarqué; peut
contenir un ou
plusieurs des carac-
tères spécifiés, dans
n'importe quel ordre
mais sans répétitionaidequip-
ment
errorcode 1{DIGIT}4 Numéro de code de
message d'erreurerror2000R2082 — FR — 15.06.2002 — 001.001 — 96
▼M1
▼B
▼B
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
fieldid 1{ ALPHANUM } Intitulé de champ
ADEXP (= mot-clé)errfield
ifpsmod
firindicator 4{ ALPHA }4 Indicatif OACI de
FIReetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4Niveau de vol
exprimé comme
suit:
«F» ou «A» suivi de
trois chiffres ou
«S» ou «M» suivi
de quatre chiffresrfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'Justificationdu trai-
tement spécial
mentionné à la case
18 (indicateur STS/
):
EMER = urgence
HUM = vol huma-
nitaire
HOSP = vol sani-taire
SAR = rech. et
sauvetage
HEAD = chef d'Etat
STATE = vol d'Etatsts
flightrule 'I' | 'V' | 'Y' | 'Z' Indication des
règles de vol appli-
cables au volfltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Type de vol confor-
mément à l'indicatif
OACI utiliséflttyp
flighttypechg 'OAT' | 'GAT' Mention, dans la
descriptionde route,
d'une modification
du type de vol (
«OAT [COM]» ou
«GAT» [CAG])chgrul ptrulchg
fulldate century ! year !
month ! dayIndication de la date
enformat
CCYYMMDD
(SSAAMMJJ)
ex.: 19970801 = 1
er
août 1997fulldate-
time
fulldatetime fulldate ! timehhmm Indication de la date
enformat «full-
date», suivi immé-
diatement de l'heure
enformat HHMM
ex.:
199708010930=09-
h30 le 1eraoût 1997mesval-
period
geoname "GEO" !
2{DIGIT}2Identification d'une
positiongéogra-
phique exprimée en
latitude et longitudegeoid
heading 3{DIGIT}3 Nombre de trois
chiffres compris
entre 001 et 360ahead
icaoaerodrome 4{ ALPHA }4 Indicatif OACI à
quatre lettres pour
unaérodromeadep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid2000R2082 — FR — 15.06.2002 — 001.001 — 97
▼B
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Format joker d'aéro-
drome OACI à
utiliser dans les
messages d'interro-
gation: «?»
remplace uncarac-
tère
«+» remplace un
nombre quelconque
de caractèresadepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3Indicatif OACI du
type d'aéronefarctyp
icaomsg { CHARACTER } Message OACI
(conforme à la
syntaxe spécifiée en
réf. 4)msgtxt
ifpuid 1{ ALPHANUM } Identificateur d'une
unité IFPSifpuresp
latitudelong 6{ DIGIT }6 Latitude exprimée
ensix chiffreslattd
latitudeside 'N' | 'S' Indicateur de lati-
tude nord ou sudlattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4Indicateur OACI du
type de gilet de
sauvetage
embarqué; peut
contenir un ou
plusieurs des carac-
tères spécifiés, dans
n'importe quel ordre
mais sans répétitionsplj
longitudelong 7{ DIGIT }7 Longitude exprimée
ensept chiffreslongtd
longitudeside 'E' | 'W' Indicateur de longi-
tude est ou ouestlongtd
machnumber 'M' ! 3{ DIGIT }3 Nombre de Mach mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Indication du type
de modification
opérée dans un
champifpsmod
month ('0' | '1' ) ! DIGIT Mois, exprimé en
deux chiffresdate
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Jours de la semaine
pendant lesquels un
RPL est «activé»days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Jours de la semaine
pendant lesquels un
RPL est «activé» ;
possibilité d'utiliser
des caractères jokerdaysk
originatorid 1{ ALPHANUM
}10Identificateur de
l'émetteur du
messageorgnid
qrorgn2000R2082 — FR — 15.06.2002 — 001.001 — 98
▼B
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
point 2{ ALPHANUM }5 Indicatif d'un point
significatif ; il peut
s'agir d'unpoin t
publié, d'unpoin t
géographique, d'un
point de référence
ou d'unpoin t artifi-
ciel tel qu'unpoin t
renommé (RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Relèvement de réfé-
rencebrng
refname "REF" ! 2{DIGIT}2 Identificateur donné
à unpoin t exprimé
enrelèvemen t et
distance par rapport
à unpoin t publiérefid
regulid 1{ ALPHANUM
}20Identification d'une
mesure de régula-
tionATFM appli-
cable à unvolregul regid
renameid "REN" !
2{DIGIT}2Identificateur d'un
point renommérenid
rrteid 1{ ALPHANUM}
20Identificateur d'un
réacheminementrrteref
rtf 6{DIGIT}6 Radiofréquence
exprimée enMHz et
arrondie à trois
décimalesfreq
rulechg VFR' | 'IFR' Indicateurs utilisés
dans la description
de route pour
signaler une modifi-
cationdes règles de
volchgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSecondes, deux
chiffres de «00» à
«59».eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Vitesse exprimée
par «K» ou «N»,
suivi de quatre chif-
fresaspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 Indicatif OACI de
l'équipement SSR
de bord et, faculta-
tivement, indication
de l'équipement de
liaison de donnéesseqpt
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Indicatif de période
de «séjour» ou
période d'activité
spéciale mentionnée
dans la description
de routeptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4Indicatif OACI de
l'équipement de
survie embarqué;
peut contenir un ou
plusieurs des carac-
tères spécifiés, dans
n'importe quel ordre
mais sans répétitionspls2000R2082 — FR — 15.06.2002 — 001.001 — 99
▼B
Terme auxi-
liaireSyntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé
dans
sous-
champUtilisé en
élément
auxiliaire
text20 1{ LIM_CHAR }20 Texte de 1 à 20
caractères, à l'exclu-
siondu tiretaltnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITHeure du jour ou
durée exprimée en
heures (deux chif-
fres 00-23) et
minutes (deux chif-
fres 00-59)aobt
ata
atd
atot
cobt
ctot
delay
eetfir
eetpt
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
sple
starttime
taxitime
ttleetcto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_ela-
psedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITNombre illimité
d'heures et minutes
utilisé pour des
durées.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Format joker d'un
bloc timehhmmeobtk
titleid 1{ ALPHA }10 Intitulé de message
ADEXP valable (cf.
Annexe B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' Indicatif OACI de
catégorie de turbu-
lence de sillagewktrc
year 2{ DIGIT }2 Deux derniers chif-
fres de l'annéedate
fulldate
A.3.Champs primaires ADEXP
Champ
primaire
ADEXPType Syntaxe Sémantique
ad c '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Indicatif d'aérodrome. Si l'aéro-
drome fait partie de la description
de route, un complément d'infor-
mations d'acheminement peut être
fourni
ada b '-' "ADA" date Date d'arrivée effective
adarr b -' “ADARR” (icaoaerodrome |
'ZZZZ')Aerodrome effectif d'arrivée2000R2082 — FR — 15.06.2002 — 001.001 — 100
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
adarrz b '-' "ADARRZ" text20 Nom de l'aérodrome effectif
d'arrivée s'il n'existe pas d'indicatif
OACI
add b '-' "ADD" date Date de départ effectiveaddr c '- "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Liste de destinataires
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')Indicateur d'emplacement OACI de
l'aérodrome de départ, ou mention
«AFIL» pour indiquer un plan de
vol déposé envol, ou men tion
«ZZZZ» si l'aéroport de départ ne
possède pas d'indicateur OACI
adepk b '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Aérodrome de départ utilisé comme
clé de base de données dans une
interrogation, format joker possible;
il peut s'agir d'unin dicateur
d'emplacement OACI, de lamention «AFIL» pour indiquer un
plande vol déposé envol, de la
mention «ZZZZ» si l'aérodrome de
départ ne possède pas d'indicateur
OACI ou d'une combinaison de
caractères alphabétiques et joker
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')Aérodrome de départ «précédent»;
il peut s'agir de l'indicateur
d'emplacement OACI, de la
mention «AFIL» pour indiquer un
plande vol déposé envol ou de la
mention «ZZZZ» si l'aérodrome de
départ ne possède pas d'indicateur
OACI
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')Indicateur d'emplacement OACI de
l'aérodrome de destination ou
mention «ZZZZ» si l'aérodrome de
destination ne possède pas d'indi-
cateur OACI
adesk b '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Aérodrome de destination utilisé
comme clé de base de données
dans une interrogation, format
joker possible; il peut s'agir d'un
indicateur d'emplacement OACI, de
la mention «ZZZZ» si l'aérodrome
de destination ne possède pas
d'indicateur OACI ou d'une combi-
naison de caractères alphabétiques
et joker
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')Aérodrome de destination «précé-
dent» ; il peut s'agir de l'indicateur
d'emplacement OACI ou de la
mention «ZZZZ» si l'aérodrome de
destination ne possède pas d'indi-
cateur OACI.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Contient un message ADEXP
afildata c '-' "AFILDATA" ptid fl eto Données d'estimation pour un plan
de vol déposé envol: iden tification
d'un point, niveau de vol de jonc-
tionet date-heure estimées de
passage à la verticale du point.
NOTE: Le niveau de vol
mentionné est celui auquel le vol
est autorisé à rejoindre l'espace
aérien contrôlé au-dessus du point
indiqué. Il ne doit pas nécessaire-
ment correspondre au RFL2000R2082 — FR — 15.06.2002 — 001.001 — 101
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
ahead b '-' "AHEAD" (heading | "ZZZ") Cap assigné à un vol, exprimé en
degrés.
Il doit obligatoirement s'agir d'un
nombre à trois chiffres ou de la
mention «ZZZ» si aucun cap n'a
été assigné
altnz b '-' "ALTNZ" text20 Nom de l'aérodrome de dégage-
ment s'il n'existe pas d'indicateur
d'emplacement OACI
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')Indicateur d'emplacement OACI du
premier ADES de dégagement ou
mention «ZZZZ» si l'aérodrome ne
possède pas d'indicateur OACI
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')Indicateur d'emplacement OACI du
second ADES de dégagement ou
mention «ZZZZ» si l'aérodrome ne
possède pas d'indicateur OACI
aobd b '-' "AOBD" date Date effective de départ de l'aire de
stationnement
aobt b '-' "AOBT" timehhmm Heure effective de départ de l'aire
de stationnement
arcid b '-' "ARCID" aircraftid Identification de l'aéronef:
marques d'immatriculationde
l'aéronef ou indicatif OACI de
l'exploitant d'aéronefs suivi de
l'identification du vol
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Identification de l'aéronef utilisée
comme clé de base de données
dans une interrogation, format
joker possible.
Il doit s'agir d'une combinaison de
7 caractères alphanumériques et
joker maximum
arcidold b '-' ARCIDOLD aircraftid Identification «précédente» de
l'aéronef. En cas de modification de
l'identification de l'aéronef, la
nouvelle valeur sera entrée sous
«ARCID»
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Type d'appareil (identification
OACI) ou ZZZZ
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")Vitesse effectivement assignée au
vol, exprimée enkm/h, enn oeuds
ou enn ombre de Mach.
La mention obligatoire consiste en
un«M» suivi de trois chiffres, un
«K» ou un«N» suivi de quatre
chiffres, ou «ZZZ» pour indiquer
l'absence de restriction de vitesse
ata b '-' "ATA" timehhmm Heure d'arrivée effectiveatd b '-' "ATD" timehhmm Heure de départ effective
atot b '-' "ATOT" timehhmm Heure de décollage effective
atsrt b '-' "ATSRT" atsroute point point Indicatif de route ATS et identifi-
cateurs des premier et dernier
points
awr b -' ''AWR'' ''R'' ('1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9')Indicateur de plan de vol de
remplacement suite à l'utilisation
de la fonction «What If reroute» du
CFMU.
R suivi d'unchiffre (1-9)
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Adresses de destination des
messages ATFM2000R2082 — FR — 15.06.2002 — 001.001 — 102
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
ceqpt b '-' "CEQPT" aidequipment Equipement de radiocommunica-
tion, de navigation et d'approche
(case 10 du plande vol OACI)
cfl c '-' "CFL" fl [ptid] Niveau de vol autorisé. Niveau
effectivement assigné par l'ATC au
pilote (expressionn umérique du
niveau de vol)
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointIndication d'un changement des
«règles de vol» (VFR/IFR), du
«type de vol» (OAT/GAT) ou des
deux éléments, avec mention du
point où s'opère le changement
cobd b '-' "COBD" date Date calculée de départ de l'aire de
stationnement
cobt b '-' "COBT" timehhmm Heure calculée de départ de l'aire
de stationnement
com b '-' "COM" text20 Equipement de communication
(case 18, COM/, du plande vol
OACI
comment b '-' "COMMENT" 1 { LIM_CHAR
}Observations d'ordre général en
texte libre, sans tiret
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Identification d'une «condition
exceptionnelle» dans le contexte
ATFM
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]Conditions de transfert de contrôle
d'unvol: iden tificationd'unpoin t,
niveau de vol et estimée d'arrivée
sur le point ; éventuellement,
niveau de vol complémentaire
cop b '-' "COP" point Identificateur de point de coordina-
tion: indicatif codé d'un point ou
désignation artificielle (GEOxx,
RENxx or REFxx)
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Indication d'une croisière ascen-
dante: point d'amorce de la croi-
sière ascendante, vitesse ou nombre
de Mach et les deux niveaux de vol
délimitant la tranche d'altitude
occupée pendant la montée. Le
second niveau (niveau supérieur)
peut être remplacé par «PLUS» s'il
n'est pas connu
cstat c '-' "CSTAT" statid [statreason] Indicateur confirmant le nouveau
statut de coordination d'un vol et
mention facultative du motif du
changement intervenu
ctod b '-' "CTOD" date Date calculée de décollage
ctot b '-' "CTOT" timehhmm Heure calculée de décollage
(CTOT): heure de référence d'un
créneau ATFM
dat b '-' "DAT" datalink Indication des moyens de liaison de
données embarqués
days b '-' "DAYS" numdays Jours d'application d'un plan de vol
répétitif (1234567, où 1 correspond
à lundi, 2 à mardi, etc.; 0 pour les
jours de non-application
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Jours d'applicationd'unplande vol
répétitif, utilisés comme clé de base
de données dans une interrogation,
format joker possible2000R2082 — FR — 15.06.2002 — 001.001 — 103
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
daysold b '-' "DAYSOLD" numdays Jours d'application «précédents»,
utilisés comme clé de base de
données. En cas de modification
des jours d'applicationd'unRPL,
les nouvelles valeurs sont données
sous «DAYS»
dct b '-' "DCT" point point Indique une route directe entre 2
points. Ces points peuvent être
désignés par leur indicatif OACI
officiel ou sous la forme GEOxx,
RENxx or REFxx. (champ GEO,
REN ou REF)
delay b '-' "DELAY" timehhmm Laps de temps correspondant à un
retard. La nature du retard (par ex.
retard imposé à unvol, retard dan s
le traitement, etc.) est tributaire du
contexte
depz b '-' "DEPZ" text20 Nom de l'aérodrome de départ s'il
n'existe pas d'indicateur d'emplace-
ment OACI
desc b '-' "DESC" 1 {LIM_CHAR} Description d'une condition ou
d'une entité en rapport avec le
contenu du message
destz b '-' "DESTZ" text20 Nom de l'aérodrome de destination
s'il n'existe pas d'indicateur
d'emplacement OACI
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedIdentification de la FIR et laps de
temps cumulé (heures et minutes)
jusqu'à la limite de FIR
eetlat c '-' "EETLAT" lattd time Indication du laps de temps écoulé
jusqu'à une position donnée en lati-
tude uniquement
eetlong c '-' "EETLONG" longtd time Indication du laps de temps écoulé
jusqu'à une position donnée en
longitude uniquement
eetpt b '-' "EETPT" point timehhmm_ela-
psedIdentificateur de point et laps de
temps cumulé jusqu'au point
endtime b '-' "ENDTIME" day ! timehhmm Heure à laquelle une période prend
fin
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]Données de plan de vol applicables
au point mentionné ou à l'entrée
dans l'espace aérien considéré.
Mention obligatoire du champ
«ptid» ou 'airspdes', ou des deux
eobd b '-' "EOBD" date Date estimée de départ de l'aire de
stationnement
eobdk b '-' "EOBDK" date Date estimée de départ de l'aire de
stationnement utilisée comme clé
de base de données dans une inter-
rogation, format joker possible. Il
doit s'agir obligatoirement d'une
combinaison de 6 chiffres et carac-
tères joker maximum
eobdold b '-' "EOBDOLD" date «Précédente» date estimée de
départ de l'aire de stationnement,
utilisée comme clé de base de
données. En cas de modification de
la date estimée de départ de l'aire
de stationnement, la nouvelle
valeur sera donnée sous «EOBD»
eobt b '-' "EOBT" timehhmm Heure estimée de départ de l'aire de
stationnement (EOBT)2000R2082 — FR — 15.06.2002 — 001.001 — 104
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Heure estimée de départ de l'aire de
stationnement utilisée comme clé
de base de données dans une inter-
rogation, format joker possible
eobtold b '-' "EOBTOLD" timehhmm «Précédente» heure estimée de
départ de l'aire de stationnement,
utilisée comme clé de base de
données. En cas de modification de
l'heure estimée de départ de l'aire
de stationnement, la nouvelle
valeur sera donnée sous «EOBT»
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Liste des codes des aptitudes
d'équipements suivis chacun par
une valeur d'état indiquant l'état
actuel de l'aptitude
errfield b '-' "ERRFIELD" fieldid Intitulé ADEXP du ou des
champ(s) erroné(s)
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Texte du message d'erreur; peut
éventuellement contenir un code
d'identification d'erreur.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Données d'estimation: identification
d'un point, niveau de vol estimé
(expressionn umérique du FL) et
date-heure estimées de passage à la
verticale du point; éventuellement,
niveau de vol complémentaire
(expressionn umérique du FL
suivie de l'indicateur A ou B)
etod b '-' "ETOD" date Date estimée de décollage
etot b '-' "ETOT timehhmm Heure estimée de décollageextaddr c '-'"EXTADDR" num | { fac } |
(num {fac})Adresses fournies en sus des
adresses sélectionnées automati-
quement. Le champ peut contenir
le nombre d'adresses ou les
adresses proprement dites, ou ces
deux informations
filrte b '-' "FILRTE" {LIM_CHAR} Descriptionde la route exactemen t
telle que déposée, c.-à-d. sans trai-
tement
filtim b '-' "FILTIM" day ! timehhmm Groupe date-heure spécifiant le
moment où le message a été déposé
pour transmissoin
flband c '-' "FLBAND" fl fl Tranche de niveau de vol définis-
sant l'espace aérien dans le sens
vertical, niveaux de vol mentionnés
inclus
fltrul b '-' "FLTRUL" flightrule Règles de vol (case 8 du plande
vol OACI)
flttyp b '-' "FLTTYP" flighttype Type de vol (case 8 du plande vol
OACI)
fmp b '-' "FMP" 4{ ALPHA }4 Identificateur de poste de gestion
des courants de trafic aérien (FMP)
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Liste des FMPs et mesures de
régulationATFM associées
freq b '-' "FREQ" rtf Fréquence radio2000R2082 — FR — 15.06.2002 — 001.001 — 105
▼M1
▼B
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
fstday b '-' "FSTDAY" date Premier jour d'applicationd'unplan
de vol répétitif, utilisé pour indi-
quer à compter de quelle date des
plans de vol seront effectivement
générés à partir d'un RPL (cf.
champ «valfrom») ou à partir de
quand une modification apportée à
unRPL en trera enapplication
furthrte b '-' "FURTHRTE" {LIM_CHAR} Acheminement ultérieur du vol. A
utiliser dans les messages compor-
tant des données d'estimation rela-
tives à l'acheminement du vol après
le point estimé. Ce champ peut ne
mentionner que le point suivant ou
l'itinéraire complet jusqu'à la desti-
nation
geo c '-' "GEO" geoid lattd longtd Point de cheminement défini en
latitude et longitude et indiqué en
format GEOxx sur le plande vol
(xx correspondant à un numéro
d'ordre)
ifp b '-' "IFP" 1{ALPHA} Indication des erreurs connues dans
unFPL
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Liste d'IFPD complètes correspon-
dant à la clé de base de données
dans une interrogation. Liste
d'informations complètes pour
chaque vol correspondant à des clés
d'interrogation données
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Liste d'ifpdsum correspondant à la
clé de base de données dans une
interrogation. Liste d'informations
résumées pour chaque vol corres-
pondant à des clés d'interrogation
données
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8Identificateur unique de plan de vol
assigné par l'IFPS
ifpsmod b '-' "IFPSMOD" fieldid modifind Indication donnée par l'IFPS
concernant les champs modifiés et
la nature des changements
ifpuresp b '-' "IFPURESP" ifpuid Identification de l'IFPU responsable
d'une interrogation. Il lui appartient
de traiter cette interrogation et d'y
répondre
ignore c '-' “BEGIN” "IGNORE" { (condi-
tion| con ditionptid ptid) }'-'
“END” “IGNORE”Indication des conditions «négli-
gées» ou contournées dans le trai-
tement du message considéré. Une
condition «négligée» peut valoir
uniquement pour une portion
spécifique de la route définie par
les points de cheminement donnés.
Un exemple de condition serait une
restrictionhoraire (con dition
d'accès à une route), ou une
restrictionde n iveau de vol ou bien
encore une violation du TOS2000R2082 — FR — 15.06.2002 — 001.001 — 106
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
iobd b '-' "IOBD" date Date «initiale» de départ de l'aire
de stationnement: l'OBD indiquée
sur le FPL et actualisée au moyen
des messages de plande vol asso-
ciés (DLA, CHG, etc.). Il s'agit de
la date de référence utilisée pour
accéder au plande vol dan s la base
de données et de la seule OBD
connue des organismes ATS
concernés. Note: l'IOBD n'est pas
affectée par les modifications
demandées ou notifiées par
échange de messages ATFM
iobt b '-' "IOBT" timehhmm Heure «initiale» de départ de l'aire
de stationnement: l'OBT indiquée
sur le FPL et actualisée au moyen
des messages de plande vol asso-
ciés (DLA, CHG, etc.). Il s'agit de
l'heure de référence utilisée pour
accéder au plande vol dan s la base
de données et de la seule OBT
connue des organismes ATS
concernés.
Note: l'IOBT n'est pas affectée par
les modifications demandées ou
notifiées par échange de messages
ATFM
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Liste des routes conditionnelles
activées
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Liste des zones de ségrégation
temporaire activées
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Liste des routes ATS fermées
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Liste des FIR comprenant le nom
des régions suivi, soit de la liste
des routes conditionnelles disponi-
bles, soit des listes suivantes:
routes conditionnelles disponibles,
routes ATS fermées, zones de
ségrégationtemporaire activées,
restrictions d'espace aérien réduit et
zones à coordination réduite
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Liste des restrictions d'espace
aérienréduit
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Liste des zones à coordination
réduite
lstday b '-' "LSTDAY" date Date ultime d'applicationd'unplan
de vol répétitif: utilisée pour indi-
quer le jour effectif à compter
duquel des plans de vol cesseront
d'être générés à partir d'un RPL (cf.
champ valuntil) ou le dernier jour
d'application d'un amendement
apporté à unRPL
=> obligatoirement une date située
entre VALFROM et VALUNTIL
mach b '-' "MACH" machnumber [ point ] Nombre de Mach, en centièmes et,
facultativement, point où doit
intervenir le changement
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimePériode de validité d'unmessage,
heures mentionnées incluses
minlineup b '-' "MINLINEUP" timehhmm Temps minimum requis pour qu'un
vol «prêt au décollage» passe de sa
positiond'atten te au décollage2000R2082 — FR — 15.06.2002 — 001.001 — 107
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Nombre de rectifications requises
sur le message initial
msgref c '-' "MSGREF" sender recvr
seqnumDonnées de référence pour les
messages associés, transmis précé-
demment
msgsum c '-' "BEGIN" "MSGSUM" [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil]
'-' "END" MSGSUM"Synthèse de message
Note: unou plusieurs champs
arcid, adep, ades, eobt et orgn
doivent obligatoirement figurer
msgtxt b '-' "MSGTXT" icaomsg Contient un message OACI
complet
msgtyp b '-' "MSGTYP" titleid Contient l'intitulé du message cité
enréféren ce ou reproduit. Il peut
s'agir d'unin titulé de message
ADEXP officiel (cf. Annexe B)
nav b '-' "NAV" text20 Renseignements significatifs sur
l'équipement de navigation (case
18, NAV/, du plande vol OACI)
nbarc b '-' "NBARC" 1{ DIGIT }2 Nombre d'aéronefs, si supérieur à
un
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Nombre de données de plan de vol
correspondant à une interrogation:
obligatoirement une valeur entre 0
et 999
newctot b '-' "NEWCTOT" timehhmm Nouvelle heure calculée de décol-
lage, telle qu'actualisée par le
TACT
newend-
timeb '-' "NEWENDTIME" day !
timehhmmNouvelle heure à laquelle une
période prend fin
neweobd b '-' "NEWEOBD" date Nouvelle date estimée de départ de
l'aire de stationnement
neweobt b '-' "NEWEOBT" timehhmm Nouvelle heure estimée de départ
de l'aire de stationnement
newptot b '-' "NEWPTOT" timehhmm Nouvelle heure provisoire de
décollage
newrte b '-' "NEWRTE" { LIM_CHAR } Nouvelle route entre les mêmes
aérodromes de départ et d'arrivée
que ceux du message initial
newstart-
timeb -' “NEWSTARTTIME” day !
timehhmmNouvelle heure de début de période
oldmsg b '-' "OLDMSG" { CHARACTER } Message initial complet tel que
reçu (dans le même format)
opr b '-' "OPR" 1 { LIM_CHAR } Nom de la compagnie ou de
l'exploitant (case 18, OPR/, du plan
de vol OACI
orgmsg b '-' "ORGMSG" titleid Intitulé ADEXP d'un message
erroné reçu par le TACT
orgnb '-' "ORGN" 1{LIM_CHAR}30 Adresse de l'émetteur d'un messageorgnid b '-' "ORGNID" originatorid Indicatif d'un destinataire ayant
émis unmessage
orgrte b '-' "ORGRTE" { LIM_CHAR } Route initiale entre les aérodromes
de départ et d'arrivée
originc '-' "ORIGIN" n etworktype | fac |
(networktype fac)Informations concernant l'émetteur
d'unmessage; peut compren dre le
type de réseau utilisé ou l'adresse
considérée, ou ces deux renseigne-
ments2000R2082 — FR — 15.06.2002 — 001.001 — 108
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
origindt b '-' "ORIGINDT" datetime Date et heure de réception du
message initial par l'IFPS.
Note: il ne s'agit pas de l'heure de
dépôt du message. Format:
AAMMJJHHMM
part c '-' "PART" num lastnum Identification de la partie du
message par l'intitulé, l'heure de
dépôt et la période de validité
per b '-' "PER" text20 Données de performances d'aéronef
(case 18, PER/, du plande vol
OACI)
positionc '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Positiond'unaéron ef exprimée par
unpoin t ou unaérodorme, éven -
tuellement complétée par l'heure et
le niveau de vol
prevarcid b '-' "PREVARCID" aircraftid Indicatif d'appel précédemment
utilisé
prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4Mode et code SSR utilisés par le
vol immédiatement avant les mode
et code SSR spécifiés dans le
champ «-SSRCODE»
propfl c '-' "PROPFL" tfl [sfl] Niveau de vol proposé par l'orga-
nisme accepteur pour le transfert de
contrôle du vol
ptot b '-' "PTOT" timehhmm Heure provisoire de décollage:
heure de référence provisoire pour
uncrén eau ATFM
qrorgn b '-' "QRORGN" originatorid Identificateur de l'émetteur de
l'interrogation
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Nom du ou des aérodrome(s) de
dégagement en route
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Vitesse d'évolution: vitesse ascen-
sionnelle ou vitesse descensionnelle
assignée à un aéronef, exprimée en
centaines de pieds par minute
=> mention obligatoire: «C» pour
vitesse ascensionnelle («climb
rate») ou «D» pour vitesse descen-
sionnelle («descent rate»), suivi
d'unn ombre de deux chiffres
correspondant à la vitesse assignée
en centaines de pieds par minute.
La valeur «ZZZ» peut être utilisée
pour indiquer l'absence de vitesse
assignée.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Liste des périodes et débits associés
pour une condition ATFM
reasonb '-' "REASON" 4{ALPHA}12 Motif du rejet d'un message ou de
l'annulation d'un créneau par le
TACT. L'information à l'appui du
message est tributaire du contexte
ref c '-' "REF" refid ptid brng distnc Point de cheminement défini en
termes de relèvement magnétique
et de distance par rapport à un
autre point et désigné par l'indicatif
REFxx
refdata c '-' "REFDATA" [sender] [recvr]
seqnumDonnées de référence du message
encours de tran smission
reg b '-' "REG" 1{ LIM_CHAR }7 Marques d'immatriculation(case18,
REG/, du plande vol OACI)
regcause b '-' “REGCAUSE” cfmucode iata-
codeRaisonde la régulation , avec deux
indicatifs codés, un pour le code
CFMU, l'autre pour le code IATA2000R2082 — FR — 15.06.2002 — 001.001 — 109
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Localisation de référence d'une
mesure de régulationATFM
regul b '-' "REGUL" regulid Identification d'une mesure de
régulationapplicable à unvol
rejctot b '-' "REJCTOT" timehhmm Heure calculée de décollage
rejetée: réponse négative à une
propositiond'améliorationde
créneau
release b '-' "RELEASE" 1{ALPHA}1 Indication relative au transfert du
vol par le contrôleur transféreur au
contrôleur récepteur:
C = autorisé à monter
D = autorisé à descendre
T = autorisé à virer
F = autorisé à effectuer toutes les
maneouvres
rename c '-' "RENAME" renid ptid Mention d'une nouvelle dénomina-
tion, temporaire, donnée à un
«point significatif» apparaissant
plus d'une fois dans la description
de route, afind'éviter toute con fu-
sion. Cette dénomination tempo-
raire vise uniquement à clarifier la
représentation de la route et
n'implique pas une modifcation
effective de l'identification réelle
du point
respby b '-' "RESPBY" timehhmm Réponse demandée pour: heure à
laquelle une réponse à une propo-
sitiond'améliorationde crén eau
doit être donnée
rfl b '-' "RFL" flightlevel [point] Niveau de vol demandé (expression
numérique du FL, dizaines de
mètres ou centaines de pieds),
complété, facultativement, par le
point auquel le changement de FL
est requis
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Indicateur de plan de vol de
remplacement (RFP) => mention
obligatoire: «Q» suivi d'unchiffre
(1 à 9)
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Liste de RFPD complètes corres-
pondant aux clés de base de
données dans une interrogation
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Liste de rfpdsum (données RFPD
résumées) correspondant aux clés
de base de données dans une inter-
rogation
rif b '-' "RIF 4{LIM_CHAR} Nouvelle route sous réserve d'auto-
risation en vol, terminée par l'indi-
catif OACI du nouvel aérodrome
de destination
rmk b '-' "RMK" 1{ LIM_CHAR } Remarques enlan gage clair (case
18, RMK/, du plande vol OACI
route b '-' "ROUTE" {LIM_CHAR} Intégralité de l'information figurant
encase 15 du plande vol OACI:
vitesse, RFL et route (conforme à
la syntaxe donnée en réf. 4)
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockDescriptiond'uncouran t de trafic
devant être réacheminé
rrteref b '-' "RRTEREF" rrteid Référence du réacheminement
rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockDescriptiond'uncouran t de trafic
vers lequel le trafic doit être
réacheminé2000R2082 — FR — 15.06.2002 — 001.001 — 110
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Liste de points de cheminement;
peut contenir un identificateur
d'aérodrome
rvr b '-' "RVR" 1{ DIGIT }3 Portée visuelle de piste (RVR):
minima requis en cas de conditions
météorologiques particulières.
Exprimée enmètres
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Liste de périodes et minima RVR
applicables
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitPériode pendant laquelle les
minima RVR spécifiés sont
d'application
sector b '-' "SECTOR" 1{ ALPHANUM }8 Identification d'un secteur ATC
sel b '-' "SEL" 4{ ALPHA }5 Code SELCAL (case 18, «SEL/»,
du plande vol OACI
sendto c '-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"Liste des organismes de navigation
destinataires d'un message
seqpt b '-' "SEQPT" ssrequipment Equipement de surveillance (case
10 du plande vol OACI)
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Identification d'une procédure de
départ normalisé aux instruments
speed b '-' "SPEED" spd [ point ] Vitesse vraie (en km/h ou en
noeuds), suivie éventuellement du
point auquel un changement de
vitesse est requis
spla b '-' "SPLA" 1{ LIM_CHAR }50 Couleur des marques significatives
de l'aéronef (case 19, «A/», du plan
de vol OACI)
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Contact pour l'obtention des
données de plan de vol complé-
mentaires
splc b '-' "SPLC" 1{ LIM_CHAR }50 Nom du commandant de bord (case
19, «C/», du plande vol OACI
spldcap b '-' "SPLDCAP" 3{ DIGIT }3 Canots de sauvetage: capacité
totale (case 19, «D/», du plande
vol OACI
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Canots de sauvetage: couleur (case
19, «D/», du plande vol OACI
spldcov b '-' "SPLDCOV" ('T' | 'F') Canots de sauvetage: code préci-
sant s'il s'agit de canots couverts
(case 19, «D/», du plande vol
OACI
T («True») = vrai (=> «C» sur le
plande vol OACI)
F («False») = faux, non couverts
spldnb b '-' "SPLDNB" 2{ DIGIT }2 Canots de sauvetage: nombre (case
19, «D/», du plande vol OACI)
sple b '-' "SPLE" timehhmm_elapsed Autonomie (case 19, «E/», du plan
de vol OACI)
splj b '-' "SPLJ" lifejackets Gilets de sauvetage (case 19, «J/»,
du plande vol OACI)
splnb '-' "SPLN" 1{ LIM_CHAR } Tout autre équipemen t de survie et
remarques utiles (case 19, «N/», du
plande vol OACI)
splp b '-' "SPLP" 1{DIGIT}3 Nombre de personnes à bord (case
19, «P/», du plande vol OACI)
splr b '-' "SPLR" emergradio Radioéquipement de secours (case
19, «R/», du plande vol OACI)
spls b '-' "SPLS" survivaleqpt Equipement de survie (case 19, «S/
», du plande vol OACI)2000R2082 — FR — 15.06.2002 — 001.001 — 111
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Indication de la source de données;
contenu tributaire du champ TITLE
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Soit
— mode et code SSR (case 7, b et
c, du plande vol OACI)
soit
— mention «REQ»ifiant que le
code est demandé
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Identification d'une procédure
d'arrivée normalisée aux instru-
ments
starttime b '-' "STARTTIME" day !
timehhmmHeure de début de période
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Indique, dans la description de
route, une période d'activité
spéciale: l'aéronef va «séjourner»
dans la zone définie par les points
et/ou les aérodromes spécifiés
pendant le laps de temps indiqué
(entraînement, avitaillement en vol,
missionphotographique, etc.)
NOTE: La séquence des points et/
ou aérodromes est significative
stayinfo c '-' "STAYINFO" stayident remark Informations relatives au type
d'activité (entraînement, avitaille-
ment en vol, mission photogra-
phique, etc.) à réaliser au cours de
la période de «séjour» prévue dans
la descriptionde route
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | text20 )Motif du traitement spécial (case
18, «STS» du plande vol OACI).
Mentions possibles:
«PROTECTED» pour indiquer une
prise encharge délicate, codes
officiels (EMER, HOSP, etc.) ou
texte libre
taxitime b '-' "TAXITIME" timehhmm Différence entre l'heure de départ
de l'aire de stationnement et l'heure
de décollage; il peut s'agir des
heures réelles ou estimées, selonle
contexte
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Identification d'un volume de trafic
tfv c '-' "TFV" tfvid refloc flowlst
flblockDescriptiond'unvolume de trafic
title b '-' "TITLE" titleid Intitulé du message
ttleet b '-' "TTLEET" timehhmm_elapsed Durée totale estimée enheures et
minutes
typz b '-' "TYPZ" text20 Type d'aéronef, en l'absence d'un
code OACI
unit c '-' "UNIT" unitid [addrinfo] Informations relatives à une unité
de navigation aérienne: organisme
ATC, exploitant d'aéronefs ou
émetteur d'un plan de vol; contient
l'identification de l'unité, suivie,
facultativement, de son adresse
valfrom b '-' "VALFROM" date Première date prévue d'exploitation
du vol (année, mois, jour)2000R2082 — FR — 15.06.2002 — 001.001 — 112
▼B
Champ
primaire
ADEXPType Syntaxe Sémantique
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Première date prévue d'exploitation
du vol utilisée comme clé de base
de données dans une interrogation,
format joker possible.
Il doit s'agir d'une date correcte ou
d'une combinaison date correcte —
caractères joker
valfromold b '-' "VALFROMOLD" date Date «valfrom»«précédente»
utilisée comme clé de base de
données. En cas de modification de
la date de début de validité, la
nouvelle valeur sera donnée sous
«VALFROM»
validitydate b '-' "VALIDITYDATE" date Date de validité
valuntil b '-' "VALUNTIL" date Date ultime d'exploitation prévue
du vol (année, mois, jour)
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Date ultime d'exploitationprévue
du vol utilisée comme clé de base
de données dans une interrogation,
format joker possible.
Il doit s'agir obligatoirement d'une
date correcte ou d'une combinaison
date correcte — caractères joker
valuntilold b '-' "VALUNTILOLD" date Date «valuntil»«précédente»
utilisée comme clé de base de
données. En cas de modification de
la date ultime de validité, la
nouvelle valeur sera donnée sous
«VALUNTIL»
wktrc b '-' "WKTRC" waketurbcat Catégorie de turbulence de sillage
A.4.Sous-champsADEXP
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
addrinfo c '-' "ADDRINFO"
networktype facAdresse unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'Indicatif d'aérodrome:
indicateur d'emplace-
ment OACI ou
mention «ZZZZ» en
l'absence d'un indica-
teur d'emplacementad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Descriptionin tégrale
ou partielle de route
ATS pendant une
période spécifiéelacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Descriptionin tégrale
ou partielle d'espace
aérien pendant une
période spécifiéelatsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Désigne un espace
aérienautre qu'un e
route ATSentrydata airspace
brng b '-' "BRNG"
refbearingRelèvement d'un
point par rapport à
une aide à la naviga-
tion(endegrés
magnétiques)ref2000R2082 — FR — 15.06.2002 — 001.001 — 113
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
condition b '-' "CONDITION" 2
{ALPHA} 20Type de condition ou
de restriction: par
ex.: TOS, restriction
FLignore
crfl1 b '-' "CRFL1" flight-
levelLimite inférieure de
la tranche d'altitude
au seinde laquelle
doit s'opérer une
croisière ascendantecrsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")Limite supérieure de
la tranche d'altitude
au seinde laquelle
doit s'opérer une
croisière ascendante;
mention «PLUS» si
la limite supérieure
n'est pas connuecrsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberNombre de Mach à
maintenir pendant la
croisière ascendantecrsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd Vitesse à maintenir
pendant la croisière
ascendantecrsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Heure calculée de
passage à la verticale
d'unpoin tad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Distance d'un point
par rapport à une aide
à la navigation, en
milles nautiques => 1
à 3 chiffres, le cas
échéant avec inser-
tionde zéros entêteref
efl b '-' "EFL" flightlevel Niveau de vol estimé Reservé
pour une
utilisation
future
endreg b '-' "ENDREG" day!ti-
mehhmmHeure à laquelle une
mesure de régulation
ATFM prend finexccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusCode d'aptitude d'un
équipement suivi par
une valeur d'état
indiquant l'état actuel
de l'aptitudeeqcst
eto b '-' "ETO" date !
timehhmm ! secondsEstimée de passage à
la verticale d'un
point, exprimée en
année, mois, jour,
heures, minutes et
secondesad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreasonstartreg
endreg [flblock]
[rvrlimit] [remark]«Condition excep-
tionnelle» dans le
contexte ATFM, par
ex.: brouillard sur un
aérodromereglist
fac b '-' "FAC" 1{
LIM_CHAR }30Données d'adressage addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Désigne une FIR ou
une UIRlfir2000R2082 — FR — 15.06.2002 — 001.001 — 114
▼M1
▼B
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
fl b '-' " FL" flightlevel Champ générique de
niveau de vol;
mention «SFL»,
«EFL», «CFL»,
«RFL», etc. selonle
contextead
afildata
cfl
entrydata
estdata
flband
positionflblock
pt
flblock c '-' "FLBLOCK" fl fl Bloc de niveaux de
vol définissant un
espace aériendan s le
planvertical, n iveauxspécifiés inclus. Tout
bloc défini comme se
situant au-dessous ou
au-dessus d'unn iveau
de vol donné
s'exprime par la
mention «du niveau
de vol 000 au niveau
spécifié» ou «du
niveau de vol spécifié
au niveau de vol
999»ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulationexccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleDescriptiond'un
courant: mention de
la zone d'origine, des
routes ou points de
survol depuis la zone
d'origine (facultatif),
de la zone de desti-
nation et des routes
ou points de survol
jusqu'à la zone de
destination (facul-
tatif)flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Liste de courants de
traficrrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7Débit imposé par une
mesure de régulation
ATFMrateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Indication du «rôle»
assigné à un courant
EX = exclusi
IE = inclus exempté
EM = exemptéIN = inclusflow
from b '-' "FROM" day!ti-
mehhmmHeure de début de
périodervrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15Positionà partir de
laquelle commence
une route, une
portionde route, un
itinéraire ou un
courant.
Peut être une région,
unaérodrome ou un
point significatif.flow
geoid b '-' "GEOID" geoname Identification d'un
point géographique:
«GEO» suivi d'un
numéro d'ordre (par
ex.: "GEO12")geo
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Information complète
sur unplande vol
individuelifpdlist2000R2082 — FR — 15.06.2002 — 001.001 — 115
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnInformation résumée
sur unplande vol
individuel; contient
les champs arcid,
adep, ades, eobt et
orgnifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Nombre de trois chif-
fres indiquant la fin
d'une séquence
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitude exprimée en
degrés, minutes et
secondes (nord ou
sud)eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitude exprimée
endegrés, min utes et
secondes (est ou
ouest)eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Indication du type de
réseau utilisé pour un
échange de messagesoriginaddrin fo
num b '-' "NUM"
3{DIGIT}3Nombre de trois chif-
fresextaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7Débit d'attente utilisé
pour les besoins de
l'ATFMrateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgContient un message
ADEXP complet,
après traitementadexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgContient un message
ADEXP complet,
avant traitement (tel
que reçu)adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach) ]
[ptcrsclimb]Point de chemine-
ment
=> contient une iden-
tificationdu poin t et,
facultativement:
— unn iveau de vol
ou bloc de FL,
— unn iveau de vol
complémentaire,
— une ou des réfé-
rence(s) horaire(s),
— une croisière
ascendante,
— une indication de
cheminement,
— une indication de
période d'activité
spéciale («séjour»
prévu du vol dans la
zone pendant une
période donnée
Modification:
— RFL, règles de
vol, vit./nbre Machrtepts2000R2082 — FR — 15.06.2002 — 001.001 — 116
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Indication d'une croi-
sière ascendante dans
la descriptionde
route: vitesse ou
nombre de Mach,
suivi des deux
niveaux de vol
correspondant à la
tranche d'altitude
occupée pendant la
montée. Le second
niveau (supérieur)
peut être remplacé
par «PLUS» s'il n'est
pas connupt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Règles de vol appli-
cables au point
considéréentrydata
ptid b '-' "PTID" point Identification d'un
point: indicatif codé
ou désignation artifi-
cielle (GEOxx,
REFxx ou RENxx)afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberNombre de Mach, en
centièmes, associé à
un point de chemine-
mentad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Mention des règles
de vol militaires
applicables au point
considéréentrydata
ptrfl b '-' "PTRFL" flight-
levelNiveau de vol
demandé, associé à
un point de chemine-
mentad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}Route suivie par le
vol après le point
spécifié; il peut s'agir
de l'intégralité de la
route jusqu'à la desti-
nation ou de la
portionde routejusqu'au point suivantpt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgIndication d'une
modificationdes
«règles de vol» VFR/
IFR) ou du «type de
vol» (OAT/GAT), ou
de ces deux éléments,
associée à unpoin t
de cheminementad pt
ptspeed b '-' "PTSPEED" spd Vitesse vraie (enkm/
h ou enn œuds),
associée à unpoin t
de cheminementad
entrydatapt2000R2082 — FR — 15.06.2002 — 001.001 — 117
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmIndique, dans la
descriptionde route,
une période d'activité
spéciale: l'aéronef va
«séjourner» dans la
zone définie pendant
le laps de temps
indiqué (entraîne-
ment, avitaillement
envol, etc.)ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penratePériode pendant
laquelle les débits
spécifiés sont d'appli-
cationpour un e
mesure de régulation
ATFMratepdlst regcond
recvr b '-' "RECVR" fac Récepteur du
message cité enréfé-
rencemsgref
refdata
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]Indicatif de route
ATS et identifica-
teurs des premier et
dernier points. Les
points énumérés
peuvent être des
identificateurs OACI
ou des points
GEOxx, RENxx ou
REFxx désignés arti-
ficiellement. L'identi-
ficationdu pays où se
situe le point peut
éventuellement
figurer. Le dernier
point doit être
conforme à l'informa-
tionde routeairroute
refid b '-' "REFID" refname Identification d'un
point de référence:
«REF» suivi d'un
numéro d'ordre
(exemple: «REF02»)ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Localisationde réfé-
rence d'une mesure
de régulationATFMrrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" ratepe-
riod '-' "END"
"REGCOND"Liste des périodes et
débits associés pour
une mesure de régu-
lationparticulièreregulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Descriptiond'un e
mesure de régulation
ATFMregulation
regid b '-' "REGID" regulid Identification d'une
mesure de régulation
de gestiondes cou-
rantsregulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion[exccon d] '-'
"END" "REGLIST"Liste de mesures de
régulationà des fin s
de gestiondes cou-
rantsfmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Numéro de référence
d'une mesure de
régulationATFM:
référence unique
suivie d'une indica-
tionde la période de
validitéexccond
regulation2000R2082 — FR — 15.06.2002 — 001.001 — 118
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
regreasonb '-' "REGREASON" 4
{ALPHA} 12Motif d'une mesure
de régulationATFMexccond
regulation
regulationc '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]Mesure de régulation
imposée pour les
besoins de la gestion
des courantsreglist
remark b '-' "REMARK"
1{LIM_CHAR}Remarque concernant
un élément donné: ce
champ fait partie de
la descriptiondudit
élémentstayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identification d'un
point apparaissant
plusieurs fois dans la
descriptionde routerename
respunit b '-' "RESPUNIT"
12{ALPHA}12Organisme ATC
compétentairspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
adexpmsg '-' "END"
"RFPDLONG"Information complète
sur unplande vol
répétitifrfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilInformation résumée
sur unplande vol
répétitif; contient les
champs arcid, adep,
ades, eobt, orgn,
days, valfrom et
valuntilrfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Portée visuelle de
piste (RVR): minima
requis encas de
conditions météorolo-
giques particulières.
Exprimée enmètresrvrperiod exccond
sender b '-' "SENDER" fac Emetteur du message
cité enréféren cemsgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Numéro d'ordre du
message envoyé
(nombre de trois
chiffres unique pour
la combinaison émet-
teur/récepteur)msgref
refdata
sfl b '-' SFL flightlevel !
('A'|'B')Niveau de vol
complémentaire:
niveau de vol auquel
ou au-dessus duquel,
ou auquel ou au-
dessous duquel un
vol a été ou sera
coordonné pour le
franchissement d'un
point. Comporte le
niveau de vol et une
condition de fran-
chissement («A» si le
franchissement
s'effectuera au niveau
donné ou à un niveau
supérieur; «B» si le
franchissement
s'effectuera au niveau
donné ou à un niveau
inférieur)coordata
estdata
propflpt2000R2082 — FR — 15.06.2002 — 001.001 — 119
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
startreg b '-' "STARTREG"
day!timehhmmHeure à laquelle une
mesure de régulation
ATFM entre en
vigueurexccond
regulation
statid b '-' "STATID" coorsta-
tusidentIndication du statut
de coordination d'un
volcstat
statreasonb '-' "STATREASON"
coorstatusreasonMotif du changement
intervenu dans le
statut de coordination
d'unvolcstat
stayident b '-' "STAYIDENT"
stayidentifierIdentification d'une
période d'activité
spéciale ou d'un
«séjour» dans la
descriptionde routestay
stayinfo
sto b '-' "STO" timehhmm
! secondsChamp «time» géné-
rique pouvant
contenir l'heure
d'arrivée sur unpoin t
ou unaérodrome. Il
peut s'agir, selonle
contexte, d'une heure
estimée, calculée ou
effectivead
coordata
positionpt
tfl b '-' "TFL" flightlevel Niveau de transfert
de contrôle: niveau
auquel unvol a été
ou sera coordonné
pour le passage d'un
point (niveau
exprimé enchiffres),
s'il s'agit de la phase
de vol enpalier; ou
niveau de vol auto-
risé vers lequel le vol
se dirige s'il est en
phase de montée ou
descente au point de
transfertcoordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identification d'un
volume de traficrrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Indication de l'heure.
Il peut s'agir d'une
heure effective ou
d'une période, selon
le contexte du
messagestay
to b '-' "TO" timehhmm «Time Over/Off».
Champ générique
pouvant contenir
l'heure d'arrivée sur
unpoin t ou unaéro-
drome. Il peut s'agir
d'une heure estimée,
calculée ou effective
selonle con texteposition
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15Positionà laquelle
prend fin une route,
une portion de route,
unitin éraire ou un
courant.
Il peut s'agir d'une
région, d'un aéro-
drome ou d'unpoin t
significatifflow2000R2082 — FR — 15.06.2002 — 001.001 — 120
▼B
Sous-
champType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
unitid b '-' "UNITID" 2{
ALPHANUM}10Identification d'une
unité de navigation
aérienne, par
exemple: unorga-
nisme ATC, un
exploitant d'aéronefs
ou unémetteur de
plande volunit
until b '-' "UNTIL" day!ti-
mehhmmHeure de finde
périodervrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timePériode de validité,
heures mentionnées
inclusesairroute
airspace
via1 b '-' "VIA1" 1
{ALPHANUM} 15Point, route ATS ou
espace aérienfiguran t
ou devant figurer surla route du vol. Si
plus d'unélémen t
doit être indiqué, ce
champ contiendra le
premier élément de la
séquenceflow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Point, route ATS ou
espace aérienfiguran t
ou devant figurer sur
la route du vol. Si
plus d'unélémen t
doit être indiqué, ce
champ contiendra le
deuxième élément de
la séquenceflow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Point, route ATS ou
espace aérienfiguran t
ou devant figurer sur
la route du vol. Si
plus d'unélémen t
doit être indiqué, ce
champ contiendra le
troisième élément de
la séquenceflow
via4 b '-' "VIA4" 1
{ALPHANUM} 15Point, route ATS ou
espace aérienfiguran t
ou devant figurer sur
la route du vol. Si
plus d'unélémen t
doit être indiqué, ce
champ contiendra le
quatrième élément de
la séquenceflow2000R2082 — FR — 15.06.2002 — 001.001 — 121
▼B
ANNEXE B (Normative)
INDEX CENTRAL DES INTITULÉSDE MESSAGE ADEXP
Intitulé DéfinitionMentionné à la
Section
ABI Préavis de franchissement de limite E.3
ACK Accusé de réceptionE.1
ACP AcceptationE.5
ACT ActivationE.3
AUP Pland'utilisationde l'espace aérien E.4
BFD Données de vol de base E.5
CDN Coordination E.3
CFD Modification des données de vol E.5
CNLCOND Annulation de condition exceptionnelle ATFM E.2.3
CNLREG Annulation de régulation ATFM E.2.3
COD Assignation de codes SSR E.3
COF Changement de fréquence E.3
CRAM Disponibilité/indisponibilité de route conditionnelle E.4
DES Levée de suspension E.2.2
ERR Erreur E.2.2
EXCOND Notification de condition exceptionnelle ATFM E.2.3
FCM Confirmation de vol E.2.2
FLS Suspension de vol E.2.2
FSA Première activationE.2.3HOP Propositionde tran sfert E.3
IACH ModificationATC in dividuelle E.1
IAFP Propositionde plande vol ATC in dividuel E.1
IAPL Plande vol ATC in dividuel E.1
IARR Arrivée individuelle E.1
ICHG Modificationin dividuelle E.1
ICNL Annulation individuelle E.1
IDEP Départ individuel E.1
IDLA Retard individuel E.1
IFPL Plande vol in dividuel E.1
INF Information E.3
IRPL Plan de vol répétitif interne E.1
IRQS Demande de plan de vol individuel complémentaire E.1
ISPL Plan de vol individuel complémentaire E.1
LAM Accusé de réceptionlogique E.5
LRM Rejet logique E.3
MAC Abrogationde coordin ation E.3
MAN En attente de traitement manuel E.1
MAS Prise en charge manuelle des communications E.3
MODCOND Modification de condition exceptionnelle ATFM E.2.3
MODREG Modificationde régulationATFM E.2.3MRA Activationde route obligatoire E.2.3
MRCNL Annulation de route obligatoire E.2.3
MRMOD Modificationde route obligatoire E.2.3
NEWREG Notificationde n ouvelle régulationATFM E.2.32000R2082 — FR — 15.06.2002 — 001.001 — 122
▼B
Intitulé DéfinitionMentionné à la
Section
NTA Non-acceptation de trafic E.2.3
NTACNL Annulation de non-acceptation de trafic E.2.3
NTAMOD Modification de non-acceptation de trafic E.2.3
OLRA Activationd'itin éraire de délestage E.2.3
OLRCNL Annulation d'itinéraire de délestage E.2.3OLRMOD Modificationd'itin éraire de délestage E.2.3
PAC Activationprélimin aire E.3
RAP Renvoi à une proposition d'activation E.3
RCHG Modification de données de plan de vol répétitif E.1
RCNL Annulation de données de plan de vol répétitif E.1
RDY Prêt au départ E.2.2
REJ Rejet E.1
REV RévisionE.3
RJC Rejet de coordination E.5
RJT Rejet de réacheminement E.2.2
ROF Demande de renseignement sur les fréquences E.3
RRP Proposition de réacheminement E.2.2
RRV Renvoi à une proposition de révision E.3
SAM Allocationde crén eau E.2.2
SBY Stand-by E.3
SDM Données complémentaires E.3
SIP Propositiond'améliorationde crén eau E.2.2
SLC Annulation de demande de créneau E.2.2
SMM Créneau manqué E.2.2
SPA Acceptationde propositionde crén eau E.2.2
SRJ Rejet de propositionde crén eau E.2.2SRM Révisionde crén eau E.2.2
SRR Demande de révision de créneau E.2.2
TIM Amorce de transfert E.3
UUP Actualisationde pland'utilisationde l'espace aérien E.4
XAP Autre propositionde traversée E.5
XCM Annulation de traversée E.5
XIN Notification d'intention de traversée E.5
XRQ Demande de traversée E.52000R2082 — FR — 15.06.2002 — 001.001 — 123
▼B
ANNEXE C (Normative)
INDEX CENTRAL DES INTITULESDE MESSAGE RESERVES
C.1.Introduction
La présente annexe comporte un index central des intitulés de message
réservés, qui n'ont pas encore été définis pour être utilisés en ADEXP.
Le fait que ces messages figurent dans la présente annexe signifie qu'ils
sont appelés à être utilisés dans l'avenir ou qu'ils le sont déjà, mais à
l'échelon local uniquement.
C.2.Objet
L'établissement d'une liste des intitulés n'ayant pas encore été adoptés
officiellement aux fins d'utilisation dans le cadre de la présente Norme
ADEXP vise à prévenir, dans toute la mesure possible, les risques de
redondance, lorsqu'un nouvel intitulé est requis pour un besoin particu-
lier, ou l'adoptiond'unin titulé déjà utilisé au seind'unsystème local.
C.3.Intitulés de messages réservés
Intitulé réservé Type de message Réservé par
ACTARR Message d'activationpour un e arrivée FRANCE
ACTDEP Message d'activationpour undépart FRANCE
ADMFPL ADMAR2000 Message Plande Vol GERMANY
ADMFPT ADMAR2000 Message finde plande vol GERMANY
ADMFPU ADMAR2000 Message mise à jour plande vol GERMANY
ANM Message de notification ATFM CFMU
ANSWERCT Message de réponse FRANCEANSWM Message de réponse FRANCE
ANSXFPLCT Message de réponse FRANCE
ATT Message d'atterrissage FRANCE
BEGINPROC Message de début de traitement FRANCE
BEGPROC Message de procedure d'initialisation de la position de
tarvail du controleur (ODS)FRANCE
BEGPROCCT Message de procedure d'initialisation de la position de
tarvail du controleur (Système de contrôle terminal)FRANCE
CDA Message d'autorisationde départ (ARINC 623) FRANCE
CDAFTX Autorisationde départ (ARINC 620) FRANCE
CHGDEP Message de modificationd'unvol au départ FRANCE
CLD Autorisationde départ (ARINC 623) FRANCE
CLDFTX Autorisationde départ (ARINC620) FRANCE
CNLARR Annulation d'une arrivée FRANCE
CNLCOND Annulation de conditions exceptionnelles CFMU
CNLDEP Annulation d'un départ FRANCE
CNLREG Annulation d'une régulation ATFM CFMU
CONFEND Message terminal d'une modification de configuration
opérationnelleFRANCE
CONFIDM Message de configuration opérationnelle FRANCE
CONFIDMCT Message de configuration opérationnelle FRANCE
DEC Envol FRANCE
DOUBM Message de plande vol endouble FRANCEDRT Message de modificationde destin ation FRANCE
EATARR Message d'atterrissage FRANCE
ENDPROC Finde traitemen t FRANCE
ENDPROCCT Finde traitemen t FRANCE2000R2082 — FR — 15.06.2002 — 001.001 — 124
▼B
Intitulé réservé Type de message Réservé par
EVLARR Message de préactivationpour un e arrivée FRANCE
EVLDEP Message de préactivationpour undépart FRANCEEXCOND Activation d'une condition exceptionnelle CFMUFICM Message de fichier de données de vol FRANCEFLXVIVO Message de visualisationde descriptiond'itin éraire
flexibleFRANCE
FPCLOSE Message de clôture de données de plan de vol FRANCE
FPCLOSECT Message de clôture de données de plan de vol (Systeme
de Contrôle terminal)FRANCE
FPCLOSED Duplication du Message de clôture de données de plan
de vol (ODS)FRANCE
FPCRD Message de données de plan de vol FRANCE
FPCRDCT Message de données de plan de vol FRANCEFPCRDD Dulicationdu message d'activationdu plande vol
(ODS)FRANCE
FPCRE Message de données de plan de vol FRANCE
FPCRECT Message de données de plan de vol FRANCEFPINI Message de préactivationde plande vol FRANCEFPINICT Message de préactivationde plande vol FRANCEFPINID Duplicationde message de préactivationde plande vol FRANCE
FPNTF Message de préactivationde plande vol FRANCE
FPNTFD Duplicationde message de préactivationde plande vol FRANCEFPRDU Informations de vol pour un secteur non actif FRANCEFPRDUCT Message d'information des données plan de vol pour un
secteur non concerné (Système de contrôle terminal)FRANCE
FSM Message système (ARINC 623) FRANCE
FSMFTX Message système (ARINC 620) FRANCE
FSR Demande de suspension de vol CFMUIACHD Message de modificationATC in dividuel GERMANYICHGD Message de modificationin dividuel GERMANYIDEPD Message de déaprt individuel GERMANYIDLAD Message de délai individuel GERMANYIFPDQ Interrogation de données de plan de vol individuel CFMUIFPDQR Réponse à une interrogation de données de plan de vol
individuelCFMU
IFPDSQ Interrogation de résumé de données de plan de vol indi-
viduelCFMU
IFPDSQR Réponse à une interrogation de résumé de données de
plande vol in dividuelCFMU
IFPLD Plande vol in dividuel GERMANY
INFOM Message d'information FRANCE
IRQS Message de demande d'information supplémentaire
individuelCFMU
ISPL Message de plan de vol supplémentaire individuel CFMU
LGR Liste de messages de plande vol FRANCELISTFP Liste de messages de plande vol FRANCE
LISTFPCT Liste de messages de plande vol FRANCE
LOGON Identification de message de plan de vol FRANCEMAJVIVO Mouvements journaliers FRANCEMCOM Message de coordination FRANCEMODCOND Modification d'une condition exceptionnelle CFMU2000R2082 — FR — 15.06.2002 — 001.001 — 125
▼B
Intitulé réservé Type de message Réservé par
MODREG Modificationd'un e régulationATFM CFMU
MRA Actiavtiond'un e route obligatoire CFMUMRCNL Annulation d'une route obligatoire CFMUMRMOD Modificationd'un e route obligatoire CFMUMRR Message de réacheminement obligatoire CFMUMVTVIVO Informations sur les mouvements FRANCENEWREG Activationd'un e régulation CFMUNTA Activationd'unflux de trafic n onpermis CFMU
NTACNL Annulation d'un flux de traffic non permis CFMU
NTAMOD Modificationd'unflux de traffic n onpermis CFMUOCLM Message d'autorisationocéan ique FRANCEOCLMD Duplicationde message d'autorisationocéan ique FRANCEOLRA Activation d'une route de débordement CFMUOLRCNL Annulation d'une route de débordement CFMUOLRMOD Modification d'une route de débordement CFMUPAMAER Message d'applicabilité de piste FRANCEPAMARB Message de confirmation «sur poste de stationnement» FRANCE
PAMARRANN Annulation d'attribution de poste de stationnement pour
une arrivéeFRANCE
PAMARRCRE Attribution de poste de stationnement pour une arrivée FRANCE
PAMARRPST Modification d'attribution de poste de stationnement
pour une arrivéeFRANCE
PAMDAPARB Message de stationnement pour aéronef à l'arrivée FRANCE
PAMDAPCRE Réattribution de poste de stationnement FRANCEPAMDEPANN Annulation d'attribution de poste de stationnement pour
undépartFRANCE
PAMDEPCRE Attribution de poste de stationnement pour un départ FRANCE
PAMDEPPST Modification d'attribution de poste de stationnement
pour undépartFRANCE
PAMDRB Message de confirmation «hors poste de stationnement» FRANCE
QTAARR Retour à l'état initial de non-préactivation pour une
arrivéeFRANCE
QTADEP Retour à l'état initial de non-préactivation pour un
départFRANCE
RCD Demande d'autorisation de départ (AIRINC 623) FRANCE
RCDFTX Demande d'autorisation de départ (AIRINC 620) FRANCEREVARR Message de révisionpour un e arrivée FRANCERFPDQ Interrogation de données de plan de vol répétitif CFMURFPDQR Réponse à une interrogation de données de plan de vol
répétitifCFMU
RFPDSQ Interrogation de résumé de données de plan de vol
répétitifCFMU
RFPDSQR Réponse à une interrogation de résumé de plan de vol
répétitifCFMU
RIEM Informations de vol FRANCE
RMG Message d'approche manquée FRANCE
RRA Message d'acceptation de réacheminement CFMU
RREC Message de reprise de plande vol répétitif CFMURRN Message de notification de réacheminement CFMURSUS Message de suspension de plan de vol répétitif CFMURWYCHGCT Message de configuration des pistes FRANCE2000R2082 — FR — 15.06.2002 — 001.001 — 126
▼B
Intitulé réservé Type de message Réservé par
TRACT Demande d'activation de plan de vol FRANCE
TRACTCT Demande d'activation de plan de vol FRANCE
TRCNL Demande d'annulation de plan de vol FRANCE
TRCNLCT Demande d'annulation de plan de vol FRANCE
TRCOR Demande de corrélation manuelle FRANCE
TRDECOR Demande de décorrélation manuelle FRANCE
TRFIC Demande de données FRANCE
TRFICCT Demande de données FRANCE
TRFLRQT Demande de niveau de vol FRANCE
TRMOD Demande de modification de plan de vol FRANCE
TRMODCT Demande de modification de plan de vol FRANCE
TRMODH Demand de modification de temps FRANCE
TRMODHD Demande de modification de l'heure pour un vol retardé FRANCE
TRMVT Demande de coordination pour un vol sortant FRANCE
TRMVTCT Demande de coordination pour un vol sortant FRANCE
TRPOINT Demande de données de vol spécifiques FRANCE
TRRET Demande de précisions sur les données de vol initiales FRANCE
TRRETCT Demande de précisions sur les données de vol initiales FRANCETRRIP Demande de réimpression de bande de progression de
volFRANCE
TRRIPCT Demande de réimpression de bande de progression de
volFRANCE
TRRQT Demande de plan de vol FRANCE
TRRQTCT Demande de plan de vol FRANCE
TRSHRQT Message de changement de fréquence FRANCE
TRSTAR Message de retour enarrière FRANCE
TRSTARCT Message de retour enarrière FRANCE
TRTRP Message de positionde tran sfert FRANCE
UNKFP Message de suppressionde plande vol FRANCE
UNKFPCT Message de suppressionde plande vol FRANCE2000R2082 — FR — 15.06.2002 — 001.001 — 127
▼B
ANNEXE D (Normative)
INDEX CENTRALDES CHAMPS RESERVES
D.1.Introduction
La présente annexe comporte un index central des champs réservés —
champs primaires, sous-champs et termes auxiliaires — qui n'ont pas
encore été définis pour être utilisés en ADEXP. Leur inclusion dans la
présente annexe signifie qu'ils sont appelés à être utilisés dans l'avenir
ou qu'ils le sont déjà, mais à l'échelon local uniquement.
D.2.Objet
L'établissement d'une liste des champs n'ayant pas encore été adoptés
officiellement aux fins d'utilisation dans le cadre de la présente Norme
ADEXP vise à prévenir, dans toute la mesure possible, les risques de
redondance, lorsqu'un nouveau champ est requis pour un besoin particu-
lier, ou l'adoptiond'unmot-clé déjà utilisé au seind'unsystème local.
D.3.Termes auxiliaires réservés
Terme auxi-
liaire réservéSyntaxe SémantiqueUtilisé dans
champ
primaireUtilisé dans
sous-champUtilisé
en
élément
auxi-
liaire
centreidentifi-
cation1{ALPHA}4 Identification du
centrectsrc
ripsrc
ctripectdest
contextfdpsid 'OPEPAL' |
'OPESOS' |
'EVALPAL' |
'TSTOPEPAL' |
'TSTOPESOS'Mode de fonc-
tionnement d'une
applicationFDPS
(exploitation, test,
etc.)ctxtfdps
contextphi-
diasid'OPE'|'EVA-
L1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Spécifique au
système françaisctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Point d'entrée
pour le poste de
contrôle («E»).
Point de sortie
pour le poste de
contrôle («S»),
Point XFL (X),
Point OCL (O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Identification
d'une «unité
opérationnelle»eosrc eoid
fl3 'F' ! 3{DIGIT}3 Niveau de vol
exprimé en
centaines de piedsautfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Tendance
projetée du profil
de vol
U pour UPD pour DOWNS pour STABLEetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Statut du plande
vol au seind'un
CCRfpctst2000R2082 — FR — 15.06.2002 — 001.001 — 128
▼B
Terme auxi-
liaire réservéSyntaxe SémantiqueUtilisé dans
champ
primaireUtilisé dans
sous-champUtilisé
en
élément
auxi-
liaire
latitude 4{ DIGIT }4 Latitude exprimée
enquatre chiffres
latitudeshort 2{ DIGIT }2 Latitude exprimée
endeux chiffresRéservé à un
usage futur
longitude 5{ DIGIT }5 Longitude
exprimée encin q
chiffresRéservé à un
usage futur
longitudes-
hort3{ DIGIT }3 Longitude
exprimée entrois
chiffresRéservé à un
usage futur
pointcautra 1{ALPHANU-
M}5Spécifique au
système françaisfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Poste de travail
effectif ou
logiqueposid
qfuid (‘0'|'1'|'2'|'3')!1{D-
IGIT }1!(‘L'|'C'
|'R'|NIL)QFU pour une
piste
L = gauche (left)C= centre
R = droit (right)qfu qful
secidentifica-
tion1{ALPHANU-
M}2Identification du
secteursecdest
secsrcsecid
sendin-
greason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|'MVTSEC'|'COO-
RAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'I-
NIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|
'PKG'Motif de l'envoi
des données de
plande volevent
starreason'TOTAL' Type d'in itialisa-
tiond'unposte au
moyendes
données de plan
de volstreason
temperature ("N" | "P") !
2{DIGIT}2Température
exprimée en
degrés Celsius
(00-99) avec indi-
cationdu sign e
(négatif ou
positif)temp2000R2082 — FR — 15.06.2002 — 001.001 — 129
▼B
Terme auxi-
liaire réservéSyntaxe SémantiqueUtilisé dans
champ
primaireUtilisé dans
sous-champUtilisé
en
élément
auxi-
liaire
updatereason('T'!('R'|NIL)|'R') Type de mise à
jour dernièrement
apportée à une
donnée de vol:
transaction opéra-
teur («T»), mise à
jour radar («R»).udpt
D.4.Champs primaires réservés
Champ
primaire
réservéType Syntaxe Sémantique
aabd b '-' "AABD" date Date effective arrivée sur aire de
stationnement
aabt b '-' "AABT" timehhmm Heure effective arrivée sur aire de
stationnement
acnf c '-' "ACNF" ad rcnf [qfulist] Configuration des pistes
aobd b '-' "AOBD" date Date effective départ de l'aire de
stationnement
aobt b '-' "AOBT" timehhmm Heure effective départ de l'aire de
stationnement
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Type d'approche du vol (1 chiffre,
val.: 1, 2, 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Identification d'aéronef utilisée par
les exploitants
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Numéro d'identification d'aéronef
unique utilisé localement par l'ATC
atis b '-' "ATIS" 1{ALPHA}1 Indicateur du service automatique
d'information terminale
autfl1 b '-' "AUTFL1" fl3 Niveau de vol autorisé no1
autfl2 b '-' "AUTFL2" fl3 Niveau de vol autorisé no2
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Données à transmettre dans un
message de coordination: heured'émission, point de sortie, niveau
de vol au point de sortie, niveau de
vol prévu et mention précisant si ce
niveau est conforme ou non aux
conventions
avail b '-' "AVAIL" 'YES'|'NO' Mention précisant si un secteur est
autorisé ou non à modifier une
donnée de plan de vol
bkrow b '-' "BKROW" 1{DIGIT}2 Position d'un point dans une liste
de points de cheminement
bkt b '-' "BKT" datetime Heure de passage à la verticale du
point de référence pour une trans-
action
codetr b '-' "CODETR" 'YES'|'NO' Mention précisant si le code SSR
doit être ou non transmis au pilote
par le poste de contrôle
confid b '-' "CONFID" 1{DIGIT}5 Identification de configuration
opérationnelle (secteurs|postes)
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"Liste des associations secteurs/
postes pour un centre de contrôle
de route
crspd b '-' "CRSPD" 1{DIGIT}4 Vitesse de croisière enn œuds2000R2082 — FR — 15.06.2002 — 001.001 — 130
▼B
Champ
primaire
réservéType Syntaxe Sémantique
ctripe b '-' "CTRIPE" centreidentification Identification du centre récepteur
pour transaction
ctrow b '-' "CTROW" 1{DIGIT}1 Position d'un centre dans une liste
de centres
ctsrc b '-' "CTSRC" centreidentification Identification du centre émetteur
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Mode de fonctionnement du
système de contrôle terminal
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Mode de fonctionnement d'un
FDPS
ctxtpos b '-' "CTXTPOS" contextphidiasid Spécifique au système français
curfl b '-' "CURFL" fl3 Niveau de vol du moment
curpos c '-' "CURPOS" ptid | (lattd longtd) Position du momentcurpost b '-' "CURPOST" datetime Date et heure à la positiondu
moment
curptt b '-' "CURPTT" datetime Date et heure de survol du point
considéré
curptx b '-' "CURPTX" 1{DIGIT}2 Chiffre correspondant au point
considéré dans une liste de points
de cheminement
dcatcid b '-' "DCATCID" icaoaerodrome Aérodrome responsable de l'autori-
sationde départ lorsqu'elle est
accordée par le FDPS à l'aéronef
via la liaison de données
dcbtxt b '-' "DCBTXT" 'REJECTED'|
'RECEIVED'Statut de l'autorisationde départ
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Texte de base des messages d'auto-
risationde départ ARINC 620.
«ACK» pour accusé de réception
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Statut autorisationde départ pour
unvol
dcid b '-' "DCID" 1{DIGIT}3 Numérotationsystème d'autorisa-
tionde départ
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Type de message d'autorisationde
départ
dcref b '-' "DCREF" 1{ALPHANUM}5 Référence contextuelle pour une
autorisationde départ
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Observationpour un e autorisation
de départ
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Premier libellé complémentaire
pour le message d'autorisationde
départ
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Second libellé complémentaire
pour le message d'autorisationde
départ
dcdt b '-' "DCDT" datetime ! seconds Jour, heures, minutes et secondes
pour l'autorisationde départ
delcode b -' “DELCODE”
1{ALPHANUM}20Raisond'unretard
dfdpsid b '-' "DFDPSID datetime ! seconds Données d'identification du FDPS
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identification d'une entité «de
secours»
ecurptt b '-' "ECURPTT" datetime Estimée de passage à la verticale
du point considéré
eda b '-' "EDA" date Heure estimée d'arrivée2000R2082 — FR — 15.06.2002 — 001.001 — 131
▼B
Champ
primaire
réservéType Syntaxe Sémantique
elastptt b '-' "ELASTPTT" datetime Estimée de passage à la verticale
du dernier point de cheminement
endhldt b '-' "ENDHLDT" datetime Heure de fin de circuit d'attenteentrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Nombre d'occurrences d'un plan de
vol dans un centre
entryt b '-' "ENTRYT" datetime Heure d'entrée pour le poste
enxtptt b '-' "ENXTPTT" datetime Estimée de passage à la verticale
du point suivant (non mentionné si
le point considéré est le dernier
point)
eobdt b '-' "EOBDT" datetime Date et heure estimée de départ de
l'aire de stationnement
eosrc b '-' "EOSRC" eoidentification Identification de l'unité opération-
nelle
espfl b '-' "ESPFL" flightlevel Altitude de transfert complémen-
taire pour le poste de contrôle
précédent
eta b '-' "ETA" timehhmm Heure estimée d'arrivéeetrfl b '-' "ETRFL" flightlevel|flightten-
dancyNiveau de vol d'entrée / tendance
du profil de vol
event b '-' "EVENT" sendingreason Facteur déclenchant pour le FDPSfirstpid b '-' "FIRSTPID" pointcautra Spécifique au système français
flbk b '-' "FLBK" flightlevel Niveau de vol du dernier point de
référence de transaction, ou niveau
modifié pour un point de référence
de transaction
fpbaseid b '-'FPBASEID" datetime!seconds Identification de la base de plans
de vol
fpctst b '-' "FPCTST" fpcentrestate Etat d'un plan de vol dans un
centre
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Liste des plans de vol connus, mais
non encore transférés, destinés à un
poste
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Catégorie de vol:
T = survol
E = à l'arrivée
S = au départ
I = intérieur
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Liste d'informations de plan de vol
pour unin dicatif d'appel
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Liste de champs de plande vol
fplnb b '-' "FPLNB" 1{DIGIT}1 Nombre de plans de vol: de 0 à 5
fplstat b '-' "FPLSTAT" "T" | "C" Statut du vol:
T = terminé
C = encours
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Obsvervations du plan de vol initialfpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"“|FIC-
PAC"|"FPL"|"RPL"|"NKW")Source du plande vol
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Liste de plans de vol «inconnus»
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Message texte libre
ftxid b '-' "FLXID" 1{ALPHANUM}14 Identification d'itinéraire flexible2000R2082 — FR — 15.06.2002 — 001.001 — 132
▼B
Champ
primaire
réservéType Syntaxe Sémantique
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Désignation d'itinéraire flexible
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Numéro de création d'itinéraire
flexible
grspd b '-' "GRSPD" 1{DIGIT}4 Vitesse sol exprimée enn œudshldbkrw b -' "HLDBKRW" 1{DIGIT}2 Numéro d'ordre d'unpoin t de réfé-
rence pour un circuit d'attente dans
une liste de points de cheminement
icing b '-' "ICING" 1{ALPHA}8 Givrage:
«TRACE», «LIGHT», «MODE-
RATE» ou «SEVERE».
indstip b '-' "INDSTIP" “STIP” Spécifique au système français
initid b '-' "INITID" 1{DIGIT}1 Numéro d'initialisation
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Identificateur d'interface FDPS/
ODS ou FDPS/système terminal
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Liste des latitudes et longitudes des
points de cheminement
lang b '-' "LANG" '?' Indicateur de langage conversa-
tionnel
«?» = non usuel pour la compagnie
lastradt b '-' "LASTRADT" datetime Dernière mise à jour horaire
donnée par le radar
lights b '-' "LIGHTS" 1{ALPHANUM}1 Code de feux
maint b '-' "MAINT" 'YES'|'NO' Mention précisant si les informa-
tions à destination d'un poste de
contrôle sont actualisées en perma-
nence ou non
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Informations Mode A du SSR
modec b '-' "MODEC" flightlevel Informations Mode C du SSR
msgbody b '-' "MSGBODY"
1{CHARACTER}Contient une chaîne de caractères
identique au corps du message non
ADEXP équivalent et existant
msgct b '-' "MSGCT" datetime ! seconds Datation du message en format:
jour, heures, minutes, secondes
nat b '-' "NAT" 1{ALPHA}1 Identification d'un itinéraire Atlan-
tique Nord
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Fréquence de contact suivante
nxtfir b '-' "NXTFIR" icaoaerodrome FIR suivante à contacter
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Position suivante
nxtpost b '-' "NXTPOST" datetime Heure de survol de la position
suivante
oclfl b '-' "OCLFL" flightlevel Niveau de vol de limite d'autorisa-
tionocéan ique (OCL)
oprfl b '-' "OPRFL" flightlevel Demande de niveau de vol modi-
fiée par l'exploitant
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Liste d'observations de l'exploitant
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Observations de l'exploitant
oriented b '-' "ORIENTED" 'YES'|'NO' Vol orienté ou non
pfl b '-' "PFL" flightlevel Niveau de vol prévu (PFL)
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistCoordonnées de piste radar et
coordonnées de vecteur de vitesse
pistid b '-' "PISTID" 1{DIGIT}4 Identification de piste radar2000R2082 — FR — 15.06.2002 — 001.001 — 133
▼B
Champ
primaire
réservéType Syntaxe Sémantique
pkarr c '-' "PKARR" [pka] [pkc] pkatt Poste de stationnement d'un vol à
l'arrivée
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Poste de stationnement d'un vol au
départ
plnid b '-' "PLNID" 4{DIGIT}4 Identification de plan de vol
plnold b '-' "PLNOLD" 4{DIGIT}4 Ancienne identification de plan de
vol
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Statut poste ctrl pour coordination
mouvement:
mouvement accepté en entrée
(MAE) ou ensortie (MAS), ou
mouvement proposé en sortie
(MPS) ou ensortie alarme
(MPSA), ou poste non encore
coordonné pour le mouvement
(NO)
ptnb b '-' "PTNB" 1{DIGIT}2 Nombre de points de cheminement
qfu b '-' "QFU" qfuid Identification de piste utilisée
(QFU)
quebec b '-' "QUEBEC" 'YES'|'NO' Vol Québec ou non
radioid b '-' "RADIOID"
1{ALPHANUM}20Identification radio
reqid b '-' "REQID" 1{DIGIT}5 Numéro de demande
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Type de demande de plan de vol
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Liste des unités destinataires des
données de plan de vol
ripsrc b '-' "RIPSRC" centreidentification Identification du centre chargé
d'initialiser la transmission des
données de plan de vol
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' Numéro de transaction IFPS dans
une demande de plan de vol
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Liste des points CAUTRA de
cheminement non dirigé
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Liste des points de cheminement
pour certaines transactions
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Liste de configurations d'aérodrome
secdest b '-' "SECDEST" secidentification Identificateur du secteur destina-
taire
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Liste de secteurs
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Liste globale des secteurs
secsrc b '-' "SECSRC" secidentification Identificateur du secteur d'origine
spfl b '-' "SPFL" flightlevel Niveau de vol complémentaire
ssrcodes c '-' "SSRCODES" (code1 code2)|-
code|codep)Code SSR transmis
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmIdentification horodateur
streason b '-' "STREASON" starreason Motif d'une demande d'initialisation
émise par unposte de con trôle
strid b '-' "STRID" 1{DIGIT} Identificateur de RDPS
temp b '-' "TEMP" temperature Température2000R2082 — FR — 15.06.2002 — 001.001 — 134
▼B
Champ
primaire
réservéType Syntaxe Sémantique
terminal b '-' "TERMINAL"
1{ALPHANUM}2Désignation du terminal
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Liste de transactions possibles pour
le poste de contrôle et le plan de
vol spécifié
trfl b '-' "TRFL" flightlevel|flightten-
dancyNiveau de vol de transfert ou
tendance du profil de vol
turb b '-' "TURB" 1{ALPHA}8 Turbulence = LIGHT, MODE-
RATE ou SEVERE
validend b '-' "VALIDEND" datetime Heure de fin de visualisation
validst b '-' "VALIDST" datetime Heure de début de visualisation
visi b '-' "VISI" 1{ALPHANUM}20 Visibilité
wddir b '-' "WDDIR" 1{DIGIT}3 Directiondu ven t exprimée en
degrés de 0 à 359
wdspd b '-' "WDSPD" 1{DIGIT}3 Vitesse du vent exprimée en nœuds
xfl b '-' "XFL" flightlevel Niveau de vol de sortie (XFL)
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Message de réponse à une demande
de plande vol
D.5.Sous-champsréservés
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Champs du plande
vol modifiables au
moment de l'activa-
tiond'unvoltransid
bkchg c '-' "BKCHG" flimp
flminflmaxFL implicite, FL
minimum et FL
maximum pour le
point de référence
d'unsecteur. Le FL
est générique et peut
être unRFL, unPFL,
etc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Valeur (+/-) permise
pour une modifica-
tionhoraire d'un
pointfieldid
cflchg c '-' "CFLCHG" flimp
flminflmaxNiveau de vol auto-
risé (CFL) implicite,
CFL minimum et
CFL maximum pour
le point de référence
d'unsecteurfieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Mode SSR et code
allouéssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Mode SSR et code
disponiblessrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Mode SSR et code
précédemment allouéssrcodes2000R2082 — FR — 15.06.2002 — 001.001 — 135
▼B
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Mode SSR et code
réservé (donc non
disponible)ssrcodes
coorpt b '-' "COORPT" coor-
dpointsCaractéristique du
point de coordina-
tion: Initial, Exit,
OCL, XFLptc
ctdest b '-' "CTDEST"
centreidentificationCentre destinataire
(CCR)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervalle de temps
pour le calcul d'un
temps minimumbktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervalle de temps
pour le calcul d'un
temps maximumbktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Intervalle de vitesse
pour le calcul d'une
vitesse minimalespdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Intervalle de vitesse
pour le calcul d'une
vitesse maximalespdchg
destid c '-' "DESTID" ctdest
secripCentre ATC et liste
des secteurs destina-
taires des données de
plande volripel
edto b '-' "EDTO" dateti-
me|"WT"Estimée de passage à
la verticale d'unpoin t
en format: année,
mois, jour, heures et
minutes, ou mention
«point sans donnée
horaire» («WT»)ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationDésignation d'entité
opérationnelleeolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Liste des entités
opérationnelles asso-
ciées à unposte de
contrôleeopos
eopos c '-' "EOPOS" posid
[eolist]Désignation du poste
de contrôle et liste
des entités opération-
nelles associées à ce
posteconfl
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'R-
TE'|'ADEP'|'CODE'|'-
LANG'|'BK'|spdchg|r-
flchg|cflchg|pflchg|tf-
lchg|sflchg|xflchg|bk-
chg|bktchg|'QFU'|'PK-
DEP'|'SID'|'NFC'|'A-TIS'|'DCRM-
K'|'OPRMK'Identification des
champs modifiables
pour une transactionact
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Niveau de vol calculé
au point de coordina-
tionde sortie, qui
peut être transmis
dans le message de
coordination automa-
tique adressé au
centre suivantautomsg2000R2082 — FR — 15.06.2002 — 001.001 — 136
▼B
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
flimp b '-' "FLIMP" flight-
levelNiveau de vol impli-
citebkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" flight-
levelNiveau de vol
maximumbkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flminb '-' "FLMIN" flight-
levelNiveau de vol
minimumbkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbIdentification de plan
de vol dans un
messagefpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobtDonnées de plan de
vol «résumées»fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidIdentification de plan
de volfplist
lalg c '-' "LALG" lattd
longtdLatitude et longitude
de chaque point de
cheminementlaglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Liste des champs
modifiables après
activationtransid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Liste des champs
modifiables dans une
transaction de mise à
jour horaire après
activationtransid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2'-' "END" "MVT"Liste des champs
modifiables dans unecoordination déclen-
chée manuellement
entre secteurstransid
pflchg c '-' "PFLCHG" flimp
flminflmaxNiveaux implicite,
minimum et
maximum pour une
modificationde PFLfieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Niveau de vol prévu
qui sera transmis
dans le message de
coordination automa-
tique adressé au
centre suivant. Plus
mention précisant si
ce niveau est
conforme ou non aux
conventions opératio-
nelles applicables
(NA = non conforme)automsg
pka b '-' "PKA"
1{ALPHANUM}3Poste de stationne-
ment réservé mais
non encore allouépkarr2000R2082 — FR — 15.06.2002 — 001.001 — 137
▼B
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
pkatt b '-' "PKATT" 'YES' |
'NO'Indique que l'aéronef
est dans l'attente d'un
poste de stationne-
mentpkarr
pkc b '-' "PKC"
1{ALPHANUM}3Poste de stationne-
ment allouépkarr
pointid b '-' "POINTID" point-
cautraSpécifique au système
françaisptpro
posid b '-' "POSID" positioni-
dentificationDésignation poste de
contrôleeopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Caractéristiques d'un
point de chemine-
mentrte
ptcid b '-' "PTICD" pointcau-
tra|geonameSpécifique au système
françaisautomsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Descriptiondes
points de chemine-
ment proposésrtetr
qful c '-' "QFUL" qfuid QFU valable pour
une piste donnée d'un
aérodromeqfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Liste des QFU vala-
bles pour unaéro-
dromeacnf
rcnf b '-' "RCNF"
1{ALPHA}5Directiongén érale de
décollage et d'atter-
rissage pour unaéro-
drome (est, ouest,
etc.)acnf
ref c '-' "REF" (refi-
d|ref1id)Caractéristiques d'un
point de référence
pour une transactionptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Identification d'un
point de référence
possible pour unetransactionref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identification du
point de référence le
plus probable pour
une transactionref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Première identifica-
tiond'un e régulationregul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Deuxième identifica-
tiond'un e régulationregul
regult b '-' "REGULT" date-
timeHeure de la régula-
tionregul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Liste des champs
modifiables dans une
transaction de remise
enl'état an térieur des
données de plan de
voltransid
rflchg c '-' "RFLCHG" flimp
flminflmaxNiveaux implicite,
minimum et
maximum pour la
modificationdu RFLfieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Libellé d'une obser-
vationfaite par un
contrôleuroprmk2000R2082 — FR — 15.06.2002 — 001.001 — 138
▼B
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
sec c '-' "SEC" secid
[seccar]Identification et
caractéristiques des
secteurs d'unCCR
destinataires des
données de plan de
volseclist secrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Caractéristiques d'un
secteur de CCR:
—Premier secteur
(«F»)
—Dernier secteur
(«L»)
—Accepté pour
entrée («M»)
—Secteur source
pour «duplication»
(«D»)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Caractéristiques d'un
secteur TMA:
—Premier secteur
(«F»)
—Dernier secteur
(«L»)
—Accepté pour
entrée («M»)secct
secct c '-' "SECCT" secid
[seccarct]Identification et
caractéristiques des
secteurs TMAseclistct
secid b '-' "SECID" seciden-
tificationIdentification de
secteursecct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Liste des entités
(secteurs ou unités de
contrôle de départ/
d'arrivée) destina-
taires des données de
plande voldestid
sendt b '-' "SENDT" datetime Heure d'émission
d'unmessage de
coordinationautomsg
sflchg c '-' "SFLCHG" flimp
flminflmaxNiveaux implicite,
minimum et
maximum pour la
modificationd'unn iv.
complément. (SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Intervalles de vitesse
inférieur et supérieur
pour la modification
de la vitesse inscrite
au plande vol au
cours d'une transac-
tionfieldid
tflchg c '-' "TFLCHG" flimp
flminflmaxNiveaux implicite,
minimum et
maximum pour la
modificationdu
niveau transfert
(TFL)fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Caractéristiques d'un
point en relation avec
la trajectoire d'unvol:
S = point de scission
M = point de jonction
T = point travers
A = point STARptc
ptpro2000R2082 — FR — 15.06.2002 — 001.001 — 139
▼B
Sous-
champs
réservésType Syntaxe SémantiqueUtilisé
dans
champ
primaireUtilisé dans
sous-champ
transid c '-' " TRANSID" (act|
mod|mvt|ret|modh|
'CNL'|'RIP')|'NO'Identification de
transaction possible
pour le poste de
contrôle concernant
ce plande vol parti-
culier ou mention
«NO» pour indiquer
qu'aucune transaction
n'est possibletranslist
txt b '-' "TXT"
1{LIM_CHAR}80Texte libre freetxt
udpt b '-' "UDPT" update-
reasonDernière mise à jour
apportée par l'opéra-
teur et/ou sur la base
d'informations radarptc
view b '-' "VIEW"
('V'|'VNX')Indique le caractère
«visible» d'unpoin t
V = visible
VNX = non visible
(point artificiel)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5ALPHA:= P|N
P:= Positive
N:= NegativeCoordonnée X du
vecteur vitesse d'unepositionradarpistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|NP:= Positive
N:= NegativeCoordonnée Y du
vecteur vitesse d'une
positionradarpistcoord
xflchg c '-' "XFLCHG" flmin
flmaxNiveaux minimum et
maximum pour la
modificationd'un
niveau de sortie(XFL)fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positive
N:= NegativeCoordonnée X d'une
positionradarpistcoord
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positive
N:= NegativeCoordonnée Y d'une
positionradarpistcoord2000R2082 — FR — 15.06.2002 — 001.001 — 140
▼B
ANNEXE E (Informative)
PRÉSENTATIONDES GROUPES DE MESSAGES
INTRODUCTION
La présente Annexe présente les différents groupes ou catégories de messages
qui peuvent être échangés en ADEXP. La liste complète des intitulés de
message ADEXP figure à l'Annexe B.
NOTE On se référera, pour ce qui est des conditions et règles précises d'appli-
cationet d'utilisationdes champs, enparticulier l'emploi des champs
facultatifs, à la documentation utile (par ex. Spécifications d'interface)
des systèmes considérés.
E.1.Messages de plan de vol
E.1.1. Introduction
Les messages relevant de cette catégorie sont échangés principale-
ment entre les AO, l'IFPS et les organismes ATS compétents.
E.1.2. Définition des intitulés de message
Les messages relevant de cette catégorie portent les intitulés suivants:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQS, ISPL, MAN, RCHG, RCNL, REJ.
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 3.
E.1.3. Composition des champs primaires
La définition détaillée de la teneur des messages, les règles d'insertion
de données et le mode d'utilisation des champs obligatoires et facul-
tatifs sont énoncés dans le document cité en réf. 3.
Example
Flight PlanMessage-TITLE IFPL
-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC
EGZYTTTE -FAC EGTTZGZP
-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC
LPPCIFPS -FAC LPPTYWYA
-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS-END ADDR
-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -
CEQPT S
-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686
-ORGNID AZXRPLO
-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -
SPEED N0400 -FLTRUL I
-FLTTYP S-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS
UG41 FTM
-BEGIN RTEPTS-PT -PTID EGKK -FL F000 -ETO 980305113000-PT -PTID SAM -FL F196 -ETO 980305114012
-PT -PTID ASPEN -FL F288 -ETO 980305114658
-PT -PTID ORTAC -FL F311 -ETO 980305114959-PT -PTID GUR -FL F330 -ETO 980305115617
-PT -PTID AKEMI -FL F330 -ETO 980305120118
-PT -PTID LARSI -FL F330 -ETO 980305120626-PT -PTID QPR -FL F330 -ETO 980305121236-PT -PTID ERWAN -FL F330 -ETO 9803051231522000R2082 — FR — 15.06.2002 — 001.001 — 141
▼B
-PT -PTID LOTEE -FL F330 -ETO 980305124401
-PT -PTID AVS -FL F330 -ETO 980305125357-PT -PTID KORET -FL F330 -ETO 980305130137-PT -PTID BARKO -FL F330 -ETO 980305130734-PT -PTID CANAR -FL F330 -ETO 980305131544-PT -PTID VIS -FL F330 -ETO 980305132220-PT -PTID FTM -FL F234 -ETO 980305133230-PT -PTID LPPT -FL F000 -ETO 980305134529-END RTEPTS-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT
UR107 QPR AVS
-ATSRT UG41 AVS FTM
E.2.Messages de gestion des courants de trafic aérien
E.2.1. Introduction
Les messages relevant de cette catégorie sont échangés principale-
ment entre le système TACT du CFMU d'Eurocontrol, les
exploitants d'aéronefs et les organismes ATS.
E.2.2. Messages d'allocation de créneaux assistée par ordinateur (CASA)
Les messages relevant de cette catégorie portent les intitulés suivants:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Définition des intitulés de message
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 5.
E.2.2.2. Compositiondes champs primaires
La définition détaillée de la teneur des messages, les règles d'insertion
de données et le mode d'utilisation des champs obligatoires et facul-
tatifs sont énoncés dans le document cité en réf. 5.
Example
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3. Messages d'information
Les messages relevant de cette catégorie portent les intitulés suivants:
ANM, CNLCOND, CNLREG, EXCOND, FSA, MODCOND,
MODREG, MRA, MRCNL, MRMOD, NEWREG, NTA, NTACNL,
NTAMOD, OLRA, OLRCNL, OLRMOD.
E.2.3.1. Définition des intitulés de message
Les éléments de définition de ces messages figureront dans le docu-
ment «AME System Interface Specification» (Spécification
d'interface du système AME). Le mode d'utilisation du message
ANM est décrit dans le document initulé «ATFM User Manual»(Manuel des utilisateurs ATFM).
E.2.3.2. Compositiondes champs primaires
La définition détaillée de la teneur des messages, les règles d'insertion
de données et le mode d'utilisation des champs obligatoires et facul-
tatifs seront énoncés dans le document «AME System Interface
Specification».
Example
First System ActivationMessage-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — FR — 15.06.2002 — 001.001 — 142
▼B
E.3.Messages de coordination ATC
E.3.1. Introduction
Les messages de coordination sont utilisés pour automatiser la coor-
dination opérationnelle et l'échange d'informations entre organismes
ATC. Ils assurent la transmission, dans les délais voulus, des informa-
tions opérationnelles requises pour la coordination au moyen de
fonctions normalisées d'extraction et de transmission des données.
E.3.2. Définition des intitulés de message
Les messages relevant de cette catégorie portent les intitulés suivants:
ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 6.
E.3.3. Composition des champs primaires
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 6.
Examples
Hand-Over Proposal Message-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Activate Message
-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 005 -ARCID AMM253
-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO
1226 -TFL F350
-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4
BPK UB3 HON
E.4.Messages de gestion de l'espace aérien
E.4.1. Introduction
Messages utilisés pour la coordination de la gestion de l'espace
aérien. Ils couvrent la gestion de l'environnement dans lequel évolue
le trafic: routes permanentes et conditionnelles, zones de ségrégation
temporaire, zones dangereuses et interdites, etc.
E.4.2. Définition des intitulés de message
Les messages relevant de cette catégorie portent les intitulés suivants:
AUP, CRAM, UUP.
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 7.
E.4.3. Composition des champs primaires
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 7.
Example
Conditional Route Availability Message-TITLE CRAM -PART -NUM 001 -LASTNUM 010
-FILTIME 281353 -MESVALPERIOD 199803290600
1998703300600
-BEGIN LACDR-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803300600
-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP2000R2082 — FR — 15.06.2002 — 001.001 — 143
▼B
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030
199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL
-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700
199803291330
-END LACDR
E.5.Messages de coordination civile / militaire
E.5.1. Introduction
Messages utilisés pour la coordination des données de vol et des
demandes de traversée d'espace aérien entre organismes ATS civils
et militaires.
E.5.2. Définition des intitulés de message
Les messages relevant de cette catégorie portent les intitulés suivants:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 7.
E.5.3. Composition des champs primaires
Tous les éléments de définition de ces messages figurent dans le
document cité en réf. 7.
Example
Crossing Clearance Request Message
-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP
F111 -SECTOR SOUTH
-BEGIN RTEPTS-PT -PTID GEO01 -TO 1630 -FL F250
-PT -PTID GEO02 -TO 1631 -FL250
-END RTEPTS-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E
Acceptance Message
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — FR — 15.06.2002 — 001.001 — 144
▼B
ANNEXE F (Informative)
EXEMPLES DE FORMAT DE MESSAGES ADEXP
Les exemples ci-après sont donnés à titre d'illustration du format ADEXP et non
de la teneur du message. Le message utilisé en l'occurrence est un IFPL; bien
que correcte au moment de la publication, l'exactitude de la composition des
champs, notamment, n'est pas garantie.
L'EXEMPLE No1 est présenté de manière très lisible grâce à l'emploi de retours
chariot, de changements de ligne, de décrochements, etc. Ce format de présenta-
tion ne s'inscrit toutefois pas dans les règles de formatage ADEXP.
La présentation du message est donc laissée à la discrétion du système récep-
teur. Les EXEMPLES No2e tNo3 constituent, tous deux, des représentations
valables du même message que celui donné dans l'EXEMPLE No1.
EXAMPLE 1
-TITLE IFPL-BEGIN ADDR
-FAC CFMUTACT-FAC LFFFSTIP-FAC EDFFZRZL
-FAC EDZZZQZA
-FAC EDUUZQZA-FAC LOVVZQZX
-FAC LHBPZEZX
-FAC LYBAZQZX-FAC LWSSZQZX
-FAC LGTSZAZX
-END ADDR
-ADEP EDDF
-ADES LGTS
-ARCID DLH3728
-ARCTYP B73A
-CEQPT SDMRY
-EOBD 980517
-EOBT 0715
-FILTIM 170421
-IFPLID AA05966101
-ORGNID DLHAOCC
-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH-REG DABHM
-SEL KMGJ
-SRC FPL
-FLTTYP S
-WKTRC M
-TTLEET 0210
-RFL F330
-SPEED N0417
-FLTRUL I
-SEQPT C
-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23
BABIT UR26
SAVIN UG18 BUI UB1 TALAS
-ALTRNT1 LBSF2000R2082 — FR — 15.06.2002 — 001.001 — 145
▼B
-EETFIR EDUU 0014
-EETFIR LOVV 0035-EETFIR LJLA 0054
-EETFIR LHCC 0057
-EETFIR LYBA 0113-EETFIR LWSS 0148
-EETFIR LGGG 0159
-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414
-PT -PTID RIDER -FL F327 -ETO 980317073726-PT -PTID MAH -FL F330 -ETO 980317074130
-PT -PTID MUN -FL F330 -ETO 980317074449
-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830-PT -PTID DIMLO -FL F330 -ETO 980317081443
-PT -PTID BABIT -FL F330 -ETO 980317083107
-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204-PT -PTID VAL -FL F330 -ETO 980317084629
-PT -PTID KAVOR -FL F330 -ETO 980317085329
-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D-ATSRT UW70 NDG MUN
-ATSRT UB103 MUN UNKEN
-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN
-ATSRT UG18 SAVIN BUI
-ATSRT UB1 BUI TALAS
EXAMPLE 2
-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC
EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC
LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END
ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -
CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID
AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC
FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M
-TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE
N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26
SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -
EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR
LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -
PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -
ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID
MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO
980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID
UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO
9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID
BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO
980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID
KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO
980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID
BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO
980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID2000R2082 — FR — 15.06.2002 — 001.001 — 146
▼B
TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO
980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -
ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT
UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS
EXAMPLE 3
-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC
EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC
LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END
ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT
SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-
ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG
DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL
F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG
UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1
TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR
LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-
EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO
980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL
F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT
PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO
980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-
FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-
PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO
98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID
KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO
980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-
FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-
PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO
980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-
SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-
ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18
SAVIN BUI-ATSRT UB1 BUI TALAS2000R2082 — FR — 15.06.2002 — 001.001 — 147
▼B
ANNEXE G (Informative)
DEVELOPPEMENTS FUTURS
G.1.Introduction
La présente Annexe a pour objet de donner une indication du développe-
ment futur de l'ADEXP tel qu'il est envisagé, et d'en exposer les motifs
et les objectifs.
G.2.Objectifs
L'un des objectifs majeurs poursuivis dans le cadre de la mise au point
de l'ADEXP était le développement d'un format permettant à un système
récepteur de «ne pas prendre en compte» ou de «sauter» un champ
inconnu ou non identifié sans pour autant devoir invalider le message
en cours de traitement. Il est ainsi possible d'ajouter un nouveau champ
dans un message sans qu'il soit nécessaire de modifier à l'avance tous les
systèmes récepteurs pour procéder ensuite à un transfert très soigneuse-
ment coordonné. La souplesse considérable qui en résulte est l'un des
avantages du format ADEXP.
Cet objectif est atteint dans le cadre de la présente Norme par le recours
à des champs primaires et à des sous-champs prédéfinis, introduits par
des mots clés uniques. Un analyseur lexical ou syntaxique qui ne
«reconnaît» pas un mot clé doit sauter l'ensemble du texte jusqu'au
prochain champ primaire connu, qui ne se situe pas dans un champ de
listage («List Field»). La reprise s'opère dès lors au niveau des champs
primaires.
Le développement actuel et futur de la définition de nouveaux messages
donne à penser qu'un degré de complexité accru est requis dans certains
domaines, où des emboîtements de champs de troisième, voire de
quatrième niveau sont nécessaires. (Le message d'allocation de route
conditionnelle (CRAM) constitue une illustration actuelle de ce besoin).
Actuellement, l'ADEXP permet de construire un message avec n'importe
quel niveau d'emboîtement. Il ne permet cependant pas encore une
reprise consécutive à la détection d'un sous-champ non identifié au troi-
sième ou au quatrième niveau d'emboîtement, sans risque d'interprétation
erronée des données ou sans obligation d'invalider le message. Les modi-
fications que l'on se propose d'apporter au format ADEXP visent à faire
en sorte qu'un analyseur lexical ou syntaxique puisse, à tout moment,
déterminer où il se situe dans la structure d'un message ou d'un champ
particulier et ce faisant, à permettre une reprise à n'importe quel niveau
d'emboîtement sans risque d'interprétation erronée des données.
G.3.Proposition
Pour atteindre l'objectif d'une reprise à n'importe quel niveau, il est
nécessaire que l'analyseur lexical puisse repérer à la fois la fin et le début
d'un champ. Le format actuel permet seulement d'indiquer le début du
champ au moyendu sign e «-».
Il sera proposé, dans une version ultérieure de l'ADEXP, de recourir aux
parenthèses pour indiquer respectivement le début et la fin d'un champ.
Le signe actuel «-» de début de champ serait remplacé par la parenthèsegauche «(». La fin de champ, qui n'est pas représentée de manière expli-
cite à ce stade, serait signalée par la parenthèse droite «)». Les exemples
ci-après illustrent ce principe.
Exemples
Format actuel Format proposé
Exemple de champ simple: -RFL F330 (RFL F330)Exemple de champ composé: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430))2000R2082 — FR — 15.06.2002 — 001.001 — 148
▼B
ANNEXE III
DOCUMENT DE CONTRÔLE D'INTERFACE POUR L'ÉCHANGE DE
DONNÉES DE VOL (FDE-ICD), ÉDITION1.0
(document de référence Eurocontrol COM.ET1.ST12-STD)2000R2082 — FR — 15.06.2002 — 001.001 — 149
▼B
TABLE DES MATIÈRES
DROIT D'AUTEUR
AVANT-PROPOS1. INTRODUCTION2. DOMAINE D'APPLICATION3. RÉFÉRENCES
3.1. Introduction3.2. Références
4. DÉFINITIONS, SYMBOLES ET ABRÉVIATIONS
4.1. Définitions4.2. Symboles et abréviations4.3. Notation
5. APERÇU TECHNIQUE
5.1. Ensemble vertical des protocoles5.2. Structure du profil5.3. Relation avec des versions antérieures des spécifications
6. SPÉCIFICATIONS DE PROFIL
6.1. Conditions de conformité6.2. Conditions applicables aux couches supérieures6.3. Conditions applicables aux couches inférieures6.3.1. Couche transport6.3.2. Couche réseau6.3.3. Couche liaison de données6.3.4. Couche physique
7. MÉTHODES D'ESSAIANNEXE A (NORMATIVE) PROTOCOLE DE TRANSFERT DE MESSAGES
A.1. IntroductionA.2. Service utiliséA.3. Service requisA.4. Spécifications du protocoleA.4.1. IntroductionA.4.2. Types de donnéesA.4.3. Etablissement de l'associationA.4.4. Transfert de donnéesA.4.5. Libérationn ormale de l'associationA.4.6. Rétablissement de l'associationA.4.7. Intégrité de l'associationA.4.8. Libérationan ormale d'associationA.4.9. Reprise2000R2082 — FR — 15.06.2002 — 001.001 — 150
▼B
A.4.10. Formats des messages
A.5. Tableaux de transition des états de protocoleA.5.1. Introduction
A.5.2. Définition des états
A.5.3. Evénements possiblesA.5.4. TemporisateursA.5.5. Tableau de transition d'étatsA.5.6. Diagramme de transition d'états
ANNEXE B (NORMATIVE) PROTOCOLE D'EN-TÊTE DE MESSAGE
B.1. IntroductionB.2. Service mis enœuvreB.3. Service requisB.4. Spécifications du protocoleB.4.1. Etablissement de la connexionB.4.2. Mesures visant à éviter la redondance des connexions de réseauB.4.3. Libération de la connexionB.4.4. Transfert de données
ANNEXE C (NORMATIVE) PROTOCOLE DE RÉSEAU
C.1. IntroductionC.2. Service assuréC.3. Service requisC.4. Adresses NSAPC.4.1. IntroductionC.4.2. Structure de l'adresse NSAPC.4.3. Assignation des identificateurs et des sélecteurs d'organisme ATCC.5. Spécifications du protocoleC.5.1. AperçuC.5.2. Codage des adressesC.5.3. Codage du champ de données d'utilisateur
C.5.4. Traitement des adresses dans les paquets APPEL ENTRANT
C.5.5. Transfert de données
ANNEXE D (NORMATIVE) FORMULAIRES PICS DE CONFORMITÉ AU PROFIL
D.1. Introduction
D.2. Comment remplir les formulaires PICS
D.2.1. Structure générale des formulaires PICSD.2.2. Informations supplémentairesD.2.3. Informations sur les conditions d'exceptionD.2.4. Eléments conditionnelsD.3. Formulaire PICS pour le protocole de transfert de messagesD.3.1. Abréviations et symboles spéciaux2000R2082 — FR — 15.06.2002 — 001.001 — 151
▼B
D.3.2. Identification
D.3.3. Réalisationdu protocole
D.4. Formulaire PICS pour le protocole d'en-tête de messageD.4.1. Abréviations et symboles spéciauxD.4.2. IdentificationD.4.3. Réalisationdu protocoleD.5. Formulaire PICS pour le protocole de réseauD.5.1. Abréviations et Symboles spéciauxD.5.2. Identification
D.5.3. Réalisationdu protocole
ANNEXE E (NORMATIVE) LISTE DES SPÉCIFICATIONS DE PROFIL
E.1. IntroductionE.2. Rôle de la PRL et des formulaires PICSE.3. NotationE.4. Instructions pour remplir les formulaires PICSE.5. RéférencesE.6. Déclarationde con formitéE.6.1. Présentation générale de conformité
E.6.2. Conditions de conformité dynamique
E.7. Conditions applicables aux couches supérieuresE.8. Conditions applicables aux couches inférieuresE.8.1. Conditions applicables à la couche transportE.8.2. Conditions applicables à la couche réseauE.8.3. Conditions applicables à la couche liaison de donnéesE.8.4. Conditions applicables à la couche physique
ANNEXE F (INFORMATIVE) MÉTHODES DE TEST DE CONFORMITÉ
F.1. Introduction
F.2. Objet et portée
F.3. BibliographieF.4. Méthodes et procédés de mise au pointF.5. TestsF.5.1. IntroductionF.5.2. Tests des couches inférieures (Couches 1 à 3)F.5.3. Test de la couche applicationF.5.4. Homologation
F.5.5. Notification
ANNEXE G (INFORMATIVE) ASSIGNATION DES IDENTIFICATEURS D'ORGANISME ATC
ANNEXE H (INFORMATIVE) DIRECTIVES SUR LA FIABILITÉ, LA DISPONIBILITÉ ET LA
SECURITÉ
H.1. Introduction2000R2082 — FR — 15.06.2002 — 001.001 — 152
▼B
H.2. Objet et portée
H.3. BibliographieH.4. Réalisationsur base de liaisonspécialisée
H.4.1. Fiabilité
H.4.2. DisponibilitéH.4.3. SécuritéH.4.4. Exemple de configurationH.5. Réalisationsur base de réseauH.5.1. FiabilitéH.5.2. DisponibilitéH.5.3. SécuritéH.6. Directives générales pour les réalisations liaison spécialisée et réseauH.6.1. FiabilitéH.6.2. DisponibilitéH.6.3. Gestiondes systèmesH.6.4. Exemple de configuration2000R2082 — FR — 15.06.2002 — 001.001 — 153
▼B
DROIT D'AUTEUR
Le présent document a été élaboré par l'Agence Eurocontrol, qui en détient
les droits d'auteur.
Le contenu du présent document est librement accessible, en tout ou en
partie, aux représentants des États membres, toute reproduction ou divulga-
tion à des tiers étant toutefois subordonnée à une autorisation préalable de
l'Agence Eurocontrol.2000R2082 — FR — 15.06.2002 — 001.001 — 154
▼B
AVANT-PROPOS
1. Organe compétent
La présente Norme a été établie par le l'équipe spéciale «Échange
de données relatives aux plans de vol» (FPDE) de l'Organisation
européenne pour la sécurité de la navigation aérienne (Eurocon-
trol), qui en assure également l'actualisation.
2. Programme de travail EATCHIP
La présente Norme se rapporte à la Tâche spécialisée no12,
Mission d'encadrement 01, Domaine Communications, duProgramme de travail EATCHIP (EWPD).
3. Approbation de la Norme
3.1. La présente Norme est adoptée conformément aux procédures
exposées dans les Directives pour la normalisation à Eurocontrol,
réf. 000-2-93.
3.2. Elle prend effet dès son adoption par la Commission permanente
d'Eurocontrol et remplace la Norme Eurocontrol relative à
l'échange de données en ligne (OLDI), Edition 1, 3
epartie:
EXIGENCES TECHNIQUES (Document relatif au contrôle
d'interface à court terme), réf. 001-3-92.
4. Rectificatifs techniques et amendements
La présente Norme fait l'objet d'un suivi aux fins d'introduction
des amendements ou rectificatifs techniques requis. La procédure
d'actualisation est décrite à l'Annexe H des Directives pour la
rédaction et la présentation uniformes des documents normatifs
Eurocontrol, réf. 000-1-92.
5. Conventions rédactionnelles
5.1. Le format de présentation de la présente Norme est conforme aux
Directives pour la rédaction et la présentation uniformes des
documents normatifs Eurocontrol.
5.2. Afinde mettre enrelief le statut de chaque élémen t, il a été
décidé d'adopter les dispositions typographiques suivantes:
— les éléments normatifs sont imprimés en caractères ordinaires;
— leséléments recommandés sont imprimés en italiques, le
statut étant indiqué par le préfixe Recommandation .
5.3. Pour la rédactiondes spécification s, il a été décidé d'adopter les
dispositions suivantes: pour les éléments normatifs, on utilisera la
forme verbale «doit» ( «shall»en anglais) dans le cas des
éléments recommandés, on utilisera la formule «il convient de»
(«should» enan glais).
5.4. À titre exceptionnel, les tableaux des pages E.7 et E.8 ne compor-
tent aucun alinéa ni report sur la page suivante, de façon à
garantir une présentation adéquate des Listes de spécifications de
profil (PRL).
6. Lien avec d'autres documents normatifs
6.1. La présente Norme Eurocontrol remplace le Document relatif au
contrôle d'interface à court terme (ST-ICD), 3epartie de
l'Édition 1 de la Norme Eurocontrol OLDI [Référence 13].
6.2. Elle constitue le premier volet d'une série de documents normatifs
Eurocontrol concernant le contrôle d'interface (ICD) pour
l'échange de données de vol.
7. Statut des Annexes
Les Annexes à la présente Norme ont le statut suivant:
— Annexe A — Normative
— Annexe B — Normative
— Annexe C — Normative— Annexe D — Normative— Annexe E — Normative
— Annexe F — Informative2000R2082 — FR — 15.06.2002 — 001.001 — 155
▼B
— Annexe G — Informative
— Annexe H — Informative
8. Langue utilisée
Le texte original de la présente Norme a été rédigé en langue
anglaise.2000R2082 — FR — 15.06.2002 — 001.001 — 156
▼B
1. INTRODUCTION
La présente Norme Eurocontrol s'appuie sur le Document relatif
au contrôle d'interface à court terme établi par l'ancien Sous-
groupe technique OLDI qui avait été chargé de définir les
nouvelles normes d'interface pour l'exploitation future des
échanges OLDI entre centres de contrôle régional.
Auparavant, les liens OLDI reposaient sur des protocoles
brevetés, tels que l'INTERCAUTRA ou le Datenübertragungs-
und Verteilungssystem (DÜV), faisant appel à des circuits point
à point ou à des réseaux limités et nécessitant l'emploi de maté-
riel ou de logiciel spécialisé.
Pour la plupart des nouvelles liaisons prévues, il a été jugé
souhaitable de s'orienter vers une architecture de réseaux etd'adopter des normes de télécommunications internationales, les
liaisons pouvant ainsi être exploitées de façon plus rentable, grâce
à une réduction du nombre de connexions à chaque centre et à
l'emploi de matériel et de logiciel disponibles sur le marché.
La présente Norme Eurocontrol donne une forme définitive et
complète à l'ICD à court terme qui a été remanié de façon à
définir des spécifications plus rigoureuses devant permettre de
renforcer l'interopérabilité. En outre, elle pourra servir de point
de départ pour l'élaboration des futurs ICD destinés à répondre à
l'évolution des besoins dans le domaine de l'échange des données
de vol (FDE), notamment avec le recours accru aux réseaux
partagés et l'introduction de normes nouvelles pour les couches
inférieures. La présente Norme Eurocontrol offre un ensemble
minimum de fonctions qui peuvent être exploitées par les réalisa-
tions OLDI existantes moyennant un minimum de modifications,en utilisant soit des liaisons point à point, soit des réseaux à
commutation par paquets conformes à la recommandation X.25
du Comité consultatif international télégraphique et téléphonique
(CCITT) de 1980 ou ses versions ultérieures. Pour les achats,
d'autres possibilités peuvent être spécifiées. Le présent document
relatif au contrôle d'interface ne fait pas obstacle à la poursuite
des accords bilatéraux conclus.
Les services souhaitant exploiter d'autres protocoles d'application
en sus ou en remplacement de celui décrit dans le présent docu-
ment peuvent, soit solliciter l'amendement du présent protocole,
soit s'en démarquer en utilisant des circuits virtuels différents.
2. DOMAINE D'APPLICATION
2.1. La présente Norme Eurocontrol définit les spécifications d'une
interface de communication de données en vue de l'échange, entre
Centres de contrôle régional (CCR), de messages contenant des
données de vol. Elle est présentée sous forme de profil d'intercon-
nexion de systèmes ouverts (OSI), suivant la définition donnée
dans le rapport technique (TR) 10000-2 de l'Organisation interna-
tionale de normalisation/la Commission électrotechnique
internationale (ISO/IEC) [Référence 3]. Le profil traite à la fois
des couches inférieures (Profil T) et des couches supérieures
(Profil A).
2.2. Les dispositions de la présente Norme Eurocontrol s'appliquent
dans les circonstances suivantes:
— appui à OLDI tel qu'il est exposé dans la Norme Eurocontrol
N
o001-92 Edition1;
— appui à la transmission de messages d'application OLDI entre
les CCR et les systèmes de l'Organisme central de gestion des
courants de trafic aérien (CFMU).
2.3. Les dispositions de la Norme sont applicables aux connexions
utilisant soit:
— des liaisons spécialisées en point à point,
— des circuits point à point du réseau téléphonique public
commuté (RTPC),
— des réseaux de données à commutation par paquets ou des
réseaux interconnectés de données à commutation par paquets
disposant d'une interface conforme à la recommandation X.25
du CCITT endate de 1980 ou à un e versionultérieure.2000R2082 — FR — 15.06.2002 — 001.001 — 157
▼B
NOTES
1. Les modalités d'interface entre Systèmes de traitement des
plans de vol (FPPS) sont représentées à la Figure 1.
2. La Figure 1 ne tient pas compte des éventuelles connexions de
secours, tels que le RTPC, pour lesquelles des indications sont
données dans l'Annexe H.
Figure 1
Modalités d'interface
2.4. Un examen détaillé des questions de sécurité de l'interface de
communication de données spécifiée n'entre pas dans le cadre de
la présente Norme. On trouvera cependant des dispositions géné-
rales au paragraphe 5.4 de l'Annexe C ainsi que d'autres
indications à l'Annexe H.
3. RÉFÉRENCES
3.1. Introduction
Les documents et normes ci-après contiennent des dispositions
qui, par suite de la référence qui en est faite, constituent des
dispositions de la présente Norme Eurocontrol.
Les éditions indiquées sont celles qui étaient en vigueur au
moment de la publication de la présente Norme Eurocontrol.
Toute révision des documents de l'Organisation de l'aviation
civile internationale (OACI) cités en référence doit être immédia-
tement répercutée dans la présente Norme Eurocontrol.
Les révisions des autres documents cités en référence ne doivent
faire partie des dispositions de la présente Norme Eurocontrol que
lorsqu'elles auront été officiellement examinées et incluses dans
le présent document normatif.
En cas de conflit entre les prescriptions de la présente Norme et
la teneur des autres documents de référence, c'est la présente
Norme Eurocontrol qui prévaut.
3.2. Références
1. Recommandation X.25 (1993) (Rév. 1) de l'UIT-T, Interface
entre équipement terminal de traitement de données (ETTD)
et équipement de terminaison du circuit de données (ETCD)
pour terminaux fonctionnant en mode-paquet et raccordés à
des réseaux publics pour données par circuit spécialisé.
2. ISO/IEC TR 10000-1:1992 Technologies de l'information —
Cadre et taxonomie des profils normalisés internationaux —
Partie 1: Cadre (2eédition).2000R2082 — FR — 15.06.2002 — 001.001 — 158
▼B
3. ISO/IEC TR 10000-2:1994 Technologies de l'information —
Cadre et taxonomie des profils normalisés internationaux —
Partie 2: Principes et taxonomie pour profils OSI (3eédition).
4. Recommandation X.21 (1992) (Rév. 1) de l'UIT-T, Interface
entre l'équipement terminal de traitement de données (ETTD)
et l'équipement de terminaison du circuit de données (ETCD)
pour fonctionnement synchrone dans les réseaux publics pour
données.
5. Recommandation X.21bis (1988) du CCITT, Utilisation, sur
les réseaux publics pour données, d'équipements terminaux
de traitement de données (ETTD) destinés à assurer l'inter-
face des modems synchrones de la série V.
6. ISO/IEC 7776:1994, Technologies de l'information — Télé-
communications et échange d'information entre systèmes —
Procédures de commande de liaison de données à haut niveau
— Descriptiondes procédures de liaisond'équipemen t
terminal de transmission de données ETTD compatible X.25
(2eédition).
7. ISO/IEC 8208: 1993, Technologies de l'information —
Communication de données — Protocole X.25 de couche
paquet pour terminal de données (3eédition).
8. ISO/IEC ISP 10609-9:1992, Technologies de l'information —
Profils normalisés internationaux TB, TC, TD et TE —
Service de transport en mode connexion sur un service de
réseau en mode connexion — Partie 9: Spécifications de la
couche réseau, de la couche liaison de données et de la
couche physique dépendant du type de sous-réseau, concer-
nant l'accès permanent à un réseau de données à
commutation par paquets utilisant des communications
virtuelles.
9. ISO/IEC 7498-1: 1994, Technologies de l'information —
Interconnexion de systèmes ouverts — Modèle de
référence de base: Le modèle de base (2eédition).
10. ISO/IEC 8348:1993, Technologies de l'information — Inter-
connexion de systèmes ouverts — Définition du service de
réseau (1reédition).
11. ISO/IEC 8072:1994, Technologies de l'information — Inter-
connexion de systèmes ouverts — Définition du service de
transport (2eédition).
12. ISO/IEC 8878:1992, Technologies de l'information — Télé-
communications et échange d'informations entre systèmes —
Utilisationdu protocole X.25 pour fourn ir le service de
réseau OSI en mode connexion (2eédition).
13. Norme Eurocontrol pour l'échange de données en ligne
(OLDI) No001-92, Edition1, 1992.
14. ISO/IEC 9646-1:1994, Technologies de l'information —
Interconnexion de systèmes ouverts — Cadre général et
méthodologie des tests de conformité OSI — Partie 1:
Concepts généraux (2eédition).
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Part 1 Integration Test Plan Version 1.0,
dated 10 May 1996 (disponible uniquement en langue
anglaise).
16. Eurocontrol FDE ICD Part 1 — Reliability, Availability and
Security — Technical Report Version 1.0, dated 20 April
1997 (disponible uniquement en langue anglaise).
17. Recommandation X.32 (1993) (Rév. 1) de l'UIT-T, Interface
entre ETTD et ETCD pour terminaux fonctionnant en mode
paquet et ayant accès à un réseau public de transmission de
donnéees à commutation par paquet par l'introduction d'un
RTPC, d'unRNIS ou d'unréseau puplic pour don n ées à
commutationde circuits.
18. Recommandation E.164 (1991) (Rév. 1) de l'UIT-T, Plan de
numérotage pour le réseau numérique avec intégration des
services (RNIS).
19. Recommandation X.75 (1993) (Rév. 1) de l'UIT-T, Système
de signalisation commutation par paquets entre réseaux
publics assurant les services de transmission de données.
20. Recommandation X.121 (1993) de l'UIT-T, Plan de numéro-
tage international pour les réseaux publics pour données2000R2082 — FR — 15.06.2002 — 001.001 — 159
▼B
4. DÉFINITIONS,SYMBOLES et ABRÉVIATIONS
4.1. Définitions
4.1.1. Aux fins de la présente Norme Eurocontrol, les définitions ci-
après sont applicables:
4.1.2. Profil: un ensemble d'une ou plusieurs normes de base et, le cas
échéant, l'identification d'un choix de classes, de sous-ensembles,
d'options et de paramètres propres à ces normes de base, qui sont
nécessaires pour accomplir une fonction donnée [Référence 2].
4.1.3. Liste des spécifications de profil (PRL) : Les spécifications de
profil sont exprimées sous la forme de conditions de conformité
et présentées sous forme de tableau [Référence 2].
4.1.4. Profil T: Profil de transport fournissant un service de transport
en mode connexion [Référence 3].
4.1.5. Profil A: Profil d'application nécessitant un service de transport
en mode connexion [Référence 3].
4.1.6. Déclaration de conformité d'une instance de protocole (PICS) :
Déclaration par laquelle le fournisseur d'un système OSI indique
les moyens qui ont été mis en oeuvre pour un protocole OSI
donné [Référence 14].
4.2. Symboles et abréviations
Pour les besoins de la présente Norme Eurocontrol, les symboles
et abréviations ci-après sont utilisés:
AFI Identificateur d'autorité et de format
ASCII American Standard Code for Information
Interchange
ATC Contrôle de la circulation aérienneATCC Centre de contrôle de la circulation aérienneCAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télépho-
nique et télégraphique (devenu UIT-T)
CCR Centre de contrôle régionalCEI Commission électrotechnique internationaleCFMU Organisme central de gestion des courants
de trafic aérien
DCTS Système terminal de communication numé-
rique
DSP Partie spécifique du domaineDÜV Datenübertragungs- und VerteilungssystemETCD Equipement de terminaison de circuit de
données
ETTD Equipement terminal de traitement de
données
FDE Echange de données de vol
FPDE Echange de données relatives au plan de volFPPS Système de traitement des données de vol
GFU Groupe fermé d'usagers
ICD Document relatif au contrôle d'interface
IDI Identificateur de domaine initialIDP Partie initiale de domaineINTERCAUTRA Protocole Inter-CAUTRAISO Organisation internationale de normalisationLAPB Procédure d'accès à la liaisonenmode
symétrique
LSB Bit de plus faible poidsM, m ObligatoireMSB Bit de plus fort poids
NA Nonapplicable
NS Service de réseau
NSAP Point d'accès au service de réseau
NSDU Unité de données du service de réseau2000R2082 — FR — 15.06.2002 — 001.001 — 160
▼B
O, O.<n> Optionnel, <n> étant un numéral de réfé-
rence
o, o.<n> Optionnel, <n> étant un numéral de réfé-
rence
OACI Organisation de l'aviation civile internatio-
nale
OLDI Echange de données en ligneOSI Interconnexion de systèmes ouverts
PCP Protocole de couche paquet
PF Processeur frontalPICS Déclaration de conformité d'une instance de
protocole
PRL Liste des spécifications de profil
RNIS Réseau Numérique avec Intégration des
Services
RTPC Réseau téléphonique public commutéSE Système à l'essaiST-ICD Document relatif au contrôle d'interface à
court terme
T<x> Temporisateur (<x> étant une lettre unique
ou double servant de référence)
TA Adaptateur de terminal
TM Transfert de messages
TR Rapport technique de l'ISOTSDU Unité de données du service de transportUIT-T Union internationale des télécommunica-
tions — Secteur de la normalisation des
télécommunications
x Exclu
X Interdit
<élément>: Elément conditionnel (fonction de sa valeur)
4.3. Notation
4.3.1. Aux fins de la présente Norme Eurocontrol, les valeurs binaires
ou une séquence de bits sont présentées sous forme hexadécimale
à l'aide du symbole ‘d'H, la lettre d représentant un chiffre ou une
séquence de chiffres hexadécimaux.
4.3.2. Aux fins de la présente Norme Eurocontrol, la représentation
hexadécimale d'une séquence de bits est constituée de 4 bits pris
en même temps, en commençant par le bit de plus fort poids
(MSB) jusqu'au bit de plus faible poids (LSB).
NOTESauf avis contraire des normes internationaux en réfé-
rence, une séquence de bits est transmise depuis le MSB
jusqu'au LSB.
4.3.3. Aux fins de la présente Norme Eurocontrol, l'état de prise en
charge des fonctions d'une norme de base ou de la présente
Norme Eurocontrol est indiqué en majuscules (par exemple M,
O, O.<n>, X). La signification exacte de chaque symbole d'état
est précisée dans les annexes de la présente Norme Eurocontrol,
préalablement à leur emploi.
4.3.4. Pour définir le profil de la 1
repartie du FDE ICD dans la présente
Norme Eurocontrol, l'état de prise en charge des fonctions d'une
norme de base ou de la présente Norme Eurocontrol est indiqué
en minuscules (par ex.: m, o, o.<n>, x).
NOTELes fonctions des normes de base qui sont condition-
nelles, optionnelles ou dépendantes de la valeur sont
ainsi mieux précisées (voir le paragraphe E.3.1).
5. APERÇU TECHNIQUE
5.1. Ensemble vertical des protocoles
NOTEL'ensemble vertical des protocoles applicables au profil
de la présente Norme Eurocontrol est illustré à la2000R2082 — FR — 15.06.2002 — 001.001 — 161
▼B
figure 2. Les protocoles sont présentés suivant le modèle
de référence de base de l'OSI [Référence 9], l'ensemble
vertical étant aligné sur les couches OSI correspondantes.
Toutefois, l'ensemble vertical des protocoles constitue une
spécification des systèmes pré-OSI et n'assure pas les
multiples fonctions offertes par les protocoles OSI des
couches OSI correspondantes.
Figure 2
Ensemble vertical des protocoles
5.2. Structure du profil
NOTES
1. Comme le montre la figure 2, l'ensemble vertical combine
plusieurs protocoles de couche inférieure, dont seuls le proto-
cole X.25 en couche paquet (PCP) [Référence 1] et les
protocoles X.21 [Référence 4] et X.21.bis [Référence 5], qui
le complètent, sont définis dans les normes existantes de
l'ISO/CEI et de l'Union internationale des télécommunications
— Secteur de la normalisation des télécommunications (UIT-
T). Les protocoles des couches supérieures sont définis dans
les Annexes A, B et C de la présente Norme Eurocontrol.
2. Les conditions de conformité applicables au profil, qui
peuvent renvoyer à ces spécifications au même titre qu'à des
normes externes, sont indiquées à la section 5. Les spécifica-
tions détaillées sont présentées sous forme de tableau de PRL
(Annexe E) et dans les formulaires PICS (les formulaires pour
les protocoles définis dans les annexes figurent à l'Annexe D).
L'utilisation de ces PRL et des formulaires PICS pour la mise
au point et/ou l'acquisition est explicitée dans l'Annexe E.
5.3. Relation avec des versions antérieures des spécifications
NOTES1. Le présent profil s'appuie sur le Document ST-ICD établi par
l'ancien Sous-groupe technique OLDI. Les protocoles et les
modèles de paquet définis dans la présente Norme Eurocontrol
sont un sous-ensemble compatible de ceux du Document ST-
ICD, à la différence près que la présente Norme Eurocontrol
définit de façon plus détaillée les conditions d'emploi du PCP
X.25, y compris l'utilisation obligatoire du bit M, et remédie
au manque de cohérence des spécifications de la valeur de
l'identificateur d'autorité et de format (IAF) dans l'adresse du
point d'accès au service de réseau (NSAP).2000R2082 — FR — 15.06.2002 — 001.001 — 162
▼B
2. Les principales modifications de style apportées dans la
présente Norme Eurocontrol portent sur la structure des spéci-
fications de l'ICD. Le protocole de transfert de message
(Annexe A) est dissocié du profil T qui le complète. Cela faci-
litera l'utilisation des autres profils T lorsqu'elle deviendra
nécessaire pour faire face à l'évolution des besoins FDE.
3. Les sections des spécifications du ST-ICD traitant de la
commande des circuits virtuels X.25 et délimitant les messages
d'application figurent maintenant dans le protocole d'en-tête
de message (Annexe B), qui constitue une couche de transport
minimale pour le FDE.
6. SPÉCIFICATIONSDE PROFIL
6.1. Conditions de conformité
6.1.1. Une réalisation déclarée conforme à la présente spécification doit
satisfaire à toutes les conditions stipulées aux sections 6.2 et 6.3
ci-dessous.
6.1.2. Une déclaration de conformité doit être accompagnée d'une
Déclaration de conformité d'une instance de profil, telle qu'elle
est décrite dans les Annexes D et E.
6.2. Conditions applicables aux couches supérieures
6.2.1. Une réalisation conforme doit satisfaire aux conditions de la
norme de base, qui sont indiquées à l'Annexe A.
6.2.2. Une réalisation conforme doit satisfaire aux contraintes stipulées
dans la liste des spécifications de profil figurant à l'Annexe E.7.
6.3. Conditions applicables aux couches inférieures
6.3.1. Couche transport
6.3.1.1. Une réalisation conforme doit satisfaire aux conditions de la
norme de base, qui sont indiquées à l'Annexe B.
6.3.1.2. Une réalisation conforme doit satisfaire aux contraintes stipulées
dans la liste des spécifications de profil figurant à l'Annexe E.8.1.
6.3.1.3. Une réalisation conforme doit satisfaire à la condition de capacité
de l'unité de données du service de transport (TSDU), qui doit
être de 4 097 octets au plus.
NOTELe premier octet de la TSDU correspond à un champ
d'en-tête de message (voir les alinéas A.4.10 et B.4.4), ce
qui laisse 4 096 octets au plus pour les données de l'utili-
sateur.
6.3.2. Couche réseau
6.3.2.1. Une réalisation conforme doit satisfaire aux conditions de la
norme ISO/IEC 8208 [Référence 7], conformément à la mise en
correspondance des protocoles figurant à l'Annexe C.
6.3.2.2. Une réalisation conforme doit satisfaire aux contraintes stipulées
dans la liste des spécifications de profil figurant à l'Annexe E.8.2.
6.3.2.3. Une réalisation conforme doit, si un fonctionnement de type
Equipement terminal de traitement de données (ETTD)-ETTD
est assuré, être capable de configurer, par des mécanismes de
gestiondes systèmes, le choix du rôle de l'ETTD ou de l'équipe-
ment de terminaison de circuit de données (ETCD) pour le
fonctionnement ETTD-ETTD.
6.3.2.4. Une réalisation conforme doit, dans l'un ou l'autre rôle défini au
point 6.3.2.3, être capable de lancer une connexion conformément
aux spécifications de l'Annexe C, c'est-à-dire que le protocole est
totalement symétrique.
NOTECertaines réalisations déjà mises en place sur la base du
ST-ICD peuvent ne pas être capables de lancer des
connexions de réseau conformément au protocole de
l'Annexe C.
6.3.2.5. Une réalisation conforme doit admettre, pendant une période
donnée, le service de taille de paquets par défaut non standard,
avec une valeur de 256 dans les deux sens de transmission.2000R2082 — FR — 15.06.2002 — 001.001 — 163
▼B
6.3.2.6. Une réalisation conforme doit utiliser les adresses NSAP, telles
qu'elles sont définies dans l'Annexe C.
6.3.2.7. Une réalisation conforme doit positionner le bit D à 0 dans les
paquets d'APPEL, c et DONNÉES.
NOTEPositionner le bit D à 0 dans les paquets d'APPEL et
COMMUNICATION ACCEPTÉE équivaut à ne pas
utiliser la confirmation de remise.
6.3.3. Couche liaison de données
6.3.3.1. Une réalisation conforme doit satisfaire aux conditions de confor-
mité de la norme ISO/IEC 7776 [Référence 6] pour le protocole
de liaison unique avec procédure d'accès à la ligne en mode
symétrique (LAPB).
6.3.3.2. Une réalisation conforme doit également satisfaire aux contraintes
stipulées dans la Liste des spécifications de profil figurant à
l'Annexe E.8.3.
6.3.4. Couche physique
Une réalisation conforme doit satisfaire aux conditions de confor-
mité de la norme ISO/IEC ISP 10609-9, clause 7 [Référence 8].
7. MÉTHODES D'ESSAI
NOTES1. On trouvera à l'Annexe F une introduction aux tests destinés à
évaluer la conformité de réalisations aux présentes spécifica-
tions.
2. Les modalités d'emploi des PRL et des formulaires PICS
prévus dans les présentes spécifications pour justifier la
conformité sont exposées dans l'Annexe E.2000R2082 — FR — 15.06.2002 — 001.001 — 164
▼B
ANNEXE A (Normative)
PROTOCOLE DE TRANSFERT DE MESSAGES
A.1.Introduction
Les présentes spécifications définissent un protocole pour la mise en
oeuvre d'unservice de tran sfert de messages simple envue d'appli-
cations nécessitant l'échange de données de vol.
A.2.Service utilisé
Le protocole de transfert de messages (TM) utilise les services non-
confirmés suivants:
Association-TM: établit une association de transfert de messages
d'application.
Données-TM: transfère un message d'application composé de carac-
tères ASCII (Code standard US pour l'échange d'informations).
Abandon-TM: met fin à une association de transfert de messages
d'application.
A.3.Service requis
Ce protocole de transfert de messages nécessite un sous-ensemble
du service de transport en mode connexion, défini dans la norme
ISO/IEC 8072 [Référence 11], tel que le propose le protocole défini
dans l'Annexe B de la présente Norme Eurocontrol.
A.4.Spécifications du protocole
A.4.1. Introduction
Le texte ci-après décrit uniquement le fonctionnement d'une associa-
tion de transfert de messages lancée par l'application. D'autres
associations peuvent être assurées sur la même interface de réseau
en renouvelant ces procédures pour chaque connexion de transport
de la couche de niveau inférieur.
A.4.2. Types de données
La présente Annexe définit quatre types de messages d'application
qui sont équivalents à ceux définis dans la Norme Eurocontrol
no001-3-92 Édition1:
Messages de système: Ces messages doivent être utilisés pour la
surveillance des liaisons (message PULSION) et la commande
d'application(messages de DÉMARRAGE et d'ARRÊT).
Messages opérationnels: Ces messages doivent être liés à un
contexte opérationnel particulier et sont définis dans les Normes et
Documents normatifs d'Eurocontrol qui font appel à la présente
norme pour l'échange de données. La Norme Eurocontrol relative à
l'échange de données en ligne inclut, dans sa définition desmessages opérationnels, les messages d'activation (ACT), de préavis
de franchissement de limite (ABI) et d'accusé de réception logique
(LAM).
Messages d'opérateur: Ces messages doivent comporter un texte
libre. Leur emploi doit faire l'objet d'accords bilatéraux. Par
exemple, ils peuvent servir à échanger des informations d'essai ou
à informer l'autre partie des actions de l'opérateur.
Messages d'état: Ces messages, dont l'emploi et la teneur font
l'objet d'accords bilatéraux, peuvent notamment servir à l'échange
d'informations sur la gestion du système.
NOTES
1. L'emploi des messages de système fait partie des modalités du
présent protocole et le format des messages est précisé au
paragraphe A.4.10.3 de la présente Annexe.
2. L'utilisation et le format des messages d'état font l'objet
d'accords bilatéraux et ne sont pas précisés davantage dans la
présente Norme Eurocontrol.2000R2082 — FR — 15.06.2002 — 001.001 — 165
▼B
3. L'état du protocole détermine le type de message pouvant être
transmis, comme il est indiqué dans les paragraphes qui suivent.
A.4.3. Établissement de l'association
A.4.3.1. Au départ, le protocole est au REPOS.A.4.3.2. La primitive de demande d'Association-TM est exécutée afin d'éta-
blir une association d'application et d'amener le protocole à l'état
DONNÉES_PRÊTES. La primitive doit être invoquée à la fois par
l'applicationlocale et par l'applicationdistan te.
A.4.3.3. Il faut d'abord établir une connexion de transport de la couche de
niveau inférieur, suivant les procédures de la primitive de connexion
de transport décrites à l'Annexe B, paragraphe B.4.1, puis le proto-
cole arrive à l'état PRÊT. À ce stade, seuls les messages de système
(et éventuellement les messages d'opérateurs, selon les accords bila-
téraux conclus) peuvent être transférés. Pour transférer un message
de système ou d'opérateur, l'émetteur utilise la primitive de transport
de données (voir le paragraphe B.4.4) avec le message en tant que
paramètre.
A.4.3.4. Unmessage de DÉMARRAGE (message de système) doit alors être
transmis, le temporisateur Tr (voir le paragraphe A.4.7) doit être
déclenché et le protocole passe à l'état ASSOCIATION_EN_AT-
TENTE. Si le temporisateur Tr arrive à expiration pendant que le
protocole est encore à cet état, le message de DÉMARRAGE doit
être retransmis et le temporisateur doit être relancé.
NOTELe protocole reste dans l'état ASSOCIATION_EN_ATTENTE
jusqu'à la réception d'un message de DÉMARRAGE. Une
expiration continue du temporisateur Tr peut être signalée
localement.
A.4.3.5. La réception du message de DÉMARRAGE doit entraîner les
mesures suivantes:
— à l'état ASSOCIATION_EN_ATTENTE, unn ouveau message
de DÉMARRAGE est transmis, le protocole passe à l'état
DONNÉES_PRÊTES et la primitive indication d'Association-
TM est signalée;
— à tout autre état, le message est ignoré.
A.4.3.6. La réceptiondu message de DÉMARRAGE enétat d'ASSOCIA-
TION_EN_ATTENTE correspond:
— soit à la primitive demande d'Association-TM de l'application
distante et le protocole distant est passé à l'état ASSOCIATIO-
N_EN_ATTENTE;
— soit le protocole de transfert de messages distant répond à la
réceptiond'unmessage de DÉMARRAGE et est passé à l'état
DONNÉES_PRÊTES.
NOTECette incertitude est liée au fait que le même message est
utilisé pour le DÉMARRAGE et pour la réponse au
DÉMARRAGE. Par conséquent, le premier protocole à
passer dans l'état DONNÉES_PRÊTES va recevoir un
nouveau message de DÉMARRAGE. Comme indiqué au
paragraphe A.4.3.5, ce message est ignoré.
A.4.3.7. Une fois les messages de DÉMARRAGE échangés, l'association est
établie et tous les types de message identifiés peuvent être transférés
(état DONNÉES_PRÊTES).
A.4.4. Transfert de données
D'autres types de messages sont transférés de la même façon que les
messages de système, en utilisant le service de Données de trans-
port, avec le message en tant que paramètre. Cela correspond aux
primitives demande de Données-TM et indication de Données-TM.
NOTEChaque message est envoyé sous forme de TSDU unique: il
n'y a ni concaténation ni segmentation des messages à ce
niveau.
A.4.5. Libération normale de l'association
A.4.5.1. L'association de transfert de messages entre deux applications peut
être libérée par l'une ou l'autre des applications. Cela correspond à
la primitive du service de demande d'Abandon-TM.2000R2082 — FR — 15.06.2002 — 001.001 — 166
▼B
A.4.5.2. Les mesures suivantes doivent être prises:
— à l'état DONNÉES_PRÊTES, unmessage d'ARRÊT (message de
système) doit être transmis, les temporisateurs Tr et Ts doivent
être arrêtés et la connexion de transport doit être libérée;
— à l'état ASSOCIATION_EN_ATTENTE, unmessage d'ARRÊT
(message de système) doit être transmis, le temporisateur Tr
doit être arrêté et la connexion de transport doit être libérée;
— à l'état PRÊT la connexion de transport doit être libérée;— aucune autre mesure n'est prise par ailleurs.
NOTELe message d'ARRÊT n'est pas un préavis — il est mis fin à
l'association immédiatement. Le message n'est pas confirmé
par l'autre partie.
A.4.5.3. La réception d'un message d'ARRÊT doit entraîner les mesures
suivantes:
— à l'état DONNÉES_PRÊTES, le temporisateur Ts (voir A.4.7)
doit être arrêté, l'indication Abandon-TM est donnée et l'inter-
face passe à l'état ASSOCIATION_EN_ATTENTE sans envoi
d'unmessage de DÉMARRAGE;
— à tous les autres états, aucune mesure n'est prise.
A.4.6. Rétablissement de l'association
L'applicationqui a pris l'in itiative de la libérationde l'associationa
la responsabilité, lorsqu'elle est prête, de rétablir l'association
d'application et toute autre couche inférieure (si nécessaire).
NOTESi la libération de l'association a eu pour conséquence la
libération de la connexion de réseau, la procédure d'établis-
sement de l'association spécifiée au paragraphe A.4.3 doit
être suivie.
A.4.7. Intégrité de l'association
A.4.7.1. L'intégrité de l'association entre deux applications est assurée par le
service PULSION au repos.
A.4.7.2. Au passage à l'état DONNÉES_PRÊTES et lors de la transmission
de tout type de message sur la connexion transport, un temporisa-
teur Ts configurable doit être (re)lancé. Si le temporisateur Ts
arrive à expirationau cours de l'état DONNÉES_PRÊTES, un
message PULSION (message de système) doit être transmis (et le
temporisateur doit être relancé).
A.4.7.3. De même, au passage à l'état DONNÉES_PRÊTES et lors de la
réceptionde tout type de message, endehors d'unmessage de
DÉMARRAGE, sur la connexion transport, un temporisateur Tr
configurable doit être (re)lancé. Si le temporisateur Tr arrive à expi-
ration au cours de l'état DONNÉES_PRÊTES, l'indication Abandon-
TM est donnée, la transmission de tous les messages est arrêtée, le
temporisateur Ts est arrêté et le temporisateur Tr est relancé.
L'interface est à l'état ASSOCIATION_EN_ATTENTE.
NOTELes applications seront rétablies et resynchronisées par
l'échange de messages de DÉMARRAGE (voir
paragraphe A.4.3).
A.4.8. Libération anormale d'association
A.4.8.1. Il peut y avoir une libération anormale d'association:
— en cas de perte de la connexion de transport (par exemple, en
raison d'une défaillance de la ligne ou d'une erreur de proto-
cole);
— en cas de défaillance de l'un des deux systèmes ou applications
(imputable au matériel ou au logiciel; parfois, la connexion de
transport de la couche de niveau inférieur peut néanmoins fonc-
tionner).
NOTESelon la définition de la couche transport à l'annexe B, il
n'y a pas de connexion de transport de bout-en-bout. Par
conséquent, une perte de la connexion de transport est un
résultat direct de la perte de la connexion de réseau.
A.4.8.2. La défaillance d'un système ou d'une application peut être détectée à
l'expirationd'un e temporisationpour la réceptiond'unmessage
PULSION attendu de cette application (voir paragraphe A.4.7).2000R2082 — FR — 15.06.2002 — 001.001 — 167
▼B
A.4.9. Reprise
A.4.9.1. Deux cas doivent être envisagés:
— après une défaillance de la connexion de transport;
— après une défaillance d'application.
A.4.9.2. Dans les deux cas, le rétablissement fait intervenir la procédure
normale d'établissement de l'association (voir paragraphe A.4.3), y
compris l'échange de messages de DÉMARRAGE.
NOTEEn cas de défaillance au niveau de l'application qui ne
provoque pas la libération de la connexion de la couche de
niveau inférieur, le système défaillant peut transmettre un
message d'ARRÊT (c'est-à-dire que l'arrêt de l'utilisateur
local est invoqué soit manuellement, soit dans le cadre
d'une fonction logique d'application) avant toute tentative
de rétablissement de la liaison. Cela ralentira le temporisa-
teur Tr de l'application distante et pourrait se traduire par
un rétablissement plus rapide, avec un moindre risque de
perte de données.
A.4.10. Formats des messages
A.4.10.1. Structure générale des messages
Tous les messages se composent d'un champ de type entier («TYP»)
de 1 … 63, suivi du texte du message. Le champ «TYP», qui
s'éten d sur unoctet, est codé encaractères ASCII enajoutan t '40'H
à la représentation binaire du champ (par exemple, la valeur 3 est
codée '43'H, caractère «C»). Le texte du message est codé encarac-
tères ASCII , un par octet. On obtient le format suivant:
TYPE Texte du message
octet 1 octet 2 … octet n
A.4.10.2. Longueur du texte du message
Des messages d'une longueur de texte allant jusqu'à 4 096 octets
doivent être admis.
A.4.10.3. Format des messages de système
Les messages de système sont codés suivant le modèle TYP = 4,
codé '44'H. Le texte du message comprend deux octets codés
comme suit:
— Message de DÉMARRAGE: '3031'H (ASCII digits "01");
— Message d'ARRÊT: '3030'H (ASCII digits "00");
— Message PULSION: '3033'H (ASCII digits "03").
A.4.10.4. Autres formats de message
Le champ TYP est fonction du type de message et codé suivant les
principes énoncés plus haut:
— valeur 1 (codée '41'H) messages opérationnels
— valeur 2 (codée '42'H) messages d'opérateur
— valeur 5 (codée '45'H) messages d'état.
NOTES
1. Le format du corps du texte des messages d'état n'entre pas dans
le cadre de la présente Norme Eurocontrol.
2. Le format des messages opérationnels est indiqué dans les
Normes et Documents normatifs d'Eurocontrol définissant les
applications de messagerie tels que l'échange de données en
ligne [Référence 13].
3. Les messages d'opérateur se composent d'un texte ASCII impri-
mable. Si ces messages sont acceptés, une interface utilisateur2000R2082 — FR — 15.06.2002 — 001.001 — 168
▼B
doit être fournie pour afficher les messages reçus et permettre la
composition de messages en vue de leur transmission.
A.5.Tableaux de transition des états de protocole
A.5.1. Introduction
Les tableaux d'état ci-dessous présentent les spécifications défini-
tives du protocole. En cas de divergence avec le texte principal ci-dessus, les spécifications ci-après doivent prévaloir.
NOTELa notation utilisée pour décrire les états, événements,
temporisateurs et mesures s'appuie sur le ST-ICD. Toutefois,
les définitions ci-après et les mesures qui en résultent ont
été revues et peuvent donc s'écarter des dispositions anté-
rieures.
A.5.2. Définition des états
Tableau 1
Définitions des états
État Description de l'état Information complémentaire sur l'état
état 0 IDLE Pas de connexion de transport
état 1 READY Connexion de transport établie, utili-
sateur local indisponible, utilisateur
distant indisponible
état 2 ASSOCIATION_-
PENDINGConnexion de transport établie, utili-
sateur local disponible, utilisateur
distant indisponible
état 3 DATA_READY Utilisateur local disponible, utilisateur
distant disponible2000R2082 — FR — 15.06.2002 — 001.001 — 169
▼B
A.5.3. Evénements possibles
Tableau 2
Événements possibles
Descriptionde l'évé-
nementComplément d'information sur l'état
L_data Indique que les données (message opérationnel, d'opérateur ou
d'état) doivent être envoyées par l'utilisateur local vers l'utilisateur
distant (primitive de demande de Données-TM)
L_shutdown Une commande est données pour arrêter l'utilisateur local
(demande d'Abandon-TM)
L_startup Une commande est donnée pour faire démarrer l'utilisateur local
(demande d'Association-TM)
R_data Indique que les données envoyées par l'utilisateur distant ont été
reçues (indication de Données de transport, TYP ≠«Système»)
R_heartbeat Un message PULSION de l'utilisateur distant est reçu (indication
de Données de transport, TYP = «Système», code de message =
PULSION)
R_shutdown Un message d'ARRÊT de l'utilisateur distant est reçu (indication
de Données de transport, TYP = «Système», code de message =
ARRÊT)
R_startup Un message DÉMARRAGE de l'utilisateur distant est reçu (indi-
cation de Données de transport, TYP = «Système», code de
message = DÉMARRAGE)
Ts_timeout Expirationdu temporisateur Ts
Tr_timeout Expirationdu temporisateur Tr
TC_disconnect Une indication de libération de la connexion de transport a été
reçue (indication de Déconnexion de transport)
TC_setup Evénement (commande explicite, Demande d'application, etc.) qui
entraîne une primitive de Demande de connexion de transport
A.5.4. Temporisateurs
Tableau 3
Temporisateurs
Temporisateur Information de temporisation
Tr Temporisation pendant laquelle un message PULSION ou de
données est attendu.
Ts Temporisationpour l'en voi d'unmessage PULSION à l'utilisateur
distant.
La valeur de ces temporisateurs doit être telle que Tr = 2Ts + délai
de transit.
NOTELes valeurs types de ces temporisateurs sont les suivantes:
Ts = 30s, Tr = 70s.2000R2082 — FR — 15.06.2002 — 001.001 — 170
▼B
A.5.5. Tableau de transition d'états
Tableau 4
Transition d'états
État Événement Mesures à prendre Nouvel état
état 0 TC_setup La couche transport tente d'établir
les connexions de couches infé-
rieures entre l'utilisateur local et
l'utilisateur distant; lorsque la
connexion a été établie, l'utilisa-
teur enest averti (1)état 1
TC_disconnect Le système prend les mesures
appropriées mais reste à l'état 0état 0
L_data Négligés état 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data À négliger (l'événement ne devrait
pas se produire)état 0
R_heartbeat
R_shutdown
R_startup
état 1 L_startup L'utilisateur local envoie un
message de DÉMARRAGE à l'uti-
lisateur distant; le temporisateur
est enclenché (2)état 2
R_startup L'utilisateur local reçoit un
message de DÉMARRAGE de
l'utilisateur distant; ce message de
DÉMARRAGE est négligé étant
donné qu'il n'y a pas eu d'événe-
ment de démarrage_Létat 1
L_data Négligé état 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Négligé état 1
Ts_timeout
L_shutdown La connexion de transport est
libéréeétat 0
TC_disconnect L'utilisateur local est averti que la
connexion de transport est décon-
nectée (par exemple en raison
d'une erreur ou d'un arrêt de l'uti-
lisateur distant)état 02000R2082 — FR — 15.06.2002 — 001.001 — 171
▼B
État Événement Mesures à prendre Nouvel état
état 2 R_startup L'utilisateur local reçoit un
message de DÉMARRAGE de
l'utilisateur distant; les temporisa-
teurs Tr et Ts sont mis en marche;
l'utilisateur local est averti que les
données peuvent être envoyées sur
l'associationet la réceptiondu
message de DÉMARRAGE est
expressément notifiée par l'envoi
enrépon se d'unautre message de
DÉMARRAGE(3)état 3
Tr_timeout L'utilisateur local retransmet un
message de DÉMARRAGE s'il n'a
pas reçu de message de DÉMAR-
RAGE de l'utilisateur distant dans
undélai spécifié Tr; le temporisa-
teur Tr est remis enmarcheétat 2
L_startup Négligé état 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdownL'utilisateur local est in vité à
arrêter l'association: un message
d'ARRÊT est transmis, le tempori-
sateur Tr est arrêté et la connexion
de transport est libéréeétat 0
TC_disconnect L'utilisateur local est averti que la
connexion de transport est libérée(par suite d'une erreur, par
exemple), le temporisateur Tr est
arrêté et l'associationest aban -
donnéeétat 02000R2082 — FR — 15.06.2002 — 001.001 — 172
▼B
État Événement Mesures à prendre Nouvel état
état 3 L_data Le temporisateur Ts est remis en
marcheétat 3
R_data Le temporisateur Tr est remis en
marcheétat 3
R_heartbeat
R_startup Si unmessage de DÉMARRAGE
est reçu de l'utilisateur distant, il
est considéré comme l'acquitte-
ment d'un message de DÉMAR-
RAGE envoyé antérieurement; le
temporisateur Tr n'est pas remis en
marcheétat 3
Ts_timeout Négligé état 3
L_startup Unmessage PULSION est en voyé
et le temporisateur Ts est remis en
marcheétat 3 (4)
TC_setup
R_shutdownLe temporisateur Ts est arrêté; un e
indication d'Abandon-TM est
signalée à l'utilisateur localétat 2
Tr_timeout Le temporisateur Ts est arrêté; une
indication d'Abandon-TM est
signalée à l'utilisateur local; le
temporisateur Tr est remis en
marcheétat 2
L_shutdownUn message d'ARRÊT est
transmis; les temporisateurs Tr et
Ts sont arrêtés et la connexion de
transport est libéréeétat 0
TC_disconnect L'utilisateur local est averti que la
connexion de transport est libérée
(par exemple, par suite d'une
erreur); les temporisateurs Ts et Tr
sont arrêtés et l'association est
abandonnéeétat 0
NOTES
(1) À l'entrée dans l'état 0, le déclenchement automatique de l'événement établissement-CT.
(2) Uniquement en cas d'entrée dans l'état 1 via un événement d'établissement-CT tel qu'il est décrit à
l'état 0, l'événement de démarrage_L pouvant alors être déclenché automatiquement.
(3) Cette méthode garantit qu'un message de DÉMARRAGE reçu d'un utilisateur distant fait toujours
l'objet d'unacquittemen t au moyende message de DÉMARRAGE.
(4) Certaines réalisations antérieures à la présente Norme Eurocontrol peuvent traiter cet événement
comme une libération-CT, ce qui implique un retour à l'état 0.
A.5.6. Diagramme de transition d'états
NOTELe protocole est présenté à la Figure A.1 sous forme de
digramme de transition d'états. Ce diagramme est fourni à
titre d'information: en cas de divergence entre le diagramme
et les tableaux d'états présentés plus haut, ce sont ces
derniers qui prévaudront.2000R2082 — FR — 15.06.2002 — 001.001 — 173
▼B
Figure A.1
Protocole de transfert de messages: Diagramme de transition d'états2000R2082 — FR — 15.06.2002 — 001.001 — 174
▼B
ANNEXE B (Normative)
PROTOCOLE D'EN-TÊTE DE MESSAGE
B.1.Introduction
La présente Annexe définit le protocole d'en-tête de message, proto-
cole de transport minimal destiné aux applications telles qu'OLDI.
B.2.Service mis en œuvre
B.2.1. Le protocole d'en-tête de message correspond à un sous-ensemble du
service de transport en mode connexion, tel qu'il est défini dans le
document ISO/IEC 8072 [Référence 11], et comprend les primitives
de service suivantes:
Connexion de transport: établit une connexion de transport pour une
application.
Données de transport: assure le transfert de données ASCII
Déconnexion de transport: met fin à la connexion de transport d'une
application.
B.2.2. Le service ne permet pas le multiplexage, le retour au fonctionnement
normal ni la segmentation ou le réassemblage.
B.3.Service requis
Le protocole suppose unservice fiable du réseau de base, tel qu'il est
assuré par le protocole X.25 encouche paquet.
NOTEUne seule connexion de transport est assurée sur chaque
connexion de réseau.
B.4.Spécifications du protocole
B.4.1. Établissement de la connexion
La primitive de Connexion de transport doit être mise en œuvre au
moyen du service de connexion de réseau du service réseau de la
couche de niveau inférieur. Il y a une correspondance exacte entre
les deux séries de primitives (de demande et d'indication). Autrement,
il est possible d'utiliser une connexion de réseau existante (par
exemple une connexion établie par les mécanismes de gestion du
système).
Recommandations
1. Dans le dernier cas ci-dessus, il convient de rétablir au préalable
la connexion de réseau. La primitive de connexion de réseau peut
être rediffusée automatiquement si aucune réponse n'est reçue
dans un délai donné.
2. Si cette procédure de répétition d'appel est appliquée, il convient
de répéter les appels toutes les 15 s environ.
B.4.2. Mesures visant à éviter la redondance des connexions de réseau
Si une primitive de demande de connexion de réseau est en attente
(c'est-à-dire qu'aucune primitive correspondante de confirmation de
connexion de réseau ou de déconnexion de réseau n'a été signalée)
et qu'une indication de connexion de réseau est signalée, la tentative
d'établissement de connexion de réseau à l'arrivée sera rejetée ou
libérée, par l'envoi en réponse d'une primitive de demande de décon-
nexion de réseau, uniquement lorsque les deux conditions ci-après
sont réunies:
— l'adresse du NSAP appelant de l'indication de connexion de
réseau est la même que l'adresse du NSAP appelé de la demande
de connexion de réseau en attente;
— l'adresse du NSAP appelant de la demande de connexion de
réseau en attente est plus longue que l'adresse du NSAP appelé
de la demande de connexion de réseau en attente, la comparaison
s'établissant sur la chaîne de bits formée par le codage binaire
préférentiel de chaque adresse NSAP, suivant la définition donnée
dans le document ISO/IEC 8348 Annexe A [Référence 10] (une
chaîne sera considérée comme plus longue que l'un de ses propres
sous-ensembles initiaux, par exemple, '8800'H>'88'H).2000R2082 — FR — 15.06.2002 — 001.001 — 175
▼B
B.4.3. Libération de la connexion
B.4.3.1. La libération de la Connexion de transport doit s'effectuer au moyen
des primitives de service de déconnexion de réseau et de rétablisse-
ment de réseau du service de réseau de la couche de niveau inférieur.
B.4.3.2. Pour mettre en œuvre une demande de Déconnexion de transport, une
demande de déconnexion de réseau doit être signalée. Autrement, si
l'établissement des connexions de réseau à l'aide des primitives de
connexion de réseau n'est pas possible, la connexion de réseau ne
doit pas être expressément libérée.
Recommendations Dans ce dernier cas, il convient de réinitialiser la
connexion de réseau.
B.4.3.3. Une indication de Déconnexion de transport doit être signalée dès
réception de l'une ou l'autre primitive de service de réseau sur une
connexion de réseau correspondant à une connexion entièrement ou
partiellement établie:
— indication de déconnexion de réseau;
— indication de réinitialisation de réseau.
B.4.4. Transfert de données
B.4.4.1. La primitive de Données de transport doit être mise en œuvre au
moyen de la primitive de données de réseau du service de réseau de
la couche de niveau inférieur. Il y a une correspondance exacte entre
les deux séries de primitives (de demande et d'indication). La corres-
pondance s'établit au moyen de l'unité de données de protocole de
transport qui est transférée par le service de réseau.
B.4.4.2. L'unité de données de protocole de transfert de données doit avoir le
format suivant, transmis de gauche à droite. La structure générale des
messages définie au paragraphe A.4.10.1 doit être insèrée dans les
champs data(1), data (2) … data (n).
STX LENG ADEST DEST AEMM EMM données(1) ADRdonnées(2)
…
données(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
NOTES
1. Cet en-tête est défini de façon à être identique à celui utilisé dans
la procédure INTERCAUTRA adoptée pour l'échange de messages
ACT entre CAUTRA Paris, le système 9020D du Centre de
contrôle de la circulation aérienne de Londres et le Central
d'échange de données numérique (DCTS) de Maastricht/Karls-
ruhe, lors du transport des formats de message définis en Annexe
A; dans le cas présent, le champ «données(1)» correspond au
champ TYP.
2. L'emploi des champs ADEST, DEST, AEMM, EMM, et ADR avec
des valeurs autres que '40'H sort du cadre de la présente Norme
Eurocontrol, mais peut faire l'objet d'accords bilatéraux.
B.4.4.3. Le service de données de transport doit être limité au transfert de
données imprimables en caractères ASCII. Plus particulièrement,
aucun des octets de données ne doit avoir la valeur '03'H (désignant
la finde texte).
B.4.4.4. Une réalisation conforme doit satisfaire à la condition d'exploitation
d'unités de données du service de réseau (NSDU) d'une taille allant
jusqu'à 4 105 octets compris.
B.4.4.5. Une réalisation conforme doit exclure la concaténation de TSDU
multiples en une NSDU unique.
B.4.4.6. Une réalisation conforme doit interdire la segmentation d'une TSDU
unique en plusieurs NSDU.2000R2082 — FR — 15.06.2002 — 001.001 — 176
▼B
ANNEXE C (Normative)
PROTOCOLE DE RÉSEAU
C.1.Introduction
La présente Annexe définit un protocole de réseau de base,
s'appuyant sur le protocole X.25 en couche paquet, destiné auxréseaux point à point et à commutation par paquets, pour le transfert
de données de vol. Le sous-ensemble de protocole est compatible
avec celui défini dans le document [Référence 1] dans ses versions à
compter de 1980.
C.2.Service assuré
C.2.1. Le protocole met enœuvre le service de réseau OSI enmode con n e-
xion, tel qu'il est défini dans la norme ISO/IEC 8348 [Référence 10],
sous réserve des exceptions suivantes:
— les adresses NSAP sont limitées à la forme définie au paragraphe;
— il n'y a pas de possibilité pour les utilisateurs du service de réseau
et le fournisseur du service de réseau de convenir d'une certaine
qualité de service associée à une connexion de réseau;
— à l'exceptionde la procédure décrite au paragraphe C.5.3, le tran s-
fert de données de l'utilisateur de la connexion de réseau pendant
l'établissement et la libération de la connexion de réseau n'est pas
assuré.
C.2.2. Les options suivantes du fournisseur du service de réseau ne sont pas
offertes:
— Confirmation de réception;
— Transfert de données exprès.
C.3.Service requis
Le protocole suppose la fourniture d'un service de liaison de données
OSI, tel qu'il est défini dans la norme ISO/IEC 7776 (LAPB)
[Référence 6].
C.4.Adresses NSAP
C.4.1. Introduction
C.4.1.1. La structure des adresses NSAP est conforme à la définition donnée
dans le document ISO/IEC 8348, Annexe A [Référence 10], comme
l'illustre le schéma ci-dessous:
C.4.1.2. Les éléments de l'adresse NSAP sont les suivants:
IDP: Partie initiale de domaine, comprenant les champs AFI et IDI
AFI: Identificateur d'autorité et de format
IDI: Identificateur de domaine initial
DSP: Partie spécifique de domaine
C.4.2. Structure de l'adresse NSAP
C.4.2.1. Aux fins de la présente Norme Eurocontrol, l'adresse doit être limitée
aux éléments suivants:
C.4.2.2. La valeur d'AFI 48 doit être utilisée, indiquant un format local d'IDI
avec une syntaxe abstraite décimale.
C.4.2.3. L'IDI est égal à zéro, suivant le format local.2000R2082 — FR — 15.06.2002 — 001.001 — 177
▼B
C.4.2.4. Le DSP doit consister en deux paires de chiffres décimaux, comme
suit:
— la première paire est un identificateur d'organisme de contrôle de
la circulation aérienne (ATC), qui identifie un système ATC et
donc, indirectement, une implantation;
— la seconde paire est un sélecteur d'organisme ATC, qui peut être
utilisé pour identifier une extrémité donnée à l'intérieur d'un orga-
nisme ATC.
C.4.2.5. La structure d'adresse NSAP qui enrésulte est la suivan te:
AFI DSP
48 Identificateur d'orga-
nisme ATCSélecteur d'organisme
ATC
C.4.3. Assignation des identificateurs et des sélecteurs d'organisme ATC
C.4.3.1. Il appartiendra à Eurocontrol d'assigner des identificateurs d'orga-
nisme ATC uniques à chaque système ATC tandis que l'assignation
des sélecteurs incombera aux instances compétentes de l'administra-
tion ou de l'organisation dont relève l'organisme ATC.
C.4.3.2. L'attribution des identificateurs d'organisme ATC au moment de l'éta-
blissement de la présente Norme est indiquée à l'Annexe G.
C.5.Spécifications du protocole
C.5.1. Aperçu
Le protocole se fonde sur le Protocole de convergence dépendant du
sous-réseau pour X.25 (1980), défini dans l'Annexe A du document
ISO/IEC 8878 [Référence 12], sous réserve des exceptions suivantes:
— le service de sélectionrapide n 'est pas utilisé; toutefois, le codage
défini dans l'Annexe A du document ISO/IEC 8878 [Référence 12]
pour le champ de données d'utilisateur en format étendu disponi-
ble avec le service de sélectionrapide est utilisé ici avec le
champ de données d'utilisateur en format de base dans les paquets
d'APPEL et APPEL ENTRANT, étant donné que les restrictions
appliquées aux paramètres admis pour le service de réseau garan-
tissent que l'information codée tient dans 16 octets;
— parmi les paramètres de service de réseau dont le codage est
défini dans le document ISO/IEC 8878 [Référence 12], seules les
adresses NSAP de l'appelé et de l'appelant (et uniquement sous la
forme définie au paragraphe C.4.2) sont envoyées dans le paquet
d'APPEL;
— le champ de données d'utilisateur n'est pas employé dans les
paquets COMMUNICATION ACCEPTÉE, COMMUNICATION
ÉTABLIE, DEMANDE DE LIBÉRATION ou INDICATION DE
LIBÉRATION;
— les autres procédures d'établissement et de libération de conne-
xion de réseau ne sont pas appliquées;
— la confirmation de remise au moyen du bit D n'est pas assurée.
NOTELes trois premières restrictions visent à garantir que toutes
les informations qui seront transmises entre deux ETTD
respecteront les limites fixées pour le champ de données d'uti-
lisateur dans le PCP X.25 (1980).
C.5.2. Codage des adresses
Les adresses NSAP de l'appelant et de l'appelé doivent être codées
selon le mode de codage binaire préférentiel défini dans le document
ISO/IEC 8348 Annexe A [Référence 10].
C.5.3. Codage du champ de données d'utilisateur
C.5.3.1. Par suite des conditions énoncées ci-dessus, le champ de données
d'utilisateur dans des paquets d'APPEL et APPEL ENTRANT doit
être codé suivant le modèle ci-dessous. Les 16 octets doivent être
transmis dans leur intégralité.2000R2082 — FR — 15.06.2002 — 001.001 — 178
▼B
Tableau 1
Codage du champ de données d'utilisateur
Descriptiondu champSemi-octet de rang
élevéSemi-octet de faible
rang
Octet 0: Identité du protocole bin(1000) bin(0100)
Octet 1: Type de code de message bin(0010) bin(0000)
Octet 2: Valeur du code de message bin(0000) bin(0001)
Octet 3: Type de paramètre = NSAP appelé bin(1100) bin(1001)
Octet 4: Longueur du paramètre bin(0000) bin(0110)
Octet 5: Valeur du paramètre (1eroctet) =
valeur AFIbin(0100) bin(1000)
Octet 6: Valeur du paramètre (2eoctet) =
identificateur d'organisme ATCchiffre de rang
élevéchiffre de faible rang
Octet 7: Valeur du paramètre (3eoctet) =
sélecteur d'organisme ATCchiffre de rang
élevéchiffre de faible rang
Octet 8: Type du paramètre = NSAP appe-
lantbin(1100) bin(1011)
Octet 9: Longueur du paramètre bin(0000) bin(0110)
Octet 10: Valeur du paramètre (1eroctet) =
valeur AFIbin(0100) bin(1000)
Octet 11: Valeur du paramètre (2eoctet) =
identificateur d'organisme ATCchiffre de rang
élevéchiffre de faible rang
Octet 12: Valeur du paramètre (3eoctet) =
sélecteur d'organisme ATCchiffre de rang
élevéchiffre de faible rang
Octet 13: Réservé pour utilisation ultérieure bin(0000) bin(0000)
Octet 14: Réservé pour utilisation ultérieure bin(0000) bin(0000)
Octet 15: Réservé pour utilisation ultérieure bin(0000) bin(0000)
C.5.3.2. Les autres paramètres décrits dans le document ISO/IEC 8878
[Référence 12], ne doivent pas être utilisés.
C.5.4. Traitement des adresses dans les paquets APPEL ENTRANT
C.5.4.1. Adresses d'ETTD
L'adresse de l'ETTD appelant dans un paquet APPEL ENTRANT
doit être validée par comparaisonavec un e liste locale d'adresses
d'ETTD distants valides pour le système. Si une adresse non valide
est détectée, l'appel doit être libéré.
NOTES
1. L'adresse de l'ETTD appelant dans un paquet APPEL ENTRANT,
si elle y figure, peut également être validée par comparaison avec
une liste (comportant généralement une rubrique) des adresses des
ETTD locaux valides pour le système.
2. Dans certains cas, l'adresse de l'ETTD d'un organisme peut varier
en valeur et/ou en longueur suivant que l'organisme est le système
appelant ou appelé. Il convient donc d'accorder une attentionparticulière à cette question lorsque la fonction de validation de
l'adresse de l'ETTD est spécifiée ou mise en œuvre.
C.5.4.2. Adresses des NSAP
L'adresse du NSAP appelant, codée suivant les modalités exposées ci-
dessus dans un paquet APPEL ENTRANT doit être validée par
comparaison avec une liste locale d'adresses de NSAP distants
valides pour le système. Si une adresse non valide est détectée,
l'appel doit être libéré.
NOTEL'adresse du NSAP appelé peut également être validée par
comparaison avec une liste (comportant généralement une
rubrique) des adresses locales des NSAP valides pour le
système.2000R2082 — FR — 15.06.2002 — 001.001 — 179
▼B
C.5.5. Transfert de données
C.5.5.1. Ainsi qu'il est exposé dans le document ISO/IEC 8878 Annexe A.5.3
[Référence 12], les NSDU sont transférées dans le champ de données
d'utilisateur d'unpaquet DONNÉES.
NOTEEn conséquence, il est interdit de transmettre plus d'un
message d'utilisateur, tel qu'un message OLDI, par paquet
X.25 ou séquence de paquets X.25 au moyen du bit M.
C.5.5.2. Les NSDU dont la longueur est supérieure au maximum admis par le
circuit virtuel pour les données d'utilisateur doivent être segmentés et
transmis dans les champs de données d'utilisateur d'une séquence de
paquets DONNÉES, qui auront tous, à l'exception du dernier, la
longueur maximale, le bit M indiquant qu'il y a des données à suivre.
C.5.5.3. Dès réception, les champs de données d'utilisateur d'une séquence de
données à suivre sont réassemblés de façon à former le NSDU reçu.2000R2082 — FR — 15.06.2002 — 001.001 — 180
▼B
ANNEXE D (Normative)
FORMULAIRES PICS DE CONFORMITÉ AU PROFIL
D.1.Introduction
D.1.1. Le fournisseur d'une instance de protocole déclarée conforme aux
spécifications des Annexes A à C doit remplir les formulaires PICS
ci-après.
NOTEDroits d'auteur applicables à la diffusion des formulaires
PICS: Les utilisateurs de la présente Norme Eurocontrol
peuvent reproduire librement les formulaires PICS figurant
dans la présente Annexe pour l'usage auquel ils sont destinés
et peuvent publier ensuite le formulaire PICS rempli.
D.1.2. Unformulaire PICS rempli est le PICS pour la mise enœuvre en
question. Le PICS est une déclaration indiquant les capacités et les
options du protocole qui ont été mises en œuvre.
D.1.3. Le PICS peut avoir différents usages et notamment servir:
— au réalisateur d'un protocole, comme liste de contrôle permettant
de réduire le risque de non-conformité à la norme pour cause
d'oubli;
— au fournisseur et à l'acquéreur, effectif ou potentiel, d'une réalisa-
tion, en donnant des informations détaillées sur les capacités de la
réalisation, par rapport à la base de référence commune fournie
par le formulaire-type PICS;
— à l'utilisateur, effectif ou potentiel, de la réalisation, comme
moyen de contrôle initial de la possibilité d'interfonctionnement
avec une autre réalisation (on remarquera que si l'interfonctionne-
ment ne peut jamais être garanti, l'incompatibilité des PICS
constitue souvent un indice de défaut d'interfonctionnement);
— au réalisateur d'unessai de protocole, comme base de sélection
des essais appropriés pour l'évaluationde la con formité de la
réalisation.
D.2.Comment remplir les formulaires PICS
D.2.1. Structure générale des formulaires PICS
D.2.1.1. L'identification de la réalisation et la synthèse du protocole forment
la première partie de tout formulaire PICS, qui doit être remplie
suivant les indications fournies, accompagnées des informations
nécessaires à une parfaite identification du fournisseur ainsi que de
la réalisation.
D.2.1.2. La partie principale du formulaire PICS est constituée d'un question-
naire de format-type. Les réponses aux diverses questions doivent
être données dans la colonne située à l'extrême droite, soit en cochant
la case appropriée en cas de choix restreint (en général Oui ou Non),
soit en inscrivant une valeur ou bien un ensemble ou une plage de
valeurs.
NOTES1. Chaque élément est identifié par une référence propre dans la
première colonne; le texte de la question posée figure dans la
deuxième colonne; la troisième colonne indique la ou les réfé-
rences aux paragraphes de la présente Norme Eurocontrol dans
lesquels l'élément est explicité. Les autres colonnes sont utilisées
pour indiquer l'état de l'élément (prise en charge obligatoire,
optionnelle, interdite ou conditionnelle) et répondre aux questions
posées; voir également le paragraphe D.2.4 ci-dessous.
2. Un fournisseur peut également soumettre, ou être tenu de
soumettre, d'autres informations qualifiées soit d'informations
supplémentaires, soit d'informations sur les conditions d'exception.
Le cas échéant, chaque information supplémentaire doit être
fournie dans une sous-rubrique d'élément étiquetée A<i> or
X<i> respectivement, aux fins de renvoi réciproque, <i> repré-
sentant toute identification non ambiguë de l'élément (par ex. un
simple numéral): il n'y a aucune autre restriction de format ou
de présentation.
D.2.1.3. Un formulaire PICS dûment rempli, accompagné le cas échéant des
informations supplémentaires et des conditions d'exception, doit être2000R2082 — FR — 15.06.2002 — 001.001 — 181
▼B
qualifié de Déclaration de conformité de l'instance de protocole pour
la réalisationenquestion .
NOTE Lorsqu'une réalisation admet plusieurs configurations, un
seul PICS peut suffire à décrire toutes les configurations
possibles. Toutefois, le fournisseur a la possibilité de
soumettre plusieurs formulaires, traitant chacun un sous-
ensemble de capacités de la configuration, si la présentation
des informations doit gagner en simplicité et en clarté.
D.2.2. Informations supplémentaires
Les informations supplémentaires permettent à un fournisseur de
soumettre d'autres renseignements de nature à faciliter l'interprétation
du PICS.
NOTES
1. Les informations supplémentaires fournies ne doivent pas néces-
sairement être nombreuses et un PICS peut être considéré
comme complet même s'il ne comporte aucune information de ce
type. Ces renseignements pourront par exemple servir à présenter
les façons dont une réalisation (unique) peut être constituée pour
fonctionner dans différents environnements et configurations; ou à
donner une explication succincte (pouvant reposer sur les besoins
d'une d'application particulière) des motifs d'exclusion de
certaines fonctions qui, bien qu'elles soient optionnelles, sont
néanmoins généralement présentes dans les réalisations du proto-
cole en question.
2. Les références aux éléments d'information supplémentaires
peuvent être inscrites en regard de toute réponse au question-
naire, et peuvent être incluses dans les éléments d'information
sur les conditions d'exception.
D.2.3. Informations sur les conditions d'exception
D.2.3.1. Il peut arriver parfois qu'un fournisseur souhaite répondre à un
élément de caractère obligatoire ou interdit (après application éven-
tuelle de conditions) d'une façon qui n'est pas compatible avecl'exigence indiquée. Aucune réponse n'aura été prévue pour ce cas
dans la colonne Prise en charge et le fournisseur doit l'inscrire lui-
même dans cette colonne, en ajoutant la mention X<i> pour désigner
un élément d'information sur les conditions d'exception.
D.2.3.2. Le fournisseur doit donner le justificatif approprié à la rubrique de
l'élément d'exception proprement dit.
D.2.3.3. Une réalisation nécessitant un élément d'exception dans ces condi-
tions n'est pas conforme aux présentes spécifications.
NOTELa situation décrite ci-dessus peut s'expliquer par le fait
qu'un défaut dans la norme à été signalé et qu'un correctif
devrait modifier la condition non satisfaite par la réalisation.
D.2.4. Éléments conditionnels
D.2.4.1. Chaque élément conditionnel est indiqué par un symbole particulier
de la forme «<élément>: 
» dans la colonne État, «<élément>»
désignant une référence qui figure dans la première colonne du
tableau pour certains autres éléments et «
» étant un symbole
d'état, M, O, O.<n> or X.
NOTEUn formulaire PICS peut comporter plusieurs éléments condi-
tionnels, pour lesquels tant l'applicabilité de l'élément
proprement dit que son état, si l'élément est applicable (obli-
gatoire, optionnel ou interdit) dépendent de la prise en
charge de certains autres éléments.
D.2.4.2. Si l'élément signalé par le symbole conditionnel est indiqué comme
étant accepté, il est applicable et son état est représenté par le
symbole «
»: la colonne Prise en charge doit être remplie selon
les règles habituelles. Si l'élément conditionnel n'est pas assuré, il
convient de répondre par Non applicable (NA).
D.2.4.3. Chaque élément affecté d'un symbole conditionnel est signalé par une
astérisque dans la colonne Elément.2000R2082 — FR — 15.06.2002 — 001.001 — 182
▼B
D.3.Formulaire PICS pour le protocole de transfert de messages
D.3.1. Abréviations et symboles spéciaux
D.3.1.1. Symboles d'état
M: obligatoireO: optionnel
D.3.1.2. Références des éléments
Les éléments du formulaire PICS sont désignés par des références
mnémoniques. Une même lettre ou paire de lettres initiales (en
majuscules) est attribuée aux éléments traitant de fonctions connexes.
On trouvera ci-après une liste de ces initiales, présentées suivant
l'ordre dans lequel les groupes d'éléments apparaissent dans le formu-
laire PICS.
— MTsy, MTop, MTst, MTor types de message
— MAE, MAR, MCI, MDT,
MAVprocédures
— MEsu, MEsd, MEhb, MEty codages
— MNmsg taille du message— Ts, Tr temporisateurs
D.3.2. Identification
2000R2082 — FR — 15.06.2002 — 001.001 — 183
▼B
D.3.3. Réalisation du protocole
D.4.Formulaire PICS pour le protocole d'en-tête de message
D.4.1. Abréviations et symboles spéciaux
D.4.1.1. Symboles d'état
M obligatoire
O optionnel
O.<n> optionnel, mais au moins une parmi le groupe
d'options identifiées par le même numéral <n> est
requise
X interdit<élément>: symbole d'élément conditionnel, qui dépend de
l'appui indiqué pour l'<élément>: voir le
paragraphe D.2.4
D.4.1.2. Abréviations
NA non applicable2000R2082 — FR — 15.06.2002 — 001.001 — 184
▼B
D.4.1.3. Références des éléments
Les éléments du formulaire PICS sont désignés par des références
mnémoniques. Une même lettre ou paire de lettres initiales (en
majuscules) est attribuée aux éléments traitant de fonctions connexes.
On trouvera ci-après une liste de ces initiales, présentées suivant
l'ordre dans lequel les groupes d'éléments apparaissent dans le formu-
laire PICS.
— IHC1, IHC2, IHC3, IHC4,
IHCCétablissement de connexion
— IHR1, IHR2 libération de connexion
— IHT1, IHTx transfert de données
— Tcr temporisateur
D.4.2. Identification
2000R2082 — FR — 15.06.2002 — 001.001 — 185
▼B
D.4.3. Réalisation du protocole
D.5.Formulaire PICS pour le protocole de réseau
D.5.1. Abréviations et Symboles spéciaux
D.5.1.1. Symboles d'état
M obligatoire
O optionnel
D.5.1.2. Références des éléments
Les éléments du formulaire PICS sont désignés par des références
mnémoniques. Une même lettre ou paire de lettres initiales (en
majuscules) est attribuée aux éléments traitant de fonctions connexes.
On trouvera ci-après une liste de ces initiales, présentées suivant2000R2082 — FR — 15.06.2002 — 001.001 — 186
▼B
l'ordre dans lequel les groupes d'éléments apparaissent dans le formu-
laire PICS.
— SNDCP1 champ d'identification du proto-
cole
— NCRdae, NCRgae, NCCx,
NDRxparamètres des messages de
protocole
— NCD1, NCD2, NCN1, NCN2 Validationdes adresses
— NDT transfert de données
D.5.2. Identification
2000R2082 — FR — 15.06.2002 — 001.001 — 187
▼B
D.5.3. Réalisation du protocole
2000R2082 — FR — 15.06.2002 — 001.001 — 188
▼B
ANNEXE E ( Normative )
LISTE DES SPÉCIFICATIONSDE PROFIL
E.1.Introduction
E.1.1. Cette Annexe donne la Liste des spécifications de profil (PRL) pour
le FDE ICD défini dans la présente Norme Eurocontrol. La Déclara-
tion de conformité applicable à une réalisation déclarée conforme au
présent profil doit être établie suivant les instructions ci-après.
NOTELes formulaires de la présente Annexe s'inspirent de ceux qui
sont joints aux normes de base citées en référence.
E.1.2. Une réalisation conforme doit remplir les conditions de conformité
obligatoires des normes de base citées en référence dans le présent
profil.
E.2.Rôle de la PRL et des formulaires PICS
La section E.2. a une valeur informative: elle ne constitue pas une
disposition de la présente partie de la Norme Eurocontrol.
— La présentation des conditions de conformité sous forme de
tableaux de PRL et de PICS vise à donner une liste de contrôle
des fonctions qui doivent ou peuvent être réalisées. Les principesdirecteurs sont définis et décrits dans le document ISO/IEC 9646-
1 [Référence 14], dont la Recommandation X.290 de l'UIT-T est
une équivalence, et dans le document ISO/IEC TR 10000-1
[Référence 2].
— Un profil propose une association d'options de plusieurs normes
de base en vue de répondre à une fonction particulière de traite-
ment de l'information. Les spécifications applicables à chaque
norme de base sont définies au moyen d'un formulaire PICS. La
PRL comprend le sous-ensemble des éléments du formulaire
PICS de la norme de base qui sont imposés par le profil, ainsi
que les conditions particulières du profil; elle définit les réponses
qui doivent être données aux formulaires PICS de la norme de
base pour que la réalisationsoit con forme. Enoutre, la PRL
comprendra des éléments de type PICS qui sont propres au profil
(ou, tout au moins, un élément destiné à vérifier que tous les
formulaires PICS requis ont été dûment remplis); ces rubriques
doivent être remplies conjointement avec les formulaires PICS
de la norme de base. L'ensemble des formulaires dûment remplis
constituent la Déclaration de conformité d'une réalisation du profil
(ICS).
— Suivant la méthode exposée dans le document ISO/IEC TR
10000-1 [Référence 2], une déclaration de conformité à un profil
doit être appuyée par des formulaires PICS remplis conformément
à la PRL. L'utilisation de ces documents sera fonction de la
méthode d'acquisition retenue pour une réalisation FDE ICD.
— Plusieurs méthodes peuvent être envisagées pour une réalisation
FDE:
— Réalisation interne assurée par une administration ou un orga-
nisme national: il convient d'utiliser la PRL comme base de
référence pour les spécifications des conditions et des essais
de réception de la réalisation; il convient de produire l'ICS
dûment rempli dans le cadre de la procédure de réception.
— Réalisationdu profil par unsous-traitan t: le matériel sera
utilisé et produit comme pour une réalisation interne, mais il
convient que le sous-traitant fournisse l'ICS, cette condition
devant faire partie des obligations contractuelles.
— Réalisation du profil par un sous-traitant dans le cadre d'un
marché clé enmainou d'unmarché d'in tégrationde systèmes:
le matériel sera utilisé et produit comme pour une réalisation
interne mais le sous-traitant devra s'acquitter de cette tâche au
niveau interne et fournir l'ICS dûment rempli. La conformité
au profil permet d'éviter, par exemple, qu'unfourn isseur
travaillant pour deux administrations n'introduise ses proto-
coles privés pour répondre aux conditions du FDE et ne
puisse ainsi contribuer à donner un contrôle aux administra-
tions contractantes.
— Intégration de produits disponibles sur le marché dans une
réalisation du profil, dans l'un des cas précités: il convient
que le fournisseur d'un produit présente les formulaires PICS2000R2082 — FR — 15.06.2002 — 001.001 — 189
▼B
relatifs au produit, dûment remplis conformément à la
présente PRL, et garantisse la conformité du produit aux
spécifications du profil qui sont applicables; ce PICS peut
ensuite être transmis en tant qu'élément de l'ICS du profil.
— Après la mise en œuvre, il convient de conserver l'ICS dans la
documentation de la réalisation; elle peut servir à déterminer le
potentiel d'interopérabilité avec d'autres administrations et les
modifications qui pourraient être nécessaires en cas d'adoption
d'autres protocoles.
E.3.Notation
E.3.1. L'état des diverses fonctions est indiqué suivant la notation ci-après,
reprise du document ISO/IEC TR 10000-1 [Référence 2]:
m: obligatoire
o: optionnel
-: non applicable (c'est-à-dire logiquement impossible dans le cadre
du profil)
x: exclu
NOTES
1. Des combinaisons de deux lettres peuvent être utilisées, auquel cas
la première lettre désigne l'état (de réalisation) statique, et la
seconde l'emploi dynamique; ainsi donc, «mo» signifie «réalisa-
tion obligatoire et à emploi optionnel».
2. La notation «o.<n>» désigne un ensemble d'options au choix
(c'est-à-dire qu'au moins une option de l'ensemble doit être
réalisée) avec le même identificateur n.
3. Une fonction signalée par la lettre «x» peut néanmoins faire partie
d'une réalisation pour autant qu'elle ne soit pas utilisée lorsque la
réalisation est exploitée dans le cadre du profil.
4. L'emploi de fonctions «x» nécessiterait un accord bilatéral. Dans
ce cas, il convient de revoir l'état des fonctions étant donné leur
incidence possible sur d'autres réalisations.
E.3.2. Les prédicats sont utilisés sous la forme suivante:
<prédicat>: introduit un groupe d'éléments qui sont tous conditionnels
selon le <prédicat> (l'importance du groupe est indiquée par la
présentation).
<prédicat&gt;: introduit un seul élément conditionnel selon le
<prédicat>.
NOTEDans chaque cas, le prédicat peut être l'identificateur d'une
fonction du profil ou une combinaison booléenne de prédicats
(«¬» est le symbole de négation logique.)
E.3.3. Les spécifications des normes de base sont indiquées suivant la même
notation en majuscules (c'est-à-dire, M, O, O.<n>, X).
E.4.Instructions pour remplir les formulaires PICS
E.4.1. Pour établir l'ICS du profil, les formulaires PICS des normes de base
citées en référence doivent être remplis et complétés par les autres
éléments PICS relatifs au profil mentionnés dans la présente Annexe.
E.4.2. Lorsque le profil apporte des affinements aux caractéristiques des
normes de base, les conditions fixées par cette PRL doivent être
appliquées (suivant les indications mentionnées pour l'élément dans
la colonne «Caractéristiques du profil») afin de limiter les réponses
admissibles dans les formulaires PICS de la norme de base.
E.4.3. Lorsque le profil fixe des conditions supplémentaires, la colonne de
réponse pour ces éléments doit être remplie. Dans cette colonne, la
réponse doit soit être choisie parmi les solutions proposées, soit
comprendre une valeur ou une gamme de valeurs de paramètre.
E.4.4. Si une condition obligatoire n'est pas satisfaite, des informations sur
les conditions d'exception doivent être jointes à un justificatif de
non-conformité, au moyen d'une référence X<i>, <i> étant un identi-
ficateur unique.
NOTEUn motif d'exception peut être le cas d'une réalisation pour
laquelle un rapport de défaut est en cours concernant une
disposition du profil; si le rapport de défaut est accepté, la
réalisation est alors jugée conforme.2000R2082 — FR — 15.06.2002 — 001.001 — 190
▼B
E.5.Références
E.5.1. Le présent profil renvoie aux spécifications des protocoles suivants:
— Protocole de transfert de messages (Annexe A à la présente
Norme Eurocontrol)
— Protocole d'en-tête de message (Annexe B à la présente Norme
Eurocontrol)
— Protocole de réseau en mode connexion faisant appel à la norme
ISO/IEC 8208 (Annexe C à la présente Norme Eurocontrol)
— ISO/IEC 7776 [Référence 6]— Normes relatives à la couche physique mentionnées dans la clause
1 de la Recommandation X.25 (1993) de l'UIT-T [Référence 1].
E.5.2. En l'absence de formulaire PICS spécifiquement prévu pour les
normes applicables à la couche physique, il convient d'utiliser les
formulaires PICS provisoires pour la couche physique figurant dans
le document ISO/IEC ISP 10609-9, clause A.4 [Référence 8].
E.6.Déclaration de conformité
E.6.1. Présentation générale de conformité
2000R2082 — FR — 15.06.2002 — 001.001 — 191
▼B
E.6.2. Conditions de conformité dynamique
E.7.Conditions applicables aux couches supérieures
Tableau 3
Protocole de transfert de messages
Caractéristiques des normes de baseCaractéristiques du
profil
ElémentProtocole de transfert de
messagesRéférences État Références État
MTst — messages d'état A.4.2 O ox
MTor — messages d'opéra-
teurA.4.2 O ox
E.8.Conditions applicables aux couches inférieures
E.8.1. Conditions applicables à la couche transport
Tableau 4
Protocole d'en-tête de message
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentProtocole d'en-tête de
messageRéférences État Références État
IHTx Utilisationdes champs
ADEST, DEST,
AEMM, EMM et ADR
avec des valeurs autres
que '40'HB.4.4 O ox
E.8.2. Conditions applicables à la couche réseau
Les PRL de la présente section s'inspirent du formulaire PICS de la
norme ISO/IEC 8208:1993 [Référence 7]. Les données de la colonne
«Références» sous «Caractéristiques des normes de base» dans les
tableaux qui suivent renvoient aux dispositions des normes correspon-
dantes.2000R2082 — FR — 15.06.2002 — 001.001 — 192
▼B
E.8.2.1. Caractéristiques générales de l'ETTD
Tableau 5
Caractéristiques générales de l'ETTD
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentCaractéristiques générales
de l'ETTDRéférences État Références État
Service admis
Vs — communication
virtuelleO.1 m
Vp — circuit virtuel
permanentO.1 x
Environnements
acceptés3, 3.2
Ec/3 — ETTD/ETCD(1993) O.2 6.3.2 o.2
Ec/8 — ETTD/ETCD(1988) O.2 6.3.2 o.2
Ec/4 — ETTD/ETCD(1984) O.2 6.3.2 o.2
Ec/0 — ETTD/ETCD(1980) O.2 6.3.2 o.2
Et/t — ETTD/ETTD en
emploi fixe entan t
qu'ETTDO.2 6.3.2 o.2
Et/c — ETTD/ETTD en
emploi fixe entan t
qu'ETCDVs: O.2 6.3.2 o.2
Et/d — ETTD/ETTD avec
sélectiondyn amique
d'emploi4.5 Vs: O.2 x
Numérotationséquen -
tielle des paquets
M8 — Modulo 8 13.2, 12.1.1,
Tableau 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Tableau 3O.3 x
Service complémen-
taire d'utilisateur
«numérotation option-
nelle» pour attribution
d'identificateur de voie
logique13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
RNa — sans retour à l'utili-
sationdes gammes
de voies logiques13.29.2.1 Et:O
¬Et:Xx
RNb — avec possibilité de
retour à l'utilisation
des gammes de
voies logiques13.29.2.1 Et:O
¬Et:Xx2000R2082 — FR — 15.06.2002 — 001.001 — 193
▼B
E.8.2.2. Procédures, types et formats des paquets
Tableau 6
Fonctions de la couche paquets indépendantes des voies logiques
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentFonctions de la couche
paquets indépendantes des
voies logiquesRéférences Etat Références État
Les fonctions de la
couche paquets
suivantes sont-elles
assurées:
Z2s Émissionde paquets
de diagnostic12.7, Tableau 24 Et:O
¬Et:Xx
Z4i Lancement de l'enre-
gistrement en ligne des
services complémen-
taires:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— émissionde la
DEMANDE D'ENRE-
GISTREMENT12.9.1
— réceptionde la
CONFIRMATION
D'ENREGISTRE-
MENT12.9.2, Tableau
10
Z4r Réponse à l'enregistre-
ment en ligne des ser-
vices complémentaires:13.1, 13.1.1.1,
13.1.1.4Et:O –
— réceptionde la
DEMANDE D'ENRE-
GISTREMENT12.9.1
— émissionde la
CONFIRMATION
D'ENREGISTRE-
MENT12.9.2, Tableau
10
Tableau 7
Établissement de communication
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentÉtablissement de communi-
cationRéférences État Références État
Les communications
virtuelles sortantes
sont-elles admises:5.2.1, 5.2.5,
Tableau 33
S1a — Sélectionrapide,
sans restriction sur la
réponse?5.2.4, 13.16 O x
S1b — Sélectionrapide
avec réponse
restreinte?13.16 O x
S1c — Sélectionn on
rapide?5.2.4 O m
SP1b d'APPEL, format de
base12.2.3.1 S1c:M
S1ab: O.4m
SP1e émissiond'unpaquet
d'APPEL, format
étendu12.2.3.1,
12.2.3.2S1ab: O.4 x2000R2082 — FR — 15.06.2002 — 001.001 — 194
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentÉtablissement de communi-
cationRéférences État Références État
SP2b réceptionde COMMU-
NICATION ÉTABLIE,
format de base12.2.4.1 S1ac:M m
SP2e réceptionde COMMU-
NICATION ÉTABLIE,
format étendu12.2.4.1,
12.2.4.2S1a:M –
D'autres adressages
pour communications
virtuelles sortantes
sont-ils admis:13.28
— enutilisan t A=1 et
une adresse élargie
sous forme de blocs?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— enutilisan t le
service d'extension
d'adresse de l'appelé?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Les communications
virtuelles entrantes
sont-elles admises:5.2.2, 5.2.5,
Tableau 33
S2a — Sélectionrapide
avec acceptation
possible?5.2.3, 13.17 O –
S2b — Sélectionrapide
toujours libérée?13.17 O m
S2c — Sélectionn on
rapide avec acceptation
possible?5.2.3 O m
S2d — Sélectionn on
rapide toujours libérée?5.2.3 O x
SP3b Réceptiondes
APPELS ENTRANTS,
format de base12.2.3.1 S2:M m
SP3e Réceptiondes
APPELS ENTRANTS,
format étendu12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b Émissiond'un
COMMUNICATION
ACCEPTÉE, format de
base12.2.4.1 S2c:M
S2axc:
O.5m
SP4e Émissiond'un
COMMUNICATION
ACCEPTÉE, format
étendu12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
La négociation du bit
D est-elle assurée:
DN1 — pour les communi-
cations virtuelles
sortantes6.3 S1ac:O m
DN2 — pour les communi-
cations virtuelles
entrantes6.3 S1ac:O m
NOTE Le bit D doit toujours être négocié à la valeur 02000R2082 — FR — 15.06.2002 — 001.001 — 195
▼B
Tableau 8
Libérationde commun ication
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentLibérationde commun ica-
tionRéférences État Références État
La libérationde
communication est-elle
assurée dans les cas
suivants:5.5.4, Tableau
33
C1 — réponse à une Indi-
cationde libération5.5.2 O m
C2a — abandon d'une
tentative de communi-
cationvirtuelle
sortante?5.4, 5.5.1, 5.5.3 S1:O o
C2b — rejet d'une commu-
nication virtuelle
entrante?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd:
Om
C2c — commande de libé-
ration d'une communi-
cationvirtuelle établie?5.5.1, 5.5.3 O o
CP1b Réceptiond'un e INDI-
CATION DE
LIBÉRATION, format
de base12.2.5.1 Cany:M m
CP1e Réceptiond'un e INDI-
CATION DE
LIBÉRATION, format
étendu12.2.5.1,
12.2.5.2Cany:M –
CP2b Emissiond'un e
CONFIRMATION DE
LIBÉRATION, format
de base12.2.6.1 C1:M m
CP2e Emission d'une confir-
mationde LIBÉRA-
TION, format étendu12.2.6.1,
12.2.6.2C1rn:M x
CP3b Emissiond'un e
DEMANDE DE
LIBÉRATION, format
de base12.2.5.1 C2a:M
C2bcxa:
O.6m
CP3e Emissiond'un e
DEMANDE DE
LIBÉRATION, format
étendu12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b Réceptiond'un e
CONFIRMATION DE
LIBÉRATION, format
de base12.2.6.1 C2:M m
CP4e Réceptiond'un e
CONFIRMATION DE
LIBÉRATION, format
étendu12.2.6.1,
12.2.6.2C2rnci:M –2000R2082 — FR — 15.06.2002 — 001.001 — 196
▼B
Tableau 9
Réinitialisation des voies logiques
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentRéinitialisation des voies
logiquesRéférences État Références État
La réinitialisation est-
elle assurée:8, 8.4, Tableau
34
RSi — enqualité d'appe-
lant?8.1, 8.3 O mm
DEMANDE DE
RÉINITIALISATION
à l'émission12.5.1
INDICATION/
CONFIRMATION DE
RÉINITIALISATION
à la réception12.5.2, 12.5.1
RSr — enqualité d'appelé? 8.2 O mm
INDICATION de
RÉINITIALISATION
à la réception12.5.1
CONFIRMATION de
RÉINITIALISATION
à l'émission12.5.2
Tableau 10
Procédures d'erreur
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentProcédures d'erreur (Service
de communications
virtuelles)Références État Références État
La procédure
d'ERREUR-C corres-
pond-elle à:5.2.1, 5.4, 8.1,
Tableau 33
W1a — la libérationde la
communication
virtuelle?O.7 m
W1b — la reprise de la
couche paquets?O.7 x
La procédure
d'ERREUR-R appli-
cable aux communica-
tions virtuelles
correspond-elle à:6.3, 6.4, 6.6,
6.8.1, 6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1, 13.4.1,
Tableaux 34-36
W2sc — la reprise de la
couche paquets?O.8 x2000R2082 — FR — 15.06.2002 — 001.001 — 197
▼B
Tableau 11
Transfert des interruptions
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Transfert des interruptions Références État Références État
Is Les interruptions à
l'émissionson t-elles
admises?6.8, 6.8.1, 6.8.3,
Tableau 35Oo x
— DEMANDE
D'INTERRUPTION à
l'émission12.3.2
CONFIRMATION
D'INTERRUPTION à
la réception12.3.3
Ir Les interruptions à la
réceptionson t-elles
admises?6.8, 6.8.2, 6.8.3
Tableau 35O–
— INDICATION
D'INTERRUPTION à
la réception12.3.2
— CONFIRMATION
D'INTERRUPTION à
l'émission12.3.3
Tableau 12
Émission de données
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Émission de données Références État Références État
DS1 L'envoi de paquets de
DONNÉES est-il
admis?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Les cas suivants sont-
ils acceptés:
DS2 — envoi de la rotation
de la fenêtre dès
réceptiondes valeurs
P(R) actualisées?7.1, 7.1.2, 7.1.3 O mm
DS4a — envoi de M=0 dans
les paquets
DONNÉES?6.4, 6.5, 6.7 M mo.9
DS4b — envoi de M=1 dans
les paquets
DONNÉES?6.4, 6.5, 6.7 O mo.9
DS5a — envoi de Q=0 dans
les paquets
DONNÉES?6.6 O.10 mm
DS5b — envoi de Q=1 dans
les paquets
DONNÉES?6.6 O.10 ox
DS6 — réponse aux
demandes de retrans-
missionde paquets
(paquets REJET
reçus)?13.4.2 12.8 Et:O –
— Procédure de
temporisationde la
rotationde la fen être?
DS7a — Mesure d'erreur R à
l'expiration11.2.1(a) O ox2000R2082 — FR — 15.06.2002 — 001.001 — 198
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Émission de données Références État Références État
DS7b — retransmission de
paquets à l'expiration11.2.1(b) Et:O
¬Et:Xox
DS8 — mise au rebut des
paquets de contrôle de
flux dont la longueur
dépasse la limite
admissible (à la place
d'une ERREUR-R)?Tableau 36 Note
2Oo x
Tableau 13
Réception de données
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Réception de données Références État Références État
DR1 La réceptionde
paquets de DONNÉES
est-elle acceptée?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Les cas suivants sont-
ils admis:
DR2 — rotationde la
fenêtre en réception
par envoi des valeurs
P(R) actualisées?7.1.2, 7.1.3 O mm
DR3 — contrôle de flux par
envoi de paquets NON
PRÊT À RECEVOIR
et PRÊT À RECE-
VOIR?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — réceptionde M=1
dans les paquets de
DONNÉES?6.4, 6.5, 6.7 O mm
DR5a — réceptionde Q=0
dans les paquets de
DONNÉES?6.6 O.11 mm
DR5b — réceptionde Q=1
dans les paquets de
DONNÉES?6.6 O.11 –
DR6 — demande de
retransmission de
paquets par émission
de paquets REJET?13.4.1, 12.8 O ox
— reprise, après
réceptionde paquets
DONNÉES contenant
des P(S) non valables,
par les moyens
suivants:
DR7a — mesure d'ERREUR-
R?11.3(a) O.12 mm
DR7b — demande de
retransmission de
paquets?11.3(b) O.12 ox
DR7c — ne pas tenir compte
du paquet et attendre
qu'unpaquet correct
soit retransmis?11.3(c) O.12 ox2000R2082 — FR — 15.06.2002 — 001.001 — 199
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Réception de données Références État Références État
— reprise après récep-
tionde paquets
DONNÉES comportant
un champ de données
d'utilisateur non
valable, par les moyens
suivants:
DR8a — mesure d'ERREUR-
R?11.3(a) O.13 mm
DR8b — demande de
retransmission des
paquets?11.3(b) O.13 ox
DR8c — ne pas tenir compte
du paquet et attendre
qu'unpaquet correct
soit retransmis?11.3(c) O.13 ox
DR9 — procédure de
temporisationde la
transmission du statut
de la fenêtre?11.2.2 O ox
Tableau 14
Confirmation de remise
Caractéristiques des normes de baseCaractéristiques du
profil
Élément Confirmation de remise Références État Références État
DC La confirmation de
remise est-elle assurée?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Caractéristiques et options diverses
Tableau 15
Valeurs des codes de cause et de diagnostic
Caractéristiques de la norme de baseCaractéristiques du
profil
ÉlémentValeurs des codes de cause
et de diagnosticRéférences État Références État
Dans les paquets
DEMANDE DE
REPRISE envoyés:12.6.1.1,
12.6.1.2, Tables
24-25
Y1d — Cause=128, codes
de diagnostic privésO.14 ox
Dans les paquets
INDICATION DE
REPRISE reçus:12.6.1.1,
Tableau 9,
12.6.1.2
Y2b — Cause ni 0 ni 128,
toute valeur de code de
diagnosticEC:M
¬EC:Om
Dans les paquets
DEMANDE DE
LIBÉRATION
envoyés:12.2.3.1.1,
12.2.3.1.2,
Tables 24-25
Y3d — Cause=128, codes
de diagnostic privésO.15 ox2000R2082 — FR — 15.06.2002 — 001.001 — 200
▼B
Caractéristiques de la norme de baseCaractéristiques du
profil
ÉlémentValeurs des codes de cause
et de diagnosticRéférences État Références État
Dans les paquets
INDICATION DE
REPRISE reçus:12.2.3.1.1,
Tableau 7
12.2.3.1.2,
Y4b — Cause ni 0 ni 128,
toute valeur de code de
diagnosticEC:M
¬EC:Om
Dans les paquets
DEMANDE DE
RÉINITIALISATION
envoyés:12.5.1.1,
12.5.1.2, Tables
24-25
Y5d — Cause=128, codes
de diagnostic privésO.16 ox
Dans les paquets
INDICATION DE
RÉINITIALISATION
reçus:12.5.1.1,
Tableau 8,
12.5.1.2
Y6b — Cause ni 0 ni 128,
toute valeur de code de
diagnosticEC:M
¬EC:Om
E.8.2.4. Services complémentaires
Tableau 16
Services complémentaires envoyés par les paquets d'APPEL
Caractéristiques de la norme de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés par les paquets
d'APPELRéférences État Références État
FS1pi Négociationdes para-
mètres de contrôle de
flux, taille des paquets13.12, 15.2.2.1.1 O x
FS1wi Négociationdes para-
mètres de contrôle de
flux, taille de fenêtre13.12, 15.2.2.1.2 O x
FS2ib Négociationde la
classe de débit de base13.13,
15.2.2.2.1,
Tableau 20aOx
FS2ie Négociationde la
classe de débit étendu13.13,
15.2.2.2.2,
Tableau 20bOx
FS3b Choix du groupe fermé
d'utilisateurs, format de
base13.14.6,
15.2.2.3.1Oo
FS3e Choix du groupe fermé
d'utilisateurs, format
étendu13.14.6,
15.2.2.3.2Ox
FS4b Choix du groupe fermé
d'utilisateurs avec
accès sortant, format
de base13.14.7,
15.2.2.4.1Ox
FS4e Choix du groupe fermé
d'utilisateurs avec
accès sortant, format
étendu13.14.7,
15.2.2.4.2Ox
FS5 Choix du groupe fermé
d'utilisateurs bilatéral13.15, 15.2.2.5 O x
FS6a Sélectionrapide 13.16, 15.2.2.6 O x2000R2082 — FR — 15.06.2002 — 001.001 — 201
▼B
Caractéristiques de la norme de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés par les paquets
d'APPELRéférences État Références État
FS6b Taxationà l'arrivée 13.18, 15.2.2.6 O x
FS6c Choix du statut
d'ICRD13.25.4.2,
15.2.2.6Ox
FS7i Identification de l'utili-
sateur du réseau13.21, 13.21.3,
15.2.2.7Ox
FS8i Service de demande
d'information de taxa-
tion13.22, 15.2.2.8.1 O x
FS9b Choix de l'EPR, format
de base13.23, 13.23.2,
15.2.2.9.1Ox
FS9e Choix de l'EPR, format
de étendu13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Sélectionet in dication
de délai de transit13.27, 15.2.2.13 O x
FS99i Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FS98i Services complémen-
taires distants autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FS20i Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FS21i Extension de l'adresse
de l'appelant14.1, 15.3.2.1 x
FS22i Extension de l'adresse
de l'appelé14.2, 15.3.2.2 x
FS23ib Négociationde la
classe de débit mini-
male, format de base14.3, 15.3.2.3.1,
Tableau 20aOx
FS23ie Négociationde la
classe de débit mini-
male, format étendu14.3, 15.3.2.3.2,
Tableau 20bO
FS24i Négociationdu délai
de transit de bout en
bout14.4, 15.3.2.4 O x
FS25i Négociationdes
données exprès14.7, 15.3.2.7 O x
FS26i Priorité 14.5, 15.3.2.5 O x
FS27i Protection14.6, 15.3.2.6 O x
Tableau 17
Services complémentaires envoyés dans les paquets COMMUNICATION ACCEPTÉE
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés dans les paquets
COMMUNICATION
ACCEPTÉERéférences État Références Etat
FS1pr Négociationdes para-
mètres de contrôle de
flux, taille des paquets13.12,
15.2.2.1.1,
Tableau 13Ox2000R2082 — FR — 15.06.2002 — 001.001 — 202
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés dans les paquets
COMMUNICATION
ACCEPTÉERéférences État Références Etat
FS1wr Négociationdes para-
mètres de contrôle de
flux, taille de fenêtre13.12,
15.2.2.1.2,
Tableau 13Ox
FS2rb Négociationde la
classe de débit de base13.13,
15.2.2.2.1,
Tableau 20aOx
FS2re Négociationde la
classe de débit étendu13.13,
15.2.2.2.2,
Tableau 20bOx
FS7r Identification de l'utili-
sateur du réseau13.21, 13.21.3
15.2.2.7Ox
FS8r Service de demande
d'information de taxa-
tion13.22, 15.2.2.8.1 O x
FS10r Notificationde modifi-
cationde l'adresse de
la ligne de l'appelé13.26, 15.2.2.12 O x
FS99r Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1.Tableau 18 O x
FS98r Services complémen-
taires distants autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FS20r Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FS22r Extension de l'adresse
de l'appelé14.2, 15.3.2.2 O x
FS24r Négociationdu délai
de transit de bout en
bout14.4, 15.3.2.4 O x
FS25r Négociationdes
données exprès14.7, 15.3.2.7 O x
FS26r Priorité 14.5, 15.3.2.5 O x
FS27r Protection14.6, 15.3.2.6 O x
Tableau 18
Services complémentaires envoyés dans les paquets d'APPEL
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés dans les paquets
DEMANDE D'APPELRéférences État Références État
FS10d Notificationde modifi-
cationde l'adresse de
la ligne de l'appelé13.26, 15.2.2.12 O x
FS13 Choix de déviationdes
appels13.25.2.2,
15.2.2.10Ox
FS99d Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x2000R2082 — FR — 15.06.2002 — 001.001 — 203
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
envoyés dans les paquets
DEMANDE D'APPELRéférences État Références État
FS98d Services complémen-
taires distants autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FS20d Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FS22d Extension de l'adresse
de l'appelé14.2, 15.3.2.2 O x
Tableau 19
Services complémentaires reçus dans les paquets APPEL ENTRANT
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
APPEL ENTRANTRéférences État Références État
FR1pi Négociationdes para-
mètres de contrôle de
flux, taille des paquets13.12, 15.2.2.1.1 O x
FR1wi Négociationdes para-
mètres de contrôle de
flux, taille de fenêtre13.12, 15.2.2.1.2 O x
FR2ib Négociationde la
classe de débit de base13.13, 15.2.2.2.1
Tableau 20aOx
FR2ie Négociationde la
classe de débit étendu13.13, 15.2.2.2.2
Tableau 20bOx
FR3b Choix du groupe fermé
d'utilisateurs, format de
base13.14.6,
15.2.2.3.1Oo
FR3e Choix du groupe fermé
d'utilisateurs, format
étendu13.14.6,
15.2.2.3.2Ox
FR4b Choix du groupe fermé
d'utilisateurs avec
accès sortant, formatde base13.4.7,
15.2.2.4.1Ox
FR4e Choix du groupe fermé
d'utilisateurs avec
accès sortant, format
étendu13.4.7,
15.2.2.4.2Ox
FR5 Choix du groupe fermé
d'utilisateurs bilatéral13.15, 15.2.2.5 O x
FR6a Sélectionrapide 13.16, 13.17,
15.2.2.6Ox
FR6b Taxationà l'arrivée 13.18, 13.19,
15.2.2.6Ox
FR11 Notificationde réache-
minement ou de dévia-
tiondes appels13.25.3,
15.2.2.11Ox
FR12i Sélectionet in dication
de délai de transit13.27, 15.2.2.13 O x
FR99i Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x2000R2082 — FR — 15.06.2002 — 001.001 — 204
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
APPEL ENTRANTRéférences État Références État
FR20i Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FR21 Extension de l'adresse
de l'appelant14.1, 15.3.2.1 x
FR22i Extension de l'adresse
de l'appelé14.2, 15.3.2.2 x
FR23b Négociationde la
classe de débit mini-
male, format de base14.3, 15.3.2.3.1,
Tableau 20aOx
FR23e Négociationde la
classe de débit mini-
male, format étendu14.3, 15.3.2.3.2,
Tableau 20bOx
FR24i Négociationdu délai
de transit de bout en
bout14.4, 15.3.2.4 O x
FR25i Négociationdes
données exprès14.7, 15.3.2.7 O x
FR26i Priorité 14.5, 15.3.2.5 O x
FR27i Protection14.6, 15.3.2.6 O x
Tableau 20
Services complémentaires reçus dans les paquets COMMUNICATION ÉTABLIE
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
COMMUNICATION
ÉTABLIERéférences État Références État
FR1pr Négociationdes para-
mètres de contrôle de
flux, taille des paquets13.12,
15.2.2.1.1,
Tableau 14Ox
FR1wr Négociationdes para-
mètres de contrôle de
flux, taille de fenêtre13.12,
15.2.2.1.2,
Tableau 14Ox
FR2rb Négociationde la
classe de débit de base13.13,
15.2.2.2.1,
Tableau 20aOx
FR2re Négociationde la
classe de débit étendu13.13,
15.2.2.2.2,
Tableau 20bOx
FR10r Notificationde modifi-
cationde l'adresse de
la ligne de l'appelé13.26, 15.2.2.12 O x
FR12r Sélectionet in dication
de délai de transit13.27, 15.2.2.13 O x
FR99r Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FR20r Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FR22r Extension de l'adresse
de l'appelé14.2, 15.3.2.2 O x2000R2082 — FR — 15.06.2002 — 001.001 — 205
▼B
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
COMMUNICATION
ÉTABLIERéférences État Références État
FR24r Négociationdu délai
de transit de bout en
bout14.4, 15.3.2.4 O x
FR25r Négociationdes
données exprès14.7, 15.3.2.7 O x
FR26r Priorité 14.5, 15.3.2.5 O x
FR27r Protection14.6, 15.3.2.6 O x
Tableau 21
Services complémentaires reçus dans les paquets INDICATION DE LIBÉRATION
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
INDICATION DE
LIBÉRATIONRéférences État Références État
FR8ad Information de taxa-
tion, unité monétaire13.22, 15.2.2.8.2 O x
FR8bd Information de taxa-
tion, nombre de
segments13.22, 15.2.2.8.3 O x
FR8cd Information de taxa-
tion, durée de l'appel13.22, 15.2.2.8.4 O x
FR10d Notificationde modifi-
cationde l'adresse de
la ligne de l'appelé13.26, 15.2.2.12 O x
FR99d Services complémen-
taires locaux autres
que X.25, selon
marqueur de service15.1, Tableau 18 O x
FR20d Marqueur de service,
Services complémen-
taires d'ETTD spécifiés
par le CCITT15.1 O x
FR22d Extension de l'adresse
de l'appelé14.2, 15.3.2.2 O x
Tableau 22
Services complémentaires reçus dans les paquets CONFIRMATION DE LIBÉRATION
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentServices complémentaires
reçus dans les paquets
CONFIRMATION DE
LIBÉRATIONRéférences État Références État
FR8af Information de taxa-
tion, unité monétaire13.22, 15.2.2.8.2 O x
FR8bf Information de taxa-
tion, nombre de
segments13.22, 15.2.2.8.3 O x
FR8cf Information de taxa-
tion, durée de l'appel13.22, 15.2.2.8.4 O x2000R2082 — FR — 15.06.2002 — 001.001 — 206
▼B
E.8.2.5. Valeurs et plages des paramètres
Tableau 23
Valeurs et plages des paramètres
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentValeurs et plages des para-
mètresRéférences État Références État
Valeurs admises:
V1s — Taille des paquets
par défaut (enémis-
sion)16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octets6.3.2 Au
moins
128 et
256
V1r — Taille des paquets
par défaut (enrécep-
tion)16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octets6.3.2 Au
moins
128 et
256
V2s — Taille de fenêtre par
défaut (enémission )16.2.2.6 (M8: dans
la plage
1-7)2
V2r — Taille de fenêtre par
défaut (enréception )16.2.2.6 (M8: dans
la plage
1-7)2
E.8.3. Conditions applicables à la couche liaison de données
Les PRL de la présente section s'appuient sur le formulaire PICS de
la norme ISO/IEC 7776:1994 [Référence 6]. Les mentions dans la
colonne «Références» de la rubrique «Caractéristiques des normes
de base» renvoient aux dispositions des normes visées.
Tableau 24
Protocole de liaison de données
Caractéristiques des normes de baseCaractéristiques du
profil
ÉlémentProtocole de liaisonde
donnéesRéférences État Références État
Lm Procédure multiliaisons 6 O ox
Lc Fonctionnement
ETTD/ETCD1, 5.1 M mo.1
Lt Fonctionnement
ETTD/ETTD1, 5.1 O mo.1
M8 Fonctionnement en
mode normal (Modulo
8)1, 3, 4.1.1 O.1 mm
M128 Fonctionnement en
mode étendu (Modulo
128)1, 3, 4.1.1 O.1 ox
T4 Procédure de tempori-
sationT45.3.2, 5.6.1 O mm
SPN1 Nombre maximum
(N1) de bits dans une
trame I5.7.3 N1 ≥
1 080N1≥
2 104
SPk Nombre maximum de
trames (k) en instance5.7.4 1 ≤k≤
7k=72000R2082 — FR — 15.06.2002 — 001.001 — 207
▼B
E.8.4. Conditions applicables à la couche physique
Voir le document ISO/IEC TR 10609-9, clause A.4 [Référence 8].2000R2082 — FR — 15.06.2002 — 001.001 — 208
▼B
ANNEXE F (Informative)
MÉTHODES DE TEST DE CONFORMITÉ
F.1.Introduction
F.1.1. Il importe que les réalisations du présent ICD soient telles qu'elles
engendrent un haut niveau de confiance, dans l'optique de l'interfonc-
tionnement des centres de contrôle de la circulation aérienne (ATCC)
au moyende l'in terface.
F.1.2. Il est probable que les États membres utilisent plusieurs sources
d'approvisionnement pour réaliser l'interface. Pour obtenir un niveau
de confiance élevé dans l'interfonctionnement de ces réalisations, il
est nécessaire d'établir un ensemble commun de conditions de test
de conformité de façon à uniformiser la préparation et le déroulement
des tests ainsi que la présentation des résultats.
F.2.Objet et portée
F.2.1. La présente Annexe définit les conditions applicables aux tests de
conformité des réalisations de la présente Norme Eurocontrol, dont
elle fait partie intégrante.
F.2.2. Elle désigne les mécanismes par lesquels la confiance dans l'interface
déclarée peut s'établir au moyende tests de validationde la deman de.
F.3.Bibliographie
Le document ci-après présente un intérêt pour les tests de réalisations
de la présente Norme Eurocontrol:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Part 1 Integration Test Plan Version 1, dated 10 May
1996 [Référence 15] (disponible uniquement en langue anglaise).
F.4.Méthodes et procédés de mise au point
F.4.1. Les réalisations de l'ICD peuvent faire appel à certaines options et
versions de l'ICD proprement dit. Pour démontrer les possibilités
d'interfonctionnement, un État membre réalisant l'interface doit faire
connaître les éléments de l'ICD qui sont acceptés, en soumettant une
déclaration précise sur les capacités, et les limites éventuellement
applicables aux paramètres variables.
F.4.2. Il convient de soumettre toute réalisation à un test de conformité tel
qu'il est décrit ci-dessous.
F.5.Tests
F.5.1. Introduction
F.5.1.1. Afin d'établir la confiance nécessaire et d'apporter l'appui voulu à
l'interface FDE au sein d'un ATCC en vue de l'interfonctionnement
d'applications FDE coopérantes, il est souhaitable que chaque réalisa-
tion soit soumise à des tests de conformité aux normes dont la
présente Annexe fait partie. Ces tests, qui concernent le comporte-
ment extérieur du système à tester (SUT), sont destinés à mesurer la
capacité d'interfonctionnement du système terminal et non son apti-
tude à fournir un service donné.
F.5.1.2. Les résultats de ces tests peuvent servir de preuves à l'appui d'une
déclaration de conformité soumise conformément à la Section 6.1 de
la présente partie de la Norme Eurocontrol. Les formulaires PICS et
les PRL évoqués dans les présentes spécifications de profil peuvent
être utilisés comme de base de départ; en outre, les normes internatio-
nales (par exemple la norme ISO/IEC 8208 [Référence 7]) peuvent
comporter des suites de tests abstraits définies qui peuvent être
exploitées dans les tests de conformité.
F.5.1.3. Le présent document vise à fournir un programme uniforme de tests
qui s'appuie sur une suite de tests normalisés dont l'emploi devrait
garantir la comparabilité des résultats et leur acceptation à un large
niveau, ce qui permettrait de limiter au minimum les essais de confor-
mité. La suite de tests normalisés a été établie en partie par
Eurocontrol.2000R2082 — FR — 15.06.2002 — 001.001 — 209
▼B
F.5.1.4. Sur la base de la Figure 2, l'essai de l'ensemble du système terminal
prend la forme de tests sur les 3 couches inférieures. Il est souhaitable
d'inclure des essais sur les messages d'application FDE, d'état, de
système et d'opérateur.
F.5.1.5. Il convient de mener chacun des tests suivant l'ordre dans lequel il est
présenté ci-dessous. Le dernier test ne pourra être fructueux que si les
couches inférieures fonctionnement correctement, ce que les premiers
tests devraient permettre de vérifier.
F.5.1.6. Quoi qu'il en soit, les tests décrits dans la présente section sont volon-
taires.
F.5.2. Tests des couches inférieures (Couches 1 à 3)
Pour garantir l'interfonctionnement de tout ATCC avec ses homolo-
gues, il est recommandé que chaque test s'inspire du plan de tests
d'intégration FDE ICD établi par Eurocontrol (Division Systèmes du
Centre de contrôle de Maastricht). Les procédures de test doivent être
convenues bilatéralement entre les ATCC coopérants.
F.5.3. Test de la couche application
Une série de tests décidée au niveau bilatéral doit être réalisée
conjointement par les ATCC coopérants.
F.5.4. Homologation
Les résultats des tests doivent être consignés et approuvés par les
parties coopérantes.
F.5.5. Notification
Il convient que les États membres communiquent à Eurocontrol toutes
précisions sur les résultats des tests qu'ils ont menés.2000R2082 — FR — 15.06.2002 — 001.001 — 210
▼B
ANNEXE G (Informative)
ASSIGNATIONDES IDENTIFICATEURSD'ORGANISME ATC
Le tableau ci-dessous donne la liste des identificateurs d'organisme ATC assi-
gnés au 22 avril 1997. Des données actualisées peuvent être obtenues auprès
d'Eurocontrol. Le tableau indique également sous forme hexadécimale le codage
binaire de l'identificateur qui fait partie du codage d'adresse NSAP défini à
l'Annexe C.
Tableau 1
Identificateurs des organismes ATC
Identificateur d'organisme
ATCCodage Description
00 Réservé
01 '01' H CATCAS, Copenhague
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Francfort/Main
04 '04'H CANAC Bruxelles
05 '05'H Générique CAUTRA, France
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, Londres
09 '09'H ATCC Oslo
10 '10'H ATCC Karlsruhe
11 '11'H Langen (futur système allemand)
12 '12'H FATMI-system, Tampere13 '13'H ROVA-system, Rovaniemi
14 '14'H VAS, Vienne
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H CCR/FMP Genève
18 '18'H CCR/FMP Zurich
19 '19'H Barcelone
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milan
23 '23'H Rome
24 '24'H Jersey
25 '25'H Shanwick
26 '26'H Athis-Mons
27 '27'H Reims
28 '28'H Brest
29 '29'H Bordeaux
30 '30'H Aix-en-Provence
31 '31'H Bratislava
32 '32'H Stockholm-Arlanda
33 '33'H Malmö-Sturup34 '34'H Sundsvall
35 '35'H Lisbonne
36 '36'H Séville
37 '37'H Grande Canarie2000R2082 — FR — 15.06.2002 — 001.001 — 211
▼B
Identificateur d'organisme
ATCCodage Description
38 '38'H Prague
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Système militaire allemand
42 '42'H Système militaire allemand43 '43'H Système militaire allemand
44 '44'H Système militaire allemand
45 '45'H Système militaire allemand
46 '46'H Système militaire allemand
47 '47'H Système militaire allemand
48 '48'H Système militaire allemand
49 '49'H Système militaire allemand
50 '50'H Münich (Futur système allemand)
51 '51'H Zagreb
52 '52'H Aéroport de Hahn, Allemagne
53 '53'H FIR de Santa Maria
54 '54'H Ljubljana
55 '55'H Système militaire belge
56 '56'H Budapest
57 '57'H Varsovie2000R2082 — FR — 15.06.2002 — 001.001 — 212
▼B
ANNEXE H (Informative)
DIRECTIVES SUR LA FIABILITÉ, LA DISPONIBILITÉ ET LA
SÉCURITÉ
H.1.Introduction
Il est prévu que des applications ATC telles qu'OLDI vont utiliser les
services de télécommunication fournis par des réseaux X.25 publics
ou privés interconnectés. Par conséquent, il est considéré comme
nécessaire de fournir des directives aux réalisations FDE ICD.
H.2.Objet et portée
H.2.1. La présente Annexe décrit des directives relatives à la fiabilité, la
disponibilité et la sécurité.
H.2.2. La présente Annexe s'appuie sur deux scénarios. Le premier corres-
pond à une liaison point à point sur un liaison spécialisée. Le
second est basé dans un environnement de réseaux X.25 intercon-
nectés.
NOTE Dans le cadre du second scénario, tout ce qui se rapporte à
l'interconnexion des réseaux X.25 n'est pas pris en considéra-
tion.
H.2.3. Il est convenu qu'une protection soit assurée contre l'intrusion
physique, les pannes d'alimentation et les autres menaces extérieures
pouvant affecter les opérations normales.
H.3.Bibliographie
La présente annexe est une vue d'ensemble du document détaillé
d'analyse technique mentionné ci-dessous:
Eurocontrol FDE ICD Part 1: Reliability, Availability and Security
— Technical Report [Référence 16] (disponible uniquement en
langue anglaise).
H.4.Réalisation sur base de liaison spécialisée
H.4.1. Fiabilité
Afind'accroître la fiabilité du service physique, les circuits des liai-
sons spécialisées, les circuits RTPC ainsi que les circuits du réseau
numérique avec intégration des services (RNIS) doivent emprunter
des chemins de câbles physiquement différents et être reliés à des
commutateurs différents de l'opérateur de télécommunication (ceci
doit être précisé à l'opérateur de télécommunication).
H.4.2. Disponibilité
H.4.2.1. En raison des délais d'établissement sur circuit RTPC qui sont incom-
patibles avec des applications à contrainte de temps, il convient
d'utiliser RNIS comme moyende secours.
H.4.2.2. Dans le cas de basculement de l'ETTD, il est convient que l'ETTD de
secours génère une trame DISC pour accélérer le rétablissement de la
connexion.
H.4.3. Sécurité
H.4.3.1. Lors de l'utilisation de RNIS comme moyen de secours, il convient
que l'adaptateur de terminal (TA) RNIS appelé valide l'adresse
E.164 de l'appelant [Référence 18].
H.4.3.2. Il convient que l'ETTD appelant soit conforme à la Recommandation
X.32 de l'UIT-T [Référence 17] en incluant l'information d'identifica-
tion et d'authentification de l'appelant.2000R2082 — FR — 15.06.2002 — 001.001 — 213
▼B
H.4.4. Exemple de configuration
Figure H.1
Exemple de configuration pour une liaison spécialisée
H.5.Réalisation sur base de réseau
H.5.1. Fiabilité
Afin d'accroître la fiabilité du service, il convient de connecter les
systèmes d'un même site à deux ETCD appartenant à des commuta-
teurs différents du réseau (ce besoin doit être spécifié à l'opérateur
réseau).
H.5.2. Disponibilité
H.5.2.1. Il convient d'utiliser le service complémentaire de recherche de
groupe afin d'assigner une seule adresse X.121 [Référence 20] aux
ETCD d'unmême site, ce qui optimise le routage réseau et limite le
nombre d'appels non-établis.
H.5.2.2. Dans le cas ou d'autres mécanismes sont utilisés qui entraînent une
différence de valeur d'adresse ETTD appelé dans les paquets
d'APPEL et COMMUNICATION ACCEPTEE, il convient de confi-
gurer l'ETTD appelant pour qu'il n'y ait aucun impact sur
l'établissement de l'appel.
H.5.2.3. Dans le cas d'une déconnexion de l'ETCD provoqué par une défail-
lance dans le réseau et qu'un second ETCD raccordé au réseau est
disponible, il convient d'exécuter la reprise par l'intermédiaire de ce
second accès.
H.5.3. Sécurité
Dans le cadre de cet Annexe il convient d'utiliser le service complé-
mentaire groupe fermé d'usagés (GFU) qui est le seul service réseau
applicable.
H.6.Directives générales pour les réalisations liaison spécialisée et
réseau
H.6.1. Fiabilité
H.6.1.1. Le basculement total d'un système peut être long, il est judicieux de
considérer l'utilisation d'un processeur frontal (PF) pour pallier à ce
type de panne.
H.6.1.2. Une architecture sur base de processeur frontal peut accroître la fiabi-
lité du service.
NOTE L'inclusion d'une couche de transport dans la spécification du
profil sera éventuellement développée dans le contexte du
futur standard FDE ICD Partie 2.2000R2082 — FR — 15.06.2002 — 001.001 — 214
▼B
H.6.2. Disponibilité
Lors d'un appel non-établi, il convient que le site appelant appelle
une deuxième fois en utilisant la seconde adresse X.121 (si disponi-
ble).
H.6.3. Gestion des systèmes
H.6.3.1. Il convient d'utiliser lorsque que c'est possible, des commutateurs qui
peuvent basculer automatiquement en scrutant les signaux d'interface.
H.6.3.2. Pendant la phase de transfert de données, une indication d'erreur
locale peut être utilisée pour déclencher le basculement des systèmes.
H.6.3.3. Lors du basculement d'un PF, il convient de générer une libération-
CT afinde s'assurer que le système local soit dan s l'état REPOS.
H.6.3.4. Lors de l'expirationdes temporisateurs des couches liaisonde
données ou réseau X.25, il convient de libérer les couches supé-
rieures.
H.6.3.5. Il convient de générer une libération-CT lors d'une panne totale d'un
PF
H.6.3.6. À partir du système de gestion, il convient d'interroger la couche
protocole de transfert de message (Annexe A) et de vérifier la
machine état afin de faire la distinction entre une panne du protocole
de transfert de message et une panne de l'application.
H.6.4. Exemple de configuration
Figure H.2
Exemple de configuration réseau2000R2082 — FR — 15.06.2002 — 001.001 — 215