Europeiska rymdorganisationens ( ESA) bärraket Ariane 5 kraschade under sin första uppskjutning, den 4 juni 1996 vid rymdhamnen Kourou . Raketen kollapsade vid den 40:e sekunden av flygningen på grund av felaktig användning av programvaran ombord .
Detta lanseringsfel var ett av de mest kostsamma datorfelen i historien, med uppskattningar av enbart materiella förluster som sträckte sig från $360 miljoner till $500 miljoner [ . Felet inträffade i programvaran som ärvts från den tidigare Ariane-4- raketen, när modulen inte testades i den nya miljön .
Som ett resultat av olyckan gick 4 ESA-satelliter förlorade « Cluster", designad för att studera jordens magnetfält . Detta vetenskapliga program sköts upp, och därefter Cluster-2- satelliternalanserades av Soyuz -missiler sommaren 2000 .
Olyckan som inträffade hade stor resonans - både på grund av stora materiella förluster, och som ett resultat av en operativ undersökning, präglad av öppenheten i resultaten och utförd med deltagande av specialister från intresserade europeiska länder. Kommissionen kunde hitta och återskapa felet genom att rekonstruera händelserna under flygningen .
Efter utvecklingen av tidigare versioner av Ariane -missilerna togs ett beslut i slutet av 1987 att skapa ett nytt Ariane-5-system, vilket skulle göra ESA till en ledare inom uppskjutningar på den kommersiella marknaden. Egenskaperna för den nya bärraketen var att tillåta både uppskjutning av telekommunikationssatelliter och möjligheten att skjuta upp Hermes -skytteln . Trots det faktum att arbetet med skytteln avbröts 1992, fortsatte utvecklingen av Ariane-5 för den potentiella implementeringen av bemannad astronautik . Den deklarerade tillförlitligheten borde inte ha varit mindre än 0,98 för de övervägda 50-100 uppskjutningarna, och uppskjutningskostnaden jämfört med Ariane-4 borde ha minskat med 10 % [1] [2] .
Arbetet med Ariane-5 utfördes i cirka 10 år och 7 miljarder dollar spenderades på utveckling. Ariane 5 baserades på den tidigare modellen, Ariane 4 , som lanserades framgångsrikt 90 gånger av 93 [3] [4] [5] . I februari 1994 utfärdades en industriell order för tillverkning av 14 bärraketer för uppskjutningar 1996-1999, och den första flygningen var planerad till oktober 1995. En av uppgifterna för de två första uppskjutningarna var att demonstrera bärraketens förmåga att föra nyttolasten i omloppsbana. Den första lanseringen sköts upp flera gånger och ägde rum sommaren 1996 [1] .
Nyttolasten för den första uppskjutningen av raketen, som inkluderar fyra Cluster-satelliter, var 4681 kg [6] . Denna uppskjutning var tänkt att genomföra ett av stegen i det vetenskapliga programmet "Cluster", som initierades av ESA 1982 i samarbete med NASA [7] . Uppdraget var att mäta små svängningar av jordens magnetosfär och solvindens inverkan på den på grund av solaktiviteten . För detta designades ett multisatellituppdrag, eftersom synkrona mätningar krävdes på flera satelliter placerade på olika punkter i yttre rymden. "Ariane-5" var tänkt att samtidigt skjuta upp fyra "kluster"-satelliter in i en mellanliggande geostationär bana [8] .
Vädret på morgonen den 4 juni 1996 var acceptabelt och Ariane-5-raketen (serienummer 501) levererades till uppskjutningsplatsen ( ELA-3 , Kourou rymdhamn [9] ) - uppskjutningstiden var planerad till 8:35 lokal tid (11:00). 35 UTC ). Nedräkningen , som innefattade förberedelse av raketen, gick smidigt fram till 7 minuter före uppskjutning, då siktförhållandena försämrades, och i samband med detta sköts uppskjutningen upp. Den nya starttiden H 0 sattes till 09:33:59 lokal tid [10] .
36,7 sekunder efter tändning (H 0 +36,7) [r. 1] flygningen fortskred normalt. Men efter detta ögonblick avvek raketen, som ligger på en höjd av ~ 3700 m, plötsligt från den planerade banan, falla isär och exploderade vid den 40:e sekunden (H 0 +40). Detta hände i början av flygningen - den nominella drifttiden för förstastegsmotorerna är 575 sekunder [10] [3] .
Från den omedelbara analysen av uppgifterna fastställdes det att raketen betedde sig normalt fram till det ögonblick då den plötsligt avvek från kursen och självförstörde. Explosionen inträffade på en höjd av ~ 4 km, på ett avstånd av 1 km från startrampen, och fragmenten spreds över ett område på cirka 12 km 2 i savannen och träsk. Några fragment föll nära startrampen, men den förblev intakt. Det var inga skadade under denna händelse. Vädret var acceptabelt och det kunde inte ha påverkat. Samtidigt visade flygdata att systemen som styr munstyckena på den fasta drivmedelsboostern (det aktiva systemet och det primära tröghetsorienteringssystemet , IOS) misslyckades nästan samtidigt före förstörelsen av raketen [4] [3] .
Dagen efter olyckan började bildandet av en utredningskommission. Den leddes av en representant för den franska vetenskapsakademin , professor Jacques-Louis Lions , och i kommissionen ingick vetenskapsmän och specialister från intresserade europeiska länder. Den 13 juni började hon jobba. Kommissionen försågs med telemetridata för raketen, banadata (från radarstationer och från optiska observationsposter), samt information som mottagits från det fallna skräpet och den återvunna IDF. Dessutom kom enskilda komponenter i raketen, inklusive de som användes för testning och inspektion, i besittning. För att omedelbart tillhandahålla all data bildades en speciell teknisk kommitté av kommissionen från representanter för kunder och entreprenörer. Delar av raketen och utrustningen monterades och studerades, liksom vittnesmål från specialister hördes och produktions- och operativ dokumentation studerades [4] [5] .
Efter analysen och simuleringen rekonstruerades flyghändelserna [10] [4] [5] :
Ett fel inträffade i ISO-programmodulen under omvandlingen av ett 64-bitars reellt tal till ett 16-bitars heltal med tecken , och då inträffade ett aritmetiskt överflöde av det senare. Denna variabel ( E_BH , Bias Horizontal , horisontell förskjutning) visade den horisontella förskjutningen av tröghetsplattformen och var relaterad till raketens horisontella hastighet [10] . Programmodulen som orsakade felet hade sju variabler, varav fyra var skyddade. Kodraden som fick felet att köras ser ut så här [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)))Ett särdrag för aktiveringen av denna modul var att Ariane-5-systemet hade en annan ordning för att utföra åtgärder före flygningen, annorlunda än Ariane-4. Denna skillnad var så stor att driften av den misslyckade programmodulen efter starten inte behövdes, utan modulen återanvändes utan några modifieringar.
Kommissionen kunde snabbt finna felet [till. 2] på grund av tillgången på mätdata, simuleringsmiljöer och dokumentation. Meteorologiska data uteslöt påverkan av vädret, telemetri gjorde det möjligt att bestämma de verkliga data för flygvägen. Detta gjorde det möjligt att begränsa området för potentiella defekter och, på basis av den mottagna informationen, genomföra simuleringsmodeller, som exakt återgav den händelsekedja som ledde raketen till en olycka [4] .
Som är fallet med andra säkerhetskritiska systemfelolyckan orsakades av mer än en orsak. Under utveckling och testning fanns det många stadier där en defekt kunde identifieras [12] . Följande är namngivna som de främsta orsakerna [4] :
Kommissionen betonade att specialister från organisationer oberoende av både kunden och systementreprenören inte var involverade i kontrollprocessen, vilket bröt mot principen om åtskillnad av verkställande och kontrollfunktioner. Anspråk gjordes både på testprocessen och på verifieringsstrategin. Så vid test- och felsökningsstadiet var det tekniskt möjligt att undersöka driften av ISO genom den integrerade flygsimuleringen, vilket skulle göra det möjligt att nästan säkert upptäcka ett fel. Men när man simulerade driften av hela hårdvaru-mjukvarukomplexet ansågs ISO vara en svart låda som fungerar korrekt. Uppmärksamheten uppmärksammades på den ömsesidiga inkonsekvensen mellan behovet av att säkerställa tillförlitlighet och deklarationen av den maximala tillåtna belastningen på datorn. Dessutom kritiserades mekanismen för att hantera exceptionella situationer, som fungerade isolerat från hela situationens allmänna kontext, och som ett resultat blev det som en läkare som utan någon undersökning sköt en patient som kom till honom med oförstående symtom så att han inte skulle lida.” Denna implementering var en följd av bruket att radikalt stänga av hårdvaruenheter i händelse av hårdvarufel, baserat på antagandet att sannolikheten för ett fel i reservenheten är extremt liten. Men i fallet med Ariane-5 var det ett systematiskt fel - eftersom felet gjordes i mjukvaran förekom det även i reservenheten [5] .
Kommissionens rapport innehåller följande observation [4] [10] :
Den främsta motivationen i utvecklingen av Ariane-5 är att minska risken för en olyckshändelse. ... Undantaget som inträffade beror inte på en slumpmässig olycka, utan på ett konstruktionsfel. Ett undantag fångades upp men hanterades felaktigt eftersom man ansåg att programmet skulle anses korrekt tills motsatsen bevisats. … Kommissionen har den motsatta uppfattningen, att programvara bör anses vara felaktig tills användningen av för närvarande accepterade bästa praxis visar att den är korrekt.
Originaltext (engelska)[ visaDölj] Ett underliggande tema i utvecklingen av Ariane 5 är fördomen mot att lindra slumpmässiga misslyckanden. … Undantaget som inträffade berodde inte på ett slumpmässigt fel utan ett konstruktionsfel. Undantaget upptäcktes, men hanterades olämpligt eftersom man ansåg att programvaran borde anses vara korrekt tills den visar sig vara fel. … Styrelsen är positiv till den motsatta uppfattningen, att programvara bör antas vara felaktig tills tillämpning av de för närvarande accepterade bästa praxismetoderna kan visa att den är korrekt.Ariane 5-underhållsteamet gav följande förklaringar till vad som hände [4] :
Denna misslyckade lansering blev ett av de mest kostsamma datorfelen i historien. Uppskattningar av materiella förluster sträcker sig från $360 miljoner till $500 miljoner ( vilket inkluderar inte bara kostnaden för raketen, utan också den vetenskapliga nyttolastutrustningen). Dessutom skedde inte ett antal efterföljande kommersiella lanseringar av byrån, Ariane-5-programmet försenades med ett år och ESA förlorade sitt rykte på marknaden [ca. 3] [5] [13] [14] .
Som ett resultat av olyckan gick 4 ESA-satelliter "Cluster", designade för att studera jordens magnetfält, förlorade. I juli samma år erbjöd sig ESA att återskapa detta projekt på minst en satellit, som fick namnet "Phoenix". Projektet inkluderade en satellit, som skulle ha samma instrument som fanns på de förlorade Cluster-satelliterna. I mitten av 1997 hade alla instrument testats och den nya Phoenix-satelliten var klar för uppskjutning. Men eftersom en satellit inte kunde ge den korrekta vetenskapliga informationen som fyra satelliter kunde ge, beslutade ESA att återskapa hela uppdraget som en del av fyra satelliter kallade "Cluster-2". Lanseringen var planerad till sommaren 2000, eftersom detta var det förväntade toppåret för solaktivitet. För att minska risken anförtroddes uppskjutningen av satelliterna den ryska Soyuz-uppskjutningsfordonet som använde Fregats övre steg . Det första paret satelliter lanserades framgångsrikt i omloppsbana den 16 juli 2000, och det andra paret lanserades framgångsrikt den 9 augusti samma år [15] [8] .
För efterföljande lanseringar av Ariane-5 genomfördes följande aktiviteter [3] :
Baserat på kommissionens rekommendationer genomfördes en kodinspektion från tredje part för var och en av enheterna i systemet . Ett antal organisatoriska åtgärder vidtogs också för att göra processerna för interaktion mellan partners mer transparenta med en tydlig fördelning av befogenheter och ansvar. Mjukvaruvalidering inkluderade redan enhetstestning , integrationstestning , funktionsvalidering , kodtäckningsanalys och certifiering, och trots detta validerades programvaran genom statisk kodanalys genom abstrakt tolkning. Endast de två mest komplexa och säkerhetskritiska modulerna verifierades - ISO och den centrala flygmodulen - där det fanns 30 respektive 60 tusen rader kod på Ada - språket . Dessa tester var bland de första tillämpningarna av statisk analys för stora industriella mjukvarusystem och bidrog till spridningen av statiska analysmetoder [16] [17] .
Nästa uppskjutning av Ariane-5 ägde rum i oktober 1997, och då sköt raketen upp en satellit " JA". Denna uppskjutning ansågs vara delvis lyckad, eftersom nyttolasten sattes i en för låg omloppsbana på grund av för tidig avstängning av motorerna. Detta fel förklarades och korrigerades efter flygningen, men ändå blev kundernas förtroende för den nya raketen lidande, och av denna anledning gjordes ett antal Ariane-4-uppskjutningar fram till 2003 [18] .
Olyckan som inträffade fick stor resonans - både på grund av stora materiella förluster, och som ett resultat av en verksamhetsutredning, präglad av öppenheten i resultaten [5] .
J.-M. Zhezekeloch Bertrand Meyer kom till slutsatsen att mjukvarufelet, enligt deras åsikt, är rent tekniskt till sin natur och har sina rötter i felaktiga metoder för återanvändning av programvara, och avsaknaden av en exakt specifikation av den återanvändbara modulen spelade en ödesdiger roll. Utredningen visade att kravet på ett maxvärde som ryms i 16 bitar gick förlorat i bilagorna till huvudspecifikationsdokumentet. Dessutom fanns det ingen kommentar eller hänvisning till ett dokument som styrkte detta påstående. För att lösa problemet föreslog författarna att man skulle använda principen om kontraktsdesign [k. 4] när ett "kontrakt" specificeras som definierar villkoren för ingångs- och utdataparametrarna för komponenten, och författarna lämnade ett "utkast" till ett sådant kontrakt. Enligt författarna skulle detta kunna avslöja problemet både på teststadiet och under flygningen [14] .
Jezekels och Meyers synvinkel orsakade många reaktioner. Den mest detaljerade kritiska analysen av deras artikel utfördes av Lockheed Martin Tactical AirCraft Systems-anställd , en välkänd expert på utveckling av kritiska system, Ken Garlington [ 19 ] . Så han märkte att kontraktet som föreslagits av Zhesekel och Meyer innehåller ett fel, eftersom det antar att värdet av E_BH konverteras från ett heltal, men i verkligheten var det en konvertering från ett reellt tal. Samtidigt var det betydelsefullt att endast Garlington uppmärksammade ett ganska uppenbart problem, medan artikeln lästes och diskuterades offentligt av många kvalificerade specialister. Dessutom diskuterade Garlington i detalj de icke-triviala problem som uppstår när man inte skriver ett "utkast", utan en fullständig specifikation av ett kontrakt för en given specifik situation. Garlingtons slutsats visar att problemet är komplext och främst beror på den objektiva komplexiteten hos system som "Arian" [5] .
Chefredaktör för Journal of Automated Software Engineering Bashar Nuzaybehgjort en genomgång av olika synpunkter på orsakerna till olyckan och kommit fram till att "alla har rätt". Bashar ansåg att olyckan är relaterad till de allmänna problemen med att utveckla mjukvarusystem och noterade dessutom att separationen av intressen hos de specialister som är involverade i utveckling och verifiering (vilket är förknippat med det omfattande införandet av tillvägagångssätt som objektorienterade och komponentteknologier) får inte en ordentlig balanserande motvikt på ledningens sida, som behöver koordinera hela arbetet på rätt nivå [12] .