32000R2082

Rozporządzenie Komisji (WE) nr 2082/2000

z dnia 6 września 2000 r.

przyjmujące normy Eurocontrolu i zmieniające dyrektywę 97/15/WE przyjmującą normy Eurocontrolu oraz zmieniającą dyrektywę Rady 93/65/EWG

KOMISJA WSPÓLNOT EUROPEJSKICH,

uwzględniając Traktat ustanawiający Wspólnotę Europejską,

uwzględniając dyrektywę Rady 93/65/EWG z dnia 19 lipca 1993 r. w sprawie definicji i korzystania ze zgodnych specyfikacji technicznych dla zamówień na sprzęt i systemy zarządzania ruchem powietrznym [1], w szczególności jego art. 3,

uwzględniając dyrektywę Komisji 97/15/WE z dnia 25 marca 1997 r. przyjmującą normy Eurocontrolu oraz zmieniającą dyrektywę Rady 93/65/EWG w sprawie definicji i korzystania ze zgodnych specyfikacji technicznych dla zamówień na sprzęt i systemy zarządzania ruchem powietrznym [2],

a także mając na uwadze, co następuje:

(1) Dyrektywa 97/15/WE przyjęła normę Eurocontrolu dla bezpośredniej wzajemnej wymiany danych (OLDI), wersja 1.0 oraz normę Eurocontrolu dla prezentacji danych dotyczących służb ruchu lotniczego (ADEXP), wersja 1.0.

(2) Eurocontrol przyjał bardziej aktualną wersję wyżej wspomnianych norm na przykład OLDI wersja 2.2 oraz ADEXP wersja 2.0, a także nową normę Eurocontrolu zwaną Wymiana danych lotu — Dokument kontroli interfejsu.

(3) Zmiany norm Eurocontrolu wchodzące w zakres dyrektywy 93/65/EWG przyczyniają się do harmonizacji krajowych systemów kontroli ruchu lotniczego Państw Członkowskich, w szczególności przekazywania lotów między centrami kontroli ruchu lotniczego (OLDI) i zarządzania przepływem ruchu lotniczego (ADEXP) oraz komunikacji między krajowymi systemami (FDE-ICD).

(4) Wersja 2.2 OLDI oraz 2.0 ADEXP zastępuje poprzednie wersje obecnie w obiegu zgodnie z przepisami art. 1 dyrektywy 97/15/WE i dlatego ten artykuł musi zostać uchylony.

(5) Przepisy niniejszego rozporządzenia są zgodne z opinią komitetu utworzonego zgodnie z dyrektywą 93/65/EWG,

PRZYJMUJE NINIEJSZE ROZPORZĄDZENIE:

Artykuł 1

W takim zakresie, w jakim potrzebne są do stosowania zintegrowanego europejskiego systemu kontroli ruchu lotniczego, obowiązkowe elementy specyfikacji Eurocontrolu zawarte w niniejszym dokumencie normy Eurocontrolu są przyjęte w ramach dyrektywy 93/65/EWG:

- norma Eurocontrolu dla bezpośredniej wzajemnej wymiany danych (OLDI), wersja 2.2 (Eurocontrol, dokument odniesienia DPS.ET1.ST06-STD), którego tekst jest zawarty w załączniku I do niniejszego rozporządzenia,

- norma Eurocontrolu dla wymiany danych służb ruchu lotniczego (ADEXP), wersja 2.0 (Eurocontrol, dokument odniesienia DPS.ET1.ST09-STD), którego tekst jest zawarty w załączniku II do niniejszego rozporządzenia,

- norma Eurocontrolu dla "Wymiany danych lotu — Dokumentu kontroli interfejsu" (FDE-ICD), wersja 1.0 (Eurocontrol, dokument odniesienia COM.ET1.ST12-STD), którego tekst jest zawarty w załączniku III niniejszego rozporządzenia.

Artykuł 2

Artykuł 1 dyrektywy 97/15/WE uchyla się.

Artykuł 3

Niniejsze rozporządzenie wchodzi w życie trzeciego dnia po jego opublikowaniu w Dzienniku Urzędowym Wspólnot Europejskich.

Niniejsze rozporządzenie wiąże w całości i jest bezpośrednio stosowane we wszystkich Państwach Członkowskich.

Sporządzono w Brukseli, dnia 6 września 2000 r.

W imieniu Komisji

Loyola De Palacio

Wiceprzewodniczący

[1] Dz.U. L 187 z 29.7.1993, str. 52.

[2] Dz.U. L 95 z 10.4.1997, str. 16.

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

ZAŁĄCZNIK I

BEZPOŚREDNIA WZAJEMNA WYMIANA DANYCH (OLDI) WERSJA 2.2

(Eurocontrol, dokument odniesienia DPS.ET1.ST06-STD)

SPIS TREŚCI

UWAGA O PRAWACH AUTORSKICH … PRZEDMOWA … 1. WPROWADZENIE …

1.1. Cel …

1.2. Zakres …

2. ODNIESIENIA …

3. DEFINICJE, SYMBOLE, SKRÓTY …

3.1. Definicje …

3.2. Symbole i skróty …

4. WYMAGANIA OGÓLNE …

4.1. Wprowadzenie …

4.2. Wymogi dotyczące systemu przetwarzania danych lotu …

4.2.1. Baza danych lotu …

4.2.2. Działania w czasie rzeczywistym …

4.2.3. Możliwość komunikowania danych …

4.2.4. Funkcje stosowania …

4.2.5. Interfejs człowiek-maszyna (HMI) …

4.2.6. Wprowadzenie komunikatów …

4.2.7. Odbieranie komunikatów …

4.3. Uaktualnianie z danych dozorowania …

4.4. Rejestrowanie danych OLDI …

4.4.1. Treść …

4.4.2. Udogodnienia …

4.5. Dostępność, wiarygodność, bezpieczeństwo danych oraz integralność danych …

4.5.1. Dostępność …

4.5.2. Wiarygodność …

4.5.3. Bezpieczeństwo danych …

4.5.4. Integralność danych …

4.6. Ocena operacyjna …

4.6.1. Okres oceny …

4.6.2. Termin wprowadzenia operacyjnego …

5. KATEGORIE KOMUNIKATÓW …

5.1. Przepisy ogólne …

5.1.1. Cel …

5.1.2. Kategorie komunikatów …

5.2. Czasy transakcji …

5.2.1. Warunki czasu transakcji …

5.3. Klasyfikacja komunikatów i ich podział na kategorie …

5.3.1. Klasyfikacja komunikatów — obowiązkowe i uzupełniające …

5.3.2. Podział komunikatów na kategorie …

6. PROCEDURA PODSTAWOWA — KOMUNIKATY OBOWIĄZKOWE …

6.1. Przepisy ogólne …

6.1.1. Opis wymogów …

6.1.2. Wdrożenie …

6.2. Komunikat informacji o przecięciu granicy (ABI) …

6.2.1. Cel komunikatu ABI …

6.2.2. Treść komunikatu …

6.2.3. Zasady stosowania …

6.2.4. Potwierdzenie ABI …

6.2.5. Przykłady …

6.3. Komunikat aktywacji (ACT) …

6.3.1. Cel komunikatu ACT …

6.3.2. Treść komunikatu …

6.3.3. Zasady stosowania …

6.3.4. Potwierdzenie ACT …

6.3.5. Przykłady …

6.4. Komunikat potwierdzenia logicznego (LAM) …

6.4.1. Cel komunikatu LAM …

6.4.2. Treść komunikatu …

6.4.3. Zasady stosowania …

6.4.4. Potwierdzenie LAM …

6.4.5. Przykłady …

7. PROCEDURA PODSTAWOWA — KOMUNIKATY UZUPEŁNIAJĄCE …

7.1. Przepisy ogólne …

7.1.1. Opis wymagań …

7.1.2. Wdrażanie …

7.2. Komunikat wstępnej aktywacji (PAC) …

7.2.1. Cel komunikatu PAC …

7.2.2. Treść komunikatu …

7.2.3. Zasady stosowania …

7.2.4. Potwierdzenie PAC …

7.2.5. Przykłady …

7.3. Komunikat weryfikacji (REV) …

7.3.1. Cel komunikatu weryfikacji REV …

7.3.2. Treść komunikatu …

7.3.3. Zasady stosowania …

7.3.4. Potwierdzenie REV …

7.3.5. Przykłady …

7.4. Komunikat dla odwołania koordynacji (MAC) …

7.4.1. Cel komunikatu MAC …

7.4.2. Treść komunikatu …

7.4.3. Zasady stosowania …

7.4.4. Potwierdzenie MAC …

7.4.5. Przykłady …

7.5. Komunikat przyznania oznaczenia kodowego (COD) …

7.5.1. Cel komunikatu COD …

7.5.2. Treść komunikatu …

7.5.3. Zasady stosowania …

7.5.4. Potwierdzenie COD …

7.5.5. Przykłady …

7.6. Komunikat informacji (INF) …

7.6.1. Cel komunikatu (INF) …

7.6.2. Treść komunikatu …

7.6.3. Zasady stosowania …

7.6.4. Potwierdzenie INF …

7.6.5. Przykłady …

8. PROCEDURA DIALOGU — KOORDYNACJA …

8.1. Przepisy ogólne …

8.1.1. Wstęp …

8.1.2. Filtr …

8.1.3. Sekwencja komunikatu …

8.1.4. Jednoczesne stosowanie komunikatów …

8.1.5. Obsługiwanie odrzucenia …

8.1.6. Operacyjna odpowiedź przerwy …

8.1.7. Stosowanie …

8.2. Komunikat aktywacji (ACT) …

8.2.1. Cel komunikatu ACT …

8.2.2. Treść komunikatu …

8.2.3. Zasady stosowania …

8.2.4. Potwierdzenie ACT …

8.3. Komunikat przedłożenia propozycji aktywacji (RAP) …

8.3.1. Cel komunikatu RAP …

8.3.2. Treść komunikatu …

8.3.3. Zasady stosowania …

8.3.4. Potwierdzenie komunikatu RAP …

8.3.5. Odpowiedź operacyjna na RAP …

8.3.6. Przykłady …

8.4. Komunikat weryfikacji (REV) …

8.4.1. Cel komunikatu weryfikacji REV …

8.4.2. Treść komunikatu …

8.4.3. Zasady stosowania …

8.4.4. Potwierdzenie komunikatu REV …

8.4.5. Operacyjna odpowiedź na REV …

8.5. Komunikat przedłożenia propozycji weryfikacji (RRV) …

8.5.1. Cel komunikatu RRV …

8.5.2. Treść komunikatu …

8.5.3. Zasady stosowania …

8.5.4. Potwierdzenie RRV …

8.5.5. Operacyjna odpowiedź na RRV …

8.5.6. Przykłady …

8.6. Komunikat oczekiwania (SBY) …

8.6.1. Cel komunikatu SBY …

8.6.2. Treść komunikatu …

8.6.3. Zasady stosowania …

8.6.4. Potwierdzenie SBY …

8.6.5. Przykłady …

8.7. Komunikat akceptacji (ACP) …

8.7.1. Cel komunikatu akceptacji ACP …

8.7.2. Treść komunikatu …

8.7.3. Zasady stosowania …

8.7.4. Potwierdzenie ACP …

8.7.5. Przykłady …

8.8. Komunikat koordynacji (CDN) …

8.8.1. Cel komunikatu CDN …

8.8.2. Treść komunikatu …

8.8.3. Zasady stosowania …

8.8.4. Potwierdzenie CDN …

8.8.5. Odpowiedź operacyjna na CDN …

8.8.6. Przykłady …

8.9. Komunikat odrzucenia koordynacji (RJC) …

8.9.1. Cel komunikatu RJC …

8.9.2. Treść komunikatu …

8.9.3. Zasady stosowania …

8.9.4. Potwierdzenie RJC …

8.9.5. Przykłady …

9. PROCEDURA DIALOGU — PRZEKAZ ŁĄCZNOŚCI …

9.1. Przepisy ogólne …

9.1.1. Wstęp …

9.1.2. Sekwencja komunikatu …

9.1.3. Przekaz łączności …

9.2. Komunikat inicjowania przekazu (TIM) …

9.2.1. Cel komunikatu TIM …

9.2.2. Treść komunikatu …

9.2.3. Zasady stosowania …

9.2.4. Potwierdzenie TIM …

9.2.5. Przykłady …

9.3. Komunikat danych uzupełniających (SDM) …

9.3.1. Cel komunikatu SDM …

9.3.2. Treść komunikatu …

9.3.3. Zasady stosowania …

9.3.4. Potwierdzenie SDM …

9.3.5. Przykład …

9.4. Propozycja przekazania lotu (HOP) …

9.4.1. Cel komunikatu HOP …

9.4.2. Treść komunikatu …

9.4.3. Zasady stosowania …

9.4.4. Potwierdzenie HOP …

9.4.5. Przykład …

9.5. Komunikat żądania zmiany częstotliwości (ROF) …

9.5.1. Cel komunikatu ROF …

9.5.2. Treść komunikatu …

9.5.3. Zasady stosowania …

9.5.4. Potwierdzenie ROF …

9.5.5. Przykład …

9.6. Komunikat zmiany częstotliwości (COF) …

9.6.1. Cel komunikatu COF …

9.6.2. Treść komunikatu …

9.6.3. Zasady stosowania …

9.6.4. Potwierdzenie COF …

9.6.5. Przykłady …

9.7. Komunikat ręcznego przejęcia łączności (MAS) …

9.7.1. Cel komunikatu MAS …

9.7.2. Treść komunikatu …

9.7.3. Zasady stosowania …

9.7.4. Potwierdzenie MAS …

9.7.5. Przykład …

ZAŁĄCZNIK A (NORMATYWNY) ZASADY WPROWADZANIA DANYCH … ZAŁĄCZNIK B (NORMATYWNY) WYMOGI DOTYCZĄCE PRZETWARZANIA POSZCZEGÓLNYCH TRAS … ZAŁĄCZNIK C (INFORMACYJNY) FAZY PROCEDURY DIALOGU (POZIOM 1 SYSCO) — KOLEJNOŚĆ KOMUNIKATU … UWAGA O PRAWACH AUTORSKICH

Niniejszy dokument został opracowany przez Agencję Eurocontrol.

Prawa autorskie należą do Agencji Eurocontrol.

Treść niniejszego dokumentu lub jakakolwiek jego część jest udostępniona przedstawicielom Państw Członkowskich, ale kopiowanie lub ujawnienie innym podlega uprzedniemu pisemnemu wyrażeniu zgody przez Agencję Eurocontrol.

PRZEDMOWA

1. Organ upoważniony

Norma Eurocontrolu dla bezpośredniej wzajemnej wymiany danych (OLDI), wersja 2.2 została opracowana przez Dyrekcję Rozwoju (DED) europejskiego programu harmonizacji i integracji kontroli ruchu lotniczego (EATCHIP) w Eurocontrolu, która jest również odpowiedzialna za uaktualnianie niniejszego dokumentu. Wszystkie uwagi oraz zapytania należy adresować do Dyrekcji Generalnej Eurocontrolu, ulica de la Fusée, 96, B-1130 Bruksela, do wydziału DED-2.

2. Powiązanie z dokumentem Program pracy EATCHIP

Niniejsza norma wynika ze specjalnego zadania DPS.ET1.ST06 systemów przetwarzania danych zarządzania ruchem lotniczym (DPS) domeny EATCHIP, jak określono w dokumencie Program pracy (EWPD) wersja 2.0, z dnia 30/09/94.

3. Zatwierdzenie i poprawki

Niniejsza norma była przedmiotem następującej procedury zatwierdzenia określonej w dyrektywach dotyczących normalizacji Eurocontrolu:

- zatwierdzenie przez wymogi operacyjne EATCHIP i zespół przetwarzanie danych ATM (ODT) drogą korespondencyjną;

- konsultacje wszystkich państw ECAC za pośrednictwem ich przedstawicieli przed Komitetem Zarządzania lub Komitetem Dyrektorów EATCHIP;

- zatwierdzenie przez Komitet Dyrektorów EATCHIP i Komitet Zarządzania;

- przyjęcie przez Stałą Komisję.

Przepisy niniejszej normy wchodzą w życie po przyjęciu przez Stałą Komisję.

W celu spełnienia wymogów związanych z ewolucją procedur kontroli ruchu lotniczego (ATC) zmiany i uzupełnienia mogą być zaproponowane poprzez ODT do dyskusji i ewentualnego zatwierdzenia. Wymogi będą wdrożone albo w formie poprawki, albo kolejnej wersji dokumentu, i przedstawione dla zaaprobowania i zatwierdzenia zgodnie z określonymi procedurami.

4. Praktyki redakcyjne

W celu wskazania statusu każdego stwierdzenia stosowana jest następująca praktyka: elementy normatywne zostały wydrukowane czcionką zwykłą; elementy zalecane zostały wydrukowane kursywą, status jest wskazywany przez poprzedzenie wyrazem Zalecenie.

Następująca praktyka redakcyjna była poprzedzona w formie pisemnej specyfikacji: dla elementów normatywnych użyty jest czasownik operacyjny "musi", natomiast dla elementów zalecanych czasownik operacyjny "powinien".

Uwagi są drukowane kursywą i poprzedzone wyrazem "UWAGA".

5. Odniesienie do wersji 1 norm Eurocontrolu dotyczącej bezpośredniej wzajemnej wymiany danych

Niniejszy dokument zastępuje część 1 i 2 wersji 1 norm Eurocontrolu dla bezpośredniej wymiany danych (OLDI). Część 3, opisująca techniczne protokoły, które mają zostać użyte, jest zastąpiona przez normę Eurocontrolu dla "Wymiany danych lotu — Dokumentu kontroli interfejsu" część 1.

6. Zasadnicze zmiany w odniesieniu do wersji 1

Najbardziej znaczącymi zmianami i uzupełnieniami w odniesieniu do wersji 1 są:

1. Włączenie następujących uzupełniających (nieobowiązkowych) komunikatów w odniesieniu do podstawowej procedury:

- komunikat dla odwołania koordynacji (MAC);

- komunikat przydzielenia kodu wtórnego radaru dozorowania SSR (COD);

- komunikat informacji (INF).

2. Określenie treści komunikatu i jego formatu w celu wsparcia przekraczania granic przez lot na trasie, która nie jest określoną trasą służb ruchu lotniczego, lecz która jest określona przez punkty początkowe i końcowe odcinka trasy.

3. Włączenie procedury dialogu pozwalającej na:

- identyfikację i negocjowanie niestandardowych warunków przekazu przez kontrolerów wykonujących funkcje planistyczne;

- zapewnienie jednostce akceptującej możliwości do złożenia kontrpropozycji dla warunków przekazu;

- zapewnienie przekazu urządzeń łączności jako część przekazu procedury kontroli.

4. Wprowadza się wykorzystanie formatu opisanego w wersji 2 normy Eurocontrolu dotyczącej wymiany danych służb ruchu lotniczego (ADEXP). Wszystkie komunikaty określone na podstawie procedury podstawowej i tej używanej podczas fazy koordynacji procedury dialogu są opisane z wykorzystaniem zarówno formatu Międzynarodowej Organizacji Lotnictwa Cywilnego (ICAO), jak i ADEXP. Przekazywanie komunikatów łączności opisane na podstawie procedury dialogu jest przedstawione z wykorzystaniem tylko formatu ADEXP.

5. Skreśla się następujące załączniki do wersji 1:

A : Identyfikacja jednostki ATC.

B :

Struktury komunikatów OLDI

(wszystkie komunikaty w wersji 3 zawierają przykłady).

D : Ogólny zarys.

E : Plan wdrożenia.

F : Wypełnianie zgodności przez państwa.

G : Wytyczne procedur.

H : Wskazówki do oceny OLDI.

6.3. Wyodrębnienie części 3 — Wymagania techniczne — ze specyfikacji stosowania.

7. Odniesienie do innych dokumentów

Niniejszy dokument odnosi się do wykorzystania dwóch typów pól formatu w powiązaniu z komunikatami; są to ICAO i ADEXP.

Formaty pól ICAO są określone w odniesieniu 1. W przypadku gdy odniesienie 1 jest zastąpione przez inny dokument, definicja typów pól ICAO jest taka, jak w niniejszym dokumencie.

Formaty pól ADEXP są określone w odniesieniu 2.

UWAGA:

Dokumenty informacyjne są wykazane w pkt 2

8. Język

Podczas opracowywania oryginału niniejszego dokumentu został użyty język angielski.

1. WPROWADZENIE

1.1. Cel

1.1.1. Loty, które są dostarczane w serwisie ATC, są przekazywane z jednej jednostki ATC do następnej w sposób zaprojektowany dla zapewnienia całkowitego bezpieczeństwa. W celu wypełnienia tego zamierzenia procedurą standardową jest, że przejście każdego lotu przez granicę obszaru odpowiedzialności dwóch jednostek jest uprzednio koordynowane między nimi oraz że kontrola lotu jest przekazywana wówczas, kiedy lot znajduje się na danej granicy lub w jej sąsiedztwie.

1.1.2. W przypadku wydawania poleceń (komunikowania się) telefonicznie przekazywanie danych dotyczących poszczególnego lotu będące częścią procesu koordynacji jest głównym zadaniem wspomagającym w jednostkach kontroli ruchu lotniczego w szczególności w centrach kontroli obszaru (ACC). W celu zastąpienia takich słownych "szacunków", odnoszących się jako bezpośrednia wzajemna wymiana danych OLDI, operacyjne użycie połączeń między systemami przetwarzania danych lotu w ACC rozpoczęło się w Europie we wczesnych latach osiemdziesiątych ubiegłego wieku.

1.1.3. W celu ułatwiania wdrażania wspólne zasady i formaty komunikatów zostały wypracowane i uzgodnione przez zainteresowane agencje oraz włączone do wersji 1 norm Eurocontrolu dla OLDI; niniejszy dokument, wersja, został opracowany w celu wsparcia trwającego rozwoju takich funkcji zgodnie z wymaganiami EATCHIP.

1.2. Zakres

1.2.1. Niniejszy dokument określa informacje i komunikaty, które mają być dostarczane między FDPS obsługującymi jednostki ATC w celu osiągnięcia:

- koordynacji wymaganej przed przekazem lotów z jednej jednostki do następnej;

- przekazu łączności takich lotów.

1.2.2. Niniejszy dokument:

- określa formaty komunikatów oraz zasady dotyczące zawartości;

- opisuje udogodnienia wymagane w takich jednostkach, które są warunkiem wstępnym wykorzystania wymiany danych do tego celu.

1.2.3. Niniejsza norma ma zastosowanie między Państwami Członkowskimi Eurocontrolu do międzynarodowych procedur OLDI między jednostkami dostarczającymi usługi ATC na danym obszarze.

1.2.4. Zalecenie

Zaleca się, aby państwa Europejskiej Konferencji Lotnictwa Cywilnego (ECAC) stosowały tę normę do:

- międzynarodowych udogodnień OLDI między jednostkami dostarczającymi usługi ATC na danym obszarze;

- udogodnień OLDI między jednostkami dostarczającymi regionalne usługi ATC na poziomie krajowym danego państwa.

2. ODNIESIENIA

2.1. Następujące dokumenty zawierają przepisy, które przez odniesienia w niniejszym tekście, ustanawiają przepisy niniejszego dokumentu normy Eurocontrol.

W czasie publikacji niniejszego dokumentu normy Eurocontrolu, wersje wskazujące do odnoszonych dokumentów są ważne.

Jakiekolwiek poprawki w odnośnych dokumentach ICAO zostaną natychmiast wzięte pod uwagę w celu zaktualizowania niniejszego dokumentu normy Eurocontrol.

Poprawki innych odnośnych dokumentów nie tworzą części przepisów niniejszego dokumentu normy Eurocontrolu, do czasu kiedy zostaną one w sposób formalny przejrzane i włączone do niniejszego dokumentu normy Eurocontrol.

W przypadku rozbieżności między wymaganiami niniejszego dokumentu normy Eurocontrolu a treścią innych odnośnych dokumentów niniejszy dokument normy Eurocontrolu ma pierwszeństwo.

2.2. Następujące dokumenty znajdują odniesienie do niniejszego dokumentu normy:

1. Procedury dla służb nawigacji powietrznej - Zasady służb ruchu lotniczego, dokument ICAO 4444, wersja 13 z dnia 7 listopada 1996 r., ze zmianami.

2. Wersja 2.0 dokumentu normy Eurocontrolu dla Prezentacji wymiany danych służb ruchu lotniczego (ADEXP), dokument referencyjny DPS-ET1-ST09-STD-01-00 z czerwca 1998 r.

3. DEFINICJE, SYMBOLE I SKRÓTY

3.1. Definicje

Do celów niniejszego dokumentu normy mają zastosowanie następujące definicje.

Jednostka akceptująca: Jednostka dostarczająca usługę ATC, która ma przejąć kontrolę lotu lub przejęła kontrolę lotu, kiedy przekaz z jednej jednostki do następnej ma lub miał już miejsce.

Potwierdzenie: Powiadomienie, że komunikat został otrzymany i uznany za poprawnie przetworzony.

Aktywacja: Proces w jednostce odbiorczej ATC, będący częścią procesu koordynacji między dwiema jednostkami, którego wynikiem jest dostarczenie danych do kontrolerów oraz dzięki któremu plan lotu dla odnośnego lotu jest zaktualizowany, w sposób pozwalający na zawarcie danych dostarczonych przez jednostkę przekazującą.

Wysokość: Pionowa odległość poziomu, punktu lub obiektu uznanego za punkt, mierzonego od poziomu morza.

Stosowanie: Ta część podsystemu ATS, która odpowiada niniejszej normie i łączy się z takimi podmiotami w innych systemach ATS.

Obszar odpowiedzialności: Przestrzeń powietrzna o określonych wymiarach, w której jednostka ATC dostarcza usługi ruchu lotniczego.

Połączenie: Procedura, w której system łączy otrzymany komunikat OLDI z planem lotu wprowadzonym do bazy danych.

Jednostka ATC: Organ dostarczający usługę kontroli ruchu lotniczego.

Dostępność: Prawdopodobieństwo, że udogodnienie będzie udostępnione przez użytkownika w danym czasie.

Granica: Samoloty (poziomo lub pionowo) przekraczające obszar odpowiedzialności jednostki ATC.

Dozwolony poziom lotu: Poziom lotu, na który lub w którym lot otrzymał zezwolenie od ATC.

Koordynacja, ATC: Proces, wykonywany między jednostkami ATC z przylegającym obszarem odpowiedzialności, polegający na wzajemnym formalnym doradzaniu sobie w zakresie planowanych przejść lotów przez granicę w celu zapewnienia bezpieczeństwa lotu przez zgodność planowanych działań.

Komunikat koordynacji: Ogólne pojęcie odnoszące się do komunikatów wykorzystywanych do wykonywania koordynacji ATC. Określenie to zawiera CDN, który jest szczególnym komunikatem opisanym w ppkt 8.8.

Faza koordynacji: W odniesieniu do danego lotu jest to faza, podczas której jednostki ATC przekazujące i odbiorcze ustalają warunki (np. poziom lotu, punkt graniczny), na podstawie których lot przejdzie z kontroli jednej jednostki do drugiej.

Punkt koordynacji: Punkt na granicy lub w jej sąsiedztwie znany przez jednostki ATC w sekwencji koordynacji i odnoszący się do komunikatów koordynacji.

Zależność: Proces oparty na określonych kryteriach łączenia danych planu lotu oraz trasy radaru tego samego lotu, przedstawianych zazwyczaj na wyświetlaczu kontrolera.

Norma Eurocontrolu: Jakakolwiek specyfikacja parametrów fizycznych, konfiguracji, materiałów, działania, personelu lub procedury, których ujednolicone stosowanie zostało zatwierdzone jako istotne dla wdrożenia w systemach ATS w Państwach Członkowskich Eurocontrolu. Norma Eurocontrolu nie może być sprzeczna z normami ICAO, lecz, gdzie to właściwe, powinna uzupełniać normę ICAO.

Kontroler wykonawczy: Kontroler, który dostarcza instrukcje bezpośrednio lotom podlegających jego/jej kontroli. Do kontrolerów tych zalicza się również kontrolerów wykonujących usługi radarowej kontroli obszaru.

Poziom wyjścia: Poziom, na którym lot był koordynowany w celu przekroczenia przez punkt przekazu kontroli. Poziom wyjścia może zawierać dodatkowe warunki przekroczenia, które określają poziom pasm, w którym będzie odbywał się lot wznoszący lub zniżający.

Plan lotu: Szczegółowe informacje dostarczane do organów służb ruchu lotniczego, odnoszące się do zamierzonego lotu lub części lotu statku powietrznego. Dodatkowo informacje pochodzące z planu lotu określonego lotu odbywającego się w ramach FDPS.

Wytwarzać: Proces w systemie ATC, gdzie odpowiednie dane są pobierane z bazy lub baz danych i komunikat jest wytwarzany w celu przekazu do jednostki odbiorczej ATC.

Format ICAO: Format wykorzystywany dla przekazu ziemia-ziemia komunikatów ATS, który wykorzystuje rodzaje pól i separatorów opisanych w odniesieniu 1.

Poziom: Ogólne pojęcie odnoszące się do pionowej pozycji statku powietrznego podczas lotu; w obrębie niniejszej normy w przypadkach, gdzie zostało to użyte, pojęcie poziom lub lot zawiera wysokość.

Powiadomienie: Proces, za pomocą którego jednostka przekazująca przekazuje dane w celu uzupełnienia systemu w jednostce odbiorczej w oczekiwaniu na fazę koordynacji.

Jednostka odbiorcza: Jednostka ATC, do której komunikat jest wysyłany.

Wiarygodność: Odsetek rozkładowych dostępności, w czasie których usługa ma być wykonana.

Zgłoszony poziom lotu: Poziom lotu zgłoszony przez statek powietrzny w planie lotu.

Weryfikacja: Zmiana do danych przesłanych wcześniej przez przekazującą jednostkę ATC do jednostki odbiorczej ATC.

Uzupełniający poziom przekraczania: Poziom, na którym lub powyżej którego albo na którym lub poniżej którego lot był koordynowany w celu przekroczenia punktu przekazu kontrolni. Uzupełniający poziom, jeśli istnieje, jest elementem poziomu wyjścia.

System planu lotu: Informacje pozyskiwane z planu lotu określonego lotu odbywającego się w FDPS.

Czas transakcji: Przedział czasowy następujący po wprowadzeniu komunikatu, podczas którego są wykonywane: przesył, początkowe przetwarzanie w systemie odbiorczym, wytwarzanie i przesył komunikatu potwierdzenia oraz jego identyfikacja w systemie przekazującym.

Punkt przekazu kontroli: Określony punkt, położony wzdłuż ścieżki lotu statku powietrznego, w którym odpowiedzialność za dostarczanie ATS do statku powietrznego jest przekazywana z jednej jednostki ATC lub stanowiska kontroli do następnej. Niekoniecznie tożsamy z punktem koordynacji.

Faza przekazu: Faza lotu następująca po fazie koordynacji, podczas której dokonuje się przekaz łączności.

Jednostka przekazująca: W sekwencji koordynacji jednostka ATC odpowiedzialna za dostarczanie usług dla lotu przed granicą, która zapoczątkowuje fazę koordynacji z następną jednostką.

Przesyłać: Przekazywać komunikaty z jednego systemu do drugiego.

Jednostka: Organ służb ruchu lotniczego.

Ostrzeżenie: Komunikat wyświetlany na stanowisku pracy, kiedy zawodzi zautomatyzowany proces koordynacji.

3.2. Symbole i skróty

Do celów niniejszej normy Eurocontrolu mają zastosowanie poniższe symbole i skróty.

ABI Komunikat zaawansowanej informacji o przecięciu granicy

ACC Centrum kontroli obszaru

ACP Komunikat akceptacji

ACT Komunikat aktywacji

ADEXP Prezentacja wymiany danych organów służb ruchu lotniczego

ATC Kontrola ruchu lotniczego

ATM Zarządzanie ruchem lotniczym

ATS Służby ruchu lotniczego

CDN Komunikat koordynacji

CNL Anulowanie planu lotu

COD Komunikat przyznania kodu SSR

COF Komunikat zmiany częstotliwości

COP Punkt koordynacji

DED Dyrekcja rozwoju EATCHIP, Eurocontrol

EATCHIP Europejski Program Harmonizacji i Integracji Kontroli Ruchu Lotniczego

ECAC Europejska Konferencja Lotnictwa Cywilnego

ETO Przewidywany czas nad

ETOT Przewidywany czas startu

EWPD Dokument Program pracy EATCHIP

FDPS System przetwarzania danych lotu

FRF Dalsza trasa lotu

HMI Interfejs człowiek-maszyna

HOP Komunikat propozycji przekazania lotu

ICAO Międzynarodowa Organizacja Lotnictwa Cywilnego

INF Komunikat informacji

LAM Komunikat potwierdzenia logicznego

LoA Umowa

MAC Komunikat dla odwołania koordynacji

MAS Ręczne przejęcie łączności

NM Mile morskie

OLDI Bezpośrednia wzajemna wymiana danych

ORCAM Metoda przyznania kodu pochodzącego z regionu

PAC Komunikat wstępnej aktywacji

RAP Komunikat przedłożenia propozycji aktywacji

REV Komunikat weryfikacji

RJC Komunikat odrzucenia koordynacji

ROF Komunikat żądanej zmiany częstotliwości

RRV Komunikat przedłożenia propozycji weryfikacji

SBY Komunikat oczekiwania

SDM Komunikat danych uzupełniających

SSR Radar wtórny dozorowania

SYSCO Koordynacja wsparta systemowo

TI Inicjacja przekazu

TIM Komunikat inicjacji przekazu

TWR/APP Wieża (kontrola lotniska) i kontrola zbliżania

4. WYMAGANIA OGÓLNE

4.1. Wprowadzenie

Niniejszy punkt opisuje ogólne wymagania operacyjne niezbędne dla stosowania funkcji OLDI między jednostkami ATC oraz wymagania klasyfikacyjne i wykonawcze różnych rodzajów wykorzystywanych komunikatów.

4.2. Wymagania odnoszące się do systemu przetwarzania danych dotyczących lotu (FDPS)

4.2.1. Baza danych lotu

Jednostki wykorzystujące udogodnienia określone w niniejszym dokumencie mają dane dostarczane z FDPS, który zawiera wszystkie informacje wymagane dla wyświetlania, przetwarzania i kompilowania określonych komunikatów. Pierwszym źródłem danych dla każdego lotu jest plan lotu przesłany przez lub w imieniu dowódcy statku powietrznego. Dalsze elementy danych są otrzymywane poprzez przetwarzanie planów lotów w odniesieniu do otoczenia danej jednostki.

4.2.2. Działania w czasie rzeczywistym

Procedura OLDI zawiera działania w jednostce przekazującej ATC do zapoczątkowania funkcji niezbędnych do czasowego przedstawiania danych kontrolerowi przekazującemu oraz przesyłu danych koordynacji do jednostki akceptującej. W tym celu FDPS jest w stanie rozpocząć działania poprzez porównanie uniwersalnego czasu skoordynowanego i parametrów stosowanego czasu z czasami w określonych punktach na trasie lotu zgodnie z obliczeniami dokonanymi na podstawie bazy danych lotu.

4.2.3. Możliwość komunikowania danych

4.2.3.1. FDPS jest w stanie otrzymywać i przekazywać dane dotyczące lotu w formacie mającym zastosowanie do komunikatów, jak określono w niniejszym dokumencie, za pośrednictwem środka łączności danych, który wspomaga funkcję OLDI.

4.2.3.2. Zalecenie

FDPS powinny posiadać potencjał rozwojowy umożliwiający dodanie nowych komunikatów, które mogą zostać zawarte w kolejnych wydaniach niniejszej normy.

4.2.3.3. W trakcie wykonywania wymagań określonych w niniejszym dokumencie środek łączności danych dostarcza szybkiej i właściwej wymiany danych aplikacja-do-aplikacji poprzez:

- zapewnienie integralności przekazu komunikatów OLDI;

i

- monitorowanie połączeń typu punkt-do-punktu lub statusu sieci łączności, wówczas gdy ma to zastosowanie.

4.2.3.4. FDPS ostrzega stanowisko pracy, kiedy anomalie są wykryte przez system komunikowania danych.

4.2.4. Funkcje stosowania

4.2.4.1. Systemy wykorzystywane dla dostarczania udogodnień OLDI są w stanie automatycznie przyjąć, przechować, przetworzyć, wyodrębnić, dostarczyć do wyświetlacza oraz przekazać stosowne dane OLDI w rzeczywistym czasie.

4.2.4.2. FDPS:

- odzwierciedla aktualne dane operacyjne odpowiednie do funkcji OLDI zgodnie z wymaganiami niniejszej normy, uzupełnione automatycznie, przez ręczne wprowadzenie albo w drodze kombinacji tych dwóch;

- jest w stanie wyodrębnić takie elementy z bazy danych planu lotu;

- identyfikuje następną jednostkę ATC na trasie lotu.

4.2.4.3. Następujące elementy są uzgodnione dwustronnie:

- Punkty koordynacji (COP);

- W danych przypadkach punkty odniesienia wykorzystywane dla umownych znaków położenia i odległości w identyfikacji COP, na odcinkach tras nieobsługiwanych przez ATS.

UWAGA

COP mogą nie zawsze być identyczne z punktami przekazu kontroli.

4.2.5. Interfejs człowiek-maszyna (HMI)

4.2.5.1. HMI jest w stanie:

- wyświetlać treść operacyjną komunikatów OLDI i odpowiednich ostrzeżeń odnoszących się do komunikatów dla natychmiastowego zwrócenia uwagi;

- koordynować trasę i przekazywać komunikaty ostrzegawcze do stanowisk operacyjnych odpowiedzialnych za koordynację danych lotów.

4.2.5.2. Personel ATC jest wyposażony w środki do modyfikacji danych, z których uzyskuje się treść operacyjną komunikatów, zgodnie z wymogami niniejszego dokumentu.

4.2.5.3. W zależności od przypadku HMI wskazuje, że przesyłanie komunikatów jest w trakcie lub zostały pomyślnie przesłane.

4.2.5.4. Wysłanie ostrzeżenia lub powiadomienia do właściwego ATC lub stanowiska technicznego jest dokonywane automatycznie, jeśli żadne potwierdzenie nie zostało odebrane w stałym odstępie czasu następującym po przekazie komunikatu koordynacji lub przekazu.

4.2.5.5. Ostrzeżenie to lub powiadomienie jest w takiej formie, która natychmiast zwróci uwagę właściwego stanowiska pracy.

4.2.5.6. Zalecenie

HMI na stanowiskach ATC wykorzystujących OLDI powinien dostarczyć ostrzeżenie, jeśli udogodnienie OLDI jest niedostępne.

4.2.6. Wprowadzanie komunikatów

4.2.6.1. Każdy system zawiera zestaw systemowych parametrów w celu zapewnienia czasowego automatycznego wprowadzania komunikatów OLDI.

4.2.6.2. Zalecenie

Powinna zostać zapewniona możliwość ręcznego wprowadzania przekazu komunikatów koordynacji przed obliczonym czasem transmisji.

4.2.6.3. Automatyczne działanie powinno być zawsze zapewnione, na wypadek gdy ręczne wprowadzenie nie może być przeprowadzone.

4.2.6.4. System wykorzystuje parametry czasu w celu określenia następujących elementów:

- czasu poprzedzającego przesył, kiedy treść operacyjna komunikatów w jednostce przekazującej jest wyświetlana;

- czasu, globalnego lub przez COP, aby przekazać komunikaty, w danym przypadku;

- czasu po przesyle komunikatów, w którym potwierdzenie poziomu stosowania ma zostać otrzymane.

4.2.6.5. Komunikat jest przesyłany niezwłocznie, kiedy wymagane informacje stają się dostępne w czasie późniejszym niż ten, w którym byłby w innym wypadku przesłany.

Przykład:

Lot rozpoczyna się na odcinku GAT IFR w punkcie blisko granicy, którą ma zamiar przekroczyć; ETO w tym punkcie jest komunikowany na osiem minut przed COP w czasie, w którym przesłanie komunikatu ACT jest już opóźnione w oparciu o odpowiedni parametr czasowy (czasów); komunikat jest przesyłany niezwłocznie.

4.2.7. Odbieranie komunikatów

4.2.7.1. System kontroli ruchu lotniczego jest zdolny do:

- otrzymywania komunikatów OLDI;

- przetwarzania ich automatycznie zgodnie z niniejszą normą;

- wytworzenia danych o locie zgodnie z otrzymanym komunikatem i wyświetlania wymaganych ostrzeżeń w przypadku niezgodności w otrzymanych danych;

- wytworzenia i przesłania automatycznie komunikatów potwierdzających na poziomie stosowania.

4.2.7.2. Komunikat potwierdzenia (komunikat logicznego potwierdzenia (LAM), akceptacji (ACP) lub oczekiwania (SBY)) jest wytwarzany i przesyłany, kiedy odpowiedni komunikat został przetworzony i kiedy przedstawienie wyników przetwarzania do właściwych stanowisk jest, w razie konieczności, zapewnione.

UWAGA

Szczegółowe warunki dla wytwarzania potwierdzenia są określone osobno dla każdego komunikatu.

4.3. Uaktualnianie z danych dozorowania

Zalecenie

W celu zapewnienia dokładności danych dotyczących przewidywanego czasu do uaktualniania bazy danych dotyczących planu lotu powinna być użyta informacja pochodząca ze śledzenia lotu przez radar lub inny środek nadzoru.

4.4. Rejestrowanie danych OLDI

4.4.1. Treść

Treść wszystkich komunikatów OLDI oraz czas otrzymywania są rejestrowane.

4.4.2. Udogodnienia

Udogodnienia są dostępne do odzyskiwania i wyświetlania zarejestrowanych danych.

4.5. Dostępność, wiarygodność, bezpieczeństwo danych oraz integralność danych

4.5.1. Dostępność

4.5.1.1. Udogodnienia OLDI między dwiema zainteresowanymi jednostkami są dostępne w godzinach szczytu ruchu lotniczego oraz poza szczytem.

4.5.1.2. Zalecenie

Udogodnienia OLDI powinny być dostępne przez 24 godziny dziennie.

4.5.1.3. Jakikolwiek zaplanowany okres, w którym urządzenia są wyłączone z pracy (i tym samym czas dostępności urządzeń) jest uzgadniany przez dwie zainteresowane jednostki.

4.5.2. Wiarygodność

4.5.2.1. Wiarygodność na każdym połączeniu OLDI powinna wynosić przynajmniej 99,86 % (równowartość czasu wyłączenia urządzeń z pracy przez nie dłużej niż 12 godzin rocznie w oparciu o dwudziestoczterogodzinną dostępność).

4.5.2.2. Zalecenie

Tam gdzie jest to uzasadnione względami operacyjnymi, powinna być zapewniona wiarygodność rzędu przynajmniej 99,99 % (równowartość czasu wyłączenia urządzeń z pracy przez nie dłużej niż 52 minuty rocznie w oparciu o dwudziestoczterogodzinną dostępność).

4.5.3. Bezpieczeństwo danych

Zalecenie

Metody zabezpieczania danych (np. prawa dostępu, weryfikacja źródła), a w danym przypadku zarządzanie siecią, powinny być stosowane udogodnienia OLDI.

4.5.4. Integralność danych

Wskaźnik błędu na poziomie stosowania nie powinien przekroczyć jednego błędu w przesyle na 2000 komunikatów.

4.6. Ocena operacyjna

4.6.1. Okres oceny

Każde nowe udogodnienie OLDI łącznie z nowym udogodnieniem na istniejącym połączeniu, przed jego wdrożeniem operacyjnym powinno być poddane ocenie w celu zweryfikowania integralności danych, dokładności, wydajności, zgodności z procedurami ATC i całkowitego bezpieczeństwa.

UWAGA

Procedura asystowania przy ocenie nowego udogodnienia OLDI jest dostępna w sekretariacie OLDI, Eurocontrol.

4.6.2. Termin wprowadzenia operacyjnego

Termin wprowadzenia operacyjnego, oznaczający ukończenie oceny, powinien być uzgodniony między dwiema jednostkami.

5. KATEGORIE KOMUNIKATÓW

5.1. Przepisy ogólne

5.1.1. Cel

Niniejszy podpunkt dokumentu:

- określa kategorie komunikatów;

- przedstawia wymogi dotyczące czasu transakcji dla kategorii;

- stwierdza, które komunikaty są obowiązkowe, a które uzupełniające;

- przyporządkowuje rodzaje komunikatów do kategorii.

5.1.2. Kategorie komunikatów

Komunikaty OLDI zostały przyporządkowane następującym kategoriom:

- kategoria 1: Przekaz łączności;

- kategoria 2: Koordynacja;

- kategoria 3: Powiadomienie.

5.2. Czasy transakcji

5.2.1. Warunki czasu transakcji

5.2.1.1. Określone czasy transakcji zawierają przesyłanie, wstępne przetwarzanie w jednostce otrzymującej, tworzenie komunikatu potwierdzenia, przesyłanie go i odbiór w jednostce przesyłającej. Dlatego też komunikaty automatycznego potwierdzenia LAM i SBY nie zostały przyporządkowane kategoriom komunikatów.

5.2.1.2. Maksymalny czas transakcji dla różnych kategorii przedstawia poniższa tabela 5-1.

Tabela 5-1

Maksymalne czasy transakcji

Kategoria komunikatów | 90 % | 99,8 % |

1 | 4 s | 10 s |

2 | 10 s | 25 s |

3 | 15 s | 45 s |

5.2.1.3. Wartość przyznanego czasu jest określana dla kategorii lub rodzaju komunikatów.

5.2.1.4. Jeśli nie otrzymano żadnego potwierdzenia w określonym czasie po przekazie, komunikat jest uznawany za niewłaściwie przesłany lub niewłaściwie przetworzony, pojawia się wówczas ostrzeżenie zgodnie z przepisami stosownego punktu niniejszego dokumentu.

5.2.1.5. Zalecenie

Wartości przyznanego czasu dla trzech kategorii nie powinny przekroczyć odpowiednio 12 sekund, 30 sekund i 60 sekund.

5.3. Klasyfikacja komunikatów i ich podział na kategorie

5.3.1. Klasyfikacja komunikatów — obowiązkowe i uzupełniające

5.3.1.1. Komunikaty opisane w tym dokumencie są klasyfikowane jako obowiązkowe lub uzupełniające.

5.3.1.2. Tam gdzie komunikat do przesłania jest opisany jako obowiązkowy, przetwarzanie jest uwzględnione, tak aby było możliwe przesłanie tego komunikatu.

5.3.1.3. Tam gdzie komunikat do otrzymania (REC) jest opisany jako obowiązkowy, przetwarzanie jest uwzględnione, tak aby było możliwe przetworzenie otrzymanego komunikatu.

UWAGA

W wyjątkowych przypadkach, kiedy przepływ ruchu między dwiema jednostkami jest jednokierunkowy, obowiązkowe komunikaty mogą być stosowane w tylko w jednym kierunku.

5.3.1.4. Tam gdzie komunikat do przesłania jest opisany jako uzupełniający (C), przetwarzanie jest uwzględnione, tak aby było możliwe przesłanie tego komunikatu, w razie konieczności, przez przesyłającą jednostkę i uzgodnione z jednostką otrzymującą.

UWAGA

Uzupełniające komunikaty mogą być użyte w jednym kierunku tylko zgodnie z wymogami operacyjnymi.

5.3.1.5. Tam gdzie komunikat do odbioru jest opisany jako uzupełniający, przetwarzanie jest uwzględnione, tak aby było możliwe przetworzenie otrzymanych komunikatów, jeśli takie działanie zostało uzgodnione dwustronnie.

5.3.1.6. Wymagania opisane w tabelach 5-3 i 5-4 znajdują zastosowanie tylko tam, gdzie wykorzystanie procedury dialogu dla koordynacji i/lub przekazu łączności zostało odpowiednio uzgodnione dwustronnie między jednostkami kontroli ruchu lotniczego.

5.3.2. Podział komunikatów na kategorie

5.3.2.1. Podział komunikatów na kategorie dla procedury podstawowej jest określony w tabeli 5-2.

5.3.2.2. Podział na kategorie dodatkowych komunikatów koordynacji dla procedury dialogu jest określony w tabeli 5-3.

5.3.2.3. Podział na kategorie komunikatów przekazu łączności dla procedury dialogu jest określony w tabeli 5-4.

Tabla 5-2

Komunikaty procedury podstawowej

Rodzaj komunikatów | Skrót | Kategorie | Przesył | Odbiór |

Zaawansowana informacja o przecięciu granicy | ABI | 3 | M | M |

Aktywacja | ACT | 2 | M | M |

Weryfikacja | REV | 2 | C [1] | C [1] |

Wstępna aktywacja | PAC | 2 | C | C |

Odwołanie koordynacji | MAC | 2 | C | C |

Przyznanie kodu SSR | COD | 2 | C | C |

Informacja | INF | 3 | C | C |

Komunikat logicznego potwierdzenia | LAM | | M | M |

Tabela 5-3

Procedura dialogu — komunikaty fazy koordynacji

(Uzupełnienie do tabeli 5-2)

Rodzaj komunikatów | Skrót | Kategorie | Przesyłanie | Odbiór |

Przedłożenie propozycji aktywacji | RAP | 2 | C | M |

Przedłożona weryfikacja | RRV | 2 | C | M |

Koordynacja | CDN | 2 | M | M |

Oczekiwanie [2] | SBY | | M | M |

Akceptacja | ACP | 2 | M | M |

Odrzucić koordynację [3] | RJC | 2 | C | C |

Tabela 5-4

Procedura dialogu — komunikaty fazy przekazu

Rodzaje komunikatów | Skrót | Kategorie | Przesyłanie | Odbiór |

Inicjowanie przekazu | TIM | 1 | M | M |

Dane uzupełniające | SDM | 1 | [4] | [4] |

Propozycja przekazania lotu | HOP | 1 | M | M |

Zmiana częstotliwości [5] | COF | 1 | C | M |

Żądanie zmiany częstotliwości | ROF | 1 | C | M |

Ręczne przejęcie łączności [5] | MAS | 1 | C | M |

6. PROCEDURA PODSTAWOWA — KOMUNIKATY OBOWIĄZKOWE

6.1. Przepisy ogólne

6.1.1. Opis wymogów

Niniejszy podpunkt opisuje minimalne wymagania na poziomie stosowania dla wdrożenia udogodnień OLDI.

6.1.2. Wdrożenie

Jednostki wykorzystujące OLDI dla koordynacji lotów powinny wdrożyć ABI, ACT i LAM zgodnie z opisem w niniejszym podpunkcie, z wyjątkiem sytuacji gdzie zostało dwustronnie uzgodnione, aby wykorzystywać procedurę koordynacji dialogu opisaną w pkt 8 niniejszego dokumentu, dla każdego przypadku warunki wykorzystywania komunikatów ACT i LAM zostały określone w niniejszym podpunkcie.

6.2. Komunikat informacji o przecięciu granicy (ABI)

6.2.1. Cel komunikatu ABI

Komunikat ABI spełnia następujące operacyjne wymagania:

- zapewnia przejęcie brakujących danych w planie lotu;

- dostarcza zaawansowanych informacji o przecięciu granicy oraz poprawek do nich następnej jednostce ATC;

- uaktualnia podstawowe dane w planie lotu;

- ułatwia wczesną korelację ścieżek radaru;

- ułatwia dokładne oszacowanie obciążenia odcinka w krótkim okresie czasu.

ABI jest komunikatem zgłaszającym.

6.2.2. Treść komunikatu

Komunikat ABI zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikacja statku powietrznego;

- tryb i kod SSR (jeśli jest dostępny);

- lotnisko odlotu;

- prognozowane dane;

- lotnisko docelowe;

- numer i typ statku powietrznego;

- trasę (do wyboru);

- inne dane dotyczące planu lotu (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

6.2.3. Zasady stosowania

6.2.3.1. Przepisy ogólne

6.2.3.1.1. Z wyjątkiem informacji przewidzianych w ppkt 6.2.3.1.3 i 6.2.3.1.4 poniżej jeden lub więcej komunikatów ABI jest przesyłanych na każdy lot, którego celem jest przekroczenie granicy obszarów odpowiedzialności podlegających procedurom OLDI.

6.2.3.1.2. Komunikat ABI poprzedza komunikat aktywacji (ACT) lub komunikat przedłożenia propozycji aktywacji (RAP).

6.2.3.1.3. Komunikat ABI nie jest wytwarzany, jeśli komunikat wstępnej aktywacji (PAC) ma być przesłany.

6.2.3.1.4. Zalecenie

Przesył ABI powinien być zakazany jeśli komunikat ACP lub RAP oczekuje na przesył niezwłocznie lub w przedziale czasowym uzgodnionym dwustronnie.

UWAGA

Celem tego zalecenia jest uniknięcie usiłowanego jednoczesnego nałożenia się nieprawidłowości w różnych stanowiskach jednostki odbiorczej w odniesieniu do komunikatów ABI i ACT dla tego samego lotu.

6.2.3.1.5. Zweryfikowany komunikat ABI jest przesyłany, jeśli kolejny komunikat ACT nie został wytworzony oraz:

- trasa lotu została zmodyfikowana w ten sposób, że COP w poprzednim komunikacie ABI nie jest już dokładny;

- lotnisko docelowe zostało zmienione;

lub

- typ statku powietrznego został zmieniony.

6.2.3.1.6. Zalecenie

Zweryfikowany komunikat powinien być przesłany, jeśli kolejny komunikat ACT nie został wytworzony oraz jeśli jeden z następujących punktów ma być zmieniony:

- oczekiwany poziom przekroczenia granicy;

- oczekiwany kod SSR w punkcie przekazu kontroli;

- kiedy przewidywany czas nad (ETO) w COP różni się od poprzedniego komunikatu ABI o więcej niż czas określony w umowie (LoA);

- pozostałe inne dane, które zostały uzgodnione dwustronnie.

6.2.3.2. Przetwarzanie w jednostce odbiorczej

6.2.3.2.1. System ATC odbierając komunikat ABI dokonuje próby jego połączenia z odpowiadającymi jemu danymi planu lotu.

6.2.3.2.2. Jeśli połączenie z planem lotu nie jest pomyślne, plan lotu jest stworzony automatycznie lub ręcznie w systemie odbiorczym.

6.2.3.2.3. Jeśli połączenie z planem lotu jest pomyślne, ale odnotowano rozbieżność między danymi w komunikacie i odpowiadającymi danymi w systemie odbiorczym i w wyniku tej rozbieżności w razie potrzeby konieczne byłoby podjęcie działania korygującego po otrzymaniu następującego komunikatu ACT, rozbieżność jest odsyłana do odpowiedniego stanowiska w celu wyeliminowania.

6.2.3.3. Parametry czasu przeznaczonego do przesyłu

6.2.3.3.1. Komunikat jest przesyłany w odstępie stałej liczby minut przed przewidywanym czasem w COP.

6.2.3.3.2. Parametry wytwarzania ABI są ujęte w umowie (LoA) między zainteresowanymi jednostkami ATC.

6.2.3.3.3. Zalecenie

Wytworzony(-e) parametr(-y) ABI powinien(-ny) być:

- zmienny, oparty na postanowieniach umowy (LoA);

- określony oddzielnie dla każdego COP.

6.2.4. Potwierdzenie ABI

6.2.4.1. Potwierdzenie

Komunikat ABI jest potwierdzany poprzez wytwarzanie i przesył komunikatu LAM.

UWAGA

Komunikat LAM jest wytwarzany niezależnie od wyników próby połączenia planu lotu.

6.2.4.2. Brak potwierdzenia

Zalecenie

Jeśli żaden komunikat LAM nie został odebrany jako potwierdzenie dla komunikatu ABI, na stanowisku nadzoru powinno ukazać się ostrzeżenie.

6.2.5. Przykłady

"Air 2000" 253, Boeing 757 z Malty do Birmingham przewidywany BNE VOR o godz. 1221 UTC, lecący FL350 z rzeczywistą prędkością 480 knots, planujący lecieć przez UB4 BNE UB4 BPK UB3 HON, nadając na A7012 i żądając FL390. Poniżej przedstawione są przykłady komunikatów ABI przesłanych z Reims do Londynu ACC.

6.2.5.1. ICAO

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

6.2.5.2. ADEXP

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

6.3. Komunikat aktywacji (ACT)

6.3.1. Cel komunikatu aktywacji (ACT)

Komunikat ACT spełnia następujące wymogi operacyjne:

- zastępuje słowne prognozy graniczne poprzez automatyczne przesyłanie szczegółów lotu z jednej jednostki ATC do następnej przed przekazaniem kontroli;

- wprowadza aktualne informacje do podstawowych danych w planie lotu w jednostce odbiorczej ATC;

- ułatwia dystrybucję i wyświetlanie planu lotu w ramach odbiorczej jednostki ATC do zaangażowanych funkcjonujących stanowisk;

- przyspiesza wyświetlanie korelacji znak wywoławczy/kod w odbiorczej jednostce ATC;

- dostarcza warunki przekazu do odbiorczej jednostki ATC.

6.3.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- typ komunikatu;

- numer komunikatu;

- identyfikacja statku powietrznego;

- tryb i kod SSR;

- lotnisko odlotu;

- prognozowane dane;

- lotnisko docelowe;

- numer i typ statku powietrznego;

- trasę (do wyboru);

- inne dane dotyczące planu lotu (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

6.3.3. Zasady stosowania

6.3.3.1. Przepisy ogólne

6.3.3.1.1. Jeden komunikat ACT jest wysyłany dla odpowiednich lotów przekraczających granicę, z wyjątkiem przewidzianych w ppkt 6.3.3.1.10.

6.3.3.1.2. Komunikat ACT jest wytwarzany i przesyłany automatycznie w obliczonym czasie, jak określono w umowie, jeśli nie został ręcznie wprowadzony wcześniej.

6.3.3.1.3. Zalecenie

Personel kontroli ruchu lotniczego powinien posiadać środki do uruchamiania przesyłu komunikatów ACT przed obliczonym czasem przesyłu.

6.3.3.1.4. Treść operacyjna komunikatu ACT, który ma być przesłany jest wyświetlany na stanowisku pracy odpowiedzialnym za koordynację lotu przed faktycznym przesyłem.

6.3.3.1.5. Zalecenie

W odniesieniu do ppkt 6.3.3.1.4 czas, w którym szacuje się, że komunikat ACT będzie przesłany automatycznie, powinien być wyświetlony razem z jej treścią.

6.3.3.1.6. Komunikat ACT zawiera najnowsze informacje na temat lotu odzwierciedlające oczekiwane warunki wyjścia.

6.3.3.1.7. Stosowne stanowiska pracy są powiadamiane o przesyle komunikatu ACT.

6.3.3.1.8. Jak tylko komunikat LAM zostaje odebrany, dane dotyczące komunikatu ACT stają się operacyjnie wiążące dla dwóch jednostek kontroli lotów. Warunki koordynacji przekazu oraz fakt, że LAM został odebrany, są przedstawiane personelowi ATC w jednostce przekazującej.

6.3.3.1.9. Warunki przekazu przewidziane w komunikacie ACT są akceptowane przez jednostkę odbiorczą, jeśli jednostka odbiorcza nie wprowadza koordynacji w celu ich zmiany.

6.3.3.1.10. Jeśli poprzedni komunikat ACT został odwołany z wykorzystaniem MAC, kolejny komunikat ACT może być wysłany tylko do tego samego partnera koordynacji.

6.3.3.1.11. Trasa oraz inne dane dotyczące planu lotu są uwzględnianie, jeśli tak zostało uzgodnione przez dwie strony.

6.3.3.2. Przetwarzanie w jednostce odbiorczej

6.3.3.2.1. System ATC otrzymując komunikat ACT dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

6.3.3.2.2. Jeśli plan lotu odpowiadający komunikatowi został odnaleziony i nie występują żadne rozbieżności w komunikacie, które powstrzymywałyby prawidłowe jego przetwarzanie:

- operacyjna treść jest uwzględniana w planie lotu;

- wymagane dane są wytwarzane w stanowiskach operacyjnych ATC lub w innych w razie konieczności;

- LAM jest odsyłany.

6.3.3.2.3. Jeśli odpowiadający komunikatowi plan lotu nie może być odnaleziony albo występuje rozbieżność, która powstrzymuje prawidłowe przetwarzanie komunikatu:

- jeśli sektor odpowiedzialny za przyjęcie kontroli lotu może być określony:

- treść operacyjna komunikatu musi być przedstawiona w sektorze;

- LAM jest odsyłany;

- plan lotu jest tworzony;

- w pozostałych innych przypadkach LAM nie jest odsyłany.

6.3.3.3. Parametry dla przesyłu

6.3.3.3.1. Komunikat jest przesyłany w czasie lub najkrótszym odstępie czasu spośród przedstawionych poniżej:

- stałej liczby minut przed oszacowanym czasem w COP;

- czasie, w którym lot znajduje się w odległości dwustronnie uzgodnionej od COP.

6.3.3.3.2. Parametry wytwarzające ACT są zawarte w umowie między zainteresowanymi jednostkami ATC.

6.3.3.3.3. Parametry wytwarzające ACT są zmiennymi opartymi na zaleceniach umowy.

6.3.3.3.4. Zalecenie

Parametry wytwarzające ACT powinny być określane oddzielnie dla każdego COP.

6.3.3.3.5. Określone parametry dopuszczają wystarczającą ilość czasu:

- jednostce przesyłającej w celu uaktualniania poziomu lotu przekazu kontroli, aby odzwierciedlić oczekiwane warunki w COP;

oraz

- jednostce odbiorczej do przetworzenia ACT i wytworzenia oraz przesyłu LAM, ale nadal pozostawiając jednostce przekazującej możliwość przeprowadzania słownej koordynacji, a jednostce akceptującej możliwość podjęcia koniecznych środków, jeśli wymiana danych się nie powiedzie.

6.3.4. Potwierdzenie ACT

6.3.4.1. Potwierdzenie

Komunikat ACT jest potwierdzany poprzez wytwarzanie i przesył komunikatu LAM.

6.3.4.2. Brak potwierdzenia

Jeśli żaden komunikat LAM nie został odebrany jako potwierdzenie komunikatu ACT, ostrzeżenie wyświetla się na stanowisku ATC odpowiedzialnym za koordynację lotu.

6.3.5. Przykłady

Przedstawione poniżej przykłady stanowią ciąg dalszy przykładów przedstawionych w ppkt 6.2; wszystkie szczegóły są takie same, z wyjątkiem ETO przy COP, który w komunikacie ACT przedstawionej poniżej wynosi 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. Komunikat potwierdzenia logicznego (LAM)

6.4.1. Cel komunikatu LAM

Za pomocą LAM odbiór i ochrona przesyłanego komunikatu są sygnalizowane do jednostki wysyłającej poprzez jednostkę odbiorczą.

Przetwarzanie LAM dostarcza personelowi w jednostce przekazującej następujących informacji:

- ostrzeżenie, kiedy nie otrzymano żadnego potwierdzenia;

- wskazanie, że potwierdzony komunikat został odebrany, pomyślnie przetworzony, wolny od błędów, zachowana i, w razie konieczności, dostępny do przedstawienia odpowiedniemu stanowisku pracy.

6.4.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

6.4.3. Zasady stosowania

6.4.3.1. Przepisy ogólne

6.4.3.1.1. Zasady dla odsyłania LAM są wyszczególnione dla każdego rodzaju komunikatu w odpowiednich punktach niniejszego dokumentu.

6.4.3.1.2. Komunikat LAM jest wytwarzany i przesłany bez interwencji człowieka.

6.4.3.1.3. Komunikatu LAM nie używa się w celu uniknięcia konieczności użycia komunikatów technicznych zapewniających integralność przesyłu danych.

6.4.3.1.4. Komunikat LAM jest wytwarzany i przesyłany niezwłocznie, tak aby mógł być spełniony wymóg czasu transakcji potwierdzanej komunikatu.

6.4.3.1.5. Z wyjątkiem komunikatów ABI przesyłający system ATC informuje kontrolera odpowiedzialnego za koordynację, jeśli komunikat LAM nie został odebrany w granicach parametrów czasowych ustalonych dla takich ostrzeżeń.

6.4.4. Potwierdzenie LAM

Komunikat LAM nie wymaga żadnego potwierdzenia.

6.4.5. Przykłady

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. PROCEDURA PODSTAWOWA — KOMUNIKATY UZUPEŁNIAJĄCE

7.1. Przepisy ogólne

7.1.1. Opis wymagań

Niniejszy podpunkt opisuje udogodnienia znajdujące zastosowanie w procedurze podstawowej. Stanowią one dodatek do udogodnień opisanych w pkt 6 Procedury podstawowe — komunikaty obowiązkowe.

7.1.2. Wdrażanie

7.1.2.1. Wykorzystanie jakichkolwiek udogodnień opisanych w niniejszym podpunkcie musi być uzgodnione dwustronnie przed wprowadzeniem.

7.1.2.2. Tam gdzie wykorzystanie udogodnień zostało uzgodnione, stosuje się zasady opisane w niniejszym podpunkcie.

7.2. Komunikat wstępnej aktywacji (PAC)

7.2.1. Cel komunikatu PAC

Komunikat PAC spełnia następujące wymogi operacyjne:

- powiadomienie i koordynacja przed odlotem, gdzie czas lotu od startu do COP jest krótszy niż taki, który byłby wymagany w celu zgodności z uzgodnionymi parametrami czasu dla przesyłu komunikatu ACT;

- powiadomienie i koordynacja lotu przed startem przez lokalną jednostkę (lotniskową/kontroli zbliżania) do następnej jednostki, która przejmie kontrolę lotu;

- zapewnienie przejęcia brakujących danych w planie lotu w przypadku rozbieżności we wstępnej dystrybucji danych w planie lotu;

- żądanie w razie konieczności przyznania oznaczenia kodowego SSR z jednostki, do której powyższe powiadomienie/koordynacja jest przesyłane.

7.2.2. Treść komunikatu

Komunikat PAC zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu (do wyboru);

- identyfikacja statku powietrznego;

- tryb i kod SSR;

- lotnisko odlotu;

- przewidywany czas startu lub prognozowane dane;

- lotnisko docelowe;

- typ statku powietrznego;

- trasę (do wyboru);

- inne dane dotyczące planu lotu (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

7.2.3. Zasady stosowania

7.2.3.1. Przepisy ogólne

7.2.3.1.1. Dla każdego lotu, który ma przekroczyć granicę obszaru odpowiedzialności, gdzie czas od startu do COP nie pozwoliłby na przesłanie komunikatu ACP w wymaganym czasie, jest wysyłany jeden lub więcej komunikatów PAC.

7.2.3.1.2. Dla każdego lotu odlatującego, dla którego wymagane jest powiadomienie lub koordynacja, jednostka lotniskowa/zbliżania przesyła jeden lub więcej komunikatów PAC do następnej jednostki.

7.2.3.1.3. Zalecenie

W celu wdrożenia PAC/LAM między jednostkami stosowne systemy TWR/APP powinny być wyposażone w środki umożliwiające wdrożenie i przesłanie informacji "ruszać", "cofać", "kołować" lub podobnych informacji, z których ETOT może być wyprowadzony w celu obliczenia ETO w COP i wprowadzenia przesyłu PAC.

7.2.3.1.4. Zgodnie z dwustronnymi uzgodnieniami komunikat zawiera:

- przewidywany czas startu;

lub

- prognozowane dane.

7.2.3.1.5. Kiedy na mocy umowy dwustronnej odnośnik komunikatu jest uwzględniony wówczas:

- zawiera numer komunikatu pierwszego komunikatu PAC przesłanego dla lotu;

- jest ujęty w drugim i kolejnym komunikacie PAC.

7.2.3.1.6. Jeśli jest wymagane użycie opcji żądania kodu, jest to uzgadniane dwustronnie.

7.2.3.1.7. Jeśli przed odlotem jeden z następujących warunków ma zastosowanie, wówczas zweryfikowany komunikat PAC jest przesyłany:

- trasa lotu została zmodyfikowana tak, że COP w poprzednim komunikacie nie jest już dokładna;

- typ statku powietrznego został zmieniony;

- lotnisko docelowe w poprzednim komunikacie PAC zostało uznane za błędne.

7.2.3.1.8. Zalecenie

Zweryfikowany komunikat PAC powinien być przesłany jeśli przed odlotem następujące dane różnią się od tych w poprzednim komunikacie PAC:

- poziom (w danych prognozowanych, jeśli występuje);

- oczekiwany kod SSR w punkcie przekazu kontroli;

- przewidywany czas odlotu lub ETO w COP, jeśli różnica przekracza czas uzgodniony dwustronnie;

- wystąpiła zmiana w innych danych, niż uzgodniono dwustronnie.

7.2.3.2. Przetwarzanie w jednostce odbiorczej

7.2.3.2.1. System ATC odbierając komunikat PAC, dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

7.2.3.2.2. Jeśli odpowiadający komunikatowi plan lotu został odnaleziony i nie występują żadne rozbieżności w komunikacie, które powstrzymywałyby prawidłowe jego przetwarzanie:

- treść operacyjna jest uwzględniana w planie lotu;

- wymagane dane są wdrażane w operacyjnej ATC i innych stosownych stanowiskach;

- LAM jest odsyłany.

7.2.3.2.3. Jeśli odpowiadający komunikatowi plan lotu nie może być odnaleziony albo występuje rozbieżność, która powstrzymuje prawidłowe jego przetwarzanie:

- jeśli można zidentyfikować sektor odpowiedzialny za przyjęcie kontroli tego lotu:

- operacyjna treść tego komunikatu jest wyświetlana w sektorze;

- LAM jest odsyłany;

- plan lotu jest tworzony;

- w pozostałych innych przypadkach LAM nie jest odsyłany.

7.2.3.2.4. Dane w drugim lub kolejnym komunikacie PAC zastępują dane w poprzednim komunikacie.

7.2.3.2.5. Jeśli komunikat PAC zawiera żądanie przyznania oznaczenia kodowego SSR i jest poprawnie przetworzony zgodnie z opisem w ppkt 7.2.3.2.2, komunikat COD jest zwracany w uzupełnieniu LAM.

UWAGA

Jako że proces przyznania oznaczenia kodowego wymaga szczegółowych informacji dotyczących tras ujętych w planie lotu, niniejszy dokument nie określa żadnych wymogów dla zwrotu komunikatu COD przez jednostkę odbiorczą, kiedy takie dane mogą być niedostępne dla lotu. W takich okolicznościach nie ogranicza to jednak możliwości zwrócenia komunikatu, jeśli taka możliwość występuje na poziomie lokalnym, a procedura została uzgodniona dwustronnie.

7.2.3.3. Parametry czasu przeznaczonego do przesyłu

Jeśli komunikat sygnalizujący bliski start lotu jest wysyłany w wyniku ręcznego wprowadzenia, wówczas przesyłowy parametr czasowy nie znajduje zastosowania.

7.2.4. Potwierdzenie PAC

7.2.4.1. Potwierdzenie

Komunikaty, które mają być przesłane w odpowiedzi na komunikat PAC, są opisane w ppkt 7.2.3.2 powyżej.

7.2.4.2. Brak potwierdzenia

W przypadku nieodebrania żadnego komunikatu potwierdzającego komunikat PAC wyświetla się ostrzeżenie na stanowisku jednostki ATC odpowiedzialnej za koordynację z następną jednostką.

7.2.4.3. Przypadki braku LAM

W przypadkach braku LAM wprowadzana jest koordynacja słowna.

7.2.4.4. Komunikat bez COD

7.2.4.4.1. Jeśli nie odebrano komunikatu COD w odpowiedzi na żądanie kodu zawarte w komunikacie PAC, na właściwym stanowisku wyświetla się ostrzeżenie.

7.2.4.4.2. Tam gdzie funkcja żądania kodu ma być użyta, zastosowanie wartości przyznanego czasu, który ma być zastosowany, jest uzgadniana dwustronnie.

7.2.5. Przykłady

7.2.5.1. Przewidywany czas startu i żądanie kodu

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. Czas w 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. Komunikat weryfikacji (REV)

7.3.1. Cel komunikatu weryfikacji REV

Komunikat weryfikacji jest wykorzystywany w celu przesyłu korekt do danych koordynacji uprzednio przesłanych w komunikacie ACT, pod warunkiem że jednostka akceptująca nie zmieni się w wyniku modyfikacji.

7.3.2. Treść komunikatu

Komunikat REV zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu (do wyboru);

- identyfikacja statku powietrznego;

- tryb i kod SSR (do wyboru);

- lotnisko odlotu;

- prognozowane dane;

- punkt koordynacji (do wyboru);

- lotnisko docelowe;

- trasę (do wyboru);

- inne dane dotyczące planu lotu (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

7.3.3. Zasady stosowania

7.3.3.1. Przepisy ogólne

7.3.3.1.1. Jeden lub więcej komunikatów jest przesyłanych do jednostki, do której lot jest koordynowany poprzez wykorzystanie komunikatu aktywacji.

7.3.3.1.2. Następujące elementy są poddane weryfikacji:

- ETO przy COP;

- poziom(-y) przekazu;

- kod SSR.

7.3.3.1.3. Komunikat REV jest wysyłany, gdy:

- ETO przy COP różni się od zamieszczonego w poprzednim komunikacie w stopniu większym niż dwustronnie uzgodniona wartość, z dokładnością do najbliższej liczby całkowitej;

- występuje zmiana w poziomie/poziomach przekazu lub kodzie SSR.

7.3.3.1.4. W przypadku dwustronnego uzgodnienia komunikat REV jest wysyłany, wówczas, gdy następuje zmiana niżej wymienionych elementów:

- COP;

- trasa;

- inne dane w planie lotu (ICAO dane pól 8, 10 i 18).

UWAGA

Zasady działania mogą wymagać, aby poprawki dokonane po ACT podlegały uprzedniej koordynacji między odnośnymi jednostkami.

7.3.3.1.5. W przypadku uzgodnienia dwustronnego odnośnik komunikatu jest uwzględniony w komunikacie REV.

7.3.3.1.6. Odnośnik komunikatu, jeśli jest uwzględniony, zawiera numer poprzedniego komunikatu ACT.

7.3.3.1.7. Jeśli jednostka odbiorcza ATC nie zapoczątkowuje koordynacji w celu zmiany warunków przekazu nałożonych przez komunikat REV, wówczas akceptacja tych warunków jest dokonywana przez jednostkę odbiorczą.

7.3.3.2. Formatowanie komunikatów weryfikacji

7.3.3.2.1. Format ICAO

Wszystkie komunikaty weryfikacji zawierają typy pól 3, 7, 13, 14 i 16. W zakresie tych pól są ulokowane następujące rodzaje korekt:

- zmiana ETO przy COP lub poziomu(-ów) przekazu jest uwzględniona przez wprowadzenie zweryfikowanych danych w polu 14;

- zmiana kodu SSR jest ujęta w polu 7;

- zmiany tras obejmujące zmiany w COP są uwzględniane w danych pól 14 i 15 zawartych w formacie pola 22 po początkowych pięciu polach. Takie komunikaty zawierają dwa pola 14, pierwsze zawierające tylko element a), COP poprzez który lot był poprzednio koordynowany. Zasady koordynacji takich zmian, w tym bezpośredniego ustalania trasy, są określone w załączniku B — Specjalne wymogi dotyczące ustalania trasy;

- zmiany w polach 8, 10 i 18 są uwzględniane jako dane pola 22 po początkowych pięciu polach.

7.3.3.2.2. Format ADEXP

Wszystkie komunikaty weryfikacji w formacie ADEXP zawierają następujące pola podstawowe: TITLE REFDATA ARCID ADEP ADES. Stosuje się następujące zasady:

- zmiana ETO przy COP lub poziomu(-ów) przekazu jest uwzględniona przez wprowadzenie zweryfikowanych danych w polu podstawowym COORDATA;

- zmiany tras, łącznie ze zmianami COP, są uwzględniane w polach podstawowych COORDATA i ROUTE. Takie komunikaty obejmują podstawowe pole COP zawierające punkt koordynacji, poprzez który lot był poprzednio koordynowany. Zasady koordynacji takich zmian, w tym bezpośredniego ustalania trasy są określone w załączniku B;

- zmiana kodu SSR wykazana jest przez uwzględnienie pola podstawowego SSRCODE;

- zmiany w innych danych planu lotu są uwzględniane poprzez włączenie wymaganego podstawowego pola/pól zgodnie z tym, jak zostało określone dla innych danych planu lotu w załączniku A.

Jeśli komunikat weryfikacji jest przesyłany w celu koordynacji kodu SSR i/lub innych danych planu lotu, podstawowe pole COP jest ujęte w miejscu COORDATA.

7.3.3.2.3. Kod SSR

Tryb SSR i kod SSR będą ujęte w komunikacie REV jedynie wówczas, kiedy jest to wymagane w celu koordynacji zmiany kodu SSR.

7.3.3.3. Przetwarzanie w jednostce odbiorczej

7.3.3.3.1. Jeśli ACT został odebrany dla lotu z tej samej jednostki ATC, system ATC odbierając komunikat REV dokonuje próby jego łączenia z odpowiadającym jemu planem lotu.

7.3.3.3.2. Jeśli odpowiadający komunikatowi plan lotu z tej samej jednostki jest odnaleziony i nie występuje rozbieżność, która powstrzymywałaby prawidłowe przetwarzanie komunikatu:

- treść operacyjna jest uwzględniana w planie lotu;

- wymagane dane są wdrażane na stanowiskach operacyjnych ATC i innych stosownych stanowiskach.

7.3.3.4. Zapoczątkowanie przesyłu

7.3.3.4.1. Komunikat REV jest uruchamiany dla danego przypadku i jest przesyłany niezwłocznie po stosownym wprowadzeniu lub uaktualnieniu.

7.3.3.4.2. Użycie komunikatu REV nie może spowodować żadnych zmian po tym, jak lot znajduje się w określonym czasie/odległości od punktu przekazania. Parametry czasu i odległości uzgadniane są dwustronnie.

7.3.3.4.3. Zalecenie

Parametry REV powinny być określone oddzielnie dla każdego COP.

7.3.3.5. Zmiana jednostki odbiorczej ATC

Jeśli weryfikacja danych planu lotu prowadzi do zmiany jednostki odbiorczej ATC, wówczas komunikat REV nie jest wykorzystywany (patrz komunikat dla odwołania koordynacji).

7.3.4. Potwierdzenie REV

7.3.4.1. Potwierdzenie

Jeśli komunikat REV:

- może być połączony z planem lotu w ramach systemu odbiorczego — komunikat LAM jest przesyłany w potwierdzeniu;

- nie może być połączona z planem lotu w ramach systemu odbiorczego — komunikat LAM nie jest przesyłany.

7.3.4.2. Brak potwierdzenia

7.3.4.2.1. Jeśli nie otrzymano żadnego komunikatu LAM jako potwierdzenie komunikatu REV wyświetla się ostrzeżenie na stanowisku ATC odpowiedzialnym za koordynację lotów.

7.3.4.2.2. W przypadkach braku LAM jednostka przekazująca ATC wprowadza słowną weryfikację.

7.3.5. Przykłady

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. Komunikat dla odwołania koordynacji (MAC)

7.4.1. Cel komunikatu MAC

Komunikat MAC jest wykorzystywany w celu wskazania jednostce odbiorczej, że koordynacja lub powiadomienie stosowane poprzednio dla lotu jest odwoływane.

MAC nie zastępuje komunikatu anulowania (CNL) określonego przez ICAO i dlatego nie jest używany do usuwania podstawowych danych w planie lotu.

7.4.2. Treść komunikatu

Komunikat MAC zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu (do wyboru);

- identyfikacja statku powietrznego;

- lotnisko odlotu;

- punkt koordynacji;

- lotnisko docelowe;

- status koordynacji i powód (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

7.4.3. Zasady stosowania

7.4.3.1. Przepisy ogólne

7.4.3.1.1. Komunikat MAC jest przesyłany do jednostki, do której koordynacja lotu była uprzednio wykonywana z wykorzystaniem komunikatów ACT lub RAP, kiedy ma miejsce jeden z następujących przypadków:

- spodziewany poziom w punkcie przekazu różni się od poziomu zawartego w poprzednim komunikacie, czego wynikiem jest zmiana następnej jednostki w sekwencji koordynacji;

- trasa lotu została zmieniona, czego wynikiem jest zmiana następnej jednostki w sekwencji koordynacji;

- systemowy plan lotu jest anulowany w jednostce wysyłającej i koordynacja nie znajduje już zastosowania;

- w odniesieniu do lotu MAC jest odebrany z poprzedniej jednostki.

7.4.3.1.2. Kiedy komunikat MAC jest wysyłany z powodu zmiany poziomu lotu lub trasy, powiadomienie i/lub koordynacja, w zależności od zastosowania, są wykonywane w nowej jednostce w sekwencji koordynacji.

7.4.3.1.3. Komunikat MAC jest wysyłany, kiedy koordynacja dla lotu startującego, wykonana z wykorzystaniem komunikatu PAC, jest odwołana.

7.4.3.1.4. Zalecenie

Komunikat MAC powinien być wysłany, kiedy powiadomienie (komunikat ABI) poprzednio wykonywane dla lotu jest anulowane z powodu przyczyn określonych w ppkt 7.4.3.1.1 powyżej lub lot jest opóźniony na trasie i weryfikowana prognoza nie może być ustalona automatycznie.

7.4.3.1.5. Odnośnik komunikatu jest uwzględniany, jeśli zostało to uzgodnione dwustronnie.

7.4.3.1.6. Jeśli został uwzględniony odnośnik komunikatu zawiera on komunikat o numerze ostatniego komunikatu ABI, PAC lub ACT przesłanego dla lotu i potwierdzonego.

7.4.3.1.7. Punktem koordynacji jest COP, poprzez który lot był poprzednio powiadamiany lub koordynowany.

7.4.3.1.8. Zalecenie

Komunikat MAC powinien określać status, do którego koordynacja lub powiadomienie ma być zawrócone oraz powód odwołania.

7.4.3.1.9. Jeśli zostały uwzględnione, status i powód stanowią jedną z następujących kombinacji:

- kiedy jednostka odbiorcza nie jest już następnym partnerem koordynacji:

- status jest INI (początkowy);

- powodem jest jedna z następujących przyczyn:

- TFL, jeśli przyczyną jest zmiana poziomu przekazu;

- RTE, jeśli przyczyną jest zmiana trasy;

- CSN, jeśli przyczyną jest zmiana znaku wywoławczego;

- CAN, jeśli przyczyną jest anulowanie;

- OTH dla każdej innej przyczyny lub gdy przyczyna jest nieznana;

- kiedy jeden z następujących warunków znajduje zastosowanie:

- koordynacja wykonana z wykorzystaniem poprzedniego komunikatu PAC lub ACT (ewentualnie zmodyfikowana przez każdy kolejny komunikat REV) jest odwołana, ale oczekuje się, że lot będzie przedmiotem nowej sekwencji koordynacji w ramach tej samej jednostki;

lub

- lot następujący po przesłaniu komunikatu ABI jest przetrzymywany przez nieokreślony okres czasu i oczekuje się, że będzie przedmiotem weryfikowanej ABI lub ACT, w zależności od zastosowania:

- status jest NTF (powiadomienie);

- powodem jest jedna z następujących przyczyn:

- DLY, jeśli przyczyną jest opóźnienie;

- HLD, jeśli przyczyną jest zatrzymanie;

- OTH dla każdej innej przyczyny lub gdy przyczyna nie jest znana.

7.4.3.1.10. Jeśli lot ma być notyfikowany ponownie lub ponownie koordynowany:

- nowe powiadomienie i/lub komunikat koordynacji, w zależności od tego, co będzie uznane za właściwe, jest wysyłane;

- komunikat MAC nie wpływa na podstawowe dane planu lotu przechowywane w jednostce odbiorczej ATC;

- system utrzyma zdolność poprawnego przetwarzania nowego powiadomienia i/lub komunikatu koordynacji z poprzedniej jednostki przekazującej lub innej jednostki w nowej sekwencji koordynacji.

7.4.3.2. Przetwarzanie w jednostce odbiorczej

Stanowisko(-a) pracy w jednostce odbiorczej ATC, które posiadają szczegóły dotyczące lotu są powiadamiane o odwołaniu.

7.4.4. Potwierdzenie MAC

7.4.4.1. Potwierdzenie

7.4.4.1.1. Jeśli komunikat MAC może być połączony z planem lotu w ramach systemu odbiorczego i może być przetworzony, komunikat LAM jest przesyłany w potwierdzeniu.

7.4.4.1.2. Jeśli komunikat MAC nie może być połączony z planem lotu w ramach systemu odbiorczego lub nie może być przetworzony, komunikat LAM nie jest przesyłany.

7.4.4.2. Brak potwierdzenia

7.4.4.2.1. Jeśli koordynacja ATC jest w trakcie odwołania i nie odebrano żadnego komunikatu LAM, ostrzeżenie wyświetla się na stanowisku ATC odpowiedzialnym za koordynację.

7.4.4.2.2. W takich przypadkach słowne odwołanie koordynacji jest wykonywane przez jednostkę przekazującą.

7.4.5. Przykłady

Komunikat ABI został przesłany z Amsterdamu ACC do Brukeli ACC dla lotu HOZ3188, zaplanowanego na poziom lotu FL190; lot następnie prosi o zgodę na wzniesienie się na poziom FL270, otrzymuje na to zgodę, wchodząc w ten sposób w przestrzeń powietrzną Maastricht zamiast Brukseli. Przykłady ppkt 7.4.5.1 a oraz ppkt 7.4.5.2 a pokazują, jak MAC wysłany do Brukseli przez Amsterdam ukazywałby formaty zarówno ICAO, jak i ADEXP.

Komunikaty ABI, później ACT są wysyłane do Maastricht, ale na kilka minut przed osiągnięciem COP statek powietrzny zawraca do portu lotniczego w Amsterdamie i plan lotu jest anulowany w systemie jednostki wysyłającej; MAC jest wysłany do Maastricht, jak pokazują przykłady (ppkt 7.4.5.1 b i ppkt 7.4.5.2 b).

7.4.5.1. ICAO

a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL)

b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN)

7.4.5.2. ADEXP

a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL

b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN

7.5. Komunikat przyznania oznaczenia kodowego (COD)

7.5.1. Cel komunikatu COD

7.5.1.1. Celem metody przyznawania oznaczeń kodowych pochodzących z danego regionu (ORCAM) jest zezwolenie statkowi powietrznemu na udzielenie odpowiedzi na ten sam kod kolejnym jednostkom w ramach uczestniczącego obszaru. Jeśli przyznanie kodu nie jest wykonywane centralnie, np. przez ACC, może zaistnieć potrzeba wyposażenia portów lotniczych w zestaw osobnych kodów SSR. Takie przyznawanie kodów jest dużym marnotrawstwem.

7.5.1.2. W razie konieczności komunikat COD spełnia wymogi operacyjne dla emisji kodu SSR trybu A przez jeden organ służb ruchu lotniczego (ATS) do innego dla określonego lotu. Dowolne programy wspomagające zezwalają jednostce emisyjnej włączyć trasę lotu, jeśli zostało to uzgodnione dwustronnie.

7.5.2. Treść komunikatu

Komunikat COD zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu (do wyboru);

- identyfikację statku powietrznego;

- tryb i kod SSR;

- lotnisko odlotu;

- lotnisko docelowe;

- trasę (do wyboru).

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

7.5.3. Zasady stosowania

7.5.3.1. Przepisy ogólne

7.5.3.1.1. Komunikat COD jest wytwarzany i przesyłany automatycznie w odpowiedzi na żądanie przyznania kodu odebrane w komunikacie.

7.5.3.1.2. Kod SSR jest kodem przyznawanym dla lotu.

7.5.3.1.3. Zatwierdzony kod nasycenia, jak zostało określone w Planie Nawigacji Lotniczej dla Regionu Europejskiego, jest dodany, jeśli osobny kod nie jest dostępny.

7.5.3.1.4. Jeśli zostało to uzgodnione dwustronnie, uwzględniany jest odnośnik komunikatu zawierający numer komunikatu, w odpowiedzi na który pojawia się COD.

7.5.3.1.5. Trasa jest uwzględniona, jeśli zostało to uzgodnione dwustronnie.

7.5.3.1.6. Zakłada się zaakceptowanie kodu SSR przez jednostkę odbierającą komunikat COD.

7.5.3.2. Przetwarzanie w jednostce odbiorczej

7.5.3.2.1. Pod warunkiem że nie występują rozbieżności w komunikacie, które powstrzymywałyby prawidłowe przetwarzanie, LAM jest odsyłany.

7.5.3.2.2. Jeśli komunikat nie może być połączony z planem lotu lub występują rozbieżności, które powstrzymują prawidłowe przetwarzanie komunikatu, LAM nie jest odsyłany.

7.5.3.2.3. Dane dotyczące trasy, jeśli występują, nie są przyczyną powstrzymania odesłania LAM, chyba że nie spełniają wymogów formatu określonych w załączniku A.

7.5.3.3. Parametry czasu przeznaczonego do przesyłu

Parametru czasu przeznaczonego do przesyłu nie mają zastosowania, jeśli komunikat COD jest wysyłany jako wynik odbioru komunikatu żądającego przyznania kodu SSR.

7.5.4. Potwierdzenie COD

7.5.4.1. Potwierdzenie

Komunikat COD jest potwierdzany poprzez wytworzenie komunikatu LAM.

7.5.4.2. Brak potwierdzenia

Jeśli nie otrzymano żadnego komunikatu stanowiącego potwierdzenie komunikatu COD, ostrzeżenie wyświetla się na właściwym stanowisku.

7.5.5. Przykłady

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. Komunikat informacji (INF)

7.6.1. Cel komunikatu INF

7.6.1.1. Komunikat INF jest wykorzystywany w celu udzielenia informacji agencjom na temat określonych lotów niezaangażowanych bezpośrednio w proces koordynacji między dwiema kolejnymi jednostkami ATC na trasie lotu.

7.6.1.2. Komunikat INF może być wykorzystywany w celu przekazywania kopii komunikatów oraz w celu informowania tych agencji o uzgodnionych warunkach koordynacji w następstwie porozumiewania się kontrolerów. W tym celu komunikaty INF mogą być wytwarzane przez systemy w jednostce przesyłającej lub akceptującej.

7.6.1.3. Komunikat może być również wykorzystany w celu przekazywania agencji informacji na temat dowolnego punktu na trasie lotu.

7.6.1.4. Format pozwala na komunikowanie danych początkowych, weryfikacje oraz anulowania.

7.6.2. Treść komunikatu

Komunikat INF zawiera następujące elementy danych w formacie komunikatu opisanego w niniejszym dokumencie.

- rodzaj komunikatu;

- numer komunikatu;

- wszystkie elementy danych operacyjnych w takiej formie, w jakiej znajdowały się w oryginalnym komunikacie lub wynikające z kopiowania koordynacji;

- rodzaj komunikatu odniesienia.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

7.6.3. Zasady stosowania

7.6.3.1. Rodzaje komunikatów

Rodzaj komunikatu, który ma być podwojony przez komunikat INF, jest oparty na wymogach użytkowników i możliwości jednostki wysyłającej. Rodzaj komunikatu i zasady stosowania są ustalane dwustronnie.

7.6.3.2. Adresy komunikatów

Dla tego samego lotu można przesłać jeden lub więcej komunikatów na jeden lub więcej adresów.

7.6.3.3. Treść operacyjna

Treść operacyjna komunikatu INF jest w formacie jednego z istniejących komunikatów.

7.6.3.4 Zalecenia

1. Warunki przekazane do początkowego komunikatu dialogu (np. komunikaty ACT, RAP, REV, RRV) mogą być zmienione lub odrzucone przed ukończeniem dialogu. Jednostki wysyłające powinny być zdolne do przesłania ostatecznie uzgodnionych warunków koordynacji.

2. Komunikat INF powinien zostać przesłany niezwłocznie lub w czasie odnoszącym się do czasu w COP, w zależności od dwustronnych uzgodnień z agencją odbiorczą.

7.6.4. Potwierdzenie INF

Zalecenia

1. Komunikat INF może być potwierdzony w zależności od partnera koordynacji poprzez wytworzenie i przesłanie komunikatu LAM.

2. Na mocy umowy dwustronnej między odnośnymi jednostkami, w przypadku nieodebrania komunikatu LAM będącego potwierdzeniem komunikatu INF, ostrzeżenie wyświetli się na właściwym stanowisku.

7.6.5. Przykłady

Lot ze znakami wywoławczymi BAW011, B747 z EGLL do OMDB na FL290, żądający FL410, przewiduje Koksy (KOK) VOR o 1905, nadaje na A5437, przechodzi przez UG1 i UB6.

Komunikat ACT został wysłany przez Londyn do Maastricht dla tego lotu. Kopia została przesłana z Londynu do jednostki określonej jako IT.

Poniżej zostały przedstawione przykłady komunikatu 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. PROCEDURA DIALOGU — KOORDYNACJA

8.1. Przepisy ogólne

8.1.1. Wstęp

8.1.1.1. Procedura dialogu umożliwia komunikację i negocjacje między kontrolerami w fazie koordynacji oraz komunikacji w fazie przekazu.

8.1.1.2. Niniejszy podpunkt opisuje komunikaty stosowane w procedurze dialogu w fazie koordynacji, gdzie warunki przekazu są zaplanowane. Komunikaty dla fazy przekazu, gdzie przekazanie lotu jest zakończone, są opisane w pkt 9 — Procedura dialogu — przekaz łączności.

8.1.1.3. Procedury dla dwóch faz są niezależne od siebie; mogą być wdrożone osobno bądź razem.

8.1.1.4. Zostało wprowadzonych wiele dodatkowych komunikatów i dla każdego z partnerów możliwe jest zainicjowanie dialogu.

8.1.1.5. Procedura koordynacji dialogu umożliwia identyfikację:

- przekazów, które są zgodne z umowami (LoA) i mogą być automatycznie zaakceptowane;

- przekazów, które muszą być zasygnalizowane kontrolerowi w jednostce odbiorczej do podjęcia decyzji dotyczących akceptacji.

8.1.1.6. Procedura ta umożliwia interpretację umów (LoA) w dwóch monitorowanych systemach i zidentyfikowanie każdej niezgodności między nimi.

8.1.2. Filtr

8.1.2.1. Przepisy ogólne

8.1.2.1.1. Procedura koordynacji dialogu wymaga by system sprawdzał, czy przekazy są zgodne z umowami (LoA).

8.1.2.1.2. Działanie, które sprawdza taką zgodność jest określone w niniejszym dokumencie jako "filtr". Baza danych używana dla filtra będzie zawierać następujące składniki, jeżeli są wymagane:

- uzgodnione punkty koordynacji;

- odpowiednie (bądź nieodpowiednie) poziomy lotu, które mogą być również powiązane z punktami koordynacji;

- lotniska odlotu;

- lotniska docelowego;

- zaakceptowane trasy bezpośrednie;

- ograniczenia czasu i/lub odległości przed COP, po którym każdy komunikat koordynacji jest uważany jako niestandardowy;

- każde inne warunki, jak obustronnie uzgodnione.

8.1.2.1.3. Wszystkie pozycje na tym wykazie mogą być łączone do stworzenia bardziej zróżnicowanych warunków.

8.1.2.1.4. W pkt 8 niniejszego dokumentu pojęcie "warunki standardowe" powinno być traktowane jako "zgodne z umową (LoA)", a pojęcie "warunki niestandardowe" jako "niezgodne z umową (LoA)". Jeżeli nie uzgodniono obustronnie, komunikaty wysłane przez jednostki przekazujące dla koordynacji, które są uznane za standardowe, stosują inny rodzaj komunikatów od tych, dla których warunki są niestandardowe.

8.1.2.2. Działanie jednostki przekazującej

8.1.2.2.1. Filtr w jednostce przekazującej dokonuje przeglądu warunków przekazu, które są gotowe do wysłania do jednostki akceptującej.

8.1.2.2.2. Zalecenie

Jeżeli warunki przekazu są uznane jako niestandardowe, informacja ta powinna być zgłoszona kontrolerowi przekazującemu, do zatwierdzenia lub zmiany.

8.1.2.3. Działanie jednostki akceptującej

8.1.2.3.1. Wszystkie komunikaty ACT i REV są sprawdzone przez filtr.

8.1.2.3.2. Jeżeli kontrola wykaże, że odebrane warunki przekazu są niestandardowe, powinny być one wówczas zgłoszone kontrolerowi w celu podjęcia decyzji, w innym przypadku są akceptowane automatycznie.

8.1.2.4. Synchronizacja filtrów

8.1.2.4.1. Używanie różnych depesz dla standardowych i niestandardowych warunków przekazu umożliwia wykrycie każdej niezgodności między warunkami standardowymi w systemach w jednostkach przekazujących i akceptujących.

8.1.2.4.2. Identyfikacja w jednostce akceptującej niestandardowych warunków przekazu w komunikacie używanego do koordynacji wyłącznie przekazów standardowych będzie oznaczać różnicę między dwoma filtrami. Takie niezgodności powinny być rozwiązane w celu wydajnej działania procedury dialogu.

8.1.3. Sekwencja komunikatu

8.1.3.1. Przepisy ogólne

8.1.3.1.1. Niektóre przepisy wymagają upewnienia się, że koordynacja jest zakończona zanim nastąpi jakakolwiek korekta lub wymiana przekazu komunikatu łączności, jak również aby upewnić że kontrolerzy obu jednostek nie obsługują równocześnie tego samego lotu.

8.1.3.1.2. Jednostka ATC wyłącznie przekazuje lub potwierdza odbiór komunikatu weryfikacji (REV lub RRV) dla lotu będącego w stanie koordynacji, tj. ACT lub RAP zostały zakończone przez LAM lub ACP.

8.1.3.1.3. Komunikaty CDN są używane do przesyłu przez jednostkę akceptującą.

8.1.3.1.4. Komunikaty CDN są wyłącznie przesyłane i potwierdzane:

- jako część dialogu zainicjowana przez odbiór komunikatu aktywacji (ACT, RAP) lub weryfikacji (REV lub RRV); lub

- kiedy plan lotu dla danego lotu jest w stanie koordynacji.

8.1.4. Jednoczesne stosowanie komunikatów

8.1.4.1. Przepisy ogólne

8.1.4.1.1. Jednostka zaangażowana w koordynację lub wymianę komunikatów przekazu dla lotu nie inicjuje dalszej koordynacji lub wymiany komunikatów przekazu dla tego samego lotu w tej samej jednostce, gdy został otrzymany LAM, AKP lub RJC lub gdy nastała przerwa.

8.1.4.1.2. Dla komunikatów CDN możliwe jest skrzyżowanie z komunikatem REV, RRV lub MAC dla tego samego lotu wysłanego z jednostki przekazującej. Ta sytuacja może być sprawdzona w jednostce przekazującej poprzez przychodzący CDN przed potwierdzeniem przesłanego komunikatu koordynacji oraz w jednostce akceptującej poprzez komunikat z jednostki przekazującej przychodzącej przed potwierdzeniem CDN. W tym przypadku CDN nie jest potwierdzany, a REV, RRV lub MAC nie są przetwarzane.

8.1.5. Obsługiwanie odrzucenia

Komunikat RJC wstrzymuje dialog systemu. Musi zostać zainicjowana nowa koordynacja systemowa, która wymusi koordynację telefoniczną, gdzie to jest konieczne.

8.1.6. Operacyjna odpowiedź przerwy

8.1.6.1. Przepisy ogólne

8.1.6.1.1. Procedura przerwy jest stosowana w centrach wysyłu i odbioru w celu udzielenia odpowiedzi na komunikaty przekazywane do kontrolera.

8.1.6.1.2. Czas trwania przerw powinien być obustronnie uzgodniony.

8.1.6.1.3. Wygaśnięcie przerwy w jednostce przekazującej skutkuje ostrzeżeniem przesłanym kontrolerowi przekazującemu, w celu wskazania konieczności interwencji telefonicznej.

8.1.6.1.4. Zalecenia

1. Ostrzeżenie powinno być wyświetlone na stanowisku ATC w jednostce akceptującej odpowiedzialnej za lot, kiedy przerwa w jednostce przekazującej jest bliska.

2. Ostrzeżenie powinno uwzględniać czas przesyłu odpowiedzi.

8.1.6.1.5. Systemy posiadają możliwości do przetwarzania odpowiedzi które są odbierane po wygaśnięciu przerwy.

8.1.7. Stosowanie

8.1.7.1 Procedury dialogu skierowane są do dwóch faz, fazy koordynacji i fazy przekazu. Dialog w dwóch fazach używa różnych depesz. Wymagane czasy transakcji również są różne. Komunikaty koordynacji są określone w formatach ICAO i ADEXP, przekaz komunikatów łączności wyłącznie w ADEXP.

8.1.7.2 Minimalne wymagania HMI dla dialogu koordynacji różnią się od tych dla dialogu przekazu:

- dialog przekazu skierowany jest najpierw do funkcji wykonawczo-kontrolnej i wymaga HMI szybkiego i przyjaznego dla użytkownika;

- dialog koordynacji nie jest tak krytyczny czasowo, więc jego wymagania HMI są mniejsze.

8.1.7.3 Procedura dialogu jest wdrażana z wykorzystaniem jednego z poniższych scenariuszy:

- procedura dialogu fazy koordynacji oraz jakiekolwiek uzupełniające komunikaty, jak zostało to obustronnie uzgodnione (pkt 7 i 8);

- podstawowa procedura koordynacji i procedura dialogu fazy przekazu (pkt 6, 7 i 9);

- procedura dialogu fazy koordynacji i przekazu oraz jakiekolwiek uzupełniające komunikaty koordynacji, jak zostało to obustronnie uzgodnione (pkt 7, 8 i 9).

Komunikat zaawansowanej informacji o przecięciu granicy jest wysyłany we wszystkich podanych scenariuszach.

8.1.7.4 Scenariusz używany w celu wdrożenia jest obustronnie uzgodniony.

8.2. Komunikat aktywacji (ACT)

8.2.1. Cel komunikatu ACT

Cel komunikatu ACT jest opisany w ppkt 6.3.1. W procedurze dialogu komunikat ACT jest używany w celu spełnienia tych wymagań, jeżeli tylko warunki przekazu dla lotu są standardowe i kontroler przekazujący nie wymaga przekazania lotu do kontrolera akceptującego do akceptacji.

8.2.2. Treść komunikatu

Treść komunikatu ACT używanego w procedurze dialogu jest opisana w ppkt 6.3.2 dla komunikatu ACT.

8.2.3. Zasady stosowania

8.2.3.1. Przepisy ogólne

8.2.3.1.1. Zasady stosowania są takie, jak opisane w ppkt 6.3 dla ACT, z wyjątkiem zasad specjalnych opisanych w niniejszym podpunkcie.

8.2.3.1.2. Komunikat ACT jest wysłany dla lotu standardowymi warunkami przekazu których kontroler przekazujący nie wymaga, by były przekazane do kontrolera akceptującego.

UWAGA

Jeżeli te wymagania nie są spełnione, RAP jest wysłany (patrz ppkt 8.3 komunikat przedłożenia propozycji aktywacji).

8.2.3.1.3. Zalecenie

Nowa procedura koordynacji powinna zostać zainicjowana, kiedy komunikat odrzucenia koordynacji (RJC) jest zwrócony w odpowiedzi na komunikat ACT.

8.2.3.2. Przetwarzanie w jednostce odbiorczej

8.2.3.2.1. Komunikat jest sprawdzany przez filtr w celu potwierdzenia, że proponowane warunki są standardowe.

8.2.3.2.2. Komunikat jest przetwarzany jako komunikat RAP, jeżeli:

- warunki przesyłu okażą się niestandardowe;

- plan lotu odpowiadający systemowi nie może zostać znaleziony i nie ma wystarczającej informacji do sprawdzenia, czy warunki przekazu są standardowe.

8.2.3.2.3. Komunikaty ACT uznane za standardowe są przetwarzane zgodnie z ppkt 6.3.3.2.

8.2.3.2.4. Zalecenie

Jeżeli warunki przekazu komunikatu ACT okażą się niestandardowe, istnieje wówczas rozbieżność między filtrami w dwóch systemach. Fakt, że ACT jest niestandardowy, powinien zostać zgłoszony personelowi nadzorczemu w celu usunięcia tych rozbieżności.

8.2.4. Potwierdzenie ACT

8.2.4.1. Potwierdzenie

8.2.4.1.1. W procedurze dialogu komunikat ACT jest potwierdzony przez:

- LAM, jeżeli warunki przekazu są standardowe;

- komunikat SBY we wszystkich innych przypadkach.

8.2.4.1.2. Kiedy LAM zostanie odebrany, treść operacyjna komunikatu ACT jest operacyjnie wiążąca dla dwóch jednostek ATC.

8.2.4.1.3. Tam gdzie zostało to obustronnie uzgodnione, ACP może być zastosowany w miejsce LAM w celu wskazania akceptacji ACT zawierającej standardowe warunki przekazu przez jednostkę akceptującą.

8.2.4.2. Przypadki braku potwierdzenia

Jeżeli nie otrzymano potwierdzenia na komunikatu ACT, wówczas wyświetlane ostrzeżenie w na stanowisku ATC odpowiedzialnym za koordynację lotu.

8.3. Komunikat przedłożenia propozycji aktywacji (RAP)

8.3.1. Cel komunikatu RAP

Komunikat RAP spełnia następujące wymagania operacyjne, w uzupełnieniu do tych opisanych dla komunikatu ACT w ppkt 6.3:

- propozycja kontrolera przekazującego i przekaz do kontrolera akceptacji lotów z niestandardowymi warunkami przekazu;

- umożliwić kontrolerowi przekazującemu, jeżeli tego wymaga, skierowanie się do kontrolera akceptującego o standardowe warunki przekazu danego lotu.

8.3.2. Treść komunikatu

Treść komunikatu RAP zawiera te same dane, które są opisane dla komunikatu ACT (ppkt 6.3) i może opcjonalnie zawierać elementy następujących danych:

- powód, wskazujący źródło informacji (możliwe wyłącznie w ADEXP).

8.3.3. Zasady stosowania

8.3.3.1. Przepisy ogólne

8.3.3.1.1. Komunikat RAP jest wysłany w miejsce komunikatu ACT dla lotów przecinających granicę spełniających jeden z następujących warunków:

- system przekazujący określił warunki przekazu jako niestandardowe;

- kontroler przekazujący wskazał, iż proponowane warunki przekazu mają być przekazane kontrolerowi akceptującemu.

8.3.3.1.2. Operacyjna treść komunikatu RAP, która ma być przesłana, jest wyświetlana na stanowisku pracy odpowiedzialnym za koordynację lotu przed rzeczywistym przesyłem.

8.3.3.1.3. Zalecenie

Czas, w którym komunikat RAP jest przesyłany, powinien być automatycznie wyświetlony razem z jego treścią.

8.3.3.1.4. Odpowiednie stanowisko pracy jest zawiadomione o przesyle komunikatu RAP.

8.3.3.2. Przetwarzanie w jednostce odbiorczej

8.3.3.2.1. System ATC odbierający komunikat RAP dokonuje próby jego połączynia z odpowiedającym mu planem lotu.

8.3.3.2.2. Jeżeli plan lotu odpowiadający komunikatowi został znaleziony oraz nie stwierdzono żadnej niezgodności w komunikacie, która wstrzymałaby proces przetwarzania:

- treść operacyjna jest przedstawiana kontrolerowi akceptującemu;

- komunikat SBY jest zwracany.

8.3.3.2.3. Zalecenie

Wskazanie powodu przekazania (warunki niestandardowe lub ręczne przekazanie) powinno być uwzględnione.

8.3.3.2.4. Jeżeli komunikat nie może być połączony z planem lotu albo występuje niezgodność, która wstrzymuje prawidłowe przetwarzanie komunikatu wówczas:

- operacyjna treść komunikatu jest wyświetlana w sektorze;

oraz

- komunikat SBY jest zwracany;

oraz

- plan lotu jest tworzony.

8.3.3.2.5. We wszystkich innych przypadkach komunikat nie jest potwierdzany.

8.3.3.3. Start ręczny

8.3.3.3.1. Jeśli komunikat RAP jest używany w celu przedstawienia kontrolerowi akceptującemu proponowanej koordynacji z wykorzystaniem standardowych warunków przekazu, komunikat RAP jest inicjowany ręcznie przez kontrolera przekazującego i jest niezwłocznie przesyłany.

8.3.3.3.2. Zalecenie

Ręczne uruchomienie komunikatu RAP przed obliczonym czasem przesyłu powinno być dozwolone na stanowisku odpowiedzialnym za koordynację lotu.

8.3.3.4. Parametry dla przesyłu automatycznego

Czas/odległość przed granicą, w której komunikaty RAP są automatycznie przesyłane, jest identyczny, jak dla komunikatu ACT.

8.3.4. Potwierdzenie komunikatu RAP

8.3.4.1. Potwierdzenie

Komunikat jest potwierdzony poprzez wytworzenie i przesłanie komunikatu SBY.

8.3.4.2. Przypadek braku potwierdzenia

Jeżeli nie został otrzymany komunikat SBY jako potwierdzenie komunikatu RAP, ostrzeżenie jest wyświetlane na stanowisku ATC odpowiedzialnym za koordynację lotu.

8.3.5. Odpowiedź operacyjna na RAP

Kontroler akceptujący może zaakceptować propozycję, złożyć kontrpropozycję lub odrzucić warunki przesyłu.

8.3.5.1. Akceptacja

8.3.5.1.1. Kiedy kontroler akceptujący zaakceptuje zaproponowane warunki przesyłu, wówczas komunikat AKP jest zwracany.

8.3.5.1.2. Kiedy tylko komunikat ACP zostaje odebrany, dane komunikatu RAP stają się operacyjnie wiążące dla obydwu jednostek ATC. Skoordynowane warunki przekazu oraz fakt że komunikat ACP został odebrany są przedstawiane kontrolerowi przekazującemu.

8.3.5.2. Kontrpropozycja

Kiedy kontroler akceptujący wybiera złożenie kontrpropozycji do zaproponowanych warunków, komunikat CDN jest zwracany.

8.3.5.3 Zalecenie

Kiedy kontroler akceptujący odrzuci zaproponowane warunki przekazu, komunikat RJC powinien być zwrócony. Wówczas powinien zostać zainicjowany nowy proces koordynacji.

UWAGA

W odniesieniu do zalecenia 8.3.5.3 w większości przypadków nowa koordynacja będzie miała miejsce w innej jednostce.

8.3.6. Przykłady

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. Komunikat weryfikacji (REV)

8.4.1. Cel komunikatu weryfikacji REV

Cel komunikatu REV jest opisany w ppkt 7.3.1. W procedurze dialogu komunikat REV jest używany w celu spełnienia tych wymagań, jeżeli tylko warunki przekazu dla danego lotu są standardowe, a kontroler przekazujący nie wymaga przekazania lotu kontrolerowi akceptującemu celem akceptacji.

8.4.2. Treść komunikatu

Treść komunikatu REV jest identyczna, jak została opisana w ppkt 7.3.2.

8.4.3. Zasady stosowania

8.4.3.1. Przepisy ogólne

8.4.3.1.1. Jeden lub więcej komunikatów REV może być wysyłanych do jednostki, z którą lot został obecnie skoordynowany z wykorzystaniem komunikatów aktywacja lub RAP.

8.4.3.1.2. Komunikat REV jest wysyłany zgodnie z warunkami określonymi w ppkt 7.3.3.1 dla lotów ze standardowymi warunkami przekazu, których kontroler przekazujący nie wymaga, aby były przekazane kontrolerowi akceptującemu.

8.4.3.2. Zapoczątkowanie przesyłu

Komunikat REV jest wysyłany niezwłocznie po wykryciu zmiany w danych koordynacji wymaganych do koordynacji, jak opisano w ppkt 7.3.3.

8.4.3.3. Przetwarzanie w jednostce odbiorczej

8.4.3.3.1. Jeżeli odpowiadający plan lotu jest znaleziony w stanie koordynacji i nie znaleziono żadnych nieprawidłowości, które wstrzymałyby prawidłowe przetwarzanie komunikatu, wówczas:

- komunikat REV jest potwierdzany;

- w innych przypadkach komunikat REV nie jest potwierdzany.

8.4.3.3.2. Warunki przekazu są sprawdzane w celu upewnienia się, że są one standardowe.

8.4.3.3.3. Jeżeli warunki przekazu są niestandardowe, wówczas są przekazywane kontrolerowi akceptującemu.

8.4.3.3.4. Jeżeli zaproponowane warunki okażą się standardowe, wówczas są włączane do planu lotów i wymagane dane ukazują się w operacyjnych stanowiskach ATC i w innych stanowiskach uznanych za właściwe.

8.4.3.3.5. Zalecenie

Jeżeli warunki przekazu komunikatu REV okażą się niestandardowe, istnieje wówczas rozbieżność między filtrami w dwóch systemach. Fakt, że REV jest niestandardowy, powinien być zgłoszony personelowi nadzorującemu w celu usunięcia tych rozbieżności.

8.4.4. Potwierdzenie komunikatu REV

8.4.4.1. Potwierdzenie

8.4.4.1.1. Jeżeli komunikat REV ma być potwierdzony, musi być to wykonane przez:

- komunikat LAM, jeżeli warunki przekazu okażą się standardowe;

- komunikat SBY, jeżeli warunki przekazu okażą się niestandardowe.

8.4.4.1.2. Kiedy komunikat LAM jest odebrany, operacyjna treść komunikatu REV staje się operacyjnie wiążąca dla obydwu jednostek ATC.

8.4.4.1.3. Tam gdzie zostało to obustronnie uzgodnione, ACP może być zastosowana zamiast LAM w celu potwierdzenia poprzez jednostkę akceptującą,, iż REV zawiera standardowe warunki przekazu.

8.4.4.2. Przypadki braku potwierdzenia

Jeżeli nie otrzymano potwierdzenia na komunikat REV, wówczas wyświetla się ostrzeżenie na stanowisku ATC odpowiedzialnym za koordynację lotów.

8.4.5. Operacyjna odpowiedz na REV

Jako że komunikat REV jest stosowany do wysyłania standardowych warunków przekazu, jest więc zazwyczaj akceptowany przez system w jednostce akceptującej. Jeżeli w wyniku działania filtra w jednostce akceptującej warunki transferu okażą się być niestandardowe, komunikat będzie przetwarzany jako komunikat RRV.

8.5. Komunikat przedłożenia propozycji weryfikacji (RRV)

8.5.1. Cel komunikacie RRV

Komunikat RRV umożliwia weryfikację ostatnio wysłanych i zaakceptowanych warunków przekazu w następujących przypadkach:

- kiedy zaproponowane warunki przekazu podczas weryfikacji są niestandardowe;

- kiedy zaproponowana weryfikacja jest standardowa, ale kontroler przekazujący chce przekazać weryfikację kontrolerowi akceptującemu.

8.5.2. Treść komunikatu

Treść komunikatu RRV jest taka sama jako opisana dla komunikatu REV (ppkt 7.3.2) i może fakultatywnie zawierać element następujących danych:

- powód wskazujący ręczny przekaz (możliwe wyłącznie w formacie ADEXP).

8.5.3. Zasady stosowania

8.5.3.1. Przepisy ogólne

Jeden lub więcej komunikatów RRV jest wysyłanych w miejsce komunikatu REV dla każdej weryfikacji, jeśli:

- system przekazujący określił warunki przekazu jako niestandardowe;

lub

- kontroler przekazujący wskazał, że zaproponowane warunki przekazu muszą być przesłane kontrolerowi akceptującemu celem akceptacji. Wykorzystanie RRV jest opcjonalne.

8.5.3.2. Inicjowanie przesyłu

Komunikat RRV jest przesyłany niezwłocznie po wykryciu zmiany w danych koordynacji lub kiedy został ręcznie inicjowany.

8.5.3.3. Przetwarzanie w jednostce odbiorczej

8.5.3.3.1. Jeśli odpowiadający plan lotu jest znaleziony w stanie koordynacji i nie stwierdzono żadnych rozbieżności, które wstrzymywałyby prawidłowe przetwarzanie komunikatu, wówczas:

- komunikat RRV jest potwierdzany;

- w pozostałych przypadkach komunikat nie jest potwierdzany.

8.5.3.3.2. Zaproponowane warunki przekazu są wyświetlane na stanowisku ATC odpowiedzialnym za koordynację lotu.

8.5.3.3.3. Zalecenie

Wskazanie powodu do skierowania (warunki niestandardowe i ręczne skierowanie) powinno być uwzględnione.

8.5.4. Potwierdzenie RRV

8.5.4.1. Potwierdzenie

Komunikat jest potwierdzany przez wytworzenie i przesył komunikatu SBY.

8.5.4.2. Przypadki braku potwierdzenia

Jeżeli nie otrzymano żadnego komunikatu SBY jako potwierdzenia komunikatu RRV, ostrzeżenie wyświetli się na stanowisku ATC odpowiedzialnym za koordyancję lotu.

8.5.5. Operacyjna odpowiedź dla RRV

Kontroler akceptujący może zaakceptować, złożyć kontrpropozycję lub odrzucić komunikat RRV.

8.5.5.1. Akceptacja

Kiedy kontroler akceptujący wybiera zaakceptowanie zaproponowanej zmiany do uzgodnionych warunków przekazu, wówczas komunikat ACP jest odsyłany.

8.5.5.2. Kontrpropozycja

Kiedy kontroler akceptujący wybiera złożenie kontrpropozycji dla warunków przekazu, wówczas komunikat CDN jest odsyłany.

8.5.5.3. Odrzucenie

Kiedy kontroler akceptujący wybiera odrzucenie zaproponowanej zmiany do uzgodnionych warunków przekazu wówczas:

- komunikat RJC jest odsyłany;

oraz

- nowy proces koordynacji jest inicjowany.

Zakłada się odrzucenie, jeśli w odpowiedzi na komunikat RRV nie otrzymano ani ACP ani CDN.

8.5.6. Przykłady

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. Komunikat oczekiwania (SBY)

8.6.1. Cel komunikatu SBY

Komunikat SBY potwierdza odbiór komunikatu proponującego warunki przekazu i wskazuje, że propozycja jest przedłożona kontrolerowi celem podjęcia decyzji.

8.6.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

8.6.3. Zasady stosowania

8.6.3.1. Przepisy ogólne

Komunikat SBY jest wytwarzany i przekazywany automatycznie niezwłocznie w odpowiedzi na:

- komunikaty RAP, RRV lub CDN;

- komunikaty ACT lub REV, które nie przeszły pomyślnie sprawdzenia w filtrze.

8.6.4. Potwierdzenie SBY

Komunikat SBY nie jest potwierdzany.

8.6.5. Przykłady

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. Komunikat akceptacji (ACP)

8.7.1. Cel komunikatu akceptacji (ACP)

Komunikat ACP spełnia następujące wymogi operacyjne podczas koordynacji ATC i faz przekazu:

- wskazuje, że kontroler w jednej jednostce dokonuje ręcznej akceptacji warunków przekazu zaproponowanych przez kontrolera w innej jednostce w jednym z następujących komunikatów:

- RAP,

- RRV,

- CDN,

- ACT i REV, jeśli jeden lub drugi jest niestandardowy;

- tam gdzie zostało to uzgodnione dwustronnie, zapewnia automatyczną akceptację komunikatów ACT lub REV, które przeszły przez filtr w jednostce akceptującej (w miejsce LAM);

- tam gdzie zostało to uzgodnione dwustronnie, wskazuje ręczną akceptację komunikatu HOP (w miejsce komunikatu ROF).

8.7.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu;

- dane fakultatywne — komunikat może również zawierać:

- częstotliwość;

- fakultatywne dane komunikatów ICAO — komunikat może również zawierać wszystkie następujące elementy:

- identyfikację statku powietrznego;

- lotnisko odlotu;

- lotnisko docelowe.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

8.7.3. Zasady stosowania

8.7.3.1. Przepisy ogólne

8.7.3.1.1. Odnośnik komunikatu ACP zawiera numer komunikatu tego komunikatu, w odpowiedzi na który jest przesyłany.

8.7.3.1.2. Pole częstotliwości, jeśli występuje, zawiera częstotliwość, na której lot ma się skontaktować z jednostką akceptującą, kiedy przekazanie ma miejsce.

8.7.3.1.3. Komunikat ACP jest przesyłany w następstwie ręcznej akceptacji przez kontrolera zaproponowanych warunków przekazu, przesyłanych przez ACT, RAP, REV, RRV lub CDN.

8.7.3.1.4. Komunikat ACP może być przesłany jako alternatywa dla komunikatu ROF w odpowiedzi na komunikat HOP.

8.7.3.1.5. Jeśli zostało to uzgodnione dwustronnie, komunikat ACP jest wytworzony i przesłany automatycznie przez system jako odpowiedź na ACT/REV, który został sprawdzony przez filtr.

8.7.3.1.6. Kiedy otrzymano ACP, uzgodnione warunki przekazu są wiążące dla obydwu jednostek.

8.7.3.2. Przetwarzanie w jednostce odbiorczej

8.7.3.2.1. System ATC otrzymując komunikat ACP dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

8.7.3.2.2. Jeśli ACP może być połączony z planem lotu, akceptacja jest wskazywana kontrolerowi.

8.7.3.2.3. Jeśli ACP nie może być połączony z planem lotu:

- ostrzeżenie ukazuje się na właściwym stanowisku; oraz

- LAM nie jest wysyłany.

8.7.4. Potwierdzenie ACP

8.7.4.1. Potwierdzenie

8.7.4.1.1. LAM nie jest odsyłany, kiedy ACP jest używana, jak automatyczna odpowiedź na komunikaty ACT lub REV, które zostały sprawdzone przez filtr.

8.7.4.1.2. Komunikat ACP wysłany jako wynik ręcznej akceptacji jest potwierdzana poprzez wytworzenie i przesłanie komunikatu LAM.

8.7.4.2. Przypadki braku potwierdzenia

Jeśłi nie otrzymano żadnego komunikatu LAM stanowiącego potwierdzenie komunikatu ACP wysłanego w wyniku ręcznej akceptacji, ostrzeżenie wyświetli się na stanowisku ATC odpowiedzialnym za koordynację lotu.

8.7.5. Przykłady

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. Komunikat koordynacji (CDN)

8.8.1. Cel komunikatu CDN

Komunikat CDN spełnia następujące wymogi operacyjne:

- przesyłanie kontrpropozycji od kontrolera akceptującego do kontrolera przekazującego jako odpowiedź na komunikaty ACT, RAP, REV lub RRV;

- zezwalanie kontrolerowi akceptującemu na przekazanie kontrolerowi przekazującemu zaproponowanych modyfikacji do uzgodnionych warunków przekazu.

8.8.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu (tylko jeśli występuje w odpowiedzi na inna komunikat);

- identyfikację statku powietrznego;

- lotnisko odlotu;

- lotnisko docelowe;

UWAGA

Komunikat może również zawierać jeden lub dwa następujące elementy:

- dane prognozowane (w przypadku komunikatu ICAO) lub poziom przekazu (w przypadku komunikatu ADEXP);

- żądanie trasy bezpośredniej;

- dane dwustronnie uzgodnione — następujące dane mogą być również uwzględnione, jeśli zostało to uzgodnione dwustronnie:

- częstotliwość.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

8.8.3. Zasady stosowania

8.8.3.1. Przepisy ogólne

8.8.3.1.1. Komunikaty CDN są przesyłane tylko przez kontrolera akceptującego.

8.8.3.1.2. Komunikat CDN jest wykorzystywany w celu przesłania kontrpropozycji od kontrolera akceptującego do kontrolera przekazującego.

UWAGA

Można wykorzystać dialog w odpowiedzi na propozycję przekazaną przez komunikaty ACT, RAP, REV lub RRV lub początek dialogu w celu zmiany uprzednio uzgodnionych warunków.

8.8.3.1.3. Odnośnik komunikatu jest wprowadzany tylko wówczas, gdy komunikat CDN jest odpowiedzią na inny komunikat.

8.8.3.1.4. Jeśli odnośnik komunikatu został wprowadzony zawiera on numer tego komunikatu, na który odpowiada CDN.

8.8.3.1.5. Usługa żądania trasy bezpośredniej (opisana szczegółowo w załączniku A):

- jest wykorzystywana jedynie, jeżeli zostało to uzgodnione dwustronnie; oraz

- jeśli jest to uzgodnione, określa granice operacyjne na własny użytek.

8.8.3.1.6. CDN nie jest wysyłany po czasie/odległości przed granicą określoną w umowie (LoA) między zainteresowanymi jednostkami.

8.8.3.1.7. Kiedy CDN jest przesyłany równocześnie z komunikatem dla tego samego lotu z jednostki przekazującej, np. w przypadku zmiany lub odwołania koordynacji, nie jest odsyłane ani potwierdzenie, ani odpowiedź operacyjna.

UWAGA

Oznacza to, że kiedy dwa komunikaty się krzyżują, pierwszeństwo ma ta z jednostki przekazującej, a CDN jest odrzucana przez obydwie jednostki. Obydwie jednostki mogą wyczuć sytuację, jeśli otrzymują komunikat z innej jednostki przed odbiorem potwierdzenia.

8.8.3.1.8. Gdy tylko akceptacja jest odebrana, dane komunikatu CDN stają się operacyjnie wiążące dla obydwu jednostek ATC. Zainteresowany personel jest powiadamiany o odbiorze ACP oraz koordynowanych warunkach przekazu.

8.8.3.2. Przetwarzanie w jednostce odbiorczej

8.8.3.2.1. Jeśli odpowiadający plan lotu jest odnaleziony i nie występują żadne rozbieżności w komunikacie, które wstrzymywałyby prawidłowe przetwarzanie:

- treść operacyjna jest przedstawiana stanowisku ATC odpowiedzialnemu za koordynację lotu;

oraz

- SBY jest odsyłany.

8.8.3.2.2. Jeśli CDN nie może być połączony albo występują rozbieżności, które wstrzymują prawidłowe przetwarzanie komunikatu, SBY nie jest odsyłany.

8.8.4. Potwierdzenie CDN

8.8.4.1. Potwierdzenie

Zgodnie z warunkami określonymi powyżej, komunikat CDN jest potwierdzany poprzez wytworzenie i przesył komunikatu SBY.

8.8.4.2. Przypadki braku potwierdzenia

Jeśli nie odebrano żadnego komunikatu SBY stanowiącego potwierdzenie komunikatu CDN, wyświetla się ostrzeżenie na stanowisku ATC odpowiedzialnym za koordynację lotu.

8.8.5. Odpowiedź operacyjna na CDN

Kontroler może przyjąć albo odrzucić warunki przekazu zaproponowane w komunikacie CDN.

8.8.5.1. Akceptacja

Kiedy kontroler przekazujący wybiera zaakceptowanie zaproponowanych warunków przekazu komunikat ACP jest odsyłany.

8.8.5.2 Zalecenie

Kiedy kontroler przekazujący wybiera odrzucenie zaproponowanych warunków przekazu wysyłany jest komunikat RJC (wyraźne odrzucenie).

UWAGA

Zaproponowana koordynacja jest domyślnie odrzucana, jeśli nie otrzymano akceptacji do wygaśnięcia czasu.

8.8.6. Przykłady

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. Komunikat odrzucenia koordynacji (RJC)

8.9.1. Cel komunikatu RJC

Komunikat RJC wskazuje odrzucenie przez kontrolera w jednej jednostce zaproponowanych warunków przekazu w jednym z następujących komunikatów:

- RAP,

- RRV,

- CDN,

- ACT oraz REV, jeśli jeden lub drugi jest określony jako niestandardowy.

Komunikat RJC może być jedynie użyty w odpowiedzi bezpośredniej na jeden z powyższych komunikatów.

8.9.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- odnośnik komunikatu.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

8.9.3. Zasady stosowania

8.9.3.1. Przepisy ogólne

8.9.3.1.1. RJC jest wysyłany w razie konieczności w odpowiedzi na komunikaty RAP, RRV, CDN lub komunikaty ACT lub REV uznane w jednostce akceptującej za niestandardowe.

8.9.3.1.2. Komunikat RJC kończy dialog systemowy, a jakakolwiek koordynacja uprzednio uzgodniona pozostaje w mocy.

8.9.3.1.3. Zalecenie

W następstwie odbioru komunikatu RJC powinna być inicjowana nowa sekwencja koordynacji odzwierciedlająca w danym wypadku koordynację telefoniczną.

8.9.3.2. Przetwarzanie w jednostce odbiorczej

8.9.3.2.1. Jeśli odpowiadający komunikat do której odnosi się RJC jest odnaleziony:

- odrzucenie jest wskazywane na stanowisku ATC odpowiedzialnym za koordynację odnośnego lotu; oraz

- LAM jest odsyłany w potwierdzeniu.

8.9.3.2.2. Jeśli nie odnaleziono komunikatu czekającego na odpowiedź albo w komunikacie stwierdzono niezgodność, która uniemożliwia przetwarzanie, nie jest odsyłane jest żadne potwierdzenie.

8.9.4. Potwierdzenie RJC

8.9.4.1. Potwierdzenie

Komunikat RJC jest potwierdzany poprzez wytworzenie i przesył komunikatu LAM.

8.9.4.2. Przypadki bez potwierdzenia

Jeśli nie otrzymano żadnego komunikatu LAM stanowiącego potwierdzenie komunikatu RJC, wyświetla się ostrzeżenie na stanowisku ATC odpowiedzialnym za koordynację lotów.

8.9.5. Przykłady

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. PROCEDURA DIALOGU — PRZEKAZ ŁĄCZNOŚCI

9.1. Przepisy ogólne

9.1.1. Wstęp

9.1.1.1. Niniejszy podpunkt norm opisuje udogodnienia i komunikaty, które wspierają kwestię zmiany nadajnika przekazu procedury kontroli. Są one wdrażane tam, gdzie zostało to uzgodnione dwustronnie.

9.1.1.2. Przekaz funkcji łączności nie jest wdrażany, jeśli jednostka nie używa funkcji koordynacji opisanych w pkt 6 (Procedura podstawowa — komunikaty obowiązkowe) lub tych opisanych w pkt 8 (Procedura dialogu — koordynacja).

9.1.1.3. Komunikaty opisane w niniejszym podpunkcie są dostępne tylko w formacie ADEXP i nie planuje się, aby były one dostępne w formacie ICAO.

9.1.2. Sekwencja komunikatu

9.1.2.1. Wymiana komunikatów przekazu łączności, innych niż komunikaty danych uzupełniających (SDM), nie jest dokonywana przed ukończeniem koordynacji, np. dialog ACT lub RAP został ukończony przez LAM lub ACP.

9.1.2.2. Potwierdzenie nie jest przesyłane, jeśli koordynacja nie została ukończona.

9.1.3. Przekaz łączności

9.1.3.1. Metoda oznaczenia aktualnej zmiany łączności lotów jest uzgadniana dwustronnie między dwiema danymi jednostkami.

9.1.3.2. Warunki:

- jednostka przekazująca wysyła komunikat zmiany częstotliwości (COF);

- jednostka akceptująca wysyła komunikat ręcznego przejęcia łączności (MAS).

9.1.3.3. Metoda jest uzgadniana między dwiema jednostkami dla każdego przepływu ruchu.

UWAGA

Różne metody mogą być wykorzystywane dla różnych przepływów, np. jedna jednostka może wytwarzać komunikat COF dla lotów opuszczających jej przestrzeń powietrzną i komunikat MAS dla lotów wchodzących w jej przestrzeń powietrzną. W takim przypadku nie jest konieczne, aby inna jednostka wprowadzała komunikaty w celu oznaczenia przekazu łączności.

9.2. Komunikat inicjowania przekazu (TIM)

9.2.1. Cel komunikatu TIM

Celem systemu TIM jest:

- oznaczenie zdarzenie inicjowania przekazu (TI) (koniec fazy koordynacji i początek fazy przekazu);

- równoczesne przesyłanie wykonawczych danych kontrolnych z jednostki przekazującej do jednostki akceptującej.

9.2.2. Treść komunikatu

Komunikat TIM zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikacja statku powietrznego;

- dostępne dane — komunikat również obejmuje każdą z następujących informacji, jeśli są one dostępne:

- dozwolony poziom lotu;

- przydzielony kurs lub bezpośrednie zezwolenie;

- przydzielona prędkość;

- przydzielone tempo wznoszenia/zniżania;

- dane fakultatywne — komunikat może również zawierać:

- usytuowanie.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.2.3. Zasady stosowania

9.2.3.1. Przepisy ogólne

9.2.3.1.1. Komunikat TIM jest wytworzony i przesyłana przez jednostkę przekazującą do jednostki akceptującej bez interwencji człowieka w uzgodnionym dwustronnie okresie czasu/odległości lotu od granicy.

9.2.3.1.2. Komunikat TIM jest również wysyłany automatycznie, kiedy komunikat żądania częstotliwości (ROF) jest odebrany przez jednostkę przekazującą.

9.2.3.1.3. TIM nie jest wysyłany przed koordynacją lotu.

9.2.3.1.4. Komunikat TIM jest zawierać najnowsze dane dostępne w systemie.

9.2.3.2. Parametry czasu dla przesyłu

9.2.3.2.1. Parametr wytwarzający TIM jest zmiennym parametrem systemu, który może zostać zmieniony na podstawie zapisów w umowie.

9.2.3.2.2. Zalecenie

Parametr systemu wytwarzania TIM powinien być określony oddzielnie dla każdego COP.

9.2.3.2.3. Partnerzy koordynacji zawierają parametry wytwarzające TIM w swoich umowach.

9.2.3.2.4. Parametr systemu uruchamiający komunikat TIM może mieć odniesienie do obliczonej prędkości statku powietrznego względem ziemi. Jednakże inicjowanie komunikatu TIM zaczyna się zawsze zanim statek powietrzny nie osiągnie, zgodnie z planem lotu, bliższej odległości do COP niż minimalna odległość jaka została określona dwustronnie.

9.2.3.2.5. Określony parametr systemu dla przesyłu TIM jest dopuszcza wystarczający czas dla słownej koordynacji przed przekazaniem.

9.2.3.3. Przetwarzanie w jednostce odbiorczej

9.2.3.3.1. Dane otrzymane w TIM są udostępniane kontrolerowi akceptującemu.

9.2.4. Potwierdzenie TIM

9.2.4.1. Potwierdzenie

Jeśli komunikat TIM:

- może być jednoznacznie połączony z planem lotu, jest potwierdzany przez wytworzenie i przesłanie komunikatu LAM;

- nie może być jednoznacznie połączony z planem lotu, wówczas potwierdzenie nie zostanie wysłane.

9.2.4.2. Brak potwierdzenia

Jeśli nie odebrano żadnego komunikatu LAM stanowiącego potwierdzenie komunikatu TIM, ostrzeżenie wyświetla się na właściwym stanowisku.

9.2.5. Przykład

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

9.3. Komunikat danych uzupełniających (SDM)

9.3.1. Cel komunikatu SDM

9.3.1.1. Przepisy ogólne

9.3.1.1.1. Zasadniczym celem SDM jest przesyłanie danych kontrolnych i zmian do nich z jednostki przekazującej do jednostki akceptującej, pod warunkiem że z dwustronnego uzgodnienia wynika,, iż zmiany nie wymagają potwierdzenia przez kontrolera akceptującego.

9.3.1.1.2. Komunikat SDM może być również wykorzystany przez jednostkę akceptującą w celu powiadomienia jednostki przekazującej radiotelefoniczną częstotliwość, do której lot został przesłany.

9.3.2. Treść komunikatu

9.3.2.1. Komunikaty z jednostki przekazującej

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikacja statku powietrznego;

- dodatkowe dane — komunikat zawiera jedną lub więcej następujących danych:

- przydzielony kurs lub bezpośrednie zezwolenie;

- przydzieloną prędkość;

- przydzielone tempo wznoszenia/zniżania;

- dozwolony plan lotu.

9.3.2.2. Komunikaty z jednostki akceptującej

SDM zawiera następujące dane:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikacja statku powietrznego;

- częstotliwość.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.3.3. Zasady stosowania

9.3.3.1. Komunikaty z jednostki przekazującej

9.3.3.1.1. Komunikaty SDM są przesyłane po zainicjowaniu fazy przesyłu (patrz TIM ppkt 9.2) w następstwie jakiejkolwek zmiany w podanych poniżej elementach:

- dozwolony plan lotu;

- przydzielona prędkość;

- przydzielone tempo wznoszenia/zniżania;

- przydzielony kurs; lub

- wydanie lub zmiana zezwolenia dla lotu, aby mógł lecieć bezpośrednio do określonego punktu.

UWAGA

Wykorzystanie komunikatu HOP jest wymagane, kiedy potwierdzenie kontrolera akceptującego jest niezbędne przed przekazem łączności.

9.3.3.1.2. Komunikat zawiera tylko pola, które zostały zmienione.

9.3.3.1.3. Komunikaty SDM zawierające dane opisane w ppkt 9.3.3.1.1 są przesyłane przed TI, jeśli tak zostało uzgodnione dwustronnie.

9.3.3.1.4. Przekaz takich komunikatów rozpoczyna się w czasie uzgodnionym dwustronnie relatywnym do TI, pod warunkiem że są dane, dla których występuje wartość dostępna w systemie.

9.3.3.2. Komunikaty z jednostki akceptującej

9.3.3.2.1. Komunikaty SDM mogą być przesłane w celu wskazania częstotliwości, na której lot ma się skontaktować z jednostką akceptującą.

UWAGA

Jednostki mogą po dwustronnym uzgodnieniu przesłać inne informacje. Przesył taki nie jest określony i dlatego nie jest częścią niniejszej normy.

9.3.3.2.2. Komunikaty SDM z jednostki akceptującej przesyła się podczas fazy koordynacji, jeśli zostało to uzgodnione dwustronnie.

9.3.3.3. Przetwarzanie w jednostce odbiorczej

9.3.3.3.1. System ATC otrzymując komunikat SDM dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

9.3.3.3.2. Jeśli odpowiadający komunikatowi plan lotu jest odnaleziony w stanie koordynowania:

- LAM nie jest odsyłany; i

- treść operacyjna komunikatu SDM jest dostępna właściwemu kontrolerowi.

9.3.3.3.3. Jeśli odpowiadający komunikatowi plan lotu nie może być odnaleziony lub stwierdzono rozbieżność, która uniemożliwia poprawne przetwarzanie komunikatu:

- LAM nie jest odsyłany; i

- ostrzeżenie pojawia się na właściwym stanowisku.

9.3.4. Potwierdzenie SDM

9.3.4.1. Potwierdzenie

Komunikat SDM jest potwierdzany przez wytworzenie i przesył komunikatu LAM.

9.3.4.2. Brak potwierdzenia

Jeśli nie otrzymano komunikatu LAM stanowiącego potwierdzenie dla komunikatu SDM, ostrzeżenie wyświetla się na właściwym stanowisku.

9.3.5. Przykład

-TYTUŁ SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290

9.4. Propozycja przekazania lotu (HOP)

9.4.1. Cel komunikatu HOP

Celem systemu HOP jest:

- aby kontroler przekazujący poinformował kontrolera akceptującego o określonym locie w celach jego przekazania;

- aby kontroler przekazujący zaproponował kontrolerowi akceptującemu przekazanie lotu, kiedy jest to konieczne;

- przekazanie zmian do danych kontroli wykonawczej, które wymagają zatwierdzenia przez kontrolera akceptującego, jak zostało uzgodnione dwustronnie.

Nie jest konieczne używanie HOP do wszystkich lotów, jest on wykorzystywany dowolnie przez kontrolerów przekazujących.

UWAGA

W odniesieniu do lit. c) powyżej SDM jest wykorzystywany w celu przesyłania zmian do danych kontroli wykonawczej, które nie wymagają potwierdzenia kontrolera akceptującego.

9.4.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikację statku powietrznego;

- dostępne dane — komunikat zawiera również jeden z następujących elementów, jeśli są one dostępne:

- dozwolony poziom lotu;

- przydzielony kurs/bezpośrednie zezwolenie;

- przydzieloną prędkość;

- przydzielone tempo wznoszenia/zniżania;

- dane fakultatywne — komunikat może również zawierać:

- usytuowanie.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.4.3. Zasady stosowania

9.4.3.1. Przepisy ogólne

9.4.3.1.1. Komunikat HOP jest wprowadzany ręcznie przez kontrolera przekazującego.

9.4.3.1.2. Komunikat zawiera dane opisane w ppkt 9.4.2 powyżej, które zostały zmienione w odniesieniu do uprzednio przesłanych.

9.4.3.1.3. Jeśli komunikat jest przesłany przed TI, faza przesyłu zostanie zainicjowana.

UWAGA

Komunikat inicjowania przesyłu (TIM) nie jest wymagany w odniesieniu do HOP.

9.4.3.1.4. Najkrótszy okres czasu przed COP lub najkrótsza odległość do COP lub granicy, w którym HOP może być przesłany, jest uzgadniana dwustronnie.

9.4.3.1.5. Zalecenie

Czas/odległość powinny być określone oddzielnie dla każdego COP.

9.4.3.2. Przetwarzanie w jednostce odbiorczej

9.4.3.2.1. System ATC odbierając komunikat dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

9.4.3.2.2. Dane lotu otrzymane w komunikacie wyświetlają się niezwłocznie kontrolerowi akceptującemu.

9.4.3.2.3. Jeśli kontroler akceptujący przyjmuje lot zgodnie z warunkami zaproponowanymi w HOP, ROF może być przesłany w odpowiedzi do jednostki przekazującej. W przypadku uzgodnienia dwustronnego ACP może być wysłany jako odpowiedź na HOP.

9.4.3.2.4. Jeśli kontroler akceptujący nie może przyjąć lotu, przekaz jest uzgadniany słownie.

UWAGA

Niniejsza norma nie wymaga wsparcia systemowego w monitorowaniu odsyłania ROF (lub ACP) z uwagi na pilność procedury przekazania. Zakłada się, że kontroler przekazujący jest świadomy braku odpowiedzi od kontrolera akceptującego i w razie konieczności podejmuje działania. Jednakże niniejsza norma nie zabrania przesyłania ostrzeżenia kontrolerowi przekazującemu, jeżeli ze względów operacyjnych jest to konieczne.

9.4.3.2.5. W momencie otrzymania ROF (lub ACP) dane komunikatu HOP stają się operacyjnie wiążące do dwóch jednostek ATC.

9.4.4. Potwierdzenie HOP

9.4.4.1. Potwierdzenie

Jeżeli możliwe jest połączenie komunikatu HOP z planem lotu, jest on potwierdzany automatycznie przez LAM.

9.4.4.2. Brak potwierdzenia

Jeżeli nie otrzymano żadnego komunikatu LAM stanowiącego potwierdzenie dla komunikatu HOP, ostrzeżenie wyświetla się na właściwym stanowisku.

9.4.5. Przykład

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ

9.5. Komunikat żądania zmiany częstotliwości (ROF)

9.5.1. Cel komunikatu ROF

ROF jest przesyłany przez jednostkę akceptującą do jednostki przekazującej z żądaniem, w razie konieczności, aby kontroler przekazujący poinstruował statek powietrzny o konieczności dostosowania do częstotliwości kontrolera akceptującego. Komunikat może być użyty:

- w odpowiedzi na HOP jako potwierdzenie akceptacji lotu zgodnie z zaproponowanymi warunkami;

- żądania wczesnego przekazania lotu.

9.5.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikację statku powietrznego;

- dane alternatywne — komunikat może również zawierać:

- częstotliwość.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.5.3. Zasady stosowania

9.5.3.1. Przepisy ogólne

9.5.3.1.1. Komunikat ROF jest ręcznie inicjowany przez kontrolera akceptującego.

9.5.3.1.2. Kontroler akceptujący może uruchomić ROF:

- kiedy kontroler akceptujący żąda wcześniejszego przejścia statku powietrznego na daną częstotliwość;

- jako odpowiedź na komunikat HOP.

9.5.3.2. Przetwarzanie w jednostce odbiorczej

9.5.3.2.1. System ATC odbierając komunikat ROF dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

9.5.3.2.2. Odbiór ROF jest niezwłocznie wskazywany kontrolerowi przekazującemu.

9.5.3.2.3. Jeżeli lot nie jest w fazie przekazu, wówczas faza przekazu jest inicjowana i przesyłany jest komunikat TIM.

9.5.4. Potwierdzenie ROF

9.5.4.1. Potwierdzenie

9.5.4.1.1. W przypadku gdy komunikat ROF może być jednoznacznie połączony z planem lotu, jest to potwierdzone poprzez wytworzenie i przesył komunikatu LAM.

9.5.4.1.2. W przypadku gdy komunikat ROF nie może być jednoznacznie połączony z planem lotu, nie wysyła się żadnego potwierdzenia.

9.5.4.2. Brak potwierdzenia

Jeżeli nie otrzymano żadnego komunikatu LAM stanowiącego potwierdzenie komunikatu ROF, ostrzeżenie wyświetla się na właściwym stanowisku ATC.

9.5.5. Przykład

-TYTUŁ ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.6. Komunikat zmiany częstotliwości (COF)

9.6.1. Cel komunikatu COF

9.6.1.1. Przepisy ogólne

9.6.1.1.1. Komunikat COF jest przesyłany przez jednostkę przekazującą do jednostki akceptującej w celu wskazania, że lot otrzymał wskazówki do skontaktowania się z kontrolerem akceptującym.

9.6.1.1.2. Komunikat może zawierać możliwość zwolnienia lotu przez kontrolera przekazującego z uzgodnionych warunków przekazu, jeżeli lot ten ustanowił łączność radiową z kontrolerem akceptującym.

9.6.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- dane obowiązkowe — komunikat zawiera:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikację statku powietrznego;

- dostępne dane — komunikat zawiera również każdą z następujących informacji, jeżeli są one dostępne:

- wskazanie zwolnienia;

- częstotliwość;

- dozwolony poziom lotu;

- przydzielony kurs/zezwolenie na trasę bezpośrednią;

- przydzieloną prędkość;

- przydzielone tempo wznoszenia/zniżania;

- dane fakultatywne — komunikat może również zawierać:

- usytuowanie.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.6.3. Zasady stosowania

9.6.3.1. Przepisy ogólne

9.6.3.1.1. Komunikat COF jest ręcznie wprowadzany przez kontrolera przekazującego.

9.6.3.1.2. Użycie komunikatu COF jest obowiązkowe, jeżeli na mocy dwustronnej umowy komunikat MAS nie jest użyty.

9.6.3.1.3. Jeżeli komunikat COF jest przesyłany przed TI, faza przekazu jest inicjowana.

UWAGA

Komunikat inicjowania przekazu (TIM) nie jest wymagany w uzupełnieniu COF.

9.6.3.2. Przetwarzanie w jednostce odbiorczej

9.6.3.2.1. System ATC otrzymując komunikat COF dokonuje próby jego połączenia z odpowiadającym jemu planem lotu.

9.6.3.2.2. Odbiór COF jest wskazywany bezzwłocznie kontrolerowi akceptującemu.

9.6.4. Potwierdzenie COF

9.6.4.1. Potwierdzenie

9.6.4.1.1. Jeżeli komunikat COF można jednoznacznie połączyć z planem lotu, jest to potwierdzane poprzez wytworzenie i przesył komunikatu LAM.

9.6.4.1.2. Jeżeli komunikatu COF nie można jednoznacznie połączyć z planem lotu, potwierdzenie nie zostanie przesyłane.

9.6.4.2. Przypadki braku potwierdzenia

Jełsi nie otrzymano żadnego komunikatu LAM stanowiącego powierdzenie komunikatu COF, ostrzeżenie wyświetla się na właściwym stanowisku ATC.

9.6.5. Przykłady

-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.7. Komunikat ręcznego przejęcia łączności (MAS)

9.7.1. Cel komunikatu MAS

MAS jest przesyłany przez jednostkę akceptującą do jednostki przekazującej wskazując, że dwukierunkowy kontakt radiowy został ustanowiony z lotem.

9.7.2. Treść komunikatu

Komunikat ACT zawiera następujące elementy danych:

- rodzaj komunikatu;

- numer komunikatu;

- identyfikację statku powietrznego.

UWAGA

Zasady wprowadzania danych, formatów i zawartości pól są określone w załączniku A.

9.7.3. Zasady stosowania

9.7.3.1. Przepisy ogólne

9.7.3.1.1. Komunikat MAS jest ręcznie wprowadzany przez kontrolera akceptującego.

9.7.3.1.2. Użycie komunikatu MAS jest obowiązkowe, jeżeli na mocy umowy dwustronnej komunikat COF nie jest używany.

9.7.3.2. Przetwarzanie w jednostce odbiorczej

9.7.3.2.1. System ATC otrzymując komunikat MAS, dokonuje próby jego połączenia z odpowiadającym mu planem lotu.

9.7.3.2.2. Fakt, że MAS został odebrany niezwłocznie, przedstawiany kontrolerowi.

9.7.4. Potwierdzenie MAS

9.7.4.1. Potwierdzenie

9.7.4.1.1. Jeżeli komunikat MAS może być jednoznacznie połączony z planem lotu, jest to potwierdzane poprzez wytworzenie i przesył komunikatu LAM.

9.7.4.1.2. Jeżeli komunikat MAS nie może być jednoznacznie połączony z planem lotu, nie jest przesyłane żadne potwierdzenie.

9.7.4.2. Przypadki braku potwierdzenia

Jeżeli nie otrzymano żadnego komunikatu LAM stanowiącego potwierdzenie komunikatu MAS, ostrzeżenie wyświetla się na właściwym stanowisku ATC.

9.7.5. Przykład

-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

[1] Obowiązkowe dla TX i REC, kiedy używane są w procedurze dialogu.

[2] Patrz ppkt 5.2.1.1 warunki czasów transakcji.

[3] Niewykorzystywany we wszystkich konfiguracjach przestrzeni powietrznej.

[4] M kiedy przesyłane z jednostki przesyłającej; C kiedy przesyłane z jednostki akceptującej.

[5] Procedury uzgodnione dwustronnie stanowią, że kiedy przekaz ma miejsce w odniesieniu do danego kierunku przepływu ruchu, jako minimum jednostka przesyłająca powinna przesłać komunikat COF albo jednostka akceptująca powinna przesłać komunikat MAS.

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

ZAŁĄCZNIK II

PRZEDSTAWIANIE WYMIANY DANYCH ATS (ADEXP) WERSJA 2.0

(Dokument odniesienia Eurocontrolu DPS.ET1.ST09-STD)

SPIS TREŚCI

UWAGA O PRAWACH AUTORSKICH … PRZEDMOWA … 1. ZAKRES …

2. ODNIESIENIA …

3. DEFINICJE, SYMBOLE I SKRÓTY …

3.1. Znaki umowne …

3.2. Definicje …

3.3. Konstrukcja …

3.4. Konwencje …

3.5. Symbole rodzaju operacji …

3.6. Skróty …

4. ZASADY ADEXP …

4.1. Format tekstowy do czytania …

4.2. Pola zidentyfikowane i możliwe do odzyskania …

4.3. Pola nierozpoznawalne …

5. ZASADY SKŁADNI ADEXP …

5.1. Elementy leksykalne …

5.2. Pola …

6. ZNORMALIZOWANY OPIS KOMUNIKATÓW ADEXP …

6.1. Wstęp …

6.2. Terminy posiłkowe …

6.3. Definicja pól podstawowych …

6.4. Definicja podpól …

6.5. Grupa komunikatów …

ZAŁĄCZNIK A (Normatywny) DEFINICJE POLA ADEXP … ZAŁĄCZNIK B (Normatywny) CENTRALNY INDEKS TYTUŁÓW KOMUNIKATÓW ADEXP … ZAŁĄCZNIK C (Normatywny) CENTRALNY INDEKS ZAREZERWOWANYCH TYTUŁÓW KOMUNIKATÓW … ZAŁĄCZNIK D (Normatywny) CENTRALNY INDEKS ZAREZERWOWANYCH PÓL … ZAŁĄCZNIK E (Informacyjny) WPROWADZANIE GRUP KOMUNIKATÓW … ZAŁĄCZNIK F (Informacyjny) PRZYKŁADY FORMATÓW KOMUNIKATÓW ADEXP … ZAŁĄCZNIK G (Informacyjny) PRZYSZŁY ROZWÓJ … UWAGA O PRAWACH AUTORSKICH

Niniejszy dokument został opracowany przez Agencję Eurocontrol.

Prawa autorskie należą do Agencji Eurocontrol.

Treść jakiejkowiek części niniejszego dokumentu jest udostępniona przedstawicielom Państw Członkowskich, ale na kopiowanie lub ujawnienie innym powinna być uprzednio wyrażona pisemna zgoda przez Agencję Eurocontrol.

PRZEDMOWA

1. Organ upoważniony

Niniejsza norma została wypracowana i jest utrzymywana przez dział wymagań dotyczących użytkownika Centralnej Jednostki Zarządzania Ruchem Lotniczym (CFMU) Europejskiej Organizacji ds. Bezpieczeństwa Nawigacji Lotniczej (Eurocontrol).

2. Dokument Program pracy EATCHIP

Niniejsza norma stanowi dokument Program pracy EATCHIP (EWPD), domeny systemów przetwarzania danych (DPS), zadanie wykonawcze 09.

3. Zatwierdzenie normy

3.1. Niniejsza norma jest przyjęta w zgodzie z procedurami określonymi w dyrektywie w sprawie przyjęcia standardów organizacji Eurocontrolu, ref. 000-2-93, wersja 1.0.

3.2. Przepisy niniejszej normy weszły w życie po przyjęciu wydania 1.0 przez Stałą Komisję Eurocontrolu w 1995 r., a termin stosowania z mocą od dnia 1 grudnia 1997 r.

4. Błędy techniczne i zmiany

Niniejsza norma jest poddawana przeglądom w celu dokonania koniecznych zmian lub poprawy technicznych błędów. Procedura dla utrzymania niniejszej normy jest przedłożona w załączniku H dyrektyw dla jednolitego redagowania i prezentacji dokumentów zawierających normy Eurocontrolu.

Zmiany lub uzupełnienia wpływające na podstawowe zasady lub gramatykę formatu ADEXP są dokonywane tylko po formalnej procedurze przeglądu (w przypadku przetargów) zgodnie z dyrektywami dla jednolitego redagowania i prezentacji dokumentów zawierających normy Eurocontrolu.

Zmiany lub uzupełnienia do niniejszej normy są dokonywane w formie pisemnej do: CFMU Dział Wymogów dla Użytkowników (ADEXP), Agencja Eurocontrol.

5. Konwencje edytorskie

5.1. Format niniejszej normy jest zgodny z dyrektywami dla jednolitego redagowania i prezentacji dokumentów zawierających normy Eurocontrolu, jednakże znajdują się w nim pewne odstępstwa od tych dyrektyw. Drobne odstępstwa od dyrektyw związane z formatowaniem pozwalają uniknąć pomieszania ze znakami umownymi prezentacji wymiany danych organów służb ruchu lotniczego (ADEXP).

5.2. Następujące znaki umowne zostały użyte w celu wskazania statusu każdego elementu:

- elementy normatywne używają czasownika operacyjnego "musi" i zostały wydrukowane zwykłą czcionką;

- elementy zalecane używają czasownika operacyjnego "powinien" i zostały wydrukowane czcionką pochyłą, ich status został określony za pomocą prefiksu zalecenie.

6. Odniesienie do innych dokumentów zawierających normy

Niniejsza norma odnosi się do:

Dokumentu norm Eurocontrolu dla bezpośredniej wzajemnej wymiany danych (OLDI)

7. Status załączników do niniejszej normy

Istnieje 6 załączników do niniejszej dyrektywy, których status jest określony w następujący sposób:

Załącznik A | Normatywny |

Załącznik B | Normatywny |

Załącznik C | Normatywny |

Załącznik D | Normatywny |

Załącznik E | Informacyjny |

Załącznik F | Informacyjny |

Załącznik G | Informacyjny |

8. Wykorzystywany język

Język angielski został użyty dla tekstu oryginalnego niniejszej normy.

1. ZAKRES

1.1. ADEXP jest formatem, nie protokołem. Nie nakłada ograniczeń dotyczących środków transmisji lub protokołów do wykorzystania, oprócz zestawu znaków.

1.2. ADEXP dostarcza formatu do wykorzystania głównie w bezpośredniej wymianie komunikatów od komputera do komputera.

1.3. Niniejszy dokument określa zasady i reguły składni formatu ADEXP. Przedstawia tę definicję za pośrednictwem obszernej definicji pól ADEXP.

1.4. Format ADEXP został określony do użycia w ramach następujących obszarów wymiany komunikatów (informacja o dokumencie odniesienia patrz pkt 2, str. 3):

- Planowanie lotu: wymiana danych dotyczących planu lotu oraz powiązanych komunikatów między Zintegrowanym wstępnym systemem przetwarzania planów lotu (IFPS), służbami kontroli ruchu lotniczego (ATS) i operatorami statku powietrznego (AO) (dokument odniesienia 3).

- Zarządzanie przepływem ruchu lotniczego (ATFM): wymiana komunikatów między systemem taktycznym (TACT) CFMU, AO oraz ATS (dokument odniesienia 5).

- Koordynacja kontroli ruchu lotniczego: wymiana taktycznych komunikatów koordynacyjnych między jednostkami kontroli ruchu lotniczego (ATCU) (dokument odniesienia 6).

- Zarządzanie przestrzenią powietrzną: wymiana danych między krajowymi jednostkami ATS, CFMU oraz AO, dotyczących dostępności przestrzeni powietrznej (dokument odniesienia 7).

- Koordynacja cywilno-wojskowa: komunikaty dotyczące cywilno-wojskowych danych dotyczących lotu i komunikaty o przekroczeniu przestrzeni powietrznej (dokument odniesienia 7).

1.5. Szczegółowa specyfikacja użycia i zawartości komunikatów w ramach każdej z powyższych grup znajduje się w omawianych dokumentach.

2. ODNIESIENIA

2.1. Następujące dokumenty i normy zawierają przepisy, które przez odniesienia w niniejszym tekście, tworzą przepisy niniejszego dokumentu normy Eurocontrolu.

W czasie publikacji niniejszego dokumentu normy Eurocontrolu, wydania wskazane dla dokumentów referencyjnych i norm były ważne.

Jakiekolwiek poprawki w odpowiednich dokumentach Europejskiej Konferencji Lotnictwa Cywilnego (ICAO) są natychmiast uwzględniane w celu zaktualizowania niniejszego dokumentu normy Eurocontrolu.

Poprawki pozostałych referencyjnych dokumentów tworzą część przepisów niniejszego dokumentu normy Eurocontrolu dopiero po dokonaniu ich przeglądu pod względem formalnym oraz włączeniu do niniejszego dokumentu normy Eurocontrolu.

W przypadku rozbieżności między wymaganiami niniejszego dokumentu normy Eurocontrolu a treścią pozostałych dokumentów referencyjnych niniejszy dokument normy Eurocontrolu ma pierwszeństwo.

2.2. W czasie publikacji dokumenty wymienione poniżej stanowią odniesie dla niniejszej normy, jednakże sugeruje się, aby użytkownicy sprawdzili tabele użycia i tworzenia pól komunikatów w najnowszych wydaniach tych dokumentów.

1. ICAO, Konwencja chicagowska, załącznik 10, tom I, wydanie z listopada 1985 r.;

2. ICAO, Konwencja chicagowska, załącznik 10, tom II, wydanie z lipca 1995 r.;

3. słownik komunikatów IFPS i RPL, wersja 1.0, z marca 1998 r.;

4. "Zasady służb ruchu lotniczego", dokument PANS-RAC 4444, wydanie z listopada 1985 r. (łącznie ze zmianą nr 6 z listopada 1995 r.);

5. przewodnik do wymiany komunikatów ATFM dokument odniesienia Eurocontrolu TACT/USD/MSGGUID, wersja 6.0, obowiązujący od marca 1998 r.;

6. norma Eurocontrolu dotycząca bezpośredniej wzajemnej wymiany danych, wersja 2.0, z października 1996 r.;

7. specyfikacje funkcjonalne dla wsparcia systemowego w dystrybucji danych o przestrzeni powietrznej i koordynacja cywilno-wojskowa, wersja 1.0 z maja 1996 r.

3. DEFINICJE, SYMBOLE I SKRÓTY

3.1. Znaki umowne

Znaki umowne użyte do zdefiniowania składni określa się jako Notację Backusa-Naura (BNF). BNF określa zbiór zasad, które określają klasę ciągów znaków. W tym przypadku klasa ciągów znaków jest zbiorem komunikatów, które mogą być określone jako ważny pod względem składni komunikat ADEXP.

3.2. Definicje

Do celów niniejszego dokumentu normy Eurocontrolu stosuje się następujące definicje:

Znacznik : Znak lub zestaw znaków, które mogą być "wydobyte" przez analizator leksykalny dzięki obecności znaków rozdzielających.

Symbol : Dowolny "termin", który pojawi się w zasadach BNF, ale który nie jest znakiem.

Symbol terminalny : Symbol, który przedstawia się jako sekwencję znaków.

Symbol nieterminalny : Symbol, który przedstawia się jako jeden lub więcej symboli terminalnych.

UWAGA

Symbol nieterminalny można także przedstawiać jako mieszaninę symboli terminalnych i nieterminalnych.

3.3. Konstrukcja

3.3.1. BNF składa się ze zbioru zasad lub konstrukcji o następującej formie:

symbol ::= expression

UWAGI

1) Znaki umowne "::=" należy czytać jako "może być zastąpione".

2) "Symbol" klasyfikuje się jako symbol nieterminalny.

3) Część opisana jako "expression" zawiera symbole terminalne i nieterminalne.

3.3.2. Symbole terminalne posiadają bezpośrednie odwzorowanie jako sekwencja znaków, które mogą być zidentyfikowane jako znacznik za pomocą analizatora leksykalnego, z wykorzystaniem obecności znaków rozdzielających.

3.4. Konwencje

Do celów niniejszego dokumentu normy Eurocontrolu stosuje się następujące konwencje:

- Symbole

terminalne

pisane są dużymi literami.

UWAGA

Zgodnie z konwencją, symbol terminalny NIL oznacza "symbol nieterminalny".

Wykorzystywany jest przy wyborze, tak jak w następującym przykładzie:

a ::= b (c | NIL), gdzie a może być zastąpione przez (b, po którym następuje c) lub tylko przez b.

- Symbole nieterminalne (np. lewa strona produkcji gramatycznej) pisane są małymi literami.

- Znaki oraz literały w ciągu znaków występujące wewnątrz formuł są odpowiednio ujęte w cudzysłów (') lub podwójny cudzysłów (").

Przykłady

1) HYPHEN::= '-'

2) title::= '-' "TITLE" titleid

W przypadku niektórych aplikacji modelowania danych wymagane może być dokonywanie rozróżnienia między symbolami terminalnymi i nieterminalnymi przy użyciu innych środków niż duże i małe litery.

Jeżeli wymagane jest wyraźne rozróżnienie między symbolami terminalnymi i nieterminalnymi, inne od stosowania dużych i małych liter, sugeruje się dodanie następujących przyrostków: "_at" dla terminu posiłkowego, "_pf" dla pola oraz "_sf" dla podpola.

3.5. Symbole rodzaju operacji

Do celów niniejszego dokumentu normy Eurocontrolu stosuje się następujące symbole rodzaju operacji:

Opcja: gdy niektóre symbole mogą w sposób dozwolony pojawić się lub nie w jakimś punkcie gramatyki. Symbole opcjonalne ujęte są w nawiasy kwadratowe "["oraz"]".

Domknięcie: gdy grupa symboli może wystąpić zero lub więcej razy. Symbole są ujęte w nawiasy klamrowe "{"and"}". Jeżeli liczba określona jest przed "{" podaje wówczas minimalną ilość razy, kiedy może pojawić się grupa symboli. Jeśli liczba jest określona po "}", podaje maksymalną liczbę oznaczającą ilość razy, kiedy może pojawić się grupa symboli.

Wybór: gdy szereg alternatywnych symboli może pojawić się w jakimś punkcie gramatyki. Wybór przedstawia się jako "|".

Konkatenacja: reprezentacja symboli, które następują po sobie sekwencyjnie, nawet jeśli między nimi wystąpi jeden lub więcej znaków rozdzielających. Nie ma to jawnej reprezentacji. Występuje w dwóch rodzajach:

- Ścisła konkatenacja

: na poziomie leksykalnym, zasady mogą dotyczyć konkatenacji terminali, wskazując, że następują dokładnie jeden po drugim (bez znaku rozdzielającego pośrodku), w tym przypadku należy użyć symbolu

"!"

.

Przykład

datetime:: = date ! timehhmm

np. "9912251200", co oznacza 25 grudnia 1999 r. o godz. 12.00.

- Swobodna konkatenacja

: dozwolona obecność znaków rozdzielających między terminalami. Reprezentacja swobodnej konkatenacji w ramach reguł może być niejawna lub jawna.

Przykłady

1) Niejawna:

dct::= '-' "DCT" point point

2) Jawne

dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

np. | "-DCT NTM RMS". |

UWAGI

1) Konkatenacja zawsze ma pierwszeństwo przed wyborem. Nawiasy zwykłe "("oraz")" są używane do zmiany porządku oceny wyrażenia.

Przykład

a::= B C | D | jest równoważny z: | a::= (B C) | D |

| oraz NIE jest z: | a::= B (C | D) |

2) We wszystkich regułach dozwolona obecność znaków rozdzielających między symbolami będzie działać w sposób niejawny, w celu zachowania czytelności.

Zalecenie

Jeżeli istnieje ryzyko pomyłki wynikającej z pierwszeństwa między wyżej wymienionymi symbolami rodzaju operacji, zalecane jest użycie nawiasu w celu wyjaśnienia pożądanej kolejności oceny.

3.6. Skróty

Do celów niniejszego dokumentu normy Eurocontrolu stosuje się następujące skróty:

ACH | Komunikat ATC o zmianie planu lotu |

ADEG | Grupa wymiany informacji ATS |

ADEXP | Prezentacja wymiany danych ATS |

AFIL | Plan lotu złożony z powietrza |

AFP | Propozycja planu lotu ATC |

AFTN | Lotnicza stała sieć telekomunikacyjna |

ANM | Komunikat zgłaszający ATFM |

AO | Operator/operatorzy statku powietrznego |

APL | Plan lotu ATC |

ATC | Kontrola ruchu lotniczego |

ATCU | Jednostka(-i) kontroli ruchu lotniczego |

ATFM | Zarządzanie przepływem ruchu lotniczego |

ATS | Służby kontroli ruchu lotniczego |

BNF | Notacja Backusa-Naura |

CASA | Wspomagane komputerowo przydzielanie slotów |

CIDIN | Wspólna sieć wzajemnej wymiany danych ICAO |

CFL. | Dozwolony poziom lotu |

CFMU | Centralna jednostka zarządzania ruchem lotniczym |

CMTP | Wspólny plan średnioterminowy |

CNL | Komunikat anulowania |

CTOT | Obliczony czas startu |

DPS | Domena systemów przetwarzania danych |

ECAC | Europejska Konferencja Lotnictwa Cywilnego |

EFL | Przewidywany poziom lotu |

EOBT | Przewidywany czas odkołowania |

ETO | Przewidywany czas nad |

Eurocontrol | Europejska Organizacja ds. Bezpieczeństwa Nawigacji Lotniczej |

EWPD | Dokument Program pracy EATCHIP |

FIR | Rejon informacji o lotach |

FIW | Stacja robocza wprowadzania planu lotu |

FMP | Pozycja zarządzania ruchem lotniczym |

FNM | Komunikat zgłaszający lotu |

FPL | Komunikat planu lotu (ICAO format) |

GAT | Ogólny ruch lotniczy |

IA | Alfabet międzynarodowy |

IAFP | Indywidualna propozycja planu lotu ATC |

ICAO | Międzynarodowa Organizacja Lotnictwa Cywilnego |

IFPD | Dane indywidualnego planu lotu |

IFPS | Zintegrowany wstępny system przetwarzania planów lotu |

IFPU | Jednostka IFPS |

IFR | Przepisy dotyczące lotów przy użyciu przyrządów |

ISO | Międzynarodowa Organizacja Normalizacyjna |

ITA | Międzynarodowy alfabet telegraficzny |

LAM | Komunikat potwierdzenia logicznego |

LRM | Komunikat logicznego odrzucenia |

MAC | Komunikat odwołania koordynacji |

MFS | Komunikat z Shanwick |

OAT | Operacyjny ruch lotniczy |

OLDI | Bezpośrednia wzajemna wymiana danych |

RFL | Zgłoszony poziom lotu |

RFP | Zastępczy plan lotu |

RFPD | Dane powtarzalnego planu lotu |

RPL | Powtarzalny plan lotu |

RVR | Widzialność na pasie startowym |

SFL | Uzupełniający poziom lotu |

SRD | Dokument z wymogami oprogramowania |

SSR | Radar wtórny dozorowania |

TACT | System taktyczny CFMU |

TOS | Schemat orientacji ruchu |

UIR | Rejon informacji wyższej |

VFR | Przepisy lotu z widocznością ziemi |

4. ZASADY ADEXP

4.1. Format tekstowy do czytania

4.1.1. Format ADEXP jest formatem tekstowym, opartym na znakach.

4.1.2. Komunikaty ADEXP są do odczytania przez operatora człowieka, co pozwala na lepsze zajęcie strojeniem lub sprawami operacyjnymi.

4.1.3. Format tekstowy jest także bardziej otwarty i zrozumiały.

4.2. Pola zidentyfikowane i możliwe do odzyskania

4.2.1. Komunikat w formacie ADEXP składa się z pól.

4.2.2. Pola są rozgraniczone przez specjalny znak początku pola, znak łącznika (

"-"

) i określane przez specjalne słowa kluczowe.

UWAGA

Należy zwrócić uwagę, że pewne pola (te zdefiniowane syntaktycznie jako zawierające element leksykalny "CHARACTER") mogą w dozwolony sposób zawierać znak "-" jako część zawartości pola.

4.2.3. Podejście to poprawia rozszerzalność i elastyczność formatu. (Jeśli nie ma pola lub pole jest nieprawidłowe, można je pominąć i nadal można będzie zinterpretować pozostałą część komunikatu. (Patrz ppkt 4.3).

4.2.4. Inny skutek to fakt, że kolejność pól w komunikacie nie powinna być istotna dla ustalenia, czy jest dozwolony, z wyjątkiem pierwszego pola (obowiązkowe pole tytułu), które określa dozwolone pola.

4.2.5. Pola mogą być bazowe lub złożone.

4.2.6. Części składowe pól złożonych określanych jest jako podpola i definiowanych poprzez obecność słów kluczowych, rozgraniczonych znakiem początku pola.

4.2.7. Pola bazowe to pola, które nie zawierają podpól.

4.2.8. Pola bazowe lub złożone tworzące pierwszy poziom definicji komunikatu określa się jako pola podstawowe.

4.2.9. Wszystkie części składowe na niższym poziomie z definicji stanowią podpola, które z kolei mogą być bazowe lub złożone.

4.2.10. Pola złożone dzielą się na dwa rodzaje, pola strukturalne i pola wykazu.

4.2.11. Pola strukturalne posiadają wcześniej zdefiniowaną zawartość, złożoną wyłącznie z podpól. Kolejność podpól w polu strukturalnym NIE jest istotna.

4.2.12. Pola wykazu wprowadzane są przez słowo kluczowe BEGIN i kończą się słowem kluczowym END. Może pojawić się między nimi powtarzające się występowanie tego samego podpola lub kombinacja podpól. Kolejność występowania wewnątrz pola wykazu ma znaczenie semantyczne.

4.2.13. Poniżej termin "pole" będzie używany ogólnie dla oznaczenia pola podstawowego i/lub podpola, z wyjątkiem przypadków, gdy wyraźnie zaznaczono inaczej.

4.2.14. Pola w komunikacie mogą być opcjonalne lub obowiązkowe, co określa ich składnia.

4.3. Pola nierozpoznawalne

4.3.1. Jeśli w komunikacie pojawi się nieznane pole, należy je zignorować.

4.3.2. Innymi słowy, jeżeli system, który analizuje komunikat nie rozpoznaje słowa kluczowego, cały tekst aż do następnego znanego pola, które nie znajduje się w ramach pola wykazu, zostanie zignorowany.

4.3.3. Zależnie od tytułu komunikatu, zignorowane pole może spowodować lub nie odrzucenie komunikatu podlegającego rozbiorowi.

UWAGA

Należy zwrócić uwagę, że choć ADEXP zaprojektowano w celu zapewnienia elastyczności tego rodzaju, zadaniem osób odpowiedzialnych za określenie wymogów dotyczących interfejsu jest wskazanie dla każdego komunikatu sposobu, w jaki system powinien reagować na pole nierozpoznawalne.

4.3.4. Jeżeli nieznane pole jest polem wykazu (co poznaje się po słowie kluczowym -BEGIN), wówczas cała jego zawartość (aż do odpowiedniego słowa kluczowego -END) jest ignorowana.

4.3.5. W celu uniknięcia niejednoznaczności w trakcie odzyskiwania, które następuje po opuszczeniu pola nierozpoznawalnego, wymaga się, by słowo kluczowe wprowadzało pole lub podpole.

4.3.6. Pozwala to na zdefiniowanie dwóch rodzajów słów kluczowych:

- podstawowe słowa kluczowe;

- podsłowa kluczowe.

4.3.7. Po zdefiniowaniu słowa kluczowego jako należącego do określonego rodzaju, nie można go dalej używać w innej grupie komunikatów jako innegi rodzaju, z jednym wyjątkiem, gdy jest to możliwe wewnątrz pola wykazu. Możliwe jest wewnętrzne wystąpienie podstawowego słowa kluczowego w dowolnym miejscu pola wykazu bez powodowania niejednoznaczności, ponieważ obecność słowa kluczowego BEGIN wskazuje na fakt, że możemy rozważyć wewnętrzne wystąpienie jako podpole.

Przykłady (użycia rodzajów słów kluczowych)

1) Pole podstawowe

-RFL F330

2) Podpole: zawsze wewnątrz "pola złożonego"

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

gdzie -GEO jest podstawowym polem złożonym i -GEOID, -LATTD oraz LONGTD są podpolami.

3) Pole wykazu

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

…

-END RTEPTS

gdzie "-BEGIN" jest wskaźnikiem pola wykazu i "RTEPTS" jest polem.

UWAGA

"RFL" definiuje się jako pole. Włączenie do pola wykazu to jedyny przypadek, gdy pole może być użyte jako podpole. (Patrz przykład 3 powyżej).

5. ZASADY SKŁADNI ADEXP

5.1. Elementy leksykalne

5.1.1. Zestaw znaków

5.1.1.1. Zestaw znaków do wykorzystania w celu wymiany komunikatów w formacie ADEXP stanowi alfabet międzynarodowy numer 5 (IA-5), zgodnie z definicją w odniesieniu 1.

5.1.1.2. Format ADEXP został zaprojektowany jako format wymiany od komputera do komputera, który może być transmitowany przez różne sieci komputerowe lub przez wyspecjalizowane połączenia komputer-komputer. Ponadto istnieje wymóg, by być w stanie wymieniać niektóre komunikaty ADEXP, zazwyczaj związane z planowaniem lotu oraz ATFM, przez Lotniczą Stałą Sieć Telekomunikacyjną (AFTN).

5.1.1.3. Komunikaty, których transmisja przez AFTN może być wymagana, powinny ograniczyć swój zestaw znaków do tych znaków, w przypadku których występuje bezpośrednia korelacja między międzynarodowym alfabetem telegraficznym numer 2 (ITA-2) oraz IA-5, jak zdefiniowano w odniesieniu 1.

UWAGA

Poza zdefiniowanymi poniżej znakami graficznymi i formatyzatorami, zestaw znaków ITA-2 definiuje "sygnały" (na przykład takie jak taśma perforowana). Nie stanowią one części dozwolonego zestawu znaków dla komunikatów ADEXP.

5.1.1.4. Znaki dopuszczone do użycia w komunikatach ADEXP, które mogą być transmitowane przez AFTN, są znakami graficznymi i formatyzatorami, jak zdefiniowano poniżej:

Znaki graficzne

a) duże litery (A-Z)

b) cyfry (0-9)

c) następujące specjalne znaki graficzne:

1) znak spacji ""

2) otwarcie nawiasu "("

3) zamknięcie nawiasu ")"

4) łącznik "-"

5) znak zapytania "?"

6) dwukropek ":"

7) kropka "."

8) przecinek ","

9) apostrof "'"

10) znak równości "="

11) znak plus "+"

12) ukośnik "/"

Formatyzatory

a) Powrót karetki

b) Przesuw o wiersz

5.1.2. Podstawowe elementy leksykalne

Następujące podstawowe elementy leksykalne są zdefiniowane do użycia w niniejszej specyfikacji:

- ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'

- DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

- ALPHANUM ::= ALPHA | DIGIT

- SPACE ::= ' '

- HYPHEN ::= '-'

- FEF ::= Carriage_return | Line_Feed

- SEP ::= 1{ SPACE | FEF }

- SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'

- CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN

- LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF

- START-OF-FIELD ::= HYPHEN

UWAGA

LIM_CHAR reprezentuje dowolny dozwolony znak oprócz łącznika (HYPHEN), który jest zarezerwowany do wskazywania początku pola. Przeciwnie, znak (CHARACTER) reprezentuje dowolną dozwoloną część zestawu znaków.

5.1.3. Wiersze, znaki rozdzielające i ograniczniki

5.1.3.1. Podział tekstu komunikatu na wiersze nie powinien mieć wpływów syntaktycznych.

5.1.3.2. Separator może być znakiem spacji lub formatyzatorem.

5.1.3.3. Pola powinny być nakreślone wyłącznie poprzez obecność znaku początku pola, po którym nastąpi słowo kluczowe.

5.1.3.4. Stąd cały komunikat może, w dozwolony sposób znajdować się w jednym wierszu.

5.1.4. Oznaczone wartości

5.1.4.1. Może być wymagane wskazanie wartości liczbowej jako ujemnej.

5.1.4.2. Pola, od których wymaga się wskazania wartości ujemnej powinny, w ramach swojej definicji składni, w jasny sposób wskazać wartość jako "oznaczoną wartość", tzn. taką, która jest pozytywna lub negatywna.

5.1.4.3. "Oznaczona wartość" zawsze powinna być poprzedzona literą "N", oznaczającą wartości ujemne lub "P", oznaczającą wartości dodatnie. Wartość zero może być poprzedzona przez "N" lub "P".

5.1.4.4. Składnia pola, która pozwala na "oznaczoną wartość" powinna być następująca:

'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}

Przykład:

Pole nazwane "NUMBER", które może zawierać wartość ujemną, od jednej do ośmiu cyfr, byłoby zdefiniowane jako:

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

Dlatego:

-NUMBER P5 - wartość "number" wynosi +5

-NUMBER N5 - wartość "number" wynosi −5

-NUMBER 5 - błędna składnia, obecne musi być

"P"

lub

"N"

5.1.5. Słowa kluczowe

5.1.5.1. Słowo kluczowe to dowolna sekwencja dużych liter lub cyfr. Wprowadza pole tylko wtedy, gdy poprzedzone jest przez znak początku pola ("-").

keyword::= 1{ ALPHANUM }

5.1.5.2. Słowa kluczowe powinny być zgodne z następującą składnią:

'-'!{SEP}!"KEYWORD"!1{SEP}! <subfield/s or contained value>

tzn. słowo kluczowe powinno być oddzielone od swojego "znaku początku pola" przez zero lub więcej znaków rozdzielających. Bezpośrednio po nim musi nastąpić jeden lub więcej znaków rozdzielających, a następnie odpowiednie podpole(-a) lub wartość zawarta (contained value).

UWAGA

Istotne jest zwrócenie uwagi na fakt, że słowo kluczowe i poprzedzający je znak początku pola mogą być rozdzielone przez dowolną liczbę znaków rozdzielających, a także nierozdzielone.

Przykłady (Wszystkie następujące sekwencje wprowadzają pole w sposób ważny)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Zalecenie

Zalecaną praktyką jest unikanie znaku rozdzielającego między znakiem początku pola "-" i następującym po nim słowem kluczowym.

UWAGA

1) W powyższych przykładach pierwsze wystąpienie stanowi zalecany wybór.

2) Ważne jest także zwrócenie uwagi, że po słowie kluczowym musi bezpośrednio wystąpić co najmniej jeden znak rozdzielający.

5.1.5.4. W ramach dokumentu konkatenacja elementów rozdzielonych co najmniej przez jeden znak rozdzielający jest niejawnie przedstawiona przez znaki umowne "swobodnej konkatenacji" (patrz ppkt 3.5).

UWAGA

Zgodnie z wyjaśnieniami w dalszej części słowa kluczowe także wprowadzają pola wykazu, gdy poprzedzone są słowem kluczowym BEGIN.

5.1.5.5. Słowa kluczowe powinny być jak najkrótsze przy jednoczesnym zachowaniu znaczenia semantycznego.

5.1.5.6. Uprzednio zdefiniowane słowa kluczowe formatu ADEXP, które wymienia się poniżej, nie powinny być ponownie definiowane lub używane w innej roli, w ramach specyficznego użycia w formacie:

TITLE: | identyfikuje kategorię komunikatów i definiuje odpowiedni zestaw dozwolonych pól podstawowych; |

BEGIN: | identyfikuje początek pola wykazu; |

END: | identyfikuje koniec pola wykazu; |

COMMENT: | identyfikuje pole COMMENT. |

5.1.5.7. W celu uniknięcia niejednoznaczności (dublowania użycia tego samego słowa kluczowego z różnymi znaczeniami) lub redundancji (różne słowa kluczowe o takim samym znaczeniu), centralna tabela definicji pól podstawowych (tzn. podstawowe słowa kluczowe) przedstawiona jest w niniejszej normie w załączniku A (A3), a centralna tabela definicji podpól (tzn. podsłowa kluczowe) jest także przedstawiona w załączniku A (A4).

5.2. Pola

5.2.1. Składnia pola

field::= basic_field | structured_field | list_field

basic_field::= '-' keyword contained_values

contained_values::= {CHARACTER}

list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword

structured_field::= '-' keyword field_1 field_2 …field_n

UWAGA

Jak będzie można zauważyć, w przypadku pól wykazu słowo kluczowe nie jest poprzedzone bezpośrednio przez "-", ale przez konstrukcję "-""BEGIN".

5.2.2. Tworzenie komunikatu z wykorzystaniem pól

5.2.2.1. Pierwszym polem w komunikacie ADEXP zawsze będzie pole TITLE (tzn. pole wprowadzane przez słowo kluczowe TITLE).

5.2.2.2. Pozostała zawartość komunikatu, jeśli chodzi o jego pola podstawowe, powinna być zdefiniowana przez TITLE.

5.2.2.3. Składnia komunikatów odpowiadających danemu TITLE powinna być określona przez pola które zawiera (zdefiniowane przez swoje słowa kluczowe):

- nazwa i dozwolona zawartość jego pól podstawowych;

- nazwa i dozwolona zawartość jego podpól.

5.2.3. Pola bazowe

5.2.3.1. Składnia pola bazowego jest następująca:

basic_field::= '-' keyword contained_values

5.2.3.2. "Contained_values"

określają tekst, który dostarcza wartość pola i może nie wskazać żadnego podpola.

Przykładowa zasada

arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")

UWAGA

1) Zasadą wyraźnie równoważną jest:

arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) Oto przykład części komunikatu :: "-ARCTYP ZZZZ".

5.2.3.3. Zalecenie

Tam, gdzie są ponad dwie wartości zawarte w ramach pola bazowego i istnieje ponadto potrzeba wybrania "choice" (wybór) lub "option" pośród wartości, zaleca się utworzenie z pola, pola strukturalnego i włączenie wartości zawartych w ramach podpól.

5.2.4. Pola wykazu

5.2.4.1. Składnia pól wykazu powinna być następująca:

list_field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword

5.2.4.2. "Podpola" mogą stanowić dowolną kombinację podpól, których występowanie może mieć miejsce zero lub więcej razy wewnątrz pola wykazu.

5.2.4.3. Wykaz podpól zawartych w danym polu wykazu ma utworzyć zbiór uporządkowany (kolejność podpól jest istotna).

Przykładowa zasada

addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"

UWAGA

1) Przykład ten pokazuje, że pole "addr" jest polem wykazu, zawierającym 0 lub więcej wystąpień podpola "fac" (udogodnienie ATS).

2) Przykładem części komunikatu pokazującego ADDR jako pole wykazu zawierające podpola FAC jest:

-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) Poniżej znajduje się przykładowa część komunikatu przedstawiającego kombinację podpól:

xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5. Pola strukturalne

5.2.5.1. Składnia pól strukturalnych jest następująca:

structured_field::= '-' keyword field_1 field_2…field_n

5.2.5.2. Dozwolone podpola zawarte w danym polu strukturalnym zależą tylko od samego pola strukturalnego.

5.2.5.3. Kolejność występowania podpól w polu strukturalnym nie powinna być znacząca, co pozwoli na łatwe rozszerzanie w przyszłości (poprzez dodanie nowych zawartych podpól).

Przykładowa zasada

pt::= '-' "PT" ptid [fl] [eto]

UWAGI

1) To definiuje pole "pt" jako pole strukturalne zawierające punkt (podpole "ptid"), po którym, jako opcję, umieszcza się obliczony poziom lotu (podpole "fl"), po którym, jako opcję, umieszcza się przewidywany czas nad punktem (podpole "eto").

2) Przykładowym wystąpieniem tego pola może być na przykład:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

5.2.5.4. Zalecenie

Gdy oczekuje się, że zawartość pola może w przyszłości się rozszerzyć, właściwe jest uczynienie go polem strukturalnym. Pozwoli to na progresywne rozszerzanie podpól. Przeciwnie, pole bazowe może być prostsze lub bardziej znane w użyciu, ale narzuca stałą sekwencję elementów (wartości) przy bardzo ograniczonych możliwościach rozszerzania.

5.2.6. Pole COMMENT

5.2.6.1. Pole comment wprowadza obszar wolnego tekstu, gdzie mogą być użyte wszystkie dostępne znaki, oprócz znaku początku pola ("-") i które rozciąga się na następne pole.

comment::= '-' "COMMENT" { LIM_CHAR }

Przykład

COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

Text missing!!!

5.2.7. Pole TITLE

5.2.7.1. Pierwszym polem komunikatu ADEXP zawsze musi być pole title. Powinno mieć następującą składnię:

title::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2. Możliwe wartości pola title składają się z zestawu tytułów komunikatów ADEXP, zgodnie z wykazem w załączniku B niniejszej normy.

Przykład

-TITLE IFPL

6. ZNORMALIZOWANY OPIS KOMUNIKATÓW ADEXP

6.1. Wstęp

6.1.1. Poniższe podpunkty określają, jak należy opisać format ADEXP dla różnych kategorii komunikatów w sposób znormalizowany, w ramach niniejszej normy.

6.1.2. Znormalizowany opis uwzględnia:

- definicję terminów posiłkowych;

- definicję składni i semantyki każdego z poszczególnych pól podstawowych;

- definicję składni i semantyki każdego z poszczególnych podpól;

- definicję każdej grupy komunikatów z odniesieniem do ich dokumentacji definiującej.

6.1.3. Niniejsza norma nie podaje szczegółów dotyczących tworzenia pola i zasad zamieszczania danych dla każdego tytułu komunikatu.

6.1.4. Należy uczynić odniesienie do dokumentacji definiującej (specyfikacja interfejsu), którą stosuje się do odpowiedniej grupy komunikatów (patrz ppkt 6.5.7).

6.1.5. Dokumentacja definiująca powinna przedstawiać w znormalizowany sposób następujące informacje do każdego tytułu komunikatu:

- wykaz obowiązkowych pól podstawowych;

- wykaz pól podstawowych do wyboru;

- zasady zamieszczania danych dla każdego pola i, w szczególności, zasady dotyczące użycia podpól zdefiniowanych jako pola do wyboru w ramach normy;

- zasady dotyczące odzyskania po wykryciu pola nierozpoznawalnego.

6.1.6. Pola obecnie zdefiniowane i uzgodnione w Państwach Członkowskich Eurocontrolu do wykorzystania w ramach różnych kategorii komunikatów, które były zdefiniowane do użycia z wykorzystaniem ADEXP, są przedstawione w załączniku A do niniejszego dokumentu.

6.1.7. Pole nie powinno być użyte do innego celu, niż cel określony w jego opisie semantycznym.

6.1.8. Centralny indeks zarezerwowanych pól przedstawiony jest w załączniku D. "Zarezerwowane pola" nie zostały uzgodnione do użytku w ramach obecnie zdefiniowanych komunikatów ADEXP. Zazwyczaj są to pola, których ewentualne wykorzystanie przewiduje się w przyszłości lub które używane są na poziomie lokalnym w ramach systemów krajowych. Celem włączenia ich do niniejszej normy jest pomoc przy zapewnianiu jednoznaczności tytułów pola i unikaniu zbędnej nadmiarowości.

6.2. Terminy posiłkowe

6.2.1. W celu udostępnienia czytelnej definicji pola często użyteczne jest wprowadzanie terminów posiłkowych w opisie gramatycznym.

6.2.2. Terminy posiłkowe nie wprowadzają pola lub podpola, nie są więc kojarzone z konkretnym słowem kluczowym. Jednak mogą pojawić się w definicji więcej niż jednego pola lub podpola, lub pola posiłkowego. Na przykład taki termin posiłkowy jak "date" może być użyty w definicji wielu pól.

6.2.3. Wszystkie niezbędne terminy posiłkowe powinny być wprowadzone w porządku alfabetycznym i są zdefiniowane w załączniku A (A2) do niniejszej normy.

6.2.4. Opis może być przedstawiony w tabelce w następujący sposób, alfabetycznie:

Termin posiłkowy | Składnia | Semantyka | Użycie w polu | Użycie w podpolu | Użycie w polu posiłkowym |

adexpmsg | { CHARACTER } | Wolny tekst zgodny ze składnią opisaną dla komunikatu ADEXP. | | ifpdlong rfpdlong preproctxt postproctxt | |

aidequipment | ( ('N' | 'S') ! [ equipmentcode ] ) | equipmentcode | Urządzenia radiokomunikacjne, nawigacyjne i służące do podejścia. | ceqpt | | |

aircraftid | 1{ ALPHANUM }7 | Identyfikacja statku powietrznego. | arcid arcidk arcidold prevarcid | | |

6.3. Definicja pól podstawowych

6.3.1. Wszystkie pola podstawowe używane w komunikatach ADEXP są zgodne ze składnią i semantyką przedstawioną w załączniku A (A3) niniejszej normy.

6.3.2. Najpierw będzie podana składnia każdego pola, następnie jego semantyka, przy zastosowaniu prostych, jasnych i jednoznacznych terminów.

6.3.3. Składnia pól wyrażona zostanie z użyciem znaków umownych BNF, zgodnie z wprowadzeniem w pkt 3 niniejszej normy.

6.3.4. Opis może być przedstawiony w tabelce w następujący sposób, alfabetycznie, gdzie:

- pierwsza kolumna przedstawia zasadę BNF (tzn. ta część zasady na lewo od symbolu "::="), a trzecia kolumna przedstawia jej prawą część;

- druga kolumna (rodzaj) wskazuje, czy pole jest podstawowe ("b") czy złożone ("c").

Pole | Rodzaj | Składnia | Semantyka |

eobt | b | '-' "EOBT" timehhmm | Szacowany czas poza blokiem |

6.4. Definicja podpól

6.4.1. Wszystkie podpola używane w komunikatach ADEXP są zgodne ze składnią i semantyką przedstawioną w załączniku A (A4) niniejszej normy.

6.4.2. Ponadto, do celów odniesienia, określone są pola podstawowe, wewnątrz których znajduje się dane podpole.

6.4.3. Podpole może być także podpolem innego podpola, wówczas podaje się także odniesienie do tych podpól.

6.4.4. Opis może być przedstawiony w tabelce w następujący sposób, alfabetycznie:

Podpole | Rodzaj | Składnia | Semantyka | Użycie w polu | Użycie w podpolu |

brng | b | '-' "BRNG" refbearing | Namiar punktu z urządzenia nawigacyjnego (w stopniach magnetycznych) | ref | |

6.5. Grupa komunikatów

6.5.1. Kategorie operacyjne (grupy) komunikatów, które zostały określone do użycia z wykorzystaniem formatu ADEXP są wprowadzone w załączniku E niniejszej normy.

6.5.2. Grupy są określone pod względem natury operacyjnej wymienianych komunikatów i są często charakteryzowane za pomocą danych systemów.

6.5.3. Odniesienie do dokumentacji określającej stosuje się dla każdej grupy komunikatów.

6.5.4. Nie używa się ponownie wartości tytułu już użytej dla grupy komunikatów w odniesieniu do innej grupy o innym znaczeniu.

6.5.5. Centralny indeks tytułów komunikatów jest przestawiony w załączniku B do niniejszej normy.

6.5.6. Odniesienie do pokrewnej grupy daje się dla każdego tytułu komunikatu wymienionego w centralnym indeksie tytułów komunikatów. Odniesienie do dokumentacji określającej dla każdego tytułu komunikatu jest wobec tego udostępniane poprzez grupę komunikatów.

6.5.7. Centralny indeks zarezerwowanych tytułów komunikatów przedstawiony jest także w załączniku C. "Zarezerwowane" tytuły komunikatów nie zostały uzgodnione do użycia w ramach obecnie określonej grupy komunikatów wykorzystujących ADEXP. Zazwyczaj są to komunikaty, które przewidziano do ewentualnego użycia w przyszłości w ramach jednej z określonych grup lub są wykorzystywane lokalnie w ramach systemów krajowych. Celem włączenia ich do niniejszej normy jest zapewnienie jednoznaczności tytułów komunikatów i uniknięcie zbędnej nadmiarowości.

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

ZAŁĄCZNIK III

WYMIANA DANYCH LOTU — DOKUMENT KONTROLI INTERFEJSU (FDE-ICD), EDYCJA 1.0

(Dokument odniesienia Eurocontrolu COM.ET1.ST12-STD)

SPIS TREŚCI

NOTA DOTYCZĄCA PRAW AUTORSKICH … PRZEDMOWA … 1. WPROWADZENIE …

2. ZAKRES …

3. ODNIESIENIA …

3.1. Wprowadzenie …

3.2. Odniesienia …

4. DEFINICJE, SYMBOLE I SKRÓTY …

4.1. Definicje …

4.2. Symbole i skróty …

4.3. Oznaczenia …

5. PRZEGLĄD TECHNICZNY …

5.1. Stos protokołów …

5.2. Struktura profilu …

5.3. Odniesienie do poprzednich wersji specyfikacji …

6. WYMAGANIA DOTYCZĄCE PROFILI …

6.1. Wymagania zgodności …

6.2. Wymagania dotyczące wyższej warstwy …

6.3. Wymagania dotyczące dolnej warstwy …

6.3.1. Wymagania dotyczące warstwy transportu …

6.3.2. Wymagania dotyczące warstwy sieciowej …

6.3.3. Wymagania dotyczące warstwy łącza danych …

6.3.4. Wymagania dotyczące warstwy fizycznej …

7. METODY TESTOWE …

ZAŁĄCZNIK A (NORMATYWNY) PROTOKÓŁ PRZESYŁANIA KOMUNIKATU … A.1. Wprowadzenie …

A.2. Usługa wykonana …

A.3. Usługa przyjęta …

A.4. Specyfikacja protokołu …

A.4.1. Wprowadzenie …

A.4.2. Rodzaje danych …

A.4.3. Nawiązanie połączenia …

A.4.4. Przesyłanie danych …

A.4.5. Uporządkowane wydanie połączenia …

A.4.6. Ponowne nawiązanie połączenia …

A.4.7. Integralność połączenia …

A.4.8. Nieuporządkowane wydanie połączenia …

A.4.9. Naprawa awarii …

A.4.10. Formaty komunikatów …

A.5. Tablice zmiany stanu protokołu …

A.5.1. Wstęp …

A.5.2. Definicje stanu …

A.5.3. Możliwe zdarzenia …

A.5.4. Czasomierze …

A.5.5. Tabela zmiany stanu …

A.5.6. Schemat zmiany stanu …

ZAŁĄCZNIK B (NORMATYWNY) PROTOKÓŁ NAGŁÓWKA KOMUNIKATU … B.1. Wstęp …

B.2. Wdrożona usługa …

B.3. Przyjęcie usługi …

B.4. Specyfikacja protokołu …

B.4.1. Ustanowienie połączenia …

B.4.2. Unikanie nadmiarowych połączeń w sieci …

B.4.3. Uwolnienie połączenia …

B.4.4. Przesyłanie danych …

ZAŁĄCZNIK C (NORMATYWNY) PROTOKÓŁ SIECIOWY … C.1. Wstęp …

C.2. Udostępnienie usług …

C.3. Przyjęcie usługi …

C.4. Adresowanie NSAP …

C.4.1. Wstęp …

C.4.2. Struktura adresu NSAP …

C.4.3. Przyznanie identyfikatorów i selektorów jednostki ATC …

C.5. Specyfikacja protokołu …

C.5.1. Przegląd …

C.5.2. Kodowanie adresu …

C.5.3. Kodowanie pola danych użytkownika …

C.5.4. Traktowanie adresów w pakietach INCOMING CALL …

C.5.5. Przesyłanie danych …

ZAŁĄCZNIK D (NORMATYWNY) FORMULARZE PICS SPECYFICZNE DLA PROFILU … D.1. Wstęp …

D.2. Instrukcje wypełniania formularzy PICS …

D.2.1. Ogólna struktura formularzy PICS …

D.2.2. Dodatkowe informacje …

D.2.3. Informacja o wyjątkach …

D.2.4. Elementy warunkowe …

D.3. Formularz PICS dla protokołu przesyłania komunikatu …

D.3.1. Skróty i symbole specjalne …

D.3.2. Identyfikacja …

D.3.3. Wdrażanie protokołu …

D.4. Formularz PICS dla protokołu nagłówka komunikatu …

D.4.1. Skróty i symbole specjalne …

D.4.2. Identyfikacja …

D.4.3. Wdrażanie protokołu …

D.5. Formularz PICS dla protokołu sieciowego …

D.5.1. Skróty i symbole specjalne …

D.5.2. Identyfikacja …

D.5.3. Wdrażanie protokołu …

ZAŁĄCZNIK E (NORMATYWNY) WYKAZ WYMOGÓW PROFILU … E.1. Wstęp …

E.2. Rola PRL i formularzy PICS …

E.3. Znaki umowne …

E.4. Instrukcje wypełniania formularzy PICS …

E.5. Odniesienia …

E.6. Oświadczenie o zgodności …

E.6.1. Weryfikacja zgodności …

E.6.2. Dynamiczne wymogi zgodności …

E.7. Wymogi dotyczące wyższej warstwy …

E.8. Wymogidotyczące dolnej warstwy …

E.8.1. Wymogi dotyczące warstwy transportu …

E.8.2. Wymogi dotyczące warstwy sieciowej …

E.8.3. Wymogi dotyczące warstwy łącza danych …

E.8.4. Wymogi dotyczące warstwy fizycznej …

ZAŁĄCZNIK F (INFORMACYJNY) METODOLOGIA TESTOWANIA ZGODNOŚCI … F.1. Wstęp …

F.2. Cel i zakres …

F.3. Bibliografia …

F.4. Metody i czynności rozwojowe …

F.5. Testy …

F.5.1. Badania …

F.5.2. Badanie dolnych warstw (warstwy 1-3) …

F.5.3. Badanie warstwy aplikacji …

F.5.4. Certyfikacja …

F.5.5. Zawiadomienie …

ZAŁĄCZNIK G (INFORMACYJNY) PRZYZNANIE IDENTYFIKATORÓW JEDNOSTKI ATC … ZAŁĄCZNIK H (INFORMACYJNY) INFORMATOR DOTYCZĄCY WIARYGODNOŚCI, DOSTĘPNOŚCI I BEZPIECZEŃSTWA … H.1. Wstęp …

H.2. Cel i zakres …

H.3. Bibliografia …

H.4. Informacje linii łączy dzierżawionej …

H.4.1. Wiarygodność …

H.4.2. Dostępność …

H.4.3. Bezpieczeństwo …

H.4.4. Przykład konfiguracji …

H.5. Wdrażanie sieci …

H.5.1. Wiarygodność …

H.5.2. Dostępność …

H.5.3. Bezpieczeństwo …

H.6. Ogólny informator dotyczący linii dzierżawionej i wdrażania sieci …

H.6.1. Wiarygodność …

H.6.2. Dostępność …

H.6.3. Zarządzanie systemami …

H.6.4. Przykład konfiguracji …

NOTA DOTYCZĄCA PRAW AUTORSKICH

Niniejszy dokument został opracowany przez Agencję Eurocontrol.

Prawa autorskie przysługują Agencji Eurocontrol.

Treść dokumentu lub jakakolwiek jego część jest ogólnie dostępna przedstawicielom Państw Członkowskich, ale kopiowanie lub ujawnienie każdej innej stronie wymaga wyrażonej na piśmie uprzedniej zgody Agencji Eurocontrol.

PRZEDMOWA

1. Organ odpowiedzialny

Niniejszy dokument normy został sporządzony i jest utrzymywany przez Grupę Roboczą ds. Wymiany Danych Dotyczących Planu Lotu (FPDE) Europejskiej Organizacji ds. Bezpieczeństwa Nawigacji Lotniczej (Eurocontrol).

2. Dokument Program pracy EATCHIP

Niniejsza norma odnosi się do dokumentu Program pracy EATCHIP (EWPD), domena ds. łączności, zadanie wykonawcze 01, zadanie specjalistyczne 12.

3. Zatwierdzenie normy

3.1. Niniejszą normę przyjmuje się zgodnie z procedurami wymienionymi w dyrektywach dotyczących przyjęcia norm Eurocontrolu, ref. 000-2-93.

3.2. Niniejsza norma staje się skuteczna po przyjęciu przez Stałą Komisję Eurocontrolu i zastępują normę Eurocontrolu dotyczącą bezpośredniej wymiany danych (OLDI), wydanie 1 część 3: WYMAGANIA TECHNICZNE (Krótkoterminowy dokument kontroli interfejsu) ref. 001-3-92.

4. Sprostowania techniczne i zmiany

Niniejsza norma jest poddawana przeglądom w celu oceny wymaganych zmian lub technicznych sprostowań. Procedura dotycząca utrzymania niniejszej normy jest ustanowiona w załączniku H do dyrektyw dotyczących jednolitego sporządzania i przedstawiania dokumentów normy Eurocontrolu ref. 000-1-92.

5. Konwencje edytorskie

5.1. Format niniejszej normy jest zgodny z dyrektywami dotyczącymi jednolitego sporządzania i przedstawiania dokumentów normy Eurocontrolu.

5.2. Następujące oznaczenia zostały użyte w celu wskazania statusu każdego zdania:

- zdania normatywne używają czasownika funkcjonalnego "shall" i zostały wydrukowane zwykłą czcionką times roman;

- zalecenia używają czasownika funkcjonalnego "should" i zostały wydrukowane czcionką pochyłą, a ich status został określony za pomocą prefiksu zalecenie.

5.3. Wszelkie inne informacje uznane za istotne dla zrozumienia poszczególnych tiret zostaną zintegrowane z tekstem jako UWAGA. Uwaga jest uważna jedynie za mającą charakter informacyjny, dlatego nie zawiera specyfikacji i jest umieszczana bezpośrednio po tiret, do którego się odnosi.

5.4. Wyjątkowo, w celu przedstawienia wykazu wymagań profilu (PRL) w załączniku E w odpowiednim formacie, niektóre tabele nie są wcięte i nie zajmują kilku stron.

6. Związek z innymi dokumentami normy

6.1. Niniejszy dokument normy Eurocontrolu zastępuje Krótkoterminowy dokument kontroli interfejsu OLDI (ST-ICD), wydanie 1 część 3 normy Eurocontrolu OLDI [odniesienie 13].

6.2. Niniejszy dokument normy Eurocontrolu stanowi pierwszą część oczekiwanej serii normy Eurocontrolu dotyczącej wymiany danych lotu — dokumentów kontroli interfejsu (ICDs).

7. Status załączników do niniejszej normy

Załączniki do niniejszej normy mają następujący status:

- Załącznik A — Normatywny

- Załącznik B — Normatywny

- Załącznik C — Normatywny

- Załącznik D — Normatywny

- Załącznik E — Normatywny

- Załącznik F — Informacyjny

- Załącznik G — Informacyjny

- Załącznik H — Informacyjny

8. Użyty język

Język angielski został użyty w oryginalnym tekście niniejszej normy.

1. WPROWADZENIE

Niniejsza norma Eurocontrolu jest oparta na Krótkoterminowym dokumencie kontroli interfejsu opracowanym przez byłą podgrupę techniczną OLDI, której zadaniem było zdefiniowanie nowej normy interfejsu dla przyszłych operacji OLDI między Centrami Kontroli Obszaru.

Wcześniejsze łącza OLDI opierały się na zastrzeżonych protokołach, takich jak INTERCAUTRA lub Datenübertragungs- und Verteilungssystem (DÜV), które przebiegają w ramach wydzielonego układu dwupunktowego lub ograniczonych sieci i wymagają użycia specjalistycznego sprzętu i oprogramowania.

W odniesieniu do większej liczby nowych planowanych połączeń pożądanym wydawało się przejście w kierunku architektury opartej na sieci i przyjęcie międzynarodowych norm telekomunikacyjnych, umożliwiając realizację połączeń w sposób bardziej efektywny pod względem kosztów, poprzez zmniejszenie liczby punktów styku w każdym Centrum i zezwolenie na użytkowanie standardowego sprzętu i oprogramowania gotowego.

Niniejsza norma Eurocontrolu formalizuje i rozszerza zakres Krótkoterminowego ICD. ST-ICD napisano ponownie w celu wprowadzenia bardziej rygorystycznej specyfikacji pozwalającej na poprawę interoperacyjności oraz, dodatkowo, odpowiedniej do utworzenia podstawy przyszłych ICD, pozwalających na sprostanie zwiększającym się wymaganiom dotyczącym wymiany danych lotu (FDE), łącznie z szerszym użyciem wspólnych sieci i wprowadzeniem nowej normy dolnej warstwy. Niniejsza norma Eurocontrolu wprowadza minimalny zestaw grup funkcyjnych, które mogą być wspierane przez istniejące implementacje OLDI przy minimalnej modyfikacji, z wykorzystaniem łączy dwupunktowych lub sieci komutacji pakietów Comité Consultatif des Téléphones et Télégraphes (CCITT) Zalecenie X.25, 1980 r. lub późniejsze. W odniesieniu do zamówień można określić więcej możliwości. Niniejszy ICD nie zapobiega poczynieniu dalszych uzgodnień na podstawie umowy dwustronnej.

W przypadku zamiaru uruchomienia na instalacjach innych protokołów aplikacji, dodatkowo lub zamiast opisanego w niniejszym dokumencie można zwrócić się o zmianę niniejszego protokołu lub oddzielić swój protokół poprzez użycie innych układów wirtualnych.

2. ZAKRES

2.1. Niniejszy dokument normy Eurocontrolu określa interfejs transmisji danych dla wymiany komunikatów zawierających dane lotu między centrami kontroli obszaru (ACCs). Przedstawiony jest on w formie profilu połączenia systemów otwartych (OSI), jak określono w sprawozdaniu technicznym (TR) 10000-2 [odniesienie 3] Międzynarodowej Organizacji Normalizacyjnej/Międzynarodowej Komisji Elektrotechnicznej (ISO/IEC). Profil obejmuje zarówno dolne warstwy (Profil-T), jak i wyższe warstwy (Profil-A).

2.2. Niniejszy dokument normy Eurocontrolu ma zastosowanie w następujących przypadkach:

- obsługi OLDI, jak opisano w normie Eurocontrolu nr 001-92 wydanie1;

- obsługi przekazywania komunikatów aplikacji OLDI z ACC do systemów Centralnej Jednostki Zarządzania Ruchem Lotniczym (CFMU).

2.3. Normę stosuje się do połączenia używającego albo:

- układu dwupunktowego łącza dzierżawionego, albo

- układu dwupunktowego publicznej komutowanej sieci telefonicznej c), lub

- sieci przesyłania danych z komutacją pakietu lub połączonych wzajemnie sieci przesyłania danych z komutacją pakietu, które udostępniają interfejs zgodny z zaleceniem X.25 CCITT, 1980 r. lub później.

UWAGI

1. Układ systemów przetwarzania planu lotu (FPPS) przedstawiony jest na rysunku 1.

2. Rysunek 1 nie ilustruje potencjalnych połączeń zapasowych, takich jak PSTN, w odniesieniu do których wytyczne podano w załączniku H.

+++++ TIFF +++++

Rysunek 1Układ interfejsu

2.4. Szczegółowe względy bezpieczeństwa określonego interfejsu transmisji danych nie są nakazane przez niniejszą normę. Jednak przepisy podstawowe określone są w Załączniku, a dalsze wytyczne znajdują się w załączniku H do niniejszej normy Eurocontrolu.

3. ODNIESIENIA

3.1. Wprowadzenie

Następujące dokumenty i normy zawierają przepisy, które, przez odniesienie do niniejszego tekstu, stanowią przepisy niniejszej normy Eurocontrolu.

W chwili publikacji niniejszej normy Eurocontrolu, wydania wskazane dla dokumentów odniesienia i norm były ważne.

Wszelkie zmiany w dokumentach odniesienia Międzynarodowej Organizacji Lotnictwa Cywilnego (ICAO) uwzględnia się niezwłocznie w celu weryfikacji niniejszej normy Eurocontrolu.

Zmiany w innych dokumentach odniesienia nie stanowią części przepisów niniejszej normy Eurocontrolu, dopóki nie zostaną formalnie zweryfikowane i włączone do niniejszego dokumentu zawierającego normę Eurocontrolu.

W przypadku sprzeczności między wymaganiami niniejszego dokumentu zawierającego normę Eurocontrolu i treścią innych dokumentów odniesienia, niniejsza norma Eurocontrolu ma pierwszeństwo.

3.2. Odniesienia

1. ITU-T zalecenie X.25 (1993 r.) (Rev. 1), Interfejs między urządzeniem końcowym do transmisji danych (DTE) oraz wyposażeniem komunikacyjnym węzła sieci (DCE) dla terminali operujących w pakiecie komutowanym i przyłączonych do publicznych sieci danych przez kanał wydzielony.

2. ISO/IEC TR 10000-1:1992 r., Technologia informatyczna — Zarys i nazewnictwo międzynarodowych profili znormalizowanych: — część 1: Zarys (wydanie 2).

3. ISO/IEC TR 10000-2:1994 r., Technologia informatyczna — Zarys i nazewnictwo międzynarodowych profili znormalizowanych — część 2: Zasady i nazewnictwo profili OSI (wydanie 3).

4. ITU-T zalecenie X.21 (1992 r.) (Rev. 1), Interfejs między urządzeniem końcowym do transmisji danych (DTE) oraz wyposażeniem komunikacyjnym węzła sieci (DCE) dla operacji synchronicznych w publicznych sieciach danych.

5. CCITT zalecenie X.21bis (1988 r.), Używanie w publicznych sieciach danych urządzeń końcowych do transmisji danych (DTE), które są zaprojektowane do zapewnienia połączenia za pomocą interfejsu do synchronicznych modemów serii V.

6. ISO/IEC 7776:1994 r., Technologia informatyczna — Telekomunikacja i wymiana informacji między systemami — Procedury wysokiego poziomu do sterowania łączem danych — Opis procedur łącza danych dla DTE zgodnych z X.25 LAP B (wydanie 2).

7. ISO/IEC 8208:1993 r., Technologia informatyczna — Transmisja danych — X.25 protokół warstwy pakietu dla urządzeń końcowych do transmisji danych (wydanie 3).

8. ISO/IEC ISP 10609-9:1992 r., Technologia informatyczna — Międzynarodowe znormalizowane profile TB, TC, TD i TE — Połączeniowa usługa transportowa oparta na połączeniowej usłudze sieciowej — część 9: Wymagania zależne od typu podsieci dla warstwy sieciowej, warstwy łącza danych i warstwy fizycznej odnoszące się do ciągłego dostępu do sieci danych z komutacją pakietów z zastosowaniem połączeń wirtualnych.

9. ISO/IEC 7498-1:1994 r., Technologia informatyczna — Współdziałanie systemów otwartych — Podstawowy model odniesienia: Model podstawowy (wydanie 2).

10. ISO/IEC 8348:1993 r., Technologia informatyczna — Współdziałanie systemów otwartych — Definicja usługi sieciowej (wydanie 1).

11. ISO/IEC 8072:1994 r., Technologia informatyczna — Współdziałanie systemów otwartych — Definicja usługi transportowej (wydanie 2).

12. ISO/IEC 8878:1992 r., Technologia informatyczna — Telekomunikacja i wymiana informacji między systemami — Wykorzystanie X.25 dla zapewnienia połączeniowych usług sieciowych OSI (wydanie 2).

13. Norma Eurocontrolu dotycząca bezpośredniej wzajemnej wymiany danych (OLDI), nr 001-92, wydanie 1, 1992 r.

14. ISO/IEC 9646-1:1994 r., Technologia informatyczna — Współdziałanie systemów otwartych — Metodologia i zarys testowania zgodności — część 1: Pojęcia ogólne (wydanie 2).

15. Eurocontrol (Wydział Systemów Zarządzania Górną Przestrzenią Powietrzną Maastricht (UAC)) FDE ICD część 1, Plan testu integracyjnego, wersja 1.0, z dnia 10 maja 1996 r.

16. Eurocontrol FDE ICD część 1 — Wiarygodność, dostępność i bezpieczeństwo — Sprawozdanie techniczne, wersja 1.0, z dnia 20 kwietnia 1997 r.

17. ITU-T zalecenie X.32 (1993 r.) (Rev. 1), Interfejs między DTE i DCE dla terminali operujących w trybie komutacji pakietu i mających dostęp do komutowanych pakietów danych publicznych poprzez publiczną komutowaną sieć telefoniczną lub sieć cyfrową z zintegrowanymi usługami lub publiczną sieć danych komutacji połączeń.

18. ITU-T zalecenie E.164 (1991 r.) (Rev. 1), Plan numeracji dla ery ISDN.

19. ITU-T zalecenie X.75 (1993 r.) (Rev. 1), Instalacja sygnalizacyjna z komutacją pakietów w sieci publicznej udostępniającej usługi transmisji danych.

20. ITU-T zalecenie X.121 (1993 r.), Międzynarodowy plan numeracji dla publicznych sieci danych.

4. DEFINICJE, SYMBOLE I SKRÓTY

4.1. Definicje

4.1.1. Do celów niniejszego dokumentu zawierającego normę Eurocontrolu zastosowanie mają następujące definicje:

Profil : Zestaw złożony z jednej lub więcej norm bazowych oraz, w razie konieczności, identyfikacja wybranych klas, podzbiorów, opcji i parametrów tych norm bazowych, niezbędne dla zastosowania poszczególnych funkcji [odniesienie 2].

Wykaz wymagań profilu (PRL) : Wymagania profilu wyrażone są w formie wymagań zgodności i przedstawione są w formacie wykazu tabelarycznego [odniesienie 2].

Profil-T : Profil transportowy zapewniający tryb połączenia ze służbami transportowymi [odniesienie 3].

Profil-A : Profil aplikacji wymagający trybu połączenia ze służbami transportowymi [odniesienie 3].

Deklaracja zgodności wykonania protokołu (PICS) : Oświadczenie dostawcy systemu OSI, stwierdzające, które właściwości zostały wykonane w odniesieniu do danego protokołu OSI [odniesienie 14].

4.2. Symbole i skróty

Do celów niniejszego dokumentu normy Eurocontrolu stosowane są następujące symbole i skróty:

ACC | Centrum Kontroli Obszaru |

AFI | Identyfikator upoważnienia i formatu |

ASCII | Kod ASCII (American Standard Code for Information Interchange) |

ATC | Kontrola ruchu lotniczego |

ATCC | Centrum Kontroli Ruchu Lotniczego |

CAUTRA | Coordinateur Automatique du Trafic Aérien (Automatyczna Koordynacja Ruchu Lotniczego) |

CCITT | Comitée consultatif international télégraphique et téléphonique (obecnie ITU-T) |

CFMU | Centralna Jednostka Zarządzania Ruchem Lotniczym |

CUG | Zamknięta grupa użytkowników |

DCE | Wyposażenie komunikacyjne węzła sieci |

DCFS | Urządzenia końcowe do cyfrowego systemu transmisji |

DSP | Szczególna część domeny |

DTE | Urządzenie końcowe do transmisji danych |

DÜV | Datenübertragungs- und Verteilungssystem |

FDE | Wymiana danych lotu |

FEP | Procesor czołowy |

FPDE | Wymiana danych dotyczących planu lotu |

FPPS | System przetwarzania planu lotu |

ICAO | Europejska Konferencja Lotnictwa Cywilnego |

ICD | Dokument kontroli interfejsu |

IDI | Identyfikator domeny początkowej |

IDP | Część domeny początkowej |

IEC | Międzynarodowa Komisja Elektrotechniczna |

INTER-CAUTURA | Protokół Inter-CAUTRA |

ISO | Międzynarodowa Organizacja Normalizacyjna |

ITU-T | Międzynarodowa Unia Telekomunikacyjna — sektor normalizacji w telekomunikacji |

ISDN | Sieć cyfrowa ze zintegrowanymi usługami |

LAPB | Zrównoważona procedura dostępu do łącza |

LSB | Bit najmniej znaczący |

M, m | Obowiązkowy |

MSB | Bit najbardziej znaczący |

MT | Przesyłanie komunikatu |

NA | Nie odnosi się |

NS | Usługa sieciowa |

NSAP | Punkt dostępu do usługi sieciowej |

NSDU | Jednostka danych usługi sieciowej |

O, O.<n> | Fakultatywne, gdzie <n> jest cyfrą do odwołań |

o, o.<n> | Fakultatywne, gdzie <n> jest cyfrą do odwołań |

OLDI | Bezpośrednia wzajemna wymiana danych |

OSI | Współdziałanie systemów otwartych |

PICS | Deklaracja zgodności wykonania protokołu |

PLP | Protokół warstwy pakietu |

PRL | Wykaz wymagań profilu |

PSTN | Publiczna komutowana sieć telefoniczna |

ST-ICD | Krótkoterminowy Dokument kontroli interfejsu |

SUT | System poddawany testowaniu |

T<x> | Czasomierz (gdzie <x> jest pojedynczą lub podwójną literą do odwołań) |

TA | Adapter terminalowy |

TSDU | Jednostka danych służb transportowych |

TPDU | Jednostka danych protokołu transportowego |

TR | Sprawozdanie techniczne ISO |

X | Zakazany |

x | Wyłączony |

<item>: | Warunkowy element (zależy od wartości elementu) |

4.3. Oznaczenia

4.3.1. Do celów niniejszego dokumentu zawierającego normę Eurocontrolu wartości dwójkowe lub sekwencja bitów oznaczone są szesnastkowo przy użyciu oznaczenia "d"H, gdzie lit. d oznacza cyfrę lub sekwencję cyfr szestnastkowych.

4.3.2. Do celów niniejszego dokumentu zawierającego normę Eurocontrolu szestnastkowa reprezentacja sekwencji bitów tworzona jest poprzez użycie 4 bitów jednocześnie, od bitu najbardziej znaczącego (MSB) do bitu najmniej znaczącego (LSB).

UWAGA

Chyba że ustalono inaczej w określonych normach międzynarodowych, sekwencja bitów przekazywana jest z MSB do LSB.

4.3.3. Do celów niniejszego dokumentu zawierającego normę Eurocontrolu status obsługi właściwości normy podstawowej lub niniejszej normy Eurocontrolu przedstawia się dużymi literami (np. M, O, O.<n>, X). Dokładne znaczenie każdego z symboli statusu opisane jest w załącznikach do niniejszej normy Eurocontrolu przed ich użyciem.

4.3.4. Do celów zdefiniowania profilu FDE ICD, część 1 w niniejszym dokumencie normy Eurocontrolu status obsługi właściwości normy podstawowej lub niniejszej normy Eurocontrolu przedstawia się małymi literami (np. m, o, o.< n >, x).

UWAGA

Skutkiem powyższego jest dalsze udoskonalenie właściwości normy podstawowej, które są warunkowe, fakultatywne lub zależne od wartości (patrz ppkt E.3.1).

5. PRZEGLĄD TECHNICZNY

5.1. Stos protokołów

UWAGA

Stos protokołów dla profilu niniejszej normy Eurocontrolu przedstawiony jest na rysunku 2. Na rysunku protokoły umieszczone są w ramach podstawowego modelu odniesienia OSI [odniesienie 9] poprzez wyrównanie stosu do odpowiadających warstw OSI. Jednak stos protokołów jest specyfikacją dla systemów powstałych przed systemami OSI i nie wspiera wielu funkcji, które są dozwolone w protokołach OSI dla odpowiadających warstw OSI.

+++++ TIFF +++++

Rysunek 2Profil stosu protokołów

5.2. Struktura profilu

UWAGI

1. Jak przedstawiono na rysunku 2, stos profili kilku protokołów dolnej warstwy, z których jedynie X.25 protokół warstwy pakietu (PLP) [odniesienie 1] i wspierające go protokoły, X.21 [odniesienie 4] oraz X.21bis [odniesienie 5], określone są w istniejących normach ISO/IEC oraz normach Międzynarodowego Związku Telekomunikacyjnego — sektor normalizacji w telekomunikacji (ITU-T). Inne protokoły wyższej warstwy są zdefiniowane w załącznikach (załączniki A, B i C) do niniejszego dokumentu zawierającego normę Eurocontrolu.

2. Wymagania zgodności dla profilu mogą odnosić się do tych specyfikacji na takiej samej zasadzie, jak do zewnętrznych norm i przedstawione są w pkt 6. Szczegółowe wymagania przedstawione są przy wykorzystaniu formatu tabelarycznego PRL (załącznik E) oraz formularzy PICS (formularze dla protokołów zdefiniowanych w załącznikach zawarte są w załączniku D). Użycie tych PRL i formularzy PICS na etapie rozwoju i/lub zamówień wyjaśniono w załączniku E.

5.3. Odniesienie do poprzednich wersji specyfikacji

UWAGI

1. Profil ten oparty jest na ST-ICD, opracowanym przez byłą podgrupę techniczną OLDI. Protokoły i formaty pakietu określone w niniejszym dokumencie normy Eurocontrolu są podzbiorem zgodnym z ST-ICD, z takim wyjątkiem, że niniejsza norma Eurocontrolu zawiera bardziej szczegółowe wymagania w odniesieniu do użycia X.25 PLP, obejmuje obowiązkową obsługę megabitu i poprawia niezgodną specyfikację wartości identyfikatora upoważnienia i formatu (AFI) w adresie punktu dostępu do usługi sieciowej (NSAP).

2. Główna zmiana charakteru niniejszego dokumentu zawierającego normę Eurocontrolu związana jest ze strukturą specyfikacji ICD. Protokół przesyłania komunikatu (załącznik A) oddzielony jest od obsługi Profilu-T. Powyższe ułatwia wykorzystywanie innych Profili-T, gdy jest to niezbędne dla obsługi coraz większych wymagań FDE.

3. Te części specyfikacji ST-ICD, które dotyczą kontroli układów wirtualnych X.25 i ograniczają komunikaty aplikacji, obecnie znajdują się w protokole nagłówka komunikatu (załącznik B), który stanowi minimalną warstwę transportu dla FDE.

6. WYMAGANIA DOTYCZĄCE PROFILI

6.1. Wymagania zgodności

6.1.1. Realizacja stwierdzająca zgodność z niniejszą specyfikacją spełnia wymagania ustanowione w ppkt 6.2 i 6.3 poniżej.

6.1.2. Deklaracja zgodności jest oparta na deklaracji zgodności wykonywania profilu (PICS), jak określono w załączniku D i załączniku E.

6.2. Wymagania dotyczące wyższej warstwy

6.2.1. Wykonanie zgodne z wymaganiami spełnia wymagania dotyczące normy podstawowej, przedstawione w załączniku A.

6.2.2. Wykonanie zgodne z wymaganiami stosuje ograniczenia podane w wykazie wymagań profilu w załączniku E.7.

6.3. Wymagania dotyczące dolnej warstwy

6.3.1. Wymagania dotyczące warstwy transportu

6.3.1.1. Wykonanie zgodne z wymaganiami spełnia wymagania dotyczące normy podstawowej, przedstawione w załączniku B.

6.3.1.2. Wykonanie zgodne z wymaganiami stosuje ograniczenia podane w wykazie wymagań profilu w załączniku E.8.1.

6.3.1.3. Wykonanie zgodne z wymaganiami spełnia wymagania dotyczące obsługi jednostki danych służb transportowych (TSDU) o rozmiarze do

4097

bajtów włącznie.

UWAGA

Pierwszy bajt TSDU odpowiada polu nagłówka komunikatu (patrz ppkt A.4.10, B.4.4), pozostawiając maksymalnie 4096 bajtów na dane użytkownika.

6.3.2. Wymagania dotyczące warstwy sieciowej

6.3.2.1. Wykonanie zgodne z wymaganiami spełnia wymagania ISO/IEC 8208 [odniesienie 7] zgodnie z odwzorowaniem protokołu podanym w załączniku C.

6.3.2.2. Wykonanie zgodne z wymaganiami stosuje ograniczenia podane w wykazie wymagań profilu w załączniku E.8.2.

6.3.2.3. Wykonanie zgodne z wymaganiami zapewnia skonfigurowanie, za pomocą mechanizmów zarządzania systemem, wyboru roli DTE lub wyposażenia komunikacyjnego węzła sieci (DCE) dla operacji DTE-DTE, jeżeli obsługiwana jest operacja (DTE)-DTE urządzenia końcowego do transmisji danych.

6.3.2.4. Wykonanie zgodne z wymaganiami, w dowolnej z form określonych w ppkt 6.3.2.3, zapewnia inicjowanie połączenia zgodnie ze specyfikacją określoną w załączniku C, tzn. protokół jest całkowicie symetryczny.

UWAGA

Niektóre istniejące wykonania oparte na ST-ICD mogą nie zapewniać inicjowania połączeń sieciowych, zgodnie z protokołem w załączniku C.

6.3.2.5. Wykonanie zgodne z wymaganiami przyjmuje na pewien okres czasu ułatwienie niestandardowych domyślnych rozmiarów pakietów, o wartości 256 w obu kierunkach przesyłania.

6.3.2.6. Wykonanie zgodne z wymaganiami używa adresów NSAP, jak zdefiniowano w załączniku C.

6.3.2.7. Wykonanie zgodne z wymaganiami ustawia D bit na 0 w pakietach CALL REQUEST, CALL ACCEPTED i DATA.

UWAGA

Ustawianie D = 0 w pakietach CALL REQUEST i CALL ACCEPTED skutkuje nieużywaniem potwierdzenia odbioru.

6.3.3. Wymagania dotyczące warstwy łącza danych

6.3.3.1. Wykonanie zgodne z wymaganiami spełnia wymagania zgodności ISO/IEC 7776 [odniesienie 6] dla protokołu pojedynczego łącza zrównoważonej procedury dostępu do łącza (LAPB).

6.3.3.2. Wykonanie zgodne z wymaganiami stosuje także ograniczenia podanych w wykazie wymagań profilu w załączniku E.8.3.

6.3.4. Wymagania dotyczące warstwy fizycznej

Wykonanie zgodne z wymaganiami spełnia wymagania zgodności ISO/IEC ISP 10609-9, art. 7 [odniesienie 8].

7. METODY TESTOWE

UWAGI

1. Podejście do testowania zgodności wykonywania niniejszej specyfikacji przedstawione jest w załączniku F.

2. Użycie PRL i formularzy PICS udostępnionych wraz z niniejszą specyfikacją w celu udokumentowania zgodności przedstawione jest w załączniku E.

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