Kommissionens forordning (EF) nr. 2082/2000

af 6. september 2000

om vedtagelse af Eurocontrol-standarder og om ændring af direktiv 97/15/EF om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØF

KOMMISSIONEN FOR DE EUROPÆISKE FÆLLESSKABER HAR -

under henvisning til traktaten om oprettelse af Det Europæiske Fællesskab,

under henvisning til Rådets direktiv 93/65/EØF af 19. juli 1993 om definition og anvendelse af kompatible tekniske specifikationer for erhvervelse af udstyr og systemer til regulering af lufttrafikken (air-traffic-management equipment and systems)(1), særlig artikel 3,

under henvisning til Kommissionens direktiv 97/15/EF af 25. marts 1997, om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØF(2), og

ud fra følgende betragtninger:

(1) Ved direktiv 97/15/EF blev der vedtaget en Eurocontrol-standard for online dataudveksling (On-Line Data Interchange (OLDI), udgave 1.0) og en Eurocontrol-standard for præsentation af udvekslede ATS-data (Air Traffic Services Data Exchange Presentation (ADEXP), udgave 1.0).

(2) Eurocontrol har vedtaget nyere versioner af de to nævnte standarder, nemlig OLDI udgave 2.2 og ADEXP udgave 2.0, samt en ny Eurocontrol-standard med titlen "Dokument vedrørende kontrol med udveksling af flyvedata" (Flight Data Exchange - Interface Control Document (FDE-ICD)).

(3) Disse Eurocontrol-standarder er omfattet af direktiv 93/65/EØF og bidrager til harmoniseringen af medlemsstaternes nationale systemer for lufttrafikstyring, særlig hvad angår overførsel af flyvninger mellem flyveledelsescentre (OLDI), styring af lufttrafikstrømmen (ADEXP) og kommunikation mellem nationale systemer (FDE-ICD).

(4) Udgave 2.2 af OLDI og 2.0 af ADEXP erstatter de nugældende ældre versioner, der er anført i direktiv 97/15/EF, artikel 1, hvorfor denne artikel skal ophæves.

(5) De i denne forordning fastsatte bestemmelser er i overensstemmelse med udtalelse fra det udvalg, der er nedsat i henhold til direktiv 93/65/EØF -

UDSTEDT FØLGENDE FORORDNING:

Artikel 1

Da de obligatoriske dele af de Eurocontrol-specifikationer, der er indeholdt i følgende dokumenter om Eurocontrol-standarder, er nødvendige for gennemførelsen af et integreret europæisk system for lufttrafikstyring, vedtages de hermed inden for rammerne af direktiv 93/65/EØF:

- Eurocontrol-standard for online dataudveksling (OLDI), udgave 2.2 (Eurocontrols dokumentreference: DPS.ET1.ST06-STD), hvis ordlyd er anført i bilag I til denne forordning

- Eurocontrol-standard for præsentation af udvekslede ATS-data (ADEXP), udgave 2.0 (Eurocontrols dokumentreference: DPS.ET1.ST09-STD), hvis ordlyd er anført i bilag II til denne forordning

- Eurocontrol-standarden "Dokument vedrørende kontrol med udveksling af flyvedata" (FDE-ICD), udgave 1.0 (Eurocontrols dokumentreference: COM.ET1.ST12-STD), hvis ordlyd er anført i bilag III til denne forordning.

Artikel 2

Artikel 1 i direktiv 97/15/EF ophæves.

Artikel 3

Denne forordning træder i kraft på tredjedagen efter offentliggørelsen i De Europæiske Fællesskabers Tidende.

Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.

Udfærdiget i Bruxelles, den 6. september 2000.

På Kommissionens vegne

Loyola De Palacio

Næstformand

(1) EFT L 187 af 29.7.1993, s. 52.

(2) EFT L 95 af 10.4.1997, s. 16.

BILAG I

ON-LINE DATAUDVEKSLING (OLDI) UDGAVE 2.2

(Eurocontrols dokumentreference: DPS.ET1.ST06-STD)

INDHOLDSFORTEGNELSE

>TABELPOSITION>

ANGIVELSE AF OPHAVSRET

Dette dokument er frembragt af Eurocontrol Agenturet.

Ophavsretten besiddes af Eurocontrol Agenturet.

Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt samtykke ved Eurocontrol Agenturet.

FORORD

1. Ansvarlig Institution

Eurocontrol-standarden for On-Line Dataudveksling (OLDI), Udgave 2.2, er blevet forberedt af Directorate of European ATC Harmonisation and Integration Programme (Direktoratet for Program for Harmonisering og Integration af Lufttrafikkontrol i Europa) (EATCHIP), Development (Udvikling) (DED), Eurocontrol, som også er ansvarlig for opdateringen af dokumentet. Alle kommentarer eller forespørgsler bør henvendes til Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for Division DED-2's opmærksomhed.

2. Forhold til EATCHIP Arbejdsprogramdokumentet

Denne standard udgør en indlevering under Specialist Task DPS.ET1.ST06 i EATCHIP's domæne ATM Data Processing Systems (Databehandlingssystemer) (DPS) som specificeret i EATCHIP Arbejdsprogramdokument (EWPD), Udgave 2.0, dateret 30. september 94.

3. Godkendelse og Rettelser

Denne standard har været genstand for den følgende godkendelsesprocedure som beskrevet detaljeret i Direktiverne for Eurocontrol standardisering:

- Godkendelse ved the EATCHIP Operational Requirement and ATM Data Processing Team (ODT) (Team for Operationelle Krav og Behandling af ATM-data) ved korrespondanceprocedure;

- Konsultation af alle ECAC-Lande gennem deres repræsentanter i the Committee of Management eller EATCHIP Project Board;

- Godkendelse ved the EATCHIP Project Board og the Committee of Management;

- Tiltrædelse ved the Permanent Commission (Den Permanente Kommission).

Denne standards bestemmelser er effektive efter en tiltrædelse ved Den Permanente Kommission.

For at imødekomme kravene fra udviklingen af Flyvekontroltjenesteprocedurer (ATC-procedurer) kan rettelser og tilføjelser foreslås gennem ODT for diskussion og mulig godkendelse. Kravene vil enten blive indarbejdet som en rettelse eller som en yderligere udgave af dokumentet for endossering og godkendelse i overensstemmelse med de specificerede procedurer.

4. Redaktionel Praksis

Den følgende praksis er blevet anvendt for at angive hver erklærings status: Retningsgivende Elementer er blevet skrevet som tekst med lys skrift; Anbefalede Elementer er blevet skrevet med lys, kursiv skrift, hvor statusen er blevet angivet med præfikset Anbefaling.

Den følgende, redaktionelle praksis er blevet fulgt i skrivningen af specifikationerne: for Retningsgivende Elementer er det operative udsagnsord "skal" anvendt og for Anbefalede Elementer er det operative udsagnsord "bør" anvendt.

Noter er skrevet med lys, kursiv skrift indledt med præfikset "NOTE".

5. Forhold til Udgave 1 af Eurocontrol-standarden for On-Line Datauudveksling

Dette dokument erstatter Delene 1 og 2 af Udgave 1 af Eurocontrol- standarden for On-Line Dataudveksling. Del 3, som beskriver de tekniske protokoller, der skal anvendes, erstattes af Eurocontrol-standarden for Dokument vedrørende Kontrol med Udveksling af Flyvedata, Del 1.

6. Signifikante Ændringer i forhold til Udgave 1

Det følgende er de mest signifikante ændringer af og tilføjelser til Udgave 1:

1. Indarbejdelse af de følgende ekstra (ikke-obligatoriske) meddelelser med hensyn til den grundlæggende procedure:

- Meddelelser om Ophævelsen af Koordinering (MAC);

- Kodetildelingsmeddelelse (COD) for Sekundær Radar (SSR);

- Informationsmeddelelse (INF).

2. Definition af indhold og format af meddelelser til at understøtte grænsekrydsningen af en flyvning på en kurs, som ikke er en defineret Lufttrafiktjenesterute (ATS-rute), men som er defineret ved rutesegmentets begyndelses- og slutpunkter.

3. Indarbejdelse af en dialogprocedure, som tillader:

- identifikationen og forhandlingen af ikke-standard overførselsbetingelser ved flyveledere, som udfører planlægningsfunktionen;

- tilvejebringelsen af evnen for den accepterende enhed til at stille mod-forslag til overførselsbetingelser;

- tilvejebringelsen af overførsel af kommunikationsfaciliteter som del af proceduren med overførslen af kontrol.

4. Anvendelsen af det format, der er beskrevet i Udgave 2 af Eurocontrol-standarddokumentet for Præsentation af Udvekslede ATS-data (ADEXP), er indført. Alle meddelelser, som er specificeret under den grundlæggende procedure, og de, der anvendes under dialogprocedurens koordineringsfase, er beskrevet ved anvendelse af både Formater for Civil Aviation Organisation (ICAO-formater) og ADEXP-formater. Meddelelser om Overførsel af Kommunikation beskrevet under dialogprocedure er kun beskrevet ved anvendelse af ADEXP-format.

5. Sletning af de følgende Annekser til Udgave 1:

A: AATC-Enhedsidentifikation.

B: OLDI- Meddelelsesstruktur

(alle meddelelser i Udgave 3 omfatter Eksempler).

D: Historisk Oversigt.

E: Implementeringsplan.

F: Indvigelse ved Lande.

G: Retningslinier for Implementering.

H: Retningslinier for Evaluering af OLDI.

6. Adskillelse af Del 3 - Tekniske Krav - fra anvendelsesspecifikationen.

7. Forhold til Andre Dokumenter

Dette dokument henviser til anvendelsen af to typer af feltformat i udarbejdelsen af meddelelser; disse er ICAO og ADEXP.

ICAO-feltformater er beskrevet i Henvisning 1. I tilfælde af at Henvisning 1 erstattes af et andet dokument, skal definition af ICAO-felttyper være som i det dokument.

Formats for ADEXP-felter er beskrevet i Henvisning 2.

NOTE

Henviste dokumenter er oplistet i Afsnit 2.

8. Sprog

Det engelske sprog er blevet anvendt ved udfærdigelsen af dette dokuments original.

1. INTRODUKTION

1.1. Formål

1.1.1. Flyvninger, der er forsynet med en ATC-tjeneste, overføres fra én ATC-enhed til den næste på en måde, som er udformet til at sikre fuldstændig sikkerhed. For at opnå dette formål er det en standardprocedure, at passagen af hver flyvning på tværs af grænsen mellem ansvarsområderne for de to enheder koordineres mellem dem forlods og at kontrollen med flyvningen overføres, når den er ved eller støder op til grænsen.

1.1.2. Passagen af data med hensyn til individuelle flyvninger som del af koordineringsprocessen er, hvor den udføres over telefon, en større understøttelsesopgave ved ATC-enheder, i særdeleshed ved Kontrolcentraler (ACCer). Den operationelle brug af forbindelser mellem Flyvedatabehandlingssystemer (FDPSer) ved ACCer med henblik på at erstatte sådanne verbale "estimater", hvilket betegnes On-Line Data Interchange (On-Line Dataudveksling) (OLDI), begyndte i Europa i de tidlige 1980'ere.

1.1.3. For at lette implementering blev fælles regler og meddelelsesformater udarbejdet og vedtaget af de berørte agenturer og er indarbejdet i Udgave 1 af Eurocontrol-standarden for On-Line Dataudveksling; dette dokument, Udgave 1, er blevet fremstillet for at støtte den fortsatte udvikling af sådanne faciliteter i overensstemmelse med EATCHIPs krav.

1.2. Omfang

1.2.1. Dette dokument specificerer de faciliteter og meddelelser, som skal tilvejebringes mellem de FDPSer, der betjener ATC-enheder, med henblik på at opnå:

- den påkrævede koordinering forud for overførslen af flyvninger fra én enhed til den næste;

- overførslen af sådanne flyvningers kommunikation.

1.2.2. Dette dokument:

- definerer meddelelsesformaterne og reglerne for indholdet;

- beskriver de faciliteter, der er påkrævet ved sådanne enheder, hvilke faciliteter er en forudsætning for brugen af dataudveksling til dette formål.

1.2.3. Denne standard kan anvendes mellem medlemslandene af Eurocontrol til internationale OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste.

1.2.4. Anbefaling

Det anbefales, at lande ved Den Europæiske Civile Luftfartskonference (European Civil Aviation Conference (ECAC)) vil anvende denne standard til:

- internationale OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste inden for ECAC-området;

- OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste, hvilke enheder er interne i det pågældende land.

2. HENVISNINGER

2.1. De følgende Dokumenter indholder bestemmelser, som ved henvisning i denne tekst udgør bestemmelser for dette Eurocontrol-standarddokument.

Ved tidspunktet for offentliggørelse af dette Eurocontrol-standarddokument var de anførte udgaver af de henviste dokumenter gyldige.

Der skal øjeblikkeligt tages hensyn til en hvilken som helst revidering af de henviste ICAO Dokumenter for at revidere dette Eurocontrol-standarddokument.

Revideringer af de andre henviste dokumenter skal ikke udgøre en del af bestemmelserne i dette Eurocontrol-standarddokument før de formelt er bedømt og indarbejdet i dette Eurocontrol-standarddokument.

I tilfælde af konflikt mellem kravene i dette Eurocontrol-standarddokument og indholdet i disse andre henviste dokumenter, skal dette Eurocontrol-standarddokument have forrang.

2.2. Der henvises til følgende dokumenter i dette standarddokument:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services, ICAO Document 4444, Trettende udgave, dateret 7 nov. 1996, som det er rettet.

2. Udgave 2.0 af Eurocontrol Standard document ATS Data Exchange Presentation (Eurocontrol-standarddokument for Præsentation af udvekslede ATS-data) (ADEXP), henvisning DPS-ET1-ST09-STD-01-00, dateret juni 1998.

3. DEFINITIONER, SYMBOLER OG FORKORTELSER

3.1. Definitioner

Med henblik på denne Eurocontrol-standard skal de følgende definitioner gælde.

3.1.1. Accepterende Enhed (Accepting Unit): Den enhed, som leverer en ATC-tjeneste, der skal tage kontrol eller har taget kontrol over en flyvning, når overførslen fra én enhed til den næste skal ske eller er sket.

3.1.2. Kvittering (Acknowledgement): Oplysning om, at en meddelelse er blevet modtaget og at det er konstateret, at den kan behandles korrekt.

3.1.3. Aktivering (Activation): Den proces i en modtagende ATC-enhed, hvorved flyveplanen for den refererede flyvning opgraderes til at indeholde de data, der fremskaffes af den overførende enhed, som en del af koordineringsprocessen mellem de to enheder og som resulterer i fremskaffelsen af dataene til flyveledere.

3.1.4. Højde (Altitude): Den vertikale afstand for et niveau, et punkt eller en genstand, der betragtes som et punkt, målt fra middelvandstand.

3.1.5. Anvendelse (Application): Den del af et ATS-undersystem, som opfylder denne standard og grænseflader med sådanne helheder i andre ATS-systemer.

3.1.6. Ansvarlighedsområde (Area of Responsibility): Et luftrum med definerede dimensioner, inden i hvilket en ATC-enhed sørger for lufttrafiktjeneste.

3.1.7. Forbindelse (Association): En procedure, hvori et system forbinder en modtaget OLDI-meddelelse med en flyveplansindførsel i databasen.

3.1.8. ATC-Enhed (ATC Unit): En enhed, der sørger for en flyvekontroltjeneste.

3.1.9. Tilgængelighed (Availability): En sandsynlighed for, at en facilitet vil være tilgængelig for en bruger til et tidspunkt.

3.1.10. Grænse (Boundary): De planer (laterale og vertikale), der afgrænser en ATC-enheds ansvarlighedsområde.

3.1.11. Klareret Flyveniveau (Cleared Flight Level): Det flyveniveau til hvilket eller ved hvilket en flyvning aktuelt er blevet klareret af ATC.

3.1.12. Koordinering, ATC (Co-ordination, ATC): Den proces, som udføres mellem ATC-enheder med tilstødende ansvarlighedsområder, med formelt at advisere hinanden om den planlagte passage af flyvninger på tværs af grænsen for at sikre flysikkerhed gennem konsistens af tilsigtede aktioner.

3.1.13. Koordineringsmeddelelse (Co-ordination Message): En fællesbetegnelse, som henviser til en meddelelse, der anvendes til at udføre ATC-koordinering. Disse indeholder CDNen, som er en specifik meddelelse beskrevet i afsnit 8.8.

3.1.14. Koordineringsfase (Co-ordination Phase): Den fase, hvorunder de overførende og modtagende ATC-enheder bliver enige om de betingelser (f.eks. flyveniveau, grænsepunkt), under hvilke en flyvning vil passere fra den ene enheds styring til den anden enheds styring, med hensyn til en given flyvning.

3.1.15. Koordineringspunkt (Co-ordination Point): Et punkt på eller stødende op til grænsen, hvilket punkt kendes af ATC-enhederne i en koordineringssekvens og henvises der til i koordineringsmeddelelser.

3.1.16. Korrelation (Correlation): Den proces, der er baseret på definerede kriteria med hensyn til at forbinde flyveplandata og radarsporet for den samme flyvning, almindeligvis for præsentation på et flyvelederdisplay.

3.1.17. Eurocontrol-Standard (Eurocontrol Standard): En hvilken som helst specifikation for fysiske kendetegn, konfiguration, materiale, ydeevne, mandskab eller procedure, hvis ensartede anvendelse er blevet godkendt som værende væsentlig for implementering i ATS-systemer i Eurocontrol-Medlemslande. En Eurocontrol-standard må ikke være i konflikt med ICAO standarder, men bør komplementere sidstnævnte, hvor det er hensigtsmæssigt.

3.1.18. Udøvende Flyveleder (Executive controller): En flyveleder, som giver instruktioner direkte til flyvninger under hans/hendes kontrol. Sådanne flyveledere omfatter de, der sørger for områderadarkontroltjeneste.

3.1.19. Udgangsniveau (Exit Level): Det niveau, hvor en flyvning er blevet koordineret til at krydse en overførsel af kontrolpunkt. Et udgangsniveau kan omfatte supplerende krydsningsbetingelser, der definerer det niveaubånd, som en stigende/nedstigende flyvning vil være indenfor.

3.1.20. Flyveplan (Flight Plan): Specificeret information leveret til lufttrafiktjenesteenheder i forbindelse med et luftfartøjs tiltænkte flyvning eller en del af dets tiltænkte flyvning. Endvidere information udledt fra flyveplanen for en specifik flyvning, der holdes inden for et FDPS.

3.1.21. Generering (Generate): En proces i et ATC-system, hvor relevante data uddrages fra databasen/databaserne og der dannes en meddelelse til transmission til en modtagende ATC-enhed.

3.1.22. ICAO Format (ICAO Format): Det format, der anvendes for jord-jord-transmissionen af ATS-meddelelser og som bruger de felttyper og -separatorer, der er beskrevet i Henvisning 1.

3.1.23. Niveau (Level): Et fælles udtryk, som angår vertikal position af et luftfartøj i flyvning; inden for denne standard omfatter udtrykket niveau eller flyveniveau højde i de tilfælde, hvor det bruges.

3.1.24. Underretning (Notification): Den proces, hvorved den overførende enhed transmitterer data til at opdatere systemet ved den modtagende enhed som forberedelse til koordineringsfasen.

3.1.25. Modtagende Enhed (Receiving Unit): Den ATC-enhed, som en meddelelse sendes til.

3.1.26. Pålidelighed (Reliability): Den procentdel af den planlagte tilgængelighed i løbet af hvilken tjenesten skal være driftsklar.

3.1.27. Anmodet flyveniveau (Requested Flight Level): Et flyveniveau, der anmodes om ved flyvningen i flyveplanen.

3.1.28. Revidering (Revision): En rettelse til data, som tidligere er blevet sendt af den overførende ATC-enhed til den modtagende ATC-enhed.

3.1.29. Supplerende Krydsningsniveau (Supplementary Crossing Level): Et niveau, ved hvilket eller over hvilket, eller ved hvilket eller under hvilket en flyvning er blevet koordineret til at krydse overførslen af kontrolpunkt. Det supplerende niveau er, hvis det er til stede, et element i udgangsniveauet.

3.1.30. Systemflyveplan (System Flight Plan): Information udledt fra flyveplanen for en specifik flyvning, der holdes inden for et FDPS.

3.1.31. Transaktionstid (Transaction Time): Et tidsinterval, der følger efter initieringen af en meddelelse, i løbet af hvilket der udføres transmission, indledende behandling i det modtagende system, generering og transmission af en kvitteringsmeddelelse og dens identifikation i det overførende system.

3.1.32. Overførsel af Kontrolpunkt (Transfer of Control Point): Et defineret punkt, som er placeret ved et luftfartøjs flyvevej, ved hvilket punkt ansvaret for at levere ATS til luftfartøjet overføres fra én ATC-enhed eller kontrolposition til den næste. Det er ikke nødvendigvis sammenfaldende med koordineringspunktet.

3.1.33. Overførselsfase (Transfer Phase): En flyvefase, som følger efter koordineringsfasen, hvorunder overførslen af kommunikation gennemføres.

3.1.34. Overførende Enhed (Transferring Unit): Den ATS-enhed, der i en koordineringssekvens er ansvarlig for at levere en tjeneste til en flyvning før grænsen og som påbegynder koordineringsfasen med den næste enhed.

3.1.35. Transmittering (Transmit): Kommunikering af en meddelelse fra ét system til et andet.

3.1.36. Enhed (Unit): Lufttrafiktjenesteenhed.

3.1.37. Advarsel (Warning): En meddelelse, der vises i en arbejdsposition, når den automatiske koordineringsproces har svigtet.

3.2. Symboler og Forkortelser

Med henblik på denne Eurocontrol-standard skal de følgende symboler og forkortelser gælde.

ABI Forudgående Grænseinformationsmeddelelse (Advance Boundary Information Message)

ACC Kontrolcentral (Area Control Centre)

ACP Acceptmeddelelse (Accept Message)

ACT Aktiveringsmeddelelse (Activate Message)

ADEXP Præsentation af Udvekslede ATS-Data (ATS Data Exchange Presentation)

ATC Flyvekontroltjeneste (Air Traffic Control)

ATM Regulering af Lufttrafikken (Air Traffic Management)

ATS Lufttrafiktjeneste (Air Traffic Service)

CDN Koordineringsmeddelelse (Co-ordination Message)

CNL Flyveplansannulering (Fligth Plan Cancellation)

COD SSR Kodetildelingsmeddelelse (SSR Code Assignment Message)

COF Frekvensændringsmeddelelse (Change of Frequency Message)

COP Koordineringsspunkt (Co-ordination Point)

DED Direktorat for EATCHIP-Udvikling, Eurocontrol (Directorate of EATCHIP Development Eurocontrol)

EATCHIP Program for Harmonisering og Integration af Lufttrafikkontrol i Europa (European ATC Harmonisation and Integration Programme)

ECAC Den Europæiske Civile Luftfartskonference (European Civil Aviation Conference)

ETO Forventet Tidspunkt over (Estimated time over)

ETOT Forventet Starttid (Estimate Take-Off Time)

EWPD Dokument for EATCHIP Arbejdsprogram (EATCHIP Work Programme Document)

FDPS Flyvedatabehandlingssystem (Flight Data Processing System)

FRF Yderligere Rute for Flyvning (Further Route of Flight)

HMI Menneske-Maskine-Grænseflade (Human-Machine-Interface)

HOP Meddelelse om Forslag om Overdragelse (Handover Proposal Message)

ICAO Den Internationale Civile Luftfarts Organisation (International Civil Aviation Organisation)

INF Informationsmeddelelse (Information Message)

LAM Logisk Kvitteringsmeddelelse (Logical Acknowledgement Message)

LoA Aftalebrev (Letter of Agreement)

MAC Meddelelse for Ophævelsen af Koordinering (Message for the Abrogation of Co-ordination)

MAS Meddelelse om Manuel Overtagelse af Kommunikation (Manuel Assumption of Communications)

NM Sømil (Nautical Mile)

OLDI On-Line Dataudveksling (On-Line Data Interchange)

ORCAM Metode til Kodetildeling for Oprindeligt Område (Originating Region Code Assignment Method)

PAC Foreløbig Aktiveringsmeddelelse (Preliminary Activate Message)

RAP Meddelelse om Henvist Aktiveringsforslag (Referred Activate Proposal Message)

REV Revideringsmeddelelse (Revision Message)

RJC Meddelelse om Afvisning af Koordinering (Reject Co-ordination Message)

ROF Frekvensanmodningsmeddelelse (Request on Frequency Message)

RRV Meddelelse om Henvist Revidering (Referred Revision Message)

SBY Stand-by Meddelelse (Stand-by Message)

SDM Supplerende Datameddelelse (Supplementary Data Message)

SSR Sekundær Radar (Secondary Surveillance Radar)

SYSCO Systemstøttet Koordinering (System Supported Co-ordination)

TI Overførselsinitiering (Transfer Initiation)

TIM Overførselsinitieringsmeddelelse (Transfer Initiation Message)

TWR/APP Tårn (luftfartøjskontrol) og Indflyvningskontrol (Tower (aerodrome control) and Approach Control

4. GENERELLE KRAV

4.1. Introduktion

Dette afsnit beskriver de generelle, operationelle krav, der er nødvendige for implementeringen af en OLDI-facilitet mellem ATC-enheder, og kravene til klassifikation og ydeevne for de forskellige typer af anvendte meddelelser.

4.2. Krav til Flyvedatabehandlingssystem

4.2.1. Flyvedatabase

Enheder, som anvender en facilitet beskrevet i dette dokument, skal være forsynet med data fra et FDPS, hvilke data indeholder al den information, der er påkrævet for visningen, behandlingen og kompileringen af meddelelserne som specificeret. Den primære datakilde for hver flyvning er flyveplanen, der er indleveret af fartøjschefen eller på hans/hendes vegne. Yderligere dataelementer opnås ved behandlingen af flyveplaner med henvisning til den pågældende enheds ydre forhold.

4.2.2. Operation i Realtid

OLDI-proceduren indeholder hændelser i den overførende ATC-enhed til at initiere funktioner, som er nødvendige for den rettidige præsentation af data til den overførende flyveleder og transmissionen af koordineringsdata til den accepterende enhed. Til dette formål skal FDPSet være i stand til at initiere funktioner ved sammenligningen af Koordineret Universal Tid og egnede tidsparametre med tider ved specificerede positioner på flyvningens rute som bestemt fra flyvedatabasen.

4.2.3. Datakommunikationskapacitet

4.2.3.1. FDPSet skal være i stand til at modtage og transmittere flyvedata i det format, der er egnet for meddelelsen som specificeret i dette dokument, via et datakommunikationsmedium, der understøtter OLDI-funktionen.

4.2.3.2. Anbefaling

FDPSet bør have udviklingspotentialet til at muliggøre tilføjelsen af nye meddelelser, der kan være indbefattet i fremtidige udgaver af denne standard.

4.2.3.3. Inden for de krav til ydeevne, som er specificeret i dette dokument, skal datakommunikationsmediet sørge for en hurtig og pålidelig anvendelse-til-anvendelse-dataudveksling ved:

- at sikre integriteten af transmissionen af OLDI-meddelelsen;

og

- at overvåge enten punkt-til-punkt-forbindelser eller statusen af kommunikationsnetværket, afhængigt af hvad der er velegnet.

4.2.3.4. FDPSet skal advare arbejdspositionerne, når der detekteres anormaliteter ved hjælp af datakommunikationssystemet.

4.2.4. Anvendelsesfunktioner

4.2.4.1. De systemer, der bruges til tilvejebringelsen af OLDI-faciliteter, skal være i stand til automatisk at modtage, lagre, behandle, uddrage og levere til display og overføre OLDI-relaterede data i realtid.

4.2.4.2. FDPSet skal:

- udtrykke foreliggende, operationelle data, der er relevante for OLDI-funktion som påkrævet ved denne standard, enten opdateret automatisk, gennem manuel indførsel eller ved en kombination af begge;

- være i stand til at uddrage sådanne elementer fra flyveplansdatabasen;

- identificere den næste ATC-enhed på flyvningens rute.

4.2.4.3. Det følgende skal aftales bilateralt:

- Koordineringspunkter (COPer);

- Henvisningspunkter, der anvendes til pejlings- og afstandsnotationer ved identifikationen af COP på direkte segmenter uden for ATS, hvor disse anvendes.

NOTE

COPerne er ikke altid identiske med overførslen af kontrolpunkter.

4.2.5. Menneske-maskine-grænseflade (HMI)

4.2.5.1. HMIen skal være i stand til:

- at vise det operationelle indhold af OLDI-meddelelser og relevante advarsler knyttet til modtagede meddelelser for øjeblikkelig opmærksomhed;

- at rette koordinerings- og overførselsmeddelelsesadvarsler til de operationelle positioner, der er ansvarlige for koordineringen af de pågældende flyvninger.

4.2.5.2. ATC-personale skal være forsynet med et middel til at modificere de data, hvorfra det operationelle indhold af meddelelserne udledes som påkrævet i dette dokument.

4.2.5.3. HMIen skal indikere, at transmission af meddelelsen er under udførelse eller at meddelelsen er blevet transmitteret vellykket, alt efter hvad der er tilfældet.

4.2.5.4. En advarsel eller underretning til den passende ATC eller de(n) passende tekniske position(er) skal genereres automatisk, hvis der ikke er blevet modtaget nogen kvittering inden for den parametertid, der følger efter en transmission af en koordinerings- eller overførselsmeddelelse.

4.2.5.5. En sådan advarsel eller oplysning skal være i en sådam udformning, at den øjeblikkelig tiltrækker den passende arbejdspositions opmærksomhed.

4.2.5.6. Anbefaling

HMIen ved ATS-positioner, der anvender OLDI, bør sørge for en advarsel, hvis OLDI- faciliteten ikke er tilgængelig.

4.2.6. Initiering af meddelelser

4.2.6.1. Hvert system skal indeholde et sæt af systemparametre for at sikre rettidig, automatisk initiering af OLDI-meddelelser.

4.2.6.2. Anbefaling

Evnen til manuelt at initiere transmissionen af en koordineringsmeddelelse forud for den forventede transmissionstid bør være til rådighed.

4.2.6.3. Den automatiske hændelse skal altid være sikret, hvis manuel initiering ikke udføres.

4.2.6.4. Systemet skal anvende tidsparametre til at definere følgende:

- gennemløbstid, forud for transmission, når det operationelle indhold af meddelelserne inden i den overførende enhed vises;

- gennemløbstid, global eller per COP, til at transmittere meddelelsen, når det er anvendeligt;

- tid efter transmission af en meddelelse, inden for hvilken tid en anvendelsesniveuakvittering skal modtages (timeout).

4.2.6.5. En meddelelse skal transmitteres uden forsinkelse, når den påkrævede information bliver tilgængelig til et senere tidspunkt end til det tidspunkt, hvor den ellers ville være blevet transmitteret.

Eksempel:

En flyvning påbegynder et GAT IFR-segment ved et punkt, der ligger nær på den grænse, som den derefter skal krydse; ETOet ved punktet kommunikeres otte minutter før COPet, til hvilket tidspunkt transmission af ACT-meddelelsen allerede er forsinket baseret på den/de anvendelige tidsparameter/tidsparametre; meddelelsen sendes uden forsinkelse.

4.2.7. Modtagelse af meddelelser

4.2.7.1. ATC-systemet skal være i stand til:

- at modtage OLDI-meddelelser;

- at behandle dem automatisk i overensstemmelse med denne standard;

- at udsende flyvedata i overensstemmelse med den modtagede meddelelse og at vise advarsler i tilfælde af inkonsistens i de modtagede data;

- at generere og transmittere kvitteringsmeddelelser automatisk ved anvendelsesniveauet.

4.2.7.2. En kvitteringsmeddelelse (Logisk Kvitteringsmeddelse (LAM), Acceptmeddelelse (ACP) eller Stand-by Meddelelse (SBY)) skal genereres og transmitteres, når den tilsvarende meddelelse er blevet behandlet og præsentationen af resultaterne af behandlingen til de(n) behørige position(er) efter behov er sikret.NOTE

De detaljerede betingelser for genereringen af en kvittering er specificeret individuelt for hver meddelelse.

4.3. Opdatering fra overvågningsdata

Anbefaling

For at sikre nøjagtigheden af tidsestimatdata bør der anvendes information udledt fra sporingen af flyvningen ved radar eller andre overvågningsmidler til at opdatere flyveplansdatabasen.

4.4. Optegnelse af OLDI-data

4.4.1. Indhold

Indholdet af alle OLDI-meddelelser og modtagelsestiden skal optegnes.

4.4.2. Faciliteter

Der skal være faciliteter tilgængeligt til genvindingen og visningen af de optegnede data.

4.5. Tilgængelighed, Pålidelighed, Datasikkerhed og Dataintegritet

4.5.1. Tilgængelighed

4.5.1.1. OLDI-faciliteten skal være tilgængelig i løbet af tiden med trafikale normal- og spidsbelastninger mellem de to pågældende enheder.

4.5.1.2. Anbefaling

OLDI-faciliteten bør være tilgængelig 24 timer hver dag.

4.5.1.3. En hvilken som helst planlagt nedlukket periode (og således den planlagte tilgængelighedstid) skal være aftalt bilateralt mellem de to berørte enheder.

4.5.2. Pålidelighed

4.5.2.1. Pålidelighed af hver OLDI-forbindelse skal være mindst 99.86 % (svarende til en nedlukningstid på ikke mere end 12 timer per år, baseret på 24-timers tilgængelighed).

4.5.2.2. Anbefaling

Hvor det operationelt er retfærdiggjort, bør der sørges for en pålidelighed på mindst 99.99% (svarende til en nedlukningstid på ikke mere end 52 minutter per år, baseret på 24-timers tilgængelighed).

4.5.3. Datasikkerhed

Anbefaling

Der bør ved OLDI-faciliteterne gøres brug af datasikkerhedsmetoder (f.eks. adgangsrettigheder, kildeverificering) og hvor det er anvendeligt netværksmanagement.

4.5.4. Dataintegritet

Fejlraten ved anvendelsesniveau må ikke overstige én transmissionsfejl per 2000 meddelelser.

4.6. Operationel evaluering

4.6.1. Evalueringsperiode

Hver ny OLDI-facilitet, heriblandt en ny facilitet på en eksisterende forbindelse, skal være udsat for en evalueringsperiode til at verificere dataintegriteten, nøjagtigheden, ydeevnen, kompatibiliteten med ATC-procedurer og overordnet sikkerhed forud for dens operationelle implementering.

NOTE

En procedure til at medvirke til evalueringen af en ny OLDI-facilitet er tilgængelig fra OLDI-Sekretariatet, Eurocontrol.

4.6.2. Operationel introduktionsdato

Datoen for den operationelle introduktion, hvilket forudsætter fuldendelse af evalueringsperioden, skal formelt være aftalt mellem de to enheder.

5. MEDDELELSESKATEGORIER

5.1. Generelt

5.1.1. Formål

Dette afsnit i dokumentet:

- definerer kategorierne for meddelelser;

- angiver krav til transaktionstider for kategorierne;

- angiver, hvilke meddelelser, der er obligatoriske, og hvilke, der er ekstra;

- tildeler kategorier til meddelelsestyper.

5.1.2. Meddelelseskategorier

OLDI-meddelelser er blevet tildelt de følgende kategorier:

- Kategori 1: Overførsel af Kommunikation;

- Kategori 2: Koordinering;

- Kategori 3: Underretning.

5.2. Transaktionstider

5.2.1. Transaktionstidsbetingelser

5.2.1.1. De specificerede transaktionstider omfatter transmission, indledende behandling ved den modtagende enhed, dannelse af kvitteringsmeddelelsen, dens transmission og modtagelse ved den overførende enhed. De automatiske kvitteringsmeddelelser LAM og SBY er derfor ikke blevet tildelt en meddelelseskategori.

5.2.1.2. De maksimale transaktionstider for de forskellige kategorier af meddelelser skal være som angivet i Tabel 5-1.

Tabel 5-1

Maksimale transaktionstider

>TABELPOSITION>

5.2.1.3. Der skal være defineret en timeout-værdi per meddelelseskategori eller -type.

5.2.1.4. Hvis der ikke er blevet modtaget nogen kvittering inden for den specificerede tid efter transmission, skal en meddelelse betragtes som værende transmitteret eller behandlet uden held og en advarsel skal udsendes som specificeret i det relevante afsnit i dette dokument.

5.2.1.5. Anbefaling

Timeout-værdierne for de tre kategorier bør ikke overstige 12 sekunder, 30 sekunder og 60 sekunder respektivt.

5.3. Meddelelsesklassifikation og -kategorisering

5.3.1. Meddelelsesklassifikation - Obligatorisk og Ekstra

5.3.1.1. De meddelelser, som er beskrevet i dette dokument, klassificeres som enten obligatoriske eller ekstra.

5.3.1.2. Hvor en meddelelse er beskrevet som obligatorisk (Mandatory) (M) for transmission (TX), skal der være indeholdt behandling for at være i stand til at sende sådanne meddelelser.

5.3.1.3. Hvor en meddelelse er beskrevet som obligatorisk for modtagelse (reception) (REC), skal der være indeholdt behandling for at være i stand til at behandle modtagede meddelelser.NOTE

I exceptionelle tilfælde, hvor trafikreguleringen mellem to enheder er envejs, kan de obligatoriske meddelelser være anvendelige i kun én retning.

5.3.1.4. Hvor en meddelelse er beskrevet som ekstra (complementary) (C) for transmission, skal der være indeholdt behandling for at være i stand til at sende sådanne meddelelser, hvis det kræves af den sendende enhed og hvis det er aftalt bilateralt med den modtagende enhed.NOTE

Ekstra meddelelser kan anvendes i kun én retning, hvis det bestemmes ved operationelle krav.

5.3.1.5. Hvor en meddelelse er beskrevet som ekstra for modtagelse, skal der være indeholdt behandling for at være i stand til at behandle modtagede meddelelser, hvor en sådan brug er blevet aftalt bilateralt.

5.3.1.6. Krav beskrevet i Tabellerne 5-3 og 5-4 gælder kun, hvor anvendelsen af Dialogproceduren for Koordinering og/eller Overførsel af Kommunikation respektivt er blevet aftalt bilateralt mellem ATC-enheder.

5.3.2. Kategorisering af Meddelelser

5.3.2.1. Kategoriseringen af meddelelser for den grundlæggende procedure er specificeret i Tabel 5-2.

5.3.2.2. Kategoriseringen af de yderligere koordineringsmeddelelser for dialogproceduren er specificeret i Tabel 5-3.

5.3.2.3. Kategoriseringen af overførsel af kommunikationsmeddelelser for dialogproceduren er specificeret i Tabel 5-4.

Tabel 5-2

Grundlæggende Proceduremeddelelser

>TABELPOSITION>

Tabel 5-3

Dialogprocedure - Koordineringsfasemeddelelser

(Supplerende til Tabel 5-2)

>TABELPOSITION>

Tabel 5-4

Dialogprocedure - Overførselsfasemeddelelser

>TABELPOSITION>

6. GRUNDLÆGGENDE PROCEDURE - OBLIGATORISKE MEDDELELSER

6.1. Generelt

6.1.1. Beskrivelse af Krav

Dette afsnit beskriver det minimale krav ved anvendelsesniveauet for implementeringen af OLDI-faciliteter.

6.1.2. Implementering

Enheder, som anvender OLDI til koordineringen af flyvninger, skal implementere ABI, ACT og LAM som beskrevet i dette afsnit, bortset fra de tilfælde hvor det er blevet aftalt bilateralt at anvende koordineringsdialogproceduren som beskrevet i dette dokuments Afsnit 8, i hvilket tilfælde betingelserne for anvendelsen af ACT- og LAM-meddelelserne er som defineret i det afsnit.

6.2. Forudgående Grænseinformationsmeddelelse (ABI)

6.2.1. Formål med ABI-Meddelelsen

ABI opfylder de følgende, operationelle krav:

- at sørge for erhvervelse af manglende flyveplansdata;

- at tilvejebringe forudgående grænseinformation og revideringer dertil for den næste ATC-enhed;

- at opdatere de grundlæggende flyveplansdata;

- at lette en tidlig korrelation af radarspor;

- at lette en nøjagtig vurdering af kortsigtet sektorbelastning.

ABI er en underretningsmeddelelse.

6.2.2. Indhold af Meddelelse

ABI-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Luftfartøjsidentifikation;

- SSR Tilstand og -Kode (hvis det er tilgængeligt);

- Afgangsflyveplads;

- Estimatdata;

- Bestemmelsesflyveplads;

- Nummer for og type af Luftfartøj;

- Rute (frivilligt);

- Andre Flyveplansdata (frivilligt).

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

6.2.3. Regler for Anvendelse

6.2.3.1. Generelt

6.2.3.1.1. Bortset fra de tilfælde, som er angivet i 6.2.3.1.3 og 6.2.3.1.4 nedenfor, skal der sendes én eller flere ABI-meddelelser for hver flyvning, som er planlagt til at krydse grænsen mellem ansvarsområder omfattet af OLDI-procedurer.

6.2.3.1.2. Når ABI-meddelelsen sendes, skal den gå forud for Aktiveringsmeddelelsen (ACT) eller Meddelelse om Henvist Aktiveringsforslag (RAP).

6.2.3.1.3. Der skal ikke genereres en ABI-meddelelse, hvis en Foreløbig Aktiveringsmeddelelse (PAC) skal sendes.

6.2.3.1.4. Anbefaling

ABI-transmission bør forhindres, hvis ACT- eller RAP-meddelelsen er forfalden til transmission øjeblikkeligt eller inden for et bilateralt aftalt tidsinterval.NOTE

Formålet med denne anbefaling er at undgå den forsøgte, samtidige afgørelse med hensyn til anormaliteter ved forskellige positioner i den modtagende enhed med hensyn til ABI- og ACT-meddelelser for den samme flyvning.

6.2.3.1.5. Der skal sendes en revideret ABI-meddelelse, hvis den efterfølgende ACT-meddelelse ikke er blevet genereret og:

- flyvningens rute er blevet modificeret således, at COPet i den tidligere ABI-meddelelse ikke længere er nøjagtigt;

- bestemmelsesflyveplanen er blevet ændret;

eller

- typen af luftfartøj er blevet ændret.

6.2.3.1.6. Anbefaling

Der bør sendes en revideret ABI-meddelelse, hvis den efterfølgende ACT-meddelelse ikke er blevet genereret og én af de følgende emner er genstand for forandring:

- Det forventede grænsekrydsningsniveau;

- Den forventede SSR-kode ved overførsel af kontrolpunkt;

- Når det forventede tidspunkt over (ETO) ved COPet er forskelligt fra den tidligere ABI-meddelelse i længere tid end den tid, der er specificeret i Aftalebrevet (LoA);

- Vilkårlige andre data, som er aftalt bilateralt.

6.2.3.2. Behandling i den Modtagende Enhed

6.2.3.2.1. Det ATC-system, som modtager en ABI-meddelelse, skal forsøge at få forbindelse med de tilsvarende flyveplansdata.

6.2.3.2.2. Hvis flyveplansforbindelsen ikke er vellykket, skal en flyveplan dannes automatisk eller manuelt i det modtagende system.

6.2.3.2.3. Hvis flyveplansforbindelsen er vellykket, men der identificeres en uoverensstemmelse mellem dataene i meddelelsen og tilsvarende data i det modtagende system, hvilken uoverensstemmelse ville resultere i et behov for en korrigerende handling ved modtagelsen af den følgende ACT-meddelelse, skal uoverensstemmelsen henvises til en passende position for afgørelse.

6.2.3.3. Tidsparametre for Transmission

6.2.3.3.1. Meddelelsen skal transmitteres et parameterantal af minutter før den forventede tid ved COPet.

6.2.3.3.2. ABI-genereringsparameteren/ABI-genereringsparametrene skal indbefattes i Aftalebrevet LoA mellem de pågældende ATC-enheder.

6.2.3.3.3. Anbefaling

ABI-genereringsparameteren/ABI-genereringsparametrene bør være:

- variable, baseret på bestemmelserne i LoAet ;

- defineret særskilt for hvert af COPerne.

6.2.4. Kvittering for ABI

6.2.4.1. Kvittering

Der skal kvitteres for ABI-meddelelsen ved at generere og transmittere en LAM-meddelelse.

NOTE

Der genereres en LAM-meddelelse uanset resultaterne af forsøget på flyveplansforbindelse.

6.2.4.2. Ingen Kvittering

Anbefaling

Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en ABI-meddelelse, bør der vises en advarsel ved en overvågningsposition.

6.2.5. Eksempler

"Air 2000" 253, en Boeing 757 fra Malta til Birmingham, som forventer BNE VOR til 1221 UTC, som flyver ved FL350 ved en egenfart på 480 knob, som er planlagt til at flyve via UB4 BNE UB4 BPK UB3 HON, som har en transpondervisning på A7012 og som anmoder om FL390. Det følgende er tilsvarende eksempler på ABI-meddelelsen sendt fra Reims til London ACC.

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. Aktiveringsmeddelelse (ACT)

6.3.1. Formål med ACT-Meddelelsen

ACT-meddelelsen opfylder de følgende, operationelle krav:

- At erstatte den verbale grænseberegning ved automatisk at transmittere detaljer for en flyvning fra én ATC-enhed til den næste forud for overførslen af kontrol;

- At opdatere de grundlæggende flyveplansdata i den modtagende ATC-enhed med den seneste information;

- At lette fordeling og visning af flyveplansdata inden i den modtagende ATC-enhed for de involverede arbejdspositioner;

- Hurtigt at udføre visning af kaldesignal/kode-korrelering i den modtagende ATC-enhed;

- At sørge for overførselsbetingelser til den modtagende ATC-enhed.

6.3.2. Indhold af Meddelelse

ACT-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Luftfartøjsidentifikation;

- SSR Tilstand og -Kode (hvis det er tilgængeligt);

- Afgangsflyveplads;

- Estimatdata;

- Bestemmelsesflyveplads;

- Nummer for og type af luftfartøj;

- Rute (frivilligt);

- Andre flyveplansdata (frivilligt).

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

6.3.3. Regler for Anvendelse

6.3.3.1. Generelt

6.3.3.1.1. Der skal sendes én ACT-meddelelse for flyvninger, der antages at krydse grænsen, bortset fra de tilfælde, der er angivet i afsnit 6.3.3.1.10.

6.3.3.1.2. ACT-meddelelsen skal genereres og transmitteres automatisk til det forventede tidspunkt som specificeret i LoAet, med mindre den initieres til et tidligere tidspunkt.

6.3.3.1.3. Anbefaling

ATC-mandskab skal være forsynet med et middel til at igangsætte transmissionen af ACT-meddelelser forud for den forventede transmissionstid.

6.3.3.1.4. Det operationelle indhold af den ACT-meddelelse, der skal til at blive transmitteret, skal vises ved den arbejdsposition, som er ansvarlig for koordineringen af flyvningen forud for den aktuelle transmission.

6.3.3.1.5. Anbefaling

I forbindelse med 6.3.3.1.4 bør det tidspunkt, til hvilket det er forventes, at ACTen skal transmitteres automatisk, vises sammen med dens indhold.

6.3.3.1.6. ACT-meddelelsen skal indeholde den seneste information om flyvningen, hvilket udtrykker de forventede udgangsbetingelser.

6.3.3.1.7. Den relevante arbejdsposition skal underrettes om transmission af ACT-meddelelsen.

6.3.3.1.8. Så snart der er modtaget en LAM, bliver ACT-meddelelsesdataene operationelt bindende for begge ATC-enhederne. De koordinerede overførselsbetingelser og det faktum, at LAMen er blevet modtaget, skal forelægges for ATC-mandskabet ved den overførende enhed.

6.3.3.1.9. Der regnes med accept ved den modtagende enhed af de overførselsbetingelser, der rummes i ACT-meddelelsen, med mindre den modtagende enhed initierer koordinering for at rette i dem.

6.3.3.1.10. Der kan kun sendes en yderligere ACT-meddelelse til den samme koordineringspartner, hvis den tidligere meddelelse er blevet ophævet ved anvendelsen af en MAC.

6.3.3.1.11. Rute og Andre flyveplansdata skal være indeholdt, hvis det er aftalt bilateralt.

6.3.3.2. Behandling i den Modtagende Enhed

6.3.3.2.1. Det ATC-system, som modtager en ACT-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.

6.3.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:

- skal det operationelle indhold være indbefattet i flyveplanen;

- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt;

- skal der returneres en LAM.

6.3.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen:

- hvis den sektor, der er ansvarlig for at acceptere kontrol over flyvningen kan identificeres:

- skal det operationelle indhold af meddelelsen vises ved sektoren;

- skal en LAM returneres;

- skal en flyveplan dannes;

- i alle andre tilfælde skal en LAM ikke returneres.

6.3.3.3. Parametre for Transmission

6.3.3.3.1. Meddelelsen skal transmitteres til eller så snart som muligt efter det tidligste af de tidspunkter, der bestemmes ud fra det følgende:

- et parameterantal af minutter før den forventede tid ved COPet;

- det tidspunkt, til hvilket flyvningen er i en bilateralt aftalt afstand fra COPet.

6.3.3.3.2. ACT-genereringsparameteren/ACT-genereringsparametrene skal være indbefattet i LoAet mellem de pågældende ATC-enheder.

6.3.3.3.3. ACT-genereringsparameteren/ACT-genereringsparametrene skal være variable, baseret på bestemmelserne i LoAet.

6.3.3.3.4. Anbefaling

ACT-genereringsparametre bør være defineret særskilt for hvert af COPerne.

6.3.3.3.5. De specificerede parametre skal give tilstrækkelig tid til:

- at den transmitterende enhed kan opdatere overførselsflyveniveauet for at udtrykke de forventede betingelser ved COPet;

og

- at den modtagende enhed kan behandle ACTen og generere og transmittere en LAM, men stadig give mulighed for, at der kan udføres verbal koordinering ved hjælp af den overførende enhed og at resulterende handling kan initieres ved hjælp af den accepterende enhed, hvis udvekslingen af data svigter.

6.3.4. Kvittering for ACT

6.3.4.1. Kvittering

Der skal kvitteres for ACT-meddelelsen ved genereringen og transmissionen af en LAM-meddelelse.

6.3.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en ACT-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for flyvningens koordinering.

6.3.5. Eksempler

De følgende eksempler er en udvidelse af de, der er givet for ABI-meddelelsen i afsnit 6.2; alle detaljer er de samme bortset fra det ETO ved COPet, hvilket tidspunkt er 1226 i den viste ACT-meddelelse.

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. Logisk Kvitteringsmeddelelse (LAM)

6.4.1. Formål med LAM-Meddelelsen

LAMen er det middel med hvilket modtagelsen og beskyttelsen af en transmitteret meddelelse angives til den sendende enhed af den modtagende enhed.

LAM-behandlingen forsyner ATC-mandskabet ved den overførende enhed med følgende:

- en advarsel, når der ikke er blevet modtaget en kvittering;

- en angivelse af, at den meddelelse, der kvitteres for, er blevet modtaget, vellykket behandlet, fundet som værende fri for fejl, lagret og hvor det er relevant er tilgængelig for præsentation til de(n) passende arbejdsposition(er)

6.4.2. Indhold af Meddelelse

LAM-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer

- Meddelelseshenvisning.

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

6.4.3. Regler for Anvendelse

6.4.3.1. Generelt

6.4.3.1.1. Reglerne for returneringen af en LAM er specificerede i de afsnit af dette dokument, som definerer behandlingen af hver meddelelse.

6.4.3.1.2. LAM-meddelelsen skal genereres og transmitteres uden menneskelig intervention.

6.4.3.1.3. LAM-meddelelsen skal ikke anvendes til at undgå behovet for tekniske meddelelser til at sikre integriteten af datatransmissioner.

6.4.3.1.4. LAM-meddelelsen skal genereres og transmitteres øjeblikkeligt, således at kravet til transaktionstid for den meddelelse, som der kvitteres for, kan opfyldes.

6.4.3.1.5. Med undtagelse af ABI-meddelelser skal det transmitterende ATC-system underrette den flyveleder, som er ansvarlig for koordineringen, hvis der ikke er blevet modtaget en LAM-meddelelse inden for den tidsparameter, der er fastsat for sådanne advarsler.

6.4.4. Kvittering for LAM

LAM-meddelelsen skal ikke kræve nogen kvittering.

6.4.5. Eksempler

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. GRUNDLÆGGENDE PROCEDURE - EKSTRA MEDDELELSER

7.1. Generelt

7.1.1. Beskrivelse af Krav

Dette Afsnit beskriver faciliteter, der er anvendelige med den grundlæggende procedure, hvilke faciliteter er supplerende til de, som er beskrevet i Afsnit 6 Grundlæggende Procedure - Obligatoriske Meddelelser.

7.1.2. Implementering

7.1.2.1. Anvendelsen af en hvilken som helst af de i dette Afsnit beskrevne faciliteter skal være aftalt bilateralt, før de indføres.

7.1.2.2. Når en sådan anvendelse er aftalt, skal de regler, som er beskrevet i dette afsnit, gælde.

7.2. Foreløbig Aktiveringsmeddelelse (PAC)

7.2.1. Formål med PAC-Meddelelsen

PAC-Meddelelsen opfylder de følgende, operationelle krav:

- underretning og koordinering før afgang for en flyvning, hvor flyvetiden fra afgang til COPet er mindre end den tid, der ville være påkrævet til at overholde de aftalte tidsparametre for transmission af ACT-meddelelser;

- underretning og koordinering før afgang for en flyvning før afgang ved en lokal (flyveplads/indflyvningskontrol) enhed til den næste enhed, der vil tage kontrol over flyvningen;

- at sørge for erhvervelse af manglende flyveplansdata i tilfældet af uoverensstemmelser i den indledende fordeling af flyveplansdata;

- at anmode om tildelingen af en SSR-kode fra den enhed, som underretningen/koordineringen ovenfor sendes til, hvis det er påkrævet.

7.2.2. Indhold af Meddelelse

PAC-Meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Meddelelseshenvisning (frivilligt);

- Luftfartøjsidentifikation;

- SSR Tilstand og -Kode;

- Afgangsflyveplads;

- Forventet Starttid eller Estimatdata;

- Bestemmelsesflyveplads;

- Type af Luftfartøj;

- Rute (frivilligt);

- Andre flyveplansdata (frivilligt).

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

7.2.3. Regler for Anvendelse

7.2.3.1. Generelt

7.2.3.1.1. Der skal sendes én eller flere PAC-meddelelser for hver flyvning, der er planlagt til at krydse grænsen mellem ansvarlighedsområder, hvor tiden fra afgang til COPet ikke ville tillade, at ACT-meddelelsen kan sendes til det påkrævede tidspunkt.

7.2.3.1.2. Der skal sendes én eller flere PAC-meddelelser af Flyveplads-/Indflyvningsenheden til den næste enhed for hver afgående flyvning, for hvilken der enten er påkrævet underretning eller koordinering.

7.2.3.1.3. Anbefaling

For implementeringen af PAC/LAM mellem enheder bør de relevante TWR/APP-systemer være forsynet med et middel til at indføre og videresende "opstart" ("start-up"), "push-back", "kørsel" (taxi) eller tilsvarende information ud fra hvilken ETOTet kan udledes til at beregne ETOet ved COPet og initiere transmissionen af PACen.

7.2.3.1.4. Alt efter hvad, der er aftalt bilateralt, skal meddelelsen indeholde enten:

- Forventet Starttid;

eller

- Estimatdata.

7.2.3.1.5. Når meddelelseshenvisningen er indeholdt i overensstemmelse med bilateral aftale skal den:

- indeholde meddelelsesnummeret for det første PAC-meddelelse sendt for flyvningen;

- være indholdt i den anden og efterfølgende PAC-meddelelser.

7.2.3.1.6. Anvendelsen af kodeanmodningsfaciliteten skal, hvis den er påkrævet, være aftalt bilateralt.

7.2.3.1.7. Der skal sendes en revideret PAC-meddelelse, hvis en hvilken som helst af de følgende betingelser er opfyldt inden afgang:

- flyvningens rute er blevet modificeret således, at COPet i den tidligere meddelelse ikke længere er nøjagtigt;

- typen af luftfartøj er blevet ændret;

- destinationsflyvepladsen i den tidligere PAC har vist sig at være ukorrekt.

7.2.3.1.8. Anbefaling

Der bør sendes en revideret PAC-meddelelse, hvis de følgende data er forskellige fra dataene i den tidligere PAC-meddelelse inden afgang:

- niveauet (i estimatdataene, hvis de er til stede);

- den forventede SSR-kode ved overførslen af kontrolpunkt;

- den Forventede Starttid eller ETO ved COPet til et tidspunkt ud over en værdi, som er aftalt bilateralt;

- der er en ændring i vilkårlige andre data, ifølge bilateral aftale.

7.2.3.2. Behandling i den Modtagende Enhed

7.2.3.2.1. Det ATC-system, som modtager en PAC-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.

7.2.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:

- skal det operationelle indhold være indbefattet i flyveplanen;

- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt;

- skal der returneres en LAM.

7.2.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen:

- hvis den sektor, der er ansvarlig for at acceptere kontrol over flyvningen kan identificeres:

- skal det operationelle indhold af meddelelsen vises ved sektoren;

- skal en LAM returneres;

- skal en flyveplan dannes;

- i alle andre tilfælde skal en LAM ikke returneres.

7.2.3.2.4. Dataene i en anden eller en efterfølgende PAC-meddelelse skal erstatte dataene i den tidligere meddelelse.

7.2.3.2.5. Hvis PAC-meddelelsen indeholder en anmodning om tildelingen af en SSR-kode og kan behandles korrekt som beskrevet i Afsnit 7.2.3.2.2 ovenfor, skal der returneres en COD-meddelelse ud over LAMen.NOTE

Idet kodetildelingsprocessen kræver detaljeret flyveplansruteinformation, stilles der i dette dokument ikke noget krav om returneringen af en COD-meddelelse ved den modtagende enhed, hvor sådanne data måske ikke er tilgængelige for flyvningen. Dette forhindrer ikke, at en meddelelse kan returneres under sådanne omstændigheder, hvis der eksisterer en specifik, lokal egenskab og proceduren er aftalt bilateralt.

7.2.3.3. Tidsparametre for Transmission

En transmissionstidsparameter er ikke anvendelig, idet meddelelsen sendes som et resultat af en manuelt indført meddelelse, som identificerer flyvningens forestående afgang.

7.2.4. Kvittering for PAC

7.2.4.1. Kvittering

De meddelelser, der skal sendes som reaktion på en PAC-meddelelse, er beskrevet i Afsnit 7.2.3.2 ovenfor.

7.2.4.2. Ingen Kvittering

Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en PAC-meddelelse, skal der vises en advarsel ved den position i ATC-enheden, som er ansvarlig for koordineringen med den næste enhed.

7.2.4.3. Tilfælde af Ingen LAM

I tilfælde af ingen LAM skal verbal koordinering initieres.

7.2.4.4. Ingen COD-Meddelelse

7.2.4.4.1. Hvis der ikke modtages en COD-meddelelse som reaktion på en kodeanmodning, som er indbefattet i PAC-meddelelsen, skal en advarsel vises ved en passende position.

7.2.4.4.2. Hvor kodeanmodningsfunktionen skal bruges, skal den timeout-værdi, der skal anvendes, være aftalt bilateralt.

7.2.5. Eksempler

7.2.5.1. Estimeret Starttid og Kodeanmodning

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. Tid ved 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. Revideringsmeddelelse (REV)

7.3.1. Formål med REV-Meddelelsen

REV-meddelelsen bruges til at transmittere revideringer til koordineringsdata, som tidligere er sendt i en ACT-meddelelse, under forudsætning af at den accepterende enhed ikke ændres som et resultat af modifikationen.

7.3.2. Indhold af Meddelelse

REV-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Meddelelseshenvisning (frivilligt);

- Luftfartøjsidentifikation;

- SSR Tilstand og -Kode (frivilligt);

- Afgangsflyveplads;

- Estimatdata;

- Koordineringspunkt (frivilligt);

- Bestemmelsesflyveplads;

- Rute (frivilligt);

- Andre Flyveplansdata (frivilligt).

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

7.3.3. Regler for Anvendelse

7.3.3.1. Generelt

7.3.3.1.1. Der kan sendes én eller flere REV-meddelelsen til den enhed, som en flyvning for øjeblikket er blevet koordineret til ved brugen af en Aktiveringsmeddelelse.

7.3.3.1.2. De følgende elementer skal være omfattet af revideringer:

- ETO ved COPet;

- Overførselsniveau(er);

- SSR-Kode.

7.3.3.1.3. Der skal sendes en REV-meddelelse, når:

- ETOet ved COPet afviger fra det, der fremgår af den tidligere meddelelse, med mere end en bilateralt aftalt værdi, rundet af til den nærmeste heltalsværdi;

- Der er en hvilken som helst forandring med hensyn til overførselsniveauet/overførselsniveauerne eller SSR-koden.

7.3.3.1.4. Hvor det bilateralt er aftalt, skal der sendes en REV-meddelelse, hvis der en hvilken som helst forandring i de følgende:

- COP;

- rute;

- andre flyveplansdata (data i ICAO felt 8, 10 og 18).

NOTE

Operationelle regler kan kræve, at modifikationer, som udføres efter ACT, kan være på betingelse af forudgående koordinering mellem de berørte enheder.

7.3.3.1.5. Når det er aftalt bilateralt, skal meddelelseshenvisningen indbefattes i REV-meddelelsen.

7.3.3.1.6. Meddelelseshenvisningen skal, når den er indbefattet, indeholde den tidligere ACT-meddelelses meddelelsesnummer.

7.3.3.1.7. Den modtagende ATC-enheds accept af de overførselsbetingelser, der medføres af REV-meddelelsen, skal formodes, medmindre den modtagende ATC-enhed initierer koordinering for at rette i dem.

7.3.3.2. Formatering af Revideringsmeddelelser

7.3.3.2.1. ICAO-Format

Alle revideringsmeddelelser omfatter felttyper 3, 7, 13, 14 og 16. De følgende typer af revidering indbefattes i disse felter:

- en ændring af ETOet ved COPet eller overførselsniveauet/overførselsniveauerne skal indarbejdes i indbefatningen af de reviderede data i felt 14;

- en ændring af SSR-Koden skal være indbefattet i felt 7;

- ruteændringer, som omfatter ændringer af COPet, skal være indarbejdet i data i felterne 14 og 15 indbefattet i felt 22's format efter de første fem indledende felter. Sådanne meddelelser skal indeholde to felter 14, hvor det første indeholder et element a) kun det COP, som flyvningen tidligere er blevet koordineret igennem. Regler for koordineringen af sådanne ændringer, heri indbefattet direkte styringer, er specificeret i Anneks B Specielle Rutebehandlingskrav;

- modifikationer af felterne 8, 10 og 18 skal være indarbejdet som data i felt 22 efter de fem indledende felter.

7.3.3.2.2. ADEXP-Format

Alle revideringsmeddelelser i ADEXP-format skal indbefatte de følgende primære felter: TITLE REFDATA ARCID ADEP ADES. De følgende regler gælder:

- en ændring af ETOet ved COPet eller overførselsniveauet/overførselsniveauerne skal indarbejdes i indbefatningen af de reviderede data i det primære felt COORDATA;

- ruteændringer, heriblandt ændringer af COPet, skal være indarbejdet i de primære felter COORDATA og ROUTE. Sådanne meddelelser skal omfatte det primære felt COP, der indeholder det Koordineringspunkt, som flyvningen tidligere er blevet koordineret igennem. Regler for koordineringen af sådanne ændringer, heri indbefattet direkte styringer, er specificeret i Anneks B;

- en ændring af SSR-Koden skal være angivet ved indbefatningen af det primære felt SSRCODE;

- modifikationer til andre flyveplansdata skal være indarbejdet af indbefatningen af de(t) fornødne primære felt(er) som defineret for Andre Flyveplansdata i Anneks A.

Hvis der sendes en revideringsmeddelelse til kun at koordinere SSR-Kode og/eller Andre Flyveplansdata, skal det primære felt COP være indbefattet i stedet for COORDATA.

7.3.3.2.3. SSR-Kode

SSR-Tilstand og -Kode skal kun være indbefattet i en REV-meddelelse, når det er påkrævet at koordinere en ændring af SSR-kode.

7.3.3.3. Behandling i den Modtagende Enhed

7.3.3.3.1. Hvis der modtages en ACT for den pågældende flyvning fra den samme ATC-enhed, skal det ATC-system, som modtager en PAC-meddelelse, forsøge at opnå forbindelse med den tilsvarende flyveplan.

7.3.3.3.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:

- skal det operationelle indhold være indbefattet af flyveplanen;

- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt.

7.3.3.4. Initiering af Transmission

7.3.3.4.1. REV-meddelelsen er hændelsesdrevet og skal transmitteres øjeblikkeligt efter den relevante indføring eller opdatering.

7.3.3.4.2. Der kan ikke udføres nogen ændringer ved brugen af REV-meddelelsen, efter at flyvningen er ved et specificeret tidspunkt/en specificeret afstand fra overførselspunktet. Tids- og afstandsparametrene skal være aftalt bilateralt.

7.3.3.4.3. Anbefaling

REV-parametrene bør være defineret særskilt for hvert af COPene.

7.3.3.5. Ændring af Modtagende ATC-Enhed

REV-meddelelsen skal ikke bruges, hvis en revidering af flyveplansdata fører til en ændring af den modtagende ATC-Enhed (se Meddelelse for Ophævelsen af Koordinering).

7.3.4. Kvittering for REV

7.3.4.1. Kvittering

Hvis REV-meddelelsen:

- kan forbindes med en flyveplan i det modtagende system, skal der transmitteres en LAM-meddelelse som kvittering;

- ikke kan forbindes med en flyveplan i det modtagende system, skal der ikke transmitteres en LAM-meddelelse.

7.3.4.2. Ingen Kvittering

7.3.4.2.1. Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en REV-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen af flyvninger.

7.3.4.2.2. I tilfælde af ingen LAM skal en verbal koordinering initieres af den overførende ATC-enhed.

7.3.5. Eksempler

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. Meddelelse for Ophævelsen af Koordinering (MAC)

7.4.1. Formål med MAC-Meddelelsen

En MAC-meddelelse bruges til at angive over for den modtagende enhed, at den koordinering eller underretning, som tidligere blev udført for en flyvning, er blevet ophævet.

MACen er ikke en erstatning for en Annuleringsmeddelelse (CNL), som denne er defineret af ICAO, og skal derfor ikke bruges til at slette de grundlæggende flyveplansdata.

7.4.2. Indhold af Meddelelse

MAC-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Meddelelseshenvisning (frivilligt);

- Luftfartøjsidentifikation;

- Afgangsflyveplads;

- Koordineringspunkt;

- Bestemmelsesflyveplads;

- Koordineringsstatus og -Årsag (frivilligt);

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

7.4.3. Regler for Anvendelse

7.4.3.1. Generelt

7.4.3.1.1. Der skal sendes en MAC-meddelelse til en enhed, som koordinering tidligere er blevet udført til for en flyvning, ved brugen af en ACT- eller RAP-meddelelse, når ét af følgende forekommer:

- det forventede niveau ved overførselspunktet er forskelligt fra det niveau, der er indeholdt i den tidligere meddelelse, hvilket resulterer i en ændring af den næste enhed i koordineringssekvensen;

- flyvningens rute er blevet forandret, hvilket resulterer i ændring af den næste enhed i koordineringssekvensen;

- systemflyveplanen er annulleret i den sendende enhed og koordinering er ikke længere relevant;

- der modtages en MAC fra den tidligere enhed i forhold til flyvningen.

7.4.3.1.2. Når der sendes en MAC-meddelelse på grund af en ændring i flyveniveau eller flyverute, skal underretning og/eller koordinering, alt efter hvad der er behørigt, udføres med den nye enhed i koordineringssekvensen.

7.4.3.1.3. Der skal sendes en MAC-meddelelse, når koordineringen for en afgående flyvning, udført ved brugen af en PAC-meddelelse, ophæves.

7.4.3.1.4. Anbefaling

Der bør sendes en MAC-meddelelse, når den underretning (ABI-meddelelse), som tidligere blev udført for en flyvning, annulleres på grund af en hvilken som helst af de grunde, der er specificeret i Afsnit 7.4.3.1.1 ovenfor eller hvis flyvningen forsinkes en-route og der ikke kan bestemmes et revideret estimat automatisk.

7.4.3.1.5. En meddelelseshenvisning skal være indbefattet, hvis det er aftalt bilateralt.

7.4.3.1.6. Hvis den er indbefattet, skal meddelelseshenvisningen indeholde meddelelsesnummeret for den sidste ABI-, PAC- eller ACT-meddelelse , som er transmitteret til flyvningen og som der er kvitteret for.

7.4.3.1.7. Koordineringspunktet skal være det COP, som flyvningen tidligere er blevet underrettet eller koordineret gennem.

7.4.3.1.8. Anbefaling

MAC-meddelelsen bør identificere den status, som koordineringen eller underretningen skal vende tilbage til, og årsagen til ophævelsen.

7.4.3.1.9. Hvis det er indbefattet, skal statusen og årsagen være én af de følgende kombinationer:

- når den modtagende enhed ikke længere er den næste koordineringspartner:

- er statusen INI (indledende);

- er årsagen én af de følgende:

- TFL, hvis årsagen er en ændring af overførselsniveau;

- RTE, hvis årsagen er en ændring af rute;

- CSN, hvis årsagen er en ændring af kaldesignalet;

- CAN, hvis årsagen er en annullering;

- OTH for en hvilken som helst anden årsag eller hvis årsagen er ukendt;

- når én af de følgende betingelser gælder:

- koordineringen udført ved anvendelse af den tidligere PAC- eller ACT-meddelelse (som modificeret ved en hvilken som helst efterfølgende REV-meddelelse) ophæves, men flyvningen forventes at blive omfattet af en ny koordineringssekvens med den samme enhed;

eller

- flyvningen efterfølgende transmissionen af en ABI-meddelelse er i holding i en ubestemt periode og forventes at blive omfattet af en revideret ABI eller ACT, alt efter hvad der er behørigt:

- er statusen NTF (underretning);

- er årsagen én af de følgende:

- DLY, hvis årsagen er en forsinkelse;

- HLD, hvis årsagen er en holding;

- OTH for en hvilken som helst anden årsag eller hvis årsagen er ukendt.

7.4.3.1.10. Hvis flyvningen skal gen-underrettes eller gen-koordineres:

- skal en ny underretnings- og/eller koordineringsmeddelelse sendes, alt efter hvad der er behørigt;

- skal de grundlæggende flyveplandata, der er lagret i den modtagende ATC-enhed, ikke påvirkes af en MAC-meddelelse;

- skal systemet bevare evnen til korrekt at behandle en ny underretnings- og/eller koordineringsmeddelelse fra enten den tidligere overførende enhed eller en anden enhed i en ny koordineringssekvens.

7.4.3.2. Behandling i den Modtagende Enhed

De(n) arbejdsposition(er) i den modtagende ATC-enhed, som er forsynet med flyvedetaljer, skal underrettes om ophævelsen.

7.4.4. Kvittering for MAC

7.4.4.1. Kvittering

7.4.4.1.1. Hvis MAC-meddelelsen kan forbindes med en flyveplan i det modtagende system og kan behandles, skal en LAM-meddelelse transmitteres som kvittering.

7.4.4.1.2. Hvis MAC-meddelelsen ikke kan forbindes med en flyveplan i det modtagende system eller hvis den ikke kan behandles, skal der ikke transmitteres en LAM-meddelelse.

7.4.4.2. Ingen Kvittering

7.4.4.2.1. Hvis ATC-koordinering ophæves og der ikke er modtaget nogen LAM-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen.

7.4.4.2.2. I sådanne tilfælde skal en verbal ophævelse af koordinering udføres af den overførende ATC-enhed.

7.4.5. Eksempler

En ABI-meddelelse blev sendt af Amsterdam ACC til Bruxelles ACC for flyvning HOZ3188, planlagt til FL190; flyvningen anmoder efterfølgende om at stige til FL270 og klarerers til dette og går således ind i Maastrichts luftrum i stedet for Bruxelles'. Eksempler 7.4.5.1 a og 7.4.5.2 a viser, hvordan MACen, der sendes til Bruxelles af Amsterdam, ville forekomme, både i ICAO- og i ADEXP-format.

En ABI- og senere en ACT-meddelelse sendes til Maastricht, men enkelte minutter før luftfartøjet når COPet, returnerer det til Amsterdams Lufthavn og flyveplanen annulleres i den sendende enheds system; der sendes MAC til Maastricht som vist i eksempler (7.4.5.1 b og 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. SSR Kodetildelingsmeddelelse (COD)

7.5.1. Formål med COD-Meddelelsen

7.5.1.1. Metoden til Kodetildeling for Oprindeligt Område (ORCAM) er frembragt til at tillade en flyvning at respondere på den samme kode til efterfølgende enheder inden for et deltagende område. Medmindre kodetildeling udføres centralt, f.eks. af en ACC, kan lufthavne have behov for at have et sæt diskrete SSR-koder tildelt individuelt. Sådanne tildelinger er meget uøkonomiske med koder.

7.5.1.2. COD-meddelelsen opfylder de operationelle krav til udstedelsen af en SSR-Kode, Tilstand A, af én Lufttrafiktjenesteenhed til en anden for en specificeret flyvning, når der anmodes derom. En valgfri facilitet tillader den udstedende enhed at indbefatte flyvningen rute, hvis det er aftalt bilateralt.

7.5.2. Indhold af Meddelelse

COD -meddelelsen skal indeholde de følgende dataemner:

- Meddelelsestype;

- Meddelelsesnummer;

- Meddelelseshenvisning (frivilligt);

- Luftfartøjsidentifikation;

- SSR-Tilstand og -Kode;

- Afgangsflyveplads;

- Bestemmelsesflyveplads;

- Rute (frivilligt);

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

7.5.3. Regler for Anvendelse

7.5.3.1. Generelt

7.5.3.1.1. Der skal automatisk genereres og transmitteres en COD-meddelelse som reaktion på en kodetildelingsanmodning, der er modtaget i en meddelelse.

7.5.3.1.2. SSR-koden skal være den kode, der tildeles til flyvningen.

7.5.3.1.3. Den anerkendte mætningskode, som angivet i Luftnavigeringsplanen for den Europæiske Region, skal indsættes, hvis en diskret kode ikke er tilgængelig.

7.5.3.1.4. Hvis det er aftalt bilateralt, skal meddelelseshenvisningen, som indeholder meddelelsesnummeret for den meddelelse, som COD-meddelelsen reagerer på, indbefattes.

7.5.3.1.5. Ruten skal indbefattes, hvis det er aftalt bilateralt.

7.5.3.1.6. Der skal formodes accept af SSR-kode af den enhed, der modtager COD-meddelelsen.

7.5.3.2. Behandling i den Modtagende Enhed

7.5.3.2.1. Forudsat, at der ikke er nogen uoverensstemmelse i meddelelsen, som ville forhindre korrekt behandling, skal en LAM returneres.

7.5.3.2.2. Hvis meddelelsen ikke kan forbindes med en flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen, skal der ikke returneres nogen LAM.

7.5.3.2.3. Rutedata skal, hvis de er indbefattet, ikke være årsag til at forhindre returneringen af en LAM, medmindre de fejler med hensyn til at overholde formatkravet som fremsat i Anneks A.

7.5.3.3. Tidsparametre for Transmission

En transmissionstidsparameter skal ikke være anvendelig, idet COD-meddelelsen sendes som et resultat af modtagelsen af en meddelelse, der anmoder om tildelingen af en SSR-kode.

7.5.4. Kvittering for COD

7.5.4.1. Kvittering

Der skal kvitteres for COD-meddelelsen ved at generere og transmittere en LAM-meddelelse.

7.5.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en COD-meddelelse, skal en advarsel vises ved en passende position.

7.5.5. Eksempler

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. Informationsmeddelelse (INF)

7.6.1. Formål med INF-Meddelelsen

7.6.1.1. INF-meddelelsen bruges til at frembringe information med hensyn til specifikke flyvninger til agenturer, som ikke er direkte involverede i koordineringsprocessen mellem to på hinanden følgende ATC-enheder på en flyvnings rute.

7.6.1.2. INF-meddelelsen kan bruges til at frembringe kopier af meddelelser og til at kommunikere aftalte koordineringsbetingelser til sådanne agenturer efter en dialog mellem flyveledere. Til dette formål kan INF-meddelelser genereres af systemerne i den overførende eller den accepterende enhed.

7.6.1.3. Meddelelsen kan også bruges til at frembringe information i forhold til et hvilket som helst punkt på en flyvnings rute til et agentur.

7.6.1.4. Formatet muliggør kommunikationen af indledende data, revideringer og annulleringer.

7.6.2. Indhold af Meddelelse

INF-meddelelsen skal indeholde de følgende dataemner i formatet for en meddelelse beskrevet i dette dokument:

- Meddelelsestype;

- Meddelelsesnummer;

- Alle emner af operationelle data som indbefattet i den originale meddelelse eller resulterende koordinering, der kopieres;

- Henvisningsmeddelelsestype (frivilligt);

NOTE

Dataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.

7.6.3. Regler for Anvendelse

7.6.3.1. Meddelelsestyper

Typen/typerne af meddelelse(r), der skal duplikeres ved en INF-meddelelse, vil være baseret på brugeres krav og egenskaberne for den sendende enhed. Typen/typerne af meddelelse(r) og reglerne for anvendelse vil almindeligvis være aftalt bilateralt.

7.6.3.2. Meddelelsesadressater

Der kan transmitteres én eller flere INF-meddelelser for den samme flyvning til én eller flere adressater.

7.6.3.3. Operationelt Indhold

Det operationelle indhold i INF-meddelelsen skal være i formatet for én af de eksisterende meddelelser.

7.6.3.4. Anbefalinger

1. Betingelser, der er videresendt i en indledende dialogmeddelelse (f.eks. ACT-, RAP-, REV-, RRV-meddelelse) kan ændres eller afvises, før dialogen er færdiggjort. Sendende enheder bør være i stand til at videresende de endelige aftalte koordineringsbetingelser.

2. INF-meddelelsen bør sendes øjeblikkeligt eller til et tidspunkt i forhold til tidspunktet ved COPet, som er aftalt bilateralt med det modtagende agentur.

7.6.4. Kvittering for INF

Anbefalinger

1. Der kan kvitteres for INF-meddelelsen afhængigt af koordineringspartneren ved at generere og transmittere en LAM-meddelelse.

2. fhængigt af en bilateral aftale bør der mellem vedrørte enheder vises en advarsel ved en passende position, hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en INF-meddelelse.

7.6.5. Eksempler

En flyvning med kaldesignal BAW011, B747 fra EGLL til OMDB ved FL290, anmoder om FL410, forventer Koksy (KOK) VOR kl. 1905, har transpondervisning på A5437, fortsætter via UG1 og UB6.

Der sendes en ACT-meddelelse af London til Maastricht for flyvningen. En kopi sendes fra London til en enhed, der identificeres som IT.

Det følgende giver eksempler på INF-meddelelsen.

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

8.1. Generelt

8.1.1. Introduktion

8.1.1.1. Dialogproceduren frembringer faciliteter til kommunikation og forhandling mellem flyveledere i koordineringsfasen og til kommunikation i overførselsfasen.

8.1.1.2. Dette afsnit beskriver meddelelser, der anvendes i dialogproceduren i koordineringsfasen, hvor betingelserne for overførsel planlægges. De, der gælder for overførselsfasen, hvor flyvningens overdragelse gennemføres, er beskrevet i Afsnit 9 - Dialogprocedure - Overførsel af Kommunikation.

8.1.1.3. Procedurer for de to faser er ikke afhængige af hinanden; de kan implementeres enkeltvis eller sammen.

8.1.1.4. Et antal yderligere meddelelser indføres og begge partneres evne til at initiere en dialog understøttes.

8.1.1.5. Koordineringsdialogproceduren tillader identifikation af:

- overførsler, som er i overensstemmelse med LoAet og som kan accepteres automatisk; og

- de, som kræver at blive henvist til flyvelederen ved den modtagende enhed for en beslutning vedrørende accept.

8.1.1.6. Denne procedure tillader også, at der kan føres opsyn med fortolkningen af LoAene i de to systemer og at en hvilken som helst uoverensstemmelse mellem dem kan identificeres.

8.1.2. Filteret

8.1.2.1. Generelt

8.1.2.1.1. Koordineringsdialogproceduren kræver, at systemer identificerer, hvorvidt overførsler er i overensstemmelse med LoAet eller ej.

8.1.2.1.2. Den proces, som kontrollerer en sådan overensstemmelse, betegnes i dette dokument "filteret". Den database, som bruges til filteret, vil, hvis det er påkrævet, indbefatte de følgende:

- aftalte koordineringspunkter;

- berettigede (eller uberettigede) flyveniveauer, hvilket også kan være forbundet med koordineringspunkterne;

- afgangsflyvepladser;

- destinationer;

- aftalte, direkte ruter;

- tids- og/eller distancegrænser forud for COPet, efter hvilke en hvilken som helst koordineringsmeddelelse betragtes som ikke-standard;

- vilkårlige andre betingelser, som er aftalt bilateralt.

8.1.2.1.3. Alle emner i denne liste kan kombineres til at definere mere komplekse betingelser.

8.1.2.1.4. I dette dokuments Afsnit 8 skal udtrykket "standardbetingelser" fortolkes som "i overensstemmelse med LoAet" og udtrykket "ikke-standardbetingelser" som "ikke i overensstemmelse med LoAet". Medmindre det er aftalt bilateralt, skal meddelelser, der sendes af overførende enheder for koordineringer, som er kendt som værende standard, anvende andre meddelelsestyper end de, for hvilke betingelserne er ikke-standard.

8.1.2.2. Handling I den Overførende Enhed

8.1.2.2.1. Filteret i den overførende enhed skal gennemgå de overførselsbetingelser, som skal til at blive sendt til den accepterende enhed.

8.1.2.2.2. Anbefaling

Hvis overførselsbetingelserne viser sig at være ikke-standard, skal den overførende flyveleders opmærksomhed henledes til dette faktum for bekræftelse eller modifikation.

8.1.2.3. Handling i den Accepterende Enhed

8.1.2.3.1. Alle ACT- og REV-meddelelser skal kontrolleres i forhold til filteret.

8.1.2.3.2. Hvis kontrollen angiver, at de modtagede overførselsbetingelser er ikke-standard, skal de henvises til flyvelederen for en beslutning, i modsat fald vil de blive accepteret automatisk.

8.1.2.4. Synkronisering af Filtrene

8.1.2.4.1. Brugen af forskellige meddelelser for standard- og ikke-standardoverførselsbetingelser muliggør identifikationen af en hvilken som helst uoverensstemmelse mellem standardbetingelser, som de holdes i systemerne ved den overførende og den accepterende enhed.

8.1.2.4.2. Identifikationen i den accepterende enhed af ikke-standardoverførselsbetingelser i en meddelelse, der kun bruges til at koordinere standardoverførsler, vil betyde en uoverensstemmelse mellem de to filtre. Sådanne uoverensstemmelser bør afgøres for dialogprocedurens effektive funktion.

8.1.3. Meddelelsessekvens

8.1.3.1. Generelt

8.1.3.1.1. Det er påkrævet, at der følges bestemte regler for at sikre, at koordinering er fuldstændig, før der finder nogen revidering eller overførsel af kommunikationsmeddelelsesudveksling sted og også for at sikre, at flyveledere ved begge enheder ikke samtidigt kommer med forslag med hensyn til den samme flyvning.

8.1.3.1.2. En ATC-enhed skal kun transmittere eller kvittere for modtagelse af en Revideringsmeddelelse (REV eller RRV) for en flyvning, når den er i den koordinerede tilstand, dvs. en ACT- eller RAP-dialog er blevet fuldført ved en LAM eller ACP.

8.1.3.1.3. CDN-meddelelser skal kun være berettigede for transmission ved den accepterende enhed.

8.1.3.1.4. CDN-meddelelser skal kun transmitteres og kvitteres:

- som del af en dialog, der er initieret ved modtagelsen af en Aktiverings- (ACT, RAP) eller en Revideringsmeddelelse (REV eller RRV); eller

- når flyveplanen for den pågældende flyvning er i den koordinerede tilstand.

8.1.4. Samtidig Håndtering af Meddelelser

8.1.4.1. Generelt

8.1.4.1.1. En enhed, der er involveret i en udveksling af en koordinerings- eller en overførselsmeddelelse for en flyvning, skal ikke initiere en yderligere udveksling af en koordinerings- eller overførselsmeddelelse for den samme flyvning med den samme enhed, før der er modtaget enten en LAM, en ACP eller en RJC eller hvis der nås en timeout.

8.1.4.1.2. Det er muligt for en CDN-meddelelse at krydse en REV-, en RRV- eller en MAC-meddelelse for den samme flyvning sendt fra den overførende enhed. Denne situation kan identificeres i den overførende enhed ved, at CDNen ankommer før kvitteringen for den transmitterede koordineringsmeddelelse og i den accepterende enhed ved, at meddelelsen fra den overførende enhed ankommer før kvitteringen for CDNen. I dette tilfælde skal der ikke kvitteres for CDNen og REVen, RRVen eller MACen skal behandles.

8.1.5. Håndtering af Afvisning

RJC-meddelelsen afslutter en systemdialog. Der skal initieres en ny systemkoordinering, som afspejler telefonkoordineringen, hvor det er anvendeligt.

8.1.6. Operationelt Timeout for Besvarelser

8.1.6.1. Generelt

8.1.6.1.1. Der skal anvendes en timeout-mekanisme ved sende- og modtagecentrene for besvarelsen til meddelelser, der henvises til flyvelederen.

8.1.6.1.2. Varigheden af disse timeouts skal være aftalt bilateralt.

8.1.6.1.3. Udløbet af timeout'et ved den overførende enhed skal resultere i, at der udsendes en advarsel til den overførende flyveleder for at angive behovet for at initiere en telefonkoordinering.

8.1.6.1.4. Anbefalinger

1. En advarsel bør vises til den ATC-position i den accepterende enhed, som er ansvarlig for flyvningen, når timeout'et i den overførende enhed er forestående.

2. Advarslen bør tage hensyn til besvarelsens transmissionstid.

8.1.6.1.5. Systemer skal være i stand til at behandle besvarelser, der modtages efter udløbet af timeout'et.

8.1.7. Implementering

8.1.7.1. Dialogprocedurerne henvender sig til to faser, nemlig koordineringsfasen og overførselsfasen. Dialogen i de to faser bruger forskellige meddelelser og de påkrævede transaktionstider er forskellige. Koordineringsmeddelelserne er specificeret i ICAO- og ADEXP-formater og meddelelserne for overførslen af kommunikation kun i ADEXP.

8.1.7.2. De minimale HMI-krav for koordineringsdialogen er forskellige fra de tilsvarende krav for overførselsdialogen:

- Overførselsdialogen henvender sig primært til den udøvende kontrolfunktion og kræver en hurtig og brugervenlig HMI;

- koordineringsdialogen er ikke lige så tidskritisk og derfor er dens HMI-krav af mindre betydning.

8.1.7.3. Dialogproceduren skal implementeres ved at anvende ét af følgende, alternative forløb:

- koordineringsfasedialogprocedure plus en hvilken som helst ekstra meddelelse, som aftalt bilateralt (Afsnit 7 og 8);

- grundlæggende koordineringsprocedure og overførselsfasedialogprocedure (Afsnit 6, 7 og 9);

- koordinerings- og overførselsfasedialogprocedure plus en hvilken som helst ekstra koordineringsmeddelelse, som aftalt bilateralt (Afsnit 7, 8 og 9).

Den Forudgående Grænseinformationsmeddelelse skal sendes i alle forløb.

8.1.7.4. Det forløb, der anvendes til implementeringen, skal være aftalt bilateralt.

8.2. Aktiveringsmeddelelse (ACT)

8.2.1. Formål med ACT-Meddelelsen

Formålet med ACT-Meddelelsen er beskrevet i afsnit 6.3.1. I en dialogprocedure bruges ACT-meddelelsen til at opfylde disse krav forudsat, at overførselsbetingelserne for flyvningen er standardbetingelser og at den overførende flyveleder ikke kræver at henvise flyvningen til den accepterende flyveleder for accept.

8.2.2. Indhold af Meddelelse

Indholdet af den ACT-meddelelse, der bruges i dialogproceduren, skal være som beskrevet for ACT-meddelelsen i afsnit 6.3.2.

8.2.3. Regler for Anvendelse

8.2.3.1. Generelt

8.2.3.1.1. Reglerne for anvendelse er som beskrevet for ACTen i afsnit 6.3 med undtagelse af de specielle regler, der er beskrevet i dette afsnit.

8.2.3.1.2. Der skal sendes en ACT-meddelelse for en flyvning med standardoverførselsbetingelser, hvis den overførende flyveleder ikke kræver, at flyvningen skal henvises til den accepterende flyveleder.NOTE

Hvis disse krav ikke gælder sendes en RAP (se afsnit 8.3 3 Meddelelse om Henvist Aktiveringsforslag).

8.2.3.1.3. Anbefaling

Der bør initieres en ny koordineringsprocedure, hvis der returneres en Meddelelse om Afvisning af Koordinering (RJC) som reaktion på en ACT-meddelelse.

8.2.3.2. Behandling i den Modtagende Enhed

8.2.3.2.1. Meddelelsen kontrolleres i forhold til filteret for at bekræfte, at de foreslåede betingelse er standard.

8.2.3.2.2. Meddelelsen skal behandles som en RAP-meddelelse, hvis:

- overførselsbetingelserne viser sig at være ikke-standard;

- der ikke kan findes en tilsvarende systemflyveplan og der er tilstrækkelig information tilgængelig til at identificere, hvorvidt overførselsbetingelserne er standard eller ej.

8.2.3.2.3. ACT-meddelelser, der viser sig at være standard, skal behandles i overensstemmelse med afsnit 6.3.3.2.

8.2.3.2.4. Anbefaling

Hvis overførselsbetingelserne i en ACT-meddelelse viser sig at være ikke-standard, er der en uoverensstemmelse mellem filtrene i de to systemer. Overvågningsmandskabets opmærksomhed bør henledes på det faktum, at ACTen er ikke-standard, for at uoverensstemmelsen kan løses.

8.2.4. Kvittering for ACT

8.2.4.1. Kvittering

8.2.4.1.1. I en dialogprocedure skal en ACT-meddelelse kvitteres ved:

- en LAM, hvis overførselsbetingelserne viser sig at være standard;

- en SBY-meddelelse i alle andre tilfælde.

8.2.4.1.2. Når der er modtaget en LAM, skal det operationelle indhold af ACT-meddelelsen blive operationelt bindende for begge ATC-enheder.

8.2.4.1.3. Hvor det er aftalt bilateralt, kan der bruges en ACP i stedet for en LAM til at angive accepten af en ACT, der indeholder standardoverførselsbetingelser ved den accepterende enhed.

8.2.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke er modtaget nogen kvittering for en ACT-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.

8.3. Meddelelse om Henvist Aktiveringsforslag (RAP)

8.3.1. Formål med RAP-Meddelelsen

RAP-meddelelsen opfylder de følgende, operationelle krav ud over de, der er specificeret for ACT-meddelelsen i afsnit 6.3:

- forslaget ved den overførende flyveleder og henvisningen til den accepterende flyveleder af flyvninger med ikke-standard overførselsbetingelser;

- at tillade flyvelederen, hvis han/hun ønsker at gøre dette, at tvinge henvisningen til den accepterende flyveleder af standard overførselsbetingelser for en specifik flyvning.

8.3.2. Indhold af Meddelelse

Indholdet i RAP-meddelelsen skal være de samme data som beskrevet for ACT-meddelelsen (afsnit 6.3) og kan frivilligt indbefatte det følgende dataelement:

- årsag, angivende manuel henvisning (kun tilgængelig i ADEXP).

8.3.3. Regler for Anvendelse

8.3.3.1. Generelt

8.3.3.1.1. Der skal sendes en RAP-meddelelse i stedet for ACT-meddelelsen for flyvninger, der krydser grænsen og som opfylder én af de følgende betingelser:

- det overførende system har bestemt overførselsbetingelserne som værende ikke-standard;

- den overførende flyveleder har angivet, at de foreslåede overførselsbetingelser skal henvises til den accepterende flyveleder.

8.3.3.1.2. Det operationelle indhold i RAP-meddelelsen, der skal til at blive transmitteret, skal vises ved den arbejdsposition, der er ansvarlig for koordineringen af flyvningen forud for den aktuelle transmission.

8.3.3.1.3. Anbefaling

Det tidspunkt, hvor RAP-meddelelsen transmitteres automatisk, bør vises sammen med dens indhold.

8.3.3.1.4. Den relevante arbejdsposition skal underrettes om transmissionen af RAP-meddelelsen.

8.3.3.2. Behandling i den Modtagende Enhed

8.3.3.2.1. Det ATC-system, som modtager en RAP-meddelelse, skal forsøge forbindelse med den tilsvarende flyveplan.

8.3.3.2.2. Hvis der findes en tilsvarende flyveplan og der ikke er nogen uoverensstemmelse til stede i meddelelsen, som ville forhindre korrekt behandling:

- skal det operationelle indhold henvises til den accepterende flyveleder;

- skal en SBY returneres.

8.3.3.2.3. Anbefaling

En angivelse af årsagen til henvisningen (ikke-standard betingelser eller manuel henvisning) bør være indeholdt.

8.3.3.2.4. Hvis meddelelsen ikke kan forbindes med en flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen, da:

- skal det operationelle indhold af meddelelsen vises ved sektoren;

og

- en SBY-meddelelse skal returneres;

og

- en flyveplan skal dannes.

8.3.3.2.5. I alle andre tilfælde skal der ikke kvitteres for meddelelsen.

8.3.3.3. Manuel Igangsættelse

8.3.3.3.1. RAPen vil, når den bruges til at tvinge henvisningen af en foreslået koordinering med standardoverførselsbetingelser til den accepterende flyveleder, initieres manuelt af den overførende flyveleder og transmitteres øjeblikkeligt.

8.3.3.3.2. Anbefaling

Manuel igangsættelse af en RAP-meddelelse før den beregnede transmissionstid bør være tilladt ved den position, der er ansvarlig for flyvningens koordinering.

8.3.3.4. Tidsparametre for Automatisk Transmission

Tiden/distancen før den grænse, hvor RAP-meddelelser automatisk transmitteres, skal være den samme som for ACT-meddelelserne.

8.3.4. Kvittering for RAP

8.3.4.1. Kvittering

Der skal kvitteres for meddelelsen ved genereringen og transmissionen af en SBY-meddelelse.

8.3.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke modtages nogen SBY-meddelelse som en kvittering for en RAP-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.

8.3.5. Operationel Besvarelse af RAP

Den accepterende flyveleder kan enten acceptere, stille et mod-forslag om eller afvise overførselsbetingelser.

8.3.5.1. Accept

8.3.5.1.1. Når den accepterende flyveleder vælger at acceptere de foreslåede overførselsbetingelser, skal en ACP-meddelelse returneres.

8.3.5.1.2. Så snart som ACP-meddelelse er blevet modtaget, bliver RAP-meddelelsesdataene operationelt bindende for begge ATC-enhederne. De koordinerede overførselsbetingelser og det faktum, at ACP er blevet modtaget, skal forelægges for den overførende flyveleder.

8.3.5.2. Mod-Forslag

Når den accepterende flyveleder vælger at stille et mod-forslag om overførselsbetingelserne, skal der returneres en CDN-meddelelse.

8.3.5.3. Anbefaling

Når den accepterende flyveleder vælger at afvise de foreslåede overførselsbetingelser, bør der returneres en RJC-meddelelse. En ny koordineringsproces bør da initieres.

NOTE

Med hensyn til anbefalingen i 8.3.5.3, vil den nye koordinering i de fleste tilfælde være med en anden enhed.

8.3.6. Eksempler

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. Revideringsmeddelelse (REV)

8.4.1. Formål med REV-Meddelelsen

Formålet med REV-meddelelsen er beskrevet i afsnit 7.3.1. I en dialogprocedure bruges REV-meddelelsen til at opfylde disse krav, under forudsætning af at overførselsbetingelserne for flyvningen er standard og at den overførende flyveleder ikke kræver at henvise flyvningen til den accepterende flyveleder for accept.

8.4.2. Indhold af Meddelelse

Indholdet af REV-meddelelsen skal være som beskrevet for REV-meddelelsen i afsnit 7.3.2.

8.4.3. Regler for Anvendelse

8.4.3.1. Generelt

8.4.3.1.1. Der kan sendes én eller flere REV-meddelelser til den enhed, som en flyvning for øjeblikket er blevet koordineret til ved brug af en Aktiverings- eller RAP-meddelelse.

8.4.3.1.2. REV-meddelelser skal sendes under de betingelser, som er specificeret i afsnit 7.3.3.1 for flyvninger med standard overførselsbetingelser, hvilke flyvninger den overførende flyveleder ikke kræver bliver henvist til den accepterende flyveleder.

8.4.3.2. Initiering af Transmission

REV-meddelelsen skal transmitteres straks efter en detektering af en ændring i de koordineringsdata, der påkrævet skal koordineres som beskrevet i afsnit 7.3.3.

8.4.3.3. Behandling i den Modtagende Enhed

8.4.3.3.1. Hvis der findes en tilsvarende flyveplan i den koordinerede tilstand og der ikke findes nogen uoverensstemmelse, som ville forhindre korrekt behandling af meddelelsen, da:

- skal der kvitteres for REV-meddelelsen;

- i alle andre tilfælde skal der ikke kvitteres for meddelelsen.

8.4.3.3.2. Overførselsbetingelserne skal undersøges for at sikre, at de er standard.

8.4.3.3.3. Hvis overførselsbetingelserne ikke er standard, skal de forelægges for den accepterende flyveleder.

8.4.3.3.4. Hvis det viser sig, at de foreslåede overførselsbetingelser er standard, skal de indbefattes i flyveplanen og de påkrævede data skal udsendes ved operationel ATC og andre positioner, som det er passende.

8.4.3.3.5. Anbefaling

Hvis overførselsbetingelserne i en REV-meddelelse viser sig at være ikke-standard, er der en uoverensstemmelse mellem filtrene i de to systemer. Overvågningsmandskabets opmærksomhed bør henledes på det faktum, at REVen er ikke-standard, for at uoverensstemmelsen kan løses.

8.4.4. Kvittering for REV

8.4.4.1. Kvittering

8.4.4.1.1. Hvis der skal kvitteres for en REV-meddelelse, skal den kvitteres ved:

- en LAM-meddelelse, hvis overførselsbetingelserne har vist sig at være standard;

- en SBY-meddelelse, hvis overførselsbetingelserne har vist sig at være ikke-standard.

8.4.4.1.2. Når der er modtaget en LAM, bliver det operationelle indhold af REV-meddelelsen operationelt bindende til begge ATC-enhederne.

8.4.4.1.3. Hvor det er aftalt bilateralt, kan en ACP anvendes i stedet for en LAM for at angive accepten ved den accepterende enhed af en REV, som indeholder standardoverførselsbetingelser.

8.4.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke modtages nogen kvittering for en REV-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for koordineringen af flyvningerne.

8.4.5. Operationel Besvarelse af REV

Idet REV-meddelelsen bruges til at sende standard overførselsbetingelser vil den almindeligvis blive accepteret af systemet i den accepterende enhed. Hvis filteret i den accepterende enhed finder, at overførselsbetingelserne er ikke-standard, skal meddelelsen behandles som en RRV-meddelelse.

8.5. Meddelelse om Forslag om Henvist Revidering (RRV)

8.5.1. Formål med RRV-Meddelelsen

RRV-meddelelsen skal sørge for revideringen af tidligere sendte og aftalte betingelser i de følgende tilfælde:

- når de foreslåede overførselsbetingelser i revideringen er ikke-standard;

- når den foreslåede revidering er standard, men den overførende flyveleder ønsker at henvise revideringen til den accepterende flyveleder.

8.5.2. Indhold af Meddelelse

Indholdet af RRV-meddelelsen skal være som beskrevet for REV-meddelelsen (afsnit 7.3.2) og kan frivilligt indbefatte det følgende dataelement:

- årsag, angivende manuel henvisning (kun tilgængelig i ADEXP).

8.5.3. Regler for Anvendelse

8.5.3.1. Generelt

Der skal sendes én eller flere RRV-meddelelser i stedet for REV-meddelelser for hver revidering, hvis enten:

- det overførende system har bestemt overførselsbetingelserne som værende ikke-standard;

eller

- den overførende flyveleder har angivet, at de foreslåede overførselsbetingelser skal henvises til den accepterende flyveleder. Denne anvendelse af RRVen er valgfri.

8.5.3.2. Initiering af Transmission

RRV-meddelelsen skal transmitteres straks efter detekteringen af en ændring i koordineringsdataene eller når den initieres manuelt.

8.5.3.3. Behandling i den Modtagende Enhed

8.5.3.3.1. Hvis der findes en tilsvarende flyveplan i den koordinerede tilstand og hvis der ikke findes nogen uoverensstemmelse, som ville forhindre en korrekt behandling af meddelelsen, da:

- skal der kvitteres for RRV-meddelelsen;

- i alle andre tilfælde skal der ikke kvitteres for meddelelsen.

8.5.3.3.2. De foreslåede overførselsbetingelser skal vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.

8.5.3.3.3. Anbefaling

En indikation af årsagen til henvisningen (ikke-standard betingelser eller manuel henvisning) bør indbefattes.

8.5.4. Kvittering for RRV

8.5.4.1. Kvittering

Der skal kvitteres for meddelelsen ved at generere og transmittere en SBY-meddelelse.

8.5.4.2. Tilfælde af Ingen Kvittering

Hvis der ikke modtages nogen SBY-meddelelse som kvittering for en RRV-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen af flyvningen.

8.5.5. Operationel Besvarelse af RRV

Den accepterende flyveleder kan enten acceptere, stille et mod-forslag om eller afvise en RRV-meddelelse.

8.5.5.1. Accept

Når den accepterende flyveleder vælger at acceptere de foreslåede rettelser til de aftalte overførselsbetingelser, skal der returneres en ACP-meddelelse.

8.5.5.2. Mod-Forslag

Når den accepterende flyveleder vælger at stille et mod-forslag om overførselsbetingelser, skal der returneres en CDN-meddelelse.

8.5.5.3. Afvisning

Når den accepterende flyveleder vælger at afvise de foreslåede rettelser i de aftalte overførselsbetingelser:

- skal en RJC-meddelelse returneres;

og

- en ny koordineringsproces skal initieres.

Afvisning er underforstået, hvis der hverken modtages en ACP- eller en CDN som reaktion på RRV-meddelelsen.

8.5.6. Eksempler

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. Stand-by Meddelelse (SBY)

8.6.1. Formål med SBY-Meddelelsen

SBY-meddelelsen kvitterer for modtagelsen af en meddelelse, der foreslår overførselsbetingelser, og angiver, at forslaget er blevet henvist til flyvelederen for en beslutning.

8.6.2. Indhold af Meddelelse

SBY-meddelelsen skal indeholde de følgende dataemner:

- Meddelelsest