2000R2082 — IT — 15.06.2002 — 001.001 — 1
Trattandosidiunsemplice strumentodidocumentazione,essononimpegnalaresponsabilitàdelleistituzioni
►B REGOLAMENTOCEN.2082/2000DELLACOMMISSIONE
del6settembre2000
cheadottalenormeEurocontrol echemodificaladirettiva 97/15/CE,cheadottalenormeEuro-
controlechemodificaladirettiva 93/65/CEEdelConsiglio
(GU L 254 del 9.10.2000, pag. 1)
Modificato da:
Gazzetta ufficiale
n. pag. data
►M1Regolamento (CE) n. 980/2002 della Commissione del 4 giugno 2002 L 150 38 8.6.2002
▼B
REGOLAMENTOCEN.2082/2000DELLACOMMISSIONE
del6settembre2000
che adotta le norme Eurocontrol e che modifica la direttiva 97/15/
CE,cheadottalenormeEurocontrolechemodificaladirettiva93/
65/CEEdelConsiglio
LA COMMISSIONE DELLE COMUNITÀ EUROPEE,
visto il trattato che istituisce la Comunità europea,
vista la direttiva 93/65/CEE del Consiglio, del 19 luglio 1993, relativa
alla definizione e all'utilizzazione di specifiche tecniche compatibili per
l'acquisto di apparecchiature e di sistemi per la gestione del trafficoaereo(
1), in particolare l'articolo 3,
vista la direttiva 97/15/CE della Commissione, del 25 marzo 1997, che
adotta le norme Eurocontrol e che modifica la direttiva 93/65/CEE delConsiglio, relativa alla definizione e all'utilizzazione di specifichetecniche compatibili per l'acquisto di apparecchiature e di sistemi per
la gestione del traffico aereo(
2),
considerando quanto segue:
(1)La direttiva 97/15/CE ha adottato la norma Eurocontrol per
l'interscambio di dati in linea (On-Line Data Interchange —OLDI), edizione 1.0, e la norma Eurocontrol per la presentazione
dello scambio di dati per i servizi di traffico aereo (ADEXP),
edizione 1.0.
(2)Eurocontrol ha adottato una versione più recente delle due
norme sopra indicate, vale a dire l'edizione 2.2 della norma
OLDI e l'edizione 2.0 della norma ADEXP, nonché una nuovanorma Eurocontrol denominata «Scambio di dati di volo —Documento relativo al controllo di interfaccia» [Flight DataExchange — Interface Control Document (FDE-ICD].
(3)Queste norme Eurocontrol rientrano nel campo di applicazionedella direttiva 93/65/CEE e contribuiscono all'armonizzazionedei sistemi nazionali di gestione del traffico aereo degli Statimembri, soprattutto per quanto riguarda il trasferimento dei volitra centri di controllo del traffico aereo (OLDI), la gestione del
flusso del traffico aereo (ADEXP) e le comunicazioni tra sistemi
nazionali (FDE-ICD).
(4)Le edizioni 2.2 della norma OLDI e 2.0 della norma ADEXP
sostituiscono quelle precedenti attualmente in vigore conforme-
mente al disposto dell'articolo 1 della direttiva 97/15/CE, percui questo articolo deve essere abrogato.
(5)Le disposizioni del presente regolamento sono conformi al
parere del comitato istituito ai sensi della direttiva 93/65/CEE,
HA ADOTTATO IL PRESENTE REGOLAMENTO:
Articolo 1
Nella misura necessaria all'attuazione di un sistema integrato europeo
di gestione del traffico aereo, gli elementi obbligatori delle specifiche
Eurocontrol comprese nei documenti normativi Eurocontrol seguentisono adottati ai sensi della direttiva 93/65/CEE:
— la norma Eurocontrol per l'interscambio di dati in linea (On-Line
Data Interchange — OLDI), edizione 2.2 (documento Eurocontrol
di riferimento DPS.ET1.ST06-STD), il cui testo figuranell'allegato I del presente regolamento;
— la norma Eurocontrol per la presentazione dello scambio di dati per
i servizi di traffico aereo (ADEXP), edizione 2.0 (documento Euro-2000R2082 — IT — 15.06.2002 — 001.001 — 2
(1) GU L 187 del 29.7.1993, pag. 52.
(2) GU L 95 del 10.4.1997, pag. 16.
▼B
control di riferimento DPS.ET1.ST09-STD), il cui testo figura
nell'allegato II del presente regolamento;
— la norma Eurocontrol per lo scambio di dati di volo — documento
relativo al controllo di interfaccia (FDE-ICD), edizione 1.0 (docu-mento Eurocontrol di riferimento COM.ET1.ST12-STD), il cui
testo figura nell'allegato III del presente regolamento.
Articolo 2
L'articolo 1 della direttiva 97/15/CE è abrogato.
Articolo 3
Il presente regolamento entra in vigore il terzo giorno successivo alla
pubblicazione nella Gazzetta ufficiale delle Comunità europee .
Il presente regolamento è obbligatorio in tutti i suoi elementi e diretta-
mente applicabile in ciascuno degli Stati membri.2000R2082 — IT — 15.06.2002 — 001.001 — 3
▼B
ALLEGATO I
INTERSCAMBIODIDATIINLINEA(OLDI),EDIZIONE2.2
(documentoEurocontroldiriferimento DPS.ET1.ST06-STD)2000R2082 — IT — 15.06.2002 — 001.001 — 4
▼B
INDICE
AVVISO/DIRITTI D'AUTORE
PREFAZIONE1. INTRODUZIONE
1.1. Scopo1.2. Campo di applicazione
2. RIFERIMENTI3. DEFINIZIONI, SIMBOLI E ABBREVIAZIONI
3.1. Definizioni3.2. Simboli e abbreviazioni
4. CARATTERISTICHE GENERALI
4.1. Introduzione4.2. Requisiti del sistema di elaborazione dei dati di volo4.2.1. Database di volo4.2.2. Funzionamento in tempo reale4.2.3. Mezzi di comunicazione dati4.2.4. Funzioni applicative4.2.5. Interfaccia uomo-macchina (HMI)4.2.6. Attivazione dei messaggi4.2.7. Ricevimento dei messaggi4.3. Aggiornamento a partire dai dati di sorveglianza4.4. Registrazione dei dati OLDI4.4.1. Contenuto4.4.2. Mezzi hardware
4.5. Disponibilità, affidabilità, sicurezza dei dati e integrità dei dati4.5.1. Disponibilità4.5.2. Affidabilità4.5.3. Sicurezza dei dati4.5.4. Integrità dei dati4.6. Valutazione operativa4.6.1. Periodo di valutazione4.6.2. Data di messa in servizio operativo
5. CATEGORIE DI MESSAGGI
5.1. Indicazioni generali5.1.1. Scopo5.1.2. Categorie di messaggi5.2. Tempi di transazione5.2.1. Condizioni relative ai tempi di transazione5.3. Classificazione e categorizzazione dei messaggi2000R2082 — IT — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Classificazione dei messaggi — Obbligatori e complementari
5.3.2. Categorizzazione dei messaggi
6. PROCEDURA DI BASE — MESSAGGI OBBLIGATORI
6.1. Indicazioni generali6.1.1. Descrizione dei requisiti6.1.2. Implementazione6.2. Messaggio di preavviso di attraversamento di confine (ABI)
6.2.1. Scopo del messaggio ABI
6.2.2. Contenuto del messaggio6.2.3. Regole di applicazione6.2.4. Riscontro all'ABI6.2.5. Esempi6.3. Messaggio di attivazione (ACT)
6.3.1. Scopo del messaggio ACT
6.3.2. Contenuto del messaggio6.3.3. Regole di applicazione6.3.4. Riscontro all'ACT6.3.5. Esempi
6.4. Messaggio di riscontro logico (LAM)
6.4.1. Scopo del messaggio LAM6.4.2. Contenuto del messaggio6.4.3. Regole di applicazione6.4.4. Riscontro al LAM6.4.5. Esempi
7. PROCEDURA DI BASE — MESSAGGI COMPLEMENTARI
7.1. Indicazioni generali
7.1.1. Descrizione delle necessità7.1.2. Implementazione7.2. Messaggio di attivazione preliminare (PAC)7.2.1. Scopo del messaggio PAC7.2.2. Contenuto del messaggio
7.2.3. Regole di applicazione
7.2.4. Riscontro al PAC7.2.5. Esempi7.3. Messaggio di revisione (REV)7.3.1. Scopo del messaggio REV
7.3.2. Contenuto del messaggio
7.3.3. Regole di applicazione7.3.4. Riscontro al REV7.3.5. Esempi2000R2082 — IT — 15.06.2002 — 001.001 — 6
▼B
7.4. Messaggio di abrogazione del coordinamento (MAC)
7.4.1. Scopo del messaggio MAC7.4.2. Contenuto del messaggio
7.4.3. Regole di applicazione
7.4.4. Riscontro al MAC7.4.5. Esempi7.5. Messaggio di assegnazione di codice SSR (COD)
7.5.1. Scopo del messaggio COD
7.5.2. Contenuto del messaggio7.5.3. Regole di applicazione
7.5.4. Riscontro al COD
7.5.5. Esempi7.6. Messaggio di informazione (INF)7.6.1. Scopo del messaggio INF
7.6.2. Contenuto del messaggio
7.6.3. Regole di applicazione7.6.4. Riscontro all'INF
7.6.5. Esempi
8. PROCEDURA DI DIALOGO — COORDINAMENTO
8.1. Indicazioni generali8.1.1. Introduzione
8.1.2. Il filtro
8.1.3. Sequenza dei messaggi8.1.4. Trattamento simultaneo dei messaggi8.1.5. Trattamento dei messaggi di rigetto
8.1.6. Tempo massimo consentito per la risposta operativa
8.1.7. Attuazione8.2. Messaggio di attivazione (ACT)
8.2.1. Scopo del messaggio ACT
8.2.2. Contenuto del messaggio8.2.3. Regole di applicazione
8.2.4. Riscontro all'ACT
8.3. Messaggio di proposta di attivazione sottoposta per accettazione (RAP)8.3.1. Scopo del messaggio RAP8.3.2. Contenuto del messaggio
8.3.3. Regole di applicazione
8.3.4. Riscontro al RAP8.3.5. Risposta operativa al RAP
8.3.6. Esempi
8.4. Messaggio di revisione (REV)2000R2082 — IT — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Scopo del messaggio REV
8.4.2. Contenuto del messaggio8.4.3. Regole di applicazione
8.4.4. Riscontro al REV
8.4.5. Risposta operativa al REV8.5. Messaggio di proposta di revisione sottoposta per accettazione (RRV)8.5.1. Scopo del messaggio RRV
8.5.2. Contenuto del messaggio
8.5.3. Regole di applicazione8.5.4. Riscontro all'RRV
8.5.5. Risposta operativa all'RRV
8.5.6. Esempi8.6. Messaggio di attesa (SBY)8.6.1. Scopo del messaggio SBY
8.6.2. Contenuto del messaggio
8.6.3. Regole di applicazione8.6.4. Riscontro all'SBY
8.6.5. Esempi
8.7. Messaggio di accettazione (ACP)8.7.1. Scopo del messaggio ACP
8.7.2. Contenuto del messaggio
8.7.3. Regole di applicazione8.7.4. Riscontro all'ACP8.7.5. Esempi
8.8. Messaggio di coordinamento (CDN)
8.8.1. Scopo del messaggio CDN8.8.2. Contenuto del messaggio
8.8.3. Regole di applicazione
8.8.4. Riscontro al CDN8.8.5. Risposta operativa al CDN8.8.6. Esempi
8.9. Messaggio di rigetto di coordinamento (RJC)
8.9.1. Scopo del messaggio RJC8.9.2. Contenuto del messaggio
8.9.3. Regole di applicazione
8.9.4. Riscontro all'RJC8.9.5. Esempi
9. PROCEDURA DI DIALOGO — TRASFERIMENTO DELLE COMUNICAZIONI
9.1. Indicazioni generali
9.1.1. Introduzione2000R2082 — IT — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Sequenza di messaggi
9.1.3. Trasferimento delle comunicazioni9.2. Messaggio di avvio del trasferimento (TIM)
9.2.1. Scopo del messaggio TIM
9.2.2. Contenuto del messaggio9.2.3. Regole di applicazione9.2.4. Riscontro al TIM9.2.5. Esempio9.3. Messaggio di dati supplementari (SDM)9.3.1. Scopo del messaggio SDM9.3.2. Contenuto del messaggio9.3.3. Regole di applicazione9.3.4. Riscontro all'SDM9.3.5. Esempio9.4. Proposta di trasferimento (HOP)9.4.1. Scopo del messaggio HOP9.4.2. Contenuto del messaggio9.4.3. Regole di applicazione9.4.4. Riscontro all'HOP9.4.5. Esempio9.5. Messaggio di richiesta di cambio di frequenza (ROF)
9.5.1. Scopo del messaggio ROF
9.5.2. Contenuto del messaggio9.5.3. Regole di applicazione9.5.4. Riscontro al ROF9.5.5. Esempio9.6. Messaggio di cambio di frequenza (COF)9.6.1. Scopo del messaggio COF9.6.2. Contenuto del messaggio9.6.3. Regole di applicazione9.6.4. Riscontro al COF9.6.5. Esempi9.7. Messaggio di assunzione manuale delle comunicazioni (MAS)9.7.1. Scopo del messaggio MAS9.7.2. Contenuto del messaggio9.7.3. Regole di applicazione9.7.4. Riscontro al MAS9.7.5. Esempio
ALLEGATO A (NORMATIVO) REGOLE DI INSERIMENTO DEI DATI
ALLEGATO B (NORMATIVO) PRESCRIZIONI RELATIVE ALL'ELABORAZIONE DI ROTTE
PARTICOLARI2000R2082 — IT — 15.06.2002 — 001.001 — 9
▼B
ALLEGATO C (INFORMATIVO) FASI DELLA PROCEDURA DI DIALOGO (LIVELLO SYSCO
1) — SEQUENZA DEI MESSAGGI2000R2082 — IT — 15.06.2002 — 001.001 — 10
▼B
AVVISO/DIRITTID'AUTORE
Il presente documento è stato elaborato dall'Agenzia Eurocontrol, che ne
detiene i diritti d'autore.
Il contenuto del presente documento, o di qualsiasi parte di esso, è a dispo-
sizione dei rappresentanti degli Stati membri, ma la riproduzione o
divulgazione a terzi è subordinata al preventivo consenso scritto dell'A-
genzia Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 11
▼B
PREFAZIONE
1. Organoresponsabile
La norma Eurocontrol per l'interscambio di dati in linea (OLDI),
edizione 2.2, è stata elaborata dalla Direzione Sviluppo (DED)
del Programma europeo di armonizzazione ed integrazione del
controllo del traffico aereo (EATCHIP), che provvede anche al
suo aggiornamento. Tutti i commenti e le richieste di informa-
zioni vanno indirizzati al Direttore Generale di Eurocontrol, Rue
de la Fusée, 96, B-1130 Bruxelles, all'attenzione della Divisione
DED-2.
2. RapportoconilProgrammadilavoroEATCHIP
La presente norma è un prodotto risultante dall'Attività speciali-
stica DPS.ET1.ST06 del dominio «Sistemi di elaborazione dati
ATM (DPS)» di EATCHIP, definita nel documento Programma
di lavoro EATCHIP (EWPD), edizione 2.0, del 30/09/94.
3. Approvazioniemodifiche
La presente norma è stata sottoposta alla procedura di approva-
zione seguente, definita nelle Direttive per la normalizzazione di
Eurocontrol:
— approvazione da parte del gruppo «Requisiti operativi ed
elaborazione dei dati ATM (ODT)» di EATCHIP, per corri-
spondenza;
— consultazione con tutti gli Stati ECAC attraverso i loro
rappresentanti presso il Comitato di gestione o il Comitato
direttivo di EATCHIP;
— approvazione da parte del Comitato direttivo di EATCHIP e
del Comitato di gestione;
— adozione da parte della Commissione permanente.
Le disposizioni contenute nella presente norma hanno acquisito
efficacia dopo l'adozione da parte della Commissione perma-
nente.
Per riflettere l'evoluzione delle procedure di controllo del traffico
aereo (ATC), modifiche ed integrazioni potranno essere proposte
attraverso l'ODT affinché vengano discusse ed eventualmente
approvate. Le prescrizioni saranno poi incorporate o in una modi-
fica o in una nuova edizione del documento, da sottoporre per
accettazione secondo le procedure stabilite.
4. Convenzioniredazionali
Per indicare lo status di ciascun elemento è stata adottata la nota-
zione seguente: gli elementi normativi sono stampati in caratteri
tondi; gli elementi raccomandati sono stampati in caratteri corsivi
e preceduti dall'indicazione Raccomandazione .
Per la stesura delle specifiche ci si è attenuti alle seguenti
convenzioni redazionali: per gli elementi normativi sono stati
utilizzati verbi al modo indicativo, tempo presente; per gli
elementi raccomandati è stata utilizzata la forma verbale «è
opportuno che».
Le note sono stampate in caratteri corsivi e sono precedute
dall'indicazione NOTA.
5. Rapporto con l'edizione 1 della norma Eurocontrol per
l'interscambio didatiinlinea
Il presente documento sostituisce le parti 1 e 2 dell'edizione 1
della norma «Eurocontrol Standard for On Line Data Inter-
change». La parte 3, che descrive i protocolli tecnici da
utilizzare, è sostituita dalla norma Eurocontrol — Documento
relativo al controllo di interfaccia per lo scambio di dati di volo
— parte 1.2000R2082 — IT — 15.06.2002 — 001.001 — 12
▼B
6. Cambiamentirilevantirispettoall'edizione 1
I cambiamenti e le integrazioni principali rispetto all'edizione 1
sono i seguenti:
1. Incorporazione dei seguenti messaggi complementari (non
obbligatori) nella procedura di base:
— messaggio di abrogazione del coordinamento (MAC);
— messaggio di assegnazione di codice SSR (COD) per il
radar secondario di sorveglianza;
— messaggio di informazione (INF).
2. Definizione del contenuto e del formato del messaggio da
inviare quando un volo attraversa un confine su una rotta che
non è una rotta ATS ma che è definita dai punti iniziale e
finale del segmento di rotta.
3. Incorporazione di una procedura di dialogo che consente:
— ai controllori che si occupano della pianificazione di iden-
tificare e negoziare condizioni di trasferimento non
standard;
— all'ente accettante di sottoporre una controproposta sulle
condizioni di trasferimento;
— la messa a disposizione di strumenti per il trasferimento
delle comunicazioni nel quadro della procedura di trasferi-
mento del controllo.
4. Uso del formato descritto nell'edizione 2 della norma Eurocon-
trol per la presentazione dello scambio di dati ATS (ADEXP).
Tutti i messaggi utilizzati nella procedura di base e quelli
utilizzati nella fase di coordinamento della procedura di
dialogo sono descritti usando sia il formato ICAO sia il
formato ADEXP. I messaggi di trasferimento delle comunica-
zioni descritti nel quadro della procedura di dialogo sono
presentati unicamente nel formato ADEXP.
5. Cancellazione dei seguenti allegati dell'edizione 1:
A: ATC Unit Identification (Identificazione degli enti ATC).
B: OLDI Message Structure (Struttura dei messaggi OLDI)
(tutti i messaggi presentati nell'edizione 3 sono illustrati
mediante esempi).
D: Historical Overview (Panoramica storica).E: Implementation Plan (Piano di implementazione).F: Compliance by States (Ottemperanza da parte degli Stati).G: Guidelines for Implementation (Linee-guida per l'imple-
mentazione).
H: Guidelines of Evaluation of OLDI (Linee-guida per la
valutazione dell'OLDI).
6. Separazione della parte 3 — Requisiti tecnici — dalle speci-
fiche relative alle applicazioni.
7. Rapportoconaltridocumenti
Il presente documento fa riferimento a due tipi di formati di
campo utilizzabili nella compilazione dei messaggi: il formato
ICAO e il formato ADEXP.
I formati di campo ICAO sono descritti nel documento di cui al
riferimento 1. Nel caso in cui tale documento sia sostituito da un
altro documento, la definizione dei tipi di campo ICAO sarà
quella descritta nel nuovo documento.
I formati di campo ADEXP sono descritti nel documento di cui al
riferimento 2.
NOTA L'elenco dei documenti di riferimento è contenuto nella
sezione 2.2000R2082 — IT — 15.06.2002 — 001.001 — 13
▼B
8. Lingua
L'originale del presente documento è stato redatto in lingua
inglese.2000R2082 — IT — 15.06.2002 — 001.001 — 14
▼B
1. INTRODUZIONE
1.1. Scopo
1.1.1. I voli a cui è fornito un servizio ATC sono trasferiti da un ente
ATC al successivo in condizioni studiate per assicurare una sicu-
rezza totale. Per raggiungere questo obiettivo, la prassi standard
prevede che i due enti coordinino tra di loro in anticipo il
passaggio di ciascun volo attraverso il confine tra le rispettive
aree di giurisdizione e che il controllo del volo sia trasferito
quando l'aeromobile attraversa o si appresta ad attraversare detto
confine.
1.1.2. Quando è svolta per telefono, la trasmissione dei dati sui singoli
voli nell'ambito del processo di coordinamento è una delle princi-
pali funzioni di supporto degli enti ATC, in particolare dei centri
di controllo d'area (ACC). L'interscambio di dati in linea (OLDI,
dall'inglese On-Line Data Interchange), vale a dire l'uso operativo
dei collegamenti tra i Sistemi di elaborazione dei dati di volo
(FDPS) degli ACC allo scopo di sostituire queste «stime verbali»,
ha avuto inizio in Europa nei primi anni '80.
1.1.3. Per facilitare l'implementazione gli organismi competenti hanno
elaborato e adottato regole e formati di messaggio comuni, incor-
porati nell'edizione 1 della norma Eurocontrol per l'interscambio
di dati in linea; la presente edizione Erreur! Source du renvoi
introuvable. è stata elaborata allo scopo di riflettere lo sviluppo
continuo di questo strumento conformemente alle disposizioni
del programma EATCHIP.
1.2. Campodiapplicazione
1.2.1. Il presente documento specifica le procedure ed i messaggi da
utilizzare tra FDPS di enti ATC allo scopo di assicurare:
— il coordinamento necessario prima del trasferimento dei voli
da un ente al successivo;
— il trasferimento delle comunicazioni per i voli in questione.
1.2.2. Il presente documento:
— definisce i formati dei messaggi e le regole relative al conte-
nuto;
— descrive gli strumenti di cui devono disporre tali enti per
poter attuare lo scambio di dati.
1.2.3. La presente norma si applica tra gli Stati membri di Eurocontrol
ai servizi OLDI internazionali tra enti che assicurano un servizio
ATC d'area.
1.2.4. Raccomandazione Si raccomanda che gli Stati membri della
Conferenza europea dell'aviazione civile (ECAC) applichino la
presente norma a:
—servizi OLDI internazionali tra enti che assicurano un servi-
zio ATC d'area nell'area ECAC;
—servizi OLDI tra enti che assicurano un servizio ATC d'area a
livello nazionale .
2. RIFERIMENTI
2.1. I documenti indicati qui di seguito contengono disposizioni che,
attraverso i rimandi contenuti in questo testo, costituiscono dispo-
sizioni della presente norma Eurocontrol.
Le edizioni indicate sono quelle in vigore al momento della
pubblicazione della presente norma Eurocontrol.
Ogni revisione dei documenti ICAO a cui si fa riferimento è
immediatamente incorporata nella presente norma Eurocontrol.
Le revisioni degli altri documenti a cui si fa riferimento non
entrano a far parte delle disposizioni della presente norma Euro-
control se non dopo essere state formalmente esaminate ed
incorporate nella presente norma Eurocontrol.
In caso di conflitto tra le prescrizioni della presente norma Euro-
control ed il contenuto dei documenti a cui si fa riferimento
prevale la presente norma Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 15
▼B
2.2. I documenti di riferimento ai fini della presente norma sono i
seguenti:
1. Procedures for Air Navigation Services — Rules of the Air &
Air Traffic Services, Document 4444 ICAO, tredicesima
edizione del 7 novembre 1996, e successive modifiche.
2. Edizione 2.0 della norma Eurocontrol per la presentazione
dello scambio di dati ATS (ADEXP), riferimento DPS-ET1-
ST09-STD-01-00, giugno 1998.
3. DEFINIZIONI,SIMBOLIEABBREVIAZIONI
3.1. Definizioni
Ai fini della presente norma Eurocontrol si applicano le seguenti
definizioni:
3.1.1. Ente accettante : ente preposto a fornire un servizio di controllo
del traffico aereo (ATC) che assumerà o ha assunto il controllo
di un volo quando avrà o ha avuto luogo il trasferimento da un
ente al successivo.
3.1.2. Riscontro : avviso che segnala che un messaggio è stato ricevuto e
che può essere elaborato correttamente.
3.1.3. Attivazione : processo con cui un ente ATC ricevente aggiorna il
piano di volo per il volo oggetto di coordinamento includendo i
dati comunicati dall'ente trasferente nel quadro del coordinamento
tra i due enti, e che porta alla trasmissione dei dati ai controllori.
3.1.4. Altitudine : distanza verticale di una quota, un punto o un oggetto
considerato come un punto rispetto al livello medio del mare.
3.1.5. Applicazione : parte di un sottosistema ATS conforme alla
presente norma e collegato ad entità simili in altri sistemi ATS.
3.1.6. Area di giurisdizione : spazio aereo di dimensioni definite in cui
un ente ATC assicura servizi del traffico aereo.
3.1.7. Associazione : procedura con cui un sistema mette in relazione un
messaggio OLDI ricevuto con un piano di volo inserito nel data-
base.
3.1.8. Ente ATC : ente che fornisce un servizio di controllo del traffico
aereo.
3.1.9. Disponibilità : probabilità che un servizio sia accessibile ad un
utente in un determinato momento.
3.1.10. Confine: piani (laterali e verticali) che delimitano l'area di giuri-
sdizione di un ente ATC.
3.1.11. Livello di volo autorizzato : livello di volo a cui o fino a cui
l'ATC ha autorizzato un aeromobile a volare.
3.1.12. Coordinamento ATC : processo con cui enti ATC con aree di
giurisdizione adiacenti si informano ufficialmente del passaggio
previsto di voli attraverso il confine tra le rispettive aree di giuri-
sdizione allo scopo di garantire la sicurezza dei voli mediante la
coerenza delle azioni previste.
3.1.13. Messaggio di coordinamento : termine generico che designa un
messaggio utilizzato per effettuare un coordinamento ATC. Nei
messaggi di coordinamento è compreso il messaggio CDN che è
un messaggio specifico descritto nel punto 8.8.
3.1.14. Fase di coordinamento : per un determinato volo, la fase in cui
l'ente ATC trasferente e l'ente ATC ricevente concordano le
condizioni (ad es. livello di volo, punto di attraversamento del
confine) in base alle quali il controllo dell'aeromobile sarà trasfe-rito da un ente all'altro.
3.1.15. Punto di coordinamento : punto conosciuto dagli enti ATC in una
sequenza di coordinamento, situato sul o in prossimità del confine
tra gli enti ATC e citato nei messaggi di coordinamento.
3.1.16. Correlazione : processo, fondato su criteri definiti, che consiste
nel mettere in collegamento i dati del piano di volo e la traccia
radar dello stesso volo, normalmente per presentarli sullo
schermo di un controllore.2000R2082 — IT — 15.06.2002 — 001.001 — 16
▼B
3.1.17. Norma Eurocontrol : qualsiasi specifica applicabile alle caratteri-
stiche fisiche, alla configurazione, al materiale, alle prestazioni,
al personale o alle procedure, la cui applicazione uniforme è stata
approvata come essenziale per l'attuazione di sistemi ATS negli
Stati membri di Eurocontrol. Una norma Eurocontrol non deve
essere in conflitto con le norme ICAO ma eventualmente comple-
tarle.
3.1.18. Controllore esecutivo : controllore che dà istruzioni direttamente
ai voli sotto il suo controllo. Rientrano in questa categoria i
controllori che assicurano il servizio di controllo radar d'area.
3.1.19. Quota di uscita : quota alla quale un volo è stato autorizzato,
mediante coordinamento, ad attraversare un punto di trasferi-
mento del controllo. Può essere completata con condizioni di
attraversamento supplementari che definiscono lo strato entro cui
si svolgerà una salita/discesa.
3.1.20. Piano di volo : informazioni specificate fornite agli enti dei servizi
del traffico aereo relativamente ad un volo previsto o ad una sua
parte, e informazioni tratte dal piano di volo di un volo specifico
contenute in un FDPS.
3.1.21. Generazione : processo con cui un sistema ATC estrae le informa-
zioni utili dal/i database e crea un messaggio da trasmettere ad un
ente ATC ricevente.
3.1.22. Formato ICAO : formato utilizzato per la trasmissione terra —
terra dei messaggi ATS, in cui sono utilizzati i tipi di campo ed
i separatori descritti nel riferimento 1.
3.1.23. Quota: termine generico che indica la posizione verticale di un
aeromobile in volo; nella presente norma il termine quota (o
livello di volo) indica anche l'altitudine, nei casi in cui questa è
utilizzata.
3.1.24. Notifica: processo con cui l'ente trasferente trasmette dati di
aggiornamento al sistema dell'ente ricevente in preparazione della
fase di coordinamento.
3.1.25. Ente ricevente : l'ente ATC a cui è trasmesso un messaggio.
3.1.26. Affidabilità : percentuale della disponibilità programmata in cui il
servizio deve essere funzionante.
3.1.27. Livello di volo richiesto : livello di volo richiesto dall'aeromobile
nel piano di volo.
3.1.28. Revisione : modifica dei dati trasmessi precedentemente dall'ente
ATC trasferente all'ente ATC ricevente.
3.1.29. Quota di attraversamento supplementare : quota alla quale o al di
sopra o al di sotto della quale un volo è stato coordinato per
l'attraversamento del punto di trasferimento del controllo. La
quota supplementare, se presente, è un elemento della quota di
uscita.
3.1.30. Piano di volo di sistema : informazioni ricavate dal piano di volo
di un particolare aeromobile contenute in un FDPS.
3.1.31. Tempo di transazione : intervallo di tempo successivamente all'at-
tivazione di un messaggio in cui hanno luogo la trasmissione,
l'elaborazione iniziale nel sistema ricevente, la generazione e
trasmissione di un messaggio di riscontro, e la sua identificazione
nel sistema trasferente
3.1.32. Punto di trasferimento del controllo : punto definito, situato lungo
la traiettoria di volo di un aeromobile, in cui la responsabilità di
fornire i servizi del traffico aereo a tale aeromobile è trasferita da
un ente ATC o posizione di controllo al/la successivo/a. Non
coincide necessariamente con il punto di coordinamento.
3.1.33. Fase di trasferimento : fase del volo che segue la fase di coordi-
namento, nel corso della quale è effettuato il trasferimento delle
comunicazioni.
3.1.34. Ente trasferente : in una sequenza di coordinamento, l'ente ATC
responsabile di fornire un servizio ad un aeromobile prima dell'at-
traversamento del confine e che avvia la fase di coordinamento
con l'ente successivo.
3.1.35. Trasmettere : comunicare un messaggio da un sistema ad un altro.
3.1.36. Ente: ente ATS2000R2082 — IT — 15.06.2002 — 001.001 — 17
▼B
3.1.37. Avvertimento : messaggio visualizzato sullo schermo di una posi-
zione di lavoro quando il processo di coordinamento
automatizzato non va a buon fine.
3.2. Simbolieabbreviazioni
Ai fini della presente norma Eurocontrol si applicano le seguenti
sigle e abbreviazioni.
ABI Messaggio di preavviso di attraversamento di
confine
ACC Centro di controllo d'area
ACP Messaggio di accettazione
ACT Messaggio di attivazione
ADEXP Presentazione dello scambio di dati ATS
ATC Controllo del traffico aereo
ATM Gestione del traffico aereo
ATS Servizio del traffico aereo
CDN Messaggio di coordinamento
CNL Cancellazione di piano di volo
COD Messaggio di assegnazione di codice SSR
COF Messaggio di cambio di frequenza
COP Punto di coordinamentoDED Direzione Sviluppo EATCHIP di Eurocontrol
EATCHIP Programma europeo di armonizzazione ed integra-
zione del controllo del traffico aereo
ECAC European Civil Aviation Conference (Conferenza
europea sull'aviazione civile)
ETO Orario stimato di sorvolo (di un punto)
ETOT Orario stimato di decollo
EWPD Documento «Programma di lavoro EATCHIP»
FDPS Sistema di elaborazione dei dati di volo
FRF Rotta ulteriore di volo
HMI Interfaccia uomo/macchina
HOP Messaggio di proposta di trasferimento
ICAO International Civil Aviation Organisation (Organiz-
zazione dell'aviazione civile internazionale)
INF Messaggio di informazione
LAM Messaggio di riscontro logico
LoA Lettera di accordoMAC Messaggio di abrogazione del coordinamento
MAS Assunzione manuale delle comunicazioni
NM Miglio nautico
OLDI Interscambio di dati in linea
ORCAM Metodo di assegnazione dei codici in funzione della
regione di origine
PAC Messaggio di attivazione preliminare
RAP Messaggio di proposta di attivazione sottoposta per
accettazione
REV Messaggio di revisione
RJC Messaggio di rigetto di coordinamento
ROF Messaggio di richiesta di cambio di frequenza
RRV Messaggio di revisione sottoposta per accettazione
SBY Messaggio di attesa
SDM Messaggio di dati supplementariSSR Radar secondario di sorveglianza
SYSCO Coordinamento automatizzato
TI Avvio del trasferimento2000R2082 — IT — 15.06.2002 — 001.001 — 18
▼B
TIM Messaggio di avvio del trasferimento
TWR/APP Controllo di aerodromo e controllo di avvicinamento
4. CARATTERISTICHEGENERALI
4.1. Introduzione
La presente sezione descrive le caratteristiche operative generali
necessarie per l'implementazione di un servizio OLDI tra enti
ATC; illustra inoltre le regole di classificazione ed i requisiti
operativi dei vari tipi di messaggi utilizzati.
4.2. Requisitidelsistemadielaborazionedeidatidivolo
4.2.1. Database di volo
Gli enti che utilizzano i servizi descritti nel presente documento
ricevono dati da un FDPS contenente tutte le informazioni
richieste per la visualizzazione, l'elaborazione e la compilazione
dei messaggi specificati. La principale fonte di dati per ogni
volo è il piano di volo trasmesso dal comandante dell'aeromobile
o in suo nome. Altri dati sono ricavati dall'elaborazione dei piani
di volo nell'ambiente dell'ente in questione.
4.2.2. Funzionamento in tempo reale
La procedura OLDI comprende gli eventi nell'ente ATC trasfe-
rente che attivano le funzioni necessarie per la presentazione
tempestiva dei dati al controllore trasferente e la trasmissione
dei dati di coordinamento all'ente accettante. A questo scopo,
l'FDPS deve essere in grado di attivare le funzioni confrontando
il tempo universale coordinato e i parametri temporali applicabili
all'orario di sorvolo di punti specificati sulla rotta di volo, deter-
minati a partire dal database di dati di volo.
4.2.3. Mezzi di comunicazione dati
4.2.3.1. L'FDPS è in grado di ricevere e trasmettere dati di volo nel
formato applicabile al messaggio, così come specificato nel
presente documento, utilizzando un mezzo di comunicazione dati
che supporti la funzione OLDI.
4.2.3.2. Raccomandazione È opportuno che l'FDPS abbia potenzialità di
sviluppo sufficienti per consentire l'aggiunta di nuovi messaggi
che potrebbero essere inclusi in versioni future di questa norma.
4.2.3.3. Il mezzo di comunicazione dati assicura uno scambio di dati
rapido e affidabile tra applicazioni rispettando i requisiti operativi
specificati nel presente documento e
— garantendo l'integrità della trasmissione dei messaggi OLDI;
— tenendo sotto controllo i collegamenti da punto a punto o lo
stato della rete di telecomunicazioni, secondo il caso.
4.2.3.4. L'FDPS avverte le posizioni di lavoro quando il sistema di comu-
nicazione dati rileva delle anomalie.
4.2.4. Funzioni applicative
4.2.4.1. I sistemi utilizzati per l'OLDI sono in grado di assicurare in modo
automatico le operazioni di ricevimento, archiviazione, elabora-
zione, estrazione, consegna per visualizzazione e trasmissione
dei dati OLDI in tempo reale.
4.2.4.2. L'FDPS:
— contiene i dati operativi correnti attinenti alla funzione OLDI,
così come prevede la presente norma, aggiornati in modo
automatico, manuale o automatico/manuale;
— è in grado di estrarre questi dati dal database di piani di volo;
— identifica l'ente ATC successivo sulla rotta di volo.
4.2.4.3. Gli elementi indicati qui di seguito sono concordati bilateral-
mente:
— punti di coordinamento (COP);
— punti di riferimento utilizzati per indicare il rilevamento o la
distanza allo scopo di identificare i COP su segmenti diretti al
di fuori di rotte ATS, quando questi sono utilizzati.
NOTAI COP possono non coincidere sempre con i punti di
trasferimento del controllo.2000R2082 — IT — 15.06.2002 — 001.001 — 19
▼B
4.2.5. Interfaccia uomo-macchina (HMI)
4.2.5.1. L'HMI permette di:
— visualizzare il contenuto operativo dei messaggi OLDI e gli
avvertimenti associati ai messaggi ricevuti, affinché vengano
esaminati immediatamente;
— instradare gli avvertimenti dei messaggi di coordinamento e
trasferimento alle posizioni operative responsabili del coordi-
namento dei voli in questione.
4.2.5.2. Il personale ATC dispone dei mezzi necessari per modificare i
dati da cui è ricavato il contenuto operativo dei messaggi, così
come prevede il presente documento.
4.2.5.3. L'HMI indica che la trasmissione dei messaggi è in corso o è
stata completata correttamente, secondo il caso.
4.2.5.4. Un avvertimento o avviso alla o alle posizioni ATC o tecniche
competenti è generato automaticamente in caso di mancato rice-
vimento di un riscontro entro i termini previsti successivamente
alla trasmissione di un messaggio di coordinamento o trasferi-
mento.
4.2.5.5. Tale avvertimento o avviso è presentato in forma tale da attirare
immediatamente l'attenzione della posizione di lavoro compe-
tente.
4.2.5.6. Raccomandazione È opportuno che l'HMI alle posizioni ATC
che utilizzano l'OLDI produca un avvertimento quando il servizio
OLDI non è disponibile.
4.2.6. Attivazione dei messaggi
4.2.6.1. Ogni sistema contiene un insieme di parametri di sistema che
garantiscono l'attivazione tempestiva ed automatica dei messaggi
OLDI.
4.2.6.2. Raccomandazione È opportuno prevedere la possibilità di atti-
vare manualmente la trasmissione di un messaggio di
coordinamento prima dell'orario calcolato di trasmissione.
4.2.6.3. L'attivazione automatica è sempre assicurata, se l'attivazione
manuale non viene eseguita.
4.2.6.4. Il sistema utilizza parametri temporali per definire gli elementi
seguenti:
— periodo di tempo prima della trasmissione in cui sugli schermi
dell'ente trasferente è visualizzato il contenuto operativo dei
messaggi;
— tempo mancante, globale o per COP, alla trasmissione del
messaggio, ove previsto;
— lasso di tempo dopo la trasmissione di un messaggio entro cui
deve essere ricevuto un riscontro a livello di applicazione
(tempo massimo consentito).
4.2.6.5. Un messaggio è trasmesso immediatamente quando le informa-
zioni necessarie sono disponibili solo dopo il momento in cui
avrebbero dovuto essere trasmesse.
Esempio: Un volo inizia un segmento IFR GAT in un punto
vicino al confine che si appresta ad attraversare; l'ETO sul puntoin questione è comunicato otto minuti prima del COP; a questo
stadio la trasmissione del messaggio ACT è già in ritardo in
base ai parametri temporali applicabili; il messaggio è trasmesso
immediatamente.
4.2.7. Ricevimento dei messaggi
4.2.7.1. Il sistema ATC è in grado di:
— ricevere messaggi OLDI;
— elaborarli automaticamente conformemente alle disposizioni
della presente norma;
— presentare i dati di volo corrispondenti al messaggio ricevuto,
e visualizzare gli avvertimenti necessari in caso di non
coerenza nei dati ricevuti;
— generare e trasmettere automaticamente messaggi di riscontro
a livello di applicazione.
4.2.7.2. Quando un messaggio è stato elaborato il sistema genera e
trasmette un messaggio di riscontro (riscontro logico — LAM,2000R2082 — IT — 15.06.2002 — 001.001 — 20
▼B
accettazione — ACP, o attesa — SBY) e presenta i risultati
dell'elaborazione alla/e posizione/i competente/i.
NOTALe condizioni esatte per la generazione di un riscontro
sono precisate per ogni messaggio.
4.3. Aggiornamentoapartiredaidatidisorveglianza
Raccomandazione Per garantire la precisione dei dati relativi
agli orari stimati è opportuno utilizzare le informazioni ricavate
dal tracking dei voli mediante radar o qualsiasi altro mezzo di
sorveglianza per aggiornare il database dei piani di volo .
4.4. RegistrazionedeidatiOLDI
4.4.1. Contenuto
Il contenuto e l'orario di ricevimento di tutti i messaggi OLDI
sono registrati.
4.4.2. Mezzi hardware
Devono essere disponibili mezzi hardware per il reperimento e la
visualizzazione dei dati registrati.
4.5. Disponibilità, affidabilità, sicurezza dei dati e integrità dei
dati
4.5.1. Disponibilità
4.5.1.1. Il servizio OLDI è disponibile nelle ore di flusso di traffico
normale e di punta tra i due enti interessati.
4.5.1.2. Raccomandazione È opportuno che il servizio OLDI sia disponi-
bile 24 ore al giorno, 7 giorni su 7.
4.5.1.3. I periodi di fermo programmati (e quindi il tempo di disponibilità
pianificato) sono concordati bilateralmente dai due enti interes-
sati.
4.5.2. Affidabilità
4.5.2.1. L'affidabilità di ogni collegamento OLDI è almeno del 99,86 %
(corrispondente ad un tempo di fermo non superiore a 12 ore
l'anno sulla base di una disponibilità di 24 ore su 24).
4.5.2.2. Raccomandazione Se la misura si giustifica dal punto di vista
operativo, è opportuno prevedere una disponibilità di almeno il
99,99 % (corrispondente ad un tempo di fermo non superiore a
52 minuti l'anno sulla base di una disponibilità di 24 ore su 24).
4.5.3. Sicurezza dei dati
RaccomandazioneÈ opportuno applicare dei metodi di sicurezza
dei dati (ad es. diritti di accesso, verifica delle fonti) ai servizi
OLDI e, ove applicabile, assicurare la gestione di rete .
4.5.4. Integrità dei dati
Il tasso di guasto a livello di applicazione non deve essere supe-
riore a un errore di trasmissione ogni 2 000 messaggi.
4.6. Valutazioneoperativa
4.6.1. Periodo di valutazione
Prima di essere implementato a livello operativo ogni nuovo ser-
vizio OLDI (anche quando si tratta di un nuovo servizio su un
collegamento esistente) è oggetto di un periodo di valutazione
volto a verificare l'integrità dei dati, l'esattezza, il funzionamento,
la compatibilità con le procedure ATC e la sicurezza comples-
siva.
NOTAUna procedura che facilita la valutazione di un nuovo
servizio OLDI può essere richiesta al Segretariato OLDI
di Eurocontrol.
4.6.2. Data di messa in servizio operativo
La data di messa in servizio operativo, che implica l'avvenuto
completamento del periodo di valutazione, è concordata formal-
mente dai due enti.2000R2082 — IT — 15.06.2002 — 001.001 — 21
▼B
5. CATEGORIEDIMESSAGGI
5.1. Indicazionigenerali
5.1.1. Scopo
La presente sezione:
— definisce le categorie di messaggi;
— indica i tempi di transazione ammessi per ogni categoria;— indica quali sono i messaggi obbligatori e quali i messaggi
complementari;
— assegna i tipi di messaggio alle varie categorie.
5.1.2. Categorie di messaggi
I messaggi OLDI sono stati assegnati alle categorie seguenti:
— Categoria 1: trasferimento delle comunicazioni;
— Categoria 2: coordinamento;
— Categoria 3: notifica.
5.2. Tempiditransazione
5.2.1. Condizioni relative ai tempi di transazione
5.2.1.1. I tempi di transazione specificati comprendono la trasmissione,
l'elaborazione iniziale presso l'ente ricevente, la creazione del
messaggio di riscontro, la sua trasmissione e la sua ricezione da
parte dell'ente trasferente. I messaggi automatici di riscontro
LAM e SBY, pertanto, non sono stati assegnati ad alcuna cate-
goria di messaggi.
5.2.1.2. I tempi massimi di transazione per le varie categorie di messaggi
sono specificati nella tabella 5-1.
Tabella 5-1
Tempi massimi di transazione
Categoria di messaggi 90 % 99,8 %
14 s 1 0 s
2 15 s 10 s
3 25 s 45 s
5.2.1.3. Per ogni categoria o tipo di messaggi è definito un tempo
massimo consentito.
5.2.1.4. In caso di mancato ricevimento di un riscontro entro il periodo di
tempo specificato dopo la trasmissione, la trasmissione e l'elabo-
razione del messaggio sono considerati non andati a buon fine ed
è presentato un avvertimento, conformemente a quanto previsto a
questo riguardo nel presente documento.
5.2.1.5. Raccomandazione È opportuno che i tempi massimi consentiti
per le tre categorie non siano superiori rispettivamente a 12
secondi, 30 secondi e 60 secondi .
5.3. Classificazioneecategorizzazione deimessaggi
5.3.1. Classificazione dei messaggi — Obbligatori e complementari
5.3.1.1. I messaggi descritti nel presente documento sono classificati
come obbligatori o complementari.
5.3.1.2. Quando un messaggio è descritto come obbligatorio (M) per la
trasmissione (TX), si deve includere l'elaborazione per poter
inviare tali messaggi.
5.3.1.3. Quando un messaggio è descritto come obbligatorio per la rice-
zione (REC), si deve includere l'elaborazione per poter elaborare
i messaggi ricevuti.
NOTAIn casi eccezionali, quando il flusso di traffico tra due
enti è unidirezionale, l'obbligatorietà può aversi in una
sola direzione.2000R2082 — IT — 15.06.2002 — 001.001 — 22
▼B
5.3.1.4. Quando un messaggio è descritto come complementare (C) per la
trasmissione, si deve includere l'elaborazione per poter inviare tali
messaggi se l'ente trasmittente lo richiede e se così è concordato
bilateralmente con l'ente ricevente.
NOTAÈ possibile che i messaggi complementari siano usati in
una sola direzione, in funzione delle necessità operative.
5.3.1.5. Quando un messaggio è descritto complementare per la ricezione,
si deve includere l'elaborazione per poter elaborare i messaggi
ricevuti, se tale utilizzo è stato concordato bilateralmente.
5.3.1.6. Le condizioni indicate nelle tabelle 5-3 e 5-4 valgono solo
quando l'uso della procedura di dialogo rispettivamente per il
coordinamento e/o il trasferimento delle comunicazioni è stato
concordato bilateralmente tra gli enti ATC.
5.3.2. Categorizzazione dei messaggi
5.3.2.1. La categorizzazione dei messaggi per la procedura di base è indi-
cata nella tabella 5-2.
5.3.2.2. La categorizzazione dei messaggi di coordinamento aggiuntivi
per la procedura di dialogo è indicata nella tabella 5-3.
5.3.2.3. La categorizzazione dei messaggi di trasferimento delle comuni-
cazioni per la procedura di dialogo è indicata nella tabella 5-4.
Tabella 5-2
Messaggi della procedura di base
Tipo di messaggioAbbrevia-
zioneCategoria Trasmissione Ricezione
Preavviso di attraversa-
mento di confineABI 3 M M
Attivazione ACT 2 M M
Revisione REV 2 C (1)C (1)
Attivazione preliminare PAC 2 C C
Abrogazione del coordina-
mentoMAC 2 C C
Assegnazione di codice
SSRCOD 2 C C
Informazione INF 3 C C
Riscontro logico LAM M M
NOTA
(1) Obbligatorio in TX e REC quando è utilizzato in una procedura di dialogo.
Tabella 5-3
Procedura di dialogo — Messaggi della fase di coordinamento
(in aggiunta alla tabella 5-2)
Tipo di messaggioAbbrevia-
zioneCategoria Trasmissione Ricezione
Proposta di attivazione
sottoposta per accettazioneRAP 2 C M
Revisione sottoposta per
accettazioneRRV 2 C M
Coordinamento CDN 2 M M
Attesa (1) SBY M M
Accettazione ACP 2 M M
Rigetto di coordina-
mento (2)RJC 2 C C
NOTE
(1) Cfr. punto 5.2.1.1 Condizioni relative ai tempi di transazione.
(2) Non utilizzato in tutte le configurazioni dello spazio aereo.2000R2082 — IT — 15.06.2002 — 001.001 — 23
▼B
Tabella 5-4
Procedura di dialogo — Messaggi della fase di trasferimento
Tipo di messaggioAbbrevia-
zioneCategoria Trasmissione Ricezione
Avvio del trasferimento TIM 1 M M
Dati supplementari SDM 1 (1)(1)
Proposta di trasferimento HOP 1 M M
Cambio di frequenza (2) COF 1 C M
Richiesta di cambio di
frequenzaROF 1 C M
Assunzione manuale (2) MAS 1 C M
NOTE
(1) M quando è inviato dall'ente trasferente; C quando è inviato dall'ente accettante.
(2) Le procedure concordate bilateralmente devono specificare che quando il trasferimento ha
luogo per una determinata direzione di flusso di traffico, occorre come minimo che l'ente trasfe-rente invii un messaggio COF oppure che l'ente accettante invii in messaggio MAS.
6. PROCEDURADIBASE—MESSAGGIOBBLIGATORI
6.1. Indicazionigenerali
6.1.1. Descrizione dei requisiti
Questa sezione descrive i requisiti minimi a livello di applica-
zione per l'implementazione di servizi OLDI.
6.1.2. Implementazione
Gli enti che utilizzano l'OLDI per il coordinamento dei voli
devono usare i messaggi ABI, ACT e LAM nel modo descritto
nella presente sezione, tranne quando è stato concordato bilateral-
mente di utilizzare la procedura di dialogo di coordinamento
descritta nella sezione 8 del presente documento; in questo caso
le condizioni per l'utilizzo dei messaggi ACT e LAM sono quelle
definite in tale sezione.
6.2. Messaggiodipreavvisodiattraversamentodiconfine(ABI)
6.2.1. Scopo del messaggio ABI
Il messaggio ABI soddisfa le necessità operative seguenti:
— permettere l'acquisizione dei dati di piano di volo mancanti;
— fornire all'ente ATC successivo informazioni anticipate sugli
attraversamenti di confine e le revisioni di tali informazioni;
— aggiornare i dati di base dei piani di volo;
— facilitare la correlazione rapida delle tracce radar;
— facilitare la valutazione a breve termine del carico del settore.
L'ABI è un messaggio di notifica.
6.2.2. Contenuto del messaggio
Il messaggio ABI contiene i dati seguenti:
— tipo di messaggio,
— numero del messaggio,— identificazione dell'aeromobile,
— modo e codice SSR (se disponibile),
— aerodromo di partenza,— dati stimati,
— aerodromo di destinazione,
— numero e tipo degli aeromobili,— tipo di volo,
— capacità e stato delle apparecchiature,
— rotta (facoltativo),— altri dati del piano di volo (facoltativo).2000R2082 — IT — 15.06.2002 — 001.001 — 24
▼M1
▼M1
NOTA:Le regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
6.2.3. Regole di applicazione
6.2.3.1. Indicazioni generali6.2.3.1.1. Salvo disposizioni diverse contenute nei punti 6.2.3.1.3 e
6.2.3.1.4 qui sotto, si inviano uno o più messaggi ABI per ciascun
volo che deve attraversare il confine tra aree di giurisdizione,
conformemente alle procedure OLDI.
6.2.3.1.2. Quando è inviato, il messaggio ABI precede il messaggio di atti-
vazione (ACT) o il messaggio di proposta di attivazione
sottoposta per accettazione (RAP).
6.2.3.1.3. Se è previsto un messaggio di attivazione preliminare (PAC) il
messaggio ABI non viene generato.
6.2.3.1.4. Raccomandazione È opportuno inibire la trasmissione dell'ABI
se la trasmissione del messaggio ACT o RAP è prevista immedia-
tamente o entro un lasso di tempo concordato bilateralmente.
NOTAQuesta raccomandazione ha lo scopo di evitare che posi-
zioni diverse dell'ente ricevente cerchino
contemporaneamente di risolvere anomalie riguardanti
messaggi ABI e ACT relativi ad uno stesso volo.
6.2.3.1.5. Si invia un messaggio ABI riveduto se il messaggio ACT succes-
sivo non è stato generato e se:
— la rotta di volo è stata modificata e il COP indicato nel
messaggio ABI precedente non è più esatto;
— l'aerodromo di destinazione è stato modificato;
oppure
— il tipo di aeromobile è stato modificato.
6.2.3.1.6. Raccomandazione È opportuno inviare un messaggio ABI rive-
duto se il messaggio ACT successivo non è stato generato ed
uno degli elementi indicati qui di seguito è passibile di modifica:
—quota prevista di attraversamento del confine;
—codice SSR previsto al punto di trasferimento del controllo;
—quando l'orario stimato di sorvolo (ETO) del COP differisce
rispetto al messaggio ABI precedente più del lasso di tempo
specificato nella Lettera di accordo (LoA);
—qualsiasi altro dato concordato bilateralmente .
6.2.3.2. Elaborazione nell'ente ricevente
6.2.3.2.1. Il sistema ATC che riceve un messaggio ABI cerca di associarlo
ai dati del piano di volo corrispondente.
6.2.3.2.2. Se il tentativo di associazione non ha esito positivo nel sistema
ricevente è creato automaticamente o manualmente un piano di
volo.
6.2.3.2.3. Se il tentativo di associazione al piano di volo ha esito positivo
ma tra i dati del messaggio ed i dati corrispondenti contenuti nel
sistema ricevente è individuata una discordanza che renderebbe
necessaria un'azione correttiva al ricevimento del messaggio
ACT successivo, la discordanza è segnalata alla posizione di
lavoro appropriata affinché venga eliminata.
6.2.3.3. Parametri temporali per la trasmissione
6.2.3.3.1. Il messaggio è trasmesso un numero di minuti calcolato secondo
un parametro definito prima dell'orario stimato di sorvolo del
COP.
6.2.3.3.2. Il/i parametro/i di generazione dell'ABI è/sono incluso/i nella
LoA tra gli enti ATC competenti.
6.2.3.3.3. Raccomandazione È opportuno che il/i parametro/i di genera-
zione dell'ABI sia/siano:
—variabile/i, in funzione delle disposizioni della LoA;
—definito/i separatamente per ogni COP .2000R2082 — IT — 15.06.2002 — 001.001 — 25
▼B
▼B
6.2.4. Riscontro all'ABI
6.2.4.1. Riscontro
Al messaggio ABI è dato riscontro tramite la generazione e
trasmissione di un messaggio LAM.
NOTAUn messaggio LAM è generato indipendentemente dai
risultati del tentativo di associazione al piano di volo.
6.2.4.2. Mancato riscontro
Raccomandazione In caso di mancato ricevimento di un
messaggio LAM in riscontro ad un messaggio ABI è opportuno
che sia visualizzato un avvertimento sullo schermo di una posi-
zione di supervisione .
6.2.5. Esempi
«Air 2000» 253, un Boeing 757 in volo da Malta a Birmingham,
orario stimato di arrivo al VOR BNE 1221 UTC, livello di volo
FL350, velocità vera all'aria 480 nodi, rotta prevista via UB4
BNE UB4 BPK UB3 HON, transponder regolato su A7012,
livello di volo richiesto FL390. I messaggi riportati qui di seguito
sono esempi equivalenti del messaggio ABI inviato dall'ACC di
Reims all'ACC di Londra.
6.2.5.1. I C A O
(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. Messaggiodiattivazione(ACT)
6.3.1. Scopo del messaggio ACT
Il messaggio ACT risponde alle necessità operative seguenti:
— sostituire la stima verbale di attraversamento di confine con la
trasmissione automatica da un ente ATC al successivo delle
informazioni relative ad un volo prima del trasferimento del
controllo;
— aggiornare i dati di base del piano di volo nell'ente ATC rice-
vente sulla base delle informazioni più recenti;
— facilitare la distribuzione e la visualizzazione dei dati del
piano di volo sugli schermi delle posizioni di lavoro compe-
tenti dell'ente ATC ricevente;
— accelerare la visualizzazione della correlazione tra indicativo
di chiamata e codice nell'ente ATC ricevente;
— comunicare le condizioni di trasferimento all'ente ATC rice-
vente.
6.3.2. Contenuto del messaggio
Il messaggio ACT contiene i dati seguenti:
— tipo di messaggio,
— numero del messaggio,— identificazione dell'aeromobile,
— modo e codice SSR,
— aerodromo di partenza,— dati stimati,— aerodromo di destinazione,— numero e tipo degli aeromobili,— tipo di volo,— capacità e stato delle apparecchiature,— rotta (facoltativo),2000R2082 — IT — 15.06.2002 — 001.001 — 26
▼M1
▼B
▼M1
▼M1
— altri dati del piano di volo (facoltativo).
NOTA:Le regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
6.3.3. Regole di applicazione
6.3.3.1. Indicazioni generali6.3.3.1.1. Il messaggio ACT è inviato per i voli che soddisfano le condi-
zioni stabilite e che attraversano il confine, tranne nel caso
previsto nel punto 6.3.3.1.10.
6.3.3.1.2. Il messaggio ACT è generato e trasmesso automaticamente all'o-
rario calcolato secondo quanto specificato nella LoA, a meno che
non sia attivato precedentemente in modo manuale.
6.3.3.1.3. Raccomandazione È opportuno che il personale ATC abbia
modo di avviare la trasmissione dei messaggi ACT prima dell'o-
rario calcolato di trasmissione.
6.3.3.1.4. Il contenuto operativo del messaggio ACT da trasmettere è visua-
lizzato sullo schermo della posizione di lavoro responsabile del
coordinamento del volo prima dell'effettiva trasmissione.
6.3.3.1.5. Raccomandazione In relazione al punto 6.3.3.1.4, è opportuno
che insieme al contenuto del messaggio ACT sia visualizzato
l'orario calcolato in cui è prevista la trasmissione automatica.
6.3.3.1.6. Il messaggio ACT contiene le informazioni più recenti sul volo, e
rispecchia le condizioni di uscita previste.
6.3.3.1.7. La trasmissione del messaggio ACT è notificata alla posizione di
controllo competente.
6.3.3.1.8. Una volta ricevuto un LAM i dati del messaggio ACT diventano
operativamente vincolanti per entrambi gli enti ATC. Le condi-
zioni di trasferimento coordinate e l'avvenuto ricevimento del
LAM sono portati a conoscenza dell'ente trasferente.
6.3.3.1.9. Le condizioni di trasferimento previste nel messaggio ACT si
presumono accettate dall'ente ricevente a meno che l'ente rice-
vente non avvii un coordinamento allo scopo di modificarle.
6.3.3.1.10. Un nuovo messaggio ACT può essere inviato allo stesso interlo-
cutore nel processo di coordinamento solo se il messaggio
precedente è stato abrogato mediante un MAC.
6.3.3.1.11. Nel messaggio ACT sono incluse informazioni sulla rotta ed altri
dati del piano di volo se così è concordato bilateralmente.
6.3.3.2. Elaborazione nell'ente ricevente
6.3.3.2.1. Il sistema ATC che riceve un messaggio ACT cerca di associarlo
al piano di volo corrispondente.
6.3.3.2.2. Se il tentativo di associazione ha esito positivo e se nel
messaggio non è rilevata alcuna discordanza che ne impedisca la
corretta elaborazione:
— il contenuto operativo è incluso nel piano di volo;
— i dati richiesti sono trasmessi alle posizioni ATC operative e
ad altre, se del caso;
— è inviato un LAM in risposta.
6.3.3.2.3. Se il tentativo di associazione al piano di volo non ha esito posi-
tivo o se si rileva una discordanza che impedisce la corretta
elaborazione del messaggio:
— se è possibile identificare il settore che deve accettare il
controllo del volo:
— il contenuto operativo del messaggio è visualizzato sugli
schermi di tale settore;
— è inviato un LAM in risposta;
— è creato un piano di volo;
— in tutti gli altri casi non è inviato un LAM in risposta.2000R2082 — IT — 15.06.2002 — 001.001 — 27
▼B
▼B
6.3.3.3. Parametri per la trasmissione
6.3.3.3.1. Il messaggio è trasmesso in coincidenza con o non appena possi-
bile dopo il primo tra:
— un numero di minuti calcolato secondo un determinato para-
metro prima dell'orario stimato sul COP;
— il momento in cui il volo si trova ad una distanza dal COP
concordata bilateralmente.
6.3.3.3.2. Il parametro o i parametri di generazione dell'ACT sono inclusi
nella LoA tra gli enti ATC competenti.
6.3.3.3.3. Il parametro o i parametri di generazione dell'ACT sono variabili
e possono essere modificati in base alle disposizioni della LoA.
6.3.3.3.4. Raccomandazione È opportuno che i parametri di generazione
dell'ACT siano definiti separatamente per ogni COP.
6.3.3.3.5. I parametri specificati lasciano sufficiente tempo per:
— permettere all'ente trasmittente di aggiornare il livello di volo
di trasferimento del controllo in modo da tener conto delle
condizioni previste al COP;
e
— permettere all'ente ricevente di elaborare l'ACT e generare e
trasmettere un LAM lasciando comunque all'ente trasferente
la possibilità di effettuare un coordinamento verbale e all'ente
accettante la possibilità di attuare le iniziative necessarie in
caso di esito negativo dello scambio di dati.
6.3.4. Riscontro all'ACT
6.3.4.1. Riscontro
Al messaggio ACT è dato riscontro tramite la generazione e la
trasmissione di un messaggio LAM.
6.3.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio ACT, sullo schermo della posizione
di lavoro ATC responsabile del coordinamento del volo è visua-
lizzato un avvertimento.
6.3.5. Esempi
Gli esempi qui di seguito sono un ampliamento di quelli forniti
per il messaggio ABI al punto 6.2; tutte le indicazioni sono le
stesse tranne l'ETO sul COP, che nel messaggio ACT qui ripor-
tato è 1226.
6.3.5.1. I C A O
(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. Messaggiodiriscontrologico(LAM)
6.4.1. Scopo del messaggio LAM
Il LAM è il messaggio che l'ente ricevente utilizza per indicare
all'ente trasmittente che un messaggio trasmesso è stato ricevuto
e protetto.
L'elaborazione del LAM fornisce al personale ATC dell'ente
trasferente:
— un avvertimento in caso di mancato ricevimento di un
riscontro;
— un'indicazione che il messaggio a cui è dato riscontro è stato
ricevuto, che è stato elaborato con esito positivo, che non è2000R2082 — IT — 15.06.2002 — 001.001 — 28
▼M1
▼B
▼B
stato rilevato alcun errore, che è stato memorizzato e, ove
appropriato, che può essere comunicato alla/e posizione/i di
controllo competente/i.
6.4.2. Contenuto del messaggio
Il messaggio LAM contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;— riferimento del messaggio.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
6.4.3. Regole di applicazione
6.4.3.1. Indicazioni generali6.4.3.1.1. Le regole per l'invio di un LAM in risposta ad un altro messaggio
sono indicate singolarmente per ogni tipo di messaggio nella
sezione corrispondente del presente documento.
6.4.3.1.2. Il messaggio LAM è generato e trasmesso senza intervento
umano.
6.4.3.1.3. Il messaggio LAM non è utilizzato per evitare di dover inviare
messaggi tecnici destinati ad assicurare l'integrità delle trasmis-
sioni di dati.
6.4.3.1.4. Il messaggio LAM è generato e trasmesso immediatamente in
modo che possa essere rispettato il tempo di transazione stabilito
per il messaggio a cui è dato riscontro.
6.4.3.1.5. Tranne che nel caso dei messaggi ABI, il sistema ATC trasmit-
tente informa il controllore responsabile del coordinamento del
mancato ricevimento di un messaggio LAM entro i limiti di
tempo stabiliti per questo tipo di avvertimento.
6.4.4. Riscontro al LAM
Il messaggio LAM non richiede alcun riscontro.
6.4.5. Esempi
6.4.5.1. ICAO
(LAML/E012E/L001)
6.4.5.2. ADEXP
-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -
SEQNUM 001
7. PROCEDURA DI BASE — MESSAGGI COMPLEMEN-
TARI
7.1. Indicazionigenerali
7.1.1. Descrizione delle necessità
Questa sezione descrive i servizi e le funzioni utilizzabili nella
procedura di base in aggiunta a quelli descritti nella sezione 6,
Procedura di base — Messaggi obbligatori.
7.1.2. Implementazione
7.1.2.1. I servizi e le funzioni descritti nella presente sezione sono utiliz-
zati previo accordo bilaterale.
7.1.2.2. Quando tale utilizzo viene concordato si applicano le regole
descritte nella presente sezione.
7.2. Messaggiodiattivazionepreliminare (PAC)
7.2.1. Scopo del messaggio PAC
Il messaggio PAC soddisfa le necessità operative seguenti:
— permettere la notifica e il coordinamento di un volo prima
della partenza quando il tempo di volo tra il punto di partenza
e il COP è inferiore al lasso di tempo che sarebbe necessario
perché siano rispettati i parametri temporali fissati per la
trasmissione del messaggio ACT;2000R2082 — IT — 15.06.2002 — 001.001 — 29
▼B
— permettere la notifica e il coordinamento di un volo prima
della partenza tra un ente locale (controllo di aerodromo/di
avvicinamento) e l'ente successivo che assumerà il controllo
del volo;
— permettere l'acquisizione dei dati del piano di volo mancanti
in caso di discordanze nei dati del piano di volo distribuiti
inizialmente;
— permettere la richiesta di assegnazione di un codice SSR da
parte dell'ente a cui è inviata la notifica/il coordinamento, se
necessario.
7.2.2. Contenuto del messaggio
Il messaggio PAC contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio (facoltativo);
— identificazione dell'aeromobile;
— modo e codice SSR;
— aerodromo di partenza;— orario stimato di decollo o dati stimati;
— aerodromo di destinazione;
— tipo di aeromobile;— rotta (facoltativo);
— altri dati del piano di volo (facoltativo).
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
7.2.3. Regole di applicazione
7.2.3.1. Indicazioni generali7.2.3.1.1. Uno o più messaggi PAC sono inviati per ogni volo che deve
attraversare il confine tra aree di giurisdizione diverse quando il
tempo di volo tra il punto di partenza ed il COP non consente
l'invio del messaggio ACT al momento previsto.
7.2.3.1.2. Uno o più messaggi PAC sono inviati dall'ente di controllo di
aerodromo/di avvicinamento all'ente successivo per ogni volo in
partenza per il quale è richiesta una notifica o un coordinamento.
7.2.3.1.3. Raccomandazione Per l'utilizzo dei messaggi PAC/LAM tra enti
diversi, è opportuno che i sistemi TWR/APP abbiano modo di
inserire e trasmettere i dati «start-up» ,«push-back» ,«taxi»o
qualsiasi altra informazione analoga da cui possa essere ricavato
l'ETOT, per consentire il calcolo dell'ETO sul COP ed avviare la
trasmissione del PAC.
7.2.3.1.4. In base a quanto concordato bilateralmente, il messaggio
contiene:
— l'orario stimato di decollo (ETOT);
oppure
— dati stimati.
7.2.3.1.5. Quando, per accordo bilaterale, è indicato il riferimento del
messaggio, questo:
— contiene il numero di messaggio del primo messaggio PAC
inviato per il volo;
— è citato nel secondo messaggio PAC e nei successivi.
7.2.3.1.6. L'uso eventuale della funzione di richiesta di codice è concordato
bilateralmente.
7.2.3.1.7. Un messaggio PAC riveduto è inviato se, prima della partenza, si
verifica una delle condizioni seguenti:
— la rotta di volo è stata modificata ed il COP indicato nel
messaggio precedente non è più corretto;
— il tipo di aeromobile è stato modificato;
— l'aerodromo di destinazione indicato nel PAC precedente è
risultato non esatto.
7.2.3.1.8. Raccomandazione È opportuno che sia inviato un messaggio
PAC riveduto se, prima della partenza, i dati seguenti differiscono
da quelli indicati nel messaggio PAC precedente:
—quota (nei dati stimati, se questi sono riportati);2000R2082 — IT — 15.06.2002 — 001.001 — 30
▼B
—codice SSR previsto al punto di trasferimento del controllo;
—orario stimato di decollo (ETOT) o ETO sul COP, se la varia-
zione supera il lasso di tempo concordato bilateralmente;
—c'è una variazione concordata bilateralmente di qualsiasi
altro dato .
7.2.3.2. Elaborazione nell'ente ricevente
7.2.3.2.1. Il sistema ATC che riceve un messaggio PAC cerca di associarlo
ai dati del piano di volo corrispondente.
7.2.3.2.2. Se il tentativo di associazione al piano di volo ha esito positivo e
se nel messaggio non è rilevata alcuna discordanza che ne impe-
disca la corretta elaborazione:
— il contenuto operativo è incluso nel piano di volo;
— i dati richiesti sono presentati alle posizioni ATC operative e
ad altre, se del caso;
— è inviato un LAM in risposta.
7.2.3.2.3. Se il tentativo di associazione al piano di volo non ha esito posi-
tivo o se è rilevata una discordanza che impedisce la corretta
elaborazione del messaggio:
— se è possibile identificare il settore che deve accettare il
controllo del volo:
— il contenuto operativo del messaggio è visualizzato sugli
schermi di tale settore;
— è inviato un LAM in risposta;— è creato un piano di volo;
— in tutti gli altri casi, non è inviato un LAM in risposta.
7.2.3.2.4. I dati contenuti nel secondo messaggio PAC o nei messaggi
successivi sostituiscono i dati del messaggio precedente.
7.2.3.2.5. Se il messaggio PAC contiene una richiesta di assegnazione di un
codice SSR e può essere elaborato correttamente, così come
descritto nel punto 7.2.3.2.2 precedente, oltre al messaggio LAM
è inviato in risposta un messaggio COD.
NOTADal momento che per assegnare dei codici sono neces-
sarie informazioni dettagliate sulla rotta indicata nel
piano di volo, l'ente ricevente non è obbligato in base al
presente documento ad inviare in risposta un messaggio
COD quando questi dati non sono disponibili. Questo
non impedisce che in tali circostanze sia inviato unmessaggio in risposta se a livello locale esistono risorse
e mezzi adeguati e se la procedura è stata concordata
bilateralmente.
7.2.3.3. Parametri temporali per la trasmissione
Alla trasmissione non si applica alcun parametro temporale
perché il messaggio è inviato in seguito ad un messaggio inserito
manualmente che segnala l'imminente partenza di un volo.
7.2.4. Riscontro al PAC
7.2.4.1. Riscontro
I messaggi da inviare in risposta ad un messaggio PAC sono
descritti nel punto 7.2.3.2 precedente.
7.2.4.2. Mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio PAC, sullo schermo della posizione di
lavoro dell'ente ATC responsabile del coordinamento con l'ente
successivo è visualizzato un avvertimento.
7.2.4.3. Casi di mancato ricevimento di un messaggio LAM
Nei casi di mancato ricevimento di un messaggio LAM è avviato
un coordinamento verbale.
7.2.4.4. Mancato ricevimento di un messaggio COD
7.2.4.4.1. In caso di mancato ricevimento di un messaggio COD in risposta
ad una richiesta di codice nel messaggio PAC, sullo schermo
della posizione di lavoro competente è visualizzato un avverti-
mento.2000R2082 — IT — 15.06.2002 — 001.001 — 31
▼B
7.2.4.4.2. Quando si deve utilizzare la funzione di richiesta di codice, il
tempo massimo da applicare è concordato bilateralmente.
7.2.5. Esempi
7.2.5.1. Orario stimato di decollo e richiesta di codice
7.2.5.1.1. ICAO
(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. Orario sul COP7.2.5.2.1. ICAO
(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. Messaggiodirevisione (REV)
7.3.1. Scopo del messaggio REV
Il messaggio REV è utilizzato per trasmettere revisioni apportate
ai dati di coordinamento inviati precedentemente in un messaggio
ACT, a condizione che la variazione non comporti il cambia-
mento dell'ente accettante.
7.3.2. Contenuto del messaggio
Il messaggio REV contiene i dati seguenti:
— tipo di messaggio,
— numero del messaggio,
— identificazione dell'aeromobile,
— aerodromo di partenza,
— dati stimati e/o punto di coordinamento,
— aerodromo di destinazione,
— riferimento del messaggio (facoltativo),
— modo e codice SSR (facoltativo),
— rotta (facoltativo),
— capacità e stato delle apparecchiature.
NOTA:Le regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
7.3.3. Regole di applicazione
7.3.3.1. Indicazioni generali7.3.3.1.1. Uno o più messaggi REV possono essere inviati all'ente con cui è
stato effettuato il coordinamento di un volo mediante un
messaggio di attivazione.
7.3.3.1.2. Gli elementi seguenti sono soggetti a revisione:
— ETO sul COP,
— quota/e di trasferimento,
— codice SSR,
— capacità e stato delle apparecchiature.
7.3.3.1.3. Un messaggio REV è inviato:
— quando l'ETO sul COP differisce da quello indicato nel
messaggio precedente di più di un valore concordato bilateral-
mente, arrotondato al numero intero più vicino,
— in caso di variazione della/e quota/e di trasferimento, del
codice SSR o della capacità e stato delle apparecchiature.2000R2082 — IT — 15.06.2002 — 001.001 — 32
▼M1
▼B
▼M1
▼M1
7.3.3.1.4. Se concordato bilateralmente, un messaggio REV è inviato anche
in caso di variazione riguardante:
— il COP,
— la rotta.
NOTA:Regole operative possono imporre che le variazioni
apportate dopo l'ACT avvengano previo coordinamento
tra gli enti competenti.
7.3.3.1.5. Se concordato bilateralmente, nel messaggio REV è indicato il
riferimento del messaggio.
7.3.3.1.6. Il riferimento del messaggio, se indicato, contiene il numero del
messaggio ATC precedente.
7.3.3.1.7. Le condizioni di trasferimento previste nel messaggio REV si
presumono accettate dall'ente ATC ricevente a meno che l'ente
ATC ricevente non avvii un coordinamento allo scopo di modifi-
carle.
7.3.3.2. Formato dei messaggi di revisione
7.3.3.2.1. Formato I C A O
Tutti i messaggi di revisione comprendono le caselle 3, 7, 13, 14
e 16, in cui sono previsti i seguenti tipi di revisione:
— una variazione dell'ETO sul COP o della/e quota/e di trasferi-
mento è inserita introducendo i dati riveduti nella casella 14,
— una variazione del codice SSR è inserito come elemento b) e
c) nella casella 7.
Tutte le altre variazioni sono inserite nel formato della casella 22
dopo i primi cinque campi. Si applicano le seguenti regole:
— i campi inseriti nel formato della casella 22 possono essere in
qualsiasi ordine gli uni rispetto agli altri,
— le variazioni del COP sono inserite nella casella 14 nel
formato della casella 22 (cfr. allegato B, Prescrizioni relative
all'elaborazione di rotte particolari),
— i cambiamenti di rotta sono inseriti nella casella 15 nel
formato della casella 22; le regole per coordinare tali cambia-
menti, comprese le rotte dirette, sono specificate nell'allegatoB, Prescrizioni relative all'elaborazione di rotte particolari,
— capacità e stato delle apparecchiature; vanno indicate solo
eventuali variazioni nelle capacità; un messaggio che modi-
fichi una determinata capacità e che comporti la necessità di
includervi dati relativi alla capacità aggiuntiva, come preci-
sato nell'allegato A, paragrafo A.30, deve comprendere la
capacità aggiuntiva.
7.3.3.2.2. Formato A D E X P
Tutti i messaggi di revisione in formato ADEXP contengono i
seguenti campi primari: TITLE REFDATA ARCID ADEP
ADES. Si applicano le seguenti regole:
— una variazione dell'ETO sul COP o della/e quota/e di trasferi-
mento è inserita introducendo i dati riveduti nel campo
primario COORDATA,
— deve essere incluso il campo primario COP, se una variazione
dell'ETA o della/e quota/e di trasferimento non richiedono
l'impiego del campo primario COORDATA; deve essere
incluso il COP utilizzato per l'attuale coordinamento o, se il
COP è in corso di modifica, quello tramite cui il volo era
stato coordinato in precedenza,
— le modifiche del COP devono essere inserite utilizzando il
campo primario COORDATA (cfr. allegato B, Prescrizioni
relative all'elaborazione di rotte particolari); tali messaggi
devono inoltre contenere il campo primario COP, come prece-
dentemente indicato,
— le variazioni di rotta devono essere inserite utilizzando il
campo primario ROUTE; le regole per il coordinamento di
queste variazioni, comprese le rotte dirette, sono specificate
nell'allegato B, Prescrizioni relative all'elaborazione di rotte
particolari,
— la variazione del codice SSR è indicata inserendo il campo
primario SSRCODE,2000R2082 — IT — 15.06.2002 — 001.001 — 33
▼B
▼M1
▼M1
— i cambiamenti nella capacità e stato delle apparecchiature
sono inseriti utilizzando il campo primario EQCST; vanno
indicate solo le capacità oggetto di variazione.
7.3.3.2.3. Codice SSR
Il modo e il codice SSR figurano in un messaggio REV solo
quando sono necessari per coordinare una variazione del codice
SSR.
7.3.3.3. Elaborazione nell'ente ricevente
7.3.3.3.1. Un sistema ATC che riceve un messaggio REV dopo aver rice-
vuto dallo stesso ente ATC un messaggio ACT cerca di
associarlo al piano di volo corrispondente.
7.3.3.3.2. Se trova un piano di volo corrispondente e se nel messaggio non
è presente alcuna discordanza che ne impedisca l'elaborazione
corretta:
— il contenuto operativo è incluso nel piano di volo;
— i dati necessari sono presentati alle posizioni ATC operative e
ad altre posizioni di lavoro, se del caso.
7.3.3.4. Avvio della trasmissione
7.3.3.4.1. Il messaggio REV è attivato da un evento ed è trasmesso subito
dopo l'immissione o l'aggiornamento dei dati corrispondenti.
7.3.3.4.2. Non è possibile apportare cambiamenti mediante un messaggio
REV dopo un determinato lasso di tempo/una certa distanza dal
punto di trasferimento. I parametri temporali e di distanza sono
concordati bilateralmente.
7.3.3.4.3. Raccomandazione È opportuno che i parametri REV siano defi-
niti separatamente per ogni COP.
7.3.3.5. Cambiamento dell'ente ATC ricevente
Il messaggio REV non si utilizza se una revisione dei dati del
piano di volo determina un cambiamento dell'ente ATC ricevente
(cfr. messaggio di abrogazione del coordinamento).
7.3.4. Riscontro al REV
7.3.4.1. Riscontro
Se il messaggio REV:
— risulta associabile ad un piano di volo contenuto nel sistema
ricevente, è trasmesso in riscontro un messaggio LAM;
— non risulta associabile ad alcun piano di volo contenuto nel
sistema ricevente, non è trasmesso alcun messaggio LAM.
7.3.4.2. Mancato riscontro7.3.4.2.1. In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio REV, sullo schermo della posizione
di lavoro dell'ente ATC responsabile del coordinamento del volo
è visualizzato un avvertimento.
7.3.4.2.2. Nei casi di mancato ricevimento di un messaggio LAM l'ente
ATC trasferente avvia una revisione verbale.
7.3.5. Esempi
7.3.5.1. I C A O
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 EGBB2000R2082 — IT — 15.06.2002 — 001.001 — 34
▼B
▼M1
▼M1
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. Messaggiodiabrogazionedelcoordinamento(MAC)
7.4.1. Scopo del messaggio MAC
Il messaggio MAC è usato per indicare all'ente ricevente che il
coordinamento o la notifica effettuati precedentemente per un
volo sono abrogati.
Il messaggio MAC non sostituisce un messaggio di cancellazione
(CNL) quale definito dall'ICAO, e quindi non è usato per cancel-
lare i dati del piano di volo di base.
7.4.2. Contenuto del messaggio
Il messaggio MAC contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio (facoltativo);
— identificazione dell'aeromobile;— aerodromo di partenza;
— punto di coordinamento;
— aerodromo di destinazione;— status del coordinamento e motivo dell'abrogazione (facolta-
tivo).
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
7.4.3. Regole di applicazione
7.4.3.1. Indicazioni generali
7.4.3.1.1. Un messaggio MAC è inviato all'organismo con il quale era stato
effettuato precedentemente il coordinamento di un volo mediante
un messaggio ACT o RAP quando si verifica una delle situazioni
seguenti:
— la quota prevista al punto di trasferimento è diversa dalla
quota contenuta nel messaggio precedente, con conseguente
cambiamento dell'ente successivo nella sequenza di coordina-
mento;
— la rotta di volo è stata modificata con conseguente cambia-
mento dell'ente successivo nella sequenza di coordinamento;
— il piano di volo è annullato nel sistema dell'ente mittente e
perciò il coordinamento non è più necessario;
— l'ente precedente ha inviato un MAC relativamente al volo.
7.4.3.1.2. Quando il messaggio MAC è inviato per una variazione del
livello di volo o della rotta, la notifica e/o il coordinamento, a
seconda dei casi, sono effettuati con il nuovo ente nella sequenza
di coordinamento.
7.4.3.1.3. Un messaggio MAC è inviato in caso di abrogazione del coordi-
namento effettuato mediante un messaggio PAC per un volo in
partenza.
7.4.3.1.4. Raccomandazione È opportuno inviare un messaggio MAC
quando la notifica (messaggio ABI) effettuata precedentemente
per un volo è annullata per una delle ragioni indicate nel punto
7.4.3.1.1 precedente o il volo è ritardato in rotta e non è possi-
bile determinare automaticamente uno stimato riveduto.
7.4.3.1.5. Se concordato bilateralmente, nel messaggio MAC è indicato il
riferimento del messaggio.2000R2082 — IT — 15.06.2002 — 001.001 — 35
▼B
▼B
7.4.3.1.6. Il riferimento del messaggio, se indicato, contiene il numero
dell'ultimo messaggio ABI, PAC o ACT trasmesso per il volo e
a cui è stato dato riscontro.
7.4.3.1.7. Il punto di coordinamento è il COP utilizzato per la notifica o il
coordinamento precedente.
7.4.3.1.8. Raccomandazione È opportuno che il messaggio MAC indichi lo
status a cui deve tornare il coordinamento o la notifica ed il
motivo dell'abrogazione.
7.4.3.1.9. Lo status ed il motivo, se sono indicati, sono una delle combina-
zioni seguenti:
— quando l'ente ricevente non è più l'interlocutore di coordina-
mento successivo:
— lo status è INI (iniziale);
— il motivo è uno dei seguenti:
— TFL in caso di variazione della quota di trasferimento;
— RTE in caso di variazione di rotta;
— CSN in caso di variazione dell'indicativo di chiamata;
— CAN in caso di cancellazione;— OTH in tutti gli altri casi o se il motivo non è noto;
— quando si presenta una delle condizioni seguenti:
— il coordinamento effettuato mediante il messaggio PAC o
ACT precedente (eventualmente modificato da uno o più
messaggi REV) è abrogato ma si prevede che il volo sarà
oggetto di una nuova sequenza di coordinamento con lo
stesso ente;
oppure
— dopo la trasmissione di un messaggio ABI il volo è in
attesa per un periodo indeterminato e si prevede che sarà
trasmesso un messaggio ABI o ACT riveduto, secondo il
caso:
— lo status è NTF (notifica);
— il motivo è uno dei seguenti:
— DLY in caso di ritardo;
— HLD in caso di attesa;
— OTH in tutti gli altri casi, o se il motivo non è
noto.
7.4.3.1.10. Se il volo deve essere oggetto di una nuova notifica o di un
nuovo coordinamento:
— sono inviati una nuova notifica e/o un nuovo messaggio di
coordinamento, secondo il caso;
— un messaggio MAC non ha alcun effetto sui dati del piano di
volo di base memorizzati nel sistema dell'ente ATC ricevente;
— il sistema resta in grado di elaborare correttamente una nuova
notifica e/o un nuovo messaggio di coordinamento provenienti
dall'ente trasferente precedente o da un ente diverso in una
nuova sequenza di coordinamento.
7.4.3.2. Elaborazione nell'ente ricevente
La o le posizioni di lavoro dell'ente ATC ricevente a cui sono
comunicate le informazioni sul volo sono avvisate dell'abroga-
zione.
7.4.4. Riscontro al MAC
7.4.4.1. Riscontro7.4.4.1.1. Se il messaggio MAC risulta associabile ad un piano di volo
contenuto nel sistema ricevente e può essere elaborato, è
trasmesso in riscontro un messaggio LAM.
7.4.4.1.2. Se il messaggio MAC non risulta associabile ad alcun piano di
volo contenuto nel sistema ricevente o non può essere elaborato,
non è trasmesso alcun messaggio LAM.
7.4.4.2. Mancato riscontro
7.4.4.2.1. Se viene abrogato il coordinamento ATC e non viene ricevuto
alcun messaggio LAM, alla posizione di lavoro dell'ente ATC
responsabile del coordinamento è visualizzato un avvertimento.2000R2082 — IT — 15.06.2002 — 001.001 — 36
▼B
7.4.4.2.2. In questi casi l'ente ATC trasferente effettua un'abrogazione
verbale del coordinamento.
7.4.5. Esempi
È stato inviato un messaggio ABI dall'ACC di Amsterdam
all'ACC di Bruxelles per il volo HOZ3188, livello di volo piani-
ficato FL190; il volo chiede l'autorizzazione a salire a FL270 e
viene autorizzato a farlo, entrando così nello spazio aereo di
Maastricht anziché in quello di Bruxelles. Gli esempi 7.4.5.1 a.
e 7.4.5.2 a. indicano come sarebbe il MAC trasmesso a Bruxelles
da Amsterdam nel formato ICAO e nel formato ADEXP.
Un messaggio ABI e successivamente un messaggio ACT
vengono inviati a Maastricht, ma qualche minuto prima di
raggiungere il COP l'aeromobile torna verso l'aeroporto di
Amsterdam ed il piano di volo viene cancellato nel sistema
dell'ente mittente; a Maastricht viene inviato un messaggio
MAC, riportato negli esempi 7.4.5.1 b. e 7.4.5.2 b.
7.4.5.1. ICAO
a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/
INITFL)
b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/
INICAN)
7.4.5.2. ADEXP
a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON TFL
b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON CAN
7.5. MessaggiodiassegnazionedicodiceSSR(COD)
7.5.1. Scopo del messaggio COD
7.5.1.1. Il metodo di assegnazione dei codici in funzione della regione
d'origine (ORCAM) è stato studiato per permettere ad un volo di
rispondere sullo stesso codice ad enti successivi nella zona di
partecipazione. In mancanza di un'assegnazione centrale dei
codici, assicurata ad esempio da un ACC, può essere necessario
assegnare singolarmente agli aeroporti una serie di codici SSR
individuali, il che comporta una grande dispersione di codici.
7.5.1.2. Il messaggio COD consente ad un ente ATS di emettere un
codice SSR in modo A destinato all'ente successivo per un deter-
minato volo, qualora ciò sia richiesto. Un servizio facoltativo
permette all'ente mittente di includere la rotta di volo, se così è
concordato bilateralmente
7.5.2. Contenuto del messaggio
Il messaggio COD contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio (facoltativo);— identificazione dell'aeromobile;
— modo e codice SSR;
— aerodromo di partenza;— aerodromo di destinazione;— rotta (facoltativo).
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
7.5.3. Regole di applicazione
7.5.3.1. Indicazioni generali
7.5.3.1.1. Un messaggio COD è generato e trasmesso automaticamente in
risposta ad una richiesta di assegnazione di codice ricevuta in un
messaggio.
7.5.3.1.2. Il codice SSR è il codice assegnato al volo.2000R2082 — IT — 15.06.2002 — 001.001 — 37
▼B
7.5.3.1.3. Se non è disponibile un codice individuale è inserito il codice di
saturazione approvato, così come specificato nel piano di naviga-
zione aerea per la regione Europa.
7.5.3.1.4. Se concordato bilateralmente, è incluso il riferimento del
messaggio, contenente il numero del messaggio a cui risponde il
messaggio COD.
7.5.3.1.5. Se concordato bilateralmente, è inclusa la rotta.7.5.3.1.6. Si presuppone che l'ente che riceve il messaggio COD accetti il
codice SSR.
7.5.3.2. Elaborazione nell'ente ricevente7.5.3.2.1. Se nel messaggio non vi sono discordanze che ne impediscano la
corretta elaborazione, è inviato un LAM in risposta.
7.5.3.2.2. Se il messaggio non risulta associabile ad un piano di volo o se è
rilevata una discordanza che impedisce la corretta elaborazione
del messaggio, non è inviato alcun messaggio LAM.
7.5.3.2.3. I dati di rotta eventualmente riportati non sono un motivo che
possa impedire l'invio di un LAM in risposta, a meno che essi
non risultino non conformi alle prescrizioni relative al formato
indicate nell'allegato A.
7.5.3.3. Parametri temporali per la trasmissione
Alla trasmissione non è applicabile un parametro temporale
perché il messaggio COD è inviato in risposta ad un messaggio
contenente una richiesta di assegnazione di codice SSR.
7.5.4. Riscontro al COD
7.5.4.1. Riscontro
Al messaggio COD è dato riscontro tramite la generazione e
trasmissione di un messaggio LAM.
7.5.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio COD, sullo schermo della posizione
di lavoro competente è visualizzato un avvertimento.
7.5.5. Esempi
7.5.5.1. ICAO
(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. Messaggiodiinformazione (INF)
7.6.1. Scopo del messaggio INF
7.6.1.1. Il messaggio INF è usato per fornire informazioni su voli speci-
fici ad enti non direttamente coinvolti nel processo di
coordinamento tra due enti ATC successivi sulla rotta di volo.
7.6.1.2. Il messaggio INF può essere utilizzato per fornire copie di
messaggi agli enti suindicati e per comunicare loro le condizioni
di coordinamento concordate in seguito ad un dialogo tra control-
lori. A tal fine, i messaggi INF possono essere generati dal
sistema dell'ente trasferente o da quello dell'ente accettante.
7.6.1.3. Il messaggio INF può essere usato anche per fornire ad un ente
informazioni relative a qualsiasi punto sulla rotta di volo.
7.6.1.4. Il formato consente la comunicazione dei dati iniziali, delle revi-
sioni e delle cancellazioni.
7.6.2. Contenuto del messaggio
Il messaggio INF contiene i dati seguenti nel formato di
messaggio descritto nel presente documento:
— tipo di messaggio;
— numero del messaggio;2000R2082 — IT — 15.06.2002 — 001.001 — 38
▼B
— tutti i dati operativi del messaggio originario o del coordina-
mento risultante di cui il messaggio INF presenta una copia;
— tipo del messaggio di riferimento.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
7.6.3. Regole di applicazione
7.6.3.1. Tipi di messaggio
Il tipo o i tipi di messaggio di cui il messaggio INF presenta
copia dipendono dalle necessità degli utilizzatori e dai mezzi di
cui dispone l'ente mittente. Il tipo o i tipi di messaggio e le regole
di applicazione normalmente sono concordati bilateralmente.
7.6.3.2. Destinatari dei messaggi
Uno o più messaggi INF riguardanti uno stesso volo possono
essere trasmessi ad uno o più destinatari.
7.6.3.3. Contenuto operativo
Il contenuto operativo del messaggio INF è presentato nel
formato di uno dei messaggi esistenti.
7.6.3.4. Raccomandazioni
1.Le condizioni comunicate in un messaggio di dialogo iniziale
(ad esempio messaggi ACT, RAP, REV, RRV) possono essere
modificate o rigettate prima della fine del dialogo. È oppor-
tuno che gli enti mittenti siano in grado di trasmettere le
condizioni di coordinamento definitive adottate .
2.È opportuno che il messaggio INF venga trasmesso immedia-
tamente o in un momento collegato all'orario sul COP
concordato bilateralmente con l'ente ricevente
7.6.4. Riscontro all'INF
Raccomandazioni
1.Al messaggio INF può essere dato riscontro mediante la gene-
razione e trasmissione di un messaggio LAM, a seconda
dell'interlocutore di coordinamento .
2.Se così è concordato bilateralmente tra gli enti competenti, in
caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio INF è opportuno che compaia un
avvertimento alla posizione di lavoro competente .
7.6.5. Esempi
Aeromobile B747 con indicativo di chiamata BAW011, in volo
da EGLL a OMDB, livello di volo FL290, richiesta di salire a
FL410; orario previsto al VOR di Koksy (KOK) 1905, tran-
sponder regolato su A5437, rotta via UG1 e UB6.
Londra invia a Maastricht un messaggio ACT per il volo, e ne
trasmette copia ad un ente denominato IT.
Qui di seguito sono riportati esempi del messaggio INF.
7.6.5.1. ICAO
(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 ACT2000R2082 — IT — 15.06.2002 — 001.001 — 39
▼B
8. PROCEDURADIDIALOGO—COORDINAMENTO
8.1. Indicazionigenerali
8.1.1. Introduzione
8.1.1.1. La procedura di dialogo fornisce i mezzi per la comunicazione e
negoziazione tra controllori nella fase di coordinamento e per la
comunicazione nella fase di trasferimento.
8.1.1.2. La presente sezione descrive i messaggi usati nella procedura di
dialogo durante la fase di coordinamento in cui sono pianificate
le condizioni di trasferimento. I messaggi usati nella fase di
trasferimento in cui il controllo di un volo passa un ente al
successivo sono descritti nella sezione 9 — Procedura di dialogo
— Trasferimento delle comunicazioni.
8.1.1.3. Le procedure definite per le due fasi non sono interdipendenti;
possono essere applicate singolarmente o insieme.
8.1.1.4. Sono presentati vari messaggi aggiuntivi, ed è assicurata ad
entrambi gli interlocutori la possibilità di avviare un dialogo.
8.1.1.5. La procedura di dialogo nella fase di coordinamento permette di
distinguere:
— i trasferimenti che sono conformi alle LoA e possono essere
accettati automaticamente; e
— i trasferimenti che devono essere sottoposti al controllore
dell'ente ricevente per una decisione riguardante l'accetta-
zione.
8.1.1.6. Questa procedura permette anche di sorvegliare l'interpretazione
delle LoA nei due sistemi e di individuare eventuali discordanze.
8.1.2. Il filtro
8.1.2.1. Indicazioni generali
8.1.2.1.1. La procedura di dialogo nella fase di coordinamento richiede che
i sistemi stabiliscano se i trasferimenti sono o non sono conformi
alle LoA.
8.1.2.1.2. In questo documento il processo di verifica della conformità è
definito «filtro». Il database utilizzato per il filtro comprende i
seguenti elementi, se necessari:
— punti di coordinamento concordati;
— livelli di volo ammissibili (o non ammissibili) che possono
anche essere associati ai punti di coordinamento;
— aerodromi di partenza;
— destinazioni;
— rotte dirette concordate;— limiti di tempo e/o distanza prima del COP oltrepassati i quali
qualsiasi messaggio di coordinamento è considerato non stan-
dard;
— qualsiasi altra condizione eventualmente concordata bilateral-
mente.
8.1.2.1.3. Tutti gli elementi di questo elenco possono essere associati tra
loro per definire situazioni più complesse.
8.1.2.1.4. Nella sezione 8 del presente documento l'espressione «condizioni
standard» significa «conformi alla LoA» e l'espressione «condi-
zioni non standard» significa «non conformi alla LoA». Se non
diversamente concordato bilateralmente, i messaggi inviati dagli
enti trasferenti per il coordinamento di trasferimenti di cui è
noto il carattere standard sono di tipo diverso da quelli che si
riferiscono a condizioni non standard.
8.1.2.2. Azioni nell'ente trasferente8.1.2.2.1. Il filtro nell'ente trasferente esamina le condizioni di trasferi-
mento in procinto di essere inviate all'ente accettante.
8.1.2.2.2. Raccomandazione Se le condizioni di trasferimento risultano
non standard è opportuno portare il fatto all'attenzione del
controllore trasferente, che potrà confermarle o modificarle.2000R2082 — IT — 15.06.2002 — 001.001 — 40
▼B
8.1.2.3. Azioni nell'ente accettante
8.1.2.3.1. Tutti i messaggi ACT e REV sono controllati per mezzo del
filtro.
8.1.2.3.2. Se dal controllo risulta che le condizioni di trasferimento ricevute
sono non standard, tali condizioni sono sottoposte al controllore
affinché questi prenda una decisione a riguardo; se invece le
condizioni di trasferimento risultano standard esse sono accettate
automaticamente.
8.1.2.4. Sincronizzazione dei filtri
8.1.2.4.1. L'uso di messaggi diversi per le condizioni di trasferimento stan-
dard e non standard permette di individuare le discordanze
rispetto alle condizioni standard contenute nei sistemi degli enti
trasferente e accettante.
8.1.2.4.2. L'identificazione, in seno all'ente accettante, di condizioni di
trasferimento non standard in un messaggio destinato unicamente
a coordinare trasferimenti standard significa che esiste una discor-
danza tra i due filtri. È opportuno che queste discordanze siano
eliminate per garantire l'efficacia della procedura di dialogo.
8.1.3. Sequenza dei messaggi
8.1.3.1. Indicazioni generali
8.1.3.1.1. È necessario seguire determinate regole per assicurarsi che la
procedura di coordinamento sia terminata prima di effettuare revi-
sioni o lo scambio di messaggi per il trasferimento delle
comunicazioni, e per evitare che i controllori dei due enti sotto-
pongano simultaneamente delle proposte per lo stesso volo.
8.1.3.1.2. Un ente ATC deve trasmettere un messaggio di revisione (REV o
RRV) o un riscontro di ricezione di tale messaggio solo quando il
volo è nello status «coordinato», vale a dire quando un dialogo
ACT o RAP è stato completato con un messaggio LAM o ACP.
8.1.3.1.3. Solo l'ente accettante è autorizzato a trasmettere messaggi CDN.
8.1.3.1.4. I messaggi CDN sono trasmessi e sono oggetto di riscontro unica-
mente:
— nell'ambito di un dialogo iniziato dopo il ricevimento di un
messaggio di attivazione (ACT, RAP) o revisione (REV o
RRV); oppure
— quando il piano di volo in questione è nello status «coordi-
nato».
8.1.4. Trattamento simultaneo dei messaggi
8.1.4.1. Indicazioni generali8.1.4.1.1. Un ente che partecipa ad uno scambio di messaggi di coordina-
mento o trasferimento per un determinato volo non avvia un
altro scambio di messaggi di coordinamento o trasferimento per
lo stesso volo con lo stesso ente finché non ha ricevuto un
messaggio LAM, ACP o RJC, o finché non è stato raggiunto un
tempo massimo consentito.
8.1.4.1.2. È possibile che un messaggio CDN si incroci con un messaggio
REV, RRV o MAC inviato dall'ente trasferente per lo stesso volo.
L'ente trasferente può riconoscere questa situazione dal fatto che
il CDN gli giunge prima del riscontro al messaggio di coordina-
mento trasmesso, mentre l'ente accettante può riconoscerla dal
fatto che il messaggio dell'ente trasferente gli giunge prima del
riscontro al CDN. In questo caso al CDN non è dato riscontro
ed il messaggio REV, RRV o MAC non è elaborato.
8.1.5. Trattamento dei messaggi di rigetto
Il messaggio RJC pone fine ad un dialogo tra sistemi. Ove appro-
priato, deve essere avviato un nuovo coordinamento che rispecchi
il coordinamento telefonico.
8.1.6. Tempo massimo consentito per la risposta operativa
8.1.6.1. Indicazioni generali
8.1.6.1.1. Per la risposta a messaggi sottoposti all'accettazione del control-
lore, nei centri mittente e ricevente è utilizzato un meccanismo di
temporizzazione che prevede l'impiego di tempi massimi consen-
titi.2000R2082 — IT — 15.06.2002 — 001.001 — 41
▼B
8.1.6.1.2. La durata dei tempi massimi consentiti è concordata bilateral-
mente.
8.1.6.1.3. Una volta superato il tempo massimo consentito nell'ente trasfe-
rente, al controllore trasferente è presentato un avvertimento che
segnala la necessità di avviare un coordinamento telefonico.
8.1.6.1.4. Raccomandazioni
1.È opportuno che sullo schermo della posizione ATC dell'ente
accettante responsabile del volo sia visualizzato un avverti-
mento quando è imminente il superamento del tempo
massimo consentito nell'ente trasferente .
2.È opportuno che l'avvertimento tenga conto del tempo di
trasmissione della risposta .
8.1.6.1.5. I sistemi sono in grado di elaborare le risposte ricevute dopo il
superamento del tempo massimo consentito.
8.1.7. Attuazione
8.1.7.1. Le procedure di dialogo si applicano a due fasi: la fase di coordi-
namento e la fase di trasferimento. I messaggi ed i tempi di
transazione richiesti nelle due fasi sono diversi. I messaggi di
coordinamento sono presentati in formato ICAO e in formato
ADEXP, i messaggi di trasferimento delle comunicazioni solo in
formato ADEXP.
8.1.7.2. I requisiti HMI minimi per il dialogo di coordinamento sono di-
versi da quelli relativi al dialogo di trasferimento:
— il dialogo di trasferimento si riferisce principalmente alla
funzione di controllo esecutivo e necessita di un'HMI rapida
e user-friendly;
— il dialogo di coordinamento non ha un carattere d'urgenza
altrettanto marcato ed i requisiti relativi all'HMI sono meno
severi.
8.1.7.3. La procedura di dialogo è attuata usando uno degli scenari alter-
nativi seguenti:
— procedura di dialogo per la fase di coordinamento più
messaggi complementari concordati bilateralmente (sezioni 7
e 8);
— procedura di coordinamento di base e procedura di dialogo
per la fase di trasferimento (sezioni 6, 7 e 9);
— procedura di dialogo per le fasi di coordinamento e di trasfe-
rimento più messaggi di coordinamento complementari
concordati bilateralmente (sezioni 7, 8 e 9).
Il messaggio di preavviso di attraversamento di confine (ABI) è
inviato in tutti gli scenari indicati.
8.1.7.4. Lo scenario usato per l'attuazione è concordato bilateralmente.
8.2. Messaggiodiattivazione(ACT)
8.2.1. Scopo del messaggio ACT
Lo scopo del messaggio ACT è descritto nel punto 6.3.1. In una
procedura di dialogo, il messaggio ACT è usato per rispondere
alle necessità indicate a condizione che le condizioni di trasferi-
mento per il volo siano standard e che il controllore trasferente
non abbia bisogno di sottoporre il volo al controllore accettante
per accettazione.
8.2.2. Contenuto del messaggio
Il contenuto del messaggio ACT usato nella procedura di dialogo
è uguale a quello descritto per il messaggio ACT nel punto 6.3.2.
8.2.3. Regole di applicazione
8.2.3.1. Indicazioni generali8.2.3.1.1. Le regole di applicazione sono quelle descritte per i messaggi
ACT nel punto 6.3, fatta eccezione per le regole particolari illu-
strate nel presente punto.
8.2.3.1.2. Un messaggio ACT è inviato nel caso di un volo con condizioni
di trasferimento standard che il controllore trasferente non chiede
siano sottoposte al controllore accettante.2000R2082 — IT — 15.06.2002 — 001.001 — 42
▼B
NOTANegli altri casi è inviato un messaggio RAP (cfr. punto
8.3 Messaggio di proposta di attivazione sottoposta per
accettazione).
8.2.3.1.3. Raccomandazione Se in risposta ad un messaggio ACT è inviato
un messaggio di rigetto di coordinamento (RJT), è opportuno che
sia avviata una nuova procedura di coordinamento.
8.2.3.2. Elaborazione nell'ente ricevente8.2.3.2.1. Il messaggio è controllato mediante il filtro allo scopo di confer-
mare che le condizioni proposte sono standard.
8.2.3.2.2. Il messaggio è elaborato come un messaggio RAP se:
— le condizioni di trasferimento risultano non standard;
— non viene trovato un piano di volo di sistema corrispondente,
e le informazioni disponibili sono insufficienti per stabilire se
le condizioni di trasferimento sono standard.
8.2.3.2.3. I messaggi ACT che risultano standard sono elaborati conforme-
mente a quanto indicato nel punto 6.3.3.2.
8.2.3.2.4. Raccomandazione Se le condizioni di trasferimento in un
messaggio ACT risultano non standard, c'è una discordanza tra
i filtri dei due sistemi. È opportuno portare all'attenzione del
personale di supervisione il fatto che l'ACT è non standard, cosìda poter eliminare tale discordanza.
8.2.4. Riscontro all'ACT
8.2.4.1. Riscontro
8.2.4.1.1. In una procedura di dialogo ad un messaggio ACT è dato
riscontro mediante:
— un messaggio LAM se le condizioni di trasferimento risultano
standard;
— un messaggio SBY in tutti gli altri casi.
8.2.4.1.2. Una volta ricevuto un LAM il contenuto operativo del messaggio
ACT diventa operativamente vincolante per entrambi gli enti
ATC.
8.2.4.1.3. Se concordato bilateralmente, si può usare un messaggio ACP al
posto di un LAM per indicare l'accettazione di un ACT conte-
nente condizioni di trasferimento standard da parte dell'ente
accettante.
8.2.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un riscontro ad un messaggio
ACT, sullo schermo della posizione ATC responsabile del coordi-
namento del volo è visualizzato un avvertimento.
8.3. Messaggio di proposta di attivazione sottoposta per accetta-
zione(RAP)
8.3.1. Scopo del messaggio RAP
Il messaggio RAP risponde alle necessità operative seguenti, oltre
a quelle precisate per il messaggio ACT nel punto 6.3:
— permettere al controllore trasferente di proporre e sottoporre
al controllore accettante voli con condizioni di trasferimento
non standard;
— permettere al controllore trasferente, se necessario, di forzare
la presentazione al controllore accettante di condizioni di
trasferimento standard per un volo specifico.
8.3.2. Contenuto del messaggio
Il contenuto del messaggio RAP è costituito dagli stessi dati
precisati per il messaggio ACT (punto 6.3) e può comprendere
facoltativamente l'informazione seguente:
— motivo, con indicazione della presentazione manuale (disponi-
bile solo in ADEXP).2000R2082 — IT — 15.06.2002 — 001.001 — 43
▼B
8.3.3. Regole di applicazione
8.3.3.1. Indicazioni generali8.3.3.1.1. Un messaggio RAP è inviato al posto del messaggio ACT per i
voli che attraversano il confine e soddisfano una delle condizioni
seguenti:
— il sistema dell'ente trasferente ha stabilito che le condizioni di
trasferimento sono non standard;
— il controllore trasferente ha indicato che le condizioni di
trasferimento proposte devono essere sottoposte del control-
lore accettante.
8.3.3.1.2. Il contenuto operativo del messaggio RAP da trasmettere è visua-
lizzato sullo schermo della posizione di lavoro responsabile del
coordinamento del volo prima dell'effettiva trasmissione.
8.3.3.1.3. Raccomandazione È opportuno che insieme al contenuto del
messaggio RAP sia visualizzato l'orario di trasmissione automa-
tica del messaggio RAP.
8.3.3.1.4. La trasmissione del messaggio RAP è notificata alla posizione di
lavoro competente.
8.3.3.2. Elaborazione nell'ente ricevente8.3.3.2.1. Il sistema ACT che riceve un messaggio RAP cerca di associarlo
ai dati del piano di volo corrispondente.
8.3.3.2.2. Se il tentativo di associazione al piano di volo ha esito positivo e
se nel messaggio non è rilevata alcuna discordanza che ne impe-
disca la corretta elaborazione:
— il contenuto operativo è sottoposto al controllore accettante;
— è inviato in risposta un messaggio SBY.
8.3.3.2.3. Raccomandazione È opportuno indicare il motivo della presen-
tazione della proposta per accettazione (condizioni non standard
o presentazione manuale).
8.3.3.2.4. Se il tentativo di associazione del messaggio ad un piano di volo
non ha esito positivo o se è rilevata una discordanza che impe-
disce la corretta elaborazione del messaggio:
— il contenuto operativo del messaggio è visualizzato sugli
schermi del settore;
e
— è inviato in risposta un messaggio SBY;
e
— è creato un piano di volo.
8.3.3.2.5. In tutti gli altri casi al messaggio non è dato riscontro.
8.3.3.3. Attivazione manuale
8.3.3.3.1. Quando il messaggio RAP è usato per forzare la presentazione di
un coordinamento proposto con condizioni di trasferimento stan-
dard al controllore accettante, il messaggio è attivato
manualmente dal controllore trasferente e trasmesso immediata-
mente.
8.3.3.3.2. Raccomandazione È opportuno consentire alla posizione respon-
sabile del coordinamento del volo l'attivazione manuale di un
messaggio RAP prima dell'orario calcolato di trasmissione.
8.3.3.4. Parametri temporali per la trasmissione automatica
Il lasso di tempo/distanza prima del confine a cui sono trasmessi
automaticamente i messaggi RAP sono identici a quelli relativi ai
messaggi ACT.
8.3.4. Riscontro al RAP
8.3.4.1. Riscontro
Al messaggio RAP è dato riscontro mediante la generazione e
trasmissione di un messaggio SBY.
8.3.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio SBY in riscontro
ad un messaggio RAP, sullo schermo della posizione ATC
responsabile del coordinamento del volo è visualizzato un avver-
timento.2000R2082 — IT — 15.06.2002 — 001.001 — 44
▼B
8.3.5. Risposta operativa al RAP
Il controllore accettante può accettare le condizioni di trasferi-
mento, rigettarle o presentare una controproposta.
8.3.5.1. Accettazione8.3.5.1.1. Quando il controllore accettante decide di accettare le condizioni
di trasferimento proposte, è inviato in risposta un messaggio
ACP.
8.3.5.1.2. Una volta ricevuto il messaggio ACP, i dati del messaggio RAP
diventano operativamente vincolanti per entrambi gli enti ATC. Il
controllore trasferente è informato delle condizioni di trasferi-
mento coordinate e del ricevimento dell'ACP.
8.3.5.2. Contropr oposta
Quando il controllore accettante decide di controproporre delle
condizioni di trasferimento, è inviato in risposta un messaggio
CDN.
8.3.5.3. Raccomandazione Quando il controllore accettante decide di
rigettare le condizioni di trasferimento proposte, è opportuno
che sia inviato in risposta un messaggio RJC e che sia avviato
un nuovo processo di coordinamento.
NOTAIn riferimento alla raccomandazione di cui al
punto 8.3.5.3, nella maggior parte dei casi il nuovo coor-
dinamento si attua con un ente diverso.
8.3.6. Esempi
8.3.6.1. ICAO
(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. Messaggiodirevisione (REV)
8.4.1. Scopo del messaggio REV
Lo scopo del messaggio REV è descritto nel punto 7.3.1. In una
procedura di dialogo il messaggio REV è utilizzato per rispondere
alle necessità indicate a condizione che le condizioni di trasferi-
mento per il volo siano standard e che il controllore trasferente
non abbia bisogno di sottoporre il volo al controllore accettante
per accettazione.
8.4.2. Contenuto del messaggio
Il contenuto del messaggio REV è uguale a quello descritto per il
messaggio REV nel punto 7.3.2.
8.4.3. Regole di applicazione
8.4.3.1. Indicazioni generali
8.4.3.1.1. Uno o più messaggi REV possono essere inviati all'ente con cui è
stato coordinato un volo mediante un messaggio di attivazione o
un messaggio RAP.
8.4.3.1.2. I messaggi REV sono inviati così come precisato nel punto
7.3.3.1 per i voli con condizioni di trasferimento standard che il
controllore trasferente non ha bisogno di sottoporre al controllore
accettante.
8.4.3.2. Avvio della trasmissione
Il messaggio REV è trasmesso non appena è rilevata una varia-
zione dei dati di coordinamento che renda necessario un
coordinamento, così come descritto nel punto 7.3.3.2000R2082 — IT — 15.06.2002 — 001.001 — 45
▼B
8.4.3.3. Elaborazione nell'ente ricevente
8.4.3.3.1. Se è individuato un piano di volo corrispondente nello status
«coordinato» e non è rilevata alcuna discordanza che impedisca
una corretta elaborazione del messaggio:
— è dato riscontro al messaggio REV;
— in tutti gli altri casi al messaggio non è dato riscontro.
8.4.3.3.2. Le condizioni di trasferimento sono esaminate per verificare che
siano standard.
8.4.3.3.3. Se le condizioni di trasferimento risultano non standard, esse sono
sottoposte al controllore accettante.
8.4.3.3.4. Se le condizioni di trasferimento proposte risultano standard, esse
sono inserite nel piano di volo ed i dati necessari sono presentati
alle posizioni ATC operative e ad altre posizioni, se del caso.
8.4.3.3.5. Raccomandazione Se le condizioni di trasferimento in un
messaggio REV risultano non standard c'è una discordanza tra i
filtri dei due sistemi. È opportuno portare all'attenzione del
personale di supervisione il fatto che il REV è non standard,
così da poter eliminare tale discordanza.
8.4.4. Riscontro al REV
8.4.4.1. Riscontro8.4.4.1.1. Se è necessario dare riscontro al messaggio REV si utilizza:
— un messaggio LAM se le condizioni di trasferimento risultano
standard;
— un messaggio SBY se le condizioni di trasferimento risultano
non standard.
8.4.4.1.2. Una volta ricevuto un messaggio LAM il contenuto operativo del
messaggio REV diventa operativamente vincolante per entrambi
gli enti ATC.
8.4.4.1.3. Se concordato bilateralmente, si può usare un ACP al posto di un
LAM per indicare l'accettazione di un REV contenente condizioni
di trasferimento standard da parte dell'ente accettante.
8.4.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio di riscontro ad
un messaggio REV, sullo schermo della posizione ATC responsa-
bile del coordinamento dei voli è visualizzato un avvertimento.
8.4.5. Risposta operativa al REV
Dal momento che il messaggio REV è utilizzato per notificare
condizioni di trasferimento standard, normalmente esso è accet-
tato dal sistema dell'ente accettante. Se il filtro dell'ente
accettante rileva che le condizioni di trasferimento sono non stan-
dard il messaggio è elaborato come un messaggio RRV.
8.5. Messaggiodipropostadirevisionesottopostaperaccettazione
(RRV)
8.5.1. Scopo del messaggio RRV
Il messaggio RRV permette la revisione di condizioni di trasferi-
mento precedentemente inviate ed approvate nei casi seguenti:
— quando le condizioni di trasferimento proposte nella revisione
sono non standard;
— quando la revisione proposta è standard, ma il controllore
trasferente vuole sottoporre la revisione al controllore accet-
tante.
8.5.2. Contenuto del messaggio
Il contenuto del messaggio RRV è lo stesso descritto per il
messaggio REV (punto 7.3.2) e può facoltativamente compren-
dere l'elemento seguente:
— motivo, con indicazione della presentazione manuale (disponi-
bile solo in formato ADEXP).2000R2082 — IT — 15.06.2002 — 001.001 — 46
▼B
8.5.3. Regole di applicazione
8.5.3.1. Indicazioni generali
Uno o più messaggi RRV sono inviati al posto di messaggi REV
per ciascuna revisione se:
— il sistema trasferente ha stabilito che le condizioni di trasferi-
mento sono non standard;
oppure se
— il controllore trasferente ha indicato che le condizioni di
trasferimento proposte devono essere sottoposte al controllore
accettante. L'uso dell'RRV in questo caso è facoltativo.
8.5.3.2. Avvio della trasmissione
Il messaggio RRV è inviato non appena è rilevata una variazione
dei dati di coordinamento oppure quando è attivato manualmente.
8.5.3.3. Elaborazione nell'ente ricevente8.5.3.3.1. Se è individuato un piano di volo corrispondente nello status
«coordinato» e non è rilevata alcuna discordanza che impedisca
la corretta elaborazione del messaggio:
— è dato riscontro al messaggio RRV;
— in tutti gli altri casi al messaggio non è dato riscontro.
8.5.3.3.2. Le condizioni di trasferimento proposte sono visualizzate sullo
schermo della posizione ATC responsabile del coordinamento
del volo.
8.5.3.3.3. Raccomandazione È opportuno indicare il motivo per cui la
proposta è sottoposta per accettazione (condizioni non standard
o presentazione manuale) .
8.5.4. Riscontro all'RRV
8.5.4.1. Riscontro
Al messaggio è dato riscontro mediante la generazione e trasmis-
sione di un messaggio SBY.
8.5.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio SBY in riscontro
ad un messaggio RRV, sullo schermo della posizione ATC
responsabile del coordinamento del volo è visualizzato un avver-
timento.
8.5.5. Risposta operativa all'RRV
Il controllore accettante può accettare un messaggio RRV, riget-
tarlo o presentare una controproposta.
8.5.5.1. Accettazione
Quando il controllore accettante decide di accettare la modifica
proposta delle condizioni di trasferimento concordate, è inviato
un messaggio ACP in risposta.
8.5.5.2. Contropr oposta
Quando il controllore accettante decide di controproporre delle
condizioni di trasferimento, è inviato un messaggio CDN in
risposta.
8.5.5.3. Rigetto
Quando il controllore accettante decide di rigettare la modifica
proposta delle condizioni di trasferimento concordate:
— è inviato un messaggio RJC in risposta;
e
— è avviato un nuovo processo di coordinamento.
Il mancato ricevimento di un messaggio ACP o di un messaggio
CDN in risposta al messaggio RRV indica che questo è stato
rigettato.
8.5.6. Esempi
8.5.6.1. ICAO
(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)2000R2082 — IT — 15.06.2002 — 001.001 — 47
▼B
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. Messaggiodiattesa(SBY)
8.6.1. Scopo del messaggio SBY
Il messaggio SBY dà riscontro al ricevimento di un messaggio in
cui si propongono condizioni di trasferimento e indica che la
proposta è all'esame del controllore affinché questi prenda una
decisione a riguardo.
8.6.2. Contenuto del messaggio
Il messaggio SBY contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
8.6.3. Regole di applicazione
8.6.3.1. Indicazioni generali
Il messaggio SBY è generato e trasmesso automaticamente subito
dopo il ricevimento di:
— un messaggio RAP, RRV o CDN;
— un messaggio ACT o REV che non supera l'esame del filtro.
8.6.4. Riscontro all'SBY
Al messaggio SBY non è dato riscontro.
8.6.5. Esempi
8.6.5.1. ICAO
(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. Messaggiodiaccettazione (ACP)
8.7.1. Scopo del messaggio ACP
Il messaggio ACP risponde alle necessità operative seguenti
durante le fasi di coordinamento e trasferimento ATC:
— indicare l'accettazione manuale da parte di un controllore di
un ente delle condizioni di trasferimento proposte dal control-
lore dell'altro ente in uno dei seguenti messaggi:
— RAP;
— RRV;
— CDN;
— ACT e REV, se le condizioni risultano non standard;
— previo accordo bilaterale, permettere l'accettazione automatica
di un messaggio ACT o REV che ha superato il filtro nell'ente
ricevente (al posto del LAM);
— previo accordo bilaterale, indicare l'accettazione manuale di
un messaggio HOP (al posto del messaggio ROF).
8.7.2. Contenuto del messaggio
Il messaggio ACP contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio;
— Dati facoltativi — il messaggio può contenere anche:
— frequenza;2000R2082 — IT — 15.06.2002 — 001.001 — 48
▼B
— Dati facoltativi di messaggi in formato ICAO — il messaggio
può contenere anche tutti i dati seguenti:
— identificazione dell'aeromobile;
— aerodromo di partenza;— aerodromo di destinazione.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
8.7.3. Regole di applicazione
8.7.3.1. Indicazioni generali8.7.3.1.1. Il riferimento del messaggio ACP comprende il numero del
messaggio a cui l'ACP risponde.
8.7.3.1.2. Il campo Frequenza, quando è incluso, contiene la frequenza sulla
quale il volo deve contattare l'ente accettante al momento del
trasferimento del controllo.
8.7.3.1.3. Il messaggio ACP è inviato dopo l'accettazione manuale da parte
del controllore delle condizioni di trasferimento proposte in un
messaggio ACT, RAP, REV, RRV o CDN.
8.7.3.1.4. Il messaggio ACP può essere inviato in alternativa ad un
messaggio ROF in risposta ad un messaggio HOP.
8.7.3.1.5. Se concordato bilateralmente, il messaggio ACP è generato e
trasmesso automaticamente dal sistema in risposta ad un ACT/
REV che ha superato il filtro.
8.7.3.1.6. Una volta ricevuto un ACP, le condizioni di trasferimento
concordate diventano vincolanti per entrambi gli enti.
8.7.3.2. Elaborazione nell'ente ricevente8.7.3.2.1. Il sistema ATC che riceve un messaggio ACP cerca di associarlo
al piano di volo corrispondente.
8.7.3.2.2. Se il tentativo di associazione ha esito positivo l'accettazione è
indicata al controllore.
8.7.3.2.3. Se il tentativo non ha esito positivo:
— è presentato un avvertimento alla posizione di lavoro compe-
tente; e
— non è inviato un LAM.
8.7.4. Riscontro all'ACP
8.7.4.1. Riscontro
8.7.4.1.1. Quando l'ACP è usato come risposta automatica per un
messaggio ACT o REV che ha superato il filtro non è inviato un
LAM in riscontro.
8.7.4.1.2. Ad un messaggio ACP inviato in seguito ad un'accettazione
manuale è dato riscontro tramite la generazione e trasmissione di
un messaggio LAM.
8.7.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio ACP inviato in seguito ad un'accetta-
zione manuale, sullo schermo della posizione ATC responsabile
del coordinamento del volo è visualizzato un avvertimento.
8.7.5. Esempi
8.7.5.1. ICAO
(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 2421502000R2082 — IT — 15.06.2002 — 001.001 — 49
▼B
8.8. Messaggiodicoordinamento(CDN)
8.8.1. Scopo del messaggio CDN
Il messaggio CDN risponde alle necessità operative seguenti:
— permettere al controllore accettante di trasmettere una contro-
proposta al controllore trasferente in risposta ad un messaggio
ACT, RAP, REV o RRV;
— permettere al controllore accettante di sottoporre al control-
lore trasferente una proposta di modifica delle condizioni di
trasferimento concordate.
8.8.2. Contenuto del messaggio
Il messaggio CDN contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;— riferimento del messaggio (solo se è in risposta ad un altro
messaggio);
— identificazione dell'aeromobile;— aerodromo di partenza;— aerodromo di destinazione;
NOTAIl messaggio contiene anche uno degli elementi
seguenti, o entrambi:
— dati stimati (nel caso di un messaggio in formato ICAO) o
livello di volo di trasferimento (nel caso di un messaggio
ADEXP);
— richiesta di rotta diretta.
— Dati concordati bilateralmente — Il messaggio può contenere
anche il dato seguente, previo accordo bilaterale:
— frequenza.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
8.8.3. Regole di applicazione
8.8.3.1. Indicazioni generali
8.8.3.1.1. I messaggi CDN sono attivati unicamente dal controllore accet-
tante.
8.8.3.1.2. Il messaggio CDN è usato dal controllore accettante per sotto-
porre una controproposta al controllore trasferente.
NOTAQuesto può avvenire in un dialogo in risposta ad una
proposta trasmessa con un messaggio ACT, RAP, REV,
o RRV, o all'inizio di un dialogo per modificare condi-
zioni di trasferimento precedentemente concordate.
8.8.3.1.3. Il riferimento del messaggio è indicato solo quando il messaggio
CDN è in risposta ad un altro messaggio.
8.8.3.1.4. Il riferimento del messaggio, quando è indicato, contiene il
numero del messaggio a cui risponde il CDN.
8.8.3.1.5. Il servizio di richiesta di rotta diretta (descritto nei particolari
nell'allegato A):
— è usato solo se concordato bilateralmente; e
— se concordato, definisce anche i limiti operativi applicabili al
suo utilizzo.
8.8.3.1.6. Il messaggio CDN non può essere inviato dopo un lasso di
tempo/una distanza prima del confine specificati nella LoA tra
gli enti competenti.
8.8.3.1.7. Se un CDN è trasmesso contemporaneamente ad un messaggio
dell'ente trasferente relativo allo stesso volo, ad esempio una revi-
sione o un'abrogazione di coordinamento, non è inviato in
risposta alcun riscontro o risposta operativa.
NOTAQuesto significa che quando due messaggi si incrociano,
quello dell'ente trasferente ha la priorità ed il CDN è
tralasciato da entrambi gli enti. I due enti possono accor-
gersi di questa situazione se ricevono il messaggio
dell'altro ente prima di aver ricevuto il riscontro.2000R2082 — IT — 15.06.2002 — 001.001 — 50
▼B
8.8.3.1.8. Non appena ricevuta l'accettazione i dati del messaggio CDN
diventano operativamente vincolanti per entrambi gli enti ATC.
Il personale ATC competente è informato delle condizioni di
trasferimento coordinate e del ricevimento dell'ACP.
8.8.3.2. Elaborazione nell'ente ricevente8.8.3.2.1. Se il sistema trova un piano di volo corrispondente e nel
messaggio non è presente alcuna discordanza che ne impedisca
la corretta elaborazione:
— il contenuto operativo è sottoposto alla posizione ATC
responsabile del coordinamento del volo;
e
— è inviato in risposta un messaggio SBY.
8.8.3.2.2. Se il tentativo di associazione del messaggio ad un piano di volo
non ha esito positivo o se è rilevata una discordanza che impe-
disce la corretta elaborazione del messaggio, non è inviato in
risposta alcun messaggio SBY.
8.8.4. Riscontro al CDN
8.8.4.1. Riscontro
In base alle condizioni precisate qui sopra, al messaggio CDN è
dato riscontro mediante la generazione e trasmissione di un
messaggio SBY.
8.8.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio SBY in riscontro
ad un messaggio CDN, sullo schermo della posizione ATC
responsabile del coordinamento del volo è visualizzato un avver-
timento.
8.8.5. Risposta operativa al CDN
Il controllore può accettare o rigettare le condizioni di trasferi-
mento proposte in un messaggio CDN.
8.8.5.1. Accettazione
Quando il controllore accettante decide di accettare le condizioni
di trasferimento proposte, è trasmesso in risposta un messaggio
ACP.
8.8.5.2. Raccomandazione Quando il controllore trasferente decide di
rigettare le condizioni di trasferimento proposte, è opportuno
che sia inviato un messaggio RJC (rigetto esplicito).
NOTAIl coordinamento proposto è implicitamente rigettato se
non si riceve un'accettazione prima della scadenza del
tempo massimo consentito per il messaggio CDN.
8.8.6. Esempi
8.8.6.1. ICAO
(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. Messaggiodirigetto dicoordinamento(RJC)
8.9.1. Scopo del messaggio RJC
Il messaggio RJC indica che il controllore di un ente rigetta le
condizioni di trasferimento proposte dal controllore dell'altro
ente in uno dei messaggi seguenti:
— RAP;
— RRV;— CDN;— ACT e REV, se risultano non standard.
Il messaggio RJC può essere usato solo in risposta diretta ad uno
dei messaggi sopra citati.2000R2082 — IT — 15.06.2002 — 001.001 — 51
▼B
8.9.2. Contenuto del messaggio
Il messaggio RJC contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— riferimento del messaggio.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
8.9.3. Regole di applicazione
8.9.3.1. Indicazioni generali8.9.3.1.1. Il messaggio RJC è inviato all'occorrenza in risposta ad un
messaggio RAP, RRV, CDN o ad un messaggio ACT o REV
risultato non standard all'esame dell'ente ricevente.
8.9.3.1.2. Il messaggio RJC pone fine al dialogo tra sistemi e qualsiasi
coordinamento concordato precedentemente rimane valido.
8.9.3.1.3. Raccomandazione Dopo il ricevimento di un messaggio RJC è
opportuno che sia avviata una nuova sequenza di coordinamento
che rispecchi il coordinamento telefonico, ove appropriato.
8.9.3.2. Elaborazione nell'ente ricevente8.9.3.2.1. Se il sistema trova un messaggio corrispondente al messaggio a
cui fa riferimento il messaggio RJC:
— il rigetto è indicato alla posizione ATC responsabile del coor-
dinamento del volo; e
— è inviato un LAM in riscontro.
8.9.3.2.2. Se il sistema non trova alcun messaggio con tali caratteristiche in
attesa di risposta o se riscontra nel messaggio una discordanza
che ne impedisca l'elaborazione, non è inviato alcun riscontro.
8.9.4. Riscontro all'RJC
8.9.4.1. Riscontro
Al messaggio RJC è dato riscontro mediante la generazione e
trasmissione di un messaggio LAM.
8.9.4.2. Casi di mancato riscontro
In assenza di un messaggio LAM che dia riscontro ad un
messaggio RJC, sullo schermo della posizione ATC responsabile
del coordinamento del volo è visualizzato un avvertimento.
8.9.5. Esempi
8.9.5.1. ICAO
(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. PROCEDURA DI DIALOGO — TRASFERIMENTO
DELLECOMUNICAZIONI
9.1. Indicazionigenerali
9.1.1. Introduzione
9.1.1.1. La presente sezione della norma descrive le procedure ed i
messaggi a supporto degli aspetti della procedura di trasferimento
del controllo relativi al trasferimento radar. Le disposizioni qui
indicate sono applicate previo accordo bilaterale.
9.1.1.2. Le procedure di trasferimento delle comunicazioni non sono
attuate a meno che l'ente non stia utilizzando le procedure di
coordinamento descritte nella sezione 6 (Procedura di base —
Messaggi obbligatori) o quelle descritte nella sezione 8 (Proce-
dura di dialogo — Coordinamento).
9.1.1.3. I messaggi descritti nella presente sezione sono disponibili unica-
mente in formato ADEXP e non si prevede di renderli disponibili
anche in formato ICAO.2000R2082 — IT — 15.06.2002 — 001.001 — 52
▼B
9.1.2. Sequenza di messaggi
9.1.2.1. Lo scambio di messaggi di trasferimento delle comunicazioni
fatta eccezione per il messaggio di dati supplementari (SDM),
avviene solo se il coordinamento è stato completato, vale a dire
se un messaggio LAM o ACP ha posto fine ad un dialogo ACT
o RAP.
9.1.2.2. Nessun riscontro è inviato fintantoché è in corso il coordina-
mento.
9.1.3. Trasferimento delle comunicazioni
9.1.3.1. Il metodo da utilizzare per indicare l'effettivo trasferimento delle
comunicazioni per un volo è concordato dai due enti competenti.
9.1.3.2. La procedura si attua al verificarsi di una delle condizioni
seguenti o di entrambe:
— l'ente trasferente invia un messaggio di cambio di frequenza
(COF);
— l'ente ricevente invia un messaggio di assunzione manuale
delle comunicazioni (MAS);
9.1.3.3. Il metodo da utilizzare è concordato dai due enti per ogni flusso
di traffico.
NOTAPer flussi diversi possono essere usati metodi alternativi,
ad esempio un ente può generare messaggi COF per i
voli che escono dal suo spazio aereo e messaggi MAS
per i voli che invece vi entrano. In questo caso l'altro
ente non avrebbe bisogno di generare e trasmettere alcun
messaggio per indicare il trasferimento delle comunica-
zioni.
9.2. Messaggiodiavviodeltrasferimento (TIM)
9.2.1. Scopo del messaggio TIM
Il messaggio TIM è utilizzato per:
— segnalare l'evento che dà avvio al trasferimento (TI) (fine
della fase di coordinamento ed inizio della fase di trasferi-
mento);
— trasmettere contemporaneamente i dati di controllo esecutivo
dall'ente trasferente all'ente accettante.
9.2.2. Contenuto del messaggio
Il messaggio TIM contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;— identificazione dell'aeromobile;
— Dati disponibili — il messaggio contiene anche i dati
seguenti, se sono disponibili:
— livello di volo autorizzato;
— prua assegnata o autorizzazione di rotta diretta;— velocità assegnata;— rateo di salita/discesa assegnato;
— Dati facoltativi — il messaggio può contenere anche:
— posizione.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.2.3. Regole di applicazione
9.2.3.1. Indicazioni generali9.2.3.1.1. Il messaggio TIM è generato e trasmesso dall'ente trasferente
all'ente accettante senza intervento umano ad una distanza o un
lasso di tempo rispetto al confine concordati bilateralmente.
9.2.3.1.2. Un messaggio TIM è inviato automaticamente anche quando
l'ente trasferente riceve un messaggio di richiesta di cambio di
frequenza (ROF).
9.2.3.1.3. L'invio del messaggio TIM è possibile solo dopo che il volo è
stato coordinato.2000R2082 — IT — 15.06.2002 — 001.001 — 53
▼B
9.2.3.1.4. Il messaggio TIM contiene i dati più recenti disponibili nel
sistema.
9.2.3.2. Parametri temporali per la trasmissione
9.2.3.2.1. Il parametro di generazione del TIM è un parametro variabile di
sistema che può essere modificato in base alle disposizioni delle
LoA.
9.2.3.2.2. Raccomandazione È opportuno che il parametro di sistema di
generazione del TIM sia definito separatamente per ogni COP.
9.2.3.2.3. Gli interlocutori del coordinamento includono i parametri di
generazione del TIM nella loro LoA.
9.2.3.2.4. Il parametro di sistema che determina l'attivazione del messaggio
TIM può essere legato alla velocità calcolata dell'aeromobile
rispetto al suolo. Tuttavia, l'attivazione di un messaggio TIM
inizia sempre prima che l'aeromobile, secondo il piano di volo
in vigore, sia ad una distanza dal COP inferiore ad una distanza
minima concordata bilateralmente.
9.2.3.2.5. Il parametro di sistema specificato per la trasmissione del TIM
lascia sufficiente tempo per un coordinamento verbale prima del
trasferimento.
9.2.3.3. Elaborazione nell'ente ricevente
9.2.3.3.1. I dati ricevuti in un TIM sono comunicati al controllore accet-
tante.
9.2.4. Riscontro al TIM
9.2.4.1. Riscontro
Se il messaggio TIM:
— è associabile senza ambiguità ad un piano di volo, ne è dato
riscontro mediante la generazione e trasmissione di un
messaggio LAM;
— non è associabile senza ambiguità ad un piano di volo non è
inviato alcun riscontro.
9.2.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio TIM, sullo schermo della posizione di
lavoro ATC competente è visualizzato un avvertimento.
9.2.5. Esempio
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM253
9.3. Messaggiodidatisupplementari(SDM)
9.3.1. Scopo del messaggio SDM
9.3.1.1. Indicazioni generali9.3.1.1.1. Lo scopo principale del messaggio SDM è la trasmissione dei dati
di controllo e delle relative variazioni dall'ente trasferente all'ente
accettante, purché sia stato concordato bilateralmente che il
controllore accettante non ha l'obbligo di dare riscontro alle varia-
zioni.
9.3.1.1.2. Il messaggio SDM può anche essere utilizzato dall'ente accettante
per notificare all'ente trasferente la frequenza radiotelefonica su
cui deve essere trasferito il volo.
9.3.2. Contenuto del messaggio
9.3.2.1. Messaggi inviati dall'ente trasferente
Il messaggio SDM contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;
— identificazione dell'aeromobile;
— Dati supplementari — il messaggio contiene anche uno o più
dati tra quelli indicati qui di seguito:
— prua assegnata o autorizzazione di rotta diretta;2000R2082 — IT — 15.06.2002 — 001.001 — 54
▼B
— velocità assegnata;
— rateo di salita/discesa assegnato;
— livello di volo autorizzato.
9.3.2.2. Messaggi inviati dall'ente accettante
Il messaggio SDM contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;— identificazione dell'aeromobile;
— frequenza.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.3.3. Regole di applicazione
9.3.3.1. Messaggi inviati dall'ente trasferente
9.3.3.1.1. I messaggi SDM sono trasmessi dopo l'avvio della fase di trasfe-
rimento (cfr. TIM, punto 9.2) in seguito a qualsiasi variazione di
uno dei seguenti elementi:
— livello di volo autorizzato;
— velocità assegnata;
— rateo di salita/discesa assegnato;
— prua assegnata; o— emissione o modifica di un'autorizzazione che permetta al
volo di procedere direttamente verso un punto specificato.
NOTASe prima del trasferimento delle comunicazioni è neces-
saria l'approvazione del controllore accettante si usa il
messaggio HOP.
9.3.3.1.2. Il messaggio contiene unicamente i campi che sono stati modifi-
cati.
9.3.3.1.3. Se concordato bilateralmente, i messaggi SDM contenenti i dati
indicati nel punto 9.3.3.1.1 sono trasmessi prima del TI.
9.3.3.1.4. La trasmissione di questi messaggi inizia in un momento concor-
dato bilateralmente rispetto al TI, purché si tratti di dati per i
quali nel sistema esiste un valore.
9.3.3.2. Messaggi inviati dall'ente accettante
9.3.3.2.1. I messaggi SDM possono essere trasmessi per indicare la
frequenza sulla quale il volo deve contattare l'ente accettante.
NOTAGli enti possono stabilire di comune accordo di inviare
altre informazioni. Questi trasferimenti non sono definiti
in questa norma, e quindi non rientrano nel suo campo
d'applicazione.
9.3.3.2.2. I messaggi SDM dell'ente accettante sono trasmessi durante la
fase di coordinamento, se concordato bilateralmente.
9.3.3.3. Elaborazione nell'ente ricevente
9.3.3.3.1. Il sistema ATC che riceve un messaggio SDM cerca di associarlo
ai dati del piano di volo corrispondente.
9.3.3.3.2. Se è individuato un piano di volo corrispondente nello status
«coordinato»:
— è inviato un LAM in risposta; e
— il contenuto operativo del messaggio SDM è presentato al
controllore competente.
9.3.3.3.3. Se il tentativo di associazione al piano di volo non ha esito posi-
tivo o se è rilevata una discordanza che impedisca la corretta
elaborazione del messaggio:
— non è inviato alcun LAM in risposta; e
— sullo schermo delle posizione di lavoro competente è presen-
tato un avvertimento.
9.3.4. Riscontro all'SDM
9.3.4.1. Riscontro
Al messaggio SDM è dato riscontro mediante la generazione e
trasmissione di un messaggio LAM.2000R2082 — IT — 15.06.2002 — 001.001 — 55
▼B
9.3.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio SDM, sullo schermo della posizione
competente è visualizzato un avvertimento.
9.3.5. Esempio
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4. Propostaditrasferimento(HOP)
9.4.1. Scopo del messaggio HOP
Lo scopo del messaggio HOP è:
— permettere al controllore trasferente di attirare l'attenzione del
controllore accettante su un volo specifico allo scopo di
trasferirne il controllo;
— permettere al controllore trasferente di proporre il trasferi-
mento del volo al controllore accettante al momento
opportuno;
— trasmettere modifiche dei dati di controllo esecutivo che
necessitano dell'approvazione del controllore accettante,
secondo quanto concordato bilateralmente.
Non è necessario utilizzare il messaggio HOP per tutti i voli;
l'uso di questo messaggio è lasciato alla discrezione del control-
lore trasferente.
NOTAIn relazione al punto c) precedente, per trasmettere modi-
fiche dei dati di controllo esecutivo che non richiedono
l'approvazione del controllore accettante si usa il
messaggio SDM.
9.4.2. Contenuto del messaggio
Il messaggio HOP contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;— identificazione dell'aeromobile;
— Dati disponibili — il messaggio contiene anche i dati
seguenti, se sono disponibili:
— livello di volo autorizzato;
— prua assegnata/autorizzazione di rotta diretta;
— velocità assegnata;
— rateo di salita/discesa assegnato;
— Dati facoltativi — il messaggio può contenere anche:
— posizione.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.4.3. Regole di applicazione
9.4.3.1. Indicazioni generali9.4.3.1.1. Il messaggio HOP, quando è usato, è attivato manualmente dal
controllore trasferente.
9.4.3.1.2. Il messaggio contiene i dati di volo descritti nel punto 9.4.2
precedente che sono stati modificati rispetto ai dati trasmessi
precedentemente.
9.4.3.1.3. Se un messaggio HOP è inviato prima del TI si avvia la fase di
trasferimento.
NOTANon è necessario un messaggio di avvio del trasferimento
(TIM) in aggiunta al messaggio HOP.
9.4.3.1.4. I due enti concordano bilateralmente il momento o la distanza
prima del COP o del confine a partire dal quale può essere
inviato un messaggio HOP.
9.4.3.1.5. Raccomandazione È opportuno precisare separatamente il
momento/la distanza per ogni COP.2000R2082 — IT — 15.06.2002 — 001.001 — 56
▼B
9.4.3.2. Elaborazione nell'ente ricevente
9.4.3.2.1. Il sistema ATC che riceve un messaggio HOP cerca di associarlo
ai dati del piano di volo corrispondente.
9.4.3.2.2. I dati di volo ricevuti nel messaggio sono visualizzati immediata-
mente sullo schermo del controllore accettante.
9.4.3.2.3. Se il controllore accettante accetta il volo secondo le condizioni
proposte nel messaggio HOP, può essere inviato un ROF in
risposta all'ente trasferente. Previo accordo bilaterale, in risposta
ad un messaggio HOP può essere inviato un ACP.
9.4.3.2.4. Se il controllore accettante non è in grado di accettare il volo, il
trasferimento è concordato verbalmente.
NOTAIn considerazione del carattere di urgenza della proce-
dura di trasferimento, la presente norma non impone un
controllo automatizzato dell'invio di un ROF (o di un
ACP) in risposta all'HOP; si suppone che il controllore
trasferente sia consapevole della mancata risposta del
controllore accettante ed attui le misure necessarie. La
presente norma, tuttavia, non impedisce che venga
presentato un avvertimento al controllore trasferente se
ciò è ritenuto necessario dal punto di vista operativo.
9.4.3.2.5. Non appena ricevuto un ROF (o un ACP), i dati del messaggio
HOP diventano operativamente vincolanti per entrambi gli enti
ATC.
9.4.4. Riscontro all'HOP
9.4.4.1. Riscontro
Se il messaggio HOP è associabile ad un piano di volo, ne è dato
riscontro automaticamente tramite un LAM.
9.4.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio HOP, sullo schermo della posizione
di lavoro competente è visualizzato un avvertimento.
9.4.5. Esempio
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ
9.5. Messaggiodirichiesta dicambiodifrequenza(ROF)
9.5.1. Scopo del messaggio ROF
Il ROF è inviato all'occorrenza dall'ente accettante all'ente trasfe-
rente per chiedere al controllore trasferente di invitare
l'aeromobile a passare sulla frequenza del controllore accettante.
Il messaggio può essere usato:
— in risposta ad un HOP per indicare l'accettazione del volo alle
condizioni proposte;
— per chiedere il trasferimento anticipato del volo.
9.5.2. Contenuto del messaggio
Il messaggio ROF contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;
— identificazione dell'aeromobile;
— Dati facoltativi — il messaggio può contenere anche:
— frequenza.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.5.3. Regole di applicazione
9.5.3.1. Indicazioni generali9.5.3.1.1. Il messaggio ROF è attivato manualmente dal controllore accet-
tante.2000R2082 — IT — 15.06.2002 — 001.001 — 57
▼B
9.5.3.1.2. Il controllore accettante può attivare un ROF:
— quando il controllore accettante chiede il passaggio anticipato
dell'aeromobile sulla sua frequenza;
— in risposta ad un messaggio HOP.
9.5.3.2. Elaborazione nell'ente ricevente
9.5.3.2.1. Il sistema ATC che riceve un messaggio ROF cerca di associarlo
al piano di volo corrispondente.
9.5.3.2.2. Il ricevimento del ROF è segnalato immediatamente al control-
lore trasferente.
9.5.3.2.3. Se il volo non è nella fase di trasferimento si avvia la fase di
trasferimento ed è trasmesso un messaggio TIM.
9.5.4. Riscontro al ROF
9.5.4.1. Riscontro9.5.4.1.1. Se il messaggio ROF è associabile senza ambiguità ad un piano
di volo, ne è dato riscontro tramite la generazione e trasmissione
di un messaggio LAM.
9.5.4.1.2. Se il messaggio ROF non è associabile senza ambiguità ad un
piano di volo non è inviato alcun riscontro.
9.5.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio ROF, sullo schermo della posizione
ATC competente è visualizzato un avvertimento.
9.5.5. Esempio
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6. Messaggiodicambiodifrequenza(COF)
9.6.1. Scopo del messaggio COF
9.6.1.1. Indicazioni generali9.6.1.1.1. Il COF è inviato dall'ente trasferente all'ente accettante per indi-
care che il volo è stato invitato a contattare il controllore
accettante.
9.6.1.1.2. Il messaggio può prevedere la possibilità per il controllore trasfe-
rente di rilasciare il volo alle condizioni di trasferimento
concordate una volta stabilita la comunicazione radio con il
controllore accettante.
9.6.2. Contenuto del messaggio
Il messaggio COF contiene i dati seguenti:
— Dati obbligatori — il messaggio contiene:
— tipo di messaggio;
— numero del messaggio;— identificazione dell'aeromobile;
— Dati disponibili — il messaggio contiene anche i dati
seguenti, se sono disponibili:
— indicazione di rilascio;
— frequenza;— livello di volo autorizzato;— prua assegnata o autorizzazione di rotta diretta;— velocità assegnata;— rateo di salita/discesa assegnato;
— Dati facoltativi — il messaggio può contenere anche:
— posizione.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.6.3. Regole di applicazione
9.6.3.1. Indicazioni generali9.6.3.1.1. Il messaggio COF è attivato manualmente dal controllore trasfe-
rente.2000R2082 — IT — 15.06.2002 — 001.001 — 58
▼B
9.6.3.1.2. L'uso del messaggio COF è obbligatorio se, per accordo bilate-
rale, non è usato il messaggio MAS.
9.6.3.1.3. Se un messaggio COF è inviato prima del TI si avvia la fase di
trasferimento.
NOTANon è necessario un messaggio di avvio del trasferimento
(TIM) in aggiunta al COF.
9.6.3.2. Elaborazione nell'ente ricevente
9.6.3.2.1. Il sistema ATC che riceve un messaggio COF cerca di associarlo
ai dati del piano di volo corrispondente.
9.6.3.2.2. Il ricevimento del COF è segnalato immediatamente al control-
lore accettante.
9.6.4. Riscontro al COF
9.6.4.1. Riscontro
9.6.4.1.1. Se il messaggio COF è associabile senza ambiguità ad un piano
di volo, ne è dato riscontro tramite la generazione e trasmissione
di un messaggio LAM.
9.6.4.1.2. Se il messaggio COF non è associabile senza ambiguità ad un
piano di volo non è inviato alcun riscontro
9.6.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio COF, sullo schermo della posizione
ATC competente è visualizzato un avvertimento.
9.6.5. Esempi
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7. Messaggiodiassunzionemanualedellecomunicazioni(MAS)
9.7.1. Scopo del messaggio MAS
Il MAS è inviato dall'ente accettante all'ente trasferente per indi-
care che è stato stabilito il contatto radio bidirezionale con il
volo.
9.7.2. Contenuto del messaggio
Il messaggio MAS contiene i dati seguenti:
— tipo di messaggio;
— numero del messaggio;
— identificazione dell'aeromobile.
NOTALe regole di inserimento dei dati, i formati ed il conte-
nuto dei campi sono specificati nell'allegato A.
9.7.3. Regole di applicazione
9.7.3.1. Indicazioni generali9.7.3.1.1. Il messaggio MAS è attivato manualmente dal controllore accet-
tante.
9.7.3.1.2. L'uso del messaggio MAS è obbligatorio se, per accordo bilate-
rale, non è utilizzato il messaggio COF.
9.7.3.2. Elaborazione nell'ente ricevente9.7.3.2.1. Il sistema ATC che riceve un messaggio MAS cerca di associarlo
ai dati del piano di volo corrispondente.
9.7.3.2.2. Il ricevimento del MAS è segnalato immediatamente al control-
lore.
9.7.4. Riscontro al MAS
9.7.4.1. Riscontro
9.7.4.1.1. Se il messaggio MAS è associabile senza ambiguità ad un piano
di volo, ne è dato riscontro tramite la generazione e trasmissione
di un messaggio LAM.
9.7.4.1.2. Se il messaggio MAS non è associabile senza ambiguità ad un
piano di volo, non è inviato alcun riscontro.2000R2082 — IT — 15.06.2002 — 001.001 — 59
▼B
9.7.4.2. Casi di mancato riscontro
In caso di mancato ricevimento di un messaggio LAM in
riscontro ad un messaggio MAS, sullo schermo della posizione
ATC competente è visualizzato un avvertimento.
9.7.5. Esempio
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — IT — 15.06.2002 — 001.001 — 60
▼B
ALLEGATO A (Normativo)
REGOLEDIINSERIMENTODEIDATI
INDICE
A.1. Scopo
A.2. Formati generici dei messaggiA.3. Tipo di messaggio
A.4. Numero del messaggio
A.5. Riferimento del messaggioA.6. Identificazione dell'aeromobile
A.7. Modo e codice SSR
A.8. Aerodromo di partenzaA.9. Dati stimati
A.10. Punto di coordinamento
A.11. Aerodromo di destinazioneA.12. Numero e tipo degli aeromobili
A.13. Rotta
A.14. Altri dati del piano di voloA.15. Status di coordinamento e motivo
A.16. Prua assegnata (solo ADEXP)
A.17. Velocità assegnata (solo ADEXP)A.18. Rateo di salita/discesa assegnato (solo ADEXP)
A.19. Autorizzazione di rotta diretta (solo ADEXP)
A.20. Richiesta di rotta direttaA.21. Posizione (solo ADEXP)
A.22. Indicazione di rilascio (solo ADEXP)
A.23. FrequenzaA.24. Motivo (solo ADEXP)
A.25. Livello di volo autorizzato (solo ADEXP)
A.26. Livello di volo di trasferimento (solo ADEXP)A.27. Orario stimato di decollo
A.28. Tipo del messaggio di riferimento
A.29. Tipo di volo
A.30. Capacità e stato delle apparecchiature
A.1.Scopo
Il presente allegato descrive le regole generali per l'inserimento dei
dati nei messaggi definiti nella presente norma. Queste regole si
applicano a tutti i messaggi tranne quando nelle regole di applica-
zione per un messaggio specifico sono indicate espressamente
eccezioni o disposizioni diverse.
A.2.Formati generici deimessaggi
A.2.1. Tutti i messaggi descritti nelle sezioni seguenti possono essere
trasmessi utilizzando il formato ICAO:
6 Procedura di base — Messaggi obbligatori;
7 Procedura di base — Messaggi complementari;
8 Procedura di dialogo — Coordinamento.2000R2082 — IT — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
A.2.2. I formati dei campi dei messaggi sono definiti dall'ICAO nel Docu-
ment 4444 — Procedures for Air Navigation Services — Rules of
the Air and Air Traffic Control. Nei messaggi in cui sono presenti,
i tipi di campo ICAO indicati qui di seguito sono trasmessi prima di
qualsiasi altro tipo di campo nell'ordine seguente: 3, 7, 13, 14, e 16.
Dal momento che sono nel formato di tipo di campo 22, gli altri tipi
di campo ICAO possono essere trasmessi in qualsiasi ordine, purché
non precedano i tipi di campo indicati qui sopra.
A.2.2.a In alcuni casi, in assenza di un tipo di campo ICAO appropriato, è
impiegato un «finto» tipo di campo ICAO. Il valore impiegato in tal
caso è un numero di due cifre, pari o superiore ad 80.
A.2.3. Tutti i messaggi descritti nel presente documento possono essere
trasmessi usando il formato ADEXP di Eurocontrol. Il contenuto,
la struttura e l'uso dei campi di dati ADEXP devono essere conformi
al documento di cui al riferimento 2.
NOTE1.Solo i campi dati primari ADEXP sono elencati nel presente
allegato, eccetto quando i sottocampi ad essi associati richie-
dono osservazioni particolari. La norma ADEXP elenca tutti i
sottocampi obbligatori e facoltativi necessari in ogni campo
primario.
2.I messaggi descritti nella sezione 9, Procedura di dialogo —
Trasferimento delle comunicazioni, sono descritti solo in formato
ADEXP.
A.3.Tipodimessaggio
Il tipo di messaggio è l'abbreviazione del messaggio, così come
indicata nell'elenco seguente:
ABI: preavviso di attraversamento di confine.
ACP: accettazione.
ACT: attivazione.
CDN: coordinamento.
COD: assegnazione di codice SSR.
COF: cambio di frequenza.
HOP: proposta di trasferimento.
INF: informazione.
LAM: messaggio di riscontro logico.
MAC: messaggio di abrogazione del coordinamento.
MAS: assunzione manuale delle comunicazioni.
PAC: attivazione preliminare.
RAP: proposta di attivazione sottoposta per accettazione.
REV: revisione.
RJC: rigetto di coordinamento.
ROF: richiesta di cambio di frequenza.
RRV: proposta di revisione sottoposta per accettazione.
SBY: attesa.
SDM: messaggio di dati supplementari.
TIM: messaggio di avvio del trasferimento.
A.3.1. ICAO
Tipo di campo 3, elemento (a).
A.3.2. ADEXP
Campo primario «title».
A.4.Numerodelmessaggio
Il numero del messaggio comprende gli identificatori assegnati agli
enti trasmittente e ricevente ed il numero progressivo del
messaggio. Quest'ultimo va da 001 a 000 (che corrisponde 1000),2000R2082 — IT — 15.06.2002 — 001.001 — 62
▼M1
▼B
▼B
quindi riprende da 001 per tutti i messaggi inviati ad uno stesso
destinatario, indipendentemente dal tipo di messaggio.
A.4.1. ICAO
Tipo di campo 3, elemento (b).
A.4.2. ADEXP
Campo primario «refdata».
Il sottocampo «fac», all'interno dei sottocampi «sender» e «recvr»,
contiene gli identificatori assegnati agli enti ATC. La lunghezza di
questi identificatori non deve essere superiore a otto caratteri.
Il sottocampo «seqnum» contiene il numero progressivo.
A.5.Riferimentodelmessaggio
A.5.1. ICAO
Tipo di campo 3, elemento (c) (chiamato ‘reference data' (dati di
riferimento) nel documento ICAO 4444).
Il contenuto dell'elemento (c) è quello del tipo di campo 3, elemento
(b), del messaggio OLDI a cui si fa riferimento.
A.5.2. ADEXP
Campo primario «msgref».I valori dei sottocampi «sender», «recvr» e «seqnum», all'interno del
campo primario «msgref», sono quelli degli stessi sottocampi all'in-
terno del campo primario «refdata» del messaggio OLDI a cui si fa
riferimento.
A.6.Identificazionedell'aeromobile
A.6.1. ICAO
Tipo di campo 7, elemento (a).
A.6.2. ADEXP
Campo primario «arcid».
A.7.ModoecodiceSSR
1. Se è noto, il modo/codice SSR su cui l'ente ricevente può aspet-
tarsi una risposta dell'aeromobile al punto di trasferimento del
controllo;
oppure
2. Indicazione che segnali la richiesta di un codice SSR all'ente
ricevente.
A.7.1. ICAO
Tipo di campo 7, elementi (b) e (c).Se non è assegnato un codice SSR o se il modo/codice non è noto
gli elementi (b) e (c) sono omessi.
Quando si richiede un codice/modo SSR, gli elementi b) e c)
contengono il valore «A9999».
A.7.2. ADEXP
Campo primario «ssrcode».Se non è assegnato un codice SSR valido o se il modo/codice non è
noto il campo è omesso.
Quando si richiede un codice/modo SSR attraverso il messaggio
PAC il campo primario «ssrcode» contiene l'indicatore «REQ».2000R2082 — IT — 15.06.2002 — 001.001 — 63
▼B
A.8.Aerodromodipartenza
A.8.1. ICAO
Tipo di campo 13, elemento (a).
A.8.2. ADEXP
Campo primario «adep».
A.9.Datistimati
A.9.1. Indicazioni generali
A.9.1.1. I dati stimati comprendono il COP, l'orario sul COP e la quota di
trasferimento.
A.9.1.2. Il punto di coordinamento corrisponde ad un punto di riferimento
noto, oppure ad una distanza e un rilevamento rispetto ad un punto
di riferimento noto, oppure ad una latitudine e longitudine.
A.9.1.3. La quota (di trasferimento) autorizzata corrisponde alle condizioni
di trasferimento proposte.
A.9.1.4.Raccomandazione Per i voli in salita o in discesa è opportuno che
i dati stimati contengano anche dati di attraversamento supplemen-
tari e le condizioni di attraversamento.
A.9.1.5. I dati di attraversamento supplementari, se sono utilizzati, compren-
dono anche la quota di attraversamento supplementare al punto di
trasferimento del controllo. Le condizioni di attraversamento sono
indicate come segue:
— Lettera «A»; — se il volo sarà alla quota o sopra la quota indi-
cata nei dati di attraversamento supplementari; oppure
— Lettera «B»; — se il volo sarà alla quota o sotto la quota indi-
cata nei dati di attraversamento supplementari.
A.9.2. ICAO
Tipo di campo 14.
A.9.3. ADEXP
Campo primario «coordata».Il sottocampo «ptid» all'interno del campo primario «coordata»
contiene:
— un punto di riferimento noto; oppure
— un rilevamento e una distanza rispetto ad un punto di riferimento
noto, così come definito nel campo primario «REF» o «GEO»
dello stesso messaggio.
A.10.Puntodicoordinamento
A.10.1. Indicazioni generali
A.10.1.1. Il punto di coordinamento a cui fanno riferimento gli enti ATC
trasferente e ricevente ai fini del trasferimento in questione.
A.10.1.2. Il punto di coordinamento corrisponde ad un punto di riferimento
noto, oppure ad una distanza e un rilevamento rispetto ad un punto
di riferimento noto, oppure ad una latitudine e longitudine.
A.10.2. ICAO
Campo 14, elemento (a).
A.10.3. ADEXP
Campo primario «cop» contenente:
— un punto di riferimento noto; oppure
— un rilevamento e una distanza rispetto ad un punto di riferimento
noto, così come definito nel campo primario «REF» o «GEO»
dello stesso messaggio.2000R2082 — IT — 15.06.2002 — 001.001 — 64
▼B
A.11.Aerodromodidestinazione
A.11.1. ICAO
Campo 16, elemento (a).
A.11.2. ADEXP
Campo primario «ades».
A.12.Numeroetipodegliaeromobili
Questo campo contiene il tipo di aeromobile e nel caso di voli in
formazione anche il numero degli aeromobili.
A.12.1. ICAO
Tipo di campo 9 nel formato del tipo di campo 22. L'elemento c del
tipo di campo 9 contiene la categoria di turbolenza di scia corri-
spondente al tipo di aeromobile oppure la lettera «Z».
A.12.2. ADEXP
Campo primario «arctyp». Se ci sono più aeromobili, aggiungere il
campo primario «nbarc».
A.13.Rotta
Entrambi i formati consentono la descrizione della rotta così come
definita per i messaggi ICAO, in cui il primo elemento deve essere
costituito da velocità, livello di volo richiesta o altitudine. Dopo il
gruppo della velocità, i dati relativi alla rotta comprendono almeno
i dati specificati nel punto seguente. Ulteriori dati eventualmente
disponibili possono essere inseriti dopo l'elemento c). Vedere anche
le regole di inserimento dei dati relativi alla rotta nell'allegato B,
Prescrizioni relative all'elaborazione di rotte particolari.
A.13.1. Contenuto
A.13.1.1. Voli che passano per un COP definito
— il tratto di rotta prima del COP (rotta ATS, identificatore SID,
DCT o punto significativo);
— il COP;
— il tratto di rotta dopo il COP (rotta ATS o punto significativo).
A.13.1.2. Voli al di fuori di rotte ATS
— il punto a partire dal quale il volo procede lungo il segmento di
rotta diretta;
— l'elemento «DCT»;
— il punto verso il quale il volo procede lungo il segmento di rotta
diretta.
A.13.2. Formato
A.13.2.1. ICAO
Tipo di campo 15, nel formato del tipo di campo 22.
A.13.2.2. ADEXP
Campo primario «route».
A.14. Il presente campo permette di inserire in specifici messaggi dati del
piano di volo che non sono in genere inseriti nel corso della proce-
dura di coordinamento e che non figurano in nessun altro punto del
presente allegato. È consentito l'inserimento dei seguenti elementi,
come indicato nel riferimento 1, allegato 2, tipi di campo 8 e 18:
— regole del volo,
— marche di immatricolazione,
— nome dell'operatore,— motivo del trattamento particolare da parte dell'ATS,2000R2082 — IT — 15.06.2002 — 001.001 — 65
▼M1
▼M1
— tipo,
— prestazioni,
— nome dell'aerodromo di partenza, di destinazione e alternato,
— osservazioni in chiaro.
A.14.1. ICAO
Tipo di campo 8, elemento a) Regole del volo nel formato del tipo
di campo 22.
Uno o più dei seguenti elementi del tipo di campo 18 nel formato
del tipo di campo 22.
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Campi primari: «fltrul», «depz», «destz», «opr», «per», «reg»,
«rmk», «altrnt1», «altrnt2», «sts», e «typz».
A.15.Statusdicoordinamentoemotivo
Lo status di coordinamento ed il motivo comprendono gli elementi
seguenti:
— un indicatore di tre lettere, scelto tra quelli indicati qui di
seguito, che conferma il nuovo status del piano di volo nel
sistema:
— INI, quando il piano di volo nel sistema è nello status
iniziale, cioè non è stato ricevuto alcun messaggio di noti-
fica;
— NTF, quando il piano di volo nel sistema è nello status
«notificato»;
— CRD, quando il piano di volo nel sistema è nello status
«coordinato», cioè l'ACT di base è stato ricevuto o il dialogo
di coordinamento iniziale è stato completato e le condizioni
sono state concordate.
— un indicatore di tre lettere, scelto tra quelli indicati qui di
seguito, che precisa il motivo dello status:
— TFL, se il motivo è un cambiamento della quota di trasferi-
mento;
— RTE, se il motivo è un cambiamento di rotta;— HLD, per indicare che il volo è in attesa per un periodo
indeterminato e che sarà oggetto di un ulteriore messaggio;
— DLY, per indicare che la partenza è ritardata;— CAN, se il motivo è una cancellazione;— CSN, per un cambiamento dell'indicativo di chiamata;— OTH, per qualsiasi altro motivo o se il motivo è sconosciuto.
A.15.1. ICAO
A.15.1.1. Lo status di coordinamento e il motivo sono indicati nel formato del
tipo di campo 18.
A.15.1.2. Lo status di coordinamento e il motivo includono gli elementi
seguenti, presentati come gruppo di dieci caratteri:
— STA seguito da una barra obliqua;
— l'indicatore che conferma il nuovo status della notifica/coordina-
mento;
— l'indicatore che specifica il motivo.
A.15.2. ADEXP
Campo primario «cstat».Gli elementi ausiliari «coordstatusident» e «coordstatusreason»
contengono il nuovo status ed il motivo conformemente a quanto
indicato qui sopra.
A.16.Pruaassegnata (solo ADEXP)
Il campo primario «ahead» contiene:
— la prua assegnata ad un volo, espressa in gradi;2000R2082 — IT — 15.06.2002 — 001.001 — 66
▼B
▼B
oppure
— se non è assegnata una prua, l'indicatore «ZZZ», ad esempio
quando si usa un messaggio SDM per indicare che una prua
assegnata in precedenza non è più valida.
A.17.Velocità assegnata (solo ADEXP)
Il campo primario «aspeed» contiene:
— la velocità assegnata ad un volo, espressa in nodi, numero di
Mach o km/ora;
oppure
— se non è assegnata una velocità, l'indicatore «ZZZ», ad esempio
quando si usa un messaggio SDM per indicare che una velocità
assegnata in precedenza non è più valida.
A.18.Rateodisalita/discesaassegnato (solo ADEXP)
Il campo primario «rate» contiene:
— il rateo di salita o discesa assegnato ad un volo, espresso in
centinaia di piedi al minuto;
oppure
— se non è assegnato un rateo di salita/discesa, l'indicatore «ZZZ»
nella parte numerica del campo, ad esempio quando si usa un
messaggio SDM per indicare che un rateo di salita/discesa asse-
gnato in precedenza non è più valido.
A.19.Autorizzazione dirottadiretta (solo ADEXP)
Rotta diretta, non definita come una rotta ATS, tra due punti. I punti
possono essere costituiti da punti di riferimento noti, oppure essere
espressi mediante l'indicazione di una distanza ed un rilevamento
rispetto ad un punto di riferimento. Tutti gli indicatori di punti
terminali utilizzati sono concordati bilateralmente, cioè sono noti
ad entrambi i sistemi.
Campo primario «DCT» contenente:
— il punto in cui ha avuto o avrà inizio l'allontanamento, definito
nel modo seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto, definito nello stesso messaggio nel campo primario
«REF»;
oppure
— valore «ZZZ» se l'ente mittente non richiede la designazione
del punto di allontanamento.
— il punto situato sulla rotta originaria del piano di volo fino a cui
l'aeromobile è stato o sarà autorizzato, definito nel modo
seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto, definito nello stesso messaggio dal campo primario
«REF».
A.20.Richiestadirottadiretta
Richiesta di rotta diretta, non definita come rotta ATS, tra due punti.
I punti possono essere costituiti da punti di riferimento noti, oppure
essere espressi mediante l'indicazione di una distanza ed un rileva-
mento rispetto ad un punto di riferimento.
Tutti gli indicatori di punti terminali utilizzati sono concordati bila-
teralmente, cioè sono noti ad entrambi i sistemi.
A.20.1. ICAO
Tipo di campo 15, tranne il gruppo velocità/quota iniziale, nel
formato del campo 22.2000R2082 — IT — 15.06.2002 — 001.001 — 67
▼B
Contiene:
— il punto in cui si richiede che inizi l'allontanamento, definito nel
modo seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto;
oppure
— valore «ZZZ» se l'ente ATC ricevente richiede una rotta
diretta.
— l'abbreviazione «DCT»,
— seguita dal punto situato sulla rotta originaria del piano di volo
fino a cui si richiede che l'aeromobile sia autorizzato, definito
nel modo seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto.
A.20.2. ADEXP
Campo primario «DCT» contenente:
— il punto in cui si richiede che abbia inizio l'allontanamento, defi-
nito nel modo seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto definito nello stesso messaggio nel campo primario
«REF»;
oppure
— valore «ZZZ» se l'ente ATC ricevente richiede una rotta
diretta ma il punto preciso d'inizio non è noto.
— il punto situato sulla rotta originaria del piano di volo fino a cui
è richiesta l'autorizzazione dell'aeromobile, definito nel modo
seguente:
— punto di riferimento noto;
oppure
— distanza e rilevamento rispetto ad un punto di riferimento
noto definito nello stesso messaggio nel campo primario
«REF».
A.21.Posizione (solo ADEXP)
A.21.1. Indicazioni generali
A.21.1.1. La posizione corrente del volo espressa in coordinate geografiche o
mediante un rilevamento e una distanza rispetto a un punto desi-
gnato.
A.21.1.2. Il campo primario «ref» o «geo» definisce la posizione orizzontale
corrente dell'aeromobile. I punti usati per indicare la distanza ed il
rilevamento nel campo primario «ref» sono concordati bilateral-
mente, cioè sono noti ad entrambi i sistemi. Il campo primario
«position» contiene il sottocampo «ptid» che si riferisce al punto di
riferimento o geografico definito. Se si devono includere informa-
zioni temporali si utilizza il sottocampo «to» (hhmm) o «sto»
(hhmmss), previo accordo bilaterale.
A.22.Indicazionedirilascio (solo ADEXP)
Il campo primario «release» contiene uno degli elementi seguenti:
— C, se il volo è rilasciato per la salita;
— D, se il volo è rilasciato per la discesa;
— T, se il volo è rilasciato per la virata;
— F, se il volo è rilasciato per tutte le manovre.2000R2082 — IT — 15.06.2002 — 001.001 — 68
▼B
A.23.Frequenza
A.23.1. ICAO
Il tipo di campo 18 contiene gli elementi seguenti nel formato del
campo 22:
— FRQ, seguito da una barra obliqua;
— 6 cifre che indicano la frequenza, espressa in MHz fino al terzo
decimale.
A.23.2. ADEXP
Campo primario «freq».
A.24.Motivo (solo ADEXP)
Campo primario «reason», contenente il valore «MANUAL» per i
messaggi sottoposti manualmente.
A.25.Livello divoloautorizzato (solo ADEXP)
Campo primario «cfl».
A.26.Livello divolopropostoperiltrasferimento (solo ADEXP)
Campo primario «propfl».
A.27.Orario stimatodidecollo
A.27.1. ICAO
Tipo di campo 13 elemento (b).
A.27.2. ADEXP
Campo primario «etot».
A.28.Tipodimessaggiodiriferimento
Il campo contiene il tipo di messaggio specificato nel punto A.1 del
presente allegato.
A.28.1. ICAO
Tipo di campo 18 nel formato del tipo di campo 22. L'indicatore di
elemento è «MSG».
A.28.2. ADEXP
Campo primario «msgtyp».
A.29.Tipodivolo
Va riportato quanto figura sul piano di volo, ovvero un dato equiva-
lente ricavato da una fonte alternativa. Va inserita la lettera «X» se
il tipo di volo non figura sul piano di volo o se, per un qualsiasi
motivo, il tipo di volo non è conosciuto.
A.29.1. ICAO
Il tipo di volo deve essere inserito per mezzo di un'unica lettera nel
formato del tipo di campo 22 utilizzando il «finto» tipo di campo
80.
A.29.2. ADEXP
Campo primario «flttyp».
A.30.Capacitàestatodelleapparecchiature
Il presente elemento indica capacità e stato delle apparecchiature
che risultano essere un prerequisito per poter volare in determinati
spazi aerei o lungo specifiche rotte, ovvero che influenzano notevol-
mente la fornitura dei servizi ATC. Pur essendo indicata nel piano
di volo, la presenza di determinate capacità potrebbe infatti risultare2000R2082 — IT — 15.06.2002 — 001.001 — 69
▼M1
▼M1
scorretta o essersi modificata nel corso del volo. Capacità e stato
delle apparecchiature indicano lo stato in quel momento.
Va inserito lo status dei seguenti elementi:
— capacità RVSM,
— equipaggiamento 8.33 kHzRTF
Lo status del seguente elemento va inserito nel piano di volo dei
voli di Stato, identificati come tali nel «tipo di volo», per i quali
non si sa se può essere impiegato un equipaggiamento 8.33 kHzRTF:
— equipaggiamento UHF.
A.30.1. ICAO
I dati devono essere inseriti nel formato del tipo di campo 22, utiliz-
zando il «finto» tipo di campo 81.
Per ogni capacità devono essere inseriti due elementi:
— la capacità delle apparecchiature espressa con un'unica lettera
come indicato nel tipo di campo 10 «Apparati» nel piano di
volo ICAO (cfr. allegato 3 del riferimento 1), subito seguita da:
— elemento separatore — barra (/), subito seguita da,— stato espresso con due lettere.
Lo stato va espresso utilizzando i seguenti indicatori, scelti a
seconda del tipo di volo:
a) EQ il volo è dotato di apparati che possono essere utilizzati
durante il volo;
b) NO il volo non è dotato di apparati o per un qualsiasi motivo
essi non possono essere utilizzati durante il volo;
c) UN la capacità non è conosciuta.
Il primo gruppo di capacità va inserito direttamente dopo la barra
che lo separa dal numero di campo. I gruppi seguenti vanno separati
con spazi o caratteri. L'ordine d'inserimento delle capacità delle
apparecchiature non è significativo.
A.30.2. ADEXP
Campo primario «EQCST».2000R2082 — IT — 15.06.2002 — 001.001 — 70
▼B
ALLEGATO B (Normativo)
PRESCRIZIONI RELATIVE ALL'ELABORAZIONE DI ROTTE PARTI-
COLARI
B.1.Introduzione
B.1.1. Indicazioni generali
B.1.1.1. Il presente allegato descrive le regole e le prescrizioni relative
all'inserimento dei dati nei casi seguenti, quando essi sono consen-
titi:
— un volo segue una traiettoria diretta, fuori dalla rotta, e attra-
versa il confine per effetto di un segmento di rotta diretta
inserito nel piano di volo;
— dopo la trasmissione del messaggio ABI o ACT, un volo è rein-
stradato via:
— una rotta ATS diversa; oppure
— una traiettoria diretta per ricongiungersi alla rotta originaria
in un punto successivo
B.1.1.2. Per quanto riguarda il reinstradamento dei voli (punto B.1.1.1), lo
scambio di dati descritto nel presente allegato consente la modifica
della rotta di volo nei due sistemi mediante l'uso di messaggi di
notifica e di coordinamento.
B.2.Applicazionedeimessaggi
B.2.1. Regole di base applicabili agli instradamenti diretti
B.2.1.1. Le condizioni per l'uso dell'OLDI per il coordinamento dei voli nel
caso di instradamenti diretti sono concordate bilateralmente.
B.2.1.2. I dati richiesti per la notifica ed il coordinamento dei voli nel caso
di instradamenti diretti sono contenuti nel punto di coordinamento
(dati stimati (formato ICAO), nei dati di coordinamento (formato
ADEXP)) e nella rotta nei messaggi utilizzati.
B.2.2. Rotta diretta presentata
Quando la rotta indica che il volo attraverserà il confine su una
rotta diretta, il segmento di rotta diretta ed il COP risultante sono
inclusi nel o nei messaggi ABI. Questo COP è incluso nel
messaggio ACT o RAP successivo.
Il COP ed i dati relativi alla rotta sono presentati nel formato
descritto nel punto B.3.2.
B.2.3. Reinstradamenti dopo la trasmissione dell'ABI e prima della
trasmissione dell'ACT
Si invia un nuovo messaggio ABI con i dati corrispondenti alla
nuova rotta.
B.2.4. Reinstradamento dopo la trasmissione dell'ACT
B.2.4.1. Si utilizza un messaggio REV per indicare i reinstradamenti effet-
tuati dopo l'invio del messaggio ACT prima dello scadere di un
lasso di tempo, concordato bilateralmente, prima dell'ETO sul
COP precedentemente coordinato.
NOTASi utilizza un messaggio REV unicamente quando l'ente
accettante non cambia in seguito alla modifica. Se l'ente
accettante cambia si deve inviare un messaggio MAC
all'ente accettante iniziale o annullare verbalmente il coor-
dinamento.
B.2.4.2. Il messaggio contiene i dati seguenti:
— punto di coordinamento (COP precedente, a titolo di riferi-
mento);
— dati stimati;
— rotta.2000R2082 — IT — 15.06.2002 — 001.001 — 71
▼B
B.2.4.3. I messaggi in formato ICAO contengono i campi seguenti:
3 ipo e numero del messaggio; riferimento del messaggio se
concordato bilateralmente;
7 Identificazione dell'aeromobile. Non si includono gli elementi
b e c a meno che non si stia contemporaneamente coordinando
una revisione del codice SSR;
13 Aerodromo di partenza;
14 Solo l'elemento a contenente il COP precedente, a titolo di
riferimento;
16 Destinazione;
22 Campo 14 contenente i dati stimati per le nuove condizioni di
attraversamento di confine nel formato del campo 22;
22 Campo 15 contenente la nuova rotta nel formato del campo 22.
B.2.4.4. I messaggi in formato ADEXP contengono, oltre al tipo e al
numero del messaggio, l'identificazione dell'aeromobile, l'aero-
dromo di partenza, la destinazione e, se concordato bilateralmente,
il numero di riferimento del messaggio:
— il COP precedente nel campo COP;
— le nuove condizioni di coordinamento nel campo COORDATA;
— la nuova rotta nel campo ROUTE.
B.2.4.5. Le revisioni di rotta inviate nell'ambito della procedura di dialogo
sono inviate sotto forma di messaggi RRV, a meno che non si sia
concordato bilateralmente di considerarle «standard».
B.3.Contenutodeicampi
B.3.1. Rotte ATS
Per i voli reinstradati via una rotta ATS alternativa, i campi relativi
ai dati stimati e alla rotta sono presentati nel formato dei messaggi
ABI e ACT.
B.3.2. Rotte dirette
B.3.2.1. Il punto di coordinamento nei dati stimati è il punto di attraversa-
mento del confine espresso come rilevamento e distanza rispetto a
un punto di riporto. Questi punti sono concordati bilateralmente.
Quando la distanza è nulla o se un volo passerà entro una distanza
concordata bilateralmente da tale punto, si indica solo l'identifica-
tore del punto.
B.3.2.2. Se concordato bilateralmente, il punto di coordinamento per un
volo su una rotta diretta può essere espresso in latitudine e longitu-
dine.
B.3.2.3. La rotta comprende:
— il punto situato sulla rotta originaria a partire dal quale l'aero-
mobile deve seguire una rotta diretta; quando ad un volo è
fatta seguire una rotta diretta dalla «posizione attuale», il punto
può essere espresso come rilevamento e distanza rispetto a un
punto di riporto. Se concordato bilateralmente, il punto può
essere espresso in latitudine e longitudine;
— l'abbreviazione «DCT»;
— il punto verso il quale l'aeromobile deve procedere direttamente;
— il tratto rimanente della rotta ulteriore di volo (FRF), se il
sistema mittente ne è a conoscenza.
B.4.Esempi
B.4.1. Rotte dirette
B.4.1.1. Messaggi ABI e ACT
B.4.1.1.1. Il volo (identificazione Jetset 253) deve attraversare il confine su
una rotta diretta tra il punto A (PTA) ed il punto C (PTC) dopo di
che seguirà la rotta ATS UA134. Il sistema determina un COP il
cui rilevamento è di 350 gradi rispetto al punto B (PTB) e la cui
distanza è di 22 NM rispetto al suddetto punto B (PTB).2000R2082 — IT — 15.06.2002 — 001.001 — 72
▼B
È inviato il seguente messaggio ABI:
— ICAO
(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. Il messaggio ACT ha lo stesso formato del messaggio ABI tranne
per il fatto che la rotta di volo è facoltativa.
B.4.1.2. Messaggio REV
Il volo HZT2051 è stato precedentemente oggetto del messaggio
ACT seguente (o del suo equivalente ADEXP):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
2000R2082 — IT — 15.06.2002 — 001.001 — 73
▼B
Il volo è quindi instradato diretto a MYY da un punto 40 NM ad
ovest del punto RQA. Il punto più vicino all'attraversamento del
confine è TDS da cui la distanza rispetto al punto di effettivo attra-
versamento è 26 NM a 240 gradi. È inviato il messaggio di
revisione seguente:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
L'equivalente ADEXP del messaggio è:
-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG
-SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -
ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310
-REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -
ROUTE N0458F310 RQA270040 DCT MYY
Un messaggio di revisione successivo indicherebbe TDS240026
come COP.2000R2082 — IT — 15.06.2002 — 001.001 — 74
▼B
B.4.2. Reinstradamento via rotte ATS dopo la trasmissione del messaggio
ACT
B.4.2.1. Messaggio ACT
Per il volo GKP217 è pianificato il passaggio sul punto di coordi-
namento EMT. È trasmesso il messaggio ACT seguente:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
Successivamente il volo è reinstradato via la rotta ATS UM247all'interno dello spazio aereo del centro mittente verso un nuovo
punto di coordinamento XAT, superato il quale deve seguire la
rotta ATS UJ124. Il centro accettante rimane lo stesso. È inviato il
seguente messaggio di revisione:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
2000R2082 — IT — 15.06.2002 — 001.001 — 75
▼B
Il volo è quindi autorizzato a passare a FL290, il che dà luogo al
messaggio seguente (contenente il nuovo COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. Equivalenti ADEXP
Gli equivalenti ADEXP dei due messaggi di revisione sono i
seguenti:
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 — IT — 15.06.2002 — 001.001 — 76
▼B
ALLEGATO C (Informativo)
FASI DELLA PROCEDURA DI DIALOGO (LIVELLO SYSCO 1) — SEQUENZA DEI
MESSAGGI
Sequenzadeimessaggi
2000R2082 — IT — 15.06.2002 — 001.001 — 77
▼B
ALLEGATO II
PRESENTAZIONE DELLO SCAMBIO DI DATI PER I SERVIZI DI
TRAFFICOAEREO(ADEXP),EDIZIONE2.0
(documentoEurocontroldiriferimento DPS.ET1.ST09-STD)2000R2082 — IT — 15.06.2002 — 001.001 — 78
▼B
INDICE
AVVISO/DIRITTI D'AUTORE
PREFAZIONE1. CAMPO DI APPLICAZIONE2. RIFERIMENTI3. DEFINIZIONI, SIMBOLI E ABBREVIAZIONI
3.1. Notazione3.2. Definizioni3.3. Costruzione3.4. Convenzioni3.5. Operatori3.6. Simboli e abbreviazioni
4. PRINCIPI ADEXP
4.1. Formato testuale leggibile dall'uomo4.2. Campi identificati e recuperabili4.3. Campi non identificati
5. REGOLE SINTATTICHE ADEXP
5.1. Elementi lessicali5.2. Campi
6. DESCRIZIONE NORMALIZZATA DEI MESSAGGI ADEXP
6.1. Introduzione6.2. Termini ausiliari6.3. Definizione dei campi primari6.4. Definizione dei sottocampi6.5. Gruppi di messaggi
ALLEGATO A (NORMATIVO) DEFINIZIONI DEI CAMPI
ALLEGATO B (NORMATIVO) INDICE CENTRALE DEI TITOLI DI MESSAGGIO ADEXPALLEGATO C (NORMATIVO) INDICE CENTRALE DEI TITOLI DI MESSAGGIO RISERVATIALLEGATO D (NORMATIVO) INDICE CENTRALE DEI CAMPI RISERVATIALLEGATO E (INFORMATIVO) PRESENTAZIONE DEI GRUPPI DI MESSAGGIALLEGATO F (INFORMATIVO) ESEMPI DI FORMATO DI MESSAGGI ADEXPALLEGATO G (INFORMATIVO) SVILUPPI FUTURI2000R2082 — IT — 15.06.2002 — 001.001 — 79
▼B
AVVISO/DIRITTID'AUTORE
Il presente documento è stato elaborato dall'Agenzia Eurocontrol, che ne
detiene i diritti d'autore.
Il contenuto del presente documento, o di qualsiasi parte di esso, è a dispo-
sizione dei rappresentanti degli Stati membri, ma la riproduzione o
divulgazione a terzi è subordinata al preventivo consenso scritto dell'A-
genzia Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 80
▼B
PREFAZIONE
1. Organoresponsabile
La presente norma è stata elaborata dalla sezione «Fabbisogni
degli utenti» dell'Unità centrale di gestione del flusso (CFMU)
dell'Organizzazione europea per la sicurezza della navigazione
aerea (Eurocontrol), che provvede anche al suo aggiornamento.
2. ProgrammadilavoroEATCHIP
La presente norma è un prodotto del Programma di lavoro
EATCHIP (EWPD), Dominio «Sistemi di elaborazione dati
(DPS)», Attività direttiva 09.
3. Approvazionedellanorma
3.1. La presente norma è adottata in conformità alle procedure defi-
nite nelle «Directives for Eurocontrol Standardisation», rif. 000-
2-93, edizione 1.0.
3.2. Le disposizioni della presente norma hanno acquisito efficacia
dopo l'adozione dell'edizione 1.0 da parte della Commissione
permanente di Eurocontrol nel 1995; sono entrate in applicazione
a partire dal 1odicembre 1997.
4. Rettifiche tecnicheemodifiche
La presente norma è all'esame allo scopo di individuare le modi-
fiche o rettifiche tecniche necessarie. La procedura per
l'aggiornamento della presente norma è definita nell'allegato H
delle «Directives for the Uniform Drafting and Presentation of
Eurocontrol Standard Documents».
Le modifiche o integrazioni che influiscono sui principi di base o
sulla grammatica del formato ADEXP possono essere apportate
solo seguendo la procedura di riesame formale definita nelle
«Directives for the Uniform Drafting and Presentation of Euro-
control Standard Documents».
Le modifiche o le integrazioni della presente norma devono
essere proposte per iscritto a: CFMU Users Requirements Section
(ADEXP), Eurocontrol Agency.
5. Convenzioniredazionali
5.1. Il formato della presente norma è conforme alle «Directives for
the Uniform Drafting and Presentation of Eurocontrol Standard
Documents», rispetto alle quali tuttavia vi sono alcune differenze.
Le differenze di formato rispetto alle suddette direttive hanno lo
scopo di evitare confusione con la notazione ADEXP (presenta-
zione dello scambio di dati ATS).
5.2. Per indicare lo status di ciascun elemento è stata adottata le nota-
zione seguente:
— gli elementi normativi sono caratterizzati da verbi al modo
indicativo, tempo presente, e sono stampati in caratteri tondi;
— glielementi raccomandati sono caratterizzati dalla forma
verbale «è opportuno che»; sono stampati in caratteri corsivi
e preceduti dall'indicazione Raccomandazione .
6. Collegamenticonaltrenorme
La presente norma è collegata al documento seguente:Norma Eurocontrol per l'interscambio di dati in linea (OLDI)
7. Statusdegliallegatidellapresentenorma
La presente norma ha 6 allegati, il cui status è indicato qui di
seguito:
Allegato A normativo
Allegato B normativoAllegato C normativoAllegato D normativoAllegato E informativo2000R2082 — IT — 15.06.2002 — 001.001 — 81
▼B
Allegato F informativo
Allegato G informativo
8. Linguautilizzata
Il testo originale della presente norma è stato redatto in lingua
inglese.2000R2082 — IT — 15.06.2002 — 001.001 — 82
▼B
1. CAMPODIAPPLICAZIONE
1.1. ADEXP è un formato, non un protocollo. Non impone alcuna
restrizione relativamente ai supporti o ai protocolli di trasmis-
sione da utilizzare, fatta eccezione per il set di caratteri.
1.2. Il formato ADEXP è destinato principalmente allo scambio di
messaggi in linea tra computer e computer.
1.3. Il presente documento definisce i principi e le regole sintattiche
del formato ADEXP attraverso una definizione completa dei
campi.
1.4. Sono state emanate specifiche per l'uso del formato ADEXP nelle
seguenti aree (per informazioni sui documenti di riferimento, cfr.
sezione 2, pag. 3):
— Pianificazione dei voli: scambio di dati di piano di volo e dei
messaggi associati tra il Sistema integrato di elaborazione
iniziale dei piani di volo (IFPS), i servizi del traffico aereo
(ATS) e gli esercenti di aeromobili (AO). (Documento rif. 3)
— Gestione del flusso del traffico aereo (ATFM): scambio di
messaggi tra il Sistema tattico (TACT) della CFMU, gli AO
e l'ATS. (Documento rif. 5)
— Coordinamento del controllo del traffico aereo: scambio di
messaggi di coordinamento tattico tra enti di controllo del
traffico aereo (ATCU). (Documento rif. 6)
— Gestione dello spazio aereo: scambio di dati tra gli enti ATS
nazionali, la CFMU e gli AO, relativamente alla disponibilità
dello spazio aereo. (Documento rif. 7)
— Coordinamento civile-militare: messaggi riguardanti i dati dei
voli civili e militari e messaggi di attraversamento di spazio
aereo. (Documento rif. 7).
1.5. Le specifiche dettagliate riguardanti l'uso ed il contenuto dei
messaggi di ognuno dei gruppi sopra indicati sono contenute nei
documenti di riferimento.
2. RIFERIMENTI
2.1. I documenti e le norme indicati qui di seguito contengono dispo-
sizioni che, attraverso i rimandi contenuti in questo testo,
costituiscono disposizioni della presente norma Eurocontrol.
Le edizioni indicate sono quelle in vigore al momento della
pubblicazione della presente norma Eurocontrol.
Ogni revisione dei documenti dell'Organizzazione dell'aviazione
civile internazionale (ICAO) a cui si fa riferimento è immediata-
mente incorporata nella presente norma Eurocontrol.
Le revisioni degli altri documenti a cui si fa riferimento non
entrano a far parte delle disposizioni della presente norma Euro-
control se non dopo essere state formalmente esaminate ed
incorporate nella presente norma Eurocontrol.
In caso di conflitto tra le prescrizioni della presente norma Euro-
control ed il contenuto degli altri documenti a cui si fa
riferimento prevale la presente norma Eurocontrol.
2.2. I documenti elencati qui di seguito costituiscono i documenti di
riferimento al momento della pubblicazione della presente norma
Eurocontrol; gli utilizzatori sono comunque invitati a controllare
il modo di utilizzo e le tabelle di composizione dei campi dei
messaggi nelle ultime edizioni pubblicate di tali documenti.
1. ICAO Chicago Convention Annex 10, Volume I, edizione
novembre 1985;
2. ICAO Chicago Convention Annex 10, Volume II, edizione
luglio 1995;
3. IFPS and RPL Dictionary of Messages, edizione 1.0, marzo
1998;
4. «Rules of the Air and Air Traffic Services», PANS-RAC Doc.
4444, edizione novembre 1985 (compreso l'Amendment No. 6
del novembre 1995);
5. Guide To ATFM Message Exchange, Eurocontrol Document
Ref. TACT/USD/MSGGUID, edizione 6.0, in vigore dal
marzo 1998;2000R2082 — IT — 15.06.2002 — 001.001 — 83
▼B
6. Eurocontrol Standard for On-Line Data Interchange, edizione
2.0, ottobre 1996.
7. Functional Specifications for System Support to Airspace Data
Distribution and Civil Military Co-ordination, edizione 1.0,
maggio 1996.
3. DEFINIZIONI,SIMBOLIEABBREVIAZIONI
3.1. Notazione
Il sistema di notazione usato per definire la sintassi è denominato
Forma normale di Backus (BNF). Questo sistema definisce un
insieme di regole che determina una categoria di stringhe di
caratteri. In questo caso, la categoria di stringhe di caratteri è
l'insieme di messaggi che formano un messaggio ADEXP sintat-
ticamente valido.
3.2. Definizioni
Ai fini della presente norma Eurocontrol si applicano le seguenti
definizioni:
unità («token») : carattere o insieme di caratteri che può essere
«estratto» da un analizzatore lessicale per la presenza di separa-
tori;
simbolo: qualsiasi «termine» che figura in una regola BNF ma
non è un carattere;
simbolo terminale : simbolo rappresentato in termini di sequenza
di caratteri;
simbolo non terminale : simbolo rappresentato da uno o più
simboli terminali.
NOTAUn simbolo non terminale può essere rappresentato
anche come un insieme di simboli terminali e non termi-
nali.
3.3. Costruzione
3.3.1. La BNF è costituita da un insieme di regole o costrutti del tipo:
simbolo::= espressione
NOTE1)La notazione «::=» va letta come «può essere sostituito da».
2)Il «simbolo» è classificato come non terminale.
3)L'elemento «espressione» contiene simboli terminali e non
terminali.
3.3.2. I simboli terminali hanno una rappresentazione diretta costituita
da una sequenza di caratteri che possono essere identificati come
unità («token») da un analizzatore lessicale, grazie alla presenza
di separatori.
3.4. Convenzioni
Ai fini della presente norma Eurocontrol si applicano le seguenti
convenzioni:
— I simboli terminali sono in lettere maiuscole.
NOTAPer convenzione, il simbolo terminale NIL significa
«nessun simbolo terminale» .
Questo simbolo è usato in scelte come nell'esempio
qui sotto:
a::= b ( c | NIL )dove a può essere sostituito da (b
seguito da c) o da b solamente.
— I simboli non-terminali (ad es. la parte sinistra di una produ-
zione grammaticale) sono in lettere minuscole.
—I caratteri e i letterali di stringa che figurano all'interno delle
regole sono racchiusi rispettivamente tra virgolette singole (')
o doppie (").
Esempi1) HYPHEN:= '-'2000R2082 — IT — 15.06.2002 — 001.001 — 84
▼B
2) title:= '-' "TITLE" titleid
Per alcune applicazioni di modellizzazione di dati, può essere
necessario distinguere i simboli terminali dai simboli non termi-
nali con sistemi diversi dall'uso delle lettere maiuscole e
minuscole.
Quando occorre distinguere esplicitamente i simboli terminali dai
simboli non terminali con un sistema diverso dall'uso delle lettere
maiuscole o minuscole, si raccomanda di ricorrere all'aggiunta di
un suffisso: «_at» per un termine ausiliare, «_pf» per un campo
primario ed «_sf» per un sottocampo.
3.5. Operatori
Ai fini della presente norma Eurocontrol si applicano i seguenti
operatori:
facoltativo: quando certi simboli possono validamente figurare o
non figurare in un determinato punto nella grammatica. I simboli
facoltativi sono racchiusi tra parentesi quadre «[» e »]».
chiusura: quando un gruppo di simboli può apparire zero volte o
più. I simboli sono racchiusi tra parentesi graffe «{» e «}». Se
prima della parentesi graffa «{» compare un numero, questo
indica il numero minimo di volte per cui può apparire il gruppo
di simboli. Se dopo la parentesi graffa «}» compare un numero,
questo indica il numero massimo di volte per cui può apparire il
gruppo di simboli.
scelta:quando in un punto della grammatica possono figurare di-
versi simboli alternativi. La scelta è indicata da «|».
concatenazione: rappresentazione di simboli ordinati in sequenza.
I simboli possono essere anche inframmezzati da uno o più sepa-
ratori. Non esiste una rappresentazione esplicita della
concatenazione. Si distinguono due tipi di concatenazione:
—concatenazione rigida: a livello lessicale, le regole possono
comportare una concatenazione di simboli terminali che si
succedono senza separatori intermedi; in questo caso si
utilizza il punto esclamativo «!».
Esempio datetime:: = date ! timehhmm
es. "9912251200", che significa 25 dicembre 1999, alle ore
12.00.
—concatenazione flessibile: è ammessa la presenza di separatori
tra simboli terminali. La rappresentazione di una concatena-
zione flessibile in una regola può essere implicita o esplicita.
Esempi1) implicita:
dct::= '-' "DCT" point point
2) esplicita
dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
es "-DCT NTM RMS".
NOTE
1)La concatenazione ha sempre la precedenza sulla scelta. Le
parentesi «(» e »)» sono usate per modificare l'ordine di valu-
tazione dell'espressione.
Esempio a::= B C | D equivale a: a::= (B C) | D
e NON a: a::= B (C | D).
2)In tutte le regole, la presenza ammessa di separatori tra i
simboli è lasciata implicita allo scopo di migliorare la leggi-
bilità.
Raccomandazione Quando c'è rischio di confusione riguardo
alla precedenza da rispettare tra gli operatori sopra indicati, si
raccomanda di usare le parentesi per chiarire l'ordine di valuta-
zione desiderato.2000R2082 — IT — 15.06.2002 — 001.001 — 85
▼B
3.6. Simbolieabbreviazioni
Ai fini della presente norma Eurocontrol si applicano le seguenti
sigle e abbreviazioni:
ACH Messaggio di modifica di piano di volo
ATC
ADEG Gruppo per lo scambio di dati ATS
ADEXP Presentazione dello scambio di dati ATSAFIL Piano di volo trasmesso durante il voloAFP Proposta di piano di volo ATCAFTN Rete del servizio fisso delle telecomunica-
zioni aeronautiche
ANM Messaggio di notifica ATFM
AO Esercente/i di aeromobiliAPL Piano di volo ATCATC Controllo del traffico aereoATCU Ente/i di controllo del traffico aereoATFM Gestione dei flussi di traffico aereoATS Servizi del traffico aereo
BNF Forma normale di Backus
CASA Assegnazione computerizzata degli slot
CIDIN Rete ICAO comune di interscambio di datiCFL Livello di volo autorizzatoCFMU Unità centrale di gestione dei flussi di traf-
fico
CMTP Piano comune a medio termineCNL Messaggio di cancellazioneCTOT Orario calcolato di decollo
DPS Dominio «Sistemi di elaborazione dati»
ECAC European Civil Aviation Conference
(Conferenza europea sull'aviazione civile)
EFL Livello di volo stimatoEOBT Orario stimato di inizio rullaggioETO Orario stimato di sorvolo di un punto
EUROCONTROL Organizzazione europea per la sicurezza
della navigazione aerea
EWPD Documento «Programma di lavoro
EATCHIP»
FIR Regione di informazioni di volo
FIW Workstation di immissione dei piani di
volo
FMP Posizione di gestione dei flussi di trafficoFNM Messaggio di notifica di voloFPL Messaggio di piano di volo (formato
ICAO)
GAT Traffico aereo generale
IA Alfabeto internazionale
IAFP Proposta di piano di volo ATC singoloICAO International Civil Aviation Organisation
(Organizzazione dell'aviazione civile inter-
nazionale)
IFPD Dati di piano di volo singoloIFPS Sistema integrato di elaborazione iniziale
dei piani di volo
IFPU Unità IFPSIFR Regole del volo strumentaleISO International Standards Organisation (Orga-
nizzazione internazionale di normazione)
ITA Alfabeto telegrafico internazionale
LAM Messaggio di riscontro logico
LRM Messaggio di rigetto logico
MAC Messaggio di abrogazione del coordina-
mento2000R2082 — IT — 15.06.2002 — 001.001 — 86
▼B
MFS Messaggio da Shanwick
OAT Traffico aereo operativo
OLDI Interscambio di dati in linea
RFL Livello di volo richiesto
RFP Piano di volo sostitutivoRFPD Dati di piano di volo ripetitivoRPL Piano di volo ripetitivoRVR Portata visuale di pista
SFL Livello di volo supplementare
SRD Documento sui requisiti software
SSR Radar secondario di sorveglianza
TACT Sistema tattico della CFMU
TOS Programma di orientamento del traffico
UIR Regione superiore di informazioni di volo
VFR Regole del volo a vista
4. PRINCIPIADEXP
4.1. Formatotestualeleggibile dall'uomo
4.1.1. Il formato ADEXP si presenta sotto forma di testo (caratteri).
4.1.2. I messaggi ADEXP rimangono leggibili per l'operatore, il che
facilita la messa a punto o l'esame delle questioni operative.
4.1.3. Questo formato risulta anche più aperto e comprensibile.
4.2. Campiidentificati erecuperabili
4.2.1. Un messaggio in formato ADEXP è composto da campi.
4.2.2. I campi sono delimitati da un carattere speciale di inizio campo,
il trattino («-», hyphen in inglese), e sono identificati da parole
chiave specifiche.
NOTASi noti che in alcuni campi (quelli sintatticamente definiti
come contenenti l'elemento lessicale «CHARACTER») nel
contenuto del campo può validamente figurare un carat-
tere «-».
4.2.3. Questa soluzione offre possibilità di estensione e migliora la
robustezza del formato. (Se un campo è assente o non è corretto,
può essere ignorato e la parte rimanente del messaggio può essere
comunque interpretata) (cfr. sezione 4.3).
4.2.4. Un'altra conseguenza è che l'ordine dei campi di un messaggio
non influisce in alcun modo sulla determinazione della validità
del messaggio, fatta eccezione per il primo campo (campo obbli-
gatorio del titolo) che determina i campi ammessi.
4.2.5. I campi possono essere semplici o composti.4.2.6. I costituenti dei campi composti sono denominati sottocampi e
sono definiti dalla presenza di parole chiave, delimitate da un
carattere di inizio campo.
4.2.7. I campi semplici sono campi che non contengono sottocampi.
4.2.8. I campi semplici o composti che costituiscono il primo livello di
definizione di un messaggio sono denominati campi primari.
4.2.9. Tutti i costituenti di livello inferiore sono per definizione sotto-
campi, che a loro volta possono essere semplici o composti.
4.2.10. I campi composti sono di due tipi, campi strutturati e campi lista.
4.2.11. I campi strutturati hanno un contenuto predefinito e sono
composti da esclusivamente da sottocampi. L'ordine dei sotto-
campi in un campo strutturato NON è significativo.
4.2.12. I campi lista iniziano con la parola chiave BEGIN e terminano
con la parola chiave END. Tra queste due parole chiave si
possono trovare più occorrenze di uno stesso sottocampo o una2000R2082 — IT — 15.06.2002 — 001.001 — 87
▼B
combinazione di sottocampi diversi. L'ordine delle occorrenze
all'interno di un campo lista è semanticamente significativo.
4.2.13. Nei paragrafi seguenti, il termine «campo» è usato per indicare
indistintamente campi primari e/o sottocampi, salvo diversa indi-
cazione.
4.2.14. I campi di un messaggio possono essere facoltativi od obbligatori,
secondo la loro sintassi.
4.3. Campinonidentificati
4.3.1. Se in un messaggio figura un campo non identificato, tale campo
è ignorato.
4.3.2. In altre parole, se il sistema che analizza il messaggio non rico-
nosce una parola chiave, ignora tutto il testo fino al successivo
campo primario identificato non collocato all'interno di un campo
lista.
4.3.3. A seconda del titolo del messaggio, il campo ignorato può deter-
minare o no il rigetto del messaggio.
NOTAÈ bene notare che, sebbene ADEXP sia studiato per
offrire questo tipo di flessibilità, i responsabili della defi-
nizione dei requisiti in materia di interfaccia possono a
loro discrezione indicare, per ogni messaggio, come
deve reagire il sistema ad un campo non identificato.
4.3.4. Se il campo non identificato è un campo lista (che perciò inizia
con la parola chiave -BEGIN) tutto il suo contenuto (fino alla
parola chiave -END corrispondente) è ignorato.
4.3.5. Per evitare ambiguità nel recupero dopo il salto di un campo non
identificato è indispensabile che i campi primari e i sottocampi
inizino con una parola chiave.
4.3.6. Si possono quindi distinguere due tipi di parole chiave:
— parole chiave primarie;
— parole chiave secondarie.
4.3.7. Una volta che è stata definita come appartenente ad uno dei due
tipi, una parola chiave non può essere riutilizzata in un altro
gruppo di messaggi come parola chiave dell'altro tipo, eccetto se
è all'interno di un campo lista. È possibile avere occorrenze
interne di una parola chiave primaria in qualsiasi punto all'interno
di un campo lista senza che si crei ambiguità, perché la presenza
della parola chiave BEGIN indica che l'occorrenza interna può
essere considerata come un sottocampo.
Esempi (di utilizzo dei tipi di parole chiave)
1)Campo primario
-RFL F330
2)Sottocampo: sempre all'interno di un «campo composto»
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W
dove -GEO è un campo composto primario e -GEOID, -
LATTD e LONGTD sono tutti sottocampi.
3)Campo lista
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTS
dove «-BEGIN» è l'identificatore di campo lista e «RTEPTS»
è un campo primario.
NOTA«RFL» è definito come un campo primario. L'inclusione
in un campo lista è l'unico caso in cui un campo primario
può essere utilizzato come sottocampo. (cfr. esempio 3
precedente)2000R2082 — IT — 15.06.2002 — 001.001 — 88
▼B
5. REGOLESINTATTICHEADEXP
5.1. Elementi lessicali
5.1.1. Set di caratteri
5.1.1.1. Il set di caratteri da utilizzare per lo scambio di messaggi in
formato ADEXP è l'alfabeto internazionale n. 5 (IA-5) definito
nel riferimento 1.
5.1.1.2. ADEXP è un formato di scambio di dati tra computer e computer
utilizzabile in varie reti di computer o su collegamenti computer-
computer dedicati. Inoltre alcuni messaggi ADEXP, in particolare
messaggi relativi alla pianificazione dei voli e all'ATFM, devono
poter essere scambiati sulla rete del servizio fisso delle telecomu-
nicazioni aeronautiche (AFTN).
5.1.1.3. Nei messaggi che possono dover essere trasmessi via AFTN il set
di caratteri è limitato ai caratteri che presentano una correlazione
diretta tra l'alfabeto telegrafico internazionale n. 2 (ITA-2) e l'IA-
5, definito nel riferimento 1.
NOTAOltre ai caratteri grafici e ai caratteri di impaginazione
indicati qui di seguito, il set di caratteri ITA-2 definisce
anche una serie di «segnali» (ad esempio nastro perfo-
rato). Questi segnali non fanno parte del set di caratteri
ammessi per i messaggi ADEXP.
5.1.1.4. I caratteri ammessi nei messaggi ADEXP che possono essere
trasmessi via AFTN sono i caratteri grafici ed i caratteri di impa-
ginazione indicati qui sotto:
Caratteri grafici
a) lettere maiuscole (da A a Z)
b) numeri (da 0 a 9)
c) caratteri grafici speciali:
1) spazio « »
2) parentesi aperta «(»3) parentesi chiusa «)»4) trattino «-»5) punto interrogativo «?»6) due punti «:»7) punto «.»8) virgola «,»9) apostrofo «'»
10) segno uguale «=»11) segno più «+»12) barra «/»
Caratteri di impaginazione
a) Ritorno carrello
b) Avanzamento riga
5.1.2. Unità lessicali di base
Le unità lessicali di base utilizzabili sono le seguenti:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
— ALPHANUM ::= ALPHA | DIGIT
— SPACE ::= ' '— HYPHEN ::= '-'
— FEF ::= Carriage_return | Line_Feed
— SEP ::= 1{ SPACE | FEF }
— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'
— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF— START-OF-FIELD ::= HYPHEN2000R2082 — IT — 15.06.2002 — 001.001 — 89
▼B
NOTALIM_CHAR rappresenta qualsiasi carattere ammesso
eccetto il trattino («HYPHEN») utilizzabile esclusiva-
mente per indicare l'inizio di un campo. Al contrario,
CHARACTER rappresenta qualsiasi elemento ammesso
del set di caratteri.
5.1.3. Righe, separatori e delimitatori
5.1.3.1. La divisione del testo di un messaggio in righe non ha alcun
effetto sintattico.
5.1.3.2. Un separatore può essere un carattere spazio o un carattere di
impaginazione.
5.1.3.3. I campi sono delimitati solo dalla presenza di un carattere di
inizio campo seguito da una parola chiave.
5.1.3.4. Un messaggio può quindi essere validamente formulato su una
sola riga.
5.1.4. Valori con segno
5.1.4.1. Può essere necessario indicare un valore numerico negativo.
5.1.4.2. I campi in cui può essere necessario riportare un valore negativo
indicano esplicitamente, nella loro definizione sintattica, che il
valore è contraddistinto da un segno, positivo o negativo. Un
campo che non è stato definito in questo modo non può rappre-
sentare un valore negativo.
5.1.4.3. Un valore con segno deve sempre essere preceduto dalla lettera
«N» per negativo o «P» per positivo. Il valore zero può essere
preceduto da «N» o da «P».
5.1.4.4. La sintassi di un campo che ammette un valore con segno è la
seguente:
'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}
Esempio Un campo chiamato «NUMBER» che può contenere un
valore negativo da una a otto cifre sarebbe definito nel
modo seguente:
'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8
Quindi: -NUMBER P5 — valore +5
-NUMBER N5 — valore -5
-NUMBER 5 — sintassi non valida, il numero
deve essere obbligatoriamente
preceduto da «P» o «N»
5.1.5. Parole chiave
5.1.5.1. Una parola chiave è una qualsiasi sequenza di lettere maiuscole o
numeri. Introduce un campo solo quando è preceduta da un carat-
tere di inizio campo («-»).
keyword::= 1{ ALPHANUM }
5.1.5.2. Le parole chiave rispettano la seguente sintassi:
'-'!{SEP}!"KEYWORD"!1{SEP}! <subfield/s or contained value>
perciò una parola chiave è separata dal suo carattere di inizio
campo da zero o più separatori, ed è seguita immediatamente da
uno o più separatori, quindi dal/i sottocampo/i o dal valore conte-
nuto.
NOTA È importante notare che una parola chiave può essere
separata dal carattere di inizio campo che la precede da
qualsiasi numero di separatori, compreso zero.
ESEMPI (le sequenze riportate di seguito introducono tutte
validamente un campo)
1) -TITLE IFPL
2) - TITLE IFPL3) - TITLE IFPL4) -
TITLE IFPL
5.1.5.3. Raccomandazione Si raccomanda di non usare un separatore tra
il carattere di inizio campo «-» e la parola chiave che segue.2000R2082 — IT — 15.06.2002 — 001.001 — 90
▼B
NOTA
1) Negli esempi qui sopra, la prima occorrenza è la soluzione
raccomandata.
2) È importante anche notare che una parola chiave deve essere
immediatamente seguita da almeno un separatore.
5.1.5.4. Nel presente documento la concatenazione di elementi separati da
almeno un separatore è rappresentata implicitamente dalla nota-
zione di «concatenazione flessibile» (cfr. 3.5).
NOTA Come spiegato più avanti, le parole chiave introducono
anche campi lista quando sono precedute dalla parola chiave
BEGIN.
5.1.5.5. Le parole chiave sono il più possibile brevi, rimanendo allo stesso
tempo semanticamente significative.
5.1.5.6. Le parole chiave predefinite del formato ADEXP elencate qui di
seguito non possono essere ridefinite o utilizzate con una
funzione diversa in applicazioni specifiche del formato:
TITLE: identifica una categoria di messaggi e definisce
l'insieme corrispondente di campi primari
ammessi;
BEGIN: identifica l'inizio di un campo lista;
END: identifica la fine di un campo lista;
COMMENT: identifica un campo COMMENT (osservazioni).
5.1.5.7. Per non generare ambiguità (uso di una stessa parola chiave con
significati diversi) o ridondanza (parole chiave diverse con lo
stesso significato), l'allegato A (A3) della presente norma riporta
una tabella centrale di definizioni dei campi primari (cioè delle
parole chiave primarie), mentre l'allegato A (A4) riporta una
tabella centrale di definizioni dei sottocampi (cioè delle parole
chiave secondarie).
5.2. Campi
5.2.1. Sintassi dei campi
field::= basic_field | structured_field | list_field
basic_field::= '-' keyword contained_valuescontained_values::= {CHARACTER}list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keywordstructured_field::= '-' keyword field_1 field_2 ….field_n
NOTA Come si vedrà più avanti, nei campi lista la parola chiave
non è preceduta direttamente da «-» ma dal costrutto «-
»«BEGIN»
5.2.2. Composizione dei messaggi in termini di campi
5.2.2.1. Il primo campo di un messaggio ADEXP è sempre un campo
TITLE (cioè un campo titolo introdotto dalla parola chiave
TITLE).
5.2.2.2. Gli altri campi primari che compongono il messaggio sono defi-
niti dal suo titolo TITLE.
5.2.2.3. La sintassi dei messaggi corrispondenti ad un determinato TITLE
è definita dai campi che compongono il messaggio (definiti dalla
loro parola chiave):
— nome e contenuto ammesso dei campi primari;
— nome e contenuto ammesso dei sottocampi.
5.2.3. Campi semplici
5.2.3.1. La sintassi dei campi semplici è la seguente:
basic_field::= '-' keyword contained_values
5.2.3.2. I «valori_contenuti» sono costituiti dal testo che precisa il valore
del campo; non possono introdurre alcun sottocampo.2000R2082 — IT — 15.06.2002 — 001.001 — 91
▼B
Esempio di regola arctyp::= '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")
NOTA
1) Un equivalente esplicito sarebbe:
arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype |
"ZZZZ").
2) Esempio di porzione di messaggio::
"-ARCTYP ZZZZ".
5.2.3.3. Raccomandazione Quando un campo semplice comprende più di
due valori contenuti ed è necessario anche esprimere una scelta o
un'opzione tra i valori, si raccomanda di trasformare il campo in
campo strutturato e di includere i valori contenuti nei sottocampi.
5.2.4. Campi lista
5.2.4.1. La sintassi dei campi lista è la seguente:
list_field::='-' "BEGIN" keyword { subfields } '-' "END" keyword
5.2.4.2. I «sottocampi» possono essere costituiti da qualsiasi combina-
zione di sottocampi che può figurare zero o più volte nel campo
lista.
5.2.4.3. L'elenco dei sottocampi contenuti in un determinato campo lista
forma un insieme ordinato (l'ordine dei sottocampi è significa-
tivo).
Esempio di regola addr::= '-' "BEGIN" "ADDR" { fac } '-'
"END" "ADDR"
NOTA
1) In questo esempio il campo «addr» è un campo lista conte-
nente 0 o più occorrenze di un sottocampo «fac»
(un'installazione ATS).
2) Esempio di porzione di messaggio in cui ADDR è un campo
lista contenente sottocampi
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.
3) Esempio di porzione di messaggio in cui figura una combina-
zione di sottocampi:
xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".
5.2.5. Campi strutturati
5.2.5.1. La sintassi dei campi strutturati è la seguente:
structured_field::= '-' keyword field_1 field_2…field_n
5.2.5.2. I sottocampi ammessi in un campo strutturato dipendono esclusi-
vamente dal campo strutturato stesso.
5.2.5.3. L'ordine in cui figurano i sottocampi in un campo strutturato non
è significativo, il che facilita le estensioni successive (aggiunta di
nuovi sottocampi).
Esempiodiregola pt::= '-' "PT" ptid [fl] [eto]
NOTE
1) Nell'esempio, il campo «pt» è un campo strutturato contenente
un punto (sottocampo «ptid»), seguito facoltativamente da un
livello di volo calcolato (sottocampo «fl»), seguito facoltativa-
mente da un orario stimato di sorvolo del punto (sottocampo
«eto»).
2) Un esempio di occorrenza di questo campo potrebbe essere:
"-PT -PTID RMS -FL F250 -ETO 921225120000".
5.2.5.4. Raccomandazione Se si ritiene che il contenuto di un campo
possa evolvere in futuro, è consigliabile trasformarlo in un
campo strutturato: in questo modo sarà possibile aumentare
progressivamente i sottocampi. Un campo semplice può essere
più facile da usare e più familiare, ma impone una sequenza fissa
di elementi (valori) ed offre possibilità di estensione molto limi-
tate.2000R2082 — IT — 15.06.2002 — 001.001 — 92
▼B
5.2.6. Il campo COMMENT (osservazioni)
5.2.6.1. Il campo COMMENT introduce un'area di testo libero in cui
possono essere utilizzati tutti i caratteri eccetto il carattere di
inizio campo («-»), e si estende fino al campo successivo.
comment::= '-' "COMMENT" { LIM_CHAR }
Esempio COMMENT THIS IS THE BEGINNING OF A FREE
ROUTE TEXT AREA
5.2.7. Il campo TITLE (titolo)
5.2.7.1. Il primo campo di un messaggio ADEXP è sempre un campo
TITLE. La sintassi di questo campo è la seguente:
title::= '-' "TITLE" 1{ ALPHA }10
5.2.7.2. I valori possibili del campo TITLE sono costituiti dai titoli di
messaggi ADEXP, elencati nell'allegato B della presente norma.
Esempio -TITLE IFPL
6. DESCRIZIONE NORMALIZZATA DEI MESSAGGI
ADEXP
6.1. Introduzione
6.1.1. I paragrafi seguenti definiscono il modo in cui il formato ADEXP
delle varie categorie di messaggi è descritto in modo normaliz-
zato nel quadro della presente norma.
6.1.2. Questa descrizione normalizzata comprende:
— la definizione dei termini ausiliari;
— la definizione della sintassi e della semantica di ogni campo
primario;
— la definizione della sintassi e della semantica di ogni sotto-
campo;
— la definizione di ogni gruppo di messaggi con rinvio alla
documentazione di specifica.
6.1.3. La presente norma non fornisce indicazioni particolareggiate sulla
composizione dei campi e sulle regole di inserimento dei dati per
ogni titolo di messaggio.
6.1.4. È consigliabile fare riferimento ai documenti di specifica (speci-
fica d'interfaccia) relativi ad ogni gruppo di messaggi (cfr.
sezione 6.5.7).
6.1.5. I documenti di specifica dovrebbero fornire in modo normalizzato
le seguenti informazioni per ogni titolo di messaggio:
— elenco dei campi primari obbligatori;
— elenco dei campi primari facoltativi;— regole di inserimento dei dati per ogni campo e, in partico-
lare, regole riguardanti l'uso dei sottocampi definiti
facoltativi nella presente norma;
— regole riguardanti il recupero dopo il rilevamento di un campo
non identificato.
6.1.6. I campi attualmente definiti e approvati dagli Stati membri di
Eurocontrol per l'utilizzo nelle diverse categorie di messaggi
ADEXP sono indicati nell'allegato A del presente documento.
6.1.7. Un campo non può essere utilizzato per scopi diversi da quelli
specificati nella sua descrizione semantica.
6.1.8. Un indice centrale dei campi riservati figura nell'allegato D. L'uso
dei «campi riservati» nei messaggi ADEXP attualmente definiti
non è stato approvato. Si tratta generalmente di campi definiti in
previsione di un possibile uso futuro, o utilizzati localmente dai
sistemi nazionali. Questi campi sono stati inclusi nella presente
norma per assicurare l'unicità dei titoli dei campi ed evitare inutili
ridondanze.
6.2. Terminiausiliari
6.2.1. Per ottenere una definizione leggibile dei campi spesso è utile
introdurre dei termini ausiliari nella descrizione grammaticale.2000R2082 — IT — 15.06.2002 — 001.001 — 93
▼B
6.2.2. I termini ausiliari non introducono un campo o un sottocampo, e
quindi non sono associati ad una particolare parola chiave. Essi
tuttavia possono apparire nella definizione di più campi, sotto-
campi o elementi ausiliari. Ad esempio un termine ausiliare
come «date» può essere usato nella definizione di molti campi.
6.2.3. Tutti i termini ausiliari necessari sono introdotti in ordine alfabe-
tico e sono definiti nell'allegato A (A2) della presente norma.
6.2.4. La descrizione può essere presentata in una tabella, come qui sotto, in ordine alfabe-
tico:
Termine
ausiliareSintassi SemanticaUsato in
campo
primarioUsato in
sottocampoUsato
in
eleme-
nto
ausi-
liare
adexpmsg { CHARACTER } Testo libero
conforme alla
sintassi
descritta per i
messaggi
ADEXP.ifpdlong
rfpdlongpreproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeApparati per le
comunicazioni
radio e aiuti
per la naviga-
zione e l'avvi-
cinamento.ceqpt
aircraftid 1{ ALPHANUM
}7Identificazione
di aeromobile.arcid
arcidkarcidold
prevarcid
6.3. Definizionedeicampiprimari
6.3.1. Tutti i campi primari utilizzati nei messaggi ADEXP sono
conformi alla sintassi e alla semantica specificate nell'allegato A
(A3) della presente norma.
6.3.2. Per prima cosa è indicata la sintassi di ogni campo, quindi la
semantica in termini chiari e inequivocabili.
6.3.3. La sintassi dei campi è espressa utilizzando il sistema di nota-
zione BNF presentato nella sezione 3 della presente norma.
6.3.4. La descrizione può essere presentata in una tabella come qui sotto, in ordine alfabetico,
dove:
— la prima colonna corrisponde alla parte sinistra di una regola BNF (cioè la parte
della regola posta a sinistra del simbolo «::=»), e la terza colonna corrisponde alla
parte destra;
— la seconda colonna (Tipo) indica se il campo è semplice («b», cioè «basic»)
composto («c», cioè «compound»).
Campo primario Tipo Sintassi Semantica
eobt b '-' "EOBT" timehhmm Orario stimato di inizio
rullaggio
6.4. Definizionedeisottocampi
6.4.1. Tutti i sottocampi usati nei messaggi ADEXP sono conformi alla
sintassi e alla semantica specificate nell'allegato A (A4) della
presente norma.
6.4.2. Per facilitare i rimandi sono identificati i campi primari in cui
compare il sottocampo specifico.
6.4.3. Un sottocampo può essere anche un sottocampo di altri sotto-
campi, quindi sono presenti anche rimandi a questi sottocampi.2000R2082 — IT — 15.06.2002 — 001.001 — 94
▼B
6.4.4. La descrizione può essere presentata in una tabella, come qui sotto, in ordine alfabe-
tico:
Sottocampo Tipo Sintassi SemanticaUsato in
campo
primarioUsato
in sotto-
campo
brng b '-' "BRNG"
refbearingRilevamento di
un punto da un
aiuto alla naviga-
zione (in gradi
magnetici)ref
6.5. Gruppidimessaggi
6.5.1. Le categorie operative (gruppi) di messaggi utilizzabili nel
formato ADEXP sono presentate nell'allegato E della presente
norma.
6.5.2. Questi gruppi sono definiti in base alla natura operativa dei
messaggi scambiati, e si caratterizzano spesso per i sistemi utiliz-
zati.
6.5.3. Per ogni gruppo di messaggi si rimanda alla relativa documenta-
zione di specifica.
6.5.4. Un valore TITLE utilizzato per un gruppo di messaggi non può in
nessun caso essere riutilizzato per un altro gruppo con un diverso
significato.
6.5.5. Un indice centrale dei titoli di messaggio è contenuto nell'allegato
B della presente norma.
6.5.6. Ad ogni titolo di messaggio contenuto in questo indice centrale è
associato un rinvio al relativo gruppo di messaggi; il rinvio aidocumenti di specifica si effettua quindi attraverso il gruppo di
messaggi.
6.5.7. Un indice centrale di titoli di messaggio riservati è contenuto
nell'allegato C. L'uso di questi titoli di messaggio «riservati» nei
gruppi di messaggi ADEXP attualmente definiti non è stato
approvato. Si tratta generalmente di messaggi definiti in previ-
sione di un possibile uso futuro in uno dei gruppi definiti, o di
messaggi usati localmente nei sistemi nazionali. Questi messaggi
sono stati inclusi nella presente norma per assicurare l'unicità dei
titoli di messaggio ed evitare inutili ridondanze.2000R2082 — IT — 15.06.2002 — 001.001 — 95
▼B
ALLEGATO A (Normativo)
DEFINIZIONIDEICAMPIADEXP
A.1.Introduzione
Il presente allegato contiene un elenco di tutti i campi — termini ausi-
liari, campi primari e sottocampi — specificati per il formato ADEXP.
A.2.Termini ausiliariADEXP
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
adexpmsg { CHARACTER } Testo libero
conforme alla
sintassi descritta per
un messaggi
ADEXP.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeApparati per le
comunicazioni radio
e aiuti per la navi-
gazione e l'avvici-
namento.ceqpt
aircraftid 2{ ALPHANUM }7 Identificazione di
aeromobile.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Forma jolly di
aircraftid da usare
nei messaggi di
interrogazione:
«?» sostituisce un
carattere
«+» sostituisce
qualsiasi stringa di
caratteri.arcidk
atsroute 2 {ALPHANUM} 7 Identificatore di
rotta ATS.atsrt refatsrte
century 2{DIGIT}2 Prime due cifre del
secolo.fulldate
coorstatusident 3 {ALPHA} 3 Indicazione dello
status di coordina-
mento di un volo.statid
coorstatu-
sreason3 {ALPHA} 7 Motivo della noti-
fica di un cambia-
mento dello status
di coordinamento.statreas-
on
country 2{ALPHA}2 Identificatore ICAO
del paese, in due
lettere.refatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4Identificatore ICAO
del collegamento
dati. Può contenere
i valori S, H, V o M
in qualsiasi ordine
ma senza ripeti-
zioni.dat2000R2082 — IT — 15.06.2002 — 001.001 — 96
▼B
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
date year ! month ! day Indicazione della
data nel formato
AAMMGG.
Es. 930424 = 24
aprile 1993.ada
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 Data, così come
definita qui sopra,seguita dall'orario
nel formato
HHMM.
Es.
9304240930=0930Z
del 24 aprile 1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6Gruppo data in cuiè ammesso il
formato jolly.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITNumero di duecifre, da 00 a 31.endtimefiltim
starttimeendreg
from
startreg
untildatefulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicatore del tipo
di apparati radio di
emergenza presenti
a bordo dell'aero-
mobile. Può essere
composto da uno o
più caratteri tra
quelli specificati, in
qualsiasi ordine ma
senza ripetizioni.splr
eqptcode 1 {ALPHANUM} 2 Codice che identi-
fica una capacità
dell'apparecchiatura,
può corrispondere a
«equipmentmode»eqpt
eqptstatus 2 {ALPHA} 2 Valore espresso con
due lettere indicantilo stato delle
capacità dell'aero-
mobileeqpt
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' )} 24Codice alfabeticoICAO valido che
indica il tipo di
apparati presenti.
Può essere
composto da uno o
più caratteri tra
quelli specificati, in
qualsiasi ordine ma
senza ripetizioni.aidequip-ment2000R2082 — IT — 15.06.2002 — 001.001 — 97
▼M1
B▼
▼B
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
errorcode 1{DIGIT}4 Codice numerico
del messaggio
d'errore.error
fieldid 1{ ALPHANUM } Nome di campo
ADEXP valido
(parola chiave).errfield
ifpsmod
firindicator 4{ ALPHA }4 Identificatore ICAO
di una FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4Livello di volo
espresso nel modo
seguente:
«F» o «A» seguita
da tre cifre, oppure
«S» o «M» seguita
da quattro cifre.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'Motivo del tratta-
mento speciale indi-
cato nella casella 18
(elemento «STS/»).
EMER = emergenza
HUM = volo
umanitario
HOSP = volo
ambulanza
SAR = ricerca e
salvataggio
HEAD = capo di
Stato
STATE = volo di
Statosts
flightrule 'I' | 'V' | 'Y' | 'Z' Indicatore delle
regole del volo
applicabili al volo.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Tipo di volo così
come indicatodall'identificatore
ICAO utilizzato.flttyp
flighttypechg 'OAT' | 'GAT' Indicazione, nella
rotta di volo, di una
modifica del tipo di
volo in «OAT» o
«GAT».chgrul ptrulchg
fulldate century ! year !
month ! dayIndicazione della
data in formato
AAAAMMGG
Es. 19970801 = 1
o
agosto 1997fulldate-
time
fulldatetime fulldate ! timehhmm Indicazione della
data in formato
AAAAMMGG,
seguita immediata-
mente dall'orario in
formato HHMM
Es.
199708010930=09.-
30 del 1oagosto
1997mesval-
period
geoname ''GEO'' ! 2{DIGIT}2 Identificazione di
una posizione
geografica espressa
in latitudine e
longitudine.geoid
heading 3{DIGIT}3 Numero di tre cifre
compreso tra 001 e
360.ahead2000R2082 — IT — 15.06.2002 — 001.001 — 98
▼B
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
icaoaerodrome 4{ ALPHA }4 Identificatore ICAO
di aerodromo, in
quattro cifre.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Forma jolly di
icaoaerodrome, da
utilizzare nei
messaggi di interro-
gazione:
«?» sostituisce un
carattere
«+» sostituisce
qualsiasi stringa di
caratteri.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3Identificatore ICAO
del tipo di aeromo-
bile.arctyp
icaomsg { CHARACTER } Messaggio ICAO.
(conforme alla
sintassi descritta nel
rif. {4})msgtxt
ifpuid 1{ ALPHANUM } Identificatore di
un'unità IFPS.ifpuresp
latitudelong 6{ DIGIT }6 Latitudine espressa
in sei cifre.lattd
latitudeside 'N' | 'S' Indicatore di latitu-
dine nord o sud.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4Indicatore ICAO del
tipo di cinture di
salvataggio presenti
a bordo.
Può contenere uno o
più caratteri tra
quelli specificati, in
qualsiasi ordine ma
senza ripetizioni.splj
longitudelong 7{ DIGIT }7 Longitudine
espressa in sette
cifre.longtd
longitudeside 'E' | 'W' Indicatore di longi-
tudine est o ovest.longtd
machnumber 'M' ! 3{ DIGIT }3 Numero di Mach. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Indicazione del tipo
di modifica appor-
tata ad un campo.ifpsmod
month ('0' | '1' ) ! DIGIT Mese espresso in
due cifre.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Indicazione dei
giorni della setti-
mana in cui si
applica un RPL.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Indicazione dei
giorni della setti-
mana in cui si
applica un RPL. È
ammesso l'uso dei
caratteri jolly.daysk2000R2082 — IT — 15.06.2002 — 001.001 — 99
▼B
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
originatorid 1{ ALPHANUM
}10Identificatore dell'o-
riginatore del
messaggio.orgnid
qrorgn
point 2{ ALPHANUM }5 Identificatore di un
punto significativo.
Può essere un punto
pubblicato, un punto
geografico, un
punto di riferimento
o un punto artifi-
ciale come un punto
«ridenominato»
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Valore del rileva-
mento di riferi-
mento.brng
refname "REF" ! 2{DIGIT}2 Identificatore attri-
buito ad un punto
espresso come rile-
vamento e distanza
da un punto pubbli-
cato.refid
regulid 1{ ALPHANUM
}20Identificazione di
una misura ATFM
applicabile ad un
volo.regul regid
renameid "REN" !
2{DIGIT}2Identificatore di un
punto ridenominato.renid
rrteid 1{ ALPHANUM}
20Identificatore di un
reinstradamento.rrteref
rtf 6{DIGIT}6 Radiofrequenza
espressa in MHz
fino al terzo deci-
male.freq
rulechg 'VFR' | 'IFR' Indicatori utilizzati
nella descrizione di
rotta per segnalare
un cambiamento
delle regole del
volo.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSecondi (due cifre
00-59).eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Velocità, espressa
come «K» o »N»
seguita da quattro
cifre.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 Identificatore ICAO
dell'apparato SSR
presente a bordo e,
facoltativamente,
indicazione del
collegamento dati.seqpt
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Identificatore del
periodo di «perma-
nenza», un periodo
di «attività
speciale» nella
descrizione di rotta
di un volo.ptstay
stayident2000R2082 — IT — 15.06.2002 — 001.001 — 100
▼B
Termine ausi-
liareSintassi SemanticaUsato in
campo
primarioUsato in
sotto-
campoUsato in
elemento
ausiliare
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4Identificatore ICAO
dell'equipaggia-
mento di sopravvi-
venza presente a
bordo. Può conte-
nere uno o più
caratteri tra quelli
specificati, in qual-
siasi ordine ma
senza ripetizioni.spls
text20 1{ LIM_CHAR }20 Testo composto da
un numero di carat-
teri compreso tra 1
e 20, ad esclusione
del carattere trat-
tino.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITOra del giorno o
durata, espressa in
ore (2 cifre 00-23) e
minuti (2 cifre 00-
59).aobt
ata
atd
atot
cobt
ctot
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitimecto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_ela-
psedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITNumero illimitato di
ore e minuti, usato
per indicare durate.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Forma jolly di
timehhmm.eobtk
titleid 1{ ALPHA }10 Titolo di messaggio
ADEXP valido.
(cfr. allegato B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' Identificatore ICAO
di categoria di
turbolenza di scia.wktrc
year 2{ DIGIT }2 Ultime due cifre
dell'anno.date
fulldate2000R2082 — IT — 15.06.2002 — 001.001 — 101
▼B
A.3.CampiprimariADEXP
Campo
primario
ADEXPTipo Sintassi Semantica
ad c '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Identificatore di aerodromo. Nei
casi in cui l'aerodromo è parte
integrante della descrizione di rotta,
possono essere fornite informazioni
aggiuntive sull'instradamento.
ada b '-' "ADA" date Data effettiva di arrivo.
adarr b '-' "ADARR" (icaoaerodrome |
'ZZZZ')Aerodromo effettivo di arrivo.
adarrzb '-' "ADARRZ" text20 Nome dell'aerodromo effettivo di
arrivo se non esiste un indicatore di
località ICAO.
add b '-' "ADD" date Data effettiva di partenza.
addr c '-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Elenco di destinatari.
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')Indicatore di località ICAO dell'ae-
rodromo di partenza, o indicazione
«AFIL» per un piano di volo
trasmesso durante il volo o gruppo
«ZZZZ» se all'aerodromo di
partenza non è assegnato un indi-
catore di località ICAO.
adepk b '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Aerodromo di partenza usato come
chiave di database in un'interroga-
zione. È ammesso l'uso di caratteri
jolly. Può trattarsi di un indicatore
di località ICAO o dell'indicazione
«AFIL» per un piano di volo
trasmesso durante il volo o del
gruppo «ZZZZ» se all'aerodromo di
partenza non è assegnato un indi-
catore di località ICAO o di una
combinazione di caratteri alfabetici
e caratteri jolly.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')Aerodromo di partenza «prece-
dente». Può trattarsi dell'indicatore
di località ICAO o dell'indicazione
«AFIL» per un piano di volo
trasmesso durante il volo o del
gruppo «ZZZZ» se all'aerodromo di
partenza non è assegnato un indi-
catore di località ICAO.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')Indicatore di località ICAO dell'ae-
rodromo di destinazione o gruppo
«ZZZZ» se all'aerodromo di desti-
nazione non è assegnato un indica-
tore di località ICAO.
adesk b '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Aerodromo di destinazione usato
come chiave di database in un'in-
terrogazione. È ammesso l'uso di
caratteri jolly.
Può trattarsi dell'indicatore di
località ICAO o del gruppo
«ZZZZ» se all'aerodromo di desti-
nazione non è assegnato un indica-
tore di località ICAO o di una
combinazione di caratteri alfabetici
e caratteri jolly.
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')Aerodromo di destinazione «prece-
dente». Può trattarsi dell'indicatore
di località ICAO o del gruppo
«ZZZZ» se all'aerodromo di desti-
nazione non è assegnato un indica-
tore di località ICAO.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Contiene un messaggio ADEXP.2000R2082 — IT — 15.06.2002 — 001.001 — 102
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
afildata c '-' "AFILDATA" ptid fl eto Dati stimati per un piano di volo
trasmesso durante il volo: identifi-
cazione di un punto, livello di volo
di entrata e data-orario stimati sul
punto.
NOTA: Il livello di volo indicato è
la quota a cui il volo è autorizzato
a entrare nello spazio aereo
controllato sopra il punto indicato.
Non corrisponde necessariamente
all'RFL.
ahead b '-' "AHEAD" (heading | "ZZZ") Prua assegnata ad un volo, espressa
in gradi.
Deve essere un numero di tre cifre
o il gruppo «ZZZ» se non è stata
assegnata alcuna prua.
altnzb '-' "ALTNZ" text20 Nome dell'aerodromo alternato se
non esiste un indicatore di località
ICAO.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')Indicatore di località ICAO del
primo aerodromo alternato di desti-
nazione o gruppo «ZZZZ» se
all'aerodromo non è assegnato un
indicatore di località ICAO.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')Indicatore di località ICAO del
secondo aerodromo alternato di
destinazione o gruppo «ZZZZ» se
all'aerodromo non è assegnato un
indicatore di località ICAO.
aobd b '-' "AOBD" date Data effettiva di inizio rullaggio.
aobt b '-' "AOBT" timehhmm Orario effettivo di inizio rullaggio.
arcid b '-' "ARCID" aircraftid Identificazione dell'aeromobile.
Può trattarsi delle marche di
immatricolazione dell'aeromobile, o
dell'identificatore ICAO dell'eser-
cente di aeromobili seguito dall'i-
dentificatore del volo.
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Identificazione dell'aeromobile
usata come chiave di database in
un'interrogazione; è ammesso l'uso
di caratteri jolly.
Deve essere una combinazione di
caratteri alfanumerici e caratteri
jolly fino ad un massimo di 7
caratteri in tutto.
arcidold b '-' ARCIDOLD aircraftid Identificazione «precedente»
dell'aeromobile. Se si deve modifi-
care l'identificazione dell'aeromo-
bile il nuovo valore è immesso in
«ARCID».
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Tipo di aeromobile (identificazione
ICAO del tipo) o ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")Velocità attualmente assegnata al
volo, in km/ora, nodi o numero di
Mach.
Deve essere espressa come «M»
seguita da tre cifre, «K» o «N»
seguita da quattro cifre o «ZZZ»
per indicare che non esistono
restrizioni per la velocità.
ata b '-' "ATA" timehhmm Orario effettivo di arrivo.
atd b '-' "ATD" timehhmm Orario effettivo di partenza.
atot b '-' "ATOT" timehhmm Orario effettivo di decollo.
atsrt b '-' "ATSRT" atsroute point point Identificatore della rotta ATS e del
primo e dell'ultimo punto.2000R2082 — IT — 15.06.2002 — 001.001 — 103
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Indirizzi di destinazione dei
messaggi ATFM.
ceqpt b '-' "CEQPT" aidequipment Apparati per le comunicazioni
radio ed aiuti per la navigazione e
l'avvicinamento (casella 10 del
piano di volo ICAO).
cfl c '-' "CFL" fl [ptid] Livello di volo autorizzato. Livello
di volo attualmente assegnato
dall'ATC al pilota (numero FL).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointIndicazione di un cambiamento
delle «regole del volo» (VFR/IFR)
o del «tipo di volo» (OAT/GAT) o
di entrambi, e punto in cui avviene
il cambiamento.
cobd b '-' "COBD" date Data calcolata di inizio rullaggio.
cobt b '-' "COBT" timehhmm Orario calcolato di inizio rullaggio.
com b '-' "COM" text20 Apparato di comunicazione (casella
18 COM/ del piano di volo ICAO).
comment b '-' "COMMENT" 1 { LIM_CHAR
}Note generali in testo libero, senza
trattino.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Identificazione di una «condizione
eccezionale» in contesto ATFM.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]Condizioni di trasferimento di
controllo di un volo: identifica-
zione di un punto, livello di volo e
orario stimato sul punto; eventual-
mente, informazioni sul livello di
volo supplementare.
cop b '-' "COP" point Identificatore di punto di coordina-
mento: identificatore codificato di
un punto o designazione artificiale
(GEOxx, RENxx o REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Indicazione di salita con procedura
cruiseclimb: punto d'inizio della
salita, velocità o numero di Mach e
i due livelli di volo che definiscono
lo strato occupato durante la proce-
dura. Se il secondo livello (quota
superiore) non è noto lo si può
sostituire con «PLUS».
cstat c '-' "CSTAT" statid [statreason] Identificatore che conferma il
nuovo status di coordinamento di
un volo ed eventualmente il motivo
del cambiamento.
ctod b '-' "CTOD" date Data calcolata di decollo.ctot b '-' "CTOT" timehhmm Orario calcolato di decollo
(CTOT): orario di riferimento di
uno slot ATFM.
dat b '-' "DAT" datalink Indicazione dei collegamenti dati
presenti a bordo.
days b '-' "DAYS" numdays Giorni di applicazione di un piano
di volo ripetitivo (1234567 dove 1
corrisponde a lunedì, 2 a martedì,
ecc.; 0 nelle colonne dei giorni di
non applicazione).
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Giorni di applicazione di un piano
di volo ripetitivo, usati come
chiave di database in un'interroga-
zione. È ammesso l'uso dei caratteri
jolly.2000R2082 — IT — 15.06.2002 — 001.001 — 104
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
daysold b '-' "DAYSOLD" numdays Giorni di applicazione «prece-
denti», usati come chiave di data-
base. In caso di modifica dei giorni
di applicazione di un RPL i nuovi
valori sono inseriti in «DAYS».
dct b '-' "DCT" point point Indica una rotta diretta tra due
punti. Questi punti possono essere
un identificatore valido o punti
GEOxx, RENxx o REFxx (campi
GEO, REN o REF).
delay b '-' "DELAY" timehhmm Periodo di tempo corrispondente ad
un ritardo. La natura del ritardo (es.
ritardo di un volo, ritardo nell'ela-
borazione, ecc.) dipende dal
contesto.
depzb '-' "DEPZ" text20 Nome dell'aerodromo di partenz a,
se non esiste un indicatore di
località ICAO.
desc b '-' "DESC" 1 {LIM_CHAR} Descrizione di una condizione o di
una entità in rapporto con il conte-
nuto del messaggio.
destzb '-' "DESTZ" text20 Nome dell'aerodromo di destina-
zione, se non esiste un indicatore di
località ICAO.
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedIdentificazione della FIR e tempo
trascorso accumulato (in ore e
minuti) fino al confine della FIR.
eetlat c '-' "EETLAT" lattd time Indicazione del tempo trascorso
fino ad una posizione espressa
esclusivamente in latitudine.
eetlong c '-' "EETLONG" longtd time Indicazione del tempo trascorso
fino ad una posizione espressa
esclusivamente in longitudine.
eetpt b '-' "EETPT" point timehhmm_ela-
psedIdentificatore di un punto e tempo
trascorso accumulato fino al punto.
endtime b '-' "ENDTIME" day ! timehhmm Orario in cui termina un periodo di
tempo.
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]Dati di piano di volo applicabili al
punto indicato o all'entrata nello
spazio aereo in questione. È obbli-
gatoria la presenza del campo
«ptid» o «airspdes», o di entrambi.
eobd b '-' "EOBD" date Data stimata di inizio rullaggio.eobdk b '-' "EOBDK" date Data stimata di inizio rullaggio
utilizzata come chiave di database
in un'interrogazione. È ammesso
l'uso di caratteri jolly. Deve essere
una combinazione di cifre e carat-
teri jolly, fino ad un massimo di 6
caratteri in tutto.
eobdold b '-' "EOBDOLD" date Data stimata di inizio rullaggio
«precedente», utilizzata come
chiave di database. In caso di
modifica della data stimata di
inizio rullaggio il nuovo valore è
immesso in «EOBD».
eobt b '-' "EOBT" timehhmm Orario stimato di inizio rullaggio
(EOBT)
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Orario stimato di inizio rullaggio
utilizzato come chiave di database
in un'interrogazione. È ammesso
l'uso di caratteri jolly.2000R2082 — IT — 15.06.2002 — 001.001 — 105
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
eobtold b '-' "EOBTOLD" timehhmm Orario stimato di inizio rullaggio
«precedente», utilizzato come
chiave di database. In caso di
modifica della data stimata di
inizio rullaggio il nuovo valore è
immesso in «EOBT».
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Elenco di codici della capacità
dell'apparecchiatura, seguito
ciascuno da un valore di stato che
indica la capacità in quel momento
errfield b '-' "ERRFIELD" fieldid Nome ADEXP di campo/i erroneo/
i.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Testo del messaggio d'errore. Può
eventualmente contenere un codice
d'identificazione di errore.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Dati stimati. Identificazione di un
punto, livello di volo stimato
(numero FL) e data-orario stimati
sul punto; eventualmente, livello divolo supplementare (numero FL
seguito dall'identificatore A o B).
etod b '-' "ETOD" date Data stimata di decollo.etot b '-' "ETOT timehhmm Orario stimato di decollo.
extaddr c '-'"EXTADDR" num | { fac } |
(num {fac})Indirizzi forniti oltre a quelli deter-
minati automaticamente, cioè
«indirizzi supplementari». Può
contenere solo il numero di indi-
rizzi o gli indirizzi veri e propri, o
entrambe le informazioni.
filrte b '-' "FILRTE" {LIM_CHAR} Descrizione della rotta esattamente
come è presentata, cioè senza
elaborazione.
filtim b '-' "FILTIM" day ! timehhmm Gruppo data-orario che specifica
quando è stato presentato il
messaggio per essere trasmesso.
flband c '-' "FLBAND" fl fl Strato che definisce lo spazio aereo
in senso verticale, livelli di volo
indicati inclusi.
fltrul b '-' "FLTRUL" flightrule Regole del volo (casella 8 del
piano di volo ICAO).
flttyp b '-' "FLTTYP" flighttype Tipo di volo (casella 8 del piano di
volo ICAO).
fmp b '-' "FMP" 4{ ALPHA }4 Identificatore di «posizione di
gestione del flusso del traffico»
(FMP).
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Elenco delle FMP e delle misure
ATFM associate.
freq b '-' "FREQ" rtf Radiofrequenza.
fstday b '-' "FSTDAY" date Primo giorno di applicazione di un
piano di volo ripetitivo, utilizzato
per indicare il giorno effettivo a
partire dal quale verranno generati
piani di volo sulla base di un RPL
(cfr. campo valfrom) o a partire dal
quale si applica una modifica di un
RPL.2000R2082 — IT — 15.06.2002 — 001.001 — 106
▼M1
▼B
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
furthrte b '-' "FURTHRTE" {LIM_CHAR} Ulteriore instradamento di un volo.
Da utilizzare nei messaggi che
contengono stimati per indicare
l'instradamento successivo al punto
stimato. Il messaggio può indicare
solo il punto successivo o l'instra-
damento successivo completo finoa destinazione.
geo c '-' "GEO" geoid lattd longtd Punto lungo una rotta definito in
latitudine e longitudine e indicato
nel piano di volo come GEOxx
(dove xx corrisponde ad un numero
progressivo).
ifp b '-' "IFP" 1{ALPHA} Indicazione degli errori noti in un
FPL.
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong} '-' "END" "IFPDLIST"Elenco di IFPD completi corri-
spondenti alla chiave di database
indicata in un messaggio di inter-
rogazione.
Contiene un elenco di informazioni
complete per ogni volo singolo
corrispondenti alle chiavi di inter-
rogazione specificate.
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Elenco di ifpdsum corrispondenti
alla chiave di database indicata in
un messaggio di interrogazione.
Contiene un elenco di informazioni
riassuntive per ogni volo singolo
corrispondenti alle chiavi di inter-
rogazione specificate.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8Identificatore univoco di piano di
volo, assegnato dall'IFPS.
ifpsmod b '-' "IFPSMOD" fieldid modifind Indicazione fornita dall'IFPS
riguardante i campi modificati e la
natura dei cambiamenti.
ifpuresp b '-' "IFPURESP" ifpuid Identificatore dell'IFPU responsa-
bile di un'interrogazione. Deve
elaborare l'interrogazione e rispon-
dervi.
ignore c '-' "BEGIN" "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
"END" "IGNORE"Indicazione di condizioni che sono
state «ignorate» o aggirate nell'ela-
borazione del messaggio in
questione. Una condizione «igno-
rata» può essere limitata ad un
tratto specifico della rotta definito
dai punti indicati. Una condizione
può essere, ad esempio, una restri-
zione oraria (condizione d'accesso
a una rotta), una restrizione di
livello di volo o una violazione del
TOS.
iobd b '-' "IOBD" date Data «iniziale» di inizio rullaggio:
«data di inizio rullaggio» indicata
nell'FPL e aggiornata attraverso i
messaggi di piano di volo associati
(DLA, CHG, ecc.). È la data di
riferimento usata per accedere al
piano di volo nel database, ed è
l'unica «data di inizio rullaggio»
conosciuta dagli enti ATS interes-
sati.
Nota: la IOBD non è modificata
dalle variazioni richieste o notifi-
cate attraverso lo scambio di
messaggi ATFM.2000R2082 — IT — 15.06.2002 — 001.001 — 107
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
iobt b '-' "IOBT" timehhmm Orario «iniziale» di inizio
rullaggio: «orario di inizio
rullaggio» indicato nell'FPL e
aggiornato attraverso i messaggi di
piano di volo associati (DLA,
CHG, ecc.). È l'orario di riferi-
mento usato per accedere al piano
di volo nel database, ed è l'unico
«orario di inizio rullaggio» cono-
sciuto dagli enti ATS interessati.
Nota: l'IOBT non è modificato
dalle variazioni richieste o notifi-
cate attraverso lo scambio di
messaggi ATFM.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Elenco di rotte attive sotto condi-
zione.
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Elenco di zone temporaneamente
riservate attive.
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Elenco di rotte ATS chiuse.
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Elenco di FIR, comprendente il
nome della regione seguito dall'e-
lenco di rotte sotto condizione
disponibili o dagli elenchi seguenti:
rotte sotto condizione disponibili,
rotte ATS chiuse, zone tempora-
neamente riservate attive, restri-
zioni ridotte dello spazio aereo e
spazi aerei a coordinamento ridotto.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Elenco di restrizioni ridotte dello
spazio aereo.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Elenco di aree a coordinamento
ridotto.
lstday b '-' "LSTDAY" date Ultimo giorno di applicazione di un
piano di volo ripetitivo. Usato per
indicare l'ultimo giorno effettivo in
cui sono generati piani di volo in
base ad un RPL (cfr. campo
valuntil) o l'ultimo giorno di appli-
cazione di una modifica dell'RPL.
=> Deve essere una data compresa
tra VALFROM e VALUNTIL.
mach b '-' "MACH" machnumber [ point ] Numero di Mach, in centesimi di
unità, e facoltativamente punto in
cui deve avvenire il cambiamento.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimePeriodo di validità di un
messaggio, orari indicati inclusi.
minlineup b '-' "MINLINEUP" timehhmm Tempo minimo richiesto affinché
un volo, dichiaratosi pronto alla
partenza, passi dalla posizione
d'attesa al volo.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Numero di modifiche che sono
state necessarie per correggere il
messaggio iniziale.
msgref c '-' "MSGREF" sender recvr
seqnumDati di riferimento per i messaggi
associati trasmessi precedente-
mente.2000R2082 — IT — 15.06.2002 — 001.001 — 108
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Contiene il riassunto di un
messaggio.
Nota: deve contenere uno o più*
campi tra i seguenti: arcid, adep,
ades, eobt e orgn ma senza ripeti-
zione.
* uno o più di questi campi
possono essere mancanti o mutilati
nel messaggio ricevuto
msgtxt b '-' "MSGTXT" icaomsg Contiene un messaggio ICAO
completo.
msgtyp b '-' "MSGTYP" titleid Contiene il titolo del messaggio a
cui si fa riferimento o del
messaggio riprodotto.
Può essere qualsiasi titolo di
messaggio ADEXP valido (cfr.
allegato B).
nav b '-' "NAV" text20 Equipaggiamento di navigazione
significativo (casella 18 NAV/ del
piano di volo ICAO).
nbarc b '-' "NBARC" 1{ DIGIT }2 Numero di aeromobili, se superiore
a uno.
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Numero di dati di piano di volo
corrispondenti ad un'interrogazione.
Deve essere un valore compreso tra
0 e 999.
newctot b '-' "NEWCTOT" timehhmm Nuovo orario calcolato di decollo,
così come aggiornato dal TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmNuovo orario in cui termina un
periodo di tempo.
neweobd b '-' "NEWEOBD" date Nuova data stimata di inizio
rullaggio.
neweobt b '-' "NEWEOBT" timehhmm Nuovo orario stimato di inizio
rullaggio.
newptot b '-' "NEWPTOT" timehhmm Nuovo orario provvisorio di
decollo.
newrte b '-' "NEWRTE" { LIM_CHAR } Nuova rotta tra gli stessi aerodromi
di partenza ed arrivo del messaggio
iniziale.
newstart-
timeb -' "NEWSTARTTIME" day !
timehhmmNuovo orario in cui inizia un
periodo di tempo.
oldmsg b '-' "OLDMSG" { CHARACTER } Messaggio originario completo,
esattamente così come ricevuto (e
nello stesso formato).
opr b '-' "OPR" 1 { LIM_CHAR } Nome della compagnia o dell'orga-
nizzazione esercente il volo
(casella 18, OPR/ del piano di volo
ICAO).
orgmsg b '-' "ORGMSG" titleid Titolo ADEXP di un messaggio
erroneo, così come ricevuto dal
TACT.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Indirizzo dell'originatore di un
messaggio.
orgnid b '-' "ORGNID" originatorid Identificatore di un destinatario che
ha originato un messaggio.
orgrte b '-' "ORGRTE" { LIM_CHAR } Rotta originaria tra gli aerodromi di
partenza ed arrivo.
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Informazioni riguardanti l'origina-
tore di un messaggio. Può
comprendere il tipo di rete utiliz-
zato o l'indirizzo, o entrambi gli
elementi.2000R2082 — IT — 15.06.2002 — 001.001 — 109
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
origindt b '-' "ORIGINDT" datetime Data e orario di ricevimento del
messaggio originario da parte
dell'IFPS.
Nota: non è l'orario di trasmissione
del messaggio.
Formato: AAMMGGHHMM.
part c '-' "PART" num lastnum Identificazione della parte del
messaggio identificata da titolo,
orario di trasmissione e periodo di
validità.
per b '-' "PER" text20 Dati sulle prestazioni dell'aeromo-
bile (casella 18 PER/ del piano di
volo ICAO).
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Posizione di un aeromobile
espressa come un punto o un aero-
dromo, eventualmente completata
dall'orario e dal livello di volo.
prevarcid b '-' "PREVARCID" aircraftid Indicativo di chiamata precedente
utilizzato.
prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4Modo e codice SSR usati dal volo
immediatamente prima del modo e
del codice SSR specificati nel
campo «-SSRCODE».
propfl c '-' "PROPFL" tfl [sfl] Livello di volo proposto da un ente
accettante per il trasferimento di
controllo di un volo.
ptot b '-' "PTOT" timehhmm Orario provvisorio di decollo.
Orario provvisorio di riferimento
per uno slot ATFM.
qrorgn b '-' "QRORGN" originatorid Identificatore dell'originatore
dell'interrogazione.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Nome dell'aerodromo o degli aero-
dromi alternati in rotta.
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Rateo di variazione di quota: rateo
di salita o discesa assegnato ad un
aeromobile, espresso in centinaia di
piedi al minuto.
=> è obbligatorio indicare «C» per
un rateo di salita o «D» per un
rateo di discesa, seguita da un
numero di due cifre corrispondente
al rateo assegnato in centinaia di
piedi al minuto. Si può utilizzare il
gruppo «ZZZ» per indicare
l'assenza di un rateo di salita o
discesa assegnato.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Elenco di periodi e dei rispettivi
ratei di flusso per una condizione
ATFM.
reason b '-' "REASON" 4{ALPHA}12 Motivo del rigetto di un messaggio
o dell'annullamento di uno slot da
parte del TACT.
Le informazioni a supporto del
messaggio dipendono dal contesto.
ref c '-' "REF" refid ptid brng distnc Punto lungo una rotta definito in
termini di rilevamento magnetico e
distanza da un altro punto e desi-
gnato mediante l'indicativo REFxx.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumDati di riferimento per il messaggio
in trasmissione.
reg b '-' "REG" 1{ LIM_CHAR }7 Marche di immatricolazione
(casella 18 REG/ del piano di volo
ICAO).2000R2082 — IT — 15.06.2002 — 001.001 — 110
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Località di riferimento per una
misura ATFM.
regul b '-' "REGUL" regulid Identificatore di una misura appli-
cabile ad un volo.
rejctot b '-' "REJCTOT" timehhmm Orario calcolato di decollo riget-
tato: risposta negativa ad una
proposta di miglioramento di slot.
release b '-' "RELEASE" 1{ALPHA}1 Indicazione che segnala che il volo
è rilasciato (trasferito) dal control-
lore trasferente al controllore rice-
vente:
C = rilasciato per la salita
D = rilasciato per la discesa
T = rilasciato per la virata
F = rilasciato per tutte le manovre
rename c '-' "RENAME" renid ptid Indicazione di una nuova denomi-
nazione temporanea attribuita ad un
«punto significativo» che compare
più di una volta nella descrizione di
rotta, allo scopo di evitare confu-
sione. La denominazione tempo-
ranea ha il solo scopo di rendere
più chiara la rappresentazione della
rotta e non implica una modifica
effettiva dell'identificazione reale
del punto.
respby b '-' "RESPBY" timehhmm Risposta richiesta entro: orario
entro il quale deve essere data una
risposta ad una proposta di miglio-
ramento di slot.
rfl b '-' "RFL" flightlevel [point] Livello di volo richiesto (numero
FL, decine di metri o centinaia di
piedi) ed eventualmente punto in
cui è richiesto un cambiamento
dell'RFL.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Identificatore di piano di volo
sostitutivo (RFP).
Indicazione obbligatoria: «Q»
seguita da una cifra (1 - 9).
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Elenco di RFPD completi corri-
spondenti alle chiavi di database
indicate in un'interrogazione.
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Elenco di rfpdsum (dati RFPD
riassuntivi) corrispondenti alle
chiavi di database indicate in
un'interrogazione.
rif b '-' "RIF 4{LIM_CHAR} Nuova rotta condizionata ad auto-
rizzazione in volo; termina con
l'indicativo ICAO del nuovo aero-
dromo di destinazione.
rmk b '-' "RMK" 1{ LIM_CHAR } Osservazioni in chiaro (casella 18
RMK/ del piano di volo ICAO).
route b '-' "ROUTE" {LIM_CHAR} Tutte le informazioni che figurano
nella casella 15 del piano di volo
ICAO: velocità, RFL e rotta
(conformemente alla sintassi indi-
cata nel rif. 4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockDescrizione di un flusso di traffico
da reinstradare.
rrteref b '-' "RRTEREF" rrteid Riferimento del reinstradamento.
rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockDescrizione di un flusso verso il
quale reinstradare il traffico.2000R2082 — IT — 15.06.2002 — 001.001 — 111
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Elenco di punti di punti in rotta;
può contenere anche un identifica-
tore di aerodromo.
rvr b '-' "RVR" 1{ DIGIT }3 Portata visuale di pista (RVR);
minime richieste in presenza di
condizioni meteorologiche partico-
lari. Espressa in metri.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Elenco di periodi di tempo e rela-
tive minime RVR applicabili.
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitPeriodo di tempo in cui sono
applicabili le minime RVR specifi-
cate.
sector b '-' "SECTOR" 1{ ALPHANUM }8 Identificazione di un settore ATC.sel b '-' "SEL" 4{ ALPHA }5 Codice SELCAL (casella 18 «SEL/
» del piano di volo ICAO).
sendto c '-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"Elenco degli enti di navigazione
aerea destinatari di un messaggio.
seqpt b '-' "SEQPT" ssrequipment Equipaggiamento di sorveglianza
(casella 10 del piano di volo
ICAO).
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Identificatore di una procedura di
partenza strumentale standard.
speed b '-' "SPEED" spd [ point ] Velocità vera all'aria (in km/h o
nodi) e, facoltativamente, punto in
cui è richiesto un cambiamento di
velocità.
spla b '-' "SPLA" 1{ LIM_CHAR }50 Colore e segni distintivi dell'aero-
mobile (casella 19, «A/», del piano
di volo ICAO)
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Contatto per l'ottenimento di dati
supplementari di piano di volo.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Nome del pilota comandante
dell'aeromobile (casella 19, «C/»,
del piano di volo ICAO).
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Canotti: capacità totale (casella 19,
«D/», del piano di volo ICAO).
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Canotti: colore (casella 19, «D/»,
del piano di volo ICAO).
spldcov b '-' "SPLDCOV" ('T' | 'F') Canotti: indicazione che precisa se
sono coperti (casella 19, «D/», del
piano di volo ICAO).
T = («True») = vero (=> »C» nel
piano di volo ICAO)
F = («False») = falso, non coperti.
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Canotti: numero (casella 19, «D/»,
del piano di volo ICAO).
sple b '-' "SPLE" timehhmm_elapsed Autonomia (casella 19, «E/», del
piano di volo ICAO).
splj b '-' "SPLJ" lifejackets Cinture di salvataggio (casella 19,
«J/», del piano di volo ICAO).
spln b '-' "SPLN" 1{ LIM_CHAR } Altro equipaggiamento di sopravvi-
venza e osservazioni utili (casella
19, «N/», del piano di volo ICAO).
splp b '-' "SPLP" 1{DIGIT}3 Numero di persone a bordo (casella
19, «P/», del piano di volo ICAO).
splr b '-' "SPLR" emergradio Apparato radio di emergenza
(casella 19, «R/», del piano di volo
ICAO).2000R2082 — IT — 15.06.2002 — 001.001 — 112
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
spls b '-' "SPLS" survivaleqpt Equipaggiamento di sopravvivenza
(casella 19, «S/», del piano di volo
ICAO).
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Indicazione della fonte di dati. Il
contenuto dipende dal campo
TITLE.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)- Modo e codice SSR (casella 7, b
e c, del piano di volo ICAO).
oppure
- lettere «REQ» per indicare che il
codice è richiesto.
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Identificazione di una procedura di
arrivo strumentale standard.
starttime b '-' "STARTTIME" day !
timehhmmOrario in cui inizia un periodo di
tempo.
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Indicazione, nella descrizione di
rotta, di un periodo di «attività
speciale» in cui l'aeromobile
«permarrà» nell'area definita dai
punti e/o dagli aerodromi specifi-
cati per il lasso di tempo indicato
(addestramento, rifornimento in
volo, missione fotografica, ecc.)
NOTA: l'ordine in cui sono indicati
i punti e/o gli aerodromi è signifi-
cativo.
stayinfo c '-' "STAYINFO" stayident remark Informazioni relative al tipo di
attività (addestramento, missione
fotografica, ecc.) che deve essere
eseguita durante un periodo di
«permanenza» previsto nella rotta.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Motivo del trattamento particolare
(casella 18, STS/, del piano di volo
ICAO). Valori possibili:
«PROTECTED» (per indicare un
trattamento sensibile), codici uffi-
ciali (EMER, HOSP, ecc.) o testo
libero.
taxitime b '-' "TAXITIME" timehhmm Differenza tra l'«orario di inizio
rullaggio» e l'«orario di decollo».
Gli orari indicati possono essere
effettivi o stimati, a seconda delcontesto.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Identificazione di un volume di
traffico.
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockDescrizione di un volume di traf-
fico.
title b '-' "TITLE" titleid Titolo del messaggio.ttleet b '-' "TTLEET" timehhmm_elapsed Tempo totale trascorso stimato, in
ore e minuti.
typzb '-' "TYPZ" text20 Tipo di aeromobile, in assenz a di
un codice ICAO.
unit c '-' "UNIT" unitid [addrinfo] Informazioni relative ad un ente di
navigazione aerea: ente ATC, eser-
cente di aeromobili o originatore di
un piano di volo. Contiene l'identi-
ficazione dell'ente seguita even-
tualmente dal suo indirizzo.
valfrom b '-' "VALFROM" date Prima data in cui è programmato il
volo (anno, mese e giorno).2000R2082 — IT — 15.06.2002 — 001.001 — 113
▼B
Campo
primario
ADEXPTipo Sintassi Semantica
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Prima data in cui è programmato il
volo, usata come chiave di database
in un'interrogazione. È ammesso
l'uso di caratteri jolly.
Deve trattarsi di una data valida o
di una combinazione data valida-
caratteri jolly.
valfromold b '-' "VALFROMOLD" date Data «valfrom»«precedente», usata
come chiave di database. In caso di
modifica della data d'inizio di
validità il nuovo valore è immesso
in «VALFROM».
validitydate b '-' "VALIDITYDATE" date Data di validità.
valuntil b '-' "VALUNTIL" date Ultima data in cui è programmato
il volo (anno, mese e giorno).
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Ultima data in cui è programmato
il volo, usata come chiave di data-
base in un'interrogazione. È
ammesso l'uso di caratteri jolly.
Deve trattarsi di una data valida o
di una combinazione data valida-
caratteri jolly.
valuntilold b '-' "VALUNTILOLD" date Data «valuntil»«precedente», usata
come chiave di database. In caso di
modifica dell'ultima data di validità
il nuovo valore è immesso in
«VALUNTIL».
wktrc b '-' "WKTRC" waketurbcat Categoria di turbolenza di scia.
A.4.SottocampiADEXP
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
addrinfo c '-' "ADDRINFO"
networktype facIndirizzo unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'Identificatore di aero-
dromo: indicatore di
località ICAO o
«ZZZZ» in assenza
di un identificatore di
località.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Descrizione integrale
o parziale di una
rotta ATS in un
periodo specificato.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Descrizione integrale
o parziale di uno
spazio aereo in un
periodo specificato.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Designa uno spazio
aereo diverso da una
rotta ATS.entrydata airspace
brng b '-' "BRNG" refbea-
ringRilevamento di un
punto da un aiuto alla
navigazione in gradi
magnetici.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Tipo di condizione o
di restrizione, es.
TOS, restrizione di
FL.ignore2000R2082 — IT — 15.06.2002 — 001.001 — 114
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
crfl1 b '-' "CRFL1" fligh-
tlevelLimite inferiore dello
strato entro cui deve
avvenire una salita
«cruiseclimb».crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (fligh-
tlevel | "PLUS")Limite superiore
dello strato entro cui
deve avvenire una
salita «cruiseclimb»;
se il limite superiore
non è noto lo si può
sostituire con
«PLUS».crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberNumero di Mach da
mantenere durante la
salita «cruiseclimb».crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd Velocità da mante-
nere durante la salita
«cruiseclimb».crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Orario calcolato su
un punto.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Distanza di un punto
da un aiuto alla navi-
gazione in miglia
nautiche.
Da 1 a 3 cifre, possi-
bilmente precedute
da zero.ref
efl b '-' "EFL" flightlevel Livello di volo
stimato.Reserved
for future
use.
endreg b '-' "ENDREG" day!ti-
mehhmmOrario in cui finisce
una misura ATFM.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusCodice della capacità
dell'apparecchiatura,
seguito da una valore
di stato che indica la
capacità in quel
momentoeqcst
eto b '-' "ETO" date !
timehhmm ! secondsOrario stimato su un
punto: anno, mese,
giorno, ore, minuti e
secondi.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]«Condizione eccezio-
nale» nel contesto
ATFM, es. nebbia
presso un aerodromo.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Dati di indirizza-
mento.addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Designa una FIR o
una UIR.lfir
fl b '-' " FL" flightlevel Campo generico rela-
tivo al livello di volo.
Può essere «SFL»,
«EFL», «CFL»,
«RFL», ecc. a
seconda del contesto.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt2000R2082 — IT — 15.06.2002 — 001.001 — 115
▼M1
▼B
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
flblock c '-' "FLBLOCK" fl fl Blocco di livelli di
volo che definisce
uno spazio aereo
verticalmente, livelli
specificati inclusi. Un
blocco definito come
situato al di sotto o al
di sopra di un livello
di volo si esprime
rispettivamente come
«dal livello di volo
000 al livello specifi-
cato» o «dal livello
di volo specificato al
livello di volo 999».ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleDescrizione di un
«flusso»: area di
origine, rotte o punti
da sorvolare dall'area
di origine (facolta-
tivo), area di destina-
zione e rotte o punti
da sorvolare fino
all'area di destina-
zione (facoltativo).flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Elenco di flussi di
traffico.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7«Rateo» imposto da
una misura ATFM.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Indicazione del
«ruolo» di un flusso.
EX = escluso
IE = incluso esente
EM = esente
IN = inclusoflow
from b '-' "FROM" day!ti-
mehhmmOrario da cui ha
inizio un periodo di
tempo.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15Posizione da cui ha
inizio una rotta, un
tratto di rotta, un
'sentiero' o un flusso.
Può essere una
regione, un aero-
dromo o un punto
significativo.flow
geoid b '-' "GEOID" geoname Identificatore di un
punto geografico:
«GEO» seguito da un
numero progressivo
(esempio: «GEO12»).geo
ifpdlong c '-' "BEGIN"
"IFPDLONG"
adexpmsg '-' "END"
"IFPDLONG"Informazioni
complete su un piano
di volo singolo.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnInformazioni riassun-
tive su un piano di
volo singolo;
contiene i campi
arcid, adep, ades,
eobt e orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Numero di tre cifre
che indica la fine di
una sequenza.2000R2082 — IT — 15.06.2002 — 001.001 — 116
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitudine in gradi,
minuti, secondi e
direzione (nord o
sud).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitudine in gradi,
minuti secondi e
direzione (est od
ovest).eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Indicazione del tipo
di rete utilizzato per
uno scambio di
messaggi.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Numero di tre cifre. extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7«Rateo d'attesa»,
usato per scopi legati
all'ATFM.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgContiene un
messaggio ADEXP
completo dopo la sua
elaborazione.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgContiene un
messaggio ADEXP
completo prima della
sua elaborazione,
cioè così com'è stato
ricevuto.adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Punto lungo una
rotta.
=> contiene un'iden-
tificazione del punto
e facoltativamente
- un livello di volo o
un blocco di livelli di
volo,
- un livello di volo
supplementare,
- uno o più riferi-
menti orari,
- una salita «cruise-
climb»
- un'indicazione di
instradamento- un'indicazione di
periodo di «attività
speciale» («perma-
nenza» del volo
nell'area per un
determinato periodo
di tempo)
Cambiamento di:
- RFL, regole del
volo, velocità/numero
di Machrtepts
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Indicazione di una
salita «cruiseclimb»
nella descrizione di
rotta: velocità o
numero di Mach,
seguito dai due livelli
di volo che indicano
lo strato occupato
durante la salita. Se il
secondo livello
(quota superiore) non
è noto lo si può
sostituire con
«PLUS».pt2000R2082 — IT — 15.06.2002 — 001.001 — 117
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Indicazione delle
regole del volo appli-
cabili nel punto in
questione.entrydata
ptid b '-' "PTID" point Identificazione di un
punto: indicativo
codificato o designa-
zione artificiale
(GEOxx, REFxx or
RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberNumero di Mach, in
centesimi di unità,
associato ad un punto
lungo la rotta.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Indicazione delle
regole del volo mili-
tari applicabili nel
punto in questione.entrydata
ptrfl b '-' "PTRFL" fligh-
tlevelLivello di volo
richiesto, associato ad
un punto lungo la
rotta.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}Rotta di volo dopo il
punto indicato: può
trattarsi della rotta
completa fino all'ae-
rodromo di destina-
zione o del tratto di
rotta fino al punto
successivo.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgIndicazione di un
cambiamento delle
«regole del volo»
(VFR/IFR) o del
«tipo di volo» (OAT/
GAT) o di entrambi,
associato ad un punto
lungo la rotta.ad pt
ptspeed b '-' "PTSPEED" spd Velocità vera all'aria
(in km/ora o nodi)
associata ad un punto
lungo la rotta.ad
entrydatapt
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmIndicazione, nella
descrizione di rotta
trasmessa, di un
periodo di «attività
speciale» in cui
l'aeromobile
«permarrà» nell'area
definita per il lasso di
tempo indicato
(addestramento, rifor-
nimento in volo, ecc.)ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penratePeriodo di tempo in
cui i ratei di flusso
specificati sono
applicabili per una
misura ATFM.ratepdlst regcond
recvr b '-' "RECVR" fac Ricevente del
messaggio a cui si fa
riferimento.msgref
refdata2000R2082 — IT — 15.06.2002 — 001.001 — 118
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]Identificatore di rotta
ATS e identificatori
del primo e dell'ul-
timo punto. I punti
indicati possono
essere identificativi
ICAO o punti desi-
gnati artificialmente
GEOxx, RENxx or
REFxx. Eventual-
mente può essere
incluso l'identifica-
tore del paese in cuiè situato il punto.
I punti terminali
devono essere
conformi alle infor-
mazioni di rotta.airroute
refid b '-' "REFID" refname Identificatore di un
punto di riferimento:
«REF» seguito da un
numero progressivo
(esempio: «REF02»).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Località di riferi-
mento di una misura
ATFM.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Elenco di periodi di
tempo e dei rispettivi
ratei di flusso per una
misura particolare.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Descrizione di una
misura ATFM.regulation
regid b '-' "REGID" regulid Identificazione di una
«misura» di gestione
del flusso di traffico.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Elenco di «misure»
di gestione del flusso
di traffico.fmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Numero di riferi-
mento per una
«misura» ATFM:
riferimento univoco
seguito da un'indica-
zione di validità.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12Motivo di una misura
ATFM.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]«Misura» imposta per
la gestione del flusso
di traffico.reglist
remark b '-' "REMARK"
1{LIM_CHAR}Osservazione riguar-
dante l'elemento in
questione; questo
campo fa parte della
descrizione di tale
elemento.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identificatore attri-
buito ad un punto che
compare più volte
nella descrizione di
rotta.rename
respunit b '-' "RESPUNIT"
12{ALPHA}12Ente ATC compe-
tente.airspace2000R2082 — IT — 15.06.2002 — 001.001 — 119
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Informazioni
complete riguardanti
un piano di volo
ripetitivo.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilInformazioni riassun-
tive riguardanti un
piano di volo ripeti-
tivo: contiene i campi
arcid, adep, ades,
eobt, orgn, days,
valfrom e valuntil.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Portata visuale di
pista (RVR): minime
operative in presenza
di condizioni meteo-
rologiche particolari.
Espressa in metri.rvrperiod exccond
sender b '-' "SENDER" fac Mittente del
messaggio a cui si fa
riferimento.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Numero progressivo
del messaggio in
trasmissione (numero
di 3 cifre che identi-
fica in modo univoco
la combinazione
mittente/ricevente).msgref
refdata
sfl b '-' SFL flightlevel !
('A'|'B')Livello di volo
supplementare.
Livello di volo al
quale o al di sopra
del quale o al di sotto
del quale un volo è
stato o sarà coordi-
nato per l'attraversa-
mento di un punto. È
costituito da un
numero FL e da una
condizione di attra-
versamento («A» se
l'aeromobile attra-
verserà il punto alla
quota indicata o ad
una quota superiore,
«B» se l'aeromobile
attraverserà il punto
alla quota indicata o
ad una quota infe-
riore).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmOrario in cui entra in
vigore una misura
ATFM.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentIndicazione dello
status di coordina-
mento di un volo.cstat
statreason b '-' "STATREASON"
coorstatusreasonMotivo del cambia-
mento dello status di
coordinamento di un
volo.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentificazione di un
periodo di «attività
speciale» o di una
«permanenza» nella
rotta di un volo.stay
stayinfo2000R2082 — IT — 15.06.2002 — 001.001 — 120
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
sto b '-' "STO" timehhmm
! secondsCampo «orario»
generico che può
contenere l'orario su
un punto o un aero-
dromo. L'orario può
essere stimato, calco-
lato o effettivo, a
seconda del contesto.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Livello di volo di
trasferimento. Livello
di volo (numero) al
quale un volo è stato
o sarà coordinato per
l'attraversamento di
un punto se è in fase
di volo livellato, o
quota autorizzata
verso cui procede il
volo se è in fase di
salita o di discesa al
punto di trasferi-
mento.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identificazione di un
«volume di traffico».rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Indicazione tempo-
rale. Può essere un
orario effettivo o un
periodo di tempo, a
seconda del contesto
del messaggio.stay
to b '-' "TO" timehhmm «Orario su». Campo
generico che può
contenere l'orario su
un punto o un aero-
dromo. L'orario può
essere stimato, calco-
lato o effettivo, a
seconda del contesto.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15Posizione in cui
termina una rotta, un
tratto di rotta, un
«sentiero» o un
flusso. Può trattarsi di
una regione, un aero-
dromo o un punto
significativo.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Identificazione di un
ente di navigazione
aerea, che può essere
un ente ATC, un
esercente di aeromo-
bili o un originatore
di piano di volo.unit
until b '-' "UNTIL" day!ti-
mehhmmOrario in cui termina
un periodo di tempo.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timePeriodo di validità,
ore indicate incluse.airroute
airspace2000R2082 — IT — 15.06.2002 — 001.001 — 121
▼B
Sotto-
campoTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
via1 b '-' "VIA1" 1
{ALPHANUM} 15Punto, rotta ATS o
spazio aereo che
figura o deve figurare
sulla rotta del volo.
Se è richiesta l'indi-
cazione di più di un
elemento, questo
campo contiene il
primo elemento della
sequenza.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Punto, rotta ATS o
spazio aereo che
figura o deve figurare
sulla rotta del volo.
Se è richiesta l'indi-
cazione di più di un
elemento, questo
campo contiene il
secondo elemento
della sequenza.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Punto, rotta ATS o
spazio aereo che
figura o deve figurare
sulla rotta del volo.
Se è richiesta l'indi-
cazione di più di un
elemento, questo
campo contiene il
terzo elemento della
sequenza.flow
via4 b '-' "VIA4" 1
{ALPHANUM} 15Punto, rotta ATS o
spazio aereo che
figura o deve figurare
sulla rotta del volo.
Se è richiesta l'indi-
cazione di più di un
elemento, questo
campo contiene il
quarto elemento della
sequenza.flow2000R2082 — IT — 15.06.2002 — 001.001 — 122
▼B
ALLEGATO B (Normativo)
INDICECENTRALEDEITITOLIDIMESSAGGIOADEXP
Titolo DefinizionePresentato nella
sezione
ABI Messaggio di preavviso di attraversamento di confine E.3
ACK Messaggio di riscontro E.1
ACP Messaggio di accettazione E.5
ACT Messaggio di attivazione E.3
AUP Messaggio di piano d'uso dello spazio aereo E.4
BFD Messaggio di dati di volo fondamentali E.5
CDN Messaggio di coordinamento E.3
CFD Messaggio di modifica dei dati di volo E.5
CNLCOND Messaggio di cancellazione di condizione eccezionale
ATFME.2.3
CNLREG Messaggio di cancellazione di misura ATFM E.2.3
COD Messaggio di assegnazione di codice SSR E.3
COF Messaggio di cambio di frequenza E.3
CRAM Messaggio di disponibilità di rotta sotto condizione E.4
DES Messaggio di eliminazione di sospensione E.2.2
ERR Messaggio di errore E.2.2
EXCOND Messaggio di notifica di condizione eccezionale ATFM E.2.3
FCM Messaggio di conferma di volo E.2.2
FLS Messaggio di sospensione di volo E.2.2
FSA Messaggio di prima attivazione del sistema E.2.3HOP Messaggio di proposta di trasferimento E.3
IACH Messaggio di modifica ATC singola E.1
IAFP Messaggio di proposta di piano di volo ATC singolo E.1
IAPL Messaggio di piano di volo ATC singolo E.1
IARR Messaggio di arrivo singolo E.1
ICHG Messaggio di modifica singola E.1
ICNL Messaggio di cancellazione singola E.1
IDEP Messaggio di partenza singola E.1
IDLA Messaggio di ritardo singolo E.1
IFPL Messaggio di piano di volo singolo E.1
INF Messaggio di informazione E.3
IRPL Piano di volo ripetitivo interno E.1
IRQS Richiesta singola di piano di volo supplementare E.1
ISPL Piano di volo singolo supplementare E.1
LAM Messaggio di riscontro logico E.3, E.5
LRM Messaggio di rigetto logico E.3
MAC Messaggio di abrogazione del coordinamento E.3
MAN In attesa di elaborazione manuale E.1
MAS Messaggio di assunzione manuale delle comunicazioni E.3
MODCOND Messaggio di modifica di condizione eccezionale ATFM E.2.3
MODREG Messaggio di modifica di misura ATFM E.2.3MRA Messaggio di attivazione di rotta obbligatoria E.2.3
MRCNL Messaggio di annullamento di rotta obbligatorio E.2.3
MRMOD Messaggio di modifica di rotta obbligatoria E.2.3
NEWREG Messaggio di notifica di nuova misura ATFM E.2.32000R2082 — IT — 15.06.2002 — 001.001 — 123
▼B
Titolo DefinizionePresentato nella
sezione
NTA Messaggio di non accettazione di traffico E.2.3
NTACNL Messaggio di cancellazione di non accettazione di traffico E.2.3
NTAMOD Messaggio di modifica di non accettazione di traffico E.2.3
OLRA Messaggio di attivazione di rotta alternativa E.2.3
OLRCNL Messaggio di cancellazione di rotta alternativa E.2.3OLRMOD Messaggio di modifica di rotta alternativa E.2.3
PAC Messaggio di attivazione preliminare E.3
RAP Messaggio di proposta di attivazione sottoposta per accetta-
zioneE.3
RCHG Messaggio di modifica di dati di piano di volo ripetitivo E.1
RCNL Messaggio di cancellazione di dati di piano di volo ripeti-
tivoE.1
RDY Pronto alla partenza E.2.2
REJ Messaggio di rigetto E.1
REV Messaggio di revisione E.3
RJC Messaggio di rigetto di coordinamento E.5
RJT Messaggio di rigetto di reinstradamento E.2.2
ROF Messaggio di richiesta di cambio di frequenza E.3
RRP Messaggio di proposta di reinstradamento E.2.2
RRV Messaggio di proposta di revisione sottoposta per accetta-
zioneE.3
SAM Messaggio di assegnazione di slot E.2.2
SBY Messaggio di attesa E.3
SDM Messaggio di dati supplementari E.3
SIP Messaggio di proposta di miglioramento di slot E.2.2
SLC Messaggio di cancellazione di richiesta di slot E.2.2
SMM Messaggio di slot mancato E.2.2
SPA Messaggio di accettazione di proposta di slot E.2.2
SRJ Messaggio di rigetto di proposta di slot E.2.2
SRM Messaggio di revisione di slot E.2.2SRR Messaggio di richiesta di revisione di slot E.2.2
TIM Messaggio di avvio del trasferimento E.3
UUP Messaggio di aggiornamento di piano d'uso dello spazio
aereoE.4
XAP Messaggio di proposta alternativa di attraversamento E.5
XCM Messaggio di cancellazione di attraversamento E.5
XIN Messaggio di notifica di intenzione di attraversamento E.5
XRQ Messaggio di richiesta di attraversamento E.52000R2082 — IT — 15.06.2002 — 001.001 — 124
▼B
ALLEGATO C (Normativo)
INDICECENTRALEDEITITOLIDIMESSAGGIORISERVATI
C.1.Introduzione
Il presente allegato contiene un indice centrale di titoli di messaggio
riservati non ancora definiti per l'utilizzo in ADEXP. La loro inclusione
nel presente allegato indica che si prevede che verranno utilizzati in
futuro, oppure che sono già utilizzati ma solamente nell'ambito di sistemi
locali.
C.2.Scopo
La compilazione di un elenco di titoli che non sono ancora stati adottati
formalmente per l'utilizzo in ADEXP ha lo scopo di evitare, nella misura
del possibile, i rischi di ridondanza quando è necessario un nuovo titolo
per uno scopo particolare e di impedire l'adozione di un titolo già utiliz-
zato in un sistema locale.
C.3.Titolidimessaggioriservati
Titolo riservato Tipo di messaggio Riservato da
ACTARR Messaggio di attivazione per un arrivo FRANCIA
ACTDEP Messaggio di attivazione per una partenza FRANCIA
ADMFPL Messaggio di piano di volo ADMAR2000 GERMANIA
ADMFPT Messaggio di termine di piano di volo ADMAR2000 GERMANIAADMFPU Messaggio di aggiornamento di piano di volo
ADMAR2000GERMANIA
ANM Messaggio di notifica ATFM CFMU
ANSWERCT Messaggio di risposta (Sistema di controllo terminale) FRANCIA
ANSWM Messaggio di risposta (ODS) FRANCIA
ANSXFPLCT Messaggio di risposta FRANCIA
ATT Messaggio di atterraggio FRANCIA
BEGINPROC Messaggio di inizio di elaborazione FRANCIA
BEGPROC Messaggio di procedura di inizializzazione di posizione
di lavoro di controllore (ODS)FRANCIA
BEGPROCCT Messaggio di inizializzazione di posizione di lavoro di
controllore (Sistema di controllo terminale)FRANCIA
CDA Autorizzazione alla partenza (ARINC 623) FRANCIA
CDAFTX Autorizzazione alla partenza (ARINC 620) FRANCIA
CHGDEP Modifica di un volo in partenza FRANCIA
CLD Autorizzazione alla partenza (ARINC 623) FRANCIA
CLDFTX Autorizzazione alla partenza (ARINC620) FRANCIA
CNLARR Cancellazione di un arrivo FRANCIA
CNLCOND Cancellazione di una condizione eccezionale CFMU
CNLDEP Cancellazione di una partenza FRANCIA
CNLREG Cancellazione di una misura ATFM CFMU
CONFEND Messaggio finale di una modifica di configurazione
operativaFRANCIA
CONFIDM Messaggio di configurazione operativa (ODS) FRANCIA
CONFIDMCT Messaggio di configurazione operativa (Sistema di
controllo terminale)FRANCIA
DEC Messaggio di decollo FRANCIA
DOUBM Messaggio di duplicazione di piano di volo FRANCIA
DRT Messaggio di modifica di destinazione FRANCIA
EATARR Messaggio di aggiornamento dell'orario stimato di
arrivoFRANCIA2000R2082 — IT — 15.06.2002 — 001.001 — 125
▼B
Titolo riservato Tipo di messaggio Riservato da
ENDPROC Ultimo messaggio della procedura di inizializzazione di
posizione di lavoro di controllore (ODS)FRANCIA
ENDPROCCT Ultimo messaggio della procedura di inizializzazione di
posizione di lavoro di controllore (Sistema di controllo
terminale)FRANCIA
EVLARR Messaggio di preattivazione per un arrivo FRANCIA
EVLDEP Messaggio di preattivazione per una partenza FRANCIA
EXCOND Messaggio di attivazione di una condizione eccezionale CFMU
FICM Messaggio di creazione di dati di volo FRANCIA
FLXVIVO Messaggio di visualizzazione di descrizione di «rotta
flessibile»FRANCIA
FPCLOSE Messaggio di chiusura di dati di piano di volo (ODS) FRANCIA
FPCLOSECT Messaggio di chiusura di dati di piano di volo (Sistema
di controllo terminale)FRANCIA
FPCLOSED Messaggio di chiusura di duplicazione di dati di piano
di volo (ODS)FRANCIA
FPCRD Messaggio di attivazione di piano di volo (ODS) FRANCIA
FPCRDCT Messaggio di attivazione di piano di volo (Sistema di
controllo terminale)FRANCIA
FPCRDD Messaggio di duplicazione di attivazione di dati di
piano di volo (ODS)FRANCIA
FPCRE Messaggio di creazione di piano di volo (ODS) FRANCIA
FPCRECT Messaggio di creazione di piano di volo (Sistema di
controllo terminale)FRANCIA
FPINI Messaggio di preattivazione di piano di volo (ODS) FRANCIA
FPINICT Messaggio di preattivazione di piano di volo (Sistema
di controllo terminale)FRANCIA
FPINID Messaggio di duplicazione di preattivazione di piano di
voloFRANCIA
FPNTF Messaggio di preattivazione di piano di volo (ODS) FRANCIA
FPNTFD Messaggio di duplicazione di preattivazione di piano di
volo (ODS)FRANCIA
FPRDU Messaggio di informazione di dati di volo per un
settore non attivo (ODS)FRANCIA
FPRDUCT Messaggio di informazione di dati di volo per un
settore non attivo (Sistema di controllo terminale)FRANCIA
FSM Messaggio di sistema di autorizzazione alla partenza
(ARINC 623)FRANCIA
FSMFTX Messaggio di sistema di autorizzazione alla partenza
(ARINC 620)FRANCIA
FSR Messaggio di richiesta di sospensione di volo CFMU
IACHD Messaggio di modifica ATC singola GERMANIAICHGD Messaggio di modifica singola GERMANIA
IDEPD Messaggio di partenza singola GERMANIA
IDLAD Messaggio di ritardo singolo GERMANIA
IFPDQ Messaggio di interrogazione di dati di piano di volo
singoloCFMU
IFPDQR Messaggio di risposta ad interrogazione di dati di piano
di volo singoloCFMU
IFPDSQ Messaggio di interrogazione di dati riassuntivi di piano
di volo singoloCFMU
IFPDSQR Messaggio di risposta ad interrogazione di dati riassun-
tivi di piano di voloCFMU
IFPLD Piano di volo singolo GERMANIA
INFOM Messaggio di informazioni FRANCIA2000R2082 — IT — 15.06.2002 — 001.001 — 126
▼B
Titolo riservato Tipo di messaggio Riservato da
IRQS Messaggio di richiesta singola di informazioni supple-
mentariCFMU
ISPL Piano di volo supplementare singolo CFMU
LGR Elenco di messaggi di piano di volo FRANCIA
LISTFP Elenco di messaggi di piano di volo (ODS) FRANCIA
LISTFPCT Elenco di messaggi di piano di volo (Sistema di
controllo terminale)FRANCIA
LOGON Messaggio di identificazione di piano di volo FRANCIA
MAJVIVO Messaggio di movimenti giornalieri FRANCIAMCOM Messaggio di coordinamento FRANCIAMODCOND Modifica di una condizione eccezionale CFMUMODREG Modifica di una misura ATFM CFMUMRA Attivazione di una rotta obbligatoria CFMU
MRCNL Cancellazione di una rotta obbligatoria CFMU
MRMOD Modifica di una rotta obbligatoria CFMUMRR Messaggio di reinstradamento obbligatorio CFMUMVTVIVO Messaggio di informazione sui movimenti FRANCIANEWREG Attivazione di una misura ATFM CFMU
NTA Attivazione di un flusso di traffico «non consentito» CFMU
NTACNL Cancellazione di un flusso di traffico «non consentito» CFMUNTAMOD Modifica di un flusso di traffico «non consentito» CFMUOCLM Messaggio di autorizzazione oceanica FRANCIAOCLMD Messaggio di duplicazione di autorizzazione oceanica FRANCIAOLRA Messaggio di attivazione di una rotta alternativa CFMU
OLRCNL Messaggio di cancellazione di una rotta alternativa CFMU
OLRMOD Messaggio di modifica di una rotta alternativa CFMUPAMAER Applicabilità di pista FRANCIAPAMARB Conferma «in zona di stazionamento» FRANCIAPAMARRANN Cancellazione di attribuzione di parcheggio per un
arrivoFRANCIA
PAMARRCRE Attribuzione di posizione di parcheggio per un arrivo FRANCIA
PAMARRPST Modifica di attribuzione di parcheggio per un arrivo FRANCIAPAMDAPARB Messaggio di parcheggio per aeromobile in arrivo FRANCIA
PAMDAPCRE Attribuzione di posizione di parcheggio FRANCIA
PAMDEPANN Cancellazione di attribuzione di parcheggio per una
partenzaFRANCIA
PAMDEPCRE Attribuzione di parcheggio per una partenza FRANCIA
PAMDEPPST Modifica di attribuzione di parcheggio per una partenza FRANCIA
PAMDRB Conferma «in zona di stazionamento» FRANCIAQTAARR Ritorno a status iniziale «Creato» per un arrivo FRANCIAQTADEP Ritorno a status iniziale «Creato» per una partenza FRANCIARCD Messaggio di richiesta di autorizzazione alla partenza
(AIRINC 623)FRANCIA
RCDFTX Messaggio di richiesta di autorizzazione alla partenza
(AIRINC 620)FRANCIA
REVARR Messaggio di revisione per un arrivo FRANCIA
RFPDQ Messaggio di interrogazione di dati di piano di volo
ripetitivoCFMU
RFPDQR Messaggio di risposta a interrogazione di dati di piano
di volo ripetitivoCFMU2000R2082 — IT — 15.06.2002 — 001.001 — 127
▼B
Titolo riservato Tipo di messaggio Riservato da
RFPDSQ Messaggio di interrogazione di dati riassuntivi di piano
di volo ripetitivoCFMU
RFPDSQR Messaggio di risposta a interrogazione di dati riassun-
tivi di piano di volo ripetitivoCFMU
RIEM Messaggio di informazione di dati di volo FRANCIA
RMG Messaggio di avvicinamento mancato FRANCIA
RRA Messaggio di accettazione di reinstradamento CFMU
RREC Messaggio di recupero di piano di volo ripetitivo CFMU
RRN Messaggio di notifica di reinstradamento CFMU
RSUS Messaggio di sospensione di piano di volo ripetitivo CFMU
RWYCHGCT Messaggio di configurazione delle piste FRANCIA
TRACT Richiesta di attivazione di piano di volo (ODS) FRANCIA
TRACTCT Richiesta di attivazione di piano di volo (Sistema di
controllo terminale)FRANCIA
TRCNL Richiesta di cancellazione di piano di volo (ODS) FRANCIA
TRCNLCT Richiesta di cancellazione di piano di volo (Sistema di
controllo terminale)FRANCIA
TRCOR Richiesta di correlazione manuale FRANCIA
TRDECOR Richiesta di decorrelazione manuale FRANCIA
TRFIC Richiesta di creazione di dati di piano di volo (ODS) FRANCIA
TRFICCT Richiesta di creazione di dati di piano di volo (Sistema
di controllo terminale)FRANCIA
TRFLRQT Richiesta di livello di volo FRANCIA
TRMOD Richiesta di modifica di piano di volo (ODS) FRANCIATRMODCT Richiesta di modifica di piano di volo (Sistema di
controllo terminale)FRANCIA
TRMODH Richiesta di modifica di orario FRANCIA
TRMODHD Richiesta di modifica di orario per volo ritardato FRANCIA
TRMVT Richiesta di coordinamento per volo in uscita (ODS) FRANCIA
TRMVTCT Richiesta di coordinamento per volo in uscita (Sistema
di controllo terminale)FRANCIA
TRPOINT Messaggio di richiesta di dati di volo specifici FRANCIA
TRRET Richiesta di revisione di piano di volo e passaggio allo
status «Creato» (ODS)FRANCIA
TRRETCT Richiesta di revisione di piano di volo e passaggio allo
status «Creato» (Sistema di controllo terminale)FRANCIA
TRRIP Richiesta di visualizzazione di dati di volo (ODS) FRANCIA
TRRIPCT Richiesta di visualizzazione di informazioni sui dati di
volo (Sistema di controllo terminale)FRANCIA
TRRQT Richiesta di piano di volo (ODS) FRANCIA
TRRQTCT Richiesta di piano di volo (Sistema di controllo termi-
nale)FRANCIA
TRSHRQT Richiesta di azione SHOOT FRANCIA
TRSTAR Richiesta di inizializzazione di posizione di lavoro di
controllore (ODS)FRANCIA
TRSTARCT Richiesta di inizializzazione di posizione di lavoro di
controllore (Sistema di controllo terminale)FRANCIA
TRTRP Messaggio di posizione di trasferimento FRANCIA
UNKFP Messaggio di soppressione di piano di volo (ODS) FRANCIA
UNKFPCT Messaggio di soppressione di piano di volo (Sistema di
controllo terminale)FRANCIA2000R2082 — IT — 15.06.2002 — 001.001 — 128
▼B
ALLEGATO D (Normativo)
INDICECENTRALEDEICAMPIRISERVATI
D.1.Introduzione
Il presente allegato contiene un indice centrale di campi riservati —
campi primari, sottocampi e termini ausiliari — non ancora definiti per
l'utilizzo in ADEXP. La loro inclusione in questo allegato indica che è
previsto che siano utilizzati in futuro, o che sono già utilizzati ma solo
nell'ambito di sistemi locali.
D.2.Scopo
La compilazione di un elenco di campi che non sono ancora stati formal-
mente adottati per l'utilizzo in ADEXP ha lo scopo di evitare, nella
misura del possibile, i rischi di ridondanza quando è necessario un
campo per uno scopo particolare e di impedire l'adozione di una parola
chiave già utilizzata in un sistema locale.
D.3.Termini ausiliaririservati
Termine ausi-
liare riservatoSintassi SemanticaUsato in
campo
primarioUsato in
sottocampoUsato in
element-
o ausi-
liare
centreidentifi-
cation1{ALPHA}4 Identificazione
del centroctsrc
ripsrc
ctripectdest
contextfdpsid 'opepal' | 'opesos' |
'evalpal' | 'tsto-
pepal' |'tstopesos'Modo di funzio-
namento di un'ap-
plicazione FDPS
(operativa, test,
ecc.)ctxtfdps
contextphi-
diasid'ope'|'eva-
l1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Specifico del
sistema francesectxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Punto di entrata
per la posizione
di controllo ('E').
Punto di uscita
per la posizione
di controllo ('S'),
punto XFL (X),
punto OCL (O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Identificazione di
una «unità opera-
tiva»eosrc eoid
fl3 'F' ! 3{DIGIT}3 Livello di volo
espresso in centi-
naia di piedi.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Tendenza prevista
del profilo di
volo.
U per UPD per DownS per Stableetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Status del piano
di volo in un
ACC.fpctst2000R2082 — IT — 15.06.2002 — 001.001 — 129
▼B
Termine ausi-
liare riservatoSintassi SemanticaUsato in
campo
primarioUsato in
sottocampoUsato in
element-
o ausi-
liare
latitude 4{ DIGIT }4 Latitudine
espressa in
quattro cifreRiservato
per uso
futuro
latitudeshort 2{ DIGIT }2 Latitudine
espressa in due
cifre.Riservato
per uso
futuro
longitude 5{ DIGIT }5 Longitudine
espressa in cinque
cifre.Riservato
per uso
futuro
longitudes-
hort3{ DIGIT }3 Longitudine
espressa in tre
cifre.Riservato
per uso
futuro
pointcautra 1{ALPHANU-
M}5Specifico del
sistema francesefirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Posizione di
lavoro effettiva o
logicaposid
qfuid ('0'|'1'|'2'|'3')!1{
DIGIT }1!('L'|'C'
|'R'|NIL)QFU per una
pista.
L = sinistra
C= centroR = destraqfu qful
secidentifica-
tion1{ALPHANU-
M}2Identificazione
del settore.secdest
secsrcsecid
sendin-
greason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|'MVTSEC'|'COO-
RAUTO'|'
ODHD'|
'CNL'|'RADAR'|'I-
NIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|
'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|
'PKG'Motivo dell'invio
dei dati di piano
di volo.event
starreason 'TOTAL' Tipo di inizializ-
zazione di una
posizione con dati
di piano di volostreason
temperature ("N" | "P") !
2{DIGIT}2Temperatura
espressa in gradi
Celsius (00-99)
con indicazione
del segno (nega-
tivo o positivo)temp
updatereason ('T'!('R'|NIL)|'R') Tipo dell'ultimo
aggiornamento
dei dati di volo:
Transazione
operatore («T»).
Aggiornamento
radar («R»).udpt2000R2082 — IT — 15.06.2002 — 001.001 — 130
▼B
D.4.Campiprimaririservati
Campo
primario
riservatoTipo Sintassi Semantica
aabd b '-' "AABD" date Data effettiva di arrivo ai blocchi
aabt b '-' "AABT" timehhmm Orario effettivo di arrivo ai blocchi
acnf c '-' "ACNF" ad rcnf [qfulist] Configurazione delle piste
aobd b '-' "AOBD" date Data effettiva di partenza
aobt b '-' "AOBT" timehhmm Orario effettivo di partenza
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Tipo di avvicinamento del volo (1
cifra, valori: 1, 2, 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Identificazione dell'aeromobile
usata dagli esercenti di aeromobili
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Numero di identificazione dell'ae-
romobile localmente univoco
utilizzato dall'ATC
atis b '-' "ATIS" 1{ALPHA}1 Servizio automatico di informa-
zioni terminali
autfl1 b '-' "AUTFL1" fl3 Livello di volo autorizzato n. 1
autfl2 b '-' "AUTFL2" fl3 Livello di volo autorizzato n. 2
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Dati da trasmettere in un
messaggio di coordinamento: orario
di emissione, punto di uscita,
livello di volo al punto di uscita,
livello di volo pianificato e infor-
mazioni che precisano se la quota è
conforme agli accordi.
avail b '-' "AVAIL" 'YES'|'NO' Indicazione che precisa se un
settore è autorizzato a modificare
un dato di piano di volo.
bkrow b '-' "BKROW" 1{DIGIT}2 Posizione di un punto di riferi-
mento in un elenco di punti in
rotta.
bkt b '-' "BKT" datetime Orario di passaggio sulla verticale
del punto di riferimento per una
transazione.
codetr b '-' "CODETR" 'YES'|'NO' Indicazione che precisa se il codice
SSR deve essere trasmesso (o no)
al pilota dalla posizione di
controllo.
confid b '-' "CONFID" 1{DIGIT}5 Identificazione della configurazione
operativa (settori|posizioni).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"Elenco di associazioni settori/posi-
zioni per un centro di controllo di
rotta.
crspd b '-' "CRSPD" 1{DIGIT}4 Velocità di crociera in nodi
ctripe b '-' "CTRIPE" centreidentification Nome del centro ricevente per una
transazione
ctrow b '-' "CTROW" 1{DIGIT}1 Posizione di un centro in un elenco
di centri.
ctsrc b '-' "CTSRC" centreidentification Identificazione del centro emit-
tente.
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Modo di funzionamento del sistema
di controllo terminale.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Modo di funzionamento di un
FDPS
ctxtpos b '-' "CTXTPOS" contextphidiasid Modo di funzionamento per ODS
curfl b '-' "CURFL" fl3 Livello di volo corrente2000R2082 — IT — 15.06.2002 — 001.001 — 131
▼B
Campo
primario
riservatoTipo Sintassi Semantica
curpos c '-' "CURPOS" ptid | (lattd longtd) Posizione corrente
curpost b '-' "CURPOST" datetime Data e orario alla posizione
corrente
curptt b '-' "CURPTT" datetime Data e orario di sorvolo del punto
corrente
curptx b '-' "CURPTX" 1{DIGIT}2 Posizione numerata del punto
corrente in un elenco di punti in
rotta.
dcatcid b '-' "DCATCID" icaoaerodrome Aerodromo responsabile dell'auto-
rizzazione al decollo quando questa
è data dall'FDPS all'aeromobile
attraverso il collegamento dati.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Testo di base dei messaggi di auto-
rizzazione alla partenza ARINC
623. «ACK» per messaggio di
riscontro.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Testo di base dei messaggi di auto-
rizzazione alla partenza ARINC
620. «ACK» per messaggio di
riscontro.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Status di autorizzazione alla
partenza per un volo.
dcid b '-' "DCID" 1{DIGIT}3 Numero di sistema per l'autorizza-
zione alla partenza.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Tipo di messaggio di autorizza-
zione alla partenza.
dcref b '-' "DCREF" 1{ALPHANUM}5 Riferimento contestuale per un'au-
torizzazione alla partenza.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Osservazione per un'autorizzazione
alla partenza.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Testo supplementare per il
messaggio di sistema di autorizza-
zione alla partenza (ARINC 623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Secondo testo supplementare per il
messaggio di sistema di autorizza-
zione alla partenza (ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Giorno, ore, minuti e secondi per
l'autorizzazione alla partenza.
delcode b -' "DELCODE"
1{ALPHANUM}20Motivo di un ritardo
dfdpsid b '-' "DFDPSID datetime ! seconds Dati di identificazione del sistema
di elaborazione dei dati di volo
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identificazione di un'entità «dupli-
cata».
ecurptt b '-' "ECURPTT" datetime Orario stimato di sorvolo del punto
corrente
eda b '-' "EDA" date Data stimata di arrivo
elastptt b '-' "ELASTPTT" datetime Orario stimato di sorvolo dell'ul-
timo punto della rotta
endhldt b '-' "ENDHLDT" datetime Orario in cui termina il circuito di
attesa.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Numero di occorrenze di un piano
di volo in un centro.
entryt b '-' "ENTRYT" datetime Orario di entrata per la posizione.2000R2082 — IT — 15.06.2002 — 001.001 — 132
▼B
Campo
primario
riservatoTipo Sintassi Semantica
enxtptt b '-' "ENXTPTT" datetime Orario stimato di sorvolo del punto
successivo (non compare se il
punto corrente è l'ultimo punto).
eobdt b '-' "EOBDT" datetime Data e orario stimati di inizio
rullaggio.
eosrc b '-' "EOSRC" eoidentification Identificazione della «entità»
operativa
espfl b '-' "ESPFL" flightlevel Livello di volo di trasferimento
supplementare per la posizione di
controllo precedente.
eta b '-' "ETA" timehhmm Orario stimato di arrivo.
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyLivello di volo di entrata o
tendenza del profilo di volo.
event b '-' "EVENT" sendingreason Evento che determina l'attivazione
per l'FDPS.
firstpid b '-' "FIRSTPID" pointcautra Specifico del sistema francese
flbk b '-' "FLBK" flightlevel Livello di volo dell'ultimo punto di
riferimento di transazione per un
volo attivato, o livello modificato
per un punto di riferimento per una
transazione.
fpbaseid b '-'FPBASEID" datetime!seconds Identificazione del database dei
piani di volo
fpctst b '-' "FPCTST" fpcentrestate Status di un piano di volo in un
centro.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Elenco dei piani di volo noti ma
non ancora trasferiti per una posi-
zione.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Categoria di volo:
T = sorvolo
E = in arrivo
S = in partenza
I = interno.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Elenco di informazioni di piano di
volo per un indicativo di chiamata.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Elenco di campi di piano di volo.
fplnb b '-' "FPLNB" 1{DIGIT}1 Numero di piani di volo: da 0 a 5
fplstat b '-' "FPLSTAT" "T" | "C" Status del volo:
T = terminato
C = in corso.
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Osservazioni del piano di volo
iniziale.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT""|FIC-
PAC"|'FPL"|"RPL"|"NKW")Sorgente del piano di volo.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Elenco di piani di volo «scono-
sciuti».
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Testo libero.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Identificazione di rotta flessibile.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Nome di rotta flessibile.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Numero di creazione di rotta fles-
sibile.
grspd b '-' "GRSPD" 1{DIGIT}4 Velocità rispetto al suolo in nodi.2000R2082 — IT — 15.06.2002 — 001.001 — 133
▼B
Campo
primario
riservatoTipo Sintassi Semantica
hldbkrw b -' "HLDBKRW" 1{DIGIT}2 Numero progressivo di un punto di
riferimento per un circuito di attesa
in un elenco di punti in rotta.
icing b '-' "ICING" 1{ALPHA}8 Formazione di ghiaccio.
«TRACE», «LIGHT», «MODE-
RATE» o «SEVERE».
indstip b '-' "INDSTIP" 'STIP' Specifico del sistema francese
initid b '-' "INITID" 1{DIGIT}1 Numero di inizializzazione.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Identificatore d'interfaccia FDPS/
ODS o FDPS/sistema terminale.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Elenco delle latitudini e longitudini
dei punti in rotta.
lang b '-' "LANG" '?' Identificatore di lingua di conver-
sazione.
«?» = lingua non comune nella
compagnia
lastradt b '-' "LASTRADT" datetime Ultimo aggiornamento orario
fornito dal radar.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Codice luci.maint b '-' "MAINT" 'YES'|'NO' Indicazione che precisa se le infor-
mazioni per una posizione di
controllo sono aggiornate continua-
mente o no.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Informazioni Modo A dell'SSR.
modec b '-' "MODEC" flightlevel Informazioni Modo C dell'SSR.
msgbody b '-' "MSGBODY"
1{CHARACTER}Contiene una stringa di caratteri
identica al testo del messaggio non
ADEXP equivalente esistente.
msgct b '-' "MSGCT" datetime ! seconds Datazione del messaggio nel
formato: giorno, ore, minuti,
secondi.
nat b '-' "NAT" 1{ALPHA}1 Identificazione di una rotta norda-
tlantica.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Frequenza di contatto successiva.
nxtfir b '-' "NXTFIR" icaoaerodrome FIR successiva da contattare
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Posizione successiva.
nxtpost b '-' "NXTPOST" datetime Orario di sorvolo della posizione
successiva.
oclfl b '-' "OCLFL" flightlevel Livello di volo al limite di autoriz-
zazione oceanica (OCL).
oprfl b '-' "OPRFL" flightlevel Richiesta di livello di volo modifi-
cata da un esercente.
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Elenco di osservazioni dell'eser-
cente.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Osservazioni dell'esercente.
oriented b '-' "ORIENTED" 'YES'|'NO' Volo orientato o no.
pfl b '-' "PFL" flightlevel Livello di volo pianificato (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistCoordinate di traccia radar e coor-
dinate di vettore della velocità.
pistid b '-' "PISTID" 1{DIGIT}4 Identificazione di traccia radar.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Posizione di parcheggio per un
volo in arrivo
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Posizione di parcheggio per un
volo in partenza.2000R2082 — IT — 15.06.2002 — 001.001 — 134
▼B
Campo
primario
riservatoTipo Sintassi Semantica
plnid b '-' "PLNID" 4{DIGIT}4 Identificazione di piano di volo
plnold b '-' "PLNOLD" 4{DIGIT}4 Vecchia identificazione di piano di
volo
posst b '-' "POSST" 'MAE'|'MP-
S'|'MAS'|'MPSA'|'MPSLATE'|'NO'Status di coordinamento del movi-
mento per la posizione: movimento
accettato in entrata (MAE) o in
uscita (MAS) o movimento
proposto in uscita (MPS) o in
uscita allarme (MPSA) o posizione
non ancora coordinata per il movi-
mento (NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Numero di punti in rotta.
qfu b '-' "QFU" qfuid Identificazione della pista utilizzata
(QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Volo Quebec o no.
radioid b '-' "RADIOID"
1{ALPHANUM}20Identificazione radio.
reqid b '-' "REQID" 1{DIGIT}5 Numero di una richiesta.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Tipo di richiesta di piano di volo.
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Elenco di entità destinatarie dei
dati di piano di volo
ripsrc b '-' "RIPSRC" centreidentification Identificazione del centro responsa-
bile di avviare la trasmissione dei
dati di piano di volo.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' Numero di transazione IFPS in una
richiesta di piano di volo.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Elenco dei punti CAUTRA in rotta
non diretta.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Elenco dei punti in rotta per alcune
transazioni.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Elenco di configurazioni di aero-
dromo.
secdest b '-' "SECDEST" secidentification Identificatore del settore destina-
tario.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Elenco globale di settori.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Elenco globale dei settori.
secsrc b '-' "SECSRC" secidentification Identificatore del settore di origine.
spfl b '-' "SPFL" flightlevel Livello di volo supplementare.ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Codice SSR trasmesso.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmIdentificazione oraria.
streason b '-' "STREASON" starreason Motivo di una richiesta di inizia-
lizzazione emessa da una posizione
di lavoro.
strid b '-' "STRID" 1{DIGIT} Identificatore di RDPS.
temp b '-' "TEMP" temperature Temperaturaterminal b '-' "TERMINAL"
1{ALPHANUM}2Nome del terminal
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Elenco di transazioni possibili per
la posizione di controllo ed il piano
di volo specificato.2000R2082 — IT — 15.06.2002 — 001.001 — 135
▼B
Campo
primario
riservatoTipo Sintassi Semantica
trfl b '-' "TRFL" flightlevel | flightten-
dancyLivello di volo di trasferimento o
tendenza del profilo di volo
turb b '-' "TURB" 1{ALPHA}8 Turbolenza = LIGHT, MODE-
RATE o SEVERE
validend b '-' "VALIDEND" datetime Orario di fine di visualizzazione.
validst b '-' "VALIDST" datetime Orario d'inizio di visualizzazione.
visi b '-' "VISI" 1{ALPHANUM}20 Visibilità.
wddir b '-' "WDDIR" 1{DIGIT}3 Direzione del vento espressa in
gradi da 0 a 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Velocità del vento espressa in nodi.
xfl b '-' "XFL" flightlevel Livello di volo di uscita (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Messaggio di risposta ad una
richiesta di piano di volo.
D.5.Sottocampiriservati
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Campi del piano di
volo modificabili al
momento dell'attiva-
zione di un volo.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxFL implicito, FL
minimo ed FL
massimo per il punto
di riferimento per una
transazione. L'FL è
generico, e può
essere un RFL, un
PFL, ecc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Valore (+/-) consen-
tito per una modifica
oraria per un punto.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxLivello di volo auto-
rizzato (CFL) impli-
cito, CFL minimo e
CFL massimo per il
punto di riferimento
per una transazione.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e codice
assegnato.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo e codice SSR
disponibili per l'uti-
lizzo.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e codice
precedentemente
assegnato.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e codice
riservato (quindi non
disponibile).ssrcodes
coorpt b '-' "COORPT" coord-
pointsCaratteristica del
punto di coordina-
mento: iniziale, di
uscita, OCL, XFLptc2000R2082 — IT — 15.06.2002 — 001.001 — 136
▼B
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
ctdest b '-' "CTDEST"
centreidentificationCentro destinatario
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervallo di tempo
per il calcolo di un
tempo minimo.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervallo di tempo
per il calcolo di un
tempo massimo.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Intervallo di velocità
per il calcolo di una
velocità minima.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Intervallo di velocità
per il calcolo di una
velocità massima.spdchg
destid c '-' "DESTID" ctdest
secripCentro ATC ed
elenco di settori a cui
vanno inviati i dati di
piano di voloripel
edto b '-' "EDTO" dateti-
me|"WT"Orario stimato su un
punto (anno, mese,
giorno, ore, minuti) o
indicazione «WT»,
«punto senza orario».ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationDesignazione di
«entità» operativa.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Elenco di entità
operative associate ad
una posizione di
controllo.eopos
eopos c '-' "EOPOS" posid
[eolist]Designazione della
posizione di controllo
ed elenco di entità
operative associate a
tale posizione.confl
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'Identificazione dei
campi modificabili
per una transazione.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Livello di volo calco-
lato al punto di coor-
dinamento di uscita,
che può essere
trasmesso nel
messaggio di coordi-
namento automatico
indirizzato al centro
successivo.automsg
flimp b '-' "FLIMP" fligh-
tlevelLivello di volo impli-
cito.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" fligh-
tlevelLivello di volo
massimo.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg2000R2082 — IT — 15.06.2002 — 001.001 — 137
▼B
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
flmin b '-' "FLMIN" fligh-
tlevelLivello di volo
minimo.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbIdentificazione di
piano di volo in un
messaggio.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobtDati «riassuntivi» di
piano di volo.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidIdentificazione di
piano di volo.fplist
lalg c '-' "LALG" lattd
longtdLatitudine e longitu-
dine di ogni punto in
rottalaglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Elenco di campi
modificabili dopo
l'attivazione.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Elenco di campi
modificabili in una
transazione di aggior-
namento orario dopo
l'attivazione.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Elenco di campi
modificabili in un
coordinamento
avviato manualmente
tra settoritransid
pflchg c '-' "PFLCHG" flimp
flmin flmaxQuota implicita,
minima e massima
per una modifica di
PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Livello di volo piani-
ficato che sarà
trasmesso nel
messaggio di coordi-
namento automatico
indirizzato al centro
successivo, più indi-
cazione che precisa
se il livello è
conforme agli accordi
operativi applicabili.
NA = Non conforme.automsg
pka b '-' "PKA"
1{ALPHANUM}3Posizione di
parcheggio riservata,
non ancora assegnata.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indicatore che
segnala che l'aeromo-
bile è in attesa di una
posizione di
parcheggio.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Posizione di
parcheggio assegnata.pkarr
pointid b '-' "POINTID" point-
cautraSpecifico del sistema
francese.ptpro
posid b '-' "POSID" positioni-
dentificationDesignazione della
posizione di
controllo.eopos2000R2082 — IT — 15.06.2002 — 001.001 — 138
▼B
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Caratteristica di un
punto in rotta.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameSpecifico del sistema
francese.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Descrizione di punti
in rotta proposti.rtetr
qful c '-' "QFUL" qfuid QFU valido per una
pista di un aero-
dromo.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Elenco di QFU validi
per un aerodromo.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Direzione generale di
decollo ed atterraggio
per un aerodromo
(est, ovest, ecc.)acnf
ref c '-' "REF" (refi-
d|ref1id)Caratteristiche di un
punto di riferimento
per una transazione.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Identificazione di un
possibile punto di
riferimento per una
transazione.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identificazione del
punto di riferimento
più probabile per una
transazione.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Informazione sulla
regolamentazione
specifica dei sistemi
francesi.regul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Informazione sulla
regolamentazione
specifica dei sistemi
francesi.regul
regult b '-' "REGULT" date-
timeInformazione sulla
regolamentazione
specifica dei sistemi
francesi.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Elenco di campi
modificabili in una
transazione per ripor-
tare i dati di piano di
volo allo status
precedente.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxQuota implicita,
minima e massima
per la modifica
dell'RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Testo di un'osserva-
zione fatta dal
controllore.oprmk
sec c '-' "SEC" secid
[seccar]Identificazione e
caratteristiche dei
settori ACC a cui
vanno inviati i dati di
piano di volo.seclist secrip2000R2082 — IT — 15.06.2002 — 001.001 — 139
▼B
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Caratteristica di un
settore ACC:
- Primo settore («F»)
- Ultimo settore
(«L»)
- Accettato per
entrata («M»)
- Settore sorgente per
«duplicazione» («D»)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Caratteristica di un
settore di area termi-
nale:
- Primo settore («F»)
- Ultimo settore
(«L»)
- Accettato per
entrata («M»)secct
secct c '-' "SECCT" secid
[seccarct]Identificazione e
caratteristiche dei
settori di area termi-
nale.seclistct
secid b '-' "SECID" seciden-
tificationIdentificazione di
settore.secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Elenco di entità
destinatarie (settori o
entità di controllo di
partenza/arrivo) a cui
vanno inviati i dati di
piano di volo.destid
sendt b '-' "SENDT" datetime Orario per l'invio di
un messaggio di
coordinamento.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxQuota implicita,
minima e massima
per la modifica di un
livello di volo
supplementare (SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Intervalli di velocità
inferiore e superiore
per la modifica della
velocità indicata nel
piano di volo durante
una transazione.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxQuota implicita,
minima e massima
per la modifica del
livello di trasferi-
mento di controllo
(TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Caratteristica di un
punto in relazione
alla traiettoria di un
volo:
S = Punto di scis-
sione
M = Punto di giun-
zione
T = Punto al traverso
A = Punto di STARptc
ptpro2000R2082 — IT — 15.06.2002 — 001.001 — 140
▼B
Sottocampi
riservatiTipo Sintassi SemanticaUsato in
campo
primarioUsato in
sottocampo
transid b '-' " TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Identificazione di
transazione possibile
per la posizione di
controllo per il piano
di volo particolare o
indicazione «NO» per
segnalare che la tran-
sazione non è possi-
bile.translist
txt b '-' "TXT"
1{LIM_CHAR}80Testo libero. freetxt
udpt b '-' "UDPT" update-
reasonUltimo aggiorna-
mento apportato
dall'operatore e/o
sulla base di infor-
mazioni radar.ptc
view b '-' "VIEW"
('V'|'VNX')Indicazione della
«visibilità» di un
punto.
V = visibile
VNX = non visibile
(punto artificiale)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positiva
N:= NegativaCoordinata X del
vettore della velocità
di una posizione
radar.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positiva
N:= NegativaCoordinata Y del
vettore della velocità
di una posizione
radar.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxQuota minima e
massima per la modi-
fica di un livello di
volo di uscita (XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positiva
N:= NegativaCoordinata X di una
posizione radar.pistcoord
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positiva
N:= NegativaCoordinata Y di una
posizione radar.pistcoord2000R2082 — IT — 15.06.2002 — 001.001 — 141
▼B
ALLEGATO E (Informativo)
PRESENTAZIONEDEIGRUPPIDIMESSAGGI
INTRODUZIONE
Il presente allegato presenta i vari gruppi di messaggi o categorie di messaggi
che è possibile scambiare in ADEXP. L'elenco completo dei titoli di messaggio
ADEXP è contenuto nell'allegato B.
NOTA Per le condizioni e le regole precise di applicazione ed utilizzo dei
campi, in particolare per quanto riguarda l'impiego dei campi facoltativi,
fare riferimento alla documentazione (es. specifiche d'interfaccia) dei
sistemi in questione.
E.1.Messaggidipianodivolo
E.1.1. Introduzione
I messaggi di questa categoria sono scambiati principalmente tra
l'AO, l'IFPS e gli enti ATS competenti.
E.1.2. Definizione dei titoli di messaggio
I messaggi facenti parte di questa categoria hanno i titoli seguenti:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQP, MAN, RCHG, RCNL, REJ.
Tutto il materiale di definizione di questi messaggi è contenuto nel
documento di cui al rif. 3
E.1.3. Composizione dei campi primari
La definizione dettagliata del contenuto dei messaggi, le regole di
inserimento dei dati e le modalità di utilizzo dei campi obbligatori e
facoltativi sono contenute nel documento di cui al rif. 3.
Esempio:
Messaggio di piano di volo-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 — IT — 15.06.2002 — 001.001 — 142
▼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.Messaggidigestionedelflussodeltraffico aereo
E.2.1. Introduzione
I messaggi facenti parte di questa categoria sono scambiati principal-
mente tra il sistema TACT della CFMU di Eurocontrol, gli esercenti
di aeromobili e gli enti ATS.
E.2.2. Messaggi di assegnazione computerizzata di slot (CASA)
I messaggi facenti parte di questa categoria hanno i titoli seguenti:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Definizione dei titoli di messaggio
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 5.
E.2.2.2. Composizione dei campi primari
La definizione dettagliata del contenuto dei messaggi, le regole di
inserimento dei dati e le modalità di utilizzo dei campi obbligatori e
facoltativi sono contenute nel documento di cui al rif. 5.
Esempio:
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3. Messaggi di informazione
I messaggi facenti parte di questa categoria hanno i titoli seguenti:FSA
E.2.3.1. Definizione dei titoli di messaggio
Il materiale di definizione per questo messaggio è contenuto nel
documento di cui al rif. 5.
E.2.3.2. Composizione dei campi primari
La definizione dettagliata del contenuto dei messaggi, le regole di
inserimento dei dati e le modalità di utilizzo dei campi obbligatori e
facoltativi sono contenute nel documento di cui al rif. 5.
Esempio
Messaggio di prima attivazione del sistema
-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — IT — 15.06.2002 — 001.001 — 143
▼B
E.3.MessaggidicoordinamentoATC
E.3.1. Introduzione
I messaggi di coordinamento sono utilizzati per automatizzare il coor-
dinamento operativo e lo scambio di informazioni tra enti ATC.
Questi messaggi assicurano la trasmissione, nei tempi voluti, delle
informazioni operative associate al coordinamento mediante funzioni
normalizzate di estrazione e trasmissione dati.
E.3.2. Definizione dei titoli di messaggio
I messaggi facenti parte di questa categoria hanno i titoli seguenti:
ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 6.
E.3.3. Composizione dei campi primari
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 6.
Esempi:
Messaggio di proposta di trasferimento-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Messaggio di attivazione
-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.Messaggidigestionedellospazioaereo
E.4.1. Introduzione
Messaggi utilizzati per il coordinamento della gestione dello spazio
aereo. Questi messaggi riguardano la gestione dell'ambiente in cui si
svolge il traffico: rotte permanenti e sotto condizione, zone tempora-
neamente riservate, zone pericolose e vietate, ecc.
E.4.2. Definizione dei titoli di messaggio
I messaggi facenti parte di questa categoria hanno i titoli seguenti:
AUP, CRAM, UUP.
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 7.
E.4.3. Composizione dei campi primari
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 7.
Esempio:
Messaggio di disponibilità di rotta sotto condizione-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 — IT — 15.06.2002 — 001.001 — 144
▼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.Messaggidicoordinamentocivile /militare
E.5.1. Introduzione
Messaggi utilizzati per il coordinamento dei dati di volo e delle
richieste di attraversamento di spazio aereo tra enti ATS civili e mili-
tari.
E.5.2. Definizione dei titoli di messaggio
I messaggi facenti parte di questa categoria hanno i titoli seguenti:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 7.
E.5.3. Composizione dei campi primari
Tutto il materiale di definizione per questi messaggi è contenuto nel
documento di cui al rif. 7.
Esempio:
Messaggio di richiesta di autorizzazione di attraversamento
-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
Messaggio di accettazione
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — IT — 15.06.2002 — 001.001 — 145
▼B
ALLEGATO F (Informativo)
ESEMPIDIFORMATODIMESSAGGIADEXP
Gli esempi qui di seguito sono forniti a titolo di dimostrazione del formato
ADEXP, non di esempio di contenuto dei messaggi. Il messaggio utilizzato è
un IFPL; benché sia corretto all'epoca della pubblicazione, non si garantisce
l'esattezza della composizione dei campi, ecc.
L'ESEMPIO 1 è presentato in un modo che lo rende leggibile senza difficoltà,
grazie all'uso di ritorni carrello, avanzamenti riga, rientri, ecc. Questo formato di
presentazione, però, non rientra tra le regole di formattazione ADEXP.
La presentazione di un messaggio è quindi lasciata alla discrezione del sistema
ricevente. Gli ESEMPI 2 e 3 sono entrambi rappresentazioni valide dello stesso
messaggio dell'ESEMPIO 1.
ESEMPIO 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 — IT — 15.06.2002 — 001.001 — 146
▼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
ESEMPIO 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 -ETO980317074449 -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 — IT — 15.06.2002 — 001.001 — 147
▼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
ESEMPIO 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 — IT — 15.06.2002 — 001.001 — 148
▼B
ALLEGATO G (Informativo)
SVILUPPIFUTURI
G.1.Introduzione
Il presente allegato ha lo scopo di fornire indicazioni sullo sviluppo
futuro proposto di ADEXP, di precisare i motivi e gli obiettivi di tale
sviluppo.
G.2.Obiettivi
Uno degli obiettivi più importanti che si è voluto perseguire con lo
sviluppo di ADEXP è l'elaborazione di un formato che permetta ad un
sistema ricevente di «ignorare» o «saltare» un campo sconosciuto o non
identificato senza per questo dover invalidare il messaggio in fase di
elaborazione. Questo permette di aggiungere un nuovo campo in un
messaggio senza dover modificare in anticipo tutti i sistemi riceventi
per procedere ad un trasferimento coordinato nei minimi particolari.
L'enorme flessibilità che ne consegue è uno dei vantaggi del formato
ADEXP.
Questo obiettivo è raggiunto nella norma presente attraverso l'uso di
campi primari e sottocampi predefiniti, introdotti da parole chiave
univoche. Un analizzatore lessicale o un parser che non «riconosce»
una parola chiave deve ignorare tutto il testo fino al successivo campo
primario identificato non situato all'interno di un campo lista. Il recupero,
quindi, avviene a livello di campi primari.
Lo sviluppo attuale e futuro nella definizione di nuovi messaggi indica
che in alcune aree è necessaria una maggior complessità, con l'intercala-
mento di campi di terzo o anche quarto livello. (Il messaggio di
assegnazione di rotta sotto condizione (CRAM) è un esempio attuale di
tale necessità). Attualmente ADEXP permette di costruire un messaggio
con qualsiasi livello di intercalamento; tuttavia non permette ancora il
recupero dopo il rilevamento di un sottocampo non identificato magari
al terzo o quarto livello di intercalamento senza il rischio di un'interpre-
tazione errata dei dati o la necessità di invalidare il messaggio. Le
modifiche proposte hanno lo scopo di assicurare che un analizzatore
lessicale o un parser possa in qualsiasi momento determinare in che
punto è all'interno della struttura di un messaggio o di un campo partico-
lare, in modo da consentire un recupero a qualsiasi livello di
intercalamento senza il pericolo di un'interpretazione errata dei dati.
G.3.Proposta
Per raggiungere l'obiettivo di un recupero a qualsiasi livello, è necessario
che l'analizzatore lessicale sia in grado di determinare la fine, oltre che
l'inizio, di un campo. Il formato attuale consente invece di determinare
unicamente l'inizio di un campo tramite il carattere «-».
In una versione futura di ADEXP si proporrà di introdurre l'uso delle
parentesi per indicare l'inizio e la fine di un campo. Il carattere «-»
attualmente utilizzato per introdurre l'inizio di un campo verrebbe sosti-
tuito dal carattere «(». La fine del campo, che oggi non è indicata
esplicitamente, verrebbe indicata in futuro dal carattere «)». Gli esempiqui di seguito illustrano questo principio.
Esempi
Formato attuale Formato proposto
Esempio di campo semplice: -RFL F330 (RFL F330)Esempio di campo composto: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430))2000R2082 — IT — 15.06.2002 — 001.001 — 149
▼B
ALLEGATO III
SCAMBIO DI DATI DI VOLO — DOCUMENTO RELATIVO AL
CONTROLLODIINTERFACCIA(FDE-ICD),EDIZIONE1.0
(documentoEurocontroldiriferimento COM.ET1.ST12-STD)2000R2082 — IT — 15.06.2002 — 001.001 — 150
▼B
INDICE
AVVISO/DIRITTI D'AUTORE
PREFAZIONE1. INTRODUZIONE2. CAMPO DI APPLICAZIONE3. RIFERIMENTI
3.1. Introduzione3.2. Riferimenti
4. DEFINIZIONI, SIMBOLI E ABBREVIAZIONI
4.1. Definizioni4.2. Simboli e abbreviazioni4.3. Notazioni
5. PANORAMICA TECNICA
5.1. Pila dei protocolli5.2. Struttura del profilo5.3. Rapporto con versioni precedenti delle specifiche
6. REQUISITI PER IL PROFILO
6.1. Requisiti di conformità6.2. Requisiti relativi ai livelli superiori6.3. Requisiti relativi ai livelli inferiori6.3.1. Requisiti relativi al livello di trasporto6.3.2. Requisiti relativi al livello di rete6.3.3. Requisiti relativi al livello di collegamento6.3.4. Requisiti relativi al livello fisico
7. METODI DI PROVAALLEGATO A (NORMATIVO) PROTOCOLLO DI TRASFERIMENTO DI MESSAGGI
A.1. IntroduzioneA.2. Servizi implementatiA.3. Servizi richiestiA.4. Specifiche del protocolloA.4.1. IntroduzioneA.4.2. Tipi di datiA.4.3. Formazione dell'associazioneA.4.4. Trasferimento di datiA.4.5. Rilascio normale dell'associazioneA.4.6. Riformazione dell'associazioneA.4.7. Integrità dell'associazioneA.4.8. Rilascio anormale dell'associazioneA.4.9. Recupero da malfunzionamento2000R2082 — IT — 15.06.2002 — 001.001 — 151
▼B
A.4.10. Formati dei messaggi
A.5. Tabelle di transizione degli stati di protocolloA.5.1. IntroduzioneA.5.2. Definizioni degli statiA.5.3. Eventi possibili
A.5.4. Timer
A.5.5. Tabella di transizioni di statoA.5.6. Diagramma delle transizioni di stato
ALLEGATO B (NORMATIVO) PROTOCOLLO DI INTESTAZIONE DEI MESSAGGI
B.1. IntroduzioneB.2. Servizio implementatoB.3. Servizio richiesto
B.4. Specifiche del protocollo
B.4.1. Formazione della connessioneB.4.2. Misure volte ad evitare connessioni di rete ridondantiB.4.3. Rilascio della connessioneB.4.4. Trasferimento di dati
ALLEGATO C (NORMATIVO) PROTOCOLLO DI RETE
C.1. Introduzione
C.2. Servizio fornitoC.3. Servizio richiestoC.4. Indirizzi di NSAPC.4.1. Introduzione
C.4.2. Struttura degli indirizzi di NSAP
C.4.3. Assegnazione degli identificatori e dei selettori di ente ATCC.5. Specifiche relative al protocolloC.5.1. Presentazione generaleC.5.2. Codifica degli indirizzi
C.5.3. Codifica del campo User Data
C.5.4. Trattamento degli indirizzi nei pacchetti INCOMING CALLC.5.5. Trasferimento di dati
ALLEGATO D (NORMATIVO) DICHIARAZIONI PROFORMA PICS DI CONFORMITA AL
PROFILO
D.1. IntroduzioneD.2. Istruzioni per la compilazione delle dichiarazioni proforma PICSD.2.1. Struttura generale delle dichiarazioni proforma PICSD.2.2. Informazioni supplementari
D.2.3. Informazioni sulle difformità
D.2.4. Elementi condizionatiD.3. Dichiarazione proforma PICS per il Protocollo di trasferimento di messaggi2000R2082 — IT — 15.06.2002 — 001.001 — 152
▼B
D.3.1. Abbreviazioni e simboli speciali
D.3.2. Identificazione
D.3.3. Implementazione del protocolloD.4. Dichiarazione proforma PICS per il protocollo di intestazione dei messaggiD.4.1. Abbreviazioni e simboli specialiD.4.2. IdentificazioneD.4.3. Implementazione del protocolloD.5. Dichiarazione proforma PICS per il protocollo di reteD.5.1. Abbreviazioni e simboli speciali
D.5.2. Identificazione
D.5.3. Implementazione del protocollo
ALLEGATO E (NORMATIVO) LISTA DEI REQUISITI PER IL PROFILO
E.1. IntroduzioneE.2. Ruolo della PRL e delle dichiarazioni proforma PICSE.3. NotazioneE.4. Istruzioni per la compilazione delle dichiarazioni proforma PICSE.5. RiferimentiE.6. Dichiarazione di conformità
E.6.1. Presentazione generale della conformità
E.6.2. Requisiti di conformità dinamicaE.7. Requisiti relativi ai livelli superioriE.8. Requisiti relativi ai livelli inferioriE.8.1. Requisiti relativi al livello di trasportoE.8.2. Requisiti relativi al livello di reteE.8.3. Requisiti relativi al livello di collegamentoE.8.4. Requisiti relativi al livello fisico
ALLEGATO F (INFORMATIVO) METODOLOGIE PER LE PROVE DI CONFORMITÀ
F.1. Introduzione
F.2. Scopo e campo d'applicazioneF.3. BibliografiaF.4. Metodi e pratiche di sviluppoF.5. ProveF.5.1. IntroduzioneF.5.2. Prove dei livelli inferiori (livelli 1 — 3)F.5.3. Prova del livello applicazione
F.5.4. Certificazione
F.5.5. Notifica
ALLEGATO G (INFORMATIVO) ASSEGNAZIONE DEGLI IDENTIFICATORI DEGLI ENTI ATC
ALLEGATO H (INFORMATIVO) DIRETTIVE SULL'AFFIDABILITÀ, LA DISPONIBILITÀ E LA
SICUREZZA2000R2082 — IT — 15.06.2002 — 001.001 — 153
▼B
H.1. Introduzione
H.2. Scopo e campo d'applicazioneH.3. Bibliografia
H.4. Implementazioni su linea affittata
H.4.1. AffidabilitàH.4.2. DisponibilitàH.4.3. SicurezzaH.4.4. Esempio di configurazioneH.5. Implementazione su reteH.5.1. AffidabilitàH.5.2. DisponibilitàH.5.3. SicurezzaH.6. Direttive generali per le implementazioni su linea affittata e su reteH.6.1. AffidabilitàH.6.2. DisponibilitàH.6.3. Gestione dei sistemiH.6.4. Esempio di configurazione2000R2082 — IT — 15.06.2002 — 001.001 — 154
▼B
AVVISO/DIRITTID'AUTORE
Il presente documento è stato elaborato dall'Agenzia Eurocontrol, che ne
detiene i diritti d'autore.
Il contenuto del presente documento, o di qualsiasi parte di esso, è a dispo-
sizione dei rappresentanti degli Stati membri, ma la riproduzione o
divulgazione a terzi è subordinata al preventivo consenso scritto dell'A-
genzia Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 155
▼B
PREFAZIONE
1. Organoresponsabile
La presente norma è stata elaborata dalla task force «Scambio di
dati relativi ai piani di volo (FPDE)» dell'Organizzazione europea
per la sicurezza della navigazione aerea (Eurocontrol), che si
occupa anche del suo aggiornamento.
2. Documento«ProgrammadilavoroEATCHIP»
La presente norma è collegata al documento «Programma di
lavoro EATCHIP (EWPD)», dominio «Comunicazioni», attività
direttiva 01, attività specialistica 12.
3. Approvazionedellanorma
3.1. La presente norma è adottata conformemente alle procedure defi-
nite nelle «Directives for Eurocontrol Standardisation», rif. 000-2-
93.
3.2. La presente norma acquisisce efficacia non appena adottata dalla
Commissione permanente di Eurocontrole sostituisce la norma
«Eurocontrol Standard for On-Line Data Interchange (OLDI)»,
edizione 1, parte 3: Technical requirements (Short Term Interface
Control Document), rif. 001-3-92.
4. Rettifiche tecnicheemodifiche
La presente norma è tenuta sotto controllo allo scopo di indivi-
duare le modifiche o rettifiche tecniche necessarie. La procedura
per l'aggiornamento della presente norma è definita nell'allegato
H delle «Directives for the Uniform Drafting and Presentation of
EurocontrolStandard Documents», rif. 000-1-92.
5. Convenzioniredazionali
5.1. Il formato della presente norma è conforme alle «Directives for
the Uniform Drafting and Presentation of Eurocontrol Standard
Documents».
5.2. Per indicare lo status di ciascun elemento è stata adottata la nota-
zione seguente:
— gli elementi normativi sono caratterizzati da verbi al modo
indicativo, tempo presente, e sono stampati in caratteri tondi;
— glielementi raccomandati sono caratterizzati dalla forma
verbale «è opportuno che» o «dovrebbe/dovrebbero»; sono
stampati in caratteri corsivi e preceduti dall'indicazione
Raccomandazione .
5.3. Qualsiasi altra informazione ritenuta essenziale per la compren-
sione di un particolare paragrafo è stata incorporata nel testo
sotto forma di NOTA. Le note hanno valore unicamente informa-
tivo, pertanto non contengono specifiche e sono collocate subito
dopo il paragrafo a cui si riferiscono.
5.4. Eccezionalmente, per alcune delle tabelle dell'allegato E non sono
stati rispettati i rientri standard e la suddivisione in pagine, allo
scopo di garantire un formato di presentazione adeguato delle
Liste dei requisiti per i profili (PRL).
6. Rapportoconaltrenorme
6.1. La presente norma Eurocontrol sostituisce il documento «OLDI
Short Term Interface Control Document (ST-ICD)», parte 3,
edizione 1 della norma Eurocontrol sull'interscambio di dati in
linea (OLDI) [riferimento 13].
6.2. La presente norma Eurocontrol è la prima parte di una serie
prevista di documenti Eurocontrol relativi al controllo di inter-
faccia (ICD) per lo scambio di dati di volo.
7. Statusdegliallegatidellapresentenorma
Gli allegati della presente norma hanno lo status seguente:
— allegato A — normativo
— allegato B — normativo2000R2082 — IT — 15.06.2002 — 001.001 — 156
▼B
— allegato C — normativo
— allegato D — normativo
— allegato E — normativo
— allegato F — informativo— allegato G — informativo— allegato H — informativo
8. Linguautilizzata
Il testo originale della presente norma è stato redatto in lingua
inglese.2000R2082 — IT — 15.06.2002 — 001.001 — 157
▼B
1. INTRODUZIONE
La presente norma Eurocontrol si fonda sul documento «Short
Term Interface Control Document» elaborato dal precedente
sottogruppo tecnico OLDI, che era stato incaricato di definire
nuovi standard di interfaccia per l'utilizzo futuro dell'OLDI tra
Centri di controllo d'area.
In passato, i collegamenti OLDI utilizzavano protocolli di
proprietà come INTERCAUTRA o Datenübertragungs- und
Verteilungssystem (DÜV), che erano utilizzati su circuiti punto a
punto dedicati o reti limitate e richiedevano l'uso di hardware e
software specializzati.
Per il numero più ampio di nuovi collegamenti previsti si è rite-
nuto auspicabile orientarsi verso un'architettura basata su reti ed
adottare norme di telecomunicazioni internazionali, così da poter
implementare i collegamenti in modo economicamente vantag-
gioso grazie alla riduzione del numero di connessioni in ogni
Centro e all'uso di hardware e software standard disponibili sul
mercato.
La presente norma Eurocontrol formalizza ed amplia l'ICD a
breve termine, che è stato riscritto in modo da definire specifiche
più rigorose che migliorino l'interoperabilità. Potrà inoltre servire
come punto di partenza per futuri ICD che rispondano all'evolu-
zione delle esigenze nel campo dello scambio di dati di volo
(FDE), con un utilizzo più diffuso delle reti condivise e l'introdu-
zione di nuove norme relative ai livelli inferiori. La presente
norma Eurocontrol definisce un insieme minimo di funzionalità
che possono essere supportate dalle implementazioni OLDI
esistenti con modifiche minime, usando collegamenti punto a
punto o reti a commutazione di pacchetto conformi alla Racco-
mandazione X.25 del CCITT del 1980 o a sue versioni
successive. Per gli acquisti si possono specificare altre possibilità.
Il presente ICD non impedisce l'attuazione di accordi bilaterali
già conclusi.
I servizi che desiderano utilizzare altri protocolli applicativi in
aggiunta a quello descritto nel presente documento o al suo posto
possono chiedere una modifica del presente protocollo oppure
separare il loro protocollo utilizzando circuiti virtuali diversi.
2. CAMPODIAPPLICAZIONE
2.1. La presente norma Eurocontrol definisce le specifiche relative ad
un'interfaccia di comunicazione dati per l'interscambio di
messaggi contenenti dati di volo tra Centri di controllo d'area
(ACC). È presentata sotto forma di profilo di interconnessione di
sistemi aperti (OSI) secondo la definizione contenuta nel rapporto
tecnico (TR) 10000-2 della International Organisation for Stan-
dardisation/International Electrotechnical Commission (ISO/IEC)
[riferimento 3]. Il profilo riguarda sia i livelli inferiori (profilo
T) sia i livelli superiori (profilo A).
2.2. La presente norma Eurocontrol si applica agli scenari seguenti:
— supporto dell'OLDI così come descritto nella norma Eurocon-
trol No001-92 edizione 1;
— supporto della trasmissione di messaggi applicativi OLDI dai
sistemi degli ACC al sistema dell'Unità centrale di gestione
del flusso (CFMU).
2.3. La presente norma si applica alle connessioni che utilizzano:
— circuiti punto a punto su linea affittata, o
— circuiti punto a punto su rete telefonica pubblica commutata
(PSTN), o
— reti dati a commutazione di pacchetto o reti dati a commuta-
zione di pacchetto interconnesse che dispongono di
un'interfaccia conforme alla Raccomandazione X.25 CCITT
del 1980 o ad una versione successiva.
NOTE
1. Le modalità di interfaccia tra Sistemi di elaborazione dei piani
di volo (FPPS) sono rappresentate nella figura 1.
2. La figura 1 non illustra le eventuali connessioni di riserva
come la PSTN; le indicazioni relative a tali connessioni di
riserva sono riportate nell'Allegato H.2000R2082 — IT — 15.06.2002 — 001.001 — 158
▼B
Figura 1
Modalità di interfaccia
2.4. La presente norma non contiene disposizioni dettagliate sugli
aspetti legati alla sicurezza dell'interfaccia di comunicazione di
dati specificata. Disposizioni generali a questo riguardo sono
contenute nell'allegato e ulteriori indicazioni nell'Allegato H.
3. RIFERIMENTI
3.1. Introduzione
Le norme e i documenti indicati qui di seguito contengono dispo-
sizioni che, attraverso i rimandi contenuti in questo testo,
costituiscono disposizioni della presente norma Eurocontrol.
Le edizioni indicate sono quelle in vigore al momento della
pubblicazione della presente norma Eurocontrol.
Qualsiasi revisione dei documenti ICAO indicati come riferimenti
entra immediatamente a far parte della presente norma Eurocon-
trol.
Le revisioni degli altri documenti indicati come riferimenti non
entrano a far parte delle disposizioni della presente norma Euro-
control se non dopo essere state formalmente esaminate ed
incorporate nella presente norma Eurocontrol.
In caso di conflitto tra le prescrizioni della presente norma Euro-
control ed il contenuto degli altri documenti indicati come
riferimenti prevale la presente norma Eurocontrol.
3.2. Riferimenti
1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the
packet mode and connected to public data networks by dedi-
cated circuit.
2. ISO/IEC TR 10000-1:1992, Information technology —
Framework and taxonomy of International Standardized
Profiles: — Part 1: Framework (2nd edition).
3. ISO/IEC TR 10000-2:1994, Information technology —
Framework and taxonomy of International Standardized
Profiles — Part 2: Principles and Taxonomy for OSI Profiles
(3rd edition).
4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-2000R2082 — IT — 15.06.2002 — 001.001 — 159
▼B
terminating equipment (DCE) for synchronous operation on
public data networks.
5. CCITT Recommendation X.21bis (1988), Use on public data
networks of data terminal equipment (DTE) which is desi-
gned for interfacing to synchronous V-Series modems.
6. ISO/IEC 7776:1994, Information technology — Telecommu-
nications and information exchange between systems —
High-level data link control procedures — Description of
the X.25 LAPB-compatible DTE Data Link procedure
(2nd edition).
7. ISO/IEC 8208:1993, Information Technology — Data
communications — X.25 Packet Layer Protocol for Data
Terminal Equipment (3rd edition).
8. UNI CEI EN ISP 10609-9, Tecnologia dell'informazione —
Profili normalizzati internazionali TB, TC, TD e TE —
Servizio di trasporto in modo connesso su un servizio di
rete in modo connesso — parte 9: Specifiche dipendenti dal
tipo di sottorete per livello rete, livello data link e livello
fisico, relative ad accesso permanente a rete dati a commuta-
zione di pacchetto che utilizza chiamata virtuale.
9. UNI CEN EN ISO/IEC 7498-1, Tecnologia dell'informazione
— Interconnessione dei sistemi aperti (OSI) — Modello di
riferimento di base: il modello base.
10. ISO/IEC 8348:1993, Information technology — Open
Systems Interconnection — Network Service Definition (1st
edition).
11. ISO/IEC 8072:1994, Information technology — Open
Systems Interconnection — Transport service definition (2nd
edition).
12. ISO/IEC 8878:1992, Information Technology — Telecommu-
nications and information exchange between systems — Use
of X.25 to provide the OSI connection-mode Newtork
Service (2nd edition).
13. Eurocontrol Standard for On-Line Data Interchange (OLDI),
Nº 001-92, Edition 1, 1992.
14. UNI CEI EN ISO/IEC 9646-1, Tecnologia dell'informazione
— Interconnessione dei sistemi aperti — Metodologia e strut-
tura delle prove di conformità — parte 1: Concetti generali.
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Part 1 Integration Test Plan Version 1.0,dated 10 May 1996.
16. Eurocontrol FDE ICD Part 1- Reliability, Availability and
Security — Technical Report version 1.0, dated 20 April
1997.
17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface
between DTE and DCE for terminals operating in the packet
mode and accessing a packet switched public data through a
public switched telephone network or an integrated services
digital network or a circuit switched public data network.
18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering
plan for the ISDN era.
19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-swit-
ched signalling system between public network providing
data transmission service.
20. ITU-T Recommendation X.121 (1993), International numbe-
ring plan for public data networks.
4. DEFINIZIONI,SIMBOLIEABBREVIAZIONI
4.1. Definizioni
4.1.1. Ai fini della presente norma Eurocontrol si applicano le defini-
zioni seguenti:
4.1.2. Profilo: insieme di una o più norme di base e, se del caso, iden-
tificazione di particolari classi, sottoinsiemi, opzioni e parametri
di queste norme di base, necessari per svolgere una funzione
specifica [riferimento 2].2000R2082 — IT — 15.06.2002 — 001.001 — 160
▼B
4.1.3. Lista dei requisiti per il profilo (PRL) : i requisiti per il profilo
sono espressi sotto forma di requisiti di conformità, e sono
presentati sotto forma di tabella [riferimento 2].
4.1.4. Profilo T : profilo di trasporto che assicura un servizio di
trasporto in modo connesso [riferimento 3].
4.1.5. Profilo A : profilo di applicazione che richiede un servizio di
trasporto in modo connesso [riferimento 3].
4.1.6. Dichiarazione di conformità al protocollo per l'implementazione
(PICS):: dichiarazione con cui il fornitore di un sistema OSI
indica quali capacità sono state implementate per un particolare
protocollo OSI [riferimento 14].
4.2. Simbolieabbreviazioni
Ai fini della presente norma Eurocontrol si applicano i simboli e
le abbreviazioni seguenti:
ACC Centro di controllo d'area
AFI Authority and Format IdentifierASCII Codice standard americano per l'inter-
scambio di informazioni
ATC Controllo del traffico aereoATCC Centro di controllo del traffico aereo
CAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télégra-
phique et téléphonique (Comitato consultivo
internazionale telegrafico e telefonico)
(divenuto ITU-T)
CFMU Unità centrale di gestione del flussoCUG Gruppo chiuso di utenti
DCE Apparecchiatura terminale per linee dati
DCTS Sistema terminale di comunicazione digitaleDSP Parte specifica del dominioDTE Apparecchiatura terminale per datiDÜV Datenübertragungs- und Verteilungssystem
FDE Scambio di dati di volo
FEP Processore front-endFPDE Scambio di dati relativi al piano di volo
FPPS Sistema di elaborazione dei piani di volo
ICAO International Civil Aviation Organisation
(Organizzazione dell'aviazione civile inter-
nazionale
ICD Documento relativo al controllo di inter-
faccia
IDI Identificatore di dominio iniziale
IDP Parte del dominio inizialeIEC International Electrotechnical Commission
(Commissione elettrotecnica internazionale)
INTERCAUTRA Protocollo inter-CAUTRA
ISO International Standards Organization (Orga-
nizzazione internazionale di normazione)
ITU-T International Telecommunication Union —
Telecommunication Standardization Sector
(Unione internazionale delle telecomunica-
zioni — Settore normalizzazione delle
telecomunicazioni)
ISDN Rete digitale integrata nei servizi
LAPB Procedura di accesso al collegamento bilan-
ciata
LSB Bit meno significativo
M, m Obbligatorio
MSB Bit più significativo
MT Trasferimento di messaggi
NA Non applicabile
NS Servizio di rete2000R2082 — IT — 15.06.2002 — 001.001 — 161
▼B
NSAP Punto d'accesso al servizio di rete
NSDU Unità di dati del servizio di rete
O, O.<n> Opzionale, dove <n> è un è un numerale di
riferimento
o, o.<n> Opzionale, dove <n> è un numerale di rife-
rimento
OLDI Interscambio di dati in linea
OSI Interconnessione di sistemi aperti
PICS Dichiarazione di conformità al protocollo
per l'implementazione
PLP Protocollo di livello pacchetto
PRL Lista dei requisiti per il profilo
PSTN Rete telefonica pubblica commutata
ST-ICD Documento relativo al controllo di inter-
faccia a breve termine
SUT Sistema in prova
T<x> Timer (dove <x> è una lettera singola o
doppia che serve come riferimento)
TA Adattatore di terminale
TSDU Unità di dati del servizio di trasportoTPDU Unità di dati del protocollo di trasportoTR Rapporto tecnico ISO
X Vietato
x Escluso<elemento> Elemento condizionato (che dipende dal
valore dell'elemento)
4.3. Notazioni
4.3.1. Ai fini della presente norma Eurocontrol, i valori binari o una
sequenza di bit sono presentati in forma esadecimale usando la
notazione 'd'H' dove la lettera d rappresenta una cifra o una
sequenza di cifre esadecimali.
4.3.2. Ai fini della presente norma Eurocontrol, la rappresentazione
esadecimale di una sequenza di bit si ottiene prendendo 4 bit per
volta dal bit più significativo (MSB) al bit meno significativo
(LSB).
NOTASe non diversamente specificato nelle norme internazio-
nali a cui si fa riferimento, una sequenza di bit è
trasmessa dall'MSB all'LSB.
4.3.3. Ai fini della presente norma Eurocontrol, lo status del supporto
delle funzioni di una norma di base o della presente norma Euro-
control è indicato in lettere maiuscole (es. M, O, O.<n>, X). Il
significato esatto di ciascun simbolo di status è descritto negli
allegati della presente norma Eurocontrol, prima del loro utilizzo.
4.3.4. Per la definizione del profilo dell'FDE ICD parte 1 nella presente
norma Eurocontrol, lo status del supporto delle funzioni di una
norma di base o della presente norma Eurocontrol è indicato in
lettere minuscole (es. m, o, o.<n>, x).
NOTASi ottiene così una miglior definizione delle funzioni delle
norme di base che sono condizionate, opzionali o dipen-
denti dal valore (cfr. E.3.1).
5. PANORAMICATECNICA
5.1. Piladeiprotocolli
NOTALa pila dei protocolli per il profilo della presente norma
Eurocontrol è illustrata nella figura 2. La figura presenta
i protocolli secondo il modello di riferimento di base OSI
[riferimento 9] allineando la pila ai livelli OSI corrispon-
denti. La pila di protocolli, però, è una specifica relativa
ai sistemi pre-OSI e non supporta le numerose funzioni
offerte dai protocolli OSI dei livelli OSI corrispondenti.2000R2082 — IT — 15.06.2002 — 001.001 — 162
▼B
Figura 2
Pila dei protocolli
5.2. Strutturadelprofilo
NOTE
1. Come indica la Figura 2, la pila dei profili combina più
protocolli di livello inferiore, di cui solo il protocollo X.25 di
livello pacchetto (PLP) [riferimento 1] ed i protocolli di
supporto associati X.21 [riferimento 4] e X.21bis [riferimento
5], sono definiti nelle norme esistenti ISO/IEC e ITU-T. I
protocolli dei livelli superiori sono definiti negli allegati (alle-
gati A, B e C) della presente norma Eurocontrol.
2. I requisiti di conformità per il profilo possono rinviare tanto a
queste specifiche quanto a norme esterne e sono indicati nella
sezione 6. I requisiti dettagliati sono indicati sotto forma di
tabella nelle PRL (allegato E) e nelle dichiarazioni proforma
PICS (le dichiarazioni proforma per i protocolli definiti negli
allegati sono riportate nell'allegato D). L'uso di queste PRL e
delle dichiarazioni proforma PICS per lo sviluppo e/o
l'acquisto è spiegato nell'allegato E.
5.3. Rapportoconversioniprecedentidellespecifiche
NOTE
1. Il presente profilo è basato sul documento ST-ICD elaborato
dal vecchio sottogruppo tecnico OLDI. I protocolli ed i
formati di pacchetto definiti nella presente norma Eurocontrol
sono un sottoinsieme compatibile di quelli del documento ST-
ICD, con la differenza che la presente norma Eurocontrol
stabilisce requisiti più dettagliati per l'uso del PLP X.25,
introduce l'uso obbligatorio del bit M e corregge la difformità
nelle specifiche relative al valore dell'Identificatore di autorità
e di formato (AFI) nell'indirizzo del punto d'accesso al servi-
zio di rete (NSAP).
2. Le principali modifiche di stile introdotte nella presente norma
Eurocontrol riguardano la struttura delle specifiche dell'ICD.
Il Protocollo di trasferimento di messaggi (allegato A) è sepa-
rato dal profilo T. Questo faciliterà l'utilizzo di altri profili T
quando diventerà necessario farlo per far fronte all'evoluzione
delle necessità dell'FDE.
3. Le parti delle specifiche dell'ST-ICD che riguardano il
controllo dei circuiti virtuali X.25 e delimitano i messaggi2000R2082 — IT — 15.06.2002 — 001.001 — 163
▼B
applicativi figurano ora nel Protocollo di intestazione dei
messaggi (allegato B), che costituisce un livello di trasporto
minimo per l'FDE.
6. REQUISITIPERILPROFILO
6.1. Requisitidiconformità
6.1.1. Un'implementazione che dichiara la conformità alle presenti
specifiche deve soddisfare i requisiti presentati nelle sezioni 6.2
e 6.3 seguenti.
6.1.2. Una dichiarazione di conformità deve essere accompagnata da
una dichiarazione di conformità dell'implementazione del profilo,
descritta nell'allegato D e nell'allegato E.
6.2. Requisitirelativi ailivelli superiori
6.2.1. Un'implementazione conforme soddisfa i requisiti della norma di
base, indicati nell'allegato A.
6.2.2. Un'implementazione conforme rispetta i vincoli indicati nella lista
dei requisiti per il profilo, allegato E.7.
6.3. Requisitirelativi ailivelli inferiori
6.3.1. Requisiti relativi al livello di trasporto
6.3.1.1. Un'implementazione conforme soddisfa i requisiti della norma di
base, indicati nell'allegato B.
6.3.1.2. Un'implementazione conforme rispetta i vincoli indicati nella lista
dei requisiti per il profilo, allegato E.8.1.
6.3.1.3. Un'implementazione conforme supporta dimensioni dell'unità di
dati del servizio di trasporto (TSDU) pari ad un massimo di
4 097 ottetti.
NOTAIl primo ottetto della TSDU corrisponde ad un campo
dello header del messaggio (cfr. A.4.10 e B.4.4); gli
ottetti disponibili per i dati di utente sono quindi al
massimo 4 096.
6.3.2. Requisiti relativi al livello di rete
6.3.2.1. Un'implementazione conforme soddisfa i requisiti della norma
ISO/IEC 8208 [riferimento 7] conformemente alla mappatura dei
protocolli riportata nell'allegato C.
6.3.2.2. Un'implementazione conforme rispetta i vincoli indicati nella lista
dei requisiti per il profilo, allegato E.8.2.
6.3.2.3. Un'implementazione conforme è in grado, se supporta un funzio-
namento di tipo apparecchiatura terminale per dati (DTE)-DTE,
di configurare, mediante meccanismi di gestione dei sistemi, la
scelta del ruolo del DTE o dell'apparecchiatura terminale per
linee dati (DCE) per il funzionamento DTE-DTE.
6.3.2.4. Un'implementazione conforme è in grado, in entrambi i ruoli
definiti nel punto 6.3.2.3, di attivare una connessione conforme-
mente alle specifiche dell'allegato C; in altri termini, il
protocollo è totalmente simmetrico.
NOTAAlcune implementazioni esistenti basate sull'ST-ICD
possono non essere in grado di attivare connessioni di
rete conformemente al protocollo dell'allegato C.
6.3.2.5. Un'implementazione conforme ammette per un certo periodo di
tempo il servizio di dimensioni default dei pacchetti non standard,
con un valore di 256 per entrambi i sensi di trasmissione.
6.3.2.6. Un'implementazione conforme utilizza gli indirizzi di NSAP così
come sono definiti nell'allegato C.
6.3.2.7. Un'implementazione conforme imposta il bit D a 0 nei pacchetti
CALL REQUEST, CALL ACCEPTED e DATA
NOTAImpostare D=0 nei pacchetti CALL REQUEST e CALL
ACCEPTED equivale a non usare la conferma di
consegna.2000R2082 — IT — 15.06.2002 — 001.001 — 164
▼B
6.3.3. Requisiti relativi al livello di collegamento
6.3.3.1. Un'implementazione conforme soddisfa i requisiti di conformità
della norma ISO/IEC 7776 [riferimento 6] per il protocollo di
collegamento singolo con procedura di accesso al collegamento
bilanciata (LAPB).
6.3.3.2. Un'implementazione conforme rispetta anche i vincoli indicati
nella lista dei requisiti per il profilo, allegato E.8.3.
6.3.4. Requisiti relativi al livello fisico
Un'implementazione conforme soddisfa i requisiti di conformità
della norma ISO/IEC ISP 10609-9 clausola 7 [riferimento 8].
7. METODIDIPROVA
NOTE
1. Un approccio utilizzabile per le prove di conformità relativa-
mente alle implementazioni delle presenti specifiche è
riportato nell'allegato F.
2. L'uso delle PRL e delle dichiarazioni proforma PICS previste
nelle presenti specifiche per documentare la conformità è illu-
strato nell'allegato E.2000R2082 — IT — 15.06.2002 — 001.001 — 165
▼B
ALLEGATO A (Normativo)
PROTOCOLLODITRASFERIMENTODIMESSAGGI
A.1.Introduzione
Le presenti specifiche definiscono un protocollo per l'implementa-
zione di un servizio semplice di trasferimento di messaggi per
applicazioni che richiedono lo scambio di dati di volo.
A.2.Servizi implementati
Il protocollo di trasferimento di messaggi (MT) implementa i
seguenti servizi non confermati:
MT-Associate: stabilisce un'associazione di trasferimento di
messaggi applicativi;
MT-Data: trasferisce un messaggio applicativo costituito da caratteri
ASCII (codici standard americani per l'interscambio di informa-
zioni);
MT-Abort: termina un'associazione di trasferimento di messaggi
applicativi.
A.3.Servizi richiesti
Il presente Protocollo di trasferimento di messaggi richiede un
sottoinsieme del servizio di trasporto in modo connesso definito
nella norma ISO/IEC 8072 [riferimento 11], come quello offerto
dal protocollo definito nell'allegato della presente norma Eurocon-
trol.
A.4.Specifichedelprotocollo
A.4.1. Introduzione
Il testo qui di seguito descrive il funzionamento di una associazione
di trasferimento di messaggi attivata dall'applicazione. Altre associa-
zioni possono essere supportate sulla stessa interfaccia di rete
ripetendo queste procedure per ogni connessione di trasporto di
livello inferiore.
A.4.2. Tipi di dati
Il presente allegato identifica quattro tipi di messaggi applicativi che
sono equivalenti a quelli definiti nella norma Eurocontrol No001-3-
92, edizione 1:
Messaggi di sistema: questi messaggi sono usati per il monitoraggio
del collegamento (messaggio HEARTBEAT) ed il controllo dell'ap-
plicazione (messaggi STARTUP e SHUTDOWN).
Messaggi operativi: questi messaggi sono legati ad uno specifico
contesto operativo e sono definiti nelle norme e nei documenti
Eurocontrol che si richiamano alla presente norma per l'inter-
scambio di dati. La norma Eurocontrol per l'interscambio di dati in
linea definisce messaggi operativi come i messaggi di attivazione,
(ACT), preavviso di attraversamento di confine (ABI) e riscontro
logico (LAM).
Messaggi operatore: questi messaggi contengono testo libero. Il loro
uso è concordato bilateralmente. Ad esempio, possono essere usati
per scambiare informazioni di prova o per informare l'altra parte
delle azioni dell'operatore.
Messaggi di status: l'uso ed il contenuto di questi messaggi sono
concordati bilateralmente. Ad esempio, possono essere usati per
scambiare informazioni sulla gestione del sistema.
NOTE
1. L'uso dei messaggi di sistema rientra nelle modalità di utilizzo
del presente protocollo ed il loro formato è specificato nel punto
del presente allegato.
2. L'uso ed il formato dei messaggi di status sono soggetti ad
accordo bilaterale e non sono precisati nella presente norma
Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 166
▼B
3. Lo stato del protocollo determina i tipi di messaggi che possono
essere trasmessi, così come indicato nei paragrafi seguenti.
A.4.3. Formazione dell'associazione
A.4.3.1. Il protocollo è inizialmente nello stato IDLE.A.4.3.2. È eseguita la primitiva MT-Associate-Request per stabilire un'asso-
ciazione applicativa e portare il protocollo nello stato
DATA_READY. La primitiva deve essere invocata sia dall'applica-
zione locale che dall'applicazione remota.
A.4.3.3. Innanzitutto è necessario stabilire una connessione di trasporto al
livello inferiore, seguendo le procedure relative alla primitiva T-
connect descritte nell'allegato B punto B.4.1, dopodiché il protocollo
entra nello stato READY. In questo stadio possono essere trasferiti
solo i messaggi di sistema (ed eventualmente i messaggi operatore,
se così è stabilito bilateralmente). Per trasferire un messaggio di
sistema o un messaggio operatore, l'emittente utilizza la primitiva
T-Data (cfr. B.4.4), con il messaggio come parametro.
A.4.3.4. Successivamente è trasmesso un messaggio STARTUP (messaggio
di sistema), il timer Tr (cfr. A.4.7) parte ed il protocollo entra nello
stato ASSOCIATION_PENDING. Se il timer Tr scade mentre il
protocollo è ancora in questo stato il messaggio STARTUP è ritra-
smesso ed il timer riparte.
NOTAIl protocollo rimane nello stato ASSOCIATION_PENDING
fino alla ricezione di un messaggio STARTUP. Scadenze
continue del timer Tr possono essere segnalate localmente.
A.4.3.5. La ricezione del messaggio STARTUP dà luogo alle azioni
seguenti:
— nello stato ASSOCIATION_PENDING è trasmesso un altro
messaggio STARTUP, il protocollo passa allo stato DATA_-
READY ed è segnalata la primitiva MT-Associate-Indication;
— in tutti gli altri stati il messaggio è ignorato.
A.4.3.6. La ricezione del messaggio STARTUP nello stato ASSOCIA-
TION_PENDING corrisponde ad una delle situazioni seguenti:
— l'applicazione remota ha inviato una primitiva MT-Associate-
Request ed il suo protocollo di trasferimento di messaggi è
passato allo stato ASSOCIATION_PENDING, oppure
— il protocollo di trasferimento di messaggi remoto risponde ad un
messaggio STARTUP ricevuto precedentemente ed è passato
allo stato DATA_READY.
NOTAQuesta incertezza è legata al fatto che lo stesso messaggio è
usato per lo STARTUP e per la risposta allo STARTUP. Di
conseguenza, il protocollo di trasferimento di messaggi che
è passato per primo allo stato DATA_READY riceve un
ulteriore messaggio STARTUP. Come indicato nel punto
A.4.3.5, questo messaggio STARTUP è ignorato.
A.4.3.7. Una volta scambiati i messaggi STARTUP l'associazione è stabilita
e tutti i tipi identificati di messaggi possono essere trasferiti (stato
DATA_READY).
A.4.4. Trasferimento di dati
Altri tipi di messaggi sono trasferiti allo stesso modo dei messaggi
di sistema utilizzando il servizio T-Data con il messaggio come
parametro. Questo corrisponde alle primitive di servizio MT-Data-
Request e MT-Data-Indication.
NOTAOgni messaggio è inviato sotto forma di TSDU singola: non
c'è concatenazione o frammentazione dei messaggi a questo
livello.
A.4.5. Rilascio normale dell'associazione
A.4.5.1. L'associazione di trasferimento di messaggi tra due applicazioni può
essere svincolata dall'una o dall'altra applicazione. Questo corri-
sponde alla primitiva di servizio MT-Abort-Request.
A.4.5.2. Si attuano le azioni seguenti:
— nello stato DATA_READY è trasmesso un messaggio SHUT-
DOWN (messaggio di sistema), i timer Tr e Ts sono fermati e
la connessione di trasporto è rilasciata;2000R2082 — IT — 15.06.2002 — 001.001 — 167
▼B
— nello stato ASSOCIATION_PENDING è trasmesso un
messaggio SHUTDOWN (messaggio di sistema), il timer Tr è
fermato e la connessione di trasporto è rilasciata;
— nello stato READY la connessione di trasporto è rilasciata;
— diversamente non è attuata alcuna azione.
NOTAIl messaggio SHUTDOWN non è un preavviso, ma termina
immediatamente l'associazione. Non vi è conferma del
messaggio dall'altra parte.
A.4.5.3. La ricezione del messaggio SHUTDOWN dà luogo alle azioni
seguenti:
— nello stato DATA_READY il timer Ts (cfr. A.4.7) si ferma, è
segnalata l'MT-Abort-Indication e l'interfaccia entra nello stato
ASSOCIATION_PENDING senza che venga inviato un
messaggio STARTUP;
— in tutti gli altri stati non è attuata alcuna azione.
A.4.6. Riformazione dell'associazione
L'applicazione da cui è partito lo svincolo dell'associazione ha la
responsabilità, quando è pronta, di ristabilire l'associazione applica-
tiva e qualsiasi livello inferiore (se necessario).
NOTASe lo svincolo dell'associazione ha avuto come conseguenza
il rilascio della connessione di rete, deve essere seguita la
procedura di formazione dell'associazione specificata nel
punto A.4.3.
A.4.7. Integrità dell'associazione
A.4.7.1. L'integrità dell'associazione tra due applicazioni è assicurata dal ser-
vizio «heartbeat» a riposo.
A.4.7.2. Al passaggio allo stato DATA_READY e in concomitanza con la
trasmissione di qualsiasi tipo di messaggio sulla connessione di
trasporto, (ri)parte un timer Ts configurabile. Se il timer Ts scade
nello stato DATA_READY è trasmesso un messaggio HEART-
BEAT (Messaggio di sistema) (e il timer riparte).
A.4.7.3. Allo stesso modo, al passaggio allo stato DATA_READY e in
concomitanza con la ricezione di qualsiasi messaggio eccetto un
messaggio STARTUP sulla connessione, (ri)parte un timer configu-
rabile Tr. Se il timer Tr scade nello stato DATA_READY è
segnalata l'MT-Abort-Indication, la trasmissione di tutti i messaggi
è interrotta, il timer Ts si ferma ed il timer Tr riparte. L'interfaccia
è nello stato ASSOCIATION_PENDING.
NOTAIl recupero e la risincronizzazione delle applicazioni si
effettuano tramite lo scambio di messaggi STARTUP (cfr.
A.4.3).
A.4.8. Rilascio anormale dell'associazione
A.4.8.1. Può esserci un rilascio anormale dell'associazione:
— in caso di malfunzionamento della connessione di trasporto (es.
per guasto della linea, errore di protocollo),
— in caso di malfunzionamento di uno dei due sistemi o applica-
zioni (dovuto ad esempio a malfunzionamento dell'hardware o
del software; in alcuni casi la connessione di trasporto del livello
inferiore può comunque funzionare).
NOTASecondo la definizione del protocollo di trasporto di cui
all'allegato B non c'è connessione di trasporto end to end.
Di conseguenza, il malfunzionamento della connessione di
trasporto è una conseguenza diretta del malfunzionamento
della connessione di rete.
A.4.8.2. Ci si può accorgere del malfunzionamento di un sistema o di un'ap-
plicazione dallo scadere di una temporizzazione per la ricezione da
questa applicazione di un messaggio HEARTBEAT atteso (cfr.
A.4.7).
A.4.9. Recupero da malfunzionamento
A.4.9.1. Sono due i casi da prendere in considerazione:
— recupero dopo un malfunzionamento della connessione di
trasporto;2000R2082 — IT — 15.06.2002 — 001.001 — 168
▼B
— recupero dopo un malfunzionamento di un'applicazione.
A.4.9.2. In entrambi i casi la riformazione comporta la normale procedura di
formazione dell'associazione (cfr. A.4.3), compreso lo scambio di
messaggi STARTUP.
NOTANel caso di un malfunzionamento al livello dell'applicazione
che non provochi il rilascio della connessione al livello
inferiore, il sistema interessato dal malfunzionamento può
trasmettere un messaggio SHUTDOWN (vale a dire che
l'arresto dell'utente locale è invocato manualmente o nel
quadro della logica dell'applicazione) prima di cercare di
ristabilire il collegamento. Questo rallenta il timer Tr
dell'applicazione remota e può consentire un recupero più
rapido con minori possibilità di perdita di dati.
A.4.10. Formati dei messaggi
A.4.10.1. Struttura generale dei messaggi
Tutti i messaggi sono costituiti da un campo di tipo intero («TYP»)
nell'intervallo 1…63 seguito dal testo del messaggio. Il campo
«TYP» è codificato in un ottetto in un carattere ASCII aggiungendo
'40'H alla rappresentazione binaria del campo (ad es. il valore 3 è
codificato come '43'H, carattere «C»). Il testo del messaggio è costi-
tuito da caratteri ASCII codificati uno per ottetto. Si ha così il
formato seguente:
TYP Testo del messaggio
ottetto 1 ottetto 2 … ottetto n
A.4.10.2. L unghezza del testo del messaggio
Sono supportati messaggi con un testo di lunghezza fino a
4 096 ottetti.
A.4.10.3. Formati dei messaggi di sistema
I messaggi di sistema sono codificati con TYP = 4, codificato come
'44'H. Il testo del messaggio è costituito da due ottetti codificati nel
modo seguente:
— Messaggio Startup: '3031'H (ASCII digits "01");
— Messaggio Shutdown: '3030'H (ASCII digits "00");
— Messaggio Heartbeat: '3033'H (ASCII digits "03").
A.4.10.4. Altri formati di messaggio
Il campo TYP definisce il tipo di messaggio, codificato nel modo
descritto qui sopra:
— valore 1 (codificato come
'41'H)messaggi operativi;
— valore 2 (codificato come
'42'H)messaggi operatore;
— valore 5 (codificato come
'45'H)messaggi di status.
NOTE
1. Il formato del testo del messaggio per i messaggi di status non
rientra nel campo di applicazione della presente norma Eurocon-
trol.
2. Il formato dei messaggi operativi è specificato nelle norme e nei
documenti Eurocontrol che definiscono applicazioni di messaggi-
stica come l'interscambio di dati in linea [riferimento 13].
3. I messaggi operatore sono costituiti da testo ASCII stampabile.
Se questi messaggi sono supportati, deve essere fornita un'inter-
faccia utente per visualizzare i messaggi ricevuti e per consentire
la composizione di messaggi da trasmettere.2000R2082 — IT — 15.06.2002 — 001.001 — 169
▼B
A.5.Tabelle ditransizionedeglistatidiprotocollo
A.5.1. Introduzione
Le tabelle di stato che seguono presentano le specifiche definitive
del protocollo. In caso di discrepanza rispetto al testo principale
qui sopra, prevalgono le specifiche riportate di seguito.
NOTALa notazione usata per descrivere stati, eventi, timer ed
azioni si basa sull'ST-ICD. Tuttavia, le definizioni seguenti
e le azioni che ne risultano sono state rivedute e possono
differire dall'ST-ICD.
A.5.2. Definizioni degli stati
Tabella 1
Definizioni degli stati
Stato Descrizione dello stato Altre informazioni sullo stato
stato 0 IDLE Nessuna connessione di trasporto
stato 1 READY Connessione di trasporto stabilita,
utente locale indisponibile, utente
remoto indisponibile
stato 2 ASSOCIATION_PEN-
DINGConnessione di trasporto stabilita,
utente locale disponibile, utente
remoto indisponibile
stato 3 DATA_READY Utente locale disponibile, utente
remoto disponibile
A.5.3. Eventi possibili
Tabella 2
Eventi possibili
Descrizione dell'e-
ventoAltre informazioni sull'evento
L_data Indica che devono essere inviati dei dati (messaggio operativo,
operatore o di status) dall'utente locale all'utente remoto (primitiva
di MT-Data-Request)
L_shutdown È dato un comando per arrestare l'utente locale (MT-Abort-
Request)
L_startup È dato un comando per avviare l'utente locale (MT-Associate-
Request)
R_data Indica che sono stati ricevuti dei dati dall'utente remoto (T-Data-
Indication, TYP ≠«Sistema»)
R_heartbeat È ricevuto un messaggio HEARTBEAT dall'utente remoto (T-
Data-Indication, TYP = «Sistema», codice messaggio = HEART-
BEAT)
R_shutdown È ricevuto un messaggio SHUTDOWN dall'utente remoto (T-
Data-Indication, TYP = «Sistema», codice messaggio = SHUT-
DOWN)
R_startup È ricevuto un messaggio STARTUP dall'utente remoto (T-Data-
Indication, TYP = «Sistema», codice messaggio = STARTUP)
Ts_timeout Scadenza del timer Ts
Tr_timeout Scadenza del timer Tr
TC_disconnect È stata ricevuta un'indicazione di rilascio della connessione di
trasporto (T-Disconnect-Indication)
TC_setup Evento (es. comando esplicito, richiesta di applicazione) che dà
luogo ad una primitiva T-Connect-Request2000R2082 — IT — 15.06.2002 — 001.001 — 170
▼B
A.5.4. Timer
Tabella 3
Timer
Timer Informazioni sul timer
Tr Scadenza della temporizzazione quando si attende un messaggio
HEARTBEAT o di dati
Ts Scadenza della temporizzazione per l'invio di un messaggio
HEARTBEAT all'utente remoto
Il valore di questi timer è tale per cui Tr = 2Ts + tempo di attraver-
samento.
NOTAI valori tipici di questi timer sono: Ts = 30s, Tr = 70s.
A.5.5. Tabella di transizioni di stato
Tabella 4
Transizioni di stato
Stato Evento Azioni da attuare Nuovo stato
stato 0 TC_setup Il livello di trasporto cerca di
stabilire la/e connessione/i di
trasporto di livello inferiore tra gli
utenti locali e remoti; una volta
stabilita la connessione l'utente è
avvertito (1)stato 1
TC_disconnect Il sistema attua le azioni appro-
priate ma resta nello stato 0stato 0
L_data Ignorati stato 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignorare (l'evento non dovrebbe
verificarsi)stato 0
R_heartbeat
R_shutdown
R_startup
stato 1 L_startup L'utente locale invia un messaggio
STARTUP all'utente remoto, parte
il timer Tr (2)stato 2
R_startup L'utente locale riceve un
messaggio STARTUP dall'utente
remoto, questo messaggio
STARTUP è ignorato perché non
si è verificato un evento L-startupstato 1
L_data Ignorati stato 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignorati stato 1
Ts_timeout
L_shutdown La connessione di trasporto è
svincolatastato 0
TC_disconnect All'utente locale è segnalato che la
connessione di trasporto è discon-
nessa (es. a causa di un errore o di
un arresto dell'utente remoto)stato 02000R2082 — IT — 15.06.2002 — 001.001 — 171
▼B
Stato Evento Azioni da attuare Nuovo stato
stato 2 R_startup L'utente locale riceve un
messaggio STARTUP dall'utente
remoto; partono i timer Tr e Ts;
all'utente locale è segnalato che i
dati possono essere inviati sull'as-
sociazione e la ricezione del
messaggio STARTUP è esplicita-
mente segnalata mediante l'invio
in risposta di un altro messaggio
STARTUP (3)stato 3
Tr_timeout L'utente locale ritrasmette un
messaggio STARTUP se non ha
ricevuto un messaggio STARTUP
dall'utente remoto entro un periodo
di tempo Tr specificato, il timer Tr
ripartestato 2
L_startup Ignorati stato 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown L'utente è invitato ad arrestare
l'associazione: è trasmesso un
messaggio SHUTDOWN, il timer
Tr si ferma e la connessione di
trasporto è svincolatastato 0
TC_disconnect All'utente locale è segnalato che la
connessione di trasporto è discon-
nessa (es. a causa di un errore), iltimer Tr si ferma e l'associazione è
abbandonatastato 02000R2082 — IT — 15.06.2002 — 001.001 — 172
▼B
Stato Evento Azioni da attuare Nuovo stato
stato 3 L_data Il timer Ts riparte stato 3
R_data Il timer Tr riparte stato 3
R_heartbeat
R_startup Se è ricevuto un messaggio
STARTUP dall'utente remoto,
questo è considerato come un
riscontro ad un messaggio
STARTUP inviato in precedenza;
il timer Tr non ripartestato 3
Ts_timeout È inviato un messaggio HEART-
BEAT ed il timer Ts ripartestato 3
L_startup Ignorati stato 3 (4)
TC_setup
R_shutdown Il timer Ts si ferma; l'MT-Abort-
Indication è segnalata all'utente
localestato 2
Tr_timeout Il timer Ts si ferma. L'MT-Abort-
Indication è segnalata all'utente
locale; il timer Tr ripartestato 2
L_shutdown È trasmesso un messaggio SHUT-
DOWN; i timer Tr e Ts si fermano
e la connessione di trasporto è
rilasciatastato 0
TC_disconnect All'utente locale è segnalato che la
connessione di trasporto è discon-
nessa (es. a causa di un errore); i
timer Tr e Ts si fermano e l'asso-
ciazione è abbandonatastato 0
NOTE
(1) Al passaggio allo stato 0, si può considerare che generi automaticamente l'evento TC_setup.
(2) Solo in caso di passaggio allo stato 1 attraverso un evento TC_setup generato automaticamente
come descritto nello stato 0, l'evento L-startup può essere generato automaticamente.
(3) Questo metodo garantisce che ad un messaggio STARTUP proveniente da un utente remoto venga
sempre dato riscontro con un messaggio STARTUP.
(4) Alcune implementazioni esistenti, anteriori alla presente norma Eurocontrol, possono trattare
questo evento come una TC-disconnect, il che implica un ritorno allo stato 0.2000R2082 — IT — 15.06.2002 — 001.001 — 173
▼B
A.5.6. Diagramma delle transizioni di stato
NOTAIl protocollo è descritto nella Figura A.1 sotto forma di
diagramma delle transizioni di stato. Il diagramma è pura-
mente informativo: in caso di conflitto tra il diagramma e le
tabelle di stato precedenti, prevalgono queste ultime.
Figura A.1
Protocollo di trasferimento di messaggi: diagramma delle transizioni
di stato2000R2082 — IT — 15.06.2002 — 001.001 — 174
▼B
ALLEGATO B (Normativo)
PROTOCOLLODIINTESTAZIONEDEIMESSAGGI
B.1.Introduzione
Il presente allegato definisce il protocollo di intestazione dei
messaggi, un protocollo di trasporto minimo destinato ad applicazioni
come OLDI.
B.2.Servizioimplementato
B.2.1. Il protocollo di intestazione dei messaggi corrisponde ad un sottoin-
sieme del servizio di trasporto in modo connesso definito nella norma
ISO/IEC 8072 [riferimento 11], e comprende le primitive di servizio
seguenti.
T-Connect: stabilisce una connessione di trasporto per un'applica-
zione
T-Data: assicura il trasferimento di dati ASCII
T-Disconnect: termina la connessione di trasporto di un'applicazione
B.2.2. Il servizio non supporta la multiplazione, il recupero da errore e la
frammentazione/ricomposizione.
B.3.Serviziorichiesto
Il protocollo presuppone un servizio di rete di base affidabile quale il
servizio assicurato dal protocollo di livello pacchetto X.25.
NOTASu ogni connessione di rete è supportata una sola connes-
sione di trasporto.
B.4.Specifichedelprotocollo
B.4.1. Formazione della connessione
La primitiva T-Connect è implementata utilizzando il servizio N-
connect del servizio di rete del livello inferiore. C'è una corrispon-
denza diretta tra le due serie di primitive (di richiesta e di
indicazione). In alternativa si può usare una connessione di reteesistente (ad es. una connessione di rete stabilita dai meccanismi di
gestione del sistema).
Raccomandazioni
1. In quest'ultimo caso è opportuno effettuare il reset della connes-
sione di rete prima di utilizzarla. La primitiva N-Connect può
essere riemessa automaticamente se non è stata ricevuta una
risposta entro un determinato lasso di tempo.
2. Se è implementata questa procedura di ripetizione automatica, è
opportuno che le chiamate siano ripetute all'incirca ogni 15
secondi.
B.4.2. Misure volte ad evitare connessioni di rete ridondanti
Se c'è una primitiva N-Connect-Request in attesa (cioè non è stata
segnalata una corrispondente primitiva N-Connect-Confirm o N-
Disconnect) ed è segnalata una N-Connect-Indication, il tentativo di
formazione di connessione di rete in arrivo è rifiutato o annullato
mediante l'invio in risposta di una primitiva N-Disconnect-Request,
unicamente quando si riscontrano contemporaneamente le due condi-
zioni seguenti:
— l'indirizzo della N-Connect-Indication dell'NSAP chiamante coin-
cide con l'indirizzo della N-Connect-Request in attesa dell'NSAP
chiamato
— l'indirizzo della N-Connect-Request in attesa dell'NSAP chia-
mante è più grande dell'indirizzo della N-Connect-Request in
attesa dell'NSAP chiamato, effettuando il confronto sulle stringhe
di bit formate dalla codifica binaria preferita di ciascun indirizzo
di NSAP, secondo la definizione contenuta nella norma ISO/IEC
8348 allegato A [riferimento 10] (una stringa è considerata più
grande di ogni sua sottostringa iniziale, es. '8800'H>'88'H).2000R2082 — IT — 15.06.2002 — 001.001 — 175
▼B
B.4.3. Rilascio della connessione
B.4.3.1. Il rilascio della connessione si effettua mediante le primitive di servi-
zio N-Disconnect e N-Reset del servizio di rete del livello inferiore.
B.4.3.2. Per attuare una T-Disconnect-Request si segnala una N-Disconnect-
Request. In alternativa, se non è supportata la formazione di connes-sioni di rete utilizzando primitive N-Connect, la connessione di rete
non è esplicitamente rilasciata.
Raccomandazione In quest'ultimo caso è opportuno resettare la
connessione di rete.
B.4.3.3. Una T-Disconnect-Indication è segnalata alla ricezione di una delle
seguenti primitive di servizio di rete su una connessione di rete corri-
spondente ad una connessione di trasporto stabilita interamente o in
parte:
— N-Disconnect-Indication;
— N-Reset-Indication.
B.4.4. Trasferimento di dati
B.4.4.1. La primitiva T-Data è implementata usando la primitiva N-Data del
servizio di rete del livello inferiore. C'è una corrispondenza diretta
tra le due serie di primitive (di richiesta e di indicazione). La corri-
spondenza si stabilisce mediante un'unità di dati del protocollo di
trasporto (TPDU) che è trasferita dal servizio di rete.
B.4.4.2. La TPDU ha il formato seguente, trasmesso da sinistra a destra. La
struttura dei messaggi definita nel punto A.4.10.1 è inserita nei campi
data(1), data(2)…data(n).
STX LENG ADEST DEST AEMM EMM data(1) ADRdata(2)…
data(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
NOTE
1. Questo header è definito in modo da essere identico a quello
usato nella procedura INTERCAUTRA definita per lo scambio di
messaggi ACT tra CAUTRA Parigi, il sistema 9020D del Centro
di controllo del traffico aereo di Londra ed il Sistema terminale
di comunicazione digitale (DCTS) di Maastricht/Karlsruhe, nel
trasporto dei formati di messaggio definiti nell'; in questo caso il
campo «data(1)» corrisponde al campo TYP.
2. L'uso dei campi ADEST, DEST, AEMM, EMM e ADR con valori
diversi da '40'H non rientra nel campo di applicazione della
presente norma Eurocontrol, ma può essere concordato bilateral-
mente.
B.4.4.3. Il servizio T-Data è limitato al trasferimento di dati in caratteri ASCII
stampabili. In particolare, nessuno degli ottetti di dati deve avere il
valore '03'H (carattere ETX).
B.4.4.4. Un'implementazione conforme supporta unità di dati del servizio di
rete (NSDU) con dimensioni in ottetti fino a 4 105 compresi.
B.4.4.5. Un'implementazione conforme non permette la concatenazione di più
TSDU in una singola NSDU.
B.4.4.6. Un'implementazione conforme non permette la frammentazione di
una singola TSDU in più NSDU.2000R2082 — IT — 15.06.2002 — 001.001 — 176
▼B
ALLEGATO C (Normativo)
PROTOCOLLODIRETE
C.1.Introduzione
Il presente allegato definisce un protocollo di rete di base basato sul
protocollo del livello pacchetto X.25, destinato sia alle reti punto a
punto che alle reti a commutazione di pacchetto per il trasferimento
di dati di volo. Il sottoinsieme di protocollo è compatibile con quello
definito nelle versioni del [riferimento 1] a partire dall'edizione del
1980.
C.2.Serviziofornito
C.2.1. Il protocollo implementa il servizio di rete OSI in modo connesso
così come definito nella norma ISO/IEC 8348 [riferimento 10], con
le seguenti eccezioni.
— gli indirizzi di NSAP sono limitati alla forma definita nel punto;
— non è prevista la possibilità per gli utenti del servizio di rete (NS)
ed il fornitore del servizio di rete di concordare la qualità del ser-
vizio associata ad una connessione di rete;
— non è supportato il trasferimento di NS-User-Data durante la
formazione e il rilascio della connessione di rete, fatte salve le
disposizioni di cui al punto C.5.3.
C.2.2. Non sono offerte le seguenti opzioni del fornitore del servizio di rete:
— conferma di ricezione;
— trasferimento di dati veloce.
C.3.Serviziorichiesto
Il protocollo presuppone l'esistenza di un servizio di collegamento
dati OSI come quello definito nella norma ISO/IEC 7776 (LAPB)
[riferimento 6].
C.4.IndirizzidiNSAP
C.4.1. Introduzione
C.4.1.1. La struttura degli indirizzi di NSAP è conforme alla struttura definita
nella norma ISO/IEC 8348 allegato A [riferimento 10], come illustra
lo schema qui sotto.
C.4.1.2. I componenti dell'indirizzo di NSAP sono definiti qui di seguito:
IDP: Parte del dominio iniziale, comprensiva dei campi AFI e IDI
AFI: Identificatore di autorità e di formato, e
IDI: Identificatore di dominio iniziale
DSP: Parte specifica del dominio
C.4.2. Struttura degli indirizzi di NSAP
C.4.2.1. Ai fini della presente norma Eurocontrol, i componenti degli indirizzi
sono limitati alla forma indicata qui di seguito.
C.4.2.2. Si utilizza il valore AFI 48, che indica un IDI di formato locale con
sintassi astratta decimale.
C.4.2.3. L'IDI è uguale a zero, secondo il formato locale.2000R2082 — IT — 15.06.2002 — 001.001 — 177
▼B
C.4.2.4. Il DSP è costituito da due coppie di cifre decimali, come indicato qui
di seguito:
— la prima coppia è un identificatore di ente di controllo del traffico
aereo (ATC), che identifica un sistema ATC ed è quindi indiretta-
mente una località;
— la seconda coppia è un selettore di ente ATC, che può essere
usato per identificare un particolare end point all'interno di un
ente ATC.
C.4.2.5. La struttura di indirizzo di NSAP che ne risulta è la seguente:
AFI DSP
48 identificatore di ente
ATCselettore di ente ATC
C.4.3. Assegnazione degli identificatori e dei selettori di ente ATC
C.4.3.1. L'assegnazione di identificatori di ente ATC univoci ad ogni sistema
ATC compete ad Eurocontrol, mentre l'assegnazione dei selettori di
ente ATC spetta all'autorità competente dell'amministrazione o
dell'organizzazione ATC.
C.4.3.2. Gli identificatori di ente ATC già assegnati alla data dell'elaborazione
della presente norma sono illustrati nell'.
C.5.Specificherelative alprotocollo
C.5.1. Presentazione generale
Il protocollo si basa sul Protocollo di convergenza dipendente dalla
sottorete per l'X.25 (1980) definito nell'allegato A della norma ISO/
IEC 8878 [riferimento 12], con le differenze seguenti:
— il servizio Fast Select non è utilizzato; tuttavia, la codifica defi-
nita nell'allegato A della norma ISO/IEC 8878 [riferimento 12]
per il campo User Data in formato esteso disponibile con il servi-
zio Fast Select è usata qui con il campo User Data in formato dibase nei pacchetti CALL REQUEST e INCOMING CALL, dal
momento che le restrizioni applicate ai parametri ammessi per il
servizio di rete assicurano che le informazioni codificate siano
contenute in 16 ottetti;
— dei parametri del servizio di rete le cui codifiche sono definite
nella norma ISO/IEC 8878 [riferimento 12], solo gli indirizzi
dell'NSAP chiamato e chiamante (e solo nella forma definita nel
punto) sono inviati nel pacchetto CALL REQUEST;
— il campo User Data non è usato nei pacchetti CALL ACCEPTED,
CALL CONNECTED, CLEAR REQUEST, o CLEAR INDICA-
TION;
— le procedure alternative per la formazione e il rilascio della
connessione di rete non sono usate;
— la conferma di ricezione mediante il bit D non è supportata.
NOTALe prime tre di queste restrizioni assicurano che tutte le
informazioni trasmesse tra due DTE rispettino le limitazioni
fissate per il campo User Data nel PLP X.25 (1980).
C.5.2. Codifica degli indirizzi
Gli indirizzi dell'NSAP chiamato e chiamante sono codificati usando
la codifica binaria preferita definita nella norma ISO/IEC 8348 alle-
gato A [riferimento 10].
C.5.3. Codifica del campo User Data
C.5.3.1. Per effetto dei requisiti sopra indicati, il campo User Data nei
pacchetti CALL REQUEST e INCOMING CALL è codificato nel
modo illustrato qui di seguito. Tutti e 16 gli ottetti sono trasmessi.2000R2082 — IT — 15.06.2002 — 001.001 — 178
▼B
Tabella 1
Codifica del campo User Data
Descrizione del campoSemi-ottetto più signi-
ficativoSemi-ottetto meno
significativo
Ottetto 0: Identità del protocollo bin(1000) bin(0100)
Ottetto 1: Tipo di codice di messaggio bin(0010) bin(0000)
Ottetto 2: Valore del codice di messaggio
(N CR)bin(0000) bin(0001)
Ottetto 3: Tipo di parametro = NSAP chia-
matobin(1100) bin(1001)
Ottetto 4: Lunghezza del parametro bin(0000) bin(0110)
Ottetto 5: Valore del parametro (1oottetto)
= valore AFIbin(0100) bin(1000)
Ottetto 6: Valore del parametro (2oottetto)
= identificatore dell'ente ATCbit più significa-
tivobit meno significa-
tivo
Ottetto 7: Valore del parametro (3oottetto)
= selettore dell'ente ATCbit più significa-
tivobit meno significa-
tivo
Ottetto 8: Tipo di parametro = NSAP chia-
mantebin(1100) bin(1011)
Ottetto 9: Lunghezza del parametro bin(0000) bin(0110)
Ottetto 10: Valore del parametro (1oottetto)
= valore AFIbin(0100) bin(1000)
Ottetto 11: Valore del parametro (2oottetto)
= identificatore dell'ente ATCbit più significa-
tivobit meno significa-
tivo
Ottetto 12: Valore del parametro (3oottetto)
= selettore dell'ente ATCbit più significa-
tivobit meno significa-
tivo
Ottetto 13: Riservato per uso futuro bin(0000) bin(0000)Ottetto 14: Riservato per uso futuro bin(0000) bin(0000)
Ottetto 15: Riservato per uso futuro bin(0000) bin(0000)
C.5.3.2. Gli altri parametri descritti nella norma ISO/IEC 8878
[riferimento 12] non sono utilizzati.
C.5.4. Trattamento degli indirizzi nei pacchetti INCOMING CALL
C.5.4.1. Indirizzi di DTE
L'indirizzo del DTE chiamante in un pacchetto INCOMING CALL è
validato a fronte di un elenco locale di indirizzi di DTE remoti validi
per il sistema. Se è individuato un indirizzo non valido, la chiamata è
svincolata.
NOTE
1. L'eventuale indirizzo del DTE chiamato in un pacchetto INCO-
MING CALL può essere validato anche a fronte di un elenco
(generalmente di un elemento) di indirizzi di DTE locali validi
per il sistema.
2. In alcuni casi l'indirizzo del DTE di un ente può variare nel
valore e/o nella lunghezza a seconda che l'ente agisca da sistema
chiamante o da sistema chiamato. Si deve perciò fare particolare
attenzione a questo aspetto quando è specificata o implementata
la funzione di validazione dell'indirizzo del DTE.
C.5.4.2. Indirizzi di NSAP
L'indirizzo dell'NSAP chiamante codificato nel modo descritto in
precedenza in un pacchetto INCOMING CALL è validato a fronte
di un elenco locale di indirizzi di NSAP remoti validi per il sistema.
Se è rilevato un indirizzo non valido, la chiamata è svincolata.
NOTAL'indirizzo dell'NSAP chiamato può essere validato anche a
fronte di un elenco (generalmente di un elemento) di indirizzi
di NSAP locali validi per il sistema.2000R2082 — IT — 15.06.2002 — 001.001 — 179
▼B
C.5.5. Trasferimento di dati
C.5.5.1. Come descritto nella norma ISO/IEC 8878 allegato A.5.3
[riferimento 12], le NSDU sono trasferite nel campo User Data di
un pacchetto DATA.
NOTADi conseguenza, è proibito trasmettere più di un messaggio
utente, come ad esempio un messaggio OLDI, per pacchetto
X.25 o sequenza di bit M.
C.5.5.2. Le NSDU di lunghezza superiore al massimo consentito nel circuito
virtuale per gli User Data sono segmentate e trasmesse nei campi
User Data di una sequenza di pacchetti DATA che avranno tutti,
tranne l'ultimo, la lunghezza massima ed il bit M impostato (ad indi-
care che seguiranno altri dati).
C.5.5.3. Una volta ricevuti, i campi User Data di una sequenza contraddistinta
dall'uso del bit M sono ricomposti in modo da formare la NSDU rice-
vuta.2000R2082 — IT — 15.06.2002 — 001.001 — 180
▼B
ALLEGATO D (Normativo)
DICHIARAZIONIPROFORMAPICSDICONFORMITÀALPROFILO
D.1.Introduzione
D.1.1. Il fornitore di un'implementazione di protocollo dichiarata conforme
alle specifiche di cui agli allegati A-C compila le dichiarazioni
proforma PICS seguenti.
NOTADispensa dalla riserva dei diritti d'autore per le dichiara-
zioni proforma PICS: gli utilizzatori della presente norma
Eurocontrol possono riprodurre liberamente le dichiarazioni
proforma PICS contenute nel presente allegato per usarle
per lo scopo a cui sono destinate, nonché pubblicare le
dichiarazioni PICS compilate.
D.1.2. Una dichiarazione proforma PICS compilata è la PICS per l'imple-
mentazione in questione. La PICS è una dichiarazione che indica le
capacità e le opzioni del protocollo che sono state implementate.
D.1.3. La PICS può avere più utilizzi, e in particolare servire:
— a chi implementa il protocollo come lista di controllo per ridurre
il rischio mancata ottemperanza alla norma dovuta a una svista;
— al fornitore e all'acquirente o potenziale acquirente dell'implemen-
tazione come indicazione dettagliata delle capacità
dell'implementazione, rispetto alla base comune costituita dalla
dichiarazione proforma PICS standard;
— all'utente o potenziale utente dell'implementazione come mezzo di
controllo iniziale della possibilità di interoperare con un'altra
implementazione (si noti che la possibilità di interoperare non
può mai essere garantita del tutto, ma l'incompatibilità delle
PICS è spesso indicativa di una impossibilità di interoperare);
— a chi realizza prove sul protocollo come base per selezionare
prove appropriate con cui valutare le dichiarazioni di conformità
dell'implementazione.
D.2.Istruzioniperlacompilazionedelledichiarazioni proformaPICS
D.2.1. Struttura generale delle dichiarazioni proforma PICS
D.2.1.1. L'identificazione dell'implementazione e il riassunto del protocollo
costituiscono la prima parte di ogni dichiarazione proforma PICS e
vanno compilate nel modo indicato inserendo le informazioni neces-
sarie per identificare in modo completo sia il fornitore che
l'implementazione.
D.2.1.2. La parte principale della dichiarazione proforma PICS è un questio-
nario di formato fisso. Le risposte alle varie domande vanno inserite
nell'ultima colonna a destra, barrando la casella appropriata in caso di
scelta ristretta (in genere Sì o No), oppure immettendo un valore o un
insieme o campo di valori.
NOTE
1. Ogni elemento è identificato da un riferimento univoco riportato
nella prima colonna; la seconda colonna contiene la domanda a
cui rispondere; la terza colonna contiene il riferimento o i riferi-
menti ai punti della presente norma Eurocontrol in cui è descritto
l'elemento. Le altre colonne sono utilizzate per indicare lo status
dell'elemento (supporto obbligatorio, opzionale, vietato o condi-
zionato) e per rispondere alle domande; cfr. anche il punto D.2.4.
qui di seguito.
2. Un fornitore può anche fornire, o essere tenuto a fornire, altre
informazioni definite informazioni supplementari o informazioni
sulle difformità. Ogni tipo di informazioni supplementari, se
presenti, deve essere riportato in una sottosezione di elementi
indicata rispettivamente come <i> o X<i> per consentire i
rimandi, dove <i> è qualsiasi identificazione non ambigua dell'e-
lemento (ad es. un semplice numerale); non vi sono altre
restrizioni di formato o di presentazione.
D.2.1.3. Una dichiarazione proforma PICS compilata, completa di eventuali
informazioni supplementari e informazioni sulle difformità, è definita
«dichiarazione di conformità dell'implementazione al protocollo».2000R2082 — IT — 15.06.2002 — 001.001 — 181
▼B
NOTAQuando un'implementazione può essere configurata in più
modi, un'unica PICS può essere sufficiente per descrivere
tutte le configurazioni possibili. Il fornitore, tuttavia, può
presentare più PICS, ciascuna delle quali relativa ad un
sottoinsieme di configurazioni dell'implementazione, se
questo semplifica e rende più chiara la presentazione delle
informazioni.
D.2.2. Informazioni supplementari
Le informazioni supplementari permettono al fornitore di presentare
altre informazioni volte a facilitare l'interpretazione della PICS.
NOTE
1. Non è previsto né richiesto che sia presentata una mole conside-
revole di informazioni supplementari, ed una PICS può essere
considerata completa anche senza alcuna informazione supple-
mentare. Queste informazioni possono servire ad esempio a
presentare i modi in cui si può adattare un'implementazione
affinché possa funzionare in ambienti e configurazioni diversi;
oppure a dare una spiegazione sintetica (magari riferita alle
necessità di un'applicazione specifica) dei motivi dell'esclusione
di elementi che, benché opzionali, sono comunque generalmente
presenti nelle implementazioni del protocollo in questione.
2. Riferimenti alle informazioni supplementari possono essere ripor-
tati accanto alle risposte del questionario, e possono essere
inclusi nelle informazioni sulle difformità.
D.2.3. Informazioni sulle difformità
D.2.3.1. In qualche caso può accadere che un fornitore desideri rispondere ad
un elemento di carattere obbligatorio o vietato (dopo che eventuali
condizioni sono state applicate) in un modo che non è compatibile
con il requisito indicato. In questo caso nella colonna Supportato
non è possibile trovare una risposta confacente: il fornitore, allora,
deve inserire la risposta mancante nella colonna Supportato, aggiun-
gendo l'indicazione X<i> per indicare il riferimento alle informazioni
sulle difformità.
D.2.3.2. Il fornitore indica poi le motivazioni appropriate nelle informazioni
sulle difformità.
D.2.3.3. Un'implementazione in cui esiste una difformità non è conforme alle
presenti specifiche.
NOTALa situazione sopra descritta può essere motivata dalla
presenza nella norma di un difetto segnalato la cui corre-
zione dovrebbe modificare il requisito non soddisfatto
dall'implementazione.
D.2.4. Elementi condizionati
D.2.4.1. I singoli elementi condizionati sono indicati da un simbolo condizio-
nato della forma «<elemento>: 
» nella colonna Status, dove
«<elemento>» è un riferimento che compare nella prima colonna
della tabella per qualche altro elemento, e «
» è un simbolo di
status (M, O, O.<n> o X).
NOTAUna dichiarazione proforma PICS può contenere diversi
elementi condizionati, per i quali sia l'applicabilità dell'ele-
mento stesso che il suo status, se l'elemento è applicabile
(obbligatorio, opzionale o vietato) dipendono dall'eventuale
supporto di altri elementi.
D.2.4.2. Se l'elemento a cui fa riferimento il simbolo condizionato è suppor-
tato, l'elemento condizionato è applicabile e il suo status è indicato
da «
»: la colonna Supportato va compilata nel modo consueto.
Diversamente, l'elemento condizionato non è applicabile e la risposta
da indicare è NA (non applicabile).
D.2.4.3. Ciascun elemento il cui riferimento è usato in un simbolo condizio-
nato è indicato con un asterisco nella colonna Elemento.2000R2082 — IT — 15.06.2002 — 001.001 — 182
▼B
D.3.Dichiarazione proforma PICS per il Protocollo di trasferimento
dimessaggi
D.3.1. Abbreviazioni e simboli speciali
D.3.1.1. Simboli di status
M: obbligatorio
O: opzionale
D.3.1.2. Riferimenti degli elementi
Gli elementi della dichiarazione proforma PICS sono identificati da
riferimenti mnemonici. Gli elementi della PICS che trattano funzioni
connesse sono identificati da riferimenti che hanno la stessa lettera o
coppia di lettere iniziale, in maiuscole. Qui di seguito è riportato un
elenco di queste iniziali, nell'ordine in cui appaiono i gruppi di
elementi nella dichiarazione proforma PICS.
— MTsy, MTop, MTst, MTor tipi di messaggio
— MAE, MAR, MCI, MDT,
MAVprocedure
— MEsu, MEsd, MEhb, MEty codifiche
— MNmsg dimensioni del messaggio
— Ts, Tr timer
D.3.2. Identificazione
2000R2082 — IT — 15.06.2002 — 001.001 — 183
▼B
D.3.3. Implementazione del protocollo
D.4.DichiarazioneproformaPICSperilprotocollodiintestazionedei
messaggi
D.4.1. Abbreviazioni e simboli speciali
D.4.1.1. Simboli di status
M obbligatorio
O opzionale
O.<n> opzionale, ma è necessario che sia supportata almeno
una delle opzioni del gruppo identificate dallo stesso
numerale <n>
X vietato<elemento> simbolo di elemento condizionato, che dipende dal
supporto indicato per l'<elemento> (cfr. D.2.4)2000R2082 — IT — 15.06.2002 — 001.001 — 184
▼B
D.4.1.2. Abbreviazioni
NA non applicabile
D.4.1.3. Riferimenti degli elementi
Gli elementi della dichiarazione proforma PICS sono identificati da
riferimenti mnemonici. Gli elementi della PICS che trattano funzioni
connesse sono identificati da riferimenti che hanno la stessa lettera o
coppia di lettere iniziale, in maiuscole. Qui di seguito è riportato un
elenco di queste iniziali, nell'ordine in cui appaiono i gruppi di
elementi nella dichiarazione proforma PICS.
— IHC1, IHC2, IHC3, IHC4,
IHCCformazione della connessione
— IHR1, IHR2 rilascio della connessione
— IHT1, IHTx trasferimento dati— Tcr timer
D.4.2. Identificazione
2000R2082 — IT — 15.06.2002 — 001.001 — 185
▼B
D.4.3. Implementazione del protocollo
D.5.Dichiarazione proformaPICSperil protocollodirete
D.5.1. Abbreviazioni e simboli speciali
D.5.1.1. Simboli di status
M obbligatorio
O opzionale
D.5.1.2. Riferimenti degli elementi
Gli elementi della dichiarazione proforma PICS sono identificati da
riferimenti mnemonici. Gli elementi della PICS che trattano funzioni
connesse sono identificati da riferimenti che hanno la stessa lettera o
coppia di lettere iniziale, in maiuscole. Qui di seguito è riportato un2000R2082 — IT — 15.06.2002 — 001.001 — 186
▼B
elenco di queste iniziali, nell'ordine in cui appaiono i gruppi di
elementi nella dichiarazione proforma PICS.
— SNDCP1 campo di identificazione del
protocollo
— NCRdae, NCRgae, NCCx,
NDRxparametri nei messaggi di proto-
collo
— NCD1, NCD2, NCN1, NCN2 validazione degli indirizzi
— NDT trasferimento dati
D.5.2. Identificazione
2000R2082 — IT — 15.06.2002 — 001.001 — 187
▼B
D.5.3. Implementazione del protocollo
2000R2082 — IT — 15.06.2002 — 001.001 — 188
▼B
ALLEGATO E (Normativo)
LISTADEIREQUISITIPERILPROFILO
E.1.Introduzione
E.1.1. Il presente allegato riporta la PRL per il profilo FDE ICD definito
nella presente norma Eurocontrol. La dichiarazione di conformità
dell'implementazione per un'implementazione per la quale si dichiara
la conformità al presente profilo deve essere stilata secondo le istru-
zioni riportate qui di seguito.
NOTALe dichiarazioni proforma del presente allegato si basano su
quelle che accompagnano le norme di base a cui si fa riferi-
mento.
E.1.2. Un'implementazione conforme soddisfa i requisiti di conformità
obbligatori delle norme di base a cui si fa riferimento nel presente
profilo.
E.2.RuolodellaPRLedelledichiarazioniproformaPICS
La presente sezione (E.2) è di natura informativa, e non costituisce
una disposizione della presente norma Eurocontrol.
— Nelle PRL e nelle dichiarazioni proforma PICS i requisiti di
conformità sono presentati sotto forma di tabella allo scopo di
fornire una lista di controllo delle caratteristiche che devono o
possono essere implementate. I concetti sono definiti e descritti
nella norma ISO/IEC 9646-1 [riferimento 14] (la Raccomanda-
zione X.290 dell'ITU-T è equivalente) e nella norma ISO/IEC
TR 10000-1 [riferimento 2]
— Un profilo riunisce e seleziona le opzioni di diverse norme di
base allo scopo di rispondere ad una funzione particolare di elabo-
razione delle informazioni. I requisiti fissati da ciascuna norma di
base sono indicati in una specifica dichiarazione proforma PICS.
La PRL comprende il sottoinsieme degli elementi delle dichiara-
zioni proforma PICS delle norme di base che sono imposti dal
profilo, insieme ai requisiti specifici del profilo; definisce le
risposte che devono essere riportate nelle dichiarazioni proforma
PICS delle norme di base per assicurare la conformità al profilo.
La PRL contiene inoltre elementi di tipo PICS che sono specifici
del profilo (o almeno un elemento che permetta di verificare se
tutte le dichiarazioni proforma PICS richieste sono state compilate
correttamente); queste sezioni devono essere compilate insieme
alle dichiarazioni proforma PICS delle norme di base. Le dichia-
razioni proforma compilate formano insieme la dichiarazione di
conformità dell'implementazione del profilo (ICS).
— Secondo la metodologia della norma ISO/IEC TR 10000-1 [riferi-
mento 2], una dichiarazione di conformità ad un profilo deve
essere supportata da dichiarazioni proforma PICS compilate
secondo la PRL. L'uso di questi documenti dipende dall'approccio
scelto per l'acquisizione di un'implementazione FDE ICD.
— Si possono immaginare diversi approcci possibili per un'imple-
mentazione FDE:
— Implementazione interna da parte di un'amministrazione od
organizzazione nazionale: la PRL dovrebbe essere usata come
base di riferimento per le specifiche dei requisiti e delle prove
di accettazione dell'implementazione; l'ICS compilata
dovrebbe essere prodotta nel quadro della procedura di accet-
tazione.
— Implementazione del profilo da parte di un appaltatore: il
materiale è utilizzato e prodotto come per un'implementazione
interna, ma l'appaltatore dovrebbe fornire l'ICS. Questa condi-
zione deve essere un'obbligazione contrattuale.
— Implementazione del profilo da parte di un appaltatore nel
quadro di un contratto chiavi in mano o di un contratto di
integrazione di sistemi: il materiale è utilizzato e prodotto
come per un'implementazione interna, ma l'appaltante deve
farlo internamente e fornire l'ICS compilata. La conformità alprofilo assicura, ad esempio, che un fornitore che lavora per
due amministrazioni diverse non possa introdurre protocolli
propri per soddisfare i requisiti relativi all'FDE, e quindi
contribuisce a far sì che il controllo sia nelle mani delle am-
ministrazioni appaltanti.2000R2082 — IT — 15.06.2002 — 001.001 — 189
▼B
— Integrazione di prodotti disponibili sul mercato in un'imple-
mentazione del profilo in tutti i casi suindicati: al fornitore di
un prodotto dovrebbe essere chiesto di presentare le dichiara-
zioni proforma PICS inerenti al prodotto compilate secondo la
PRL qui riportata, e di garantire la conformità del prodotto ai
requisiti del profilo che sono applicabili; questa PICS può
essere poi trasmessa come elemento dell'ICS del profilo.
— Dopo l'implementazione è opportuno conservare l'ICS nella docu-
mentazione relativa all'implementazione; può servire perprevedere l'interoperabilità con altre amministrazioni e per indivi-
duare le modifiche che potrebbero essere necessarie in caso di
adozione di altri protocolli.
E.3.Notazione
E.3.1. Lo status delle varie caratteristiche è indicato nella PRL con la nota-
zione qui di seguito, tratta dalla norma ISO/IEC TR 10000-1
[riferimento 2]:
m obbligatorio
o opzionale
- non applicabile (vale a dire logicamente impossibile nel campo di
applicazione del profilo)
x escluso
NOTE
1. Si possono utilizzare combinazioni di due caratteri; in questo caso
il primo carattere si riferisce allo status (di implementazione)
statico, il secondo all'uso dinamico; «mo», quindi, significa
«implementazione obbligatoria, utilizzo opzionale».
2. La notazione «o.<n>» è usata per indicare una serie di opzioni
selezionabili (il che significa che almeno una delle opzioni della
serie deve essere implementata) con lo stesso identificatore n.
3. Un servizio contrassegnato dalla lettera «x» può essere incluso
comunque in un'implementazione purché non sia usato quando
l'implementazione è utilizzata conformemente al profilo.
4. L'uso delle caratteristiche indicate con la lettera 'x' deve essere
concordato bilateralmente. In questo caso, è opportuno rivedere
lo status delle caratteristiche visto che potrebbero essere di inte-
resse per altre implementazioni.
E.3.2. Per i predicati la notazione usata è la seguente:
<predicato>:
introduce un gruppo di elementi, tutti condizionati in base al <predi-
cato> (l'estensione del gruppo è indicata dalla presentazione).
<predicato>:
introduce un elemento singolo, condizionato in base al <predicato>.
NOTAIl predicato può essere l'identificatore di una caratteristica
del profilo o una combinazione booleana di predicati (« ¬»è
il simbolo di negazione logica).
E.3.3. I requisiti delle norme di base sono indicati usando la stessa nota-
zione ma in lettere maiuscole (M, O, O.<n>, X).
E.4.Istruzioniperlacompilazionedelledichiarazioni proformaPICS
E.4.1. Per preparare l'ICS per il profilo si compilano le dichiarazioni
proforma PICS per le norme di base a cui si fa riferimento, unita-
mente agli altri elementi PICS relativi al profilo indicati nel presente
allegato.
E.4.2. Quando il profilo affina le caratteristiche delle norme di base si appli-
cano i requisiti indicati in questa PRL (nella colonna «Caratteristiche
del profilo», ove questa è presente) per limitare le risposte ammissi-
bili nelle dichiarazioni proforma PICS della norma di base.
E.4.3. Quando il profilo fissa requisiti aggiuntivi si compila la colonna delle
risposte per tali elementi. In questa colonna la risposta va scelta tra
quelle proposte o indica un valore o una gamma di valori del para-
metro.
E.4.4. Se un requisito obbligatorio non è soddisfatto si devono fornire infor-
mazioni sulla difformità immettendo un riferimento X, dove è un2000R2082 — IT — 15.06.2002 — 001.001 — 190
▼B
identificatore univoco che rimanda ad un'acclusa motivazione della
non conformità.
NOTAUna difformità si può avere ad esempio nel caso di un'imple-
mentazione per la quale è stato presentato un rapporto di
difetto relativo ad una disposizione del profilo; se il rapporto
di difetto è accettato, l'implementazione risulterà conforme.
E.5.Riferimenti
E.5.1. Il presente profilo rimanda alle specifiche dei protocolli seguenti:
— protocollo di trasferimento di messaggi (allegato A della presente
norma Eurocontrol);
— protocollo di intestazione dei messaggi (allegato B della presente
norma Eurocontrol);
— protocollo di rete in modo connesso a norma ISO/IEC 8208 (alle-
gato C della presente norma Eurocontrol);
— ISO/IEC 7776 [riferimento 6];— norme relative al livello fisico richiamate nella clausola 1 della
Raccomandazione X.25 dell'ITU-T (1993) 1 [riferimento 1].
E.5.2. Poiché non esistono dichiarazioni proforma PICS specifiche per le
norme relative al livello fisico si utilizzano le dichiarazioni proforma
PICS provvisorie per il livello fisico indicate nella norma ISO/IEC
ISP 10609-9 clausola A.4 [riferimento 8].2000R2082 — IT — 15.06.2002 — 001.001 — 191
▼B
E.6.Dichiarazione diconformità
E.6.1. Presentazione generale della conformità
2000R2082 — IT — 15.06.2002 — 001.001 — 192
▼B
E.6.2. Requisiti di conformità dinamica
E.7.Requisitirelativi ailivelli superiori
Tabella 3
Protocollo di trasferimento di messaggi
Caratteristiche delle norme di baseCaratteristiche del
profilo
Element-
oProtocollo di trasferimento
di messaggiRiferimenti Status Riferimenti Status
MTst — messaggi di status A.4.2 O ox
MTor — messaggi operatore A.4.2 O ox
E.8.Requisitirelativi ailivelli inferiori
E.8.1. Requisiti relativi al livello di trasporto
Tabella 4
Protocollo di intestazione dei messaggi
Caratteristiche delle norme di baseCaratteristiche del
profilo
Element-
oProtocollo di intestazione
dei messaggiRiferimenti Status Riferimenti Status
IHTx Uso dei campi
ADEST, DEST,
AEMM, EMM e ADR
con valori diversi da
'40'HB.4.4 O ox
E.8.2. Requisiti relativi al livello di rete
Le PRL di questa sezione si basano sulla dichiarazione proforma
PICS della norma ISO/IEC 8208:1993 [riferimento 7]. I dati della
colonna «Riferimenti» sotto «Caratteristiche della norma di base»
nelle tabelle che seguono si riferiscono alle clausole di tale norma.2000R2082 — IT — 15.06.2002 — 001.001 — 193
▼B
E.8.2.1. Caratteristiche generali del DTE
Tabella 5
Caratteristiche generali del DTE
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oCaratteristiche generali del
DTERiferimenti Status Riferimenti Status
Servizio supportato:
Vs — chiamata virtuale O.1 m
Vp — circuito virtuale
permanenteO.1 x
Ambienti supportati: 3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2
Ec/8 — DTE/DCE(1988) O.2 6.3.2 o.2
Ec/4 — DTE/DCE(1984) O.2 6.3.2 o.2Ec/0 — DTE/DCE(1980) O.2 6.3.2 o.2
Et/t — DTE/DTE nel ruolo
fisso di DTEO.2 6.3.2 o.2
Et/c — DTE/DTE nel ruolo
fisso di DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE con sele-
zione dinamica del
ruolo4.5 Vs: O.2 x
Numerazione della
sequenza di pacchetti
supportata:
M8 — Modulo 8 13.2, 12.1.1,
tabella 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
tabella 3O.3 x
Servizio utente opzio-
nale Numero di riferi-
mento per
assegnazione alterna-
tiva degli identificatori
dei canali logici:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, fig. 31
RNa — senza ritorno all'uso
delle gamme dei
canali logici13.29.2.1 Et:O
¬Et:Xx
RNb — con possibilità di
ritorno all'uso delle
gamme dei canali
logici13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Procedure, tipi e formati di pacchetto
Tabella 6
Funzioni del livello pacchetto indipendenti dai canali logici
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oFunzioni del livello
pacchetto indipendenti dai
canali logiciRiferimenti Status Riferimenti Status
Le seguenti funzioni
del livello pacchetto
sono supportate?
Z2s Invio di pacchetto
Diagnostic12.7, tabella 24 Et:O
¬Et:Xx2000R2082 — IT — 15.06.2002 — 001.001 — 194
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oFunzioni del livello
pacchetto indipendenti dai
canali logiciRiferimenti Status Riferimenti Status
Z4i Avvio della registra-
zione on-line dei
servizi:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— invio di REGI-
STRATION
REQUEST12.9.1
— ricezione di REGI-
STRATION CONFIR-
MATION12.9.2, tabella
10
Z4r Risposta alla registra-
zione on-line dei
servizi:13.1, 13.1.1.1,
13.1.1.4Et:O –
— ricezione di REGI-
STRATION
REQUEST12.9.1
— invio di REGI-
STRATION CONFIR-
MATION12.9.2., tabella
10
Tabella 7
Formazione della connessione
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oFormazione della connes-
sioneRiferimenti Status Riferimenti Status
Le chiamate virtuali in
uscita sono supportate:5.2.1, 5.2.5,
tabella 33
S1a — Fast Select, senza
limitazioni sulla
risposta?5.2.4, 13.16 O x
S1b — Fast Select con
limitazioni sulla
risposta?13.16 O x
S1c — non Fast Select? 5.2.4 O m
SP1b CALL REQUEST,
formato di base12.2.3.1 S1c:M
S1ab: O.4m
SP1e invio di CALL
REQUEST, formato
esteso12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b ricezione di CALL
CONNECTED,
formato di base12.2.4.1 S1ac:M m
SP2e ricezione di CALL
CONNECTED,
formato esteso12.2.4.1,
12.2.4.2S1a:M –
L'indirizzamento alter-
nativo per le chiamate
virtuali in uscita è
supportato:13.28
— usando A = 1 ed il
formato blocco indi-
rizzi allargato?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— usando il servizio
Estensione indirizzo
chiamata?13.28.2.2 Ec/3:O
¬Ec/3:Xx2000R2082 — IT — 15.06.2002 — 001.001 — 195
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oFormazione della connes-
sioneRiferimenti Status Riferimenti Status
Le chiamate virtuali in
entrata sono suppor-
tate:5.2.2., 5.2.5,
tabella 33
S2a — Fast Select con
accettazione possibile?5.2.3, 13.17 O –
S2b — Fast Select, sempre
svincolata?13.17 O m
S2c — non Fast Select con
accettazione possibile?5.2.3 O m
S2d — non Fast Select,
sempre svincolata?5.2.3 O x
SP3b ricezione di INCO-
MING CALL, formato
di base12.2.3.1 S2:M m
SP3e ricezione di INCO-
MING CALL, formato
esteso12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b invio di CALL
ACCEPTED, formato
di base12.2.4.1 S2c:M
S2axc:
O.5m
SP4e invio di CALL
ACCEPTED, formato
esteso12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
La negoziazione del bit
D è supportata:
DN1 —per chiamate virtuali
in uscita6.3 S1ac:O m
DN2 —per chiamate virtuali
in entrata6.3 S1ac:O m
NOTA Il bit D è sempre negoziato al valore 0.
Tabella 8
Svincolo della connessione
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oSvincolo della connessione Riferimenti Status Riferimenti Status
Lo svincolo della
connessione è suppor-
tato, per:5.5.4., tabella 33
C1 — risposta ad indica-
zione di svincolo?5.5.2 O m
C2a — abbandono di un
tentativo di chiamata
virtuale in uscita?5.4, 5.5.1, 5.5.3 S1:O o
C2b — rifiuto di una chia-
mata virtuale in
entrata?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd :
Om
C2c — comando di svin-
colo di una chiamata
virtuale formata?5.5.1, 5.5.3 O o
CP1b ricezione di CLEAR
INDICATION,
formato di base12.2.5.1 Cany:M m2000R2082 — IT — 15.06.2002 — 001.001 — 196
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oSvincolo della connessione Riferimenti Status Riferimenti Status
CP1e ricezione di CLEAR
INDICATION,
formato esteso12.2.5.1,
12.2.5.2Cany:M –
CP2b invio di CLEAR
CONFIRMATION,
formato di base12.2.6.1 C1:M m
CP2e invio di CLEAR
CONFIRMATION,
formato esteso12.2.6.1,
12.2.6.2C1rn:M x
CP3b invio di CLEAR
REQUEST, formato di
base12.2.5.1 C2a:M
C2bcxa:
O.6m
CP3e invio di CLEAR
REQUEST, formato
esteso12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b ricezione di CLEAR
CONFIRMATION,
formato di base12.2.6.1 C2:M m
CP4e ricezione di CLEAR
CONFIRMATION,
formato esteso12.2.6.1,
12.2.6.2C2rnci:M –
Tabella 9
Reset dei canali logici
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oReset dei canali logici Riferimenti Status Riferimenti Status
Il reset è supportato: 8, 8.4, tabella 34
RSi — come chiamante? 8.1, 8.3 O mm
invio di RESET
REQUEST12.5.1
ricezione di RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.1
RSr — come chiamato? 8.2 O mm
ricezione di RESET
INDICATION12.5.1
invio di RESET
CONFIRMATION12.5.2
Tabella 10
Procedure di errore
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oProcedure di errore (servi-
zio Chiamata virtuale)Riferimenti Status Riferimenti Status
La procedura ERROR-
C corrisponde a:5.2.1, 5.4, 8.1,
tabella 33
W1a — svincolo della chia-
mata virtuale?O.7 m2000R2082 — IT — 15.06.2002 — 001.001 — 197
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oProcedure di errore (servi-
zio Chiamata virtuale)Riferimenti Status Riferimenti Status
W1b — riavvio del livello
pacchetto?O.7 x
La procedura ERROR-
R per le chiamate
virtuali corrisponde a: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,
tabelle 34-36
W2sc — riavvio del livello
pacchetto?O.8 x
Tabella 11
Interruzione del trasferimento
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oInterruzione del trasferi-
mentoRiferimenti Status Riferimenti Status
Is L'invio di interruzioni
è supportato?6.8, 6.8.1, 6.8.3,
tabella 35Oo x
—; invio di INTER-
RUPT REQUEST12.3.2
ricezione di INTER-
RUPT CONFIRMA-
TION12.3.3
Ir La ricezione di interru-
zioni è supportata?6.8, 6.8.2, 6.8.3,
tabella 35O–
—ricezione di INTER-
RUPT INDICATION12.3.2
—invio di INTER-
RUPT CONFIRMA-
TION12.3.3
Tabella 12
Invio di dati
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oInvio di dati Riferimenti Status Riferimenti Status
DS1 L'invio di pacchetti
DATA è supportata?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Quanto segue è
supportato:
DS2 —rotazione della fine-
stra in invio alla rice-
zione di valori P(R)
aggiornati?7.1, 7.1.2, 7.1.3 O mm
DS4a —invio di M = 0 nei
pacchetti DATA?6.4, 6.5, 6.7 M mo.9
DS4b —invio di M = 1 nei
pacchetti DATA?6.4, 6.5, 6.7 O mo.9
DS5a —invio di Q = 0 nei
pacchetti DATA?6.6 O.10 mm
DS5b —invio di Q = 1 nei
pacchetti DATA?6.6 O.10 ox2000R2082 — IT — 15.06.2002 — 001.001 — 198
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oInvio di dati Riferimenti Status Riferimenti Status
DS6 —risposta a richieste
di ritrasmissione di
pacchetti (ricezione di
pacchetti REJECT)?13.4.2 12.8 Et:O –
—procedura di rota-
zione della finestra
temporale:
DS7a —al termine, azione
ERROR-R11.2.1(a) O ox
DS7b —al termine, ritrasmis-
sione dei pacchetti11.2.1(b) Et:O
¬Et:Xox
DS8 —scarto dei pacchetti
controllo del flusso di
lunghezza superiore al
limite ammesso (al
posto di ERROR-R)?Tabella 36 nota
2Oo x
Tabella 13
Ricezione di dati
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oRicezione di dati Riferimenti Status Riferimenti Status
DR1 La ricezione di
pacchetti DATA è
supportata?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Quanto segue è
supportato:
DR2 —rotazione della fine-
stra in ricezione
mediante l'invio di
valori P(R) aggiornati?7.1.2, 7.1.3 O mm
DR3 —controllo di flusso
mediante l'invio dipacchetti RECEIVE
NOT READY e
RECEIVE READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b —ricezione di M = 1
nei pacchetti DATA?6.4, 6.5, 6.7 O mm
DR5a —ricezione di Q = 0
nei pacchetti DATA?6.6 O.11 mm
DR5b —ricezione di Q = 1
nei pacchetti DATA?6.6 O.11 –
DR6 —richiesta di ritra-
smissione di pacchetti
mediante l'invio di
pacchetti REJECT?13.4.1, 12.8 O ox
—recupero dopo la
ricezione di pacchetti
DATA contenenti P(S)
non validi, mediante:
DR7a —azione ERROR-R? 11.3(a) O.12 mm
DR7b —richiesta di ritra-
smissione di pacchetti?11.3(b) O.12 ox2000R2082 — IT — 15.06.2002 — 001.001 — 199
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oRicezione di dati Riferimenti Status Riferimenti Status
DR7c —ignorazione del
pacchetto ed attesa
della ritrasmissione di
un pacchetto corretto?11.3(c) O.12 ox
—recupero dopo la
ricezione di pacchetti
DATA con campo
User Data non valido,
mediante:
DR8a —azione ERROR-R? 11.3(a) O.13 mm
DR8b —richiesta di ritra-
smissione del
pacchetto?11.3(b) O.13 ox
DR8c —ignorazione del
pacchetto e attesa della
ritrasmissione di un
pacchetto corretto?11.3(c) O.13 ox
DR9 —procedura di tempo-
rizzazione della
trasmissione dello
status della finestra?11.2.2 O ox
Tabella 14
Conferma di consegna
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oConferma di consegna Riferimenti Status Riferimenti Status
DC La conferma di
consegna è supportata?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Caratteristiche ed opzioni varie
Tabella 15
Valori dei codici di causa e diagnosi
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oValori dei codici di causa e
diagnosiRiferimenti Status Riferimenti Status
Nei pacchetti
RESTART REQUEST
inviati:12.6.1.1,
12.6.1.2, tabelle
24-25
Y1d —Cause = 128, codici
di diagnosi privatiO.14 ox
Nei pacchetti
RESTART INDICA-
TION ricevuti:12.6.1.1, tabella
9, 12.6.1.2
Y2b —Cause non 0 o 128,
qualsiasi valore di
codice di diagnosiEC:M
¬EC:Om
Nei pacchetti CLEAR
REQUEST inviati:12.2.3.1.1,
12.2.3.1.2,
tabelle 24-25
Y3d —Cause = 128, codici
di diagnosi privatiO.15 ox2000R2082 — IT — 15.06.2002 — 001.001 — 200
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oValori dei codici di causa e
diagnosiRiferimenti Status Riferimenti Status
Nei pacchetti CLEAR
INDICATION ricevuti:12.2.3.1.1,
tabella 7
12.2.3.1.2,
Y4b —Cause non 0 o 128,
qualsiasi valore di
codice di diagnosiEC:M
¬EC:Om
Nei pacchetti RESET
REQUEST inviati:12.5.1.1,
12.5.1.2, tabelle
24-25
Y5d —Cause = 128, codici
di diagnosi privatiO.16 ox
Nei pacchetti RESET
INDICATION ricevuti:12.5.1.1, tabella
8, 12.5.1.2
Y6b —Cause non 0 o 128,
qualsiasi valore di
codice di diagnosiEC:M
¬EC:Om
E.8.2.4. Servizi opzionali
Tabella 16
Servizi opzionali inviati nei pacchetti CALL REQUEST
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi inviati nei pacchetti
CALL REQUESTRiferimenti Status Riferimenti Status
FS1pi Negoziazione para-
metri del controllo di
flusso, dimensioni dei
pacchetti13.12, 15.2.2.1.1 O x
FS1wi Negoziazione para-
metri del controllo di
flusso, dimensioni
della finestra13.12, 15.2.2.1.2 O x
FS2ib Negoziazione classe di
throughput di base13.13,
15.2.2.2.1,tabella 20aOx
FS2ie Negoziazione classe di
throughput estesa13.13,
15.2.2.2.2,
tabella 20bOx
FS3b Selezione gruppo
chiuso di utenti,
formato di base13.14.6,
15.2.2.3.1Oo
FS3e Selezione gruppo
chiuso di utenti,
formato esteso13.14.6,
15.2.2.3.2Ox
FS4b Selezione gruppo
chiuso di utenti con
accesso in uscita,
formato di base13.14.7,
15.2.2.4.1Ox
FS4e Selezione gruppo
chiuso di utenti con
accesso in uscita,
formato esteso13.14.7,
15.2.2.4.2Ox
FS5 Selezione gruppo
chiuso di utenti bilate-
rale13.15, 15.2.2.5 O x
FS6a Fast Select 13.16, 15.2.2.6 O x2000R2082 — IT — 15.06.2002 — 001.001 — 201
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi inviati nei pacchetti
CALL REQUESTRiferimenti Status Riferimenti Status
FS6b Addebito a carico del
destinatario13.18, 15.2.2.6 O x
FS6c Selezione status
dell'ICRD13.25.4.2,
15.2.2.6Ox
FS7i Identificazione utente
di rete13.21, 13.21.3,
15.2.2.7Ox
FS8i Dettaglio degli adde-
biti, richiesta servizio13.22, 15.2.2.8.1 O x
FS9b Selezione RPOA,
formato di base13.23, 13.23.2,
15.2.2.9.1Ox
FS9e Selezione RPOA,
formato esteso13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Indicazione e selezione
tempo di attraversa-
mento13.27, 15.2.2.13 O x
FS99i Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS98i Servizi remoti non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS20i Marcatore di servizi,
servizi del DTE speci-
ficati dal CCITT15.1 O x
FS21i Estensione indirizzo
del chiamante14.1, 15.3.2.1 x
FS22i Estensione indirizzo
del chiamato14.2, 15.3.2.2 x
FS23ib Negoziazione classe di
throughput minima,
formato di base14.3, 15.3.2.3.1,
tabella 20aOx
FS23ie Negoziazione classe di
throughput minima,
formato esteso14.3, 15.3.2.3.2,
tabella 20bO
FS24i Negoziazione tempo di
attraversamento da
estremo a estremo14.4, 15.3.2.4 O x
FS25i Negoziazione veloce
per trasmissione dati14.7, 15.3.2.7 O x
FS26i Priorità 14.5, 15.3.2.5 O x
FS27i Protezione 14.6, 15.3.2.6 O x
Tabella 17
Servizi opzionali inviati nei pacchetti CALL ACCEPTED
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi inviati nei pacchetti
CALL ACCEPTEDRiferimenti Status Riferimenti Status
FS1pr Negoziazione para-
metri del controllo di
flusso, dimensioni dei
pacchetti13.12,
15.2.2.1.1,
tabella 13Ox
FS1wr Negoziazione para-
metri del controllo di
flusso, dimensioni dei
pacchetti13.12,
15.2.2.1.2,
tabella 13Ox2000R2082 — IT — 15.06.2002 — 001.001 — 202
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi inviati nei pacchetti
CALL ACCEPTEDRiferimenti Status Riferimenti Status
FS2rb Negoziazione classe di
throughput di base13.13,
15.2.2.2.1,
tabella 20aOx
FS2re Negoziazione classe di
throughput estesa13.13,
15.2.2.2.2,
tabella 20bOx
FS7r Identificazione utente
di rete13.21, 13.21.3
15.2.2.7Ox
FS8r Dettaglio degli adde-
biti, richiesta servizio13.22, 15.2.2.8.1 O x
FS10r Notifica modifica
dell'indirizzo della
linea chiamata13.26, 15.2.2.12 O x
FS99r Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS98r Servizi remoti non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS20r Marcatore di servizi,
servizi del DTE speci-
ficati dal CCITT15.1 O x
FS22r Estensione indirizzo
del chiamato14.2, 15.3.2.2 O x
FS24r Negoziazione tempo di
attraversamento da
estremo a estremo14.4, 15.3.2.4 O x
FS25r Negoziazione veloce
per trasmissione dati14.7, 15.3.2.7 O x
FS26r Priorità 14.5, 15.3.2.5 O x
FS27r Protezione 14.6, 15.3.2.6 O x
Tabella 18
Servizi opzionali inviati nei pacchetti CLEAR REQUEST
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi inviati nei pacchetti
CLEAR REQUESTRiferimenti Status Riferimenti Status
FS10d Notifica modifica
dell'indirizzo della
linea chiamata13.26, 15.2.2.12 O x
FS13 Selezione trasferimento
di chiamata13.25.2.2,
15.2.2.10Ox
FS99d Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS98d Servizi remoti non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FS20d Marcatore di servizi,
servizi del DTE speci-
ficati dal CCITT15.1 O x
FS22d Estensione indirizzo
del chiamato14.2, 15.3.2.2 O x2000R2082 — IT — 15.06.2002 — 001.001 — 203
▼B
Tabella 19
Servizi opzionali ricevuti nei pacchetti INCOMING CALL
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi ricevuti nei
pacchetti INCOMING
CALLRiferimenti Status Riferimenti Status
FR1pi Negoziazione para-
metri del controllo di
flusso, dimensioni dei
pacchetti13.12, 15.2.2.1.1 O x
FR1wi Negoziazione para-
metri del controllo di
flusso, dimensioni
della finestra13.12, 15.2.2.1.2 O x
FR2ib Negoziazione classe di
throughput di base13.13, 15.2.2.2.1
tabella 20aOx
FR2ie Negoziazione classe di
throughput estesa13.13, 15.2.2.2.2
tabella 20bOx
FR3b Selezione gruppo
chiuso di utenti,
formato di base13.14.6,
15.2.2.3.1Oo
FR3e Selezione gruppo
chiuso di utenti,
formato esteso13.14.6,
15.2.2.3.2Ox
FR4b Selezione gruppo
chiuso di utenti con
accesso in uscita,
formato di base13.4.7,
15.2.2.4.1Ox
FR4e Selezione gruppo
chiuso di utenti con
accesso in uscita,
formato esteso13.4.7,
15.2.2.4.2Ox
FR5 Selezione gruppo
chiuso di utenti bilate-
rale13.15, 15.2.2.5 O x
FR6a Fast select 13.16, 13.17,
15.2.2.6Ox
FR6b Addebito a carico del
destinatario13.18, 13.19,
15.2.2.6Ox
FR11 Notifica dirottamento
di chiamata o trasferi-
mento di chiamata13.25.3,
15.2.2.11Ox
FR12i Indicazione e selezione
tempo di attraversa-
mento13.27, 15.2.2.13 O x
FR99i Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FR20i Marcatore di servizi,
servizi del DTE speci-
ficati dal CCITT15.1 O x
FR21 Estensione indirizzo
del chiamante14.1, 15.3.2.1 x
FR22i Estensione indirizzo
del chiamato14.2, 15.3.2.2 x
FR23b Negoziazione classe di
throughput minima,
formato di base14.3, 15.3.2.3.1,
tabella 20aOx
FR23e Negoziazione classe di
throughput minima,
formato esteso14.3, 15.3.2.3.2,
tabella 20bOx2000R2082 — IT — 15.06.2002 — 001.001 — 204
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi ricevuti nei
pacchetti INCOMING
CALLRiferimenti Status Riferimenti Status
FR24i Negoziazione tempo di
attraversamento da
estremo a estremo14.4, 15.3.2.4 O x
FR25i Negoziazione veloce
per trasmissione dati14.7, 15.3.2.7 O x
FR26i Priorità 14.5, 15.3.2.5 O x
FR27i Protezione 14.6, 15.3.2.6 O x
Tabella 20
Servizi opzionali ricevuti nei pacchetti CALL CONNECTED
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi ricevuti nei
pacchetti CALL
CONNECTEDRiferimenti Status Riferimenti Status
FR1pr Negoziazione para-
metri del controllo di
flusso, dimensioni dei
pacchetti13.12,
15.2.2.1.1,
tabella 14Ox
FR1wr Negoziazione para-
metri del controllo di
flusso, dimensioni
della finestra13.12,
15.2.2.1.2,
tabella 14Ox
FR2rb Negoziazione classe di
throughput di base13.13,
15.2.2.2.1,
tabella 20aOx
FR2re Negoziazione classe di
throughput estesa13.13,
15.2.2.2.2,
tabella 20bOx
FR10r Notifica modifica
dell'indirizzo della
linea chiamata13.26, 15.2.2.12 O x
FR12r Indicazione e selezione
tempo di attraversa-
mento13.27, 15.2.2.13 O x
FR99r Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FR20r Marcatore di servizi,
servizi del DTE speci-
ficati dal CCITT15.1 O x
FR22r Estensione indirizzo
del chiamato14.2, 15.3.2.2 O x
FR24r Negoziazione tempo di
attraversamento da
estremo a estremo14.4, 15.3.2.4 O x
FR25r Negoziazione veloce
per trasmissione dati14.7, 15.3.2.7 O x
FR26r Priorità 14.5, 15.3.2.5 O x
FR27r Protezione 14.6, 15.3.2.6 O x2000R2082 — IT — 15.06.2002 — 001.001 — 205
▼B
Tabella 21
Servizi opzionali ricevuti nei pacchetti CLEAR INDICATION
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi ricevuti nei
pacchetti CLEAR INDICA-
TIONRiferimenti Status Riferimenti Status
FR8ad Dettaglio degli adde-
biti, unità monetaria13.22, 15.2.2.8.2 O x
FR8bd Dettaglio degli adde-
biti, conteggio dei
segmenti13.22, 15.2.2.8.3 O x
FR8cd Dettaglio degli adde-
biti, durata della chia-
mata13.22, 15.2.2.8.4 O x
FR10d Notifica modifica
dell'indirizzo della
linea chiamata13.26, 15.2.2.12 O x
FR99d Servizi locali non
X.25, secondo marca-
tore di servizi15.1, tabella 18 O x
FR20d Marcatore di servizi,
servizi del DTE speci-
ficati dall'ITU-T15.1 O x
FR22d Estensione indirizzo
del chiamato14.2, 15.3.2.2 O x
Tabella 22
Servizi opzionali ricevuti nei pacchetti CLEAR CONFIRMATION
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oServizi opzionali ricevuti
nei pacchetti CLEAR
CONFIRMATIONRiferimenti Status Riferimenti Status
FR8af Dettaglio degli adde-
biti, unità monetaria13.22, 15.2.2.8.2 O x
FR8bf Dettaglio degli adde-
biti, conteggio dei
segmenti13.22, 15.2.2.8.3 O x
FR8cf Dettaglio degli adde-
biti, durata della chia-
mata13.22, 15.2.2.8.4 O x
E.8.2.5. Valori e range dei parametri
Tabella 23
Valori e range dei parametri
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oValori e range dei para-
metriRiferimenti Status Riferimenti Status
Quali valori sono
supportati:2000R2082 — IT — 15.06.2002 — 001.001 — 206
▼B
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oValori e range dei para-
metriRiferimenti Status Riferimenti Status
V1s —Dimensioni di
default dei pacchetti
(invio)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
ottetti6.3.2 Alme-
no 128
e 256
V1r —Dimensioni di
default dei pacchetti
(ricezione)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
ottetti6.3.2 Alme-
no 128
e 256
V2s —Dimensioni di
default della finestra,
invio?16.2.2.6 ( M8:nel
range 1-7)2
V2r —Dimensioni di
default della finestra,
ricezione?16.2.2.6 ( M8:nel
range 1-7)2
E.8.3. Requisiti relativi al livello di collegamento
Le PRL di questa sezione si basano sulla dichiarazione proforma
PICS della norma ISO/IEC 7776:1994 [riferimento 6]. I dati riportati
nella colonna «Riferimenti» per le «Caratteristiche della norma di
base» delle tabelle si riferiscono alle clausole di tale norma.
Tabella 24
Protocollo di collegamento dati
Caratteristiche della norma di baseCaratteristiche del
profilo
Element-
oProtocollo di collegamento
datiRiferimenti Status Riferimenti Status
Lm Procedura multilink 6 O ox
Lc Funzionamento DTE/
DCE1, 5.1 M mo.1
Lt Funzionamento DTE/
DTE1, 5.1 O mo.1
M8 Funzionamento di base
(Modulo 8)1, 3, 4.1.1 O.1 mm
M128 Funzionamento esteso
(Modulo 128)1, 3, 4.1.1 O.1 ox
T4 Procedura timer T4 5.3.2, 5.6.1 O mm
SPN1 Numero massimo (N1)
di bit in una trama I5.7.3 N1 ≥
1 080N1≥
2 104
SPk Numero massimo di
trame (k) outstanding5.7.4 1 ≤k≤
7k=7
E.8.4. Requisiti relativi al livello fisico
Cfr. ISO/IEC TR 10609-9 clausola A.4 [riferimento 8].2000R2082 — IT — 15.06.2002 — 001.001 — 207
▼B
ALLEGATO F (Informativo)
METODOLOGIEPERLEPROVEDICONFORMITÀ
F.1.Introduzione
F.1.1. È importante che le implementazioni del presente ICD siano tali da
generare un livello elevato di fiducia riguardo all'interfunzionamento
tra Centri di controllo del traffico aereo (ATCC) che interagiscono
mediante l'interfaccia.
F.1.2. È probabile che gli Stati membri si servano di diverse fonti di
acquisto per l'implementazione dell'interfaccia. Per ottenere un
elevato livello di fiducia riguardo all'interfunzionamento delle varie
implementazioni è necessario fissare requisiti comuni per le prove di
conformità in modo da normalizzare la preparazione delle prove, la
loro effettuazione e la presentazione dei risultati.
F.2.Scopoecampod'applicazione
F.2.1. Il presente allegato definisce i requisiti relativi alle prove di
conformità realizzate sulle implementazioni della presente norma
Eurocontrol, di cui questo allegato è parte integrante.
F.2.2. Identifica i meccanismi con i quali si crea la fiducia nell'interfaccia
dichiarata mediante opportune prove di validazione.
F.3.Bibliografia
Il documento indicato qui di seguito ha attinenza con l'effettuazione
delle prove sulle implementazioni della presente norma Eurocontrol:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Part 1 Integration Test Plan Version 1.0, 10 maggio
1996 [riferimento 15].
F.4.Metodiepratichedisviluppo
F.4.1. Le implementazioni dell'ICD possono essere realizzate usando parti-
colari versioni ed opzioni dell'ICD stesso. Per stabilire le potenzialità
di interfunzionamento, uno Stato membro che implementa l'inter-
faccia deve identificare quali parti dell'ICD sono supportate; a questo
scopo è necessaria una dichiarazione precisa sulle capacità e sugli
eventuali limiti relativi ai parametri variabili.
F.4.2. È opportuno sottoporre qualsiasi implementazione ad una prova di
conformità nel modo descritto di seguito.
F.5.Prove
F.5.1. Introduzione
F.5.1.1. Per creare la fiducia necessaria e supportare l'interfaccia FDE in un
ATCC per l'interfunzionamento tra applicazioni FDE cooperanti, è
auspicabile che ogni implementazione sia sottoposta a prove diconformità alle norme di cui fa parte il presente allegato. Tali prove,
che riguardano il comportamento esterno del sistema in prova (SUT),
hanno lo scopo di misurare la capacità di interoperare del sistema
terminale e non la sua capacità di fornire un determinato servizio.
F.5.1.2. I risultati di queste prove possono servire come riscontri a supporto di
una dichiarazione di conformità preparata conformemente alla
sezione 6.1 di questa parte della norma Eurocontrol. Le dichiarazioni
proforma PICS e le PRL richiamate in queste specifiche di profilo
possono essere usate come base di partenza; inoltre, le norme interna-
zionali (ad es. la norma ISO/IEC 8208 [riferimento 7]) possono
contenere serie di prove astratte già definite utilizzabili nelle prove
di conformità.
F.5.1.3. Lo scopo del presente documento è fornire un programma normaliz-
zato di prove che faccia riferimento ad una serie di prove
normalizzate, il cui utilizzo dovrebbe assicurare la confrontabilità dei
risultati e la loro accettazione generalizzata, e quindi ridurre al
minimo il ricorso alle prove di conformità. La serie di prove norma-
lizzate è stata elaborata in parte da Eurocontrol.2000R2082 — IT — 15.06.2002 — 001.001 — 208
▼B
F.5.1.4. In base alla figura 2, la prova del sistema terminale completo è costi-
tuita da prove sui tre livelli inferiori. È consigliabile includere prove
sui messaggi applicativi FDE, di status, di sistema e operatore.
F.5.1.5. Le prove descritte di seguito dovrebbero essere eseguite nell'ordine
indicato. L'ultima prova potrà dare risultati positivi solo se i livelli
inferiori funzionano correttamente, e le prove precedenti dovrebbero
permettere di verificarlo.
F.5.1.6. In ogni caso, le prove descritte in questa sezione sono volontarie.
F.5.2. Prove dei livelli inferiori (livelli 1 - 3)
Per garantire l'interfunzionamento tra qualsiasi ATCC ed i suoi
omologhi si raccomanda che ogni prova si basi sull'uso del piano di
prove di integrazione FDE ICD elaborato da Eurocontrol (Divisione
sistemi UAC Maastricht). Le procedure di prova devono essere
concordate bilateralmente tra gli ATCC cooperanti.
F.5.3. Prova del livello applicazione
È opportuno che gli ATCC cooperanti stabiliscano di comune accordo
e realizzino una serie comune di prove.
F.5.4. Certificazione
È opportuno che il risultato delle prove sia registrato e approvato
dalle parti cooperanti.
F.5.5. Notifica
È opportuno che gli Stati membri comunichino a Eurocontrol infor-
mazioni dettagliate sui risultati di qualsiasi prova effettuata.2000R2082 — IT — 15.06.2002 — 001.001 — 209
▼B
ALLEGATO G (Informativo)
ASSEGNAZIONEDEGLIIDENTIFICATORIDEGLIENTIATC
La tabella che segue riporta gli identificatori degli enti ATC assegnati al
22 aprile 1997. Dati aggiornati sugli identificatori assegnati possono essere
richiesti a Eurocontrol. La tabella riporta anche in forma esadecimale la codifica
binaria dell'identificatore che fa parte della codifica dell'indirizzo di NSAP defi-
nita nell'allegato C.
Tabella 1
Identificatori degli enti ATC
Identificatore dell'ente
ATCCodifica Descrizione
00 Riservato
01 '01'H CATCAS, Copenaghen
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Francoforte sul Meno
04 '04'H CANAC Bruxelles
05 '05'H Generico CAUTRA, Francia
06 '06'H Dublino
07 '07'H Shannon
08 '08'H LATCC, Londra
09 '09'H ATCC Oslo
10 '10'H ATCC Karlsruhe
11 '11'H Langen (futuro sistema tedesco)
12 '12'H FATMI-system, Tampere13 '13'H ROVA-system, Rovaniemi
14 '14'H VAS, Vienna
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H ACC/FMP Ginevra
18 '18'H ACC/FMP Zurigo
19 '19'H Barcellona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milano
23 '23'H Roma
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 Stoccolma-Arlanda
33 '33'H Malmö-Sturup34 '34'H Sundsvall
35 '35'H Lisbona
36 '36'H Siviglia
37 '37'H Gran Canaria2000R2082 — IT — 15.06.2002 — 001.001 — 210
▼B
Identificatore dell'ente
ATCCodifica Descrizione
38 '38'H Praga
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Sistema militare tedesco
42 '42'H Sistema militare tedesco43 '43'H Sistema militare tedesco
44 '44'H Sistema militare tedesco
45 '45'H Sistema militare tedesco
46 '46'H Sistema militare tedesco
47 '47'H Sistema militare tedesco
48 '48'H Sistema militare tedesco
49 '49'H Sistema militare tedesco
50 '50'H Monaco (futuro sistema tedesco)
51 '51'H Zagabria
52 '52'H Aeroporto di Hahn, Germania
53 '53'H FIR di Santa Maria
54 '54'H Lubiana
55 '55'H Sistema militare belga
56 '56'H Budapest
57 '57'H Varsavia2000R2082 — IT — 15.06.2002 — 001.001 — 211
▼B
ALLEGATO H (Informativo)
DIRETTIVE SULL'AFFIDABILITÀ, LA DISPONIBILITÀ E LA SICU-
REZZA
H.1.Introduzione
Si prevede che applicazioni ATC come OLDI utilizzeranno reti X.25
interconnesse e/o servizi di telecomunicazioni pubblici o privati. Di
conseguenza, si ritiene necessario fornire direttive riguardo alle
implementazioni dell'FDE ICD, parte 1.
H.2.Scopoecampod'applicazione
H.2.1. Lo scopo del presente allegato è fornire direttive su questioni riguar-
danti l'affidabilità, la disponibilità e la sicurezza.
H.2.2. Il campo d'applicazione del presente allegato include due diversi
scenari. Il primo scenario è una connessione punto a punto su linea
affittata; il secondo è un ambiente di rete X.25 interconnesso.
NOTA Per il secondo scenario non sono prese in considerazione le
questioni riguardanti l'interconnessione delle reti X.25.
H.2.3. Le implementazioni sono protette fisicamente dall'intrusione, da
interruzioni dell'alimentazione e da altre minacce esterne che possono
ripercuotersi sul normale funzionamento.
H.3.Bibliografia
Il presente allegato presenta una panoramica dell'analisi tecnica detta-
gliata contenuta nel documento seguente:
Eurocontrol FDE ICD Part 1: Reliability, Availability and Security
— Technical Report [riferimento 16].
H.4.Implementazionisulineaaffittata
H.4.1. Affidabilità
Per aumentare l'affidabilità del servizio, i cavi delle linee affittate,
della PSTN e della rete digitale integrata nei servizi (ISDN) devono
seguire vie diverse ed essere collegati a commutatori diversi del
gestore delle telecomunicazioni (questo requisito deve essere specifi-
cato al gestore delle telecomunicazioni).
H.4.2. Disponibilità
H.4.2.1. A causa dei lunghi tempi di formazione sulla PSTN, incompatibili
con applicazioni che presentano vincoli temporali, è opportuno utiliz-
zare la rete ISDN come mezzo fisico di riserva.
H.4.2.2. In caso di avvicendamento del DTE è opportuno che il DTE di
riserva generi una trama DISC per accelerare la riformazione della
connessione.
H.4.3. Sicurezza
H.4.3.1. Quando si usa l'ISDN come mezzo di riserva è opportuno che l'adat-
tatore di terminale (TA) chiamato validi l'indirizzo E.164 del
chiamante [riferimento 18].
H.4.3.2. È opportuno che il DTE chiamante sia conforme alla
Raccomandazione X.32 dell'ITU-T [riferimento 17] e includa l'identi-
ficazione del chiamante e informazioni per l'autenticazione.2000R2082 — IT — 15.06.2002 — 001.001 — 212
▼B
H.4.4. Esempio di configurazione
Figura H.1
Esempio di configurazione per una linea affittata
H.5.Implementazionesurete
H.5.1. Affidabilità
Per accrescere l'affidabilità del servizio è opportuno che gli host di
un sito siano collegati a due DCE facenti campo a commutatori di-
versi della rete (questo requisito deve essere specificato al gestore
della rete).
H.5.2. Disponibilità
H.5.2.1. È opportuno utilizzare il servizio opzionale Hunt Group in modo da
poter assegnare un unico indirizzo X.121 [riferimento 20] ai DCE di
un sito, ottimizzando in questo modo l'instradamento di rete e limi-
tando il numero di chiamate non formate.
H.5.2.2. Se sono utilizzati altri meccanismi di chiamata che comportano un
valore diverso dell'indirizzo del DTE chiamato nei pacchetti CALL
REQUEST e CALL ACCEPT, è opportuno configurare il DTE chia-
mante in modo che non ci siano effetti sulla formazione del
collegamento.
H.5.2.3. Se si verifica una disconnessione del DCE causata da un malfunzio-
namento della rete ed è disponibile un secondo accesso alla rete, è
opportuno che la riformazione del collegamento venga effettuata
attraverso questo secondo accesso.
H.5.3. Sicurezza
Nel quadro del presente allegato, il servizio opzionale Gruppo chiuso
di utenti (CUG) è l'unico servizio di rete da utilizzare.
H.6.Direttive generali per le implementazioni su linea affittata e su
rete
H.6.1. Affidabilità
H.6.1.1. Dal momento che il passaggio da un host ad un altro può richiedere
molto tempo vale la pena di prendere in considerazione l'uso di un
processore front-end (FEP) per risolvere il problema dei malfunziona-
menti dell'host.
H.6.1.2. Un'architettura basata sull'uso di un FEP può accrescere l'affidabilità
del servizio.
NOTA L'inclusione di uno stack di trasporto nella specifica del
profilo potrà essere sviluppata nel contesto di una futura
norma FDE ICD, parte 2.2000R2082 — IT — 15.06.2002 — 001.001 — 213
▼B
H.6.2. Disponibilità
Quando una chiamata non ha esito positivo è opportuno che il sito
chiamante effettui la seconda chiamata usando il secondo
indirizzo X.121 (se disponibile).
H.6.3. Gestione dei sistemi
H.6.3.1. Ove possibile, è opportuno utilizzare commutatori che commutano
automaticamente analizzando i segnali di interfaccia.
H.6.3.2. Durante la trasmissione di dati può essere utilizzata un'indicazione
locale di errore per avviare l'avvicendamento dell'host.
H.6.3.3. È opportuno che all'avvicendamento di un FEP si generi una TC-
disconnect per assicurare che l'host locale sia nella condizione IDLE.
H.6.3.4. Allo scadere dei timeout della rete X.25 o dei livelli di collegamento
è opportuno che i livelli superiori siano svincolati.
H.6.3.5. È opportuno che un malfunzionamento totale del FEP generi una TC-
disconnect.
H.6.3.6. È opportuno che il sistema di gestione interroghi il livello protocollo
di trasferimento di messaggi (allegato A) e controlli la macchina di
stato per distinguere tra un malfunzionamento del protocollo di
trasferimento di messaggi ed un malfunzionamento dell'applicazione.
H.6.4. Esempio di configurazione
Figura H.2
Esempio di configurazione per una rete2000R2082 — IT — 15.06.2002 — 001.001 — 214