(ES) č. 2082/2000Nařízení Komise (ES) č. 2082/2000 ze dne 6. září 2000, kterým se přijímají normy Eurocontrol a mění směrnice 97/15/ES, kterou se přijímají normy Eurocontrol a mění směrnice Rady 93/65/EHS
| Publikováno: | Úř. věst. L 254, 9.10.2000 | Druh předpisu: | Nařízení |
| Přijato: | 6. září 2000 | Autor předpisu: | Evropská komise |
| Platnost od: | 12. října 2000 | Nabývá účinnosti: | 12. října 2000 |
| Platnost předpisu: | Zrušen předpisem (ES) č. 552/2004 | Pozbývá platnosti: | 20. dubna 2004 |
Text předpisu s celou hlavičkou je dostupný pouze pro registrované uživatele.
Nařízení Komise (ES) č. 2082/2000 ze dne 6. září 2000, kterým se přijímají normy Eurocontrol a mění směrnice 97/15/ES, kterou se přijímají normy Eurocontrol a mění směrnice Rady 93/65/EHS KOMISE EVROPSKÝCH SPOLEČENSTVÍ, s ohledem na Smlouvu o založení Evropského společenství, s ohledem na směrnici Rady 93/65/EHS ze dne 19. července 1993 o definici a užívání slučitelných technických specifikací pro zadávání zakázek na zařízení a systémy řízení letového provozu [1], a zejména na článek 3 uvedené směrnice, s ohledem na směrnici Komise 97/15/ES ze dne 25. března 1997, ze dne 25. března 1997, kterou se přijímají normy Eurocontrol a mění směrnice Rady 93/65/EHS o definici a užívání slučitelných technických specifikací pro zadávání zakázek na zařízení a systémy řízení letového provozu [2], vzhledem k těmto důvodům: (1) Směrnice Komise 97/15/ES přijala normy Evropské organizace pro bezpečnost leteckého provozu (Eurocontrol) pro výměnu dat on-line (OLDI — On-Line Data Interchange), verze 1.0, a normy Eurocontrol pro ADEXP — Způsob výměny dat ATS, Formát ADEXP — Air Traffic Services Data Exchange Presentation), verze 1.0. (2) Evropská organizace pro bezpečnost leteckého provozu (Eurocontrol) přijala novější verze obou výše zmíněných norem, tj. OLDI verze 2.2 a ADEXP verze 2.0, a také nové normy Eurocontrol nazvané Dokument definující rozhraní pro výměnu dat o letu (FDE — ICD). (3) Tyto normy Eurocontrol přísluší do působnosti směrnice 93/65/EHS a přispívají k harmonizaci vnitrostátních systémů řízení letového provozu členských států, zvláště v oblastech předávání letů mezi ATCC — Středisko řízení letového provozu (OLDI), uspořádání toku letového provozu (ADEXP) a komunikace mezi vnitrostátními systémy (FDE-ICD). (4) Verze OLDI 2.2 a ADEXP 2.0 nahrazují předchozí verze, které jsou v současnosti v platnosti na základě článku 1 směrnice 97/15/ES, a proto je nutné uvedený článek zrušit. (5) Opatření tohoto nařízení jsou v souladu se stanoviskem výboru zřízeného směrnicí 93/65/EHS, PŘIJALA TOTO NAŘÍZENÍ: Článek 1 V míře nezbytné pro zavedení integrovaného evropského systému řízení letového provozu se závazné prvky specifikací Eurocontrol obsažené v následujících normách Eurocontrol přijímají v rámci směrnice 93/65/EHS: - normy Eurocontrol pro výměnu dat on-line (OLDI — On-Line Data Interchange), verze 2.2 (odkaz na dokument Eurocontrol DPS.ET1.ST06-STD), jejichž znění je uvedeno v příloze I tohoto nařízení, - normy Eurocontrol pro ADEXP — Způsob výměny dat ATS, Formát ADEXP, verze 2.0 (odkaz na dokument Eurocontrol DPS.ET1.ST09-STD), jejichž znění je uvedeno v příloze II tohoto nařízení, - normy Eurocontrol definující rozhraní pro výměnu dat o letu (FDE-ICD), verze 1.0 (odkaz na dokument Eurocontrol COM.ET1.ST12-STD), jejichž znění je uvedeno v příloze III tohoto nařízení. Článek 2 Zrušuje se článek 1 směrnice 97/15/ES. Článek 3 Toto nařízení vstupuje v platnost třetím dnem po vyhlášení v Úředním věstníku Evropských společenství. Toto nařízení je závazné v celém rozsahu a přímo použitelné ve všech členských státech. V Bruselu dne 6. září 2000. Za Komisi Loyola De Palacio místopředsedkyně [1] Úř. věst. L 187, 29.7.1998, s. 52. [2] Úř. věst. L 95, 10.4.1997, s. 16. -------------------------------------------------- PŘÍLOHA I VÝMĚNA DAT ON-LINE (OLDI), VERZE 2.2 (odkaz na dokument Eurocontrol DPS.ET1.ST06-STD) OBSAH UPOZORNĚNÍ NA AUTORSKÁ PRÁVA … PŘEDMLUVA … 1 ÚVOD … 1.1 Účel … 1.2 Oblast působnosti … 2. ODKAZY … 3. DEFINICE, SYMBOLY A ZKRATKY … 3.1 Definice … 3.2 Symboly a zkratky … 4. VŠEOBECNÉ POŽADAVKY … 4.1 Úvod … 4.2 Požadavky na systém zpracování letových dat (FDPS) … 4.2.1 Databáze letů … 4.2.2 Provoz v reálném čase … 4.2.3 Způsobilost pro přenos dat … 4.2.4 Funkce aplikace … 4.2.5 Rozhraní člověk/stroj (HMI) … 4.2.6 Spouštění zpráv … 4.2.7 Příjem zpráv … 4.3 Aktualizace dat pomocí sledování … 4.4 Záznam údajů OLDI … 4.4.1 Obsah … 4.4.2 Služby … 4.5 Dostupnost, spolehlivost, ochrana dat a jejich neporušenost … 4.5.1 Dostupnost … 4.5.2 Spolehlivost … 4.5.3 Ochrana dat … 4.5.4 Integrita dat … 4.6 Provozní hodnocení … 4.6.1 Doba hodnocení … 4.6.2 Datum uvedení do provozu … 5. KATEGORIE ZPRÁV … 5.1 Úvod … 5.1.1 Účel … 5.1.2 Kategorie zpráv … 5.2 Časy transakcí … 5.2.1 Požadavky na čas transakce … 5.3 Zařazení zpráv do tříd a kategorií … 5.3.1 Zařazení zpráv do tříd — povinné a doplňkové … 5.3.2 Zařazení zpráv do kategorií … 6. ZÁKLADNÍ POSTUP — POVINNÉ ZPRÁVY … 6.1 Úvod … 6.1.1 Popis požadavků … 6.1.2 Zavedení … 6.2 Předběžná informační zpráva o přeletu hranice FIR (ABI) … 6.2.1 Účel zprávy ABI … 6.2.2 Obsah zprávy … 6.2.3 Pravidla používání … 6.2.4 Potvrzení zprávy ABI … 6.2.5 Příklady … 6.3 Aktivační zpráva (ACT) … 6.3.1 Účel zprávy ACT … 6.3.2 Obsah zprávy … 6.3.3 Pravidla používání … 6.3.4 Potvrzení zprávy ACT … 6.3.5 Příklady … 6.4 Zpráva o příjmu a zpracování předchozí zprávy (LAM) … 6.4.1 Účel zprávy LAM … 6.4.2 Obsah zprávy … 6.4.3 Pravidla používání … 6.4.4 Potvrzení zprávy LAM … 6.4.5 Příklady … 7. ZÁKLADNÍ POSTUP — DOPLŇKOVÉ ZPRÁVY … 7.1 Úvod … 7.1.1 Popis požadavků … 7.1.2 Zavedení … 7.2 Zpráva o předběžné aktivaci (PAC) … 7.2.1 Účel zprávy PAC … 7.2.2 Obsah zprávy … 7.2.3 Pravidla používání … 7.2.4 Potvrzení zprávy PAC … 7.2.5 Příklady … 7.3 Zpráva o změně koordinačních dat (REV) … 7.3.1 Účel zprávy REV … 7.3.2 Obsah zprávy … 7.3.3 Pravidla používání … 7.3.4 Potvrzení zprávy REV … 7.3.5 Příklady … 7.4 Zpráva zrušení koordinace (MAC) … 7.4.1 Účel zprávy MAC … 7.4.2 Obsah zprávy … 7.4.3 Pravidla používání … 7.4.4 Potvrzení zprávy MAC … 7.4.5 Příklady … 7.5 Zpráva o přidělení kódu SSR (COD) … 7.5.1 Účel zprávy COD … 7.5.2 Obsah zprávy … 7.5.3 Pravidla používání … 7.5.4 Potvrzení zprávy COD … 7.5.5 Příklady … 7.6 Informativní zpráva (INF) … 7.6.1 Účel zprávy INF … 7.6.2 Obsah zprávy … 7.6.3 Pravidla používání … 7.6.4 Potvrzení zprávy INF … 7.6.5 Příklady … 8. DIALOGOVÝ POSTUP KOORDINACE … 8.1 Celkový přehled … 8.1.1 Úvod … 8.1.2 Filtr … 8.1.3 Pořadí zpráv … 8.1.4 Souběžná výměna zpráv … 8.1.5 Zpracování odmítnutí … 8.1.6 Časový limit pro obdržení odpovědi … 8.1.7 Provedení … 8.2 Aktivační zpráva (ACT) … 8.2.1 Účel zprávy ACT … 8.2.2 Obsah zprávy … 8.2.3 Pravidla používání … 8.2.4 Potvrzení zprávy ACT … 8.3 Zpráva navrhující nestandardní podmínky předání předložená přijímajícímu řídícímu (RAP) … 8.3.1 Účel zprávy RAP … 8.3.2. Obsah zprávy … 8.3.3 Pravidla používání … 8.3.4 Potvrzení zprávy RAP … 8.3.5 Operativní odpověď na zprávu RAP … 8.3.6 Příklady … 8.4 Zpráva o změně koordinačních dat (REV) … 8.4.1 Účel zprávy REV … 8.4.2 Obsah zprávy … 8.4.3 Pravidla používání … 8.4.4 Potvrzení zprávy REV … 8.4.5 Operativní odpověď na zprávu REV … 8.5 Zpráva o změně nestandardních koordinačních podmínek (RRV) … 8.5.1 Účel zprávy RRV … 8.5.2 Obsah zprávy … 8.5.3 Pravidla používání … 8.5.4 Potvrzení zprávy RRV … 8.5.5 Operativní odpověď na zprávu RRV … 8.5.6 Příklady … 8.6 Zpráva … 8.6.1 Účel zprávy SBY … 8.6.2 Obsah zprávy … 8.6.3 Pravidla používání … 8.6.4 Potvrzení zprávy SBY … 8.6.5 Příklady … 8.7 Akceptační zpráva (ACP) … 8.7.1 Účel zprávy ACP … 8.7.2 Obsah zprávy … 8.7.3 Pravidla používání … 8.7.4 Potvrzení zprávy ACP … 8.7.5 Příklady … 8.8 Koordinační zpráva (CDN) … 8.8.1 Účel zprávy CDN … 8.8.2 Obsah zprávy … 8.8.3 Pravidla používání … 8.8.4 Potvrzení zprávy CDN … 8.8.5 Operativní odpověď na zprávu CDN … 8.8.6 Příklady … 8.9 Zpráva o odmítnutí koordinačních dat, (RJC) … 8.9.1 Účel zprávy RJC … 8.9.2 Obsah zprávy … 8.9.3 Pravidla používání … 8.9.4 Potvrzení zprávy RJC … 8.9.5 Příklady … 9. DIALOGOVÝ POSTUP PŘEDÁNÍ SPOJENÍ … 9.1 Celkový přehled … 9.1.1 Úvod … 9.1.2 Pořadí zpráv … 9.1.3 Předání spojení … 9.2 Zpráva zahájení předání (TIM) … 9.2.1 Účel zprávy TIM … 9.2.2 Obsah zprávy … 9.2.3 Pravidla používání … 9.2.4 Potvrzení zprávy TIM … 9.2.5 Příklad … 9.3 Zpráva doplňku letových dat (SDM) … 9.3.1 Účel zprávy SDM … 9.3.2 Obsah zprávy … 9.3.3 Pravidla používání … 9.3.4 Potvrzení zprávy SDM … 9.3.5 Příklad … 9.4 Návrh na předání (HOP) … 9.4.1 Účel zprávy HOP … 9.4.2 Obsah zprávy … 9.4.3 Pravidla používání … 9.4.4 Potvrzení zprávy HOP … 9.4.5 Příklad … 9.5 Zpráva žádosti o předání na spojení (ROF) … 9.5.1 Účel zprávy ROF … 9.5.2 Obsah zprávy … 9.5.3 Pravidla používání … 9.5.4 Potvrzení zprávy ROF … 9.5.5 Příklad … 9.6 Zpráva o změně kmitočtu (COF) … 9.6.1 Účel zprávy COF … 9.6.2 Obsah zprávy … 9.6.3 Pravidla používání … 9.6.4 Potvrzení zprávy COF … 9.6.5 Příklady … 9.7 Manuální převzetí spojení a řízení (MAS) … 9.7.1 Účel zprávy MAS … 9.7.2 Obsah zprávy … 9.7.3 Pravidla používání … 9.7.4 Potvrzení zprávy MAS … 9.7.5 Příklad … PŘÍLOHA A (NORMATIVNÍ) PRAVIDLA VKLÁDÁNÍ DAT … PŘÍLOHA B (NORMATIVNÍ) POŽADAVKY NA VYTVOŘENÍ SPECIÁLNÍCH TRATÍ… PŘÍLOHA C (INFORMATIVNÍ) FÁZE DIALOGOVÉHO POSTUPU (ÚROVEŇ SYSCO 1) — POŘADÍ ZPRÁV … UPOZORNĚNÍ NA AUTORSKÁ PRÁVA Tento dokument vypracovala agentura Eurocontrol. Držitelem autorských práv je agentura Eurocontrol. Obsah nebo kterákoli část tohoto dokumentu je tímto volně k dispozici zástupcům členských států, ale kopírování nebo prozrazení jakékoli další straně podléhá předchozímu písemnému souhlasu agentury Eurocontrol. PŘEDMLUVA 1. Odpovědný orgán Norma Evropské organizace pro bezpečnost leteckého provozu (Eurocontrol) pro výměnu dat on-line (OLDI — On-Line Data Interchange), verze 2.2, byla vypracována Ředitelstvím pro rozvoj evropského programu harmonizace a integrace řízení leteckého provozu (DED-EATCHIP — Directorate of European ATC Harmonisation and Integration Programme Development) Eurocontrol, které je také odpovědné za aktualizaci uvedeného dokumentu. Veškeré připomínky nebo dotazy je nutno zasílat na adresu: Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, for the attention of (k rukám) Division DED-2. 2. Vztah k pracovnímu dokumentu EATCHIP Tato norma představuje zakázku v rámci odborného úkolu DPS.ET1.ST06 sekce EATCHIP, jak je určeno v pracovním dokumentu EATCHIP (EWPD), verze 2.0, ze dne 30.9.1994. 3. Schvalování a změny Tato norma byla podrobena následujícímu postupu schvalování podrobně uvedenému ve směrnicích pro normalizaci Eurocontrol: - schvalování pracovní skupinou pro provozní požadavky EATCHIP a zpracování dat ATM (ODT) pomocí korespondenčního postupu, - konzultace všech členských států Evropské konference pro civilní letectví (ECAC — European Civil Aviation Conference) prostřednictvím jejich zástupců ve Výboru pro řízení nebo v Radě projektu EATCHIP - schvalování Radou projektu EATCHIP a Výborem pro řízení, - přijetí Stálou komisí. Ustanovení normy vstupují v platnost po přijetí Stálou komisí. Ke splnění požadavků vývoje postupů ATC lze prostřednictvím pracovní skupiny pro provozní požadavky EATCHIP a zpracování dat ATM (ODT) navrhovat změny a dodatky k projednání a případnému schválení. Uvedené požadavky se začlení buď v rámci změny, nebo v rámci nové verze dokumentu k podpisu a schválení v souladu s uvedenými postupy. 4. Redakční postupy Aby se vyznačila funkce každého výroku, dodržují se následující postupy: normativní prvky jsou vytištěny obyčejným písmem, doporučené prvky jsou vytištěny obyčejnou kurzívou a jejich funkce je vyznačena nadpisem Doporučení. Při psaní specifikace se dodržují následující redakční postupy: pro normativní prvky se používá přítomného popř. budoucího času slovesa nebo pomocného slovesa "muset/nesmět", vazeb "je nutno" apod. (v angličtině pomocné sloveso "shall") a pro doporučené prvky podmiňovacího způsobu slovesa "mít" (v angličtině pomocné sloveso "should"). Poznámky jsou vytištěny obyčejnou kurzívou s označením "POZNÁMKA". 5. Vztah k verzi 1 normy Eurocontrol pro výměnu dat on-line (OLDI) Tento dokument nahrazuje části 1 a 2 verze 1 normy Eurocontrol pro výměnu dat on-line. Část 3, která popisuje technické protokoly, které mají být použity, se nahrazuje částí 1 normy Eurocontrol definující rozhraní pro výměnu dat o letu. 6. Významné změny oproti verzi 1 Dále jsou uvedeny nejvýznamnější změny a dodatky oproti verzi 1: 1. Začlenění následujících doplňkových (nepovinných) zpráv pro základní postup: - zpráva zrušení koordinace (MAC, - Zpráva o přidělení kódu sekundárního sledovacího radaru SSR (COD), - Informativní zpráva (INF). 2. Definice obsahu a formátu zprávy pro podporu traťové hranice, která není definovanou tratí letových provozních služeb (trať ATS), ale která je definována výchozím a koncovým bodem segmentu trasy. 3. Začlenění dialogového postupu, který umožňuje: - určení a vyjednávání nestandardních podmínek předání řídícími letového provozu, kteří provádí plánování, - zajištění schopnosti přijímací jednotky podmínek předání, - umožnění prostředků pro předání spojení v rámci postupu předání řízení. 4. Je zavedeno použití formátu popsaného ve verzi 2 normy Eurocontrol pro způsob výměny dat ATS (ADEXP). Veškeré zprávy určené v rámci základního postupu a ty, které se používají během koordinační fáze dialogového postupu, jsou popsány jak pomocí formátů Mezinárodní organizace pro civilní letectví (ICAO — International Civil Aviation Organisation), tak pomocí formátů ADEXP. Přenos uvedených v rámci dialogového postupu je popsán pouze pomocí formátu ADEXP. 5. Zrušení následujících příloh verze 1: A : Identifikace stanoviště ATC) B : Struktura zprávy OLDI (všechny zprávy verze 3 zahrnují příklady) D : Historický přehled E : Prováděcí plán F : Dodržování členskými státy G : Zásady pro zavádění H : Zásady pro ověřování OLDI 6. Oddělení části 3 — Technické požadavky — od specifikací aplikací 7. Vztah k jiným dokumentům Tento dokument odkazuje na použití dvou typů formátu polí při sestavování zprávy: ICAO a ADEXP. Formáty polí ICAO jsou popsány v odkaze 1. V případě nahrazení odkazu 1 jiným dokumentem se budou definice typů polí ICAO řídit popisem uvedeným v dotyčném dokumentu. Formáty polí ADEXP jsou popsány v odkaze 2. POZNÁMKA: Referenční dokumenty jsou uvedeny v oddíle 2. 8. Použitý jazyk K vypracování originálu tohoto dokumentu byl použit anglický jazyk. 1. ÚVOD 1.1 Účel 1.1.1 Lety zajišťované službou ATC jsou předávány z jednoho stanoviště ATC na další způsobem, který zajistí naprostou bezpečnost. Aby se tohoto cíle dosáhlo, je standardním postupem, že přelet každého letu přes hranice prostoru odpovědnosti příslušných dvou jednotek je mezi nimi koordinován předem a že se řízení letu předává v okamžiku, kdy je letadlo na tomto rozhraní nebo poblíž něj. 1.1.2 Pokud se provádí telefonicky, je předávání dat o jednotlivých letech jako součást koordinačního postupu hlavním podpůrným úkolem stanoviště ATC, zvláště u oblastních středisek řízení. Provozní využívání propojení mezi systémem zpracování letových dat (FDPS — Flight Data Processing Systems) na úrovni oblastních středisek řízení (ACC) za účelem náhrady příslušných ústních "odhadů", což se nazývá výměna dat on-line (OLDI), začalo v Evropě na počátku osmdesátých let dvacátého století. 1.1.3 Aby se usnadnilo zavedení takové výměny, byla příslušnými institucemi vypracována a schválena společná pravidla a formáty zpráv a tyto byly zahrnuty do verze 1 normy Eurocontrol pro výměnu dat on-line, tato verze dokumentu byla vypracována pro podporu pokračujícího rozvoje takových zařízení ve shodě s požadavky Evropského programu harmonizace a integrace řízení leteckého provozu (European ATC Harmonisation and Integration Programme — EATCHIP). 1.2 Oblast působnosti 1.2.1 Tento dokument určuje vybavení a zprávy, které mají být poskytovány mezi FDPS sloužícími stanovištím ATC za účelem dosažení: - koordinace požadované před předáním letů z jedné jednotky na jednotku následující, - předání spojení s takovými lety. 1.2.2 Tento dokument: - definuje formáty zpráv a pravidla pro jejich obsah, - popisuje vybavení požadované pro takové jednotky, které je nezbytným předběžným předpokladem používání výměny dat k uvedenému účelu. 1.2.3 Tato norma platí mezi členskými státy Eurocontrol pro mezinárodní zařízení (OLDI) mezi stanovišti poskytujícími oblastní služby ATC. 1.2.4 Doporučení: Doporučuje se, aby členské státy Evropské konference pro civilní letectví (ECAC) uplatnily tuto normu na: - mezinárodní zařízení OLDI mezi stanovišti poskytujícími služby ATC v oblasti ECAC, - zařízení OLDI mezi stanovišti poskytujícími oblastní služby ATC uvnitř daného státu.. 2. ODKAZY 2.1 Následující dokumenty obsahují předpisy, které se odkazem v tomto textu stávají předpisy této normy Eurocontrol. V době zveřejnění této normy Eurocontrol byly v platnosti uvedené verze referenčních dokumentů. Jakékoli opravy dokumentů ICAO, na které se odkazuje, budou neprodleně vzaty v úvahu pro přepracování této normy Eurocontrol. Oprava jiných dokumentů, na které se odkazuje, netvoří součást této normy Eurocontrol, dokud a pokud nejsou oficiálně přezkoumány a začleněny do této normy Eurocontrol. V případě rozporu mezi požadavky této normy Eurocontrol a obsahem uvedených jiných dokumentů, na které se odkazuje, se dává přednost této normě Eurocontrol. 2.2 V této normě se odkazuje na následující dokumenty: 1. Postupy pro letové navigační služby — pravidla létání a letové provozní služby (Procedures for Air Navigation Services — Rules of the Air & Air Traffic Services) dokument ICAO 4444, třináctá verze ze dne 7. listopadu 1996, v platném znění. 2. Verze 2.0 normy Eurocontrol pro způsob výměny dat ATS (ADEXP), odkaz DPS-ET1-ST09-STD-01-00, červen 1998. 3. DEFINICE, SYMBOLY A ZKRATKY 3.1 Definice Pro účely této normy Eurocontrol se rozumí: "přebírajícím stanovištěm" (Accepting Unit) stanoviště poskytující služby ATC, které převezme nebo převzalo řízení letu při předání z jedné jednotky na druhou. "potvrzením" (Acknowledgement) oznámení, že zpráva byla přijata a ověřena jako bezchybně zpracovatelná; "aktivací" (Activation) postup přijímajícího stanoviště ATC, kterým se aktualizuje letový plán příslušného letu tak, aby zahrnoval data poskytnutá předávajícím stanovištěm v rámci postupu koordinace mezi uvedenými dvěma stanovišti, jehož výsledkem je poskytnutí dat řídícím letového provozu; "nadmořskou výškou" (Altitude): vertikální vzdálenost roviny, bodu nebo objektu uvažovaného jako bod, měřená od průměrné úrovně hladiny moře; "aplikací" (Application) taková součást podsystému ATS, která splňuje tuto normu a je propojena se stejnými prvky jiných systémů ATS; "prostorem odpovědnosti" (Area of Responsibility) vzdušný prostor definovaných rozměrů, v rámci kterého poskytuje stanoviště ATC letové provozní služby; "přičleněním" (Association) postup, během kterého systém propojí přijatou zprávu OLDI se záznamem letového plánu v databázi; "stanovištěm ATC" (ATC Unit) stanoviště, která poskytuje služby řízení letového provozu; "dostupností" (Availability) pravděpodobnost, že zařízení bude v určitém čase dostupné uživateli; "hranicí" (Boundary) roviny (boční a výškové), které vymezují prostor odpovědnosti určitého stanoviště ATC; "povolenou letovou hladinou" (Cleared Flight Level) letová hladina, na které nebo na kterou byl ATC aktuálně povolen let; "koordinací řízení letového provozu" (Co-ordination, ATC) postup oficiálního vzájemného oznamování plánovaných přeletů hranice uskutečňovaný mezi stanovišti ATC, jejichž prostor odpovědnosti vzájemně sousedí, jehož účelem je zajistit bezpečnost letu pomocí vzájemné sladěnosti zamýšlených činností; "koordinační zprávou" (Co-ordination Message) obecný pojem odkazující na zprávu používanou k dosažení koordinace ATC. Tyto zprávy zahrnují koordinační zprávu CDN, což je zvláštní zpráva popsaná v odstavci 8.8; "koordinační fází" (Co-ordination Phase) fáze daného letu, během které předávající a přijímající stanoviště ATC dohodnou podmínky (např. letovou hladinu, bod na hranici) za kterých bude let předán do řízení druhého stanoviště; "koordinačním bodem" (Co-ordination Point) bod na nebo v blízkosti hranice známý stanovištím ATC v koordinační posloupnosti, na který se odkazuje v koordinačních zprávách; "korelací" (Correlation) postup založený na definovaných kriteriích propojení dat letového plánu a radarovém tracku téhož letu, který se obvykle používá pro prezentaci na monitoru řídícího letového provozu; "normou Eurocontrol" (Eurocontrol Standard) jakákoli specifikace fyzikálních charakteristik, konfigurace, materiálu, provedení, pracovníků nebo postupu, jejíž jednotné uplatnění bylo schváleno jako nezbytné pro zavedení v systémech ATS v rámci členských států Eurocontrol. Norma Eurocontrol nesmí být v rozporu s normami ICAO, ale měla by je ve vhodných případech doplňovat; "výkonným řídícím letového provozu" (Executive Controller) řídící letového provozu, který poskytuje pokyny přímo letům, které řídí. Mezi takové řídící letového provozu patří ti, kteří zajišťují službu oblastního radarového řízení; "letovou hladinou opuštění oblasti" (Exit Level): letová hladina, na které byl let koordinován pro překročení bodu předání řízení. Výstupní letová hladina (XFL) může zahrnovat doplňkové podmínky předání, které definují pásmo letových hladin stoupání/klesání letu; "letovým plánem" (Flight Plan) určené údaje poskytnuté stanovištím letové provozní služby, které se týkají zamýšleného letu určitého letadla nebo části tohoto letu. Dále též údaje, které jsou získány z letového plánu určitého letu a uchovávány v rámci systému zpracování letových dat (FDPS); "generováním" (Generate) postup systému ATC, při kterém jsou příslušná data vyhledána v databázi/databázích a je sestavena zpráva pro přenos pro přijímající stanoviště ATC; "formátem ICAO" (ICAO Format) formát používaný pro přenos země — země zpráv ATS, který používá typy polí a separátorů popsané v odkaze 1; "letovou hladinou" (Level) obecný pojem pro vertikální polohu letadla během letu, v rámci této normy zahrnuje pojem hladina nebo letová hladina nadmořskou výšku; "oznámením" (Notification) postup, kterým předávající stanoviště odesílá data k aktualizaci systému přijímajícímu stanovišti; "přijímacím stanovištěm" (Receiving Unit) stanoviště ATC, kterému je odesílána zpráva; "spolehlivostí" (Reliability) procento plánované dostupnosti služby, tj. doby, kdy ji bude možno využívat; "požadovanou letovou hladinou" (Requested Flight Level) letová hladina požadovaná pro let v letovém plánu; "opravou" (Revision) změna dat dříve odeslaných předávajícím stanovištěm ATC přijímajícímu stanovišti ATC; "doplňkovou přeletovou hladinou" (Supplementary Crossing Level) letová hladina, na které nebo nad kterou, nebo na které nebo pod kterou, byl let koordinován pro přelet bodu předání řízení. Doplňková přeletová hladina, je-li použita, je prvkem výstupní letové hladiny (XFL); "systémovým letovým plánem" (System Flight Plan) údaje získané z letového plánu určitého letu uložené v systému zpracování letových dat (FDPS); "časem transakce" (Transaction Time) časový interval po spuštění zprávy, během kterého se provede její přenos, prvotní zpracování v přijímajícím systému, generování a přenos potvrzení zprávy a jeho identifikace v předávajícím systému; "bodem předání řízení" (Transfer of Control Point) definovaný bod umístěný na dráze letu, ve kterém se převádí odpovědnost za poskytování služby ATS letadlu z jednoho stanoviště ATC nebo řídícího pracoviště na následující. Není nutně totožný s bodem koordinace; "fází předání" (Transfer Phase) fáze letu následující po koordinační fázi, během které se provádí předání spojení; "předávajícím stanovištěm" (Transferring Unit) v rámci koordinační sekvence stanoviště ATC, které je odpovědné za poskytování služeb danému letu před dosažením hranice a které zahajuje koordinační fázi s následující jednotkou; "vysíláním" (Transmit) předávání zprávy z jednoho systému do druhého; "stanovištěm" (Unit) stanoviště letové provozní služby; "výstrahou" (Warning) zpráva zobrazená na provozním pracovišti, pokud dojde k selhání automatického postupu koordinace. 3.2 Symboly a zkratky Pro účely této normy Eurocontrol platí následující symboly a zkratky. ABI Advance Boundary Information Message — Předběžná informační zpráva o přeletu hranice ACC Area Control Centre — Oblastní středisko řízení ACP Accept Message — Akceptační zpráva ACT Activate Message — Aktivační zpráva ADEXP ATS Data Exchange Presentation — Způsob výměny údajů letových provozních služeb (ATS) ATC Air Traffic Control — Řízení letového provozu ATM Air Traffic Management — Uspořádání letového provozu ATS Air Traffic Services — Letové provozní služby CDN Co-ordination Message — Koordinační zpráva CNL Flight Plan Cancellation — Zpráva o zrušení letového plánu COD SSR Code Assignment Message — Zpráva o přidělení kódu sekundárního přehledového radaru (SSR) COF Change of Frequency Message — Zpráva o změně kmitočtu COP Co-ordination Point — Koordinační bod DED Directorate of EATCHIP Development, Eurocontrol — Ředitelství pro rozvoj Evropského programu harmonizace a integrace řízení letového provozu (EATCHIP) agentury, Eurocontrol EATCHIP European ATC Harmonisation and Integration Programme — Evropský program harmonizace a integrace řízení letového provozu ECAC European Civil Aviation Conference — Evropská konference pro civilní letectví ETO Estimated Time Over — Předpokládaný čas přeletu ETOT Estimated Take-Off Time — Předpokládaný čas vzletu EWPD EATCHIP Work Programme Document — Dokument pracovního programu Evropského programu harmonizace a integrace řízení letového provozu (EATCHIP) FDPS Flight Data Processing System — Systém zpracování letových údajů FRF Further Route of Flight — Další trasa letu HMI Human-Machine Interface — Rozhraní člověk/přístroj HOP Handover Proposal Message — Zpráva o návrhu na předání ICAO International Civil Aviation Organisation — Mezinárodní organizace pro civilní letectví INF Information Message — Informativní zpráva LAM Logical Acknowledgement Message — Zpráva o příjmu a zpracování předchozí zprávy LoA Letter of Agreement — Dopis o dohodě MAC Message for the Abrogation of Co-ordination — Zpráva o zrušení koordinace MAS Manual Assumption of Communications — Ruční převzetí spojení a přenosu NM Nautical Mile — Námořní míle OLDI On-Line Data Interchange — Výměna přímých (spřažených) údajů ORCAM Originating Region Code Assignment Method — Metoda přidělení kódu výchozího okrsku PAC Preliminary Activate Message — Zpráva o předběžné aktivaci RAP Referred Activate Proposal Message — Zpráva o návrhu postoupené aktivace REV Revision Message — Zpráva o změně koordinačních údajů RJC Reject Co-ordination Message — Zpráva o odmítnutí koordinace ROF Request on Frequency Message — Zpráva o žádosti o předání na spojení RRV Referred Revision Message — Zpráva o postoupené změně nestandardních koordinačních podmínek, zpráva RRV SBY Stand-by Message — Zpráva SDM Supplementary Data Message — Zpráva doplňku letových údajů SSR Secondary Surveillance Radar — Sekundární přehledový radar SYSCO System Supported Co-ordination — Systémově podporovaná koordinace TI Transfer Initiation — Zahájení předání TIM Transfer Initiation Message — Zpráva o zahájení předání TWR/APP Tower (aerodrome control) and Approach Control — Letištní řídící věž a přibližovací stanoviště řízení 4. VŠEOBECNÉ POŽADAVKY 4.1 Úvod Tento oddíl popisuje obecné provozní požadavky nutné pro zavedení zařízení OLDI mezi stanovišti ATC a klasifikační a výkonnostní požadavky pro různé typy použitých zpráv. 4.2 Požadavky na systém zpracování letových dat (FDPS) 4.2.1 Databáze letů Stanoviště, které používají zařízení popsané v tomto dokumentu, obdrží data z FDPS obsahující veškeré údaje potřebné pro zobrazení, zpracování a sestavení zpráv, jak je určeno. Hlavním zdrojem dat pro každý let je letový plán vyplněný velitelem letadla nebo v jeho zastoupení. Další položky dat se získávají zpracováním letových plánů s ohledem na vybavení dotyčné jednotky. 4.2.2 Provoz v reálném čase Postup OLDI zahrnuje události v předávajícím stanovišti ATC, které spouštějí funkce nutné pro včasnou prezentaci dat předávajícímu řídícímu letového provozu a přenos koordinačních dat přebírajícímu stanovišti. Za tímto účelem musí být FDPS schopen spouštět funkce pomocí porovnání světového koordinovaného času a příslušných časových parametrů s časy v určených polohách tratí letu, jak je určena z databáze letů. 4.2.3 Způsobilost pro přenos dat 4.2.3.1 FDPS musí být schopen přijímat a vysílat letová data ve formátu platném pro danou zprávu, jak je určen v tomto dokumentu, prostřednictvím média pro přenos dat, které umožňuje funkce OLDI. 4.2.3.2 Doporučení: FDPS by měl mít vývojový potenciál, který by umožňoval doplnění nových zpráv, které možná budou součástí následujících verzí této normy. 4.2.3.3 V rámci výkonnostních požadavků určených v tomto dokumentu musí médium pro přenos dat umožňovat rychlou a spolehlivou výměnu dat mezi aplikacemi tím, že: - zaručuje neporušenost přenosu zprávy OLDI a - průběžně kontroluje buď spojení bod —bod nebo stav komunikační sítě, jak je příslušné. 4.2.3.4 Pokud systém pro přenos dat zjistí výskyt anomálií, varuje FDPS provozní pracoviště. 4.2.4 Funkce aplikace 4.2.4.1 Systémy používané pro poskytování služeb OLDI musí být schopny automaticky přijímat, uchovávat, zpracovávat, vyhledávat a dodávat pro zobrazení a vysílat data týkající se OLDI v reálném čase. 4.2.4.2 FDPS musí: - zobrazovat aktuální provozní data týkající se OLDI, jak je požadováno touto normou, aktualizovaná automaticky, ručním zadáním nebo kombinací obou možností, - být schopný vybrat takové prvky z databáze letového plánu, - určit následující stanoviště ATC na trati letu. 4.2.4.3 Následující body je nutno dohodnout vzájemně: - Koordinační body (COP) - referenční body používané pro záznamy směrů a vzdáleností při určování koordinačních bodů na přímých úsecích tratí bez ATS pokud jsou použity. POZNÁMKA: COP nemusí být vždy totožné s body předání řízení. 4.2.5 Rozhraní člověk/stroj (HMI) 4.2.5.1 Rozhraní člověk/stroj musí být schopno: - zobrazit pracovní obsah zpráv OLDI a příslušné výstrahy týkající se přijatých zpráv, které vyžadují okamžitou pozornost, - směrovat výstrahy pro koordinační zprávy a zprávy o předání na provozní pracoviště odpovědná za koordinaci příslušných letů. 4.2.5.2 Pracovníci ATC musí být vybaveni prostředky ke změně dat, ze kterých se odvozuje pracovní obsah zpráv, jak je požadováno v tomto dokumentu. 4.2.5.3 HMI musí dle potřeby zobrazovat, že probíhá nebo byl úspěšně ukončen přenos zprávy. 4.2.5.4 Výstraha nebo oznámení příslušnému ATC nebo technickému pracovišti se generuje automaticky, pokud v hranici určeného časového parametru po přenosu koordinační zprávy nebo zpráva o předání nedojde k přijetí potvrzení. 4.2.5.5 Taková výstraha nebo oznámení musí mít formu, která neprodleně získá pozornost příslušného provozní pracoviště. 4.2.5.6 Doporučení: HMI na stanovištích ATC, která používají OLDI, by měla zajišťovat výstrahu, pokud služba OLDI není dostupná. 4.2.6 Spouštění zpráv 4.2.6.1 Každý systém musí obsahovat soubor systémových parametrů, aby se zajistilo včasné automatické spuštění zpráv OLDI. 4.2.6.2 Doporučení: Měla by být k dispozici schopnost ručního spuštění přenosu koordinační zprávy před vypočteným časem přenosu. 4.2.6.3 Pokud není provedeno ruční spuštění, musí být automatická akce vždy zajištěna. 4.2.6.4 K definici následujících položek musí systém používat časové parametry: - střední (průměrný) čas, po který je zobrazen pracovní obsah zprávy v předávajícím stanovišti před jejím přenosem, - střední (průměrný) čas zaslání zprávy, celkový nebo případně na COP, - čas po přenosu zprávy, do kterého má být přijato potvrzení na úrovni aplikace (prodleva). 4.2.6.5 Pokud se požadované údaje stanou dostupnými později než v čase, kdy by byla zpráva obvykle vysílána, musí být zpráva vysílána bezodkladně. Příklad: Let vstoupí do úseku GAT IFR v bodě poblíž hranice, kterou má poté překročit, ETO v daném bodě je sdělen osm minut před COP, kdy je přenos zprávy ACT podle příslušných časových parametrů již zpožděn, zpráva je odeslána bezodkladně. 4.2.7 Příjem zpráv 4.2.7.1 Systém ATC musí být schopen: - přijímat zprávy OLDI, - zpracovávat je automaticky v souladu touto normou, - produkovat letová data v souladu s přijatou zprávou a zobrazit požadované výstrahy v případě rozpornosti přijatých dat, - generovat a vysílat na úrovni aplikace automaticky potvrzení. 4.2.7.2 Potvrzení (zpráva o příjmu a zpracování předchozí zprávy (LAM), akceptační zpráva (ACP) nebo zpráva "vyčkejte" (SBY)) musí být generováno a vysíláno po zajištění zpracování odpovídající zprávy a prezentaci výsledků zpracování příslušnému stanovišti dle potřeby. POZNÁMKA: Podrobné podmínky generování potvrzení jsou určeny jednotlivě pro každou zprávu. 4.3 Aktualizace dat na základě kontroly Doporučení: Aby se zajistila přesnost dat odhadu času, měly by být k aktualizaci databáze letového plánu použity údaje získané sledováním letů pomocí radaru nebo jiných nástrojů sledování. 4.4 Záznam údajů OLDI 4.4.1 Obsah Obsah všech zpráv OLDI a čas jejich příjmu musí být zaznamenány. 4.4.2 Služby Musí být k dispozici služby pro vyhledávání a zobrazení zaznamenaných dat. 4.5 Dostupnost, spolehlivost, ochrana dat a jejich neporušenost 4.5.1 Dostupnost 4.5.1.1 Služba OLDI musí být dostupná v hodinách normální a špičkové prostupnosti prostoru mezi příslušnými dvěmi stanovišti. 4.5.1.2 Doporučení: Služba OLDI by měla být dostupná nepřetržitě. 4.5.1.3 Jakákoli plánovaná doba trvání výpadku (a tím i plánovaná doba dostupnosti) musí být vzájemně dohodnuty mezi příslušnými dvěmi stanovišti. 4.5.2 Spolehlivost 4.5.2.1 Spolehlivost každého spojení OLDI musí být nejméně 99,86 % (což se rovná době trvání výpadku nepřesahujícímu 12 hodin ročně při 24hodinové dostupnosti). 4.5.2.2 Doporučení: Kde je to provozně oprávněné, měla by být zajištěna spolehlivost nejméně 99,99 % (což se rovná době trvání výpadku nepřesahujícímu 52 minut ročně při 24hodinové dostupnosti). 4.5.3 Ochrana dat Doporučení: Pro služby OLDI by měly být používány metody ochrany dat např. přístupová práva, ověření zdroje a — kde je to použitelné — správa sítě. 4.5.4 Integrita dat Poruchovost na úrovni aplikace nesmí překročit jednu chybu přenosu na 2000 zpráv. 4.6 Provozní hodnocení 4.6.1 Doba hodnocení Každé nové zařízení OLDI, včetně nového zařízení na stávajícím spoji, musí být podrobeno době hodnocení, aby se před jeho uvedením do provozu ověřila integrita dat, přesnost, výkonnost, slučitelnost s postupy ATC a celková bezpečnost. POZNÁMKA: Postup nápomocný při hodnocení nového OLDI je k dispozici na sekretariátu OLDI Evropské organizace pro bezpečnost leteckého provozu (Eurocontrol). 4.6.2 Datum uvedení do provozu Datum uvedení do provozu, tj. ukončení doby hodnocení, musí být oficiálně dohodnuto mezi oběma stanovišti. 5. KATEGORIE ZPRÁV 5.1 Úvod 5.1.1 Účel Tento oddíl dokumentu: - definuje kategorie zpráv, - uvádí požadavky na čas transakce pro dotyčné kategorie, - uvádí, které zprávy jsou povinné a které doplňkové, - přiřazuje typy zpráv kategoriím. 5.1.2 Kategorie zpráv Zprávy OLDI byly zařazeny do následujících kategorií: - Kategorie 1: předání spojení - Kategorie 2: koordinace, - Kategorie 3: oznámení. 5.2 Časy transakcí 5.2.1 Požadavky na čas transakce 5.2.1.1 Určené časy transakcí zahrnují přenos, prvotní zpracování v přijímajícím stanovišti, generování potvrzení, jeho přenos a příjem na předávajícím stanovišti. Proto nebyly zprávy automatického potvrzení LAM a SBY zařazeny do žádné kategorie zpráv. 5.2.1.2 Maximální časy transakcí pro různé kategorie zpráv musí odpovídat údajům v tabulce 5-1. Tabulka 5-1 Maximální časy transakcí Message Category | 90 % | 99,8 % | 1 | 4 sec | 10 sec | 2 | 10 sec | 25 sec | 3 | 15 sec | 45 sec | 5.2.1.3 Časový parametr musí být definován pro kategorii nebo typ zprávy. 5.2.1.4 Pokud nebylo v určeném čase po přenosu přijato potvrzení, je nutné zprávu považovat za neúspěšně zaslanou nebo neúspěšně zpracovanou a musí být generována výstraha, jak je určeno v příslušném oddíle tohoto dokumentu. 5.2.1.5 Doporučení: Časový parametr pro uvedené tři kategorie by neměl překročit 12 sekund, 30 sekund a 60 sekund v daném pořadí. 5.3 Zařazení zpráv do tříd a kategorií 5.3.1 Zařazení zpráv do tříd — povinné a doplňkové 5.3.1.1 Zprávy popsané v tomto dokumentu jsou zařazeny do tříd jako povinné nebo doplňkové. 5.3.1.2 Je-li zpráva popsána jako povinná (M — mandatory) pro přenos (TX — transmission), je nutné zahrnout zpracování umožňující zasílat takové zprávy. 5.3.1.3 Je-li zpráva popsána jako povinná pro příjem (REC — reception), je nutné zahrnout zpracování umožňující zpracovat přijaté zprávy. POZNÁMKA: Ve výjimečných případech, kdy je provoz mezi dvěma stanovišti jednosměrný, mohou být povinné zprávy použitelné pouze v jednom směru. 5.3.1.4 Je-li zpráva popsána jako doplňková (C — complementary) pro přenos, je nutné zahrnout zpracování umožňující zasílání takových zpráv, pokud jsou požadovány zasílajícím stanovištěm a vzájemně dohodnuty s přijímacím stanovištěm. POZNÁMKA: Doplňkové zprávy lze použít pouze v jednom směru, jak určují provozní požadavky. 5.3.1.5 Je-li zpráva popsána jako doplňková pro příjem, je nutné zahrnout zpracování umožňující zpracovat přijaté zprávy, pokud je takové použití vzájemně dohodnuto. 5.3.1.6 Požadavky popsané v tabulkách 5-3 a 5-4 jsou použitelné pouze tehdy, pokud bylo mezi stanovišti ATC vzájemně dohodnuto použití dialogového postupu koordinace a/nebo předání spojení. 5.3.2 Zařazení zpráv do kategorií 5.3.2.1 Zařazení zpráv do kategorií pro základní postup je určeno v tabulce 5-2. 5.3.2.2 Zařazení doplňkových koordinačních zpráv pro dialogový postup do kategorií je určeno v tabulce 5-3. 5.3.2.3 Zařazení komunikačních zpráv pro dialogový postup do kategorií přenosu je určeno v tabulce 5-4. Tabulka 5-2 Zprávy pro základní postup Typ zprávy | Zkratka | Kategorie | Přenos | Příjem | Předběžná informační zpráva o přeletu hranice FIR | ABI | 3 | M | M | Aktivační zpráva | ACT | 2 | M | M | Zpráva o změně koordinačních dat | REV | 2 | C [1] | C [1] | Zpráva o předběžné aktivaci | PAC | 2 | C | C | Zpráva zrušení koordinace | MAC | 2 | C | C | Zpráva o přidělení kódu | COD | 2 | C | C | Informativní zpráva | INF | 3 | C | C | Zpráva o příjmu a zpracování předchozí zprávy | LAM | | M | M | Tabulka 5-3 Dialogový postup — zprávy koordinační fáze (Doplňková k tabulce 5-2) Typ zprávy | Zkratka | Kategorie | Přenos | Příjem | Zpráva navrhující nestandardní podmínky předání předložená přijímajícímu řídícímu | RAP | 2 | C | M | Zpráva o změně nestandardních koordinačních podmínek | RRV | 2 | C | M | Koordinační zpráva | CDN | 2 | M | M | Zpráva vyčkejte [2] | SBY | | M | M | Akceptační zpráva | ACP | 2 | M | M | Zpráva o odmítnutí koordinačních dat [3] | RJC | 2 | C | C | Tabulka 5-4 Dialogový postup — zprávy fáze předání Typ zprávy | Zkratka | Kategorie | Přenos | Příjem | Zpráva zahájení předání | TIM | 1 | M | M | Zpráva doplňku letových dat | SDM | 1 | [4] | [4] | Zpráva "návrh na předání" | HOP | 1 | M | M | Zprávu o změně kmitočtu [5] | COF | 1 | C | M | Zpráva žádosti o předání na spojení | ROF | 1 | C | M | Manuální převzetí spojení a řízení [5] | MAS | 1 | C | M | 6. ZÁKLADNÍ POSTUP — POVINNÉ ZPRÁVY 6.1 Úvod 6.1.1 Popis požadavků Tento oddíl popisuje minimální požadavky na úrovni aplikace pro zavedení služeb OLDI. 6.1.2 Zavedení Stanoviště používající OLDI pro koordinaci letů musí zavést ABI, ACT a LAM, jak je popsáno v tomto oddíle, pokud nebylo vzájemně dohodnuto používání dialogového postupu koordinace, jak je popsán v oddíle 8 tohoto dokumentu, v kterémžto případě se podmínky používání zpráv ACT a LAM řídí uvedeným oddílem. 6.2 Předběžná informační zpráva o přeletu hranice FIR (ABI) 6.2.1 Účel zprávy ABI Zpráva ABI splňuje následující provozní požadavky: - zajišťuje získání chybějících dat letového plánu, - poskytuje následujícímu stanovišti ATC předběžné údaje o hranici a jejich opravě, - aktualizuje základní data letového plánu, - umožňuje včasné porovnání radarového tracku, - umožňuje přesné krátkodobé hodnocení zatížení sektoru. ABI je oznamovací zpráva. 6.2.2 Obsah zprávy Zpráva ABI musí obsahovat následující datové položky: - Typ zprávy, - Číslo zprávy, - Identifikace letadla - Mód a kód sekundárního radaru (SSR) (je-li k dispozici), - Letiště vzletu - Předběžná data, - Letiště zamýšleného přistání - Číslo a typ letadla, - Trať (nepovinné), - Další data letového plánu (nepovinné). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 6.2.3 Pravidla používání 6.2.3.1 Obecná pravidla 6.2.3.1.1 Kromě případů stanovených níže v bodech 6.2.3.1.3 a 6.2.3.1.4 je nutné zaslat jednu nebo více zprávu ABI pro každý plánovaný let překračující hranici prostoru odpovědnosti v souladu s postupy OLDI. 6.2.3.1.2 Při zasílání musí zpráva ABI předcházet aktivační zprávě (ACT), nebo zprávě navrhující nestandardní podmínky předání předložené přijímajícímu řídícímu. 6.2.3.1.3 Zpráva se negeneruje, má-li být zaslána zpráva o předběžné aktivaci (PAC). 6.2.3.1.4 Doporučení: Přenos ABI by měl být blokován, má-li být zpráva ACT nebo zpráva RAP zaslána neprodleně nebo během vzájemně dohodnutého časového intervalu. POZNÁMKA: Účelem tohoto doporučení je zabránit pokusu o současné rozlišení anomálií na různých pracovištích přijímajícího stanoviště pro zprávy a ACT pro stejný let. 6.2.3.1.5 Revidovanou zprávu ABI je nutné poslat, pokud nebyla generována následná zpráva ACT a: - trať letu se změnila tak, že COP předchozí zprávy ABI již není přesný, - došlo ke změně letiště zamýšleného přistání nebo - došlo ke změně typu letadla. 6.2.3.1.6 Doporučení: Revidovaná zpráva ABI by měla být poslána, pokud nebyla generována následná zpráva a jedna z následujících položek podléhá změně: - předpokládaná přeletová hladina hranice - předpokládaný kód SSR v bodu předání řízení, - pokud se předpokládaný čas přeletu (ETO) v COP liší od předchozí zprávy o více než o čas určený v koordinační dohodě (LoA) - jakákoli další vzájemně dohodnutá data. 6.2.3.2 Zpracování v přijímajícím stanovišti 6.2.3.2.1 Systém ATC přijímající zprávu ABI se musí pokusit o přidružení zprávy datům odpovídajícího letového plánu. 6.2.3.2.2 Je-li přidružení letovému plánu neúspěšné, musí být letový plán vyhotoven automaticky, nebo ručně v přijímajícím systému. 6.2.3.2.3 Je-li přidružení letovému plánu úspěšné, ale mezi daty zprávy a odpovídajícími daty v přijímajícím systému je zjištěn nesoulad, který by vedl k potřebě nápravných opatření při příjmu následující zprávy ACT, dotyčný nesoulad musí být předán příslušnému pracovišti k vyřešení. 6.2.3.3 Časové parametry přenosu 6.2.3.3.1 Zpráva musí být odeslána parametrem určený počet minut před předpokládaným časem dosažení COP. 6.2.3.3.2 Parametr (parametry) generování ABI musí být zahrnuty do koordinační dohody (LoA) mezi dotyčnými stanoviště ATC. 6.2.3.3.3 Doporučení: Parametr (parametry) generování ABI by měl (měly) být: - proměnná založená na ustanoveních koordinační dohody (LoA) - definovány samostatně pro každý COP. 6.2.4 Potvrzení ABI 6.2.4.1 Potvrzení Příjem zprávy ABI musí být potvrzen generováním a odesláním zprávy LAM. POZNÁMKA: Zpráva LAM je generována bez ohledu na výsledky pokusu o přidružení letového plánu. 6.2.4.2 Nedoručení potvrzení Doporučení: Není-li přijata LAM jako potvrzení zprávy, měla by být na kontrolním pracovišti zobrazena výstraha. 6.2.5 Příklady "Air 2000" 253, Boeing 757 z Malty do Birminghamu odhad BNE VOR v 1221 univerzálního koordinovaného času (UTC — universal time coordinated), letící na FL350 pravou vzdušnou rychlostí 480 uzlů, plánovaná trať přes UB4 BNE UB4 BPK UB3 HON, odpovídající na A7012 a požadující FL390. Následují příslušné příklady zprávy ABI odeslané z oblastního řídícího střediska (ACC) v Remeši do ACC Londýn. 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 Aktivační zpráva (ACT) 6.3.1 Účel zprávy ACT Zpráva ACT splňuje následující provozní požadavky: - nahradit ústní odhad hranice automatickým zasláním podrobných údajů o letu z jednoho stanoviště ATC na následující před předáním řízení, - aktualizovat základní data letového plánu v přijímajícím stanovišti ATC nejaktuálnějšími údaji, - usnadnit rozdělení dat letového plánu na jednotlivá zapojená pracoviště na přijímajícím stanovišti ATC a zobrazení těchto dat, - urychlit zobrazení vzájemného vztahu volacího znaku a kódu (callsign/code) v přijímajícím stanovišti ATC, - poskytnout přijímajícímu stanovišti ATC podmínky předání. 6.3.2 Obsah zprávy Zpráva ACT musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - mód a kód sekundárního radaru (SSR), - letiště vzletu, - předběžná data, - letiště zamýšleného přistání, - číslo a typ letadla, - trať (nepovinné), - další data letového plánu. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 6.3.3 Pravidla používání 6.3.3.1 Obecná pravidla 6.3.3.1.1 Jedna zpráva ACT musí být zaslána příslušným letům překračujícím hranice s výjimkou případů stanovených v odstavci 6.3.3.1.10. 6.3.3.1.2 Zpráva ACT musí být generována a zaslána automaticky ve vypočtený čas určený v koordinační dohodě (LoA), pokud není spuštěna ručně před tímto časem. 6.3.3.1.3 Doporučení: Pracovníci ATC by měli být vybaveni prostředky na spuštění přenosu zprávy před vypočteným časem přenosu. 6.3.3.1.4 Pracovní obsah zprávy ACT která má být odeslána, musí být před vlastním přenosem zprávy zobrazen na provozní pracovišti příslušném pro koordinaci letu. 6.3.3.1.5 Doporučení: Ve vztahu k bodu 6.3.3.1.4 by měl být společně s obsahem zprávy zobrazen vypočtený čas, ve kterém má být zpráva ACT automaticky odeslána. 6.3.3.1.6 Zpráva ACT musí obsahovat nejnovější údaje o letu, které odráží předpokládané podmínky opuštění oblasti. 6.3.3.1.7 Příslušné provozní pracoviště musí být upozorněno na přenos zprávy ACT. 6.3.3.1.8 Jakmile byla přijata zpráva LAM, stávají se data zprávy ACT provozně závaznými pro obě stanoviště ATC. S koordinovanými podmínkami předání a se skutečností, že byla přijata zpráva LAM, musí být seznámeni pracovníci řízení letového provozu ATC předávajícího stanoviště. 6.3.3.1.9 Je nutno předpokládat akceptaci podmínek přenosu uvedených ve zprávě ACT přijímajícím stanovištěm, pokud přijímající stanoviště nezahájí koordinaci za účelem změny těchto podmínek. 6.3.3.1.10 Stejnému koordinačnímu partneru lze zaslat další zprávu ACT pouze pokud předchozí zpráva byla zrušena pomocí zprávy MAC. 6.3.3.1.11 Je-li to vzájemně dohodnuto, musí být uvedena trať a další data letového plánu. 6.3.3.2 Zpracování v přijímajícím stanovišti 6.3.3.2.1 Systém ATC přijímající zprávu ACT se musí pokusit o přidružení jejích dat k odpovídajícímu letovému plánu. 6.3.3.2.2 Pokud je nalezen odpovídající letový plán a zpráva neobsahuje žádný nesoulad, který by znemožňoval správné zpracování: - pracovní obsah musí být zahrnut do letového plánu, - požadovaná data musí být vyvedena na řízení letového provozu a další příslušná pracoviště, - musí být odeslána zpět zpráva LAM. 6.3.3.2.3 Nelze-li nalézt odpovídající letový plán nebo je zjištěn nesoulad, který znemožňuje správné zpracování zprávy: - pokud sektor odpovědný za převzetí řízení letu lze určit: - pracovní obsah zprávy se zobrazí v dotyčném sektoru, - musí být odeslána zpět zpráva LAM, - musí být sestaven letový plán, - ve všech ostatních případech nesmí být odeslána zpráva LAM. 6.3.3.3 Parametry přenosu 6.3.3.3.1 Zpráva musí být odeslána v nejbližším čase určeném dle následujících bodů, nebo co nejdříve poté: - parametrem určený počet minut před předpokládaným časem dosažení COP, - čas, kdy let dosáhne vzájemně dohodnuté vzdálenosti od COP. 6.3.3.3.2 Parametr (parametry) generování zprávy ACT musí být obsažen (obsaženy) v koordinační dohodě (LoA) mezi dotyčnými stanovišti ATC. 6.3.3.3.3 Parametr (parametry) generování zprávy ACT musí být proměnná (proměnné) vycházející z ustanovení koordinační dohody (LoA). 6.3.3.3.4 Doporučení: Parametry generování zprávy by měly být definovány samostatně pro každý COP. 6.3.3.3.5 Určené parametry musí poskytovat dostatečný čas pro: - odesílající (vysílající) stanoviště na aktualizaci letové hladiny předání tak, aby odrážela předpokládané podmínky v COP, a - přijímající stanoviště na zpracování zprávy ACT a generování a odeslání zprávy LAM, ale přitom nadále umožňovat provedení ústní koordinace předávajícím stanovištěm a výsledné akce spuštěné přijímajícím stanovištěm, pokud dojde k selhání výměny dat. 6.3.4 Potvrzení zprávy ACT 6.3.4.1 Potvrzení Příjem zprávy ACT musí být potvrzen generováním a odesláním zprávy LAM. 6.3.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy ACT, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 6.3.5 Příklady Následující příklady jsou pokračováním příkladů uvedeným pro zprávu ABI v odstavci 6.2, veškeré podrobné údaje jsou stejné s výjimkou ETO v COP který je v uvedené zprávě ACT 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 Zpráva o příjmu a zpracování předchozí zprávy (LAM) 6.4.1 Účel zprávy LAM Zpráva LAM je prostředkem, jehož pomocí přijímací stanoviště oznamuje vysílajícímu stanovišti příjem a zabezpečení zaslané zprávy. Zpracování zprávy LAM poskytuje pracovníkům ATC z předávajícího stanoviště: - výstrahu, pokud nebylo přijato potvrzení, - oznámení, že zpráva, jejíž příjem byl potvrzen, byla přijata, úspěšně zpracována, nebyly v ní nalezeny chyby, byla uložena a — pokud je to vhodné — je k dispozici pro prezentaci příslušnému pracovišti. 6.4.2 Obsah zprávy Zpráva LAM musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (jejíž příjem se potvrzuje). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 6.4.3 Pravidla používání 6.4.3.1 Obecná pravidla 6.4.3.1.1 Pravidla pro odesílání zprávy LAM jsou určena v těch oddílech tohoto dokumentu, které definují zpracování každé jednotlivé zprávy. 6.4.3.1.2 Zpráva LAM musí být generována a odeslána bez lidského zásahu. 6.4.3.1.3 Zpráva LAM se nepoužije k nahrazení potřeby technických zpráv zajištujících neporušenost přenosů dat. 6.4.3.1.4 Zpráva LAM musí být generována a odeslána neprodleně, aby mohl být dosažen požadovaný čas transakce potvrzení zprávy. 6.4.3.1.5 S výjimkou zpráv ABI musí odesílající systém ATC informovat řídícího letového provozu odpovědného za koordinaci, pokud zpráva LAM nebyla přijata v hranici časového parametru určeného pro takovou výstrahu. 6.4.4 Potvrzení zprávy LAM Zpráva LAM nevyžaduje žádné potvrzení. 6.4.5 Pří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 — DOPLŇKOVÉ ZPRÁVY 7.1 Úvod 7.1.1 Popis požadavků Tento oddíl popisuje služby použitelné pro základní postup, které jsou doplňkové ke službám popsaným v oddíle 6, Základní postup — povinné zprávy. 7.1.2 Zavedení 7.1.2.1 Použití kterékoli ze služeb popsaných v tomto oddíle musí být před jejich zavedením vzájemně dohodnuto. 7.1.2.2 Je-li takové použití dohodnuto, musí být uplatněna pravidla popsaná v tomto oddíle. 7.2 Zpráva o předběžné aktivaci ( PAC) 7.2.1 Účel zprávy PAC Zpráva PAC splňuje následující provozní požadavky: - oznámení a koordinace letu před odletem, pokud čas letu od startu do COP je nižší než čas, který by byl požadován ke splnění dohodnutých časových parametrů pro přenos zprávy ACT, - oznámení a koordinace letu před odletem místním stanovištěm (letištní řídící věží) na následující stanoviště, která převezme řízení letu, - zajištění sběru chybějících dat letového plánu v případě rozporů v prvotním rozdělení dat letového plánu, - žádost o přidělení kódu SSR od stanoviště, kterému je výše uvedené oznámení/koordinace zasláno, pokud je požadována. 7.2.2 Obsah zprávy Zpráva PAC musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (nepovinné), - identifikace letadla, - mód a kód SSR, - letiště vzletu, - předpokládaný čas vzletu nebo předběžná data, - letiště zamýšleného přistání, - typ letadla, - trať (nepovinné), - další data letového plánu (nepovinné). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 7.2.3 Pravidla používání 7.2.3.1 Obecná pravidla 7.2.3.1.1 Jedna nebo několik zpráv PAC musí být zasláno pro každý plánovaný let, který má překročit hranice prostoru odpovědnosti, pokud by čas od startu do COP neumožňoval zaslání zprávy ACT v požadovaném čase. 7.2.3.1.2 Jedna nebo několik zpráv PAC musí být zasláno letištní řídící věží/přibližovacím stanovištěm řízení (TWR/APP) následujícímu stanovišti pro každý vzlétající let, pro který je požadováno oznámení nebo koordinace. 7.2.3.1.3 Doporučení: Pro zavedení zpráv PAC LAM mezi stanovišti by měly být příslušné systémy TWR/ vybaveny prostředky pro zavádění a zasílání signálů "start-up" (start), "push-back", "taxi" (rolování) nebo podobných informací, ze kterých lze odvodit ETOT pro výpočet předpokládaného času přeletu COP a spuštění přenosu zprávy PAC. 7.2.3.1.4 Dle vzájemné dohody musí zpráva obsahovat buď: - předpokládaný čas vzletu, nebo - předběžná data. 7.2.3.1.5 Je-li dle vzájemné dohody uveden odkaz na zprávu, musí: - obsahovat číslo prvé zprávy PAC odeslané pro dotyčný let, - být uveden na druhé a následujících zprávách PAC. 7.2.3.1.6 Použití vyžádání kódu, je-li požadováno, musí být vzájemně dohodnuto. 7.2.3.1.7 Opravená zpráva PAC musí být zaslána, pokud před startem platí kterákoli z následujících podmínek: - trať letu byla změněna tak, že COP uvedený v předchozí zprávě již není přesný, - došlo ke změně typu letadla, - bylo zjištěno, že letiště zamýšleného přistání uvedené v předchozí zprávě PAC není správné. 7.2.3.1.8 Doporučení: Opravená zpráva PAC by měla být zaslána, pokud se před startem následující data liší od dat předchozí zprávy PAC: - letová hladina (v předběžných datech, pokud jsou použita), - předpokládaný kód SSR v bodu předání řízení, - předpokládaný čas vzletu nebo předpokládaný čas přeletu COP o časový interval přesahující vzájemně dohodnutou hodnotu, - dojde ke změně jakýchkoli dalších dat dle vzájemné dohody.. 7.2.3.2 Zpracování v přijímajícím stanovišti 7.2.3.2.1 Systém ATC zprávu PAC se musí pokusit o její přidružení odpovídajícímu letovému plánu. 7.2.3.2.2 Je-li odpovídající letový plán nalezen a zpráva neobsahuje žádný nesoulad, který by znemožňoval správné zpracování: - pracovní obsah musí být zahrnut do letového plánu, - požadovaná data musí být vyvedena na řízení letového provozu a další příslušná pracoviště, - musí být odeslána zpět zpráva LAM. 7.2.3.2.3 Nelze-li nalézt odpovídající letový plán, nebo je-li zjištěn nesoulad, který znemožňuje správné zpracování zprávy: - pokud sektor odpovědný za převzetí řízení letu lze určit: - pracovní obsah zprávy se zobrazí v dotyčném sektoru, - musí být odeslána zpět zpráva LAM, - musí být sestaven letový plán, - ve všech ostatních případech nesmí být odeslána zpráva LAM. 7.2.3.2.4 Data druhé nebo následující zprávy PAC nahradí data předchozí zprávy. 7.2.3.2.5 Pokud zpráva PAC zahrnuje žádost o přidělování kódů SSR a je bezchybně zpracovatelná, jak je popsáno v odstavci 7.2.3.2.2. výše, musí být kromě zprávy LAM zaslána zpět zpráva COD. POZNÁMKA: Vzhledem k tomu, že postup pro přidělování kódů vyžaduje podrobné údaje o trase letového plánu, neobsahuje tento dokument žádné požadavky pro zpětné zaslání zprávy COD přijímajícím stanoviště, které nemusí být tato data pro dotyčný let k dispozici. To nebrání zpětnému zaslání zprávy za těchto okolností, pokud existuje specifická místní způsobilost a postup byl vzájemně dohodnut. 7.2.3.3 Časové parametry pro přenos Časový parametr přenosu nelze použít, neboť zpráva se zasílá jako reakce na ručně zadanou zprávu, která oznamuje bezprostřední vzlet dotyčného letu. 7.2.4 Potvrzení zprávy PAC 7.2.4.1 Potvrzení Zprávy, které mají být odeslány jako odpověď na zprávu PAC jsou popsány v odstavci 7.2.3.2. výše. 7.2.4.2 Nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy PAC, zobrazí se výstraha na pracovišti stanoviště ATC odpovědném za koordinaci s následující jednotkou. 7.2.4.3 Případy nedoručení zprávy LAM Není-li doručena zpráva LAM, musí být zahájena ústní koordinace. 7.2.4.4 Nedoručení zprávy COD 7.2.4.4.1 Není-li přijata zpráva COD jako odpověď na žádost o kód obsaženou ve zprávě PAC, zobrazí se na příslušném pracovišti výstraha. 7.2.4.4.2 Má-li být použita funkce žádost o kód, musí být vzájemně dohodnut požadovaný časový parametr. 7.2.5 Příklady 7.2.5.1 Předpokládaný čas vzletu a žádost o kód 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 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 Zpráva o změně koordinačních dat (REV) 7.3.1 Účel zprávy REV Zpráva REV se používá na zasílání změn koordinačních dat dříve odeslaných ve zprávě ACT, pokud v důsledku změn nedojde ke změně přebírajícího stanoviště. 7.3.2 Obsah zprávy Zpráva REV musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (nepovinné), - identifikace letadla, - mód a kód SSR (nepovinné), - letiště vzletu, - předběžná data, - koordinační bod (nepovinné), - letiště zamýšleného přistání, - trať (nepovinné), - další data letového plánu (nepovinné). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 7.3.3 Pravidla používání 7.3.3.1 Obecná pravidla 7.3.3.1.1 Stanovišti, se kterým byl let aktuálně koordinován pomocí zprávy ACT, lze zaslat jednu nebo několik zpráv REV. 7.3.3.1.2 Následující prvky musí podléhat opravě: - předpokládaný čas přeletu COP, - letová hladina při předání, - kód SSR. 7.3.3.1.3 Zpráva REV musí být zaslána, pokud: - se předpokládaný čas přeletu COP liší od údaje předchozí zprávy o více než je vzájemně dohodnutá hodnota zaokrouhlená na nejbližší celé číslo, - dojde ke změně letové hladiny při předání nebo kódu SSR. 7.3.3.1.4 Je-li to vzájemně dohodnuto, musí být zpráva REV zaslána, pokud dojde ke změně kterékoli z následujících položek: - COP, - trať, - další data letového plánu (data polí ICAO 8, 10 a 18). POZNÁMKA: Operační pravidla mohou vyžadovat, aby změny provedené po zprávě ACT podléhaly předchozí koordinaci mezi dotyčnými stanovišti. 7.3.3.1.5 Je-li to vzájemně dohodnuto, musí zpráva REV obsahovat odkaz na zprávu, kterou mění. 7.3.3.1.6 Odkaz na zprávu, je-li uveden, musí obsahovat číslo předchozí zprávy ACT. 7.3.3.1.7 Podmínky předání uvedené ve zprávě REV přijímacím stanovištěm ATC se považují za přijaté, pokud přijímací stanoviště ATC nezahájí koordinaci za účelem změny těchto podmínek. 7.3.3.2 Formátování zprávy REV 7.3.3.2.1 Formát ICAO Veškeré změnové zprávy obsahují pole typů 3, 7, 13, 14 a 16. Uvedená pole umožňují následující typy změn: - změna předpokládaného času přeletu COP nebo letové hladiny předání musí být začleněna zadáním změněných dat do pole 14, - změna kódu SSR musí být zadána do pole 7, - změny trasy včetně změn COP musí být začleněny do dat polí 14 a 15 zahrnutých do formátu pole 22 po úvodních pěti polích. Takové zprávy musí obsahovat dvě pole 14, přičemž první obsahuje pouze prvek a), COP, přes který byl let dříve koordinován. Pravidla koordinace takových změn, včetně přímé tratě, jsou určena v příloze B, Požadavky na vytvoření speciálních tratí. - změny polí 8, 10 a 18 musí být zahrnuty do dat pole 22 po úvodních pěti polích. 7.3.3.2.2 Formát ADEXP Veškeré zprávy REV ve formátu ADEXP musí obsahovat následující primární pole TITLE REFDATA ARCID ADEP ADES. Uplatňují se následující pravidla: - změna předpokládaného času přelet COP nebo letové hladiny při předání musí být začleněna zadáním změněných dat do primárního pole COORDATA, - změny tratě, včetně změn COP musí být začleněny do hlavních polí COORDATA a ROUTE. Takové zprávy musí obsahovat primární pole COP, které obsahuje koordinační bod, přes který byl let dříve koordinován. Pravidla koordinace takových změn, včetně přímé tratě, jsou určena v příloze B, - změna kódu SSR musí být vyznačena zahrnutím primárního pole SSRCODE, - změny dalších dat letového plánu musí být začleněny zahrnutím nezbytných primárních polí, jak jsou definována pro další data letového plánu v příloze A. Je-li zpráva REV zaslána pouze za účelem koordinace kódu SSR a/nebo dalších dat letového plánu, primární pole COP musí být zahrnuto na místě pole COORDATA. 7.3.3.2.3 Kód SSR Mód a kód SSR musí být zahrnut do zprávy REV pouze pokud je to požadováno za účelem koordinace změny kódu SSR. 7.3.3.3 Zpracování v přijímajícím stanovišti 7.3.3.3.1 Byla-li pro dotyčný let přijata zpráva ACT ze stejného stanoviště ATC, systém ATC přijímající zprávu REV se musí pokusit o její přidružení odpovídajícímu letovému plánu. 7.3.3.3.2 Pokud je nalezen odpovídající letový plán a zpráva neobsahuje žádný nesoulad, který by znemožňoval správné zpracování: - pracovní obsah musí být zahrnut do letového plánu, - požadovaná data musí být vyvedena na operační ATC a další příslušná pracoviště. 7.3.3.4 Spuštění přenosu 7.3.3.4.1 Zpráva REV je vynucená událost a musí být odeslána neprodleně po příslušném vstupu nebo aktualizaci. 7.3.3.4.2 Poté, co let dosáhne určeného času/vzdálenosti od bodu předání, nelze provést žádné změny pomocí zprávy REV. Parametry času a vzdálenosti musí být vzájemně dohodnuty. 7.3.3.4.3 Doporučení: Parametry zprávy REV by měly být definovány samostatně pro každý COP. 7.3.3.5 Změna přijímajícího stanoviště ATC Zpráva REV se nepoužije, pokud oprava dat letového plánu vede ke změně přijímajícího stanoviště ATC (viz zpráva zrušení koordinace). 7.3.4 Potvrzení zprávy REV 7.3.4.1 Potvrzení Pokud zprávu REV: - lze přičlenit letovému plánu v rámci přijímajícího systému, musí být jako potvrzení odeslána zpráva LAM, - nelze přičlenit letovému plánu v rámci přijímajícího systému, zpráva LAM se neodesílá. 7.3.4.2 Nedoručení potvrzení 7.3.4.2.1 Není-li přijata zpráva LAM jako potvrzení zprávy REV, zobrazí se výstraha na pracovišti ATC odpovědném za koordinaci dotyčných letů. 7.3.4.2.2 Není-li doručena zpráva LAM, musí předávající stanoviště ATC zahájit ústní opravu. 7.3.5 Pří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 Zpráva zrušení koordinace (MAC) 7.4.1 Účel zprávy MAC Zpráva MAC se používá k oznámení přijímajícímu stanovišti, že koordinace nebo oznámení dříve vykonané pro určitý let se ruší. Zpráva MAC není náhradou zprávy o zrušení letového plánu (CNL), jak je definována ICAO, a proto se nepoužije k vymazání základních dat letového plánu. 7.4.2 Obsah zprávy Zpráva MAC musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (nepovinné), - identifikace letadla, - letiště vzletu, - COP, - letiště zamýšleného přistání, - stav a důvod koordinace (nepovinné). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 7.4.3 Pravidla používání 7.4.3.1 Obecná pravidla 7.4.3.1.1 Zpráva MAC musí být zaslána stanovišti, se kterým byla předtím provedena koordinace určitého letu pomocí zprávy ACT nebo RAP, pokud dojde k některé z následujících událostí: - předpokládaná letová hladina v bodě předání se liší od letové hladiny uvedené v předchozí zprávě, což vede ke změně následujícího stanoviště koordinační posloupnosti, - trať letu byla změněna, což vede ke změně následujícího stanoviště koordinační posloupnosti, - systémový letový plán je v odesílajícím stanovišti zrušen a koordinace není nadále aktuální, - pro dotyčný let je přijata zpráva MAC od předchozího stanoviště koordinační posloupnosti. 7.4.3.1.2 Je-li zpráva MAC odeslána z důvodu změny letové hladiny nebo tratě, musí být provedeno příslušné oznámení a/nebo koordinace s novým stanovištěm koordinační posloupnosti. 7.4.3.1.3 Zpráva MAC musí být odeslána, pokud je zrušena koordinace startujícího letu provedená pomocí zprávy PAC. 7.4.3.1.4 Doporučení: Zpráva MAC by měla být odeslána, pokud oznámení (zpráva ABI) předtím provedené pro určitý let, je zrušeno z jakéhokoli důvodu uvedeného v odstavci 7.4.3.1.1. výše nebo je-li let zpožděn na trati a změněný odhad nelze určit automaticky. 7.4.3.1.5 Je-li to vzájemně dohodnuto, musí být uveden odkaz na zprávu. 7.4.3.1.6 Odkaz na zprávu, je-li uveden, musí obsahovat číslo poslední zprávy ABI, PAC nebo ACT zaslané pro dotyčný let, jejíž příjem byl potvrzen. 7.4.3.1.7 Bod koordinace musí být ten COP, přes který byl let dříve oznámen nebo koordinován. 7.4.3.1.8 Doporučení: Zpráva MAC by měla uvádět stav, do kterého se má koordinace nebo oznámení vrátit, a důvod zrušení. 7.4.3.1.9 Je-li uveden stav a důvod, musí jít o jednu z následujících kombinací: - pokud přijímající stanoviště není nadále následujícím koordinačním partnerem: - stav je INI (initial — výchozí), - důvod je jeden z následujících: - TFL, je-li důvodem změna letové hladiny předání, - RTE, je-li důvodem změna trasy, - CSN, je-li důvodem změna volacího znaku (callsign), - CAN, je-li důvodem zrušení, - OTH, jde-li o libovolný jiný důvod nebo je-li důvod neznámý, - pokud se uplatní jedna z následujících podmínek: - koordinace vykonaná pomocí předchozí zprávy PAC nebo ACT (změněné jakoukoli následnou zprávou REV) je zrušena, ale předpokládá se, že let bude předmětem nové koordinační sekvence se stejným stanovištěm nebo - po přenosu zprávy ABI je let pozastaven na dobu neurčitou a předpokládá se, že bude předmětem změněné zprávy ABI nebo ACT, jak je příslušné: - stav je NTF (oznámení), - důvod je jeden z následujících: - DLY, je-li důvodem zpoždění, - HLD, je-li důvodem pozastavení, - OTH, jde-li o libovolný jiný důvod nebo je-li důvod neznámý. 7.4.3.1.10 Pokud má být let znovu oznámen nebo koordinován: - musí být dle vhodnosti odesláno nové oznámení a/nebo koordinační zpráva, - základní data letového plánu uložená v přijímajícím stanovišti ATC nesmí být ovlivněna zprávou MAC, - systém si musí podržet schopnost správně zpracovat nové oznámení a/nebo koordinační zprávu od předchozího předávajícího stanoviště nebo jiného stanoviště nové koordinační posloupnosti. 7.4.3.2 Zpracování v přijímajícím stanovišti Pracoviště přijímajícího stanoviště ATC, kterému/kterým byly poskytnuty podrobné údaje o letu, musí být upozorněno/upozorněna na zrušení. 7.4.4 Potvrzení zprávy MAC 7.4.4.1 Potvrzení 7.4.4.1.1 Pokud zprávu MAC lze přičlenit letovému plánu v rámci přijímajícího systému a lze ji zpracovat, musí být jako potvrzení odeslána zpráva LAM. 7.4.4.1.2 Pokud zprávu MAC nelze přičlenit letovému plánu v rámci přijímajícího systému nebo ji nelze zpracovat, zpráva LAM se neodesílá. 7.4.4.2 Nedoručení potvrzení 7.4.4.2.1 Pokud je koordinace ATC zrušena a není přijata zpráva LAM, zobrazí se výstraha na pracovišti ATC odpovědném za koordinaci. 7.4.4.2.2 V takových případech musí být předávajícím stanovištěm ATC provedeno ústní zrušení koordinace. 7.4.5 Příklady ACC v Amsterdamu zaslalo zprávu ABI ACC v Bruselu pro let HOZ3188 plánovaný na FL190, let následně žádá o výstup na FL270 (letovou hladinu 270), což je mu povoleno, takže vstoupí do vzdušného prostoru Maastrichtu namísto Bruselu. Příklady 7.4.5.1 a 7.4.5.2 ukazují, jak by vypadala zpráva MAC zaslaná do Bruselu z Amsterdamu, a to jak ve formátu ICAO, tak ve formátu ADEXP. Do Maastrichtu je zaslána zpráva ABI a později zpráva ACT, avšak několik minut před dosažením COP se letadlo vrací na letiště v Amsterdamu a letový plán je v systému odesílajícího stanoviště zrušen, do Maastrichtu je zaslána zpráva MAC, jak ji ukazují příklady (7.4.5.1b a 7.4.5.2b). 7.4.5.1 ICAO a) (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL) b) (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN) 7.4.5.2 ADEXP a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN 7.5 Zpráva o přidělení kódu SSR (COD) 7.5.1 Účel zprávy COD 7.5.1.1 Metoda přidělení kódu (ORCAM) dává letu možnost odpovídat na stejném kódu následným stanovištím v rámci zúčastněné oblasti. Není-li přidělování kódů provedeno centrálně, např. ACC, letiště mohou vyžadovat individuální přidělení souboru diskrétních kódů SSR. Taková přidělení jsou velkým plýtváním kódy. 7.5.1.2 Zpráva COD splňuje provozní požadavek vydání kódu módu A SSR pro určený let jedním stanovištěm letové provozní služby jiné, pokud je požadován. Nepovinná funkce umožňuje vydávající jednotce zahrnout trať letu, je-li to vzájemně dohodnuto. 7.5.2 Obsah zprávy Zpráva COD musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (nepovinné), - identifikace letadla, - mód a kód SSR, - letiště vzletu, - letiště zamýšleného přistání, - trať (nepovinné). POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 7.5.3 Pravidla používání 7.5.3.1 Obecná pravidla 7.5.3.1.1 Zpráva COD musí být generována a automaticky odeslána jako odpověď na žádost o přidělování kódů přijatou v rámci přijaté zprávy. 7.5.3.1.2 Uvedený kód SSR musí být kód přidělený dotyčnému letu. 7.5.3.1.3 Pokud diskrétní kód není k dispozici, musí být vložen kód schváleného využití, jak je určen v Navigačním plánu pro region EUR. 7.5.3.1.4 Je-li to vzájemně dohodnuto, musí být uveden odkaz na zprávu, který obsahuje číslo zprávy, na kterou je zpráva COD odpovědí. 7.5.3.1.5 Je-li to vzájemně dohodnuto, musí být uvedena trať. 7.5.3.1.6 Předpokládá se akceptace kódu SSR stanovištěm přijímajícím zprávu COD. 7.5.3.2 Zpracování v přijímajícím stanovišti 7.5.3.2.1 Není-li ve zprávě nesoulad, který by znemožňoval správné zpracování, musí být odeslána zpět zpráva LAM. 7.5.3.2.2 Pokud zprávu nelze přidružit letovému plánu nebo je zjištěn nesoulad, který znemožňuje správné zpracování zprávy, zpráva LAM se nezasílá. 7.5.3.2.3 Data trasy, pokud jsou uvedena, nesmí být důvodem, který zabrání zpětnému zaslání zprávy LAM, pokud nedojde k nedodržení požadovaného formátu, jak je uveden v příloze A. 7.5.3.3 Časové parametry přenosu Časový parametr přenosu není použitelný, neboť zpráva COD se odesílá v důsledku příjmu zprávy žádající přidělování kódů SSR. 7.5.4 Potvrzení zprávy COD 7.5.4.1 Potvrzení Příjem zprávy COD musí být potvrzen generováním a odesláním zprávy LAM. 7.5.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy COD, zobrazí se na příslušném pracovišti výstraha. 7.5.5 Pří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 Informativní zpráva (INF) 7.6.1 Účel zprávy INF 7.6.1.1 Zpráva INF se používá k poskytnutí údajů o určitých letech orgánům, které se přímo nepodílí na postupu koordinace mezi dvěma následnými stanovišti ATC na trati letu. 7.6.1.2 Zprávu INF lze po domluvě mezi řídícími letového provozu použít k poskytování kopií zpráv a sdělování dohodnutých podmínek koordinace takovým orgánům. K tomuto účelu mohou zprávy INF generovat systémy předávajících nebo přebírajících stanovišť. 7.6.1.3 Zprávu lze též použít k poskytnutí údajů týkajících se libovolného bodu trati letu některému orgánu. 7.6.1.4 Formát umožňuje přenos výchozích dat, opravu a zrušení. 7.6.2 Obsah zprávy Zpráva INF musí obsahovat následující položky dat ve formátu zprávy popsaném v tomto dokumentu: - typ zprávy, - číslo zprávy, - veškeré položky provozních dat obsažené v původní zprávě nebo výsledné koordinaci, která se kopíruje, - typ zprávy, na kterou se odkazuje. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 7.6.3 Pravidla používání 7.6.3.1 Typy zpráv Typ zprávy/typy zpráv, které mají být zprávou INF zkopírovány, se zakládá (zakládají) na požadavcích uživatelů a možnostech odesílajícího stanoviště. Typ zprávy/typy zpráv a pravidla použití se obvykle dohodnou vzájemně. 7.6.3.2 Příjemci Lze odeslat jednu nebo více zpráv INF pro týž let jednomu nebo více příjemcům. 7.6.3.3 Pracovní obsah Pracovní obsah zprávy INF musí být ve formátu jedné z existujících zpráv. 7.6.3.4 Doporučení: 1. Podmínky zaslané ve výchozí interaktivní zprávě (např. ACT RAP, REV, RRV) lze před dokončením dialogu změnit nebo odmítnout. Odesílající stanoviště by měly být schopny zaslání konečného znění dohodnutých podmínek koordinace. 2. Zpráva INF by měl být odeslána neprodleně nebo v čase vztaženém k času dosažení COP, který je vzájemně dohodnut s přijímajícím orgánem. 7.6.4 Potvrzení zprávy INF Doporučení: 1. Příjem zprávy INF lze potvrdit v závislosti na koordinačním partnerovi generováním a odesláním zprávy LAM. 2. Není-li přijata zpráva LAM jako potvrzení zprávy INF, měla by — v závislosti na vzájemné dohodě mezi dotyčnými stanovišti — být na příslušném pracovišti zobrazena výstraha. 7.6.5 Příklady Let s volacím znakem BAW011, B747 z EGLL do OMDB na FL290 (letové hladině 290), žádající o FL410, předpokládá Koksy (KOK) VOR v 1905, odpovídá na A5437, pokračuje přes UG1 a UB6. Londýn zasílá pro uvedený let zprávu ACT do Maastrichtu. Kopie je odeslána z Londýna na jednotku označenou IT. Dále jsou uvedeny příklady příslušné zprá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. DIALOGOVÝ POSTUP KOORDINACE 8.1 Celkový přehled 8.1.1 Úvod 8.1.1.1 Dialogový postup poskytuje možnosti pro komunikaci a dojednávání mezi řídícími letového provozu v koordinační fázi a pro komunikaci ve fázi předání. 8.1.1.2 Tento oddíl popisuje zprávy používané pro dialogový postup v koordinační fázi, ve které jsou podmínky předání plánovány. Zprávy pro fázi předání, ve které je předání letu dokončeno, jsou popsány v oddíle 9 — Dialogový postup předání spojení 8.1.1.3 Postupy těchto dvou fází nejsou vzájemně závislé, lze je provádět samostatně nebo společně. 8.1.1.4 Je zavedeno několik doplňkových zpráv a je podporována schopnost obou partnerů zahájit dialog. 8.1.1.5 Dialogový postup koordinace umožňuje rozpoznat: - předání, která jsou v souladu s koordinační dohodou (LoA) a která lze akceptovat automaticky, a - předání, která vyžadují doručení řídícímu letového provozu přijímajícího stanoviště k rozhodnutí o akceptaci. 8.1.1.6 Tento postup umožňuje také výklad koordinační dohody (LoA) mezi dvěma systémy, které mají být sledovány, a zjištění jakéhokoli nesouladu mezi nimi. 8.1.2 Filtr 8.1.2.1 Obecná pravidla 8.1.2.1.1 Dialogový postup koordinace vyžaduje, aby systémy rozpoznaly, zda jsou předání v souladu s koordinační dohodou (LoA) 8.1.2.1.2 Postup, který kontroluje tuto shodu, je v tomto dokumentu uváděn jako - dohodnuté COP, - přípustné (nebo nepřípustné) letové hladiny, které mohou být také přidruženy koordinačním bodům, - letiště vzletu, - letiště přistání, - dohodnuté přímé tratě, - meze času a/nebo vzdálenosti do COP po jejichž dosažení je jakákoli koordinační zpráva považována za nestandardní, - jakékoli další vzájemně dohodnuté podmínky. 8.1.2.1.3 Za účelem definování složitějších podmínek lze všechny položky tohoto seznamu kombinovat. 8.1.2.1.4 V rámci oddílu 8 tohoto dokumentu musí být pojem "standardní podmínky" vykládán ve smyslu "podmínky, které jsou v souladu s koordinační dohodou (LoA)" a pojem "nestandardní podmínky" jako "podmínky, které jsou v nesouladu s koordinační dohodou (LoA)". Není-li vzájemně dohodnuto jinak, musí zprávy odeslané předávajícím stanovištěm za účelem koordinace, o nichž je známo, že jsou standardní, používat odlišné typy zpráv než ty, jejichž podmínky jsou nestandardní. 8.1.2.2 Činnosti předávajícího stanoviště 8.1.2.2.1 Filtr předávajícího stanoviště musí přezkoumat podmínky předání, které mají být zaslány přebírajícímu stanovišti. 8.1.2.2.2 Doporučení: Pokud je zjištěno, že podmínky předání jsou nestandardní, měl by být na tuto skutečnost upozorněn předávající řídící letového provozu, aby provedl potvrzení nebo změnu. 8.1.2.3 Činnosti přebírajícího stanoviště 8.1.2.3.1 Veškeré zprávy ACT a REV musí být kontrolovány pomocí filtru. 8.1.2.3.2 Pokud kontrola ukáže, že přijaté podmínky předání jsou nestandardní, musí být postoupeny řídícímu letového provozu k rozhodnutí, v opačném případě jsou přijaty automaticky. 8.1.2.4 Synchronizace filtrů 8.1.2.4.1 Používání různých zpráv pro standardní a nestandardní podmínky předání umožňuje rozpoznat jakýkoli nesoulad mezi standardními podmínkami uloženými v systémech předávajících a přebírajících stanovišť. 8.1.2.4.2 Pokud přebírající stanoviště rozpozná nestandardní podmínky předání ve zprávě používané pouze za účelem koordinace standardních předání, projeví se nesoulad mezi oběma filtry. Takové rozpory by měly být za účelem účinného fungování dialogového postupu řešeny. 8.1.3 Pořadí zpráv 8.1.3.1 Obecná pravidla 8.1.3.1.1 Je nutné dodržovat určitá pravidla, aby se zajistilo, že koordinace je úplná dříve, než dojde k výměně jakýchkoli oprav nebo zpráv o předání spojení, a také, aby se zajistilo, že řídící letového provozu obou stanovišť nevypracovávají současně návrhy pro tentýž let. 8.1.3.1.2 V koordinovaném stavu, tj. po dokončení dialogu ACT nebo RAP odesláním LAM nebo ACP, může stanoviště ATC pouze vysílat zprávu REV nebo RRV nebo potvrdit příjem takové zprávy pro určitý let. 8.1.3.1.3 Zprávy CDN může vysílat pouze přebírající stanoviště. 8.1.3.1.4 Vysílat zprávy CDN a potvrzovat jejich příjem lze pouze: - jako součást dialogu zahájeného příjmem zprávy ACT nebo RAP nebo zprávy REV nebo RRV, nebo - je-li letový plán pro dotyčný let v koordinovaném stavu. 8.1.4 Souběžná výměna zpráv 8.1.4.1 Obecná pravidla 8.1.4.1.1 Stanoviště účastnící se výměny koordinačních zpráv nebo zpráv o předání pro určitý let nezahájí další výměnu koordinačních zpráv nebo zpráv o předání pro stejný let se stejnou jednotkou, dokud neobdrží zprávu LAM ACP nebo RJC, nebo dokud neuplynula časová prodleva. 8.1.4.1.2 Zpráva CDN se může křížit se zprávou REV, RRV nebo MAC pro stejný let odeslanou z předávajícího stanoviště. Takovou situaci lze rozpoznat v předávajícím stanovišti z toho, že zpráva CDN dorazí dříve než potvrzení pro odeslanou koordinační zprávu, a v přebírajícím stanovišti podle toho, že zpráva z předávajícího stanoviště dorazí dříve než potvrzení zprávy CDN. V takovém případě se příjem zprávy CDN nepotvrzuje a zpráva REV, RRV nebo MAC je zpracována. 8.1.5 Zpracování odmítnutí Zpráva RJC ukončí systémový dialog. Musí být zahájena nová systémová koordinace, která odráží telefonickou koordinaci, pokud je to použitelné. 8.1.6 Časový limit pro obdržení odpovědi 8.1.6.1 Obecná pravidla 8.1.6.1.1 Pro odpověď na zprávy, které jsou předávány řídícímu letového provozu, se musí u odesílajících a přijímajících středisek uplatnit mechanismus časového limitu. 8.1.6.1.2 Trvání těchto časových limitů musí být vzájemně dohodnuto. 8.1.6.1.3 Ukončení časového limitu u předávajícího stanoviště způsobí vygenerování výstrahy u předávajícího řídícího letového provozu, čímž je upozorněn na potřebu zahájit telefonickou koordinaci. 8.1.6.1.4 Doporučení: 1. Když hrozí vypršení časového limitu předávajícího stanoviště, měla by být zobrazena výstraha na pracovišti ATC přebírajícího stanoviště příslušného pro dotyčný let. 2. Výstraha by měla vzít v úvahu čas přenosu odpovědi. 8.1.6.1.5 Systémy musí být schopny zpracovat odpovědi přijaté po uplynutí časového limitu. 8.1.7 Provedení 8.1.7.1 Dialogový postup se týká dvou fází, jmenovitě koordinační fáze a fáze předání. Dialog v těchto dvou fázích používá různé zprávy a požadované časy transakcí jsou různé. Koordinační zprávy jsou určeny ve formátech ICAO a ADEXP, zprávy předání spojení pouze ve formátu ADEXP. 8.1.7.2 Minimální požadavky na HMI pro koordinační dialog se liší od požadavků na předávací dialog: - předávací dialog se týká především funkce výkonu řízení a vyžaduje rychlé a uživatelsky příjemné HMI, - koordinační dialog není natolik časově kritický a jeho požadavky na HMI jsou nižšího stupně. 8.1.7.3 Dialogový postup musí být proveden za použití jednoho z následujících alternativních scénářů: - dialogový postup koordinační fáze a jakékoli doplňkové zprávy dle vzájemné dohody (oddíly 7 a 8), - základní koordinační postup a dialogový postup fáze předání (oddíly 6, 7 a 9), - dialogový postup koordinační fáze a fáze předání a jakékoli doplňkové koordinační zprávy dle vzájemné dohody (oddíly 7, 8 a 9). Předběžná informační zpráva o přeletu hranice FIR musí být odeslána v rámci všech scénářů. 8.1.7.4 Scénář použitý pro provedení musí být vzájemně dohodnut. 8.2 Aktivační zpráva (ACT) 8.2.1 Účel zprávy ACT Účel zprávy ACT je popsán v odstavci 6.3.1. Při dialogovém postupu se zpráva ACT používá ke splnění uvedených požadavků za předpokladu, že podmínky předání pro uvedený let jsou standardní a že předávající řídící letového provozu nepožaduje postoupení letu přebírajícímu řídícímu k akceptaci. 8.2.2 Obsah zprávy Obsah zprávy ACT používané pro dialogový postup musí odpovídat popisu pro zprávu ACT uvedenému v odstavci 6.3.2. 8.2.3 Pravidla používání 8.2.3.1 Obecná pravidla 8.2.3.1.1 Pravidla používání odpovídají popisu pro zprávu ACT uvedenému v odstavci 6.3 s výjimkou zvláštních pravidel popsaných v tomto odstavci. 8.2.3.1.2 Zpráva ACT musí být zaslána pro let se standardními podmínkami přenosu, u kterých předávající řídící letového provozu nepožaduje, aby byly postoupeny přebírajícímu řídícímu. POZNÁMKA: Pokud tyto požadavky nejsou splněny, posílá se zpráva RAP viz odstavec 8.3, ¨zpráva navrhující nestandardní podmínky předání předložená přijímajícímu řídícímu. 8.2.3.1.3 Doporučení: Je-li jako odpověď na zprávu ACT zaslána zpět zpráva RJC, měl by být zahájen nový koordinační postup. 8.2.3.2 Zpracování v přijímacím stanovišti 8.2.3.2.1 Zpráva je zkontrolována pomocí filtru za účelem ujištění, že navrhované podmínky jsou standardní. 8.2.3.2.2 Zpráva musí být zpracována jako zpráva RAP, pokud: - je zjištěno, že podmínky přenosu jsou nestandardní, - nelze nalézt odpovídající systémový letový plán a dostupné údaje jsou nedostatečné k určení, zda jsou podmínky předání standardní. 8.2.3.2.3 Zpráva ACT určená jako standardní musí být zpracována v souladu s odstavcem 6.3.3.2. 8.2.3.2.4 Doporučení: Pokud je zjištěno, že podmínky předání ve zprávě jsou nestandardní, existuje nesoulad mezi filtry v dotyčných dvou systémech. Na skutečnost, že zpráva ACT je nestandardní, by měl být upozorněn personál dozoru, aby byl dotyčný nesoulad řešen. 8.2.4 Potvrzení zprávy ACT 8.2.4.1 Potvrzení 8.2.4.1.1 Při dialogovém postupu musí být příjem zprávy ACT potvrzen: - pomocí zprávy LAM, pokud jsou podmínky přenosu shledány standardními, - pomocí zprávy SBY ve všech ostatních případech. 8.2.4.1.2 Je-li přijata zpráva LAM, pracovní obsah zprávy ACT se musí stát provozně závazným pro obě stanoviště ATC. 8.2.4.1.3 Je-li tak vzájemně dohodnuto, může přebírající stanoviště použít k oznámení přijetí zprávy ACT obsahující standardní podmínky předání namísto zprávy LAM zprávu ACP. 8.2.4.2 Případy nedoručení potvrzení Není-li přijato potvrzení zprávy ACT, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.3 Zpráva navrhující nestandardní podmínky předání předložená přijímajícímu řídícímu (RAP) 8.3.1 Účel zprávy RAP Zpráva RAP splňuje kromě požadavků určených pro zprávu ACT v odstavci 6.3 následující provozní požadavky: - návrh předávajícího řídícího letového provozu a jeho doručení přebírajícímu řídícímu pro lety s nestandardními podmínkami předání, - umožňuje předávajícímu řídícímu letového provozu, pokud to vyžaduje, vynutit si doručení standardních podmínek předání pro určitý let přebírajícímu řídícímu. 8.3.2 Obsah zprávy Zpráva RAP musí obsahovat stejná data, jaká jsou popsána pro zprávu ACT v odstavci 6.3, a může nepovinně obsahovat následující datové prvky: - důvod vyznačení ručního doručení (k dispozici pouze ve formátu ADEXP). 8.3.3 Pravidla používání 8.3.3.1 Obecná pravidla 8.3.3.1.1 Zpráva RAP musí být zaslána namísto zprávy ACT pro lety překračující hranice při splnění jedné z následujících podmínek: - předávající systém určil, že podmínky předání jsou nestandardní, - předávající řídící letového provozu vyznačil, že navrhované podmínky předání mají být doručeny přebírajícímu řídícímu. 8.3.3.1.2 Pracovní obsah zprávy RAP, která má být odeslána, se před vlastním odesláním zobrazí na pracovišti příslušném pro koordinaci dotyčného letu. 8.3.3.1.3 Doporučení: Čas, kdy je zpráva RAP automaticky odeslána, by měl být zobrazen společně s jejím obsahem. 8.3.3.1.4 Příslušné pracoviště musí být upozorněno na přenos zprávy RAP. 8.3.3.2 Zpracování v přijímajícím stanovišti 8.3.3.2.1 Systém ATC přijímající zprávu RAP se musí pokusit o její přidružení odpovídajícímu letovému plánu. 8.3.3.2.2 Pokud je nalezen odpovídající letový plán a zpráva neobsahuje žádný nesoulad, který by znemožňoval správné zpracování: - pracovní obsah musí být doručen přebírajícímu řídícímu, - musí být zaslána zpět zpráva SBY. 8.3.3.2.3 Doporučení: Mělo by být provedeno také vyznačení důvodu doručení (nestandardní podmínky nebo ruční doručení). 8.3.3.2.4 Pokud zprávu nelze přidružit letovému plánu nebo je zjištěn nesoulad, který znemožňuje správné zpracování zprávy: - pracovní obsah zprávy se zobrazí v dotyčném sektoru a - musí být zaslána zpět zpráva SBY a - musí být sestaven letový plán. 8.3.3.2.5 Ve všech ostatních případech se příjem zprávy nepotvrzuje. 8.3.3.3 Ruční spuštění 8.3.3.3.1 Je-li použito k vynucení doručení navrhované koordinace se standardními podmínkami předání přebírajícímu řídícímu, spouští předávající řídící letového provozu zprávu RAP ručně a ta je odeslána neprodleně. 8.3.3.3.2 Doporučení: Ruční spuštění zprávy RAP před vypočteným časem přenosu by mělo být povoleno pracovišti příslušnému pro koordinaci dotyčného letu. 8.3.3.4 Časové parametry pro automatický přenos Čas/vzdálenost od hranice, ve které jsou zprávy RAP automaticky odesílány, musí být stejné jako pro zprávu ACT. 8.3.4 Potvrzení zprávy RAP 8.3.4.1 P o t v r z e n í Příjem zprávy musí být potvrzen generováním a přenosem zprávy SBY. 8.3.4.2 Nedoručení potvrzení Není-li přijata zpráva SBY jako potvrzení zprávy RAP, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.3.5 Operativní odpověď na zprávu RAP Přebírající řídící může podmínky předání přijmout, podat protinávrh nebo podmínky odmítnout. 8.3.5.1 Akceptace 8.3.5.1.1 Pokud se přebírající řídící rozhodne akceptovat navrhované podmínky předání, musí být zaslána zpět zpráva ACP. 8.3.5.1.2 Jakmile je přijata zpráva ACP, stanou se data zprávy RAP provozně závaznými pro obě stanoviště ATC. Koordinované podmínky předání a skutečnost, že byla přijata zpráva ACP, musí být předloženy předávajícímu řídícímu letového provozu 8.3.5.2 Protinávrh Pokud se přebírající řídící rozhodne podat protinávrh podmínek předání, musí být zaslána zpět zpráva CDN. 8.3.5.3 Doporučení: Pokud se přebírající řídící rozhodne odmítnout navrhované podmínky předání, měla by být zaslána zpět zpráva RJC. Poté by měl být zahájen nový koordinační postup. POZNÁMKA: Pokud jde o doporučení v bodě 8.3.5.3, ve většině případů dojde k nové koordinaci s jiným stanovištěm. 8.3.6 Pří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 Zpráva o změně koordinačních dat (REV) 8.4.1 Účel zprávy REV Účel zprávy REV je popsán v odstavci 7.3.1. V dialogovém postupu se zpráva REV používá ke splnění uvedených požadavků za předpokladu, že podmínky předání pro dotyčný let jsou standardní a předávající řídící letového provozu nepožaduje doručení letu přebírajícímu řídícímu k akceptaci. 8.4.2 Obsah zprávy Obsah zprávy REV musí odpovídat popisu pro zprávu REV v odstavci 7.3.2. 8.4.3 Pravidla používání 8.4.3.1 Obecná pravidla 8.4.3.1.1 Stanovišti, se kterým byl let aktuálně koordinován pomocí zpráv ACT nebo RAP, lze zaslat jednu nebo několik zpráv REV. 8.4.3.1.2 Zpráva REV musí být zaslána za podmínek určených v odstavci 7.3.3.1 pro lety se standardními podmínkami předání, u kterých předávající řídící letového provozu nepožaduje, aby byly předány přebírajícímu řídícímu. 8.4.3.2 Spuštění přenosu Zpráva REV musí být zaslána neprodleně po zjištění změny koordinačních dat, která vyžadují koordinaci, jak je popsáno v odstavci 7.3.3. 8.4.3.3 Zpracování v přijímajícím stanovišti 8.4.3.3.1 Pokud je nalezen odpovídající letový plán v koordinovaném stavu a není zjištěn žádný nesoulad, který by znemožňoval správné zpracování zprávy: - příjem zprávy REV musí být potvrzen, - ve všech ostatních případech se zpráva REV nepotvrzuje. 8.4.3.3.2 Podmínky předání musí být zkontrolovány, aby se zajistilo, že jsou standardní. 8.4.3.3.3 Pokud podmínky předání nejsou standardní, musí být předloženy přebírajícímu řídícímu. 8.4.3.3.4 Pokud jsou navrhované podmínky předání shledány standardními, musí být zahrnuty do letového plánu a požadovaná data předána ATC a dalším příslušným pracovištím. 8.4.3.3.5 Doporučení: Pokud se zjistí, že podmínky předání ve zprávě REV jsou nestandardní, existuje nesoulad mezi filtry dotyčných dvou systémů. Na skutečnost, že zpráva REV je nestandardní, by měl být upozorněn personál dozoru, aby byl uvedený nesoulad řešen. 8.4.4 Potvrzení zprávy REV 8.4.4.1 Potvrzení 8.4.4.1.1 Má-li být příjem zprávy REV potvrzen, musí se použít: - Zpráva LAM, pokud jsou podmínky předání shledány standardními, - zpráva SBY, pokud jsou podmínky předání shledány nestandardními. 8.4.4.1.2 Je-li přijata zpráva LAM, pracovní obsah zprávy REV se stává provozně závazným pro obě stanoviště ATC. 8.4.4.1.3 Je-li tak vzájemně dohodnuto, může přebírající stanoviště použít k oznámení přijetí zprávy REV obsahující standardní podmínky předání namísto zprávy LAM zprávu ACP. 8.4.4.2 Případy nedoručení potvrzení Není-li přijato potvrzení zprávy REV, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.4.5 Operativní odpověď na zprávu REV Vzhledem k tomu, že zpráva REV se používá k zaslání standardních podmínek předání, bude obvykle systémem přebírajícího stanoviště přijata. Pokud se pomocí filtru přebírajícího stanoviště zjistí, že podmínky předání jsou nestandardní, musí být zpráva zpracována jako zpráva RRV. 8.5 Zpráva o změně nestandardních koordinačních podmínek (RRV) 8.5.1 Účel zprávy RRV Zpráva RRV umožňuje změny dříve zaslaných a dohodnutých podmínek předání v následujících případech: - pokud změnou navrhované podmínky předání jsou nestandardní, - je-li navrhovaná změna standardní, ale předávající řídící letového provozu si přeje doručit změnu přebírajícímu řídícímu. 8.5.2 Obsah zprávy Obsah zprávy RRV musí odpovídat popisu pro zprávu REV odstavec 7.3.2) a může nepovinně zahrnovat následující datové prvky: - důvod vyznačení ručního doručení (k dispozici pouze ve formátu ADEXP). 8.5.3 Pravidla používání 8.5.3.1 Obecná pravidla Je nutné zaslat jednu nebo více zpráv RRV namísto zprávy REV pro každou změnu, pokud: - předávající systém určil, že podmínky předání jsou nestandardní, nebo - předávající řídící letového provozu vyznačil, že navrhované podmínky předání mají být doručeny přebírajícímu řídícímu. Toto použití zprávy RRV je nepovinné. 8.5.3.2 Spuštění přenosu Zpráva RRV musí být zaslána neprodleně po zjištění změny koordinačních dat nebo jakmile je spuštěna ručně. 8.5.3.3 Zpracování v přijímajícím stanovišti 8.5.3.3.1 Pokud je nalezen odpovídající letový plán v koordinovaném stavu a není zjištěn žádný nesoulad, který by znemožňoval správné zpracování zprávy: - musí být příjem zprávy RRV potvrzen, - ve všech ostatních případech se zpráva nepotvrzuje. 8.5.3.3.2 Navrhované podmínky předání se musí zobrazit na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.5.3.3.3 Doporučení: Mělo by být provedeno také vyznačení důvodu doručení (nestandardní podmínky nebo ruční doručení). 8.5.4 Potvrzení zprávy RRV 8.5.4.1 Potvrzení Příjem zprávy musí být potvrzen generováním a přenosem zprávy SBY. 8.5.4.2 Případy nedoručení potvrzení Není-li přijata zpráva SBY jako potvrzení zprávy RRV, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.5.5 Operativní odpověď zprávu RRV Přebírající řídící může zprávu RRV přijmout, podat protinávrh nebo zprávu odmítnout. 8.5.5.1 Akceptace Pokud se přebírající řídící rozhodne přijmout navrhovanou změnu dohodnutých podmínek předání, musí být zaslána zpět zpráva ACP 8.5.5.2 Protinávrh Pokud se přebírající řídící rozhodne podat protinávrh podmínek předání, musí být zaslána zpět zpráva CDN. 8.5.5.3 Odmítnutí Pokud se přebírající řídící rozhodne odmítnout navrhovanou změnu dohodnutých podmínek předání: - musí být zaslána zpět zpráva RJC a - musí být zahájen nový koordinační postup. Odmítnutí se předpokládá, není-li jako odpověď na zprávu RRV přijata zpráva ACP nebo CDN. 8.5.6 Pří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 Zpráva "vyčkejte" (SBY) 8.6.1 Účel zprávy SBY Zpráva SBY potvrzuje příjem zprávy navrhující podmínky předání a označuje, že se návrh předává řídícímu letového provozu k rozhodnutí. 8.6.2 Obsah zprávy Zpráva SBY musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 8.6.3 Pravidla používání 8.6.3.1 Obecná pravidla Zpráva SBY musí být neprodleně generována a automaticky odeslána jako odpověď na: - zprávy RAP, RRV nebo CDN, - zprávu ACT nebo REV, která je vyřazena filtrem. 8.6.4 Potvrzení zprávy SBY Zpráva SBY se nepotvrzuje. 8.6.5 Pří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 Akceptační zpráva (ACP) 8.7.1 Účel zprávy ACP Zpráva ACP splňuje následující provozní požadavky během fází koordinace a předání ATC: - oznamuje ruční akceptaci řídícího letového provozu jednoho stanoviště podmínek předání navrhovaných řídícím letového provozu druhého stanoviště pro jednu z následujících zpráv: - RAP, - RRV, - CDN, - ACT a REV, pokud jsou jejich podmínky shledány nestandardními, - je-li to vzájemně dohodnuto, poskytuje automatickou akceptaci zpráva ACT nebo REV, která úspěšně prošla filtrem přebírajícího stanoviště namísto zprávy LAM, - je-li to vzájemně dohodnuto, oznamuje ruční akceptaci zprávy HOP (namísto zprávy ROF). 8.7.2 Obsah zprávy Zpráva ACP musí sestávat z následujících datových položek: - Povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu, - nepovinná data — zpráva může zahrnovat také: - kmitočet, - nepovinná data zprávy formátu ICAO — zpráva může obsahovat také všechny následující položky: - identifikace letadla, - letiště vzletu, - letiště zamýšleného přistání. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 8.7.3 Pravidla používání 8.7.3.1 Obecná pravidla 8.7.3.1.1 Odkaz na zprávu ve zprávě ACP musí uvádět číslo zprávy, na kterou zpráva ACP odpovídá. 8.7.3.1.2 Pole "kmitočet", pokud se uvádí, musí obsahovat kmitočet, na kterém má let navázat spojení s přebírajícím stanovištěm během provádění předání. 8.7.3.1.3 Zpráva ACP musí být odeslána po ruční akceptaci navrhovaných podmínek předání řídícím letového provozu a předchází jí zprávy ACT RAP, REV, RRV nebo CDN. 8.7.3.1.4 Zprávu ACP lze zaslat jako alternativu zprávy ROF jako odpověď na zprávu HOP. 8.7.3.1.5 Je-li to vzájemně dohodnuto, musí být zpráva ACP generována a automaticky odeslána systémem jako odpověď na zprávu ACT nebo REV, která úspěšně prošla filtrem. 8.7.3.1.6 Jakmile byla přijata zpráva ACP, dohodnuté podmínky předání se stávají závaznými pro obě stanoviště. 8.7.3.2 Zpracování v přijímajícím stanovišti 8.7.3.2.1 Systém ATC přijímající zprávu ACP se musí pokusit o její přidružení odpovídajícímu letovému plánu. 8.7.3.2.2 Pokud lze zprávu ACP přidružit letovému plánu, musí být akceptace oznámena řídícímu letového provozu. 8.7.3.2.3 Pokud zprávu ACP nelze přidružit letovému plánu: - musí být spuštěna výstraha na příslušném pracovišti a - neodesílá se zpráva LAM. 8.7.4 Potvrzení zprávy ACP 8.7.4.1 Potvrzení 8.7.4.1.1 Pokud se zpráva ACP používá jako automatická odpověď na zprávu ACT nebo REV, která úspěšně prošla filtrem, neposílá se zpět zpráva LAM. 8.7.4.1.2 Příjem zprávy ACP zaslané v důsledku ruční akceptace musí být potvrzen generováním a odesláním zprávy LAM. 8.7.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy ACP zaslané v důsledku ruční akceptace, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.7.5 Příklady 8.7.5.1 ICAO (ACPL/E027E/L002-18/FRQ/242150) 8.7.5.2 ADEXP -TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -FREQ 242150 8.8 Koordinační zpráva (CDN) 8.8.1 Účel zprávy CDN Zpráva CDN splňuje následující provozní požadavky: - doručit protinávrh přebírajícího řídícího předávajícímu řídícímu letového provozu jako odpověď na zprávu ACT, RAP, REV nebo RRV, - zahájit změnu dohodnutých podmínek předání navrhovanou přebírajícím řídícím předávajícímu řídícímu letového provozu. 8.8.2 Obsah zprávy Zpráva CDN musí sestávat z následujících datových položek: - Povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu (pouze jde-li o odpověď na předchozí zprávu), - identifikace letadla, - letiště vzletu, - letiště zamýšleného přistání. POZNÁMKA: Zpráva musí obsahovat také jednu — nebo obě — následující položky: - předběžná data (jde-li o zprávu ICAO) nebo letovou hladinu při předání jde-li o zprávu ADEXP), - žádost o přímou trať, - vzájemně dohodnutá data — lze také uvést následující data, pokud to bylo vzájemně dohodnuto: - kmitočet. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 8.8.3 Pravidla používání 8.8.3.1 Obecná pravidla 8.8.3.1.1 Zprávy CDN může spustit pouze přebírající řídící. 8.8.3.1.2 Tuto zprávu je nutné použít k zaslání protinávrhu přebírajícího řídícího předávajícímu řídícímu letového provozu. POZNÁMKA: Může to být v rámci dialogu jako odpověď na návrh zprávou ACT RAP, REV nebo RRV, nebo jako počátek dialogu za účelem změny dříve dohodnutých podmínek předání. 8.8.3.1.3 Odkaz na zprávu se zadává pouze tehdy, pokud je zpráva CDN odpovědí na jinou zprávu. 8.8.3.1.4 Je-li uveden, musí odkaz na zprávu obsahovat číslo zprávy, na kterou je zpráva CDN odpovědí. 8.8.3.1.5 Služba - se použije pouze, pokud je vzájemně dohodnuta, - a je-li dohodnuta, je nutné definovat veškeré provozní meze jejího použití. 8.8.3.1.6 Zpráva CDN se neposílá po dosažení času/vzdálenosti od hranice, jejichž hodnoty jsou určeny v koordinační dohodě (LoA) mezi dotyčnými stanovišti. 8.8.3.1.7 V případě, že se zpráva CDN vysílá de facto zároveň se zprávou pro tentýž let od předávajícího stanoviště např. s opravou nebo se zrušením koordinace, nemusí být zasláno zpět potvrzení ani operativní odpověď. POZNÁMKA: Následkem výše uvedeného je, že pokud se dvě zprávy kříží, má zpráva od předávajícího stanoviště přednost a zpráva CDN je oběma stanovišti ignorována. Obě stanoviště si mohou danou situaci uvědomit po příjmu zprávy druhé strany před odesláním potvrzení. 8.8.3.1.8 Jakmile byla přijata akceptace, stávají se data zprávy CDN provozně závaznými pro obě stanoviště ATC. S koordinovanými podmínkami předání a se skutečností, že byla přijata zpráva ACP, musí být seznámeni příslušní pracovníci ATC předávající stanoviště. 8.8.3.2 Zpracování v přijímajícím stanovišti 8.8.3.2.1 Pokud je nalezen odpovídající letový plán a zpráva neobsahuje žádný nesoulad, který by znemožňoval správné zpracování: - pracovní obsah se zobrazí na stanovišti řízení letového provozu ATC odpovědném za koordinaci dotyčného letu a - musí být zaslána zpět zpráva SBY. 8.8.3.2.2 Pokud zprávu CDN nelze přidružit letovému plánu, nebo je zjištěn nesoulad, který znemožňuje správné zpracování zprávy, zpráva SBY se nezasílá. 8.8.4 Potvrzení zprávy CDN 8.8.4.1 Potvrzení Za podmínek určených výše musí být příjem zprávy CDN potvrzen generováním a přenosem zprávy SBY. 8.8.4.2 Případy nedoručení potvrzení Není-li přijata zpráva SBY jako potvrzení zprávy CDN, zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.8.5 Operativní odpověď na zprávu CDN Řídící letového provozu může akceptovat nebo odmítnout podmínky předání navrhované zprávou CDN. 8.8.5.1 Akceptace Pokud se předávající řídící letového provozu rozhodne akceptovat navrhované podmínky předání, musí být zaslána zpět zpráva ACP. 8.8.5.2 Doporučení: Pokud se předávající řídící letového provozu rozhodne odmítnout navrhované podmínky předání, měla by být zaslána zpět zpráva RJC. POZNÁMKA: Navrhovaná koordinace je implicitně odmítnuta, pokud nebyla do ukončení časového limitu zprávy CDN přijata akceptace. 8.8.6 Příklady 8.8.6.1 ICAO (CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -EBBR) 8.8.6.2 ADEXP -TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -PROPFL -TFL F270 -SFL F110A 8.9 Zpráva o odmítnutí koordinačních dat (RJC) 8.9.1 Účel zprávy RJC Zpráva RJC oznamuje odmítnutí podmínek předání navrhovaných řídícím letového provozu jednoho stanoviště v jedné z následujících zpráv řídícímu letového provozu druhého stanoviště: - RAP, - RRV, - CDN, - ACT a REV, pokud jsou jejich podmínky shledány nestandardními. Zprávu RJC lze použít pouze jako přímou odpověď na některou z výše uvedených zpráv. 8.9.2 Obsah zprávy Zpráva RJC musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - odkaz na zprávu. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 8.9.3 Pravidla používání 8.9.3.1 Obecná pravidla 8.9.3.1.1 Zpráva RJC musí být zaslána dle potřeby jako odpověď na zprávu RAP, RRV, CDN nebo na zprávu ACT nebo REV, která je přebírajícím stanovištěm určena jako nestandardní. 8.9.3.1.2 Zpráva RJC ukončuje systémový dialog a jakákoli dříve dohodnutá koordinace zůstává platná. 8.9.3.1.3 Doporučení: Po příjmu zprávy RJC by měla být zahájena nová koordinační sekvence zohledňující telefonickou koordinaci, kde je to použitelné. 8.9.3.2 Zpracování v přijímajícím stanovišti 8.9.3.2.1 Pokud je nalezena odpovídající zpráva, na kterou zpráva RJC odkazuje: - musí být odmítnutí vyznačeno na pracovišti ATC příslušném pro koordinaci dotyčného letu a - musí být odeslána zpět zpráva LAM jako potvrzení 8.9.3.2.2 Není-li nalezena žádná taková zpráva vyžadující odpověď, nebo zpráva obsahuje nesoulad, který brání jejímu zpracování, nezasílá se zpět žádné potvrzení. 8.9.4 Potvrzení zprávy RJC 8.9.4.1 Potvrzení Příjem zprávy RJC musí být potvrzen generováním a přenosem zprávy LAM. 8.9.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy RJC zobrazí se výstraha na pracovišti ATC příslušném pro koordinaci dotyčného letu. 8.9.5 Příklady 8.9.5.1 ICAO (RJCMC/E746E/MC324) 8.9.5.2 ADEXP -TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E -SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC MC -SEQNUM 324 9. DIALOGOVÝ POSTUP PŘEDÁNÍ SPOJENÍ 9.1 Celkový přehled 9.1.1 Úvod 9.1.1.1 Tento oddíl normy popisuje služby a zprávy, které podporují postup předání řízení z hlediska předání radarového řízení. Musí být zavedeny, pokud je tak vzájemně dohodnuto. 9.1.1.2 Prostředky pro předání spojení se neprovádí, pokud stanoviště nepoužívá buď koordinační služby popsané v oddíle 6 (Základní postup — povinné zprávy) nebo v oddíle 8 (Dialogový postup koordinace). 9.1.1.3 Zprávy popsané v tomto oddíle dokumentu jsou dostupné pouze ve formátu ADEXP a není plánováno zpřístupnit je ve formátu ICAO. 9.1.2 Pořadí zpráv 9.1.2.1 Výměna zpráv předání spojení kromě Zprávy doplňku letových dat (SDM) neprobíhá, pokud koordinace není dokončena, tj. pokud byl dokončen dialog ACT nebo RAP pomocí LAM nebo ACP. 9.1.2.2 Potvrzení nejsou zasílána zpět, dokud není koordinace dokončena. 9.1.3 Předání spojení 9.1.3.1 Metoda oznámení vlastní změny komunikace letů musí být vzájemně dohodnuta mezi příslušnými dvěma stanovišti. 9.1.3.2 Musí být dodržena jedna nebo obě následující podmínky: - předávající stanoviště posílá Zprávu o změně kmitočtu (COF), - přebírající stanoviště posílá zprávu Manuální převzetí spojení a řízení (MAS). 9.1.3.3 Metoda musí být dohodnuta mezi příslušnými dvěma stanovišti pro každý tok letového provozu. POZNÁMKA: Lze použít alternativní metody pro různé toky letového provozu, např. jedno stanoviště může generovat zprávu COF pro lety opouštějící její vzdušný prostor a zprávy MAS pro lety vstupující do jejího vzdušného prostoru. V takovém případě by nebylo nutné, aby druhé stanoviště zadávalo jakékoli zprávy oznamující předání spojení. 9.2 Zpráva zahájení předání (TIM) 9.2.1 Účel zprávy TIM Účelem zprávy TIM je: - oznámit zahájení předání (TI) (tj. konec koordinační fáze a začátek fáze předání), - současně doručit data operativního řízení z předávajícího do přebírajícího stanoviště. 9.2.2 Obsah zprávy Zpráva TIM musí sestávat z následujících datových položek: - povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - dostupná data — zpráva musí též obsahovat veškeré následující položky, pokud jsou dostupné: - povolená letová hladina, - stanovený kurz nebo povolení přímé trati, - stanovená rychlost, - stanovená rychlost stoupání/klesání, - nepovinná data — zpráva může též obsahovat položku: - poloha. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.2.3 Pravidla používání 9.2.3.1 Obecná pravidla 9.2.3.1.1 Zpráva TIM musí být předávajícím stanovištěm generována a odeslána přebírajícímu stanovišti bez lidského zásahu ve vzájemně dohodnutém čase/vzdálenosti letu od hranice. 9.2.3.1.2 Zpráva TIM musí být též odeslána automaticky, pokud byla předávajícím stanovištěm přijata Zpráva žádosti o předání na spojení (ROF). 9.2.3.1.3 Zpráva TIM se neposílá, dokud není dotyčný let v koordinovaném stavu. 9.2.3.1.4 Zpráva TIM musí obsahovat nejaktuálnější v systému dostupná data. 9.2.3.2 Časové parametry přenosu 9.2.3.2.1 Parametr generování zprávy TIM musí být proměnný systémový parametr, který lze změnit na základě ustanovení koordinační dohody (LoA) 9.2.3.2.2 Doporučení: Systémový parametr generování zprávy TIM by měl být definován samostatně pro každý z COP. 9.2.3.2.3 Koordinační partneři musí zahrnout parametry generování zprávy TIM do vzájemné koordinační dohody (LoA). 9.2.3.2.4 Systémový parametr spouštějící zprávu TIM může být vztažen k vypočtené traťové rychlosti letadla. Spuštění zprávy TIM musí však vždy začít dříve, než aktuální poloha letového plánu k COP klesne pod vzájemně určenou nejnižší vzdálenost. 9.2.3.2.5 Určený systémový parametr pro přenos zprávy TIM musí poskytovat dostatečný čas pro ústní koordinaci před předáním. 9.2.3.3 Zpracování v přijímajícím stanovišti 9.2.3.3.1 Data přijatá ve zprávě TIM musí být zpřístupněna přebírajícímu řídícímu. 9.2.4 Potvrzení zprávy TIM 9.2.4.1 Potvrzení Pokud zprávu TIM: - lze jednoznačně přidružit letovému plánu, musí být její příjem potvrzen generováním a odesláním zprávy LAM, - nelze jednoznačně přidružit letovému plánu, potvrzení se neposílá. 9.2.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy TIM, zobrazí se na příslušném pracovišti výstraha. 9.2.5 Příklad -TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253 9.3 Zpráva doplňku letových dat (SDM) 9.3.1 Účel zprávy SDM 9.3.1.1 Obecná pravidla 9.3.1.1.1 Hlavním účelem zprávy SDM je zasílání dat k řízení a jejich změn předávajícím stanovištěm přebírajícímu stanovišti za předpokladu, že bylo vzájemně dohodnuto, že změny nemusí být potvrzeny přebírajícím řídícím. 9.3.1.1.2 Zprávu SDM může přebírající stanoviště též použít k oznámení radiotelefonního kmitočtu, na který má být let převeden, předávajícímu stanovišti. 9.3.2 Obsah zprávy 9.3.2.1 Zprávy od předávajícího stanoviště Zpráva SDM musí sestávat z následujících datových položek: - povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - doplňující data — zpráva musí též obsahovat jednu nebo několik následujících položek: - stanovený kurz nebo Povolení přímé trati, - stanovená rychlost, - stanovená rychlost stoupání/klesání, - povolená letová hladina. 9.3.2.2 Zprávy od přebírajícího stanoviště Zpráva SDM musí obsahovat následující data: - typ zprávy, - číslo zprávy, - identifikace letadla, - kmitočet. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.3.3 Pravidla používání 9.3.3.1 Zprávy od předávajícího stanoviště 9.3.3.1.1 Zprávy SDM musí být vysílány po zahájení fáze předání (viz TIM, odstavec 9.2) po jakékoli změně následujících položek: - povolená letová hladina, - stanovená rychlost, - stanovená rychlost stoupání/klesání, - stanovený kurz nebo - vydání nebo změna povolení pro daný let pokračovat přímo do určeného bodu. POZNÁMKA: Je-li před předáním spojení požadováno schválení přebírajícího řídícího, je nutné použít zprávu Návrh na předání (HOP). 9.3.3.1.2 Zpráva musí obsahovat pouze ta pole, ve kterých došlo ke změně. 9.3.3.1.3 Je-li to vzájemně dohodnuto, musí být zprávy SDM obsahující data popsaná v odstavci 9.3.3.1.1 vysílány před zahájením předání (TI). 9.3.3.1.4 Takové zprávy musí začít ve vzájemně dohodnutém čase vztaženém k zahájení předání (TI) za předpokladu, že existují data, pro která je v systému dostupná hodnota. 9.3.3.2 Zprávy od přebírajícího stanoviště 9.3.3.2.1 Zprávy SDM mohou být vysílány za účelem oznámení kmitočtu, na kterém má let navázat spojení s přebírajícím stanovištěm. POZNÁMKA: Stanoviště se mohou vzájemně dohodnout na zasílání dalších údajů. Takové přenosy nejsou v této normě definovány a nejsou tedy ani její součástí. 9.3.3.2.2 Je-li to vzájemně dohodnuto, musí být zprávy SDM vysílány přebírajícím stanovištěm během koordinační fáze. 9.3.3.3 Zpracování v přijímajícím stanovišti 9.3.3.3.1 Systém ATC přijímající zprávu SDM se musí pokusit o její přidružení odpovídajícímu letovému plánu. 9.3.3.3.2 Je-li nalezen odpovídající letový plán v koordinovaném stavu: - musí být odeslána zpět zpráva LAM a - pracovní obsah zprávy SDM musí být zpřístupněn příslušnému řídícímu letového provozu. 9.3.3.3.3 Nelze-li nalézt odpovídající letový plán, nebo je zjištěn nesoulad, který znemožňuje správné zpracování zprávy: - zpráva LAM se neodesílá a - na příslušném pracovišti se zobrazí výstraha 9.3.4 Potvrzení zprávy SDM 9.3.4.1 Potvrzení Příjem zprávy SDM musí být potvrzen generováním a odesláním zprávy LAM. 9.3.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy SDM, zobrazí se na příslušném pracovišti výstraha. 9.3.5 Příklad -TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290 9.4 Návrh na předání (HOP) 9.4.1 Účel zprávy HOP Účelem zprávy HOP je: - aby předávající řídící letového provozu upozornil přebírajícího řídící ho na určitý let pro účely předání, - aby předávající řídící letového provozu navrhl let pro předání přebírajícímu řídícímu, pokud je to požadováno, - aby byly zaslány změny dat operativního řízení, které podle vzájemné dohody vyžadují schválení přebírajícím řídícím. Zprávu HOP není nutné používat pro všechny lety, používá se dle vlastního uvážení předávajícího řídícího letového provozu. POZNÁMKA: Podle třetí odrážky výše se k zaslání změn dat operativního řízení, které nevyžadují schválení přebírajícího řídícího používá zpráva SDM. 9.4.2 Obsah zprávy Zpráva HOP musí sestávat z následujících datových položek: - povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - dostupná data — zpráva musí též obsahovat veškeré následující položky, pokud jsou dostupné: - povolená letová hladina, - stanovený kurz, Povolení přímé trati, - stanovená rychlost, - stanovená rychlost stoupání/klesání, - nepovinná data — zpráva může též obsahovat položku: - poloha. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.4.3 Pravidla používání 9.4.3.1 Obecná pravidla 9.4.3.1.1 Zprávu HOP, pokud je používána, musí ručně spustit předávající řídící letového provozu. 9.4.3.1.2 Zpráva musí obsahovat jakákoli letová data popsaná v odstavci 9.4.2 výše, která se změnila oproti datům dříve odeslaným. 9.4.3.1.3 Je-li zpráva HOP odeslána před zahájením předání (TI), je jí zahájena fáze předání. POZNÁMKA: Zpráva zahájení předání (TIM) není při použití zprávy HOP požadována. 9.4.3.1.4 Nejkratší čas nebo vzdálenost před COP nebo hranicí, ve kterém lze zaslat zprávu HOP, musí být vzájemně dohodnuty. 9.4.3.1.5 Doporučení: Uvedený čas a/nebo vzdálenost by měly být určeny samostatně pro každý COP. 9.4.3.2 Zpracování v přijímajícím stanovišti 9.4.3.2.1 Systém ATC přijímající zprávu HOP se musí pokusit o její přidružení odpovídajícímu letovému plánu. 9.4.3.2.2 Letová data přijatá ve zprávě musí být neprodleně zobrazena přebírajícímu řídícímu. 9.4.3.2.3 Pokud přebírající řídící akceptuje let za podmínek navrhovaných ve zprávě HOP, lze předávajícímu stanovišti zaslat jako odpověď zprávu ROF. Je-li to vzájemně dohodnuto, lze zaslat jako odpověď na zprávu HOP zprávu ACP. 9.4.3.2.4 Pokud přebírající řídící nemůže let akceptovat, musí být předání dohodnuto ústně. POZNÁMKA: Vzhledem k naléhavosti postupu předání nepožaduje tato norma systémovou podporu sledování zpětného zaslání zprávy ROF (nebo ACP), předpokládá se, že si předávající řídící letového provozu bude dobře vědom nedoručení odpovědi od přebírajícího řídícího a provede činnosti dle potřeby. Tato norma však nebrání poskytování výstrahy předávajícímu řídícímu letového provozu, je-li to považováno za provozně nezbytné. 9.4.3.2.5 Jakmile je přijata zpráva ROF (nebo ACP), data zprávy HOP se stávají provozně závaznými pro obě stanoviště ATC. 9.4.4 Potvrzení zprávy HOP 9.4.4.1 Potvrzení Pokud lze zprávu HOP přidružit letovému plánu, musí být její příjem potvrzen automaticky pomocí zprávy LAM 9.4.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy HOP, zobrazí se na příslušném pracovišti výstraha. 9.4.5 Příklad -TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ 9.5 Zpráva žádosti o předání na spojení (ROF) 9.5.1 Účel zprávy ROF Zprávu ROF zasílá přebírající stanoviště v případě potřeby jako žádost předávajícímu řídícímu letového provozu, aby dal letadlu pokyn k přechodu na kmitočet přebírajícího řídícího. Zprávu lze použít: - jako odpověď na zprávu HOP k oznámení akceptace letu za navrhovaných podmínek, - k žádosti o předčasné předání letu. 9.5.2 Obsah zprávy Zpráva ROF musí sestávat z následujících datových položek: - povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - nepovinná data — zpráva může též obsahovat: - kmitočet. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.5.3 Pravidla používání 9.5.3.1 Obecná pravidla 9.5.3.1.1 Zprávu ROF musí ručně spustit přebírající řídící. 9.5.3.1.2 Přebírající řídící může spustit zprávu ROF - když vyžaduje předčasné předání letadla na kmitočet nebo - jako odpověď na zprávu HOP. 9.5.3.2 Zpracování v přijímajícím stanovišti 9.5.3.2.1 Systém ATC přijímající zprávu ROF se musí pokusit o její přidružení odpovídajícímu letovému plánu. 9.5.3.2.2 Příjem zprávy ROF musí být bezodkladně oznámen předávajícímu řídícímu letového provozu. 9.5.3.2.3 Pokud let není ve fázi předání, musí být zahájena fáze předání a odeslána zpráva TIM. 9.5.4 Potvrzení zprávy ROF 9.5.4.1 Potvrzení 9.5.4.1.1 Pokud lze zprávu ROF jednoznačně přidružit letovému plánu, musí být její příjem potvrzen generováním a odesláním zprávy LAM. 9.5.4.1.2 Pokud zprávu ROF nelze jednoznačně přidružit letovému plánu, potvrzení se neposílá. 9.5.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy ROF, zobrazí se výstraha na příslušném stanovišti řízení letového provozu ATC. 9.5.5 Příklad -TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.6 Zpráva o změně kmitočtu (COF) 9.6.1 Účel zprávy COF 9.6.1.1 Obecná pravidla 9.6.1.1.1 Zprávu COF zasílá předávající stanoviště přebírajícímu stanovišti aby oznámilo, že let dostal pokyny k navázání spojení s přebírajícím řídícím. 9.6.1.1.2 Zpráva může zahrnovat možnost pro předávajícího řídícího letového provozu zprostit let dohodnutých podmínek předání, poté co navázal rádiové spojení s přebírajícím řídícím. 9.6.2 Obsah zprávy Zpráva COF musí sestávat z následujících datových položek: - povinná data — zpráva musí obsahovat položky: - typ zprávy, - číslo zprávy, - identifikace letadla, - dostupná data — zpráva musí též obsahovat veškeré následující položky, pokud jsou dostupné: - oznámení povolení, - kmitočet, - povolená letová hladina, - stanovený kurz nebo Povolení přímé trati, - stanovená rychlost, - stanovená rychlost stoupání/klesání. - nepovinná data — zpráva může též obsahovat položku: - poloha. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.6.3 Pravidla používání 9.6.3.1 Obecná pravidla 9.6.3.1.1 Zprávu COF musí ručně spustit předávající řídící letového provozu. 9.6.3.1.2 Používání zprávy COF je povinné, pokud se na základě vzájemné dohody nepoužívá zpráva MAS. 9.6.3.1.3 Je-li zpráva COF zaslána před zahájením předání (TI), musí být zahájena fáze předání. POZNÁMKA: Zpráva zahájení předání (TIM) není při použití zprávy COF požadována. 9.6.3.2 Zpracování v přijímajícím stanovišti 9.6.3.2.1 Systém ATC přijímající zprávu COF se musí pokusit o její přidružení odpovídajícímu letovému plánu. 9.6.3.2.2 Příjem zprávy COF musí být bezodkladně oznámen přebírajícímu řídícímu. 9.6.4 Potvrzení zprávy COF 9.6.4.1 Potvrzení 9.6.4.1.1 Pokud lze zprávu COF jednoznačně přidružit letovému plánu, musí být její příjem potvrzen generováním a odesláním zprávy LAM. 9.6.4.1.2 Pokud zprávu COF nelze jednoznačně přidružit letovému plánu, potvrzení se neposílá. 9.6.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy COF, zobrazí se výstraha na příslušném pracovišti ATC. 9.6.5 Příklady -TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.7 Manuální převzetí spojení a řízení (MAS) 9.7.1 Účel zprávy MAS Zprávu (MAS) zasílá přebírající stanoviště předávajícímu stanovišti jako oznámení, že s letem bylo navázáno obousměrné rádiové spojení. 9.7.2 Obsah zprávy Zpráva MAS musí obsahovat následující datové položky: - typ zprávy, - číslo zprávy, - identifikace letadla. POZNÁMKA: Pravidla vkládání dat, formáty a obsah polí jsou určeny v příloze A. 9.7.3 Pravidla používání 9.7.3.1 Obecná pravidla 9.7.3.1.1 Zprávu MAS musí ručně spustit přebírající řídící. 9.7.3.1.2 Používání zprávy MAS je povinné, pokud se na základě vzájemné dohody nepoužívá zpráva COF. 9.7.3.2 Zpracování v přijímajícím stanovišti 9.7.3.2.1 Systém ATC přijímající zprávu MAS se musí pokusit o její přidružení odpovídajícímu letovému plánu. 9.7.3.2.2 Skutečnost, že byla přijata zpráva MAS, musí být neprodleně oznámena řídícímu letového provozu. 9.7.4 Potvrzení zprávy MAS 9.7.4.1 Potvrzení 9.7.4.1.1 Pokud zprávu MAS lze jednoznačně přidružit letovému plánu, musí být její příjem potvrzen generováním a odesláním zprávy LAM. 9.7.4.1.2 Pokud zprávu MAS nelze jednoznačně přidružit letovému plánu, potvrzení se neposílá. 9.7.4.2 Případy nedoručení potvrzení Není-li přijata zpráva LAM jako potvrzení zprávy MAS, zobrazí se výstraha na příslušném pracovišti ATC dle potřeby. 9.7.5 Příklad -TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 [1] Povinná pro TX (přenos) a REC (příjem) při použití dialogového postupu M — povinná (mandatory), C — doplňková (complementary) [2] Viz odstavec 5.2.1.1 Požadavky na čas transakce. [3] Nepoužívá se ve všech leteckých konfiguracích. [4] M při zasílání z předávajícího stanoviště, C při zasílání z přebírajícího stanoviště. [5] Vzájemně dohodnuté postupy musí určovat, že při přenosu pro daný směr provozu musí minimálně buď předávající stanoviště zaslat zprávu COF, nebo přebírající stanoviště zaslat zprávu MAS. -------------------------------------------------- PŘÍLOHA II ZPŮSOB VÝMĚNY DAT LETOVÝCH PROVOZNÍCH SLUŽEB (AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION (ADEXP)), VERZE 2.0 (odkaz na dokument Eurocontrol DPS.ET1.ST09-STD) OBSAH UPOZORNĚNÍ NA AUTORSKÁ PRÁVA … PŘEDMLUVA … 1. OBLAST PŮSOBNOSTI … 2. ODKAZY … 3. DEFINICE, SYMBOLY A ZKRATKY … 3.1 Zápis … 3.2 Definice … 3.3 Konstrukce … 3.4 Konvence … 3.5 Operátory … 3.6 Zkratky … 4. ZÁSADY FORMÁTU ADEXP … 4.1 Textový formát (pro přímé čtení) … 4.2 Označená pole schopná vyhledávání … 4.3 Nerozpoznaná pole … 5. SYNTAKTICKÁ PRAVIDLA FORMÁTU ADEXP … 5.1 Lexikální prvky … 5.2 Pole … 6. NORMALIZOVANÝ POPIS ZPRÁVY ADEXP … 6.1 Úvod … 6.2 Pomocný výraz … 6.3 Definice primárních polí … 6.4 Definice sekundárních polí … 6.5 Skupina zpráv … PŘÍLOHA A (Normativní) DEFINICE POLÍ ADEXP … PŘÍLOHA B (Normativní) HLAVNÍ REJSTŘÍK DRUHŮ ZPRÁV ADEXP … PŘÍLOHA C (Normativní) HLAVNÍ REJSTŘÍK DRUHŮ VYHRAZENÝCH ZPRÁV … PŘÍLOHA D (Normativní) HLAVNÍ REJSTŘÍK VYHRAZENÝCH POLÍ … PŘÍLOHA E (Informativní) PŘEHLED SKUPIN ZPRÁV … PŘÍLOHA F (Informativní) PŘÍKLADY FORMÁTU ZPRÁV ADEXP … PŘÍLOHA G (Informativní) BUDOUCÍ VÝVOJ … UPOZORNĚNÍ NA AUTORSKÁ PRÁVA Tento dokument vypracovala Agentura Eurocontrol. Držitelem autorských práv je Agentura Eurocontrol. Obsah nebo kterákoli část tohoto dokumentu je tímto volně k dispozici zástupcům členských států, ale kopírování nebo prozrazení jakékoli další straně podléhá předchozímu písemnému souhlasu Agentury Eurocontrol. PŘEDMLUVA 1. Odpovědný subjekt Tato norma byla vypracována a je aktualizována oddělením pro styk s uživateli CFMU při Evropské organizaci pro bezpečnost leteckého provozu (Eurocontrol). 2. Pracovní dokument EATCHIP Tato norma byla vypracována jako výsledek pracovního dokumentu EATCHIP, doména zpracování dat (DPS), pracovní úkol 09. 3. Schvalování normy 3.1 Tato norma byla schválena v souladu s postupy popsanými ve směrnicích organizace Eurocontrol pro normalizaci, odkaz 000-2-93, verze 1.0. 3.2 Ustanovení normy nabyla účinnosti po schválení verze 1.0 Stálou komisí organizace Eurocontrol v roce 1995 a jsou uplatňována s platností od 1. prosince 1997. 4. Technické opravy a změny Tato norma je trvale aktualizována za účelem zajištění požadovaných změn nebo technických oprav. Postup aktualizace této normy je popsán v příloze H Směrnic pro jednotné vypracování a prezentaci norem organizace Eurocontrol. Změny nebo dodatky ovlivňující základní principy nebo gramatická pravidla ve formátu ADEXP se provádí pouze po oficiálním posouzení stanoveném ve Směrnicích pro jednotné vypracování a prezentaci norem organizace Eucontrol. Změny nebo dodatky k této normě je nutno zasílat v písemné formě sekci "Požadavky uživatelů" - CFMU Users Requirements Section (ADEXP), Agentura Eurocontrol. 5. Redakční postupy 5.1 Formát této normy vyhovuje Směrnicím pro jednotné vypracování a prezentaci norem organizace Eurocontrol, obsahuje však několik odchylek od těchto zásad. Menší odchylky formátu od směrnic jsou určeny k zamezení záměny se značením způsobu výměny dat ATS (ADEXP). 5.2 K vyznačení funkce každého výroku bylo použito následujícího značení: - pro normativní prvky se používá přítomného času popř. budoucího času slovesa nebo pomocného slovesa "muset", vazeb "je nutno" apod. (v angličtině pomocného slovesa "shall") a jsou vytištěna obyčejným písmem Roman, - pro doporučené prvky se používá podmiňovacího způsobu slovesa "mít" (v angličtině slovesa "should"), jsou vytištěna obyčejnou kurzívou a uvozena označením Doporučení. 6. Souvislosti s jinými normami Tato norma souvisí s: Normou Eurocontrol pro výměnu dat on-line (OLDI) 7. Statut příloh této normy Tato norma obsahuje sedm příloh, jejichž funkce je následující: Příloha A | Normativní | Příloha B | Normativní | Příloha C | Normativní | Příloha D | Normativní | Příloha E | Informativní | Příloha F | Informativní | Příloha G | Informativní | 8. Použitý jazyk Původní znění této normy je anglické. 1. OBLAST PŮSOBNOSTI 1.1 ADEXP je formát nikoli protokol. Neexistují žádná omezení pro přenosová média nebo protokoly kromě omezení plynoucích ze znakové sady. 1.2 ADEXP poskytuje formát, který je určen především k výměně zpráv on-line mezi jednotlivými počítači. 1.3 Tento dokument definuje principy a syntaktická pravidla formátu ADEXP. Poskytuje tuto definici ve formě úplné definice polí ADEXP. 1.4 Formát ADEXP je určen k použití v následujících oblastech výměny zpráv (odkazy na dokumenty viz oddíl 2, strana 3): - Plánování letů: výměna dat letového plánu a přidružených zpráv mezi integrovaným systémem základního zpracování letových plánů (IFPS), letovými provozními službami (ATS) a provozovateli letadel (AO). (Odkaz 3). - Uspořádání toku letového provozu (ATFM): výměna zpráv mezi taktickým systémem centrální jednotky uspořádání toku letového provozu (TACT), AO a ATS. (Odkaz 5). - Koordinace řízení letového provozu: výměna taktických koordinačních zpráv mezi stanovišti řízení letového provozu (ATCU). (Odkaz 6). - Řízení vzdušného prostoru: výměna dat týkajících se dostupnosti vzdušného prostoru mezi vnitrostátními ATS, CFMU a AO. (Odkaz 7). - Koordinace civilních a vojenských letů: zprávy týkající se civilních a vojenských letových dat a zprávy o přeletech vzdušného prostoru. (Odkaz 7). 1.5 Podrobné specifikace použití a obsahu zpráv každé z výše uvedených skupin naleznete v příslušných odkazech. 2. ODKAZY 2.1 Následující dokumenty a normy obsahují předpisy, které — prostřednictvím odkazů v tomto textu — představují předpisy této normy Eurocontrol. V době zveřejnění této normy Eurocontrol byly v platnosti zde uvedené verze referenčních dokumentů a norem. Jakékoli opravy uvedených dokumentů Mezinárodní organizace pro civilní letectví (ICAO) musí být neprodleně vzaty v úvahu pro aktualizaci této normy Eurocontrol. Oprava ostatních referenčních dokumentů netvoří součást předpisů této normy Eurocontrol dokud a pokud nejsou oficiálně přezkoumány a začleněny do této normy Eurocontrol. V případě konfliktu mezi požadavky této normy Eurocontrol a obsahem dalších uvedených dokumentů, na které se odkazuje, má přednost tato norma Eurocontrol. 2.2 V době zveřejnění normy byly níže uvedené dokumenty referenčními pro tuto normu, vybízíme však uživatele ke zkontrolování tabulek použití a složení polí zpráv v nejnovějších verzích uvedených dokumentů. 1. ICAO Chicago Convention (Chicagská úmluva ICAO), příloha 10, svazek I, verze z listopadu 1985; 2. ICAO Chicago Convention (Chicagská úmluva ICAO), příloha 10, svazek II, verze z července 1995; 3. IFPS and RPL Dictionary of messages (Slovník zpráv IFPS a RPL), verze 1.0 z března 1998; 4. "Rules of the Air and Air Traffic Services" (Pravidla leteckých a letových provozních služeb), dokument PANS-RAC 4444, verze z listopadu 1985 (včetně změny č. 6 z listopadu 1995); 5. Guide To ATFM Message Exchange (Příručka pro výměnu zpráv ATFM), dokument Eurocontrol, odkaz TACT/USD/MSGGUID, verze 6.0 platná od března 1998; 6. Eurocontrol Standard for On-Line Data Interchange (Norma Eurocontrol pro výměnu dat on-line), verze 2.0 z října 1996; 7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination (Funkční specifikace systémové podpory distribuce dat o vzdušném prostoru a koordinaci mezi civilním a vojenským sektorem), verze 1.0 z května 1996. 3. DEFINICE, SYMBOLY A ZKRATKY 3.1 Zápis Zápis použitý k definování syntaxe se nazývá Backusova normální forma (BNF — Backus Naur Form). BNF definuje soubor pravidel, která určují třídu znakových řetězců. V tomto případě je třídou znakového řetězce soubor zpráv, které lze považovat za syntakticky správné zprávy ADEXP. 3.2 Definice Pro účely této normy Eurocontrol se rozumí: jednotkou : "token" znak nebo soubor znaků, které mohou být "vyjmuty" lexikálním analyzátorem díky přítomnosti separátorů, symbolem : každý "výraz" , který se vyskytuje v pravidle BNF, ale který není znak, koncovým symbolem : symbol, který je reprezentován posloupností znaků, nekoncovým symbolem : symbol, který je reprezentován jedním nebo více koncovými symboly. POZNÁMKA: Nekoncový symbol může být také reprezentován jako kombinace koncových a nekoncových symbolů. 3.3 Konstrukce 3.3.1 BNF se skládá ze souboru pravidel nebo konstrukcí typu: symbol ::= výraz POZNÁMKY: 1) Zápis "::=" znamená "může být nahrazen". 2) "Symbol" je zařazen jako nekoncový. 3) "Výraz" obsahuje koncové a nekoncové symboly. 3.3.2 Koncové symboly jsou přímo reprezentovány řetězcem znaků, které mohou být díky výskytu separátorů lexikálním analyzátorem rozpoznány jako jednotka "token". 3.4 Konvence Pro účely této normy Eurocontrol platí následující konvence: - Koncové symboly jsou vytištěny velkými písmeny. POZNÁMKA: Dle úmluvy znamená koncový symbol NIL "žádný koncový symbol". Tento symbol se používá ve výběru typu: a ::= b (c | NIL), kde a může být nahrazeno (b následováno c) nebo pouze b. - Nekoncové symboly (např. levá strana gramatické stavby) se píší malými písmeny. - Znaky a řetězce písmen objevující se v pravidlech jsou v jednoduchých (') a dvojitých uvozovkách (") v daném pořadí: Příklady 1) HYPHEN::= '-' 2) title::= '-' "TITLE" titleid Pro některá použití modelování dat může být požadováno rozlišování mezi koncovými a nekoncovými symboly jinými prostředky, než je používání velkých a malých písmen. Kdykoli je požadováno rozlišit výslovně mezi koncovými a nekoncovými symboly jiným způsobem, než je psaní malých a velkých písmen, je doporučeno připojit příponu následujícím způsobem: "_at" pro pomocný výraz, "_pf" pro primární pole a "_sf" pro sekundární pole. 3.5 Operátory Pro účely této normy Eurocontrol se používají následující operátory: Volitelné (Optional): tehdy, když se některé symboly mohou, ale nemusí, v gramatice objevit. Volitelné symboly jsou označeny hranatými závorkami "[" a "]". Uzavření (Closure): tehdy, když se skupina symbolů může objevit vícekrát nebo ani jednou. Symboly jsou uzavřeny ve složených závorkách "{" a "}". Jestliže je číslo uvedeno před složenou závorkou, označuje minimální povolený počet výskytů skupiny symbolů. Jestliže je číslo uvedeno po složené závorce, označuje maximální povolený počet výskytů skupiny symbolů. Výběr (Choice): tehdy, když se v gramatice může objevit určitý počet alternativních symbolů. Výběr se značí "|". Zřetězení (Concatenation): reprezentace symbolů uspořádaných do posloupností, třebaže mezi nimi může být jeden nebo více separátorů. Neexistuje explicitní reprezentace. Rozlišujeme dva typy zřetězení: - Přísné zřetězení (Strict Concatenation): určitá pravidla na lexikální úrovni mohou vyžadovat zřetězení koncových symbolů označující, že následují "přísně" za sebou (bez separátoru uprostřed), v tomto případě se použije symbol "!" . Příklad: datetime:: = date ! timehhmm např. "9912251200" znamená 25. prosince 1999 ve 12.00 hod. - Volné zřetězení (Loose Concatenation): přítomnost separátorů mezi koncovými symboly je povolena. Reprezentace volného zřetězení v rámci pravidla může být implicitní nebo explicitní. Příklady: 1) Implicitní: dct::= '-' "DCT" point point 2) Explicitní dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point např. | "-DCT NTM HMS". | POZNÁMKY 1) Zřetězení má vždy přednost před výběrem. Ke změně pořadí vyhodnocování výrazu se používají pravé a levé kulaté závorky. "(" a ")". Příklad: a::= B C | D | je shodné s: | a::= (B C) | D | | a NE s: | a::= B (C | D) | 2) Z důvodů zachování čitelnosti zůstane ve všech pravidlech povolená přítomnost separátorů mezi symboly implicitní. Doporučení: Jestliže hrozí riziko záměny vyplývající z pořadí priorit mezi výše uvedenými operátory, je doporučeno používat k jednoznačnému vyjádření požadovaného pořadí vyhodnocování závorky. 3.6 Zkratky Pro účely této normy Eurocontrol se používají následující zkratky: ACH | ATC Flight Plan Amendment Message — Zpráva o doplňku letového plánu ATC | ADEG | ATS Data Exchange Group — Skupina pro výměnu ATS dat | ADEXP | ATS Data Exchange Presentation — Způsob výměny dat ATS | AFIL | Air-Filed Flight Plan — Letový plán podaný za letu, letový plán AFIL | AFP | ATC Flight Plan Proposal — Návrh letového plánu řízení letového provozu | AFTN | Aeronautical Fixed Telecommunication Network — Letecká pevná telekomunikační síť | ANM | ATFM Notification Message — Zpráva oznámení ATFM, zpráva ANM | AO | Aircraft Operator(s) — Provozovatelé letadel | APL | ATC Flight Plan — APL — Letový plán předložený složkami řízení letového provozu | ATC | Air Traffic Control — Řízení letového provozu | ATCU | Air Traffic Control Unit(s) — Stanoviště řízení letového provozu (ATCU) | ATFM | Air Traffic Flow Management — Uspořádání toku letového provozu | ATS | Air Traffic Services — Letové provozní služby | BNF | Backus Naur Form — Backusova normální forma (Backus Naurova forma) | CASA | Computer Assisted Slot Allocation — Počítačové přidělování časových mezer pro vzlet | CIDIN | Common ICAO Data Interchange Network — Společná datová síť ICAO | CFL. | Cleared Flight Level — Povolená letová hladina | CFMU | Central Flow Management Unit — Centrální jednotka uspořádání toku letového provozu | CMTP | Common Medium-Term Plan — Společný střednědobý plán | CNL | Cancellation Message — Zpráva o zrušení letového plánu, zpráva CNL | CTOT | Calculated Take-Off Time — Vypočítaný čas vzletu | DPS | Data Processing Systems Domain — Doména zpracování dat, doména DPS | ECAC | European Civil Aviation Conference — Evropská konference pro civilní letectví | EFL | Estimated Flight Level — Předpokládaná hladina letu | EOBT | Estimated Off-Block Time — Čas zahájení pojíždění | ETO | Estimated Time Over — Předpokládaný čas přeletu | Eurocontrol | European Organisation for the Safety of Air Navigation — Evropská organizace pro bezpečnost leteckého provozu | EWPD | EATCHIP Work Programme Document — Pracovní dokument EATCHIP | FIR | Flight Information Region — Letová informační oblast | FIW | Flight Plan Input Workstation — Vstupní zařízení pro letový plán | FMP | Flow Management Position — Pracoviště uspořádání toku letového provozu | FNM | Flight Notification Message — Zpráva oznámení o letu, zpráva FNM | FPL | Flight Plan Message (ICAO format) — Zpráva podaného letového plánu, Zpráva FPL (formát ICAO) | GAT | General Air Traffic — Letový provoz v souladu s pravidly ICAO | IA | International Alphabet — IA — mezinárodní abeceda | IAFP | Individual ATC Flight Plan Proposal — Zpráva návrhu letového plánu ATC | ICAO | International Civil Aviation Organisation — Mezinárodní organizace pro civilní letectví | IFPD | Individual Flight Plan Data — Data individuálního letového plánu | IFPS | Integrated Initial Flight Plan Processing System — Integrovaný systém zpracování letových plánů | IFPU | IFPS Unit — Jednotka integrovaného systému zpracování letových plánů, jednotka IFPS | IFR | Instrument Flight Rules — Pravidla letu podle přístrojů | ISO | International Standards Organisation — Mezinárodní organizace pro normalizaci | ITA | International Telegraph Alphabet — Mezinárodní telegrafická abeceda | LAM | Logical Acknowledgement Message — Zpráva o příjmu a zpracování předchozí zprávy, zpráva LAM | LRM | Logical Rejection Message — Logická zpráva odmítnutí, zpráva LRM | MAC | Co-ordination Abrogation Message — Zpráva zrušení koordinace, zpráva MAC | MFS | Message from Shanwick — Zpráva ze Shanwicku, zpráva MFS | OAT | Operational Air Traffic — Let prováděný podle jiných pravidel než ICAO | OLDI | On-Line Data Interchange — Výměna dat on-line | RFL | Requested Flight Level — Požadovaná letová hladina | RFP | Replacement Flight Plan — Nahrazující letový plán | RFPD | Repetitive Flight Plan Data — Data stálého letového plánu | RPL | Repetitive Flight Plan — Stálý letový plán | RVR | Runway Visual Range — Dráhová dohlednost | SFL | Supplementary Flight Level — Doplňková letová hladina | SRD | Software Requirements Document — Dokument softwarových požadavků | SSR | Secondary Surveillance Radar — Sekundární přehledový radar | TACT | Tactical System of the CFMU — Taktický systém centrální jednotky uspořádání toku letového provozu | TOS | Traffic Orientation Scheme — Schéma orientace provozu (TOS) | UIR | Upper Information Region — Horní letová informační oblast (UIR) | VFR | Visual Flight Rules — Pravidla letu za viditelnosti | 4. ZÁSADY FORMÁTU ADEXP 4.1 Textový formát (pro přímé čtení) 4.1.1 Formát ADEXP je textový formát založený na znacích. 4.1.2 Zprávy ADEXP může číst operátor, což usnadňuje lepší slaďování nebo řešení provozních problémů. 4.1.3 Textový formát je také přístupnější a srozumitelnější. 4.2 Označená pole schopná vyhledávání 4.2.1 Zpráva ve formátu ADEXP se skládá z polí. 4.2.2 Tato pole jsou oddělena vlastním znakem začátku pole, spojovníkem ( "-" ), a jsou označena specifickým klíčovými slovy. POZNÁMKA: Je nutno si uvědomit, že určitá pole (ta, která jsou syntakticky definována jako obsahující lexikální položku "CHARACTER") mohou právoplatně obsahovat znak "-"jako součást obsahu pole. 4.2.3 Tento přístup zlepšuje rozšiřitelnost a odolnost formátu. (jestliže je pole nepřítomné nebo nesprávné, může být vynecháno, aniž by to zabránilo interpretaci zbytku zprávy) (viz oddíl 4.3). 4.2.4 Dalším důsledkem je, že pořadí polí ve zprávě nemá — kromě prvního pole (povinné pole "TITLE"), které určuje povolená pole — vliv na určení její platnosti. 4.2.5 Pole mohou být základní nebo složená. 4.2.6 Základní součásti složených polí se nazývají sekundární pole a jsou definovány přítomností klíčových slov a ohraničeny znaky začátku pole. 4.2.7 Základní pole jsou pole, která neobsahují sekundární pole. 4.2.8 Jednoduchá nebo složená pole tvořící první úroveň definice zprávy se nazývají primární pole. 4.2.9 Všechny složky nižší úrovně jsou podle definice sekundární pole, která mohou být základní nebo složená. 4.2.10 Složená pole jsou dvou typů: strukturovaná pole nebo výčet polí. 4.2.11 Strukturovaná pole mají předem definovaný obsah složený pouze ze sekundárních polí. Pořadí sekundárních polí v strukturovaném poli NENÍ významné. 4.2.12 Výčet polí je uvozen klíčovým slovem BEGIN (začátek) a ukončen klíčovým slovem END (konec). Mezi nimi se může vícekrát vyskytnout stejné sekundární pole nebo kombinace sekundárních polí. Pořadí výskytů uvnitř výčtu polí je sémanticky významné. 4.2.13 Pokud není výslovně určeno jinak, používá se v následujícím textu termín "pole" obecně ve významu primární pole a/nebo sekundární pole. 4.2.14 Pole ve zprávě mohou být volitelná nebo povinná, což je definováno jejich syntaxí. 4.3 Nerozpoznaná pole 4.3.1 Pokud se ve zprávě objeví neznámé pole, je ignorováno. 4.3.2 Jinými slovy, jestliže systém, který analyzuje zprávu, nerozpozná klíčové slovo, je ignorován celý text až k příštímu známému primárnímu poli, které není v rámci výčtu polí. 4.3.3 V závislosti na druhu zprávy může — ale nemusí — ignorované pole způsobit odmítnutí celé analyzované zprávy. POZNÁMKA: Je nutno poznamenat, že ačkoli je formát ADEXP navržen tak, aby poskytoval tento typ flexibility, je na vlastním úsudku osob odpovědných za definování požadavků rozhraní určit pro každou zprávu, jakým způsobem by měl systém reagovat na nerozpoznané pole. 4.3.4 Je-li neznámé pole výčtem polí (což se zjistí dle klíčového slova -BEGIN), potom je celý jeho obsah (až k odpovídajícímu klíčovému slovu -END) ignorován. 4.3.5 Aby se zabránilo jakékoliv nejednoznačnosti během návratu, který následuje po přeskočení nerozpoznaného pole, je požadováno, aby klíčové slovo uvádělo buď primární pole, nebo sekundární pole. 4.3.6 To umožňuje definovat dva druhy klíčových slov: - primární klíčová slova, - sekundární klíčová slova. 4.3.7 Jakmile je klíčové slovo definováno jako příslušející do jedné z těchto kategorií, nesmí být, s výjimkou výskytu uvnitř výčtu polí, později znovu použito v jiné skupině zpráv jako patřící do druhé kategorie. Vnitřní výskyty primárních klíčových slov kdekoli v rámci výčtu polí jsou možné, aniž by vznikly jakékoliv nejasnosti, neboť klíčové slovo BEGIN označuje, že jeho vnitřní výskyty lze považovat za sekundární pole. Příklady (použití typů klíčových slov): 1) primární pole -RFL F330; 2) sekundární pole: vždy v rámci "složeného pole" -GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W kde -GEO je primární složené pole a pole -GEOID, -LATTD a -LONGTD jsou všechna sekundární; 3) výčet polí -BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID … -END RTEPTS, kde "-BEGIN" je indikátor výčtu polí a "RTEPTS" je primární pole. POZNÁMKA: "RFL" je definováno jako primární pole. Zařazení do výčtu polí je jediný případ, kdy může být primární pole použito jako sekundární pole. (viz příklad 3 výše). 5. SYNTAKTICKÁ PRAVIDLA FORMÁTU ADEXP 5.1 Lexikální prvky 5.1.1 Sada znaků 5.1.1.1 Pro výměnu zpráv ve formátu ADEXP se používá mezinárodní abeceda č. 5 (IA-5), jak je definována v odkaze 1. 5.1.1.2 Formát ADEXP je navržen jako formát pro výměnu mezi dvěma počítači, což lze provádět pomocí různých počítačových sítí nebo pomocí nekomutovaných propojení mezi počítači. Navíc existuje potřeba, aby bylo možno vyměňovat některé zprávy ADEXP, zvláště ty, které se týkají plánování letů a ATFM, pomocí letecké pevné telekomunikační sítě (AFTN). 5.1.1.3 Zprávy, jejichž přenos může být požadován pomocí AFTN, musí mít znakovou sadu omezenou na znaky, u kterých existuje přímá korelace mezi mezinárodní telegrafní abecedou č. 2 (ITA-2) a IA-5, jak je definováno v odkaze 1. POZNÁMKA: Kromě grafických a formátovacích znaků, jak jsou definovány níže, definuje sada znaků ITA-2 "signály" (např.: děrná páska). Ty nejsou součástí povolené znakové sady pro zprávy ADEXP. 5.1.1.4 K použití ve zprávách ADEXP povolené a způsobilé k přenosu pomocí AFTN jsou níže definované grafické a formátovací znaky: Grafické znaky a) velká písmena (A až Z) b) čísla (0 až 9) c) následující speciální grafické znaky: 1) mezerník „” 2) levá závorka "(" 3) pravá závorka ")" 4) spojovník "-" 5) otazník "?" 6) dvojtečka ":" 7) tečka "." 8) čárka "," 9) odsuvník "'" 10) rovnítko "=" 11) znaménko plus "+" 12) lomítko "/" Formátovací znaky a) návrat vozíku b) nová řádka 5.1.2 Základní lexikální položky Následující základní lexikální položky jsou definovány pro použití v této specifikaci: - ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'| 'T'|'U'|'V'|'W'|'X'|'Y'|'Z' - DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9' - ALPHANUM ::= ALPHA | DIGIT - SPACE ::= ' ' - HYPHEN ::= '-' - FEF ::= Carriage_return | Line_Feed (návrat vozíku, nová řádka) - SEP ::= 1{ SPACE | FEF } - SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/' - CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN - LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF - START-OF-FIELD ::= HYPHEN POZNÁMKA: LIM_CHAR zastupuje jakýkoliv povolený znak kromě znaku HYPHEN, který je rezervován pro označení začátku pole. Naproti tomu CHARACTER zastupuje jakýkoli povolený prvek znakové sady. 5.1.3 Řádky, separátory a oddělovače 5.1.3.1 Rozdělení textu zprávy na řádky nemá žádný syntaktický účinek. 5.1.3.2 Separátor může být mezerník nebo formátovací znak. 5.1.3.3 Pole musí být vymezena pouze přítomností znaku začátku pole následovaného klíčovým slovem. 5.1.3.4 Celá zpráva může tedy být právoplatně umístěna na jediné řádce. 5.1.4 Označené hodnoty 5.1.4.1 Může být požadováno označení číselné hodnoty jako negativní. 5.1.4.2 Pole, u nichž je požadováno označení negativní hodnoty, musí v rámci své syntaktické definice explicitně označovat hodnotu jako "s označenou"(signed value), tj. jako buď pozitivní, nebo negativní. Pole, které nebylo takto definováno, nemůže představovat negativní hodnotu. 5.1.4.3 "Označená hodnota" musí být vždy uvozena buď písmenem "N" znamenajícím negativní (mínus) nebo písmenem "P" znamenajícím pozitivní (plus). Nulová hodnota může být uvozena buď "N", nebo "P". 5.1.4.4 Syntaxe pole, které umožňuje výskyt označené hodnoty, musí být následující: '-' "KEYWORD" ("P" | "N") ! 1{DIGIT} Příklad: Pole nazvané "NUMBER" , které může obsahovat negativní hodnotu o jedné až osmi číslicích se definuje následovně: '-' "NUMBER" ("P" | "N") ! 1{DIGIT}8 Z toho plyne: -NUMBER P5 - hodnota je +5 -NUMBER N5 - hodnota je -5 -NUMBER 5 - neplatná syntaxe, pole musí obsahovat "P" nebo "N" 5.1.5 Klíčová slova 5.1.5.1 Klíčové slovo je libovolná posloupnost velkých písmen nebo číslic. Uvádí pole, pouze pokud mu předchází znak začátku pole ("-"). keyword::= 1{ ALPHANUM } 5.1.5.2 Klíčová slova musí dodržovat následující syntaxi: '-'!{SEP}!"KEYWORD"!1{SEP}! < sekundární pole nebo obsažená hodnota> tj. klíčové slovo je odděleno od svého "znaku začátku pole" pomocí žádného nebo několika separátorů. Ihned po něm musí následovat jeden nebo několik separátorů následovaných příslušným sekundárním polem/ příslušnými sekundárními poli nebo obsaženou hodnotou. POZNÁMKA: Je důležité si uvědomit, že klíčové slovo a jeho uvádějící znak začátku pole mohou být vzájemně odděleny jakýmkoli počtem separátorů nebo nemusí být odděleny žádným separátorem. Příklady: (Všechny následující posloupnosti právoplatně uvádějí pole) 1) -TITLE IFPL 2) - TITLE IFPL 3) - TITLE IFPL 4) - TITLE IFPL 5.1.5.3 Doporučení: Doporučeným postupem je nepoužívat separátor mezi znakem začátku pole "-" a následujícím klíčovým slovem. POZNÁMKA: 1) V předcházejících příkladech odpovídá doporučení první příklad. 2) Je také důležité si uvědomit, že po klíčovém slově musí ihned následovat alespoň jeden separátor. 5.1.5.4 V celém dokumentu je zřetězení položek oddělených alespoň jedním separátorem implicitně zastupováno zápisem "volného zřetězení" (viz odst. 3.5). POZNÁMKA: Jak bude vysvětleno později, klíčová slova uvádějí také výčet polí, pokud jsou uvozena klíčovým slovem BEGIN. 5.1.5.5 Klíčová slova musí být co nejkratší, ale přitom musí zůstat sémanticky smysluplná. 5.1.5.6 Předdefinovaná klíčová slova formátu ADEXP, která jsou uvedena níže, nemohou být předefinována nebo použita k jinému účelu při speciálním použití formátu. TITLE: | DRUH, označuje kategorii zpráv a definuje příslušný soubor povolených primárních polí, | BEGIN: | ZAČÁTEK, označuje začátek výčtu polí | END: | KONEC, označuje konec výčtu polí | COMMENT: | KOMENTÁŘ, označuje pole COMMENT. | 5.1.5.7 Aby se zabránilo nejednoznačnosti (dvojí použití stejného klíčového slova s rozdílným významem) nebo opakování (různá klíčová slova se stejným významem), je v příloze A (A3) této normy uvedena hlavní tabulka definic primárních polí tj. primární klíčová slova. Hlavní tabulka definic sekundárních polí tj. sekundárních klíčových slov) je také uvedena, a to v příloze A (A4). 5.2 Pole 5.2.1 Syntaxe polí field::= basic_field | structured_field | list_field (pole::= základní pole | strukturované pole | výčet polí basic_field::= '-' keyword contained_values (základní pole::= '-' klíčové slovo obsažené hodnoty) contained_values::= {CHARACTER} (obsažené hodnoty::= {ZNAK}) list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword (výčet polí::= '-' "ZAČÁTEK" klíčové slovo {sekundární pole} '-' "KONEC" klíčové slovo) structured_field::= '-' keyword field_1 field_2 …field_n (strukturované pole::= '-' klíčové slovo pole 1 pole 2… pole n) POZNÁMKA: Jak uvidíte dále, v případě výčtu polí není klíčové slovo uvozeno přímo pomocí "-" ale pomocí konstrukce "-""BEGIN". 5.2.2 Stavba zpráv prostřednictvím polí 5.2.2.1 První pole zprávy ADEXP musí být vždy pole TITLE (tj. pole uvozené klíčovým slovem TITLE — druh). 5.2.2.2 Zbytek obsahu zprávy na úrovni primárních polí musí být definován svým polem TITLE. 5.2.2.3 Syntaxe zpráv odpovídajících danému poli TITLE musí být definována pomocí polí, která obsahuje (tato pole jsou definována svými klíčovými slovy): - název a povolený obsah jejích primárních polí, - název a povolený obsah jejích sekundárních polí. 5.2.3 Základní pole 5.2.3.1 Syntaxe jednoduchých polí je následující: basic_field::= '-' keyword contained_values (Základní pole::= '-' klíčové slovo obsažené hodnoty) 5.2.3.2 Výraz "contained_values" (obsažené hodnoty) definuje text poskytující hodnotu pole a nemůže uvádět žádné sekundární pole. Příklad pravidla: arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ") POZNÁMKA: 1) Explicitní obdoba tohoto pravidla zní: arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ"). 2) Příklad části zprávy:: "-ARCTYP ZZZZ". 5.2.3.3. Doporučení: Jestliže jsou v základním poli více než dvě obsažené hodnoty a je navíc potřeba vyjádřit "výběr" nebo "volbu" mezi hodnotami, je doporučeno změnit pole na strukturované pole a zahrnout obsažené hodnoty do sekundárních polí. 5.2.4 Výčet polí 5.2.4.1 Syntaxe výčtu polí je následující: list_field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword (Výčet polí::= '-' "ZAČÁTEK" klíčové slovo {sekundární pole} '-' "KONEC" klíčové slovo) 5.2.4.2 "Sekundární pole" mohou být jakékoli kombinace sekundárních polí, které se mohou uvnitř výčtu polí vyskytovat vícekrát nebo ani jednou. 5.2.4.3 Souhrn sekundárních polí obsažených v daném výčtu polí musí tvořit uspořádaný celek (pořadí sekundárních polí je významné). Příklad pravidla: addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR" POZNÁMKA 1) Tento příklad ukazuje, že pole "addr" je výčet polí, který obsahuje 0 nebo více výskytů sekundárního pole "fac" (služba ATS). 2) Příklad části zprávy ukazující ADDR jako výčet polí obsahující sekundární pole FAC: -BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR. 3) Příklad části zprávy ukazující kombinaci sekundárních polí: xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX". 5.2.5 Strukturovaná pole 5.2.5.1 Syntaxe strukturovaných polí je následující: structured_field::= '-' keyword field_1 field_2…field_n (strukturované pole::= '-' klíčové slovo pole 1 pole 2… pole n) 5.2.5.2 Povolená sekundární pole obsažená v daných strukturovaných polích závisí pouze na samotných strukturovaných polích. 5.2.5.3 Pořadí výskytu sekundárních polí v strukturovaném poli není významné, což umožňuje snadné pozdější rozšiřování (přidání nových obsažených sekundárních polí). Příklad pravidla: pt::= '-' "PT" ptid [fl] [eto] POZNÁMKY: 1) Tento příklad definuje pole "pt"jako strukturované pole obsahující bod (sekundární pole "ptid"), nepovinně následovaný plánovanou letovou hladinou (sekundární pole "fl"), nepovinně následovanou předpokládaným časem přeletu (sekundární pole "eto"). 2) Příklad výskytu takového pole může být: "-PT -PTID RMS -FL F250 -ETO 921225120000". 5.2.5.4 Doporučení: Kdykoliv se předpokládá, že se obsah pole může později rozšířit, je žádoucí vytvořit strukturované pole. To umožní pozdější rozšiřování jeho sekundárních polí. Naopak základní pole může být snadněji a běžněji použitelné, ale vyžaduje pevnou posloupnost prvků (hodnot) s velmi omezenými možnostmi rozšíření. 5.2.6 Pole COMMENT (komentář) 5.2.6.1 Pole comment uvádí oblast volného textu, ve které lze použít všechny dostupné znaky kromě znaku začátku pole ("-") a která končí až začátkem dalšího pole. comment::= '-' "COMMENT" { LIM_CHAR } Příklad: COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA (komentář: Toto je začátek oblasti volného textového popisu tratě) 5.2.7 Pole TITLE (druh) 5.2.7.1 První pole zprávy ADEXP musí vždy být pole TITLE. Syntaxe tohoto pole je následující: title::= '-' "TITLE" 1{ ALPHA }10 5.2.7.2 Možné hodnoty pole TITLE sestávají ze souboru druh zprávy ADEXP, jak jsou uvedeny v příloze B této normy. Příklad: -TITLE IFPL 6. NORMALIZOVANÝ POPIS ZPRÁVY ADEXP 6.1 Úvod 6.1.1 Následující odstavce definují, jak musí být normalizovaným způsobem popsán formát ADEXP různých skupin zpráv v rámci této normy. 6.1.2 Tento normalizovaný popis obsahuje: - definice pomocného výrazu, - definice syntaxe a sémantiky každého primárního pole, - definice syntaxe a sémantiky každého sekundárního pole, - definice každé skupiny zpráv s odkazem na jejich specifikační dokumenty. 6.1.3 Tato norma neposkytuje podrobný popis skladby polí a pravidla vkládání dat pro každého druhu zprávy. 6.1.4 Měla by být konzultována specifikační dokumentace rozhraní určená pro příslušnou skupinu zpráv (viz oddíl 6.5.7). 6.1.5 Specifikační dokumenty by měly normalizovaným způsobem poskytovat následující informace pro každý druh zprávy: - seznam povinných primárních polí, - seznam nepovinných primárních polí, - Pravidla vkládání dat pro každé pole, a zvláště pravidla týkající se použití sekundárních polí, která jsou v rámci této normy definována jako nepovinná, - pravidla týkající se návratu po zjištění nerozpoznaného pole. 6.1.6 Pole aktuálně definovaná a schválená všemi členskými státy Eurocontrol pro použití v rámci různých kategorií zpráv, pro které bylo definováno použití formátu ADEXP, jsou uvedena v příloze A tohoto dokumentu. 6.1.7 Pole se nemůže použít pro jiný účel, než jaký je definován v jeho sémantickém popisu. 6.1.8 Hlavní rejstřík vyhrazených polí je uveden v příloze D. Použití vyhrazených polí v rámci aktuálně definovaných zpráv ADEXP nebylo schváleno. Jde převážně o pole, u kterých se předpokládá použití v budoucnosti nebo se používají místně v rámci vnitrostátních systémů. Účelem jejich začlenění do této normy je zajištění jedinečnosti druhu polí a vyvarování se zbytečných opakování. 6.2 Pomocný výraz 6.2.1 Abychom získali čitelnou definici polí, je často užitečné zavést v gramatickém popisu pomocný výraz. 6.2.2 Pomocné výrazy neuvádějí pole nebo sekundární pole, a proto nejsou sdruženy se zvláštním klíčovým slovem. Přesto se mohou objevit v definici několika polí nebo sekundárních polí nebo pomocných položek. Například pomocný výraz jako "date" může být použit v definici mnoha polí. 6.2.3 Všechny nezbytné pomocné výrazy musí být uvedeny v abecedním pořádku a jsou definovány v příloze A (A2) této normy. 6.2.4 Popis lze uvést v abecedním pořádku v tabulce podobné následující: Pomocný výraz | Syntaxe | Sémantika | Použití v primárním poli | Použití v sekundárním poli | Použití v pomocné položce | adexpmsg | { CHARACTER } | Volný text odpovídající syntaxi popsané pro zprávu ADEXP | | Ifpdlong Rfpdlong Preproctxt Postproctxt | | aidequipment | ( ('N' | 'S') ! [ equipmentcode ] ) | equipmentcode | Zařízení pro radiové spojení, navigaci a přiblížení | ceqpt | | | aircraftid | 1{ ALPHANUM }7 | Identifikace letadla | Arcid Arcidk Arcidold Prevarcid | | | 6.3 Definice primárních polí 6.3.1 Všechna primární pole používaná ve zprávách ADEXP musí odpovídat syntaxi a sémantice určené v příloze A (A3) této normy. 6.3.2 Nejprve je uvedena syntaxe každého pole, potom jeho sémantika popsaná jednoduchým, přesným a jednoznačným způsobem. 6.3.3 Syntaxe pole je vyjádřena pomocí zápisu BNF, jak byl uveden v oddíle 3 této normy. 6.3.4 Popis může být uveden v abecedním pořádku v tabulce podobné následující, kde: - první sloupec představuje levou část pravidla BNF (tj. část pravidla nalevo od "::=", třetí sloupec představuje pravou část pravidla BNF, - druhý sloupec (Typ) uvádí, jestli se jedná o pole základní ("b" jako "basic") nebo složené ("c" jako "compound") Primární pole | Typ | Syntaxe | Sémantika | eobt | b | '-' "EOBT" timehhmm | Předpokládaný čas zahájení pojíždění | 6.4 Definice sekundárních polí 6.4.1 Všechna sekundární pole používaná ve zprávách ADEXP musí odpovídat syntaxi a sémantice popsané v příloze A (A4) této normy. 6.4.2 Navíc jsou pro účely křížových odkazů určena Primární pole, ve kterých se dané sekundární pole objevuje. 6.4.3 Sekundární pole může být podřazeno také jiným sekundárním polím, proto je uveden také křížový odkaz na taková sekundární pole. 6.4.4 Popis může být uveden v abecedním pořádku v tabulce podobné následující: Sekundární pole | Typ | Syntaxe | Sémantika | Použití v primárním poli | Použití v sekundárním poli | brng | b | '-' "BRNG" refbearing | Směrník bodu z navigační příručky (v magnetických stupních) | ref | | 6.5 Skupina zpráv 6.5.1 Provozní kategorie (skupiny) zpráv definované pro použití formátu ADEXP jsou uvedeny v příloze E této normy. 6.5.2 Skupiny jsou definovány dle provozní povahy vyměňovaných zpráv a jsou často charakterizované příslušným systémem. 6.5.3 Pro každou skupinu zpráv je nutné uvádět odkazy na příslušnou specifikační dokumentaci. 6.5.4 Žádnou hodnotu TITLE (druh) již použitou pro jednu skupinu zpráv nelze znovu použít s rozdílným významem pro jinou skupinu. 6.5.5 Hlavní rejstřík druhů zpráv je veden v příloze B této normy. 6.5.6 Pro každý druh vyskytující se v hlavním rejstříku druhů zpráv je uveden odkaz na příslušnou skupinu. Odkaz na specifikační dokumenty je tedy pro každý druh zprávy zajištěn pomocí skupiny zpráv. 6.5.7 Je uveden také hlavní rejstřík druhů vyhrazených zpráv v příloze C. Druhy "vyhrazených" zpráv nebyly schváleny k použití v rámci aktuálně definovaných skupin zpráv používajících ADEXP. Jde obvykle o zprávy, u kterých se předpokládá případné použití v budoucnosti v rámci některé již definované skupiny, nebo o zprávy používané místně v rámci vnitrostátních systémů. Účelem jejich začlenění do této normy je zajištění jedinečnosti druhů zpráv a zamezení zbytečnému opakování. -------------------------------------------------- PŘÍLOHA III DOKUMENT DEFINUJÍCÍ ROZHRANÍ PRO VÝMĚNU DAT O LETU (FDE-ICD — FLIGHT DATA EXCHANGE — INTERFACE CONTROL DOCUMENT), VERZE 1.0 (odkaz na dokument Eurocontrol COM.ET1.ST12-STD) OBSAH UPOZORNĚNÍ NA AUTORSKÁ PRÁVA… PŘEDMLUVA… 1. ÚVOD… 2. OBLAST PŮSOBNOSTI… 3. ODKAZY… 3.1 Úvod… 3.2 Odkazy… 4. DEFINICE, SYMBOLY A ZKRATKY… 4.1 Definice… 4.2 Symboly a zkratky… 4.3 Zápis… 5. TECHNICKÝ PŘEHLED… 5.1 Sada protokolů… 5.2 Struktura profilu… 5.3 Vztah k předchozím verzím specifikací… 6. POŽADAVKY NA PROFIL… 6.1 Požadavky na shodu… 6.2 Požadavky na vyšší vrstvy… 6.3 Požadavky na nižší vrstvy… 6.3.1 Požadavky na přenosovou vrstvu… 6.3.2 Požadavky na síťovou vrstvu… 6.3.3 Požadavky na vrstvu datových spojení… 6.3.4 Požadavky na fyzickou vrstvu… 7. ZKUŠEBNÍ POSTUPY… PŘÍLOHA A (Normativní) PROTOKOL PRO PŘENOS ZPRÁV… A.1 ÚVOD… A.2 Poskytované služby… A.3 Požadované služby… A.4 Specifikace protokolu… A.4.1 Úvod… A.4.2 Druhy dat… A.4.3 Navázání spojení… A.4.4 Přenos dat… A.4.5 Řádné ukončení spojení… A.4.6 Opakované navázání spojení… A.4.7 Neporušenost spojení… A.4.8 Mimořádné ukončení spojení… A.4.9 Návrat po poruše… A.4.10 Formáty zpráv… A.5 Tabulky přechodu stavu protokolu… A.5.1 Úvod… A.5.2 Definice stavů… A.5.3 Možné události… A.5.4 Časovače… A.5.5 Tabulka přechodů stavu… A.5.6 Diagram přechodů stavu… PŘÍLOHA B (Normativní) PROTOKOL ZÁHLAVÍ ZPRÁVY… B.1 Úvod… B.2 Poskytované služby… B.3 Požadované služby… B.4 Specifikace protokolu… B.4.1 Navázání spojení… B.4.2 Zabránění přebytečným síťovým spojením… B.4.3 Zrušení spojení… B.4.4 Přenos dat… PŘÍLOHA C (Normativní) SÍŤOVÝ PROTOKOL… C.1 Úvod… C.2 Poskytované služby… C.3 Požadované služby… C.4 Adresování NSAP… C.4.1 Úvod… C.4.2 Struktura adresy NSAP… C.4.3 Přidělení identifikátorů a voličů jednotek ATC… C.5 Specifikace protokolu… C.5.1 Přehled… C.5.2 Kódování adresy… C.5.3 Kódování uživatelského datového pole… C.5.4 Zpracování adres v paketech INCOMING CALL (příchozí volání)… C.5.5 Přenos dat… PŘÍLOHA D (Normativní) FORMULÁŘE PROHLÁŠENÍ O SHODĚ PROVEDENÍ PROTOKOLU (PICS) PRO JEDNOTLIVÉ PROFILY… D.1 Úvod… D.2 Pokyny pro vyplnění formulářů PICS… D.2.1 Celková struktura formulářů PICS… D.2.2 Doplňkové údaje… D.2.3 Údaje o výjimkách… D.2.4 Podmíněné položky… D.3 Formulář PICS protokolu pro přenos zpráv… D.3.1 Zkratky a speciální symboly… D.3.2 Identifikace… D.3.3 Provedení protokolu… D.4 Formulář PICS pro protokol záhlaví zprávy… D.4.1 Zkratky a speciální symboly… D.4.2 Identifikace… D.4.3 Provedení protokolu… D.5 Formulář PICS pro síťový protokol… D.5.1 Zkratky a speciální symboly… D.5.2 Identifikace… D.5.3 Provedení protokolu… PŘÍLOHA E (Normativní) SEZNAM POŽADAVKŮ NA PROFIL… E.1. Úvod… E.2. Úloha formulářů PRL a PICS… E.3. Zápis… E.4. Pokyny pro vyplňování formulářů PICS… E.5 Odkazy… E.6 Prohlášení o shodě… E.6.1 Přehled shody… E.6.2 Dynamické požadavky na shodu… E.7 Požadavky na vyšší vrstvu… E.8 Požadavky na nižší vrstvu… E.8.1 Požadavky na přenosovou vrstvu… E.8.2 Požadavky na síťovou vrstvu… E.8.3 Požadavky na vrstvu datového spojení… E.8.4 Požadavky na fyzickou vrstvu… PŘÍLOHA F (Informativní) POSTUP PROVÁDĚNÍ ZKOUŠEK SHODY S POŽADAVKY… F.1 Úvod… F.2 Účel a oblast působnosti… F.3 Dokumentace… F.4 Metody a postupy vývoje… F.5 Zkoušky… F.5.1 Úvod… F.5.2 Zkoušky nižších vrstev (vrstvy 1-3)… F.5.3 Zkoušky aplikační vrstvy… F.5.4 Osvědčení… F.5.5 Oznámení… PŘÍLOHA G (Informativní) PŘIDĚLENÍ IDENTIFIKÁTORŮ JEDNOTEK ŘÍZENÍ LETOVÉHO PROVOZU… PŘÍLOHA H (Informativní) POKYNY PRO SPOLEHLIVOST, DOSTUPNOST A ZABEZPEČENÍ… H.1 Úvod… H.2 Účel a oblast působnosti… H.3 Dokumentace… H.4 Provedení pronajaté linky… H.4.1 Spolehlivost… H.4.2 Dostupnost… H.4.3 Zabezpečení… H.4.4 Příklad konfigurace… H.5 Síťové provedení… H.5.1 Spolehlivost… H.5.2 Dostupnost… H.5.3 Zabezpečení… H.6 Obecné pokyny pro provedení pronajaté linky a síťových provedení… H.6.1 Spolehlivost… H.6.2 Dostupnost… H.6.3 Správa systémů… H.6.4 Příklad konfigurace… UPOZORNĚNÍ NA AUTORSKÁ PRÁVA Tento dokument vypracovala Agentura Eurocontrol. Držitelem autorských práv je Agentura Eurocontrol. Obsah nebo kterákoli část tohoto dokumentu je tímto volně k dispozici zástupcům členských států, ale kopírování nebo prozrazení jakékoli další straně podléhá předchozímu písemnému souhlasu Agentura Eurocontrol. PŘEDMLUVA 1. Odpovědný subjekt Tato norma byla vypracována a je aktualizována Skupinou pro výměnu dat letových plánů (FPDE) Evropské organizace pro bezpečnost leteckého provozu (Eurocontrol). 2. Pracovní dokument EATCHIP Tato norma se vztahuje k pracovnímu dokumentu EATCHIP (EWPD), doména komunikace, pracovní úkol 01, odborný úkol 12. 3. Schvalování normy 3.1 Tato norma byla schválena v souladu s postupy popsanými ve směrnicích organizace Eurocontrol pro normalizaci, odkaz 000-2-93. 3.2 Tato norma nabývá účinnosti po schválení Stálou komisí organizace Eurocontrol a nahrazuje normu Eurocontrol pro výměnu dat on-line (OLDI), verze 1, část 3: TECHNICKÉ POŽADAVKY (Dokument definující rozhraní — krátkodobý) odkaz 001-3-92. 4. Technické opravy a změny Tato norma je trvale aktualizována za účelem zajištění požadovaných změn nebo technických oprav. Postup aktualizace této normy je popsán v příloze H Směrnic pro jednotné vypracování a prezentaci norem organizace Eurocontrol, odkaz 000-1-92. 5. Redakční postupy 5.1 Formát této normy vyhovuje Směrnicím pro jednotné vypracování a prezentaci norem organizace Eurocontrol. 5.2 K vyznačení funkce každého výroku byl použit následujícího zápis: - pro normativní výroky se používá přítomného času popř. budoucího času slovesa nebo pomocného slovesa "muset", vazeb "je nutno" apod. (v angličtině pomocného slovesa "shall") a jsou vytištěna obyčejným písmem Roman, - pro doporučené prvky se používá podmiňovacího způsobu slovesa "mít" (v angličtině slovesa "should"), jsou vytištěna obyčejnou kurzívou a uvozena označením Doporučení. 5.3 Jakékoli jiné informace považované za důležité pro porozumění určité odrážce budou začleněny do textu jako POZNÁMKA. Poznámka je považována za pouze informativní, tudíž neobsahuje specifikace a je umístěna hned za odrážkou, ke které se vztahuje. 5.4 Výjimečně, aby byly seznamy požadavků na profil (PRL — Profile Requirements Lists) v příloze E předloženy ve vhodném formátu, nejsou některé tabulky odsazeny a nepokračují přes několik stran. 6. Souvislosti s jinými normami 6.1 Tato norma organizace Eurocontrol nahrazuje Dokument definující rozhraní — krátkodobý OLDI (ST-ICD), část 3, verze 1, norma Eurocontrol OLDI [odkaz 13]. 6.2 Tato norma Eurocontrol je první částí předpokládaného souboru norem Eurocontrol týkajících se definování rozhraní (ICD — Interface Control Documents) pro výměnu letových dat. 7. Statut příloh této normy Přílohy této normy mají následující funkci: - Příloha A — Normativní - Příloha B — Normativní - Příloha C — Normativní - Příloha D — Normativní. - Příloha E — Normativní - Příloha F — Informativní - Příloha G — Informativní - Příloha H — Informativní 8. Použitý jazyk Původní znění této normy je anglické. 1. ÚVOD Tato norma je založena na krátkodobém dokumentu definujícím rozhraní vytvořeném bývalou technickou skupinou OLDI, jejímž úkolem bylo definovat nové normy rozhraní pro budoucí provoz OLDI mezi oblastními řídícími středisky. Dřívější propojení OLDI bylo založeno na autorizovaných protokolech, jako je INTERCAUTRA nebo Datenübertragungs- und Verteilungssystem (DÜV — systém přenosu a distribuce dat), které využívají vyhrazených okruhů bod — bod nebo omezené sítě a vyžadují specializované technické a programové vybavení (hardware a software). Vzhledem k většímu počtu nově plánovaných propojení bylo považováno za vhodné přejít na síťovou architekturu a přijmout mezinárodní telekomunikační normy umožňující, díky snížení počtu spojení v každém středisku, účinnější využití nákladů a používání standardního, běžně dostupného technického a programového vybavení. Tato norma Eurocontrol dává oficiální formu krátkodobému ICD a rozšiřuje jej. Dokument ST-ICD byl přepracován tak, aby přesněji definoval technické parametry, což zlepší kompatibilitu a navíc může sloužit jako základ budoucích dokumentů ICD odpovídajících na vývoj požadavků na výměna dat o letu (FDE), včetně širšího užívání sdílených sítí a zavedení nových standardů nižších vrstev. Tato norma Eurocontrol nabízí minimální soubor funkcí, které mohou být s minimálními změnami podporovány současnými zařízeními OLDI využívajícími buď okruh bod — bod, nebo doporučení X.25 Mezinárodního poradního výboru pro telegrafii a telefonii (CCITT — Comité consultatif international télégraphique et téléphonique) z roku 1980 nebo později paketovou přepojovací síť. Za účelem nákupu může být určeno více možností. Tento dokument ICD nebrání širšímu pojetí v rámci dvoustranných dohod. Zařízení, u kterých je kromě nebo namísto protokolu popsaného v tomto dokumentu požadováno provozování jiných aplikačních protokolů, mohou buď požádat o změnu současného protokolu, nebo oddělit svůj protokol pomocí odlišného virtuálního spoje. 2. OBLAST PŮSOBNOSTI 2.1 Tato norma Eurocontrol definuje rozhraní přenosu dat pro výměnu zpráv letových dat mezi oblastními řídícími středisky (ACC). Je předložena ve formě profilu propojení otevřených systémů (OSI — Open Systems Interconnection), jak je definován v technické zprávě (TR — Technical Report) 10000-2 Mezinárodní organizace pro normalizaci / Mezinárodní elektrotechnické komise (ISO/IEC — International Organisation for Standardisation/International Electrotechnical Commission) [odkaz 3]. Profil zahrnuje nižší (profil T) i horní vrstvy (profil A). 2.2 Tato norma Eurocontrol platí v následujících případech: - podpora OLDI, jak je popsaná v normě Eurocontrol č. 001-92, verze 1, - podpora přenosu zpráv OLDI z ACC do systémů centrální jednotky uspořádání toku letového provozu (CFMU). 2.3 Tato norma platí pro spojení používající buď: - okruh bod — bod pronajatých linek, nebo - okruh bod — bod veřejné komutované telefonní sítě (PSTN), nebo - paketovou přepojovací síť nebo propojené paketové přepojovací sítě, které poskytují rozhraní odpovídající doporučení X.25 výboru CCITT z roku 1980 nebo později. POZNÁMKY: 1. Uspořádání spojení mezi systém zpracovávání letových plánů (FPSS) je vyobrazeno na obr. 1. 2. Obr. 1 nezobrazuje možná záložní spojení, jako je PSTN, pro která jsou pokyny uvedeny v příloze H. +++++ TIFF +++++ Obr. 1Uspořádání rozhraní 2.4 Podrobný rozbor bezpečnostních otázek uvedeného rozhraní přenosu dat není do této normy zahrnut. Základní opatření jsou však určena v příloze a další pokyny lze nalézt v příloze H této normy Eurocontrol. 3. ODKAZY 3.1 Úvod Následující dokumenty a normy obsahují předpisy, které se — prostřednictvím odkazů v tomto textu — stávají předpisy této normy Eurocontrol. V době zveřejnění této normy Eurocontrol byly v platnosti zde uvedené verze referenčních dokumentů a norem. Jakékoli opravy uvedených dokumentů Mezinárodní organizace pro civilní letectví (ICAO) musí být neprodleně vzaty v úvahu pro aktualizaci této normy Eurocontrol. Oprava ostatních referenčních dokumentů netvoří součást předpisů této normy Eurocontrol, dokud a pokud nejsou oficiálně přezkoumány a začleněny do této normy Eurocontrol. V případě konfliktu mezi požadavky této normy Eurocontrol a obsahem dalších uvedených dokumentů, na které se odkazuje, má přednost tato norma Eurocontrol. 3.2 Odkazy 1. Doporučení X.25 ITU-T (1993) (Oprava 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit (Rozhraní mezi koncovým datovým zařízením (DTE) a ukončujícím datovým zařízením (DCE) pro koncová zařízení pracující v paketovém módu A připojená k veřejné datové síti vyhrazeným spojem). 2. ISO/IEC TR 10000-1:1992, Information technology — Framework and taxonomy of International Standardized Profiles (Informační technologie — rámec a taxonomie mezinárodních standardizovaných profilů): — část 1: Rámec (druhá verze). 3. ISO/IEC TR 10000-2:1994, Information technology — Framework and taxonomy of International Standardized Profiles (Informační technologie — rámec a taxonomie mezinárodních standardizovaných profilů) — část 2: Principles and Taxonomy for OSI Profiles (Principy a taxonomie pro profily OSI) (třetí verze). 4. Doporučení X.21 ITU-T (1992) (Oprava 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks (Rozhraní mezi koncovým datovým zařízením (DTE) a ukončujícím datovým zařízením (DCE) pro souběžné operace ve veřejných datových sítích). 5. Doporučení X.21bis CCITT (1988), Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems (Užívání koncových datových zařízení (DTE) navržených pro propojení se synchronními modemy řady V). 6. ISO/IEC 7776:1994, Telecommunications and information exchange between systems — High-level data link control procedures — Description of the X.25 LAPB-compatible DTE Data Link procedures (Informační technologie — telekomunikace a výměna dat mezi systémy - postupy vyššího řízení datových spojů — popis postupů datových spojů DTE X.25 slučitelných s LAPB), (druhá verze). 7. ISO/IEC 8208:1993, Information Technology — Data communications — X.25 Packet Layer Protocol for Data Terminal Equipment (Informační technologie - přenos dat — protokol paketové vrstvy X.25 pro koncová datová zařízení), (třetí verze). 8. ISO/IEC ISP 10609-9:1992, Information technology — International Standardized Profiles TB, TC, TD and TE — Connection-mode Transport Service over Connection-mode Network Service - Part 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a packet-switched data network using virtual calls (Informační technologie — mezinárodní normalizované profily TB, TC, TD a TE - přenosová služba ve spojovacím režimu pomocí síťových služeb ve spojovacím režimu - část 9: Požadavky na síťovou, datovou a fyzickou vrstvu závislé na typu dílčí sítě pro trvalý přístup na paketovou datovou síť používající virtuální volání). 9. ISO/IEC 7498-1:1994, Information technology — Open Systems Interconnection — Basic Reference Model: The Basic Model (Informační technologie — propojení otevřených systémů — základní referenční vzor: základní vzor), (druhá verze). 10. ISO/IEC 8348:1993, Information technology — Open Systems Interconnection — Network Service Definition (Informační technologie — propojení otevřených systémů — definice síťové služby), (první verze). 11. ISO/IEC 8072:1994, Information technology — Open Systems Interconnection — Transport service definition (Informační technologie — propojení otevřených systémů - definice přenosové služby), (druhá verze). 12. ISO/IEC 8878:1992, Information Technology — Telecommunications and information exchange between systems — Use of X.25 to provide the OSI connection-mode Network Service (Informační technologie — telekomunikace a výměna dat mezi systémy — použití X.25 pro poskytování síťové služby propojení otevřených systémů (OSI) ve spojovacím režimu), (druhá verze). 13. Norma Eurocontrol OLDI, č. 001-92, verze 1, 1992. 14. ISO/IEC 9646-1:1994, Information technology — Open Systems Interconnection — Conformance testing methodology and framework — Part 1: General concepts (Informační technologie — propojení otevřených systémů - postup a rámec pro zkoušky shody s požadavky — část 1: celkové pojetí), (druhá verze). 15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan (Eurocontrol, sekce systémů řízení vyšší oblasti (UAC) Maastricht, dokument řízení rozhraní pro výměnu letových dat, část 1, plán zkoušek součinnosti), verze 1.0, datováno 10. května 1996. 16. Eurocontrol FDE ICD Part 1 — Reliability, Availability and Security — Technical Report (Eurocontrol, dokument řízení rozhraní pro výměnu letových dat, část 1 — spolehlivost, dostupnost a zabezpečení — technická zpráva), verze 1.0, datováno 20. dubna 1997. 17. Doporučení ITU-T X.32 (1993) (Oprava 1), Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network (Rozhraní mezi DTE a DCE pro koncová zařízení pracující v paketovém režimu s přístupem k veřejným paketovým datům prostřednictvím veřejné komutované telefonní sítě (PSTN) nebo digitální sítě integrovaných služeb (ISDN) nebo veřejné datové sítě s přepojováním okruhů (CSPDN). 18. Doporučení ITU-T E.164 (1991) (Oprava 1) Numbering plan for the ISDN era (Plán číslování pro epochu ISDN). 19. Doporučení ITU-T X.75 (1993) (Oprava 1), Packet-switched signalling system between public network providing data transmission service (Paketový signalizační systém mezi veřejnými sítěmi zajišťujícími službu přenosu dat). 20. Doporučení ITU-T X.121 (1993), International numbering plan for public data networks (Mezinárodní plán číslování pro veřejné datové sítě). 4. DEFINICE, SYMBOLY A ZKRATKY 4.1 Definice 4.1.1 Pro účely této normy Eurocontrol se rozumí: "profilem" : soubor jednoho nebo více základních norem a - kde je to příslušné — určení vybraných tříd, podsouborů, voleb a parametrů základních norem nezbytných pro provedení konkrétní funkce [odkaz 2]. "seznamem požadavků na profil" : (PRL — Profile Requirements List) požadavky na profily jsou vyjádřeny ve formě požadavků na shodu a jsou uspořádány do tabulky [odkaz 2]. "profilem T" : profil přenosu poskytující přenosovou službu ve spojovacím režimu [odkaz 3]. "profilem A" : profil aplikace požadující přenosovou službu ve spojovacím režimu [odkaz 3]. "Prohlášením o shodě provedení protokolu" : (PICS — Protocol Implementation Conformance Statement): Prohlášení, kterým dodavatel systému OSI vyhlašuje, jaké funkce jsou zavedeny pro daný protokol OSI [odkaz 14]. 4.2 Symboly a zkratky Pro účely této normy se používají následující symboly a zkratky: ACC | Area Control Centre — Oblastní řídící středisko | AFI | Authority and Format Identifier — Identifikátor subjektu a formátu | ASCII | American Standard Code for Information Interchange — Americký normalizovaný kód pro výměnu informací | ATC | Air Traffic Control — Řízení letového provozu | ATCC | Air Traffic Control Centre — Středisko řízení letového provozu | CAUTRA | Coordinateur Automatique du Trafic Aérien — Automatický koordinátor letového provozu | CCITT | Comité consultatif international télégraphique et téléphonique (now ITU-T) — Mezinárodní poradní výbor pro telegrafii a telefonii (nyní ITU-T) | CFMU | Central Flow Management Unit — Centrální jednotka uspořádání toku letového provozu | CUG | Closed User Group — Uzavřená skupina uživatelů | DCE | Data Circuit-terminating Equipment — Ukončující datové zařízení (DCE) | DCFS | Digital Communications Terminal System — Koncový systém digitálních spojení | DSP | Domain Specific Part — Část specifická pro doménu | DTE | Data Terminal Equipment — Koncové datové zařízení | DÜV | Datenübertragungs- und Verteilungssystem — Systém přenosu a distribuce dat | FDE | Flight Data Exchange — Výměna dat o letu | FEP | Front-End Processor — Zařízení na předřazené zpracování | FPDE | Flight Plan related Data Exchange — Výměna dat letového plánu | FPPS | Flight Plan Processing System — Systém zpracovávání letových plánů | ICAO | International Civil Aviation Organisation — Mezinárodní organizace pro civilní letectví | ICD | Interface Control Document — Dokument definice rozhraní | IDI | Initial Domain Identifier — Identifikátor počáteční domény | IDP | Initial Domain Part — Počáteční část domény | IEC | International Electrotechnical Commission — Mezinárodní elektrotechnická komise | INTER-CAUTURA | INTERCAUTURA protocol — Protokol INTERCAUTURA | ISO | International Organization for Standardization — Mezinárodní organizace pro normalizaci | ITU-T | International Telecommunication Union — Telecommunication Standardization Sector — Mezinárodní telekomunikační unie — sekce pro normalizaci | ISDN | Integrated Services Digital Network — Digitální síť integrovaných služeb | LAPB | Link Access Procedure Balanced — Postup symetrického přístupu ke spoji | LSB | Least Significant Bit — Nejnižší platný bit | M, m | Mandatory — Povinný | MSB | Most Significant Bit — Nejvyšší platný bit | MT | Message Transfer — Přenos zprávy | NA | Not Applicable — Nepoužije se | NS | Network Service — Síťová služba | NSAP | Network Service Access Point — Přístupový bod síťové služby | NSDU | Network Service Data Unit — Datová jednotka síťové služby | O, O.<n> | Optional, where <n> is a numeral for referencing — Nepovinné, kde <n> je číslo odkazu | o, o.<n> | Optional, where <n>is a numeral for referencing — Nepovinné, kde <n> je číslo odkazu | OLDI | On-Line Data Interchange — Výměna dat on-line | OSI | Open Systems Interconnection — Propojení otevřených systémů | PICS | Protocol lmplementation Conformance Statement — Prohlášení o shodě provedení protokolu | PLP | Packet Layer Protocol — Protokol paketové vrstvy | PRL | Profile Requirements List — Seznam požadavků na profil | PSTN | Public Switched Telephone Network — Veřejná komutovaná telefonní síť | ST-ICD | Short Term Interface Control Document — Dokument definující rozhraní — krátkodobý | SUT | System Under Test — Kontrolovaný systém | T<x> | Timer (where <x> is a single or double letter for referencing) — Časovač (kde <x> je odkaz o jednom nebo dvou písmenech) | TA | Terminal Adaptor — Koncový adaptér | TSDU | Transport Service Data Unit — Datová jednotka přenosové služby | TPDU | Transport Protocol Data Unit — Datová jednotka přenosového protokolu | TR | ISO Technical Report — Technická zpráva ISO | X | Prohihited — Zakázáno | X | Excluded — vyjmuto | <item>: | Conditional Item (dependent on value of item) — Podmíněná položka (závisí na hodnotě položky) | 4.3 Zápis 4.3.1 Pro účely této normy Eurocontrol jsou binární hodnoty nebo posloupnosti bitů zapsány v hexadecimální soustavě a značí se "d"H, kde písmeno d představuje číslici nebo posloupnost hexadecimálních číslic. 4.3.2 Pro účely této normy Eurocontrol se hexadecimální zápis posloupnosti bitů skládá ze skupin 4 bitů od nejvyššího platného bitu (MSB) k nejnižšímu platnému bitu (LSB). POZNÁMKA: Pokud není v mezinárodních normách, na které se odkazuje, určeno jinak, posloupnost bitů se přenáší od nejvyššího platného bitu k nejnižšímu platnému bitu. 4.3.3 Pro účely této normy se stav podpory ustanovení základní normy nebo této normy Eurocontrol musí uvádět velkými písmeny (např. M, O, O.< n >, X). Přesný význam každého symbolu stavu je popsán v přílohách této normy Eurocontrol před jeho použitím. 4.3.4 Pro účely definování profilu FDE ICD, část 1, se v této normě Eurocontrol stav podpory ustanovení základní normy nebo této normy Eurocontrol musí uvádět malými písmeny (např. m, o, o.< n >, x). POZNÁMKA: Výsledkem je podrobnější rozlišení ustanovení základních norem, které jsou podmíněné, nepovinné nebo závislé na hodnotě (viz E.3.1). 5. TECHNICKÝ PŘEHLED 5.1 Sada protokolů POZNÁMKA: Sada protokolů pro profil této normy Eurocontrol je znázorněna na obr. 2. Zobrazení umísťuje protokoly do rámce základního referenčního vzoru OSI [odkaz 9] přiřazením sady protokolů k odpovídajícím vrstvám OSI. Sada protokolů však představuje specifikaci pro systémy předcházející OSI a nepodporuje mnohé z funkcí, které jsou umožněny v protokolech OSI odpovídajících vrstev OSI. +++++ TIFF +++++ Obr. 2Sada protokolů profilu 5.2 Struktura profilu POZNÁMKY: 1. Jak ukazuje obr. 2, sada protokolů profilu kombinuje několik protokolů nižších vrstev, z nichž pouze protokol paketové vrstvy X.25 (PLP) [odkaz 1] a protokoly, které ho podporují, X.21 [odkaz 4] a X.21 bis [odkaz 5], jsou definovány ve stávajících normách ISO/IEC a normách Mezinárodní telekomunikační unie — sekce pro normalizaci (ITU-T). Ostatní protokoly horní vrstvy jsou definovány v přílohách (A, B a C) této normy Eurocontrol. 2. Požadavky na shodu pro uvedený profil mohou odkazovat na tyto specifikace, stejně jako na jiné externí normy, a jsou uvedeny v oddílu 6. Podrobné požadavky jsou uvedeny ve formě tabulek seznamů požadavků na profil (PRL) (příloha E) a ve formulářích prohlášení o shodě provedení protokolu (PICS) (formuláře pro protokoly definované v přílohách jsou uvedeny v příloze D). Použití těchto seznamů PRL a formulářů PICS ve vývoji a/nebo zpracovávání je vysvětleno v příloze E. 5.3 Vztah k předchozím verzím specifikací POZNÁMKY: 1. Tento profil je založen na dokumentu ST-ICD vyvinutém bývalou technickou sekcí OLDI. Protokoly a paketové formáty definované v této normě Eurocontrol jsou slučitelnou podskupinou protokolů a formátů uvedených v dokumentu ST-ICD s tím rozdílem, že tato norma Eurocontrol definuje podrobněji požadavky použití X.25 PLP, obsahuje povinné použití M-bitu a opravuje nejednotnou specifikaci hodnoty identifikátoru subjektu a formátu (AFI) v adrese přístupového bodu síťové služby (NSAP). 2. Hlavní změna stylu této normy Eurocontrol se týká struktury specifikace ICD. Protokol přenosu zpráv (příloha A) je oddělen od profilu T, který jej podporuje. To usnadňuje použití jiných profilů T, jestliže je to nutné pro podporu vývoje požadavků FDE. 3. Ty části specifikace ST-ICD, které se týkají řízení virtuálních okruhů X.25 a vymezují zprávy aplikace se nyní nacházejí v protokolu záhlaví zprávy (příloha B), který představuje minimální přenosovou vrstvu pro výměnu letových dat (FDE). 6. POŽADAVKY NA PROFIL 6.1 Požadavky na shodu 6.1.1 Provedení činící si nárok na shodu s touto specifikací musí splňovat požadavky uvedené v následujících oddílech 6.2 a 6.3. 6.1.2 Nárok na shodu musí být podpořen prohlášením o shodě provedení protokolu (PICS), jak je popsáno v přílohách D a E. 6.2 Požadavky na horní vrstvu 6.2.1 Vyhovující provedení musí splňovat požadavky základních norem uvedených v příloze A. 6.2.2 Vyhovující provedení musí splňovat omezení uvedená v seznamu požadavků na profil v příloze E.7. 6.3 Požadavky na nižší vrstvu 6.3.1 Požadavky na přenosovou vrstvu 6.3.1.1 Vyhovující provedení musí splňovat požadavky základních norem uvedených v příloze B. 6.3.1.2 Vyhovující provedení musí splňovat omezení uvedená v seznamu požadavků na profil v příloze E.8.1. 6.3.1.3. Vyhovující provedení musí splňovat požadavky na podporu velikostí datové jednotky přenosové služby (TSDU) až do 4097 oktetů včetně. POZNÁMKA: První oktet TSDU odpovídá poli záhlaví zprávy viz A.4.10 a B.4.4), ož ponechává maximálně 4096 oktetů pro data uživatele. 6.3.2 Požadavky na síťovou vrstvu 6.3.2.1 Vyhovující provedení musí splňovat požadavky norem ISO/IEC 8208 [odkaz 7] v souladu s mapováním protokolů uvedeným v příloze C. 6.3.2.2 Vyhovující provedení musí splňovat omezení uvedená v seznamu požadavků na profil v příloze E.8.2. 6.3.2.3 Jestliže je podporován provoz typu DTE-DTE, vyhovující provedení musí být schopno konfigurace výběru úlohy koncového datového zařízení (DTE) nebo ukončujícího datového zařízení (DCE) pro provoz typu DTE-DTE pomocí mechanizmů správy systémů. 6.3.2.4 Vyhovující provedení musí být v obou úlohách definovaných v bodě 6.3.2.3 schopno zahájit spojení v souladu se specifikacemi uvedenými v příloze C, tj. protokol je zcela symetrický. POZNÁMKA: Některá již existující provedení založená na ST-ICD nemusí být schopna zahájit síťová spojení v souladu s protokolem přílohy C. 6.3.2.5 Vyhovující provedení musí po určitý časový interval umožňovat službu nestandardní implicitní velikosti paketů s hodnotou 256 pro oba směry přenosu. 6.3.2.6 Vyhovující provedení musí používat adresy NSAP, jak jsou definovány v příloze C. 6.3.2.7 Vyhovující provedení musí v paketech CALL REQUEST (Žádost o spojení) CALL ACCEPTED (volání akceptováno) a v datových paketech nastavit D-bit (bit potvrzení předání na 0 (nulu)). POZNÁMKA: Nastavení D-bitu na nulu v paketech CALL REQUEST (Žádost o spojení) CALL ACCEPTED (volání akceptováno) má za následek nepoužití potvrzení předání. 6.3.3 Požadavky na Vrstvu datových spojení 6.3.3.1 Vyhovující provedení musí splnit požadavky na shodu s normou ISO/IEC 7776 [odkaz 6] pro protokol jednoduchého spoje s postupem symetrického přístupu ke spoji (LAPB). 6.3.3.2 Vyhovující provedení musí splňovat také omezení uvedená v seznamu požadavků na profil v příloze E.8.3. 6.3.4 Požadavky na fyzickou vrstvu Vyhovující provedení musí splňovat požadavky na shodu s normou ISO/IEC ISP 10609-9, větou 7 [odkaz 8]. 7. ZKUŠEBNÍ POSTUPY POZNÁMKY: 1. Přístup k provádění zkoušek shody provedení s touto specifikací je přehledně uveden v příloze F. 2. Použití formulářů PRL a PICS stanovených touto specifikací pro doložení shody je přehledně uvedeno v příloze E. --------------------------------------------------