Antagande av Eurocontrol-standarder

Avis juridique important

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 officiella tidning nr L 254 , 09/10/2000 s. 0001 - 0234

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 beskrivs i bilaga A.

8.8.3. Tillämpningsregler

8.8.3.1. Allmänt

8.8.3.1.1. CDN-meddelanden skall endast initieras av den mottagande flygledaren.

8.8.3.1.2. Det skall användas för att sända ett motförslag från den mottagande flygledaren till den överlämnande.ANMÄRKNING

Detta kan ske i en dialog som ett svar på ett förslag som framförts genom ett ACT, RAP, REV, eller RRV, eller som början på en dialog för att ändra tidigare överenskomna överföringsförhållanden.

8.8.3.1.3. Meddelandereferensen skall endast inkluderas då CDN-meddelandet skickas som svar på ett annat meddelande.

8.8.3.1.4. Om meddelandereferensen inkluderas, skall den innehålla meddelandenumret på meddelandet till vilket CDN är ett svar.

8.8.3.1.5. Tillämpningen av begäran om direktflygning (beskriven i detalj i bilaga A) skall

- endast användas om det har överenskommits bilateralt; och

- om överenskommet, beskriva alla dess operativa begränsningar.

8.8.3.1.6. Ett CDN får inte sändas efter det att en given tid eller distans före gränsen passerats, som fastställts i en LoA mellan de berörda enheterna,

8.8.3.1.7. Om ett CDN sänds samtidigt som ett meddelande, rörande samma flygning, från den överlämnande enheten, t.ex. en ändring eller upphävande av samordning, skall varken en bekräftelse eller ett operativt svar återsändas.ANMÄRKNING

Resultatet av detta är att när två meddelanden korsar varandra, har meddelandet från den överlämnande enheten företräde, och CDN-meddelandet utesluts av båda systemen. Båda enheterna kan uppmärksamma situationen i och med att meddelandet från den andra mottas innan bekräftelsen mottas.

8.8.3.1.8. Så fort en bekräftelse mottagits blir CDN-meddelandets data operativt bindande för båda ATC-enheterna. De samordnade överföringsförhållandena och det faktum att ACP-meddelandet har mottagits skall framföras till berörd ATC-personal.

8.8.3.2. Behandling i den mottagande enheten

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

- det operativa innehållet visas vid den ATC-station som har ansvaret för samordningen av flygningen,

och

- ett SBY återsändas.

8.8.3.2.2. Om CDN inte kan anslutas, eller om en avvikelse som förhindrar korrekt behandling av meddelandet påträffas, skall inget SBY återsändas.

8.8.4. Bekräftelse av ett CDN

8.8.4.1. Bekräftelse

Under ovan beskrivna förhållanden, skall CDN-meddelandet bekräftas genom genererandet och sändandet av ett SBY-meddelande.

8.8.4.2. Tillfällen utan bekräftelse

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

8.8.5. Operativt svar på ett CDN

Flygledaren kan antingen godkänna eller avslå de överföringsförhållanden som föreslås i ett CDN-meddelande.

8.8.5.1. Godkännande

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

8.8.5.2. Rekommendation

När den överlämnande flygledaren väljer att avslå de föreslagna överföringsförhållandena, bör ett RJC-meddelande återsändas (uttryckligt avslag).

ANMÄRKNING

Den föreslagna samordningen är uttryckligen avslagen om inget godkännande har mottagits innan tidsbegränsningen för CDN-meddelandet löpt ut.

8.8.6. Exempel

8.8.6.1. ICAO

(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -EBBR)

8.8.6.2. ADEXP

-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -PROPFL -TFL F270 -SFL F110A

8.9. Meddelande med avslag av samordning (RJC)

8.9.1. Syfte med RJC-meddelandet

RJC-meddelandet påvisar avslaget, från en flygledare vid en enhet, av de överföringsförhållanden som föreslagits av flygledaren vid den andra enheten, genom ett av följande meddelanden:

- RAP

- RRV

- CDN

- ACT och REV, om något av dessa befunnits vara onormalt.

RJC-meddelandet kan endast användas som direkt svar på ett av de ovanstående meddelandena.

8.9.2. Meddelandeinnehåll

RJC-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.9.3. Tillämpningsregler

8.9.3.1. Allmänt

8.9.3.1.1. Ett RJC skall sändas, när så erfordras, som svar på ett RAP-, RRV- eller CDN-meddelande eller som svar på ett ACT- eller REV-meddelande som den mottagande enheten befunnit vara onormalt.

8.9.3.1.2. RJC-meddelandet avslutar systemdialogen och all tidigare överenskommen samordning förblir gällande.

8.9.3.1.3. Rekommendation

Efter mottagandet av ett RJC-meddelande bör en ny samordningssekvens, som återspeglar telefonsamordningen om detta är tillämpligt, påbörjas.

8.9.3.2. Behandling i den mottagande enheten

8.9.3.2.1. Om ett meddelande som motsvarar en hänvisning i RJC-meddelandet påträffas, skall

- det operativa innehållet visas vid den ATC-station som har ansvaret för samordningen av flygningen, och

- ett LAM återsändas som bekräftelse.

8.9.3.2.2. Om inget sådant meddelande befinns vänta på svar, eller om en avvikelse som förhindrar behandling förekommer i meddelandet, skall ingen bekräftelse återsändas.

8.9.4. Bekräftelse av ett RJC

8.9.4.1. Bekräftelse

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

8.9.4.2. Tillfällen utan bekräftelse

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

8.9.5. Exempel

8.9.5.1. ICAO

(RJCMC/E746E/MC324)

8.9.5.2. ADEXP

-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E -SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC MC -SEQNUM 324

9. DIALOGFÖRFARANDE - KOMMUNIKATIONSÖVERFÖRING

9.1. Allmänt

9.1.1. Inledning

9.1.1.1. I detta avsnitt av standarden beskrivs de funktioner och meddelanden som stödjer radarhanteringen inom kontrollförfarandet. De skall genomföras där så har överenskommits bilateralt.

9.1.1.2. Funktionerna för kommunikationsöverföring skall inte införas om inte enheten använder sig antingen av de samordningsmöjligheter som beskrivs i avsnitt 6 (Grundläggande förfaranden - Obligatoriska meddelanden) eller av dem i avsnitt 8 (Dialogförfaranden - Samordning).

9.1.1.3. Meddelandena som beskrivs i detta avsnitt finns endast tillgängliga i ADEXP-format, och det är inte planerat att de skall bli tillgängliga i ICAO-format.

9.1.2. Meddelandeföljd

9.1.2.1. Kommunikationsöverföringsmeddelanden, andra än meddelanden med tilläggsdata (SDM), skall inte förekomma om inte samordningen är avslutad, dvs. en ACT- eller RAP-dialog har avslutats med ett LAM eller ett ACP.

9.1.2.2. En bekräftelse skall inte återsändas så länge som samordningen inte är slutförd.

9.1.3. Kommunikationsöverföring

9.1.3.1. Metoden för att tillkännage det faktiska övertagandet av kommunikationen för en flygning skall vara bilateralt överenskommen mellan de två berörda enheterna.

9.1.3.2. Förhållandena skall vara ett eller båda av följande:

- Den överlämnande enheten sänder ett meddelande om frekvensändring (COF).

- Den mottagande enheten sänder att meddelande om manuellt övertagande av kommunikationen (MAS).

9.1.3.3. Metoden skall vara överenskommen mellan de båda enheterna för varje trafikflöde.ANMÄRKNING

Alternativa metoder kan tillämpas för olika flöden, t.ex. kan en enhet generera COF-meddelanden för flygningar som lämnar dess luftrum och MAS-meddelanden för flygningar som inträder i dess luftrum. I sådant fall skulle det inte vara nödvändigt för den andra enheten att utfärda några meddelanden för att tillkännage kommunikationsöverföring.

9.2. Meddelande om initiering av överföring (TIM)

9.2.1. Syfte med TIM-meddelandet

Syftet med TIM är att

- tillkännage initiering av överföringsmomentet (TI) (slutet av samordningsfasen och början på överföringsfasen),

- samtidigt överföra verkställande kontrolldata från den överlämnande enheten till den mottagande enheten.

9.2.2. Meddelandeinnehåll

TIM-meddelandet skall bestå av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- Meddelandenummer,

- flygplansidentifiering,

- Tillgänglig data - meddelandet skall också innehålla vart och ett av följande, om det finns tillgängligt:

- Godkänd flygnivå.

- Tilldelad kurs eller tillstånd till direkt flygväg.

- Tilldelad fart.

- Tilldelad stig-/sjunkhastighet.

- Valfri data - meddelandet kan även innehålla

- position.

ANMÄRKNING

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

9.2.3. Tillämpningsregler

9.2.3.1. Allmänt

9.2.3.1.1. TIM-meddelandet skall genereras och sändas av den överlämnande enheten till den mottagande enheten utan mänsklig inblandning då flygningen befinner sig vid bilateralt överenskommen tid/överenskommet avstånd från gränsen.

9.2.3.1.2. Ett TIM-meddelande skall också sändas automatiskt när meddelandet med begäran om frekvens (ROF) tas emot av den överlämnande enheten.

9.2.3.1.3. Ett TIM skall inte sändas innan flygningen har samordnats.

9.2.3.1.4. TIM-meddelandet skall innehålla den senaste datan som finns tillgänglig i systemet.

9.2.3.2. Tidsparametrar för sändning

9.2.3.2.1. Parametern för genererandet av TIM skall vara en variabel systemparameter som kan ändras, baserat på villkoren i LoA.

9.2.3.2.2. Rekommendation

Systemet för genererandet av TIM bör definieras separat för varje COP.

9.2.3.2.3. De samordnande parterna skall innefatta parametrarna för genererandet av ett TIM i deras LoA.

9.2.3.2.4. Systemparametrarna som utlöser TIM-meddelandet kan vara kopplade till flygplanets beräknade fart över marken. Emellertid skall initieringen av ett TIM-meddelande alltid påbörjas innan den aktuella färdplanspositionen är närmare COP än den det minimiavstånd som har angivits bilateralt.

9.2.3.2.5. Den angivna systemparametern för TIM-sändningen skall ge tillräckligt med tid för muntlig kommunikation före överlämnandet.

9.2.3.3. Behandling i den mottagande enheten

9.2.3.3.1. Den data som mottagits i ett TIM skall göras tillgänglig för den mottagande flygledaren.

9.2.4. Bekräftelse av ett TIM

9.2.4.1. Bekräftelse

Om TIM-meddelandet

- otvetydigt kan anslutas till en färdplan, skall det bekräftas genom genererandet och sändandet av ett LAM-meddelande,

- inte otvetydigt kan anslutas till en färdplan, skall inget bekräftelsemeddelande sändas.

9.2.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som bekräftelse på ett TIM-meddelande, skall en varning visas vid den berörda stationen.

9.2.5. Exempel

-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253

9.3. Meddelande med tilläggsdata (SDM)

9.3.1. Syfte med SDM-meddelandet

9.3.1.1. Allmänt

9.3.1.1.1. Huvudsyftet med SDM är att sända kontrolldata, och ändringar till densamma, från den överlämnande enheten till den mottagande enheten, förutsatt att det har överenskommits bilateralt att ändringarna inte behöver bekräftas av den mottagande flygledaren.

9.3.1.1.2. SDM-meddelandet kan också användas av den mottagande enheten för att upplysa den överlämnande enheten om vilken radiotelefonifrekvens flygningen skall överföras till.

9.3.2. Meddelandeinnehåll

9.3.2.1. Meddelanden från den överlämnande enheten

SDM-meddelandet skall bestå av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- meddelandenummer,

- flygplansidentifiering.

- Tilläggsdata - meddelandet skall också innehålla en eller flera av följande:

- Tilldelad kurs eller tillstånd till direkt flygväg.

- Tilldelad fart.

- Tilldelad stig-/sjunkhastighet.

- Godkänd flygnivå.

9.3.2.2. Meddelanden från den mottagande enheten

Ett SDM skall innehålla följande data:

- Meddelandetyp.

- Meddelandenummer.

- Flygplansidentifiering.

- Frekvens.

ANMÄRKNING

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

9.3.3. Tillämpningsregler

9.3.3.1. Meddelanden från den överlämnande enheten

9.3.3.1.1. SDM-meddelanden skall sändas efter initiering av överföringsfasen (se TIM, punkt 9.2) vid varje förändring av någon av följande punkter:

- Godkänd flygnivå.

- Tilldelad fart.

- Tilldelad stig-/sjunkhastighet.

- Tilldelad kurs.

- Utfärdande eller ändring av ett tillstånd för flygningen att fortsätta direkt till en fastställd punkt.

ANMÄRKNING

HOP-meddelandet måste användas när tillstånd från den mottagande flygledaren krävs före överföringen av kommunikationen.

9.3.3.1.2. Meddelandet skall endast innehålla de fält som ändrats.

9.3.3.1.3. SDM-meddelande som innehåller den data som beskrivits i 9.3.3.1.1 skall sändas före TI, om så har överenskommits bilateralt.

9.3.3.1.4. Sådana meddelanden skall påbörjas vid en bilateralt överenskommen tidpunkt i förhållande till TI, under förutsättning att det finns data för vilken det finns ett värde tillgängligt i systemet.

9.3.3.2. Meddelanden från den mottagande enheten

9.3.3.2.1. SDM-meddelanden kan sändas för att påvisa den frekvens som flygningen skall använda för att kontakta den mottagande enheten.ANMÄRKNING

Enheter kan bilateralt komma överens om att sända annan information. Sådan överföring har inte definierats i, och är därför inte någon del av, denna standard.

9.3.3.2.2. Om så har överenskommits bilateralt, skall SDM-meddelanden från den mottagande enheten sändas under samordningsfasen.

9.3.3.3. Behandling i den mottagande enheten

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

9.3.3.3.2. Om en motsvarande, samordnad, färdplan påträffas

- skall ett LAM återsändas, och

- det operativa innehållet i SDM-meddelandet göras tillgängligt för den berörda flygledaren.

9.3.3.3.3. Om en motsvarande färdplan inte kan påträffas, eller om en avvikelse påträffas som förhindrar korrekt behandling av meddelandet,

- skall inget LAM återsändas, och

- en varning visas vid en berörd station.

9.3.4. Bekräftelse av ett SDM

9.3.4.1. Bekräftelse

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

9.3.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande har mottagits som en bekräftelse på ett SDM-meddelande, skall en varning visas vid en berörd station.

9.3.5. Exempel

-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290

9.4. Förslag till överlämning (HOP)

9.4.1. Syfte med HOP-meddelandet

Syftet med HOP-meddelandet är

- för den överlämnande flygledaren att uppmärksamma den mottagande flygledaren på en särskild flygning för överlämnande,

- för den överlämnande flygledaren att föreslå flygningen för överlämnande till den mottagande flygledaren då detta krävs,

- att överföra ändringar av den verkställande kontrolldatan, vilket kräver godkännande av den mottagande flygledaren, enligt bilateral överenskommelse.

Det är inte nödvändigt att använda HOP till alla flygningar; det används efter den överlämnande flygledarens godtycke.ANMÄRKNING

Med avseende på punkt c) ovan, används ett SDM för att vidarebefordra ändringar i verkställande kontrolldata som inte kräver godkännande av den mottagande flygledaren.

9.4.2. Meddelandeinnehåll

HOP-meddelandet skall bestå av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- meddelandenummer,

- flygplansidentifiering.

- Tillgänglig data - meddelandet skall också innehålla vart och ett av följande, om det finns tillgängligt:

- Godkänd flygnivå.

- Tilldelad kurs eller tillstånd till direkt flygväg.

- Tilldelad fart.

- Tilldelad stig-/sjunkhastighet.

- Valfri data - meddelandet kan även innehålla

- position.

ANMÄRKNING

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

9.4.3. Tillämpningsregler

9.4.3.1. Allmänt

9.4.3.1.1. HOP-meddelandet skall, då det används, vara manuellt initierat av den överlämnande flygledaren.

9.4.3.1.2. Meddelandet skall inkludera all flygdata, som beskrivits i punkt 9.4.2 ovan, som har ändrats från den som tidigare sänts.

9.4.3.1.3. Om ett HOP-meddelande sänds före TI, skall överföringsfasen inledas.ANMÄRKNING

Ett meddelande om initiering av överföring (TIM) erfordras inte utöver ett HOP.

9.4.3.1.4. Tidigaste tidpunkten eller avståndet före en COP eller gräns då ett HOP kan sändas skall vara bilateralt överenskommet.

9.4.3.1.5. Rekommendation

Tiden/avståndet bör fastställas separat för varje COP.

9.4.3.2. Behandling i den mottagande enheten

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

9.4.3.2.2. Den flygdata som erhållits i meddelandet skall omedelbart visas för den mottagande flygledaren.

9.4.3.2.3. Om den mottagande flygledaren godkänner flygningen under de förhållanden som föreslagits i ett HOP, kan ett ROF sändas som svar till den överlämnande enheten. När det har överenskommits bilateralt, kan ett ACP sändas som ett svar på ett HOP.

9.4.3.2.4. Om den mottagande flygledaren inte kan godkänna flygningen, skall överlämnandet överenskommas muntligen.ANMÄRKNING

På grund av överlämningsförfarandets brådskande karaktär, har inte systemhjälp med övervakning av återsändandet av ett ROF (eller ACP) krävts i denna standard. Det antas att den överlämnande flygledaren är väl medveten om avsaknaden av ett svar från den mottagande flygledaren och vidtar erforderliga åtgärder. Denna standard förhindrar emellertid inte att en varning ges till den överlämnande flygledaren om det bedöms vara nödvändigt av operativa orsaker.

9.4.3.2.5. Så snart ett ROF (eller ACP) har tagits emot, skall datan i HOP-meddelandet bli operativt bindande för båda ATC-enheterna.

9.4.4. Bekräftelse av ett HOP

9.4.4.1. Bekräftelse

Om det kan anslutas till en färdplan, skall HOP-meddelandet bekräftas automatiskt med ett LAM.

9.4.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande har mottagits som en bekräftelse på ett HOP-meddelande, skall en varning visas vid den berörda stationen.

9.4.5. Exempel

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ

9.5. Meddelande med begäran om frekvens (ROF)

9.5.1. Syfte med ROF-meddelandet

Ett ROF sänds, när så erfordras, av den mottagande enheten till den överlämnande enheten med en begäran till den överlämnande flygledaren om att beordra flygplanet att byta till den mottagande flygledarens frekvens. Meddelandet kan användas

- som svar på ett HOP för tillkännage godkännandet av flygningen under de föreslagna förhållandena,

- för att begära tidigare överlämnande av flygningen.

9.5.2. Meddelandeinnehåll

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

- Obligatorisk data - meddelandet skall innehålla

- Meddelandetyp,

- Meddelandenummer,

- flygplansidentifiering.

- Valfri data - meddelandet kan även innehålla

- frekvens.

ANMÄRKNING

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

9.5.3. Tillämpningsregler

9.5.3.1. Allmänt

9.5.3.1.1. ROF-meddelandet skall initieras manuellt av den mottagande flygledaren.

9.5.3.1.2. Den mottagande flygledaren kan utlösa ett ROF, antingen

- när den mottagande flygledaren kräver att ha flygplanet på frekvens tidigt, eller

- som ett svar på ett HOP-meddelande.

9.5.3.2. Behandling i den mottagande enheten

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

9.5.3.2.2. Mottagandet av ett ROF skall utan dröjsmål påvisas för den överlämnande flygledaren.

9.5.3.2.3. Om flygningen inte befinner sig i överföringsfasen, skall överföringsfasen inledas, och ett TIM-meddelande sändas.

9.5.4. Bekräftelse av ett ROF

9.5.4.1. Bekräftelse

9.5.4.1.1. Om ROF-meddelandet otvetydigt kan anslutas till en färdplan, skall det bekräftas genom genererandet och sändandet av ett LAM-meddelande.

9.5.4.1.2. Om ROF-meddelandet inte otvetydigt kan anslutas till en färdplan, skall ingen bekräftelse sändas.

9.5.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som bekräftelse på ett ROF-meddelande, skall en varning visas vid den berörda ATC-stationen.

9.5.5. Exempel

-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.6. Meddelande om frekvensändring (COF)

9.6.1. Syfte med COF-meddelandet

9.6.1.1. Allmänt

9.6.1.1.1. Ett COF sänds av den överlämnande enheten till den mottagande enheten för att påvisa att flygningen har beordrats att kontakta den mottagande flygledaren.

9.6.1.1.2. Meddelandet kan innehålla en möjlighet för den överlämnande flygledaren att befria flygningen från de överenskomna överföringsförhållandena när den har etablerat radiokontakt med den mottagande flygledaren.

9.6.2. Meddelandeinnehåll

COF-meddelandet skall bestå av följande data:

- Obligatorisk data - meddelandet skall innehålla

- meddelandetyp,

- meddelandenummer,

- flygplansidentifiering.

- Tillgänglig data - meddelandet skall också innehålla vilken som helst av följande, om det finns tillgängligt:

- Överlåtelseindikering.

- Frekvens.

- Godkänd flygnivå.

- Tilldelad kurs eller tillstånd till direkt flygväg.

- Tilldelad fart.

- Tilldelad stig-/sjunkhastighet.

- Valfri data - meddelandet kan även innehålla:

- Position.

ANMÄRKNING

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

9.6.3. Tillämpningsregler

9.6.3.1. Allmänt

9.6.3.1.1. COF-meddelandet skall initieras manuellt av den överlämnande flygledaren.

9.6.3.1.2. Användandet av COF-meddelandet är obligatoriskt om, genom en bilateral överenskommelse, MAS-meddelandet inte används.

9.6.3.1.3. Om ett COF-meddelande sänds före TI, skall överföringsfasen inledas.ANMÄRKNING

Ett meddelande om initiering av överföring (TIM) krävs inte utöver ett COF.

9.6.3.2. Behandling i den mottagande enheten

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

9.6.3.2.2. Mottagandet av ett COF skall utan dröjsmål påvisas för den mottagande flygledaren.

9.6.4. Bekräftelse av ett COF

9.6.4.1. Bekräftelse

9.6.4.1.1. Om COF-meddelandet otvetydigt kan anslutas till en färdplan, skall det bekräftas genom genererandet och sändandet av ett LAM-meddelande.

9.6.4.1.2. Om COF-meddelandet inte otvetydigt kan anslutas till en färdplan, skall ingen bekräftelse sändas.

9.6.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som en bekräftelse på ett COF-meddelande, skall en varning visas vid den berörda ATC-stationen.

9.6.5. Exempel

-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.7. Meddelande om manuellt övertagande av kommunikationen (MAS)

9.7.1. Syfte med MAS-meddelandet

Ett MAS sänds av den mottagande enheten till den överlämnande enheten för att påvisa att tvåvägs radiokontakt har upprättats med flygningen.

9.7.2. Meddelandeinnehåll

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

- Meddelandetyp.

- Meddelandenummer.

- Flygplansidentifiering.

ANMÄRKNING

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

9.7.3. Tillämpningsregler

9.7.3.1. Allmänt

9.7.3.1.1. MAS-meddelandet skall initieras manuellt av den mottagande flygledaren.

9.7.3.1.2. Användandet av MAS-meddelandet är obligatoriskt om, genom en bilateral överenskommelse, COF-meddelandet inte används.

9.7.3.2. Behandling i den mottagande enheten

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

9.7.3.2.2. Mottagandet av ett MAS skall utan dröjsmål påvisas för den mottagande flygledaren.

9.7.4. Bekräftelse av ett MAS

9.7.4.1. Bekräftelse

9.7.4.1.1. Om MAS-meddelandet otvetydigt kan anslutas till en färdplan, skall det bekräftas genom genererandet och sändandet av ett LAM-meddelande.

9.7.4.1.2. Om MAS-meddelandet inte otvetydigt kan anslutas till en färdplan, skall ingen bekräftelse sändas.

9.7.4.2. Tillfällen utan bekräftelse

Om inget LAM-meddelande tas emot som en bekräftelse på ett MAS-meddelande, skall en varning visas vid den berörda ATC-stationen.

9.7.5. Exempel

-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

BILAGA A (Normativ)

REGLER FÖR INFÖRANDE AV DATA

INNEHÅLL

>Plats för tabell>

A.1. Syfte

I denna bilaga beskrivs de allmänna reglerna för införande av data i meddelandena beskrivna i denna standard. Dessa regler gäller för alla meddelanden utom då andra alternativ eller undantag till dessa regler specifikt har uppgivits i tillämpningsreglerna för ett specifikt meddelande.

A.2. Allmänna meddelandeformat

A.2.1. Alla meddelanden beskrivna i de följande avsnitten kan sändas med användande av ICAO-formatet:

6 Grundläggande förfarande - Obligatoriska meddelanden.

7 Grundläggande förfarande - Kompletterande meddelanden.

8 Dialogförfarande - Samordning.

A.2.2. Fältformat för ICAO-meddelanden är specificerade i Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control (Document 4444). I meddelanden där de förekommer, skall följande ICAO-fälttyper sändas före alla andra fälttyper och i följande ordning: 3, 7, 13, 14 och 16. Eftersom de är i fälttyp 22-format, är ordningsföljden på andra ICAO-fälttyper inte viktig, annat än att de inte får föregå de fälttyper som listas ovan.

A.2.3. Alla meddelanden beskrivna i detta dokument kan sändas med användande av Eurocontrol ADEXP-format. Innehållet, uppbyggnaden och användandet av ADEXP-datafält skall ske i överensstämmelse med referensdokument 2.ANMÄRKNINGAR

1. Endast de primära ADEXP-datafälten är listade i denna bilaga, förutom där förknippade underordnade fält kräver särskilda kommentarer. ADEXP-standarden listar alla valfria och obligatoriska underordnade fält som krävs inom varje primärt fält.

2. Meddelanden beskrivna i avsnitt 9, Dialogförfaranden - Överföring av kommunikationen, beskrivs endast i ADEXP-format.

A.3. Meddelandetyp

Meddelandetypen betecknas med en förkortning för meddelandet, enligt följande förteckning:

ABI: Förhandsmeddelande med gränsinformation.

ACP: Godkännande.

ACT: Aktivering.

CDN: Samordning.

COD: Tilldelning av SSR-kod.

COF: Frekvensändring.

HOP: Förslag till överlämning.

INF: Information.

LAM: Logiskt bekräftelsemeddelande.

MAC: Meddelande om upphävande av samordning.

MAS: Manuellt övertagande av kommunikationen.

PAC: Preliminär aktivering.

RAP: Remitterat aktiveringsförslag.

REV: Ändring.

RJC: Avslag till samordning.

ROF: Begäran om frekvens.

RRV: Remitterat ändringsmeddelande.

SBY: Beredskap.

SDM: Meddelande med tilläggsdata.

TIM: Meddelande om initiering av överföring.

A.3.1. ICAO

Fälttyp 3, element (a).

A.3.2. ADEXP

Primärt fält "title".

A.4. Meddelandenummer

Meddelandenumrets data innehåller de identifieringar som tilldelats de sändande och mottagande enheterna samt meddelandets sekvensnummer. Meddelandets sekvensnummer löper i ordningsföljd från 001 till 000 (som representerar 1000), därefter upprepas det från 001 för alla meddelanden som sänds till samma mottagare, oavsett typen av meddelande.

A.4.1. ICAO

Fälttyp 3, element (b).

A.4.2. ADEXP

Primärt fält "refdata".

Underordnat fält "fac", inom underordnade fält "sender" och "recvr" skall innehålla de identifieringar som har tilldelats ATC-enheterna. Dessa identifieringar skall inte vara längre än åtta tecken.

Underordnat fält "seqnum" skall innehålla sekvensnumret.

A.5. Meddelandereferens

A.5.1. ICAO

Fälttyp 3, element (c) (benämnt "reference data" i ICAO dokument 4444).

Innehållet i element (c) skall vara detsamma som det i fälttyp 3, element (b), i det hänvisade OLDI-meddelandet.

A.5.2. ADEXP

Primärt fält "msgref".

Värdena i underordnade fält "sender", "recvr" och "seqnum", inom det primära fältet "msgref", skall vara desamma som de i samma underordnade fält inom det primära fältet "refdata" i det hänvisade OLDI-meddelandet.

A.6. Flygplansidentifiering

A.6.1. ICAO

Fälttyp 7, element (a).

A.6.2. ADEXP

Primärt fält "arcid".

A.7. SSR-läge och -kod

Antingen

1. om känd, den SSR-läge/-kod på vilken den mottagande enheten kan förvänta sig att flygplanet svarar vid kontrollöverföringspunkten,

eller

2. ett tecken på att SSR-kod har begärts från den mottagande enheten.

A.7.1. ICAO

Fälttyp 7, element (b) och (c).

Om ingen SSR-kod har tilldelats, eller om läget/koden inte är känd, skall element (b) och (c) utelämnas.

Vid begäran av en SSR-kod/-läge skall element b) och c) innehålla värdet "A9999".

A.7.2. ADEXP

Primärt fält "ssrcode".

Om ingen giltig SSR-kod har tilldelats eller om läget/koden inte är känd skall fältet utelämnas.

Vid begäran av en SSR-kod/-läge via PAC-meddelandet skall det primära fältet "ssrcode" innehålla indikatorn "REQ".

A.8. Startflygplats

A.8.1. ICAO

Fälttyp 13, element (a).

A.8.2. ADEXP

Primärt fält "adep".

A.9. Beräknad data

A.9.1. Allmänt

A.9.1.1. Beräknad data skall innefatta COP, tid vid COP och överföringsnivå.

A.9.1.2. Samordningspunkten skall definieras som antingen en känd referenspunkt, en distans och en bäring från en känd referenspunkt, eller en latitud och en longitud.

A.9.1.3. Den godkända (överförings-)nivån skall motsvara de föreslagna överföringsförhållandena.

A.9.1.4. Rekommendation

För stigande eller sjunkande flygningar skall den beräknade datan även innehålla tilläggsdata och förhållanden för korsning.

A.9.1.5. Om den används, skall tilläggsdatan för korsning innefatta tilläggsnivån för korsning vid kontrollöverföringspunkten. Korsningsvillkoren skall vara följande:

- Bokstaven "A" - om flygningen kommer att befinna sig på eller över nivån i tilläggsdatan för korsning.

- Bokstaven "B" - om flygningen kommer att befinna sig på eller under nivån i tilläggsdatan för korsning.

A.9.2. ICAO

Fälttyp 14.

A.9.3. ADEXP

Primärt fält "coordata".

Underordnade fält "ptid" inom primärt fält "coordata" skall innehålla antingen

- en känd referenspunkt, eller

- en bäring och en distans från en känd referenspunkt, vilken definierats i samma meddelande genom primärt fält "REF" eller "GEO".

A.10. Samordningspunkt

A.10.1. Allmänt

A.10.1.1. Samordningspunkten som remitterats till av de överlämnande och mottagande ATC-enheterna i samband med berörd överföring.

A.10.1.2. Samordningspunkten skall definieras antingen som en känd punkt, en distans och en bäring från en känd referenspunkt eller en latitud och en longitud.

A.10.2. ICAO

Fält 14, element (a).

A.10.3. ADEXP

Primärt fält "cop" innehållande

- en känd referenspunkt, eller

- en bäring och en distans från en känd referenspunkt, vilken definierats i samma meddelande genom primärt fält "REF" eller "GEO".

A.11. Landningsflygplats

A.11.1. ICAO

Fält 16, element (a).

A.11.2. ADEXP

Primärt fält "ades".

A.12. Antal och typ av flygplan

Antal och typ av flygplan skall innehålla typen av flygplan. Antalet flygplan skall inkluderas om det rör sig om en formationsflygning.

A.12.1. ICAO

Fälttyp 9 i fälttyp 22-format. Element c av fälttyp 9 skall innehålla antingen kategorin för vakturbulens tillämplig för flygplanstypen eller bokstaven "Z".

A.12.2. ADEXP

Primärt fält "arctyp". Som tillägg, om det ingår mer än ett flygplan i flygningen, primärt fält "nbarc".

A.13. Flygväg

Båda formaten stödjer flygvägsbeskrivningen enligt definition för ICAO-meddelanden, vilken kräver som de första elementen fart och begärd flygnivå eller höjdinformation. Efter fart/nivå-gruppen inkluderar flygvägsdatan, som ett minimum, vad som specificeras i följande punkt. Ytterligare flygvägsdata kan infogas efter punkt c) om det finns tillgängligt. Se även bilaga B, "Krav för behandling av speciella flygvägar", för införingsregler för flygvägsdata.

A.13.1. Innehåll

A.13.1.1. Flygningar som passerar en definierad COP

- Elementet flygväg före COP (ATS-flygväg, SID-identifiering, DCT eller väsentlig punkt).

- COP.

- Elementet flygväg efter COP (ATS-flygväg eller väsentlig punkt).

A.13.1.2. Flygningar som fortsätter utanför ATS-flygväg

- Den punkt från vilken flygningen fortsätter på det direkta flygvägssegmentet.

- Elementet "DCT".

- Den punkt till vilken flygningen fortsätter på det direkta flygvägssegmentet.

A.13.2. Format

A.13.2.1. ICAO

Fälttyp 15, i fälttyp 22-format.

A.13.2.2. ADEXP

Primärt fält "route".

A.14. Annan färdplansdata

A.14.1. ICAO

Fälttyper 8, 10, och 18, i fälttyp 22-format.

A.14.2. ADEXP

Primära fält: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts", och "typz".

A.15. Samordningsstatus och anledning

Samordningsstatus och anledning skall innefatta följande element:

- En trebokstavsbeteckning som bekräftar den nya statusen på systemfärdplanen enligt en av följande:

- INI, när systemfärdplanen skall ha initial status, dvs. inget underrättelsemeddelande har mottagits.

- NTF, när systemfärdplanen skall ha underrättad status.

- CRD, när systemfärdplanen skall ha samordnad status, dvs. grundläggande ACT mottaget eller initial samordningsdialog avslutad med överenskomna förhållanden.

- en trebokstavsbeteckning som specificerar anledningen till statusen enligt en av följande:

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

- RTE, om anledningen är en förändrad flygväg.

- HLD, som anvisning på att flygningen väntar under en obestämd tidsperiod och kommer att erhålla ett ytterligare meddelande.

- DLY, som anvisning på att avgången är försenad.

- CAN, om anledningen är en annullering.

- CSN, för en förändring av callsign.

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

A.15.1. ICAO

A.15.1.1. Samordningsstatusen och anledningen skall vara i fälttyp 18-format.

A.15.1.2. Samordningsstatusen och anledningen skall innehålla följande element som en tiokaraktärsgrupp:

- STA efterföljt av ett snedstreck.

- Beteckningen som bekräftar den nya statusen på underrättelsen/ samordningen.

- Beteckningen som specificerar anledningen.

A.15.2. ADEXP

Primärt fält "cstat".

Hjälpbegreppen "coordstatusident" och "coordstatusreason" skall innehålla den nya statusen och anledningen enligt ovanstående beskrivning.

A.16. Tilldelad kurs (endast ADEXP)

Primärt fält "ahead" skall innehålla antingen

- kursen som tilldelats en flygning, uttryckt i grader,

eller

- om ingen kurs är tilldelad, beteckningen "ZZZ", t.ex. när ett SDM-meddelande används för att indikera att en tidigare tilldelad kurs inte längre gäller.

A.17. Tilldelad fart (endast ADEXP)

Primärt fält "aspeed" skall innehålla antingen

- farten som tilldelats en flygning, uttryckt i knop, Machtal eller kilometer/timme,

eller

- om ingen fart har tilldelats, beteckningen "ZZZ", t.ex. när ett SDM-meddelande används för att indikera att en tidigare tilldelad fart inte längre gäller.

A.18. Tilldelad stig-/sjunkhastighet (endast ADEXP)

Primärt fält "rate" skall innehålla

- stig- eller sjunkhastigheten som tilldelats en flygning, uttryckt i hundratal fot per minut,

eller

- om ingen stig- eller sjunkhastigheten tilldelats, beteckningen "ZZZ" i sifferdelen av fältet, t.ex. när ett SDM-meddelande används för att indikera att en tidigare tilldelad stig-/sjunkhastighet inte längre gäller.

A.19. Tillstånd till direkt flygväg (endast ADEXP)

En direkt flygväg, , ej definierad som en ATS-flygväg, mellan två punkter. Punkterna kan definieras som antingen en känd referenspunkt eller en distans och en bäring från en referenspunkt. Alla beteckningar på slutpunkter som används skall vara bilateralt överenskomna, dvs. kända av båda systemen.

Primärt fält "DCT" med följande innehåll:

- Den punkt vid vilken avvikelsen har begärts att påbörjas, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt, enligt definition i samma meddelande genom primärt fält "REF",

eller

- värdet "ZZZ" om den sändande enheten inte kräver att avvikelsepunkten fastställs.

- den punkt belägen längs den ursprungliga flygvägen till vilken flygplanet har beviljats, eller kommer att beviljas tillstånd, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt, enligt definition i samma meddelande genom primärt fält "REF".

A.20. Begäran om direkt flygväg

Begäran om en direkt flygväg, ej definierad som en ATS-flygväg, mellan två punkter. Punkterna kan definieras som antingen en känd referenspunkt eller en distans och en bäring från en referenspunkt.

Alla beteckningar på slutpunkter som används skall vara bilateralt överenskomna, dvs. kända av båda systemen.

A.20.1. ICAO

Fälttyp 15, utelämnande den ursprungliga fart/nivå-gruppen, i fält 22-format.

Det skall innehålla:

- den punkt vid vilken avvikelsen har begärts att påbörjas, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt,

eller

- värdet "ZZZ" om en direkt flygväg begärs av den mottagande ATC-enheten.

- förkortningen "DCT",

- åtföljd av den punkt belägen längs den ursprungliga flygvägen till vilken flygplanet har beviljats, eller kommer att beviljas tillstånd, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt.

A.20.2. ADEXP

Primärt fält "DCT" innehållande:

- den punkt vid vilken avvikelsen har begärts att påbörjas, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt, enligt definition i samma meddelande genom primärt fält "REF",

eller

- värdet "ZZZ" om en direkt flygväg begärs av den mottagande ATC-enheten men den exakta punkten vid vilken den skulle påbörjas inte är känd.

- den punkt belägen längs den ursprungliga flygvägen till vilken flygplanet har beviljats, eller kommer att beviljas tillstånd, definierad som

- en känd referenspunkt,

eller

- en distans och en bäring från en känd referenspunkt, enligt definition i samma meddelande genom primärt fält "REF".

A.21. Position (endast ADEXP)

A.21.1. Allmänt

A.21.1.1. Den aktuella positionen på flygningen uttryckt antingen i geografiska koordinater eller genom bäring och distans från en fastställd punkt.

A.21.1.2. Primärt fält "ref" eller "geo" skall definiera det aktuella horisontella läget på flygplanet. Punkter som används för distans och bäring i primärt fält "ref" skall vara bilateralt överenskomna, dvs. kända i båda systemen. Primärt fält "position" skall innehålla det underordnade fältet "ptid" vilket hänvisar till den fastställda referenspunkten eller geografiska punkten. Om tidsinformation skall ingå, skall antingen underordnat fält "to" (ttmm) eller "sto" (ttmmss) användas, enligt bilateral överenskommelse.

A.22. Överlåtelseanvisning (endast ADEXP)

Primärt fält "release" skall innehålla ett av följande:

- C, om flygningen erhållit tillstånd att stiga.

- D, om flygningen erhållit tillstånd att sjunka.

- T, om flygningen erhållit tillstånd att svänga.

- F, om flygningen erhållit tillstånd till alla åtgärder.

A.23. Frekvens

A.23.1. ICAO

Fälttyp 18 skall innehålla följande element i fält 22-format:

- FRQ, åtföljt av ett snedstreck.

- 6 siffror som betecknar frekvensen, uttryckt i MHz till tre decimaler.

A.23.2. ADEXP

Primärt fält "freq".

A.24. Anledning (endast ADEXP)

Primärt fält "reason", innehållande värdet "MANUAL" för manuellt hänvisade meddelanden.

A.25. Tilldelad flygnivå (endast ADEXP)

Primärt fält "cfl".

A.26. Föreslagen överföringsnivå (endast ADEXP)

Primärt fält "propfl".

A.27. Beräknad starttid

A.27.1. ICAO

Fälttyp 13 element (b).

A.27.2. ADEXP

Primärt fält "etot".

A.28. Typ av referensmeddelande

Fältet innehåller meddelandetypen enligt specifikation i punkt A.1 i denna bilaga.

A.28.1. ICAO

Fälttyp 18 i fälttyp 22-format. Elementindikatorn skall vara "MSG".

A.28.2. ADEXP

Primärt fält "msgtyp".

BILAGA B (Normativ)

KRAV FÖR BEHANDLING AV SPECIELLA FLYGVÄGAR

B.1. Inledning

B.1.1. Allmänt

B.1.1.1. I denna bilaga beskrivs reglerna och kraven för införande av data i följande fall, där så tillåts:

- En flygning dirigeras på en direkt kurs över gränsen, utanför flygvägen, som en följd av ett direkt flygvägssegment finns registrerat i färdplanen.

- Efter sändning av ABI- eller ACT-meddelandet, är en flygning omdirigerad via endera av

- en annan ATS-flygväg,

- en direkt flygväg för att återförenas med den ursprungliga flygvägen vid en senare punkt.

B.1.1.2. När det gäller omdirigering av flygningar (punkt B.1.1.1), stödjer det datautbyte som beskrivs i denna bilaga ändring av den planerade flygväg som återfinns i båda systemen genom användandet av underrättelse- och samordningsmeddelanden.

B.2. Tillämpning av meddelanden

B.2.1. Grundläggande regler för direkta flygvägar

B.2.1.1. Villkoren för användandet av OLDI för samordning av flygningar på direkta flygvägar skall överenskommas bilateralt.

B.2.1.2. Den data som krävs för underrättelse och samordning av flygningar på direkta flygvägar består i samordningspunkt (beräknad data (ICAO-format) och samordningsdata (ADEXP-format)) samt flygväg i berörda meddelanden.

B.2.2. Registrerad direkt flygväg

Då flygvägen indikerar att flygningen kommer att korsa gränsen på en direkt kurs, skall det direkta flygvägssegmentet och den resulterande COP ingå i ABI-meddelandet (-meddelandena). Denna COP inkluderas i det efterföljande ACT- eller RAP-meddelandet.

COP och flygvägsdata skall formateras enligt riktlinjerna i punkt B.3.2.

B.2.3. Omdirigeringar efter ABI- och före ACT-sändning

Ett nytt ABI-meddelande skall sändas med data som överensstämmer med den nya flygvägen.

B.2.4. Omdirigering efter ACT-sändning

B.2.4.1. Ett REV-meddelande skall användas för att påvisa en omdirigering som sker efter det att ACT-meddelandet har sänts men före en viss bilateralt överenskommen tid före ETO vid tidigare samordnad COP.ANMÄRKNING

Ett REV-meddelande används endast då den mottagande enheten inte ändras som ett resultat av ändringen. Om den ändras, måste ett MAC-meddelande sändas till den ursprungliga mottagande enheten eller samordningen muntligen upphävas.

B.2.4.2. Meddelandet skall innehålla följande data:

- Samordningspunkt (tidigare COP, i referenssyfte).

- Beräknad data.

- Flygväg.

B.2.4.3. Meddelanden i ICAO-format skall innehålla följande fält:

3 Meddelandetyp och -nummer, meddelandereferens om det är bilateralt överenskommet.

7 Flygplansidentifiering. Element b och c skall inte vara medtagna om inte en ändring av SSR-koden samtidigt samordnas.

13 Startflygplats.

14 Endast element a, innehållande föregående COP i referenssyfte.

16 Destination.

22 Fält 14, innehållande den beräknade datan för de nya gränskorsningsförhållandena, i fält 22-format.

22 Fält 15, innehållande den nya flygvägen, i fält 22-format.

B.2.4.4. Meddelanden i ADEXP-format skall, utöver meddelandetyp och -nummer, flygplansidentifiering, startflygplats, destination och, om det är bilateralt överenskommet, meddelandets referensnummer, innehålla

- föregående COP i COP-fältet,

- de nya samordningsförhållandena i COORDATA-fältet,

- den nya flygvägen i ROUTE-fältet.

B.2.4.5. Flygvägsändringar som sänds som delar av dialogförfarandet skall sändas som RRV-meddelanden om det inte är bilateralt överenskommet att de skall betraktas som "normala".

B.3. Fältens innehåll

B.3.1. ATS-flygvägar

För flygningar som omdirigeras via en alternativ ATS-flygväg, skall fälten för beräknad data och flygväg formateras som för ABI- och ACT-meddelanden.

B.3.2. Direkt flygväg

B.3.2.1. Samordningspunkten i den beräknade datan skall vara punkten för gränskorsning uttryckt som en bäring och en distans från rapportpunkten. Sådana punkter skall vara bilateralt överenskomna. Då avståndet är noll eller om en flygning kommer att passera inom ett bilateralt överenskommet avstånd från en sådan punkt, skall endast beteckningen på punkten inkluderas.

B.3.2.2. När det är bilateralt överenskommet, kan samordningspunkten för en flygning på en direkt flygväg uttryckas med hänvisning till latitud/longitud.

B.3.2.3. Flygvägen skall innehålla följande:

- Den punkt belägen längs den ursprungliga flygvägen från vilken flygplanet skall dirigeras direkt. När en flygning dirigeras direkt från "nuvarande position", kan punkten uttryckas som en bäring och en distans från en rapportpunkt. När det har överenskommits bilateralt, kan punkten uttryckas med hänvisning till latitud/longitud,

- Förkortningen "DCT",

- Den punkt till vilken flygplanet skall fortsätta direkt,

- Återstoden av den fortsatta flygvägen (FRF), om den är känd i det sändande systemet.

B.4. Exempel

B.4.1. Direkta flygvägar

B.4.1.1. ABI- och ACT-meddelanden

B.4.1.1.1. Flygningen (identifiering Jetset 253) skall korsa gränsen på en direkt kurs från punkt A (PTA), till punkt C (PTC) varefter den kommer att följa ATS-flygväg UA134. Systemet fastställer en COP med bäring 350 och distans 22 NM från punkt B (PTB).

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

Följande ABI-meddelande sänds:

- ICAO

(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)

- ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB -BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT PTC UA134

B.4.1.1.2. ACT-meddelandet har samma format som ABI-meddelandet, förutom att flygningens flygväg valfritt kan inkluderas.

B.4.1.2. REV-meddelande

Flygning HZT2051 var tidigare föremål för följande ACT-meddelande (eller ADEXP-motsvarighet):

(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M

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

Flygningen dirigeras därefter från 40 NM väst er om punkt RQA direkt till MYY. Den punkt som är närmast gränskorsningen är TDS från vilken avståndet till den faktiska korsningspunkten är 26 NM vid bäring 240 grader. Följande ändringsmeddelande sänds:

(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY)

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

ADEXP-motsvarigheten till meddelandet är:

-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG -SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310 -REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -ROUTE N0458F310 RQA270040 DCT MYY

Ett efterföljande ändringsmeddelande indikerar att TDS240026 är COP.

B.4.2. Omdirigering via ATS-flygvägar efter ACT-sändning

B.4.2.1. ACT-meddelande

Flygning GKP217 är planerad att dirigeras via samordningspunkt EMT. Följande ACT sänds:

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

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

Flygningen omdirigeras följaktligen via ATS-flygväg UM247 inom den sändande centralens luftrum till ny samordningspunkt XAT efter vilket den skall följa ATS-flygväg UJ124. Den mottagande centralen kvarstår. Följande ändringsmeddelande skickas:

(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)

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

Flygningen får sedan tillstånd till FL290, vilket resulterar i följande meddelande (innehållande den nya COP):

(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)

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

B.4.2.2. ADEXP-motsvarigheter

ADEXP-motsvarigheterna till de två ändringsmeddelandena är följande:

a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -ROUTE N0430F290 UM247 XAT UJ124

b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTA

BILAGA C (Informativ)

DIALOGFÖRFARANDEFASER (SYSCO NIVÅ 1) - MEDDELANDEFÖLJD

Meddelandeföljd

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

BILAGA II

UTFORMNINGEN AV UTBYTET AV ATS-DATA (ADEXP) UTGÅVA 2.0

(Eurocontrol-dokument DPS.ET1.ST09-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

Denna standard har utarbetats av och upprätthålls av avdelningen för användares krav (User Requirements Section) inom centralenheten för trafikflödeskontroll (Central Flow Management Unit - CFMU) inom den europeiska organisationen för luftfartssäkerhet, (Eurocontrol).

2. Eatchips arbetsprogramdokument

Denna standard har tillkommit som ett resultat av Eatchips arbetsprogramdokument, (EWPD), domänen för databehandling (DPS), verkställande åtgärd 09.

3. Godkännande av standarden

3.1. Denna standard har antagits i överensstämmelse med de förfaranden som beskrivs i Eurocontrols standardiseringsanvisningar, Ref. 000-2-93, Utgåva 1.0.

3.2. Bestämmelserna i denna standard trädde i kraft 1995, då utgåva 1.0 antogs av Eurocontrols ständiga kommission. Standarden tillämpas från och med den 1 december 1997.

4. Tekniska rättelser och ändringar

Det görs en regelbunden översyn av denna standard för att säkerställa erforderliga ändringar eller tekniska rättelser. Förfarandet för upprätthållandet av denna standard är fastställt i bilaga H i anvisningarna för enhetliga utkast och utformning av Eurocontrols standarddokument.

Ändringar eller tillägg som påverkar de grundläggande reglerna eller grammatiken i ADEXP-formatet, skall endast göras i enighet med de formella förfaranden för översyn som tillhandahålls i anvisningarna för enhetliga utkast och utformning av Eurocontrols standarddokument.

Ändringar eller tillägg till denna standard skall skriftligen föreslås till centralenheten för trafikflödeskontroll: CFMU, Users Requirements Section (ADEXP), Eurocontrol Agency.

5. Redaktionella regler

5.1. Formatet på denna standard överensstämmer med anvisningarna för enhetliga utkast och utformning av Eurocontrols standarddokument. Det finns dock några avvikelser från anvisningarna. De små formateringsundantagen från anvisningarna har gjorts för att undvika förväxling med beteckningssättet i utformningen av utbytet av ATS-data.

5.2. Följande beteckningssätt har använts för att ange status på respektive utlåtande:

- I normativa delar används det modala hjälpverbet "skall" och dessa delar har skrivits med normal text.

- I rekommenderade delar används det modala hjälpverbet "bör" och dessa delar har skrivits med kursiv stil. Status har indikerats med hjälp av prefixet Rekommendation.

6. Samband med andra standarder

Denna standard sammanhänger med

Eurocontrolstandard för utbyte on-line av data - OLDI (On-Line Data Interchange)

7. Status på bilagorna till denna standard

>Plats för tabell>

8. Använt språk

Originaltexten i denna standard är skriven på engelska.

1. OMFATTNING

1.1. ADEXP är ett format, inte ett protokoll. Inga begränsningar ges beträffande användande av överföringsmedium eller protokoll som används, med undantag för teckenuppsättningen.

1.2. ADEXP tillhandahåller ett format som i första hand används för utväxling av meddelanden mellan direktanslutna datorer.

1.3. I detta dokument beskrivs grundreglerna och språkreglerna i ADEXP-formatet. Det tillhandahåller denna beskrivning i formen av en omfattande definition av de fält som ingår i ADEXP.

1.4. ADEXP-formatet har specificerats för användning inom följande områden för utväxling av meddelanden (se avsnitt 2, sidan 3, för information om dokumenthänvisningar):

- Färdplanering: utbyte av färdplansdata och förknippade meddelanden mellan systemet för behandling av integrerade ursprungliga färdplaner (IFPS - Integrated Initial Flight Plan Processing System), flygtrafikledning (ATS - Air Traffic Services) och flygplansoperatörer (AO - Aircraft Operators). (referensdokument 3)

- Flygledningstjänst (ATFM - Air Traffic Flow Management): utväxling av meddelanden mellan det taktiska systemet (TACT) inom centralenheten för trafikflödeskontroll (CFMU - Central Flow Management Unit), AO samt ATS. (referensdokument 5)

- Samordning av flygkontrolltjänst (ATC): utväxling av taktiska samordnande meddelanden mellan ATC-enheter (ATCU). (referensdokument 6)

- Luftrumsledning: utbyte av data mellan enheter för nationella flygtrafikledningsenheter (ATS-enheter), CFMU samt AO, rörande luftrummets tillgänglighet. (referensdokument 7)

- Civil-militär samordning: meddelanden rörande civil och militär flygdata samt meddelanden rörande förflyttningar i luftrummet. (referensdokument 7).

1.5. Detaljerade beskrivningar rörande hantering och innehåll för meddelanden inom var och en av de ovanstående grupperna återfinns i de dokument till vilka hänvisningarna gjorts.

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 anvisade utgåvorna av hänvisade dokument och standarder gällande.

Vid samtliga revisioner av de dokument från Internationella civila luftfartsorganisationen (ICAO) till vilka hänvisning här skett, skall omedelbart revision av denna Eurocontrolstandard tas i beaktande.

Revidering av de övriga dokument som refererats till, skall icke 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. Vid tidpunkten för denna utgåva har referenser i denna standard gjorts till dokumenten i nedanstående sammanställning. Användare uppmanas emellertid att kontrollera användarförfarandet och tabellerna för sammansättning av meddelandefälten i de senaste utgåvorna av dessa dokument.

1. ICAOs Chicagokonvention, bilaga 10, volym I, utgåva daterad november 1985.

2. ICAOs Chicagokonvention, bilaga 10, volym II, utgåva daterad juli 1995.

3. IFPS and RPL Dictionary of Messages, utgåva 1.0, daterad mars 1998.

4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, utgåva daterad november 1985 (inklusive ändring nr 6 daterad november 1995).

5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, utgåva 6.0, gällande från mars 1998.

6. Eurocontrol Standard for On-Line Data Interchange, utgåva 2.0, daterad oktober 1996.

7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, utgåva 1.0, daterad maj 1996.

3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR

3.1. Beteckningsnorm

Den norm som används för att definiera syntax är betecknad Backus Naur Form (BNF). BNF definierar en uppsättning regler, vilka fastställer en grupp av teckenrader. I detta fall är gruppen av teckenrader den uppsättning av meddelanden som kan kallas för ett syntaktiskt giltigt ADEXP-meddelande.

3.2. Definitioner

I denna Eurocontrolstandard avses med

tecken: ett skrifttecken eller en uppsättning av skrifttecken som kan "utvinnas" av en lexikalisk analyseringsfunktion genom närvaron av avgränsare,

symbol: alla "beteckningar" som förekommer i en BNF-föreskrift men ej är ett skrifttecken,

terminal symbol: en symbol som representeras av en serie skrifttecken,

icke-terminal symbol: en symbol som representeras av en eller flera terminala symboler.

ANMÄRKNING

En icke-terminal symbol kan även representeras av en blandning av terminala och icke-terminala symboler.

3.3. Uppbyggnad

3.3.1. BNF består av en uppsättning regler eller konstruktioner enligt formatet

symbol ::= uttryck

ANMÄRKNINGAR

1) Beteckningen "::=" betyder "kan ersättas av".

2) Beståndsdelen "symbol" kategoriseras som icke-terminal.

3) Beståndsdelen "uttryck" innehåller terminala och icke-terminala symboler.

3.3.2. Terminala symboler framställs som en serie av skrifttecken vilka kan identifieras som ett tecken av en lexikalisk analyseringsfunktion genom närvaron av avgränsare.

3.4. Vedertagna regler

I denna Eurocontrolstandard gäller följande:

- Terminala symboler skrivs med stora bokstäver (versaler).ANMÄRKNING

Enligt vedertaget bruk betyder den terminala symbolen NIL "ingen terminal symbol".

Den används i alternativ enligt följande exempel:

a ::= b ( c | NIL ) där a kan ersättas av (b följt av c) eller av endast b.

- Icke-terminala symboler (t.ex. den vänstra sidan av en grammatisk sammansättning) skrivs med små bokstäver (gemener).

- Skrifttecken och serier av bokstäver som förekommer i reglerna omges av enkla citationstecken (') respektive dubbla citationstecken (").

Exempel

1) HYPHEN ::= '-'

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

I vissa fall av datautformning, kan det vara nödvändigt att särskilja terminala och icke-terminala symboler genom andra metoder än användandet av versaler och gemener.

Närhelst det fordras att uttryckligen särskilja terminala och icke-terminala symboler, på annat sätt än att använda versaler och gemener, rekommenderas tillägg av ett suffix enligt följande: "_at" för ett hjälputtryck, "_pf" för ett primärt fält och "_sf" för ett underordnat fält.

3.5. Operativa benämningar

I denna Eurocontrolstandard används följande operativa benämningar:

Valfrihet: När det är tillåtet för vissa giltiga symboler både att förekomma och att inte förekomma inom grammatiken. De valfria symbolerna omges av hakparentes "[" och "]".

Avslut: När en grupp med symboler kan uppträda noll eller flera gånger. Symbolerna omges av klammer "{" och "}". Om en siffra har specificerats framför tecknet "{", anger denna det minimala antalet gånger som gruppen av symboler får förekomma. Om en siffra har specificerats efter tecknet "}", anger denna det maximala antalet gånger som gruppen av symboler får förekomma.

Urval: Närhelst ett antal alternativa symboler förekommer vid något tillfälle i grammatiken. Valet representeras som ett lodstreck "|".

Hoplänkning: Förekomst av symboler som förekommer i sekvens, även om en eller flera avgränsare kan förekomma i densamma. Förekomsten av detta är inte entydig. Det finns två typer:

- Fast hoplänkning: på lexikalisk nivå, vissa regler kan innefatta hoplänkning av terminaler och indikera att de strikt följer varandra (utan avgränsare mellan dem). I dessa fall skall utropstecken "!" användas.Exempel

datetime :: = date ! timehhmm

t.ex. "9912251200" vilket innebär den 25 december 1999, klockan 12:00.

- Lös hoplänkning: den tillåtna närvaron av avgränsare mellan terminaler. Förekomsten av lös hoplänkning inom en regel kan vara antingen underförstådd eller explicit.Exempel

1) Underförstådd:

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

2) Explicit:

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

>Plats för tabell>

ANMÄRKNING

1) Hoplänkning skall alltid ha företrädesrätt över urval. Parenteserna "(" och ")" används för att förändra ordningsföljden för utvärdering av uttrycket.Exempel

>Plats för tabell>

2) Inom alla regler lämnas den tillåtna närvaron av avgränsare mellan symbolerna underförstådd för att läsbarheten skall bibehållas.

Rekommendation

När det finns risk för oklarhet beroende på rangordning mellan de ovan nämnda operativa beteckningarna, rekommenderas användandet av parenteserna i syfte att förtydliga den önskade utvärderingsföljden.

3.6. Förkortningar

>Plats för tabell>

4. GRUNDREGLER FÖR ADEXP

4.1. Textat, direkt läsbart format

4.1.1. Formatet i ADEXP är i textform, baserat på skrivtecken.

4.1.2. ADEXP-meddelanden är direkt läsbara för en operatör, vilket förbättrar möjligheterna till anpassning i operationella ärenden.

4.1.3. Ett textformat är dessutom mer överskådligt och begripligt.

4.2. Identifierade och sökbara fält

4.2.1. Ett meddelande i ADEXP-format skall bestå av fält.

4.2.2. Fält skall avgränsas genom användandet av ett speciellt fältstarttecken ("-") och identifieras med specifika nyckelord.ANMÄRKNING

Det bör noteras att vissa fält (de som syntaktiskt definieras såsom innehållande "CHARACTER") får innehålla ett bindestreck "-" som del av innehållet i fältet.

4.2.3. Denna uppbyggnadsmetod förbättrar formatets utbyggnadsmöjligheter och stabilitet. (Om ett fält saknas eller är felaktigt kan det hoppas över, och övriga delar av meddelandet kan ändå tolkas. (Se avsnitt 4.3)

4.2.4. En annan konsekvens är att ordningsföljden på fälten i ett meddelande inte har någon betydelse för fastställandet av dess giltighet, förutom det första fältet (obligatoriskt titelfält) som avgör vilka fält som är tillåtna.

4.2.5. Fält kan vara enkla eller sammansatta.

4.2.6. Beståndsdelarna i ett sammansatt fält kallas underordnade fält och definieras genom förekomsten av nyckelord, avgränsade av fältstarttecken.

4.2.7. Enkla fält är fält som inte innehåller underordnade fält.

4.2.8. De enkla eller sammansatta fälten som utgör den första definitionsnivån i ett meddelande kallas för dess primära fält.

4.2.9. Alla lägre uppbyggnadsdelar definieras som underordnade fält, vilka i sin tur kan vara enkla eller sammansatta.

4.2.10. Sammansatta fält förekommer som två typer, strukturerade fält eller listfält.

4.2.11. Strukturerade fält har ett fördefinierat innehåll uppbyggt uteslutande av underordnade fält. Ordningsföljden på underordnade fält i ett strukturerat fält SAKNAR betydelse.

4.2.12. Listfält påbörjas med nyckelordet BEGIN och avslutas med nyckelordet END. Mellan dessa kan återkommande förekomster av samma underordnade fält eller kombination av underordnade fält äga rum. Ordningsföljden på förekomsten inom ett listfält är viktigt för betydelsen.

4.2.13. I följande avsnitt används begreppet "fält" allmänt i betydelsen primära fält och/eller underordnade fält om annat ej uttryckligen sägs.

4.2.14. Fält i ett meddelande kan vara valfritt eller obligatoriskt beroende på dess syntax.

4.3. Oidentifierade fält

4.3.1. Om ett oidentifierat fält förekommer i ett meddelande, skall detta ignoreras.

4.3.2. Med andra ord, om systemet som analyserar meddelandet inte känner igen ett nyckelord, kommer all text fram till nästa kända primära fält, som inte ligger inom ett listfält, att ignoreras.

4.3.3. Det ignorerade fältet antingen kan eller kan inte, beroende på meddelandets titel, komma att orsaka att det analyserade meddelandet förkastas.ANMÄRKNING

Noteras bör, att trots att ADEXP är utformat för att tillhandahålla denna typ av flexibilitet, är det de som ansvarar för definitionen av gränssnittskraven som, för varje meddelande, måste använda sitt omdöme för att indikera hur systemet bör reagera på ett oidentifierat fält.

4.3.4. Om det oidentifierade fältet är ett listfält (vilket har påträffats genom nyckelordet -BEGIN), ignoreras hela dess innehåll (fram till det korresponderande nyckelordet -END).

4.3.5. För att undvika tvetydigheter i samband med att funktionen återupptas efter utelämnande av ett oidentifierat fält, krävs det att ett nyckelord påbörjar antingen ett primärt fält eller ett underordnat fält.

4.3.6. Detta möjliggör definitionen av två typer av nyckelord:

- Primära nyckelord.

- Sekundära nyckelord.

4.3.7. När typen av nyckelord väl är definierat, skall detta ej längre återanvändas i en annan grupp av meddelanden i egenskap av den andra typen, med undantag av om det förekommer inne i ett listfält utan att orsaka tvetydighet, då närvaron av nyckelordet BEGIN indikerar att den interna förekomsten kan komma att betraktas såsom ett underordnat fält.Exempel (på användning av typer av nyckelord)

1) Primärt fält

-RFL F330

2) Underordnat fält: alltid inom ett "sammansatt fält"

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

där -GEO är ett primärt sammansatt fält och -GEOID, -LATTD samt LONGTD är alla underordnade fält.

3) Listfält

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

...

-END RTEPTS

där "-BEGIN" är listfältets indikator och "RTEPTS" är ett primärt fält.

ANMÄRKNING

"RFL" är definierat som ett primärt fält. Det enda tillfället då ett primärt fält får användas som ett underordnat fält är då det primära fältet inkluderas i ett listfält. (Se Exempel 3 ovan.)

5. SYNTAXREGLER FÖR ADEXP

5.1. Lexikaliska element

5.1.1. Teckenuppsättning

5.1.1.1. Den teckenuppsättning som skall användas för utväxling av meddelanden i ADEXP- format skall vara det internationella alfabetet nummer 5 (IA-5) enligt definition i referensdokument 1.

5.1.1.2. ADEXP-formatet har utformats som ett utbytesformat dator till dator och kan sändas via olika datornätverk eller via dedikerade linjer mellan datorer. Dessutom finns ett behov av att kunna utväxla vissa ADEXP-meddelanden, normalt för färdplanering och flygledningstjänster (ATFM), på luftfartens fasta fjärrskriftnät (AFTN).

5.1.1.3. Meddelanden som kan behöva sändas via AFTN skall ha sina teckenuppsättningar begränsade till de tecken som har en direkt överensstämmelse med internationellt telegrafalfabet nummer 2 (ITA-2) och IA-5, enligt definition i referensdokument 1.ANMÄRKNING

Förutom skrifttecken och formatkommandon, enligt nedanstående definition, definierar teckenuppsättningen ITA-2 "signaler" (som exempelvis perforerade band). Dessa är inte del av den tillåtna teckenuppsättningen för ADEXP-meddelanden.

5.1.1.4. De tecken som är tillåtna för användning i ADEXP-meddelanden som får sändas via AFTN, är de skrifttecken och formatkommandon som definierats nedan:

Skrifttecken

a) Stora bokstäver, versaler (A till Z)

b) Siffror (0 till 9)

c) Speciella grafiska tecken, enligt följande:

1) mellanslag " "

2) vänsterparentes "("

3) högerparentes ")"

4) bindestreck "-"

5) frågetecken "?"

6) kolon ":"

7) punkt "."

8) komma ","

9) apostrof "'"

10) likhetstecken "="

11) plustecken "+"

12) snedstreck "/"

Formatkommandon

a) Valsretur

b) Radmatning

5.1.2. Grundläggande lexikaliska enheter

Följande lexikaliska enheter har definierats för användning i denna specifikation:

- ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'

- DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

- ALPHANUM ::= ALPHA | DIGIT

- SPACE ::= ' '

- HYPHEN ::= '-'

- FEF ::= Carriage_return | Line_Feed

- SEP ::= 1{ SPACE | FEF }

- SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'

- CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN

- LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF

- START-OF-FIELD ::= HYPHEN

ANMÄRKNING

LIM_CHAR representerar vilken som helst av de tillåtna tecknen med undantag av HYPHEN (bindestreck), vilket har reserverats för att indikera början av ett fält. I motsats till detta, representerar CHARACTER vilket som helst av de tillåtna enheterna i teckenuppsättningen.

5.1.3. Linjer och avgränsare

5.1.3.1. Uppdelningen av texten i ett meddelande till rader skall inte ha någon syntaktisk påverkan.

5.1.3.2. En avgränsare kan vara ett mellanslag eller ett formatkommando.

5.1.3.3. Fält skall beskrivas endast genom förekomsten av ett fältstarttecken efterföljt av ett nyckelord.

5.1.3.4. Följaktligen kan hela meddelandet bestå av en rad.

5.1.4. Teckenberoende värden

5.1.4.1. Det kan vara nödvändigt att ange ett numeriskt värde som negativt.

5.1.4.2. Fält där ett negativt värde krävs, skall, inom definitionen för dess syntax, uttryckligen ange värdet som ett teckenberoende värde, dvs. som antingen positivt eller negativt. Ett fält som ej har definierats på detta vis får inte representera ett negativt värde.

5.1.4.3. Ett "teckenberoende värde" skall alltid föregås av antingen bokstaven "N", i betydelsen negativ, eller "P", i betydelsen positiv. Ett nollvärde kan föregås av antingen "N" eller "P".

5.1.4.4. Syntax för ett fält som tillåter ett "teckenberoende värde" skall vara enligt följande:

'-' "NØGLEORD" ("P" | "N") ! 1{DIGIT}

Exempel

Ett fält med beteckningen "NUMBER", vilket kan innehålla ett negativt värde bestående av en till åtta siffror, skulle definieras som

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

vilket innebär följande:

-NUMBER P5 - motsvarar värdet +5

-NUMBER N5 - motsvarar värdet -5

-NUMBER 5 - ogiltigt syntax. Antingen måste ett "P" eller ett "N" förekomma

5.1.5. Nyckelord

5.1.5.1. Ett nyckelord är en följd, vilken som helst, av stora bokstäver (versaler) eller siffror. Det introducerar ett fält endast då det föregås av ett fältstarttecken ("-").

keyword ::= 1{ ALPHANUM }

5.1.5.2. Nyckelord skall överensstämma med följande syntax:

'-'!{SEP}!"NØGLEORD"!1{SEP}! < subfield/s or contained value >

dvs. ett nyckelord skall vara skilt från dess "fältstarttecken" med noll eller fler avgränsare. Det skall omedelbart åtföljas av en eller fler avgränsare, följda av motsvarande underordnat fält eller ingående värde.

ANMÄRKNING

Det är viktigt att notera, att ett nyckelord och dess föregående fältstarttecken får avdelas med vilket som helst antal av avgränsare, även ingen.

Exempel (Alla de följande sekvenserna redovisar ett giltigt fält.)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Rekommendation

Det är rekommenderad praxis att undvika användandet av en avgränsare mellan fältstarttecknet "-" och det efterföljande nyckelordet.

ANMÄRKNING

1) I ovanstående exempel är det första fallet det rekommenderade valet.

2) Det är också viktigt att notera att ett nyckelord omedelbart måste åtföljas av minst en avgränsare.

5.1.5.4. Genom hela dokumentet gäller att hoplänkningen av element åtskilda av åtminstone en avgränsare representeras otvetydigt av beteckningen "lös hoplänkning" (se 3.5).ANMÄRKNING

Som kommer att förklaras senare, inleder nyckelord också listfält när dessa föregås av nyckelordet BEGIN.

5.1.5.5. Nyckelord skall hållas så korta som möjligt samtidigt som de måste ha en meningsfull språklig innebörd.

5.1.5.6.

>Plats för tabell>

5.1.5.7. För att förhindra tvetydighet (användning av samma nyckelord med olika innebörd) eller redundans (olika nyckelord med samma innebörd), upprätthålls en central definitionstabell för primära fält (dvs. primära nyckelord) i bilaga A (A3) i denna standard, och en central definitionstabell för underordnade fält (dvs. sekundära nyckelord) i bilaga A (A4).

5.2. Fält

5.2.1. Fältsyntax

field ::= basic_field | structured_field | list_field

basic_field ::= '-' keyword contained_values

contained_values ::= {CHARACTER}

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

structured_field ::= '-' keyword field_1 field_2 ...field_n

ANMÄRKNING

Som det kommer att visa sig då det gäller listfält, föregås nyckelordet inte direkt av "-" utan av konstruktionen "-""BEGIN".

5.2.2. Sammansättning av meddelanden med avseende på beteckning på fält

5.2.2.1. Det första fältet i ett ADEXP-meddelande skall alltid vara ett titelfält (dvs. ett fält som påbörjas med nyckelordet TITLE).

5.2.2.2. Det efterföljande innehållet i ett meddelande, i form av dess primära fält, skall definieras genom dess TITLE.

5.2.2.3. Syntaxen i de meddelanden som motsvaras av en TITLE skall definieras genom de fält som ingår (vilka definieras av deras nyckelord):

- Namnet och tillåtet innehåll i dess primära fält.

- Namnet och tillåtet innehåll i dess sekundära fält.

5.2.3. Enkla fält

5.2.3.1. Syntaxen för enkla fält skall vara enligt följande:

basic_field ::= '-' keyword contained_values

5.2.3.2. Uttrycket "Contained_values" definierar den text som tillhandahåller betydelsen på fältet och får inte påbörja något underordnat fält.Regelexempel

arctyp ::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ") ANMÄRKNING

1) En otvivelaktig, likvärdig regel för vilket gäller:

arctyp ::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) Exempel på del av meddelande: "-ARCTYP ZZZZ".

5.2.3.3. Rekommendation

När ett enkelt fält innehåller fler än två värden, och det dessutom förekommer ett behov av att uttrycka ett urval eller valfrihet mellan värdena, rekommenderas att fältet görs som ett strukturerat fält och att värdena inkluderas i underordnade fält.

5.2.4. Listfält

5.2.4.1. Syntaxen för listfält skall vara enligt följande:

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

5.2.4.2. De underordnade fälten kan vara vilken kombination som helst av underordnade fält vilka tillåts förekomma noll eller flera gånger inom listfältet.

5.2.4.3. Listan över underordnade fält inom ett givet listfält skall utgöra en ordningsföljd (ordningsföljden på underordnade fält är betydelsefull).Regelexempel

addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"ANMÄRKNING

1) Detta exempel visar, att ett "addr" fält är ett listfält innehållande 0 eller flera förekomster av ett "fac" underordnat fält (en ATS installation).

2) En exempeldel av ett meddelande som visar ADDR som ett listfält innehållande FAC underordnade fält är:

-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) Ett exempeldel av ett meddelande som visar en kombination av underordnade fält är:

xxx ::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5. Strukturerade fält

5.2.5.1. Syntaxen för ett strukturerat fält skall vara enligt följande:

structured_field ::= '-' keyword field_1 field_2...field_n

5.2.5.2. De tillåtna, ingående underordnade fälten i ett givet strukturerat fält skall endast vara beroende på det strukturerade fältet i sig själv.

5.2.5.3. Ordningsföljden på förekomsten av underordnade fält i ett strukturerat fält skall inte vara betydelsefullt, vilket senare medger enkla förlängningar (genom tillägg av nya underordnade fält).Regelexempel

pt ::= '-' "PT" ptid [fl] [eto] ANMÄRKNINGAR

1) Detta definierar "pt" fältet som ett strukturerat fält innehållande en punkt ("ptid" underordnat fält), valfritt följt av en beräknad flygnivå ("fl" underordnat fält), valfritt följd av en beräknad tidpunkt över punkten ("eto" underordnat fält).

2) Ett exempel på förekomst av detta fält kan vara:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

5.2.5.4. Rekommendation

Närhelst man kan ana att innehållet i ett fält senare kan komma att utvecklas, är det önskvärt att göra det till ett strukturfält. Detta kommer att tillåta gradvis utökning av dess underordnat fält. I motsats till detta kan ett enkelt fält vara lättare eller mer bekant att använda men det påtvingar en fast följd av element (värden) med mycket reducerade utbyggnadsmöjligheter.

5.2.6. COMMENT fältet

5.2.6.1. Comment fältet introducerar ett område för fri text där alla tillgängliga tecken, utom fältstarttecknet ("-"), kan användas, och som utsträcker sig till nästa fält.

comment ::= '-' "COMMENT" { LIM_CHAR }

Exempel

-COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

5.2.7. Titelfältet (TITLE)

5.2.7.1. Det första fältet i ett ADEXP-meddelande skall alltid vara ett titelfält TITLE. Syntaxen för detta skall vara enligt följande:

title ::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2. De möjliga värdena i ett titelfält består av en uppsättning av ADEXP-meddelandetitlar som listats i bilaga B i denna standard.Exempel

-TITLE IFPL

6. NORMALISERAD BESKRIVNING AV ADEXP-MEDDELANDEN

6.1. Inledning

6.1.1. Följande avsnitt beskriver hur formatet i ADEXP för olika typer av meddelanden skall beskrivas på ett normaliserat sätt inom ramarna för nuvarande standard.

6.1.2. Den normaliserade beskrivningen omfattar:

- Definition av hjälputtryck;

- Definition av varje primärt fälts syntax och betydelse;

- Definition av varje underordnat fälts syntax och betydelse;

- Definition av varje grupp av meddelanden med hänvisning till dess beskrivande dokumentation.

6.1.3. Denna standard tillhandahåller inte detaljerna för sammansättning av fält eller regler för insättande av data i varje meddelandetitel.

6.1.4. Hänvisningar skall göras till den beskrivande dokumentationen (specifikation av gränssnitt) som är tillämpbar för varje meddelandegrupp. (Se avsnitt 6.5.7).

6.1.5. Beskrivande dokumentation skall, på ett normaliserat sätt, tillhandahålla följande information för varje meddelandetitel:

- en lista över obligatoriska primära fält;

- en lista över valfria primära fält;

- reglerna för insättande av data i varje fält och, i synnerhet, reglerna berörande användandet av underordnade fält vilka definierats som valfria inom denna standard;

- reglerna beträffande återskapande efter upptäckt av ett oidentifierat fält.

6.1.6. De fält, för användning inom de olika kategorierna av meddelanden som används i ADEXP, som för närvarande är definierade och accepterade av medlemsstaterna i Eurocontrol, är de som föreskrivs i bilaga A i detta dokument.

6.1.7. Ett fält skall inte användas i annat syfte än för de som fastställts i dess betydelsebeskrivning.

6.1.8. Ett centralt register över reserverade fält finns i bilaga D. "Reserverade fält" har inte godkänts för användning i den nuvarande definitionen av ADEXP-meddelanden. Normalt är dessa fält sådana som har bedömts kunna komma till användning i framtiden, eller som används lokalt i nationella system. Syftet med att inkludera dem i denna standard, är att bidra till att säkerställa att fälttitlar förblir unika och att förhindra onödig övertalig förekomst.

6.2. Hjälputtryck

6.2.1. I syfte att tillhandahålla en läsbar definition av fält, är det ofta användbart att införa hjälputtryck i den grammatiska beskrivningen.

6.2.2. Hjälputtryck innehåller inte något fält eller underordnat fält och är således inte associerat med något speciellt nyckelord. De kan emellertid förekomma i definitionen av mer än ett fält eller underordnat fält, eller hjälputtryck. T.ex. kan ett hjälputtryck som "date" användas i definitionen av många fält.

6.2.3. Alla nödvändiga hjälputtryck skall införas i alfabetisk ordningsföljd och finns definierade i bilaga A (A2) i denna standard.

6.2.4.

>Plats för tabell>

6.3. Definition av primära fält

6.3.1. Alla primära fält som används i ADEXP-meddelanden skall överensstämma med det syntax och den betydelse som angivits i bilaga A (A3) i denna standard.

6.3.2. Syntax för varje fält anges först, och därefter anges dess betydelse i enkel otvetydig klartext.

6.3.3. Syntax för fälten uttrycks genom användandet av BNF-normen, vilken beskrivits i avsnitt 3 i denna standard.

6.3.4.

>Plats för tabell>

6.4. Definition av underordnade fält

6.4.1. Alla underordnade fält som används i ADEXP-meddelanden skall överensstämma med det syntax och den betydelse som angivits i bilaga A (A4) i denna standard.

6.4.2. Dessutom är, i korsreferenssyfte, det primära fältet, i vilket ett givet underordnat fält förekommer, identifierat.

6.4.3. Ett underordnat fält kan också vara ett underordnat fält eller andra underordnade fält. Därför ges även en korsreferens till dessa underordnade fält.

6.4.4.

>Plats för tabell>

6.5. Meddelandegrupper

6.5.1. De operativa kategorierna (grupperna) av meddelanden som har definierats för användning i ADEXP-formatet, beskrivs i bilaga E i denna standard.

6.5.2. Grupperna definieras med avseende på den operativa naturen av de meddelanden som utväxlas och är ofta utmärkande för berörda system.

6.5.3. Hänvisning till den definierande dokumentationen skall göras för varje meddelandegrupp.

6.5.4. Ingen namnbeteckning som redan använts för en meddelandegrupp skall återanvändas för en annan grupp med annan betydelse.

6.5.5. Ett centralt register över namnbeteckningar på meddelanden skall upprätthållas i bilaga B i denna standard.

6.5.6. En hänvisning till berörd grupp ges för varje meddelandenamn som listats i det centrala registret över meddelandenamn. Hänvisning till den definierande dokumentationen för varje meddelandenamn tillhandahålls därför via meddelandegruppen.

6.5.7. Ett centralt register över reserverade meddelandenamn finns också i bilaga C. "Reserverade" meddelandenamn har ännu inte accepterats för användning inom de nu fastställda meddelandegrupper som använder ADEXP. Normalt är dessa meddelanden som har bedömts kunna komma till användning i framtiden inom någon av de fastställda grupperna, eller som används i nationella system. Syftet med att inkludera dem i denna standard, är att bidra till att säkerställa att meddelandenamn förblir unika och att förhindra onödig övertalig förekomst.

BILAGA A (Normativ)

DEFINITIONER AV ADEXP-FÄLTEN

A.1. Inledning

Denna bilaga tillhandahåller en sammanställning av alla fält: hjälputtryck, primära fält och underordnade fält som har definierats för användning i ADEXP.

A.2. ADEXP-hjälputtryck

>Plats för tabell>

A.3. ADEXP Primära fält

>Plats för tabell>

A.4. ADEXP Underordnade fält

>Plats för tabell>

BILAGA B (Normativ)

CENTRAL FÖRTECKNING ÖVER TITLAR PÅ ADEXP-MEDDELANDE

>Plats för tabell>

BILAGA C (Normativ)

CENTRAL FÖRTECKNING ÖVER RESERVERADE MEDDELANDETITLAR

C.1. Inledning

Denna bilaga innehåller en central förteckning över reserverade meddelandetitlar som ännu inte har definierats för användning i ADEXP. Att de finns upptagna i denna bilaga indikerar att de antingen förutsetts för framtida användning, eller att de redan används men att deras användning är begränsad till lokala system.

C.2. Syfte

Syftet med att tillhandahålla en lista med titlar som ännu ej formellt har antagits för användning inom denna ADEXP-standard är att förhindra, i största möjliga utsträckning, antingen skapandet av överflöd närhelst en ny titel behövs för ett särskilt ändamål eller skapandet av en titel som redan används i ett lokalt system.

C.3. Reserverade meddelandetitlar

>Plats för tabell>

BILAGA D (Normativ)

CENTRAL FÖRTECKNING ÖVER RESERVERADE FÄLT

D.1. Inledning

Denna bilaga innehåller en central förteckning över reserverade fält, primära, underordnade fält och hjälputtryck som ännu inte har definierats för användning i ADEXP. Att de finns upptagna i denna bilaga indikerar antingen att de förutsetts för framtida användning, eller att de redan används men att deras användning är begränsad till lokala system.

D.2. Syfte

Syftet med att tillhandahålla en lista med fält som ännu ej formellt har antagits för användning inom denna ADEXP-standard är att förhindra, i största möjliga utsträckning, antingen skapandet av redundans närhelst ett nytt fält behövs för ett särskilt ändamål eller att ett nyckelord införs som redan används i ett lokalt system.

D.3. Reserverade Hjälputtryck

>Plats för tabell>

D.4. Reserverade primära fält

>Plats för tabell>

D.5. Reserverade Underordnade fält

>Plats för tabell>

BILAGA E (Informativ)

INTRODUKTION AV MEDDELANDEGRUPPER

INLEDNING

Denna bilaga tillhandahåller en introduktion till de olika grupperna eller kategorierna av meddelanden som kan utväxlas i ADEXP. En fullständig sammanställning över samtliga titlar på ADEXP-meddelanden i finns i bilaga B.

ANMÄRKNING

För exakta villkor, tillämpningsregler och användande av fält, särskilt användandet av valfria fält, skall hänvisning göras till relevant dokumentation (t.ex. dokument för specifikation av gränssnitt) för berörda system.

E.1. Färdplansmeddelanden

E.1.1. Inledning

Meddelanden inom denna kategorin utväxlas i första hand mellan AO, IFPS och relevanta ATS-enheter.

E.1.2. Definition av meddelandetitlar

Meddelandetitlar inom denna kategori är:

ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.

Allt definitionsunderlag för dessa meddelanden finns i referensdokument 3

E.1.3. Sammansättning av primära fält

Detaljerad definition av meddelandeinnehåll, regler för användande av data och användandet av obligatoriska och valfria fält återfinns i referensdokument 3.

Exempel:

Färdplansmeddelande

-TITLE IFPL

-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC EGZYTTTE -FAC EGTTZGZP

-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC LPPCIFPS -FAC LPPTYWYA

-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS

-END ADDR

-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -CEQPT S

-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686 -ORGNID AZXRPLO

-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -SPEED N0400 -FLTRUL I

-FLTTYP S

-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS UG41 FTM

-BEGIN RTEPTS

-PT -PTID EGKK -FL F000 -ETO 980305113000

-PT -PTID SAM -FL F196 -ETO 980305114012

-PT -PTID ASPEN -FL F288 -ETO 980305114658

-PT -PTID ORTAC -FL F311 -ETO 980305114959

-PT -PTID GUR -FL F330 -ETO 980305115617

-PT -PTID AKEMI -FL F330 -ETO 980305120118

-PT -PTID LARSI -FL F330 -ETO 980305120626

-PT -PTID QPR -FL F330 -ETO 980305121236

-PT -PTID ERWAN -FL F330 -ETO 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

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

-ATSRT UG41 AVS FTM

E.2. Meddelanden från flygledningstjänsten (ATFM-meddelanden)

E.2.1. Inledning

Meddelanden inom denna kategori utväxlas i första hand mellan TACT-systemet inom Eurocontrol CFMU, flygplansoperatörer och ATS-enheter.

E.2.2. Meddelanden rörande datorstödd slot-tilldelning (CASA)

Meddelandetitlar inom denna kategori är:

DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.

E.2.2.1. Definition av meddelandetitlar

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 5.

E.2.2.2. Sammansättning av primära fält

Detaljerad definition av meddelandeinnehåll, regler för användande av data och användandet av obligatoriska och valfria fält återfinns i referensdokument 5.

Exempel:

-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945

-CTOT 010 -REGUL UZZU11 -TAXITIME 0020

E.2.3. Informationsmeddelanden

Meddelanden inom denna kategori är:

FSA

E.2.3.1. Definition av meddelandetitlar

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 5.

E.2.3.2. Sammansättning av primära fält

Detaljerad definition av meddelandeinnehåll, regler för användande av data och användandet av obligatoriska och valfria fält återfinns i referensdokument 5.

Exempel:

Första systemaktiveringsmeddelande

-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646

E.3. ATC-samordningsmeddelanden

E.3.1. Inledning

Samordningsmeddelanden används för att automatisera operationell samordning och utbyte av information mellan ATC-enheter. Meddelandena säkerställer leverans i rätt tid av operationell information relaterad till samordning genom standardisering av utdrag av data och överföringskapacitet.

E.3.2. Definition av meddelandetitlar

Meddelandetitlar inom denna kategori är:

ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 6.

E.3.3. Sammansättning av primära fält

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 6.

Exempel:

Medelande med förslag om överlämning

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN

Aktiveringsmeddelande

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253

-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350

-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

E.4. Meddelanden om ledning av luftrum

E.4.1. Inledning

Meddelanden använda för samordning av ledning av luftrum. Dessa meddelanden täcker ledningen av den omgivning som trafikeras: de permanenta och villkorliga färdvägarna, tillfälligt avskilda områden, farliga och förbjudna områden etc.

E.4.2. Definition av meddelandetitlar

Meddelandetitlar inom denna kategori är:

AUP, CRAM, UUP.

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 7.

E.4.3. Sammansättning av primära fält

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 7.

Exempel:

Meddelande om tillgänglighet av villkorlig färdväg

-TITLE CRAM -PART -NUM 001 -LASTNUM 010

-FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600

-BEGIN LACDR

-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600

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

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

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

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

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

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

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

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

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

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

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

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

-END LACDR

E.5. Civila/militära samordningsmeddelanden

E.5.1. Inledning

Meddelanden som används i samordningen för flygdata och förfrågningar om korsande av luftrum mellan civila och militära ATS-enheter.

E.5.2. Definition av meddelandetitlar

Meddelandetitlar inom denna kategori är:

ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 7.

E.5.3. Sammansättning av primära fält

Allt definitionsunderlag för dessa meddelanden återfinns i referensdokument 7.

Exempel:

Meddelande med begäran om tillstånd för överfart

-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP F111 -SECTOR SOUTH

-BEGIN RTEPTS

-PT -PTID GEO01 -TO 1630 -FL F250

-PT -PTID GEO02 -TO 1631 -FL250

-END RTEPTS

-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E

-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E

Godtagandemeddelande

-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ

-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012

BILAGA F (Informativ)

EXEMPEL PÅ ADEXP-MEDDELANDEFORMAT

Följande exempel tillhandahålls som en demonstration av ADEXP-formatet, inte som ett exempel på innehåll i ett meddelande. Meddelandet som används är en IFPL, men trots att det var korrekt vid tidpunkten för publicerandet, kan inte riktigheten av fältsammansättning etc. garanteras.

Exempel 1 nedan har utformats på ett sätt som gör det lätt att läsa. Detta har uppnåtts genom användande av valsreturer, radmatningar, indragningar etc. En sådan uppställning är dock inte del av reglerna i ADEXP-formatet.

Utformning av ett meddelande är därför beroende av urskillningsförmågan i det mottagande systemet. EXEMPEL 2 och EXEMPEL 3 är båda giltiga återgivanden av samma meddelande som i EXEMPEL 1.

EXEMPEL 1

-TITLE IFPL

-BEGIN ADDR

-FAC CFMUTACT

-FAC LFFFSTIP

-FAC EDFFZRZL

-FAC EDZZZQZA

-FAC EDUUZQZA

-FAC LOVVZQZX

-FAC LHBPZEZX

-FAC LYBAZQZX

-FAC LWSSZQZX

-FAC LGTSZAZX

-END ADDR

-ADEP EDDF

-ADES LGTS

-ARCID DLH3728

-ARCTYP B73A

-CEQPT SDMRY

-EOBD 980517

-EOBT 0715

-FILTIM 170421

-IFPLID AA05966101

-ORGNID DLHAOCC

-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH

-REG DABHM

-SEL KMGJ

-SRC FPL

-FLTTYP S

-WKTRC M

-TTLEET 0210

-RFL F330

-SPEED N0417

-FLTRUL I

-SEQPT C

-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26

SAVIN UG18 BUI UB1 TALAS

-ALTRNT1 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

EXEMPEL 2

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

EXEMPEL 3

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

BILAGA G (Informativ)

FRAMTIDA UTVECKLINGAR

G.1. Inledning

Denna bilaga tillhandahåller en anvisning om den föreslagna framtida utvecklingen av ADEXP samt anledningarna och målsättningarna bakom utvecklingen.

G.2. Målsättning

En av de viktigaste målsättningarna under utvecklingen av ADEXP var kravet på att utveckla ett format som skulle möjliggöra ett mottagande system att framgångsrikt "ignorera" eller "hoppa över" ett okänt eller inte erkänt fält utan att nödvändigtvis ogiltigförklara det behandlade meddelandet. Införandet av detta kan tillåta tillägg av nya fält inom ett meddelande utan krav på att ha alla mottagande system modifierade i förväg åtföljt av en mycket väl samordnad "övergång". Den enorma flexibilitet som detta kan tillhandahålla är en av fördelarna med ADEXP-formatet.

Denna målsättning uppnås under nuvarande standard genom användandet av fördefinierade primära och underordnade fält, introducerade genom unika nyckelord. En lexikalisk analysator som inte "godtar" ett nyckelord krävs för att ignorera all text fram till nästa kända primära fält som inte finns inom ett listfält. Återvinnande uppnås därför på primärfältsnivå.

Nuvarande och framtida utveckling av definitionen av nya meddelanden indikerar att det inom vissa områden krävs en högre grad av komplexitet, i vilken uppsättningar av fält på tredje och till och med fjärde nivå behövs. (Meddelandet om villkorlig tilldelning av färdväg (CRAM) är ett nuvarande exempel på detta krav.) ADEXP tillhandahåller idag möjligheten att sammansätta ett meddelande med uppsättningar på alla nivåer. Förmågan till återvinning av ett ej erkänt underordnat fält, som återfinns på kanske den tredje eller fjärde nivån, utan risk för feltolkning av data eller risk för att meddelandet ogiltigförklaras finns emellertid inte. De föreslagna förändringarna som krävs för ADEXP-formatet är utformade för att säkerställa, att en lexikalisk analysator alltid kan fastslå var den befinner sig inom strukturen av ett meddelande eller ett individuellt fält, och därigenom möjliggöra att återvinning kan ske på alla nivåer utan risk för felaktig tolkning av data.

G.3. Förslag

För att uppnå målsättningen med återvinning på alla nivåer av ett meddelande, är det nödvändigt att den lexikaliska analysatorn kan fastställa slutet, såväl som början av ett fält. Det nuvarande formatet möjliggör endast fastställande av början av ett fält genom användadet av tecknet "-".

Det kommer att föreslås, i en framtida utgåva av ADEXP, att introducera användandet av parenteser för att indikera början respektive slutet av ett fält. Den nuvarande användningen av tecknet "-" för att markera början av fält skulle ersättas av tecknet "(". Slutet av ett fält, vilket inte är uttryckligen markerat idag, skulle markeras med tecknet ")". Följande exempel är ämnade för att demonstrera principen.

Exempel

>Plats för tabell>

BILAGA III

UTBYTE AV FLYGDATA - DOKUMENT FÖR KONTROLL AV GRÄNSSNITT (FDE-ICD), UTGÅVA 1.0

(Eurocontrol-dokument COM.ET1.ST12-STD)

OBS: översättning av texten finns redan

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

Denna standard har sammanställts och upprätthålls av arbetsgruppen för utbyte av färdplansrelaterad data FPDE (Flight Plan related Data Exchange) inom europeiska organisationen för luftfartssäkerhet (Eurocontrol).

2. Eatchips arbetsprogramdokument

Denna standard har anknytning till Eatchips arbetsprogramdokument (EWPD), domänen för kommunikation, verkställande uppdrag 01, specialistuppdrag 12

3. Godkännande av standarden

3.1. Denna standard har antagits i enlighet med de förfaranden som beskrivs i Eurocontrols standardiseringsanvisningar, (Directives for Eurocontrol Standardisation), Ref. 000-2-93.

3.2. Denna standard träder i kraft när den antas av Eurocontrols ständiga kommission, och ersätter Eurocontrolstandard för utbyte on-line av data (OLDI), utgåva 1, del 3: Tekniska krav (korttidsdokument för gränssnittskontroll) Ref. 001-3-92.

4. Tekniska rättelser och ändringar

Denna standard hålls under granskning för att säkerställa erforderliga ändringar eller tekniska rättelser. Förfarandet för uppdatering av denna standard fastställs i bilaga H i anvisningarna för enhetliga utkast och utformning av Eurocontrols standarddokument, Ref. 000-1-92.

5. Redaktionella regler

5.1. Formatet på denna standard överensstämmer med anvisningarna för enhetliga utkast och presentationer av Eurocontrolstandarder.

5.2. Följande beteckningssätt har använts för att ange status på respektive utlåtande:

- Normativa delar använder det modala hjälpverbet "skall" och har skrivits med normal text.

- Rekommenderade delar använder det modala hjälpverbet "bör" och har skrivits med kursiv stil. Status indikeras med prefixet Rekommendation.

5.3. All annan information som betraktas som väsentlig för förståelsen av ett särskilt stycke är infogad som en ANMÄRKNING. Anmärkningar anses vara enbart informativa, varför de inte innehåller specifikationer. Anmärkningar är placerade direkt efter det stycke de hänvisar till.

5.4. För att presentera profilkravslistorna (PRL) i bilaga E i ett lämpligt format, är undantagsvis en del tabeller inte formaterade med indrag och löper inte heller över flera sidor.

6. Förhållande till andra standarder

6.1. Denna Eurocontrolstandard ersätter OLDI:s korttidsdokument för gränssnittskontroll, ST-ICD, (Short Term Interface Control Document), del 3, utgåva 1 av OLDI Eurocontrolstandard [Referens 13].

6.2. Denna Eurocontrolstandard är den första delen i en planerad serie av Eurocontrolstandarder för kontroll av gränssnitt (Interface Control Documents - ICDs) för utbyte av flygdata.

7. Status på bilagorna till denna standard

Bilagorna till denna standard har följande status:

- Bilaga A - normativ

- Bilaga B - normativ

- Bilaga C - normativ

- Bilaga D - normativ

- Bilaga E - normativ

- Bilaga F - informativ

- Bilaga G - informativ

- Bilaga H - informativ

8. Använt språk

Originaltexten i denna standard är skriven på engelska.

1. INLEDNING

Denna Eurocontrolstandard är baserad på det korttidsdokument för gränssnittskontroll som utvecklades av den tidigare tekniska undergruppen inom OLDI, vilken hade som uppgift att definiera nya gränssnittsstandarder för den framtida användningen av OLDI mellan regionala ledningscentraler.

Tidigare OLDI-förbindelser baserades på ägarskyddade protokoll som t.ex. INTERCAUTRA och Datenübertragungs- und Verteilungssystem (DÜV). Dessa använder sig av dedikerade direktlinjer eller begränsade nätverk och kräver speciell utrustning och programvara.

För det större antal nya förbindelser som planeras ansågs det önskvärt att övergå till en nätverksbaserad arkitektur, samt att anta internationella standarder för telekommunikation. Detta för att kunna upprätta förbindelser på ett mer kostnadseffektivt sätt, genom en minskning av antalet anslutningar i varje central och möjligheterna att använda sig av standardiserad maskin- och -programvara.

Denna Eurocontrolstandard formaliserar och utvidgar korttidsdokumentet för gränssnittskontroll. ST-ICD har omarbetats för att ge en noggrannare specifikation som kommer att förbättra samverkan och som dessutom är lämplig som grund för att framtida dokument för gränssnittskontroll skall kunna uppfylla de framtida kraven på utbyte av flygdata (FDE), inklusive mer utbredd användning av delade nätverk och införandet av nya standarder för lägre skikt. Denna Eurocontrolstandard tillhandahåller en minimiuppsättning av funktioner som kan stödjas av befintliga OLDI-tillämpningar, med minimala modifieringar, genom användandet av antingen direktlinjer eller Comité Consultatif des Téléphones et Télégraphes (CCITT) rekommendation X.25, 1980 eller senare, över paketförmedlande nätverk. För anskaffande kan flera möjligheter specificeras. Detta ICD förhindrar inte att bilaterala avtal utvecklas utöver detta.

Centraler som önskar använda andra tillämpningsprotokoll som tillägg till, eller som ersättning för, det som beskrivs i detta dokument, kan antingen ansöka om ändring av det nuvarande protokollet, eller separera sina protokoll genom användandet av skilda virtuella kretsar.

2. OMFATTNING

2.1. Denna Eurocontrolstandard specificerar ett gränssnitt för datakommunikation för utväxling av flygrelaterade meddelanden mellan regionala ledningscentraler (ACC). Det presenteras i formen av en OSI-profil (Open Systems Interconnection - OSI) enligt definitionen i Internationella standardiseringsorganisationen/Internationella elektrotekniska kommissionens (ISO/IEC) tekniska rapport (TR) 10000-2 [Referens 3]. Profilen omfattar både undre skikt (T-profil) och övre skikt (A-profil).

2.2. Denna Eurocontrolstandard är tillämplig på följande:

- Stöd för OLDI enligt beskrivningen i Eurocontrolstandard 001-92 utgåva 1.

- Stöd för sändning av meddelanden från OLDI-tillämpningar från regionala ledningscentraler (ACC) till systemen för centralenheten för trafikflödeskontroll (Central Flow Management Unit - CFMU).

2.3. Standarden är tillämplig på anslutningar som använder antingen

- abonnerade direktlinjer,

- direktlinjer över det allmänna telenätet (PSTN), eller

- paketförmedlande datanätverk eller sammankopplade paketförmedlande datanätverk som tillhandahåller ett gränssnitt som uppfyller CCITT rekommendation X.25, 1980 eller senare.

ANMÄRKNINGAR

1. Samordningen mellan systemen för behandling av färdplaner - (FPPS) framgår av Figur 1.

2. Figur 1 visar inte tänkbara reservanslutningar, som t.ex. PSTN. Vägledning för detta ges i.

Figur 1

Arrangemang för gränssnitt

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

2.4. Detaljerade säkerhetsaspekter på det specificerade gränssnittet för datakommunikation tas inte upp i denna standard. Grundläggande åtgärder specificeras emellertid i Bilaga C.5.4, och ytterligare vägledning finns i Bilaga H till denna Eurocontrolstandard.

3. HÄNVISNINGAR

3.1. Inledning

Följande dokument och standarder innehåller villkor som genom referens i denna text utgör förutsättningar för denna Eurocontrolstandard.

Vid publiceringen av denna Eurocontrolstandard var utgåvorna som nämnts för de dokument och standarder, till vilka hänvisning skett, giltiga.

Alla revisioner av de dokument från Internationella civila luftfartsorganisationen (ICAO) som det hänvisats till, skall omgående beaktas för revision av denna Eurocontrolstandard.

Revisioner av de övriga dokument till vilka det hänvisats skall inte utgöra del av villkoren för denna Eurocontrolstandard förrän de formellt granskats och införts i denna Eurocontrolstandard.

Om konflikt uppstår mellan kraven i denna Eurocontrolstandard och innehållet i något av de övriga dokument till vilket hänvisning skett, skall denna Eurocontrolstandard ha företräde.

3.2. Referenser

1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit. (ITU-T-rekommendation X.25 (1993) (Rev. 1), Gränssnitt mellan terminalutrustning (DTE) och nätanslutningsenheter (DCE) för terminaler i paketförmedlande läge som är anslutna till allmänna datanätverk med dedikerade linjer.)

2. ISO/IEC TR 10000-1:1992, Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework (2nd edition). (ISO/IEC TR 10000-1:1992, Informationsteknologi - Ramverk och taxonomi för Internationella standardiserade profiler: - Del 1: Ramverk (2:a utgåvan).)

3. ISO/IEC TR 10000-2:1994, Information technology - Framework and taxonomy of International Standardized Profiles - Part 2: Principles and Taxonomy for OSI Profiles (3rd edition).(ISO/IEC TR 10000-2:1994, Informationsteknologi - Ramverk och taxonomi för Internationella standardiserade profiler: - Del 2: Principer och taxonomi för OSI- profiler (3:e utgåvan).)

4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks. (ITU-T-rekommendation X.21 (1992) (Rev. 1), Gränssnitt mellan terminalutrustning (DTE) och nätanslutningsenheter (DCE) för synkron drift på allmänna datanätverk.)

5. CCITT Recommendation X.21bis (1988), Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems. (CCITT-rekommendation X.21bis (1988), Användning av dataterminalutrustning (DTE), som konstruerats för gränssnitt till synkrona modem i V-serien, på allmänna datanätverk.)

6. ISO/IEC 7776:1994, Information technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2nd edition).(ISO/IEC 7776:1994, Informationsteknologi - Telekommunikations- och informationsutbyte mellan system - Förfaranden för kontroll av dataförbindelser på hög nivå - Beskrivning av de X.25 LAPB-kompatibla förfarandena för DTE-datalänkförbindelser (2:a utgåvan).)

7. ISO/IEC 8208:1993, Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment (3rd edition).(ISO/IEC 8208:1993, Informationsteknologi - Datakommunikation - X.25 paketskiktsprotokoll för terminalutrustning (3:e utgåvan).)

8. ISO/IEC ISP 10609-9:1992, Information technology - International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service - Part 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a packet-switched data network using virtual calls. (ISO/IEC ISP 10609-9:1992, Informationsteknologi - Internationella standardiserade profiler TB, TC, TD och TE - Transporttjänst för anslutningsläge över nätverkstjänst för anslutningsläge - Del 9: Subnätsberoende krav för nätverksskikt, datalänkskikt och fysiska skikt som rör permanent åtkomst till ett paketförmedlande datanätverk med virtuella anrop.)

9. ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model (2nd edition).(ISO/IEC 7498-1:1994, Informationsteknologi - Systemförbindelser mellan öppna system - Grundläggande referensmodell: Den grundläggande modellen(2:a utgåvan).)

10. ISO/IEC 8348:1993, Information technology - Open Systems Interconnection - Network Service Definition (1st edition).(ISO/IEC 8348:1993, Informationsteknologi - Systemförbindelser mellan öppna system - Definition av nätverkstjänst (1:a utgåvan).)

11. ISO/IEC 8072:1994, Information technology - Open Systems Interconnection - Transport service definition (2nd edition).(ISO/IEC 8072:1994, Informationsteknologi - Systemförbindelser mellan öppna system - Definition av transporttjänst (2:a utgåvan).)

12. ISO/IEC 8878:1992, Information Technology - Telecommunications and information exchange between systems - Use of X.25 to provide the OSI connection-mode Network Service (2nd edition). (ISO/IEC 8878:1992, Informationsteknologi - Telekommunikations- och informationsutbyte mellan system - Användande av X.25 för att tillhandahålla OSI-nätverkstjänster för anslutning (2:a utgåvan).)

13. Eurocontrol Standard for On-Line Data Interchange (OLDI), No 001-92, Edition 1, 1992. 1(Eurocontrolstandard för utbyte on-line av data (OLDI), 001-92, Edition 1, 1992.)

14. ISO/IEC 9646-1:1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (2nd edition). (ISO/IEC 9646-1:1994, Informationsteknologi - Systemförbindelser mellan öppna system - Metodik och ramverk för test av konformitet - Del 1: Allmänna begrepp (2:a utgåvan).)

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10 May 1996. (Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Del 1, Testplan för integration, Version 1.0, daterad 10 maj 1996.)

16. Eurocontrol FDE ICD Part 1 - Reliability, Availability and Security - Technical Report version 1.0, dated 20 April 1997. (Eurocontrol FDE ICD Del 1 - Tillförlitlighet, tillgänglighet och säkerhet - Teknisk rapport, version 1.0, daterad 20 april 1997.)

17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network. (ITU-T-rekommendation X.32 (1993) (Rev. 1), Gränssnitt mellan DTE och DCE för terminaler som fungerar i paketläge och som har åtkomst till paketförmedlat data över det offentliga telenätet, ett ISDN-nät eller ett allmänt kretskopplat datanät.)

18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering plan for the ISDN era. (ITU-T-rekommendation E.164 (1991) (Rev.1), Nummerplan för ISDN.)

19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-switched signalling system between public network providing data transmission service. (ITU-T-rekommendation X.75 (1993) (Rev. 1), Paketförmedlat signalsystem mellan allmänna nätverk som tillhandahåller dataöverföringstjänster.)

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks. (ITU-T-rekommendation X.121 (1993), Internationell nummerplan för allmänna datanätverk.)

4. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR

4.1. Definitioner

4.1.1. För denna Eurocontrolstandard gäller följande definitioner:

4.1.2. Profil: En grupp av en eller fler grundstandarder, och när tillämpligt, benämningen av utvalda klasser, undergrupper, valmöjligheter och parametrar i dessa grundstandarder som är nödvändiga för att uppnå en speciell funktion [Referens 2].

4.1.3. Profilkravslista (PRL): Profilkraven uttrycks som krav på överensstämmelse och har ordnats i tabellform [Referens 2].

4.1.4. T-profil: Transportprofil som tillhandahåller en transporttjänst för anslutningsläge [Referens 3].

4.1.5. A-profil: Tillämpningsprofil som kräver en transporttjänst för anslutningsläge [Referens 3].

4.1.6. Utlåtande om ett infört protokolls överensstämmelse (PICS): Ett uttalande från leverantören av ett OSI-system, i vilket det uppges vilka möjligheter som implementerats för ett bestämt OSI-protokoll [Referens 14].

4.2. Symboler och Förkortningar

>Plats för tabell>

4.3. Beteckningssätt

4.3.1. I denna Eurocontrolstandard betecknas binära tal eller en följd av bitar, med hexadecimala tal genom beteckningen 'd'H, där bokstaven "d" betyder ett tecken eller en följd av hexadecimala tecken.

4.3.2. I denna Eurocontrolstandard är det hexadecimala återgivandet av en följd av bitar uppbyggd genom att fyra bitar i taget tas, från den mest betydande biten (MSB) till den minst betydande biten (LSB).ANMÄRKNING

Om inte annat specificeras i de internationella standarder det hänvisas till, skickas en följd av bitar från MSB till LSB.

4.3.3. I denna Eurocontrolstandard skall statusen på stödet för funktioner i en grundstandard eller denna Eurocontrolstandard, anges med versaler (t.ex. M, O, O.< n >, X). Den exakta betydelsen av varje statussymbol beskrivs i bilagorna till denna Eurocontrolstandard före dess användning.

4.3.4. I syfte att definiera FDE ICD del 1-profilen i denna Eurocontrolstandard, skall statusen på stödet för funktioner i en grundstandard eller denna Eurocontrolstandard, anges med gemener (t.ex. m, o, o.< n >, x).ANMÄRKNING

Resultatet är en ytterligare förfining av de funktioner i grundstandarderna som är villkorade, valfria eller värdeberoende (se E.3.1).

5. TEKNISK ÖVERSIKT

5.1. Protokollstack

ANMÄRKNING

Protokollstacken för profilen i denna Eurocontrolstandard illustreras i Figur 2. Bilden visar protokollens placering i ramverket för den grundläggande referensmodellen för OSI [Referens 9] genom att återge stacken bredvid motsvarande OSI-skikt. Protokollstacken är emellertid specificerad för äldre system än OSI, och stödjer inte de många funktioner som tillåts i OSI-protokollen för motsvarande OSI-skikt.

Figur 2

Protokollstack för profilen

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

5.2. Profilens uppbyggnad

ANMÄRKNINGAR

1. Som visas i Figur 2, kombinerar profilens protokollstack flera protokoll i lägre skikt. Av dessa är endast X.25-protokollet för paketskikt (PLP) [Referens 1] och dess stödprotokoll, X.21 [Referens 4] och X.21bis [Referens 5], definierade i befintliga standarder hos ISO/IEC och Internationella teleunionen - sektorn för standardisering av telekommunikation (ITU-T). Övriga protokoll i högre skikt är definierade i bilagorna A, B och C till denna Eurocontrolstandard.

2. Profilens krav på överensstämmelse kan hänvisa till dessa specifikationer, som är jämförbara med externa standarder och anges i avsnitt 6. De detaljerade kraven framförs i tabeller över PRL (Bilaga E) och PICS-dokument (proforma för protokoll definierade i bilagorna anges i Bilaga D). Användandet av dessa PRL- och PICS-dokument vid utveckling och/eller anskaffande förklaras i Bilaga E.

5.3. Förhållande till tidigare versioner av specifikationen

ANMÄRKNINGAR

1. Denna profil grundar sig på det ST-ICD som utvecklades av den tidigare tekniska undergruppen inom OLDI. Protokollen och paketformaten som definieras i denna Eurocontrolstandard är en kompatibel undergrupp av de som definieras i ST-ICD, med undantag av att denna Eurocontrolstandard ställer mer detaljerade krav på användandet av X.25 PLP, inkluderar obligatoriskt stöd för M-biten samt korrigerar de motstridiga specifikationerna på myndighets- och format-ID (AFI) -värdet i adressen till punkten för tillgång till nätverkstjänster (NSAP).

2. Den huvudsakliga förändringen av utformningen av denna Eurocontrolstandard berör uppbyggnaden av ICD-specifikationen. Protokollet för meddelandeöverföring (Bilaga A) har avskiljts från den stödjande T-profilen. Detta underlättar användandet av andra T-profiler då detta blir nödvändigt för att stödja kommande FDE-krav.

3. De delar av ST-ICD som berör kontroll av virtuella kretsar för X.25 och avgränsande tillämpningsmeddelanden finns nu i protokollet för meddelanderubriker (Bilaga B), vilket utgör ett minimalt transportskikt för FDE.

6. PROFILKRAV

6.1. Krav för överensstämmelse

6.1.1. En implementering som påstås överensstämma med denna specifikation skall uppfylla kraven som framförs i avsnitten 6.2 och 6.3 nedan.

6.1.2. Ett påstående om överensstämmelse skall stödjas av ett utlåtande om ett infört protokolls uppfyllande (PICS) av standarden, enligt beskrivning i Bilaga D och Bilaga E.

6.2. Krav på övre skikt

6.2.1. En implementering skall för att överensstämma med grundstandarden uppfylla de krav som redovisas i Bilaga A.

6.2.2. En implementering skall för att överensstämma med standarden uppfylla de restriktioner som redovisas i profilkravslistan i bilaga E.7.

6.3. Krav på lägre skikt

6.3.1. Krav på transportskikt

6.3.1.1. En implementering skall för att överensstämma med grundstandarden uppfylla de krav som redovisas i Bilaga B.

6.3.1.2. En implementering som överensstämmer med standarden skall uppfylla restriktionerna som redovisas i profilkravslistan i bilaga E.8.1.

6.3.1.3. En implementering som överensstämmer med standarden skall uppfylla kravet på att stödja dataenheter för transporttjänst (TSDU) på upp till och med 4097 oktetter.ANMÄRKNING

Den första oktetten i en TSDU utgörs av ett fält för meddelanderubriken (se A.4.10 och B.4.4), vilket gör att maximalt 4096 oktetter kan användas till användardata.

6.3.2. Krav på nätverksskikt

6.3.2.1. En implementering som överensstämmer med standarden skall uppfylla kraven i ISO/IEC 8208 [Referens 7], i enlighet med protokollmappningen som redovisas i Bilaga C.

6.3.2.2. En implementering som överensstämmer med standarden skall uppfylla restriktionerna som redovisas i profilkravslistan i bilaga E.8.2.

6.3.2.3. En implementering som överensstämmer med standarden skall, om funktionen DTE-DTE stöds, ha förmågan att genom hanteringsmekanismer i systemet, styra valet av uppgift för DTE eller nätanslutningsenheter (DCE) för DTE-DTE-funktionen.

6.3.2.4. En implementering som överensstämmer med standarden skall för alla uppgifter beskrivna i 6.3.2.3, kunna initiera en förbindelse enligt specifikationen i Bilaga C, dvs. protokollet är helt symmetriskt.ANMÄRKNING

Vissa befintliga utföranden som baserats på ST-ICD kanske inte kan initiera nätverksförbindelser i enighet med protokollet i Bilaga C.

6.3.2.5. En implementering som överensstämmer med standarden skall under en tidsperiod tillåta icke standardiserade storlekar på standardpaket med värdet 256 i båda överföringsriktningarna.

6.3.2.6. En implementering som överensstämmer med standarden skall använda NSAP-adresser enligt definitionen i Bilaga C.

6.3.2.7. En implementering som överensstämmer med standarden skall sätta D-biten till 0 i CALL REQUEST-, CALL ACCEPTED- och DATA-paket.ANMÄRKNING

Att sätta D=0 i CALL REQUEST- och CALL ACCEPTED-paket motsvarar att överföringsbekräftelse inte används.

6.3.3. Krav på datalänkskikt

6.3.3.1. En implementering som överensstämmer med standarden skall uppfylla kraven som redovisas i ISO/IEC 7776 [Referens 6] för Link Access Protocol Balanced (LAPB) Single Link Protocol.

6.3.3.2. En implementering som överensstämmer med standarden skall också uppfylla restriktionerna som redovisas i profilkravslistan i bilaga E.8.3.

6.3.4. Krav på fysiska skikt

En implementering som överensstämmer med standarden skall uppfylla kraven som redovisas i ISO/IEC ISP 10609-9 klausul 7 [Referens 8].

7. TESTMETODER

ANMÄRKNINGAR

1. En metod för test av implementeringens överensstämmelse med denna specifikation beskrivs i Bilaga F.

2. Användandet av de PRL- och PICS-dokument som tillhandahålls med denna specifikation för dokumentering av överensstämmelse med standarden, beskrivs i Bilaga E.

BILAGA A (Normativ)

PROTOKOLL FÖR MEDDELANDEÖVERFÖRING

A.1. Inledning

Denna specifikation definierar ett protokoll avsett att implementera en enkel tjänst för meddelandeöverföring för tillämpningar som kräver utbyte av flygdata.

A.2. Implementerad tjänst

Protokollet för meddelandeöverföring (MT) implementerar följande obekräftade tjänster:

MT-Associate: Upprättar en anslutning för överföring av tillämpningsmeddelanden.

MT-Data: Överför ett tillämpningsmeddelande bestående av ASCII-tecken.

MT-Abort: Avslutar en anslutning för överföring av tillämpningsmeddelanden.

A.3. Förutsatt tjänst

Detta protokoll för meddelandeöverföring förutsätter en undergrupp av transporttjänsten för förbindelseläge enligt definitionen i ISO/IEC 8072 [Referens 11], som det som ingår i det protokoll som definieras i Bilaga B till denna Eurocontrolstandard.

A.4. Protokollspecifikation

A.4.1. Inledning

I följande text beskrivs endast funktionen för en tillämpningsinitierad anslutning för meddelandeöverföring. Ytterligare anslutningar kan upprättas med samma nätverksgränssnitt genom repetition av dessa förfaranden för varje underliggande transportförbindelse.

A.4.2. Datatyper

Denna bilaga identifierar fyra typer av programmeddelanden. Dessa motsvarar de som definieras i Eurocontrolstandard 001-3-92 utgåva 1:

Systemmeddelanden: Dessa meddelanden skall användas för länkövervakning (HEARTBEAT-meddelande) och programkontroll (STARTUP- och SHUTDOWN-meddelanden).

Operativa meddelanden: Dessa meddelanden skall kopplas till ett specifikt operativt sammanhang och är definierade i de Eurocontrolstandarder och -dokument som använder denna standard för utbyte av data. Eurocontrolstandarden för OLDI definierar operativa meddelanden som t.ex. aktiveringsmeddelande (ACT), förhandsmeddelande om gränsinformation (ABI) och logiskt bekräftelsemeddelande (LAM).

Användarmeddelanden: Dessa meddelanden skall innehålla fri text. Deras användning skall vara bilateralt överenskommen. De kan t.ex. användas för att utväxla testinformation eller för att informera motparten om användaråtgärder.

Statusmeddelanden: Användningen av, och innehållet i dessa meddelanden skall vara bilateralt överenskommet. De kan t.ex. användas för att utväxla systemhanteringsinformation.

ANMÄRKNINGAR

1. Användningen av systemmeddelanden är en del av detta protokoll, och deras format specificeras i stycke A.4.10.3 i denna bilaga.

2. Användningen av, och formatet på statusmeddelanden regleras av bilaterala överenskommelser och specificeras inte ytterligare i denna Eurocontrolstandard.

3. Vilka typer av meddelanden som kan sändas beror på protokollets tillstånd. Detta specificeras i följande stycken.

A.4.3. Upprättande av anslutning

A.4.3.1. Protokollet är inledningsvis i tillståndet IDLE.

A.4.3.2. Primitivet för begäran av MT-Associate verkställs för att upprätta en anslutning mellan tillämpningar och för att överföra protokollet till tillståndet DATA_READY. Primitivet måste anropas av både den lokala tillämpningen och fjärrtillämpningen.

A.4.3.3. Det är först nödvändigt att upprätta en underliggande transportförbindelse enligt förfarandet för T-Connect-primitiv, som beskrivs i Bilaga B stycke B.4.1. Efter detta övergår protokollet till tillståndet READY. I detta skede kan endast systemmeddelanden (och möjligtvis, enligt bilateral överenskommelse, användarmeddelanden) överföras. För att överföra ett system- eller användarmeddelande använder sig avsändaren av primitivet T-Data (se B.4.4), med meddelandet som parameter.

A.4.3.4. Ett STARTUP-meddelande (systemmeddelande) skall därefter sändas, timer Tr (se A.4.7) skall startas och protokollet övergår sedan till tillståndet ASSOCIATION_PENDING. Om timer Tr överskrids medan protokollet fortfarande befinner sig i detta tillstånd skall STARTUP-meddelandet sändas igen och timern startas om.ANMÄRKNING

Protokollet kvarstår i tillståndet ASSOCIATION_PENDING, tills ett STARTUP-meddelande mottas. Fortlöpande överskridning av Tr-timern kan signaleras lokalt.

A.4.3.5. Mottagning av STARTUP-meddelandet skall medföra följande åtgärder:

- I tillståndet ASSOCIATION_PENDING sänds ytterligare ett STARTUP-meddelande, protokollet övergår till tillståndet DATA_READY och indikeringsprimitivet för MT-Associate signaleras.

- I alla andra tillstånd ignoreras meddelandet.

A.4.3.6. Mottagande av STARTUP-meddelandet i tillståndet ASSOCIATION_PENDING motsvarar något av följande:

- Fjärrtillämpningen skickade ett primitiv för begäran om MT-Associate, och dess protokoll för meddelandeöverföring har övergått till tillståndet ASSOCIATION_PENDING.

- Fjärrtillämpningens protokoll för meddelandeöverföring svarar på ett tidigare mottaget STARTUP-meddelande och har övergått till tillståndet DATA_READY.

ANMÄRKNING

Denna osäkerhet uppstår därför att samma meddelande används för STARTUP som för svar på STARTUP. På grund av detta kommer det protokoll för meddelandeöverföring som först övergick till tillståndet DATA_READY, att erhålla ytterligare ett STARTUP-meddelande. Som beskrivet i A.4.3.5 skall detta STARTUP-meddelande ignoreras.

A.4.3.7. När STARTUP-meddelanden utväxlats är anslutningen upprättad, och alla angivna meddelandetyper kan överföras (tillståndet DATA_READY).

A.4.4. Dataöverföring

Andra typer av meddelanden överförs på samma sätt som systemmeddelanden, med hjälp av tjänsten T-Data, med meddelandet som parameter. Detta motsvarar tjänsteprimitiven för begäran och indikering för MT-Data. ANMÄRKNING

Varje meddelande sänds som en enstaka TSDU: det förekommer ingen hoplänkning eller segmentering av meddelanden på denna nivå.

A.4.5. Kontrollerad nedkoppling av anslutning

A.4.5.1. Anslutningen för meddelandeöverföring mellan två tillämpningar kan avslutas av båda sidor. Detta motsvarar tjänsteprimitivet för begäran om MT-Abort.

A.4.5.2. Följande åtgärder skall vidtas:

- I tillståndet DATA_READY skall ett SHUTDOWN-meddelande (systemmeddelande) sändas, timer Tr och Ts skall stoppas och transportförbindelsen skall kopplas ner.

- I tillståndet ASSOCIATION_PENDING skall ett SHUTDOWN-meddelande (systemmeddelande) sändas, timer Tr skall stoppas och transportförbindelsen skall kopplas ner.

- I tillståndet READY skall transportförbindelsen kopplas ner.

- I övrigt vidtas inga åtgärder.

ANMÄRKNING

SHUTDOWN-meddelandet är inte en tidig varning - anslutningen kopplas ner omedelbart. Det kommer ingen bekräftelse från den andra sidan.

A.4.5.3. Mottagande av ett SHUTDOWN-meddelande skall medföra följande åtgärder:

- I tillståndet DATA_READY skall timer Ts (se A.4.7) stoppas, indikering för MT-Abort signaleras och gränssnittet övergå till tillståndet ASSOCIATION_PENDING utan att sända ett STARTUP-meddelande.

- För alla andra tillstånd vidtas inga åtgärder.

A.4.6. Återupprättande av anslutning

Tillämpningen som initierade nedkopplingen av anslutningen ansvarar för att, när den är redo, återupprätta anslutningen samt eventuella lägre skikt (om nödvändigt).ANMÄRKNING

Om nedkopplingen av anslutningen resulterat i att den underliggande nätverksförbindelsen avslutats måste förfarandet för upprättande av anslutning, beskriven i stycke A.4.3, följas.

A.4.7. Anslutningsintegritet

A.4.7.1. Integriteten hos anslutningen mellan två tillämpningar sköts genom heartbeat-funktionen.

A.4.7.2. När tillståndet DATA_READY uppnås, och när någon typ av meddelande sänds över transportförbindelsen, skall en ställbar timer, Ts, (om)startas. Om timern Ts överskrids i tillståndet DATA_READY, skall ett HEARTBEAT-meddelande (systemmeddelande) sändas (och timern skall startas om).

A.4.7.3. På liknande sätt skall då tillståndet DATA_READY uppnås, och vid mottagning av alla meddelanden utom STARTUP-meddelanden över förbindelsen, en ställbar timer Tr (om)startas. Om timern Tr överskrids i tillståndet DATA_READY signaleras en indikering om MT-Abort, sändning av alla meddelanden stoppas, timer Ts stoppas och timer Tr startas om. Gränssnittet befinner sig i tillståndet ASSOCIATION_PENDING.ANMÄRKNING

Tillämpningarna återupptar och synkroniserar förbindelsen genom utväxling av STARTUP-meddelanden (se A.4.3).

A.4.8. Okontrollerad nedkoppling av anslutning

A.4.8.1. Det kan uppstå en okontrollerad nedkoppling av en anslutning om

- transportförbindelsen bryts (t.ex. linjefel eller protokollfel),

- det inträffar något fel i en av de två tillämpningarna eller i ett av systemen (detta kan bero på maskin- eller programvarufel, i vissa fall kan den underliggande transportförbindelsen fortfarande fungera),

ANMÄRKNING

Enligt definitionen på transportprokotollet i bilaga B, finns det inte någon sammanhängande transportförbindelse som går från tillämpningssystem till tillämpningssystem. Detta innebär att ett avbrott i transportförbindelsen är ett direkt resultat av avbrottet på nätverksförbindelsen.

A.4.8.2. Ett tillämpnings- eller systemfel kan upptäckas genom att tidsbegränsningen löper ut för mottagandet av ett förväntat HEARTBEAT-meddelande (se A.4.7) från denna tillämpning.

A.4.9. Återhämtning vid avbrott

A.4.9.1. Två fall måste beaktas:

- Efter fel på en transportförbindelse.

- Efter ett tillämpningsfel.

A.4.9.2. I båda fallen innebär ett återupprättande av anslutningen att det normala förfarandet för upprättande av en anslutning (se A.4.3) används, inklusive utväxling av STARTUP-meddelanden.ANMÄRKNING

Vid ett avbrott på tillämpningsnivån som inte medför att den underliggande förbindelsen bryts, kan det felande systemet sända ett SHUTDOWN-meddelande (dvs. L_shutdown, anropat antingen manuellt eller som del av tillämpningens logik) innan försök att återupprätta anslutningen görs. Detta avkortar fjärrtillämpningens tidsbegränsning Tr, och kan resultera i en snabbare återhämtning med mindre risk för dataförluster.

A.4.10. Meddelandeformat

A.4.10.1. Allmän meddelandeuppbyggnad

>Plats för tabell>

A.4.10.2. Längd på meddelandetext

Meddelandetexter på upp till och med 4096 oktetter skall stödjas.

A.4.10.3. Format på systemmeddelanden

>Plats för tabell>

A.4.10.4. Andra meddelandeformat

>Plats för tabell>

ANMÄRKNINGAR

1. Formatet för meddelandetexten i statusmeddelanden ligger utanför omfattningen av denna Eurocontrolstandard.

2. Formatet för operativa meddelanden är beskrivet i Eurocontrolstandarder och dokument som definierar meddelandetillämpningar, som t.ex. OLDI [Referens 13].

3. Användarmeddelanden består av utskrivbar ASCII-text. Om meddelanden av denna typ stöds, måste ett användargränssnitt tillhandahållas för att visa mottagna meddelanden och för att medge sammansättning av meddelanden för sändning.

A.5. Tabeller med tillståndsövergångar i protokollet

A.5.1. Inledning

Tillståndstabellerna nedan är den definitiva specifikationen på protokollet. Vid avvikelse mot huvudtexten ovan gäller nedanstående specifikation.ANMÄRKNING

Beteckningarna som använts för att beskriva tillstånd, händelser, timrar och åtgärder är baserade på ST-ICD. Emellertid har följande definitioner och resulterande åtgärder granskats, de kan därför skilja sig från ST-ICD.

A.5.2. Tillståndsdefinitioner

Tabell 1

Tillståndsdefinitioner

>Plats för tabell>

A.5.3. Möjliga händelser

Tabell 2

Möjliga händelser

>Plats för tabell>

A.5.4. Timrar

Tabell 3

Timrar

>Plats för tabell>

Värdet för dessa tidsbegränsningar skall vara sådana att Tr = 2Ts + överföringstiden.ANMÄRKNING

Typiska värden på dessa timrar är: Ts = 30 s, Tr = 70 s.

A.5.5. Tabell över tillståndsövergångar

Tabell 4

Tillståndsövergångar

>Plats för tabell>

A.5.6. Flödesdiagram över tillståndsövergångar

ANMÄRKNING

Protokollet beskrivs i figur A.1 i form av ett flödesdiagram där tillståndsövergångarna visas. Flödesdiagrammet är endast informativt: om avvikelser förekommer mellan flödesdiagrammet och tillståndstabellerna ovan, gäller tabellerna.

Figur A.1

Protokoll för meddelandeöverföring: Flödesdiagram över tillståndsövergångar

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

BILAGA B (Normativ)

PROTOKOLL FÖR MEDDELANDERUBRIKER

B.1. Inledning

Denna bilaga definierar protokollet för meddelanderubriker, ett minimalt transportprotokoll för användning i tillämpningar som t.ex. OLDI.

B.2. Implementerad tjänst

B.2.1. Protokollet för meddelanderubriker motsvarar en undergrupp av transporttjänsten för anslutningsläge enligt definitionen i ISO/IEC 8072 [Referens 11], och innefattar följande tjänsteprimitiv.

T-Connect: upprätta en transportförbindelse för en tillämpning

T-Data: överför ASCII-data

T-Disconnect: avsluta transportförbindelsen för en tillämpning

B.2.2. Tjänsten stödjer inte multiplexöverföring, felkorrigering eller segmentering och sammansättning.

B.3. Förutsättningar för tjänsten

Protokollet förutsätter tillgång till en pålitlig, grundläggande nätverksfunktion som den som tillhandahålls genom X.25 Packet Layer Protocol.ANMÄRKNING

Endast en enkel transportförbindelse stöds för varje nätverksförbindelse.

B.4. Protokollspecifikation

B.4.1. Upprättande av förbindelse

Primitivet för T-Connect skall implementeras genom användandet av tjänsten N-Connect i den underliggande nätverkstjänsten. Det finns en direkt mappning mellan de två uppsättningarna (begäran, indikering) primitiver. Alternativt kan en befintlig nätverksförbindelse användas (t.ex. en som upprättats av mekanismer för systemhantering).Rekommendationer

1. I det senare fallet ovan, bör nätverksförbindelsen återställas före användning. Primitivet för N-Connect kan upprepas automatiskt om inget svar erhållits inom en bestämd tid.

2. Om denna automatiska upprepning är infört bör försök göras ungefär var 15:e sekund.

B.4.2. Undvikande av överflödiga nätverksanslutningar

Om ett primitiv för begäran om N-Connect är utestående (dvs. ingen motsvarande N-Connect-bekräftelse eller primitiv för N-Disconnect har signalerats) och en N-Connect-indikering signaleras, skall det inkommande försöket till kontakt med nätverket avvisas eller rensas bort, genom svar med ett primitiv för begäran om N-Disconnect, endast då båda följande förhållanden råder:

- Den anropande NSAP-adressen i N-Connect-indikeringen är den samma som den anropade NSAP-adressen i den utestående N-Connect-begäran.

- Den anropande NSAP-adressen i den utestående N-Connect-begäran är större än den anropade NSAP-adressen i den utestående N-Connect-begäran. Jämförelsen görs på bit-strängarna som formats av den använda binära kodningen för varje NSAP-adress, enligt definitionen i ISO/IEC 8348 bilaga A [Referens 10] (en sträng skall anses vara större än någon av dess egna inledande delsträngar, t.ex. '8800'H > '88'H).

B.4.3. Nedkoppling av förbindelse

B.4.3.1. För nedkoppling av förbindelse skall serviceprimitiven för N-Disconnect och N-Reset för den underliggande nätverkstjänsten användas.

B.4.3.2. För att utföra en T-Disconnect-begäran, skall en N-Disconnect-begäran signaleras. Alternativt skall, om upprättande av nätverksförbindelser genom primitivet för N-Connect inte stöds, nätverksförbindelsen inte uttryckligen kopplas ner.Rekommendation

I det senare fallet ovan, bör nätverksförbindelsen återställas.

B.4.3.3. En T-Disconnect-indikering skall signaleras vid mottagande av endera av följande serviceprimitiv för nätverk på en nätverksförbindelse som motsvarar en helt eller delvis upprättad transportförbindelse:

- N-Disconnect-indikering.

- N-Reset-indikering.

B.4.4. Dataöverföring

B.4.4.1. Primitivet för T-Data skall implementeras genom användandet av primitivet för N-Data för den underliggande nätverkstjänsten. Det finns en direkt mappning mellan de två uppsättningarna (begäran, indikering) primitiv. Mappningen använder en TPDU-enhet som överförs med nätverkstjänsten.

B.4.4.2.

>Plats för tabell>

ANMÄRKNINGAR

1. Denna rubrik har definierats så att den skall vara identisk med den som används i det INTERCAUTRA-förfarande som definierats för utväxling av ACT-meddelanden mellan CAUTRA Paris, London Air Traffic Control Centers 9020D-system och Digital Communications Terminal System (DCTS) Maastricht/Karlsruhe, vid transport av de meddelandeformat som definierats i Bilaga A. I detta fall motsvarar fältet "data(1)" TYP-fältet.

2. Användandet av fälten ADEST, DEST, AEMM, EMM och ADR med värden andra än '40'H ligger utanför omfattningen av denna Eurocontrolstandard, men kan vara föremål för bilateral överenskommelse.

B.4.4.3. Tjänsten T-Data skall begränsas till överförandet av utskrivbara ASCII-tecken. Särskilt gäller att inga av dataoktetterna skall ha värdet '03'H (tecknet ETX).

B.4.4.4. En implementering som överensstämmer med standarden skall uppfylla kravet på stöd för dataenheter för nätverkstjänster (NSDU) på upp till och med 4105 oktetter.

B.4.4.5. En implementering som överensstämmer med standarden skall förhindra hoplänkning av flera TSDU till en enskild NSDU.

B.4.4.6. En implementering som överensstämmer med standarden skall förhindra uppdelning av en TSDU i flera NSDU.

BILAGA C (Normativ)

NÄTVERKSPROTOKOLL

C.1. Inledning

Denna bilaga specificerar ett grundläggande nätverksprotokoll som använder X.25 Packet Layer Protocol, för användning i både direktanslutna och paketförmedlande nätverksmiljöer, för att stödja överföringen av flygdata. Protokollets underuppsättning är kompatibel med den som är definieras i [Referens 1] från 1980 års utgåva och framåt.

C.2. Tillhandahållen tjänst

C.2.1. Protokollet implementerar OSI-nätverkstjänsten för förbindelseläge enligt definitionen i ISO/IEC 8348 [Referens 10], med följande undantag:

- NSAP-adresser är begränsade till formen definierad i C.4.2.

- Det finns ingen funktion för att upprätta en överenskommelse mellan användare och leverantör av nätverkstjänsten (NS) beträffande kvaliteten på tjänsterna kopplade till en nätverksanslutning.

- Överföring av NS-användardata under uppkoppling och nedkoppling av en nätverksanslutning stöds inte, med undantag av det som tillhandahålls enligt beskrivningen i C.5.3.

C.2.2. Följande tillägg till nätverkstjänsten erbjuds inte:

- Mottagningsbekräftelse.

- Påskyndad dataöverföring.

C.3. Förutsatt tjänst

Protokollet förutsätter tillgång till en OSI-datalänktjänst, som den som erbjuds genom ISO/IEC 7776 (LAPB) [Referens 6].

C.4. NSAP-adressering

C.4.1. Inledning

C.4.1.1. Uppbyggnaden av NSAP-adresserna överensstämmer med definitionerna i ISO/IEC 8348 bilaga A [Referens 10], som visat nedan.

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

C.4.1.2. Beståndsdelarna i NSAP-adressen är definierade nedan.

IDP: Inledande domändel, bestående av AFI- och IDI-fälten.

AFI: Myndighets- och format-ID.

IDI: Inledande domänidentifiering.

DSP: Domänspecifik del.

C.4.2. Adresstruktur för NSAP

C.4.2.1. I denna Eurocontrolstandard skall adressdelarna begränsas till följande format:

C.4.2.2. AFI-värdet 48 skall användas, indikerande ett lokalt IDI-format med decimalabstrakt syntax.

C.4.2.3. IDI är null, följande det lokala formatet.

C.4.2.4. DSP skall bestå av två par av decimala siffror enligt följande:

- Det första paret är enhetsbeteckningen för en enhet för flygkontrolltjänst (ATC), vilken identifierar ett ATC-system och därigenom även indirekt en plats.

- Det andra paret är en ATC-enhetsväljare, som kan användas för att identifiera en särskild slutpunkt inom en ATC-enhet.

C.4.2.5.

>Plats för tabell>

C.4.3. Tilldelning av ATC-enhetsbeteckningar och -enhetsväljare

C.4.3.1. Ansvaret för tilldelning av unika ATC-enhetsbeteckningar för varje ATC-system kommer att ligga hos Eurocontrol, medan tilldelningen av ATC-enhetsväljare sker av relevant myndighet inom ATC-administrationen eller -organisationen.

C.4.3.2. Tilldelningen av ATC-enhetsbeteckningar vid tidpunkten för upprättandet av denna standard redovisas i Bilaga G.

C.5. Protokollspecifikation

C.5.1. Översikt

Protokollet är baserat på det subnätverksberoende konvergensprotokollet för X.25(1980), definierat i till ISO/IEC 8878 [Referens 12], med följande skillnader:

- Användarfunktionen snabbval (Fast Select) används inte, emellertid används kodningen, som definieras i bilaga A till ISO/IEC 8878 [Referens 12] för användning med det utökade formatet för användardata som finns tillgängligt i snabbvalsfunktionen, här i det grundläggande formatets fält för användardata i CALL REQUEST- och INCOMING CALL-paket eftersom begränsningar i parametrarna till den tillåtna nätverkstjänsten säkerställer att den kodade informationen får plats i 16 oktetter.

- Av parametrarna för nätverkstjänst, för vilka kodning är definierad i ISO/IEC 8878 [Referens 12], sänds endast de anropande och anropade NSAP-adresserna (och bara i formatet definierat i C.4.2.) i CALL REQUEST-paketet.

- Fältet för användardata används inte i CALL ACCEPTED-, CALL CONNECTED-, CLEAR REQUEST- eller CLEAR INDICATION-paketen.

- De alternativa förfarandena för uppkoppling och nedkoppling av nätverksförbindelser används inte.

- Mottagningsbekräftelse med hjälp av D-biten stöds inte.

ANMÄRKNING

De tre första av dessa begränsningarna säkerställer att all information som skall överföras mellan två DTE respekterar begränsningarna för fältet User Data i X.25 (1980) PLP.

C.5.2. Adresskodning

De anropande och anropade NSAP-adresserna skall kodas med den önskade binära kodning som definieras i ISO/IEC 8348 bilaga A [Referens 10].

C.5.3. Kodning av fält för användardata

C.5.3.1. Som ett resultat av kraven ovan, skall fältet för användardata i CALL REQUEST- och INCOMING CALL-paket kodas enligt vad som visas i Tabell 1, nedan. Alla 16 oktetterna skall sändas.

Tabell 1

Kodning av fält för användardata

>Plats för tabell>

C.5.3.2. Andra parametrar beskrivna i ISO/IEC 8878 [Referens 12] skall inte användas.

C.5.4. Behandling av adresser i INCOMING CALL-paket

C.5.4.1. DTE-adresser

Den anropande DTE-adressen i ett INCOMING CALL-paket skall valideras mot en lokal lista över giltiga DTE-fjärradresser för systemet. Om en ogiltig adress upptäcks skall anropet kopplas bort.

ANMÄRKNINGAR

1. Den anropade DTE-adressen, om närvarande, i ett INCOMING CALL-paket, om närvarande, kan också valfritt valideras mot en lista (vanligtvis med ett element) över giltiga DTE-adresser för systemet.

2. I några fall kan DTE-adressen för en enhet avvika i värde och/eller längd när enheten uppträder som det anropande eller anropade systemet. Särskild hänsyn måste därför tas till detta vid specificering eller implementering av valideringsfunktionen för DTS-adresser.

C.5.4.2. NSAP-adresser

Den anropande NSAP-adressen, kodad enligt beskrivningen ovan, i ett INCOMING CALL-paket skall valideras mot en lokal lista över godkända NSAP-fjärradresser för systemet. Om en ogiltig adress upptäcks, skall anropet kopplas bort.

ANMÄRKNING

Den anropade NSAP-adressen kan även valideras mot en lista över (vanligtvis med ett element) giltiga lokala NSAP-adresser för systemet.

C.5.5. Dataöverföring

C.5.5.1. Som beskrivet i ISO/IEC 8878 bilaga A.5.3 [Referens 12], överförs NSDU i fältet för användardata i ett DATA-paket.

ANMÄRKNING

Som en följd av detta är det förbjudet att sända mer än ett användarmeddelande, som t.ex. ett OLDI-meddelande, per X.25-paket eller M-bitssekvens.

C.5.5.2. NSDU som är längre än det maximalt tillåtna användardatat för den virtuella kretsen skall delas upp i segment och sändas i fälten för användardata som en följd av DATA-paket, där alla utom det sista skall både ha maximal längd och M-biten satt (dvs. en More-bit-sekvens).

C.5.5.3. Vid mottagning skall fälten för användardata i en More-bit-sekvens sättas ihop så att de bildar den mottagna NSDU.

BILAGA D (Normativ)

PROFILSPECIFIKA PICS-DOKUMENT

D.1. Inledning

D.1.1. Leverantören av en protokollimplementering som påstås uppfylla specifikationerna i bilagorna A-C skall fylla i följande PICS-dokument.ANMÄRKNING

Befrielse från upphovsmannarätten för PICS-dokument: användare av denna Eurocontrolstandard får fritt återge PICS-dokument i denna bilaga så att de kan användas i avsett syfte, och får även publicera ifyllda PICS.

D.1.2. Ett ifyllt PICS-dokument är PICS för berörd implementering. Ett PICS är ett utlåtande över vilka av protokollets funktioner och valmöjligheter som implementerats.

D.1.3. Det kan finnas ett antal användningsområden för ett PICS, bl.a. följande:

- Som en kontrollista, av den person som ansvarar för implementeringen av ett protokoll, för att minska risken att protokollet inte uppfyller standarden på grund av överseende.

- För leverantören och köparen, eller potentiella köparen, av implementeringen. Som en detaljerad anvisning om implementeringens kapacitet, fastställd i förhållande till den gemensamma grund som tillhandahålls av PICS-dokumenten.

- För användaren, eller den potentiella användaren, av implementeringen som grund för att inledningsvis undersöka möjligheten till samverkan med en annan implementering (notera att även om samverkan aldrig kan garanteras, kan misslyckad samverkan ofta förutses genom oförenliga PICS).

- Av en protokolltestare, som grund för att välja rätt tester för utvärdering av om implementeringen överensstämmer med standarden.

D.2. Instruktioner för ifyllnad av PICS-dokument

D.2.1. Allmän uppbyggnad av PICS-dokument

D.2.1.1. Implementeringsidentifieringen och protokollsammanfattningen är den första delen av varje PICS-dokument, och skall fyllas i enligt anvisning med den information som är nödvändig för fullständig identifiering av både leverantör och implementering.

D.2.1.2. Huvuddelen av ett PICS-dokument består av ett frågeformulär i fast format. Svar på frågorna i frågeformuläret skall anges i kolumnen längs till höger, antingen genom att ett svar helt enkelt markeras för att påvisa ett begränsat val (vanligtvis Ja eller Nej), eller genom angivandet av ett värde eller ett intervall av värden.ANMÄRKNINGAR

1. Varje element identifieras med en unik elementreferens i den första kolumnen, den andra kolumnen innehåller frågan som skall besvaras, den tredje kolumnen innehåller hänvisningar till det material som specificerar elementet i denna Eurocontrolstandard. De övriga kolumnerna visar statusen för elementet (om stöd är obligatoriskt, valfritt, förbjudet eller villkorat) och lämnar utrymme för svaren: se även D.2.4, nedan.

2. En leverantör kan också tillhandahålla, eller åläggas att tillhandahålla, ytterligare information kategoriserad som antingen tilläggsinformation eller undantagsinformation. Om sådan finns, skall varje typ av ytterligare information lämnas i en underparagraf med element benämnda A< i > eller X< i >, för korsreferens, där < i > är en entydig identifiering av elementet (t.ex. ett siffra helt enkelt): det finns inga andra restriktioner på dess format eller presentation.

D.2.1.3. Ett ifyllt PICS-dokument, inklusive all tilläggsinformation och undantagsinformation, skall hänvisas till som utlåtandet om ett infört protokolls överensstämmelse med standarden för berörd implementering. ANMÄRKNING

När en implementering kan konfigureras på mer än ett sätt, kan det vara möjligt att beskriva alla sådana konfigurationer i en enda PICS. Leverantören har emellertid möjlighet att tillhandahålla mer än ett PICS, där var och en täcker någon undergrupp av implementeringens konfigureringsmöjligheter, om detta medför enklare och tydligare presentation av informationen.

D.2.2. Tilläggsinformation

Element med tilläggsinformation låter en leverantör lämna ytterligare information ämnad att underlätta tolkningen av ett PICS.ANMÄRKNINGAR

1. Det är inte menat eller förväntat att stora mängder skall tillhandahållas, och ett PICS kan betraktas som komplett utan någon sådan information. Ett exempel kan vara ett utkast över på vilka sätt en (enstaka) implementering kan installeras för att fungera i en mängd olika miljöer och konfigurationer, eller en kortfattad förklaring (kanske baserad på speciella tillämpningsbehov) till utelämnandet av funktioner som, även om de är valfria trots allt normalt förekommer i implementeringen av detta protokoll.

2. Hänvisningar till element med tilläggsinformation kan anges bredvid vilket svar som helst i frågeformuläret, och kan innefattas i element för undantagsinformation.

D.2.3. Undantagsinformation

D.2.3.1. Det kan hända att en leverantör önskar besvara en fråga med statusen obligatorisk eller förbjuden (efter det att något villkor tillämpats), på ett sätt som står i strid med de anvisade kraven. Inget förtryckt svar finns för detta i "stöd"-kolumnen: istället skall leverantören skriva in det saknade svaret i "stöd"-kolumnen, tillsammans med en X< i >-hänvisning till ett element med undantagsinformation.

D.2.3.2. Leverantören skall redovisa det ändamålsenliga skälet som del av undantagsinformationen.

D.2.3.3. En implementering för vilken ett undantagselement krävs på detta sätt, är inte i överensstämmelse med denna specifikation.ANMÄRKNING

En tänkbar anledning till situationen som beskrivits ovan, är att en brist i standarden har rapporterats, där en korrigering förväntas ändra de krav som inte uppfylldes av implementeringen.

D.2.4. Villkorliga element

D.2.4.1. Individuella villkorade element indikeras med en villkorssymbol i formatet "< element >: < s >" i statuskolumnen, där "< element >" är en elementhänvisning som visas i tabellens första kolumn för något annat element, och "< s >" är en statusbeteckning, M, O, O.< n > eller X.ANMÄRKNING

En PICS-dokument kan innehålla ett antal villkorade element. Dessa är element för vilka både tillämpning av elementet själv, och dess status om den är tillämplig (obligatorisk, valfri eller förbjuden), beror på om vissa andra element stöds eller inte.

D.2.4.2. Om elementet som det hänvisats till genom villkorstecknet är markerat som att det stöds, gäller det villkorade elementet och dess status anges med "< s >". "Stöd"-kolumnen skall vara ifylld på vanligt sätt. Annars är inte det villkorade elementet relevant, och svaret (NA) skall markeras.

D.2.4.3. Varje element vars hänvisning används i en villkorssymbol indikeras med en asterisk i kolumnen med element.

D.3. PICS-dokument för protokollet för meddelandeöverföring

D.3.1. Förkortningar och speciella beteckningar

D.3.1.1. Statusbeteckningar

M: Obligatorisk

O: Valfri

D.3.1.2. Elementhänvisningar

Element i PICS-dokumenten identifieras genom mnemotekniska elementhänvisningar. PICS-element som berör relaterade funktioner identifieras genom elementhänvisningar som delar samma begynnelsebokstav eller -bokstavspar (med versaler). Nedan följer en lista över dessa initialer, i samma ordning som grupperna med element förekommer i PICS-dokumenten.

>Plats för tabell>

D.3.2. Identifiering

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

D.3.3. Protokollimplementering

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

D.4. PICS-dokument för protokollet för meddelanderubriker

D.4.1. Förkortningar och speciella beteckningar

D.4.1.1. Statusbeteckningar

M obligatorisk

O valfri

O.< n > valfri, men stöd av åtminstone en grupp av alternativ, benämnd med samma nummer < n > krävs

X förbjuden

< element >: beteckning för villkor, beroende på det stöd som markerats för < element > (se D.2.4)

D.4.1.2. Förkortningar

NA ej tillämpligt

D.4.1.3. Elementhänvisningar

>Plats för tabell>

D.4.2. Identifiering

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

D.4.3. Protokollimplementering

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

D.5. PICS-dokument för nätverksprotokollet

D.5.1. Förkortningar och speciella beteckningar

D.5.1.1. Statusbeteckningar

M obligatorisk

O valfri

D.5.1.2. Elementhänvisningar

>Plats för tabell>

D.5.2. Identifiering

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

D.5.3. Protokollimplementering

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

BILAGA E (Normativ)

PROFILKRAVSLISTA

E.1. Inledning

E.1.1. Denna bilaga tillhandahåller PRL för FDE ICD-profilen som definieras i denna Eurocontrolstandard. Utlåtandet om överensstämmelse med denna standard för en implementering som gör anspråk på att uppfylla kraven i denna profil skall genereras enligt nedanstående instruktioner.ANMÄRKNING

Proforma i denna bilaga är baserade på dem som medföljer hänvisade grundstandarder.

E.1.2. En implementering som överensstämmer med denna standard skall uppfylla de obligatoriska kraven på överensstämmelse för de grundstandarder som det hänvisats till i denna profil.

E.2. Syftet med PRL- och PICS-dokumenten

Statusen på detta avsnitt (E.2) är informativ: det utgör inte en av bestämmelserna i denna del av denna Eurocontrolstandard.

- Syftet med att presentera kraven för överensstämmelse med standarden i tabellform för PRL- och PICS-dokument är att tillhandahålla en kontrollista med de funktioner som måste eller kan vara implementerade. De underliggande begreppen är definierade och beskrivna i ISO/IEC 9646-1 [Referens 14] (ITU-T Rekommendation X.290 är likvärdig) och ISO/IEC TR 10000-1 [Referens 2]

- En profil kombinerar och väljer möjligheterna i flera grundstandarder för att uppfylla en specifik funktion för informationsbehandling. För varje grundstandard finns det ett PICS-dokument som listar standardens krav. En PRL omfattar den undergrupp av grundstandardens element för PICS-dokument som är begränsade av profilen, tillsammans med de specifika profilkraven. Den definierar de svar som krävs på grundstandardens PICS-dokument för överensstämmelse med profilen. Dessutom innehåller en PRL element av PICS-typ, som är specifika för profilen (som minst finns det ett element som testar om alla erforderliga PICS-dokument fyllts i korrekt). Dessa element måste fyllas i tillsammans med grundstandardens PICS-dokument. Dessa ifyllda proforma utgör tillsammans utlåtandet om profilimplementeringens överensstämmelse med standarden.

- Som följd av metodiken i ISO/IEC TR 10000-1 [Referens 2], måste ett påstående om överensstämmelse med en profil stödjas med PICS-dokument som ifyllts i överensstämmelse med PRL. Användandet av detta material beror på förfarandet för anskaffning av en FDE ICD-implementering.

- Ett flertal olika förfaranden för en FDE-implementering är möjliga:

- Egen implementering av en nationell myndighet eller organisation: PRL bör användas som grund för krav- och acceptanstestspecifikationen för implementeringen, den ifyllda ICS bör tas fram som del av acceptansförfarandet.

- Implementering av profilen av en entreprenör: materialet kommer att användas och produceras som för en intern implementering, men entreprenören bör tillhandahålla ICS, och behovet av detta måste vara ett kontraktskrav.

- Implementering utförd av en entreprenör som del av ett nyckelfärdigt system eller helhetskontrakt för system: materialet kommer att användas och produceras som för en egen implementering, men entreprenören måste avkrävas att göra detta internt samt att även tillhandahålla en ifylld ICS. Överensstämmelse med profilen säkerställer exempelvis att en leverantör som arbetar för två olika uppdragsgivare inte kan införa egna protokoll för att uppfylla FDE-kraven, och bidrar på så sätt till att ge uppdragsgivarna kontroll.

- Integrering av standardprodukter till en profilimplementering i något av de föregående fallen: leverantören av en produkt måste avkrävas att tillhandahålla de PICS-dokument som är relevanta för produkten, kompletterade enligt den PRL som beskrivits här, och garantier för att produkten uppfyller de berörda profilkraven. Detta PICS kan därefter vidarebefordras som en del av profilens ICS.

- Efter implementeringen bör ICS behållas som en del av dokumentationen för implementeringen. Den kan användas för att förutse möjligheter till samverkan med andra myndigheter och organisationer, och för att identifiera förändringar som kan krävas vid övergång till andra protokoll.

E.3. Beteckningar

E.3.1. Följande beteckningar från ISO/IEC TR 10000-1 [Referens 2] används i ett PRL för att ange statusen på funktionerna:

m: obligatorisk

o: valfri

-: ej tillämpligt (dvs. logiskt omöjligt inom profilens omfattning)

x: utesluten

ANMÄRKNINGAR

1. Kombinationer av två tecken kan användas, där det första tecknet hänvisar till den statiska (implementering) statusen, och den andra till den dynamiska (användning), således innebär "mo" obligatorisk implementering, valfri användning.

2. Beteckningen "o. >n< " används för att visa en uppsättning av valfria möjligheter (dvs. minst en i uppsättningen måste vara implementerad) med samma identifiering n.

3. En funktion markerad "x" kan trots detta vara del av en implementering så länge den inte utnyttjas när implementeringen används i överensstämmelse med profilen.

4. Användande av funktionen "x" kräver bilateral överenskommelse. I detta fall bör statusen på funktionerna ses över, då de kan vara av intresse för andra implementeringar.

E.3.2. Följande beteckningar används för predikat:

>predicate< :: för en grupp med element där alla är villkorade för >predicate< (gruppens omfattning visas genom arrangemanget).

>predicate< : för ett ensamt element som är villkorat för >predicate< .

ANMÄRKNING

I varje individuellt fall, kan predikatet vara benämningen på en profilfunktion eller en boolesk kombination av predikat ("¬" är symbolen för logisk negation).

E.3.3. Kraven i grundstandarden visas med motsvarande beteckningar med versaler (dvs. M, O, O. >n< , X).

E.4. Instruktioner för att fylla i PICS-dokument

E.4.1. För att tillhandahålla ICS-profilen, skall PICS-dokument för de grundstandarder till vilket det hänvisas vara kompletterade tillsammans med ytterligare profilrelaterade PICS-element som tillhandahålls i denna bilaga.

E.4.2. Där denna profil förfinar funktionerna i grundstandarden skall kraven som framförs i denna PRL tillämpas (som indikeras i PRL-element med en kolumn för "Profilfunktioner") för att begränsa antalet tillåtna svar i PICS-dokument för grundstandarden.

E.4.3. Där denna profil ställer ytterligare krav skall svarskolumnen för sådana element fyllas i. I denna kolumn skall varje svar antingen väljas från den anvisade uppsättning svar, eller bestå av ett eller flera parametervärden eller ett intervall av värden, enligt de uppställda kraven.

E.4.4. Om ett obligatoriskt krav inte uppfylls måste undantagsinformation tillhandahållas genom angivandet av en hänvisning X >i< , där >i< är en unik beteckning på en bifogad förklaring till att överensstämmelse inte uppnåtts.ANMÄRKNING

En möjlig orsak till ett sådant undantag är att implementeringen integrerar fakta från en aktuell felrapport rörande ett villkor i profilen, om felrapporten accepteras kommer implementeringen att uppfylla standarden.

E.5. Hänvisningar

E.5.1. För denna profil görs hänvisningar till följande protokollspecifikationer:

- Protokoll för meddelandeöverföring (bilaga A till denna Eurocontrolstandard).

- Protokoll för meddelanderubriker (bilaga B till denna Eurocontrolstandard).

- Nätverksprotokoll för förbindelseläge som använder ISO/IEC 8208 ( till denna Eurocontrolstandard).

- ISO/IEC 7776 [Referens 6].

- Standarder för fysiska skikt, upprättade avi ITU-T Rekommendation X.25 (1993), klausul 1 [Referens 1].

E.5.2. Då det inte finns några uttryckliga PICS-dokument för de relevanta standarderna för fysiska skikt, skall tillfälliga PICS-dokument för fysiska skikt enligt ISO/IEC ISP 10609-9 klausul A.4 [Referens 8] användas.

E.6. Utlåtande om överensstämmelse med standarden

E.6.1. Översikt

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

E.6.2. Dynamiska krav på överensstämmelse med standarden

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

E.7. Krav på övre skikt

Tabell 3

Protokoll för meddelandeöverföring

>Plats för tabell>

E.8. Krav på lägre skikt

E.8.1. Krav på transportskikt

Tabell 4

Protokoll för meddelanderubriker

>Plats för tabell>

E.8.2. Krav på nätverksskikt

De PRL som redovisas i detta avsnitt utgår ifrån PICS-dokument för ISO/IEC 8208:1993 [Referens 7]. Uppgifterna i kolumnen "Hänvisningar" under "Funktioner i grundstandard" i följande tabeller är hänvisningar till klausuler i den standarden.

E.8.2.1. Allmän DTE-karaktäristik

Tabell 5

Allmän DTE-karaktäristik

>Plats för tabell>

E.8.2.2. Förfaranden, pakettyper och paketformat

Tabell 6

Paketskiktsfunktioner oberoende av logiska kanaler

>Plats för tabell>

Tabell 7

Upprätta kommunikation

>Plats för tabell>

Tabell 8

Avsluta kommunikation

>Plats för tabell>

Tabell 9

Återställning av logiska kanaler

>Plats för tabell>

Tabell 10

Förfaranden vid fel

>Plats för tabell>

Tabell 11

Avbrottsöverföring

>Plats för tabell>

Tabell 12

Sändning av data

>Plats för tabell>

Tabell 13

Datamottagning

>Plats för tabell>

Tabell 14

Leveransbekräftelse

>Plats för tabell>

E.8.2.3. Blandade funktioner och valmöjligheter

Tabell 15

Värden på orsaker och diagnostiska koder

>Plats för tabell>

E.8.2.4. Funktioner

Tabell 16

Funktioner som skickas i CALL REQUEST-paket

>Plats för tabell>

Tabell 17

Funktioner som skickas i CALL ACCEPT-paket

>Plats för tabell>

Tabell 18

Funktioner skickade i CLEAR REQUEST-paket

>Plats för tabell>

Tabell 19

Funktioner mottagna i INCOMING CALL-paket

>Plats för tabell>

Tabell 20

Funktioner mottagna i CALL CONNECTED-paket

>Plats för tabell>

Tabell 21

Funktioner mottagna i CLEAR INDICATION-paket

>Plats för tabell>

Tabell 22

Funktioner mottagna i CLEAR CONFIRMATION-paket

>Plats för tabell>

E.8.2.5. Värden och omfång för parametrar

Tabell 23

Värden och omfång för parametrar

>Plats för tabell>

E.8.3. Krav på datalänkskikt

De PRL som redovisas i detta avsnitt grundar sig på PICS-dokument för ISO/IEC 7776:1994 [Referens 6]. Uppgifterna i kolumnen "Hänvisningar" under "Funktioner i grundstandard" i följande tabeller är hänvisningar till klausuler i den standarden.

Tabell 24

Datalänkprotokoll

>Plats för tabell>

E.8.4. Krav på fysiska skikt

Se ISO/IEC TR 10609-9 klausul A.4 [Referens 8].

BILAGA F (Informativ)

METODIK FÖR TEST AV ÖVERENSSTÄMMELSE MED STANDARDEN

F.1. Inledning

F.1.1. Det är viktigt att implementeringar av detta ICD är sådana att det finns en hög förtroendenivå för samverkan mellan centraler för flygkontrolltjänst (ATCC) som arbetar gemensamt över gränssnittet.

F.1.2. Implementering av gränssnittet genomförs av medlemsstater på ett sätt som troligen leder till anskaffning av utrustning från olika källor. För att uppnå en hög förtroendenivå för att sådana implementeringar skall fungera tillsammans, krävs en gemensam uppsättning krav på test av om standarden uppfylls för att standardisera förberedelser för tester, tester samt presentation av resultat.

F.2. Syfte och omfattning

F.2.1. I denna bilaga definieras kraven på tester som andvänds för att kontrollera om en implementering uppfyller denna Eurocontrolstandard, av vilken denna bilaga är en del.

F.2.2. Den identifierar mekanismer varigenom förtroende för ett redovisat gränssnittet fastställs genom ett testförfarande som validerar överensstämmelse med standarden.

F.3. Litteraturförteckning

Följande dokument är relevant för implementeringstesterna av denna Eurocontrolstandard:

Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD del 1, Testplan för integration, Version 1.0, daterad 10 maj 1996.

F.4. Utvecklingsmetoder och tillämpningar

F.4.1. Implementeringar av ett ICD kan påverkas genom att man använder vissa valmöjligheter i, och versioner av ett ICD. För att fastställa möjligheten till samverkan, måste en medlemsstat som implementerar gränssnittet, genom ett definierat utlåtande, identifiera vilka delar av ett ICD som stöds beträffande funktion, och vilka eventuella begränsningar av variabla parametrar som stöds.

F.4.2. För alla implementeringar skall test av överensstämmelse med denna standard utföras enligt nedanstående beskrivning.

F.5. Tester

F.5.1. Inledning

F.5.1.1. För att kunna tillföra förtroende och stöd för FDE-gränssnitt inom en ATCC till samverkan mellan samarbetande FDE-tillämpningar, är det önskvärt att var och en testas för överensstämmelse med de standarder av vilka denna bilaga utgör en del. Sådan test sker för den externa funktionen i systemet under test (SUT), och är ämnat att testa samverkan snarare än slutsystemets användbarhet.

F.5.1.2. Resultatet av sådana tester kan användas som underlag för att stödja anspråk på överensstämmelse med standarden gjorda enligt avsnitt i den här delen av denna Eurocontrolstandard. De PICS-dokument och PRL som anges i den här profilspecifikationen kan användas som grund för test av överensstämmelse med standarden. I tillägg kan internationella standarder (t.ex. ISO/IEC 8208 ) redan ha abstrakta testuppsättningar definierade som kan användas för sådana test.

F.5.1.3. Syftet med detta dokument är att tillhandahålla ett standardiserat testprogram som förlitar sig på en standardiserad testuppsättning, vars användning bör leda till möjligheten att jämföra testresultat, utbrett antagande av sådana testresultat och en minimering av behovet för test av överensstämmelsen med standarden. Den standardiserade testsviten har delvis utvecklats av Eurocontrol.

F.5.1.4. Baserat på figur 2, består testen av det kompletta slutsystemet av tester av de tre lägre skikten. Det är tillrådlig att inkludera tester av FDE-tillämpningarna status-, system- and användarmeddelanden.

F.5.1.5. Varje test som beskrivs nedan bör ske i följdordning. De senare testerna kan bara lyckas om de lägre skikten fungerar korrekt, och det är troligt att detta fastställs genom de tidigare testerna.

F.5.1.6. Ovanstående till trots, är testningen beskriven i detta avsnitt frivillig.

F.5.2. Test av de lägre skikten (Skikt 1-3)

Som stöd för kravet på samverkan mellan alla ATCC, rekommenderas det att all testning skall baseras på användningen av testplanen i Eurocontrols (Maastricht UAC Systems Division) FDE ICD Testplan för integrering. Testförfaranden skall vara bilateralt överenskomna mellan samarbetande ATCC.

F.5.3. Test av tillämpningsskiktet

En serie av bilateralt överenskomna tester bör utföras mellan samarbetande ATCC.

F.5.4. Certifiering

Resultaten av testerna bör registreras och accepteras av de samarbetande parterna.

F.5.5. Anvisning

Medlemsstaterna bör vidarebefordra resultatinformationen från alla tester till Eurocontrol.

BILAGA G (Informativ)

TILLDELNING AV IDENTITETER PÅ ATC-ENHETER

I nedanstående tabell redovisas de beteckningar som tilldelats ATC-enheter fram till 22 april 1997. Eurocontrol kan tillhandahålla information om den aktuella tilldelningen av identiteter. I tabellen redovisas även, med hexadecimala siffror, den binära kodningen av beteckningarna som del av den kodning av NSAP-adresser som definieras i Bilaga C.

Tabell 1

Beteckningar för ATC-enheter

>Plats för tabell>

BILAGA H (Informativ)

RIKTLINJER FÖR TILLFÖRLITLIGHET, TILLGÄNGLIGHET OCH SÄKERHET

H.1. Inledning

Det förväntas att ATC-tillämpningar, såsom OLDI, skall utnyttja sammankopplade X.25-nätverk och/eller offentliga eller privata telekommunikationstjänster. Som ett resultat av detta har det bedömts nödvändigt att tillhandahålla riktlinjer för FDE ICD, del 1 implementeringar.

H.2. Syfte och omfattning

H.2.1. Syftet med denna bilaga är att ge riktlinjer för frågor rörande tillförlitlighet, tillgänglighet och säkerhet.

H.2.2. Omfattningen av denna bilaga baseras på två scenarion. Det första scenariot är en direktansluten förbindelse över hyrd linje. Det andra scenariot baseras på ett sammankopplad nätverk i en X.25-nätverksmiljö.ANMÄRKNING

För det andra scenariot har frågor som berör sammankopplingen av X.25-nätverket inte vägts in.

H.2.3. Det är säkerställt att implementeringarna är fysiskt skyddade mot intrång, strömavbrott och andra externa hot som kan påverka normal drift.

H.3. Litteraturförteckning

Dokumentet nedan är en detaljerad teknisk analys av vilken denna bilaga är en översikt:

Eurocontrol FDE ICD del 1: Tillförlitlighet, tillgänglighet och säkerhet - Teknisk rapport [Referens 16].

H.4. Implementering av hyrda linjer

H.4.1. Tillförlitlighet

För att förbättra driftens tillförlitlighet, måste kablarna för hyrda linjer, PSTN och ISDN (digitalt flertjänstnät) vara dragna på ett sådant sätt att de är fysiskt skilda från varandra. De måste också anslutas till olika växlar hos telekommunikationsbolagen (detta måste specificeras till telekommunikationsbolaget).

H.4.2. Tillgänglighet

H.4.2.1. P.g.a. långa uppkopplingstider för PSTN, som är oförenliga med tidsbegränsade tillämpningar, bör ISDN användas som reservmedium.

H.4.2.2. Vid händelse av DTE-byte skall den DTE som befinner sig i standby generera en DISC-ram för att snabba upp återupprättandet av anslutningen.

H.4.3. Säkerhet

H.4.3.1. När ISDN används som ett reservmedium, bör den anropade ISDN-terminaladaptern (TA) validera anroparens E.164-adress [Referens 18].

H.4.3.2. Anropande DTE bör uppfylla ITU-T:s rekommendation X.32 [Referens 17] genom att inkludera sin identitet och autenticitetsinformation.

H.4.4. Exempel på utformning

Figur H.1

Exempel på utformning med hyrd linje

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

H.5. Nätverksimplementering

H.5.1. Tillförlitlighet

För att öka tillförlitligheten skall värdar på en given plats uppkopplas till två DCE som tillhör olika nätverksväxlar (detta krav skall vara specificerat till nätverksoperatören).

H.5.2. Tillgänglighet

H.5.2.1. Kommunikationsanläggningen (hunt group) skall användas för att kunna tilldela en enda X.121-adress [Referens 20] till de DCE som är belägna på en given plats. På så sätt optimeras transporterna på nätverket och antalet misslyckade anrop begränsas.

H.5.2.2. Om andra kommunikationsmekanismer finns implementerade, som resulterar i ett annat värde på anropad DTE-adress i CALL REQUEST- och CALL ACCEPT-paketet, så skall anropande DTE konfigureras så att det inte har någon inverkan på uppkopplingen av anropet.

H.5.2.3. Om ett nätverksfel orsakar en DCE-frånkoppling, och en andra anslutningsmöjlighet finns till nätverket, skall återupprättande av kommunikationen ske via den andra adressen.

H.5.3. Säkerhet

Inom ramarna för denna bilaga, är tjänsten för sluten användargrupp (CUG) den enda tillämpliga nätverksfunktion som skall användas.

H.6. Allmänna riktlinjer för hyrd linje och nätverksimplementeringar

H.6.1. Tillförlitlighet

H.6.1.1. Då en komplett omkoppling mellan värdsystemen kan ta tid, är det fördelaktigt att överväga användandet av en front-end processor (FEP) för att vara behjälplig vid avbrott i värdsystemet.

H.6.1.2. En struktur baserad på en FEP kan öka tjänsternas tillförlitlighet.ANMÄRKNING

Inkluderandet av en transportstack i profilspecifikationen kan komma att ske i samband med en framtida FDE ICD, del 2 -standard.

H.6.2. Tillgänglighet

När ett anrop misslyckas skall den anropande platsen göra ett andra anrop med användning av den andra X.121-adressen (om sådan finns).

H.6.3. Systemhantering

H.6.3.1. Användningen av växlar, som automatiskt slår om genom avsökning av gränssnittssignalerna, bör användas där så är möjligt.

H.6.3.2. En lokal felindikering under dataöverföring kan användas för att utlösa en omkoppling mellan värdsystemen.

H.6.3.3. Omkopplingen av en FEP bör generera en TC-disconnect för att säkerställa att det lokala värdsystemet befinner sig i tillståndet IDLE.

H.6.3.4. När tidsbegränsningarna för X.25-nätverket eller datalänkskikten löper ut, bör det högre skiktet kopplas ner.

H.6.3.5. Ett totalt FEP-haveri bör generera en TC-disconnect.

H.6.3.6. Övervakningssystemet bör undersöka protokollskiktet för meddelandeöverföring (bilaga A) och kontrollera tillståndsmaskinen för att skilja mellan ett fel i protokollet för meddelandeöverföring och ett tillämpningsfel.

H.6.4. Exempel på utformning

Figur H.2

Exempel på utformning av nätverk

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