KOMMISSIONENS FÖRORDNING (EG) nr 2082/2000

av den 6 september 2000

om antagande av Eurocontrol-standarder och om ändring av direktiv 97/15/EG om antagande av Eurocontrol-standarder och om ändring av rådets direktiv 93/65/EEG

EUROPEISKA GEMENSKAPERNAS KOMMISSION HAR ANTAGIT DETTA DIREKTIV

med beaktande av Fördraget om upprättandet av Europeiska gemenskapen,

med beaktande av rådets direktiv 93/65/EEG av den 19 juli 1993 om definition och användning av kompatibla tekniska specifikationer vid upphandling av utrustning och system för ledning av lufttrafiken(1), särskilt artikel 3 i detta,

med beaktande av kommissionens direktiv 97/15/EG av den 25 mars 1997 om antagande av Eurocontrol-standarder och om ändring av rådets direktiv 93/65/EEG(2),

och av följande skäl:

1. Genom direktiv 97/15/EG antogs Eurocontrol-standarden för utbyte on-line av data (OLDI), utgåva 1.0 och Eurocontrol-standarden för utformningen av utbytet av ATS-data (ADEXP), utgåva 1.0.

2. Eurocontrol har antagit nyare utgåvor av de två ovan nämnda standarderna, OLDI utgåva 2.2 och ADEXP utgåva 2.0 samt en ny Eurocontrol-standard kallad Eurocontrol-standarden för utbyte av flygdata - dokument för kontroll av gränssnitt (FDE-ICD).

3. Dessa Eurocontrol-standarder ligger inom tillämpningsområdet för direktiv 93/65/EEG och bidrar till harmoniseringen av medlemsstaternas nationella system för ledning av lufttrafiken, särskilt vad beträffar överföringen av flygningar mellan kontrollcentraler för lufttrafik (OLDI), ledningen av lufttrafikflödet (ADEXP) och kommunikationerna mellan nationella system (FDE-ICD).

4. OLDI utgåva 2.2 och ADEXP utgåva 2.0 ersätter tidigare utgåvor som nu gäller enligt artikel 1 i direktiv 97/15/EG och därför måste den artikeln upphävas.

5. Bestämmelserna i detta direktiv är förenliga med yttrandet från den kommitté som upprättats i enlighet med direktiv 93/65/EEG.

HÄRIGENOM FÖRESKRIVS FÖLJANDE.

Artikel 1

De obligatoriska elementen i Eurocontrol-specifikationerna, som ingår i följande Eurocontrol-standarder, skall antas, inom ramen för direktiv 93/65/EEG eftersom de är nödvändiga för genomförandet av ett integrerat europeiskt system för lufttrafikledning:

- Eurocontrol-standarden för utbyte on-line av data (OLDI), utgåva 2.2 (Eurocontrol-dokument DPS.ET1.ST06-STD). Texten bifogas i bilaga I till denna förordning.

- Eurocontrol-standarden för utformningen av utbytet av ATS-data (ADEXP), utgåva 2.0 (Eurocontrol-dokument DPS.ET1.ST09-STD). Texten bifogas i bilaga II till denna förordning.

- Eurocontrol-standarden för utbyte av flygdata - dokument för kontroll av gränssnitt (FDE-ICD), utgåva 1.0 (Eurocontrol-dokument COM.ET1.ST12-STD). Texten bifogas i bilaga III till denna förordning.

Artikel 2

Artikel 1 i direktiv 97/15/EG skall upphöra att gälla.

Artikel 3

Denna förordning träder i kraft den tredje dagen efter det att den har offentliggjorts i Europeiska gemenskapernas officiella tidning.

Denna förordning är till alla delar bindande och direkt tillämplig i alla medlemsstater.

Utfärdad i Bryssel den 6 september 2000.

På kommissionens vägnar

Loyola DE PALACIO

Vice ordförande

(1) EGT L 187, 29.7.1993, s. 52.

(2) EGT L 95, 10.4.1997, s. 16.

BILAGA I

UTBYTE ON-LINE AV DATA (OLDI)

(EUROCONTROL-DOKUMENT DPS.ET1.ST06-STD)

INNEHÅLLSFÖRTECKNING

>Plats för tabell>

MEDDELANDE OM UPPHOVSMANNARÄTT

Detta dokument har sammanställts av Eurocontrolbyrån.

Eurocontrolbyrån har lagstadgad upphovsmannarått.

Innehållet, eller del därav, är således fritt tillgängligt för representanter för medlemsstaterna, dock får kopiering eller spridning av innehållet till någon annan part inte ske utan skriftligt tillstånd från Eurocontrolbyrån.

FÖRORD

1. Ansvarig organisation

Eurocontrolstandard för utbyte on-line av data (On-Line Data Interchange, OLDI), utgåva 2.2 har utarbetats av direktoratet för utveckling av Eatchip-programmet för harmonisering och integrering av europeisk flygkontrolltjänst [Directorate of European ATC Harmonisation and Integration Programme (EATCHIP) Development (DED)], inom Eurocontrol, vilket också ansvarar för uppdateringen av dokumentet. Alla kommentarer och förfrågningar skall adresseras till generaldirektören för Eurocontrol, Rue de la Fusée, 96, B-1130 Bryssel, Attention Division DED-2.

2. Förhållande till Eatchips arbetsprogramdokument

Denna standard är underordnad specialistuppdrag DPS.ET1.ST06, under domänen för ATM-databehandlingssystem (DPS) inom Eatchip, som specificerats i Eatchips arbetsprogramdokument (EWPD) utgåva 2.0, daterad 940930.

3. Godkännande och ändringar

Denna standard har varit föremål för följande godkännandeförfarande, vilket beskrivits i detalj i direktiven om Eurocontrols standardisering:

- Godkännande av Eatchips arbetsgrupp för operativa krav och behandling av ATM-data (ODT) genom korrespondensförfarande.

- Konsultationer med samtliga ECAC-stater genom deras representanter i styrkommittén (Committee of Management) eller Eatchips projektstyrelse.

- Godkännande av Eatchips projektstyrelse och styrkommittén.

- Antagande av den ständiga kommissionen.

Villkoren i denna standard gäller efter antagandet av den ständiga kommissionen.

För att möta kraven på en utveckling av förfaranden för flygkontrolltjänst (ATC), kan ändringar och tillägg föreslås genom ODT för diskussion och möjligt godkännande. Kraven kommer att införas antingen som en ändring eller som en ytterligare utgåva av dokumentet för antagande och godkännande enligt specificerade förfaranden.

4. Redaktionella regler

Följande praxis har följts för att beskriva status på respektive påstående: Normativa delar har skrivits med normal text. Rekommenderade delar har skrivits med kursiv stil, och status indikeras där med prefixet Rekommendation.

Följande redaktionella regel har följts då specifikationerna har skrivits: I normativa delar används det modala hjälpverbet "skall", och i rekommenderade delar används det modala hjälpverbet "bör".

Anmärkningar är skrivna med vanlig text föregångna av prefixet "ANMÄRKNING" i fet stil.

5. Förhållande till utgåva 1 av Eurocontrolstandard för utbyte on-line av data

Detta dokument ersätter delarna 1 och 2 av utgåva 1 av Eurocontrolstandard för utbyte on-line av data. Del 3, som beskriver de tekniska protokollen som skall användas har ersatts av Eurocontrolstandard för utbyte av flygdata - Dokument för kontroll av gränssnitt Del 1.

6. Betydelsefulla förändringar från utgåva 1

De mest betydelsefulla ändringarna och tilläggen från utgåva 1 är följande:

1. Införandet av följande kompletterande (icke obligatoriska) meddelanden rörande det grundläggande förfarandet:

- Meddelande om upphävande av samordning (MAC).

- Meddelande om tilldelning av SSR- (Sekundär övervakningsradar) kod (COD).

- Informationsmeddelande (INF).

2. Definition av meddelandeinnehåll och format för att stödja korsningen av en gräns för en flygning på en kurs som inte är en definierad flygtrafiklednings- (Air Traffic Services - ATS) flygväg, men som är definierad med start- och slutpunkt för flygvägssegmentet.

3. Införandet av ett dialogförfarande som tillåter

- identifiering och hantering av onormala överföringsförhållanden av flygledare som utför planeringsfunktionen,

- tillhandahållande av en möjlighet för den mottagande enheten att lägga fram motförslag till överföringsförhållandena,

- tillhandahållande av funktioner för överföring av kommunikationen, som en del av förfarandet för överföring av kontrollen.

4. Användandet av det format som beskrivs i utgåva 2 av Eurocontrolstandard för utformningen av utbytet av ATS-data (ADEXP) har introducerats. Alla meddelanden som specificerats under det grundläggande förfarandet och de som används under samordningsfasen av dialogförfarandet har beskrivits med användande av både ICAO- och ADEXP-format. Meddelanden om kommunikationsöverföring, beskrivna under dialogförfarandet, beskrivs med användande endast av ADEXP-format.

5. Strykning av följande bilagor i utgåva 1:

A: Identifiering av ATC-enhet.

B: Struktur på OLDI-meddelanden

(alla meddelanden i utgåva 3 innehåller exempel).

D: Historisk översikt.

E: Genomförandeplan.

F: Staters uppfyllande av krav.

G: Riktlinjer för genomförande.

H: Riktlinjer för utvärdering av OLDI.

6. Frånskiljande av del 3, Tekniska krav, från tillämpningsspecifikationen.

7. Förhållande till andra dokument

Detta dokument hänvisar till användandet av två typer av fältformat i sammansättningen av meddelanden. Dessa är ICAO och ADEXP.

ICAO-fältformatet beskrivs i referensdokument 1. Om referensdokument 1 ersätts av ett annat dokument, skall definitionen av ICAO-fälttyperna vara de som beskrivs i det dokumentet.

Format för ADEXP-fält beskrivs i referensdokument 2.

ANMÄRKNING

De referensdokument som det hänvisas till är listade i avsnitt 2.

8. Språk

Originaltexten i denna standard är skriven på engelska.

1. INLEDNING

1.1. Syfte

1.1.1. Flygningar som tillhandahålls tjänster från ATC överförs från en ATC-enhet till en annan på ett sätt som utformats för att säkerställa total säkerhet. För att detta syfte skall uppnås, är det normala förfarandet att varje flygnings passering över gränsen mellan de två enheternas ansvarsområde samordnas mellan dessa i förväg och att kontrollen av flygningen överförs då den befinner sig över eller i anslutning till nämnda gräns.

1.1.2. Då den utförs via telefon, är överföringen av data för individuella flygningar, som del av samordningsförfarandet, en omfattande stöduppgift för ATC-enheterna, speciellt vid regionala kontrollcentraler (Area Control Centres, ACC). I syfte att ersätta sådana muntliga "uppskattningar" påbörjade man i början av 1980-talet inom Europa ett operativt användande av anslutningar mellan processystemen för flygdata (Flight Data Processing Systems - FDPS) vid kontrollcentralerna, vilket betecknas utbyte on-line av data - OLDI (On-Line Data Interchange).

1.1.3. För att förenkla genomförandet, utarbetades omsorgsfullt gemensamma regler och meddelandeformat vilka accepterades av berörda organ och införlivades i utgåva 1 av Eurocontrolstandard för utbyte on-line av data (OLDI). Detta dokument, utgåva 2.2, har sammanställts för att stödja den fortsatta utvecklingen av sådana möjligheter med hänsyn till behoven för Eatchip.

1.2. Omfattning

1.2.1. Detta dokument specificerar de hjälpmedel och meddelanden som skall tillhandahållas mellan FDPS-system som betjänar ATC-enheter i syfte att uppnå

- den samordning som krävs inför överföringen av flygningar från en enhet till en annan

- överföring av kommunikationen för sådana flygningar.

1.2.2. Detta dokument

- definierar meddelandeformaten och reglerna för innehållet,

- beskriver hjälpmedlen som behövs vid sådana enheter, och som utgör förutsättningar för användandet av datautbyte i detta syfte.

1.2.3. Denna standard är tillämplig mellan medlemsstater i Eurocontrol på internationella OLDI-installationer mellan enheter som tillhandahåller regional ATC-tjänst

1.2.4. Rekommendation

Det rekommenderas att länder inom Europeiska konferensen för civil luftfart (ECAC) tillämpar denna standard på

- internationella OLDI-installationer mellan enheter som tillhandahåller regional ATC-tjänst inom ECAC-området,

- OLDI-installationer mellan enheter som tillhandahåller regional ATC-tjänst inom berört land.

2. HÄNVISNINGAR

2.1. Följande dokument och standarder innehåller bestämmelser vilka, genom hänvisningar i denna text, utgör bestämmelser i denna Eurocontrolstandard.

Vid tidpunkten för publiceringen av denna Eurocontrolstandard var de angivna utgåvorna av referensdokument och -standarder gällande.

Vid samtliga revisioner av de ICAO-dokument, till vilka hänvisning här skett, skall omedelbart revision av denna Eurocontrolstandard tas i beaktande.

Revidering av de övriga dokument som det refererats till, skall inte utgöra del av bestämmelserna i denna Eurocontrolstandard förrän de är formellt genomgångna och införlivade i denna Eurocontrolstandard.

Vid konflikt mellan bestämmelserna i denna Eurocontrolstandard och innehållet i de övriga dokument, till vilka hänvisning skett, gäller denna Eurocontrolstandard.

2.2. I denna standard görs hänvisningar till följande dokument:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services, ICAO Document 4444, trettonde uppdaterade utgåvan, daterad 7 Nov. 1996.

2. Utgåva 2.0 av Eurocontrolstandard för utformningen av utbytet av ATS-data (ADEXP), referens DPS-ET1-ST09-STD-01-00, daterad juni 1998.

3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR

3.1. Definitioner

I denna Eurocontrolstandard används följande beteckningar med de betydelser som här anges:

3.1.1. accepterande enhet: den enhet, tillhandahållande ATC-tjänst, som skall överta kontrollen eller som har övertagit kontrollen över en flygning när överföringen från en enhet till nästa skall ske eller har skett.

3.1.2. bekräftelse: tillkännagivande att ett meddelande har emottagits och befunnits vara korrekt för behandling.

3.1.3. aktivering: förfarandet hos en mottagande ATC-enhet i vilken färdplanen för berörd flygning uppgraderas till att inkludera de data som tillhandahållits från den överlämnande ATC-enheten som del av samordningsförfarandet mellan de två enheterna och som resulterar i tillhandahållandet av data till flygledare.

3.1.4. höjd: det vertikala avståndet till en nivå, en punkt eller ett föremål betecknat som en punkt, mätt över havsytan.

3.1.5. tillämpning: den del av ett ATS-undersystem som överensstämmer med denna standard och samverkar med sådana enheter i andra ATS-system.

3.1.6. ansvarsområde: ett luftrum med fastställda dimensioner inom vilket en ATC-enhet tillhandahåller flygtrafikledning.

3.1.7. anslutning till färdplan: ett förfarande där ett system sammankopplar ett emottaget OLDI-meddelande med en färdplansregistrering i databasen.

3.1.8. ATC-enhet: en enhet som tillhandahåller flygkontrolltjänst.

3.1.9. tillgänglighet: sannolikheten att en anläggning kommer att vara tillgänglig för en användare vid en tidpunkt.

3.1.10. gräns: de plan (horisontella and vertikala) som utgör ansvarsområdet för en ATC-enhet.

3.1.11. tilldelad flygnivå: den flygnivå till vilken, eller vid vilken, en flygning för närvarande har fått godkännande av ATC.

3.1.12. samordning, ATC: den process, utförd mellan ATC-enheter med angränsande ansvarsområden, i vilken man formellt rådgör med varandra om den planerade flygningen över gränsen, för att säkerställa flygsäkerheten genom konsekvens i planerade handlingar.

3.1.13. samordningsmeddelande: ett allmänt uttryck som innebär ett meddelande som används för att uppnå ATC-samordning. Häri inkluderas CDN, ett särskilt meddelande som beskrivs i punkt 8.8.

3.1.14. samordningsfas: den fas under en flygning under vilken den överlämnande och den mottagande ATC-enheten kommer överens om de förhållanden (t.ex. flygnivå, gränspunkt) under vilka en flygning skall övergå från en enhets kontroll till en annan.

3.1.15. samordningspunkt: en punkt på eller intill gränsen, igenkänd av ATC-enheterna i en samordningssekvens och hänvisad till i samordningsmeddelanden.

3.1.16. samband: förfarande, baserat på fastställda kriterier, för att sammankoppla färdplansdata och radarspårning för en flygning, normalt för presentation på en bildskärm hos flygledare.

3.1.17. Eurocontrolstandard: alla specifikationer avseende fysiska egenskaper, form, material, funktion, personal eller förfarande, vars enhetliga tillämpning anses vara oumbärlig för att kunna genomföra ett integrerat system för flygtrafikledning (ATS-system) inom medlemsstater i Eurocontrol. En Eurocontrolstandard får inte strida mot en ICAO-standard, men skall, där detta är tillämpligt, komplettera den senare.

3.1.18. utövande flygledare: en flygledare som tillhandahåller instruktioner direkt till flygningar under hans/hennes kontroll. Sådana flygledare inkluderar de som tillhandahåller tjänsterna för radarövervakning av området.

3.1.19. utträdesnivå: den nivå vid vilken en flygning har samordnats till att korsa en kontrollöverföringspunkt. En utträdesnivå kan inkludera tilläggsvillkor som definierar nivåområdet inom vilket en stigande/sjunkande flygning kommer att befinna sig.

3.1.20. färdplan: detaljerad information, lämnad till flygtrafikledningsenheter, som berör ett flygplans planerade flygning eller del av en flygning. Även information som härstammar från färdplanen för en flygning som finns i ett FDPS.

3.1.21. generera: en process i ett ATC-system där relevant data tas ut ur databasen/databaserna och ett meddelande skapas för överföring till en mottagande ATC-enhet.

3.1.22. ICAO-format: det format som används för mark-till-mark-sändningar av ATS-meddelanden och som använder fälttyper och avgränsare beskrivna i referensdokument 1.

3.1.23. nivå: ett allmänt begrepp som härrör sig till den vertikala positionen på ett flygplan under flygning. Inom denna standard inkluderar benämningen nivå eller flygnivå höjd i de fall benämningen används.

3.1.24. underrättelse: det förfarande där den överlämnande enheten överför data för att uppdatera systemet hos den mottagande enheten för att förbereda till samordningsfasen.

3.1.25. mottagande enhet: den ATC-enhet till vilken ett meddelande skickas.

3.1.26. tillförlitlighet: det procenttal av den schemalagda tillgängligheten för vilken tjänsten är i drift.

3.1.27. begärd flygnivå: en flygnivå som begärts i färdplanen för en flygning.

3.1.28. revision: en ändring av data som tidigare skickats från den överlämnande ATC-enheten till den mottagande ATC-enheten.

3.1.29. tilläggsnivå för korsning: en nivå vid, eller över eller under vilken en flygning har samordnats för att korsa en kontrollöverföringspunkt. Tilläggsnivån, om sådan förekommer, är en del av utträdesnivån.

3.1.30. systemfärdplan: information som härrör från färdplanen för en viss flygning och som finns i ett FDPS.

3.1.31. transaktionstid: ett tidsintervall som följer initieringen av ett meddelande, under vilket överföring, första behandling i mottagarsystemet, genererandet och överföringen av ett bekräftelsemeddelande samt dess identifiering i överföringssystemet genomförs.

3.1.32. kontrollöverföringspunkt: en fastställd punkt, efter ett flygplans flygväg, vid vilken ansvaret för att tillhandahålla ATS till flygplanet överförs från en ATC-enhet eller kontrollposition till nästa. Den behöver inte nödvändigtvis överensstämma med samordningspunkten.

3.1.33. överföringsfas: en fas av en flygning, som följer samordningsfasen, under vilken överföringen av kommunikationen verkställs.

3.1.34. överlämnande enhet: i en samordningssekvens, den ATC-enhet som är ansvarig för att tillhandahålla en tjänst till en flygning före gränsen och som påbörjar samordningsfasen med nästa enhet.

3.1.35. sända: överföra ett meddelande från ett system till ett annat.

3.1.36. enhet: flygtrafikledningsenhet

3.1.37. varning: ett meddelande som visas på en arbetsstation när den automatiska samordningsprocessen har misslyckats.

3.2. Symboler och förkortningar

I denna Eurocontrolstandard används följande förkortningar med de betydelser som här anges:

ABI Förhandsmeddelande med gränsinformation (Advance Boundary Information Message)

ACC Regional kontrollcentral (Area Control Centre)

ACP Godkännandemeddelande (Accept Message)

ACT Aktiveringsmeddelande (Activate Message)

ADEXP Utformningen av utbytet av ATS-data (ATS Data Exchange Presentation)

ATC Flygkontrolltjänst (Air Traffic Control)

ATM Flygledning (Air Traffic Management)

ATS Flygtrafikledning (Air Traffic Service)

CDN Samordningsmeddelande (Co-ordination Message)

CNL Annullering av färdplan (Flight Plan Cancellation)

COD Meddelande om tilldelning av SSR-kod (SSR Code Assignment Message)

COF Meddelande om frekvensändring (Change of Frequency Message)

COP Samordningspunkt (Co-ordination Point)

DED Direktoratet för utveckling av Eatchip-programmet (Directorate of Eatchip Development), Eurocontrol

Eatchip Programmet för harmonisering och integrering av europeisk flygkontrolltjänst (European ATC Harmonisation and Integration Programme)

ECAC Europeiska konferensen för civil luftfart

ETO Beräknad "time over" (Estimated Time Over)

ETOT Beräknad starttid (Estimated Take-Off Time)

EWPD Eatchips arbetsprogramdokument (Eatchip Work Programme Document)

FDPS Processystem för flygdata (Flight Data Processing System)

FRF Fortsatt flygväg (Further Route of Flight)

HMI Gränssnitt människa-maskin (Human-Machine Interface)

HOP Meddelande med förslag till överlämning (Handover Proposal Message)

ICAO Internationella civila luftfartsorganisationen

INF Informationsmeddelande (Information Message)

LAM Logiskt bekräftelsemeddelande (Logical Acknowledgement Message)

LoA Skriftlig överenskommelse (Letter of Agreement)

MAC Meddelande om upphävande av samordning (Message for the Abrogation of Co-ordination)

MAS Manuellt övertagande av kommunikationen (Manual Assumption of Communications)

NM Nautisk mil (Nautical Mile)

OLDI Utbyte on-line av data (On-Line Data Interchange)

ORCAM Metod för kodtilldelning för upphovsområde (Originating Region Code Assignment Method)

PAC Preliminärt aktiveringsmeddelande (Preliminary Activate Message)

RAP Meddelande med remitterat aktiveringsförslag (Referred Activate Proposal Message)

REV Ändringsmeddelande (Revision Message)

RJC Meddelande med avslag av samordning (Reject Co-ordination Message)

ROF Meddelande med begäran om frekvens (Request on Frequency Message)

RRV Remitterat ändringsmeddelande (Referred Revision Message)

SBY Beredskapsmeddelande (Stand-by Message)

SDM Meddelande med tilläggsdata (Supplementary Data Message)

SSR Sekundär övervakningsradar (Secondary Surveillance Radar)

SYSCO Systemstödd samordning (System Supported Co-ordination)

TI Initiering av överföring (Transfer Initiation)

TIM Meddelande om initiering av överföring (Transfer Initiation Message)

TWR/APP Kontrolltorn och inflygningskontroll [Tower (aerodrome control) and Approach Control]

4. ALLMÄNNA KRAV

4.1. Inledning

Detta avsnitt beskriver de allmänna operativa kraven nödvändiga för genomförandet av OLDI-möjligheter mellan ATC-enheter samt klassificerings- och prestandakraven för de olika typer av meddelanden som används.

4.2. Systemkrav för behandling av flygdata

4.2.1. Flygdatabas

Enheter som utnyttjar en möjlighet som beskrivs i detta dokument skall förses med data från en FDPS som innehåller all nödvändig information som specificerats för visning, behandling och sammansättning av meddelanden. Den primära källan till data för varje flygning är färdplanen som den registrerats av, eller för, befälhavaren. Ytterligare data erhålls genom behandlingen av färdplaner med hänvisning till förhållandena vid berörd enhet.

4.2.2. Drift i realtid

OLDI-förfarandet inkluderar händelser hos den överlämnande ATC-enheten för att initiera funktioner som är nödvändiga för lämplig presentation av data till den accepterande enheten. I detta syfte skall FDPS kunna initiera funktioner genom jämförelse mellan UTK-tid och tillämpliga tidsparametrar med tider vid angivna positioner längs flygvägen, fastställda med hjälp av flygdatabasen.

4.2.3. Kapacitet för datakommunikation

4.2.3.1. FDPS skall kunna mottaga och sända flygdata i det format som är tillämpligt för meddelandena som specificerats i detta dokument via ett medium för datakommunikation som stödjer OLDI-funktionen.

4.2.3.2. Rekommendation

FDPS borde ha utvecklingspotential för att tillåta tillägg av nya meddelanden som kan komma att inkluderas i framtida utgåvor av denna standard.

4.2.3.3. Inom prestandakraven som specificerats i detta dokument, skall mediet för datakommunikation tillhandahålla ett snabbt och pålitligt datautbyte mellan tillämpningarna genom

- säkerställande av integritet vid överföring av OLDI-meddelanden

och

- kontroll av direktanslutningar eller status på kommunikationsnätverket, vilket som är tillämpligt.

4.2.3.4. FDPS skall varna arbetsstationerna när avvikelser upptäcks av datakommunikationssystemet.

4.2.4. Funktioner

4.2.4.1. Systemen som används för OLDI-installationer skall automatiskt kunna ta emot, lagra, behandla, utvinna och leverera för visning, samt sända OLDI-relaterad data i realtid.

4.2.4.2. FDPS skall

- återspegla aktuell operativ data av betydelse för OLDI-funktionerna enligt kraven i denna standard, uppdaterad antingen automatiskt eller genom manuell inläsning, eller genom en kombination av båda,

- kunna utvinna sådana delar från databasen för färdplaner,

- identifiera nästa ATC-enhet längs flygvägen.

4.2.4.3. Följande skall överenskommas bilateralt:

- Samordningspunkter (COP).

- Referenspunkter använda för bärings- och distansnoteringar för identifiering av COP på direkta, icke ATS-segment av flygvägen, där sådana brukas.

ANMÄRKNING

COP behöver inte alltid vara identiska med kontrollöverföringspunkterna.

4.2.5. Gränssnitt människa-maskin (HMI)

4.2.5.1. HMI skall kunna

- visa det operativa innehållet i OLDI-meddelanden och relevanta varningar relaterade till emottagna meddelanden för omedelbar uppmärksamhet,

- befordra varningar rörande samordnings- och överföringsmeddelanden till ansvariga operativa befattningar för samordning av berörda flygningar.

4.2.5.2. ATC personal skall ha tillgång till medel för att omvandla data, från vilken det operativa innehållet i meddelanden erhålls, enligt kraven i detta dokument.

4.2.5.3. HMI skall visa att överföring av meddelandet pågår, eller att överföringen har lyckats, vilket som är fallet.

4.2.5.4. En varning eller underrättelse till berörd ATC eller teknisk(a) befattning(ar) skall genereras automatiskt om ingen bekräftelse har emottagits inom tidsparametern som följer efter en sändning av ett samordnings- eller överföringsmeddelande.

4.2.5.5. En sådan varning eller underrättelse skall vara i sådant format att den omedelbart tilldrar sig uppmärksamhet vid berörd arbetsstation.

4.2.5.6. Rekommendation

HMI vid ATC-stationer som använder OLDI bör utfärda en varning om OLDI-installationen ej är tillgänglig.

4.2.6. Initiering av meddelanden

4.2.6.1. Varje system skall bestå av en uppsättning systemparametrar för att säkerställa läglig automatisk initiering av OLDI-meddelanden.

4.2.6.2. Rekommendation

Det skall finnas möjlighet att manuellt initiera överföringen av ett samordningsmeddelande före den beräknade sändningstiden.

4.2.6.3. Det skall säkerställas att den automatiska funktionen alltid utlöses om manuell initiering ej utförs.

4.2.6.4. Systemet skall använda tidsparametrar för att definiera följande:

- Tid, före sändning, då det operativa innehållet i meddelandena inom den överlämnande enheten visas.

- Tid, global eller per COP, för att sända meddelandet, där så är tillämpligt.

- Tid efter sändning av ett meddelande efter vilken en bekräftelse på tillämpningsnivå skall erhållas (tidsbegränsning).

4.2.6.5. Ett meddelande skall sändas utan fördröjning när den erforderliga informationen blir tillgänglig vid en tidpunkt senare än den vid vilken det annars normalt skulle ha sänts.

Exempel:

En flygning påbörjar ett GAT IFR-segment vid en punkt nära den gräns som den skall korsa. ETO för punkten meddelas åtta minuter före COP, vid vilken tid sändningen av ATC-meddelandet redan är sen, baserat på tillämplig(a) tidsparameter(-parametrar). Meddelandet sänds utan fördröjning.

4.2.7. Mottagande av meddelanden

4.2.7.1. ATC-systemet skall ha förmågan att

- ta emot OLDI-meddelanden,

- behandla dessa automatiskt i överensstämmelse med denna standard,

- producera flygdata i överensstämmelse med mottaget meddelande och visa erforderliga varningar om det finns motsägelser i emottagen data,

- automatiskt generera och sända bekräftelsemeddelanden på tillämpningsnivån.

4.2.7.2. Ett bekräftelsemeddelande [logiskt bekräftelse- (LAM), godkännande- (ACP) eller avvakta- (SBY) meddelande] skall genereras och sändas när motsvarande meddelande har behandlats och presentationen till berörd(a) arbetsstation(er) av resultaten av behandlingen har säkerställts.ANMÄRKNING

De detaljerade förhållandena för genererandet av en bekräftelse anges individuellt för varje meddelande.

4.3. Uppdatering från övervakningsdata

Rekommendation

För att säkerställa noggrannheten för data med beräknad tid, skall information från bevakning av flygningar med hjälp av radar eller annan övervakningsfunktion användas för att uppdatera databasen för färdplaner.

4.4. Registrering av OLDI-data

4.4.1. Innehåll

Innehållet i alla OLDI-meddelanden samt mottagningstiden skall registreras.

4.4.2. Installationer

Installationer skall finnas tillgängliga för inhämtning och visning av registrerad data.

4.5. Tillgänglighet, tillförlitlighet, datasäkerhet och dataintegritet

4.5.1. Tillgänglighet

4.5.1.1. OLDI-installationen skall vara tillgänglig under tider då trafikflödet mellan de två berörda enheterna är normalt och under högtrafik.

4.5.1.2. Rekommendation

OLDI-installationen bör vara tillgänglig 24 timmar dagligen.

4.5.1.3. Varje planlagd nedstängningsperiod (och således den planerade tillgänglighetstiden) skall vara överenskommen bilateralt mellan de två berörda enheterna.

4.5.2. Tillförlitlighet

4.5.2.1. Tillförlitligheten i alla OLDI-förbindelser skall vara minst 99,86 % (motsvarande en nedstängningstid som inte överstiger 12 timmar per år baserat på 24-timmars tillgänglighet.)

4.5.2.2. Rekommendation

När det är motiverat ur operativ synpunkt, bör en tillgänglighet av minst 99,99 % tillhandahållas (motsvarande en nedstängningstid som inte överstiger 52 minuter per år baserat på 24-timmars tillgänglighet).

4.5.3. Datasäkerhet

Rekommendation

Metoder för datasäkerhet (t.ex. användarrättigheter, källverifikation) och, där så är tillämpligt, nätverksadministration bör tillämpas för OLDI-installationer.

4.5.4. Dataintegritet

Felfrekvensen på tillämpningsnivå får inte överstiga ett sändningsfel per 2000 meddelanden.

4.6. Driftsutvärdering

4.6.1. Utvärderingsperiod

Varje ny OLDI-installation, inklusive en ny installation på en befintlig anslutning, skall innan den tas i bruk vara föremål för en utvärderingsperiod för bekräftelse av dataintegritet, noggrannhet, prestanda och kompatibilitet med ATC-förfarandena samt övergripande säkerhet.

ANMÄRKNING

Ett förfarande för att bistå i utvärderingen av ett nytt OLDI-system finns tillgängligt från OLDI-sekretariatet, Eurocontrol.

4.6.2. Operativt startdatum

Datumet för den operativa starten, som innebär att utvärderingsperioden fullbordas, skall vara formellt överenskommet mellan de två enheterna.

5. MEDDELANDEKATEGORIER

5.1. Allmänt

5.1.1. Syfte

Detta avsnitt av dokumentet

- definierar kategorier av meddelanden,

- anger kraven på transaktionstid för kategorierna,

- anger vilka meddelanden som är obligatoriska och vilka som är kompletterande,

- kategoriserar meddelandetyperna.

5.1.2. Meddelandekategorier

OLDI-meddelanden har tilldelats följande kategorier:

- Kategori 1: Kommunikationsöverföring.

- Kategori 2: Samordning.

- Kategori 3: Underrättelse.

5.2. Transaktionstider

5.2.1. Villkor för transaktionstider

5.2.1.1. De specificerade transaktionstiderna inkluderar sändning, inledande behandling vid mottagarenheten, sammanställning av bekräftelsemeddelandet, dess avsändande samt mottagandet hos överlämnande enhet. De automatiska bekräftelsemeddelandena, LAM och SBY, har därför inte tilldelats en meddelandekategori.

5.2.1.2. De maximala transaktionstiderna för de olika meddelandekategorierna skall vara de som anges i tabell 5-1.

Tabell 5-1

Maximala Transaktionstider

>Plats för tabell>

5.2.1.3. Ett värde på tidsbegränsning skall definieras per meddelandekategori eller typ.

5.2.1.4. Om ingen bekräftelse har emottagits inom den fastställda tiden efter sändning, skall ett meddelande bedömas vara otillfredsställande överfört eller behandlat, och en varning skall lämnas enligt specifikationerna i berört avsnitt av detta dokument.

5.2.1.5. Rekommendation

Värdena för tidsbegränsning för de tre kategorierna skall inte överskrida 12 sekunder, 30 sekunder respektive 60 sekunder.

5.3. Klassificering och kategorisering av meddelanden

5.3.1. Meddelandeklassificering - obligatoriska och kompletterande

5.3.1.1. Meddelanden som beskrivs i detta dokument klassificeras antingen som obligatoriska eller kompletterande.

5.3.1.2. När ett meddelande beskrivs som obligatoriskt (M) för sändning (TX) skall behandling inkluderas för att sådana meddelanden ska kunna sändas.

5.3.1.3. När ett meddelande beskrivs som obligatoriskt för mottagning (REC) skall behandling inkluderas för att mottagna meddelanden ska kunna behandlas.

ANMÄRKNING

I exceptionella fall, där trafikflödet mellan två enheter endast går i en riktning, kan de obligatoriska meddelandena vara tillämpbara i endast en riktning.

5.3.1.4. Då ett meddelande beskrivs som kompletterande (C) för sändning skall behandling inkluderas för att sådana meddelanden ska kunna sändas om så krävs av den sändande enheten och detta är bilateralt överenskommet med den mottagande enheten.ANMÄRKNING

Kompletterande meddelanden kan endast användas i en riktning, beroende på operativa krav.

5.3.1.5. Då ett meddelande beskrivs som kompletterande för mottagning, skall behandling inkluderas för att mottagna meddelanden ska kunna behandlas där sådan användning är bilateralt överenskommen.

5.3.1.6. Kraven som beskrivs i tabellerna 5-3 och 5-4 gäller endast då respektive användande av dialogförfaranden för samordning och/eller överföring av kommunikationen har överenskommits bilateralt mellan ATC-enheter.

5.3.2. Kategorisering av meddelanden

5.3.2.1. Kategoriseringen av meddelanden för det grundläggande förfarandet är specificerad i tabell 5-2.

5.3.2.2. Kategoriseringen av de extra samordningsmeddelandena för dialogförfarandet är specificerad i tabell 5-3.

5.3.2.3. Kategoriseringen av meddelanden för kommunikationsöverföring för dialogförfarandet är specificerad i tabell 5-4.

Tabell 5-2

Grundläggande förfarandemeddelanden

>Plats för tabell>

Tabell 5-3

Dialogförfarande - samordningsfasmeddelanden

(Tillägg till tabell 5-2)

>Plats för tabell>

Tabell 5-4

Dialogförfarande - överföringsfasmeddelanden

>Plats för tabell>

6. GRUNDLÄGGANDE FÖRFARANDEN - OBLIGATORISKA MEDDELANDEN

6.1. Allmänt

6.1.1. Kravbeskrivning

Detta avsnitt beskriver minimikraven vid tillämpningsnivån för genomförandet av OLDI-installationer.

6.1.2. Genomförande

Enheter som använder OLDI för samordning av flygningar skall införa ABI, ACT, och LAM så som beskrivs i detta avsnitt, förutom vid en bilateral överenskommelse om att använda dialogförfarandet för samordning så som beskrivs i avsnitt 8 i detta dokument, i vilket fall villkoren för användandet av ACT- och LAM-meddelanden definieras i det avsnittet.

6.2. Förhandsmeddelande - gränsinformation (ABI)

6.2.1. Syfte med ABI-meddelandet

ABI möter följande operativa krav:

- Möjliggör förvärv av saknad färdplansdata.

- Tillhandahåller i förhand gränsinformation och ändringar till densamma för nästa ATC-enhet.

- Uppdaterar grundläggande färdplansdata.

- Underlättar tidig samordning av radarspårning.

- Underlättar noggrann kortsiktig uppskattning av sektorbelastning.

ABI är ett underrättelsemeddelande.

6.2.2. Meddelandeinnehåll

ABI-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Flygplansidentifiering.

- SSR-läge och -kod (om tillgängligt).

- Startflygplats.

- Beräknad data.

- Landningsflygplats.

- Antal och typ av flygplan.

- Flygväg (valfritt).

- Annan färdplansdata (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

6.2.3. Tillämpningsregler

6.2.3.1. Allmänt

6.2.3.1.1. Förutom vad som anges i 6.2.3.1.3 och 6.2.3.1.4 nedan, skall ett eller flera ABI-meddelanden sändas för varje flygning som är planerad att korsa gränsen mellan ansvarsområden som är berörda av OLDI-förfaranden.

6.2.3.1.2. När det sänds, skall ABI-meddelandet föregå aktiveringsmeddelandet (ACT) eller remitterat aktiveringsförslag (RAP).

6.2.3.1.3. Ett ABI-meddelande skall inte genereras om ett preliminärt aktiveringsmeddelande (PAC) skall sändas.

6.2.3.1.4. Rekommendation

ABI-sändning bör förhindras om ACT- eller RAP-meddelande skall sändas omedelbart eller inom bilateralt överenskommet tidsintervall.ANMÄRKNING

Syftet med denna rekommendation är att undvika samtidiga försök till utredningar av avvikelser vid olika stationer hos den mottagande enheten beträffande ABI- och ACT-meddelanden för samma flygning.

6.2.3.1.5. Ett ändrat ABI-meddelande skall sändas om det efterföljande ACT-meddelandet inte har genererats och

- flygvägen har ändrats så att COP i det föregående ABI-meddelandet inte längre är korrekt,

- landningsflygplats har ändrats,

eller

- flygplanstypen har ändrats.

6.2.3.1.6. Rekommendation

Ett ändrat ABI-meddelande bör sändas om det efterföljande ACT-meddelandet inte har genererats och en av följande punkter ändras:

- Den beräknade nivån vid gränskorsningen.

- Den förväntade SSR-koden vid kontrollöverföringspunkten.

- När beräknad "time over" (ETO) vid COP avviker från det tidigare ABI-meddelandet med mer än den tid som specificerats i den skriftliga överenskommelsen (LoA).

- All annan data som berörs av bilateral överenskommelse.

6.2.3.2. Behandling hos den mottagande enheten

6.2.3.2.1. Det ATC-system som emottar ett ABI-meddelande skall försöka ansluta till motsvarande färdplansdata.

6.2.3.2.2. Om det inte gick att upprätta en anslutning till färdplanen, skall en färdplan skapas automatiskt eller manuellt i det mottagande systemet.

6.2.3.2.3. Om det gick att upprätta en anslutning till färdplanen, men en avvikelse noteras mellan data i meddelandet och motsvarande data i det mottagande systemet, vilket skulle resultera i behovet av en korrigerande åtgärd vid mottagandet av efterföljande ACT-meddelande, skall avvikelsen överlämnas till lämplig befattningshavare för tillrättaläggande.

6.2.3.3. Tidsparametrar för sändning

6.2.3.3.1. Meddelandet skall sändas inom en tidsparameter, i minuter, före beräknad tid vid COP.

6.2.3.3.2. Parametern (parametrarna) för genererandet av ABI skall ingå i LoA mellan berörda ATC-enheter.

6.2.3.3.3. Rekommendation

Parametern(parametrarna) för genererandet av ABI bör vara

- variabla, baserat på villkoren i LoA,

- definierade separat för varje COP.

6.2.4. Bekräftelse på ett ABI

6.2.4.1. Bekräftelse

ABI-meddelandet skall bekräftas genom genererandet och sändningen av ett LAM-meddelande.

ANMÄRKNING

Ett LAM-meddelande genereras oavsett resultatet av försöket att ansluta till färdplanen.

6.2.4.2. Ingen bekräftelse

Rekommendation

Om inget LAM-meddelande tas emot som bekräftelse på ett ABI-meddelande, skall en varning visas hos en övervakande befattningshavare.

6.2.5. Exempel

"Air 2000" 253, en Boeing 757 från Malta till Birmingham beräknad BNE VOR vid 1221 UTC, flyger på FL350 med verklig fart på 480 knop, planerad att gå via UB4 BNE UB4 BPK UB3 HON, transponder på A7012 och begär FL390. Följande är överensstämmande exempel på ABI meddelandet sänt från Reims till Londons 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. Aktiveringsmeddelande (ACT)

6.3.1. Syfte med aktiveringsmeddelandet

ACT-meddelandet uppfyller följande operativa krav:

- Ersätter den muntliga gränsuppskattningen genom att automatiskt sända detaljer om en flygning från en ATC-enhet till nästa innan överföringen av kontrollen äger rum.

- Uppdaterar grundläggande färdplansdata hos den övertagande ATC-enheten med den senaste informationen.

- Underlätta distribution och visning av färdplansdata till berörda arbetsstationer inom den övertagande ATC-enheten.

- Påskynda visning av callsign/kod-förhållandet i den övertagande ATC-enheten.

- Förse den övertagande ATC-enheten med information om förhållandena för överföring.

6.3.2. Meddelandeinnehåll

ACT-meddelandet skall innehålla följande informationsdata:

- Meddelandetyp.

- Meddelandenummer.

- Flygplansidentifiering.

- SSR-läge och -kod.

- Startflygplats.

- Beräknad data.

- Landningsflygplats.

- Antal och typ av flygplan.

- Flygväg (valfritt).

- Annan färdplansdata (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

6.3.3. Tillämpningsregler

6.3.3.1. Allmänt

6.3.3.1.1. Ett ACT-meddelande skall sändas för berättigade flygningar som korsar gränsen, förutom vad som sägs i punkt.

6.3.3.1.2. ACT-meddelandet skall genereras och sändas automatiskt på beräknad tid såsom specificerats i den skriftliga överenskommelsen, om det inte har initierats manuellt vid ett tidigare tillfälle.

6.3.3.1.3. Rekommendation

ATC-personal bör förses med en möjlighet att utlösa sändningen av ett ACT-meddelande före den beräknade tiden för sändning.

6.3.3.1.4. Det operativa innehållet i ett ACT-meddelande som skall sändas skall visas vid arbetsstationen med ansvar för samordningen av flygningen, före den faktiska sändningen.

6.3.3.1.5. Rekommendation

Beträffande 6.3.3.1.4, gäller att tidpunkten vid vilken det beräknas att ACT-meddelandet automatiskt skall sändas bör visas tillsammans med dess innehåll.

6.3.3.1.6. ACT-meddelandet skall innehålla den senaste informationen för flygningen, återspeglande de förväntade utträdesförhållandena.

6.3.3.1.7. Den berörda arbetsstationen skall underrättas om sändningen av ACT-meddelandet.

6.3.3.1.8. Så snart ett LAM har mottagits, blir datan i ACT-meddelandet operativt bindande för båda ATC-enheterna. De samordnade överföringsförhållandena och det faktum att ett LAM har emottagits skall presenteras för ATC-personalen vid den överlämnande enheten.

6.3.3.1.9. Godkännande av överföringsförhållandena, som framgår av ACT-meddelandet, skall ske av den mottagande enheten, om inte den mottagande enheten initierar samordning för att ändra dessa.

6.3.3.1.10. Ytterligare ett ACT-meddelande får endast sändas till samma samordningspartner om det tidigare har upphävts genom användandet av ett MAC.

6.3.3.1.11. Flygväg och annan färdplansdata skall inkluderas om så är bilateralt överenskommet.

6.3.3.2. Behandling i den mottagande enheten

6.3.3.2.1. Det ATC-system som tar emot ett ACT-meddelande skall försöka ansluta till den berörda färdplanen.

6.3.3.2.2. Om berörd färdplan påträffas och inga avvikelser förekommer i meddelandet som skulle förhindra korrekt behandling skall

- det operativa innehållet inkluderas i färdplanen,

- erforderlig data föras ut till operativ ATC och andra tillämpliga stationer,

- ett LAM återsändas.

6.3.3.2.3. Om berörd färdplan inte kan påträffas, eller om en avvikelse som förhindrar korrekt behandling av meddelandet påträffas skall,

- om sektorn ansvarig för att acceptera kontroll över flygningen kan identifieras,

- det operativa innehållet i meddelandet visas vid sektorn,

- ett LAM återsändas,

- en färdplan skapas,

- i alla övriga fall skall ett LAM inte återsändas.

6.3.3.3. Sändningsparametrar

6.3.3.3.1. Meddelandet skall sändas vid eller så snart som möjligt efter den första av de tidpunkter som fastställs enligt följande:

- En tidsparameter, i minuter, före den beräknade tiden vid COP.

- Tidpunkten vid vilken flygningen befinner sig på ett bilateralt överenskommet avstånd från COP.

6.3.3.3.2. Parametern (parametrarna) för genererandet av ACT skall vara inkluderade i LoA mellan berörda ATC-enheter.

6.3.3.3.3. Parametern (parametrarna) för genererandet av ACT skall vara variabel (variabla) baserat på villkoren i den skriftliga överenskommelsen.

6.3.3.3.4. Rekommendation

Parametrar för genererande av ACT bör definieras separat för varje COP.

6.3.3.3.5. De fastställda parametrarna skall ge tillräckligt med tid för

- den sändande enheten att uppdatera flygnivån vid överföringen till att återspegla de förväntade förhållandena vid COP,

och

- den mottagande enheten att behandla ACT-meddelandet och att generera samt sända ett LAM men ändå ge utrymme för genomförande av muntlig samordning från den överlämnande enheten och resulterande åtgärder initierade av den mottagande enheten om utbytet av data misslyckas.

6.3.4. Bekräftelse av ett ACT

6.3.4.1. Bekräftelse

ACT-meddelandet skall bekräftas genom genererandet och sändandet av ett LAM-meddelande.

6.3.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som bekräftelse på ett ACT-meddelande, skall en varning visas vid den ATC-station som har ansvaret för samordningen av flygningen.

6.3.5. Exempel

De följande exemplen är en utvidgning av de som getts för ABI-meddelanden i punkt 6.2. Alla detaljer är desamma förutom ETO vid COP, vilken är 1226 i ACT-meddelandet som visas.

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. Logiskt bekräftelsemeddelande (LAM)

6.4.1. Syfte med LAM-meddelandet

LAM är den metod genom vilken mottagandet och skyddet av ett sänt meddelande påvisas för den sändande enheten från den mottagande enheten.

LAM-förfarandet förser ATC-personal vid den överlämnande enheten med följande:

- En varning när ingen bekräftelse har emottagits.

- En anvisning om att meddelandet som bekräftas har mottagits, behandlats problemfritt, befunnits vara fritt från fel, sparats och, om detta är relevant, finns tillgängligt för presentation till berörd(a) arbetsstation(er).

6.4.2. Meddelandeinnehåll

LAM-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens.

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

6.4.3. Tillämpningsregler

6.4.3.1. Allmänt

6.4.3.1.1. Reglerna för återsändande av ett LAM beskrivs i avsnitten om behandling av respektive meddelande i detta dokument.

6.4.3.1.2. LAM-meddelandet skall genereras och sändas utan mänsklig inblandning.

6.4.3.1.3. LAM-meddelandet skall inte användas för att undvika behovet av tekniska meddelanden för att säkerställa integriteten vid dataöverföringar.

6.4.3.1.4. LAM-meddelandet skall genereras och sändas omgående så att kravet på sändningstid för meddelandet som bekräftas kan mötas.

6.4.3.1.5. Med undantag av ABI-meddelanden, skall det sändande ATC-systemet informera den flygledare som är ansvarig för samordningen om ett LAM-meddelande inte har emottagits inom den tidsparameter som är fastställd för sådana varningar.

6.4.4. Bekräftelse av ett LAM

LAM-meddelandet skall inte kräva någon bekräftelse.

6.4.5. Exempel

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ÄGGANDE FÖRFARANDE - KOMPLETTERANDE MEDDELANDEN

7.1. Allmänt

7.1.1. Kravbeskrivning

Detta avsnitt beskriver ytterligare funktioner som kan tillämpas vid de grundläggande förfarandena, utöver de som beskrivits i avsnitt 6, Grundläggande förfaranden - Obligatoriska meddelanden.

7.1.2. Genomförande

7.1.2.1. Innan någon av de funktioner som beskrivs i detta avsnitt börjar användas, skall en bilateral överenskommelse träffas.

7.1.2.2. Då överenskommelse om sådan användning har träffats, skall reglerna som beskrivs i detta avsnitt gälla.

7.2. Preliminärt aktiveringsmeddelande (PAC)

7.2.1. Syfte med PAC-meddelandet

PAC-meddelandet möter följande operativa krav:

- Underrättelse och samordning före avgång av en flygning, då flygtiden från avgång till COP är mindre än vad som krävs för att uppfylla de överenskomna tidsparametrarna för sändande av ACT-meddelande.

- Underrättelse och samordning före avgång av en flygning mellan en lokal (flygplats-/inflygningskontroll-)enhet och nästa enhet som skall ta kontroll över flygningen.

- Ger möjlighet att erhålla saknad färdplansdata om avvikelser förekommer i den ursprungliga distributionen av färdplansdata.

- Begär tilldelning av en SSR-kod från den enhet till vilken ovanstående underrättelse/samordning har skickats, om så erfordras.

7.2.2. Meddelandeinnehåll

PAC-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens (valfritt).

- Flygplansidentifiering.

- SSR-läge och -kod.

- Startflygplats.

- Beräknad starttid eller beräknad data.

- Landningsflygplats.

- Flygplanstyp.

- Flygväg (valfritt).

- Annan färdplansdata (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

7.2.3. Tillämpningsregler

7.2.3.1. Allmänt

7.2.3.1.1. Ett eller flera PAC-meddelanden skall sändas för varje flygning som är planerad att korsa gränsen för ansvarsområden då tiden från avgång till COP inte skulle tillåta ACT-meddelandet att sändas vid erforderlig tidpunkt.

7.2.3.1.2. Ett eller flera PAC-meddelanden skall sändas av enheten för flygplats-/inflygningskontroll till nästa enhet för varje avgående flygning där antingen underrättelse eller samordning krävs.

7.2.3.1.3. Rekommendation

För genomförandet av PAC/LAM mellan enheter, bör TWR/APP-systemet i fråga förses med möjligheter att registrera och sända "start-up", "push-back", "taxi" eller liknande information från vilken ETOT kan härledas för beräkning av ETO vid COP samt initiering av sändandet av PAC.

7.2.3.1.4. Enligt bilateral överenskommelse skall meddelandet innehålla antingen

- beräknad starttid,

eller

- beräknad data.

7.2.3.1.5. När meddelandereferensen ingår skall den, enligt bilateral överenskommelse,

- innehålla meddelandenumret på det första PAC-meddelandet som skickats för flygningen,

- inkluderas i andra och efterföljande PAC-meddelanden.

7.2.3.1.6. Användandet av funktionen kodbegäran, om sådan erfordras, skall vara bilateralt överenskommet.

7.2.3.1.7. Ett ändrat PAC-meddelande skall sändas om något av följande förhållanden råder före avgång:

- Flygvägen har ändrats så att COP i tidigare meddelande ej längre är korrekt.

- Flygplanstypen har ändrats.

- Landningsflygplatsen i föregående PAC har befunnits vara fel.

7.2.3.1.8. Rekommendation

Ett ändrat PAC-meddelande bör sändas om, före avgång, följande data avviker från datan i det föregående PAC-meddelandet:

- Nivån (i beräknad data, om befintlig).

- Den förväntade SSR-koden vid punkten för kontrollöverföring.

- Den beräknade starttiden eller ETO vid COP i tid överstiger ett bilateralt överenskommet värde.

- Det förekommer ändring av någon annan data som är bilateralt överenskommen.

7.2.3.2. Behandling i den mottagande enheten

7.2.3.2.1. Det ATC-system som tar emot ett ACT-meddelande skall försöka ansluta till den berörda färdplanen.

7.2.3.2.2. Om en berörd färdplan påträffas och inga avvikelser förekommer i meddelandet som skulle förhindra korrekt behandling skall

- det operativa innehållet inkluderas i färdplanen,

- erforderlig data föras ut till operativ ATC och andra tillämpliga stationer,

- ett LAM återsändas.

7.2.3.2.3. Om en berörd färdplan inte kan påträffas, eller om en avvikelse som förhindrar korrekt behandling av meddelandet påträffas skall,

- om sektorn ansvarig för att acceptera kontroll över flygningen kan identifieras,

- det operativa innehållet i meddelandet visas vid sektorn,

- ett LAM återsändas,

- en färdplan skapas,

- i alla övriga fall skall ett LAM inte återsändas.

7.2.3.2.4. Datan i ett andra eller efterföljande PAC-meddelande skall ersätta datan i det föregående meddelandet.

7.2.3.2.5. Om PAC-meddelandet innehåller en begäran om tilldelning av en SSR-kod, och det är korrekt behandlingsbart enligt beskrivningen i punkt 7.2.3.2.2 ovan, skall ett COD-meddelande återsändas utöver LAM.ANMÄRKNING

Eftersom processen för kodtilldelning kräver detaljerad flygvägsinformation från färdplanen, ställs inga krav i detta dokument för återsändande av ett COD-meddelande från den mottagande enheten då sådan data kanske inte finns tillgänglig för flygningen. Detta förhindrar inte att ett meddelande återsänds under sådana omständigheter om en specifik lokal kapacitet finns och förfarandet är bilateralt överenskommet.

7.2.3.3. Tidsparametrar för sändning

En tidsparameter för sändning är inte tillämplig då meddelandet har sänts som ett resultat av ett manuellt infört meddelande som informerar om den omedelbart förestående avgången.

7.2.4. Bekräftelse av ett PAC

7.2.4.1. Bekräftelse

De meddelanden som skall sändas som svar på ett PAC-meddelande beskrivs i punkt 7.2.3.2 ovan.

7.2.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som bekräftelse på ett PAC-meddelande, skall en varning visas vid arbetsstationen hos den ATC-enhet som är ansvarig för samordning med nästa enhet.

7.2.4.3. Avsaknad av LAM

Vid de tillfällen då LAM ej mottagits skall muntlig samordning ske.

7.2.4.4. Avsaknad av COD-meddelande

7.2.4.4.1. Om inget COD-meddelande tas emot som svar på en kodbegäran, skall en varning visas vid berörd arbetsstation.

7.2.4.4.2. Då funktionen för kodbegäran skall användas, skall det värde på avbrottstid som används vara bilateralt överenskommet.

7.2.5. Exempel

7.2.5.1. Beräknad starttid och kodbegäran

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 vid 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. Ändringsmeddelande (REV)

7.3.1. Syfte med ändringsmeddelandet

REV-meddelandet används för att sända ändringar i samordningsdata som tidigare avsänts i ett ACT-meddelande, under förutsättning att den mottagande enheten inte ändras som ett resultat av ändringen.

7.3.2. Meddelandeinnehåll

REV-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens (valfritt).

- Flygplansidentifiering.

- SSR-läge och -kod (valfritt).

- Startflygplats.

- Beräknad data.

- Samordningspunkt (valfritt).

- Landningsflygplats.

- Flygväg (valfritt).

- Annan färdplansdata (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

7.3.3. Tillämpningsregler

7.3.3.1. Allmänt

7.3.3.1.1. Ett eller flera REV-meddelanden kan sändas till den enhet till vilken samordningen av flygningen för tillfället är förlagd, genom användandet av ett aktiveringsmeddelande.

7.3.3.1.2. Följande element skall vara föremål för ändring:

- ETO vid COP.

- Överföringsnivå(er).

- SSR-kod.

7.3.3.1.3. Ett REV-meddelande skall sändas när

- ETO vid COP avviker från den i det tidigare meddelandet med mer än ett värde som är bilateralt överenskommet, avrundat till närmaste heltal,

- ändringar av överföringsnivå(erna) eller SSR-kod görs.

7.3.3.1.4. När det är bilateralt överenskommet, skall ett REV-meddelande sändas då det sker en förändring av följande:

- COP.

- Flygväg.

- Andra färdplansdata (ICAO fält 8, 10 och 18 data).

ANMÄRKNING

Operativa regler kan kräva att förändringarna utförda efter ACT skall vara föremål för tidigare samordning mellan berörda enheter.

7.3.3.1.5. När det är bilateralt överenskommet, skall meddelandereferensen ingå i REV-meddelandet.

7.3.3.1.6. Meddelandereferensen, då sådan är inkluderad, skall innehålla meddelandenumret på föregående ACT-meddelande.

7.3.3.1.7. Godkännande av överföringsförhållandena, som framgår av REV-meddelandet, skall ske av den mottagande enheten, om inte den mottagande enheten initierar samordning för att ändra dessa.

7.3.3.2. Format på ändringsmeddelanden

7.3.3.2.1. ICAO-format

Alla ändringsmeddelanden innehåller fälttyper 3, 7, 13, 14 och 16. Följande typer av ändringar kan användas inom dessa fält:

- En förändring av ETO vid COP eller överföringsnivå(er) skall införas genom att ändrad data förs in i fält 14.

- En förändring av SSR-koden skall införas i fält 7.

- Förändringar av flygvägen, inklusive förändringar av COP, skall införas i fält 14 och 15 med data i fält 22-format efter de fem första fälten. Sådana meddelanden skall innehålla två fält 14, det första endast innehållande element a), den COP genom vilken flygningen tidigare var samordnad. Regler för samordningen av sådana förändringar, inklusive direkta flygvägar, är specificerade i bilaga B, "Krav för behandling av speciella flygvägar".

- Ändringar i fält 8, 10 och 18 skall införas som fält 22 data efter de fem första fälten.

7.3.3.2.2. ADEXP-format

Alla ändringsmeddelanden i ADEXP-format skall innehålla följande primära fältfält: TITLE REFDATA ARCID ADEP ADES. Följande regler gäller:

- En förändring av ETO vid COP eller överföringsnivå(erna) skall göras genom att den ändrade datan förs in i primärt fält COORDATA.

- Flygvägsändringar, inklusive förändringar av COP, skall införas i primära fält COORDATA och ROUTE. Sådana meddelanden skall inkludera primärt fält COP innehållande samordningspunkten genom vilken flygningen tidigare hade samordnats för. Regler för samordningen av sådana förändringar, inklusive direkta flygvägar, är specificerade i bilaga B.

- En ändring av SSR-koden skall indikeras genom inkluderande av primärt fält SSRCODE.

- Förändringar av annan färdplansdata skall införas genom inkluderande av erforderligt primärt fält (primära fält) enligt definitionerna för annan färdplansdata in bilaga A.

Om ett ändringsmeddelande skickas för samordning av endast SSR-kod och/eller annan färdplansdata, skall det primära fältet COP ingå i stället för COORDATA.

7.3.3.2.3. SSR-kod

SSR-läge och -kod skall ingå i ett REV-meddelande endast då det krävs för att samordna en ändring av SSR-kod.

7.3.3.3. Behandling i den mottagande enheten

7.3.3.3.1. Om ett ACT har emottagits för berörd flygning från samma ATC-enhet, skall ATC-systemet som tar emot ett REV-meddelande försöka ansluta till den berörda färdplanen.

7.3.3.3.2. Om en motsvarande färdplan hittas, och ingen avvikelse som skulle förhindra behandlingen finns i meddelandet, skall

- det operativa innehållet inkluderas i färdplanen,

- erforderlig data föras ut till operativ ATC och andra tillämpliga stationer.

7.3.3.4. Initiering av sändning

7.3.3.4.1. REV-meddelandet är händelsestyrt och skall sändas omedelbart efter relevant inläsning eller uppdatering.

7.3.3.4.2. Inga ändringar får genomföras genom användandet av REV-meddelandet sedan flygningen befinner sig inom fastställd tidsrymd eller fastställt avstånd från överföringspunkten. Parametrarna för tid och avstånd skall vara bilateralt överenskomna.

7.3.3.4.3. Rekommendation

REV-parametrarna bör definieras separat för varje COP.

7.3.3.5. Förändring av mottagande ATC-enhet

REV-meddelandet skall inte användas om en ändring av färdplansdata leder till en förändring av den mottagande ATC-enheten (se Meddelande om upphävande av samordning).

7.3.4. Bekräftelse av ett REV

7.3.4.1. Bekräftelse

Om REV-meddelandet

- kan anslutas till en färdplan i det mottagande systemet skall ett LAM-meddelande sändas som bekräftelse,

- inte kan anslutas till en färdplan i det mottagande systemet skall ett LAM-meddelande inte sändas.

7.3.4.2. Tillfällen utan bekräftelse

7.3.4.2.1. Om inget LAM-meddelande tas emot som bekräftelse på ett REV-meddelande, skall en varning visas vid arbetsstationen hos den ATC-enhet som är ansvarig för samordning med nästa enhet.

7.3.4.2.2. Vid de tillfällen då LAM ej mottagits skall muntlig samordning ske

7.3.5. Exempel

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. Meddelande om upphävande av samordning (MAC)

7.4.1. Syfte med MAC-meddelandet

Ett MAC-meddelande används för att påvisa för till den mottagande enheten att samordningen eller underrättelse som tidigare berört en flygning upphävs.

MAC är inte en ersättning för ett annulleringsmeddelande (CNL), som det definieras av ICAO, och skall därför inte användas för att radera grundläggande färdplansdata.

7.4.2. Meddelandeinnehåll

MAC-meddelandet skall innehåla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens (valfritt).

- Flygplansidentifiering.

- Startflygplats.

- Samordningspunkt.

- Landningsflygplats.

- Samordningsstatus och anledning (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

7.4.3. Tillämpningsregler

7.4.3.1. Allmänt

7.4.3.1.1. Ett MAC-meddelande skall sändas till en enhet vid vilken samordning tidigare skett för en flygning, genom användandet av ett ACT- eller RAP-meddelande, när något av följande inträffar:

- Den förväntade nivån vid överföringspunkten är annorlunda än den nivå som angivits i föregående meddelande, vilket resulterar i en förändring av nästa enhet i samordningssekvensen.

- Flygvägen har ändrats vilket resulterar i förändring av nästa enhet i samordningssekvensen.

- Systemfärdplanen är annullerad i den sändande enheten och samordningen är inte längre relevant.

- Ett MAC tas emot från den föregående enheten kopplad till flygningen.

7.4.3.1.2. När MAC-meddelandet sänds på grund av en förändring av flygnivå eller flygväg, skall underrättelse och/eller samordning, vilket som är tillämpligt, upprättas med den nya enheten i samordningssekvensen.

7.4.3.1.3. Ett MAC-meddelande skall sändas när samordningen för en avgående flygning, påverkad av användandet av ett PAC-meddelande, är upphävd.

7.4.3.1.4. Rekommendation

Ett MAC-meddelande bör sändas när underrättelsen (ABI-meddelande) tidigare verkställd för en flygning är annullerad beroende på någon av orsakerna beskrivna i punkt 7.4.3.1.1 ovan, eller om flygningen är försenad under färden och en ändrad beräkning inte kan göras automatiskt.

7.4.3.1.5. En meddelandereferens skall inkluderas om så är bilateralt överenskommet.

7.4.3.1.6. Om den ingår, skall meddelandereferensen innehålla meddelandenumret för det senaste ABI-, PAC- eller ACT-meddelandet sänt och bekräftat för flygningen.

7.4.3.1.7. Samordningspunkten skall vara den COP genom vilken flygningen tidigare hade underrättats om eller samordnats.

7.4.3.1.8. Rekommendation

MAC-meddelandet bör identifiera den status till vilken samordningen eller underrättelsen skall återgå samt orsaken till upphävandet.

7.4.3.1.9. Om inkluderad, skall statusen och anledningen vara en av följande kombinationer:

- När den mottagande enheten ej längre är nästa samordningspartner.

- Statusen är INI (initial).

- Anledningen är en av följande:

- TFL om anledningen är en förändring av överföringsnivån.

- RTE om anledningen är en förändring av flygvägen.

- CSN om anledningen är en förändring av callsign.

- CAN om anledningen är en annullering.

- OTH för alla andra anledningar eller om orsaken är okänd.

- Om ett av följande villkor föreligger:

- Samordningen effektuerad genom användandet av det föregående PAC- eller ACT-meddelandet (så som det ändrats genom efterföljande REV-meddelande) är upphävt men flygningen förväntas bli föremål för en ny samordningssekvens med samma enhet.

- Efter sändandet av ett ABI-meddelande väntar flygningen under en obestämd tidsperiod och förväntas vara föremål för en ändrad ABI eller ACT, vilket som är tillämpligt.

- Statusen är NTF (underrättelse).

- Anledningen är en av följande:

- DLY om orsaken är en försening.

- HLD om orsaken är väntan.

- OTH för alla andra orsaker, eller om orsaken är okänd.

7.4.3.1.10. Om ny underrättelse skall ske eller ny samordning skall göras för flygningen, skall

- ett nytt underrättelse- och/eller samordningsmeddelande, vilket som är tillämpligt, sändas,

- grundläggande färdplansdata hos den mottagande ATC-enheten inte påverkas av ett MAC-meddelande,

- systemet bibehålla förmågan att korrekt behandla ett nytt underrättelse- och/eller samordningsmeddelande från antingen den tidigare överlämnande enheten eller en annan enhet i den nya samordningssekvensen.

7.4.3.2. Behandling i den mottagande enheten

Arbetsstationen (-stationerna) i den mottagande ATC-enheten, som förses med färddetaljer skall meddelas om upphävandet.

7.4.4. Bekräftelse av ett MAC

7.4.4.1. Bekräftelse

7.4.4.1.1. Om MAC-meddelandet kan anslutas till en färdplan i det mottagande systemet och kan behandlas, skall ett AM-meddelande sändas som bekräftelse.

7.4.4.1.2. Om MAC-meddelandet inte kan anslutas till en färdplan i det mottagande systemet, skall ett LAM-meddelande inte sändas.

7.4.4.2. Tillfällen utan bekräftelse

7.4.4.2.1. Om ATC-samordning upphävts och inget LAM-meddelande mottagits, skall en varning visas vid den ATC-station som ansvarar för samordningen.

7.4.4.2.2. I sådana fall skall muntligt upphävande av samordning utfärdas av den överlämnande ATC-enheten.

7.4.5. Exempel

Ett ABI-meddelande skickades från Amsterdams ACC till Bryssels ACC för flygning HOZ3188, planerad för FL190; flygningen begär senare tillstånd att få stiga till FL270 och tillstånd till detta erhålls, varvid man kommer in i Maastrichts luftrum istället för Bryssels. Exempel 7.4.5.1 a och 7.4.5.2 a visar hur det MAC som sänds till Bryssel från Amsterdam skulle se ut i både ICAO- och ADEXP-format.

Ett ABI- och, senare, ett ACT-meddelande sänds till Maastricht, men några minuter innan COP nås, återvänder flygplanet till Amsterdams flygplats och färdplanen annulleras i den sändande enhetens system; ett MAC skickas till Maastricht som visas i exemplen (7.4.5.1 b and 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. Meddelande om tilldelning av SSR-kod (COD)

7.5.1. Syfte med COD-meddelandet

7.5.1.1. Metoden för tilldelning av koder för ursprungsregion -(ORCAM) tillhandahålls för att möjliggöra att en flygning kan svara på samma kod till efterföljande enheter inom ett deltagarområde. Om inte kodtilldelning sker centralt, t.ex. av en ACC, kan flygplatser komma att individuellt behöva tilldelas en uppsättning av specifika SSR-koder. Sådan tilldelning är ett slöseri med koder.

7.5.1.2. COD-meddelandet möter de operativa kraven på utfärdandet av en SSR-kod, läge A, av en flygtrafikledningsenhet till en annan för en specifik flygning när så begärs. En valfri funktion tillåter den utfärdande enheten att inkludera flygvägen om detta är bilateralt överenskommet.

7.5.2. Meddelandeinnehåll

COD-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens (valfritt).

- Flygplansidentifiering.

- SSR-läge och -kod

- Startflygplats.

- Landningsflygplats.

- Flygväg (valfritt).

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

7.5.3. Tillämpningsregler

7.5.3.1. Allmänt

7.5.3.1.1. Ett COD-meddelande skall genereras och sändas automatiskt som svar på en begäran om kodtilldelning erhållen inom ett meddelande.

7.5.3.1.2. SSR-koden skall vara den kod som tilldelats för flygningen.

7.5.3.1.3. Den godkända mättnadskoden, enligt specifikation i flygnavigeringsplanen för europeiska regionen (Air Navigation Plan for the European Region), skall användas om en specifik kod inte är tillgänglig.

7.5.3.1.4. Om det är bilateralt överenskommet, skall meddelandereferensen, som innehåller meddelandenumret på det meddelande till vilket COD-meddelandet är ett svar, ingå.

7.5.3.1.5. Flygvägen skall ingå om så är bilateralt överenskommet.

7.5.3.1.6. Den enhet som emottar COD-meddelandet skall acceptera SSR-koden.

7.5.3.2. Behandling i mottagande enhet

7.5.3.2.1. Förutsatt att det inte föreligger någon avvikelse i meddelandet som förhindrar korrekt behandling, skall ett LAM återsändas.

7.5.3.2.2. Om inte meddelandet kan anslutas till en färdplan eller om det förekommer en avvikelse som förhindrar korrekt behandling av meddelandet, skall inte ett LAM återsändas.

7.5.3.2.3. Flygvägsdata, om sådan ingår, skall inte vara en anledning till att återsändandet av ett LAM förhindras, annat än i det fall den inte möter de formatkrav som angivits i bilaga A.

7.5.3.3. Tidsparametrar för sändning

En tidsparameter för sändning skall inte vara tillämplig, eftersom COD-meddelandet har skickats som ett resultat av mottagandet av ett meddelande med begäran om tilldelning av en SSR-kod.

7.5.4. Bekräftelse av ett COD

7.5.4.1. Bekräftelse

COD-meddelandet skall bekräftas genom genererandet och sändandet av ett LAM-meddelande.

7.5.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som en bekräftelse på ett COD-meddelande, skall en varning visas vid lämplig station.

7.5.5. Exempel

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

7.6.1. Syfte med INF-meddelandet

7.6.1.1. INF-meddelandet används för att tillhandahålla information om specifika flygningar till organ som inte är direkt inblandade i samordningsprocessen mellan två efterföljande ATC-enheter längs flygvägen.

7.6.1.2. INF-meddelandet kan användas för att tillhandahålla kopior av meddelanden och för att meddela överenskomna samordningsförhållanden till sådana organ efter en dialog mellan flygledare. I detta syfte kan INF-meddelanden genereras av systemen vid den överlämnande eller mottagande enheten.

7.6.1.3. Meddelandet kan även användas för att lämna information rörande vilken som helst av punkterna längs flygvägen till ett organ.

7.6.1.4. Formatet medger kommunikation av ursprungsdata, ändringar och annulleringar.

7.6.2. Meddelandeinnehåll

INF-meddelandet skall innehålla följande data i det meddelandeformat som beskrivs i detta dokument:

- Meddelandetyp.

- Meddelandenummer.

- All operativ data som ingick i det ursprungliga meddelandet eller kopiering av resulterande samordning.

- Hänvisad meddelandetyp.

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

7.6.3. Tillämpningsregler

7.6.3.1. Meddelandetyper

Typen (typerna) av meddelande(n) som skall dupliceras genom INF-meddelanden baseras på användares krav och sändande enhets kapacitet. Typ(er) av meddelande(n) och tillämpningsregler är i allmänhet bilateralt överenskomna.

7.6.3.2. Meddelandeadressater

Ett eller flera INF-meddelande(n) kan sändas för samma flygning till en eller flera adressater.

7.6.3.3. Operativt innehåll

Det operativa innehållet i INF-meddelandet skall vara i samma format som ett av de befintliga meddelandena.

7.6.3.4. Rekommendationer

1. Förhållanden framförda i ett ursprungligt dialogmeddelande (t.ex. ACT-, RAP-, REV- eller RRV-meddelande) kan ändras eller förkastas innan dialogen är slutförd. Avsändande enheter bör ha möjlighet att vidarebefordra de slutgiltigt överenskomna samordningsförhållandena.

2. INF-meddelandet bör sändas omedelbart, eller vid en tidpunkt i förhållande till tiden vid COP vilken har överenskommits bilateralt med det mottagande organet.

7.6.4. Bekräftelse av ett INF

Rekommendationer

1. INF-meddelandet kan bekräftas, beroende på samordningspartnern, genom genererandet och sändandet av ett LAM-meddelande.

2. Beroende på bilateral överenskommelse mellan berörda enheter, skall en varning visas vid en lämplig station om inget LAM-meddelande har emottagits som bekräftelse på ett INF-meddelande.

7.6.5. Exempel

En flygning med callsign BAW011, B747 från EGLL till OMDB vid FL290, begärande FL410, är beräknad Koksy (KOK) VOR vid 1905, sändande på A5437, fortsätter via UG1 och UB6.

Ett ACT-meddelande skickas av London till Maastricht för flygningen. En kopia skicka från London till en enhet identifierad som IT.

Det följande ger ett exempel på INF-meddelandet.

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. DIALOGFÖRFARANDEN - SAMORDNING

8.1. Allmänt

8.1.1. Inledning

8.1.1.1. Dialogförfarandet ger möjlighet till kommunikation och förhandlingar mellan trafikledare under samordningsfasen och för kommunikation i överföringsfasen.

8.1.1.2. Detta avsnitt beskriver meddelanden som används i dialogförfarandet under samordningsfasen där förhållandena för överföring planeras. De meddelanden som används för överföringsfasen, där överlämningen av flygningen sker, beskrivs i avsnitt 9, Dialogförfaranden - Överföring av kommunikationen.

8.1.1.3. Förfarandena för de två faserna är oberoende av varandra. De kan utföras individuellt eller tillsammans.

8.1.1.4. Ytterligare ett antal meddelanden har införts och möjligheten för endera partnern att initiera en dialog stöds.

8.1.1.5. Dialogförfarandet för samordning innebär att följande kan identifieras:

- Överföringar som överensstämmer med LoA och kan accepteras automatiskt.

- Överföringar som måste remitteras till flygledaren vid den mottagande enheten för ett beslut om godkännande.

8.1.1.6. Detta förfarande möjliggör även övervakning av tolkningen av skriftliga överenskommelser inom de två systemen, och identifiering av varje avvikelse mellan dessa.

8.1.2. Filtret

8.1.2.1. Allmänt

8.1.2.1.1. Dialogförfarandet för samordning kräver att systemen fastställer huruvida överföringarna överensstämmer med LoA eller ej.

8.1.2.1.2. Processen som kontrollerar att detta tillmötesgås, hänvisas till i detta dokument som "filtret". Databasen som används till filtret innehåller följande, om så erfordras:

- Överenskomna samordningspunkter.

- Tillåtna (eller otillåtna) flygnivåer som också kan vara associerade med samordningspunkterna.

- Startflygplatser.

- Destinationer.

- Överenskomna direkta flygvägar.

- Tids- och/eller avståndsgränser före COP, efter vilka alla samordningsmeddelanden betraktas som onormala.

- Alla andra förhållanden, enligt bilateral överenskommelse.

8.1.2.1.3. Alla punkter på denna lista kan kombineras för att definiera mer komplicerade förhållanden.

8.1.2.1.4. Inom avsnitt 8 i detta dokument, skall begreppet "normala förhållanden" tolkas som "i överensstämmelse med LoA" och begreppet "onormala förhållanden" som "ej i överensstämmelse med LoA". Om inte annat är bilateralt överenskommet, skall man för meddelanden som sänds av överlämnande enheter för samordningar som är normala, använda andra meddelandetyper än för samordningar där förhållandena är onormala.

8.1.2.2. Åtgärd i den överlämnande enheten

8.1.2.2.1. Filtret i den överlämnande enheten skall granska överföringsförhållandena som skall sändas till den accepterande enheten.

8.1.2.2.2. Rekommendation

Om överföringsförhållandena befinns vara onormala, bör den överlämnande flygledaren uppmärksammas på detta faktum för bekräftelse eller ändring.

8.1.2.3. Åtgärd i den accepterande enheten

8.1.2.3.1. Alla ACT- och REV-meddelanden skall kontrolleras gentemot filtret.

8.1.2.3.2. Om kontrollen indikerar att de mottagna överföringsförhållandena är onormala, skall dessa remitteras till flygledaren för ett beslut, annars kommer de att accepteras automatiskt.

8.1.2.4. Synkronisering av filtren

8.1.2.4.1. Användandet av olika meddelanden för normala och onormala överföringsförhållanden medger identifiering av alla avvikelser mellan normalförhållandena som de är inlästa i systemen hos den överlämnande och den accepterande enheten.

8.1.2.4.2. Identifieringen hos den accepterande enheten av onormala överföringsförhållanden i ett meddelande som används för att samordna endast normalöverföringar innebär att det finns en avvikelse mellan de två filtren. Sådana avvikelser bör lösas för att dialogförfarandet skall fungera effektivt.

8.1.3. Meddelandeföljd

8.1.3.1. Allmänt

8.1.3.1.1. Vissa regler måste följas för att säkerställa att samordningen är fullständig innan några ändringar sker eller utväxling av meddelanden om överföring av kommunikationen äger rum, och även för att säkerställa att flygledare vid båda enheterna inte samtidigt lämnar förslag till samma flygning.

8.1.3.1.2. En ATC-enhet skall endast sända eller bekräfta meddelande om mottagande av ändring (REV eller RRV) för en flygning då den befinner sig i det samordnade tillståndet, dvs. en ACT- eller RAP-dialog har avslutats med ett LAM eller ACP.

8.1.3.1.3. CDN-meddelanden skall endast tillåtas för sändningar av den accepterande enheten.

8.1.3.1.4. CDN-meddelanden skall endast sändas och bekräftas

- som del av dialogen initierad genom mottagandet av ett aktiverings- (ACT, RAP) eller ändrings- (REV eller RRV) meddelande, eller

- då färdplanen för den flygningen befinner sig i det samordnade tillståndet.

8.1.4. Samtidig meddelandehantering

8.1.4.1. Allmänt

8.1.4.1.1. En enhet som är inblandad i en samordning av en utväxling av samordnings- eller överföringsmeddelanden för en flygning skall inte initiera ytterligare ett samordnings- eller överföringsmeddelande för samma flygning med samma enhet förrän antingen ett LAM, ACP eller RJC har mottagits, eller en tidsbegränsning har uppnåtts.

8.1.4.1.2. Det är möjligt för ett CDN-meddelande och ett REV-, RRV- eller MAC-meddelande för samma flygning skickat från den överlämnande enheten att mötas korsvis under vägen. Denna situation kan identifieras vid den överlämnandeenheten genom att CDN inkommer före bekräftelsen för det sända meddelandet, och vid den accepterande enheten genom att meddelandet från den överlämnande enheten anländer före bekräftelsen av CDN. I detta fall skall inte CDN bekräftas och ej heller REV, RRV eller MAC behandlas.

8.1.5. Hantering av avslag

RJC-meddelandet avslutar en systemdialog. En ny systemsamordning som återspeglar telefonsamordningen måste initieras där så är tillämpligt.

8.1.6. Tidsbegränsning av operativt svar

8.1.6.1. Allmänt

8.1.6.1.1. Ett tidsbegränsningssystem skall tillämpas vid de sändande och mottagande centralerna för svaret på meddelanden som har remitterats till flygledaren.

8.1.6.1.2. Varaktigheten på dessa tidsbegränsningar skall vara bilateralt överenskommen.

8.1.6.1.3. Utgången av tidsbegränsningen vid den överlämnande enheten skall resultera i att en varning utfärdas till den överlämnande flygledaren, som en anvisning på behovet att påbörja samordning via telefon.

8.1.6.1.4. Rekommendationer

1. En varning bör visas vid ATC-stationen vid den accepterande enheten ansvarig för flygningen, när utgången av tidsbegränsningen i den överlämnande enheten är omedelbart förestående.

2. Varningen bör ta hänsyn till sändningstiden för svaret.

8.1.6.1.5. System skall kunna behandla svar som mottagits efter tidsbegränsningens utgång.

8.1.7. Genomförande

8.1.7.1. Dialogförfarandena berör två faser, nämligen samordningsfasen och överföringsfasen. Dialogen i de två faserna använder olika meddelanden och de erforderliga transaktionstiderna är olika. Samordningsmeddelandena är specificerade i ICAO- och ADEXP-format, meddelandena för överföring av kommunikationen endast i ADEXP.

8.1.7.2. HMI-minimikraven för samordningsdialogen skiljer sig från kraven för överföringsdialogen:

- Överföringsdialogen berör i första hand den verkställande kontrollfunktionen och kräver ett snabbt och användarvänligt HMI.

- Samordningsdialogen är inte lika tidskritisk och därför är dess HMI-krav lägre ställda.

8.1.7.3. Dialogförfarandet skall genomföras genom användandet av ett av följande alternativa scenarier:

- Dialogförfarande för samordningsfas och alla kompletterande meddelanden enligt bilateral överenskommelse (avsnitt 7 och 8).

- Grundläggande samordningsförfarande och dialogförfarande för överföring (avsnitt 6, 7 och 9).

- Förfarande för samordnings- och överföringsfas samt alla kompletterande samordningsmeddelanden enligt bilateral överenskommelse (avsnitt 7, 8 och 9).

Förhandsmeddelandet med gränsinformation skall sändas för alla scenarier.

8.1.7.4. Scenariot som används för genomförandet skall överenskommas bilateralt.

8.2. Aktiveringsmeddelande (ACT)

8.2.1. Syfte med ACT-meddelandet

Syftet med ACT-meddelandet beskrivs i punkt 6.3.1. I ett dialogförfarande används ACT-meddelandet för att möta dessa krav om överföringsförhållandena för flygningen är normala och den överlämnande flygledaren inte behöver hänvisa flygningen till den accepterande flygledaren för godkännande.

8.2.2. Meddelandeinnehåll

Innehållet i ett ACT-meddelande som används i dialogförfarandet skall överensstämma med beskrivningen för ACT-meddelanden i punkt 6.3.2.

8.2.3. Tillämpningsregler

8.2.3.1. Allmänt

8.2.3.1.1. Tillämpningsreglerna är desamma som de beskrivna för ACT i punkt 6.3, med undantag av de särskilda regler som beskrivs i denna punkt.

8.2.3.1.2. Ett ACT-meddelande skall sändas för en flygning med normala överföringsförhållanden som den överlämnande flygledaren inte behöver remittera till den mottagande flygledaren.ANMÄRKNING

Om dessa krav inte är tillämpliga, sänds ett RAP (se punkt 8.3, Meddelande med remitterat aktiveringsförslag).

8.2.3.1.3. Rekommendation

Ett nytt samordningsförfarande bör påbörjas om ett meddelande med avslag av samordning (RJC) återsändas som svar på ett ACT-meddelande.

8.2.3.2. Behandling i den mottagande enheten

8.2.3.2.1. Meddelandet kontrolleras mot filtret för att bekräfta att de föreslagna förhållandena är normala.

8.2.3.2.2. Meddelandet skall behandlas som ett RAP-meddelande om

- överföringsförhållandena befinns vara onormala,

- en motsvarande färdplan inte kan påträffas och det finns otillräckligt med information tillgänglig för att identifiera om överföringsvillkoren är normala eller ej.

8.2.3.2.3. Ett ACT-meddelande som befunnits vara normalt skall behandlas enligt punkt 6.3.3.2.

8.2.3.2.4. Rekommendation

Om överföringsförhållandena i ett ACT-meddelande befunnits vara onormala, finns en avvikelse mellan filtren i de två systemen. Det faktum att ett ACT är onormalt skall uppmärksammas för övervakande personal för att avvikelsen skall lösas.

8.2.4. Bekräftelse av ett ACT

8.2.4.1. Bekräftelse

8.2.4.1.1. I ett dialogförfarande skall ett ACT-meddelande bekräftas med

- ett LAM om överföringsförhållandena befunnits vara normala,

- ett SBY-meddelande i alla övriga fall.

8.2.4.1.2. När ett LAM har mottagits, skall det operativa innehållet i ACT-meddelandet bli operativt bindande för båda ATC-enheterna.

8.2.4.1.3. När det är bilateralt överenskommet, kan ett ACP användas av den accepterande enheten i stället för ett LAM för att ange godkännandet av ett ACT som innehåller normala överföringsförhållanden.

8.2.4.2. Tillfällen utan bekräftelse

Om ingen bekräftelse på ett ACT-meddelande tas emot, skall en varning visas vid den ATC-station som är ansvarig för samordningen av flygningen.

8.3. Meddelande med remitterat aktiveringsförslag (RAP)

8.3.1. Syfte med RAP-meddelandet

RAP-meddelandet möter följande operativa krav, utöver de som fastställts för ACT-meddelandet i punkt 6.3:

- Förslag från den överlämnande flygledaren och remiss till den mottagande flygledaren för flygningar där förhållandena är onormala.

- Möjliggör för den överlämnande flygledaren, om så erfordras, att tvångsremittera överföringsförhållandena för en bestämd flygning där normala förhållanden föreligger, till den mottagande flygledaren.

8.3.2. Meddelandeinnehåll

Innehållet i ett RAP-meddelande skall vara samma data som beskrivits för ACT-meddelandet (punkt 6.3), och kan valfritt innehålla följande data:

- Anledning, med anvisning om manuell remittering (endast tillgängligt i ADEXP).

8.3.3. Tillämpningsregler

8.3.3.1. Allmänt

8.3.3.1.1. Ett RAP-meddelande skall sändas i stället för ACT-meddelandet för flygningar som korsar gränsen och uppfyller ett av följande villkor:

- Det överlämnande systemet har konstaterat att överföringsförhållandena är onormala.

- Den överlämnande flygledaren har angivit att de föreslagna överföringsförhållandena skall remitteras till den mottagande flygledaren.

8.3.3.1.2. Det operativa innehållet i RAP-meddelandet som skall sändas, skall visas hos den befattningshavare som ansvarar för samordningen av flygningen, innan sändningen äger rum.

8.3.3.1.3. Rekommendation

Tidpunkten då RAP-meddelandet automatiskt sänts, bör visas tillsammans med meddelandets innehåll.

8.3.3.1.4. Berörd befattningshavare skall informeras om sändandet av RAP-meddelandet.

8.3.3.2. Behandling i den mottagande enheten

8.3.3.2.1. ATC-systemet som tar emot ett RAP-meddelande skall försöka ansluta till den berörda färdplanen.

8.3.3.2.2. Om en motsvarande färdplan påträffas och det inte förekommer någon avvikelse i meddelandet som skulle kunna förhindra korrekt behandling, skall

- det operativa innehållet remitteras till den mottagande flygledaren,

- ett SBY återsändas.

8.3.3.2.3. Rekommendation

En anvisning om anledningen till remitteringen (onormala förhållanden eller manuell remittering) bör inkluderas.

8.3.3.2.4. Om meddelandet inte kan kopplas till en färdplan, eller om en avvikelse påträffas som förhindrar korrekt behandling av meddelandet, skall

- det operativa innehållet i meddelandet visas vid sektorn

och

- ett SBY-meddelande återsändas

och

- en färdplan upprättas.

8.3.3.2.5. I alla andra fall skall meddelandet inte bekräftas.

8.3.3.3. Manuell aktivering

8.3.3.3.1. När ett RAP används för att tvångsremittera en föreslagen samordning med normala överföringsförhållanden till den mottagande flygledaren, initieras det manuellt av den överlämnande flygledaren och sänds omgående.

8.3.3.3.2. Rekommendation

Manuell aktivering av ett RAP-meddelande före den beräknade tidpunkten för sändning bör tillåtas vid den ATC-station som har ansvaret för samordningen av flygningen.

8.3.3.4. Tidsparametrar för automatisk sändning

Tiden/avståndet till gränsen, vid vilken RAP-meddelanden automatiskt sänds, skall vara samma som för ACT-meddelanden.

8.3.4. Bekräftelse av ett RAP

8.3.4.1. Bekräftelse

Meddelandet skall bekräftas genom genererandet och sändandet av ett SBY-meddelande.

8.3.4.2. Tillfällen utan bekräftelse

Om inget SBY-meddelande har mottagits som bekräftelse på ett RAP-meddelande, skall en varning visas vid den ATC-station som har ansvaret för samordningen av flygningen.

8.3.5. Operativt svar på ett RAP

Den mottagande flygledaren kan antingen acceptera, ge ett motförslag till eller avslå överföringsförhållandena.

8.3.5.1. Godkännande

8.3.5.1.1. När den mottagande flygledaren väljer att godkänna de föreslagna överföringsförhållandena, skall ett ACP-meddelande återsändas.

8.3.5.1.2. Så snart ACP-meddelandet har mottagits, blir RAP-meddelandet operativt bindande för båda ATC-enheterna. De samordnade överföringsförhållandena och det faktum att ett ACP har mottagits skall presenteras för den överlämnande flygledaren.

8.3.5.2. Motförslag

När den mottagande flygledaren väljer att presentera ett motförslag med överföringsförhållanden, skall ett CDN-meddelande återsändas.

8.3.5.3. Rekommendation

När den mottagande flygledaren väljer att avslå överföringsförhållandena, skall ett RJC-meddelande återsändas. Ett nytt samordningsförfarande bör därefter påbörjas.ANMÄRKNING

Beträffande rekommendationen i 8.3.5.3 sker den nya samordningen i de flesta fall med en annan enhet.

8.3.6. Exempel

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

8.4.1. Syfte med REV-meddelandet

Syftet med REV-meddelandet beskrivs i punkt 7.3.1. I ett dialogförfarande används REV-meddelandet för att möta dessa krav förutsatt att överföringsförhållandena för flygningen är normala och att den överlämnande flygledaren inte kräver att remittera flygningen till den mottagande flygledaren för godkännande.

8.4.2. Meddelandeinnehåll

Innehållet i REV-meddelandet skall vara som beskrivits för REV-meddelandet i punkt 7.3.2.

8.4.3. Tillämpningsregler

8.4.3.1. Allmänt

8.4.3.1.1. Ett eller flera REV-meddelanden kan sändas till den enhet med vilken en flygning för närvarande har samordnats, genom användandet av ett aktiverings- eller RAP-meddelande.

8.4.3.1.2. REV-meddelanden skall sändas under de förhållanden som angivits i punkt 7.3.3.1 för flygningar med normala överföringsförhållanden som den överlämnande flygledaren inte behöver remittera till den mottagande flygledaren.

8.4.3.2. Initiering av sändning

REV-meddelandet skall sändas omedelbart efter uppmärksammandet av en ändring av samordningsdata, vilket kräver en samordning enligt beskrivningen i punkt 7.3.3.

8.4.3.3. Behandling i den mottagande enheten

8.4.3.3.1. Om en motsvarande färdplan påträffas och det inte förekommer någon avvikelse i meddelandet som skulle kunna förhindra korrekt behandling

- skall REV-meddelandet bekräftas,

- i alla andra fall skall meddelandet inte bekräftas.

8.4.3.3.2. Överföringsförhållandena skall undersökas för att det skall kunna konstateras att de är normala.

8.4.3.3.3. Om överföringsförhållandena inte är normala skall de presenteras för den mottagande flygledaren.

8.4.3.3.4. Om de föreslagna överföringsförhållandena befunnits vara normala, skall de inkluderas i färdplanen och nödvändig datautlämning hos operativ ATC och andra tillämpliga stationer.

8.4.3.3.5. Rekommendation

Om överföringsförhållandena i ett ACT-meddelande befunnits vara onormala, är det en avvikelse mellan filtren i de två systemen. Det faktum att ett ACT är onormalt skall uppmärksammats för övervakande personal för att avvikelsen skall lösas.

8.4.4. Bekräftelse av ett REV

8.4.4.1. Bekräftelse

8.4.4.1.1. Om REV-meddelandet skall bekräftas, skall detta ske genom

- ett LAM-meddelande, om överföringsförhållandena befunnits vara normala,

- ett SBY-meddelande, om överföringsförhållandena befunnits vara onormala.

8.4.4.1.2. När ett LAM har mottagits blir det operativa innehållet i REV-meddelandet operativt bindande för de båda ATC-enheterna.

8.4.4.1.3. När det är bilateralt överenskommet, kan ett ACP användas i stället för ett LAM för att ange att den mottagande enheten godkänner mottagandet av ett REV som innehåller normala överföringsförhållanden.

8.4.4.2. Tillfällen utan bekräftelse

Om ingen bekräftelse på ett REV-meddelande tas emot, skall en varning visas vid den ATC-station som har ansvaret för samordningen av flygningen.

8.4.5. Operativt svar på ett REV

Eftersom REV-meddelandet används till att sända normala överföringsförhållanden, godkänns det normalt av systemet i den mottagande enheten. Om överföringsförhållandena befinns vara onormala av filtret i den mottagande enheten, skall meddelandet behandlas som ett RRV-meddelande.

8.5. Remitterat ändringsmeddelande (RRV)

8.5.1. Syfte med RRV-meddelandet

RRV-meddelandet skall medge ändring av tidigare sända och överenskomna överföringsvillkor i följande fall:

- När de föreslagna överföringsvillkoren är onormala.

- När de föreslagna överföringsvillkoren är normala, men den överlämnande flygledaren vill remittera ändringen till den mottagande flygledaren.

8.5.2. Meddelandeinnehåll

Innehållet i RRV-meddelandet skall vara som beskrivits för REV-meddelandet (punkt 7.3.2), och kan valfritt innehålla följande data:

- anledning, med anvisning om manuell remittering (endast tillgängligt i ADEXP).

8.5.3. Tillämpningsregler

8.5.3.1. Allmänt

Ett eller flera RRV-meddelanden skall sändas, i stället för REV-meddelanden, för varje ändring om antingen

- det överlämnande systemet har fastställt att överföringsförhållandena är onormala,

eller

- den överlämnande flygledaren har påpekat att de föreslagna överföringsförhållandena skall remitteras till den mottagande flygledaren. Denna användning av RRV är valfri.

8.5.3.2. Initiering av sändning

REV-meddelandet skall sändas omedelbart efter uppmärksammandet av en ändring av samordningsdata eller vid manuell initiering.

8.5.3.3. Behandling i den mottagande enheten

8.5.3.3.1. Om en motsvarande färdplan påträffas och det inte förekommer någon avvikelse i meddelandet som skulle kunna förhindra korrekt behandling

- skall RRV-meddelandet bekräftas,

- i alla andra fall skall meddelandet inte bekräftas.

8.5.3.3.2. De föreslagna överföringsförhållandena skall visas vid den ATC-station som ansvarar för samordningen av flygningen.

8.5.3.3.3. Rekommendation

En anvisning om anledningen till remitteringen (onormala förhållanden eller manuell remittering) bör inkluderas.

8.5.4. Bekräftelse av ett RRV

8.5.4.1. Bekräftelse

Meddelandet skall bekräftas genom genererandet och sändandet av ett SBY-meddelande.

8.5.4.2. Tillfällen utan bekräftelse

Om inget SBY-meddelande tas emot som bekräftelse på ett RRV-meddelande, skall en varning visas vid den ATC-station som har ansvaret för samordningen av flygningen.

8.5.5. Operativt svar på ett RRV

Den mottagande flygledaren kan antingen acceptera, ge ett motförslag till eller avslå ett RRV-meddelande.

8.5.5.1. Godkännande

När den mottagande flygledaren väljer att godkänna de föreslagna överföringsförhållandena, skall ett ACP-meddelande återsändas.

8.5.5.2. Motförslag

När den mottagande flygledaren väljer att presentera ett motförslag med överföringsförhållanden, skall ett CDN-meddelande återsändas.

8.5.5.3. Avslag

När den mottagande flygledaren väljer att avslå den föreslagna ändringen till de överenskomna överföringsförhållandena

- skall ett RJC-meddelande återsändas,

och

- ett nytt samordningsförfarande inledas.

Om varken ett ACP eller ett CDN har mottagits som svar på RRV-meddelandet har detta avslagits.

8.5.6. Exempel

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. Beredskapsmeddelande (SBY)

8.6.1. Syfte med SBY-meddelandet

SBY-meddelandet bekräftar mottagandet av ett meddelande med förslag till överföringsförhållanden, och påvisar att förslaget har remitterats till flygledaren för ett beslut.

8.6.2. Meddelandeinnehåll

SBY-meddelandet skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Meddelandereferens.

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

8.6.3. Tillämpningsregler

8.6.3.1. Allmänt

SBY-meddelandet skall genereras och sändas automatiskt som svar på

- ett RAP-, RRV- eller CDN-meddelande,

- ett ACT- eller REV-meddelande som inte godtas av filtret.

8.6.4. Bekräftande av ett SBY

SBY-meddelandet skall inte bekräftas.

8.6.5. Exempel

8.6.5.1. ICAO

(SBYL/E027E/L002)

8.6.5.2. ADEXP

-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002

8.7. Godkännandemeddelande (ACP)

8.7.1. Syfte med ACP-meddelandet

ACP-meddelandet uppfyller följande operativa krav under ATC- samordnings- och överföringsfasen:

- Att notera det manuella godkännandet från en flygledare i en enhet av överföringsförhållandena, som föreslagits av flygledaren i den andra enheten i ett av följande meddelanden:

- RAP

- RRV

- CDN

- ACT och REV, om någon av dem har befunnits vara onormal.

- Att, när det har överenskommits bilateralt, lämna det automatiska godkännandet av ett ACT- eller REV-meddelande som har passerat filtret i den mottagande enheten (i stället för LAM).

- Att, när det har överenskommits bilateralt, indikera det manuella godkännandet av ett HOP-meddelande (i stället för ROF-meddelandet).

8.7.2. Meddelandeinnehåll

ACP-meddelandet innehåller består av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- meddelandenummer,

- meddelandereferens.

- Valfri data - meddelandet kan även innehålla

- frekvens.

- Valfri data i meddelanden i ICAO-format - meddelandet kan även innehålla följande information:

- Flygplansidentifiering.

- Startflygplats.

- Landningsflygplats.

ANMÄRKNING

Regler för införande av data, format och fältinnehåll beskrivs i bilaga A.

8.7.3. Tillämpningsregler

8.7.3.1. Allmänt

8.7.3.1.1. Meddelandereferensen i ett ACP skall innefatta meddelandenumret på det meddelande som besvaras.

8.7.3.1.2. Frekvensfältet skall, när det finns medtaget, innehålla den frekvens som skall användas då flygningen skall kontakta den mottagande enheten vid överlämnandet.

8.7.3.1.3. ACP-meddelandet skall sändas efter manuellt godkännande från flygledaren av föreslagna överföringsförhållanden, översända genom ett ACT, RAP, REV, RRV eller CDN.

8.7.3.1.4. ACP-meddelandet kan sändas, som ett alternativ till ett ROF-meddelande, som svar på ett HOP-meddelande.

8.7.3.1.5. När det är bilateralt överenskommet, skall ACP-meddelandet genereras och sändas automatiskt av systemet som ett svar på ett ACT/REV som har passerat filtret.

8.7.3.1.6. När ett ACP har mottagits, skall de överenskomna överföringsförhållandena vara bindande för båda enheterna.

8.7.3.2. Behandling i den mottagande enheten

8.7.3.2.1. ATC-systemet som tar emot ett ACP-meddelande skall försöka ansluta till den berörda färdplanen.

8.7.3.2.2. Om ett ACP kan anslutas till en färdplan, skall godkännandet anges till flygledaren.

8.7.3.2.3. Om ett ACP inte kan anslutas till en färdplan

- skall en varning lämnas hos berörd befattningshavare, och

- ett LAM skall inte sändas.

8.7.4. Bekräftelse av ett ACP

8.7.4.1. Bekräftelse

8.7.4.1.1. Ett LAM skall inte återsändas då ett ACP används som ett automatiskt svar på ett ACT- eller REV-meddelande som har passerat filtret.

8.7.4.1.2. Ett ACP-meddelande som sänds till följd av ett manuellt godtagande skall bekräftas genom genererandet och sändandet av ett LAM-meddelande.

8.7.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som bekräftelse på ett ACP-meddelande, avsänt som bekräftelse på ett manuellt godkännande, skall en varning visas vid den ATC-station som har ansvaret för samordningen av flygningen

8.7.5. Exempel

8.7.5.1. ICAO

(ACPL/E027E/L002-18/FRQ/242150)

8.7.5.2. ADEXP

-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -FREQ 242150

8.8. Samordningsmeddelande (CDN)

8.8.1. Syfte med CDN-meddelandet

CDN-meddelandet möter följande operativa krav:

- Framför ett motförslag från den mottagande flygledaren till den överlämnande som svar på ett ACT-, RAP-, REV- eller RRV-meddelande.

- Påbörjar en föreslagen förändring av överenskomna överföringsförhållanden från den mottagande flygledaren till den överlämnande.

8.8.2. Meddelandeinnehåll

CDN-meddelandet består av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- meddelandenummer,

- meddelandereferens (endast vid svar på ett annat meddelande),

- flygplansidentifiering,

- startflygplats,

- landningsflygplats.

ANMÄRKNING

Meddelandet skall även innehålla ett eller båda av följande:

- Beräknad data (gäller ICAO-meddelanden) eller överföringsnivå (gäller ADEXP-meddelanden).

- Begäran om direktflygning.

- Bilateralt överenskommen data - följande data kan också ingå, om det är bilateralt överenskommet:

- Frekvens.

ANMÄRKNING

Regler för införande av data, format och fältinnehåll bes