Può “qualche riga di codice” scritta male provocare un incidente aereo e la morte di centinaia di persone? Prima di arrivare a dare una risposta a questo inquietante interrogativo, è utile ripercorrere tutto quello che è accaduto in un anno nero per l’aviazione mondiale, il 2018, funestato da due terribili incidenti aerei che hanno rimesso in discussione tutta l’industria del settore e fatto emergere domande su come tutto ciò sia potuto accadere, su un aereo nuovo – il Boing 737 MAX – considerato il più sicuro e quello con maggiore successo commerciale.
Il software di intelligenza artificiale sul banco degli imputati
Sul ‘banco degli imputati’, tra i diversi fattori, prende un posto di massimo rilievo un sistema software di intelligenza artificiale: pensato per semplificare la gestione dei piloti, è diventato invece il principale sospettato, facendo pensare che qualche riga di codice scritto malamente o senza le necessarie garanzie possa comportarsi come a volte capita di vedere su un PC, che si ‘blocca’ o risponde in modo differente rispetto ai nostri input. Con la differenza che su un aereo in volo non si può applicare la regola aurea dell’informatica, ovvero “spegni e poi riaccendi”. Siamo sempre stati consapevoli che un elemento fisico può arrivare a rompersi, e quindi a provocare incidenti, ma può essere che “il software” abbia potuto uccidere 346 persone?
Il report finale [1] del primo incidente occorso è stato rilasciato solo pochi giorni fa, e illustra complessivamente uno scenario in cui sono stati messi a fuoco tutti gli elementi che hanno contribuito alla tragedia del Lion Air JT610, e molte domande finalmente trovano risposta.
Il volo Lion Air JT610
29 ottobre 2018. Volo Lion Air JT610 in partenza da Giacarta con 189 persone a bordo. L’aeromobile è un 737 MAX nuovissimo, collaudato da Boeing il 30 luglio. Eppure, pochi minuti dopo il decollo, ancora in fase di salita, i piloti segnalano la necessità di rientro per problemi tecnici, in particolare problemi con il sistema di controllo del volo. Pochi minuti dopo l’aeromobile si disintegrerà nel mare di Giava, senza lasciare superstiti.
Il rapporto preliminare faceva già emergere alcuni dettagli quanto mai inquietanti. In primis, i dati provenienti dal DFDR (Digital Flight Data Recorder, il registratore digitale dei parametri di volo) mostrano una sorta di lotta tra equipaggio e sistema automatico per il controllo del TRIM: il sistema automatico muove lo stabilizzatore orizzontale in modo da far puntare l’aereo verso il basso, mentre i piloti si affannano a contrastare questi comandi con manovre opposte, fino allo schianto.
Il grafico della battaglia instaurata tra aereo e piloti è angosciante, in un susseguirsi di azioni e controazioni (blu) per correggere i comandi automatici del sistema di controllo del volo (arancio) che continuavano a far puntare l’aereo verso il basso:
Boeing, per la prima volta in assoluto, informa tutti i clienti che hanno nella flotta un 737MAX che su questo aereo è stato “implementato un sistema” denominato MCAS che “comanda lo stabilizzatore per puntare giù il naso [dell’aereo] per migliorare la caratteristica di beccheggio durante virate strette con fattori di carico elevati e durante il volo con i flap ritratti a velocità prossime a quelle di stallo”
“MCAS si attiva senza interazione del pilota ed opera solamente nel volo manuale con i flap ritratti. Il sistema è progettato per consentire all’equipaggio di utilizzare il comando di trim posto sulla cloche o gli interruttori di spegnimento dello stabilizzatore per superare i comandi di MCAS. La funzione è comandata dal computer di controllo del volo utilizzando i dati in ingresso dai sensori e dagli altri sistemi dell’aeromobile.
La funzione MCAS diventa attiva quanto l’angolo di attacco dell’aeromobile supera una soglia basata sulla velocità e altitudine. I comandi incrementali dello stabilizzatore sono limitati a 2.5 gradi e sono inviati ad una velocità di 0,27 gradi al secondo. L’ampiezza del comando dello stabilizzatore è inferiore a numero Mach più elevati, e più grande a numero di Mach bassi. La funzione è azzerata quando l’angolo di attacco rientra al di sotto della soglia, o se i comandi manuali dello stabilizzatore sono forniti dall’equipaggio. Qualora l’originale situazione di elevato angolo di attacco persista, la funzione MCAS invia un altro comando incrementale di abbassamento del naso in funzione del corrente numero di Mach.”
La comunicazione di Boeing appare alquanto tardiva, e peraltro fa comprendere come vi sia la concreta possibilità che proprio questo sistema sia stato protagonista degli eventi che hanno portato all’incidente Lion Air: il DFDR ha infatti mostrato che esisteva una differenza di rilevazione dell’angolo di attacco tra i sensori destro e sinistro di circa 20 gradi, ancor prima che l’aereo decollasse (e fino alla fine della registrazione)!
In attesa del rapporto conclusivo, che più avanti vedremo, una serie di ragionevoli preoccupazioni si sono destate, soprattutto tra i piloti, evidentemente tenuti all’oscuro di una funzione potenzialmente cruciale.
Per tale ragione i sindacati dei piloti si sono mossi nei confronti di Boeing: in base a quanto raccontato dal New York Times [2], a poche settimane di distanza da questo incidente i piloti dell’American Airlines hanno fatto pressioni sui manager di Boeing affinché lavorassero urgentemente ad una sistemazione del problema, paventando anche l’ipotesi di tenere a terra il Max come misura d’emergenza. I piloti espressero frustrazione sul fatto che Boeing non li avesse neppure informati della presenza del nuovo software sull’aereo fino al disastro della Lion Air.
Il portavoce del sindacato piloti, al termine dell’incontro, chiese espressamente se Boeing fosse ancora fiduciosa sulla sicurezza del Max, e se “la situazione sia sotto controllo, prima che sia implementata la sistemazione del software”, ricevendo come risposta: “Assolutamente”.
Perché l’MCAS?
Prima di affrontare la storia del successivo incidente risulta importante comprendere questo ‘nuovo’ sistema di AI inserito sul 737MAX ad insaputa degli stessi piloti. L’esigenza deriva dall’obiettivo di produrre un velivolo in grado di ridurre i costi di esercizio, risultato già ottenuto da Airbus con l’introduzione dell’A320neo nel 2016: 15% in meno di carburante e più silenzioso.
I motori che consentono però di ottenere queste prestazioni sono più grandi ed ingombranti, che sull’A320 riescono comunque a trovare alloggiamento in virtù della sua maggiore altezza da terra, al contrario del 737 che era stato progettato negli anni ’60 optando per un carrello di minore altezza, facilitando così l’ispezione e la manutenzione da terra.
Modifiche della struttura del 737 per risolvere questo problema avrebbero richiesto molto tempo, sia di progettazione che di realizzazione e una successiva fase di certificazione. La scelta operata è stata quindi di installare i motori in una posizione più alta, e per questo necessariamente più avanzata, rispetto alla posizione originale.
Questo comporta lo spostamento della linea centrale di spinta dell’aereo, e una significativa propensione a ‘sollevare il naso’, specialmente nei momenti in cui viene applicata la massima potenza.
Questa “propensione” eccessiva al sollevamento della prua proprio nei momenti di massima potenza, come di già elevati angoli di attacco, sicuramente rendeva il comportamento dell’aereo differente dai 737 già in esercizio. E qui arriva la scelta di Boeing: risolvere il “problema hardware” con una “soluzione software”, certamente meno impegnativa, meno costosa e meno lunga come sarebbe stato rimettere mano al progetto dell’aereo. Così nasce il sistema MCAS, o “Maneuvering Characteristics Augmentation System” [6].
E’ bene qui fare una precisazione: spesso nelle news e nei diversi approfondimenti dedicati è stato indicato questo software come “anti-stallo”. L’argomento è in realtà dibattuto, in quanto Boeing, come altri esperti, ritengono che sia del tutto errata come dizione, nel senso che il sistema non è pensato per eseguire operazioni anti-stallo, ma semplicemente per modificare il comportamento del 737 MAX in modo che la sua risposta ai comandi rimanga identica a quella del 737 tradizionale. Tuttavia, pare che l’implementazione più aggressiva di questo sistema fosse derivata proprio dal comportamento del 737MAX alle basse velocità prossime allo stallo.
Sia come sia, l’obiettivo era certamente quello di rendere ‘trasparente’ al pilota il comando dell’aereo attraverso il supporto del software: questo sarebbe intervenuto con le opportune correzioni facendo in modo da annullare l’effetto di aumento del picco senza l’intervento esplicito del pilota. Ciò significava anche non dover fare training ai piloti, con i costi e i tempi risparmiati anche per questo.
Per pilotare un 737 MAX sarebbe quindi stato sufficiente un breve aggiornamento fatto sull’ipad: un corso di 56 minuti da tenere direttamente sul tablet.
Il volo Ethiopian ET-302
E, invece, il 10 marzo 2019, un altro gravissimo incidente funesta la reputazione del 737MAX: il volo ET-302 si schianta al suolo uccidendo tutte le 157 persone a bordo pochi minuti dopo il decollo dall’aeroporto di Addis Abeba.
Il rapporto preliminare [3] racconta una storia molto simile a quella vista nei dati dell’incidente precedente: i sensori dell’angolo di attacco durante il decollo appaiono normali e allineati, ma poco dopo il sensore di destra misura un angolo di 74,5 gradi, contro i 15,3 dell’altro sensore.
Questo verosimilmente ‘innesca’ il sistema di controllo, che agisce facendo puntare il muso dell’aereo verso il basso, azione a cui si contrappone quella dei piloti, in una sequenza interrotta a un certo punto dall’esclusione del motore che comanda gli stabilizzatori, come indicato dalla checklist. Il rapporto indica che l’equipaggio eseguì la checklist mettendo gli interruttori del trim dello stabilizzatore nella posizione ‘cutout’, confermando che l’operazione di trim manuale non stava funzionando.
Quello che il grafico mostra dopo questa azione è qualcosa che fa pensare che verosimilmente gli interruttori siano stati rimessi nella posizione operativa, visto che all’azione di trim dei piloti corrisponde poco dopo un ultimo, irrecuperabile, comando di ‘naso giù’ da cui non sarà più possibile alcun recupero: in pochi secondi, a 900 Km/h, l’aereo impatterà il suolo.
La ‘checklist’ di questo problema è anche messa a disposizione nel rapporto preliminare, e riportata qui di seguito:
Si legge chiaramente come in caso di effetto continuato dello stabilizzatore, viene indicato di arrivare a togliere l’alimentazione ai motori che muovono lo stabilizzatore, agendo poi manualmente sulle ruote del trim (grasp and hold).
Va detto però che questa modalità operativa di gestione manuale del trim dello stabilizzatore presenta sul 737 delle problematiche piuttosto importanti, anche se al momento non è chiaro se queste si siano effettivamente verificate nel caso dell’incidente Ethiopian. Senza entrare nel merito di una spiegazione tecnica più dettagliata, il fenomeno che si può creare quando non è il motore a muovere lo stabilizzatore, ma la ruota manuale cablata con lo stabilizzatore stesso, è che le forze in gioco sul piano di coda siano tali da non consentire la manovra manuale.
Questo tipo di fenomeno è peraltro noto [4], e caratteristico per questo aeromobile, tant’è che per consentire una gestione dello stesso erano già state definite delle apposite manovre, come è possibile rilevare nelle procedure di emergenza che risalgono agli anni ’80, del 737, tramite una manovra definita “montagne russe” (roller coaster). La manovra deve essere realizzata in modo iterativo: viene ‘allentata’ per qualche secondo la pressione sul piano di coda tramite la cloche, in modo da rendere possibile l’azione di rotazione manuale del trim, ripetendo l’iter fino a stabilizzazione avvenuta. E’ evidente che una tale procedura non ha modo di essere adottata se il velivolo si trova a bassa quota, in quanto non vi è l’altezza sufficiente a portare a termine l’operazione.
In ogni caso, ad oggi, non è dato sapere se questo fenomeno si sia verificato e se abbia giocato un ruolo nel volo Ethiopian. Rimanendo in attesa di migliori indicazioni dal rapporto definitivo, è comunque anche questa una variabile importante da valutare: l’azione indicata in check list espone comunque -tramite la necessità di azione manuale sul trim- ad un elevato livello di rischio quando questa interviene in fase di decollo, ovvero quelle fasi in cui l’aereo si trova a volare a bassa quota, e i margini di intervento pressoché nulli.
L’upgrade del software
Era evidente che dopo due incidenti così gravi, a breve distanza di tempo, il 737MAX non poteva essere più considerato “sicuro” e per questo a livello mondiale questo aereo è stato “messo a terra” per un periodo indefinito, in modo da comprendere se vi sono effettivamente dei problemi e dei rischi strutturali.
Al momento di pubblicazione di questo articolo ancora non è chiaro quando verrà nuovamente dato il via libera dai diversi regolatori a livello globale. Il danno economico, per Boeing, e per tutti gli operatori che hanno in uso questo aeromobile, o ne avevano ordinati degli esemplari, è enorme. Il danno di immagine per Boeing e per la FAA, il regolatore americano, è altrettanto grande, e probabilmente avrà degli strascichi nel prossimo periodo. Al momento l’indicazione è che questo aereo potrebbe tornare a volare nel 2020, dopo aver sicuramente provveduto ad un nuovo, esaustivo e puntuale, processo di ri-certificazione.
Boeing è necessariamente intervenuta sul software MCAS, per rilasciarne un “aggiornamento” dichiarato come risolutivo dei problemi osservati. Ad avviso del CEO di Boeing, come affermato in conferenza stampa [9] il 29 aprile 2019, questa attenzione non è significativa di una responsabilità riconosciuta a questo sistema (“in ogni incidente grave c’è una catena di eventi che accadono, non è corretto attribuire la causa ad uno dei singoli elementi, noi sappiamo che ci sono dei miglioramenti che possiamo portare al sistema MCAS, e noi faremo questi miglioramenti”), ma al fatto che “uno degli anelli” della catena di eventi che ha portato al disastro è “l’attivazione del sistema MCAS a causa di errati dati sull’angolo di attacco”, un “fattore comune in entrambi gli incidenti”.
C’è da dire che il concetto stesso di ‘upgrade’ di un sistema software all’interno di un aeromobile desta di per sé qualche ragionevole perplessità: siamo probabilmente abituati a veder aggiornare “il firmware” di qualche dispositivo domestico, spesso tramite una chiavetta USB che contiene il software aggiornato da installare, altra cosa è che questo sia necessario per un aereo di linea che trasporta centinaia di passeggeri.
In ogni caso la reale preoccupazione, se non sbigottimento, che emerge in modo dirompente da questa fase è il comunicato stesso di Boeing [10] che riassume gli interventi effettuati per aggiornare il software.
In questo comunicato, si legge che:
“Boeing ha sviluppato un aggiornamento del software MCAS al fine di raggiungere un ulteriore livello di protezione se i sensori dell’angolo di attacco (AOA) forniscono dati errati. […] I livelli addizionali di protezione includono:
- I sistemi di controllo del volo ora confrontano gli input di entrambi i sensori AOA. Se i sensori mostrano una differenza di 5,5 gradi o più, con i flap retratti, MCAS non si attiva. Un indicatore sul cruscotto mostrerà questo allarme ai piloti;
- Se MCAS si attiva in condizioni non normali, fornirà solamente un input per ogni evento di angolo di attacco elevato. Non ci sono condizioni di guasto note o previste per cui MCAS fornirà input multipli;
- MCAS non potrà mai comandare più input allo stabilizzatore di quello che può essere controbilanciato dall’azione dell’equipaggio sui comandi dell’aereo. I piloti continueranno ad avere sempre la possibilità di annullare l’MCAS e controllare manualmente l’aereo.
Questi aggiornamenti riducono il carico di lavoro dell’equipaggio in condizioni di volo non normali e impediscono che dati errati causino l’attivazione di MCAS.”
Quanto sopra consente di capire, prima di ogni altra cosa, quale fosse la reale “soluzione software” inizialmente adottata da Boeing con l’introduzione di MCAS. Un sistema che:
- Prendeva decisioni sulla base di un solo sensore, senza alcun sistema di verifica di eventuali errori e senza segnalare il suo intervento;
- Agiva senza mai interrompersi finché la situazione di elevato angolo di attacco era rilevata, anche in presenza di comandi contrari dell’equipaggio;
- Agiva con un’azione di entità tale da rendere critica la risposta dell’equipaggio tramite il normale controllo dell’aereo.
E’ evidente che questa descrizione dell’upgrade svela più di ogni altra cosa uno scenario incredibile e assurdo in merito alle modalità di sviluppo del software su un sistema aeronautico e alla sua qualità.
Una menzione a parte merita anche la discutibile scelta di non rendere evidente tramite un apposito avviso la situazione di disallineamento delle misure tra i due sensori AOA: questa caratteristica era implementata solo come opzionale ad un costo aggiuntivo, e anche dopo l’incidente di Lion Air fu ritenuta un’indicazione superflua. In un comunicato Boeing (Boeing Statement on AOA Disagree Alert) si legge che “quando il MAX tornerà in servizio, tutta la produzione avrà un avviso di disallineamento AOA”, anche per i precedenti aerei già consegnati.
I criteri per la progettazione sicura
Tutto ciò conduce inequivocabilmente alla necessità di comprendere il processo che ha portato alla creazione di un sistema così evidentemente inadeguato ad essere installato su un aereo di linea. Come è stato possibile?
Secondo il racconto del NYT [11], un anno prima che la realizzazione del 737 MAX fosse completata, Boeing ha reso il sistema MCAS più aggressivo e ‘rischioso’: mentre la versione originale si doveva basare sui dati di almeno due tipi di sensori, la versione finale ne ha usato solamente uno, senza criteri di salvaguardia. Sembrerebbe che molte persone coinvolte nella costruzione, test e approvazione del sistema MCAS non avessero la piena conoscenza di tali cambiamenti: le dichiarazioni di impiegati di Boeing al giornale americano erano che “pensavano che il sistema si basasse su più sensori e che si sarebbe attivato raramente, se mai”.
Inizialmente, MCAS non doveva essere un componente software ‘rischioso’: il sistema si sarebbe dovuto attivare in circostanze rare, abbassando dolcemente il naso dell’aereo nelle manovre ad alta velocità, basando i suoi dati su misure provenienti da sensori multipli (accelerazione dell’aereo, angolo rispetto al vento) proprio per evitare erronee attivazioni.
Successivamente, gli ingegneri di Boeing hanno riconcepito questo sistema, soprattutto abilitandolo ad abbassare in modo aggressivo il naso dell’aereo, rimuovendo i meccanismi di salvaguardia, che dovevano essere 2: angolo di attacco e G-force. Dai previsti 0,6 gradi in circa 10 secondi, nella nuova versione di MCAS lo stabilizzatore può essere spostato di 2,5 gradi nello stesso tempo.
Pare che gli ufficiali della FAA, l’ente americano che deve rilasciare la certificazione al volo, non fossero stati aggiornati sulla modifica così effettuata, né che questa portasse con sé all’interno di Boieng una rivalutazione del rischio connesso.
I test effettuati per verificare il funzionamento di MCAS non hanno contemplato l’attivazione del sistema come risultato di una lettura errata del sensore dell’angolo di attacco, considerandola come un’eventualità rara, una volta in 10 milioni di ore di volo.
E così, quando Boeing mandò una mail nel 2016 all’FAA chiedendo di rimuovere MCAS dal manuale dei piloti, questa fu approvata sulla base dell’impressione che questo fosse un sistema sostanzialmente benigno e di rara attivazione. Con questa soluzione Boeing ha anche potuto risparmiare milioni di dollari per l’aggiornamento dei piloti, rispondendo in tempi più brevi alla pressione di Airbus con il suo A320NEO.
Le nuove problematiche emerse nel processo di ri-certificazione
E’ chiaro che il processo di ri-certificazione in corso attualmente sul 737MAX, a valle delle modifiche apportate da Boeing, è diventato molto più scrupoloso di quanto non lo fosse prima (e verrebbe da chiedersi come mai un processo di questo tipo non debba essere sempre rigorosamente scrupoloso, senza eccezioni).
Ciò ha fatto emergere ulteriori problematiche piuttosto inattese. Come riporta Reuters [12], durante i test al simulatore effettuati dai piloti della FAA, cercando scenari di attivazione intenzionale del sistema MCAS, durante un’attivazione si è notato un periodo più esteso per il recupero del sistema di trim dello stabilizzatore.
L’aspetto preoccupante è che non è chiaro se questo tipo di situazione possa essere risolto con un miglioramento del software o se si tratti di un problema del microprocessore, cosa che richiederebbe una sua sostituzione a livello quindi hardware.
Questo rilievo, nell’articolo rimasto poco chiaro, sembrerebbe essere legato al tipo di microprocessore utilizzato, l’80286, che risale al 1986: ciò non deve di per sé far preoccupare, anzi, i processori di questa tipologia sono molto affidabili e sostanzialmente “error free”, ma per quanto ottimizzato, il software potrebbe eccedere la capacità elaborativa. Non è noto come sia stato superato questo presunto problema.
Ma l’attento scrutinio in corso sul 737 MAX ha fatto emergere anche altre problematiche, che in funzione di quanto accaduto non possono essere così facilmente superate oggi, o quanto meno gettano una luce ambigua sulle metodologie di progettazione e sviluppo di Boeing.
Come, ad esempio, il fatto riportato da Bloomberg [13] che lo sviluppo del software del MAX fosse stato assegnato tramite subappalti a lavoratori temporanei stranieri pagati 9 dollari all’ora per sviluppare e testare il software.
Oppure, come riportato dal NYT [14] che durante la certificazione del 737MAX, l’FAA ha ‘ritirato’ alcune raccomandazioni dei suoi stessi membri dopo le insistenze della Boeing. Proprio per la tipologia di motore più grande utilizzato dal MAX, ne deriva anche un maggior rischio in caso di rottura della turbina o delle sue pale: i danni provocati in caso di distacco possono essere più gravi rispetto a quelli derivanti da un motore più piccolo, in particolare arrivando magari a tranciare i cavi che dalla cabina di pilotaggio arrivano in coda per muovere il timone. Da qui la richiesta di riprogettare il sistema di cavi che controlla il timone, per proteggerlo da questo tipo di incidente, contrastata poi con successo dalle pressioni di Boeing.
E ciò non fa che ampliare la portate dei dubbi su quanto il regolatore americano fosse indipendente nel processo di certificazione: sebbene su questa vicenda un interno dell’FAA fece un reclamo anonimo, il successivo team investigativo produsse risultati discutibili, ma intanto l’approvazione a non ridondare o proteggere meglio il sistema di cavi era già stata data, creando anche una sensibile frustrazione tra gli esperti dell’FAA.
Consapevole del grave fallimento in questa certificazione, l’FAA ha quindi deciso di affidare ad un comitato di esperti, il JATR (Joint Authorities Techical Review, un organismo indipendente composto dai rappresentati tecnici di FAA, NASA e autorità dell’aviazione civile provenienti da Australia, Brasile, Canada, Cina, Europa, Indonesia, Giappone, Singapore e Emirati Arabi Uniti), la valutazione del processo di certificazione del sistema di controllo di volo del 737MAX .
Questo comitato ha espresso le sue raccomandazioni l’11 ottobre 2019 con una pubblicazione [15], contenente 12 raccomandazioni per migliorare il processo di certificazione di questi sistemi, partendo proprio dalla regola del “cambio prodotto” (Changed Product Rule), in cui tenere in considerazione alcuni principi chiave, come una completa analisi integrata a livello di sistema per riconoscere tutte le possibili interazioni della ‘novità’ su tutte le altre parti del sistema.
E se fosse colpa dei piloti?
Fin qui, tutto farebbe convergere su un problema creato dal software, ma non tutti gli analisti sono d’accordo su questo. Sul New York Times Magazine un articolo sposta tutta l’attenzione sui piloti [16].
Per quanto vero che il sistema MCAS fosse stato implementato in modo errato, che la progettazione del MAX avesse dei difetti, che il processo di certificazione altre falle… ma, ci si chiede nell’articolo, qualunque fosse stata la ragione per la quale lo stabilizzatore si fosse impropriamente mosso, perché i piloti non hanno reagito prontamente come avrebbero dovuto, come previsto dal manuale?
Secondo l’autore, che si cimenta in una minuziosa analisi dei comportamenti dei piloti, in entrambi gli incidenti viene fatto notare come alcune regole di sicurezza e di esperienza da parte dei piloti avrebbero forse potuto evitare di arrivare ai due disastri. L’articolo pone poi attenzione anche al fatto che la crescente crescita del comparto aereo negli ultimi anni, la forte competizione, la necessità di riduzione dei costi, porti ad avere oggi piloti con un’esperienza inferiore, anche per l’altissimo grado di automatismo presente sugli aerei stessi, in grado di semplificare il compito al pilota in modo da evitare che si trovi in situazioni di rischio.
Paradossalmente, infatti, l’elevata informatizzazione del controllo del volo e di tutti i sistemi a supporto, ha reso più fragili i piloti nello sviluppare una maggiore padronanza del mezzo, via via più complicato come sistemi, ‘scollegando’ il pilota dal comando diretto del mezzo.
Avvisaglie di questi potenziali pericoli si erano già viste anni fa, con l’incidente del volo AF447, nel 2009: in quel caso un A330 che, come nella filosofia di Airbus, è provvisto di un sistema informatico di automazione del volo che di fatto lascia ai computer la gestione dell’aeromobile nella maggior parte del tempo. Le modalità standard di funzionamento fanno sì che vengano impedite (o corrette) le azioni dei piloti che possano causare pericolo al volo, in pratica correggendo e proteggendo l’aereo da manovre potenzialmente errate, che lo farebbero uscire da quella che è definita come la ‘curva di sicurezza di volo’ (flight envelope). In questo incidente, la rilevazione della velocità errata causata dal ghiaccio nei tubi di Pitot è stata riconosciuta dal sistema di volo automatico, e per la presenza di tali informazioni inconsistenti si è ‘scollegato’ lasciando ai piloti l’onere di gestire l’aereo in presenza di tali discrepanze sui dati di volo. Senza un precedente avviso…
Purtroppo, però, ciò ha colto completamente di sorpresa i piloti, che hanno avuto di fatto solo pochi minuti per comprendere cosa stesse succedendo, reagendo in modo scorretto, in particolare cercando di alzarsi di quota, e non cogliendo (di notte e ad alta quota) che così stavano uscendo dalla curva di sicurezza portando l’aeromobile allo stallo.
Una chiara concausa di quel disastro è stata sostanzialmente un’interazione uomo-computer completamente fallita, in cui il computer non è riuscito a comunicare correttamente ai piloti le informazioni essenziali e l’uomo non aveva il reale controllo della macchina…
Tornando all’articolo del NYT, che ha raccolto moltissime critiche per aver rivolto queste accuse ai piloti, secondo uno schema non nuovo in questi incidenti, ovvero cercando di addossare la colpa alle vittime, va tuttavia detto che anche questa minore capacità di controllo del mezzo, questa inferiore ‘sensibilità’ a riconoscere il malfunzionamento e a diagnosticare velocemente delle azioni di recupero è oggettivamente un problema emergente, e può certamente aver avuto un ruolo in entrambi gli incidenti. Una sorta di problema di effettiva e concreta “padronanza” del mezzo, reso sempre più autonomo in molte fasi del volo.
Il Final Report del volo Lion Air
E quindi, a cosa si deve il disastro del Lion Air? Il Report appena pubblicato ha puntualmente messo in evidenza tutti i tasselli che hanno costituito la complessiva “catena di eventi” che ha portato all’incidente, ma il responso che emerge con maggiore enfasi è la pesante critica al sistema MCAS, come principale fattore.
- Errata valutazione del rischio attribuita a questo sistema;
- errata valutazione delle reazioni dell’equipaggio e dei suoi tempi di risposta;
- eccessiva azione dell’MCAS sullo stabilizzatore, arrivando a poterlo configurare, nelle ripetute attivazioni di MCAS, ad angoli superiori a qualunque possibilità per l’equipaggio di poter controbilanciare con il normale comando dell’elevatore;
- difficoltà ad individuare la corretta procedura di gestione dell’anomalia;
- presenza di allarmi multipli e indicazioni in cabina che hanno sovraccaricato il compito dei piloti;
- errata valutazione di Boeing in merito al fatto che la disabilitazione del motore dello stabilizzatore fosse disponibile ma non richiesta in questi casi;
- errata valutazione di Boeing in merito alla probabilità di errore sul sensore dell’angolo di attacco (AOA);
- errata valutazione di Boeing in merito alla dipendenza di MCAS da un solo sensore AOA;
- errata valutazione di Boeing sulla mancata ridondanza del sensore AOA.
I dati di volo del Lion Air hanno mostrato come durante l’ultima fase del volo la discesa dell’aereo non poteva essere controllata per la necessità di forze sull’elevatore superiori a quelle limite. E’ stato anche verificato che tirare indietro la cloche normalmente interrompe qualunque comando di ‘naso giù’ dello stabilizzatore, ma questa funzione era disabilitata sul 737MAX con l’esecuzione del software MCAS.
E’ stato anche verificato come durante il tragico volo del Lion Air sono stati forniti erronei input dal sensore AOA che hanno portato a molti messaggi di errore in cabina, oltre all’attivazione dell’MCAS, complicando la comprensione della situazione per l’equipaggio, oltre al fatto che la vibrazione dei comandi intervenuta subito al decollo, oltre a produrre rumore, può aver reso difficile per l’equipaggio sentire il movimento della ruota del trim, e quindi a non accorgersi di questa azione. Gli allarmi in cabina avrebbero invece dovuto aiutare l’equipaggio ad identificare prontamente il problema, invece anche l’avviso dell’errore sull’angolo rilevato dal sensore (AOA DISAGREE), installato sulla versione NG, non era disponibile sul 737 dell’incidente, e la sua assenza ha reso ancor più difficile identificare il problema e correggerlo.
La mancata conoscenza dell’esistenza di questo sistema e di come agiva ha tolto all’equipaggio tempo cruciale per poter reagire alle continue attivazioni di MCAS, ma Boeing non aveva precedentemente fornito indicazioni o formazione specifica in merito a questo sistema, che invece -evidentemente- avrebbe dovuto essere parte del training.
Tra i fattori vengono anche elencati diversi comportamenti non corretti nelle fasi precedenti: nei voli precedenti erano stati rilevati gli stessi problemi, gestiti con difficoltà dai precedenti equipaggi, ma la comunicazione dell’esperienza vissuta non è stata correttamente riportata, oltre ad altre decisioni prese in quelle circostanze in modo difforme da quanto previsto dal regolamento.
Così come anche il sensore AOA incriminato era stato sostituito proprio prima del volo fatale, con una procedura di regolazione che verosimilmente non è stata condotta in modo corretto, lasciando quindi il sensore con una rilevazione dell’angolo errata in partenza.
Infine, viene anche indicata l’inefficiente gestione in cabina della situazione di crisi, con verbalizzazioni non fatte tra i piloti, indicatori di un fattore di stress superiore a quanto atteso, e una risposta a questi eventi non coerente con quello che avrebbe dovuto essere la reazione prevista.
L’audizione pubblica con la Commissione Trasporti USA
Il 29 ottobre 2019 si è tenuta un’audizione pubblica della Commissione Trasporti presso il Senato a Washington, che sta investigando sugli incidenti occorsi al 737MAX. A rispondere alle domande incalzanti dei senatori il CEO di Boeing, che ha espressamente ammesso che “abbiamo fatto degli errori e abbiamo sbagliato qualcosa”.
E in particolare, di fronte alle domande -scaturite proprio dall’esito del rapporto finale relativo al volo Lion Air- se fossero stati effettivamente testati tutti gli aspetti relativi all’affidabilità di un solo sensore, alla risposta legata al fattore umano e a tutti gli altri elementi evidenziati in quel rapporto, la risposta è stata un laconico “no”.
Considerazioni finali
La crescente digitalizzazione di ogni aspetto della vita umana ha portato con sé molte comodità nella vita quotidiana, e certamente contribuito a migliorare la sicurezza in moltissimi ambiti, tra i quali quello aeronautico.
La grande attenzione ai due incidenti del Boeing 737 MAX è proprio derivata dallo sconcerto generato in questo settore, in cui la sicurezza ha raggiunto livelli molto alti, superiori a molte altre categorie, e per questo generando sgomento: in primis perché due incidenti così potessero accadere ancora, e a seguire per tutti i retroscena emersi piano piano, partendo -inevitabilmente questo è stato il primo tassello- da una ri-progettazione di un aereo che non ha seguito un rigoroso approccio orientato alla sicurezza, ma -così apparirebbe oggi- da un forte orientamento al risparmio di tempi e costi.
Forse per questo la “soluzione informatica” è parsa la panacea di tutto quello che avrebbe dovuto essere probabilmente ripensato in modo più organico. Un software per rendere l’aereo “come quello di prima”, anche se molto diverso: un modo per aiutare il pilota, in realtà ingannandolo con funzionalità per lui invisibili, e proprio per questo estremamente pericolose in caso di malfunzionamento.
In tutto ciò, non può neppure essere sottovalutato l’attuale ruolo dei piloti, che hanno gioco forza sempre meno padronanza degli aerei che pilotano in quanto estremamente automatizzati: aspetti da considerare, e probabilmente da rivalutare, già in fase di progettazione, proprio per rendere più trasparente ed efficace il rapporto uomo-macchina, soprattutto perché è chiaro che nel futuro anche in cabina di pilotaggio appariranno i sistemi di intelligenza artificiale (AI).
Alla fine, purtroppo, non è stato un problema di “qualche riga di codice” scritta male, ma qualcosa di ben più ampio e preoccupante: un approccio alla progettazione che apparirebbe essere stato troppo vincolato alle esigenze economiche e commerciali che non al rispetto degli standard e delle procedure esistenti, arrivando fino ad un impoverimento del ruolo del regolatore in quanto diminuito in una reale indipendenza rispetto al produttore.
E allarma come in questa vicenda “non sia bastato” il primo incidente del 737 Lion Air a far ripensare a cosa potesse essere stato sottovalutato o non compreso, decidendo di non lasciare a terra la flotta dei 737 MAX per quelle che sarebbero state delle doverose rivalutazioni dei fattori di rischio adottate in fase di progettazione e una seria disamina di quei tracciati di volo già disponibili poco tempo dopo l’incidente stesso. E le parole del CEO durante l’audizione a Washington appare purtroppo piuttosto lontana da una piena cultura della sicurezza: “Continuo a ripensare a quella decisione, ogni giorno, e se noi avessimo saputo ogni cosa allora che invece conosciamo adesso, noi avremmo preso un’altra decisione”.
Questi disastri -sotto il profilo della perdita umana imperdonabili, che sarà sempre doveroso ricordare per l’ingiusto e doloroso tributo versato da tutte le vittime- saranno però quelli che impediranno, questa almeno è la speranza concreta, il ripetersi di simili tragedie.
Bibliografia
[1] “FINAL KNKT.18.10.35.04”, Final Report, 29.10.2018
[2] “Before Ethiopian Crash, Boeing Resisted Pilots’ Calls for Aggressive Steps on 737 Max”, The New York Times
[3] “Aircraft Accident Investigation Preliminary Report Ethiopian Airlines Group B737-8 (MAX) Registered ET-AVJ”, Report No. AI-01/19, Federal Democratic Republic of Ethiopia – Ministry of Transport – Aircraft Accident Investigation Bureau
[4] “Vestigial design issue clouds 737 Max crash investigations”, The Air Current
[5] “Boeing’s 737 Max Suffers Setback in Flight Simulator Test”, New York Times,
[6] “How the Boeing 737 Max Disaster Looks to a Software Developer”, IEEE SPECTRUM
[7] “Safety Recommendation Report – Assumptions Used in the Safety Assessment Process and the Effects of Multiple Alerts and Indications on Pilot Performance” – NTSB – 26/09/2019
[8] “Boeing rejected 737 MAX safety upgrades before fatal crashes, whistleblower says”, The Seattle Times, 2.10.2019
[9] Boeing CEO holds news conference, 29.04.2019
[10] “Boeing: The 737 MAX MCAS Software Enhancement”, Boeing,
[11] “Boeing Built Deadly Assumptions Into 737 Max, Blind to a Late Design Change”, The New York Times, 1.06.2019
[12] “U.S. regulator cites new flaw on grounded Boeing 737 MAX”, Reuters, 26.06.2019
[13] “Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers”, Bloomberg, 28.06.2019
[14] “The Roots of Boeing’s 737 Max Crisis: A Regulator Relaxes Its Oversight”, The New York Times, 27.07.2019
[15] “The Joint Authorities Technical Review (JATR) – Boeing 737 MAX Flight Control System”, JATR, 11.10.2019
[16] “What Really Brought Down the Boeing 737 Max?”, The New York Times Magazine, 18.09.2019
