Den Europæiske Rumorganisations ( ESA) Ariane 5 løfteraket styrtede ned under sin første opsendelse, den 4. juni 1996 ved Kourou-rumhavnen . Raketten kollapsede i det 40. sekund af flyvningen på grund af forkert betjening af softwaren ombord .
Denne lanceringsfejl var en af de mest kostbare computerfejl i historien, med skøn over materielle tab alene, der spændte fra $360 millioner til $500 millioner [ . Fejlen opstod i softwaren arvet fra den tidligere Ariane-4 raket, da modulet ikke blev testet i det nye miljø .
Som følge af ulykken gik 4 ESA-satellitter tabt « Cluster", designet til at studere Jordens magnetfelt . Dette videnskabelige program blev udskudt, og efterfølgende Cluster-2 satellitterneblev affyret af Soyuz- missiler i sommeren 2000 .
Ulykken, der fandt sted, havde stor resonans - både på grund af store materielle tab, og som følge af en operationel undersøgelse, præget af åbenheden i resultaterne og udført med deltagelse af specialister fra interesserede europæiske lande. Kommissionen var i stand til at finde og genskabe fejlen ved at rekonstruere begivenhederne under flyvningen .
Efter udviklingen af tidligere versioner af Ariane -missilerne blev der i slutningen af 1987 truffet en beslutning om at skabe et nyt Ariane-5-system, som skulle gøre ESA til førende inden for opsendelser på det kommercielle marked. Karakteristikaene ved den nye løfteraket var at tillade både opsendelse af telekommunikationssatellitter og muligheden for at opsende Hermes - shuttlen . På trods af at arbejdet på rumfærgen blev indskrænket i 1992, fortsatte udviklingen af Ariane-5 for den potentielle implementering af bemandet astronautik . Den erklærede pålidelighed burde ikke have været mindre end 0,98 for de betragtede 50-100 opsendelser, og opsendelsesomkostningerne sammenlignet med Ariane-4 skulle have været reduceret med 10 % [1] [2] .
Arbejdet med Ariane-5 blev udført i omkring 10 år, og 7 milliarder dollars blev brugt på udvikling. Ariane 5 var baseret på den tidligere model, Ariane 4 , som med succes blev lanceret 90 gange ud af 93 [3] [4] [5] . I februar 1994 blev der udstedt en industriel ordre til fremstilling af 14 løfteraketter til opsendelser i 1996-1999, og den første flyvning var planlagt til oktober 1995. En af opgaverne ved de to første opsendelser var at demonstrere løfterakettens evne til at bringe nyttelasten i kredsløb. Den første opsendelse blev udskudt flere gange og fandt sted i sommeren 1996 [1] .
Nyttelasten for den første opsendelse af raketten, som omfatter fire Cluster-satellitter, var 4681 kg [6] . Denne opsendelse skulle implementere en af faserne af det videnskabelige program "Cluster", som blev initieret af ESA i 1982 i samarbejde med NASA [7] . Missionens opgave var at måle små svingninger af Jordens magnetosfære og solvindens indvirkning på den på grund af solaktivitet . Til dette blev en multi-satellit mission designet, da synkrone målinger var påkrævet på flere satellitter placeret på forskellige punkter i det ydre rum. "Ariane-5" skulle samtidig opsende fire "Cluster"-satellitter ind i en mellemliggende geostationær bane [8] .
Vejret om morgenen den 4. juni 1996 var acceptabelt og Ariane-5 raketten (serienummer 501) blev leveret til opsendelsesstedet ( ELA-3 , Kourou rumhavn [9] ) - opsendelsestiden var planlagt til 8:35 lokal tid (11:00). 35 UTC ). Nedtællingen , som omfattede klargøring af raketten, forløb gnidningsfrit indtil 7 minutter før opsendelsen, hvor sigtforholdene forværredes, og i forbindelse hermed blev opsendelsen udskudt. Det nye starttidspunkt H 0 blev sat til 09:33:59 lokal tid [10] .
36,7 sekunder efter tænding (H 0 +36,7) [r. 1] flyvningen forløb normalt. Efter dette øjeblik begyndte raketten, placeret i en højde af ~ 3700 m, pludselig at afvige fra den planlagte bane, at falde fra hinanden og eksploderede i det 40. sekund (H 0 +40). Dette skete i begyndelsen af flyvningen - den nominelle driftstid for første trins motorer er 575 sekunder [10] [3] .
Fra den umiddelbare analyse af dataene blev det fastslået, at raketten opførte sig normalt indtil det øjeblik, hvor den pludselig afveg fra kursen og selvdestruerede. Eksplosionen fandt sted i en højde af ~ 4 km, i en afstand af 1 km fra affyringsrampen, og fragmenterne blev spredt over et område på omkring 12 km 2 i savannen og sumpene. Nogle fragmenter faldt i nærheden af affyringsrampen, men den forblev intakt. Der var ingen tilskadekomne under denne hændelse. Vejret var acceptabelt, og det kunne ikke have haft indflydelse. Samtidig viste flyvedata, at de systemer, der styrer dyserne på den faste drivmiddelbooster (det aktive system og det primære Inertial Orientation System , IOS) svigtede næsten samtidigt før ødelæggelsen af raketten [4] [3] .
Dagen efter ulykken begyndte dannelsen af en undersøgelseskommission. Det blev ledet af en repræsentant for det franske videnskabsakademi , professor Jacques-Louis Lions , og kommissionen omfattede videnskabsmænd og specialister fra interesserede europæiske lande. Den 13. juni startede hun på arbejde. Kommissionen blev forsynet med telemetridata for raketten, banedata (fra radarstationer og fra optiske observationsposter) samt information modtaget fra det faldne affald og den genoprettede IDF. Derudover kom individuelle komponenter af raketten, inklusive dem, der blev brugt til test og inspektion, i besiddelse. Til øjeblikkelig levering af alle data blev der dannet et særligt teknisk udvalg af kommissionen fra repræsentanter for kunder og entreprenører. Dele af raketten og udstyret blev samlet og undersøgt, ligesom specialisternes vidneudsagn blev hørt og produktions- og driftsdokumentationen blev studeret [4] [5] .
Efter analysen og simuleringen blev flyvehændelserne rekonstrueret [10] [4] [5] :
Der opstod en fejl i ISO-programmodulet under konverteringen af et 64-bit reelt tal til et 16-bit fortegnet heltal , og derved opstod et aritmetisk overløb af sidstnævnte. Denne variabel ( E_BH , Bias Horizontal , horisontal forskydning) viste den vandrette forskydning af inertiplatformen og var relateret til rakettens horisontale hastighed [10] . Programmodulet, der forårsagede fejlen, havde syv variabler, hvoraf fire var beskyttet. Den kodelinje, der fik fejlen til at køre, ser sådan ud [11] :
P_M_DERIVE(T_ALG.E_BH) := UC_16S_DA_16NS(TDB.T_ENTIER_16S ((1,0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)))Et træk ved aktiveringen af dette modul var, at Ariane-5-systemet havde en anden rækkefølge til at udføre handlinger før flyvningen, forskellig fra Ariane-4. Denne forskel var så stor, at driften af det fejlslagne programmodul efter starten ikke var nødvendig, men modulet blev genbrugt uden ændringer.
Kommissionen var i stand til hurtigt at finde fejlen [til. 2] på grund af tilgængeligheden af måledata, simuleringsmiljøer og dokumentation. Meteorologiske data udelukkede vejrets indflydelse, telemetri gjorde det muligt at bestemme flyvestiens reelle data. Dette gjorde det muligt at indsnævre området for potentielle defekter og på grundlag af den modtagne information at udføre simuleringsmodellering, som nøjagtigt gengav den begivenhedskæde, der førte raketten til en ulykke [4] .
Som det er tilfældet med andre sikkerhedskritiske systemfejl, var ulykken forårsaget af mere end én årsag. Under udvikling og test var der mange stadier, hvor en defekt kunne identificeres [12] . Følgende er nævnt som hovedårsagerne [4] :
Kommissionen understregede, at specialister fra organisationer, der er uafhængige af både kunden og systementreprenøren, ikke var involveret i kontrolprocessen, hvilket var i strid med princippet om adskillelse af udøvende og kontrolfunktioner. Der blev fremsat krav både til testprocessen og til verifikationsstrategien. Så på test- og fejlfindingsstadiet var det teknisk muligt at undersøge driften af ISO'en gennem den integrerede flysimulering, hvilket ville gøre det muligt næsten med sikkerhed at opdage en fejl. Når man simulerede driften af hele hardware-softwarekomplekset, blev ISO imidlertid betragtet som en sort boks , der fungerer korrekt. Opmærksomheden blev henledt på den gensidige uoverensstemmelse mellem behovet for at sikre pålidelighed og erklæringen om den maksimalt tilladte belastning på computeren. Derudover blev mekanismen til håndtering af ekstraordinære situationer kritiseret, som fungerede isoleret fra den generelle kontekst af hele situationen, og som et resultat, "blev det som en læge, der uden nogen undersøgelse skød en patient, der kom til ham med uforståelig symptomer, så han ikke ville lide." Denne implementering var en konsekvens af praksis med radikalt at lukke hardwareenheder ned i tilfælde af hardwarefejl, baseret på den antagelse, at sandsynligheden for en fejl i reserveenheden er ekstremt lille. Men i tilfældet Ariane-5 var der en systematisk fejl - da fejlen var lavet i softwaren, dukkede den også op i reserveenheden [5] .
Kommissionens rapport indeholder følgende observation [4] [10] :
Hovedmotivationen i udviklingen af Ariane-5 er at reducere risikoen for en ulykke. ... Undtagelsen, der opstod, skyldes ikke et tilfældigt uheld, men en designfejl. En undtagelse blev fanget, men håndteret forkert, fordi man mente, at programmet skulle anses for korrekt, indtil det modsatte er bevist. … Kommissionen er af den modsatte opfattelse, nemlig at software bør betragtes som fejlagtig, indtil brugen af aktuelt accepteret bedste praksis viser, at den er korrekt.
Originaltekst (engelsk)[ Visskjule] Et underliggende tema i udviklingen af Ariane 5 er bias mod afbødning af tilfældige fejl. … Undtagelsen, der opstod, skyldtes ikke tilfældig fejl, men en designfejl. Undtagelsen blev opdaget, men uhensigtsmæssigt håndteret, fordi man havde antaget, at software skulle anses for korrekt, indtil det viser sig at være fejlagtigt. … Bestyrelsen går ind for det modsatte synspunkt, nemlig at software skal antages at være defekt, indtil anvendelse af de aktuelt accepterede best practice-metoder kan påvise, at den er korrekt.Ariane 5-vedligeholdelsesteamet gav følgende forklaringer på, hvad der skete [4] :
Denne mislykkede lancering blev en af de mest kostbare computerfejl i historien. Estimater af materielle tab varierer fra $360 millioner til $500 millioner ( som ikke kun inkluderer omkostningerne til raketten, men også det videnskabelige nyttelastudstyr). Derudover fandt en række efterfølgende kommercielle lanceringer af agenturet ikke sted, Ariane-5-programmet blev forsinket med et år, og ESA mistede sit omdømme på markedet [ca. 3] [5] [13] [14] .
Som følge af ulykken gik 4 ESA-satellitter "Cluster", designet til at studere Jordens magnetfelt, tabt. I juli samme år tilbød ESA at genskabe dette projekt på mindst én satellit, som fik navnet "Phoenix". Projektet omfattede én satellit, som skulle have de samme instrumenter, som var på de tabte Cluster-satellitter. I midten af 1997 var alle instrumenter blevet testet, og den nye Phoenix-satellit var klar til opsendelse. Men da en satellit ikke kunne give den korrekte videnskabelige information, som fire satellitter kunne give, besluttede ESA at genskabe hele missionen som en del af fire satellitter kaldet "Cluster-2". Lanceringen var planlagt til sommeren 2000, da dette var det forventede topår for solaktivitet. For at reducere risikoen blev opsendelsen af satellitterne overdraget til den russiske Soyuz løfteraket ved hjælp af Fregat øvre trin . Det første par satellitter blev med succes opsendt i kredsløb den 16. juli 2000, og det andet par blev opsendt med succes den 9. august samme år [15] [8] .
Til efterfølgende lanceringer af Ariane-5 blev følgende aktiviteter udført [3] :
Baseret på anbefalingerne fra Kommissionen blev der udført en tredjeparts kodeinspektion for hver af enhederne i systemet . Der blev også truffet en række organisatoriske tiltag for at gøre processerne for samspil mellem partnere mere gennemsigtige med en klar fordeling af beføjelser og ansvar. Softwarevalidering inkluderede allerede enhedstest , integrationstest , funktionel validering , kodedækningsanalyse og certificering, og på trods af dette blev softwaren valideret ved statisk kodeanalyse gennem abstrakt fortolkning. Kun de to mest komplekse og sikkerhedskritiske moduler blev verificeret - ISO og det centrale flymodul - hvori der var henholdsvis 30 og 60 tusind linjer kode på Ada -sproget . Disse tests var blandt de første anvendelser af statisk analyse til store industrielle softwaresystemer og bidrog til udbredelsen af statiske analysemetoder [16] [17] .
Den næste opsendelse af Ariane-5 fandt sted i oktober 1997, og derefter opsendte raketten én satellit " JA". Denne opsendelse blev betragtet som delvist vellykket, da nyttelasten blev sat i en for lav bane på grund af for tidlig nedlukning af motorerne. Denne fejl blev forklaret og rettet efter flyvningen, men ikke desto mindre led kundernes tillid til den nye raket, og af denne grund blev der foretaget en række Ariane-4 opsendelser indtil 2003 [18] .
Ulykken, der fandt sted, fik stor resonans - både på grund af store materielle tab, og som følge af en operationel undersøgelse, præget af resultaternes åbenhed [5] .
J.-M. Zhezekelog Bertrand Meyer kom til den konklusion, at softwarefejlen efter deres mening er af rent teknisk karakter og er forankret i forkert praksis for genbrug af software, og manglen på en nøjagtig specifikation af det genanvendelige modul spillede en fatal rolle. Undersøgelsen viste, at kravet om en maksimal værdi, der passer i 16 bit, gik tabt i bilagene til hovedspecifikationsdokumentet. Derudover var der ingen kommentarer eller henvisning til et dokument, der underbyggede denne påstand. For at løse problemet foreslog forfatterne at bruge princippet om kontraktdesign [k. 4] når der er specificeret en "kontrakt", der definerer betingelserne for input- og outputparametrene for komponenten, og forfatterne har givet et "udkast" til en sådan kontrakt. Ifølge forfatterne kunne dette afsløre problemet både på teststadiet og under flyvningen [14] .
Jezekels og Meyers synspunkt forårsagede mange reaktioner. Den mest detaljerede kritiske analyse af deres artikel blev udført af Lockheed Martin Tactical AirCraft Systems-medarbejder , en velkendt ekspert i udvikling af kritiske systemer, Ken Garlington [ 19 ] . Så han bemærkede, at kontrakten foreslået af Zhesekel og Meyer indeholder en fejl, da den antager, at værdien af E_BH er konverteret fra et heltal, men i virkeligheden var der en konvertering fra et reelt tal. Samtidig var det markant, at kun Garlington gjorde opmærksom på et ret åbenlyst problem, mens artiklen blev læst og offentligt diskuteret af mange kvalificerede specialister. Derudover diskuterede Garlington i detaljer de ikke-trivielle problemer, der opstår, når man ikke skriver et "udkast", men en komplet specifikation af en kontrakt for en given specifik situation. Garlingtons konklusion viser, at problemet er komplekst og primært skyldes den objektive kompleksitet af systemer som "Arian" [5] .
Chefredaktør for Journal of Automated Software Engineering Bashar Nuzaybehgennemførte en gennemgang af forskellige synspunkter på årsagerne til ulykken og kom frem til, at "alle har ret." Bashar mente, at ulykken er relateret til de generelle problemer med at udvikle softwaresystemer og bemærkede desuden, at adskillelsen af interesser hos de specialister, der er involveret i udvikling og verifikation (som er forbundet med den udbredte introduktion af tilgange såsom objektorienterede og komponentteknologier) får ikke en ordentlig balancerende modvægt på ledelsens side, som skal koordinere hele arbejdsprocessen på det rette niveau [12] .