CELEX: 32000R2082
Language: da
Date: 2000-09-06 00:00:00
Title: Kommissionens forordning (EF) nr. 2082/2000 af 6. september 2000 om vedtagelse af Eurocontrol-standarder og om ændring af direktiv 97/15/EF om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØF

Avis juridique important

|

32000R2082

Kommissionens forordning (EF) nr. 2082/2000 af 6. september 2000 om vedtagelse af Eurocontrol-standarder og om ændring af direktiv 97/15/EF om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØF  

EF-Tidende nr. L 254 af 09/10/2000 s. 0001 - 0234

Kommissionens forordning (EF) nr. 2082/2000af 6. september 2000om vedtagelse af Eurocontrol-standarder og om ændring af direktiv 97/15/EF om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØFKOMMISSIONEN FOR DE EUROPÆISKE FÆLLESSKABER HAR -under henvisning til traktaten om oprettelse af Det Europæiske Fællesskab,under henvisning til Rådets direktiv 93/65/EØF af 19. juli 1993 om definition og anvendelse af kompatible tekniske specifikationer for erhvervelse af udstyr og systemer til regulering af lufttrafikken (air-traffic-management equipment and systems)(1), særlig artikel 3,under henvisning til Kommissionens direktiv 97/15/EF af 25. marts 1997, om vedtagelse af Eurocontrol-standarder og om ændring af Rådets direktiv 93/65/EØF(2), ogud fra følgende betragtninger:(1) Ved direktiv 97/15/EF blev der vedtaget en Eurocontrol-standard for online dataudveksling (On-Line Data Interchange (OLDI), udgave 1.0) og en Eurocontrol-standard for præsentation af udvekslede ATS-data (Air Traffic Services Data Exchange Presentation (ADEXP), udgave 1.0).(2) Eurocontrol har vedtaget nyere versioner af de to nævnte standarder, nemlig OLDI udgave 2.2 og ADEXP udgave 2.0, samt en ny Eurocontrol-standard med titlen "Dokument vedrørende kontrol med udveksling af flyvedata" (Flight Data Exchange - Interface Control Document (FDE-ICD)).(3) Disse Eurocontrol-standarder er omfattet af direktiv 93/65/EØF og bidrager til harmoniseringen af medlemsstaternes nationale systemer for lufttrafikstyring, særlig hvad angår overførsel af flyvninger mellem flyveledelsescentre (OLDI), styring af lufttrafikstrømmen (ADEXP) og kommunikation mellem nationale systemer (FDE-ICD).(4) Udgave 2.2 af OLDI og 2.0 af ADEXP erstatter de nugældende ældre versioner, der er anført i direktiv 97/15/EF, artikel 1, hvorfor denne artikel skal ophæves.(5) De i denne forordning fastsatte bestemmelser er i overensstemmelse med udtalelse fra det udvalg, der er nedsat i henhold til direktiv 93/65/EØF -UDSTEDT FØLGENDE FORORDNING:Artikel 1Da de obligatoriske dele af de Eurocontrol-specifikationer, der er indeholdt i følgende dokumenter om Eurocontrol-standarder, er nødvendige for gennemførelsen af et integreret europæisk system for lufttrafikstyring, vedtages de hermed inden for rammerne af direktiv 93/65/EØF:- Eurocontrol-standard for online dataudveksling (OLDI), udgave 2.2 (Eurocontrols dokumentreference: DPS.ET1.ST06-STD), hvis ordlyd er anført i bilag I til denne forordning- Eurocontrol-standard for præsentation af udvekslede ATS-data (ADEXP), udgave 2.0 (Eurocontrols dokumentreference: DPS.ET1.ST09-STD), hvis ordlyd er anført i bilag II til denne forordning- Eurocontrol-standarden "Dokument vedrørende kontrol med udveksling af flyvedata" (FDE-ICD), udgave 1.0 (Eurocontrols dokumentreference: COM.ET1.ST12-STD), hvis ordlyd er anført i bilag III til denne forordning.Artikel 2Artikel 1 i direktiv 97/15/EF ophæves.Artikel 3Denne forordning træder i kraft på tredjedagen efter offentliggørelsen i De Europæiske Fællesskabers Tidende.Denne forordning er bindende i alle enkeltheder og gælder umiddelbart i hver medlemsstat.Udfærdiget i Bruxelles, den 6. september 2000.På Kommissionens vegneLoyola De PalacioNæstformand(1) EFT L 187 af 29.7.1993, s. 52.(2) EFT L 95 af 10.4.1997, s. 16.BILAG ION-LINE DATAUDVEKSLING (OLDI) UDGAVE 2.2(Eurocontrols dokumentreference: DPS.ET1.ST06-STD)INDHOLDSFORTEGNELSE>TABELPOSITION>ANGIVELSE AF OPHAVSRETDette dokument er frembragt af Eurocontrol Agenturet.Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt samtykke ved Eurocontrol Agenturet.FORORD1. Ansvarlig InstitutionEurocontrol-standarden for On-Line Dataudveksling (OLDI), Udgave 2.2, er blevet forberedt af Directorate of European ATC Harmonisation and Integration Programme (Direktoratet for Program for Harmonisering og Integration af Lufttrafikkontrol i Europa) (EATCHIP), Development (Udvikling) (DED), Eurocontrol, som også er ansvarlig for opdateringen af dokumentet. Alle kommentarer eller forespørgsler bør henvendes til Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for Division DED-2's opmærksomhed.2. Forhold til EATCHIP ArbejdsprogramdokumentetDenne standard udgør en indlevering under Specialist Task DPS.ET1.ST06 i EATCHIP's domæne ATM Data Processing Systems (Databehandlingssystemer) (DPS) som specificeret i EATCHIP Arbejdsprogramdokument (EWPD), Udgave 2.0, dateret 30. september 94.3. Godkendelse og RettelserDenne standard har været genstand for den følgende godkendelsesprocedure som beskrevet detaljeret i Direktiverne for Eurocontrol standardisering:- Godkendelse ved the EATCHIP Operational Requirement and ATM Data Processing Team (ODT) (Team for Operationelle Krav og Behandling af ATM-data) ved korrespondanceprocedure;- Konsultation af alle ECAC-Lande gennem deres repræsentanter i the Committee of Management eller EATCHIP Project Board;- Godkendelse ved the EATCHIP Project Board og the Committee of Management;- Tiltrædelse ved the Permanent Commission (Den Permanente Kommission).Denne standards bestemmelser er effektive efter en tiltrædelse ved Den Permanente Kommission.For at imødekomme kravene fra udviklingen af Flyvekontroltjenesteprocedurer (ATC-procedurer) kan rettelser og tilføjelser foreslås gennem ODT for diskussion og mulig godkendelse. Kravene vil enten blive indarbejdet som en rettelse eller som en yderligere udgave af dokumentet for endossering og godkendelse i overensstemmelse med de specificerede procedurer.4. Redaktionel PraksisDen følgende praksis er blevet anvendt for at angive hver erklærings status: Retningsgivende Elementer er blevet skrevet som tekst med lys skrift; Anbefalede Elementer er blevet skrevet med lys, kursiv skrift, hvor statusen er blevet angivet med præfikset Anbefaling.Den følgende, redaktionelle praksis er blevet fulgt i skrivningen af specifikationerne: for Retningsgivende Elementer er det operative udsagnsord "skal" anvendt og for Anbefalede Elementer er det operative udsagnsord "bør" anvendt.Noter er skrevet med lys, kursiv skrift indledt med præfikset "NOTE".5. Forhold til Udgave 1 af Eurocontrol-standarden for On-Line DatauudvekslingDette dokument erstatter Delene 1 og 2 af Udgave 1 af Eurocontrol- standarden for On-Line Dataudveksling. Del 3, som beskriver de tekniske protokoller, der skal anvendes, erstattes af Eurocontrol-standarden for Dokument vedrørende Kontrol med Udveksling af Flyvedata, Del 1.6. Signifikante Ændringer i forhold til Udgave 1Det følgende er de mest signifikante ændringer af og tilføjelser til Udgave 1:1. Indarbejdelse af de følgende ekstra (ikke-obligatoriske) meddelelser med hensyn til den grundlæggende procedure:- Meddelelser om Ophævelsen af Koordinering (MAC);- Kodetildelingsmeddelelse (COD) for Sekundær Radar (SSR);- Informationsmeddelelse (INF).2. Definition af indhold og format af meddelelser til at understøtte grænsekrydsningen af en flyvning på en kurs, som ikke er en defineret Lufttrafiktjenesterute (ATS-rute), men som er defineret ved rutesegmentets begyndelses- og slutpunkter.3. Indarbejdelse af en dialogprocedure, som tillader:- identifikationen og forhandlingen af ikke-standard overførselsbetingelser ved flyveledere, som udfører planlægningsfunktionen;- tilvejebringelsen af evnen for den accepterende enhed til at stille mod-forslag til overførselsbetingelser;- tilvejebringelsen af overførsel af kommunikationsfaciliteter som del af proceduren med overførslen af kontrol.4. Anvendelsen af det format, der er beskrevet i Udgave 2 af Eurocontrol-standarddokumentet for Præsentation af Udvekslede ATS-data (ADEXP), er indført. Alle meddelelser, som er specificeret under den grundlæggende procedure, og de, der anvendes under dialogprocedurens koordineringsfase, er beskrevet ved anvendelse af både Formater for Civil Aviation Organisation (ICAO-formater) og ADEXP-formater. Meddelelser om Overførsel af Kommunikation beskrevet under dialogprocedure er kun beskrevet ved anvendelse af ADEXP-format.5. Sletning af de følgende Annekser til Udgave 1:A: AATC-Enhedsidentifikation.B: OLDI- Meddelelsesstruktur(alle meddelelser i Udgave 3 omfatter Eksempler).D: Historisk Oversigt.E: Implementeringsplan.F: Indvigelse ved Lande.G: Retningslinier for Implementering.H: Retningslinier for Evaluering af OLDI.6. Adskillelse af Del 3 - Tekniske Krav - fra anvendelsesspecifikationen.7. Forhold til Andre DokumenterDette dokument henviser til anvendelsen af to typer af feltformat i udarbejdelsen af meddelelser; disse er ICAO og ADEXP.ICAO-feltformater er beskrevet i Henvisning 1. I tilfælde af at Henvisning 1 erstattes af et andet dokument, skal definition af ICAO-felttyper være som i det dokument.Formats for ADEXP-felter er beskrevet i Henvisning 2.NOTEHenviste dokumenter er oplistet i Afsnit 2.8. SprogDet engelske sprog er blevet anvendt ved udfærdigelsen af dette dokuments original.1. INTRODUKTION1.1. Formål1.1.1. Flyvninger, der er forsynet med en ATC-tjeneste, overføres fra én ATC-enhed til den næste på en måde, som er udformet til at sikre fuldstændig sikkerhed. For at opnå dette formål er det en standardprocedure, at passagen af hver flyvning på tværs af grænsen mellem ansvarsområderne for de to enheder koordineres mellem dem forlods og at kontrollen med flyvningen overføres, når den er ved eller støder op til grænsen.1.1.2. Passagen af data med hensyn til individuelle flyvninger som del af koordineringsprocessen er, hvor den udføres over telefon, en større understøttelsesopgave ved ATC-enheder, i særdeleshed ved Kontrolcentraler (ACCer). Den operationelle brug af forbindelser mellem Flyvedatabehandlingssystemer (FDPSer) ved ACCer med henblik på at erstatte sådanne verbale "estimater", hvilket betegnes On-Line Data Interchange (On-Line Dataudveksling) (OLDI), begyndte i Europa i de tidlige 1980'ere.1.1.3. For at lette implementering blev fælles regler og meddelelsesformater udarbejdet og vedtaget af de berørte agenturer og er indarbejdet i Udgave 1 af Eurocontrol-standarden for On-Line Dataudveksling; dette dokument, Udgave 1, er blevet fremstillet for at støtte den fortsatte udvikling af sådanne faciliteter i overensstemmelse med EATCHIPs krav.1.2. Omfang1.2.1. Dette dokument specificerer de faciliteter og meddelelser, som skal tilvejebringes mellem de FDPSer, der betjener ATC-enheder, med henblik på at opnå:- den påkrævede koordinering forud for overførslen af flyvninger fra én enhed til den næste;- overførslen af sådanne flyvningers kommunikation.1.2.2. Dette dokument:- definerer meddelelsesformaterne og reglerne for indholdet;- beskriver de faciliteter, der er påkrævet ved sådanne enheder, hvilke faciliteter er en forudsætning for brugen af dataudveksling til dette formål.1.2.3. Denne standard kan anvendes mellem medlemslandene af Eurocontrol til internationale OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste.1.2.4. AnbefalingDet anbefales, at lande ved Den Europæiske Civile Luftfartskonference (European Civil Aviation Conference (ECAC)) vil anvende denne standard til:- internationale OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste inden for ECAC-området;- OLDI-faciliteter mellem enheder, der leverer en ATC-tjeneste, hvilke enheder er interne i det pågældende land.2. HENVISNINGER2.1. De følgende Dokumenter indholder bestemmelser, som ved henvisning i denne tekst udgør bestemmelser for dette Eurocontrol-standarddokument.Ved tidspunktet for offentliggørelse af dette Eurocontrol-standarddokument var de anførte udgaver af de henviste dokumenter gyldige.Der skal øjeblikkeligt tages hensyn til en hvilken som helst revidering af de henviste ICAO Dokumenter for at revidere dette Eurocontrol-standarddokument.Revideringer af de andre henviste dokumenter skal ikke udgøre en del af bestemmelserne i dette Eurocontrol-standarddokument før de formelt er bedømt og indarbejdet i dette Eurocontrol-standarddokument.I tilfælde af konflikt mellem kravene i dette Eurocontrol-standarddokument og indholdet i disse andre henviste dokumenter, skal dette Eurocontrol-standarddokument have forrang.2.2. Der henvises til følgende dokumenter i dette standarddokument:1. Procedures for Air Navigation Services - Rules of the Air &  Air Traffic Services, ICAO Document 4444, Trettende udgave, dateret 7 nov. 1996, som det er rettet.2. Udgave 2.0 af Eurocontrol Standard document ATS Data Exchange Presentation (Eurocontrol-standarddokument for Præsentation af udvekslede ATS-data) (ADEXP), henvisning DPS-ET1-ST09-STD-01-00, dateret juni 1998.3. DEFINITIONER, SYMBOLER OG FORKORTELSER3.1. DefinitionerMed henblik på denne Eurocontrol-standard skal de følgende definitioner gælde.3.1.1. Accepterende Enhed (Accepting Unit): Den enhed, som leverer en ATC-tjeneste, der skal tage kontrol eller har taget kontrol over en flyvning, når overførslen fra én enhed til den næste skal ske eller er sket.3.1.2. Kvittering (Acknowledgement): Oplysning om, at en meddelelse er blevet modtaget og at det er konstateret, at den kan behandles korrekt.3.1.3. Aktivering (Activation): Den proces i en modtagende ATC-enhed, hvorved flyveplanen for den refererede flyvning opgraderes til at indeholde de data, der fremskaffes af den overførende enhed, som en del af koordineringsprocessen mellem de to enheder og som resulterer i fremskaffelsen af dataene til flyveledere.3.1.4. Højde (Altitude): Den vertikale afstand for et niveau, et punkt eller en genstand, der betragtes som et punkt, målt fra middelvandstand.3.1.5. Anvendelse (Application): Den del af et ATS-undersystem, som opfylder denne standard og grænseflader med sådanne helheder i andre ATS-systemer.3.1.6. Ansvarlighedsområde (Area of Responsibility): Et luftrum med definerede dimensioner, inden i hvilket en ATC-enhed sørger for lufttrafiktjeneste.3.1.7. Forbindelse (Association): En procedure, hvori et system forbinder en modtaget OLDI-meddelelse med en flyveplansindførsel i databasen.3.1.8. ATC-Enhed (ATC Unit): En enhed, der sørger for en flyvekontroltjeneste.3.1.9. Tilgængelighed (Availability): En sandsynlighed for, at en facilitet vil være tilgængelig for en bruger til et tidspunkt.3.1.10. Grænse (Boundary): De planer (laterale og vertikale), der afgrænser en ATC-enheds ansvarlighedsområde.3.1.11. Klareret Flyveniveau (Cleared Flight Level): Det flyveniveau til hvilket eller ved hvilket en flyvning aktuelt er blevet klareret af ATC.3.1.12. Koordinering, ATC (Co-ordination, ATC): Den proces, som udføres mellem ATC-enheder med tilstødende ansvarlighedsområder, med formelt at advisere hinanden om den planlagte passage af flyvninger på tværs af grænsen for at sikre flysikkerhed gennem konsistens af tilsigtede aktioner.3.1.13. Koordineringsmeddelelse (Co-ordination Message): En fællesbetegnelse, som henviser til en meddelelse, der anvendes til at udføre ATC-koordinering. Disse indeholder CDNen, som er en specifik meddelelse beskrevet i afsnit 8.8.3.1.14. Koordineringsfase (Co-ordination Phase): Den fase, hvorunder de overførende og modtagende ATC-enheder bliver enige om de betingelser (f.eks. flyveniveau, grænsepunkt), under hvilke en flyvning vil passere fra den ene enheds styring til den anden enheds styring, med hensyn til en given flyvning.3.1.15. Koordineringspunkt (Co-ordination Point): Et punkt på eller stødende op til grænsen, hvilket punkt kendes af ATC-enhederne i en koordineringssekvens og henvises der til i koordineringsmeddelelser.3.1.16. Korrelation (Correlation): Den proces, der er baseret på definerede kriteria med hensyn til at forbinde flyveplandata og radarsporet for den samme flyvning, almindeligvis for præsentation på et flyvelederdisplay.3.1.17. Eurocontrol-Standard (Eurocontrol Standard): En hvilken som helst specifikation for fysiske kendetegn, konfiguration, materiale, ydeevne, mandskab eller procedure, hvis ensartede anvendelse er blevet godkendt som værende væsentlig for implementering i ATS-systemer i Eurocontrol-Medlemslande. En Eurocontrol-standard må ikke være i konflikt med ICAO standarder, men bør komplementere sidstnævnte, hvor det er hensigtsmæssigt.3.1.18. Udøvende Flyveleder (Executive controller): En flyveleder, som giver instruktioner direkte til flyvninger under hans/hendes kontrol. Sådanne flyveledere omfatter de, der sørger for områderadarkontroltjeneste.3.1.19. Udgangsniveau (Exit Level): Det niveau, hvor en flyvning er blevet koordineret til at krydse en overførsel af kontrolpunkt. Et udgangsniveau kan omfatte supplerende krydsningsbetingelser, der definerer det niveaubånd, som en stigende/nedstigende flyvning vil være indenfor.3.1.20. Flyveplan (Flight Plan): Specificeret information leveret til lufttrafiktjenesteenheder i forbindelse med et luftfartøjs tiltænkte flyvning eller en del af dets tiltænkte flyvning. Endvidere information udledt fra flyveplanen for en specifik flyvning, der holdes inden for et FDPS.3.1.21. Generering (Generate): En proces i et ATC-system, hvor relevante data uddrages fra databasen/databaserne og der dannes en meddelelse til transmission til en modtagende ATC-enhed.3.1.22. ICAO Format (ICAO Format): Det format, der anvendes for jord-jord-transmissionen af ATS-meddelelser og som bruger de felttyper og -separatorer, der er beskrevet i Henvisning 1.3.1.23. Niveau (Level): Et fælles udtryk, som angår vertikal position af et luftfartøj i flyvning; inden for denne standard omfatter udtrykket niveau eller flyveniveau højde i de tilfælde, hvor det bruges.3.1.24. Underretning (Notification): Den proces, hvorved den overførende enhed transmitterer data til at opdatere systemet ved den modtagende enhed som forberedelse til koordineringsfasen.3.1.25. Modtagende Enhed (Receiving Unit): Den ATC-enhed, som en meddelelse sendes til.3.1.26. Pålidelighed (Reliability): Den procentdel af den planlagte tilgængelighed i løbet af hvilken tjenesten skal være driftsklar.3.1.27. Anmodet flyveniveau (Requested Flight Level): Et flyveniveau, der anmodes om ved flyvningen i flyveplanen.3.1.28. Revidering (Revision): En rettelse til data, som tidligere er blevet sendt af den overførende ATC-enhed til den modtagende ATC-enhed.3.1.29. Supplerende Krydsningsniveau (Supplementary Crossing Level): Et niveau, ved hvilket eller over hvilket, eller ved hvilket eller under hvilket en flyvning er blevet koordineret til at krydse overførslen af kontrolpunkt. Det supplerende niveau er, hvis det er til stede, et element i udgangsniveauet.3.1.30. Systemflyveplan (System Flight Plan): Information udledt fra flyveplanen for en specifik flyvning, der holdes inden for et FDPS.3.1.31. Transaktionstid (Transaction Time): Et tidsinterval, der følger efter initieringen af en meddelelse, i løbet af hvilket der udføres transmission, indledende behandling i det modtagende system, generering og transmission af en kvitteringsmeddelelse og dens identifikation i det overførende system.3.1.32. Overførsel af Kontrolpunkt (Transfer of Control Point): Et defineret punkt, som er placeret ved et luftfartøjs flyvevej, ved hvilket punkt ansvaret for at levere ATS til luftfartøjet overføres fra én ATC-enhed eller kontrolposition til den næste. Det er ikke nødvendigvis sammenfaldende med koordineringspunktet.3.1.33. Overførselsfase (Transfer Phase): En flyvefase, som følger efter koordineringsfasen, hvorunder overførslen af kommunikation gennemføres.3.1.34. Overførende Enhed (Transferring Unit): Den ATS-enhed, der i en koordineringssekvens er ansvarlig for at levere en tjeneste til en flyvning før grænsen og som påbegynder koordineringsfasen med den næste enhed.3.1.35. Transmittering (Transmit): Kommunikering af en meddelelse fra ét system til et andet.3.1.36. Enhed (Unit): Lufttrafiktjenesteenhed.3.1.37. Advarsel (Warning): En meddelelse, der vises i en arbejdsposition, når den automatiske koordineringsproces har svigtet.3.2. Symboler og ForkortelserMed henblik på denne Eurocontrol-standard skal de følgende symboler og forkortelser gælde.ABI Forudgående Grænseinformationsmeddelelse (Advance Boundary Information Message)ACC Kontrolcentral (Area Control Centre)ACP Acceptmeddelelse (Accept Message)ACT Aktiveringsmeddelelse (Activate Message)ADEXP Præsentation af Udvekslede ATS-Data (ATS Data Exchange Presentation)ATC Flyvekontroltjeneste (Air Traffic Control)ATM Regulering af Lufttrafikken (Air Traffic Management)ATS Lufttrafiktjeneste (Air Traffic Service)CDN Koordineringsmeddelelse (Co-ordination Message)CNL Flyveplansannulering (Fligth Plan Cancellation)COD SSR Kodetildelingsmeddelelse (SSR Code Assignment Message)COF Frekvensændringsmeddelelse (Change of Frequency Message)COP Koordineringsspunkt (Co-ordination Point)DED Direktorat for EATCHIP-Udvikling, Eurocontrol (Directorate of EATCHIP Development Eurocontrol)EATCHIP Program for Harmonisering og Integration af Lufttrafikkontrol i Europa (European ATC Harmonisation and Integration Programme)ECAC Den Europæiske Civile Luftfartskonference (European Civil Aviation Conference)ETO Forventet Tidspunkt over (Estimated time over)ETOT Forventet Starttid (Estimate Take-Off Time)EWPD Dokument for EATCHIP Arbejdsprogram (EATCHIP Work Programme Document)FDPS Flyvedatabehandlingssystem (Flight Data Processing System)FRF Yderligere Rute for Flyvning (Further Route of Flight)HMI Menneske-Maskine-Grænseflade (Human-Machine-Interface)HOP Meddelelse om Forslag om Overdragelse (Handover Proposal Message)ICAO Den Internationale Civile Luftfarts Organisation (International Civil Aviation Organisation)INF Informationsmeddelelse (Information Message)LAM Logisk Kvitteringsmeddelelse (Logical Acknowledgement Message)LoA Aftalebrev (Letter of Agreement)MAC Meddelelse for Ophævelsen af Koordinering (Message for the Abrogation of Co-ordination)MAS Meddelelse om Manuel Overtagelse af Kommunikation (Manuel Assumption of Communications)NM Sømil (Nautical Mile)OLDI On-Line Dataudveksling (On-Line Data Interchange)ORCAM Metode til Kodetildeling for Oprindeligt Område (Originating Region Code Assignment Method)PAC Foreløbig Aktiveringsmeddelelse (Preliminary Activate Message)RAP Meddelelse om Henvist Aktiveringsforslag (Referred Activate Proposal Message)REV Revideringsmeddelelse (Revision Message)RJC Meddelelse om Afvisning af Koordinering (Reject Co-ordination Message)ROF Frekvensanmodningsmeddelelse (Request on Frequency Message)RRV Meddelelse om Henvist Revidering (Referred Revision Message)SBY Stand-by Meddelelse (Stand-by Message)SDM Supplerende Datameddelelse (Supplementary Data Message)SSR Sekundær Radar (Secondary Surveillance Radar)SYSCO Systemstøttet Koordinering (System Supported Co-ordination)TI Overførselsinitiering (Transfer Initiation)TIM Overførselsinitieringsmeddelelse (Transfer Initiation Message)TWR/APP Tårn (luftfartøjskontrol) og Indflyvningskontrol (Tower (aerodrome control) and Approach Control4. GENERELLE KRAV4.1. IntroduktionDette afsnit beskriver de generelle, operationelle krav, der er nødvendige for implementeringen af en OLDI-facilitet mellem ATC-enheder, og kravene til klassifikation og ydeevne for de forskellige typer af anvendte meddelelser.4.2. Krav til Flyvedatabehandlingssystem4.2.1. FlyvedatabaseEnheder, som anvender en facilitet beskrevet i dette dokument, skal være forsynet med data fra et FDPS, hvilke data indeholder al den information, der er påkrævet for visningen, behandlingen og kompileringen af meddelelserne som specificeret. Den primære datakilde for hver flyvning er flyveplanen, der er indleveret af fartøjschefen eller på hans/hendes vegne. Yderligere dataelementer opnås ved behandlingen af flyveplaner med henvisning til den pågældende enheds ydre forhold.4.2.2. Operation i RealtidOLDI-proceduren indeholder hændelser i den overførende ATC-enhed til at initiere funktioner, som er nødvendige for den rettidige præsentation af data til den overførende flyveleder og transmissionen af koordineringsdata til den accepterende enhed. Til dette formål skal FDPSet være i stand til at initiere funktioner ved sammenligningen af Koordineret Universal Tid og egnede tidsparametre med tider ved specificerede positioner på flyvningens rute som bestemt fra flyvedatabasen.4.2.3. Datakommunikationskapacitet4.2.3.1. FDPSet skal være i stand til at modtage og transmittere flyvedata i det format, der er egnet for meddelelsen som specificeret i dette dokument, via et datakommunikationsmedium, der understøtter OLDI-funktionen.4.2.3.2. AnbefalingFDPSet bør have udviklingspotentialet til at muliggøre tilføjelsen af nye meddelelser, der kan være indbefattet i fremtidige udgaver af denne standard.4.2.3.3. Inden for de krav til ydeevne, som er specificeret i dette dokument, skal datakommunikationsmediet sørge for en hurtig og pålidelig anvendelse-til-anvendelse-dataudveksling ved:- at sikre integriteten af transmissionen af OLDI-meddelelsen;og- at overvåge enten punkt-til-punkt-forbindelser eller statusen af kommunikationsnetværket, afhængigt af hvad der er velegnet.4.2.3.4. FDPSet skal advare arbejdspositionerne, når der detekteres anormaliteter ved hjælp af datakommunikationssystemet.4.2.4. Anvendelsesfunktioner4.2.4.1. De systemer, der bruges til tilvejebringelsen af OLDI-faciliteter, skal være i stand til automatisk at modtage, lagre, behandle, uddrage og levere til display og overføre OLDI-relaterede data i realtid.4.2.4.2. FDPSet skal:- udtrykke foreliggende, operationelle data, der er relevante for OLDI-funktion som påkrævet ved denne standard, enten opdateret automatisk, gennem manuel indførsel eller ved en kombination af begge;- være i stand til at uddrage sådanne elementer fra flyveplansdatabasen;- identificere den næste ATC-enhed på flyvningens rute.4.2.4.3. Det følgende skal aftales bilateralt:- Koordineringspunkter (COPer);- Henvisningspunkter, der anvendes til pejlings- og afstandsnotationer ved identifikationen af COP på direkte segmenter uden for ATS, hvor disse anvendes.NOTECOPerne er ikke altid identiske med overførslen af kontrolpunkter.4.2.5. Menneske-maskine-grænseflade (HMI)4.2.5.1. HMIen skal være i stand til:- at vise det operationelle indhold af OLDI-meddelelser og relevante advarsler knyttet til modtagede meddelelser for øjeblikkelig opmærksomhed;- at rette koordinerings- og overførselsmeddelelsesadvarsler til de operationelle positioner, der er ansvarlige for koordineringen af de pågældende flyvninger.4.2.5.2. ATC-personale skal være forsynet med et middel til at modificere de data, hvorfra det operationelle indhold af meddelelserne udledes som påkrævet i dette dokument.4.2.5.3. HMIen skal indikere, at transmission af meddelelsen er under udførelse eller at meddelelsen er blevet transmitteret vellykket, alt efter hvad der er tilfældet.4.2.5.4. En advarsel eller underretning til den passende ATC eller de(n) passende tekniske position(er) skal genereres automatisk, hvis der ikke er blevet modtaget nogen kvittering inden for den parametertid, der følger efter en transmission af en koordinerings- eller overførselsmeddelelse.4.2.5.5. En sådan advarsel eller oplysning skal være i en sådam udformning, at den øjeblikkelig tiltrækker den passende arbejdspositions opmærksomhed.4.2.5.6. AnbefalingHMIen ved ATS-positioner, der anvender OLDI, bør sørge for en advarsel, hvis OLDI- faciliteten ikke er tilgængelig.4.2.6. Initiering af meddelelser4.2.6.1. Hvert system skal indeholde et sæt af systemparametre for at sikre rettidig, automatisk initiering af OLDI-meddelelser.4.2.6.2. AnbefalingEvnen til manuelt at initiere transmissionen af en koordineringsmeddelelse forud for den forventede transmissionstid bør være til rådighed.4.2.6.3. Den automatiske hændelse skal altid være sikret, hvis manuel initiering ikke udføres.4.2.6.4. Systemet skal anvende tidsparametre til at definere følgende:- gennemløbstid, forud for transmission, når det operationelle indhold af meddelelserne inden i den overførende enhed vises;- gennemløbstid, global eller per COP, til at transmittere meddelelsen, når det er anvendeligt;- tid efter transmission af en meddelelse, inden for hvilken tid en anvendelsesniveuakvittering skal modtages (timeout).4.2.6.5. En meddelelse skal transmitteres uden forsinkelse, når den påkrævede information bliver tilgængelig til et senere tidspunkt end til det tidspunkt, hvor den ellers ville være blevet transmitteret.Eksempel:En flyvning påbegynder et GAT IFR-segment ved et punkt, der ligger nær på den grænse, som den derefter skal krydse; ETOet ved punktet kommunikeres otte minutter før COPet, til hvilket tidspunkt transmission af ACT-meddelelsen allerede er forsinket baseret på den/de anvendelige tidsparameter/tidsparametre; meddelelsen sendes uden forsinkelse.4.2.7. Modtagelse af meddelelser4.2.7.1. ATC-systemet skal være i stand til:- at modtage OLDI-meddelelser;- at behandle dem automatisk i overensstemmelse med denne standard;- at udsende flyvedata i overensstemmelse med den modtagede meddelelse og at vise advarsler i tilfælde af inkonsistens i de modtagede data;- at generere og transmittere kvitteringsmeddelelser automatisk ved anvendelsesniveauet.4.2.7.2. En kvitteringsmeddelelse (Logisk Kvitteringsmeddelse (LAM), Acceptmeddelelse (ACP) eller Stand-by Meddelelse (SBY)) skal genereres og transmitteres, når den tilsvarende meddelelse er blevet behandlet og præsentationen af resultaterne af behandlingen til de(n) behørige position(er) efter behov er sikret.NOTEDe detaljerede betingelser for genereringen af en kvittering er specificeret individuelt for hver meddelelse.4.3. Opdatering fra overvågningsdataAnbefalingFor at sikre nøjagtigheden af tidsestimatdata bør der anvendes information udledt fra sporingen af flyvningen ved radar eller andre overvågningsmidler til at opdatere flyveplansdatabasen.4.4. Optegnelse af OLDI-data4.4.1. IndholdIndholdet af alle OLDI-meddelelser og modtagelsestiden skal optegnes.4.4.2. FaciliteterDer skal være faciliteter tilgængeligt til genvindingen og visningen af de optegnede data.4.5. Tilgængelighed, Pålidelighed, Datasikkerhed og Dataintegritet4.5.1. Tilgængelighed4.5.1.1. OLDI-faciliteten skal være tilgængelig i løbet af tiden med trafikale normal- og spidsbelastninger mellem de to pågældende enheder.4.5.1.2. AnbefalingOLDI-faciliteten bør være tilgængelig 24 timer hver dag.4.5.1.3. En hvilken som helst planlagt nedlukket periode (og således den planlagte tilgængelighedstid) skal være aftalt bilateralt mellem de to berørte enheder.4.5.2. Pålidelighed4.5.2.1. Pålidelighed af hver OLDI-forbindelse skal være mindst 99.86 % (svarende til en nedlukningstid på ikke mere end 12 timer per år, baseret på 24-timers tilgængelighed).4.5.2.2. AnbefalingHvor det operationelt er retfærdiggjort, bør der sørges for en pålidelighed på mindst 99.99% (svarende til en nedlukningstid på ikke mere end 52 minutter per år, baseret på 24-timers tilgængelighed).4.5.3. DatasikkerhedAnbefalingDer bør ved OLDI-faciliteterne gøres brug af datasikkerhedsmetoder (f.eks. adgangsrettigheder, kildeverificering) og hvor det er anvendeligt netværksmanagement.4.5.4. DataintegritetFejlraten ved anvendelsesniveau må ikke overstige én transmissionsfejl per 2000 meddelelser.4.6. Operationel evaluering4.6.1. EvalueringsperiodeHver ny OLDI-facilitet, heriblandt en ny facilitet på en eksisterende forbindelse, skal være udsat for en evalueringsperiode til at verificere dataintegriteten, nøjagtigheden, ydeevnen, kompatibiliteten med ATC-procedurer og overordnet sikkerhed forud for dens operationelle implementering.NOTEEn procedure til at medvirke til evalueringen af en ny OLDI-facilitet er tilgængelig fra OLDI-Sekretariatet, Eurocontrol.4.6.2. Operationel introduktionsdatoDatoen for den operationelle introduktion, hvilket forudsætter fuldendelse af evalueringsperioden, skal formelt være aftalt mellem de to enheder.5. MEDDELELSESKATEGORIER5.1. Generelt5.1.1. FormålDette afsnit i dokumentet:- definerer kategorierne for meddelelser;- angiver krav til transaktionstider for kategorierne;- angiver, hvilke meddelelser, der er obligatoriske, og hvilke, der er ekstra;- tildeler kategorier til meddelelsestyper.5.1.2. MeddelelseskategorierOLDI-meddelelser er blevet tildelt de følgende kategorier:- Kategori 1: Overførsel af Kommunikation;- Kategori 2: Koordinering;- Kategori 3: Underretning.5.2. Transaktionstider5.2.1. Transaktionstidsbetingelser5.2.1.1. De specificerede transaktionstider omfatter transmission, indledende behandling ved den modtagende enhed, dannelse af kvitteringsmeddelelsen, dens transmission og modtagelse ved den overførende enhed. De automatiske kvitteringsmeddelelser LAM og SBY er derfor ikke blevet tildelt en meddelelseskategori.5.2.1.2. De maksimale transaktionstider for de forskellige kategorier af meddelelser skal være som angivet i Tabel 5-1.Tabel 5-1Maksimale transaktionstider>TABELPOSITION>5.2.1.3. Der skal være defineret en timeout-værdi per meddelelseskategori eller -type.5.2.1.4. Hvis der ikke er blevet modtaget nogen kvittering inden for den specificerede tid efter transmission, skal en meddelelse betragtes som værende transmitteret eller behandlet uden held og en advarsel skal udsendes som specificeret i det relevante afsnit i dette dokument.5.2.1.5. AnbefalingTimeout-værdierne for de tre kategorier bør ikke overstige 12 sekunder, 30 sekunder og 60 sekunder respektivt.5.3. Meddelelsesklassifikation og -kategorisering5.3.1. Meddelelsesklassifikation - Obligatorisk og Ekstra5.3.1.1. De meddelelser, som er beskrevet i dette dokument, klassificeres som enten obligatoriske eller ekstra.5.3.1.2. Hvor en meddelelse er beskrevet som obligatorisk (Mandatory) (M) for transmission (TX), skal der være indeholdt behandling for at være i stand til at sende sådanne meddelelser.5.3.1.3. Hvor en meddelelse er beskrevet som obligatorisk for modtagelse (reception) (REC), skal der være indeholdt behandling for at være i stand til at behandle modtagede meddelelser.NOTEI exceptionelle tilfælde, hvor trafikreguleringen mellem to enheder er envejs, kan de obligatoriske meddelelser være anvendelige i kun én retning.5.3.1.4. Hvor en meddelelse er beskrevet som ekstra (complementary) (C) for transmission, skal der være indeholdt behandling for at være i stand til at sende sådanne meddelelser, hvis det kræves af den sendende enhed og hvis det er aftalt bilateralt med den modtagende enhed.NOTEEkstra meddelelser kan anvendes i kun én retning, hvis det bestemmes ved operationelle krav.5.3.1.5. Hvor en meddelelse er beskrevet som ekstra for modtagelse, skal der være indeholdt behandling for at være i stand til at behandle modtagede meddelelser, hvor en sådan brug er blevet aftalt bilateralt.5.3.1.6. Krav beskrevet i Tabellerne 5-3 og 5-4 gælder kun, hvor anvendelsen af Dialogproceduren for Koordinering og/eller Overførsel af Kommunikation respektivt er blevet aftalt bilateralt mellem ATC-enheder.5.3.2. Kategorisering af Meddelelser5.3.2.1. Kategoriseringen af meddelelser for den grundlæggende procedure er specificeret i Tabel 5-2.5.3.2.2. Kategoriseringen af de yderligere koordineringsmeddelelser for dialogproceduren er specificeret i Tabel 5-3.5.3.2.3. Kategoriseringen af overførsel af kommunikationsmeddelelser for dialogproceduren er specificeret i Tabel 5-4.Tabel 5-2Grundlæggende Proceduremeddelelser>TABELPOSITION>Tabel 5-3Dialogprocedure - Koordineringsfasemeddelelser(Supplerende til Tabel 5-2)>TABELPOSITION>Tabel 5-4Dialogprocedure - Overførselsfasemeddelelser>TABELPOSITION>6. GRUNDLÆGGENDE PROCEDURE - OBLIGATORISKE MEDDELELSER6.1. Generelt6.1.1. Beskrivelse af KravDette afsnit beskriver det minimale krav ved anvendelsesniveauet for implementeringen af OLDI-faciliteter.6.1.2. ImplementeringEnheder, som anvender OLDI til koordineringen af flyvninger, skal implementere ABI, ACT og LAM som beskrevet i dette afsnit, bortset fra de tilfælde hvor det er blevet aftalt bilateralt at anvende koordineringsdialogproceduren som beskrevet i dette dokuments Afsnit 8, i hvilket tilfælde betingelserne for anvendelsen af ACT- og LAM-meddelelserne er som defineret i det afsnit.6.2. Forudgående Grænseinformationsmeddelelse (ABI)6.2.1. Formål med ABI-MeddelelsenABI opfylder de følgende, operationelle krav:- at sørge for erhvervelse af manglende flyveplansdata;- at tilvejebringe forudgående grænseinformation og revideringer dertil for den næste ATC-enhed;- at opdatere de grundlæggende flyveplansdata;- at lette en tidlig korrelation af radarspor;- at lette en nøjagtig vurdering af kortsigtet sektorbelastning.ABI er en underretningsmeddelelse.6.2.2. Indhold af MeddelelseABI-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- SSR Tilstand og -Kode (hvis det er tilgængeligt);- Afgangsflyveplads;- Estimatdata;- Bestemmelsesflyveplads;- Nummer for og type af Luftfartøj;- Rute (frivilligt);- Andre Flyveplansdata (frivilligt).NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.6.2.3. Regler for Anvendelse6.2.3.1. Generelt6.2.3.1.1. Bortset fra de tilfælde, som er angivet i 6.2.3.1.3 og 6.2.3.1.4 nedenfor, skal der sendes én eller flere ABI-meddelelser for hver flyvning, som er planlagt til at krydse grænsen mellem ansvarsområder omfattet af OLDI-procedurer.6.2.3.1.2. Når ABI-meddelelsen sendes, skal den gå forud for Aktiveringsmeddelelsen (ACT) eller Meddelelse om Henvist Aktiveringsforslag (RAP).6.2.3.1.3. Der skal ikke genereres en ABI-meddelelse, hvis en Foreløbig Aktiveringsmeddelelse (PAC) skal sendes.6.2.3.1.4. AnbefalingABI-transmission bør forhindres, hvis ACT- eller RAP-meddelelsen er forfalden til transmission øjeblikkeligt eller inden for et bilateralt aftalt tidsinterval.NOTEFormålet med denne anbefaling er at undgå den forsøgte, samtidige afgørelse med hensyn til anormaliteter ved forskellige positioner i den modtagende enhed med hensyn til ABI- og ACT-meddelelser for den samme flyvning.6.2.3.1.5. Der skal sendes en revideret ABI-meddelelse, hvis den efterfølgende ACT-meddelelse ikke er blevet genereret og:- flyvningens rute er blevet modificeret således, at COPet i den tidligere ABI-meddelelse ikke længere er nøjagtigt;- bestemmelsesflyveplanen er blevet ændret;eller- typen af luftfartøj er blevet ændret.6.2.3.1.6. AnbefalingDer bør sendes en revideret ABI-meddelelse, hvis den efterfølgende ACT-meddelelse ikke er blevet genereret og én af de følgende emner er genstand for forandring:- Det forventede grænsekrydsningsniveau;- Den forventede SSR-kode ved overførsel af kontrolpunkt;- Når det forventede tidspunkt over (ETO) ved COPet er forskelligt fra den tidligere ABI-meddelelse i længere tid end den tid, der er specificeret i Aftalebrevet (LoA);- Vilkårlige andre data, som er aftalt bilateralt.6.2.3.2. Behandling i den Modtagende Enhed6.2.3.2.1. Det ATC-system, som modtager en ABI-meddelelse, skal forsøge at få forbindelse med de tilsvarende flyveplansdata.6.2.3.2.2. Hvis flyveplansforbindelsen ikke er vellykket, skal en flyveplan dannes automatisk eller manuelt i det modtagende system.6.2.3.2.3. Hvis flyveplansforbindelsen er vellykket, men der identificeres en uoverensstemmelse mellem dataene i meddelelsen og tilsvarende data i det modtagende system, hvilken uoverensstemmelse ville resultere i et behov for en korrigerende handling ved modtagelsen af den følgende ACT-meddelelse, skal uoverensstemmelsen henvises til en passende position for afgørelse.6.2.3.3. Tidsparametre for Transmission6.2.3.3.1. Meddelelsen skal transmitteres et parameterantal af minutter før den forventede tid ved COPet.6.2.3.3.2. ABI-genereringsparameteren/ABI-genereringsparametrene skal indbefattes i Aftalebrevet LoA mellem de pågældende ATC-enheder.6.2.3.3.3. AnbefalingABI-genereringsparameteren/ABI-genereringsparametrene bør være:- variable, baseret på bestemmelserne i LoAet ;- defineret særskilt for hvert af COPerne.6.2.4. Kvittering for ABI6.2.4.1. KvitteringDer skal kvitteres for ABI-meddelelsen ved at generere og transmittere en LAM-meddelelse.NOTEDer genereres en LAM-meddelelse uanset resultaterne af forsøget på flyveplansforbindelse.6.2.4.2. Ingen KvitteringAnbefalingHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en ABI-meddelelse, bør der vises en advarsel ved en overvågningsposition.6.2.5. Eksempler"Air 2000" 253, en Boeing 757 fra Malta til Birmingham, som forventer BNE VOR til 1221 UTC, som flyver ved FL350 ved en egenfart på 480 knob, som er planlagt til at flyve via UB4 BNE UB4 BPK UB3 HON, som har en transpondervisning på A7012 og som anmoder om FL390. Det følgende er tilsvarende eksempler på ABI-meddelelsen sendt fra Reims til London ACC.6.2.5.1. ICAO(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)6.2.5.2. ADEXP-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON6.3. Aktiveringsmeddelelse (ACT)6.3.1. Formål med ACT-MeddelelsenACT-meddelelsen opfylder de følgende, operationelle krav:- At erstatte den verbale grænseberegning ved automatisk at transmittere detaljer for en flyvning fra én ATC-enhed til den næste forud for overførslen af kontrol;- At opdatere de grundlæggende flyveplansdata i den modtagende ATC-enhed med den seneste information;- At lette fordeling og visning af flyveplansdata inden i den modtagende ATC-enhed for de involverede arbejdspositioner;- Hurtigt at udføre visning af kaldesignal/kode-korrelering i den modtagende ATC-enhed;- At sørge for overførselsbetingelser til den modtagende ATC-enhed.6.3.2. Indhold af MeddelelseACT-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- SSR Tilstand og -Kode (hvis det er tilgængeligt);- Afgangsflyveplads;- Estimatdata;- Bestemmelsesflyveplads;- Nummer for og type af luftfartøj;- Rute (frivilligt);- Andre flyveplansdata (frivilligt).NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.6.3.3. Regler for Anvendelse6.3.3.1. Generelt6.3.3.1.1. Der skal sendes én ACT-meddelelse for flyvninger, der antages at krydse grænsen, bortset fra de tilfælde, der er angivet i afsnit 6.3.3.1.10.6.3.3.1.2. ACT-meddelelsen skal genereres og transmitteres automatisk til det forventede tidspunkt som specificeret i LoAet, med mindre den initieres til et tidligere tidspunkt.6.3.3.1.3. AnbefalingATC-mandskab skal være forsynet med et middel til at igangsætte transmissionen af ACT-meddelelser forud for den forventede transmissionstid.6.3.3.1.4. Det operationelle indhold af den ACT-meddelelse, der skal til at blive transmitteret, skal vises ved den arbejdsposition, som er ansvarlig for koordineringen af flyvningen forud for den aktuelle transmission.6.3.3.1.5. AnbefalingI forbindelse med 6.3.3.1.4 bør det tidspunkt, til hvilket det er forventes, at ACTen skal transmitteres automatisk, vises sammen med dens indhold.6.3.3.1.6. ACT-meddelelsen skal indeholde den seneste information om flyvningen, hvilket udtrykker de forventede udgangsbetingelser.6.3.3.1.7. Den relevante arbejdsposition skal underrettes om transmission af ACT-meddelelsen.6.3.3.1.8. Så snart der er modtaget en LAM, bliver ACT-meddelelsesdataene operationelt bindende for begge ATC-enhederne. De koordinerede overførselsbetingelser og det faktum, at LAMen er blevet modtaget, skal forelægges for ATC-mandskabet ved den overførende enhed.6.3.3.1.9. Der regnes med accept ved den modtagende enhed af de overførselsbetingelser, der rummes i ACT-meddelelsen, med mindre den modtagende enhed initierer koordinering for at rette i dem.6.3.3.1.10. Der kan kun sendes en yderligere ACT-meddelelse til den samme koordineringspartner, hvis den tidligere meddelelse er blevet ophævet ved anvendelsen af en MAC.6.3.3.1.11. Rute og Andre flyveplansdata skal være indeholdt, hvis det er aftalt bilateralt.6.3.3.2. Behandling i den Modtagende Enhed6.3.3.2.1. Det ATC-system, som modtager en ACT-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.6.3.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:- skal det operationelle indhold være indbefattet i flyveplanen;- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt;- skal der returneres en LAM.6.3.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen:- hvis den sektor, der er ansvarlig for at acceptere kontrol over flyvningen kan identificeres:- skal det operationelle indhold af meddelelsen vises ved sektoren;- skal en LAM returneres;- skal en flyveplan dannes;- i alle andre tilfælde skal en LAM ikke returneres.6.3.3.3. Parametre for Transmission6.3.3.3.1. Meddelelsen skal transmitteres til eller så snart som muligt efter det tidligste af de tidspunkter, der bestemmes ud fra det følgende:- et parameterantal af minutter før den forventede tid ved COPet;- det tidspunkt, til hvilket flyvningen er i en bilateralt aftalt afstand fra COPet.6.3.3.3.2. ACT-genereringsparameteren/ACT-genereringsparametrene skal være indbefattet i LoAet mellem de pågældende ATC-enheder.6.3.3.3.3. ACT-genereringsparameteren/ACT-genereringsparametrene skal være variable, baseret på bestemmelserne i LoAet.6.3.3.3.4. AnbefalingACT-genereringsparametre bør være defineret særskilt for hvert af COPerne.6.3.3.3.5. De specificerede parametre skal give tilstrækkelig tid til:- at den transmitterende enhed kan opdatere overførselsflyveniveauet for at udtrykke de forventede betingelser ved COPet;og- at den modtagende enhed kan behandle ACTen og generere og transmittere en LAM, men stadig give mulighed for, at der kan udføres verbal koordinering ved hjælp af den overførende enhed og at resulterende handling kan initieres ved hjælp af den accepterende enhed, hvis udvekslingen af data svigter.6.3.4. Kvittering for ACT6.3.4.1. KvitteringDer skal kvitteres for ACT-meddelelsen ved genereringen og transmissionen af en LAM-meddelelse.6.3.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en ACT-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for flyvningens koordinering.6.3.5. EksemplerDe følgende eksempler er en udvidelse af de, der er givet for ABI-meddelelsen i afsnit 6.2; alle detaljer er de samme bortset fra det ETO ved COPet, hvilket tidspunkt er 1226 i den viste ACT-meddelelse.6.3.5.1. ICAO(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)6.3.5.2. ADEXP-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON6.4. Logisk Kvitteringsmeddelelse (LAM)6.4.1. Formål med LAM-MeddelelsenLAMen er det middel med hvilket modtagelsen og beskyttelsen af en transmitteret meddelelse angives til den sendende enhed af den modtagende enhed.LAM-behandlingen forsyner ATC-mandskabet ved den overførende enhed med følgende:- en advarsel, når der ikke er blevet modtaget en kvittering;- en angivelse af, at den meddelelse, der kvitteres for, er blevet modtaget, vellykket behandlet, fundet som værende fri for fejl, lagret og hvor det er relevant er tilgængelig for præsentation til de(n) passende arbejdsposition(er)6.4.2. Indhold af MeddelelseLAM-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer- Meddelelseshenvisning.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.6.4.3. Regler for Anvendelse6.4.3.1. Generelt6.4.3.1.1. Reglerne for returneringen af en LAM er specificerede i de afsnit af dette dokument, som definerer behandlingen af hver meddelelse.6.4.3.1.2. LAM-meddelelsen skal genereres og transmitteres uden menneskelig intervention.6.4.3.1.3. LAM-meddelelsen skal ikke anvendes til at undgå behovet for tekniske meddelelser til at sikre integriteten af datatransmissioner.6.4.3.1.4. LAM-meddelelsen skal genereres og transmitteres øjeblikkeligt, således at kravet til transaktionstid for den meddelelse, som der kvitteres for, kan opfyldes.6.4.3.1.5. Med undtagelse af ABI-meddelelser skal det transmitterende ATC-system underrette den flyveleder, som er ansvarlig for koordineringen, hvis der ikke er blevet modtaget en LAM-meddelelse inden for den tidsparameter, der er fastsat for sådanne advarsler.6.4.4. Kvittering for LAMLAM-meddelelsen skal ikke kræve nogen kvittering.6.4.5. Eksempler6.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 0017. GRUNDLÆGGENDE PROCEDURE - EKSTRA MEDDELELSER7.1. Generelt7.1.1. Beskrivelse af KravDette Afsnit beskriver faciliteter, der er anvendelige med den grundlæggende procedure, hvilke faciliteter er supplerende til de, som er beskrevet i Afsnit 6 Grundlæggende Procedure - Obligatoriske Meddelelser.7.1.2. Implementering7.1.2.1. Anvendelsen af en hvilken som helst af de i dette Afsnit beskrevne faciliteter skal være aftalt bilateralt, før de indføres.7.1.2.2. Når en sådan anvendelse er aftalt, skal de regler, som er beskrevet i dette afsnit, gælde.7.2. Foreløbig Aktiveringsmeddelelse (PAC)7.2.1. Formål med PAC-MeddelelsenPAC-Meddelelsen opfylder de følgende, operationelle krav:- underretning og koordinering før afgang for en flyvning, hvor flyvetiden fra afgang til COPet er mindre end den tid, der ville være påkrævet til at overholde de aftalte tidsparametre for transmission af ACT-meddelelser;- underretning og koordinering før afgang for en flyvning før afgang ved en lokal (flyveplads/indflyvningskontrol) enhed til den næste enhed, der vil tage kontrol over flyvningen;- at sørge for erhvervelse af manglende flyveplansdata i tilfældet af uoverensstemmelser i den indledende fordeling af flyveplansdata;- at anmode om tildelingen af en SSR-kode fra den enhed, som underretningen/koordineringen ovenfor sendes til, hvis det er påkrævet.7.2.2. Indhold af MeddelelsePAC-Meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning (frivilligt);- Luftfartøjsidentifikation;- SSR Tilstand og -Kode;- Afgangsflyveplads;- Forventet Starttid eller Estimatdata;- Bestemmelsesflyveplads;- Type af Luftfartøj;- Rute (frivilligt);- Andre flyveplansdata (frivilligt).NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.7.2.3. Regler for Anvendelse7.2.3.1. Generelt7.2.3.1.1. Der skal sendes én eller flere PAC-meddelelser for hver flyvning, der er planlagt til at krydse grænsen mellem ansvarlighedsområder, hvor tiden fra afgang til COPet ikke ville tillade, at ACT-meddelelsen kan sendes til det påkrævede tidspunkt.7.2.3.1.2. Der skal sendes én eller flere PAC-meddelelser af Flyveplads-/Indflyvningsenheden til den næste enhed for hver afgående flyvning, for hvilken der enten er påkrævet underretning eller koordinering.7.2.3.1.3. AnbefalingFor implementeringen af PAC/LAM mellem enheder bør de relevante TWR/APP-systemer være forsynet med et middel til at indføre og videresende "opstart" ("start-up"), "push-back", "kørsel" (taxi) eller tilsvarende information ud fra hvilken ETOTet kan udledes til at beregne ETOet ved COPet og initiere transmissionen af PACen.7.2.3.1.4. Alt efter hvad, der er aftalt bilateralt, skal meddelelsen indeholde enten:- Forventet Starttid;eller- Estimatdata.7.2.3.1.5. Når meddelelseshenvisningen er indeholdt i overensstemmelse med bilateral aftale skal den:- indeholde meddelelsesnummeret for det første PAC-meddelelse sendt for flyvningen;- være indholdt i den anden og efterfølgende PAC-meddelelser.7.2.3.1.6. Anvendelsen af kodeanmodningsfaciliteten skal, hvis den er påkrævet, være aftalt bilateralt.7.2.3.1.7. Der skal sendes en revideret PAC-meddelelse, hvis en hvilken som helst af de følgende betingelser er opfyldt inden afgang:- flyvningens rute er blevet modificeret således, at COPet i den tidligere meddelelse ikke længere er nøjagtigt;- typen af luftfartøj er blevet ændret;- destinationsflyvepladsen i den tidligere PAC har vist sig at være ukorrekt.7.2.3.1.8. AnbefalingDer bør sendes en revideret PAC-meddelelse, hvis de følgende data er forskellige fra dataene i den tidligere PAC-meddelelse inden afgang:- niveauet (i estimatdataene, hvis de er til stede);- den forventede SSR-kode ved overførslen af kontrolpunkt;- den Forventede Starttid eller ETO ved COPet til et tidspunkt ud over en værdi, som er aftalt bilateralt;- der er en ændring i vilkårlige andre data, ifølge bilateral aftale.7.2.3.2. Behandling i den Modtagende Enhed7.2.3.2.1. Det ATC-system, som modtager en PAC-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.7.2.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:- skal det operationelle indhold være indbefattet i flyveplanen;- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt;- skal der returneres en LAM.7.2.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen:- hvis den sektor, der er ansvarlig for at acceptere kontrol over flyvningen kan identificeres:- skal det operationelle indhold af meddelelsen vises ved sektoren;- skal en LAM returneres;- skal en flyveplan dannes;- i alle andre tilfælde skal en LAM ikke returneres.7.2.3.2.4. Dataene i en anden eller en efterfølgende PAC-meddelelse skal erstatte dataene i den tidligere meddelelse.7.2.3.2.5. Hvis PAC-meddelelsen indeholder en anmodning om tildelingen af en SSR-kode og kan behandles korrekt som beskrevet i Afsnit 7.2.3.2.2 ovenfor, skal der returneres en COD-meddelelse ud over LAMen.NOTEIdet kodetildelingsprocessen kræver detaljeret flyveplansruteinformation, stilles der i dette dokument ikke noget krav om returneringen af en COD-meddelelse ved den modtagende enhed, hvor sådanne data måske ikke er tilgængelige for flyvningen. Dette forhindrer ikke, at en meddelelse kan returneres under sådanne omstændigheder, hvis der eksisterer en specifik, lokal egenskab og proceduren er aftalt bilateralt.7.2.3.3. Tidsparametre for TransmissionEn transmissionstidsparameter er ikke anvendelig, idet meddelelsen sendes som et resultat af en manuelt indført meddelelse, som identificerer flyvningens forestående afgang.7.2.4. Kvittering for PAC7.2.4.1. KvitteringDe meddelelser, der skal sendes som reaktion på en PAC-meddelelse, er beskrevet i Afsnit 7.2.3.2 ovenfor.7.2.4.2. Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en PAC-meddelelse, skal der vises en advarsel ved den position i ATC-enheden, som er ansvarlig for koordineringen med den næste enhed.7.2.4.3. Tilfælde af Ingen LAMI tilfælde af ingen LAM skal verbal koordinering initieres.7.2.4.4. Ingen COD-Meddelelse7.2.4.4.1. Hvis der ikke modtages en COD-meddelelse som reaktion på en kodeanmodning, som er indbefattet i PAC-meddelelsen, skal en advarsel vises ved en passende position.7.2.4.4.2. Hvor kodeanmodningsfunktionen skal bruges, skal den timeout-værdi, der skal anvendes, være aftalt bilateralt.7.2.5. Eksempler7.2.5.1. Estimeret Starttid og Kodeanmodning7.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 LSZA7.2.5.2. Tid ved COP7.2.5.2.1. ICAO(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-EBBR-9/B737/M)7.2.5.2.2. ADEXP-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL F110A -ARCTYP B737 -ADES EBBR7.3. Revideringsmeddelelse (REV)7.3.1. Formål med REV-MeddelelsenREV-meddelelsen bruges til at transmittere revideringer til koordineringsdata, som tidligere er sendt i en ACT-meddelelse, under forudsætning af at den accepterende enhed ikke ændres som et resultat af modifikationen.7.3.2. Indhold af MeddelelseREV-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning (frivilligt);- Luftfartøjsidentifikation;- SSR Tilstand og -Kode (frivilligt);- Afgangsflyveplads;- Estimatdata;- Koordineringspunkt (frivilligt);- Bestemmelsesflyveplads;- Rute (frivilligt);- Andre Flyveplansdata (frivilligt).NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.7.3.3. Regler for Anvendelse7.3.3.1. Generelt7.3.3.1.1. Der kan sendes én eller flere REV-meddelelsen til den enhed, som en flyvning for øjeblikket er blevet koordineret til ved brugen af en Aktiveringsmeddelelse.7.3.3.1.2. De følgende elementer skal være omfattet af revideringer:- ETO ved COPet;- Overførselsniveau(er);- SSR-Kode.7.3.3.1.3. Der skal sendes en REV-meddelelse, når:- ETOet ved COPet afviger fra det, der fremgår af den tidligere meddelelse, med mere end en bilateralt aftalt værdi, rundet af til den nærmeste heltalsværdi;- Der er en hvilken som helst forandring med hensyn til overførselsniveauet/overførselsniveauerne eller SSR-koden.7.3.3.1.4. Hvor det bilateralt er aftalt, skal der sendes en REV-meddelelse, hvis der en hvilken som helst forandring i de følgende:- COP;- rute;- andre flyveplansdata (data i ICAO felt 8, 10 og 18).NOTEOperationelle regler kan kræve, at modifikationer, som udføres efter ACT, kan være på betingelse af forudgående koordinering mellem de berørte enheder.7.3.3.1.5. Når det er aftalt bilateralt, skal meddelelseshenvisningen indbefattes i REV-meddelelsen.7.3.3.1.6. Meddelelseshenvisningen skal, når den er indbefattet, indeholde den tidligere ACT-meddelelses meddelelsesnummer.7.3.3.1.7. Den modtagende ATC-enheds accept af de overførselsbetingelser, der medføres af REV-meddelelsen, skal formodes, medmindre den modtagende ATC-enhed initierer koordinering for at rette i dem.7.3.3.2. Formatering af Revideringsmeddelelser7.3.3.2.1. ICAO-FormatAlle revideringsmeddelelser omfatter felttyper 3, 7, 13, 14 og 16. De følgende typer af revidering indbefattes i disse felter:- en ændring af ETOet ved COPet eller overførselsniveauet/overførselsniveauerne skal indarbejdes i indbefatningen af de reviderede data i felt 14;- en ændring af SSR-Koden skal være indbefattet i felt 7;- ruteændringer, som omfatter ændringer af COPet, skal være indarbejdet i data i felterne 14 og 15 indbefattet i felt 22's format efter de første fem indledende felter. Sådanne meddelelser skal indeholde to felter 14, hvor det første indeholder et element a) kun det COP, som flyvningen tidligere er blevet koordineret igennem. Regler for koordineringen af sådanne ændringer, heri indbefattet direkte styringer, er specificeret i Anneks B Specielle Rutebehandlingskrav;- modifikationer af felterne 8, 10 og 18 skal være indarbejdet som data i felt 22 efter de fem indledende felter.7.3.3.2.2. ADEXP-FormatAlle revideringsmeddelelser i ADEXP-format skal indbefatte de følgende primære felter: TITLE REFDATA ARCID ADEP ADES. De følgende regler gælder:- en ændring af ETOet ved COPet eller overførselsniveauet/overførselsniveauerne skal indarbejdes i indbefatningen af de reviderede data i det primære felt COORDATA;- ruteændringer, heriblandt ændringer af COPet, skal være indarbejdet i de primære felter COORDATA og ROUTE. Sådanne meddelelser skal omfatte det primære felt COP, der indeholder det Koordineringspunkt, som flyvningen tidligere er blevet koordineret igennem. Regler for koordineringen af sådanne ændringer, heri indbefattet direkte styringer, er specificeret i Anneks B;- en ændring af SSR-Koden skal være angivet ved indbefatningen af det primære felt SSRCODE;- modifikationer til andre flyveplansdata skal være indarbejdet af indbefatningen af de(t) fornødne primære felt(er) som defineret for Andre Flyveplansdata i Anneks A.Hvis der sendes en revideringsmeddelelse til kun at koordinere SSR-Kode og/eller Andre Flyveplansdata, skal det primære felt COP være indbefattet i stedet for COORDATA.7.3.3.2.3. SSR-KodeSSR-Tilstand og -Kode skal kun være indbefattet i en REV-meddelelse, når det er påkrævet at koordinere en ændring af SSR-kode.7.3.3.3. Behandling i den Modtagende Enhed7.3.3.3.1. Hvis der modtages en ACT for den pågældende flyvning fra den samme ATC-enhed, skal det ATC-system, som modtager en PAC-meddelelse, forsøge at opnå forbindelse med den tilsvarende flyveplan.7.3.3.3.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen er nogen uoverensstemmelse til stede, som ville forhindre korrekt behandling:- skal det operationelle indhold være indbefattet af flyveplanen;- skal de påkrævede data udsendes ved operationel ATC og andre positioner som behørigt.7.3.3.4. Initiering af Transmission7.3.3.4.1. REV-meddelelsen er hændelsesdrevet og skal transmitteres øjeblikkeligt efter den relevante indføring eller opdatering.7.3.3.4.2. Der kan ikke udføres nogen ændringer ved brugen af REV-meddelelsen, efter at flyvningen er ved et specificeret tidspunkt/en specificeret afstand fra overførselspunktet. Tids- og afstandsparametrene skal være aftalt bilateralt.7.3.3.4.3. AnbefalingREV-parametrene bør være defineret særskilt for hvert af COPene.7.3.3.5. Ændring af Modtagende ATC-EnhedREV-meddelelsen skal ikke bruges, hvis en revidering af flyveplansdata fører til en ændring af den modtagende ATC-Enhed (se Meddelelse for Ophævelsen af Koordinering).7.3.4. Kvittering for REV7.3.4.1. KvitteringHvis REV-meddelelsen:- kan forbindes med en flyveplan i det modtagende system, skal der transmitteres en LAM-meddelelse som kvittering;- ikke kan forbindes med en flyveplan i det modtagende system, skal der ikke transmitteres en LAM-meddelelse.7.3.4.2. Ingen Kvittering7.3.4.2.1. Hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en REV-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen af flyvninger.7.3.4.2.2. I tilfælde af ingen LAM skal en verbal koordinering initieres af den overførende ATC-enhed.7.3.5. Eksempler7.3.5.1. ICAOa. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)7.3.5.2. ADEXPa. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBBb. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A23177.4. Meddelelse for Ophævelsen af Koordinering (MAC)7.4.1. Formål med MAC-MeddelelsenEn MAC-meddelelse bruges til at angive over for den modtagende enhed, at den koordinering eller underretning, som tidligere blev udført for en flyvning, er blevet ophævet.MACen er ikke en erstatning for en Annuleringsmeddelelse (CNL), som denne er defineret af ICAO, og skal derfor ikke bruges til at slette de grundlæggende flyveplansdata.7.4.2. Indhold af MeddelelseMAC-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning (frivilligt);- Luftfartøjsidentifikation;- Afgangsflyveplads;- Koordineringspunkt;- Bestemmelsesflyveplads;- Koordineringsstatus og -Årsag (frivilligt);NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.7.4.3. Regler for Anvendelse7.4.3.1. Generelt7.4.3.1.1. Der skal sendes en MAC-meddelelse til en enhed, som koordinering tidligere er blevet udført til for en flyvning, ved brugen af en ACT- eller RAP-meddelelse, når ét af følgende forekommer:- det forventede niveau ved overførselspunktet er forskelligt fra det niveau, der er indeholdt i den tidligere meddelelse, hvilket resulterer i en ændring af den næste enhed i koordineringssekvensen;- flyvningens rute er blevet forandret, hvilket resulterer i ændring af den næste enhed i koordineringssekvensen;- systemflyveplanen er annulleret i den sendende enhed og koordinering er ikke længere relevant;- der modtages en MAC fra den tidligere enhed i forhold til flyvningen.7.4.3.1.2. Når der sendes en MAC-meddelelse på grund af en ændring i flyveniveau eller flyverute, skal underretning og/eller koordinering, alt efter hvad der er behørigt, udføres med den nye enhed i koordineringssekvensen.7.4.3.1.3. Der skal sendes en MAC-meddelelse, når koordineringen for en afgående flyvning, udført ved brugen af en PAC-meddelelse, ophæves.7.4.3.1.4. AnbefalingDer bør sendes en MAC-meddelelse, når den underretning (ABI-meddelelse), som tidligere blev udført for en flyvning, annulleres på grund af en hvilken som helst af de grunde, der er specificeret i Afsnit 7.4.3.1.1 ovenfor eller hvis flyvningen forsinkes en-route og der ikke kan bestemmes et revideret estimat automatisk.7.4.3.1.5. En meddelelseshenvisning skal være indbefattet, hvis det er aftalt bilateralt.7.4.3.1.6. Hvis den er indbefattet, skal meddelelseshenvisningen indeholde meddelelsesnummeret for den sidste ABI-, PAC- eller ACT-meddelelse , som er transmitteret til flyvningen og som der er kvitteret for.7.4.3.1.7. Koordineringspunktet skal være det COP, som flyvningen tidligere er blevet underrettet eller koordineret gennem.7.4.3.1.8. AnbefalingMAC-meddelelsen bør identificere den status, som koordineringen eller underretningen skal vende tilbage til, og årsagen til ophævelsen.7.4.3.1.9. Hvis det er indbefattet, skal statusen og årsagen være én af de følgende kombinationer:- når den modtagende enhed ikke længere er den næste koordineringspartner:- er statusen INI (indledende);- er årsagen én af de følgende:- TFL, hvis årsagen er en ændring af overførselsniveau;- RTE, hvis årsagen er en ændring af rute;- CSN, hvis årsagen er en ændring af kaldesignalet;- CAN, hvis årsagen er en annullering;- OTH for en hvilken som helst anden årsag eller hvis årsagen er ukendt;- når én af de følgende betingelser gælder:- koordineringen udført ved anvendelse af den tidligere PAC- eller ACT-meddelelse (som modificeret ved en hvilken som helst efterfølgende REV-meddelelse) ophæves, men flyvningen forventes at blive omfattet af en ny koordineringssekvens med den samme enhed;eller- flyvningen efterfølgende transmissionen af en ABI-meddelelse er i holding i en ubestemt periode og forventes at blive omfattet af en revideret ABI eller ACT, alt efter hvad der er behørigt:- er statusen NTF (underretning);- er årsagen én af de følgende:- DLY, hvis årsagen er en forsinkelse;- HLD, hvis årsagen er en holding;- OTH for en hvilken som helst anden årsag eller hvis årsagen er ukendt.7.4.3.1.10. Hvis flyvningen skal gen-underrettes eller gen-koordineres:- skal en ny underretnings- og/eller koordineringsmeddelelse sendes, alt efter hvad der er behørigt;- skal de grundlæggende flyveplandata, der er lagret i den modtagende ATC-enhed, ikke påvirkes af en MAC-meddelelse;- skal systemet bevare evnen til korrekt at behandle en ny underretnings- og/eller koordineringsmeddelelse fra enten den tidligere overførende enhed eller en anden enhed i en ny koordineringssekvens.7.4.3.2. Behandling i den Modtagende EnhedDe(n) arbejdsposition(er) i den modtagende ATC-enhed, som er forsynet med flyvedetaljer, skal underrettes om ophævelsen.7.4.4. Kvittering for MAC7.4.4.1. Kvittering7.4.4.1.1. Hvis MAC-meddelelsen kan forbindes med en flyveplan i det modtagende system og kan behandles, skal en LAM-meddelelse transmitteres som kvittering.7.4.4.1.2. Hvis MAC-meddelelsen ikke kan forbindes med en flyveplan i det modtagende system eller hvis den ikke kan behandles, skal der ikke transmitteres en LAM-meddelelse.7.4.4.2. Ingen Kvittering7.4.4.2.1. Hvis ATC-koordinering ophæves og der ikke er modtaget nogen LAM-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen.7.4.4.2.2. I sådanne tilfælde skal en verbal ophævelse af koordinering udføres af den overførende ATC-enhed.7.4.5. EksemplerEn ABI-meddelelse blev sendt af Amsterdam ACC til Bruxelles ACC for flyvning HOZ3188, planlagt til FL190; flyvningen anmoder efterfølgende om at stige til FL270 og klarerers til dette og går således ind i Maastrichts luftrum i stedet for Bruxelles'. Eksempler 7.4.5.1 a og 7.4.5.2 a viser, hvordan MACen, der sendes til Bruxelles af Amsterdam, ville forekomme, både i ICAO- og i ADEXP-format.En ABI- og senere en ACT-meddelelse sendes til Maastricht, men enkelte minutter før luftfartøjet når COPet, returnerer det til Amsterdams Lufthavn og flyveplanen annulleres i den sendende enheds system; der sendes MAC til Maastricht som vist i eksempler (7.4.5.1 b og 7.4.5.2 b).7.4.5.1. ICAOa. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL)b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN)7.4.5.2. ADEXPa. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFLb. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN7.5. SSR Kodetildelingsmeddelelse (COD)7.5.1. Formål med COD-Meddelelsen7.5.1.1. Metoden til Kodetildeling for Oprindeligt Område (ORCAM) er frembragt til at tillade en flyvning at respondere på den samme kode til efterfølgende enheder inden for et deltagende område. Medmindre kodetildeling udføres centralt, f.eks. af en ACC, kan lufthavne have behov for at have et sæt diskrete SSR-koder tildelt individuelt. Sådanne tildelinger er meget uøkonomiske med koder.7.5.1.2. COD-meddelelsen opfylder de operationelle krav til udstedelsen af en SSR-Kode, Tilstand A, af én Lufttrafiktjenesteenhed til en anden for en specificeret flyvning, når der anmodes derom. En valgfri facilitet tillader den udstedende enhed at indbefatte flyvningen rute, hvis det er aftalt bilateralt.7.5.2. Indhold af MeddelelseCOD -meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning (frivilligt);- Luftfartøjsidentifikation;- SSR-Tilstand og -Kode;- Afgangsflyveplads;- Bestemmelsesflyveplads;- Rute (frivilligt);NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.7.5.3. Regler for Anvendelse7.5.3.1. Generelt7.5.3.1.1. Der skal automatisk genereres og transmitteres en COD-meddelelse som reaktion på en kodetildelingsanmodning, der er modtaget i en meddelelse.7.5.3.1.2. SSR-koden skal være den kode, der tildeles til flyvningen.7.5.3.1.3. Den anerkendte mætningskode, som angivet i Luftnavigeringsplanen for den Europæiske Region, skal indsættes, hvis en diskret kode ikke er tilgængelig.7.5.3.1.4. Hvis det er aftalt bilateralt, skal meddelelseshenvisningen, som indeholder meddelelsesnummeret for den meddelelse, som COD-meddelelsen reagerer på, indbefattes.7.5.3.1.5. Ruten skal indbefattes, hvis det er aftalt bilateralt.7.5.3.1.6. Der skal formodes accept af SSR-kode af den enhed, der modtager COD-meddelelsen.7.5.3.2. Behandling i den Modtagende Enhed7.5.3.2.1. Forudsat, at der ikke er nogen uoverensstemmelse i meddelelsen, som ville forhindre korrekt behandling, skal en LAM returneres.7.5.3.2.2. Hvis meddelelsen ikke kan forbindes med en flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen, skal der ikke returneres nogen LAM.7.5.3.2.3. Rutedata skal, hvis de er indbefattet, ikke være årsag til at forhindre returneringen af en LAM, medmindre de fejler med hensyn til at overholde formatkravet som fremsat i Anneks A.7.5.3.3. Tidsparametre for TransmissionEn transmissionstidsparameter skal ikke være anvendelig, idet COD-meddelelsen sendes som et resultat af modtagelsen af en meddelelse, der anmoder om tildelingen af en SSR-kode.7.5.4. Kvittering for COD7.5.4.1. KvitteringDer skal kvitteres for COD-meddelelsen ved at generere og transmittere en LAM-meddelelse.7.5.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en COD-meddelelse, skal en advarsel vises ved en passende position.7.5.5. Eksempler7.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 A07677.6. Informationsmeddelelse (INF)7.6.1. Formål med INF-Meddelelsen7.6.1.1. INF-meddelelsen bruges til at frembringe information med hensyn til specifikke flyvninger til agenturer, som ikke er direkte involverede i koordineringsprocessen mellem to på hinanden følgende ATC-enheder på en flyvnings rute.7.6.1.2. INF-meddelelsen kan bruges til at frembringe kopier af meddelelser og til at kommunikere aftalte koordineringsbetingelser til sådanne agenturer efter en dialog mellem flyveledere. Til dette formål kan INF-meddelelser genereres af systemerne i den overførende eller den accepterende enhed.7.6.1.3. Meddelelsen kan også bruges til at frembringe information i forhold til et hvilket som helst punkt på en flyvnings rute til et agentur.7.6.1.4. Formatet muliggør kommunikationen af indledende data, revideringer og annulleringer.7.6.2. Indhold af MeddelelseINF-meddelelsen skal indeholde de følgende dataemner i formatet for en meddelelse beskrevet i dette dokument:- Meddelelsestype;- Meddelelsesnummer;- Alle emner af operationelle data som indbefattet i den originale meddelelse eller resulterende koordinering, der kopieres;- Henvisningsmeddelelsestype (frivilligt);NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.7.6.3. Regler for Anvendelse7.6.3.1. MeddelelsestyperTypen/typerne af meddelelse(r), der skal duplikeres ved en INF-meddelelse, vil være baseret på brugeres krav og egenskaberne for den sendende enhed. Typen/typerne af meddelelse(r) og reglerne for anvendelse vil almindeligvis være aftalt bilateralt.7.6.3.2. MeddelelsesadressaterDer kan transmitteres én eller flere INF-meddelelser for den samme flyvning til én eller flere adressater.7.6.3.3. Operationelt IndholdDet operationelle indhold i INF-meddelelsen skal være i formatet for én af de eksisterende meddelelser.7.6.3.4. Anbefalinger1. Betingelser, der er videresendt i en indledende dialogmeddelelse (f.eks. ACT-, RAP-, REV-, RRV-meddelelse) kan ændres eller afvises, før dialogen er færdiggjort. Sendende enheder bør være i stand til at videresende de endelige aftalte koordineringsbetingelser.2. INF-meddelelsen bør sendes øjeblikkeligt eller til et tidspunkt i forhold til tidspunktet ved COPet, som er aftalt bilateralt med det modtagende agentur.7.6.4. Kvittering for INFAnbefalinger1. Der kan kvitteres for INF-meddelelsen afhængigt af koordineringspartneren ved at generere og transmittere en LAM-meddelelse.2. fhængigt af en bilateral aftale bør der mellem vedrørte enheder vises en advarsel ved en passende position, hvis der ikke modtages nogen LAM-meddelelse som en kvittering for en INF-meddelelse.7.6.5. EksemplerEn flyvning med kaldesignal BAW011, B747 fra EGLL til OMDB ved FL290, anmoder om FL410, forventer Koksy (KOK) VOR kl. 1905, har transpondervisning på A5437, fortsætter via UG1 og UB6.Der sendes en ACT-meddelelse af London til Maastricht for flyvningen. En kopi sendes fra London til en enhed, der identificeres som IT.Det følgende giver eksempler på INF-meddelelsen.7.6.5.1. ICAO(INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/MSG/ACT)7.6.5.2. ADEXP-TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK NTM UB6 KRH -MSGTYP ACT8. DIALOGPROCEDURE - KOORDINERING8.1. Generelt8.1.1. Introduktion8.1.1.1. Dialogproceduren frembringer faciliteter til kommunikation og forhandling mellem flyveledere i koordineringsfasen og til kommunikation i overførselsfasen.8.1.1.2. Dette afsnit beskriver meddelelser, der anvendes i dialogproceduren i koordineringsfasen, hvor betingelserne for overførsel planlægges. De, der gælder for overførselsfasen, hvor flyvningens overdragelse gennemføres, er beskrevet i Afsnit 9 - Dialogprocedure - Overførsel af Kommunikation.8.1.1.3. Procedurer for de to faser er ikke afhængige af hinanden; de kan implementeres enkeltvis eller sammen.8.1.1.4. Et antal yderligere meddelelser indføres og begge partneres evne til at initiere en dialog understøttes.8.1.1.5. Koordineringsdialogproceduren tillader identifikation af:- overførsler, som er i overensstemmelse med LoAet og som kan accepteres automatisk; og- de, som kræver at blive henvist til flyvelederen ved den modtagende enhed for en beslutning vedrørende accept.8.1.1.6. Denne procedure tillader også, at der kan føres opsyn med fortolkningen af LoAene i de to systemer og at en hvilken som helst uoverensstemmelse mellem dem kan identificeres.8.1.2. Filteret8.1.2.1. Generelt8.1.2.1.1. Koordineringsdialogproceduren kræver, at systemer identificerer, hvorvidt overførsler er i overensstemmelse med LoAet eller ej.8.1.2.1.2. Den proces, som kontrollerer en sådan overensstemmelse, betegnes i dette dokument "filteret". Den database, som bruges til filteret, vil, hvis det er påkrævet, indbefatte de følgende:- aftalte koordineringspunkter;- berettigede (eller uberettigede) flyveniveauer, hvilket også kan være forbundet med koordineringspunkterne;- afgangsflyvepladser;- destinationer;- aftalte, direkte ruter;- tids- og/eller distancegrænser forud for COPet, efter hvilke en hvilken som helst koordineringsmeddelelse betragtes som ikke-standard;- vilkårlige andre betingelser, som er aftalt bilateralt.8.1.2.1.3. Alle emner i denne liste kan kombineres til at definere mere komplekse betingelser.8.1.2.1.4. I dette dokuments Afsnit 8 skal udtrykket "standardbetingelser" fortolkes som "i overensstemmelse med LoAet" og udtrykket "ikke-standardbetingelser" som "ikke i overensstemmelse med LoAet". Medmindre det er aftalt bilateralt, skal meddelelser, der sendes af overførende enheder for koordineringer, som er kendt som værende standard, anvende andre meddelelsestyper end de, for hvilke betingelserne er ikke-standard.8.1.2.2. Handling I den Overførende Enhed8.1.2.2.1. Filteret i den overførende enhed skal gennemgå de overførselsbetingelser, som skal til at blive sendt til den accepterende enhed.8.1.2.2.2. AnbefalingHvis overførselsbetingelserne viser sig at være ikke-standard, skal den overførende flyveleders opmærksomhed henledes til dette faktum for bekræftelse eller modifikation.8.1.2.3. Handling i den Accepterende Enhed8.1.2.3.1. Alle ACT- og REV-meddelelser skal kontrolleres i forhold til filteret.8.1.2.3.2. Hvis kontrollen angiver, at de modtagede overførselsbetingelser er ikke-standard, skal de henvises til flyvelederen for en beslutning, i modsat fald vil de blive accepteret automatisk.8.1.2.4. Synkronisering af Filtrene8.1.2.4.1. Brugen af forskellige meddelelser for standard- og ikke-standardoverførselsbetingelser muliggør identifikationen af en hvilken som helst uoverensstemmelse mellem standardbetingelser, som de holdes i systemerne ved den overførende og den accepterende enhed.8.1.2.4.2. Identifikationen i den accepterende enhed af ikke-standardoverførselsbetingelser i en meddelelse, der kun bruges til at koordinere standardoverførsler, vil betyde en uoverensstemmelse mellem de to filtre. Sådanne uoverensstemmelser bør afgøres for dialogprocedurens effektive funktion.8.1.3. Meddelelsessekvens8.1.3.1. Generelt8.1.3.1.1. Det er påkrævet, at der følges bestemte regler for at sikre, at koordinering er fuldstændig, før der finder nogen revidering eller overførsel af kommunikationsmeddelelsesudveksling sted og også for at sikre, at flyveledere ved begge enheder ikke samtidigt kommer med forslag med hensyn til den samme flyvning.8.1.3.1.2. En ATC-enhed skal kun transmittere eller kvittere for modtagelse af en Revideringsmeddelelse (REV eller RRV) for en flyvning, når den er i den koordinerede tilstand, dvs. en ACT- eller RAP-dialog er blevet fuldført ved en LAM eller ACP.8.1.3.1.3. CDN-meddelelser skal kun være berettigede for transmission ved den accepterende enhed.8.1.3.1.4. CDN-meddelelser skal kun transmitteres og kvitteres:- som del af en dialog, der er initieret ved modtagelsen af en Aktiverings- (ACT, RAP) eller en Revideringsmeddelelse (REV eller RRV); eller- når flyveplanen for den pågældende flyvning er i den koordinerede tilstand.8.1.4. Samtidig Håndtering af Meddelelser8.1.4.1. Generelt8.1.4.1.1. En enhed, der er involveret i en udveksling af en koordinerings- eller en overførselsmeddelelse for en flyvning, skal ikke initiere en yderligere udveksling af en koordinerings- eller overførselsmeddelelse for den samme flyvning med den samme enhed, før der er modtaget enten en LAM, en ACP eller en RJC eller hvis der nås en timeout.8.1.4.1.2. Det er muligt for en CDN-meddelelse at krydse en REV-, en RRV- eller en MAC-meddelelse for den samme flyvning sendt fra den overførende enhed. Denne situation kan identificeres i den overførende enhed ved, at CDNen ankommer før kvitteringen for den transmitterede koordineringsmeddelelse og i den accepterende enhed ved, at meddelelsen fra den overførende enhed ankommer før kvitteringen for CDNen. I dette tilfælde skal der ikke kvitteres for CDNen og REVen, RRVen eller MACen skal behandles.8.1.5. Håndtering af AfvisningRJC-meddelelsen afslutter en systemdialog. Der skal initieres en ny systemkoordinering, som afspejler telefonkoordineringen, hvor det er anvendeligt.8.1.6. Operationelt Timeout for Besvarelser8.1.6.1. Generelt8.1.6.1.1. Der skal anvendes en timeout-mekanisme ved sende- og modtagecentrene for besvarelsen til meddelelser, der henvises til flyvelederen.8.1.6.1.2. Varigheden af disse timeouts skal være aftalt bilateralt.8.1.6.1.3. Udløbet af timeout'et ved den overførende enhed skal resultere i, at der udsendes en advarsel til den overførende flyveleder for at angive behovet for at initiere en telefonkoordinering.8.1.6.1.4. Anbefalinger1. En advarsel bør vises til den ATC-position i den accepterende enhed, som er ansvarlig for flyvningen, når timeout'et i den overførende enhed er forestående.2. Advarslen bør tage hensyn til besvarelsens transmissionstid.8.1.6.1.5. Systemer skal være i stand til at behandle besvarelser, der modtages efter udløbet af timeout'et.8.1.7. Implementering8.1.7.1. Dialogprocedurerne henvender sig til to faser, nemlig koordineringsfasen og overførselsfasen. Dialogen i de to faser bruger forskellige meddelelser og de påkrævede transaktionstider er forskellige. Koordineringsmeddelelserne er specificeret i ICAO- og ADEXP-formater og meddelelserne for overførslen af kommunikation kun i ADEXP.8.1.7.2. De minimale HMI-krav for koordineringsdialogen er forskellige fra de tilsvarende krav for overførselsdialogen:- Overførselsdialogen henvender sig primært til den udøvende kontrolfunktion og kræver en hurtig og brugervenlig HMI;- koordineringsdialogen er ikke lige så tidskritisk og derfor er dens HMI-krav af mindre betydning.8.1.7.3. Dialogproceduren skal implementeres ved at anvende ét af følgende, alternative forløb:- koordineringsfasedialogprocedure plus en hvilken som helst ekstra meddelelse, som aftalt bilateralt (Afsnit 7 og 8);- grundlæggende koordineringsprocedure og overførselsfasedialogprocedure (Afsnit 6, 7 og 9);- koordinerings- og overførselsfasedialogprocedure plus en hvilken som helst ekstra koordineringsmeddelelse, som aftalt bilateralt (Afsnit 7, 8 og 9).Den Forudgående Grænseinformationsmeddelelse skal sendes i alle forløb.8.1.7.4. Det forløb, der anvendes til implementeringen, skal være aftalt bilateralt.8.2. Aktiveringsmeddelelse (ACT)8.2.1. Formål med ACT-MeddelelsenFormålet med ACT-Meddelelsen er beskrevet i afsnit 6.3.1. I en dialogprocedure bruges ACT-meddelelsen til at opfylde disse krav forudsat, at overførselsbetingelserne for flyvningen er standardbetingelser og at den overførende flyveleder ikke kræver at henvise flyvningen til den accepterende flyveleder for accept.8.2.2. Indhold af MeddelelseIndholdet af den ACT-meddelelse, der bruges i dialogproceduren, skal være som beskrevet for ACT-meddelelsen i afsnit 6.3.2.8.2.3. Regler for Anvendelse8.2.3.1. Generelt8.2.3.1.1. Reglerne for anvendelse er som beskrevet for ACTen i afsnit 6.3 med undtagelse af de specielle regler, der er beskrevet i dette afsnit.8.2.3.1.2. Der skal sendes en ACT-meddelelse for en flyvning med standardoverførselsbetingelser, hvis den overførende flyveleder ikke kræver, at flyvningen skal henvises til den accepterende flyveleder.NOTEHvis disse krav ikke gælder sendes en RAP (se afsnit 8.3 3 Meddelelse om Henvist Aktiveringsforslag).8.2.3.1.3. AnbefalingDer bør initieres en ny koordineringsprocedure, hvis der returneres en Meddelelse om Afvisning af Koordinering (RJC) som reaktion på en ACT-meddelelse.8.2.3.2. Behandling i den Modtagende Enhed8.2.3.2.1. Meddelelsen kontrolleres i forhold til filteret for at bekræfte, at de foreslåede betingelse er standard.8.2.3.2.2. Meddelelsen skal behandles som en RAP-meddelelse, hvis:- overførselsbetingelserne viser sig at være ikke-standard;- der ikke kan findes en tilsvarende systemflyveplan og der er tilstrækkelig information tilgængelig til at identificere, hvorvidt overførselsbetingelserne er standard eller ej.8.2.3.2.3. ACT-meddelelser, der viser sig at være standard, skal behandles i overensstemmelse med afsnit 6.3.3.2.8.2.3.2.4. AnbefalingHvis overførselsbetingelserne i en ACT-meddelelse viser sig at være ikke-standard, er der en uoverensstemmelse mellem filtrene i de to systemer. Overvågningsmandskabets opmærksomhed bør henledes på det faktum, at ACTen er ikke-standard, for at uoverensstemmelsen kan løses.8.2.4. Kvittering for ACT8.2.4.1. Kvittering8.2.4.1.1. I en dialogprocedure skal en ACT-meddelelse kvitteres ved:- en LAM, hvis overførselsbetingelserne viser sig at være standard;- en SBY-meddelelse i alle andre tilfælde.8.2.4.1.2. Når der er modtaget en LAM, skal det operationelle indhold af ACT-meddelelsen blive operationelt bindende for begge ATC-enheder.8.2.4.1.3. Hvor det er aftalt bilateralt, kan der bruges en ACP i stedet for en LAM til at angive accepten af en ACT, der indeholder standardoverførselsbetingelser ved den accepterende enhed.8.2.4.2. Tilfælde af Ingen KvitteringHvis der ikke er modtaget nogen kvittering for en ACT-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.8.3. Meddelelse om Henvist Aktiveringsforslag (RAP)8.3.1. Formål med RAP-MeddelelsenRAP-meddelelsen opfylder de følgende, operationelle krav ud over de, der er specificeret for ACT-meddelelsen i afsnit 6.3:- forslaget ved den overførende flyveleder og henvisningen til den accepterende flyveleder af flyvninger med ikke-standard overførselsbetingelser;- at tillade flyvelederen, hvis han/hun ønsker at gøre dette, at tvinge henvisningen til den accepterende flyveleder af standard overførselsbetingelser for en specifik flyvning.8.3.2. Indhold af MeddelelseIndholdet i RAP-meddelelsen skal være de samme data som beskrevet for ACT-meddelelsen (afsnit 6.3) og kan frivilligt indbefatte det følgende dataelement:- årsag, angivende manuel henvisning (kun tilgængelig i ADEXP).8.3.3. Regler for Anvendelse8.3.3.1. Generelt8.3.3.1.1. Der skal sendes en RAP-meddelelse i stedet for ACT-meddelelsen for flyvninger, der krydser grænsen og som opfylder én af de følgende betingelser:- det overførende system har bestemt overførselsbetingelserne som værende ikke-standard;- den overførende flyveleder har angivet, at de foreslåede overførselsbetingelser skal henvises til den accepterende flyveleder.8.3.3.1.2. Det operationelle indhold i RAP-meddelelsen, der skal til at blive transmitteret, skal vises ved den arbejdsposition, der er ansvarlig for koordineringen af flyvningen forud for den aktuelle transmission.8.3.3.1.3. AnbefalingDet tidspunkt, hvor RAP-meddelelsen transmitteres automatisk, bør vises sammen med dens indhold.8.3.3.1.4. Den relevante arbejdsposition skal underrettes om transmissionen af RAP-meddelelsen.8.3.3.2. Behandling i den Modtagende Enhed8.3.3.2.1. Det ATC-system, som modtager en RAP-meddelelse, skal forsøge forbindelse med den tilsvarende flyveplan.8.3.3.2.2. Hvis der findes en tilsvarende flyveplan og der ikke er nogen uoverensstemmelse til stede i meddelelsen, som ville forhindre korrekt behandling:- skal det operationelle indhold henvises til den accepterende flyveleder;- skal en SBY returneres.8.3.3.2.3. AnbefalingEn angivelse af årsagen til henvisningen (ikke-standard betingelser eller manuel henvisning) bør være indeholdt.8.3.3.2.4. Hvis meddelelsen ikke kan forbindes med en flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen, da:- skal det operationelle indhold af meddelelsen vises ved sektoren;og- en SBY-meddelelse skal returneres;og- en flyveplan skal dannes.8.3.3.2.5. I alle andre tilfælde skal der ikke kvitteres for meddelelsen.8.3.3.3. Manuel Igangsættelse8.3.3.3.1. RAPen vil, når den bruges til at tvinge henvisningen af en foreslået koordinering med standardoverførselsbetingelser til den accepterende flyveleder, initieres manuelt af den overførende flyveleder og transmitteres øjeblikkeligt.8.3.3.3.2. AnbefalingManuel igangsættelse af en RAP-meddelelse før den beregnede transmissionstid bør være tilladt ved den position, der er ansvarlig for flyvningens koordinering.8.3.3.4. Tidsparametre for Automatisk TransmissionTiden/distancen før den grænse, hvor RAP-meddelelser automatisk transmitteres, skal være den samme som for ACT-meddelelserne.8.3.4. Kvittering for RAP8.3.4.1. KvitteringDer skal kvitteres for meddelelsen ved genereringen og transmissionen af en SBY-meddelelse.8.3.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen SBY-meddelelse som en kvittering for en RAP-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.8.3.5. Operationel Besvarelse af RAPDen accepterende flyveleder kan enten acceptere, stille et mod-forslag om eller afvise overførselsbetingelser.8.3.5.1. Accept8.3.5.1.1. Når den accepterende flyveleder vælger at acceptere de foreslåede overførselsbetingelser, skal en ACP-meddelelse returneres.8.3.5.1.2. Så snart som ACP-meddelelse er blevet modtaget, bliver RAP-meddelelsesdataene operationelt bindende for begge ATC-enhederne. De koordinerede overførselsbetingelser og det faktum, at ACP er blevet modtaget, skal forelægges for den overførende flyveleder.8.3.5.2. Mod-ForslagNår den accepterende flyveleder vælger at stille et mod-forslag om overførselsbetingelserne, skal der returneres en CDN-meddelelse.8.3.5.3. AnbefalingNår den accepterende flyveleder vælger at afvise de foreslåede overførselsbetingelser, bør der returneres en RJC-meddelelse. En ny koordineringsproces bør da initieres.NOTEMed hensyn til anbefalingen i 8.3.5.3, vil den nye koordinering i de fleste tilfælde være med en anden enhed.8.3.6. Eksempler8.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 B7578.4. Revideringsmeddelelse (REV)8.4.1. Formål med REV-MeddelelsenFormålet med REV-meddelelsen er beskrevet i afsnit 7.3.1. I en dialogprocedure bruges REV-meddelelsen til at opfylde disse krav, under forudsætning af at overførselsbetingelserne for flyvningen er standard og at den overførende flyveleder ikke kræver at henvise flyvningen til den accepterende flyveleder for accept.8.4.2. Indhold af MeddelelseIndholdet af REV-meddelelsen skal være som beskrevet for REV-meddelelsen i afsnit 7.3.2.8.4.3. Regler for Anvendelse8.4.3.1. Generelt8.4.3.1.1. Der kan sendes én eller flere REV-meddelelser til den enhed, som en flyvning for øjeblikket er blevet koordineret til ved brug af en Aktiverings- eller RAP-meddelelse.8.4.3.1.2. REV-meddelelser skal sendes under de betingelser, som er specificeret i afsnit 7.3.3.1 for flyvninger med standard overførselsbetingelser, hvilke flyvninger den overførende flyveleder ikke kræver bliver henvist til den accepterende flyveleder.8.4.3.2. Initiering af TransmissionREV-meddelelsen skal transmitteres straks efter en detektering af en ændring i de koordineringsdata, der påkrævet skal koordineres som beskrevet i afsnit 7.3.3.8.4.3.3. Behandling i den Modtagende Enhed8.4.3.3.1. Hvis der findes en tilsvarende flyveplan i den koordinerede tilstand og der ikke findes nogen uoverensstemmelse, som ville forhindre korrekt behandling af meddelelsen, da:- skal der kvitteres for REV-meddelelsen;- i alle andre tilfælde skal der ikke kvitteres for meddelelsen.8.4.3.3.2. Overførselsbetingelserne skal undersøges for at sikre, at de er standard.8.4.3.3.3. Hvis overførselsbetingelserne ikke er standard, skal de forelægges for den accepterende flyveleder.8.4.3.3.4. Hvis det viser sig, at de foreslåede overførselsbetingelser er standard, skal de indbefattes i flyveplanen og de påkrævede data skal udsendes ved operationel ATC og andre positioner, som det er passende.8.4.3.3.5. AnbefalingHvis overførselsbetingelserne i en REV-meddelelse viser sig at være ikke-standard, er der en uoverensstemmelse mellem filtrene i de to systemer. Overvågningsmandskabets opmærksomhed bør henledes på det faktum, at REVen er ikke-standard, for at uoverensstemmelsen kan løses.8.4.4. Kvittering for REV8.4.4.1. Kvittering8.4.4.1.1. Hvis der skal kvitteres for en REV-meddelelse, skal den kvitteres ved:- en LAM-meddelelse, hvis overførselsbetingelserne har vist sig at være standard;- en SBY-meddelelse, hvis overførselsbetingelserne har vist sig at være ikke-standard.8.4.4.1.2. Når der er modtaget en LAM, bliver det operationelle indhold af REV-meddelelsen operationelt bindende til begge ATC-enhederne.8.4.4.1.3. Hvor det er aftalt bilateralt, kan en ACP anvendes i stedet for en LAM for at angive accepten ved den accepterende enhed af en REV, som indeholder standardoverførselsbetingelser.8.4.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen kvittering for en REV-meddelelse, skal en advarsel vises ved den ATC-position, som er ansvarlig for koordineringen af flyvningerne.8.4.5. Operationel Besvarelse af REVIdet REV-meddelelsen bruges til at sende standard overførselsbetingelser vil den almindeligvis blive accepteret af systemet i den accepterende enhed. Hvis filteret i den accepterende enhed finder, at overførselsbetingelserne er ikke-standard, skal meddelelsen behandles som en RRV-meddelelse.8.5. Meddelelse om Forslag om Henvist Revidering (RRV)8.5.1. Formål med RRV-MeddelelsenRRV-meddelelsen skal sørge for revideringen af tidligere sendte og aftalte betingelser i de følgende tilfælde:- når de foreslåede overførselsbetingelser i revideringen er ikke-standard;- når den foreslåede revidering er standard, men den overførende flyveleder ønsker at henvise revideringen til den accepterende flyveleder.8.5.2. Indhold af MeddelelseIndholdet af RRV-meddelelsen skal være som beskrevet for REV-meddelelsen (afsnit 7.3.2) og kan frivilligt indbefatte det følgende dataelement:- årsag, angivende manuel henvisning (kun tilgængelig i ADEXP).8.5.3. Regler for Anvendelse8.5.3.1. GenereltDer skal sendes én eller flere RRV-meddelelser i stedet for REV-meddelelser for hver revidering, hvis enten:- det overførende system har bestemt overførselsbetingelserne som værende ikke-standard;eller- den overførende flyveleder har angivet, at de foreslåede overførselsbetingelser skal henvises til den accepterende flyveleder. Denne anvendelse af RRVen er valgfri.8.5.3.2. Initiering af TransmissionRRV-meddelelsen skal transmitteres straks efter detekteringen af en ændring i koordineringsdataene eller når den initieres manuelt.8.5.3.3. Behandling i den Modtagende Enhed8.5.3.3.1. Hvis der findes en tilsvarende flyveplan i den koordinerede tilstand og hvis der ikke findes nogen uoverensstemmelse, som ville forhindre en korrekt behandling af meddelelsen, da:- skal der kvitteres for RRV-meddelelsen;- i alle andre tilfælde skal der ikke kvitteres for meddelelsen.8.5.3.3.2. De foreslåede overførselsbetingelser skal vises ved den ATC-position, som er ansvarlig for flyvningens koordinering.8.5.3.3.3. AnbefalingEn indikation af årsagen til henvisningen (ikke-standard betingelser eller manuel henvisning) bør indbefattes.8.5.4. Kvittering for RRV8.5.4.1. KvitteringDer skal kvitteres for meddelelsen ved at generere og transmittere en SBY-meddelelse.8.5.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen SBY-meddelelse som kvittering for en RRV-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen af flyvningen.8.5.5. Operationel Besvarelse af RRVDen accepterende flyveleder kan enten acceptere, stille et mod-forslag om eller afvise en RRV-meddelelse.8.5.5.1. AcceptNår den accepterende flyveleder vælger at acceptere de foreslåede rettelser til de aftalte overførselsbetingelser, skal der returneres en ACP-meddelelse.8.5.5.2. Mod-ForslagNår den accepterende flyveleder vælger at stille et mod-forslag om overførselsbetingelser, skal der returneres en CDN-meddelelse.8.5.5.3. AfvisningNår den accepterende flyveleder vælger at afvise de foreslåede rettelser i de aftalte overførselsbetingelser:- skal en RJC-meddelelse returneres;og- en ny koordineringsproces skal initieres.Afvisning er underforstået, hvis der hverken modtages en ACP- eller en CDN som reaktion på RRV-meddelelsen.8.5.6. Eksempler8.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 EGBB8.6. Stand-by Meddelelse (SBY)8.6.1. Formål med SBY-MeddelelsenSBY-meddelelsen kvitterer for modtagelsen af en meddelelse, der foreslår overførselsbetingelser, og angiver, at forslaget er blevet henvist til flyvelederen for en beslutning.8.6.2. Indhold af MeddelelseSBY-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.8.6.3. Regler for Anvendelse8.6.3.1. GenereltSBY-meddelelsen skal genereres og transmitteres automatisk øjeblikkeligt som reaktion på:- en RAP-, RRV- eller CDN-meddelelse;- en ACT- eller REV-meddelelse, som ikke passerer filteret.8.6.4. Kvittering for SBYDer skal ikke kvitteres for SBY-meddelelsen.8.6.5. Eksempler8.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 0028.7. Acceptmeddelelse (ACP)8.7.1. Formål med ACP-MeddelelsenACP-meddelelsen opfylder de følgende operationelle krav under ATC-koordinerings- og overførselsfasen:- at angive den manuelle accept ved en flyveleder i én enhed af de overførselsbetingelser, der er foreslået af flyvelederen i den anden enhed i én af de følgende meddelelser:- RAP;- RRV;- CDN;- ACT og REV, hvis én af dem har vist sig at være ikke-standard;- når det er aftalt bilateralt, at frembringe den automatiske accept af en ACT- eller REV-meddelelse, som har passeret filteret i den accepterende enhed (i stedet for LAMen);- når det er aftalt bilateralt, at angive den manuelle accept af en HOP-meddelelse (i stedet for ROF-meddelelsen).8.7.2. Indhold af MeddelelseACP-meddelelsen består af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning;- Frivillige data - meddelelsen kan også indbefatte:- Frekvens;- Frivillige data i meddelelser i ICAO-format - meddelelsen kan også indeholde alle de følgende emner:- Luftfartøjsidentifikation;- Afgangsflyveplads;- Destinationsflyveplads.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.8.7.3. Regler for Anvendelse8.7.3.1. Generelt8.7.3.1.1. ACPens Meddelelseshenvisning skal indbefatte Meddelelsesnummeret på den meddelelse, som den er en reaktion på.8.7.3.1.2. Frekvensfeltet skal, når det er indbefattet, indeholde den frekvens, på hvilken flyvningen skal kontakte den accepterende enhed, når overdragelsen finder sted.8.7.3.1.3. ACP-meddelelsen skal sendes efterfølgende en manuel accept ved flyvelederen af foreslåede overførselsbetingelser, videresendt ved en ACT, RAP, REV, RRV eller CDN.8.7.3.1.4. ACP-meddelelsen kan sendes som et alternativ til en ROF-meddelelse som reaktion på en HOP-meddelelse.8.7.3.1.5. Når det bilateralt er aftalt, skal ACP-meddelelsen genereres og transmitteres automatisk ved systemet som en besvarelse af en ACT/REV, der har passeret filteret.8.7.3.1.6. Når en ACP er blevet modtaget, skal de aftalte overførselsbetingelser være bindende for begge enheder.8.7.3.2. Behandling i den Modtagende Enhed8.7.3.2.1. Det ATC-system, som modtager en ACP-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.8.7.3.2.2. Hvis ACPen kan forbindes med en flyveplan, skal accepten angives over for flyvelederen.8.7.3.2.3. Hvis ACPen ikke kan forbindes med en flyveplan:- skal en advarsel udsendes ved den behørige position; og- en LAM skal ikke sendes.8.7.4. Kvittering for ACP8.7.4.1. Kvittering8.7.4.1.1. Der skal ikke returneres en LAM, hvor ACPen anvendes som en automatisk besvarelse af en ACT- eller REV-meddelelse, der har passeret filteret.8.7.4.1.2. Der skal kvitteres for en ACP-meddelelse, der er sendt som et resultat af en manuel accept, ved at generere og transmittere en LAM-meddelelse.8.7.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som kvittering for en ACP-meddelelse, der er sendt som et resultat af en manuel accept, skal en advarsel vises ved den ATC-position, som er ansvarlig for koordineringen af flyvningen.8.7.5. Eksempler8.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 2421508.8. Koordineringsmeddelelse (CDN)8.8.1. Formål med CDN-MeddelelsenCDN-meddelelsen opfylder de følgende, operationelle krav:- at videresende et mod-forslag fra den accepterende flyveleder til den overførende flyveleder som en besvarelse af en ACT-, en RAP-, en REV- eller en RRV-meddelelse;- at initiere en foreslået modifikation af aftalte overførselsbetingelser ved den accepterende flyveleder til den overførende flyveleder.8.8.2. Indhold af MeddelelseCDN-meddelelsen består af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning (kun hvis den er en reaktion på en anden meddelelse);- Luftfartøjsidentifikation;- Afgangsflyveplads;- Destinationsflyveplads;NOTEMeddelelsen skal også indeholde ét af de følgende emner eller dem begge:- Estimatdata (hvis det er en ICAO-meddelelse) eller Overførselsflyveniveau (hvis det er en ADEXP-meddelelse);- Anmodning om Direkte Rutestyring.- Bilateralt aftalte data - De følgende data kan også være indbefattet, når det er aftalt bilateralt:- Frekvens.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.8.8.3. Regler for Anvendelse8.8.3.1. Generelt8.8.3.1.1. CDN-meddelelser skal kun initieres af den accepterende flyveleder.8.8.3.1.2. De skal bruges til at transmittere et mod-forslag fra den accepterende flyveleder til den overførende flyveleder.NOTEDette kan ske i en dialog som en besvarelse af et forslag videresendt ved en ACT, en RAP, en REV eller en RRV, eller som starten på en dialog med henblik på at rette tidligere aftalte betingelser.8.8.3.1.3. Meddelelseshenvisningen skal kun indsættes, når CDN-meddelelsen er som besvarelse af en anden meddelelse.8.8.3.1.4. Når den indsættes, skal meddelelseshenvisningen indeholde meddelelsesnummeret for den meddelelse, som CDNen er en besvarelse af.8.8.3.1.5. Faciliteten med Direkte Anmodning om Rutestyring (beskrevet detaljeret i Anneks A) skal:- kun anvendes, hvis det er aftalt bilateralt; og- hvis det er aftalt, definere enhver operationel grænse for dens brug.8.8.3.1.6. CDNen må ikke sendes efter et tidspunkt/en afstand før grænsen, som specificeret i LoAet mellem de berørte enheder.8.8.3.1.7. I tilfælde af at en CDN transmitteres samtidigt med en meddelelse for den samme flyvning fra den overførende enhed, f.eks. en revidering eller en ophævelse af koordinering, skal der hverken returneres en kvittering eller en operationel besvarelse.NOTEFølgen af dette er, at når to meddelelser krydser hinanden, tager meddelelsen fra den overførende enhed prioritet og begge lader CDNen falde. Begge enheder kan registrere situationen ved modtagelsen af meddelelsen fra den anden før modtagelsen af kvitteringen.8.8.3.1.8. Så snart som der er modtaget en accept, bliver dataene i CDN-meddelelsen operationelt bindende for begge ATC-enhederne. De koordinerede overførselsbetingelser og det faktum, at ACPen er blevet modtaget, skal forelægges for det berørte ATC-mandskab.8.8.3.2. Behandling i den Modtagende Enhed8.8.3.2.1. Hvis der findes en tilsvarende flyveplan og der ikke er nogen uoverensstemmelse til stede i meddelelsen, som ville forhindre korrekt behandling:- skal det operationelle indhold forelægges for den ATC-position, der er ansvarlig for flyvningens koordinering;og- en SBY skal returneres.8.8.3.2.2. Hvis CDNen ikke kan forbindes eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen, skal der ikke returneres nogen SBY.8.8.4. Kvittering for CDN8.8.4.1. KvitteringUnder de betingelser, der er specificeret ovenfor, skal der kvitteres for CDN-meddelelsen ved genereringen og transmissionen af en SBY-meddelelse.8.8.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen SBY-meddelelse som en kvittering for en CDN-meddelelse, skal en advarsel vises ved den ATC-position, der er ansvarlig for flyvningens koordinering.8.8.5. Operationel Besvarelse af CDNFlyvelederen kan enten acceptere eller afvise de overførselsbetingelser, som er foreslået i en CDN-meddelelse.8.8.5.1. AcceptNår den overførende flyveleder vælger at acceptere de foreslåede overførselsbetingelser, skal en ACP-meddelelse returneres.8.8.5.2. AnbefalingNår den overførende flyveleder vælger at afvise de foreslåede overførselsbetingelser, bør der sendes en RJC-meddelelse (udtrykkelig afvisning).NOTEDen foreslåede koordination afvises stiltiende, hvis der ikke er blevet modtaget nogen accept til tidspunktet for CDN-meddelelsens timeout.8.8.6. Eksempler8.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 F110A8.9. Meddelelse om Afvisning af Koordinering (RJC)8.9.1. Formål med RJC-MeddelelsenRJC-meddelelsen angiver afvisningen ved en flyveleder ved én enhed af de overførselsbetingelser, der er foreslået af flyvelederen ved den anden enhed, i én af de følgende meddelelser:- RAP;- RRV;- CDN;- ACT og REV, hvis en hvilken som helst af dem viser sig at være ikke-standard.RJC-meddelelsen kan kun bruges som direkte reaktion på én af meddelelserne ovenfor.8.9.2. Indhold af MeddelelseRJC-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Meddelelseshenvisning.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.8.9.3. Regler for Anvendelse8.9.3.1. Generelt8.9.3.1.1. RJCen skal sendes som påkrævet som reaktion på en RAP-, en RRV-, en CDN-meddelelse eller på en ACT- eller en REV-meddelelse, som har vist sig at være ikke-standard ved den accepterende enhed.8.9.3.1.2. RJC-meddelelsen afslutter systemdialogen og en hvilken som helst koordinering, som tidligere er aftalt, forbliver gyldig.8.9.3.1.3. AnbefalingEfterfølgende modtagelsen af en RJC-meddelelse bør der initieres en ny koordineringssekvens, som afspejler telefonkoordineringen, når det er anvendeligt.8.9.3.2. Behandling i den Modtagende Enhed8.9.3.2.1. Hvis der er fundet en tilsvarende meddelelse, som RJC-meddelelsen henviser til:- skal afvisningen angives ved den ATC-position, som er ansvarlig for den relevante flyvnings koordinering; og- en LAM skal returneres som kvittering.8.9.3.2.2. Hvis der ikke findes nogen sådan meddelelse som venter på en besvarelse, eller hvis der er en uoverensstemmelse til stede i meddelelsen, hvilken uoverensstemmelse forhindrer behandling, skal der ikke returneres nogen kvittering.8.9.4. Kvittering for RJC8.9.4.1. KvitteringDer skal kvitteres for RJC-meddelelse ved genereringen og transmissionen af en LAM meddelelse.8.9.4.2. Tilfælde af Ingen KvitteringHvis der ikke er modtaget nogen LAM-meddelelse som en kvittering for en RJC-meddelelse, skal der vises en advarsel ved den ATC-position, som er ansvarlig for koordineringen af flyvningerne.8.9.5. Eksempler8.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 3249. DIALOGPROCEDURE - OVERFØRSEL AF KOMMUNIKATION9.1. Generelt9.1.1. Introduktion9.1.1.1. Dette afsnit i standarden beskriver de faciliteter og meddelelser, som understøtter kontrolprocedurens radaroverdragelsesaspekt. De skal implementeres, hvor det er aftalt bilateralt.9.1.1.2. Faciliteterne i Overførsel af Kommunikation skal ikke implementeres, medmindre enheden enten anvender de koordineringsfaciliteter, der er beskrevet i Afsnit 6 (Grundlæggende Procedure - Obligatoriske Meddelelser), eller de, som er beskrevet i Afsnit 8 (Dialogprocedure - Koordinering).9.1.1.3. De meddelelser, som er beskrevet i dette afsnit af dokumentet, er kun tilgængelige i ADEXP-format og det er ikke planlagt, at de gøres tilgængelige i ICAO-format.9.1.2. Meddelelsessekvens9.1.2.1. En meddelelsesudveksling om Overførsel af Kommunikation, som er forskellig fra den Supplerende Datameddelelse (SDM), skal ikke finde sted, medmindre koordinering er fuldstændig, dvs. at en ACT- eller RAP-dialog er blevet fuldført ved hjælp af en LAM eller en ACP.9.1.2.2. Der skal ikke returneres en kvittering, medens koordinering er udestående.9.1.3. Overførsel af Kommunikation9.1.3.1. Metoden til at tilkendegive det aktuelle skift af flyvningers kommunikation skal være aftalt bilateralt mellem de to berørte enheder.9.1.3.2. Betingelserne skal være én af de følgende eller dem begge:- den overførende enhed sender en Frekvensændringsmeddelelse (COF);- den accepterende enhed sender en Meddelelse om Manuel Overtagelse af Kommunikation (MAS);9.1.3.3. Metoden skal aftales mellem de to enheder for hver trafikregulering.NOTEDer kan anvendes alternative metoder for forskellige trafikreguleringer, f.eks. kan én enhed generere COF-meddelelser for flyvninger, der forlader dens luftrum, og MAS-meddelelser for flyvninger, der kommer ind i dens luftrum. I et sådant tilfælde ville det ikke være nødvendigt for den anden enhed at indføre nogen som helst meddelelser til at tilkendegive overførsel af kommunikation.9.2. Overførselsinitieringsmeddelelse (TIM)9.2.1. Formål med TIM-MeddelelsenFormålet med TIMen er:- at tilkendegive Overførselsinitieringshændelsen (TI) (slutningen af koordineringsfasen og starten på overførselsfasen);- samtidigt at videresende overordnede kontroldata fra den overførende til den accepterende enhed.9.2.2. Indhold af MeddelelseTIM meddelelsen skal bestå af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Tilgængelige data - meddelelsen skal også indeholde enhvert af de følgende emner, hvis de er tilgængelige:- Klareret Flyveniveau;- Tildelt Kurs eller Direkte Klarering;- Tildelt Hastighed;- Tildelt Stignings-/Nedstigningsrate;- Frivillige data - meddelelsen kan også indeholde:- Position.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.2.3. Regler for Anvendelse9.2.3.1. Generelt9.2.3.1.1. TIM-meddelelsen skal genereres og transmitteres af den overførende enhed til den accepterende enhed uden menneskelig intervention, når flyvningen er ved en bilateralt aftalt tid/en bilateralt aftalt afstand fra grænsen.9.2.3.1.2. En TIM-meddelelse skal også sendes automatisk, når Frekvensanmodningsmeddelelsen (ROF) modtages af den overførende enhed.9.2.3.1.3. Der skal ikke sendes en TIM, før flyvningen er blevet koordineret.9.2.3.1.4. TIM-meddelelsen skal indeholde de seneste data, der er tilgængelige i systemet.9.2.3.2. Tidsparametre for Transmission9.2.3.2.1. TIM-genereringsparameteren skal være en Variabel Systemparameter, som kan ændres baseret på bestemmelserne i LoAene.9.2.3.2.2. AnbefalingTIM-genereringssystemparameteren bør være defineret særskilt for hvert af COPerne.9.2.3.2.3. Koordineringspartnerne skal indbefatte TIM-genereringsparametrene i deres LoAe.9.2.3.2.4. Den systemparameter, som igangsætter TIM-meddelelsen, kan vedrøre luftfartøjets beregnede, beholdne fart. Initieringen af en TIM-meddelelse skal imidlertid altid indledes, før den pågældende flyveplansposition er tættere på COP end en minimal distance, der er specificeret bilateralt.9.2.3.2.5. Den specificerede systemparameter for TIM-transmission skal tillade tilstrækkelig tid til verbal koordinering før overdragelsen.9.2.3.3. Behandling i den Modtagende Enhed9.2.3.3.1. De data, der modtages i en TIM, skal gøres tilgængelige for den accepterende flyveleder.9.2.4. Kvittering for TIM9.2.4.1. KvitteringHvis TIM-meddelelsen:- utvetydigt kan forbindes med en flyveplan, skal der kvitteres for den ved genereringen og transmissionen af en LAM-meddelelse;- ikke kan forbindes utvetydigt med en flyveplan, skal der ikke sendes nogen kvittering.9.2.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en TIM-meddelelse, skal der vises en advarsel ved den behørige position.9.2.5. Eksempel-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM2539.3. Supplerende Datameddelelse (SDM)9.3.1. Formål med SDM-Meddelelsen9.3.1.1. Generelt9.3.1.1.1. Det primære formål med SDMen er at transmittere kontroldata og ændringer dertil fra den overførende enhed til den accepterende enhed under forudsætning af, det bilateralt er blevet aftalt, at der ikke behøver at blive kvitteret for ændringerne ved den accepterende flyveleder.9.3.1.1.2. SDM-meddelelsen kan også bruges ved den accepterende enhed til at oplyse den overførende enhed om den radiotelefonifrekvens, som flyvningen skal overføres til.9.3.2. Indhold af Meddelelse9.3.2.1. Meddelelser fra den Overførende EnhedSDM-meddelelsen skal bestå af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Yderligere data - meddelelsen skal også indeholde én eller flere af følgende:- Tildelt Kurs eller Direkte Klarering;- Tildelt Hastighed;- Tildelt Stignings-/Nedstigningsrate;- Klareret Flyveniveau.9.3.2.2. Meddelelser fra den Accepterende EnhedSDMen skal indeholde de følgende data:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Frekvens.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.3.3. Regler for Anvendelse9.3.3.1. Meddelelser fra den Overførende Enhed9.3.3.1.1. SDM-meddelelser transmitteres efter initieringen af overførselsfasen (se TIM, afsnit 9.2) efterfølgende en hvilken som helst ændring af de følgende emner:- klareret flyveniveau;- tildelt hastighed;- tildelt stignings-/nedstigningsrate;- tildelt kurs; eller- udstedelse eller ændring af en klarering for flyvningen til at fortsætte direkte til et specificeret punkt.NOTEDet er påkrævet at anvende HOP-meddelelsen, når godkendelse ved den accepterende flyveleder er påkrævet forud for overførslen af kommunikation.9.3.3.1.2. Meddelelsen skal kun indeholde de felter, der er ændrede.9.3.3.1.3. SDM-meddelelser indeholdende de data, der er beskrevet i in 9.3.3.1.1, skal transmitteres før TI, hvis det er aftalt bilateralt.9.3.3.1.4. Sådanne meddelelser skal påbegyndes til et bilateralt aftalt tidspunkt i forhold til TI forudsat, at der er data, for hvilke en værdi er tilgængelig i systemet.9.3.3.2. Meddelelser fra den Accepterende Enhed9.3.3.2.1. SDM-meddelelser kan transmitteres for at angive den frekvens, på hvilken flyvningen skal kontakte den accepterende enhed.NOTEEnheder kan bilateralt aftale at sende anden information. En sådan overførsel er ikke defineret i og er derfor ikke en del af denne standard.9.3.3.2.2. SDM-meddelelser fra den accepterende enhed skal transmitteres under koordineringsfasen, hvis det er aftalt bilateralt.9.3.3.3. Behandling i den Modtagende Enhed9.3.3.3.1. Det ATC-system, som modtager en SDM-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.9.3.3.3.2. Hvis en tilsvarende flyveplan i den koordinerede tilstand er fundet:- skal en LAM returneres; og- skal det operationelle indhold i SDM-meddelelsen gøres tilgængeligt for den pågældende flyveleder.9.3.3.3.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der findes en uoverensstemmelse, som forhindrer korrekt behandling af meddelelsen:- skal der ikke returneres nogen LAM; og- der skal udsendes en advarsel ved en passende position.9.3.4. Kvittering for SDM9.3.4.1. KvitteringDer skal kvitteres for SDM-meddelelsen ved genereringen og transmissionen af en LAM-meddelelse.9.3.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en SDM-meddelelse, skal der vises en advarsel ved en passende position.9.3.5. Eksempel-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 2909.4. Forslag om Overdragelse (HOP)9.4.1. Formål med HOP-MeddelelsenFormålet med HOP-Meddelelsen er:- for den overførende flyveleder at henlede den accepterende flyveleders opmærksomhed til en specifik flyvning for overdragelsesformål;- for den overførende flyveleder at foreslå flyvningen til overdragelse til den accepterende flyveleder, når det er påkrævet at gøre dette;- at videresende modifikationer til de overordnede kontroldata, hvilke kræver godkendelsen ved den accepterende flyveleder, ifølge bilateral aftalte.Det er ikke nødvendigt at anvende HOPen for alle flyvninger; den bruges efter den overførende flyveleders skøn.NOTEMed hensyn til afsnit c) ovenfor, anvendes SDMen til at videresende modifikationer til overordnede kontroldata, hvilke modifikationer ikke kræver den accepterende flyveleders godkendelse.9.4.2. Indhold af MeddelelseHOP-meddelelsen skal bestå af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Tilgængelige data - meddelelsen skal også indeholde enhvert af de følgende emner, hvis de er tilgængelige:- Klareret Flyveniveau.- Tildelt Kurs/Direkte Klarering;- Tildelt Hastighed;- Tildelt Stignings-/Nedstigningsrate;- Frivillige data - meddelelsen kan også indeholde:- Position.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.4.3. Regler for Anvendelse9.4.3.1. Generelt9.4.3.1.1. HOP-meddelelsen skal, når den bruges, initieres manuelt af den overførende flyveleder.9.4.3.1.2. Meddelelsen skal indbefatte hvilke som helst flyvedata, der er beskrevet i afsnit 9.4.2 ovenfor, og som er ændret i forhold til det, der tidligere er transmitteret.9.4.3.1.3. Hvis en HOP-meddelelse sendes før TI, skal Overførselsfasen initieres.NOTEEn overførselsinitieringsmeddelelse (TIM) er ikke påkrævet ud over HOPen.9.4.3.1.4. Det tidligste tidspunkt eller den tidligste distance før COPet eller grænsen, hvor HOPen kan sendes, skal være aftalt bilateralt.9.4.3.1.5. AnbefalingDette tidspunkt/denne distance bør være specificeret særskilt for hvert COP.9.4.3.2. Behandling i den Modtagende Enhed9.4.3.2.1. Det ATC-system, som modtager en HOP-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.9.4.3.2.2. De flyvedata, der er modtaget i meddelelsen, skal øjeblikkeligt vises til den accepterende flyveleder.9.4.3.2.3. Hvis den accepterende flyveleder accepterer flyvningen under de betingelser, der er foreslået i HOPen, kan en ROF sendes som reaktion til den overførende enhed. Når det er aftalt bilateralt, kan en ACP sendes som en besvarelse af en HOP.9.4.3.2.4. Hvis den accepterende flyveleder ikke er i stand til at acceptere flyvningen, skal overførslen aftales verbalt.NOTEPå grund af overdragelsesprocedurens presserende karakter er systemstøtte ved at overvåge returneringen af ROFen (eller ACPen) ikke påkrævet ved denne standard; det antages, at den overførende flyveleder godt er klar over fraværet af en reaktion fra den accepterende flyveleder og vil tage de forholdsregler, som er nødvendige. Imidlertid forhindrer denne standard ikke, at der kan tilvejebringes en advarsel til den overførende flyveleder, hvis det betragtes som værende operationelt nødvendigt.9.4.3.2.5. Så snart som der er modtaget en ROF (eller en ACP), skal dataene i HOP-meddelelsen blive operationelt bindende for begge ATC-enhederne.9.4.4. Kvittering for HOP9.4.4.1. KvitteringHvis den kan forbindes med en flyveplan, skal der automatisk kvitteres for HOP-meddelelsen ved hjælp af en LAM.9.4.4.2. Tilfælde af Ingen KvitteringHvis der ikke er modtaget nogen LAM-meddelelse som en kvittering for en HOP-meddelelse, skal der vises en advarsel ved den behørige position.9.4.5. Eksempel-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ9.5. Frekvensanmodningsmeddelelse (ROF)9.5.1. Formål med ROF-MeddelelsenROFen sendes af den accepterende enhed til den overførende enhed, når det er påkrævet, og anmoder derved den overførende flyveleder om at instruere luftfartøjet om at skifte til den accepterende flyveleders frekvens. Meddelelsen kan bruges:- som besvarelse af en HOP for at tilkendegive accepten af flyvningen under de foreslåede betingelser;- til at anmode om den tidlige overførsel af flyvningen.9.5.2. Indhold af MeddelelseROF-meddelelsen skal bestå af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Frivillige data - meddelelsen kan også indeholde:- Frekvens.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.5.3. Regler for Anvendelse9.5.3.1. Generelt9.5.3.1.1. ROF-meddelelsen skal initieres manuelt af den accepterende flyveleder.9.5.3.1.2. Den accepterende flyveleder kan igangsætte en ROF, enten:- når den accepterende flyveleder kræver at have luftfartøjet tidligt på frekvensen; eller- som en besvarelse af en HOP-meddelelse.9.5.3.2. Behandling i den Modtagende Enhed9.5.3.2.1. Det ATC-system, som modtager en ROF-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.9.5.3.2.2. Modtagelsen af ROFen skal angives over for den overførende flyveleder uden forsinkelse.9.5.3.2.3. Hvis flyvningen ikke er i Overførselsfasen, skal Overførselsfasen initieres og der skal transmitteres en TIM-meddelelse.9.5.4. Kvittering for ROF9.5.4.1. Kvittering9.5.4.1.1. Hvis ROF-meddelelsen utvetydigt kan forbindes med en flyveplan, skal der kvitteres for den ved genereringen og transmissionen af en LAM-meddelelse.9.5.4.1.2. Hvis ROF-meddelelsen ikke kan forbindes utvetydigt med en flyveplan, skal der ikke sendes nogen kvittering.9.5.4.2. Tilfælde af Ingen KvitteringHvis der ikke er modtaget nogen LAM-meddelelse som en kvittering for en ROF-meddelelse, skal der vises en advarsel ved den behørige ATC-position.9.5.5. Eksempel-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM2539.6. Frekvensændringsmeddelelse (COF)9.6.1. Formål med COF-Meddelelsen9.6.1.1. Generelt9.6.1.1.1. COFen sendes af den overførende enhed til den accepterende enhed for at angive, at flyvningen er blevet instrueret om at kontakte den accepterende flyveleder.9.6.1.1.2. Meddelelsen kan indbefatte faciliteten til, at den overførende flyveleder kan frigøre flyvningen fra de aftalte overførselsbetingelser, når den har etableret radiokommunikation med den accepterende flyveleder.9.6.2. Indhold af MeddelelseCOF-meddelelsen skal bestå af de følgende dataemner:- Obligatoriske data - meddelelsen skal indeholde:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation;- Tilgængelige data - meddelelsen skal også indeholde enhvert af de følgende emner, hvis de er tilgængelige:- Frigivelsesindikation;- Frekvens;- Klareret Flyveniveau.- Tildelt Kurs eller Direkte Klarering;- Tildelt Hastighed;- Tildelt Stignings-/Nedstigningsrate;- Frivillige data - meddelelsen kan også indeholde:- Position.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.6.3. Regler for Anvendelse9.6.3.1. Generelt9.6.3.1.1. COF-meddelelsen skal initieres manuelt af den overførende flyveleder.9.6.3.1.2. Anvendelsen af COF-meddelelsen er obligatorisk, hvis MAS-meddelelsen efter bilateral aftale ikke anvendes.9.6.3.1.3. Hvis en COF-meddelelse sendes før TI, skal Overførselsfasen initieres.NOTEDer er ikke påkrævet en Overførselsinitieringsmeddelelse (TIM) ud over COFen.9.6.3.2. Behandling i den Modtagende Enhed9.6.3.2.1. Det ATC-system, som modtager en COF-meddelelse, skal forsøge at opnå forbindelse med en tilsvarende flyveplan.9.6.3.2.2. Modtagelsen af COFen skal angives over for den accepterende flyveleder uden forsinkelse.9.6.4. Kvittering for COF9.6.4.1. Kvittering9.6.4.1.1. Hvis COF-meddelelsen utvetydigt kan forbindes med en flyveplan, skal der kvitteres for den ved genereringen og transmissionen af en LAM-meddelelse.9.6.4.1.2. Hvis COF-meddelelsen ikke kan forbindes utvetydigt med en flyveplan, skal der ikke sendes nogen kvittering.9.6.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en COF-meddelelse, skal der vises en advarsel ved den behørige ATC-position.9.6.5. Eksempler-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM2539.7. Meddelelse om Manuel Overtagelse af Kommunikation (MAS)9.7.1. Formål med MAS-MeddelelsenMASen sendes af den accepterende enhed til den overførende enhed og angiver derved, at der er blevet etableret tovejsradiokontakt med flyvningen.9.7.2. Indhold af MeddelelseMAS-meddelelsen skal indeholde de følgende dataemner:- Meddelelsestype;- Meddelelsesnummer;- Luftfartøjsidentifikation.NOTEDataindsættelsesregler, formater og feltindhold er specificeret i Anneks A.9.7.3. Regler for Anvendelse9.7.3.1. Generelt9.7.3.1.1. MAS-meddelelsen skal initieres manuelt af den accepterende flyveleder.9.7.3.1.2. Anvendelsen af MAS-meddelelsen er obligatorisk, hvis COF-meddelelsen ifølge bilateral aftale ikke anvendes.9.7.3.2. Behandling i den Modtagende Enhed9.7.3.2.1. Det ATC-system, som modtager en MAS-meddelelse, skal forsøge at opnå forbindelse med den tilsvarende flyveplan.9.7.3.2.2. Det faktum, at MASen er blevet modtaget, skal øjeblikkeligt forelægges for flyvelederen.9.7.4. Kvittering for MAS9.7.4.1. Kvittering9.7.4.1.1. Hvis MAS-meddelelsen utvetydigt kan forbindes med en flyveplan, skal der kvitteres for den ved genereringen og transmissionen af en LAM-meddelelse.9.7.4.1.2. Hvis MAS-meddelelsen ikke kan forbindes utvetydigt med en flyveplan, skal der ikke sendes nogen kvittering.9.7.4.2. Tilfælde af Ingen KvitteringHvis der ikke modtages nogen LAM-meddelelse som en kvittering for en MAS-meddelelse, skal der vises en advarsel ved den behørige ATC-position, som det er påkrævet.9.7.5. Eksempel-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253ANNEKS A (Retningsgivende)DATAINDSÆTTELSESREGLERINDHOLD>TABELPOSITION>A.1. FormålDette Anneks beskriver de generelle regler for indsættelsen af data i de meddelelser, der er beskrevet i denne standard. Disse regler gælder for alle meddelelser, undtagen hvor andre alternativer eller undtagelser til disse regler er anført specifikt i Reglerne for Anvendelse for en specifik meddelelse.A.2. Fælles MeddelelsesformaterA.2.1. Alle meddelelser beskrevet i de følgende afsnit kan transmitteres ved brug af ICAO-format:6 Grundlæggende Procedure - Obligatoriske Meddelelser;7 Grundlæggende Procedure - Ekstra Meddelelser;8 Dialogprocedure - Koordinering.A.2.2. ICAO-meddelelsesfeltformater er specificeret i Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control (Document 4444) (Procedurer for Luftnavigeringstjenester - Regler for Luft- og Lufttrafikkontrollen). I meddelelser, hvor de forekommer, skal de følgende ICAO-felttyper transmitteres før nogen andre Felttyper i den følgende rækkefølge: 3, 7, 13, 14 og 16. Idet de er i Felttype 22-format, er rækkefølgen af andre ICAO-Felttyper ikke vigtig, bortset fra at de ikke må gå forud for de ovenfor oplistede Felttyper.A.2.3. Alle meddelelser beskrevet i dette dokument kan transmitteres ved brug af Eurocontrol ADEXP-format. Indholdet, strukturen og anvendelsen af ADEXP-datafelter skal være i overensstemmelse med Henvisning 2.NOTER1. Kun de Primære ADEXP-datafelter er oplistet i dette Anneks, bortset fra når forbundne Underfelter kræver en specifik kommentar. ADEXP-standarden oplister alle frivillige og obligatoriske Underfelter, som er påkrævede inden i hvert Primærfelt.2. Meddelelser beskrevet i Afsnit 9, Dialogprocedure - Overførsel Kommunikation, er kun beskrevet i ADEXP-format.A.3. MeddelelsestypeMeddelelsestypen skal være forkortelsen for meddelelsen som beskrevet i den følgende liste:ABI: Forudgående Grænseinformation (Advance Boundary Information).ACP: Accept (Acceptance).ACT: Aktivering (Activate).CDN: Koordinering (Co-ordination).COD: SSR-Kodetildeling (SSR Code Assignment).COF: Frekvensændring (Change of Frequency).HOP: Forslag om Overdragelse (Hand-Over Proposal).INF: Information (Information).LAM: Logisk Kvitteringsmeddelelse (Logical Acknowledgement Message).MAC: Meddelelse for Ophævelse af Koordinering (Message for Abrogation of Co-ordination).MAS: Manuel Overtagelse af Kommunikation (Manual Assumption of Communications).PAC: Foreløbig Aktivering (Preliminary Activiation).RAP: Henvist Aktiveringsforslag (Referrede Activate Proposal).REV: Revidering (Revision).RJC: Afvisning af Koordinering (Reject Co-ordination).ROF: Frekvensanmodning (Request on Frequency).RRV: Forslag om Henvist Revidering (Referred Revision Proposal).SBY: Stand-by (Stand-by).SDM: Supplerende Datameddelelse (Supplementary Data Message).TIM: Overførselsinitieringsmeddelelse (Transfere Initiation Message).A.3.1. ICAOFelt type 3, element (a).A.3.2. ADEXPPrimært felt "title".A.4. MeddelelsesnummerMeddelelsesnummerdataene indbefatter de identifikatorer, der er tildelt til den transmitterende og den modtagende enhed, og meddelelsessekvensnummeret. Meddelelsessekvensnummeret går sekventielt frem fra 001 til 000 (som repræsenterer 1000), og gentager derfra fra 001 for alle meddelelser, som er sendt til den samme adressat, uanset typen af meddelelse.A.4.1. ICAOFelttype 3, element (b).A.4.2. ADEXPPrimært felt "refdata".Underfeltet "fac", inden i underfelterne "sender" og "recvr", skal indeholde de identifikatorer, som er tildelt til ATC-enhederne. Disse identifikatorers længde må ikke være større end otte karakterer.Underfeltet "seqnum" skal indeholde sekvensnummeret.A.5. MeddelelseshenvisningA.5.1. ICAOFelttype 3, element (c) (betegnes "reference data" i ICAO dokument 4444).Indholdet af element (c) skal være som indholdet i Felttype 3, element (b), i den OLDI-meddelelse, der henvises til.A.5.2. ADEXPPrimært felt "msgref".Værdierne af Underfelterne "sender", "recvr" og "seqnum" inden i det Primære felt "msgref" skal være værdierne af de samme Underfelter inden i det Primære felt "refdata" i den OLDI-meddelelse, der henvises til.A.6. LuftfartøjsidentifikationA.6.1. ICAOFelttype 7, element (a).A.6.2. ADEXPPrimært felt "arcid".A.7. SSR-Tilstand og -KodeEnten:1. hvis den er kendt, den SSR-tilstand/kode på hvilken den modtagende enhed kan forvente at luftfartøjet responderer ved kontrolpunktsoverførslen;eller2. en indikator for, at der anmodes om SSR-koden fra den modtagende enhed.A.7.1. ICAOFelttype 7, elementer (b) og (c).Hvis der ikke er tildelt nogen SSR-kode eller hvis tilstanden/koden ikke er kendt, skal elementerne (b) og (c) udelades.Når der anmodes om en SSR-kode/tilstand, skal elementerne b) og c) indeholde værdien "A9999".A.7.2. ADEXPPrimært felt "ssrcode".Hvis der ikke er tildelt nogen gyldig SSR-kode eller hvis tilstanden/koden ikke er kendt, skal feltet udelades.Når der anmodes om en SSR-kode/tilstand via PAC-meddelelsen, skal det primære felt "ssrcode" indeholde indikatoren "REQ".A.8. AfgangsflyvepladsA.8.1. ICAOFelttype 13, element (a).A.8.2. ADEXPPrimært felt "adep".A.9. EstimatdataA.9.1. GenereltA.9.1.1. Estimatdata skal indeholde COPet, tidspunkt ved COPet og overførselsniveau.A.9.1.2. Koordineringspunktet skal være defineret som enten et kendt referencepunkt, en afstand og pejling fra et kendt referencepunkt eller en breddegrad og en længdegrad.A.9.1.3. Det klarerede (overførsels-) niveau skal svare til de foreslåede overførselsbetingelser.A.9.1.4. AnbefalingFor stigende eller nedstigende flyvninger bør estimatdataene også indeholde supplerende krydsningsdata og krydsningsbetingelser.A.9.1.5. Hvis de bruges, skal de supplerende krydsningsdata indeholde det supplerende krydsningsniveau ved kontrolpunktsoverførslen. Krydsningsbetingelserne skal være:- Bogstavet "A"; - hvis flyvningen vil være ved eller over niveauet i de supplerende krydsningsdata; eller- Bogstavet "B"; - hvis flyvningen vil være ved eller under niveauet i de supplerende krydsningsdata.A.9.2. ICAOFelttype 14.A.9.3. ADEXPPrimært felt "coordata".Underfeltet "ptid" inden i det Primære felt "coordata" skal enten indeholde:- et kendt referencepunkt; eller- en pejling og en distance fra et kendt referencepunkt som defineret i den samme meddelelse ved det Primære felt "REF" eller "GEO".A.10. KoordineringspunktA.10.1. GenereltA.10.1.1. Det koordineringspunkt, som der henvises til af den overførende og den modtagende ATC-enhed, med henblik på den pågældende overførsel.A.10.1.2. Koordineringspunktet skal være defineret som enten et kendt referencepunkt, en afstand og pejling fra et kendt referencepunkt eller en breddegrad og en længdegrad.A.10.2. ICAOFelt 14, element (a).A.10.3. ADEXPPrimært felt "cop", som indeholder:- et kendt referencepunkt; eller- en pejling og en distance fra et kendt referencepunkt som defineret i den samme meddelelse ved det Primære felt "REF" eller "GEO".A.11. DestinationsflyvepladsA.11.1. ICAOFelt 16, element (a).A.11.2. ADEXPPrimære felter "ades".A.12. Luftfartøjsnummer og -TypeLuftfartøjsnummeret og -typen skal indeholde typen af luftfartøj. Luftfartsnummeret skal være indeholdt i tilfælde af formationsflyvninger.A.12.1. ICAOFelttype 9 i felttype 22-format. Element c i felttype 9 skal enten indeholde den wake turbulence kategori, der er passende for luftfartøjets type, eller bogstavet "Z".A.12.2. ADEXPPrimært felt "arctyp". Derudover, hvis der er mere end ét luftfartøj i flyvningen, det primære felt "nbarc".A.13. RuteBegge formater understøtter rutebeskrivelsen som defineret for ICAO-meddelelser, hvilke som det første element kræver hastighed og anmodet flyveniveau eller højdeinformation. Efter hastighed-niveau-gruppen vil rutedataene som et minimum indbefatte det, der er specificeret i den følgende afsnit. Yderligere rutedata kan være indsat efter emne c), hvis de er tilgængelige. Se også Anneks B "Specielle Rutebehandlingskrav" for indsættelsesregler for rutedata.A.13.1. IndholdA.13.1.1. Flyvninger, der fortsætter via et Defineret COP- ruteelementet før COPet (ATS-rute, SID-identifikator, DCT eller signifikant punkt);- COPet;- ruteelementet efter COPet (ATS-rute eller signifikant punkt).A.13.1.2. Flyvninger, der fortsætter Uden for ATS-Rute- det punkt, hvorfra flyvningen fortsætter på det direkte rutesegment;- elementet "DCT";- det punkt, hvortil flyvningen fortsætter på det direkte rutesegment.A.13.2. FormatA.13.2.1. ICAOFelttype 15, i felttype 22-format.A.13.2.2. ADEXPPrimært felt "route".A.14. Andre FlyveplansdataA.14.1. ICAOFelttyper 8, 10 og 18 i felttype 22-formatet.A.14.2. ADEXPPrimære felter: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts", og "typz".A.15. Koordineringsstatus og -ÅrsagKoordineringsstatus og Årsag skal indbefatte de følgende elementer:- en indikator på tre bogstaver, hvilken indikator bekræfter den nye status af systemflyveplanen som værende én af de følgende:- INI, når systemflyveplanen skal være i en indledende tilstand, dvs. ingen underretningsmeddelelse modtaget;- NTF, når systemflyveplanen skal være i en underrettet status;- CRD, når systemflyveplanen skal være i koordineret status, dvs. grundlæggende ACT modtaget eller indledende koordineringsdialog fuldendt med aftalte betingelser.- en indikator på tre bogstaver, hvilken indikator angiver årsagen til at statusen som værende én af de følgende:- TFL, hvis årsagen er et skift i overførselsniveau;- RTE, hvis årsagen er en ændring af rute;- HLD, for at angive at flyvningen er i holding i en ubestemt periode og vil være genstand for en yderligere meddelelse;- DLY, for at angive, at afgangen er forsinket;- CAN, hvis årsagen er en annullering;- CSN, for en ændring af kaldesignal;- OTH, for en hvilken som helst anden årsag eller hvis årsagen er ukendt.A.15.1. ICAOA.15.1.1. Koordineringsstatusen og -årsagen skal være i Felttype 18-format.A.15.1.2. Koordineringsstatusen og -årsagen skal indbefatte de følgende elementer som en gruppe på ti karakterer:- STA efterfulgt af en skråstreg;- den indikator, der bekræfter den nye status af underretningen/koordineringen;- den indikator, som specificerer årsagen.A.15.2. ADEXPPrimært felt "cstat".Ekstra emner "coordstatusident" og "coordstatusreason" skal indeholde den nye status og årsag som specificeret ovenfor respektivt.A.16. Tildelt Kurs (kun ADEXP)Primært felt "ahead" skal indeholde enten:- den kurs, der er tildelt en flyvning, udtrykt i grader;eller- hvis der ikke er tildelt nogen kurs, indikatoren "ZZZ", f.eks. når en SDM-meddelelse bruges for at indikere, at en tidligere tildelt kurs ikke længere gælder.A.17. Tildelt Hastighed (kun ADEXP)Primært felt "aspeed" skal enten indeholde:- den hastighed, der er tildelt til flyvningen, udtrykt i knob, machtal eller kilometer/time;eller- hvis der ikke er tildelt nogen hastighed, indikatoren "ZZZ", f.eks. når en SDM-meddelelse bruges for at indikere, at en tidligere tildelt hastighed ikke længere gælder.A.18. Tildelt Stignings-/Nedstigningsrate (kun ADEXP)Primært felt "rate" skal indeholde:- den stignings- eller nedstigningsrate, der er tildelt til en flyvning, udtrykt i hundrede fod per minut;eller- hvis der ikke er tildelt nogen stignings-/nedstigningsrate, indikatoren "ZZZ" i feltets cifferdel, f.eks. når en SDM-meddelelse bruges for at indikere, at en tidligere tildelt stignings-/nedstigningsrate ikke længere gælder.A.19. Direkte Klarering (kun ADEXP)En direkte rute, ikke defineret som en ATS-rute, mellem to punkter. Punkterne kan enten være defineret som et kendt referencepunkt eller en afstand og pejling fra et referencepunkt. Alle anvendte slutpunktsdesignatorer skal være aftalt bilateralt, dvs. de skal være kendt af begge systemer.Primært felt "DCT", som indeholder:- det punkt, hvor afvigelsen er påbegyndt eller vil påbegynde, defineret som ét af de følgende:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt, som defineret i den samme meddelelse ved det Primære felt "REF";eller- værdien "ZZZ", hvis den sendende enhed ikke behøver at angive afvigelsespunktet.- det punkt, der er placeret på den originale flyveplansrute, til hvilket luftfartøjet er blevet eller vil blive klareret, defineret som:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt, som defineret i den samme meddelelse ved det Primære felt "REF".A.20. Anmodning om Direkte RutestyringAnmodning om en direkte rute, ikke defineret som en ATS-rute, mellem to punkter. Punkterne kan være defineret som enten et kendt referencepunkt eller en afstand og en pejling fra et referencepunkt.Alle anvendte slutpunktsdesignatorer skal være aftalt bilateralt, dvs. de skal være kendt af begge systemer.A.20.1. ICAOFelttype 15, uden den indledende hastighed/niveau-gruppe, i felt 22-format.Den skal indeholde:- det punkt, ved hvilket der anmodes om at afvigelsen begynder, defineret som et af de følgende:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt;eller- værdien "ZZZ", hvis der anmodes om en direkte rutestyring ved den modtagende ATC-enhed.- forkortelsen "DCT",- efterfulgt af det punkt, der er placeret på den originale flyveplansrute, som luftfartøjet anmodes om at blive klareret til, defineret som:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt.A.20.2. ADEXPPrimært felt "DCT", som indeholder:- det punkt ved hvilket der anmodes om at afvigelsen begynder, defineret som et af de følgende:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt, som defineret i den samme meddelelse ved det Primære felt "REF";eller- værdien "ZZZ", hvis der anmodes om en direkte rutestyring ved den modtagende ATC-enhed, men det nøjagtige punkt, ved hvilket det skulle begynde, ikke kendes.- det punkt, der er placeret på den originale flyveplansrute, som luftfartøjet anmodes om at blive klareret til, defineret som:- et kendt referencepunkt;eller- en afstand og en pejling fra et kendt referencepunkt, som defineret i den samme meddelelse ved det Primære felt "REF".A.21. Position (kun ADEXP)A.21.1. GenereltA.21.1.1. Flyvningens aktuelle position enten udtrykt i geografiske koordinater eller ved pejling og afstand fra et angivet punkt.A.21.1.2. Primært felt "ref" eller "geo" skal definere flyvningens aktuelle horisontale beliggenhed. Punkter, der bruges til afstands- og pejlingsformål i det primære felt "ref", skal være aftalt bilateralt, dvs. kendt af begge systemer. Primært felt "position" skal indeholde underfeltet "ptid", som henviser til det definerede referencepunkt eller det definerede geografiske punkt. Hvis tidsinformation skal indbefattes, skal enten underfeltet 'to' (hhmm) eller 'sto' (hhmmss) anvendes, efter bilateral aftale.A.22. Frigivelsesindikation (kun ADEXP)Primært felt "release" skal indeholde én af de følgende:- C, hvis flyvningen er frigivet til stigning;- D, hvis flyvningen er frigivet til nedstigning;- T, hvis flyvningen er frigivet til drej;- F, hvis flyvningen er helt frigivet til alle handlinger.A.23. FrekvensA.23.1. ICAOFelttype 18 skal indbefatte de følgende elementer i felt 22-format:- FRQ, efterfulgt af en skråstreg;- 6 cifre, som angiver frekvensen udtrykt MHz med tre decimalpladser.A.23.2. ADEXPPrimært felt "freq".A.24. Årsag (kun ADEXP)Primært felt "reason", som indeholder værdien "MANUAL" for meddelelser, der henvises manuelt.A.25. Klareret Flyveniveau (kun ADEXP)Primært felt "cfl".A.26. Foreslået Overførselsflyveniveau (kun ADEXP)Primært felt "propfl".A.27. Estimeret StarttidA.27.1. ICAOFelttype 13 element (b).A.27.2. ADEXPPrimært felt "etot".A.28. HenvisningsmeddelelsestypeFeltet indeholder meddelelsestypen som specificeret i afsnit A.1 i dette Anneks.A.28.1. ICAOFelttype 18 i felttype 22-format. Elementets indikator skal være "MSG".A.28.2. ADEXPPrimært felt "msgtyp".ANNEKS B (Retningsgivende)SPECIELLE RUTEBEHANDLINGSKRAVB.1. IntroduktionB.1.1. GenereltB.1.1.1. Dette Anneks beskriver reglerne og dataindsættelseskravene i de følgende tilfælde, når de er tilladte:- en flyvning styrer på en direkte beholden kurs, uden for rute, på tværs af grænsen som et resultat af et direkte rutesegment, der er arkiveret i flyveplanen;- en flyvning efter transmission af ABI- eller ACT-meddelelsen gen-dirigeres via enten:- en anden ATS-rute;- en direkte, beholden kurs for at slutte sig til den originale rute ved et senere punkt.B.1.1.2. Med hensyn til gen-dirigeringen af flyvninger (afsnit B.1.1.1), understøtter den dataudveksling, de er beskrevet i dette Anneks, modifikationen af flyvningens rute, som den holdes i begge systemer ved brug af underretnings- og koordineringsmeddelelser.B.2. Anvendelse af MeddelelserB.2.1. Grundlæggende Regler for Direkte RutestyringerB.2.1.1. Betingelser for brugen af OLDIen til koordineringen af flyvninger på direkte rutestyringer skal være aftalt bilateralt.B.2.1.2. De data, der er påkrævet for underretningen og koordineringen af flyvninger på direkte rutestyringer, er indeholdt i koordineringspunktsdata (estimatdata (ICAO-format) og koordineringsdata (ADEXP-format) og ruten i de anvendelige meddelelser.B.2.2. Arkiveret Direkte RuteNår ruten angiver, at flyvningen vil krydse grænsen på en direkte, beholden kurs, vil det direkte rutesegment og det resulterende COP være indbefattet i ABI-meddelelsen/ABI-meddelelserne. Dette COP er indbefattet i den efterfølgende ACT- eller RAP-meddelelse.COPet og rutedataene skal være i det format, der er beskrevet i afsnit B.3.2.B.2.3. Gen-dirigeringer efter ABI- og før ACT-TransmissionDer skal sendes en ny ABI-meddelelse med data svarende til den nye rute.B.2.4. Gen-dirigering efter ACT-TransmissionB.2.4.1. Der skal bruges en REV-meddelelse til at angive gen-dirigeringer, efter at ACT-meddelelsen er blevet sendt, indtil et bilateralt aftalt tidspunkt før ETO ved det COP, der tidligere blev koordineret.NOTEDer bruges kun en REV-meddelelse, hvor den accepterende enhed ikke ændres som et resultat af modifikationen. Hvis den ændres, skal der sendes en MAC-meddelelse til den originale, accepterende enhed eller koordineringen skal annulleres verbalt.B.2.4.2. Meddelelsen skal indeholde de følgende dataelementer:- Koordineringspunkt (tidligere COP for henvisningsformål);- Estimatdata;- Rute.B.2.4.3. Meddelelser i ICAO format skal indeholde de følgende felter:3 Meddelelsestype og -nummer; meddelelseshenvisning hvis det er aftalt bilateralt;7 Luftfartøjsidentifikation. Elementer b og c skal ikke indbefattes, med mindre en revidering eller SSR-koden koordineres samtidigt;13 Afgangsflyveplads;14 Kun Element a, som indeholder det tidligere COP for henvisningsformål;16 Destination;22 Felt 14, der indeholder estimatdataene for de nye grænsekrydsningsbetingelser i felt 22-format;22 Felt 15 indeholdende den nye rute i felt 22-format.B.2.4.4. Meddelelser i ADEXP-format skal ud over meddelelsestypen og -nummeret luftfartøjsidentifikationen, afgangsflyvepladsen, destinationen, og hvis det er aftalt bilateralt meddelelseshenvisningsnummeret, indbefatte:- det tidligere COP i COP-feltet;- de nye koordineringsbetingelser COORDATA-feltet;- den nye rute i ROUTE-feltet.B.2.4.5. Ruterevideringer, der er sendt som del af dialogproceduren, skal sendes som RRV-meddelelser, med mindre det bilateralt er aftalt, at de bliver betragtet som "standard".B.3. FeltindholdB.3.1. ATS-RuterFor flyvninger, som genstyres via en alternativ ATS-Rute, har estimat- og rutefelterne samme format som for ABI- og ACT-meddelelserne.B.3.2. Direkte RuterB.3.2.1. Koordineringspunktet i estimatdataene skal være grænsekrydsningspunktet udtrykt som en pejling og en afstand fra et rapporteringspunkt. Sådanne punkter skal være aftalt bilateralt. Hvor afstanden er nul eller en flyvning vil passere inden for en bilateralt aftalt afstand fra et sådant punkt, skal kun indbefattes punktets identifikator.B.3.2.2. Når det er aftalt bilateralt, kan koordineringspunktet for en flyvning på en direkte rute udtrykkes ved henvisning til breddegrad/længdegrad.B.3.2.3. Ruten skal indeholde:- det punkt, placeret på den originale rute, fra hvilket luftfartøjet skal styres direkte; hvor en flyvning styres direkte fra en "nuværende position", kan punktet udtrykkes som en pejling og en afstand fra et rapporteringspunkt. Når de er aftalt bilateralt, kan punktet udtrykkes ved henvisning til breddegrad/længdegrad;- forkortelsen "DCT";- det punkt, til hvilket luftfartøjet skal fortsætte direkte;- den resterende del af den yderligere flyverute (FRF), hvis den er kendt af det sendende system.B.4. EksemplerB.4.1. Direkte RuterB.4.1.1. ABI- og ACT-MeddelelserB.4.1.1.1. Flyvningen (identifikation Jetset 253) skal til at krydse grænsen på en direkte, beholden kurs fra Punkt A (PTA) til Punkt C (PTC), hvorefter den vil følge ATS-rute UA134. Systemet bestemmer et COP med pejling 350, afstand 22 NM fra Punkt B (PTB).>PIC FILE= "L_2000254DA.008401.EPS">Der sendes den følgende ABI-meddelelse:- 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 UA134B.4.1.1.2. ACT-meddelelsen har det samme format som ABI-meddelelsen bortset fra, at flyvningens rute er valgfri.B.4.1.2. REV-MeddelelseFlyvning HZT2051 var tidligere genstand for den følgende ACT-meddelelse (eller ADEXP-ækvivalent):(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M>PIC FILE= "L_2000254DA.008501.EPS">Flyvningen dirigeres dernæst fra 40 NM vest for punktet RQA direkte til MYY. Det nærmest punkt på grænsekrydsningen er TDS, hvorfra afstanden til det aktuelle krydsningspunkt er 26 NM ved en pejling på 240 grader. Den følgende revideringsmeddelelse sendes:(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY)>PIC FILE= "L_2000254DA.008502.EPS">ADEXP-ækvivalentet af meddelelsen er:-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 MYYEn efterfølgende revideringsmeddelelse ville angive TDS240026 som COPet.B.4.2. Gen-dirigering via ATS-Ruter efter ACT-TransmissionB.4.2.1. ACT-MeddelelseFlyvning GKP217 er planlagt til at flyve via koordineringspunkt EMT. Den følgende ACT transmitteres:(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)>PIC FILE= "L_2000254DA.008601.EPS">Flyvningen gen-dirigeres efterfølgende via ATS-rute UM247 inden for det sendende centers luftrum til et nyt koordineringspunkt XAT, hvorefter den skal følge ATS-rute UJ124. Det accepterende center forbliver det samme. Den følgende revideringsmeddelelse sendes:(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)>PIC FILE= "L_2000254DA.008602.EPS">Flyvningen klareres dernæst til FL290, hvilket resulterer i den følgende meddelelse (som indeholder, det nye COP):(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)>PIC FILE= "L_2000254DA.008701.EPS">B.4.2.2. ADEXP-ÆkvivalenterADEXP-ækvivalenterne for de to revideringsmeddelelser er som følger: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 UJ124b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTAANNEKS C (Informativt)FASER FOR DIALOGPROCEDURE (SYSCO NIVEAU 1) - MEDDELELSESSEKVENSMeddelelsessekvens>PIC FILE= "L_2000254DA.008802.EPS">BILAG IIPRÆSENTATION AF UDVEKSLEDE ATS-DATA (ADEXP) UDGAVE 2.0(Eurocontrols dokumentreference: DPS.ET1.ST09-STD)INDHOLDSFORTEGNELSE>TABELPOSITION>ANGIVELSE AF OPHAVSRETDette dokument er frembragt af Eurocontrol Agenturet.Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt samtykke ved Eurocontrol Agenturet.FORORD1. Ansvarlig InstitutionDenne Standard er blevet udviklet og vedligeholdes af User Requirements Section (Afdelingen for Brugerkrav) i the Central Flow Management Unit (CFMU) (Enheden for Central Regulering) i the European Organisation for the Safety of Air Navigation (Den europæiske Organisation for Luftfartens Sikkerhed) Eurocontrol).2. EATCHIP-ArbejdsprogramdokumentDenne Standard er blevet frembragt som en indlevering af the EATCHIP Work Programme Dokument (EWPD) (EATCHIP Arbejdsprogramdokument), Data Processing Systems Domain (DPS), Executive Task 09.3. Godkendelse af Standarden3.1. Denne standard er udstedt i overensstemmelse med de procedurer, som er opridset i the Directives for Eurocontrol Standardisation (Direktiverne for Eurocontrolstandardisering), Ref. 000-2-93, udgave 1.0.3.2. Denne Standard trådte i kraft efter udstedelse af udgave 1.0 ved the Permanent Commission of Eurocontrol (Eurocontrols Permanente Kommission) i 1995 og havde en anvendelsesdato med effekt fra den 1. december 1997.4. Teknisk Rettelsesliste og Tekniske RettelserDenne Standard holdes under kontrol for at konstatere påkrævede rettelser eller en teknisk rettelsesliste. Proceduren for vedligeholdelsen af denne Standard er fastlagt i Anneks H i the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents (Direktiverne vedrørende ensartet udarbejdelse og præsentation af Eurocontrolstandarddokumenter).Rettelser eller tilføjelser, som påvirker de grundlæggende principper eller grammatikken for ADEXP-formatet, skal kun foretages ifølge den formelle gennemgangsprocedure, som den er tilvejebragt i the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents (Direktiverne vedrørende ensartet udarbejdelse og præsentation af Eurocontrolstandarddokumenter).Rettelser eller tilføjelser til denne Standard skal foreslås skriftligt til: CFMU Users Requirements Section (ADEXP), Eurocontrol Agency.5. Redaktionelle Konventioner5.1. Denne Standards format er i overensstemmelse med the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents (Direktiverne vedrørende ensartet udarbejdelse og præsentation af Eurocontrolstandarddokumenter), men der er imidlertid nogle afvigelser fra Direktiverne. De mindre formatmæssige dispensationer fra Direktiverne er for at undgå forvirring med notationen i Præsentation af Udvekslede ATS-Data (ADEXP).5.2. Den følgende notation er blevet anvendt til at angive hver erklærings status:- Retningsgivende Elementer anvender det operative udsagnsord "skal" og er trykt med lys, antivatekst;- Anbefalede Elementer anvender det operative udsagnsord "bør" og er trykt med lyse kursiver, hvor statusen er angivet ved præfikset Anbefaling.6. Forhold til andre StandarddokumenterDenne Standard vedrører:Eurocontrol-standarddokument for On-Line Data Interchange (OLDI)7. Status af Annekser til denne Standard>TABELPOSITION>8. Anvendt SprogDet engelske sprog er blevet anvendt til denne Standards originale tekst.1. OMFANG1.1. ADEXP er et format, ikke en protokol. Der er ikke pålagt nogen begrænsninger med hensyn til det transmissionsmedium eller de protokoller, der skal anvendes, ud over begrænsningen med hensyn til tegnsættet.1.2. ADEXP tilvejebringer et format, som primært er til brug i on-line udveksling af meddelelser, computer til computer.1.3. Dette dokument definerer principperne og syntaksreglerne for ADEXP-formatet. Det tilvejebringer denne definition udtrykt i en omfattende definition af ADEXP-felterne.1.4. ADEXP-formatet er blevet specificeret til brug inden for de følgende områder af udveksling af meddelelser (for information om dokumenthenvisning se Afsnit 2, side 3):- Flyveplanlægning: udveksling af flyveplansdata og tilknyttede meddelelser mellem det Integrerede Oprindelige Flyveplansbehandlingssystem (Integrated Initial Flight Plan Processing System) (IFPS), Lufttrafiktjenesterne (Air Traffic Services) (ATS) og Luftfartøjsoperatorer (Aircraft Operators) (AO). (Dokument Henv. 3)- Regulering af Afvikling af Lufttrafikken (Air Traffic Flow Management) (ATFM): udveksling af meddelelser mellem de Taktiske Systemer (the Tactical System) (TACT) i CFMU, AO og ATS. (Dokument Henv. 5)- Flyvekontroltjenestekoordinering: udveksling af taktiske koordineringsmeddelelser mellem Flyvekontroltjenesteenheder (Air Traffic Control Units) (ATCU). (Dokument Henv. 6)- Luftrumsregulering: udveksling af data mellem Nationale ATS-Enheder, CFMU og AO angående tilgængelighed af luftrum. (Dokument Henv. 7)- Civil/Militær Koordinering: meddelelser angående civile/militære flyvedata og luftrumskrydsningsmeddelelser. (Dokument Henv. 7)1.5. Detaljerede specifikationer angående anvendelsen og indholdet af meddelelserne inden for hver af de ovenstående grupper skal findes i de henviste dokumenter.2. HENVISNINGER2.1. De følgende dokumenter og erklæringer indeholder bestemmelser, som ved henvisning i denne tekst udgør bestemmelser for dette Eurocontrol-Standarddokument.Ved offentliggørelsestidspunktet for dette Eurocontrol-Standarddokument var de udgaver, der er angivet for de henviste dokumenter og standarder gyldige.Der skal øjeblikkeligt tages hensyn til en hvilken som helst revidering af de henviste International Civil Aviation Organisation (ICAO) Dokumenter for at revidere dette Eurocontrol-Standarddokument.Revideringer af de andre henviste dokumenter skal ikke udgøre en del af dette Eurocontrol-Standarddokument, før de formelt er bedømt og indarbejdet i dette Eurocontrol-Standarddokument.I tilfælde af konflikt mellem kravene i dette Eurocontrol-Standarddokument og indholdet i disse andre henviste dokumenter, skal dette Eurocontrol-Standarddokument have forrang.2.2. Ved offentliggørelsestidspunktet er de dokumenter, som er oplistet nedenfor, de der henvises til fra denne Standard, imidlertid inviteres brugere til at kontrollere brug- og meddelelsesfeltkompositionstabellerne i de seneste udgaver af disse dokumenter.1. ICAO Chicago Convention Annex 10 Volume I, udgave dateret november 1985;2. ICAO Chicago Convention Annex 10 Volume II, udgave dateret juli 1995;3. IFPS and RPL Dictionary of Messages, udgave 1.0, dateret marts 1998;4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, udgave dateret november 1985 (omfattende Amendment No 6 dateret november 1995);5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, udgave 6.0, virksomt marts 1998;6. Eurocontrol Standard for On-Line Data Interchange (Eurocontrolstandard for On-Line Dataudveksling), udgave 2.0, dateret oktober 1996;7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, udgave 1.0, dateret maj 1996.3. DEFINITIONER, SYMBOLER OG FORKORTELSER3.1. NotationDen notation, som er anvendt til at definere syntaksen, betegnes Backus Naur Form (BNF). BNF definerer et sæt regler, der bestemmer en klasse af tegnfølger. Klassen af tegnfølger er i dette tilfælde sættet af meddelelser, som kan kaldes en syntaktisk gyldig ADEXP-meddelelse.3.2. DefinitionerMed henblik på dette Eurocontrol-standarddokument skal de følgende definitioner gælde:Stafet (Token): Et tegn eller et sæt af tegn, der kan "uddrages" af en leksikalsk analysator på grund af tilstedeværelsen af separatorer.Symbol (Symbol): Et hvilket som helst "udtryk", som forekommer i en BNF-regel, men som ikke er et tegn.Terminalsymbol (Terminal Symbol): Et symbol, der er repræsenteret udtrykt som en sekvens af tegn.Non-Terminalsymbol (Non-Terminal Symbol): Et symbol, der er repræsenteret ved ét eller flere terminalsymboler.NOTEEt non-terminalsymbol kan også repræsenteres som en blanding af terminal- og non-terminalsymboler.3.3. Konstruktion3.3.1. BNF består af et sæt regler eller konstruktioner af formen:symbol ::= udtrykNOTER1) Notationen "::=" bør læses som "kan erstattes af"2) "Symbol" er klassificeret som non-terminalt.3) Delen "udtryk" indeholder terminal- og non-terminalsymboler.3.3.2. Terminalsymboler har en direkte repræsentation som en sekvens af tegn, hvilket af en leksikalsk analysator kan identificeres som en stafet ved anvendelse af separatorernes tilstedeværelse.3.4. KonventionerMed henblik på dette Eurocontrol-standarddokument skal de følgende konventioner gælde:- Terminalsymboler skrives med versaler. NOTEIfølge konventionen står terminalsymbolet NIL terminal for "intet terminalsymbol".Det anvendes i valg som i det følgende eksempel:a ::= b ( c | NIL ) hvor a kan erstattes af (b efterfulgt af c) eller blot af b.- non-terminalsymboler (f.eks. den venstre side af en grammatikfremstilling) er skrevet med minuskler.- Tegn og Strenglitteraler som forekommer inden i reglerne er henholdsvis omgivet af anførselstegn (') eller dobbelte anførselstegn (").Eksempler1) HYPHEN ::= '-'2) title ::= '-' "TITLE" titleidDet kan for nogle datamodelleringsapplikationer være påkrævet at skelne mellem terminal- og non-terminalsymboler ved hjælp af andet end anvendelsen af bogstaver, der er skrevet som versaler og minuskler.Hvor det end er påkrævet eksplicit at skelne mellem terminal og non-terminalsymboler ved hjælp af andet end bogstaver, der er skrevet som versaler og minuskler, anbefales det at bruge tilføjelsen af et suffiks som følger: "_at"k for et Hjælpeudtryk, "_pf" for et Primært felt og "_sf" for et Underfelt.3.5. OperatorerMed henblik på dette Eurocontrol-standarddokument skal de følgende operatorer gælde:Valgfri (Optional): Når nogle symboler lovligt kan forekomme eller ej et bestemt sted i grammatikken. De valgfri symboler er omgivet af firkantede parenteser "[" og "]".Lukning (Closure): Når en gruppe af symboler kan forekomme nul eller flere gange. Symbolerne er omgivet af bølgede parenteser "{"k og "}". Hvis der er specificeret et tal før parentesen "{" angiver dette tal det minimale antal gange, som gruppen af symboler kan forekomme. Hvis et tal er specificeret efter parentesen "}" angiver dette tal det maksimale antal gange, som gruppen af symboler kan forekomme.Valg (Choice): Når et antal af alternative symboler kan forekomme et bestemt sted i grammatikken. Valg repræsenteres ved "|".Sammenkædning (Concatenation): Repræsentation af symboler som følger sekventielt, selv om der kan komme én eller flere separatorer i midten. Der er ikke nogen eksplicit repræsentation af dette. Der er to typer:- Nøje Sammenkædning (Strict Concatenation): ved det leksikalske niveau kan regler involvere sammenkædning af terminaler, hvilket indikerer at de følger nøje efter hinanden (ingen separator i midten), i dette tilfælde skal symbolet "!" anvendes.Eksempeldatetime :: = date ! timehhmmf.eks. betyder "9912251200" den 25. december 1999, kl. 12.00.- Løs Sammenkædning (Loose Concatenation): den tilladte tilstedeværelse af separatorer mellem terminaler. Repræsentationen af Løs Sammenkædning inden i en regel kan være enten Implicit eller EksplicitEksempler1) Implicit:dct ::= '-' "DCT" point point2) Explicitdct ::= '-' !{SEP}!"DCT"!1{SEP}!point!1{SEP}!point>TABELPOSITION>NOTER1) Sammenkædning skal altid have forrang i forhold til valg. Der anvendes parenteser "(" og ")" til at forandre udtrykkets evalueringsrækkefølge.Eksempel>TABELPOSITION>2) I alle regler vil den tilladte tilstedeværelse af separatorer mellem symbolerne være implicit for at bevare læselighed.AnbefalingNår der er risiko for forvirring på grund af forrang mellem de ovenfor nævnte operatorer, anbefales det at anvende parenteser for at tydeliggøre den ønskede evalueringsrækkefølge.3.6. Forkortelser>TABELPOSITION>4. ADEXP-PRINCIPPER4.1. Tekstmæssigt, Menneskeligt Læseligt Format4.1.1. ADEXP-formatet er et tekstmæssigt format baseret på tegn.4.1.2. ADEXP-meddelelserne forbliver læselige for en menneskelig operator, hvilket muliggør, at der kan tages fat på bedre justering eller operationelle emner.4.1.3. Et tekstmæssigt format er også mere åbent og forståeligt.4.2. Identificerede og Genfindelige Felter4.2.1. En meddelelse i ADEXP-format skal bestå af felter.4.2.2. Felter skal afgrænses ved hjælp af et specielt start-på-felt-tegn, tegnet bindestreg ("-") og skal identificeres ved hjælp af specifikke nøgleord. NOTEDet bør bemærkes, at visse felter (de som syntaksmæssigt er defineret som indeholdende det leksikale emne "CHARACTER") lovligt kan indeholde et tegn "-" som en del af feltindholdet.4.2.3. Denne fremgangsmåde forbedrer formatets udvidelighed og robusthed. (Hvis et felt er fraværende eller ukorrekt, kan det springes over, og den resterende del af meddelelsen kan stadig tolkes). (Se afsnit 4.3).4.2.4. Som en anden konsekvens skal rækkefølgen af felter i en meddelelse ikke være relevant for at bestemme dens lovlighed, undtagen for det første felt (obligatorisk titelfelt (mandatory title field)), som bestemmer de tilladte felter.4.2.5. Felter kan være grundlæggende eller sammensatte.4.2.6. Bestanddelene i sammensatte felter kaldes underfelter og er defineret ved tilstedeværelsen af nøgleord, afgrænset ved hjælp af et start-på-felt-tegn.4.2.7. Grundlæggende felter er felter, der ikke indeholder underfelter.4.2.8. De grundlæggende eller sammensatte felter, som udgør en meddelelses første definitionsniveau, kaldes dens primære felter.4.2.9. Alle bestanddele af lavere niveauer er per definition underfelter, som til gengæld kan være grundlæggende eller sammensatte.4.2.10. Sammensatte felter kan være af to typer: strukturerede felter eller listefelter.4.2.11. Strukturerede felter har et foruddefineret indhold, der udelukkende udgøres af underfelter. Rækkefølgen af underfelter i et struktureret felt er IKKE betydningsfuld.4.2.12. Listefelter indledes med nøgleordet BEGIN og afsluttes med nøgleordet END. Mellem disse kan gentagne forekomster af det samme underfelt eller en kombination af underfelter forekomme. Rækkefølgen af forekomster inden i et listefelt er semantisk betydningsfuld.4.2.13. I det følgende vil udtrykket "felt" anvendes både i betydningen primært felt og/eller underfelt, undtagen når det udtrykkeligt begrænses på anden måde.4.2.14. Felter i en meddelelse kan være valgfri eller obligatoriske, alt efter hvad der er defineret i deres syntaks.4.3. Uigenkendte Felter4.3.1. Hvis der forekommer et ukendt felt i en meddelelse, skal det ignoreres.4.3.2. Hvis det system, som analyserer meddelelsen, med andre ord ikke genkender et nøgleord, vil al den tekst, der er op til det næste kendte Primære felt, som ikke er inden i et Listefelt, blive ignoreret.4.3.3. Afhængigt af meddelelsestitlen kan det ignorerede felt forårsage en afvisning af den meddelelse, der analyseres, eller ej.NOTEDet bør bemærkes, at til trods for at ADEXP er udformet til at give denne slags fleksibilitet, skal det efter skøn fra de, der er ansvarlige for at definere grænsefladekravene, for hver meddelelse angives, hvorledes systemet bør reagere på et uigenkendt felt.4.3.4. Hvis det ukendte felt er et listefelt (dette er konstateret på grundlag af nøgleordet -BEGIN), da ignoreres hele dets indhold (hen til det tilsvarende nøgleord -END).4.3.5. For at undgå en hvilken som helst tvetydighed under den genoprettelse, som følger efter overspringelse af et uigenkendt felt, er det påkrævet, at et nøgleord indleder enten et primært felt eller et underfelt.4.3.6. Dette muliggør definitionen af to slags nøgleord:- Primære nøgleord;- Undernøgleord.4.3.7. Et nøgleord skal, når først det er defineret som værende af én slags, ikke genanvendes yderligere i en anden gruppe af meddelelser som den anden slags, men med den ene undtagelse når det er inden i et listefelt. Det er muligt at have indre forekomster af primære nøgleord et hvilket som helst sted inden i et listefelt uden skabelse af tvetydighed, idet tilstedeværelsen af nøgleordet BEGIN angiver, at vi kan betragte den indre forekomst som et underfelt.Ekempler (på brug af nøgleordstyper)1) Primært Felt-RFL F3302) Underfelt: altid inden i et "Sammensat Felt"-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000Whvor -GEO er et primært, sammensat felt og -GEOID, -LATTD og LONGTD alle er underfelter.3) Listefelt-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID...-END RTEPTShvor "-BEGIN" er listefeltindikatoren og "RTEPTS" er et primært felt.NOTE"RFL" er defineret som et primært felt. Indbefatning inden i et listefelt er den eneste lejlighed, hvor et primært felt kan anvendes som et underfelt. (Se Eksempel 3 ovenfor)5. ADEXP-SYNTAKSREGLER5.1. Leksikalske Elementer5.1.1. Tegnsæt5.1.1.1. Det tegnsæt, som skal anvendes til udvekslingen af meddelelser i ADEXP-format, skal være det Internationale Alfabet Nummer 5 (IA-5) som defineret i Henvisning 1.5.1.1.2. ADEXP-formatet er udformet som et computer-til-computer-udvekslingsformat, der kan transmitteres over forskellige computernetværk eller over dedikerede computer-computer-forbindelser. Der findes yderligere et krav om at være i stand til at udveksle visse ADEXP-meddelelser, typisk relateret til Flyveplanlægning og ATFM, på Luftfartens Faste Telekommunikationsnetværk (AFTN).5.1.1.3. Meddelelser, som kan blive pålagt at blive transmitteret via AFTN, skal have deres tegnsæt begrænset til de tegn, som har en direkte korrelation mellem det Internationale Telegrafalfabet Nummer 2 (ITA-2) og IA-5 som defineret i Henvisning 1.NOTEUd over grafiske tegn og formateffektorer som defineret nedenfor definerer tegnsættet ITA-2 "signaler" (som for eksempel hulstrimler). De udgør ikke en del af det tilladte tegnsæt for ADEXP-meddelelser.5.1.1.4. De tegn, som er tilladte til brug i ADEXP-meddelelser, der kan transmitteres via AFTN, er de grafiske tegn og de formateffektorer, som er defineret nedenfor:Grafiske Tegna) bogstaver skrevet med versaler (A til Z)b) cifre (0 til 9)c) specielle grafiske tegn, som følger:1) tegnet mellemrum " "2) åbneparentes "("3) lukkeparentes ")"4) bindestreg "-"5) spørgsmålstegn "?"6) kolon ":"7) punktum "."8) komma ","9) apostrof "'"10) lighedstegn "="11) plustegn "+"12) skråstreg "/"Formateffektorera) Vognreturb) Liniefremføring5.1.2. Grundlæggende Leksikalske EmnerDe følgende grundlæggende Leksikalske Emner er defineret til brug i denne 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 ::= HYPHENNOTELIM_CHAR repræsenterer et hvilket som helst tilladt tegn bortset fra HYPHEN (bindestreg), som er reserveret til at angive begyndelsen af et felt. På den anden side repræsenterer CHARACTER et hvilket som helst tilladt element i tegnsættet.5.1.3. Linier, Separatorer og Skilletegn5.1.3.1. Opdelingen af en meddelelses tekst i linier skal ikke have nogen syntaksmæssig effekt.5.1.3.2. En separator kan være tegnet mellemrum eller en formateffektor.5.1.3.3. Felter skal kun afgrænses ved tilstedeværelsen af et start-på-felt-tegn efterfulgt af et nøgleord.5.1.3.4. Derfor kan hele meddelelsen være på én linie.5.1.4. Værdier med Fortegn5.1.4.1. Det kan være påkrævet at angive en numerisk værdi som værende negativ.5.1.4.2. Felter, som skal angive en negativ værdi, skal inden i deres syntaksdefinition udtrykkeligt angive værdien som værende en "værdi med fortegn", dvs. som værende enten positiv eller negativ. Et felt, der ikke er blevet defineret således, kan ikke repræsentere en negativ værdi.5.1.4.3. Forud for en "værdi med fortegn" skal der altid være enten bogstavet "N", som betyder negativ, eller "P", der betyder positiv. Enten "N" eller "P" kan gå forud for en værdi på nul.5.1.4.4. Syntaksen for et felt, som tillader en 'værdi med fortegn' skal være som følger:'-' "NØGLEORD" ("P" | "N") ! 1{DIGIT}Eksempel:Et felt, der kaldes 'NUMBER', og som kan indeholde en negativ værdi på ét til otte cifre (digits) ville være defineret som:'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8Derfor:-NUMBER P5 - værdi af "number" er +5-NUMBER N5 - værdi af "number" er -5-NUMBER 5 - ugyldig syntaks, enten et "P" eller et "N" skal være til stede5.1.5. Nøgleord5.1.5.1. Et nøgleord er en hvilken som helst sekvens af bogstaver skrevet med versaler eller cifre. Det indleder kun et felt, når et start-på-felt-tegn ("-") går forud for det.keyword ::= 1{ ALPHANUM }5.1.5.2. Nøgleord skal være i overensstemmelse med den følgende syntaks:'-' !{SEP}!"NØGLEORD"!1{SEP}! &lt; subfield/s or contained value &gt;dvs. at et nøgleord skal være adskilt fra dets "start-på-felt-tegn" ved hjælp af nul eller flere separatorer. Det skal efterfølges straks af én eller flere separatorer, efterfulgt af de(t) relevante underfelt(er) eller den indeholdte værdi.NOTEDet er vigtigt at bemærke, at et nøgleord og dets forudgående start-på-felt-tegn kan være adskilt af et hvilket som helst antal separatorer, heriblandt ingen.Eksempler (De følgende sekvenser indleder alle lovligt et felt)1) -TITLE IFPL2) - TITLE IFPL3) - TITLE IFPL4) -TITLE IFPL5.1.5.3. AnbefalingDet er en anbefalet praksis at undgå brugen af en separator mellem start-på-felt-tegnet "-" og det efterfølgende nøgleord.NOTE1) I eksemplerne ovenfor er den første forekomst det anbefalede valg.2) Det er også vigtigt at bemærke, at et nøgleord skal efterfølges straks af mindst én separator.5.1.5.4. Hele dokumentet igennem er sammenkædningen af emner adskilt ved hjælp af mindst én separator, som repræsenteres implicit ved hjælp af notationen for "Løs Sammenkædning" (se 3.5).NOTESom det vil blive forklaret senere, indleder nøgleord også listefelter, når nøgleordet BEGIN går forud for dem.5.1.5.5. Nøgleord skal være så korte som muligt, så længe som de stadig forbliver semantisk meningsfulde.5.1.5.6.>TABELPOSITION>5.1.5.7. For at undgå tvetydighed (dobbelt brug af det samme nøgleord med forskellige betydninger) eller redundans (forskellige nøgleord med den samme mening), opretholdes en Central Definitionstabel over Primære Felter (dvs. primære nøgleord) i denne Standard i Anneks A (A3) og en Central Definitionstabel over Underfelter (dvs. undernøgleord) opretholdes også i Anneks A (A4).5.2. Felter5.2.1. Feltsyntaksfelt ::= grundlæggende_felt | struktureret_felt | liste_feltgrundlæggende_felt ::= '-' nøgleord indeholdte_værdierindeholdte_værdier ::= {CHARACTER}liste_felt ::= '-' "BEGIN" nøgleord {underfelter} '-' "END" nøgleordstruktureret_felt ::= '-' nøgleord felt_1 felt_2 ...felt_nNOTEIkke '-', men strukturen '-' "BEGIN" går direkte forud for nøgleordet i tilfælde af listefelterne, som det vil fremgå.5.2.2. Meddelelsessammensætning Udtrykt i Felter5.2.2.1. Det første felt i en ADEXP-meddelelse skal altid være et TITLE-felt (dvs. et felt, der indledes af nøgleordet TITLE).5.2.2.2. Det resterende indhold i en meddelelse udtrykt i dets primære felter skal være defineret ved hjælp af dens TITLE.5.2.2.3. Syntaksen for meddelelser svarende til en given TITLE skal være defineret ved hjælp af de felter, de indeholder (defineret ved hjælp af deres nøgleord):- Navnet og det tilladte indhold af dens primære felter;- Navnet og det tilladte indhold af dens underfelter.5.2.3. Grundlæggende Felter5.2.3.1. Syntaksen for et grundlæggende felt skal være som følger:grundlæggende_felt ::= '-' nøgleord indeholdte _værdier5.2.3.2. "Indeholdte_værdier" definerer den tekst, som tilvejebringer feltets værdi, og kan ikke indlede noget underfelt.Eksempel på en regelarctyp ::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")NOTE1) En eksplicit ækvivalent regel for denne er:arctyp ::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").2) En eksempel på en del af en meddelelse: "-ARCTYP ZZZZ".5.2.3.3. AnbefalingHvis der er mere end to indeholdte værdier inden i et grundlæggende felt og der yderligere er behov for at udtrykke "valg" eller "valgmulighed" blandt værdierne, anbefales det at gøre feltet til et struktureret felt og at indbefatte de indeholdte værdier inden i underfelter.5.2.4. Listefelter5.2.4.1. Syntaksen for listefelter skal være som følger:listefelt ::='-' "BEGIN" nøgleord { underfelter } '-' "END" nøgleord5.2.4.2. "Underfelterne" kan være en hvilken som helst kombination af underfelter, hvis forekomst kan forekomme nul eller flere gange inden i listefeltet.5.2.4.3. Listen af underfelter, der er indeholdt i et givet listefelt, skal danne et ordnet sæt (rækkefølgen af underfelter er betydningsfuld).Eksempel på en regeladdr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"NOTER1) Dette eksempel viser, at et "addr"-felt er et listefelt, som indeholder 0 eller flere forekomster af et "fac"-underfelt (en ATS-facilitet).2) Et eksempel på en del af en meddelelse, som viser ADDR som et listefelt, der indeholder FAC-underfelter:-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.3) En eksempel på en del af en meddelelse, der viser en kombination af underfelter, er:xxx ::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".5.2.5. Strukturerede Felter5.2.5.1. Syntaksen for strukturerede felter skal være som følger:struktureret_felt ::= '-' nøgleord felt_1 felt_2...felt_n5.2.5.2. De tilladte indeholdte underfelter i et givet struktureret felt skal kun afhænge af selve det strukturerede felt.5.2.5.3. Rækkefølgen af underfelters forekomst i et struktureret felt skal ikke være betydningsfuld, hvilket tillader nemme fremtidige udvidelser (ved at tilføje nye, indeholdte underfelter).Eksempel på en regelpt::= '-' "PT" ptid [fl] [eto]NOTER1) Dette definerer "pt"- feltet som et struktureret felt, der indeholder et punkt ("ptid"-underfelt), valgfrit efterfulgt af et beregnet flyveniveau ("fl"-underfelt), valgfrit efterfulgt af et beregnet tidspunkt over det opgivne punkt ("eto"-underfelt).2) Et eksempel på en forekomst af dette felt kan for eksempel være:"-PT -PTID RMS -FL F250 -ETO 921225120000".5.2.5.4. AnbefalingOveralt hvor det fornemmes, at indholdet af et felt kan udvikles i fremtiden, er det ønskeligt at gøre det til et struktureret felt. Dette vil tillade progressive udvidelser af dets underfelter. På den anden side kan et grundlæggende felt være mere enkelt og mere velkendt at anvende, men det påtvinger en fast sekvens af elementer (værdier) med meget nedsatte muligheder for udvidelse.5.2.6. Feltet COMMENT5.2.6.1. Feltet comment (kommentar) indleder et område med fri tekst, hvor alle tilgængelige tegn, undtagen start-på-felt-tegnet ("-"), kan bruges, og som forløber indtil det næste felt.comment ::= '-' "COMMENT" { LIM_CHAR }EksempelCOMMENT DETTE ER BEGYNDELSEN PÅ ET OMRÅDE MED FRI RUTETEKST5.2.7. Feltet TITLE5.2.7.1. Det første felt i en ADEXP-meddelelse skal altid være et title-felt (titel-felt). Syntaksen af dette skal være som følger:title ::= '-' "TITLE" 1{ ALPHA }105.2.7.2. De mulige værdier for title-feltet består af sættet af ADEXP-meddelelsestitler, som er oplistet i denne Standards Anneks B.Eksempel-TITLE IFPL6. NORMALISERET BESKRIVELSE AF ADEXP-MEDDELELSER6.1. Introduktion6.1.1. De følgende afsnit definerer, hvorledes ADEXP-formatet for forskellige kategorier af meddelelser skal beskrives på en normaliseret måde inden for den foreliggende Standards ramme.6.1.2. Den Normaliserede beskrivelse involverer:- Definition af hjælpeudtryk;- Definition af hvert individuelle felts syntaks og semantik;- Definition af hvert individuelle underfelts syntaks og semantik;- Definition af hver gruppe af meddelelser med henvisning til deres definerende dokumentation.6.1.3. Denne Standard tilvejebringer ikke detaljer angående feltsammensætningen og dataindsættelsesregler for hver meddelelsestitel.6.1.4. Der bør henvises til den definerende dokumentation (Interface Specification), som er anvendelig for den relevante meddelelsesgruppe (Se afsnit 6.5.7).6.1.5. Definerende dokumentation bør på en normaliseret måde tilvejebringe den følgende information for hver meddelelsestitel:- en optegnelse over tvungne primære felter;- en optegnelse over valgfri primære felter;- dataindsættelsesreglerne for hvert felt og i særdeleshed de regler, som angår brugen af underfelter, som er defineret som valgfri i denne Standard;- de regler, der angår genoprettelse efterfølgende detekteringen af et uigenkendt felt.6.1.6. De felter, som løbende defineres og aftales blandt alle Eurocontrol-Medlemslande til brug indenfor de forskellige kategorier af meddelelser, der er defineret for anvendelse ved brug af ADEXP, er de, der er angivet i dette dokuments Anneks A.6.1.7. Et felt skal ikke bruges til noget andet formål end det, der er specificeret i dets semantiske beskrivelse.6.1.8. Et centralt indeks over reserverede felter er tilvejebragt i Anneks D. "Reserverede felter" er ikke blevet aftalt til anvendelse inden for de gældende, definerede ADEXP-meddelelser. De er typisk felter, som er blevet forudset til mulig fremtidig brug, eller de anvendes lokalt inden i nationale systemer. Formålet med at indbefatte dem i denne Standard er at hjælpe til at sikre, at felttitler er enestående og at undgå unødvendig redundans.6.2. Hjælpeudtryk6.2.1. For at tilvejebringe en læselig beskrivelse af felter er det ofte nyttigt at indføre hjælpeudtryk i grammatikbeskrivelsen.6.2.2. Hjælpeudtryk indleder ikke et felt eller et underfelt og er derfor ikke knyttet til et særligt nøgleord. De kan imidlertid forekomme i definitionen af mere end ét felt eller underfelt eller hjælpeudtryk. For eksempel kan et hjælpeudtryk som "date" ("dato") bruges i definitionen af mange felter.6.2.3. Alle nødvendige hjælpeudtryk skal indføres i alfabetisk rækkefølge og er defineret i denne Standards Anneks A (A2).6.2.4.>TABELPOSITION>6.3. Definition af Primære Felter6.3.1. Alle primære felter, der anvendes i ADEXP-meddelelser, skal være i overensstemmelse med syntaksen og semantikken som udtrykt i denne Standards Anneks A (A3).6.3.2. Hvert felts syntaks vil være angivet først, dernæst dets semantik i enkle, tydelige og utvetydige udtryk.6.3.3. Syntaksen af felter vil blive udtrykt ved brug af BNF-notation som indført i denne Standards afsnit 3.6.3.4.>TABELPOSITION>6.4. Definition af Underfelter6.4.1. Alle underfelter, der anvendes i ADEXP-meddelelser, skal være i overensstemmelse med den syntaks og semantik, som er udtrykt i denne Standards Anneks A (A4).6.4.2. Yderligere identificeres de primære felter, som et givet underfelt forekommer indeni, med henblik på krydshenvisning.6.4.3. Et underfelt kan også være et underfelt af andre underfelter, derfor gives der også en krydshenvisning til disse underfelter.6.4.4.>TABELPOSITION>6.5. Gruppe af Meddelelser6.5.1. De operationelle kategorier (grupper) af meddelelser, som er blevet defineret til anvendelse ved brug af ADEXP-formatet, er indført i denne Standards Anneks E.6.5.2. Grupperne defineres udtrykt i den operationelle beskaffenhed af de meddelelser, der udveksles, og er ofte karakteriseret ved de vedrørte systemer.6.5.3. Der skal henvises til den definerende dokumentation for hver gruppe af meddelelser.6.5.4. Der må ikke genbruges nogen titel-værdi, som allerede bruges for en gruppe af meddelelser, til nogen anden gruppe med en anderledes betydning.6.5.5. Et centralt indeks over meddelelsestitler skal opretholdes i denne Standards Anneks B.6.5.6. Der er givet en henvisning til den vedrørte gruppe for hver meddelelsestitel, som er oplistet i det centrale indeks over meddelelsestitler. Der er derfor tilvejebragt henvisning til den definerende dokumentation for hver meddelelsestitel via meddelelsesgruppen.6.5.7. Et centralt indeks over reserverede meddelelsestitler er også tilvejebragt i Anneks C. "Reserverede" meddelelsestitler er ikke blevet aftalt til brug inden for de gældende definerede grupper af meddelelser, som anvender ADEXP. De er typisk meddelelser, som er blevet forudset til mulig fremtidig brug inden for én af de definerede grupper, eller de anvendes lokalt inden i nationale systemer. Formålet med at indbefatte dem i denne Standard er at hjælpe til at sikre, at meddelelsestitler er enestående og at undgå unødvendig redundans.ANNEKS A (Retningsgivende)ADEXP-FELTDEFINITIONERA.1. IntroduktionDette Anneks tilvejebringer en fortegnelse over alle de felter: Hjælpeudtryk, Primære Felter og Underfelter, som er blevet defineret til brug i ADEXP.A.2. ADEXP-Hjælpeudtryk>TABELPOSITION>A.3. Primære Felter i ADEXP>TABELPOSITION>A.4. ADEXP Underfelter>TABELPOSITION>ANNEKS B (Retningsgivende)CENTRALT INDEKS OVER ADEXP MEDDELELSESTITLER>TABELPOSITION>ANNEKS C (Retningsgivende)CENTRALT INDEKS OVER RESERVEREDE MEDDELELSESTITLERC.1. IntroduktionDette anneks indeholder et centralt indeks over reserverede meddelelsestitler, som endnu ikke er blevet defineret til brug i ADEXP. Deres indbefattelse i dette anneks indikerer, at de enten forudses til fremtidig brug eller at de allerede er i brug, men at deres brug er begrænset til lokale systemer.C.2. FormålFormålet med at tilvejebringe en fortegnelse over titler, som endnu ikke formelt er udstedt til anvendelse i denne ADEXP-Standard, er så vidt muligt at forhindre dels frembringelsen af redundans, når som helst en ny titel er påkrævet til et særligt formål, dels frembringelsen af en titel, som allerede er i brug inden i et lokalt system.C.3. Reserverede Meddelelsestitler>TABELPOSITION>ANNEKS D (Retningsgivende)CENTRALT INDEKS OVER RESERVEREDE FELTERD.1. IntroduktionDette anneks indeholder et centralt indeks over reserverede felter: Primære, Underfelter og Hjælpeudtryk, som endnu ikke er blevet defineret til brug i ADEXP. Deres indbefattelse i dette anneks angiver, at de enten er blevet forudset til fremtidig brug eller at de allerede er i brug, men at deres anvendelse er begrænset til brug i lokale systemer.D.2. FormålFormålet med at tilvejebringe en fortegnelse over felter, som endnu ikke formelt er udstedt til brug inden i ADEXP-Standard, er så vidt muligt at forhindre dels frembringelsen af redundans, når som helst et nyt felt er påkrævet til et særligt formål, dels frembringelsen af et nøgleord, som allerede er i brug inden i et lokalt system.D.3. Reserverede Hjælpeudtryk>TABELPOSITION>D.4. Reserverede Primære Felter>TABELPOSITION>D.5. Reserverede Underfelter>TABELPOSITION>ANNEKS E (Informativt)INTRODUKTION AF MEDDELELSESGRUPPERINTRODUKTIONDette Anneks tilvejebringer en introduktion til de forskellige grupper eller kategorier af meddelelser, som kan udveksles i ADEXP. En fuldstændig fortegnelse over alle ADEXP-meddelelsestitler er givet i Anneks B.NOTEFor de nøjagtige betingelser, regler for anvendelse og feltbrug, i særdeleshed anvendelsen af valgfri felter, bør der henvises til den relevante dokumentation (f.eks. Interface Specification document) for de vedrørte systemer.E.1. FlyveplansmeddelelserE.1.1. IntroduktionMeddelelser inden for denne kategori udveksles primært mellem AO, IFPS og de relevante ATS-Enheder.E.1.2. Definition af MeddelelsestitlerMeddelelsestitler inden for denne kategori er:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.Alt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 3.E.1.3. Sammensætning af Primære FelterDetaljeret definition af meddelelsesindhold, dataindsættelsesregler og brugen af obligatoriske og valgfri felter kan findes i Dokumenthenvisning 3.EksempelFlyveplansmeddelelse-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 FTME.2. Meddelelser vedrørende Regulering af Afvikling af LufttrafikkenE.2.1. IntroduktionMeddelelser inden for denne kategori udveksles primært mellem TACT-system i Eurocontrol CFMU, Luftfartøjsoperatorer og ATS-Enheder.E.2.2. Computerassisteret Slot-allokeringsmeddelelser (CASA)Meddelelsestitler inden for denne kategori er:DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.E.2.2.1. Definition af MeddelelsestitlerAlt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 5.E.2.2.2. Sammensætning af Primære FelterDetaljeret definition af meddelelsesindhold, dataindsættelsesregler og brugen af obligatoriske og valgfri felter kan findes i Dokumenthenvisning 5.Eksempel-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945-CTOT 010 -REGUL UZZU11 -TAXITIME 0020E.2.3. InformationsmeddelelserMeddelelsestitler inden for denne kategori er:FSAE.2.3.1. Definition af MeddelelsestitlerDefinerende materiale for denne meddelelse vil være tilgængelig i Dokumenthenvisning 5.E.2.3.2. Sammensætning af Primære FelterDefinition af meddelelsesindhold, dataindsættelsesregler og brugen af obligatoriske og valgfri felter kan findes i Dokumenthenvisning 5.EksempelFørste Systemaktiveringsmeddelelse-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646E.3. ATC KoordineringsmeddelelserE.3.1. IntroduktionKoordineringsmeddelelser anvendes til at automatisere operationel koordinering og udvekslingen af information mellem ATC-enheder. Meddelelserne sikrer den rettidige levering af operationel information, der vedrører koordinering, gennem standardiserede datauddragelses- og transmissionsevner.E.3.2. Definition af MeddelelsestitlerMeddelelsestitler inden for denne kategori er:ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.Alt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 6.E.3.3. Sammensætning af Primære FelterAlt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 6.Eksempler:Meddelelse om Forslag om Overdragelse-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STNAktiveringsmeddelelse-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 HONE.4. Meddelelser vedrørende Regulering af LuftrumE.4.1. IntroduktionMeddelelser anvendt i koordineringen af luftrumsregulering. Disse meddelelser dækker reguleringen af de omgivelser, hvori trafikken bevæger sig: de permanente og betingede ruter, midlertidigt afsondrede områder, farlige og forbudte områder, osv.E.4.2. Definition af MeddelelsestitlerMeddelelsestitler inden for denne kategori er:AUP, CRAM, UUP.Alt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 7.E.4.3. Sammensætning af Primære FelterAlt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 7.EksempelMeddelelse om Betinget Rutetilgængelighed-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 LACDRE.5. Civile / Militære KoordineringsmeddelelserE.5.1. IntroduktionMeddelelser anvendt i koordineringen af flyvedata og luftrumskrydsningsanmodninger mellem civile og militære ATS-enheder.E.5.2. Definition af MeddelelsestitlerMeddelelsestitler inden for denne kategori er:ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.Alt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 7.E.5.3. Sammensætning af Primære FelterAlt definerende materiale for disse meddelelser er indeholdt i Dokumenthenvisning 7.EksempelMeddelelse om Anmodning om Krydsningsklarering-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 0051500EAcceptmeddelelse-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ-SEQNUM 012ANNEKS F (Informativt)EKSEMPLER PÅ ADEXP-MEDDELELSESFORMATDe følgende eksempler er tilvejebragt som en anskueliggørelse af ADEXP-formatet, ikke som et eksempel på indhold af meddelelsen. Den anvendte meddelelse er en IFPL og selv om den er korrekt til tidspunktet for offentliggørelse, garanteres der ikke for nøjagtighed med hensyn til feltsammensætning osv.EKSEMPEL 1 nedenfor er blevet præsenteret på en måde, som gør det letlæseligt. Dette er blevet opnået ved anvendelse af vognretur, liniefremføringer, indryk, osv. Et sådant layout udgør imidlertid ikke en del af reglerne for ADEXP-format.Præsentation af en meddelelse sker derfor efter det modtagende systems skøn. De eksempler, der er tilvejebragt som EKSEMPEL 2 og EKSEMPEL 3, er begge gyldige repræsentationer af den samme meddelelse som meddelelsen i EKSEMPEL 1.EKSEMPEL 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 UR26SAVIN 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 TALASEKSEMPEL 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 TALASEKSEMPEL 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 TALASANNEKS G (Informativt)FREMTIDIGE UDVIKLINGERG.1. IntroduktionDette anneks er tiltænkt at tilvejebringe en angivelse af den foreslåede, fremtidige udvikling ADEXP og årsagerne og målsætningen bag udviklingen.G.2. MålsætningEn af de mest betydningsfulde målsætninger i løbet af udviklingen af ADEXP var kravet om at udvikle et format, som ville gøre det muligt for et modtagende system vellykket at "ignorere" eller "springe over" et ukendt eller uigenkendt felt uden nødvendigvis at være nødt til at ugyldiggøre den meddelelse, der blev behandlet. Denne implementering kan muliggøre tilføjelsen af et nyt felt inden i en meddelelse uden kravet om at have modificeret alle modtagende systemer på forhånd efterfulgt af et meget omhyggeligt koordineret "skift". Den enorme fleksibilitet, som dette kan tilvejebringe, er én af fordelene med ADEXP-formatet.Denne målsætning opnås i den foreliggende standard gennem brugen af foruddefinerede primære felter og underfelter, indført ved et entydigt nøgleord. En leksikal analysator eller parser, som ikke "genkender" et nøgleord, anmodes om at ignorere al teksten op til det næste kendte Primære Felt, som ikke er inden i et Listefelt. Der opnås derfor genoprettelse ved niveauet af primære felter.Foreliggende og fremtidig udvikling i definitionen af nye meddelelser angiver, at et større niveau af kompleksitet er påkrævet i bestemte områder, hvor nesting af tredje og endda fjerde niveau er nødvendig. (Meddelelsen om Betinget Ruteallokering (CRAM) er et foreliggende eksempel på dette krav). ADEXP tilvejebringer i dag evnen til at bygge en meddelelse med et hvilket som helst niveau af nesting. Evnen til genoprettelse fra et uigenkendt underfelt, som måske forekommer ved det tredje eller fjerde niveau af nesting, uden risikoen for misfortolkning af data eller for at være nødt til at ugyldiggøre meddelelse eksisterer imidlertid ikke. De forslåede modifikationer, der er påkrævet til ADEXP-formatet, er udformede for at sikre, at en leksikal analysator eller parser til alle tidspunkter er i stand til at bestemme, hvor den er inden i strukturen af en meddelelse eller et individuel felt, og ved at gøre dette at gøre det muligt, at genoprettelse kan finde sted ved et hvilket som helst niveau af nesting uden faren for misfortolkning af data.G.3. ForslagFor at opnå målsætningen med genoprettelse ved et hvilket som helst niveau inden i en meddelelse er det nødvendigt, at den leksikale analysator er i stand til at bestemme slutningen af såvel som starten på et felt. Det foreliggende format muliggør kun bestemmelsen af starten på et felt ved brug af tegnet "-".Det vil i en fremtidig frigivelse af ADEXP blive foreslået at indføre brugen af parenteser til henholdsvis at angive starten på og slutningen af et felt. Den foreliggende anvendelsen af tegnet "-" til at indlede starten på et felt ville blive erstattet med tegnet "(". Slutningen af feltet, som ikke angives eksplicit i dag, ville i fremtiden blive angivet ved tegnet ")". De følgende eksempler er tiltænkt at anskueliggøre princippet.Eksempler>TABELPOSITION>BILAG IIIDOKUMENT VEDRØRENDE KONTROL MED UDVEKSLING AF FLYVEDATA (FLIGHT DATA EXCHANGE INTERFACE CONTROL DOCUMENT: FDE-ICD), UDGAVE 1.0(Eurocontrols dokumentreference: COM.ET1.ST12-STD)INDHOLDSFORTEGNELSE>TABELPOSITION>ANGIVELSE AF OPHAVSRETDette dokument er frembragt af Eurocontrol Agenturet.Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt samtykke ved Eurocontrol Agenturet.FORORD1. Ansvarlig InstitutionDette standarddokument er blevet forberedt af og vedligeholdes af Arbejdsstyrken for den Flyveplansrelaterede Udveksling af Data (FPDE) (the Flight Plan related Data Exchange (FPDE) Task Force) i Den Europæiske Organisation for Luftfartens Sikkerhed (the European Organisation for the Safety of Air Navigation) (Eurocontrol).2. EATCHIP-ArbejdsprogramdokumentDenne standard angår EATCHIP Arbejdsprogram dokumentet (EWPD), Communications Domain, Overordnet Opgave 01, Specialistopgave 12.3. Godkendelse af standarden3.1. Denne standard er udstedt i overensstemmelse med de procedurer, som er opridset i Direktiverne for Eurocontrol standardisering, Ref. 000-2-93.3.2. Denne standard træder i kraft efter tiltrædelse ved Eurocontrols Permanente Kommission og erstatter Eurocontrolstandard for On-Line Dataudveksling (OLDI), Udgave 1, Del 3: TEKNISKE KRAV (Short Term Control Document (Dokument vedrørende kortsigtet kontrol)) Ref. 001-3-92.4. Teknisk Rettelsesliste og Tekniske RettelserDenne standard holdes under kontrol for at konstatere påkrævede rettelser eller en teknisk rettelsesliste. Proceduren for vedligeholdelsen af denne standard er fastlagt i Anneks H i the Directives for the Uniform Drafting and Presentation of Eurocontrol Standard Documents (Direktiver vedrørende Ensartet Udarbejdelse og Præsentation af Eurocontrolstandarddokumenter), Ref. 000-1-92.5. Redaktionelle Konventioner5.1. Formatet af denne standard er i overensstemmelse med Direktiver vedrørende Ensartet Udarbejdelse og Præsentation af Eurocontrolstandarddokumenter.5.2. Den følgende notation er blevet anvendt til at angive hver erklærings status:- Retningsgivende erklæringer anvender det operative udsagnsord "skal" og er blevet trykt med lys, antivatekst;- Anbefalede erklæringer anvender det operative udsagnsord "bør" og er blevet trykt med lyse kursiver, hvor statusen er angivet ved præfikset Anbefaling.5.3. En hvilken som helst anden information, der betragtes som værende væsentlig for forståelse af et særligt afsnit, vil blive indarbejdet i teksten som en NOTE. En note betragtes kun som værende retningsgivende og indeholder derfor ikke specifikationer og er placeret straks efter det afsnit, som den henviser til.5.4. For at kunne præsentere Profilkravlisterne (PRLerne) i Anneks E i et velegnet format er nogle tabeller undtagelsesvis ikke indrykkede og fortsættes ikke over adskillige sider.6. Forhold til andre standarddokumenter6.1. Dette Eurocontrolstandarddokument erstatter OLDI Dokumentet vedrørende Kortsigtet Kontrol med Udveksling (ST-ICD), Del 3, Udgave 1 i OLDI-Eurocontrolstandarden [Henvisning 13].6.2. Dette Eurocontrolstandarddokument er den første del af en forventet række af Eurocontrolstandarddokumenter vedrørende Kontrol (ICDer) med Udveksling af Flyvedata.7. Status af Annekser til denne standardAnnekserne til denne standard har den følgende status:- Anneks A - Retningsgivende- Anneks B - Retningsgivende- Anneks C - Retningsgivende- Anneks D - Retningsgivende- Anneks E - Retningsgivende- Anneks F - Informativt- Anneks G - Informativt- Anneks H - Informativt8. Anvendt SprogDet engelske sprog er blevet anvendt til denne standards originale tekst.1. INTRODUKTIONDenne Eurocontrolstandard er baseret på Dokumentet vedrørende Kortsigtet Kontrol med Udveksling (the Short Term Interface Control Document), som er udviklet af den tidligere OLDI Tekniske Under-Gruppe, som arbejdede med at definere nye grænsefladestandarder for den fremtidige funktion af OLDI mellem kontrolcentraler.Tidligere OLDI-links var baseret på beskyttede protokoller såsom INTERCAUTRA eller Datenübertragungs- und Verteilungssystem (DÜV), som løber over tilegnede punkt-til-punkt-kredsløb eller begrænsede netværk, og kræver anvendelsen af specialiseret hardware og software.For det større antal nye, planlagte links virkede det som værende ønskeligt at bevæge sig mod en netværksbaseret arkitektur og tiltrædelsen af internationale telekommunikationsstandarder, hvilket muliggør, at links kan implementeres på en mere omkostningseffektiv måde ved at formindske antallet af forbindelser ved hvert Center og tillade brugen af gængs "ned-af-hylden" hardware og software.Denne Eurocontrolstandard formaliserer og udvider Dokumentet vedrørende Kortsigtet Kontrol med Udveksling (ST-ICD). ST-ICDet er blevet omarbejdet for at give en mere rigoristisk specifikation, som vil forbedre fælles funktionsdygtighed og som yderligere er velegnet til at danne grundlaget for fremtidige ICDer for at imødekomme de nye krav for Flyvedataudveksling (FDE), heriblandt bredere brug af fælles netværk og indførelsen af nye standarder for nedre lag. Denne Eurocontrolstandard tilvejebringer en minimumsmængde af funktionaliteter, som kan understøttes ved hjælp af eksisterende OLDI-implementeringer med minimale modifikationer ved brug af enten punkt-til-punkt-linkene eller pakketilsluttede netværk ifølge Comité Consultatif des Téléphones et Télégraphes (CCITT) Recommendation X.25, 1980 eller senere. Der kan være specificeret flere muligheder for anskaffelse. Dette ICD forhindrer ikke aftaler på et bilateralt grundlag i at gå videre.Installationer, som ønsker at køre andre applikationsprotokoller ud over eller i stedet for dette dokument, kan enten ansøge om rettelse af den foreliggende protokol eller adskille deres protokol ved at anvende anderledes, virtuelle kredsløb.2. OMFANG2.1. Dette Eurocontrolstandarddokument angiver en datakommunikationsgrænseflade for udvekslingen af flyverelaterede datameddelelser mellem Kontrolcentraler (ACCer). Det er fremstillet i form af en profil for en Open Systems Interconnection (OSI) (Indbyrdes Forbindelse mellem Åbne Systemer) som defineret i Den Internationale standardiseringsorganisation/International Electrotechnical Commission (ISO/IEC) Technical Report (TR) 10000-2 [Henvisning 3]. Profilen dækker både nedre lag (T-profil) og øvre lag (A-profil).2.2. Dette Eurocontrolstandarddokument kan anvendes til de følgende forløb:- understøttelse af OLDI som beskrevet i Eurocontrolstandard No 001-92 Udgave 1;- understøttelse af transmission af OLDI applikationsmeddelelser fra ACCer til Central Flow Management Unit (CFMU) systemer (Systemer af Enheder for Central Regulering).2.3. Standarden kan anvendes til forbindelse ved brug af enten:- faste punkt-til-punkt-kredsløb, eller- punkt-til-punkt-kredsløb i Public Switched Telephone Network (PSTN) (Offentligt Koblet Telefonnetværk), eller- pakkekoblede datanetværk eller indbyrdes forbundne datanetværk, som tilvejebringer en grænseflade, der er i overensstemmelse med CCITT Anbefaling X.25, 1980 eller senere.NOTER1. Indretningen mellem Flyveplansbehandlende Systemer (FPPSer) er repræsenteret i Figur 1.2. Figur 1 viser ikke potentielle backupforbindelser, såsom PSTN, for hvilke vejledning er givet i Anneks H.Figur 1Grænsefladeindretning>PIC FILE= "L_2000254DA.017801.EPS">2.4. Detaljerede sikkerhedsaspekter ved den specificerede datakommunikationsgrænseflade bemyndiges ikke ved denne standard. En grundlæggende bestemmelse er imidlertid specificeret i Anneks C.5.4 og videre vejledning kan findes i Anneks H i denne Eurocontrolstandard.3. HENVISNINGER3.1. IntroduktionDe følgende dokumenter og erklæringer indeholder bestemmelser, som ved henvisning i denne tekst udgør bestemmelser for denne Eurocontrolstandard.Ved offentliggørelsestidspunktet for denne Eurocontrolstandard var de udgaver, der er angivet for de henviste dokumenter og standarder, gyldige.Der skal øjeblikkeligt tages hensyn til en hvilken som helst revidering af de henviste International Civil Aviation Organisation (ICAO) Dokumenter (Dokumenter fra Den Internationale Civile Luftfarts Organisation) for at revidere denne Eurocontrolstandard.Revideringer af de andre henviste dokumenter skal ikke udgøre en del af denne Eurocontrolstandards bestemmelser, før de formelt er bedømt og indarbejdet i dette Eurocontrolstandarddokument.I tilfælde af konflikt mellem kravene i dette Eurocontrolstandarddokument og indholdet i disse andre henviste dokumenter, skal dette Eurocontrolstandarddokument have forrang.3.2. Henvisninger1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit.2. ISO/IEC TR 10000-1:1992, Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework (2. udgave).3. ISO/IEC TR 10000-2:1994, Information technology - Framework and taxonomy of International Standardized Profiles - Part 2: Principles and Taxonomy for OSI Profiles (3. udgave).4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks.5. CCITT Recommendation X.21bis (1988), Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems.6. ISO/IEC 7776:1994, Information technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2. udgave).7. ISO/IEC 8208:1993, Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment (3. udgave).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.9. ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model (2. udgave).10. ISO/IEC 8348:1993, Information technology - Open Systems Interconnection - Network Service Definition (1. udgave).11. ISO/IEC 8072:1994, Information technology - Open Systems Interconnection - Transport service definition (2. udgave).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 (2. udgave).13. Eurocontrol standard for On-Line Data Interchange (Eurocontrolstandard for On-Line Dataudveksling) (OLDI), No 001-92, udgave 1, 1992.14. ISO/IEC 9646-1:1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (2. udgave).15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dateret 10. maj 1996.16. Eurocontrol FDE ICD Part 1 - Reliability, Availability and Security - Technical Report version 1.0, dateret 20. april 1997.17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network.18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering plan for the ISDN era.19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-switched signalling system between public network providing data transmission service.20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks.4. DEFINITIONER, SYMBOLER OG FORKORTELSER4.1. Definitioner4.1.1. Med henblik på denne Eurocontrolstandard skal de følgende definitioner gælde:4.1.2. Profil: En mængde på én eller flere basisstandarder, og hvor den er gyldig den identifikation af valgte klasser, delmængder, valgmuligheder og parameter for disse basisstandarder, som er nødvendig for at udføre en særlig funktion [Henvisning 2].4.1.3. Profilkravliste (PRL): Profilkravene er udtrykt i form af krav med hensyn til overensstemmelse og er opstillet i et tabellisteformat [Henvisning 2].4.1.4. T-profil: Transportprofil, som tilvejebringer en Transporttjeneste i Forbindelsestilstand [Henvisning 3].4.1.5. A-profil: Applikationsprofil, der kræver en Transporttjeneste i Forbindelsestilstand [Henvisning 3].4.1.6. Meddelelse vedrørende Overensstemmelse med hensyn til Implementering af Protokoller (PICS): En meddelelse frembragt af leverandøren af et OSI-system, hvilken meddelelse angiver, hvilke egenskaber der for en given OSI-protokol er blevet implementeret [Henvisning 14].4.2. Symboler og Forkortelser>TABELPOSITION>4.3. Notationer4.3.1. Med henblik på dette Eurocontrolstandarddokument betegnes binære værdier eller en sekvens af bits som hexadecimaler ved brug af notationen "d"H, hvor bogstavet d står for et ciffer eller en sekvens af hexadecimale cifre.4.3.2. Med henblik på dette Eurocontrolstandarddokument dannes den hexadecimale repræsentation af en bitsekvens ved at tage 4 bits ad gangen fra den mest signifikante bit (MSB) til den mindst signifikante bit (LSB).NOTEEn sekvens af bits transmitteres fra MSB til LSB, med mindre det er specificeret på en anden måde i de henviste internationale standarder.4.3.3. Med henblik på dette Eurocontrolstandarddokument skal statusen af understøttelsen af træk ved en basisstandard, eller denne Eurocontrolstandard, være vist med versaler (f.eks. M, O, O.&lt; n &gt;, X). Den nøjagtige betydning af hvert statussymbol er beskrevet i Annekserne i denne Eurocontrolstandard forud for deres brug.4.3.4. Med henblik på at definere Profilen FDE ICD, Del 1, i dette Eurocontrolstandarddokument skal statusen af understøttelsen af træk ved en basisstandard eller ved denne Eurocontrolstandard være vist med minuskler (f.eks. m, o, o.&lt; n &gt;, x).NOTEResultatet er en yderligere forædling af de træk ved basisstandarderne, som er betingede, valgfri eller værdiafhængige (se E.3.1).5. TEKNISK OVERSIGT5.1. ProtokolstackNOTEProtokolstacken for denne Eurocontrolstandards profil er illustreret i Figur 2. Figuren placerer protokollerne i strukturen af the OSI Basic Reference Model (den Grundlæggende OSI Referencemodel) [Henvisning 9] ved at justere stacken med de tilsvarende OSI-lag. Imidlertid er protokolstacken en specifikation for præ-OSI-systemer og den understøtter ikke de mange funktioner, som er mulige i OSI-protokoller for de tilsvarende OSI-lag.Figur 2Protokolstack for profil>PIC FILE= "L_2000254DA.018201.EPS">5.2. Profilens StrukturNOTER1. Som vist i Figur 2, kombinerer profilstacken adskillige protokoller for nedre lag, hvoraf kun X.25 Pakkelag-Protokollen (PLP) [Henvisning 1] og dens understøttende protokoller, X.21 [Henvisning 4] og X.21bis [Henvisning 5], er defineret i eksisterende standarder fra ISO/IEC og Standarder fra International Telecommunication Union-Telecommunication Standardization Sector (ITU-T). De andre protokoller for højere lag er defineret i Annekser (Annekserne A, B og C) i dette Eurocontrolstandarddokument.2. Krav med hensyn til overensstemmelse for profilen kan henvise til disse specifikationer på lige fod med eksterne standarder og er angivet Afsnit 6. De detaljerede krav er angivet ved brug af PRLernes tabelformat (Anneks E) og PICS-proformaer (proformaer for protokoller, der er defineret i Annekserne, er givet i Anneks D). Brugen af disse PRLer og PICS-proformaer i udvikling og/eller anskaffelse er forklaret i Anneks E.5.3. Forhold til Tidligere Versioner af SpecifikationenNOTER1. Denne profil er baseret på det ST-ICD, der er udviklet af den tidligere OLDI Tekniske Under-Gruppe. De protokoller og pakkeformater, der er defineret i dette Eurocontrolstandarddokument, er en kompatibel delmængde af ST-ICDets protokoller og pakkeformater med undtagelsen af, at denne Eurocontrolstandard stiller mere detaljerede krav til anvendelsen af X.25 PLP, omfatter obligatorisk understøttelse af M-bitten og korrigerer den inkonsistente specifikation af værdien af Autoritet- og Formatidentifikatoren (AFI) i adressen for Tilgangspunktet til Netværkstjenestens (NSAP).2. Hovedændringen i stilen for dette Eurocontrolstandarddokument angår strukturen af ICD-specifikationen. Meddelelsesoverførselsprotokollen (Anneks A) er adskilt fra den understøttende T-profil. Dette vil lette brugen af andre T-profiler, når dette bliver nødvendigt for at understøtte nye FDE-krav.3. De dele af ST-ICD-specifikationen, som vedrører kontrollen af X.25 virtuelle kredsløb og afgrænsning af applikationsmeddelelser, findes nu i Meddelelsestopprotokollen (Anneks B), som udgør et minimalt transportlag for FDE.6. PROFILKRAV6.1. Krav med hensyn til Overensstemmelse6.1.1. En implementering, som påstår overensstemmelse med denne specifikation, skal opfylde de krav, der er angivet i afsnit 6.2 og 6.3 nedenfor.6.1.2. En påstand om overensstemmelse skal understøttes af en Meddelelse vedrørende Overensstemmelse med hensyn til Implementering af Protokoller som beskrevet i Anneks D og Anneks E.6.2. Krav til Øvre Lag6.2.1. En overensstemmende implementering skal tilfredsstille de krav for basisstandarden, som er angivet i Anneks A.6.2.2. En overensstemmende implementering skal tilfredsstille de restriktioner, der er angivet i Profilkravlisten i Anneks E.7.6.3. Krav til Nedre lag6.3.1. Krav til Transportlag6.3.1.1. En overensstemmende implementering skal tilfredsstille de krav for basisstandarden, som er angivet i Anneks B.6.3.1.2. En overensstemmende implementering skal tilfredsstille de restriktioner, der er angivet i Profilkravlisten i Anneks E.8.1.6.3.1.3. En overensstemmende implementering skal tilfredsstille kravet med at understøtte størrelser af Dataenheder for Transporttjeneste (TSDU) på op til og med 4097 oktetter.NOTEDen første oktet i TSDUen svarer til et felt i Meddelelsestopteksten (se A.4.10 og B.4.4) og efterlader maksimalt 4096 oktetter til brugerdata.6.3.2. Krav til Netværkslag6.3.2.1. En overensstemmende implementering skal tilfredsstille kravene i ISO/IEC 8208 [Henvisning 7] i overensstemmelse med den protokolafbildning, der er givet i Anneks C.6.3.2.2. En overensstemmende implementering skal tilfredsstille de restriktioner, der er givet Profilkravlisten i Anneks E.8.2.6.3.2.3. Hvis der understøttes operation af dataterminaludstyr (DTE)-DTE, skal en overensstemmende implementering være i stand til at konfigurere valget af funktionen af DTE eller udstyr til datakredsløbsafslutning (DCE) for DTE-DTE-operationen ved hjælp af systemadministrationsmekanismer.6.3.2.4. En overensstemmende implementering skal i begge de funktioner, der er defineret ved 6.3.2.3, være i stand til at initiere en forbindelse i overensstemmelse med specifikationen i Anneks C, dvs. at protokollen er fuldstændigt symmetrisk.NOTENogle eksisterende implementeringer baseret på ST-ICDer er måske ikke i stand til at initiere netværksforbindelser i overensstemmelse med protokollen i Anneks C.6.3.2.5. En overensstemmende implementering skal inden for en tidsperiode stemme overens med faciliteten med Ikke-standard, Default Pakkestørrelser med værdien 256 for begge transmissionsretninger.6.3.2.6. En overensstemmende implementering skal anvende NSAP-adresser som defineret i Anneks C.6.3.2.7. En overensstemmende implementering skal sætte D-bitten til 0 i CALL REQUEST-, CALL ACCEPTED- og DATA-pakker.NOTEAt sætte D=0 i CALL REQUEST- og CALL ACCEPTED-pakker har den effekt, at der ikke anvendes Leveringsbekræftelse.6.3.3. Krav til Datalinklag6.3.3.1. En overensstemmende implementering skal tilfredsstille overensstemmelseskravene i ISO/IEC 7776 [Henvisning 6] for Enkeltlagsprotokollen for the Link Access Protokol Balanced (LAPB).6.3.3.2. En overensstemmende implementering skal også tilfredsstille de restriktioner, som er givet i Profilkravlisten i Anneks E.8.3.6.3.4. Krav til Fysiske LagEn overensstemmende implementering skal tilfredsstille overensstemmelseskravene i ISO/IEC ISP 10609-9 klausul 7 [Henvisning 8].7. AFPRØVNINGSMETODERNOTER1. Der er redegjort for en fremgangsmåde til overensstemmelsesafprøvning af implementeringer af denne specifikation i Anneks F.2. Der er redegjort for anvendelsen af de PRLer og PICS-proformaer, som er tilvejebragt med denne specifikation til dokumentoverensstemmelse, i Anneks E.ANNEKS A (Retningsgivende)MEDDELELSESOVERFØRSELSPROTOKOLA.1. IntroduktionDenne specifikation definerer en protokol til at implementere en enkel meddelelsesoverførselstjeneste for applikationer, der kræver flyvedataudveksling.A.2. Implementeret TjenesteMeddelelsesoverførselsprotokollen (MT-protokollen) implementerer de følgende, ubekræftede tjenester:MT-Associate: etablerer en tilslutning til overførsel af en applikationsmeddelelse;MT-Data: overfører en applikationsmeddelelse, der består af ASCII-karakterer (Karakterer ifølge Amerikansk Standardkode for informationsudveksling);MT-Abort: afslutter en tilslutning til overførsel af en applikationsmeddelelse.A.3. Antaget TjenesteDenne Meddelelsesoverførselsprotokol antager en delmængde af Transporttjenesten i Forbindelsestilstand som defineret i ISO/IEC 8072 [Henvisning 11], såsom den, der er tilbudt af den protokol, som er defineret i Anneks B i denne Eurocontrolstandard.A.4. ProtokolspecifikationA.4.1. IntroduktionI den følgende tekst er der kun beskrevet operationen af én applikationsinitieret Meddelelseoverførselstilslutning. Yderligere forbindelser kan understøttes af den samme netværksgrænseflade ved at gentage disse procedurer for hver underliggende transportforbindelse.A.4.2. Typer af DataDette Anneks identificerer fire typer af applikationsmeddelelser, som svarer til de, der er defineret i Eurocontrolstandard No 001-3-92, Udgave 1:Systemmeddelelser: Disse meddelelser skal anvendes til link-overvågning (HEARTBEAT-meddelelse) og applikationskontrol (STARTUP- og SHUTDOWN-meddelelser).Operationelle Meddelelser: Disse meddelelser skal være forbundet med en specifik, operationel kontekst og er defineret i de Eurocontrolstandarder og Eurocontroldokumenter, som gør brug af denne standard for dataudveksling. Eurocontrolstandarddokument for On-line Dataudveksling definerer operationelle meddelelser, såsom Aktiveringsmeddelelsen (ACT), den Forudgående Grænseinformationsmeddelelse (ABI), den Logiske Kvitteringsmeddelelse (LAM).Operatormeddelelser: Disse meddelelser skal indeholde fri tekst. Deres brug skal være aftalt bilateralt. De kan for eksempel anvendes til at udveksle afprøvningsinformation eller til at informere den anden side om operatorhandlinger.Statusmeddelelser: Anvendelsen og indholdet af disse meddelelser skal være aftalt bilateralt. De kan for eksempel anvendes til at udveksle systemreguleringsinformation.NOTER1. Anvendelsen af Systemmeddelelser er del af denne protokols operation og deres format er specificeret i afsnit A.4.10.3 i dette Anneks.2. Anvendelsen og formatet af Statusmeddelelser er genstand for bilateral aftale og er ikke yderligere specificeret i denne Eurocontrolstandard.3. Protokollens tilstand bestemmer, hvilken type af meddelelse, der kan transmitteres, som specificeret i de følgende afsnit.A.4.3. Etablering af TilslutningA.4.3.1. Protokollen er indledningsvis i den uvirksomme tilstand (IDLE).A.4.3.2. Grundproceduren MT-Associate-Request udføres for at etablere en applikationstilslutning og for at bringe grundproceduren ind i DATA_READY-tilstanden. Grundproceduren skal aktiveres af både den lokale og den fjerne applikation.A.4.3.3. Det er først nødvendigt at etablere en underliggende transportforbindelse, efterfølgende de T-forbindelses-grundprocedurer, der er beskrevet i Anneks B, afsnit , hvorefter protokollen går ind i READY-tilstanden. Ved dette trin kan der kun overføres Systemmeddelelser (og muligvis Operatormeddelelser efter bilateral aftale). For at overføre en System- eller en Operatormeddelelse anvender senderen grundproceduren T-Data (se B.4.4) med meddelelsen som parameter.A.4.3.4. En STARTUP-meddelelse (systemmeddelelse) skal dernæst transmitteres, timeren Tr (se A.4.7) skal startes og protokollen går ind i tilstanden ASSOCIATION_PENDING. Hvis timeren Tr udløber, medens protokollen stadig er i denne tilstand, skal meddelelsen STARTUP transmitteres igen og timeren skal genstartes.NOTEProtokollen vil forblive i tilstanden ASSOCIATION_PENDING, indtil der modtages en STARTUP-meddelelse. Vedvarende tidsudkoblinger af timeren Tr kan signaleres lokalt.A.4.3.5. Modtagelse af STARTUP-meddelelsen skal forårsage de følgende handlinger:- i tilstanden ASSOCIATION_PENDING transmitteres en yderligere STARTUP-meddelelse, protokollen går ind i tilstanden DATA_READY og grundproceduren MT-Associate-Indication signaleres;- i en hvilken som helst anden tilstand ignoreres meddelelsen.A.4.3.6. Modtagelse af STARTUP-meddelelsen i tilstand ASSOCIATION_PENDING svarer til enten:- at den fjerne applikation har udsendt en grundprocedure MT-Associate-Request og dens Meddelelsesoverførselsprotokol er gået ind i tilstanden ASSOCIATION_PENDING, eller- at den fjerne Meddelelsesoverførselsprotokol reagerer på en tidligere modtaget STARTUP-meddelelse og er gået ind i tilstanden DATA_READY.NOTEDenne ubestemthed forekommer, fordi den samme meddelelse bruges til STARTUP og til reaktion på STARTUP. Som et resultat vil den Meddelelsesoverførselsprotokol, som først gik ind i tilstanden DATA_READY, modtage en yderligere STARTUP-meddelelse. Som specificeret i A.4.3.5, ignoreres denne STARTUP-meddelelse.A.4.3.7. Når først STARTUP-meddelelser er blevet udvekslet, etableres tilslutningen og alle de identificerede typer af meddelelser kan overføres (tilstand DATA_READY).A.4.4. DataoverførselAndre typer af meddelelser overføres på den samme måde som Systemmeddelelser ved at anvende T-Data-tjenesten med meddelelsen som parameter. Dette svarer til tjenestegrundprocedurerne MT-Data-Request og MT-Data-Indication. NOTEHver meddelelse sendes som en enkelt TSDU: der er ingen sammenkædning eller segmentering af meddelelser på dette niveau.A.4.5. Velordnet Frigivelse af TilslutningA.4.5.1. Meddelelsesoverførselstilslutningen mellem to applikationer kan frigives af en hvilken som helst af dem. Dette svarer til tjenestegrundproceduren MT-Abort-Request.A.4.5.2. De følgende handlinger skal foretages:- i tilstanden DATA_READY, skal en SHUTDOWN-meddelelse (systemmeddelelse) transmitteres, timerne Tr og Ts skal stoppes og transportforbindelsen skal frigives;- i tilstanden ASSOCIATION_PENDING, skal en SHUTDOWN-meddelelse (systemmeddelelse) transmitteres, timeren Tr skal stoppes og transportforbindelsen skal frigives;- i tilstanden READY skal transportforbindelsen frigives;- i andre henseender skal der ikke foretages nogen handling.NOTESHUTDOWN-meddelelsen er ikke en tidlig varsling - tilslutningen afsluttes øjeblikkeligt. Der er ikke nogen bekræftelse af denne meddelelse fra den anden side.A.4.5.3. Modtagelse af en SHUTDOWN-meddelelse skal forårsage de følgende handlinger:- i tilstanden DATA_READY skal timeren Ts (se A.4.7) stoppes, der signaleres MT-Abort-Indication og grænsefladen går ind i tilstanden ASSOCIATION_PENDING uden at sende en STARTUP-meddelelse;- i en hvilken som helst anden tilstand foretages der ikke nogen handling.A.4.6. Genetablering af TilslutningDen applikation, som initierede frigivelsen af tilslutningen, har, når den er klar, ansvaret for at genetablere applikationstilslutningen og et hvilket som helst lavere niveau (hvis det er nødvendigt).NOTEHvis frigivelsen af tilslutningen har resulteret i frigivelsen af den underliggende netværksforbindelse, skal der følges den tilslutningsetableringsprocedure, som er specificeret i afsnit A.4.3.A.4.7. Integritet af TilslutningA.4.7.1. Integriteten af tilslutningen mellem to applikationer tilvejebringes ved hjælp af den uvirksomme heartbeat-facilitet.A.4.7.2. Efter at være gået ind i tilstanden DATA_READY og efter at have transmitteret en hvilken som helst type af meddelelse på transportforbindelsen, skal en konfigurabel timer Ts (gen)startes. Hvis timeren Ts udløber i tilstanden DATA_READY, skal en HEARTBEAT-meddelelse (Systemmeddelelse) transmitteres (og timeren skal genstartes).A.4.7.3. Efter at være gået ind i tilstanden DATA_READY og efter at have modtaget en hvilken som helst meddelelse bortset fra en STARTUP-meddelelse på forbindelsen, skal en konfigurabel timer Tr tilsvarende (gen)startes. Hvis timeren Tr udløber i tilstanden DATA_READY, signaleres MT-Abort-Indication, transmissionen af alle meddelelser stoppes, timeren Ts stoppes og timeren Tr genstartes. Grænsefladen er i tilstanden ASSOCIATION_PENDING.NOTEApplikationerne genoprettes og gensynkroniseres ved udvekslingen af STARTUP-meddelelser (se A.4.3).A.4.8. Uordentlig Frigivelse af TilslutningA.4.8.1. Der kan være en anormal tilslutningfrigivelse, hvis:- transportforbindelsen fejler (f.eks. liniefejl, protokolfejl),- én af de to applikationer eller systemer fejler (dette kunne skyldes hardware- eller softwarefejl; i visse tilfælde kan den underliggende transportforbindelse stadig fungere).NOTEIfølge definitionen på transportprotokollen i Anneks B er der ingen ende-til-ende-transportforbindelse. Som et resultat heraf er fejl af transportforbindelsen et direkte resultat af netværksforbindelsesfejlen.A.4.8.2. Et applikations- eller systemfejl kan detekteres ved udløbet af en tidsudkobling for modtagelsen af en forventet HEARTBEAT-meddelelse (se A.4.7) fra denne applikation.A.4.9. Genoprettelse fra FejlA.4.9.1. Der skal betragtes to tilfælde:- efter en transportforbindelsesfejl;- efter en applikationsfejl.A.4.9.2. I begge tilfælde involverer retableringen den normale tilslutningsetableringsprocedure (se A.4.3), som indbefatter udveksling af STARTUP-meddelelser.NOTEI tilfældet med en fejl ved applikationsniveauet, som ikke forårsager, at den underliggende forbindelse frigives, kan det fejlede system transmittere en SHUTDOWN-meddelelse (dvs. L_shutdown, som enten er aktiveret manuelt eller som del af applikationslogikken), før der forsøges på at genstarte linket. Dette vil afkorte den fjerne applikations tidsudkobling Tr og kan resultere i en hurtigere genoprettelse med en mindre risiko for tabt data.A.4.10. MeddelelsesformaterA.4.10.1. Generel Meddelelsesstruktur>TABELPOSITION>A.4.10.2. Længde af MeddelelseskerneDer skal understøttes meddelelseskerne med længder på op til og med 4096 oktetter.A.4.10.3. Systemmeddelelsesformater>TABELPOSITION>A.4.10.4. Andre Meddelelsesformater>TABELPOSITION>NOTER1. Formatet af meddelelseskernen for Statusmeddelelser ligger uden for dette Eurocontrolstandarddokuments omfang.2. Formatet for Operationelle meddelelser er specificeret i Eurocontrolstandarder og Dokumenter, der definerer meddelelsesoverførselsapplikationer såsom On-Line Dataudveksling [Henvisning 13].3. Operatormeddelelser består af skrivelig ASCII-tekst. Hvis disse meddelelser understøttes, skal der tilvejebringes en brugergrænseflade til at vise modtagede meddelelser og til at muliggøre sammensætningen af meddelelser til transmission.A.5. Tabeller over ProtokoltilstandsovergangeA.5.1. IntroduktionTilstandstabellerne nedenfor er den definitive specifikation af protokollen. I tilfælde af uoverensstemmelse med hovedteksten ovenfor skal specifikationen nedenfor gælde.NOTEDen anvendte notation til at beskrive tilstande, hændelser, timere og handlinger er baseret på ST-ICD. Imidlertid er de følgende definitioner og resulterende handlinger blevet revideret og kan afvige fra ST-ICD.A.5.2. TilstandsdefinitionerTabel 1Tilstandsdefinitioner>TABELPOSITION>A.5.3. Mulige HændelserTabel 2Mulige Hændelser>TABELPOSITION>A.5.4. TimereTabel 3Timere>TABELPOSITION>Værdien for disse timere skal være således, at Tr = 2Ts + transittid.NOTETypiske værdier for disse timere er: Ts = 30 s, Tr = 70 s.A.5.5. TilstandsovergangstabelTabel 4Tilstandsovergange>TABELPOSITION>A.5.6. TilstandsovergangsdiagramNOTEProtokollen er beskrevet i Figur A.1 i form af et tilstandsovergangsdiagram. Diagrammet er kun retningsgivende: i tilfælde af en konflikt mellem diagrammet og tilstandstabellerne ovenfor, skal de sidstnævnte have forrang.Figur A.1Meddelelsesoverførselsprotokol: Tilstandsovergangsdiagram>PIC FILE= "L_2000254DA.019301.EPS">ANNEKS B (Retningsgivende)MEDDELELSESTOPPROTOKOLB.1. IntroduktionDette Anneks definerer Meddelelsestopprotokollen, en minimal transportprotokol, som skal bruges til applikationer såsom OLDI.B.2. Implementeret TjenesteB.2.1. Meddelelsestopprotokollen svarer til en delmængde af Transporttjenesten i Forbindelsestilstand, som defineret i ISO/IEC 8072 [Henvisning 11], omfattende de følgende servicegrundprocedurer.T-Connect: etablerer en transportforbindelse for en applikationT-Data: overfører ASCII-dataT-Disconnect: afslutter en applikations transportforbindelseB.2.2. Tjenesten understøtter ikke multipleksing, fejlgenoprettelse eller segmentering og gensamling.B.3. Antaget TjenesteProtokollen antager en pålidelig, grundlæggende netværkstjeneste som tilvejebragt ved hjælp af X.25 Pakkelag-Protokollen.NOTEDer understøttes kun en enkelt transportforbindelse på hver netværksforbindelse.B.4. ProtokolspecifikationB.4.1. Etablering af ForbindelseGrundproceduren T-Connect skal implementeres ved brug af tjenesten N-Connect i den underliggende netværkstjeneste. Der er en direkte afbildning mellem de to mængder af grundprocedurer (request (anmodning), indication (indikation)). Alternativt kan der anvendes en eksisterende netværksforbindelse (f.eks. én, som er etableret ved hjælp af systemadministrationsmekanismer).Anbefalinger1. I det sidstnævnte tilfælde ovenfor bør netværksforbindelsen genopstartes før brug. Grundproceduren N-Connect kan udsendes igen automatisk, hvis der ikke er modtaget nogen reaktion inden for et bestemt tidsrum.2. Hvis dette automatiske, gentagne forsøg implementeres, bør gentagne forsøg prøves tilnærmelsesvis hvert 15. sekund.B.4.2. Undgåelse af Redundante NetværksforbindelserHvis en grundprocedure N-Connect-Request er udstående (dvs. at der ikke er blevet signaleret nogen tilsvarende grundprocedure N-Connect-Confirm eller N-Disconnect) og der signaleres en N-Connect-Indication, da skal det indkommende netværksetableringsforsøg afvises eller frigives ved at reagere med en grundprocedure N-Disconnect-Request primitive, kun når begge de følgende betingelser er opfyldt:- den kaldende NSAP-adresse for N-Connect-Indication'en er den samme som den kaldte NSAP-adresse for den udestående N-Connect-Request;- den kaldende NSAP-adresse for den udestående N-Connect-Request er større end den kaldte NSAP-adresse for den udestående N-Connect-Request, hvor sammenligningen udføres på de bitstrenge, der dannes ved den foretrukne binære indkodning af hver NSAP-adresse som defineret i ISO/IEC 8348 Anneks A [Henvisning 10] (en streng skal betragtes som værende større end en hvilken som helst af dens regulære, oprindelige delstrenge, f.eks. '8800'H &gt;'88'H).B.4.3. Frigivelse af ForbindelseB.4.3.1. Frigivelse af Forbindelse skal anvende tjenestegrundprocedurerne N-Disconnect og N-Reset for den underliggende netværkstjeneste.B.4.3.2. For at implementere en T-Disconnect-Request, skal der signaleres en N-Disconnect-Request. Hvis etableringen af netværksforbindelser ved brug af grundprocedurer N-Connect ikke understøttes, skal netværksforbindelsen alternativt ikke frigives eksplicit.AnbefalingI det sidstnævnte tilfælde ovenfor bør netværksforbindelsen genstartes.B.4.3.3. Der skal signaleres en T-Disconnect-Indication ved modtagelsen af en hvilken som helst af de følgende netværkstjenestegrundprocedurer på en netværksforbindelse svarende til en fuldstændigt eller delvist etableret transportforbindelse:- N-Disconnect-Indication;- N-Reset-Indication.B.4.4. DataoverførselB.4.4.1. Grundproceduren T-Data skal implementeres ved brug af grundproceduren N-Data i den underliggende netværkstjeneste. Der er en direkte afbildning mellem de to mængder af grundprocedurer (request (anmodning), indication (indikation)). Afbildningen anvender en Dataenhed for Transportprotokol (TPDU), som overføres af netværkstjenesten.B.4.4.2.>TABELPOSITION>NOTER1. Denne top er defineret således, at den er identisk med den, som anvendes i INTERCAUTRA-proceduren defineret for ACT-meddelelsesudveksling mellem CAUTRA Paris, 9020D-systemet i the London Air Traffic Control Centre og Digital Communications Terminal System (DCTS) Maastricht/Karlsruhe, når der bæres de meddelelsesformater, som er defineret i Anneks A; i dette tilfælde svarer feltet "data(1)" til TYP-feltet.2. Brugen af felterne ADEST, DEST, AEMM, EMM og ADR med andre værdier end '40'H ligger uden for dette Eurocontrolstandarddokuments omfang, men kan være genstand for bilateral aftale.B.4.4.3. T-Data-tjenesten skal være begrænset til overførslen af skrivelige ASCII-karakterdata. I særdeleshed må ingen af dataoktetterne have værdien '03'H (karakteren ETX).B.4.4.4. En overensstemmende implementering skal opfylde kravet om at understøtte Dataenheder til Netværkstjeneste (NSDU) med størrelser på op til og med 4105 oktetter.B.4.4.5. En overensstemmende implementering skal forhindre sammenkædning af multiple TSDUer til en enkelt NSDU.B.4.4.6. En overensstemmende implementering skal forhindre segmentering af en enkelt TSDU til multiple NSDUer.ANNEKS C (Retningsgivende)NETVÆRKSPROTOKOLC.1. IntroduktionDette Anneks specificerer en grundlæggende Netværksprotokol som bruger X.25-pakkelag-protokollen, både til brug i punkt-til-punkt- og pakkekoblede netværksomgivelser, for at understøtte overførslen af flyvedata. Protokoldelmængden er kompatibel med den, der er defineret i versioner af [Henvisning 1] fra 1980-udgaven og senere.C.2. Tilvejebragt TjenesteC.2.1. Protokollen implementer OSI-Netværkstjenesten i forbindelsestilstand som defineret i ISO/IEC 8348 [Henvisning 10], med de følgende undtagelser:- NSAP-adresser er begrænset til formen defineret i;- der er ingen facilitet til at etablere aftale mellem Netværkstjenestens (NS) brugere og NS-udbyderen med hensyn til kvaliteten af tjeneste, som er knyttet til en netværksforbindelse;- overførsel af NS-Brugerdata under etablering og frigivelse af netværksforbindelse understøttes ikke, bortset fra de bestemmelser, som er beskrevet i C.5.3.C.2.2. De følgende NS-udbyder-valgmuligheder tilbydes ikke:- Bekræftelse af Modtagelse (Receipt Confirmation);- Udført Dataoverførsel (Expedited Data Transfer).C.3. Antaget TjenesteProtokollen antager tilvejebringelsen af en OSI-Datalinktjeneste, såsom den der tilbydes ved ISO/IEC 7776 (LAPB) [Henvisning 6].C.4. NSAP-AdresseringC.4.1. IntroduktionC.4.1.1. Strukturen af NSAP-adresserne følger den, der er defineret i ISO/IEC 8348, Anneks A, [Henvisning 10], som vist nedenfor.>PIC FILE= "L_2000254DA.019702.EPS">C.4.1.2. Komponenterne i NSAP-adressen er defineret nedenfor:IDP:: Indledende Domænedel (Initial Domain Part), omfattende AFI- og IDI-felterneAFI:: Autoritet- og Formatidentifikator (Authority and Format Identifier), ogIDI:: Indledende Domæneidentifikator (Initial Domain Identifier)DSP:: Domænespecifik Del (Domain Specific Part)C.4.2. NSAP-AdressestrukturC.4.2.1. Med henblik på dette Eurocontrolstandarddokument skal adressekomponenterne være begrænset til den følgende form.C.4.2.2. AFI-værdien 48 skal bruges og indikerer en IDI med Lokalt format med decimal, abstrakt syntaks.C.4.2.3. IDIen er nul, ifølge det Lokale format.C.4.2.4. DSPen skal bestå af 2 par decimale cifre, som følger:- det første par er en Flyvekontroltjenesteenhedsidentifikator (ATC-enhedsidentifikator), som identificerer et ATC-system og således indirekte en beliggenhed;- det andet par er en ATC-enhedsselektor, som kan anvendes til at identificere et særligt slutpunkt inden for en ATC-enhed.C.4.2.5.>TABELPOSITION>C.4.3. Tildeling af ATC-Enhedsidentifikatorer og -SelektorerC.4.3.1. Tildeling af en unik ATC-enhedsidentifikator til hvert ATC-system vil være Eurocontrols ansvar, medens ATC-enhedsselektorer vil blive tildelt af den relevante autoritet inden for ATC-Administrationen eller -Organisationen.C.4.3.2. Allokeringen af ATC-enhedsidentifikatorer til tidspunktet for udarbejdelsen af denne standard er vist i Anneks G.C.5. ProtokolspecifikationC.5.1. OversigtProtokollen er baseret på the Subnetwork-Dependent Convergence Protocol for X.25 (1980) defineret i Anneks A i ISO/IEC 8878 [Henvisning 12], med de følgende forskelle:- brugerfaciliteten Fast Select bruges ikke; imidlertid bruges den indkodning, som er defineret i Anneks A i ISO/IEC 8878 [Henvisning 12] til anvendelse med Brugerdata-feltet med udvidet format, hvilket felt er tilgængeligt med faciliteten Fast Select, her med Brugerdatafeltet med grundlæggende format i CALL REQUEST- og INCOMING CALL-pakker, idet begrænsninger på de tilladte netværkstjenesteparametre sikrer, at den indkodede information passer ind i 16 oktetter;- af de netværkstjenesteparametre for hvilke indkodninger er defineret i ISO/IEC 8878 [Henvisning 12], sendes der kun de kaldte og de kaldende NSAP-adresser (og kun i den form, som er defineret i in C.4.2) i CALL REQUEST-pakken;- Brugerdata-feltet anvendes ikke i pakkerne CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST eller CLEAR INDICATION;- de alternative procedurer til etablering og frigivelse af netværksforbindelser bruges ikke;- bekræftelse af modtagelse ved anvendelse af D-bitten understøttes ikke.NOTEDe første tre af disse begrænsninger sikrer, at al information, som vil blive overført mellem de to DTE, vil respektere begrænsningerne af Brugerdata-feltet i X.25 (1980) PLP.C.5.2. AdresseindkodningDe kaldene og de kaldte NSAP-adresser skal indkodes ved brug af den foretrukne binære indkodning, som er defineret i ISO/IEC 8348, Anneks A [Henvisning 10].C.5.3. Indkodning af BrugerdatafeltetC.5.3.1. Som et resultat af de ovenfor anførte krav skal Brugerdatafeltet i pakkerne CALL REQUEST og INCOMING CALL indkodes som illustreret nedenfor. Alle 16 oktetter skal transmitteres.Tabel 1Indkodning af Brugerdatafelt>TABELPOSITION>C.5.3.2. Andre parametre beskrevet i ISO/IEC 8878 [Henvisning 12] skal ikke anvendes.C.5.4. Behandling af Adresser i INCOMING CALL-PakkerC.5.4.1. DTE-AdresserDen kaldende DTE-adresse i en INCOMING CALL-pakke skal valideres i forhold til en lokal liste over gyldige, fjerne DTE-adresser for systemet. Hvis der registreres en gyldig adresse, skal opkaldet frigives.NOTER1. Den kaldte DTE-adresse, hvis den er til stede, i en INCOMING CALL-pakke, hvis den er til stede, kan eventuelt også valideres i forhold til en liste (typisk på ét emne) over gyldige, lokale DTE-adresser for systemet.2. Under nogle omstændigheder kan DTE-adressen for en enhed have forskellig værdi og/eller længde, når enheden fungerer som det kaldende eller det kaldte system. Derfor skal der tildeles dette emne særlig opmærksomhed, når DTE-adressevalideringsfunktionaliteten specificeres eller implementeresC.5.4.2. NSAP-AdresserDen kaldende NSAP-adresse indkodet som beskrevet ovenfor i en INCOMING CALL-pakke skal valideres i forhold til en liste af gyldige, fjerne NSAP-adresser for systemet. Hvis der detekteres en ugyldig adresse, skal opkaldet frigives.NOTEDen kaldte NSAP-adresse kan eventuelt også valideres i forhold til en liste (på typisk ét emne) over gyldige, lokale NSAP-adresser for systemet.C.5.5. DataoverførselC.5.5.1. Som beskrevet i ISO/IEC 8878, Anneks A.5.3, [Henvisning 12], overføres NSDUer i Brugerdatafeltet i en DATA-pakke.NOTESom en konsekvens er det forbudt at transmittere mere end én brugermeddelelse, såsom en OLDI-meddelelse, per X.25-pakke eller M-bit-sekvens.C.5.5.2. NSDUer, som er længere end den maksimale Brugerdata, der er tilladt for det virtuelle kredsløb, skal segmenteres og transmitteres i Brugerdatafelterne i en sekvens af DATA-pakker, hvor alle undtagen den sidste skal have både maksimal længde og M-bitmængden [dvs. en More-bit-sequence (en Flere-bit-sekvens)].C.5.5.3. Ved modtagelse skal Brugerdatafelterne i en Flere-bit-sekvens samles igen for at danne den modtagede NSDU.ANNEKS D (Retningsgivende)PROFIL-SPECIFIKKE PICS-PROFORMAERD.1. IntroduktionD.1.1. Udbyderen af en protokolimplementering, der påstås at være i overensstemmelse med specifikationerne i Annekserne A til C, skal fuldstændiggøre de følgende PICS-proformaer.NOTEFrigivelse af ophavsret for PICS-proformaer: brugere af dette Eurocontrolstandarddokument kan frit reproducere PICS-Proformaerne i dette Anneks, således at de kan bruges til det tiltænke formål, og kan yderligere offentliggøre den fuldstændige PICS.D.1.2. En fuldstændig PICS-proforma er PICSen for den pågældende implementering. PICSen er en meddelelse over hvilke egenskaber og valgmuligheder i protokollen, der er blevet implementeret.D.1.3. PICSen kan have et antal anvendelser, omfattende anvendelse:- af protokolimplementoren som en kontrolliste for at reducere risikoen for fejl med hensyn til at være i overensstemmelse med standarden ved uagtsomhed;- af udbyderen og erhververen eller den potentielle erhverver af implementeringen som en detaljeret indikation af implementeringens egenskaber, som er erklæret i forhold til et fælles forståelsesgrundlag tilvejebragt ved hjælp af standard-PICS-proformaen;- af brugeren eller den potentielle bruger af implementeringen som et grundlag for indledende at kontrollere muligheden for at samarbejde med en anden implementering (bemærk, at medens der aldrig kan garanteres for samarbejde, kan mangel på samarbejde ofte forudses ud fra inkompatible PICSer);- af en protokolafprøver som grundlag for at vælge passende afprøvninger, som påstanden om overensstemmelse for implementeringen kan vurderes i forhold til.D.2. Instruktioner til at Fuldstændiggøre PICS-ProformaerneD.2.1. Generel Struktur af PICS-ProformaerneD.2.1.1. Implementeringsidentifikationen (Implementation Identification) og Protokoloversigten (Protocol Summary) er den første del af hver PICS-proforma og skal som angivet fuldstændiggøres med den information, der er nødvendig for fuldstændigt at identificere både udbyderen og implementeringen.D.2.1.2. Hoveddelen af PICS-proformaen er et spørgeskema af fast format. Svar til emnerne i spørgeskemaet skal tilvejebringes i kolonnen længst til højre, enten ved blot at markere et svar for at angive et begrænset valg (almindeligvis Ja eller Nej) eller ved at anføre en værdi eller en mængde eller et interval af værdier.NOTER1. Hvert emne identificeres ved hjælp af en enestående emnehenvisning i den første kolonne; den anden kolonne indeholder det spørgsmål, der skal besvares; den tredje kolonne indeholder henvisningen eller henvisningerne til det materiale, som specificerer emnet i denne Eurocontrolstandard. De resterende kolonner optegner hvert emnes status (uanset om understøttelse er obligatorisk, valgfri, forbudt eller betinget) og giver plads til svarene: se også D.2.4 nedenfor.2. En udbyder kan også tilvejebringe eller kan kræves at tilvejebringe videre information kategoriseret som enten Yderligere Information eller Undtagelsesinformation. Når den er til stede skal enhver slags videre information tilvejebringes i en yderligere underklausul af emner med mærket A&lt; i &gt; eller X&lt; i &gt; respektivt med henblik på krydshenvisning, hvor &lt; i &gt; er en hvilken som helst utvetydig identifikation for emnet (f.eks. ganske enkelt et tal): der er ingen andre begrænsninger med hensyn til dens format og præsentation.D.2.1.3. En fuldstændig PICS-proforma, der indbefatter en hvilken som helst Yderligere Information og Undtagelsesinformation, skal betegnes som den pågældende implementerings Meddelelse vedrørende Overensstemmelse med hensyn til Implementering af Protokoller. NOTEHvor en implementering er i stand til at blive konfigureret på mere end én måde, kan en enkelt PICS være i stand til at beskrive alle sådanne konfigurationer. Imidlertid har udbyderen muligheden for at tilvejebringe mere end én PICS, som hver især dækker en vis delmængde af implementeringens konfigurationsegenskaber i tilfælde af, at dette udgør en lettere og mere tydelig præsentation af informationen.D.2.2. Yderligere InformationEmner i Yderligere Information tillader, at en udbyder kan tilvejebringe videre information, som er tiltænkt at medvirke til tolkningen af PICSen.NOTER1. Det tiltænkes eller forventes ikke, at der vil tilføres en stor mængde, og en PICS kan betragtes som værende fuldstændig uden nogen sådan information. Eksempler kan være en skitsering af de måder, hvorpå en (enkelt) implementering kan sættes op til at fungere i en mangfoldighed af omgivelser og konfigurationer; eller en kort logisk begrundelse (måske baseret på specifikke applikationsbehov) for udelukkelsen af træk, som, selv om de er valgfri, ikke desto mindre almindeligvis er til stede i implementeringer af denne protokol.2. Henvisninger til emner i Yderligere Information kan indføres ved siden af et hvilket som helst svar i spørgeskemaet og kan være indeholdt i emnerne i Undtagelsesinformation.D.2.3. UndtagelsesinformationD.2.3.1. Det kan lejlighedsvis ske, at en udbyder ønsker at besvare et emne med en obligatorisk eller forbudt status (efter at en hvilken som helst betingelse er blevet pålagt) på en måde, som er i konflikt med det angivne krav. Der ville ikke findes noget fortrykt svar i Understøttelseskolonnen til dette: i stedet skal udbyderen skrive det manglende svar ind i Understøttelseskolonnen, sammen med en X&lt; i &gt; henvisning til et emne i Undtagelsesinformation.D.2.3.2. Udbyderen skal tilvejebringe den passende logiske begrundelse i selve Undtagelsesemnet.D.2.3.3. En implementering, for hvilken en Undtagelse på denne måde er påkrævet, er ikke i overensstemmelse med denne specifikation.NOTEEn mulig årsag til den ovenfor beskrevne situation er, at der i standarden er blevet rapporteret en defekt, for hvilken en korrektion forventes at ændre det krav, som ikke er opfyldt ved implementeringen.D.2.4. Betingede EmnerD.2.4.1. Individuelle betingede emner er angivet ved hjælp af et betinget symbol i form af "&lt; emne &gt;: &lt; s &gt;" i Statuskolonnen, "&lt; emne &gt;" er en henvisning til et emne, som forekommer i tabellens første kolonne for et vist andet emne, og "&lt; s &gt;" er et statussymbol, M, O, O. &lt; n &gt; eller X.NOTEEn PICS-proforma kan indeholde et antal betingede emner. Disse er emner for hvilke både gyldigheden af emnet selv og dets status, hvis det anvendes (obligatorisk, valgfri eller forbudt), afhænger af, hvorvidt bestemte andre emner understøttes eller ej.D.2.4.2. Hvis det emne, som der henvises til ved hjælp af det betingede symbol, er markeret som understøttet, er det betingede emne gyldigt og dets status er givet ved hjælp af "&lt; s &gt;": understøttelseskolonnen skal fuldstændiggøres på den sædvanlige måde. I modsat fald er det betingede emne ikke relevant og svaret Ikke Gyldig (Not Applicable) (NA) skal markeres.D.2.4.3. Hvert emne, hvis henvisning bruges i et betinget symbol, er angivet ved en stjerne i Emne-kolonnen.D.3. PICS-Proforma for MeddelelsesoverførselsprotokollenD.3.1. Forkortelser og Specielle SymbolerD.3.1.1. StatussymbolerM: Obligatorisk (Mandatory)O: Valgfri (Optional)D.3.1.2. EmnehenvisningerEmner i PICS-proformaen identificeres ved hjælp af mnemotekniske emnehenvisninger. PICS-emner, der angår beslægtede funktioner, identificeres ved hjælp af emnehenvisninger, som deler det samme indledende bogstav eller par af bogstaver (i store bogstaver). Der følger en liste over disse initialer, i den rækkefølge, hvori grupperne af emner forekommer i PICS-proformaen.>TABELPOSITION>D.3.2. Identifikation>PIC FILE= "L_2000254DA.020301.EPS">D.3.3. Protokolimplementering>PIC FILE= "L_2000254DA.020401.EPS">D.4. PICS-Proforma for MeddelelsestopprotokollenD.4.1. Forkortelser og Specielle SymbolerD.4.1.1. StatussymbolerM obligatorisk (mandatory)O valgfri (optional)O.&lt; n &gt; valgfri, men understøttelse af mindst én i gruppen af muligheder, der er mærket med det samme tal &lt; n &gt;, er påkrævetX forbudt (prohibited)&lt; emne &gt;: symbol for betinget emne, afhængig af den understøttelse, der er markeret for &lt; emne &gt; (se D.2.4)D.4.1.2. ForkortelserNA ikke gyldig (not applicable)D.4.1.3. Emnehenvisninger>TABELPOSITION>D.4.2. Identifikation>PIC FILE= "L_2000254DA.020501.EPS">D.4.3. Protokolimplementering>PIC FILE= "L_2000254DA.020601.EPS">D.5. PICS-Proforma for NetværksprotokollenD.5.1. Forkortelser og Specielle SymbolerD.5.1.1. StatussymbolerM obligatorisk (mandatory)O valgfri (optional)D.5.1.2. Emnehenvisninger>TABELPOSITION>D.5.2. Identifikation>PIC FILE= "L_2000254DA.020701.EPS">D.5.3. Protokolimplementering>PIC FILE= "L_2000254DA.020702.EPS">ANNEKS E (Retningsgivende)PROFILKRAVLISTEE.1. IntroduktionE.1.1. Dette Anneks tilvejebringer PRLen for den FDE ICD profil, som er defineret i dette Eurocontrolstandarddokument. Meddelelsen vedrørende Overensstemmelse med hensyn til Implementering for en implementering, som påstår overensstemmelse med denne profil, skal genereres ifølge de nedenfor angivne instruktioner.NOTEProformaerne i dette Anneks er baseret på de proformaer, der følger med de henviste, grundlæggende standarder.E.1.2. En overensstemmende implementering skal tilfredsstille de obligatoriske overensstemmelseskrav i de basisstandarder, som der henvises til i denne profil.E.2. Funktionen af PRLen og PICS-ProformaerneDette afsnits (E.2) status er retningsgivende: det udgør ikke en bestemmelse i denne del af denne Eurocontrolstandard.- Formålet med at præsentere overensstemmelseskravene i tabelform for PRLen og PICS-proformaerne er at tilvejebringe en kontrolliste for de træk, som skal eller kan implementeres. De underliggende koncepter er defineret og beskrevet i ISO/IEC 9646-1 [Henvisning 14] (ITU-T Recommendation X.290 er ækvivalent) og ISO/IEC TR 10000-1 [Henvisning 2]- En profil kombinerer og udvælger valgene for adskillige basisstandarder for at udføre en specifik informationsbehandlende funktion. Hver basisstandard har en PICS-proforma, som oplister standardens krav. PRLen omfatter den delmængde af basisstandardens PICS-proforma-emner, som er begrænset ved profilen, sammen med de specifikke profilkrav; den definerer svar, der er påkrævet til basisstandardens PICS-proformaer for at være i overensstemmelse med profilen. Yderligere vil PRLen indeholde PICS-type-emner, som er specifikke for profilen (i det mindste vil der være et emne, som afprøver, hvorvidt alle de påkrævede PICS-proformaer er blevet fuldstændiggjort korrekt); disse emner skal være fuldstændiggjort sammen med basisstandardens PICS-proformaer. De fuldstændiggjorte proformaer udgør tilsammen profilen Meddelelse vedrørende Overensstemmelse med hensyn til Implementering (ICS - Implementation Conformance Statement).- Ifølge metodologien i ISO/IEC TR 10000-1 [Henvisning 2] skal en påstand om overensstemmelse med en profil understøttes af PICS-proformaer, der er fuldstændiggjort i overensstemmelse med PRLen. Brugen af dette materiale vil afhænge af anskaffelsesfremgangsmåden for en FDE ICD implementering.- Man kan forestille sig adskillige mulige fremgangsmåder til en FDE implementering:- Intern implementering ved en National Administration eller Organisation: PRLen bør anvendes som grundlaget for kravspecifikationen og acceptafprøvningsspecifikationen for implementeringen; den fuldstændiggjorte ICS bør frembringes som del af acceptproceduren.- Implementering af profilen ved en ordremodtager: materialet vil blive brugt og frembragt som for en intern implementering, men ordremodtageren bør tilvejebringe ICSen og behovet for dette skal være et kontraktmæssigt krav.- Implementering af profilen ved en ordremodtager som del af en totalentreprisekontrakt eller en systemintegrationskontrakt: materialet vil blive brugt og frembragt som for en intern implementering, men ordremodtageren skal pålægges at gøre dette internt såvel som at tilvejebringe den fuldstændige ICS. Overensstemmelse med profilen sikrer for eksempel, at en udbyder, som arbejder for to administrationer, ikke kan indføre hans beskyttede protokoller til at imødekomme FDE-kravet og hjælper således til at give de kontraherende administrationer kontrol.- Integration af ned-ad-hylden-produkter ind i en profilimplementering i et hvilket som helst af de foregående tilfælde: udbyderen af et produkt bør pålægges at tilvejebringe de PICS-proformaer, som er relevante for produktet, fuldstændiggjort i overensstemmelse med den her angivne PRL, og at garantere for overensstemmelse af produktet med de gyldige profilkrav; denne PICS kan dernæst videresendes som en del af profilen ICS.- Efter implementering bør ICSen bibeholdes som en del af dokumentationen for implementeringen; den kan bruges til at forudse fælles funktionsdygtighed med andre administrationer og til at identificere ændringer, der kan være nødvendige ved flytningen til andre protokoller.E.3. NotationE.3.1. De følgende notationer fra ISO/IEC TR 10000-1 [Henvisning 2] bruges i PRLen til at angive træks status:m: obligatorisk (mandatory)o: valgfri (optional):-: ikke gyldig (dvs. logisk umulig indenfor profilens omfang)x: udelukketNOTER1. Der kan bruges kombinationer af to karakterer, i hvilket tilfælde den første karakter henviser til den statiske status (implementering) og den anden til den dynamiske (brug); således betyder "mo""obligatorisk med hensyn til at blive implementeret, valgfri med hensyn til at blive brugt".2. Notationen "o.&lt; n &gt;" bruges til at vise en mængde af valgbare muligheder (dvs. at der skal implementeres mindst én i mængden) med den samme identifikator n.3. En facilitet markeret med "x" kan ikke desto mindre udgøre en del af en implementering, så længe som den ikke bruges, når implementeringen fungerer i overensstemmelse med profilen.4. Brug af træk markeret med "x" ville kræve bilateral aftale. I dette tilfælde bør trækkenes status revideres, idet de kan være af interesse for andre implementeringer.E.3.2. Der anvendes den følgende prædikatnotation:&lt; prædikat &gt;:: introducerer en gruppe af emner, som alle er betingede af &lt; prædikat &gt; (størrelsen af gruppen vises af layoutet).&lt; prædikat &gt;: introducerer et enkelt emne, som er betinget af &lt; prædikat &gt;.NOTEI begge tilfælde kan prædikatet være en profilfacilitets identifkator eller en boolsk kombination af prædikater ("¬" er symbolet for logisk negation).E.3.3. Basisstandardkrav er vist ved brug af de ækvivalente notationer skrevet med versaler (dvs. M, O, O.&lt; n &gt;, X).E.4. Instruktioner til at Fuldstændiggøre PICS-ProformaerneE.4.1. For at tilvejebringe profilen ICS skal PICS-proformaerne for de henviste basisstandarder være fuldstændiggjort sammen med de yderligere profilrelaterede PICS-emner, som er tilvejebragt i dette Anneks.E.4.2. Hvor denne profil forædler trækkene i basisstandarderne, skal de krav, der er udtrykt i denne PRL, gælde (som angivet i PRL-emner med en kolonne 'Profiltræk') for at begrænse de tilladte besvarelser i basisstandardens PICS-proformaer.E.4.3. Hvor denne profil stiller yderligere krav, skal besvarelseskolonnen for sådanne emner fuldstændiggøres. I denne kolonne skal hver besvarelse enten vælges ud fra den angivne mængde af besvarelser eller omfatte en parameterværdi eller parameterværdier eller et interval af værdier, alt efter hvad der anmodes om.E.4.4. Hvis et obligatorisk krav ikke opfyldes, skal der leveres undtagelsesinformation ved at indføre en henvisning X&lt; i &gt;, hvor &lt; i &gt; er en enestående identifkator, til en medfølgende logisk begrundelse for den manglende overensstemmelse.NOTEEn mulig årsag til en sådan undtagelse er overensstemmelse med en verserende defektrapport med hensyn til tilvejebringelsen af profilen; hvis defektrapporten accepteres, vil implementeringen dernæst blive overensstemmende.E.5. HenvisningerE.5.1. Denne profil henviser til de følgende protokolspecifikationer:- Meddelelsesoverførselsprotokol (Anneks A i dette Eurocontrolstandarddokument);- Meddelelsestopprotokol (Anneks B i dette Eurocontrolstandarddokument);- Netværksprotokol i Tilslutningstilstand ved brug af ISO/IEC 8208 (Anneks C i dette Eurocontrolstandarddokument);- ISO/IEC 7776 [Henvisning 6];- Physical Layer Standards called up by ITU-T Recommendation X.25 (1993) clause 1 (Standarder for Fysiske Lag fremlagt ved ITU-T Recommendation X.25 (1993), klausul 1) [Henvisning 1].E.5.2. Der er ingen eksplicitte PICS-proformaer for de relevante Standarder for Fysiske Lag, de interimistiske PICS-proformaer for fysiske lag i ISO/IEC ISP 10609-9, klausul A.4, [Henvisning 8] skal anvendes.E.6. Meddelelse vedrørende OverensstemmelseE.6.1. Oversigt over Overensstemmelse>PIC FILE= "L_2000254DA.021101.EPS">E.6.2. Dynamiske Krav med hensyn til Overensstemmelse>PIC FILE= "L_2000254DA.021201.EPS">E.7. Krav til Øvre LagTabel 3Meddelelsesoverførselsprotokol>TABELPOSITION>E.8. Krav til Nedre lagE.8.1. Krav til TransportlagTabel 4Meddelelsestopprotokol>TABELPOSITION>E.8.2. Krav til NetværkslagDe PRLer, der er angivet i dette afsnit, er baseret på PICS-proformaen for ISO/IEC 8208:1993 [Henvisning 7]. Indførslerne i kolonnen "Henvisninger" under "Basisstandardtræk" i de følgende tabeller er henvisninger til klausuler i den standard.E.8.2.1. Generelle Karakteristikker for DTETabel 5Generelle Karakteristikker for DTE>TABELPOSITION>E.8.2.2. Procedurer, Pakketyper og PakkeformaterTabel 6Pakkelagsfunktioner, der er uafhængige af Logiske Kanaler>TABELPOSITION>Tabel 7Opkaldsstruktur>TABELPOSITION>Tabel 8Opkaldsfrigivelse>TABELPOSITION>Tabel 9Genstart af Logiske Kanaler>TABELPOSITION>Tabel 10Fejlprocedurer>TABELPOSITION>Tabel 11Afbrydelsesoverførsel>TABELPOSITION>Tabel 12Udsendelse af Data>TABELPOSITION>Tabel 13Modtagelse af Data>TABELPOSITION>Tabel 14Bekræftelse af Levering>TABELPOSITION>E.8.2.3. Diverse Træk og ValgmulighederTabel 15Værdier af Årsag og Diagnostiske Koder>TABELPOSITION>E.8.2.4. FaciliteterTabel 16Faciliteter Sendt i CALL REQUEST-Pakker>TABELPOSITION>Tabel 17Faciliteter Sendt i CALL ACCEPT-Pakker>TABELPOSITION>Tabel 18Faciliteter Sendt i CLEAR REQUEST-Pakker>TABELPOSITION>Tabel 19Faciliteter Modtaget i INCOMING CALL-Pakker>TABELPOSITION>Tabel 20Faciliteter Modtaget i CALL CONNECTED-Pakker>TABELPOSITION>Tabel 21Faciliteter Modtaget i CLEAR INDICATION-Pakker>TABELPOSITION>Tabel 22Faciliteter Modtaget i CLEAR CONFIRMATION-Pakker>TABELPOSITION>E.8.2.5. Parameterværdier og -IntervallerTabel 23Parameterværdier og -Intervaller>TABELPOSITION>E.8.3. Krav til DatalinklagDe PRLer, der er givet i dette afsnit, er baseret på PICS-proformaen for ISO/IEC 7776:1994 [Henvisning 6]. Indførslerne i kolonnen 'Henvisninger' under 'Basisstandardtræk' for de følgende tabeller er henvisninger til klausuler i den standard.Tabel 24Datalink-Protokol>TABELPOSITION>E.8.4. Krav til Fysiske LagSe ISO/IEC TR 10609-9, klausul A.4 [Henvisning 8].ANNEKS F (Informativt)METODOLOGI TIL OVERENSSTEMMELSESAFPRØVNINGF.1. IntroduktionF.1.1. Det er vigtigt, at implementeringer af dette ICD er således, at der er et højt sikkerhedsniveau for indbyrdes operation mellem Flyvekontroltjenestecentraler (ATCCer), som arbejder sammen på tværs af grænsefladen.F.1.2. Medlemslande foretager implementeringer af grænsefladen på en måde, som efter al sandsynlighed støtter sig til anskaffelse fra forskellige kilder. For at opnå et højt niveau af sikkerhed for at sådanne implementeringer vil fungere indbyrdes, er et fælles sæt af krav til overensstemmelsesafprøvninger påkrævet for at standardisere forberedelse til afprøvning, afprøvning og præsentation af resultater.F.2. Formål og OmfangF.2.1. Dette Anneks definerer krav til overensstemmelsesafprøvningen for implementeringer af denne Eurocontrolstandard, som dette Anneks er en del af.F.2.2. Det identificerer mekanismer, hvorved sikkerhed i den angivne grænseflade etableres ved en afprøvningsproces for at validere påstanden.F.3. BibliografiDet følgende dokument er relevant i forhold til afprøvning af implementeringer af dette Eurocontrolstandarddokument:Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dateret 10. maj 1996 [Henvisning 15].F.4. Udviklingsmetoder og PraksisF.4.1. Implementeringer af ICDet kan udføres ved anvendelse af bestemte valgmuligheder og versioner af ICDet selv. For at etablere potentialet for indbyrdes samarbejde skal et Medlemsland, som implementerer grænsefladen, identificere, hvilke dele af ICDet, som understøttes, med en defineret erklæring i forhold til hvilke egenskaber og hvilke begrænsninger, hvis der er nogen, af variable parametre, der understøttes.F.4.2. En hvilken som helst implementering bør være genstand for en overensstemmelsesafprøvning som beskrevet nedenfor.F.5. AfprøvningerF.5.1. IntroduktionF.5.1.1. For at tilvejebringe sikkerhed i og understøttelse for FDE-Grænseflade inden i en ATCC for det indbyrdes samarbejde mellem samvirkende FDE-applikationer er det ønskeligt, at de hver især afprøves med hensyn til overensstemmelse i forhold til de standarder, som dette Anneks udgør en del af. En sådan afprøvning er i forhold til den ydre opførsel af Systemet Under Afprøvning (SUT) og er tiltænkt at afprøve med hensyn til indbyrdes samarbejde frem for slutsystemets servicevenlighed.F.5.1.2. Resultaterne af sådan afprøvning kan fungere som dokumentation til understøttelse for påstande om overensstemmelse, der stilles i overensstemmelse med Afsnit i denne del af dette Eurocontrolstandarddokument. PICS-proformaerne og PRLerne, der kaldes op ved denne profilspecifikation, kan anvendes som grundlag for overensstemmelsesafprøvninger; yderligere kan internationale standarder (e.g. ISO/IEC 8208 [Henvisning 7]) allerede have defineret abstrakte afprøvningsfølger, som kan bruges ved overensstemmelsesafprøvning.F.5.1.3. Hensigten med dette dokument er at sørge for et standardiseret afprøvningsprogram, som støtter sig til en standardiseret afprøvningsfølge, hvis anvendelse bør føre til sammenlignelighed af afprøvningsresultater, bred accept af sådanne afprøvningsresultater og en minimering af påkrævet overensstemmelsesafprøvning. Den standardiserede afprøvningsfølge er delvist blevet udviklet af Eurocontrol.F.5.1.4. Afprøvningen af det fuldstændige slutsystem tager form af afprøvninger af de nederste 3 lag, baseret på . Det er tilrådeligt, at afprøvning omfatter afprøvninger med hensyn til FDE-applikationen, Status-, System- og Operatormeddelelser.F.5.1.5. Hver af de nedenfor beskrevne afprøvninger bør udføres i rækkefølge. Den sidstnævnte afprøvning vil kun være vellykket, hvis de nedre lag fungerer korrekt, og det er sandsynligt, at dette vil blive konstateret med de tidligere afprøvninger.F.5.1.6. Til trods for det ovenstående er den i dette afsnit beskrevne afprøvning valgfri.F.5.2. Afprøvning af de Nedre lag (Lag 1 til 3)Som understøttelse af kravet om indbyrdes funktion mellem en hvilken som helst ATCC og dens ligestillede, anbefales det, at en hvilken som helst afprøvning skal være baseret på brugen af den afprøvningsplan, der er angivet i the Eurocontrol (Maastricht UAC Systems Division) FDE ICD Integration Test Plan. Afprøvningsprocedurer skal aftales bilateralt mellem samvirkende ATCCer.F.5.3. Afprøvning af ApplikationslagetEn række bilateralt aftalte afprøvninger bør være aftalt og udøvet mellem samvirkende ATCCer.F.5.4. CertificeringResultaterne af afprøvninger bør registreres og aftales mellem de samvirkende parter.F.5.5. NotificeringMedlemslande bør sende detaljer vedrørende resultaterne af en hvilken som helst afprøvning til Eurocontrol.ANNEKS G (Informativt)TILDELING AF ATC-ENHEDSIDENTIFIKATORERDen følgende tabel viser de ATC-enhedsidentifikatorer, der er tildelt den 22. april 1997. Eurocontrol kan tilvejebringe information med hensyn til den aktuelle tildeling af identifikatorer. Tabellen viser også hexadecimalt den binære indkodning af identifikatoren som del af den NSAP-adresseindkodning, der er defineret i Anneks C.Tabel 1ATC-Enhedsidentifikatorer>TABELPOSITION>ANNEKS H (Informativt)VEJLEDNING OM PÅLIDELIGHED, TILGÆNGELIGHED OG SIKKERHEDH.1. IntroduktionDet forventes, at ATC-applikationer såsom OLDI skal gøre brug af indbyrdes forbundne X.25 netværk og/eller offentlige eller private telekommunikationstjenester. Som en konsekvens heraf anses det for værende nødvendigt at tilvejebringe vejledning til implementeringer af FDE ICD, Del 1.H.2. Formål og OmfangH.2.1. Formålet med dette Anneks er at give vejledning om emner, der angår pålidelighed, tilgængelighed og sikkerhed.H.2.2. Omfanget af dette Anneks er baseret på to forløb. Det første forløb er en punkt-til-punkt-forbindelse over en fast linie. Det andet forløb er baseret inden for et indbyrdes forbundet X.25 netværksmiljø.NOTEFor det andet forløb tages der ikke stilling til emner, som angår den indbyrdes forbindelse af X25 netværkerne.H.2.3. Det garanteres, at implementeringer er fysisk beskyttede over for indtrængen, energisvigt og andre ydre trusler, som kan påvirke almindelig operation.H.3. BibliografiDet følgende dokument er en detaljeret, teknisk analyse, som dette Anneks er en oversigt over:Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report (Pålidelighed, Tilgængelighed og Sikkerhed - Teknisk Rapport) [Henvisning 16].H.4. Implementeringer med Fast LinieH.4.1. PålidelighedFor at øge tjenestepålidelighed skal kabler i fast linie, PSTN, Integrated Services Digital Network (ISDN), følge fysisk forskellige stier og være forbundet til forskellige telekommunikationsoperatorskiftere (dette skal være specificeret over for telekommunikationsoperatoren).H.4.2. TilgængelighedH.4.2.1. På grund af lange opsætningstider på PSTN, som er inkompatible med tidsindskrænkende applikationer, bør ISDN anvendes som et backup-medium.H.4.2.2. I tilfælde af DTE-skift, bør standby-DTEen generere en DISC-ramme for at øge hastigheden af genetableringen af forbindelse.H.4.3. SikkerhedH.4.3.1. Når ISDN bruges som backup-medium, bør den kaldte ISDN-terminaladaptor (TA) validere den opkaldendes E.164-adresse [Henvisning 18].H.4.3.2. Den kaldende DTE bør rette sig efter ITU-T Recommendation X.32 [Henvisning 17] ved at indbefatte den opkaldendes identifikation og for verifikationsinformation.H.4.4. KonfigurationseksempelFigur H.1Konfigurationseksempel med Fast Linie>PIC FILE= "L_2000254DA.023301.EPS">H.5. NetværksimplementeringH.5.1. PålidelighedFor at øge tjenestepålidelighed bør værter på et givet sted være forbundet til to DCEer, som tilhører forskellige netværksskiftere (dette krav bør være specificeret over for netværksoperatoren).H.5.2. TilgængelighedH.5.2.1. Eftersøgningsgruppefaciliteten bør anvendes for at være i stand til at tildele en enkelt X.121 adresse [Henvisning 20] til de DCE, der er placeret ved et givet sted, hvorved netværksdirigering optimeres og mislykkede opkald begrænses.H.5.2.2. I tilfælde af at andre opkaldsmekanismer er implementeret, hvilket resulterer i en anderledes opkaldt DTE adresseværdi i pakkerne CALL REQUEST og CALL ACCEPT, bør det kaldende DTE være konfigureret således, at det ikke har nogen påvirkning på opkaldets opsætning.H.5.2.3. I tilfælde af DCE-afbrydelse på grund af netværkssvigt og en anden tilgang til netværket er tilgængelig, bør genetablering af opkaldet foretages via denne anden tilgang.H.5.3. SikkerhedInden for dette Anneks' omfang er faciliteten Lukket Brugergruppe (CUG) den eneste anvendelige netværksfacilitet, der bør bruges.H.6. Generel Vejledning om Implementeringer med Fast Linie og NetværkH.6.1. PålidelighedH.6.1.1. Idet et fuldstændigt værtsskift kan være langt, er det fordelagtigt at betragte brugen af en Front End Processor (FEP) til at sørge for værtssvigt.H.6.1.2. En arkitektur baseret på en FEP kan øge tjenestepålidelighed.NOTEIndbefattelse af en transportstack i profilspecifikationen kan udvikles i konteksten af en fremtidig standard FDE ICD, Del 2.H.6.2. TilgængelighedNår et opkald er mislykket, bør det kaldende sted foretage et andet opkald ved brug af en anden X.121 adresse (hvis den er tilgængelig).H.6.3. SystemadministrationH.6.3.1. Hvor det er muligt, bør der anvendes skiftere, som automatisk skifter ved skanning af grænsefladesignalerne.H.6.3.2. En lokal fejlindikation under datatransmission kan anvendes til at igangsætte et værtsskift.H.6.3.3. Skiftet af en FEP bør generere en TC-afbrydelse for at sikre, at den lokale vært er i tilstanden IDLE (uvirksom).H.6.3.4. Ved udløb af tidsudkoblingerne på X.25 netværket eller datalinklagene bør de højestliggende lag frigives.H.6.3.5. Et totalt FEP-svigt bør generere en TC-afbrydelse.H.6.3.6. Administrationssystemet bør checke Meddelelsesoverførselsprotokollens lag (Anneks A) og kontrollere tilstandsmaskinen for at skelne mellem en fejl i Meddelelsesoverførselsprotokollen og en applikationsfejl.H.6.4. KonfigurationseksempelFigur H.2Netværkskonfigurationseksempel>PIC FILE= "L_2000254DA.023401.EPS">