Vehiculul de lansare Ariane 5 al Agenției Spațiale Europene ( ESA) s-a prăbușit în timpul primei lansări, pe 4 iunie 1996, în portul spațial Kourou . Racheta s-a prăbușit în a 40-a secundă de zbor din cauza funcționării incorecte a software -ului de bord .
Acest eșec de lansare a fost una dintre cele mai costisitoare erori de calculator din istorie, estimările doar ale pierderilor materiale variind de la 360 de milioane de dolari la 500 de milioane de dolari [ . Eșecul a apărut în software-ul moștenit de la racheta anterioară Ariane-4 , când modulul nu a fost testat în noul mediu .
În urma accidentului, 4 sateliți ESA au fost pierduți « Cluster", conceput pentru a studia câmpul magnetic al Pământului . Acest program științific a fost amânat, iar ulterior sateliții Cluster-2au fost lansate de rachetele Soyuz în vara anului 2000 .
Accidentul care a avut loc a avut o mare rezonanță - atât din cauza pierderilor materiale mari, cât și ca urmare a unei investigații operaționale, caracterizată prin deschiderea rezultatelor și efectuată cu participarea specialiștilor din țările europene interesate. Comisia a reușit să găsească și să reproducă eroarea reconstituind evenimentele zborului .
În urma dezvoltării versiunilor anterioare ale rachetelor Ariane , la sfârșitul anului 1987 a fost luată decizia de a crea un nou sistem Ariane-5, care urma să facă din ESA un lider în lansări pe piața comercială. Caracteristicile noului vehicul de lansare au fost să permită atât lansarea sateliților de telecomunicații, cât și capacitatea de a lansa naveta Hermes . În ciuda faptului că lucrările la navetă au fost reduse în 1992, dezvoltarea Ariane-5 a continuat pentru implementarea potențială a astronauticii cu echipaj . Fiabilitatea declarată nu ar fi trebuit să fie mai mică de 0,98 pentru cele 50-100 de lansări considerate, iar costul de lansare față de Ariane-4 ar fi trebuit redus cu 10% [1] [2] .
Lucrările la Ariane-5 au fost efectuate timp de aproximativ 10 ani și au fost cheltuite 7 miliarde de dolari pentru dezvoltare. Ariane 5 a fost bazat pe modelul anterior, Ariane 4 , care a fost lansat cu succes de 90 de ori din 93 [3] [4] [5] . În februarie 1994, a fost emis un ordin industrial pentru fabricarea a 14 vehicule de lansare pentru lansări în 1996-1999, iar primul zbor a fost programat pentru octombrie 1995. Una dintre sarcinile primelor două lansări a fost de a demonstra capacitatea vehiculului de lansare de a pune sarcina utilă pe orbită. Prima lansare a fost amânată de mai multe ori și a avut loc în vara anului 1996 [1] .
Sarcina utilă pentru prima lansare a rachetei, care include patru sateliți Cluster, a fost de 4681 kg [6] . Această lansare trebuia să implementeze una dintre etapele programului științific „Cluster”, care a fost inițiat de ESA în 1982 în cooperare cu NASA [7] . Sarcina misiunii a fost de a măsura mici oscilații ale magnetosferei Pământului și impactul vântului solar asupra acesteia din cauza activității solare . Pentru aceasta, a fost concepută o misiune multisatelit, deoarece au fost necesare măsurători sincrone pe mai mulți sateliți aflați în puncte diferite din spațiul cosmic. „Ariane-5” trebuia să lanseze simultan patru sateliți „Cluster” pe o orbită geostaționară intermediară [8] .
Vremea în dimineața zilei de 4 iunie 1996 a fost acceptabilă și racheta Ariane-5 (numărul de serie 501) a fost livrată la locul de lansare ( ELA-3 , portul spațial Kourou [9] ) - ora de lansare a fost programată pentru 8:35 ora locală (11:00 a.m.). 35 UTC ). Numărătoarea inversă , care a inclus pregătirea rachetei, a decurs fără probleme până cu 7 minute înainte de lansare, când condițiile de vizibilitate s-au deteriorat și, în legătură cu aceasta, lansarea a fost amânată. Noua oră de pornire H 0 a fost setată la 09:33:59, ora locală [10] .
36,7 secunde după aprindere (H 0 +36,7) [r. 1] zborul a decurs normal. Totuși, după acest moment, racheta, situată la o altitudine de ~ 3700 m, a deviat brusc de la traiectoria planificată, a început să se destrame și a explodat în a 40-a secundă (H 0 +40). Acest lucru s-a întâmplat la începutul zborului - timpul nominal de funcționare al motoarelor din prima etapă este de 575 de secunde [10] [3] .
Din analiza imediată a datelor s-a stabilit că racheta s-a comportat normal până în momentul în care a deviat brusc de la curs și s-a autodistrus. Explozia a avut loc la o altitudine de ~ 4 km, la o distanță de 1 km de rampa de lansare, iar fragmentele au fost împrăștiate pe o suprafață de aproximativ 12 km 2 în savană și mlaștini. Unele fragmente au căzut lângă rampa de lansare, dar aceasta a rămas intactă. Nu au existat victime în timpul acestui incident. Vremea a fost acceptabilă și nu ar fi putut avea un impact. În același timp, datele de zbor au arătat că sistemele care controlează duzele propulsorului cu combustibil solid (sistemul activ și sistemul primar de orientare inerțială , IOS) au eșuat aproape simultan înainte de distrugerea rachetei [4] [3] .
A doua zi după accident a început formarea unei comisii de anchetă. Acesta a fost condus de un reprezentant al Academiei Franceze de Științe , profesorul Jacques-Louis Lions , iar comisia a inclus oameni de știință și specialiști din țările europene interesate. Pe 13 iunie a început să lucreze. Comisiei i-au fost furnizate date de telemetrie ale rachetei, date de traiectorie (de la stațiile radar și de la punctele de observare optică), precum și informații primite de la resturile căzute și IDF recuperate. În plus, au intrat în posesie componente individuale ale rachetei, inclusiv cele folosite pentru testare și inspecție. Pentru furnizarea imediată a tuturor datelor, s-a format un Comitet Tehnic special din comisia din reprezentanți ai clienților și antreprenorilor. Au fost asamblate și studiate părți ale rachetei și echipamentelor, s-au ascultat mărturiile specialiștilor și s-a studiat documentația de producție și exploatare [4] [5] .
După analiză și simulare , evenimentele de zbor au fost reconstruite [10] [4] [5] :
A apărut o eroare în modulul programului ISO în timpul conversiei unui număr real de 64 de biți într-un număr întreg cu semn de 16 biți și, făcând aceasta, a avut loc o depășire aritmetică a acestuia din urmă. Această variabilă ( E_BH , Bias Horizontal , deplasare orizontală) a arătat deplasarea orizontală a platformei inerțiale și a fost legată de viteza orizontală a rachetei [10] . Modulul de program care a cauzat eroarea avea șapte variabile, dintre care patru erau protejate. Linia de cod care a determinat rularea erorii arată astfel [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)))O caracteristică a activării acestui modul a fost că sistemul Ariane-5 avea o ordine diferită pentru efectuarea acțiunilor înainte de zbor, diferită de Ariane-4. Această diferență a fost atât de mare încât nu a fost necesară funcționarea modulului de program eșuat după pornire, dar modulul a fost reutilizat fără modificări.
Comisia a putut găsi rapid greșeala [la. 2] datorită disponibilității datelor de măsurare, a mediilor de simulare și a documentației. Datele meteorologice au exclus influența vremii, telemetria a făcut posibilă determinarea datelor reale ale traseului de zbor. Acest lucru a făcut posibilă restrângerea zonei de defecte potențiale și, pe baza informațiilor primite, efectuarea modelelor de simulare, care au reprodus cu exactitate lanțul de evenimente care au condus racheta la un accident [4] .
Ca și în cazul altor erori de sistem critice pentru securitate, accidentul a fost cauzat din mai multe motive. În timpul dezvoltării și testării, au existat multe etape în care a putut fi identificat un defect [12] . Următoarele sunt denumite drept motive principale [4] :
Comisia a subliniat că în procesul de control nu au fost implicați specialiști din organizații independente atât de client, cât și de contractantul de sistem, ceea ce a încălcat principiul separării funcțiilor executive și de control. S-au făcut revendicări atât la procesul de testare, cât și la strategia de verificare. Deci, în etapa de testare și depanare, a fost posibil din punct de vedere tehnic să se investigheze funcționarea ISO prin simularea integrată a zborului, ceea ce ar face posibilă detectarea aproape sigură a unei erori. Cu toate acestea, la simularea funcționării întregului complex hardware-software, ISO a fost considerat ca o cutie neagră care funcționează corect. S-a atras atenția asupra inconsecvenței reciproce dintre necesitatea asigurării fiabilității și declararea sarcinii maxime admisibile pe computer. În plus, a fost criticat mecanismul de gestionare a situațiilor excepționale, care a funcționat izolat de contextul general al întregii situații și, drept urmare, „a devenit ca un medic care, fără nicio examinare, împușca un pacient care venea la el cu neînțeles. simptome ca să nu sufere.” Această implementare a fost o consecință a practicii de închidere radicală a unităților hardware în cazul oricărei defecțiuni hardware, pe baza presupunerii că probabilitatea unei defecțiuni în unitatea de rezervă este extrem de mică. Totuși, în cazul lui Ariane-5, a existat o eroare sistematică - întrucât eroarea a fost făcută în software, aceasta a apărut și în unitatea de rezervă [5] .
Raportul comisiei conține următoarea observație [4] [10] :
Principala motivație în dezvoltarea lui Ariane-5 este reducerea riscului unui accident accidental. ... Excepția care a apărut nu se datorează unui accident întâmplător, ci unei erori de proiectare. A fost prinsă o excepție, dar a fost tratată incorect, deoarece s-a considerat că programul ar trebui considerat corect până când se dovedește contrariul. […] Comisia consideră opusă, că software-ul ar trebui considerat eronat până când utilizarea celor mai bune practici acceptate în prezent demonstrează că este corect.
Text original (engleză)[ arataascunde] O temă de bază în dezvoltarea lui Ariane 5 este părtinirea față de atenuarea eșecului întâmplător. … Excepția care a apărut nu s-a datorat unei defecțiuni aleatorii, ci unei erori de proiectare. Excepția a fost detectată, dar a fost tratată în mod necorespunzător, deoarece a fost considerat că software-ul ar trebui considerat corect până când se demonstrează că este defect. … Consiliul este în favoarea punctului de vedere opus, conform căruia software-ul ar trebui să fie considerat defectuos până când aplicarea celor mai bune practici acceptate în prezent poate demonstra că este corectă.Echipa de întreținere Ariane 5 a oferit următoarele explicații pentru ceea ce s-a întâmplat [4] :
Această lansare eșuată a devenit una dintre cele mai costisitoare erori de computer din istorie. Estimările pierderilor materiale variază de la 360 de milioane de dolari până la 500 de milioane de dolari ( care include nu numai costul rachetei, ci și echipamentul științific al sarcinii utile). În plus, o serie de lansări comerciale ulterioare ale agenției nu au avut loc, programul Ariane-5 a fost amânat cu un an, iar ESA și-a pierdut reputația pe piață [c. 3] [5] [13] [14] .
În urma accidentului, s-au pierdut 4 sateliți ESA „Cluster”, proiectați să studieze câmpul magnetic al Pământului. În iulie același an, ESA s-a oferit să recreeze acest proiect pe cel puțin un satelit, căruia i s-a dat numele „Phoenix”. Proiectul a inclus un satelit, care ar fi trebuit să aibă aceleași instrumente care erau pe sateliții Cluster pierduți. Până la jumătatea anului 1997, toate instrumentele fuseseră testate, iar noul satelit Phoenix era gata de lansare. Dar, deoarece un satelit nu a putut furniza informațiile științifice adecvate pe care le-ar putea oferi patru sateliți, ESA a decis să recreeze întreaga misiune ca parte a patru sateliți numiți „Cluster-2”. Lansarea a fost programată pentru vara anului 2000, deoarece acesta a fost anul de vârf așteptat pentru activitatea solară. Pentru a reduce riscul, lansarea sateliților a fost încredințată vehiculului de lansare rusesc Soyuz folosind treapta superioară Fregat . Prima pereche de sateliți a fost lansată cu succes pe orbită pe 16 iulie 2000, iar a doua pereche a fost lansată cu succes pe 9 august a aceluiași an [15] [8] .
Pentru lansările ulterioare ale lui Ariane-5 au fost desfășurate următoarele activități [3] :
Pe baza recomandărilor Comisiei, a fost efectuată o inspecție a codului terță parte pentru fiecare dintre dispozitivele din sistem . De asemenea, au fost luate o serie de măsuri organizatorice pentru a face procesele de interacțiune între parteneri mai transparente, cu o distribuție clară a puterilor și responsabilităților. Validarea software-ului includea deja testarea unitară , testarea integrării , validarea funcțională , analiza acoperirii codului și certificarea și, în ciuda acestui fapt, software-ul a fost validat prin analiză statică a codului prin interpretare abstractă .. Au fost verificate doar cele două module cele mai complexe și critice pentru siguranță - ISO și modulul central de zbor - în care existau 30, respectiv 60 de mii de linii de cod în limba Ada . Aceste teste au fost printre primele aplicații ale analizei statice pentru sistemele software industriale mari și au contribuit la răspândirea metodelor de analiză statică [16] [17] .
Următoarea lansare a lui Ariane-5 a avut loc în octombrie 1997, iar apoi racheta a lansat un satelit „ DA". Această lansare a fost considerată parțial reușită, deoarece sarcina utilă a fost pusă pe o orbită prea joasă din cauza opririi premature a motoarelor. Această eroare a fost explicată și corectată după zbor, dar, cu toate acestea, încrederea clienților în noua rachetă a avut de suferit, iar din acest motiv au fost efectuate o serie de lansări Ariane-4 până în 2003 [18] .
Accidentul care a avut loc a avut o mare rezonanță – atât din cauza unor mari pierderi materiale, cât și ca urmare a unei anchete operaționale, caracterizată prin deschiderea rezultatelor [5] .
J.-M. Jezekeliar Bertrand Meyer a ajuns la concluzia că eroarea de software este, în opinia lor, de natură pur tehnică și are rădăcini în practici incorecte de reutilizare a software-ului, iar lipsa unei specificații precise a modulului reutilizabil a jucat un rol fatal. Investigația a arătat că cerința pentru o valoare maximă care se încadrează în 16 biți a fost pierdută în anexele la documentul de specificație principal. În plus, nu a existat niciun comentariu sau referire la un document care să susțină această afirmație. Pentru a rezolva problema, autorii au propus să se folosească principiul proiectării contractului [k. 4] când este specificat un „contract” care definește condițiile pentru parametrii de intrare și de ieșire ai componentei, iar autorii au furnizat o „schiță” a unui astfel de contract. Potrivit autorilor, aceasta ar putea dezvălui problema atât în faza de testare, cât și în timpul zborului [14] .
Punctul de vedere al lui Jezekel și Meyer a provocat o mulțime de răspunsuri. Cea mai detaliată analiză critică a articolului lor a fost efectuată de angajatul Lockheed Martin Tactical AirCraft Systems , un cunoscut expert în dezvoltarea sistemelor critice, Ken Garlington [ 19 ] . Deci, el a observat că contractul propus de Zhesekel și Meyer conține o eroare, deoarece presupune că valoarea lui E_BH este convertită dintr-un număr întreg, dar în realitate a existat o conversie dintr-un număr real. În același timp, a fost semnificativ faptul că doar Garlington a atras atenția asupra unei probleme destul de evidente, în timp ce articolul a fost citit și discutat public de mulți specialiști calificați. În plus, Garlington a discutat în detaliu problemele non-triviale care apar atunci când scrieți nu o „schiță”, ci o specificație completă a unui contract pentru o anumită situație specifică. Concluzia lui Garlington arată că problema este complexă și se datorează în primul rând complexității obiective a unor sisteme precum „Arian” [5] .
Editor-șef al Jurnalului de inginerie software automatizată Bashar Nuzaybeha efectuat o trecere în revistă a diferitelor puncte de vedere asupra cauzelor accidentului și a ajuns la concluzia că „toată lumea are dreptate”. Bashar a considerat că accidentul este legat de problemele generale ale dezvoltării sistemelor software și a remarcat, în plus, că separarea intereselor specialiștilor implicați în dezvoltare și verificare (care este asociată cu introducerea pe scară largă a abordărilor precum tehnologiile orientate pe obiecte și componente) nu primește o contrapondere de echilibrare adecvată din partea conducerii, care trebuie să coordoneze întregul proces de lucru la nivelul corespunzător [12] .