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, 2³² -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.