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

Tecnicamente parlando, è stato più un caso di " decomposizione del software ". Il software di controllo del volo è stato riciclato dal precedente razzo Ariane 4, una mossa sensata dato quanto è costoso sviluppare software, soprattutto quando si tratta di software mission critical che deve essere testato e verificato con standard molto più rigorosi di quanto la maggior parte dei software commerciali debbano essere.

Sfortunatamente nessuno si è preoccupato di testare quale effetto avrebbe avuto il cambiamento in ambiente operativo, o se lo avesse fatto non avrebbe fatto il test con uno standard sufficientemente accurato.

Il software è stato progettato per prevedere che alcuni parametri non superino mai determinati valori (spinta, accelerazione, consumo di carburante, 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à spettacolaremente sbagliato. L'Ariane 5, tuttavia, è molto più potente e le gamme che sembrerebbero sciocche su 4 potrebbero facilmente accadere sul 5.

Non sono sicuro di quale parametro sia andato fuori portata (potrebbe essere stata l'accelerazione, dovrò controllare), ma quando è stato eseguito, il software non è stato in grado di far fronte e ha subito un overflow aritmetico per il quale non c'era stato un controllo degli errori e un codice di ripristino insufficienti. Il computer di guida ha iniziato a inviare rifiuti ai gomiti degli ugelli del motore, che a loro volta hanno iniziato a puntare l'ugello del motore in modo abbastanza casuale. Il razzo ha iniziato a ruzzolare e rompere, e il sistema automatico di autodistruzione ha rilevato che il razzo era ora in un atteggiamento irrecuperabile non sicuro e ha terminato il lavoro.

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

Questo particolare caso è stato particolarmente clamoroso perché una scorciatoia per risparmiare ha finito per costare una quantità enorme, sia in termini di denaro che di reputazione perduta. Se il software fosse stato testato con la stessa robustezza in un ambiente simulato Ariane 5 come quando era stato originariamente sviluppato per Ariane 4, l'errore sicuramente sarebbe venuto alla luce molto prima che il software fosse installato nell'hardware di lancio e messo al comando di un vero volo. Inoltre, se uno sviluppatore di software avesse deliberatamente gettato qualche input senza senso nel software, allora l'errore potrebbe essere stato catturato anche nell'era di Ariane 4, in quanto avrebbe evidenziato il fatto che il recupero degli errori era inadeguato.

Quindi, in breve, non insegnava davvero nuove lezioni, ma spingeva a casa i pericoli del non ricordare i vecchi. Ha anche dimostrato che l'ambiente in cui opera un sistema software è tanto importante quanto il software stesso. Solo perché il software è verosimilmente corretto per l'ambiente X non significa che sia adatto allo scopo nell'ambiente simile ma distinto Y. Infine ha evidenziato quanto sia importante che il software mission-critical sia sufficientemente robusto per affrontare circostanze che non dovrebbero avere è accaduto.

Contrasto volo 501 con Apollo 11 e problemi relativi al computer. Mentre il software LGC ha sofferto di un grave inconveniente durante l'atterraggio, è stato progettato per essere estremamente robusto ed è stato in grado di rimanere in uno stato operativo nonostante gli allarmi software attivati, senza mettere in pericolo gli astronauti e poter continuare a completa la sua missione.

Si trattava principalmente di un problema di riutilizzo e di problemi di gestione e non di programmazione. Dai miei ricordi (sto probabilmente facendo alcune cose sbagliate) del rapporto.

• un sottosistema era stato progettato per Ariane IV. Le traiettorie di Ariane IV non hanno potuto causare il trabocco ed è stato quindi deciso di proposito che, se si fosse verificato, si trattava di un problema hardware e lo spegnimento del sottosistema e il passaggio alla riserva erano la cosa giusta da fare.

• per Ariane V, si è deciso di riutilizzare quel sottosistema e non di rivedere le ipotesi e il codice ma fare affidamento sui test.

• inoltre è stato deciso di abbandonare il test completo.

Parametri di volo diversi di Ariane V hanno causato l'overflow. Spegni 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 di per sé una fonte di problemi).

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

Come altri hanno accennato, ha indotto l'industria in generale a riesaminare il concetto di riutilizzo e a collocarlo in un quadro di riferimento più ampio in cui i componenti non sono valutati separatamente ma nel contesto dell'intero sistema. Ciò riduce significativamente l'attrattiva del riutilizzo, poiché anche se un componente può essere riutilizzato senza modifiche, deve comunque essere analizzato con una nuova serie di ipotesi. Un altro corollario è che l'hardware di backup che esegue lo stesso software non è altrettanto attraente, dato che la maggior parte dell'hardware moderno è di ordine di grandezza più affidabile del software moderno. Ho sentito che alcuni contratti di difesa richiedono due sistemi software separati sviluppati da team diversi che utilizzano tecnologie diverse che lavorano con le stesse specifiche per verificare la corretta implementazione.