2000. december 11-én tengerészgyalogos katonák tartottak vissza a bázisukra, az Észak-Karolinában lévő New Riveri tengerészgyalogos-támaszpontra. Egy kimerítő gyakorlaton voltak túl, ám aznapra még hátra volt számukra egy eléggé megterhelő túlélő-program: a lezuhanás.
Az őket szállító MV-22 Osprey repülő-helikopter gép már közeledett a bázis felé, így lassítani kezdett. Ekkor önműködően elindult az átkapcsolás repülőgép-üzemmódból helikopter-üzemmódba, aminek pontosan így is kellett történnie. A két rotor-pod hajtómű-gondola szépen fordulni kezdett, ám pont ebben a pillanatban az egyik hidraulika-cső megunta, hogy állandóan dörzsölődik valamihez, és eltört. Ettől az egyik hidraulika-rendszer leállt, de ez még nem lett volna akkora baj, hisz volt belőle tartalék. Érkezett egy vészjelzés a pilótának a csőtörésről és arról, hogy a hajtómű-gondolák köztes állapotban rekedtek. Na innen kezdődtek a gondok.
Világítani kezdett ugyanis a Reset gomb a műszerfalon, amit a pilóta a kiképzésnek megfelelően meg is nyomott. Ez a gomb az elsődleges repülésvezérlő számítógépet (PFCS) indította újra (biztonságos állapotba küldte). Ez bevett dolog volt: ha kigyulladt a lámpa, meg kellett nyomni a gobot. Ez elvileg a félbehagyott üzemmód-váltás következtében félállásban lévő hajtómű-gondolákat is visszaállította volna alaphelyzetbe, de nem ez történt.
Sajnos a gép által kiadott műveletek az egyik oldalon nem haladtak a számítógép által elvárt sebességgel, mert addigra már nem volt elegendő a hidraulika-nyomás. A gép féloldalas lett, de a BAE által fejlesztett szoftver ezzel abszolúte nem tudott mit kezdeni. A Reset gomb nyomogatásának hatására (vagy tízszer megnyomta a pilóta a gombot, mert nem volt foganatja) a rendszer változtatgatni kezdte a rotor-sebességet és a lapátok dőlésszögét, amitől aztán a gép előbb ugrálni, billegni kezdett, majd egy idő után szépen átesett és lezuhant.
Négy tengerészgyalogos halt meg.
A vizsgálat úgy találta, hogy a hidraulika-probléma még nem okozott volna balesetet, ellenben a fedélzeti számítógép szoftverét nem készítették fel egy ilyen szituáció helyes lekezelésére. Ez okozta a gép lezuhanását [Forrás].
Ez az eset is jól mutatja: egy programot a leghatékonyabban elrontani a lehetséges működési üzemmódok és események átgondolásának idején lehet. Amire ilyenkor nem gondol a programtervező, azt később már nem is fogja hiányolni senki – egész addig, míg a kifelejtett szituáció elő nem áll a valóságban.
És ez a legtöbbször csak idő kérdése. Szó szerint.
Enjoy the Silence
A Los Angeles Airport légi irányítói igencsak jól végezték a dolgukat. Ezért a Sors 2004. szeptember 14-én új nehézségi szintre emelte számukra a feladatot, csak, hogy ne unatkozzanak.
Úgy mindenki tud repülőgépet irányítani, hogy lehet a gépekkel rádión beszélgetni, ez túl könnyű. Mindjárt nehezebb lett, amikor este 5 óra körül meglepetésszerűen leállt a teljes hangkapcsolat a földi irányítás és a levegőben lévő kb. 400 repülőgép között.
A hangkapcsolat elvesztésétől persze az irányítók frász kaptak, így gyorsan elindították a tartalék rendszert. Az rendben működött is majdnem egy egész percig, de utána az is feldobta a talpát. Na, innen szép nyerni!
Ezzel elkezdődött a rémálom, ami nem csak a légiirányítóknak adott izgalmas kihívást, de a repülőgépek személyzetének is. Az érkező gépeket más irányítókon át megpróbálták átküldeni máshová, ahol meg elkerülhetetlen volt, ott különféle unortodox megoldásokkal valahogy levezetni őket a földre. A dolog végülis sikerült, de az eset kb. 800 járat útját tette érdekesebbé és változatosabbá.
A hibát egy számláló okozta a kommunikációs szoftverben. Ez a számláló ezredmásodpercenként számolt egyet vissza, s minden ilyen lépéskor egy lekérdezést küldött ki a rendszer a gépek felé. Amíg ez ment, addig minden rendben is volt a hangkapcsolattal.
Csakhogy a számláló 32 bites számábrázolású volt, és a rendszer indulásakor a maximális értékről, 232 -ről indult. Ez több mint 4 milliárd, ami a rendszer tervezői számára nagyon soknak tűnhetett, szinte végtelennek – de közel sem volt az. Másodpercenként ezret csökkenve rajta mindössze csak 50 napon át tartott ki, s mikor elérte a nullát, az időzítő is felhagyott a működéssel, ami a rádiókapcsolat azonnali leállását jelentette.
Tehát szó szerint csak idő kérdése volt, hogy mikor áll le a kapcsolat.
Egy programhibát sokféle módon ki lehet javítani. Ha nem akarjuk a programot módosítani, akkor ott van mindjárt a filozófiai javítás ("végülis ez így is jó, szokd meg"), vagy a dokumentációs javítás ("tényleg nem jól működik, de ezt is leírjuk, tehát tudsz róla - tiéd a felelősség. "). Ebben az esetben az utóbbit választották, és előírták: a rendszert 30 naponta újra kell indítani. Microsoftos módszer, de végülis működik: azóta nincs gond a rendszerrel [Forrás].
Most viszont elevenítsünk fel egy szörnyű tragédiát, melyben –az eddigiektől eltérően – a számítógépek szoftverei rendben tették a dolgukat. Máshol volt a probléma.
A Nagy Dilemma
2002. július elsején a DHL 611-es teherszállító járata és a BAL (Bashkirian Airlines) TU-154-es utasszállító repülőgépe épp Németország felett repült, egymásra merőleges útvonalon, de ugyanazon a magasságon, ráadásul ütköző pályán. A gépeket egyetlen ember, Peter Nielsen irányította Zürihből. A helyzetét nem csak az nehezítette, hogy egyszerre két ember helyett kellett dolgoznia (két monitoron), de ráadásul karbantartás miatt a modern főradar sem állt a rendelkezésére. Így a sokkal lassabb tartalék radaron dolgozott. Ez csak 12 másodpercenként egyszer frissült, ráadásul sokkal több időt és energiát igényelt a használata, így Nielsen erősen túlterhelt volt. Emellett a munkáját akadályozta a telefonvonal is: a fő vonalat szintén karbantartották, a tartalék meg eleve hibás volt. Így mikor egy bénázó gépet kellett kisegítenie, az hosszú percekre lekötötte az irányító teljes figyelmét.
Így fordulhatott elő, hogy Nielsen nem hallotta meg az STCA ütközésre figyelmeztető rendszer riasztását. Ez csak egyetlen egy figyelmeztető hangjelzés volt, amit ha elmulasztott, akkor más (pl. felirat, vagy ilyesmi) már nem utalt a veszélyre. Ezt Nielsen nem hallotta meg, ráadásul, még ha hallotta is volna, a lassú radar miatt akkor sem tudta volna normálisan értelmezni.
A gépek 23:34-kor, kb. 11 ezer méter magasan haladtak egymás felé, amikor felgyorsultak az események. Peter Nielsen észrevette, hogy a két gép ütköző pályán halad. Ezért 1 perccel az ütközés előtt felvette a kapcsolatot a 2937-es járattal, a Tupoljevvel, és utasította a pilótákat, hogy süllyedjenek 1000 lábnyit. Ezzel egy időben mindkét gépen riasztani kezdett az ütközés-elhárító rendszer, a TCAS. A DHL Boeing 757-estének pilótáit a TCAS arra utasította, hogy azonnal süllyedjenek, az utasszállítót pedig arra, hogy azonnal emelkedjen.
Ekkor a DHL gép kapitánya, Paul Phillips meg is kezdte a TCAS utasításának végrehajtását, és süllyedni kezdett. Erről ugyan szólnia kellett volna a légiirányítónak, de akkor Peter Nielsen éppen a baskír géppel kommunikált.
A Tu-154 kapitánya, Александр Михайлович Гросс viszont gondba került: az irányító süllyedésre utasította, a TCAS meg emelkedésre. Melyiket válassza? Ráadásul Nielsen radarja csak lassan frissült, így az irányító nem is tudott róla, hogy a Boeing már süllyedni kezdett. Ezért megerősítette a süllyedési parancsot a Tupoljevnek, Гросс kapitány pedig úgy döntött, hogy az irányító parancsára hallgat, nem a számítógépre.
Rossz ötlet volt.
23:35:32-kor, Überlingen felett a két gép összeütközött a levegőben. Az utasszállítón 69, a teherszállítón két ember volt ekkor, senki sem élte túl a katasztrófát.
Volt még egy áldozat: Peter Nielsen légiirányítót 2004-ben az egyik áldozat rokona meggyilkolta.
A kérdés persze adódik: hol itt a szoftver hiba? Sok dolog mondott csődöt aznap éjjel, de speciel az STCA és a TCAS jól működtek… hát nem egészen. Ezeknek a rendszereknek az volt a feladata, azért voltak ott, hogy az ilyen ütközéseket elkerüljék, és ebben bizony csődöt mondtak. Az STCA jelzése nem volt egyértelmű, a TCAS-t pedig felül lehetett bírálni. A készítőinek talán eszébe sem jutott, hogy lesz olyan öngyilkosjelölt, aki megteszi [Forrás].
Az eset felhívta a figyelmet az ember-gép kapcsolat problémáira. A TCAS következő generációjának tervezése ezért már abba az irányba indult el, hogy az egység szükség esetén automatikusan be is avatkozzon a repülésbe. Ez viszont már azt jelentette, hogy bizonyos esetekben a számítógép felülbírálhatja az emberi döntéseket, életekről döntve.
Nos, ennek a filozófiának az egyik fő képviselője az Airbus. Amikor a vállalat 1978-ban új lendületet kapott, az egyértelmű cél a Boeing megszorongatása volt. Ehhez viszont villantani kellett valami újat, így a cég eleve a fly-by-wire irányába kötelezte el magát. Míg a Boeing esetében a gépet a pilóta vezeti és az elektronika csak segíti a munkáját, addig az Airbusnál a gépet már a számítógép vezeti, a pilóta csak a gépnek ad parancsokat.
Ennek viszont igencsak szigorú feltételei vannak, kezdve az üzembiztonsággal, így az Airbus mindent meg is tett, hogy a gépet irányító főszámítógép nagyon üzembiztos legyen. Többszörözött hardver, mindegyik gépen más-más fejlesztők által írt szoftver futott (elkerülendő az Ariane 5 esetét). Szigorú előírások és vizsgálatok gondoskodtak arról, hogy a számítógép mindig stabilan működjön. És ezt alapvetően sikerült is elérni, de azért voltak apróbb hiányosságok - ahogy a következő, 30 évvel később játszódó történet is mutatja.
Űrhajos-kiképzés
2008. október 7-én a Quantas társaság A330-as gépe az Indiai Óceán felett repült. Az út sokáig nyugodtan telt, ám egyszer csak a robotpilóta váratlanul kikapcsolt. A pilóta érzékelte a figyelmeztető jelzést, és átvette a kormányt.
Ám ebben a pillanatban a gép minden előzmény nélkül zuhanórepülésbe kezdett. Akik nem voltak bekötve, mint például az utaskísérők és az utasok fele, azok repkedni kezdtek az utastérben. Ezt az A330-ast viszont nem űrhajós-kiképző gépnek tervezték, így a viszonylag kemény belső felületei miatt a be nem kötött emberek nem igazán tudták élvezni az átmeneti súlytalanságot.
A pilóta ugyan visszanyerte az irányítást, ám nem sokkal később az eset újra megismétlődött, és megint zuhanórepülést végeztek (hogy aki még nem törte magát össze, annak legyen rá még egy lehetősége). Végül a gép sikeresen leszállt egy közeli reptéren, de a gépen ülő 303 utasból és 12 főnyi személyzetből 101 utas és 9 légi kísérő megsérült. 12 ember súlyosan, 33-an kórházba kerültek.
A dolog egy kettős hibára volt visszavezethető. Az első probléma az volt, hogy a repülőgép három szenzorrendszere (pitot-csöve) közül az egyik bedöglött (elfagyott), és elkezdett hibás adatokat továbbítani a főszámítógéphez. Ez elég ritka esemény, addig mindössze háromszor fordult elő. De azért számítottak rá, a rendszer fel volt készítve, hogy ilyenkor a másik kettőt használja. Legutóbb ugyanezen a gépen ugyanez a hiba nem is okozott problémát, ám most a szenzor nem teljesen leállt, hanem csak hibás adatokat kezdett szolgáltatni. A gép erre rá is jött, mert a másik két szenzorrendszer jól működött. Ám az az algoritmus, amely kiválasztotta, hogy a gép melyik szenzorrendszernek higgyen, el volt fuserálva. Ebben (és csak ebben) az esetben a két jó helyett a rossz rendszer adatait adta tovább, így a gépet a főszámítógép a teljesen rossz adatok alapján kezdte el irányítani – kis színt véve az amúgy unalmas repülőútba [Forrás].
Csak csendben jegyzem meg, hogy nem ez volt az utolsó ilyen jellegű probléma az Airbus gépeken... De most inkább koncentráljunk a lényegre: ki vezeti a gépet?
Légi bemutató extrákkal
A fly-by-wire rendszer egyik fő előnye, hogy lehetővé teszi, hogy a számítógép a pilóta veszélyesnek ítélt parancsait felülbírálja. Ez a lehetőség rengeteg kétséget szült, melyeket enyhítendő 1988. június 26-án az Airbus egy bemutatót szervezett. A tervnek megfelelően az Air France 296-os járata, egy A320-111 repült volna át az utasaival együtt (!) a Mulhouse-Habsheim repülőtér felett, alacsonyan és lassan. Ezzel azt akarták demonstrálni, hogy a rendszer még egészen extrém viszonyok között is remekül irányítható marad. Ez igazából sikerült is: a gép gyönyörűen átviharzott a reptér felett, tényleg nagyon lassan és nagyon alacsonyan. Ám a végén sem emelkedett fel, hanem inkább letarolta az ott álló fákat, majd lezuhant. A gépen ülő 133 emberből hárman sajnos már nem tudtak kimenekülni a roncsok közül.
Ez nem volt jó reklám az Airbusnak, főleg, hogy a vizsgálat során a kapitány a gépet okolta a balesetért: a hajtómű nem reagált a gázadásra, és hiába próbálta megemelni a gép orrát, az sem engedelmeskedett.
Ez rosszul hangzott, de a vizsgálat végül jelentősen árnyalta a képet. Először is: a gép eleve túl alacsonyan és túl lassan haladt. A kapitány és az Air France ugyanis közös munkával összekeverte az angolszász mértékrendszert a metrikussal, így 30 méter helyett mindössze csak 10 méter magasan repültek. A sebesség is túl alacsony volt, a hajtóművek fordulatszáma is. Lényegében az átesés határán repült a gép, amit a kapitány még csak nem is tudott, mert a számítógép észrevétlenül segített rajta. (A kijelzőkön megjelenő magassági- és sebesség-értékeket rendszerhibának gondolta a rendkívül magas IQ-val megáldott pilóta, a hangos figyelmeztetéseket és vészjelzéseket pedig nem hallotta a fülhallgatójától.).
A futópálya végénél aztán a kapitány tényleg gázt adott, de már túl későn: a hajtóművek egyszerűen nem tudtak ilyen gyorsan felpörögni. A kapitány ekkor megpróbálta felhúzni a gép orrát, hogy elkerülje a fákat, de ilyen alacsony sebesség mellett ez a repülő azonnali átesésével (és földbe fúródásával) járt volna. Ezért a számítógép valóban megtagadta a parancsot. Tehát a gép végülis jól tette a dolgát: elsősorban pilótahiba történt. [Forrás]
Ám az eset rámutatott, hogy az Airbus-rendszer sem mindenható. Még teljesen jól működő program esetén is előfordulhat, hogy az ember és a gép valahogy nem tudnak közös hullámhosszra kerülni – s így baleset történik. Ez pedig egy rendkívül komplex problémakör felé vezet minket: a kezelői felület kérdéséhez.
Ez egy rendkívül komoly tudományterület, ahol egész nagy tudományos konferenciákat töltenek meg a kezelő felületek tervezési kérdéseivel és miattuk létrejövő emberi hibák elkerülésével.
A fő gond az, hogy gyakran nem veszik figyelembe az ember tulajdonságait és képességeit – tulajdonképpen nem kompenzálják az emberi gyarlóságot. Márpedig gyarlóság, az akad bőven.
Értelmezés
1992. január 20-án az Air Inter Flight 148 járata, ami egy A320-111 gép volt, épp leszálláshoz készülődött. A cél Strasbourg volt. A leszállás egyik első lépéseként a pilóta úgy döntött, hogy a gépet enyhe, 3,3 fokos süllyedésre utasítja. Ehhez beírta a fedélzeti számítógépbe (FCU - Flight Control Unit), hogy „– 3 , 3 ”, ám ezután nem az történt, mint amit várt; a gép lendületes süllyedésbe kezdett.
A probléma az volt, hogy az FCU nem FPA (emelkedési szög) üzemmódban volt, hanem (valamilyen hiba miatt) VS (függőleges sebesség) üzemmódban. A kapitány ezt nem vette észre, mivel egyrészt nem volt feltűnő a kiírás, másrészt nem tudni, hogy mitől váltott át egyáltalán a program függőleges sebesség-megadási üzemmódba.
A gép minden esetre elfogadta a beírt számokat, de a tizedes veszőt ebben az üzemmódban nem tudta értelmezni, így azt figyelmeztetés nélkül eldobta. Tehát maradt a „-33”, így sikerült a gépet 33 csomós ereszkedési sebességre utasítani. Ez percenként úgy ezer méteres magasságvesztést jelent, ami ugyan nagyon durva süllyedés, de a számítógép még épp elfogadhatónak minősítette.
A repülő tehát majdhogynem zuhanórepülésbe ment át, a kapitány meg versenyt futott az idővel, hogy megértse: mi lehet a probléma. Sajnos kifutott az időből, mivel a szembe érkező Mont Sainte-Odile hegy nem tudott elég gyorsan félreugrani előle. A gép végiggyalulta a fákat, és lezuhant. 87-en haltak meg, csak 6 szerencsés túlélő volt.[Forrás]
Látható tehát, hogy a számítógép teljesen megbízhatóan, stabilan működött, mégis katasztrófa lett belőle. Emberi hiba? Igen, de az emberi hibát a számítógép viselkedése, pontosabban a kezelő felület súlyos hibája váltotta ki.
Azért az igazság és a politikai korrektség kedvéért meg kell jegyezni, hogy a Boeing „csak segíti a pilótákat az elektronika” filozófiája sem mindig működött ideálisan.
Nem vak az, csak bátor
Az Aeroperu 603-as járata 1996. október 2-án éjszaka úgy szállt fel, hogy a pitot-csöveit védőfólia takarta, ezért a fedélzeti műszerek és a fedélzeti számítógép is véletlenszám-generátorként funkcionáltak. Ez egyrészt rengeteg értelmezhetetlen és egymásnak is ellentmondó vészjelzést zúdított az amúgy is túlterhelt pilótákra, másrészt igen nehéz volt ebben a helyzetben megítélni, hogy a sok vészjelzésből melyek kötődnek közös hibához (tehát nem kell velük foglalkozni), és melyek jönnek független alrendszerből (tehát akár igazak is lehetnek). A kormányrázó például önálló magasság-mérőről járt, mégsem vették sokkal komolyabban, mint az összes többi vészjelzést. Ráadásul a földi adatok sem voltak jók, mert azok is a gépről érkeztek – de ezt sem tudta senki, és mivel alapvetően ez alapján dolgoztak a pilóták, halálra voltak ítélve.
A korszerű Boeing 706-os 757-es gép a tengerbe csapódott, mindenki meghalt a fedélzeten.
Az Air France 447-es járatának 2009 május 31-i lezuhanásában is nyakig benne van a túl sok értelmezhetetlen riasztás problematikája, és a pitot-csövek hibája is. De most maradjunk a kezelői felületeknél és az emberi tényezőnél.
Az eset amúgy rávilágít egy nagyon fontos dologra: az emberi döntéshozás működésére. Igen gyakran előfordul, hogy a kezelő emberre egy olyan szerkezet vagy szoftver kezelése van rábízva, melynek működését nem látja át teljes mélységében. A gyakorlatban erre nem is igazán van szükség, mert az esetek 99%-ban rutinfeladatokat kell elvégezni. A rutinfeladat ritkán jelent gondot, mert nincs idő elfelejteni a teendőket, és egyébként is ökölszabályok alapján hozzák meg a kezelők a döntéseket: „Így szoktuk, és jó szokott lenni”. Bevett sémák és rutinműveletek vannak tehát, melyekkel a normál üzem során teljesen el lehet boldogulni anélkül, hogy a rendszer hátterét vagy miértjét a kezelő mélyebben is ismerné.
Ám rendkívüli helyzetben a dolog igencsak megváltozik. Ekkor egy olyan szituáció áll elő, amire nincs bevett séma, nincs ökölszabály. Újat kellene teremteni, ráadásul időre – ehhez viszont szükség lenne az adott rendszer sokkal mélyebb ismeretére. Ami ha volt is valaha, már régen feledésbe merült, és a stressz sem segít emlékezni rá.
Ilyenkor a kezelő vagy lebénul (nem tesz semmit), vagy keres egy olyan ökölszabályt, ami a leginkább alkalmazhatónak tűnik az adott helyzetben, és aszerint jár el. Csak az a gond, hogy az „erős, de legalább nem jó” szabály használata általában teljesen rossz irányba vezet, sokat súlyosbítva az amúgy is problémás szituáción. Egy átgondoltan programozott számítógép ilyenkor sokkal jobb döntést hozhat, mint egy megzavarodott ember – de csakis akkor, ha az adott esetre felkészítették. Tehát sokat profitálhatunk a szoftveres segítségből- ha az a szoftver tényleg jó.
Levezetésként jöjjön még egy rövid bónusz történet.
Fagyi
Nemrég olvastam, hogy a B52-es repülőgépek modernizálása során az amerikai hadsereg úgy döntött, hogy a repülőgép belső kommunikációs rendszerét a Microsoft Windows-alapú Connect szoftverrel oldja meg.
Remélhetőleg jobban sikerül, mint a USS Yorktown esetében…
Ezt a hajót látták el ugyanis elsőként – kísérleti jelleggel – számítógépes irányítórendszerrel, még 1996-ban. Ez volt a „Smart Ship” program, aminek keretében a hajóra telepítettek egy 16 számítógépből álló hálózatot. Ezek a gépek Pentium-pro processzorokra épültek, optikai hálózattal kapcsolódtak egymáshoz, és Microsoft Windows NT 4.0 futott rajtuk. (A képen a híd Smart Ship-termináljai.)
Ez a hálózat vezérelte a híd megjelenítő rendszerét (IBS), a meghajtást és a gépészetet (SMCS), a navigációt (VMS), és még egy sor további alrendszert.
Ám 1997 szeptemberében Cape Charles kikötőjének elhagyása során a rendszer központi adatbázisába véletlenül egy hibás adatot vittek be, mégpedig egy nullát. Egyszerű emberi hiba, ám a rendszer nem volt felkészítve rá. A Remote Data Base Manager ugyanis rövid úton osztani akart ezzel a beírt nullával, ami persze nem sikerült; így hiba keletkezett, ami végül a teljes hálózat összeomlásához vezetett.
A rendszer leállt, vele együtt néhány "kevésbé lényeges" alrendszer is, mint például a meghajtás…
A hajó a hiba következtében 2 óra 45 percre olyan lett, mint a magyar gyorsnaszád: teljesen mozgásképtelenné vált. Még szerencse, hogy épp nem járt arra ellenség.
A következő részben egy olyan esetről lesz szó, amikor egy szoftverhiba szándékosan került a rendszerbe, és okozott katasztrófát.
Titus Pullo Urbino 2012.05.07. 09:19:55
Lakatos Gábor · http://asimov.blog.hu 2012.05.07. 10:00:01
Szoftverfejlesztőként át tudom érezni a probléma gyökerét.
Combat Gear Admin · http://combatgear.blog.hu 2012.05.07. 10:40:04
Egyébként a svájci háza előtt, több késszúrással végzett Peter Nielsen-el. A vallomása alapján nem előre eltervezett gyilkosságról van szó, hanem képeket akart mutatni a halott rokonairól, amit Nielsen kivert a kezéből. Erre Kaloyev bepipult és nem emlékszik mi történt utána.
stoppos76 2012.05.07. 11:58:26
Öcsielvtárs 2012.05.07. 12:34:50
molnibalage · https://militavia.blog.hu/ 2012.05.07. 12:58:21
Az említett légkatasztrófa.
molnibalage · https://militavia.blog.hu/ 2012.05.07. 13:08:47
www.youtube.com/watch?v=SjE-wXC9VOQ&feature=fvst
Asidotus 2012.05.07. 14:37:07
Mindössze egy festés utáni takarófólia el nem távolítása ...
molnibalage · https://militavia.blog.hu/ 2012.05.07. 15:03:21
Munchausen 2012.05.07. 15:09:26
LouiS 2012.05.07. 20:59:21
Tyeplica 2012.05.07. 23:48:45
(A söröket átveheted a múlt hét szombati talin.)
:-D
Almaspite 2012.05.08. 06:42:21
Nekem is bántsa a szemem...
Papírzsepi · http://lemil.blog.hu 2012.05.08. 06:55:15
molnibalage · https://militavia.blog.hu/ 2012.05.08. 08:25:45
www.youtube.com/watch?v=KweY1a6zzjc&feature=plcp
Hiperszuper számítógépek, de az üzemanyagfogyás vs. lerepült útvonalhossz ellenőrzést kézzel kellett csinálni. A 15-30 perces lag pontosan elég volt ahhoz, hogy a kersztbetáplálással kinyomják a kerót a gépből a szivárgás miatt. Ha folyamatosan a gép monitorozta volna a fenti dologt, akkor valszeg nem történt volna meg ami.
wazelin 2012.05.08. 09:26:05
Amúgy most olvatam, hogy Nevadában engedélyeztek a Google sofőrnélküli autójának használatát, igaz, kell, hogy üljön benne "sofőr".
stoppos76 2012.05.08. 11:52:24
Kinai cuccok blog · http://kinaicuccok.blog.hu 2012.05.08. 16:28:16
wazelin 2012.05.08. 17:14:53
zum trucc 2012.05.08. 18:15:00
Szerintem Papírzsepi direkt írta ezt a kis viccet bele, hogy lássuk, az emberi figyelem határait.
Amúgy a cikk igen kiváló.
@Kínai cuccok tesztje: állítólag az Osprey a sok, a fejlesztési időre eső súlyos baleset, a jelentős költség- és fejlesztésiidő-túllépés ellenére még hadrendbe állítása előtt megbízható, használható géppé vált. Végülis, egy tényleg újszerű műszaki megoldás.
Tyeplica 2012.05.08. 18:37:47
Papírzsepi · http://lemil.blog.hu 2012.05.08. 20:12:27
Sajnos az igazán jól megcsinált programok nyers adatok feldolgozásában mindig előnyben lesznek, főleg az olyan szórakozott alakokkal szemben, mint pl. én...
Jól megcsinált program például a .... a .... öö .... szóval a .... na mindegy. Most nem jut az eszembe.
radeon5 2012.05.08. 23:13:29
Esetleg csak konvergalhat afele...vagy nem ;)
folti_ 2012.05.09. 10:21:50
Papírzsepi · http://lemil.blog.hu 2012.05.09. 10:29:19
Szerintem megérne egy külön posztot a Lemilen ez a fejlesztésnek nevezett vicc, amit bemutattak.
Molnibalage-t kellene valahogy megvesztegetnünk, hogy írjon róla....
Jockey11 2012.05.09. 10:46:52
Csak egy megjegyzés: Peter Nielsen szerepét a nyugati sajtóban szokás egy kissé alábecsülni az überlingeni katasztrófa kapcsán. Ugyi a baleset után (még a vizsgálatok megkezdése előtt) mindenki kijelentette, hogy lám már megint a hülye oroszok nem tudnak repülőt vezetni, és emiatt emberek halnak meg! (Mondjuk mindenki mentségére szolgáljon, hogy ez a kijelentés az orosz polgári és katonai repülés történetének ismeretében "nem volt teljesen légből kapott") Aztán kiderült kettő dolog:
1. a baleset pillanatában pontosan három azaz 3 gép tartózkodott a Nielsen által felügyelt teljes légtérben, melyből ugye kettőt sikeresen egymásnak irányított,
2. ha az égvilágon semmit sem tett volna, akkor nem következik be az ütközés.
Jock
Ui.: Pm-et szokott olvasni?
molnibalage · https://militavia.blog.hu/ 2012.05.09. 23:43:34
@Jockey11: Neki senki nem szólt arról, hogy a TCAS mást mondott.
A mindenki meg erős túlzás...
folti_ 2012.05.10. 10:20:59
Amúgy pocsék UI-re visszatérve, ez a baleset is megér egy misét: en.wikipedia.org/wiki/Aeroflot_Flight_593
Az autópilóta bizonyos funkciói autómatikusan kikapcsoltak, ha valaki(a kapitány fia) megpiszkálja a kormányt, de erről semmilyen hangos figyelmeztetés nem érkezik...
Jockey11 2012.05.10. 11:34:30
A mindenki alatt a teljes mainstream médiát értem, tehát mindenkit, mert az egy világjelenségre példa, hogy az esti RTL híradót kb. 2 millióval többen nézik meg, mint ahányan "a maga nemében páratlan" esszéket olvasnak. Sajnálom, hogy ilyenek az arányok, de hát ezzel együtt lehet élni.
Münci66 2012.05.10. 13:13:46
Csak némi -nem szakértői, csak érdeklődői!- kiegészítés a DHL vs BAL ügyben. A közforgalmi pilótának jelzés esetén a TCAS parancsait_KELL_követnie, bármit is mond az irányító. Ennek oka tudtommal az, hogy a TCAS-ok le meccselik egymással, ki merre menjen. A régi szovjet -főleg a katonai- elv szerint viszont az irányító az úr! Ez alaposan be volt vésve a baskír gép pilótájába, sajnos.
A kommunikáció sem volt tökéletes, ebben is szerepet játszhattak a rossz beidegződések.
Tisztelettel, Münci
tudi 2012.05.10. 15:02:49
molnibalage · https://militavia.blog.hu/ 2012.05.10. 19:01:55
Szerencsétlennek szólni akart más is, de a rendszer egyes elemeit folyamatosan lőtték le a karbantartók.
Miért nem a pilóta akkor a hibás? Miért gondolta azt, hogy a TCAS-t felülbírálhatja az irányító? Volt erre vonatkozó szabály? Ha igen, akkor ki felejtette el? Ha nem, akkor meg szitén nem tehet róla egyik fél sem. Nem tisztázott hézag volt a rendszerben.
Jockey11 2012.05.10. 21:34:05
Jockey11 2012.05.10. 21:48:21
Azt meg azért TCAS mentén se felejtsük el, hogy viszonylag rövid történe egyébként nem volt mentes a fals riasztásoktól.
folti_ 2012.05.10. 22:49:58
Maga a gépeken lévő TCAS is hiányoságokkal küzdött, mivel még nem volt kötelező TCAS riasztásokat az ATC felé is közvetítő modul (nem mintha a földi berendezések hiányosságai miatt ez segített volna), illetve nem volt képes arra, hogy a hirtelen megváltozott forgalmi helyzet alapján(másik gép nem/rosszul reagált a TCAS utasításaira) új utasításokat adjon.
folti_ 2012.05.11. 09:02:44
molnibalage · https://militavia.blog.hu/ 2012.05.11. 10:06:56
folti_ 2012.05.11. 10:37:30
Meg mert eredeti TCAS változatot a 80-as évek technikai szintjéhez tervezték ami miatt tele van limitációkkal (pl simán adhat olyan utasítást ami terepakadályba, vagy max repülési magasság fölé vinné a gépet), míg nagyforgalmú helyeken ígyis kitöltik a rendelkezésre álló frekvenciasávot az egymással beszélgető gépek. Megmivel a TCAS lelke is csakegy számítógép, azért azt a fejlesztést is meg kellene tervezni, irni és kidebugolni. Plusz addig, amig az ATC felé nincs meg mindenhol TCAS saját kommunikációja, addig extra zűrzavarhoz vezetne megadott útvonaltól elkolbászoló gép. Vagy balesetekhez, a nagyforgalmú helyeken.
Jagohu · http://www.eurocontrol.int 2012.05.12. 13:32:04
Überlingen:
"Így fordulhatott elő, hogy Nielsen nem hallotta meg az STCA ütközésre figyelmeztető rendszer riasztását."
-A tartalék rendszeren (és nem radaron) amin az irányítónak dolgoznia kellett NEM állt rendelkezésre ez a feature (STCA, short-term conflict alert, ami általában azelőtt jelez valamennyivel, hogy két gép az előírt minimumnál közelebb kerülne egymáshoz), NEM VOLT semmiféle riasztás, sem hanggal, sem vizuálisan.
-A Baskír Tupoljevet nem 100, hanem 1000 lábbal való süllyedésre utasította
-Az oroszok folyamatosan látták (a CVR felvétel szerint) a DHL 757-est a TCASen, és fél percen belül kétszer(!) fordultak el jobbra egyenként 10 fokot,(ami az előírás VIZUÁLIS, azaz VFR repülésnél a másik elkerülésére - de az utasszállítók mindig IFR azaz műszer szerint repülnek, és ez kötelező, nem választható) amely aztán annyit jelentett, hogy mivel balról közelített a keresztező forgalom, ezért pont belefordultak. Ha tartották volna az előírt, eredeti irányt akkor hozzávetőlegesen 2 tengeri mérfölddel (kb. 3.6 km) mennek el a 757es mögött - ami szintén a minimum elkülönítés alatt van, de mégis jóval több mint ami kell egy ütközéshez...
Ez az adat a FDR (fekete doboz) és a radar felvételek alapján került felszínre és valahogy nem került bele az újságokba.
@Jockey11: a kulcsszó a történetben nem az, hogy 3 gépből kettő egymásnak ment. A kulcsszó az, hogy dolgozz egymástól 5 méterre levő képernyőkön úgy, hogy az egyiken levő egy gépet (ami nem egy "béna" gép volt, hanem egy későn érkező Airbus Friedrichshafenbe) a leszálláshoz való bevezető egyenesre kellett irányítani (approach), majd mielőtt átadta volna a toronynak, előtte KÖTELEZŐEN telefonon egyeztetni erről (ami a nem működő telefonrendszer miatt lehetetlen volt, de erről az irányító nem tudott).
Megkérném, hogy ne szakértsen annyira olyan témában, amihez ennyire nem ért. Köszönöm.
PS: egyébként nagyon szeretem a blogot, meg az itt megjelenő publikációkat, szóval így tovább!
Hiryu 2,0 · http://theidf.blog.hu/ 2012.05.12. 14:17:34
iho.hu/hir/nem-lesz-oriasi-egi-lezer-120306
xylon 2012.05.12. 14:43:40
Jockey11 2012.05.12. 16:13:36
1. Nem hiszem, hogy bárhol látta volna leírva, hogy szakértőnek mondtam volna magam bármely témában, itt vagy bármely más kommentemnél, esetleg valamelyik cikkemben.
Illetve láthatott tőlem ilyen megnyilvánulást, de az olyan régen volt, hogy arra nem hinném, hogy rajtam kívül bárki emlékezne. Meg aztán az olyan téma volt, ami viszont az én szakmámba vág és az biztos, hogy nem a repülés, ami iránt valóban csak amatőrként érdeklődöm.
2. Az viszont igaz, hogy a józan paraszti eszet mindennél többre becsülöm, aminek többször hangot is adtam. Ezért van az, hogy nem értem (most sem) hogyha az Új-Delhi esetnél a légiirányító mindkét ütköző pályán haladó gépet figyelmeztette a másikra, akkor ez ebben az esetben miért nem történt meg. Azt Ön tudja, hogy van-e ilyen előrírás vagy nincs, mindenesetre számomra ezt lett volna a logikus lépés, és - a nevezetes történelmi "ha" szerint - még az is lehet, hogy ebben az esetben nem történik meg az ütközés.
Jockey
Ui.: 3. Amatőrként olyan dolgokról valóban nem tudok számot adni, ami egyébként soha nem került nyilvánosságra.
Jagohu · http://www.eurocontrol.int 2012.05.13. 00:43:47
molnibalage · https://militavia.blog.hu/ 2012.05.13. 09:35:11
Rosszindulatú Vászka 2012.05.13. 20:18:17
Ezek szerint a légiirányító mindkét gépet süllyedésre utasította nem? Akkor mégicsak ő nézte be? Ha nem biztos benne, hogy az egyik pilóta végrehajtja az utasítást, akkor miért kéri a másiktól is, hogy süllyedjen? Nem az a logikus, hogy az egyik magasabbra, a másik méklyebbre, és ha az egyik nem csinál semmit, még mindig túlélik?
Nem állítok semmit, csak kérdeztem.
xylon 2012.05.13. 21:58:55
A kovetkezo szivasok voltak a rendszerben:
-A baskirok megprobaltak "elevagni" vizualis iranyitassal a DHL gepnek, ezt mondjuk abszolut nem ertem.
-Az elvileg redundans rendszerek egyszerre doglottek meg es voltak karbantartva.
-Egy masik legiiranyito eppen szunyalt a szomszed szobaban.
-A legiiranyito csak az egyik felet utasitotta (az most mindegy hogy hogy).
-A baskirok az automata helyett a legiiranyitot kovettek, annak ellenere hogy tudhattak volna hogy az automata a masik gepet veluk ellentetes utasitassal latta el.
Akarhogy is nezem itt a DHL gep pilotai az egyetlen artatlan bagazs.
Rosszindulatú Vászka 2012.05.14. 06:42:49
Sztem nem kéne a baskír pilótát hibáztatni, sok más szituációban meg lehet, hogy pont azért nincs katasztrófa, mert a légiirányítónak hisz és nem a gépeknek (lsd. a sorozat többi darabját).
Csak egy kérdés a végére apróbetűvel: csak engem zavar, hogy Tupolev és nem Tupoljev? Nem ügyrendi kérdés természetesen.
Jockey11 2012.05.14. 17:49:27
Ne zavarjon, mert ha "Андрей Николаевич Туполев"-ről beszélünk, akkor a nevét fonetikusan Andrej Nyikolajevics (és nem Nyikolaevics) Tupoljev-nek írjuk, és még véletlenül sem Tupolevnek, mint az angolszászok.
Az orosz ugyanis két "betűt" használ a kemény "Э" (pl.: электроника - ami nincs az orosz gépekben) felel meg a miénknek, míg a lágy "е" kiejtéskor legtöbbször egy "j"-vel együtt áll. Lásd. emberünk apai nevét középütt.
Rosszindulatú Vászka 2012.05.14. 18:30:10
Továbbá napjainkra egyre káoszosabb a cirill, kínai, japán (itákdálse) nevek magyar átiratai is. Ami azért mókás, mert pl. akár egy kínai helyszín másképpen néz ki, ha német, másképpen , ha angol nyelvből kopipazstázázk a hírt a rátermett bölcsészek.
Ez például akkor okoz gondot, ha Viszockíjt gúglizok (ez is milyen szép magyar szó).
Alapvetően meg nem akarnám ezzel a valóban kicsinységgel azt a látszatot kelteni, mintha elégedetlen Lemil-olvasó lennék. Amúgy meg lehet simán elütés is, azt meg nem elegáns dolog firtatni.
Papírzsepi · http://lemil.blog.hu 2012.05.14. 21:03:41
Eredetileg jól írtam a Tupoljevet. Aztán elbizonytalanodtam, és kijavítottam. :(
Na mindegy, most vissza-korrigáltam, ne maradjon így.
(Meg a 100 láb is 1000 lett, bár szinte 0 a különbség...)
Rosszindulatú Vászka 2012.05.15. 07:33:43
A német meg lengyel átirat meg Tupolew, szóval nagy itt a diverzió. Bezzeg a ruszkik pont szarják le az egészet és minden latin betűs nevet fonetikusan írnak át, na azt nagy cselendzs sokszor kisilabizálni, hogy kiről is beszélnek.
Ahzazhogy ezzel nem kell foglalkoznod, leginkább ki kell várni, amíg a Tudomány oda fejlődik, hogy lesz egységes cirill-latin-ésatöbbi átirat, mert jelenleg még nincs. Mókás dolog ez a multikulti.
Szakmailag ennyit tudtam hozzátenni az amúgy érdekes poszthoz, hogy kicsit grammárnáciztam, de leginkább diverzáltam csak :)))
pooh_aki_pooh_volt_a_regiszt_elott 2012.06.08. 14:48:53
a tudomány (vagyishogy a publikációk) pontosan ettől elfelé fejlődik. régen ugyanis pont hogy egyértelműbb volt minden. ma viszont minden botcsinálta "szakértő", sőt még a tényleg komoly szakértők is mindent angolból leforditva szakértenek. hiányoznak azok, akik nativ forditóként tudnák terjeszteni az igét.
egy másik bosszantó dolog, hogy ezzel gyakran átveszik az angolszász szemléletet is, nagyban torzitva a dolgokat.
bocsi, ez csak úgy kikivánkozott :-)))
a poszt meg tetszett :-)))
David Bowman 2012.07.23. 07:52:53
David Bowman 2012.07.23. 07:57:36
folti_ 2012.07.23. 11:33:01
folti_ 2012.07.23. 11:39:46
David Bowman 2012.07.23. 11:43:48
folti_ 2012.07.23. 22:28:36
Minden éppen rádióra nem reagáló gépre meg nem költséghatékony emelni a vadászgépeket, mert esetleg két perc múlva kiderül hogy semmi baj, csak a kapitany a wc-n ült, míg a másodpilóta esetleg aludt... Sajna ebben az esetben is igaz, hogy a légierő nem mágikus mindentmegold gomb, legjobb esetben csak ők is, csak információforrásokként léphetnek fel az utólagos vizsgálatok folyamán.
Hamár piros telefonmokról van szó, 9/11 -et az akadályozhatta volna meg, hogyha Bushék nem töketlenkedik el a különféle szolgálatok közti együttműködést. Majdnem minden információ megvolt, csak különféle szolgálatoknál és aki tehetett volna érte valamit az bagzott ra. Bush külön jelentést kapott, amit nem olvasott el, hanem lelépett golfozni.
David Bowman 2012.07.25. 08:11:50
A perui gép vagy 1 órát töketlenkedett, és végül azért zuihant le, mert nem tudta a pilóta sem a sebességet, sem a magasságot. Tiszta sor volt, hogy kurvanagy bajban van. Rá kellett volna küldeni 1 vadászt, de azonnal.