Qual è stato l'impatto storico del volo 501 di Ariane 5?

La disintegrazione del razzo Ariane 5 37 secondi dopo il lancio nel suo viaggio inaugurale ( volo 501 ) viene comunemente definita come uno dei bug software più costosi della storia ¹ :

L'Agenzia spaziale europea ha impiegato 10 anni e 7 miliardi di dollari per produrre Ariane 5, un razzo gigante in grado di lanciare in orbita una coppia di satelliti da tre tonnellate ad ogni lancio e destinato a dare all'Europa una schiacciante supremazia nel settore dello spazio commerciale.

Tutto quello che ci è voluto per far esplodere quel razzo a meno di un minuto nel suo viaggio inaugurale lo scorso giugno, spargendo macerie infuocate nelle paludi di mangrovie della Guyana francese, era un piccolo programma per computer che cercava di inserire un numero a 64 bit in uno spazio a 16 bit.

Un bug, un crash. Di tutte le linee trascurate di codice registrate negli annali dell'informatica, questa potrebbe essere la più devastantemente efficiente. Dalle interviste con esperti di rocketry e un'analisi preparata per l'agenzia spaziale, emerge un chiaro percorso da un errore aritmetico alla distruzione totale.

Quali importanti cambiamenti hanno causato il fallimento di Flight 501 e le successive indagini hanno ispirato la ricerca di sistemi critici per la sicurezza e test del software?

Non sto cercando una spiegazione del bug stesso, ma una spiegazione dell'impatto storico del bug, in termini di ricerca che sono stati ispirati o direttamente correlati alle indagini sul fallimento. Ad esempio, questo documento conclude:

Abbiamo utilizzato l'analisi statica per:

• controlla l'inizializzazione delle variabili,
• fornire l'elenco esaustivo di potenziali conflitti di accesso ai dati per variabili condivise,
• elenca in modo esaustivo i potenziali errori di runtime dalla semantica di Ada.

Per quanto ne sappiamo, questa è la prima volta che vengono utilizzate tecniche di analisi statica su base booleana e non su base booleana per convalidare i programmi industriali.

Allo stesso modo, questo documento ^(pdf) osserva:

Le analisi del programma statico basate sull'interpretazione astratta sono state utilizzate per l'analisi statica del software ADA incorporato del launcher Ariane 5 e dell'ARD. L'analizzatore di programmi statici mira al rilevamento automatico della defi- nità, potenzialità, impossibilità o inaccessibilità di errori di runtime come flussi scalari e di punti di galleggiamento, errori dell'indice di array, divisioni per zero e relative eccezioni aritmetiche, variabili non inizializzate, gare di dati su strutture di dati condivisi, ecc. L'analizzatore è stato in grado di rilevare automaticamente l'errore di volo Ariane 501. L'analisi statica di software di sicurezza integrati (come il software avionico) è molto promettente .

Mi piacerebbe una spiegazione approfondita dell'impatto che questo singolo evento ha avuto sugli approcci e sugli strumenti di test del software.

_{¹ Il dato di $ 7 miliardi si riferisce probabilmente al costo totale del progetto Ariane 5, Wikipedia riporta che il fallimento ha comportato una perdita di oltre $ 370 milioni. Ancora un fallimento piuttosto costoso ma in nessun posto vicino alla cifra di $ 7 miliardi.}

Tecnicamente parlando, era più un caso di " marciume software ". Il software di controllo del volo è stato riciclato dal precedente razzo Ariane 4, una mossa ragionevole dato quanto è costoso sviluppare software, specialmente quando si tratta di software mission-critical che devono essere testati e verificati secondo standard molto più rigorosi di quelli che la maggior parte dei software commerciali deve essere.

Sfortunatamente, nessuno si è preoccupato di testare quale effetto avrebbe avuto il cambiamento nell'ambiente operativo, o se lo hanno fatto non ha detto test a uno standard sufficientemente approfondito.

Il software è stato creato per aspettarsi che determinati parametri non superino mai determinati valori (spinta, accelerazione, consumi, livelli di vibrazione, ecc.). Nel volo normale su un Ariane 4 questo non era un problema perché quei parametri non avrebbero mai raggiunto valori non validi senza che qualcosa fosse già incredibilmente sbagliato. L'Ariane 5, tuttavia, è molto più potente e le gamme che sembrano sciocche sul 4 potrebbero facilmente accadere sul 5.

Non sono sicuro di quale parametro sia andato fuori portata (potrebbe essere stata un'accelerazione, dovrò controllare), ma quando lo ha fatto, il software non è stato in grado di far fronte e ha subito un overflow aritmetico per il quale c'era stato implementato codice di controllo e recupero errori insufficiente. Il computer di guida ha iniziato a inviare spazzatura ai gimbal degli ugelli del motore, che a loro volta hanno iniziato a puntare l'ugello del motore in modo quasi casuale. Il razzo ha iniziato a cadere e rompersi, e il sistema automatico di autodistruzione ha rilevato che il razzo era ora in un atteggiamento non sicuro e irrecuperabile e ha finito il lavoro.

Ad essere onesti, questo incidente probabilmente non ha insegnato nuove lezioni, poiché il tipo di problemi è stato scoperto prima in tutti i tipi di sistemi e ci sono già strategie in atto per affrontare la ricerca e la correzione degli errori. Quello che ha fatto l'incidente è stato rammentare che essere rilassati nel seguire queste strategie può avere conseguenze enormi, in questo caso milioni di dollari di hardware distrutto, alcuni clienti estremamente incazzati e una brutta ammaccatura nella reputazione di Arianespace.

Questo caso particolare è stato particolarmente evidente perché una scorciatoia presa per risparmiare denaro è costata moltissimo, sia in termini di denaro che di perdita di reputazione. Se il software fosse stato testato in maniera altrettanto solida in un ambiente simulato di Ariane 5 come lo era quando era stato sviluppato originariamente per Ariane 4, l'errore sarebbe sicuramente emerso molto prima che il software fosse installato nell'hardware di lancio e messo al comando di un volo reale. Inoltre, se uno sviluppatore di software avesse deliberatamente immesso qualche input senza senso nel software, l'errore potrebbe anche essere stato colto nell'era di Ariane 4, in quanto avrebbe evidenziato il fatto che il ripristino dell'errore in atto era inadeguato.

Quindi, in breve, non ha insegnato davvero nuove lezioni, ma ha speronato a casa i pericoli di non ricordare quelli vecchi. Ha anche dimostrato che l'ambiente in cui opera un sistema software è altrettanto importante quanto il software stesso. Solo perché il software è verificabile in modo verificabile per l'ambiente X non significa che sia adatto allo scopo in un ambiente simile ma distinto Y. Infine ha messo in evidenza quanto sia importante che il software mission-critical sia abbastanza robusto da affrontare circostanze che non dovrebbero avere è accaduto.

Contrasta il volo 501 con Apollo 11 e i suoi problemi con il computer. Mentre il software LGC ha sofferto di un grave problema tecnico durante l'atterraggio, è stato progettato per essere estremamente robusto ed è stato in grado di rimanere in uno stato operativo nonostante gli allarmi software che sono stati attivati, senza mettere in pericolo gli astronauti ed essere ancora in grado di completa la sua missione.

Era principalmente un problema di riutilizzo e di gestione e non di codifica. Dai miei ricordi (probabilmente sto sbagliando alcune cose) del rapporto.

• un sottosistema era stato progettato per Ariane IV. Le traiettorie di Ariane IV non hanno potuto provocare lo straripamento ed è stato quindi volutamente deciso che se si fosse verificato, si sarebbe trattato di un problema hardware e l'arresto del sottosistema e il passaggio alla riserva era la cosa giusta da fare.

• per Ariane V, è stato deciso di riutilizzare quel sottosistema e di non rivedere i presupposti e il codice, ma fare affidamento sui test.

• inoltre si è deciso di abbandonare i test completi.

Diversi parametri di volo di Ariane V hanno causato l'overflow. Chiudi il primario. Spegni il ricambio. Autodestruction.

Altre cose che ricordo:

• il sottosistema al momento dell'overflow non era più utile. Si potrebbe sostenere che il suo fallimento non avrebbe dovuto innescare l'autodistruzione. (D'altra parte, la complessità aggiunta potrebbe essere essa stessa una fonte di problemi).

• c'erano dati di debug inviati a un bus quando non avrebbero dovuto. Non ricordo lo specifico.

Come altri hanno già detto, ha indotto l'industria in generale a riesaminare il concetto di riutilizzo e a inserirlo in un quadro di riferimento più ampio in base al quale i componenti non vengono valutati isolatamente ma nel contesto dell'intero sistema. Ciò riduce significativamente l'attrattiva del riutilizzo, poiché anche se un componente può essere riutilizzato senza modifiche, deve ancora essere analizzato con una nuova serie di ipotesi. Un altro corollario è che l'hardware di backup che esegue lo stesso software non è altrettanto attraente, dal momento che la maggior parte dell'hardware moderno è ordini di grandezza più affidabili del software moderno. Ho sentito che alcuni contratti di difesa richiedono due sistemi software separati sviluppati da team diversi che utilizzano tecnologie diverse che funzionano con le stesse specifiche per verificare la corretta implementazione.