arepulesrol

[arepulesrol]

Meteorológiai táviratok

Tudjuk, hogy a repülésben az egyik legfontosabb információ az időjárási adatok. Mint minden más, ezek az adatok is szabványosított formában jutnak el a felhasználókhoz (repülőterek, légiforgalmi irányítóközpontok, pilóták).

Nézzük, milyen meteorológiai adatokat cserélgetünk, és miért hívjuk ezeket táviratnak?

A repülés hőskorában az elsődleges kommunikációs forma a távíró volt. A meteorológusok elkészítették a méréseket, azokat egy szabványos, tömör formátumba szerkesztették, majd a távírász "feladta", a címzett leírta, és ezzel meg is érkezett a távirat. Később a távírászokat felváltották a telexek, a rádiós továbbítást pedig az AFTN (Aeronautical Fixed Telecommunications Network) hálózat. Telexek meglepő módon a kilencvenes évekig üzemeltek, az AFTN hálózat pedig - nyilván fejlesztve - máig üzemel, az egyik legfontosabb kommunikációs médiumként.

Kis színes: a légitársasági üzenetváltásokat, amik anno szintén telexen érkeztek, a SITA V. kerületi központjában fogadták. Dél és fél egy között az üzenettovábbítás szünetelt, no nem ebédszünet miatt, hanem addigra gyűlt össze annyi hulladék papírszalag a telexekből, hogy már nem lehetett közlekedni a teremben. A kitakarítás idejére pedig üzemszünet volt.

A telexeket mára leváltották a feldolgozó számítógépek, a telefonvonalakat az IP-s hálózat erre-arra vegyítve a klasszik telefonvonalon üzemelő modemekkel, de az üzenetek formátuma évtizedek óta ugyanaz a rövid, tömör szöveg maradt - ezért használjuk máig a távirat kifejezést.

Nézzük, milyen táviratfajták léteznek, kezdjük a nagyközönség által is jól használható METAR-ral és TAF-fal!

METAR

A legfontosabb egy adott repülőtér aktuális időjárását közlő METAR, Meteorological Aerodrome Report. Ez egy 30 percenként (szignifikáns, tehát repülésre veszélyt jelentő, hirtelen változások esetén ennél gyakrabban, ez a SPECI) frissülő riport. A METAR-t a repülőtéren dolgozó helyi észlelők állítják össze. 2022 végéig Magyarországon ezt a Hungarocontrol meteorológusai, azóta pedig az OMSZ készíti. Tartalmazza az aktuális szélirányt, felhőzetet, látótávolságot, hőmérsékletet, légnyomást, rossz látási viszonyok esetén a futópályamenti látótávolságot (RVR), légnyomást, illetve ha jelentősebb változás várható, akkor azt is.

Nézzünk néhány példát, itt az augusztus 5-i armageddon riportja:

METAR LHBP 050000Z 25037G64KT 210V280 SQ 0200 R31L/0500D R31R/0650D +TSRAGR OVC020CB 19/19 Q1009=

LHBP - a ferihegyi repülőtér kódja. 05000Z - a hónap ötödik napján, UTC éjfélkor készült riport 25037G64KT 210V280 - az alapszél 250 fokról 37 csomó, 64 csomós lökésekkel, iránya változik 210 és 280 fok között SQ: szélrohamok 0200 - látótávolság 200m R31L/0500D R31R/0650D: 31L futópálya földetérési zónájában a látótávolság 500m, romló tendenciával (erre utal a D, downwards), 31R pályán 650m. +TSRAGR: Heves (+) zivatar (TS) esővel (RA) és jéggel (GR). OVC020CB: a felhőzet teljesen fedi az eget (OVC, overcast), alapja 2000 lábon (020), fajtája zivatarfelhő (CB, Cumulonimbus). 19/19: hőmérséklet és harmatpont 19 fok. Q1009: a számított légnyomás (QNH) 1009hPa.

4 perccel később már jött is a kiegészítő SPECI:

SPECI LHBP 050004Z 27028G51KT 220V300 2000 R31L/0900U R31R/1200U TSRA SCT006 BKN020CB 19/19 Q1007 RETSGR BECMG 8000 -TSRA=

Látótávolság javult 2000 méterre, a pályamenti látás javult és javuló tendendciát mutat (R31L/0900U, upwards), jelenleg zivatar van esővel (TSRA), korábban zivatar volt jégesővel (RETSGR, Recent thunderstorm, hail (GR)), várhatóan a látótáv javulni fog, és csökken a zivatar ereje (BECMG, Becoming, 8000m, -TSRA).

SPECI LHBP 050055Z VRB04KT 4000 TSRA SCT004 OVC025CB 20/20 Q1007 TEMPO 0500 +TSRA=

Itt pedig egy újabb kiegészítés, amit akkor adtak ki, amikor bedörrent BP mellett a harmadik cella. Itt azt mondja a végén, hogy hamarosan, átmenetileg (TEMPO) 500m-re csökken a látás, és újabb heves zivatar várható.

TAF

A Terminal Area Forecast 6 óránként frissülő, 24 órára szóló előrejelzést tartalmaz egy adott repülőtérre. A TAF kódolása megegyezik a METAR-ral, annyi kiegészítéssel, hogy az egyes időszakok is szerepelnek benne, valamint a kétes beválású előrejelzések PROB30 (30% esély) vagy PROB40 jelzéssel vannak ellátva.

Nézzünk egy példát:

EFHK 081732Z 0818/0918 14002KT 9999 FEW030 TEMPO 0822/0905 4000 MIFG BR PROB40 0900/0905 0500 FG VV002 PROB40 0905/0907 4000 BR BKN004

EFHK: Helsinki 081732Z: kiadva 8-án, 17:32UTC-kor. 0818/0918: érvényes 8-án 18UTC kezdettel 9-én 18UTC-ig 0822/0905: 22 UTC és 5 UTC között várhatóan... PROB40 0905/0907: 5 és 7 óra között 40% valószínűséggel...

A METAR és TAF táviratok azok, amik nagyon hasznosak lehetnek azoknak, akik repülőtér környékén élnek. Én egy napnál távolabbra az Időképet használom, de 24 órán belülre csak a TAF-ot és a METAR-t. A beválási arányuk több, mint kiváló. Kis gyakorlás után mindkettő szépen dekódolható fejben is.

Hasznos linkek ezekhez: METAR/TAF dekódolva is: https://en.allmetsat.com/metar-taf/europe.php?icao=LHBP METAR/TAF rövidítések jegyzéke: https://www.aopa.co.uk/images/go_flying/METAR_TAF_abbreviations.pdf

AIRMET, SIGMET

Ezzel a két táviratfajtával ritkábban lehet találkozni. Általában teljes FIR-ekre vonatkoznak (tehát például egész Magyarország területe), és csak szükség esetén adják ki őket.

Az AIRMET tartalmazza azokat a jelenségeket, amelyek a repülésre nem kifejezetten veszélyesek, de "jó tudni": közepes turbulencia, jegesedés.

A SIGMET a veszélyes (szignifikáns) jelenségeket taglalja, mint zivatarok, zivatarrendszerek, heves turbulencia, erős jegesedés.

Ezek forrása szintén a meteorológusok, illetve maguk a pilóták is, akik jelentik az irányításnak pl az erős jegesedést, akik továbbítják a jelentést, majd ebből születik egy SIGMET.

Formátumuk ugyanaz a tömör, mint a METAR, a rövidítések is megegyeznek, néhány kiegészítéssel, amiket angol tudással könnyen meg lehet fejteni:

WSTU31 LTAC 081827 LTAA SIGMET 7 VALID 081830/082230 LTAC- LTAA ANKARA FIR EMBDD TS N OF LINE N39 E041- N39 E043 - N39 E045 TOP FL340 MOV NE 12KT NC=

Ankara FIR, embedded thunderstorms north of line (coords), cloud top FL340, moving northeast az 12 knots, no change. Az ankarai FIR-ben zivatarok vannak, északra a koordinátákkal jelölt vonaltól, a felhőtető FL340-en van, a rendszer 12 csomóval mozog, nem várható változás.

FAJO SIGMET B02 VALID 081800/082200 FAOR- FAJO JOHANNESBURG OCEANIC FIR SEV TURB FCST WI S4449 E05700 - S4500 E05700 - S4500 E06531 - S4534 E06620 - S5101 E05250 - S5251 E03436 - S5215 E02132 - S4824 E01502 - S4612 E01636 - S4742 E02644 - S4748 E04659 FL240/270=

Itt pedig egy erős turbulenciáról szóló előrejelzés, a koordinátákkal megadott boxban (severe turbulence forecasted within...)

AIRMET/SIGMET adatbázis: https://www.aviationweather.gov/sigmet/intl?hazard=all&loc=eur

GRIB

A GRIB egy fájlformátum neve (GRidded Binary), nem az adatoké, azonban eddig bárkit láttam szakmában, így hivatkozik rá. Ez egy kakukktojás, mert bár meteorológiai adat, nem táviratként közlekedik, viszont ugyanúgy felhasználják mindenhol, mint a fentieket. A GRIB a magassági szeleket tartalmazza az egész Földön, 100 NM x 100 NM felbontással, földfelszintől egészen FL660-ig.

Ezeket az adatokat a flight plannerek használják az útvonalak tervezéséhez (kiemelten: transzatlanti járatok. USA-EU viszonylatban meglovagolják a jetstream-et, ezzel akár egy órát is lehet nyerni.), a pilóták, illetve az irányításban az ETO (Estimated Time of Overfly) időket pontosítjuk vele.

SNOWTAM, ASHTAM, BIRDTAM

Ismét félig kakukktojások, ezért csak érintőlegesen pár mondat. Ezek a táviratok egyfajta NOTAM-ok (Notice To Airmen v. Notice To Air Missions).

A NOTAM a repülőtér és légtérrel kapcsolatos, nem meteorológiai jellegű infóit tartalmazza (például: pályazár, korlátozások, eseti légterek).

A SNOWTAM havas időben kerül kiadásra, és a futópálya állapotát tartalmazza (milyen csapadékforma van a pályán, latyak, száraz hó, jég; milyen vastagságú; milyen a fékhatás):

(SNOWTAM 1435 EBLG 11300120 04L 5/5/5 75/100/75 NR/03/03 WET/SLUSH/WET SNOW 11300130 04R 5/2/2 100/50/75 NR/06/06 WET/SLUSH/SLUSH RWY 04L SNOW BANK LR20 FM CL. RWY 04R ADJ SNOW BANKS. TWY B POOR. APRON POOR)

Bővebben: https://skybrary.aero/articles/snowtam

Az ASHTAM vulkáni tevékenységet részletez, koordinátákkal:

VALI0024 LIRR 01151800 ASHTAM 015/10 A) ROMA FIR B) 01151650 C) ETNA 101-06 D) 3744N01500E E) RED ALERT F) AREA AFFECTED 3700N01500E 3900N01600E 3800N001700W SFC/35000FT G) NE H) ROUTES AFFECTED WILL BE NOTIFIED BY ATC

Bővebbn: https://skybrary.aero/articles/ashtam

A BIRDTAM pedig madárütközés veszélyére figyelmeztet. Ez az üzenetforma nem szabványosított, és nem is használják univerzálisan, ezért igen ritkán lehe vele találkozni.

[arepulesrol]

Változások a repülésben

Kaptam egy remek kérdést a torony régen-most posztomra a Twitteren (az X még mindig nem jön a számra):

Rengeteg minden változott, arról tudsz mesélni, hogy a különböző technológiák közötti váltásokat hogyan oldja meg egy reptér? Átállni egyikről a másikra, fejleszteni? Mekkorák az ilyen maintanance ablakok, amikor nincs forgalom? Van e egyáltalán ilyen?

Amit itt leírok, az az ICAO/Eurocontrol ajánlásokon alapszik, semmiféle konkrét eljárásrendet nem teszek közzé. </Disclaimer> :)

A repülés és légiforgalmi irányítás nem kifezetten az az iparág, ahol mindig a bleeding edge-n vagyunk. Természetesen begyűrűzik előbb-utóbb minden technológiai újítás, de sosem az elsők között adoptáljuk ezeket. Mondok egy példát: a világon sehol sincs például tisztán VOIP alapú telefonos, vagy rádiós hálózat a légiforgalmi irányításban. Miért? Mert "új". Mert még most készülnek azok a szabványok (ICAO illetve Eurocontrol), amelyek olyan bombabiztossá teszik majd a rendszert, ami a repülésben elfogadható lesz.

Nézzük meg, hogyan történik egy technológiai átállás. Alapvetés, hogy nem történhet változtatás anélkül, hogy erről ne készülne egy repülésbiztonsági elemzés, kockázatértékeléssel. Nem csak olyan volumenű változáshoz szükséges ilyet írni, hogy teszemazt, átépítjük az irányítóközpontot, hanem egy látszólag egyszerűbbhöz is: átrakunk egy routert az egyik rackből a másikba.

Mit tartalmaz egy ilyen elemzés? Mit is szeretnénk csinálni? Miért? Mikor? Mit érint, kiket? Milyen adatkapcsolat az, amit biztosan érinteni fog? Van ezeknek tartaléka? Mi van, ha a tartalék elhal pont a művelet közben? Mennyire kritikus az érintett rendszer? Satöbbi satöbbi. Minden csoport, aki érintett egy ilyen ügyben, ellenőrzi, hogy nem ütközik-e valamilyen más munkával a művelet, ami gondokat okozna, majd összehoznak egy kockázati értéket. Addig kell gyűrni a művelet kivitelezésének módját, amíg - kritikus rendszerek esetében - minden "mi van akkor, ha.." kezdetű kérdésre az lesz a válasz, hogy nem, vagy csak rendkívül minimális eséllyel lesz kiesés.

Ha ez elkészült, akkor beütemezhető a munka, minden érintett megkapja a tájékoztatást, és - szintén kritikus rendszerek esetében - valamikor késő éjjel, kis forgalomban elvégezhető.

A légiforgalmi irányításban az irányítás ura az ATC Supervisor, a irányítást közvetlenül és közvetetten támogató rendszerek ura pedig a Technical Supervisor (TSV). Bármely munka az irányítási rendszereken csak akkor kezdhető meg, ha erre a TSV engedélyt ad - amire ő beszerzi az ATC SV engedélyét.

Kritikus rendszereknél downtime szinte nincs, az irányítás folyamatos. Meg kell oldani tehát valahogyan azt, hogy úgy történjen minden karbantartás, frissítés, hogy az irányításban ez ne okozzon néhány másodpercnél hosszabb kiesést. Ezt jellemzően a redundanciával lehet megoldani. Dolgozunk a slave-n, switchover, aztán a korábbi masteren. Vagy hálózati eszköz esetében viszi a hot standby pár a forgalmat, amig a master le van állítva. Vagy rádiónál a tartalék, multiplexereknél a kerülő utak, stb.

A legkritikusabb rendszer természetesen maga az irányítórendszer. Ez a rendszer is redundáns szerverekből épül fel, redundáns hálózaton kommunikál, és képes arra, hogy egy paranccsal rendszerszinten váltogasson oda-vissza a szoftververziók vagy paraméterek között. Ha erre a rendszerre érkezik egy patch, vagy paraméterfrissítés (például egy új légtér), azt először természetesen szénné tesztelik a teszt rendszeren, majd feltöltik az éles rendszerre. A váltási parancsra (ugye késő éjjel, SV-k engedélyével) a rendszer annyit tesz, hogy az applikációit újraindítja, és megcseréli az új paraméterszettet a régivel. Egy ilyen váltás néhány másodpercig tart, és utána onnan folytatja az irányító, ahol abbahagyta. Ha kiderül, hogy mégsem kerek valami, ugyanúgy pár másodperc alatt vissza lehet állni a korábbi verzióra. Szoftverfrissítés már komolyabb, ott hosszabb kieséssel kellene számolni, azonban erre is mindenhol van megoldás: vagy egy tartalék rendszert használnak a frissítés alatt, vagy ki van építve egy "kisközpont", ahol kis forgalmat biztonságosan el lehet vinni, és oda ülnek át az irányítók.

Előfordulhat nagy volumenű munka is, például egy teljes átépítés. Ez ott tud zökkenőmentesen végbemenni, ahol van egy tartalék irányítóköpont. Magyarországon van. Az átülés menete jellemzően az, hogy beülnek a tartalékközpontba (contingency központ) az irányítók "árnyékolni", vagyis hallgatják a rádióforgalmazást, és végrehajtják ugyanazokat, amit az élesen az ottani irányítók. Beírják a címkékbe a kiadott magasságokat, stb. Amikor felvették a ritmust, és minden flottul működik, végszóra megtörténik a váltás, a műszak átkapcsolja a telefonvonalakat, és onanntól ők irányítanak. Ezt a pilóták annyiban veszik észre, ha egyáltalán, hogy a következő utasítást már más hangtól kapják. Esetleg még annyival lehet megfejelni az átülést, hogy miután a contingency átvette az irányítást, onnantól a korábbi központ árnyékol meghatározott ideig, hogy szükség esetén azonnal visszavegye a forgalmat. https://iho.hu/hirek/hungarocontrol-felujitas-utan-vissza-a-munkaterembe

A technológiai váltásoknál minden agyon van tesztelve, mielőtt bekerülhet az irányítók elé. Vagy számtalan próbával (már vannak tesztelés alatt tisztán VOIP telefonok), stressz teszttel, gyűri az új rendszert a network security etikus hackerei, ezerszer lepróbálják a redundáns váltásokat, és még lehetne sorolni. Ami tehát bekerül az irányításba, az szinte biztos, hogy hibamentes.

Általában még arra is figyelnek, hogy egy user interface-nél ne legyen drasztikus váltás. A Topsky irányítórendszer UI-ja szinte ugyanúgy néz ki már bő 20 éve. Hellyel-közzel meg lehet feleltetni a Windows szériának: a felület keveset változott (oké, tudom, hogy W95 és W11 között mekkora a difi, az elvre gondolok), de az alatta lévő szoftver nagyonis. De ugyanez igaz a hangkommunikációs rendszerre is, a minap a kezembe került egy rádiós-telefonos panel 40 évvel ezelőttről, és még abban is fel lehet fedezni számos elrendezésbeli és funkcionális hasonlóságot a mostanival - igaz, hogy a kattanós kapcsolókat és izzólámpás visszajelzőket már leváltotta rég a touchscreen.

A repülőtérnél már keményebb dió egy nagyobb karbantartás. Az IT, elektromos rendszerek stb esetében ugyanúgy megvan a redundancia, de egy teszemazt futópálya karbantartásnál már zárni kell. Régebben a pályakarbantartásokat éjjel csinálták, manapság már nappal zárják az egyik futópályát, amíg hézagolnak, fényeket javítanak, vagy leszedik a gumit. Itt Ferihegyen van két pálya, tehát komolyabb fennakadást ez nem okoz. Nagyon ritkán van, amikor olyat csinálnak, amihez teljes reptérzár kell. Pár éve volt ilyen, pontosan nem tudom, mit csináltak akkor, de kiadták jó előre, hogy éjféltől reggel 4-ig még kényszerhelyzeti forgalom sem jöhet.

[arepulesrol]

Die Hard 2, repülős szemmel

Minap feldobtam a Twitterre egy rövidet a PAPI fények-ről, amik segítenek a vizuális megközelítésben. Hamar elterelődött a téma a preciziós leszállítórendszerek felé (ILS), mígnem fel nem merült, hogy elemezzük a Die Hard 2 mozit repülős szemmel.

Legyen hát!

"Valahogy" megszakítjuk a kommunikációt az irányítás és a gépek között, szerencsétlenek maradnak odafenn holdingolni, fogy az üzemanyag, jajaj. Hogyan lehetne ezt megtenni? Zavarjuk az összes frekvenciát és kész, katonáknak van rá cuccuk. A filmben nem ezt a módszert használták - hiszen beméred a zavarót, Bruce odamegy, stáblista.

Az irányítást kellett elhallgattatni. Ez már keményebb dió. A repülésben minden redundáns, különösen a rádiók. Több rádiós telephely üzemel általában, minden telephelyen minden ott telepített frekvenciához egy main és standby rádióval, minden telephelyhez saját generátorral. A telephelyeket - hacsak nem valami huszadrangú adócskáról van szó - redundáns adatkapcsolatokon érjük el, redundáns hálózati eszközökön. A vonalak georedundánsak, azaz nem lehet ugyanazon a nyomvonalon a fő és a tartalék (Working és Protecting ág). A legjobb, ha még a szolgáltató sem egyezik meg. Ha országon belül vagyunk, akkor az egyik ág lehet optika, a másik pedig mikrohullám. Egy telephely többé-kevésbé képes lefedni az országot, így ha egy kiesik, legalább még egy tud szolgáltatni.

Tehát nem piszkáljuk a telephelyeket, mert nem lesz belőle film.

Menjünk tovább az irányítóközpontba. Redundáns kommunikációs rendszer, redundáns áramellátás, redundáns szerverek, hálózat, klimatizálás, sőt, több helyütt még maga a központ is redundáns, a tartalékközpont a fő központtól teljesen független, a maga redundáns rendszereivel, továbbá akad néhány "last resort" rádió is. Ez utóbbiak a nevükből adódóan a legutolsó mentsvárak, ha már minden, de tényleg minden megállt, ezek akkor is mennek tovább: külön akku, külön távkezelő, külön mikrofon és hangszóró, saját kábelnyomvonal, saját antenna. Itt legfeljebb csak a Storm Shadow vagy a Kindzsal rúghatna labdába.

Tegyük fel, hogy megtörténik ez, és a teljes központ eltűnik a térképről, tartalékkal együtt. Mi fog történni?

A pilóták igen hamar realizálni fogják, hogy csend lett a frekiken, próbálkozni fognak kétszer, majd harmadjára bemondják az világszerte használt vészfrekvencián, a 121.5 Mhz-en, hogy keresik Budapestet. Ez a frekvencia minden repülőgépen és irányítói munkahelyen kötelezően ki van választva, tehát rengetegen fogják hallani az adást.

Hamarosan kiderül, hogy ott sem válaszol az irányítás. Innentől már lehet, hogy lesz némi fejetlenség, amikor mindenki egyszerre akar adni. Közben észreveszik a katonák is, hogy eltűnt a polgári központ (ők teljesen máshonnan dolgoznak), és a szomszéd irányítók is észlelik a kapcsolatok megszakadását. Mivel ők sem érnek el senkit sem az irány��tás belső telefonhálózatán sem a vésztartalék vezetékesen/mobilon, ezért nem engednek gépeket felénk, hanem elkezdenek mindenkit elterelni.

A légtérben lévő gépek közben folytatják az utat, amerre eredetileg tartottak, a következő irányítóegység (a szomszéd ország/állam) meghívja őket a vészfrekvencián, és bekéri a sajátjára. Vagy a katonák veszik kezükbe a légteret, és a szomszédokkal lekoordinálva ugyanúgy a vészfrekin mindenkit átküldenek a megfelelő frekvenciára. Radarlefedettség a szomszédos országok felett is van, az irányítók képesek figyelni az elkülönítésekre. De ha nem lenne, a repülőgépeken még mindig ott a TCAS, ami végső esetben segít elkerülni egy ütközést.

A filmben várakozó gépek mit tennének? Szintén vészfrekin megpróbálják elérni a kitérő repülőterükhöz tartozó FIR-t. Ha Budapesten lennénk, akkor jó eséllyel Szlovákiát vagy Ausztriát. Ha alacsonyan vannak és ezért nem tudnak elszólni olyan messzire, akkor mindig lenne valaki, aki egyszerre hallja az adó gépet, és az irányítót is, akit keres, tehát rögtön továbbítaná az üzenetet. A holdingoló gépek lekoordinálják egymással, hogy ki, mikor lép ki a várakozásból, és így minimalizálható a konfliktus. De ugye még mindig ott a TCAS, mint utolsó védőháló.

És az elfogyó az üzemanyag? Dehogy! A repülőgépeket nem csak a célállomásig tankolják meg, hanem kapnak még elegendő üzemanyagot a kitérő repülőtérig, plusz még ~20 percnyit várakozni, plusz még ~45 percnyi végső tartalékot, és a kapitány saját elhatározása alapján tankolhat még ezen felül is. Tehát nem fog lepotyogni senki, ha várakozni kell.

Mondjunk be egy hamis légnyomásértéket, ezáltal földnek megy a repülőgép.

Meglepő módon van ebben ráció, de ebben a rendszerben is annyi safeguard van, ami nagyon minimálisra csökkenti a baleset esélyét. Persze nem nullára.

2022-ben volt egy eset Párizsban, ahol az irányító 1001 helyett 1011 millibár értéket adott a pilótáknak, így a gép kb. 80 méterrel a siklópálya alá került, rossz látási viszonyok között (eső, és a pályafények sem égtek), alig néhány méterrel a föld fölött sikerült átstartolni. Remek cikk született róla az Airbus Safety First-ben. Az Airbus máris kiadott egy szoftverfrissítést, ami bizonyos limitek között képes kiszúrni a feltehetően hibás beállítást.

Ami kivédhet egy ebből származó balesetet, az:

a pilótáknak szóló ATIS (automatikus időjárásjelentés) adásban elhangzó QNH és az irányító által adott QNH összehasonlítása. 1-2 mb változás lehet viszonylag gyorsan, de 10 már nem, hacsak nem minden frontok ősanyja rohant át percek alatt felettünk.

a rádiós magasságmérő figyelése. Ha gyanúsan alacsonyan vagyunk gyanúsan messze, akkor lehet, hogy baj van a beállított légnyomással.

Decision Altitude, az elhatározási magasság. Ha ezen a magasságon nem látjuk a pályát, vagy ránézésre is magasan/alacsonyan vagyunk akkor át kell startolni.

Az ILS használata. Az ILS nem függ a gépen beállított légnyomástól, hiszen a gép a rádiós iránysávot és siklópályát követi ebben az esetben. A példának hozott eseménynél nem ILS megközelítést használtak a pilóták.

Összefoglalva, egyedül a hibás QNH érték adásának van némi rációja a filmben, de szükségszerűen az sem vezetne balesethez, sőt, igen kicsi eséllyel lehetne belőle esemény.