Loty poza wyznaczonymi drogami lotniczymi

Cześć wszystkim.
Latam na symulatorach (głównie Prepar3D) i chciałbym zapytać o dwie rzeczy.

1. Do planowania tras używałem kiedyś SkyVectora a obecnie programu Little Navmap.
Planując trasę z Warszawy (EPWA) np. do Lanzarote (GCRR), program planuje ją na wysokości 24 000 ft, bo na tyle pozwalają drogi lotnicze którymi prowadzi. Przedstawia to załączony zrzut ekranu. Podobnie sprawa ma się gdy wyznaczam trasę do Burgas (program proponuje max 13 000 ft) czy Heraklionu (max 29 000 ft). Albo jak leciałem z Salzburga (LOWS) do Skiathos (LGSK) - max 29 000 ft. Próba zmiany proponowanego poziomu lotu na wyższy kończy się ostrzeżeniem, że ta wysokość wykracza poza drogi lotnicze. Na FR24 widzę, że samoloty latają do Lanzarote na FL390. Czasem da się ręcznie poprowadzić w programie inną trasę, uwzględniając inne drogi lotnicze (każda droga ma opisany zakres wysokości), które pasują do planowanej wysokości lotu, ale czasami tak się nie da (nie ma po trasie takich dróg).
I tu mam pytanie: co w takim przypadku w prawdziwym lotnictwie, gdy w jakimś rejonie są drogi lotnicze np. tylko do FL240, a samoloty potrzebują latać wyżej - czy to wymaga jakichś specjalnych zgód na lot poza wyznaczonymi drogami lotniczymi? I czy taki lot odbywa się równolegle do jakiejś istniejącej drogi tylko na innej wysokości czy zupełnie gdzieś "z boku"? Czy może lata się "naokoło", tak aby drogi pasowały?
https://images92.fotosik.pl/398/4f6bc3ce67d4e0c5gen.jpg

2. Drugie pytanie dotyczy dróg lotniczych w rejonach Słowacji, Węgier, Słowenii, Chorwacji, Bośni i Hercegowiny. Zarówno SkyVector jak i Little Navmap nie pokazują tam żadnych dróg. Czy takich tam nie ma? Czy może te dane nie są oficjalnie dostępne? Skąd to wynika? Jak planować loty w tych rejonach, bo program domyślnie omija te puste przestrzenie i prowadzi dookoła, tam gdzie istnieją drogi. Czy tak to wygląda również w rzeczywistości? Sytuację przedstawiają dwa zrzuty ekranu.
https://images89.fotosik.pl/398/4c9dda373cad2677gen.jpg
https://images90.fotosik.pl/397/2643ee83206d910cgen.jpg

Poczytaj na temat Free Route Airspace (FRA) i jej implementacji w poszczególnych FIRach.

To chyba istnieje stosunkowo krótko? A jak było przed wprowadzeniem FRA?

Obstawiam, że problem tkwi raczej w bazie danych, lub w ustawieniach Twojego programu do planowania. Poszukaj „wysokich” dróg lotniczych, raczej na 100% powinno się udac zaplanować ten lot po drogach lotniczych na normalnych poziomach lotu.

Wspomniana FRA istnieje bodaj jedynie nad Węgrami (o ile coś się w temacie nie zmieniło) i tam faktycznie nie ma dróg, tylko planuje się lot od punktu do punktu.

layoverlover, dzięki za Twoją odpowiedź.
Baza danych, z której korzysta program to jest AIRAC opracowywany dla symulatorów przez firmę Navigraph. Aktualizowany zgodnie z cyklem AIRAC (co 28 dni). Z dokładnie tej samej bazy korzystają samoloty w symulatorze i inne programy które tego potrzebują. Myślę, że to raczej nie jest kwestia tego. Jest to bardzo popularne rozwiązanie i gdyby były jakieś błędy, społeczność już dawno by to zgłosiła.
Wybieram drogi lotnicze typu Jet (Jet Airways) i one zdaje się są od FL180 do FL450, więc FL240 już łapie się w tym zakresie.
Dla innych tras program generuje trasy poprawnie, ale akurat na tych kierunkach które opisałem w pierwszym poście zaciekawiły mnie tak niskie proponowane wysokości. Może po prostu program wybiera trasę najkrótszą i ona akurat prowadzi po takich drogach, a pomija fakt istnienia w pobliżu dróg bardziej pasujących wysokością - zapytam autora programu.
Dużo wirtualnych pilotów korzysta z Online Flight Plannera, Route Findera lub Vroute, ale dwa pierwsze nie uwzględniają w ogóle wysokości dróg przy planowaniu, a ostatni zawiera sporo błędów, których autor nie chce poprawiać, nawet gdy je zgłaszałem... Spośród wszystkich stron i programów do planowania których używałem, tylko Little Navmap robi to bezbłędnie.
FRA wydaje się ciekawą opcją i będę to teraz stosował na trasach, na których nie ma dróg :) Tylko tak się zastanawiam, w jakim celu w ogóle były tworzone drogi lotnicze, skoro teraz i tak można latać DCT?

Drogi lotnicze były tworzone w czasach gdy nie istniał rnav i trzeba było lecieć „od vora do vora”.

Cytat:

Zamieszczone przez layoverlover

Wspomniana FRA istnieje bodaj jedynie nad Węgrami (o ile coś się w temacie nie zmieniło) i tam faktycznie nie ma dróg, tylko planuje się lot od punktu do punktu.

Już dawno znacznie szerzej.

Są dwie rzeczy - FRA oraz DCT zastępujące drogi. Z reguły LNM gubi się wszędzie tam, gdzie drogi zostały wycięte na regulacje danego kraju (tzw. faciliate traffic flow, czyli przekierowanie ruchu na inną drogę). Jeśli gdzieś czegoś brakuje - warto zajrzeć do RAD na Eurokontroli.

Ostatnio szukając podobnej trasy (Las Palmas) wyszło, że FRA trzeba stosować po kolei:
1. u nas (teoretycznie można po N869, ale nie pamiętam czy też wysokość nie jest już ograniczona)
2. w Czechach (TOMTI-ASTEL-OKG)
3. Niemcy na razie po UN869 (choć też już niby FRA, czyli da się OKG DCT RINLI)
4. Szwajcarzy po N869/UN869 się da (RINLI-N869-OLBEN-UN869-MILPA). Też FRA, powinni pozwolić RINLI DCT MILPA.
5. Francja - jeden sektor wciąż nie FRA. Bezpiecznie jest UN869 do TIVLI.
6. Hiszpania - można po staremu TIVLI-UN869-ADUKO-UN975-ELVAR albo directy.
7. Portugalia - po drogach byłoby ELVAR-UN975-BIRBA-UN873-BAROK, albo wprost na BAROK (FRA)
8. Końcówka UN873 do SAMAR.

Poza jednym sektorem Francji (LFMM - Marsylia) oraz Marokiem (GMMM) wszystko jest FRA, i można robić directy. Nie jestem tylko pewien, czy wszystkie sektory danego kraju można traktować jak jeden, czy robi się directy na sektorach. Teoretycznie chyba to pierwsze, ale pewności dla wszystkich krajów po drodze nie mam.

Pozdrawiam, Adam

Cytat:

Zamieszczone przez layoverlover

Wspomniana FRA istnieje bodaj jedynie nad Węgrami (o ile coś się w temacie nie zmieniło) i tam faktycznie nie ma dróg, tylko planuje się lot od punktu do punktu.

Dużo się zmieniło.

https://www.skybrary.aero/images/thu...x-FRA_2019.png

W części sektorów pozostały dostępne do planowania drogi lotnicze (np. Polska, Szwecja), w części je zlikwidowano (Wegry, Slowenia). SkyVector ich nie pokazuje, gdyż już nie istnieją. Do końca 2024 roku we wszystkich europejskich sektorach ma obowiązywać FRA.

Rozumiem. Ale w Polsce tych VORów jest i raczej zawsze było mało (w porównaniu np. z takim USA gdzie na VORach można dolecieć z dowolnego miejsca w inne dowolne, bez używania RNAV). Więc te drogi w Polsce raczej już powstawały na bazie punktów RNAV?
Być może chodziło o to, by zapewnić większe bezpieczeństwo i odciążyć kontrolerów w pracy, bo wówczas radary, komputery i inne urządzenia nie były jeszcze zbyt precyzyjne? I pewniej było puszczać samoloty po wyznaczonych drogach, niż ogarnąć takie latające gdzie im się podoba? :) A dziś technika jest rozwinięta na tyle, że pomimo większego ruchu, da się to ogarnąć? Dobrze kombinuję? :)

Cytat:

Zamieszczone przez arek_waw

Vroute

To akurat jest jedynie baza planów a nie generator.

Z plannerów, dobry jest PFPX: http://www.flightsimsoft.com/pfpx/

Program planuje po drogach a w niektórych FIR nie ma już dróg na wysokich poziomach. Trzeba planować po punktach.

Cytat:

Zamieszczone przez arek_waw

Baza danych, z której korzysta program to jest AIRAC opracowywany dla symulatorów przez firmę Navigraph.

Wejdź na stronki odpowiednich FIRów z którymi masz kłopoty i zobaczysz, że ich realny AIRAC jest inny niż widzisz w plannerze. Standardowy problem plannerów dla wirtuala od lat - nie do wszystkich baz danych mają dostęp w odpowiednim czasie. Rady Rzemyka są celne choć trzeba się upewnić, że symulator zna wszystkie punkty trasy (zwłaszcza gdy plannery nie nadążają za cyklami AIRAC). Dopóki nie płacisz jak linie lotnicze ogromnych pieniędzy za modyfikację danych do zmian w realu, dopóty masz, co masz.

Piotr

Dziękuję za wszystkie odpowiedzi :)

Witam,

Trochę zostały pomieszane zasady planowania lotów w tym wątku oraz pojawiło się trochę nieprawdziwych informacji (np. we Francji nigdzie nie ma FRA; możliwość używania pewnych DCT nierówna się implementacji FRA) Postaram się to trochę wyjaśnić.

Kwestia poprawnego planowania lotów w Europie to jest bardzo złożona sprawa. Jakbyśmy chcieli wszystko opisać to wyszłaby pewnie gruba książka .

Zacznijmy od historii.
Dawno, dawno temu w odległej … przestrzeni nawigacja realizowana była przeważnie w sposób konwencjonalny – tzn. latało się po prostej od pomocy do pomocy nawigacyjnej (VOR lub NDB) lub przez punkty określone, jako przecięcia radiali tych pomocy. Tak też były tworzone konwencjonalne drogi ATS. Dodatkowym problemem było to, że im dalej samolot znajdował się od pomocy nawigacyjnej tym gorsza była precyzja wyznaczenia pozycji, co powodowało, że tzw. przestrzenie chronione (szerokość drogi) rozrastały się wraz ze wzrostem odległości od pomocy. To wszystko mocno zawężało możliwości i elastyczność w projektowaniu dróg. Mapa dróg lotniczych w FIR Warszawa z lat 60’ przedstawia bardzo prostą sieć składającą się z paru pomocy i kilku dróg.

Poniżej link do mapy na stronie PAŻP z 65 roku:
https://www.pansa.pl/storage/2020/04/mapahist.jpg

Później (w latach 70’), wraz z rozwojem systemów nawigacyjnych, powstała koncepcja nawigacji trasowej (RNAV), przy użyciu, której można było już nawigować w oderwaniu od pomocy nawigacyjnej. Samolot mógł lecieć pomiędzy dowolnie określonymi punktami o ile pozostawał w zasięgu pokrycia sygnałem naziemnych referencyjnych pomocy nawigacyjnych albo pozostawał w limitach zdolności nawigacyjnych własnych systemów RNAV (INS/IRS) lub w kombinacji dwóch wyżej wymienionych warunków. Dodatkowo samolot musi być wyposażony w bazę punktów nawigacyjnych lub posiadać zdolność wprowadzenia manualnie, co najmniej 4 punktów. Wymóg 4 punktów wziął się stąd, że w momencie tworzenia specyfikacji RNAV najsłabszy samolot komunikacyjny miał takie wyposażenie (o ile dobrze pamiętam był to L-1011 TriStar).

Występuje kilka specyfikacji RNAV określonych różną wymaganą dokładnością nawigacji (dopuszczalną odchyłką od trasy nominalnej). Obecnie wszystkie te zasady zostały ujednolicone w ramach PBN (Performance Based Navigation).

Od 1998 roku, w większości przestrzeni en-route (również poza drogami) w Europie obowiązuje specyfikacja nawigacji RNAV5 – tzn. samoloty muszą mieć zdolność nawigacji +/- 5NM od linii centralnej planowanej trasy przez 95% czasu lotu. Dla RNAV5 dopuszczone są obecnie następujące sensory nawigacyjne: IRU, DME/DME, DME/DME/IRU, DME/VOR i GNSS.

Jak RNAV był tworzony to GNSS jeszcze nie istniał i żeby stworzyć drogę RNAV w danej przestrzeni, dane ANSP musiało zapewnić pokrycie nawigacyjne RNAV w tym rejonie. Takie porycie zaczęto budować w oparciu o już istniejące w tedy VORy i DME, później DVOR/DME. Obecnie DVORy trasowe są wycofywane a w ich miejsce w celu utrzymania pokrycia RNAV wdrażane są tylko DME (ponieważ jest to tańsze rozwiązanie), przez co sensor DME/DME staje się głównym sensorem trasowej nawigacji RNAV (głównym w sensie obowiązku zapewnienia pokrycia RNAV przez ANSP). Dlatego to od ponad 10 lat znikają kolejne DVORy trasowe w Polsce. Po 2030 roku głównym sensorem ma stać się GNSS.

Wracając do dróg lotniczych. Pierwsza sieć dróg lotniczych w Polsce powstała, jako sieć konwencjonalnych dróg ATS na bazie VOR i NDB. Później wraz z wdrożeniem RNAV istniejące wtedy VOR i DME stały się podstawą do zapewnienie pokrycia RNAV dla nowego typu dróg. RNAV dał możliwość bardzo elastycznego planowania nowych dróg, których przebieg nie był bezpośrednio uzależniony od posadowienia naziemnie pomocy. Zaczęły pojawiać się nowe drogi RNAV obok istniejących konwencjonalnych. Nie od razu uzyskano pełne pokrycie RNAV powyżej FL95 w polskiej przestrzeni powietrznej, dlatego przez długi czas mieliśmy mieszaną sieć dróg lotniczych RNAV + konwencjonalne. Wraz z rozszerzaniem pokrycia RNAV, z biegiem czasu przybywało dróg RNAV5 a ubywało konwencjonalnych. I tak dopiero około 2010 roku zostały wycofane ostatnie 4 konwencjonalne drogi ATS w Polsce (w rejonie Wrocławia i Katowic).

Obecnie cała sieć dróg lotniczych w Polsce jest w pełni RNAV5. Dodatkowo jedno z rozporządzeń unijnych (odnośnie PBN) zobowiązuje wszystkie kraje członkowskie, aby do końca 2020 roku wszystkie drogi w tych krajach były już tylko wyłącznie RNAV.

Odnośnie pytania, dlaczego w Polsce jest tak mało DVOR w porównaniu z USA to nie ma chyba jednoznacznej odpowiedzi na to, ale wydaje mi się, że wynika to z następujących uwarunkowań historycznych:

Porównując się z USA to możemy porównać się do jakiegoś średniego stanu. VORy czy DVORy często pełnią podwójne funkcje: lotniskowo-obszarowe. Praktycznie każdy VOR/DVOR stawiany do obsłużenie podejść do lądowania na danym lotnisku może pełnić funkcje pomocy nawigacyjnej dla fazy en-route. Pewnie w USA jest większe zagęszczenie lotnisk kontrolowanych z oprzyrządowaniem nawigacyjnym niż było/jest w Polsce. Pewnie ta różnica w latach 80’ i 90’ była jeszcze większa. Trzeba by sprawdzić ile w USA jest VORów czysto trasowych.
Jak tworzyła się koncepcja RNAV to ruch w Polsce był znacznie mniejszy niż w USA, więc nie potrzebowaliśmy tyle dróg i pomocy.
Kolejnym istotnym faktem było to, że praktycznie do czasu wejścia Polski do Unii był u nas sztywny podział na przestrzeń wojskową (większość) i cywilną. To wojsko zarządzało przestrzenią powietrzną. Nawet jak wojsko nie latało to cywile w tej przestrzeni się nie pojawiali. W wojskowej przestrzeni cywile nie tworzyli dróg lotniczych i nie stawiali tam pomocy. Wszystko się zmieniło na początku lat 2000, jak cywile przejęli zarządzanie przestrzenią w czasie pokoju i została wdrożona koncepcja elastycznego zarządzania przestrzenią FUA (Flexible Use of Airspace). Został zlikwidowany stały podział na przestrzeń wojskową i cywilną. Od tej pory cywilna siec dróg lotniczych mogła zacząć się rozrastać i zaczęła. Ale wtedy już plany rozwoju infrastruktury nawigacyjnej w Europie zakładały, że w niedalekiej przyszłości, wraz z rozwojem systemów nawigacyjnych, obszarowy RNAV w Europie będzie bazował na DME/DME, bo będzie taniej. Więc już nie opłacało się inwestować w drogie DVOR dla przestrzeni obszarowej, bo przyszłościowy RNAV dało się zrobić na tańszych DME/DME.

Ogólna zasada planowania trasy lotu była taka, że w sieci dróg lotniczych trasa lotu może być wytyczona wzdłuż danej drogi lotniczej a przejście z jednej drogi na drugą może odbyć się tylko w punkcie nawigacyjnym, który znajduje się na przecięciu tych dróg i jest opublikowany równocześnie w obu drogach. Jeżeli punkt fizycznie znajduje się na przecięciu dwóch dróg a jest opublikowany tylko w jednej to nie można planować zmiany drogi w tym punkcie. Ale wraz z rozwojem systemów i RNAV zaczęto umożliwiać "przeskoczenie" z jednej drogi na drugą w pomiędzy punktami, które nie leżały na przecięciu tych dróg. I tu pojawiają się nam te słynne DCT (direct). Możliwość planowania DCT pojawiła się dużo wcześniej niż wymyślono/wdrożono FRA (Free Route Airspace). Jeżeli ktoś utożsamia możliwość zaplanowania odcinka trasy, jako DCT z implementacją FRA to robi poważny błąd, (pomimo że w skrajnych przypadkach rezultat może być taki sam).

Jak już wspomniałem, po wdrożeniu RANV a przed FRA, w pewnym momencie (dokładnie, kiedy to nie pamiętam, bo w tamtym czasie to nie interesowałem się jeszcze lotnictwem ) uznano, że skoro w całej przestrzeni en-route wymaga się posiadania zdolności nawigacyjnej RNAV5 to można pozwolić na używanie w planie lotu odcinków DCT poza drogami. Zasady używania takich DCT w różnych FIR’ach w Europie wyglądają różnie. Są miejsca, gdzie użycie takiego DCT nie jest limitowane i można używać prawie wszędzie dowolnych odcinków DCT – np.: w Szwecji (w takim przypadku rezultat końcowy dla użytkownika jest zbliżony do FRA), ale w większości FIR’ów użycie DCT było/jest limitowane – np.: max 50NM. W niektórych FIR’ach można użyć dowolnego DCT o ile nie przekracza się jakiegoś limitu długości albo ogólnie limit ustawiony jest na 0NM a można używać wyłącznie DCT z predefiniowanej listy. Limity mogą być rożne w zależności od wysokości dla tego samego FIR. Te wszystkie przypadki opisane wyżej to nadal nie jest FRA. Te zasady mogą (ale nie muszą) być opisane w AIP poszczególnych krajów ale jest jedno miejsce gdzie można znaleźć te zasady. I tu dochodzimy do RAD’u, który powstał na długo przed FRA.

Plany lotu IFR składane na lot w europejskiej przestrzeni powietrznej, w tym FIR Warszawa muszą spełniać krajowe wymogi określone w dokumencie RAD (Route Availability Document). RAD to wspólny europejski dokument referencyjny zawierający przepisy zasady, procedury, opis dostępnych tras oraz ograniczeń w ich wykorzystaniu przez zdefiniowane potoki ruchu lotniczego w europejskiej przestrzeni powietrznej, w tym w FIR WARSZAWA. Obejmuje także zasady użytkowania i dostępność zarówno sieci dróg lotniczych jak i przestrzeni FRA, w tym POLFRA. RAD jest również narzędziem do zarządzania przepływem i przepustowością ruchu lotniczego (ATFCM), zaprojektowanym, jako scalony dokument przeznaczony do planowania lotu, o jednym wspólny źródle, który integruje zarówno wymagania strukturalne, jak i wymagania ATFCM, w zakresie geograficznym i pionowym. Dokument ten jest dostępny na stronie internetowej EUROCONTROL pod następującym linkiem:

https://www.nm.eurocontrol.int/RAD/index.html

Obecnie RAD zawiera kilka tysięcy restrykcji/zasad obowiązujących w Europie. Wszystkie te restrykcje zaimplementowane są w systemach NM (Network Manager) – funkcja obecnie zapewniana przez EUROCONTROL (dawniej CFMU). Każdy plan lotu walidowany przez IFPS jest sprawdzany pod kątem zgodności ze wszystkimi restrykcjami. Generalnie niespełnienie, chociaż jednej restrykcji (typu "hard check") powoduje odrzucenie planu lotu. Bez uwzględnienia RADu nie da się zaplanować prawie żadnego lotu komunikacyjnego IFR. Ograniczenia RAD nie dotyczą ruchu OAT (lot lub fragment lotu wykonywany, jako OAT nie jest walidowany przez NM/IFPS – oczywiście samoloty pasażerskie nie latają, jako OAT). Tak duża liczba restrykcji + różne dostępne opcje planowania (siec dróg lotniczych, DCT poza drogami, FRA) sprawia, że bardzo ciężko jest zaplanować długi lot w przestrzeni Europejskiej bez dedykowanego narzędzia. Można próbować, ale często jest to metoda prób i błędów. Tak jak ktoś już wspomniał, linie lotnicze korzystają z profesjonalnych narzędzi do planowania lotów (np.: LIDO od LHSystem, Sabre, Jeppesen), które uwzględniają to wszystko, o czym pisałem a mimo to zdarza się, że plan lotu wygenerowany przez taki system jest odrzucany przez IFPS. Narzędzia te są niezbędna dla linii lotniczych, bo działy dispatch nie poradziłyby sobie z planowaniem dużej liczby operacji manualnie, ale to kosztuje bardzo dużo. RAD definiuję mnóstwo rzeczy, których często nie znajdziemy nigdzie indziej – np.: jaki powinien być użyty punkt w planie lotu jako pierwszy/ostatni w locie na dane lotnisko.

Dokument RAD składa się z kilku załączników a jego struktura wygląda następująco:

Appendix 2: Area definitions – definiuję grupy lotnisk w celu łatwiejszego zapisu restrykcji w kolejnych częściach,
Appendix 3: City-pair Level Capping – definiuję maksymalny poziom lotu dla zdefiniowanych par lotnisk (DEP-ARR) lub potoków ruchu lotniczego np: DEP EP**- ARR ED**; Przykład rzeczywistej restrykcji EP4010: DEP EP** with ARR EP** Not above FL285 w okresie JUN..SEP 04:00..20:00 – restrykcja ta ogranicza maksymalny poziom lotu dla lotów krajowych w Polsce w ciągu dnia latem maksymalnie do poziomu FL280,
Appendix 4: Enroute DCTs / General Limits – definiuję zasady użycia dozwolonych DCT poza drogami lotniczymi, które nie są częścią FRA (General Limits), oraz listę predefiniowanych DCT, które są dozwolone lub zabronione do użycia w przypadku, gdy ogólne zasady „zerują” długość domyślnego dopuszczonego DCT lub DCT jest dłuższy od wprowadzonego ogólnego limitu (to jest w części Enroute DCTs).
Appendix 5: Airport Connectivity - definiuje jak powinien wyglądać pierwszy/ostatni punkt w planie lotu z/do danego lotniska,
Appendix 7: FUA Restrictions – definiuję zasady akceptacji/odrzucania planów lotu, które są kolizyjne z aktywnymi wydzielonymi strefami (TSA, TRA) oraz strefami D, P, R. Dla każdej strefy indywidualnie.
Annex - Pan Europe – główny aneks zawierający ograniczenia w dostępność połączeń dla zdefiniowanych potoków ruchu lotniczego – np.:

Punkt POLON jest niedostępny dla startów z EPLB za wyjątkiem dolotów do EPLL (część restrykcji EP2156),
Punkt POZUM jest dostępny tylko dla dolotów do EPMO/EPWA przez POZUM DCT ADVAB tylko powyżej FL315 w punkcie POZUM (część niemiecko-polskiej restrykcji EDEP1000),
Punkt LASIS jest obowiązkowy dla startów z EPKK/EPKT, które lecą do EH**, EB**, EG** i które planowane są dalej przez DLE powyżej FL285 za wyjątkiem tych lotów, które są planowane przez punkt NAROX (restrykcja EP2024).

Restrykcje w RAD mogą być oparte o punkty nawigacyjne, segmenty dróg, sektory kontroli ruchu lotniczego. W definicji potoku ruchu lotniczego można używać np.: punktów, segmentów dróg, sektorów kontroli, typu samolotów (np.: jet), konkretnych modeli (np.: B739), poziomów lotu, konkretnych przestrzeni tak jak są one zdefiniowane w bazie CACD w NM/IFPS (np.:LKAA), lotniska startu, lądowania. Zachęcam do przejrzenia dokumentu i zapoznania się ze skalą problemu w planowaniu lotów w Europie .

Jak znamy już RAD to możemy przejeść w końcu do FRA.

Po 2000 roku, jak już był miks konwencjonalnych i RNAV’oskich dróg lotniczych oraz pewne DCT poza drogami lotniczymi zaczęto myśleć nad koncepcją planowania lotów, która jeszcze w większym stopniu byłaby elastyczniejsza i udostępniła użytkownikom krótsze trasy lotu, w celu redukcji kosztów i zmniejszenia negatywnego wpływu na środowisko (redukcji spalania, co nie udało się do końca, bo linie często patrzą na końcowy koszt a nie tylko na spalanie i wolą lecieć dłużej jeżeli trasa jest tańsza). I tak powstały dwie koncepcje:

FRA like, później zwana DRA (Direct Route Airspace) – jako etap przejściowy,
Full FRA, później zwana FRA.

FRA like/DRA zakładała udostępnienie dodatkowo jak największej liczby predefiniowanych połączeń DCT pomiędzy drogami lotniczymi w FIRach gdzie domyślna długość DCT była wyzerowana lub ograniczona. Czyli praktycznie, poza liczbą dostępnych DCT zasady planowania się nie zmieniały. Niektóre kraje, trochę „ściemniały” wykorzystując koncepcję DRA. Np.: Słowacy w pewnym momencie skasowali wszystkie swoje górne drogi i w to miejsce opublikowali dokładnie takie same połączenia tylko jako DCT zdefiniowane w RAD appendix 4. To był trochę taki chwyt marketingowy, że niby mają pełne DRA a w praktyce dla użytkowników nic się nie zmieniło, bo nie dostali żadnych nowych połączeń tylko zmienił się ich opis – zamiast sieci dróg lotniczych w AIP była sieć DCT w RAD appendix 4. To samo zaczęli robić teraz Czesi (zostawili tylko parę górnych dróg a resztę połączeń drogowych przenieśli do RADu), u których „normalne” FRA będzie opublikowane dopiero w przyszłym roku.

Natomiast koncepcja pełnego FRA zakłada inny sposób opisu dostępnych połączeń i trochę inny sposób walidacji planów lotu w NM/IFPS.

Obecnie możemy mówić o dostępności FRA w jakimś FIR pod warunkiem, że:

Został zdefiniowany w AIP wolumen przestrzeni FRA określony geograficznie i w danym przedziale wysokości (obecnie odpowiednie regulacji unijne nakazują implementacje FRA minimum powyżej FL305),
Wlot przestrzeń FRA możliwy jest tylko przez punkty umiejscowione na granicy FRA i opisane, jako „Entry”
Wylot jest możliwy tylko prze punkty „Exit”
Wewnątrz przestrzeni FRA dostępne są punkty Intermediate, które w ogólności mogą ale nie muszą być używane prze użytkownika. Punkty intermediate w większości są opcjonalne ale nie zawsze. Czasami w RADzie są zdefiniowane dodatkowe restrykcje nakazujące użycie dodatkowych punktów Intermediate dla zdefiniowanych potoków ruchu lotniczego. W POLFRA, czyli polskim FRA zostało zdefiniowanych ponad 100 dodatkowych restrykcji w dokumencie RAD.
Odcinek DCT planowany w danym FRA musi całkowicie znajdować się wewnątrz wolumenu przestrzeni FRA. Jeżeli chcielibyśmy umożliwić planowanie odcinka DCT, który znajduje się częściowo w wolumenie przestrzeni FRA (punkt początkowy lub końcowy leży poza wolumenem FRA) to taki DCT musi zostać zdefiniowany w RAD appendix 4 jako dopuszczony.
Jeżeli dla danego potoku ruchu lotniczego nie ma dodatkowych restrykcji to jest możliwy lot po prostej od Entry do Exit – np.: LUGOL DCT LUSID w FIR EPWWW.

W praktyce FRA różni się od DRA i dróg lotniczych (w przypadku z przestrzeni z ograniczonym DCT) tym, że użytkownik ma dostępnych dużo więcej kombinacji połączeń. Nie są one z góry predefiniowane a zamiast tego definiujemy tylko, które punkty można używać do „skonstruowania” sobie optymalnego połączenia – np.: we włoskim FRA wprowadzonym parę lat temu wszystkich kombinacji DCT było ponad 70 000. Pewnie nie wszystkie miały sens z punktu widzenia użytkownika ale przytaczam tę liczbę, żeby pokazać skalę problemu i dlaczego stosuje się właśnie ten typ publikacji i opisu.

Jednak w praktyce żadne FRA w Europie nie jest w pełni „free”. Praktycznie w każdym FRA mamy wprowadzone pewnie ograniczenia w RAD, żeby uniknąć pewnych połączeń, które mogą stanowić kwestię bezpieczeństwa zapewniania kontroli ruchu lotniczego oraz żeby nie zaszkodzić pojemności i przepustowości przestrzeni. Ograniczone FRA jest pewnym kompromisem pomiędzy efektywnością kosztową dla pojedynczego lotu a ogólną przepustowości przestrzeni, szczególnie w okresach letnich.

Dodatkowo we FRA, często dla dużych lotnisk stosuje się predefiniowane arrival/departure/feeding routes, które nakazują planowanie dolotu/odlotu do/z danego lotniska fragmentem drogi lub przez z góry narzuconą sekwencje punktów w fazie zniżania i wznoszenia.

Obecnie w Europie stosuje się dwa modele FRA (tylko takie modele dopuszczają systemy NM/IFPS):

Full FRA,
FRA with Intemediate points.

Model Full FRA dopuszcza użycie w planie lotu jako „Intermediate point” dowolnego punktu, który został gdziekolwiek opublikowany w AIP. W takim modelu np.: punkt WA533 (z procedury STAR dla EPWA) mógłby być użyty dla lotu tranzytowego z Moskwy do Madrytu. W tym modelu dopuszczone są również punkty definiowane przez użytkownika i opisane współrzędnymi geograficznymi.

Model FRA with Intemediate points dopuszcza użycie jedynie punktów, które w AIP są zdefiniowane, jako udostępnione we FRA (patrz AIP ENR. 4). Ten model daje większe panowanie nad FRA. Trzeba pamiętać, że konsekwencją tego modelu jest to, że nie wszystkie punkty z sieci dróg lotniczych w danym kraju mogą być dostępne we FRA. W POLFRA wykorzystywane jest właśnie ten model i nie wszystkie punkty z naszej sieci dróg lotniczych są dopuszczone we FRA.

Kolejna kwestią jest współistnienie sieci dróg lotniczych z FRA lub DRA.

Każdy kraj decyduje sam czy zostawia sieć dróg lotniczych po wdrożeniu FRA czy nie. W Polsce po wdrożeniu FRA w lutym 2019 roku sieć dróg pozostała w całości i obecnie użytkownicy mogą sobie wybrać, która opcje preferują. Dopuszcza się złożenie planu lotu w całości według zasad POLFRA lub „po staremu”, po drogach lotniczych. Można też robić mieszankę i zaplanować część lotu w drogach a część we FRA. Podobnie jest w Szwecji i Niemczech.

Inne kraje natomiast zdecydowały się na skasowanie dróg od pierwszego dnia działania FRA – np.: Węgry.

Jak widać mamy w Europie różne kombinacje dostępnych opcji do planowania, często zdublowane.

Należy jednak pamiętać, że jak zobaczymy białą plamę bez dróg na skyvector to w cale nie oznacza, że tam jest FRA (mogą tam być tylko predefiniowane DCT w RAD appendix 4). Z drugie strony jak na skyvector widzimy gęstą siec dróg lotniczych to też nie oznacza, że nie ma tam FRA. Jednoznaczną odpowiedź uzyskamy tylko przeglądając AIP i RAD.

Podsumowując, obecnie w Europie mamy 3 opcje do planowani lotu:

Sieć dróg lotniczych,
Predefiniowane DCT w RAD appendix 4,
FRA

FRA w Europie jest implementowane stopniowo od 2009 roku. Pierwszymi krajami była Portugalia i Irlandia. Ostatni pewnie będą Francuzi, bo boją się FRA jak diabeł święconej wody . Mapa z ECTL przytoczona parę postów wyżej jest poprawna i widać na niej, że już większość krajów ma wdrożone FRA. Niektóre są już o krok dalej, po wdrożeniu cross-border FRA, który jest kolejnym krokiem w rozwoju europejskiej przestrzeni. Polega on na łączeniu poszczególnych sąsiadujących ze sobą FRA w większe jednolite przestrzenie FRA, w których nie ma konieczności planowania punktów na granicach poszczególnych FIR wchodzących w skład tej przestrzeni – np.: inicjatywa BOREALIS, SEEN FRA.

Teraz jeszcze kilka słów w zakresie FUA i planów lotu w rejonach kolizyjnych ze wydzielonymi strefami.

Konsekwencją wprowadzenia wspomnianej koncepcji FUA było powstanie dróg warunkowych (tzw. CDR). Drogi te były z reguły publikowane w rejonach, w których istniały też strefy wydzielone (TSA) lub rezerwowane strefy (TRA) - wojskowe lub cywilne. Dotyczy to też stref D, P, R. Z reguły drogi takie są dostępne tylko, gdy kolizyjna z nimi strefa jest nieaktywna. Informacja o dostępności lub niedostępności danej drogi w danym momencie jest zawarta w AUP, który jest cyklicznie (raz na dobę) wydawany prze AMC danego kraju. AUP może być aktualizowany w ciągu dnia w postaci UUP. W FUA istnieje 3 rodzaje dróg CDR:

CDR1 – domyślnie otwarte, chyba, że zostaną zamknięte w danym przedziale czasowym w AUP,
CDR2 – domyślnie zamknięte, chyba, że zostaną otwarte w AUP,
CDR3 – drogi nigdy nie dostępne do planowania, możliwe tylko do taktycznego użycia przez kontrolera ruchu lotniczego.

Od pewnego czasu w FIR Warszawa występują już jedynie drogi warunkowe typu CDR1.

Jak wspomniałem już wyżej, wdrożenie FRA wiązało się ze zmianą sposobu walidacji planów lotu przez IFPS. W czasach przed FRA, kiedy plany były złożone w drogach lotniczych i za pomocą predefiniowanych DCT walidacja polegała głównie na sprawdzeniu dwóch kwestii:

czy w planie lotu nie występuje jakiś segment zamkniętej drogi (stałej lub CDR1), nieotwartej drogi CDR2 lub niedostępnego DCT.
czy plan lotu spełnia warunki opisane prze restrykcje RAD.

Wdrożenia koncepcji FRA wymagało opracowania nowego sposobu walidacji planów lotu, które nie wykorzystują zdefiniowanej sieci dróg ani predefiniowanych DCT w RAD appendix 4 a są zaplanowane przy wykorzystaniu dowolnie wyznaczonych DCT we FRA. Tu pojawiają się nam FBZ’ty (Flight Buffer Zones). Z reguły, w przypadku większości aktywny stref, Kontroler ruchu lotniczego zobowiązany jest do utrzymania jakiegoś określonego minimalnego dystansu pomiędzy samolotem a granicą danej strefy. W przypadku dróg lotniczych taka odległość była uzyskana poprzez definicję drogi. W przypadku RNAV5 szerokość drogi wynosi 10NM (+/-5Nm od linii centralnej). Problem powstaje dla DCT, które nie mają parametru szerokości w definicji. Dla predefiniowanych DCT to nie jest problem, bo zadaną odległość otrzymuje się w fazie projektu poprze odpowiednie dobranie punktów początku i końca. Dla DCT we FRA staje się to problematyczne ze względu na ilość kombinacji (>kilkudziesięciu tysięcy) i na to, że nie są predefiniowane. Dlatego potrzebujemy dodatkowych buforów, żeby „odsunąć” nominalną trasę od aktywnych stref.

Dla każdego segmentu wspomnianych wyżej stref (jeżeli nie chcemy dopuścić możliwości planowania trasy zbyt blisko strefy musi zostać wyznaczony dodatkowy bufor, który zostanie wykorzystany tylko i wyłącznie do sprawdzenia planu lotu w IFPS. Z reguły bufory te są większe niż strefy żeby zapewnić dodatkowy bufor jednak koncepcja FBZ jest bardzo elastyczna i zapewnia możliwość stworzenia FBZ o wymiarach mniejszych niż strefa lub nawet w zupełnie innym miejscu niż rzeczywista strefa powiązana z tym buforem. FBZ mniejsze niż strefa możemy użyć w przypadku, gdy chcemy pozwolić na planowanie lotu po obrzeżach strefy ale nie chcemy planów przez środek. Ale to nie jest jeszcze koniec. Sam FBZ jeszcze nie wystarczy, żeby odrzucić plan lotu. Konieczne jest zdefiniowanie tzw. „FUA restriction” do każdego FBZ i/lub oryginalnej strefy. Restrykcje FUA są publikowane w RAD appendix 7 i opisują zasady akceptacji planów lotu w danym FBZ lub oryginalnej strefy. Możemy definiować potoki ruchu lotniczego, które mogą być zaakceptowane, a które nie. W znacznej większości przypadków FBZty mają przypisane proste reguły mówiące, że jak strefa aktywna to żaden plan lotu przez tę strefę nie może zostać zaakceptowany. Ale koncepcja dopuszcza pełną dowolność w definicji wyjątków dla wybranych potoków. Np.: możemy zdefiniować regułę, która mówi, że jak strefa EPTSA02A jest aktywna to nie akceptujemy planów lotu przez tę strefą za wyjątkiem startów z EPWA samolotem B788 powyżej FL285, które dalej są zaplanowane przez przestrzeń FIR Mińsk i wylatują z FIR EPWW przez punkt GORAT w okresie od lipca do września, w godzinach 12:00 do 15:45.

FBZ przypisany do danej strefy ma taką samą nazwę jak strefa z dodaną literą „Z” na końcu. FUA restrykcja przypisana do danego FBZ ma taką nazwę jak FBZ z dodaną literą „R” Np.:

strefa: EPTSA02A
FBZ: EPTSA02AZ
FUA restrykcja: EPTSA02AZR

Zdefiniowanie FBZ w AIP i FUA restrykcji w RAD nie oznacza jeszcze, że plany lotu będą poprawnie walidowane. Żeby to wszytko zadziałało to zarówno FBZ jak i FUA restrykcja musi zostać każdorazowo aktywowane przez AMC w AUP. Dopiero na bazie tego IFPS będzie stosował opisane zasady przy walidacji, która działa mniej więcej tak. Dla każdego planu IFPS buduje trajektorię 4D i sprawdza, czy jest kolizyjna z aktywowaną strefą lub FBZ’tem. Jak wykryje kolizję to sprawdza czy dla danego FBZ lub strefy są zdefiniowane odpowiednie FUA restrykcje i czy są aktywowane przez AMC. Jeżeli są to sprawdza czy dany potok ruchu lotniczego jest do zaakceptowania czy odrzucenia.

Powyższy opis jest tylko opisem podstawowych przypadków. Koncepcja FBZ i FUA restrykcji jest bardzo elastyczna i dużo bardziej skomplikowana. Jeżeli chodzi o FBZty to może być zdefiniowanych wiele FBZ do jednej strefy a pojedynczy FBZ może składać się z wielu „partów” o różnych granicach geograficznych i pionowych. Podobnie dla FUA restrykcji, może być jedna lub wiele zdefiniowanych do FBZtu/strefy. W tych przypadkach kodowanie nazw trochę się komplikuje i dochodzą nowe dodatkowe literki i cyfry w nazwach. Nie wszystkie FBZty i FUA restrykcje muszą być aktywne każdego dnia. Skyvector pokazuje FBZty na swoich mapach. Dobrze tam widać jak większość stref jest obudowana dodatkowymi buforami. Moim zdaniem skyvector niepotrzebnie je pokazuje, bo to zaciemnia obraz. Zrobili to pewnie, bo nie wiedzieli, czym tak naprawdę są FBZty, pewnie byli przekonani, że to też rzeczywiste strefy, w których może dziać się jakaś działalność lotnicza. FBZty są tworem Europejskim, który nie jest dobrze rozumiany prze pilotów/dispatcherów z innych kontynentów.

Teraz kilka słów o zasadach w FIR Warszawa.

POLFRA i sieć dróg RNAV

W FIR EPWW przestrzeń FRA (POLFRA) została zaimplementowana w lutym 2019 roku prawie w pełnym zakresie geograficznym (z wyłączeniem dwóch małych fragmentów delegacji ATS z EPWW do LKAA (OKX oraz Kłodzko)). W zakresie pionowym POLFRA obowiązuje od FL95 do FL660 z wyłączeniem przestrzeni TMA.
Oprócz FRA została pozostawiona cała sieć dróg lotniczych, które może być używana zamiennie z POLFRA.
Żeby zaplanować lot tranzytowy przez TMA należy użyć sieci dróg RNAV.
Nie ma ograniczenia długości DCT w POLFRA (pomiędzy punktami dopuszczonymi do POLFRA)
Dla pewnych lotnisk zostały zdefiniowane obowiązkowe feeding routes.
Dodatkowo w POLFRA zostało zdefiniowanych ponad 100 restrykcji RAD.

Pierwszy/ostatni punkt w planie lotu:

Dla lotnisk, dla których istnieją procedury SID/STAR dla danego lotniska, plan lotu z/do tego lotniska może zaczynać się lub kończyć w ostaniem punkcie SID/pierwszym punkcie STAR,
Dla kontrolowanych lotnisk, które nie posiadają procedur SID/STAR lub posiadają je tylko dla części bram wlotowych/wylotowych zostały zdefiniowane w RAD appendix 5 tzw. „connecting points” for arrival/departure. W takim wypadku plan lotu powinien kończyć się lub zaczynać w jednym ze zdefiniowanych punktów,
Dla pozostałych lotnisk (niekontrolowanych i wojskowych) może to być dowolny punkt w promieniu 50NM od ARP lotniska.
UWAGA. Dla niektórych lotnisk kontrolowanych obowiązuję model mieszany – tzn. pomimo istnienia procedur SID i STAR ze wszystkich bram wlotowych dodatkowo istnieją opublikowane connectng points w RAD appendix 5. Taki przypadek mamy np.: dla EPWA i EPMO. Prawidłowy plan lotu pomiędzy EPWA i EPMO to „WAR”. Punkt WAR jest dodany, jako connecting point dla tych dwóch lotnisk. Podobny przypadek jest w TMA Kraków dla lotów pomiędzy EPKK i EPKT z tą różnicą, że są to dwa różne punkty w zależności od tego czy lecimy z EPKK do EPKT czy na odwrót. Mamy też taki przypadek dla EPLL, i ruchu przez Ukrainę.

Ogólne zasady planowania lotów w FIR EPWW:
„General DCT limits” zdefiniowane w RAD appendix 4:

Powyżej FL95 ogólny limit DCT=0. Dopuszczone do używania są jedynie DCT, które da się zdefiniować w POLFRA (tu bez ograniczenia długości) oraz predefiniowana lista dozwolonych DCT z RAD appendix 4.
Poniżej FL95 zasada jest odwrotna: Można używać dowolnie długich DCT za wyjątkiem tych, które są zdefiniowane w RAD appendix 4 jako niedostępne.

Dokładne informacje odnośnie POLFRA można znaleźć na stronie PAŻP:
https://www.pansa.pl/polfra/

Dodatkowo na tej stronie jest dostępnych wile map pokazujących dozwolone połączenia/ograniczenia/ obowiązkowe i rekomendowane trasy dolotowe/odlotowe w POLFRA:
https://www.pansa.pl/polfra/maps/

Na koniec kilka uwag do informacji z poprzednich postów:

Ostatnio szukając podobnej trasy (Las Palmas) wyszło, że FRA trzeba stosować po kolei:
1. u nas (teoretycznie można po N869, ale nie pamiętam czy też wysokość nie jest już ograniczona) - obie opcje dostępne POLFRA + drogi
2. w Czechach (TOMTI-ASTEL-OKG) - nie ma FRA w Czechach (będzie dopiero w przyszłym roku) część dróg przenieśli do RAD appendix 4 jako lista dostępnych DCT
3. Niemcy na razie po UN869 (choć też już niby FRA, czyli da się OKG DCT RINLI) – w górnej przestrzeni (UAC Karlsruhe) obie opcje dostępne FRA (limitowane do grup sektorów ACC) + drogi, W dolnych FIRach w Niemczech brak FRA.
4. Szwajcarzy po N869/UN869 się da (RINLI-N869-OLBEN-UN869-MILPA). Też FRA, powinni pozwolić RINLI DCT MILPA. – W Szwajcarii nie ma jeszcze FRA; tylko drogi i DCT z RAD appendix 4.
5. Francja - jeden sektor wciąż nie FRA. Bezpiecznie jest UN869 do TIVLI. – We Francji też nie ma FRA i jak wspominałem wyżej, pewnie będą ostatni w Europie; tylko drogi i DCT z RAD appendix 4.
6. Hiszpania - można po staremu TIVLI-UN869-ADUKO-UN975-ELVAR albo directy.- Nie ma FRA, tylko drogi i DCT z RAD appendix 4.
7. Portugalia - po drogach byłoby ELVAR-UN975-BIRBA-UN873-BAROK, albo wprost na BAROK (FRA) Jeden z pierwszych krajów, który wprowadził FRA już chyba 10 lat temu.

Odnośnie prostych planerów dostępnych dla „zwykłego zjadacza chleba” to mogę jedynie potwierdzić, to co zostało już powiedziane. To są tanie proste systemy, które pewnie nigdy nie będą w stanie poradzić sobie z wyznaczeniem optymalnej trasy. Szczególnie, jeżeli chcielibyśmy wziąć pod uwagę FRA i RAD. W takie zwykłej bazie z Navigraph to zapewne jest tylko definicja sieci dróg lotniczych. Pewnie nie ma tam też informacji o FRA a o RAD to możemy zapomnieć. Systemy, które to wszystko uwzględniają są nieporównywalnie droższe a nawet i one mają problem żeby optymalnie wyznaczyć trasę w FRA. Plany lotu z tych darmowych planerów często mogą być inne od rzeczywistych planów lotu dla tego samego połączenia, ponieważ systemy te najczęściej wyszukują najkrótszą trasę pomiędzy lotniskiem startu a lotniskiem lądowania (szukają trasy zbliżonej do ortodromy) natomiast linie lotnicze najczęściej optymalizują trasy pod względem całkowitego kosztu lotu (tzw. costodroma) a nie długości trasy. Profesjonalne systemy biorą pod uwagę prognozę pogody (wiatry) oraz wysokość opłat nawigacyjnych w poszczególnych krajach po drodze. Często opłaca polecieć parę minut dłużej przez tańszy kraj żeby w końcowym rozrachunku zaoszczędzić .

Zgadzam się z tym, co ktoś już wspomniał, że te proste systemy zapewne szukają tylko najkrótszej trasy horyzontalnie w sieci dróg i nie patrzą podczas optymalizacji na wysokość dostępną w poszczególnych segmentach. Predefiniowanych DCT z RAD pewnie też tam nie ma a o dobrej implementacji FRA też możemy zapomnieć. O ile dobrze pamiętam Navigraph zaczynał (i co nadal kontynuuje) od tworzenia baz danych do wirtualnych FMC/FMSów do zaawansowanych modeli samolotów w MSFS a później Prepar3d. Bazy te zawierają to, co bazy FMC w prawdziwych samolotach:

Definicje pomocy nawigacyjnych,
Punktów nawigacyjnych,
Dróg lotniczych,
Procedur SID/STAR,
Instrumentalnych Procedur podejścia do lądowania (ILS, VOR, NDB. RNAV)

Architektura tych baz jest na tyle stara, że nie ma w niech miejsca na definicje konkretnych dostępnych DCT czy poprawnej definicji FRA. Zakładam, że Navigraph daję wszystkim te same bazy danych a nie tworzy dla obsługiwanych planerów oddzielnych bardzie zaawansowanych baz, które zawierają informacje o definicji DCT z RAD czy FRA.

Zasze można spróbować ułożyć sobie samemu trasę na podstawie skyvector + RAD + AIP poszczególnych krajów.
Poprawność takiej trasy zawsze można zwalidować na portalu NOP EUROCONTRL:
https://www.public.nm.eurocontrol.in...pec/index.html

W prawej kolumnie, u dołu jest zakładka „Flight Planning”, gdzie można otworzyć sobie okienko edytora planu lotu IFPUV i sprawdzić czy taki plan przeszedłby prze IFPS w rzeczywistości.

To byłoby na tyle jeżeli chodzi o moją próbę rozjaśnienia sytuacji w planowaniu lotów w Europie.
Mam nadzieję, że te informacje komuś się przydadzą :).

Pozdrawiam wszsytkich, którzy dotrwali do końca :).

pozdrawiam,
Grzegorz

Mygod... Nie dotrwałem do końca bo to zbyt wiele jak na jeden wieczór przy jednym piffku ale jutro wrócę do Twojego posta żeby go przeczytać ze zrozumieniem... Tak ze dwa razy. Szacun. Dla mnie jako krl, Twój wpis jest mega wartościowy bo na szkoleniu nie omawiają tego tak szczegółowo... PS: pracujesz w "firmie"? Jeśli tak - priv pls.

Przeczytałem z zaciekawieniem - wielkie dzięki!

świetny mail.

Ja dodam tylko, że oparłem się na mapie z NMa Eurokontroli, przeoczywszy, że to "target", czyli sektory FRA na koniec implementacji - 2022.
https://www.eurocontrol.int/sites/de...?itok=4s4dwDDd

Pozdrawiam,
Adam

Cytat:

Zamieszczone przez foxmulder

O ile dobrze pamiętam Navigraph zaczynał (i co nadal kontynuuje) od tworzenia baz danych do wirtualnych FMC/FMSów do zaawansowanych modeli samolotów w MSFS a później Prepar3d. Bazy te zawierają to, co bazy FMC w prawdziwych samolotach:

Muszę przyznać, że post jest super merytoryczny. Dzięki, super się czyta!

Masz rację co do Navigraph. To baza danych do symulatorów (FSX, P3D, XPlane) oraz dodatków do symulatorów plus programów użytkowych w stylu flight plannerów. Tak jak napisałeś, baza danych, ale nie narzędzie do tego czy owego. Można rzec, że pobocznie oferują jeszcze mapy lotnicze.
A więc póki dodatki programy jako dane wejściowe potrzebują tylko "proste informacje", póty navigraph nie będzie szedł w niepotrzebne koszty.

Z ciekawości sprawdzę co PFPX wygeneruje, ale muszę go najpierw zainstalować po instalacji nowego Windowsa.

Wow! Chwilę mnie nie było, a tu takie wypracowania powstają :)
foxmulder, dziękujemy za Twoje zaangażowanie. Szacun.

Zaskoczyło mnie, że RNAV powstał przed GNSS. Czyli RNAV był tworzony nie w oparciu o system satelitarny tylko w oparciu o naziemne radiopomoce nagiwacyjne VOR i DME? I samolot lecąc nawet po punktach RNAV musiał być cały czas w zasięgu jakiejś radiopomocy? A punkty RNAV (fixy) to były współrzędne wypadające na przecięciu radiali różnych VOR-ów?

Kolejna rzecz, która mnie ciekawi: napisałeś, że obecnie RNAV bazuje na DME (VOR nieopłacalny), czyli do określenia pozycji statku powietrznego wystarczy coś w rodzaju triangulacji - odległości od 3 nadajników (niepotrzebne są radiale), dobrze zrozumiałem?

W kwestii lotnictwa wirtualnego: zdaję sobie sprawę z ułomności tychże rozwiązań, w szczególności tych darmowych (choć są wyjątki, że darmowe są lepsze od płatnych). Nie miałem okazji korzystać z płatnego plannera, ale z tych darmowych do IFR uważam że Little Navmap jest najlepszy. Ma błędy, sukcesywnie je sobie wypisuję i co jakiś czas wysyłam do autora (niedługo będzie kolejna wersja z poprawkami), ale ogólnie jest świetny. Wcześniej używałem strony Route Finder, potem Online Flight Planner, potem oprogramowania vRoute, potem "ręcznie" planowałem loty z wykorzystaniem SkyVectora, ale odkąd trafiłem na Little Navmap zlecam to jemu.

Cytat:

Zamieszczone przez arek_waw

Zaskoczyło mnie, że RNAV powstał przed GNSS.

Do nawigacji obszarowej (RNAV), na upartego, w zasadzie nic nie potrzebujesz oprócz mapy, kompasu, prędkościomierza, zegarka i linijki. Jeżeli będziesz znał kurs, prędkość i czas, możesz sobie na mapie wyrysować punkt na mapie, w którym się obecnie znajdujesz.
Jeżeli będziesz aktualizował swoją pozycję dość często, będziesz miał dość aktualną pozycję. Będziesz też w stanie wyznaczyć kurs na dowolne współrzędne geograficzne.
Na (mniej więcej) takiej zasadzie działają INS-y, czyli systemy inercyjne. Stojąc na lotnisku, wprowadza się w system współrzędne geograficzne. Następnie podczas ruchu precyzyjne żyroskopy wykrywają przeciążenia, które to są przeliczane na wektory ruchu (przesunięcie pozycji).
System tak naprawdę nie zna swojej pozycji, ale wie że od miejsca startu przesunął się tyle a tyle na wschód i tyle a tyle na północ, więc sobie to przelicza i pokazuje wynik.

Obecnie FMS integruje INS, GPS/GLONASS, odbiorniki VOR i DME. Mając dane z kilku źródeł zwiększa się precyzję ustalenia pozycji w przestrzeni.

Cytat:

Kolejna rzecz, która mnie ciekawi: napisałeś, że obecnie RNAV bazuje na DME (VOR nieopłacalny), czyli do określenia pozycji statku powietrznego wystarczy coś w rodzaju triangulacji - odległości od 3 nadajników (niepotrzebne są radiale), dobrze zrozumiałem?

Tak.
W przestrzeni 3 wymiarowej potrzeba 4 źródła danych, ale mając wysokościomierz można wyliczyć pozycję z 3 sfer.