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



Úradný vestník L 254 , 09/10/2000 S. 0001 - 0234

CS.ES Kapitola 07 Zväzok 005 S. 104 - 337

ET.ES Kapitola 07 Zväzok 005 S. 104 - 337

HU.ES Kapitola 07 Zväzok 005 S. 104 - 337

LT.ES Kapitola 07 Zväzok 005 S. 104 - 337

LV.ES Kapitola 07 Zväzok 005 S. 104 - 337

MT.ES Kapitola 07 Zväzok 005 S. 104 - 337

PL.ES Kapitola 07 Zväzok 005 S. 104 - 337

SK.ES Kapitola 07 Zväzok 005 S. 104 - 337

SL.ES Kapitola 07 Zväzok 005 S. 104 - 337



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