32000R2082

Regolamento CE n. 2082/2000 della Commissione

del 6 settembre 2000

che adotta le norme Eurocontrol e che modifica la direttiva 97/15/CE, che adotta le norme Eurocontrol e che modifica la direttiva 93/65/CEE del Consiglio

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 traffico aereo(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 del Consiglio, relativa alla definizione e all'utilizzazione di specifiche tecniche 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 nuova norma Eurocontrol denominata "Scambio di dati di volo - Documento relativo al controllo di interfaccia" [Flight Data Exchange - Interface Control Document (FDE-ICD].

(3) Queste norme Eurocontrol rientrano nel campo di applicazione della direttiva 93/65/CEE e contribuiscono all'armonizzazione dei sistemi nazionali di gestione del traffico aereo degli Stati membri, soprattutto per quanto riguarda il trasferimento dei voli tra 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 conformemente al disposto dell'articolo 1 della direttiva 97/15/CE, per cui 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 seguenti sono 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 figura nell'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 Eurocontrol 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 (documento 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 direttamente applicabile in ciascuno degli Stati membri.

Fatto a Bruxelles, il 6 settembre 2000.

Per la Commissione

Loyola De Palacio

Vicepresidente

(1) GU L 187 del 29.7.1993, pag. 52.

(2) GU L 95 del 10.4.1997, pag. 16.

ALLEGATO I

INTERSCAMBIO DI DATI IN LINEA (OLDI), EDIZIONE 2.2

(documento Eurocontrol di riferimento DPS.ET1.ST06-STD)

INDICE

>SPAZIO PER TABELLA>

AVVISO/DIRITTI D'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 disposizione dei rappresentanti degli Stati membri, ma la riproduzione o divulgazione a terzi è subordinata al preventivo consenso scritto dell'Agenzia Eurocontrol.

PREFAZIONE

1. Organo responsabile

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 informazioni vanno indirizzati al Direttore Generale di Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, all'attenzione della Divisione DED-2.

2. Rapporto con il Programma di lavoro EATCHIP

La presente norma è un prodotto risultante dall'Attività specialistica 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. Approvazioni e modifiche

La presente norma è stata sottoposta alla procedura di approvazione 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 corrispondenza;

- 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 permanente.

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 modifica o in una nuova edizione del documento, da sottoporre per accettazione secondo le procedure stabilite.

4. Convenzioni redazionali

Per indicare lo status di ciascun elemento è stata adottata la notazione 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 di dati in linea

Il presente documento sostituisce le parti 1 e 2 dell'edizione 1 della norma "Eurocontrol Standard for On Line Data Interchange". 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.

6. Cambiamenti rilevanti rispetto all'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 identificare 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 trasferimento del controllo.

4. Uso del formato descritto nell'edizione 2 della norma Eurocontrol 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 comunicazioni 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'implementazione).

H: Guidelines of Evaluation of OLDI (Linee-guida per la valutazione dell'OLDI).

6. Separazione della parte 3 - Requisiti tecnici - dalle specifiche relative alle applicazioni.

7. Rapporto con altri documenti

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.

8. Lingua

L'originale del presente documento è stato redatto in lingua inglese.

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 sicurezza 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 principali 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, incorporati 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. Campo di applicazione

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 contenuto;

- 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 servizio 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 disposizioni 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 Eurocontrol se non dopo essere state formalmente esaminate ed incorporate nella presente norma Eurocontrol.

In caso di conflitto tra le prescrizioni della presente norma Eurocontrol ed il contenuto dei documenti a cui si fa riferimento prevale la presente norma Eurocontrol.

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, SIMBOLI E ABBREVIAZIONI

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 database.

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 giurisdizione 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 giurisdizione 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à trasferito 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.

3.1.17. Norma Eurocontrol: qualsiasi specifica applicabile alle caratteristiche 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 completarle.

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 trasferimento 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 informazioni 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'attivazione 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 coordinamento, 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'attraversamento 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 ATS

3.1.37. Avvertimento: messaggio visualizzato sullo schermo di una posizione di lavoro quando il processo di coordinamento automatizzato non va a buon fine.

3.2. Simboli e abbreviazioni

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 coordinamento

DED Direzione Sviluppo EATCHIP di Eurocontrol

EATCHIP Programma europeo di armonizzazione ed integrazione 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 (Organizzazione dell'aviazione civile internazionale)

INF Messaggio di informazione

LAM Messaggio di riscontro logico

LoA Lettera di accordo

MAC 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 supplementari

SSR Radar secondario di sorveglianza

SYSCO Coordinamento automatizzato

TI Avvio del trasferimento

TIM Messaggio di avvio del trasferimento

TWR/APP Controllo di aerodromo e controllo di avvicinamento

4. CARATTERISTICHE GENERALI

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. Requisiti del sistema di elaborazione dei dati di volo

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 trasferente 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, determinati 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 comunicazione 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, elaborazione, 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 bilateralmente:

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

NOTA

I COP possono non coincidere sempre con i punti di trasferimento del controllo.

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 coordinamento 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 ricevimento di un riscontro entro i termini previsti successivamente alla trasmissione di un messaggio di coordinamento o trasferimento.

4.2.5.5. Tale avvertimento o avviso è presentato in forma tale da attirare immediatamente l'attenzione della posizione di lavoro competente.

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 attivare 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 informazioni 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 punto in 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, accettazione - ACP, o attesa - SBY) e presenta i risultati dell'elaborazione alla/e posizione/i competente/i.NOTA

Le condizioni esatte per la generazione di un riscontro sono precisate per ogni messaggio.

4.3. Aggiornamento a partire dai dati di sorveglianza

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. Registrazione dei dati OLDI

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 disponibile 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 interessati.

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 superiore a un errore di trasmissione ogni 2000 messaggi.

4.6. Valutazione operativa

4.6.1. Periodo di valutazione

Prima di essere implementato a livello operativo ogni nuovo servizio 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 complessiva.

NOTA

Una 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 formalmente dai due enti.

5. CATEGORIE DI MESSAGGI

5.1. Indicazioni generali

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. Tempi di transazione

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

>SPAZIO PER TABELLA>

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'elaborazione 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. Classificazione e categorizzazione dei messaggi

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 ricezione (REC), si deve includere l'elaborazione per poter elaborare i messaggi ricevuti.NOTA

In casi eccezionali, quando il flusso di traffico tra due enti è unidirezionale, l'obbligatorietà può aversi in una sola direzione.

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 è indicata 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 comunicazioni per la procedura di dialogo è indicata nella tabella 5-4.

Tabella 5-2

Messaggi della procedura di base

>SPAZIO PER TABELLA>

Tabella 5-3

Procedura di dialogo - Messaggi della fase di coordinamento

(in aggiunta alla tabella 5-2)

>SPAZIO PER TABELLA>

Tabella 5-4

Procedura di dialogo - Messaggi della fase di trasferimento

>SPAZIO PER TABELLA>

6. PROCEDURA DI BASE - MESSAGGI OBBLIGATORI

6.1. Indicazioni generali

6.1.1. Descrizione dei requisiti

Questa sezione descrive i requisiti minimi a livello di applicazione 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 bilateralmente 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. Messaggio di preavviso di attraversamento di confine (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;

- rotta (facoltativo);

- altri dati del piano di volo (facoltativo).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

6.2.3. Regole di applicazione

6.2.3.1. Indicazioni generali

6.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 attivazione (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 immediatamente o entro un lasso di tempo concordato bilateralmente.NOTA

Questa raccomandazione ha lo scopo di evitare che posizioni 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 successivo 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 riveduto 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 generazione dell'ABI sia/siano:

- variabile/i, in funzione delle disposizioni della LoA;

- definito/i separatamente per ogni COP.

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.

NOTA

Un 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 posizione 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. ICAO

(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.2.5.2. ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.3. Messaggio di attivazione (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 ricevente sulla base delle informazioni più recenti;

- facilitare la distribuzione e la visualizzazione dei dati del piano di volo sugli schermi delle posizioni di lavoro competenti 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 ricevente.

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;

- rotta (facoltativo);

- altri dati del piano di volo (facoltativo).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

6.3.3. Regole di applicazione

6.3.3.1. Indicazioni generali

6.3.3.1.1. Il messaggio ACT è inviato per i voli che soddisfano le condizioni 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'orario 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'orario calcolato di trasmissione.

6.3.3.1.4. Il contenuto operativo del messaggio ACT da trasmettere è visualizzato 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 condizioni 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 ricevente non avvii un coordinamento allo scopo di modificarle.

6.3.3.1.10. Un nuovo messaggio ACT può essere inviato allo stesso interlocutore 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 positivo 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.

6.3.3.3. Parametri per la trasmissione

6.3.3.3.1. Il messaggio è trasmesso in coincidenza con o non appena possibile dopo il primo tra:

- un numero di minuti calcolato secondo un determinato parametro 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 è visualizzato 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 riportato è 1226.

6.3.5.1. ICAO

(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.3.5.2. ADEXP

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.4. Messaggio di riscontro logico (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 è 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

6.4.3. Regole di applicazione

6.4.3.1. Indicazioni generali

6.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 trasmissioni 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 trasmittente 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 COMPLEMENTARI

7.1. Indicazioni generali

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 utilizzati previo accordo bilaterale.

7.1.2.2. Quando tale utilizzo viene concordato si applicano le regole descritte nella presente sezione.

7.2. Messaggio di attivazione preliminare (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;

- 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).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

7.2.3. Regole di applicazione

7.2.3.1. Indicazioni generali

7.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);

- codice SSR previsto al punto di trasferimento del controllo;

- orario stimato di decollo (ETOT) o ETO sul COP, se la variazione 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 impedisca 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 positivo 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.NOTA

Dal momento che per assegnare dei codici sono necessarie 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 un messaggio 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 avvertimento.

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 COP

7.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. Messaggio di revisione (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 cambiamento dell'ente accettante.

7.3.2. Contenuto del messaggio

Il messaggio REV contiene i dati seguenti:

- tipo di messaggio;

- numero del messaggio;

- riferimento del messaggio (facoltativo);

- identificazione dell'aeromobile;

- modo e codice SSR (facoltativo);

- aerodromo di partenza;

- dati stimati;

- punto di coordinamento (facoltativo);

- aerodromo di destinazione;

- rotta (facoltativo);

- altri dati del piano di volo (facoltativo).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

7.3.3. Regole di applicazione

7.3.3.1. Indicazioni generali

7.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 passibili di revisione:

- ETO sul COP;

- quota/e di trasferimento;

- codice SSR.

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 bilateralmente, arrotondato al numero intero più vicino;

- in caso di variazione della/e quota/e di trasferimento o del codice SSR.

7.3.3.1.4. Se concordato bilateralmente, un messaggio REV è inviato anche in caso di variazione riguardante:

- il COP;

- la rotta;

- altri dati del piano di volo (caselle 8, 10 e 18 ICAO).

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 modificarle.

7.3.3.2. Formato dei messaggi di revisione

7.3.3.2.1. Formato ICAO

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 trasferimento è inserita introducendo i dati riveduti nella casella 14;

- una variazione del codice SSR è inserito nella casella 7;

- le variazioni di rotta, comprese le variazioni del COP, sono inserite nei dati delle caselle 14 e 15 inclusi nel formato della casella 22 dopo le prime cinque caselle. In questi messaggi figurano due caselle 14, la prima delle quali contiene unicamente l'elemento a), vale a dire il COP attraverso il quale il volo era stato coordinato in precedenza. Le regole per il coordinamento di queste variazioni, comprese le rotte dirette, sono specificate nell'allegato B, Prescrizioni relative all'elaborazione di rotte particolari;

- le variazioni apportate alle caselle 8, 10 e 18 sono inserite come dati della casella 22 dopo i primi cinque campi.

7.3.3.2.2. Formato ADEXP

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 trasferimento è inserito introducendo i dati riveduti nel campo primario COORDATA;

- le variazioni di rotta, comprese le variazioni del COP, sono inserite nei campi primari COORDATA e ROUTE. In questi messaggi figura il campo primario COP contenente il punto di coordinamento attraverso il quale il volo era stato coordinato in precedenza. Le regole per il coordinamento di queste variazioni, comprese le rotte dirette, sono specificate nell'allegato B;

- una variazione del codice SSR è indicata inserendo il campo primario SSRCODE;

- le variazioni degli altri dati del piano di volo sono indicate inserendo il/i campo/i primario/i appropriato/i, così come definito/i per gli altri dati del piano di volo nell'allegato A.

Se un messaggio di revisione è inviato per coordinare unicamente il codice SSR e/o altri dati del piano di volo, il campo primario COP sostituisce il campo COORDATA.

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 ricevuto 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 definiti 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 riscontro

7.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. ICAO

a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)

b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)

7.3.5.2. ADEXP

a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317

7.4. Messaggio di abrogazione del coordinamento (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 cancellare 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 (facoltativo).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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 coordinamento;

- la rotta di volo è stata modificata con conseguente cambiamento 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 coordinamento 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 è possibile determinare automaticamente uno stimato riveduto.

7.4.3.1.5. Se concordato bilateralmente, nel messaggio MAC è indicato il riferimento del messaggio.

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 combinazioni seguenti:

- quando l'ente ricevente non è più l'interlocutore di coordinamento 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'abrogazione.

7.4.4. Riscontro al MAC

7.4.4.1. Riscontro

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

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 pianificato 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. Messaggio di assegnazione di codice SSR (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 determinato 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).

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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.

7.5.3.1.3. Se non è disponibile un codice individuale è inserito il codice di saturazione approvato, così come specificato nel piano di navigazione 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 ricevente

7.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. Messaggio di informazione (INF)

7.6.1. Scopo del messaggio INF

7.6.1.1. Il messaggio INF è usato per fornire informazioni su voli specifici 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 controllori. 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 revisioni 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;

- tutti i dati operativi del messaggio originario o del coordinamento risultante di cui il messaggio INF presenta una copia;

- tipo del messaggio di riferimento.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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. È opportuno che gli enti mittenti siano in grado di trasmettere le condizioni di coordinamento definitive adottate.

2. È opportuno che il messaggio INF venga trasmesso immediatamente 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 generazione 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, transponder 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 ACT

8. PROCEDURA DI DIALOGO - COORDINAMENTO

8.1. Indicazioni generali

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'accettazione.

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 standard;

- qualsiasi altra condizione eventualmente concordata bilateralmente.

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 "condizioni 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 trasferente

8.1.2.2.1. Il filtro nell'ente trasferente esamina le condizioni di trasferimento 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.

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 standard 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 discordanza 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 revisioni o lo scambio di messaggi per il trasferimento delle comunicazioni, e per evitare che i controllori dei due enti sottopongano 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 unicamente:

- 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 "coordinato".

8.1.4. Trattamento simultaneo dei messaggi

8.1.4.1. Indicazioni generali

8.1.4.1.1. Un ente che partecipa ad uno scambio di messaggi di coordinamento 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 coordinamento 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 appropriato, 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 controllore, nei centri mittente e ricevente è utilizzato un meccanismo di temporizzazione che prevede l'impiego di tempi massimi consentiti.

8.1.6.1.2. La durata dei tempi massimi consentiti è concordata bilateralmente.

8.1.6.1.3. Una volta superato il tempo massimo consentito nell'ente trasferente, 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 avvertimento 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 coordinamento 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 diversi 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 alternativi 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 trasferimento 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. Messaggio di attivazione (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 trasferimento 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 generali

8.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 illustrate 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.NOTA

Negli 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 ricevente

8.2.3.2.1. Il messaggio è controllato mediante il filtro allo scopo di confermare 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 conformemente 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 contenente 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 coordinamento del volo è visualizzato un avvertimento.

8.3. Messaggio di proposta di attivazione sottoposta per accettazione (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 (disponibile solo in ADEXP).

8.3.3. Regole di applicazione

8.3.3.1. Indicazioni generali

8.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 controllore accettante.

8.3.3.1.2. Il contenuto operativo del messaggio RAP da trasmettere è visualizzato 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 automatica 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 ricevente

8.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 impedisca 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 presentazione 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 impedisce 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 standard al controllore accettante, il messaggio è attivato manualmente dal controllore trasferente e trasmesso immediatamente.

8.3.3.3.2. Raccomandazione

È opportuno consentire alla posizione responsabile 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 avvertimento.

8.3.5. Risposta operativa al RAP

Il controllore accettante può accettare le condizioni di trasferimento, rigettarle o presentare una controproposta.

8.3.5.1. Accettazione

8.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 trasferimento coordinate e del ricevimento dell'ACP.

8.3.5.2. Controproposta

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.NOTA

In riferimento alla raccomandazione di cui al punto 8.3.5.3, nella maggior parte dei casi il nuovo coordinamento 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. Messaggio di revisione (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 trasferimento 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 variazione dei dati di coordinamento che renda necessario un coordinamento, così come descritto nel punto 7.3.3.

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. Riscontro

8.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 responsabile 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 è accettato dal sistema dell'ente accettante. Se il filtro dell'ente accettante rileva che le condizioni di trasferimento sono non standard il messaggio è elaborato come un messaggio RRV.

8.5. Messaggio di proposta di revisione sottoposta per accettazione (RRV)

8.5.1. Scopo del messaggio RRV

Il messaggio RRV permette la revisione di condizioni di trasferimento 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 accettante.

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 comprendere l'elemento seguente:

- motivo, con indicazione della presentazione manuale (disponibile solo in formato ADEXP).

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 trasferimento 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 ricevente

8.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 trasmissione 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 avvertimento.

8.5.5. Risposta operativa all'RRV

Il controllore accettante può accettare un messaggio RRV, rigettarlo 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. Controproposta

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)

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. Messaggio di attesa (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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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. Messaggio di accettazione (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 controllore 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;

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

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

8.7.3. Regole di applicazione

8.7.3.1. Indicazioni generali

8.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 ricevente

8.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 competente; 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'accettazione 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 242150

8.8. Messaggio di coordinamento (CDN)

8.8.1. Scopo del messaggio CDN

Il messaggio CDN risponde alle necessità operative seguenti:

- permettere al controllore accettante di trasmettere una controproposta al controllore trasferente in risposta ad un messaggio ACT, RAP, REV o RRV;

- permettere al controllore accettante di sottoporre al controllore 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;

NOTA

Il 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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 accettante.

8.8.3.1.2. Il messaggio CDN è usato dal controllore accettante per sottoporre una controproposta al controllore trasferente.NOTA

Questo 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 condizioni 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 revisione o un'abrogazione di coordinamento, non è inviato in risposta alcun riscontro o risposta operativa.NOTA

Questo 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 accorgersi di questa situazione se ricevono il messaggio dell'altro ente prima di aver ricevuto il riscontro.

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 ricevente

8.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 impedisce 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 avvertimento.

8.8.5. Risposta operativa al CDN

Il controllore può accettare o rigettare le condizioni di trasferimento 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).

NOTA

Il 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. Messaggio di rigetto di coordinamento (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.

8.9.2. Contenuto del messaggio

Il messaggio RJC contiene i dati seguenti:

- tipo di messaggio;

- numero del messaggio;

- riferimento del messaggio.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

8.9.3. Regole di applicazione

8.9.3.1. Indicazioni generali

8.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 ricevente

8.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 coordinamento 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 DELLE COMUNICAZIONI

9.1. Indicazioni generali

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 (Procedura di dialogo - Coordinamento).

9.1.1.3. I messaggi descritti nella presente sezione sono disponibili unicamente in formato ADEXP e non si prevede di renderli disponibili anche in formato ICAO.

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 coordinamento.

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.NOTA

Per 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 comunicazioni.

9.2. Messaggio di avvio del trasferimento (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 trasferimento);

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

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

9.2.3. Regole di applicazione

9.2.3.1. Indicazioni generali

9.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.

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 accettante.

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. Messaggio di dati supplementari (SDM)

9.3.1. Scopo del messaggio SDM

9.3.1.1. Indicazioni generali

9.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 variazioni.

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;

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

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto 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 trasferimento (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.

NOTA

Se prima del trasferimento delle comunicazioni è necessaria l'approvazione del controllore accettante si usa il messaggio HOP.

9.3.3.1.2. Il messaggio contiene unicamente i campi che sono stati modificati.

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 concordato 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.NOTA

Gli 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 positivo 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 è presentato 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.

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. Proposta di trasferimento (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 trasferimento 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 controllore trasferente.NOTA

In relazione al punto c) precedente, per trasmettere modifiche 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

9.4.3. Regole di applicazione

9.4.3.1. Indicazioni generali

9.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.NOTA

Non è 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.

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 immediatamente 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.NOTA

In considerazione del carattere di urgenza della procedura 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. Messaggio di richiesta di cambio di frequenza (ROF)

9.5.1. Scopo del messaggio ROF

Il ROF è inviato all'occorrenza dall'ente accettante all'ente trasferente 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

9.5.3. Regole di applicazione

9.5.3.1. Indicazioni generali

9.5.3.1.1. Il messaggio ROF è attivato manualmente dal controllore accettante.

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 controllore 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. Riscontro

9.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. Messaggio di cambio di frequenza (COF)

9.6.1. Scopo del messaggio COF

9.6.1.1. Indicazioni generali

9.6.1.1.1. Il COF è inviato dall'ente trasferente all'ente accettante per indicare che il volo è stato invitato a contattare il controllore accettante.

9.6.1.1.2. Il messaggio può prevedere la possibilità per il controllore trasferente 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

9.6.3. Regole di applicazione

9.6.3.1. Indicazioni generali

9.6.3.1.1. Il messaggio COF è attivato manualmente dal controllore trasferente.

9.6.3.1.2. L'uso del messaggio COF è obbligatorio se, per accordo bilaterale, non è usato il messaggio MAS.

9.6.3.1.3. Se un messaggio COF è inviato prima del TI si avvia la fase di trasferimento.NOTA

Non è 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 controllore 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. Messaggio di assunzione manuale delle comunicazioni (MAS)

9.7.1. Scopo del messaggio MAS

Il MAS è inviato dall'ente accettante all'ente trasferente per indicare 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.

NOTA

Le regole di inserimento dei dati, i formati ed il contenuto dei campi sono specificati nell'allegato A.

9.7.3. Regole di applicazione

9.7.3.1. Indicazioni generali

9.7.3.1.1. Il messaggio MAS è attivato manualmente dal controllore accettante.

9.7.3.1.2. L'uso del messaggio MAS è obbligatorio se, per accordo bilaterale, non è utilizzato il messaggio COF.

9.7.3.2. Elaborazione nell'ente ricevente

9.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 controllore.

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.

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 AMM253

ALLEGATO A (Normativo)

REGOLE DI INSERIMENTO DEI DATI

INDICE

>SPAZIO PER TABELLA>

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 applicazione per un messaggio specifico sono indicate espressamente eccezioni o disposizioni diverse.

A.2. Formati generici dei messaggi

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.

A.2.2. I formati dei campi dei messaggi sono definiti dall'ICAO nel Document 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.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.NOTE

1. Solo i campi dati primari ADEXP sono elencati nel presente allegato, eccetto quando i sottocampi ad essi associati richiedono 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. Tipo di messaggio

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. Numero del messaggio

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), 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. Riferimento del messaggio

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'interno del campo primario "refdata" del messaggio OLDI a cui si fa riferimento.

A.6. Identificazione dell'aeromobile

A.6.1. ICAO

Tipo di campo 7, elemento (a).

A.6.2. ADEXP

Campo primario "arcid".

A.7. Modo e codice SSR

1. Se è noto, il modo/codice SSR su cui l'ente ricevente può aspettarsi 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".

A.8. Aerodromo di partenza

A.8.1. ICAO

Tipo di campo 13, elemento (a).

A.8.2. ADEXP

Campo primario "adep".

A.9. Dati stimati

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 supplementari e le condizioni di attraversamento.

A.9.1.5. I dati di attraversamento supplementari, se sono utilizzati, comprendono 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 indicata nei dati di attraversamento supplementari; oppure

- Lettera "B"; - se il volo sarà alla quota o sotto la quota indicata 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. Punto di coordinamento

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.

A.11. Aerodromo di destinazione

A.11.1. ICAO

Campo 16, elemento (a).

A.11.2. ADEXP

Campo primario "ades".

A.12. Numero e tipo degli aeromobili

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 corrispondente 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. Altri dati del piano di volo

A.14.1. ICAO

Tipi di campo 8, 10, e 18, nel formato del tipo di campo 22.

A.14.2. ADEXP

Campi primari: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts", e "typz".

A.15. Status di coordinamento e motivo

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 notifica;

- 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 trasferimento;

- 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/coordinamento;

- 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. Prua assegnata (solo ADEXP)

Il campo primario "ahead" contiene:

- la prua assegnata ad un volo, espressa in gradi;

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. Rateo di salita/discesa assegnato (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 assegnato in precedenza non è più valido.

A.19. Autorizzazione di rotta diretta (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. Richiesta di rotta diretta

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 rilevamento rispetto ad un punto di riferimento.

Tutti gli indicatori di punti terminali utilizzati sono concordati bilateralmente, 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.

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, 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 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 designato.

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 bilateralmente, 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 informazioni temporali si utilizza il sottocampo "to" (hhmm) o "sto" (hhmmss), previo accordo bilaterale.

A.22. Indicazione di rilascio (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.

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 di volo autorizzato (solo ADEXP)

Campo primario "cfl".

A.26. Livello di volo proposto per il trasferimento (solo ADEXP)

Campo primario "propfl".

A.27. Orario stimato di decollo

A.27.1. ICAO

Tipo di campo 13 elemento (b).

A.27.2. ADEXP

Campo primario "etot".

A.28. Tipo di messaggio di riferimento

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".

ALLEGATO B (Normativo)

PRESCRIZIONI RELATIVE ALL'ELABORAZIONE DI ROTTE PARTICOLARI

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 consentiti:

- un volo segue una traiettoria diretta, fuori dalla rotta, e attraversa 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 è reinstradato 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. Applicazione dei messaggi

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 effettuati dopo l'invio del messaggio ACT prima dello scadere di un lasso di tempo, concordato bilateralmente, prima dell'ETO sul COP precedentemente coordinato.NOTA

Si 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 coordinamento.

B.2.4.2. Il messaggio contiene i dati seguenti:

- punto di coordinamento (COP precedente, a titolo di riferimento);

- dati stimati;

- rotta.

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'aerodromo 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. Contenuto dei campi

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 attraversamento 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'identificatore 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 longitudine.

B.3.2.3. La rotta comprende:

- il punto situato sulla rotta originaria a partire dal quale l'aeromobile 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).

>PIC FILE= "L_2000254IT.008401.EPS">

È 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

>PIC FILE= "L_2000254IT.008501.EPS">

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 attraversamento è 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)

>PIC FILE= "L_2000254IT.008502.EPS">

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.

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 coordinamento EMT. È trasmesso il messaggio ACT seguente:

(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)

>PIC FILE= "L_2000254IT.008601.EPS">

Successivamente il volo è reinstradato via la rotta ATS UM247 all'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)

>PIC FILE= "L_2000254IT.008602.EPS">

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)

>PIC FILE= "L_2000254IT.008701.EPS">

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 DTTA

ALLEGATO C (Informativo)

FASI DELLA PROCEDURA DI DIALOGO (LIVELLO SYSCO 1) - SEQUENZA DEI MESSAGGI

Sequenza dei messaggi

>PIC FILE= "L_2000254IT.008802.EPS">

ALLEGATO II

PRESENTAZIONE DELLO SCAMBIO DI DATI PER I SERVIZI DI TRAFFICO AEREO (ADEXP), EDIZIONE 2.0

(documento Eurocontrol di riferimento DPS.ET1.ST09-STD)

INDICE

>SPAZIO PER TABELLA>

AVVISO/DIRITTI D'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 disposizione dei rappresentanti degli Stati membri, ma la riproduzione o divulgazione a terzi è subordinata al preventivo consenso scritto dell'Agenzia Eurocontrol.

PREFAZIONE

1. Organo responsabile

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. Programma di lavoro EATCHIP

La presente norma è un prodotto del Programma di lavoro EATCHIP (EWPD), Dominio "Sistemi di elaborazione dati (DPS)", Attività direttiva 09.

3. Approvazione della norma

3.1. La presente norma è adottata in conformità alle procedure definite 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 1o dicembre 1997.

4. Rettifiche tecniche e modifiche

La presente norma è all'esame allo scopo di individuare 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 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 Eurocontrol Standard Documents".

Le modifiche o le integrazioni della presente norma devono essere proposte per iscritto a: CFMU Users Requirements Section (ADEXP), Eurocontrol Agency.

5. Convenzioni redazionali

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 (presentazione dello scambio di dati ATS).

5.2. Per indicare lo status di ciascun elemento è stata adottata le notazione seguente:

- gli elementi normativi sono caratterizzati da verbi al modo indicativo, tempo presente, e sono stampati in caratteri tondi;

- gli elementi raccomandati sono caratterizzati dalla forma verbale "è opportuno che"; sono stampati in caratteri corsivi e preceduti dall'indicazione Raccomandazione.

6. Collegamenti con altre norme

La presente norma è collegata al documento seguente:

Norma Eurocontrol per l'interscambio di dati in linea (OLDI)

7. Status degli allegati della presente norma

>SPAZIO PER TABELLA>

8. Lingua utilizzata

Il testo originale della presente norma è stato redatto in lingua inglese.

1. CAMPO DI APPLICAZIONE

1.1. ADEXP è un formato, non un protocollo. Non impone alcuna restrizione relativamente ai supporti o ai protocolli di trasmissione 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 disposizioni 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 è 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 Eurocontrol se non dopo essere state formalmente esaminate ed incorporate nella presente norma Eurocontrol.

In caso di conflitto tra le prescrizioni della presente norma Eurocontrol 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;

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, SIMBOLI E ABBREVIAZIONI

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 sintatticamente 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 separatori;

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.

NOTA

Un simbolo non terminale può essere rappresentato anche come un insieme di simboli terminali e non terminali.

3.3. Costruzione

3.3.1. La BNF è costituita da un insieme di regole o costrutti del tipo:

simbolo::= espressione

NOTE

1) 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. NOTA

Per 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 produzione 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 (").

Esempi

1) HYPHEN:= '-'

2) title:= '-' "TITLE" titleid

Per alcune applicazioni di modellizzazione di dati, può essere necessario distinguere i simboli terminali dai simboli non terminali 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 diversi simboli alternativi. La scelta è indicata da "|".

concatenazione: rappresentazione di simboli ordinati in sequenza. I simboli possono essere anche inframmezzati da uno o più separatori. 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 concatenazione flessibile in una regola può essere implicita o esplicita.Esempi

1) implicita:

dct::= '-' "DCT" point point

2) esplicita

dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

>SPAZIO PER TABELLA>

NOTE

1) La concatenazione ha sempre la precedenza sulla scelta. Le parentesi "(" e »)» sono usate per modificare l'ordine di valutazione dell'espressione.Esempio

>SPAZIO PER TABELLA>

2) In tutte le regole, la presenza ammessa di separatori tra i simboli è lasciata implicita allo scopo di migliorare la leggibilità.

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 valutazione desiderato.

3.6. Simboli e abbreviazioni

>SPAZIO PER TABELLA>

4. PRINCIPI ADEXP

4.1. Formato testuale leggibile 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. Campi identificati e recuperabili

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.NOTA

Si noti che in alcuni campi (quelli sintatticamente definiti come contenenti l'elemento lessicale "CHARACTER") nel contenuto del campo può validamente figurare un carattere "-".

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 obbligatorio 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 sottocampi, 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 sottocampi 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 una 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 indicazione.

4.2.14. I campi di un messaggio possono essere facoltativi od obbligatori, secondo la loro sintassi.

4.3. Campi non identificati

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 riconosce 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ò determinare o no il rigetto del messaggio.NOTA

È bene notare che, sebbene ADEXP sia studiato per offrire questo tipo di flessibilità, i responsabili della definizione 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)

5. REGOLE SINTATTICHE ADEXP

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 telecomunicazioni 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.NOTA

Oltre 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 perforato). 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 impaginazione 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 ::= HYPHEN

NOTA

LIM_CHAR rappresenta qualsiasi carattere ammesso eccetto il trattino ("HYPHEN") utilizzabile esclusivamente 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ò rappresentare 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 carattere 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 contenuto.

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 IFPL

3) - TITLE IFPL

4) -

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.

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 notazione 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.

>SPAZIO PER TABELLA>

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_values

contained_values::= {CHARACTER}

list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword

structured_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 definiti 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.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 combinazione 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 è significativo).Esempio di regola

addr::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"NOTA

1) In questo esempio il campo "addr" è un campo lista contenente 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 combinazione 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 esclusivamente 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).Esempio di regola

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 facoltativamente 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 limitate.

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 normalizzato 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 sottocampo;

- 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 (specifica 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 particolare, 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. Termini ausiliari

6.2.1. Per ottenere una definizione leggibile dei campi spesso è utile introdurre dei termini ausiliari nella descrizione grammaticale.

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, sottocampi 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 alfabetico e sono definiti nell'allegato A (A2) della presente norma.

6.2.4.

>SPAZIO PER TABELLA>

6.3. Definizione dei campi primari

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 notazione BNF presentato nella sezione 3 della presente norma.

6.3.4.

>SPAZIO PER TABELLA>

6.4. Definizione dei sottocampi

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 sottocampi, quindi sono presenti anche rimandi a questi sottocampi.

6.4.4.

>SPAZIO PER TABELLA>

6.5. Gruppi di messaggi

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 utilizzati.

6.5.3. Per ogni gruppo di messaggi si rimanda alla relativa documentazione 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 ai documenti 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 previsione 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.

ALLEGATO A (Normativo)

DEFINIZIONI DEI CAMPI ADEXP

A.1. Introduzione

Il presente allegato contiene un elenco di tutti i campi - termini ausiliari, campi primari e sottocampi - specificati per il formato ADEXP.

A.2. Termini ausiliari ADEXP

>SPAZIO PER TABELLA>

A.3. Campi primari ADEXP

>SPAZIO PER TABELLA>

A.4. Sottocampi ADEXP

>SPAZIO PER TABELLA>

ALLEGATO B (Normativo)

INDICE CENTRALE DEI TITOLI DI MESSAGGIO ADEXP

>SPAZIO PER TABELLA>

ALLEGATO C (Normativo)

INDICE CENTRALE DEI TITOLI DI MESSAGGIO RISERVATI

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à utilizzato in un sistema locale.

C.3. Titoli di messaggio riservati

>SPAZIO PER TABELLA>

ALLEGATO D (Normativo)

INDICE CENTRALE DEI CAMPI RISERVATI

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 formalmente 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 ausiliari riservati

>SPAZIO PER TABELLA>

D.4. Campi primari riservati

>SPAZIO PER TABELLA>

D.5. Sottocampi riservati

>SPAZIO PER TABELLA>

ALLEGATO E (Informativo)

PRESENTAZIONE DEI GRUPPI DI MESSAGGI

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. Messaggi di piano di volo

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 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS

-ATSRT UG41 AVS FTM

E.2. Messaggi di gestione del flusso del traffico aereo

E.2.1. Introduzione

I messaggi facenti parte di questa categoria sono scambiati principalmente 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 -POSITION -PTID LIFFY -TO 1646

E.3. Messaggi di coordinamento ATC

E.3.1. Introduzione

I messaggi di coordinamento sono utilizzati per automatizzare il coordinamento 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. Messaggi di gestione dello spazio aereo

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 temporaneamente 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 LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530

-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL

-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330

-END LACDR

E.5. Messaggi di coordinamento civile / 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 militari.

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 012

ALLEGATO F (Informativo)

ESEMPI DI FORMATO DI MESSAGGI ADEXP

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 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

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

-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS

ALLEGATO G (Informativo)

SVILUPPI FUTURI

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'intercalamento 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'interpretazione 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 particolare, 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 sostituito dal carattere "(". La fine del campo, che oggi non è indicata esplicitamente, verrebbe indicata in futuro dal carattere ")". Gli esempi qui di seguito illustrano questo principio.

Esempi

>SPAZIO PER TABELLA>

ALLEGATO III

SCAMBIO DI DATI DI VOLO - DOCUMENTO RELATIVO AL CONTROLLO DI INTERFACCIA (FDE-ICD), EDIZIONE 1.0

(documento Eurocontrol di riferimento COM.ET1.ST12-STD)

INDICE

>SPAZIO PER TABELLA>

AVVISO/DIRITTI D'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 disposizione dei rappresentanti degli Stati membri, ma la riproduzione o divulgazione a terzi è subordinata al preventivo consenso scritto dell'Agenzia Eurocontrol.

PREFAZIONE

1. Organo responsabile

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 "Programma di lavoro EATCHIP"

La presente norma è collegata al documento "Programma di lavoro EATCHIP (EWPD)", dominio "Comunicazioni", attività direttiva 01, attività specialistica 12.

3. Approvazione della norma

3.1. La presente norma è adottata conformemente alle procedure definite 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 tecniche e modifiche

La presente norma è tenuta sotto controllo allo scopo di individuare 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. Convenzioni redazionali

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 notazione seguente:

- gli elementi normativi sono caratterizzati da verbi al modo indicativo, tempo presente, e sono stampati in caratteri tondi;

- gli elementi 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 comprensione di un particolare paragrafo è stata incorporata nel testo sotto forma di NOTA. Le note hanno valore unicamente informativo, 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. Rapporto con altre norme

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 interfaccia (ICD) per lo scambio di dati di volo.

7. Status degli allegati della presente norma

Gli allegati della presente norma hanno lo status seguente:

- allegato A - normativo

- allegato B - normativo

- allegato C - normativo

- allegato D - normativo

- allegato E - normativo

- allegato F - informativo

- allegato G - informativo

- allegato H - informativo

8. Lingua utilizzata

Il testo originale della presente norma è stato redatto in lingua inglese.

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 è ritenuto auspicabile orientarsi verso un'architettura basata su reti ed adottare norme di telecomunicazioni internazionali, così da poter implementare i collegamenti in modo economicamente vantaggioso 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'evoluzione delle esigenze nel campo dello scambio di dati di volo (FDE), con un utilizzo più diffuso delle reti condivise e l'introduzione 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 Raccomandazione 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. CAMPO DI APPLICAZIONE

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 Standardisation/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 Eurocontrol No 001-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 commutazione 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.

Figura 1

Modalità di interfaccia

>PIC FILE= "L_2000254IT.017801.EPS">

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 disposizioni 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 Eurocontrol.

Le revisioni degli altri documenti indicati come riferimenti non entrano a far parte delle disposizioni della presente norma Eurocontrol se non dopo essere state formalmente esaminate ed incorporate nella presente norma Eurocontrol.

In caso di conflitto tra le prescrizioni della presente norma Eurocontrol 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 dedicated 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-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 designed for interfacing to synchronous V-Series modems.

6. ISO/IEC 7776:1994, Information technology - Telecommunications 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 commutazione 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 - Telecommunications 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 struttura 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-switched signalling system between public network providing data transmission service.

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks.

4. DEFINIZIONI, SIMBOLI E ABBREVIAZIONI

4.1. Definizioni

4.1.1. Ai fini della presente norma Eurocontrol si applicano le definizioni seguenti:

4.1.2. Profilo: insieme di una o più norme di base e, se del caso, identificazione di particolari classi, sottoinsiemi, opzioni e parametri di queste norme di base, necessari per svolgere una funzione specifica [riferimento 2].

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. Simboli e abbreviazioni

>SPAZIO PER TABELLA>

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).NOTA

Se non diversamente specificato nelle norme internazionali 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 Eurocontrol è 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).NOTA

Si ottiene così una miglior definizione delle funzioni delle norme di base che sono condizionate, opzionali o dipendenti dal valore (cfr. E.3.1).

5. PANORAMICA TECNICA

5.1. Pila dei protocolli

NOTA

La 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 corrispondenti. 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.

Figura 2

Pila dei protocolli

>PIC FILE= "L_2000254IT.018201.EPS">

5.2. Struttura del profilo

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 (allegati 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. Rapporto con versioni precedenti delle specifiche

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 servizio 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) è separato 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 messaggi applicativi figurano ora nel Protocollo di intestazione dei messaggi (allegato B), che costituisce un livello di trasporto minimo per l'FDE.

6. REQUISITI PER IL PROFILO

6.1. Requisiti di conformità

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. Requisiti relativi ai livelli 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. Requisiti relativi ai livelli 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 4097 ottetti.NOTA

Il 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 4096.

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 funzionamento 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 conformemente alle specifiche dell'allegato C; in altri termini, il protocollo è totalmente simmetrico.NOTA

Alcune 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 DATANOTA

Impostare D=0 nei pacchetti CALL REQUEST e CALL ACCEPTED equivale a non usare la conferma di consegna.

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. METODI DI PROVA

NOTE

1. Un approccio utilizzabile per le prove di conformità relativamente 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à è illustrato nell'allegato E.

ALLEGATO A (Normativo)

PROTOCOLLO DI TRASFERIMENTO DI MESSAGGI

A.1. Introduzione

Le presenti specifiche definiscono un protocollo per l'implementazione 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 informazioni);

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 Eurocontrol.

A.4. Specifiche del protocollo

A.4.1. Introduzione

Il testo qui di seguito descrive il funzionamento di una associazione di trasferimento di messaggi attivata dall'applicazione. Altre associazioni 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 No 001-3-92, edizione 1:

Messaggi di sistema: questi messaggi sono usati per il monitoraggio del collegamento (messaggio HEARTBEAT) ed il controllo dell'applicazione (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'interscambio 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.

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'associazione applicativa e portare il protocollo nello stato DATA_READY. La primitiva deve essere invocata sia dall'applicazione 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 è ritrasmesso ed il timer riparte.NOTA

Il 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 ASSOCIATION_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.

NOTA

Questa 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. NOTA

Ogni 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 corrisponde alla primitiva di servizio MT-Abort-Request.

A.4.5.2. Si attuano le azioni seguenti:

- nello stato DATA_READY è trasmesso un messaggio SHUTDOWN (messaggio di sistema), i timer Tr e Ts sono fermati e la connessione di trasporto è rilasciata;

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

NOTA

Il 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 applicativa e qualsiasi livello inferiore (se necessario).NOTA

Se 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 servizio "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 HEARTBEAT (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 configurabile 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.NOTA

Il 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 applicazioni (dovuto ad esempio a malfunzionamento dell'hardware o del software; in alcuni casi la connessione di trasporto del livello inferiore può comunque funzionare).

NOTA

Secondo 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'applicazione 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;

- 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.NOTA

Nel 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

>SPAZIO PER TABELLA>

A.4.10.2. Lunghezza del testo del messaggio

Sono supportati messaggi con un testo di lunghezza fino a 4096 ottetti.

A.4.10.3. Formati dei messaggi di sistema

>SPAZIO PER TABELLA>

A.4.10.4. Altri formati di messaggio

>SPAZIO PER TABELLA>

NOTE

1. Il formato del testo del messaggio per i messaggi di status non rientra nel campo di applicazione della presente norma Eurocontrol.

2. Il formato dei messaggi operativi è specificato nelle norme e nei documenti Eurocontrol che definiscono applicazioni di messaggistica 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'interfaccia utente per visualizzare i messaggi ricevuti e per consentire la composizione di messaggi da trasmettere.

A.5. Tabelle di transizione degli stati di protocollo

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.NOTA

La 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

>SPAZIO PER TABELLA>

A.5.3. Eventi possibili

Tabella 2

Eventi possibili

>SPAZIO PER TABELLA>

A.5.4. Timer

Tabella 3

Timer

>SPAZIO PER TABELLA>

Il valore di questi timer è tale per cui Tr = 2Ts + tempo di attraversamento.NOTA

I valori tipici di questi timer sono: Ts = 30s, Tr = 70s.

A.5.5. Tabella di transizioni di stato

Tabella 4

Transizioni di stato

>SPAZIO PER TABELLA>

A.5.6. Diagramma delle transizioni di stato

NOTA

Il protocollo è descritto nella Figura A.1 sotto forma di diagramma delle transizioni di stato. Il diagramma è puramente 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 stato

>PIC FILE= "L_2000254IT.019301.EPS">

ALLEGATO B (Normativo)

PROTOCOLLO DI INTESTAZIONE DEI MESSAGGI

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. Servizio implementato

B.2.1. Il protocollo di intestazione dei messaggi corrisponde ad un sottoinsieme 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'applicazione

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. Servizio richiesto

Il protocollo presuppone un servizio di rete di base affidabile quale il servizio assicurato dal protocollo di livello pacchetto X.25. NOTA

Su ogni connessione di rete è supportata una sola connessione di trasporto.

B.4. Specifiche del protocollo

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 corrispondenza diretta tra le due serie di primitive (di richiesta e di indicazione). In alternativa si può usare una connessione di rete esistente (ad es. una connessione di rete stabilita dai meccanismi di gestione del sistema).Raccomandazioni

1. In quest'ultimo caso è opportuno effettuare il reset della connessione 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 condizioni seguenti:

- l'indirizzo della N-Connect-Indication dell'NSAP chiamante coincide con l'indirizzo della N-Connect-Request in attesa dell'NSAP chiamato

- l'indirizzo della N-Connect-Request in attesa dell'NSAP chiamante è 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).

B.4.3. Rilascio della connessione

B.4.3.1. Il rilascio della connessione si effettua mediante le primitive di servizio 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 connessioni 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 corrispondente 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 corrispondenza si stabilisce mediante un'unità di dati del protocollo di trasporto (TPDU) che è trasferita dal servizio di rete.

B.4.4.2.

>SPAZIO PER TABELLA>

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 bilateralmente.

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 4105 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.

ALLEGATO C (Normativo)

PROTOCOLLO DI RETE

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. Servizio fornito

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 servizio 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. Servizio richiesto

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. Indirizzi di NSAP

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.

>PIC FILE= "L_2000254IT.019702.EPS">

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.

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 indirettamente 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.

>SPAZIO PER TABELLA>

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. Specifiche relative al protocollo

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 definita nell'allegato A della norma ISO/IEC 8878 [riferimento 12] per il campo User Data in formato esteso disponibile con il servizio Fast Select è usata qui con il campo User Data in formato di base 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 INDICATION;

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

NOTA

Le 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 allegato 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.

Tabella 1

Codifica del campo User Data

>SPAZIO PER TABELLA>

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 INCOMING 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.

NOTA

L'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.

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.

NOTA

Di 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 indicare 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 ricevuta.

ALLEGATO D (Normativo)

DICHIARAZIONI PROFORMA PICS DI CONFORMITÀ AL PROFILO

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.NOTA

Dispensa dalla riserva dei diritti d'autore per le dichiarazioni 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'implementazione 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'implementazione 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. Istruzioni per la compilazione delle dichiarazioni proforma PICS

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 necessarie per identificare in modo completo sia il fornitore che l'implementazione.

D.2.1.2. La parte principale della dichiarazione proforma PICS è un questionario 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 riferimenti 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 condizionato) 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'elemento (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". NOTA

Quando 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 considerevole di informazioni supplementari, ed una PICS può essere considerata completa anche senza alcuna informazione supplementare. 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 riportati 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, aggiungendo 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.NOTA

La situazione sopra descritta può essere motivata dalla presenza nella norma di un difetto segnalato la cui correzione 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 condizionato della forma "< elemento >: < s >" nella colonna Status, dove "< elemento >" è un riferimento che compare nella prima colonna della tabella per qualche altro elemento, e "< s >" è un simbolo di status (M, O, O.< n > o X).NOTA

Una dichiarazione proforma PICS può contenere diversi elementi condizionati, per i quali sia l'applicabilità dell'elemento 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 è supportato, l'elemento condizionato è applicabile e il suo status è indicato da "< s >": 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 condizionato è indicato con un asterisco nella colonna Elemento.

D.3. Dichiarazione proforma PICS per il Protocollo di trasferimento di messaggi

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.

>SPAZIO PER TABELLA>

D.3.2. Identificazione

>PIC FILE= "L_2000254IT.020301.EPS">

D.3.3. Implementazione del protocollo

>PIC FILE= "L_2000254IT.020401.EPS">

D.4. Dichiarazione proforma PICS per il protocollo di intestazione dei 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)

D.4.1.2. Abbreviazioni

NA non applicabile

D.4.1.3. Riferimenti degli elementi

>SPAZIO PER TABELLA>

D.4.2. Identificazione

>PIC FILE= "L_2000254IT.020501.EPS">

D.4.3. Implementazione del protocollo

>PIC FILE= "L_2000254IT.020601.EPS">

D.5. Dichiarazione proforma PICS per il protocollo di rete

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

>SPAZIO PER TABELLA>

D.5.2. Identificazione

>PIC FILE= "L_2000254IT.020701.EPS">

D.5.3. Implementazione del protocollo

>PIC FILE= "L_2000254IT.020702.EPS">

ALLEGATO E (Normativo)

LISTA DEI REQUISITI PER IL PROFILO

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 istruzioni riportate qui di seguito.NOTA

Le dichiarazioni proforma del presente allegato si basano su quelle che accompagnano le norme di base a cui si fa riferimento.

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. Ruolo della PRL e delle dichiarazioni proforma PICS

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 Raccomandazione 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 elaborazione 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 dichiarazioni 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 dichiarazioni proforma compilate formano insieme la dichiarazione di conformità dell'implementazione del profilo (ICS).

- Secondo la metodologia della norma ISO/IEC TR 10000-1 [riferimento 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'implementazione 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 accettazione.

- 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 condizione 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à al profilo 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 amministrazioni appaltanti.

- Integrazione di prodotti disponibili sul mercato in un'implementazione del profilo in tutti i casi suindicati: al fornitore di un prodotto dovrebbe essere chiesto di presentare le dichiarazioni 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 documentazione relativa all'implementazione; può servire per prevedere l'interoperabilità con altre amministrazioni e per individuare 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 notazione 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 interesse 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 < predicato > (l'estensione del gruppo è indicata dalla presentazione).

< predicato >: introduce un elemento singolo, condizionato in base al < predicato >.

NOTA

Il 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 notazione ma in lettere maiuscole (M, O, O.< n >, X).

E.4. Istruzioni per la compilazione delle dichiarazioni proforma PICS

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, unitamente 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 applicano i requisiti indicati in questa PRL (nella colonna "Caratteristiche del profilo", ove questa è presente) per limitare le risposte ammissibili 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 parametro.

E.4.4. Se un requisito obbligatorio non è soddisfatto si devono fornire informazioni sulla difformità immettendo un riferimento X, dove è un identificatore univoco che rimanda ad un'acclusa motivazione della non conformità.NOTA

Una difformità si può avere ad esempio nel caso di un'implementazione 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 (allegato 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].

E.6. Dichiarazione di conformità

E.6.1. Presentazione generale della conformità

>PIC FILE= "L_2000254IT.021101.EPS">

E.6.2. Requisiti di conformità dinamica

>PIC FILE= "L_2000254IT.021201.EPS">

E.7. Requisiti relativi ai livelli superiori

Tabella 3

Protocollo di trasferimento di messaggi

>SPAZIO PER TABELLA>

E.8. Requisiti relativi ai livelli inferiori

E.8.1. Requisiti relativi al livello di trasporto

Tabella 4

Protocollo di intestazione dei messaggi

>SPAZIO PER TABELLA>

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.

E.8.2.1. Caratteristiche generali del DTE

Tabella 5

Caratteristiche generali del DTE

>SPAZIO PER TABELLA>

E.8.2.2. Procedure, tipi e formati di pacchetto

Tabella 6

Funzioni del livello pacchetto indipendenti dai canali logici

>SPAZIO PER TABELLA>

Tabella 7

Formazione della connessione

>SPAZIO PER TABELLA>

Tabella 8

Svincolo della connessione

>SPAZIO PER TABELLA>

Tabella 9

Reset dei canali logici

>SPAZIO PER TABELLA>

Tabella 10

Procedure di errore

>SPAZIO PER TABELLA>

Tabella 11

Interruzione del trasferimento

>SPAZIO PER TABELLA>

Tabella 12

Invio di dati

>SPAZIO PER TABELLA>

Tabella 13

Ricezione di dati

>SPAZIO PER TABELLA>

Tabella 14

Conferma di consegna

>SPAZIO PER TABELLA>

E.8.2.3. Caratteristiche ed opzioni varie

Tabella 15

Valori dei codici di causa e diagnosi

>SPAZIO PER TABELLA>

E.8.2.4. Servizi opzionali

Tabella 16

Servizi opzionali inviati nei pacchetti CALL REQUEST

>SPAZIO PER TABELLA>

Tabella 17

Servizi opzionali inviati nei pacchetti CALL ACCEPTED

>SPAZIO PER TABELLA>

Tabella 18

Servizi opzionali inviati nei pacchetti CLEAR REQUEST

>SPAZIO PER TABELLA>

Tabella 19

Servizi opzionali ricevuti nei pacchetti INCOMING CALL

>SPAZIO PER TABELLA>

Tabella 20

Servizi opzionali ricevuti nei pacchetti CALL CONNECTED

>SPAZIO PER TABELLA>

Tabella 21

Servizi opzionali ricevuti nei pacchetti CLEAR INDICATION

>SPAZIO PER TABELLA>

Tabella 22

Servizi opzionali ricevuti nei pacchetti CLEAR CONFIRMATION

>SPAZIO PER TABELLA>

E.8.2.5. Valori e range dei parametri

Tabella 23

Valori e range dei parametri

>SPAZIO PER TABELLA>

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

>SPAZIO PER TABELLA>

E.8.4. Requisiti relativi al livello fisico

Cfr. ISO/IEC TR 10609-9 clausola A.4 [riferimento 8].

ALLEGATO F (Informativo)

METODOLOGIE PER LE PROVE DI CONFORMITÀ

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. Scopo e campo d'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 Division) FDE ICD Part 1 Integration Test Plan Version 1.0, 10 maggio 1996 [riferimento 15].

F.4. Metodi e pratiche di sviluppo

F.4.1. Le implementazioni dell'ICD possono essere realizzate usando particolari versioni ed opzioni dell'ICD stesso. Per stabilire le potenzialità di interfunzionamento, uno Stato membro che implementa l'interfaccia 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 di conformità 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 internazionali (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 normalizzato 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 normalizzate è stata elaborata in parte da Eurocontrol.

F.5.1.4. In base alla figura 2, la prova del sistema terminale completo è costituita 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 informazioni dettagliate sui risultati di qualsiasi prova effettuata.

ALLEGATO G (Informativo)

ASSEGNAZIONE DEGLI IDENTIFICATORI DEGLI ENTI ATC

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 definita nell'allegato C.

Tabella 1

Identificatori degli enti ATC

>SPAZIO PER TABELLA>

ALLEGATO H (Informativo)

DIRETTIVE SULL'AFFIDABILITÀ, LA DISPONIBILITÀ E LA SICUREZZA

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. Scopo e campo d'applicazione

H.2.1. Lo scopo del presente allegato è fornire direttive su questioni riguardanti 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 dettagliata contenuta nel documento seguente:

Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [riferimento 16].

H.4. Implementazioni su linea affittata

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 specificato 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 utilizzare 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'adattatore 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'identificazione del chiamante e informazioni per l'autenticazione.

H.4.4. Esempio di configurazione

Figura H.1

Esempio di configurazione per una linea affittata

>PIC FILE= "L_2000254IT.023301.EPS">

H.5. Implementazione su rete

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 diversi 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 limitando 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 chiamante 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 malfunzionamento 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 malfunzionamenti 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.

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 rete

>PIC FILE= "L_2000254IT.023401.EPS">