Alfonso Maruccia

USA, errore di memoria nel controllo dei cieli

Il sistema incaricato di tenere sotto controllo la sicurezza dei voli negli USA va in crash a causa di un errore di memoria insufficiente, un errore provocato da un velivolo-spia con un piano di volo erratico

Roma - Momento di crisi vissuto qualche giorno fa dalla Federal Aviation Administration (FAA), con il sistema En Route Automation Modernization (ERAM) abbattuto da un errore e la conseguente necessità di bloccare il traffico nell'intero spazio aereo statunitense.

Sviluppato dal contractor Lockheed Martin, il sistema ERAM è stato progettato per tracciare le caratteristiche di ogni volo (traiettoria, velocità, altitudine) e valutare la possibilità di collisioni in aria. A ogni velivolo viene assegnata una quantità limitata di dati, e l'approccio ha sempre funzionato come avrebbe dovuto.

L'entrata di un aereo spia U-2 nello spazio controllato dall'unità ERAM di Los Angeles ha pero messo in crisi l'intero sistema, visto che i piani di volo del jet prevedevano svariate entrate e uscite dalla zona di controllo e i dati del volo si avvicinavano molto ai limiti imposti a ERAM.
Il combinato disposto del piano di volo U-2 e l'intervento di un controllore del traffico in carne e ossa per impostare manualmente l'altitudine a 60.000 piedi, ha spinto il sistema a calcolare tutte le possibili altitudini del jet superando la quantità di memoria disponibile per la gestione del volo. Errori di sistema, crash e riavvii sono stati la naturale conseguenza di quella che è stata classificata come una vera e propria falla potenziale di ERAM - anche se piuttosto difficile da sfruttare per intenti malevoli.

Alfonso Maruccia
18 Commenti alla Notizia USA, errore di memoria nel controllo dei cieli
Ordina
  • L'U2 è un progetto degli anni 50.. QUELLA era vera progettazione fatta bene
    non+autenticato
  • No.
    E' che i progetti fallimentari di quegli anni nel frattempo ce li siamo dimenticati.
    non+autenticato
  • Pensavo che ormai i programmatori avessero imparato a non dare per scontato un limite fisso per memorizzare dei dati e *soprattutto* non tralasciate controlli per il superamento di tale limite.
    Un errore simile, date le responsabilità in gioco è veramente indice di estrema incompetenza e trascuratezza.
    non+autenticato
  • Non è un bug, è una feature

    > ha spinto il sistema a calcolare tutte le possibili altitudini
    non+autenticato
  • Se i costruttori costruissero come i programmatori programmano, il primo picchio di passaggio distruggerebbe la civiltà.

    Battuta vecchia, ogni giorno più vera.
    non+autenticato
  • - Scritto da: Francesco
    > Se i costruttori costruissero come i
    > programmatori programmano, il primo picchio di
    > passaggio distruggerebbe la
    > civiltà.
    >
    > Battuta vecchia, ogni giorno più vera.

    Bah... e' successo qualcosa in questo caso? E' caduto qualche aereo? Morto qualcuno? No... e la mia cantina continua ad allagarsi.
    non+autenticato
  • Come quelli che hanno progettato questo ponte, vero?
    Clicca per vedere le dimensioni originali
    http://en.wikipedia.org/wiki/I-35W_Mississippi_Riv...
    per dirne una...
  • - Scritto da: amedeo
    > Pensavo che ormai i programmatori avessero
    > imparato a non dare per scontato un limite fisso
    > per memorizzare dei dati e *soprattutto* non
    > tralasciate controlli per il superamento di tale
    > limite.

    Non ho capito bene, non devono assumere un limite fisso ma devono controllare che non si superi tale limite?

    > Un errore simile, date le responsabilità in gioco
    > è veramente indice di estrema incompetenza e
    > trascuratezza.

    Shit happens...
    non+autenticato
  • - Scritto da: nome e cognome

    > Non ho capito bene, non devono assumere un limite
    > fisso ma devono controllare che non si superi
    > tale limite?

    No, in soldoni ha detto che non ci dev'essere nessun limite fisso e che così facendo [venendo cioè a mancare tale limite] non ci sarebbe più bisogno di tralasciare controlli per la paura di superarlo.

    > Shit happens...

    More often than not.
    non+autenticato
  • Da ormai parecchi anni, i linguaggi di programmazione permettono l'utilizzo di variabili con dimensioni dinamiche, per cui invece di dimensionare un valore in modo fisso e piccolo (come fanno tanti incapaci per cui spesso non riesco a mettere l'indirizzo completo nelle form), si può prevedere di utilizzare più spazio.
    Visto che comunque la quantità fisica di memoria non è infinita, (come invece piacerebbe a tutti i programmatori, me compreso), è importante ricordarselo e gestirla in modo da non sforare i limiti imposti.
    Proprio lo 'sbordare' è un problema classico (tipico nell'utilizzo allegro di puntatori tanto amato da alcuni fan del C) da cui nascono bug e exploit più o meno gravi, normalmente perché si supera lo spazio riservato al proprio programma/processo (o chi per esso) andando a scrivere in un'area (non correttamente protetta) di qualcun altro.
    Ne può risultare un malfunzionamento o crash di un programma o in casi peggiori, un crash del sistema.
    Quando questo succede su un PC, normalmente non è molto grave; su un server infastidisce già più persone, su un sistema di controllo aereo mi sembra piuttosto grave (si, non è morto nessuno ma per quanto tempo e quanti aerei sono rimasti bloccati, e con quali costi e rischi di incidenti?). Supponendo che una Lockheed Martin si faccia pagare profumatamente per quei sistemi, ritengo che dovrebbe avere un controllo qualità migliore e dei programmatori che ricordino bene quanto sia importante tenere conto dei limiti.
    non+autenticato
  • - Scritto da: amedeo
    > Proprio lo 'sbordare' è un problema classico
    > (tipico nell'utilizzo allegro di puntatori tanto
    > amato da alcuni fan del C) da cui nascono bug e
    > exploit più o meno gravi, normalmente perché si
    > supera lo spazio riservato al proprio
    > programma/processo (o chi per esso) andando a
    > scrivere in un'area (non correttamente protetta)
    > di qualcun
    > altro.
    > Ne può risultare un malfunzionamento o crash di
    > un programma o in casi peggiori, un crash del
    > sistema.

    AFAIK, se vai in overflow all'interno del tuo spazio ti malfunziona o crasha il programma, se provi ad uscire vai in SegFault, ci pensa il sistema operativo a "proteggere" lo spazio altrui. Difficile che un programma in userspace mandi in crash il sistema.
    In questo caso comunque non penso che sia un problema di buffer overflow, ma di eccessivo uso della memoria, una sorta di stack overflow.
    non+autenticato
  • - Scritto da: amedeo
    > Da ormai parecchi anni, i linguaggi di
    > programmazione permettono l'utilizzo di variabili
    > con dimensioni dinamiche, per cui invece di
    > dimensionare un valore in modo fisso e piccolo
    > (come fanno tanti incapaci per cui spesso non
    > riesco a mettere l'indirizzo completo nelle
    > form), si può prevedere di utilizzare più
    > spazio.
    > Visto che comunque la quantità fisica di memoria
    > non è infinita, (come invece piacerebbe a tutti i
    > programmatori, me compreso), è importante
    > ricordarselo e gestirla in modo da non sforare i
    > limiti
    > imposti.

    Quindi ti devi imporre un limite o no?

    > Supponendo che una Lockheed Martin
    > si faccia pagare profumatamente per quei sistemi,
    > ritengo che dovrebbe avere un controllo qualità
    > migliore e dei programmatori che ricordino bene
    > quanto sia importante tenere conto dei
    > limiti.

    Secondo te è possibile garantire l'assenza di bug in un programma?
    non+autenticato
  • Un "piano di volo erratico"? Newbie, inesperto
  • Magari intendevano "errato" e, giustamente, hanno errato nello scrivere "errato"... basta fatemi uscire da questo loop!A bocca aperta

    In ogni caso anche "erratico" ci sta bene se teniamo conto che il sistema ha cercato di calcolare tutte le possibili varianti al piano di volo (e quindi "erratico" è corretto, nel senso di "mutevole").

    Nicola
  • erràtico agg. [dal lat. erratĭcus, der. di errare «vagare»] (pl. m. -ci). –

    1. Che muta continuamente posto, errante, vagabondo: pianeta non vuol dire altro che e., cioè vagabondo (Varchi); accalappiatori di cani e. (D’Annunzio). Con sign. più ristretto, in zoologia, detto di organismi che compiono movimenti irregolari nello spazio e nel tempo, per lo più in cerca di cibo e di condizioni più favorevoli di esistenza, spec. in inverno (analogam., nel linguaggio venatorio, con riferimento a esemplari di selvaggina).
    non+autenticato
  • in inglese erratic significa senza una rotta precisa
    non+autenticato
  • anche in latino il verbo "errare" e la relativa corrispondenza in italiano "errare", stanno a significare la medesima azione

    cosi' come l'attributo latino "errāticus" e quello italiano "erràtico" rappresentano il medesimo significato del post-inglese "erratic"
    non+autenticato