Letecké drama na pokračování

Část druhá

Vzhledem k až neočekávaně příznivým ohlasům na první část tohoto dramatu a na četná přání z řad p.t. čtenářské obce jsem se rozhodl pokračovat. Upřímně řečeno jsem neočekával, že tak příznivě budou přijaty tak málo atraktivní informace o tom, co se děje v zákulisí pro diváka mnohem zajímavějších dějů.

Kam jsme to minule došli? Aha, došli jsme k situaci, kdy složky řízení provozu vymyslely, nebo si alespoň myslely, že vymyslely, neomylný automatizovaný systém, který zabrání tomu, aby letadla vyčkávala před přistáním ve vzduchu a současně, aby před vzletem vyčkávala s běžícími motory před dráhou, čímž mělo dojít ke značným ekonomickým úsporám a současně ke zvýšení ohleduplnosti k životnímu prostředí.

Dále jsme si řekli důvody, proč systém jaksi odmítal fungovat. Tím důvodem byly  poruchy v předpokládaném průběhu odbavovacího procesu, ať už to bylo neukázněné počínání cestujícího, nebo prostě chybná organizace procesu samého.

Složky řízení se dostaly do situace režiséra pozorujícího herce na scéně s myšlenkou, jak mu to ti troubové zase kazej. Ale pozor! Lichá je představa, že cestujícího předěláte a svou roli hraje i následující skutečnost. Všichni, ale absolutně všichni, panem kapitánem a jeho posádkou počínaje, přes generalitu letecké společnosti která pana kapitána zaměstnává, až po posledního pošmejďáka u této společnosti, dále všichni zaměstnanci letiště i zaměstnanci složek řízení provozu, absolutně všichni jsme placeni z peněz, které je cestující ochoten zaplatit za letenku, která je ne právě nejlevnějším zbožím. Existuje tedy velice úzká souvislost mezi portmonkami cestující veřejnosti a naší výplatní páskou na konci měsíce.

Bude tedy lepší naše chlebodárce příliš nepopouzet, akceptovat nezměnitelný stav věcí a přizpůsobit naše chování  a postupy daným skutečnostem. Tak se došlo na myšlenku „Airport CDM“, neboli „Collaborative Decision Making“, společného rozhodování ve spolupráci dopravce, provozovatele letiště a složek řízení.

Oni si totiž donedávna hráli více méně každý na svém písečku a vzájemné vazby byly velice, velice chabé. Dopravce podal letový plán, letiště odbavovalo a řízení provozu slepě věřilo, že letový plán (v této fázi hlavně časové údaje v něm uvedené) bude dodržen. Složky řízení praktikovaly přístup „gate to gate“. Let je zajímal od okamžiku, kdy opouští odbavovací místo, až do okamžiku kdy letadlo zastaví po příletu na jiném odbavovacím místě. Co se děje v mezičase je příliš nezajímalo. Jak výše uvedeno, spoléhaly plně na letový plán příštího letu.

Co je tedy principem „Airport CDM“?  Upozorňuji, že následujíc popis je velmi, ale skutečně velmi zjednodušený.

Ačkoliv to málokdo ví, je průběh odbavovacího procesu pečlivě naplánován. Tedy, má-li být dodrženo EOBT (Estimated off Block Time), tedy předpokládaný čas zahájení pojíždění uvedený v letovém plánu následujícího letu, musí určitá událost v  procesu odbavení nastat

v čase „T“. Následující událost musí nastat v čase T plus něco a tak dále.

Tyto rozhodující okamžiky byly nazvány milníky (mile stones) a o jejich dosažení se partneři vzájemně informují. Jakmile z informace vyplývá, že určitého milníku bylo nebo bude dosaženo pozdě a to s dopadem na EOBT a tedy i na čas vzletu, musí se podniknout nějaké opatření.

Co v této situaci činí sám dopravce a letiště, to nevím, ale nás zajímá DMAN,  tedy vzletový manager. Ten průběžně sleduje aktualizace  EOBT a z nich vyplývající možný čas vzletu nazývaný  „Target Take-off Time (TTOT).  DMAN průběžně  hledá v příletovém sledu mezeru kam vzlet zařadit, popřípadě vyjednává s AMANem, aby mu tuto mezeru vytvořil. Změní-li se TTOT začne celý proces znovu.

Od jistého okamžiku začne DMAN zpětně informovat partnery o výsledku svých kalkulací. Tímto časem je z hlediska jednotlivého vzletu obvykle čas, kdy eventuální přílety dosáhnou časového horizontu působnosti AMANu a kdy už existuje jakýs takýs předpoklad, že naposledy aktualizované EOBT je zhruba stabilní. Trvá-li let od hranice oblasti do přistání 15 minut a koordinační data jsou obdržena 15 minut před vstupem (a AMAN začne být schopen ovlivňovat příletový sled), začne DMAN informovat partnery o vypočteném čase vzletu 30 minut před aktuálním EOBT a zašle zprávu se zhruba následujícím obsahem:

„Vážení, na základě Vámi naposledy laskavě  aktualizovaného času EOBT si Vám dovolujeme sdělit, že pro Váš let jsme vykalkulovali čas vzletu „T“. Své další činění upravte tak, abyste byli připraveni ke spuštění pohonných jednotek v čase „T minus něco“ a byli připraveni k pojíždění v čase „T minus o něco méně“.

Je samozřejmé, že čas, kdy má být letadlo připraveno k pojíždění podle požadavků DMANu nemusí být totožný s naposledy aktualizovaným časem EOBT oznámeným na základě průběhu odbavovacího procesu. Požadovaný čas vyplývá z interakce AMAN a DMAN a následně nalezeného optimálního času pro vzlet.

Dále z toho logicky vyplývá, že požadovaný čas zahájení pojíždění nemůže nikdy ležet před

se strany partnerů aktualizovaným EOBT. To je ten nedřívější čas, ve kterém může být s ohledem na předchozí události pojíždění zahájeno. Oba časy budou v ideálním případě totožné, ale spíše bude čas požadovaný DMANem  vzhledem k příletům a předchozím odletům o něco pozdější. Pozor, nemluvíme o hodinách , ale o čase v jednotkách minut!

Jestliže něco na zemi opět selže (a to se půl hodiny před odletem stále ještě může stát, protože v té době začíná, nebo probíhá nástup cestujících) a EOBT se opět změní, tak nezbývá, než celý proces opakovat. Tedy: další aktualizace EOBT, nové hledání škvíry, kam letadlo strčit, nové dohadování mezi DMANem a AMANem, nový požadovaný čas pro zahájení pojíždění a plánovaný vzlet.

Ať se práší z kočárem a z procesorů ať se kouří.

Já tu ale stále mluvím o čase, kdy by měl být let připraven k nahození a zahájení pojíždění podle výpočtů DMANu, a ono to tak vlastně není. V mezičase nám totiž vstoupil do hry další partner a to SMAN. Tedy „Surface Manager“, pro kterého marně hledám lidský překlad do češtiny. „Povrchový manager“ je zjevná blbost a „manager pojíždění“ není zase plně vystihující označení. O co jde?  I na takovém letišťátku, jakým je naše milá Ruzyně  (ano, ve srovnání se světovými velkoletišti je to skutečně letišťátko) je setsakramentský rozdíl, jestli se letadlo chystá pojíždět od nákladového terminálu cca 300 metrů od dráhy 24, nebo se chystá pojíždět tamtéž z prostoru terminálu jih (staré letiště) vzdáleného tři kilometry. A teď si představte situaci, že ten pojíždějící ze starého letiště bude vzlétat jako druhý, až  za tím stojícím v prostoru pro cargo.  Aby byl schopen ve vypočteném čase vzletět , musí ten, který parkuje podstatně dál zahájit pojíždění podstatně dřív než ten který parkuje nedaleko dráhy i přesto, že ten co je blíž u dráhy bude startovat jako první.  Navíc ten co to má blíž žádá z nějakých důvodů  o povolení k pojíždění dříve. Pokud pořadí a časy vzletů nebyly rigorózně určovány, bylo to jedno, za daných okolností ale nikoliv. Kdyby mu bylo vyhověno, před dráhu by  mohli dorazit v opačném pořadí, než by měli vzletět. Vzájemné předjíždění na poslední chvíli je sice v konkrétním případě dráhy 24  možné, ale v případě jiných drah nikoliv. Tak a jsme v pytli! Respektive byli bychom kdyby nebylo SMANa.

Jak to funguje, nebo lépe řečeno, jak by to v budoucnu fungovat mělo. DMAN vytvoří po dohodě s AMANem vzletový sled (pořadí ve které letadla vzletí) a vykalkuluje konkrétní časy vzletů. Vše předá kromě jiných i do SMANu. SMAN se porozhlédne po letišti a vyhledá místo, kde se dotyčné vzdušné koráby nalézají. Vypracuje pojížděcí trať a na základě parametrických časů  vypočte za jak dlouho ten který z nich dorazí před dráhu. Následně odečte od  vykalkulovaných časů vzletu jednotlivé časy potřebné k pojíždění, čímž získá časy, kdy by měl každý z nich opustit svůj parkovací bod tak, aby před dráhu dorazili v žádoucím pořadí a časových odstupech. Říká se tomu předvzletový sled, neboli  „pre-departure sequence“.

Individuálními údaji pro jednotlivé lety obešle SMAN partnery  v procesu CDM a sled jako celek dostane řídící věž. Řídícímu tamtéž říká: „Hele, letadlo A by se ti mělo rozjet v čase  „T“ jako první i když vzlétat bude až jako druhé za letadlem B, které se sice  rozjede jako druhé, ale parkuje podstatně blíž od dráhy. Koukej dohlídnout, ať ti v tomhle pořadí taky skutečně před dráhu dorazí! Jinak budeš mít potíže pořadím a   dodržením časů vzletu.“

Zní to všechno sice hezky, ale potíž bude s těmi parametrickými časy. Zase ty zatracené parametrické časy. Jak bylo  v prvním díle tohoto dramatu uvedeno, letadlo na zemi je tvorem nevypočitatelným a skutečné časy pojíždění se v reálu budou stoprocentně lišit od těch parametrických, tedy předpokládaných, alespoň v polovině případů. Takže ti kluci (a dnes i holky) na cimbuří (řídící věži) tam zcela určitě budou nuceni zůstat i nadále.

Tohle je praktická ukázka toho, čemu se říká „systémová podpora řízení provozu“. A tohle je  prosím Letiště Praha Ruzyně!  A teď si představte Paříž de Gaulle, nebo Amsterdam Shiphol!

Připadá vám to složité? Držte si klobouky, ještě jsem neskončil. Abych to vysvětlil, musím začít poněkud ze široka.

V průběhu osmdesátých let začalo být nad oblohou západní Evropy poněkud dusno a těsno. Střední a východní Evropu  postihlo totéž  s malým zpožděním a na základě proběhlých politických změn v létech devadesátých. Pro vaši informaci a pokud jste to už nečetli jinde.  V roce 1991 bylo ve vzdušném prostoru České republiky registrováno 110 360 IFR (Instrument Flight Rules) letů, tedy řízených letů podle přístrojů. V roce 2000 to bylo 308 428 pohybů a v roce 2010 již 649 403 IFR pohybů.

Tohle ovšem dosud poněkud zanedbávané služby řízení řádně zaskočilo a zvládaly to jen s největšími potížemi. Začínalo být zjevné, že půjde-li to takhle dál, začne jít brzy cestujícím v letadlech o kejhák a řídícím na zemi o kriminál.

I začalo se masivně investovat do detekční techniky (primární radary, sekundární radary, monopulzní sekundární radary, S-Mód a později ADS /Automatic Dependent Surveillance/), podpůrných počítačových systémů a do vývoje nových provozních postupů.

Zároveň bylo ale jasné, že tohle všechno chce čas a výsledky se nedostaví hned. A udělat něco okamžitě bylo nutné. I začala éra řízení toku provozu.

V dřevních dobách to probíhalo tak, že posádka letu, dejme tomu z Kodaně do Istanbulu, si přečetla zprávu, které středisko na jeho trati řídí tok. Středisko na trati  totiž z předběžného plánování (ano tehdy se ještě plánovalo také předběžně, tedy před podáním letového plánu), ale  hlavně z empirické zkušenosti vědělo, že v pátek mezi 14:00 až 18:00 bude mít na krku  provoz hustší než zdrávo. Po podání letového plánu byl pan kapitán nucen zvednout telefon a zavolat dotyčné středisko (třeba z Kodaně do Prahy) a zeptat se, zda je pro něj příslušném  čase a v prostoru ještě místo. Buď bylo, nebo bylo zájemců tolik, že mu bylo řečeno zhruba následující: „Je nám líto,  mezi 14:00 a 14:25 jak vyplývá z vašeho letového plánu už jsme totálně přetížený, ale máme na vás čas mezi 14:35 a 15:00“.

Pan kapitán pak následně posunul čas vzletu o dotyčných 35 minut.

Bylo to neohrabané, ale pokud bylo na trati řízení toku jen jedno, tak to jakž takž fungovalo. Jenže provoz houstl dál a čím dál častěji se stávalo, že řízení toku na trati bylo několik a chudák kapča dostal dva, tři nebo i více časů, které spolu vůbec nekorespondovaly.

Zkrátím to, po dalších peripetiích bylo výsledkem nadnárodní centralizované středisko řízení toku (Central Flow Management Unit – CFMU) v Bruselu.

Jak to funguje, o tom si přečtěte v třetí části našeho povídání.