2000R2082 — SV — 15.06.2002 — 001.001 — 1
Detta dokument är endast avsett som dokumentationshjälpmedel och institutionerna ansvarar inte för innehållet
►B KOMMISSIONENS FÖRORDNING (EG) nr 2082/2000
av den 6 september 2000
om antagande av Eurocontrol-standarder och om ändring av direktiv 97/15/EG om antagande av
Eurocontrol-standarder och om ändring av rådets direktiv 93/65/EEG
(EGT L 254, 9.10.2000, s. 1)
Ändrad genom:
Officiella tidningen
nr sida datum
►M1Kommissionens förordning (EG) nr 980/2002 av den 4 juni 2002 L 150 38 8.6.2002
▼B
KOMMISSIONENS FÖRORDNING (EG) nr 2082/2000
av den 6 september 2000
om antagande av Eurocontrol-standarder och om ändring av
direktiv 97/15/EG om antagande av Eurocontrol-standarder och
om ändring av rådets direktiv 93/65/EEG
EUROPEISKA GEMENSKAPERNAS KOMMISSION HAR ANTAGIT
DETTA DIREKTIV
med beaktande av Fördraget om upprättandet av Europeiska gemenska-
pen,
med beaktande av rådets direktiv 93/65/EEG av den 19 juli 1993 om
definition och användning av kompatibla tekniska specifikationer vidupphandling av utrustning och system för ledning av lufttrafiken(
1),
särskilt artikel 3 i detta,
med beaktande av kommissionens direktiv 97/15/EG av den 25 mars
1997 om antagande av Eurocontrol-standarder och om ändring avrådets direktiv 93/65/EEG(
2),
och av följande skäl:
1.Genom direktiv 97/15/EG antogs Eurocontrol-standarden för
utbyte on-line av data (OLDI), utgåva 1.0 och Eurocontrol-stan-
darden för utformningen av utbytet av ATS-data (ADEXP),
utgåva 1.0.
2.Eurocontrol har antagit nyare utgåvor av de två ovan nämndastandarderna, OLDI utgåva 2.2 och ADEXP utgåva 2.0 samt enny Eurocontrol-standard kallad Eurocontrol-standarden för utbyteav flygdata — dokument för kontroll av gränssnitt (FDE-ICD).
3.Dessa Eurocontrol-standarder ligger inom tillämpningsområdetför direktiv 93/65/EEG och bidrar till harmoniseringen avmedlemsstaternas nationella system för ledning av lufttrafiken,särskilt vad beträffar överföringen av flygningar mellan kontroll-
centraler för lufttrafik(OLDI), ledningen av lufttrafik flödet
(ADEXP) och kommunikationerna mellan nationella system(FDE-ICD).
4.OLDI utgåva 2.2 och ADEXP utgåva 2.0 ersätter tidigareutgåvor som nu gäller enligt artikel 1 i direktiv 97/15/EG ochdärför måste den artikeln upphävas.
5.Bestämmelserna i detta direktiv är förenliga med yttrandet frånden kommitté som upprättats i enlighet med direktiv 93/65/EEG.
HÄRIGENOM FÖRESKRIVS FÖLJANDE.
Artikel 1
De obligatoriska elementen i Eurocontrol-specifikationerna, som ingår i
följande Eurocontrol-standarder, skall antas, inom ramen för direktiv93/65/EEG eftersom de är nödvändiga för genomförandet av ett integ-
rerat europeiskt system för lufttrafikledning:
— Eurocontrol-standarden för utbyte on-line av data (OLDI), utgåva
2.2 (Eurocontrol-dokument DPS.ET1.ST06-STD). Texten bifogas i
bilaga I till denna förordning.
— Eurocontrol-standarden för utformningen av utbytet av ATS-data
(ADEXP), utgåva 2.0 (Eurocontrol-dokument DPS.ET1.ST09-STD). Texten bifogas i bilaga II till denna förordning.
— Eurocontrol-standarden för utbyte av flygdata — dokument för
kontroll av gränssnitt (FDE-ICD), utgåva 1.0 (Eurocontrol-doku-
ment COM.ET1.ST12-STD). Texten bifogas i bilaga III till dennaförordning.2000R2082 — SV — 15.06.2002 — 001.001 — 2
(1) EGT L 187, 29.7.1993, s. 52.
(2) EGT L 95, 10.4.1997, s. 16.
▼B
Artikel 2
Artikel 1 i direktiv 97/15/EG skall upphöra att gälla.
Artikel 3
Denna förordning träder i kraft den tredje dagen efter det att den har
offentliggjorts i Europeiska gemenskapernas officiella tidning .
Denna förordning är till alla delar bindande och direkt tillämplig i alla
medlemsstater.2000R2082 — SV — 15.06.2002 — 001.001 — 3
▼B
BILAGA I
UTBYTE ON-LINE AV DATA (OLDI)
(EUROCONTROL-DOKUMENT DPS.ET1.ST06-STD)2000R2082 — SV — 15.06.2002 — 001.001 — 4
▼B
INNEHÅLLSFÖRTECKNING
MEDDELANDE OM UPPHOVSMANNARÄTT
FÖRORD1. INLEDNING
1.1. Syfte1.2. Omfattning
2. HÄNVISNINGAR3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
3.1. Definitioner3.2. Symboler och förkortningar
4. ALLMÄNNA KRAV
4.1. Inledning4.2. Systemkrav för behandling av flygdata4.2.1. Flygdatabas4.2.2. Drift i realtid4.2.3. Kapacitet för datakommunikation4.2.4. Funktioner4.2.5. Gränssnitt människa-maskin (HMI)4.2.6. Initiering av meddelanden4.2.7. Mottagande av meddelanden4.3. Uppdatering från övervakningsdata4.4. Registrering av OLDI-data4.4.1. Innehåll4.4.2. Installationer4.5. Tillgänglighet, tillförlitlighet, datasäkerhet och dataintegritet4.5.1. Tillgänglighet4.5.2. Tillförlitlighet4.5.3. Datasäkerhet4.5.4. Dataintegritet4.6. Driftsutvärdering4.6.1. Utvärderingsperiod4.6.2. Operativt startdatum
5. MEDDELANDEKATEGORIER
5.1. Allmänt5.1.1. Syfte5.1.2. Meddelandekategorier5.2. Transaktionstider5.2.1. Villkor för transaktionstider5.3. Klassificering och kategorisering av meddelanden2000R2082 — SV — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Meddelandeklassificering — obligatoriska och kompletterande
5.3.2. Kategorisering av meddelanden
6. GRUNDLÄGGANDE FÖRFARANDEN — OBLIGATORISKA MEDDELANDEN
6.1. Allmänt6.1.1. Kravbeskrivning6.1.2. Genomförande6.2. Förhandsmeddelande — gränsinformation (ABI)
6.2.1. Syfte med ABI-meddelandet
6.2.2. Meddelandeinnehåll6.2.3. Tillämpningsregler6.2.4. Bekräftelse på ett ABI6.2.5. Exempel6.3. Aktiveringsmeddelande (ACT)
6.3.1. Syfte med aktiveringsmeddelandet
6.3.2. Meddelandeinnehåll6.3.3. Tillämpningsregler6.3.4. Bekräftelse av ett ACT6.3.5. Exempel
6.4. Logiskt bekräftelsemeddelande (LAM)
6.4.1. Syfte med LAM-meddelandet6.4.2. Meddelandeinnehåll6.4.3. Tillämpningsregler6.4.4. Bekräftelse av ett LAM6.4.5. Exempel
7. GRUNDLÄGGANDE FÖRFARANDE — KOMPLETTERANDE MEDDELANDEN
7.1. Allmänt
7.1.1. Kravbeskrivning7.1.2. Genomförande7.2. Preliminärt aktiveringsmeddelande (PAC)7.2.1. Syfte med PAC-meddelandet7.2.2. Meddelandeinnehåll
7.2.3. Tillämpningsregler
7.2.4. Bekräftelse av ett PAC7.2.5. Exempel7.3. Ändringsmeddelande (REV)7.3.1. Syfte med ändringsmeddelandet
7.3.2. Meddelandeinnehåll
7.3.3. Tillämpningsregler7.3.4. Bekräftelse av ett REV7.3.5. Exempel2000R2082 — SV — 15.06.2002 — 001.001 — 6
▼B
7.4. Meddelande om upphävande av samordning (MAC)
7.4.1. Syfte med MAC-meddelandet7.4.2. Meddelandeinnehåll
7.4.3. Tillämpningsregler
7.4.4. Bekräftelse av ett MAC7.4.5. Exempel7.5. Meddelande om tilldelning av SSR-kod (COD)
7.5.1. Syfte med COD-meddelandet
7.5.2. Meddelandeinnehåll7.5.3. Tillämpningsregler
7.5.4. Bekräftelse av ett COD
7.5.5. Exempel7.6. Informationsmeddelande (INF)7.6.1. Syfte med INF-meddelandet
7.6.2. Meddelandeinnehåll
7.6.3. Tillämpningsregler7.6.4. Bekräftelse av ett INF
7.6.5. Exempel
8. DIALOGFÖRFARANDEN — SAMORDNING
8.1. Allmänt8.1.1. Inledning
8.1.2. Filtret
8.1.3. Meddelandeföljd8.1.4. Samtidig meddelandehantering8.1.5. Hantering av avslag
8.1.6. Tidsbegränsning av operativt svar
8.1.7. Genomförande8.2. Aktiveringsmeddelande (ACT)
8.2.1. Syfte med ACT-meddelandet
8.2.2. Meddelandeinnehåll8.2.3. Tillämpningsregler
8.2.4. Bekräftelse av ett ACT
8.3. Meddelande med remitterat aktiveringsförslag (RAP)8.3.1. Syfte med RAP-meddelandet8.3.2. Meddelandeinnehåll
8.3.3. Tillämpningsregler
8.3.4. Bekräftelse av ett RAP8.3.5. Operativt svar på ett RAP
8.3.6. Exempel
8.4. Ändringsmeddelande (REV)2000R2082 — SV — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Syfte med REV-meddelandet
8.4.2. Meddelandeinnehåll8.4.3. Tillämpningsregler
8.4.4. Bekräftelse av ett REV
8.4.5. Operativt svar på ett REV8.5. Remitterat ändringsmeddelande (RRV)8.5.1. Syfte med RRV-meddelandet
8.5.2. Meddelandeinnehåll
8.5.3. Tillämpningsregler8.5.4. Bekräftelse av ett RRV
8.5.5. Operativt svar på ett RRV
8.5.6. Exempel8.6. Beredskapsmeddelande (SBY)8.6.1. Syfte med SBY-meddelandet
8.6.2. Meddelandeinnehåll
8.6.3. Tillämpningsregler8.6.4. Bekräftande av ett SBY
8.6.5. Exempel
8.7. Godkännandemeddelande (ACP)8.7.1. Syfte med ACP-meddelandet
8.7.2. Meddelandeinnehåll
8.7.3. Tillämpningsregler8.7.4. Bekräftelse av ett ACP8.7.5. Exempel
8.8. Samordningsmeddelande (CDN)
8.8.1. Syfte med CDN-meddelandet8.8.2. Meddelandeinnehåll
8.8.3. Tillämpningsregler
8.8.4. Bekräftelse av ett CDN8.8.5. Operativt svar på ett CDN8.8.6. Exempel
8.9. Meddelande med avslag av samordning (RJC)
8.9.1. Syfte med RJC-meddelandet8.9.2. Meddelandeinnehåll
8.9.3. Tillämpningsregler
8.9.4. Bekräftelse av ett RJC8.9.5. Exempel
9. DIALOGFÖRFARANDE — KOMMUNIKATIONSÖVERFÖRING
9.1. Allmänt
9.1.1. Inledning2000R2082 — SV — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Meddelandeföljd
9.1.3. Kommunikationsöverföring9.2. Meddelande om initiering av överföring (TIM)
9.2.1. Syfte med TIM-meddelandet
9.2.2. Meddelandeinnehåll9.2.3. Tillämpningsregler9.2.4. Bekräftelse av ett TIM
9.2.5. Exempel
9.3. Meddelande med tilläggsdata (SDM)9.3.1. Syfte med SDM-meddelandet
9.3.2. Meddelandeinnehåll
9.3.3. Tillämpningsregler9.3.4. Bekräftelse av ett SDM9.3.5. Exempel
9.4. Förslag till överlämning (HOP)
9.4.1. Syfte med HOP-meddelandet9.4.2. Meddelandeinnehåll
9.4.3. Tillämpningsregler
9.4.4. Bekräftelse av ett HOP9.4.5. Exempel
9.5. Meddelande med begäran om frekvens (ROF)
9.5.1. Syfte med ROF-meddelandet9.5.2. Meddelandeinnehåll9.5.3. Tillämpningsregler
9.5.4. Bekräftelse av ett ROF
9.5.5. Exempel9.6. Meddelande om frekvensändring (COF)
9.6.1. Syfte med COF-meddelandet
9.6.2. Meddelandeinnehåll9.6.3. Tillämpningsregler9.6.4. Bekräftelse av ett COF
9.6.5. Exempel
9.7. Meddelande om manuellt övertagande av kommunikationen (MAS)9.7.1. Syfte med MAS-meddelandet
9.7.2. Meddelandeinnehåll
9.7.3. Tillämpningsregler9.7.4. Bekräftelse av ett MAS
9.7.5. Exempel
BILAGA A (NORMATIV) REGLER FÖR INFÖRANDE AV DATA
BILAGA B (NORMATIV) KRAV FÖR BEHANDLING AV SÄRSKILDA FLYGVÄGAR2000R2082 — SV — 15.06.2002 — 001.001 — 9
▼B
BILAGA C (INFORMATIV) DIALOGFÖRFARANDEFASER (SYSCO NIVÅ 1) — MEDDELAN-
DEFÖLJD2000R2082 — SV — 15.06.2002 — 001.001 — 10
▼B
MEDDELANDE OM UPPHOVSMANNARÄTT
Detta dokument har sammanställts av Eurocontrolbyrån.
Eurocontrolbyrån har lagstadgad upphovsmannarått.Innehållet, eller del därav, är således fritt tillgängligt för representanter för
medlemsstaterna, dockfår k opiering eller spridning av innehållet till någon
annan part inte ske utan skriftligt tillstånd från Eurocontrolbyrån.2000R2082 — SV — 15.06.2002 — 001.001 — 11
▼B
FÖRORD
1. Ansvarig organisation
Eurocontrolstandard för utbyte on-line av data (On-Line Data
Interchange, OLDI), utgåva 2.2 har utarbetats av direktoratet för
utveckling av Eatchip-programmet för harmonisering och integ-
rering av europeiskflygk ontrolltjänst [Directorate of European
ATC Harmonisation and Integration Programme (EATCHIP)
Development (DED)], inom Eurocontrol, vilket också ansvarar
för uppdateringen av dokumentet. Alla kommentarer och
förfrågningar skall adresseras till generaldirektören för Eurocon-
trol, Rue de la Fusée, 96, B-1130 Bryssel, Attention Division
DED-2.
2. Förhållande till Eatchips arbetsprogramdokument
Denna standard är underordnad specialistuppdrag DPS.ET1.ST06,
under domänen för ATM-databehandlingssystem (DPS) inom
Eatchip, som specificerats i Eatchips arbetsprogramdokument
(EWPD) utgåva 2.0, daterad 940930.
3. Godkännande och ändringar
Denna standard har varit föremål för följande godkännandeförfa-
rande, vilket beskrivits i detalj i direktiven om Eurocontrols
standardisering:
— Godkännande av Eatchips arbetsgrupp för operativa krav och
behandling av ATM-data (ODT) genom korrespondensförfa-
rande.
— Konsultationer med samtliga ECAC-stater genom deras repre-
sentanter i styrkommittén (Committee of Management) eller
Eatchips projektstyrelse.
— Godkännande av Eatchips projektstyrelse och styrkommittén.— Antagande av den ständiga kommissionen.
Villkoren i denna standard gäller efter antagandet av den ständiga
kommissionen.
För att möta kraven på en utveckling av förfaranden för flygkon-
trolltjänst (ATC), kan ändringar och tillägg föreslås genom ODT
för diskussion och möjligt godkännande. Kraven kommer att
införas antingen som en ändring eller som en ytterligare utgåva
av dokumentet för antagande och godkännande enligt specifice-
rade förfaranden.
4. Redaktionella regler
Följande praxis har följts för att beskriva status på respektive
påstående: Normativa delar har skrivits med normal text. Rekom-
menderade delar har skrivits med kursiv stil, och status indikeras
där med prefixet Rekommendation .
Följande redaktionella regel har följts då specifikationerna har
skrivits: I normativa delar används det modala hjälpverbet
”skall”, och i rekommenderade delar används det modala
hjälpverbet ”bör”.
Anmärkningar är skrivna med vanlig text föregångna av prefixet
”ANMÄRKNING” i fet stil.
5. Förhållande till utgåva 1 av Eurocontrolstandard för utbyte
on-line av data
Detta dokument ersätter delarna 1 och 2 av utgåva 1 av Eurocon-
trolstandard för utbyte on-line av data. Del 3, som beskriver de
tekniska protokollen som skall användas har ersatts av Eurocon-
trolstandard för utbyte av flygdata — Dokument för kontroll av
gränssnitt Del 1.2000R2082 — SV — 15.06.2002 — 001.001 — 12
▼B
6. Betydelsefulla förändringar från utgåva 1
De mest betydelsefulla ändringarna och tilläggen från utgåva 1 är
följande:
1. Införandet av följande kompletterande (icke obligatoriska)
meddelanden rörande det grundläggande förfarandet:
— Meddelande om upphävande av samordning (MAC).
— Meddelande om tilldelning av SSR- (Sekundär övervak-
ningsradar) kod (COD).
— Informationsmeddelande (INF).
2. Definition av meddelandeinnehåll och format för att stödja
korsningen av en gräns för en flygning på en kurs som inte
är en definierad flygtrafiklednings- (Air Traffic Services —
ATS) flygväg, men som är definierad med start- och slutpunkt
för flygvägssegmentet.
3. Införandet av ett dialogförfarande som tillåter
— identifiering och hantering av onormala överföri-
ngsförhållanden av flygledare som utför
planeringsfunktionen,
— tillhandahållande av en möjlighet för den mottagande
enheten att lägga fram motförslag till överföringsförhållan-
dena,
— tillhandahållande av funktioner för överföring av kommu-
nikationen, som en del av förfarandet för överföring av
kontrollen.
4. Användandet av det format som beskrivs i utgåva 2 av Euro-
controlstandard för utformningen av utbytet av ATS-data
(ADEXP) har introducerats. Alla meddelanden som specifice-
rats under det grundläggande förfarandet och de som används
under samordningsfasen av dialogförfarandet har beskrivits
med användande av både ICAO- och ADEXP-format. Medde-
landen om kommunikationsöverföring, beskrivna under
dialogförfarandet, beskrivs med användande endast av
ADEXP-format.
5. Strykning av följande bilagor i utgåva 1:
A: Identifiering av ATC-enhet.
B: Struktur på OLDI-meddelanden
(alla meddelanden i utgåva 3 innehåller exempel).
D: Historisköversik t.
E: Genomförandeplan.
F: Staters uppfyllande av krav.G: Riktlinjer för genomförande.H: Riktlinjer för utvärdering av OLDI.
6. Frånskiljande av del 3, Tekniska krav, från tillämpningsspeci-
fikationen.
7. Förhållande till andra dokument
Detta dokument hänvisar till användandet av två typer av
fältformat i sammansättningen av meddelanden. Dessa är ICAO
och ADEXP.
ICAO-fältformatet beskrivs i referensdokument 1. Om referensdo-
kument 1 ersätts av ett annat dokument, skall definitionen av
ICAO-fälttyperna vara de som beskrivs i det dokumentet.
Format för ADEXP-fält beskrivs i referensdokument 2.ANMÄRKNING De referensdokument som det hänvisas till är
listade i avsnitt 2.
8. Språk
Originaltexten i denna standard är skriven på engelska.2000R2082 — SV — 15.06.2002 — 001.001 — 13
▼B
1. INLEDNING
1.1. Syfte
1.1.1. Flygningar som tillhandahålls tjänster från ATC överförs från en
ATC-enhet till en annan på ett sätt som utformats för att
säkerställa total säkerhet. För att detta syfte skall uppnås, är det
normala förfarandet att varje flygnings passering över gränsen
mellan de två enheternas ansvarsområde samordnas mellan dessa
i förväg och att kontrollen av flygningen överförs då den befinner
sig över eller i anslutning till nämnda gräns.
1.1.2. Då den utförs via telefon, är överföringen av data för individuella
flygningar, som del av samordningsförfarandet, en omfattande
stöduppgift för ATC-enheterna, speciellt vid regionala kontroll-
centraler (Area Control Centres, ACC). I syfte att ersätta sådana
muntliga ”uppskattningar” påbörjade man i början av 1980-talet
inom Europa ett operativt användande av anslutningar mellan
processystemen för flygdata (Flight Data Processing Systems —
FDPS) vid kontrollcentralerna, vilket betecknas utbyte on-line av
data — OLDI (On-Line Data Interchange).
1.1.3. För att förenkla genomförandet, utarbetades omsorgsfullt gemen-
samma regler och meddelandeformat vilka accepterades av
berörda organ och införlivades i utgåva 1 av Eurocontrolstandard
för utbyte on-line av data (OLDI). Detta dokument, utgåva 2.2,
har sammanställts för att stödja den fortsatta utvecklingen av
sådana möjligheter med hänsyn till behoven för Eatchip.
1.2. Omfattning
1.2.1. Detta dokument specificerar de hjälpmedel och meddelanden som
skall tillhandahållas mellan FDPS-system som betjänar ATC-
enheter i syfte att uppnå
— den samordning som krävs inför överföringen av flygningar
från en enhet till en annan
— överföring av kommunikationen för sådana flygningar.
1.2.2. Detta dokument
— definierar meddelandeformaten och reglerna för innehållet,
— beskriver hjälpmedlen som behövs vid sådana enheter, och
som utgör förutsättningar för användandet av datautbyte i
detta syfte.
1.2.3. Denna standard är tillämplig mellan medlemsstater i Eurocontrol
på internationella OLDI-installationer mellan enheter som tillhan-
dahåller regional ATC-tjänst
1.2.4. Rekommendation Det rekommenderas att länder inom Europe-
iska konferensen för civil luftfart (ECAC) tillämpar dennastandard på
— internationella OLDI-installationer mellan enheter som till-
handahåller regional ATC-tjänst inom ECAC-området,
— OLDI-installationer mellan enheter som tillhandahåller
regional ATC-tjänst inom berört land.
2. HÄNVISNINGAR
2.1. Följande dokument och standarder innehåller bestämmelser vilka,
genom hänvisningar i denna text, utgör bestämmelser i denna
Eurocontrolstandard.
Vid tidpunkten för publiceringen av denna Eurocontrolstandard
var de angivna utgåvorna av referensdokument och -standarder
gällande.
Vid samtliga revisioner av de ICAO-dokument, till vilka hänvis-
ning här skett, skall omedelbart revision av denna
Eurocontrolstandard tas i beaktande.
Revidering av de övriga dokument som det refererats till, skall
inte utgöra del av bestämmelserna i denna Eurocontrolstandard
förrän de är formellt genomgångna och införlivade i denna Euro-
controlstandard.
Vid konflikt mellan bestämmelserna i denna Eurocontrolstandard
och innehållet i de övriga dokument, till vilka hänvisning skett,
gäller denna Eurocontrolstandard.2000R2082 — SV — 15.06.2002 — 001.001 — 14
▼B
2.2. I denna standard görs hänvisningar till följande dokument:
1. Procedures for Air Navigation Services — Rules of the Air &
Air Traffic Services, ICAO Document 4444, trettonde uppda-
terade utgåvan, daterad 7 Nov. 1996.
2. Utgåva 2.0 av Eurocontrolstandard för utformningen av utbytet
av ATS-data (ADEXP), referens DPS-ET1-ST09-STD-01-00,
daterad juni 1998.
3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
3.1. Definitioner
I denna Eurocontrolstandard används följande beteckningar med
de betydelser som här anges:
3.1.1. accepterande enhet : den enhet, tillhandahållande ATC-tjänst, som
skall överta kontrollen eller som har övertagit kontrollen över en
flygning när överföringen från en enhet till nästa skall ske eller
har skett.
3.1.2. bekräftelse : tillkännagivande att ett meddelande har emottagits
och befunnits vara korrekt för behandling.
3.1.3. aktivering : förfarandet hos en mottagande ATC-enhet i vilken
färdplanen för berörd flygning uppgraderas till att inkludera de
data som tillhandahållits från den överlämnande ATC-enheten
som del av samordningsförfarandet mellan de två enheterna och
som resulterar i tillhandahållandet av data till flygledare.
3.1.4. höjd: det vertikala avståndet till en nivå, en punkt eller ett
föremål betecknat som en punkt, mätt över havsytan.
3.1.5. tillämpning : den del av ett ATS-undersystem som
överensstämmer med denna standard och samverkar med sådana
enheter i andra ATS-system.
3.1.6. ansvarsområde : ett luftrum med fastställda dimensioner inom
vilket en ATC-enhet tillhandahåller flygtrafikledning.
3.1.7. anslutning till färdplan : ett förfarande där ett system samman-
kopplar ett emottaget OLDI-meddelande med en
färdplansregistrering i databasen.
3.1.8. ATC-enhet : en enhet som tillhandahåller flygkontrolltjänst.
3.1.9. tillgänglighet : sannolikheten att en anläggning kommer att vara
tillgänglig för en användare vid en tidpunkt.
3.1.10. gräns: de plan (horisontella and vertikala) som utgör ansvars-
området för en ATC-enhet.
3.1.11. tilldelad flygnivå : den flygnivå till vilken, eller vid vilken, en
flygning för närvarande har fått godkännande av ATC.
3.1.12. samordning, ATC : den process, utförd mellan ATC-enheter med
angränsande ansvarsområden, i vilken man formellt rådgör med
varandra om den planerade flygningen över gränsen, för att
säkerställa flygsäkerheten genom konsekvens i planerade hand-
lingar.
3.1.13. samordningsmeddelande : ett allmänt uttrycksom innebär ett
meddelande som används för att uppnå ATC-samordning. Häri
inkluderas CDN, ett särskilt meddelande som beskrivs i punkt
8.8.
3.1.14. samordningsfas : den fas under en flygning under vilken den
överlämnande och den mottagande ATC-enheten kommer överens
om de förhållanden (t.ex. flygnivå, gränspunkt) under vilka en
flygning skall övergå från en enhets kontroll till en annan.
3.1.15. samordningspunkt : en punkt på eller intill gränsen, igenkänd av
ATC-enheterna i en samordningssekvens och hänvisad till i
samordningsmeddelanden.
3.1.16. samband: förfarande, baserat på fastställda kriterier, för att
sammankoppla färdplansdata och radarspårning för en flygning,
normalt för presentation på en bildskärm hos flygledare.
3.1.17. Eurocontrolstandard : alla specifikationer avseende fysiska egen-
skaper, form, material, funktion, personal eller förfarande, vars
enhetliga tillämpning anses vara oumbärlig för att kunna2000R2082 — SV — 15.06.2002 — 001.001 — 15
▼B
genomföra ett integrerat system för flygtrafikledning (ATS-
system) inom medlemsstater i Eurocontrol. En Eurocontrolstan-
dard får inte strida mot en ICAO-standard, men skall, där detta
är tillämpligt, komplettera den senare.
3.1.18. utövande flygledare : en flygledare som tillhandahåller instruk-
tioner direkt till flygningar under hans/hennes kontroll. Sådana
flygledare inkluderar de som tillhandahåller tjänsterna för radarö-
vervakning av området.
3.1.19. utträdesnivå : den nivå vid vilken en flygning har samordnats till
att korsa en kontrollöverföringspunkt. En utträdesnivå kan inklu-
dera tilläggsvillkor som definierar nivåområdet inom vilket en
stigande/sjunkande flygning kommer att befinna sig.
3.1.20. färdplan: detaljerad information, lämnad till flygtrafikledningsen-
heter, som berör ett flygplans planerade flygning eller del av en
flygning. Även information som härstammar från färdplanen för
en flygning som finns i ett FDPS.
3.1.21. generera: en process i ett ATC-system där relevant data tas ut ur
databasen/databaserna och ett meddelande skapas för överföring
till en mottagande ATC-enhet.
3.1.22. ICAO-format : det format som används för mark-till-mark-
sändningar av ATS-meddelanden och som använder fälttyper och
avgränsare beskrivna i referensdokument 1.
3.1.23. nivå: ett allmänt begrepp som härrör sig till den vertikala posi-
tionen på ett flygplan under flygning. Inom denna standard
inkluderar benämningen nivå eller flygnivå höjd i de fall benäm-
ningen används.
3.1.24. underrättelse : det förfarande där den överlämnande enheten
överför data för att uppdatera systemet hos den mottagande
enheten för att förbereda till samordningsfasen.
3.1.25. mottagande enhet : den ATC-enhet till vilken ett meddelande
skickas.
3.1.26. tillförlitlighet : det procenttal av den schemalagda tillgängligheten
för vilken tjänsten är i drift.
3.1.27. begärd flygnivå : en flygnivå som begärts i färdplanen för en flyg-
ning.
3.1.28. revision: en ändring av data som tidigare skickats från den
överlämnande ATC-enheten till den mottagande ATC-enheten.
3.1.29. tilläggsnivå för korsning : en nivå vid, eller över eller under
vilken en flygning har samordnats för att korsa en kontrollöver-
föringspunkt. Tilläggsnivån, om sådan förekommer, är en del av
utträdesnivån.
3.1.30. systemfärdplan : information som härrör från färdplanen för en
viss flygning och som finns i ett FDPS.
3.1.31. transaktionstid : ett tidsintervall som följer initieringen av ett
meddelande, under vilket överföring, första behandling i motta-
garsystemet, genererandet och överföringen av ett
bekräftelsemeddelande samt dess identifiering i överföringssys-
temet genomförs.
3.1.32. kontrollöverföringspunkt : en fastställd punkt, efter ett flygplans
flygväg, vid vilken ansvaret för att tillhandahålla ATS till flyg-
planet överförs från en ATC-enhet eller kontrollposition till
nästa. Den behöver inte nödvändigtvis överensstämma med
samordningspunkten.
3.1.33. överföringsfas : en fas av en flygning, som följer samordningsf-
asen, under vilken överföringen av kommunikationen verkställs.
3.1.34. överlämnande enhet : i en samordningssekvens, den ATC-enhet
som är ansvarig för att tillhandahålla en tjänst till en flygning
före gränsen och som påbörjar samordningsfasen med nästa
enhet.
3.1.35. sända: överföra ett meddelande från ett system till ett annat.
3.1.36. enhet: flygtrafikledningsenhet
3.1.37. varning: ett meddelande som visas på en arbetsstation när den
automatiska samordningsprocessen har misslyckats.2000R2082 — SV — 15.06.2002 — 001.001 — 16
▼B
3.2. Symboler och förkortningar
I denna Eurocontrolstandard används följande förkortningar med
de betydelser som här anges:
ABI Förhandsmeddelande med gränsinformation
(Advance Boundary Information Message)
ACC Regional kontrollcentral (Area Control Centre)ACP Godkännandemeddelande (Accept Message)
ACT Aktiveringsmeddelande (Activate Message)
ADEXP Utformningen av utbytet av ATS-data (ATS Data
Exchange Presentation)
ATC Flygkontrolltjänst (Air Traffic Control)ATM Flygledning (Air Traffic Management)ATS Flygtrafikledning (Air Traffic Service)
CDN Samordningsmeddelande (Co-ordination Message)
CNL Annullering av färdplan (Flight Plan Cancellation)COD Meddelande om tilldelning av SSR-kod (SSR Code
Assignment Message)
COF Meddelande om frekvensändring (Change of
Frequency Message)
COP Samordningspunkt (Co-ordination Point)
DED Direktoratet för utveckling av Eatchip-programmet
(Directorate of Eatchip Development), Eurocontrol
Eatchip Programmet för harmonisering och integrering av
europeiskflygk ontrolltjänst (European ATC Harmo-
nisation and Integration Programme)
ECAC Europeiska konferensen för civil luftfartETO Beräknad ”time over” (Estimated Time Over)
ETOT Beräknad starttid (Estimated Take-Off Time)
EWPD Eatchips arbetsprogramdokument (Eatchip Work
Programme Document)
FDPS Processystem för flygdata (Flight Data Processing
System)
FRF Fortsatt flygväg (Further Route of Flight)
HMI Gränssnitt människa-maskin (Human-Machine Inter-
face)
HOP Meddelande med förslag till överlämning (Handover
Proposal Message)
ICAO Internationella civila luftfartsorganisationenINF Informationsmeddelande (Information Message)
LAM Logiskt bekräftelsemeddelande (Logical Acknowled-
gement Message)
LoA Skriftlig överenskommelse (Letter of Agreement)
MAC Meddelande om upphävande av samordning
(Message for the Abrogation of Co-ordination)
MAS Manuellt övertagande av kommunikationen (Manual
Assumption of Communications)
NM Nautiskmil (Nautical Mile)OLDI Utbyte on-line av data (On-Line Data Interchange)
ORCAM Metod för kodtilldelning för upphovsområde (Origi-
nating Region Code Assignment Method)
PAC Preliminärt aktiveringsmeddelande (Preliminary
Activate Message)
RAP Meddelande med remitterat aktiveringsförslag
(Referred Activate Proposal Message)
REV Ändringsmeddelande (Revision Message)RJC Meddelande med avslag av samordning (Reject Co-
ordination Message)
ROF Meddelande med begäran om frekvens (Request on
Frequency Message)2000R2082 — SV — 15.06.2002 — 001.001 — 17
▼B
RRV Remitterat ändringsmeddelande (Referred Revision
Message)
SBY Beredskapsmeddelande (Stand-by Message)SDM Meddelande med tilläggsdata (Supplementary Data
Message)
SSR Sekundär övervakningsradar (Secondary Surveil-
lance Radar)
SYSCO Systemstödd samordning (System Supported Co-
ordination)
TI Initiering av överföring (Transfer Initiation)TIM Meddelande om initiering av överföring (Transfer
Initiation Message)
TWR/APP Kontrolltorn och inflygningskontroll [Tower (aero-
drome control) and Approach Control]
4. ALLMÄNNA KRAV
4.1. Inledning
Detta avsnitt beskriver de allmänna operativa kraven nödvändiga
för genomförandet av OLDI-möjligheter mellan ATC-enheter
samt klassificerings- och prestandakraven för de olika typer av
meddelanden som används.
4.2. Systemkrav för behandling av flygdata
4.2.1. Flygdatabas
Enheter som utnyttjar en möjlighet som beskrivs i detta dokument
skall förses med data från en FDPS som innehåller all nödvändig
information som specificerats för visning, behandling och
sammansättning av meddelanden. Den primära källan till data
för varje flygning är färdplanen som den registrerats av, eller
för, befälhavaren. Ytterligare data erhålls genom behandlingen
av färdplaner med hänvisning till förhållandena vid berörd enhet.
4.2.2. Drift i realtid
OLDI-förfarandet inkluderar händelser hos den överlämnande
ATC-enheten för att initiera funktioner som är nödvändiga för
lämplig presentation av data till den accepterande enheten. I detta
syfte skall FDPS kunna initiera funktioner genom jämförelsemellan UTK-tid och tillämpliga tidsparametrar med tider vid
angivna positioner längs flygvägen, fastställda med hjälp av flyg-
databasen.
4.2.3. Kapacitet för datakommunikation
4.2.3.1. FDPS skall kunna mottaga och sända flygdata i det format som är
tillämpligt för meddelandena som specificerats i detta dokument
via ett medium för datakommunikation som stödjer OLDI-funk-
tionen.
4.2.3.2. Rekommendation FDPS borde ha utvecklingspotential för att
tillåta tillägg av nya meddelanden som kan komma att inkluderas
i framtida utgåvor av denna standard.
4.2.3.3. Inom prestandakraven som specificerats i detta dokument, skall
mediet för datakommunikation tillhandahålla ett snabbt och pålit-
ligt datautbyte mellan tillämpningarna genom
— säkerställande av integritet vid överföring av OLDI-medde-
landen
och
— kontroll av direktanslutningar eller status på kommunikations-
nätverket, vilket som är tillämpligt.
4.2.3.4. FDPS skall varna arbetsstationerna när avvikelser upptäcks av
datakommunikationssystemet.
4.2.4. Funktioner
4.2.4.1. Systemen som används för OLDI-installationer skall automatiskt
kunna ta emot, lagra, behandla, utvinna och leverera för visning,
samt sända OLDI-relaterad data i realtid.2000R2082 — SV — 15.06.2002 — 001.001 — 18
▼B
4.2.4.2. FDPS skall
— återspegla aktuell operativ data av betydelse för OLDI-funk-
tionerna enligt kraven i denna standard, uppdaterad antingen
automatiskt eller genom manuell inläsning, eller genom en
kombination av båda,
— kunna utvinna sådana delar från databasen för färdplaner,
— identifiera nästa ATC-enhet längs flygvägen.
4.2.4.3. Följande skall överenskommas bilateralt:
— Samordningspunkter (COP).
— Referenspunkter använda för bärings- och distansnoteringar
för identifiering av COP på direkta, icke ATS-segment av
flygvägen, där sådana brukas.
ANMÄRKNING COP behöver inte alltid vara identiska med
kontrollöverföringspunkterna.
4.2.5. Gränssnitt människa-maskin (HMI)
4.2.5.1. HMI skall kunna
— visa det operativa innehållet i OLDI-meddelanden och rele-
vanta varningar relaterade till emottagna meddelanden för
omedelbar uppmärksamhet,
— befordra varningar rörande samordnings- och överföringsmed-
delanden till ansvariga operativa befattningar för samordning
av berörda flygningar.
4.2.5.2. ATC personal skall ha tillgång till medel för att omvandla data,
från vilken det operativa innehållet i meddelanden erhålls, enligt
kraven i detta dokument.
4.2.5.3. HMI skall visa att överföring av meddelandet pågår, eller att
överföringen har lyckats, vilket som är fallet.
4.2.5.4. En varning eller underrättelse till berörd ATC eller teknisk(a)
befattning(ar) skall genereras automatiskt om ingen bekräftelse
har emottagits inom tidsparametern som följer efter en sändning
av ett samordnings- eller överföringsmeddelande.
4.2.5.5. En sådan varning eller underrättelse skall vara i sådant format att
den omedelbart tilldrar sig uppmärksamhet vid berörd arbetssta-
tion.
4.2.5.6. Rekommendation HMI vid ATC-stationer som använder OLDI
bör utfärda en varning om OLDI-installationen ej är tillgänglig.
4.2.6. Initiering av meddelanden
4.2.6.1. Varje system skall bestå av en uppsättning systemparametrar för
att säkerställa läglig automatisk initiering av OLDI-meddelanden.
4.2.6.2. Rekommendation Det skall finnas möjlighet att manuellt initiera
överföringen av ett samordningsmeddelande före den beräknade
sändningstiden.
4.2.6.3. Det skall säkerställas att den automatiska funktionen alltid utlöses
om manuell initiering ej utförs.
4.2.6.4. Systemet skall använda tidsparametrar för att definiera följande:
— Tid, före sändning, då det operativa innehållet i meddelandena
inom den överlämnande enheten visas.
— Tid, global eller per COP, för att sända meddelandet, där så är
tillämpligt.
— Tid efter sändning av ett meddelande efter vilken en
bekräftelse på tillämpningsnivå skall erhållas (tidsbegräns-
ning).
4.2.6.5. Ett meddelande skall sändas utan fördröjning när den erforderliga
informationen blir tillgänglig vid en tidpunkt senare än den vid
vilken det annars normalt skulle ha sänts.
Exempel: En flygning påbörjar ett GAT IFR-segment vid en
punkt nära den gräns som den skall korsa. ETO för punkten
meddelas åtta minuter före COP, vid vilken tid sändningen av
ATC-meddelandet redan är sen, baserat på tillämplig(a) tidspara-
meter(-parametrar). Meddelandet sänds utan fördröjning.2000R2082 — SV — 15.06.2002 — 001.001 — 19
▼B
4.2.7. Mottagande av meddelanden
4.2.7.1. ATC-systemet skall ha förmågan att
— ta emot OLDI-meddelanden,
— behandla dessa automatiskt i överensstämmelse med denna
standard,
— producera flygdata i överensstämmelse med mottaget medde-
lande och visa erforderliga varningar om det finns
motsägelser i emottagen data,
— automatiskt generera och sända bekräftelsemeddelanden på
tillämpningsnivån.
4.2.7.2. Ett bekräftelsemeddelande [logiskt bekräftelse- (LAM), godkän-
nande- (ACP) eller avvakta- (SBY) meddelande] skall genereras
och sändas när motsvarande meddelande har behandlats och
presentationen till berörd(a) arbetsstation(er) av resultaten av
behandlingen har säkerställts.
ANMÄRKNING De detaljerade förhållandena för genererandet
av en bekräftelse anges individuellt för varje
meddelande.
4.3. Uppdatering från övervakningsdata
Rekommendation För att säkerställa noggrannheten för data med
beräknad tid, skall information från bevakning av flygningar med
hjälp av radar eller annan övervakningsfunktion användas för att
uppdatera databasen för färdplaner.
4.4. Registrering av OLDI-data
4.4.1. Innehåll
Innehållet i alla OLDI-meddelanden samt mottagningstiden skall
registreras.
4.4.2. Installationer
Installationer skall finnas tillgängliga för inhämtning och visning
av registrerad data.
4.5. Tillgänglighet, tillförlitlighet, datasäkerhet och dataintegritet
4.5.1. Tillgänglighet
4.5.1.1. OLDI-installationen skall vara tillgänglig under tider då
trafikflödet mellan de två berörda enheterna är normalt och under
högtrafik.
4.5.1.2. Rekommendation OLDI-installationen bör vara tillgänglig 24
timmar dagligen.
4.5.1.3. Varje planlagd nedstängningsperiod (och således den planerade
tillgänglighetstiden) skall vara överenskommen bilateralt mellan
de två berörda enheterna.
4.5.2. Tillförlitlighet
4.5.2.1. Tillförlitligheten i alla OLDI-förbindelser skall vara minst
99,86 % (motsvarande en nedstängningstid som inte överstiger
12 timmar per år baserat på 24-timmars tillgänglighet.)
4.5.2.2. Rekommendation När det är motiverat ur operativ synpunkt, bör
en tillgänglighet av minst 99,99 % tillhandahållas (motsvarande
en nedstängningstid som inte överstiger 52 minuter per år baserat
på 24-timmars tillgänglighet).
4.5.3. Datasäkerhet
Rekommendation Metoder för datasäkerhet (t.ex. användarrättig-
heter, källverifikation) och, där så är
tillämpligt, nätverksadministration bör tillä-
mpas för OLDI-installationer.
4.5.4. Dataintegritet
Felfrekvensen på tillämpningsnivå får inte överstiga ett
sändningsfel per 2 000 meddelanden.2000R2082 — SV — 15.06.2002 — 001.001 — 20
▼B
4.6. Driftsutvärdering
4.6.1. Utvärderingsperiod
Varje ny OLDI-installation, inklusive en ny installation på en
befintlig anslutning, skall innan den tas i bruk vara föremål för
en utvärderingsperiod för bekräftelse av dataintegritet,
noggrannhet, prestanda och kompatibilitet med ATC-förfarandena
samt övergripande säkerhet.
ANMÄRKNING Ett förfarande för att bistå i utvärderingen av
ett nytt OLDI-system finns tillgängligt från
OLDI-sekretariatet, Eurocontrol.
4.6.2. Operativt startdatum
Datumet för den operativa starten, som innebär att utvärdering-
sperioden fullbordas, skall vara formellt överenskommet mellan
de två enheterna.
5. MEDDELANDEKATEGORIER
5.1. Allmänt
5.1.1. Syfte
Detta avsnitt av dokumentet
— definierar kategorier av meddelanden,
— anger kraven på transaktionstid för kategorierna,
— anger vilka meddelanden som är obligatoriska och vilka som
är kompletterande,
— kategoriserar meddelandetyperna.
5.1.2. Meddelandekategorier
OLDI-meddelanden har tilldelats följande kategorier:
— Kategori 1: Kommunikationsöverföring.
— Kategori 2: Samordning.
— Kategori 3: Underrättelse.
5.2. Transaktionstider
5.2.1. Villkor för transaktionstider
5.2.1.1. De specificerade transaktionstiderna inkluderar sändning, inle-
dande behandling vid mottagarenheten, sammanställning av
bekräftelsemeddelandet, dess avsändande samt mottagandet hos
överlämnande enhet. De automatiska bekräftelsemeddelandena,
LAM och SBY, har därför inte tilldelats en meddelandekategori.
5.2.1.2. De maximala transaktionstiderna för de olika meddelandekatego-
rierna skall vara de som anges i tabell 5-1.
Tabell 5-1
Maximala Transaktionstider
Meddelandekategori 90 % 99,8 %
14 s 1 0 s
2 15 s 10 s
3 25 s 45 s
5.2.1.3. Ett värde på tidsbegränsning skall definieras per meddelandekate-
gori eller typ.
5.2.1.4. Om ingen bekräftelse har emottagits inom den fastställda tiden
efter sändning, skall ett meddelande bedömas vara otillfredsstäl-
lande överfört eller behandlat, och en varning skall lämnas enligt
specifikationerna i berört avsnitt av detta dokument.2000R2082 — SV — 15.06.2002 — 001.001 — 21
▼B
5.2.1.5. Rekommendation Värdena för tidsbegränsning för de tre katego-
rierna skall inte överskrida 12 sekunder, 30 sekunder respektive
60 sekunder.
5.3. Klassificering och kategorisering av meddelanden
5.3.1. Meddelandeklassificering — obligatoriska och kompletterande
5.3.1.1. Meddelanden som beskrivs i detta dokument klassificeras
antingen som obligatoriska eller kompletterande.
5.3.1.2. När ett meddelande beskrivs som obligatoriskt (M) för sändning
(TX) skall behandling inkluderas för att sådana meddelanden ska
kunna sändas.
5.3.1.3. När ett meddelande beskrivs som obligatoriskt för mottagning
(REC) skall behandling inkluderas för att mottagna meddelanden
ska kunna behandlas.
ANMÄRKNING I exceptionella fall, där trafikflödet mellan två
enheter endast går i en riktning, kan de obliga-
toriska meddelandena vara tillämpbara i endast
en riktning.
5.3.1.4. Då ett meddelande beskrivs som kompletterande (C) för sändning
skall behandling inkluderas för att sådana meddelanden ska kunna
sändas om så krävs av den sändande enheten och detta är bilate-
ralt överenskommet med den mottagande enheten.
ANMÄRKNING Kompletterande meddelanden kan endast
användas i en riktning, beroende på operativa
krav.
5.3.1.5. Då ett meddelande beskrivs som kompletterande för mottagning,
skall behandling inkluderas för att mottagna meddelanden ska
kunna behandlas där sådan användning är bilateralt överens-
kommen.
5.3.1.6. Kraven som beskrivs i tabellerna 5-3 och 5-4 gäller endast då
respektive användande av dialogförfaranden för samordning och/
eller överföring av kommunikationen har överenskommits bilate-
ralt mellan ATC-enheter.
5.3.2. Kategorisering av meddelanden
5.3.2.1. Kategoriseringen av meddelanden för det grundläggande förfa-
randet är specificerad i tabell 5-2.
5.3.2.2. Kategoriseringen av de extra samordningsmeddelandena för
dialogförfarandet är specificerad i tabell 5-3.
5.3.2.3. Kategoriseringen av meddelanden för kommunikationsöverföring
för dialogförfarandet är specificerad i tabell 5-4.
Tabell 5-2
Grundläggande förfarandemeddelanden
Meddelandetyp Förkortning Kategori Sändning Mottagning
Förhandsmeddelande med
gränsinformationABI 3 M M
Aktivering ACT 2 M M
Ändring REV 2 C (1)C (1)
Preliminär aktivering PAC 2 C CUpphävande av samord-
ningMAC 2 C C
Tilldelning av SSR-kod COD 2 C C
Information INF 3 C C2000R2082 — SV — 15.06.2002 — 001.001 — 22
▼B
Meddelandetyp Förkortning Kategori Sändning Mottagning
Logiskt bekräftelsemedde-
landeLAM M M
ANMÄRKNING
(1) Obligatoriskför TX och REC vid användning i ett dialogförfarande.
Tabell 5-3
Dialogförfarande — samordningsfasmeddelanden
(Tillägg till tabell 5-2)
Meddelandetyp Förkortning Kategori Sändning Mottagning
Remitterat aktiveringsför-
slagRAP 2 C M
Hänvisad ändring RRV 2 C M
Samordning CDN 2 M M
Beredskap (1) SBY M M
Godkännande ACP 2 M M
Avslag till samordning(2) RJC 2 C C
ANMÄRKNINGAR
(1) Se punkt 5.2.1.1 Villkor för transaktionstider.
(2) Används inte i alla luftrumskonfigurationer.
Tabell 5-4
Dialogförfarande — överföringsfasmeddelanden
Meddelandetyp Förkortning Kategori Sändning Mottagning
Initiering av överföring TIM 1 M M
Tilläggsdata SDM 1 (1)(1)
Förslag till överlämning HOP 1 M M
Frekvensändring (2) COF 1 C M
Begäran om frekvens ROF 1 C M
Manuellt övertagande (2) MAS 1 C M
ANMÄRKNINGAR
(1) M när avsänt från den överlämnande enheten; C när avsänt från den accepterande enheten.
(2) Bilateralt överenskomna förfaranden skall specificera att då överlämningen sker i samband med
en viss trafikflödesriktning skall, som ett minimum, antingen den överlämnande enheten sändaett COF-meddelande eller den accepterande enheten sända ett MAS-meddelande.
6. GRUNDLÄGGANDE FÖRFARANDEN — OBLIGATO-
RISKA MEDDELANDEN
6.1. Allmänt
6.1.1. Kravbeskrivning
Detta avsnitt beskriver minimikraven vid tillämpningsnivån för
genomförandet av OLDI-installationer.
6.1.2. Genomförande
Enheter som använder OLDI för samordning av flygningar skall
införa ABI, ACT, och LAM så som beskrivs i detta avsnitt,
förutom vid en bilateral överenskommelse om att använda
dialogförfarandet för samordning så som beskrivs i avsnitt 8 i
detta dokument, i vilket fall villkoren för användandet av ACT-
och LAM-meddelanden definieras i det avsnittet.2000R2082 — SV — 15.06.2002 — 001.001 — 23
▼B
6.2. Förhandsmeddelande — gränsinformation (ABI)
6.2.1. Syfte med ABI-meddelandet
ABI möter följande operativa krav:
— Möjliggör förvärv av saknad färdplansdata.
— Tillhandahåller i förhand gränsinformation och ändringar till
densamma för nästa ATC-enhet.
— Uppdaterar grundläggande färdplansdata.
— Underlättar tidig samordning av radarspårning.
— Underlättar noggrann kortsiktig uppskattning av sektorbelast-
ning.
ABI är ett underrättelsemeddelande.
6.2.2. Meddelandeinnehåll
ABI-meddelandet skall innehålla följande data:
— Meddelandetyp
— Meddelandenummer
— Luftfartygsidentifiering
— SSR-läge och -kod (om tillgängligt)
— Startflygplats
— Beräknad data— Landningsflygplats
— Antal och typ av luftfartyg
— Typ av flygning
— Utrustningens kapacitet och status
— Flygväg (valfritt)
— Annan färdplansdata (valfritt)
ANMÄRKNING: Regler för införande av data, format och
fältinnehåll beskrivs i bilaga A.
6.2.3. Tillämpningsregler
6.2.3.1. Allmänt
6.2.3.1.1. Förutom vad som anges i 6.2.3.1.3 och 6.2.3.1.4 nedan, skall ett
eller flera ABI-meddelanden sändas för varje flygning som är
planerad att korsa gränsen mellan ansvarsområden som är berörda
av OLDI-förfaranden.
6.2.3.1.2. När det sänds, skall ABI-meddelandet föregå aktiveringsmedde-
landet (ACT) eller remitterat aktiveringsförslag (RAP).
6.2.3.1.3. Ett ABI-meddelande skall inte genereras om ett preliminärt akti-
veringsmeddelande (PAC) skall sändas.
6.2.3.1.4. Rekommendation ABI-sändning bör förhindras om ACT- eller
RAP-meddelande skall sändas omedelbart eller inom bilateralt
överenskommet tidsintervall.
ANMÄRKNING Syftet med denna rekommendation är att
undvika samtidiga försök till utredningar av
avvikelser vid olika stationer hos den motta-
gande enheten beträffande ABI- och ACT-
meddelanden för samma flygning.
6.2.3.1.5. Ett ändrat ABI-meddelande skall sändas om det efterföljande
ACT-meddelandet inte har genererats och
— flygvägen har ändrats så att COP i det föregående ABI-
meddelandet inte längre är korrekt,
— landningsflygplats har ändrats,
eller
— flygplanstypen har ändrats.
6.2.3.1.6. Rekommendation Ett ändrat ABI-meddelande bör sändas om det
efterföljande ACT-meddelandet inte har genererats och en av
följande punkter ändras:
—Den beräknade nivån vid gränskorsningen .
—Den förväntade SSR-koden vid kontrollöverföringspunkten .2000R2082 — SV — 15.06.2002 — 001.001 — 24
▼M1
▼B
▼B
—När beräknad ”time over” (ETO) vid COP avviker från det
tidigare ABI-meddelandet med mer än den tid som specifice-
rats i den skriftliga överenskommelsen (LoA).
—All annan data som berörs av bilateral överenskommelse .
6.2.3.2. Behandling hos den mottagande enheten
6.2.3.2.1. Det ATC-system som emottar ett ABI-meddelande skall försöka
ansluta till motsvarande färdplansdata.
6.2.3.2.2. Om det inte gickatt upprätta en anslutning till färdplanen, sk all
en färdplan skapas automatiskt eller manuellt i det mottagande
systemet.
6.2.3.2.3. Om det gickatt upprätta en anslutning till färdplanen, men en
avvikelse noteras mellan data i meddelandet och motsvarande
data i det mottagande systemet, vilket skulle resultera i behovet
av en korrigerande åtgärd vid mottagandet av efterföljande ACT-
meddelande, skall avvikelsen överlämnas till lämplig befattnings-
havare för tillrättaläggande.
6.2.3.3. Tidsparametrar för sändning
6.2.3.3.1. Meddelandet skall sändas inom en tidsparameter, i minuter, före
beräknad tid vid COP.
6.2.3.3.2. Parametern (parametrarna) för genererandet av ABI skall ingå i
LoA mellan berörda ATC-enheter.
6.2.3.3.3. Rekommendation Parametern(parametrarna) för genererandet av
ABI bör vara
—variabla, baserat på villkoren i LoA,
—definierade separat för varje COP .
6.2.4. Bekräftelse på ett ABI
6.2.4.1. Bekräftelse
ABI-meddelandet skall bekräftas genom genererandet och
sändningen av ett LAM-meddelande.
ANMÄRKNING Ett LAM-meddelande genereras oavsett resul-
tatet av försöket att ansluta till färdplanen.
6.2.4.2. Ingen bekräftelse
Rekommendation Om inget LAM-meddelande tas emot som
bekräftelse på ett ABI-meddelande, skall en varning visas hos en
övervakande befattningshavare.
6.2.5. Exempel
”Air 2000” 253, en Boeing 757 från Malta till Birmingham
beräknad BNE VOR vid 1221 UTC, flyger på FL350 med verklig
fart på 480 knop, planerad att gå via UB4 BNE UB4 BPK UB3
HON, transponder på A7012 och begär FL390. Följande är
överensstämmande exempel på ABI meddelandet sänt från Reims
till Londons ACC.
6.2.5.1. ICAO
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.2.5.2. ADEXP
TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 - ADEP
LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES
EGBB -ARCTYP B757 -FLTTYP N -BEGIN EQCST -EQPT W/
EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON)2000R2082 — SV — 15.06.2002 — 001.001 — 25
▼M1
▼B
6.3. Aktiveringsmeddelande (ACT)
6.3.1. Syfte med aktiveringsmeddelandet
ACT-meddelandet uppfyller följande operativa krav:
— Ersätter den muntliga gränsuppskattningen genom att automa-
tiskt sända detaljer om en flygning från en ATC-enhet till
nästa innan överföringen av kontrollen äger rum.
— Uppdaterar grundläggande färdplansdata hos den övertagande
ATC-enheten med den senaste informationen.
— Underlätta distribution och visning av färdplansdata till
berörda arbetsstationer inom den övertagande ATC-enheten.
— Påskynda visning av callsign/kod-förhållandet i den överta-
gande ATC-enheten.
— Förse den övertagande ATC-enheten med information om
förhållandena för överföring.
6.3.2. Meddelandeinnehåll
ACT-meddelandet skall innehålla följande data:
— Meddelandetyp
— Meddelandenummer
— Luftfartygsidentifiering
— SSR-läge och -kod
— Startflygplats
— Beräknad data
— Landningsflygplats
— Antal och typ av luftfartyg
— Typ av flygning
— Utrustningens kapacitet och status
— Flygväg (valfritt)
— Annan färdplansdata (valfritt)
ANMÄRKNING: Regler för införande av data, format och
fältinnehåll beskrivs i bilaga A.
6.3.3. Tillämpningsregler
6.3.3.1. Allmänt
6.3.3.1.1. Ett ACT-meddelande skall sändas för berättigade flygningar som
korsar gränsen, förutom vad som sägs i punkt .
6.3.3.1.2. ACT-meddelandet skall genereras och sändas automatiskt på
beräknad tid såsom specificerats i den skriftliga överenskom-
melsen, om det inte har initierats manuellt vid ett tidigare tillfälle.
6.3.3.1.3. Rekommendation ATC-personal bör förses med en möjlighet att
utlösa sändningen av ett ACT-meddelande före den beräknade
tiden för sändning.
6.3.3.1.4. Det operativa innehållet i ett ACT-meddelande som skall sändas
skall visas vid arbetsstationen med ansvar för samordningen av
flygningen, före den faktiska sändningen.
6.3.3.1.5. Rekommendation Beträffande 6.3.3.1.4, gäller att tidpunkten vid
vilken det beräknas att ACT-meddelandet automatiskt skall
sändas bör visas tillsammans med dess innehåll.
6.3.3.1.6. ACT-meddelandet skall innehålla den senaste informationen för
flygningen, återspeglande de förväntade utträdesförhållandena.
6.3.3.1.7. Den berörda arbetsstationen skall underrättas om sändningen av
ACT-meddelandet.
6.3.3.1.8. Så snart ett LAM har mottagits, blir datan i ACT-meddelandet
operativt bindande för båda ATC-enheterna. De samordnade
överföringsförhållandena och det faktum att ett LAM har emotta-
gits skall presenteras för ATC-personalen vid den överlämnande
enheten.
6.3.3.1.9. Godkännande av överföringsförhållandena, som framgår av ACT-
meddelandet, skall ske av den mottagande enheten, om inte den
mottagande enheten initierar samordning för att ändra dessa.2000R2082 — SV — 15.06.2002 — 001.001 — 26
▼M1
▼B
▼B
6.3.3.1.10. Ytterligare ett ACT-meddelande får endast sändas till samma
samordningspartner om det tidigare har upphävts genom
användandet av ett MAC.
6.3.3.1.11. Flygväg och annan färdplansdata skall inkluderas om så är bilate-
ralt överenskommet.
6.3.3.2. Behandling i den mottagande enheten6.3.3.2.1. Det ATC-system som tar emot ett ACT-meddelande skall försöka
ansluta till den berörda färdplanen.
6.3.3.2.2. Om berörd färdplan påträffas och inga avvikelser förekommer i
meddelandet som skulle förhindra korrekt behandling skall
— det operativa innehållet inkluderas i färdplanen,
— erforderlig data föras ut till operativ ATC och andra tillämp-
liga stationer,
— ett LAM återsändas.
6.3.3.2.3. Om berörd färdplan inte kan påträffas, eller om en avvikelse som
förhindrar korrekt behandling av meddelandet påträffas skall,
— om sektorn ansvarig för att acceptera kontroll över flygningen
kan identifieras,
— det operativa innehållet i meddelandet visas vid sektorn,
— ett LAM återsändas,
— en färdplan skapas,
— i alla övriga fall skall ett LAM inte återsändas.
6.3.3.3. Sändningsparametrar
6.3.3.3.1. Meddelandet skall sändas vid eller så snart som möjligt efter den
första av de tidpunkter som fastställs enligt följande:
— En tidsparameter, i minuter, före den beräknade tiden vid
COP.
— Tidpunkten vid vilken flygningen befinner sig på ett bilateralt
överenskommet avstånd från COP.
6.3.3.3.2. Parametern (parametrarna) för genererandet av ACT skall vara
inkluderade i LoA mellan berörda ATC-enheter.
6.3.3.3.3. Parametern (parametrarna) för genererandet av ACT skall vara
variabel (variabla) baserat på villkoren i den skriftliga överens-
kommelsen.
6.3.3.3.4. Rekommendation Parametrar för genererande av ACT bör defi-
nieras separat för varje COP.
6.3.3.3.5. De fastställda parametrarna skall ge tillräckligt med tid för
— den sändande enheten att uppdatera flygnivån vid överför-
ingen till att återspegla de förväntade förhållandena vid COP,
och
— den mottagande enheten att behandla ACT-meddelandet och
att generera samt sända ett LAM men ändå ge utrymme för
genomförande av muntlig samordning från den överlämnande
enheten och resulterande åtgärder initierade av den motta-
gande enheten om utbytet av data misslyckas.
6.3.4. Bekräftelse av ett ACT
6.3.4.1. Bekräftelse
ACT-meddelandet skall bekräftas genom genererandet och
sändandet av ett LAM-meddelande.
6.3.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som bekräftelse på ett
ACT-meddelande, skall en varning visas vid den ATC-station
som har ansvaret för samordningen av flygningen.
6.3.5. Exempel
De följande exemplen är en utvidgning av de som getts för ABI-
meddelanden i punkt 6.2. Alla detaljer är desamma förutom ETO
vid COP, vilken är 1226 i ACT-meddelandet som visas.2000R2082 — SV — 15.06.2002 — 001.001 — 27
▼M1
6.3.5.1. ICAO
(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. ADEXP
-TITLE ACT -REFDATA -SENDER –FAC E -RECVR -FAC L -
SEQNUM 005 –ARCID AMM253 -SSRCODE A7012 -ADEP
LMML -COORDATA -PTID BNE -TO 1226 -TFL F350
–ADES EGBB -ARCTYP B757 -FLTTYP N-BEGIN EQCST-
EQPT W/EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390
UB4 BNE UB4 BPK UB3 HON
6.4. Logiskt bekräftelsemeddelande (LAM)
6.4.1. Syfte med LAM-meddelandet
LAM är den metod genom vilken mottagandet och skyddet av ett
sänt meddelande påvisas för den sändande enheten från den
mottagande enheten.
LAM-förfarandet förser ATC-personal vid den överlämnande
enheten med följande:
— En varning när ingen bekräftelse har emottagits.
— En anvisning om att meddelandet som bekräftas har mottagits,
behandlats problemfritt, befunnits vara fritt från fel, sparats
och, om detta är relevant, finns tillgängligt för presentation
till berörd(a) arbetsstation(er).
6.4.2. Meddelandeinnehåll
LAM-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.— Meddelandereferens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
6.4.3. Tillämpningsregler
6.4.3.1. Allmänt6.4.3.1.1. Reglerna för återsändande av ett LAM beskrivs i avsnitten om
behandling av respektive meddelande i detta dokument.
6.4.3.1.2. LAM-meddelandet skall genereras och sändas utan mänsklig
inblandning.
6.4.3.1.3. LAM-meddelandet skall inte användas för att undvika behovet av
tekniska meddelanden för att säkerställa integriteten vid dataöver-
föringar.
6.4.3.1.4. LAM-meddelandet skall genereras och sändas omgående så att
kravet på sändningstid för meddelandet som bekräftas kan mötas.
6.4.3.1.5. Med undantag av ABI-meddelanden, skall det sändande ATC-
systemet informera den flygledare som är ansvarig för samord-
ningen om ett LAM-meddelande inte har emottagits inom den
tidsparameter som är fastställd för sådana varningar.
6.4.4. Bekräftelse av ett LAM
LAM-meddelandet skall inte kräva någon bekräftelse.
6.4.5. Exempel
6.4.5.1. ICAO
(LAML/E012E/L001)
6.4.5.2. ADEXP
-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -
SEQNUM 0012000R2082 — SV — 15.06.2002 — 001.001 — 28
▼B
▼B
7. GRUNDLÄGGANDE FÖRFARANDE – KOMPLETTE-
RANDE MEDDELANDEN
7.1. Allmänt
7.1.1. Kravbeskrivning
Detta avsnitt beskriver ytterligare funktioner som kan tillämpas
vid de grundläggande förfarandena, utöver de som beskrivits i
avsnitt 6, Grundläggande förfaranden — Obligatoriska medde-
landen.
7.1.2. Genomförande
7.1.2.1. Innan någon av de funktioner som beskrivs i detta avsnitt börjar
användas, skall en bilateral överenskommelse träffas.
7.1.2.2. Då överenskommelse om sådan användning har träffats, skall
reglerna som beskrivs i detta avsnitt gälla.
7.2. Preliminärt aktiveringsmeddelande (PAC)
7.2.1. Syfte med PAC-meddelandet
PAC-meddelandet möter följande operativa krav:
— Underrättelse och samordning före avgång av en flygning, då
flygtiden från avgång till COP är mindre än vad som krävs
för att uppfylla de överenskomna tidsparametrarna för
sändande av ACT-meddelande.
— Underrättelse och samordning före avgång av en flygning
mellan en lokal (flygplats-/inflygningskontroll-)enhet och
nästa enhet som skall ta kontroll över flygningen.
— Ger möjlighet att erhålla saknad färdplansdata om avvikelser
förekommer i den ursprungliga distributionen av färdplans-
data.
— Begär tilldelning av en SSR-kod från den enhet till vilken
ovanstående underrättelse/samordning har skickats, om så
erfordras.
7.2.2. Meddelandeinnehåll
PAC-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.— Meddelandereferens (valfritt).
— Flygplansidentifiering.
— SSR-läge och -kod.— Startflygplats.— Beräknad starttid eller beräknad data.— Landningsflygplats.— Flygplanstyp.— Flygväg (valfritt).— Annan färdplansdata (valfritt).
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
7.2.3. Tillämpningsregler
7.2.3.1. Allmänt7.2.3.1.1. Ett eller flera PAC-meddelanden skall sändas för varje flygning
som är planerad att korsa gränsen för ansvarsområden då tiden
från avgång till COP inte skulle tillåta ACT-meddelandet att
sändas vid erforderlig tidpunkt.
7.2.3.1.2. Ett eller flera PAC-meddelanden skall sändas av enheten för flyg-
plats-/inflygningskontroll till nästa enhet för varje avgående
flygning där antingen underrättelse eller samordning krävs.
7.2.3.1.3. Rekommendation För genomförandet av PAC/LAM mellan
enheter, bör TWR/APP-systemet i fråga förses med möjligheter
att registrera och sända ”start-up”, ”push-back”, ”taxi” eller
liknande information från vilken ETOT kan härledas för beräk-
ning av ETO vid COP samt initiering av sändandet av PAC.2000R2082 — SV — 15.06.2002 — 001.001 — 29
▼B
7.2.3.1.4. Enligt bilateral överenskommelse skall meddelandet innehålla
antingen
— beräknad starttid,
eller
— beräknad data.
7.2.3.1.5. När meddelandereferensen ingår skall den, enligt bilateral
överenskommelse,
— innehålla meddelandenumret på det första PAC-meddelandet
som skickats för flygningen,
— inkluderas i andra och efterföljande PAC-meddelanden.
7.2.3.1.6. Användandet av funktionen kodbegäran, om sådan erfordras, skall
vara bilateralt överenskommet.
7.2.3.1.7. Ett ändrat PAC-meddelande skall sändas om något av följande
förhållanden råder före avgång:
— Flygvägen har ändrats så att COP i tidigare meddelande ej
längre är korrekt.
— Flygplanstypen har ändrats.
— Landningsflygplatsen i föregående PAC har befunnits vara
fel.
7.2.3.1.8. Rekommendation Ett ändrat PAC-meddelande bör sändas om,
före avgång, följande data avviker från datan i det föregående
PAC-meddelandet:
—Nivån (i beräknad data, om befintlig) .
—Den förväntade SSR-koden vid punkten för kontrollöverföring .
—Den beräknade starttiden eller ETO vid COP i tid överstiger
ett bilateralt överenskommet värde .
—Det förekommer ändring av någon annan data som är bilate-
ralt överenskommen .
7.2.3.2. Behandling i den mottagande enheten7.2.3.2.1. Det ATC-system som tar emot ett ACT-meddelande skall försöka
ansluta till den berörda färdplanen.
7.2.3.2.2. Om en berörd färdplan påträffas och inga avvikelser förekommer
i meddelandet som skulle förhindra korrekt behandling skall
— det operativa innehållet inkluderas i färdplanen,
— erforderlig data föras ut till operativ ATC och andra tillämp-
liga stationer,
— ett LAM återsändas.
7.2.3.2.3. Om en berörd färdplan inte kan påträffas, eller om en avvikelse
som förhindrar korrekt behandling av meddelandet påträffas skall,
— om sektorn ansvarig för att acceptera kontroll över flygningen
kan identifieras,
— det operativa innehållet i meddelandet visas vid sektorn,
— ett LAM återsändas,— en färdplan skapas,
— i alla övriga fall skall ett LAM inte återsändas.
7.2.3.2.4. Datan i ett andra eller efterföljande PAC-meddelande skall ersätta
datan i det föregående meddelandet.
7.2.3.2.5. Om PAC-meddelandet innehåller en begäran om tilldelning av en
SSR-kod, och det är korrekt behandlingsbart enligt beskrivningen
i punkt 7.2.3.2.2 ovan, skall ett COD-meddelande återsändas
utöver LAM.
ANMÄRKNING Eftersom processen för kodtilldelning kräver
detaljerad flygvägsinformation från färdplanen,
ställs inga krav i detta dokument för återsän-
dande av ett COD-meddelande från den
mottagande enheten då sådan data kanske inte
finns tillgänglig för flygningen. Detta
förhindrar inte att ett meddelande återsänds
under sådana omständigheter om en specifik
lokal kapacitet finns och förfarandet är bilate-
ralt överenskommet.2000R2082 — SV — 15.06.2002 — 001.001 — 30
▼B
7.2.3.3. Tidsparametrar för sändning
En tidsparameter för sändning är inte tillämplig då meddelandet
har sänts som ett resultat av ett manuellt infört meddelande som
informerar om den omedelbart förestående avgången.
7.2.4. Bekräftelse av ett PAC
7.2.4.1. Bekräftelse
De meddelanden som skall sändas som svar på ett PAC-medde-
lande beskrivs i punkt 7.2.3.2 ovan.
7.2.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som bekräftelse på ett
PAC-meddelande, skall en varning visas vid arbetsstationen hos
den ATC-enhet som är ansvarig för samordning med nästa enhet.
7.2.4.3. Avsaknad av LAM
Vid de tillfällen då LAM ej mottagits skall muntlig samordning
ske.
7.2.4.4. Avsaknad av COD-meddelande
7.2.4.4.1. Om inget COD-meddelande tas emot som svar på en kodbegäran,
skall en varning visas vid berörd arbetsstation.
7.2.4.4.2. Då funktionen för kodbegäran skall användas, skall det värde på
avbrottstid som används vara bilateralt överenskommet.
7.2.5. Exempel
7.2.5.1. Beräknad starttid och kodbegäran7.2.5.1.1. ICAO
(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)
7.2.5.1.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC
SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP
LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA
7.2.5.2. Tid vid COP
7.2.5.2.1. ICAO
(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-
EBBR-9/B737/M)
7.2.5.2.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP
EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL
F110A -ARCTYP B737 -ADES EBBR
7.3. Ändringsmeddelande (REV)
7.3.1. Syfte med ändringsmeddelandet
REV-meddelandet används för att sända ändringar i samordnings-
data som tidigare avsänts i ett ACT-meddelande, under
förutsättning att den mottagande enheten inte ändras som ett
resultat av ändringen.
7.3.2. Meddelandeinnehåll
REV-meddelandet skall innehålla följande data:
— Meddelandetyp
— Meddelandenummer
— Luftfartygsidentifiering
— Startflygplats
— Beräknad data och/eller samordningspunkt
— Landningsflygplats— Meddelandereferens (valfritt)
— SSR-läge och -kod (valfritt)
— Flygväg (valfritt)— Utrustningens kapacitet och status (valfritt)2000R2082 — SV — 15.06.2002 — 001.001 — 31
▼M1
▼M1
ANMÄRKNING: Regler för införande av data, format och
fältinnehåll beskrivs i bilaga A.
7.3.3. Tillämpningsregler
7.3.3.1. Allmänt
7.3.3.1.1. Ett eller flera REV-meddelanden kan sändas till den enhet till
vilken samordningen av flygningen för tillfället är förlagd, genom
användandet av ett aktiveringsmeddelande.
7.3.3.1.2. Följande element skall vara föremål för ändring:
— ETO vid COP
— Överföringsnivå(er)— SSR-kod— Utrustningens kapacitet och status
7.3.3.1.3. Ett REV-meddelande skall sändas när
— ETO vid COP avviker från den i det tidigare meddelandet
med mer än ett värde som är bilateralt överenskommet,
avrundat till närmaste heltal,
— ändringar av överföringsnivå(erna), SSR-kod eller utrust-
ningens kapacitet och status görs.
7.3.3.1.4. När det är bilateralt överenskommet, skall ett REV-meddelande
sändas då något av följande ändras:
— COP
— Flygväg
ANMÄRKNING: Operativa regler kan kräva att ändringar
utförda efter ACT skall vara föremål för tidi-
gare samordning mellan berörda enheter.
7.3.3.1.5. När det är bilateralt överenskommet, skall meddelandereferensen
ingå i REV-meddelandet.
7.3.3.1.6. Meddelandereferensen, då sådan är inkluderad, skall innehålla
meddelandenumret på föregående ACT-meddelande.
7.3.3.1.7. Godkännande av överföringsförhållandena, som framgår av REV-
meddelandet, skall ske av den mottagande enheten, om inte den
mottagande enheten initierar samordning för att ändra dessa.
7.3.3.2. Format på ändringsmeddelanden
7.3.3.2.1. ICAO-format
Alla ändringsmeddelanden innehåller fälttyper 3, 7, 13, 14 och
16. Följande regler gäller:
— En ändring av ETO vid COP eller överföringsnivå(er) skall
införas genom att ändrad data förs in i fält 14.
— En ändring av SSR-koden skall införas som element (b) och
(c) av fält 7.
Alla övriga ändringar skall införas i fält 22-format efter de fem
första fälten. Följande regler gäller:
— Valfri ordningsföljd gäller för fält införda i fält 22-format.
— Ändringar av COP skall införas som fält 14-data i fält 22-
format (se bilaga B, ”Krav för behandling av speciella
flygvägar”).
— Flygvägsändringar skall införas som fält 15-data i fält 22-
format. Regler för samordningen av sådana ändringar, inklu-
sive direkta flygvägar, är specificerade i bilaga B, ”Krav för
behandling av speciella flygvägar”.
— Utrustningens kapacitet och status. Endast kapacitetsändringar
skall införas. Ett meddelande om ändrad kapacitet, som
nödvändiggör införande av data om ytterligare kapacitet enligt
punkt A.30 i bilaga A, skall innehålla den ytterligare kapaci-
teten.2000R2082 — SV — 15.06.2002 — 001.001 — 32
▼B
▼M1
▼B
▼M1
▼M1
7.3.3.2.2. ADEXP-format
Alla ändringsmeddelanden i ADEXP-format skall innehålla
följande primära fält: TITLE REFDATA ARCID ADEP ADES.
Följande regler gäller:
— En ändring av ETO vid COP eller överföringsnivå(erna) skall
göras genom att den ändrade datan förs in i primärt fält
COORDATA.
— Primärt fält COP skall ingå utom om en ändring av ETA eller
överföringsnivå(erna) nödvändiggör användandet av primärt
fält COORDATA. Meddelandet skall innehålla den COP
genom vilken flygningen för närvarande samordnas eller, vid
ändrad COP, den COP genom vilken flygningen tidigare
samordnades.
— Ändringar av COP skall införas med hjälp av primärt fält
COORDATA (se bilaga B, ”Krav för behandling av speciella
flygvägar”). Sådana meddelanden skall också inkludera
primärt fält COP enligt ovan.
— Flygvägsändringar skall införas med hjälp av primärt fält
ROUTE. Regler för samordningen av sådana ändringar, inklu-
sive direkta flygvägar, är specificerade i bilaga B, ”Krav för
behandling av speciella flygvägar”.
— En ändring av SSR-koden skall indikeras genom inkluderande
av primärt fält SSRCODE.
— För en ändring av utrustningens kapacitet och status skall
primärt fält EQCST användas. Endast kapacitetsändringar
skall införas. Ett meddelande om ändrad kapacitet, som
nödvändiggör införande av data om ytterligare kapacitet enligt
punkt A.30 i bilaga A, skall innehålla den ytterligare kapaci-
teten.
7.3.3.2.3. SSR-kod
SSR-läge och -kod skall ingå i ett REV-meddelande endast då det
krävs för att samordna en ändring av SSR-kod.
7.3.3.3. Behandling i den mottagande enheten
7.3.3.3.1. Om ett ACT har emottagits för berörd flygning från samma ATC-
enhet, skall ATC-systemet som tar emot ett REV-meddelande
försöka ansluta till den berörda färdplanen.
7.3.3.3.2. Om en motsvarande färdplan hittas, och ingen avvikelse som
skulle förhindra behandlingen finns i meddelandet, skall
— det operativa innehållet inkluderas i färdplanen,
— erforderlig data föras ut till operativ ATC och andra tillämp-
liga stationer.
7.3.3.4. Initiering av sändning
7.3.3.4.1. REV-meddelandet är händelsestyrt och skall sändas omedelbart
efter relevant inläsning eller uppdatering.
7.3.3.4.2. Inga ändringar får genomföras genom användandet av REV-
meddelandet sedan flygningen befinner sig inom fastställd tids-
rymd eller fastställt avstånd från överföringspunkten.
Parametrarna för tid och avstånd skall vara bilateralt överens-
komna.
7.3.3.4.3. Rekommendation REV-parametrarna bör definieras separat för
varje COP.
7.3.3.5. Förändring av mottagande ATC-enhet
REV-meddelandet skall inte användas om en ändring av
färdplansdata leder till en förändring av den mottagande ATC-
enheten (se Meddelande om upphävande av samordning).
7.3.4. Bekräftelse av ett REV
7.3.4.1. Bekräftelse
Om REV-meddelandet
— kan anslutas till en färdplan i det mottagande systemet skall
ett LAM-meddelande sändas som bekräftelse,
— inte kan anslutas till en färdplan i det mottagande systemet
skall ett LAM-meddelande inte sändas.2000R2082 — SV — 15.06.2002 — 001.001 — 33
▼B
▼B
7.3.4.2. Tillfällen utan bekräftelse
7.3.4.2.1. Om inget LAM-meddelande tas emot som bekräftelse på ett
REV-meddelande, skall en varning visas vid arbetsstationen hos
den ATC-enhet som är ansvarig för samordning med nästa enhet.
7.3.4.2.2. Vid de tillfällen då LAM ej mottagits skall muntlig samordning
ske
7.3.5. Exempel
7.3.5.1. ICAO
a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
EGBB)
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. ADEXP
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) -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. Meddelande om upphävande av samordning (MAC)
7.4.1. Syfte med MAC-meddelandet
Ett MAC-meddelande används för att påvisa för till den motta-
gande enheten att samordningen eller underrättelse som tidigare
berört en flygning upphävs.
MAC är inte en ersättning för ett annulleringsmeddelande (CNL),
som det definieras av ICAO, och skall därför inte användas för att
radera grundläggande färdplansdata.
7.4.2. Meddelandeinnehåll
MAC-meddelandet skall innehåla följande data:
— Meddelandetyp.
— Meddelandenummer.— Meddelandereferens (valfritt).
— Flygplansidentifiering.
— Startflygplats.— Samordningspunkt.— Landningsflygplats.— Samordningsstatus och anledning (valfritt).
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
7.4.3. Tillämpningsregler
7.4.3.1. Allmänt7.4.3.1.1. Ett MAC-meddelande skall sändas till en enhet vid vilken
samordning tidigare skett för en flygning, genom användandet av
ett ACT- eller RAP-meddelande, när något av följande inträffar:
— Den förväntade nivån vid överföringspunkten är annorlunda
än den nivå som angivits i föregående meddelande, vilket2000R2082 — SV — 15.06.2002 — 001.001 — 34
▼M1
▼B
▼B
resulterar i en förändring av nästa enhet i samordningsse-
kvensen.
— Flygvägen har ändrats vilket resulterar i förändring av nästa
enhet i samordningssekvensen.
— Systemfärdplanen är annullerad i den sändande enheten och
samordningen är inte längre relevant.
— Ett MAC tas emot från den föregående enheten kopplad till
flygningen.
7.4.3.1.2. När MAC-meddelandet sänds på grund av en förändring av
flygnivå eller flygväg, skall underrättelse och/eller samordning,
vilket som är tillämpligt, upprättas med den nya enheten i
samordningssekvensen.
7.4.3.1.3. Ett MAC-meddelande skall sändas när samordningen för en
avgående flygning, påverkad av användandet av ett PAC-medde-
lande, är upphävd.
7.4.3.1.4. Rekommendation Ett MAC-meddelande bör sändas när under-
rättelsen (ABI-meddelande) tidigare verkställd för en flygning är
annullerad beroende på någon av orsakerna beskrivna i punkt
7.4.3.1.1 ovan, eller om flygningen är försenad under färden och
en ändrad beräkning inte kan göras automatiskt.
7.4.3.1.5. En meddelandereferens skall inkluderas om så är bilateralt
överenskommet.
7.4.3.1.6. Om den ingår, skall meddelandereferensen innehålla meddelande-
numret för det senaste ABI-, PAC- eller ACT-meddelandet sänt
och bekräftat för flygningen.
7.4.3.1.7. Samordningspunkten skall vara den COP genom vilken flyg-
ningen tidigare hade underrättats om eller samordnats.
7.4.3.1.8. Rekommendation MAC-meddelandet bör identifiera den status
till vilken samordningen eller underrättelsen skall återgå samt
orsaken till upphävandet.
7.4.3.1.9. Om inkluderad, skall statusen och anledningen vara en av
följande kombinationer:
— När den mottagande enheten ej längre är nästa samordnings-
partner.
— Statusen är INI (initial).
— Anledningen är en av följande:
— TFL om anledningen är en förändring av överföri-
ngsnivån.
— RTE om anledningen är en förändring av flygvägen.— CSN om anledningen är en förändring av callsign.— CAN om anledningen är en annullering.— OTH för alla andra anledningar eller om orsaken är
okänd.
— Om ett av följande villkor föreligger:
— Samordningen effektuerad genom användandet av det
föregående PAC- eller ACT-meddelandet (så som det
ändrats genom efterföljande REV-meddelande) är upphävt
men flygningen förväntas bli föremål för en ny samord-
ningssekvens med samma enhet.
— Efter sändandet av ett ABI-meddelande väntar flygningen
under en obestämd tidsperiod och förväntas vara föremål
för en ändrad ABI eller ACT, vilket som är tillämpligt.
— Statusen är NTF (underrättelse).
— Anledningen är en av följande:
— DLY om orsaken är en försening.
— HLD om orsaken är väntan.— OTH för alla andra orsaker, eller om orsaken är
okänd.
7.4.3.1.10. Om ny underrättelse skall ske eller ny samordning skall göras för
flygningen, skall
— ett nytt underrättelse- och/eller samordningsmeddelande,
vilket som är tillämpligt, sändas,
— grundläggande färdplansdata hos den mottagande ATC-
enheten inte påverkas av ett MAC-meddelande,2000R2082 — SV — 15.06.2002 — 001.001 — 35
▼B
— systemet bibehålla förmågan att korrekt behandla ett nytt
underrättelse- och/eller samordningsmeddelande från antingen
den tidigare överlämnande enheten eller en annan enhet i den
nya samordningssekvensen.
7.4.3.2. Behandling i den mottagande enheten
Arbetsstationen (-stationerna) i den mottagande ATC-enheten,
som förses med färddetaljer skall meddelas om upphävandet.
7.4.4. Bekräftelse av ett MAC
7.4.4.1. Bekräftelse7.4.4.1.1. Om MAC-meddelandet kan anslutas till en färdplan i det motta-
gande systemet och kan behandlas, skall ett AM-meddelande
sändas som bekräftelse.
7.4.4.1.2. Om MAC-meddelandet inte kan anslutas till en färdplan i det
mottagande systemet, skall ett LAM-meddelande inte sändas.
7.4.4.2. Tillfällen utan bekräftelse7.4.4.2.1. Om ATC-samordning upphävts och inget LAM-meddelande
mottagits, skall en varning visas vid den ATC-station som
ansvarar för samordningen.
7.4.4.2.2. I sådana fall skall muntligt upphävande av samordning utfärdas
av den överlämnande ATC-enheten.
7.4.5. Exempel
Ett ABI-meddelande skickades från Amsterdams ACC till Brys-
sels ACC för flygning HOZ3188, planerad för FL190;
flygningen begär senare tillstånd att få stiga till FL270 och
tillstånd till detta erhålls, varvid man kommer in i Maastrichts
luftrum istället för Bryssels. Exempel 7.4.5.1 a och 7.4.5.2 a visar
hur det MAC som sänds till Bryssel från Amsterdam skulle se ut
i både ICAO- och ADEXP-format.
Ett ABI- och, senare, ett ACT-meddelande sänds till Maastricht,
men några minuter innan COP nås, återvänder flygplanet till
Amsterdams flygplats och färdplanen annulleras i den sändande
enhetens system; ett MAC skickas till Maastricht som visas i
exemplen (7.4.5.1 b and 7.4.5.2 b).
7.4.5.1. ICAO
a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/
INITFL)
b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/
INICAN)
7.4.5.2. ADEXP
a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON TFL
b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -
STATREASON CAN
7.5. Meddelande om tilldelning av SSR-kod (COD)
7.5.1. Syfte med COD-meddelandet
7.5.1.1. Metoden för tilldelning av koder för ursprungsregion –(ORCAM)
tillhandahålls för att möjliggöra att en flygning kan svara på
samma kod till efterföljande enheter inom ett deltagarområde.
Om inte kodtilldelning sker centralt, t.ex. av en ACC, kan flyg-
platser komma att individuellt behöva tilldelas en uppsättning av
specifika SSR-koder. Sådan tilldelning är ett slöseri med koder.
7.5.1.2. COD-meddelandet möter de operativa kraven på utfärdandet av
en SSR-kod, läge A, av en flygtrafikledningsenhet till en annan
för en specifikflygning när så begärs. En valfri funk tion tillåter
den utfärdande enheten att inkludera flygvägen om detta är bila-
teralt överenskommet.2000R2082 — SV — 15.06.2002 — 001.001 — 36
▼B
7.5.2. Meddelandeinnehåll
COD-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.
— Meddelandereferens (valfritt).
— Flygplansidentifiering.— SSR-läge och -kod
— Startflygplats.
— Landningsflygplats.— Flygväg (valfritt).
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
7.5.3. Tillämpningsregler
7.5.3.1. Allmänt
7.5.3.1.1. Ett COD-meddelande skall genereras och sändas automatiskt som
svar på en begäran om kodtilldelning erhållen inom ett medde-
lande.
7.5.3.1.2. SSR-koden skall vara den kod som tilldelats för flygningen.
7.5.3.1.3. Den godkända mättnadskoden, enligt specifikation i flygnavige-
ringsplanen för europeiska regionen (Air Navigation Plan for the
European Region), skall användas om en specifik kod inte är
tillgänglig.
7.5.3.1.4. Om det är bilateralt överenskommet, skall meddelandereferensen,
som innehåller meddelandenumret på det meddelande till vilket
COD-meddelandet är ett svar, ingå.
7.5.3.1.5. Flygvägen skall ingå om så är bilateralt överenskommet.
7.5.3.1.6. Den enhet som emottar COD-meddelandet skall acceptera SSR-
koden.
7.5.3.2. Behandling i mottagande enhet
7.5.3.2.1. Förutsatt att det inte föreligger någon avvikelse i meddelandet
som förhindrar korrekt behandling, skall ett LAM återsändas.
7.5.3.2.2. Om inte meddelandet kan anslutas till en färdplan eller om det
förekommer en avvikelse som förhindrar korrekt behandling av
meddelandet, skall inte ett LAM återsändas.
7.5.3.2.3. Flygvägsdata, om sådan ingår, skall inte vara en anledning till att
återsändandet av ett LAM förhindras, annat än i det fall den inte
möter de formatkrav som angivits i bilaga A.
7.5.3.3. Tidsparametrar för sändning
En tidsparameter för sändning skall inte vara tillämplig, eftersom
COD-meddelandet har skickats som ett resultat av mottagandet av
ett meddelande med begäran om tilldelning av en SSR-kod.
7.5.4. Bekräftelse av ett COD
7.5.4.1. Bekräftelse
COD-meddelandet skall bekräftas genom genererandet och
sändandet av ett LAM-meddelande.
7.5.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som en bekräftelse på ett
COD-meddelande, skall en varning visas vid lämplig station.
7.5.5. Exempel
7.5.5.1. ICAO
(CODP/PO011-AAL905/A0767-LFPO-KEWR)
7.5.5.2. ADEXP
-TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO
-SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905
-SSRCODE A07672000R2082 — SV — 15.06.2002 — 001.001 — 37
▼B
7.6. Informationsmeddelande (INF)
7.6.1. Syfte med INF-meddelandet
7.6.1.1. INF-meddelandet används för att tillhandahålla information om
specifika flygningar till organ som inte är direkt inblandade i
samordningsprocessen mellan två efterföljande ATC-enheter
längs flygvägen.
7.6.1.2. INF-meddelandet kan användas för att tillhandahålla kopior av
meddelanden och för att meddela överenskomna samordnings-
förhållanden till sådana organ efter en dialog mellan flygledare.
I detta syfte kan INF-meddelanden genereras av systemen vid
den överlämnande eller mottagande enheten.
7.6.1.3. Meddelandet kan även användas för att lämna information
rörande vilken som helst av punkterna längs flygvägen till ett
organ.
7.6.1.4. Formatet medger kommunikation av ursprungsdata, ändringar och
annulleringar.
7.6.2. Meddelandeinnehåll
INF-meddelandet skall innehålla följande data i det meddelande-
format som beskrivs i detta dokument:
— Meddelandetyp.
— Meddelandenummer.
— All operativ data som ingicki det ursprungliga meddelandet
eller kopiering av resulterande samordning.
— Hänvisad meddelandetyp.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
7.6.3. Tillämpningsregler
7.6.3.1. Meddelandetyper
Typen (typerna) av meddelande(n) som skall dupliceras genom
INF-meddelanden baseras på användares krav och sändande
enhets kapacitet. Typ(er) av meddelande(n) och tillämpnings-
regler är i allmänhet bilateralt överenskomna.
7.6.3.2. Meddelandeadressater
Ett eller flera INF-meddelande(n) kan sändas för samma flygning
till en eller flera adressater.
7.6.3.3. Operativt innehåll
Det operativa innehållet i INF-meddelandet skall vara i samma
format som ett av de befintliga meddelandena.
7.6.3.4. Rekommendationer
1.Förhållanden framförda i ett ursprungligt dialogmeddelande
(t.ex. ACT-, RAP-, REV- eller RRV-meddelande) kan ändras
eller förkastas innan dialogen är slutförd. Avsändande enheter
bör ha möjlighet att vidarebefordra de slutgiltigt överens-
komna samordningsförhållandena .
2.INF-meddelandet bör sändas omedelbart, eller vid en tidpunkt
i förhållande till tiden vid COP vilken har överenskommits
bilateralt med det mottagande organet .
7.6.4. Bekräftelse av ett INF
Rekommendationer1.INF-meddelandet kan bekräftas, beroende på samordnings-
partnern, genom genererandet och sändandet av ett LAM-
meddelande .
2.Beroende på bilateral överenskommelse mellan berörda
enheter, skall en varning visas vid en lämplig station om inget
LAM-meddelande har emottagits som bekräftelse på ett INF-
meddelande .
7.6.5. Exempel
En flygning med callsign BAW011, B747 från EGLL till OMDB
vid FL290, begärande FL410, är beräknad Koksy (KOK) VOR
vid 1905, sändande på A5437, fortsätter via UG1 och UB6.2000R2082 — SV — 15.06.2002 — 001.001 — 38
▼B
Ett ACT-meddelande skickas av London till Maastricht för flyg-
ningen. En kopia skicka från London till en enhet identifierad
som IT.
Det följande ger ett exempel på INF-meddelandet.
7.6.5.1. ICAO
(INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/
B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/
MSG/ACT)
7.6.5.2. ADEXP
-TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -
SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP
EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES
OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK
NTM UB6 KRH -MSGTYP ACT
8. DIALOGFÖRFARANDEN — SAMORDNING
8.1. Allmänt
8.1.1. Inledning
8.1.1.1. Dialogförfarandet ger möjlighet till kommunikation och förhand-
lingar mellan trafikledare under samordningsfasen och för
kommunikation i överföringsfasen.
8.1.1.2. Detta avsnitt beskriver meddelanden som används i dialogförfa-
randet under samordningsfasen där förhållandena för överföring
planeras. De meddelanden som används för överföringsfasen, där
överlämningen av flygningen sker, beskrivs i avsnitt 9, Dialogför-
faranden — Överföring av kommunikationen.
8.1.1.3. Förfarandena för de två faserna är oberoende av varandra. De kan
utföras individuellt eller tillsammans.
8.1.1.4. Ytterligare ett antal meddelanden har införts och möjligheten för
endera partnern att initiera en dialog stöds.
8.1.1.5. Dialogförfarandet för samordning innebär att följande kan identi-
fieras:
— Överföringar som överensstämmer med LoA och kan accep-
teras automatiskt.
— Överföringar som måste remitteras till flygledaren vid den
mottagande enheten för ett beslut om godkännande.
8.1.1.6. Detta förfarande möjliggör även övervakning av tolkningen av
skriftliga överenskommelser inom de två systemen, och identifi-
ering av varje avvikelse mellan dessa.
8.1.2. Filtret
8.1.2.1. Allmänt8.1.2.1.1. Dialogförfarandet för samordning kräver att systemen fastställer
huruvida överföringarna överensstämmer med LoA eller ej.
8.1.2.1.2. Processen som kontrollerar att detta tillmötesgås, hänvisas till i
detta dokument som ”filtret”. Databasen som används till filtret
innehåller följande, om så erfordras:
— Överenskomna samordningspunkter.
— Tillåtna (eller otillåtna) flygnivåer som också kan vara associ-
erade med samordningspunkterna.
— Startflygplatser.— Destinationer.
— Överenskomna direkta flygvägar.
— Tids- och/eller avståndsgränser före COP, efter vilka alla
samordningsmeddelanden betraktas som onormala.
— Alla andra förhållanden, enligt bilateral överenskommelse.
8.1.2.1.3. Alla punkter på denna lista kan kombineras för att definiera mer
komplicerade förhållanden.
8.1.2.1.4. Inom avsnitt 8 i detta dokument, skall begreppet ”normala
förhållanden” tolkas som ”i överensstämmelse med LoA” och
begreppet ”onormala förhållanden” som ”ej i överensstämmelse
med LoA”. Om inte annat är bilateralt överenskommet, skall2000R2082 — SV — 15.06.2002 — 001.001 — 39
▼B
man för meddelanden som sänds av överlämnande enheter för
samordningar som är normala, använda andra meddelandetyper
än för samordningar där förhållandena är onormala.
8.1.2.2. Åtgärd i den överlämnande enheten8.1.2.2.1. Filtret i den överlämnande enheten skall granska överföri-
ngsförhållandena som skall sändas till den accepterande enheten.
8.1.2.2.2. Rekommendation Om överföringsförhållandena befinns vara
onormala, bör den överlämnande flygledaren uppmärksammas
på detta faktum för bekräftelse eller ändring.
8.1.2.3. Åtgärd i den accepterande enheten
8.1.2.3.1. Alla ACT- och REV-meddelanden skall kontrolleras gentemot
filtret.
8.1.2.3.2. Om kontrollen indikerar att de mottagna överföringsförhållandena
är onormala, skall dessa remitteras till flygledaren för ett beslut,
annars kommer de att accepteras automatiskt.
8.1.2.4. Synkronisering av filtren8.1.2.4.1. Användandet av olika meddelanden för normala och onormala
överföringsförhållanden medger identifiering av alla avvikelser
mellan normalförhållandena som de är inlästa i systemen hos
den överlämnande och den accepterande enheten.
8.1.2.4.2. Identifieringen hos den accepterande enheten av onormala
överföringsförhållanden i ett meddelande som används för att
samordna endast normalöverföringar innebär att det finns en avvi-
kelse mellan de två filtren. Sådana avvikelser bör lösas för att
dialogförfarandet skall fungera effektivt.
8.1.3. Meddelandeföljd
8.1.3.1. Allmänt
8.1.3.1.1. Vissa regler måste följas för att säkerställa att samordningen är
fullständig innan några ändringar sker eller utväxling av medde-
landen om överföring av kommunikationen äger rum, och även
för att säkerställa att flygledare vid båda enheterna inte samtidigt
lämnar förslag till samma flygning.
8.1.3.1.2. En ATC-enhet skall endast sända eller bekräfta meddelande om
mottagande av ändring (REV eller RRV) för en flygning då den
befinner sig i det samordnade tillståndet, dvs. en ACT- eller
RAP-dialog har avslutats med ett LAM eller ACP.
8.1.3.1.3. CDN-meddelanden skall endast tillåtas för sändningar av den
accepterande enheten.
8.1.3.1.4. CDN-meddelanden skall endast sändas och bekräftas
— som del av dialogen initierad genom mottagandet av ett akti-
verings- (ACT, RAP) eller ändrings- (REV eller RRV)
meddelande, eller
— då färdplanen för den flygningen befinner sig i det samord-
nade tillståndet.
8.1.4. Samtidig meddelandehantering
8.1.4.1. Allmänt
8.1.4.1.1. En enhet som är inblandad i en samordning av en utväxling av
samordnings- eller överföringsmeddelanden för en flygning skall
inte initiera ytterligare ett samordnings- eller överföringsmedde-
lande för samma flygning med samma enhet förrän antingen ett
LAM, ACP eller RJC har mottagits, eller en tidsbegränsning har
uppnåtts.
8.1.4.1.2. Det är möjligt för ett CDN-meddelande och ett REV-, RRV- eller
MAC-meddelande för samma flygning skickat från den överläm-
nande enheten att mötas korsvis under vägen. Denna situation kan
identifieras vid den överlämnandeenheten genom att CDN
inkommer före bekräftelsen för det sända meddelandet, och vid
den accepterande enheten genom att meddelandet från den
överlämnande enheten anländer före bekräftelsen av CDN. I detta
fall skall inte CDN bekräftas och ej heller REV, RRV eller MAC
behandlas.2000R2082 — SV — 15.06.2002 — 001.001 — 40
▼B
8.1.5. Hantering av avslag
RJC-meddelandet avslutar en systemdialog. En ny systemsamord-
ning som återspeglar telefonsamordningen måste initieras där så
är tillämpligt.
8.1.6. Tidsbegränsning av operativt svar
8.1.6.1. Allmänt8.1.6.1.1. Ett tidsbegränsningssystem skall tillämpas vid de sändande och
mottagande centralerna för svaret på meddelanden som har remit-
terats till flygledaren.
8.1.6.1.2. Varaktigheten på dessa tidsbegränsningar skall vara bilateralt
överenskommen.
8.1.6.1.3. Utgången av tidsbegränsningen vid den överlämnande enheten
skall resultera i att en varning utfärdas till den överlämnande
flygledaren, som en anvisning på behovet att påbörja samordning
via telefon.
8.1.6.1.4. Rekommendationer
1.En varning bör visas vid ATC-stationen vid den accepterande
enheten ansvarig för flygningen, när utgången av tidsbegräns-
ningen i den överlämnande enheten är omedelbart
förestående .
2.Varningen bör ta hänsyn till sändningstiden för svaret .
8.1.6.1.5. System skall kunna behandla svar som mottagits efter tids-
begränsningens utgång.
8.1.7. Genomförande
8.1.7.1. Dialogförfarandena berör två faser, nämligen samordningsfasen
och överföringsfasen. Dialogen i de två faserna använder olika
meddelanden och de erforderliga transaktionstiderna är olika.
Samordningsmeddelandena är specificerade i ICAO- och
ADEXP-format, meddelandena för överföring av kommunika-
tionen endast i ADEXP.
8.1.7.2. HMI-minimikraven för samordningsdialogen skiljer sig från
kraven för överföringsdialogen:
— Överföringsdialogen berör i första hand den verkställande
kontrollfunktionen och kräver ett snabbt och användarvänligt
HMI.
— Samordningsdialogen är inte lika tidskritisk och därför är dess
HMI-krav lägre ställda.
8.1.7.3. Dialogförfarandet skall genomföras genom användandet av ett av
följande alternativa scenarier:
— Dialogförfarande för samordningsfas och alla kompletterande
meddelanden enligt bilateral överenskommelse (avsnitt 7 och
8).
— Grundläggande samordningsförfarande och dialogförfarande
för överföring (avsnitt 6, 7 och 9).
— Förfarande för samordnings- och överföringsfas samt alla
kompletterande samordningsmeddelanden enligt bilateral
överenskommelse (avsnitt 7, 8 och 9).
Förhandsmeddelandet med gränsinformation skall sändas för alla
scenarier.
8.1.7.4. Scenariot som används för genomförandet skall överenskommas
bilateralt.
8.2. Aktiveringsmeddelande (ACT)
8.2.1. Syfte med ACT-meddelandet
Syftet med ACT-meddelandet beskrivs i punkt 6.3.1. I ett
dialogförfarande används ACT-meddelandet för att möta dessa
krav om överföringsförhållandena för flygningen är normala och
den överlämnande flygledaren inte behöver hänvisa flygningen
till den accepterande flygledaren för godkännande.2000R2082 — SV — 15.06.2002 — 001.001 — 41
▼B
8.2.2. Meddelandeinnehåll
Innehållet i ett ACT-meddelande som används i dialogförfarandet
skall överensstämma med beskrivningen för ACT-meddelanden i
punkt 6.3.2.
8.2.3. Tillämpningsregler
8.2.3.1. Allmänt
8.2.3.1.1. Tillämpningsreglerna är desamma som de beskrivna för ACT i
punkt 6.3, med undantag av de särskilda regler som beskrivs i
denna punkt.
8.2.3.1.2. Ett ACT-meddelande skall sändas för en flygning med normala
överföringsförhållanden som den överlämnande flygledaren inte
behöver remittera till den mottagande flygledaren.
ANMÄRKNING Om dessa krav inte är tillämpliga, sänds ett
RAP (se punkt 8.3, Meddelande med remitterat
aktiveringsförslag).
8.2.3.1.3. Rekommendation Ett nytt samordningsförfarande bör påbörjas
om ett meddelande med avslag av samordning (RJC) återsändas
som svar på ett ACT-meddelande.
8.2.3.2. Behandling i den mottagande enheten
8.2.3.2.1. Meddelandet kontrolleras mot filtret för att bekräfta att de föres-
lagna förhållandena är normala.
8.2.3.2.2. Meddelandet skall behandlas som ett RAP-meddelande om
— överföringsförhållandena befinns vara onormala,
— en motsvarande färdplan inte kan påträffas och det finns
otillräckligt med information tillgänglig för att identifiera om
överföringsvillkoren är normala eller ej.
8.2.3.2.3. Ett ACT-meddelande som befunnits vara normalt skall behandlas
enligt punkt 6.3.3.2.
8.2.3.2.4. Rekommendation Om överföringsförhållandena i ett ACT-
meddelande befunnits vara onormala, finns en avvikelse mellan
filtren i de två systemen. Det faktum att ett ACT är onormalt skall
uppmärksammas för övervakande personal för att avvikelsen skall
lösas.
8.2.4. Bekräftelse av ett ACT
8.2.4.1. Bekräftelse
8.2.4.1.1. I ett dialogförfarande skall ett ACT-meddelande bekräftas med
— ett LAM om överföringsförhållandena befunnits vara normala,
— ett SBY-meddelande i alla övriga fall.
8.2.4.1.2. När ett LAM har mottagits, skall det operativa innehållet i ACT-
meddelandet bli operativt bindande för båda ATC-enheterna.
8.2.4.1.3. När det är bilateralt överenskommet, kan ett ACP användas av
den accepterande enheten i stället för ett LAM för att ange
godkännandet av ett ACT som innehåller normala överföri-
ngsförhållanden.
8.2.4.2. Tillfällen utan bekräftelse
Om ingen bekräftelse på ett ACT-meddelande tas emot, skall en
varning visas vid den ATC-station som är ansvarig för samord-
ningen av flygningen.
8.3. Meddelande med remitterat aktiveringsförslag (RAP)
8.3.1. Syfte med RAP-meddelandet
RAP-meddelandet möter följande operativa krav, utöver de som
fastställts för ACT-meddelandet i punkt 6.3:
— Förslag från den överlämnande flygledaren och remiss till den
mottagande flygledaren för flygningar där förhållandena är
onormala.
— Möjliggör för den överlämnande flygledaren, om så erfordras,
att tvångsremittera överföringsförhållandena för en bestämd
flygning där normala förhållanden föreligger, till den motta-
gande flygledaren.2000R2082 — SV — 15.06.2002 — 001.001 — 42
▼B
8.3.2. Meddelandeinnehåll
Innehållet i ett RAP-meddelande skall vara samma data som
beskrivits för ACT-meddelandet (punkt 6.3), och kan valfritt
innehålla följande data:
— Anledning, med anvisning om manuell remittering (endast
tillgängligt i ADEXP).
8.3.3. Tillämpningsregler
8.3.3.1. Allmänt8.3.3.1.1. Ett RAP-meddelande skall sändas i stället för ACT-meddelandet
för flygningar som korsar gränsen och uppfyller ett av följande
villkor:
— Det överlämnande systemet har konstaterat att överföri-
ngsförhållandena är onormala.
— Den överlämnande flygledaren har angivit att de föreslagna
överföringsförhållandena skall remitteras till den mottagande
flygledaren.
8.3.3.1.2. Det operativa innehållet i RAP-meddelandet som skall sändas,
skall visas hos den befattningshavare som ansvarar för samord-
ningen av flygningen, innan sändningen äger rum.
8.3.3.1.3. Rekommendation Tidpunkten då RAP-meddelandet automatiskt
sänts, bör visas tillsammans med meddelandets innehåll.
8.3.3.1.4. Berörd befattningshavare skall informeras om sändandet av RAP-
meddelandet.
8.3.3.2. Behandling i den mottagande enheten8.3.3.2.1. ATC-systemet som tar emot ett RAP-meddelande skall försöka
ansluta till den berörda färdplanen.
8.3.3.2.2. Om en motsvarande färdplan påträffas och det inte förekommer
någon avvikelse i meddelandet som skulle kunna förhindra
korrekt behandling, skall
— det operativa innehållet remitteras till den mottagande flygle-
daren,
— ett SBY återsändas.
8.3.3.2.3. Rekommendation En anvisning om anledningen till remitter-
ingen (onormala förhållanden eller manuell remittering) bör
inkluderas.
8.3.3.2.4. Om meddelandet inte kan kopplas till en färdplan, eller om en
avvikelse påträffas som förhindrar korrekt behandling av medde-
landet, skall
— det operativa innehållet i meddelandet visas vid sektorn
och
— ett SBY-meddelande återsändas
och
— en färdplan upprättas.
8.3.3.2.5. I alla andra fall skall meddelandet inte bekräftas.8.3.3.3. Manuell aktivering
8.3.3.3.1. När ett RAP används för att tvångsremittera en föreslagen
samordning med normala överföringsförhållanden till den motta-
gande flygledaren, initieras det manuellt av den överlämnande
flygledaren och sänds omgående.
8.3.3.3.2. Rekommendation Manuell aktivering av ett RAP-meddelande
före den beräknade tidpunkten för sändning bör tillåtas vid den
ATC-station som har ansvaret för samordningen av flygningen.
8.3.3.4. Tidsparametrar för automatisksändning
Tiden/avståndet till gränsen, vid vilken RAP-meddelanden auto-
matiskt sänds, skall vara samma som för ACT-meddelanden.
8.3.4. Bekräftelse av ett RAP
8.3.4.1. Bekräftelse
Meddelandet skall bekräftas genom genererandet och sändandet
av ett SBY-meddelande.2000R2082 — SV — 15.06.2002 — 001.001 — 43
▼B
8.3.4.2. Tillfällen utan bekräftelse
Om inget SBY-meddelande har mottagits som bekräftelse på ett
RAP-meddelande, skall en varning visas vid den ATC-station
som har ansvaret för samordningen av flygningen.
8.3.5. Operativt svar på ett RAP
Den mottagande flygledaren kan antingen acceptera, ge ett
motförslag till eller avslå överföringsförhållandena.
8.3.5.1. Godkännande
8.3.5.1.1. När den mottagande flygledaren väljer att godkänna de föreslagna
överföringsförhållandena, skall ett ACP-meddelande återsändas.
8.3.5.1.2. Så snart ACP-meddelandet har mottagits, blir RAP-meddelandet
operativt bindande för båda ATC-enheterna. De samordnade
överföringsförhållandena och det faktum att ett ACP har motta-
gits skall presenteras för den överlämnande flygledaren.
8.3.5.2. Motförslag
När den mottagande flygledaren väljer att presentera ett motför-
slag med överföringsförhållanden, skall ett CDN-meddelande
återsändas.
8.3.5.3. Rekommendation När den mottagande flygledaren väljer att
avslå överföringsförhållandena, skall ett RJC-meddelande
återsändas. Ett nytt samordningsförfarande bör därefter påbörjas.
ANMÄRKNING Beträffande rekommendationen i 8.3.5.3 sker
den nya samordningen i de flesta fall med en
annan enhet.
8.3.6. Exempel
8.3.6.1. ICAO
(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M)
8.3.6.2. ADEXP
-TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP
LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADESEGBB -ARCTYP B757
8.4. Ändringsmeddelande (REV)
8.4.1. Syfte med REV-meddelandet
Syftet med REV-meddelandet beskrivs i punkt 7.3.1. I ett
dialogförfarande används REV-meddelandet för att möta dessa
krav förutsatt att överföringsförhållandena för flygningen är
normala och att den överlämnande flygledaren inte kräver att
remittera flygningen till den mottagande flygledaren för godkän-
nande.
8.4.2. Meddelandeinnehåll
Innehållet i REV-meddelandet skall vara som beskrivits för REV-
meddelandet i punkt 7.3.2.
8.4.3. Tillämpningsregler
8.4.3.1. Allmänt
8.4.3.1.1. Ett eller flera REV-meddelanden kan sändas till den enhet med
vilken en flygning för närvarande har samordnats, genom
användandet av ett aktiverings- eller RAP-meddelande.
8.4.3.1.2. REV-meddelanden skall sändas under de förhållanden som angi-
vits i punkt 7.3.3.1 för flygningar med normala
överföringsförhållanden som den överlämnande flygledaren inte
behöver remittera till den mottagande flygledaren.
8.4.3.2. Initiering av sändning
REV-meddelandet skall sändas omedelbart efter uppmärksam-
mandet av en ändring av samordningsdata, vilket kräver en
samordning enligt beskrivningen i punkt 7.3.3.2000R2082 — SV — 15.06.2002 — 001.001 — 44
▼B
8.4.3.3. Behandling i den mottagande enheten
8.4.3.3.1. Om en motsvarande färdplan påträffas och det inte förekommer
någon avvikelse i meddelandet som skulle kunna förhindra
korrekt behandling
— skall REV-meddelandet bekräftas,
— i alla andra fall skall meddelandet inte bekräftas.
8.4.3.3.2. Överföringsförhållandena skall undersökas för att det skall kunna
konstateras att de är normala.
8.4.3.3.3. Om överföringsförhållandena inte är normala skall de presenteras
för den mottagande flygledaren.
8.4.3.3.4. Om de föreslagna överföringsförhållandena befunnits vara
normala, skall de inkluderas i färdplanen och nödvändig
datautlämning hos operativ ATC och andra tillämpliga stationer.
8.4.3.3.5. Rekommendation Om överföringsförhållandena i ett ACT-
meddelande befunnits vara onormala, är det en avvikelse mellan
filtren i de två systemen. Det faktum att ett ACT är onormalt skall
uppmärksammats för övervakande personal för att avvikelsen
skall lösas.
8.4.4. Bekräftelse av ett REV
8.4.4.1. Bekräftelse8.4.4.1.1. Om REV-meddelandet skall bekräftas, skall detta ske genom
— ett LAM-meddelande, om överföringsförhållandena befunnits
vara normala,
— ett SBY-meddelande, om överföringsförhållandena befunnits
vara onormala.
8.4.4.1.2. När ett LAM har mottagits blir det operativa innehållet i REV-
meddelandet operativt bindande för de båda ATC-enheterna.
8.4.4.1.3. När det är bilateralt överenskommet, kan ett ACP användas i
stället för ett LAM för att ange att den mottagande enheten
godkänner mottagandet av ett REV som innehåller normala
överföringsförhållanden.
8.4.4.2. Tillfällen utan bekräftelse
Om ingen bekräftelse på ett REV-meddelande tas emot, skall en
varning visas vid den ATC-station som har ansvaret för samord-
ningen av flygningen.
8.4.5. Operativt svar på ett REV
Eftersom REV-meddelandet används till att sända normala
överföringsförhållanden, godkänns det normalt av systemet i den
mottagande enheten. Om överföringsförhållandena befinns vara
onormala av filtret i den mottagande enheten, skall meddelandet
behandlas som ett RRV-meddelande.
8.5. Remitterat ändringsmeddelande (RRV)
8.5.1. Syfte med RRV-meddelandet
RRV-meddelandet skall medge ändring av tidigare sända och
överenskomna överföringsvillkor i följande fall:
— När de föreslagna överföringsvillkoren är onormala.
— När de föreslagna överföringsvillkoren är normala, men den
överlämnande flygledaren vill remittera ändringen till den
mottagande flygledaren.
8.5.2. Meddelandeinnehåll
Innehållet i RRV-meddelandet skall vara som beskrivits för REV-
meddelandet (punkt 7.3.2), och kan valfritt innehålla följande
data:
— anledning, med anvisning om manuell remittering (endast
tillgängligt i ADEXP).2000R2082 — SV — 15.06.2002 — 001.001 — 45
▼B
8.5.3. Tillämpningsregler
8.5.3.1. Allmänt
Ett eller flera RRV-meddelanden skall sändas, i stället för REV-
meddelanden, för varje ändring om antingen
— det överlämnande systemet har fastställt att överföri-
ngsförhållandena är onormala,
eller
— den överlämnande flygledaren har påpekat att de föreslagna
överföringsförhållandena skall remitteras till den mottagande
flygledaren. Denna användning av RRV är valfri.
8.5.3.2. Initiering av sändning
REV-meddelandet skall sändas omedelbart efter uppmärksam-
mandet av en ändring av samordningsdata eller vid manuell
initiering.
8.5.3.3. Behandling i den mottagande enheten8.5.3.3.1. Om en motsvarande färdplan påträffas och det inte förekommer
någon avvikelse i meddelandet som skulle kunna förhindra
korrekt behandling
— skall RRV-meddelandet bekräftas,
— i alla andra fall skall meddelandet inte bekräftas.
8.5.3.3.2. De föreslagna överföringsförhållandena skall visas vid den ATC-
station som ansvarar för samordningen av flygningen.
8.5.3.3.3. Rekommendation En anvisning om anledningen till remitter-
ingen (onormala förhållanden eller manuell remittering) bör
inkluderas.
8.5.4. Bekräftelse av ett RRV
8.5.4.1. Bekräftelse
Meddelandet skall bekräftas genom genererandet och sändandet
av ett SBY-meddelande.
8.5.4.2. Tillfällen utan bekräftelse
Om inget SBY-meddelande tas emot som bekräftelse på ett RRV-
meddelande, skall en varning visas vid den ATC-station som har
ansvaret för samordningen av flygningen.
8.5.5. Operativt svar på ett RRV
Den mottagande flygledaren kan antingen acceptera, ge ett
motförslag till eller avslå ett RRV-meddelande.
8.5.5.1. Godkännande
När den mottagande flygledaren väljer att godkänna de föreslagna
överföringsförhållandena, skall ett ACP-meddelande återsändas.
8.5.5.2. Motförslag
När den mottagande flygledaren väljer att presentera ett motför-
slag med överföringsförhållanden, skall ett CDN-meddelande
återsändas.
8.5.5.3. Avslag
När den mottagande flygledaren väljer att avslå den föreslagna
ändringen till de överenskomna överföringsförhållandena
— skall ett RJC-meddelande återsändas,
och
— ett nytt samordningsförfarande inledas.
Om varken ett ACP eller ett CDN har mottagits som svar på
RRV-meddelandet har detta avslagits.
8.5.6. Exempel
8.5.6.1. ICAO
(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)2000R2082 — SV — 15.06.2002 — 001.001 — 46
▼B
8.5.6.2. ADEXP
-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA
-PTID BNE -TO 1226 -TFL F310 -ADES EGBB
8.6. Beredskapsmeddelande (SBY)
8.6.1. Syfte med SBY-meddelandet
SBY-meddelandet bekräftar mottagandet av ett meddelande med
förslag till överföringsförhållanden, och påvisar att förslaget har
remitterats till flygledaren för ett beslut.
8.6.2. Meddelandeinnehåll
SBY-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.— Meddelandereferens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
8.6.3. Tillämpningsregler
8.6.3.1. Allmänt
SBY-meddelandet skall genereras och sändas automatiskt som
svar på
— ett RAP-, RRV- eller CDN-meddelande,
— ett ACT- eller REV-meddelande som inte godtas av filtret.
8.6.4. Bekräftande av ett SBY
SBY-meddelandet skall inte bekräftas.
8.6.5. Exempel
8.6.5.1. ICAO
(SBYL/E027E/L002)
8.6.5.2. ADEXP
-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002
8.7. Godkännandemeddelande (ACP)
8.7.1. Syfte med ACP-meddelandet
ACP-meddelandet uppfyller följande operativa krav under ATC-
samordnings- och överföringsfasen:
— Att notera det manuella godkännandet från en flygledare i en
enhet av överföringsförhållandena, som föreslagits av flygle-
daren i den andra enheten i ett av följande meddelanden:
— RAP
— RRV
— CDN
— ACT och REV, om någon av dem har befunnits vara
onormal.
— Att, när det har överenskommits bilateralt, lämna det automa-
tiska godkännandet av ett ACT- eller REV-meddelande som
har passerat filtret i den mottagande enheten (i stället för
LAM).
— Att, när det har överenskommits bilateralt, indikera det manu-
ella godkännandet av ett HOP-meddelande (i stället för ROF-
meddelandet).
8.7.2. Meddelandeinnehåll
ACP-meddelandet innehåller består av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— meddelandenummer,— meddelandereferens.2000R2082 — SV — 15.06.2002 — 001.001 — 47
▼B
— Valfri data — meddelandet kan även innehålla
— frekvens.
— Valfri data i meddelanden i ICAO-format — meddelandet kan
även innehålla följande information:
— Flygplansidentifiering.
— Startflygplats.
— Landningsflygplats.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
8.7.3. Tillämpningsregler
8.7.3.1. Allmänt
8.7.3.1.1. Meddelandereferensen i ett ACP skall innefatta meddelande-
numret på det meddelande som besvaras.
8.7.3.1.2. Frekvensfältet skall, när det finns medtaget, innehålla den frek-
vens som skall användas då flygningen skall kontakta den
mottagande enheten vid överlämnandet.
8.7.3.1.3. ACP-meddelandet skall sändas efter manuellt godkännande från
flygledaren av föreslagna överföringsförhållanden, översända
genom ett ACT, RAP, REV, RRV eller CDN.
8.7.3.1.4. ACP-meddelandet kan sändas, som ett alternativ till ett ROF-
meddelande, som svar på ett HOP-meddelande.
8.7.3.1.5. När det är bilateralt överenskommet, skall ACP-meddelandet
genereras och sändas automatiskt av systemet som ett svar på ettACT/REV som har passerat filtret.
8.7.3.1.6. När ett ACP har mottagits, skall de överenskomna överföri-
ngsförhållandena vara bindande för båda enheterna.
8.7.3.2. Behandling i den mottagande enheten
8.7.3.2.1. ATC-systemet som tar emot ett ACP-meddelande skall försöka
ansluta till den berörda färdplanen.
8.7.3.2.2. Om ett ACP kan anslutas till en färdplan, skall godkännandet
anges till flygledaren.
8.7.3.2.3. Om ett ACP inte kan anslutas till en färdplan
— skall en varning lämnas hos berörd befattningshavare, och
— ett LAM skall inte sändas.
8.7.4. Bekräftelse av ett ACP
8.7.4.1. Bekräftelse
8.7.4.1.1. Ett LAM skall inte återsändas då ett ACP används som ett auto-
matiskt svar på ett ACT- eller REV-meddelande som har passerat
filtret.
8.7.4.1.2. Ett ACP-meddelande som sänds till följd av ett manuellt godta-
gande skall bekräftas genom genererandet och sändandet av ett
LAM-meddelande.
8.7.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som bekräftelse på ett
ACP-meddelande, avsänt som bekräftelse på ett manuellt godkän-
nande, skall en varning visas vid den ATC-station som har
ansvaret för samordningen av flygningen
8.7.5. Exempel
8.7.5.1. ICAO
(ACPL/E027E/L002-18/FRQ/242150)
8.7.5.2. ADEXP
-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -
SEQNUM 002 -FREQ 2421502000R2082 — SV — 15.06.2002 — 001.001 — 48
▼B
8.8. Samordningsmeddelande (CDN)
8.8.1. Syfte med CDN-meddelandet
CDN-meddelandet möter följande operativa krav:
— Framför ett motförslag från den mottagande flygledaren till
den överlämnande som svar på ett ACT-, RAP-, REV- eller
RRV-meddelande.
— Påbörjar en föreslagen förändring av överenskomna överföri-
ngsförhållanden från den mottagande flygledaren till den
överlämnande.
8.8.2. Meddelandeinnehåll
CDN-meddelandet består av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— meddelandenummer,— meddelandereferens (endast vid svar på ett annat medde-
lande),
— flygplansidentifiering,— startflygplats,— landningsflygplats.
ANMÄRKNING Meddelandet skall även innehålla ett eller
båda av följande:
— Beräknad data (gäller ICAO-meddelanden) eller överföri-
ngsnivå (gäller ADEXP-meddelanden).
— Begäran om direktflygning.
— Bilateralt överenskommen data — följande data kan också
ingå, om det är bilateralt överenskommet:
— Frekvens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
8.8.3. Tillämpningsregler
8.8.3.1. Allmänt8.8.3.1.1. CDN-meddelanden skall endast initieras av den mottagande flyg-
ledaren.
8.8.3.1.2. Det skall användas för att sända ett motförslag från den motta-
gande flygledaren till den överlämnande.
ANMÄRKNING Detta kan ske i en dialog som ett svar på ett
förslag som framförts genom ett ACT, RAP,
REV, eller RRV, eller som början på en dialog
för att ändra tidigare överenskomna överföri-
ngsförhållanden.
8.8.3.1.3. Meddelandereferensen skall endast inkluderas då CDN-medde-
landet skickas som svar på ett annat meddelande.
8.8.3.1.4. Om meddelandereferensen inkluderas, skall den innehålla medde-
landenumret på meddelandet till vilket CDN är ett svar.
8.8.3.1.5. Tillämpningen av begäran om direktflygning (beskriven i detalj i
bilaga A) skall
— endast användas om det har överenskommits bilateralt; och
— om överenskommet, beskriva alla dess operativa begräns-
ningar.
8.8.3.1.6. Ett CDN får inte sändas efter det att en given tid eller distans före
gränsen passerats, som fastställts i en LoA mellan de berörda
enheterna,
8.8.3.1.7. Om ett CDN sänds samtidigt som ett meddelande, rörande samma
flygning, från den överlämnande enheten, t.ex. en ändring eller
upphävande av samordning, skall varken en bekräftelse eller ett
operativt svar återsändas.
ANMÄRKNING Resultatet av detta är att när två meddelanden
korsar varandra, har meddelandet från den
överlämnande enheten företräde, och CDN-
meddelandet utesluts av båda systemen. Båda
enheterna kan uppmärksamma situationen i2000R2082 — SV — 15.06.2002 — 001.001 — 49
▼B
och med att meddelandet från den andra mottas
innan bekräftelsen mottas.
8.8.3.1.8. Så fort en bekräftelse mottagits blir CDN-meddelandets data
operativt bindande för båda ATC-enheterna. De samordnade
överföringsförhållandena och det faktum att ACP-meddelandet
har mottagits skall framföras till berörd ATC-personal.
8.8.3.2. Behandling i den mottagande enheten
8.8.3.2.1. Om en motsvarande färdplan påträffas och det inte förekommer
någon avvikelse i meddelandet som skulle kunna förhindra
korrekt behandling skall
— det operativa innehållet visas vid den ATC-station som har
ansvaret för samordningen av flygningen,
och
— ett SBY återsändas.
8.8.3.2.2. Om CDN inte kan anslutas, eller om en avvikelse som förhindrar
korrekt behandling av meddelandet påträffas, skall inget SBY
återsändas.
8.8.4. Bekräftelse av ett CDN
8.8.4.1. Bekräftelse
Under ovan beskrivna förhållanden, skall CDN-meddelandet
bekräftas genom genererandet och sändandet av ett SBY-medde-
lande.
8.8.4.2. Tillfällen utan bekräftelse
Om inget SBY-meddelande har mottagits som bekräftelse på ett
CDN-meddelande, skall en varning visas vid den ATC-station
som har ansvaret för samordningen av flygningen.
8.8.5. Operativt svar på ett CDN
Flygledaren kan antingen godkänna eller avslå de överföri-
ngsförhållanden som föreslås i ett CDN-meddelande.
8.8.5.1. Godkännande
När den överlämnande flygledaren väljer att godkänna de föres-
lagna överföringsförhållandena, skall ett ACP-meddelandeåtersändas.
8.8.5.2. Rekommendation När den överlämnande flygledaren väljer att
avslå de föreslagna överföringsförhållandena, bör ett RJC-
meddelande återsändas (uttryckligt avslag).
ANMÄRKNING Den föreslagna samordningen är uttryckligen
avslagen om inget godkännande har mottagits
innan tidsbegränsningen för CDN-meddelandet
löpt ut.
8.8.6. Exempel
8.8.6.1. ICAO
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A
8.9. Meddelande med avslag av samordning (RJC)
8.9.1. Syfte med RJC-meddelandet
RJC-meddelandet påvisar avslaget, från en flygledare vid en
enhet, av de överföringsförhållanden som föreslagits av flygle-
daren vid den andra enheten, genom ett av följande meddelanden:
— RAP
— RRV
— CDN
— ACT och REV, om något av dessa befunnits vara onormalt.2000R2082 — SV — 15.06.2002 — 001.001 — 50
▼B
RJC-meddelandet kan endast användas som direkt svar på ett av
de ovanstående meddelandena.
8.9.2. Meddelandeinnehåll
RJC-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.— Meddelandereferens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
8.9.3. Tillämpningsregler
8.9.3.1. Allmänt8.9.3.1.1. Ett RJC skall sändas, när så erfordras, som svar på ett RAP-,
RRV- eller CDN-meddelande eller som svar på ett ACT- eller
REV-meddelande som den mottagande enheten befunnit vara
onormalt.
8.9.3.1.2. RJC-meddelandet avslutar systemdialogen och all tidigare
överenskommen samordning förblir gällande.
8.9.3.1.3. Rekommendation Efter mottagandet av ett RJC-meddelande bör
en ny samordningssekvens, som återspeglar telefonsamordningen
om detta är tillämpligt, påbörjas.
8.9.3.2. Behandling i den mottagande enheten8.9.3.2.1. Om ett meddelande som motsvarar en hänvisning i RJC-medde-
landet påträffas, skall
— det operativa innehållet visas vid den ATC-station som har
ansvaret för samordningen av flygningen, och
— ett LAM återsändas som bekräftelse.
8.9.3.2.2. Om inget sådant meddelande befinns vänta på svar, eller om en
avvikelse som förhindrar behandling förekommer i meddelandet,
skall ingen bekräftelse återsändas.
8.9.4. Bekräftelse av ett RJC
8.9.4.1. Bekräftelse
RJC-meddelandet skall bekräftas genom genererandet och
sändandet av ett LAM-meddelande.
8.9.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande har mottagits som bekräftelse på ett
RJC-meddelande, skall en varning visas vid den ATC-station som
har ansvaret för samordningen av flygningen.
8.9.5. Exempel
8.9.5.1. ICAO
(RJCMC/E746E/MC324)
8.9.5.2. ADEXP
-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E
-SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC
MC -SEQNUM 324
9. DIALOGFÖRFARANDE — KOMMUNIKATIONSÖVER-
FÖRING
9.1. Allmänt
9.1.1. Inledning
9.1.1.1. I detta avsnitt av standarden beskrivs de funktioner och medde-
landen som stödjer radarhanteringen inom kontrollförfarandet.
De skall genomföras där så har överenskommits bilateralt.
9.1.1.2. Funktionerna för kommunikationsöverföring skall inte införas om
inte enheten använder sig antingen av de samordningsmöjligheter
som beskrivs i avsnitt 6 (Grundläggande förfaranden — Obligato-
riska meddelanden) eller av dem i avsnitt 8 (Dialogförfaranden —
Samordning).2000R2082 — SV — 15.06.2002 — 001.001 — 51
▼B
9.1.1.3. Meddelandena som beskrivs i detta avsnitt finns endast tillgäng-
liga i ADEXP-format, och det är inte planerat att de skall bli
tillgängliga i ICAO-format.
9.1.2. Meddelandeföljd
9.1.2.1. Kommunikationsöverföringsmeddelanden, andra än meddelanden
med tilläggsdata (SDM), skall inte förekomma om inte samord-
ningen är avslutad, dvs. en ACT- eller RAP-dialog har avslutats
med ett LAM eller ett ACP.
9.1.2.2. En bekräftelse skall inte återsändas så länge som samordningen
inte är slutförd.
9.1.3. Kommunikationsöverföring
9.1.3.1. Metoden för att tillkännage det faktiska övertagandet av kommu-
nikationen för en flygning skall vara bilateralt överenskommen
mellan de två berörda enheterna.
9.1.3.2. Förhållandena skall vara ett eller båda av följande:
— Den överlämnande enheten sänder ett meddelande om frek-
vensändring (COF).
— Den mottagande enheten sänder att meddelande om manuellt
övertagande av kommunikationen (MAS).
9.1.3.3. Metoden skall vara överenskommen mellan de båda enheterna för
varje trafikflöde.
ANMÄRKNING Alternativa metoder kan tillämpas för olika
flöden, t.ex. kan en enhet generera COF-
meddelanden för flygningar som lämnar dess
luftrum och MAS-meddelanden för flygningar
som inträder i dess luftrum. I sådant fall skulle
det inte vara nödvändigt för den andra enheten
att utfärda några meddelanden för att till-
kännage kommunikationsöverföring.
9.2. Meddelande om initiering av överföring (TIM)
9.2.1. Syfte med TIM-meddelandet
Syftet med TIM är att
— tillkännage initiering av överföringsmomentet (TI) (slutet av
samordningsfasen och början på överföringsfasen),
— samtidigt överföra verkställande kontrolldata från den
överlämnande enheten till den mottagande enheten.
9.2.2. Meddelandeinnehåll
TIM-meddelandet skall bestå av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— Meddelandenummer,
— flygplansidentifiering,
— Tillgänglig data — meddelandet skall också innehålla vart
och ett av följande, om det finns tillgängligt:
— Godkänd flygnivå.
— Tilldelad kurs eller tillstånd till direkt flygväg.— Tilldelad fart.— Tilldelad stig-/sjunkhastighet.
— Valfri data — meddelandet kan även innehålla
— position.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.2.3. Tillämpningsregler
9.2.3.1. Allmänt9.2.3.1.1. TIM-meddelandet skall genereras och sändas av den överläm-
nande enheten till den mottagande enheten utan mänsklig
inblandning då flygningen befinner sig vid bilateralt överens-
kommen tid/överenskommet avstånd från gränsen.2000R2082 — SV — 15.06.2002 — 001.001 — 52
▼B
9.2.3.1.2. Ett TIM-meddelande skall också sändas automatiskt när medde-
landet med begäran om frekvens (ROF) tas emot av den
överlämnande enheten.
9.2.3.1.3. Ett TIM skall inte sändas innan flygningen har samordnats.
9.2.3.1.4. TIM-meddelandet skall innehålla den senaste datan som finns
tillgänglig i systemet.
9.2.3.2. Tidsparametrar för sändning9.2.3.2.1. Parametern för genererandet av TIM skall vara en variabel
systemparameter som kan ändras, baserat på villkoren i LoA.
9.2.3.2.2. Rekommendation Systemet för genererandet av TIM bör defini-
eras separat för varje COP.
9.2.3.2.3. De samordnande parterna skall innefatta parametrarna för genere-
randet av ett TIM i deras LoA.
9.2.3.2.4. Systemparametrarna som utlöser TIM-meddelandet kan vara
kopplade till flygplanets beräknade fart över marken. Emellertid
skall initieringen av ett TIM-meddelande alltid påbörjas innan
den aktuella färdplanspositionen är närmare COP än den det
minimiavstånd som har angivits bilateralt.
9.2.3.2.5. Den angivna systemparametern för TIM-sändningen skall ge
tillräckligt med tid för muntlig kommunikation före överläm-
nandet.
9.2.3.3. Behandling i den mottagande enheten
9.2.3.3.1. Den data som mottagits i ett TIM skall göras tillgänglig för den
mottagande flygledaren.
9.2.4. Bekräftelse av ett TIM
9.2.4.1. Bekräftelse
Om TIM-meddelandet
— otvetydigt kan anslutas till en färdplan, skall det bekräftas
genom genererandet och sändandet av ett LAM-meddelande,
— inte otvetydigt kan anslutas till en färdplan, skall inget
bekräftelsemeddelande sändas.
9.2.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som bekräftelse på ett TIM-
meddelande, skall en varning visas vid den berörda stationen.
9.2.5. Exempel
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM253
9.3. Meddelande med tilläggsdata (SDM)
9.3.1. Syfte med SDM-meddelandet
9.3.1.1. Allmänt9.3.1.1.1. Huvudsyftet med SDM är att sända kontrolldata, och ändringar
till densamma, från den överlämnande enheten till den motta-
gande enheten, förutsatt att det har överenskommits bilateralt att
ändringarna inte behöver bekräftas av den mottagande flygle-
daren.
9.3.1.1.2. SDM-meddelandet kan också användas av den mottagande
enheten för att upplysa den överlämnande enheten om vilken
radiotelefonifrekvens flygningen skall överföras till.
9.3.2. Meddelandeinnehåll
9.3.2.1. Meddelanden från den överlämnande enheten
SDM-meddelandet skall bestå av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— meddelandenummer,
— flygplansidentifiering.2000R2082 — SV — 15.06.2002 — 001.001 — 53
▼B
— Tilläggsdata — meddelandet skall också innehålla en eller
flera av följande:
— Tilldelad kurs eller tillstånd till direkt flygväg.
— Tilldelad fart.— Tilldelad stig-/sjunkhastighet.— Godkänd flygnivå.
9.3.2.2. Meddelanden från den mottagande enheten
Ett SDM skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.
— Flygplansidentifiering.
— Frekvens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.3.3. Tillämpningsregler
9.3.3.1. Meddelanden från den överlämnande enheten
9.3.3.1.1. SDM-meddelanden skall sändas efter initiering av överföringsf-
asen (se TIM, punkt 9.2) vid varje förändring av någon av
följande punkter:
— Godkänd flygnivå.
— Tilldelad fart.
— Tilldelad stig-/sjunkhastighet.
— Tilldelad kurs.— Utfärdande eller ändring av ett tillstånd för flygningen att
fortsätta direkt till en fastställd punkt.
ANMÄRKNING HOP-meddelandet måste användas när tillstånd
från den mottagande flygledaren krävs före
överföringen av kommunikationen.
9.3.3.1.2. Meddelandet skall endast innehålla de fält som ändrats.
9.3.3.1.3. SDM-meddelande som innehåller den data som beskrivits i
9.3.3.1.1 skall sändas före TI, om så har överenskommits bilate-
ralt.
9.3.3.1.4. Sådana meddelanden skall påbörjas vid en bilateralt överens-
kommen tidpunkt i förhållande till TI, under förutsättning att det
finns data för vilken det finns ett värde tillgängligt i systemet.
9.3.3.2. Meddelanden från den mottagande enheten9.3.3.2.1. SDM-meddelanden kan sändas för att påvisa den frekvens som
flygningen skall använda för att kontakta den mottagande
enheten.
ANMÄRKNING Enheter kan bilateralt komma överens om att
sända annan information. Sådan överföring
har inte definierats i, och är därför inte någon
del av, denna standard.
9.3.3.2.2. Om så har överenskommits bilateralt, skall SDM-meddelanden
från den mottagande enheten sändas under samordningsfasen.
9.3.3.3. Behandling i den mottagande enheten
9.3.3.3.1. ATC-systemet som tar emot ett SDM-meddelande skall försöka
ansluta till den berörda färdplanen.
9.3.3.3.2. Om en motsvarande, samordnad, färdplan påträffas
— skall ett LAM återsändas, och
— det operativa innehållet i SDM-meddelandet göras tillgängligt
för den berörda flygledaren.
9.3.3.3.3. Om en motsvarande färdplan inte kan påträffas, eller om en avvi-
kelse påträffas som förhindrar korrekt behandling av
meddelandet,
— skall inget LAM återsändas, och
— en varning visas vid en berörd station.2000R2082 — SV — 15.06.2002 — 001.001 — 54
▼B
9.3.4. Bekräftelse av ett SDM
9.3.4.1. Bekräftelse
SDM-meddelandet skall bekräftas genom genererandet och
sändandet av ett LAM-meddelande.
9.3.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande har mottagits som en bekräftelse på
ett SDM-meddelande, skall en varning visas vid en berörd station.
9.3.5. Exempel
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4. Förslag till överlämning (HOP)
9.4.1. Syfte med HOP-meddelandet
Syftet med HOP-meddelandet är
— för den överlämnande flygledaren att uppmärksamma den
mottagande flygledaren på en särskild flygning för överläm-
nande,
— för den överlämnande flygledaren att föreslå flygningen för
överlämnande till den mottagande flygledaren då detta krävs,
— att överföra ändringar av den verkställande kontrolldatan,
vilket kräver godkännande av den mottagande flygledaren,
enligt bilateral överenskommelse.
Det är inte nödvändigt att använda HOP till alla flygningar; det
används efter den överlämnande flygledarens godtycke.
ANMÄRKNING Med avseende på punkt c) ovan, används ett
SDM för att vidarebefordra ändringar i
verkställande kontrolldata som inte kräver
godkännande av den mottagande flygledaren.
9.4.2. Meddelandeinnehåll
HOP-meddelandet skall bestå av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— meddelandenummer,
— flygplansidentifiering.
— Tillgänglig data — meddelandet skall också innehålla vart
och ett av följande, om det finns tillgängligt:
— Godkänd flygnivå.
— Tilldelad kurs eller tillstånd till direkt flygväg.
— Tilldelad fart.— Tilldelad stig-/sjunkhastighet.
— Valfri data — meddelandet kan även innehålla
— position.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.4.3. Tillämpningsregler
9.4.3.1. Allmänt
9.4.3.1.1. HOP-meddelandet skall, då det används, vara manuellt initierat
av den överlämnande flygledaren.
9.4.3.1.2. Meddelandet skall inkludera all flygdata, som beskrivits i punkt
9.4.2 ovan, som har ändrats från den som tidigare sänts.
9.4.3.1.3. Om ett HOP-meddelande sänds före TI, skall överföringsfasen
inledas.
ANMÄRKNING Ett meddelande om initiering av överföring
(TIM) erfordras inte utöver ett HOP.
9.4.3.1.4. Tidigaste tidpunkten eller avståndet före en COP eller gräns då
ett HOP kan sändas skall vara bilateralt överenskommet.
9.4.3.1.5. Rekommendation Tiden/avståndet bör fastställas separat för
varje COP.2000R2082 — SV — 15.06.2002 — 001.001 — 55
▼B
9.4.3.2. Behandling i den mottagande enheten
9.4.3.2.1. ATC-systemet som tar emot ett HOP-meddelande skall försöka
ansluta till den berörda färdplanen.
9.4.3.2.2. Den flygdata som erhållits i meddelandet skall omedelbart visas
för den mottagande flygledaren.
9.4.3.2.3. Om den mottagande flygledaren godkänner flygningen under de
förhållanden som föreslagits i ett HOP, kan ett ROF sändas som
svar till den överlämnande enheten. När det har överenskommits
bilateralt, kan ett ACP sändas som ett svar på ett HOP.
9.4.3.2.4. Om den mottagande flygledaren inte kan godkänna flygningen,
skall överlämnandet överenskommas muntligen.
ANMÄRKNING På grund av överlämningsförfarandets
brådskande karaktär, har inte systemhjälp med
övervakning av återsändandet av ett ROF (eller
ACP) krävts i denna standard. Det antas att
den överlämnande flygledaren är väl medveten
om avsaknaden av ett svar från den mottagande
flygledaren och vidtar erforderliga åtgärder.
Denna standard förhindrar emellertid inte att
en varning ges till den överlämnande flygle-
daren om det bedöms vara nödvändigt av
operativa orsaker.
9.4.3.2.5. Så snart ett ROF (eller ACP) har tagits emot, skall datan i HOP-
meddelandet bli operativt bindande för båda ATC-enheterna.
9.4.4. Bekräftelse av ett HOP
9.4.4.1. Bekräftelse
Om det kan anslutas till en färdplan, skall HOP-meddelandet
bekräftas automatiskt med ett LAM.
9.4.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande har mottagits som en bekräftelse på
ett HOP-meddelande, skall en varning visas vid den berörda
stationen.
9.4.5. Exempel
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ
9.5. Meddelande med begäran om frekvens (ROF)
9.5.1. Syfte med ROF-meddelandet
Ett ROF sänds, när så erfordras, av den mottagande enheten till
den överlämnande enheten med en begäran till den överlämnande
flygledaren om att beordra flygplanet att byta till den mottagande
flygledarens frekvens. Meddelandet kan användas
— som svar på ett HOP för tillkännage godkännandet av flyg-
ningen under de föreslagna förhållandena,
— för att begära tidigare överlämnande av flygningen.
9.5.2. Meddelandeinnehåll
ROF-meddelandet skall innehålla följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— Meddelandetyp,
— Meddelandenummer,— flygplansidentifiering.
— Valfri data — meddelandet kan även innehålla
— frekvens.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.5.3. Tillämpningsregler
9.5.3.1. Allmänt9.5.3.1.1. ROF-meddelandet skall initieras manuellt av den mottagande
flygledaren.2000R2082 — SV — 15.06.2002 — 001.001 — 56
▼B
9.5.3.1.2. Den mottagande flygledaren kan utlösa ett ROF, antingen
— när den mottagande flygledaren kräver att ha flygplanet på
frekvens tidigt, eller
— som ett svar på ett HOP-meddelande.
9.5.3.2. Behandling i den mottagande enheten
9.5.3.2.1. ATC-systemet som tar emot ett ROF-meddelande skall försöka
ansluta till den berörda färdplanen.
9.5.3.2.2. Mottagandet av ett ROF skall utan dröjsmål påvisas för den
överlämnande flygledaren.
9.5.3.2.3. Om flygningen inte befinner sig i överföringsfasen, skall
överföringsfasen inledas, och ett TIM-meddelande sändas.
9.5.4. Bekräftelse av ett ROF
9.5.4.1. Bekräftelse9.5.4.1.1. Om ROF-meddelandet otvetydigt kan anslutas till en färdplan,
skall det bekräftas genom genererandet och sändandet av ett
LAM-meddelande.
9.5.4.1.2. Om ROF-meddelandet inte otvetydigt kan anslutas till en
färdplan, skall ingen bekräftelse sändas.
9.5.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som bekräftelse på ett
ROF-meddelande, skall en varning visas vid den berörda ATC-
stationen.
9.5.5. Exempel
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6. Meddelande om frekvensändring (COF)
9.6.1. Syfte med COF-meddelandet
9.6.1.1. Allmänt9.6.1.1.1. Ett COF sänds av den överlämnande enheten till den mottagande
enheten för att påvisa att flygningen har beordrats att kontakta
den mottagande flygledaren.
9.6.1.1.2. Meddelandet kan innehålla en möjlighet för den överlämnande
flygledaren att befria flygningen från de överenskomna överföri-
ngsförhållandena när den har etablerat radiokontakt med den
mottagande flygledaren.
9.6.2. Meddelandeinnehåll
COF-meddelandet skall bestå av följande data:
— Obligatoriskdata — meddelandet sk all innehålla
— meddelandetyp,
— meddelandenummer,— flygplansidentifiering.
— Tillgänglig data — meddelandet skall också innehålla vilken
som helst av följande, om det finns tillgängligt:
— Överlåtelseindikering.
— Frekvens.— Godkänd flygnivå.— Tilldelad kurs eller tillstånd till direkt flygväg.— Tilldelad fart.— Tilldelad stig-/sjunkhastighet.
— Valfri data — meddelandet kan även innehålla:
— Position.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.6.3. Tillämpningsregler
9.6.3.1. Allmänt9.6.3.1.1. COF-meddelandet skall initieras manuellt av den överlämnande
flygledaren.2000R2082 — SV — 15.06.2002 — 001.001 — 57
▼B
9.6.3.1.2. Användandet av COF-meddelandet är obligatoriskt om, genom en
bilateral överenskommelse, MAS-meddelandet inte används.
9.6.3.1.3. Om ett COF-meddelande sänds före TI, skall överföringsfasen
inledas.
ANMÄRKNING Ett meddelande om initiering av överföring
(TIM) krävs inte utöver ett COF.
9.6.3.2. Behandling i den mottagande enheten
9.6.3.2.1. ATC-systemet som tar emot ett COF-meddelande skall försöka
ansluta till den berörda färdplanen.
9.6.3.2.2. Mottagandet av ett COF skall utan dröjsmål påvisas för den
mottagande flygledaren.
9.6.4. Bekräftelse av ett COF
9.6.4.1. Bekräftelse
9.6.4.1.1. Om COF-meddelandet otvetydigt kan anslutas till en färdplan,
skall det bekräftas genom genererandet och sändandet av ett
LAM-meddelande.
9.6.4.1.2. Om COF-meddelandet inte otvetydigt kan anslutas till en
färdplan, skall ingen bekräftelse sändas.
9.6.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som en bekräftelse på ett
COF-meddelande, skall en varning visas vid den berörda ATC-
stationen.
9.6.5. Exempel
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7. Meddelande om manuellt övertagande av kommunikationen
(MAS)
9.7.1. Syfte med MAS-meddelandet
Ett MAS sänds av den mottagande enheten till den överlämnande
enheten för att påvisa att tvåvägs radiokontakt har upprättats med
flygningen.
9.7.2. Meddelandeinnehåll
MAS-meddelandet skall innehålla följande data:
— Meddelandetyp.
— Meddelandenummer.
— Flygplansidentifiering.
ANMÄRKNING Regler för införande av data, format och fältin-
nehåll beskrivs i bilaga A.
9.7.3. Tillämpningsregler
9.7.3.1. Allmänt
9.7.3.1.1. MAS-meddelandet skall initieras manuellt av den mottagande
flygledaren.
9.7.3.1.2. Användandet av MAS-meddelandet är obligatoriskt om, genom
en bilateral överenskommelse, COF-meddelandet inte används.
9.7.3.2. Behandling i den mottagande enheten9.7.3.2.1. ATC-systemet som tar emot ett MAS-meddelande skall försöka
ansluta till den berörda färdplanen.
9.7.3.2.2. Mottagandet av ett MAS skall utan dröjsmål påvisas för den
mottagande flygledaren.
9.7.4. Bekräftelse av ett MAS
9.7.4.1. Bekräftelse
9.7.4.1.1. Om MAS-meddelandet otvetydigt kan anslutas till en färdplan,
skall det bekräftas genom genererandet och sändandet av ett
LAM-meddelande.
9.7.4.1.2. Om MAS-meddelandet inte otvetydigt kan anslutas till en
färdplan, skall ingen bekräftelse sändas.2000R2082 — SV — 15.06.2002 — 001.001 — 58
▼B
9.7.4.2. Tillfällen utan bekräftelse
Om inget LAM-meddelande tas emot som en bekräftelse på ett
MAS-meddelande, skall en varning visas vid den berörda ATC-
stationen.
9.7.5. Exempel
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — SV — 15.06.2002 — 001.001 — 59
▼B
BILAGA A (Normativ)
REGLER FÖR INFÖRANDE AV DATA
INNEHÅLL
A.1. Syfte
A.2. Allmänna meddelandeformatA.3. Meddelandetyper
A.4. Meddelandenummer
A.5. MeddelandereferensA.6. Flygplansidentifiering
A.7. SSR-läge och -kod
A.8. StartflygplatsA.9. Beräknad data
A.10. Samordningspunkt
A.11. LandningsflygplatsA.12. Antal och typ av flygplan
A.13. Flygväg
A.14. Annan färdplansdataA.15. Samordningsstatus och anledning
A.16. Tilldelad kurs (endast ADEXP)
A.17. Tilldelad fart (endast ADEXP)A.18. Tilldelad stig-/sjunkhastighet (endast ADEXP)
A.19. Tillstånd till direkt flygväg (endast ADEXP)
A.20. Begäran om direkt flygvägA.21. Position (endast ADEXP)
A.22. Överlåtelseanvisning(endast ADEXP)
A.23. FrekvensA.24. Anledning (endast ADEXP)
A.25. Godkänd flygnivå (endast ADEXP)
A.26. Överföringsnivå (endast ADEXP)A.27. Beräknad starttid
A.28. Typ av referensmeddelande
A.29. Typ av flygning
A.30. Utrustningens kapacitet och status
A.1. Syfte
I denna bilaga beskrivs de allmänna reglerna för införande av data i
meddelandena beskrivna i denna standard. Dessa regler gäller för
alla meddelanden utom då andra alternativ eller undantag till dessa
regler specifikt har uppgivits i tillämpningsreglerna för ett specifikt
meddelande.
A.2. Allmänna meddelandeformat
A.2.1. Alla meddelanden beskrivna i de följande avsnitten kan sändas med
användande av ICAO-formatet:
6 Grundläggande förfarande — Obligatoriska meddelanden.
7 Grundläggande förfarande — Kompletterande meddelanden.
8 Dialogförfarande — Samordning.2000R2082 — SV — 15.06.2002 — 001.001 — 60
▼M1
▼B
▼B
A.2.2. Fältformat för ICAO-meddelanden är specificerade i Procedures for
Air Navigation Services — Rules of the Air and Air Traffic Control
(Document 4444). I meddelanden där de förekommer, skall följande
ICAO-fälttyper sändas före alla andra fälttyper och i följande
ordning: 3, 7, 13, 14 och 16. Eftersom de är i fälttyp 22-format, är
ordningsföljden på andra ICAO-fälttyper inte viktig, annat än att de
inte får föregå de fälttyper som listas ovan.
A.2.2.a. Där det saknas ett passande ICAO-fält, används i vissa fall ett oäkta
ICAO-fälttypstal. Sådana tal är tvåsiffriga och är lika med eller
större än 80.
A.2.3. Alla meddelanden beskrivna i detta dokument kan sändas med
användande av Eurocontrol ADEXP-format. Innehållet, uppbygg-
naden och användandet av ADEXP-datafält skall ske i
överensstämmelse med referensdokument 2.
ANMÄRKNINGAR1.Endast de primära ADEXP-datafälten är listade i denna bilaga,
förutom där förknippade underordnade fält kräver särskilda
kommentarer. ADEXP-standarden listar alla valfria och obliga-
toriska underordnade fält som krävs inom varje primärt fält.
2.Meddelanden beskrivna i avsnitt 9, Dialogförfaranden —
Överföring av kommunikationen, beskrivs endast i ADEXP-
format.
A.3. Meddelandetyp
Meddelandetypen betecknas med en förkortning för meddelandet,
enligt följande förteckning:
ABI: Förhandsmeddelande med gränsinformation.
ACP: Godkännande.
ACT: Aktivering.
CDN: Samordning.
COD: Tilldelning av SSR-kod.
COF: Frekvensändring.
HOP: Förslag till överlämning.
INF: Information.
LAM: Logiskt bekräftelsemeddelande.
MAC: Meddelande om upphävande av samordning.
MAS: Manuellt övertagande av kommunikationen.
PAC: Preliminär aktivering.
RAP: Remitterat aktiveringsförslag.
REV: Ändring.
RJC: Avslag till samordning.
ROF: Begäran om frekvens.
RRV: Remitterat ändringsmeddelande.
SBY: Beredskap.
SDM: Meddelande med tilläggsdata.
TIM: Meddelande om initiering av överföring.
A.3.1. ICAO
Fälttyp 3, element (a).
A.3.2. ADEXP
Primärt fält ”title”.
A.4. Meddelandenummer
Meddelandenumrets data innehåller de identifieringar som tilldelats
de sändande och mottagande enheterna samt meddelandets sekven-
snummer. Meddelandets sekvensnummer löper i ordningsföljd från
001 till 000 (som representerar 1 000), därefter upprepas det från2000R2082 — SV — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
001 för alla meddelanden som sänds till samma mottagare, oavsett
typen av meddelande.
A.4.1. ICAO
Fälttyp 3, element (b).
A.4.2. ADEXP
Primärt fält ”refdata”.Underordnat fält ”fac”, inom underordnade fält ”sender” och ”recvr”
skall innehålla de identifieringar som har tilldelats ATC-enheterna.
Dessa identifieringar skall inte vara längre än åtta tecken.
Underordnat fält ”seqnum” skall innehålla sekvensnumret.
A.5. Meddelandereferens
A.5.1. ICAO
Fälttyp 3, element (c) (benämnt ”reference data” i ICAO dokument
4444).
Innehållet i element (c) skall vara detsamma som det i fälttyp 3,
element (b), i det hänvisade OLDI-meddelandet.
A.5.2. ADEXP
Primärt fält ”msgref”.
Värdena i underordnade fält ”sender”, ”recvr” och ”seqnum”, inom
det primära fältet ”msgref”, skall vara desamma som de i samma
underordnade fält inom det primära fältet ”refdata” i det hänvisade
OLDI-meddelandet.
A.6. Flygplansidentifiering
A.6.1. ICAO
Fälttyp 7, element (a).
A.6.2. ADEXP
Primärt fält ”arcid”.
A.7. SSR-läge och -kod
Antingen1. om känd, den SSR-läge/-kod på vilken den mottagande enheten
kan förvänta sig att flygplanet svarar vid kontrollöverföri-
ngspunkten,
eller
2. ett tecken på att SSR-kod har begärts från den mottagande
enheten.
A.7.1. ICAO
Fälttyp 7, element (b) och (c).Om ingen SSR-kod har tilldelats, eller om läget/koden inte är känd,
skall element (b) och (c) utelämnas.
Vid begäran av en SSR-kod/-läge skall element b) och c) innehålla
värdet ”A9999”.
A.7.2. ADEXP
Primärt fält ”ssrcode”.Om ingen giltig SSR-kod har tilldelats eller om läget/koden inte är
känd skall fältet utelämnas.
Vid begäran av en SSR-kod/-läge via PAC-meddelandet skall det
primära fältet ”ssrcode” innehålla indikatorn ”REQ”.2000R2082 — SV — 15.06.2002 — 001.001 — 62
▼B
A.8. Startflygplats
A.8.1. ICAO
Fälttyp 13, element (a).
A.8.2. ADEXP
Primärt fält ”adep”.
A.9. Beräknad data
A.9.1. Allmänt
A.9.1.1. Beräknad data skall innefatta COP, tid vid COP och överföri-
ngsnivå.
A.9.1.2. Samordningspunkten skall definieras som antingen en känd refe-
renspunkt, en distans och en bäring från en känd referenspunkt,
eller en latitud och en longitud.
A.9.1.3. Den godkända (överförings-)nivån skall motsvara de föreslagna
överföringsförhållandena.
A.9.1.4. Rekommendation För stigande eller sjunkande flygningar skall den
beräknade datan även innehålla tilläggsdata och förhållanden för
korsning.
A.9.1.5. Om den används, skall tilläggsdatan för korsning innefatta tillä-
ggsnivån för korsning vid kontrollöverföringspunkten.
Korsningsvillkoren skall vara följande:
— Bokstaven ”A” — om flygningen kommer att befinna sig på
eller över nivån i tilläggsdatan för korsning.
— Bokstaven ”B” — om flygningen kommer att befinna sig på
eller under nivån i tilläggsdatan för korsning.
A.9.2. ICAO
Fälttyp 14.
A.9.3. ADEXP
Primärt fält ”coordata”.Underordnade fält ”ptid” inom primärt fält ”coordata” skall
innehålla antingen
— en känd referenspunkt, eller
— en bäring och en distans från en känd referenspunkt, vilken defi-
nierats i samma meddelande genom primärt fält ”REF” eller
”GEO”.
A.10. Samordningspunkt
A.10.1. Allmänt
A.10.1.1. Samordningspunkten som remitterats till av de överlämnande och
mottagande ATC-enheterna i samband med berörd överföring.
A.10.1.2. Samordningspunkten skall definieras antingen som en känd punkt,
en distans och en bäring från en känd referenspunkt eller en latitud
och en longitud.
A.10.2. ICAO
Fält 14, element (a).
A.10.3. ADEXP
Primärt fält ”cop” innehållande
— en känd referenspunkt, eller
— en bäring och en distans från en känd referenspunkt, vilken defi-
nierats i samma meddelande genom primärt fält ”REF” eller
”GEO”.2000R2082 — SV — 15.06.2002 — 001.001 — 63
▼B
A.11. Landningsflygplats
A.11.1. ICAO
Fält 16, element (a).
A.11.2. ADEXP
Primärt fält ”ades”.
A.12. Antal och typ av flygplan
Antal och typ av flygplan skall innehålla typen av flygplan. Antalet
flygplan skall inkluderas om det rör sig om en formationsflygning.
A.12.1. ICAO
Fälttyp 9 i fälttyp 22-format. Element c av fälttyp 9 skall innehålla
antingen kategorin för vakturbulens tillämplig för flygplanstypen
eller bokstaven ”Z”.
A.12.2. ADEXP
Primärt fält ”arctyp”. Som tillägg, om det ingår mer än ett flygplan i
flygningen, primärt fält ”nbarc”.
A.13. Flygväg
Båda formaten stödjer flygvägsbeskrivningen enligt definition för
ICAO-meddelanden, vilken kräver som de första elementen fart
och begärd flygnivå eller höjdinformation. Efter fart/nivå-gruppen
inkluderar flygvägsdatan, som ett minimum, vad som specificeras i
följande punkt. Ytterligare flygvägsdata kan infogas efter punkt c)
om det finns tillgängligt. Se även bilaga B, ”Krav för behandling
av speciella flygvägar”, för införingsregler för flygvägsdata.
A.13.1. Innehåll
A.13.1.1. Fl ygningar som passerar en definierad COP
— Elementet flygväg före COP (ATS-flygväg, SID-identifiering,
DCT eller väsentlig punkt).
— COP.— Elementet flygväg efter COP (ATS-flygväg eller väsentlig
punkt).
A.13.1.2. Fl ygningar som fortsätter utanför ATS-flygväg
— Den punkt från vilken flygningen fortsätter på det direkta
flygvägssegmentet.
— Elementet ”DCT”.
— Den punkt till vilken flygningen fortsätter på det direkta
flygvägssegmentet.
A.13.2. Format
A.13.2.1. ICAO
Fälttyp 15, i fälttyp 22-format.
A.13.2.2. ADEXP
Primärt fält ”route”.
A.14. I detta fält kan man i specificerade meddelanden införa färdplans-
data som normalt inte ingår i samordningsförfarandet och som inte
beskrivs någon annanstans i denna bilaga. Följande data, enligt
beskrivningen i referensdokument 1, bilaga 2, fälttyperna 8 och 18,
får införas:
— Flygregler
— Registreringsmärkning
— Operatörens namn— Anledning till speciellt ATS-handhavande2000R2082 — SV — 15.06.2002 — 001.001 — 64
▼M1
▼M1
— Typ
— Prestanda— Namn på startflygplats, landningsflygplats och alternativa flyg-
platser
— Anmärkningar i klarspråk
A.14.1. ICAO
Fälttyp 8, element (a) ”Flygregler” i fälttyp 22-format.
Ett eller flera av följande fälttyp 18-element i fälttyp 22-format:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Primära fält: ”fltrul”, ”depz”, ”destz”, ”opr”, ”per”, ”reg”, ”rmk”,
”altrnt1”, ”altrnt2”, ”sts”, and ”typz”.
A.15. Samordningsstatus och anledning
Samordningsstatus och anledning skall innefatta följande element:
— En trebokstavsbeteckning som bekräftar den nya statusen på
systemfärdplanen enligt en av följande:
— INI, när systemfärdplanen skall ha initial status, dvs. inget
underrättelsemeddelande har mottagits.
— NTF, när systemfärdplanen skall ha underrättad status.— CRD, när systemfärdplanen skall ha samordnad status, dvs.
grundläggande ACT mottaget eller initial samordningsdialog
avslutad med överenskomna förhållanden.
— en trebokstavsbeteckning som specificerar anledningen till
statusen enligt en av följande:
— TFL, om anledningen är en förändring av överföringsnivå.
— RTE, om anledningen är en förändrad flygväg.— HLD, som anvisning på att flygningen väntar under en
obestämd tidsperiod och kommer att erhålla ett ytterligare
meddelande.
— DLY, som anvisning på att avgången är försenad.— CAN, om anledningen är en annullering.— CSN, för en förändring av callsign.— OTH, för alla andra orsaker eller om anledningen är okänd.
A.15.1. ICAO
A.15.1.1. Samordningsstatusen och anledningen skall vara i fälttyp 18-format.
A.15.1.2. Samordningsstatusen och anledningen skall innehålla följande
element som en tiokaraktärsgrupp:
— STA efterföljt av ett snedstreck.
— Beteckningen som bekräftar den nya statusen på underrättelsen/
samordningen.
— Beteckningen som specificerar anledningen.
A.15.2. ADEXP
Primärt fält ”cstat”.Hjälpbegreppen ”coordstatusident” och ”coordstatusreason” skall
innehålla den nya statusen och anledningen enligt ovanstående
beskrivning.
A.16. Tilldelad kurs (endast ADEXP)
Primärt fält ”ahead” skall innehålla antingen
— kursen som tilldelats en flygning, uttryckt i grader,
eller
— om ingen kurs är tilldelad, beteckningen ”ZZZ”, t.ex. när ett
SDM-meddelande används för att indikera att en tidigare till-
delad kurs inte längre gäller.2000R2082 — SV — 15.06.2002 — 001.001 — 65
▼B
▼B
A.17. Tilldelad fart (endast ADEXP)
Primärt fält ”aspeed” skall innehålla antingen
— farten som tilldelats en flygning, uttryckt i knop, Machtal eller
kilometer/timme,
eller
— om ingen fart har tilldelats, beteckningen ”ZZZ”, t.ex. när ett
SDM-meddelande används för att indikera att en tidigare till-
delad fart inte längre gäller.
A.18. Tilldelad stig-/sjunkhastighet (endast ADEXP)
Primärt fält ”rate” skall innehålla
— stig- eller sjunkhastigheten som tilldelats en flygning, uttryckt i
hundratal fot per minut,
eller
— om ingen stig- eller sjunkhastigheten tilldelats, beteckningen
”ZZZ” i sifferdelen av fältet, t.ex. när ett SDM-meddelande
används för att indikera att en tidigare tilldelad stig-/sjunkhas-
tighet inte längre gäller.
A.19. Tillstånd till direkt flygväg (endast ADEXP)
En direkt flygväg, , ej definierad som en ATS-flygväg, mellan två
punkter. Punkterna kan definieras som antingen en känd referens-
punkt eller en distans och en bäring från en referenspunkt. Alla
beteckningar på slutpunkter som används skall vara bilateralt
överenskomna, dvs. kända av båda systemen.
Primärt fält ”DCT” med följande innehåll:
— Den punkt vid vilken avvikelsen har begärts att påbörjas, defini-
erad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt, enligt
definition i samma meddelande genom primärt fält ”REF”,
eller
— värdet ”ZZZ” om den sändande enheten inte kräver att avvi-
kelsepunkten fastställs.
— den punkt belägen längs den ursprungliga flygvägen till vilken
flygplanet har beviljats, eller kommer att beviljas tillstånd, defi-
nierad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt, enligt
definition i samma meddelande genom primärt fält ”REF”.
A.20. Begäran om direkt flygväg
Begäran om en direkt flygväg, ej definierad som en ATS-flygväg,
mellan två punkter. Punkterna kan definieras som antingen en känd
referenspunkt eller en distans och en bäring från en referenspunkt.
Alla beteckningar på slutpunkter som används skall vara bilateralt
överenskomna, dvs. kända av båda systemen.
A.20.1. ICAO
Fälttyp 15, utelämnande den ursprungliga fart/nivå-gruppen, i fält
22-format.
Det skall innehålla:
— den punkt vid vilken avvikelsen har begärts att påbörjas, defini-
erad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt,
eller
— värdet ”ZZZ” om en direkt flygväg begärs av den motta-
gande ATC-enheten.
— förkortningen ”DCT”,2000R2082 — SV — 15.06.2002 — 001.001 — 66
▼B
— åtföljd av den punkt belägen längs den ursprungliga flygvägen
till vilken flygplanet har beviljats, eller kommer att beviljas
tillstånd, definierad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt.
A.20.2. ADEXP
Primärt fält ”DCT” innehållande:
— den punkt vid vilken avvikelsen har begärts att påbörjas, defini-
erad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt, enligt
definition i samma meddelande genom primärt fält ”REF”,
eller
— värdet ”ZZZ” om en direkt flygväg begärs av den motta-
gande ATC-enheten men den exakta punkten vid vilken den
skulle påbörjas inte är känd.
— den punkt belägen längs den ursprungliga flygvägen till vilken
flygplanet har beviljats, eller kommer att beviljas tillstånd, defi-
nierad som
— en känd referenspunkt,
eller
— en distans och en bäring från en känd referenspunkt, enligt
definition i samma meddelande genom primärt fält ”REF”.
A.21. Position (endast ADEXP)
A.21.1. Allmänt
A.21.1.1. Den aktuella positionen på flygningen uttryckt antingen i geogra-
fiska koordinater eller genom bäring och distans från en fastställd
punkt.
A.21.1.2. Primärt fält ”ref” eller ”geo” skall definiera det aktuella horisontella
läget på flygplanet. Punkter som används för distans och bäring i
primärt fält ”ref” skall vara bilateralt överenskomna, dvs. kända i
båda systemen. Primärt fält ”position” skall innehålla det underord-nade fältet ”ptid” vilket hänvisar till den fastställda referenspunkten
eller geografiska punkten. Om tidsinformation skall ingå, skall
antingen underordnat fält ”to” (ttmm) eller ”sto” (ttmmss) användas,
enligt bilateral överenskommelse.
A.22. Överlåtelseanvisning (endast ADEXP)
Primärt fält ”release” skall innehålla ett av följande:
— C, om flygningen erhållit tillstånd att stiga.
— D, om flygningen erhållit tillstånd att sjunka.
— T, om flygningen erhållit tillstånd att svänga.
— F, om flygningen erhållit tillstånd till alla åtgärder.
A.23. Frekvens
A.23.1. ICAO
Fälttyp 18 skall innehålla följande element i fält 22-format:
— FRQ, åtföljt av ett snedstreck.
— 6 siffror som betecknar frekvensen, uttryckt i MHz till tre deci-
maler.
A.23.2. ADEXP
Primärt fält ”freq”.
A.24. Anledning (endast ADEXP)
Primärt fält ”reason”, innehållande värdet ”MANUAL” för manuellt
hänvisade meddelanden.2000R2082 — SV — 15.06.2002 — 001.001 — 67
▼B
A.25. Tilldelad flygnivå (endast ADEXP)
Primärt fält ”cfl”.
A.26. Föreslagen överföringsnivå (endast ADEXP)
Primärt fält ”propfl”.
A.27. Beräknad starttid
A.27.1. ICAO
Fälttyp 13 element (b).
A.27.2. ADEXP
Primärt fält ”etot”.
A.28. Typ av referensmeddelande
Fältet innehåller meddelandetypen enligt specifikation i punkt A.1 i
denna bilaga.
A.28.1. ICAO
Fälttyp 18 i fälttyp 22-format. Elementindikatorn skall vara ”MSG”.
A.28.2. ADEXP
Primärt fält ”msgtyp”.
A.29. Typ av flygning
Denna punkt skall innehålla den data som finns registrerad i
färdplanen eller likvärdig data från en annan källa. Bokstaven ”X”
skall infogas, om typen av flygning inte finns angiven i färdplanen
eller är okänd av någon annan orsak.
A.29.1. ICAO
Typ av flygning skall infogas som enstaka bokstav i fälttyp 22-
format med användande av det oäkta fälttypstalet 80.
A.29.2. ADEXP
Primärt fält flttyp.
A.30. Utrustningens kapacitet och status
I denna punkt anges kapacitet hos och status på den utrustning som
antingen krävs för flygning i vissa luftrum eller på vissa specifice-
rade flygvägar eller som på ett avgörande sätt påverkar
genomförandet av ATC-tjänst. Befintlig kapacitet framgår av
färdplanen men kan visa sig vara felaktig eller ha ändrats under
flygningen. I punkten ”Utrustningens kapacitet och status” specifi-
ceras nuvarande status.
Status på följande skall ingå:
— RVSM-kapacitet
— 8.33 kHz RTF-utrustning
För statliga flygningar, där det är okänt vilken 8.33 kHz RTF-utrust-
ning som finns tillgänglig, skall följande anges i enlighet med vad
som specificerats som typ av flygning i färdplanen:
— UHF-utrustning
A.30.1. ICAO
Datan skall infogas i fälttyp 22-format med användande av det oäkta
fälttypstalet 81.
För varje slags kapacitet skall två element införas:
— Utrustningens kapacitet uttryckt med en enstaka bokstav enligt
vad som anges i fälttyp 10 ”Utrustning” i ICAO-färdplanen (se
bilaga 3 till referensdokument 1), omedelbart åtföljt av en2000R2082 — SV — 15.06.2002 — 001.001 — 68
▼M1
▼M1
— avgränsare – snedstreck(/), omedelbart åtföljd av
— status uttryckt med två bokstäver.
Status skall anges med hjälp av följande indikatorer beroende på
vad som är tillämpligt på flygningen:
a) EQ Flygningen är utrustad, och utrustningen kan användas för
flygningen.
b) NO Flygningen är inte utrustad, eller utrustningen kan av någon
anledning inte användas för flygningen.
c) UN Överensstämmelse med kapaciteten är okänd.
Den första kapacitetsgruppen skall infogas omedelbart efter det
snedstrecksom följer på fälttalet. Efterföljande grupper sk all
åtskiljas med hjälp av ett mellanslag. Ordningsföljden på utrust-
ningens kapaciteter saknar betydelse.
A.30.2. ADEXP
Primärt fält ”EQCST”.2000R2082 — SV — 15.06.2002 — 001.001 — 69
▼B
BILAGA B ( Normativ )
KRAV FÖR BEHANDLING AV SPECIELLA FLYGVÄGAR
B.1. Inledning
B.1.1. Allmänt
B.1.1.1. I denna bilaga beskrivs reglerna och kraven för införande av data i
följande fall, där så tillåts:
— En flygning dirigeras på en direkt kurs över gränsen, utanför
flygvägen, som en följd av ett direkt flygvägssegment finnsregistrerat i färdplanen.
— Efter sändning av ABI- eller ACT-meddelandet, är en flygning
omdirigerad via endera av
— en annan ATS-flygväg,
— en direkt flygväg för att återförenas med den ursprungliga
flygvägen vid en senare punkt.
B.1.1.2. När det gäller omdirigering av flygningar (punkt B.1.1.1), stödjer
det datautbyte som beskrivs i denna bilaga ändring av den plane-
rade flygväg som återfinns i båda systemen genom användandet av
underrättelse- och samordningsmeddelanden.
B.2. Tillämpning av meddelanden
B.2.1. Grundläggande regler för direkta flygvägar
B.2.1.1. Villkoren för användandet av OLDI för samordning av flygningar
på direkta flygvägar skall överenskommas bilateralt.
B.2.1.2. Den data som krävs för underrättelse och samordning av flygningar
på direkta flygvägar består i samordningspunkt (beräknad data
(ICAO-format) och samordningsdata (ADEXP-format)) samt
flygväg i berörda meddelanden.
B.2.2. Registrerad direkt flygväg
Då flygvägen indikerar att flygningen kommer att korsa gränsen på
en direkt kurs, skall det direkta flygvägssegmentet och den resulte-
rande COP ingå i ABI-meddelandet (-meddelandena). Denna COP
inkluderas i det efterföljande ACT- eller RAP-meddelandet.
COP och flygvägsdata skall formateras enligt riktlinjerna i punkt
B.3.2.
B.2.3. Omdirigeringar efter ABI- och före ACT-sändning
Ett nytt ABI-meddelande skall sändas med data som
överensstämmer med den nya flygvägen.
B.2.4. Omdirigering efter ACT-sändning
B.2.4.1. Ett REV-meddelande skall användas för att påvisa en omdirigering
som sker efter det att ACT-meddelandet har sänts men före en viss
bilateralt överenskommen tid före ETO vid tidigare samordnad
COP.
ANMÄRKNING Ett REV-meddelande används endast då den
mottagande enheten inte ändras som ett resultat
av ändringen. Om den ändras, måste ett MAC-
meddelande sändas till den ursprungliga motta-
gande enheten eller samordningen muntligen
upphävas.
B.2.4.2. Meddelandet skall innehålla följande data:
— Samordningspunkt (tidigare COP, i referenssyfte).
— Beräknad data.
— Flygväg.
B.2.4.3. Meddelanden i ICAO-format skall innehålla följande fält:
3 Meddelandetyp och -nummer, meddelandereferens om det är
bilateralt överenskommet.2000R2082 — SV — 15.06.2002 — 001.001 — 70
▼B
7 Flygplansidentifiering. Element b och c skall inte vara
medtagna om inte en ändring av SSR-koden samtidigt
samordnas.
13 Startflygplats.14 Endast element a, innehållande föregående COP i referens-
syfte.
16 Destination.
22 Fält 14, innehållande den beräknade datan för de nya
gränskorsningsförhållandena, i fält 22-format.
22 Fält 15, innehållande den nya flygvägen, i fält 22-format.
B.2.4.4. Meddelanden i ADEXP-format skall, utöver meddelandetyp och -
nummer, flygplansidentifiering, startflygplats, destination och, om
det är bilateralt överenskommet, meddelandets referensnummer,
innehålla
— föregående COP i COP-fältet,
— de nya samordningsförhållandena i COORDATA-fältet,— den nya flygvägen i ROUTE-fältet.
B.2.4.5. Flygvägsändringar som sänds som delar av dialogförfarandet skall
sändas som RRV-meddelanden om det inte är bilateralt överens-
kommet att de skall betraktas som ”normala”.
B.3. Fältens innehåll
B.3.1. ATS-flygvägar
För flygningar som omdirigeras via en alternativ ATS-flygväg, skall
fälten för beräknad data och flygväg formateras som för ABI- och
ACT-meddelanden.
B.3.2. Direkt flygväg
B.3.2.1. Samordningspunkten i den beräknade datan skall vara punkten för
gränskorsning uttryckt som en bäring och en distans från rapport-
punkten. Sådana punkter skall vara bilateralt överenskomna. Då
avståndet är noll eller om en flygning kommer att passera inom ett
bilateralt överenskommet avstånd från en sådan punkt, skall endast
beteckningen på punkten inkluderas.
B.3.2.2. När det är bilateralt överenskommet, kan samordningspunkten för
en flygning på en direkt flygväg uttryckas med hänvisning till
latitud/longitud.
B.3.2.3. Flygvägen skall innehålla följande:
— Den punkt belägen längs den ursprungliga flygvägen från vilken
flygplanet skall dirigeras direkt. När en flygning dirigeras direkt
från ”nuvarande position”, kan punkten uttryckas som en bäring
och en distans från en rapportpunkt. När det har överenskom-
mits bilateralt, kan punkten uttryckas med hänvisning till
latitud/longitud,
— Förkortningen ”DCT”,— Den punkt till vilken flygplanet skall fortsätta direkt,— Återstoden av den fortsatta flygvägen (FRF), om den är känd i
det sändande systemet.
B.4. Exempel
B.4.1. Direkta flygvägar
B.4.1.1. ABI- och ACT-meddelanden
B.4.1.1.1. Flygningen (identifiering Jetset 253) skall korsa gränsen på en
direkt kurs från punkt A (PTA), till punkt C (PTC) varefter den
kommer att följa ATS-flygväg UA134. Systemet fastställer en
COP med bäring 350 och distans 22 NM från punkt B (PTB).2000R2082 — SV — 15.06.2002 — 001.001 — 71
▼B
Följande ABI-meddelande sänds:
— ICAO
(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-
EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)
— ADEXP
-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L
-SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP
LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -
ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB
-BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT
PTC UA134
B.4.1.1.2. ACT-meddelandet har samma format som ABI-meddelandet,
förutom att flygningens flygväg valfritt kan inkluderas.
B.4.1.2. REV-meddelande
Flygning HZT2051 var tidigare föremål för följande ACT-medde-
lande (eller ADEXP-motsvarighet):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
Flygningen dirigeras därefter från 40 NM väst er om punkt RQA
direkt till MYY. Den punkt som är närmast gränskorsningen är2000R2082 — SV — 15.06.2002 — 001.001 — 72
▼B
TDS från vilken avståndet till den faktiska korsningspunkten är 26
NM vid bäring 240 grader. Följande ändringsmeddelande sänds:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
ADEXP-motsvarigheten till meddelandet är:
-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG
-SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -
ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310
-REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -
ROUTE N0458F310 RQA270040 DCT MYY
Ett efterföljande ändringsmeddelande indikerar att TDS240026 är
COP.
B.4.2. Omdirigering via ATS-flygvägar efter ACT-sändning
B.4.2.1. ACT-meddelande
Flygning GKP217 är planerad att dirigeras via samordningspunkt
EMT. Följande ACT sänds:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
2000R2082 — SV — 15.06.2002 — 001.001 — 73
▼B
Flygningen omdirigeras följaktligen via ATS-flygväg UM247 inom
den sändande centralens luftrum till ny samordningspunkt XAT
efter vilket den skall följa ATS-flygväg UJ124. Den mottagande
centralen kvarstår. Följande ändringsmeddelande skickas:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
Flygningen får sedan tillstånd till FL290, vilket resulterar i följandemeddelande (innehållande den nya COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. ADEXP-motsvarigheter
ADEXP-motsvarigheterna till de två ändringsmeddelandena är
följande:
a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -
ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -
ROUTE N0430F290 UM247 XAT UJ124
b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G
-SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA
-PTID XAT -TO 1225 -TFL F290 -ADES DTTA2000R2082 — SV — 15.06.2002 — 001.001 — 74
▼B
BILAGA C (Informativ)
DIALOGFÖRFARANDEFASER (SYSCO NIVÅ 1) — MEDDELANDEFÖLJD
Meddelandeföljd
2000R2082 — SV — 15.06.2002 — 001.001 — 75
▼B
BILAGA II
UTFORMNINGEN AV UTBYTET AV ATS-DATA (ADEXP) UTGÅVA 2.0
(Eurocontrol-dokument DPS.ET1.ST09-STD)2000R2082 — SV — 15.06.2002 — 001.001 — 76
▼B
INNEHÅLLSFÖRTECKNING
MEDDELANDE OM UPPHOVSMANNARÄTT
FÖRORD1. OMFATTNING2. HÄNVISNINGAR3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
3.1. Beteckningsnorm3.2. Definitioner3.3. Uppbyggnad3.4. Vedertagna regler3.5. Operativa benämningar3.6. Förkortningar
4. GRUNDREGLER FÖR ADEXP
4.1. Textat, direkt läsbart format4.2. Identifierade och sökbara fält4.3. Oidentifierade fält
5. SYNTAXREGLER FÖR ADEXP
5.1. Lexikaliska element5.2. Fält
6. NORMALISERAD BESKRIVNING AV ADEXP-MEDDELANDEN
6.1. Inledning6.2. Hjälputtryck6.3. Definition av primära fält6.4. Definition av underordnade fält6.5. Meddelandegrupper
BILAGA A (NORMATIV) DEFINITIONER AV FÄLTEN
BILAGA B (NORMATIV) CENTRAL FÖRTECKNING ÖVER TITLAR PÅ ADEXP-MEDDE-
LANDEN
BILAGA C (NORMATIV) CENTRAL FÖRTECKNING ÖVER RESERVERADE MEDDELANDE-
TITLAR
BILAGA D (NORMATIV) CENTRAL FÖRTECKNING ÖVER RESERVERADE FÄLTBILAGA E (INFORMATIV) INTRODUKTION AV MEDDELANDEGRUPPERBILAGA F (INFORMATIV) EXEMPEL PÅ ADEXP-MEDDELANDEFORMATBILAGA G (INFORMATIV) FRAMTIDA VIDAREUTVECKLINGAR2000R2082 — SV — 15.06.2002 — 001.001 — 77
▼B
MEDDELANDE OM UPPHOVSMANNARÄTT
Detta dokument har sammanställts av Eurocontrolbyrån.
Eurocontrolbyrån har lagstadgad upphovsmannarätt.Innehållet, eller del därav, är således fritt tillgängligt för representanter för
medlemsstaterna, dockfår k opiering eller spridning av innehållet till någon
annan part inte ske utan skriftligt tillstånd från Eurocontrolbyrån.2000R2082 — SV — 15.06.2002 — 001.001 — 78
▼B
FÖRORD
1. Ansvarig organisation
Denna standard har utarbetats av och upprätthålls av avdelningen
för användares krav (User Requirements Section) inom centralen-
heten för trafikflödeskontroll (Central Flow Management Unit —
CFMU) inom den europeiska organisationen för luftfartssäkerhet,
(Eurocontrol).
2. Eatchips arbetsprogramdokument
Denna standard har tillkommit som ett resultat av Eatchips
arbetsprogramdokument, (EWPD), domänen för databehandling
(DPS), verkställande åtgärd 09.
3. Godkännande av standarden
3.1. Denna standard har antagits i överensstämmelse med de förfa-
randen som beskrivs i Eurocontrols standardiseringsanvisningar,
Ref. 000-2-93, Utgåva 1.0.
3.2. Bestämmelserna i denna standard trädde i kraft 1995, då utgåva
1.0 antogs av Eurocontrols ständiga kommission. Standarden tillä-
mpas från och med den 1 december 1997.
4. Tekniska rättelser och ändringar
Det görs en regelbunden översyn av denna standard för att
säkerställa erforderliga ändringar eller tekniska rättelser. Förfa-
randet för upprätthållandet av denna standard är fastställt i
bilaga H i anvisningarna för enhetliga utkast och utformning av
Eurocontrols standarddokument.
Ändringar eller tillägg som påverkar de grundläggande reglerna
eller grammatiken i ADEXP-formatet, skall endast göras i enighet
med de formella förfaranden för översyn som tillhandahålls i
anvisningarna för enhetliga utkast och utformning av Eurocon-
trols standarddokument.
Ändringar eller tillägg till denna standard skall skriftligen föreslås
till centralenheten för trafikflödeskontroll: CFMU, Users Require-
ments Section (ADEXP), Eurocontrol Agency.
5. Redaktionella regler
5.1. Formatet på denna standard överensstämmer med anvisningarna
för enhetliga utkast och utformning av Eurocontrols standarddo-
kument. Det finns dock några avvikelser från anvisningarna. De
små formateringsundantagen från anvisningarna har gjorts för att
undvika förväxling med beteckningssättet i utformningen av
utbytet av ATS-data.
5.2. Följande beteckningssätt har använts för att ange status på respek-
tive utlåtande:
— I normativa delar används det modala hjälpverbet ”skall” och
dessa delar har skrivits med normal text.
—Irekommenderade delar används det modala hjälpverbet
”bör” och dessa delar har skrivits med kursiv stil. Status har
indikerats med hjälp av prefixet Rekommendation .
6. Samband med andra standarder
Denna standard sammanhänger med
Eurocontrolstandard för utbyte on-line av data — OLDI (On-Line
Data Interchange)
7. Status på bilagorna till denna standard
Det finns 6 bilagor till dessa direktiv. Deras respektive status
definieras enligt följande:
Bilaga A Normativ
Bilaga B NormativBilaga C NormativBilaga D NormativBilaga E Informativ2000R2082 — SV — 15.06.2002 — 001.001 — 79
▼B
Bilaga F Informativ
Bilaga G Informativ.
8. Använt språk
Originaltexten i denna standard är skriven på engelska.2000R2082 — SV — 15.06.2002 — 001.001 — 80
▼B
1. OMFATTNING
1.1. ADEXP är ett format, inte ett protokoll. Inga begränsningar ges
beträffande användande av överföringsmedium eller protokoll
som används, med undantag för teckenuppsättningen.
1.2. ADEXP tillhandahåller ett format som i första hand används för
utväxling av meddelanden mellan direktanslutna datorer.
1.3. I detta dokument beskrivs grundreglerna och språkreglerna i
ADEXP-formatet. Det tillhandahåller denna beskrivning i formen
av en omfattande definition av de fält som ingår i ADEXP.
1.4. ADEXP-formatet har specificerats för användning inom följande
områden för utväxling av meddelanden (se avsnitt 2, sidan 3, för
information om dokumenthänvisningar):
— Färdplanering: utbyte av färdplansdata och förknippade
meddelanden mellan systemet för behandling av integrerade
ursprungliga färdplaner (IFPS — Integrated Initial Flight
Plan Processing System), flygtrafikledning (ATS — Air
Traffic Services) och flygplansoperatörer (AO — Aircraft
Operators). (referensdokument 3)
— Flygledningstjänst (ATFM — Air Traffic Flow Management):
utväxling av meddelanden mellan det taktiska systemet
(TACT) inom centralenheten för trafikflödeskontroll (CFMU
— Central Flow Management Unit), AO samt ATS.
(referensdokument 5)
— Samordning av flygkontrolltjänst (ATC): utväxling av taktiska
samordnande meddelanden mellan ATC-enheter (ATCU).
(referensdokument 6)
— Luftrumsledning: utbyte av data mellan enheter för nationella
flygtrafikledningsenheter (ATS-enheter), CFMU samt AO,
rörande luftrummets tillgänglighet. (referensdokument 7)
— Civil-militär samordning: meddelanden rörande civil och
militär flygdata samt meddelanden rörande förflyttningar i
luftrummet. (referensdokument 7).
1.5. Detaljerade beskrivningar rörande hantering och innehåll för
meddelanden inom var och en av de ovanstående grupperna
återfinns i de dokument till vilka hänvisningarna gjorts.
2. HÄNVISNINGAR
2.1. Följande dokument och standarder innehåller bestämmelser vilka,
genom hänvisningar i denna text, utgör bestämmelser i denna
Eurocontrolstandard.
Vid tidpunkten för publiceringen av denna Eurocontrolstandard
var de anvisade utgåvorna av hänvisade dokument och standarder
gällande.
Vid samtliga revisioner av de dokument från Internationella civila
luftfartsorganisationen (ICAO) till vilka hänvisning här skett,
skall omedelbart revision av denna Eurocontrolstandard tas i
beaktande.
Revidering av de övriga dokument som refererats till, skall icke
utgöra del av bestämmelserna i denna Eurocontrolstandard förrän
de är formellt genomgångna och införlivade i denna Eurocon-
trolstandard.
Vid konflikt mellan bestämmelserna i denna Eurocontrolstandard
och innehållet i de övriga dokument till vilka hänvisning skett,
gäller denna Eurocontrolstandard.
2.2. Vid tidpunkten för denna utgåva har referenser i denna standard
gjorts till dokumenten i nedanstående sammanställning.
Användare uppmanas emellertid att kontrollera användarförfa-
randet och tabellerna för sammansättning av meddelandefälten i
de senaste utgåvorna av dessa dokument.
1. ICAOs Chicagokonvention, bilaga 10, volym I, utgåva daterad
november 1985.
2. ICAOs Chicagokonvention, bilaga 10, volym II, utgåva
daterad juli 1995.
3. IFPS and RPL Dictionary of Messages, utgåva 1.0, daterad
mars 1998.2000R2082 — SV — 15.06.2002 — 001.001 — 81
▼B
4. ”Rules of the Air and Air Traffic Services”, PANS-RAC Doc
4444, utgåva daterad november 1985 (inklusive ändring nr 6
daterad november 1995).
5. Guide To ATFM Message Exchange Eurocontrol Document
Ref. TACT/USD/MSGGUID, utgåva 6.0, gällande från mars
1998.
6. Eurocontrol Standard for On-Line Data Interchange,
utgåva 2.0, daterad oktober 1996.
7. Functional Specifications for System Support to Airspace Data
Distribution and Civil Military Co-ordination, utgåva 1.0,
daterad maj 1996.
3. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
3.1. Beteckningsnorm
Den norm som används för att definiera syntax är betecknad
Backus Naur Form (BNF). BNF definierar en uppsättning regler,
vilka fastställer en grupp av teckenrader. I detta fall är gruppen
av teckenrader den uppsättning av meddelanden som kan kallas
för ett syntaktiskt giltigt ADEXP-meddelande.
3.2. Definitioner
I denna Eurocontrolstandard avses medtecken: ett skrifttecken eller en uppsättning av skrifttecken som
kan ”utvinnas” av en lexikalisk analyseringsfunktion genom
närvaron av avgränsare,
symbol: alla ”beteckningar” som förekommer i en BNF-föreskrift
men ej är ett skrifttecken,
terminal symbol : en symbol som representeras av en serie skrif-
ttecken,
icke-terminal symbol : en symbol som representeras av en eller
flera terminala symboler.
ANMÄRKNING En icke-terminal symbol kan även represen-
teras av en blandning av terminala och icke-
terminala symboler.
3.3. Uppbyggnad
3.3.1. BNF består av en uppsättning regler eller konstruktioner enligt
formatet
symbol::= uttryck
ANMÄRKNINGAR
1)Beteckningen ”::=” betyder ”kan ersättas av”.
2)Beståndsdelen ”symbol” kategoriseras som icke-terminal.
3)Beståndsdelen ”uttryck” innehåller terminala och icke-termi-
nala symboler.
3.3.2. Terminala symboler framställs som en serie av skrifttecken vilka
kan identifieras som ett tecken av en lexikalisk analyseringsfunk-
tion genom närvaron av avgränsare.
3.4. Vedertagna regler
I denna Eurocontrolstandard gäller följande:
—Terminala symboler skrivs med stora bokstäver (versaler).
ANMÄRKNING Enligt vedertaget bruk betyder den termi-
nala symbolen NIL ”ingen terminal
symbol”.
Den används i alternativ enligt följande
exempel:
a::= b ( c | NIL ) där a kan ersättas av (b
följt av c) eller av endast b.
—Icke-terminala symboler (t.ex. den vänstra sidan av en gram-
matisk sammansättning) skrivs med små bokstäver (gemener).2000R2082 — SV — 15.06.2002 — 001.001 — 82
▼B
—Skrifttecken och serier av bokstäver som förekommer i
reglerna omges av enkla citationstecken (') respektive dubbla
citationstecken (").
Exempel1) HYPHEN::= '-'
2) title::= '-' "TITLE" titleid
I vissa fall av datautformning, kan det vara nödvändigt att
särskilja terminala och icke-terminala symboler genom andra
metoder än användandet av versaler och gemener.
Närhelst det fordras att uttryckligen särskilja terminala och icke-
terminala symboler, på annat sätt än att använda versaler och
gemener, rekommenderas tillägg av ett suffix enligt följande:
”_at” för ett hjälputtryck, ”_pf” för ett primärt fält och ”_sf” för
ett underordnat fält.
3.5. Operativa benämningar
I denna Eurocontrolstandard används följande operativa benäm-
ningar:
Valfrihet: När det är tillåtet för vissa giltiga symboler både att
förekomma och att inte förekomma inom grammatiken. De
valfria symbolerna omges av hakparentes ”[” och ”]”.
Avslut:När en grupp med symboler kan uppträda noll eller flera
gånger. Symbolerna omges av klammer ”{” och ”}”. Om en siffra
har specificerats framför tecknet ”{”, anger denna det minimala
antalet gånger som gruppen av symboler får förekomma. Om en
siffra har specificerats efter tecknet ”}”, anger denna det maxi-
mala antalet gånger som gruppen av symboler får förekomma.
Urval:Närhelst ett antal alternativa symboler förekommer vid
något tillfälle i grammatiken. Valet representeras som ett
lodstreck”|”.
Hoplänkning: Förekomst av symboler som förekommer i sekvens,
även om en eller flera avgränsare kan förekomma i densamma.
Förekomsten av detta är inte entydig. Det finns två typer:
—Fast hoplänkning: på lexikalisk nivå, vissa regler kan inne-
fatta hoplänkning av terminaler och indikera att de strikt
följer varandra (utan avgränsare mellan dem). I dessa fall
skall utropstecken ”!” användas.
Exempel datetime:: = date ! timehhmm
t.ex. "9912251200" vilket innebär den 25 december 1999,
klockan 12:00.
—Lös hoplänkning: den tillåtna närvaron av avgränsare mellan
terminaler. Förekomsten av lös hoplänkning inom en regel
kan vara antingen underförstådd eller explicit.
Exempel1) Underförstådd:
dct::= '-' "DCT" point point
2) Explicit:
dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
t.ex. "-DCT NTM RMS".
ANMÄRKNING
1)Hoplänkning skall alltid ha företrädesrätt över urval. Parente-
serna ”(” och ”)” används för att förändra ordningsföljden
för utvärdering av uttrycket.
Exempel a::= B C | D är likvärdigt
med:a::= (B C) | D
och EJ med: a::= B (C | D).
2)Inom alla regler lämnas den tillåtna närvaron av avgränsare
mellan symbolerna underförstådd för att läsbarheten skall
bibehållas .2000R2082 — SV — 15.06.2002 — 001.001 — 83
▼B
Rekommendation När det finns risk för oklarhet beroende på
rangordning mellan de ovan nämnda operativa beteckningarna,
rekommenderas användandet av parenteserna i syfte att förtyd-
liga den önskade utvärderingsföljden.
3.6. Förkortningar
I denna Eurocontrolstandard används följande förkortningar med
de betydelser som här anges:
ACH Meddelande om förändring i ATC-färdplan (ATC
Flight Plan Amendment Message)
ADEG ATS-gruppen för utbyte av data (ATS Data
Exchange Group)
ADEXP Utformningen av utbytet av ATS-data (ATS Data
Exchange Presentation)
AFIL Färdplan registrerad under flygning (Air-Filed
Flight Plan)
AFP Förslag till ATC-färdplan (ATC Flight Plan
Proposal)
AFTN Luftfartens fasta fjärrskriftnät (Aeronautical Fixed
Telecommuni-cation Network)
ANM Meddelande från ATFM (ATFM Notification
Message)
AO Flygoperatör(er) (Aircraft Operator(s))APL ATC-färdplan (ATC Flight Plan)ATC Flygkontrolltjänst (Air Traffic Control)ATCU ATC-enheter (flygkontrollorgan) (Air Traffic
Control Unit(s))
ATFM Flygledningstjänst (Air Traffic Flow Manage-
ment)
ATS Flygtrafikledning (Air Traffic Services)
BNF Backus Naur Form (Syntaxregler)
CASA Datorstödd slot-tilldelning (Computer Assisted
Slot Allocation)
CIDIN Gemensamt nätverkför datautbyte inom ICAO
(Common ICAO Data Interchange Network)
CFL Tilldelad flygnivå (Cleared Flight Level)CFMU Centralenheten för trafikflödeskontroll (Central
Flow Management Unit)
CMTP Allmän medellång tidsplan (Common Medium-
Term Plan)
CNL Annulleringsmeddelande (Cancellation Message)
CTOT Beräknad starttid (Calculated Take-Off Time)
DPS Domänen för databehandling (Data Processing
Systems Domain)
ECAC Europeiska konferensen för civil luftfart
EFL Planerad flygnivå (Estimated Flight Level)EOBT Beräknad ”off-block”-tid (Estimated Off-Block
Time)
ETO Beräknad Time Over (Estimated Time Over)
Eurocontrol Europeiska organisationen för luftfartssäkerhetEWPD Arbetsprogramdokument för Eatchip (EATCHIP
WorkProgramme Document)
FIR Flyginformationsregion (Flight Information
Region)
FIW Arbetsstation för inläsning av färdplaner (Flight
Plan Input Workstation)
FMP Befattning inom trafikflödeskontroll (Flow Mana-
gement Position)
FNM Underrättelsemeddelande från flygning (Flight
Notification Message)
FPL Inlämnad färdplan (ICAO format) (ICAO Flight
Plan Message)
GAT Allmän flygtrafik(General Air Traffic)
IA Internationellt alfabet2000R2082 — SV — 15.06.2002 — 001.001 — 84
▼B
IAFP Förslag till individuell ATC-färdplan (Individual
ATC Flight Plan Proposal)
ICAO Internationella civila luftfartsorganisationenIFPD Individuell färdplansdata (Individual Flight Plan
Data)
IFPS Integrerat system för behandling av ursprungliga
färdplaner (Integrated Initial Flight Plan
Processing System)
IFPU Enhet för IFPS (IFPS Unit)IFR Instrumentflygregler (Instrument Flight Rules)ISO Internationella standardiseringsorganisationenITA Internationellt telegrafialfabet
LAM Logiskt bekräftelsemeddelande (Logical Acknow-
ledgement Message)
LRM Logiskt meddelande om ogiltighet (Logical
Rejection Message)
MAC Meddelande om ogiltigförklarad samordning (Co-
ordination Abrogation Message)
MFS Medelande från Shanwick(Message from Shan-
wick)
OAT Operativ flygtrafik(Operational Air Traffic)
OLDI Utbyte on-line av data (On-Line Data Inter-
change)
RFL Begärd flygnivå (Requested Flight Level)
RFP Ersättningsfärdplan (Replacement Flight Plan)RFPD Data från repetitiv färdplan (Repetitive Flight
Plan Data)
RPL Repetitiv färdplan (Repetitive Flight Plan)
RVR Bansynvidd (Runway Visual Range)
SFL Supplementär flygnivå (Supplementary Flight
Level)
SRD Dokument för mjukvarukrav (Software Require-
ments Document)
SSR Sekundär övervakningsradar (Secondary Surveil-
lance Radar)
TACT CFMUs taktiska system (Tactical System of the
CFMU)
TOS Trafikorienteringsplan (Traffic Orientation
Scheme)
UIR Övre flyginformationsregion (Upper Information
Region)
VFR Visuellflygregler (Visual Flight Rules)
4. GRUNDREGLER FÖR ADEXP
4.1. Textat, direkt läsbart format
4.1.1. Formatet i ADEXP är i textform, baserat på skrivtecken.
4.1.2. ADEXP-meddelanden är direkt läsbara för en operatör, vilket
förbättrar möjligheterna till anpassning i operationella ärenden.
4.1.3. Ett textformat är dessutom mer överskådligt och begripligt.
4.2. Identifierade och sökbara fält
4.2.1. Ett meddelande i ADEXP-format skall bestå av fält.4.2.2. Fält skall avgränsas genom användandet av ett speciellt fältstart-
tecken (”-”) och identifieras med specifika nyckelord.
ANMÄRKNING Det bör noteras att vissa fält (de som syntak-
tiskt definieras såsom innehållande
”CHARACTER”) får innehålla ett bindestreck
”-” som del av innehållet i fältet.
4.2.3. Denna uppbyggnadsmetod förbättrar formatets utbyggnadsmöjlig-
heter och stabilitet. (Om ett fält saknas eller är felaktigt kan det2000R2082 — SV — 15.06.2002 — 001.001 — 85
▼B
hoppas över, och övriga delar av meddelandet kan ändå tolkas.
(Se avsnitt 4.3)
4.2.4. En annan konsekvens är att ordningsföljden på fälten i ett medde-
lande inte har någon betydelse för fastställandet av dess giltighet,
förutom det första fältet (obligatoriskt titelfält) som avgör vilka
fält som är tillåtna.
4.2.5. Fält kan vara enkla eller sammansatta.
4.2.6. Beståndsdelarna i ett sammansatt fält kallas underordnade fält och
definieras genom förekomsten av nyckelord, avgränsade av
fältstarttecken.
4.2.7. Enkla fält är fält som inte innehåller underordnade fält.4.2.8. De enkla eller sammansatta fälten som utgör den första defini-
tionsnivån i ett meddelande kallas för dess primära fält.
4.2.9. Alla lägre uppbyggnadsdelar definieras som underordnade fält,
vilka i sin tur kan vara enkla eller sammansatta.
4.2.10. Sammansatta fält förekommer som två typer, strukturerade fält
eller listfält.
4.2.11. Strukturerade fält har ett fördefinierat innehåll uppbyggt uteslu-
tande av underordnade fält. Ordningsföljden på underordnade
fält i ett strukturerat fält SAKNAR betydelse.
4.2.12. Listfält påbörjas med nyckelordet BEGIN och avslutas med nyck-
elordet END. Mellan dessa kan återkommande förekomster av
samma underordnade fält eller kombination av underordnade fält
äga rum. Ordningsföljden på förekomsten inom ett listfält är
viktigt för betydelsen.
4.2.13. I följande avsnitt används begreppet ”fält” allmänt i betydelsen
primära fält och/eller underordnade fält om annat ej uttryckligen
sägs.
4.2.14. Fält i ett meddelande kan vara valfritt eller obligatoriskt beroende
på dess syntax.
4.3. Oidentifierade fält
4.3.1. Om ett oidentifierat fält förekommer i ett meddelande, skall detta
ignoreras.
4.3.2. Med andra ord, om systemet som analyserar meddelandet inte
känner igen ett nyckelord, kommer all text fram till nästa kända
primära fält, som inte ligger inom ett listfält, att ignoreras.
4.3.3. Det ignorerade fältet antingen kan eller kan inte, beroende på
meddelandets titel, komma att orsaka att det analyserade medde-
landet förkastas.
ANMÄRKNING Noteras bör, att trots att ADEXP är utformat
för att tillhandahålla denna typ av flexibilitet,
är det de som ansvarar för definitionen av
gränssnittskraven som, för varje meddelande,
måste använda sitt omdöme för att indikera
hur systemet bör reagera på ett oidentifierat
fält.
4.3.4. Om det oidentifierade fältet är ett listfält (vilket har påträffats
genom nyckelordet -BEGIN), ignoreras hela dess innehåll (fram
till det korresponderande nyckelordet -END).
4.3.5. För att undvika tvetydigheter i samband med att funktionen
återupptas efter utelämnande av ett oidentifierat fält, krävs det
att ett nyckelord påbörjar antingen ett primärt fält eller ett under-
ordnat fält.
4.3.6. Detta möjliggör definitionen av två typer av nyckelord:
— Primära nyckelord.
— Sekundära nyckelord.
4.3.7. När typen av nyckelord väl är definierat, skall detta ej längre
återanvändas i en annan grupp av meddelanden i egenskap av
den andra typen, med undantag av om det förekommer inne i ett
listfält utan att orsaka tvetydighet, då närvaron av nyckelordet
BEGIN indikerar att den interna förekomsten kan komma att
betraktas såsom ett underordnat fält.2000R2082 — SV — 15.06.2002 — 001.001 — 86
▼B
Exempel (på användning av typer av nyckelord)
1) Primärt fält
-RFL F330
2)Underordnat fält: alltid inom ett ”sammansatt fält”
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W
där -GEO är ett primärt sammansatt fält och -GEOID, -
LATTD samt LONGTD är alla underordnade fält.
3) Listfält
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTSdär ”-BEGIN” är listfältets indikator och ”RTEPTS” är ett
primärt fält.
ANMÄRKNING ”RFL” är definierat som ett primärt fält. Det
enda tillfället då ett primärt fält får användas
som ett underordnat fält är då det primära
fältet inkluderas i ett listfält. (Se Exempel 3
ovan.)
5. SYNTAXREGLER FÖR ADEXP
5.1. Lexikaliska element
5.1.1. Teckenuppsättning
5.1.1.1. Den teckenuppsättning som skall användas för utväxling av
meddelanden i ADEXP- format skall vara det internationella alfa-
betet nummer 5 (IA-5) enligt definition i referensdokument 1.
5.1.1.2. ADEXP-formatet har utformats som ett utbytesformat dator till
dator och kan sändas via olika datornätverk eller via dedikerade
linjer mellan datorer. Dessutom finns ett behov av att kunna
utväxla vissa ADEXP-meddelanden, normalt för färdplanering
och flygledningstjänster (ATFM), på luftfartens fasta fjärrskriftnät
(AFTN).
5.1.1.3. Meddelanden som kan behöva sändas via AFTN skall ha sina
teckenuppsättningar begränsade till de tecken som har en direkt
överensstämmelse med internationellt telegrafalfabet nummer 2
(ITA-2) och IA-5, enligt definition i referensdokument 1.
ANMÄRKNING Förutom skrifttecken och formatkommandon,
enligt nedanstående definition, definierar tecke-
nuppsättningen ITA-2 ”signaler” (som
exempelvis perforerade band). Dessa är inte
del av den tillåtna teckenuppsättningen för
ADEXP-meddelanden.
5.1.1.4. De tecken som är tillåtna för användning i ADEXP-meddelanden
som får sändas via AFTN, är de skrifttecken och formatkom-
mandon som definierats nedan:
Skrifttecken
a) Stora bokstäver, versaler (A till Z)
b) Siffror (0 till 9)
c) Speciella grafiska tecken, enligt följande:
1) mellanslag ” ”
2) vänsterparentes ”(”3) högerparentes ”)”
4) bindestreck”-”
5) frågetecken ”?”6) kolon ”:”
7) punkt ”.”
8) komma ”,”9) apostrof ”'”
10) likhetstecken ”=”2000R2082 — SV — 15.06.2002 — 001.001 — 87
▼B
11) plustecken ”+”
12) snedstreck”/”
Formatkommandon
a) Valsretur
b) Radmatning
5.1.2. Grundläggande lexikaliska enheter
Följande lexikaliska enheter har definierats för användning i
denna specifikation:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'— ALPHANUM ::= ALPHA | DIGIT— SPACE ::= ' '— HYPHEN ::= '-'— FEF ::= Carriage_return | Line_Feed— SEP ::= 1{ SPACE | FEF }— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF— START-OF-FIELD ::= HYPHEN
ANMÄRKNING LIM_CHAR representerar vilken som helst av
de tillåtna tecknen med undantag av HYPHEN
(bindestreck), vilket har reserverats för att indi-
kera början av ett fält. I motsats till detta,
representerar CHARACTER vilket som helst av
de tillåtna enheterna i teckenuppsättningen.
5.1.3. Linjer och avgränsare
5.1.3.1. Uppdelningen av texten i ett meddelande till rader skall inte ha
någon syntaktisk påverkan.
5.1.3.2. En avgränsare kan vara ett mellanslag eller ett formatkommando.
5.1.3.3. Fält skall beskrivas endast genom förekomsten av ett fältstart-
tecken efterföljt av ett nyckelord.
5.1.3.4. Följaktligen kan hela meddelandet bestå av en rad.
5.1.4. Teckenberoende värden
5.1.4.1. Det kan vara nödvändigt att ange ett numeriskt värde som nega-
tivt.
5.1.4.2. Fält där ett negativt värde krävs, skall, inom definitionen för dess
syntax, uttryckligen ange värdet som ett teckenberoende värde,
dvs. som antingen positivt eller negativt. Ett fält som ej har defi-
nierats på detta vis får inte representera ett negativt värde.
5.1.4.3. Ett ”teckenberoende värde” skall alltid föregås av antingen
bokstaven ”N”, i betydelsen negativ, eller ”P”, i betydelsen
positiv. Ett nollvärde kan föregås av antingen ”N” eller ”P”.
5.1.4.4. Syntax för ett fält som tillåter ett ”teckenberoende värde” skall
vara enligt följande:
'-' "NØGLEORD" ("P" | "N") ! 1{DIGIT}
Exempel Ett fält med beteckningen ”NUMBER”, vilket kan
innehålla ett negativt värde bestående av en till åtta
siffror, skulle definieras som
'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8
vilket innebär följande: -NUMBER P5 — motsvarar värdet
+5
-NUMBER N5 — motsvarar värdet
-5
-NUMBER 5 — ogiltigt syntax.
Antingen måste
ett ”P” eller ett
”N” förekomma2000R2082 — SV — 15.06.2002 — 001.001 — 88
▼B
5.1.5. Nyckelord
5.1.5.1. Ett nyckelord är en följd, vilken som helst, av stora bokstäver
(versaler) eller siffror. Det introducerar ett fält endast då det
föregås av ett fältstarttecken (”-”).
keyword::= 1{ ALPHANUM }
5.1.5.2. Nyckelord skall överensstämma med följande syntax:
'-'!{SEP}!"NØGLEORD"!1{SEP}! <subfield/s or contained
value>
dvs. ett nyckelord skall vara skilt från dess ”fältstarttecken” med
noll eller fler avgränsare. Det skall omedelbart åtföljas av en eller
fler avgränsare, följda av motsvarande underordnat fält eller
ingående värde.
ANMÄRKNING Det är viktigt att notera, att ett nyckelord och
dess föregående fältstarttecken får avdelas med
vilket som helst antal av avgränsare, även
ingen.
Exempel (Alla de följande sekvenserna redovisar ett giltigt
fält.)
1) -TITLE IFPL
2) - TITLE IFPL
3) - TITLE IFPL
4) -
TITLE IFPL
5.1.5.3. Rekommendation Det är rekommenderad praxis att undvika
användandet av en avgränsare mellan fältstarttecknet ”-” och
det efterföljande nyckelordet.
ANMÄRKNING1) I ovanstående exempel är det första fallet det rekommenderade
valet.
2) Det är också viktigt att notera att ett nyckelord omedelbart
måste åtföljas av minst en avgränsare.
5.1.5.4. Genom hela dokumentet gäller att hoplänkningen av element
åtskilda av åtminstone en avgränsare representeras otvetydigt av
beteckningen ”lös hoplänkning” (se 3.5).
ANMÄRKNING Som kommer att förklaras senare, inleder nyck-
elord också listfält när dessa föregås av nyckelordet BEGIN.
5.1.5.5. Nyckelord skall hållas så korta som möjligt samtidigt som de
måste ha en meningsfull språklig innebörd.
5.1.5.6. De fördefinierade nyckelorden i ADEXP-formatet som listas
nedan, får inte omdefinieras eller användas i annan mening
inom ramen för specifikanvändning av formatet.
TITLE: identifierar en kategori av meddelanden och
definierar den korresponderande uppsättningen
av tillåtna primära fält.
BEGIN: identifierar början av ett listfält.
END: identifierar slutet av ett listfält.COMMENT: identifierar ett COMMENT fält.
5.1.5.7. För att förhindra tvetydighet (användning av samma nyckelord
med olika innebörd) eller redundans (olika nyckelord med samma
innebörd), upprätthålls en central definitionstabell för primära fält
(dvs. primära nyckelord) i bilaga A (A3) i denna standard, och en
central definitionstabell för underordnade fält (dvs. sekundära
nyckelord) i bilaga A (A4).
5.2. Fält
5.2.1. Fältsyntax
field::= basic_field | structured_field | list_fieldbasic_field::= '-' keyword contained_values2000R2082 — SV — 15.06.2002 — 001.001 — 89
▼B
contained_values::= {CHARACTER}
list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword
structured_field::= '-' keyword field_1 field_2 ….field_nANMÄRKNING Som det kommer att visa sig då det gäller
listfält, föregås nyckelordet inte direkt av ”-”
utan av konstruktionen ”-””BEGIN”.
5.2.2. Sammansättning av meddelanden med avseende på beteckning på
fält
5.2.2.1. Det första fältet i ett ADEXP-meddelande skall alltid vara ett
titelfält (dvs. ett fält som påbörjas med nyckelordet TITLE).
5.2.2.2. Det efterföljande innehållet i ett meddelande, i form av dess
primära fält, skall definieras genom dess TITLE.
5.2.2.3. Syntaxen i de meddelanden som motsvaras av en TITLE skall
definieras genom de fält som ingår (vilka definieras av derasnyckelord):
— Namnet och tillåtet innehåll i dess primära fält.
— Namnet och tillåtet innehåll i dess sekundära fält.
5.2.3. Enkla fält
5.2.3.1. Syntaxen för enkla fält skall vara enligt följande:
basic_field::= '-' keyword contained_values
5.2.3.2. Uttrycket ”Contained_values” definierar den text som tillhan-
dahåller betydelsen på fältet och får inte påbörja något
underordnat fält.
Regelexempel arctyp::= '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")
ANMÄRKNING1) En otvivelaktig, likvärdig regel för vilket gäller:
arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype |
"ZZZZ").
2) Exempel på del av meddelande
"-ARCTYP ZZZZ".
5.2.3.3. Rekommendation När ett enkelt fält innehåller fler än två
värden, och det dessutom förekommer ett behov av att uttrycka
ett urval eller valfrihet mellan värdena, rekommenderas att fältet
görs som ett strukturerat fält och att värdena inkluderas i under-
ordnade fält.
5.2.4. Listfält
5.2.4.1. Syntaxen för listfält skall vara enligt följande:
list_field::='-' "BEGIN" keyword { subfields } '-' "END" keyword
5.2.4.2. De underordnade fälten kan vara vilken kombination som helst av
underordnade fält vilka tillåts förekomma noll eller flera gånger
inom listfältet.
5.2.4.3. Listan över underordnade fält inom ett givet listfält skall utgöra
en ordningsföljd (ordningsföljden på underordnade fält är betydel-
sefull).
Regelexempel addr::= '-' "BEGIN" "ADDR" { fac } '-' "END"
"ADDR"
ANMÄRKNING
1) Detta exempel visar, att ett ”addr” fält är ett listfält innehål-
lande 0 eller flera förekomster av ett ”fac” underordnat fält
(en ATS installation).
2) En exempeldel av ett meddelande som visar ADDR som ett
listfält innehållande FAC underordnade fält är:
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.2000R2082 — SV — 15.06.2002 — 001.001 — 90
▼B
3) Ett exempeldel av ett meddelande som visar en kombination
av underordnade fält är:
xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".
5.2.5. Strukturerade fält
5.2.5.1. Syntaxen för ett strukturerat fält skall vara enligt följande:
structured_field::= '-' keyword field_1 field_2…field_n
5.2.5.2. De tillåtna, ingående underordnade fälten i ett givet strukturerat
fält skall endast vara beroende på det strukturerade fältet i sig
själv.
5.2.5.3. Ordningsföljden på förekomsten av underordnade fält i ett struk-
turerat fält skall inte vara betydelsefullt, vilket senare medger
enkla förlängningar (genom tillägg av nya underordnade fält).
Regelexempel pt::= '-' "PT" ptid [fl] [eto]
ANMÄRKNINGAR
1) Detta definierar ”pt” fältet som ett strukturerat fält innehål-
lande en punkt (”ptid” underordnat fält), valfritt följt av en
beräknad flygnivå (”fl” underordnat fält), valfritt följd av en
beräknad tidpunkt över punkten (”eto” underordnat fält).
2) Ett exempel på förekomst av detta fält kan vara:
"-PT -PTID RMS -FL F250 -ETO 921225120000".
5.2.5.4. Rekommendation Närhelst man kan ana att innehållet i ett fält
senare kan komma att utvecklas, är det önskvärt att göra det till
ett strukturfält. Detta kommer att tillåta gradvis utökning av dess
underordnat fält. I motsats till detta kan ett enkelt fält vara
lättare eller mer bekant att använda men det påtvingar en fast
följd av element (värden) med mycket reducerade utbyggnads-
möjligheter.
5.2.6. COMMENT fältet
5.2.6.1. Comment fältet introducerar ett område för fri text där alla
tillgängliga tecken, utom fältstarttecknet (”-”), kan användas, och
som utsträcker sig till nästa fält.
comment::= '-' "COMMENT" { LIM_CHAR }
Exempel -COMMENT THIS IS THE BEGINNING OF A FREE
ROUTE TEXT AREA
5.2.7. Titelfältet (TITLE)
5.2.7.1. Det första fältet i ett ADEXP-meddelande skall alltid vara ett
titelfält TITLE. Syntaxen för detta skall vara enligt följande:
title::= '-' "TITLE" 1{ ALPHA }10
5.2.7.2. De möjliga värdena i ett titelfält består av en uppsättning av
ADEXP-meddelandetitlar som listats i bilaga B i denna standard.
Exempel -TITLE IFPL
6. NORMALISERAD BESKRIVNING AV ADEXP-MEDDE-
LANDEN
6.1. Inledning
6.1.1. Följande avsnitt beskriver hur formatet i ADEXP för olika typer
av meddelanden skall beskrivas på ett normaliserat sätt inom
ramarna för nuvarande standard.
6.1.2. Den normaliserade beskrivningen omfattar:
— Definition av hjälputtryck;
— Definition av varje primärt fälts syntax och betydelse;
— Definition av varje underordnat fälts syntax och betydelse;
— Definition av varje grupp av meddelanden med hänvisning till
dess beskrivande dokumentation.
6.1.3. Denna standard tillhandahåller inte detaljerna för sammansättning
av fält eller regler för insättande av data i varje meddelandetitel.2000R2082 — SV — 15.06.2002 — 001.001 — 91
▼B
6.1.4. Hänvisningar skall göras till den beskrivande dokumentationen
(specifikation av gränssnitt) som är tillämpbar för varje medde-
landegrupp. (Se avsnitt 6.5.7).
6.1.5. Beskrivande dokumentation skall, på ett normaliserat sätt, tillhan-
dahålla följande information för varje meddelandetitel:
— en lista över obligatoriska primära fält;
— en lista över valfria primära fält;— reglerna för insättande av data i varje fält och, i synnerhet,
reglerna berörande användandet av underordnade fält vilka
definierats som valfria inom denna standard;
— reglerna beträffande återskapande efter upptäckt av ett oiden-
tifierat fält.
6.1.6. De fält, för användning inom de olika kategorierna av medde-
landen som används i ADEXP, som för närvarande är
definierade och accepterade av medlemsstaterna i Eurocontrol, är
de som föreskrivs i bilaga A i detta dokument.
6.1.7. Ett fält skall inte användas i annat syfte än för de som fastställts i
dess betydelsebeskrivning.
6.1.8. Ett centralt register över reserverade fält finns i bilaga D. ”Reser-
verade fält” har inte godkänts för användning i den nuvarande
definitionen av ADEXP-meddelanden. Normalt är dessa fält
sådana som har bedömts kunna komma till användning i fram-
tiden, eller som används lokalt i nationella system. Syftet med
att inkludera dem i denna standard, är att bidra till att säkerställa
att fälttitlar förblir unika och att förhindra onödig övertalig
förekomst.
6.2. Hjälputtryck
6.2.1. I syfte att tillhandahålla en läsbar definition av fält, är det ofta
användbart att införa hjälputtryck i den grammatiska beskriv-
ningen.
6.2.2. Hjälputtryckinnehåller inte något fält eller underordnat fält och
är således inte associerat med något speciellt nyckelord. De kan
emellertid förekomma i definitionen av mer än ett fält eller
underordnat fält, eller hjälputtryck. T.ex. kan ett hjälputtryck
som ”date” användas i definitionen av många fält.
6.2.3. Alla nödvändiga hjälputtrycksk all införas i alfabetisk
ordningsföljd och finns definierade i bilaga A (A2) i denna stan-
dard.
6.2.4. Beskrivningen kan presenteras, sorterad i alfabetisk ordning, i en tabell enligt följande:
Hjälputt-
ryckSyntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fältAnvänt
i
hjälpu-
ttryck
adexpmsg { CHARACTER } Fri text
anpassad till
syntax
beskriven för
ett ADEXP-
meddelande.ifpdlong
rfpdlong
preproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadiokommu-
nikation, navi-
gation och
hjälputrustning
för inflygning.ceqpt
aircraftid 1{ ALPHANUM
}7Flygplansiden-
tifikation.arcid
arcidk
arcidoldprevarcid2000R2082 — SV — 15.06.2002 — 001.001 — 92
▼B
6.3. Definition av primära fält
6.3.1. Alla primära fält som används i ADEXP-meddelanden skall
överensstämma med det syntax och den betydelse som angivits i
bilaga A (A3) i denna standard.
6.3.2. Syntax för varje fält anges först, och därefter anges dess bety-
delse i enkel otvetydig klartext.
6.3.3. Syntax för fälten uttrycks genom användandet av BNF-normen,
vilken beskrivits i avsnitt 3 i denna standard.
6.3.4. Beskrivningen kan presenteras, sorterad i alfabetisk ordning, i en tabell enligt följande:
— Den första kolumnen representerar den vänstra delen av en BNF-regel (dvs. delen
av regeln till vänster om symbolen ”::=”), och den tredje kolumnen representerar
dess högra del.
— Den andra kolumnen (Typ) indikerar om ett fält är enkelt (”e”) eller sammansatt
(”s”).
Primärt fält Typ Syntax Betydelse
eobt b '-' "EOBT" timehhmm Beräknad ”off-block”-tid
6.4. Definition av underordnade fält
6.4.1. Alla underordnade fält som används i ADEXP-meddelanden skall
överensstämma med det syntax och den betydelse som angivits i
bilaga A (A4) i denna standard.
6.4.2. Dessutom är, i korsreferenssyfte, det primära fältet, i vilket ett
givet underordnat fält förekommer, identifierat.
6.4.3. Ett underordnat fält kan också vara ett underordnat fält eller
andra underordnade fält. Därför ges även en korsreferens till
dessa underordnade fält.
6.4.4. Beskrivningen kan presenteras, sorterad i alfabetisk ordning, i en tabell enligt följande:
Underordnat
fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt
i under-
ordnat
fält
brng b '-' "BRNG"
refbearingBäring från en
punkt avläst frånett navigations-
hjälpmedel (i
magnetiska
grader)ref
6.5. Meddelandegrupper
6.5.1. De operativa kategorierna (grupperna) av meddelanden som har
definierats för användning i ADEXP-formatet, beskrivs i bilaga E
i denna standard.
6.5.2. Grupperna definieras med avseende på den operativa naturen av
de meddelanden som utväxlas och är ofta utmärkande för berörda
system.
6.5.3. Hänvisning till den definierande dokumentationen skall göras för
varje meddelandegrupp.
6.5.4. Ingen namnbeteckning som redan använts för en meddelande-
grupp skall återanvändas för en annan grupp med annan
betydelse.
6.5.5. Ett centralt register över namnbeteckningar på meddelanden skall
upprätthållas i bilaga B i denna standard.
6.5.6. En hänvisning till berörd grupp ges för varje meddelandenamn
som listats i det centrala registret över meddelandenamn. Hänvis-
ning till den definierande dokumentationen för varje
meddelandenamn tillhandahålls därför via meddelandegruppen.
6.5.7. Ett centralt register över reserverade meddelandenamn finns
också i bilaga C. ”Reserverade” meddelandenamn har ännu inte2000R2082 — SV — 15.06.2002 — 001.001 — 93
▼B
accepterats för användning inom de nu fastställda meddelande-
grupper som använder ADEXP. Normalt är dessa meddelanden
som har bedömts kunna komma till användning i framtiden inom
någon av de fastställda grupperna, eller som används i nationella
system. Syftet med att inkludera dem i denna standard, är att
bidra till att säkerställa att meddelandenamn förblir unika och att
förhindra onödig övertalig förekomst.2000R2082 — SV — 15.06.2002 — 001.001 — 94
▼B
BILAGA A (Normativ)
DEFINITIONER AV ADEXP-FÄLTEN
A.1.Inledning
Denna bilaga tillhandahåller en sammanställning av alla fält: hjälputt-
ryck, primära fält och underordnade fält som har definierats för
användning i ADEXP.
A.2.ADEXP-hjälputtryck
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeRadioutrustning för
kommunikation,
navigering och
inflygning.ceqpt
aircraftid 2{ ALPHANUM }7 Flygplansidentitet. arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7”Wildcard”-format
av flygplansidentitet
att användas då
frågeställning görs i
meddelandeform:
”?” ersätter ett
tecken
”+” ersätter ett
obegränsat antal
tecken.arcidk
atsroute 2 {ALPHANUM} 7 Beteckningen på en
ATS- färdväg.atsrt refatsrte
century 2{DIGIT}2 De två första siff-
rorna i ett århund-
rade.fulldate
coorstatusident 3 {ALPHA} 3 En beteckning på
koordinationstatusen
för en flygning.statid
coorstatus-
reason3 {ALPHA} 7 Anledningen till
meddelande om en
förändring av koor-
dinationsstatusen.statreas-
on
country 2{ALPHA}2 ICAO:s tvåbokstav-
skod för ett land.refatsrte
datalink1 {'S' | 'H' | 'V' | 'M'
}4ICAO:s beteckning
för datalänkens
möjligheter.
Får innehålla vilket
som helst av
värdena: S, H, V
eller M i valfri
ordning men utan
upprepning.dat2000R2082 — SV — 15.06.2002 — 001.001 — 95
▼B
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
date year ! month ! day En datumangivelse i
formatet,
YYMMDD.
T.ex. 930424 = den
24 april 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm En datumangivelse
enligt ovanstående
beskrivning omedel-
bart åtföljd av en
tidsangivelse i
formatet, HHMM.
T.ex.
9304240930=0930Z
den 24 april 1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6En datumangivelse
som kan innehåla
”Wildcard”.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITEtt tvåsiffrigt tal
som kan innehålla
siffrorna från 00 till
31.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Beteckning på typen
av nödradioutrust-
ning ombord på
flygplanet. Kan vara
en eller fler av de
definierade tecknen
i valfri ordning men
utan upprepning.splr
eqptcode 1 {ALPHANUM} 2 Kod som identifi-
erar en utrustnings-
kapacitet. Är
eventuellt identisk
med equipmentcodeeqpt
eqptstatus 2 {ALPHA} 2 Kod bestående av
två bokstäver för
status på flygplanets
kapaciteteqpt
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' )} 24En giltig ICAO
kodbokstav som
indikerar utrust-
ningen ombord. Kan
vara en eller fler av
de definierade
tecknen i valfri
ordning men utan
upprepning.aidequip-
ment2000R2082 — SV — 15.06.2002 — 001.001 — 96
▼M1
▼B
▼B
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
errorcode 1{DIGIT}4 Kodnummer för
felmeddelande.error
fieldid 1{ ALPHANUM } Giltigt ADEXP-
fältnamn (dvs nyck-
elord).errfield
ifpsmod
firindicator 4{ ALPHA }4 En ICAO beteck-
ning på en FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4En flygnivå uttryckt
antingen som; ”F”
eller ”A” åtföljt av
tre siffror eller, ”S”
eller ”M” åtföljt av
fyra siffror.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'Anledningen till
speciell hantering
enligt indikering i
fält 18 element
”STS/”.
EMER = Nödläge
HUM = Humanitär
flygning
HOSP = Sjuktran-
sport
SAR = Eftersökning
och räddning
HEAD = Statsöver-
huvud
STATE = Statlig
flygningsts
flightrule 'I' | 'V' | 'Y' | 'Z' Beteckningen på
flygreglerna för en
flygning.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Typ av flygning
enligt de av ICAO
använda beteck-
ningarna.flttyp
flighttypechg 'OAT' | 'GAT' Den beteckning som
ges då en ändring
av flygtypen till
”OAT” eller ”GAT”
görs under
pågående flygning.chgrul ptrulchg
fulldate century ! year !
month ! dayEn datumangivelse i
formatet
CCYYMMDD
T.ex. 19970801 =
den 1 augusti 1997.fulldate-
time
fulldatetime fulldate ! timehhmm Ett datum, som
beskrivits i ”full-
date”, omedelbart
åtföljt av en tids-
angivelse i formatet
HHMM
T.ex.
199708010930=09-
30 den 1 augusti
1997.mesval-
period
geoname "GEO" !
2{DIGIT}2Beteckningen för en
given geografisk
position uttryckt i
latitud och longitud.geoid
heading 3{DIGIT}3 Ett tresiffrigt tal
mellan 001 och 360.ahead2000R2082 — SV — 15.06.2002 — 001.001 — 97
▼B
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
icaoaerodrome 4{ ALPHA }4 Fyrbokstavs ICAO-
koden för en flyg-
plats.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4”Wildcard” format
av icaoaerodrome,
att användas då
frågeställning görs i
meddelandeform:
”?” ersätter ett
tecken
”+” ersätter ett
obegränsat antal
tecken.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3ICAO-beteckningen
på en flygplanstyp.arctyp
icaomsg { CHARACTER } Ett ICAO-medde-
lande.
(i överensstäm-
mande med syntax
beskrivet i Ref. {4})msgtxt
ifpuid 1{ ALPHANUM } Beteckningen på en
IFPS enhet.ifpuresp
latitudelong 6{ DIGIT }6 En latitud uttryckt
med sex siffror.lattd
latitudeside 'N' | 'S' En beteckning på
”Nordlig” eller
”Sydlig” latitud.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4ICAO-beteckningen
för typen av
flytvästar ombord.
Kan vara en eller
fler av de defini-
erade tecknen i
valfri ordning men
utan upprepning.splj
longitudelong 7{ DIGIT }7 En longitud uttryckt
med sju siffror.longtd
longitudeside 'E' | 'W' En beteckning på
”Östlig” eller
”Västlig” longitud.longtd
machnumber 'M' ! 3{ DIGIT }3 Machtalet. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Beteckning på typen
av ändring gjord i
ett fält.ifpsmod
month ('0' | '1' ) ! DIGIT Månad uttryckt med
ett tvåsiffrigt tal.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Beteckningen för de
dagar i veckan då
en RPL är aktiv.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Beteckningen för de
dagar i veckan då
en RPL är aktiv.
”Wildcard”-tecken
kan också användas.daysk2000R2082 — SV — 15.06.2002 — 001.001 — 98
▼B
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
originatorid 1{ ALPHANUM
}10Identiteten på den
ursprungliga
avsändaren av ett
meddelande.orgnid
qrorgn
point 2{ ALPHANUM }5 Beteckningen för en
betydelsefull punkt.
Kan vara en
kungjord punkt, en
geografiskpunk t, en
referenspunkt eller
en konstruerad
punkt såsom en
omdöpt punkt (”re-
named” point,
RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Referensbäring. brng
refname "REF" ! 2{DIGIT}2 Beteckningen för en
punkt uttryckt i
bäring och avstånd
från en kungjord
punkt.refid
regulid 1{ ALPHANUM
}20Beteckningen för en
ATFM-föreskrift
som berör en flyg-
ning.regul regid
renameid "REN" !
2{DIGIT}2Beteckningen för en
omdöpt punkt.renid
rrteid 1{ ALPHANUM}
20Beteckningen för en
omplanerad färdväg.rrteref
rtf 6{DIGIT}6 En radiofrekvens
uttryckt i MHz med
tre decimaler.freq
rulechg 'VFR' | 'IFR' Beteckningar som
används under flyg-
ning för att indikera
en förändring i
flygreglerna.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSekunder. Ett
tvåsiffrigt tal mellan
”00” och ”59”.eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Hastighet.
Uttryckt i antingen
”K” eller ”N” åtföljt
av fyra siffror.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 ICAO-beteckningen
för den SSR-utrust-
ning som finns
ombord och,
valfritt, beteck-
ningen för
datalänkmöjligheter.seqpt
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Beteckningen för ett
”uppehåll” (”stay”),
en period med
”speciell aktivitet”
inom flygningensfärdväg.ptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4ICAO-beteckningen
för överlevnadsut-
rustningen ombord.
Kan vara en eller
fler av de defini-
erade tecknen i
valfri ordning men
utan upprepning.spls2000R2082 — SV — 15.06.2002 — 001.001 — 99
▼B
HjälputtryckSyntax BetydelseAnvänt i
primärt
fältAnvänt i
under-
ordnat
fältAnvänt i
hjälputt-
ryck
text20 1{ LIM_CHAR }20 Text bestående av 1
till 20 tecken,
utöver bindestreck
(-).altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITTid uttryckt i
timmar (2 siffror
00-23) och minuter
(2 siffror 00-59).
Kan vara tiden på
dygnet eller en
tidsperiod.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' ) ! DIGITEtt obegränsat antal
timmar och minuter,
använt för tidspe-
riod.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Wild card-format
för en tid; hhmm.eobtk
titleid 1{ ALPHA }10 En giltigt ADEXP-
meddelande titel.
(se bilaga B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' ICAO-beteckningen
för wake-turbulens
kategorin.wktrc
year 2{ DIGIT }2 De två sista siff-
rorna i ett årtal.date
fulldate
A.3.ADEXP Primära fält
ADEXP
Primärt
fältTyp Syntax Betydelse
ad C '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Beteckningen för en flygplats. I de
fall då flygplatsen ingår som en del
av färdplanen kan ytterligare
färdinformation lämnas.
ada b '-' "ADA" date Faktiskt ankomstdatum.
adarr b '-' "ADARR" (icaoaerodrome |
'ZZZZ')Faktisk flygplats vid ankomst.
adarrz b '-' "ADARRZ" text20 Namnet på den faktiska flygplatsen
vid ankomst om ingen ICAO-plat-
sbeteckning finns.
add b '-' "ADD" date Faktiskt datum för avgång.2000R2082 — SV — 15.06.2002 — 001.001 — 100
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
addr c '-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Lista med adressater.
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')ICAO-platsbeteckning för flyg-
platsen för avgång eller beteck-
ningen ”AFIL” innebärande en
färdplan som lämnats under flyg-
ning eller ”ZZZZ” när ingen
ICAO-platsbeteckning har tilldelats
flygplatsen för avgång.
adepkb '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Flygplatsen för avgång använd som
databasnyckel i en förfrågan. Kan
innehålla ”Wildcard”.
Kan innehålla en ICAO-platsbe-
teckning eller beteckningen ”AFIL”
innebärande en färdplan som
lämnats under flygning eller
”ZZZZ” när ingen ICAO-platsbe-
teckning har tilldelats flygplatsen
för avgång eller en kombination av
bokstäver och ”wildcard”-tecken.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')”Föregående” flygplats för avgång.
Kan innehålla ICAO-platsbeteck-
ningen eller beteckningen ”AFIL”
innebärande en färdplan som
lämnats under flygning eller
”ZZZZ” när ingen ICAO-platsbe-
teckning har tilldelats flygplatsen
för avgång.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')ICAO-platsbeteckningen för flyg-
platsen för ankomst eller ”ZZZZ”
när ingen ICAO-platsbeteckning
har tilldelats flygplatsen för
ankomst.
adeskb '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Flygplatsen för ankomst använd
som databasnyckel i en förfrågan.
Kan innehålla ”Wildcard”.
Kan innehålla en ICAO-platsbe-
teckning eller beteckningen ”AFIL”
innebärande en färdplan som
lämnats under flygning eller
”ZZZZ” när ingen ICAO-platsbe-
teckning har tilldelats flygplatsen
för ankomst eller en kombination
av bokstäver och ”wildcard”-
tecken.
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')”Föregående” flygplats för
ankomst. Kan innehålla ICAO-plat-
sbeteckningen eller ”ZZZZ” när
ingen ICAO-platsbeteckning har
tilldelats flygplatsen för ankomst.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Innehåller ett ADEXP-meddelande.
afildata c '-' "AFILDATA" ptid fl eto Planerade data för en färdplan som
lämnats under flygning
En punktidentifiering, den anslu-
tande flygnivån och planerat datum
och tid vid punkten.
ANMÄRKNING: Angiven flygnivå
är den nivå för vilken flygningen
har beviljats för inträde i kontrol-
lerat luftrum ovanför den identifi-
erade punkten. Den behöver inte
vara densamma som RFL.
ahead b '-' "AHEAD" (heading | "ZZZ") Kursen som anvisats för en flyg-
ning, uttryckt i grader.
Måste vara ett tresiffrigt tal eller
värdet ”ZZZ” som indikerar att
ingen kurs har anvisats.2000R2082 — SV — 15.06.2002 — 001.001 — 101
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
altnz b '-' "ALTNZ" text20 Namnet på en alternativ flygplats
om ingen ICAO-platsbeteckning
finns.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')ICAO-platsbeteckningen för den
första alternativflygplatsen för
ankomst eller beteckningen
”ZZZZ” då ingen ICAO-platsbe-
teckning har tilldelats flygplatsen.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')ICAO-platsbeteckningen för den
andra alternativflygplatsen för
ankomst eller beteckningen
”ZZZZ” då ingen ICAO-platsbe-
teckning har tilldelats flygplatsen.
aobd b '-' "AOBD" date Faktiskt ”off-block”-datum.aobt b '-' "AOBT" timehhmm Faktisk ”off-block”-tid.arcid b '-' "ARCID" aircraftid Flygplanets identitet.
Kan vara flygplanets registrerings-
beteckning eller ICAO-beteck-
ningen för dess operatör åtföljt av
flygningens identifiering.
arcidkb '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Flygplanets identitet använt som
databasnyckel i en förfrågan; kan
innehålla ”wildcard”.
Måste vara en kombination av
alfanumeriska och ”wildcard”
tecken upp till maximalt 7 tecken
totalt.
arcidold b '-' ARCIDOLD aircraftid Föregående flygplansidentitet. När
flygplanets identitet skall ändras,
skall den nya beteckningen anges i
”ARCID”.
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Flygplanstyp (ICAO beteckningen
för typen) eller ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")Den nuvarande anvisade flyghas-
tigheten angiven i kilometer per
timme, knop eller Machtal.
Måste vara ”M” åtföljt av tre
siffror, ”K” eller ”N” åtföljt av fyra
siffror eller ”ZZZ” som indikerar
att inga restriktioner har givits för
hastigheten.
ata b '-' "ATA" timehhmm Faktisk ankomsttid.atd b '-' "ATD" timehhmm Faktisk avgångstid.atot b '-' "ATOT" timehhmm Faktisk starttidatsrt b '-' "ATSRT" atsroute point point ATS benämning på färdvägen och
identifiering av dess första och sista
punkter.
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Adressater till vilka ATFM-medde-
landen skall sändas.
ceqpt b '-' "CEQPT" aidequipment Radioutrustning för kommunika-
tion, navigering och inflygning
(enligt ICAO fält 10).
cfl c '-' "CFL" fl [ptid] Tilldelad flygnivå. Den flygnivå
som för tillfället tilldelats piloten
av ATC. (numeriskbenämning av
flygnivån).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointBeteckning för en förändring av
antingen ”flygreglerna” (VFR/IFR)
eller ”typen av flygning” (OAT/
GAT) eller båda tillsammans med
den punkt vid vilken förändringen
inträffar.
cobd b '-' "COBD" date Planerat ”off-block”-datum.2000R2082 — SV — 15.06.2002 — 001.001 — 102
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
cobt b '-' "COBT" timehhmm Planerad ”off-block”-tid.
com b '-' "COM" text20 Kommunikationsutrustning (enligt
ICAO fält 18 COM/).
comment b '-' "COMMENT" 1 { LIM_CHAR
}En allmän kommentar i fri text
utan bindestreck.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Beteckningen för ett ”exceptionellt
förhållande” framfört i samband
med ATFM.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]Förflyttningsförhållandena för en
flygning. En punktidentifiering,
flygnivån och beräknad tid vid
denna punkt samt valfri tilläggsin-
formation om flygnivå.
cop b '-' "COP" point En samordnande punktidentifiering,
antingen en kodad beteckning på
en punkt eller ett konstruerat namn
(GEOxx, RENxx eller REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Beteckning för en marschstigning
(cruiseclimb). Ger punkten för då
stigningen skall påbörjas, hastighet
eller machtal samt de två nivåerna
för flygnivåbandet som används
under stigningen. Den andra nivån
kan vara ”PLUS” medan den övre
nivån är okänd.
cstat c '-' "CSTAT" statid [statreason] En beteckning som bekräftar det
nya samordningsförhållandet för en
flygning och, valfritt, orsaken till
förändringen.
ctod b '-' "CTOD" date Beräknat startdatum.ctot b '-' "CTOT" timehhmm Beräknad starttid (CTOT): refe-
renstid för en ATFM-slot.
dat b '-' "DAT" datalinkBeteck ning för flygplanets dataö-
verföringsmöjligheter.
days b '-' "DAYS" numdays Dagar för genomförandet av en
återkommande färdplan (1234567
där 1 står för måndag, 2 för tisdag,
…, med 0 i kolumner där ingen
trafikäger rum).
dayskb '-' "DAYSK" (numdays |
numdayswldcrd)Dagar för genomförandet av en
återkommande färdplan, använd
som databasnyckel i en förfrågan,
kan innehålla ”wildcard”.
daysold b '-' "DAYSOLD" numdays ”Föregående” dagars trafik.
Används som databasnyckel. Då
dagarna för trafikenligt RPL sk all
ändras, skall de nya värdena
angivas i ”DAYS”.
dct b '-' "DCT" point point Indikerar en direkt färdväg mellan
två punkter.
Punkterna kan antingen vara en
giltig ICAO-beteckning eller en
punkt som återfinns i ett GEO,
REN eller REF fält i formatet
GEOxx, RENxx eller REFxx.
delay b '-' "DELAY" timehhmm En tidsperiod som representerar en
försening. Typen av försening, dvs.
försening av en flygning, förfaran-
deförsening etc. beror på samman-
hanget.
depz b '-' "DEPZ" text20 Namn på flygplats för avgång då
ingen ICAO-platsbeteckning finns.2000R2082 — SV — 15.06.2002 — 001.001 — 103
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
desc b '-' "DESC" 1 {LIM_CHAR} Beskrivning av en omständighet
eller företeelse av betydelse för
innehållet i meddelandet.
destz b '-' "DESTZ" text20 Namn på flygplats för ankomst då
ingen ICAO-platsbeteckning finns.
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedFIR identifiering och den ackumu-
lerade förflutna tiden (i timmar och
minuter) till FIR-gränsen.
eetlat c '-' "EETLAT" lattd time Anvisning om förfluten tid till en
position given endast som latitud.
eetlong c '-' "EETLONG" longtd time Anvisning om förfluten tid till en
position given endast som longitud.
eetpt b '-' "EETPT" point timehhmm_e-
lapsedIdentifieringen av en punkt och den
ackumulerade förflutna tiden till
punkten.
endtime b '-' "ENDTIME" day ! timehhmm Tidpunkten vid vilken en tidsperiod
slutar.
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]De färdplansdata som gäller för en
flygning vid den givna punkten
eller vid inträdet till berört luftrum.
Ett eller båda fälten; ”ptid”,
”airspdes”, måste finnas med.
eobd b '-' "EOBD" date Planerat ”off-block”-datum.eobdkb '-' "EOBDK" date Planerat ”off-block ”-datum använt
som databasnyckel i en förfrågan.
Kan innehålla ”wildcard”.
Får vara en kombination av maxi-
malt 6 siffror eller wildcardtecken
totalt.
eobdold b '-' "EOBDOLD" date ”Föregående” planerat ”off-block”-
datum. Används som en databas-
nyckel. Då det planerade ”off-
block”-datumet skall ändras, skall
det nya värdet anges som ”EOBD”.
eobt b '-' "EOBT" timehhmm Beräknad ”off-block”-tid (EOBT)eobtkb '-' "EOBTK" (timehhmm |
timewldcrd)Beräknad ”off-block”-tid använd
som databasnyckel i förfrågan. Kan
innehålla ”wildcard”.
eobtold b '-' "EOBTOLD" timehhmm ”Föregående” planerad ”off-block”-
tid. Används som en databasnyckel.
Då det planerade ”off-block”-
datumet skall ändras, skall det nya
värdet anges som ”EOBD”.
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Lista med koder för utrustningska-
paciteter åtföljda av uppgift om
respektive kapacitets nuvarande
status
errfield b '-' "ERRFIELD" fieldid ADEXP-namn för felaktiga fält.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Felmeddelandetext. Kan valfritt
innehålla en felidentifieringskod.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Beräknad data. En punktidenti-
fiering, planerad flygnivå (flyg-
nivånummer) och beräknat datum-
tid vid denna punkt, valfritt åtföljd
av supplementär flygnivå (flyg-
nivånummer åtföljt av indikatorn Aeller B).
etod b '-' "ETOD" date Planerat startdatum.etot b '-' "ETOT" timehhmm Planerad starttid.2000R2082 — SV — 15.06.2002 — 001.001 — 104
▼M1
▼B
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
extaddr c '-' "EXTADDR" num | { fac } |
(num {fac})Adresser som tillhandahålls utöver
de som är automatiskt fastställda
dvs ”extra adresser”. Får endast
innehålla antalet adresser, de fak-
tiska adresserna eller både och.
filrte b '-' "FILRTE" {LIM_CHAR} Färdvägen exakt som den registre-
rats dvs utan någon behandling.
filtim b '-' "FILTIM" day ! timehhmm Dag-tid-grupp som specificerar när
meddelandet lämnades för
sändning.
flband c '-' "FLBAND" fl fl Ett flygnivåband som definierar
luftrummet vertikalt, inklusive de
flygnivåer som givits.
fltrul b '-' "FLTRUL" flightrule Flygregel, enligt ICAO fält 8.
flttyp b '-' "FLTTYP" flighttype Typ av flygning, enligt ICAO fält
8.
fmp b '-' "FMP" 4{ ALPHA }4 Identifieringen på en befattning
inom trafikflödeskontroll (”Flow
Management Position”).
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Lista med FMP och dess berörda
ATFM-föreskrifter.
freq b '-' "FREQ" rtf Radio frekvens.
fstday b '-' "FSTDAY" date Första dagen för trafikför en repe-
titiv färdplan. Detta används för att
ange den faktiska första dagen för
vilken färdplaner kommer att
upprättas från en RPL (se valfrom-
fältet) eller den första dagen för
vilken en ändring av en RPL gäller.
furthrte b '-' "FURTHRTE" {LIM_CHAR} Den fortsatta färdvägen för en
flygning. Att användas i medde-
landen som innehåller beräknad
data för att indikera den fortsatta
färdvägen för en flygning efter en
beräknad punkt. Den kan innehålla
enbart nästkommande punkt eller
den kompletta kvarvarande
färdvägen till destinationen.
geo c '-' "GEO" geoid lattd longtd Punkt längs färdvägen vilken defi-
nieras genom latitud och longitud
och som anges i färdplanen som
GEOxx (där xx är ett löpnummer).
ifp b '-' "IFP" 1{ALPHA} Beteckning för kända fel inom en
FPL.
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Lista över komplett IFPD
överensstämmande med databas-
nyckeln given i en förfrågan.
Innehåller en lista över komplett
information för varje individuell
flygning som överensstämmer med
givna nycklar för förfrågan.
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Lista över ifpdsum överensstäm-
mande med databasnyckeln given i
en förfrågan.
Innehåller en lista över sammanfat-
tande information för varje indivi-
duell flygning som överensstämmer
med givna nycklar för förfrågan.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8En unikfärdplans identifiering,
tilldelad av IFPS.
ifpsmod b '-' "IFPSMOD" fieldid modifind En beteckning tilldelad av IFPS för
de fält som har modifierats, och
modifieringens beskaffenhet.2000R2082 — SV — 15.06.2002 — 001.001 — 105
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
ifpuresp b '-' "IFPURESP" ifpuid Identiteten på den IFPU som är
ansvarig för en förfrågan. Den
måste behandla förfrågan och
besvara densamma.
ignore c '-' "BEGIN" "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
"END" "IGNORE"Beteckning på förhållanden som
har ”ignorerats” eller förbigåtts i
behandlingen av berört medde-
lande. Ett ”ignorerat” villkor kan
vara begränsat till ett speciellt
avsnitt av färdvägen avgränsat av
de punkter som angivits. Ett igno-
rerat förhållande kan t.ex. vara en
tidsrestriktion (villkor för tillträde
till färdväg), flygnivåbegränsning
eller TOS-överträdelse.
iobd b '-' "IOBD" date ”Ursprungligt””off-block”-datum -
”off-block”-datumet som det angi-
vits i FPL och uppdaterats med
meddelanden associerade med
färdplaner (DLA, CHG, etc.). Detta
är referensdatumet som används för
åtkomst av färdplanen i databasen
och är det enda ”off-block”-datum
som berörd ATS-enhet känner till.
Anmärkning: IOBD påverkas inte
av förändringar som begärs eller
meddelas genom utväxling av
ATFM-meddelanden.
iobt b '-' "IOBT" timehhmm ”Ursprunglig””off-block”-tid —
”off-block”-tiden som den angivits
i FPL och uppdaterats med medde-
landen associerade med färdplaner
(DLA, CHG, etc.). Detta är refe-
renstiden som används för åtkomst
av färdplanen i databasen och är
den enda ”off-block”-tid som
berörd ATS-enhet känner till.
Anmärkning: IOBD påverkas inte
av förändringar som begärs eller
meddelas genom utväxling av
ATFM-meddelanden.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Lista över aktiva villkorade
färdvägar.
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Lista över aktiva tillfälligt avskilda
områden.
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Lista över stängda ATS-färdvägar.
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Lista över FIR, inkluderande
namnet på området följt av
antingen listan över tillgängliga
villkorade färdvägar eller listan
över tillgängliga villkorade
färdvägar, stängda ATS-färdvägar,
aktiva tillfälligt avskilda områden,
restriktioner för reducerat luftrum
och luftrum med reducerad
samordning.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Lista över restriktioner för redu-
cerat luftrum.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Lista över luftrum med reducerad
samordning.2000R2082 — SV — 15.06.2002 — 001.001 — 106
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
lstday b '-' "LSTDAY" date Sista dagen för trafikför en repe-
titiv färdplan. Detta används för att
ange den faktiska sista dagen för
vilken färdplaner kommer att
upprättas från en RPL (se valuntil-
fältet) eller den sista dagen för
vilken en ändring av en RPL gäller.
=> Måste vara ett datum mellan
VALFROM och VALUNTIL.
mach b '-' "MACH" machnumber [ point ] Machtal, uttryckt i hundradelar, och
valfritt den punkt vid vilken
förändringen begärs.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimeGiltighetstiden för ett meddelande,
inklusive de angivna tiderna.
minlineup b '-' "MINLINEUP" timehhmm Minimitiden som krävs för en flyg-
ning, som förklarat sig färdig för
avgång, för förflyttning från nuva-
rande vänteposition till att bli luft-
buren.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Antal ändringar som krävdes för att
korrigera ett ursprungligt medde-
lande.
msgref c '-' "MSGREF" sender recvr
seqnumReferensdata för associerade, tidi-
gare sända meddelanden.
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" "MSGSUM"Innehåller en sammanställning av
ett meddelande.
Anmärkning: Måste innehålla en
eller fler* av fälten arcid, adep,
ades, eobt och orgn men utan
upprepning.* ett eller fler av fälten kan ha
saknats eller varit oläsbara i ett
mottaget meddelande.
msgtxt b '-' "MSGTXT" icaomsg Innehåller ett komplett ICAO
meddelande.
msgtyp b '-' "MSGTYP" titleid Innehåller titeln på det åberopade
eller kopierade meddelandet.
Kan vara vilken godkänd ADEXP-
titel som helst. (se bilaga B).
nav b '-' "NAV" text20 Betydelsefull navigeringsutrustning,
såsom ICAO fält 18 NAV/.
nbarc b '-' "NBARC" 1{ DIGIT }2 Antal flygplan, om fler än ett.nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Antal färdplandata som matchar en
förfrågan. Måste vara mellan 0 och
999.
newctot b '-' "NEWCTOT" timehhmm En ny beräknad starttid, uppdaterad
av TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmEn ny tidpunkt vid vilken en
tidsperiod slutar.
neweobd b '-' "NEWEOBD" date Ett nytt planerat ”off-block”-datum.neweobt b '-' "NEWEOBT" timehhmm En ny planerad ”off-block”-tid.newptot b '-' "NEWPTOT" timehhmm En ny provisoriskstarttid.newrte b '-' "NEWRTE" { LIM_CHAR } En ny färdväg mellan samma flyg-
platser för avgång och ankomst
som i det ursprungliga medde-
landet.
newstart-
timeb -' “NEWSTARTTIME" day !
timehhmmEn ny tid vid vilken en tidsperiod
börjar.
oldmsg b '-' "OLDMSG" { CHARACTER } Ett komplett originalmeddelande,
exakt (och i samma format) som
det erhölls.2000R2082 — SV — 15.06.2002 — 001.001 — 107
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
opr b '-' "OPR" 1 { LIM_CHAR } Namnet på företaget eller agen-
turen som opererar flygningen, som
ICAO fält 18 element OPR/.
orgmsg b '-' "ORGMSG" titleid ADEXP-titeln på ett felaktigt
meddelande, som det emottogs av
TACT.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Adressen till meddelandets
upphovsman.
orgnid b '-' "ORGNID" originatorid Identiteten på en adressat av ett
meddelande.
orgrte b '-' "ORGRTE" { LIM_CHAR } Ursprungliga färdvägen mellan
flygplatserna för avgång och
ankomst.
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Information rörande upphovs-
mannen till ett meddelande. Kan
innehålla typen av nätverkanvänteller berörd adress eller båda.
origindt b '-' "ORIGINDT" datetime Datum och tid för mottagandet av
ett ursprungligt meddelande av
IFPS.
Anmärkning: Detta är inte tiden för
registrering av meddelandet.
Format är ÅÅMMDDTTMM.
part c '-' "PART" num lastnum Identifiering av den del av medde-
landet som igenkänns genom titeln,
registreringstiden och giltighetspe-
rioden.
per b '-' "PER" text20 Flygplans prestandadata, enligt
ICAO fält 18 PER/.
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Positionen på ett flygplan angivet
antingen som en punkt eller som en
flygplats med valfri information om
tidpunkt och flygnivå.
prevarcid b '-' "PREVARCID" aircraftid Föregående använda callsign.prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4SSR-läge och kod använt för flyg-
ningen omedelbart före SSR-läge
och kod angivna i fält ”-
SSRCODE”.
propfl c '-' "PROPFL" tfl [sfl] En flygnivå föreslagen av en
godkännande enhet för genom-
förandet av en flygning.
ptot b '-' "PTOT" timehhmm Provisoriskstarttid. Provisorisk
referenstid för en ATFM-slot.
qrorgn b '-' "QRORGN" originatorid Identiteten på upphovsmannen till
en förfrågan.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Namn på alternativ(a) flygplats(er)
under en flygning.
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Förändringshastighet: stighastig-
heten eller sjunkhastigheten till-
delad ett flygplan uttryckt i
hundratal fot per minut.
=> Måste vara ”C” visande en
stighastighet, eller ”D” visande en
sjunkhastighet, åtföljt av ett
tvåsiffrigt tal som visar den tillde-
lade hastigheten i hundratal fot per
minut. Som alternativ kan beteck-
ningen ”ZZZ” användas för att visa
att det inte finns någon tilldelad
stig- eller sjunkhastighet.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Lista över tidsperioder och dess
respektive flöde för ett ATFM-
villkor.2000R2082 — SV — 15.06.2002 — 001.001 — 108
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
reason b '-' "REASON" 4{ALPHA}12 Anledning till antingen ett avvisat
meddelande eller en annullering av
en slot av TACT.
Informationen om meddelandet är
beroende av dess innehåll.
ref c '-' "REF" refid ptid brng distnc Punkt efter färdvägen som defini-
erats genom magnetiskbäring och
avstånd från en annan punkt och
har givits beteckningen REFxx.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumReferensdata för avsänt medde-
lande.
reg b '-' "REG" 1{ LIM_CHAR }7 Registreringsmärkning, per ICAO
fält 18 REG/.
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Referens till positionen för en
ATFM-föreskrift.
regul b '-' "REGUL" regulid Identifieringen av en föreskrift som
berör en flygning.
rejctot b '-' "REJCTOT" timehhmm Avvisad beräknad starttid: negativt
svar på ett förslag om en förbättrad
slot.
release b '-' "RELEASE" 1{ALPHA}1 En anvisning om att flygningen är
överlämnad från förflyttnings-
övervakare till mottagande överva-
kare.
C = tillstånd att stiga
D = tillstånd att sjunka
T = tillstånd att svänga
F = tillstånd till alla åtgärder
rename c '-' "RENAME" renid ptid Anvisning om att ett tillfälligt, nytt
namn givits till en ”betydelsefull
punkt” som förekommer mer än en
gång i färdbeskrivningen, för att
förhindra förvirring. Detta tillfäl-
liga namn används endast i förtyd-
ligande syfte under återgivandet av
färdvägen och innebär inte en
faktisk förändring av den verkliga
identifieringen av punkten.
respby b '-' "RESPBY" timehhmm Svara senast: tidpunkt vid vilken
ett svar till en förfrågan om
förbättrad slot måste lämnas.
rfl b '-' "RFL" flightlevel [point] Begärd flygnivå (som flygnivåtal,
tiotal meter eller hundratal fot) och
valfritt den punkt vid vilken en
förändring av RFL behövs.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Beteckning på ersättningsfärdplan
(RFP).
Måste vara ”Q” åtföljt av en siffra
(1 - 9).
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Lista över alla RFPD som
överensstämmer med databasnyck-
larna givna i en förfrågan.
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Lista över rfpdsum (sammanfattad
RFPD information) som
överensstämmer med databasnyck-
larna givna i en förfrågan.
rif b '-' "RIF 4{LIM_CHAR} Förändrad färdväg beroende på
tillstånd under flygning och som
avslutas med ICAO-beteckningen
på den nya ankomstflygplatsen.
rmk b '-' "RMK" 1{ LIM_CHAR } Anmärkningar i klarspråk, per
ICAO fält 18 RMK/.2000R2082 — SV — 15.06.2002 — 001.001 — 109
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
route b '-' "ROUTE" {LIM_CHAR} Komplett ICAO fält 15-information
innehållande fart, RFL och färdväg
(i enighet med syntax givet i Ref.
4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockBeskrivning av ett trafikflöde där
färdvägen skall ändras.
rrteref b '-' "RRTEREF" rrteid Referens för ändring av färdväg.
rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockBeskrivning av ett trafikflöde till
vilket trafik skall omfördelas.
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Lista över punkter längs färdvägen.
Kan också innehålla flygplatsbe-teckningar.
rvr b '-' "RVR" 1{ DIGIT }3 Visuellt sikt för rullbana (RVR).
Operativa minima då speciella
meteorologiska förhållanden råder.
Uttrycks i meter.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Lista över tidsperioder och dess
tillämpliga RVR gränsvärden.
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitDen tidsperiod för vilken det givna
RVR gränsvärdet gäller.
sector b '-' "SECTOR" 1{ ALPHANUM }8 Identifiering av en ATC-sektor.sel b '-' "SEL" 4{ ALPHA }5 SELCAL-kod per ICAO fält 18
element ”SEL/”.
sendto c '-' "BEGIN" "SENDTO" {unit} '-'
"END" "SENDTO"Lista över luftnavigeringsenheter
till vilka ett meddelande skall
sändas.
seqpt b '-' "SEQPT" ssrequipment Övervakningsutrustning, per ICAO
fält 10.
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Beteckning på en standard instru-
ment avgång (Standard Instrument
Departure) förfarande.
speed b '-' "SPEED" spd [ point ] Verklig flyghastighet (”airspeed”)
(i kilometer per timme eller knop)
och valfritt, punkten för vilken enförändring i flyghastighet (”airs-
peed”) har begärts.
spla b '-' "SPLA" 1{ LIM_CHAR }50 Färg på markeringar på ett flyg-
plan, per ICAO fält 19 element ”A/
”.
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Kontaktdata, där tilläggsinforma-
tion till färdplan kan erhållas.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Namn på befälhavare, per ICAO
fält 19 element ”C/”.
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Totalkapacitet på livflottar, per
ICAO fält 19 element ”D/”.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Färg på livflottar, per ICAO fält 19
element ”D/”.
spldcov b '-' "SPLDCOV" ('T' | 'F') Livflottar: indikering om de är
täckta, per ICAO fält 19 element
”D/”.T = Ja (True) (=> ”C” i ICAO)
F = Nej (False), ej täckta.
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Livflottar: antal, per ICAO fält 19
element ”D/”.
sple b '-' "SPLE" timehhmm_elapsed Bränsleuthållighet, per ICAO fält
19 element ”E/”.
splj b '-' "SPLJ" lifejackets Livvästar, per ICAO fält 19
element ”J/”.2000R2082 — SV — 15.06.2002 — 001.001 — 110
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
spln b '-' "SPLN" 1{ LIM_CHAR } Annan överlevnadsutrustning och
användbar information, per ICAO
fält 19 element ”N/”.
splp b '-' "SPLP" 1{DIGIT}3 Antal personer ombord, per ICAO
fält 19 element ”P/”.
splr b '-' "SPLR" emergradio Nödradioutrustning, per ICAO fält
19 element ”R/”.
spls b '-' "SPLS" survivaleqpt Överlevnadsutrustning, per ICAO
fält 19 element ”S/”.
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Beteckning på datakällan.
Innehållet beror på TITLE-fältet.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Antingen;
- SSR-läge och kod, per ICAO fält
7 elements b och c.
eller
- bokstäverna ”REQ” innebärande
att koden har begärts.
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Beteckning på en standardförfa-
rande för ankomst (Standard
Arrival).
starttime b '-' "STARTTIME" day !
timehhmmTidpunkt vid vilken en tidsperiod
påbörjas.
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Beteckning på en period under
flygningen med ”speciell aktivitet”
då flygplanet kommer att uppehålla
sig (”stay”) i ett område som defi-
nieras av punkterna och/eller flyg-
platser angivna för indikerad
tidsperiod, exempelvis för utbild-
ning, tankning i luften, flygfotogra-
fering etc.
ANMÄRKNING: Följden i vilken
punkterna och/eller flygplatserna
anges är av betydelse.
stayinfo c '-' "STAYINFO" stayident remarkInformation rörande typen av ak ti-
vitet (utbildning, tankning i luften,
flygfotografering etc.) som skall
genomföras under en ”uppehållspe-
riod” under flygningen.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Anledning till speciellt handha-
vande, per ICAO fält 18 STS/. Kan
vara antingen ”PROTECTED” för
att beteckna känsligt handhavande
eller en av de vedertagna beteck-
ningarna EMER, HOSP, etc. eller
fri text.
taxitime b '-' "TAXITIME" timehhmm Skillnaden i tid mellan ”off block”-
tiden och starttiden. Tiderna som
refererats kan vara faktiska eller
planerade beroende på samman-
hanget.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Beteckningen på en trafikvolym.
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockBeskrivning av en trafikvolym.
title b '-' "TITLE" titleid Meddelandetitel.
ttleet b '-' "TTLEET" timehhmm_elapsed Total beräknad förfluten tid i
timmar och minuter.
typz b '-' "TYPZ" text20 Typ av flygplan då ingen ICAO-
kod finns.2000R2082 — SV — 15.06.2002 — 001.001 — 111
▼B
ADEXP
Primärt
fältTyp Syntax Betydelse
unit c '-' "UNIT" unitid [addrinfo] Information rörande en ”luftnavi-
geringsenhet” dvs en ATC-enhet,
en flygplansoperatör eller färdplan-
sutställare. Innehåller identiteten på
enheten och valfritt adressinforma-
tion.
valfrom b '-' "VALFROM" date Första dagen för vilken en flygning
är schemalagd att genomföras (år,
månad och dag).
valfromkb '-' "VALFROMK" ( date |
datewldcrd )Första dagen för vilken en flygning
är schemalagd att genomföras,
använd som databasnyckel i en
förfrågan, kan vara ”wildcarded”.
Måste vara ett giltigt datum eller en
kombination av ett giltigt datum
och ”wildcard” tecken.
valfromold b '-' "VALFROMOLD" date ”Föregående””valfrom”-datum.
Används som en databasnyckel.
Om första giltighetsdatum skall
ändras, skall det nya datumet anges
i ”VALFROM”.
validitydate b '-' "VALIDITYDATE" date Datum för giltighet.
valuntil b '-' "VALUNTIL" date Sista datum för vilket flygningen är
schemalagd att genomföras. (år,
månad och dag).
valuntilkb '-' "VALUNTILK" ( date |
datewldcrd )Sista dagen för vilken en flygning
är schemalagd att genomföras,
använd som databasnyckel i en
förfrågan, kan vara ”wildcarded”.
Måste vara ett giltigt datum eller en
kombination av ett giltigt datum
och ”wildcard” tecken.
valuntilold b '-' "VALUNTILOLD" date ”Föregående””valuntil”-datum.
Används som en databasnyckel.
Om sista giltighetsdatum skall
ändras, skall det nya datumet anges
i ”VALUNTIL”.
wktrc b '-' "WKTRC" waketurbcat Kategori för vakturbulens (”wake
turbulence”).
A.4.ADEXP Underordnade fält
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
addrinfo c '-' "ADDRINFO"
networktype facAdress information unit
adid b '-' "ADID" icaoaerod-
rome | 'ZZZZ'Beteckningen på en
flygplats. Kan
innehålla ICAO-
beteckningen eller
bokstäverna ”ZZZZ”
om ingen beteckning
har tilldelats.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblockvalperiod
[remark]Beskrivning av alla
delar av en ATS-
färdväg under en
given period.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblockvalperiod
respunit [remark]Beskrivning av alla
delar av ett luftrum-
sområde under en
given period.latsa
lrar
lrca2000R2082 — SV — 15.06.2002 — 001.001 — 112
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Anger ett luftrum-
sområde annat än en
ATS-färdväg.entrydata airspace
brng b '-' "BRNG" refbe-
aringRiktning till en punkt
från ett navigering-
shjälpmedel i magne-
tiska grader.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Typ av omständig-
heter eller begräns-
ningar t.ex. TOS, FL-
begränsning.ignore
crfl1 b '-' "CRFL1" flight-
levelDen lägre gränsen i
ett flygnivåområde i
vilket en stigning till
marschhöjd har
begärts.crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")Den övre gränsen i
ett flygnivåområde
inom vilket en stig-
ning till marschhöjd
har begärts. ”PLUS”
där övre gränsen är
okänd.crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberMach-talet som hålls
under en stigning till
marschhöjd.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd Farten som skall
hållas under en stig-
ning till marschhöjd.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Beräknad tid över en
punkt.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Avstånd från en
punkt från ett navige-
ringshjälpmedel i
nautiska mil. Måste
vara 1 till 3 siffror,
möjligen med inle-
dande nollor.ref
efl b '-' "EFL" flightlevel Beräknad flygnivå. Reser-
verad för
framtida
bruk.
endreg b '-' "ENDREG" day!ti-
mehhmmTidpunkten vid
vilken en ATFM-föreskrift upphör.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusKod för utrustnings-
kapacitet åtföljd av
uppgift om kapacite-
tens nuvarande statuseqcst
eto b '-' "ETO" date !
timehhmm ! secondsBeräknad tid över en
punkt, i år, månad,
dag, timmar, minuter
och sekunder.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]Ett ”exceptionellt
förhållande” framfört
i sammanhanget av
ATFM t.ex. dimma
på en flygplats.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Adressinformation. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender2000R2082 — SV — 15.06.2002 — 001.001 — 113
▼M1
▼B
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
fir b '-' "FIR" 7{ ALPHA
}7Betecknar ett FIR
eller UIR.lfir
fl b '-' " FL" flightlevel Ett allmänt flyg-
nivåfält. Kan vara
”SFL”, ”EFL”,
”CFL”, ”RFL”, etc.
beroende på
sammanhanget.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt
flblockc '-' "FLBLOCK" fl fl Ett flygnivåområde,
”block”, som defini-
erar ett luftrum-
sområde vertikalt,
inkluderande givna
flygnivåer. Ett block
definierat som under
eller över en flygnivå
skall uttryckas
respektive som från
flygnivå 000 till den
specificerade nivån
eller som från den
specificerade flyg-
nivån till flygnivå
999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleBeskrivning av ett
”flöde” med angi-
vande av ursprung-
sområdet, valfritt
med färdvägen eller
punkter som passeras
från ursprung-
sområdet, destina-
tionsområdet och
valfritt med
färdvägen eller
punkter som passeras
på vägen till destina-
tionsområdet.flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Lista över trafik-
flöden.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7Flödesfrekvensen
som regleras av en
ATFM-föreskrift.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'En beteckning på
”betydelsen” inom ett
flöde.
EX = exkluderad
IE = inkluderad
undantagen
EM = undantagen
IN = inkluderadflow
from b '-' "FROM" day!ti-
mehhmmTidpunkten vid
vilken en tidsperiod
börjar.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15En position från
vilken en färdväg, del
av färdväg, en
”resplan” eller ett
flöde påbörjas.
Kan vara ett område,
en flygplats eller en
betydelsefull punkt.flow2000R2082 — SV — 15.06.2002 — 001.001 — 114
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
geoid b '-' "GEOID" geoname Beteckning för en
geografiskpunk t
uppbyggd av ”GEO”
åtföljt av ett sekven-
snummer (exempel:
”GEO12”).geo
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Komplett information
beträffande en indivi-
duell färdplan.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnSammanfattande
information om en
individuell färdplan.
Innehåller fälten
arcid, adep, ades,
eobt och orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Ett tresiffrigt tal som
indikerar slutet av en
sekvens.
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitud i grader,
minuter och sekunder
samt riktning.
(Nordlig eller sydlig.)eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitud i grader,
minuter och sekunder
samt riktning. (Östlig
eller västlig.)eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Beteckning på typen
av nätverksom
används för utväxling
av meddelanden.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Ett tresiffrigt tal. extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7”Väntetal”, används i
ATFM-syften.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgInnehåller ett
komplett ADEXP-
meddelande efter det
att det har behand-
lats.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgInnehåller ett
komplett ADEXP-
meddelande innan det
har behandlats, dvs.
som det mottogs.adexptxt2000R2082 — SV — 15.06.2002 — 001.001 — 115
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Punkt efter en
färdväg.
=> Innehåller en
identifiering av
punkten och valfritt;
- en flygnivå eller ett
flygnivåblock,
- en supplementär
flygnivå,
- en/flera tidsrefe-
rens(er),
- en stigning till
marschhöjd,
- en beteckning på
värdvägen,
- en beteckning på en
period av ”speciell
aktivitet”, dvs. att
flygningen kommer
att uppehålla sig i
området under en
tidsperiod.
Förändring av:
- RFL, flygregler,fart/Machtal.rtepts
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Beteckning under
flygvägen på en stig-
ning till marschhöjd.
Angivande fart eller
Machtal åtföljt av de
två nivåerna som
betecknar flygnivå-
bandet som används
under stigningen.
Den andra nivån kan
vara ”PLUS” där den
övre nivån är okänd.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'En beteckning på
flygreglerna som
gäller för berörd
punkt.entrydata
ptid b '-' "PTID" point Identifiering av
punkt, antingen
kodad beteckning
eller ett fingerat
namn (GEOxx,
REFxx or RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberMachtal, i hundra-
delar av en enhet,
förknippat med en
punkt efter
färdvägen.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'En beteckning på de
”militära” flygreg-
lerna som gäller för
berörd punkt.entrydata
ptrfl b '-' "PTRFL" flight-
levelBegärd flygnivå,
förknippad med en
punkt längs
färdvägen.ad
entrydatapt2000R2082 — SV — 15.06.2002 — 001.001 — 116
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
ptrte b '-' "PTRTE"
2{LIM_CHAR}Färdvägen efter den
indikerade punkten.
Kan vara hela
färdvägen till desti-
nationen eller helt
enkelt avsnittet till
nästa punkt.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgBeteckning på en
förändring i antingen
flygreglerna (VFR/
IFR) eller typen av
flygning (OAT/GAT)
eller båda samt
förknippad med en
punkt efter
färdvägen.ad pt
ptspeed b '-' "PTSPEED" spd Verklig flyghastighet
(”airspeed”) (i kilo-
meter per timme eller
knop) förknippat med
en punkt efter
färdvägen.ad
entrydatapt
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmBeteckning, inom den
registrerade
färdvägen, på en
period med ”speciell
aktivitet” då flyg-
planet kommer att
uppehålla sig (”stay”)
i området under en
tidsperiod, exem-
pelvis för utbildning,
tankning i luften etc.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penrateEn tidsperiod för
vilken det angivna
flödet berörs av en
ATFM-föreskrift.ratepdlst regcond
recvr b '-' "RECVR" fac Mottagaren av refe-
rerat meddelande.msgref
refdata
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]ATS färdvägsbeteck-
ning samt identifi-
ering av första och
sista punkterna.
Punkterna som listats
kan vara ICAO-
beteckningar eller
fiktiva GEOxx,
RENxx or REFxx
punkter. Beteck-
ningen på det land
inom vilket punk-
terna befinner sig kan
valfritt inkluderas.
Ändpunkterna måste
överensstämma med
färdvägsinforma-
tionen.airroute
refid b '-' "REFID" refname Beteckning på en
referenspunkt
bestående av ”REF”
åtföljt av ett sekven-
snummer (exem-
pelvis: ”REF02”).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Referensposition för
en ATFM-föreskrift.rrteto
rrtefrom
tfvexccond
regulation2000R2082 — SV — 15.06.2002 — 001.001 — 117
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Lista över tidspe-
rioder och dess
respektive flödesfrek-
vens för en särskild
föreskrift.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Beskrivning av en
ATFM-föreskrift.regulation
regid b '-' "REGID" regulid Beteckning på en
”föreskrift” från flyg-
ledning.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Lista över ”föresk-
rifter” för flygled-
ningssyften.fmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Ett referensnummer
för en ATFM-
”föreskrift”. Ger en
unikreferens åtföljt
av en giltighetsbe-
teckning.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12Orsaken till en
ATFM-föreskrift.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]En ”föreskrift” införd
i flygledningssyfte.reglist
remarkb '-' "REMARK"
1{LIM_CHAR}En anmärkning. Detta
fältet är en del av
beskrivningen.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Beteckning given till
en punkt som
återupprepas i
färdbeskrivningen.rename
respunit b '-' "RESPUNIT"
12{ALPHA}12Ansvariga ATC-
enheten.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Komplett information
om en repetitiv
färdplan.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilSammanfattning av
information rörande
en repetitiv färdplan.
Den innehåller arcid,
adep, ades, eobt,
orgn, days, valfrom
och valuntil fält.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Visuell sikt för rull-
bana:
Operativa minima då
speciella meteorolo-
giska förhållanden
råder. Uttrycks i
meter.rvrperiod exccond
sender b '-' "SENDER" fac Avsändare av refe-
rerat meddelande.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Serienumret på
avsänt meddelande
(ett 3-siffrigt tal som
är unikt för kombina-
tionen sändare/motta-
gare.msgref
refdata2000R2082 — SV — 15.06.2002 — 001.001 — 118
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
sfl b '-' SFL flightlevel !
('A'|'B')Supplementär
flygnivå. Flygnivån
vid vilken eller
ovanför vilken, eller
vid vilken eller under
vilken en flygning
har samordnats eller
kommer att
samordnas för att
korsa en punkt.
Består av ett
flygnivå-nummer och
ett korsnings-
förhållande (antingen
”A” om flygplanet
kommer att korsa
punkten vid eller
ovanför nivån, eller
”B” om flygplanet
kommer att korsa
punkten vid eller
under nivån).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmTiden vid vilken en
ATFM-föreskrift
träder i kraft.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentBeteckningen på
samordningsstatusen
på en flygning.cstat
statreason b '-' "STATREASON"
coorstatusreasonOrsaken till en
förändring i samord-
ningsstatusen på en
flygning.cstat
stayident b '-' "STAYIDENT"
stayidentifierBeteckningen på en
period med ”speciell
aktivitet” eller ett
”uppehåll” (”stay”)
inom en flygnings
färdväg.stay
stayinfo
sto b '-' "STO" timehhmm
! secondsEtt allmänt tidsfält
som kan innehålla
tiden för en punkt
eller för en flygplats.
Tiden kan vara
planerad, beräknad
eller verklig tid
beroende på
sammanhanget.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Transferering-
sflygnivå. Den
flygnivå vid vilken
en flygning har varit
eller kommer att
samordnas för att
korsa en punkt (flyg-
nivånummer) i plan-
flykt, eller den
godkända flygnivån
till vilken flygningen
fortsätter under stig-
ning eller sjunkning
vid gränspunkten.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identifiering av en
”trafikvolym”.rrteto
rrtefrom
tfvregulation2000R2082 — SV — 15.06.2002 — 001.001 — 119
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
time b '-' "TIME" timehhmm En tidsindikering.
Kan vara faktisk tid
eller en tidsperiod,
beroende på
sammanhanget i
meddelandet.stay
to b '-' "TO" timehhmm ”Time Over/Off”. Ett
allmänt tidsfält som
kan innehålla tiden
för en punkt eller för
en flygplats. Tiden
kan vara planerad,
beräknad eller verklig
tid beroende på
sammanhanget.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15En position från
vilken en färdväg, del
av färdväg, en
”resplan” eller ett
flöde påbörjas.
Kan vara ett område,
en flygplats eller en
betydelsefull punkt.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Beteckning på en
luftnavigeringsenhet,
t.ex. en ATC-enhet,
flygplansoperatör
eller färdplansutstäl-
lare.unit
until b '-' "UNTIL" day!ti-
mehhmmTiden vid vilken en
tidsperiod slutar.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeEn giltighetsperiod,
inkluderande de
givna tiderna.airroute
airspace
via1 b '-' "VIA1" 1
{ALPHANUM} 15En punkt, en ATS-
färdväg eller ett luft-
rumsområde som
antingen är, eller
måste vara längs
färdvägen. När det
krävs indikering av
mer än en, innehåller
detta fält den första i
ordningen.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15En punkt, en ATS-
färdväg eller ett luft-
rumsområde som
antingen är, eller
måste vara längs
färdvägen. När det
krävs indikering av
mer än en, innehåller
detta fält den andra i
ordningen.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15En punkt, en ATS-
färdväg eller ett luft-
rumsområde som
antingen är, eller
måste vara längs
färdvägen. När det
krävs indikering av
mer än en, innehåller
detta fält den tredje i
ordningen.flow2000R2082 — SV — 15.06.2002 — 001.001 — 120
▼B
Under-
ordnat fältTyp Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
via4 b '-' "VIA4" 1
{ALPHANUM} 15En punkt, en ATS-
färdväg eller ett luft-
rumsområde som
antingen är, eller
måste vara längs
färdvägen. När det
krävs indikering av
mer än en, innehåller
detta fält den fjärde i
ordningen.flow2000R2082 — SV — 15.06.2002 — 001.001 — 121
▼B
BILAGA B (Normativ)
CENTRAL FÖRTECKNING ÖVER TITLAR PÅ ADEXP-MEDDELANDE
Titel BeskrivningIntroducerat i
avdelning
ABI Förhandsmeddelande om gränsinformation E.3
ACK Bekräftelsemeddelande E.1
ACP Godkännandemeddelande E.5
ACT Aktiveringsmeddelande E.3
AUP Meddelande om planerat användande av luftrummet E.4
BFD Grundläggande flygdatameddelande E.5
CDN Samordningsmeddelande E.3
CFD Meddelande om förändrade flygdata E.5
CNLCOND Meddelande om annullering orsakad av exceptionella
ATFM-förhållandenE.2.3
CNLREG Meddelande om annullering av ATFM-reglering E.2.3
COD Meddelande om tilldelning av SSR-kod E.3
COF Meddelande om ändrad frekvens E.3
CRAM Tillgänglighet av villkorlig färdväg E.4
DES Meddelande om upphävd indragning E.2.2
ERR Felmeddelande E.2.2
EXCOND ATFM-meddelande om exceptionella förhållanden E.2.3
FCM Bekräftelsemeddelande för flygning E.2.2
FLS Meddelande om inställd flygning E.2.2
FSA Meddelande om första systemaktivering E.2.3HOP Meddelande med förslag till överlämning E.3
IACH Meddelande om individuell ATC-förändring E.1
IAFP Meddelande om individuellt ATC-färdplansförslag E.1
IAPL Meddelande om individuell ATC-färdplan E.1
IARR Meddelande om individuell ankomst E.1
ICHG Meddelande om individuell förändring E.1
ICNL Meddelande om individuell annullering E.1
IDEP Meddelande om individuell avgång E.1
IDLA Meddelande om individuell försening E.1
IFPL Meddelande om individuell färdplan E.1
INF Informationsmeddelande E.3
IRPL Meddelande om individuell repetitiv färdplan E.1
IRQS Meddelande om individuell begäran om tilläggsfärdplan E.1
ISPL Meddelande om individuell tilläggsfärdplan E.1
LAM Logiskt bekräftelsemeddelande E.3, E.5
LRM Logiskt avslagsmeddelande E.3
MAC Meddelande om upphävande av samordning E.3
MAN Meddelande om förestående manuell behandling E.1
MAS Meddelande om manuellt antagande om kommunikation E.3MODCOND ATFM-meddelande om förändrade exceptionella
förhållandenE.2.3
MODREG ATFM-meddelande om förändrade föreskrifter E.2.3
MRA Meddelande om obligatoriskak tivering av färdväg E.2.3
MRCNL Meddelande om annullering av obligatoriskfärdväg E.2.3
MRMOD Meddelande om förändring av obligatoriskfärdväg E.2.32000R2082 — SV — 15.06.2002 — 001.001 — 122
▼B
Titel BeskrivningIntroducerat i
avdelning
NEWREG Meddelande med tillkännagivande om ny ATFM-föreskrift E.2.3
NTA Meddelande om att ingen trafikaccepteras E.2.3
NTACNL Meddelande om upphörandet av ”ingen trafikaccepteras” E.2.3
NTAMOD Meddelande om förändring av ”ingen trafikaccepteras” E.2.3OLRA Meddelande om aktivering av avlastningsfärdväg E.2.3
OLRCNL Meddelande om upphävande av avlastningsfärdväg E.2.3
OLRMOD Meddelande om förändring av avlastningsfärdväg E.2.3
PAC Preliminärt aktiveringsmeddelande E.3
RAP Svarsmeddelande till aktiveringsförslag E.3
RCHG Meddelande om ändrad data för repetitiv färdplan E.1
RCNL Meddelande om annullering av data för repetitiv färdplan E.1
RDY Färdigmeddelande E.2.2
REJ Meddelande med avslag E.1
REV Meddelande om ändring E.3
RJC Meddelande om avslag på samordning E.5
RJT Meddelande om avslag på omdirigering E.2.2
ROF Meddelande med begäran om frekvens E.3
RRP Meddelande med förslag till omdirigering E.2.2
RRV Svarsmeddelande till aktiveringsförslag E.3
SAM Slottilldelningsmeddelande E.2.2
SBY ”Avvakta”-meddelande E.3
SDM Meddelande med tilläggsdata E.3
SIP Meddelande med förslag till förbättrad slot E.2.2
SLC Meddelande med annullering av begäran om slot E.2.2
SMM Meddelande om missad slot E.2.2SPA Meddelande med godkännande av föreslagen slot E.2.2
SRJ Meddelande med avslag på föreslagen slot E.2.2
SRM Meddelande om förändrad slot E.2.2
SRR Meddelande med begäran om förändrad slot E.2.2
TIM Meddelande om påbörjad transfer E.3
UUP Meddelande om uppdaterad användarplan för luftrummet E.4
XAP Meddelande med förslag om alternativ överfart E.5
XCM Meddelande om annulerad överfart E.5
XIN Meddelande med underrättelse om tilltänkt överfart E.5
XRQ Meddelande med begäran om överfart E.52000R2082 — SV — 15.06.2002 — 001.001 — 123
▼B
BILAGA C (Normativ)
CENTRAL FÖRTECKNING ÖVER RESERVERADE MEDDELANDE-
TITLAR
C.1.Inledning
Denna bilaga innehåller en central förteckning över reserverade medde-
landetitlar som ännu inte har definierats för användning i ADEXP. Att
de finns upptagna i denna bilaga indikerar att de antingen förutsetts för
framtida användning, eller att de redan används men att deras använd-
ning är begränsad till lokala system.
C.2.Syfte
Syftet med att tillhandahålla en lista med titlar som ännu ej formellt har
antagits för användning inom denna ADEXP-standard är att förhindra, i
största möjliga utsträckning, antingen skapandet av överflöd närhelst en
ny titel behövs för ett särskilt ändamål eller skapandet av en titel som
redan används i ett lokalt system.
C.3.Reserverade meddelandetitlar
Reserverad Titel Meddelandetyp Reserverad av
ACTARR Aktiveringsmeddelande för en ankomst FRANKRIKE
ACTDEP Aktiveringsmeddelande för en avgång FRANKRIKE
ADMFPL ADMAR2000 färdplansmeddelande TYSKLAND
ADMFPT ADMAR2000 meddelande om avslutad färdplan TYSKLAND
ADMFPU ADMAR2000 meddelande om uppdatering av färdplan TYSKLAND
ANM ATFM meddelande CFMU
ANSWERCT Svarsmeddelande (Terminal Control System) FRANKRIKE
ANSWM Svarsmeddelande (ODS) FRANKRIKE
ANSXFPLCT Svarsmeddelande FRANKRIKE
ATT Landningsmeddelande FRANKRIKE
BEGINPROC Medelande med begäran om start av behandling FRANKRIKE
BEGPROC Meddelande från trafikledare om förfarandestart (ODS) FRANKRIKE
BEGPROCCT Meddelande från trafikledare om förfarandestart
(Terminal Control System)FRANKRIKE
CDA Meddelande om starttillstånd (ARINC 623) FRANKRIKE
CDAFTX Starttillstånd (ARINC 620) FRANKRIKE
CHGDEP Ändringsmeddelande för en avgående flygning FRANKRIKE
CLD Starttillstånd (ARINC 623) FRANKRIKE
CLDFTX Starttillstånd (ARINC620) FRANKRIKE
CNLARR Annullering av en ankomst FRANKRIKECNLCOND Annullering av exceptionella förhållanden CFMU
CNLDEP Annullering av en avgång FRANKRIKE
CNLREG Annullering av an ATFM-bestämmelse CFMU
CONFEND Slutmeddelande till en förändring av operationell konfi-
gurationFRANKRIKE
CONFIDM Operationellt konfigurationsmeddelande (ODS) FRANKRIKE
CONFIDMCT Operationellt konfigurationsmeddelande (Terminal
Control System)FRANKRIKE
DEC Startmeddelande FRANKRIKE
DOUBM Meddelande om duplicerad färdplan FRANKRIKE
DRT Meddelande om förändrad destination FRANKRIKE
EATARR Meddelande med uppdatering av beräknad ankomsttid FRANKRIKE
ENDPROC Sista meddelande från trafikledare om förfarandestart
(ODS)FRANKRIKE2000R2082 — SV — 15.06.2002 — 001.001 — 124
▼B
Reserverad Titel Meddelandetyp Reserverad av
ENDPROCCT Sista meddelande från trafikledare om förfarandestart
(Terminal Control System)FRANKRIKE
EVLARR Föraktiveringsmeddelande för ankomst FRANKRIKE
EVLDEP Föraktiveringsmeddelande för avgång FRANKRIKE
EXCOND Aktivering av exceptionella förhållanden CFMU
FICM Meddelande om skapande av flygdata FRANKRIKE
FLXVIVO Meddelande om visuell kontakt längs flexibel färdväg FRANKRIKE
FPCLOSE Stängningsmeddelande för färdplansdata (ODS) FRANKRIKEFPCLOSECT Stängningsmeddelande för färdplansdata (Terminal
Control System)FRANKRIKE
FPCLOSED Stängningsmeddelande för duplicerad färdplansdata
(ODS)FRANKRIKE
FPCRD Meddelande om aktivering av färdplan (ODS) FRANKRIKE
FPCRDCT Meddelande om aktivering av färdplan (Terminal
Control System)FRANKRIKE
FPCRDD Meddelande om duplikat av föraktivering av färdplan
(ODS)FRANKRIKE
FPCRE Meddelande om upprättande av färdplan (ODS) FRANKRIKE
FPCRECT Meddelande om upprättande av färdplan (Terminal
Control System)FRANKRIKE
FPINI Meddelande om föraktivering av färdplan (ODS) FRANKRIKE
FPINICT Meddelande om föraktivering av färdplan (Terminal
Control System)FRANKRIKE
FPINID Meddelande om duplikat av föraktivering av färdplan FRANKRIKE
FPNTF Meddelande om föraktivering av färdplan (ODS) FRANKRIKE
FPNTFD Meddelande om duplikat av föraktivering av färdplan
(ODS)FRANKRIKE
FPRDU Meddelande med flygdatainformation för en icke
berörd sektor (ODS)FRANKRIKE
FPRDUCT Meddelande med flygdatainformation för en icke
berörd sektor (Terminal Control System)FRANKRIKE
FSM Meddelande från system för starttillstånd (ARINC 623) FRANKRIKE
FSMFTX Meddelande från system för starttillstånd (ARINC 620) FRANKRIKE
FSR Meddelande med begäran om indragning av flygning CFMU
IACHD Individuellt meddelande om ATC-förändringar TYSKLANDICHGD Individuellt ändringsmeddelande TYSKLAND
IDEPD Individuellt avgångsmeddelande TYSKLAND
IDLAD Individuellt förseningsmeddelande TYSKLAND
IFPDQ Individuellt meddelande med frågeställning om
färdplansdataCFMU
IFPDQR Individuellt svarsmeddelande till frågeställning om
färdplansdataCFMU
IFPDSQ Individuellt meddelande med frågeställning om
sammanställning av färdplansdataCFMU
IFPDSQR Individuellt svarsmeddelande till frågeställning om
sammanställning av färdplansdataCFMU
IFPLD Individuell färdplan TYSKLAND
INFOM Informationsmeddelande FRANKRIKE
IRQS Individuellt meddelande med begäran om tilläggsinfor-
mationCFMU
ISPL Meddelande om individuell begäran om tilläggsfärdplan CFMU
LGR Lista med lista över färdplaner FRANKRIKE
LISTFP Lista med lista över färdplaner (ODS) FRANKRIKE2000R2082 — SV — 15.06.2002 — 001.001 — 125
▼B
Reserverad Titel Meddelandetyp Reserverad av
LISTFPCT Lista med lista över färdplaner (Terminal Control
System)FRANKRIKE
LOGON Meddelande med identifiering av färdplan FRANKRIKE
MAJVIVO Meddelande med dagliga rörelser FRANKRIKEMCOM Samordningsmeddelande FRANKRIKE
MODCOND Förändring av exceptionella förhållanden CFMU
MODREG Förändring av en ATFM-bestämmelse CFMU
MRA Aktivering av obligatorisk färdväg CFMU
MRCNL Annullering av obligatoriskfärdväg CFMUMRMOD Förändring av obligatoriskfärdväg CFMU
MRR Meddelande om obligatoriskförändring av färdväg CFMU
MVTVIVO Meddelande med förflyttningsinformation FRANKRIKE
NEWREG Aktivering av en ATFM-bestämmelse CFMU
NTA Aktivering av ett ”icke tillåtet” trafikflöde CFMUNTACNL Annullering av ett ”icke tillåtet” trafikflöde CFMU
NTAMOD Ändring av ett ”icke tillåtet” trafikflöde CFMU
OCLM Meddelande om tillstånd för oceanflygning FRANKRIKE
OCLMD Meddelande om duplicering av tillstånd för oceanflyg-
ningFRANKRIKE
OLRA Aktivering av en avlastningsfärdväg CFMU
OLRCNL Annullering av en avlastningsfärdväg CFMU
OLRMOD Ändring av en avlastningsfärdväg CFMU
PAMAER Meddelande med ansökan om rullbana FRANKRIKE
PAMARB Meddelande om bekräftelse av ”On-Stand” FRANKRIKEPAMARRANN Annullering av tilldelad parkering för en ankomst FRANKRIKE
PAMARRCRE Tilldelning av parkeringsplats för en ankomst FRANKRIKE
PAMARRPST Ändring av tilldelad parkering för en ankomst FRANKRIKEPAMDAPARB Parkeringsmeddelande för ankommande flygplan FRANKRIKE
PAMDAPCRE Tilldelning av en parkeringsplats FRANKRIKE
PAMDEPANN Annullering av tilldelad parkering för en avgång FRANKRIKE
PAMDEPCRE Tilldelning av parkering för en avgång FRANKRIKE
PAMDEPPST Ändring av tilldelad parkering för en avgång FRANKRIKEPAMDRB Meddelande om bekräftelse av ”Off-Stand” FRANKRIKE
QTAARR Återgång till ursprunglig, ej aktiverad, status för en
ankomstFRANKRIKE
QTADEP Återgång till ursprunglig, ej aktiverad, status för en
avgångFRANKRIKE
RCD Meddelande med begäran om starttillstånd (AIRINC
623)FRANKRIKE
RCDFTX Meddelande med begäran om starttillstånd (AIRINC
620)FRANKRIKE
REVARR Ändringsmeddelande för en ankomst FRANKRIKE
RFPDQ Frågemeddelande om data i repetitiv färdplans CFMU
RFPDQR Svarsmeddelande på frågor om data i repetitiv färdplan CFMURFPDSQ Frågemeddelande om sammanfattning av repetitiv
färdplanCFMU
RFPDSQR Svarsmeddelande på begäran om sammanfattning av
repetitiv färdplanCFMU
RIEM Meddelande med flygdatainformation FRANKRIKE
RMG Meddelande om missad inflygning FRANKRIKE
RRA Meddelande om acceptans av förändrad färdväg CFMU2000R2082 — SV — 15.06.2002 — 001.001 — 126
▼B
Reserverad Titel Meddelandetyp Reserverad av
RREC Meddelande om återfående av repetitiv färdplan CFMU
RRN Meddelande med information om förändrad färväg CFMU
RSUS Meddelande om indragning av repetitiv färdplan CFMU
RWYCHGCT Meddelande om rullbanekonfiguration FRANKRIKE
TRACT Begäran om aktivering av färdplan (ODS) FRANKRIKE
TRACTCT Begäran om aktivering av färdplan (Terminal Control
System)FRANKRIKE
TRCNL Begäran om annullering av färdplan (ODS) FRANKRIKE
TRCNLCT Begäran om annullering av färdplan (Terminal Control
System)FRANKRIKE
TRCOR Begäran om manuellt samband FRANKRIKE
TRDECOR Begäran om upphörande av manuellt samband FRANKRIKE
TRFIC Begäran om upprättande av färdplansdata (ODS) FRANKRIKE
TRFICCT Begäran om upprättande av färdplansdata (Terminal
Control System)FRANKRIKE
TRFLRQT Meddelande med begäran om flygnivå FRANKRIKE
TRMOD Begäran om ändring av färdplan (ODS) FRANKRIKE
TRMODCT Begäran om ändring av färdplan (Terminal Control
System)FRANKRIKE
TRMODH Begäran om ändring av tid FRANKRIKE
TRMODHD Begäran om ändring av tid för försenad flygning FRANKRIKE
TRMVT Begäran om samordning av utgående flygning (ODS) FRANKRIKETRMVTCT Begäran om samordning av utgående flygning
(Terminal Control System)FRANKRIKE
TRPOINT Meddelande med förfrågan om speciell flygdata. FRANKRIKE
TRRET Begäran om ändring av färdplan till ursprunglig status
(ODS)FRANKRIKE
TRRETCT Begäran om ändring av färdplan till ursprunglig status
(Terminal Control System)FRANKRIKE
TRRIP Begäran om uppvisande av flygdatainformation (ODS) FRANKRIKE
TRRIPCT Begäran om uppvisande av flygdatainformation
(Terminal Control System)FRANKRIKE
TRRQT Begäran om färdplan (ODS) FRANKRIKE
TRRQTCT Begäran om färdplan (Terminal Control System) FRANKRIKE
TRSHRQT Begäran om frekvensbyte FRANKRIKE
TRSTAR Initialiseringsbegäran från trafikledare (ODS) FRANKRIKE
TRSTARCT Initialiseringsbegäran från trafikledare (Terminal
Control System)FRANKRIKE
TRTRP Meddelande om överföringsposition. FRANKRIKE
UNKFP Meddelande om undertryckande av färdplan (ODS) FRANKRIKE
UNKFPCT Meddelande om undertryckande av färdplan (Terminal
Control System)FRANKRIKE2000R2082 — SV — 15.06.2002 — 001.001 — 127
▼B
BILAGA D (Normativ)
CENTRAL FÖRTECKNING ÖVER RESERVERADE FÄLT
D.1.Inledning
Denna bilaga innehåller en central förteckning över reserverade fält,
primära, underordnade fält och hjälputtrycksom ännu inte har definierats
för användning i ADEXP. Att de finns upptagna i denna bilaga indikerar
antingen att de förutsetts för framtida användning, eller att de redan
används men att deras användning är begränsad till lokala system.
D.2.Syfte
Syftet med att tillhandahålla en lista med fält som ännu ej formellt har
antagits för användning inom denna ADEXP-standard är att förhindra, i
största möjliga utsträckning, antingen skapandet av redundans närhelst ett
nytt fält behövs för ett särskilt ändamål eller att ett nyckelord införs som
redan används i ett lokalt system.
D.3.Reserverade Hjälputtryck
Reserverat
HjälputtryckSyntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fältAnvänt i
hjälputt-
ryck
centreidentifi-
cation1{ALPHA}4 Center-beteck-
ning.ctsrc
ripsrcctripectdest
contextfdpsid 'OPEPAL' |
'OPESOS' |
'EVALPAL' |
'TSTOPEPAL' |
'TSTOPESOS'Operativläge för
en FDPS tillämp-
ning.
(Operationell,
Test, etc.)ctxtfdps
contextphi-
diasid'OPE'|'EVA-
L1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Specifik för det
franska systemetctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Inträdespunkt för
kontrollpositionen
(”E”).
Utträdespunkt för
kontrollpositionen
(”S”),
XFL punkt (X),
OCL punkt (O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Beteckningen på
en ”operationell
enhet”eosrc eoid
fl3 'F' ! 3{DIGIT}3 Flygnivå uttryckt
i hundratals fot.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Planerad tendens
för flygprofilen.
U för UP
D för Down
S för Stableetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Färdplansstatus
inom ett ACC-
område.fpctst
latitude 4{ DIGIT }4 En latitud
uttryckt i fyra
siffrorReserverad
för framtida
bruk2000R2082 — SV — 15.06.2002 — 001.001 — 128
▼B
Reserverat
HjälputtryckSyntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fältAnvänt i
hjälputt-
ryck
latitudeshort 2{ DIGIT }2 En latitud
uttryckt i två
siffror.Reserverad
för framtida
bruk
longitude 5{ DIGIT }5 En longitud
uttryckt i fem
siffror.Reserverad
för framtida
bruk
longitudes-
hort3{ DIGIT }3 En longitud
uttryckt i tre
siffror.Reserverad
för framtida
bruk
pointcautra 1{ALPHANU-
M}5Specifik för det
franska systemetfirstpid pointid
ptcidptid
positioniden-
tification1{ALPHANU-
M}6Färdposition,
verklig eller
logisk.posid
qfuid ('0'|'1'|'2'|'3')!1{
DIGIT }1!('L'|'C'
|'R'|NIL)QFU för en rull-
bana.
L = VänsterC= Mitten
R = Högerqfu qful
secidentifica-
tion1{ALPHANU-
M}2Sektorbeteckning secdest
secsrcsecid
sending-
reason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|'MVTSEC'|'COO-
RAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'I-
NIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|
'PKG'Anledningen till
översändandet av
färdplansdataevent
starreason 'TOTAL' Typen av initiali-
sering av en posi-
tion med
färdplansdatastreason
temperature ("N" | "P") !
2{DIGIT}2Temperatur
uttrycki grader
Celsius (00-99)
med utvisande av
förtecknet (minus
eller plus)temp
updatereason ('T'!('R'|NIL)|'R') Typ av uppda-
tering senast
gjord för ett flyg-
data.
Operatörs-trans-
aktion (”T”).
Radaruppdater-
ing(”R”).udpt2000R2082 — SV — 15.06.2002 — 001.001 — 129
▼B
D.4.Reserverade primära fält
Reserverat
primärt fältTyp Syntax Betydelse
aabd b '-' "AABD" date Verkligt datum för ankomst ”on-
block”.
aabt b '-' "AABT" timehhmm Verklig tid för ankomst ”on-block”.
acnf c '-' "ACNF" ad rcnf [qfulist] Rullbanans konfiguration
aobd b '-' "AOBD" date Verkligt datum för ”off-block”.
aobt b '-' "AOBT" timehhmm Verklig tid för ”off-block”.
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Inflygningstyp (1 siffra, värden: 1,
2, 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Flygplansbeteckning använd av
flygplansoperatörer.
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Lokalt unikt identifieringsnummer
på flygplan, använt av ATC.
atis b '-' "ATIS" 1{ALPHA}1 Beteckning på Automatiserad
Terminal Informations Service
autfl1 b '-' "AUTFL1" fl3 Godkänd flygnivå 1
autfl2 b '-' "AUTFL2" fl3 Godkänd flygnivå 2
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Tillhandahåller den data som skall
översändas i ett samordningsmed-
delande:
sänder tid, utträdespunkt, flygnivå
över utträdespunkten, planerad
flygnivå och information om huru-
vida nivån är i enighet med
överenskommelser.
avail b '-' "AVAIL" 'YES'|'NO' Indikering på huruvida en sektor
har tillåtelse eller inte att förändra
ett färdplansdata.
bkrow b '-' "BKROW" 1{DIGIT}2 Positionen på en referenspunkt i en
lista av färdvägspunkter.
bkt b '-' "BKT" datetime Tid över en referenspunkt för en
transaktion.
codetr b '-' "CODETR" 'YES'|'NO' Indikering på huruvida SSR-koden
skall sändas (eller ej) från kontroll-
positionen till piloten.
confid b '-' "CONFID" 1{DIGIT}5 Operationell konfiguration-identifi-
ering (sektorer/positioner).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-'"END" "CONFL"Lista över sektor-/positionsförknip-
pelser till en central längs
färdvägen.
crspd b '-' "CRSPD" 1{DIGIT}4 Marschhastighet i knop
ctripe b '-' "CTRIPE" centreidentification Namn på centralen som är motta-
gare av en transaktion.
ctrow b '-' "CTROW" 1{DIGIT}1 Positionen på en central i en lista
av centraler.
ctsrc b '-' "CTSRC" centreidentification Beteckningen på en sändande
central.
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Operativläge för kontrollsystemter-
minal.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Operativläge för en FPDS.
ctxtpos b '-' "CTXTPOS" contextphidiasid Operativläge för ODS.curfl b '-' "CURFL" fl3 Nuvarande flygnivå.
curpos c '-' "CURPOS" ptid | (lattd longtd) Nuvarande position.
curpost b '-' "CURPOST" datetime Datum och tid vid nuvarande posi-
tion.
curptt b '-' "CURPTT" datetime Datum och tid vid överflygning av
nuvarande punkt.2000R2082 — SV — 15.06.2002 — 001.001 — 130
▼B
Reserverat
primärt fältTyp Syntax Betydelse
curptx b '-' "CURPTX" 1{DIGIT}2 Numrerad position för nuvarande
punkt i en lista över
färdvägspunkter.
dcatcid b '-' "DCATCID" icaoaerodrome Flygplats ansvarig för starttillstånd
då detta lämnas av FDPS till flyg-
planet via datalänk.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Normaltext för ARINC 623
meddelande med starttillstånd.
”ACK” för starttillstånds-medde-
lande.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Normaltext för ARINC 620
meddelande med starttillstånd.
”ACK” för starttillstånds-medde-
lande.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Status på starttillstånd för en flyg-
ning.
dcid b '-' "DCID" 1{DIGIT}3 Systemnummer för starttillstånd
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Typ av meddelande för start-
tillstånd.
dcref b '-' "DCREF" 1{ALPHANUM}5 Kontextreferens för ett start-
tillstånd.
dcrmkb '-' "DCRMK" 1{LIM_CHAR}80 Anmärk ning till starttillstånd.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Tilläggstext till meddelande från
systemet för starttillstånd. (ARINC
623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Andra texttillägget till meddelande
från systemet för starttillstånd.
(ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Dag, timmar, minuter och sekunder
för starttillståndet för avgång.
delcode b -' “DELCODE”
1{ALPHANUM}20Orsaktill en försening.
dfdpsid b '-' "DFDPSID datetime ! seconds Data för identifiering av system för
behandling av flygdata.
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identifiering av en ”duplicerad”
enhet.
ecurptt b '-' "ECURPTT" datetime Beräknad tid för överflygning av
aktuell punkt.
eda b '-' "EDA" date Beräknat ankomstdatum.elastptt b '-' "ELASTPTT" datetime Beräknad tid för överflygning av
sista punkt i färdvägen.
endhldt b '-' "ENDHLDT" datetime Tid för upphörande av väntläge.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Antal gånger en färdplan
förekommer inom en central.
entryt b '-' "ENTRYT" datetime Inträdestid för positionen.
enxtptt b '-' "ENXTPTT" datetime Beräknad tid för överflygning av
nästa punkt (uppges ej om nuva-
rande punkt är sista punkt).
eobdt b '-' "EOBDT" datetime Datum och beräknad ”off-block”
tid.
eosrc b '-' "EOSRC" eoidentification Beteckning på operativ ”enhet”.
espfl b '-' "ESPFL" flightlevel Supplementär flygnivå för
överföring för den föregående
kontrollpositionen.
eta b '-' "ETA" timehhmm Beräknad ankomsttid.2000R2082 — SV — 15.06.2002 — 001.001 — 131
▼B
Reserverat
primärt fältTyp Syntax Betydelse
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyFlygnivå vid inträde eller tendens
till flygprofil.
event b '-' "EVENT" sendingreason Utlösande händelse för FDPS.
firstpid b '-' "FIRSTPID" pointcautra Specifik för det franska systemet
flbkb '-' "FLBK" flightlevel Flygnivå vid transak tionen för den
senaste referenspunkten för en
aktiverad flygning, eller förändrad
nivå för en transaktions referens-
punkt.
fpbaseid b '-' "FPBASEID" datetime!seconds Identifiering av databas för
färdplaner.
fpctst b '-' "FPCTST" fpcentrestate Färdplansstatus inom en central.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Lista över de kända men ännu ej
genomförda färdplanerna för en
position.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Flygkategori:
T = överflygning
E = inkommande
S = utgående
I = inre.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Lista över färdplansinformation för
ett ”callsign”.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Lista över färdplansfält.
fplnb b '-' "FPLNB" 1{DIGIT}1 Antal färdplaner från 0 till 5
fplstat b '-' "FPLSTAT" "T" | "C" Flygningens status:
T = avslutad
C = pågående.
fprmkb '-' "FPRMK" 1{LIM_CHAR}8 Anmärk ningar i ursprunglig
färdplan.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"“|FIC-
PAC"|'FPL"|"RPL"|"NKW")Färdplanens ursprung.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Lista över ”okända” färdplaner.
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Meddelande i fritext.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Identifiering av flexibel färdväg.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Beteckning på flexibel färdväg.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Genererat nummer på flexibel
färdväg.
grspd b '-' "GRSPD" 1{DIGIT}4 Markrelaterad fart i knop.hldbkrw b '-' "HLDBKRW" 1{DIGIT}2 Nummerordning på en referens-
punkt för ett väntläge i en lista
över punkter längs en färdväg.
icing b '-' "ICING" 1{ALPHA}8 Nedisning.
”TRACE” eller ”LIGHT” eller
”MODERATE” eller ”SEVERE”.
indstip b '-' "INDSTIP" 'STIP' Specifik för det franska systemet
initid b '-' "INITID" 1{DIGIT}1 Initialiseringsnummer.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2FDPS/ODS eller FDPS/Terminal-
system gränssnittsidentifiering.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Lista över latitud och longitud för
punkter längs färdvägen.2000R2082 — SV — 15.06.2002 — 001.001 — 132
▼B
Reserverat
primärt fältTyp Syntax Betydelse
lang b '-' "LANG" '?' Beteckning på konversationsspråk.
”?” = språket används normalt inte
av bolaget.
lastradt b '-' "LASTRADT" datetime Senaste uppdateringstid lämnad
genom radarinformation.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Belysningskod.
maint b '-' "MAINT" 'YES'|'NO' Indikering huruvida datainforma-
tionen för en kontrollposition är
kontinuerligt upprätthållen eller ej.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Information vid SSR-läge A
modec b '-' "MODEC" flightlevel Information vid SSR-läge C
msgbody b '-' "MSGBODY"
1{CHARACTER}Innehåller en teckenföljd som är
identiskmed stommen i ett
likvärdig, befintligt, meddelande
som ej är ett ADEXP-meddelande.
msgct b '-' "MSGCT" datetime ! seconds Tidsstämpel för ett meddelande i
formatet: Dag, timmar, minuter och
sekunder.
nat b '-' "NAT" 1{ALPHA}1 Identifiering av en färdväg över
Nordatlanten.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Frekvens för nästa kontakt.
nxtfir b '-' "NXTFIR" icaoaerodrome Nästa FIR som skall kontaktas.
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Nästa position.nxtpost b '-' "NXTPOST" datetime Tid över nästa position.
oclfl b '-' "OCLFL" flightlevel Begränsad flygnivå för tillstånd till
flygning över ocean (OCL).
oprfl b '-' "OPRFL" flightlevel Begärd flygnivå ändrad av en
operatör.
oprmkc '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Lista över operatörsanmärkningar.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Operatörsanmärkningar.
oriented b '-' "ORIENTED" 'YES'|'NO' Orienterad flygning eller ej.
pfl b '-' "PFL" flightlevel Planerad flygnivå (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistRadarspårningskoordinater och
fartvektor-koordinater.
pistid b '-' "PISTID" 1{DIGIT}4 Spårningsradaridentifiering.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Parkeringsplats för en ankommande
flygning.
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Parkeringsplats för en avgående
flygning.
plnid b '-' "PLNID" 4{DIGIT}4 Identifiering av färdplan
plnold b '-' "PLNOLD" 4{DIGIT}4 Gammal identifiering av färdplan
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Status på samordning av förflytt-
ningar för positionen:
Accepterad förflyttning för inträdet
(MAE) eller för utträdet (MAS)
eller föreslagen förflyttning för
utträdet (MPS) eller alarm för
föreslaget utträde (MPSA) eller
position ännu ej samordnad för
förflyttningar (NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Antal punkter efter färdvägen.
qfu b '-' "QFU" qfuid Identifiering av använd rullbana
(QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Quebec-flygning eller inte.2000R2082 — SV — 15.06.2002 — 001.001 — 133
▼B
Reserverat
primärt fältTyp Syntax Betydelse
radioid b '-' "RADIOID"
1{ALPHANUM}20Radio identifikation.
reqid b '-' "REQID" 1{DIGIT}5 Antal förfrågningar.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Typ av förfrågan om färdplan.
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Lista över enheter som skall erhålla
färdplansdata.
ripsrc b '-' "RIPSRC" centreidentification Beteckning på centralen som är
ansvarig för att inleda sändningen
av färdplansdata.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' Numret på en IFPS-transaktion i en
begärd färdplan.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Lista över CAUTRA-punkterna i
en icke styrd färdväg.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Lista över färdvägspunkter för
vissa transaktioner.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Lista över flygplatskonfigurationer.
secdest b '-' "SECDEST" secidentification Beteckning på mottagande sektor.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Global lista över sektorer.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Global lista över sektorerna.
secsrc b '-' "SECSRC" secidentification Beteckning på ursprunglig sektor.
spfl b '-' "SPFL" flightlevel Supplementär flygnivå.
ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Utsänd SSR-kod.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmStämpelidentifiering.
streason b '-' "STREASON" starreason Anledning till en begäran om
inledning lämnad av en kontrollpo-
sition.
strid b '-' "STRID" 1{DIGIT} RDPS-identifiering.
temp b '-' "TEMP" temperature Temperatur.
terminal b '-' "TERMINAL"
1{ALPHANUM}2Namn på terminalen.
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Lista på möjliga transaktioner för
kontrollpositionen och för den
specificerade färdplanen.
trfl b '-' "TRFL" flightlevel | flightten-
dancyTransfereringsflygnivå eller
tendensinformation för en flyg-
profil.
turb b '-' "TURB" 1{ALPHA}8 Turbulens = LIGHT, MODERATE
eller SEVERE
validend b '-' "VALIDEND" datetime Tid då visuell kontakt upphör.
validst b '-' "VALIDST" datetime Tid då visuell kontakt inleds.
visi b '-' "VISI" 1{ALPHANUM}20 Sikt.
wddir b '-' "WDDIR" 1{DIGIT}3 Vindriktning uttryckt i grader från
0 till 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Vindhastighet uttryckt i knop.
xfl b '-' "XFL" flightlevel Flygnivå vid utträde (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Svarsmeddelande till en begäran
beträffande färdplan.2000R2082 — SV — 15.06.2002 — 001.001 — 134
▼B
D.5.Reserverade Underordnade fält
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Färdplansfält som
kan ändras vid tiden
för aktivering av en
flygning.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxAbsolut FL,
minimum FL och
maximum FL för
referenspunkten för
en transaktion. FL är
allmän, kan vara
RFL, PFL, etc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Det värde (+/-) vid
vilket en förändring
av tiden för en punkt
tillåts.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxAbsolut flygnivå
(CFL), minimum
CFL och maximum
CFL för referens-
punkten för en trans-
aktion.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-läge och till-
delad kod.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-7'}4SSR-läge och kod
som är tillgänglig för
användning.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-läge och kod
som tidigare tillde-
lats.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-läge och kod
som har reserverats
för användning och
därför ej är
tillgänglig.ssrcodes
coorpt b '-' "COORPT" coord-
pointsKaraktäristik för
koordinationspunkt:
Initial, Exit, OCL,
XFLptc
ctdest b '-' "CTDEST"
centreidentificationMottagandecentral
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTidsintervall för
beräkning av en
minimitid.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTidsintervall för
beräkning av en
maximitid.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Fartintervall för
beräkning av minimi-
fart.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Fartintervall för
beräkning av maxi-
mifart.spdchg
destid c '-' "DESTID" ctdest
secripATC-central och lista
över sektorer till
vilka en färdplan
skall sändas.ripel2000R2082 — SV — 15.06.2002 — 001.001 — 135
▼B
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
edto b '-' "EDTO" dateti-
me|"WT"Beräknad tid över en
punkt i år, månad,
dag, timmar, minuter
eller indikeringen
”punkt utan
tid””WT”.ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationNamn på operativ
enhet.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Lista över operativa
enheter associerade
till en kontrollposi-
tion.eopos
eopos c '-' "EOPOS" posid
[eolist]Namn på kontrollpo-
sition och lista på
operativa enheter
associerade till denna
position.confl
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'R-
TE'|'ADEP'|'CODE'|'-
LANG'|'-
BK'|spdchg|rflchg|cfl-
chg|pflchg|tflchg|sflc-
hg|xflchg|bkchg|bktc-
hg|'QFU'|'PKDEP'|'-
SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Beteckning på ett
ändringsbart fält för
en transaktion.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Beräknad flygnivå
vid samordnad
utträdespunkt vilken
kan sändas i det
automatiska samord-
nings-meddelandet
till nästa central.automsg
flimp b '-' "FLIMP" flight-
levelAbsolut flygnivå. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" flight-
levelMaximal flygnivå. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" flight-
levelMinimal flygnivå. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbFärdplansidentifiering
i ett meddelande.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobtSammanställning av
färdplansdata.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidIdentifiering av
färdplan.fplist2000R2082 — SV — 15.06.2002 — 001.001 — 136
▼B
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
lalg c '-' "LALG" lattd
longtdLatitud och longitud
för varje punkt efter
färdvägen.laglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Lista på fält som kan
ändras efter akti-
vering.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Lista på fält som kan
ändras i en tidsupp-
daterings-transaktion
efter aktivering.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Lista över fält som
kan ändras i en
manuellt aktiverad
samordning mellan
sektorer.transid
pflchg c '-' "PFLCHG" flimp
flmin flmaxAbsolut-, minimi-
och maximinivå för
förändring av PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Planerad flygnivå
som skall sändas i det
automatiska samord-
ningsmeddelandet till
nästa central. Samt
en indikering om
huruvida nivån
överensstämmer med
de berörda operativa
överenskommelserna.
NA = Ej enligt
överenskommelse.automsg
pka b '-' "PKA"
1{ALPHANUM}3Reserverad parker-
ingsplats, ännu ej
tilldelad.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indikering på att
flygplanet väntar på
en parkeringsplats.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Tilldelad parkerings-
plats.pkarr
pointid b '-' "POINTID" point-
cautraSpecifik för det
franska systemet.ptpro
posid b '-' "POSID" positioni-
dentificationNamn på kontrollpo-
sition.eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Karaktäristik för en
punkt längs
färdvägen.rte
ptcid b '-' "PTICD" point-
cautra|geonameSpecifik för det
franska systemet.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Beskrivning av föres-
lagna punkter längs
färdvägen.rtetr
qful c '-' "QFUL" qfuid Giltig QFU för en
angiven rullbana på
en flygplats.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Lista över giltiga
QFU för en flygplats.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Allmän start- och
landningsriktning för
en flygplats.
(Östlig, västlig etc.)acnf2000R2082 — SV — 15.06.2002 — 001.001 — 137
▼B
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
ref c '-' "REF" (refi-
d|ref1id)Karaktäristik för en
referenspunkt för en
transaktion.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Identifiering av en
möjlig referenspunkt
för en transaktion.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identifiering av den
troligaste referens-
punkten för en trans-
aktion.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Föreskriftsinforma-
tion specifikför de
franska systemen.regul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Föreskriftsinforma-
tion specifikför de
franska systemen.regul
regult b '-' "REGULT" date-
timeFöreskriftsinforma-
tion specifikför de
franska systemen.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Lista över fält som
kan förändras i en
transaktion för att
återställa färdplanen
till dess föregående
status.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxAbsolut-, minimi-
och maximinivå för
ändring av RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Text i en anmärkning
från en trafikledare.oprmk
sec c '-' "SEC" secid
[seccar]Identifiering och
karakräristik för
ACC-sektorer till
vilka färdplansdata
skall sändas.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'Karaktäristik för en
ACC-sektor:
-Första sektorn (”F”)
-Sista sektorn (”L”)
-Accepterad för
inträde (”M”)
-Källsektor för
”duplicering” (”D”)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Karaktäristik för en
terminalområdes-
sektor:
-Första sektorn (”F”)
-Sista sektorn (”L”)
-Accepterad för
inträde (”M”)secct
secct c '-' "SECCT" secid
[seccarct]Identifiering och
karaktäristik för
terminalområdessek-
torer.seclistct
secid b '-' "SECID" seciden-
tificationSektoridentifiering secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Lista över motta-
gande enheter
(sektorer eller
avgångs-/ankomst-
kontroll- enheter) till
vilka färdplansdata
skall sändas.destid2000R2082 — SV — 15.06.2002 — 001.001 — 138
▼B
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
sendt b '-' "SENDT" datetime Tid för avsändande
av samordningsmed-
delande.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxAbsolut-, minimi-
och maximi-nivå för
förändring av supple-
mentär flygnivå
(SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Lägre och övre
fartintervall för
förändring av
färdplansfarten under
en transaktion.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxAbsolut-, minimi-
och maximi-nivå för
förändring av trans-
ferflygnivå (TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Kännetecken för en
punkt i förhållande
till kursen på en
flygning:
S = delningspunkt
M = skärningspunkt
T = tvärsgående
punkt
A = STAR-punktptc
ptpro
transid b '-' " TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Identifiering av
möjlig transaktion för
kontrollpositionen för
berörd färdplan eller
beteckningen ”NO”
innebärande att trans-
aktion ej är möjlig.translist
txt b '-' "TXT"
1{LIM_CHAR}80Fri text. freetxt
udpt b '-' "UDPT" update-
reasonSenaste uppdatering
lämnad av operatör
och/eller genom
radarinformation.ptc
view b '-' "VIEW"
('V'|'VNX')Beteckning på
”synbarheten” av en
punkt.
V = synlig
VNX = ej synlig
(fiktiv punkt)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeX-koordinat för
fartvektorn för en
radarposition.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeY-koordinat för
fartvektorn för en
radarposition.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxMinimi- och maxi-
minivå för ändring av
en utträdesflygnivå
(XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positif
N:= NegativeX-koordinat för en
radarposition.pistcoord2000R2082 — SV — 15.06.2002 — 001.001 — 139
▼B
Reserve-
rade under-
ordnade
fältKind Syntax BetydelseAnvänt i
primärt fältAnvänt i
underordnat
fält
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= NegativeY-koordinat för en
radarposition.pistcoord2000R2082 — SV — 15.06.2002 — 001.001 — 140
▼B
BILAGA E (Informativ)
INTRODUKTION AV MEDDELANDEGRUPPER
INLEDNING
Denna bilaga tillhandahåller en introduktion till de olika grupperna eller katego-
rierna av meddelanden som kan utväxlas i ADEXP. En fullständig
sammanställning över samtliga titlar på ADEXP-meddelanden i finns i bilaga B.
ANMÄRKNING För exakta villkor, tillämpningsregler och användande av fält,
särskilt användandet av valfria fält, skall hänvisning göras till
relevant dokumentation (t.ex. dokument för specifikation av
gränssnitt) för berörda system.
E.1. Färdplansmeddelanden
E.1.1. Inledning
Meddelanden inom denna kategorin utväxlas i första hand mellan
AO, IFPS och relevanta ATS-enheter.
E.1.2. Definition av meddelandetitlar
Meddelandetitlar inom denna kategori är:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQP, MAN, RCHG, RCNL, REJ.
Allt definitionsunderlag för dessa meddelanden finns i
referensdokument 3
E.1.3. Sammansättning av primära fält
Detaljerad definition av meddelandeinnehåll, regler för användande
av data och användandet av obligatoriska och valfria fält återfinns i
referensdokument 3.
Exempel:
Färdplansmeddelande-TITLE IFPL
-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC
EGZYTTTE -FAC EGTTZGZP
-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC
LPPCIFPS -FAC LPPTYWYA
-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS-END ADDR
-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -
CEQPT S
-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686
-ORGNID AZXRPLO
-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -
SPEED N0400 -FLTRUL I
-FLTTYP S-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS
UG41 FTM
-BEGIN RTEPTS-PT -PTID EGKK -FL F000 -ETO 980305113000-PT -PTID SAM -FL F196 -ETO 980305114012
-PT -PTID ASPEN -FL F288 -ETO 980305114658
-PT -PTID ORTAC -FL F311 -ETO 980305114959-PT -PTID GUR -FL F330 -ETO 980305115617
-PT -PTID AKEMI -FL F330 -ETO 980305120118
-PT -PTID LARSI -FL F330 -ETO 980305120626-PT -PTID QPR -FL F330 -ETO 980305121236-PT -PTID ERWAN -FL F330 -ETO 9803051231522000R2082 — SV — 15.06.2002 — 001.001 — 141
▼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. Meddelanden från flygledningstjänsten (ATFM-meddelanden)
E.2.1. Inledning
Meddelanden inom denna kategori utväxlas i första hand mellan
TACT-systemet inom Eurocontrol CFMU, flygplansoperatörer och
ATS-enheter.
E.2.2. Meddelanden rörande datorstödd slot-tilldelning (CASA)
Meddelandetitlar inom denna kategori är:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Definition av meddelandetitlar
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 5.
E.2.2.2. Sammansättning av primära fält
Detaljerad definition av meddelandeinnehåll, regler för användande
av data och användandet av obligatoriska och valfria fält återfinns i
referensdokument 5.
Exempel:
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3. Informationsmeddelanden
Meddelanden inom denna kategori är:FSA
E.2.3.1. Definition av meddelandetitlar
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 5.
E.2.3.2. Sammansättning av primära fält
Detaljerad definition av meddelandeinnehåll, regler för användande
av data och användandet av obligatoriska och valfria fält återfinns i
referensdokument 5.
Exempel:
Första systemaktiveringsmeddelande
-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — SV — 15.06.2002 — 001.001 — 142
▼B
E.3. ATC-samordningsmeddelanden
E.3.1. Inledning
Samordningsmeddelanden används för att automatisera operationell
samordning och utbyte av information mellan ATC-enheter. Medde-
landena säkerställer leverans i rätt tid av operationell information
relaterad till samordning genom standardisering av utdrag av data
och överföringskapacitet.
E.3.2. Definition av meddelandetitlar
Meddelandetitlar inom denna kategori är:
ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 6.
E.3.3. Sammansättning av primära fält
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 6.
Exempel:
Medelande med förslag om överlämning-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Aktiveringsmeddelande
-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -
SEQNUM 005 -ARCID AMM253
-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO
1226 -TFL F350
-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4
BPK UB3 HON
E.4. Meddelanden om ledning av luftrum
E.4.1. Inledning
Meddelanden använda för samordning av ledning av luftrum. Dessa
meddelanden täcker ledningen av den omgivning som trafikeras: de
permanenta och villkorliga färdvägarna, tillfälligt avskilda områden,
farliga och förbjudna områden etc.
E.4.2. Definition av meddelandetitlar
Meddelandetitlar inom denna kategori är:
AUP, CRAM, UUP.
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 7.
E.4.3. Sammansättning av primära fält
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 7.
Exempel:
Meddelande om tillgänglighet av villkorlig färdväg-TITLE CRAM -PART -NUM 001 -LASTNUM 010
-FILTIME 281353 -MESVALPERIOD 199803290600
1998703300600
-BEGIN LACDR-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803300600
-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP2000R2082 — SV — 15.06.2002 — 001.001 — 143
▼B
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030
199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL
-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700
199803291330
-END LACDR
E.5. Civila/militära samordningsmeddelanden
E.5.1. Inledning
Meddelanden som används i samordningen för flygdata och
förfrågningar om korsande av luftrum mellan civila och militära
ATS-enheter.
E.5.2. Definition av meddelandetitlar
Meddelandetitlar inom denna kategori är:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 7.
E.5.3. Sammansättning av primära fält
Allt definitionsunderlag för dessa meddelanden återfinns i
referensdokument 7.
Exempel:
Meddelande med begäran om tillstånd för överfart
-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP
F111 -SECTOR SOUTH
-BEGIN RTEPTS-PT -PTID GEO01 -TO 1630 -FL F250
-PT -PTID GEO02 -TO 1631 -FL250
-END RTEPTS-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E
Godtagandemeddelande
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — SV — 15.06.2002 — 001.001 — 144
▼B
BILAGA F (Informativ)
EXEMPEL PÅ ADEXP-MEDDELANDEFORMAT
Följande exempel tillhandahålls som en demonstration av ADEXP-formatet, inte
som ett exempel på innehåll i ett meddelande. Meddelandet som används är en
IFPL, men trots att det var korrekt vid tidpunkten för publicerandet, kan inte
riktigheten av fältsammansättning etc. garanteras.
Exempel 1 nedan har utformats på ett sätt som gör det lätt att läsa. Detta har
uppnåtts genom användande av valsreturer, radmatningar, indragningar etc. En
sådan uppställning är dockinte del av reglerna i ADEXP-formatet.
Utformning av ett meddelande är därför beroende av urskillningsförmågan i det
mottagande systemet. EXEMPEL 2 och EXEMPEL 3 är båda giltiga återgi-
vanden av samma meddelande som i EXEMPEL 1.
EXEMPEL 1
-TITLE IFPL
-BEGIN ADDR
-FAC CFMUTACT-FAC LFFFSTIP-FAC EDFFZRZL
-FAC EDZZZQZA
-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX
-FAC LWSSZQZX
-FAC LGTSZAZX-END ADDR
-ADEP EDDF
-ADES LGTS
-ARCID DLH3728
-ARCTYP B73A
-CEQPT SDMRY-EOBD 980517
-EOBT 0715
-FILTIM 170421
-IFPLID AA05966101
-ORGNID DLHAOCC
-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH
-REG DABHM-SEL KMGJ
-SRC FPL
-FLTTYP S
-WKTRC M
-TTLEET 0210-RFL F330
-SPEED N0417
-FLTRUL I
-SEQPT C
-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23
BABIT UR26
SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF2000R2082 — SV — 15.06.2002 — 001.001 — 145
▼B
-EETFIR EDUU 0014
-EETFIR LOVV 0035-EETFIR LJLA 0054
-EETFIR LHCC 0057
-EETFIR LYBA 0113-EETFIR LWSS 0148
-EETFIR LGGG 0159
-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414
-PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130
-PT -PTID MUN -FL F330 -ETO 980317074449
-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830
-PT -PTID DIMLO -FL F330 -ETO 980317081443-PT -PTID BABIT -FL F330 -ETO 980317083107
-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204
-PT -PTID VAL -FL F330 -ETO 980317084629
-PT -PTID KAVOR -FL F330 -ETO 980317085329
-PT -PTID BUI -FL F330 -ETO 980317090135-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414
-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D-ATSRT UW70 NDG MUN
-ATSRT UB103 MUN UNKEN
-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN
-ATSRT UG18 SAVIN BUI
-ATSRT UB1 BUI TALAS
EXEMPEL 2
-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC
EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC
LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END
ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -
CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID
AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC
FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M
-TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE
N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26
SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -
EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR
LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -
PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -
ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID
MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO980317074449 -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 -PTID2000R2082 — SV — 15.06.2002 — 001.001 — 146
▼B
TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO
980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -
ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT
UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS
EXEMPEL 3
-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC
EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC
LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END
ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT
SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-
ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG
DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL
F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG
UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1
TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR
LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-
EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO
980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL
F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT
PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO
980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-
FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-
PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO
98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID
KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO
980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-
FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-
PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO
980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-
SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-
ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18
SAVIN BUI-ATSRT UB1 BUI TALAS2000R2082 — SV — 15.06.2002 — 001.001 — 147
▼B
BILAGA G (Informativ)
FRAMTIDA UTVECKLINGAR
G.1.Inledning
Denna bilaga tillhandahåller en anvisning om den föreslagna framtida
utvecklingen av ADEXP samt anledningarna och målsättningarna bakom
utvecklingen.
G.2.Målsättning
En av de viktigaste målsättningarna under utvecklingen av ADEXP var
kravet på att utveckla ett format som skulle möjliggöra ett mottagande
system att framgångsrikt ”ignorera” eller ”hoppa över” ett okänt eller
inte erkänt fält utan att nödvändigtvis ogiltigförklara det behandlade
meddelandet. Införandet av detta kan tillåta tillägg av nya fält inom ett
meddelande utan krav på att ha alla mottagande system modifierade i
förväg åtföljt av en mycket väl samordnad ”övergång”. Den enorma flex-
ibilitet som detta kan tillhandahålla är en av fördelarna med ADEXP-
formatet.
Denna målsättning uppnås under nuvarande standard genom användandet
av fördefinierade primära och underordnade fält, introducerade genom
unika nyckelord. En lexikalisk analysator som inte ”godtar” ett nyckelord
krävs för att ignorera all text fram till nästa kända primära fält som inte
finns inom ett listfält. Återvinnande uppnås därför på primärfältsnivå.
Nuvarande och framtida utveckling av definitionen av nya meddelanden
indikerar att det inom vissa områden krävs en högre grad av komplexitet,
i vilken uppsättningar av fält på tredje och till och med fjärde nivå
behövs. (Meddelandet om villkorlig tilldelning av färdväg (CRAM) är
ett nuvarande exempel på detta krav.) ADEXP tillhandahåller idag
möjligheten att sammansätta ett meddelande med uppsättningar på alla
nivåer. Förmågan till återvinning av ett ej erkänt underordnat fält, som
återfinns på kanske den tredje eller fjärde nivån, utan risk för feltolkning
av data eller riskför att meddelandet ogiltigförk laras finns emellertid
inte. De föreslagna förändringarna som krävs för ADEXP-formatet är
utformade för att säkerställa, att en lexikalisk analysator alltid kan fastslå
var den befinner sig inom strukturen av ett meddelande eller ett indivi-
duellt fält, och därigenom möjliggöra att återvinning kan ske på alla
nivåer utan risk för felaktig tolkning av data.
G.3.Förslag
För att uppnå målsättningen med återvinning på alla nivåer av ett medde-
lande, är det nödvändigt att den lexikaliska analysatorn kan fastställa
slutet, såväl som början av ett fält. Det nuvarande formatet möjliggör
endast fastställande av början av ett fält genom användadet av tecknet
”-”.
Det kommer att föreslås, i en framtida utgåva av ADEXP, att introducera
användandet av parenteser för att indikera början respektive slutet av ett
fält. Den nuvarande användningen av tecknet ”-” för att markera början
av fält skulle ersättas av tecknet ”(”. Slutet av ett fält, vilket inte är
uttryckligen markerat idag, skulle markeras med tecknet ”)”. Följandeexempel är ämnade för att demonstrera principen.
Exempel
Nuvarande Format Föreslaget Format
Exempel på enkelt fält: -RFL F330 (RFL F330)Exempel på sammansatt fält: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430))2000R2082 — SV — 15.06.2002 — 001.001 — 148
▼B
BILAGA III
UTBYTE AV FLYGDATA — DOKUMENT FÖR KONTROLL AV
GRÄNSSNITT (FDE-ICD), UTGÅVA 1.0
(Eurocontrol-dokument COM.ET1.ST12-STD)
OBS: översättning av texten finns redan2000R2082 — SV — 15.06.2002 — 001.001 — 149
▼B
INNEHÅLLSFÖRTECKNING
MEDDELANDE OM UPPHOVSMANNARÄTT
FÖRORD1. INLEDNING2. OMFATTNING3. HÄNVISNINGAR
3.1. Inledning3.2. Hänvisningar
4. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
4.1. Definitioner4.2. Symboler och Förkortningar4.3. Beteckningssätt
5. TEKNISK ÖVERSIKT
5.1. Protokollstack5.2. Profilens uppbyggnad5.3. Förhållande till tidigare versioner av specifikationen
6. PROFILKRAV
6.1. Krav för överensstämmelse6.2. Krav på övre skikt6.3. Krav på lägre skikt6.3.1. Krav på transportskikt6.3.2. Krav på nätverksskikt6.3.3. Krav på datalänkskikt6.3.4. Krav på fysiska skikt
7. TESTMETODERBILAGA A (NORMATIV) PROTOKOLL FÖR MEDDELANDEÖVERFÖRING
A.1. InledningA.2. Implementerad tjänstA.3. Förutsatt tjänstA.4. ProtokollspecifikiationA.4.1. InledningA.4.2. DatatyperA.4.3. Upprättande av anslutningA.4.4. DataöverföringA.4.5. Kontrollerad nedkoppling av anslutningA.4.6. Aterupprättande av anslutningA.4.7. AnslutningsintegritetA.4.8. Okontrollerad nedkoppling av anslutningA.4.9. Återhämtning vid avbrott2000R2082 — SV — 15.06.2002 — 001.001 — 150
▼B
A.4.10. Meddelandeformat
A.5. Tabeller med tillståndingsövergångar i protokkoletA.5.1. Inledning
A.5.2. Tilståndsdefinitioner
A.5.3. Möjliga händelserA.5.4. TimrarA.5.5. Tabel över tillståndsövergångarA.5.6. Flödesdiagram över tillståndsövergångar
BILAGA B (NORMATIV) MESSAGE HEADER PROTOCOL
B.1. InledningB.2. Implementerad tjänstB.3. Förutsatt tjänstB.4. ProtokollspecifikationB.4.1. Upprättande av ForbindelseB.4.2. Undvikande av överflödiga nätverksanslutningarB.4.3. Nedkoppling av förbindelseB.4.4. Dataöverföring
BILAGA C (NORMATIV) NÄTVERKSPROTOKOLL
C.1. InledningC.2. Tillhandahållen tjänstC.3. Förutsatt tjänstC.4. NSAP-adresseringC.4.1. InledningC.4.2. Adresstruktur för NSAPC.4.3. Tildelning av ATC-enhetsbeteckningar och -enhetsväljareC.5. ProtokollspecifikationC.5.1. ÖversigtC.5.2. AdressekodningC.5.3. Kodning av fält för användarta
C.5.4. Behandling av adresser i INCOMING CALL-paket
C.5.5. Dataöverföring
BILAGA D (NORMATIV) PROFILSPECIFIKA PICS-DOKUMENT
D.1. Inledning
D.2. Instruktioner för ifyllnad av PICS-dokument
D.2.1. Allmän uppbyggnad av PICS-dokumentD.2.2. TilläggsinformationD.2.3. UndantagsinformationD.2.4. Villkorliga elementD.3. PICS-dokument för protokollet för meddelandeöverföringD.3.1. Förkortningar och specielle beteckningar2000R2082 — SV — 15.06.2002 — 001.001 — 151
▼B
D.3.2. Identifiering
D.3.3. Protokollimplementering
D.4. PICS-dokument för protokollet för meddelanderubrikerD.4.1. Förkortningar och speciella beteckningarD.4.2. IdentifieringD.4.3. ProtokollimplementeringD.5. PICS-dokument för nätverksprotokolletD.5.1. Förkortningar och speciella beteckningarD.5.2. Identifiering
D.5.3. Protokollimplementering
BILAGA E (NORMATIV) PROFILKRAVLISTA
E.1. Inledning
E.2. Syftet med PRL- och PICS-dokumentenE.3. BeteckningarE.4. Instruktioner för att fylla i PICS-dokumentE.5. HänvisningarE.6. Utlåtande om överensstämmelse med standardenE.6.1. ÖversiktE.6.2. Dynamiska krav på överensstämmelse med standardenE.7. Krav på övre skikt
E.8. Krav på lägre skikt
E.8.1. Krav på transportskiktE.8.2. Krav på nätværksskiktE.8.3. Krav på datalänkskiktE.8.4. Krav på fysiska skikt
BILAGA F (INFORMATIV) METODIK FÖR TEST AV ÖVERENSSTÄMMELSE MED STAN-
DARDEN
F.1. Inledning
F.2. Syfte och omfattningF.3. LitteraturförteckningF.4. Utvecklingsmetoder och tillämpningarF.5. TesterF.5.1. InledningF.5.2. Test av de lägre skikten (skikt 1–3)F.5.3. Test av tillämpningsskiktet
F.5.4. Certifiering
F.5.5. Anvisning
BILAGA G (INFORMATIV) TILLDELNING AV IDENTITETER PÅ ATC-ENHETER
BILAGA H (INFORMATIVT) RIKTLINJER FÖR TILLFÖRLITLIGHET, TILLGÄNGLIGHET
OCH SÄKERHET2000R2082 — SV — 15.06.2002 — 001.001 — 152
▼B
H.1. Inledning
H.2. Syfte och omfattningH.3. Litteraturförteckning
H.4. Implementering av hyrda linjer
H.4.1. TillförlitlighetH.4.2. TillgänglighetH.4.3. SäkerhetH.4.4. Exempel på utformningH.5. NätverksimplementeringH.5.1. TillförlitlighetH.5.2. TilgänglighetH.5.3. SäkerhetH.6. Allmänna riktlinjer för hyrd linje och nätverksimplementeringarH.6.1. TillförlitlighetH.6.2. TilgänglighetH.6.3. SystemhanteringH.6.4. Exempel på utformning2000R2082 — SV — 15.06.2002 — 001.001 — 153
▼B
MEDDELANDE OM UPPHOVSMANNARÄTT
Detta dokument har sammanställts av Eurocontrolbyrån.
Eurocontrolbyrån har lagstadgad upphovsmannarätt.Innehållet, eller del därav, är således fritt tillgängligt för representanter för
medlemsstaterna, dockfår k opiering eller spridning av innehållet till någon
annan part inte ske utan skriftligt tillstånd från Eurocontrolbyrån.2000R2082 — SV — 15.06.2002 — 001.001 — 154
▼B
FÖRORD
1. Ansvarigt organ
Denna standard har sammanställts och upprätthålls av arbets-
gruppen för utbyte av färdplansrelaterad data FPDE (Flight Plan
related Data Exchange) inom europeiska organisationen för luft-
fartssäkerhet (Eurocontrol).
2. Eatchips arbetsprogramdokument
Denna standard har anknytning till Eatchips arbetsprogramdoku-
ment (EWPD), domänen för kommunikation, verkställandeuppdrag 01, specialistuppdrag 12
3. Godkännande av standarden
3.1. Denna standard har antagits i enlighet med de förfaranden som
beskrivs i Eurocontrols standardiseringsanvisningar, (Directives
for Eurocontrol Standardisation), Ref. 000-2-93.
3.2. Denna standard träder i kraft när den antas av Eurocontrols
ständiga kommission, och ersätter Eurocontrolstandard för utbyte
on-line av data (OLDI), utgåva 1, del 3: Tekniska krav (korttids-
dokument för gränssnittskontroll) Ref. 001-3-92.
4. Tekniska rättelser och ändringar
Denna standard hålls under granskning för att säkerställa erfor-
derliga ändringar eller tekniska rättelser. Förfarandet för
uppdatering av denna standard fastställs i bilaga H i anvisning-
arna för enhetliga utkast och utformning av Eurocontrols
standarddokument, Ref. 000-1-92.
5. Redaktionella regler
5.1. Formatet på denna standard överensstämmer med anvisningarna
för enhetliga utkast och presentationer av Eurocontrolstandarder.
5.2. Följande beteckningssätt har använts för att ange status på respek-
tive utlåtande:
— Normativa delar använder det modala hjälpverbet ”skall” och
har skrivits med normal text.
— Rekommenderade delar använder det modala hjälpverbet
”bör” och har skrivits med kursiv stil. Status indikeras med
prefixetRekommendation .
5.3. All annan information som betraktas som väsentlig för förståelsen
av ett särskilt stycke är infogad som en ANMÄRKNING.
Anmärkningar anses vara enbart informativa, varför de inte
innehåller specifikationer. Anmärkningar är placerade direkt efter
det stycke de hänvisar till.
5.4. För att presentera profilkravslistorna (PRL) i bilaga E i ett
lämpligt format, är undantagsvis en del tabeller inte formaterade
med indrag och löper inte heller över flera sidor.
6. Förhållande till andra standarder
6.1. Denna Eurocontrolstandard ersätter OLDI:s korttidsdokument för
gränssnittskontroll, ST-ICD, (Short Term Interface Control Docu-
ment), del 3, utgåva 1 av OLDI Eurocontrolstandard
[Referens 13].
6.2. Denna Eurocontrolstandard är den första delen i en planerad serie
av Eurocontrolstandarder för kontroll av gränssnitt (Interface
Control Documents — ICDs) för utbyte av flygdata.
7. Status på bilagorna till denna standard
Bilagorna till denna standard har följande status:
— Bilaga A — normativ
— Bilaga B — normativ
— Bilaga C — normativ— Bilaga D — normativ— Bilaga E — normativ
— Bilaga F — informativ2000R2082 — SV — 15.06.2002 — 001.001 — 155
▼B
— Bilaga G — informativ
— Bilaga H — informativ
8. Använt språk
Originaltexten i denna standard är skriven på engelska.2000R2082 — SV — 15.06.2002 — 001.001 — 156
▼B
1. INLEDNING
Denna Eurocontrolstandard är baserad på det korttidsdokument
för gränssnittskontroll som utvecklades av den tidigare tekniska
undergruppen inom OLDI, vilken hade som uppgift att definiera
nya gränssnittsstandarder för den framtida användningen av
OLDI mellan regionala ledningscentraler.
Tidigare OLDI-förbindelser baserades på ägarskyddade protokoll
som t.ex. INTERCAUTRA och Datenübertragungs- und Vertei-
lungssystem (DÜV). Dessa använder sig av dedikerade
direktlinjer eller begränsade nätverk och kräver speciell utrust-
ning och programvara.
För det större antal nya förbindelser som planeras ansågs det
önskvärt att övergå till en nätverksbaserad arkitektur, samt att
anta internationella standarder för telekommunikation. Detta för
att kunna upprätta förbindelser på ett mer kostnadseffektivt sätt,
genom en minskning av antalet anslutningar i varje central och
möjligheterna att använda sig av standardiserad maskin- och -
programvara.
Denna Eurocontrolstandard formaliserar och utvidgar korttidsdo-
kumentet för gränssnittskontroll. ST-ICD har omarbetats för att
ge en noggrannare specifikation som kommer att förbättra
samverkan och som dessutom är lämplig som grund för att fram-
tida dokument för gränssnittskontroll skall kunna uppfylla de
framtida kraven på utbyte av flygdata (FDE), inklusive mer
utbredd användning av delade nätverkoch införandet av nya stan-
darder för lägre skikt. Denna Eurocontrolstandard tillhandahåller
en minimiuppsättning av funktioner som kan stödjas av befintliga
OLDI-tillämpningar, med minimala modifieringar, genom
användandet av antingen direktlinjer eller Comité Consultatif des
Téléphones et Télégraphes (CCITT) rekommendation X.25, 1980
eller senare, över paketförmedlande nätverk. För anskaffande kan
flera möjligheter specificeras. Detta ICD förhindrar inte att bilate-
rala avtal utvecklas utöver detta.
Centraler som önskar använda andra tillämpningsprotokoll som
tillägg till, eller som ersättning för, det som beskrivs i detta doku-
ment, kan antingen ansöka om ändring av det nuvarande
protokollet, eller separera sina protokoll genom användandet av
skilda virtuella kretsar.
2. OMFATTNING
2.1. Denna Eurocontrolstandard specificerar ett gränssnitt för data-
kommunikation för utväxling av flygrelaterade meddelanden
mellan regionala ledningscentraler (ACC). Det presenteras i
formen av en OSI-profil (Open Systems Interconnection — OSI)
enligt definitionen i Internationella standardiseringsorganisa-
tionen/Internationella elektrotekniska kommissionens (ISO/IEC)
tekniska rapport (TR) 10000-2 [Referens 3]. Profilen omfattar
både undre skikt (T-profil) och övre skikt (A-profil).
2.2. Denna Eurocontrolstandard är tillämplig på följande:
— Stöd för OLDI enligt beskrivningen i Eurocontrolstandard
001-92 utgåva 1.
— Stöd för sändning av meddelanden från OLDI-tillämpningar
från regionala ledningscentraler (ACC) till systemen för cent-
ralenheten för trafikflödeskontroll (Central Flow Management
Unit — CFMU).
2.3. Standarden är tillämplig på anslutningar som använder antingen
— abonnerade direktlinjer,
— direktlinjer över det allmänna telenätet (PSTN), eller
— paketförmedlande datanätverk eller sammankopplade
paketförmedlande datanätverk som tillhandahåller ett
gränssnitt som uppfyller CCITT rekommendation X.25, 1980
eller senare.
ANMÄRKNINGAR
1. Samordningen mellan systemen för behandling av färdplaner
— (FPPS) framgår av Figur 1.
2. Figur 1 visar inte tänkbara reservanslutningar, som t.ex.
PSTN. Vägledning för detta ges i .2000R2082 — SV — 15.06.2002 — 001.001 — 157
▼B
Figur 1
Arrangemang för gränssnitt
2.4. Detaljerade säkerhetsaspekter på det specificerade gränssnittet för
datakommunikation tas inte upp i denna standard. Grundläggande
åtgärder specificeras emellertid i Bilaga C.5.4, och ytterligare
vägledning finns i Bilaga H till denna Eurocontrolstandard.
3. HÄNVISNINGAR
3.1. Inledning
Följande dokument och standarder innehåller villkor som genom
referens i denna text utgör förutsättningar för denna Eurocontrols-
tandard.
Vid publiceringen av denna Eurocontrolstandard var utgåvorna
som nämnts för de dokument och standarder, till vilka hänvisning
skett, giltiga.
Alla revisioner av de dokument från Internationella civila luft-
fartsorganisationen (ICAO) som det hänvisats till, skall
omgående beaktas för revision av denna Eurocontrolstandard.
Revisioner av de övriga dokument till vilka det hänvisats skall
inte utgöra del av villkoren för denna Eurocontrolstandard förrän
de formellt granskats och införts i denna Eurocontrolstandard.
Om konflikt uppstår mellan kraven i denna Eurocontrolstandard
och innehållet i något av de övriga dokument till vilket hänvis-
ning skett, skall denna Eurocontrolstandard ha företräde.
3.2. Referenser
1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for terminals operating in the
packet mode and connected to public data networks by dedi-
cated circuit. (ITU-T-rekommendation X.25 (1993) (Rev. 1),
Gränssnitt mellan terminalutrustning (DTE) och nätanslut-
ningsenheter (DCE) för terminaler i paketförmedlande läge
som är anslutna till allmänna datanätverkmed dedik erade
linjer.)
2. ISO/IEC TR 10000-1:1992, Information technology — Fram-
eworkand taxonomy of International Standardized Profiles:
— Part 1: Framework(2nd edition). (ISO/IEC TR 10000-
1:1992, Informationsteknologi — Ramverk och taxonomi för
Internationella standardiserade profiler: — Del 1: Ramverk
(2:a utgåvan).)
3. ISO/IEC TR 10000-2:1994, Information technology — Fram-
eworkand taxonomy of International Standardized Profiles
— Part 2: Principles and Taxonomy for OSI Profiles (3rd2000R2082 — SV — 15.06.2002 — 001.001 — 158
▼B
edition).(ISO/IEC TR 10000-2:1994, Informationsteknologi
— Ramverkoch taxonomi för Internationella standardiserade
profiler: — Del 2: Principer och taxonomi för OSI- profiler
(3:e utgåvan).)
4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface
between data terminal equipment (DTE) and data circuit-
terminating equipment (DCE) for synchronous operation on
public data networks. (ITU-T-rekommendation X.21 (1992)
(Rev. 1), Gränssnitt mellan terminalutrustning (DTE) och
nätanslutningsenheter (DCE) för synkron drift på allmänna
datanätverk.)
5. CCITT Recommendation X.21bis (1988), Use on public data
networks of data terminal equipment (DTE) which is
designed for interfacing to synchronous V-Series modems.
(CCITT-rekommendation X.21bis (1988), Användning avdataterminalutrustning (DTE), som konstruerats för gränssnitt
till synkrona modem i V-serien, på allmänna datanätverk.)
6. ISO/IEC 7776:1994, Information technology — Telecommu-
nications and information exchange between systems —
High-level data linkcontrol procedures — Description of
the X.25 LAPB-compatible DTE Data Linkprocedures (2nd
edition).(ISO/IEC 7776:1994, Informationsteknologi — Tele-
kommunikations- och informationsutbyte mellan system —
Förfaranden för kontroll av dataförbindelser på hög nivå —
Beskrivning av de X.25 LAPB-kompatibla förfarandena för
DTE-datalänkförbindelser (2:a utgåvan).)
7. ISO/IEC 8208:1993, Information Technology — Data
communications — X.25 Packet Layer Protocol for Data
Terminal Equipment (3rd edition).(ISO/IEC 8208:1993,
Informationsteknologi — Datakommunikation — X.25
paketskiktsprotokoll för terminalutrustning (3:e utgåvan).)
8. ISO/IEC ISP 10609-9:1992, Information technology — 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. (ISO/IEC ISP
10609-9:1992, Informationsteknologi — Internationella stan-
dardiserade profiler TB, TC, TD och TE — Transporttjänst
för anslutningsläge över nätverkstjänst för anslutningsläge
— Del 9: Subnätsberoende krav för nätverksskikt, datalänk-
skikt och fysiska skikt som rör permanent åtkomst till ett
paketförmedlande datanätverk med virtuella anrop.)
9. ISO/IEC 7498-1:1994, Information technology — Open
Systems Interconnection — Basic Reference Model: The
Basic Model (2nd edition).(ISO/IEC 7498-1:1994, Informa-
tionsteknologi — Systemförbindelser mellan öppna system
— Grundläggande referensmodell: Den grundläggande
modellen(2:a utgåvan).)
10. ISO/IEC 8348:1993, Information technology — Open
Systems Interconnection — NetworkService Definition (1st
edition).(ISO/IEC 8348:1993, Informationsteknologi —
Systemförbindelser mellan öppna system — Definition av
nätverkstjänst (1:a utgåvan).)
11. ISO/IEC 8072:1994, Information technology — Open
Systems Interconnection — Transport service definition (2nd
edition).(ISO/IEC 8072:1994, Informationsteknologi —
Systemförbindelser mellan öppna system — Definition av
transporttjänst (2:a utgåvan).)
12. ISO/IEC 8878:1992, Information Technology — Telecommu-
nications and information exchange between systems — Use
of X.25 to provide the OSI connection-mode Network
Service (2nd edition). (ISO/IEC 8878:1992, Informationstek-
nologi — Telekommunikations- och informationsutbyte
mellan system — Användande av X.25 för att tillhandahålla
OSI-nätverkstjänster för anslutning (2:a utgåvan).)
13. Eurocontrol Standard for On-Line Data Interchange (OLDI),
N
o001-92, Edition 1, 1992. 1(Eurocontrolstandard för utbyte
on-line av data (OLDI), 001-92, Edition 1, 1992.)
14. ISO/IEC 9646-1:1994, Information technology — Open
Systems Interconnection — Conformance testing method-
ology and framework— Part 1: General concepts (2nd2000R2082 — SV — 15.06.2002 — 001.001 — 159
▼B
edition). (ISO/IEC 9646-1:1994, Informationsteknologi —
Systemförbindelser mellan öppna system — Metodikoch
ramverkför test av k onformitet — Del 1: Allmänna begrepp
(2:a utgåvan).)
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Part 1 Integration Test Plan Version 1.0,
dated 10 May 1996. (Eurocontrol (Maastricht Upper Area
Control (UAC) Systems Division) FDE ICD Del 1, Testplan
för integration, Version 1.0, daterad 10 maj 1996.)
16. Eurocontrol FDE ICD Part 1 — Reliability, Availability and
Security — Technical Report version 1.0, dated 20 April
1997. (Eurocontrol FDE ICD Del 1 — Tillförlitlighet,
tillgänglighet och säkerhet — Teknisk rapport, version 1.0,
daterad 20 april 1997.)
17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface
between DTE and DCE for terminals operating in the packet
mode and accessing a packet switched public data through a
public switched telephone networkor an integrated services
digital networkor a circuit switched public data network .
(ITU-T-rekommendation X.32 (1993) (Rev. 1), Gränssnitt
mellan DTE och DCE för terminaler som fungerar i
paketläge och som har åtkomst till paketförmedlat data över
det offentliga telenätet, ett ISDN-nät eller ett allmänt krets-kopplat datanät.)
18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering
plan for the ISDN era. (ITU-T-rekommendation E.164
(1991) (Rev.1), Nummerplan för ISDN.)
19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-swit-
ched signalling system between public networkproviding
data transmission service. (ITU-T-rekommendation X.75
(1993) (Rev. 1), Paketförmedlat signalsystem mellan
allmänna nätverksom tillhandahåller dataöverföringstjänster.)
20. ITU-T Recommendation X.121 (1993), International
numbering plan for public data networks. (ITU-T-rekommen-
dation X.121 (1993), Internationell nummerplan för allmänna
datanätverk.)
4. DEFINITIONER, SYMBOLER OCH FÖRKORTNINGAR
4.1. Definitioner
4.1.1. För denna Eurocontrolstandard gäller följande definitioner:4.1.2. Profil: En grupp av en eller fler grundstandarder, och när
tillämpligt, benämningen av utvalda klasser, undergrupper,
valmöjligheter och parametrar i dessa grundstandarder som är
nödvändiga för att uppnå en speciell funktion [Referens 2].
4.1.3. Profilkravslista (PRL) : Profilkraven uttrycks som krav på
överensstämmelse och har ordnats i tabellform [Referens 2].
4.1.4. T-profil: Transportprofil som tillhandahåller en transporttjänst för
anslutningsläge [Referens 3].
4.1.5. A-profil: Tillämpningsprofil som kräver en transporttjänst för
anslutningsläge [Referens 3].
4.1.6. Utlåtande om ett infört protokolls överensstämmelse (PICS) : Ett
uttalande från leverantören av ett OSI-system, i vilket det uppges
vilka möjligheter som implementerats för ett bestämt OSI-proto-
koll [Referens 14].
4.2. Symboler och Förkortningar
För denna Eurocontrolstandard gäller följande definitioner:
ACC Regional kontrollcentral (Area Control
Centre)
AFI Myndighets- och format-ID (Authority and
Format Identifier)
ASCII Amerikansk standardkod för informationsut-
byte (American Standard Code for
Information Interchange)
ATC Flygkontrolltjänst (Air Traffic Control)2000R2082 — SV — 15.06.2002 — 001.001 — 160
▼B
ATCC Central för flygkontrolltjänst (Air Traffic
Control Centre)
CAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télégrap-
hique et téléphonique (numera ITU-T)
CFMU Centralenhet för trafikflödeskontroll (Central
Flow Management Unit)
CUG Sluten användargrupp (Closed User Group)
DCE Nätanslutningsenheter (Data Circuit-termi-
nating Equipment)
DCTS Terminalsystem för digital kommunikation
(Digital Communications Terminal System)
DSP Domänspecifikdel (Domain Specific Part)
DTE Terminalutrustning (Data Terminal Equip-
ment)
DÜV Datenübertragungs- und Verteilungssystem
FDE Utbyte av flygdata (Flight Data Exchange)
FEP Front-end processor
FPDE Utbyte av färdplansrelaterad data (Flight
Plan related Data Exchange)
FPPS System för behandling av färdplaner (Flight
Plan Processing System)
ICAO Internationella civila luftfartsorganisationen
ICD Dokument för kontroll av gränssnitt (Inter-
face Control Document)
IDI Inledande domänidentifiering (Initial
Domain Identifier)
IDP Inledande domändel (Initial Domain Part)IEC Internationella elektrotekniska kommis-
sionen
INTERCAUTRA Inter-CAUTRA-protokoll
ISO Internationella standardiseringsorganisa-
tionen
ITU-T Internationella teleunionen — sektorn för
standardisering av telekommunikation
(International Telecommunication Union —
Telecommunication Standardization Sector)
ISDN Digitalt flertjänstnät (Integrated Services
Digital Network)
LAPB Standardiserat protokoll för datakommunika-
tion (LinkAccess Procedure Balanced)
LSB Minst betydande bit (Least Significant Bit)
M, m Obligatorisk
MSB Mest betydande bit (Most Significant Bit)
MT Meddelandeöverföring
NA Ej tillämpbart
NS Nätverkstjänst
NSAP Punkt för tillgång till nätverkstjänster
(NetworkService Access Point)
NSDU Dataenhet för nätverkstjänster (Network
Service Data Unit)
O, O.<n> Valfritt, där <n> är ett referensnummer
o, o.<n> Valfritt, där <n> är ett referensnummerOLDI Direktuppkopplad datautbyte
OSI Systemförbindelser mellan öppna system
(Open Systems Interconnection)
PICS Utlåtande om ett infört protokolls
överensstämmelse (Protocol Implementation
Conformance Statement)
PLP Protokoll för paketskikt (Packet Layer
Protocol)
PRL Profilkravslista (Profile Requirements List)PSTN Offentligt telefonnät (Public Switched Tele-
phone Network)2000R2082 — SV — 15.06.2002 — 001.001 — 161
▼B
ST-ICD Korttidsdokument för gränssnittskontroll
(Short Term Interface Control Document)
SUT System under test
T<x> Timer (där <x> är en enkel eller dubbel
bokstav för referens)
TA Terminaladapter
TSDU Dataenhet för transporttjänst (Transport
Service Data Unit)
TPDU Dataenhet för transportprotokoll (Transport
Protocol Data Unit)
TR Teknisk rapport från ISO
X Förbjudet
x Utelämnat<element> Villkorad beståndsdel (beroende på
elementet)
4.3. Beteckningssätt
4.3.1. I denna Eurocontrolstandard betecknas binära tal eller en följd av
bitar, med hexadecimala tal genom beteckningen 'd'H, där
bokstaven ”d” betyder ett tecken eller en följd av hexadecimala
tecken.
4.3.2. I denna Eurocontrolstandard är det hexadecimala återgivandet av
en följd av bitar uppbyggd genom att fyra bitar i taget tas, från
den mest betydande biten (MSB) till den minst betydande biten
(LSB).
ANMÄRKNING Om inte annat specificeras i de internationella
standarder det hänvisas till, skickas en följd av
bitar från MSB till LSB.
4.3.3. I denna Eurocontrolstandard skall statusen på stödet för funk-
tioner i en grundstandard eller denna Eurocontrolstandard, anges
med versaler (t.ex. M, O, O.<n>, X). Den exakta betydelsen av
varje statussymbol beskrivs i bilagorna till denna Eurocontrolstan-
dard före dess användning.
4.3.4. I syfte att definiera FDE ICD del 1-profilen i denna Eurocontrols-
tandard, skall statusen på stödet för funktioner i en grundstandard
eller denna Eurocontrolstandard, anges med gemener (t.ex. m, o,
o.<n>, x).
ANMÄRKNING Resultatet är en ytterligare förfining av de
funktioner i grundstandarderna som är villko-
rade, valfria eller värdeberoende (se E.3.1).
5. TEKNISK ÖVERSIKT
5.1. Protokollstack
ANMÄRKNING Protokollstacken för profilen i denna Eurocon-
trolstandard illustreras i Figur 2. Bilden visar
protokollens placering i ramverket för den
grundläggande referensmodellen för OSI
[Referens 9] genom att återge stacken bredvid
motsvarande OSI-skikt. Protokollstacken är
emellertid specificerad för äldre system än
OSI, och stödjer inte de många funktioner som
tillåts i OSI-protokollen för motsvarande OSI-
skikt.2000R2082 — SV — 15.06.2002 — 001.001 — 162
▼B
Figur 2
Protokollstack för profilen
5.2. Profilens uppbyggnad
ANMÄRKNINGAR
1. Som visas i Figur 2, kombinerar profilens protokollstack flera
protokoll i lägre skikt. Av dessa är endast X.25-protokollet för
paketskikt (PLP) [Referens 1] och dess stödprotokoll, X.21
[Referens 4] och X.21bis [Referens 5], definierade i befintliga
standarder hos ISO/IEC och Internationella teleunionen —
sektorn för standardisering av telekommunikation (ITU-T).
Övriga protokoll i högre skikt är definierade i bilagorna A, B
och C till denna Eurocontrolstandard.
2. Profilens krav på överensstämmelse kan hänvisa till dessa
specifikationer, som är jämförbara med externa standarder
och anges i avsnitt 6. De detaljerade kraven framförs i
tabeller över PRL (Bilaga E) och PICS-dokument (proforma
för protokoll definierade i bilagorna anges i Bilaga D).
Användandet av dessa PRL- och PICS-dokument vid utveck-
ling och/eller anskaffande förklaras i Bilaga E.
5.3. Förhållande till tidigare versioner av specifikationen
ANMÄRKNINGAR
1. Denna profil grundar sig på det ST-ICD som utvecklades av
den tidigare tekniska undergruppen inom OLDI. Protokollen
och paketformaten som definieras i denna Eurocontrolstan-
dard är en kompatibel undergrupp av de som definieras i ST-
ICD, med undantag av att denna Eurocontrolstandard ställer
mer detaljerade krav på användandet av X.25 PLP, inkluderar
obligatoriskt stöd för M-biten samt korrigerar de motstridiga
specifikationerna på myndighets- och format-ID (AFI) -värdet
i adressen till punkten för tillgång till nätverkstjänster (NSAP).
2. Den huvudsakliga förändringen av utformningen av denna
Eurocontrolstandard berör uppbyggnaden av ICD-specifika-
tionen. Protokollet för meddelandeöverföring (Bilaga A) har
avskiljts från den stödjande T-profilen. Detta underlättar
användandet av andra T-profiler då detta blir nödvändigt för
att stödja kommande FDE-krav.
3. De delar av ST-ICD som berör kontroll av virtuella kretsar för
X.25 och avgränsande tillämpningsmeddelanden finns nu i
protokollet för meddelanderubriker (Bilaga B), vilket utgör
ett minimalt transportskikt för FDE.2000R2082 — SV — 15.06.2002 — 001.001 — 163
▼B
6. PROFILKRAV
6.1. Krav för överensstämmelse
6.1.1. En implementering som påstås överensstämma med denna speci-
fikation skall uppfylla kraven som framförs i avsnitten 6.2 och
6.3 nedan.
6.1.2. Ett påstående om överensstämmelse skall stödjas av ett utlåtande
om ett infört protokolls uppfyllande (PICS) av standarden, enligt
beskrivning i Bilaga D och Bilaga E.
6.2. Krav på övre skikt
6.2.1. En implementering skall för att överensstämma med grundstan-
darden uppfylla de krav som redovisas i Bilaga A.
6.2.2. En implementering skall för att överensstämma med standarden
uppfylla de restriktioner som redovisas i profilkravslistan i
bilaga E.7.
6.3. Krav på lägre skikt
6.3.1. Krav på transportskikt
6.3.1.1. En implementering skall för att överensstämma med grundstan-
darden uppfylla de krav som redovisas i Bilaga B.
6.3.1.2. En implementering som överensstämmer med standarden skall
uppfylla restriktionerna som redovisas i profilkravslistan i bilaga
E.8.1.
6.3.1.3. En implementering som överensstämmer med standarden skall
uppfylla kravet på att stödja dataenheter för transporttjänst
(TSDU) på upp till och med 4097 oktetter.
ANMÄRKNING Den första oktetten i en TSDU utgörs av ett fält
för meddelanderubriken (se A.4.10 och B.4.4),
vilket gör att maximalt 4 096 oktetter kan
användas till användardata.
6.3.2. Krav på nätverksskikt
6.3.2.1. En implementering som överensstämmer med standarden skall
uppfylla kraven i ISO/IEC 8208 [Referens 7], i enlighet med
protokollmappningen som redovisas i Bilaga C.
6.3.2.2. En implementering som överensstämmer med standarden skall
uppfylla restriktionerna som redovisas i profilkravslistan i
bilaga E.8.2.
6.3.2.3. En implementering som överensstämmer med standarden skall,
om funktionen DTE-DTE stöds, ha förmågan att genom hanter-
ingsmekanismer i systemet, styra valet av uppgift för DTE eller
nätanslutningsenheter (DCE) för DTE-DTE-funktionen.
6.3.2.4. En implementering som överensstämmer med standarden skall för
alla uppgifter beskrivna i 6.3.2.3, kunna initiera en förbindelse
enligt specifikationen i Bilaga C, dvs. protokollet är helt symmet-
riskt.
ANMÄRKNING Vissa befintliga utföranden som baserats på ST-
ICD kanske inte kan initiera nätverksförbin-
delser i enighet med protokollet i Bilaga C.
6.3.2.5. En implementering som överensstämmer med standarden skall
under en tidsperiod tillåta icke standardiserade storlekar på stan-
dardpaket med värdet 256 i båda överföringsriktningarna.
6.3.2.6. En implementering som överensstämmer med standarden skall
använda NSAP-adresser enligt definitionen i Bilaga C.
6.3.2.7. En implementering som överensstämmer med standarden skall
sätta D-biten till 0 i CALL REQUEST-, CALL ACCEPTED-och DATA-paket.
ANMÄRKNING Att sätta D=0 i CALL REQUEST- och CALL
ACCEPTED-paket motsvarar att överföringsbe-
kräftelse inte används.2000R2082 — SV — 15.06.2002 — 001.001 — 164
▼B
6.3.3. Krav på datalänkskikt
6.3.3.1. En implementering som överensstämmer med standarden skall
uppfylla kraven som redovisas i ISO/IEC 7776 [Referens 6] för
LinkAccess Protocol Balanced (LAPB) Single LinkProtocol.
6.3.3.2. En implementering som överensstämmer med standarden skall
också uppfylla restriktionerna som redovisas i profilkravslistan i
bilaga E.8.3.
6.3.4. Krav på fysiska skikt
En implementering som överensstämmer med standarden skall
uppfylla kraven som redovisas i ISO/IEC ISP 10609-9 klausul 7
[Referens 8].
7. TESTMETODER
ANMÄRKNINGAR1. En metod för test av implementeringens överensstämmelse med
denna specifikation beskrivs i Bilaga F.
2. Användandet av de PRL- och PICS-dokument som tillhan-
dahålls med denna specifikation för dokumentering av
överensstämmelse med standarden, beskrivs i Bilaga E.2000R2082 — SV — 15.06.2002 — 001.001 — 165
▼B
BILAGA A (Normativ)
PROTOKOLL FÖR MEDDELANDEÖVERFÖRING
A.1. Inledning
Denna specifikation definierar ett protokoll avsett att implementera
en enkel tjänst för meddelandeöverföring för tillämpningar som
kräver utbyte av flygdata.
A.2. Implementerad tjänst
Protokollet för meddelandeöverföring (MT) implementerar följande
obekräftade tjänster:
MT-Associate: Upprättar en anslutning för överföring av tillä-
mpningsmeddelanden.
MT-Data: Överför ett tillämpningsmeddelande bestående av ASCII-
tecken.
MT-Abort: Avslutar en anslutning för överföring av tillämpnings-
meddelanden.
A.3. Förutsatt tjänst
Detta protokoll för meddelandeöverföring förutsätter en undergrupp
av transporttjänsten för förbindelseläge enligt definitionen i ISO/IEC
8072 [Referens 11], som det som ingår i det protokoll som defini-
eras i Bilaga B till denna Eurocontrolstandard.
A.4. Protokollspecifikation
A.4.1. Inledning
I följande text beskrivs endast funktionen för en tillämpningsiniti-
erad anslutning för meddelandeöverföring. Ytterligare anslutningar
kan upprättas med samma nätverksgränssnitt genom repetition av
dessa förfaranden för varje underliggande transportförbindelse.
A.4.2. Datatyper
Denna bilaga identifierar fyra typer av programmeddelanden. Dessa
motsvarar de som definieras i Eurocontrolstandard 001-3-92
utgåva 1:
Systemmeddelanden : Dessa meddelanden skall användas för
länkövervakning (HEARTBEAT-meddelande) och programkontroll
(STARTUP- och SHUTDOWN-meddelanden).
Operativa meddelanden : Dessa meddelanden skall kopplas till ett
specifikt operativt sammanhang och är definierade i de Eurocon-
trolstandarder och -dokument som använder denna standard för
utbyte av data. Eurocontrolstandarden för OLDI definierar operativa
meddelanden som t.ex. aktiveringsmeddelande (ACT), förhandsmed-
delande om gränsinformation (ABI) och logiskt
bekräftelsemeddelande (LAM).
Användarmeddelanden : Dessa meddelanden skall innehålla fri text.
Deras användning skall vara bilateralt överenskommen. De kan
t.ex. användas för att utväxla testinformation eller för att informera
motparten om användaråtgärder.
Statusmeddelanden : Användningen av, och innehållet i dessa
meddelanden skall vara bilateralt överenskommet. De kan t.ex.
användas för att utväxla systemhanteringsinformation.
ANMÄRKNINGAR1. Användningen av systemmeddelanden är en del av detta proto-
koll, och deras format specificeras i stycke A.4.10.3 i denna
bilaga.
2. Användningen av, och formatet på statusmeddelanden regleras
av bilaterala överenskommelser och specificeras inte ytterligare
i denna Eurocontrolstandard.
3. Vilka typer av meddelanden som kan sändas beror på protokol-
lets tillstånd. Detta specificeras i följande stycken.2000R2082 — SV — 15.06.2002 — 001.001 — 166
▼B
A.4.3. Upprättande av anslutning
A.4.3.1. Protokollet är inledningsvis i tillståndet IDLE.A.4.3.2. Primitivet för begäran av MT-Associate verkställs för att upprätta en
anslutning mellan tillämpningar och för att överföra protokollet till
tillståndet DATA_READY. Primitivet måste anropas av både den
lokala tillämpningen och fjärrtillämpningen.
A.4.3.3. Det är först nödvändigt att upprätta en underliggande transportför-
bindelse enligt förfarandet för T-Connect-primitiv, som beskrivs i
Bilaga B stycke B.4.1. Efter detta övergår protokollet till tillståndet
READY. I detta skede kan endast systemmeddelanden (och
möjligtvis, enligt bilateral överenskommelse, användarmeddelanden)
överföras. För att överföra ett system- eller användarmeddelande
använder sig avsändaren av primitivet T-Data (se B.4.4), med
meddelandet som parameter.
A.4.3.4. Ett STARTUP-meddelande (systemmeddelande) skall därefter
sändas, timer Tr (se A.4.7) skall startas och protokollet övergår
sedan till tillståndet ASSOCIATION_PENDING. Om timer Tr
överskrids medan protokollet fortfarande befinner sig i detta
tillstånd skall STARTUP-meddelandet sändas igen och timern
startas om.
ANMÄRKNING Protokollet kvarstår i tillståndet ASSOCIATION_-
PENDING, tills ett STARTUP-meddelande mottas.
Fortlöpande överskridning av Tr-timern kan
signaleras lokalt.
A.4.3.5. Mottagning av STARTUP-meddelandet skall medföra följande
åtgärder:
— I tillståndet ASSOCIATION_PENDING sänds ytterligare ett
STARTUP-meddelande, protokollet övergår till tillståndet
DATA_READY och indikeringsprimitivet för MT-Associate
signaleras.
— I alla andra tillstånd ignoreras meddelandet.
A.4.3.6. Mottagande av STARTUP-meddelandet i tillståndet ASSOCIA-
TION_PENDING motsvarar något av följande:
— Fjärrtillämpningen skickade ett primitiv för begäran om MT-
Associate, och dess protokoll för meddelandeöverföring har
övergått till tillståndet ASSOCIATION_PENDING.
— Fjärrtillämpningens protokoll för meddelandeöverföring svarar
på ett tidigare mottaget STARTUP-meddelande och har övergått
till tillståndet DATA_READY.
ANMÄRKNING Denna osäkerhet uppstår därför att samma
meddelande används för STARTUP som för svar
på STARTUP. På grund av detta kommer det
protokoll för meddelandeöverföring som först
övergick till tillståndet DATA_READY, att erhålla
ytterligare ett STARTUP-meddelande. Som
beskrivet i A.4.3.5 skall detta STARTUP-medde-
lande ignoreras.
A.4.3.7. När STARTUP-meddelanden utväxlats är anslutningen upprättad,
och alla angivna meddelandetyper kan överföras (tillståndet
DATA_READY).
A.4.4. Dataöverföring
Andra typer av meddelanden överförs på samma sätt som system-
meddelanden, med hjälp av tjänsten T-Data, med meddelandet som
parameter. Detta motsvarar tjänsteprimitiven för begäran och indi-
kering för MT-Data.
ANMÄRKNING Varje meddelande sänds som en enstaka TSDU:
det förekommer ingen hoplänkning eller segmen-
tering av meddelanden på denna nivå.
A.4.5. Kontrollerad nedkoppling av anslutning
A.4.5.1. Anslutningen för meddelandeöverföring mellan två tillämpningar
kan avslutas av båda sidor. Detta motsvarar tjänsteprimitivet för
begäran om MT-Abort.2000R2082 — SV — 15.06.2002 — 001.001 — 167
▼B
A.4.5.2. Följande åtgärder skall vidtas:
— I tillståndet DATA_READY skall ett SHUTDOWN-meddelande
(systemmeddelande) sändas, timer Tr och Ts skall stoppas och
transportförbindelsen skall kopplas ner.
— I tillståndet ASSOCIATION_PENDING skall ett SHUTDOWN-
meddelande (systemmeddelande) sändas, timer Tr skall stoppas
och transportförbindelsen skall kopplas ner.
— I tillståndet READY skall transportförbindelsen kopplas ner.— I övrigt vidtas inga åtgärder.
ANMÄRKNING SHUTDOWN-meddelandet är inte en tidig
varning – anslutningen kopplas ner omedelbart.
Det kommer ingen bekräftelse från den andra
sidan.
A.4.5.3. Mottagande av ett SHUTDOWN-meddelande skall medföra följande
åtgärder:
— I tillståndet DATA_READY skall timer Ts (se A.4.7) stoppas,
indikering för MT-Abort signaleras och gränssnittet övergå till
tillståndet ASSOCIATION_PENDING utan att sända ett
STARTUP-meddelande.
— För alla andra tillstånd vidtas inga åtgärder.
A.4.6. Återupprättande av anslutning
Tillämpningen som initierade nedkopplingen av anslutningen
ansvarar för att, när den är redo, återupprätta anslutningen samt
eventuella lägre skikt (om nödvändigt).
ANMÄRKNING Om nedkopplingen av anslutningen resulterat i att
den underliggande nätverksförbindelsen avslutats
måste förfarandet för upprättande av anslutning,
beskriven i stycke A.4.3, följas.
A.4.7. Anslutningsintegritet
A.4.7.1. Integriteten hos anslutningen mellan två tillämpningar sköts genom
heartbeat-funktionen.
A.4.7.2. När tillståndet DATA_READY uppnås, och när någon typ av
meddelande sänds över transportförbindelsen, skall en ställbar timer,
Ts, (om)startas. Om timern Ts överskrids i tillståndet DATA_-
READY, skall ett HEARTBEAT-meddelande (systemmeddelande)
sändas (och timern skall startas om).
A.4.7.3. På liknande sätt skall då tillståndet DATA_READY uppnås, och vid
mottagning av alla meddelanden utom STARTUP-meddelanden
över förbindelsen, en ställbar timer Tr (om)startas. Om timern Tr
överskrids i tillståndet DATA_READY signaleras en indikering om
MT-Abort, sändning av alla meddelanden stoppas, timer Ts stoppas
och timer Tr startas om. Gränssnittet befinner sig i tillståndet
ASSOCIATION_PENDING.
ANMÄRKNING Tillämpningarna återupptar och synkroniserar
förbindelsen genom utväxling av STARTUP-
meddelanden (se A.4.3).
A.4.8. Okontrollerad nedkoppling av anslutning
A.4.8.1. Det kan uppstå en okontrollerad nedkoppling av en anslutning om
— transportförbindelsen bryts (t.ex. linjefel eller protokollfel),
— det inträffar något fel i en av de två tillämpningarna eller i ett av
systemen (detta kan bero på maskin- eller programvarufel, i
vissa fall kan den underliggande transportförbindelsen fortfa-
rande fungera),
ANMÄRKNING Enligt definitionen på transportprokotollet i
bilaga B, finns det inte någon sammanhängande
transportförbindelse som går från tillämpnings-
system till tillämpningssystem. Detta innebär att
ett avbrott i transportförbindelsen är ett direkt
resultat av avbrottet på nätverksförbindelsen.
A.4.8.2. Ett tillämpnings- eller systemfel kan upptäckas genom att tids-
begränsningen löper ut för mottagandet av ett förväntat
HEARTBEAT-meddelande (se A.4.7) från denna tillämpning.2000R2082 — SV — 15.06.2002 — 001.001 — 168
▼B
A.4.9. Återhämtning vid avbrott
A.4.9.1. Två fall måste beaktas:
— Efter fel på en transportförbindelse.
— Efter ett tillämpningsfel.
A.4.9.2. I båda fallen innebär ett återupprättande av anslutningen att det
normala förfarandet för upprättande av en anslutning (se A.4.3)
används, inklusive utväxling av STARTUP-meddelanden.
ANMÄRKNING Vid ett avbrott på tillämpningsnivån som inte
medför att den underliggande förbindelsen bryts,
kan det felande systemet sända ett SHUTDOWN-
meddelande (dvs. L_shutdown, anropat antingen
manuellt eller som del av tillämpningens logik)
innan försök att återupprätta anslutningen görs.
Detta avkortar fjärrtillämpningens tidsbegräns-
ning Tr, och kan resultera i en snabbare
återhämtning med mindre risk för dataförluster.
A.4.10. Meddelandeformat
A.4.10.1. Allmän meddelandeup pbyggnad
Alla meddelanden består av ett heltalsfält (”TYP”) från intervallet
1-63 åtföljt av meddelandets innehåll. ”TYP”-fältet är kodat i en
oktett som ett ASCII-tecken genom tillägget av '40'H till fältets
binära representation (t.ex. kodas värdet 3 som '43'H, tecknet ”C”).
Meddelandetexten består av ASCII-tecken kodade med ett tecken
per oktett. Detta ger följande format:
TYP Meddelandetext
oktett 1 oktett 2 …oktett n
A.4.10.2. Längd på meddelandetext
Meddelandetexter på upp till och med 4 096 oktetter skall stödjas.
A.4.10.3. Format på systemmeddelanden
Systemmeddelanden kodas med TYP = 4, kodat som '44'H. Medde-
landetexten består av två oktetter, kodade enligt följande:
— Startup-meddelande: '3031'H (ASCII siffrorna "01");
— Shutdown-meddelande: '3030'H (ASCII siffrorna "00");
— Heartbeat-meddelande: '3033'H (ASCII siffrorna "03").
A.4.10.4. Andra meddelandeformat
Fältet TYP definierar meddelandetypen, kodat enligt beskrivningen
ovan:
— värdet 1 (kodat som '41'H) Operativa meddelanden.
— värdet 2 (kodat som '42'H) Användarmeddelanden.
— värdet 5 (kodat som '45'H) Statusmeddelanden.
ANMÄRKNINGAR
1. Formatet för meddelandetexten i statusmeddelanden ligger
utanför omfattningen av denna Eurocontrolstandard.
2. Formatet för operativa meddelanden är beskrivet i Eurocontrols-
tandarder och dokument som definierar
meddelandetillämpningar, som t.ex. OLDI [Referens 13].
3. Användarmeddelanden består av utskrivbar ASCII-text. Om
meddelanden av denna typ stöds, måste ett användargränssnitt
tillhandahållas för att visa mottagna meddelanden och för att
medge sammansättning av meddelanden för sändning.2000R2082 — SV — 15.06.2002 — 001.001 — 169
▼B
A.5. Tabeller med tillståndsövergångar i protokollet
A.5.1. Inledning
Tillståndstabellerna nedan är den definitiva specifikationen på proto-
kollet. Vid avvikelse mot huvudtexten ovan gäller nedanstående
specifikation.
ANMÄRKNING Beteckningarna som använts för att beskriva
tillstånd, händelser, timrar och åtgärder är base-
rade på ST-ICD. Emellertid har följande
definitioner och resulterande åtgärder granskats,
de kan därför skilja sig från ST-ICD.
A.5.2. Tillståndsdefinitioner
Tabell 1
Tillståndsdefinitioner
Tillstånd Tillståndsbeskrivning Kompletterande tillståndsinformation
tillstånd 0 IDLE Ingen transportförbindelse
tillstånd 1 READY Transportförbindelse upprättad, lokal
användare otillgänglig, fjärranvändareotillgänglig
tillstånd 2 ASSOCIATION_-
PENDINGTransportförbindelse upprättad, lokal
användare tillgänglig, fjärranvändare
otillgänglig
tillstånd 3 DATA_READY Lokal användare tillgänglig,
fjärranvändare tillgänglig
A.5.3. Möjliga händelser
Tabell 2
Möjliga händelser
Händelse-beskrivning Kompletterande tillståndsinformation
L_data Indikering om att data (operativt, användar- eller statusmedde-
lande) skall sändas från den lokala användaren till fjärranvändaren
(Primitiv för begäran av MT-data)
L_shutdown Ett kommando ges för att stoppa den lokala användaren (MT-
avbrottsbegäran)
L_startup Ett kommando ges för att starta den lokala användaren (MT-
uppkopplingsbegäran)
R_data Indikerar att data tagits emot från fjärranvändaren (T-Data-indi-
kering, TYP ≠”System”)
R_heartbeat Ett HEARTBEAT-meddelande har mottagits från fjärranvändaren
(T-Data-indikering, TYP = ”System”, Meddelandekod = HEART-
BEAT)
R_shutdown Ett SHUTDOWN-meddelande har mottagits från fjärranvändaren
(T-Data-indikering, TYP = ”System”, Meddelandekod = SHUT-
DOWN)
R_startup Ett STARTUP-meddelande har mottagits från fjärranvändaren (T-
Data-indikering, TYP = ”System”, Meddelandekod = STARTUP)
Ts_timeout Överskridande av timer Ts
Tr_timeout Överskridande av timer Tr
TC_disconnect En indikering om upphörande av transportförbindelse har motta-
gits (T-Disconnect-indikering)
TC_setup Händelse (t.ex. ett explicit kommando, en tillämpningsförfrågan)
som medför ett primitiv för begäran om T-Connect2000R2082 — SV — 15.06.2002 — 001.001 — 170
▼B
A.5.4. Timrar
Tabell 3
Timrar
Timer Timer-information
Tr Tidsbegränsning för när ett HEARTBEAT- eller datameddelande
väntas
Ts Tidsbegränsning för sändande av ett HEARTBEAT-meddelande
till fjärranvändaren
Värdet för dessa tidsbegränsningar skall vara sådana att Tr = 2Ts +
överföringstiden.
ANMÄRKNING Typiska värden på dessa timrar är: Ts = 30 s, Tr
=7 0s .
A.5.5. Tabell över tillståndsövergångar
Tabell 4
Tillståndsövergångar
Tillstånd Händelse Åtgärder som skall vidtagas Nytt tillstånd
Tillstånd 0 TC_setup Transportskiktet försöker upprätta
förbindelse(r) för de lägre skikten
mellan den lokala användaren och
fjärranvändaren, när förbindelsen
upprättats meddelas användaren (1)tillstånd 1
TC_disconnect Systemet vidtar lämpliga åtgärder
men förblir i tillstånd 0tillstånd 0
L_data Ignoreras tillstånd 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignoreras (dessa händelser skall ej
inträffa)tillstånd 0
R_heartbeat
R_shutdown
R_startup
Tillstånd 1 L_startup Den lokala användaren sänder ett
STARTUP-meddelande till
fjärranvändaren, timer Tr startas (2)tillstånd 2
R_startup Den lokala användaren mottar ett
STARTUP-meddelande från
fjärranvändaren, detta STARTUP-
meddelande ignoreras då ingen
L_startup händelse inträffattillstånd 1
L_data Ignoreras tillstånd 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignoreras tillstånd 1
Ts_timeout
L_shutdown Transportförbindelsen kopplas ner tillstånd 0
TC_disconnect Den lokala användaren meddelas
att transportförbindelsen kopplats
ner (t.ex. p.g.a. ett fel eller att
fjärranvändaren kopplat ned)tillstånd 02000R2082 — SV — 15.06.2002 — 001.001 — 171
▼B
Tillstånd Händelse Åtgärder som skall vidtagas Nytt tillstånd
tillstånd 2 R_startup Den lokala användaren mottar ett
STARTUP-meddelande från
fjärranvändaren, timer Tr och Ts
startas; den lokala användaren
meddelas att data kan skickas på
förbindelsen, och mottagandet av
STARTUP-meddelandet till-
kännages explicit genom att svara
med ett annat STARTUP-medde-
lande (3)tillstånd 3
Tr_timeout Den lokala användaren skickar åter
ett STARTUP-meddelande om inte
ett STARTUP-meddelande erhölls
från fjärranvändaren inom en
specificerad tidsrymd Tr, timer Tr
återstartastillstånd 2
L_startup Ignoreras tillstånd 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown Den lokala användaren beordras
att koppla ner förbindelsen: ett
SHUTDOWN-meddelande sänds,
timer Tr stoppas och transportför-
bindelsen kopplas nertillstånd 0
TC_disconnect Den lokala användaren meddelas
att transportförbindelsen är
nedkopplad (t.ex. p.g.a. ett fel),timer Tr stoppas och förbindelsen
avbrytstillstånd 02000R2082 — SV — 15.06.2002 — 001.001 — 172
▼B
Tillstånd Händelse Åtgärder som skall vidtagas Nytt tillstånd
tillstånd 3 L_data Timer Ts startas om tillstånd 3
R_data Timer Tr startas om tillstånd 3
R_heartbeat
R_startup Om ett STARTUP-meddelande
mottas från fjärranvändaren
betraktas detta som en bekräftelse
på ett tidigare sänt STARTUP-
meddelande, timer Tr startas inte
omtillstånd 3
Ts_timeout Ett HEARTBEAT-meddelande
sänds och timer Ts startas omtillstånd 3
L_startup Ignoreras tillstånd 3 (4)
TC_setup
R_shutdown Timer Ts stoppas, Indikeringen
MT-Abort sänds till den lokala
användarentillstånd 2
Tr_timeout Timer Ts stoppas, indikeringen
MT-Abort sänds till den lokala
användaren, timer Tr startas omtillstånd 2
L_shutdown Ett SHUTDOWN-meddelande
sänds, timer Tr och Ts stoppas och
transportförbindelsen kopplas nertillstånd 0
TC_disconnect Den lokala användaren meddelas
att transportförbindelsen är
nedkopplad (t.ex. p.g.a. ett fel),
timer Tr och Ts stoppas och
förbindelsen avbrytstillstånd 0
ANMÄRKNINGAR
(1) Vid inträde i tillstånd 0 kan det övervägas att automatiskt generera händelsen TC_setup.
(2) Endast då tillstånd 1 uppnås genom en automatiskt genererad TC_setup-händelse, som beskrivet i
tillstånd 0, får händelsen L_startup genereras automatiskt.
(3) Denna metod garanterar att ett mottaget STARTUP-meddelande från en fjärranvändare alltid
bekräftas med ett STARTUP-meddelande.
(4) En del befintliga utföranden, tillkomna före denna Eurocontrolstandard, kan behandla denna
händelse som TC_disconnect, dvs. återgå till tillstånd 0.2000R2082 — SV — 15.06.2002 — 001.001 — 173
▼B
A.5.6. Flödesdiagram över tillståndsövergångar
ANMÄRKNING Protokollet beskrivs i figur A.1 i form av ett
flödesdiagram där tillståndsövergångarna visas.
Flödesdiagrammet är endast informativt: om avvi-
kelser förekommer mellan flödesdiagrammet och
tillståndstabellerna ovan, gäller tabellerna.
Figur A.1
Protokoll för meddelandeöverföring: Flödesdiagram över till-
ståndsövergångar2000R2082 — SV — 15.06.2002 — 001.001 — 174
▼B
BILAGA B (Normativ)
PROTOKOLL FÖR MEDDELANDERUBRIKER
B.1. Inledning
Denna bilaga definierar protokollet för meddelanderubriker, ett mini-
malt transportprotokoll för användning i tillämpningar som t.ex.
OLDI.
B.2. Implementerad tjänst
B.2.1. Protokollet för meddelanderubriker motsvarar en undergrupp av
transporttjänsten för anslutningsläge enligt definitionen i ISO/IEC
8072 [Referens 11], och innefattar följande tjänsteprimitiv.
T-Connect: upprätta en transportförbindelse för en tillämpning
T-Data:överför ASCII-data
T-Disconnect: avsluta transportförbindelsen för en tillämpning
B.2.2. Tjänsten stödjer inte multiplexöverföring, felkorrigering eller segmen-
tering och sammansättning.
B.3. Förutsättningar för tjänsten
Protokollet förutsätter tillgång till en pålitlig, grundläggande
nätverksfunktion som den som tillhandahålls genom X.25 Packet
Layer Protocol.
ANMÄRKNING Endast en enkel transportförbindelse stöds för varje
nätverksförbindelse.
B.4. Protokollspecifikation
B.4.1. Upprättande av förbindelse
Primitivet för T-Connect skall implementeras genom användandet av
tjänsten N-Connect i den underliggande nätverkstjänsten. Det finns en
direkt mappning mellan de två uppsättningarna (begäran, indikering)
primitiver. Alternativt kan en befintlig nätverksförbindelse användas
(t.ex. en som upprättats av mekanismer för systemhantering).
Rekommendationer
1. I det senare fallet ovan, bör nätverksförbindelsen återställas före
användning. Primitivet för N-Connect kan upprepas automatiskt
om inget svar erhållits inom en bestämd tid.
2. Om denna automatiska upprepning är infört bör försök göras
ungefär var 15:e sekund.
B.4.2. Undvikande av överflödiga nätverksanslutningar
Om ett primitiv för begäran om N-Connect är utestående (dvs. ingen
motsvarande N-Connect-bekräftelse eller primitiv för N-Disconnect
har signalerats) och en N-Connect-indikering signaleras, skall det
inkommande försöket till kontakt med nätverket avvisas eller rensas
bort, genom svar med ett primitiv för begäran om N-Disconnect,
endast då båda följande förhållanden råder:
— Den anropande NSAP-adressen i N-Connect-indikeringen är den
samma som den anropade NSAP-adressen i den utestående N-
Connect-begäran.
— Den anropande NSAP-adressen i den utestående N-Connect-
begäran är större än den anropade NSAP-adressen i den
utestående N-Connect-begäran. Jämförelsen görs på bit-strängarna
som formats av den använda binära kodningen för varje NSAP-
adress, enligt definitionen i ISO/IEC 8348 bilaga A [Referens
10] (en sträng skall anses vara större än någon av dess egna inle-
dande delsträngar, t.ex. '8800'H > '88'H).
B.4.3. Nedkoppling av förbindelse
B.4.3.1. För nedkoppling av förbindelse skall serviceprimitiven för N-Discon-
nect och N-Reset för den underliggande nätverkstjänsten användas.2000R2082 — SV — 15.06.2002 — 001.001 — 175
▼B
B.4.3.2. För att utföra en T-Disconnect-begäran, skall en N-Disconnect-
begäran signaleras. Alternativt skall, om upprättande av nätverksför-
bindelser genom primitivet för N-Connect inte stöds,
nätverksförbindelsen inte uttryckligen kopplas ner.
Rekommendation I det senare fallet ovan, bör nätverksförbindelsen
återställas.
B.4.3.3. En T-Disconnect-indikering skall signaleras vid mottagande av
endera av följande serviceprimitiv för nätverkpå en nätverk sförbin-
delse som motsvarar en helt eller delvis upprättad
transportförbindelse:
— N-Disconnect-indikering.
— N-Reset-indikering.
B.4.4. Dataöverföring
B.4.4.1. Primitivet för T-Data skall implementeras genom användandet av
primitivet för N-Data för den underliggande nätverkstjänsten. Det
finns en direkt mappning mellan de två uppsättningarna (begäran,
indikering) primitiv. Mappningen använder en TPDU-enhet som
överförs med nätverkstjänsten.
B.4.4.2. TPDU:n skall ha följande format, sänd från vänster till höger, varvid
meddelandestrukturen som definieras i A.4.10.1, skall sättas in i
fälten data(1), data(2)…data(n).
STX LENG ADEST DEST AEMM EMM data(1) ADR data(2) …
data(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
ANMÄRKNINGAR
1. Denna rubrik har definierats så att den skall vara identisk med
den som används i det INTERCAUTRA-förfarande som definierats
för utväxling av ACT-meddelanden mellan CAUTRA Paris,
London Air Traffic Control Centers 9020D-system och Digital
Communications Terminal System (DCTS) Maastricht/Karlsruhe,
vid transport av de meddelandeformat som definierats i Bilaga A.
I detta fall motsvarar fältet ”data(1)” TYP-fältet.
2. Användandet av fälten ADEST, DEST, AEMM, EMM och ADR
med värden andra än '40'H ligger utanför omfattningen av denna
Eurocontrolstandard, men kan vara föremål för bilateral överens-
kommelse.
B.4.4.3. Tjänsten T-Data skall begränsas till överförandet av utskrivbara
ASCII-tecken. Särskilt gäller att inga av dataoktetterna skall ha
värdet '03'H (tecknet ETX).
B.4.4.4. En implementering som överensstämmer med standarden skall
uppfylla kravet på stöd för dataenheter för nätverkstjänster (NSDU)
på upp till och med 4 105 oktetter.
B.4.4.5. En implementering som överensstämmer med standarden skall
förhindra hoplänkning av flera TSDU till en enskild NSDU.
B.4.4.6. En implementering som överensstämmer med standarden skall
förhindra uppdelning av en TSDU i flera NSDU.2000R2082 — SV — 15.06.2002 — 001.001 — 176
▼B
BILAGA C (Normativ)
NÄTVERKSPROTOKOLL
C.1. Inledning
Denna bilaga specificerar ett grundläggande nätverksprotokoll som
använder X.25 Packet Layer Protocol, för användning i både direkt-
anslutna och paketförmedlande nätverksmiljöer, för att stödja
överföringen av flygdata. Protokollets underuppsättning är kompatibel
med den som är definieras i [Referens 1] från 1980 års utgåva och
framåt.
C.2. Tillhandahållen tjänst
C.2.1. Protokollet implementerar OSI-nätverkstjänsten för förbindelseläge
enligt definitionen i ISO/IEC 8348 [Referens 10], med följande
undantag:
— NSAP-adresser är begränsade till formen definierad i C.4.2.
— Det finns ingen funktion för att upprätta en överenskommelse
mellan användare och leverantör av nätverkstjänsten (NS)
beträffande kvaliteten på tjänsterna kopplade till en nätverksans-
lutning.
— Överföring av NS-användardata under uppkoppling och nedkopp-
ling av en nätverksanslutning stöds inte, med undantag av det som
tillhandahålls enligt beskrivningen i C.5.3.
C.2.2. Följande tillägg till nätverkstjänsten erbjuds inte:
— Mottagningsbekräftelse.
— Påskyndad dataöverföring.
C.3. Förutsatt tjänst
Protokollet förutsätter tillgång till en OSI-datalänktjänst, som den
som erbjuds genom ISO/IEC 7776 (LAPB) [Referens 6].
C.4. NSAP-adressering
C.4.1. Inledning
C.4.1.1. Uppbyggnaden av NSAP-adresserna överensstämmer med definitio-
nerna i ISO/IEC 8348 bilaga A [Referens 10], som visat nedan.
C.4.1.2. Beståndsdelarna i NSAP-adressen är definierade nedan.
IDP: Inledande domändel, bestående av AFI- och IDI-fälten.
AFI: Myndighets- och format-ID.
IDI: Inledande domänidentifiering.
DSP: Domänspecifikdel.
C.4.2. Adresstruktur för NSAP
C.4.2.1. I denna Eurocontrolstandard skall adressdelarna begränsas till
följande format:
C.4.2.2. AFI-värdet 48 skall användas, indikerande ett lokalt IDI-format med
decimalabstrakt syntax.
C.4.2.3. IDI är null, följande det lokala formatet.
C.4.2.4. DSP skall bestå av två par av decimala siffror enligt följande:
— Det första paret är enhetsbeteckningen för en enhet för flygkon-
trolltjänst (ATC), vilken identifierar ett ATC-system och
därigenom även indirekt en plats.
— Det andra paret är en ATC-enhetsväljare, som kan användas för
att identifiera en särskild slutpunkt inom en ATC-enhet.2000R2082 — SV — 15.06.2002 — 001.001 — 177
▼B
C.4.2.5. Den resulterande NSAP-adresstrukturen illustreras nedan.
AFI DSP
48 ATC-enhetsbeteckning ATC-enhetsväljare
C.4.3. Tilldelning av ATC-enhetsbeteckningar och -enhetsväljare
C.4.3.1. Ansvaret för tilldelning av unika ATC-enhetsbeteckningar för varje
ATC-system kommer att ligga hos Eurocontrol, medan tilldelningen
av ATC-enhetsväljare sker av relevant myndighet inom ATC-admi-
nistrationen eller -organisationen.
C.4.3.2. Tilldelningen av ATC-enhetsbeteckningar vid tidpunkten för
upprättandet av denna standard redovisas i Bilaga G.
C.5. Protokollspecifikation
C.5.1. Översikt
Protokollet är baserat på det subnätverksberoende konvergensproto-
kollet för X.25(1980), definierat i till ISO/IEC 8878 [Referens 12],
med följande skillnader:
— Användarfunktionen snabbval (Fast Select) används inte, emel-
lertid används kodningen, som definieras i bilaga A till ISO/IEC
8878 [Referens 12] för användning med det utökade formatet för
användardata som finns tillgängligt i snabbvalsfunktionen, här i
det grundläggande formatets fält för användardata i CALL
REQUEST- och INCOMING CALL-paket eftersom begräns-
ningar i parametrarna till den tillåtna nätverkstjänsten säkerställer
att den kodade informationen får plats i 16 oktetter.
— Av parametrarna för nätverkstjänst, för vilka kodning är defini-
erad i ISO/IEC 8878 [Referens 12], sänds endast de anropande
och anropade NSAP-adresserna (och bara i formatet definierat i
C.4.2.) i CALL REQUEST-paketet.
— Fältet för användardata används inte i CALL ACCEPTED-,
CALL CONNECTED-, CLEAR REQUEST- eller CLEAR INDI-
CATION-paketen.
— De alternativa förfarandena för uppkoppling och nedkoppling av
nätverksförbindelser används inte.
— Mottagningsbekräftelse med hjälp av D-biten stöds inte.
ANMÄRKNING De tre första av dessa begränsningarna
säkerställer att all information som skall överföras
mellan två DTE respekterar begränsningarna för
fältet User Data i X.25 (1980) PLP.
C.5.2. Adresskodning
De anropande och anropade NSAP-adresserna skall kodas med den
önskade binära kodning som definieras i ISO/IEC 8348 bilaga A
[Referens 10].
C.5.3. Kodning av fält för användardata
C.5.3.1. Som ett resultat av kraven ovan, skall fältet för användardata i CALL
REQUEST- och INCOMING CALL-paket kodas enligt vad som
visas i Tabell 1, nedan. Alla 16 oktetterna skall sändas.
Tabell 1
Kodning av fält för användardata
Fältbeskrivning Högre semioktett Lägre semioktett
Oktett 0: Protokollidentitet bin(1000) bin(0100)
Oktett 1: Typ av meddelandekod bin(0010) bin(0000)
Oktett 2: Värde för meddelandekod (N CR) bin(0000) bin(0001)
Oktett 3: Parametertyp = Anropad NSAP bin(1100) bin(1001)
Oktett 4: Parameterlängd bin(0000) bin(0110)Oktett 5: Parametervärde (1:a oktetten) =
AFI-värdebin(0100) bin(1000)2000R2082 — SV — 15.06.2002 — 001.001 — 178
▼B
Fältbeskrivning Högre semioktett Lägre semioktett
Oktett 6: Parametervärde (2:a oktetten) =
enhetsbeteckning för ATC-enhettal av högre
ordningental av lägre
ordningen
Oktett 7: Parametervärde (3:e oktetten) =
ATC-enhetsväljaretal av högre
ordningental av lägre
ordningen
Oktett 8: Parametertyp = Anropande NSAP bin(1100) bin(1011)
Oktett 9: Parameterlängd bin(0000) bin(0110)
Oktett 10: Parametervärde (1:a oktetten) =
AFI-värdebin(0100) bin(1000)
Oktett 11: Parametervärde (2:a oktetten) =
enhetsbeteckning för ATC-enhettal av högre
ordningental av lägre
ordningen
Oktett 12: Parametervärde (3:e oktetten) =
ATC-enhetsväljaretal av högre
ordningental av lägre
ordningen
Oktett 13: Reserverad för framtida bruk bin(0000) bin(0000)
Oktett 14: Reserverad för framtida bruk bin(0000) bin(0000)
Oktett 15: Reserverad för framtida bruk bin(0000) bin(0000)
C.5.3.2. Andra parametrar beskrivna i ISO/IEC 8878 [Referens 12] skall inte
användas.
C.5.4. Behandling av adresser i INCOMING CALL-paket
C.5.4.1. DTE-adresser
Den anropande DTE-adressen i ett INCOMING CALL-paket skall
valideras mot en lokal lista över giltiga DTE-fjärradresser för
systemet. Om en ogiltig adress upptäcks skall anropet kopplas bort.
ANMÄRKNINGAR
1. Den anropade DTE-adressen, om närvarande, i ett INCOMING
CALL-paket, om närvarande, kan också valfritt valideras mot en
lista (vanligtvis med ett element) över giltiga DTE-adresser för
systemet.
2. I några fall kan DTE-adressen för en enhet avvika i värde och/
eller längd när enheten uppträder som det anropande eller anro-
pade systemet. Särskild hänsyn måste därför tas till detta vid
specificering eller implementering av valideringsfunktionen för
DTS-adresser.
C.5.4.2. NSAP-adresser
Den anropande NSAP-adressen, kodad enligt beskrivningen ovan, i
ett INCOMING CALL-paket skall valideras mot en lokal lista över
godkända NSAP-fjärradresser för systemet. Om en ogiltig adress
upptäcks, skall anropet kopplas bort.
ANMÄRKNING Den anropade NSAP-adressen kan även valideras
mot en lista över (vanligtvis med ett element)
giltiga lokala NSAP-adresser för systemet.
C.5.5. Dataöverföring
C.5.5.1. Som beskrivet i ISO/IEC 8878 bilaga A.5.3 [Referens 12], överförs
NSDU i fältet för användardata i ett DATA-paket.
ANMÄRKNING Som en följd av detta är det förbjudet att sända
mer än ett användarmeddelande, som t.ex. ett
OLDI-meddelande, per X.25-paket eller M-bitsse-
kvens.
C.5.5.2. NSDU som är längre än det maximalt tillåtna användardatat för den
virtuella kretsen skall delas upp i segment och sändas i fälten för
användardata som en följd av DATA-paket, där alla utom det sista
skall både ha maximal längd och M-biten satt (dvs. en More-bit-
sekvens).
C.5.5.3. Vid mottagning skall fälten för användardata i en More-bit-sekvens
sättas ihop så att de bildar den mottagna NSDU.2000R2082 — SV — 15.06.2002 — 001.001 — 179
▼B
BILAGA D (Normativ)
PROFILSPECIFIKA PICS-DOKUMENT
D.1. Inledning
D.1.1. Leverantören av en protokollimplementering som påstås uppfylla
specifikationerna i bilagorna A-C skall fylla i följande PICS-doku-
ment.
ANMÄRKNING Befrielse från upphovsmannarätten för PICS-doku-
ment: användare av denna Eurocontrolstandard får
fritt återge PICS-dokument i denna bilaga så att de
kan användas i avsett syfte, och får även publicera
ifyllda PICS.
D.1.2. Ett ifyllt PICS-dokument är PICS för berörd implementering. Ett
PICS är ett utlåtande över vilka av protokollets funktioner och
valmöjligheter som implementerats.
D.1.3. Det kan finnas ett antal användningsområden för ett PICS, bl.a.
följande:
— Som en kontrollista, av den person som ansvarar för implementer-
ingen av ett protokoll, för att minska risken att protokollet inte
uppfyller standarden på grund av överseende.
— För leverantören och köparen, eller potentiella köparen, av imple-
menteringen. Som en detaljerad anvisning om implementeringens
kapacitet, fastställd i förhållande till den gemensamma grund som
tillhandahålls av PICS-dokumenten.
— För användaren, eller den potentiella användaren, av implemen-
teringen som grund för att inledningsvis undersöka möjligheten
till samverkan med en annan implementering (notera att även
om samverkan aldrig kan garanteras, kan misslyckad samverkan
ofta förutses genom oförenliga PICS).
— Av en protokolltestare, som grund för att välja rätt tester för
utvärdering av om implementeringen överensstämmer med stan-
darden.
D.2. Instruktioner för ifyllnad av PICS-dokument
D.2.1. Allmän uppbyggnad av PICS-dokument
D.2.1.1. Implementeringsidentifieringen och protokollsammanfattningen är
den första delen av varje PICS-dokument, och skall fyllas i enligt
anvisning med den information som är nödvändig för fullständig
identifiering av både leverantör och implementering.
D.2.1.2. Huvuddelen av ett PICS-dokument består av ett frågeformulär i fast
format. Svar på frågorna i frågeformuläret skall anges i kolumnen
längs till höger, antingen genom att ett svar helt enkelt markeras för
att påvisa ett begränsat val (vanligtvis Ja eller Nej), eller genom angi-
vandet av ett värde eller ett intervall av värden.
ANMÄRKNINGAR
1. Varje element identifieras med en unik elementreferens i den
första kolumnen, den andra kolumnen innehåller frågan som skall
besvaras, den tredje kolumnen innehåller hänvisningar till det
material som specificerar elementet i denna Eurocontrolstandard.
De övriga kolumnerna visar statusen för elementet (om stöd är
obligatoriskt, valfritt, förbjudet eller villkorat) och lämnar
utrymme för svaren: se även D.2.4, nedan.
2. En leverantör kan också tillhandahålla, eller åläggas att tillhan-
dahålla, ytterligare information kategoriserad som antingen
tilläggsinformation eller undantagsinformation. Om sådan finns,
skall varje typ av ytterligare information lämnas i en underpa-
ragraf med element benämnda A<i> eller X<i>, för
korsreferens, där <i> är en entydig identifiering av elementet
(t.ex. ett siffra helt enkelt): det finns inga andra restriktioner på
dess format eller presentation.
D.2.1.3. Ett ifyllt PICS-dokument, inklusive all tilläggsinformation och
undantagsinformation, skall hänvisas till som utlåtandet om ett infört
protokolls överensstämmelse med standarden för berörd implemen-
tering.2000R2082 — SV — 15.06.2002 — 001.001 — 180
▼B
ANMÄRKNING När en implementering kan konfigureras på mer än
ett sätt, kan det vara möjligt att beskriva alla
sådana konfigurationer i en enda PICS. Leveran-
tören har emellertid möjlighet att tillhandahålla
mer än ett PICS, där var och en täcker någon
undergrupp av implementeringens konfigurering-
smöjligheter, om detta medför enklare och
tydligare presentation av informationen.
D.2.2. Tilläggsinformation
Element med tilläggsinformation låter en leverantör lämna ytterligare
information ämnad att underlätta tolkningen av ett PICS.
ANMÄRKNINGAR1. Det är inte menat eller förväntat att stora mängder skall tillhan-
dahållas, och ett PICS kan betraktas som komplett utan någon
sådan information. Ett exempel kan vara ett utkast över på vilka
sätt en (enstaka) implementering kan installeras för att fungera i
en mängd olika miljöer och konfigurationer, eller en kortfattad
förklaring (kanske baserad på speciella tillämpningsbehov) till
utelämnandet av funktioner som, även om de är valfria trots allt
normalt förekommer i implementeringen av detta protokoll.
2. Hänvisningar till element med tilläggsinformation kan anges
bredvid vilket svar som helst i frågeformuläret, och kan innefattas
i element för undantagsinformation.
D.2.3. Undantagsinformation
D.2.3.1. Det kan hända att en leverantör önskar besvara en fråga med statusen
obligatoriskeller förbjuden (efter det att något villk or tillämpats), på
ett sätt som står i strid med de anvisade kraven. Inget förtryckt svar
finns för detta i ”stöd”-kolumnen: istället skall leverantören skriva in
det saknade svaret i ”stöd”-kolumnen, tillsammans med en X<i>-
hänvisning till ett element med undantagsinformation.
D.2.3.2. Leverantören skall redovisa det ändamålsenliga skälet som del av
undantagsinformationen.
D.2.3.3. En implementering för vilken ett undantagselement krävs på detta
sätt, är inte i överensstämmelse med denna specifikation.
ANMÄRKNING En tänkbar anledning till situationen som beskrivits
ovan, är att en brist i standarden har rapporterats,
där en korrigering förväntas ändra de krav som
inte uppfylldes av implementeringen.
D.2.4. Villkorliga element
D.2.4.1. Individuella villkorade element indikeras med en villkorssymbol i
formatet ”<element>: 
” i statuskolumnen, där ”<element>” är en
elementhänvisning som visas i tabellens första kolumn för något
annat element, och ”
” är en statusbeteckning, M, O, O.<n> eller
X.
ANMÄRKNING En PICS-dokument kan innehålla ett antal villko-
rade element. Dessa är element för vilka både
tillämpning av elementet själv, och dess status om
den är tillämplig (obligatorisk, valfri eller
förbjuden), beror på om vissa andra element stöds
eller inte.
D.2.4.2. Om elementet som det hänvisats till genom villkorstecknet är
markerat som att det stöds, gäller det villkorade elementet och dess
status anges med ”
”. ”Stöd”-kolumnen skall vara ifylld på vanligt
sätt. Annars är inte det villkorade elementet relevant, och svaret (NA)
skall markeras.
D.2.4.3. Varje element vars hänvisning används i en villkorssymbol indikeras
med en asteriski k olumnen med element.
D.3. PICS-dokument för protokollet för meddelandeöverföring
D.3.1. Förkortningar och speciella beteckningar
D.3.1.1. Statusbeteckningar
M: Obligatorisk2000R2082 — SV — 15.06.2002 — 001.001 — 181
▼B
O: Valfri
D.3.1.2. Elementhänvisningar
Element i PICS-dokumenten identifieras genom mnemotekniska
elementhänvisningar. PICS-element som berör relaterade funktioner
identifieras genom elementhänvisningar som delar samma begynnel-
sebokstav eller -bokstavspar (med versaler). Nedan följer en lista
över dessa initialer, i samma ordning som grupperna med element
förekommer i PICS-dokumenten.
— MTsy, MTop, MTst, Mtor meddelandetyper
— MAE, MAR, MCI, MDT,
MAVförfaranden
— MEsu, MEsd, MEhb, Mety kodningar
— MNmsg storlekpå meddelande— Ts, Tr timrar
D.3.2. Identifiering
2000R2082 — SV — 15.06.2002 — 001.001 — 182
▼B
D.3.3. Protokollimplementering
D.4. PICS-dokument för protokollet för meddelanderubriker
D.4.1. Förkortningar och speciella beteckningar
D.4.1.1. Statusbeteckningar
M obligatorisk
O valfriO.<n> valfri, men stöd av åtminstone en grupp av alternativ,
benämnd med samma nummer <n> krävs
X förbjuden<element>: beteckning för villkor, beroende på det stöd som
markerats för <element> (se D.2.4)
D.4.1.2. Förkortningar
NA ej tillämpligt
D.4.1.3. Elementhänvisningar
Element i PICS-dokumenten identifieras genom mnemotekniska
elementhänvisningar. PICS-element som rör relaterade funktioner
identifieras genom elementhänvisningar som delar samma begynnel-2000R2082 — SV — 15.06.2002 — 001.001 — 183
▼B
sebokstav eller -bokstavspar (med versaler). Här följer en lista över
dessa initialer, i samma ordning som grupperna med element
förekommer i PICS-dokumenten.
— IHC1, IHC2, IHC3, IHC4,
IHCCuppkoppling av anslutning
— IHR1, IHR2 nedkoppling av anslutning
— IHT1, IHTx dataöverföring
— Tcr timer
D.4.2. Identifiering
2000R2082 — SV — 15.06.2002 — 001.001 — 184
▼B
D.4.3. Protokollimplementering
D.5. PICS-dokument för nätverksprotokollet
D.5.1. Förkortningar och speciella beteckningar
D.5.1.1. Statusbeteckningar
M obligatorisk
O valfri
D.5.1.2. Elementhänvisningar
Element i PICS-dokumenten identifieras genom mnemotekniska
elementhänvisningar. PICS-element som rör relaterade funktioner
identifieras genom elementhänvisningar som delar samma begynnel-
sebokstav eller -bokstavspar (med versaler). Nedan följer en lista2000R2082 — SV — 15.06.2002 — 001.001 — 185
▼B
över dessa initialer, i samma ordning som grupperna med element
förekommer i PICS-dokumenten.
— SNDCP1 fält för protokoll-ID
— NCRdae, NCRgae, NCCx,
NDRxparametrar i protokollmedde-
landen
— NCD1, NCD2, NCN1, NCN2 validering av adresser— NDT dataöverföring
D.5.2. Identifiering
2000R2082 — SV — 15.06.2002 — 001.001 — 186
▼B
D.5.3. Protokollimplementering
2000R2082 — SV — 15.06.2002 — 001.001 — 187
▼B
BILAGA E (Normativ)
PROFILKRAVSLISTA
E.1. Inledning
E.1.1. Denna bilaga tillhandahåller PRL för FDE ICD-profilen som defini-
eras i denna Eurocontrolstandard. Utlåtandet om överensstämmelse
med denna standard för en implementering som gör anspråkpå att
uppfylla kraven i denna profil skall genereras enligt nedanstående
instruktioner.
ANMÄRKNING Proforma i denna bilaga är baserade på dem som
medföljer hänvisade grundstandarder.
E.1.2. En implementering som överensstämmer med denna standard skall
uppfylla de obligatoriska kraven på överensstämmelse för de grunds-
tandarder som det hänvisats till i denna profil.
E.2. Syftet med PRL- och PICS-dokumenten
Statusen på detta avsnitt (E.2) är informativ: det utgör inte en av
bestämmelserna i denna del av denna Eurocontrolstandard.
— Syftet med att presentera kraven för överensstämmelse med stan-
darden i tabellform för PRL- och PICS-dokument är att
tillhandahålla en kontrollista med de funktioner som måste eller
kan vara implementerade. De underliggande begreppen är defini-
erade och beskrivna i ISO/IEC 9646-1 [Referens 14] (ITU-T
Rekommendation X.290 är likvärdig) och ISO/IEC TR 10000-1
[Referens 2]
— En profil kombinerar och väljer möjligheterna i flera grundstan-
darder för att uppfylla en specifikfunk tion för
informationsbehandling. För varje grundstandard finns det ett
PICS-dokument som listar standardens krav. En PRL omfattar
den undergrupp av grundstandardens element för PICS-dokumentsom är begränsade av profilen, tillsammans med de specifika
profilkraven. Den definierar de svar som krävs på grundstandar-
dens PICS-dokument för överensstämmelse med profilen.
Dessutom innehåller en PRL element av PICS-typ, som är speci-
fika för profilen (som minst finns det ett element som testar om
alla erforderliga PICS-dokument fyllts i korrekt). Dessa element
måste fyllas i tillsammans med grundstandardens PICS-dokument.
Dessa ifyllda proforma utgör tillsammans utlåtandet om profi-
limplementeringens överensstämmelse med standarden.
— Som följd av metodiken i ISO/IEC TR 10000-1 [Referens 2],
måste ett påstående om överensstämmelse med en profil stödjas
med PICS-dokument som ifyllts i överensstämmelse med PRL.
Användandet av detta material beror på förfarandet för anskaff-
ning av en FDE ICD-implementering.
— Ett flertal olika förfaranden för en FDE-implementering är
möjliga:
— Egen implementering av en nationell myndighet eller organi-
sation: PRL bör användas som grund för krav- och
acceptanstestspecifikationen för implementeringen, den ifyllda
ICS bör tas fram som del av acceptansförfarandet.
— Implementering av profilen av en entreprenör: materialet
kommer att användas och produceras som för en intern imple-
mentering, men entreprenören bör tillhandahålla ICS, och
behovet av detta måste vara ett kontraktskrav.
— Implementering utförd av en entreprenör som del av ett nyck-
elfärdigt system eller helhetskontrakt för system: materialet
kommer att användas och produceras som för en egen imple-
mentering, men entreprenören måste avkrävas att göra detta
internt samt att även tillhandahålla en ifylld ICS.
Överensstämmelse med profilen säkerställer exempelvis att
en leverantör som arbetar för två olika uppdragsgivare inte
kan införa egna protokoll för att uppfylla FDE-kraven, och
bidrar på så sätt till att ge uppdragsgivarna kontroll.
— Integrering av standardprodukter till en profilimplementering i
något av de föregående fallen: leverantören av en produkt
måste avkrävas att tillhandahålla de PICS-dokument som är
relevanta för produkten, kompletterade enligt den PRL som
beskrivits här, och garantier för att produkten uppfyller de2000R2082 — SV — 15.06.2002 — 001.001 — 188
▼B
berörda profilkraven. Detta PICS kan därefter vidarebefordras
som en del av profilens ICS.
— Efter implementeringen bör ICS behållas som en del av dokumen-
tationen för implementeringen. Den kan användas för att förutse
möjligheter till samverkan med andra myndigheter och organisa-
tioner, och för att identifiera förändringar som kan krävas vid
övergång till andra protokoll.
E.3. Beteckningar
E.3.1. Följande beteckningar från ISO/IEC TR 10000-1 [Referens 2]
används i ett PRL för att ange statusen på funktionerna:
m: obligatorisk
o: valfri-: ej tillämpligt (dvs. logiskt omöjligt inom profilens omfattning)x: utesluten
ANMÄRKNINGAR
1. Kombinationer av två tecken kan användas, där det första tecknet
hänvisar till den statiska (implementering) statusen, och den andra
till den dynamiska (användning), således innebär ”mo” obligato-
risk implementering, valfri användning.
2. Beteckningen ”o.>n<” används för att visa en uppsättning av
valfria möjligheter (dvs. minst en i uppsättningen måste vara
implementerad) med samma identifiering n.
3. En funktion markerad ”x” kan trots detta vara del av en imple-
mentering så länge den inte utnyttjas när implementeringen
används i överensstämmelse med profilen.
4. Användande av funktionen ”x” kräver bilateral överenskommelse.
I detta fall bör statusen på funktionerna ses över, då de kan vara
av intresse för andra implementeringar.
E.3.2. Följande beteckningar används för predikat:
>predicate<:: för en grupp med element där alla är villkorade för
>predicate< (gruppens omfattning visas genom arrangemanget).
>predicate<: för ett ensamt element som är villkorat för >predicate<.
ANMÄRKNING I varje individuellt fall, kan predikatet vara benäm-
ningen på en profilfunktion eller en boolesk
kombination av predikat (” ¬” är symbolen för
logisk negation).
E.3.3. Kraven i grundstandarden visas med motsvarande beteckningar med
versaler (dvs. M, O, O.>n<, X).
E.4. Instruktioner för att fylla i PICS-dokument
E.4.1. För att tillhandahålla ICS-profilen, skall PICS-dokument för de
grundstandarder till vilket det hänvisas vara kompletterade tillsam-
mans med ytterligare profilrelaterade PICS-element som
tillhandahålls i denna bilaga.
E.4.2. Där denna profil förfinar funktionerna i grundstandarden skall kraven
som framförs i denna PRL tillämpas (som indikeras i PRL-element
med en kolumn för ”Profilfunktioner”) för att begränsa antalet tillåtnasvar i PICS-dokument för grundstandarden.
E.4.3. Där denna profil ställer ytterligare krav skall svarskolumnen för
sådana element fyllas i. I denna kolumn skall varje svar antingen
väljas från den anvisade uppsättning svar, eller bestå av ett eller flera
parametervärden eller ett intervall av värden, enligt de uppställda
kraven.
E.4.4. Om ett obligatoriskt krav inte uppfylls måste undantagsinformation
tillhandahållas genom angivandet av en hänvisning X>i<, där >i< är
en unik beteckning på en bifogad förklaring till att överensstämmelse
inte uppnåtts.
ANMÄRKNING En möjlig orsak till ett sådant undantag är att
implementeringen integrerar fakta från en aktuell
felrapport rörande ett villkor i profilen, om felrap-
porten accepteras kommer implementeringen att
uppfylla standarden.2000R2082 — SV — 15.06.2002 — 001.001 — 189
▼B
E.5. Hänvisningar
E.5.1. För denna profil görs hänvisningar till följande protokollspecifika-
tioner:
— Protokoll för meddelandeöverföring (bilaga A till denna Eurocon-
trolstandard).
— Protokoll för meddelanderubriker (bilaga B till denna Eurocon-
trolstandard).
— Nätverksprotokoll för förbindelseläge som använder ISO/IEC
8208 ( till denna Eurocontrolstandard).
— ISO/IEC 7776 [Referens 6].
— Standarder för fysiska skikt, upprättade avi ITU-T Rekommenda-
tion X.25 (1993), klausul 1 [Referens 1].
E.5.2. Då det inte finns några uttryckliga PICS-dokument för de relevanta
standarderna för fysiska skikt, skall tillfälliga PICS-dokument för
fysiska skikt enligt ISO/IEC ISP 10609-9 klausul A.4 [Referens 8]
användas.
E.6. Utlåtande om överensstämmelse med standarden
E.6.1. Översikt
2000R2082 — SV — 15.06.2002 — 001.001 — 190
▼B
E.6.2. Dynamiska krav på överensstämmelse med standarden
E.7. Krav på övre skikt
Tabell 3
Protokoll för meddelandeöverföring
Funktioner i grundstandard Profilfunktioner
ElementProtokoll för meddelandeö-
verföringHänvisningar Status Hänvisningar Status
MTst — Statusmeddelanden A.4.2 O ox
MTor — Användarmedde-
landenA.4.2 O ox
E.8. Krav på lägre skikt
E.8.1. Krav på transportskikt
Tabell 4
Protokoll för meddelanderubriker
Funktioner i grundstandard Profilfunktioner
ElementProtokoll för meddelande-
rubrikerHänvisningar Status Hänvisningar Status
IHTx Användning av fälten
ADEST, DEST,
AEMM, EMM och
ADR med andra
värden än '40'HB.4.4 O ox
E.8.2. Krav på nätverksskikt
De PRL som redovisas i detta avsnitt utgår ifrån PICS-dokument för
ISO/IEC 8208:1993 [Referens 7]. Uppgifterna i kolumnen ”Hänvis-
ningar” under ”Funktioner i grundstandard” i följande tabeller är
hänvisningar till klausuler i den standarden.2000R2082 — SV — 15.06.2002 — 001.001 — 191
▼B
E.8.2.1. Allmän DTE-karaktäristik
Tabell 5
Allmän DTE-karaktäristik
Funktioner i grundstandard Profilfunktioner
Element Allmän DTE-karaktäristik Hänvisningar Status Hänvisningar Status
Tjänster som stöds:
Vs — virtuellt anrop O.1 m
Vp — permanent virtuell
kretsO.1 x
Miljöer som stöds: 3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2
Ec/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
uppgift som DTEO.2 6.3.2 o.2
Et/c — DTE/DTE i fast
uppgift som DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE med
dynamiskt val av
uppgift4.5 Vs: O.2 x
Numrering av paketse-
kvens stöds:
M8 — Modulo 8 13.2, 12.1.1,
Tabell 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Tabell 3O.3 x
Tilläggstjänst för
användare, för valfritt
tillägg av referens-nummer vid tilldelning
av alternativa logiska
kanaler:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
RNa — utan återgång till
användning av
logiska kanal-omfång13.29.2.1 Et:O
¬Et:Xx
RNb — med möjlig
återgång till
logiska kanal-
omfång13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Förfaranden, pakettyper och paketformat
Tabell 6
Paketskiktsfunktioner oberoende av logiska kanaler
Funktioner i grundstandard Profilfunktioner
ElementPaketskiktsfunktioner
oberoende av logiska
kanalerHänvisningar Status Hänvisningar Status
Stöds följande pakets-
kiktsfunktioner:
Z2s sändning av diagno-
stikpaket12.7, Tabell 24 Et:O
¬Et:Xx2000R2082 — SV — 15.06.2002 — 001.001 — 192
▼B
Funktioner i grundstandard Profilfunktioner
ElementPaketskiktsfunktioner
oberoende av logiska
kanalerHänvisningar Status Hänvisningar Status
Z4i Initiering av direktans-
luten registrering av
tjänst:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— sänd REGISTRA-
TION REQUEST12.9.1
— ta emot REGIST-
RATION CONFIR-
MATION12.9.2, Tabell
10
Z4r Svar på direktansluten
registrering av tjänst:13.1, 13.1.1.1,
13.1.1.4Et:O –
— ta emot REGIST-
RATION REQUEST12.9.1
— sänd REGISTRA-
TION CONFIRMA-
TION12.9.2, Tabell
10
Tabell 7
Upprätta kommunikation
Funktioner i grundstandard Profilfunktioner
Element Upprätta kommunikation Hänvisningar Status Hänvisningar Status
Stöds utgående virtuell
kommunikation:5.2.1, 5.2.5,
Tabell 33
S1a — Snabbval, inga
begränsningar av svar?5.2.4, 13.16 O x
S1b — Snabbval, med
begränsat svar?13.16 O x
S1c — Inget Snabbval? 5.2.4 O m
SP1b CALL REQUEST,
grundformat12.2.3.1 S1c:M
S1ab: O.4m
SP1e Sänd CALL
REQUEST, utökat
format12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b Ta emot CALL
CONNECTED, grund-
format12.2.4.1 S1ac:M m
SP2e Ta emot CALL
CONNECTED, utökat
format12.2.4.1,
12.2.4.2S1a:M –
Stöds alternativ adres-
sering för utgående
virtuell kommunika-
tion:13.28
— med A = 1 och
utökat adressblock-
format?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— med funktionen för
utökning av anropad
adress?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Stöds inkommande
virtuell kommunika-
tion:5.2.2, 5.2.5,
Tabell 33
S2a — snabbval där godta-
gande är möjligt?5.2.3, 13.17 O –
S2b — snabbval, alltid
frånkopplad?13.17 O m2000R2082 — SV — 15.06.2002 — 001.001 — 193
▼B
Funktioner i grundstandard Profilfunktioner
Element Upprätta kommunikation Hänvisningar Status Hänvisningar Status
S2c — icke snabbval där
godtagande är möjligt?5.2.3 O m
S2d — icke snabbval, alltid
frånkopplad?5.2.3 O x
SP3b ta emot INCOMING
CALL, grundformat12.2.3.1 S2:M m
SP3e ta emot INCOMING
CALL, utökat format12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b sänd CALL
ACCEPTED, grund-
format12.2.4.1 S2c:M
S2axc:
O.5m
SP4e sänd CALL
ACCEPTED, utökat
format12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
Stöds förhandling av
D-bit:
DN1 — för utgående
virtuell kommunikation6.3 S1ac:O m
DN2 — för inkommande
virtuell kommunikation6.3 S1ac:O m
ANMÄRKNING D-biten skall alltid förhandlas till 0.
Tabell 8
Avsluta kommunikation
Funktioner i grundstandard Profilfunktioner
Element Avsluta kommunikation Hänvisningar Status Hänvisningar Status
Stöds nedkoppling av
kommunikation för att:5.5.4, Tabell 33
C1 — svara på anvisning
om nedkoppling5.5.2 O m
C2a — avbryta ett försök
till utgående virtuell
kommunikation?5.4, 5.5.1, 5.5.3 S1:O o
C2b — avvisa inkommande
virtuell kommunika-
tion?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd:
Om
C2c — Inleda nedkoppling
av en upprättad virtuell
förbindelse?5.5.1, 5.5.3 O o
CP1b ta emot CLEAR INDI-
CATION, grundformat12.2.5.1 Cany:M m
CP1e ta emot CLEAR INDI-
CATION, utökat
format12.2.5.1,
12.2.5.2Cany:M –
CP2b sänd CLEAR
CONFIRMATION,
grundformat12.2.6.1 C1:M m
CP2e sänd CLEAR
CONFIRMATION,
utökat format12.2.6.1,
12.2.6.2C1rn:M x
CP3b sänd CLEAR
REQUEST, grund-
format12.2.5.1 C2a:M
C2bcxa:
O.6m2000R2082 — SV — 15.06.2002 — 001.001 — 194
▼B
Funktioner i grundstandard Profilfunktioner
Element Avsluta kommunikation Hänvisningar Status Hänvisningar Status
CP3e sänd CLEAR
REQUEST, utökat
format12.2.5.1 ,
12.2.5.2C2bcxa:
O.6
C2axbc:
Xx
CP4b ta emot CLEAR
CONFIRMATION,
grundformat12.2.6.1 C2:M m
CP4e ta emot CLEAR
CONFIRMATION,
utökat format12.2.6.1,
12.2.6.2C2rnci:M –
Tabell 9
Återställning av logiska kanaler
Funktioner i grundstandard Profilfunktioner
ElementÅterställning av logiska
kanalerHänvisningar Status Hänvisningar Status
Stöds återställning: 8, 8.4, Tabell 34
RSi — som initiativtagare? 8.1, 8.3 O mm
sänd RESET
REQUEST12.5.1
ta emot RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.1
RSr — som besvarare? 8.2 O mm
ta emot RESET INDI-
CATION12.5.1
sänd RESET CONFIR-
MATION12.5.2
Tabell 10
Förfaranden vid fel
Funktioner i grundstandard Profilfunktioner
ElementFörfaranden vid fel
(Virtuell uppkoppling)Hänvisningar Status Hänvisningar Status
Är förfarandet för
ERROR-C:5.2.1, 5.4, 8.1,
Tabell 33
W1a — nedkoppling av den
virtuella anslutningen?O.7 m
W1b — starta om pakets-
kiktet?O.7 x
Är förfarandet för
ERROR-R för virtuell
kommunikation: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 — starta om pakets-
kiktet?O.8 x2000R2082 — SV — 15.06.2002 — 001.001 — 195
▼B
Tabell 11
Avbrottsöverföring
Funktioner i grundstandard Profilfunktioner
Element Avbrottsöverföring Hänvisningar Status Hänvisningar Status
Is Stöds sändning av
avbrott?6.8, 6.8.1, 6.8.3,
Tabell 35Oo x
— sänd INTERRUPT
REQUEST12.3.2
ta emot INTERRUPT
CONFIRMATION12.3.3
Ir Stöds mottagning av
avbrott?6.8, 6.8.2, 6.8.3,
Tabell 35O–
— ta emot INTER-
RUPT INDICATION12.3.2
— sänd INTERRUPT
CONFIRMATION12.3.3
Tabell 12
Sändning av data
Funktioner i grundstandard Profilfunktioner
Element Sändning av data Hänvisningar Status Hänvisningar Status
DS1 Stöds sändning av
DATA-paket?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Stöds följande:
DS2 — rotation av
sändfönster vid
mottagning av uppda-
terade P(R)-värden?7.1, 7.1.2, 7.1.3 O mm
DS4a — sändning av M = 0
i DATA-paket?6.4, 6.5, 6.7 M mo.9
DS4b — sändning av M = 1
i DATA-paket?6.4, 6.5, 6.7 O mo.9
DS5a — sändning av Q = 0 i
DATA-paket?6.6 O.10 mm
DS5b — sändning av Q = 1 i
DATA-paket?6.6 O.10 ox
DS6 — svar på begäran om
omsändning av paket
(mottagna REJECT-
paket)?13.4.2 12.8 Et:O –
— Förfarande för tids-
kontroll av fönsterrota-
tion:
DS7a — åtgärd ERROR-R
vid överskridande11.2.1(a) O ox
DS7b — omsändning av
paket vid överskri-
dande11.2.1(b) Et:O
¬Et:Xox
DS8 — kassering av för
långa flödeskontrol-
lpaket (istället för
ERROR-R)?Tabell 36
Anmärkning 2Oo x2000R2082 — SV — 15.06.2002 — 001.001 — 196
▼B
Tabell 13
Datamottagning
Funktioner i grundstandard Profilfunktioner
Element Datamottagning Hänvisningar Status Hänvisningar Status
DR1 Stöds mottagning av
DATA-paket?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Stöds följande:
DR2 — rotation av mottag-
ningsfönster genom
sändning av uppdate-
rade P(R)-värden?7.1.2, 7.1.3 O mm
DR3 — flödeskontroll
genom sändning av
RECEIVE NOT
READY och
RECEIVE READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — mottagning av M
= 1 i DATA-paket?6.4, 6.5, 6.7 O mm
DR5a —mottagning av Q= 0
i DATA-paket?6.6 O.11 mm
DR5b —mottagning av Q= 1
i DATA-paket?6.6 O.11 –
DR6 — begäran om
omsändning av paketet
genom sändande av
REJECT-paket?13.4.1, 12.8 O ox
— återhämtning från
mottagande av DATA-
paket innehållande
ogiltig P(S), genom:
DR7a — åtgärd ERROR-R? 11.3(a) O.12 mmDR7b — begäran om
omsändning av
paketet?11.3(b) O.12 ox
DR7c — ignorerande av
paketet och väntan på
ett korrekt, omsänt
paket?11.3(c) O.12 ox
— återhämtning från
mottagande av DATA-
paket med ogiltigt fält
för användardata
genom:
DR8a — åtgärd ERROR-R? 11.3(a) O.13 mmDR8b — begäran om
omsändning av
paketet?11.3(b) O.13 ox
DR8c — ignorerande av
paketet och väntan på
ett korrekt, omsänt
paket?11.3(c) O.13 ox
DR9 — förfarande för tids-
kontroll av sändning
av fönsterstatus?11.2.2 O ox2000R2082 — SV — 15.06.2002 — 001.001 — 197
▼B
Tabell 14
Leveransbekräftelse
Funktioner i grundstandard Profilfunktioner
Element Leveransbekräftelse Hänvisningar Status Hänvisningar Status
DC Stöds leveransbe-
kräftelse?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Blandade funktioner och valmöjligheter
Tabell 15
Värden på orsaker och diagnostiska koder
Funktioner i grundstandard Profilfunktioner
ElementVärden på orsaker och
diagnostiska koderHänvisningar Status Hänvisningar Status
I skickade RESTART
REQUEST-paket:12.6.1.1,
12.6.1.2,
Tabeller 24-25
Y1d — Orsak= 128,
privata diagnostikkoderO.14 ox
I mottagna RESTART
INDICATION-paket:12.6.1.1, Tabell
9, 12.6.1.2
Y2b — Orsakinte 0 eller
128, vilket diagnostiskt
kodvärde som helstEC:M
¬EC:Om
I skickade CLEAR
REQUEST-paketet:12.2.3.1.1,
12.2.3.1.2,
Tabeller 24-25
Y3d — Orsak= 128,
privata diagnostikkoderO.15 ox
I mottagna CLEAR
INDICATION-paket:12.2.3.1.1,
Tabell 7,
12.2.3.1.2,
Y4b — Orsakinte 0 eller
128, vilket diagnostiskt
kodvärde som helstEC:M
¬EC:Om
I skickade RESET
REQUEST-paket:12.5.1.1,
12.5.1.2,
Tabeller 24-25
Y5d — Orsak= 128,
privata diagnostikkoderO.16 ox
I mottagna RESET
INDICATION-paket:12.5.1.1, Tabell
8, 12.5.1.2
Y6b — Orsakinte 0 eller
128, vilket diagnostiskt
kodvärde som helstEC:M
¬EC:Om
E.8.2.4. Funktioner
Tabell 16
Funktioner som skickas i CALL REQUEST-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner som skickas i
CALL REQUEST-paketHänvisningar Status Hänvisningar Status
FS1pi Förhandling av flödes-
kontrollparameter,
paketstorlek13.12, 15.2.2.1.1 O x2000R2082 — SV — 15.06.2002 — 001.001 — 198
▼B
Funktioner i grundstandard Profilfunktioner
ElementFunktioner som skickas i
CALL REQUEST-paketHänvisningar Status Hänvisningar Status
FS1wi Förhandling av flödes-
kontrollparameter,
fönsterstorlek13.12, 15.2.2.1.2 O x
FS2ib Förhandling om grund-
läggande kapacitets-
klass13.13,
15.2.2.2.1,
Tabell 20aOx
FS2ie Förhandling om utökad
kapacitetsklass13.13,
15.2.2.2.2,
Tabell 20bOx
FS3b Val i sluten användar-
grupp, grundläggande
format13.14.6,
15.2.2.3.1Oo
FS3e Val i sluten användar-
grupp, utökat format13.14.6,
15.2.2.3.2Ox
FS4b Val i sluten användar-
grupp med val av
utgång, grundformat13.14.7,
15.2.2.4.1Ox
FS4e Val i sluten användar-
grupp med val av
utgång, utökat format13.14.7,
15.2.2.4.2Ox
FS5 Val i bilateralt sluten
användargrupp13.15, 15.2.2.5 O x
FS6a Snabbval 13.16, 15.2.2.6 O x
FS6b Omvänd debitering 13.18, 15.2.2.6 O xFS6c Val av ICRD-status 13.25.4.2,
15.2.2.6Ox
FS7i Nätverksanvändar-ID 13.21, 13.21.3,
15.2.2.7Ox
FS8i Debiteringsinforma-
tion, begäran om tjänst13.22, 15.2.2.8.1 O x
FS9b RPOA-val, grund-
format13.23, 13.23.2,
15.2.2.9.1Ox
FS9e RPOA-val, utökat
format13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Val och indikering av
försenad överföring13.27, 15.2.2.13 O x
FS99i Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FS98i Fjärrbaserade icke
X.25-funktioner, efter
funktionsmarkör15.1, Tabell 18 O x
FS20i Funktionsmarkör,
CCITT-specifierade
DTE-funktioner15.1 O x
FS21i Tillägg för anropande
adress14.1, 15.3.2.1 x
FS22i Tillägg för anropad
adress14.2, 15.3.2.2 x
FS23ib Förhandling om mini-
mikapacitetsklass,
grundformat14.3, 15.3.2.3.1,
Tabell 20aOx
FS23ie Förhandling om mini-
mikapacitetsklass,
utökat format14.3, 15.3.2.3.2,
Tabell 20bO
FS24i Förhandling om förse-
ning från slutnod till
slutnod14.4, 15.3.2.4 O x2000R2082 — SV — 15.06.2002 — 001.001 — 199
▼B
Funktioner i grundstandard Profilfunktioner
ElementFunktioner som skickas i
CALL REQUEST-paketHänvisningar Status Hänvisningar Status
FS25i Förhandling om
påskyndning av data14.7, 15.3.2.7 O x
FS26i Prioritet 14.5, 15.3.2.5 O x
FS27i Skydd 14.6, 15.3.2.6 O x
Tabell 17
Funktioner som skickas i CALL ACCEPT-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner som skickas i
CALL ACCEPT-paketHänvisningar Status Hänvisningar Status
FS1pr Förhandling om
flödeskontrollpara-
metrar, paketstorlek13.12,
15.2.2.1.1,
Tabell 13Ox
FS1wr Förhandling om
flödeskontrollpara-
metrar, fönsterstorlek13.12,
15.2.2.1.2,
Tabell 13Ox
FS2rb Förhandling om grund-
läggande kapacitets-
klass13.13,
15.2.2.2.1,
Tabell 20aOx
FS2re Förhandling om utökad
kapacitetsklass13.13,
15.2.2.2.2,
Tabell 20bOx
FS7r Nätverksanvändar-ID 13.21, 13.21.3
15.2.2.7Ox
FS8r Debiteringsinforma-
tion, begäran om tjänst13.22, 15.2.2.8.1 O x
FS10r Anvisning om ändrad
anropad linjeadress13.26, 15.2.2.12 O x
FS99r Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FS98r Fjärrbaserade icke
X.25-funktioner, efter
funktionsmarkör15.1, Tabell 18 O x
FS20r Funktionsmarkör,
CCITT-specificerade
DTE-funktioner15.1 O x
FS22r Tillägg för anropad
adress14.2, 15.3.2.2 O x
FS24r Förhandling om förse-
ning slutnod-till-
slutnod14.4, 15.3.2.4 O x
FS25r Förhandling om
påskyndning av data14.7, 15.3.2.7 O x
FS26r Prioritet 14.5, 15.3.2.5 O x
FS27r Skydd 14.6, 15.3.2.6 O x2000R2082 — SV — 15.06.2002 — 001.001 — 200
▼B
Tabell 18
Funktioner skickade i CLEAR REQUEST-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner skickade i
CLEAR REQUEST-paketHänvisningar Status Hänvisningar Status
FS10d Anvisning om ändrad
anropad linjeadress13.26, 15.2.2.12 O x
FS13 Val av omdirigering av
anrop13.25.2.2,
15.2.2.10Ox
FS99d Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FS98d Fjärrbaserade icke
X.25-funktioner, efter
funktionsmarkör15.1, Tabell 18 O x
FS20d Funktionsmarkör,
CCITT-specificerade
DTE-funktioner15.1 O x
FS22d Tillägg för anropad
adress14.2, 15.3.2.2 O x
Tabell 19
Funktioner mottagna i INCOMING CALL-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
INCOMING CALL-paketHänvisningar Status Hänvisningar Status
FR1pi Förhandling om
flödeskontrollpara-
metrar, paketstorlek13.12, 15.2.2.1.1 O x
FR1wi Förhandling om
flödeskontrollpara-
metrar, fönsterstorlek13.12, 15.2.2.1.2 O x
FR2ib Förhandling om grund-
läggande kapacitets-
klass13.13, 15.2.2.2.1
Tabell 20aOx
FR2ie Förhandling om utökad
kapacitetsklass13.13,
15.2.2.2.2,
Tabell 20bOx
FR3b Val i sluten användar-
grupp, grundformat13.14.6,
15.2.2.3.1Oo
FR3e Val i sluten användar-
grupp, utökat format13.14.6,
15.2.2.3.2Ox
FR4b Val i sluten användar-
grupp med tillträde till
utgång, grundformat13.4.7,
15.2.2.4.1Ox
FR4e Val i sluten användar-
grupp med tillträde till
utgång, utökat format13.4.7,
15.2.2.4.2Ox
FR5 Val i bilateralt sluten
användargrupp13.15, 15.2.2.5 O x
FR6a Snabbval 13.16, 13.17,
15.2.2.6Ox
FR6b Omvänd debitering 13.18, 13.19,
15.2.2.6Ox
FR11 Omdirigering av anrop
eller indikering om
anropsavvikelse13.25.3,
15.2.2.11Ox
FR12i Val och anvisning av
försenad överföring13.27, 15.2.2.13 O x2000R2082 — SV — 15.06.2002 — 001.001 — 201
▼B
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
INCOMING CALL-paketHänvisningar Status Hänvisningar Status
FR99i Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FR20i Funktionsmarkör,
CCITT-specifierade
DTE-funktioner15.1 O x
FR21 Tillägg för anropande
adress14.1, 15.3.2.1 x
FR22i Tillägg för anropad
adress14.2, 15.3.2.2 x
FR23b Förhandling om mini-
mikapacitetsklass,
grundformat14.3, 15.3.2.3.1,
Tabell 20aOx
FR23e Förhandling om mini-
mikapacitetsklass,
utökat format14.3, 15.3.2.3.2,
Tabell 20bOx
FR24i Förhandling om förse-
ning slutnod-till-slutnot14.4, 15.3.2.4 O x
FR25i Förhandling om
påskyndning av data14.7, 15.3.2.7 O x
FR26i Prioritet 14.5, 15.3.2.5 O x
FR27i Skydd 14.6, 15.3.2.6 O x
Tabell 20
Funktioner mottagna i CALL CONNECTED-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
CALL CONNECTED-paketHänvisningar Status Hänvisningar Status
FR1pr Förhandling om
flödeskontrollpara-
metrar, paketstorlek13.12,
15.2.2.1.1,
Tabell 14Ox
FR1wr Förhandling om
flödeskontrollpara-
metrar, fönsterstorlek13.12,
15.2.2.1.2,
Tabell 14Ox
FR2rb Förhandling om grund-
läggande kapacitets-
klass13.13,
15.2.2.2.1,
Tabell 20aOx
FR2re Förhandling om utökad
kapacitetsklass13.13, 15.2.2.2.2
Tabell 20bOx
FR10r Anvisning om ändrad
anropad linjeadress13.26, 15.2.2.12 O x
FR12r Val och anvisning av
försenad överföring13.27, 15.2.2.13 O x
FR99r Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FR20r Funktionsmarkör,
CCITT-specificerade
DTE-funktioner15.1 O x
FR22r Tillägg för anropad
adress14.2, 15.3.2.2 O x
FR24r Förhandling om förse-
ning av slutnod-till-
slutnod14.4, 15.3.2.4 O x
FR25r Förhandling om
påskyndning av data14.7, 15.3.2.7 O x2000R2082 — SV — 15.06.2002 — 001.001 — 202
▼B
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
CALL CONNECTED-paketHänvisningar Status Hänvisningar Status
FR26r Prioritet 14.5, 15.3.2.5 O x
FR27r Skydd 14.6, 15.3.2.6 O x
Tabell 21
Funktioner mottagna i CLEAR INDICATION-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
CLEAR INDICATION-
paketHänvisningar Status Hänvisningar Status
FR8ad Debiteringsinforma-
tion, valutaenhet13.22, 15.2.2.8.2 O x
FR8bd Debiteringsinforma-
tion, antal segment13.22, 15.2.2.8.3 O x
FR8cd Debiteringsinforma-
tion, uppkopplingstid13.22, 15.2.2.8.4 O x
FR10d Anvisning om ändrad
anropad linjeadress13.26, 15.2.2.12 O x
FR99d Lokala icke X.25-
funktioner, efter funk-
tionsmarkör15.1, Tabell 18 O x
FR20d Funktionsmarkör, ITU-
T-specificerade DTE-funktioner15.1 O x
FR22d Tillägg för anropad
adress14.2, 15.3.2.2 O x
Tabell 22
Funktioner mottagna i CLEAR CONFIRMATION-paket
Funktioner i grundstandard Profilfunktioner
ElementFunktioner mottagna i
CLEAR CONFIRMA-
TION-paketHänvisningar Status Hänvisningar Status
FR8af Debiteringsinforma-
tion, valutaenhet13.22, 15.2.2.8.2 O x
FR8bf Debiteringsinforma-
tion, antal segment13.22, 15.2.2.8.3 O x
FR8cf Debiteringsinforma-
tion, uppkopplingstid13.22, 15.2.2.8.4 O x
E.8.2.5. Värden och omfång för parametrar
Tabell 23
Värden och omfång för parametrar
Funktioner i grundstandard Profilfunktioner
ElementVärden och omfång för
parametrarHänvisningar Status Hänvisningar Status
Vilka värden stöds:2000R2082 — SV — 15.06.2002 — 001.001 — 203
▼B
Funktioner i grundstandard Profilfunktioner
ElementVärden och omfång för
parametrarHänvisningar Status Hänvisningar Status
V1s — förvalda värden på
paketstorlekar
(sändande)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096okte-
tter6.3.2 Minst
128
och
256
V1r — förvalda värden på
paketstorlekar (motta-
gande)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096okte-
tter6.3.2 Minst
128
och
256
V2s — förvalda värden på
fönsterstorlekar,
sändande?16.2.2.6 ( M8:
inom
spannet
1–7)2
V2r — förvalda värden på
fönsterstorlekar, motta-
gande?16.2.2.6 ( M8:
inom
spannet
1–7)2
E.8.3. Krav på datalänkskikt
De PRL som redovisas i detta avsnitt grundar sig på PICS-dokument
för ISO/IEC 7776:1994 [Referens 6]. Uppgifterna i kolumnen
”Hänvisningar” under ”Funktioner i grundstandard” i följande tabeller
är hänvisningar till klausuler i den standarden.
Tabell 24
Datalänkprotokoll
Funktioner i grundstandard Profilfunktioner
Element Datalänkprotokoll Hänvisningar Status Hänvisningar Status
Lm Multilänkförfarande 6 O ox
Lc DTE/DCE 1, 5.1 M mo.1
Lt DTE/DTE 1, 5.1 O mo.1
M8 Grundläge (Modulo 8) 1, 3, 4.1.1 O.1 mm
M128 Utökat läge (Modulo
128)1, 3, 4.1.1 O.1 ox
T4 Förfarande för Timer
T45.3.2, 5.6.1 O mm
SPN1 Maximalt antal (N1)
bitar i en I-ram5.7.3 N1 ≥
1 080N1≥
2 104
SPkMaximalt antal
utstående ramar (k)5.7.4 1 ≤k≤
7k=7
E.8.4. Krav på fysiska skikt
Se ISO/IEC TR 10609-9 klausul A.4 [Referens 8].2000R2082 — SV — 15.06.2002 — 001.001 — 204
▼B
BILAGA F (Informativ)
METODIK FÖR TEST AV ÖVERENSSTÄMMELSE MED STAN-
DARDEN
F.1. Inledning
F.1.1. Det är viktigt att implementeringar av detta ICD är sådana att det
finns en hög förtroendenivå för samverkan mellan centraler för flyg-
kontrolltjänst (ATCC) som arbetar gemensamt över gränssnittet.
F.1.2. Implementering av gränssnittet genomförs av medlemsstater på ett
sätt som troligen leder till anskaffning av utrustning från olika källor.
För att uppnå en hög förtroendenivå för att sådana implementeringar
skall fungera tillsammans, krävs en gemensam uppsättning krav på
test av om standarden uppfylls för att standardisera förberedelser för
tester, tester samt presentation av resultat.
F.2. Syfte och omfattning
F.2.1. I denna bilaga definieras kraven på tester som andvänds för att
kontrollera om en implementering uppfyller denna Eurocontrolstan-
dard, av vilken denna bilaga är en del.
F.2.2. Den identifierar mekanismer varigenom förtroende för ett redovisat
gränssnittet fastställs genom ett testförfarande som validerar
överensstämmelse med standarden.
F.3. Litteraturförteckning
Följande dokument är relevant för implementeringstesterna av denna
Eurocontrolstandard:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD del 1, Testplan för integration, Version 1.0, daterad10 maj 1996.
F.4. Utvecklingsmetoder och tillämpningar
F.4.1. Implementeringar av ett ICD kan påverkas genom att man använder
vissa valmöjligheter i, och versioner av ett ICD. För att fastställa
möjligheten till samverkan, måste en medlemsstat som implementerar
gränssnittet, genom ett definierat utlåtande, identifiera vilka delar av
ett ICD som stöds beträffande funktion, och vilka eventuella begräns-
ningar av variabla parametrar som stöds.
F.4.2. För alla implementeringar skall test av överensstämmelse med denna
standard utföras enligt nedanstående beskrivning.
F.5. Tester
F.5.1. Inledning
F.5.1.1. För att kunna tillföra förtroende och stöd för FDE-gränssnitt inom en
ATCC till samverkan mellan samarbetande FDE-tillämpningar, är det
önskvärt att var och en testas för överensstämmelse med de stan-
darder av vilka denna bilaga utgör en del. Sådan test sker för den
externa funktionen i systemet under test (SUT), och är ämnat att testa
samverkan snarare än slutsystemets användbarhet.
F.5.1.2. Resultatet av sådana tester kan användas som underlag för att stödja
anspråkpå överensstämmelse med standarden gjorda enligt avsnitt i
den här delen av denna Eurocontrolstandard. De PICS-dokument och
PRL som anges i den här profilspecifikationen kan användas som
grund för test av överensstämmelse med standarden. I tillägg kan
internationella standarder (t.ex. ISO/IEC 8208 ) redan ha abstrakta
testuppsättningar definierade som kan användas för sådana test.
F.5.1.3. Syftet med detta dokument är att tillhandahålla ett standardiserat test-
program som förlitar sig på en standardiserad testuppsättning, vars
användning bör leda till möjligheten att jämföra testresultat, utbrett
antagande av sådana testresultat och en minimering av behovet för
test av överensstämmelsen med standarden. Den standardiserade test-
sviten har delvis utvecklats av Eurocontrol.
F.5.1.4. Baserat på figur 2, består testen av det kompletta slutsystemet av
tester av de tre lägre skikten. Det är tillrådlig att inkludera tester av
FDE-tillämpningarna status-, system- and användarmeddelanden.2000R2082 — SV — 15.06.2002 — 001.001 — 205
▼B
F.5.1.5. Varje test som beskrivs nedan bör ske i följdordning. De senare
testerna kan bara lyckas om de lägre skikten fungerar korrekt, och
det är troligt att detta fastställs genom de tidigare testerna.
F.5.1.6. Ovanstående till trots, är testningen beskriven i detta avsnitt frivillig.
F.5.2. Test av de lägre skikten (Skikt 1–3)
Som stöd för kravet på samverkan mellan alla ATCC, rekommenderas
det att all testning skall baseras på användningen av testplanen i
Eurocontrols (Maastricht UAC Systems Division) FDE ICD Testplan
för integrering. Testförfaranden skall vara bilateralt överenskomna
mellan samarbetande ATCC.
F.5.3. Test av tillämpningsskiktet
En serie av bilateralt överenskomna tester bör utföras mellan samar-
betande ATCC.
F.5.4. Certifiering
Resultaten av testerna bör registreras och accepteras av de samarbe-
tande parterna.
F.5.5. Anvisning
Medlemsstaterna bör vidarebefordra resultatinformationen från alla
tester till Eurocontrol.2000R2082 — SV — 15.06.2002 — 001.001 — 206
▼B
BILAGA G (Informativ)
TILLDELNING AV IDENTITETER PÅ ATC-ENHETER
I nedanstående tabell redovisas de beteckningar som tilldelats ATC-enheter fram
till 22 april 1997. Eurocontrol kan tillhandahålla information om den aktuella
tilldelningen av identiteter. I tabellen redovisas även, med hexadecimala siffror,
den binära kodningen av beteckningarna som del av den kodning av NSAP-
adresser som definieras i Bilaga C.
Tabell 1
Beteckningar för ATC-enheter
Beteckning för ATC-
enhetKodbeteckning Beskrivning
00 Reserverad
01 '01'H CATCAS, Köpenhamn
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Bryssel
05 '05'H Allmänt CAUTRA, Frankrike
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 (framtida tyskt system)
12 '12'H FATMI-system, Tammerfors13 '13'H ROVA-system, Rovaniemi
14 '14'H VAS, Wien
15 '15'H CFMU Haren
16 '16'H CFMU Bretagne
17 '17'H Geneve ACC/FMP
18 '18'H Zurich 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ö-Sturup34 '34'H Sundsvall
35 '35'H Lissabon
36 '36'H Sevilla
37 '37'H Gran Canaria2000R2082 — SV — 15.06.2002 — 001.001 — 207
▼B
Beteckning för ATC-
enhetKodbeteckning Beskrivning
38 '38'H Prag
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Tyskt militärt system
42 '42'H Tyskt militärt system43 '43'H Tyskt militärt system
44 '44'H Tyskt militärt system
45 '45'H Tyskt militärt system
46 '46'H Tyskt militärt system
47 '47'H Tyskt militärt system
48 '48'H Tyskt militärt system
49 '49'H Tyskt militärt system
50 '50'H Munchen (Framtida tyskt system)
51 '51'H Zagreb
52 '52'H Hahn Airport, Tyskland
53 '53'H Santa Maria FIR
54 '54'H Ljubljana
55 '55'H Belgiskt militärt system
56 '56'H Budapest
57 '57'H Warsawa2000R2082 — SV — 15.06.2002 — 001.001 — 208
▼B
BILAGA H (Informativ)
RIKTLINJER FÖR TILLFÖRLITLIGHET, TILLGÄNGLIGHET OCH
SÄKERHET
H.1. Inledning
Det förväntas att ATC-tillämpningar, såsom OLDI, skall utnyttja
sammankopplade X.25-nätverk och/eller offentliga eller privata tele-
kommunikationstjänster. Som ett resultat av detta har det bedömts
nödvändigt att tillhandahålla riktlinjer för FDE ICD, del 1 implemen-
teringar.
H.2. Syfte och omfattning
H.2.1. Syftet med denna bilaga är att ge riktlinjer för frågor rörande till-
förlitlighet, tillgänglighet och säkerhet.
H.2.2. Omfattningen av denna bilaga baseras på två scenarion. Det första
scenariot är en direktansluten förbindelse över hyrd linje. Det andra
scenariot baseras på ett sammankopplad nätverk i en X.25-nätverks-
miljö.
ANMÄRKNING För det andra scenariot har frågor som berör
sammankopplingen av X.25-nätverket inte vägts in.
H.2.3. Det är säkerställt att implementeringarna är fysiskt skyddade mot
intrång, strömavbrott och andra externa hot som kan påverka normal
drift.
H.3. Litteraturförteckning
Dokumentet nedan är en detaljerad teknisk analys av vilken denna
bilaga är en översikt:
Eurocontrol FDE ICD del 1: Tillförlitlighet, tillgänglighet och
säkerhet — Teknisk rapport [Referens 16].
H.4. Implementering av hyrda linjer
H.4.1. Tillförlitlighet
För att förbättra driftens tillförlitlighet, måste kablarna för hyrda
linjer, PSTN och ISDN (digitalt flertjänstnät) vara dragna på ett
sådant sätt att de är fysiskt skilda från varandra. De måste också
anslutas till olika växlar hos telekommunikationsbolagen (detta
måste specificeras till telekommunikationsbolaget).
H.4.2. Tillgänglighet
H.4.2.1. P .g.a. långa uppkopplingstider för PSTN, som är oförenliga med
tidsbegränsade tillämpningar, bör ISDN användas som reservmedium.
H.4.2.2. Vid händelse av DTE-byte skall den DTE som befinner sig i standby
generera en DISC-ram för att snabba upp återupprättandet av anslut-
ningen.
H.4.3. Säkerhet
H.4.3.1. När ISDN används som ett reservmedium, bör den anropade ISDN-
terminaladaptern (TA) validera anroparens E.164-adress
[Referens 18].
H.4.3.2. Anropande DTE bör uppfylla ITU-T:s rekommendation X.32
[Referens 17] genom att inkludera sin identitet och autenticitetsinfor-
mation.2000R2082 — SV — 15.06.2002 — 001.001 — 209
▼B
H.4.4. Exempel på utformning
Figur H.1
Exempel på utformning med hyrd linje
H.5. Nätverksimplementering
H.5.1. Tillförlitlighet
För att öka tillförlitligheten skall värdar på en given plats uppkopplas
till två DCE som tillhör olika nätverksväxlar (detta krav skall vara
specificerat till nätverksoperatören).
H.5.2. Tillgänglighet
H.5.2.1. Kommunikationsanläggningen (hunt group) skall användas för att
kunna tilldela en enda X.121-adress [Referens 20] till de DCE som
är belägna på en given plats. På så sätt optimeras transporterna på
nätverket och antalet misslyckade anrop begränsas.
H.5.2.2. Om andra kommunikationsmekanismer finns implementerade, som
resulterar i ett annat värde på anropad DTE-adress i CALL
REQUEST- och CALL ACCEPT-paketet, så skall anropande DTE
konfigureras så att det inte har någon inverkan på uppkopplingen av
anropet.
H.5.2.3. Om ett nätverksfel orsakar en DCE-frånkoppling, och en andra
anslutningsmöjlighet finns till nätverket, skall återupprättande av
kommunikationen ske via den andra adressen.
H.5.3. Säkerhet
Inom ramarna för denna bilaga, är tjänsten för sluten användargrupp
(CUG) den enda tillämpliga nätverksfunktion som skall användas.
H.6. Allmänna riktlinjer för hyrd linje och nätverksimplementeringar
H.6.1. Tillförlitlighet
H.6.1.1. Då en komplett omkoppling mellan värdsystemen kan ta tid, är det
fördelaktigt att överväga användandet av en front-end processor
(FEP) för att vara behjälplig vid avbrott i värdsystemet.
H.6.1.2. En struktur baserad på en FEP kan öka tjänsternas tillförlitlighet.
ANMÄRKNING Inkluderandet av en transportstack i profilspecifika-
tionen kan komma att ske i samband med en
framtida FDE ICD, del 2 -standard.
H.6.2. Tillgänglighet
När ett anrop misslyckas skall den anropande platsen göra ett andra
anrop med användning av den andra X.121-adressen (om sådan
finns).2000R2082 — SV — 15.06.2002 — 001.001 — 210
▼B
H.6.3. Systemhantering
H.6.3.1. Användningen av växlar, som automatiskt slår om genom avsökning
av gränssnittssignalerna, bör användas där så är möjligt.
H.6.3.2. En lokal felindikering under dataöverföring kan användas för att
utlösa en omkoppling mellan värdsystemen.
H.6.3.3. Omkopplingen av en FEP bör generera en TC-disconnect för att
säkerställa att det lokala värdsystemet befinner sig i tillståndet IDLE.
H.6.3.4. När tidsbegränsningarna för X.25-nätverket eller datalänkskikten
löper ut, bör det högre skiktet kopplas ner.
H.6.3.5. Ett totalt FEP-haveri bör generera en TC-disconnect.H.6.3.6. Övervakningssystemet bör undersöka protokollskiktet för meddelan-
deöverföring (bilaga A) och kontrollera tillståndsmaskinen för att
skilja mellan ett fel i protokollet för meddelandeöverföring och ett
tillämpningsfel.
H.6.4. Exempel på utformning
Figur H.2
Exempel på utformning av nätverk2000R2082 — SV — 15.06.2002 — 001.001 — 211