32000R2082

Nariadenie Komisie č. 2082/2000

zo 6. septembra 2000,

ktorým sa prijímajú technické normy Eurocontrol a mení a dopĺňa smernica 97/15/ES, ktorou sa prijímajú technické normy Eurocontrol a mení a dopĺňa smernica Rady 93/65/EHS

KOMISIA EURÓPSKYCH SPOLOČENSTIEV,

so zreteľom na Zmluvu o založení Európskeho spoločenstva,

so zreteľom na smernicu Rady 93/65/EHS z 19. júla 1993 týkajúcu sa definovania a použitia kompatibilných technických parametrov na zaobstarávanie zariadení a systémov riadenia leteckej dopravy [1], a to najmä na článok 3 tejto smernice,

so zreteľom na smernicu Komisie 97/15/ES z 25. marca 1997, ktorou sa prijímajú technické normy Eurocontrol a mení a dopĺňa smernica Rady č. 93/65/EHS týkajúca sa definovania a použitia kompatibilných technických parametrov pri obstarávaní zariadení a systémov riadenia leteckej dopravy [2],

keďže:

(1) Smernicou 97/15/ES sa prijala technická norma Eurocontrol pre priamu výmenu dát (OLDI), vydanie 1.0, a technická norma Eurocontrol pre zobrazovanie výmeny dát služby leteckej dopravy (ADEXP), vydanie 1.0.

(2) Technickou normou Eurocontrol sa prijali novšie verzie horeuvedených dvoch technických noriem, t.j. OLDI vydanie 2.2 a ADEXP vydanie 2.0 a taktiež nová technická norma Eurocontrol pod názvom Výmena letových dát - dokument riadenia prepojenia (FDE-ICD).

(3) Vyššie uvedené technické normy Eurocontrol spadajú pod rámec smernice 93/65/EHS a prispievajú k harmonizácii štátnych systémov riadenia leteckej dopravy členských štátov, a to najmä v oblasti transferu letov medzi strediskami riadenia leteckej prevádzky (OLDI) a riadením leteckej dopravy (ADEXP) a komunikácie medzi štátnymi systémami (FDE-ICD).

(4) Vydania 2.2 OLDI a 2.0 ADEXP nahrádzajú predchádzajúce vydania, ktoré sú doteraz platné podľa ustanovení článku 1 smernice 97/15/ES, a z toho dôvodu musí byť tento článok zrušený.

(5) Ustanovenia tohto nariadenia sú v súlade so stanoviskom výboru, ktorý bol vytvorený v súlade so smernicou 93/65/EHS,

PRIJALA TOTO NARIADENIE:

Článok 1

Vzhľadom na to, že povinné prvky špecifikácií Eurocontrol, ktoré sú obsiahnuté v nasledujúcich technických normách, sú nevyhnutné pre realizáciu integrovaného systému riadenia leteckej dopravy, prijímajú sa v rámci smernice 93/65/EHS:

- technická norma Eurocontrol pre priamu výmenu dát (OLDI), vydanie 2.2 (odkaz na dokument Eurocontrol DPS.ET1.ST06-STD), text ktorej je uvedený v prílohe I k tomuto nariadeniu,

- technická norma Eurocontrol pre zobrazovanie výmeny dát služby leteckej dopravy (ADEXP), vydanie 2.0 (odkaz na dokument Eurocontrol DPS.ET1.ST09-STD), text ktorej je uvedený v prílohe II k tomuto nariadeniu,

- technická norma Eurocontrol pre výmenu letových dát - dokument riadenia prepojenia (FDE-ICD), vydanie 1.0 (odkaz na dokument Eurocontrol COM.ET1.ST12-STD), text ktorej je uvedený v prílohe III k tomuto nariadeniu.

Článok 2

Týmto sa ruší článok 1 smernice 97/15/ES.

Článok 3

Toto nariadenie nadobúda účinnosť na tretí deň po jeho zverejnení v Úradnom vestníku Európskych spoločenstiev.

Toto nariadenie je záväzné vo svojej celistvosti a priamo uplatniteľné vo všetkých členských štátoch.

V Bruseli 6. septembra 2000

Za Komisiu

Loyola De Palacio

podpredseda

[1] Ú.v. ES L 187, 29.7.1993, s. 52.

[2] Ú.v. ES L 95, 10.4.1997, s. 16.

--------------------------------------------------

PRÍLOHA I

PRIAMA VÝMENA ÚDAJOV (OLDI), VYDANIE 2.2

(odkaz na dokument Eurocontrol DPS.ET1.ST06-STD)

OBSAH

POZNÁMKA K AUTORSKÉMU PRÁVU … PREDSLOV … 1. ÚVOD …

1.1. Účel …

1.2. Pôsobnosť …

2. ODKAZY …

3. DEFINÍCIE, ZNAKY A SKRATKY …

3.1. Definície …

3.2. Znaky a skratky …

4. VŠEOBECNÉ POŽIADAVKY …

4.1. Úvod …

4.2. Požiadavky na systém spracovania letových dát …

4.2.1. Letová databáza …

4.2.2. Operácia v reálnom čase …

4.2.3. Schopnosť komunikácie dát …

4.2.4. Aplikačné funkcie …

4.2.5. Rozhranie medzi človekom a počítačom (HMI) …

4.2.6. Spúšťanie správ …

4.2.7. Príjem správ …

4.3. Aktualizácia z dát získaných sledovaním …

4.4. Zaznamenávanie dát OLDI …

4.4.1. Obsah …

4.4.2. Zariadenia …

4.5. Dostupnosť, spoľahlivosť, utajenosť dát a úplnosť dát …

4.5.1. Dostupnosť …

4.5.2. Spoľahlivosť …

4.5.3. Utajenosť dát …

4.5.4. Úplnosť dát …

4.6. Vyhodnocovanie prevádzky …

4.6.1. Vyhodnocovacie obdobie …

4.6.2. Dátum spustenia operácie …

5. KATEGÓRIE SPRÁV …

5.1. Všeobecné informácie …

5.1.1. Účel …

5.1.2. Kategórie správ …

5.2. Transakčné časy …

5.2.1. Časové podmienky transakcií…

5.3. Klasifikácia a kategorizácia správ …

5.3.1. Klasifikácia správ - povinné a dodatkové …

5.3.2. Kategorizácia správ …

6. ZÁKLADNÝ POSTUP - POVINNÉ SPRÁVY …

6.1. Všeobecné ustanovenia …

6.1.1. Požiadavky …

6.1.2. Realizácia …

6.2. Správa o presunutí hranice (ABI)…

6.2.1. Účel správy ABI …

6.2.2. Obsah správy …

6.2.3. Vykonávacie predpisy …

6.2.4. Potvrdenie príjmu ABI …

6.2.5. Príklady …

6.3. Správa o aktivizácii (ACT) …

6.3.1. Účel správy ACT …

6.3.2. Obsah správy …

6.3.3. Vykonávacie predpisy …

6.3.4. Potvrdenie príjmu ACT …

6.3.5. Príklady …

6.4. Správa o logicom potvrdení príjmu (LAM) …

6.4.1. Účel správy LAM …

6.4.2. Obsah správy …

6.4.3. Vykonávacie predpisy …

6.4.4. Potvrdenie príjmu LAM …

6.4.5. Príklady …

7. ZÁKLADNÝ POSTUP - DODATKOVÉ SPRÁVY …

7.1. Všeobecné informácie …

7.1.1. Popis požiadavky …

7.1.2. Činnosť …

7.2. Správa o predbežnej aktivácii (PAC) …

7.2.1. Účel správy PAC …

7.2.2. Obsah správy …

7.2.3. Vykonávacie predpisy …

7.2.4. Potvrdenie príjmu PAC …

7.2.5. Príklady …

7.3. Správa o korekcii dát (REV) …

7.3.1. Účel správy REV …

7.3.2. Obsah správy …

7.3.3. Vykonávacie predpisy …

7.3.4. Potvrdenie príjmu REV …

7.3.5. Príklady …

7.4. Správa o zrušení koordinácie (MAC) …

7.4.1. Účel správy MAC …

7.4.2. Obsah správy …

7.4.3. Vykonávacie predpisy …

7.4.4. Potvrdenie príjmu MAC …

7.4.5. Príklady …

7.5. Správa o pridelení kódu SSR (sekundárneho prehľadového rádiolokátora) (COD) …

7.5.1. Účel správy COD …

7.5.2. Obsah správy …

7.5.3. Vykonávacie predpisy …

7.5.4. Potvrdenie príjmu COD …

7.5.5. Príklady …

7.6. Informatívna správa (INF) …

7.6.1. Účel správy INF …

7.6.2. Obsah správy …

7.6.3. Vykonávacie predpisy …

7.6.4. Potvrdenie príjmu INF …

7.6.5. Príklady …

8. DIALÓGOVÝ POSTUP - KOORDINÁCIA …

8.1. Všeobecné informácie …

8.1.1. Úvod …

8.1.2. Filter …

8.1.3. Postupnosť správ …

8.1.4. Spracovanie simultánnych správ …

8.1.5. Odmietnutie spracovania …

8.1.6. Prevádzkový prestoj na odpoveď …

8.1.7. Činnosť …

8.2. Aktivovanie správy (ACT) …

8.2.1. Účel správy ACT …

8.2.2. Obsah správy …

8.2.3. Vykonávacie predpisy …

8.2.4. Potvrdenie príjmu ACT …

8.3. Zmienená správa na aktiváciu návrhu (RAP) …

8.3.1. Účel správy RAP …

8.3.2. Obsah správy …

8.3.3. Vykonávacie predpisy …

8.3.4. Potvrdenie príjmu RAP …

8.3.5. Prevádzková odpoveď na RAP …

8.3.6. Príklady …

8.4. Správa o korekcii dát (REV) …

8.4.1. Účel správy REV …

8.4.2. Obsah správy …

8.4.3. Vykonávacie predpisy …

8.4.4. Potvrdenie príjmu REV …

8.4.5. Prevádzková odpoveď na REV …

8.5. Zmienená správa na revíziu návrhu (RRV) …

8.5.1. Účel správy RRV …

8.5.2. Obsah správy …

8.5.3. Vykonávacie predpisy …

8.5.4. Potvrdenie príjmu RRV …

8.5.5. Prevádzková odpoveď na RRV …

8.5.6. Príklady …

8.6. Pohotovostná správa (SBY) …

8.6.1. Účel správy SBY …

8.6.2. Obsah správy …

8.6.3. Vykonávacie predpisy …

8.6.4. Potvrdenie príjmu SBY …

8.6.5. Príklady …

8.7. Správa o akceptácii (ACP) …

8.7.1. Účel správy ACP …

8.7.2. Obsah správy …

8.7.3. Vykonávacie predpisy …

8.7.4. Potvrdenie príjmu ACP …

8.7.5. Príklady …

8.8. Koordinačná správa (CDN) …

8.8.1. Účel správy CDN …

8.8.2. Obsah správy …

8.8.3. Vykonávacie predpisy …

8.8.4. Potvrdenie príjmu CDN …

8.8.5. Prevádzková odpoveď na CDN …

8.8.6. Príklady …

8.9. Správa o odmietnutí koordinácie (RJC) …

8.9.1. Účel správy RJC …

8.9.2. Obsah správy …

8.9.3. Vykonávacie predpisy …

8.9.4. Potvrdenie príjmu RJC …

8.9.5. Príklady …

9. DIALÓGOVÝ POSTUP - TRANSFER KOMUNIKÁCIE …

9.1. Všeobecné ustanovenia …

9.1.1. Úvod …

9.1.2. Postupnosť správ …

9.1.3. Odovzdanie spojenia …

9.2. Správa o spustení odovzdávania (TIM) …

9.2.1. Účel správy TIM …

9.2.2. Obsah správy …

9.2.3. Vykonávacie predpisy …

9.2.4. Potvrdenie príjmu TIM …

9.2.5. Príklad …

9.3. Správa o dodatkových dátach (SDM) …

9.3.1. Účel správy SDM …

9.3.2. Obsah správy …

9.3.3. Vykonávacie predpisy …

9.3.4. Potvrdenie príjmu SDM …

9.3.5. Príklad …

9.4. Správa o návrhu na odovzdanie rádiolokátora (HOP) …

9.4.1. Účel správy HOP …

9.4.2. Obsah správy …

9.4.3. Vykonávacie predpisy …

9.4.4. Potvrdenie príjmu HOP …

9.4.5. Príklad …

9.5. Správa o požadovanej frekvencii (ROF) …

9.5.1. Účel správy ROF …

9.5.2. Obsah správy …

9.5.3. Pravidlá aplikácie …

9.5.4. Potvrdenie príjmu ROF …

9.5.5. Príklad …

9.6. Správa o zmene kmitočtu (COF) …

9.6.1. Účel správy COF …

9.6.2. Obsah správy …

9.6.3. Vykonávacie predpisy …

9.6.4. Potvrdenie príjmu COF …

9.6.5. Príklady …

9.7. MAS …

9.7.1. Účel správy MAS …

9.7.2. Obsah správy …

9.7.3. Pravidlá aplikácie …

9.7.4. Potvrdenie príjmu MAS …

9.7.5. Príklad …

PRÍLOHA A (NORMATÍVNA) PRAVIDLÁ VKLADANIA DÁT … PRÍLOHA B (NORMATÍVNA) ZVLÁŠTNE POŽIADAVKY NA SPRACOVANIE TRASY… PRÍLOHA C (INFORMATÍVNA) POSTUP DIALÓGU (SYSCO ÚROVEŇ 1) FÁZY - POSTUPNOSŤ SPRÁV … AUTORSKÁ DOLOŽKA

Tento dokument vyhotovila Agentúra Eurocontrol.

Autorské práva prislúchajú Agentúre Eurocontrol.

Obsah tohto dokumentu alebo niektorej jeho časti je bez obmedzenia k dispozícii zástupcom členských štátov, poskytnutie jeho odpisu alebo vyzradenie jeho obsahu tretej strane sa však môže uskutočniť len na základe predchádzajúceho písomného súhlasu Agentúry Eurocontrol.

PREDSLOV

1. Zodpovedný orgán

Technickú normu upravujúcu priamu výmenu dát (OLDI), vydanie 2.2 vypracovalo Riaditeľstvo rozvoja Európskeho programu harmonizácie a integrácie riadenia leteckej prevádzky (EATCHIP) (DED), Eurocontrol, ktoré zodpovedá aj za aktualizovanie dokumentu. Všetky pripomienky alebo otázky je potrebné zaslať na túto adresu: Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for the attention of Division DED-2.

2. Vzťah k programovému dokumentu EATCHIP

Touto technickou normou sa napĺňa osobitná úloha DPS.ET1.ST06 v oblasti systémov spracovania dát ATM (DPS) EATCHIP, ako je to uvedené v programovom dokumente EATCHIP (EWPD), vydanie 2.0 zo dňa 30.9.94.

3. Schvaľovanie a zmeny a dodatky

Táto technická norma bola predmetom tohto schvaľovacieho konania, ako je to presne uvedené v smerniciach upravujúcich štandardizáciu Eurontrol:

- schválenie pracovnou skupinou pre spracovanie dát ATM (ODT) a prevádzkové požiadavky EATCHIP v príslušnom konaní,

- porada všetkých štátov ECAC prostredníctvom ich zástupcov v riadiacom výbore alebo Výbore pre projekt EATCHIP,

- schválenie Výborom pre projekt EATCHIP a riadiacim výborom,

- prijatie stálou komisiou.

Ustanovenia tejto technickej normy nadobúdajú účinnosť po jej prijatí stálou komisiou.

V záujme uspokojenia požiadaviek, ktoré kladie vývoj v metodike riadenia leteckej prevádzky, možno cez ODT na prejednanie a prípadné schválenie navrhnúť zmeny a dodatky. Požiadavky sa zapracujú buď vo forme novely alebo ďalšieho vydania dokumentu, ktoré sa potvrdí a schváli v súlade s uvedenými postupmi.

4. Zásady zostavenia textu

Pri označovaní právnej sily každého ustanovenia sa uplatnili tieto zásady: normatívna časť textu sa vytlačila jemným typom písma; Odporúčania sa vytlačili jemnou kurzívou, pričom právnu silu vyjadruje názov Odporúčanie.

Pri písaní špecifikácií sa uplatnia tieto zásady: v normatívnej časti sa používa sloveso textu "musieť", pre odporúčania "mať".

Poznámky sú vytlačené jemnou kurzívou s označením "POZNÁMKA".

5. Vzťah k 1. vydaniu Technickej normy Eurocontrol o priamej výmene dát

Tento dokument nahrádza časti 1 a 2 1.vydania Technickej normy Eurocontrol o priamej výmene dát. Časť 3, popisujúca technické protokoly, ktoré sa majú používať, sa nahrádza Technickou normou Eurocontrol o výmene letových dát - dokument o riadení prepojenia, časť 1.

6. Dôležité zmeny oproti 1. vydaniu

V porovnaní s 1.vydaním sú najdôležitejšie tieto zmeny:

1. Zavedenie týchto dodatkových (nepovinných) správ v súvislosti so základným postupom:

- správa o zrušení koordinácie (MAC),

- správa o pridelení kódu sekundárnemu prehľadovému rádiolokátoru (SSR) (COD),

- informatívna správa (INF).

2. Určenie obsahu a formátu správy pri prelete hranice lietadlom, ktorého kurz nesleduje vymedzenú trasu služieb leteckej dopravy (ATS), ale ho vymedzuje počiatočný a konečný bod príslušného úseku trasy.

3. Zavedenie dialógového postupu, ktorý umožňuje:

- aby dispečeri zostavujúci letový plán určili a dohodli neštandardný režim odovzdania spojenia,

- aby prijímacie stanovište predložilo protinávrh režimu odovzdania spojenia,

- aby boli v rámci odovzdávania riadenia letu odovzdané spojovacie zariadenia.

4. Zavádza sa používanie formátu popísaného v 2. vydaní Technickej normy Eurocontrol týkajúcej sa zobrazovania výmeny dát služby leteckej dopravy (ADEXP). Všetky správy, ktoré sa uvádzajú v rámci základného postupu, ako aj tie, ktoré sa používajú počas koordinačnej fázy dialógového postupu, sa popisujú pomocou formátov Medzinárodnej organizácie civilného letectva (ICAO) a ADEXP. Správy o odovzdaní spojenia uvedení v dialógovom postupe, sa popisujú len pomocou formátu ADEXP.

5. Rušia sa tieto prílohy k 1. vydaniu:

A : Identifikácia stanovíšť riadenia leteckej prevádzky

B :

Štruktúra správy OLDI

(všetky správy v 3. vydaní zahŕňajú príklady).

D : Historický prehľad

E : Vykonávací plán

F : Plnenie jednotlivými štátmi

G : Vykonávacie smernice

H : Smernice na vyhodnocovanie OLDI

6. Oddelenie časti 3 - Technické požiadavky - od špecifikácie aplikácií.

7. Vzťah k iným dokumentom

Tento dokument sa odvoláva na používanie dvoch typov formátov polí pri zostavovaní správ; ide o formáty ICAO a ADEXP.

Formáty polí ICAO sú popísané v odkaze 1. V prípade, že odkaz 1 bude nahradený iným dokumentom, typy polí ICAO sa budú definovať tak, ako je to uvedené v spomínanom dokumente.

Formáty polí ADEXP sú popísané v Odkaze 2.

POZNÁMKA

Odkazy, na ktoré sa tu odvoláva, sú vymenované v oddieli 2.

8. Jazyk

Pri vypracúvaní originálu tohto dokumentu sa použil anglický jazyk.

1. ÚVOD

1.1. Účel

1.1.1. Lety, ktorým sa poskytuje služba riadenia leteckej prevádzky, si stanovištia riadenia leteckej prevádzky odovzdávajú tak, aby bola zabezpečená úplná bezpečnosť. Preto prelet každého lietadla cez hranicu oblastí pokrytia dvoch stanovíšť tieto stanovištia spoločne vopred koordinujú a riadenie letu si odovzdávajú v okamihu, keď sa lietadlo nachádza na spomínanej hranici alebo v jej tesnej blízkosti.

1.1.2. V prípade, že dáta o jednotlivých letoch sa v rámci koordinácie odovzdávajú telefonicky, ide o veľmi významnú zabezpečovaciu úlohu, ktorá sa vykonáva na stanovištiach riadenia leteckej prevádzky, a to najmä v oblastných riadiacich strediskách (ACC). Spojenia medzi systémami spracovania letových dát (FDPS) v strediskách ACC, čo sa nazýva priama výmena dát (OLDI), sa v prevádzke začali v Európe používať začiatkom osemdesiatych rokov dvadsiateho storočia, aby nahradili takéto ústne odhady.

1.1.3. Inštitúcie, ktorých sa to dotklo, a ktoré boli začlenené do 1. vydania Technickej normy Eurocontrol o priamej výmene dát, v záujme ľahšieho vykonávania činnosti vypracovali a schválili jednotné pravidlá a formáty správ; tento dokument, vydanie, bol vypracovaný na podporu ďalšieho rozvoja takýchto zariadení v súlade s požiadavkami EATCHIP.

1.2. Pôsobnosť

1.2.1. V tomto dokumente sa uvádzajú zariadenia a správy, ktoré si majú poskytovať systémy FDPS obsluhujúce stanovištia riadenia letovej prevádzky, aby sa dosiahlo toto:

- požadovaná koordinácia pred odovzdaním riadenia letu jedným stanovišťom ďalšiemu,

- odovzdanie spojenia s takýmito lietadlami.

1.2.2. Tento dokument:

- definuje formáty správ a pravidlá určujúce ich obsah,

- popisuje zariadenia, ktorými musia byť takéto stanovištia vybavené, čo je nevyhnutný predpoklad na to, aby sa na tento účel mohla používať priama výmena dát.

1.2.3. Táto technická norma sa v rámci vzťahov medzi členskými štátmi Eurocontrol týka medzinárodných zariadení OLDI v styku medzi stanovišťami, ktoré poskytujú službu oblastného riadenia leteckej prevádzky.

1.2.4. Odporúčanie

Odporúča sa, aby štáty Európskej konferencie o civilnom letectve (ECAC) túto technickú normu uplatňovali na:

- medzinárodné zariadenia OLDI v styku medzi stanovišťami, ktoré poskytujú službu oblastného riadenia leteckej prevádzky na území ECAC,

- na zariadenia OLDI v styku medzi stanovišťami, ktoré poskytujú službu oblastného riadenia leteckej prevádzky na území príslušného štátu.

2. ODKAZY

2.1. Ustanovenia, ktoré sa v dôsledku toho, že sa na ne táto technická norma odvoláva, stávajú ustanoveniami tejto technickej normy Eurocontrol, sú obsiahnuté v týchto dokumentoch.

V čase zverejnenia tejto technickej normy Eurocontrol boli dokumenty, na ktoré sa tu odvoláva, platné v uvedenom vydaní.

Zohľadní sa každá úprava dokumentov ICAO, na ktoré sa tu odvoláva, a v súlade s tým sa upraví táto technická norma Eurocontrol.

Úpravy iných dokumentov, na ktoré sa tu odvoláva, sa stanú súčasťou ustanovení tejto technickej normy Eurocontrol až po ich formálnom posúdení a začlenení do tejto technickej normy Eurocontrol.

V prípade, že požiadavky obsiahnuté v tejto technickej norme Eurocontrol nie sú v súlade s obsahom spomínaných dokumentov, na ktoré sa tu odvoláva, prednosť má táto technická norma Eurocontrol.

2.2. Táto technická norma obsahuje odkazy na tieto dokumenty:

1. Prevádzkový poriadok služieb leteckej navigácie - prevádzkový poriadok služieb leteckej dopravy, Dokument ICAO 4444, trináste vydanie zo dňa 7. novembra 1996 v novelizovanom znení.

2. Vydanie 2.0 Technickej normy Eurocontrol týkajúce sa zobrazovania výmeny dát služby leteckej dopravy (ADEXP), značka DPS-ET1-ST09-STD-01-00 z júna 1998.

3. DEFINÍCIE, ZNAKY A SKRATKY

3.1. Definície

Na účely tejto technickej normy platia tieto definície.

Prijímajúce (akceptujúce) stanovište : Stanovište poskytujúce službu riadenia leteckej prevádzky, ktoré má prevziať alebo prevzalo riadenie letu vo chvíli, keď jedno stanovište má odovzdať alebo odovzdalo jeho riadenie ďalšiemu.

Potvrdenie o príjme : Oznámenie o tom, že správa bola prijatá a možno ju riadne spracovať.

Aktivácia : proces prebiehajúci na prijímacom stanovišti riadenia leteckej prevádzky, v rámci ktorého sa letový plán príslušného lietadla dopĺňa o údaje, ktoré odovzdávajúce stanovište poskytlo ako súčasť koordinácie medzi oboma stanovišťami, a z ktorého vzídu dáta určené pre dispečerov.

Výška letu : Vertikálna vzdialenosť určitej hladiny, bodu alebo predmetu považovaného za bod, ktorá sa meria od strednej hladiny mora.

Aplikácia : Tá časť podsystému ATS, ktorá vyhovuje tejto technickej norme a prepája sa s takýmito jednotkami v iných systémoch ATS.

Oblasť pokrytia : Vzdušný priestor s vymedzenými rozmermi, v rámci ktorého stanovište riadenia leteckej prevádzky poskytuje služby leteckej dopravy.

Pridruženie : Postup, počas ktorého určitý systém priradí prijatú správu OLDI k zápisu letového plánu v databáze.

Stanovište ATC : Stanovište poskytujúce službu riadenia leteckej prevádzky.

Prístupnosť : Pravdepodobnosť, že užívateľ bude mať v určitom čase prístup k určitému zariadeniu.

Hranica : Roviny (bočné a vertikálne) vymedzujúce oblasť pokrytia stanovišťom riadenia leteckej prevádzky.

Povolená letová hladina : Letová hladina, ktorú práve povolilo stanovište riadenia leteckej prevádzky

Koordinácia, ATC : Činnosť, ktorú vo vzájomnom styku vykonávajú stanovištia riadenia leteckej prevádzky, ktorých oblasti pokrytia spolu susedia, a ktoré si oznamujú plánované prelety liedatiel cez hranicu, aby sa zosúladením plánovaných činností zaistila bezpečnosť letu.

Koordinačná správa : Všeobecný pojem označujúci správu, ktorá sa používa na skoordinovanie riadenia leteckej prevádzky. Patrí sem aj CDN, čo je osobitný druh správy popísaný v odseku 8.8.

Koordinačná fáza : Vo vzťahu k danému letu fáza, počas ktorej sa odovzdávajúce a prijímajúce stanovištia dohodnú na určitých podmienkach (napríklad na letovej hladine, hraničnom bode), za ktorých si odovzdajú riadenie letu.

Koordinačný bod : Bod ležiaci na hranici alebo v jej tesnej blízkosti, ktorý stanovištia riadenia leteckej prevádzky poznajú v rámci koordinačnej sekvencie, a na ktorý sa odvolávajú koordinačné správy.

Korelácia : Proces založený na definovaných kritériách pre spájanie dát letového plánu s rádiolokátorovým kurzom letu, zvyčajne za účelom zobrazovania na dispečerskom displeji.

Technická norma Eurocontrol : Parametre fyzických charakteristík, konfigurácie, materiálu, výkonu, personálu alebo postupu, ktorých jednotné uplatňovanie sa schválilo, keďže to má zásadný význam pre činnosť v rámci systémov ATS v členských štátoch Eurocontrol. Technická norma Eurocontrol nesmie byť v rozpore s technickými normami ICAO, ale tam, kde je to vhodné, by ich mala dopĺňať.

Výkonný dispečer : Dispečer, ktorý priamo vydáva pokyny lietadlám, ktorých let riadi. Patria k nim aj dispečeri, ktorí poskytujú službu oblastného riadenia leteckej prevádzky.

Výstupná hladina : Hladina, v ktorej bolo lietadlo skoordinované na prelet bodom odovzdávania riadenia. Výstupná hladina môže zahŕňať dodatkové podmienky prechodu, ktoré vymedzujú hladinové pásmo, v ktorom sa bude nachádzať stúpajúce/klesajúce lietadlo.

Letový plán : Predpísané údaje, ktoré sa poskytujú stanovištiam služby leteckej dopravy a ktoré sa vzťahujú na plánovaný let či časť letu určitého lietadla. Okrem toho obsahujú aj informácie z letového plánu konkrétneho letu, ktoré sa uchovávajú v systéme FDPS.

Generovať : Proces prebiehajúci v systéme riadenia leteckej prevádzky, počas ktorého sa príslušné dáta vyberajú z databázy a zostavuje sa správa určená na odvysielanie stanovišťu riadenia leteckej prevádzky.

Formát ICAO : Formát, ktorý sa používa na prenos správ ATS medzi pozemnými stanicami, a v ktorom sa používajú typy polí a oddeľovačov popísané v odkaze 1.

Hladina : Všeobecný termín vzťahujúci sa na vertikálnu polohu lietadla počas letu; v tejto technickej norme termín hladina alebo letová hladina, tam, kde sa používa, zahŕňa aj výšku letu.

Hlásenie : Proces, počas ktorého odovzdávajúce stanovište v príprave na koordinačnú fázu odovzdáva dáta na aktualizovanie systému v prijímacom stanovišti.

Prijímajúce stanovište : Stanovište riadenia leteckej prevádzky, ktorému sa správa odosiela.

Spoľahlivosť : Percentuálna miera plánovanej dostupnosti, v rámci ktorej sa má služba vykonávať.

Požadovaná letová hladina : Letová hladina, ktorú v letovom pláne požaduje lietadlo.

Korekcia : Zmeny a doplňujúce údaje, ktoré už odovzdávajúce stanovište riadenia leteckej prevádzky zaslalo prijímajúcemu stanovišťu riadenia leteckej prevádzky.

Dodatková hladina preletu : Hladina, na ktorej, nad ktorou alebo pod ktorou bol skoordinovaný prelet lietadla cez bod odovzdávania riadenia. Pokiaľ sa dodatková hladina používa, je zložkou výstupnej hladiny.

Systémový letový plán : Informácie z letového plánu konkrétneho lietadla, ktoré sa uchovávajú v systéme FDSP.

Transakčný čas : Časový interval nasledujúci po spustení správy, počas ktorého sa vykoná prenos, počiatočné spracovanie v prijímajúcom systéme, generovanie a prenos správy potvrdzujúcej príjem a jej identifikácia v odovzdávajúcom systéme.

Bod odovzdania riadenia : Presne definovaný bod ležiaci na letovej dráhe lietadla, v ktorom zodpovednosť za poskytovanie služby ATS lietadlu prechádza z jedného stanovišťa riadenia leteckej prevádzky na druhé. Nemusí sa zhodovať s koordinačným bodom.

Odovzdávacia fáza : Fáza letu nasledujúca po koordinačnej, počas ktorej sa odovzdá spojenie.

Odovzdávajúce stanovište : V koordinačnej sekvencii stanovište riadenia leteckej prevádzky zodpovedné za poskytovanie služby určitému letu pred hranicou a ktoré spúšťa koordinačnú fázu s ďalším stanovišťom.

Odovzdať : Odoslať správu z jedného systému na druhý.

Stanovište : Stanovište služby leteckej dopravy

Výstraha : Správa, ktorá sa zobrazí na pracovisku v prípade, že zlyhal proces koordinácie.

3.2. Znaky a skratky

Na účely tejto technickej normy Eurocontrol sa používajú tieto znaky a skratky:

ABI informatívna správa o predsunutí hranice

ACC oblastné riadiace stredisko

ACP správa o prijatí

ACT správa o aktivácii

ADEXP zobrazovanie výmeny dát služby leteckej dopravy

ATC služba riadenia leteckej prevádzky

ATM riadenie leteckej dopravy

ATS služba leteckej dopravy

CDN koordinačná správa

CNL zrušenie letového plánu

COD správa o pridelení kódu sekundárneho prehľadového rádiolokátora

COF správa o zmene frekvencie

COP koordinačný bod

DED riaditeľstvo rozvoja Európskeho programu harmonizácie a integrácie riadenia leteckej prevádzky

EATCHIP Európsky program harmonizácie a integrácie riadenia leteckej prevádzky

ECAC Európska konferencia o civilnom letectve

ETO odhadovaný čas do preletu hranice

ETOT odhadovaný čas vzlietnutia

EWPD programový dokument Európskeho programu harmonizácie a integrácie riadenia leteckej prevádzky

FDPS systém spracovania letových dát

FRF ďalšia trasa letu

HMI rozhranie medzi človekom a počítačom

HOP správa o návrhu na odovzdanie rádiolokátora

ICAO Medzinárodná organizácia civilného letectva

INF informatívna správa

LAM správa o logickom potvrdení príjmu

LoA písomná dohoda

MAC správa o zrušení koordinácie

MAS ručné nadviazanie spojenia

NM námorná míľa

OLDI priama výmena dát

ORCAM metóda priraďovania kódu východzej oblasti

PAC správa o predbežnej aktivácii

RAP správa o postúpení návrhu na aktiváciu

REV správa o korekcii dát

RJC správa o odmietnutí koordinácie

ROF správa o požadovanej frekvencii

RRV správa o postúpení korekcie

SBY správa o príjme a postúpení

SDM správa o dodatkových dátach

SSR sekundárny prehľadový rádiolokátor

SYSCO koordinácia zabezpečovaná systémom

TI spustenie odovzdávania

TIM správa o spustení odovzdávania

TWR/APP riadiaca veža (riadenie letištnej prevádzky) a riadenie približovania

4. VŠEOBECNÉ POŽIADAVKY

4.1. Úvod

Táto časť obsahuje všeobecné prevádzkové požiadavky, ktoré sú nevyhnutné na realizáciu zariadenia OLDI medzi stanovišťami riadenia leteckej prevádzky a klasifikáciu a požiadavky na vykonávanie rôznych typov správ, ktoré sa používajú.

4.2. Požiadavky na systém spracovania letových dát

4.2.1. Letová databáza

Stanovištia, ktoré používajú zariadenie popísané v tomto dokumente, dostávajú dáta od niektorého systému FDPS, ktorý obsahuje všetky požadované údaje na zobrazenie, spracovanie a zostavovanie predpísaných správ. Dáta o každom lete v prvom rade pochádzajú z letového plánu, ktorý predloží veliaci pilot alebo niekto iný v jeho zastúpení. Ďalšie dáta sa získavajú spracovaním letových plánov so zreteľom na okolie dotknutého stanovišťa.

4.2.2. Operácia v reálnom čase

Postup OLDI zahŕňa operácie v odovzdávajúcom stanovišti riadenia leteckej prevádzky, aby sa mohli spustiť funkcie potrebné na včasné predloženie dát odovzdávajúcemu dispečerovi a odvysielanie koordinačných dát prijímajúcemu stanovišťu. Na tento účel musí byť FDSP schopný spustiť funkcie porovnávaním koordinovaného univerzálneho času a platných časových parametrov s časmi v ustanovených polohách na trase letu, ako boli určené z databázy.

4.2.3. Schopnosť prenosu dát

4.2.3.1. FDSP musí mať schopnosť prijímať a odovzdávať letové dáta vo formáte platnom pre danú správu, ako je to uvedené v tomto dokumente, cez médium na prenos dát, ktoré zabezpečuje funkciu OLDI.

4.2.3.2. Odporúčanie

FDSP by mal byť natoľko vývojaschopný, že sa bude dať doplniť o nové druhy správ, ktoré sa prípadne zahrnú do budúcich vydaní tejto technickej normy.

4.2.3.3. V rámci požiadaviek na výkon, ktoré sú uvedené v tomto dokumente, médium na prenos dát musí zabezpečiť rýchlu a spoľahlivú výmenu dát medzi aplikáciami tým, že:

- zabezpečí prenos dát OLDI v celom rozsahu,

a

- bude monitorovať buď dvojbodové spojenia alebo stav komunikačnej siete.

4.2.3.4. FDPS upozorňuje pracoviská, ak systém prenosu dát zistí určité anomálie.

4.2.4. Funkcie aplikácií

4.2.4.1. Systémy, ktoré sa používajú na poskytovanie zariadení OLDI, musia mať schopnosť v reálnom čase automaticky prijímať, uchovávať, spracúvať, vyberať a dodávať na zobrazenie a prenášať dáta týkajúce sa OLDI.

4.2.4.2. FDSP musí mať tieto schopnosti:

- priebežne akceptovať prevádzkové dáta týkajúce sa funkcie OLDI, ako to vyžaduje táto technická norma, aktualizované buď automaticky, manuálnym vstupom alebo kombináciou oboch spôsobov,

- vyberať takéto prvky z databázy letového plánu,

- identifikovať ďalšie stanovište riadenia leteckej prevádzky na trase letu.

4.2.4.3. Dvojstranne sa dohodne toto:

- koordinačné body (COP),

- orientačné body slúžiace na zápis kurzu a vzdialenosti pri identifikácii bodu COP na priamych úsekoch trasy, kde sa neposkytuje ATS, ak sú potrebné.

POZNÁMKA

Body COP sa nemusia vždy zhodovať s bodmi odovzdávania riadenia.

4.2.5. Rozhranie medzi človekom a počítačom (HMI)

4.2.5.1. HMI musí mať tieto schopnosti:

- zobrazovať funkčný obsah správ OLDI a príslušné súrne výstrahy k prijatým správam,

- usmerňovať koordináciu a odovzdávať výstražné správy prevádzkam, ktoré zodpovedajú za koordináciu dotknutých letov.

4.2.5.2. Personál riadenia leteckej prevádzky obdrží prostriedky na zmenu dát, z ktorých pochádza funkčný obsah správ, ako sa to vyžaduje v tomto dokumente.

4.2.5.3. HMI udáva, že prenos správy prebieha, prípadne, že sa úspešne skončil.

4.2.5.4. Výstraha alebo hlásenie príslušným pracoviskám riadenia letovej prevádzky alebo technickým pracoviskám sa generuje automaticky, pokiaľ po odvysielaní správy o koordinácii alebo odovzdaní riadenia nebol v predpísanom čase potvrdený príjem.

4.2.5.5. Takáto výstraha alebo hlásenie musí mať formu, ktorá okamžite vyvolá pozornosť na príslušnom pracovisku.

4.2.5.6. Odporúčanie

HMI na pracoviskách riadenia leteckej premávky, kde sa používa OLDI, by mali poskytnúť výstrahu, pokiaľ zariadenie OLDI nie je k dispozícii.

4.2.6. Spúšťanie prenosu správ

4.2.6.1. Každý systém obsahuje súbor systémových parametrov, aby sa včas zaistilo automatické spustenie správ OLDI.

4.2.6.2. Odporúčanie

Mala by sa zabezpečiť schopnosť ručne spustiť odoslanie správy o koordinácii ešte pred vypočítaným časom prenosu.

4.2.6.3. Automatická činnosť sa zabezpečí vždy vtedy, keď sa nevykoná ručné spustenie.

4.2.6.4. V systéme sa použijú časové parametre na definovanie tohto:

- realizačný čas, pred prenosom, keď sa funkčný obsah správ zobrazuje na odovzdávajúcom stanovišti.,

- realizačný čas, celkový alebo za jeden COP, potrebný na odvysielanie správy tam, kde sa používa,

- čas, za ktorý musí po prenose správy prísť na určitej aplikačnej úrovni potvrdenie o príjme.

4.2.6.5. Správa sa odvysiela bezodkladne, keď sa požadované informácie získajú neskôr než v čase, v ktorom by sa inak odvysielala.

Príklad:

Let sa podľa prístrojov začína v segmente GAT IFR, v bode neďaleko hranice, ktorým vzápätí prejde; v tomto bode má ETO hodnotu osem minút do COP, v tomto čase odvysielanie správy ACT už podľa platných časových parametrov mešká; správa sa teda odošle bezodkladne.

4.2.7. Príjem správ

4.2.7.1. Systém riadenia leteckej prevádzky musí mať schopnosť:

- prijímať správy OLDI,

- spracúvať ich automaticky v súlade s touto technickou normou,

- vydávať výstupné letové dáta, ktoré sú v súlade s prijatou správou a v prípade, že prijaté dáta spolu nesúhlasia, zobraziť požadované výstrahy,

- automaticky generovať a odovzdávať na úrovni aplikácie správy o potvrdení príjmu.

4.2.7.2. Správa o potvrdení príjmu (logické potvrdenie príjmu (LAM), potvrdenie ručného príjmu (ACP) alebo potvrdenie príjmu a postúpenie (SBY) sa generuje a odosiela po spracovaní zodpovedajúcej správy a po tom, čo sa zabezpečí, že výsledky spracovania sa podľa potreby predložia príslušným pracovískám.

POZNÁMKA

Podmienky na generovanie potvrdenia príjmu sa upresňujú pre každú správu osobitne.

4.3. Aktualizácia dát získaných sledovaním

Odporúčanie

V záujme presného odhadu časových dát by sa na aktualizáciu databázy mali využiť informácie získané sledovaním leteckej prevádzky rádiolokátorom alebo inými sledovacími prostriedkami.

4.4. Zaznamenávanie dát OLDI

4.4.1. Obsah

Zaznamenáva sa obsah všetkých správ OLDI a čas ich príjmu.

4.4.2. Zariadenia

K dispozícii musia byť zariadenia na vyhľadávanie a zobrazovanie zaznamenaných dát.

4.5. Dostupnosť, spoľahlivosť, utajenosť dát a úplnosť dát

4.5.1. Dostupnosť

4.5.1.1. Zariadenie OLDI je k dispozícii v čase bežnej a špičkovej prevádzky medzi dotknutými stanovišťami.

4.5.1.2. Odporúčanie

Zariadenie OLDI by malo byť k dispozícii 24 hodín denne.

4.5.1.3. Na plánovaných prestojoch (a teda aj plánovanom čase dostupnosti) sa spolu dohodnú obe dotknuté stanovištia.

4.5.2. Spoľahlivosť

4.5.2.1. Percentuálna miera spoľahlivosti každého spojenia OLDI musí byť aspoň 99,86 % (čo sa rovná prestoju do 12 hodín ročne pri 24 hodinovej dostupnosti).

4.5.2.2. Odporúčanie

Tam, kde je to z prevádzkových dôvodov odôvodnené, by sa mala zabezpečiť percentuálna miera spoľahlivosti aspoň 99,99 % (čo sa rovná prestoju do 52 minút pri 24-hodinovej dostupnosti).

4.5.3. Utajenosť dát

Odporúčanie

Na prostriedky OLDI by sa mali uplatňovať metódy utajovania dát (napr. práva na prístup, overovanie zdroja).

4.5.4. Úplnosť dát

Poruchovosť na úrovni aplikácie nesmie byť väčšia ako jeden chybný prenos na 2000 správ.

4.6. Vyhodnocova prevádzky

4.6.1. Vyhodnocovacie obdobie

Každé nové zariadenie OLDI, vrátane nového zariadenia na existujúcom spojení, prejde pred uvedením do prevádzky obdobím vyhodnocovania, aby sa overilo z hľadiska úplnosti dát, presnosti, výkonu, kompatibility s postupmi riadenia leteckej prevádzky a celkovej bezpečnosti.

POZNÁMKA

O postupe, ktorý uľahčuje vyhodnocovanie nového zariadenia OLDI, sa možno informovať na sekretariáte OLDI, Eurocontrol.

4.6.2. Termín uvedenia do prevádzky

Na termíne uvedenia do prevádzky, čo je podmienené ukončením vyhodnocovacieho obdobia, sa obe strany formálne dohodnú.

5. KATEGÓRIE SPRÁV

5.1. Všeobecné informácie

5.1.1. Účel

V tejto časti dokumentu:

- sa definujú kategórie správ,

- sa ustanovujú požiadavky na transakčný čas pre jednotlivé kategórie,

- sa ustanovuje, ktoré druhy správ sú povinné, a ktoré dodatkové,

- sa typy správ zaraďujú do kategórií.

5.1.2. Kategórie správ

Správy OLDI boli zaradené do týchto kategórií:

- kategória 1: Odovzdanie spojenia,

- kategória 2: Koordinácia,

- kategória 3: Hlásenie.

5.2. Transakčné časy

5.2.1. Režim transakčných časov

5.2.1.1. Uvedené transakčné časy zahŕňajú prenos, prvé spracovanie na prijímajúcom stanovišti, vytvorenie správy potvrdzujúcej príjem, jej prenos a príjem na odovzdávajúcom stanovišti. Automatické správy potvrdzujúce príjem LAM a SBY preto neboli zaradené do žiadnej aktegórie.

5.2.1.2. Maximálne transakčné časy pre jednotlivé kategórie správ sú uvedené v tabuľke 5-1.

Tabuľka 5-1

Maximálne transakčné časy

Kategória správy | 90 % | 99,8 % |

1 | 4 s | 10 s |

2 | 10 s | 25 s |

3 | 15 s | 45 s |

5.2.1.3. Hodnota prestoja sa určí podľa kategórie alebo typu správy.

5.2.1.4. Pokiaľ sa príjem správy do uplynutia predpísaného času po jej odvysielaní nepotvrdí, usúdi sa, že správa sa považuje za neodvysielanú alebo nespracovanú a vydá sa výstupná výstraha, ako je to uvedené v príslušnej časti tohto dokumentu.

5.2.1.5. Odporúčanie

Hodnota prestojov pre tieto tri kategórie by nemala prevýšiť 12 sekúnd, resp. 30 sekúnd, resp. 60 sekúnd.

5.3. Klasifikácia a kategorizácia správ

5.3.1. Klasifikácia správ - povinné a dodatkové

5.3.1.1. V tomto dokumente sa správy klasifikujú buď ako povinné alebo dodatkové.

5.3.1.2. Ak sa udáva, že správa je povinná (M) pre odvysielanie (TX), zahŕňa to aj spracovanie, aby sa takéto správy dali odoslať.

5.3.1.3. Ak sa udáva, že správa je povinná pre príjem (REC), zahŕňa to aj spracovanie, aby sa prijaté správy dali spracovať.

POZNÁMKA

Vo výnimočných prípadoch, keď medzi dvoma stanovišťami prebieha jednosmerná prevádzka, povinné správy môžu platiť len v jednom smere.

5.3.1.4. Ak sa udáva, že správa je dodatková (C) pre odvysielanie, zahŕňa to aj spracovanie, aby odosielacie stanovište takéto správy, pokiaľ sa to vyžaduje a dvojstranne dohodlo s prijímajúcim stanovišťom, mohlo odoslať.

POZNÁMKA

Dodatkové správy sa podľa prevádzkových požiadaviek môžu používať vždy len jednosmerne.

5.3.1.5. Ak sa udáva, že správa je dodatková pre príjem, zahŕňa to aj spracovanie, aby sa prijaté správy dali spracovať, ak sa takéto použitie dvojstranne dohodlo.

5.3.1.6. Požiadavky uvedené v tabuľkách 5-3 a 5-4 platia len v prípade, že stanovištia riadenia leteckej prevádzky sa dvojstranne dohodli, že na koordináciu a/alebo odovzdanie spojenia sa použije dialógový postup.

5.3.2. Kategorizácia správ

5.3.2.1. Kategorizácia správ pre základný postup sa uvádza v tabuľke 5-2.

5.3.2.2. Kategorizácia dodatkových koordinačných správ pre dialógový postup sa uvádza v tabuľke 5-3.

5.3.2.3. Kategorizácia správ o odovzdaní spojenia pre dialógový postup sa uvádza v tabuľke č. 5-4.

Tabuľka 5-2

Správy pre základný postup

Typ správy | Skratka | Kategória | Odvysielanie | Príjem |

Informácia o pedsunutí hranice | ABI | 3 | M | M |

Aktivácia | ACT | 2 | M | M |

Korekcia dát | REV | 2 | C [1] | C [1] |

Predbežná aktivácia | PAC | 2 | C | C |

Zrušenie koordinácie | MAC | 2 | C | C |

Pridelenie kódu SSR | COD | 2 | C | C |

Informatívna správa | INF | 3 | C | C |

Logické potvrdenie príjmu | LAM | | M | M |

Tabuľka 5-3

Dialógový postup - správy o koordinačnej fáze

(Dodatkové k tabuľke 5-2)

Typ správy | Skratka | Kategória | Odvysielanie | Príjem |

Postúpenie návrhu na aktiváciu | RAP | 2 | C | M |

Postúpenie korekcie | RRV | 2 | C | M |

Koordinácia | CDN | 2 | M | M |

Potvrdenie príjmu a postúpenie [2] | SBY | | M | M |

Ručné potvrdenie príjmu | ACP | 2 | M | M |

Odmietnutie koordinácie [3] | RJC | 2 | C | C |

Tabuľka 5-4

Dialógový postup - správy o odovzdávacej fáze

Typ správy | Skratka | Kategória | Odvysielanie | Príjem |

Spustenie odovzdania riadenia | TIM | 1 | M | M |

Dodatkové dáta | SDM | 1 | [4] | [4] |

Návrh na odovzdanie | HOP | 1 | M | M |

Zmena kmitočtu [5] | COF | 1 | C | M |

Požadovaný kmitočet | ROF | 1 | C | M |

Ručné nadviazanie spojenia [5] | MAS | 1 | C | M |

6. ZÁKLADNÝ POSTUP - POVINNÉ SPRÁVY

6.1. Všeobecné ustanovenia

6.1.1. Požiadavky

V tomto oddieli sa popisujú minimálne požiadavky na používanie prostriedkov OLDI na úrovni aplikácie.

6.1.2. Realizácia

Stanovištia, ktoré na koordináciu letov používajú OLDI, vykonávajú ABI, ACT a LAM, ako je to uvedené v tomto oddieli. Pokiaľ sa dvojstranne nedohodlo, že na koordináciu sa bude používať dialógový postup, ako je to uvedené v oddieli 8 tohto dokumentu, tak pre používanie správ ACT a LAM platia podmienky uvedené v spomínanom oddieli.

6.2. Správa o predsunutí hranice (ABI)

6.2.1. Účel správy ABI

ABI uspokojuje tieto prevádzkové požiadavky:

- poskytuje chýbajúce dáta o letovom pláne,

- poskytuje ďalšiemu stanovišťu riadenia leteckej prevádzky informácie o predsunutí hranice a korekciu týchto údajov,

- aktualizuje základné dáta letového plánu,

- uľahčuje včasnú koreláciu rádiolokátorových kurzov,

- uľahčuje presné stanovenie krátkodobej vyťaženosti sektoru.

ABI je správa, ktorá má povahu hlásenia.

6.2.2. Obsah správy

Správa ABI obsahuje tieto údaje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- režim a kód SSR (pokiaľ je k dispozícii),

- letisko odletu,

- dáta určené odhadom,

- cieľové letisko,

- číslo a typ lietadla,

- trasu (nepovinne),

- iné údaje o letovom pláne (nepovinne),

POZNÁMKA

Pravidlá pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

6.2.3. Vykonávacie predpisy

6.2.3.1. Všeobecné ustanovenia

6.2.3.1.1. S výhradou ustanovení v bodoch 6.2.3.1.3 a 6.2.3.1.4. nižšie, pri každom lete, ktorý má prejsť cez hranicu oblastí pokrytia, v ktorých sa uplatňuje postup OLDI, sa odosiela jedna alebo viac správ ABI.

6.2.3.1.2. Ak sa správa ABI odosiela, tak pred správou o aktivácii (ACT) alebo správou o postúpení návrhu na aktiváciu (RAP).

6.2.3.1.3. Správa ABI sa negeneruje, ak sa má odoslať správa o predbežnej aktivácii (PAC).

6.2.3.1.4. Odporúčanie

Odvysielanie správy ABI by sa malo zablokovať, ak sa má okamžite alebo v obojstranne dohodnutom časovom intervale odvysielať správa ACT alebo RAP.

POZNÁMKA

Týmto odporúčaním sa sleduje, aby sa rôzne pracoviská na prijímajúcom stanovišti súčasne nepokúšali o odstránenie nezrovnalostí v správach ABI a ACT o jednom a tom istom lete.

6.2.3.1.5. Opravená správa ABI sa odošle, ak nebola generovaná ďalšia správa ACT a:

- trasa letu sa zmenila do tej miery, že COP uvedený v predchádzajúcej správe ABI už nie je presný,

- došlo k zmene cieľového letiska,

alebo

- došlo k zmene v type lietadla.

6.2.3.1.6. Odporúčanie

Opravená správa ABI by sa mala odoslať, ak nebola generovaná ďalšia správa ACT a zmenil sa jeden z týchto údajov:

- predpokladaná hladina preletu hranice,

- predpokladaný kód SSR v bode odovzdania riadenia letu,

- keď sa odhadovaný čas do preletu hranice (ETO) v bode COP líši od času uvedeného v predchádzajúcej správe ABI o viac, než ako je to uvedené v Dohode (LoA),

- iné údaje na základe obojstrannej dohody.

6.2.3.2. Spracovanie na prijímajúcom stanovišti

6.2.3.2.1. Systém riadenia leteckej prevádzky, ktorý prijíma určitú správu ABI, sa pokúsi priradiť ju k dátam o príslušnom letovom pláne.

6.2.3.2.2. Ak sa priradenie k príslušnému letovému plánu nepodarí, letový plán sa v prijímajúcom systéme vytvorí buď automaticky, alebo ručne.

6.2.3.2.3. Ak sa priradenie k letovému plánu podarí, no zároveň sa zistia určité rozpory medzi dátami obsiahnutými v správe a príslušnými dátami v prijímajúcom systéme, ktoré by si po príjme ďalšej správy ACT vyžiadali korekciu, tieto rozpory sa postúpia na vyriešenie príslušnému pracovisku.

6.2.3.3. Časové parametre prenosu

6.2.3.3.1. Správa sa odvysiela predpísaný počet minút pred odhadovaným časom v bode COP.

6.2.3.3.2. Parametre generovania ABI sa zahrnú do LoA medzi dotknutými stanovišťami riadenia leteckej prevádzky.

6.2.3.3.3. Odporúčanie

Parametre generovania ABI by mali byť:

- premenné, podľa ustanovení LoA,

- definované osobitne pre každý bod COP.

6.2.4. Potvrdenie príjmu ABI

6.2.4.1. Potvrdenie príjmu

Príjem správy ABI sa potvrdzuje generovaním a odvysielaním správy LAM.

POZNÁMKA

Správa LAM sa generuje bez ohľadu na výsledok pokusu o pridruženie správy k príslušnému letovému plánu.

6.2.4.2. Nepotvrdenie príjmu

Odporúčanie

Ak nepríde žiadna správa LAM, ktorou sa potvrdzuje príjem určitej správy ABI, na dozornom pracovisku by sa malo zobraziť výstražné upozornenie.

6.2.5. Príklady

"Let 2000" 253, Boeing 757 z Malty do Birminghamu odhaduje BNE VOR na 1221 UTC, letí na FL350 skutočnou rýchlosťou 480 uzlov, s plánovanou trasou cez UB4 BNE UB4 BPK UB3 HON, odpovedá na A7012 a požaduje FL390. Nižšie sú uvedené rovnocenné príklady odoslania správy ABI z Remešu do londýnskeho ACC.

6.2.5.1. ICAO

(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.2.5.2. ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.3. Správa o aktivácii (ACT)

6.3.1. Účel správy ACT

Správa ACT uspokojuje tieto prevádzkové požiadavky:

- nahrádza ústny odhad hranice tým, že ešte pred odovzdaní riadenia letu automatický prenáša presné údaje o lete z jedného stanovišťa riadenia leteckej prevádzky do druhého,

- podľa najnovších informácií aktualizuje základné dáta letového plánu na prijímajúcom stanovišti riadenia leteckej prevádzky,

- na prijímajúcom stanovišti riadenia leteckej prevádzky uľahčuje distribúciu a zobrazovanie dát letového plánu na dotknutých pracoviskách,

- urýchľuje zobrazovanie korelácie volacieho znaku/kódu na prijímajúcom stanovišti riadenia letovej prevádzky,

- prijímajúcemu stanovišťu riadenia leteckej prevádzky dodáva podmienky na odovzdanie riadenia letu.

6.3.2. Obsah správy

Správa ACT obsahuje tieto údaje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- režim a kód SSR,

- letisko odletu,

- dáta určené odhadom,

- cieľové letisko,

- číslo a typ lietadla,

- trasu (nepovinne),

- iné údaje o letovom pláne (nepovinne).

POZNÁMKA

Pravidlá týkajúce sa vkladania dát a obsahu polí sú uvedené v prílohe A.

6.3.3. Vykonávacie predpisy

6.3.3.1. Všeobecné ustanovenia

6.3.3.1.1. Pri letoch cez hranicu, ktoré na to majú nárok, sa odvysiela jedna správa ACT, s výhradou ustanovení odseku 6.3.3.1.10.

6.3.3.1.2. Správa ACT sa generuje a odvysiela automaticky vo vypočítanom čase, ako je to uvedené v LoA, pokiaľ sa jej odvysielanie už skôr nespustilo ručne.

6.3.3.1.3. Odporúčanie

Personál riadenia leteckej prevádzky by mal mať k dispozícii prostriedky na spustenie odvysielania správ ACT ešte skôr, než vo vypočítanom čase odvysielania.

6.3.3.1.4. Funkčný obsah správy ACT, určený na odvysielanie, sa zobrazí na pracovisku, ktoré zodpovedá za koordináciu letu pred tým, ako je správa naozaj odoslaná.

6.3.3.1.5. Odporúčanie

Pokiaľ ide o odsek 6.3.3.1.4., čas, v ktorom sa podľa výpočtu má správa ACT automaticky odoslať, by sa mal zobraziť spolu s jej obsahom.

6.3.3.1.6. Správa ACT obsahuje najnovšie informácie o lete a vyjadruje predpokladané výstupné podmienky.

6.3.3.1.7. Odvysielanie správy ACT sa oznámi príslušnému pracovisku.

6.3.3.1.8. Okamžite po prijatí správy LAM sa obe stanovištia riadenia leteckej prevádzky vo svojej činnosti musia riadiť dátami správy ACT. Podmienky koordinovaného odovzdania riadenia letu a skutočnosť, že bola prijatá správa LAM, sa oznámia personálu riadenia leteckej prevádzky na odovzdávajúcom stanovišti.

6.3.3.1.9. Pokiaľ prijímajúce stanovište nespustí koordináciu, aby sa upravili podmienky odovzdania riadenia, ktoré boli uvedené v správe ACT, predpokladá sa, že prijímajúce stanovište s nimi súhlasí.

6.3.3.1.10. Ďalšiu správu ACT možno tomu istému koordinačnému partnerovi odoslať len za predpokladu, že predchádzajúca bola zrušená použitím správy MAC.

6.3.3.1.11. Pokiaľ sa to dvojstranne dohodne, správa zahŕňa aj trasu a iné údaje o letovom pláne.

6.3.3.2. Spracovanie na prijímajúcom stanovišti

6.3.3.2.1. Systém riadenia leteckej prevádzky, ktorý prijal určitú správu ACT, sa pokúsi o jej priradenie k príslušnému letovému plánu.

6.3.3.2.2. Ak sa príslušný letový plán nájde a správa neobsahuje žiadne nezrovnalosti, ktoré by bránili správnemu spracovaniu:

- funkčný obsah sa zahrnie do letového plánu,

- požadované dáta sa vo forme výstupu zobrazia na pracovisku riadenia leteckej prevádzky alebo na inom vhodnom pracovisku,

- LAM sa zašle späť.

6.3.3.2.3. Ak sa príslušný letový plán nedá nájsť, alebo ak sa zistí odlišnosť, pre ktorú nemožno správu správne spracovať:

- ak sa dá zistiť, ktorý sektor zodpovedá za prevzatie riadenia letu:

- funkčný obsah správy sa zobrazí v tomto sektore,

- LAM sa zašle späť,

- vytvorí sa letový plán,

- vo všetkých ostatných prípadoch sa LAM späť nezašle.

6.3.3.3. Parametre prenosu

6.3.3.3.1. Správa sa odošle v skoršom z časov, ktoré sa určili podľa nižšie uvedeného, alebo čo najskôr po ňom:

- predpísaný počet minút pred odhadovaným časom v bode COP,

- v čase, v ktorom sa lietadlo nachádza vo dvojstranne dohodnutej vzdialenosti od bodu COP.

6.3.3.3.2. Parametre generovania ACT sa zahrnú do LoA medzi dotknutými stanovišťami riadenia leteckej prevádzky.

6.3.3.3.3. Parametre generovania ACT sú premenné podľa ustanovení LoA.

6.3.3.3.4. Odporúčanie

Parametre generovania ACT by sa mali definovať osobitne pre každý bod COP.

6.3.3.3.5. Predpísané parametre musia poskytovať dostatočný čas na to:

- aby odovzdávajúce stanovište aktualizovalo hladinu letu pri odovzdávaní podľa podmienok predpokladaných v bode COP,

a

- aby prijímajúce stanovište spracovalo správu ACT a generovalo a odvysielalo správu LAM a naviac aby odovzdávajúce stanovište uskutočnilo ústnu koordináciu a výslednú operáciu, ktorú spustí prijímajúce stanovište, ak sa výmena údajov nepodarí.

6.3.4. Potvrdenie príjmu ACT

6.3.4.1. Potvrdenie príjmu

Príjem správy ACT sa potvrdzuje generovaním a odvysielaním správy LAM.

6.3.4.2. Nepotvrdenie príjmu

Ak nepríde správa LAM, potvrdzujúca príjem správy ACT, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu, sa zobrazí výstražná správa.

6.3.5. Príklady

Tieto príklady nadväzujú na príklady týkajúce sa správy ABI v odseku 6.2; všetky údaje sú rovnaké, s výnimkou ETO v bode COP, ktorý má v tu uvádzanej správe hodnotu 1226.

6.3.5.1. ICAO

(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.3.5.2. ADEXP

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757-ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.4. Správa o logickom potvrdení príjmu (LAM)

6.4.1. Účel správy LAM

LAM predstavuje prostriedok, pomocou ktorého prijímajúce stanovište oznamuje odosielajúcemu stanovišťu príjem a zabezpečenie odvysielanej správy.

Spracovaním správy LAM sa personálu riadenia letovej prevádzky na odovzdávajúcom stanovišti poskytuje toto:

- výstražná správa v prípade, že nebol potvrdený príjem odvysielanej správy,

- oznámenie, že predmetná správa bola prijatá, úspešne spracovaná, bezchybná, uložená a tam, kde je to dôležité, že je pripravená na zobrazenie na príslušných pracoviskách.

6.4.2. Obsah správy

Správa LAM obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy.

POZNÁMKA

Pravidlá pre vkladanie dát, formáty a obsah polí sú uvedené v Prílohe A.

6.4.3. Vykonávacie predpisy

6.4.3.1. Všeobecné ustanovenia

6.4.3.1.1. Predpisy týkajúce sa spätného odosielania LAM sú uvedené v oddieloch tohto dokumentu, kde sa definuje spracovanie každého druhu správy.

6.4.3.1.2. Správa LAM sa generuje a vysiela bez zásahu človeka.

6.4.3.1.3. Správa LAM sa nepoužíva ako náhrada za technické správy, ktorými sa zabezpečuje úplnosť odvysielaných dát.

6.4.3.1.4. Správa LAM sa generuje a odvysiela okamžite, aby sa v súvislosti so správou, ktorej príjem sa potvrdzuje, dodržal predpísaný transakčný čas.

6.4.3.1.5. Ak správa LAM nebola prijatá v čase predpísanom pre takéto výstražné správy, pokiaľ nejde o správu ABI, odovzdávajúci systém riadenia leteckej prevádzky to oznámi dispečerovi zodpovednému za koordináciu.

6.4.4. Potvrdenie príjmu LAM

Správa LAM si nevyžaduje potvrdenie príjmu.

6.4.5. Príklady

6.4.5.1. ICAO

(LAML/E012E/L001)

6.4.5.2. ADEXP

-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 012 -MSGREF -SENDER -FAC E RECVR -FAC L -SEQNUM 001

7. ZÁKLADNÝ POSTUP - DODATKOVÉ SPRÁVY

7.1. Všeobecné informácie

7.1.1. Požiadavky

V tomto oddieli sa popisujú prostriedky využiteľné v rámci základného postupu, ktoré dopĺňajú prostriedky uvedené v oddieli 6 Základný postup - povinné správy.

7.1.2. Používanie

7.1.2.1. Skôr ako sa zavedú prostriedky, ktoré sa popisujú v tomto oddieli, ich používanie sa dvojstranne dohodne.

7.1.2.2. V prípade, že sa používanie týchto prostriedkov dohodne, platia predpisy uvedené v tomto oddieli.

7.2. Správa o predbežnej aktivácii (PAC)

7.2.1. Účel správy PAC

Správa PAC uspokojuje tieto prevádzkové požiadavky:

- hlásenie o lete a jeho koordinácia pred odletom v prípade, že čas letu od odletu po bod COP je kratší než čas, ktorý by bol potrebný na dodržanie dohodnutých časových parametrov pre odvysielanie správy ACT,

- hlásenie o lete a jeho koordinácia pred odletom miestnym (letištným/približovacím) stanovišťom, v súčinnosti s ďalším stanovišťom, ktoré má prevziať riadenie letu.,

- získanie chýbajúcich údajov o letovom pláne v prípade, že pri počiatočnej distribúcii dát letového plánu sa vyskytli nezrovnalosti,

- v prípade potreby vyžiadanie kódu SSR od stanovišťa, ktorému sa vyššie uvedené hlásenie/koordinačné údaje odosielajú.

7.2.2. Obsah správy

Správa PAC obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy (nepovinne),

- identifikačné údaje lietadla,

- režim a kód SSR,

- letisko odletu,

- odhadovaný čas odletu alebo dáta určené odhadom,

- cieľové letisko,

- typ lietadla,

- trasa (nepovinne),

- iné údaje o letovom pláne (nepovinne).

7.2.3. Vykonávacie predpisy

7.2.3.1. Všeobecné ustanovenia

7.2.3.1.1. Pri každom plánovanom lete cez hranicu oblastí pokrytia, kde čas od odletu do dosiahnutia COP je tak krátky, že v požadovanom čase sa nestihne odoslať správa ACT, sa odošle jedna alebo viac správ PAC.

7.2.3.1.2. Pri každom lete, ktorý je potrebné hlásiť alebo koordinovať, letisko/približovacie stanovište odošle ďalšiemu stanovišťu jednu alebo dve správy PAC.

7.2.3.1.3. Odporúčanie

Na používanie správ PAC/LAM medzi stanovišťami by sa mali príslušné systémy TWR/APP vybaviť prostriedkami na vkladanie a odosielanie príkazov ako napr. "roztočiť", "ustúpiť", "rolovať" alebo podobných informácií, z ktorých možno odvodiť ETOT na vypočítanie ETO v bode COP a spustenie prenosu správy PAC.

7.2.3.1.4. Podľa toho, ako sa to dvojstranne dohodlo, správa obsahuje buď:

- odhadovaný čas vzlietnutia,

alebo

- dáta stanovené odhadom.

7.2.3.1.5. Ak sa na základe dvojstrannej dohody uvádza značka správy,:

- obsahuje číslo prvej odoslanej správy PAC o danom lete,

- uvedie sa v druhej a ďalších správach PAC.

7.2.3.1.6. Ak sa to vyžaduje, obojstranne sa dohodne prostriedok na vyžiadanie kódu.

7.2.3.1.7. Opravená správa PAC sa odosiela, ak pred odletom platí jedna z týchto podmienok:

- trasa letu sa zmenila natoľko, že COP uvedený v predchádzajúcej správe už nie je presný,

- došlo k zmene typu lietadla,

- zistilo sa, že cieľové letisko je v predchádzajúcej správe PAC uvedené nesprávne.

7.2.3.1.8. Odporúčanie

Opravená správa PAC by sa mala odoslať, ak sa v porovnaní s predchádzajúcou správou PAC pred odletom vyskytli nezrovnalosti v týchto údajoch:

- hladina (v údajoch určených odhadom, ak existujú),

- predpokladaný kód SSR v bode odovzdávania riadenia letu,

- odhadovaný čas vzlietnutia alebo ETO v bode COP, ak rozdiel prevyšuje dvojstranne dohodnutú hodnotu,

- zmenili sa iné dvojstranne dohodnuté údaje..

7.2.3.2. Spracovanie na prijímajúcom stanovišti

7.2.3.2.1. Systém riadenia leteckej prevádzky, ktorý prijal správu PAC, sa pokúsi o jej priradenie k príslušnému letovému plánu.

7.2.3.2.2. Ak sa príslušný letový plán nájde a správa neobsahuje žiadne odlišnosti, ktoré by bránili jej správnemu spracovaniu:

- funkčný obsah správy sa zahrnie do letového plánu,

- požadované dáta sa vydajú cez výstup na pracovisku riadenia leteckej prevádzky alebo na iných vhodných pracoviskách,

- správa LAM sa zašle späť.

7.2.3.2.3. Ak príslušný letový plán nemožno nájsť, alebo ak sa zistí rozpor, ktorý bráni správnemu spracovaniu:

- ak je možné zistiť, ktorý sektor zodpovedá za prevzatie riadenia letu:

- funkčný obsah správy sa zobrazí v tomto sektore,

- správa LAM sa zašle späť,

- vytvorí sa letový plán,

- vo všetkých ostatných prípadoch sa správa LAM späť nezašle.

7.2.3.2.4. Dáta obsiahnuté v druhej a ďalších správach PAC nahradia dáta z predchádzajúcej správy.

7.2.3.2.5. Ak správa PAC obsahuje žiadosť o pridelenie kódu SSR a dá sa správne spracovať, ako je to uvedené v odseku 7.2.3.2.2. vyššie, okrem správy LAM sa späť zašle aj správa COD.

POZNÁMKA

Vzhľadom na to, že na pridelenie kódu COD sú potrebné presné informácie o trase zapísanej v letovom pláne, v tomto dokumente sa od prijímajúceho stanovišťa nevyžaduje, aby zasielalo späť správu COD, ak takéto údaje o lete nie sú k dispozícii. Napriek tomu možno správu za týchto podmienok zaslať späť, ak na to na určitom mieste existuje spôsobilosť a na tomto postupe sa dvojstranne dohodlo.

7.2.3.3. Časové parametre prenosu

Časový parameter prenosu sa neuplatňuje, keďže správa sa odosiela v nadväznosti na ručne vloženú správu, ktorá identifikuje bezprostredný odlet lietadla.

7.2.4. Potvrdenie príjmu PAC

7.2.4.1. Potvrdenie príjmu

Správy, ktoré sa odosielajú v odpovedi na správu PAC, sú uvedené v odseku 7.2.3.2. vyššie.

7.2.4.2. Nepotvrdenie príjmu

Ak nepríde žiadna správa, potvrdzujúca príjem správy PAC, na pracovisku stanovišťa riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu s ďalším stanoviskom, sa zobrazí výstražná správa.

7.2.4.3. Nepoužívanie LAM

V prípadoch, v ktorých sa správa LAM nepoužíva, sa spustí ústna koordinácia.

7.2.4.4. Neodoslanie správy COD

7.2.4.4.1. Ak sa na žiadosť o pridelenie kódu, ktorú obsahuje správa PAC, nereaguje odoslaním správy COD, na príslušnom pracovisku sa zobrazí výstražná správa.

7.2.4.4.2. V prípade, že sa má použiť funkcia žiadosti o pridelenie kódu, uplatňuje sa dvojstranne dohodnutý prevádzkový prestoj.

7.2.5. Príklady

7.2.5.1. Odhadovaný čas vzlietnutia a žiadosť o pridelenie kódu

7.2.5.1.1. ICAO

(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)

7.2.5.1.2. ADEXP

-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP LFSB -ETOT 1638 -ARCTYP b737 -ADES LSZA

7.2.5.2. Čas v bode 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. Správa o korekcii dát (REV)

7.3.1. Účel správy

Správa REV sa používa na prenos korigovaných koordinačných dát, ktoré boli odoslané v niektorej predchádzajúcej správe ACT za predpokladu, že v dôsledku zmeny sa nezmení aj prijímajúce stanovište.

7.3.2. Obsah správy

Správa REV obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy (nepovinne),

- identifikačné údaje o lietadle,

- režim a kód SSR (nepovinne),

- letisko odletu,

- dáta určené odhadom,

- koordinačný bod (nepovinne),

- cieľové letisko,

- trasu (nepovinne),

- iné údaje o letovom pláne (nepovinne).

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

7.3.3. Vykonávacie predpisy

7.3.3.1. Všeobecné ustanovenia

7.3.3.1.1. Stanovišťu, do ktorého bol pomocou správy o aktivácii práve skoordinovaný určitý let, možno odoslať jednu alebo viacero správ REV.

7.3.3.1.2. Korekcii podliehajú tieto prvky:

- ETO v bode COP,

- hladiny odovzdania riadenia letu,

- kód SSR.

7.3.3.1.3. Správa REV sa odosiela v týchto prípadoch:

- keď ETO a COP sa oproti údajom v predchádzajúcej správe líšia o viac než dvojstranne dohodnutú hodnotu, zaokrúhlenú na najbližšie celé číslo,

- keď sa zmenia hladiny odovzdávania riadenia letu alebo SSR.

7.3.3.1.4. Ak sa to dvojstranne dohodne, správa REV sa odosiela, keď sa zmení toto:

- COP,

- trasa,

- iné údaje o letovom pláne (dáta ICAO o poliach 8, 10 a 18).

POZNÁMKA

V prevádzkových predpisoch s a môže vyžadovať, aby zmeny, ktoré sa uskutočnili po ACT, boli najprv predmetom koordinácie medzi dotknutými stanovišťami.

7.3.3.1.5. Ak sa to dvojstranne dohodlo, správa REV obsahuje aj značku správy.

7.3.3.1.6. Ak sa uvádza značka správy, obsahuje číslo predchádzajúcej správy ACT.

7.3.3.1.7. Pokiaľ prijímajúce stanovište riadenia leteckej prevádzky nespustí koordináciu za účelom úpravy podmienok odovzdania riadenia letu podľa správy REV, bude sa to považovať za jej súhlas s týmito podmienkami.

7.3.3.2. Formátovanie správ o korekcii údajov

7.3.3.2.1. Formát ICAO

Všetky správy o korekcii údajov obsahujú typy polí 3, 7, 13, 14 a 16. V rámci spomínaných polí možno uskutočniť korekcie týchto údajov:

- zmena ETO v bode COP alebo zmena hladiny odovzdávania riadenia letu sa začlení tak, že opravené údaje sa zaradia do poľa 14,

- zmena kódu SSR sa zaradí do poľa 7,

- zmeny trasy, vrátane zmien bodu COP, sa začlenia medzi dáta polí 14 a 15, zahrnutých vo formáte poľa 22, nasledujúcom po prvých piatich poliach. Takéto správy zahrňujú dve polia 14, pričom prvé obsahuje len zložku a), bod COP, cez ktorý sa predtým let koordinoval. Predpisy pre koordináciu takýchto zmien, vrátane priameho vymedzenia trasy, sú uvedené v prílohe B Osobitné požiadavky na spracovanie trasy,

- zmeny v poliach 8, 10 a 18 sa začleňujú ako dáta poľa 22 po prvých piatich poliach.

7.3.3.2.2. Formát ADEXP

Všetky správy o korekcii dát vo formáte ADEXP obsahujú tieto primárne polia: TITLE REFDATA ARCID ADEP ADES. Pritom platia tieto predpisy:

- zmena ETO alebo hladiny odovzdávania riadenia letu sa začlení tak, že opravené údaje sa zaradia do primárneho poľa COORDATA,

- zmeny trasy, vrátane zmien bodu COP, sa začleňujú do primárnych polí COORDATA a ROUTE. Takéto správy zahŕňajú primárne pole COP, ktoré obsahuje koordinačný bod, cez ktorý sa predtým koordinoval let. Predpisy pre koordináciu takýchto zmien, vrátane priameho vymedzovania trasy, sú uvedené v prílohe B,

- zmena kódu SSR sa uvedie zaradením primárneho poľa SSRCODE,

- zmeny dát letového plánu sa začleňujú zaradením požadovaných primárnych polí, ako je to definované pre ostatné dáta letového plánu v prílohe A.

Ak sa správa o korekcii dát odosiela len na koordináciu kódu SSR a/alebo ostatných dát letového plánu, namiesto primárneho poľa COORDATA sa zaradí primárne pole COP.

7.3.3.2.3. Kód SSR

Režim a kód SSR sa do správy REV zaradí len v prípade, že je potrebné skoordinovať zmenu kódu SSR.

7.3.3.3. Spracovanie na prijímajúcom stanovišti

7.3.3.3.1. Ak správa ACT o predmetnom lete prišla z toho istého stanovišťa riadenia leteckej prevádzky, systém riadenia leteckej prevádzky, ktorý správu REV prijíma, sa pokúsi o jej priradenie k príslušnému letovému plánu.

7.3.3.3.2. Ak sa príslušný letový plán nájde a v správe sa nevyskytne žiadna odlišnosť, ktorá by bránila jej správnemu spracovaniu:

- funkčný obsah správy sa začlení do letového plánu,

- požadované dáta sa vydajú cez výstup na pracovisku riadenia leteckej prevádzky alebo prípadne na iných pracoviskách.

7.3.3.4. Spustenie prenosu

7.3.3.4.1. Správa REV sa spúšťa v dôsledku inej udalosti a odvysiela sa okamžite po príslušnom vstupe alebo aktualizácii.

7.3.3.4.2. Prostredníctvom správy REV nemožno uskutočniť žiadne zmeny po tom, čo sa lietadlo ocitlo v predpísanej vzdialenosti a čase od bodu odovzdania riadenia. Predpísaný čas a vzdialenosť sa obojstranne dohodnú.

7.3.3.4.3. Odporúčanie

Parametre REV by sa mali určiť pre každý COP osobitne.

7.3.3.5. Zmena prijímajúceho stanovišťa ATC

Správa REV sa nepoužije, ak zmena v dátach letového plánu znamená aj zmenu prijímajúceho stanovišťa riadenia leteckej prevádzky (pozri Správu o zrušení koordinácie).

7.3.4. Potvrdenie príjmu REV

7.3.4.1. Potvrdenie príjmu

Ak správu REV:

- možno v rámci prijímajúceho systému priradiť k niektorému letovému plánu, príjem správy sa potvrdí odvysielaním správy LAM,

- nemožno v rámci prijímajúceho systému priradiť k niektorému letovému plánu, správa LAM sa neodvysiela.

7.3.4.2. Nepotvrdenie príjmu

7.3.4.2.1. Ak správa, ktorou by sa potvrdil príjem správy REV, nepríde, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letov, sa zobrazí výstražná správa.

7.3.4.2.2. V prípadoch, keď sa správa LAM neodosiela, odovzdávajúce stanovište riadenia leteckej prevádzky spustí ústnu korekciu.

7.3.5. Príklady

7.3.5.1. ICAO

a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)

b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)

7.3.5.2. ADEXP

a) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

b) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML - COP BNE -ADES EGBB -SSRCODE A2317

7.4. Správa o zrušení koordinácie (MAC)

7.4.1. Účel správy MAC

Správou MAC sa prijímajúcemu stanovišťu oznamuje, že predchádzajúca koordinácia alebo hlásenie o určitom lete sa ruší.

Správa MAC nenahrádza správu o zrušení letového plánu (CNL), ako ju definuje ICAO, a preto sa nepoužíva na výmaz základných dát letového plánu.

7.4.2. Obsah správy

Správa MAC obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy (nepovinne),

- identifikačné údaje lietadla,

- letisko odletu,

- koordinačný bod,

- cieľové letisko,

- funkciu a dôvod zrušenia koordinácie (nepovinné).

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

7.4.3. Vykonávacie predpisy

7.4.3.1. Všeobecné ustanovenia

7.4.3.1.1. Správa MAC sa odosiela stanovišťu, s ktorým sa predtým koordinovalo riadenie určitého letu použitím správy ACT alebo RAP, ak sa stane jedna z týchto udalostí:

- predpokladaná hladina v bode odovzdávania riadenia letu sa odlišuje od hladiny uvedenej v predchádzajúcej správe, čo má za následok zmenu najbližšieho stanovišťa v koordinačnom slede,

- zmenila sa trasa letu, čo má za následok zmenu najbližšieho stanovišťa v koordinačnom slede,

- na odosielajúcom stanovišti sa zruší systémový letový plán a koordinácia viac nemá význam,

- príde správa MAC o lete z predchádzajúceho stanovišťa.

7.4.3.1.2. Keď sa správa MAC odosiela kvôli zmene letovej hladiny alebo trasy, hlásenie alebo koordinácia sa uskutoční s novou jednotkou v koordinačnom slede.

7.4.3.1.3. Správa MAC sa odosiela v prípade, že sa ruší koordinácia odlietajúceho lietadla, ktorá sa uskutočnila použitím správy PAC.

7.4.3.1.4. Odporúčanie

Správa MAC by sa mala odoslať, keď sa predchádzajúce hlásenie (správa ABI) o lete zruší z dôvodov uvedených v odseku 7.4.3.1.1. vyššie. Alebo ak s a let na trase zdrží a korigovaný odhad nemožno určiť automaticky.

7.4.3.1.5. Ak sa to dvojstranne dohodne, uvedie sa aj značka správy.

7.4.3.1.6. Ak sa uvádza aj značka správy, obsahuje číslo poslednej správy ABI, PAC alebo ACT o lete, ktorá sa odvysielala, alebo ktorej príjem sa potvrdil.

7.4.3.1.7. Koordinačným bodom je ten, cez ktorý sa predtým uskutočňovalo hlásenie o lete alebo jeho koordinácia.

7.4.3.1.8. Odporúčanie

V správe MAC by sa malo uvádzať, ako sa má zmeniť funkcia koordinácie alebo hlásenie a z akého dôvodu boli zrušené.

7.4.3.1.9. Ak sa uvádza funkcia a dôvod zrušenia, tak v jednej z týchto kombinácií:

- keď prijímajúca jednotka prestala byť najbližším koordinačným partnerom:

- funkcia je INI (počiatočná),

- dôvodom jeden z týchto:

- TFL, ak je dôvodom zmena hladiny odovzdania riadenia letu,

- RTE, ak je dôvodom zmena trasy,

- CSN, ak je dôvodom zmena volacieho znaku,

- CAN, ak je dôvodom zrušenie letového plánu,

- OTH, z akéhokoľvek iného dôvodu, alebo ak dôvod nie je známy,

- keď platí jedna z týchto podmienok:

- koordinácia, ktorá sa uskutočnila použitím predchádzajúcej správy PAC alebo ACT (upravenej ďalšou správou REV), sa zrušila, ale predpokladá sa, že let bude predmetom novej koordinácie .s tým istým stanovišťom,

alebo

- po odvysielaní správy ABI sa let na neurčitú dobu zdržiava a očakáva sa, že sa o ňom odošle korigovaná správa ABI alebo ACT:

- funkcia je NTF (hlásenie),

- dôvodom jeden z týchto:

- DLY, ak je dôvodom meškanie,

- HLD, ak je dôvodom zdržanie,

- OTH z akéhokoľvek iného dôvodu, alebo ak dôvod nie je známy.

7.4.3.1.10. Ak má byť let znovu predmetom hlásenia alebo koordinácie:

- odošle sa nová správa o hlásení, resp. koordinácii,

- správa MAC neovplyvní základné dáta letového plánu uložené na prijímajúcom stanovišti riadenia leteckej prevádzky,

- systém si zachová schopnosť správne spracovať novú správu o hlásení alebo koordinácii, buď od predchádzajúceho odovzdávajúceho stanovišťa alebo od iného stanovišťa v novom koordinačnom slede.

7.4.3.2. Spracovanie na prijímajúcom stanovišti

Pracoviskám na prijímajúcom stanovišti riadenia leteckej prevádzky, ktorým sa poskytujú údaje o lete, bude zrušenie koordinácie oznámené.

7.4.4. Potvrdenie príjmu MAC

7.4.4.1. Potvrdenie príjmu

7.4.4.1.1. Ak správu MAC možno priradiť k niektorému letovému plánu v prijímajúcom systéme a ak ju možno spracovať, jej príjem sa potvrdí odoslaním správy LAM.

7.4.4.1.2. Ak správu MAC nemožno priradiť k letovému plánu v prijímajúcom systéme, alebo ak ju nemožno spracovať, správa LAM sa neodošle.

7.4.4.2. Nepotvrdenie príjmu

7.4.4.2.1. Ak sa koordinácia riadenia leteckej prevádzky ruší a žiadna správa LAM neprichádza, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu, sa zobrazí výstražná správa.

7.4.4.2.2. V takýchto prípadoch odovzdávajúce stanovište riadenia leteckej prevádzky zruší koordináciu ručne.

7.4.5. Príklady

Amsterdamské ACC odoslalo bruselskému ACC správu ABI o lete HOZ3188, plánovanom na FL190 letovej hladine), let neskôr požaduje vzostup na FL270 a je mu to povolené, čím namiesto do bruselského, vstupuje do maastrichtského vzdušného priestoru. Príklady 7.4.5.1. a a 7.4.5.2. a znázorňujú, akú podobu by správa MAC, odoslaná z Amsterdamu do Bruselu, mala vo formátoch ICAO a ADEXP.

Do Maastrichtu sa odošle správa ABI a neskôr aj správa ACT, ibaže niekoľko minút pred dosiahnutím COP sa lietadlo vracia na amsterdamské letisko a na odosielajúcom stanovišti sa letový plán zruší; do Maastrichtu sa odošle správa MAC, ako je uvedená v príkladoch (7.4.5.1. b a 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-LPFG-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. Správa o pridelení kódu SSR (COD)

7.5.1. Účel správy COD

7.5.1.1. V záujme toho, aby určitý let mohol v tom istom kóde odpovedať po sebe nasledujúcim stanovištiam v účastníckej oblasti, sa uplatňuje metóda prideľovania kódu východzej oblasti. Pokiaľ sa kódy neprideľujú centrálne, napríklad, ak ho neprideľujú stredisko ACC, môže sa stať, že letiská potrebujú, aby im bol každému osobitne pridelený súbor tajných kódov SSR. Pri takomto spôsobe prideľovania sa použije zbytočne veľké množstvo kódov.

7.5.1.2. Správa COD uspokojuje prevádzkovú požiadavku na to, aby jedno stanovište služby leteckej dopravy mohlo na požiadanie vydať druhému na udaný let kód SSR v režime A. Ak sa to dvojstranne dohodne, nepovinný prostriedok umožňuje, aby vydávajúce stanovište uvádzalo aj trasu letu.

7.5.2. Obsah správy

Správa COD obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy (nepovinne),

- identifikačné údaje lietadla,

- režim a kód SSR,

- letisko odletu,

- cieľové letisko,

- trasu (nepovinne).

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

7.5.3. Vykonávacie predpisy

7.5.3.1. Všeobecné ustanovenia

7.5.3.1.1. Správa COD sa generuje a vysiela automaticky v odpovedi na žiadosť o pridelenie kódu obsiahnutú v určitej správe.

7.5.3.1.2. Kód SSR je kód, ktorý sa pridelí danému letu.

7.5.3.1.3. Schválený saturačný kód, ako je to uvedené v Pláne leteckej navigácie pre oblasť Európy, sa vkladá, ak tajný kód nie je k dispozícii.

7.5.3.1.4. Ak sa to dvojstranne dohodne, uvádza sa aj značka správy, ktorá obsahuje číslo správy, na ktorú reaguje správa COD.

7.5.3.1.5. Trasa sa uvádza, ako sa to dvojstranne dohodne.

7.5.3.1.6. Predpokladá sa, že stanovište, ktoré prijíma správu COD, pridelený SSR kód akceptuje.

7.5.3.2. Spracovanie na prijím ajúcom stanovišti

7.5.3.2.1. Za predpokladu, že správa neobsahuje žiadnu nezrovnalosť, ktorá by bránila správnemu spracovaniu, zašle sa späť správa LAM.

7.5.3.2.2. Ak správu nemožno priradiť k niektorému letovému plánu, alebo ak sa zistí nezrovnalosť, ktorá bráni správnemu spracovaniu správy, LAM sa späť nezašle.

7.5.3.2.3. Pokiaľ sa uvádzajú aj údaje o trase, nebráni to spätnému odoslaniu správy LAM, ak jej formát vyhovuje požiadavkám podľa prílohy A.

7.5.3.3. Časové parametre prenosu

Časový parameter prenosu sa neuplatňuje, keďže správa COD sa odosiela v reakcii na príjem správy, v ktorej sa požaduje pridelenie kódu SSR.

7.5.4. Potvrdenie príjmu COD

7.5.4.1. Potvrdeni príjmu

Príjem správy COD sa potvrdí generovaním a odvysielaním správy LAM.

7.5.4.2. Nepotvrdenie príjmu

Ak nepríde správa LAM, potvrdzujúca príjem správy COD. Na príslušnom pracovisku sa zobrazí výstražná správa.

7.5.5. Príklady

7.5.5.1. ICAO

(CODP/PO011 -AAL905/A0767-LFPO-KEWR)

7.5.5.2. ADEXP

-TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO -SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905 -SSRCODE A0767

7.6. Informatívna správa (INF)

7.6.1. Účel správy INF

7.6.1.1. Správa INF poskytuje informácie o konkrétnych letoch subjektom, ktoré sa priamo nezúčastňujú na koordinácii medzi dvoma po sebe nasledujúcimi stanovišťami riadenia leteckej prevádzky na trase letu.

7.6.1.2. Správou INF možno poskytnúť kópie správ a oznámiť dohodnuté podmienky koordinácie subjektom, ktoré sledujú dialóg medzi dispečermi. Na tento účel môžu správy INF generovať systémy na odovzdávajúcom alebo prijímajúcom stanovišti.

7.6.1.3. Tento druh správy možno použiť aj na poskytnutie informácií určitému subjektu o ktoromkoľvek bode na trase letu.

7.6.1.4. Tento formát umožňuje oznámiť počiatočné dáta, korekcie a zrušenie letových plánov.

7.6.2. Obsah správy

Správa INF obsahuje tieto údaje vo formáte správy, ktorý sa popisuje v tomto dokumente:

- typ správy,

- číslo správy,

- všetky prevádzkové údaje obsiahnuté v pôvodnej správe alebo výslednú koordináciu, ktorá sa reprodukuje,

- typ správy obsahujúcej odkaz.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

7.6.3. Vykonávacie predpisy

7.6.3.1. Typy správ

Typy správ, ktoré správa INF reprodukuje, sú určené požiadavkami užívateľov a možnosťami odosielajúcej jednotky. Typy správ a vykonávacie predpisy budú spravidla predmetom obojstrannej dohody.

7.6.3.2. Príjemcovia správ

O jednom lete možno jednému alebo viacerým príjemcom odoslať jednu alebo viacero správ INF.

7.6.3.3. Funkčný obsah

Funkčný obsah správy INF má formát jednej z existujúcich správ.

7.6.3.4. Odporúčania

1. Podmienky, ktoré boli zaslané v prvej dialógovej správe (napr. správy ACT, RAP, REV, RRV) možno pred ukončením dialógu zmeniť. Odosielajúce stanovištia by mali byť schopné odoslať konečné, odsúhlasené podmienky koordinácie.

2. Správa INF by sa mala odoslať okamžite alebo v čase odvodenom od času v COP, čo sa dohodne s prijímajúcim subjektom.

7.6.4. Potvrdenie príjmu INF

Odporúčania

1. Príjem správy INF možno potvrdiť v závislosti od koordinačného partnera generovaním a odvysielaním správy LAM.

2. S výhradou obojstrannej dohody medzi dotknutými stanovišťami, ak nepríde žiadna správa potvrdzujúca príjem správy INF, na príslušnom pracovisku by sa mala zobraziť výstražná správa.

7.6.5. Príklady

Let s volacím znakom BAW011, B747 z EGLL do OMDB na FL290, požadujúci FL410, odhaduje Koksy (KOK) VOR na 1905, odpovedá na A5437, pokračuje cez UG1 a UB6.

O tomto lete sa z Londýna odošle správa do Maastrichtu. Kópia sa z Londýna odošle na stanovište, ktoré sa identifikuje ako IT.

Nižšie sú uvedené príklady správy INF.

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. DIALÓGOVÝ POSTUP - KOORDINÁCIA

8.1. Všeobecné ustanovenia

8.1.1. Úvod

8.1.1.1. Dialógový postup poskytuje prostriedky na komunikáciu a dohováranie medzi dispečermi v koordinačnej fáze a na komunikáciu vo fáze odovzdávania riadenia.

8.1.1.2. V tejto časti sa popisujú správy, ktoré sa používajú v dialógovom postupe v koordinačnej fáze, keď sa plánujú podmienky odovzdania riadenia letu. Tie, ktoré sa používajú vo fáze odovzdávania, keď sa dokončí odovzdanie riadenia letu, sú popísané v oddieli 9 - Dialógový postup - odovzdanie spojenia.

8.1.1.3. Postupy platné pre tieto dve fázy nezávisia jeden od druhého; možno ich vykonávať osobitne alebo súčasne.

8.1.1.4. Zavádza sa viacero dodatkových druhov správ a zabezpečuje schopnosť každého partnera spustiť dialóg.

8.1.1.5. Koordinačný dialógový postup umožňuje identifikovať:

- odovzdávanie riadenia letov, ktoré sú v súlade s LoA a ktoré možno prijať automaticky, a

- odovzdávanie riadenia letov, ktoré je potrebné postúpiť dispečerovi na prijímajúcom stanovišti, aby rozhodol, či ho prebrať.

8.1.1.6. Vďaka tomuto postupu možno takisto monitorovať výklad LoA v rámci oboch systémov a identifikovať prípadné nezrovnalosti medzi nimi.

8.1.2. Filter

8.1.2.1. Všeobecné informácie

8.1.2.1.1. Koordinačný dialógový systém vyžaduje, aby systémy zistili, či odovzdávanie riadenia letov je alebo nie je v súlade s LoA.

8.1.2.1.2. Proces, ktorým sa takýto súlad kontroluje, sa v tomto dokumente nazýva "filter". Ak sa to vyžaduje, databáza filtra bude zahŕňať toto:

- dohodnuté koordinačné body,

- spôsobilé (alebo nespôsobilé) letové hladiny, ktoré možno takisto priradiť ku koordinačným bodom,

- letisko odletu,

- cieľové letiská,

- dohodnuté priame trasy,

- medzné časy alebo vzdialenosti pred COP, po ktorom sa každá koordinačná správa považuje za neštandardnú,

- iné dvojstranne dohodnuté podmienky.

8.1.2.1.3. Všetky údaje uvedené v tomto zozname môžu vo vzájomných kombináciách definovať zložitejšie podmienky.

8.1.2.1.4. V oddieli 8 tohto dokumentu sa termín "štandardné podmienky" chápe ako "v súlade s LoA" a termín "neštandardné podmienky" ako "v nesúlade s LoA". Pokiaľ sa to dvojstranne nedohodne, odovzdávajúce stanovištia odosielajú v rámci koordinácie, o ktorej sa vie, že je štandardná, iné typy správ, než v prípade neštandardných koordinačných podmienok.

8.1.2.2. Činnosť na odovzdávajúcom stanovišti

8.1.2.2.1. Filter na odovzdávajúcom stanovišti preskúma podmienky odovzdania, ktoré sa práve majú odoslať prijímajúcej jednotke.

8.1.2.2.2. Odporúčanie

Ak sa zistí, že podmienky odovzdania riadenia sú neštandardné, na túto skutočnosť by mal byť upozornený odovzdávajúci dispečer, aby ich potvrdil alebo zmenil.

8.1.2.3. Činnosť na prijím ajúcom stanovišti

8.1.2.3.1. Všetky správy ACT a REV sa kontrolujú cez filter.

8.1.2.3.2. Ak sa kontrolou zistí, že prijaté podmienky odovzdania riadenia nie sú štandardné, postúpia sa na rozhodnutie dispečerovi, v opačnom prípade sa automaticky akceptujú.

8.1.2.4. Synchronizácia filtrov

8.1.2.4.1. Vďaka tomu, že pre štandardné podmienky odovzdania riadenia letu sa používajú iné správy než pre neštandardné, možno zistiť všetky nezrovnalosti medzi štandardnými podmienkami, ktoré sa uchovávajú na odovzdávajúcom a prijímajúcom stanovišti.

8.1.2.4.2. Ak sa na prijímajúcom stanovišti zistí, že správa, ktorá sa používa len na koordinovanie štandardného odovzdávania, obsahuje neštandardné podmienky odovzdávania, značí to, že príslušné dva filtre nie sú zosúladené. Takýto nesúlad by sa mal v záujme efektívneho priebehu dialógového postupu odstrániť.

8.1.3. Postupnosť správ

8.1.3.1. Všeobecné ustanovenia

8.1.3.1.1. Potrebné je dodržiavať určité pravidlá, aby sa zabezpečilo, že koordinácia sa skončí ešte pred korekciou alebo výmenou správ o odovzdaní spojenia a dispečeri na oboch stanovištiach nepredložia návrhy týkajúce sa jedného a toho istého letu súčasne.

8.1.3.1.2. Stanovište riadenia leteckej prevádzky odvysiela správu o korekcii dát (REV alebo RRV) určitého letu, alebo potvrdí jej príjem len za predpokladu, že je v koordinovanom stave, t.j. správou LAM alebo ACP sa ukončil dialóg ACT alebo RAP.

8.1.3.1.3. Správy CDN smie vysielať len prijímajúce stanovište.

8.1.3.1.4. Správy CDN sa vysielajú a ich príjem potvrdzuje:

- len v rámci dialógu, ktorý sa spustil príjmom správy o aktivácii (ACT, RAP) alebo korekcii dát (REV alebo RRV), alebo

- len vtedy, keď letový plán daného letu je v koordinovanom stave.

8.1.4. Súčasné spracovanie správ

8.1.4.1. Všeobecné ustanovenia

8.1.4.1.1. Stanovište, ktoré sa zúčastňuje na výmene správ o koordinácii alebo odovzdaní riadenia určitého letu, spustí ďalšiu výmenu správ o koordinácii alebo odovzdaní riadenia toho istého letu s tým istým stanovišťom, až keď obdrží správu LAM, ACP alebo RJC, alebo až keď sa naplní povolený prevádzkový prestoj na odoslanie odpovede.

8.1.4.1.2. Môže sa stať, že správa CDM sa križuje so správou REV, RRV alebo MAC o tom istom lete, odoslanou z odovzdávajúceho stanovišťa. Ak sa to stane, na odovzdávajúcom stanovišti to možno zistiť podľa toho, že CDN príde ešte pred potvrdením príjmu odvysielanej koordinačnej správy a na prijímajúcom stanovišti podľa toho, že správa z odovzdávajúceho stanovišťa príde ešte pred potvrdením príjmu CDN. V takom prípade sa príjem CDN nepotvrdí a správa REV, RRV alebo MAC sa spracuje.

8.1.5. Odmietnutie spracovania

Správa RJC ukončuje dialóg medzi systémami. Musí sa spustiť nová koordinácia medzi systémami, ktorá tam, kde je to možné, reprodukuje telefonickú koordináciu.

8.1.6. Prevádzkový prestoj na odvysielanie odpovede

8.1.6.1. Všeobecné ustanovenia

8.1.6.1.1. Mechanizmus prevádzkového prestoja sa na odosielajúcom a prijímajúcom stanovišti uplatňuje v súvislosti s odoslaním odpovede na správy, ktoré boli postúpené dispečerovi.

8.1.6.1.2. Dĺžka týchto prestojov sa dvojstranne dohodne.

8.1.6.1.3. Po uplynutí tohto prestoja sa dispečerovi na odovzdávajúcom stanovišti zobrazí výstražná správa, ktorou sa oznamuje, že je potrebné spustiť telefonickú koordináciu.

8.1.6.1.4. Odporúčanie

1. Výstražná správa by sa mala na pracovisku prijímajúceho stanovišťa riadenia leteckej prevádzky, ktoré za riadenie príslušného letu zodpovedá, zobraziť bezprostredne pred tým, čo na odovzdávajúcom stanovišti uplynie povolený prestoj.

2. Pri zobrazovaní výstražnej správy by sa mal zohľadniť čas potrebný na odvysielanie odpovede.

8.1.6.1.5. Systémy musia mať schopnosť spracovať odpovede, ktoré prídu po uplynutí povoleného prestoja.

8.1.7. Činnosť

8.1.7.1. Dialógové postupy sa vzťahujú na dve fázy, konkrétne na koordinačnú fázu a fázu odovzdávania riadenia letu. V každej z týchto dvoch fáz sa v dialógu používajú iné druhy správ a vyžadujú iné transakčné časy. Koordinačné správy sa uvádzajú vo formátoch ICAO a ADEXP, správy o odovzdaní spojenia len vo formáte ADEXP.

8.1.7.2. V koordinačnom dialógu platia iné minimálne požiadavky na HMI, než v dialógu, ktorý sa týka odovzdania riadenia letu:

- dialóg týkajúci sa odovzdania riadenia napĺňa predovšetkým riadiacu funkciu a vyžaduje si rýchle a jednoducho používateľné HMI,

- v koordinačnom dialógu nie je čas až natoľko rozhodujúci, a preto kladie na HMI rádovo nižšie nároky.

8.1.7.3. Dialógový postup sa vykonáva podľa jedného z týchto scenárov:

- dialógový postup v koordinačnej fáze plus dvojstranne dohodnuté dodatkové správy (oddiely 7 a 8),

- základný koordinačný postup a dialógový postup vo fáze odovzdávania riadenia (oddiely 6, 7 a 9),

- dialógový postup v koordinačnej fáze a fáze odovzdávania riadenia plus dvojstranne dohodnuté dodatkové koordinačné správy (oddiely 7, 8 a 9).

Správa o predsunutí hranice sa odosiela vo všetkých scenároch.

8.1.7.4. Dvojstranne sa dohodne, ktorý scenár sa na vykonanie použije.

8.2. Správa o aktivácii (ACT)

8.2.1. Účel správy ACT

Účel správy ACT je uvedený v odseku 6.3.1. V dialógovom postupe sa správa ACT používa na uspokojovanie týchto požiadaviek za predpokladu, že podmienky odovzdania riadenia letu sú štandardné a odovzdávajúci dispečer nevyžaduje, aby bol let postúpený na odsúhlasenie prijímajúcemu dispečerovi.

8.2.2. Obsah správy

Obsah správy ACT, ktorá sa používa v dialógovom postupe, sa zhoduje s tým, ako je pre správu ACT popísaný v odseku 6.3.2.

8.2.3. Vykonávacie predpisy

8.2.3.1. Všeobecné ustanovenia

8.2.3.1.1. Vykonávacie predpisy sa zhodujú s tým, ako sú pre správu ACT popísané v odseku 6.3., s výhradou osobitných predpisov, ktoré sú uvedené v tomto odseku.

8.2.3.1.2. Správa ACT sa odosiela, ak odovzdanie riadenia príslušného letu prebieha v štandardných podmienkach a odovzdávajúci dispečer nevyžaduje, aby boli postúpené na schválenie prijímajúcemu dispečerovi.

POZNÁMKA

Ak tieto požiadavky neplatia, odosiela sa RAP (pozri odsek 8.3 Správa o postúpení návrhu na aktiváciu).

8.2.3.1.3. Odporúčanie

Koordinácia by sa mala spustiť ešte raz v prípade, že v odpovedi na správu ACT príde späť správa o odmietnutí koordinácie (RJC).

8.2.3.2. Spracovanie na prijímajúcom stanovišti

8.2.3.2.1. Správa sa skontroluje cez filter, aby sa potvrdilo, že navrhované podmienky sú štandardné.

8.2.3.2.2. Správa sa spracuje ako správa RAP, ak:

- sa zistí, že podmienky odovzdania riadenia nie sú štandardné,

- nemožno nájsť príslušný systémový letový plán a niet dostatok informácii na to, aby sa zistilo, či sú podmienky odovzdania riadenia štandardné alebo nie.

8.2.3.2.3. Správy ACT, o ktorých sa zistilo, že sú štandardné, sa spracujú v súlade s odsekom 6.3.3.2.

8.2.3.2.4. Odporúčanie

Ak sa zistí, že správa ACT obsahuje neštandardné podmienky odovzdania riadenia letu, znamená to, že príslušné dva filtre nie sú zosúladené. Na skutočnosť, že ACT nie je štandardná, by mal byť upozornený dozorný personál, aby sa tento nesúlad odstránil.

8.2.4. Potvrdenie príjmu ACT

8.2.4.1. Potvrdenie príjmu

8.2.4.1.1. V dialógovom postupe sa príjem správy ACT potvrdzuje:

- správou LAM, ak sa zistí, že podmienky odovzdania riadenia sú štandardné,

- správou SBY vo všetkých ostatných prípadoch.

8.2.4.1.2. Po obdržaní správy LAM sa stáva funkčný obsah správy ACT prevádzkovo záväzný pre obe stanovištia riadenia leteckej prevádzky.

8.2.4.1.3. Tam, kde sa to dvojstranne dohodne, môže prijímajúce stanovište na akceptovanie správy ACT, ktorá obsahuje štandardné podmienky odovzdania riadenia, namiesto LAM použiť ACP.

8.2.4.2. Nepotvrdenie príjmu

Ak sa príjem správy ACT nepotvrdí, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu sa zobrazí výstražná správa.

8.3. Správa o postúpení návrhu na aktiváciu (RAP)

8.3.1. Účel správy RAP

Správa RAP spĺňa okrem požiadaviek určených pre správu ACT v odseku 6.3 nasledujúce prevádzkové požiadavky:

- návrh odovzdávajúceho dispečera letovej prevádzky a jeho doručenie preberajúcemu dispečerovi pre lety s neštandardnými podmienkami odovzdania,

- umožňuje odovzdávajúcemu dispečerovi letovej prevádzky, ak si to vyžaduje, vynútiť si doručenie štandardných podmienok odovzdania pre určitý let preberajúcemu dispečerovi.

8.3.2. Obsah správy

Správa RAP obsahuje tie isté údaje, ktoré sa uvádzajú pre správu ACT (odsek 6.3.) a nepovinne môže obsahovať ešte tento údaj:

- dôvod, udávajúc ručné postúpenie (možné len v ADEXP).

8.3.3. Vykonávacie predpisy

8.3.3.1. Všeobecné ustanovenia

8.3.3.1.1. Správa RAP sa odosiela namiesto správy ACT, ak ide o let, ktorý prechádza cez hranicu a spĺňa jednu z týchto podmienok:

- odovzdávajúci systém zistil, že podmienky odovzdania riadenia letu nie sú štandardné,

- odovzdávajúci dispečer oznámil, že navrhované podmienky odovzdania riadenia letu je potrebné postúpiť prijímajúcemu dispečerovi.

8.3.3.1.2. Funkčný obsah správy RAP, ktorá sa má odvysielať, sa zobrazí na pracovisku, ktoré zodpovedá za koordináciu letu pred jej skutočným odvysielaním.

8.3.3.1.3. Odporúčanie

Čas, v ktorom sa správa RAP automatický odvysiela, by sa mal zobraziť spolu s jej obsahom.

8.3.3.1.4. Odvysielanie správy RAP sa oznámi príslušnému pracovisku.

8.3.3.2. Spracovanie na prijímajúcom stanovišti

8.3.3.2.1. Systém riadenia leteckej prevádzky, ktorý správu RAP prijíma, sa pokúsi o jej priradenie k príslušnému letovému plánu.

8.3.3.2.2. Ak sa príslušný letový plán nájde a nezistí sa žiadna nezrovnalosť, ktorá by bránila správnemu spracovaniu:

- funkčný obsah sa postúpi na schválení dispečerovi,

- späť sa odošle správa SBY.

8.3.3.2.3. Odporúčanie

V správe by sa malo uviesť, prečo bola postúpená na schválenie dispečerovi (neštandardné podmienky alebo ručné postúpenie).

8.3.3.2.4. Ak správu nemožno priradiť k žiadnemu letovému plánu, alebo ak sa zistí nezrovnalosť, ktorá bráni správnemu spracovaniu, potom:

- sa v príslušnom sektore zobrazí funkčný obsah správy,

a

- späť sa odošle správa SBY,

a

- vytvorí sa letový plán.

8.3.3.2.5. Vo všetkých ostatných prípadoch sa príjem správy nepotvrdí.

8.3.3.3. Ručné spustenie

8.3.3.3.1. Ak sa správa RAP používa na to, aby sa navrhovaná koordinácia so štandardnými podmienkami odovzdania riadenia letu postúpila prijímajúcemu dispečerovi, odovzdávajúci dispečer ju spustí ručne a okamžite odvysiela.

8.3.3.3.2. Odporúčanie

Pracovisko zodpovedné za koordináciu letu by malo mať oprávnenie ručne spustiť odvysielanie správy RAP ešte pred vypočítaným časom prenosu.

8.3.3.4. Časové parametre automatického prenosu

Čas a vzdialenosť od hranice, na ktorej sa správy RAP automaticky vysielajú, sú rovnaké, ako je tomu v prípade správ ACT.

8.3.4. Potvrdenie príjmu RAP

8.3.4.1. Potvrdenie príjmu

Príjem správy sa potvrdzuje generovaním a odvysielaním správy SBY.

8.3.4.2. Nepotvrdenie príjmu

Ak sa príjem správy RAP nepotvrdí odoslaním správy SBY, na pracovisku, ktoré zodpovedá za koordináciu letu, sa zobrazí výstražná správa.

8.3.5. Prevádzková odpoveď na RAP

Prijímajúci dispečer môže podmienky odovzdania riadenia letu prijať, odmietnuť, alebo dať protinávrh.

8.3.5.1. Prijatie podmienok

8.3.5.1.1. Keď sa prijímajúci dispečer rozhodne navrhované podmienky odovzdania riadenia letu prijať, odošle sa späť správa ACP.

8.3.5.1.2. Okamžite po príjme správy ACP sa dáta, ktoré obsahuje správa RAP, stávajú prevádzkovo záväzné pre obe stanovištia riadenia leteckej prevádzky. Koordinované podmienky odovzdania riadenia letu a príjem správy ACP sa oznámia odovzdávajúcemu dispečerovi.

8.3.5.2. Protinávrh

Keď sa prijímajúci dispečer rozhodne podať protinávrh podmienok odovzdania riadenia letu, odošle sa späť správa CDN.

8.3.5.3. Odporúčanie

Keď sa prijímajúci dispečer rozhodne, že navrhované podmienky odovzdania riadenia letu odmietne, späť by sa mala odoslať správa RJC. Potom by sa mal znovu spustiť proces koordinácie.

POZNÁMKA

Vzhľadom na odporúčanie v odseku 8.3.5.3. sa ďalšia koordinácia vo väčšine prípadov spustí s iným stanovišťom.

8.3.6. Príklady

8.3.6.1. ICAO

(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M)

8.3.6.2. ADEXP

-TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757

8.4. Správa o korekcii dát (REV)

8.4.1. Účel správy REV

Účel správy REV je uvedený v odseku 7.3.1. V dialógovom postupe sa správa REV používa na uspokojenie týchto požiadaviek za predpokladu, že podmienky odovzdania riadenia letu sú štandardné a odovzdávajúci dispečer nevyžaduje, aby bol let postúpený na schválenie prijímajúcemu dispečerovi.

8.4.2. Obsah správy

Správa REV obsahuje údaje, ktoré sú pre tento druh správy uvedené v odseku 7.3.2.

8.4.3. Vykonávacie predpisy

8.4.3.1. Všeobecné ustanovenia

8.4.3.1.1. Stanovišťu, na ktoré bol let práve skoordinovaný použitím správy o aktivácii alebo správy RAP, možno odoslať jednu alebo viac správ REV.

8.4.3.1.2. Správy REV sa odosielajú za podmienok uvedených v odseku 7.3.3.1., ak ide o lety so štandardnými podmienkami odovzdania ich riadenia a odovzdávajúci dispečer nevyžaduje, aby boli na schválenie postúpené prijímajúcemu dispečerovi.

8.4.3.2. Spustenie prenosu

Správa REV sa odvysiela, len čo sa zistí zmena v koordinačných dátach, ktoré sa musia skoordinovať, ako je to uvedené v odseku 7.3.3.

8.4.3.3. Spracovanie na prijímajúcom stanovišti

8.4.3.3.1. Ak sa príslušný letový plán nájde v skoordinovanom stave a nezistí sa žiadna nezrovnalosť, ktorá by bránila správnemu spracovaniu správy, potom:

- sa príjem správy REV potvrdí,

- vo všetkých ostatných prípadoch sa príjem správy nepotvrdí.

8.4.3.3.2. Podmienky odovzdania riadenia letu sa preskúmajú, aby sa zistilo, či sú štandardné.

8.4.3.3.3. Ak podmienky odovzdania riadenia letu nie sú štandardné, predložia sa prijímajúcemu dispečerovi.

8.4.3.3.4. Ak sa zistí, že navrhované podmienky odovzdania riadenia letu sú štandardné, zahrnú sa do letového plánu a požadované dáta sa vydajú cez výstup na pracovisku riadenia leteckej prevádzky, prípadne na iných pracoviskách.

8.4.3.3.5. Odporúčanie

Ak s a zistí, že správa REV obsahuje neštandardné podmienky odovzdania riadenia letu, znamená to, že filtre príslušných dvoch systémov nie sú zosúladené. Na skutočnosť, že REV nie je štandardná, by mal byť upozornený dozorný personál, aby sa tento nesúlad odstránil.

8.4.4. Potvrdenie príjmu REV

8.4.4.1. Potvrdenie príjmu

8.4.4.1.1. Ak sa má príjem správy REV potvrdiť, potvrdí sa:

- správou LAM, ak sa zistí, že podmienky odovzdania riadenia letu sú štandardné,

- správou SBY, ak sa zistí, že podmienky odovzdania riadenia letu nie sú štandardné.

8.4.4.1.2. Po príjme správy LAM sa funkčný obsah správy EV stáva prevádzkovo záväzný pre obe stanovištia riadenia leteckej prevádzky.

8.4.4.1.3. Tam, kde sa to dvojstranne dohodne, možno na oznámenie skutočnosti, že prijímajúce stanovište schválilo REV, ktorá obsahuje štandardné podmienky odovzdania riadenia letu, namiesto LAM použiť ACP.

8.4.4.2. Ne Potvrdenie príjmu

Ak sa príjem správy REV nepotvrdí, na pracovisku, ktoré zodpovedá za koordináciu letov, sa zobrazí výstražná správa.

8.4.5. Prevádzková odpoveď na REV

Vzhľadom na to, že správa REV sa používa na odosielanie štandardných podmienok odovzdávania riadenia letu, systém na prijímajúcom stanovišti ju zvyčajne schváli. Ak sa cez filter na prijímajúcom stanovišti zistí, že podmienky odovzdania riadenia letu nie sú štandardné, správa sa spracuje ako správa RRV.

8.5. Správa o postúpení návrhu na korekciu (RRV)

8.5.1. Účel správy RRV

Správa RRV zabezpečuje korekciu už odoslaných a odsúhlasených podmienok odovzdania riadenia letu v týchto prípadoch:

- keď podmienky odovzdania riadenia letu, ktoré sa navrhujú v korekcii, nie sú štandardné,

- keď navrhovaná korekcia je štandardná,, ale odovzdávajúci dispečer chce korekciu postúpiť na schválenie prijímajúcemu dispečerovi.

8.5.2. Obsah správy

Obsah správy RRV sa zhoduje s tým, ako je uvedený pre správu REV (odsek 7.3.2.) a nepovinne môže zahŕňať aj tieto údaje:

- dôvod, uvádzajúc ručné postúpenie (možné len vo formáte ADEXP).

8.5.3. Vykonávacie predpisy

8.5.3.1. Všeobecné ustanovenia

O každej korekcii sa namiesto správ REV odošle jedna alebo viac správ RRV, ak:

- odovzdávajúci systém zistil, že podmienky odovzdania riadenia letu nie sú štandardné,

alebo

- odovzdávajúci dispečer oznámil, že navrhované podmienky odovzdania riadenia letu sa majú postúpiť na schválenie prijímajúcemu dispečerovi. Tento spôsob použitia správy RRV nie je povinný.

8.5.3.2. Spustenie prenosu

Správa RRV sa odvysiela, len čo sa zistí zmena v koordinačných dátach, alebo ak sa spustí ručne.

8.5.3.3. Spracovanie na prijímajúcom stanovišti

8.5.3.3.1. Ak sa príslušný letový plán nájde v skoordinovanom stave a nezistí sa žiadna nezrovnalosť, ktorá by bránila správnemu spracovaniu správy, potom:

- sa príjem správy RRVG potvrdí,

- vo všetkých ostatných prípadoch sa príjem správy nepotvrdí.

8.5.3.3.2. Navrhované podmienky odovzdania riadenia letu sa zobrazia na pracovisku, ktoré zodpovedá za koordináciu letu.

8.5.3.3.3. Odporúčanie

V správe by sa malo uvádzať aj to, prečo bola postúpená na schválenie (neštandardné podmienky alebo ručné postúpenie).

8.5.4. Potvrdenie príjmu RRV

8.5.4.1. Potvrdenie príjmu

Príjem správy sa potvrdí generovaním a odvysielaním správy SBY.

8.5.4.2. Nepotvrdenie príjmu

Ak sa príjem správy RRV nepotvrdí odoslaním správy SBY, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu, sa zobrazí výstražná správa.

8.5.5. Prevádzková odpoveď na RRV

Prijímajúci dispečer môže správu RRV prijať, odmietnuť alebo dať vlastný protinávrh.

8.5.5.1. Schválenie správy

Keď sa prijímajúci dispečer rozhodne navrhovanú zmenu v dohodnutých podmienkach odovzdávania riadenia letu prijať, odošle sa späť správa ACP.

8.5.5.2. Protinávrh

Keď sa prijímajúci dispečer rozhodne, že podá protinávrh podmienok odovzdania riadenia letu, odošle sa späť správa CDN.

8.5.5.3. Odmietnutie

Keď sa prijímajúci dispečer rozhodne, že navrhovanú zmenu v dohodnutých podmienkach odovzdania riadenia letu odmietne:

- odošle sa späť správa RJC,

a

- spustí sa nový proces koordinácie.

V prípade, že v odpovedi na správu RR nepríde ani ACP, ani CDN, predpokladá sa, že navrhovaná zmena bola odmietnutá.

8.5.6. Príklady

8.5.6.1. ICAO

(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)

8.5.6.2. ADEXP

-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226-TFL F310 -ADES EGBB

8.6. Správa o príjme a postúpení (SBY)

8.6.1. Účel správy SBY

Správou SBY sa potvrdzuje príjem správy, v ktorej sa navrhujú podmienky odovzdania riadenia letu a uvádza sa v nej, že tento návrh sa na posúdenie postupuje dispečerovi.

8.6.2. Obsah správy

Správa SBY obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

8.6.3. Vykonávacie predpisy

8.6.3.1. Všeobecn é ustanovenia

Správa SBY sa generuje a vysiela automaticky a okamžite v odpovedi na:

- správu RAP, RRV alebo CDN,

- správu ACT alebo REV, ktoré filter neuzná za štandardné.

8.6.4. Potvrdenie príjmu SBY

Príjem správy SBY sa nepotvrdzuje.

8.6.5. Príklady

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. Správa o prijatí podmienok

8.7.1. Účel správy

Správa ACP uspokojuje počas fázy koordinácie a odovzdávania riadenia letu tieto prevádzkové požiadavky:

- oznamuje, že dispečer na jednom stanovišti ručne odsúhlasil podmienky odovzdania riadenia letu, ktoré navrhol dispečer z druhého stanovišťa, a ktoré sú obsiahnuté v týchto typoch správ:

- RAP,

- RRV,

- CDN,

- ACT a REV, ak sa o nich zistí, že sú neštandardné,

- ak sa to dvojstranne dohodne, automaticky sa nimi odsúhlasuje správa ACT alebo REV, ktorá prešla cez filter na prijímajúcom stanovišti (namiesto LAM),

- keď sa to dvojstranne dohodne, oznamuje sa ňou ručné odsúhlasenie správy HOP (namiesto správy ROF).

8.7.2. Obsah správy

Správa ACP obsahuje tieto údaje:

- povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- značku správy,

- nepovinné údaje - správa môže takisto obsahovať:

- kmitočet,

- nepovinné údaje v správach vo formáte ICAO - správa môže obsahovať takisto tieto údaje:

- identifikačné údaje lietadla,

- letisko odletu,

- cieľové letisko.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

8.7.3. Vykonávacie pravidlá

8.7.3.1. Všeobecné ustanovenia

8.7.3.1.1. Odkaz na správu v správe ACP musí uvádzať číslo správy, na ktorú správa ACP odpovedá.

8.7.3.1.2. Ak sa uvádza pole kmitočtu, obsahuje kmitočet, na ktorom sa má počas odovzdávania lietadlo spojiť s prijímajúcim stanovišťom.

8.7.3.1.3. Správa ACP sa odosiela po tom, čo dispečer ručne odsúhlasil navrhované podmienky odovzdania riadenia letu, odoslané v správe ACT, RAP, REV, RRV alebo CDN.

8.7.3.1.4. Správu ACP možno odoslať namiesto správy ROF, v odpovedi na správu HOP.

8.7.3.1.5. Keď sa to dvojstranne dohodne, správa ACP automaticky generuje a odosiela systém v odpovedi na správu ACT alebo REV, ktorá prešla cez filter.

8.7.3.1.6. Po príjme správy ACP sú podmienky odovzdania riadenia letu záväzné pre obe stanovištia.

8.7.3.2. Spracovanie na prijímajúcom stanovišti

8.7.3.2.1. Systém riadenia leteckej prevádzky, ktorý prijal správu ACP, sa pokúsi priradiť ku k príslušnému letovému plánu:

8.7.3.2.2. ak správu ACP možno priradiť k určitému letovému plánu, jej odsúhlasenie sa oznámi príslušnému dispečerovi.

8.7.3.2.3. Ak správu ACP nemožno priradiť k určitému letovému plánu:

- na príslušnom pracovisku sa zobrazí výstražná správa a

- neodošle sa správa LAM.

8.7.4. Potvrdenie príjmu ACP

8.7.4.1. Potvrdenie príjmu

8.7.4.1.1. Správa LAM sa neodosiela späť v prípade, že ACP automaticky odpovedá na správu ACT alebo REV, ktorá prešla filtrom.

8.7.4.1.2. Príjem správy ACP, ktorá sa odoslala v dôsledku ručného odsúhlasenia, sa potvrdí generovaním a odvysielaním správy LAM.

8.7.4.2. Nepotvrdenie príjmu

Ak sa príjem správy ACP, ktorá sa odoslala v dôsledku ručného odsúhlasenia, nepotvrdí odoslaním správy LAM, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu, sa zobrazí výstražná správa.

8.7.5. Príklady

8.7.5.1. ICAO

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

8.7.5.2. ADEXP

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

8.8. Koordinačná správa (CDN)

8.8.1. Účel správy CDN

Správa CDN uspokojuje tieto prevádzkové požiadavky:

- odoslanie protinávrhu od prijímajúceho dispečera odovzdávajúcemu dispečerovi, v odpovedi na správu ACT, RAP, REV alebo RRV,

- spustenie navrhovanej zmeny v dohodnutých podmienkach odovzdania riadenia letu, ktorú prijímajúci dispečer predkladá odovzdávajúcemu dispečerovi.

8.8.2. Obsah správy

Správa CDN obsahuje tieto údaje:

- povinné údaje- správa obsahuje:

- typ správy,

- číslo správy,

- značku správy (len v prípade, že sa ňou odpovedá na inú správu),

- identifikačné údaje lietadla,

- letisko odletu,

- cieľové letisko,

POZNÁMKA

Správa takisto obsahuje aj jeden alebo oba tieto údaje:

- dáta určené odhadom (ak ide o správu vo formáte ICAO) alebo letovú hladinu pri odovzdávaní riadenia letu (ak ide o správu vo formáte ADEXP),

- žiadosť o priamu trasu.

- Dvojstranne dohodnuté údaje - Keď sa to dvojstranne dohodne, možno uvádzať aj tieto údaje:

- kmitočet.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

8.8.3. Vykonávacie predpisy

8.8.3.1. Všeobecné ustanovenia

8.8.3.1.1. Odosielanie správ CDN spúšťa len prijímajúci dispečer.

8.8.3.1.2. Používa sa na odvysielanie protinávrhu prijímajúceho dispečera odovzdávajúcemu dispečerovi.

POZNÁMKA

Toto môže prebiehať buď počas dialógu, v odpovedi na návrh zaslaný v správe ACT, RAP, REV alebo RRV, alebo započatím dialógu za účelom zmeny už dohodnutých podmienok odovzdania riadenia letu.

8.8.3.1.4. Ak sa uvádza aj značka správy, obsahuje číslo správy, na ktorú sa správou CDN odpovedá.

8.8.3.1.5. Prostriedok žiadosti o priamu trasu (podrobne popísaný v prílohe A):

- sa používa, len ak sa to dvojstranne dohodne a

- ak sa to dohodne, definuje obmedzenia na jeho používanie v prevádzke.

8.8.3.1.6. CDN sa neodosiela, ak uplynie určitý čas, alebo ak sa prekročí určitá vzdialenosť k hranici, ako je to uvedené v LoA medzi dotknutými stanovišťami.

8.8.3.1.7. V prípade, že CDN sa vysiela v čase, keď sa z odovzdávajúceho stanovišťa odosiela určitá správa o tom istom lete, napríklad ak ide o korekciu alebo zrušenie koordinácie, neodosiela sa späť ani potvrdenie o príjme, ani prevádzková odpoveď.

POZNÁMKA

Znamená to, že, keď sa križujú dve správy, správa z odovzdávajúceho stanovišťa má prednosť a obe stanovištia upustia od odoslania CDN. Na oboch stanovištiach možno takúto situáciu spoznať podľa toho, že správa z druhého stanovišťa príde skôr ako potvrdenie príjmu.

8.8.3.1.8. Len čo príde správa, ktorou sa podmienky odovzdania riadenia letu schvália, údaje v správe CDN sú prevádzkovo záväzné pre obe stanovištia riadenia leteckej prevádzky. Podmienky koordinovaného odovzdania riadenia letu a skutočnosť a príjem správy ACP sa oznámia dotknutému personálu riadenia leteckej prevádzky.

8.8.3.2. Spracovanie na prijímajúcom stanovišti

8.8.3.2.1. Ak sa príslušný letový plán nájde a správa neobsahuje žiadnu nezrovnalosť, ktorá by bránila správnemu spracovaniu:

- jej funkčný obsah sa zobrazí na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu,

a

- späť sa odošle správa SBY.

8.8.3.2.2. Ak správu CDN nemožno priradiť k určitému letovému plánu, alebo ak sa zistí nezrovnalosť, ktorá by bránila správnemu spracovaniu správy, správa SBY sa späť neodošle.

8.8.4. Potvrdenie príjmu CDN

8.8.4.1. Potvrdenie príjmu

Na základe vyššie uvedených podmienok sa príjem správy CDN potvrdí generovaním a odvysielaním správy SBY.

8.8.4.2. Nepotvrdenie príjmu

Ak sa príjem správy CDN nepotvrdí odoslaním správy SBY, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letu, sa zobrazí výstražná správa.

8.8.5. Prevádzková odpoveď na CDN

Dispečer môže podmienky odovzdania riadenia letu, ktoré sa navrhujú v správe CDB, prijať alebo odmietnuť.

8.8.5.1. Schválenie

Keď sa odovzdávajúci dispečer rozhodne, že navrhované podmienky odovzdania letu prijíma, odošle sa späť správa ACP.

8.8.5.2. Odporúčanie

Keď sa odovzdávajúci dispečer rozhodne, že navrhované podmienky odovzdania letu odmietne, mala by sa odoslať správa RJC (výslovné odmietnutie).

POZNÁMKA

Ak do uplynutia prestoja, ktorý je povolený na odoslanie odsúhlasenia správy CDN, schválenie nepríde, predpokladá sa, že navrhovaná koordinácia sa odmieta.

8.8.6. Príklady

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. Správa o odmietnutí koordinácie (RJC)

8.9.1. Účel správy RJC

Správou RJC sa oznamuje, že dispečer na jednom stanovišti odmieta podmienky odovzdania riadenia letu, ktoré navrhuje dispečer na druhom stanovišti v jednej z týchto správ.

- RAP,

- RRV,

- CDN,

- ACT a REV, ak sa o nich zistí, že sú neštandardné.

Správu RJC možno použiť len v priamej odpovedi na jednu z vyššie uvedených správ.

8.9.2. Obsah správy

Správa RJC obsahuje tieto údaje:

- typ správy,

- číslo správy,

- značku správy.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

8.9.3. Vykonávacie pravidlá

8.9.3.1. Všeobecné ustanovenia

8.9.3.1.1. RJC sa podľa požiadavky odosiela v odpovedi na správu RAP, RRV, CDN alebo v odpovedi na správu ACT či REV, ak sa na prijímajúcom stanovišti zistilo, že nie je štandardná.

8.9.3.1.2. Správou RJC sa ukončuje dialóg medzi systémami a v platnosti zostáva každá, už dohodnutá koordinácia.

8.9.3.1.3. Odporúčanie

Po príjme správy RJC by sa mal spustiť nový koordinačný sled, ktorý tam, kde je to možné, reprodukuje telefonickú koordináciu.

8.9.3.2. Spracovanie na prijímajúcom stanovišti

8.9.3.2.1. Ak sa nájde príslušná správa, na ktorú sa odvoláva správa RJC:

- odmietnutie sa oznámi na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu príslušného letu, a

- príjem správy sa potvrdí spätným odoslaním správy LAM.

8.9.3.2.2. Ak sa nenájde takáto správa, ktorá čaká na odpoveď, alebo ak správa obsahuje nezrovnalosť, ktorá bráni spracovaniu, potvrdenie príjmu sa späť neodošle.

8.9.4. Potvrdenie príjmu RJC

8.9.4.1. Potvrdenie príjmu

Príjem správy RJC sa potvrdí generovaním a odvysielaním správy LAM.

8.9.4.2. Nepotvrdenie príjmu

Ak sa príjem správy RJC nepotvrdí odoslaním správy LAM, na pracovisku riadenia leteckej prevádzky, ktoré zodpovedá za koordináciu letov, sa zobrazí výstražná správa.

8.9.5. Príklady

8.9.5.1. ICAO

(RJCMC/E746E/MC324)

8.9.5.2. ADEXP

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

9. DIALÓGOVÝ POSTUP — ODOVZDANIE SPOJENIA

9.1. Všeobecné ustanovenia

9.1.1. Úvod

9.1.1.1. V tomto oddieli technickej normy sa popisujú prostriedky a správy, ktorými sa v rámci odovzdávania riadenia letu odovzdávajú rádiolokátory. Vykonávajú sa tam, kde sa to dvojstranne dohodne.

9.1.1.2. Prostriedky odovzdávania spojenia sa používajú len v prípade, že príslušné stanovište používa buď koordinačné prostriedky uvedené v oddieli 6 (Základný postup - povinné správy) alebo tie uvedené v oddieli 8 (Dialógový postup - koordinácia).

9.1.1.3. Správy, ktoré sa popisujú v tejto časti dokumentu, možno používať len vo formáte ADEXP a neuvažuje sa o tom, že by sa používali aj vo formáte ICAO.

9.1.2. Sled správ

9.1.2.1. Výmena správ o odovzdaní spojenia, okrem správy o dodatkových údajoch (SDM), prebieha až po dokončení koordinácie, t.j. až keď sa dialóg prostredníctvom správ ACT alebo RAP zavŕšil odoslaním správy LAM alebo ACP.

9.1.2.2. Pokiaľ sa nedokončila koordinácia, príjem správ sa späť neodosiela.

9.1.3. Odovzdanie spojenia

9.1.3.1. Na spôsobe, akým sa oznámi zmena spojenia s letmi, sa medzi sebou dohodnú obe dotknuté stanovištia.

9.1.3.2. Pritom platí jedna alebo viacero týchto podmienok:

- odovzdávajúce stanovište odošle správu o zmene kmitočtu (COF),

- prijímajúce stanovište odošle správu o ručnom nadviazaní spojenia (MAS),

9.1.3.3. Na tomto spôsobe sa obe stanovištia dohodnú pre každý dopravný prúd.

POZNÁMKA

Pre iné dopravné prúdy možno použiť iné spôsoby, napríklad jedno stanovište môže generovať správy COF o letoch, ktoré opúšťajú jeho vzdušný priestor, a správy MAS o letoch, ktoré doň vstupujú. V takom prípade nie je potrebné, aby druhé stanovište oznamovalo odovzdanie spojenia nejakou správou.

9.2. Správa o spustení odovzdávania (TIM)

9.2.1. Účel správy TIM

Správa TIM má tento účel:

- oznámiť spustenie procesu odovzdávania (TI) (koniec koordinačnej fáze a začiatok fáze odovzdávania),

- zároveň odoslať dáta o riadení letu z odovzdávajúceho stanovišťa na prijímajúce.

9.2.2. Obsah správy

Správa TIM obsahuje tieto údaje:

- povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- dostupné údaje - pokiaľ sú k dispozícii, správa obsahuje aj tieto údaje:

- povolenú letovú hladinu,

- pridelený kurz alebo povolenie k pristátiu či odletu,

- pridelenú rýchlosť,

- pridelenú rýchlosť stúpania alebo klesania,

- nepovinné údaje - správa môže takisto obsahovať:

- polohu.

POZNÁMKA:

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

9.2.3. Vykonávacie predpisy

9.2.3.1. Všeobecné ustanovenia

9.2.3.1.1. Správu TIM generuje a odosiela odovzdávajúce stanovište prijímajúcemu stanovišťu bež zásahu človeka vo vzájomne dohodnutom čase a vzdialenosti lietadla od hranice.

9.2.3.1.2. Správa TIM sa odosiela aj automaticky, keď odovzdávajúce stanovište obdrží správu o požadovanom kmitočte (ROF).

9.2.3.1.3. Správa TIM sa odosiela až po skoordinovaní letu.

9.2.3.1.4. Správa TIM obsahuje najnovšie údaje, ktoré sú v systéme k dispozícii.

9.2.3.2. Časové parametre prenosu

9.2.3.2.1. Parametrom generovania TIM je premenný parameter systému, ktorý možno v závislosti od ustanovení LoA zmeniť.

9.2.3.2.2. Odporúčanie

Parameter systému na generovanie TIM by sa mal určiť pre každý COP osobitne.

9.2.3.2.3. Koordinační partneri začlenia parametre generovania TIM do svojej LoA.

9.2.3.2.4. Parameter systému, ktorým sa spúšťa správa TIM, možno uviesť do vzťahu s vypočítanou pozemnou rýchlosťou lietadla. Avšak správa TIM sa spustí vždy skôr, než sa lietadlo priblíži k COP na vzdialenosť kratšiu, než je minimálna dvojstranne určená vzdialenosť.

9.2.3.2.5. Predpísaný parameter systému pre prenos TIM musí poskytovať dostatok času na ústnu koordináciu pred odovzdaním rádiolokátora.

9.2.3.3. Spracovanie na prijímajúcom stanovišti

9.2.3.3.1. Údaje obsiahnuté v prijatej správe TIM sa dajú k dispozícii prijímajúcemu dispečerovi.

9.2.4. Potvrdenie príjmu TIM

9.2.4.1. Potvrdenie príjmu

Ak správu TIM:

- možno jednoznačne priradiť k určitému letovému plánu, jej príjem sa potvrdí generovaním a odoslaním správy LAM,

- nemožno jednoznačne priradiť k určitému letovému plánu, jej príjem sa nepotvrdí.

9.2.4.2. Nepotvrdenie príjmu

Ak sa príjem správy TIM nepotvrdí odoslaním správy MAL, na príslušnom pracovisku sa zobrazí výstražná správa.

9.2.5. Príklad

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

9.3. Správa o dodatkových údajoch (SDM)

9.3.1. Účel správy

9.3.1.1. Všeobecné ustanovenia

9.3.1.1.1. Správa SDM má predovšetkým za cieľ prenos dát o riadení letu a ich zmien z odovzdávajúceho stanovišťa na prijímajúce stanovište za predpokladu, že sa dvojstranne dohodlo, že príjem týchto zmien nemusí prijímajúci dispečer potvrdiť.

9.3.1.1.2. Správu SDM môže prijímajúce stanovište použiť aj na to, že odovzdávajúcemu stanovišťu oznámi rádiotelefonický kmitočet, na ktorý sa má let preladiť.

9.3.2. Obsah správy

9.3.2.1. Správy z odovzdávajúceho stanovišťa

Správa SDM obsahuje tieto údaje:

- povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- dodatkové údaje - správa obsahuje takisto jeden alebo viacero týchto údajov:

- pridelený kurz alebo povolenie na pristátie či vzlietnutie,

- pridelenú rýchlosť,

- pridelenú rýchlosť stúpania alebo klesania,

- povolenú letovú hladinu.

9.3.2.2. Správy z prijímajúceho stanovišťa

SDM obsahuje tieto údaje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- kmitočet.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

9.3.3. Vykonávacie predpisy

9.3.3.1. Správy z odovzdávajúceho stanovišťa

9.3.3.1.1. Správy SDM sa odosielajú po spustení fázy odovzdávania (pozri TIM, odsek 9.2.), keď sa zmení jeden z týchto údajov:

- povolená letová hladina,

- pridelená rýchlosť,

- pridelená rýchlosť stúpania alebo klesania,

- pridelený kurz, alebo

- ak sa pre let vydá či zmení povolenie postupovať priamo k určenému bodu.

POZNÁMKA

Keď sa pred odovzdaním spojenia vyžaduje súhlas prijímajúceho dispečera, vyžaduje sa použitie správy HOP.

9.3.3.1.2. Správa obsahuje len tie polia, ktoré sa zmenili.

9.3.3.1.3. Ak sa to dvojstranne dohodne, správy SDM, ktoré obsahujú údaje uvedené v odseku 9.3.3.1.1., sa odosielajú pred TI.

9.3.3.1.4. Takéto správy sa začínajú odosielať v dvojstranne dohodnutom čase vo vzťahu k TI za predpokladu, že existujú dáta, ku ktorým systém môže priradiť určitú hodnotu.

9.3.3.2. Správy z prijímajúceho stanovišťa

9.3.3.2.1. Správami SDM možno oznamovať kmitočet, na ktorom sa má príslušný let spojiť s prijímajúcim stanovišťom.

POZNÁMKA

Stanovištia sa môžu dohodnúť na odosielaní aj iných informácií. Takéto odovzdávanie sa v tejto technickej norme nedefinuje, a preto nie je jej súčasťou.

9.3.3.2.2. Ak sa to dvojstranne dohodne, správy SDM sa odosielajú z prijímajúceho stanovišťa počas koordinačnej fázy.

9.3.3.3. Spracovanie na prijím ajúcom stanovišti

9.3.3.3.1. Systém riadenia leteckej prevádzky, ktorý prijal správu SDM, sa pokúsi o jej priradenie k príslušnému letovému plánu.

9.3.3.3.2. Ak sa nájde príslušný letový plán v skoordinovanom stave:

- späť sa odošle správa LAM a

- funkčný obsah správy SDM sa dá k dispozícii príslušnému dispečerovi.

9.3.3.3.3. Ak príslušný letový plán nemožno nájsť, alebo ak sa zistí určitá nezrovnalosť, ktorá bráni správnemu spracovaniu správy:

- správa LAM sa späť neodošle a

- na príslušnom pracovisku sa zobrazí výstražná správa.

9.3.4. Potvrdenie príjmu SDM

9.3.4.1. Potvrdenie príjmu

Správa SDM sa prijíma generovaním a odvysielaním správy LAM.

9.3.4.2. Nepotvrdenie príjmu

Ak sa príjem správy SDM nepotvrdí odoslaním správy LAM, na príslušnom pracovisku sa zobrazí výstražná správa.

9.3.5. Príklad

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

9.4. Návrh na odovzdanie (HOP)

9.4.1. Účel správy HOP

Účelom správy HOP je:

- aby odovzdávajúci dispečer za účelom odovzdania upriamil pozornosť prijímajúceho dispečera na určitý let,

- aby odovzdávajúci dispečer, keď sa to vyžaduje, navrhol prijímajúcemu dispečerovi prevzatie letu,

- odoslať zmeny v dátach riadenia letu, ktoré si vyžadujú súhlas prijímajúceho dispečera tak, ako sa to dvojstranne dohodlo.

Správa HOP sa nemusí používať pri všetkých letoch, odovzdávajúci dispečer ju používa podľa vlastného uváženia.

POZNÁMKA

So zreteľom na odsek c) vyššie sa SDM používa na odosielanie zmien v dátach riadenia letu, ktoré si nevyžadujú súhlas prijímajúceho dispečera.

9.4.2. Obsah správy

Správa HOP obsahuje tieto údaje:

- Povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- Dostupné údaje - pokiaľ sú k dispozícii, správa obsahuje takisto tieto údaje:

- povolená letová hladina,

- pridelený kurz alebo povolenie k pristátiu či vzlietnutiu,

- pridelenú rýchlosť,

- pridelenú rýchlosť stúpania alebo klesania,

- Nepovinné údaje - správa môže obsahovať:

- polohu.

POZNÁMKA

Predpisy pre vkladanie údajov, formáty a obsah polí sú uvedené v prílohe A.

9.4.3. Vykonávacie predpisy

9.4.3.1. Všeobecné ustanovenia

9.4.3.1.1. Keď sa správa HOP používa, odovzdávajúci dispečer ju spúšťa ručne.

9.4.3.1.2. Správa obsahuje letové údaje uvedené v odseku 9.4.2. vyššie, ktoré sa v porovnaní s už odvysielanými zmenili.

9.4.3.1.3. Ak sa správa HOP odošle pred TI, spustí sa fáza odovzdávania riadenia letu.

POZNÁMKA

Popri správe HOP sa nevyžaduje aj správa o spustení odovzdávania (TIM).

9.4.3.1.4. Najskorší čas alebo najkratšia vzdialenosť do bodu COP alebo k hranici, keď možno správu HOP odoslať, sa dohodne dvojstranne.

9.4.3.1.5. Odporúčanie

Tento čas alebo táto vzdialenosť by sa mali pre každý bod COP určiť osobitne.

9.4.3.2. Spracovanie na prijímajúcom stanovišti

9.4.3.2.1. Systém riadenia leteckej prevádzky, ktorý správu HOP prijal, sa pokúsi o jej priradenie k príslušnému letovému plánu.

9.4.3.2.2. Letové dáta obsiahnuté v prijatej správe sa okamžite zobrazia prijímajúcemu dispečerovi.

9.4.3.2.3. Ak prijímajúci dispečer prijíma let za podmienok, ktoré sú uvedené v HOP, odovzdávajúcemu stanovišťu sa v odpovedi môže odoslať správa ROF. Keď sa to dvojstranne dohodne, v odpovedi na správu HOP možno odoslať správu ACP.

9.4.3.2.4. Ak prijímajúci dispečer nemôže let odsúhlasiť, odovzdanie riadenia letu sa dohodne ústne.

POZNÁMKA

Vzhľadom na naliehavosť postupu odovzdávania rádiolokátora sa v tejto technickej norme nevyžaduje, aby spätné odoslanie správy ROF (alebo ACP) zabezpečoval systém; predpokladá sa, že odovzdávajúci dispečer si dokonale uvedomí, že neprišla odpoveď od prijímajúceho dispečera a podnikne opatrenia, vykoná všetko, čo je potrebné. Táto technická norma však nebráni tomu, aby sa odovzdávajúcemu dispečerovi, ak sa to z hľadiska prevádzky považuje za potrebné, poskytla výstraha.

9.4.3.2.5. Okamžite po príjme ROF (alebo ACP) sú údaje obsiahnuté v HOP prevádzkovo záväzné pre obe stanovištia riadenia leteckej prevádzky.

9.4.4. Potvrdenie príjmu HOP

9.4.4.1. Potvrdenie príjmu

Ak správu HOP možno priradiť k určitému letovému plánu, jej príjem sa potvrdí automaticky odoslaním správy LAM.

9.4.4.2. Nepotvrdenie príjmu

Ak sa príjem správy HOP nepotvrdí odoslaním správy LAM, na príslušnom pracovisku sa zobrazí výstražná správa.

9.4.5. Príklad

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

9.5. Správa o požadovanom kmitočte (ROF)

9.5.1. Účel správy ROF

Správu ROF odosiela v prípade potreby prijímajúce stanovište odovzdávajúcemu a žiada v nej odovzdávajúceho dispečera, aby lietadlu prikázal prejsť na kmitočet prijímajúceho dispečera. Správou možno:

- v odpovedi na HOP oznámiť prijatie letu za navrhovaných podmienok,

- žiadať skoršie odovzdanie riadenia letu.

9.5.2. Obsah správy

Správa ROF obsahuje tieto údaje:

- Povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- Nepovinné údaje - správa môže takisto obsahovať:

- kmitočet.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

9.5.3. Vykonávacie predpisy

9.5.3.1. Všeobecné ustanovenia

9.5.3.1.1. Správu ROF ručne spúšťa prijímajúci dispečer.

9.5.3.1.2. Prijímajúci dispečer môže správu ROF spustiť buď:

- keď chce mať prijímajúci dispečer lietadlo skôr na svojom kmitočte,

- v odpovedi na správu HOP.

9.5.3.2. Spracovanie na prijímajúcom stanovišti

9.5.3.2.1. Systém riadenia leteckej prevádzky, ktorý správu ROF prijal, sa pokúsi o jej priradenie k príslušnému letovému plánu.

9.5.3.2.2. Príjem správy ROF sa okamžite oznámi odovzdávajúcemu dispečerovi.

9.5.3.2.3. Ak let nie je vo fáze odovzdávania riadenia, spustí sa fáza odovzdávania a odvysiela správa TIM.

9.5.4. Potvrdenie príjmu ROF

9.5.4.1. Potvrdenie príjmu

9.5.4.1.1. Ak možno správu ROF jednoznačne priradiť k určitému letovému plánu, jej príjem sa potvrdí generovaním a odvysielaním správy LAM.

9.5.4.1.2. Ak správu ROF nemožno jednoznačne priradiť k niektorému letovému plánu, jej príjem sa nepotvrdí.

9.5.4.2. Nepotvrdenie príjmu

Ak sa príjem správy ROF nepotvrdí odoslaním správy LAM, na príslušnom pracovisku sa zobrazí výstražná správa.

9.5.5. Príklad

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

9.6. Správa o zmene kmitočtu (COF)

9.6.1. Účel správy

9.6.1.1. Všeobecné ustanovenia

9.6.1.1.1. Správu COF odosiela odovzdávajúce stanovište prijímajúcemu a oznamuje v nej, že lietadlu bol vydaný pokyn, aby sa spojilo s prijímajúcim dispečerom.

9.6.1.1.2. Správa môže zahŕňať prostriedok, ktorým odovzdávajúci dispečer prepustí let z dohodnutých podmienok odovzdania riadenia, keď lietadlo nadviaže rádiové spojenie s prijímajúcim dispečerom.

9.6.2. Obsah správy

Správa COF obsahuje tieto údaje:

- Povinné údaje - správa obsahuje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla,

- Dostupné správy - ak sú k dispozícii, správa obsahuje takisto tieto údaje:

- oznámenie o prepustení z dohodnutých podmienok,

- kmitočet,

- povolenú letovú hladinu,

- pridelený kurz alebo povolenie k pristátiu či vzlietnutiu,

- pridelenú rýchlosť,

- pridelenú rýchlosť stúpania alebo klesania,

- Nepovinné údaje - správa môže takisto obsahovať:

- pozíciu.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

9.6.3. Vykonávacie predpisy

9.6.3.1. Všeobecné ustanovenia

9.6.3.1.1. Správu COF spúšťa ručne odovzdávajúci dispečer.

9.6.3.1.2. Použitie správy COF je povinné, ak sa na základe dvojstrannej dohody nepoužíva správa MAS.

9.6.3.1.3. Ak sa správa COF odosiela pred TI, spustí sa fáza odovzdávania riadenia letu.

POZNÁMKA

Popri správe COF sa nevyžaduje aj správa o spustení odovzdávania (TIM).

9.6.3.2. Spracovanie na prijímajúcom stanovišti

9.6.3.2.1. Systém riadenia leteckej prevádzky, ktorý správu COF prijal, sa pokúsi o jej priradenie k príslušnému letovému plánu.

9.6.3.2.2. Príjem správy COF sa okamžite oznámi prijímajúcemu dispečerovi.

9.6.4. Potvrdenie príjmu COF

9.6.4.1. Potvrdenie príjmu

9.6.4.1.1. Ak možno správu COF jednoznačne priradiť k určitému letovému plánu, jej príjem sa potvrdí generovaním a odvysielaním správy LAM.

9.6.4.1.2. Ak správu COF nemožno jednoznačne priradiť k niektorému letovému plánu, jej príjem sa nepotvrdí.

9.6.4.2. Nepotvrdenie príjmu

Ak sa príjem správy COF nepotvrdí odoslaním správy LAM, na príslušnom pracovisku riadenia leteckej prevádzky sa zobrazí výstražná správa.

9.6.5. Príklady

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

9.7. Správa o manuálnom nadviazaní spojenia (MAS)

9.7.1. Účel správy

Správou MAS prijímajúce stanovište oznamuje odovzdávajúcemu, že s letom bolo nadviazané obojsmerné spojenie.

9.7.2. Obsah správy

Správa MAS obsahuje tieto údaje:

- typ správy,

- číslo správy,

- identifikačné údaje lietadla.

POZNÁMKA

Predpisy pre vkladanie dát, formáty a obsah polí sú uvedené v prílohe A.

9.7.3. Vykonávacie predpisy

9.7.3.1. Všeobecné ustanovenia

9.7.3.1.1. Správu MAS môže ručne spustiť prijímajúci dispečer.

9.7.3.1.2. Použitie správy MAS je povinné, ak sa na základe dvojstrannej dohody nepoužíva správa COF.

9.7.3.2. Spracovanie na prijímajúcom stanovišti

9.7.3.2.1. Systém riadenia leteckej prevádzky, ktorý prijal správu MAS, sa pokúsi o jej priradenie k príslušnému letovému plánu.

9.7.3.2.2. Skutočnosť, že správa MAS prišla, sa okamžite oznámi dispečerovi.

9.7.4. Potvrdenie o príjme MAS

9.7.4.1. Potvrdenie príjmu

9.7.4.1.1. Ak možno správu MAS jednoznačne priradiť k určitému letovému plánu, jej príjem sa potvrdí generovaním a odvysielaním správy LAM.

9.7.4.1.2. Ak správu MAS nemožno jednoznačne priradiť k niektorému letovému plánu, jej príjem sa nepotvrdí.

9.7.4.2. Nepotvrdenie príjmu

Ak sa príjem správy MAS nepotvrdí odoslaním správy LAM, na príslušnom stanovišti sa, tak ako sa to vyžaduje, zobrazí výstražná správa.

9.7.5. Príklad

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

[1] Povinné pre TX a REC, ak sa používajú v dialógovom postupe.

[2] Pozri odsek 5.2.1.1. Režim transakčných časov.

[3] Nepoužíva sa vo všetkých konfiguráciách vzdušného priestoru.

[4] M, keď sa odosiela z odovzdávajúceho stanovišťa.

[5] V rámci dvojstranne dohodnutých postupov sa ustanoví, že keď sa odovzdávanie uskutoč- ňuje v určitom danom smere prevádzky, minimálne, buď odovzdávajúce stanovište odošle správu COF alebo prijímacie stanovište odošle správu MAS.

--------------------------------------------------

PRÍLOHA II

ZOBRAZOVANIE VÝMENY DÁT MEDZI SLUŽBAMI LETECKEJ DOPRAVY (ADEXP) 2.0 VYDANIE

(Dokument Eurocontrol značka DPS.ET1.ST09-STD)

OBSAH

AUTORSKÁ DOLOŽKA … PREDSLOV … 1. PÔSOBNOSŤ …

2. ODKAZY …

3. DEFINÍCIE, SYMBOLY A SKRATKY …

3.1 Zápis …

3.2 Definície …

3.3 Konštrukcia …

3.4 Zásady …

3.5 Operátory …

3.6 Skratky …

4. ZÁSADY FORMÁTU ADEXP …

4.1 Textový, človekom čitateľný formát …

4.2 Identifikované a vyhľadateľné polia …

4.3 Neidentifikované polia …

5. SYNTAKTICKÉ PRAVIDLÁ ADEXP …

5.1 Lexikálne jednotky …

5.2 Polia …

6. NORMALIZOVANÝ POPIS SPRÁV VO FORMÁTE ADEXP …

6.1 Úvod …

6.2 Pomocné termíny …

6.3 Definícia primárnych polí …

6.4 Definícia čiastkových polí …

6.5 Skupina správ …

PRÍLOHA A (NORMATÍVNA) DEFINÍCIE POLÍ … PRÍLOHA B (NORMATÍVNA) HLAVNÝ ZOZNAM NÁZVOV SPRÁV VO FORMÁTE ADEXP … PRÍLOHA C (NORMATÍVNA) HLAVNÝ ZOZNAM NÁZVOV REZERVNÝCH SPRÁV … PRÍLOHA D (NORMATÍVNA) HLAVNÝ ZOZNAM REZERVNÝCH POLÍ … PRÍLOHA E (INFORMATÍVNA) ÚVOD DO SKUPÍN SPRÁV … PRÍLOHA F (INFORMATÍVNA) PRÍKLADY SPRÁV VO FORMÁTE ADEXP … PRÍLOHA G (INFORMATÍVNA) ĎAĽŠÍ VÝVOJ … AUTORSKÁ DOLOŽKA

Tento dokument vyhotovila Eurocontrol Agency.

Autorské práva prislúchajú Eurocontrol Agency.

Obsah tohto dokumentu alebo niektorej jeho časti je bez obmedzenia k dispozícii zástupcom členských štátov, poskytnutie jeho odpisu alebo vyzradenie jeho obsahu tretej strane sa však môže uskutočniť len na základe predchádzajúceho písomného súhlasu Eurocontrol Agency.

PREDSLOV

1. Zodpovedný orgán

Túto technickú normu vypracovala a upravuje Sekcia užívateľských požiadaviek Strediska riadenia leteckej dopravy (CFMU) Európskej organizácie bezpečnosti leteckej navigácie (Eurocontrol).

2. Plán práce EATCHIP

Touto technickou normou sa v rámci Plánu práce EATCHIP (EWPD), oblasť systémov na spracovanie dát (DPS), splnila úloha číslo 09.

3. Schválenie technickej normy

3.1. Táto technická norma bola prijatá súlade s postupom uvedeným v smerniciach týkajúcich sa normalizácie Eurocontrol, zn. 000-2-93, vydanie 1.0.

3.2. Ustanovenia tejto technickej normy nadobudli účinnosť po tom, čo jej 1.vydanie v roku 1995 prijala Stála komisia Eurocontrol a začali sa uplatňovať s účinnosťou od 1. decembra 1997.

4. Technické chyby a zmeny a doplnky

Táto technická norma sa neustále skúma, aby sa zistilo, ako ju pozmeniť a doplniť, alebo aby sa odstránili technické chyby. Podmienky upravujúce kontrolu tejto technickej normy sú ustanovené v prílohe H ku smerniciam týkajúcim sa jednotnej osnovy a úpravy technických noriem Eurocontrol.

Zmeny alebo doplnky, ktoré sa týkajú základných zásad alebo gramatiky formátu ADEXP, sa prijmú až po formálnom preskúmaní, ako sa to predpokladá v smerniciach týkajúcich sa jednotnej osnovy a úpravy technických noriem Eurocontrol.

Návrhy na zmeny alebo doplnky k tejto technickej norme sa predkladajú písomne: Sekcii užívateľských požiadaviek CFMU (ADEXP), Eurocontrol Agency.

5. Zásady zostavovania textu

5.1. Formát tejto technickej normy vyhovuje smerniciam týkajúcim sa jednotnej osnovy a úpravy technických noriem Eurocontrol, v niečom sa však od týchto smerníc odkláňa. Menšie odchylky vo formátovaní od týchto smerníc majú zabrániť tomu, aby nedošlo k zámene so zápisom zobrazovania výmeny dát ATS (ADEXP).

5.2. Na vyznačenie právnej sily každého ustanovenia sa použil tento zápis:

- v normatívnych zložkách sa používa oznamovací spôsob a sú vytlačené tenkou latinkou,

- v odporúčaných zložkách sa používa podmieňovací spôsob a boli vytlačené tenkou kurzívou, pričom právnu silu označuje pred ustanovením výraz Odporúčanie.

6. Vzťah k iným technickým normám

Táto technická norma je vo vzťahu k týmto dokumentom:

Technická norma Eurocontrol pre priamu výmenu dát (OLDI)

7. Právna sila príloh k tejto technickej norme

Existuje 6 príloh k tejto technickej norme a majú takúto právnu silu:

Príloha A | normatívna |

Príloha B | normatívna |

Príloha C | normatívna |

Príloha D | normatívna |

Príloha E | informatívna |

Príloha F | informatívna |

Príloha G | informatívna |

8. Použitý jazyk

Pôvodné znenie tejto technickej normy bolo sformulované v anglickom jazyku.

1. PÔSOBNOSŤ

1.1. ADEXP je formát, a nie protokol. Na používanie prenosových médií alebo protokolov sa nevzťahujú žiadne obmedzenia s výhradou súboru znakov.

1.2. Formát ADEXP sa používa predovšetkým on-line, na výmenu správ medzi počítačmi.

1.3. V tomto dokumente sa definujú zásady a syntaktické pravidlá formátu ADEXP. Definujú sa vo forme komplexnej definície polí ADEXP.

1.4. Formát ADEXP sa určil na používanie pri výmene správ v nižšie uvedených oblastiach (o odkazoch na dokumenty pozri oddiel 2, strana 3):

- Plánovanie letu: výmena dát o letovom pláne a s tým súvisiacich správ medzi integrovaným systémom spracovania počiatočného letového plánu (IFPS), službami leteckej dopravy (ATS) a palubnými rádiotelegrafistami (AO). (Dokument odk.3)

- Riadenie leteckej dopravy (ATFM): výmena správ medzi taktickým systémom CFMU, AO a ATS. (Dokument odk.5)

- Koordinácia riadenia leteckej prevádzky: výmena taktických koordinačných správ medzi stanovišťami riadenia leteckej prevádzky (ATCU). (Dokument odk.6)

- Riadenie využívania vzdušného priestoru: výmena dát medzi vnútroštátnymi stanovišťami ATS, CFMU a AO o využiteľnosti vzdušného priestoru. (Dokument odk.7)

- Koordinácia civilných/vojenských letov: správy obsahujúce údaje o civilných/vojenských letoch a správy o prelete vzdušným priestorom. (Dokument odk.7).

1.5. Presné údaje o používaní a obsahu správ v rámci každej z vyššie uvedených skupín sa nachádzajú v dokumentoch, na ktoré sa odkazuje.

2. ODKAZY

2.1. Tieto dokumenty a technické normy obsahujú ustanovenia, ktoré sa stávajú ustanoveniami tejto technickej normy Eurocontrol v dôsledku toho, že sa na ne táto technická norma odvoláva.

V čase zverejnenia tejto technickej normy Eurocontrol boli dokumenty, na ktoré sa tu odvoláva, platné v uvedenom vydaní.

Zohľadní sa každá úprava dokumentov ICAO, na ktoré sa tu odvoláva, a v súlade s tým sa upraví táto technická norma Eurocontrol.

Úpravy iných dokumentov, na ktoré sa tu odvoláva, sa stanú súčasťou ustanovení tejto technickej normy Eurocontrol až po ich formálnom posúdení a začlenení do tejto technickej normy Eurocontrol.

V prípade, že požiadavky obsiahnuté v tejto technickej norme Eurocontrol nie sú v súlade s obsahom spomínaných dokumentov, na ktoré sa tu odvoláva, prednosť má táto technická norma Eurocontrol.

2.2. V čase zverejnenia táto technická norma obsahovala odkazy na nižšie uvedené dokumenty, avšak užívateľov žiadame, aby si používanie a tabuľky zloženia polí správ preverili v najnovších vydaniach týchto dokumentov.

1. ICAO Chicago Convention príloha 10, zväzok I, vydanie z novembra 1985;

2. ICAO Chicago Convention príloha 10, zväzok II, vydanie z júla 1995;

3. IFPS and RPL Dictionary of Messages, vydanie 1.0 z marca 1998;

4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, vydanie z novembra 1985 (vrátane prílohy č.6 z novembra 1995);

5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, vydanie 6.0, platné od marca 1998;

6. Eurocontrol Standard for On-Line Data Interchange, vydanie 2.0 z októbra 1996;

7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Coordination, vydanie 1.0 z mája 1996.

3. DEFINÍCIE, SYMBOLY A SKRATKY

3.1. Zápis

Na zapísanie definície syntaxe sa používa vzorec, ktorý sa nazýva Backus Naurova forma (BNF). BNF definuje súbor spojení, ktorý vymedzuje určitu triedu znakových reťazcov. V tomto prípade predstavuje túto triedu znakových reťazcov súbor správ, ktoré možno nazvať syntakticky platnou správou vo formáte ADEXP.

3.2. Definície

Na účely tejto technickej normy Eurocontrol platia tieto definície:

Rozlišujúci znak : Znak alebo súbor znakov, ktorý možno "vyčleniť" na základe lexikálneho rozboru na základe prítomnosti oddeľovačov.

Symbol : "Termín", ktorý sa vyskytuje v určitom vzorci BNF, no nie je znakom.

Koncový symbol : Symbol, ktorý sa znázorňuje určitým sledom znakov.

Nekoncový symbol : Symbol, ktorý sa znázorňuje jedným alebo viacerými symbolmi.

POZNÁMKA

Nekoncový symbol môže byť znázornený aj kombináciou koncových a nekoncových symbolov.

3.3. Stavba

3.3.1 BNF pozostáva zo súboru určitých spojení alebo konštrukcií v tvare:

symbol::= výraz

POZNÁMKY

1) Zápis "::=" by sa mal čítať ako "možno nahradiť (čím)".

2) "Symbol" sa klasifikuje ako nekoncový.

3) Časť "výraz" obsahuje koncové a nekoncové symboly.

3.3.2. Koncové symboly sa znázorňujú priamo ako určitý sled znakov, ktorý možno na základe lexikálnej analýzy pomocou oddeľovačov vyčleniť ako rozlišovací znak.

3.4. Zásady

Na účely tejto technickej normy platia tieto zásady:

- Koncové

symboly sa zapisujú veľkými písmenami.

POZNÁMKA

Koncový symbol NIL spravidla zastupuje "nekoncový symbol".

Používa sa napríklad v takejto podobe:

a::= b (cNIL), kde a možno nahradiť (b, po ktorom nasleduje c) alebo len b.

- Nekoncové symboly (napr. ľavá strana gramatického útvaru) sa zapisujú malými písmenami.

- Znaky a reťazcové literály, ktoré sa vyskytujú vo vnútri spojení, sa uzatvárajú do jednoduchých (') alebo obyčajných (”) úvodzoviek.

Príklady

1) SPOJOVNÍK::= '-'

2) title(názov správy)::= '-' "TITLE" titleid

Pri niektorých aplikáciach modelovania dát sa môže stať, že koncové symboly je potrebné od nekoncových odlíšiť aj inak než len veľkými a malými písmenami.

Vždy, keď je potrebné explicitne rozlíšiť koncové symboly od nekoncových inak než veľkými a malými písmenami, odporúča sa vložiť takto predponu: "_at" namiesto Auxiliary term (pomocný výraz), "_pf" namiesto Primary field (primárne pole a "_sf" namiesto čiastkové pole.

3.5. Operátory

Na účely tejto technickej normy Eurocontrol sa používajú tieto operátory:

Nepovinné použitie: Keď je prípustné, aby sa niektoré symboly buď vyskytovali, alebo nevyskytovali v príslušnom gramatickom výraze. Nepovinné symboly sa uzatvárajú do hranatých zátvoriek "["a"]".

Uzatvorenie: Keď sa určitá skupina symbolov môže vyskytnúť nula alebo viackrát. Tieto symboly sú uzatvorené v zložených zátvorkách "{"a"}". Ak sa pred "{"uvedie určité číslo, vyjadruje, koľkokrát minimálne sa môže určitá skupina symbolov vyskytnúť. Ak sa určité číslo uvedie za"}", vyjadruje, koľkokrát maximálne sa môže vyskytnúť určitá skupina symbolov.

Voľba: Keď sa na určitom mieste v gramatickom výraze môže vyskytnúť viacero alternatívnych symbolov. Voľba sa znázorňuje "".

Zreťazenie: Znázornenie symbolov, ktoré sú usporiadané v určitej postupnosti, aj keď sa medzi nimi môže vyskytnúť jeden či viacero oddeľovačov. Explicitne sa to neznázorňuje. Sú dva typy zreťazenia:

- Pevné zreťazenie: na lexikálnej rovine môžu vzorce obsahovať zreťazené koncové symboly, ktoré naznačujú, že nasledujú tesne jeden po druhom (oddeľovač sa medzi nimi nevyskytuje), v takom prípade sa používa symbol

"!"

.

Príklad

datetime::= date! timehhmm

Napr. "9912251200" , čo značí 25. decembra 1999 o 12.00 hod.

- Voľné zreťazenie: pripúšťa sa prítomnosť oddeľovačov medzi koncovými symbolmi. Voľné zreťazenie možno v určitom spojení znázorniť buď implicitne alebo explicitne.

Príklady

1) Implicitne:

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

2) Explicitne:

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

napr. | "-DCT NTM HMS". |

POZNÁMKY

1) Zreťazenie má vždy prednosť pred voľbou. Zátvorky ("("a ")") sa používajú na zmenu v usporiadaní pri vyhodnocovaní výrazu.

Napríklad

a::= B C D | sa rovná: | a::= (B C) D |

| a NIE: | a::= B (C D) |

2) Z dôvodov zachovania čitateľnosti zostane ve všetkých pravidlách povolená prítomnosť separátorov medzi symbolmi implicitná.

Odporúčanie

Ak v dôsledku toho, že jeden z vyššie uvedených operátorov má prednosť pred druhým, vzorec nemusí byť jednoznačný, odporúča sa upresniť požadované usporiadanie pri vyhodnocovaní zátvorkami.

3.6. Skratky

Na účely tejto technickej normy Eurocontrol sa používajú tieto skratky:

ACH | ATC Flight Plan Amendment Message - Správa o zmene letového plánu ATC |

ADEG | ATS Data Exchange Group - Skupina výmeny dát ATS |

ADEXP | ATS Data Exchange Presentation - Zobrazovanie výmeny dát ATS |

AFIL | Air-Filed Flight Plan - Palubný letový plán |

AFP | ATC Flight Plan Proposal - Návrh letového plánu ATC |

AFTN | Aeronautical Fixed Telecommunications Network - Leteckonavigačná pevná telekomunikačná sieť |

ANM | ATFM Notification Message - Správa o hlásení ATFM |

AO | Aircraft Operator(s) - Palubný rádiotelegrafista |

APL | ATC Flight Plan - Letový plán ATC |

ATC | Air Traffic Control - Riadenie leteckej prevádzky |

ATCU | Air Traffic Control Units - Stanovištia riadenia leteckej prevádzky |

ATFM | Air Traffic Flow Management - Riadenie leteckej dopravy |

ATS | Air Traffic Services - Služby leteckej dopravy |

BNF | Backus Naurova forma |

CASA | Computer Assisted Slot Allocation - Prideľovanie časových úsekov na pristátie počítačom |

CIDIN | Common ICAO Data Interchange Network - Spoločná sieť výmeny dát ICAO |

CFL. | Cleared Flight Level - Povolená letová hladina |

CFMU | Central Flow Management Unit - Stredisko riadenia leteckej dopravy |

CMTP | Common Medium-Term Plan - Spoločný strednodobý plán |

CNL | Cancellation Message - Správa o zrušení letového plánu |

CTOT | Calculated Take-Off Time - Vypočítaný čas vzlietnutia |

DPS | Data Processing Systems Domain - Oblasť systémov na spracovanie dát |

ECAC | European Civil Aviation Conference - Konferencia Európskej organizácie civilného letectva |

EFL | Estimated Flight Level - Odhadovaná letová hladina |

EOBT | Estimated Off-Block Time - Odhadovaný Off-Block time |

ETO | Estimated Time Over - Odhadovaný čas do preletu hranice |

Eurocontrol | European Organisation for the Safety of Air Navigation - Európska organizácia pre bezpečnosť leteckej navigácie |

EWPD | EATCHIP Work Programme Document - Plán práce EATCHIP |

FIR | Flight Information Region - Letový informačný priestor |

FIW | Flight Plan Input Station - Vstupná stanica letového plánu |

FMP | Flow Management Position - Pracovisko riadenia leteckej dopravy |

FNM | Flight Notification Message - Hlásenie o lete |

FPL | Flight Plan Message - Správa o letovom pláne (formát ICAO) |

GAT | General Air Traffic - Verejná letecká doprava |

IA | International Alphabet - Medzinárodná abeceda |

IAFP | Individual ATC Flight Plan Proposal - Návrh individuálneho letového plánu ATC |

ICAO | International Civil Aviation Organisation - Medzinárodná organizácia civilného letectva |

IFPD | Individual Flight Plan Data - Dáta individuálneho letového plánu |

IFPS | Integrated Initial Flight Plan Data Processing System - Integrovaný systém spracovania počiatočného letového plánu |

IFPU | IFPS Unit - Stanovište IFPS |

IFR | Instrument Flight Rules - Pravidlá letu podľa prístrojov |

ISO | International Standards Organisation - Medzinárodná organizácia pre normalizáciu |

ITA | International Telegraph Alphabet - Medzinárodná telegrafická abeceda |

LAM | Logical Acknowledgement Message - Správa o logickom potvrdení príjmu |

LRM | Logical Rejection Message - Správa o logickom odmietnutí |

MAC | Coordination Abrogation Message - Správa o zrušení koordinácie |

MFS | Message from Shanwick - Správa zo Shanwicku |

OAT | Operation Air Traffic - Prevádzka leteckej dopravy |

OLDI | On-Line Data Interchange - Priamy prenos dát |

RFL | Requested Flight Level - Požadovaná letová hladina |

RFP | Replacement Flight Plan - Náhradný letový plán |

RFPD | Repetitive Flight Plan Data - Dáta periodického letového plánu |

RPL | Repetitive Flight Plan - Periodický letový plán |

RVR | Runway Visual Range - Dohľadnosť na vzletovej a pristávacej letiskovej dráhe |

SFL | Supplementary Flight Level - Dodatková letová hladina |

SRD | Software Requirements Document - Požiadavky na softvérové vybavenie |

SSR | Secondary Surveillance Radar - Sekundárny prehľadový rádiolokátor |

TACT | Tactical System of the CFMU - Taktický systém CFMU |

TOS | Traffic Orientation Scheme - Schéma smerovania dopravy |

UIR | Upper Information Region - Horný informačný priestor |

VFR | Visual Flight Rules - Pravidlá pre vizuálny let |

4. PRINCÍPY FORMÁTU ADEXP

4.1. Textový, človekom čitateľný formát

4.1.1. ADEXP je textový formát, ktorý je založený na znakoch.

4.1.2. Správy vo formáte ADEXP môže prečítať človek-operátor, vďaka čomu možno lepšie rozvrhnúť typy písma alebo vyriešiť operačné problémy.

4.1.3. Textový formát je aj otvorenejší a ľahšie pochopiteľný.

4.2. Identifikované a vyhľadateľné polia

4.2.1. Správa vo formáte ADEXP pozostáva z polí.

4.2.2. Polia vymedzuje osobitný znak začiatku poľa, spojovník (

"-"

), a identifikujú príslušné kľúčové polia.

POZNÁMKA

Poznamenávame, že určité polia (tie, ktoré obsahujú lexikálnu jednotku 'ZNAK') môžu obsahovať znak ("-"), ktorý je súčasťou obsahu takéhoto poľa.

4.2.3. Zvyšuje sa tým rozšíriteľnosť a odolnosť formátu. (Ak určité pole chýba, alebo ak je nesprávne, možno ho preskočiť a zvyšnú časť správy napriek tomu vyhodnotiť. (Pozri oddiel 4.3.)

4.2.4. Okrem toho to znamená, že pri posudzovaní prípustnosti určitej správy nezáleží na tom, v akom slede sú v nej usporiadané jednotlivé polia, s výhradou prvého poľa ((povinné pole názvu typu správy), ktoré vymedzuje prípustné polia.

4.2.5. Polia môžu byť základné alebo zložené.

4.2.6. Zložky zložených polí sa nazývajú čiastkové polia a definuje ich prítomnosť kľúčových slov, ktoré sú vymedzené znakom začiatku poľa.

4.2.7. Základné polia neobsahujú čiastkové polia.

4.2.8. Základné alebo zložené polia, ktoré tvoria prvú rovinu definície určitej správy, sa nazývajú primárne polia.

4.2.9. Všetky zložky na nižšej rovine sú spravidla čiastkové polia, ktoré takisto môžu byť základné alebo zložené.

4.2.10. Zložené polia sú dvojaké, štruktúrované alebo zoznamové.

4.2.11. Štruktúrované polia majú vopred určený obsah, ktorý pozostáva výlučne z čiastkových polí. V štruktúrovanom poli NEZÁLEŽÍ na poradí čiastkových polí.

4.2.12. Zoznamové pole uvádza kľúčové slovo BEGIN a ukončuje kľúčové slovo END. Medzi nimi sa môže opakovane vyskytnúť jedno a to isté pole alebo kombinácia polí. Poradie, v akom sa v zoznamovom poli vyskytujú, je sématicky závažné.

4.2.13. Nižšie sa termínom "pole" vo všeobecnosti označujú primárne alebo čiastkové polia, pokiaľ sa výslovne nekvalifikujú inak.

4.2.14. Polia, ktoré sa nachádzajú v určitej správe, môžu byť nepovinné alebo povinné, podľa toho, ako to definuje ich syntax.

4.3. Neidentifikované polia

4.3.1. Ak sa v určitej správe vyskytne neznáme pole, neberie sa do úvahy.

4.3.2. Inými slovami, ak systém, ktorý správu analyzuje, nespozná určité kľúčové slovo, celý text, až po najbližšie známe primárne pole, ktoré sa nenachádza vo vnútri zoznamového poľa, sa nezoberie do úvahy.

4.3.3. Ak sa určité pole neberie do úvahy, môže alebo nemusí to spôsobiť odmietnutie analyzovanej správy. Záleží na tom, o aký typ správy ide.

POZNÁMKA

Poznamenávame, že aj keď formát ADEXP je zostavený tak, aby bol v tomto ohľade pružný, pracovníci zodpovední za definovanie požiadaviek kladených na prepojenie podľa vlastného uváženia pri každom type správy určia, ako má systém reagovať na neidentifikované pole.

4.3.4. Ak je neznámym poľom zoznamové pole (zistilo sa to vďaka kľúčovému slovu -BEGIN), potom sa neberie do úvahy celý jeho obsah (až po príslušné kľúčové slovo -END).

4.3.5. V záujme toto, aby sa počas zotavovania systému, ktoré nasleduje po preskočení neidentifikovaného poľa, predišlo nejednoznačnosti, požaduje sa, aby kľúčové slovo uvádzalo buď primárne pole, alebo čiastkové pole.

4.3.6. Vzhľadom na to, možno vymedziť dva druhy kľúčových slov:

- primárne kľúčové slová,

- čiastkové kľúčové slová.

4.3.7. Len čo sa definuje druh určitého kľúčového slova, v inej skupine správ sa viac nepoužíva vo funkcii druhého druhu, s jedinou výnimkou, ak sa nachádza vo vnútri zoznamového poľa. Primárne kľúčové slovo sa môže v zoznamovom poli vyskytnúť na ktoromkoľvek mieste, a nedôjde k nejednoznačnosti, keďže prítomnosť kľúčového slova BEGIN naznačuje, že vo vnútri zoznamového poľa ho možno považovať za čiastkové pole.

Príklady (použitia rôznych druhov kľúčových slov)

1) Primárne pole

- RFL F330

2) Čiastkové pole: spravidla vo vnútri "zloženého poľa"

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

kde -GEO je primárne zložené pole a -GEOID, -LATID a LONGTD sú čiastkové polia.

3) Zoznamové pole

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

…

-END RTEPTS

kde "-BEGIN" je indikátor zoznamového poľa a "RTEPTS" je primárne pole

POZNÁMKA

"RFL" sa definuje ako primárne pole. Zahrnutie do zoznamového poľa predstavuje jediný prípad, keď sa primárne pole môže použiť ako čiastkové pole. (Pozri príklad 3 vyššie).

5. SYNTAKTICKÉ PRAVIDLÁ FORMÁTU ADEXP

5.1. Lexikálne jednotky

5.1.1. Súbor znakov

5.1.1.1. Pri výmene správ vo formáte ADEXP sa používa medzinárodná abeceda č. 5 (IA-56), ako je definovaná v odkaze 1.

5.1.1.2. Formát ADEXP je určený na výmenu správ medzi počítačmi, ktorá môže prebiehať v rôznych počítačových sieťach alebo na vyhradených spojeniach medzi počítačmi. Okrem toho sa vyžaduje, aby výmena niektorých správ vo formáte ADEXP, týkajúcich sa spravidla plánovania letu a ATFM, mohla prebiehať v leteckonavigačnej pevnej telekomunikačnej sieti (AFTN).

5.1.1.3. Súbor znakov správ, ktoré sa majú prenášať cez sieť AFTN, sa obmedzuje na tie znaky, ktoré spolu v medzinárodnej abecede 2 (ITA-2) a IA-5 priamo súvisia, ako sa to definuje v odkaze 1.

POZNÁMKA

Okrem grafických a formátovacích znakov, ako sú definované nižšie sa v súbore znakov ITA-2 definujú "signály" (napríklad perforovaná páska). Správy vo formáte ADEXP nie sú súčasťou prípustného súboru znakov.

5.1.1.4. Znakmi prípustnými v správach vo formáte ADEXP, ktoré sa môžu prenášať cez sieť AFTN, sú nižšie uvedené grafické a formátovacie znaky:

Grafické znaky

a) veľké písmená (od A do Z)

b) číslice (od 0 do 9)

c) tieto osobitné grafické znaky:

1) medzera ""

2) začiatok zátvorky "("

3) koniec zátvorky ")"

4) spojovník "-"

5) otáznik "?"

6) dvojbodka ":"

7) bodka "."

8) čiarka ","

9) apostrof "'"

10) znamienko rovnosti "="

11) znamienko plus "+"

12) lomka "/"

Formátovacie znaky

a) nový riadok

b) znak riadkovania

5.1.2. Základné lexikálne jednotky

V tomto technickom predpise sa používajú tieto základné lexikálne jednotky:

- 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

- MEDZERA ::= ' '

- SPOJOVNÍK ::= '-'

- FEF(form. znak) ::= nový riadok znak riadkovania

- SEP(Odd.) ::= 1{ MEDZERA FEF }

- OSOBITNÉ ::= MEDZERA '(' ')' '?' ':' '.' ',' ''' '=' '+' '/'

- ZNAK ::= ALPHA DIGIT OSOBITNÝ FEF SPOJOVNÍK

- LIM-CHAR ::= ALPHA DIGIT OSOBITNÝ FEF

- ZAČIATOK POĽA ::= SPOJOVNÍK

POZNÁMKA

LIM_CHAR predstavuj ktorýkoľvek prípustný znak s výhradou SPOJOVNÍKA, ktorý označuje výlučne začiatok poľa. Naproti tomu ZNAK predstavuje ktorýkoľvek prípustný prvok zo súboru znakov.

5.1.3. Riadky, oddeľovače a obmedzovače

5.1.3.1. Rozdelenie textu správy na riadky nemá žiadny vplyv na syntax.

5.1.3.2. Oddeľovačom môže byť medzera alebo formátovací znak.

5.1.3.3. Polia sú vymedzené len prítomnosťou znaku začiatku poľa, za ktorým nasleduje kľúčové slovo.

5.1.3.4. Preto je prípustné, aby celá správa bola v jednom riadku.

5.1.4. Hodnoty so znamienkom

5.1.4.1. Môže sa stať, že určitú číselnú hodnotu je potrebné uviesť ako zápornú.

5.1.4.2. V poliach, v ktorých sa má uvádzať záporná hodnota, sa výslovne uvádza 'hodnota so znamienkom', t.j. kladná alebo záporná. Pole, ktoré takto nebolo definované, nemôže znázorňovať zápornú hodnotu.

5.1.4.3 Pred 'hodnotou so znamienkom' sa spravidla nachádza písmeno 'N', čo značí záporná, alebo 'P', čo značí kladná.. Pred nulovou hodnotou sa môže nachádzať buď 'N'alebo 'P'.

5.1.4.4 Syntax poľa, ktoré pripúšťa 'hodnotu so znamienkom', má túto podobu:

'-' ”KĽÚČOVÉ SLOVO” (”P” ”N”) ! 1{DIGIT}8

Takže:

— ČÍSLO P5 - hodnota 'čísla' je +5

— ČÍSLO N5 - hodnota 'čísla' je -5

— ČÍSLO 5 - neplatná syntax, vyskytovať sa musí buď 'P' alebo 'N'

5.1.5. Kľúčové slová

5.1.5.1. Kľúčové slovo je ľubovoľný sled veľkých písmen alebo číslic. Pole uvádza len vtedy, keď je pred ním znak začiatku poľa ('-').

Kľúčové slovo ::= 1{ ALPHANUM }

5.1.5.2. Kľúčové slová sa riadia touto syntaxou:

'-'!{SEP}!”KĽÚČOVÉ SLOVO”!1{SEP}! < čiastkové pole alebo obsiahnutá hodnota >

t.j. kľúčové slovo oddeľuje od 'znaku začiatku poľa' nula alebo viac oddeľovačov a bezprostredne za ním nasleduje jeden alebo viacero oddeľovačov a za nimi príslušné čiastkové polia alebo obsiahnutá hodnota.

POZNÁMKA

Poznamenávame, že kľúčové slovo môže, ale nemusí byť od znaku začiatku oddelené viacerými oddeľovačmi.

Príklady (Tieto postupnosti všetky prípustne uvádzajú určité pole)

1) - TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) - TITLE IFPL

5.1.5.3. Odporúčanie

Odporúča sa nepoužívať odlučovač medzi znakom začiatku poľa '-' a nasledujúcim kľúčovým slovom.

POZNÁMKA

1) Vo vyššie uvedených príkladoch sa odporúča prvá možnosť.

2) Takisto poznamenávame, že po kľúčovom slove musí bezprostredne nasledovať aspoň jeden odlučovač.

5.1.5.4. V celom tomto dokumente zreťazenie prvkov oddelených aspoň jedným oddeľovačom implicitne znázorňuje zápis 'voľného zreťazenia' (pozri 3.5).

POZNÁMKA

Ako vysvetlíme nižšie, ak kľúčovým slovám predchádza kľúčové slovo BEGIN, uvádzajú aj zoznamové polia.

5.1.5.5. Kľúčové slová sú čo najkratšie, pričom si zachovávajú svoj sémantický význam.

5.1.5.6. Definícia vopred definovaných kľúčových slov vo formáte ADEXP, ktoré sú uvedené nižšie, sa v osobitých prípadoch použitia tohto formátu nemení, ani sa nepoužívajú v inej funkcii:

TITLE (názov správy): | určuje kategóriu správ a vymedzuje príslušný súbor prípustných primárnych polí, |

BEGIN (začiatok): | označuje začiatok zoznamového poľa; |

END (koniec): | označuje koniec zoznamového poľa; |

COMMENT (poznámka): | označuje POZNÁMKOVÉ pole. |

5.1.5.7. V záujme toho, aby sa predišlo nejednoznačnosti (duplicitnému použitiu jedného a toho istého kľúčového slova v rôznych významoch) alebo zbytočnému používaniu (rôznych kľúčových slov v rovnakom význame), do prílohy A (A3) k tejto technickej norme je zaradená hlavná tabuľka definícií primárnych polí a do prílohy A (A4) k tejto technickej norme hlavná tabuľka definícií čiastkových polí (t.j. čiastkových kľúčových slov).

5.2. Polia

5.2.1. Syntax polí

pole ::= základné_ pole štruktúrované pole zonamové_pole

základné_pole ::= '-' hodnoty_ obsiahnuté v kľúčovom slove

obsiahnuté_hodnoty ::= {ZNAK}

zoznamové_pole ::= "BEGIN (začiatok)" kľúčové slovo {čiastkové polia}'-' "END (koniec)" kľúčové slovo

štruktúrované _ pole ::= '-' kľúčové slovo pole_1 pole_2……….pole n

POZNÁMKA

Ako ešte uvidíme, ak ide o zoznamové polia, kľúčovému slovu bezprostredne nepredchádza '-' ale spojenie '-' "BEGIN".

5.2.2. Zloženie správy z polí

5.2.2.1. Prvým poľom správy vo formáte ADEXP je spravidla pole TITLE(názov správy) (t.j. pole, ktoré je uvádzané kľúčovým slovom TITLE(názov správy).

5.2.2.2. Zvyšný obsah správy z hľadiska jej primárnych polí určuje TITLE(názov správy)

5.2.2.3. Syntax správ, ktoré zodpovedajú danému TITLE(názvu správy), určujú polia(definované kľúčovými slovami), ktoré takáto správa obsahuje.

- Názov a prípustný obsah jej primárnych polí,

- Názov a prípustný obsah jej čiastkových polí.

5.2.3. Základné polia

5.2.3.1. Základné pole má takúto syntax:

základné_pole ::= '-' hodnoty_ obsiahnuté v kľúčovom slove

5.2.3.2. 'Obsiahnuté hodnoty' definujú text, ktorý vyjadruje hodnotu poľa a nesmie stáť pred žiadnym čiastkovým poľom.

Príklad vzorca

arctyp ::= '-' "ARCTYP" (icaoaircrafttype "ZZZZ")

POZNÁMKA

1) Čo sa dá vyjadriť aj takto:

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

2) Časť správy má podobu :: ”-ARCTYP ZZZZ”.

5.2.3.3. Odporúčanie

Ak základné pole obsahuje viac ako jednu hodnotu a na dôvažok je potrebné spomedzi hodnôt 'zvoliť jednu' alebo 'vybrať alternatívnu', odporúča sa vytvoriť štruktúrované pole a hodnoty zahrnúť do čiastkových polí.

5.2.4. Zoznamové polia

5.2.4.1. Zoznamové polia majú takúto syntax:

zoznamové_pole ::='-' "BEGIN" kľúčové slovo {čiastkové polia} '-' "END" kľúčové slovo

5.2.4.2. 'Čiastkové polia' môžu pozostávať z ľubovoľnej kombinácie čiastkových polí, ktoré sa v zoznamovom poli môžu vyskytnúť nula alebo viackrát.

5.2.4.3. Čiastkové polia obsiahnuté v zoznamovom poli tvoria usporiadaný súbor (záleží na poradí, v akom sú čiastkové polia usporiadané).

Príklad vzorca

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

POZNÁMKA

1) Z tohto príkladu vyplýva, že pole 'addr' je zoznamové pole, ktoré obsahuje 0 alebo viacero čiastkových polí 'fac' (zariadenie ATS).

2) Časť správy obsahujúcej ADDR v podobe zoznamového poľa obsahujúceho čiastkové polia FAC môže mať napríklad takúto podobu:

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

3) Časť správy obsahujúcej kombináciu čiastkových polí môže mať napríklad takúto podobu:

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

5.2.5. Štruktúrované polia

5.2.5.1. Štruktúrované polia majú takúto syntax:

štrukturované_pole ::='-'kľúčové slovo pole_1 pole_2…..pole_n

5.2.5.2. Výskyt prípustných čiastkových polí v danom štruktúrovanom poli podmieňuje len samotné štrukturované pole.

5.2.5.3. Na poradí čiastkových polí v štruktúrovanom poli nezáleží, vďaka čomu sa ľahko rozširuje (o ďalšie čiastkové polia).

Príklad vzorca

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

POZNÁMKY

1) Takto sa pole "ptid" definuje ako štruktúrované pole, ktoré obsahuje určitý bod (čiastkové pole "ptid" ), po ktorom môže nasledovať vypočítaná letová hladina (čiastkové pole "fl" ), prípadne odhadovaný čas preletu týmto bodom (čiastkové pole "eto").

2) Toto pole sa môže vyskytnúť napríklad v tejto podobe:

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

5.2.5.4. Odporúčanie

Vždy keď sa predpokladá, že obsah určitého poľa sa v budúcnosti rozšíri, sa odporúča, aby sa vyhotovilo v štruktúrovanej podobe. Vďaka tomu sa bude postupne dať rozširovať o čiastkové polia. Naopak, základné pole sa azda jednoduchšie používa, vyžaduje však presne vymedzený sled prvkov (hodnôt), pričom možnosti jeho ďalšieho rozširovania sú veľmi obmedzené.

5.2.6. POZNÁMKOVÉ pole

5.2.6.1. Poznámkové pole uvádza určitú oblasť voľného textu, v ktorom možno použiť všetky dostupné znaky s výnimkou znaku začiatku poľa ('-') a ktoré siaha až po najbližšie pole.

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

Príklad

COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

5.2.7. Pole TITLE (názvu správy)

5.2.7.1. Prvým poľom správy vo formáte ADEXP je spravidla pole názvu správy. Má takúto syntax:

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

5.2.7.2. Prípustné hodnoty poľa názvu správy pozostávajú zo súboru názvov správ vo formáte ADEXP, ako je to uvedené v prílohe B k tejto technickej norme.

Príklad

-TITLE IFPL

6. NORMALIZOVANÝ POPIS SPRÁV VO FORMÁTE ADEXP

6.1. Úvod

6.1.1. Normalizovaný spôsob popisovania rôznych kategórií správ vo formáte ADEXP v rámci tejto technickej normy sa definuje v odsekoch nižšie:

6.1.2. Normalizovaný popis zahŕňa:

- Definíciu pomocných termínov,

- Definíciu syntaxe a sémantiky každého primárneho poľa,

- Definíciu syntaxe a sémantiky každého čiastkového poľa,

- Definíciu každej skupiny správ na základe ich definujúcej dokumentácie.

6.1.3. Táto technická norma neustanovuje osobitne pre každý názov správy pravidlá týkajúce sa zloženia poľa a vkladania dát.

6.1.4. Mala by sa použiť definujúca dokumentácia (špecifikácia prepojenia), ktorá sa vzťahuje na príslušnú skupinu správ (pozri oddiel 6.5.7.)

6.1.5. Definujúca dokumentácia by mala v normalizovanej podobe poskytovať pri každom názve správy tieto informácie:

- zoznam povinných primárnych polí,

- zoznam nepovinných primárnych polí,

- u každého poľa pravidlá týkajúce sa vkladania dát, a to najmä pravidlá týkajúce sa používania čiastkových polí, ktoré sú v tejto technickej norme definované ako nepovinné,

- pravidlá týkajúce sa zotavovania po zistení neidentifikovaného poľa.

6.1.6. Polia, ktoré sa v súčasnosti vo všetkých členských štátoch Eurocontrol definujú a schvaľujú na používanie v rámci rôznych kategórií správ určených na požívanie vo formáte ADEXP, sú uvedené v prílohe A k tomuto dokumentu.

6.1.7. Určité pole sa používa len na účel, ktorý sa uvádza v jeho sémantickom popise.

6.1.8. Hlavný zoznam rezervných polí sa nachádza v prílohe D. Používanie "rezervných polí" v tu definovaných správach vo formáte ADEXP nebolo schválené. Ide spravidla o polia, o ktorých používaní sa uvažuje v budúcnosti, alebo ktoré sa používajú miestne vo vnútroštátnych systémoch. Do tejto technickej normy sa zaraďujú preto, aby sa zabezpečila jednoznačnosť názvov polí a predišlo zbytočnému používaniu.

6.2. Pomocné termíny

6.2.1. V záujme toho, aby sa definícia polí dala ľahko prečítať, je neraz vhodné zaviesť do popisu gramatiky pomocné termíny.

6.2.2. Pomocné termíny neuvádzajú pole, ani čiastkové pole a teda nesúvisia s konkrétnym kľúčovým slovom. Môžu sa však vyskytnúť v definícii viacerých polí, čiastkových alebo pomocných polí. Pomocný termín "date" možno napríklad použiť na definovanie mnohých polí.

6.2.3. Všetky potrebné pomocné termíny sa uvádzajú v abecednom poradí a definujú v prílohe A (A2) tejto technickej normy.

6.2.4. Popis rozčlenený v abecednom poradí, možno spracovať do takejto tabuľky:

pomocný termín | syntax | sémantika | použitie v primárnom poli | použitie v podpoli | použitie v pomoc. poli |

adexpmsg | { CHARACTER } | voľný text podľa syntaxe platnej pre správy ADEXP | | ifpdlong rfpdlong preproctxt postproctxt | |

aidequipment | (('N' 'S')![equipmentcode]) | pomocné rádiokomunikačné, navigačné a približivacie zariadenie | ceqpt | | |

aircraftid | 1{ ALPHANUM }7 | identifikácia lietadla | arcid arcidk arcidold prevarcid | | |

6.3. Definícia primárnych polí

6.3.1. Všetky primárne polia, ktoré sa používajú v správach vo formáte ADEXP, sa riadia sytnaxou a sémantikou, ako sú uvedené v prílohe A (A3) k tejto technickej norme.

6.3.2. Najprv sa uvádza syntax každého poľa, potom jednoznačnými slovami jeho sémantika.

6.3.3. Syntax polí sa vyjadruje pomocou zápisu BNF, ako sa to uvádza v oddieli 3 tejto technickej normy.

6.3.4. Popis, rozčlenený v abecednom poradí, môže mať formu nižšie uvedenej tabuľky, v ktorej:

- Prvý stĺpec predstavuje ľavú časť vzoru BNF (t. j. časť predpisu na ľavej strane od znaku ::=) a tretí stĺpec predstavuje jeho pravú stranu.

- V druhom stĺpci (druh) sa uvádza, či ide o základné ('b') alebo zložené ('c') pole.

primárne pole | druh | syntax | sémantika |

eobt | b | '-' "EOBT" timehhmm | odhadovaný mimoblokový (Off-Block) čas |

6.4. Definície čiastkových polí

6.4.1. Všetky čiastkové polia, ktoré sa používajú v správach vo formáte ADEXP, sa riadia syntaxou a sémantikou, ako sú uvedené v prílohe A (A4) k tejto technickej norme.

6.4.2. Okrem toho sa na účely krížového odkazu uvádzajú primárne polia vo vnútri daného čiastkového poľa.

6.4.3. Určité čiastkové pole môže byť takisto čiastkovým poľom iných čiastkových polí, a preto sa uvádza aj krížový odkaz na tieto čiastkové polia.

6.4.4. Popis, rozčlenený v abecednom poradí, možno usporiadať do takejto tabuľky:

podpole | druh | syntax | sémantika | použitie v primárnom poli | použitie v podpoli |

brng | b | '-' "BRNG" refbearing | odchýlka (poloha) určitého bodu od navigačnej pomôcky (vyjadrená v magnetických stupňoch) | ref | |

6.5. Skupina správ

6.5.1. Operačné kategórie (skupiny) správ, ktoré boli vymedzené na používanie vo formáte ADEXP, sa uvádzajú v prílohe E tejto technickej normy.

6.5.2. Skupiny správ sa vymedzujú podľa operačnej povahy vymieňaných správ a neraz ich charakterizujú príslušné systémy.

6.5.3. Pri každej skupine správ sa uvádza definujúca dokumentácia.

6.5.4. Hodnota názvu, ktorá sa použila na označenie určitej skupiny správ, sa viac nesmie použiť na označenie inej skupiny, majúcej iný význam.

6.5.5. Hlavný zoznam názvov správ sa vedie v prílohe B k tejto technickej norme.

6.5.6. Pri každom názve správy, ktorý je uvedený v hlavnom zozname názvov správ, sa uvádza odkaz na príslušnú skupinu správ. Pri každom názve správy sa teda vo forme odkazu na príslušnú skupinu správ uvádza definujúca dokumentácia.

6.5.7. Takisto sa uvádza aj hlavný zoznam názvov rezervných správ, ktorý sa nachádza v prílohe C. Používanie "názvov rezervných správ" v tu vymedzených skupinách správ vo formáte ADEXP nebolo schválené. Ide spravidla o správy, o ktorých používaní v jednej z vymedzených skupín sa prípadne uvažuje v budúcnosti, alebo ktoré sa používajú miestne vo vnútroštátnych systémoch. Do tejto technickej normy sa zaraďujú preto, aby sa zabezpečila jednoznačnosť názvovo správ a predišlo zbytočnému používaniu.

--------------------------------------------------

PRÍLOHA III

VÝMENA LETOVÝCH DÁT - DOKUMENT KONTROLY PREPOJENIA (FDE-ICD), VYDANIE 1.0

(Dokument Eurocontrol značka COM.ET1.ST12-STD)

OBSAH

AUTORSKÁ DOLOŽKA… PREDSLOV… 1. ÚVOD…

2. PÔSOBNOSŤ…

3. ODKAZY…

3.1. Úvod…

3.2. Odkazy…

4. DEFINÍCIE, SYMBOLY A SKRATKY…

4.1. Definície…

4.2. Symboly a skratky…

4.3. Zápisy…

5. TECHNICKÝ PREHĽAD…

5.1. Zásobník protokolov…

5.2. Štruktúra profilu…

5.3. Vzťah k predchádzajúcim verziám technického predpisu…

6. POŽIADAVKY NA PROFIL…

6.1. Predpisové požiadavky…

6.2. Požiadavky na vyššiu vrstvu…

6.3. Požiadavky na nižšiu vrstvu…

6.3.1. Požiadavky na prenosovú vrstvu…

6.3.2. Požiadavky na sieťovú vrstvu…

6.3.3. Požiadavky na spojovaciu vrstvu…

6.3.4. Požiadavky na fyzickú vrstvu…

7. SKÚŠOBNÉ METÓDY…

PRÍLOHA A (NORMATÍVNA) PROTOKOL PRENOSU SPRÁV… A.1. Úvod…

A.2. Realizácia služby…

A.3. Prevzatie funkcie služby…

A.4. Technický predpis protokolu…

A.4.1. Úvod…

A.4.2. Typy dát…

A.4.3. Vytvorenie spojenia…

A.4.4. Prenos dát…

A.4.5. Korektné prerušenie spojenia…

A.4.6. Obnovenie spojenia…

A.4.7. Neporušenosť spojenia…

A.4.8. Nekorektné prerušenie spojenia…

A.4.9. Zotavenie zo zlyhania…

A.4.10. Formáty správ…

A.5. Tabuľky prechodu medzi stavmi protokolu…

A.5.1. Úvod…

A.5.2. Definície stavov…

A.5.3. Možné udalosti…

A.5.4. Časovače…

A.5.5. Tabuľka prechodu medzi stavmi…

A.5.6. Diagram prechodu medzi stavmi…

PRÍLOHA B (NORMATÍVNA) PROTOKOL ZÁHLAVIA SPRÁV… B.1. Úvod…

B.2. Realizácia služby…

B.3. Prevzatie funkcie služby…

B.4. Technický predpis protokolu…

B.4.1. Vytvorenie spojenia…

B.4.2. Odstránenie nadbytočných sieťových spojení…

B.4.3. Zrušenie spojenia…

B.4.4. Prenos dát…

PRÍLOHA C (NORMATÍVNA) SIEŤOVÝ PROTOKOL… C.1. Úvod…

C.2. Poskytovanie služby…

C.3. Predpokladané služby…

C.4. NSAP adresovanie…

C.4.1. Úvod…

C.4.2. Štruktúra NSAP adresy…

C.4.3. Prideľovanie identifikátorov a selektorov stanovíšť ATC…

C.5. Technické parametre protokolu…

C.5.1. Súhrn…

C.5.2. Zakódovanie adresy…

C.5.3. Zakódovanie užívateľského poľa dát…

C.5.4. Ošetrenie adries v balíkoch INCOMING CALL (príchodzí hovor)…

C.5.5. Prenos dát…

PRÍLOHA D (NORMATÍVNA) PROFILOVO ŠPECIFICKÉ PROFORMY PICS… D.1. Úvod…

D.2. Pokyny na vyplňovanie proforiem PICS…

D.2.1. Jednotná štruktúra proforiem PICS…

D.2.2. Doplňujúce informácie…

D.2.3. Výnimočné informácie…

D.2.4. Podmienené položky…

D.3. Proforma PICS pre protokol prenosu správy…

D.3.1. Skratky a zvláštne znaky…

D.3.2. Identifikácia…

D.3.3. Implementácia protokolu…

D.4. Proforma PICS pre protokol záhlavia správy…

D.4.1. Skratky a zvláštne znaky…

D.4.2. Identifikácia…

D.4.3. Implementácia protokolu…

D.5. Proforma PICS pre sieťový protokol…

D.5.1. Skratky a zvláštne znaky…

D.5.2. Identifikácia…

D.5.3. Implementácia protokolu…

PRÍLOHA E (NORMATÍVNA) ZOZNAM POŽIADAVIEK NA PROFIL… E.1. Úvod…

E.2. Úloha PRL a proforiem PICS…

E.3. Zápis…

E.4. Pokyny na vypĺňanie proforiem PICS…

E.5. Odkazy…

E.6. Vyhlásenie o vyhovujúcom stave…

E.6.1. Prehľad údajov o vyhovujúcom vyhotovení…

E.6.2. Požiadavky pre dynamickú zhodu…

E.7. Požiadavky pre vrchnú vrstvu…

E.8. Požiadavky pre spodnú vrstvu…

E.8.1. ožiadavky pre transportnú vrstvu…

E.8.2. Požiadavky pre sieťovú vrstvu…

E.8.3. Požiadavky pre spojové vrstvy…

E.8.4. Požiadavky pre fyzickú vrstvu10…

PRÍLOHA F (INFORMATÍVNA) METODIKA SKÚŠANIA VYHOVUJÚCEHO STAVU… F.1. Úvod…

F.2. Účel a pôsobnosť…

F.3. Bibliografia…

F.4. Metódy a postupy vývoja…

F.5. Skúšky (testy)…

F.5.1. Úvod…

F.5.2. Skúšanie (testovanie) nižších vrstiev (vrstvy 1 - 3)…

F.5.3. Skúšanie (testovanie) aplikačnej vrstvy…

F.5.4. Certifikácia…

F.5.5. Ohlasovanie…

PRÍLOHA G (INFORMATÍVNA) PRIDEĽOVANIE IDENTIFIKÁTOROV STANOVÍŠŤ ATC… PRÍLOHA H (INFORMATÍVNA) SMERNICE OHĽADNE SPOĽAHLIVOSTI, POUŽITEĽNOSTI A BEZPEČNOSTI… H.1. Úvod…

H.2. Účel a pôsobnosť…

H.3. Bibliografia…

H.4. Implementácie prenajatej linky…

H.4.1. Spoľahlivosť…

H.4.2. Použiteľnosť…

H.4.3. Bezpečnosť…

H.4.4. Príklad konfigurácie…

H.5. Implementácia siete…

H.5.1. Spoľahlivosť…

H.5.2. Použiteľnosť…

H.5.3. Bezpečnosť…

H.6. Všeobecná smernica pre implementáciu prenajatej linky a siete…

H.6.1. Spoľahlivosť…

H.6.2. Použiteľnosť…

H.6.3. Bezpečnosť…

H.6.4. Príklad konfigurácie…

AUTORSKÁ DOLOŽKA

Tento dokument vyhotovila Eurocontrol Agency.

Autorské práva prislúchajú Eurocontrol Agency.

Obsah tohto dokumentu alebo niektorej jeho časti je bez obmedzenia k dispozícii zástupcom členských štátov, poskytnutie jeho odpisu alebo vyzradenie jeho obsahu tretej strane sa však môže uskutočniť len na základe predchádzajúceho písomného súhlasu Eurocontrol Agency.

PREDSLOV

1. Zodpovedný orgán

Túto technickú normu vypracovala a kontroluje pracovná skupina pre výmenu dát letového plánu (FPDE) pri Európskej organizácii pre bezpečnosť leteckej navigácie (Eurocontrol).

2. Plán práce EATCHIP

Táto technická norma sa vzťahuje na Plán práce EATCHIP (EWPD), oblasť komunikácie, pracovná úloha č. 01, odborná úloha 12.

3. Schválenie technickej normy

3.1. Táto technická norma sa prijíma v súlade s postupmi uvedenými v smerniciach upravujúcich normalizáciu Eurocontrol, značka 000-2-93.

3.2. Táto technická norma nadobudla účinnosť po tom, čo ju prijala Stála komisia Eurocontrol a nahrádza Technickú normu Eurocontrol týkajúcu sa priamej výmeny dát (OLDI), vydanie 1, časť 3: TECHNICKÉ POŽIADAVKY (Krátkodobé riadenie prepojenia) zn. 001-3-92.

4. Technické chyby a zmeny a doplnky

Táto technická norma sa neustále skúma, aby sa zistilo, ako ju pozmeniť a doplniť, alebo aby sa odstránili technické chyby. Postup upravujúci kontrolu tejto technickej normy je ustanovený v prílohe H ku smerniciam týkajúcim sa jednotnej osnovy a úpravy technických noriem Eurocontrol.

5. Zásady zostavovania textu

5.1. Formát tejto technickej normy vyhovuje smerniciam týkajúcim sa jednotnej osnovy a úpravy technických noriem Eurocontrol, v niečom sa však od týchto smerníc odkláňa.

5.2. Na vyznačenie právnej sily každého ustanovenia sa použil tento zápis:

- v normatívnych zložkách sa používa oznamovací spôsob a sú vytlačené tenkou latinkou,

- v odporúčaných zložkách sa používa podmieňovací spôsob a boli vytlačené tenkou kurzívou, pričom právnu silu označuje pred ustanovením výraz Odporúčanie.

5.3. Ostatné informácie, ktoré sa považujú za podstatné na pochopenie textu pod určitou pomlčkou, sa doň včleňujú ako POZNÁMKA. Poznámka má len informatívnu hodnotu, preto neobsahuje technické údaje a umiestňuje sa bezprostredne za pomlčkou, na ktorú sa vzťahuje.

5.4. Vo výnimočných prípadoch, aby boli zoznamy požiadaviek na profil (PRLs) prílohy E vo vhodnom formáte, niektoré tabuľky nie sú rozčlenené pomlčkami, ale pokračujú na viacerých stranách.

6. Vzťah k iným technickým normám

6.1. Táto technická norma Eurocontrol nahrádza dokument o krátkodobom riadení prepojenia OLDI (ST-ICD), časť 3, vydanie 1 technickej normy OLDI Eurocontrol [odkaz 13].

6.2. Táto technická norma Eurocontrol predstavuje prvú časť predpokladaného sledu technických noriem Eurocontrol týkajúcich sa riadenia prepojenia (ICDs) za účelom výmeny letových dát.

7. Právna sila príloh k tejto technickej norme

Prílohy k tejto technickej norme majú túto právnu silu:

- Príloha A - normatívna

- Príloha B - normatívna

- Príloha C - normatívna

- Príloha D - normatívna

- Príloha E - normatívna

- Príloha F - informatívna

- Príloha G - informatívna

- Príloha H - informatívna

8. Použitý jazyk

Pôvodné znenie tejto technickej normy bolo zostavené v anglickom jazyku.

1. ÚVOD

Táto technická norma Eurocontrol vychádza z dokumentu o krátkodobom riadení prepojenia, vypracovanom bývalou odbornou podskupinou OLDI, ktorú poverili, aby sformulovala nové technické predpisy prepojenia za účelom ďalšieho vykonávania OLDI medzi oblastnými strediskami riadenia leteckej prevádzky.

Staršie spoje OLDI boli založené na autorizovaných protokoloch, ako napríklad INTERCAUTRA alebo Datenübertragungs- und Verteilungssystem (DÜV), ktoré sa používajú vo vyhradených dvojbodových okruhoch alebo ohraničených sieťach a vyžadujú špeciálne strojové a programové vybavenie.

Vzhľadom na plánované zvýšenie počtu nových spojov sa považovalo za žiaduce prejsť na sieťovú architektúru a prijať medzinárodné technické normy pre oblasť telekomunikácií, vďaka čomu by sa spoje dali zrealizovať rentabilnejšie tak, že by sa znížil počet spojov v každom stredisku a povolilo používanie štandardného "hotového" strojového a programového vybavenia.

Táto technická norma Eurocontrol formalizuje a rozširuje dokument krátkodobého riadenia prepojenia. ST-ICD bol preformulovaný v záujme sprísnenia technických parametrov, čím sa zlepší súčinnosť a okrem toho môže vytvoriť základ na to, aby ďalšie ICD splnili vyvíjajúce sa požiadavky týkajúce sa výmeny letových dát (FDE), vrátane častejšieho používania spoločných sietí a zavedenia nových technických noriem pre nižšiu vrstvu. Táto technická norma Eurocontrol ustanovuje minimálny súbor funkčností, ktoré môžu po minimálnej úprave zabezpečiť existujúce verzie OLDI, a to na základe dvojbodových spojov alebo Odporúčania X.25 Poradného výboru pre telekomunikácie a telegrafiu (CCITT) z roku 1980 alebo v neskoršom vydaní, alebo pomocou sietí s prepínaním paketov. Existuje viacero možností obstarania. Tento ICD nebráni tomu, aby dvojstranné dohody zašli ešte ďalej.

Zariadenia, ktoré by mali okrem aplikačných protokolov uvedených v tomto dokumente, alebo namiesto nich používať iné, môžu buď požiadať o zmenu a doplnenie tohto protokolu, alebo svoj protokol vyčleniť pomocou rôznych virtuálnych okruhov.

2. PÔSOBNOSŤ

2.1. Táto technická norma Eurocontrol ustanovuje predpisy pre dátové komunikačné prepojenie na výmenu správ obsahujúcich letové dáta medzi oblastnými strediskami riadenia leteckej prevádzky. Má podobu profilu prepojenia otvorených systémov (OSI), tak ako je definovaný v Technickej správe (TR) 10000-2 Medzinárodnej organizácie pre normalizáciu/Medzinárodnej elektrotechnickej komisie (ISO/IEC) [odkaz 3]. Profil sa vzťahuje na nižšie (T-profil) aj vyššie (A-profil) vrstvy.

2.2. Táto technická norma Eurocontrol sa vzťahuje na nasledovné scenáre:

- zabezpečenie OLDI, ako je popísané v Technickej norme Eurocontrol č. 001-92 vydanie 1,

- zabezpečenie prenosu aplikačných správ OLDI z ACC do systémov Strediska riadenia leteckej prevádzky (CFMU).

2.3. Táto technická norma sa vzťahuje na spojenie, pri ktorom sa používajú buď:

- dvojbodové okruhy prenajatej linky alebo

- dvojbodové okruhy verejnej spojovacej telefónnej siete (PSTN) alebo

- dátové siete s prepínaním paketov alebo navzájom prepojené dátové siete s prepínaním paketov, ktoré poskytujú prepojenie vyhovujúce odporúčaniu X.25 CCITT z roku 1980 alebo v neskoršom vydaní.

POZNÁMKY

1. Usporiadanie systémov spracovania letového plánu (FPPS) je znázornené na obrázku 1.

2. Obrázok 1 neznázorňuje potenciálne záložné spojenia, ako napríklad PSTN. Smernice týkajúce sa týchto spojení obsahuje príloha H.

+++++ TIFF +++++

Obrázok 1Schéma prepojenia

2.4. Táto technická norma neautorizuje detailné bezpečnostné aspekty špecifikovaného prepojenia na prenos dát. Základné ustanovenie je však uvedené v prílohe a ďalšie smernice možno nájsť v prílohe H k tejto technickej norme Eurocontrol.

3. ODKAZY

3.1. Úvod

Nižšie uvedené dokumenty a technické normy obsahujú ustanovenia, ktoré v dôsledku toho, že sa na ne tento text odvoláva, sa stávajú ustanoveniami tejto technickej normy Eurocontrol.

V čase zverejnenia tejto technickej normy Eurocontrol boli dokumenty a technické normy, na ktoré sa odvoláva, platné v uvedenom vydaní.

Pri upravovaní tejto technickej normy Eurocontrol sa okamžite zohľadnia úpravy dokumentov Medzinárodnej organizácie civilného letectva (ICAO), na ktoré sa tu odvoláva.

Úpravy ostatných dokumentov, na ktoré sa tu odvoláva, sa stanú súčasťou tejto technickej normy Eurocontrol až po ich formálnom preskúmaní a začlenení do tejto technickej normy Eurocontrol.

V prípade, že požiadavky uvedené v tejto technickej norme Eurocontrol sú v rozpore s obsahom týchto ostatných dokumentov, prednosť má táto technická norma Eurocontrol.

3.2. Odkazy

1. ITU-T Recommendation X.25 (1993) (opravené vydanie 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit. (Odporúčanie ITU-T X.25, Prepojenie medzi koncovým zariadením prenosu dát a ukončovacím dátovým zariadením pre terminály pracujúce v paketovom režime a pripojené na verejné dátové siete vyhradeným okruhom).

2. ISO/IEC TR 10000-1:1992, Information technology - Framework and Taxonomy of International Standardized Profiles: - časť 1: Framework (2. vydanie).

3. ISO/IEC TR 10000-2:1994, Information Technology - Framework and Taxonomy of International Standardized Profiles - časť 2: Principles and Taxonomy for OSI Profiles (3.vydanie). (Informačná technológia - Rámec a taxonómia medzinárodných normalizovaných profilov: ťasť 2: zásady a taxonómia profilov OSI.)

4. ITU-T Recommendation X.21 (1992) (opravené vydanie 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks. (Odporúčanie ITU-T X.21. Prepojenie medzi koncovým zariadením prenosu dát a ukončovacím dátovým zariadením v synchrónnej prevádzke vo verejných dátových sietiach.)

5. CCITT Recommendation X.21bis (1988), Use of public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems. Odporúčanie CCITT X.21bis. Používanie koncového zariadenia prenosu dát určeného na pripojenie na synchrónne modemy série V vo verejných dátových sietiach.)

6. ISO/IEC 7776:1994, Information Technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2.vydanie). (Informačná technológia - Telekomunikácie a výmena informácií medzi systémami - Vysokoúrovňové riadenie dátového spoja - Popis spojovacích operácií DTE kompatibilných s X.25 LAPB.)

7. ISO/IEC 8208:1993, Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment (3.vydanie). (Informačná technológia - Prenos dát - Vrstvový protokol paketu X.25 pre DTE.)

8. ISO/IEC ISP 106-9:1992, Information Technology - International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service - časť 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a packet-switched data network using virtual calls. (Informačná technológia - Medzinárodné normalizované profily TB, TC, TD a TE - Služba prenosu dát v spojovacom režime cez sieťovú službu v spojovacom režime - časť 9: Požiadavky na sieťovú vrstvu v závislosti od typu pomocnej siete, spojovacia vrstva a fyzická vrstva so zreteľom na nepretržitý prístup do dátovej siete s prepínaním paketov pomocou virtuálnych volaní.)

9. ISO/IEC 7498-1:1994, Information Technology - Open Systems Interconnection - Basic Reference Model: The Basic Model (2.vydanie). (Informačná technológia - Prepojenie otvorených systémov - Základný referenčný model: Základný model.)

10. ISO/IEC 8348:1993, Information Technology - Open Systems Interconnection - Network Service Definition (1. vydanie). (Informačná technológia - Prepojenie otvorených systémov - Definovanie sieťovej služby.)

11. ISO/IEC 8072:1994, Information Technology - Open Systems Interconnection - Transport service definition (2. vydanie). (Informačná technológia - Prepojenie otvorených systémov - Definovanie služby prenosu dát.)

12. ISO/IEC 8878:1992, Information Technology - Telecommunications and information exchange between systems - Use of X.25 to provide the OSI connection-mode Network Service (2.vydanie). (Informačná technológia - Telekomunikácie a výmena informácií medzi systémami - Použitie X.25 na zabezpečenie sieťovej služby OSI v spojovacom režime.)

13. Eurocontrol Standard for On-Line Data Interchange (OLDI), No.001-92, 1.vydanie, 1992. (Technická norma Eurocontrol upravujúca priamu výmenu dát.)

14. ISO/IEC 9646-1:1994, Information Technology-Open Systems Interconnection-Conformance testing methodology and framework - časť 1: General concepts (2.vydanie). (Informačná technológia - Prepojenie otvorených systémov - metodika a rámec testovania vyhovujúceho stavu - časť 1: všeobecné pojmy.)

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD časť 1 Integration Test Plan Version 1.0, dated 10 May 1996. (Jednotný skúšobný plán, verzia 1.0 z 10. mája 1996.)

16. Eurocontrol FDE ICD časť 1 - Reliability, Availability and Security - technická správa 1.0 z 20.apríla 1997. (Spoľahlivosť, použiteľnosť a bezpečnosť.)

17. ITU-T Recommendation X.32 (1993) (opravené vydanie 1), Interface between DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network. (Odporúčanie OTU-T X.32. Prepojenie medzi DTE a DCE v prípade terminálov pracujúcich v paketovom režime a s prístupom do verejnej dátovej siete s prepínaním paketov cez verejnú spojovaciu telefónnu sieť alebo integrované služby digitálnej siete alebo cez verejnú dátovú sieť s prepínaním okruhov.)

18. ITU-T Recommendation E.164 (1991) (opravené vydanie 1), Numbering plan for the ISDN era. Odporúčanie OTU-T E.164. Číslovací plán pre éru ISDN.)

19. ITU-T Recommendation X.75 (1993) (opravené vydanie 1), Packet-switched signalling system between public network providing data transmission service. (Odporúčanie ITU-T X.75. Signalizačný systém s prepínaním paketov medzi verejnými sieťami zabezpečujúcimi službu prenosu dát.)

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks. (Odporúčanie ITU-T X.121. Medzinárodný číslovací plán verejných dátových sietí.)

4. DEFINÍCIE, SYMBOLY A SKRATKY

4.1. Definície

4.1.1. Na účely tejto technickej normy Eurocontrol platia tieto definície:

Profil: : Súbor jednej alebo viacerých základných technických noriem, prípadne vymedzenie zvolených tried, podsúborov, alternatív a parametrov týchto základných technických noriem, ktoré sú potrebné na realizáciu určitej konkrétnej funkcie [odkaz 2].

Profile Requirements List (PRL), (Zoznam požiadaviek na profil): : Požiadavky na profil sa vyjadrujú v podobe predpisových požiadaviek a sú usporiadané v podobe tabuľkového zoznamu [odkaz 2].

T-profile: : Profil prenosu dát, ktorý poskytuje službu prenosu dát v spojovacom režime [odkaz 3].

A-profile: : Aplikačný profil, ktorý vyžaduje službu prenosu dát v spojovacom režime [odkaz 3].

Protocol Implementation Conformance Statement (PICS), (Vyhlásenie o vyhovujúcom vyhotovení protokolu): : Vyhlásenie dodávateľa systému OSI o povolených operáciach, ktoré sa uskutočnili v danom protokole OSI [odkaz 14].

4.2. Symboly a skratky

Na účely tejto technickej normy Eurocontrol sa používajú tieto symboly a skratky:

ACC | Area Control Centre - Oblastné stredisko riadenia leteckej prevádzky |

AFI | Authority and Format Identifier - Identifikátor práva na prístup a formátu |

ASCII | American Standard Code for Information Interchange - Americký štandardný kód pre výmenu informácií |

ATC | Air Traffic Control - Riadenie leteckej prevádzky |

ATCC | Air Traffic Control Centre - Stredisko riadenia leteckej prevádzky |

CAUTRA | Coordinateur Automatique du Trafic Aérien - Automatický koordinátor leteckej dopravy |

CCITT | Comité consultatif international télégraphique et téléphonique (teraz ITU-T) - Medzinárodný poradný výbor pre telekomunikácie a telegrafiu |

CFMU | Central Flow Management Unit - Stredisko riadenia leteckej dopravy |

CUG | Closed User Group - Uzavretá skupina užívateľov |

DCE | Data Circuit-terminating Equipment - Ukončujúce zariadenie dátového okruhu |

DCFS | Digital Communications Terminal System - Digitálny komunikačný terminálový systém |

DSP | Domain Specific Part - Časť špecifická pre doménu |

DTE | Data Terminal Equipment - Koncové dátové zariadenie |

DÜV | Datenübertragungs- und Verteilungssystem - Systém prenosu a distribúcie dát |

FDE | Flight Data Exchange - Výmena letových dát |

FEP | Front-End Processor - Predradený procesor |

FPDE | Flight Plan related Data Exchange - Výmena dát letového plánu |

FPPS | Flight Plan Processing System - Systém spracovania letového plánu |

ICAO | International Civil Aviation Organisation - Medzinárodná organizácia civilného letectva |

ICD | Interface Control Document - Dokument o riadení prepojenia |

IDI | Initial Domain Identifier - Identifikátor prvotnej domény |

IDP | Initial Domain Part - Prvotná doménová časť |

IEC | International Electrotechnical Commission - International Electrotechnical Commission |

INTER-CAUTURA | Inter-CAUTRA protocol - Protokol Inter-CAUTRA |

ISO | International Organisation for Standardization - Medzinárodná organizácia pre normalizáciu |

ITU-T | International Telecommunication Union - Telecommunication Standardization Sector - Medzinárodný telekomunikačný zväz - odbor normalizácie telekomunikácií |

ISDN | Integrated Services Digital Network - Digitálna sieť integrovaných služieb |

LAPB | Link Access Procedure Balanced - Symetrická procedúra linkového prístupu |

LSB | Least Significant Bit - Najmenej významný bit |

M, m | Mandatory - Povinný |

MSB | Most Significant Bit - Najvýznamnejší bit |

MT | Message Transfer - Prenos správ |

NA | Not Applicable - Neaplikovateľné |

NS | Network Service - Sieťová služba |

NSAP | Network Service Access Point - Bod prístupu do sieťovej služby |

NSDU | Network Service Data Unit - Jednotka dát sieťovej služby |

O, O.<n> | Optional - Nepovinný, kde <n> je číslica, ktorá sa používa na odkazovanie |

o, o.<n> | Optional - Nepovinný, kde <n> je číslica, ktorá sa používa na odkazovanie |

OLDI | On-Line Data Interchange - Priama výmena dát |

OSI | Open Systems Interconnection - Prepojenie otvorených systémov |

PICS | Protocol lmplementation Conformance Statement - Vyhlásenie o vyhovujúcom vyhotovení protokolu |

PLP | Packet Layer Protocol - Protokol paketovej (balíkovej) vrstvy |

PRL | Profile Requirements List - Zoznam požiadaviek na profil |

PSTN | Public Switched Telephone Network - Verejná spojovacia telefónna sieť |

ST-ICD | Short Term Interface Control Document - Dokument o krátkodobom riadení prepojenia |

SUT | System Under Test - Testovaný systém |

T<x> | Timer - Časovač (kde <x> je jedno alebo dve písmená na odkazovanie) |

TA | Terminal Adaptor - Terminálový adaptér |

TSDU | Transport Service Data Unit - Jednotka dát služby prenosu dát |

TPDU | Transport Protocol Data Unit - Jednotka dát protokolu prenosu dát |

TR | ISO Technical Report - Technická správa ISO |

X | Prohihited - Zakázaný |

X | Excluded - Vylúčený |

<item>: | Conditional Item - Podmienený prvok (závislý od hodnoty prvku) |

4.3. Zápisy

4.3.1. Na účely tejto technickej normy Eurocontrol sa binárne hodnoty alebo sled bitov označuje v šestnástkovej sústave zápisom 'd'H, kde písmeno d predstavuje určitú číslicu alebo sled šestnástkových číslic.

4.3.2. Na účel tejto technickej normy Eurocontrol sa sled bitov v šestnástkovej sústave znázorňuje tak, že sa vyčleňuje po štyroch bitoch od najvýznamnejšieho (MSB) po najmenej významný (LSB).

POZNÁMKA

Pokiaľ sa v medzinárodných technických normách, na ktoré sa tu odvoláva, neuvádza inak, sled bitov sa prenáša od MSB po LSB.

4.3.3. Na účely tejto technickej normy Eurocontrol sa stav zabezpečenia vlastností podľa určitej základnej technickej normy alebo tejto technickej normy Eurocontrol uvádza veľkými písmenami (napr. M, O, O.<n>, X). Presný význam každého symbolu stavu zabezpečenia sa uvádza ešte pred jeho použitím v prílohách k tejto technickej norme Eurocontrol.

4.3.4. Na účel definovania profilu časti 1 FDE ICD v tejto technickej norme Eurocontrol, stav zabezpečenia vlastností podľa určitej základnej technickej normy alebo tejto technickej normy Eurocontrol sa uvádza malými písmenami (napr. m, o, o.<n>, x).

POZNÁMKA

Znamená to ďalšie členenie vlastností podľa základných technických noriem, ktoré sú buď podmienené, nepovinné alebo závislé od hodnoty (pozri E.3.1.).

5. TECHNICKÝ PREHĽAD

5.1. Zásobník protokolov

POZNÁMKA

Zásobník protokolov pre profil tejto technickej normy Eurocontrol je znázornený na obrázku 2. Na obrázku sú protokoly umiestnené do rámca základného modelu OSI [odkaz 9] priradením zásobníka k zodpovedajúcim vrstvám OSI. Avšak zásobník protokolov je predpis, ktorý sa vzťahuje na pred-OSI systémy a nezabezpečuje to veľké množstvo funkcií, ktoré sú povolené v protokoloch OSI príslušných vrstiev OSI.

+++++ TIFF +++++

Obrázok 2Zásobník profilových protokolov

5.2. Štruktúra profilu

POZNÁMKY

1. Ako je to znázornené na obrázku 2, zásobník profilov kombinuje viacero protokolov nižšej vrstvy, z ktorých len protokol paketovej vrstvy X.25 (PLP) [odkaz 1] a jeho pomocné protokoly, X.21 [odkaz 4] a X.21bis [odkaz 5] sú definované v platných technických normách ISO/IEC a normách Medzinárodného telekomunikačného zväzu-odbor normalizácie (ITU-T). Ostatné protokoly vyšších vrstiev sú definované v prílohách (prílohy A, B a C) k tejto technickej norme Eurocontrol.

2. Predpisové požiadavky na profil sa na tieto technické predpisy môžu odvolávať práve tak ako na iné technické normy a uvádzajú sa v oddieli 6. Presné požiadavky sa uvádzajú v tabuľkovom formáte PRL (príloha E) a proforma PICS (proforma k protokolom, ktoré sú definované v prílohách, sú uvedené v prílohe D). Používanie týchto PRL a vývoj alebo zaobstarávanie proforma PICS sa vysvetľuje v prílohe E.

5.3. Vzťah k predchádzajúcim verziám tohto technického predpisu

POZNÁMKY

1. Tento profil vychádza zo ST-ICD, ktorý vypracovala bývalá odborná podskupina OLDI. Protokoly a paketové formáty definované v tejto technickej norme Eurocontrol predstavujú kompatibilný podsúbor ST-ICD s výhradou, že táto technická norma Eurocontrol neobsahuje presnejšie požiadavky na používanie PLP X.25, zahŕňa povinné zabezpečenie M-bit a opravuje nedôsledné určenie hodnoty identifikátora práva na prístup a formátu (AFI) v adrese prístupového bodu do sieťovej služby (NSAP).

2. Hlavná zmena v tejto technickej norme Eurocontrol sa týka štruktúry predpisu ICD. Protokol prenosu správ (príloha A) sa vyčleňuje z pomocného T-profilu. Uľahčí sa tým používanie iných T-profilov, kedže je to potrebné na zabezpečenie vyvíjajúcich sa požiadaviek FDE.

3. Tieto časti predpisu ST-ICD, ktoré sa zaoberajú riadením virtuálnych okruhov X.25 a vymedzujú aplikačné správy, sa teraz nachádzajú v protokole záhlavia správ (príloha B), ktorý má funkciu minimálnej vrstvy prenosu dát v rámci FDE.

6. POŽIADAVKY NA PROFIL

6.1. Predpisové požiadavky

6.1.1. Vyhotovenie, ktoré má vyhovovať tomuto predpisu, musí spĺňať požiadavky uvedené v oddieloch 6.2 a 6.3. nižšie.

6.1.2. Tvrdenie o vyhovujúcom stave sa doloží vyhlásením o vyhovujúcom vyhotovení profilu, ako je to uvedené v prílohe D a v prílohe E.

6.2. Požiadavky na vyššiu vrstvu

6.2.1. Vyhovujúce vyhotovenie spĺňa požiadavky základnej technickej normy uvedené v prílohe A.

6.2.2. Vyhovujúce vyhotovenie spĺňa obmedzenia, ktoré sú uvedené v zozname požiadaviek na profil v prílohe E.7.

6.3. Požiadavky na nižšiu vrstvu

6.3.1. Požiadavky na vrstvu prenosu dát

6.3.1.1. Vyhovujúce vyhotovenie spĺňa požiadavky základnej technickej normy uvedené v prílohe B.

6.3.1.2. Vyhovujúce vyhotovenie spĺňa obmedzenia, ktoré sú uvedené v zozname požiadaviek na profil v prílohe E.8.1.

6.3.1.3. Vyhovujúce vyhotovenie spĺňa požiadavku na zabezpečenie veľkostí jednotky dát služby prenosu dát (TSDU) až do 4 097 oktetov.

POZNÁMKA

Prvý oktet TSDU zodpovedá určitému poľu záhlavia správy (pozri A.4.10, B.4.4), pričom ponecháva na užívateľské dáta maximálne 4 096 oktetov.

6.3.2. Požiadavky na sieťovú vrstvu

6.3.2.1. Vyhovujúce vyhotovenie spĺňa požiadavky ISO/IEC 8208 [odkaz 7] v súlade s mapovaním protokolu uvedeným v prílohe C.

6.3.2.2. Vyhovujúce vyhotovenie spĺňa obmedzenia, ktoré sú uvedené v zozname požiadaviek na profil v prílohe E.8.2.

6.3.2.3. V prípade, že je zabezpečený chod dátového koncového zariadenia (DTE)-DTE, vyhovujúce zariadenie dokáže pomocou mechanizmov systémového riadenia zabezpečiť prevádzku DTE-DTE realizovaním alternatívnej funkcie DTE alebo funkcie ukončujúceho zariadenia dátového okruhu (DCE).

6.3.2.4. Vyhovujúce zariadenie dokáže v oboch funkciách, ktoré sú definované v 6.3.2.3., vytvoriť spojenie podľa predpisu v prílohe C, čo značí, že protokol je dokonale symetrický.

POZNÁMKA

Niektoré jestvujúce vyhotovenia vychádzajúce z ST-ICD nemusia mať schopnosť vytvoriť spojenie medzi sieťami podľa protokolu v prílohe C.

6.3.2.5. Vyhovujúce vyhotovenie po určitú dobu zodpovedá zariadeniu s neštandardnou hodnotou veľkostí paketov s hodnotou 256 pri obojsmernom prenose dát.

6.3.2.6. Vyhovujúce vyhotovenie používa adresy NSAP, ako sú definované v prílohe C.

6.3.2.7. Vyhovujúce zariadenie nastaví v paketoch CALL REQUEST, CALL ACCEPTED a DATA D-bit na 0.

POZNÁMKA

Nastavenie D=0 v paketoch CALL REQUEST a CALL ACCEPTED spôsobí, že sa nepoužíva potvrdenie príjmu.

6.3.3. Požiadavky na spojovaciu vrstvu

6.3.3.1. Vyhovujúce vyhotovenie spĺňa požiadavky ISO/IEC 7776 [odkaz 6] týkajúce sa jednolinkového protokolu symetrickej procedúry linkového prístupu (LAPB).

6.3.3.2. Vyhovujúce vyhotovenie spĺňa aj obmedzenia uvedené v zozname požiadaviek na profil v prílohe E.8.3.

6.3.4. Požiadavky na fyzickú vrstvu

Vyhovujúce vyhotovenie spĺňa požiadavky ISO/IEC ISP 10609-9, bod 7 [odkaz 8].

7. SKÚŠOBNÉ METÓDY

POZNÁMKY

1. Spôsob testovania vyhotovení podľa tohto technického predpisu je uvedený v prílohe F.

2. Používanie vyhovujúcich proforma PRL a PICS v súvislosti s týmto technickým predpisom je uvedené v prílohe E.

--------------------------------------------------