Had- és rendvédelem-história, kicsit másképp

Összeálltunk páran, hogy kipróbáljuk: lehet-e szórakoztatóan, ugyanakkor informatívan foglalkozni rendvédelem-történeti, valamint katonahistóriai témákkal. Szerintünk igen. *** imélke nekünk: blog.lemil(at)yahoo.co.uk --- BLOGUNK A MAGYAR BLOGGERSZÖVETSÉG TAGJA ---

Megjelent a Kémek krémje!

borito_240.jpg

Naptár

március 2024
Hét Ked Sze Csü Pén Szo Vas
<<  < Archív
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Lemil-fészbúk

Olvasóink lobogói

Pillanatnyi olvasólétszám:

website stats

Utolsó öt komment

Fontosabb címkék

1848 49 (46) afganisztán (6) afrika (13) ajánló (88) alagút (7) állat (8) amerikai (102) angolok (8) arabok (16) argentin (5) átirányítás (13) atom (13) ausztrál (6) ázsia (15) balkán (6) betyár (5) biofegyver (5) biztonságpolitika (6) brazil (7) brit (67) buli (6) büntetésvégrehajtás (7) büntetőjog (11) címer (6) csata (9) csatabemutató (9) csendőrség (6) dél amerika (11) ejtőernyős (28) életrajz (41) elmélet (12) erdély (6) erőd (8) értékelőposzt (7) évforduló (53) fegyver (8) ferencjózsef (11) francia (24) gallup (5) görgey (13) görögök (5) háború (6) háborús bűn (8) hadifogoly (5) haditechnika (98) haditengerészet (54) hadsereg (16) hadtörténelem (162) hadtörténet (23) hadvezérek (9) hagyományőrzők (5) hajók (5) harckocsi (23) határőrség (7) hellókarácsony (5) helyi háborúk (17) hidegháború (53) híres bűnözők (8) honvédség (12) horthy (6) humint (24) huszár (10) i. világháború (49) ii világháború (108) izrael (26) japán (22) játék (6) k.u.k. (8) kalóz (6) kamikaze (6) kanada (7) katonazene (10) kelták (5) kémek és hírszerzők (59) kiképzés (7) kína (5) kínai (5) kivégzés (6) könyv (5) könyv ajánló (5) középkor (12) közép amerika (7) kuba (9) különlegesek (71) légierő (56) légvédelem (9) lengyel (17) lengyel magyar barátság (8) lista (5) lovas (7) lovasság (11) lövészárok (5) magyar (157) makett (7) monarchia (13) múzeum (12) német (68) nevezéktan (5) nők (12) ókor (13) olasz (13) önvédelem (5) orosz (31) ostrom (7) osztrák (30) osztrák magyar (28) pestis (6) plakát (12) podcast (9) polgárháború (5) porosz (5) portugál (6) programajánló (10) reform (6) reklám (5) rendőr (7) rendőrség (10) rendvédelem (53) róma (13) román (9) rövidhír (18) sigint (6) skandináv (7) skót (6) sorozat (15) spanyol (5) svájci (5) svéd (7) számítógép (9) szavazás (20) szerb (11) szlovák (5) szolgálati közlemény (39) szovjet (63) sztálin (5) telefonkártya (6) tengeralattjáró (17) tengerészgyalogos (10) terror (25) titkosszolgálat (71) török (15) tűzfegyver (9) ünnep (5) USA (7) usa (54) utánközlés (24) vadászgép (12) várostrom (7) vendégposzt (80) vértanú (11) vicc (7) vietnam (5) vitaposzt (76) wysocki légió (12) zene (11) A többi címke

Közkívánatra: feedek

General Protection Fault - I.

2012.03.26. 08:00 Papírzsepi

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.

37 komment

Címkék: katasztrófa számítógép rakétapajzs

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

hazitroll 2012.03.26. 09:01:04

Mivel Papírzsepi engem felkért, hogy nézzem át az írást, csak én kissé későn olvastam a leveleim, ezért utólag két dolgot hozzátennék a témához:
- egy "ideális" program elkészültére fordított idő legalább 50%-a, de inkább 80-90%-a a dokumentációra megy el (tervrajzkészítés, minőségi ellenőrzés - hogy egyszerű analógiát mondjak)
- a hasznos szoftverírásra fordított energia legalább 50, de inkább 90-95%-a a más rendszerekből, felhasználókból, hálózati hibákból, hardverhibából eredő problémák kezelését, javítását, de legalábbis a katasztrófa elkerülését szolgálja

Tehát az effektíve eredeti probléma megoldását, amire a program íródik a ráfordított időnek legfeljebb 25%-a, de valójában cirka 5%-a szolgálja.

Megjegyzem, ez nem extrém érték, egy orvosi beavatkozásnál is a műtét idejének nagyobb részét nem az teszi ki, hogy azt az egynéhány bemetszést, vágást megejtsék, hanem hogy odajussanak és onnét biztonságosan felébreszthessék a pácienst.

hazitroll 2012.03.26. 09:01:42

@hazitroll: Ja, még mindig nem olvastam el, remélem, nem írtad le ezt ugyanígy :)

Valandil 2012.03.26. 09:39:17

"737 tonnás rakéta" - kicsit soknak tűnik...

Papírzsepi · http://lemil.blog.hu 2012.03.26. 09:45:57

@Valandil: pedig annyi. És ez a 737 tonnát mindössze 6 tonnányi műhold fellövéséhez kell megemelni. Ennyit a hatásfokról.

Titus Pullo Urbino 2012.03.26. 10:52:05

Szép munka, gratula! A XX. század és az űrkorszak nem az én világom, én leragadtam az elöltöltős puskák világánál, úgyhogy most megkíméllek titeket az ostoba kérdéseimtől, hehehe. Azért ezt citálom: "A 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." A fonál örökre elveszett :-)

hazitroll 2012.03.26. 10:54:27

Igazából csak hozzátenni tudok a témához, a Patriot rakéta kapcsán az idő és újraindítás kapcsán:
Nagynevű német autógyártó navigációs rendszerében a legnagyobb probléma amit meg kell(ett) oldani, hogy potenciálisan sosem indul újra. Ugyanis mindig áram alatt van, kikapcsolt motornál is lehet vele matatni, tehát mindig be van kapcsolva, és memory leak, téli-nyári időátállás kezelése (útvonaltervezésben, utazási időben) mind-mind probléma. Utóbbi mondjuk egy nagyon fájó pontja szinte minden programnak. Szóval a probléma nem múlt el egyáltalán, csak jobban megtanulták kezelni a fejlesztők.

hazitroll 2012.03.26. 10:59:48

Még egy godnolat: a 70-es évek szoftverkrízise, amire elvileg megoldást hoztak a "modern" modellező, grafikus és egyéb szép eszközök eredményezik azt, hogy most hibakeresésnél legalább 8 helyen lehet hiba, míg régen vagy elgépelted, vagy (logikai értelemben véve) elb@sztad, most még lehet hibás compilered, modelleződ, validátorod, stb. Persze nem mondom, hogy régen jobb volt, csak más. Kb, mint autót szerelni: egy mai csodában sokkal több hibaforrás van, mint egy Moszkvicsban volt, de ettől még nem jobb egyik a másiknál.

Sandman (Karakum) (törölt) 2012.03.26. 11:01:04

Érdekes a poszt, várom a folytatásokat is :)

hazitroll 2012.03.26. 11:02:55

@Titus Pullo Urbino: Ma rém költői vagyok, tele hasonlatokkal: mintha egy kottából átírnád a másikra: a gregorián négy vonalas kottát használt, a mai kottaírás meg öt vonalat. ÉS akkor írd át egyikből a másikba.
Az persze megint egy sarkalatos probléma, hogy miért kell többféle ábrázolási mód.

stoppos76 2012.03.26. 11:23:00

Pár éve egy projekt kapcsán felhívtam a manágement figyelmét mindenféle bugokra és design flaw-kra. Próbáltam némi pénzt szerezni egy közepes javító projektre, arra gondolván, hogy talán később az üzemeltetésen spórolhatunk, mikor a rendszer nem csak 1 országban lesz, hanem mind a tervezett 10-ben. Ekkor mondta az akkori főnököm, hogy nyugi, nem műholdat tervezünk, nem kell mindennek elsőre tökéletesen működni. Erre tessék, azok sem működnek tökéletesen. Pedig mennyivel több idejük/pénzük van nekik, mint nekem mezei informatikusnak egy-egy projektre.

milliliteratura · http://milliliteratura.blog.hu/ 2012.03.26. 12:11:38

remek poszt, élesítjük a macskák körmeit.

@Papírzsepi: bazz :) egy bivaly méretű csúzli is hatékonyabb lenne...
ebből hány tonna az üzemanyag?

camell · http://indafoto.hu/camell 2012.03.26. 12:17:16

Jó kis cikk volt, várom a következő részt... És mindíg jót tudok röhögni az ilyen bakikon (ha nem múlik rajta emberélet). Erről az jutott eszembe, amikor egy fordítógéphez kifejlesztett algoritmust teszteltek, hogy szóösszetételekkel is el tudjon bánni. Így lett a traffic jam-ből autóizű lekvár.

Papírzsepi · http://lemil.blog.hu 2012.03.26. 12:19:51

@milliliteratura: háát, úgy látom, hogy van egyszer 130 tonna oxigén, 25 tonna hidrogén, meg a szilárd hajtóanyagú gyorsítók, melyek még darabonként 277 tonnát nyomnak. Ja, meg a második fokozat hajtóanyaga.
Viszont a későbbi Ariane 5-ök már sokkal jobbak voltak: akár 14 tonnát is felvihettek...

Tyeplica 2012.03.26. 12:24:26

Úgy emlékszem, Szaud-Arábiánan, a dahrani légitámaszponton (Saud Arabia? :-) Ennek a névnek létezik magyar átirata.) 28 _kotona_ halt meg, nem pedig sima "állampolgár". Most ne menjünk bele abba, hogy a kotona is állampolgár, mert van egy olyan felhangja az "állampolgár" szónak, hogy az talán civil. Ezek kifejezetten kotonák voltak.

sydney.edu.au/engineering/it/~alum/patriot_bug.html

Második bekezdés: "killing 28 U.S. soldiers"

hazitroll 2012.03.26. 13:03:53

@stoppos76: Semennyivel: őket is tökön rúgja valaki, ha nincs kész időre.
Esetleg azzal védekezhetnek, hogy dehát ez mégiscsak műhold, legalább ha lehet fellövés közben ne romoljon el.

Valandil 2012.03.26. 13:52:46

@Papírzsepi: Akkor már inkább a Bull-ágyúval kellene próbálkozni. (Most néztem rá az Enyergija adataira, és teljesen ledöbbentem...)

molnibalage · https://militavia.blog.hu/ 2012.03.26. 17:30:57

"melyet a U.S. Army a jól bevált légvédelmi fegyverrel, Patriot rakétákkal igyekezett védeni."

Hogyan lehetett valami jól bevált, amikor első éles szereplése volt...?

-------------

"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),"

Miféle szovjet levegő föld rakéta megy M2.0-val tatósan, ami ellen kellene a Patriot? Az életben nem hallottam még ilyet. A Patrior egy "mezei" légvédelmi rendszer volt repülőgépek ellen és minimális ABM képességgel.

---------

"és csak pár órás üzemet kellett kibírnia (utána úgyis mindenki meghalt volna)."

Ez úgy ahogy van, nettó marhaság. Az F-15-öt és a többi 4. gen gépet akkor miért tervetzék több ezer órára? A Patriot korbában már régen nem az elkerülhetetlen totális atomháborúra készültek.

BTW az atomháború esetén is van készültségi szint, tehát ott is 8 óránál magasabb üzem kell, mert senki nem jósolta meg volna, hogy melyik 8 órában jön az ellen. Szimplán ellébecoltak egy életbevágó üzemeltetési paramétert. Ennyi.

-----------
"Á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."

És lám, megtaláltuk a potenciális és átlagos taktikai atomfegyver paltormot. Akkor a Mach 2 az honnan jön?

Egyébknét én a Patriotánál én azt a hibát vártam, mai a rakéta gyújátásában okozta a hibát és ezért (is) volt annyira hatástalan az Al Hussain ellen.

Papírzsepi · http://lemil.blog.hu 2012.03.26. 18:28:13

@molnibalage: A fegyvert az eset előtt 30 évvel kezdték fejleszteni, és 25 évvel az eset előtt már használták valamely verzióját. Ez indokolja a "jól bevált" fordulatot.
Idő közben sokszor módosították, fejlesztették. Lehet, hogy repülők ellen fejlesztették eredendően, az indokolja a MACH2-t. Az orosz atomrakéták sebessége tényleg gyanús, majd utána nézek.
A rövid készültségi szint is meglepő, de eredetileg tényleg csak valami 2 óra volt a specifikációban. Aztán jött az általad is írt ellébecolós tényező, (ami a szoftvereknél amúgy igencsak gyakori hiba). Viszont később nagyon kreatívan lehet indokolni az ilyesmit, a posztban olvasható dolgokat sem én találtam ki.
Amúgy nem a Patriot rakétákról szól a poszt, hanem a szoftver hibákból bekövetkező katasztrófákról.

molnibalage · https://militavia.blog.hu/ 2012.03.27. 00:00:56

@Papírzsepi: A Patriot fejlesztése rohadtul nem a '60-as évek elején kezdődött inkább a legeslegvégén és az is csak tanulmány szinten volt akkor legfeljebb. 1975-ben semmiféle verziót nem használtak, max korai protót. A '80-as évek elején kezdék az első példányokat leszállítani.

(Egyébként ismerek egy programozót, aki dolgozott a rendszeren. Esetleg megadjam az elérhetőségét? Hátha hajlandó beszélni erről-arról. Lehet, hogy rosszul emlékszek, de az FreeFalcon fórumon BaldEagle néven van/volt jelen. A Falcon 4.0 szimulátor távoli leszármazottjának, az ingyenes FreeFalconnak a főkódere volt évekig.)

Papírzsepi · http://lemil.blog.hu 2012.03.27. 10:15:06

@molnibalage: Igazad van elszámoltam az éveket. De akkor is tíz éve rendszerben volt akkor már a rakéta, és 15 éve fejlesztették. Tehát annyira azért nem volt kezdő, hogy ilyen hibák megengedhetőek lettek volna benne (és ha csak ennyi lett volna, ugye...).

Amúgy én nem akarok most ebbe jobban belemenni, de érdemes lenne esetleg írni egyszer arról, hogy miként fejlesztenek ki egy fegyvert - mennyiben más a dolog, mint a polgári életben. Gyanítom, hogy nem nagyon - a katonai szabványok ma már nagyon közelítenek a polgáriakhoz.

HighTroller 2012.03.27. 11:44:24

Az Ariane és a Mars Climate Orbiter sztori a műszaki egyetemen szoftvertervezési témájú tárgyak esettanulmánya.

Jó a poszt!

mnandy 2012.03.27. 13:23:45

Az Erzsébet híd statikai modellezése megvolt? Az is érdekes sztori, arra, mit tud egy tizedesvessző..

molnibalage · https://militavia.blog.hu/ 2012.03.27. 16:05:12

@Papírzsepi: Békeidőben a jelek szerint soha nem próbálták ki eszerint. Nem az naptári év számít hanem az, hogy az adott körülmények között nyúzták e. A repülőgépeknél sem az számít, hogy hány évet állnak a földön, hanem a repült őrák száma...

Papírzsepi · http://lemil.blog.hu 2012.03.27. 21:12:54

@molnibalage: na igen, ebben egyet értek. Gondolom kipróbálták, de egyrészt drága dolog próbálgatni, másrészt minden körülményt úgysem lehet rendesen modellezni. Főleg az "öregedéses" jelenségeket. A második és a harmadik részben még lesz szó ilyesmiről, bőven.

laverdasfc 2012.03.28. 00:23:40

@mnandy: Ez engem is érdekelne... Nekünk mecha2-ből és fémtanból is azt tanították, hogy el lett cseszve az ötvözet, ezért nem lehetett hegeszteni, csak szegecselni.

mnandy 2012.03.28. 17:29:30

@molnibalage: @laverdasfc:

Igazából csak egy - végül jóvátehetőnek bizonyult számítási hiba, de érdekes sztori.

Szelezsán tanár úr mesélte, matekórán, még valamikor '92-ben. Amikor beindult az M3, az egyik feladat, amit futtattak rajta, az Erzsébet híd modellszámításainak az ellenőrzése volt.

szamosp.web.elte.hu/pub/levelek/inftori.htm

és

hu.wikipedia.org/wiki/A_sz%C3%A1m%C3%ADt%C3%B3g%C3%A9p_t%C3%B6rt%C3%A9nete#Az_els.C5.91_magyarorsz.C3.A1gi_sz.C3.A1m.C3.ADt.C3.B3g.C3.A9pek

Szelezsán Jánosék matematikus csoportja végezte a számításokat, közösen az M3 mérnök alkotógárdájával. A feladat az volt, hogy adják meg a hídpálya középpontjának függőleges irányú elmozdulását a névleges terhelés ötszörösének hatására, 30 C°, és 1 atmoszféra légköri nyomás mellett. Az első linken levő anyagot megnyitva és CTRL-F-fel rákeresve (Szelezsán) látható, hogy ez volt az M3 egyik, talán első alkalmazása, akkoriban ez hírnek számított, én a könyvtárban belefutottam egy talán '65 októberi Népszabi cikkbe, hogyaszongya: "aszocializmusnagyobbdicsőségére a jövő mérnökeit a jövő okos gépe segíti, ami már dolgozik a jövő hídjának tervein, szorgos népünk győzni fog!" (vagy valami hasonló propaganda-bullshit)

Erre - mármint a híd viselkedésére, nem a propagandára - felállítottak egy nemlineáris egyetletrendszert, aminek a megoldásához 30X30-as mátrixokkal kellett operálni.

A gép adottságai miatt ez akkora méretű feladat volt, hogy egyszerre nem is lehetett rávinni, rész futásokat kellett futtatni, és a részeredmény szalagokat összefuttatva jött ki az eredmény.

Ugyancsak a gép adottságai miatt - számábrázolás, a gép nem tudott lebegőpontos számokat ábrázolni - egyéb trükkök is kellettek: a programot úgy írták, hogy minden szám "nulla egész valamennyi legyen", vagyis a karakterisztika nulla legyen, és akkor csak a mantisszát kell ábrázolni. Mivel a legnagyobb adatuk tízezres nagyságrendű volt, a 30*30-as mátrix mindegyik elemét el kellett osztaniuk 10.000-rel. Ezt hat-nyolc ember végezte, papíron, ceruzával.. És az egyik adat már eleve 0,xxxxx tizedes tört volt. Átcsúszott.. Gyakorlatilag tízezerszeres az egyik paraméter..

Szóval a hetekig tartó futtatás után (a November 7-i határidő előtt három-négy nappal!) kijött végeredmény, hogy a lehajlás mértéke 27,5 méter... Vagyis a híd közepe lelóg a meder aljáig, sőt még annál is mélyebre..

Na, innentől nov.6-ig senki nem aludt a csapatból, lázasan keresték a hibát, és nagy megkönnyebbülésükre meg is találták, ráadásul nem kellett hozzá újra futtatni a teljes számítást, mert az utolsó szalagok egyikét kellett csak újrafuttatni, és azzal összefuttatni a többit, úgyhogy "határidőre"(!) meglett a végeredmény, ami megerősítette a tervező számításait, sőt, azóta a híd valóságos viselkedése is megerősíti.

November 7-én nagyon örültek az elvtársak, Szelezsán urat pedig egy héten belül műtötték gyomorfekélyjel..

laverdasfc 2012.03.28. 20:11:12

@mnandy: A hibakeresés tényleg sok embernek okozott már fekélyt...
Nem számítógépes hiba, de ide tartozik:
Ha igaz a legenda, a Breslau-i Grunwaldzki híd tervezője az átadás előtti éjjel öngyilkos lett, mert hibát vélt felfedezni a számításaiban. A híd azóta is áll.

Egy hídnál persze nem nagyon szabad hibázni. Nem véletlen, hogy az a szokás, hogy a főtervező az elkészült híd terheléses vizsgálata során a híd alatt kell, hogy tartózkodjon.

tudi 2012.03.29. 19:45:27

Érdekes várom a fojtatást. Ez is mutatja, hogy az egyszerű "kicsi" hibák mekkora gondot is okozhatnak.

whitebeard 2012.03.31. 20:42:27

Nagyon jó a cikk. Gratula ! Várom a folytatást.

Peter Shark 2012.04.01. 08:50:57

OFF ennek a témának, de BRÉKING HELP!!!
Szerkesztői emberi mulasztás miatt kérem bármely szerkesztőt, hogy MÉG MA keressenek meg emailen: petershark924@gmail.com
Köszönöm.

folti_ 2012.04.27. 00:28:39

@Valandil: @milliliteratura: Hát, nemigazán. A nagyságrendi problémák ugyanúgy meglennének, ráadásul sajátos új problémákkal megtüzdelve. Például minél nagyobb cuccot akarsz felküldeni, annál nagyobb adag lőporral kell indítani, ami sokkal nagyobb sokknak teszi ki mind az ágyút, mind a kilőni szánt eszközt, ami miatt mindakettőt meg kell erősíteni, amitől mindkettő csak nehezebb lesz, ami miatt nagyobb indítótöltet kell alájuk ... Volt egykét kisérlet ilyenekkel, (lásd az érdekes életű Gerard Bull-t és a Project HARP-ot), de a skálázódási probléma miatt (is) elkaszálódott a dolog.

Amúgy ~700-800 tonna az a megszokott versenysúly a nehéz hordozórakéták esetén. A szupernehéz hordozók (Energia, Saturn V, Angara, Space Shuttle tokkal vonóval) kezdődnek 1000 tonna felett. Csak ott már problémak kezdenek lenni olyasmikkel, hogy mégis mit is akarsz kilőni, ami ilyen nehéz, milyen pályá(k)ra és ki fogja állni czechet az egészért.

Walter Hartwell White 2012.04.29. 20:35:40

Ha már híd, a Galloping Gertie sztorija megvan? :] Bár az már az aerodinamika tudományágába esik...

Dester 2013.11.21. 13:29:49

Lehet, hogy urbanlegend, de mintha valamelyik legelső programozó mondta volna a hőskorban, amikor kérdezték, hogyan kezeli a tizedesvesszőt, amikor nem tudja a nyelv: "Minek az? A jó programozó tudja, hol van."

Brazsik79 2015.03.21. 14:54:11

Papirzsepi! Irtam privát üzenetet, illetve lemilblog email címre neked számt üzit, nem tudom, megkaptad?

mnandy 2018.02.26. 10:27:30

@molnibalage: Óbasszus, nagyonköszi! VAlamiért csak most találtam meg!
süti beállítások módosítása