Imputato software: assolto - di Alessandro Ferrero

s

Rubrica a cura di Alessandro Ferrero (alessandro.ferrero@polimi.it)

DIVAGAZIONI A ZONZO SU METROLOGIA E DINTORNI

Imputato software: assolto?

Alcuni tragici eventi accusano i software di controllo, ma...

IL SOFTWARE: IL PERICOLOSO IMPUTATO

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. aviation-safety.net/2018/ 2 0 1 8 1 0 2 9 - 0 _ B 3 8 M _ P K - LQP_PRELIMINARY.pdf) un dettagliato rapporto preliminare sulle cau se 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 decisamente meno drammatici incidenti verificatisi nella metropolitana milanese.

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’in teresse su metrologia, misure e argomenti correlati

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 re - sponsabilità sembrerebbe essere della parte del software di controllo che gestisce il “trim”, cioè l’angolo d’imbardata del velivolo e quindi il suo as - setto di volo. Avendo riscontrato un an golo 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 de - cisione errata. È giusto quindi metterlo sul banco degli imputati? Per continuare nella metafora giudiziaria, l’esecutore ma teriale del crimine sembrerebbe proprio essere il software.

IL MANDANTEPremesso 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, op - pure un ostacolo sui binari, quando questi ultimi erano inequivocabilmente li beri. Bisognerebbe pensare a un oc - culto 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 coinvol - to 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 ri - portare a destinazione l’aereo con un minimo d’inconvenienti (aveva ri chie - sto 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

DIVAGAZIONI A ZONZO SU METROLOGIA E DINTORNI

n

N. 01ƒ ; 2019

catena di dispositivi che portava il segnale dal sensore al punto in cui veniva convertito nel dato numerico passato al software di controllo. Nel caso della metropolitana milanese qualche sensore ha evidentemente avuto le traveggole o non ha più rilevato segnale, ritenendo che il treno avesse violato un segnale posto a via impedita (appunto caratterizzato dall’assenza di segnale sul binario). Viene quindi naturale chiedersi se il tanto vituperato (in questi giorni) software sia il vero colpevole o soltanto un complice. E se, magari, non esista qualche altro complice.

IL COMPLICE NASCOSTO

Se accettiamo che all’origine dei guai ci sia stato il malfunzionamento di un sensore, che ha ingannato il software di controllo fornendo dati apparentemente corretti ma sostanzialmente errati, dobbiamo però anche accettare che gran parte della responsabilità di ciò che ne è conseguito risiede in una modestissima cultura metrologica, che porta a non mettere in discussione la correttezza del dato misurato. In altre parole, una mentalità che porta a ritenere che un misuratore sia palesemente guasto, oppure che il valore misurato sia totalmente affidabile. Non ci si pone il problema di analizzare i dati forniti alla

luce dell’incertezza di misura attesa, per capire, in presenza di dati discordanti da parte di due sensori ridondanti, quale sia il più attendibile. Quel che è peggio è che sembra non ci si renda conto che quando si utilizzano tecniche di automazione per correggere potenziali instabilità del sistema controllato (come nel caso del 737 MAX 8), i dati d’ingresso diventano facilmente l’elemento più critico dell’intero sistema e preoccuparsi del solo software di controllo può non es - sere più sufficiente. Il 737 MAX 8 monta gli stessi sensori di angolo d’attacco e gli stessi sensori di velocità al - l’aria delle versioni precedenti? Sono gestiti nello stesso modo? Sono queste le domande che mi pongo, molto pri - ma di chiedermi se e quanti bachi ha il software. Mi torna in mente, oggi nella sua evidente tragicità, il commento di un collega americano che ha collaborato con NASA e Boeing, quando un po’ provocatoriamente ebbi a dire in sua presenza che l’unica cosa certa sulle misure è che sono sbagliate. Mi rispose scandalizzato che, se avessi avuto ragione, gli aerei non sarebbero stati in grado di volare. Pensando a quelle povere vittime vorrei tanto che avesse avuto ragione lui. Purtroppo una mentalità drammaticamente lontana dal considerare rilevanti gli aspetti metrologici rischia di

farsi complice occulto di quanto è successo. E indicando nel software il solo punto debole della catena di controllo rischia di ritardare la soluzione del problema. Non è rendendo più facile il disinserimento dell’au - topilota (come si sente suggerire) né rendendo meno brusca la frenata di emergenza (come ho sentito dire da tecnici dell’ATM) che si risolve il problema, se non si sarà in grado di quantificare l’”attendibilità” del dato misurato in quella circostanza. Temo che stiano venendo al pettine i nodi derivanti dall’aver trascurato a tutti i livelli, da quello della formazione a quello dell’R&D aziendale, l’impatto che l’incertezza del dato misurato in campo ha sul risultato elaborato dal software di controllo. Il software, per quanto complesso, sicuro e testato, se avrà dati d’ingresso non metrologicamente validati, rischierà di fornire dati in uscita pericolosamente inattendibili. Si tratta di una mentalità che, temo, farà ancora danni: la nuova laurea in data science partirà senza alcun insegnamento di misure. Tanto quello che importa è che il software non sbagli e i dati siano sicuramente e correttamente memorizzati; così, quando arriveranno dati in ingresso sbagliati (e nessuno sarà in grado di accorgersene), continueremo ad avere in uscita risultati correttamente e perfettamente sbagliati!

NEWS

t

CONTROLLORE AD ALTE PRESTAZIONI PER SISTEMI DI POSIZIONAMENTO DI PRECISIONE “AIR BEARING”

I sistemi di posizionamento su cuscinetti ad aria si sono dimostrati una valida soluzione per un gran numero di applicazioni, ad esempio nel campo della metrologia, nell’allineamento di fibre ottiche, nella produzione di semiconduttori e nell’ispezione di wafer, nelle applicazioni di scansione di precisione o per operazioni di posizionamento in camera bianca. I cusci-

netti ad aria presentano una serie di vantaggi rispetto ai cuscinetti meccanici: non c’è attrito, abrasione, vibrazioni, la velocità può essere controllata con precisione ed è possibile raggiungere ripetibilità nanometriche. PI (Physik Instrumente) offre la nuova linea A-82x di controllori modulari ad alte prestazioni adatto per quattro, sei od otto assi e dedicato ai sistemi di posizionamento PIGlide su cuscino d’aria, che permette il controllo di servomotori lineari o rotazionali con azionamento diretto ed encoder ad alta risoluzione. La nuova serie A-82x integra controllore, driver e adattatori di alimentazione in un rack compatto 4-RU, da 19 pollici. Inoltre, su richiesta, può anche essere

offerta come configurazione personalizzata per i clienti OEM. A seconda del numero di assi da controllare, è disponibile una potenza continua da 1.100 a 2.000 W, con picchi fino a 3.900 W.

Per ulteriori informazioni: www.pi.ws

T_M ƒ 44