Szoftverhibákkal már mindenki találkozott, aki valaha is bekapcsolt egy számítógépet. Sőt, a programhibákra gyakran már csak legyintünk, annyira megszoktuk már őket. A legtöbb esetben legfeljebb enyhe gutaütés kerülget minket miattuk – ám bizonyos esetekben ennél sokkalta súlyosabb következményekkel kell szembe néznünk.

A most induló pár részes sorozatban olyan esetekről fogok mesélni, amikor a sok egyes és nulla nem megfelelő együttállása rengeteg sok pénzbe, vagy éppenséggel emberéletekbe került. Szó lesz majd katonai és polgári szoftverek hibáiról, rakétákról, röntgengépekről és persze repülőgépekről is. Az ismertebb, érdekesebb eseteken át megpróbálom majd azt is megvilágítani, hogy miért olyan nehéz hibátlan programot írni. De azért nem kell megijedni: inkább csak mesélni fogok, hogy mindenki borzonghasson egy kellemeset. Mindemellett azoktól, akik a megfoghatatlan szoftverek helyett inkább a nagyon is megfogható páncélosokról, vagy épp a kivont karddal vágtázó hősies huszárokról akarnának olvasni, ezúttal türelmet kérek. Itt most csak katasztrófa lesz, halál, és persze a láthatatlan bűnös…

Apropó, ha már vágtázó lovaknál tartunk: csapjunk is mindjárt közéjük!

Induljunk talán az alapoktól: nyugodtan kijelenthetjük, hogy olyan értelmes funkciót végrehajtó program, mely teljesen hibátlan és mindenre 100%-ban fel van készülve, nem létezik. De miért?

Mikorra a számítógépek mérete, és ára olyan szintre csökkent, valamin a megbízhatóságuk olyan szintre emelkedett, hogy beágyazott alkalmazásokban (tehát valaminek az irányítására, vezérlésére) is felhasználhatóvá váltak, a rajtuk futó programok bonyolultsága és mérete már meredek emelkedésben volt. A tipikus programok már az 50-es éve végén sok ezer programsorból álltak, a hatvanas évekre pedig több tízezer soros programok készültek. Csak az összehasonlíthatóság kedvéért: egy 100 ezer sorból álló program kinyomtatva kb. akkora lenne, mint a Háború és Béke. És bizony ebben a „könyvben” elegendő egyetlen egy elhibázott betű, egyetlen elütés, és kész is a baj.

Irány a zűr!

1962. július 22-én indult útjára az amerikai Mariner program első rakétája. Addigra a NASA már komoly tapasztalatokkal bírt a szoftverek és a rakétavezérlés terén, tehát a dolog sima ügynek tűnt. Már csak azért is, mert a Mariner 1 rakétájának vezérlő számítógépe a programmal együtt már bizonyított: ez már a második küldetése volt.

A Mariner 1 célpontja eredetileg a Vénusz volt, de odáig a szonda már nem jutott el: 4 perc repülés után a rakéta meglepetésszerűen letért a tervezett útvonalról, így 294,5 másodperccel az indítás után, tehát reggel 9:26-kor aktiválni kellett az önmegsemmisítő rendszerét.

A jó hír, hogy az legalább működött; de azért ezt nem ennyire optimistán fogták fel. Vizsgálat indult, mely hamar kiderítette, hogy a pályaelhagyás közvetlen oka egy szoftver hiba. Bár a helyzet ennél kicsit bonyolultabb volt.

Akkoriban a rakétákat rádión, a Földről kormányozták. Tehát a földi (jól programozott) számítógépek továbbították a teendőket a fedélzeti számítógépnek, ami csak végrehajtó volt. Így működtek az Atlas repülések is, és akkor minden rendben is volt. Csakhogy a Mariner 1 esetében volt még egy hiba: az antenna sem állt a helyzet magaslatán, így a vett jel gyenge volt és zajos. Emiatt ahogy a rakéta távolodott, egy idő után már kihagyások is előfordultak a jelfolyamban, míg végül az egyik ilyennél a fedélzeti számítógép úgy döntött, hogy átkapcsol „önjáró” üzemmódba. 

Csakhogy a fedélzeti számítógép programja el volt rontva. A programot ugyanis eredetileg kézzel, papírra írták le (1962-ben vagyunk!!), majd onnan hard-kódolták be a pályavezérlő számítógépbe.  Eközben sikerült egy felülvonást kifelejteni a programból, ami vagy a hardkódolásnál, vagy az előző (szintén kézi, papír-papír) másolásnál tűnt el. Akárhogyan is történt, a lefelejtett felülvonás egy átlagolást vett ki a rendszerből, amitől a program viselkedése alapvetően változott meg a tervezetthez képest: aktiválódásakor a rakétát azonnal letérítette a helyes útvonaláról. [Forrás]

Megjegyzés 1: én még úgy tanultam, hogy a szoftvert FORTRAN nyelven írták, ahol bizonyos szituációban a pont és a vessző összekeverése szintaktikailag helyes, de teljesen máshogy működő programot eredményezhet. És eredményezett is. Ám a valóságban ez a hiba nem a Mariner 1-nél, hanem a Mercury projecben fordult elő; de még idejekorán kijavították. 

Megjegyzés 2: Sok évvel később, 1991. július elsején ugyanilyen jellegű hiba miatt állt le Washington DC, Pittsburgh, Los Angeles és San Francisco teljes telefonhálózata. A központokat kezelő System 7 program közel tízmillió programsorának egyikében volt egy apró elírás, ami egy speciális (de amúgy simán kezelhető) szituációban szépen fejre állította a teljes szoftvert úgy két napra.

Ezzel meg is ismerkedtünk a programhibák első okával: az egyszerű elírásos hibával. Természetesen az ilyen elég nehéz védekezni, de nem lehetetlen. Olyan programnyelvekre és fordítóprogramokra van szükség, melyek segítenek minimalizálni a hibákat. 1962-ben a körülmények még nagyon spártaiak voltak, még igazán hatékony és elterjedt programnyelv sem volt, nemhogy grafikus modellező eszközök – de már az úttörők dolgoztak az ügyön, sorra keletkeztek az újabb és újabb programozási nyelvek.

Közben a számítógépek teljesítménye igencsak lendületesen nőtt, és vele együtt a programok komplexitása is meredek emelkedést mutatott. A hetvenes évekre a szoftver-bonyolultság kezdte elérni azt a szintet, ahol az emberi agy már nem igazán képes a feladattal megbirkózni, tehát egyszerűen nem lehet átlátni a működést. A korabeli szoftvertervezési (támogató) eszközök meg nem sokat segítettek a lelkes programozóknak. Ez a szoftverek minőségének igen gyors és látványos visszaesését okozta, melyre „Szoftver krízis” néven hivatkozik a számítástechnika-történet. 

(Az ábrán egy viszonylag egyszerű program vizualizációja látható. Egy spéci programmal úgy próbálták ábrázolni a szoftvert, mintha az egy gyár lenne. Átlátható? Nem igazán? Na, ugye.)
Az elméleti módszerek és háttér hiánya, valamint a kezdetleges körülmények miatt sok igazán pocsék minőségű szoftver született ez alatt a pár évtized alatt. Az ezek közül is kiemelkedő gyöngyszemekről még lesz szó bőven, de illusztrációként most elevenítsünk fel egy katonai-vonatkozású esetet: az 1970-es években fejlesztett (illetve akkor kezdték a fejlesztést) MIM-104 föld-levegő rakétarendszer szoftver-problémáját. Ami – stílszerűen fogalmazva – egy időzített bombaként ketyegett évtizedeken át, mígnem…

A Pontatlan Patrióta

1991 februárjában épp javában dúlt a Sivatagi Vihar hadművelet. Az amerikaiak próbálták a stratégiai fontosságú objektumokat megvédeni, az irakiak pedig ezeket támadták. Ilyen objektum volt a Saud Arabiában található Dhahran repülőtér, melyet a U.S. Army a jól bevált légvédelmi fegyverrel, Patriot rakétákkal igyekezett védeni. Ugyanezek a rakéták vigyáztak a reptér mellett álló laktanyára is, nehogy valamilyen levegőből érkező meglepetés gondot okozzon.

Ám –hogy ismét csak stílszerű legyek- homokszem került a szerkezetbe. 25-én ugyanis egy Scud rakéta tervezte meglátogatni az ott állomásozó katonákat (nem igazán baráti látogatás keretében), amire a Patriotnak bizony ugrania kellett volna. Ám a fegyver nem tett semmit, így a Scud mindenféle feltartóztatás és kopogtatás nélkül érkezett meg egy barakkba. Kirobbanó sikere volt: 28 amerikai állampolgár veszítette életét aznap, és 98-an megsérültek.

Persze azonnal vizsgálat indult, ami hamarosan meg is találta a hibát a Patriot radarrendszerében.

A fegyver ugyanis három működési fázisban dolgozott. Az első fázis a keresés volt, amikor is az eget kémlelve olyan repülő alakzatokat keresett, melyek sebességben, alakban, repülési magasságban, stb. hasonlítottak a célpontra. Ha talált ilyet, akkor jött a második fázis. Ebben a lépésben kiszámolta, hogy a célpont hová tart és milyen gyorsan halad, így meghatározhatta, hogy hogyan kell a célkövető radart beállítani az ellenség fogadásához. A harmadik fázisban pedig a célkövető radar karjaiba futó repülő ojjjektum felé elindultak a rakétát. Ezen a napon viszont csak indultak volna, ha a már a második fázisnál nem rontotta volna el a számításokat a program.

A Patriot rakétákat eredetileg hidegháborús eszköznek szánták, így a fegyver szovjet atomrakétákra volt optimalizálva (melyek MACH2-vel mentek), és csak pár órás üzemet kellett kibírnia (utána úgyis mindenki meghalt volna). Ám később átalakították, és folyamatos védelemre kezdték használni, mégpedig Scud rakéták ellen – melyeknek MACH 5 az utazósebességük. Ezért kicsit módosítani kellett a Patriot vezérlőszoftverét, de mint kiderült, ezt nem kellő mélységig tették meg.  

A gond a szoftver sebesség-mérő rendszerével volt. Ez a program méri az időt, és a célpont előrehaladásából számolja a sebességet, majd abból az érkezési helyet a célpontkövető radar beállításához. Ám a programban a belső számábrázolási rendszerek keveredtek, így folyamatos átalakítgatásra volt szükség. Ez még nem lenne akkora probléma, ám ezt a feladatot igénytelenül oldották meg a programozók, így az időt csak jókora kerekítési hibával tudta mérni a szoftver. De még csak nem is ez volt a fő gond, hanem az, hogy ez a kerekítési hiba a működés során halmozódott. Így 8 órányi folyamatos futás után a felhalmozott időmérési hiba miatt már teljesen rosszul számolta ki a program a rakéta sebességét, emiatt azt is, hogy hol kell majd keresnie a célkövető radarnak. Az tehát „váratlan” helyen megjelenve átjuthatott a védelmen.

Ezt a hibát az izraeliek már korábban érzékelték: a tesztek során úgy találták, hogy a Patriot rakéta nyolc órányi folyamatos üzem után már csak 80%-os találati aránnyal dolgozott (a közvetlenül indítás utáni szinthez képest). Ezt jelezték is a U.S. Armynak még 1991. február elején, hozzátéve, hogy a Patriotokat maximum 8 óránként újra kell indítani. Ennek ellenére a Dhahrant védő eszközökben a Scud érkezésekor már kb. 100 órája futott a szoftver. A felhalmozott időmérési pontatlanság ekkorra már 340ms volt, ami miatt a követő radar úgy 680 méterrel odébb várta a rakétát, mint ahol az megjelent – ezért nem volt képes befogni azt.

Amúgy a hibát az izraeliek figyelmeztetése után, február 16-án kijavították az amerikaiak, de a szoftver-frissítés csak február 26-ra ért el a Dhahrani bázisra. [Forrás]

Már a szoftver krízis elején, 1976-ban feltűnt a DoD-nak (Department of Defense), hogy feltűnően sokat költenek szoftverekre. Abban az időben a fegyvereknek még csak mintegy 20%-át vezérelte számítógép, de félő volt, hogy ha ez az arány nőni fog (márpedig nőtt is, nem is kicsit), akkor előbb-utóbb finanszírozási problémákba fognak ütközni. Végeztek hát egy vizsgálatot, ami meglepő és rémisztő eredménnyel zárult. Kiderült, hogy a hadsereg által kifizetett szoftverek 80%-a csúszott meg az időben vagy a költségvetésben, a programok fele (!) pedig egyáltalán nem készült el. Vagy ha is készült, akkor sem volt sem használható, sem javítható. [Forrás]

Csak egy példa: a U.S. Stratégiai Légiparancsnokság 465L rendszerében még 12 évnyi üzemeltetés és fejlesztgetés után is átlagosan napi egy szoftver hibát találtak; de említhetnénk a haditengerészet Aegis Combat System-jét is, aminek kalandjairól külön posztot lehetne írni (mégpedig vérrel).

A polgári programoknál sem volt jobbak az arányok, a denveri repülőtér szép új automata poggyászkezelő rendszerét például csak laza egy év csúszással tudták működésre bírni a szoftver hibái (minőségi problémái) miatt; és még hosszan sorolhatnám.

Ez óriási pénzkidobás volt, melynek okaként a vizsgálat két fő dolgot azonosított:

• 450 féle programnyelvet használtak a hadsereg szoftvereinek megírásához, melyek között semmilyen átjárás nem volt. Ezért mindenki minden programot nulláról kezdett el, az egyszer már sikeresen kifejlesztett programrészeket nem lehetett újra felhasználni. Tehát mindenki elkövette ugyanazokat a hibákat újra és újra…
• A programozás mindennemű módszertan nélkül zajlott, ahogy esik, úgy puffan alapon. (A legismertebb példa, igaz, a polgári világból: Az IBM System360 oprendszerét úgy írta több száz programozó jó tíz évig, hogy nem is volt hozzá semmilyen kiindulási terv.)

Na, ez így nem eléggé katonás, rögtön hoztak is egy sor intézkedést. Előírták, hogy attól kezdve mindenki ugyanazon az egy nyelven programoz, mégpedig ADA-ban – amit kifejezetten különféle rendszerek és gépek irányítására fejlesztettek ki. (A nyelv neve amúgy tisztelgés a világ első programozója, Ada Byron előtt.) Továbbá a már megírt és bevált programrészeket újra fel kell használni, ahol csak lehet; így nem kell mindig mindent elölről kezdeni. Lesz itt rend, kérem!

Hát, valóban elég katonás megoldás volt, nem vitás: szép szögletes. Később sokat finomítottak rajta, én viszont most gonosz leszek: lássuk, hogy mi lett az eredmény!

A határértékig, és azon is túl

1996. június 4. A vadiúj, csilli-villi Ariane 5 rakéta startra készen magasodott az indító állványon. Fedélzetén négy Cluster műhold várta a fellövést, bár az időjárási viszonyok nem voltak teljesen ideálisak. Ennek ellenére a szakemberek a kilövés folytatása mellett döntöttek, így a 737 tonnás rakéta a tervezett időpontban a levegőbe emelkedhetett.

A repülés első 36 másodperce remekül ment, ám ezután kezdődtek a bajok. 36,7 másodperccel a kilövés után a rakéta tartalék IRS-e (Inertial Reference System) hibát jelzett, majd leállt. Ez még talán nem is lett volna akkora gond, de 0.05 másodperccel később az aktív IRS is hibát jelzett, majd az is újraindította magát. Ettől kezdve viszont már sejthető volt, hogy sokak napja bizony alaposan el lesz rontva.

A rakéta pár pillanattal később éles fordulóba fogott, letért a pályájáról, majd szétesett. Az automatikus önmegsemmisítő rendszer már csak a kegyelem-döfést adta meg, a rakéta menthetetlen volt. Ezt még a magyar kormány sem tudta volna sikerként kommunikálni. A kár: fél milliárd dollár, amivel az IRS-ben megbújó szoftver hiba kiérdemelte a „minden idők egyik legdrágább szoftver hibája” megtisztelő címet.

Hogy megértsük, hogy mi történt, meg kell kicsit ismerkednünk a rakéta irányító rendszerével.

Az Ariane 5-t egy nagyteljesítményű fedélzeti számítógép vezérelte, melynek programja lényegében vadonat új volt. Ám a programozás során úgy döntöttek, hogy az IRS funkcióit kezelő programrészt nem integrálják be a főszámítógép programjába, hanem inkább egy-az-egyben átemelik az Ariane 4-ből az ott alkalmazott, jól bevált, rendkívül megbízható szoftvert, és mind adatforrást csatolják a főszámítógéphez. Ez az ADA nyelvű szoftver akkor már tíz éve szolgált hibátlanul, rengeteg funkciója volt, de ebben a felállásban már csak egyszerű adatforrásként használták; a belső funkcióinak nagy részét nem vették igénybe.

A rakétában minden redundáns volt, így az IRS-ből is kettő került bele: egy aktív és egy tartalék. Mindkettőn ugyanaz a program futott. Ez nem volt igazán jó ötlet, de mivel a rakéta építésénél egyáltalán nem számoltak szoftver hibákkal, így nem is tűnhetett ki senkinek a két egyforma program problematikája: ha az egyik példány szoftver hiba miatt elkezd hibásan működni, akkor a másik is pontosan ugyanezt fogja tenni. Tehát a redundancia nem véd a programhibák ellen. 

Volt még egy hiba, amit elkövettek a tervezők: nem ellenőrizték le, hogy az IRS milyen működési tartományok között (vízszintes gyorsulás, függőleges gyorsulás, stb.) képes működni. Pedig a programhoz minden dokumentáció rendelkezésre állt, ezek az adatok is. Ám mindenki meg volt győződve róla, hogy a programrész már sokszor bizonyított, „tutira jó”.

Csakhogy az Ariane 5 gyorsító rakétái jóval erősebbek voltak, mint az Ariane 4-é. Ezért a rakéta más pályán repült, így mások voltak a gyorsulási viszonyai is. Főleg a vízszintes gyorsulása volt sokkal nagyobb. Olyannyira, hogy ez az érték már kilógott a program megengedett működési tartományából.

Az IRS szoftver ugyanis egy adott számítási lépésnél számábrázolás-váltást hajtott végre (64 bites lebegőpontosból 16 bites fix pontosra konvertált), aminek során a vízszintes gyorsulásnak bele kellett volna férnie a -32768 és +32767 közötti tartományba. Ám ezen a napon sajnos nem fért bele, így a program futása elakadt, egy kivétel keletkezett. A kivételek általában kezelhetők, és a program futhat tovább; de ebben a programban valamiért nem volt kezelve, így az egész leállt. Ilyenkor az előírt teendő az, hogy a keletkezett hiba kódját letároljuk, elküldjük a főszámítógépnek, majd megnyomjuk a RESET gombot (ami után már gyakorlatilag nem lehet repülés közben újraszinkronizálni, tehát az adott IRS-nek vége).

Mivel a tartalék és az aktív eszköz is ugyanúgy viselkedett, így mindkettő kiakadt, majd mindkettő átjelezte a hibakódot és mindkettő leállt. A leállás még nem is lett volna azonnali gond, ettől még a rakéta elboldogult volna még egy pár másodpercig. Ám az átjelzett hibakódra a főprogram nem volt felkészülve, a számot adatként értelmezte, és ennek alapján vezérelte meg a fúvókákat – korrigálva a nem létező eltérést. A rakéta erre hirtelen irányt váltott, a felszabaduló aerodinamikai erők gyorsan kiosztottak pár kokit és sallert, amitől az akkor 4 km magasan járó rakéta szerkezete megsérült, az automatikus önmegsemmisítő pedig aktiválódott. [Forrás]

Ezzel meg is találtuk a szoftver- okozta katasztrófák két újabb lehetséges okát.

Az eső és legfontosabb dolog, hogy a programokat is tervezik valamilyen működési környezetre, amit illik betartani. A második, és szintén nagyon fontos dolog, hogy a szoftverek hibái ellen nem lehet úgy védekezni, mint mondjuk egy véletlen alkatrész-törés vagy akár egy elektronikai hiba ellen. Tehát egy egyszerű duplázás semmit sem ér, sőt, már a kockázati elemzéseknél is teljesen másként kell eljárni. Szoftverekhez bizony más vizsgálati módszerek, és más hibatűrési megoldások szükségesek, melyek ebben az esetben nem történtek meg.

Biztonságkritikus környezetben működő programot tehát teljesen máshogy kell megírni, mint pl. egy játékprogramot (bár mindkettőben meg lehet halni), új elméleti hátteret, és új módszereket kellett kidolgozni. Ezek segíthettek volna elkerülni az Ariane 5 végzetét, de bizonyos banális hibáktól persze még ezek sem feltétlenül képesek megvédeni minket.

Egy tolóerő-font az hány USA-dollár? 

1999. szeptember 23-án a Mars Climate Orbiter megérkezett úticéljához, a Marshoz. A következő lépés az volt, hogy pályára kellett volna állnia a bolygó körül. Ám ehelyett a szonda eltűnt, többet nem lehetett kapcsolatba lépni vele. Mint kiderült, túl közel került a bolygóhoz (226 km helyett 150-170 km-re közelítette meg a Marsot), fékeződni kezdett, így tovább süllyedt, majd pár körrel később belépett a légkörbe és elégett.

A hibát ezúttal egy másfajta szoftveres baki okozta. A szonda fedélzeti számítógépének szoftverét és a földi kiszolgáló gépeket ugyanis két külön csapat készítette, és pár "apróságban" egyszerűen nem állapodtak meg egymással. A szonda számítógépe például metrikus rendszerben dolgozott, tehát méterben és Newtonban várta az adatokat a Földről. Eszerint végezte a szelepek vezérlését és a pályakorrekciókat is. Ezzel szemben a földi számítógépeket programozó mérnökök angolszász egységrendszert használtak, így az eredményeik is lábban meg tolóerő-fontban álltak elő.

A kár: kb. 125 millió dollár.

Azóta a NASA igyekszik a mértékrendszer-keveredési hibákat szisztematikusan kiszűrni és elkerülni, de a következő részekben fogunk még találkozni egyszer ezzel a problémával egy teljesen más eset kapcsán. [Forrás]
 

A következő részben bekeményítünk, és sokkal "egészségesebb" programhibákról fogok mesélni.