2000R2082 — DA — 15.06.2002 — 001.001 — 1
Dette dokument er et dokumentationsredskab, og institutionerne påtager sig intet ansvar herfor
►B 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
(EFT L 254 af 9.10.2000, s. 1)
Ændret ved:
Tidende
nr. side dato
►M1Kommissionens forordning (EF) nr. 980/2002 af 4. juni 2002 L 150 38 8.6.2002
▼B
KOMMISSIONENS FORORDNING (EF) Nr. 2082/2000
af 6. september 2000
om vedtagelse af Eurocontrol-standarder og om ændring af
direktiv 97/15/EF om vedtagelse af Eurocontrol-standarder og om
ændring af Rådets direktiv 93/65/EØF
KOMMISSIONEN FOR DE EUROPÆISKE FÆLLESSKABER HAR —
under henvisning til traktaten om oprettelse af Det Europæiske Fælles-skab,
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 afRådets direktiv 93/65/EØF(
2), og
ud fra følgende betragtninger:
(1)Ved direktiv 97/15/EF blev der vedtaget en Eurocontrol-standard
for online dataudveksling (On-Line Data Interchange (OLDI),udgave 1.0) og en Eurocontrol-standard for præsentation afudvekslede ATS-data (Air Traffic Services Data Exchange Pres-entation (ADEXP), udgave 1.0).
(2)Eurocontrol har vedtaget nyere versioner af de to nævnte stan-darder, nemlig OLDI udgave 2.2 og ADEXP udgave 2.0, samten ny Eurocontrol-standard med titlen »Dokument vedrørendekontrol 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 nationalesystemer for lufttrafikstyring, særlig hvad angår overførsel af
flyvninger mellem flyveledelsescentre (OLDI), styring af lufttra-
fikstrømmen (ADEXP) og kommunikation mellem nationalesystemer (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 overensstem-melse med udtalelse fra det udvalg, der er nedsat i henhold til
direktiv 93/65/EØF —
UDSTEDT FØLGENDE FORORDNING:
Artikel 1
Da de obligatoriske dele af de Eurocontrol-specifikationer, der er inde-
holdt i følgende dokumenter om Eurocontrol-standarder, er nødvendige
for gennemførelsen af et integreret europæisksystem for lufttrafik sty-ring, 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 denneforordning
— Eurocontrol-standarden »Dokument vedrørende kontrol med
udveksling af flyvedata« (FDE-ICD), udgave 1.0 (Eurocontrols2000R2082 — DA — 15.06.2002 — 001.001 — 2
(1) EFT L 187 af 29.7.1993, s. 52.
(2) EFT L 95 af 10.4.1997, s. 16.
▼B
dokumentreference: COM.ET1.ST12-STD), hvis ordlyd er anført i
bilag III til denne forordning.
Artikel 2
Artikel 1 i direktiv 97/15/EF ophæves.
Artikel 3
Denne forordning træder i kraft på tredjedagen efter offentliggørelsen i
DeEuropæiskeFællesskabersTidende .
Denne forordning er bindende i alle enkeltheder og gælder umiddelbart
i hver medlemsstat.2000R2082 — DA — 15.06.2002 — 001.001 — 3
▼B
BILAGI
ON-LINE DATAUDVEKSLING (OLDI) UDGAVE 2.2
(Eurocontrols dokumentreference: DPS.ET1.ST06-STD)2000R2082 — DA — 15.06.2002 — 001.001 — 4
▼B
INDHOLDSFORTEGNELSE
OPHAVSRET
FORORD1. INTRODUKTION
1.1. Formål1.2. Omfang
2. HENVISNINGER3. DEFINITIONER, SYMBOLER OG FORKORTELSER
3.1. Definitioner3.2. Symboler og Forkortelser
4. GENERELLE KRAV
4.1. Introduktion4.2. Krav til Flyvedatabehandlingssystem4.2.1. Flyvedatabase4.2.2. Operation i Realtid4.2.3. Datakommunikationskapacitet4.2.4. Anvendelsesfunktioner4.2.5. Menneske-maskine-grænseflade (HMI)4.2.6. Initiering af Meddelelser4.2.7. Modtagelse af meddelelser4.3. Opdatering fra Overvågningsdata4.4. Optegnelse af OLDI-Data4.4.1. Indhold4.4.2. Faciliteter4.5. Tilgængelighed, Pålidelighed, Datasikkerhed og Dataintegritet4.5.1. Tilgængelighed4.5.2. Pålidelighed4.5.3. Datasikkerhed4.5.4. Dataintegritet4.6. Operationel Evaluering4.6.1. Evalueringsperiode4.6.2. Operationel Introduktionsdato
5. MEDDELELSESKATEGORIER
5.1. Generelt5.1.1. Formål5.1.2. Meddelelseskategorier5.2. Transaktionstider5.2.1. Transaktionstidsbetingelser5.3. Meddelelsesklassifikation og -Kategorisering2000R2082 — DA — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Meddelelsesklassifikation — Obligatorisk og Ekstra
5.3.2. Kategorisering af Meddelelser
6. GRUNDLÆGGENDE PROCEDURE — OBLIGATORISKE MEDDELELSER
6.1. Generelt6.1.1. Beskrivelse af Krav6.1.2. Implementering6.2. Forudgående Grænseinformationsmeddelelse (ABI)
6.2.1. Formål med ABI-Meddelelsen
6.2.2. Indhold af Meddelelse6.2.3. Regler for Anvendelse6.2.4. Kvittering for ABI6.2.5. Eksempler6.3. Aktiveringsmeddelelse (ACT)
6.3.1. Formål med ACT-Meddelelsen
6.3.2. Indhold af Meddelelse6.3.3. Regler for Anvendelse6.3.4. Kvittering for ACT6.3.5. Eksempler
6.4. LogiskKvitteringsmeddelelse (LAM)
6.4.1. Formål med LAM-Meddelelsen6.4.2. Indhold af Meddelelse6.4.3. Regler for Anvendelse6.4.4. Kvittering for LAM6.4.5. Eksempler
7. GRUNDLÆGGENDE PROCEDURE — EKSTRA MEDDELELSER
7.1. Generelt
7.1.1. Beskrivelse af Krav7.1.2. Implementering7.2. Foreløbig Aktiveringsmeddelelse (PAC)7.2.1. Formål med PAC-Meddelelsen7.2.2. Indhold af Meddelelse
7.2.3. Regler for Anvendelse
7.2.4. Kvittering for PAC7.2.5. Eksempler7.3. Revideringsmeddelelse (REV)7.3.1. Formål med REV-Meddelelsen
7.3.2. Indhold af Meddelelse
7.3.3. Regler for Anvendelse7.3.4. Kvittering for REV7.3.5. Eksempler2000R2082 — DA — 15.06.2002 — 001.001 — 6
▼B
7.4. Meddelelse for Ophævelsen af Koordinering (MAC)
7.4.1. Formål med MAC-Meddelelsen7.4.2. Indhold af Meddelelse
7.4.3. Regler for Anvendelse
7.4.4. Kvittering for MAC7.4.5. Eksempler7.5. SSR Kodetildelingsmeddelelse (COD)
7.5.1. Formål med COD-Meddelelsen
7.5.2. Indhold af Meddelelse7.5.3. Regler for Anvendelse
7.5.4. Kvittering for COD
7.5.5. Eksempler7.6. Informationsmeddelelse (INF)7.6.1. Formål med INF-Meddelelsen
7.6.2. Indhold af Meddelelse
7.6.3. Regler for Anvendelse7.6.4. Kvittering for INF
7.6.5. Eksempler
8. DIALOGPROCEDURE — KOORDINERING
8.1. Generelt8.1.1. Introduktion
8.1.2. Filteret
8.1.3. Meddelelsessekvens8.1.4. Samtidig Håndtering af Meddelelser8.1.5. Håndtering af Afvisning
8.1.6. Operationelt Timeout for Besvarelser
8.1.7. Implementering8.2. Aktiveringsmeddelelse (ACT)
8.2.1. Formål med ACT-Meddelelsen
8.2.2. Indhold af Meddelelse8.2.3. Regler for Anvendelse
8.2.4. Kvittering for ACT
8.3. Meddelelse om Henvist Aktiveringsforslag (RAP)8.3.1. Formål med RAP-Meddelelsen8.3.2. Indhold af Meddelelse
8.3.3. Regler for Anvendelse
8.3.4. Kvittering for RAP8.3.5. Operationel Besvarelse af RAP
8.3.6. Eksempler
8.4. Revideringsmeddelelse (REV)2000R2082 — DA — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Formål med REV-Meddelelsen
8.4.2. Indhold af Meddelelse8.4.3. Regler for Anvendelse
8.4.4. Kvittering for REV
8.4.5. Operationel Besvarelse af REV8.5. Meddelelse om Forslag om Henvist Revidering (RRV)8.5.1. Formål med RRV-Meddelelsen
8.5.2. Indhold af Meddelelse
8.5.3. Regler for Anvendelse8.5.4. Kvittering for RRV
8.5.5. Operationel Besvarelse af RRV
8.5.6. Eksempler8.6. Stand-by Meddelelse (SBY)8.6.1. Formål med SBY-Meddelelsen
8.6.2. Indhold af Meddelelse
8.6.3. Regler for Anvendelse8.6.4. Kvittering for SBY
8.6.5. Eksempler
8.7. Acceptmeddelelse (ACP)8.7.1. Formål med ACP-Meddelelsen
8.7.2. Indhold af Meddelelse
8.7.3. Regler for Anvendelse8.7.4. Kvittering for ACP8.7.5. Eksempler
8.8. Koordineringsmeddelelse (CDN)
8.8.1. Formål med CDN-Meddelelsen8.8.2. Indhold af Meddelelse
8.8.3. Regler for Anvendelse
8.8.4. Kvittering for CDN8.8.5. Operationel Besvarelse af CDN8.8.6. Eksempler
8.9. Meddelelse om Afvisning af Koordinering (RJC)
8.9.1. Formål med RJC-Meddelelsen8.9.2. Indhold af Meddelelse
8.9.3. Regler for Anvendelse
8.9.4. Kvittering for RJC8.9.5. Eksempler
9. DIALOGPROCEDURE — OVERFØRSEL AF KOMMUNIKATION
9.1. Generelt
9.1.1. Introduktion2000R2082 — DA — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Meddelelsessekvens
9.1.3. Overførsel af Kommunikation9.2. Overførselsinitieringsmeddelelse (TIM)
9.2.1. Formål med TIM-Meddelelsen
9.2.2. Indhold af Meddelelse9.2.3. Regler for Anvendelse9.2.4. Kvittering for TIM
9.2.5. Eksempel
9.3. Supplerende Datameddelelse (SDM)9.3.1. Formål med SDM-Meddelelsen
9.3.2. Indhold af Meddelelse
9.3.3. Regler for Anvendelse9.3.4. Kvittering for SDM9.3.5. Eksempel
9.4. Forslag om Overdragelse (HOP)
9.4.1. Formål med HOP-Meddelelsen9.4.2. Indhold af Meddelelse
9.4.3. Regler for Anvendelse
9.4.4. Kvittering for HOP9.4.5. Eksempel
9.5. Frekvensanmodningsmeddelelse (ROF)
9.5.1. Formål med ROF-Meddelelsen9.5.2. Indhold af Meddelelse9.5.3. Regler for Anvendelse
9.5.4. Kvittering for ROF
9.5.5. Eksempel9.6. Frekvensændringsmeddelelse (COF)
9.6.1. Formål med COF-Meddelelsen
9.6.2. Indhold af Meddelelse9.6.3. Regler for Anvendelse9.6.4. Kvittering for COF
9.6.5. Eksempler
9.7. Meddelelse om Manuel Overtagelse af Kommunikation (MAS)9.7.1. Formål med MAS-Meddelelsen
9.7.2. Indhold af Meddelelse
9.7.3. Regler for Anvendelse9.7.4. Kvittering for MAS
9.7.5. Eksempel
ANNEKS A (RETNINGSGIVENDE) DATAINDSÆTTELSESREGLER
ANNEKS B (RETNINGSGIVENDE) SPECIELLE RUTEBEHANDLINGSKRAV2000R2082 — DA — 15.06.2002 — 001.001 — 9
▼B
ANNEKS C (INFORMATIVT) FASER FOR DIALOGPROCEDURE (SYSCO NIVEAU 1) —
MEDDELELSESSEKVENS2000R2082 — DA — 15.06.2002 — 001.001 — 10
▼B
ANGIVELSE AF OPHAVSRET
Dette dokument er frembragt af Eurocontrol Agenturet.
Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for
repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en
hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt
samtykke ved Eurocontrol Agenturet.2000R2082 — DA — 15.06.2002 — 001.001 — 11
▼B
FORORD
1. Ansvarlig Institution
Eurocontrol-standarden for On-Line Dataudveksling (OLDI),
Udgave 2.2, er blevet forberedt af Directorate of European ATC
Harmonisation and Integration Programme (Direktoratet for
Program for Harmonisering og Integration af Lufttrafikkontrol i
Europa) (EATCHIP), Development (Udvikling) (DED), Eurocon-
trol, som også er ansvarlig for opdateringen af dokumentet. Alle
kommentarer eller forespørgsler bør henvendes til Director
General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for
Division DED-2's opmærksomhed.
2. Forhold til EATCHIP Arbejdsprogramdokumentet
Denne standard udgør en indlevering under Specialist Task
DPS.ET1.ST06 i EATCHIP's domæne ATM Data Processing
Systems (Databehandlingssystemer) (DPS) som specificeret i
EATCHIP Arbejdsprogramdokument (EWPD), Udgave 2.0,
dateret 30. september 94.
3. Godkendelse og Rettelser
Denne standard har været genstand for den følgende godkendel-
sesprocedure 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 korrespondancepro-
cedure;
— Konsultation af alle ECAC-Lande gennem deres repræsen-
tanter 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 Flyvekontroltje-
nesteprocedurer (ATC-procedurer) kan rettelser og tilføjelser
foreslås gennem ODT for diskussion og mulig godkendelse.
Kravene vil enten blive indarbejdet som en rettelse eller som en
yderligere udgave af dokumentet for endossering og godkendelse
i overensstemmelse med de specificerede procedurer.
4. Redaktionel Praksis
Den følgende praksis er blevet anvendt for at angive hver erklær-
ings 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 opera-
tive udsagnsord »skal« anvendt og for Anbefalede Elementer er
det operative udsagnsord »bør« anvendt.
Noter er skrevet med lys, kursiv skrift indledt med præfikset
»NOTE«.
5. Forhold til Udgave 1 af Eurocontrol-standarden for On-Line
Datauudveksling
Dette dokument erstatter Delene 1 og 2 af Udgave 1 af Eurocon-
trol- 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.2000R2082 — DA — 15.06.2002 — 001.001 — 12
▼B
6. Signifikante Ændringer i forhold til Udgave 1
Det følgende er de mest signifikante ændringer af og tilføjelser til
Udgave 1:
1. Indarbejdelse af de følgende ekstra (ikke-obligatoriske)
meddelelser med hensyn til den grundlæggende procedure:
— Meddelelser om Ophævelsen af Koordinering (MAC);
— Kodetildelingsmeddelelse (COD) for Sekundær Radar
(SSR);
— Informationsmeddelelse (INF).
2. Definition af indhold og format af meddelelser til at under-
stø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ør-
selsbetingelser 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 Udvek-
slede 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. Medde-
lelser 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 HistoriskOversigt.
E Implementeringsplan.
F Indvigelse ved Lande.G Retningslinier for Implementering.H Retningslinier for Evaluering af OLDI.
6. Adskillelse af Del 3 — Tekniske Krav — fra anvendelsesspe-
cifikationen.
7. Forhold til Andre Dokumenter
Dette dokument henviser til anvendelsen af to typer af feltformat
i udarbejdelsen af meddelelser; disse er ICAO og ADEXP.
ICAO-feltformater er beskrevet i Henvisning 1. I tilfælde af at
Henvisning 1 erstattes af et andet dokument, skal definition af
ICAO-felttyper være som i det dokument.
Formats for ADEXP-felter er beskrevet i Henvisning 2.
NOTE Henviste dokumenter er oplistet i Afsnit 2.
8. Sprog
Det engelske sprog er blevet anvendt ved udfærdigelsen af dette
dokuments original.2000R2082 — DA — 15.06.2002 — 001.001 — 13
▼B
1. INTRODUKTION
1.1. Formål
1.1.1. Flyvninger, der er forsynet med en ATC-tjeneste, overføres fra én
ATC-enhed til den næste på en måde, som er udformet til at sikre
fuldstændig sikkerhed. For at opnå dette formål er det en stan-
dardprocedure, 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 forbin-
delser mellem Flyvedatabehandlingssystemer (FDPSer) ved
ACCer med henblikpå at erstatte sådanne verbale »estimater«,
hvilket betegnes On-Line Data Interchange (On-Line Dataudveks-
ling) (OLDI), begyndte i Europa i de tidlige 1980'ere.
1.1.3. For at lette implementering blev fælles regler og meddelelsesfor-
mater 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 over-
ensstemmelse med EATCHIPs krav.
1.2. Omfang
1.2.1. Dette dokument specificerer de faciliteter og meddelelser, som
skal tilvejebringes mellem de FDPSer, der betjener ATC-enheder,
med henblikpå 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 dataudveks-
ling til dette formål.
1.2.3. Denne standard kan anvendes mellem medlemslandene af Euro-
control til internationale OLDI-faciliteter mellem enheder, der
leverer en ATC-tjeneste.
1.2.4. Anbefaling Det anbefales, at lande ved Den Europæiske Civile
Luftfartskonference (European Civil Aviation Conference
(ECAC)) vil anvende denne standard til:
—internationale OLDI-faciliteter mellem enheder, der leverer
enATC-tjeneste indenforECAC-området;
—OLDI-facilitetermellemenheder,derlevererenATC-tjeneste,
hvilke enhedererinterne idetpågældendeland .
2. HENVISNINGER
2.1. De følgende Dokumenter indholder bestemmelser, som ved
henvisning i denne tekst udgør bestemmelser for dette Eurocon-
trol-standarddokument.
Ved tidspunktet for offentliggørelse af dette Eurocontrol-stan-
darddokument var de anførte udgaver af de henviste dokumenter
gyldige.
Der skal øjeblikkeligt tages hensyn til en hvilken som helst revi-
dering 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-stan-
darddokument.
I tilfælde af konflikt mellem kravene i dette Eurocontrol-stan-
darddokument og indholdet i disse andre henviste dokumenter,
skal dette Eurocontrol-standarddokument have forrang.2000R2082 — DA — 15.06.2002 — 001.001 — 14
▼B
2.2. Der henvises til følgende dokumenter i dette standarddokument:
1. Procedures for Air Navigation Services — Rules of the Air &
Air Traffic Services, ICAO Document 4444, Trettende udgave,
dateret 7 nov. 1996, som det er rettet.
2. Udgave 2.0 af Eurocontrol Standard document ATS Data
Exchange Presentation (Eurocontrol-standarddokument for
Præsentation af udvekslede ATS-data) (ADEXP), henvisning
DPS-ET1-ST09-STD-01-00, dateret juni 1998.
3. DEFINITIONER, SYMBOLER OG FORKORTELSER
3.1. Definitioner
Med henblikpå denne Eurocontrol-standard sk al de følgende
definitioner gælde.
3.1.1. AccepterendeEnhed(AcceptingUnit) : 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 middel-
vandstand.
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 flyveplansind-
førsel i databasen.
3.1.8. ATC-Enhed(ATCUnit) : En enhed, der sørger for en flyvekontrol-
tjeneste.
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 ansvarligheds-
områder, med formelt at advisere hinanden om den planlagte
passage af flyvninger på tværs af grænsen for at sikre flysik-
kerhed gennem konsistens af tilsigtede aktioner.
3.1.13. Koordineringsmeddelelse (Co-ordination Message) : En fællesbe-
tegnelse, som henviser til en meddelelse, der anvendes til at
udføre ATC-koordinering. Disse indeholder CDNen, som er en
specifikmeddelelse besk revet i afsnit 8.8.
3.1.14. Koordineringsfase(Co-ordinationPhase) : 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 koordineringsmed-
delelser.2000R2082 — DA — 15.06.2002 — 001.001 — 15
▼B
3.1.16. Korrelation (Correlation) : Den proces, der er baseret på define-
rede kriteria med hensyn til at forbinde flyveplandata og
radarsporet for den samme flyvning, almindeligvis for præsenta-
tion 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-stan-
dard 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åde-
radarkontroltjeneste.
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 luft-
trafiktjenesteenheder i forbindelse med et luftfartøjs tiltænkte
flyvning eller en del af dets tiltænkte flyvning. Endvidere infor-
mation udledt fra flyveplanen for en specifikflyvning, der
holdes inden for et FDPS.
3.1.21. Generering (Generate) : En proces i et ATC-system, hvor rele-
vante data uddrages fra databasen/databaserne og der dannes en
meddelelse til transmission til en modtagende ATC-enhed.
3.1.22. ICAOFormat(ICAOFormat) : Det format, der anvendes for jord-
jord-transmissionen af ATS-meddelelser og som bruger de felt-
typer 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 over-
fø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 specifikflyvning, 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 defi-
neret 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.2000R2082 — DA — 15.06.2002 — 001.001 — 16
▼B
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ørendeEnhed(TransferringUnit) : 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 arbejdsposi-
tion, når den automatiske koordineringsproces har svigtet.
3.2. Symboler og Forkortelser
Med henblikpå denne Eurocontrol-standard sk al 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 Manage-
ment)
ATS Lufttrafiktjeneste (Air Traffic Service)CDN Koordineringsmeddelelse (Co-ordination Message)
CNL Flyveplansannulering (Fligth Plan Cancellation)
COD SSR Kodetildelingsmeddelelse (SSR Code Assign-
ment 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 Luft-
trafikkontrol i Europa (European ATC
Harmonisation and Integration Programme)
ECAC Den Europæiske Civile Luftfartskonference (Euro-
pean Civil Aviation Conference)
ETO Forventet Tidspunkt over (Estimated time over)
ETOT Forventet Starttid (Estimate Take-Off Time)
EWPD Dokument for EATCHIP Arbejdsprogram
(EATCHIP WorkProgramme 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 LogiskKvitteringsmeddelelse (Logical Ack nowled-
gement Message)
LoA Aftalebrev (Letter of Agreement)
MAC Meddelelse for Ophævelsen af Koordinering
(Message for the Abrogation of Co-ordination)2000R2082 — DA — 15.06.2002 — 001.001 — 17
▼B
MAS Meddelelse om Manuel Overtagelse af Kommunika-
tion (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 Revi-
sion Message)
SBY Stand-by Meddelelse (Stand-by Message)
SDM Supplerende Datameddelelse (Supplementary Data
Message)
SSR Sekundær Radar (Secondary Surveillance Radar)
SYSCO Systemstøttet Koordinering (System Supported Co-
ordination)
TI Overførselsinitiering (Transfer Initiation)
TIM Overførselsinitieringsmeddelelse (Transfer Initiation
Message)
TWR/APP Tårn (luftfartøjskontrol) og Indflyvningskontrol
(Tower (aerodrome control) and Approach Control
4. GENERELLE KRAV
4.1. Introduktion
Dette afsnit beskriver de generelle, operationelle krav, der er
nødvendige for implementeringen af en OLDI-facilitet mellem
ATC-enheder, og kravene til klassifikation og ydeevne for de
forskellige typer af anvendte meddelelser.
4.2. Krav til Flyvedatabehandlingssystem
4.2.1. Flyvedatabase
Enheder, som anvender en facilitet beskrevet i dette dokument,
skal være forsynet med data fra et FDPS, hvilke data indeholder
al den information, der er påkrævet for visningen, behandlingen
og kompileringen af meddelelserne som specificeret. Den
primære datakilde for hver flyvning er flyveplanen, der er indle-
veret af fartøjschefen eller på hans/hendes vegne. Yderligere
dataelementer opnås ved behandlingen af flyveplaner med henvis-
ning til den pågældende enheds ydre forhold.
4.2.2. OperationiRealtid
OLDI-proceduren indeholder hændelser i den overførende ATC-
enhed til at initiere funktioner, som er nødvendige for den retti-
dige 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å flyvnin-
gens rute som bestemt fra flyvedatabasen.
4.2.3. Datakommunikationskapacitet
4.2.3.1. FDPSet skal være i stand til at modtage og transmittere flyvedata
i det format, der er egnet for meddelelsen som specificeret i dette
dokument, via et datakommunikationsmedium, der understøtter
OLDI-funktionen.
4.2.3.2. AnbefalingFDPSet bør have udviklingspotentialet til at mulig-
gøre tilføjelsen af nye meddelelser, der kan være indbefattet i
fremtidige udgaverafdennestandard.2000R2082 — DA — 15.06.2002 — 001.001 — 18
▼B
4.2.3.3. Inden for de krav til ydeevne, som er specificeret i dette doku-
ment, 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 anor-
maliteter ved hjælp af datakommunikationssystemet.
4.2.4. Anvendelsesfunktioner
4.2.4.1. De systemer, der bruges til tilvejebringelsen af OLDI-faciliteter,
skal være i stand til automatisk at modtage, lagre, behandle,
uddrage og levere til display og overføre OLDI-relaterede data i
realtid.
4.2.4.2. FDPSet skal:
— udtrykke foreliggende, operationelle data, der er relevante for
OLDI-funktion som påkrævet ved denne standard, enten opda-
teret automatisk, gennem manuel indførsel eller ved en
kombination af begge;
— være i stand til at uddrage sådanne elementer fra flyveplans-
databasen;
— 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 afstandsno-
tationer 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 rele-
vante advarsler knyttet til modtagede meddelelser for
øjeblikkelig opmærksomhed;
— at rette koordinerings- og overførselsmeddelelsesadvarsler til
de operationelle positioner, der er ansvarlige for koordine-
ringen 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 para-
metertid, 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 udform-
ning, at den øjeblikkelig tiltrækker den passende arbejdspositions
opmærksomhed.
4.2.5.6. AnbefalingHMIen ved ATS-positioner, der anvender OLDI, bør
sørgeforenadvarsel,hvisOLDI-faciliteten ikke ertilgængelig.
4.2.6. Initiering afmeddelelser
4.2.6.1. Hvert system skal indeholde et sæt af systemparametre for at
sikre rettidig, automatisk initiering af OLDI-meddelelser.
4.2.6.2. AnbefalingEvnen til manuelt at initiere transmissionen af en
koordineringsmeddelelse forud for den forventede transmissi-
onstidbørværetil rådighed.
4.2.6.3. Den automatiske hændelse skal altid være sikret, hvis manuel
initiering ikke udføres.2000R2082 — DA — 15.06.2002 — 001.001 — 19
▼B
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 tidspara-
meter/tidsparametre; meddelelsen sendes uden forsinkelse.
4.2.7. Modtagelseafmeddelelser
4.2.7.1. ATC-systemet skal være i stand til:
— at modtage OLDI-meddelelser;
— at behandle dem automatiski 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 behand-
lingen til de(n) behørige position(er) efter behov er sikret.
NOTEDe detaljerede betingelser for genereringen af en kvitte-
ringerspecificeret individuelt forhvermeddelelse.
4.3. Opdatering fra overvågningsdata
AnbefalingForatsikrenøjagtighedenaftidsestimatdatabørder
anvendes information udledt fra sporingen af flyvningen ved
radar eller andre overvågningsmidler til at opdatere flyveplans-
databasen .
4.4. Optegnelse af OLDI-data
4.4.1. Indhold
Indholdet af alle OLDI-meddelelser og modtagelsestiden skal
optegnes.
4.4.2. Faciliteter
Der skal være faciliteter tilgængeligt til genvindingen og
visningen af de optegnede data.
4.5. Tilgængelighed, Pålidelighed, Datasikkerhed og Dataintegritet
4.5.1. Tilgængelighed
4.5.1.1. OLDI-faciliteten skal være tilgængelig i løbet af tiden med
trafikale normal- og spidsbelastninger mellem de to pågældende
enheder.
4.5.1.2. 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ålidelighed
4.5.2.1. Pålidelighed af hver OLDI-forbindelse skal være mindst 99.86 %
(svarende til en nedlukningstid på ikke mere end 12 timer per år,
baseret på 24-timers tilgængelighed).2000R2082 — DA — 15.06.2002 — 001.001 — 20
▼B
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-timerstilgængelighed).
4.5.3. Datasikkerhed
AnbefalingDer bør ved OLDI-faciliteterne gøres brug af datasik-
kerhedsmetoder (f.eks. adgangsrettigheder, kildeverificering) og
hvordeteranvendeligt netværksmanagement .
4.5.4. Dataintegritet
Fejlraten ved anvendelsesniveau må ikke overstige én transmissi-
onsfejl per 2000 meddelelser.
4.6. Operationel evaluering
4.6.1. Evalueringsperiode
Hver ny OLDI-facilitet, heriblandt en ny facilitet på en eksister-
ende forbindelse, skal være udsat for en evalueringsperiode til at
verificere dataintegriteten, nøjagtigheden, ydeevnen, kompatibili-
teten 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. Operationelintroduktionsdato
Datoen for den operationelle introduktion, hvilket forudsætter
fuldendelse af evalueringsperioden, skal formelt være aftalt
mellem de to enheder.
5. MEDDELELSESKATEGORIER
5.1. Generelt
5.1.1. Formål
Dette afsnit i dokumentet:
— definerer kategorierne for meddelelser;
— angiver krav til transaktionstider for kategorierne;
— angiver, hvilke meddelelser, der er obligatoriske, og hvilke,
der er ekstra;
— tildeler kategorier til meddelelsestyper.
5.1.2. Meddelelseskategorier
OLDI-meddelelser er blevet tildelt de følgende kategorier:
— Kategori 1: Overførsel af Kommunikation;
— Kategori 2: Koordinering;— Kategori 3: Underretning.
5.2. Transaktionstider
5.2.1. Transaktionstidsbetingelser
5.2.1.1. De specificerede transaktionstider omfatter transmission, indle-
dende 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 meddelelseskate-
gori.
5.2.1.2. De maksimale transaktionstider for de forskellige kategorier af
meddelelser skal være som angivet i Tabel 5-1.
Tabel5-1
Maksimale transaktionstider
Meddelelseskategori 90 % 99,8 %
1 4 sek10 sek
2 15 sek10 sek2000R2082 — DA — 15.06.2002 — 001.001 — 21
▼B
Meddelelseskategori 90 % 99,8 %
3 25 sek45 sek
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
overstige12sekunder,30sekunderog60sekunderrespektivt .
5.3. Meddelelsesklassifikation og -kategorisering
5.3.1. Meddelelsesklassifikation —ObligatoriskogEkstra
5.3.1.1. De meddelelser, som er beskrevet i dette dokument, klassificeres
som enten obligatoriske eller ekstra.
5.3.1.2. Hvor en meddelelse er beskrevet som obligatorisk (Mandatory)
(M) for transmission (TX), skal der være indeholdt behandling
for at være i stand til at sende sådanne meddelelser.
5.3.1.3. Hvor en meddelelse er beskrevet som obligatorisk for modtagelse
(reception) (REC), skal der være indeholdt behandling for at være
i stand til at behandle modtagede meddelelser.
NOTEIexceptionelle tilfælde,hvortrafikreguleringenmellemto
enheder er envejs, kan de obligatoriske meddelelser være
anvendelige ikunénretning.
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 modta-
gende enhed.
NOTEEkstra meddelelser kan anvendes i kun én retning, hvis
detbestemmesvedoperationelle 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 bilate-
ralt.
5.3.1.6. Krav beskrevet i Tabellerne 5-3 og 5-4 gælder kun, hvor anven-
delsen af Dialogproceduren for Koordinering og/eller Overførsel
af Kommunikation respektivt er blevet aftalt bilateralt mellem
ATC-enheder.
5.3.2. KategoriseringafMeddelelser
5.3.2.1. Kategoriseringen af meddelelser for den grundlæggende
procedure er specificeret i Tabel 5-2.
5.3.2.2. Kategoriseringen af de yderligere koordineringsmeddelelser for
dialogproceduren er specificeret i Tabel 5-3.
5.3.2.3. Kategoriseringen af overførsel af kommunikationsmeddelelser for
dialogproceduren er specificeret i Tabel 5-4.
Tabel5-2
Grundlæggende Proceduremeddelelser
Meddelelsestype Forkortelse Kategori Transmission Modtagelse
Forudgående Grænseinfor-
mationABI 3 M M
Aktivering ACT 2 M M
Revidering REV 2 C (1)C (1)
Foreløbig Aktivering PAC 2 C C
Ophævelsen af Koordine-
ringMAC 2 C C2000R2082 — DA — 15.06.2002 — 001.001 — 22
▼B
Meddelelsestype Forkortelse Kategori Transmission Modtagelse
SSR Kodetildeling COD 2 C C
Information INF 3 C C
LogiskKvitteringsmedde-
lelseLAM M M
NOTE
(1) Obligatoriskfor TX og REC ved anvendelse i en dialogprocedure.
Tabel5-3
Dialogprocedure — Koordineringsfasemeddelelser
(Supplerende til Tabel 5-2)
Meddelelsestype Forkortelse Kategori Transmission Modtagelse
Henvist Aktiveringsforslag RAP 2 C M
Henvist Revidering RRV 2 C M
Koordinering CDN 2 M M
Stand-by (1) SBY M M
Accept ACP 2 M M
Afvis Koordinering (2) RJC 2 C C
NOTER
(1) Se afsnit 5.2.1.1 Transaktionstidsbetingelser.
(2) Anvendes ikke ved alle luftrumskonfigurationer.
Tabel5-4
Dialogprocedure — Overførselsfasemeddelelser
Meddelelsestype Forkortelse Kategori Transmission Modtagelse
Overførselsinitiering TIM 1 M M
Supplerende Data SDM 1 (1)(1)
Forslag om overdragelse HOP 1 M M
Frekvensændring (2) COF 1 C M
Frekvensanmodning ROF 1 C M
Manuel Overtagelse (2) MAS 1 C M
NOTER
(1) M, når den sendes fra den overførende enhed; C, når den sendes fra den accepterende enhed.
(2) Procedurer, som er aftalt bilateralt, skal specificere, at som et minimum skal enten den overfø-
rende enhed sende en COF-meddelelse eller den accepterende enhed skal sende en MAS-
meddelelse, når overførslen sker i forhold til en given retning af trafikreguleringen.
6. GRUNDLÆGGENDE PROCEDURE — OBLIGATORISKE
MEDDELELSER
6.1. Generelt
6.1.1. Beskrivelse afKrav
Dette afsnit beskriver det minimale krav ved anvendelsesniveauet
for implementeringen af OLDI-faciliteter.
6.1.2. Implementering
Enheder, som anvender OLDI til koordineringen af flyvninger,
skal implementere ABI, ACT og LAM som beskrevet i dette
afsnit, bortset fra de tilfælde hvor det er blevet aftalt bilateralt at
anvende koordineringsdialogproceduren som beskrevet i dette
dokuments Afsnit 8, i hvilket tilfælde betingelserne for anven-
delsen af ACT- og LAM-meddelelserne er som defineret i det
afsnit.2000R2082 — DA — 15.06.2002 — 001.001 — 23
▼B
6.2. Forudgående Grænseinformationsmeddelelse (ABI)
6.2.1. FormålmedABI-Meddelelsen
ABI opfylder de følgende, operationelle krav:
— at sørge for erhvervelse af manglende flyveplansdata;
— at tilvejebringe forudgående grænseinformation og revide-
ringer 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. Indholdafmeddelelse
ABI-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype
— Meddelelsesnummer
— Luftfartøjsidentifikation
— SSR-tilstand og -kode (hvis det er tilgængeligt)
— Afgangsflyveplads— Estimatdata
— Bestemmelsesflyveplads
— Nummer for og type af luftfartøj
— Flyvningens art
— Udstyrsspecifikation og -status
— Rute (frivilligt)
— Andre flyveplansdata (frivilligt).
NOTE:Dataindsættelsesregler, formater og feltindhold er speci-
ficeret ianneksA.
6.2.3. ReglerforAnvendelse
6.2.3.1. Generelt
6.2.3.1.1. Bortset fra de tilfælde, som er angivet i 6.2.3.1.3 og 6.2.3.1.4
nedenfor, skal der sendes én eller flere ABI-meddelelser for hver
flyvning, som er planlagt til at krydse grænsen mellem ansvars-
områder omfattet af OLDI-procedurer.
6.2.3.1.2. Når ABI-meddelelsen sendes, skal den gå forud for Aktiverings-
meddelelsen (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
indenforetbilateralt aftalttidsinterval.
NOTEFormåletmeddenneanbefalingeratundgådenforsø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øl-
gende ACT-meddelelse ikke er blevet genereret og:
— flyvningens rute er blevet modificeret således, at COPet i den
tidligere ABI-meddelelse ikke længere er nøjagtigt;
— bestemmelsesflyveplanen er blevet ændret;
eller
— typen af luftfartøj er blevet ændret.
6.2.3.1.6. Anbefaling Der bør sendes en revideret ABI-meddelelse, hvis
den efterfølgende ACT-meddelelse ikke er blevet genereret og
én af de følgende emner er genstand for forandring:
—Detforventede grænsekrydsningsniveau;
—Denforventede SSR-kode vedoverførselafkontrolpunkt;2000R2082 — DA — 15.06.2002 — 001.001 — 24
▼M1
▼B
▼B
—Når det forventede tidspunkt over (ETO) ved COPet er
forskelligt fra den tidligere ABI-meddelelse i længere tid end
dentid,dererspecificeret iAftalebrevet (LoA);
—Vilkårlige andredata,someraftaltbilateralt.
6.2.3.2. Behandling i den Modtagende Enhed
6.2.3.2.1. Det ATC-system, som modtager en ABI-meddelelse, skal forsøge
at få forbindelse med de tilsvarende flyveplansdata.
6.2.3.2.2. Hvis flyveplansforbindelsen ikke er vellykket, skal en flyveplan
dannes automatiskeller manuelt i det modtagende system.
6.2.3.2.3. Hvis flyveplansforbindelsen er vellykket, men der identificeres en
uoverensstemmelse mellem dataene i meddelelsen og tilsvarende
data i det modtagende system, hvilken uoverensstemmelse ville
resultere i et behov for en korrigerende handling ved modtagelsen
af den følgende ACT-meddelelse, skal uoverensstemmelsen
henvises til en passende position for afgørelse.
6.2.3.3. Tidsparametre for Transmission
6.2.3.3.1. Meddelelsen skal transmitteres et parameterantal af minutter før
den forventede tid ved COPet.
6.2.3.3.2. ABI-genereringsparameteren/ABI-genereringsparametrene skal
indbefattes i Aftalebrevet LoA mellem de pågældende ATC-
enheder.
6.2.3.3.3. Anbefaling ABI-genereringsparameteren/ABI-genereringspara-
metrene bør være:
—variable,baseretpåbestemmelserneiLoAet;
—defineret særskiltforhvertafCOPerne.
6.2.4. Kvittering forABI
6.2.4.1. Kvittering
Der skal kvitteres for ABI-meddelelsen ved at generere og trans-
mittere en LAM-meddelelse.
NOTEDer genereres en LAM-meddelelse uanset resultaterne af
forsøgetpåflyveplansforbindelse.
6.2.4.2. Ingen Kvittering
AnbefalingHvis der ikke modtages nogen LAM-meddelelse som
en kvittering for en ABI-meddelelse, bør der vises en advarsel
vedenovervå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. I C A O
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.2.5.2. A D E X P
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 -FLTTYP N -BEGIN EQCST -EQPT W/
EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON)2000R2082 — DA — 15.06.2002 — 001.001 — 25
▼M1
▼B
6.3. Aktiveringsmeddelelse (ACT)
6.3.1. FormålmedACT-Meddelelsen
ACT-meddelelsen opfylder de følgende, operationelle krav:
— At erstatte den verbale grænseberegning ved automatiskat
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 modta-
gende 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. Indholdafmeddelelse
ACT-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype
— Meddelelsesnummer
— Luftfartøjsidentifikation
— SSR-tilstand og -kode
— Afgangsflyveplads
— Estimatdata
— Bestemmelsesflyveplads
— Nummer for og type af luftfartøj
— Flyvningens art— Udstyrsspecifikation og -status
— Rute (frivilligt)
— Andre flyveplansdata (frivilligt).
NOTE:Dataindsættelsesregler, formater og feltindhold er speci-
ficeret ianneksA.
6.3.3. ReglerforAnvendelse
6.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,
visessammenmeddensindhold.
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-meddelelsesda-
taene 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.2000R2082 — DA — 15.06.2002 — 001.001 — 26
▼M1
▼B
▼B
6.3.3.1.9. Der regnes med accept ved den modtagende enhed af de overfør-
selsbetingelser, der rummes i ACT-meddelelsen, med mindre den
modtagende enhed initierer koordinering for at rette i dem.
6.3.3.1.10. Der kan kun sendes en yderligere ACT-meddelelse til den samme
koordineringspartner, hvis den tidligere meddelelse er blevet
ophævet ved anvendelsen af en MAC.
6.3.3.1.11. Rute og Andre flyveplansdata skal være indeholdt, hvis det er
aftalt bilateralt.
6.3.3.2. Behandling i den Modtagende Enhed
6.3.3.2.1. Det ATC-system, som modtager en ACT-meddelelse, skal
forsøge at opnå forbindelse med den tilsvarende flyveplan.
6.3.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen
er nogen uoverensstemmelse til stede, som ville forhindre korrekt
behandling:
— skal det operationelle indhold være indbefattet i flyveplanen;
— skal de påkrævede data udsendes ved operationel ATC og
andre positioner som behørigt;
— skal der returneres en LAM.
6.3.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der
findes en uoverensstemmelse, som forhindrer korrekt behandling
af meddelelsen:
— hvis den sektor, der er ansvarlig for at acceptere kontrol over
flyvningen kan identificeres:
— skal det operationelle indhold af meddelelsen vises ved
sektoren;
— skal en LAM returneres;— skal en flyveplan dannes;
— i alle andre tilfælde skal en LAM ikke returneres.
6.3.3.3. Parametre for Transmission
6.3.3.3.1. Meddelelsen skal transmitteres til eller så snart som muligt efter
det tidligste af de tidspunkter, der bestemmes ud fra det følgende:
— et parameterantal af minutter før den forventede tid ved
COPet;
— det tidspunkt, til hvilket flyvningen er i en bilateralt aftalt
afstand fra COPet.
6.3.3.3.2. ACT-genereringsparameteren/ACT-genereringsparametrene skal
være indbefattet i LoAet mellem de pågældende ATC-enheder.
6.3.3.3.3. ACT-genereringsparameteren/ACT-genereringsparametrene skal
være variable, baseret på bestemmelserne i LoAet.
6.3.3.3.4. Anbefaling ACT-genereringsparametre bør være defineret
særskiltforhvertafCOPerne.
6.3.3.3.5. De specificerede parametre skal give tilstrækkelig tid til:
— at den transmitterende enhed kan opdatere overførselsflyveni-
veauet 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 forACT
6.3.4.1. Kvittering
Der skal kvitteres for ACT-meddelelsen ved genereringen og
transmissionen af en LAM-meddelelse.
6.3.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring for en ACT-meddelelse, skal der vises en advarsel ved den
ATC-position, som er ansvarlig for flyvningens koordinering.2000R2082 — DA — 15.06.2002 — 001.001 — 27
▼B
6.3.5. Eksempler
De følgende eksempler er en udvidelse af de, der er givet for
ABI-meddelelsen i afsnit 6.2; alle detaljer er de samme bortset
fra det ETO ved COPet, hvilket tidspunkt er 1226 i den viste
ACT-meddelelse.
6.3.5.1. I C A O
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.3.5.2. A D E X P
-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 -FLTTYP N-BEGIN EQCST-EQPT W/
EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON
6.4. Logisk Kvitteringsmeddelelse (LAM)
6.4.1. FormålmedLAM-Meddelelsen
LAMen er det middel med hvilket modtagelsen og beskyttelsen af
en transmitteret meddelelse angives til den sendende enhed af den
modtagende enhed.
LAM-behandlingen forsyner ATC-mandskabet ved den overfø-
rende enhed med følgende:
— en advarsel, når der ikke er blevet modtaget en kvittering;
— en angivelse af, at den meddelelse, der kvitteres for, er blevet
modtaget, vellykket behandlet, fundet som værende fri for
fejl, lagret og hvor det er relevant er tilgængelig for præsenta-
tion til de(n) passende arbejdsposition(er)
6.4.2. IndholdafMeddelelse
LAM-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer— Meddelelseshenvisning.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
6.4.3. ReglerforAnvendelse
6.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 medde-
lelse.
6.4.3.1.2. LAM-meddelelsen skal genereres og transmitteres uden menne-
skelig 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 koor-
dineringen, hvis der ikke er blevet modtaget en LAM-meddelelse
inden for den tidsparameter, der er fastsat for sådanne advarsler.
6.4.4. Kvittering forLAM
LAM-meddelelsen skal ikke kræve nogen kvittering.
6.4.5. Eksempler
6.4.5.1. ICAO
(LAML/E012E/L001)2000R2082 — DA — 15.06.2002 — 001.001 — 28
▼M1
▼B
▼B
6.4.5.2. ADEXP
-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -
SEQNUM 001
7. GRUNDLÆGGENDE PROCEDURE — EKSTRA MEDDE-
LELSER
7.1. Generelt
7.1.1. Beskrivelse afKrav
Dette Afsnit beskriver faciliteter, der er anvendelige med den
grundlæggende procedure, hvilke faciliteter er supplerende til de,
som er beskrevet i Afsnit 6 Grundlæggende Procedure — Obliga-
toriske Meddelelser.
7.1.2. Implementering
7.1.2.1. Anvendelsen af en hvilken som helst af de i dette
Afsnit beskrevne faciliteter skal være aftalt bilateralt, før de
indføres.
7.1.2.2. Når en sådan anvendelse er aftalt, skal de regler, som er
beskrevet i dette afsnit, gælde.
7.2. Foreløbig Aktiveringsmeddelelse (PAC)
7.2.1. FormålmedPAC-Meddelelsen
PAC-Meddelelsen opfylder de følgende, operationelle krav:
— underretning og koordinering før afgang for en flyvning, hvor
flyvetiden fra afgang til COPet er mindre end den tid, der
ville være påkrævet til at overholde de aftalte tidsparametre
for transmission af ACT-meddelelser;
— underretning og koordinering før afgang for en flyvning før
afgang ved en lokal (flyveplads/indflyvningskontrol) enhed
til den næste enhed, der vil tage kontrol over flyvningen;
— at sørge for erhvervelse af manglende flyveplansdata i
tilfældet af uoverensstemmelser i den indledende fordeling af
flyveplansdata;
— at anmode om tildelingen af en SSR-kode fra den enhed, som
underretningen/koordineringen ovenfor sendes til, hvis det er
påkrævet.
7.2.2. IndholdafMeddelelse
PAC-Meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;
— Meddelelseshenvisning (frivilligt);— Luftfartøjsidentifikation;— SSR Tilstand og -Kode;
— Afgangsflyveplads;
— Forventet Starttid eller Estimatdata;— Bestemmelsesflyveplads;— Type af Luftfartøj;
— Rute (frivilligt);
— Andre flyveplansdata (frivilligt).
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
7.2.3. ReglerforAnvendelse
7.2.3.1. Generelt
7.2.3.1.1. Der skal sendes én eller flere PAC-meddelelser for hver flyvning,
der er planlagt til at krydse grænsen mellem ansvarligheds-
områ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.2000R2082 — DA — 15.06.2002 — 001.001 — 29
▼B
7.2.3.1.3. AnbefalingFor implementeringen af PAC/LAM mellem enheder
børderelevanteTWR/APP-systemerværeforsynetmedetmiddel
tilatindføreogvideresende »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-medde-
lelse sendt for flyvningen;
— være indholdt i den anden og efterfølgende PAC-meddelelser.
7.2.3.1.6. Anvendelsen af kodeanmodningsfaciliteten skal, hvis den er
påkrævet, være aftalt bilateralt.
7.2.3.1.7. Der skal sendes en revideret PAC-meddelelse, hvis en hvilken
som helst af de følgende betingelser er opfyldt inden afgang:
— flyvningens rute er blevet modificeret således, at COPet i den
tidligere meddelelse ikke længere er nøjagtigt;
— typen af luftfartøj er blevet ændret;
— destinationsflyvepladsen i den tidligere PAC har vist sig at
være ukorrekt.
7.2.3.1.8. Anbefaling Der bør sendes en revideret PAC-meddelelse, hvis de
følgende data er forskellige fra dataene i den tidligere PAC-
meddelelse inden afgang:
—niveauet(iestimatdataene, hvisdeertilstede);
—denforventede SSR-kode vedoverførslenafkontrolpunkt;
—den Forventede Starttid eller ETOved CO Pet til et tidspunkt
udoverenværdi,someraftalt bilateralt;
—der er en ændring i vilkårlige andre data, ifølge bilateral
aftale.
7.2.3.2. Behandling i den Modtagende Enhed
7.2.3.2.1. Det ATC-system, som modtager en PAC-meddelelse, skal forsøge
at opnå forbindelse med den tilsvarende flyveplan.
7.2.3.2.2. Hvis en tilsvarende flyveplan er fundet og der ikke i meddelelsen
er nogen uoverensstemmelse til stede, som ville forhindre korrekt
behandling:
— skal det operationelle indhold være indbefattet i flyveplanen;
— skal de påkrævede data udsendes ved operationel ATC og
andre positioner som behørigt;
— skal der returneres en LAM.
7.2.3.2.3. Hvis der ikke kan findes en tilsvarende flyveplan eller hvis der
findes en uoverensstemmelse, som forhindrer korrekt behandling
af meddelelsen:
— hvis den sektor, der er ansvarlig for at acceptere kontrol over
flyvningen kan identificeres:
— skal det operationelle indhold af meddelelsen vises ved
sektoren;
— skal en LAM returneres;— skal en flyveplan dannes;
— i alle andre tilfælde skal en LAM ikke returneres.
7.2.3.2.4. Dataene i en anden eller en efterfølgende PAC-meddelelse skal
erstatte dataene i den tidligere meddelelse.
7.2.3.2.5. Hvis PAC-meddelelsen indeholder en anmodning om tildelingen
af en SSR-kode og kan behandles korrekt som beskrevet i
Afsnit 7.2.3.2.2 ovenfor, skal der returneres en COD-meddelelse
ud over LAMen.
NOTEIdet kodetildelingsprocessen kræver detaljeret flyveplans-
ruteinformation, stilles der i dette dokument ikke noget
krav om returneringen af en COD-meddelelse ved den2000R2082 — DA — 15.06.2002 — 001.001 — 30
▼B
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ændig-
heder, hvis der eksisterer en specifik, lokal egenskab og
procedureneraftaltbilateralt.
7.2.3.3. Tidsparametre for Transmission
En transmissionstidsparameter er ikke anvendelig, idet medde-
lelsen sendes som et resultat af en manuelt indført meddelelse,
som identificerer flyvningens forestående afgang.
7.2.4. Kvittering forPAC
7.2.4.1. Kvittering
De meddelelser, der skal sendes som reaktion på en PAC-medde-
lelse, er beskrevet i Afsnit 7.2.3.2 ovenfor.
7.2.4.2. Ingen Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring for en PAC-meddelelse, skal der vises en advarsel ved den
position i ATC-enheden, som er ansvarlig for koordineringen
med den næste enhed.
7.2.4.3. Tilfælde af Ingen LAM
I tilfælde af ingen LAM skal verbal koordinering initieres.
7.2.4.4. Ingen COD-Meddelelse
7.2.4.4.1. Hvis der ikke modtages en COD-meddelelse som reaktion på en
kodeanmodning, som er indbefattet i PAC-meddelelsen, skal en
advarsel vises ved en passende position.
7.2.4.4.2. Hvor kodeanmodningsfunktionen skal bruges, skal den timeout-
værdi, der skal anvendes, være aftalt bilateralt.
7.2.5. Eksempler
7.2.5.1. Estimeret Starttid og Kodeanm odning
7.2.5.1.1. ICAO
(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)
7.2.5.1.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC
SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP
LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA
7.2.5.2. Tid ved COP
7.2.5.2.1. ICAO
(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-
EBBR-9/B737/M)
7.2.5.2.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP
EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL
F110A -ARCTYP B737 -ADES EBBR
7.3. Revideringsmeddelelse (REV)
7.3.1. FormålmedREV-Meddelelsen
REV-meddelelsen bruges til at transmittere revideringer til koor-
dineringsdata, 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. Indholdafmeddelelse
REV-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype
— Meddelelsesnummer— Luftfartøjsidentifikation— Afgangsflyveplads2000R2082 — DA — 15.06.2002 — 001.001 — 31
▼M1
▼M1
— Estimatdata og/eller koordineringspunkt
— Bestemmelsesflyveplads
— Meddelelseshenvisning (frivilligt)
— SSR-tilstand og -kode (frivilligt)
— Rute (frivilligt)
— Udstyrsspecifikation og -status (frivilligt).
NOTE:Dataindsættelsesregler, formater og feltindhold er speci-
ficeret ianneksA.
7.3.3. ReglerforAnvendelse
7.3.3.1. Generelt
7.3.3.1.1. Der kan sendes én eller flere REV-meddelelsen til den enhed,
som en flyvning for øjeblikket er blevet koordineret til ved
brugen af en Aktiveringsmeddelelse.
7.3.3.1.2. De følgende elementer skal være omfattet af revideringer:
— ETO ved COPet
— Overførselsniveau(er)
— SSR-kode
— Udstyrsspecifikation og -status.
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ør-
selsniveauet/overførselsniveauerne, SSR-koden eller
udstyrsspecifikation og -status.
7.3.3.1.4. Hvor det bilateralt er aftalt, skal der sendes en REV-meddelelse,
hvis der er en hvilken som helst forandring i de følgende:
— COP
— rute.
NOTE:Operationelle regler kan kræve, at modifikationer, som
udføres efter ACT, kan være på betingelse af forud-
gående koordineringmellem deberørteenheder.
7.3.3.1.5. Når det er aftalt bilateralt, skal meddelelseshenvisningen indbe-
fattes i REV-meddelelsen.
7.3.3.1.6. Meddelelseshenvisningen skal, når den er indbefattet, indeholde
den tidligere ACT-meddelelses meddelelsesnummer.
7.3.3.1.7. Den modtagende ATC-enheds accept af de overførselsbetingelser,
der medføres af REV-meddelelsen, skal formodes, medmindre
den modtagende ATC-enhed initierer koordinering for at rette i
dem.
7.3.3.2. Formatering af Revideringsmeddelelser
7.3.3.2.1. I C A O-format
Alle revideringsmeddelelser omfatter felttyper 3, 7, 13, 14 og 16.
De følgende typer af revidering indbefattes i disse felter:
— en ændring af ETOet ved COPet eller overførselsniveauet/
overførselsniveauerne skal indarbejdes i indbefatningen af de
reviderede data i felt 14.
— en ændring af SSR-koden skal være indbefattet som element
b) eller c) i felt 7.
Alle andre ændringer skal være indbefattet i felt 22's format efter
de første fem indledende felter. Der gælder følgende regler:
— Felter, som indbefattes i felt 22's format, kan være i vilkårlig
rækkefølge.
— Ændringer af COPet skal være indarbejdet som data i felt 14 i
felt 22's format (se anneks B Specielle Rutebehandlingskrav).
— Ruteændringer skal være indarbejdet som data i felt 15 i felt
22's format. Regler for koordineringen af sådanne ændringer,2000R2082 — DA — 15.06.2002 — 001.001 — 32
▼B
▼M1
▼B
▼M1
▼M1
heri indbefattet direkte styringer, er specificeret i anneks B
Specielle Rutebehandlingskrav.
— Udstyrsspecifikation og -status; kun kapacitet eller kapaci-
teter, som ændres, skal medtages. En meddelelse om ændringaf kapacitet, som medfører, at der er behov for at indarbejde
data vedrørende ekstra kapacitet som anført i anneks A, punkt
A.30, skal indbefatte den ekstra kapacitet.
7.3.3.2.2. A D E X P-format
Alle revideringsmeddelelser i ADEXP-format skal indbefatte de
følgende primære felter: TITLE REFDATA ARCID ADEP
ADES. Der gælder følgende regler:
— 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.
— Primærfeltet COP skal medtages, medmindre en ændring af
ETO eller overførselsniveau(-er) nødvendiggør anvendelsen
af primærfeltet COORDATA. Det skal indeholde det koordi-
neringspunkt, som flyvningen koordineres igennem nu, eller
hvis koordineringspunktet ændres, det koordineringspunkt,
som flyvningen tidligere blev koordineret igennem.
— Ændringer af COPet indarbejdes ved hjælp af dataene i
primærfeltet COORDATA (se anneks B Specielle Rutebe-
handlingskrav). Sådanne meddelelser skal også omfatte
primærfeltet COP som anført ovenfor.
— Ruteændringer indarbejdes ved hjælp af primærfeltet ROUTE.
Regler for koordineringen af sådanne ændringer, heri indbe-
fattet direkte styringer, er specificeret i anneks B Specielle
Rutebehandlingskrav.
— En ændring af SSR-koden skal være angivet ved indbefat-
ningen af primærfeltet SSRCODE.
— En ændring af udstyrsspecifikation og -status skal anvende
primærfeltet EQCST; kun den/de egenskab(-er), som ændrer
sig, medtages. En meddelelse om en ændring, som udløser
medtagelse af data vedrørende yderligere egenskaber, som
anført i anneks A, punkt A.30, skal angive den yderligere
egenskab.
7.3.3.2.3. SSR-Kode
SSR-Tilstand og -Kode skal kun være indbefattet i en REV-
meddelelse, når det er påkrævet at koordinere en ændring af
SSR-kode.
7.3.3.3. Behandling i den Modtagende 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 Transmission
7.3.3.4.1. REV-meddelelsen er hændelsesdrevet og skal transmitteres
øjeblikkeligt efter den relevante indføring eller opdatering.
7.3.3.4.2. Der kan ikke udføres nogen ændringer ved brugen af REV-
meddelelsen, efter at flyvningen er ved et specificeret tidspunkt/
en specificeret afstand fra overførselspunktet. Tids- og afstands-
parametrene skal være aftalt bilateralt.
7.3.3.4.3. AnbefalingREV-parametrene bør være defineret særskilt for
hvertafCOPene.
7.3.3.5. Ændring af Modtagende ATC-Enhed
REV-meddelelsen skal ikke bruges, hvis en revidering af flyve-
plansdata fører til en ændring af den modtagende ATC-Enhed
(se Meddelelse for Ophævelsen af Koordinering).2000R2082 — DA — 15.06.2002 — 001.001 — 33
▼B
▼B
7.3.4. Kvittering forREV
7.3.4.1. Kvittering
Hvis REV-meddelelsen:
— kan forbindes med en flyveplan i det modtagende system, skal
der transmitteres en LAM-meddelelse som kvittering;
— ikke kan forbindes med en flyveplan i det modtagende
system, skal der ikke transmitteres en LAM-meddelelse.
7.3.4.2. Ingen Kvittering7.3.4.2.1. Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring for en REV-meddelelse, skal der vises en advarsel ved den
ATC-position, som er ansvarlig for koordineringen af flyvninger.
7.3.4.2.2. I tilfælde af ingen LAM skal en verbal koordinering initieres af
den overførende ATC-enhed.
7.3.5. Eksempler
7.3.5.1. I C A O
a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
EGBB)
c. (REVE/L019-AMM253-LMML-BNE/1237F350-EGBB-81/W/
NO)
d. (REVBC/P873-BAF4486-EBMB-NEBUL/2201F250-LERT-
81/W/NO U/EQ)
7.3.5.2. A D E X P
a. TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COOR-
DATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB
b. TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -SSRCODE A2317
c. c. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -
FAC L -SEQNUM 019 -ARCID AMM253 -ADEP LMML -
COP BNE -ADES EGBB -BEGIN EQCST -EQPT W/NO -
END EQCST
d. -TITLE REV -REFDATA -SENDER -FAC BC -RECVR -
FAC P -SEQNUM 873 -ARCID BAF4486 -ADEP EBMB -
COP NEBUL -ADES LERT -BEGIN EQCST -EQPT Y/NO -
EQPT U/EQ -END EQCST.
7.4. Meddelelse for Ophævelsen af Koordinering (MAC)
7.4.1. FormålmedMAC-Meddelelsen
En MAC-meddelelse bruges til at angive over for den modta-
gende 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. IndholdafMeddelelse
MAC-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;
— Meddelelseshenvisning (frivilligt);
— Luftfartøjsidentifikation;
— Afgangsflyveplads;— Koordineringspunkt;
— Bestemmelsesflyveplads;
— Koordineringsstatus og –Årsag (frivilligt);
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.2000R2082 — DA — 15.06.2002 — 001.001 — 34
▼M1
▼B
▼B
7.4.3. ReglerforAnvendelse
7.4.3.1. Generelt
7.4.3.1.1. Der skal sendes en MAC-meddelelse til en enhed, som koordine-
ring 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 koordineringsse-
kvensen;
— 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 koordine-
ring, 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 under-
retning (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 revi-
deret 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 tidli-
gere 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
årsagentilophæ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 koordi-
neringspartner:
— 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-medde-
lelse 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;2000R2082 — DA — 15.06.2002 — 001.001 — 35
▼B
— 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-medde-
lelse;
— skal systemet bevare evnen til korrekt at behandle en ny
underretnings- og/eller koordineringsmeddelelse fra enten den
tidligere overførende enhed eller en anden enhed i en ny
koordineringssekvens.
7.4.3.2. Behandling i den Modtagende Enhed
De(n) arbejdsposition(er) i den modtagende ATC-enhed, som er
forsynet med flyvedetaljer, skal underrettes om ophævelsen.
7.4.4. Kvittering forMAC
7.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-posi-
tion, som er ansvarlig for koordineringen.
7.4.4.2.2. I sådanne tilfælde skal en verbal ophævelse af koordinering
udføres af den overførende ATC-enhed.
7.4.5. Eksempler
En ABI-meddelelse blev sendt af Amsterdam ACC til Bruxelles
ACC for flyvning HOZ3188, planlagt til FL190; flyvningen
anmoder efterfølgende om at stige til FL270 og klarerers til dette
og går således ind i Maastrichts luftrum i stedet for Bruxelles'.
Eksempler 7.4.5.1 a og 7.4.5.2 a viser, hvordan MACen, der
sendes til Bruxelles af Amsterdam, ville forekomme, både i
ICAO- og i ADEXP-format.
En ABI- og senere en ACT-meddelelse sendes til Maastricht, men
enkelte minutter før luftfartøjet når COPet, returnerer det til
Amsterdams Lufthavn og flyveplanen annulleres i den sendende
enheds system; der sendes MAC til Maastricht som vist i
eksempler (7.4.5.1 b og 7.4.5.2 b).
7.4.5.1. ICAO
a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/
INITFL)
b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/
INICAN)
7.4.5.2. ADEXP
a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON TFL
b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON CAN
7.5. SSR Kodetildelingsmeddelelse (COD)
7.5.1. FormålmedCOD-Meddelelsen
7.5.1.1. Metoden til Kodetildeling for Oprindeligt Område (ORCAM) er
frembragt til at tillade en flyvning at respondere på den samme2000R2082 — DA — 15.06.2002 — 001.001 — 36
▼B
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. IndholdafMeddelelse
COD -meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;— Meddelelseshenvisning (frivilligt);
— Luftfartøjsidentifikation;
— SSR-Tilstand og -Kode;— Afgangsflyveplads;— Bestemmelsesflyveplads;— Rute (frivilligt);
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
7.5.3. ReglerforAnvendelse
7.5.3.1. Generelt7.5.3.1.1. Der skal automatisk genereres og transmitteres en COD-medde-
lelse 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 Luftnavigerings-
planen 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 behand-
ling af meddelelsen, skal der ikke returneres nogen LAM.
7.5.3.2.3. Rutedata skal, hvis de er indbefattet, ikke være årsag til at
forhindre returneringen af en LAM, medmindre de fejler med
hensyn til at overholde formatkravet som fremsat i Anneks A.
7.5.3.3. Tidsparametre for Transmission
En transmissionstidsparameter skal ikke være anvendelig, idet
COD-meddelelsen sendes som et resultat af modtagelsen af en
meddelelse, der anmoder om tildelingen af en SSR-kode.
7.5.4. Kvittering forCOD
7.5.4.1. Kvittering
Der skal kvitteres for COD-meddelelsen ved at generere og trans-
mittere en LAM-meddelelse.
7.5.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring for en COD-meddelelse, skal en advarsel vises ved en
passende position.2000R2082 — DA — 15.06.2002 — 001.001 — 37
▼B
7.5.5. Eksempler
7.5.5.1. ICAO
(CODP/PO011-AAL905/A0767-LFPO-KEWR)
7.5.5.2. ADEXP
-TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO
-SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905
-SSRCODE A0767
7.6. Informationsmeddelelse (INF)
7.6.1. FormålmedINF-Meddelelsen
7.6.1.1. INF-meddelelsen bruges til at frembringe information med
hensyn til specifikke flyvninger til agenturer, som ikke er direkte
involverede i koordineringsprocessen mellem to på hinanden
følgende ATC-enheder på en flyvnings rute.
7.6.1.2. INF-meddelelsen kan bruges til at frembringe kopier af medde-
lelser 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 over-
fø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, revide-
ringer og annulleringer.
7.6.2. IndholdafMeddelelse
INF-meddelelsen skal indeholde de følgende dataemner i formatet
for en meddelelse beskrevet i dette dokument:
— Meddelelsestype;
— Meddelelsesnummer;— Alle emner af operationelle data som indbefattet i den origi-
nale meddelelse eller resulterende koordinering, der kopieres;
— Henvisningsmeddelelsestype (frivilligt);
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
7.6.3. ReglerforAnvendelse
7.6.3.1. Meddelelsestyper
Typen/typerne af meddelelse(r), der skal duplikeres ved en INF-
meddelelse, vil være baseret på brugeres krav og egenskaberne
for den sendende enhed. Typen/typerne af meddelelse(r) og
reglerne for anvendelse vil almindeligvis være aftalt bilateralt.
7.6.3.2. Meddelelsesadressater
Der kan transmitteres én eller flere INF-meddelelser for den
samme flyvning til én eller flere adressater.
7.6.3.3. Operationelt Indhold
Det operationelle indhold i INF-meddelelsen skal være i formatet
for én af de eksisterende meddelelser.
7.6.3.4. Anbefalinger
1.Betingelser, der er videresendt i en indledende dialogmedde-
lelse (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 koordi-
neringsbetingelser .
2.INF-meddelelsenbørsendesøjeblikkeligtellertilettidspunkti
forholdtil tidspunktet ved COPet, someraftalt bilateralt med
detmodtagendeagentur .
7.6.4. Kvittering forINF
Anbefalinger2000R2082 — DA — 15.06.2002 — 001.001 — 38
▼B
1.Der kan kvitteres for INF-meddelelsen afhængigt af koordine-
ringspartneren 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
enINF-meddelelse .
7.6.5. Eksempler
En flyvning med kaldesignal BAW011, B747 fra EGLL til
OMDB ved FL290, anmoder om FL410, forventer Koksy (KOK)
VOR kl. 1905, har transpondervisning på A5437, fortsætter via
UG1 og UB6.
Der sendes en ACT-meddelelse af London til Maastricht for
flyvningen. En kopi sendes fra London til en enhed, der identifi-
ceres som IT.
Det følgende giver eksempler på INF-meddelelsen.
7.6.5.1. ICAO
(INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/
B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/
MSG/ACT)
7.6.5.2. ADEXP
-TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -
SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP
EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES
OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK
NTM UB6 KRH -MSGTYP ACT
8. DIALOGPROCEDURE — KOORDINERING
8.1. Generelt
8.1.1. Introduktion
8.1.1.1. Dialogproceduren frembringer faciliteter til kommunikation og
forhandling mellem flyveledere i koordineringsfasen og til
kommunikation i overførselsfasen.
8.1.1.2. Dette afsnit beskriver meddelelser, der anvendes i dialogproce-
duren 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 — Dialogpro-
cedure — Overførsel af Kommunikation.
8.1.1.3. Procedurer for de to faser er ikke afhængige af hinanden; de kan
implementeres enkeltvis eller sammen.
8.1.1.4. Et antal yderligere meddelelser indføres og begge partneres evne
til at initiere en dialog understøttes.
8.1.1.5. Koordineringsdialogproceduren tillader identifikation af:
— overførsler, som er i overensstemmelse med LoAet og som
kan accepteres automatisk; og
— de, som kræver at blive henvist til flyvelederen ved den
modtagende enhed for en beslutning vedrørende accept.
8.1.1.6. Denne procedure tillader også, at der kan føres opsyn med
fortolkningen af LoAene i de to systemer og at en hvilken som
helst uoverensstemmelse mellem dem kan identificeres.
8.1.2. Filteret
8.1.2.1. Generelt
8.1.2.1.1. Koordineringsdialogproceduren kræver, at systemer identificerer,
hvorvidt overførsler er i overensstemmelse med LoAet eller ej.
8.1.2.1.2. Den proces, som kontrollerer en sådan overensstemmelse,
betegnes i dette dokument »filteret«. Den database, som bruges
til filteret, vil, hvis det er påkrævet, indbefatte de følgende:
— aftalte koordineringspunkter;
— berettigede (eller uberettigede) flyveniveauer, hvilket også
kan være forbundet med koordineringspunkterne;
— afgangsflyvepladser;2000R2082 — DA — 15.06.2002 — 001.001 — 39
▼B
— 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ørselsbe-
tingelser, 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
henledestil dette faktumforbekræftelse ellermodifikation.
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 beslut-
ning, 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-standard-
overfø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-standardover-
førselsbetingelser i en meddelelse, der kun bruges til at
koordinere standardoverførsler, vil betyde en uoverensstemmelse
mellem de to filtre. Sådanne uoverensstemmelser bør afgøres for
dialogprocedurens effektive funktion.
8.1.3. Meddelelsessekvens
8.1.3.1. 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 koordi-
nerede tilstand.
8.1.4. SamtidigHåndteringafMeddelelser
8.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ørsels-
meddelelse for den samme flyvning med den samme enhed, før2000R2082 — DA — 15.06.2002 — 001.001 — 40
▼B
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 accepte-
rende 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åndteringafAfvisning
RJC-meddelelsen afslutter en systemdialog. Der skal initieres en
ny systemkoordinering, som afspejler telefonkoordineringen,
hvor det er anvendeligt.
8.1.6. OperationeltTimeoutforBesvarelser
8.1.6.1. Generelt8.1.6.1.1. Der skal anvendes en timeout-mekanisme ved sende- og modta-
gecentrene for besvarelsen til meddelelser, der henvises til
flyvelederen.
8.1.6.1.2. Varigheden af disse timeouts skal være aftalt bilateralt.8.1.6.1.3. Udløbet af timeout'et ved den overførende enhed skal resultere i,
at der udsendes en advarsel til den overførende flyveleder for at
angive behovet for at initiere en telefonkoordinering.
8.1.6.1.4. Anbefalinger
1.EnadvarselbørvisestildenATC-positionidenaccepterende
enhed, som er ansvarlig for flyvningen, når timeout'et i den
overførendeenhederforestående.
2.Advarslenbørtagehensyntil besvarelsenstransmissionstid.
8.1.6.1.5. Systemer skal være i stand til at behandle besvarelser, der
modtages efter udløbet af timeout'et.
8.1.7. Implementering
8.1.7.1. Dialogprocedurerne henvender sig til to faser, nemlig koordine-
ringsfasen 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 kommu-
nikation 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ørselsfasedia-
logprocedure (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ålmedACT-Meddelelsen
Formålet med ACT-Meddelelsen er beskrevet i afsnit 6.3.1. I en
dialogprocedure bruges ACT-meddelelsen til at opfylde disse2000R2082 — DA — 15.06.2002 — 001.001 — 41
▼B
krav forudsat, at overførselsbetingelserne for flyvningen er stan-
dardbetingelser og at den overførende flyveleder ikke kræver at
henvise flyvningen til den accepterende flyveleder for accept.
8.2.2. IndholdafMeddelelse
Indholdet af den ACT-meddelelse, der bruges i dialogproceduren,
skal være som beskrevet for ACT-meddelelsen i afsnit 6.3.2.
8.2.3. ReglerforAnvendelse
8.2.3.1. Generelt
8.2.3.1.1. Reglerne for anvendelse er som beskrevet for ACTen i afsnit 6.3
med undtagelse af de specielle regler, der er beskrevet i dette
afsnit.
8.2.3.1.2. Der skal sendes en ACT-meddelelse for en flyvning med stan-
dardoverførselsbetingelser, hvis den overførende flyveleder ikke
kræver, at flyvningen skal henvises til den accepterende flyve-
leder.
NOTEHvis disse krav ikke gælder sendes en RAP (se afsnit 8.3
3Meddelelse omHenvistAktiveringsforslag).
8.2.3.1.3. AnbefalingDer børinitieres en ny koordineringsprocedure, hvis
der returneres en Meddelelse om Afvisning af Koordinering
(RJC)somreaktionpåenACT-meddelelse.
8.2.3.2. Behandling i den Modtagende Enhed
8.2.3.2.1. Meddelelsen kontrolleres i forhold til filteret for at bekræfte, at de
foreslåede betingelse er standard.
8.2.3.2.2. Meddelelsen skal behandles som en RAP-meddelelse, hvis:
— overførselsbetingelserne viser sig at være ikke-standard;
— der ikke kan findes en tilsvarende systemflyveplan og der er
tilstrækkelig information tilgængelig til at identificere, hvor-
vidt 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,foratuoverensstemmelsenkanløses.
8.2.4. Kvittering forACT
8.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 stan-
dard;
— 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 standard-
overførselsbetingelser ved den accepterende enhed.
8.2.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke er modtaget nogen kvittering for en ACT-medde-
lelse, 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ålmedRAP-Meddelelsen
RAP-meddelelsen opfylder de følgende, operationelle krav ud
over de, der er specificeret for ACT-meddelelsen i afsnit 6.3:
— forslaget ved den overførende flyveleder og henvisningen til
den accepterende flyveleder af flyvninger med ikke-standard
overførselsbetingelser;2000R2082 — DA — 15.06.2002 — 001.001 — 42
▼B
— at tillade flyvelederen, hvis han/hun ønsker at gøre dette, at
tvinge henvisningen til den accepterende flyveleder af stan-
dard overførselsbetingelser for en specifikflyvning.
8.3.2. IndholdafMeddelelse
Indholdet i RAP-meddelelsen skal være de samme data som
beskrevet for ACT-meddelelsen (afsnit 6.3) og kan frivilligt
indbefatte det følgende dataelement:
— årsag, angivende manuel henvisning (kun tilgængelig i
ADEXP).
8.3.3. ReglerforAnvendelse
8.3.3.1. Generelt
8.3.3.1.1. Der skal sendes en RAP-meddelelse i stedet for ACT-medde-
lelsen 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 over-
fø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 transmis-
sion.
8.3.3.1.3. AnbefalingDet tidspunkt, hvor RAP-meddelelsen transmitteres
automatisk,børvisessammenmeddensindhold.
8.3.3.1.4. Den relevante arbejdsposition skal underrettes om transmissionen
af RAP-meddelelsen.
8.3.3.2. Behandling i den Modtagende Enhed
8.3.3.2.1. Det ATC-system, som modtager en RAP-meddelelse, skal forsøge
forbindelse med den tilsvarende flyveplan.
8.3.3.2.2. Hvis der findes en tilsvarende flyveplan og der ikke er nogen
uoverensstemmelse til stede i meddelelsen, som ville forhindre
korrekt behandling:
— skal det operationelle indhold henvises til den accepterende
flyveleder;
— skal en SBY returneres.
8.3.3.2.3. AnbefalingEn angivelse af årsagen til henvisningen (ikke-stan-
dardbetingelser ellermanuelhenvisning)børværeindeholdt.
8.3.3.2.4. Hvis meddelelsen ikke kan forbindes med en flyveplan eller hvis
der findes en uoverensstemmelse, som forhindrer korrekt behand-ling af meddelelsen, da:
— skal det operationelle indhold af meddelelsen vises ved
sektoren;
og
— en SBY-meddelelse skal returneres;
og
— en flyveplan skal dannes.
8.3.3.2.5. I alle andre tilfælde skal der ikke kvitteres for meddelelsen.8.3.3.3. Manuel Igangsættelse
8.3.3.3.1. RAPen vil, når den bruges til at tvinge henvisningen af en fore-
slå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 transmissionstidbørvære tilladt ved den position, der
eransvarligforflyvningens koordinering.
8.3.3.4. Tidsparametre for AutomatiskTransmission
Tiden/distancen før den grænse, hvor RAP-meddelelser automa-
tisktransmitteres, sk al være den samme som for ACT-
meddelelserne.2000R2082 — DA — 15.06.2002 — 001.001 — 43
▼B
8.3.4. Kvittering forRAP
8.3.4.1. Kvittering
Der skal kvitteres for meddelelsen ved genereringen og transmis-
sionen af en SBY-meddelelse.
8.3.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen SBY-meddelelse som en kvittering
for en RAP-meddelelse, skal en advarsel vises ved den ATC-posi-
tion, som er ansvarlig for flyvningens koordinering.
8.3.5. OperationelBesvarelseafRAP
Den accepterende flyveleder kan enten acceptere, stille et mod-
forslag om eller afvise overførselsbetingelser.
8.3.5.1. Accept
8.3.5.1.1. Når den accepterende flyveleder vælger at acceptere de foreslåede
overførselsbetingelser, skal en ACP-meddelelse returneres.
8.3.5.1.2. Så snart som ACP-meddelelse er blevet modtaget, bliver RAP-
meddelelsesdataene operationelt bindende for begge ATC-enhe-
derne. De koordinerede overførselsbetingelser og det faktum, at
ACP er blevet modtaget, skal forelægges for den overførende
flyveleder.
8.3.5.2. Mod-Forslag
Når den accepterende flyveleder vælger at stille et mod-forslag
om overførselsbetingelserne, skal der returneres en CDN-medde-lelse.
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. Ennykoordineringsprocesbørdainitieres.
NOTEMedhensyntilanbefalingen i8.3.5.3,vildennyekoordi-
neringidefleste tilfælde væremedenandenenhed.
8.3.6. Eksempler
8.3.6.1. ICAO
(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M)
8.3.6.2. ADEXP
-TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP
LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES
EGBB -ARCTYP B757
8.4. Revideringsmeddelelse (REV)
8.4.1. FormålmedREV-Meddelelsen
Formålet med REV-meddelelsen er beskrevet i afsnit 7.3.1. I en
dialogprocedure bruges REV-meddelelsen til at opfylde disse
krav, under forudsætning af at overførselsbetingelserne for
flyvningen er standard og at den overførende flyveleder ikke
kræver at henvise flyvningen til den accepterende flyveleder for
accept.
8.4.2. IndholdafMeddelelse
Indholdet af REV-meddelelsen skal være som beskrevet for REV-
meddelelsen i afsnit 7.3.2.
8.4.3. ReglerforAnvendelse
8.4.3.1. Generelt
8.4.3.1.1. Der kan sendes én eller flere REV-meddelelser til den enhed, som
en flyvning for øjeblikket er blevet koordineret til ved brug af en
Aktiverings- eller RAP-meddelelse.
8.4.3.1.2. REV-meddelelser skal sendes under de betingelser, som er speci-
ficeret i afsnit 7.3.3.1 for flyvninger med standard
overførselsbetingelser, hvilke flyvninger den overførende flyve-
leder ikke kræver bliver henvist til den accepterende flyveleder.2000R2082 — DA — 15.06.2002 — 001.001 — 44
▼B
8.4.3.2. Initiering af Transmission
REV-meddelelsen skal transmitteres straks efter en detektering af
en ændring i de koordineringsdata, der påkrævet skal koordineres
som beskrevet i afsnit 7.3.3.
8.4.3.3. Behandling i den Modtagende 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 stan-
dard, 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,foratuoverensstemmelsenkanløses.
8.4.4. Kvittering forREV
8.4.4.1. Kvittering
8.4.4.1.1. Hvis der skal kvitteres for en REV-meddelelse, skal den kvitteres
ved:
— en LAM-meddelelse, hvis overførselsbetingelserne har vist sig
at være standard;
— en SBY-meddelelse, hvis overførselsbetingelserne har vist sig
at være ikke-standard.
8.4.4.1.2. Når der er modtaget en LAM, bliver det operationelle indhold af
REV-meddelelsen operationelt bindende til begge ATC-enhe-
derne.
8.4.4.1.3. Hvor det er aftalt bilateralt, kan en ACP anvendes i stedet for en
LAM for at angive accepten ved den accepterende enhed af en
REV, som indeholder standardoverførselsbetingelser.
8.4.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen kvittering for en REV-meddelelse,
skal en advarsel vises ved den ATC-position, som er ansvarlig for
koordineringen af flyvningerne.
8.4.5. OperationelBesvarelseafREV
Idet REV-meddelelsen bruges til at sende standard overførselsbe-
tingelser 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ålmedRRV-Meddelelsen
RRV-meddelelsen skal sørge for revideringen af tidligere sendte
og aftalte betingelser i de følgende tilfælde:
— når de foreslåede overførselsbetingelser i revideringen er ikke-
standard;
— når den foreslåede revidering er standard, men den overfø-
rende flyveleder ønsker at henvise revideringen til den
accepterende flyveleder.2000R2082 — DA — 15.06.2002 — 001.001 — 45
▼B
8.5.2. IndholdafMeddelelse
Indholdet af RRV-meddelelsen skal være som beskrevet for REV-
meddelelsen (afsnit 7.3.2) og kan frivilligt indbefatte det følgende
dataelement:
— årsag, angivende manuel henvisning (kun tilgængelig i
ADEXP).
8.5.3. ReglerforAnvendelse
8.5.3.1. Generelt
Der skal sendes én eller flere RRV-meddelelser i stedet for REV-
meddelelser for hver revidering, hvis enten:
— det overførende system har bestemt overførselsbetingelserne
som værende ikke-standard;
eller
— den overførende flyveleder har angivet, at de foreslåede over-
førselsbetingelser skal henvises til den accepterende
flyveleder. Denne anvendelse af RRVen er valgfri.
8.5.3.2. Initiering af Transmission
RRV-meddelelsen skal transmitteres straks efter detekteringen af
en ændring i koordineringsdataene eller når den initieres manuelt.
8.5.3.3. Behandling i den Modtagende Enhed
8.5.3.3.1. Hvis der findes en tilsvarende flyveplan i den koordinerede
tilstand og hvis der ikke findes nogen uoverensstemmelse, som
ville forhindre en korrekt behandling af meddelelsen, da:
— skal der kvitteres for RRV-meddelelsen;
— i alle andre tilfælde skal der ikke kvitteres for meddelelsen.
8.5.3.3.2. De foreslåede overførselsbetingelser skal vises ved den ATC-
position, som er ansvarlig for flyvningens koordinering.
8.5.3.3.3. AnbefalingEn indikation af årsagen til henvisningen (ikke-stan-
dardbetingelser ellermanuelhenvisning)børindbefattes.
8.5.4. Kvittering forRRV
8.5.4.1. Kvittering
Der skal kvitteres for meddelelsen ved at generere og transmittere
en SBY-meddelelse.
8.5.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen SBY-meddelelse som kvittering
for en RRV-meddelelse, skal der vises en advarsel ved den
ATC-position, som er ansvarlig for koordineringen af flyvningen.
8.5.5. OperationelBesvarelseafRRV
Den accepterende flyveleder kan enten acceptere, stille et mod-
forslag om eller afvise en RRV-meddelelse.
8.5.5.1. Accept
Når den accepterende flyveleder vælger at acceptere de foreslåede
rettelser til de aftalte overførselsbetingelser, skal der returneres en
ACP-meddelelse.
8.5.5.2. Mod-Forslag
Når den accepterende flyveleder vælger at stille et mod-forslag
om overførselsbetingelser, skal der returneres en CDN-medde-
lelse.
8.5.5.3. Afvisning
Når den accepterende flyveleder vælger at afvise de foreslåede
rettelser i de aftalte overførselsbetingelser:
— skal en RJC-meddelelse returneres;
og
— en ny koordineringsproces skal initieres.
Afvisning er underforstået, hvis der hverken modtages en ACP-
eller en CDN som reaktion på RRV-meddelelsen.2000R2082 — DA — 15.06.2002 — 001.001 — 46
▼B
8.5.6. Eksempler
8.5.6.1. ICAO
(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)
8.5.6.2. ADEXP
-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA
-PTID BNE -TO 1226 -TFL F310 -ADES EGBB
8.6. Stand-by Meddelelse (SBY)
8.6.1. FormålmedSBY-Meddelelsen
SBY-meddelelsen kvitterer for modtagelsen af en meddelelse, der
foreslår overførselsbetingelser, og angiver, at forslaget er blevet
henvist til flyvelederen for en beslutning.
8.6.2. IndholdafMeddelelse
SBY-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;— Meddelelseshenvisning.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
8.6.3. ReglerforAnvendelse
8.6.3.1. Generelt
SBY-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 forSBY
Der skal ikke kvitteres for SBY-meddelelsen.
8.6.5. Eksempler
8.6.5.1. ICAO
(SBYL/E027E/L002)
8.6.5.2. ADEXP
-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002
8.7. Acceptmeddelelse (ACP)
8.7.1. FormålmedACP-Meddelelsen
ACP-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. IndholdafMeddelelse
ACP-meddelelsen består af de følgende dataemner:
— Obligatoriske data — meddelelsen skal indeholde:
— Meddelelsestype;2000R2082 — DA — 15.06.2002 — 001.001 — 47
▼B
— 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,formaterogfeltindholderspecifi-
ceretiAnneksA.
8.7.3. ReglerforAnvendelse
8.7.3.1. Generelt
8.7.3.1.1. ACPens Meddelelseshenvisning skal indbefatte Meddelelsesnum-
meret 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 automatiskved 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ørselsbetin-
gelser være bindende for begge enheder.
8.7.3.2. Behandling i den Modtagende Enhed
8.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 forACP
8.7.4.1. Kvittering
8.7.4.1.1. Der skal ikke returneres en LAM, hvor ACPen anvendes som en
automatiskbesvarelse 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 Kvittering
Hvis 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. Eksempler
8.7.5.1. ICAO
(ACPL/E027E/L002-18/FRQ/242150)
8.7.5.2. ADEXP
-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002 -FREQ 2421502000R2082 — DA — 15.06.2002 — 001.001 — 48
▼B
8.8. Koordineringsmeddelelse (CDN)
8.8.1. FormålmedCDN-Meddelelsen
CDN-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ørselsbetin-
gelser ved den accepterende flyveleder til den overførende
flyveleder.
8.8.2. IndholdafMeddelelse
CDN-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
emnerellerdembegge:
— Estimatdata (hvis det er en ICAO-meddelelse) eller Over-
førselsflyveniveau (hvisdeterenADEXP-meddelelse);
— AnmodningomDirekteRutestyring.
— Bilateralt aftalte data — De følgende data kan også være
indbefattet, når det er aftalt bilateralt:
— Frekvens.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
8.8.3. ReglerforAnvendelse
8.8.3.1. Generelt
8.8.3.1.1. CDN-meddelelser skal kun initieres af den accepterende flyve-
leder.
8.8.3.1.2. De skal bruges til at transmittere et mod-forslag fra den accepte-
rende flyveleder til den overførende flyveleder.
NOTEDette kan ske i en dialog somen 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-medde-
lelsen 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 medde-
lelse 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 medde-
lelsenfradenandenførmodtagelsenafkvitteringen.2000R2082 — DA — 15.06.2002 — 001.001 — 49
▼B
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-mand-
skab.
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-posi-
tion, 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 uoverens-
stemmelse, som forhindrer korrekt behandling af meddelelsen,
skal der ikke returneres nogen SBY.
8.8.4. Kvittering forCDN
8.8.4.1. Kvittering
Under de betingelser, der er specificeret ovenfor, skal der kvit-
teres for CDN-meddelelsen ved genereringen og transmissionen
af en SBY-meddelelse.
8.8.4.2. Tilfælde af Ingen Kvittering
Hvis 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. OperationelBesvarelseafCDN
Flyvelederen kan enten acceptere eller afvise de overførselsbetin-
gelser, som er foreslået i en CDN-meddelelse.
8.8.5.1. Accept
Nå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-medde-
lelse(udtrykkelig afvisning).
NOTEDen foreslåede koordination afvises stiltiende, hvis der
ikke er blevet modtaget nogen accept til tidspunktet for
CDN-meddelelsenstimeout.
8.8.6. Eksempler
8.8.6.1. ICAO
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A
8.9. Meddelelse om Afvisning af Koordinering (RJC)
8.9.1. FormålmedRJC-Meddelelsen
RJC-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.2000R2082 — DA — 15.06.2002 — 001.001 — 50
▼B
8.9.2. IndholdafMeddelelse
RJC-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;
— Meddelelseshenvisning.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
8.9.3. ReglerforAnvendelse
8.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 accep-
terende 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 modtagelsenafenRJC-meddelelse bør
der initieres en ny koordineringssekvens, som afspejler telefon-
koordineringen,nårdeteranvendeligt.
8.9.3.2. Behandling i den Modtagende Enhed8.9.3.2.1. Hvis der er fundet en tilsvarende meddelelse, som RJC-medde-
lelsen 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 forRJC
8.9.4.1. Kvittering
Der skal kvitteres for RJC-meddelelse ved genereringen og trans-
missionen af en LAM meddelelse.
8.9.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke er modtaget nogen LAM-meddelelse som en kvitte-
ring for en RJC-meddelelse, skal der vises en advarsel ved den
ATC-position, som er ansvarlig for koordineringen af flyvnin-
gerne.
8.9.5. Eksempler
8.9.5.1. ICAO
(RJCMC/E746E/MC324)
8.9.5.2. ADEXP
-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E
-SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FACMC -SEQNUM 324
9. DIALOGPROCEDURE — OVERFØRSEL AF KOMMUNI-
KATION
9.1. Generelt
9.1.1. Introduktion
9.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 implemen-
teres, medmindre enheden enten anvender de
koordineringsfaciliteter, der er beskrevet i Afsnit 6 (Grundlæg-
gende Procedure — Obligatoriske Meddelelser), eller de, som er
beskrevet i Afsnit 8 (Dialogprocedure — Koordinering).2000R2082 — DA — 15.06.2002 — 001.001 — 51
▼B
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. Meddelelsessekvens
9.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ørselafKommunikation
9.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ændringsmedde-
lelse (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 trafikregule-
ring.
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.Ietsådanttilfældevilledetikkeværenødvendigt
for den anden enhed at indføre nogen som helst medde-
lelsertilattilkendegive overførselafkommunikation.
9.2. Overførselsinitieringsmeddelelse (TIM)
9.2.1. FormålmedTIM-Meddelelsen
Formålet med TIMen er:
— at tilkendegive Overførselsinitieringshændelsen (TI) (slut-
ningen af koordineringsfasen og starten på overførselsfasen);
— samtidigt at videresende overordnede kontroldata fra den
overførende til den accepterende enhed.
9.2.2. IndholdafMeddelelse
TIM 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,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.2.3. ReglerforAnvendelse
9.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 bila-
teralt aftalt afstand fra grænsen.
9.2.3.1.2. En TIM-meddelelse skal også sendes automatisk, når Frekvensan-
modningsmeddelelsen (ROF) modtages af den overførende enhed.2000R2082 — DA — 15.06.2002 — 001.001 — 52
▼B
9.2.3.1.3. Der skal ikke sendes en TIM, før flyvningen er blevet koordi-
neret.
9.2.3.1.4. TIM-meddelelsen skal indeholde de seneste data, der er tilgænge-
lige i systemet.
9.2.3.2. Tidsparametre for Transmission9.2.3.2.1. TIM-genereringsparameteren skal være en Variabel Systempara-
meter, som kan ændres baseret på bestemmelserne i LoAene.
9.2.3.2.2. AnbefalingTIM-genereringssystemparameteren bør være defi-
neretsærskiltforhvertafCOPerne.
9.2.3.2.3. Koordineringspartnerne skal indbefatte TIM-genereringsparame-
trene 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æl-
dende 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 forTIM
9.2.4.1. Kvittering
Hvis 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 Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring 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 AMM253
9.3. Supplerende Datameddelelse (SDM)
9.3.1. FormålmedSDM-Meddelelsen
9.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 accepte-
rende 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. IndholdafMeddelelse
9.3.2.1. Meddelelser fra den Overførende Enhed
SDM-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;2000R2082 — DA — 15.06.2002 — 001.001 — 53
▼B
— Tildelt Stignings-/Nedstigningsrate;
— Klareret Flyveniveau.
9.3.2.2. Meddelelser fra den Accepterende Enhed
SDMen skal indeholde de følgende data:
— Meddelelsestype;
— Meddelelsesnummer;— Luftfartøjsidentifikation;
— Frekvens.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.3.3. ReglerforAnvendelse
9.3.3.1. Meddelelser fra den Overførende Enhed
9.3.3.1.1. SDM-meddelelser transmitteres efter initieringen af overførsels-
fasen (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
forudforoverførslenafkommunikation.
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 tids-
punkt 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 Enhed
9.3.3.2.1. SDM-meddelelser kan transmitteres for at angive den frekvens,
på hvilken flyvningen skal kontakte den accepterende enhed.
NOTEEnhederkanbilateralt aftale atsendeandeninformation.
En sådan overførsel er ikke defineret i og er derfor ikke
endelafdennestandard.
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 Enhed
9.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 forSDM
9.3.4.1. Kvittering
Der skal kvitteres for SDM-meddelelsen ved genereringen og
transmissionen af en LAM-meddelelse.2000R2082 — DA — 15.06.2002 — 001.001 — 54
▼B
9.3.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring 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 290
9.4. Forslag om Overdragelse (HOP)
9.4.1. FormålmedHOP-Meddelelsen
Formålet med HOP-Meddelelsen er:
— for den overførende flyveleder at henlede den accepterende
flyveleders opmærksomhed til en specifik flyvning for over-
dragelsesformål;
— for den overførende flyveleder at foreslå flyvningen til over-
dragelse 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 ikkekræverdenaccepterende flyve-
ledersgodkendelse.
9.4.2. IndholdafMeddelelse
HOP-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,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.4.3. ReglerforAnvendelse
9.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 udoverHOPen.
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ærskiltforhvertCOP.2000R2082 — DA — 15.06.2002 — 001.001 — 55
▼B
9.4.3.2. Behandling i den Modtagende Enhed
9.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 flyve-
leder 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,
hvisdetbetragtessomværendeoperationelt 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 forHOP
9.4.4.1. Kvittering
Hvis 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 Kvittering
Hvis der ikke er modtaget nogen LAM-meddelelse som en kvitte-
ring 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 STJ
9.5. Frekvensanmodningsmeddelelse (ROF)
9.5.1. FormålmedROF-Meddelelsen
ROFen 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 accepte-
rende 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. IndholdafMeddelelse
ROF-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,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.5.3. ReglerforAnvendelse
9.5.3.1. Generelt9.5.3.1.1. ROF-meddelelsen skal initieres manuelt af den accepterende
flyveleder.2000R2082 — DA — 15.06.2002 — 001.001 — 56
▼B
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 Enhed
9.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 forROF
9.5.4.1. Kvittering9.5.4.1.1. Hvis ROF-meddelelsen utvetydigt kan forbindes med en flyve-
plan, 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 Kvittering
Hvis der ikke er modtaget nogen LAM-meddelelse som en kvitte-
ring 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 AMM253
9.6. Frekvensændringsmeddelelse (COF)
9.6.1. FormålmedCOF-Meddelelsen
9.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ørselsbetin-
gelser, når den har etableret radiokommunikation med den
accepterende flyveleder.
9.6.2. IndholdafMeddelelse
COF-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,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.6.3. ReglerforAnvendelse
9.6.3.1. Generelt9.6.3.1.1. COF-meddelelsen skal initieres manuelt af den overførende flyve-
leder.2000R2082 — DA — 15.06.2002 — 001.001 — 57
▼B
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)udoverCOFen.
9.6.3.2. Behandling i den Modtagende Enhed
9.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 forCOF
9.6.4.1. Kvittering
9.6.4.1.1. Hvis COF-meddelelsen utvetydigt kan forbindes med en flyve-
plan, 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 Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring 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 AMM253
9.7. Meddelelse om Manuel Overtagelse af Kommunikation
(MAS)
9.7.1. FormålmedMAS-Meddelelsen
MASen sendes af den accepterende enhed til den overførende
enhed og angiver derved, at der er blevet etableret tovejsradio-
kontakt med flyvningen.
9.7.2. IndholdafMeddelelse
MAS-meddelelsen skal indeholde de følgende dataemner:
— Meddelelsestype;
— Meddelelsesnummer;
— Luftfartøjsidentifikation.
NOTEDataindsættelsesregler,formaterogfeltindholderspecifi-
ceretiAnneksA.
9.7.3. ReglerforAnvendelse
9.7.3.1. Generelt
9.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 fore-
lægges for flyvelederen.
9.7.4. Kvittering forMAS
9.7.4.1. Kvittering
9.7.4.1.1. Hvis MAS-meddelelsen utvetydigt kan forbindes med en flyve-
plan, 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.2000R2082 — DA — 15.06.2002 — 001.001 — 58
▼B
9.7.4.2. Tilfælde af Ingen Kvittering
Hvis der ikke modtages nogen LAM-meddelelse som en kvitte-
ring 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 AMM2532000R2082 — DA — 15.06.2002 — 001.001 — 59
▼B
ANNEKSA (Retningsgivende)
DATAINDSÆTTELSESREGLER
INDHOLD
A.1. Formål
A.2. Fælles MeddelelsesformaterA.3. Meddelelsestype
A.4. Meddelelsesnummer
A.5. MeddelelseshenvisningA.6. Luftfartøjsidentifikation
A.7. SSR-Tilstand og -Kode
A.8. AfgangsflyvepladsA.9. Estimatdata
A.10. Koordineringspunkt
A.11. DestinationsflyvepladsA.12. Luftfartøjsnummer og -Type
A.13. Rute
A.14. Andre FlyveplansdataA.15. Koordineringsstatus og -Årsag
A.16. Tildelt Kurs (kun ADEXP)
A.17. Tildelt Hastighed (kun ADEXP)A.18. Tildelt Stignings-/Nedstigningsrate (kun ADEXP)
A.19. Direkte Klarering (kun ADEXP)
A.20. Anmodning om Direkte RutestyringA.21. Position (kun ADEXP)
A.22. Frigivelsesindikation (kun ADEXP)
A.23. FrekvensA.24. Årsag (kun ADEXP)
A.25. Klareret Flyveniveau (kun ADEXP)
A.26. Overførselsflyveniveau (kun ADEXP)A.27. Estimeret Starttid
A.28. Henvisningsmeddelelsestype
A.29. Flyvningens art
A.30. Udstyrsspecifikation og -status
A.1. Formål
Dette 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 Anven-
delse for en specifikmeddelelse.
A.2. Fælles Meddelelsesformater
A.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.2000R2082 — DA — 15.06.2002 — 001.001 — 60
▼M1
▼B
▼B
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 fore-
kommer, 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 opli-
stede Felttyper.
A.2.2.a I nogle tilfælde anvendes et pseudo-ICAO-felttypenummer, hvis der
ikke findes et passende ICAO-felt. Disse numre består af to cifre,
hvis værdi er lig med eller større end 80.
A.2.3. Alle meddelelser beskrevet i dette dokument kan transmitteres ved
brug af Eurocontrol ADEXP-format. Indholdet, strukturen og anven-
delsen af ADEXP-datafelter skal være i overensstemmelse med
Henvisning 2.
NOTER
1.Kun de Primære ADEXP-datafelter er oplistet i dette Anneks,
bortset fra når forbundne Underfelter kræver en specifik
kommentar.ADEXP-standardenoplisteralle frivillige ogobliga-
toriskeUnderfelter, somerpåkrævedeindenihvertPrimærfelt.
2.Meddelelser beskrevet i Afsnit 9, Dialogprocedure — Overførsel
Kommunikation,erkunbeskrevetiADEXP-format.
A.3. Meddelelsestype
Meddelelsestypen 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: LogiskKvitteringsmeddelelse (Logical Ack nowledgement
Message).
MAC: Meddelelse for Ophævelse af Koordinering (Message for
Abrogation of Co-ordination).
MAS: Manuel Overtagelse af Kommunikation (Manual Assump-
tion 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.ICAO
Felt type 3, element (a).
A.3.2.ADEXP
Primært felt »title«.2000R2082 — DA — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
A.4. Meddelelsesnummer
Meddelelsesnummerdataene indbefatter de identifikatorer, der er
tildelt til den transmitterende og den modtagende enhed, og medde-
lelsessekvensnummeret. 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.ICAO
Felttype 3, element (b).
A.4.2.ADEXP
Primæ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. Meddelelseshenvisning
A.5.1.ICAO
Felttype 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.ADEXP
Primæ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 Under-
felter inden i det Primære felt »refdata« i den OLDI-meddelelse, der
henvises til.
A.6. Luftfartøjsidentifikation
A.6.1.ICAO
Felttype 7, element (a).
A.6.2.ADEXP
Primært felt »arcid«.
A.7. SSR-Tilstand og -Kode
Enten:1. hvis den er kendt, den SSR-tilstand/kode på hvilken den modta-
gende enhed kan forvente at luftfartøjet responderer ved
kontrolpunktsoverførslen;
eller
2. en indikator for, at der anmodes om SSR-koden fra den modta-
gende enhed.
A.7.1.ICAO
Felttype 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.ADEXP
Primært felt »ssrcode«.2000R2082 — DA — 15.06.2002 — 001.001 — 62
▼B
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. Afgangsflyveplads
A.8.1.ICAO
Felttype 13, element (a).
A.8.2.ADEXP
Primært felt »adep«.
A.9. Estimatdata
A.9.1.Generelt
A.9.1.1. Estimatdata skal indeholde COPet, tidspunkt ved COPet og overfør-
selsniveau.
A.9.1.2. Koordineringspunktet skal være defineret som enten et kendt refe-
rencepunkt, 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 over-
førselsbetingelser.
A.9.1.4. AnbefalingForstigendeellernedstigendeflyvningerbørestimatda-
taene også indeholde supplerende krydsningsdata og
krydsningsbetingelser.
A.9.1.5. Hvis de bruges, skal de supplerende krydsningsdata indeholde det
supplerende krydsningsniveau ved kontrolpunktsoverførslen. Kryds-
ningsbetingelserne 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.ICAO
Felttype 14.
A.9.3.ADEXP
Primæ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 defi-
neret i den samme meddelelse ved det Primære felt »REF« eller
»GEO«.
A.10. Koordineringspunkt
A.10.1.Generelt
A.10.1.1. Det koordineringspunkt, som der henvises til af den overførende og
den modtagende ATC-enhed, med henblikpå den pågældende over-
førsel.
A.10.1.2. Koordineringspunktet skal være defineret som enten et kendt refe-
rencepunkt, en afstand og pejling fra et kendt referencepunkt eller
en breddegrad og en længdegrad.
A.10.2.ICAO
Felt 14, element (a).
A.10.3.ADEXP
Primært felt »cop«, som indeholder:
— et kendt referencepunkt; eller2000R2082 — DA — 15.06.2002 — 001.001 — 63
▼B
— en pejling og en distance fra et kendt referencepunkt som defi-
neret i den samme meddelelse ved det Primære felt »REF« eller
»GEO«.
A.11. Destinationsflyveplads
A.11.1.ICAO
Felt 16, element (a).
A.11.2.ADEXP
Primære felter »ades«.
A.12. Luftfartøjsnummer og -Type
Luftfartøjsnummeret og –typen skal indeholde typen af luftfartøj.
Luftfartsnummeret skal være indeholdt i tilfælde af formationsflyv-
ninger.
A.12.1.ICAO
Felttype 9 i felttype 22-format. Element c i felttype 9 skal enten
indeholde den wake turbulence kategori, der er passende for luftfar-
tøjets type, eller bogstavet »Z«.
A.12.2.ADEXP
Primært felt »arctyp«. Derudover, hvis der er mere end ét luftfartøj i
flyvningen, det primære felt »nbarc«.
A.13. Rute
Begge 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.Indhold
A.13.1.1. Fl yvninger, 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. Fl yvninger, der fortsætter Uden for ATS-Rute
— det punkt, hvorfra flyvningen fortsætter på det direkte ruteseg-
ment;
— elementet »DCT«;— det punkt, hvortil flyvningen fortsætter på det direkte ruteseg-
ment.
A.13.2.Format
A.13.2.1. ICAO
Felttype 15, i felttype 22-format.
A.13.2.2. ADEXP
Primært felt »route«.
A.14. Dette felt giver mulighed for i særlige meddelelser at medtage
flyveplansdata, som normalt ikke udgør en del af koordineringspro-
ceduren, og som ikke er beskrevet andetsteds i annekset. Følgende
elementer kan medtages, som beskrevet i reference 1, bilag 2, felt-
type 8 og 18.
— Flyveregler2000R2082 — DA — 15.06.2002 — 001.001 — 64
▼M1
▼M1
— Registreringsmarkeringer
— Navn på luftfartsselskab
— Årsag til særlig ATS-behandling— Type— Virkningsgrad— Navn på afgangs-, bestemmelses- og alternativ lufthavn
— Bemærkninger i almindeligt sprog.
A.14.1.ICAO
Felttype 8, element a) flyveregler i felttype 22-format.
Et eller flere af følgende felttype 18-elementer i felttype 22-format:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2.ADEXP
Primærfelter: »fltrul«, »depz«, »destz«, »opr«, »per«, »reg«, »rmk«,
»altrnt1«, »altrnt2«, »sts«, og »typz«.
A.15. Koordineringsstatus og -Årsag
Koordineringsstatus 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 koordi-
neringsdialog 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.ICAO
A.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.ADEXP
Primært felt »cstat«.
Ekstra emner »coordstatusident« og »coordstatusreason« skal inde-
holde 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.2000R2082 — DA — 15.06.2002 — 001.001 — 65
▼B
▼B
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 tidli-
gere 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, indika-
toren »ZZZ« i feltets cifferdel, f.eks. når en SDM-meddelelse
bruges for at indikere, at en tidligere tildelt stignings-/nedstig-
ningsrate 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 slut-
punktsdesignatorer 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 Rutestyring
Anmodning 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.ICAO
Felttype 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.2000R2082 — DA — 15.06.2002 — 001.001 — 66
▼B
— forkortelsen »DCT«,
— efterfulgt af det punkt, der er placeret på den originale flyve-
plansrute, 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.ADEXP
Primæ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.Generelt
A.21.1.1. Flyvningens aktuelle position enten udtrykt i geografiske koordi-
nater 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. Frekvens
A.23.1.ICAO
Felttype 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 decimal-
pladser.
A.23.2.ADEXP
Primært felt »freq«.
A.24. Årsag(kun ADEXP)
Primært felt »reason«, som indeholder værdien »MANUAL« for
meddelelser, der henvises manuelt.2000R2082 — DA — 15.06.2002 — 001.001 — 67
▼B
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 Starttid
A.27.1.ICAO
Felttype 13 element (b).
A.27.2.ADEXP
Primært felt »etot«.
A.28. Henvisningsmeddelelsestype
Feltet indeholder meddelelsestypen som specificeret i afsnit A.1 i
dette Anneks.
A.28.1.ICAO
Felttype 18 i felttype 22-format. Elementets indikator skal være
»MSG«.
A.28.2.ADEXP
Primært felt »msgtyp«.
A.29. Flyvningens art
Dette element skal stemme overens med flyveplanen eller tilsva-
rende data, som stammer fra en alternativ kilde. Bogstavet »X«
indsættes, hvis flyvningens art ikke er angivet i flyveplanen, eller
ikke kendes af andre årsager.
A.29.1.ICAO
Denne art flyvning indsættes som et enkelt bogstav i felttype 22-
format, og under anvendelse af pseudofelttypenummer 80.
A.29.2.ADEXP
Primært felt »flttyp«.
A.30. Udstyrsspecifikation og -status
Dette element angiver egenskaber og status for udstyr, som enten er
en forudsætning for flyvning i visse luftområder eller på visse ruter,
eller har en væsentlig indvirkning på leveringen af ATC-tjeneste.
Specifikationerne fastholdes i flyveplanen, men kan være forkert
eller være blevet ændret under flyvningen. Udstyrsspecifikation og
-status angiver den nuværende status.
Status for følgende elementer angives:
— RVSM
— 8,33 kHz RTF-udstyr
Status for nedenstående skal anføres for flyvninger, som er anført
som statsflyvninger under flyvningens art i flyveplanen, hvor det
vides, at 8,33 kHz RTF-udstyr ikke er til rådighed.
— UHF-udstyr.
A.30.1.ICAO
Dataene indføjes i felttype 22-format under anvendelse af pseudo-
feltnummer 81.
Der indsættes to elementer for hver egenskab:
— Udstyrsspecifikationen angives med et enkelt bogstav, som
anført i felttype 10 »Equipment« i ICAO-flyveplanen (se bilag
3 til reference 1), umiddelbart fulgt af2000R2082 — DA — 15.06.2002 — 001.001 — 68
▼M1
▼M1
— en elementseparator — skråstreg (/), som umiddelbart følges af
— status anført med to bogstaver.
Status angives som en af følgende indikatorer, der gælder for
flyvningen:
a) EQ betyder, at flyvningen har udstyret, og at det kan anvendes
under flyvningen
b) NO betyder, at flyvningen ikke har udstyret, eller at det af en
eller anden årsag ikke kan anvendes under flyvningen
c) UN betyder, at der ikke foreligger oplysninger om, hvorvidt
udstyret kan anvendes.
Den første specifikationsgruppe indsættes umiddelbart efter den
skråstreg, der følger efter feltnummeret. De følgende grupper
adskilles af et mellemrum. Rækkefølgen af udstyrsspecifikationsan-
givelserne er uden betydning.
A.30.2.ADEXP
Primærfelt »EQCST«.2000R2082 — DA — 15.06.2002 — 001.001 — 69
▼B
ANNEKSB(Retningsgivende)
SPECIELLE RUTEBEHANDLINGSKRAV
B.1. Introduktion
B.1.1.Generelt
B.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 beggesystemer ved brug af underretnings- og koordineringsmeddelelser.
B.2. Anvendelse af Meddelelser
B.2.1.GrundlæggendeReglerforDirekteRutestyringer
B.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 koordinerings-
punktsdata (estimatdata (ICAO-format) og koordineringsdata
(ADEXP-format) og ruten i de anvendelige meddelelser.
B.2.2.Arkiveret DirekteRute
Nå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-dirigeringerefterABI-ogførACT-Transmission
Der skal sendes en ny ABI-meddelelse med data svarende til den
nye rute.
B.2.4.Gen-dirigeringefterACT-Transmission
B.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.
NOTEDerbrugeskunen REV-meddelelse, hvordenaccepterende
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
annulleresverbalt.
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;2000R2082 — DA — 15.06.2002 — 001.001 — 70
▼B
7 Luftfartøjsidentifikation. Elementer b og c skal ikke indbe-
fattes, med mindre en revidering eller SSR-koden koordineres
samtidigt;
13 Afgangsflyveplads;14 Kun Element a, som indeholder det tidligere COP for henvis-
ningsformål;
16 Destination;
22 Felt 14, der indeholder estimatdataene for de nye grænsekryd-
sningsbetingelser 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, destinati-
onen, 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. Feltindhold
B.3.1.ATS-Ruter
For flyvninger, som genstyres via en alternativ ATS-Rute, har
estimat- og rutefelterne samme format som for ABI- og ACT-
meddelelserne.
B.3.2.DirekteRuter
B.3.2.1. Koordineringspunktet i estimatdataene skal være grænsekrydsning-
spunktet 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ængde-
grad.
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 bilate-
ralt, 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. Eksempler
B.4.1.DirekteRuter
B.4.1.1. ABI- og ACT-Meddelelser
B.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).2000R2082 — DA — 15.06.2002 — 001.001 — 71
▼B
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 UA134
B.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-Meddelelse
Flyvning HZT2051 var tidligere genstand for den følgende ACT-
meddelelse (eller ADEXP-ækvivalent):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
Flyvningen dirigeres dernæst fra 40 NM vest for punktet RQAdirekte til MYY. Det nærmest punkt på grænsekrydsningen er2000R2082 — DA — 15.06.2002 — 001.001 — 72
▼B
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)
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 MYY
En efterfølgende revideringsmeddelelse ville angive TDS240026
som COPet.
B.4.2.Gen-dirigeringviaATS-RuterefterACT-Transmission
B.4.2.1. ACT-Meddelelse
Flyvning 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)
2000R2082 — DA — 15.06.2002 — 001.001 — 73
▼B
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)
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)
B.4.2.2. ADEXP-Ækvivalenter
ADEXP-æ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 UJ124
b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA
-PTID XAT -TO 1225 -TFL F290 -ADES DTTA2000R2082 — DA — 15.06.2002 — 001.001 — 74
▼B
ANNEKSC (Informativt)
FASER FOR DIALOGPROCEDURE (SYSCO NIVEAU 1) — MEDDELELSESSEKVENS
Meddelelsessekvens
2000R2082 — DA — 15.06.2002 — 001.001 — 75
▼B
BILAGII
PRÆSENTATION AF UDVEKSLEDE ATS-DATA (ADEXP) UDGAVE 2.0
(Eurocontrols dokumentreference: DPS.ET1.ST09-STD)2000R2082 — DA — 15.06.2002 — 001.001 — 76
▼B
INDHOLDSFORTEGNELSE
OPHAVSRET
FORORD1. OMFANG2. HENVISNINGER3. DEFINITIONER, SYMBOLER OG FORKORTELSER
3.1. Notation3.2. Definitioner3.3. Konstruktion3.4. Konventioner3.5. Operatorer3.6. Forkortelser
4. ADEXP-PRINCIPPER
4.1. Tekstmæssigt, Menneskeligt Læseligt Format4.2. Identificerede og Genfindelige Felter4.3. Uigenkendte Felter
5. ADEXP-SYNTAKSREGLER
5.1. Leksikalske Elementer5.2. Felter
6. NORMALISERET BESKRIVELSE AF ADEXP-MEDDELELSER
6.1. Introduktion6.2. Hjælpeudtryk6.3. Definition af Primære Felter6.4. Definition af Underfelter6.5. Gruppe af Meddelelser
ANNEKS A (RETNINGSGIVENDE) FELTDEFINITIONER
ANNEKS B (RETNINGSGIVENDE) CENTRALT INDEKS OVER ADEXP MEDDELELSES-
TITLER
ANNEKS C (RETNINGSGIVENDE) CENTRALT INDEKS OVER RESERVEREDE MEDDELEL-
SESTITLER
ANNEKS D (RETNINGSGIVENDE) CENTRALT INDEKS OVER RESERVEREDE FELTERANNEKS E (INFORMATIVT) INTRODUKTION AF MEDDELELSESGRUPPERANNEKS F (INFORMATIVT) EKSEMPLER PÅ ADEXP-MEDDELELSESFORMATANNEKS G (INFORMATIVT) FREMTIDIGE UDVIKLINGER2000R2082 — DA — 15.06.2002 — 001.001 — 77
▼B
ANGIVELSE AF OPHAVSRET
Dette dokument er frembragt af Eurocontrol Agenturet.
Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for
repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en
hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt
samtykke ved Eurocontrol Agenturet.2000R2082 — DA — 15.06.2002 — 001.001 — 78
▼B
FORORD
1. Ansvarlig Institution
Denne Standard er blevet udviklet og vedligeholdes af User
Requirements Section (Afdelingen for Brugerkrav) i the Central
Flow Management Unit (CFMU) (Enheden for Central Regule-
ring) i the European Organisation for the Safety of Air
Navigation (Den europæiske Organisation for Luftfartens
Sikkerhed) Eurocontrol).
2. EATCHIP-Arbejdsprogramdokument
Denne Standard er blevet frembragt som en indlevering af the
EATCHIP WorkProgramme Dok ument (EWPD) (EATCHIP
Arbejdsprogramdokument), Data Processing Systems Domain
(DPS), Executive Task09.
3. Godkendelse af Standarden
3.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 Perma-
nente Kommission) i 1995 og havde en anvendelsesdato med
effekt fra den 1. december 1997.
4. Teknisk Rettelsesliste og Tekniske Rettelser
Denne Standard holdes under kontrol for at konstatere påkrævede
rettelser eller en teknisk rettelsesliste. Proceduren for vedligehol-
delsen af denne Standard er fastlagt i Anneks H i the Directives
for the Uniform Drafting and Presentation of Eurocontrol Stan-
dard Documents (Direktiverne vedrørende ensartet udarbejdelse
og præsentation af Eurocontrolstandarddokumenter).
Rettelser eller tilføjelser, som påvirker de grundlæggende prin-
cipper 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 Presen-
tation of Eurocontrol Standard Documents (Direktiverne
vedrørende ensartet udarbejdelse og præsentation af Eurocontrol-
standarddokumenter).
Rettelser eller tilføjelser til denne Standard skal foreslås skriftligt
til: CFMU Users Requirements Section (ADEXP), Eurocontrol
Agency.
5. Redaktionelle Konventioner
5.1. Denne Standards format er i overensstemmelse med the Direc-
tives for the Uniform Drafting and Presentation of Eurocontrol
Standard Documents (Direktiverne vedrørende ensartet udarbej-delse 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ær-
ings 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 Standarddokumenter
Denne Standard vedrører:
Eurocontrol-standarddokument for On-Line Data Interchange
(OLDI)2000R2082 — DA — 15.06.2002 — 001.001 — 79
▼B
7. Status af Annekser til denne Standard
Der er 7 Annekser til dette Direktiv, hvor statusen for hver især
er defineret som følger:
Anneks A Retningsgivende;
Anneks B Retningsgivende;Anneks C Retningsgivende;Anneks D Retningsgivende;Anneks E Informativt;Anneks F Informativt;Anneks G Informativt.
8. Anvendt Sprog
Det engelske sprog er blevet anvendt til denne Standards origi-
nale tekst.2000R2082 — DA — 15.06.2002 — 001.001 — 80
▼B
1. OMFANG
1.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 Flyveplans-
behandlingssystem (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 koor-
dineringsmeddelelser 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/mili-
tæ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. HENVISNINGER
2.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-Standard-
dokument var de udgaver, der er angivet for de henvistedokumenter og standarder gyldige.
Der skal øjeblikkeligt tages hensyn til en hvilken som helst revi-
dering af de henviste International Civil Aviation Organisation
(ICAO) Dokumenter for at revidere dette Eurocontrol-Standard-
dokument.
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-Stan-
darddokument og indholdet i disse andre henviste dokumenter,
skal dette Eurocontrol-Standarddokument have forrang.
2.2. Ved offentliggørelsestidspunktet er de dokumenter, som er opli-
stet nedenfor, de der henvises til fra denne Standard, imidlertid
inviteres brugere til at kontrollere brug- og meddelelsesfeltkom-
positionstabellerne 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);2000R2082 — DA — 15.06.2002 — 001.001 — 81
▼B
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 (Eurocon-
trolstandard 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 FORKORTELSER
3.1. Notation
Den 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. Definitioner
Med 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 separa-
torer.
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æsen-
teret 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
blandingafterminal-ognon-terminalsymboler.
3.3. Konstruktion
3.3.1. BNF består af et sæt regler eller konstruktioner af formen:
symbol::= udtrykNOTER1)Notationen »::=«børlæsessom»kanerstattesaf«
2)»Symbol«erklassificeret somnon-terminalt.
3)Delen»udtryk«indeholderterminal-ognon-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. Konventioner
Med henblik på dette Eurocontrol-standarddokument skal de
følgende konventioner gælde:
—Terminalsymboler skrives med versaler.
NOTEIfølge konventionen står terminalsymbolet NIL
terminalfor»intetterminalsymbol« .
Detanvendesivalgsomidetfølgende eksempel:
a::=b(c|NIL)hvorakanerstattesaf(befterfulgt
afc)ellerblotafb.
—non-terminalsymboler (f.eks. den venstre side af en gramma-
tikfremstilling) er skrevet med minuskler.
—Tegn og Strenglitteraler som forekommer inden i reglerne er
henholdsvis omgivet af anførselstegn (') eller dobbelte anfør-
selstegn (").2000R2082 — DA — 15.06.2002 — 001.001 — 82
▼B
Eksempler
1) HYPHEN::= '-'
2) title::= '-' "TITLE" titleid
Det 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. Operatorer
Med 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 paren-
teser »{«kog »}«. 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 paren-
tesen »}« angiver dette tal det maksimale antal gange, som
gruppen af symboler kan forekomme.
Valg (Choice) : Når et antal af alternative symboler kan fore-
komme 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 leksi-
kalske 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.
Eksempel datetime:: = date ! timehhmm
f.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æsenta-
tionen af Løs Sammenkædning inden i en regel kan være
enten Implicit eller Eksplicit
Eksempler1) Implicit:
dct::= '-' "DCT" point point
2) Explicit
dct::= '-' !{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
f.eks. "-DCT NTM RMS".
NOTER
1)Sammenkædningskalaltidhaveforrangiforholdtilvalg.Der
anvendes parenteser »(« og »)« til at forandre udtrykkets
evalueringsrækkefølge.
Eksempel a::= B C | D er ækvivalent
til:a::= (B C) | D
og IKKE til: a::= B (C | D) .
2)I alle regler vil den tilladte tilstedeværelse af separatorer
mellem symbolerneværeimplicitforatbevarelæselighed .2000R2082 — DA — 15.06.2002 — 001.001 — 83
▼B
AnbefalingNår der er risiko for forvirring på grund af forrang
mellem de ovenfor nævnte operatorer, anbefales det at anvende
parenteserforattydeliggøre denønskedeevalueringsrækkefølge.
3.6. Forkortelser
Med henblik på dette Eurocontrol-Standarddokument skal de
følgende forkortelser gælde:
ACH ATC Flyveplansrettelsesmeddelelse (ATC
Flight Plan Amendment Message)
ADEG ATS Dataudvekslingsgruppe (ATS Data
Exchange Group)
ADEXP Præsentation af Udvekslede ATS-Data
(ATS Data Exchange Presentation)
AFIL Flyveplan Indleveret Fra Luften (Air-Filed
Flight Plan)
AFP ATC Flyveplansforslag (ATC Flight Plan
Proposal)
AFTN Luftfartens Faste Telekommunikationsne-
tværk(Aeronautical Fixed
Telecommunication Network)
ANM ATFM Underretningsmeddelelse (ATFM
Notification Message)
AO Luftfartøjsoperator(er) (Aircraft Opera-
tor(s))
APL ATC Flyveplan (ATC Flight Plan)ATC Flyvekontroltjeneste (Air Traffic Control)ATCU Flyvekontroltjenesteenhed(er) (Air Traffic
Control Unit(s))
ATFM Regulering af Afvikling af Lufttrafikken
(Air Traffic Flow Management)
ATS Lufttrafiktjeneste (Air Traffic Services)
BNF Backus Naur Form (Backus Naur Form)
CASA Computer Assisteret Slot-Allokering
(Computer Assisted Slot Allocation)
CIDIN Fælles ICAO Dataudvekslingsnetværk
(Common ICAO Data Interchange
Network)
CFL Klareret Flyveniveau (Cleared Flight
Level)
CFMU Enhed for Central Regulering (Central
Flow Management Unit)
CMTP Common Medium Term Plan (Common
Medium Term Plan)
CNL Annuleringsmeddelelse (Cancellation
Message)
CTOT Beregnet Starttid (Calculated Take-Off
Time)
DPS Domæne for Databehandlingssystemer
(Data Processing Systems Domain)
ECAC Den Europæiske Civile Luftfartskonference
(European Civil Aviation Conference)
EFL Beregnet Flyveniveau (Estimated Flight
Level)
EOBT Forventet Off blockTidspunk t (Estimated
Off-BlockTime)
ETO Beregnet Tidspunkt Over (Estimated Time
Over)
EUROCONTROL Den Europæiske Organisation for Luftfar-
tens Sikkerhed (European Organisation for
the Safety of Air Navigation)
EWPD EATCHIP Arbejdsprogramdokument
(EATCHIP WorkProgramme Document)
FIR Flyveinformationsregion (Flight Informa-
tion Region)
FIW Indlæseterminal for Flyveplaner (Flight
Plan Input Workstation)2000R2082 — DA — 15.06.2002 — 001.001 — 84
▼B
FMP Reguleringsposition (Flow Management
Position)
FNM Flyveunderretningsmeddelelse (Flight Noti-
fication Message)
FPL Flyveplansmeddelelse (ICAO-format)
(Flight Plan Message (ICAO Format))
GAT Generel Lufttrafik(General Air Traffic)
IA Internationalt Alfabet (International
Alphabet)
IAFP Individuelt ATC Flyveplansforslag (Indivi-
dual ATC Flight Plan Proposal)
ICAO Den Internationale Civile Luftfarts Organi-
sation (International Civil Aviation
Organisation)
IFPD Individuelle Flyveplansdata (Individual
Flight Plan Data)
IFPS Integreret System for Førstebehandling af
Flyveplaner (Integrated Initial Flight Plan
Processing System)
IFPU IFPS Enhed (IFPS Unit)IFR Instrumentflyveregler (Instrument Flight
Rules)
ISO Den Internationale Standardiseringsorgani-
sation (International Standards
Organisation)
ITA Internationalt Telegrafalfabet (International
Telegraph Alphabet)
LAM LogiskKvitteringsmeddelelse (Logical
Acknowledgement Message)
LRM LogiskAfvisningsmeddelelse (Logical
Rejection Message)
MAC Meddelelse om Ophævelse af Koordinering
(Co-ordination Abrogation Message)
MFS Meddelelse fra Shanwick(Message from
Shanwick)
OAT Operationel Lufttrafik(Operational Air
Traffic)
OLDI On-Line Dataudveksling (On-Line Data
Interchange)
RFL Anmodet Flyveniveau (Requested Flight
Level)
RFP Erstatningsflyveplan (Replacement Flight
Plan)
RFPD Standard Flyveplansdata (Repetitive Flight
Plan Data)
RPL Standard Flyveplan (Repetitive Flight Plan)RVR Banesynsvidde (Runway Visual Range)
SFL Supplerende Flyveniveau (Supplementary
Flight Level)
SRD Dokument vedrørende Softwarekrav (Soft-
ware Requirements Document)
SSR Sekundær Radar (Secondary Surveillance
Radar)
TACT Taktisk System i CFMUen (Tactical
System of the CFMU)
TOS Trafikorienteringsskema (Traffic Orienta-
tion Scheme)
UIR Øvre Informationsregion (Upper Informa-
tion Region)
VFR Visuelflyveregler (Visual Flight Rules)2000R2082 — DA — 15.06.2002 — 001.001 — 85
▼B
4. ADEXP-PRINCIPPER
4.1. Tekstmæssigt, Menneskeligt Læseligt Format
4.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 Felter
4.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 speci-
fikke nøgleord.
NOTEDet børbemærkes,at vissefelter (de somsyntaksmæssigt
er defineret som indeholdende det leksikale emne
»CHARACTER«) lovligt kan indeholde et tegn »-« som
endelaffeltindholdet.
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 medde-
lelse ikke være relevant for at bestemme dens lovlighed, undtagen
for det første felt (obligatorisktitelfelt (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 defi-
neret 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 udeluk-
kende 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 Felter
4.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 igno-
reret.
4.3.3. Afhængigt af meddelelsestitlen kan det ignorerede felt forårsage
en afvisning af den meddelelse, der analyseres, eller ej.
NOTEDetbørbemærkes,attil trodsforatADEXPerudformet
til at give denne slags fleksibilitet, skal det efter skøn fra2000R2082 — DA — 15.06.2002 — 001.001 — 86
▼B
de, der er ansvarlige for at definere grænsefladekravene,
for hver meddelelse angives, hvorledes systemet bør
reagerepåetuigenkendt 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 genop-
rettelse, 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 medde-
lelser 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ærtFelt
-RFL F330
2)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
indenietlistefelterdenenestelejlighed,hvoretprimært
felt kan anvendes som et underfelt. (Se Eksempel 3
ovenfor)
5. ADEXP-SYNTAKSREGLER
5.1. Leksikalske Elementer
5.1.1. Tegnsæt
5.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 compu-
ternetværkeller over dedik erede computer-computer-forbindelser.
Der findes yderligere et krav om at være i stand til at udveksle
visse ADEXP-meddelelser, typiskrelateret 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
eksempelhulstrimler).Deudgørikkeendelafdettilladte
tegnsætforADEXP-meddelelser.2000R2082 — DA — 15.06.2002 — 001.001 — 87
▼B
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 formateffek-
torer, som er defineret nedenfor:
Grafiske Tegn
a) 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 »/«
Formateffektorer
a) Vognretur
b) Liniefremføring
5.1.2. GrundlæggendeLeksikalske Emner
De 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 ::= HYPHEN
NOTELIM_CHARrepræsentererethvilketsomhelsttilladttegn
bortsetfraHYPHEN(bindestreg),somerreserverettilat
angive begyndelsen af et felt. På den anden side repræ-
senterer CHARACTER et hvilket som helst tilladt
element itegnsættet.
5.1.3. Linier,SeparatorerogSkilletegn
5.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ærdiermedFortegn
5.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.2000R2082 — DA — 15.06.2002 — 001.001 — 88
▼B
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}8
Derfor: -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 stede
5.1.5. Nøgleord
5.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}! <subfield/s or contained
value>
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 under-
felt(er) eller den indeholdte værdi.
NOTE Det er vigtigt at bemærke, at et nøgleord og dets forud-
gå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 IFPL
2) - TITLE IFPL3) - TITLE IFPL
4) -
TITLE IFPL
5.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 semantiskmeningsfulde.
5.1.5.6. De foruddefinerede nøgleord i ADEXP-formatet, som er oplistet
nedenfor, skal ikke gendefineres eller bruges med en anderledesfunktion i specifikke anvendelser af formatet:
TITLE: identificerer en kategori af meddelelser og defi-
nerer det tilsvarende sæt af tilladte primære
felter;
BEGIN: identificerer begyndelsen af et listefelt;2000R2082 — DA — 15.06.2002 — 001.001 — 89
▼B
END: identificerer slutningen på et listefelt;
COMMENT: identificerer et COMMENT-felt
(KOMMENTAR-felt).
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 Defi-
nitionstabel 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. Felter
5.2.1. Feltsyntaks
felt::= grundlæggende_felt | struktureret_felt | liste_feltgrundlæggende_felt::= '-' nøgleord indeholdte_værdier
indeholdte_værdier::= {CHARACTER}
liste_felt::= '-' "BEGIN" nøgleord {underfelter} '-' "END"
nøgleord
struktureret_felt::= '-' nøgleord felt_1 felt_2 ….felt_n
NOTE Ikke '-', men strukturen '-' "BEGIN" går direkte forud for
nøgleordet i tilfælde af listefelterne, som det vil fremgå.
5.2.2. MeddelelsessammensætningUdtryktiFelter
5.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æggendeFelter
5.2.3.1. Syntaksen for et grundlæggende felt skal være som følger:
grundlæggende_felt::= '-' nøgleord indeholdte _værdier
5.2.3.2. »Indeholdte_værdier« definerer den tekst, som tilvejebringer
feltets værdi, og kan ikke indlede noget underfelt.
Eksempel på en regel arctyp::= '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")
NOTE
1) 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. AnbefalingHvisderermereendtoindeholdteværdierindeniet
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ærdierindeniunderfelter.
5.2.4. Listefelter
5.2.4.1. Syntaksen for listefelter skal være som følger:
listefelt::='-' "BEGIN" nøgleord { underfelter } '-' "END"
nøgleord
5.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.2000R2082 — DA — 15.06.2002 — 001.001 — 90
▼B
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 betydnings-
fuld).
Eksempel på en regel addr::= '-' "BEGIN" "ADDR" { fac } '-'
"END" "ADDR"
NOTER
1) Dette eksempel viser, at et »addr«-felt er et listefelt, som inde-
holder 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 kombi-
nation af underfelter, er:
xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".
5.2.5. StruktureredeFelter
5.2.5.1. Syntaksen for strukturerede felter skal være som følger:
struktureret_felt::= '-' nøgleord felt_1 felt_2…felt_n
5.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 udvi-
delser (ved at tilføje nye, indeholdte underfelter).
Eksempel på en regel pt::= '-' "PT" ptid [fl] [eto]
NOTER
1) Dette definerer »pt«- feltet som et struktureret felt, der inde-
holder 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 struk-
tureret 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 mulig-
hederforudvidelse.
5.2.6. Feltet COMMENT
5.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 }
Eksempel COMMENT DETTE ER BEGYNDELSEN PÅ ET
OMRÅDE MED FRI RUTETEKST
5.2.7. Feltet TITLE
5.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 }10
5.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 IFPL2000R2082 — DA — 15.06.2002 — 001.001 — 91
▼B
6. NORMALISERET BESKRIVELSE AF ADEXP-MEDDE-
LELSER
6.1. Introduktion
6.1.1. De følgende afsnit definerer, hvorledes ADEXP-formatet for
forskellige kategorier af meddelelser skal beskrives på en norma-
liseret 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 feltsammen-
sæ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 meddelelses-
gruppe (Se afsnit 6.5.7).
6.1.5. Definerende dokumentation bør på en normaliseret måde tilveje-
bringe 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 Eurocon-
trol-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 felt-
titler er enestående og at undgå unødvendig redundans.
6.2. Hjælpeudtryk
6.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ælpeud-
tryk. 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ække-
følge og er defineret i denne Standards Anneks A (A2).2000R2082 — DA — 15.06.2002 — 001.001 — 92
▼B
6.2.4. Beskrivelsen kan være præsenteret i en tabel som følger, sorteret i alfabetisk række-
følge:
Hjælpeud-
trykSyntaks SemantikAnvendt i
Primært
FeltAnvendt i
UnderfeltAnve-
ndt i
Hjæl-peud-
tryk
adexpmsg { CHARACTER } Fri tekst, som
er i overens-
stemmelse med
den syntaks,
der er
beskrevet for
en ADEXP-
meddelelse.ifpdlong
rfpdlongpreproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadiokommu-
nikation, navi-
gation og
indflyvnings-
hjælpeudstyr.ceqpt
aircraftid 1{ ALPHANUM
}7Identifikation
af Luftfartøj.arcid
arcidk
arcidold
prevarcid
6.3. Definition af Primære Felter
6.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. Beskrivelsen kan være præsenteret i en tabel som følger, sorteret i alfabetisk række-
følge, hvor:
— Den første kolonne repræsenterer den venstre del af en BNF-regel (dvs. den del
som er på den venstre siden af symbolet »::=«) og den tredje kolonne repræsenterer
dens højre del.
— Den anden kolonne (Art) angiver, om feltet er grundlæggende (»b«) eller
sammensat (»c«).
Primært Felt Art Syntaks Semantik
eobt b '-' "EOBT" timehhmm Forventet Off blockTids-
punkt
6.4. Definition af Underfelter
6.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.2000R2082 — DA — 15.06.2002 — 001.001 — 93
▼B
6.4.4. Beskrivelsen kan være præsenteret i en tabel som følger, sorteret i alfabetisk række-
følge:
Underfelt Art Syntaks SemantikAnvendt i
Primært FeltAnven-
dt i
Under-
felt
brng b '-' "BRNG"
refbearingEt punkts pejling
fra en navigati-
onshjælp (i
magnetiske
grader)ref
6.5. Gruppe af Meddelelser
6.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 ander-
ledes 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 medde-
lelsestitler. Der er derfor tilvejebragt henvisning til den
definerende dokumentation for hver meddelelsestitel via medde-
lelsesgruppen.
6.5.7. Et centralt indeks over reserverede meddelelsestitler er også tilve-
jebragt 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 typiskmeddelelser,
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.2000R2082 — DA — 15.06.2002 — 001.001 — 94
▼B
ANNEKSA (Retningsgivende)
ADEXP-FELTDEFINITIONER
A.1.Introduktion
Dette Anneks tilvejebringer en fortegnelse over alle de felter: Hjælpeud-
tryk, Primære Felter og Underfelter, som er blevet defineret til brug i
ADEXP.
A.2.ADEXP-Hjælpeudtryk
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
adexpmsg { CHARACTER } Fri tekst, som er i
overensstemmelse
med den syntaks,
der er beskrevet for
en ADEXP-medde-
lelse.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadiokommunika-
tions-, navigations-
og indflyvnings-
hjælpeudstyr.ceqpt
aircraftid 2{ ALPHANUM }7 Luftfartøjsidentifi-
kation.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Erstatning for
aircraftid til anven-
delse i Forespørg-
selsmeddelelser:
»?« erstatter ét tegn
»+« erstatter et
hvilket som helst
antal tegn.arcidk
atsroute 2 {ALPHANUM} 7 Designatoren for en
ATS-rute.atsrt refatsrte
century 2{DIGIT}2 De to første cifre i
et århundrede.fulldate
coorstatusident 3 {ALPHA} 3 En indikator for en
flyvnings koordine-
ringsstatus.statid
coorstatusre-
ason3 {ALPHA} 7 Årsagen til at
underrette om en
ændring i koordine-
ringsstatusen.statreas-
on
country 2{ALPHA}2 Et lands ICAO-
designator på to
bogstaver.refatsrte
datalink1 {'S' | 'H' | 'V' | 'M'
}4ICAO-designatoren
for datalink-egen-
skaben.
Kan indeholde en
hvilken som helst af
værdierne: S, H, V
eller M i en hvilken
som helst række-
følge, men uden
gentagelse.dat2000R2082 — DA — 15.06.2002 — 001.001 — 95
▼B
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
date year ! month ! day En datoangivelse i
formatet,
YYMMDD.
F.eks. 930424 = 24.
April 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobdvalfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm Et udtryk»date«
som beskrevet
ovenfor og straks
efterfulgt af tiden i
formatet, HHMM.
F.eks.
9304240930=0930Z
, den 24. april 1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6Et »date«-udtryk
(»dato«-udtryk), der
kan bruges som
erstatning.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITEt tal på to cifre,
hvilket kan inde-
holde cifrene fra 00
til 31.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indikator for arten
af nødradioudstyr
om bord på et luft-fartøj. Kan være ét
eller flere af de
definerede tegn i en
hvilken som helst
rækkefølge, men
uden gentagelse.splr
eqptcode 1 {ALPHANUM} 2 Kode, som angiver
et udstyrs egen-
skaber. Kan være
den samme som
udstyrskodeneqpt
eqptstatus 2 {ALPHA} 2 Værdi angivet ved
to bogstaver, som
beskriver status for
luftfartøjets udstyreqpt
equipmentcode 1 {('A' | 'B' | 'C' | 'D'
| 'E' | 'F' | 'G' | 'H' |
'I' | 'J' | 'K' | 'L' | 'M'
| 'O' | 'P' | 'Q' | 'R' |
'T' | 'U' | 'V' | 'W' |
'X' | 'Y' | 'Z' )} 24Et gyldigt ICAO-
kodebogstav til at
angive det medførte
udstyr. Kan være ét
eller flere af de
definerede tegn i en
hvilken som helst
rækkefølge, men
uden gentagelse.aidequip-
ment2000R2082 — DA — 15.06.2002 — 001.001 — 96
▼M1
▼B
▼B
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
errorcode 1{DIGIT}4 Fejlmeddelelsesko-
detal.error
fieldid 1{ ALPHANUM } Gyldigt ADEXP-
feltnavn (dvs.
nøgleord).errfield
ifpsmod
firindicator 4{ ALPHA }4 En ICAO-designator
for en FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4Et flyveniveau
udtrykt enten som;
»F« eller »A« efter-
fulgt af tre cifre,
eller
»S« eller »M«
efterfulgt af fire
cifre.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus "EMER" | "HUM" |
"HOSP" | "SAR" |"HEAD" | "STATE"Årsagen til en
speciel behandlingsom angivet i
elementet »STS/« i
Felt 18.
EMER = Nødsitua-
tion
HUM = Humanitær
flyvning
HOSP = Hospitals-
flyvning
SAR = Flyvered-
ningstjeneste
HEAD = Statsover-
hoved
STATE = Statsflyv-
ning.sts
flightrule 'I' | 'V' | 'Y' | 'Z' En flyvnings flyver-
egelindikator.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Flyvningens type
som angivet ved
hjælp af den
anvendte ICAO-
designator.flttyp
flighttypechg 'OAT' | 'GAT' Den angivelse, der
er tilvejebragt i
flyvningens rute, for
en ændring af
flyvningens type til
»OAT« eller
»GAT« .chgrul ptrulchg
fulldate century ! year !
month ! dayEn datoangivelse i
formatet
CCYYMMDD
19970801 = 1. aug.
1997.fulldate-
time
fulldatetime fulldate ! timehhmm En dato, som
beskrevet i »full-
date«, og straks
efterfulgt af tiden i
formatet
f.ek-
s199708010930 =
kl. 0930, d. 1. aug.
1997mesval-
period
geoname "GEO" !
2{DIGIT}2Den identifikation,
der gives til en
geografiskposition,
udtrykt i breddegrad
og længdegrad.geoid2000R2082 — DA — 15.06.2002 — 001.001 — 97
▼B
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
heading 3{DIGIT}3 Et tal med tre cifre i
intervallet fra 001
til 360.ahead
icaoaerodrome 4{ ALPHA }4 En flyveplads'
ICAO-designator på
fire bogstaver.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Erstatning for
icaoaerodrome til
anvendelse i Fore-
spørgselsmedde-
lelser:
»?« erstatter ét tegn
»+« erstatter et
hvilket som helst
antal tegn.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3En luftfartøjstypes
ICAO-designator.arctyp
icaomsg { CHARACTER } En ICAO-medde-
lelse.
(i overensstemmelse
med syntaksen
beskrevet i Henv.
{4})msgtxt
ifpuid 1{ ALPHANUM } En IFPS-Enheds
identifikator.ifpuresp
latitudelong 6{ DIGIT }6 En breddegrad
udtrykt som seks
cifre.lattd
latitudeside 'N' | 'S' En indikator for
"Nordlig" eller
"Sydlig" bredde.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4ICAO-indikatoren
for typen af
medførte rednings-
veste.
Den kan være ét
eller flere define-
rede tegn i en
hvilken som helst
rækkefølge, men
uden gentagelse.splj
longitudelong 7{ DIGIT }7 En længdegrad
udtrykt som syv
cifre.longtd
longitudeside 'E' | 'W' En indikator for
»Østlig« eller
»Vestlig« længde.longtd
machnumber 'M' ! 3{ DIGIT }3 Machtallet. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Angivelse af den
type af modifika-
tion, der er foretaget
af feltet.ifpsmod
month ('0' | '1' ) ! DIGIT Måned, udtrykt som
et tal med to cifre.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Angivelsen af de
dage i ugen, hvor en
RPL er aktiv.days
daysk
daysold2000R2082 — DA — 15.06.2002 — 001.001 — 98
▼B
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Angivelsen af de
dage i ugen, hvor en
RPL er aktiv. Der
kan også anvendes
Erstatningstegn.daysk
originatorid 1{ ALPHANUM
}10Identifikator for en
meddelelses origi-
nator.orgnid
qrorgn
point 2{ ALPHANUM }5 Designatoren for et
signifikant punkt.
Kan være et offent-
liggjort punkt, et
geografiskpunk t, et
henvisningspunkt
eller et kunstigt
givet punkt, såsom
et »omdøbt« punkt
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Henvisningspej-
lingsværdi.brng
refname "REF" ! 2{DIGIT}2 Identifikatoren givet
til et punkt, udtrykt
ved hjælp af pejling
og afstand fra et
offentliggjort punkt.refid
regulid 1{ ALPHANUM
}20Identifikationen for
en ATFM-bestem-
melse, der vedrører
en flyvning.regul regid
renameid "REN" !
2{DIGIT}2Identifikatoren for
et omdøbt punkt.renid
rrteid 1{ ALPHANUM}
20Identifikatoren for
en omdirigering.rrteref
rtf 6{DIGIT}6 En radiofrekvens
udtrykt i MHz med
tre decimalpladser.freq
rulechg 'VFR' | 'IFR' Indikatorerne
anvendt i en
flyvnings rute til at
angive en ændring i
flyvereglerne.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSekunder.
To cifre fra »00« til
»59«.eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Hastighed.
Udtrykt enten som
»K« eller »N«
efterfulgt af fire
cifre.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 ICAO-designatoren
for det medførte
SSR-udstyr og valg-frit angivelsen af en
datalink-egenskab.seqpt
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Designator for en
»bero«-periode
(»stay« period) for
en »speciel akti-
vitet« inden for en
flyvnings rute.ptstay
stayident2000R2082 — DA — 15.06.2002 — 001.001 — 99
▼B
HjælpeudtrykSyntak s SemantikAnvendt
i Primært
FeltAnvendt
i Under-
feltAnvendt i
Hjælpe-
udtryk
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4ICAO-designatoren
for det medførte
overlevelsesudstyr.
Den kan være ét
eller flere define-
rede tegn i en
hvilken som helst
rækkefølge, men
uden gentagelse.spls
text20 1{ LIM_CHAR }20 Tekst dannet af 1 til
20 tegn, bortset fra
tegnet bindestreg.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITTid, udtrykt i timer
(2 cifre 00-23) og
minutter (2 cifre 00-
59). Kan være tids-
punktet på en dag
eller en varighed.aobt
ata
atd
atot
cobt
ctot
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitimecto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_e-
lapsedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITEt ubegrænset antal
af timer og
minutter, anvendt til
varigheder.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Erstatning for en
timehhmm.eobtk
titleid 1{ ALPHA }10 En gyldig ADEXP-
meddelelsestitel (se
Anneks B).msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' ICAO-designatoren
for wake turbulence.wktrc
year 2{ DIGIT }2 Et års to sidstecifre. date
fulldate
A.3.Primære Felter i ADEXP
Primært
Felt i
ADEXPArt Syntaks Semantik
ad c '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Designator en for en flyveplads. I
tilfælde, hvor flyvepladsen udgør
en del af rutebeskrivelsen, kan der
være tilvejebragt supplerende
ruteinformation.2000R2082 — DA — 15.06.2002 — 001.001 — 100
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
ada b '-' "ADA" date Aktuel ankomstdato.
adarr b '-' "ADARR" (icaoaerodrome |
'ZZZZ')Aktuel ankomstflyveplads.
adarrz b '-' "ADARRZ" text20 Navn på aktuel ankomstflyveplads,
hvis der ikke eksisterer nogen
ICAO-lokalitetsindikator.
add b '-' "ADD" date Aktuel afgangsdato.
addr c '-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Liste over adresser.
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')ICAO-lokalitetsindikator for
afgangsflyvepladsen eller angi-
velsen »AFIL«, som betyder en
flyveplan indleveret fra luften, eller
»ZZZZ«, når der ikke er knyttet
nogen ICAO-lokalitetsindikator til
afgangsflyvepladsen.
adepkb '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Afgangsflyveplads anvendt som en
databasenøgle i en forespørgsel,
kan erstattes.
Kan indeholde en ICAO-lokalitets-
indikator eller angivelsen »AFIL«,
som betyder en flyveplan indleveret
fra luften, eller »ZZZZ«, når der
ikke er knyttet nogen ICAO-lokali-
tetsindikator til afgangsflyve-
pladsen, eller en kombination af
alfabetiske tegn og erstatningstegn.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')Den »foregående« afgangsflyve-
plads. Kan indeholde ICAO-lokali-
tetsindikatoren eller angivelsen
»AFIL«, der betyder en flyveplan
indleveret fra luften, eller »ZZZZ«,
når der ikke er knyttet nogen
ICAO-lokalitetsindikator til
afgangsflyvepladsen.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')ICAO-lokalitetsindikator for
bestemmelsesflyvepladsen eller
»ZZZZ«, når der ikke er knyttet
nogen ICAO-lokalitetsindikator til
bestemmelsesflyvepladsen.
adeskb '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Bestemmelsesflyveplads anvendt
som en databasenøgle i en fore-
spørgsel, kan erstattes.
Kan indeholde en ICAO-lokalitets-
indikator eller »ZZZZ«, når der
ikke er knyttet nogen ICAO-lokali-
tetsindikator til bestemmelsesflyve-
pladsen, eller en kombination af
alfabetiske tegn og erstatningstegn.
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')Den »foregående« bestemmelses-
flyveplads. Kan indeholde ICAO-
lokalitetsindikatoren eller »ZZZZ«,
når der ikke er knyttet nogen
ICAO-lokalitetsindikator til
bestemmelsesflyvepladsen.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Indeholder en ADEXP-meddelelse.2000R2082 — DA — 15.06.2002 — 001.001 — 101
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
afildata c '-' "AFILDATA" ptid fl eto Beregningsdata for en flyveplan
indleveret fra luften.
En punktidentifikation, det tilstø-
dende flyveniveau og punktets
beregnede date-time.
NOTE: De angivne flyveniveau er
det niveau, hvor flyvningen er
blevet klareret til at komme ind i
kontrolleret luftrum over det
angivne punkt. Det behøver ikke at
være det samme som RFLet.
ahead b '-' "AHEAD" (heading | "ZZZ") Kursen tildelt en flyvning, udtrykt i
grader
Skal være et tal med tre cifre eller
værdien »ZZZ«, som angiver, at
der ikke er tildelt nogen kurs.
altnz b '-' "ALTNZ" text20 Navn på alternativ flyveplads, hvis
der ikke eksisterer nogen ICAO-
lokalitet.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')ICAO-lokalitetsidentifikatoren for
den første alternative bestemmel-
sesflyveplads eller indikatoren
»ZZZZ«, når der ikke er blevet
tildelt nogen ICAO-lokalitetsindi-
kator til flyvepladsen.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
‘ZZZZ')ICAO-lokalitetsidentifikatoren for
den anden alternative bestemmel-
sesflyveplads eller indikatoren
»ZZZZ«, når der ikke er blevet
tildelt nogen ICAO-lokalitetsindi-
kator til flyvepladsen.
aobd b '-' "AOBD" date Aktuel Off-Block Dato.
aobt b '-' "AOBT" timehhmm Aktuelt Off-Block Tidspunkt.
arcid b '-' "ARCID" aircraftid Luftfartøjsidentifikation.
Kan være luftfartøjets registre-
ringsmærkning eller ICAO-desig-
natoren for luftfartøjsoperatoren
efterfulgt af flyvningsidentifika-
toren.
arcidkb '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Luftfartøjsidentifikation anvendt
som databasenøgle i en fore-
spørgsel; kan erstattes af erstat-
ningstegn.
Skal være en kombination af alfa-
numeriske tegn og erstatningstegn
op til maksimalt 7 tegn i alt.
arcidold b '-' ARCIDOLD aircraftid Den »foregående« luftfartøjsidenti-
fikation. Hvor luftfartøjsidentifika-
tionen skal rettes, vil den nye værdi
være angivet i »ARCID«.
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Luftfartøjs type (ICAO-identifika-
tion af typen) eller ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")Flyvningens i øjeblikket tildelte
hastighed i kilometer i timen, knob
eller Machtal.
Skal være »M« efterfulgt af tre
cifre, »K« eller »N« efterfulgt af
fire cifre eller »ZZZ«, hvilket
angiver, at der ikke er tildelt nogen
hastighedsrestriktion.
ata b '-' "ATA" timehhmm Aktuelt ankomsttidspunkt.
atd b '-' "ATD" timehhmm Aktuelt afgangstidspunkt.
atot b '-' "ATOT" timehhmm Aktuelt Starttidspunkt.2000R2082 — DA — 15.06.2002 — 001.001 — 102
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
atsrt b '-' "ATSRT" atsroute point point ATS-rutedesignator og identifika-
torer for det første og det sidste
punkt.
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Adresser, hvortil ATFM-medde-
lelser bør adresseres.
ceqpt b '-' "CEQPT" aidequipment Radiokommunikations-, naviga-
tions- og indflyvningshjælpeudstyr
(som ICAO-felt 10).
cfl c '-' "CFL" fl [ptid] Klareret Flyveniveau. Det flyven-
iveau, der for øjeblikket er tildelt af
ATCen til piloten (flyveniveau-
tallet).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointAngivelse af en forandring i enten
»flyvereglerne« (VFR/IFR) eller i
»flyvningens type« (OAT/GAT)
eller begge dele sammen med det
punkt, hvor forandringen fore-
kommer.
cobd b '-' "COBD" date Beregnet Off-blockDato.
cobt b '-' "COBT" timehhmm Beregnet Off-blockTidspunk t.
com b '-' "COM" text20 Kommunikationsudstyr (som
ICAO-felt 18 COM/).
comment b '-' "COMMENT" 1 { LIM_CHAR
}En generel kommentar i fri tekst
uden bindestreg.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Identifikation af en »exceptionel
betingelse« fremkaldt i ATFMs
kontekst.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]En flyvnings overførselsbetingelser.
Et punkts identifikation, flyven-
iveauet og det beregnede tidspunkt
ved punktet og valgfri supplerende
flyveniveauinformation.
cop b '-' "COP" point En identifikator for et koordine-
ringspunkt, enten en kodet desig-
nator for et punkt eller et kunstigt
givet navn (GEOxx, RENxx or
REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Angivelse af en cruise climb.
Angiver det punkt, hvor stigningen
vil begynde, hastigheden eller
machtallet og de to niveauer, som
angiver det flyveniveaubånd, der
skal indtages under stigningen. Det
andet niveau kan være »PLUS«,
hvis det øvre niveau er ukendt.
cstat c '-' "CSTAT" statid [statreason] En indikator, der bekræfter en
flyvnings nye koordineringsstatus,
og valgfrit årsagen til ændringen.
ctod b '-' "CTOD" date Beregnet Start-Dato.
ctot b '-' "CTOT" timehhmm Beregnet Start-Tidspunkt (CTOT):
henvisningstid for en ATFM-slot.
dat b '-' "DAT" datalinkAngivelse af den datalink -egen-
skab, der bæres af luftfartøjet.
days b '-' "DAYS" numdays Dage med operation for en standard
flyveplan (1234567 hvor 1 er for
Mandag, 2 for Tirsdag, …, med 0 i
kolonner uden operation).
dayskb '-' "DAYSK" (numdays |
numdayswldcrd)Dage med operation for en standard
flyveplan, anvendt som database-
nøgle i en forespørgsel, kan
erstattes af et erstatningstegn.2000R2082 — DA — 15.06.2002 — 001.001 — 103
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
daysold b '-' "DAYSOLD" numdays De »foregående« dage med opera-
tion. Anvendt som en database-
nøgle. Hvis der skal rettes i dagene
med operation for en RPL, vil de
nye værdier blive givet i »DAYS«.
dct b '-' "DCT" point point Angiver en direkte rute mellem to
punkter.
Punkterne kan enten være en gyldig
ICAO-designator for et punkt eller
et punkt, der forekommer i et
GEO-, REN- eller REF-felt i
formen GEOxx, RENxx or REFxx.
delay b '-' "DELAY" timehhmm En tidsperiode, der repræsenterer
en forsinkelse. Forsinkelsens
beskaffenhed, dvs. forsinkelse af en
flyvning, behandlingsforsinkelse,
osv., afhænger af konteksten.
depz b '-' "DEPZ" text20 Navn på afgangsflyveplads, hvis
der ikke findes nogen ICAO-loka-
litetsindikator.
desc b '-' "DESC" 1 {LIM_CHAR} Beskrivelse af en betingelse eller
en enhed, som er af relevans for
meddelelsens indhold.
destz b '-' "DESTZ" text20 Navn på bestemmelsesflyveplads,
hvis der ikke findes nogen ICAO-
lokalitetsindikator.
eetfir b '-' "EETFIR" firindicator time-
hhmm_elapsedFIR-identifikation og den akkumu-
lerende, forløbne tid (i timer og
minutter) til FIR-grænsen.
eetlat c '-' "EETLAT" lattd time Angivelse af en forløbet tid til en
position, der kun er angivet ved
hjælp af breddegrad.
eetlong c '-' "EETLONG" longtd time Angivelse af en forløbet tid til en
position, der kun er angivet ved
hjælp af længdegrad.
eetpt b '-' "EETPT" point timehhmm_e-
lapsedPunktidentifikator og den akkumu-
lerede, forløbne tid til punktet.
endtime b '-' "ENDTIME" day ! timehhmm Tidspunktet, hvor en tidsperiode
slutter.
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]De flyveplansdata, som er anven-
delige til en flyvning ved det givne
punkt eller ved flyvningens
indgang til det vedrørte luftrum.
Det ene af felterne eller begge
felter; »ptid«, »airspdes«, skal være
til stede.
eobd b '-' "EOBD" date Forventet Off-blockDato.
eobdkb '-' "EOBDK" date Forventet Off-block Dato anvendt
som databasenøgle i en fore-
spørgsel, kan erstattes af et erstat-
ningstegn.
Skal være en kombination af cifre
og erstatningstegn, op til maksimalt
6 tegn i alt.
eobdold b '-' "EOBDOLD" date Den »foregående« estimerede off
blockdato. Anvendt som en data-
basenøgle. Hvis der skal rettes i
den estimerede off blockdato, vil
den nye værdi være givet i
»EOBD«.
eobt b '-' "EOBT" timehhmm Forventet Off-blockTidspunk t
(EOBT).2000R2082 — DA — 15.06.2002 — 001.001 — 104
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
eobtkb '-' "EOBTK" (timehhmm |
timewldcrd)Forventet Off-blockTidspunk t
anvendt som en databasenøgle i en
forespørgsel, kan erstattes af et
erstatningstegn.
eobtold b '-' "EOBTOLD" timehhmm Det »foregående«, forventede off
blocktidspunk t. Anvendt som en
databasenøgle. Hvis der skal rettes
i den forventede off blockdato, vil
den nye værdi være givet i
»EOBT«.
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Liste med udstyrsspecifikations-
koder, som hver følges af en
statusværdi, der angiver den aktu-
elle status for udstyret
errfield b '-' "ERRFIELD" fieldid ADEXP-navn på fejlbehæftet/fejl-
behæftede felt/felter.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Fejlmeddelelsestekst. Kan valgfrit
indeholde en fejlidentifikations-
kode.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Estimatdata. Et punkts identifika-
tion, det estimerede flyveniveau
(flyveniveautal) og den estimerede
dato-tid ved dette punkt, valgfrit
efterfulgt af det supplerende
flyveniveau (flyveniveautal efter-
fulgt af indikatoren A eller B).
etod b '-' "ETOD" date Forventet Start-Dato.etot b '-' "ETOT timehhmm Forventet Start-Tidspunkt.
extaddr c '-'"EXTADDR" num | { fac } |
(num {fac})Adresser, som er tilvejebragt ud
over de, der bestemmes automatisk,
dvs. »ekstra adresser«. Kan inde-
holde kun antallet af adresser eller
de aktuelle adresser eller begge
dele.
filrte b '-' "FILRTE" {LIM_CHAR} Ruten nøjagtigt, som den er indle-
veret, dvs. uden nogen behandling.
filtim b '-' "FILTIM" day ! timehhmm Dag-tid-gruppe, der specificerer,
hvornår meddelelsen blev indle-
veret til transmission.
flband c '-' "FLBAND" fl fl Et flyveniveaubånd, som definerer
luftrummet vertikalt, inklusive de
givne flyveniveauer.
fltrul b '-' "FLTRUL" flightrule Flyveregel, som ICAO-felt 8.flttyp b '-' "FLTTYP" flighttype Type af flyvning, som ICAO-felt 8.
fmp b '-' "FMP" 4{ ALPHA }4 Identifikator for en »Regulerings-
position« (»Flow Management
Position«).
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Optegnelse over FMPer og deres
tilknyttede ATFM-bestemmelser.
freq b '-' "FREQ" rtf Radiofrekvens.
fstday b '-' "FSTDAY" date Første dag med operation for en
standard flyveplan. Dette anvendes
til at angive den aktuelle første
dag, hvorfra flyveplanerne vil blive
frembragt fra en RPL (se feltet
valfrom) eller den første dag,
hvorpå en rettelse til en RPL er
virksom.2000R2082 — DA — 15.06.2002 — 001.001 — 105
▼M1
▼B
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
furthrte b '-' "FURTHRTE" {LIM_CHAR} En flyvnings yderligere ruteføring.
Til anvendelse inden i meddelelser,
som indeholder estimatdata til at
angive den yderligere ruteføring for
flyvningen efter estimatpunktet.
Den kan indeholde det næste punkt
eller hele den yderligere ruteføring
indtil bestemmelsesstedet.
geo c '-' "GEO" geoid lattd longtd Punkt langs en rute defineret ved
breddegrad og længdegrad og
angivet i en flyveplan, som GEOxx
(hvor xx er et sekvenstal).
ifp b '-' "IFP" 1{ALPHA} Angivelse af kendte fejl inden i en
FPL.
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Optegnelse over fuldstændige
IFPDer, der passer til den databa-
senøgle, der er givet i en fore-
spørgselsmeddelelse.
Indeholder en optegnelse over
fuldstændig information for hver
individuel flyvning, som passer til
givne forespørgselsnøgler.
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Optegnelse over ifpdsum, som
passer til den databasenøgle, der er
givet i en forespørgselsmeddelelse.
Indeholder en optegnelse over
opsummeret information for hver
individuel flyvning, som passer til
givne forespørgselsnøgler.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8En entydig flyveplansidentifikator,
tildelt af IFPSet.
ifpsmod b '-' "IFPSMOD" fieldid modifind En angivelse givet af IFPS over de
felter, som er blevet ændret, og
ændringens beskaffenhed.
ifpuresp b '-' "IFPURESP" ifpuid Identifikator for den IFPU, som er
ansvarlig for en forespørgsel. Den
skal behandle en forespørgsel og
besvare den.
ignore c '-' “BEGIN” "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
“END” “IGNORE”Angivelse af betingelser, som er
blevet »ignoreret« eller som der
ikke er taget hensyn til i behand-
lingen af den pågældende medde-
lelse. En »ignoreret« betingelse kan
være begrænset til en specifikdel
af ruten, afgrænset af de givne
rutepunkter. En betingelse kan for
eksempel være en tidsrestriktions-
(rutetilgangsbetingelse), flyven-
iveaurestriktions- eller TOS-over-
trædelse.
iobd b '-' "IOBD" date Den »Indledende« Off BlockDato
— »off-blockdatoen« som angivet
i FPLen og opdateret ved hjælp af
flyveplanstilknyttede meddelelser
(DLA, CHG, osv.). Dette er den
henvisningsdato, der anvendes til at
få tilgang til flyveplanen i data-
basen, og er den eneste »off-block
dato«, som kendes af de pågæl-
dende ATS-enheder.
Note: IOBD påvirkes ikke af
anmodede eller underrettede
ændringer via udvekslingen af
ATFM-meddelelser.2000R2082 — DA — 15.06.2002 — 001.001 — 106
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
iobt b '-' "IOBT" timehhmm Det »Indledende« Off BlockTids-
punkt — »off block tidspunktet«
som givet i FPLen og opdateret ved
hjælp af flyveplanstilknyttede
meddelelser (DLA, CHG, osv.).
Dette er den henvisningstid, som
anvendes til at få tilgang til flyve-
planen i databasen, og er det eneste
»off-block tidspunkt«, som kendes
af de pågældende ATS-enheder.
Note: IOBT påvirkes ikke af
anmodede eller underrettede
ændringer via udvekslingen af
ATFM-meddelelser.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Optegnelse over Aktive Betingede
Ruter.
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Optegnelse over Aktive Midlerti-
digt Afsondrede Områder.
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Optegnelse over Lukkede ATS-
Ruter.
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Optegnelse over FIRer, omfattende
navnet på regionen efterfulgt af
enten listen over Tilgængelige
Betingede Ruter eller listerne over
Tilgængelige Betingede Ruter,
Lukkede ATS-Ruter, Aktive,
Midlertidigt Afsondrede Områder,
Formindskede Luftrumsrestrikti-
oner og Formindskede Koordine-
ringsluftrum.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Optegnelse over Formindskede
Luftrumsrestriktioner.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Optegnelse over Formindskede
Koordineringsområder.
lstday b '-' "LSTDAY" date Sidste dag med operation for en
standard flyveplan. Dette anvendes
til at angive den aktuelle sidste
dag, hvorfra flyveplanerne vil blive
frembragt fra en RPL (se feltet
valuntil) eller den sidste dag, hvor
en rettelse til en RPL er virksom.
=> Skal være en dato mellem
VALFROM og VALUNTIL.
mach b '-' "MACH" machnumber [ point ] Machtal i hundrededele af en enhed
og valgfrit det punkt, hvor der
anmodes om ændringen.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimeGyldighedsperioden for en medde-
lelse, inklusive de angivne tids-
punkter.
minlineup b '-' "MINLINEUP" timehhmm Den minimale tid, der kræves for
en flyvning, som har angivet sig
selv som værende parat til afgang,
til at komme fra sin nuværende
holding position til at være
luftbåren.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Antal modifikationer, der var
nødvendige til at korrigere en
original meddelelse.
msgref c '-' "MSGREF" sender recvr
seqnumHenvisningsdata for tilknyttede,
tidligere transmitterede medde-
lelser.2000R2082 — DA — 15.06.2002 — 001.001 — 107
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Indeholder en sammenfatning af en
meddelelse.
Note: Skal indeholde ét eller flere*
af felterne arcid, adep, ades, eobt
og orgn, men uden gentagelse.
* ét eller flere af felterne kan have
manglet eller kan være forvansket i
modtaget meddelelse.
msgtxt b '-' "MSGTXT" icaomsg Indeholder en fuldstændig ICAO-
meddelelse.
msgtyp b '-' "MSGTYP" titleid Indeholder titlen på den henviste
eller kopierede meddelelse.
Kan være en hvilken som helst
gyldig ADEXP-meddelelsestitel (se
Anneks B).
nav b '-' "NAV" text20 Signifikant navigationsustyr, som
ICAO-felt 18 NAV/.
nbarc b '-' "NBARC" 1{ DIGIT }2 Luftfartøjets nummer, hvis der er
mere end ét.
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Antal af flyveplansdata, der passer
til en forespørgsel.
Skal være mellem 0 og 999.
newctot b '-' "NEWCTOT" timehhmm Et nyt Beregnet Start-Tidspunkt,
som opdateret ved TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmEt nyt tidspunkt, hvor en tidspe-
riode slutter.
neweobd b '-' "NEWEOBD" date En ny Forventet Off-blockDato.neweobt b '-' "NEWEOBT" timehhmm Et nyt Forventet Off-blockTids-
punkt.
newptot b '-' "NEWPTOT" timehhmm Et nyt Foreløbigt Start-Tidspunkt.
newrte b '-' "NEWRTE" { LIM_CHAR } En ny rute mellem de samme
afgangs- og ankomstflyvepladser
som i den originale meddelelse.
newstart-
timeb '-' “NEWSTARTTIME” day !
timehhmmEt nyt tidspunkt, hvor en tidspe-
riode starter.
oldmsg b '-' "OLDMSG" { CHARACTER } En fuldstændig, original medde-
lelse, nøjagtigt (og i det samme
format) som den blev modtaget.
opr b '-' "OPR" 1 { LIM_CHAR } Navn på firma eller bureau, der
leder flyvningen, som elementet
OPR/ i ICAO-felt 18.
orgmsg b '-' "ORGMSG" titleid ADEXP-Titlen på en fejlbehæftet
meddelelse, som den blev modtaget
af TACT.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Adressen på en meddelelses origi-
nator.
orgnid b '-' "ORGNID" originatorid Designator af en adressat, der har
givet anledning til en meddelelse.
orgrte b '-' "ORGRTE" { LIM_CHAR } Original rute mellem afgangs- og
ankomstflyvepladserne.
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Information angående en medde-
lelses originator. Kan indeholdeden anvendte type af netværkeller
de vedrørte adresser eller begge
dele.
origindt b '-' "ORIGINDT" datetime Dato og tidspunkt for IFPSets
modtagelse af original meddelelse.
Note: Dette er ikke meddelelsens
indleveringstidspunkt.
Formatet er YYMMDDHHMM.2000R2082 — DA — 15.06.2002 — 001.001 — 108
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
part c '-' "PART" num lastnum Identifikation af den del af medde-
lelsen, der identificeres ved titlen,
indleveringstiden og gyldighedspe-
rioden.
per b '-' "PER" text20 Luftfartøjs ydeevnedata, som
ICAO-felt 18 PER/.
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Positionen af et luftfartøj, angivet
enten som et punkt eller en flyve-
plads med valgfri tids- og flyven-
iveauinformation.
prevarcid b '-' "PREVARCID" aircraftid Det tidligere anvendte kaldesignal.
prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4SSR-Tilstand og -Kode anvendt af
flyvningen umiddelbart forud for
SSR-Tilstanden og -Koden givet i
feltet »-SSRCODE«.
propfl c '-' "PROPFL" tfl [sfl] Et flyveniveau foreslået af en
accepterende enhed for overførslen
af en flyvning.
ptot b '-' "PTOT" timehhmm Foreløbigt Start-Tidspunkt. Fore-
løbig henvisningstid for en ATFM-
slot.
qrorgn b '-' "QRORGN" originatorid Identifikator for Forespørgslens
originator.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Navn(e) på alternativ(e) flyve-
plads(er) på ruten.
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Ændringshastighed: stige- eller
nedstigehastigheden tildelt et luft-
fartøj, udtrykt i hundreder af fod
per minut.
=> Skal være »C« for at angive en
stigehastighed eller »D« for at
angive en nedstigehastighed, efter-
fulgt af et tal med to cifre for at
angive den tildelte hastighed i
hundreder af fod per minut. Alter-
nativt kan designatoren »ZZZ«
anvendes for at angive, at der ikke
er tildelt nogen stige- eller nedsti-
gehastighed.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Optegnelse over tidsperioder og
deres respektive afviklingshastig-
heder for en ATFM-betingelse.
reason b '-' "REASON" 4{ALPHA}12 Årsag til enten afvisning af en
meddelelse eller annullering af en
slot ved TACT.
Information til at støtte medde-
lelsen afhængigt af dens kontekst.
ref c '-' "REF" refid ptid brng distnc Punkt langs en rute, hvilket er
defineret ved magnetiskpejling og
afstand fra et andet punkt og som
er tildelt designatoren REFxx.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumHenvisningsdata for en meddelelse,
der transmitteres.
reg b '-' "REG" 1{ LIM_CHAR }7 Registreringsmarkeringer, som
ICAO-felt 18 REG/.
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Henvisningslokalitet for en ATFM-
Bestemmelse.
regul b '-' "REGUL" regulid Identifikator for en Bestemmelse
vedrørende en flyvning.
rejctot b '-' "REJCTOT" timehhmm Afvist Beregnet Start-Tidspunkt:
negativ reaktion i forhold til et
Slot-forbedringsforslag.2000R2082 — DA — 15.06.2002 — 001.001 — 109
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
release b '-' "RELEASE" 1{ALPHA}1 En angivelse af, at flyvningen er
frigivet af den overførende flyve-
leder til den modtagende flyve-
leder.
C = frigivet til stigning
D = frigivet til nedstigning
T = frigivet til drej
F = frigivet til alle handlinger.
rename c '-' "RENAME" renid ptid Angivelse af et midlertidigt, nyt
navn givet til et »signifikant
punkt«, hvilket forekommer mere
end én gang i rutebeskrivelsen for
at undgå forvirring. Dette midlerti-
dige navn anvendes kun for at opnå
klarhed i rutens repræsentation og
indebærer ikke en aktuel ændring
af punktets virkelige identifikation.
respby b '-' "RESPBY" timehhmm Reager Ved: tidspunkt, hvor en
reaktion på et Slot-forbedringsfor-
slag skal foretages.
rfl b '-' "RFL" flightlevel [point] Anmodet flyveniveau (i flyven-
iveautal, udtrykt i antal ti meter
eller hundreder fod) og valgfrit et
punkt, hvor en ændring af RFL er
påkrævet.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Indikator for Erstatningsflyveplan
(RFP).
Skal være »Q« efterfulgt af et
ciffer (1-9).
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Optegnelse over fuldstændige
RFPDer, som passer til de databa-
senøgler, der er givet i en Fore-
spørgsel.
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Optegnelse over rfpdsum (RFPD-
sammenfattet information), som
passer til de databasenøgler, der er
givet i en Forespørgsel.
rif b '-' "RIF 4{LIM_CHAR} Revideret rute gjort til genstand for
klarering i flyvning og afsluttet
med ICAO-designatoren for den
reviderede bestemmelsesflyveplads.
rmkb '-' "RMK" 1{ LIM_CHAR } Bemærk ninger i almindeligt sprog,
som ICAO-felt 18 RMK/.
route b '-' "ROUTE" {LIM_CHAR} Fuldstændig information i ICAO-
Felt 15 indeholdende hastighed,
RFL og rute (i overensstemmelse
med den syntaks, der er givet i
Henv. 4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockBeskrivelse af en trafikafvikling,
som skal gendirigeres.
rrteref b '-' "RRTEREF" rrteid Gendirigeringshenvisning.
rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockBeskrivelsen af en trafikafvikling,
hvortil trafiksk al gendirigeres.
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Optegnelse over rutepunkter. Kan
også indeholde en flyvepladsidenti-
fikator.
rvr b '-' "RVR" 1{ DIGIT }3 Banesynsvidde (RVR).
Operationsminima, når specielle
meteorologiske betingelser eksi-
sterer. Udtrykt i meter.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Optegnelse over tidsperioder og
deres anvendelige RVR-grænser.2000R2082 — DA — 15.06.2002 — 001.001 — 110
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitDen tidsperiode, som RVR-
grænsen er anvendelig indenfor.
sector b '-' "SECTOR" 1{ ALPHANUM }8 Identifikation af en ATC-sektor.sel b '-' "SEL" 4{ ALPHA }5 SELCAL-kode som elementet
»SEL/« i ICAO-Felt 18.
sendto c '-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"Optegnelse over luftnavigationsen-
heder, som en meddelelse skal
sendes til.
seqpt b '-' "SEQPT" ssrequipment Overvågningsudstyr, som ICAO-
Felt 10.
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Identifikator for en Standard
Instrumentafgangsprocedure.
speed b '-' "SPEED" spd [ point ] Egenfart (i kilometer i timen eller
knob) og valgfrit det punkt, hvor
der anmodes om en ændring af
egenfart.
spla b '-' "SPLA" 1{ LIM_CHAR }50 Farve på et luftfartøjs markeringer,
som element »A/ i ICAO-Felt 19«.
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Kontaktdata, hvor Supplerende
information til flyveplanen kan
opnås.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Navn på luftfartøjschefen, som
element »C/« i ICAO-Felt 19.
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Total kapacitet af gummibåde, som
element »D/« i ICAO-Felt 19.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Farve på gummibåde, som element
»D/ i ICAO-Felt 19«.
spldcov b '-' "SPLDCOV" ('T' | 'F') Gummibåde: angivelse af, hvis de
er tildækkede, som element »D/ i
ICAO-Felt 19«.
T = Sand (=> »C« i ICAO)
F = Falsk, ikke dækket.
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Gummibåde: antal, som element
»D/« i ICAO-Felt 19.
sple b '-' "SPLE" timehhmm_elapsed Brændstofvarighed, som element
»E/« i ICAO-Felt 19.
splj b '-' "SPLJ" lifejackets Redningsveste, som element »J/« i
ICAO-Felt 19.
spln b '-' "SPLN" 1{ LIM_CHAR } Hvilket som helst andet overlevel-
sesudstyr og velegnede bemærk-
ninger, som element »N/« i ICAO-
Felt 19.
splp b '-' "SPLP" 1{DIGIT}3 Personer om bord, som element »P/
« i ICAO-Felt 19.
splr b '-' "SPLR" emergradio Nødradioudstyr, som element »R/«
i ICAO-Felt 19.
spls b '-' "SPLS" survivaleqpt Overlevelsesudstyr, som element
»S/« ICAO-Felt 19.
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Angivelse af datakilden. Indholdet
afhænger af TITLE-feltet.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Enten;
- SSR-tilstand og -kode, som
elementerne b og c i ICAO-felt 7;
eller
- bogstaverne »REQ«, som betyder,
at der anmodes om koden.
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Identifikationen af en Standard
Ankomstsprocedure.2000R2082 — DA — 15.06.2002 — 001.001 — 111
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
starttime b '-' "STARTTIME" day !
timehhmmTidspunkt, hvor en tidsperiode
begynder.
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Angivelse i flyvningens rute af en
periode med »speciel aktivitet«, når
luftfartøjet vil »forblive« (»stay«) i
det område, der er defineret ved
punkterne og/eller de flyvepladser,
der er givet for det angivne
tidsrum, dvs. træning, brændstof-
påfyldning i luften, fotografisk
mission osv.
NOTE: Den rækkefølge, hvori
punkterne og/eller flyvepladserne
er angivet, er betydningsfuld.
stayinfo c '-' "STAYINFO" stayident remarkInformation vedrørende typen af
aktivitet (træning, fotografisk
mission, osv.), der skal udføres
under en ‘stay' periode i flyvnin-
gens rute.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Årsag til speciel håndtering, som
ICAO-Feltet 18 STS/. Kan være
enten »BESKYTTET«
(»PROTECTED«) for at angive
følsom behandling eller én af de
genkendte etiketter EMER, HOSP,
osv., eller fri tekst.
taxitime b '-' "TAXITIME" timehhmm Tidsforskellen mellem »off block
tidspunktet« og »starttidspunktet«.
De tider, der henvises til, kan være
aktuelle eller estimerede afhængigt
af konteksten.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Identifikation af en »trafik-
mængde«.
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockBeskrivelse af et trafikmængde.
title b '-' "TITLE" titleid Meddelelsestitel.
ttleet b '-' "TTLEET" timehhmm_elapsed Total beregnet, forløbet tid i timer
og minutter.
typz b '-' "TYPZ" text20 Luftfartøjs type, når der ikke eksi-
sterer nogen ICAO-kode.
unit c '-' "UNIT" unitid [addrinfo] Information vedrørende en »luftna-
vigationsenhed«, dvs. en ATC-
enhed, en luftfartøjsoperator eller
en flyveplansoriginator. Indeholder
enhedens identifikation og valgfrit
adressedata.
valfrom b '-' "VALFROM" date Første dato, hvorfra flyvningen er
planlagt at operere (i år, måned og
dag).
valfromkb '-' "VALFROMK" ( date |
datewldcrd )Første dato, hvorfra flyvningen er
planlagt at operere, anvendt som
databasenøgle i en Forespørgsel,
kan erstattes af et erstatningstegn.
Skal være en gyldig dato eller en
kombination af en gyldig dato og
erstatningstegn.
valfromold b '-' "VALFROMOLD" date Den »foregående«»valfrom« dato.
Anvendt som en databasenøgle.
Hvis der skal rettes i starten på
gyldighedsdato, vil den nye værdi
være givet i »VALFROM«.
validitydate b '-' "VALIDITYDATE" date Gyldighedsdato.
valuntil b '-' "VALUNTIL" date Sidste dato, hvorfra flyvningen er
planlagt at operere (i år, måned og
dag).2000R2082 — DA — 15.06.2002 — 001.001 — 112
▼B
Primært
Felt i
ADEXPArt Syntaks Semantik
valuntilkb '-' "VALUNTILK" ( date |
datewldcrd )Sidste dato, hvorfra flyvningen er
planlagt at operere, anvendt som
databasenøgle i en Forespørgsel,
kan erstattes af et erstatningstegn.
Skal være en gyldig dato eller en
kombination af en gyldig dato og
erstatningstegn.
valuntilold b '-' "VALUNTILOLD" date Den »foregående«»valuntil« dato.
Anvendt som en databasenøgle.
Hvis der skal rettes på slutningen
af gyldighedsdata, vil den nye
værdi være givet i »VALUNTIL«.
wktrc b '-' "WKTRC" waketurbcat Wake turbulence kategori.
A.4.ADEXP Underfelter
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
addrinfo c '-' "ADDRINFO"
networktype facAdresseinformation unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'Designator for en
flyveplads. Kan inde-
holde ICAO-lokali-
tetsindikatoren eller
tegnene »ZZZZ«,
hvis der ikke er
blevet tildelt nogen
lokalitetsindikator.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblockvalperiod
[remark]Beskrivelse af en hel
eller en del af en
ATS-rute i løbet af
en specificeret
periode.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblockvalperiod
respunit [remark]Beskrivelse af et helt
eller en del af et
luftrum i løbet af en
specificeret periode.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Designerer et luftrum
forskelligt fra en
ATS-rute.entrydata airspace
brng b '-' "BRNG" refbea-
ringEt punkts pejling fra
en navigationshjælp i
magnetiske grader.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Type af betingelse
eller restriktion, f.eks.
TOS, FL-restriktion.ignore
crfl1 b '-' "CRFL1" flight-
levelDen nedre grænse for
et flyveniveaubånd,
inden for hvilket der
er anmodet om en
cruise climb.crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")Den øvre grænse for
et flyveniveaubånd,
inden for hvilket der
er anmodet om en
cruise climb.
»PLUS«, hvis den
øvre grænse er
ukendt.crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberDet Machtal, der
bibeholdes under en
cruise climb.crsclimb ptcrsclimb2000R2082 — DA — 15.06.2002 — 001.001 — 113
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
crspeed b '-' "CRSPEED" spd Den hastighed, der
skal bibeholdes under
en cruise climb.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Beregnet Tidspunkt
Over et punkt.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Afstand af et punkt
fra en navigations-
hjælp i sømil.
Skal være 1 til 3
cifre, muligvis med
nuller foran.ref
efl b '-' "EFL" flightlevel Estimeret flyven-
iveau.Reserveret
til frem-
tidig brug.
endreg b '-' "ENDREG" day!ti-
mehhmmDet tidspunkt, hvor
en ATFM-Bestem-
melse slutter.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusUdstyrsspecifikati-
onskode, som følges
af en værdi, der
angiver den aktuelle
status for udstyreteqcst
eto b '-' "ETO" date !
timehhmm ! secondsBeregnet Tidspunkt
Over et punkt i år,
måned, dag, timer,
minutter og sekunder.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]En »exceptionel
betingelse« frembragt
i ATFM's kontekst,
f.eks. tåge ved en
flyveplads.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Adressedata. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Designerer en FIR
eller UIR.lfir
fl b '-' " FL" flightlevel Et fælles flyven-
iveaufelt.
Kan være et »SFL«,
»EFL«, »CFL«,
»RFL«, osv., afhæn-
gigt af konteksten.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt
flblockc '-' "FLBLOCK" fl fl En flyveniveaublok ,
der definerer et
luftrum vertikalt,
inklusive de givne
flyveniveauer. En
blokdefineret som
neden under eller
oven over et flyven-
iveau skal udtrykkes
respektivt som fra
flyveniveau 000 til
det specificerede
niveau eller fra det
specificerede niveau
til flyveniveau 999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond2000R2082 — DA — 15.06.2002 — 001.001 — 114
▼M1
▼B
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleBeskrivelse af en
»afvikling« (»flow«),
som giver
kildeområdet, valgfrit
de ruter eller punkter,
hvor der vil være
overflow fra
kildeområdet,
bestemmelsesområdet
og valgfrit de ruter
eller punkter, hvor
der vil være overflow
til bestemmelses-
området.flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Optegnelse over
trafikafviklinger.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7Den »hastighed« som
er pålagt ved en
ATFM-Bestemmelse.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'En angivelse af en
afviklings »rolle«.
EX = udeladt
IE = indbefattet
dispenseret
EM = dispenseret
IN = indbefattetflow
from b '-' "FROM" day!ti-
mehhmmDet tidspunkt,
hvorfra en tidsperiode
begynder.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15En position, hvorfra
en rute, en rutedel, en
»sti« eller en afvik-
ling begynder.
Kan være et område,
en flyveplads eller et
signifikant punkt.flow
geoid b '-' "GEOID" geoname Identifikator for et
geografiskpunk t
udgjort af »GEO«
efterfulgt af et
sekvenstal
(eksempel:
»GEO12«).geo
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Fuldstændig informa-
tion angående en
individuel flyveplan.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnSammenfattet infor-
mation angående en
individuel flyveplan.
Den indeholder
felterne arcid, adep,
ades, eobt og orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Et tal på tre cifre,
som angiver slut-
ningen på en sekvens.
lattd b '-' "LATTD" latitude-
long ! latitudesideBreddegrad i grader,
minutter, sekunder og
retning (nord eller
syd).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLængdegrad i grader,
minutter, sekunder og
retning (øst eller
vest).eetlong
geo2000R2082 — DA — 15.06.2002 — 001.001 — 115
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Angivelse af typen af
netværk, som
anvendes til en
meddelelsesudveks-
ling.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Et tal på tre cifre. extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7Raten af »verse-
rende« sager
(»pending rate«),
anvendt til ATFM-
formål.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgIndeholder en fuld-
stændig ADEXP-
meddelelse efter den
er blevet behandlet.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgIndeholder en fuld-
stændig ADEXP-
meddelelse forud for,
at den bliver
behandlet, dvs. som
den blev modtaget.adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Punkt langs en rute.
=> Indeholder en
punktidentifikation
og valgfrit;
- et flyveniveau eller
en flyveniveaublok,
- et supplerende
flyveniveau,
- en tidshenvis-
ning(er),
- en cruise climb
- en ruteidentifikation
- en angivelse af en
periode med »speciel
aktivitet«, dvs. at
flyvningen vil
»forblive« i området i
en tidsperiode
Ændring i:
- RFL, flyveregler,
hastighed/Machtal.rtepts
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Angivelse af en
cruise climb i en
flyvnings rute.
Angiver hastigheden
eller Machtallet efter-
fulgt af de to
niveauer, som
angiver det flyven-
iveaubånd, der skal
indtages under stig-
ningen. Det andet
niveau kan være
»PLUS«, hvis det
øvre niveau er
ukendt.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'En angivelse af de
flyveregler, som er
anvendelige ved det
pågældende punkt.entrydata2000R2082 — DA — 15.06.2002 — 001.001 — 116
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
ptid b '-' "PTID" point Punkts identifikation,
enten kodet desig-
nator eller et kunstigt
givet navn (GEOxx,
REFxx or RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberMachtal i hundrede-
dele af en enhed,
knyttet til et punkt på
ruten.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'En angivelse af de
»militære« flyver-
egler, som er anven-
delige ved det
pågældende punkt.entrydata
ptrfl b '-' "PTRFL" flight-
levelAnmodet flyven-
iveau, knyttet til et
punkt på ruten.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}Flyvningens rute efter
det angivne punkt.
Kan være den fuld-
stændige rute til
bestemmelsesflyve-
pladsen eller blot
ruteelementet til det
næste punkt.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgAngivelse af en
ændring i enten
»flyvereglerne«
(VFR/IFR) eller
»typen af flyvning«
(OAT/GAT) eller
begge dele og knyttet
til et punkt på ruten.ad pt
ptspeed b '-' "PTSPEED" spd Egenfart (i kilometer
i timen eller knob)
knyttet til et punkt på
ruten.ad
entrydatapt
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmIndikation, inden i
den indleverede rute
for en flyvning, af en
periode med »speciel
aktivitet«, når luftfar-
tøjet vil »forblive« i
det definerede
område i det angivnetidsrum, dvs. træning,
brændstofpåfyldning i
luften, osv.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penrateEn tidsperiode, hvor-
under de givne afvik-
lingshastigheder er
anvendelige for en
ATFM-Bestemmelse.ratepdlst regcond
recvr b '-' "RECVR" fac Modtageren af den
henviste meddelelse.msgref
refdata2000R2082 — DA — 15.06.2002 — 001.001 — 117
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]ATS-rutedesignator
og identifikatorer for
det første og det
sidste punkt. De opli-
stede punkter kan
være ICAO-identifi-
katorer eller kunstigt
givne punkter
GEOxx, RENxx or
REFxx . Identifika-
toren for det land,
inden for hvilket
punkterne er lokali-
seret, kan valgfrit
indbefattes.
Endepunkterne skal
være konsistente med
ruteinformationen.airroute
refid b '-' "REFID" refname Identifikator for et
henvisningspunkt
udgjort af »REF«
efterfulgt af et
sekvenstal (eksempel:
»REF02«).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Henvisningslokalitet
for en ATFM-
Bestemmelse.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Optegnelse over tids-
perioder og deres
respektive afviklings-
hastigheder for en
særlig bestemmelse.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Beskrivelse af en
ATFM-Bestemmelse.regulation
regid b '-' "REGID" regulid Identifikation af en
»Bestemmelse« for
regulering af afvik-
ling.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Optegnelse over
»Bestemmelser« med
henblikpå regulering
af afvikling.fmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Et henvisningstal for
en ATFM-»Bestem-
melse«. Tilveje-
bringer en entydig
henvisning efterfulgt
af en gyldighedsiden-
tikation.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12Årsagen til en
ATFM-Bestemmelse.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]En »Bestemmelse«
pålagt med henblik
på regulering af
afvikling.reglist
remarkb '-' "REMARK"
1{LIM_CHAR}En bemærkning om
det emne, hvis
beskrivelse dette felt
er en del af.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identifikator givet til
et punkt, hvilken
gentages i rutebeskri-
velsen.rename2000R2082 — DA — 15.06.2002 — 001.001 — 118
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
respunit b '-' "RESPUNIT"
12{ALPHA}12Den ansvarlige ATC-
Enhed.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Fuldstændig informa-
tion angående en
standard flyveplan.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilSammenfatning af
informationen
angående en standard
flyveplan. Den inde-
holder felterne arcid,
adep, ades, eobt,
orgn, days, valfrom
og valuntil.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Banesynsvidde:
operationsminima,
når specielle meteo-
rologiske betingelser
eksisterer. Udtrykt i
meter.rvrperiod exccond
sender b '-' "SENDER" fac Afsenderen af den
henviste meddelelse.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Serienummeret på
den meddelelse, som
sendes (et tal på 3
cifre, som er entydigt
i forhold til sender/
modtager-kombinati-
onen).msgref
refdata
sfl b '-' SFL flightlevel !
('A'|'B')Supplerende flyven-
iveau. Det flyven-
iveau ved eller over
hvilket eller ved eller
under hvilket en
flyvning er blevet
eller vil blive koordi-
neret til at kryds ét
punkt. Består af et
flyveniveautal og en
krydsningsbetingelse
(enten »A«, hvis luft-
fartøjet vil krydse
punktet ved eller over
niveauet, eller »B«,
hvis luftfartøjet vil
krydse punktet ved
eller under niveauet).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day! timehhmmDet tidspunkt, hvor
en ATFM-Bestem-
melse bliver virksom.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentIndikatoren for en
flyvnings koordine-
ringstilstand.cstat
statreason b '-' "STATREASON"
coorstatusreasonÅrsagen til en foran-
dring i en flyvnings
koordineringsstatus.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentifikation af en
periode med »speciel
aktivitet« eller et
»stay« inden i en
flyvnings rute.stay
stayinfo2000R2082 — DA — 15.06.2002 — 001.001 — 119
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
sto b '-' "STO" timehhmm
! secondsEt fælles tidsfelt, som
kan indeholde et
punkts eller en flyve-
plads' tid. Tiden kan
være et forventet,
beregnet eller et
aktuelt tidspunkt
afhængigt af kontek-
sten.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Overførselsflyveni-
veau. Det flyven-
iveau, hvor en
flyvning er blevet
eller vil blive koordi-
neret til at krydse ét
punkt (flyven-
iveautal), i tilfælde af
flyvning i niveau,
eller det klarerede
niveau, hvortil den
fortsætter, hvis den
stiger eller nedstiger
ved grænsepunktet.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identifikation af en
»trafikmænge«.rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm En tidsidentifikation.
Kan være et aktuelt
tidspunkt eller et
tidsrum, afhængigt af
meddelelsens
kontekst.stay
to b '-' "TO" timehhmm »Tidspunkt Over/
Off«. Et fælles tids-
felt, som kan inde-
holde et punkts elleren »flyveplads« tid.
Tidsen kan være et
forventet, beregnet
eller aktuelt tidspunkt
afhængigt af kontek-
sten.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15En position hvortil en
rute, en rutedel, en
»bane« (»path«) eller
en afvikling forløber.
Kan være et område,
en flyveplads eller et
signifikant punkt.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Identifikation af en
luftnavigationsenhed,
dvs. en ATC-enhed,
luftfartøjsoperator
eller flyveplansorigi-
nator.unit
until b '-' "UNTIL" day!ti-
mehhmmDet tidspunkt, hvor
en tidsperiode slutter.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeEn gyldighedspe-
riode, inklusive de
angivne tidspunkter.airroute
airspace2000R2082 — DA — 15.06.2002 — 001.001 — 120
▼B
Underfelt Art Syntaks SemantikAnvendt i
Primært
Felt unitAnvendt i
Underfelt
via1 b '-' "VIA1" 1
{ALPHANUM} 15Et punkt, en ATS-
rute eller et luftrum,
som enten er på eller
er påkrævet at være
på en flyvnings rute.
Når det er påkrævet
at angive mere end
ét, vil dette felt inde-
holde det første i
sekvensen.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Et punkt, en ATS-
rute eller et luftrum,
som enten er på eller
er påkrævet at være
på en flyvnings rute.
Når det er påkrævet
at angive mere end
ét, vil dette felt inde-
holde det andet i
sekvensen.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Et punkt, en ATS-
rute eller et luftrum,
som enten er på eller
er påkrævet at være
på en flyvnings rute.
Når det er påkrævet
at angive mere end
ét, vil dette felt inde-
holde det tredje i
sekvensen.flow
via4 b '-' "VIA4" 1
{ALPHANUM} 15Et punkt, en ATS-
rute eller et luftrum,
som enten er på eller
er påkrævet at være
på en flyvnings rute.
Når det er påkrævet
at angive mere end
ét, vil dette felt inde-
holde det fjerde i
sekvensen.flow2000R2082 — DA — 15.06.2002 — 001.001 — 121
▼B
ANNEKSB (Retningsgivende)
CENTRALT INDEKS OVER ADEXP MEDDELELSESTITLER
Titel DefinitionIndtroduceret i
Afsnit
ABI Forudgående Grænseinformationsmeddelelse (Advance
Boundary Information Message)E.3
ACK Kvitteringsmeddelelse (Acknowledge Message) E.1
ACP Acceptmeddelelse (Acceptance Message) E.5
ACT Aktiveringsmeddelelse (Activation Message) E.3
AUP Meddelelse om Plan for Brug af Luftrum (Airspace Use
Plan Message)E.4
BFD Grundlæggende Flyvedatameddelelse (Basic Flight Data
Message)E.5
CDN Koordineringsmeddelelse (Co-ordination Message) E.3
CFD Meddelelse om Ændring af Flyvedata (Change to Flight
Data Message)E.5
CNLCOND Meddelelse om Annullering af Exceptionel Betingelse for
ATFM (ATFM Exceptional Condition Cancellation
Message)E.2.3
CNLREG Meddelelse om Annullering af ATFM-Bestemmelse (ATFM
Regulation Cancellation Message)E.2.3
COD SSR-Kodetildelingsmeddelelse (SSR Code Assignment
Message)E.3
COF Frekvensændringsmeddelelse (Change of Frequency
Message)E.3
CRAM Betinget Rutetilgængelighedsmeddelelse (Conditional Route
Availability Message)E.4
DES De-Suspensionsmeddelelse (De-Suspension Message) E.2.2
ERR Fejlmeddelelse (Error Message) E.2.2
EXCOND Underretningsmeddelelse om Exceptionel Betingelse for
ATFM (ATFM Exceptional Condition Notification
Message)E.2.3
FCM Flyvebekræftelsesmeddelelse (Flight Confirmation Message) E.2.2
FLS Flyvesuspensionsmeddelelse (Flight Suspension Message) E.2.2
FSA Første Systemaktiveringsmeddelelse (First System Activa-
tion Message)E.2.3
HOP Meddelelse om Forslag om Overdragelse (Hand-Over
Proposal Message)E.3
IACH Individuel ATC-Modifikationsmeddelelse (Individual ATC
Modification Message)E.1
IAFP Individuel Meddelelse om ATC-Flyveplansforslag (Indivi-
dual ATC Flight Plan Proposal Message)E.1
IAPL Individuel ATC-Flyveplansmeddelelse (Individual ATC
Flight Plan Message)E.1
IARR Individuel Ankomstsmeddelelse (Individual Arrival
Message)E.1
ICHG Individuel Modifikationsmeddelelse (Individual Modifica-
tion Message)E.1
ICNL Individuel Annuleringsmeddelelse (Individual Cancellation
Message)E.1
IDEP Individuel Afgangsmeddelelse (Individual Departure
Message)E.1
IDLA Individuel Forsinkelsesmeddelelse (Individual Delay
Message)E.1
IFPL Individuel Flyveplansmeddelelse (Individual Flight Plan
Message)E.1
INF Informationsmeddelelse (Information Message) E.32000R2082 — DA — 15.06.2002 — 001.001 — 122
▼B
Titel DefinitionIndtroduceret i
Afsnit
IRPL Individuel, Standard Flyveplan (Individual Repetitive Flight
Plan)E.1
IRQS Individuel Anmodning om Supplerende Flyveplan (Indivi-
dual Request Supplementary Flight Plan)E.1
ISPL Individuel Supplerende Flyveplan (Individual Supplemen-
tary Flight Plan)E.1
LAM LogiskKvitteringsmeddelelse (Logical Ack nowledgement
Message)E.3, E.5
LRM LogiskAfvisningsmeddelelse (Logical Rejection Message) E.3
MAC Meddelelse for Ophævelse af Koordinering (Message for
Abrogation of Co-ordination)E.3
MAN Manuel Verserende Behandlingsmeddelelse (Manuel
Processing Pending Message)E.1
MAS Manuel Meddelelse om Antagelse af Kommunikation
(Manual Assumption of Communications Message)E.3
MODCOND Meddelelse om Modifikation af Exceptionel Betingelse for
ATFM (ATFM Exceptional Condition Modification
Message)E.2.3
MODREG Meddelelse om Modifikation af ATFM-Bestemmelse
(ATFM Regulation Modification Message)E.2.3
MRA ObligatoriskRuteak tiveringsmeddelelse (Mandatory Route
Activation Message)E.2.3
MRCNL ObligatoriskRuteannulleringsmeddelelse (Mandatory Route
Cancellation Message)E.2.3
MRMOD ObligatoriskRutemodifik ationsmeddelelse (Mandatory
Route Modification Message)E.2.3
NEWREG Underretningsmeddelelse om Ny ATFM-Bestemmelse (New
ATFM Regulation Notification Message)E.2.3
NTA Meddelelse om Ingen TrafikAccepteret (No Traffic
Accepted Message)E.2.3
NTACNL Meddelelse af Annullering af Ingen TrafikAccepteret (No
Traffic Accepted Cancellation Message)E.2.3
NTAMOD Meddelelse med Modifikation af Ingen Trafik Accepteret
(No Traffic Accepted Modification Message)E.2.3
OLRA Off-Load Ruteaktiveringsmeddelelse (Off-Load Route
Activation Message)E.2.3
OLRCNL Off-Load Ruteannulleringsmeddelelse (Off-Load Route
Cancellation Message)E.2.3
OLRMOD Off-Load Rutemodifikationsmeddelelse (Off-Load Route
Modification Message)E.2.3
PAC Foreløbig Aktiveringsmeddelelse (Preliminary Activation
Message)E.3
RAP Meddelelse om Henvist Aktiveringsforslag (Referred
Activate Proposal Message)E.3
RCHG Meddelelse om Modifikation af Standard Flyveplansdata
(Repetitive Flight Plan Data Modification Message)E.1
RCNL Meddelelse om Annullering af Standard Flyveplansdata
(Repetitive Flight Plan Data Cancellation Message)E.1
RDY Klarmeddelelse (Ready Message) E.2.2
REJ Afvisningsmeddelelse (Rejection Message) E.1REV Revideringsmeddelelse (Revision Message) E.3RJC Meddelelse om Afvisning af Koordinering (Reject Co-ordi-
nation Message)E.5
RJT Meddelelse om Afvisning af Gendirigering (Re-Routing
Rejection Message)E.2.2
ROF Frekvensanmodningsmeddelelse (Request On Frequency
Message)E.32000R2082 — DA — 15.06.2002 — 001.001 — 123
▼B
Titel DefinitionIndtroduceret i
Afsnit
RRP Meddelelse med Gendirigeringsforslag (Re-Routing
Proposal Message)E.2.2
RRV Meddelelse om Henvist Revideringsforslag (Referred Revi-
sion Proposal Message)E.3
SAM Slot-allokeringsmeddelelse (Slot Allocation Message) E.2.2
SBY Stand-by Meddelelse (Stand-by Message) E.3
SDM Supplerende Datameddelelse (Supplementary Data
Message)E.3
SIP Meddelelse med Slot-forbedringsforslag (Slot Improvement
Proposal Message)E.2.2
SLC Meddelelse om Annullering af Slot-krav (Slot Requirement
Cancellation Message)E.2.2
SMM Meddelelse om Forfejlet Slot (Slot Missed Message) E.2.2
SPA Meddelelse om Accept af Slot-forslag (Slot Proposal
Acceptance Message)E.2.2
SRJ Meddelelse om Afvisning af Slot-forslag (Slot Proposal
Rejection Message)E.2.2
SRM Slot-revideringsmeddelelse (Slot Revision Message) E.2.2
SRR Meddelelse om Slot-revideringsanmodning (Slot Revision
Request Message)E.2.2
TIM Overførselsinitieringsmeddelelse (Transfer Initiate Message) E.3
UUP Meddelelse med Opdateret Plan for Brug af Luftrum
(Updated Airspace Use Plan Message)E.4
XAP Meddelelse om Alternativt Krydsningsforslag (Crossing
Alternate Proposal Message)E.5
XCM Krydsningsannulleringsmeddelelse (Crossing Cancellation
Message)E.5
XIN Underretningsmeddelelse om Krydsningshensigt (Crossing
Intention Notification Message)E.5
XRQ Krydsningsanmodningsmeddelelse (Crossing Request
Message)E.52000R2082 — DA — 15.06.2002 — 001.001 — 124
▼B
ANNEKSC (Retningsgivende)
CENTRALT INDEKS OVER RESERVEREDE MEDDELELSESTITLER
C.1.Introduktion
Dette anneks indeholder et centralt indeks over reserverede meddelelses-
titler, 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ål
Formå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
Reserveret Titel Meddelelsestype Reserveret af
ACTARR Aktiveringsmeddelelse for en Ankomst (Activation
Message for an Arrival)FRANKRIG
ACTDEP Aktiveringsmeddelelse for en Afgang (Activation
Message for an Departure)FRANKRIG
ADMFPL ADMAR2000 Flyveplansmeddelelse (ADMAR2000
Flight Plan Message)TYSKLAND
ADMFPT ADMAR2000 Flyveplansafslutningsmeddelelse
(ADMAR2000 Flight Plan Termination Message)TYSKLAND
ADMFPU ADMAR2000 Flyveplansopdateringsmeddelelse
(ADMAR2000 Flight Plan Update Message)TYSKLAND
ANM ATFM-Underretningsmeddelelse (ATFM Notification
Message)CFMU
ANSWERCT Reaktionsmeddelelse (Response Message) (Terminal
Control System)FRANKRIG
ANSWM Reaktionsmeddelelse (Response Message) (ODS) FRANKRIG
ANSXFPLCT Reaktionsmeddelelse (Response Message) FRANKRIG
ATT Landingsmeddelelse (Landing Message) FRANKRIG
BEGINPROC Meddelelse om Begyndelse af Behandling (Begin
Processing Message)FRANKRIG
BEGPROC Meddelelse om Flyveleders Arbejdspositionsinitialise-
ringsprocedure (Controller Working Position Initialisa-
tion Procedure Message) (ODS)FRANKRIG
BEGPROCCT Meddelelse om Flyveleders Arbejdspositionsinitialise-
ring (Controller Working Position Initialisation
Message) (Terminal Control System)FRANKRIG
CDA Afgangsklareringsmeddelelse (Departure Clearance
Message) (ARINC 623)FRANKRIG
CDAFTX Afgangsklarering (Departure Clearance) (ARINC 620) FRANKRIG
CHGDEP Modifikationsmeddelelse for en Afgangsflyvning
(Modification Message for a Departure Flight)FRANKRIG
CLD Afgangsklarering (Departure Clearance) (ARINC 623) FRANKRIG
CLDFTX Afgangsklarering (Departure Clearance) (ARINC620) FRANKRIGCNLARR Annullering af en Ankomst (Cancellation of an Arrival) FRANKRIG
CNLCOND Annullering af Exceptionel Betingelse (Cancellation of
a Exceptional Condition)CFMU
CNLDEP Annullering af en Afgang (Cancellation of a Departure) FRANKRIG
CNLREG Annullering af en ATFM-Bestemmelse (Cancellation of
an ATFM Regulation)CFMU2000R2082 — DA — 15.06.2002 — 001.001 — 125
▼B
Reserveret Titel Meddelelsestype Reserveret af
CONFEND Slutmeddelelse til en Forandring af Operationel Konfi-
gurering (End Message to a change of Operational
Configuration)FRANKRIG
CONFIDM Operationel Konfigureringsmeddelelse (Operational
Configuration Message) (ODS)FRANKRIG
CONFIDMCT Operationel Konfigureringsmeddelelse (Operational
Configuration Message) (Terminal Control System)FRANKRIG
DEC Startmeddelelse (Take-Off Message) FRANKRIG
DOUBM Meddelelse om Duplikering af Flyveplan (Duplication
Flight Plan Message)FRANKRIG
DRT Meddelelse om Modifikation af Bestemmelsessted
(Modification of Destination Message)FRANKRIG
EATARR Meddelelse om Opdatering af Beregnet Ankomsttid
(Update of Estimatede Arrival Time Message)FRANKRIG
ENDPROC Sidste Meddelelse om Flyveleders Arbejdspositionsini-
tialiseringsprocedure (Controller Working Position
Initialisation Procedure Last Message) (ODS)FRANKRIG
ENDPROCCT Sidste Meddelelse om Flyveleders Arbejdspositionsini-
tialiseringsprocedure (Controller Working Position
Initialisation Procedure Last Message) (Terminal
Control System)FRANKRIG
EVLARR Præ-Aktiveringsmeddelelse for Ankomst (Pre-Activa-
tion Message for Arrival)FRANKRIG
EVLDEP Præ-Aktiveringsmeddelelse for Afgang (Pre-Activation
Message for Departure)FRANKRIG
EXCOND Aktivering af en Exceptionel Betingelse (Activation of
an Exceptional Condition)CFMU
FICM Meddelelse om Frembringelse af Flyvedata (Flight Data
Creation Message)FRANKRIG
FLXVIVO Meddelelse om Beskrivelsesvisning for »Fleksibel
Kurs« (»Flexible Track« Description Display Message)FRANKRIG
FPCLOSE Flyveplansdatalukningsmeddelelse (Flight Plan Data
Close Message) (ODS)FRANKRIG
FPCLOSECT Flyveplansdatalukningsmeddelelse (Flight Plan Data
Close Message) (Terminal Control System)FRANKRIG
FPCLOSED Duplikering af Flyveplansdatalukningsmeddelelse
(Duplication of Flight Plan Data Close Message) (ODS)FRANKRIG
FPCRD Aktivering af Flyveplansmeddelelse (Activation of
Flight Plan Message) (ODS)FRANKRIG
FPCRDCT Aktivering af Flyveplansmeddelelse (Activation of
Flight Plan Message) (Terminal Control System)FRANKRIG
FPCRDD Meddelelse om Duplikering af Flyveplansdataaktive-
ring (Duplication of Flight Plan Data Activation
Message) (ODS)FRANKRIG
FPCRE Meddelelse om Frembringelse af Flyveplan (Creation
of Flight Plan Message) (ODS)FRANKRIG
FPCRECT Meddelelse om Frembringelse af Flyveplan (Creation
of Flight Plan Message) (Terminal Control System)FRANKRIG
FPINI Meddelelse om Præ-Aktivering af Flyveplan (Pre-
Activation of Flight Plan Message) (ODS)FRANKRIG
FPINICT Meddelelse om Præ-Aktivering af Flyveplan (Pre-
Activation of Flight Plan Message) (Terminal Control
System)FRANKRIG
FPINID Meddelelse om Duplikering af Præ-Aktivering af
Flyveplan (Duplication of Pre-Activation of Flight
Plan Message)FRANKRIG
FPNTF Meddelelse om Præ-Aktivering af Flyveplan (Pre-
Activation of Flight Plan Message) (ODS)FRANKRIG2000R2082 — DA — 15.06.2002 — 001.001 — 126
▼B
Reserveret Titel Meddelelsestype Reserveret af
FPNTFD Meddelelse om Duplikering af Præ-Aktivering af
Flyveplan (Duplication of Pre-Activation of Flight
Plan Message) (ODS)FRANKRIG
FPRDU Flyvedatainformationsmeddelelse for en Ikke-Vedrørt
Sektor (Flight Data Information Message for a Non-
Concerned Sector) (ODS)FRANKRIG
FPRDUCT Flyvedatainformationsmeddelelse for en Ikke-Vedrørt
Sektor (Flight Data Information Message for a Non-
Concerned Sector) (Terminal Control System)FRANKRIG
FSM Meddelelse om Afgangsklareringssystem (Departure
Clearance System Message) (ARINC 623)FRANKRIG
FSMFTX Meddelelse om Afgangsklareringssystem (Departure
Clearance System Message) (ARINC 620)FRANKRIG
FSR Meddelelse med Anmodning om Flyvesuspension
(Flight Suspension Request Message)CFMU
IACHD Individuel ATC-Modifikationsmeddelelse (Individual
ATC Modification Message)TYSKLAND
ICHGD Individuel Modifikationsmeddelelse (Individual Modifi-
cation Message)TYSKLAND
IDEPD Individuel Afgangsmeddelelse (Individual Departure
Message)TYSKLAND
IDLAD Individuel Forsinkelsesmeddelelse(Individual Delay
Message)TYSKLAND
IFPDQ Individuel Forespørgselsmeddelelse om Flyveplansdata
(Individual Flight Plan Data Query Message)CFMU
IFPDQR Individuel Svarmeddelelse på Forespørgsel om Flyve-
plansdata (Individual Flight Plan Data Query Reply
Message)CFMU
IFPDSQ Individuel Forespørgselsmeddelelse om Flyveplansdata-
sammenfatning (Individual Flight Plan Data Summary
Query Message)CFMU
IFPDSQR Individuel Svarmeddelelse på Forespørgsel om Flyve-
plansdatasammenfatning (Individual Flight Plan Data
Summary Query Reply Message)CFMU
IFPLD Individuel Flyveplan (Individual Flight Plan) TYSKLAND
INFOM Informationsmeddelelse (Information Message) FRANKRIGIRQS Individuel Meddelelse med Anmodning om Supple-
rende Information (Individual Request for Supplemen-
tary Information Message)CFMU
ISPL Individuel Supplerende Flyveplansmeddelelse (Indivi-
dual Supplementary Information Message)CFMU
LGR Flyveplansmeddelelsesliste (Flight Plan Message List) FRANKRIG
LISTFP Flyveplansmeddelelsesliste (Flight Plan Message List)
(ODS)FRANKRIG
LISTFPCT Flyveplansmeddelelsesliste (Flight Plan Message List)
(Terminal Control System)FRANKRIG
LOGON Identifikation af Flyveplansmeddelelse (Indication
ofFlight Plan Message)FRANKRIG
MAJVIVO Meddelelse om Daglige Bevægelser (Daily Movements
Message)FRANKRIG
MCOM Koordineringsmeddelelse (Co-ordination Message) FRANKRIG
MODCOND Modifikation af en Exceptionel Betingelse (Modifica-
tion of an Exceptional Condition)CFMU
MODREG Modifikation af en ATFM-Bestemmelse (Modification
of an ATFM Regulation)CFMU
MRA Aktivering af en Obligatorisk Rute (Activation of a
Mandatory Route)CFMU
MRCNL Annullering af en ObligatoriskRute (Cancellation of a
Mandatory Route)CFMU2000R2082 — DA — 15.06.2002 — 001.001 — 127
▼B
Reserveret Titel Meddelelsestype Reserveret af
MRMOD Modifikation af en Obligatorisk Rute (Modification of
a Mandatory Route)CFMU
MRR ObligatoriskGendirigeringsmeddelelse (Mandatory Re-
Routing Message)CFMU
MVTVIVO Informationsmeddelelse om Bevægelser (Movements
Information Message)FRANKRIG
NEWREG Aktivering af en ATFM-Bestemmelse (Activation of an
ATFM Regulation)CFMU
NTA Aktivering af en »Ikke Tilladt« Trafikafvikling (Activa-
tion of a »Not Allowed« Traffic Flow)CFMU
NTACNL Annullering af en »Ikke Tilladt« Trafikafvikling
(Cancellation of a »Not Allowed« Traffic Flow)CFMU
NTAMOD Modifikation af en »Ikke Tilladt« Trafikafvikling
(Modification of a »Not Allowed« Traffic Flow)CFMU
OCLM OceaniskKlareringsmeddelelse (Oceanic Clearance
Message)FRANKRIG
OCLMD Meddelelse om Duplikering af Oceanisk Klarering
(Duplication of Oceanic Clearance Message)FRANKRIG
OLRA Aktivering af en Off-Load Rute (Activation of an Off-
Load Route)CFMU
OLRCNL Annullering af en Off-Load Rute (Cancellation of an
Off-Load Route)CFMU
OLRMOD Modifikation af en Off-Load Rute (Modification of an
Off-Load Route)CFMU
PAMAER Baneanvendelsesmeddelelse (Runway Application
Message)FRANKRIG
PAMARB »On-Stand« Bekræftelsesmeddelelse (»On-Stand«
Confirmation Message)FRANKRIG
PAMARRANN Annullering af Parkeringsallokering for en Ankomst
(Cancellation of Parking Allocation for an Arrival)FRANKRIG
PAMARRCRE Allokering af Parkeringsposition for en Ankomst (Allo-
cation of Parking Position for an Arrival)FRANKRIG
PAMARRPST Modifikation af Parkeringsallokering for en Ankomst
(Modification of Parking Allocation for an Arrival)FRANKRIG
PAMDAPARB Parkeringsmeddelelse for Ankomstluftfartøj (Parking
Message for Arrival Aircraft)FRANKRIG
PAMDAPCRE Allokering af en Parkeringsposition (Allocation of a
Parking Position)FRANKRIG
PAMDEPANN Annullering af Parkeringsallokering for en Afgang
(Cancellation of Parking Allocation for a Departure)FRANKRIG
PAMDEPCRE Parkeringsallokering for en Afgang (Parking Allocation
for a Departure)FRANKRIG
PAMDEPPST Modifikation af Parkeringsallokering for en Afgang
(Modification of Parking Allocation for a Departure)FRANKRIG
PAMDRB »Off-Stand« Bekræftelsesmeddelelse (»Off-Stand«
Confirmation Message)FRANKRIG
QTAARR Returnering til Original »Frembragt« Status for en
Ankomst (Return to Original »Created« Status for an
Arrival)FRANKRIG
QTADEP Returnering til Original »Frembragt« Status for en
Afgang (Return to Original »Created« Status for a
Departure)FRANKRIG
RCD Meddelelse med Anmodning om Afgangsklarering
(Request Departure Clearance Message) (AIRINC 623)FRANKRIG
RCDFTX Meddelelse med Anmodning om Afgangsklarering
(Request Departure Clearance Message) (AIRINC 620)FRANKRIG
REVARR Revideringsmeddelelse for en Ankomst (Revision
Message for an Arrival)FRANKRIG2000R2082 — DA — 15.06.2002 — 001.001 — 128
▼B
Reserveret Titel Meddelelsestype Reserveret af
RFPDQ Meddelelse med Forespørgsel om Standard Flyveplans-
data (Repetitive Flight Plan Data Query Message)CFMU
RFPDQR Svarmeddelelse på Forespørgsel om Standard Flyve-
plansdata (Repetitive Flight Plan Data Query Reply
Message)CFMU
RFPDSQ Meddelelse med Forespørgsel om Sammenfatning af
Standard Flyveplansdata (Repetitive Flight Plan Data
Summary Query Message)CFMU
RFPDSQR Svarmeddelelse på Forespørgsel om Sammenfatning af
Standard Flyveplansdata (Repetitive Flight Plan Data
Query Summary Reply Message)CFMU
RIEM Flyvedatainformationsmeddelelse (Flight Data Informa-
tion Message)FRANKRIG
RMG Forfejlet Indflyvningsmeddelelse (Missed Approach
Message)FRANKRIG
RRA Meddelelse om Gendirigeringsaccept (Re-Routing
Acceptance Message)CFMU
RREC Meddelelse om Genoprettelse af Standard Flyveplan
(Repetitive Flight Plan Recovery Message)CFMU
RRN Gendirigeringsunderretningsmeddelelse (Re-Routing
Notification Message)CFMU
RSUS Meddelelse om Standard Flyveplanssuspension (Repeti-
tive Flight Plan Suspension Message)CFMU
RWYCHGCT Banekonfigureringsmeddelelse (Runway Configuration
Message)FRANKRIG
TRACT Anmodning om Flyveplansaktivering (Request for
Flight Plan Activation) (ODS)FRANKRIG
TRACTCT Anmodning om Flyveplansaktivering (Request for
Flight Plan Activation) (Terminal Control System)FRANKRIG
TRCNL Anmodning om Flyveplansannulering (Request for
Flight Plan Cancellation) (ODS)FRANKRIG
TRCNLCT Anmodning om Flyveplansannulering (Request for
Flight Plan Cancellation) (Terminal Control System)FRANKRIG
TRCOR Anmodning om Manuel Korrelering (Request for
Manual Correlation)FRANKRIG
TRDECOR Anmodning om Manuel De-Korrelering (Request for
Manual De-Correlation)FRANKRIG
TRFIC Anmodning om Frembringelse af Flyveplansdata
(Request for Creation of Flight Plan Data) (ODS)FRANKRIG
TRFICCT Anmodning om Frembringelse af Flyveplansdata
(Request for Creation of Flight Plan Data) (Terminal
Control System)FRANKRIG
TRFLRQT Meddelelse om Anmodning om Flyveniveau (Request
Flight Level Message)FRANKRIG
TRMOD Anmodning om Flyveplansmodifikation (Request for
Flight Plan Modication) (ODS)FRANKRIG
TRMODCT Anmodning om Flyveplansmodifikation (Request for
Flight Plan Modication) (Terminal Control System)FRANKRIG
TRMODH Anmodning om Tidsmodifikation (Request for Time
Modication)FRANKRIG
TRMODHD Anmodning om Tidsmodifikation for Forsinket
Flyvning (Request for Flight Plan Modication for
Delayed Flight)FRANKRIG
TRMVT Koordineringsanmodning for Udgående Flyvning (Co-
ordination Request for Exiting Flight) (ODS)FRANKRIG
TRMVTCT Koordineringsanmodning for Udgående Flyvning (Co-
ordination Request for Exiting Flight) (Terminal
Control System)FRANKRIG
TRPOINT SpecifikFlyvedataanmodningsmeddelelse (Specific
Flight Data Request Message)FRANKRIG2000R2082 — DA — 15.06.2002 — 001.001 — 129
▼B
Reserveret Titel Meddelelsestype Reserveret af
TRRET Anmodning om Revidering af Flyveplan til »Frem-
bragt« Status (Request for Revision of Flight Plan to
»created« status) (ODS)FRANKRIG
TRRETCT Anmodning om Revidering af Flyveplan til »Frem-
bragt« Status (Request for Revision of Flight Plan to
»created« status) (Terminal Control System)FRANKRIG
TRRIP Anmodning om Visning af Flyvedatainformation
(Request for Display of Flight data Information) (ODS)FRANKRIG
TRRIPCT Anmodning om Visning af Flyvedatainformation
(Request for Display of Flight data Information)
(Terminal Control System)FRANKRIG
TRRQT Flyveplansanmodning (Flight Plan Request) (ODS) FRANKRIG
TRRQTCT Flyveplansanmodning (Flight Plan Request) (Terminal
Control System)FRANKRIG
TRSHRQT Anmodning om SHOOT-Handling (Request for
SHOOT Action)FRANKRIG
TRSTAR Anmodning om Flyveleders Arbejdspositionsinitialise-
ring (Controller Working Position Initialisation
Request) (ODS)FRANKRIG
TRSTARCT Anmodning om Flyveleders Arbejdspositionsinitialise-
ring (Controller Working Position Initialisation
Request) (Terminal Control System)FRANKRIG
TRTRP Overførselspositionsmeddelelse (Transfer Position
Message)FRANKRIG
UNKFP Meddelelse om Undertrykkelse af Flyveplan (Suppres-
sion of Flight Plan Message) (ODS)FRANKRIG
UNKFPCT Meddelelse om Undertrykkelse af Flyveplan (Suppres-
sion of Flight Plan Message) (Terminal Control
System)FRANKRIG2000R2082 — DA — 15.06.2002 — 001.001 — 130
▼B
ANNEKSD (Retningsgivende)
CENTRALT INDEKS OVER RESERVEREDE FELTER
D.1.Introduktion
Dette anneks indeholder et centralt indeks over reserverede felter:
Primære, Underfelter og Hjælpeudtryk, som endnu ikke er blevet defi-
neret 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ål
Formå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
Reserveret
HjælpeudtrykSyntaks SemantikAnvendt i
Primært FeltAnvendt i
UnderfeltAnvendt
i Hjæl-
pefelt
centreidentifi-
cation1{ALPHA}4 Center-identifika-
tion.ctsrc
ripsrcctripectdest
contextfdpsid 'opepal' | 'opesos' |
'evalpal' | 'tsto-
pepal' |'tstopesos'En FDPS-anven-
delses operations-
tilstand.
(Operationel,
Test, osv.)ctxtfdps
contextphi-
diasid'ope'|'eva-
l1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Specifik fordet
franskesystemctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Indgangspunkt
for kontrolpositi-
onen (»E«).
Udgangspunkt for
kontrolpositionen
(»S«),
XFL-punkt (X),
OCL-punkt (O).coorpt
eoidentifica-
tion1{ALPHANU-
M}6Identifikation af
en »operationel
enhed«.eosrc eoid
fl3 'F' ! 3{DIGIT}3 Flyveniveau
udtrykt i antal
hundrede fod.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Flyveprofilens
Projiceredetendens.
U for Op (Up)D for Ned
(Down)
S for Stabil
(Stable).etrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Flyveplansstatus
inden i ACC.fpctst2000R2082 — DA — 15.06.2002 — 001.001 — 131
▼B
Reserveret
HjælpeudtrykSyntaks SemantikAnvendt i
Primært FeltAnvendt i
UnderfeltAnvendt
i Hjæl-
pefelt
latitude 4{ DIGIT }4 En breddegrad
udtrykt som fire
cifre.Reserveret
til fremtidig
brug
latitudeshort 2{ DIGIT }2 En breddegrad
udtrykt som to
cifre.Reserveret
til fremtidig
brug
longitude 5{ DIGIT }5 En længdegrad
udtrykt som fem
cifre.Reserveret
til fremtidig
brug
longitude-
short3{ DIGIT }3 En længdegrad
udtrykt som tre
cifre.Reserveret
til fremtidig
brug
pointcautra 1{ALPHANU-
M}5Specifik fordet
franskesystemfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Arbejdsposition
aktuel eller
logisk.posid
qfuid ('0'|'1'|'2'|'3')!1{
DIGIT }1!('L'|'C'
|'R'|NIL)QFU for en bane.
L = Venstre
(Left)
C= CenterR = Højre (Right)qfu qful
secidentifica-
tion1{ALPHANU-
M}2Sektor–identifika-
tion.secdest
secsrcsecid
sendingre-
ason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|'MVTSEC'|'COO-
RAUTO'|
'MODHD'|
'CNL'|'RADA-
R'|'INIT'
|'RQT'|'TRF'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|
'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|
'PKG'Årsag til at sende
flyveplansdata.event
starreason 'TOTAL' Typen af initiali-
sering af en posi-
tion med
flyveplansdata.streason
temperature ("N" | "P") !
2{DIGIT}2Temperatur
udtrykt i grader
Celsius (00-99)
med angivelsen af
fortegnet (Nega-
tivt eller Positivt).temp2000R2082 — DA — 15.06.2002 — 001.001 — 132
▼B
Reserveret
HjælpeudtrykSyntaks SemantikAnvendt i
Primært FeltAnvendt i
UnderfeltAnvendt
i Hjæl-
pefelt
updatereason ('T'!('R'|NIL)|'R') Type af den
senest foretagede
opdatering af
flyvedata.g
Operator- trans-
aktion (»T«).
Radaropdatering
(»R«).udpt
D.4.Reserverede Primære Felter
Reserveret
Primært
FeltArt Syntaks Semantik
aabd b '-' "AABD" date Aktuel on-block ankomstdato.
aabt b '-' "AABT" timehhmm Aktuel on-block ankomsttidspunkt.
acnf c '-' "ACNF" ad rcnf [qfulist] Banekonfigurering.
aobd b '-' "AOBD" date Aktuel off-block dato.
aobt b '-' "AOBT" timehhmm Aktuelt off-block tidspunkt.
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Flyvningens indflyvningstype (1
ciffer, værdier: 1, 2, 3).
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Luftfartøjsidentifikation anvendt af
luftfartøjsoperatorer.
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Lokalt, entydigt luftfartøjsidentifi-
kationsnummer anvendt af ATC.
atis b '-' "ATIS" 1{ALPHA}1 Indikator for Automatisk Terminal
Information Service.
autfl1 b '-' "AUTFL1" fl3 Autoriseret flyveniveau 1.
autfl2 b '-' "AUTFL2" fl3 Autoriseret flyveniveau 2.
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Tilvejebringer de data, der skal
transmitteres i en koordinerings-
meddelelse:
sendetidspunkt, udgangspunkt,
flyveniveau over udgangspunkt,
glideflugtsflyveniveau og informa-
tion angående, hvorvidt niveauet er
i overensstemmelse med aftaler.
avail b '-' "AVAIL" 'YES'|'NO' Angivelse med hensyn til hvorvidt
en sektor har tilladelse eller ej til at
modificere en flyveplandata.
bkrow b '-' "BKROW" 1{DIGIT}2 Positionen af et henvisningspunkt i
en optegnelse over rutepunkter.
bkt b '-' "BKT" datetime Tidspunkt over henvisningspunktet
for en transaktion.
codetr b '-' "CODETR" 'YES'|'NO' Angivelse af, hvorvidt ssrcode bør
transmitteres (eller ej) til piloten af
kontrolpositionen.
confid b '-' "CONFID" 1{DIGIT}5 Operationel konfigureringsidentifi-
kation (sektorer|positioner).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"Optegnelse over tilknytninger af
sektorer/positioner for et center en-
route.
crspd b '-' "CRSPD" 1{DIGIT}4 Cruise hastighed i knob.
ctripe b '-' "CTRIPE" centreidentification Navn på et modtagende center for
en transaktion.
ctrow b '-' "CTROW" 1{DIGIT}1 Positionen af et center i en opteg-
nelse over centre.
ctsrc b '-' "CTSRC" centreidentification Identifikation af sendende center.2000R2082 — DA — 15.06.2002 — 001.001 — 133
▼B
Reserveret
Primært
FeltArt Syntaks Semantik
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Operationstilstand for Terminal
Control System.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Operationstilstand for en FPDS.
ctxtpos b '-' "CTXTPOS" contextphidiasid Operationstilstand for ODS.
curfl b '-' "CURFL" fl3 Indeværende flyveniveau.curpos c '-' "CURPOS" ptid | (lattd longtd) Indeværende position.
curpost b '-' "CURPOST" datetime Dato og tidspunkt ved indeværende
position.
curptt b '-' "CURPTT" datetime Dato og tidspunkt for overflyvning
af indeværende punkt.
curptx b '-' "CURPTX" 1{DIGIT}2 Nummereret position af indevæ-
rende punkt i en optegnelse over
rutepunkter.
dcatcid b '-' "DCATCID" icaoaerodrome Flyveplads, der er ansvarlig for
afgangsklarering, når den gives af
FDPS til luftfartøjet via datalink.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | »ACK«Grundlæggende tekst for ARINC
623 afgangsklareringsmeddelelser.
»ACK« for kvitteringsmeddelelse.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDCREQUEST IGNORED' | 'ACK'Grundlæggende tekst for ARINC
620 afgangsklareringsmeddelelser.
»ACK« for kvitteringsmeddelelse.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Afgangsklareringsstatus for en
flyvning.
dcid b '-' "DCID" 1{DIGIT}3 Systemtal for afgangsklarering.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Afgangsklareringsmeddelelsestype.dcref b '-' "DCREF" 1{ALPHANUM}5 Konteksthenvisning for en afgangs-
klarering.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Bemærkning for en afgangsklare-
ring.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MEDDELELSE'.Supplerende tekst for Afgangskla-
reringssystemmeddelelsen (ARINC
623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE
PROCEDURE'Anden Supplerende tekst for
Afgangsklareringssystemmedde-
lelsen (ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Dag, timer, minutter, sekunder for
afgangsklareringen.
delcode b -' "DELCODE"
1{ALPHANUM}20Årsag til en forsinkelse.
dfdpsid b '-' "DFDPSID datetime ! seconds Data for Identifikation af Flyveda-
tabehandlingssystem.
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identifikation af en »duplikeret«
enhed.
ecurptt b '-' "ECURPTT" datetime Beregnet tidspunkt for overflyvning
af indeværende punkt.
eda b '-' "EDA" date Beregnet ankomstdato.
elastptt b '-' "ELASTPTT" datetime Beregnet tidspunkt for overflyvning
af rutens sidste punkt.
endhldt b '-' "ENDHLDT" datetime Sluttid for holding-mønster.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Antal forekomster af en flyveplan i
et center.2000R2082 — DA — 15.06.2002 — 001.001 — 134
▼B
Reserveret
Primært
FeltArt Syntaks Semantik
entryt b '-' "ENTRYT" datetime Indgangstidspunkt for positionen.
enxtptt b '-' "ENXTPTT" datetime Beregnet tidspunkt for overflyvning
af næste punkt (gives ikke, hvis det
indeværende punkt er det sidste
punkt).
eobdt b '-' "EOBDT" datetime Dato og beregnet off blocktids-
punkt.
eosrc b '-' "EOSRC" eoidentification Operationel »enheds«-identifika-
tion.
espfl b '-' "ESPFL" flightlevel Supplerende overførselsflyveniveau
for den foregående kontrolposition.
eta b '-' "ETA" timehhmm Beregnet ankomsttidspunkt.
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyIndgangsflyveniveau eller flyvepro-
filtendens.
event b '-' "EVENT" sendingreason Igangsættende hændelse for FDPS.
firstpid b '-' "FIRSTPID" pointcautra Specifik fordetfranskesystem
flbkb '-' "FLBK" flightlevel Flyveniveau for det sidste transak -
tionshenvisningspunkt for en akti-
veret flyvning eller modificeret
niveau for henvisningspunkt for en
transaktion.
fpbaseid b '-'FPBASEID" datetime!seconds Identifikation af Flyveplansdata-
base.
fpctst b '-' "FPCTST" fpcentrestate Flyveplansstatus i et Center.fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Optegnelse over de kendte, men
endnu ikke overførte flyveplaner
for en position.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Flyvekategori:
T = overflyvning
E = indgående
S = udgående
I = intern.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Optegnelse over Flyveplansinfor-
mation for et kaldesignal.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Optegnelse over flyveplansfelter.
fplnb b '-' "FPLNB" 1{DIGIT}1 Antal flyveplaner
fra 0 til 5.
fplstat b '-' "FPLSTAT" "T" | "C" Flyvnings status:
T = afsluttet
C = aktiv.
fprmkb '-' "FPRMK" 1{LIM_CHAR}8 Indledende flyveplansbemærk -
ninger.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"|"FIC-
PAC"|"FPL"|"RPL"|"NKW")Flyveplanskilde.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Optegnelse over »ukendte« flyve-
planer.
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Meddelelse i fri tekst.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Identitet af Fleksibel kurs.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Navn på Fleksibel kurs.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Frembringelsestal for Fleksibel
kurs.
grspd b '-' "GRSPD" 1{DIGIT}4 Beholden fart i knob.2000R2082 — DA — 15.06.2002 — 001.001 — 135
▼B
Reserveret
Primært
FeltArt Syntaks Semantik
hldbkrw b -' "HLDBKRW" 1{DIGIT}2 Nummerposition af et henvisnings-
punkt for et holding-mønster i en
optegnelse over rutepunkter.
icing b '-' "ICING" 1{ALPHA}8 Isdannelse.
»SPOR« eller »LET« eller
»MODERAT« eller »VOLDSOM«.
indstip b '-' "INDSTIP" 'STIP' Specifik fordetfranskesystem
initid b '-' "INITID" 1{DIGIT}1 Initialiseringstal.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Systemgrænsefladeidentifikator for
FDPS/ODS eller FDPS/Terminal.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Optegnelse over breddegrad og
længdegrad af punkter på ruten.
lang b '-' "LANG" '?' Indikator for samtalesprog.
»?«= sproget er ikke almindeligt i
firmaet.
lastradt b '-' "LASTRADT" datetime Sidste opdateringstidspunkt givet
ved radarinformation.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Lights code.maint b '-' "MAINT" 'YES'|'NO' Angivelse af, hvorvidt datainfor-
mationen for en kontrolposition
bibeholdes kontinuerligt eller ej.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Information i SSR Tilstand A.
modec b '-' "MODEC" flightlevel Information i SSR Tilstand C.
msgbody b '-' "MSGBODY"
1{CHARACTER}Indeholder en tegnfølge, som er
identiskmed helheden bestående af
den ækvivalente og eksisterende
ikke-ADEXP meddelelse.
msgct b '-' "MSGCT" datetime ! seconds Tidsstempling af meddelelsen i
formatet: Dag, timer, minutter,
sekunder.
nat b '-' "NAT" 1{ALPHA}1 Identifikation af en Nordatlantisk
kurs.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Næste frekvenskontakt.
nxtfir b '-' "NXTFIR" icaoaerodrome Næste FIR, der skal kontaktes.
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Næste position.
nxtpost b '-' "NXTPOST" datetime Tidspunkt over den næste position.oclfl b '-' "OCLFL" flightlevel OceaniskKlareringsgrænse (OCL)
flyveniveau.
oprfl b '-' "OPRFL" flightlevel Anmodning om Flyveniveau modi-
ficeret af en operator.
oprmkc '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Optegnelse over Operatorbemærk-
ninger.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Operatorbemærkninger.
oriented b '-' "ORIENTED" 'YES'|'NO' Orienteret flyvning eller ej.
pfl b '-' "PFL" flightlevel Planlagt Flyveniveau (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistRadarsporkoordinater og hastig-
hedsvektorkoordinater.
pistid b '-' "PISTID" 1{DIGIT}4 Radarsporidentifikation.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Parkeringsposition for en ankom-
mende flyvning.
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Parkeringsposition for en afgående
flyvning.
plnid b '-' "PLNID" 4{DIGIT}4 Flyveplansidentifikation.2000R2082 — DA — 15.06.2002 — 001.001 — 136
▼B
Reserveret
Primært
FeltArt Syntaks Semantik
plnold b '-' "PLNOLD" 4{DIGIT}4 Gammel Flyveplansidentifikation.
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Tilstand af Koordineringsbevægelse
for positionen:
Accepteret Bevægelse for
Indgangen (MAE) eller Udgangen
(MAS) eller Foreslået Bevægelse
for Udgangen (MPS) eller Foreslået
Bevægelsesudgangsalarm (MPSA)
eller position endnu ikke bevægel-
seskoordineret (NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Antal punkter på ruten.qfu b '-' "QFU" qfuid Identifikation af Bane i brug
(QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Quebec-flyvning eller ej.radioid b '-' "RADIOID"
1{ALPHANUM}20Radioidentifikation.
reqid b '-' "REQID" 1{DIGIT}5 Nummer på en anmodning.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Flyveplansanmodningstype.ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Optegnelse over enheder, der skal
modtage flyveplansdata
ripsrc b '-' "RIPSRC" centreidentification Identifikation af det center, som er
ansvarligt for initieringen af trans-
missionen af flyveplansdata.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' IFPS-transaktionsnummer i en
flyveplansanmodning.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Optegnelse over CAUTRA-punk-
terne på en ustyret rute.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Optegnelse over rutepunkter for
bestemte transaktioner.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Optegnelse over flyvepladskonfigu-
reringer.
secdest b '-' "SECDEST" secidentification Identifikator for Modtagende
sektor.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Global Optegnelse over sektorer.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Global Optegnelse over sektorerne.
secsrc b '-' "SECSRC" secidentification Identifikator for Hidrørende sektor.
spfl b '-' "SPFL" flightlevel Supplerende Flyveniveau.ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Transmitteret SSR-kode.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmStempelidentifikation.
streason b '-' "STREASON" starreason Årsag til en initialiseringsanmod-
ning udstedt fra en arbejdsposition.
strid b '-' "STRID" 1{DIGIT} RDPS-identifikator.temp b '-' "TEMP" temperature Temperatur.terminal b '-' "TERMINAL"
1{ALPHANUM}2Navn på terminalen.
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Optegnelse over mulige transakti-
oner for kontrolpositionen og for
den specificerede flyveplan.2000R2082 — DA — 15.06.2002 — 001.001 — 137
▼B
Reserveret
Primært
FeltArt Syntaks Semantik
trfl b '-' "TRFL" flightlevel | flightten-
dancyOverførselsflyveniveau eller
tendensinformation om en flyve-
profil.
turb b '-' "TURB" 1{ALPHA}8 Turbulens = LET eller MODERAT
eller VOLDSOM.
validend b '-' "VALIDEND" datetime Sluttidspunkt for visning.
validst b '-' "VALIDST" datetime Starttidspunkt for visning.
visi b '-' "VISI" 1{ALPHANUM}20 Sigtbarhed.
wddir b '-' "WDDIR" 1{DIGIT}3 Vindretning udtrykt i grader fra 0
til 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Vindhastighed udtrykt i knob.
xfl b '-' "XFL" flightlevel Udgangsflyveniveau (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Reaktionsmeddelelse på en flyve-
plansanmodning.
D.5.Reserverede Underfelter
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Flyveplansfelter som
kan modificeres til
tidspunktet for en
flyvnings aktivering.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxImplicit FL, minimalt
FL og maximalt FL
for henvisnings-
punktet for en trans-
aktion. FL er fælles,
kan være RFL, PFL,
osv.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Den værdi (+/-) ved
hvilken en tids-
mæssig modifikation
for et punkt er tilladt.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxImplicit Klareret
Flyveniveau (CFL),
minimalt CFL og
maksimalt CFL for
henvisningspunktet
for en transaktion.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-tilstand og allo-
keret kode.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-tilstand og -
kode, som er tilgæn-
gelig til brug.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-tilstand og -
kode, der tidligere er
allokeret.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-tilstand og -
kode, som er blevet
reserveret til brug og
som derfor ikke er
tilgængelig.ssrcodes2000R2082 — DA — 15.06.2002 — 001.001 — 138
▼B
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
coorpt b '-' "COORPT" coord-
pointsKendetegn for koor-
dineringspunkt:
Indledende, Udgangs-
, OCL, XFL.ptc
ctdest b '-' "CTDEST"
centreidentificationModtagende center
(ACC).destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTidsinterval til be-
regningen af en
minimal tid.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTidsinterval til be-
regningen af en
maksimal tid.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Hastighedsinterval
for beregningen af en
minimal hastighed.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Hastighedsinterval
for beregningen af en
maksimal hastighed.spdchg
destid c '-' "DESTID" ctdest
secripATC-Center og
optegnelse over
sektorer, som flyve-
plansdata skal sendes
tilripel
edto b '-' "EDTO" dateti-
me|"WT"Beregnet tidspunkt
over et punkt i år,
måned, dag, timer,
minutter, eller indi-
kator »point without
time« (»punkt uden
tid«) »WT«.ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationOperationelt navn på
»enhed«.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Optegnelse over
operationelle enheder
knyttet til en kontrol-
position.eopos
eopos c '-' "EOPOS" posid
[eolist]Navn på kontrolposi-
tion og optegnelse
over operationelle
enheder knyttet til
denne position.confl
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'R-
TE'|'ADEP'|'CODE'|'-
LANG'|'BK'|spdchg|r-
flchg|cflchg|pflchg|tf-
lchg|sflchg|xflchg|bk-
chg|bktchg|'QFU'|'PK-
DEP'|'SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Identifikation af
felter, der kan modi-
ficeres for en trans-
aktion.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Beregnet flyveniveau
ved udgangskoordi-
neringspunkt, hvilket
kan transmitteres i
den automatiske
koordineringsmedde-
lelse til det næste
center.automsg
flimp b '-' "FLIMP" flight-
levelImplicit flyveniveau. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg2000R2082 — DA — 15.06.2002 — 001.001 — 139
▼B
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
flmax b '-' "FLMAX" flight-
levelMaksimalt flyven-
iveau.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" flight-
levelMinimalt flyven-
iveau.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbFlyveplansidentifika-
tion i en meddelelse.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobt»Sammenfatnings«-
flyveplansdata.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidFlyveplansidentifika-
tion.fplist
lalg c '-' "LALG" lattd
longtdBreddegrad og læng-
degrad af hvert punkt
på ruten.laglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Optegnelse over
felter, som kan modi-
ficeres efter aktive-
ring.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Optegnelse over
felter, som kan modi-
ficeres i en tidsopda-
teringstransaktion
efter aktivering.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Optegnelse over
felter, der kan modi-
ficeres i en manuelt
igangsat koordinering
mellem sektorer.transid
pflchg c '-' "PFLCHG" flimp
flmin flmaxImplicit, minimalt og
maksimalt niveau for
modifikation af PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Planlagt flyveniveau,
som vil blive trans-
mitteret i den auto-
matiske koordine-
ringsmeddelelse til
det næste center. Plus
en angivelse af, hvor-
vidt niveauet er i
overensstemmelse
med de anførte,
operationelle aftaler.
NA = Ikke i overens-
stemmelse med
aftale.automsg
pka b '-' "PKA"
1{ALPHANUM}3Reserveret parke-
ringsposition, endnu
ikke allokeret.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indikator af, at luft-
fartøjet venter på en
parkeringsposition.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Allokeret parkerings-
position.pkarr2000R2082 — DA — 15.06.2002 — 001.001 — 140
▼B
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
pointid b '-' "POINTID" point-
cautraSpecifik fordet
franskesystem.ptpro
posid b '-' "POSID" positioni-
dentificationNavn på Kontrolposi-
tion.eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Kendetegn for et
rutepunkt.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameSpecifik fordet
franskesystem.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Beskrivelse af fore-
slåede rutepunkter.rtetr
qful c '-' "QFUL" qfuid Gyldig QFU for en
given bane på en
flyveplads.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Optegnelse over
gyldige QFUer for en
flyveplads.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Generel start- og
landingsretning for en
flyveplads.
(Øst, Vest, osv.)acnf
ref c '-' "REF" (refi-
d|ref1id)Kendetegn for et
henvisningspunkt for
en transaktion.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Identifikation af et
muligt henvisnings-
punkt for en transak-
tion.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identifikation af det
mest sandsynlige
henvisningspunkt for
en transaktion.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Bestemmelsesinfor-
mation, som er
specifikfor de
franske systemer.regul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Bestemmelsesinfor-
mation, som er
specifikfor de
franske systemer.regul
regult b '-' "REGULT" date-
timeBestemmelsesinfor-
mation, som er
specifikfor de
franske systemer.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Optegnelse over
felter, der kan modi-
ficeres i en transak-
tion til at returnere
flyveplansdataene til
deres foregående
status.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxImplicit, minimalt og
maksimalt niveau for
modifikationen af
RFLet.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Tekst i en flyveleder-
bemærkning.oprmk2000R2082 — DA — 15.06.2002 — 001.001 — 141
▼B
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
sec c '-' "SEC" secid
[seccar]Identifikation af og
kendetegn for ACC-
sektorer, som flyve-
plansdata skal sendes
til.seclist secrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Kendetegn for en
ACC-sektor:
- Første sektor (»F«)
- Sidste sektor (»L«)
- Accepteret til
Indgang (»M«)
- kildesektor til
»duplikering« (»D«)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)/('M'!('V'/NIL)/NIL)
/'V'Kendetegn for en
Terminalsektor:
- Første sektor (»F«)
- Sidste sektor (»L«)
- Accepteret tilIndgang (»M«)secct
secct c '-' "SECCT" secid
[seccarct]Identifikation og
kendetegn for Termi-
nalsektorer.seclistct
secid b '-' "SECID" seciden-
tificationSektoridentifikation. secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Optegnelse over
modtagende enheder
(sektorer eller
afgangs-/ankomst-
kontrolenheder) , som
flyveplansdata skal
sendes til.destid
sendt b '-' "SENDT" datetime Tidspunkt for afsen-
delse af koordine-
ringsmeddelelse.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxImplicit, minimalt og
maksimalt niveau for
modifikation af
Supplerende Flyven-
iveau (SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Nedre og øvre
hastighedsintervaller
for modifikationen af
flyveplanshastigheden
i løbet af en transak-
tion.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxImplicit, minimalt og
maksimalt niveau for
modifikation af
Overførselsflyveni-
veau (TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Kendetegn for et
punkt i forhold til en
flyvnings trajectorie:
S = Splitpunkt
M = Mergepunkt
T = Abeam punkt
A = STAR punktptc
ptpro
transid b '-' " TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Identifikation af
mulig transaktion for
kontrolpositionen for
denne flyveplan eller
en indikator »NO«,
som betyder at trans-
aktion ikke er mulig.translist2000R2082 — DA — 15.06.2002 — 001.001 — 142
▼B
Reserve-
rede
UnderfelterArt Syntaks SemantiksAnvendt i
Primært
FeltAnvendt i
Underfelt
txt b '-' "TXT"
1{LIM_CHAR}80Fri tekst. freetxt
udpt b '-' "UDPT" updatere-
asonSidste opdatering
forårsaget af
operator- og/eller
radarinformation.ptc
view b '-' "VIEW"
('V'|'VNX')Angivelse af et
punkts »synbare«
beskaffenhed.
V = synbart
VNX = ikke synbart
(kunstigt punkt)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positiv
N:= NegativX-koordinat for en
radarpositions hastig-
hedsvektor.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positiv
N:= NegativY-koordinat for en
radarpositions hastig-
hedsvektor.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxMinimalt og maksi-
malt niveau for
modifikation af et
Udgangsflyveniveau
(XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positiv
N:= NegativX-koordinat for en
radarposition.pistcoord
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positiv
N:= NegativY-koordinat for en
radarposition.pistcoord2000R2082 — DA — 15.06.2002 — 001.001 — 143
▼B
ANNEKSE (Informativt)
INTRODUKTION AF MEDDELELSESGRUPPER
INTRODUKTION
Dette Anneks tilvejebringer en introduktion til de forskellige grupper eller kate-
gorier af meddelelser, som kan udveksles i ADEXP. En fuldstændig fortegnelse
over alle ADEXP-meddelelsestitler er givet i Anneks B.
NOTE For de nøjagtige betingelser, regler for anvendelse og feltbrug, i særde-
leshed anvendelsen af valgfri felter, bør der henvises til den relevante
dokumentation (f.eks. Interface Specification document) for de vedrørte
systemer.
E.1. Flyveplansmeddelelser
E.1.1.Introduktion
Meddelelser inden for denne kategori udveksles primært mellem AO,
IFPS og de relevante ATS-Enheder.
E.1.2.Definition afMeddelelsestitler
Meddelelsestitler 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 Doku-
menthenvisning 3.
E.1.3.SammensætningafPrimæreFelter
Detaljeret definition af meddelelsesindhold, dataindsættelsesregler og
brugen af obligatoriske og valgfri felter kan findes i Dokumenthen-
visning 3.
Eksempel
Flyveplansmeddelelse-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 9803051231522000R2082 — DA — 15.06.2002 — 001.001 — 144
▼B
-PT -PTID LOTEE -FL F330 -ETO 980305124401
-PT -PTID AVS -FL F330 -ETO 980305125357-PT -PTID KORET -FL F330 -ETO 980305130137-PT -PTID BARKO -FL F330 -ETO 980305130734-PT -PTID CANAR -FL F330 -ETO 980305131544-PT -PTID VIS -FL F330 -ETO 980305132220
-PT -PTID FTM -FL F234 -ETO 980305133230
-PT -PTID LPPT -FL F000 -ETO 980305134529-END RTEPTS-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT
UR107 QPR AVS
-ATSRT UG41 AVS FTM
E.2. Meddelelser vedrørende Regulering af Afvikling af Lufttrafikken
E.2.1.Introduktion
Meddelelser inden for denne kategori udveksles primært mellem
TACT-system i Eurocontrol CFMU, Luftfartøjsoperatorer og ATS-
Enheder.
E.2.2.ComputerassisteretSlot-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 Meddelelsestitler
Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 5.
E.2.2.2. Sammensætning af Primære Felter
Detaljeret definition af meddelelsesindhold, dataindsættelsesregler og
brugen af obligatoriske og valgfri felter kan findes i Dokumenthen-
visning 5.
Eksempel
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3.Informationsmeddelelser
Meddelelsestitler inden for denne kategori er:FSA
E.2.3.1. Definition af Meddelelsestitler
Definerende materiale for denne meddelelse vil være tilgængelig i
Dokumenthenvisning 5.
E.2.3.2. Sammensætning af Primære Felter
Definition af meddelelsesindhold, dataindsættelsesregler og brugen af
obligatoriske og valgfri felter kan findes i Dokumenthenvisning 5.
Eksempel
Første Systemaktiveringsmeddelelse-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 1646
E.3. ATC Koordineringsmeddelelser
E.3.1.Introduktion
Koordineringsmeddelelser anvendes til at automatisere operationel
koordinering og udvekslingen af information mellem ATC-enheder.2000R2082 — DA — 15.06.2002 — 001.001 — 145
▼B
Meddelelserne sikrer den rettidige levering af operationel informa-
tion, der vedrører koordinering, gennem standardiserede
datauddragelses- og transmissionsevner.
E.3.2.Definition afMeddelelsestitler
Meddelelsestitler 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 Doku-
menthenvisning 6.
E.3.3.SammensætningafPrimæreFelter
Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 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 STN
Aktiveringsmeddelelse
-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 005 -ARCID AMM253
-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO
1226 -TFL F350
-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4
BPK UB3 HON
E.4. Meddelelser vedrørende Regulering af Luftrum
E.4.1.Introduktion
Meddelelser anvendt i koordineringen af luftrumsregulering. Disse
meddelelser dækker reguleringen af de omgivelser, hvori trafikken
bevæger sig: de permanente og betingede ruter, midlertidigt afson-
drede områder, farlige og forbudte områder, osv.
E.4.2.Definition afMeddelelsestitler
Meddelelsestitler inden for denne kategori er:AUP, CRAM, UUP.Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 7.
E.4.3.SammensætningafPrimæreFelter
Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 7.
Eksempel
Meddelelse 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
1998033006002000R2082 — DA — 15.06.2002 — 001.001 — 146
▼B
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030
199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700
199803291330
-END LACDR
E.5. Civile / Militære Koordineringsmeddelelser
E.5.1.Introduktion
Meddelelser anvendt i koordineringen af flyvedata og luftrumskryd-
sningsanmodninger mellem civile og militære ATS-enheder.
E.5.2.Definition afMeddelelsestitler
Meddelelsestitler inden for denne kategori er:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 7.
E.5.3.SammensætningafPrimæreFelter
Alt definerende materiale for disse meddelelser er indeholdt i Doku-
menthenvisning 7.
Eksempel
Meddelelse 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 0051500E
Acceptmeddelelse
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — DA — 15.06.2002 — 001.001 — 147
▼B
ANNEKSF (Informativt)
EKSEMPLER PÅ ADEXP-MEDDELELSESFORMAT
De 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æse-
ligt. 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 UR262000R2082 — DA — 15.06.2002 — 001.001 — 148
▼B
SAVIN UG18 BUI UB1 TALAS
-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414
-PT -PTID RIDER -FL F327 -ETO 980317073726-PT -PTID MAH -FL F330 -ETO 980317074130-PT -PTID MUN -FL F330 -ETO 980317074449
-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109-PT -PTID GRZ -FL F330 -ETO 9803170080830
-PT -PTID DIMLO -FL F330 -ETO 980317081443
-PT -PTID BABIT -FL F330 -ETO 980317083107-PT -PTID SAVIN -FL F330 -ETO 980317083613-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204
-PT -PTID VAL -FL F330 -ETO 980317084629-PT -PTID KAVOR -FL F330 -ETO 980317085329-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS
EKSEMPEL 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 -ETO2000R2082 — DA — 15.06.2002 — 001.001 — 149
▼B
980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID
BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO
980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID
TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO
980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -
ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT
UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS
EKSEMPEL 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 TALAS2000R2082 — DA — 15.06.2002 — 001.001 — 150
▼B
ANNEKSG (Informativt)
FREMTIDIGE UDVIKLINGER
G.1.Introduktion
Dette anneks er tiltænkt at tilvejebringe en angivelse af den foreslåede,
fremtidige udvikling ADEXP og årsagerne og målsætningen bag udvik-
lingen.
G.2.Målsætning
En 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 genop-
rettelse 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.Forslag
For at opnå målsætningen med genoprettelse ved et hvilket som helst
niveau inden i en meddelelse er det nødvendigt, at den leksikale analy-
sator 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 indledestarten 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 prin-
cippet.
Eksempler
Foreliggende Format Foreslået Format
Eksempel på Grundlæggende Felt: -RFL F330 (RFL F330)Eksempel på Sammensat Felt: -CRSCLIMB
-PTID DUB-CRSPEED M084
-CRFL1 F370
-CRFL2 F430(CRSCLIMB
(PTID DUB)(CRSPEED M084)
(CRFL1 F370)
(CRFL2 F430))2000R2082 — DA — 15.06.2002 — 001.001 — 151
▼B
BILAGIII
DOKUMENT VEDRØRENDE KONTROL MED UDVEKSLING AF
FLYVEDATA (FLIGHT DATA EXCHANGE INTERFACE CONTROL
DOCUMENT: FDE-ICD), UDGAVE 1.0
(Eurocontrols dokumentreference: COM.ET1.ST12-STD)2000R2082 — DA — 15.06.2002 — 001.001 — 152
▼B
INDHOLDSFORTEGNELSE
ANGIVELSE AF OPHAVSRET
FORORD1. INTRODUKTION2. OMFANG3. HENVISNINGER
3.1. Introduktion3.2. Henvisninger
4. DEFINITIONER, SYMBOLER OG FORKORTELSER
4.1. Definitioner4.2. Symboler og Forkortelser4.3. Notationer
5. TEKNISK OVERSIGT
5.1. Protokolstack5.2. Profilens Struktur5.3. Forhold til Tidligere Versioner af Specifikationen
6. PROFILKRAV
6.1. Krav med hensyn til Overensstemmelse6.2. Krav til Øvre Lag6.3. Krav til Nedre lag6.3.1. Krav til Transportlag6.3.2. Krav til Netværkslag6.3.3. Krav til Datalinklag6.3.4. Krav til Fysiske Lag
7. AFPRØVNINGSMETODERANNEKS A (RETNINGSGIVENDE) MEDDELELSESOVERFØRSELSPROTOKOL
A.1. IntroduktionA.2. Implementeret TjenesteA.3. Antaget TjenesteA.4. ProtokolspecifikationA.4.1. IntroduktionA.4.2. Typer af DataA.4.3. Etablering af TilslutningA.4.4. DataoverførselA.4.5. Velordnet Frigivelse af TilslutningA.4.6. Genetablering af TilslutningA.4.7. Integritet af TilslutningA.4.8. Uordentlig Frigivelse af TilslutningA.4.9. Genoprettelse fra Fejl2000R2082 — DA — 15.06.2002 — 001.001 — 153
▼B
A.4.10. Meddelelsesformater
A.5. Tabeller over ProtokoltilstandsovergangeA.5.1. Introduktion
A.5.2. Tilstandsdefinitioner
A.5.3. Mulige HændelserA.5.4. TimereA.5.5. TilstandsovergangstabelA.5.6. Tilstandsovergangsdiagram
ANNEKS B (RETNINGSGIVENDE) MEDDELELSESTOPPROTOKOL
B.1. IntroduktionB.2. Implementeret TjenesteB.3. Antaget TjenesteB.4. ProtokolspecifikationB.4.1. Etablering af ForbindelseB.4.2. Undgåelse af Redundante NetværksforbindelserB.4.3. Frigivelse af ForbindelseB.4.4. Dataoverførsel
ANNEKS C (RETNINGSGIVENDE) NETVÆRKSPROTOKOL
C.1. IntroduktionC.2. Tilvejebragt TjenesteC.3. Antaget TjenesteC.4. NSAP-AdresseringC.4.1. IntroduktionC.4.2. NSAP-AdressestrukturC.4.3. Tildeling af ATC-Enhedsidentifikatorer og -SelektorerC.5. ProtokolspecifikationC.5.1. OversigtC.5.2. AdresseindkodningC.5.3. Indkodning af Brugerdatafeltet
C.5.4. Behandling af Adresser i INCOMING CALL-Pakker
C.5.5. Dataoverførsel
ANNEKS D (RETNINGSGIVENDE) PROFIL-SPECIFIKKE PICS-PROFORMAER
D.1. Introduktion
D.2. Instruktioner til at Fuldstændiggøre PICS-Proformaerne
D.2.1. Generel Struktur af PICS-ProformaerneD.2.2. Yderligere InformationD.2.3. UndtagelsesinformationD.2.4. Betingede EmnerD.3. PICS-Proforma for MeddelelsesoverførselsprotokollenD.3.1. Forkortelser og Specielle Symboler2000R2082 — DA — 15.06.2002 — 001.001 — 154
▼B
D.3.2. Identifikation
D.3.3. Protokolimplementering
D.4. PICS Proforma for MeddelelsestopprotokollenD.4.1. Forkortelser og Specielle SymbolerD.4.2. IdentifikationD.4.3. ProtokolimplementeringD.5. PICS-Proforma for NetværksprotokollenD.5.1. Forkortelser og Specielle SymbolerD.5.2. Identifikation
D.5.3. Protokolimplementering
ANNEKS E (RETNINGSGIVENDE) PROFILKRAVLISTE
E.1. IntroduktionE.2. Funktionen af PRLen og PICS-ProformaerneE.3. NotationE.4. Instruktioner til at Fuldstændiggøre PICS-ProformaerneE.5. HenvisningerE.6. Meddelelse vedrørende OverensstemmelseE.6.1. Oversigt over Overensstemmelse
E.6.2. Dynamiske Krav med hensyn til Overensstemmelse
E.7. Krav til Øvre LagE.8. Krav til Nedre lagE.8.1. Krav til TransportlagE.8.2. Krav til NetværkslagE.8.3. Krav til DatalinklagE.8.4. Krav til Fysiske Lag
ANNEKS F (INFORMATIVT) METODOLOGI TIL OVERENSSTEMMELSESAFPRØVNING
F.1. Introduktion
F.2. Formål og Omfang
F.3. BibliografiF.4. Udviklingsmetoder og PraksisF.5. AfprøvningerF.5.1. IntroduktionF.5.2. Afprøvning af de Nedre lag (Lag 1 til 3)F.5.3. Afprøvning af ApplikationslagetF.5.4. Certificering
F.5.5. Notificering
ANNEKS G (INFORMATIVT) TILDELING AF ATC-ENHEDSIDENTIFIKATORER
ANNEKS H (INFORMATIVT) VEJLEDNING OM PÅLIDELIGHED, TILGÆNGELIGHED OG
SIKKERHED
H.1. Introduktion2000R2082 — DA — 15.06.2002 — 001.001 — 155
▼B
H.2. Formål og Omfang
H.3. BibliografiH.4. Implementeringer med Fast Linie
H.4.1. Pålidelighed
H.4.2. TilgængelighedH.4.3. SikkerhedH.4.4. KonfigurationseksempelH.5. NetværksimplementeringH.5.1. PålidelighedH.5.2. TilgængelighedH.5.3. SikkerhedH.6. Generel Vejledning om Implementeringer med Fast Linie og NetværkH.6.1. PålidelighedH.6.2. TilgængelighedH.6.3. SystemadministrationH.6.4. Konfigurationseksempel2000R2082 — DA — 15.06.2002 — 001.001 — 156
▼B
ANGIVELSE AF OPHAVSRET
Dette dokument er frembragt af Eurocontrol Agenturet.
Ophavsretten besiddes af Eurocontrol Agenturet.Indholdet eller en hvilken som helst del deraf er således frit tilgængeligt for
repræsentanter fra Medlemslandene, men en kopi eller fremlæggelse af en
hvilken som helst del deraf skal gøres til genstand for forudgående, skriftligt
samtykke ved Eurocontrol Agenturet.2000R2082 — DA — 15.06.2002 — 001.001 — 157
▼B
FORORD
1. Ansvarlig Institution
Dette standarddokument er blevet forberedt af og vedligeholdes
af Arbejdsstyrken for den Flyveplansrelaterede Udveksling af
Data (FPDE) (the Flight Plan related Data Exchange (FPDE)
TaskForce) i Den Europæisk e Organisation for Luftfartens
Sikkerhed (the European Organisation for the Safety of Air Navi-
gation) (Eurocontrol).
2. EATCHIP-Arbejdsprogramdokument
Denne standard angår EATCHIP Arbejdsprogram dokumentet
(EWPD), Communications Domain, Overordnet Opgave 01,
Specialistopgave 12.
3. Godkendelse af standarden
3.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 Rettelser
Denne standard holdes under kontrol for at konstatere påkrævede
rettelser eller en teknisk rettelsesliste. Proceduren for vedligehol-
delsen af denne standard er fastlagt i Anneks H i the Directives
for the Uniform Drafting and Presentation of Eurocontrol Stan-
dard Documents (Direktiver vedrørende Ensartet Udarbejdelse ogPræsentation af Eurocontrolstandarddokumenter), Ref. 000-1-92.
5. Redaktionelle Konventioner
5.1. Formatet af denne standard er i overensstemmelse med Direktiver
vedrørende Ensartet Udarbejdelse og Præsentation af Eurocontrol-
standarddokumenter.
5.2. Den følgende notation er blevet anvendt til at angive hver erklær-
ings 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 specifikati-
oner 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 indryk-
kede og fortsættes ikke over adskillige sider.
6. Forhold til andre standarddokumenter
6.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 standard
Annekserne til denne standard har den følgende status:
— Anneks A — Retningsgivende
— Anneks B — Retningsgivende2000R2082 — DA — 15.06.2002 — 001.001 — 158
▼B
— Anneks C — Retningsgivende
— Anneks D — Retningsgivende
— Anneks E — Retningsgivende
— Anneks F — Informativt— Anneks G — Informativt— Anneks H — Informativt
8. Anvendt Sprog
Det engelske sprog er blevet anvendt til denne standards originale
tekst.2000R2082 — DA — 15.06.2002 — 001.001 — 159
▼B
1. INTRODUKTION
Denne 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 hard-
ware 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 omkost-
ningseffektiv måde ved at formindske antallet af forbindelser vedhvert Center og tillade brugen af gængs »ned-af-hylden« hard-
ware 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 rigoristiskspeci-
fikation, 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ærkog indførelsen
af nye standarder for nedre lag. Denne Eurocontrolstandard tilve-
jebringer 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. OMFANG
2.1. Dette Eurocontrolstandarddokument angiver en datakommunikati-
onsgrænseflade for udvekslingen af flyverelaterede
datameddelelser mellem Kontrolcentraler (ACCer). Det er frem-stillet i form af en profil for en Open Systems Interconnection
(OSI) (Indbyrdes Forbindelse mellem Åbne Systemer) som defi-
neret 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
N
o001-92 Udgave 1;
— understøttelse af transmission af OLDI applikationsmedde-
lelser 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 datane-
tværk, som tilvejebringer en grænseflade, der er i
overensstemmelse med CCITT Anbefaling X.25, 1980 eller
senere.
NOTER
1. Indretningen mellem Flyveplansbehandlende Systemer
(FPPSer) errepræsenteretiFigur1.2000R2082 — DA — 15.06.2002 — 001.001 — 160
▼B
2. Figur 1 viser ikke potentielle backupforbindelser, såsom
PSTN,forhvilke vejledning ergivet iAnneksH.
Figur1
Grænsefladeindretning
2.4. Detaljerede sikkerhedsaspekter ved den specificerede datakom-
munikationsgræ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. HENVISNINGER
3.1. Introduktion
De 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 ogstandarder, gyldige.
Der skal øjeblikkeligt tages hensyn til en hvilken som helst revi-
dering 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 Eurocontrolstandarddo-
kument.
I tilfælde af konflikt mellem kravene i dette Eurocontrolstandard-
dokument og indholdet i disse andre henviste dokumenter, skal
dette Eurocontrolstandarddokument have forrang.
3.2. Henvisninger
1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the
packet mode and connected to public data networks by dedi-
cated circuit.
2. ISO/IEC TR 10000-1:1992, Information technology —
Frameworkand taxonomy of International Standardized
Profiles: — Part 1: Framework(2. udgave).
3. ISO/IEC TR 10000-2:1994, Information technology —
Frameworkand taxonomy of International Standardized
Profiles — Part 2: Principles and Taxonomy for OSI Profiles
(3. udgave).2000R2082 — DA — 15.06.2002 — 001.001 — 161
▼B
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 — Telecommu-
nications and information exchange between systems —
High-level data linkcontrol procedures — Description of
the X.25 LAPB-compatible DTE Data Linkprocedures
(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 — Inter-
national Standardized Profiles TB, TC, TD and TE —
Connection-mode Transport Service over Connection-mode
NetworkService — Part 9: Subnetwork -type dependent
requirements for NetworkLayer, Data LinkLayer and
Physical Layer concerning permanent access to a packet-
switched data networkusing 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 — NetworkService 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 — Telecommu-
nications 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 (Eurocon-
trolstandard for On-Line Dataudveksling) (OLDI), No001-92,
udgave 1, 1992.
14. ISO/IEC 9646-1:1994, Information technology — Open
Systems Interconnection — Conformance testing methodo-
logy 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 networkor an integrated services
digital networkor 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 networkproviding
data transmission service.
20. ITU-T Recommendation X.121 (1993), International numbe-
ring plan for public data networks.
4. DEFINITIONER, SYMBOLER OG FORKORTELSER
4.1. Definitioner
4.1.1. Med henblikpå denne Eurocontrolstandard sk al de følgende defi-
nitioner 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, valg-2000R2082 — DA — 15.06.2002 — 001.001 — 162
▼B
muligheder 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 tabelliste-
format [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 Imple-
mentering 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 imple-
menteret [Henvisning 14].
4.2. Symboler og Forkortelser
Med henblikpå dette Eurocontrolstandarddok ument anvendes de
følgende symboler og forkortelser:
ACC Kontrolcentral
AFI Autoritets- og Formatidentifikator (Autho-
rity and Format Identifier)
ASCII Amerikansk Standardkode for informations-
udveksling (American Standard Code for
Information Interchange)
ATC FlyvekontroltjenesteATCC Flyvekontroltjenestecentral
CAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télégrap-
hique et téléphonique (nu ITU-T)
CFMU Enhed for Central ReguleringCUG Lukket Brugergruppe
DCE Udstyr til Datakredsløbsafslutning
DCTS Digitalt KommunikationsterminalsystemDSP DomænespecifikDelDTE DataterminaludstyrDÜV Dataoverførsels- og Fordelingssystem (Date-
nübertragungs- und Verteilungssystem)
FDE Flyvedataudveksling
FEP Front End ProcessorFPDE Flyveplansrelateret DataudvekslingFPPS Flyveplansbehandlende System
ICAO Den Internationale Civile Luftfarts Organi-
sation (International Civil Aviation
Organisation)
ICD Dokument vedrørende Kontrol (Interface
Control Document)
IDI Indledende Domæneidentifikator
IDP Indledende Domænedel
IEC International Elektroteknisk Kommission
(International Electrotechnical Commission)
INTERCAUTRA Inter-CAUTRA-protokol (Inter-CAUTRA
protocol)
ISO Den Internationale Standardiseringsorganisa-
tion
ITU-T International Telekommunikationsforening
— Telekommunikationsstandardiserings-
sektor (International Telecommunication
Union — Telecommunication Standardiza-
tion Sector)
ISDN Integrated Services Digital Network
LAPB LinkAccess Procedure Balanced
LSB Mindst Signifikante Bit
M, m Obligatorisk
MSB Mest Signifikante Bit2000R2082 — DA — 15.06.2002 — 001.001 — 163
▼B
MT Meddelelsesoverførsel
NA Ikke Gyldig
NS NetværkstjenesteNSAP Tilgangspunkt til NetværkstjenesteNSDU Dataenhed til Netværkstjeneste
O, O.<n> Valgfri, hvor <n> er er et tal til henvisning
o, o.<n> Valgfri, hvor <n> er er et tal til henvisningOLDI On-line DataudvekslingOSI Open Systems Interconnection (Indbyrdes
Forbindelse mellem Åbne Systemer)
PICS Meddelelse vedrørende Overensstemmelse
med hensyn til Implementering af Proto-
koller
PLP Pakkelag-ProtokolPRL Liste over ProfilkravPSTN Public Switched Telephone Network
(Offentligt Koblet Telefonnetværk)
ST-ICD Dokument vedrørende Kortsigtet Kontrol
med Udveksling
SUT System Under Afprøvning
T<x> Timer (hvor <x> er et enkelt eller dobbelt
bogstav til henvisning)
TA Terminaladapter
TSDU Dataenhed for TransporttjenesteTPDU Dataenhed for TransportprotokolTR Teknisk ISO-Rapport
X Forbudt
x Udelukket<emne>: Betinget Emne (afhængigt af emnets værdi)
4.3. Notationer
4.3.1. Med henblikpå dette Eurocontrolstandarddok ument 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 henblikpå dette Eurocontrolstandarddok ument 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
mindredeterspecificeretpåenandenmådeidehenviste
internationale standarder.
4.3.3. Med henblik på dette Eurocontrolstandarddokument skal statusen
af understøttelsen af trækved en basisstandard, eller denne Euro-
controlstandard, være vist med versaler (f.eks. M, O, O.<n>, X).
Den nøjagtige betydning af hvert statussymbol er beskrevet i
Annekserne i denne Eurocontrolstandard forud for deres brug.
4.3.4. Med henblikpå at definere Profilen FDE ICD, Del 1, i dette
Eurocontrolstandarddokument skal statusen af understøttelsen af
trækved en basisstandard eller ved denne Eurocontrolstandard
være vist med minuskler (f.eks. m, o, o.<n>, x).
NOTEResultateterenyderligereforædlingafdetrækvedbasis-
standarderne, som er betingede, valgfri eller
værdiafhængige (seE.3.1).
5. TEKNISK OVERSIGT
5.1. Protokolstack
NOTEProtokolstacken for denne Eurocontrolstandards profil er
illustreret i Figur 2. Figuren placerer protokollerne i
strukturenaftheOSIBasicReferenceModel(denGrund-
læggende OSI Referencemodel) [Henvisning 9] ved at
justere stacken med de tilsvarende OSI-lag. Imidlertid er2000R2082 — DA — 15.06.2002 — 001.001 — 164
▼B
protokolstacken en specifikation for præ-OSI-systemer og
denunderstøtterikkedemangefunktioner,somermulige
iOSI-protokollerfordetilsvarende OSI-lag.
Figur2
Protokolstack for profil
5.2. Profilens Struktur
NOTER1. Som vist i Figur 2, kombinerer profilstacken adskillige proto-
koller for nedre lag, hvoraf kun X.25 Pakkelag-Protokollen
(PLP) [Henvisning 1] og dens understøttende protokoller,
X.21 [Henvisning4]og X.21bis [Henvisning 5],er defineret i
eksisterende standarder fra ISO/IEC og Standarder fra Inter-
national 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. Kravmedhensyntiloverensstemmelseforprofilenkanhenvise
tildissespecifikationerpåligefodmedeksternestandarderog
erangivetAfsnit6.Dedetaljeredekraverangivetvedbrugaf
PRLernes tabelformat (Anneks E) og PICS-proformaer
(proformaer for protokoller, der er defineret i Annekserne, er
givetiAnneksD).BrugenafdissePRLerogPICS-proformaer
iudvikling og/elleranskaffelse erforklaret iAnneksE.
5.3. Forhold til Tidligere Versioner af Specifikationen
NOTER1. Denne profil er baseretpå det ST-ICD,derer udviklet afden
tidligere OLDI Tekniske Under-Gruppe. De protokoller og
pakkeformater,dererdefineretidetteEurocontrolstandarddo-
kument,erenkompatibeldelmængdeafST-ICDetsprotokoller
og pakkeformater med undtagelsen af, at denne Eurocontrol-
standard stiller mere detaljerede krav til anvendelsen af X.25
PLP,omfatterobligatoriskunderstøttelseafM-bittenogkorri-
gerer den inkonsistente specifikation af værdien af Autoritet-
ogFormatidentifikatoren (AFI) iadressenfor Tilgangspunktet
til Netværkstjenestens (NSAP).
2. Hovedændringen i stilen for dette Eurocontrolstandarddoku-
ment angår strukturen af ICD-specifikationen.
Meddelelsesoverførselsprotokollen (Anneks A) er adskilt fra
den understøttende T-profil.Dette vil lette brugen afandreT-
profiler, når dette bliver nødvendigt for at understøtte nye
FDE-krav.2000R2082 — DA — 15.06.2002 — 001.001 — 165
▼B
3. DedeleafST-ICD-specifikationen,somvedrørerkontrollenaf
X.25 virtuelle kredsløb og afgrænsning af applikationsmedde-
lelser, findes nu i Meddelelsestopprotokollen (Anneks B), som
udgøret minimalttransportlagforFDE.
6. PROFILKRAV
6.1. Krav med hensyn til Overensstemmelse
6.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 Medde-
lelse vedrørende Overensstemmelse med hensyn til
Implementering af Protokoller som beskrevet i Anneks D og
Anneks E.
6.2. Krav til Øvre Lag
6.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 lag
6.3.1. Kravtil Transportlag
6.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 4 097 oktetter.
NOTEDenførsteoktetiTSDUensvarertiletfeltiMeddelelses-
topteksten (se A.4.10 og B.4.4) og efterlader maksimalt
4096oktetter tilbrugerdata.
6.3.2. Kravtil Netværkslag
6.3.2.1. En overensstemmende implementering skal tilfredsstille kravene i
ISO/IEC 8208 [Henvisning 7] i overensstemmelse med den proto-
kolafbildning, 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 data-
kredslø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 forbin-
delse i overensstemmelse med specifikationen i Anneks C, dvs. at
protokollen er fuldstændigt symmetrisk.
NOTENogle eksisterende implementeringer baseret på ST-
ICDerermåskeikkeistandtilatinitierenetværksforbin-
delserioverensstemmelsemedprotokolleniAnneksC.
6.3.2.5. En overensstemmende implementering skal inden for en tidspe-
riode stemme overens med faciliteten med Ikke-standard, Default
Pakkestørrelser med værdien 256 for begge transmissionsret-
ninger.
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=0i CALLREQUEST-og CALLACCEPTED-
pakker har den effekt, at der ikke anvendes Leveringsbe-
kræftelse.2000R2082 — DA — 15.06.2002 — 001.001 — 166
▼B
6.3.3. Kravtil Datalinklag
6.3.3.1. En overensstemmende implementering skal tilfredsstille overens-
stemmelseskravene 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. Kravtil FysiskeLag
En overensstemmende implementering skal tilfredsstille overens-
stemmelseskravene i ISO/IEC ISP 10609-9 klausul 7
[Henvisning 8].
7. AFPRØVNINGSMETODER
NOTER1. Dererredegjortforenfremgangsmådetiloverensstemmelses-
afprøvning af implementeringer af denne specifikation i
AnneksF.
2. DererredegjortforanvendelsenafdePRLerogPICS-profor-
maer, som er tilvejebragt med denne specifikation til
dokumentoverensstemmelse,iAnneksE.2000R2082 — DA — 15.06.2002 — 001.001 — 167
▼B
ANNEKSA (Retningsgivende)
MEDDELELSESOVERFØRSELSPROTOKOL
A.1. Introduktion
Denne specifikation definerer en protokol til at implementere en
enkel meddelelsesoverførselstjeneste for applikationer, der kræver
flyvedataudveksling.
A.2. Implementeret Tjeneste
Meddelelsesoverførselsprotokollen (MT-protokollen) implementerer
de følgende, ubekræftede tjenester:
MT-Associate: etablerer en tilslutning til overførsel af en applikati-
onsmeddelelse;
MT-Data: overfører en applikationsmeddelelse, der består af ASCII-
karakterer (Karakterer ifølge Amerikansk Standardkode for informa-
tionsudveksling);
MT-Abort: afslutter en tilslutning til overførsel af en applikations-
meddelelse.
A.3. Antaget Tjeneste
Denne 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. Protokolspecifikation
A.4.1.Introduktion
I den følgende tekst er der kun beskrevet operationen af én applika-
tionsinitieret Meddelelseoverførselstilslutning. Yderligere
forbindelser kan understøttes af den samme netværksgrænseflade
ved at gentage disse procedurer for hver underliggende transportfor-
bindelse.
A.4.2.TyperafData
Dette Anneks identificerer fire typer af applikationsmeddelelser,
som svarer til de, der er defineret i Eurocontrolstandard No001-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 Eurocon-
trolstandarder 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ænseinformati-
onsmeddelelse (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.
NOTER
1. Anvendelsen af Systemmeddelelser er del af denne protokols
operationogderesformaterspecificeret iafsnitA.4.10.3idette
Anneks.
2. Anvendelsen og formatet af Statusmeddelelser er genstand for
bilateral aftale og er ikke yderligere specificeret i denne Euro-
controlstandard.2000R2082 — DA — 15.06.2002 — 001.001 — 168
▼B
3. Protokollens tilstand bestemmer, hvilken type af meddelelse, der
kantransmitteres,somspecificeret idefølgendeafsnit.
A.4.3.Etablering afTilslutning
A.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 transportforbin-
delse, 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 System-
meddelelser (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 medde-
lelsen som parameter.
A.4.3.4. En STARTUP-meddelelse (systemmeddelelse) skal dernæst trans-
mitteres, timeren Tr (se A.4.7) skal startes og protokollen går ind itilstanden 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_PEN-
DING, 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 yderli-
gere 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 ASSOCIATIO-
N_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 medde-
lelse bruges til STARTUP og til reaktion på STARTUP.
Som et resultat vil den Meddelelsesoverførselsprotokol, som
førstgikind itilstanden DATA_READY,modtageen yderli-
gere STARTUP-meddelelse. Som specificeret i A.4.3.5,
ignoreresdenneSTARTUP-meddelelse.
A.4.3.7. Når først STARTUP-meddelelser er blevet udvekslet, etableres
tilslutningen og alle de identificerede typer af meddelelser kan over-
føres (tilstand DATA_READY).
A.4.4.Dataoverførsel
Andre typer af meddelelser overføres på den samme måde som
Systemmeddelelser ved at anvende T-Data-tjenesten med medde-
lelsen 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 afTilslutning
A.4.5.1. Meddelelsesoverførselstilslutningen mellem to applikationer kan
frigives af en hvilken som helst af dem. Dette svarer til tjeneste-
grundproceduren MT-Abort-Request.2000R2082 — DA — 15.06.2002 — 001.001 — 169
▼B
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 afdennemeddelelse fradenandenside.
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 afTilslutning
Den 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).
NOTEHvisfrigivelsenaftilslutningenharresulteretifrigivelsenaf
den underliggende netværksforbindelse, skal der følges den
tilslutningsetableringsprocedure, som er specificeret i afsnit
A.4.3.
A.4.7.Integritet afTilslutning
A.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å transport-
forbindelsen, skal en konfigurabel timer Ts (gen)startes. Hvis
timeren Ts udløber i tilstanden DATA_READY, skal en HEART-
BEAT-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_PEN-
DING.
NOTEApplikationerne genoprettesoggensynkroniseresvedudvek-
slingen afSTARTUP-meddelelser(seA.4.3).
A.4.8.UordentligFrigivelse afTilslutning
A.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ølgedefinitionenpåtransportprotokolleniAnneksBerder
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.2000R2082 — DA — 15.06.2002 — 001.001 — 170
▼B
A.4.9.Genoprettelse fraFejl
A.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 tilslutningseta-
bleringsprocedure (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
delafapplikationslogikken),førderforsøgespåatgenstarte
linket.Dettevilafkortedenfjerneapplikationstidsudkobling
Tr og kan resultere i en hurtigere genoprettelse med en
mindrerisikofortabtdata.
A.4.10.Meddelelsesformater
A.4.10.1. Generel Meddelelsesstruktur
Alle meddelelser består af et heltalstypefelt (»TYP«) i intervallet
1…63 efterfulgt af meddelelseskernen. »TYP«-feltet er indkodet i
én oktet som en ASCII-karakter ved at addere '40'H til feltets
binære repræsentation (f.eks. indkodes værdien 3 som '43'H,
karakter »C«). Meddelelseskernen består af ASCII-karakterer, som
indkodes én per oktet. Dette giver det følgende format:
TYP Meddelelseskerne
oktet 1 oktet 2 …oktet n
A.4.10.2. Længde af Meddelelseskerne
Der skal understøttes meddelelseskerne med længder på op til og
med 4 096 oktetter.
A.4.10.3. Systemmeddelelsesformater
Systemmeddelelser kodes med TYP = 4, indkodes som '44'H.
Meddelelseskernen består af to oktetter, der er kodet som følger:
— STARTUP-meddelelse: '3031'H (ASCII digits "01");
— SHUTDOWN-meddelelse: '3030'H (ASCII digits "00");— HEARTBEAT-meddelelse: '3033'H (ASCII digits "03").
A.4.10.4. Andre Meddelelsesformater
Feltet TYP definerer meddelelsestypen, der er indkodet som
beskrevet ovenfor:
— værdi 1 (indkodet som '41'H) Operationelle meddelelser;
— værdi 2 (indkodet som '42'H) Operatormeddelelser;— værdi 5 (indkodet som '45'H) Statusmeddelelser.
NOTER
1. FormatetafmeddelelseskernenforStatusmeddelelserliggeruden
fordette Eurocontrolstandarddokumentsomfang.
2. Formatet for Operationelle meddelelser er specificeret i Euro-
controlstandarder og Dokumenter, der definerer
meddelelsesoverførselsapplikationer såsom On-Line Dataudveks-
ling[Henvisning13].
3. Operatormeddelelser består af skrivelig ASCII-tekst. Hvis disse
meddelelser understøttes, skal der tilvejebringes en brugergræn-
seflade til at vise modtagede meddelelser og til at muliggøre
sammensætningenafmeddelelsertiltransmission.2000R2082 — DA — 15.06.2002 — 001.001 — 171
▼B
A.5. Tabeller over Protokoltilstandsovergange
A.5.1.Introduktion
Tilstandstabellerne nedenfor er den definitive specifikation af proto-
kollen. 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 ogkanafvige fraST-ICD.
A.5.2.Tilstandsdefinitioner
Tabel1
Tilstandsdefinitioner
Tilstand Tilstandsbeskrivelse Yderligere Tilstandsinformation
tilstand 0 IDLE Ingen transportforbindelse
tilstand 1 READY Transportforbindelse etableret, lokal
bruger nede, fjern bruger nede
tilstand 2 ASSOCIATION_PEN-
DINGTransport forbindelse etableret, lokal
bruger oppe, fjern bruger nede
tilstand 3 DATA_READY Lokal bruger oppe, fjern bruger oppe
A.5.3.Mulige Hændelser
Tabel2
Mulige Hændelser
Beskrivelse af
HændelseYderligere Tilstandsinformation
L_data Indikation af, at der skal sendes data (Operationel meddelelse,
Operator- eller Statusmeddelelse) fra den lokale til den fjerne
bruger (grundprocedure MT-Data Request)
L_shutdown Der gives en kommando om at stoppe den lokale bruger (MT-
Abort Request)
L_startup Der gives en kommando om at starte den lokale bruger (MT-Asso-
ciate Request)
R_data Angiver, at der er modtaget data fra den fjerne bruger (T-Data
Indication, TYP ≠»System«)
R_heartbeat Der er modtaget en HEARTBEAT-meddelelse fra den fjerne
bruger (T-Data Indication, TYP = »System«, Meddelelseskode =
HEARTBEAT)
R_shutdown Der er modtaget en SHUTDOWN-meddelelse fra den fjerne
bruger (T-Data Indication, TYP = »System«, Meddelelseskode =
SHUTDOWN)
R_startup Der er modtaget en STARTUP-meddelelse fra den fjerne bruger
(T-Data Indication, TYP = »System«, Meddelelseskode =
STARTUP)
Ts_timeout Udløb af timer Ts
Tr_timeout Udløb timer Tr
TC_disconnect Der er modtaget en Transportforbindelsesfrigivelsesindikation (T-
Disconnect Indication)
TC_setup Hændelse (f.eks. eksplicit kommando, applikationsanmodning),
som forårsager en T-Connect Request grundprocedure2000R2082 — DA — 15.06.2002 — 001.001 — 172
▼B
A.5.4.Timere
Tabel3
Timere
Timer Timerinformation
Tr Tidsudkobling, når der forventes en HEARTBEAT- eller en data-
meddelelse
Ts Tidsudkobling for at sende en HEARTBEAT til den fjerne bruger
Værdien for disse timere skal være således, at Tr = 2Ts + transittid.
NOTETypiske værdierfordissetimereer:Ts=30s,Tr=70s.
A.5.5.Tilstandsovergangstabel
Tabel4
Tilstandsovergange
Tilstand Hændelse Handlinger, der skal foretages Ny Tilstand
Tilstand 0 TC_setup Transportlaget forsøger at opsætte
forbindelsen/forbindelserne for de
nedre lag mellem den lokale og
den fjerne bruger; når det er
lykkedes at etablere forbindelsen,
underrettes brugeren (1)tilstand 1
TC_disconnect Systemet foretager passende hand-
linger, men forbliver i tilstand 0tilstand 0
L_data Ignoreret tilstand 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignorér (hændelse bør ikke fore-
komme)tilstand 0
R_heartbeat
R_shutdown
R_startup
tilstand 1 L_startup Den lokale bruger sender en
STARTUP-meddelelse til den
fjerne bruger, timeren Tr startes (2)tilstand 2
R_startup Den lokale bruger modtager en
STARTUP-meddelelse fra den
fjerne bruger, denne STARTUP-
meddelelse ignoreres, idet en
L_startup-hændelese ikke er fore-
kommettilstand 1
L_data Ignoreret tilstand 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignoreret tilstand 1
Ts_timeout
L_shutdown Transportforbindelsen frigives tilstand 0
TC_disconnect Den lokal bruger underrettes om,
at transportforbindelsen er afbrudt
(f.eks. på grund af en fejl eller en
fjern nedlukning)tilstand 02000R2082 — DA — 15.06.2002 — 001.001 — 173
▼B
Tilstand Hændelse Handlinger, der skal foretages Ny Tilstand
tilstand 2 R_startup Den lokale bruger modtager en
STARTUP-meddelelse fra den
fjerne bruger; timerne Tr og Ts
startes; den lokale bruger under-
rettes om, at der kan sendes data
på tilslutningen og der underrettes
eksplicit om modtagelsen af
STARTUP-meddelelsen ved at
svare med en anden STARTUP-
meddelelse (3)tilstand 3
Tr_timeout Den lokale bruger gentransmitterer
en STARTUP-meddelelse, hvis
den ikke modtog en STARTUP-
meddelelse fra den fjerne bruger
inden for et specificeret tidsrum
Tr, timer Tr genstartestilstand 2
L_startup Ignoreret tilstand 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown Den lokale bruger pålægges at
lukke tilslutningen ned: en SHUT-
DOWN-meddelelse transmitteres,
timer Tr stoppes og transportfor-
bindelsen frigivestilstand 0
TC_disconnect Den lokale bruger underrettes om,
at transportforbindelsen er afbrudt
(f.eks. på grund af en fejl), timerTr stoppes og tilslutningen
afbrydestilstand 02000R2082 — DA — 15.06.2002 — 001.001 — 174
▼B
Tilstand Hændelse Handlinger, der skal foretages Ny Tilstand
tilstand 3 L_data Timer Ts genstartes tilstand 3
R_data Timer Tr genstartes tilstand 3
R_heartbeat
R_startup Hvis der modtages en STARTUP-
meddelelse fra den fjerne bruger,
betragtes den som en kvittering for
en tidligere sendt STARTUP-
meddelelse; timer Tr genstartes
ikketilstand 3
Ts_timeout Der sendes en HEARTBEAT-
meddelelse og timer Ts genstartestilstand 3
L_startup Ignoreret tilstand 3 (4)
TC_setup
R_shutdown Timer Ts stoppes; MT-Abort-Indi-
cation signaleres til den lokale
brugertilstand 2
Tr_timeout Timer Ts stoppes. MT-Abort-Indi-
cation signaleres til den lokale
bruger; timer Tr genstartestilstand 2
L_shutdown Der transmitteres en SHUT-
DOWN-meddelelse; timere Tr og
Ts stoppes og transportforbin-
delsen frigivestilstand 0
TC_disconnect Den lokale bruger underrettes om,
at transportforbindelsen er afbrudt
(f.eks. på grund af en fejl); timere
Tr og Ts stoppes og tilslutningen
afbrydestilstand 0
NOTER
(1) Når der gås ind i tilstand 0, kan det overvejes at generere hændelsen TC_setup automatisk.
(2) Hændelsen L_startup kan kun genereres automatisk, når der gås ind i tilstand 1 via en automatisk
genereret TC_setup som beskrevet i tilstand 0.
(3) Denne metode sikrer, at der altid kvitteres for en modtaget STARTUP-meddelelse fra en fjern
bruger ved hjælp af en STARTUP-meddelelse.
(4) Nogle eksisterende implementeringer, som går forud for dette Eurocontrolstandarddokument, kan
behandle denne hændelse som en TC_disconnect, dvs. vender tilbage til tilstand 0.2000R2082 — DA — 15.06.2002 — 001.001 — 175
▼B
A.5.6.Tilstandsovergangsdiagram
NOTEProtokollen er beskrevet i Figur A.1 i form af et tilstands-
overgangsdiagram. Diagrammet er kun retningsgivende: i
tilfælde af en konflikt mellem diagrammet og tilstandstabel-
lerneovenfor,skaldesidstnævntehaveforrang.
FigurA.1
Meddelelsesoverførselsprotokol: Tilstandsovergangsdiagram2000R2082 — DA — 15.06.2002 — 001.001 — 176
▼B
ANNEKSB (Retningsgivende)
MEDDELELSESTOPPROTOKOL
B.1. Introduktion
Dette Anneks definerer Meddelelsestopprotokollen, en minimal trans-
portprotokol, som skal bruges til applikationer såsom OLDI.
B.2. Implementeret Tjeneste
B.2.1. Meddelelsestopprotokollen svarer til en delmængde af Transporttjene-
sten i Forbindelsestilstand, som defineret i ISO/IEC 8072
[Henvisning 11], omfattende de følgende servicegrundprocedurer.
T-Connect: etablerer en transportforbindelse for en applikation
T-Data:overfører ASCII-data
T-Disconnect: afslutter en applikations transportforbindelse
B.2.2. Tjenesten understøtter ikke multipleksing, fejlgenoprettelse eller
segmentering og gensamling.
B.3. Antaget Tjeneste
Protokollen 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. Protokolspecifikation
B.4.1.Etablering afForbindelse
Grundproceduren T-Connect skal implementeres ved brug af tjene-
sten 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).
Anbefalinger
1. Idetsidstnævntetilfældeovenforbørnetværksforbindelsengenop-
startes før brug. Grundproceduren N-Connect kan udsendes igen
automatisk, hvis der ikke er modtaget nogen reaktion inden for et
bestemttidsrum.
2. Hvis dette automatiske, gentagne forsøg implementeres, bør
gentagneforsøgprøvestilnærmelsesvishvert15.sekund.
B.4.2.UndgåelseafRedundante Netværksforbindelser
Hvis 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ærksetablerings-
forsøg afvises eller frigives ved at reagere med en grundprocedure
N-Disconnect-Request primitive, kun når begge de følgende betin-
gelser 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 indkod-
ning 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>'88'H).
B.4.3.Frigivelse afForbindelse
B.4.3.1. Frigivelse af Forbindelse skal anvende tjenestegrundprocedurerne N-
Disconnect og N-Reset for den underliggende netværkstjeneste.2000R2082 — DA — 15.06.2002 — 001.001 — 177
▼B
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ærks-
forbindelsen alternativt ikke frigives eksplicit.
Anbefaling I det sidstnævnte tilfælde ovenfor bør netværksforbin-
delsen 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 etab-
leret transportforbindelse:
— N-Disconnect-Indication;
— N-Reset-Indication.
B.4.4.Dataoverførsel
B.4.4.1. Grundproceduren T-Data skal implementeres ved brug af grundproce-
duren 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ærks-
tjenesten.
B.4.4.2. TPDUen skal have det følgende format, transmitteret fra venstre mod
højre, hvorved meddelelsesstrukturen defineret i A.4.10.1 skal
indsættes i felterne data(1), data(2)…data(n).
STX LENG ADEST DEST AEMM EMM data(1) ADRdata(2)…da-
ta(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
NOTER
1. Denne top er defineret således, at den er identisk med den, som
anvendes i INTERCAUTRA-proceduren defineret for ACT-medde-
lelsesudveksling 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
svarerfeltet »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 Eurocontrolstan-
darddokuments 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 4 105 oktetter.
B.4.4.5. En overensstemmende implementering skal forhindre sammenkæd-
ning af multiple TSDUer til en enkelt NSDU.
B.4.4.6. En overensstemmende implementering skal forhindre segmentering af
en enkelt TSDU til multiple NSDUer.2000R2082 — DA — 15.06.2002 — 001.001 — 178
▼B
ANNEKSC (Retningsgivende)
NETVÆRKSPROTOKOL
C.1. Introduktion
Dette 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 defi-
neret i versioner af [Henvisning 1] fra 1980-udgaven og senere.
C.2. Tilvejebragt Tjeneste
C.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ærkstjene-
stens (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 bestem-
melser, 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 Tjeneste
Protokollen antager tilvejebringelsen af en OSI-Datalinktjeneste,
såsom den der tilbydes ved ISO/IEC 7776 (LAPB) [Henvisning 6].
C.4. NSAP-Adressering
C.4.1.Introduktion
C.4.1.1. Strukturen af NSAP-adresserne følger den, der er defineret i ISO/IEC
8348, Anneks A, [Henvisning 10], som vist nedenfor.
C.4.1.2. Komponenterne i NSAP-adressen er defineret nedenfor:
IDP:: Indledende Domænedel (Initial Domain Part), omfattende
AFI- og IDI-felterne
AFI:: Autoritet- og Formatidentifikator (Authority and Format
Identifier), og
IDI:: Indledende Domæneidentifikator (Initial Domain Identifier)
DSP:: DomænespecifikDel (Domain Specific Part)
C.4.2.NSAP-Adressestruktur
C.4.2.1. Med henblik på dette Eurocontrolstandarddokument skal adressekom-
ponenterne 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.2000R2082 — DA — 15.06.2002 — 001.001 — 179
▼B
C.4.2.5. Den resulterende NSAP-adressestruktur er illustreret nedenfor.
AFI DSP
48 ATC-enhedsidentifikator ATC-enhedsselektor
C.4.3.Tildeling afATC-Enhedsidentifikatorer og-Selektorer
C.4.3.1. Tildeling af en unikATC-enhedsidentifik ator 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 udarbej-
delsen af denne standard er vist i Anneks G.
C.5. Protokolspecifikation
C.5.1.Oversigt
Protokollen 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 defi-
neret i ISO/IEC 8878 [Henvisning 12], sendes der kun de kaldte
og de kaldende NSAP-adresser (og kun i den form, som er defi-
neret i in C.4.2) i CALL REQUEST-pakken;
— Brugerdata-feltet anvendes ikke i pakkerne CALL ACCEPTED,
CALL CONNECTED, CLEAR REQUEST eller CLEAR INDI-
CATION;
— de alternative procedurer til etablering og frigivelse af netværks-
forbindelser bruges ikke;
— bekræftelse af modtagelse ved anvendelse af D-bitten understøttes
ikke.
NOTEDeførstetreafdissebegrænsningersikrer,atalinformation,
som vil blive overført mellem de to DTE, vil respektere
begrænsningerneafBrugerdata-feltet iX.25(1980)PLP.
C.5.2.Adresseindkodning
De 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.IndkodningafBrugerdatafeltet
C.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.
Tabel1
Indkodning af Brugerdatafelt
FeltbeskrivelseSemi-Oktet af Høj
OrdenSemi-Oktet af Lav
Orden
Oktet 0: Protokolidentitet bin(1000) bin(0100)
Oktet 1: Meddelelseskodetype bin(0010) bin(0000)
Oktet 2: Meddelelseskodeværdi (N CR) bin(0000) bin(0001)Oktet 3: Parametertype = Kaldt NSAP bin(1100) bin(1001)
Oktet 4: Parameterlængde bin(0000) bin(0110)2000R2082 — DA — 15.06.2002 — 001.001 — 180
▼B
FeltbeskrivelseSemi-Oktet af Høj
OrdenSemi-Oktet af Lav
Orden
Oktet 5: Parameterværdi (1. oktet) = AFI-
værdibin(0100) bin(1000)
Oktet 6: Parameterværdi (2. oktet) = ATC-
enhedsidentifikatorciffer af høj orden ciffer af lav orden
Oktet 7: Parameterværdi (3. oktet) = ATC-
enhedsselektorciffer af høj orden ciffer af lav orden
Oktet 8: Parametertype = Kaldende NSAP bin(1100) bin(1011)
Oktet 9: Parameterlængde bin(0000) bin(0110)
Oktet 10: Parameterværdi (1. oktet) = AFI-
værdibin(0100) bin(1000)
Oktet 11: Parameterværdi (2. oktet) = ATC-
enhedsidentifikatorciffer af høj orden ciffer af lav orden
Oktet 12: Parameterværdi (3. oktet) = ATC-
enhedsselektorciffer af høj orden ciffer af lav orden
Oktet 13: Reserveret til fremtidig brug bin(0000) bin(0000)
Oktet 14: Reserveret til fremtidig brug bin(0000) bin(0000)
Oktet 15: Reserveret til fremtidig brug bin(0000) bin(0000)
C.5.3.2. Andre parametre beskrevet i ISO/IEC 8878 [Henvisning 12] skal ikke
anvendes.
C.5.4.BehandlingafAdresseriINCOMINGCALL-Pakker
C.5.4.1. DTE-Adresser
Den kaldende DTE-adresse i en INCOMING CALL-pakke skal vali-
deres i forhold til en lokal liste over gyldige, fjerne DTE-adresser for
systemet. Hvis der registreres en gyldig adresse, skal opkaldet
frigives.
NOTER
1. 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-
adresserforsystemet.
2. Under nogle omstændigheder kan DTE-adressen for en enhed
have forskellig værdi og/eller længde, når enheden fungerer som
detkaldendeeller detkaldte system.Derforskaldertildeles dette
emne særlig opmærksomhed, når DTE-adressevalideringsfunktio-
naliteten specificeres ellerimplementeres
C.5.4.2. NSAP-Adresser
Den 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-adresserforsystemet.
C.5.5.Dataoverførsel
C.5.5.1. Som beskrevet i ISO/IEC 8878, Anneks A.5.3, [Henvisning 12], over-
føres NSDUer i Brugerdatafeltet i en DATA-pakke.
NOTESomenkonsekvenserdetforbudtattransmitteremereendén
brugermeddelelse, såsom en OLDI-meddelelse, per X.25-
pakkeellerM-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)].2000R2082 — DA — 15.06.2002 — 001.001 — 181
▼B
C.5.5.3. Ved modtagelse skal Brugerdatafelterne i en Flere-bit-sekvens samles
igen for at danne den modtagede NSDU.2000R2082 — DA — 15.06.2002 — 001.001 — 182
▼B
ANNEKSD (Retningsgivende)
PROFIL-SPECIFIKKE PICS-PROFORMAER
D.1. Introduktion
D.1.1. Udbyderen af en protokolimplementering, der påstås at være i over-
ensstemmelse med specifikationerne i Annekserne A til C, skal
fuldstændiggøre de følgende PICS-proformaer.
NOTEFrigivelseafophavsretforPICS-proformaer:brugereafdette
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 fuld-
stændigePICS.
D.1.2. En fuldstændig PICS-proforma er PICSen for den pågældende imple-
mentering. 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 risi-
koen 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 implementerin-
gens 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å samar-
bejde 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 imple-
menteringen kan vurderes i forhold til.
D.2. Instruktioner til at Fuldstændiggøre PICS-Proformaerne
D.2.1.GenerelStrukturafPICS-Proformaerne
D.2.1.1. Implementeringsidentifikationen ( Implementation Identification )o g
Protokoloversigten ( Protocol Summary ) er den første del af hver
PICS-proforma og skal som angivet fuldstændiggøres med den infor-
mation, 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 emnehenvis-
ning 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 specifi-
cerer 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:seogsåD.2.4nedenfor.
2. En udbyder kan også tilvejebringe eller kan kræves at tilveje-
bringe videre information kategoriseret som enten Yderligere
Information eller Undtagelsesinformation. Når den er til stede
skalenhver slagsvidereinformation tilvejebringes ienyderligere
underklausul af emner med mærket A<i> eller X<i> respektivt
medhenblikpåkrydshenvisning,hvor<i>erenhvilkensomhelst
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 betegnes2000R2082 — DA — 15.06.2002 — 001.001 — 183
▼B
som den pågældende implementerings Meddelelse vedrørende Over-
ensstemmelse med hensyn til Implementering af Protokoller.
NOTEHvorenimplementeringeristandtilatblivekonfigureretpå
mere end én måde, kan en enkelt PICS være i stand til at
beskrive alle sådanne konfigurationer. Imidlertid har udby-
deren muligheden for at tilvejebringe mere end én PICS,
som hver især dækker en vis delmængde af implementerin-
gens konfigurationsegenskaber i tilfælde af, at dette udgør
enlettere ogmeretydelig præsentationafinformationen.
D.2.2.YderligereInformation
Emner i Yderligere Information tillader, at en udbyder kan tilveje-
bringe videre information, som er tiltænkt at medvirke til tolkningen
af PICSen.
NOTER
1. 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 implemente-
ringerafdenneprotokol.
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 iemnerneiUndtagelsesinformation.
D.2.3.Undtagelsesinformation
D.2.3.1. Det kan lejlighedsvis ske, at en udbyder ønsker at besvare et emne
med en obligatoriskeller forbudt status (efter at en hvilk en 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øttel-
seskolonnen til dette: i stedet skal udbyderen skrive det manglendesvar ind i Understøttelseskolonnen, sammen med en X<i> 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.
NOTEEnmuligårsagtildenovenforbeskrevnesituationer,atderi
standarden er blevet rapporteret en defekt, for hvilken en
korrektion forventes at ændre det krav, som ikke er opfyldt
vedimplementeringen.
D.2.4.Betingede Emner
D.2.4.1. Individuelle betingede emner er angivet ved hjælp af et betinget
symbol i form af »<emne>: 
« i Statuskolonnen, »<emne>« er en
henvisning til et emne, som forekommer i tabellens første kolonne
for et vist andet emne, og »
« er et statussymbol, M, O, O. <n>
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 under-
støttesellerej.
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 »
«: 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 ( NotApplicable )
(NA) skal markeres.
D.2.4.3. Hvert emne, hvis henvisning bruges i et betinget symbol, er angivet
ved en stjerne i Emne-kolonnen.2000R2082 — DA — 15.06.2002 — 001.001 — 184
▼B
D.3. PICS-Proforma for Meddelelsesoverførselsprotokollen
D.3.1.ForkortelserogSpecielle Symboler
D.3.1.1. Statussymboler
M: Obligatorisk( Mandatory )
O: Valgfri (Optional)
D.3.1.2. Emnehenvisninger
Emner 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.
— MTsy, MTop, MTst, MTor meddelelsestyper
— MAE, MAR, MCI, MDT,
MAVprocedurer
— MEsu, MEsd, MEhb, MEty indkodninger
— MNmsg meddelelsesstørrelse— Ts, Tr timere
D.3.2.Identifikation
2000R2082 — DA — 15.06.2002 — 001.001 — 185
▼B
D.3.3.Protokolimplementering
D.4. PICS-Proforma for Meddelelsestopprotokollen
D.4.1.ForkortelserogSpecielle Symboler
D.4.1.1. Statussymboler
M obligatorisk( mandatory )
O valgfri ( optional)
O.<n> valgfri, men understøttelse af mindst én i gruppen af
muligheder, der er mærket med det samme tal <n>, er
påkrævet
X forbudt ( prohibited )
<emne>: symbol for betinget emne, afhængig af den understøt-
telse, der er markeret for <emne> (se D.2.4)
D.4.1.2. Forkortelser
NA ikke gyldig ( notapplicable )2000R2082 — DA — 15.06.2002 — 001.001 — 186
▼B
D.4.1.3. Emnehenvisninger
Emner 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.
— IHC1, IHC2, IHC3, IHC4,
IHCCetablering af forbindelse
— IHR1, IHR2 frigivelse af forbindelse
— IHT1, IHTx dataoverførsel
— Tcr timer
D.4.2.Identifikation
2000R2082 — DA — 15.06.2002 — 001.001 — 187
▼B
D.4.3.Protokolimplementering
D.5. PICS-Proforma for Netværksprotokollen
D.5.1.ForkortelserogSpecielle Symboler
D.5.1.1. Statussymboler
M obligatorisk( mandatory )
O valgfri (optional)
D.5.1.2. Emnehenvisninger
Emner i PICS-proformaen identificeres ved hjælp af mnemotekniske
emnehenvisninger. PICS-emner, som 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.
— SNDCP1 protokol ID-felt
— NCRdae, NCRgae, NCCx,
NDRxparametre i protokolmeddelelser2000R2082 — DA — 15.06.2002 — 001.001 — 188
▼B
— NCD1, NCD2, NCN1, NCN2 validering af adresser
— NDT dataoverførsel
D.5.2.Identifikation
D.5.3.Protokolimplementering
2000R2082 — DA — 15.06.2002 — 001.001 — 189
▼B
ANNEKSE (Retningsgivende)
PROFILKRAVLISTE
E.1. Introduktion
E.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.
NOTEProformaerneidetteAnnekserbaseretpådeproformaer,der
følgermeddehenviste, grundlæggendestandarder.
E.1.2. En overensstemmende implementering skal tilfredsstille de obligato-
riske overensstemmelseskrav i de basisstandarder, som der henvises
til i denne profil.
E.2. Funktionen af PRLen og PICS-Proformaerne
Dette 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 tabel-
form for PRLen og PICS-proformaerne er at tilvejebringe enkontrolliste 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 ækvi-
valent) og ISO/IEC TR 10000-1 [Henvisning 2]
— En profil kombinerer og udvælger valgene for adskillige basis-
standarder for at udføre en specifikinformationsbehandlende
funktion. Hver basisstandard har en PICS-proforma, som oplister
standardens krav. PRLen omfatter den delmængde af basisstandar-
dens 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 over-
ensstemmelse 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 State-
ment).
— 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 anskaffel-
sesfremgangsmå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 krav-
specifikationen 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 admini-
strationer kontrol.
— Integration af ned-ad-hylden-produkter ind i en profilimple-
mentering i et hvilket som helst af de foregående tilfælde:
udbyderen af et produkt bør pålægges at tilvejebringe de2000R2082 — DA — 15.06.2002 — 001.001 — 190
▼B
PICS-proformaer, som er relevante for produktet, fuldstændig-
gjort 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 doku-
mentationen 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. Notation
E.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 udelukket
NOTER1. Der kan bruges kombinationer af to karakterer, i hvilket tilfælde
den første karakter henviser til den statiske status (implemente-
ring) og den anden til den dynamiske (brug); således betyder
»mo«»obligatorisk med hensyn til at blive implementeret, valgfri
medhensyntilatblive brugt«.
2. Notationen »o.<n>« bruges til at vise en mængde af valgbare
muligheder (dvs. at der skal implementeres mindst én i mængden)
meddensammeidentifikator n.
3. Enfacilitetmarkeretmed»x«kanikkedestomindreudgøreendel
af en implementering, så længe som den ikke bruges, når imple-
menteringenfungererioverensstemmelsemedprofilen.
4. Brugaftrækmarkeretmed»x«villekrævebilateralaftale.Idette
tilfælde bør trækkenes status revideres, idet de kan være af inte-
resseforandreimplementeringer.
E.3.2. Der anvendes den følgende prædikatnotation:
<prædikat>:
introducerer en gruppe af emner, som alle er betingede af <prædikat>
(størrelsen af gruppen vises af layoutet).
<prædikat>:introducerer et enkelt emne, som er betinget af <prædikat>.
NOTEIbeggetilfældekanprædikatetværeenprofilfacilitetsidentif-
kator eller en boolsk kombination af prædikater (» ¬«e r
symboletforlogisknegation).
E.3.3. Basisstandardkrav er vist ved brug af de ækvivalente notationer
skrevet med versaler (dvs. M, O, O.<n>, X).
E.4. Instruktioner til at Fuldstændiggøre PICS-Proformaerne
E.4.1. For at tilvejebringe profilen ICS skal PICS-proformaerne for de
henviste basisstandarder være fuldstændiggjort sammen med de yder-
ligere 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 besva-
relse 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 undtagelses-
information ved at indføre en henvisning X<i>, hvor <i> er en
enestående identifkator, til en medfølgende logisk begrundelse for
den manglende overensstemmelse.2000R2082 — DA — 15.06.2002 — 001.001 — 191
▼B
NOTEEn mulig årsag til en sådan undtagelse er overensstemmelse
med en verserende defektrapport med hensyn til tilvejebrin-
gelsen af profilen; hvis defektrapporten accepteres, vil
implementeringen dernæstblive overensstemmende.
E.5. Henvisninger
E.5.1. Denne profil henviser til de følgende protokolspecifikationer:
— Meddelelsesoverførselsprotokol (Anneks A i dette Eurocontrol-
standarddokument);
— Meddelelsestopprotokol (Anneks B i dette Eurocontrolstandarddo-
kument);
— 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 Overensstemmelse
E.6.1.OversigtoverOverensstemmelse
2000R2082 — DA — 15.06.2002 — 001.001 — 192
▼B
E.6.2.DynamiskeKravmedhensyntil Overensstemmelse
E.7. Krav til Øvre Lag
Tabel3
Meddelelsesoverførselsprotokol
BasisstandardtrækProfiltræk
EmneMeddelelsesoverførselspro-
tokolHenvisninger Status Henvisninger Status
MTst — statusmeddelelser A.4.2 O ox
MTor — operatormeddelelse A.4.2 O ox
E.8. Krav til Nedre lag
E.8.1.KravtilTransportlag
Tabel4
Meddelelsestopprotokol
BasisstandardtrækProfiltræk
Emne Meddelelsestopprotokol Henvisninger Status Henvisninger Status
IHTx Brug af felterne
ADEST, DEST,
AEMM, EMM og
ADR med andre
værdier end '40'HB.4.4 O ox
E.8.2.KravtilNetværkslag
De PRLer, der er angivet i dette afsnit, er baseret på PICS-profor-
maen 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.2000R2082 — DA — 15.06.2002 — 001.001 — 193
▼B
E.8.2.1. Generelle Karakteristikker for DTE
Tabel5
Generelle Karakteristikker for DTE
BasisstandardtrækProfiltræk
EmneGenerelle Karakteristikker
for DTEHenvisninger Status Henvisninger Status
Understøttet Tjeneste:
Vs — virtuelt opkald O.1 m
Vp — permanent virtuelt
kredsløbO.1 x
Understøttede miljøer: 3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2Ec/8 — DTE/DCE(1988) O.2 6.3.2 o.2
Ec/4 — DTE/DCE(1984) O.2 6.3.2 o.2
Ec/0 — DTE/DCE(1980) O.2 6.3.2 o.2
Et/t — DTE/DTE i fast
funktion som DTEO.2 6.3.2 o.2
Et/c — DTE/DTE i fast
funktion som DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE med
dynamiskfunk tionsse-
lektion4.5 Vs: O.2 x
Understøttet pakkese-
kvensnummerering:
M8 — Modulo 8 13.2, 12.1.1,
Tabel 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Tabel 3O.3 x
Henvisningsnummer
for understøttet, valgfri
brugerfacilitet for
alternativ tildeling af
LogiskKanalidentifi-
kator:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
RNa — uden reversion til
brug af logisk
kanalomfang13.29.2.1 Et:O
¬Et:Xx
RNb — med mulig rever-
sion til brug af
logiskk analomfang13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Procedurer, Pakketyper og Pakkeformater
Tabel6
Pakkelagsfunktioner, der er uafhængige af Logiske Kanaler
BasisstandardtrækProfiltræk
EmnePakkelagsfunktioner, der er
uafhængige af Logiske
KanalerHenvisninger Status Henvisninger Status
Understøttes de
følgende pakkelags-
funktioner:
Z2s At sende diagnose-
pakke12.7, Tabel 24 Et:O
¬Et:Xx2000R2082 — DA — 15.06.2002 — 001.001 — 194
▼B
BasisstandardtrækProfiltræk
EmnePakkelagsfunktioner, der er
uafhængige af Logiske
KanalerHenvisninger Status Henvisninger Status
Z4i At initiere On-line
Facilitetsregistrering:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— send REGISTRA-
TION REQUEST12.9.1
— modtag REGI-
STRATION CONFIR-
MATION12.9.2, Tabel 10
Z4r At reagere på On-line
Facilitetsregistrering:13.1, 13.1.1.1,
13.1.1.4Et:O –
— modtag REGI-
STRATION
REQUEST12.9.1
— send REGISTRA-
TION CONFIRMA-
TION12.9.2, Tabel 10
Tabel7
Opkaldsstruktur
BasisstandardtrækProfiltræk
Emne Opkaldsstruktur Henvisninger Status Henvisninger Status
Understøttes udgående
Virtuelle Opkald:5.2.1, 5.2.5,
Tabel 33
S1a — Fast Select, ingen
indskrænkning med
hensyn til reaktion?5.2.4, 13.16 O x
S1b — Fast Select med
indskrænket reaktion?13.16 O x
S1c — non-Fast Select? 5.2.4 O m
SP1b CALL REQUEST,
grundlæggende format12.2.3.1 S1c:M
S1ab: O.4m
SP1e Send CALL
REQUEST, udvidet
format12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b Modtag CALL
CONNECTED, grund-
læggende format12.2.4.1 S1ac:M m
SP2e modtag CALL
CONNECTED,
udvidet format12.2.4.1,
12.2.4.2S1a:M –
Understøttes alternativ
adressering for
udgående Virtuelle
Opkald:13.28
— ved brug af A = 1
og forøget Adresse-
blokformat?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— ved brug af Kaldt
Adresseforlængelsesfa-
cilitet?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Understøttes indkom-
mende Virtuelle
Opkald:5.2.2, 5.2.5,
Tabel 33
S2a — Fast Select med
accept mulig?5.2.3, 13.17 O –2000R2082 — DA — 15.06.2002 — 001.001 — 195
▼B
BasisstandardtrækProfiltræk
Emne Opkaldsstruktur Henvisninger Status Henvisninger Status
S2b — Fast Select, altid
frigivet?13.17 O m
S2c — non-Fast Select
med accept mulig?5.2.3 O m
S2d — non-Fast Select,
altid frigivet?5.2.3 O x
SP3b modtag INCOMING
CALL, grundlæggende
format12.2.3.1 S2:M m
SP3e modtag INCOMING
CALL, udvidet format12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b send CALL
ACCEPTED, grund-
læggende format12.2.4.1 S2c:M
S2axc:
O.5m
SP4e send CALL
ACCEPTED, udvidet
format12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
Understøttes D-bit
negotiering:
DN1 — for udgående Virtu-
elle Opkald6.3 S1ac:O m
DN2 — for indkommende
Virtuelle Opkald6.3 S1ac:O m
NOTE D-bitten skal altid negotieres til 0.
Tabel8
Opkaldsfrigivelse
BasisstandardtrækProfiltræk
Emne Opkaldsfrigivelse Henvisninger Status Henvisninger Status
Understøttes opkalds-
frigivelse for:5.5.4, Tabel 33
C1 — reaktion til angi-
velse af frigivelse5.5.2 O m
C2a — afbrydelse af et
forsøg på udgående
Virtuelt Opkald?5.4, 5.5.1, 5.5.3 S1:O o
C2b — afvisning af et
indkommende Virtuelt
Opkald?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd:
Om
C2c — skabelse af frigi-
velse af et etableret
Virtuelt Opkald?5.5.1, 5.5.3 O o
CP1b modtag CLEAR INDI-
CATION, grundlæg-
gende format12.2.5.1 Cany:M m
CP1e modtag CLEAR INDI-
CATION, udvidet
format12.2.5.1,
12.2.5.2Cany:M –
CP2b send CLEAR
CONFIRMATION,
grundlæggende format12.2.6.1 C1:M m
CP2e send CLEAR
CONFIRMATION,
udvidet format12.2.6.1,
12.2.6.2C1rn:M x2000R2082 — DA — 15.06.2002 — 001.001 — 196
▼B
BasisstandardtrækProfiltræk
Emne Opkaldsfrigivelse Henvisninger Status Henvisninger Status
CP3b send CLEAR
REQUEST, grundlæg-
gende format12.2.5.1 C2a:M
C2bcxa:
O.6m
CP3e send CLEAR
REQUEST, udvidet
format12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b modtag CLEAR
CONFIRMATION,
grundlæggende format12.2.6.1 C2:M m
CP4e modtag CLEAR
CONFIRMATION,
udvidet format12.2.6.1,
12.2.6.2C2rnci:M –
Tabel9
Genstart af Logiske Kanaler
BasisstandardtrækProfiltræk
Emne Genstart af Logiske Kanaler Henvisninger Status Henvisninger Status
Understøttes genstart: 8, 8.4, Tabel 34
RSi — som initiator? 8.1, 8.3 O mm
send RESET
REQUEST12.5.1
modtag RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.1
RSr — som responder? 8.2 O mm
modtag RESET INDI-
CATION12.5.1
send RESET CONFIR-
MATION12.5.2
Tabel10
Fejlprocedurer
BasisstandardtrækProfiltræk
EmneFejlprocedurer
(Virtuel Opkaldstjeneste)Henvisninger Status Henvisninger Status
Er ERROR-C
procedure:5.2.1, 5.4, 8.1,
Tabel 33
W1a — at frigive det Virtu-
elle Opkald?O.7 m
W1b — at genstarte pakke-
laget?O.7 x
Er ERROR-R proce-
duren for virtuelle
opkald:6.3, 6.4, 6.6,
6.8.1, 6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1, 13.4.1,
Tabeller 34-36
W2sc — at genstarte pakke-
laget?O.8 x2000R2082 — DA — 15.06.2002 — 001.001 — 197
▼B
Tabel11
Afbrydelsesoverførsel
BasisstandardtrækProfiltræk
Emne Afbrydelsesoverførsel Henvisninger Status Henvisninger Status
Is Understøttes udsen-
delse af afbrydelser?6.8, 6.8.1, 6.8.3,
Tabel 35Oo x
— send INTERRUPT
REQUEST12.3.2
— modtag INTER-
RUPT CONFIRMA-
TION12.3.3
Ir Understøttes modta-
gelse af afbrydelser?6.8, 6.8.2, 6.8.3
Tabel 35O–
— modtag INTER-
RUPT INDICATION12.3.2
— send INTERRUPT
CONFIRMATION12.3.3
Tabel12
Udsendelse af Data
BasisstandardtrækProfiltræk
Emne Udsendelse af Data Henvisninger Status Henvisninger Status
DS1 Understøttes udsen-
delse af DATA-
pakker?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Understøttes det
følgende:
DS2 — send-window rota-
tion ved modtagelse afopdaterede P(R)-
værdier?7.1, 7.1.2, 7.1.3 O mm
DS4a — at sende M = 0 i
DATA-pakker?6.4, 6.5, 6.7 M mo.9
DS4b — at sende M = 1 i
DATA-pakker?6.4, 6.5, 6.7 O mo.9
DS5a — at sende Q = 0 i
DATA-pakker?6.6 O.10 mm
DS5b — at sende Q = 1 i
DATA-pakker?6.6 O.10 ox
DS6 — at reagere på
anmodninger om
gentransmission af
pakker (modtagede
REJECT-pakker)?13.4.2 12.8 Et:O –
— Window Rotation
Timer procedure:
DS7a — ERROR-R-handling
ved udløb11.2.1(a) O ox
DS7b — gentransmission af
pakke ved udløb11.2.1(b) Et:O
¬Et:Xox
DS8 — frasortering af for
lange flowkontrol-
pakker (i stedet for
ERROR-R)?Tabel 36, Note 2 O ox2000R2082 — DA — 15.06.2002 — 001.001 — 198
▼B
Tabel13
Modtagelse af Data
BasisstandardtrækProfiltræk
Emne Modtagelse af Data Henvisninger Status Henvisninger Status
DR1 Understøttes modta-
gelse af DATA-
pakker?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Understøttes det
følgende:
DR2 — modtag window
rotation ved at udsen-
delse af opdaterede
P(R)-værdier?7.1.2, 7.1.3 O mm
DR3 — flow-kontrol ved at
sende RECEIVE NOT
READY og RECEIVE
READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — at modtage M = 1 i
DATA-pakker?6.4, 6.5, 6.7 O mm
DR5a — at modtage Q = 0 i
DATA-pakker?6.6 O.11 mm
DR5b — at modtage Q = 1 i
DATA-pakker?6.6 O.11 –
DR6 — at anmode om
gentransmission af
pakker ved at sende
REJECT-pakker?13.4.1, 12.8 O ox
— genoprettelse fra
modtagelse af DATA-
pakker indeholdende
ugyldig P(S), ved:
DR7a — ERROR-R-hand-
ling?11.3(a) O.12 mm
DR7b — at anmode om
gentransmission af
pakke?11.3(b) O.12 ox
DR7c — at ignorere pakken
og vente på en korrekt
gentransmitteret
pakke?11.3(c) O.12 ox
— genoprettelse fra
modtagelse af DATA-
pakker med ugyldigt
Brugerdatafelt, ved:
DR8a — ERROR-R-hand-
ling?11.3(a) O.13 mm
DR8b — at anmode om
gentransmission af
pakke?11.3(b) O.13 ox
DR8c — at ignorere pakken
og vente på en korrekt
gentransmitteret
pakke?11.3(c) O.13 ox
DR9 — Window Status
Transmission Timer
procedure?11.2.2 O ox2000R2082 — DA — 15.06.2002 — 001.001 — 199
▼B
Tabel14
Bekræftelse af Levering
BasisstandardtrækProfiltræk
Emne Bekræftelse af Levering Henvisninger Status Henvisninger Status
DC Understøttes Bekræf-
telse af Levering?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Diverse Trækog Valgmuligheder
Tabel15
Værdier af Årsag og Diagnostiske Koder
BasisstandardtrækProfiltræk
EmneVærdier af Årsag og Diag-
nostiske KoderHenvisninger Status Henvisninger Status
I sendte RESTART
REQUEST-pakker:12.6.1.1,
12.6.1.2,
Tabeller 24-25
Y1d — Årsag = 128,
private diagnostiske
koderO.14 ox
I modtagede
RESTART INDICA-
TION-pakker:12.6.1.1, Tabel
9, 12.6.1.2
Y2b — Årsag ikke 0 eller
128, en hvilken som
helst diagnostiskk ode-
værdiEC:M
¬EC:Om
I sendte CLEAR
REQUEST-pakker:12.2.3.1.1,
12.2.3.1.2,
Tabeller 24-25
Y3d — Årsag = 128,
private diagnostiske
koderO.15 ox
I modtagede CLEAR
INDICATION-pakker:12.2.3.1.1, Tabel
7 12.2.3.1.2,
Y4b — Årsag ikke 0 eller
128, en hvilken som
helst diagnostiskk ode-
værdiEC:M
¬EC:Om
I sendte RESET
REQUEST-pakker:12.5.1.1,
12.5.1.2,
Tabeller 24-25
Y5d — Årsag = 128,
private diagnostiske
koderO.16 ox
I modtagede RESET
INDICATION-pakker:12.5.1.1, Tabel
8, 12.5.1.2
Y6b — Årsag ikke 0 eller
128, en hvilken som
helst diagnostiskk ode-
værdiEC:M
¬EC:Om2000R2082 — DA — 15.06.2002 — 001.001 — 200
▼B
E.8.2.4. Faciliteter
Tabel16
Faciliteter Sendt i CALL REQUEST-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Sendt i CALL
REQUEST-PakkerHenvisninger Status Henvisninger Status
FS1pi Flow-Kontrolparame-
ternegotiering, pakke-
størrelse13.12, 15.2.2.1.1 O x
FS1wi Flow-Kontrolparame-
ternegotiering, vindu-
esstørrelse13.12, 15.2.2.1.2 O x
FS2ib Grundlæggende
Gennemløbsklassene-
gotiering13.13,
15.2.2.2.1, Tabel
20aOx
FS2ie Udvidet Gennemløbs-
klassenegotiering13.13,
15.2.2.2.2, Tabel
20bOx
FS3b Lukket Brugergruppe-
selektion, grundlæg-
gende format13.14.6,
15.2.2.3.1Oo
FS3e Lukket Brugergruppe-
selektion, udvidet
format13.14.6,
15.2.2.3.2Ox
FS4b Lukket Brugergruppe
med Udgående
Adgangsselektion,
grundlæggende format13.14.7,
15.2.2.4.1Ox
FS4e Lukket Brugergruppe
med Udgående
Adgangsselektion,
udvidet format13.14.7,
15.2.2.4.2Ox
FS5 Bilateral, Lukket
Brugergruppeselektion13.15, 15.2.2.5 O x
FS6a Fast Select 13.16, 15.2.2.6 O x
FS6b Omvendt Opkrævning 13.18, 15.2.2.6 O x
FS6c ICRD-Statusselektion 13.25.4.2,
15.2.2.6Ox
FS7i Identifikation af
Netværksbruger13.21, 13.21.3,
15.2.2.7Ox
FS8i Opkrævning af Infor-
mation, anmodning om
tjeneste13.22, 15.2.2.8.1 O x
FS9b RPOA-selektion,
grundlæggende format13.23, 13.23.2,
15.2.2.9.1Ox
FS9e RPOA-selektion,
udvidet format13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Transitforsinkelsesse-
lektion og -Angivelse13.27, 15.2.2.13 O x
FS99i Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS98i Fjerne non-X.25 facili-
teter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS20i Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FS21i Opkaldende Adresse-
forlængelse14.1, 15.3.2.1 x2000R2082 — DA — 15.06.2002 — 001.001 — 201
▼B
BasisstandardtrækProfiltræk
EmneFaciliteter Sendt i CALL
REQUEST-PakkerHenvisninger Status Henvisninger Status
FS22i Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 x
FS23ib Minimal Gennemløbs-
klassenegotiering,
grundlæggende format14.3, 15.3.2.3.1,
Tabel 20aOx
FS23ie Minimal Gennemløbs-
klassenegotiering,
udvidet format14.3, 15.3.2.3.2,
Tabel 20bO
FS24i Ende-til-ende Transit-
forsinkelsesnegotiering14.4, 15.3.2.4 O x
FS25i Udført Datanegotiering 14.7, 15.3.2.7 O x
FS26i Prioritet 14.5, 15.3.2.5 O x
FS27i Beskyttelse 14.6, 15.3.2.6 O x
Tabel17
Faciliteter Sendt i CALL ACCEPT-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Sendt i CALL
ACCEPT-PakkerHenvisninger Status Henvisninger Status
FS1pr Flow-Kontrolparame-
ternegotiering, pakke-
størrelse13.12,
15.2.2.1.1, Tabel
13Ox
FS1wr Flow-Kontrolparame-
ternegotiering, vindu-
esstørrelse13.12,
15.2.2.1.2, Tabel
13Ox
FS2rb Grundlæggende
Gennemløbsklassene-
gotiering13.13,
15.2.2.2.1, Tabel
20aOx
FS2re Udvidet Gennemløbs-
klassenegotiering13.13,
15.2.2.2.2, Tabel
20bOx
FS7r Identifikation af
Netværksbruger13.21, 13.21.3
15.2.2.7Ox
FS8r Opkrævning af Infor-
mation, anmodning om
tjeneste13.22, 15.2.2.8.1 O x
FS10r Kaldt Linieadressemo-
dificeret Underretning13.26, 15.2.2.12 O x
FS99r Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS98r Fjerne non-X.25 facili-
teter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS20r Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FS22r Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 O x
FS24r Ende-til-ende Transit-
forsinkelsesnegotiering14.4, 15.3.2.4 O x
FS25r Udført Datanegotiering 14.7, 15.3.2.7 O x
FS26r Prioritet 14.5, 15.3.2.5 O x
FS27r Beskyttelse 14.6, 15.3.2.6 O x2000R2082 — DA — 15.06.2002 — 001.001 — 202
▼B
Tabel18
Faciliteter Sendt i CLEAR REQUEST-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Sendt i CLEAR
REQUEST-PakkerHenvisninger Status Henvisninger Status
FS10d Kaldt Linieadressemo-
dificeret Underretning13.26, 15.2.2.12 O x
FS13 Opkaldsafvigelsesse-
lektion13.25.2.2,
15.2.2.10Ox
FS99d Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS98d Fjerne non-X.25 facili-
teter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FS20d Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FS22d Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 O x
Tabel19
Faciliteter Modtaget i INCOMING CALL-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
INCOMING CALL-PakkerHenvisninger Status Henvisninger Status
FR1pi Flow-Kontrolparame-
ternegotiering, pakke-
størrelse13.12, 15.2.2.1.1 O x
FR1wi Flow-Kontrolparame-
ternegotiering, vindu-
esstørrelse13.12, 15.2.2.1.2 O x
FR2ib Grundlæggende
Gennemløbsklassene-
gotiering13.13, 15.2.2.2.1
Tabel 20aOx
FR2ie Udvidet Gennemløbs-
klassenegotiering13.13, 15.2.2.2.2
Tabel 20bOx
FR3b Lukket Brugergruppe-
selektion, grundlæg-
gende format13.14.6,
15.2.2.3.1Oo
FR3e Lukket Brugergruppe-
selektion, udvidet
format13.14.6,
15.2.2.3.2Ox
FR4b Lukket Brugergruppe
med Udgående
Adgangsselektion,
grundlæggende format13.4.7,
15.2.2.4.1Ox
FR4e Lukket Brugergruppe
med Udgående
Adgangsselektion,
udvidet format13.4.7,
15.2.2.4.2Ox
FR5 Bilateral Lukket
Brugergruppeselektion13.15, 15.2.2.5 O x
FR6a Fast Select 13.16, 13.17,
15.2.2.6Ox
FR6b Omvendt Opkrævning 13.18, 13.19,
15.2.2.6Ox
FR11 Opkaldsomdirigering
eller Opkaldsafvigel-
sesunderretning13.25.3,
15.2.2.11Ox2000R2082 — DA — 15.06.2002 — 001.001 — 203
▼B
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
INCOMING CALL-PakkerHenvisninger Status Henvisninger Status
FR12i Transitforsinkelsesse-
lektion og –Angivelse13.27, 15.2.2.13 O x
FR99i Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FR20i Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FR21 Kaldende Adressefor-
længelse14.1, 15.3.2.1 x
FR22i Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 x
FR23b Minimal Gennemløbs-
klassenegotiering,
grundlæggende format14.3, 15.3.2.3.1,
Tabel 20aOx
FR23e Minimal Gennemløbs-
klassenegotiering,
udvidet format14.3, 15.3.2.3.2,
Tabel 20bOx
FR24i Ende-til-ende Transit-
forsinkelsesnegotiering14.4, 15.3.2.4 O x
FR25i Udført Datanegotiering 14.7, 15.3.2.7 O x
FR26i Prioritet 14.5, 15.3.2.5 O xFR27i Beskyttelse 14.6, 15.3.2.6 O x
Tabel20
Faciliteter Modtaget i CALL CONNECTED-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
CALL CONNECTED-
PakkerHenvisninger Status Henvisninger Status
FR1pr Flow-Kontrolparame-
ternegotiering, pakke-
størrelse13.12,
15.2.2.1.1, Tabel
14Ox
FR1wr Flow-Kontrolparame-
ternegotiering, vindu-
esstørrelse13.12,
15.2.2.1.2, Tabel
14Ox
FR2rb Grundlæggende
Gennemløbsklassene-
gotiering13.13,
15.2.2.2.1, Tabel
20aOx
FR2re Udvidet Gennemløbs-
klassenegotiering13.13,
15.2.2.2.2, Tabel
20bOx
FR10r Kaldt Linieadressemo-
dificeret Underretning13.26, 15.2.2.12 O x
FR12r Transitforsinkelsesse-
lektion og –Angivelse13.27, 15.2.2.13 O x
FR99r Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FR20r Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FR22r Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 O x
FR24r Ende-til-ende Transit-
forsinkelsesnegotiering14.4, 15.3.2.4 O x2000R2082 — DA — 15.06.2002 — 001.001 — 204
▼B
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
CALL CONNECTED-
PakkerHenvisninger Status Henvisninger Status
FR25r Udført Datanegotiering 14.7, 15.3.2.7 O x
FR26r Prioritet 14.5, 15.3.2.5 O x
FR27r Beskyttelse 14.6, 15.3.2.6 O x
Tabel21
Faciliteter Modtaget i CLEAR INDICATION-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
CLEAR INDICATION-
PakkerHenvisninger Status Henvisninger Status
FR8ad Opkrævning af infor-
mation, monetær enhed13.22, 15.2.2.8.2 O x
FR8bd Opkrævning af infor-
mation, segmentoptæl-
ling13.22, 15.2.2.8.3 O x
FR8cd Opkrævning af infor-
mation, varighed af
opkald13.22, 15.2.2.8.4 O x
FR10d Kaldt Linieadressemo-
dificeret Underretning13.26, 15.2.2.12 O x
FR99d Lokale non-X.25 faci-
liteter, følgende Facili-
tetsmarkør15.1, Tabel 18 O x
FR20d Facilitetsmarkør,
CCITT-specificerede
DTE-faciliteter15.1 O x
FR22d Kaldt Adresseforlæn-
gelse14.2, 15.3.2.2 O x
Tabel22
Faciliteter Modtaget i CLEAR CONFIRMATION-Pakker
BasisstandardtrækProfiltræk
EmneFaciliteter Modtaget i
CLEAR CONFIRMA-
TION-PakkerHenvisninger Status Henvisninger Status
FR8af Opkrævning af infor-
mation, monetær enhed13.22, 15.2.2.8.2 O x
FR8bf Opkrævning af infor-
mation, segmentoptæl-
ling13.22, 15.2.2.8.3 O x
FR8cf Opkrævning af infor-
mation, varighed af
opkald13.22, 15.2.2.8.4 O x2000R2082 — DA — 15.06.2002 — 001.001 — 205
▼B
E.8.2.5. Parameterværdier og -Intervaller
Tabel23
Parameterværdier og -Intervaller
BasisstandardtrækProfiltræk
EmneParameterværdier og -Inter-
vallerHenvisninger Status Henvisninger Status
Hvilke værdier under-
støttes:
V1s — Default pakkestør-
relser (udsendende)?16.2.2.5 16, 32,
64, 128,
256, 512,
1024,
2048,
4096
oktetter6.3.2 Mindst
128 og
256
V1r — Default pakkestør-
relser (modtagende)?16.2.2.5 16, 32,
64, 128,
256, 512,
1024,
2048,
4096
oktetter6.3.2 Mindst
128 og
256
V2s — Default vindues-
størrelser, udsendende?16.2.2.6 ( M8:i
inter-
vallet 1-7)2
V2r — Default vindues-
størrelser, modta-
gende?16.2.2.6 ( M8:i
inter-
vallet 1-7)2
E.8.3.KravtilDatalinklag
De 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.
Tabel24
Datalink-Protokol
BasisstandardtrækProfiltræk
Emne Datalink-protokol Henvisninger Status Henvisninger Status
Lm Multilink-procedure 6 O ox
Lc DTE/DCE-operation 1, 5.1 M mo.1
Lt DTE/DTE-operation 1, 5.1 O mo.1
M8 Grundlæggende
(Modulo 8) operation1, 3, 4.1.1 O.1 mm
M128 Udvidet (Modulo 128)
operation1, 3, 4.1.1 O.1 ox
T4 Timer T4 procedure 5.3.2, 5.6.1 O mm
SPN1 Maksimalt antal (N1)
bits i en I-ramme5.7.3 N1 ≥
1080N1≥
2104
SPkMak simalt antal
udestående rammer (k)5.7.4 1 ≤k≤
7k=7
E.8.4.KravtilFysiske Lag
Se ISO/IEC TR 10609-9, klausul A.4 [Henvisning 8].2000R2082 — DA — 15.06.2002 — 001.001 — 206
▼B
ANNEKSF( Informativt)
METODOLOGI TIL OVERENSSTEMMELSESAFPRØVNING
F.1. Introduktion
F.1.1. Det er vigtigt, at implementeringer af dette ICD er således, at der er
et højt sikkerhedsniveau for indbyrdes operation mellem Flyvekon-
troltjenestecentraler (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 forskel-
lige 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 forbe-
redelse til afprøvning, afprøvning og præsentation af resultater.
F.2. Formål og Omfang
F.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æn-
seflade etableres ved en afprøvningsproces for at validere påstanden.
F.3. Bibliografi
Det følgende dokument er relevant i forhold til afprøvning af imple-
menteringer af dette Eurocontrolstandarddokument:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Part 1 Integration Test Plan Version 1.0, dateret
10. maj 1996 [Henvisning 15].
F.4. Udviklingsmetoder og Praksis
F.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 under-
støttes.
F.4.2. En hvilken som helst implementering bør være genstand for en over-
ensstemmelsesafprøvning som beskrevet nedenfor.
F.5. Afprøvninger
F.5.1.Introduktion
F.5.1.1. For at tilvejebringe sikkerhed i og understøttelse for FDE-Grænse-
flade 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 slut-
systemets 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 over-
ensstemmelse 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 overensstemmelses-
afprø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øvnings-
fø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. Den2000R2082 — DA — 15.06.2002 — 001.001 — 207
▼B
standardiserede afprøvningsfølge er delvist blevet udviklet af Euro-
control.
F.5.1.4. Afprøvningen af det fuldstændige slutsystem tager form af afprøv-
ninger 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øv-
ning valgfri.
F.5.2.AfprøvningafdeNedrelag(Lag1til 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øvningsproce-
durer skal aftales bilateralt mellem samvirkende ATCCer.
F.5.3.AfprøvningafApplikationslaget
En række bilateralt aftalte afprøvninger bør være aftalt og udøvet
mellem samvirkende ATCCer.
F.5.4.Certificering
Resultaterne af afprøvninger bør registreres og aftales mellem de
samvirkende parter.
F.5.5.Notificering
Medlemslande bør sende detaljer vedrørende resultaterne af en
hvilken som helst afprøvning til Eurocontrol.2000R2082 — DA — 15.06.2002 — 001.001 — 208
▼B
ANNEKSG (Informativt)
TILDELING AF ATC-ENHEDSIDENTIFIKATORER
Den 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.
Tabel1
ATC-Enhedsidentifikatorer
ATC-Enheds-Identifikator Indkodning Beskrivelse
00 Reserveret
01 '01'H CATCAS, København
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Bruxelles
05 '05'H GeneriskCAUTRA, Frank rig
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, London
09 '09'H Oslo ATCC
10 '10'H Karlsruhe ATCC
11 '11'H Langen (fremtidigt TyskSystem)
12 '12'H FATMI-system, Tampere
13 '13'H ROVA-system, Rovaniemi14 '14'H VAS, Wien
15 '15'H CFMU Haren
16 '16'H GFMU Brétigny
17 '17'H Geneve ACC/FMP
18 '18'H Zürich ACC/FMP
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milano
23 '23'H Rom
24 '24'H Jersey
25 '25'H Shanwick
26 '26'H Athis-Mons
27 '27'H Reims
28 '28'H Brest
29 '29'H Bordeaux
30 '30'H Aix-en-Provence
31 '31'H Bratislava
32 '32'H Stockholm-Arlanda
33 '33'H Malmö-Sturup
34 '34'H Sundsvall35 '35'H Lissabon
36 '36'H Sevilla
37 '37'H Gran Canaria
38 '38'H Prag2000R2082 — DA — 15.06.2002 — 001.001 — 209
▼B
ATC-Enheds-Identifikator Indkodning Beskrivelse
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H TyskMilitærsystem
42 '42'H TyskMilitærsystem
43 '43'H TyskMilitærsystem
44 '44'H TyskMilitærsystem
45 '45'H TyskMilitærsystem
46 '46'H TyskMilitærsystem
47 '47'H TyskMilitærsystem
48 '48'H TyskMilitærsystem
49 '49'H TyskMilitærsystem
50 '50'H München (fremtidigt TyskSystem)
51 '51'H Zagreb
52 '52'H Hahn Airport, Tyskland
53 '53'H Santa Maria FIR
54 '54'H Ljubljana
55 '55'H BelgiskMilitærsystem
56 '56'H Budapest57 '57'H Warszawa2000R2082 — DA — 15.06.2002 — 001.001 — 210
▼B
ANNEKSH(Informativt)
VEJLEDNING OM PÅLIDELIGHED, TILGÆNGELIGHED OG
SIKKERHED
H.1. Introduktion
Det forventes, at ATC-applikationer såsom OLDI skal gøre brug af
indbyrdes forbundne X.25 netværkog/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 Omfang
H.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ø.
NOTE For 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 fysiskbesk yttede over for
indtrængen, energisvigt og andre ydre trusler, som kan påvirke almin-
delig operation.
H.3. Bibliografi
Det 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 Linie
H.4.1.Pålidelighed
For at øge tjenestepålidelighed skal kabler i fast linie, PSTN, Inte-
grated Services Digital Network(ISDN), følge fysiskforsk ellige
stier og være forbundet til forskellige telekommunikationsoperator-
skiftere (dette skal være specificeret over for
telekommunikationsoperatoren).
H.4.2.Tilgængelighed
H.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.Sikkerhed
H.4.3.1. Når ISDN bruges som backup-medium, bør den kaldte ISDN-termi-
naladaptor (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.2000R2082 — DA — 15.06.2002 — 001.001 — 211
▼B
H.4.4.Konfigurationseksempel
FigurH.1
Konfigurationseksempel med Fast Linie
H.5. Netværksimplementering
H.5.1.Pålidelighed
For 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ængelighed
H.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.Sikkerhed
Inden 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ærk
H.6.1.Pålidelighed
H.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.
NOTE Indbefattelse af en transportstack i profilspecifikationen kan
udvikles i konteksten af en fremtidig standard FDE ICD, Del
2.
H.6.2.Tilgængelighed
Nå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).2000R2082 — DA — 15.06.2002 — 001.001 — 212
▼B
H.6.3.Systemadministration
H.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 datalinkla-
gene 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ørselsprotokol-
lens lag (Anneks A) og kontrollere tilstandsmaskinen for at skelne
mellem en fejl i Meddelelsesoverførselsprotokollen og en applikati-
onsfejl.
H.6.4.Konfigurationseksempel
FigurH.2
Netværkskonfigurationseksempel2000R2082 — DA — 15.06.2002 — 001.001 — 213