Euroopan avaruusjärjestön ( ESA) Ariane 5 -kantoraketti syöksyi maahan ensimmäisen laukaisun yhteydessä 4. kesäkuuta 1996 Kouroun avaruussatamassa . Raketti romahti lennon 40. sekunnissa koneen ohjelmiston virheellisen toiminnan vuoksi .
Tämä laukaisuvirhe oli yksi historian kalleimmista tietokonevirheistä , ja pelkästään aineellisten menetysten arvioitiin vaihdellen 360 miljoonasta 500 miljoonaan dollariin [ . Vika tapahtui edelliseltä Ariane-4- raketilta perityssä ohjelmistossa, kun moduulia ei testattu uudessa ympäristössä .
Onnettomuuden seurauksena 4 ESA-satelliittia katosi « Cluster", suunniteltu tutkimaan Maan magneettikenttää . Tämä tieteellinen ohjelma lykättiin ja myöhemmin Cluster-2- satelliititlaukaistiin Sojuz -ohjuksilla kesällä 2000 .
Tapahtuneella onnettomuudella oli suuri resonanssi - sekä suurten aineellisten menetysten vuoksi että operatiivisen tutkimuksen tuloksena, jolle oli ominaista tulosten avoimuus ja joka toteutettiin kiinnostuneiden Euroopan maiden asiantuntijoiden osallistuessa. Komissio pystyi löytämään ja toistamaan virheen rekonstruoimalla lennon tapahtumat .
Ariane -ohjusten aikaisempien versioiden kehittämisen jälkeen vuoden 1987 lopulla tehtiin päätös luoda uusi Ariane-5-järjestelmä, jonka tarkoituksena oli tehdä ESA:sta johtava laukaisu kaupallisilla markkinoilla. Uuden kantoraketin ominaisuuksien tarkoituksena oli mahdollistaa sekä televiestintäsatelliittien laukaisu että Hermes - sukkulan laukaisu . Huolimatta siitä, että sukkulan työskentelyä rajoitettiin vuonna 1992, Ariane-5:n kehitystä jatkettiin miehitetyn astronautiikan mahdollista toteuttamista varten . Ilmoitetun luotettavuuden ei olisi pitänyt olla pienempi kuin 0,98 tarkastetuilla 50-100 laukaisulla, ja laukaisukustannuksia Ariane-4:ään verrattuna olisi pitänyt vähentää 10 % [1] [2] .
Ariane-5:tä tehtiin noin 10 vuoden ajan, ja kehittämiseen käytettiin 7 miljardia dollaria. Ariane 5 perustui edelliseen malliin, Ariane 4 :ään , joka laukaistiin onnistuneesti 90 kertaa 93:sta [3] [4] [5] . Helmikuussa 1994 annettiin teollinen tilaus 14 kantoraketin valmistukseen laukaisua varten vuosille 1996-1999, ja ensimmäinen lento suunniteltiin lokakuulle 1995. Yksi kahden ensimmäisen laukaisun tehtävistä oli osoittaa kantoraketin kyky asettaa hyötykuorma kiertoradalle. Ensimmäinen laukaisu lykättiin useita kertoja ja tapahtui kesällä 1996 [1] .
Neljä klusterisatelliittia sisältävän raketin ensimmäisen laukaisun hyötykuorma oli 4681 kg [6] . Tämän laukaisun oli tarkoitus toteuttaa yksi vaiheista tieteellisessä ohjelmassa "Cluster", jonka ESA aloitti vuonna 1982 yhteistyössä NASAn kanssa [7] . Tehtävänä oli mitata Maan magnetosfäärin pieniä värähtelyjä ja aurinkotuulen vaikutusta siihen auringon aktiivisuuden vuoksi . Tätä varten suunniteltiin monisatelliittitehtävä, koska synkronisia mittauksia vaadittiin useilla satelliiteilla, jotka sijaitsivat ulkoavaruuden eri kohdissa. "Ariane-5":n piti laukaista samanaikaisesti neljä "Cluster"-satelliittia geostationaariselle kiertoradalle [8] .
Sää 4.6.1996 aamulla oli hyväksyttävä ja Ariane-5-raketti (sarjanumero 501) toimitettiin laukaisupaikalle ( ELA-3 , Kouroun avaruussatama [9] ) - laukaisuaika oli määrätty klo 8.35 paikallista aikaa (11.00). 35 UTC ). Lähtölaskenta , joka sisälsi raketin valmistelun, sujui sujuvasti 7 minuuttia ennen laukaisua, jolloin näkyvyysolosuhteet heikkenivät ja tämän vuoksi laukaisua siirrettiin. Uudeksi alkamisajaksi H 0 asetettiin 09:33:59 paikallista aikaa [10] .
36,7 sekuntia sytytyksen jälkeen (H 0 +36,7) [r. 1] lento sujui normaalisti. Tämän hetken jälkeen ~ 3700 m :n korkeudessa sijaitseva raketti poikkesi kuitenkin yhtäkkiä suunnitellulta lentoradalta, alkoi hajota ja räjähti 40. sekunnissa (H 0 +40). Tämä tapahtui lennon alussa - ensimmäisen vaiheen moottoreiden nimellinen toiminta-aika on 575 sekuntia [10] [3] .
Tietojen välittömästä analyysistä selvisi, että raketti käyttäytyi normaalisti siihen hetkeen asti, kun se yhtäkkiä poikkesi kurssilta ja tuhoutui itsestään. Räjähdys tapahtui ~ 4 km:n korkeudessa, 1 km:n etäisyydellä laukaisualustasta, ja sirpaleet hajaantuivat noin 12 km 2 :n alueelle savannilla ja soilla. Jotkut sirpaleet putosivat lähelle laukaisualustaa, mutta se pysyi ehjänä. Tässä tapahtumassa ei aiheutunut henkilövahinkoja. Sää oli hyväksyttävä, eikä sillä voinut olla vaikutusta. Samaan aikaan lentotiedot osoittivat, että kiinteän polttoaineen tehostimen suuttimia ohjaavat järjestelmät (aktiivinen järjestelmä ja ensisijainen inertiasuuntausjärjestelmä , IOS) epäonnistuivat lähes samanaikaisesti ennen raketin tuhoamista [4] [3] .
Onnettomuuden jälkeisenä päivänä aloitettiin tutkintatoimikunnan muodostaminen. Sitä johti Ranskan tiedeakatemian edustaja , professori Jacques-Louis Lions , ja komissioon kuului tutkijoita ja asiantuntijoita kiinnostuneista Euroopan maista. Hän aloitti työt 13. kesäkuuta. Komissiolle toimitettiin raketin telemetriatiedot, lentoratatiedot (tutka-asemilta ja optisista havaintopisteistä) sekä pudonneista roskista ja talteenotetusta IDF:stä saadut tiedot. Lisäksi haltuunsa tuli raketin yksittäisiä komponentteja, mukaan lukien testaukseen ja tarkastukseen käytetyt. Kaikkien tietojen välitöntä toimittamista varten komissio perusti erityisen teknisen komitean asiakkaiden ja urakoitsijoiden edustajista. Raketin ja laitteiston osia koottiin ja tutkittiin, asiantuntijoiden todistukset kuultiin ja tuotanto- ja käyttödokumentaatiota tutkittiin [4] [5] .
Analyysin ja simulaation jälkeen lentotapahtumat rekonstruoitiin [10] [4] [5] :
ISO-ohjelmamoduulissa tapahtui virhe muunnettaessa 64-bittistä reaalilukua 16-bittiseksi etumerkilliseksi kokonaisluvuksi , jolloin tapahtui jälkimmäisen aritmeettinen ylivuoto . Tämä muuttuja ( E_BH , Bias Horizontal , vaakasuuntainen siirtymä) osoitti inertialauvan vaakasuuntaisen siirtymän ja oli suhteessa raketin vaakasuuntaiseen nopeuteen [10] . Virheen aiheuttaneessa ohjelmamoduulissa oli seitsemän muuttujaa, joista neljä oli suojattuja. Koodirivi, joka aiheutti virheen, näyttää tältä [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)))Tämän moduulin aktivoinnin piirre oli, että Ariane-5-järjestelmällä oli erilainen järjestys lentoa edeltävien toimien suorittamiseksi, erilainen kuin Ariane-4:ssä. Tämä ero oli niin suuri, että epäonnistuneen ohjelmamoduulin toimintaa käynnistyksen jälkeen ei tarvittu, vaan moduulia käytettiin uudelleen ilman muutoksia.
Komissio pystyi nopeasti löytämään virheen [to. 2] mittaustietojen, simulointiympäristöjen ja dokumentaation saatavuuden vuoksi. Meteorologiset tiedot sulkivat pois sään vaikutuksen, telemetria mahdollisti lentoradan todellisten tietojen määrittämisen. Tämä mahdollisti mahdollisten vikojen alueen kaventamisen ja saatujen tietojen perusteella simulaatiomallinnuksen suorittamisen, joka toisti tarkasti raketin onnettomuuteen johtaneen tapahtumaketjun [4] .
Kuten muidenkin turvallisuuden kannalta kriittisten järjestelmävirheiden kohdalla, onnettomuus johtui useammasta kuin yhdestä syystä. Kehityksen ja testauksen aikana oli monia vaiheita, joissa vika voitiin tunnistaa [12] . Pääasiallisiksi syiksi on mainittu seuraavat [4] :
Valiokunta korosti, että sekä tilaajasta että järjestelmäurakoitsijasta riippumattomien organisaatioiden asiantuntijat eivät olleet mukana valvontaprosessissa, mikä loukkasi toimeenpano- ja valvontatoimintojen erottamisen periaatetta. Väitteitä esitettiin sekä testausprosessista että todentamisstrategiasta. Joten testaus- ja virheenkorjausvaiheessa oli teknisesti mahdollista tutkia ISO:n toimintaa integroidun lentosimuloinnin avulla, mikä mahdollistaisi virheen havaitsemisen lähes varmasti. Koko laitteisto-ohjelmistokompleksin toimintaa simuloitaessa ISO kuitenkin katsottiin mustaksi laatikoksi , joka toimii oikein. Huomio kiinnitettiin keskinäiseen epäjohdonmukaisuuteen luotettavuuden varmistamisen ja tietokoneen suurimman sallitun kuormituksen ilmoittamisen välillä. Lisäksi kritisoitiin poikkeustilanteiden käsittelymekanismia, joka toimi erillään koko tilanteen yleisestä kontekstista, ja sen seurauksena ”tuli kuin lääkäri, joka ilman minkäänlaista tutkimusta ampui luokseen tulleen potilaan käsittämättömällä oireita, jotta hän ei kärsisi." Tämä toteutus oli seurausta käytännöstä sulkea laitteistoyksiköt radikaalisti laitteistovian sattuessa olettaen, että varayksikön vian todennäköisyys on erittäin pieni. Ariane-5:n tapauksessa oli kuitenkin systemaattinen virhe - koska virhe tapahtui ohjelmistossa, se ilmestyi myös reserviyksikköön [5] .
Komission raportti sisältää seuraavan huomautuksen [4] [10] :
Päämotivaatio Ariane-5:n kehityksessä on vähentää onnettomuusriskiä. ... Poikkeus ei johdu sattumanvaraisesta onnettomuudesta, vaan suunnitteluvirheestä. Poikkeus saatiin kiinni, mutta sitä käsiteltiin väärin, koska katsottiin, että ohjelmaa on pidettävä oikeana, kunnes toisin todistetaan. – – Komissio on päinvastainen, että ohjelmistoa olisi pidettävä virheellisenä, kunnes tällä hetkellä hyväksyttyjen parhaiden käytäntöjen käyttö osoittaa sen oikeaksi.
Alkuperäinen teksti (englanniksi)[ näytäpiilottaa] Ariane 5:n kehityksen taustalla oleva teema on suuntautuminen satunnaisten epäonnistumisten lieventämiseen. … Poikkeus ei johtunut satunnaisesta viasta vaan suunnitteluvirheestä. Poikkeus havaittiin, mutta sitä käsiteltiin epäasianmukaisesti, koska näkemys oli, että ohjelmistoa pitäisi pitää oikeana, kunnes sen vika osoitetaan. … Lautakunta kannattaa päinvastaista näkemystä, että ohjelmiston pitäisi olettaa olevan viallinen, kunnes tällä hetkellä hyväksyttyjen parhaiden käytäntöjen menetelmien soveltaminen voi osoittaa sen olevan oikein.Ariane 5:n huoltotiimi selitti tapahtuneelle seuraavat [4] :
Tästä epäonnistuneesta käynnistämisestä tuli yksi historian kalleimmista tietokonevirheistä . Arviot aineellisista menetyksistä vaihtelevat 360 miljoonasta 500 miljoonaan dollariin ( joka sisältää raketin kustannusten lisäksi myös tieteelliset hyötykuormalaitteet). Lisäksi useita viraston myöhempiä kaupallisia lanseerauksia ei tapahtunut, Ariane-5-ohjelma viivästyi vuodella ja ESA menetti maineensa markkinoilla [n. 3] [5] [13] [14] .
Onnettomuuden seurauksena katosi 4 ESA-satelliittia "Cluster", jotka oli suunniteltu tutkimaan Maan magneettikenttää. Saman vuoden heinäkuussa ESA tarjoutui luomaan tämän projektin uudelleen ainakin yhdellä satelliitilla, jolle annettiin nimi "Phoenix". Projekti sisälsi yhden satelliitin, jolla piti olla samat instrumentit kuin kadonneilla Cluster-satelliiteilla. Vuoden 1997 puoliväliin mennessä kaikki instrumentit oli testattu ja uusi Phoenix-satelliitti oli valmis laukaisuun. Mutta koska yksi satelliitti ei pystynyt tarjoamaan neljän satelliitin antamaa oikeaa tieteellistä tietoa, ESA päätti luoda koko tehtävän uudelleen osaksi neljää satelliittia nimeltä "Cluster-2". Laukaisu suunniteltiin kesällä 2000, koska tämä oli auringon aktiivisuuden odotettu huippuvuosi. Riskin vähentämiseksi satelliittien laukaisu uskottiin venäläiselle Sojuz-kantoraketille Fregat -ylävaiheessa . Ensimmäinen satelliittipari laukaistiin onnistuneesti kiertoradalle 16. heinäkuuta 2000 ja toinen pari 9. elokuuta samana vuonna [15] [8] .
Ariane-5:n myöhempiä laukaisuja varten suoritettiin seuraavat toimet [3] :
Jokaiselle järjestelmän laitteelle tehtiin komission suositusten perusteella kolmannen osapuolen kooditarkastus . Myös useita organisatorisia toimenpiteitä toteutettiin kumppanien välisten vuorovaikutusprosessien avoimuuden lisäämiseksi ja selkeän toimivallan ja vastuun jaon avulla. Ohjelmistojen validointi sisälsi jo yksikkötestauksen , integraatiotestauksen , toiminnallisen validoinnin , koodikattavuuden analyysin ja sertifioinnin, ja tästä huolimatta ohjelmisto validoitiin staattisen koodianalyysin avulla abstraktin tulkinnan avulla. Vain kaksi monimutkaisinta ja turvallisuuden kannalta kriittisintä moduulia varmistettiin - ISO ja keskuslentomoduuli - joissa oli 30 ja 60 tuhatta koodiriviä Ada - kielellä . Nämä testit olivat ensimmäisiä staattisen analyysin sovelluksia suurissa teollisissa ohjelmistojärjestelmissä ja vaikuttivat staattisten analyysimenetelmien leviämiseen [16] [17] .
Seuraava Ariane-5 laukaisu tapahtui lokakuussa 1997, ja sitten raketti laukaisi yhden satelliitin " KYLLÄ". Laukaisua pidettiin osittain onnistuneena, koska hyötykuorma asetettiin liian matalalle kiertoradalle moottoreiden ennenaikaisen sammutuksen vuoksi. Tämä virhe selitettiin ja korjattiin lennon jälkeen, mutta siitä huolimatta asiakkaiden luottamus uuteen rakettiin kärsi, ja tästä syystä tehtiin useita Ariane-4 laukaisuja vuoteen 2003 asti [18] .
Tapahtuneella onnettomuudella oli suuri resonanssi - sekä suurten aineellisten menetysten vuoksi että operatiivisen tutkinnan tuloksena, jolle oli ominaista tulosten avoimuus [5] .
J.-M. Zezekelja Bertrand Meyer tulivat siihen tulokseen, että ohjelmistovirhe on heidän mielestään luonteeltaan puhtaasti tekninen ja johtuu virheellisistä ohjelmistojen uudelleenkäyttötavoista ja että uudelleenkäytettävän moduulin tarkan spesifikaation puute oli kohtalokas. Selvitys osoitti, että vaatimus 16 bittiin mahtuvasta maksimiarvosta hävisi pääasiakirjan liitteistä. Lisäksi ei ollut huomautusta tai viittausta asiakirjaan, joka olisi tukenut tätä väitettä. Ongelman ratkaisemiseksi kirjoittajat ehdottivat sopimussuunnittelun periaatteen käyttöä [k. 4] , kun määritellään "sopimus", jossa määritellään komponentin syöttö- ja lähtöparametreja koskevat ehdot, ja tekijät ovat toimittaneet "luonnoksen" tällaisesta sopimuksesta. Kirjoittajien mukaan tämä voisi paljastaa ongelman sekä testausvaiheessa että lennon aikana [14] .
Jezekelin ja Meyerin näkökulma aiheutti paljon vastauksia. Yksityiskohtaisimman kriittisen analyysin artikkelistaan teki Lockheed Martin Tactical AirCraft Systemsin työntekijä , tunnettu kriittisten järjestelmien kehittämisen asiantuntija Ken Garlington [ 19 ] . Joten hän huomasi, että Zhesekelin ja Meyerin ehdottama sopimus sisältää virheen, koska siinä oletetaan, että E_BH :n arvo muunnetaan kokonaisluvusta, mutta todellisuudessa tapahtui muunnos reaaliluvusta. Samalla oli merkittävää, että vain Garlington kiinnitti huomion melko ilmeiseen ongelmaan, kun taas monet pätevät asiantuntijat lukivat artikkelin ja keskustelivat siitä julkisesti. Lisäksi Garlington käsitteli yksityiskohtaisesti ei-triviaaleja ongelmia, joita syntyy, kun kirjoitetaan ei "luonnos", vaan täydellinen eritelmä sopimuksesta tiettyyn tilanteeseen. Garlingtonin johtopäätös osoittaa, että ongelma on monimutkainen ja johtuu ensisijaisesti järjestelmien, kuten "Arian" [5] , objektiivisesta monimutkaisuudesta .
Journal of Automated Software Engineering -lehden päätoimittaja Bashar Nuzaybehsuoritti tarkastelun eri näkökulmista onnettomuuden syistä ja tuli siihen tulokseen, että "kaikki ovat oikeassa". Bashar katsoi, että onnettomuus liittyy ohjelmistojärjestelmien kehittämisen yleisiin ongelmiin, ja totesi lisäksi, että kehitys- ja todentamiseen osallistuvien asiantuntijoiden intressien eriyttäminen (joka liittyy olio- ja komponenttiteknologian kaltaisten lähestymistapojen laajaan käyttöön) ei saa kunnollista tasapainottavaa vastapainoa johdon puolelta, jonka on koordinoitava koko työprosessi oikealla tasolla [12] .