Az Európai Űrügynökség ( ESA) Ariane 5 hordozórakétája az első kilövéskor, 1996. június 4-én lezuhant a kouroui űrkikötőben . A rakéta a repülés 40. másodpercében összeomlott a fedélzeti szoftver hibás működése miatt .
Ez az indítási hiba a történelem egyik legköltségesebb számítógépes hibája volt, csak az anyagi veszteségek becslései 360 millió dollártól 500 millió dollárig terjedtek [ . A hiba az előző Ariane-4 rakétától örökölt szoftverben történt , amikor a modult nem tesztelték az új környezetben .
A baleset következtében 4 ESA műhold elveszett « Cluster", amelyet a Föld mágneses terének tanulmányozására terveztek . Ezt a tudományos programot, majd a Cluster-2 műholdakat elhalasztottákSzojuz rakétákkal lőtték ki 2000 nyarán .
A megtörtént balesetnek nagy visszhangja volt - mind a nagy anyagi veszteségek miatt, mind egy operatív vizsgálat eredményeként, amelyet az eredmények nyíltsága jellemez, és amelyet az érdeklődő európai országok szakembereinek részvételével hajtottak végre. A bizottságnak sikerült megtalálnia és reprodukálnia a hibát a repülés eseményeinek rekonstruálásával .
Az Ariane rakéták korábbi verzióinak kifejlesztését követően 1987 végén döntés született egy új Ariane-5 rendszer létrehozásáról, amely az ESA-t vezető pozícióvá tette a kereskedelmi piacon a kilövések terén. Az új hordozórakéta jellemzői az voltak, hogy lehetővé tette a távközlési műholdak felbocsátását és a Hermes -sikló felbocsátását . Annak ellenére, hogy 1992-ben lelassították az űrsikló munkálatait, az Ariane-5 fejlesztése folytatódott az emberes űrhajózás lehetséges megvalósítása érdekében . A deklarált megbízhatóság nem lehetett kevesebb, mint 0,98 a figyelembe vett 50-100 kilövés esetén, és az Ariane-4-hez képest az indítási költséget 10%-kal kellett volna csökkenteni [1] [2] .
Az Ariane-5-ön körülbelül 10 évig dolgoztak, és 7 milliárd dollárt költöttek fejlesztésre. Az Ariane 5 az előző modellre, az Ariane 4 -re épült , amelyet 93-ból 90-szer sikeresen indítottak [3] [4] [5] . 1994 februárjában ipari megrendelést adtak ki 14 hordozórakéta gyártására az 1996-1999 közötti kilövésekhez, az első repülést 1995 októberére tervezték. Az első két kilövés egyik feladata volt annak bemutatása, hogy a hordozórakéta képes-e a hasznos terhet pályára állítani. Az első indítást többször elhalasztották, és 1996 nyarán került sor [1] .
A négy Cluster műholdat magában foglaló rakéta első indításakor a hasznos teher 4681 kg volt [6] . Ez az indítás a „Cluster” tudományos program egyik szakaszát hivatott megvalósítani, amelyet az ESA 1982-ben kezdeményezett a NASA -val együttműködésben [7] . A küldetés feladata a Föld magnetoszférájának kis oszcillációinak és a napszél naptevékenységből adódó hatásának mérése volt . Ehhez több műholdas küldetést terveztek, mivel a világűr különböző pontjain több műholdon szinkron mérésekre volt szükség. Az "Ariane-5"-nek egyidejűleg négy "Cluster" műholdat kellett volna egy közbenső geostacionárius pályára állítania [8] .
1996. június 4-én reggel az időjárás elfogadható volt, és az Ariane-5 rakétát (501-es sorozatszám) szállították a kilövési helyszínre ( ELA-3 , Kourou űrrepülőtér [9] ) - a kilövés időpontját 8:35-re tervezték. helyi idő (11:00). 35 UTC ). A rakéta előkészítését is magában foglaló visszaszámlálás zökkenőmentesen lezajlott a kilövés előtti 7 percig, amikor is romlottak a látási viszonyok, és ezzel összefüggésben a kilövést elhalasztották. Az új kezdési időpont H 0 helyi idő szerint 09:33:59 volt [10] .
36,7 másodperccel a gyújtás után (H 0 +36,7) [r. 1] a repülés rendesen haladt. E pillanat után azonban a ~ 3700 m magasságban elhelyezkedő rakéta hirtelen letért a tervezett pályáról, szétesni kezdett és a 40. másodpercben felrobbant (H 0 +40). Ez a repülés elején történt – az első fokozatú hajtóművek névleges üzemideje 575 másodperc [10] [3] .
Az adatok azonnali elemzéséből kiderült, hogy a rakéta normálisan viselkedett egészen addig a pillanatig, amíg hirtelen letért az irányból és megsemmisült. A robbanás ~ 4 km-es magasságban, az indítóállástól 1 km-re történt, és a töredékek körülbelül 12 km 2 -es területen szóródtak szét a szavannán és a mocsarakban. Néhány töredék az indítóállás közelébe esett, de az sértetlen maradt. Az eset során személyi sérülés nem történt. Az időjárás elfogadható volt, és nem lehetett hatással. Ugyanakkor a repülési adatok azt mutatták, hogy a szilárd hajtóanyag-fokozó fúvókáit vezérlő rendszerek (az aktív rendszer és az elsődleges inerciális orientációs rendszer , IOS) a rakéta megsemmisülése előtt szinte egyszerre hibáztak [4] [3] .
A balesetet követő napon megkezdődött a vizsgálóbizottság felállítása. A bizottságot a Francia Tudományos Akadémia képviselője, Jacques-Louis Lions professzor vezette, a bizottságban pedig az érdeklődő európai országok tudósai és szakemberei voltak. Június 13-án kezdett dolgozni. A bizottság megkapta a rakéta telemetriai adatait, pályaadatokat (radarállomásokról és optikai megfigyelőállomásokról), valamint a lehullott törmelékről és a helyreállított IDF-ről kapott információkat. Emellett a rakéta egyes alkatrészei, köztük a tesztelésre és ellenőrzésre használtak is birtokba kerültek. Az összes adat azonnali rendelkezésre bocsátására a megbízók és kivitelezők képviselőiből külön Műszaki Bizottságot hozott létre a bizottság. A rakéta és a berendezés egyes részeit összeszerelték és tanulmányozták, valamint meghallgatták a szakemberek vallomását, tanulmányozták a gyártási és üzemi dokumentációt [4] [5] .
Az elemzés és szimuláció után a repülési eseményeket rekonstruálták [10] [4] [5] :
Hiba lépett fel az ISO programmodulban egy 64 bites valós szám 16 bites előjelű egész számmá konvertálása során, és ennek során az utóbbi számtani túlcsordulása történt. Ez a változó ( E_BH , Bias Horizontal , horizontal displacement) a tehetetlenségi platform vízszintes elmozdulását mutatta, és a rakéta vízszintes sebességével függött össze [10] . A hibát okozó programmodul hét változót tartalmazott, ebből négy védett. A hibát okozó kódsor így néz ki [11] :
P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS(TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)))Ennek a modulnak az aktiválásának sajátossága volt, hogy az Ariane-5 rendszerben más sorrendben hajtották végre a repülés előtti műveleteket, eltérően az Ariane-4-től. Ez a különbség akkora volt, hogy a meghibásodott programmodul indítás utáni működésére nem volt szükség, hanem a modult változtatás nélkül újrahasznosították.
A bizottság gyorsan meg tudta találni a hibát [to. 2] mérési adatok, szimulációs környezetek és dokumentáció elérhetősége miatt. A meteorológiai adatok kizárták az időjárás hatását, a telemetria lehetővé tette a repülési útvonal valós adatainak meghatározását. Ez lehetővé tette a lehetséges hibák körének szűkítését, és a kapott információk alapján szimulációs modellezést, amely pontosan reprodukálta azt az eseményláncot, amely a rakétát balesethez vezette [4] .
Ahogy az egyéb biztonság szempontjából kritikus rendszerhibák esetében is, a balesetet több ok okozta. A fejlesztés és a tesztelés során számos szakaszban lehetett azonosítani egy hibát [12] . A fő okokként a következőket nevezzük meg [4] :
A bizottság hangsúlyozta, hogy az ellenőrzési folyamatba nem vonták be a megrendelőtől és a rendszervállalkozótól független szervezetek szakembereit, ami sérti a végrehajtói és az ellenőrzési funkciók szétválasztásának elvét. Mind a tesztelési folyamatra, mind az ellenőrzési stratégiára vonatkozóan állításokat tettek. Tehát a tesztelés és hibakeresés szakaszában technikailag lehetséges volt az ISO működésének vizsgálata az integrált repülésszimuláción keresztül, amely szinte biztosan lehetővé tette a hiba észlelését. A teljes hardver-szoftver komplexum működésének szimulálásakor azonban az ISO-t egy megfelelően működő fekete doboznak tekintették. Felhívták a figyelmet a kölcsönös következetlenségre a megbízhatóság biztosításának szükségessége és a számítógép megengedett legnagyobb terhelésének bejelentése között. Emellett kritizálták a kivételes helyzetek kezelésének mechanizmusát is, amely az egész helyzet általános kontextusától elszigetelten működött, és ennek eredményeként „olyan lett, mint egy orvos, aki minden vizsgálat nélkül értetlenül lelőtte a hozzá forduló beteget. tüneteket, hogy ne szenvedjen." Ez a megvalósítás annak a gyakorlatnak a következménye, hogy bármilyen hardverhiba esetén a hardveregységeket radikálisan leállították, azon a feltételezésen alapulva, hogy a tartalék egység meghibásodásának valószínűsége rendkívül kicsi. Az Ariane-5 esetében azonban szisztematikus hiba történt - mivel a hiba a szoftverben történt, a tartalék egységben is megjelent [5] .
A bizottság jelentése a következő észrevételt tartalmazza [4] [10] :
Az Ariane-5 fejlesztésének fő motivációja a véletlen balesetek kockázatának csökkentése. ... A bekövetkezett kivétel nem véletlenszerű balesetnek, hanem tervezési hibának köszönhető. Egy kivételt elkaptak, de helytelenül kezeltek, mert az volt az álláspont, hogy a programot helyesnek kell tekinteni, amíg az ellenkezőjét be nem bizonyítják. […] A Bizottság ezzel ellentétes állásponton van, miszerint a szoftvereket hibásnak kell tekinteni mindaddig, amíg a jelenleg elfogadott legjobb gyakorlatok alkalmazása be nem bizonyítja a helyességét.
Eredeti szöveg (angol)[ showelrejt] Az Ariane 5 fejlesztésének egyik alapvető témája a véletlenszerű meghibásodások mérséklése iránti elfogultság. … A kivétel, amely bekövetkezett, nem véletlenszerű meghibásodás, hanem tervezési hiba volt. A kivételt észlelték, de nem megfelelően kezelték, mert azt a nézetet képviselték, hogy a szoftvert mindaddig helyesnek kell tekinteni, amíg be nem bizonyosodik a hibássága. … A Tanács az ellenkező álláspontot képviseli, miszerint a szoftvert hibásnak kell tekinteni mindaddig, amíg a jelenleg elfogadott legjobb gyakorlati módszerek alkalmazása nem bizonyítja a helyességét.Az Ariane 5 karbantartó csapata a következő magyarázatokat adta a történtekre [4] :
Ez a sikertelen indítás a történelem egyik legköltségesebb számítógépes hibája lett. A becsült anyagi veszteségek 360 millió dollártól 500 millió dollárig terjednek ( amely nemcsak a rakéta költségét, hanem a tudományos hasznos felszerelést is tartalmazza). Emellett az ügynökség számos későbbi kereskedelmi forgalomba hozatalára nem került sor, az Ariane-5 program egy évet késett, és az ESA elvesztette hírnevét a piacon [c. 3] [5] [13] [14] .
A baleset következtében 4 ESA „Cluster” műhold veszett el, amelyeket a Föld mágneses terének tanulmányozására terveztek. Ugyanezen év júliusában az ESA felajánlotta, hogy újraalkotja ezt a projektet legalább egy műholdon, amely a „Phoenix” nevet kapta. A projekt egy műholdat tartalmazott, amelyen állítólag ugyanazok a műszerek voltak, mint az elveszett Cluster műholdakon. 1997 közepére minden műszert teszteltek, és az új Phoenix műhold készen állt az indításra. De mivel egy műhold nem tudta megadni a megfelelő tudományos információkat, amelyeket négy műhold tudott adni, az ESA úgy döntött, hogy a teljes küldetést négy, „Cluster-2” nevű műhold részeként hozza létre. Az indítást 2000 nyarára tervezték, mivel ez volt a naptevékenység várható csúcséve. A kockázat csökkentése érdekében a műholdak felbocsátását az orosz Szojuz hordozórakétára bízták a Fregat felső fokozatot használva . Az első műholdpárt 2000. július 16-án, a második párat pedig ugyanezen év augusztus 9-én [15] [8] .
Az Ariane-5 későbbi indításakor a következő tevékenységeket hajtották végre [3] :
A Bizottság ajánlásai alapján a rendszer minden egyes eszközére harmadik fél által kódolt ellenőrzést végeztek . Számos szervezeti intézkedést is tettek annak érdekében, hogy átláthatóbbá tegyék a partnerek közötti interakció folyamatait, egyértelmű hatáskör- és felelősségmegosztással. A szoftverellenőrzés már magában foglalta az egységtesztet , az integrációs tesztelést , a funkcionális validálást , a kódlefedettség - elemzést és a tanúsítást, ennek ellenére a szoftvert statikus kódelemzéssel , absztrakt interpretációval validálták.. Csupán a két legbonyolultabb és biztonságkritikus modul – az ISO és a központi repülési modul – ellenőrzésére került sor, amelyekben 30, illetve 60 ezer Ada nyelvű kódsor volt. Ezek a tesztek voltak a statikus elemzés első alkalmazásai nagy ipari szoftverrendszerekben, és hozzájárultak a statikus elemzési módszerek elterjedéséhez [16] [17] .
Az Ariane-5 következő kilövésére 1997 októberében került sor, majd a rakéta fellőtt egy műholdat " IGEN". Ez az indítás részben sikeresnek számított, mivel a hasznos teher túl alacsony pályára került a hajtóművek idő előtti leállása miatt. Ezt a hibát a repülés után megmagyarázták és kijavították, de ennek ellenére az ügyfelek bizalma az új rakéta iránt megsérült, ezért 2003-ig számos Ariane-4-es kilövés történt [18] .
A megtörtént balesetnek nagy visszhangja volt - mind a nagy anyagi veszteségek miatt, mind az operatív vizsgálat eredményeként, amelyet az eredmények nyíltsága jellemez [5] .
J.-M. Zhezekelés Bertrand Meyer arra a következtetésre jutott, hogy véleményük szerint a szoftverhiba tisztán technikai jellegű, és a szoftverek helytelen újrahasználati gyakorlatában gyökerezik, és az újrafelhasználható modul pontos specifikációjának hiánya végzetes szerepet játszott. A vizsgálat kimutatta, hogy a 16 bitbe illeszkedő maximális érték követelménye elveszett a fő specifikációs dokumentum mellékleteiből. Ezenkívül nem volt megjegyzés vagy hivatkozás az állítást alátámasztó dokumentumra. A probléma megoldására a szerzők a szerződéstervezés elvének alkalmazását javasolták [k. 4] , amikor olyan „szerződést” határoznak meg, amely meghatározza az összetevő bemeneti és kimeneti paramétereinek feltételeit, és a szerzők egy ilyen szerződés „tervezetét” adták meg. A szerzők szerint ez feltárhatja a problémát mind a tesztelési szakaszban, mind a repülés során [14] .
Jezekel és Meyer nézőpontja sok visszhangot váltott ki. Cikkük legrészletesebb kritikai elemzését a Lockheed Martin Tactical AirCraft Systems munkatársa , a kritikus rendszerek fejlesztésének ismert szakértője, Ken Garlington végezte [ 19 ] . Tehát észrevette, hogy a Zhesekel és Meyer által javasolt szerződés hibát tartalmaz, mivel azt feltételezi, hogy az E_BH értékét egész számból alakították át, de a valóságban valós számból konvertálták. Ugyanakkor jelentős volt, hogy egyedül Garlington hívta fel a figyelmet egy meglehetősen nyilvánvaló problémára, miközben a cikket számos képzett szakember olvasta és tárgyalta nyilvánosan. Ezen kívül Garlington részletesen taglalta azokat a nem triviális problémákat, amelyek akkor merülnek fel, ha nem egy „tervezetet”, hanem egy teljes szerződésspecifikációt írnak egy adott helyzetre. Garlington következtetése azt mutatja, hogy a probléma összetett, és elsősorban az olyan rendszerek objektív komplexitásának köszönhető, mint az "Arian" [5] .
A Journal of Automated Software Engineering főszerkesztője Bashar Nuzaybeháttekintette a baleset okait illetően különböző nézőpontokat, és arra a következtetésre jutott, hogy "mindenkinek igaza van". Bashar úgy vélte, hogy a baleset a szoftverrendszerek fejlesztésének általános problémáival függ össze, és emellett megjegyezte, hogy a fejlesztésben és az ellenőrzésben részt vevő szakemberek érdekeinek szétválasztása (ami az olyan megközelítések széles körű bevezetésével jár együtt, mint az objektumorientált és a komponenstechnológiák) nem kap megfelelő kiegyensúlyozó ellensúlyt a menedzsment oldalán, akinek a teljes munkafolyamatot megfelelő szinten kell koordinálnia [12] .