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łan