Ariane 5 — Il razzo che si schiantò per un numero troppo grande

All’alba del 4 giugno 1996, l’Europa spaziale tratteneva il respiro.
Il nuovo vettore Ariane 5, simbolo di autonomia e orgoglio tecnologico, si preparava al suo volo inaugurale.

Un lancio perfetto, una promessa di futuro: trentasette secondi dopo il decollo, il razzo si autodistrusse.

BUG ARCHEOLOGY — EPISODIO 20

“L’universo non ha obbligo di essere comprensibile.”
— Werner Heisenberg

👶 Introduzione per chi parte da zero

L’Ariane 5 era un razzo vettore sviluppato dall’ESA e dal CNES per portare satelliti in orbita geostazionaria.
Successore dell’Ariane 4, ne ereditava parte del software di controllo, scritto in linguaggio Ada.

Solo che il nuovo razzo era più potente, più veloce, e con un profilo di volo completamente diverso.
Il software, però, fu riutilizzato ed era quasi identico; questo — nato per gestire velocità moderate — si trovò improvvisamente a fronteggiare numeri che non sapeva rappresentare.

E bastò un valore fuori scala per scatenare la catastrofe.

I. Il sintomo: 37 secondi di trionfo e disastro

4 giugno 1996, Kourou, Guyana Francese.
Il razzo Ariane 5 decolla perfettamente. Tutto sembra procedere secondo i piani.

Nei primi 37 secondi di volo tutto sembra stabile.
Poi, all’improvviso i motori vettoriali iniziano a deviare. il razzo ruota violentemente su se stesso, le forze laterali superano ogni limite. Il sistema di controllo riceve dati incoerenti e comanda manovre assurde.
In mezzo secondo, entrambi i computer di bordo falliscono e si spengono.
Il sistema di autodistruzione entra in funzione. Un lampo squarcia il cielo equatoriale.
Nessuna vittima umana, fortunatamente, ma due satelliti scientifici e 500 milioni di dollari svaniscono.
La causa? Un overflow in una conversione numerica apparentemente innocua.

II. L’origine: il codice ereditato

Il software dell’Ariane 5 proveniva quasi integralmente dall’Ariane 4, un sistema collaudato per oltre cento lanci riusciti.
Gli ingegneri decisero di riutilizzare i moduli del sistema inerziale per risparmiare tempo e costi.

Solo che sull’Ariane 4 le velocità orizzontali massime non superavano una certa soglia; sull’Ariane 5 erano oltre quattro volte più alte.
Il codice, mai testato fuori da quel limite, continuava a tentare una conversione di un numero a 64 bit in un intero a 16 bit.
Quando il valore superò 32 767, il massimo rappresentabile, si verificò l’overflow.

Un singolo bit fuori posto.
Un errore aritmetico diventato fuoco e detriti.

III. Il bug tecnico: overflow numerico

Un overflow avviene quando un numero è troppo grande per il tipo di variabile che deve contenerlo.

Nel linguaggio Ada (e in molti altri), ciò può provocare un’eccezione non gestita che termina il programma.

🧩 Esempio semplificato:

-- valore massimo per un intero a 16 bit: 32767
declare
   x_16bit : Integer range -32768 .. 32767;
   y_64bit : Long_Float := 45000.0;
begin
   x_16bit := Integer(y_64bit);  -- 💥 Overflow: valore troppo grande
end;

Nel sistema dell’Ariane 5, questa eccezione arrestò l’unità SRI (Inertial Reference System).
L’architettura prevedeva due sistemi identici: il secondo, credendo che il primo fosse guasto, ripeté la stessa operazione e fallì nello stesso identico modo.
Non vi erano nessuna ridondanza reale, nessun salvataggio: praticamente, esistevano due cervelli gemelli, colpiti dallo stesso lampo logico. Nel caso dell’Ariane 5, un sensore calcolava la velocità orizzontale come parte del sistema di riferimento inerziale.
Quel valore, normalmente basso sull’Ariane 4, divenne gigantesco con l’accelerazione dell’Ariane 5 e fece impazzire il sistema di guida.

IV. Il contesto: fiducia cieca nel codice ereditato

Nessuno testò il modulo in condizioni di volo reali.
Si pensava che il codice fosse “già testato” — lo era stato su Ariane 4, quindi doveva funzionare.
Una frase, nelle conclusioni del rapporto d’inchiesta, divenne simbolica:

“Funzionava prima, quindi funzionerà anche ora.”

Il codice era stato giudicato “affidabile” non perché fosse necessario al nuovo profilo di volo, ma perché lo era stato nel passato.
Non venne simulato in condizioni dinamiche di Ariane 5, né validato da un team indipendente.

La fiducia divenne cieca, la sicurezza presunta.
L’errore aritmetico non era che la punta dell’iceberg organizzativo.

V. La scoperta: l’autopsia di un razzo

Dopo l’incidente, vennero recuperati i registri di telemetria e i log dei computer di bordo. L’indagine ESA–CNES durò settimane.
Analizzandoli, gli ingegneri scoprirono che entrambi gli SRI si erano spenti nello stesso istante, generando dati di navigazione impossibili (angoli di 90°, rotazioni istantanee, coordinate fuori scala).

Il computer principale interpretò quei dati come reali e ordinò la correzione immediata: una rotazione suicida.

Il rapporto d’inchiesta concluse:

“L’errore risiedeva nella conversione di un valore orizzontale da 64 bit a 16 bit, senza protezione contro l’overflow.”

Un’operazione mai necessaria in volo, ma lasciata attiva per “coerenza”: una riga inutile di codice cambiò la storia dell’astronautica europea.

Quando il primo fallì, il secondo — progettato come backup identico — lo imitò fedelmente.
Non ci fu alcuna ridondanza reale.
Il fallimento fu simmetrico e totale.

VI. Le implicazioni morali e legali

Il caso Ariane 5 non ebbe colpevoli giudiziari, ma sollevò un dibattito tecnico ed etico:
quanto possiamo fidarci del codice “collaudato”? E quando il riuso diventa negligenza?

ESA e CNES ammisero pubblicamente che la scelta di non testare il modulo derivava da un bias di affidabilità: il software “funzionava”, dunque “funzionerà”.
Una fallacia antica quanto l’ingegneria stessa.

Non ci fu alcuna causa giudiziaria, ma un terremoto etico e organizzativo.
L’incidente divenne un caso di studio su come il riuso del software possa diventare un atto di negligenza, se non accompagnato da verifica.

Da quel momento, ogni progetto aerospaziale europeo richiese:

• Analisi formale del codice critico.
• Test indipendenti di integrazione.
• Revisione del software ereditato.

Il bug dell’Ariane 5 trasformò la fiducia cieca in un principio nuovo:

“Riutilizzare è progettare di nuovo.”

🕰️ Linea temporale degli eventi

1988–1995 — 🧩 Sviluppo dell’Ariane 5
Progetto avviato per sostituire Ariane 4. Viene deciso il riuso del software di guida.

4 Giugno 1996 — 🚀 Lanciatore V88
Primo volo. Dopo 37 s il razzo devia dalla traiettoria e si autodistrugge.

Giugno 1996 — 🔍 Analisi dati
Entrambe le unità SRI falliscono simultaneamente per overflow.

Luglio 1996 — 📘 Rapporto ufficiale
ESA e CNES pubblicano il Inquiry Board Report: causa principale identificata nell’errore di conversione.

1997–1998 — 🧰 Correzioni e nuovi standard
Rimozione del codice obsoleto, aggiunta di controlli d’overflow e revisione dei processi di validazione.

VII. I danni: milioni in fumo, fiducia incrinata

Non ci furono morti, ma anni di ricerca e centinaia di milioni di euro andarono in fumo.
L’ESA subì una crisi di immagine e dovette riconquistare la fiducia dei partner commerciali.
Il disastro, paradossalmente, divenne fondativo: da quell’errore nacque una nuova disciplina di verifica del software spaziale.

VIII. Contromisure: quando il software impara dai suoi errori

Dopo Ariane 5, vennero introdotte misure che oggi consideriamo standard:

Tecniche

• Controllo delle eccezioni numeriche.
• Test di overflow e stress testing su tutte le variabili.
• Eliminazione del codice non essenziale in fase di volo.

Organizzative

• Verifica indipendente (IV&V).
• Revisione del riuso di codice.
• Documentazione completa del contesto operativo.

L’errore si trasformò in metodologia.

IX. Lezioni filosofiche: il limite dei numeri

Il caso Ariane 5 non parla solo di software.
Parla del limite: il limite di ciò che può essere previsto, rappresentato, espresso.
Ogni numero che cresce troppo rivela un confine, e ogni confine ignorato si trasforma in catastrofe, è l’immagine stessa dell’ambizione umana che eccede la misura.

Tre lezioni restano:

1. Il codice non è eterno: vive solo entro i suoi limiti.
2. La fiducia è un parametro che va testato.
3. L’errore aritmetico è anche errore epistemologico, ovvero quello di confondere il mondo con la sua rappresentazione numerica.

X. Epilogo: archeologia dell’overflow

L’Ariane 5 non fallì per un bug qualunque, ma per una catena di convinzioni non verificate.
Scavando nei suoi log, l’archeologo del bug non trova solo una variabile fuori scala: trova la traccia di una cultura che dava il software per scontato.

Come nel caso Therac-25, la tragedia nacque dall’idea che “il codice è sotto controllo”. Come un tempio costruito su fondamenta fragili, anche il software può crollare sotto il peso dei suoi stessi numeri e non fa rumore: si limita a scrivere nel cielo una lezione di umiltà.

XI. Coda: il ritorno dei numeri troppo grandi

Oggi l’overflow non vive più nei razzi, ma nei sensori IoT, nei sistemi bancari e medici, nei modelli di AI che calcolano oltre le soglie previste.
Ogni volta che un valore supera il limite stabilito da un ingegnere, un piccolo frammento dell’Ariane 5 riaffiora nel presente.

“Un singolo bit può costare mezzo miliardo.”
Ma il costo reale è sempre un altro: la perdita della fiducia nel controllo umano ed a volte basta un numero che cresce un po’ troppo per far cadere un sogno.”

Il vero insegnamento è questo:
il limite non è un difetto del mondo, ma una condizione della sua comprensibilità.
E quando dimentichiamo i limiti, i numeri — come i razzi — ci ricordano la loro legge con una scia di fuoco.

🧰 Bug Survival Kit – Ariane 5 Edition

📚 Libri consigliati

• The Mythical Man-Month – Frederick P. Brooks (versione inglese)
  → Il classico sulla complessità e l’illusione del riuso del software.
• Principi di ingegneria del software – Roger Pressman
  → Per comprendere come errori di progettazione e mancanza di verifica portino a fallimenti sistemici.
• Sette brevi lezioni di fisica – Carlo Rovelli
  → Un classico per ricordarci che anche i numeri, come le leggi fisiche, hanno limiti e approssimazioni.

🔧 Tool utili

• SPARK Ada / GNATprove — per analisi formale del codice critico.
• CBMC / Frama-C — per verifica di overflow e conversioni numeriche.
• NASA IV&V Framework — linee guida per validazione di sistemi critici.