|
Disastri informatici, la compilation (prima parte) 27.11.07 Permalink 13 commenti
La compilation dei disastri informatici
Zdnet ha pubblicato una simpatica lista, decisamente consolatoria, dei peggiori disastri informatici della storia, escludendo però quelli che hanno causato morti o feriti. Ma così è troppo blanda, per cui mi sono permesso di aggiungere qualche altro disastro. Ecco un assaggio.
1983: il sistema di difesa antimissile sovietico
Il 26 settembre 1983, un baco nel sistema sovietico di avvistamento avanzato dei missili intercontinentali segnalò erroneamente che gli Stati Uniti avevano lanciato contro l'Unione Sovietica cinque missili con testate nucleari.
Per fortuna l'ufficiale in servizio, Stanislav Petrov (nella foto), all'epoca quarantaquattrenne, ebbe la sensazione che ci fosse qualcosa che non quadrava: perché gli USA avrebbero dovuto attaccare usando soltanto cinque missili?In realtà era un difetto del software che doveva eliminare i falsi rilevamenti dei satelliti di sorveglianza, che rilevano il bagliore del lancio dei missili ma a volte si fanno ingannare dai riflessi del sole sulle nubi.
Petrov non fu mai premiato dai sovietici per la propria iniziativa, ma anzi fu torchiato per la propria insubordinazione; gli andò meglio in occidente, dove ottennne un riconoscimento dalle Nazioni Unite, ed ora è semplicemente un pensionato come tanti. Ne parlano varie fonti, come per esempio il Washington Post, ed è previsto per il 2008 un documentario che racconta la sua storia, secondo il Malta Star.
1990: collassa la rete telefonica USA
Il 15 gennaio 1990, settantacinque milioni di telefonate in tutti gli Stati Uniti cadono nel vuoto perché una singola centrale della AT&T subisce un piccolo guasto. Sessantamila utenti restano senza la possibilità di fare interurbane per ore. Il software di gestione, aggiornato da poco, contiene una sola riga sbagliata che causa un effetto domino che fa collassare tutte le altre centrali. Ne parlano anche Technology Review e Data Reservoir.
1962: sonda spaziale USA distrutta da un trattino
Il 22 luglio 1962, la sonda automatica Mariner 1 decolla da Cape Canaveral, ma invece di dirigersi verso Venere, subito dopo il lancio piega a sinistra e punta verso il basso. La NASA è costretta a farla esplodere in volo per evitare che causi danni precipitando intera.Il rapporto pubblicato in seguito dalla NASA ammette che la causa dell'errore è un singolo trattino mancante da una riga di codice Fortran del programma di guida automatica della sonda. Secondo il rapporto, "in qualche modo, un trattino era stato eliminato dal programma di guida caricato sul computer, consentendo ai segnali errati di ordinare al razzo vettore di deviare a sinistra e puntare il muso verso terra... Basti dire che il primo tentativo americano di volo interplanetario è fallito per mancanza di un trattino" ["Somehow a hyphen had been dropped from the guidance program loaded aboard the computer, allowing the flawed signals to command the rocket to veer left and nose down...Suffice it to say, the first U.S. attempt at interplanetary flight failed for want of a hyphen."].
Il vettore e la sonda costavano oltre 80 milioni di dollari, inducendo Arthur C. Clarke (grande scrittore di fantascienza, nonché inventore dei satelliti geostazionari) a battezzare questa missione come "il trattino più costoso della storia" ["the most expensive hyphen in history"]. Ne parlano Data Reservoir, Nasa e Risks Digest.
1996: il vettore Ariane 5 esplode al decollo, danni per 1 miliardo di euro
Il 4 giugno 1996 viene lanciato per la prima volta il vettore Ariane 5, punta di diamante del programma spaziale europeo. Dopo 39 secondi di volo interviene il sistema di autodistruzione, trasformando l'Ariane 5 e il suo carico pagante (quattro satelliti scientifici non assicurati, per un valore di 500 milioni di dollari) in quello che è stato definito "il più costoso fuoco d'artificio della storia".Non ci sono vittime, dato che il missile non ha equipaggio e i frammenti dell'esplosione cadono in una zona disabitata della Guiana francese, ma i danni economici sono ingentissimi (1 miliardo di euro). Il disastro avviene perché un programma del sistema di navigazione tenta di mettere un numero a 64 bit in uno spazio a 16 bit.
Il sistema, progettato per l'Ariane 4 e riciclato perché dimostratosi affidabile, tenta infatti di convertire la velocità laterale del missile dal formato a 64 bit al formato a 16 bit. Tuttavia l'Ariane 5 vola molto più velocemente dell'Ariane 4, per cui il valore della velocità laterale è più elevato di quanto possa essere gestito dalla routine di conversione, che (a differenza di molte altre routine di conversione a bordo) è priva dei normali controlli che evitano problemi di gestione.
Risultato: overflow, spegnimento del sistema di guida, e trasferimento del controllo al secondo sistema di guida, che però essendo progettato allo stesso modo è già andato in tilt nella medesima maniera pochi millisecondi prima. Privo di guida, il vettore si autodistrugge.
Ironia della sorte, la funzione di conversione difettosa che causa lo spegnimento del sistema di guida non ha alcuna utilità pratica una volta che l'Ariane è partito: serve soltanto per allineare il vettore con le coordinate celesti (l'Ariane ha un sistema di navigazione inerziale). Ma i progettisti avevano deciso di lasciarla attiva per i primi 40 secondi di volo in modo da facilitare il riavvio del sistema se si fosse verificata una breve interruzione nel conto alla rovescia.
Da un articolo di Claudio Borgonovi sul Sole 24 Ore di luglio 1996:
"Appena nove secondi dopo il decollo, le due centrali inerziali già non riuscivano ad avere un allineamento corretto. Al 37° secondo le due centrali si dichiaravano contemporaneamente in situazione d'errore irrecuperabile e lanciavano una procedura di reset (...) realizzabile fino a 40 secondi dal via. (...) veniva assunta come base di riferimento la posizione istantanea del vettore, non coincidente con la posizione verticale sulla base di lancio, e il calcolatore ordinava una brusca correzione di rotta, portando a fine corsa gli ugelli sia dei booster che del motore criogenico. L'improvviso aumento degli sforzi aerodinamici portava a instabilità strutturale ("buckling") e il vettore si rompeva poco al di sotto dell'ogiva. Subito dopo si sono attivati i sistemi automatici di autodistruzione"
2006: il software sbaglia i cablaggi dell'Airbus a due piani
L'Airbus A380, il gigantesco aereo di linea noto per la sua fusoliera a due piani, è assemblato in vari moduli in fabbriche differenti. Ma durante l'unione dei vari moduli per completare l'aereo, salta fuori che i cavi di un modulo non sono nella posizione nella quale se li aspetta il cablaggio dell'altro modulo.Un disastro che comporta ritardi di oltre un anno, riprogettazioni e penali sui contratti di fornitura già stipulati sui quali nessuno, a quanto risulta, vuole dare una cifra precisa.
Il problema è dovuto al fatto che la fabbrica di Amburgo usa una versione vecchia del software di progettazione e assemblaggio CATIA, mentre quella francese della Dassault Aviation usa quella nuova.
La seconda parte della compilation di disastri informatici è pubblicata qui.
Etichette: cronologia di Internet
Articoli che linkano questo articolo:
Commenti:
Paolo, come non dimenticare l'esplosione in volo dell'Arianne?
Anche quello fu dovuto ad una interpretazione errata, ma in questo caso, di uno staff di programmatori, che pensarono bene di non usare il Sistema internazionale di unità di misura ma, mi pare, il CGS per costruire una delle centraline di controllo del razzo. Ora vado a memoria, ma il sistema se non ricordo male aveva due centraline sviluppate ciascuna con hardware differente e software differenti in modo che uno stesso errore non si potesse verificare contemporaneamente. Solo che le misurazioni che faceva una delle due centraline ad un certo punto ha portato un valore in una variabile fuori scala e se non è opportunatamente gestita, questa eventualità, la variabile assume dei valori negativi. Il valore negativo ha fatto diventare negativa la velocità che è stata interpretata dal sistema come se il razzo stesse precipitando, quindi l'autodistruzione ha fatto il resto.
Anche quello fu dovuto ad una interpretazione errata, ma in questo caso, di uno staff di programmatori, che pensarono bene di non usare il Sistema internazionale di unità di misura ma, mi pare, il CGS per costruire una delle centraline di controllo del razzo. Ora vado a memoria, ma il sistema se non ricordo male aveva due centraline sviluppate ciascuna con hardware differente e software differenti in modo che uno stesso errore non si potesse verificare contemporaneamente. Solo che le misurazioni che faceva una delle due centraline ad un certo punto ha portato un valore in una variabile fuori scala e se non è opportunatamente gestita, questa eventualità, la variabile assume dei valori negativi. Il valore negativo ha fatto diventare negativa la velocità che è stata interpretata dal sistema come se il razzo stesse precipitando, quindi l'autodistruzione ha fatto il resto.
Il vettore Ariane 5 dell’ESA esplose durante il volo inaugurale il 4 giugno 1996 dopo 39 secondi dal decollo.
L’esplosione fu causata da un segnale di autodistruzione emesso dal sistema di controllo che era stato "riciclato" dall'Ariane 4. Però le velocità tangenziali erano molto più alte e eccedettero i 16 bit del sistema di controllo e il sistema pensò di essere troppo fuori controllo.
L’esplosione fu causata da un segnale di autodistruzione emesso dal sistema di controllo che era stato "riciclato" dall'Ariane 4. Però le velocità tangenziali erano molto più alte e eccedettero i 16 bit del sistema di controllo e il sistema pensò di essere troppo fuori controllo.
Però io mi ricordo una questione legata a due team di sviluppo e che uno per una mancanza nelle specifiche aveva usato il sistema CGS anziché il SI. O forse confondo con qualcos'altro?
Il millennium bug alla fine non ha creato questi scenari apocalittici che alcuni prospettavano, però è indubbio che la perdita di tempo e di denaro per aggiornare il software e per rimediare agli erori si potevano tranquillamente risparmiare, se ai tempi qualcuno avesse avuto la voglia di creare un altro sistema di datazione dei file.
@ martino
Probabilmente ti ricordi del Mars Surveyor, che è andato perso per una confusione fra unità SI e inglesi.
http://en.wikipedia.org/wiki/Mars_Surveyor_%2798_program
Probabilmente ti ricordi del Mars Surveyor, che è andato perso per una confusione fra unità SI e inglesi.
http://en.wikipedia.org/wiki/Mars_Surveyor_%2798_program
Replicante Cattivo: forse tu non ricordi (o non hai sperimentato) quando i dischi dei computer mainstream erano da 360k e non c'erano gli hard disk (o dischi winchester, come si chiamavano allora). Quando hai poco spazio di memorizzazione, ti adatti come puoi. Probabilmente fra 20 anni qualcuno ridera' degli algoritmi di compressione audio/video a perdita di informazioni che stiamo utilizzando ora. C'erano delle procedure che il 1/1/2000 avrebbero smesso di funzionare, non perche' qualcuno se l'e' sognato, ma perche' ha provato a mettere l'orologio in una macchina di test al 31/12/1999 e ha visto cosa e' successo. Un assaggio di questo problema l'ha avuto chi nel 1992 (se non ricordo male) usava ancora un M-24 che usava solamente 3 bit per (l'offset del)l'anno dell'orologio interno.
"Però le velocità tangenziali erano molto più alte e eccedettero i 16 bit del sistema di controllo e il sistema pensò di essere troppo fuori controllo."
Sì, ricordo anch'io qualcosa del genere, ovvero che era stata mantenuta la centralina vecchio tipo mentre altri sistemi erano nuovi; a un certo punto uno di essi tentò di copiare un valore a 32 bit in un buffer di memoria a 16 bit, causando errori nei sistemi di guida che portarono il sistema di sicurezza ad attivare l'autodistruzione.
Sì, ricordo anch'io qualcosa del genere, ovvero che era stata mantenuta la centralina vecchio tipo mentre altri sistemi erano nuovi; a un certo punto uno di essi tentò di copiare un valore a 32 bit in un buffer di memoria a 16 bit, causando errori nei sistemi di guida che portarono il sistema di sicurezza ad attivare l'autodistruzione.
Replicante Cattivo: forse tu non ricordi (o non hai sperimentato) quando i dischi dei computer mainstream erano da 360k e non c'erano gli hard disk (o dischi winchester, come si chiamavano allora). Quando hai poco spazio di memorizzazione, ti adatti come puoi.
Beh, ma non credo che nessuno ai tempi si fosse mai posto il problema; o forse non si pensava che i computer potessero arrivare a durare per 20 anni. Però dico: non potevano iniziare a pensarci a risolvere il problema già nel 1990, quando era evidente che l'informatica stava controllando il mondo? In fondo già in quegli anni, un pc iniziava ad essere obsoleto dopo 2-3 anni, potevano fare in modo che le nuove macchine sfruttassero una datazione a più cifre.
Probabilmente fra 20 anni qualcuno ridera' degli algoritmi di compressione audio/video a perdita di informazioni che stiamo utilizzando ora.
Anche tra meno di 20 anni :) Ma questo è un altro discorso
C'erano delle procedure che il 1/1/2000 avrebbero smesso di funzionare, non perche' qualcuno se l'e' sognato, ma perche' ha provato a mettere l'orologio in una macchina di test al 31/12/1999 e ha visto cosa e' successo.
Ma infatti non dico che non ci sono stati problemi. Ma ti ricordi quando c'era chi profetizzava le città che, allo scattare della mezzanotte, sarebbero piombate nel buio più totale?
Non mi ricordo che trasmissione fosse, forse la Macchina Del Tempo, che aveva descritto un possibile scenario con città senza energia, senza riscaldamento, senza nulla! Roba che solo Giacobbo avrebbe potuto fare di meglio (ma in quegli anni ancora non lavorava in tv, per fortuna).
Insomma: diciamo che c'è stato da una parte un allarmismo esagerato, dall'altra si sono pagate le conseguenze di una "pigrizia" di qualcuno.
Beh, ma non credo che nessuno ai tempi si fosse mai posto il problema; o forse non si pensava che i computer potessero arrivare a durare per 20 anni. Però dico: non potevano iniziare a pensarci a risolvere il problema già nel 1990, quando era evidente che l'informatica stava controllando il mondo? In fondo già in quegli anni, un pc iniziava ad essere obsoleto dopo 2-3 anni, potevano fare in modo che le nuove macchine sfruttassero una datazione a più cifre.
Probabilmente fra 20 anni qualcuno ridera' degli algoritmi di compressione audio/video a perdita di informazioni che stiamo utilizzando ora.
Anche tra meno di 20 anni :) Ma questo è un altro discorso
C'erano delle procedure che il 1/1/2000 avrebbero smesso di funzionare, non perche' qualcuno se l'e' sognato, ma perche' ha provato a mettere l'orologio in una macchina di test al 31/12/1999 e ha visto cosa e' successo.
Ma infatti non dico che non ci sono stati problemi. Ma ti ricordi quando c'era chi profetizzava le città che, allo scattare della mezzanotte, sarebbero piombate nel buio più totale?
Non mi ricordo che trasmissione fosse, forse la Macchina Del Tempo, che aveva descritto un possibile scenario con città senza energia, senza riscaldamento, senza nulla! Roba che solo Giacobbo avrebbe potuto fare di meglio (ma in quegli anni ancora non lavorava in tv, per fortuna).
Insomma: diciamo che c'è stato da una parte un allarmismo esagerato, dall'altra si sono pagate le conseguenze di una "pigrizia" di qualcuno.
"Non mi ricordo che trasmissione fosse, forse la Macchina Del Tempo, che aveva descritto un possibile scenario con città senza energia, senza riscaldamento, senza nulla! Roba che solo Giacobbo avrebbe potuto fare di meglio (ma in quegli anni ancora non lavorava in tv, per fortuna)."
Sì, e poi ciliegina sulla torta, una bella meteora su Venezia, Gaia style.
Sì, e poi ciliegina sulla torta, una bella meteora su Venezia, Gaia style.
Beh, Paolo non ha parlato dell'Ariane perché c'è già nel Top 10 citato. Ha aggiunto qualche altro disastro, come dice all'inizio.
Io - modestamente - penso che se vivi in un'epoca in cui 8 bit fanno la differenza in un sistema di sicurezza, o spendi quei soldi per gli 8 bit in più o non porti avanti il progetto!
Non trovo giustificabile un disastro, piccolo o grande che sia, dovuto al tentativo di risparmiare pochi byte, e penso che il cosiddetto millennium bug sia dovuto all'imperizia dei programmatori di una volta, e non dalla *necessità* di risparmio.
No?
Non trovo giustificabile un disastro, piccolo o grande che sia, dovuto al tentativo di risparmiare pochi byte, e penso che il cosiddetto millennium bug sia dovuto all'imperizia dei programmatori di una volta, e non dalla *necessità* di risparmio.
No?
marco ha detto...
..penso che il cosiddetto millennium bug sia dovuto all'imperizia dei programmatori di una volta, e non dalla *necessità* di risparmio.
No?
Appunto: No
Imperizia un fico secco: fino ai primi anni 90 l'imperativo per i programmatori era "risparmia ogni singolo bit", non perchè volessimo dimostrare la ns bravura, ma perchè le risorse erano quelle che erano. Considera inoltre che fino al 2000 moltissime aziende, anche grosse multinazionali, basavano diversi loro sistemi anche contabili su SW scritto nei casi migliori 10 anni prima e che magari poggiava su altri software ancora + vetusti.
Il vero problema dell'anno 2000 è stata la lentezza con cui le aziende si sono mosse per aggiornare i sistemi e il catastrofismo innescato da giornalisti senza alcuna competenza tecnica
..penso che il cosiddetto millennium bug sia dovuto all'imperizia dei programmatori di una volta, e non dalla *necessità* di risparmio.
No?
Appunto: No
Imperizia un fico secco: fino ai primi anni 90 l'imperativo per i programmatori era "risparmia ogni singolo bit", non perchè volessimo dimostrare la ns bravura, ma perchè le risorse erano quelle che erano. Considera inoltre che fino al 2000 moltissime aziende, anche grosse multinazionali, basavano diversi loro sistemi anche contabili su SW scritto nei casi migliori 10 anni prima e che magari poggiava su altri software ancora + vetusti.
Il vero problema dell'anno 2000 è stata la lentezza con cui le aziende si sono mosse per aggiornare i sistemi e il catastrofismo innescato da giornalisti senza alcuna competenza tecnica
<< Home
