DIVAGAZIONI A ZONZO SU METROLOGIA E DINTORNI
s
Rubrica a cura di Alessandro Ferrero (alessandro.ferrero@polimi.it)
Imputato software: assolto? Alcuni tragici eventi accusano i software di controllo, ma... WANDERING AROUND METROLOGY AND ITS NEIGHBOROUGH This column is aimed to appear whenever events, occurrences or public discussion triggers the interest about metrology and related topics RIASSUNTO Questa rubrica farà la sua comparsa tutte le volte che eventi, accadimenti o dibattiti accenderanno l’interesse su metrologia, misure e argomenti correlati
IL SOFTWARE: IL PERICOLOSO IMPUTATO
Quale il comune denominatore che me li fa associare? In entrambi i casi si è puntato il dito contro presunte falle del software di controllo. Nel caso dei due incidenti aerei la responsabilità sembrerebbe essere della parte del software di controllo che gestisce il “trim”, cioè l’angolo d’imbardata del velivolo e quindi il suo assetto di volo. Avendo riscontrato un angolo di attacco troppo elevato per la velocità all’aria rilevata, il sistema MCAS (Maneuvering Characteristics Augmentation System), per evitare il rischio di stallo, ha automaticamente modificato l’assetto, portando i velivoli in una picchiata risultata fatale. Nel caso della metropolitana di Milano, il sistema di controllo del movimento del treno ha rilevato ostacoli in linea o segnali di via impedita e ha attivato il sistema di frenatura di emergenza, causando cadute tra i passeggeri con conseguenti traumi. Sembrerebbe quindi assodato che il sistema di controllo abbia, in entrambi i casi, preso una decisione errata. È giusto quindi metterlo sul banco degli imputati? Per continuare nella metafora giudiziaria, l’esecutore materiale del crimine sembrerebbe proprio essere il software.
Alcuni recenti eventi, due dei quali con tragica conclusione e gli altri con conseguenze decisamente meno dolorose, hanno portato il software di controllo sul banco degli imputati: gli incidenti aerei che hanno coinvolto due B737 MAX8 da poco entrati in servizio (uno di proprietà della compagnia indonesiana Lion e l’altro dell’etiope Ethiopian) e le ripetute frenate di emergenza (in assenza totale di condizioni di emergenza) della metropolitana milanese. È doveroso, oltre a porgere le nostre condoglianze alle famiglie delle vittime dei due incidenti aerei, premettere che, al momento in cui questo pezzo va in macchina, nulla ancora si sa sulle cause dell’incidente che ha coinvolto l’aereo dell’Ethiopian, mentre è già disponibile (https://reports. a v i a t i o n - s a f e t y. n e t / 2 0 1 8 / 20181029-0_B38M_PKLQP_PRELIMINARY.pdf) un dettagliato rapporto preliminare sulle cause dell’incidente della Lion. Quel poco che finora si conosce, in mancanza dei dati di volo, riguardo all’incidente del volo Ethiopian porta a ritenere che i due incidenti siamo molto simili. Venendo a casa nostra, sembrano essere già state individuate le motivazioni dei decisa- IL MANDANTE mente meno drammatici incidenti verificatisi nella metropolitana milanese. Premesso che chi scrive è solo, al più,
esperto di misure, va detto che nella mia vita professionale ho però combattuto contro le bizze dei tanti programmi di elaborazione numerica di segnali che ho sviluppato. E, soprattutto, ho imparato una cosa: un software elabora i dati in ingresso secondo l’algoritmo di elaborazione codificato e, sulla base dei dati in ingresso e del codice programmato sull’hardware di elaborazione, produce i dati di uscita che vanno ad azionare gli attuatori. Un software può avere degli errori, che spesso sfuggono ai più accurati test. Sembra però poco probabile che siano sfuggiti ai test errori clamorosi, come quello di far vedere un assetto cabrato quando il velivolo era in picchiata, oppure un ostacolo sui binari, quando questi ultimi erano inequivocabilmente liberi. Bisognerebbe pensare a un occulto errore di programmazione, che vada a sovrascrivere qualche registro o cella di memoria cambiandone completamente i valori: possibile, certamente, ma molto poco probabile in un software che ha superato i controlli a cui questo tipo di programmi è sottoposto. L’unica deduzione possibile è che il mandante sia da cercare altrove. E, se appena si analizzano i dati disponibili con un pizzico di attenzione in più, è immediato individuarlo: il sensore! Nel caso dell’incidente che ha coinvolto il velivolo della Lion, l’imputato principale è il sensore che misura l’angolo d’attacco. Aveva dato problemi fin dal volo precedente ma, per fortuna, l’equipaggio era riuscito a gestirli e a riportare a destinazione l’aereo con un minimo d’inconvenienti (aveva richiesto al controllo aereo una quota di volo più bassa di quella originariamente assegnata, per evitare i problemi dati dal sensore quando il velivolo assumeva l’assetto a salire). Il sensore è stato sostituito, ma evidentemente il problema non risiedeva in questo componente bensì in qualche punto della T_M
N.
1/19 ƒ 43
