FPL2012 odchodzi do historii. Nadchodzi FF-ICE, czyli planowanie całej trajektorii lotu

Przez wiele lat podstawowym narzędziem wymiany informacji o planowanym locie pozostawał plan lotu ICAO w formacie określanym dziś jako FPL2012. Pilot, operator albo służba przygotowania lotu przekazywali w nim podstawowe dane: trasę, poziomy lotu, prędkość, typ statku powietrznego, wyposażenie oraz kilka innych informacji potrzebnych służbom ruchu lotniczego.
Problem polega na tym, że współczesny system zarządzania ruchem lotniczym potrzebuje znacznie więcej danych niż może pomieścić klasyczny formularz planu lotu.
Odpowiedzią ICAO, Unii Europejskiej i EUROCONTROL jest FF-ICE – Flight and Flow Information for a Collaborative Environment, czyli system wymiany informacji o locie i przepływie ruchu w środowisku współpracy.
Nie chodzi jednak wyłącznie o zastąpienie jednego formularza innym. Chodzi o zmianę filozofii planowania lotu.
Od deklarowanej trasy do pełnej trajektorii
Klasyczny plan lotu FPL2012 opisuje przede wszystkim zamierzoną trasę. FF-ICE ma opisywać znacznie dokładniej planowaną trajektorię statku powietrznego.
W ramach FF-ICE operator może przekazać między innymi:
- pełną trajektorię czterowymiarową, obejmującą położenie poziome, wysokość i czas,
- dane osiągowe konkretnego statku powietrznego,
- dokładne informacje o rozpoczęciu i zakończeniu wznoszenia albo zniżania,
- informacje potrzebne do analizy ograniczeń przestrzeni powietrznej,
- dane pozwalające na optymalizację lotu przez operatora i Network Managera.
W praktyce zamiast ogólnej informacji, że statek powietrzny będzie leciał określoną trasą i na określonym poziomie, system otrzymuje znacznie dokładniejszy obraz planowanego przebiegu lotu.
To właśnie ma prowadzić do wdrożenia tzw. trajectory-based operations, czyli operacji opartych na zarządzaniu trajektorią.
eFPL, czyli elektroniczny plan lotu nowej generacji
Podstawowym elementem FF-ICE jest eFPL – elektroniczny plan lotu zawierający więcej danych niż dotychczasowy FPL2012.
eFPL nie jest zwykłym elektronicznym odpowiednikiem papierowego formularza. Jest zestawem ustrukturyzowanych danych, które mogą być wymieniane między systemami operatorów, instytucji zapewniających służby ruchu lotniczego oraz Network Managera.
Wymiana ta odbywa się w środowisku SWIM – System Wide Information Management. Dane są przekazywane za pomocą usług cyfrowych, przede wszystkim poprzez systemy B2B, a nie tylko za pomocą tradycyjnych depesz AFTN lub SITA.
EUROCONTROL udostępnia między innymi usługę:
- złożenia planu lotu,
- zmiany lub anulowania planu,
- sprawdzenia planu bez jego formalnego złożenia,
- uzyskania informacji o locie,
- przekazywania informacji o starcie i lądowaniu,
- publikowania danych o planach i ich zmianach dla uprawnionych użytkowników.
GUFI – jeden lot, jeden identyfikator
Jednym z nowych elementów FF-ICE jest GUFI – Globally Unique Flight Identifier.
Jest to globalnie unikalny identyfikator przypisany do konkretnego lotu. Ma on zapobiegać pomyłkom w sytuacji, gdy kilka planów lotu zawiera podobne dane albo gdy plan jest wielokrotnie zmieniany.
GUFI pozwala powiązać wszystkie wiadomości i aktualizacje z właściwym lotem.
Można powiedzieć, że zamiast próbować identyfikować lot wyłącznie na podstawie znaku wywoławczego, lotniska odlotu, lotniska przeznaczenia oraz czasu, system otrzymuje jednoznaczny cyfrowy identyfikator.
Pierwszy operacyjny plan FF-ICE
Pierwszy plan FF-ICE dotyczący rzeczywistego lotu operacyjnego został złożony przez Lufthansę do EUROCONTROL Network Managera 15 grudnia 2022 r.
Dotyczył lotu z Monachium do Hamburga.
Nie oznaczało to jeszcze powszechnego przejścia na nowy system. Był to jednak ważny moment pokazujący, że FF-ICE przestał być wyłącznie koncepcją opisywaną w dokumentach ICAO i zaczął być stosowany operacyjnie.
FF-ICE/R1 i FF-ICE/R2
Wdrożenie FF-ICE zostało podzielone na etapy.
Pierwszy etap, FF-ICE/R1, dotyczy przede wszystkim fazy przed odlotem. Obejmuje usługi pozwalające przygotować, złożyć, zmienić, sprawdzić albo anulować plan lotu.
Drugi etap, FF-ICE/R2, ma objąć współpracę już po rozpoczęciu lotu.
Wtedy operatorzy i instytucje zarządzające ruchem lotniczym będą mogli negocjować i aktualizować trajektorię także podczas wykonywania operacji.
Docelowo system ma więc nie tylko przyjmować wcześniej przygotowany plan, lecz także wspierać ciągłą współpracę pomiędzy użytkownikiem przestrzeni powietrznej i ATM.
Plan może być zaakceptowany jako FPL i odrzucony jako eFPL
Jednym z ciekawszych skutków wdrożenia FF-ICE jest możliwość uzyskania innego wyniku walidacji dla klasycznego FPL2012 i dla eFPL dotyczącego pozornie tego samego lotu.
EUROCONTROL wyjaśnia, że klasyczny plan lotu zawiera mniej dokładne dane. W wielu przypadkach system Network Managera może więc dokonać pewnej interpretacji profilu lotu i dostosować go do istniejących ograniczeń.
W przypadku eFPL sytuacja wygląda inaczej.
Jeżeli operator dokładnie wskaże miejsce rozpoczęcia wznoszenia, miejsce jego zakończenia, profil zniżania oraz kolejne elementy trajektorii, system nie musi już niczego interpretować. Może natomiast stwierdzić, że dokładnie przedstawiona trajektoria narusza określone ograniczenia.
W rezultacie możliwa jest sytuacja, w której:
- tradycyjny FPL zostanie zaakceptowany, a eFPL odrzucony,
- eFPL zostanie zaakceptowany, a klasyczny FPL odrzucony.
Nie jest to błąd systemu. Jest to konsekwencja różnej dokładności przekazywanych danych.
FF-ICE ogranicza przestrzeń dla domysłów. Jeżeli operator dokładnie deklaruje trajektorię, system ocenia właśnie tę trajektorię, a nie jej przybliżoną interpretację.
Okres przejściowy, czyli dwa systemy jednocześnie
Przejście na FF-ICE nie nastąpi jednego dnia.
Przez dłuższy czas klasyczny FPL2012 oraz eFPL będą funkcjonować równolegle. EUROCONTROL określa ten etap jako mixed mode operations.
Oznacza to, że jedni użytkownicy i jedne instytucje będą już korzystać z FF-ICE, podczas gdy pozostali nadal będą obsługiwać tradycyjne plany lotu.
Aby system mógł działać, Network Manager wdrożył mechanizmy konwersji danych.
Plan FF-ICE może zostać przetłumaczony na format ICAO 2012 i przesłany do instytucji, która nie jest jeszcze gotowa na odbieranie eFPL. Możliwy jest również proces odwrotny, polegający na konwersji tradycyjnego planu lotu do formatu wykorzystywanego przez nowe systemy.
Przez pewien czas europejskie ATM będzie więc funkcjonowało jednocześnie w świecie depesz AFTN i w świecie cyfrowych usług SWIM.
Kogo dotyczy obowiązek wdrożenia
Wdrożenie FF-ICE/R1 wynika z rozporządzenia wykonawczego Komisji Europejskiej 2021/116 dotyczącego Common Project 1.
Termin wdrożenia określono na 31 grudnia 2025 r.
Obowiązek dotyczy przede wszystkim określonych użytkowników przestrzeni powietrznej, instytucji zapewniających służby żeglugi powietrznej oraz Network Managera.
Nie oznacza to jednak, że każdy pilot wykonujący prywatny lot samolotem General Aviation będzie musiał stworzyć własny system informatyczny i uzyskać certyfikat B2B.
Wielu operatorów będzie korzystało z usług wyspecjalizowanych dostawców planowania lotów. W takim przypadku to dostawca może odpowiadać za techniczne połączenie z systemem Network Managera.
Użytkownicy chcący łączyć się bezpośrednio z usługami EUROCONTROL będą natomiast musieli uzyskać odpowiednie certyfikaty NM B2B, najpierw dla środowiska testowego PREOPS, a następnie dla systemu operacyjnego OPS.
Co FF-ICE zmienia naprawdę
Najłatwiej przedstawić FF-ICE jako następcę planu lotu ICAO 2012. Taki opis jest jednak zbyt uproszczony.
FF-ICE nie jest tylko nową wersją formularza.
Jest elementem przejścia od systemu, w którym operator składa plan, a służby go przyjmują lub korygują, do systemu, w którym wszystkie zainteresowane podmioty wymieniają dane o planowanej trajektorii i wspólnie dążą do jej optymalizacji.
Korzyści mają obejmować:
- dokładniejszą ocenę przewidywanego obciążenia przestrzeni,
- lepsze wykorzystanie dostępnych tras i poziomów,
- wcześniejsze wykrywanie konfliktów z ograniczeniami,
- bardziej precyzyjne prognozowanie przepływu ruchu,
- łatwiejszą zmianę i aktualizację trajektorii,
- ograniczenie niejednoznaczności obecnych w klasycznych planach lotu.
System będzie jednak wymagał także znacznie lepszej jakości danych po stronie operatorów.
Im dokładniejszy plan, tym mniej miejsca na późniejsze tłumaczenie, że system powinien był domyślić się czegoś innego.
Polska gotowa na cyfrową trajektorię?
Europa przechodzi od pojedynczej depeszy planu lotu do cyfrowej wymiany danych o całej trajektorii.
Operator, Network Manager oraz instytucje zapewniające służby żeglugi powietrznej mają pracować na wspólnych, ustrukturyzowanych informacjach, które mogą być automatycznie przetwarzane przez systemy ATM.
W Polsce nadal potrafimy jednak budować zasady korzystania z przestrzeni powietrznej na obowiązku telefonicznego „uzgodnienia” lotu z jej użytkownikiem. Nie określa się przy tym jednoznacznie formy takiego uzgodnienia, procedury odmowy, sposobu dokumentowania rozmowy ani postępowania w sytuacji, gdy nikt nie odbiera telefonu.
Na jednym poziomie Europa wdraża czterowymiarowe trajektorie, globalne identyfikatory lotów i automatyczną wymianę danych pomiędzy systemami.
Na drugim polski pilot może nadal usłyszeć, że przed lotem powinien do kogoś zadzwonić i „się dogadać”.
FF-ICE pokazuje kierunek rozwoju europejskiego ATM: więcej danych, większa interoperacyjność, jasno określone procedury oraz wymiana informacji pomiędzy systemami.
Pozostaje mieć nadzieję, że przy okazji cyfryzacji planowania lotów uda się kiedyś ucywilizować również krajowe „uzgodnienia”, zgłoszenia i inne rozwiązania oparte na telefonie, dobrej woli oraz szczęściu, że osoba po drugiej stronie akurat odbierze.
Trudno mówić o trajectory-based operations, kiedy część krajowego systemu nadal działa według zasady: „proszę zadzwonić przed wlotem”.
Najciekawszy okazał się jednak ciąg dalszy.
PAŻP najpierw odmówiła udostępnienia informacji o terminach, kosztach i stanie wdrożenia FF-ICE/R1, powołując się na bezpieczeństwo, ochronę infrastruktury krytycznej oraz informacje niejawne.
Po ponownym rozpatrzeniu sprawy okazało się, że można jednak ujawnić całkiem sporo. Pierwszy etap wdrożenia został zakończony, dane FIXM są pobierane od maja 2026 r., obecnie funkcjonuje model Mixed-Mode Operations, natomiast pełna implementacja ma nastąpić wraz z nowym systemem ATM planowanym na 2032 r.
PAŻP informowała jednocześnie w AIP, że jest zdolna do przyjmowania planów FF-ICE. Odpowiednie zapisy zaczęły jednak obowiązywać 19 lutego 2026 r., już po terminie wdrożenia wynikającym z prawa Unii Europejskiej.
Nadal nie wiadomo więc jasno, które wymagane usługi działały operacyjnie 31 grudnia 2025 r., a które uruchomiono dopiero później. Samo funkcjonowanie Mixed-Mode Operations nie przesądza jeszcze o opóźnieniu, ponieważ równoległa obsługa eFPL i tradycyjnych planów lotu jest przewidzianym etapem przejściowym. Nie wyjaśnia to jednak, dlaczego dane FIXM zaczęto pobierać dopiero w maju 2026 r. ani co dokładnie PAŻP uznaje za zakończony pierwszy etap wdrożenia.
Osobnym kuriozum pozostaje podejście Agencji do jawności całego przedsięwzięcia.
PAŻP publicznie informowała o projekcie FF-ICE TRAFIC 2.0, wskazywała okres jego realizacji do 31 grudnia 2025 r., a w publikacjach AIS informowała o wdrożeniu FF-ICE R1.
Kiedy jednak padło proste pytanie o rzeczywisty stan wdrożenia, koszty, harmonogram i dokumenty odbiorowe, odpowiedź początkowo brzmiała: „nie, bo bezpieczeństwo”.
Dopiero po ponownym rozpatrzeniu część informacji przestała być tak niebezpieczna.
Pytania nie dotyczyły architektury zabezpieczeń, haseł dostępowych ani technicznych parametrów infrastruktury krytycznej. Dotyczyły tego, czy PAŻP wykonała europejski obowiązek w terminie, co faktycznie działa i co nadal czeka na wdrożenie.
Najwyraźniej sama data wykonania przepisów staje się informacją krytyczną szczególnie wtedy, gdy termin już minął, a dokumenty z „niejawnych” robią się po chwili po prostu „wewnętrzne”.
Być może samo wdrożenie FF-ICE przebiega prawidłowo i pierwsza faza działa od końca grudnia 2025 r. Problemem pozostaje jednak skandaliczna komunikacja PAŻP. Istotne informacje mają trafić do AIP dopiero w wydaniu obowiązującym od września 2026 r., choć system miał już wcześniej działać operacyjnie. Agencja opanowała przy tym wygodny sposób ogłaszania rzekomych sukcesów: najpierw nie podaje jasnych terminów, etapów ani kryteriów zakończenia projektu, a później każde częściowe uruchomienie może przedstawiać jako osiągnięcie. Pozwala na to nieskuteczny nadzór ULC, który najwyraźniej nie wymusza ani przejrzystości, ani rzetelnego rozliczania takich wdrożeń.
