disastri aerei e AI

Aereo 737 MAX, colpa dell’intelligenza artificiale o dei piloti? Storia di due tragedie evitabili

Un sistema software pensato per semplificare la gestione dei piloti, è diventato invece il principale sospettato di due terribili incidenti aerei avvenuti nel 2018. Ma come stanno davvero le cose? Di chi è la responsabilità, umana o algoritmica? Un’analisi dettagliata dei fatti

Pubblicato il 19 Nov 2019

Paolo Reale

Ingegnere, Presidente ONIF

word-image

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:

Il secondo elemento è la comunicazione inviata da Boeing il 10 novembre 2018, diretta a tutti i clienti in possesso dello stesso modello di aeromobile, il 737MAX, che possiamo leggere nell’immagine di seguito:

A screenshot of a social media post Description automatically generated

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

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Speciale PNRR

Tutti
Incentivi
Salute digitale
Formazione
Analisi
Sostenibilità
PA
Sostemibilità
Sicurezza
Digital Economy
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr
CODICE STARTUP
Imprenditoria femminile: come attingere ai fondi per le donne che fanno impresa
DECRETI
PNRR e Fascicolo Sanitario Elettronico: investimenti per oltre 600 milioni
IL DOCUMENTO
Competenze digitali, ecco il nuovo piano operativo nazionale
STRUMENTI
Da Istat e RGS gli indicatori per misurare la sostenibilità nel PNRR
STRATEGIE
PNRR – Piano nazionale di Ripresa e Resilienza: cos’è e novità
FONDI
Pnrr, ok della Ue alla seconda rata da 21 miliardi: focus su 5G e banda ultralarga
GREEN ENERGY
Energia pulita: Banca Sella finanzia i progetti green incentivati dal PNRR
TECNOLOGIA SOLIDALE
Due buone notizie digitali: 500 milioni per gli ITS e l’inizio dell’intranet veloce in scuole e ospedali
INNOVAZIONE
Competenze digitali e InPA cruciali per raggiungere gli obiettivi del Pnrr
STRATEGIE
PA digitale 2026, come gestire i fondi PNRR in 5 fasi: ecco la proposta
ANALISI
Value-based healthcare: le esperienze in Italia e il ruolo del PNRR
Strategie
Accordi per l’innovazione, per le imprese altri 250 milioni
Strategie
PNRR, opportunità e sfide per le smart city
Strategie
Brevetti, il Mise mette sul piatto 8,5 milioni
Strategie
PNRR e opere pubbliche, la grande sfida per i Comuni e perché bisogna pensare digitale
Formazione
Trasferimento tecnologico, il Mise mette sul piatto 7,5 milioni
Strategie
PSN e Strategia Cloud Italia: a che punto siamo e come supportare la PA in questo percorso
Dispersione idrica
Siccità: AI e analisi dei dati possono ridurre gli sprechi d’acqua. Ecco gli interventi necessari
PNRR
Cloud, firmato il contratto per l’avvio di lavori del Polo strategico
Formazione
Competenze digitali, stanziati 48 milioni per gli Istituti tecnologici superiori
Iniziative
Digitalizzazione delle reti idriche: oltre 600 milioni per 21 progetti
Competenze e competitività
PNRR, così i fondi UE possono rilanciare la ricerca e l’Università
Finanziamenti
PNRR, si sbloccano i fondi per l’agrisolare
Sanità post-pandemica
PNRR, Missione Salute: a che punto siamo e cosa resta da fare
Strategie
Sovranità e autonomia tecnologica nazionale: come avviare un processo virtuoso e sostenibile
La relazione
Pnrr e PA digitale, l’alert della Corte dei conti su execution e capacità di spesa
L'editoriale
Elezioni 2022, la sfida digitale ai margini del dibattito politico
Strategie
Digitale, il monito di I-Com: “Senza riforme Pnrr inefficace”
Transizione digitale
Pnrr: arrivano 321 milioni per cloud dei Comuni, spazio e mobilità innovativa
L'analisi I-COM
Il PNRR alla prova delle elezioni: come usare bene le risorse e centrare gli obiettivi digitali
Cineca
Quantum computing, una svolta per la ricerca: lo scenario europeo e i progetti in corso
L'indice europeo
Desi, l’Italia scala due posizioni grazie a fibra e 5G. Ma è (ancora) allarme competenze
L'approfondimento
PNRR 2, ecco tutte le misure per cittadini e imprese: portale sommerso, codice crisi d’impresa e sismabonus, cosa cambia
Servizi digitali
PNRR e trasformazione digitale: ecco gli investimenti e le riforme previste per la digitalizzazione della PA
Legal health
Lo spazio europeo dei dati sanitari: come circoleranno le informazioni sulla salute nell’Unione Europea
Servizi digitali
PNRR e PA digitale: non dimentichiamo la dematerializzazione
Digital Healthcare transformation
La trasformazione digitale degli ospedali
Governance digitale
PA digitale, è la volta buona? Così misure e risorse del PNRR possono fare la differenza
Servizi digitali
Comuni e digitale, come usare il PNRR senza sbagliare
La survey
Pnrr e digitale accoppiata vincente per il 70% delle pmi italiane
Missione salute
Fascicolo Sanitario Elettronico alla prova del PNRR: limiti, rischi e opportunità
Servizi pubblici
PNRR: come diventeranno i siti dei comuni italiani grazie alle nuove risorse
Skill gap
PNRR, la banda ultra larga crea 20.000 nuovi posti di lavoro
Il Piano
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUMPA2022
PNRR e trasformazione digitale: rivedi i Talk di FORUM PA 2022 in collaborazione con le aziende partner
I contratti
Avio, 340 milioni dal Pnrr per i nuovi propulsori a metano
Next Generation EU
PNRR, a che punto siamo e cosa possono aspettarsi le aziende private
Fondi
Operativo il nuovo portale del MISE con tutti i finanziamenti per le imprese
Servizi comunali
Il PNRR occasione unica per i Comuni digitali: strumenti e risorse per enti e cittadini
Healthcare data platform
PNRR dalla teoria alla pratica: tecnologie e soluzioni per l’innovazione in Sanità
Skill
Competenze digitali, partono le Reti di facilitazione
Gli obiettivi
Scuola 4.0, PNRR ultima chance: ecco come cambierà il sistema formativo
Sistema Paese
PNRR 2, è il turno della space economy
FORUM PA 2022
FORUM PA 2022: la maturità digitale dei comuni italiani rispetto al PNRR
Analisi
PNRR: dalla Ricerca all’impresa, una sfida da cogliere insieme
Innovazione
Pnrr, il Dipartimento per la Trasformazione digitale si riorganizza
FORUM PA 2022
PA verde e sostenibile: il ruolo di PNRR, PNIEC, energy management e green public procurement
Analisi
PNRR, Comuni e digitalizzazione: tutto su fondi e opportunità, in meno di 3 minuti. Guarda il video!
Rapporti
Competenze digitali e servizi automatizzati pilastri del piano Inps
Analisi
Attuazione del PNRR: il dialogo necessario tra istituzioni e società civile. Rivedi lo Scenario di FORUM PA 2022
Progetti
Pnrr, fondi per il Politecnico di Torino. Fra i progetti anche IS4Aerospace
Analisi
PNRR, Colao fa il punto sulla transizione digitale dell’Italia: «In linea con tutte le scadenze»
La Svolta
Ict, Istat “riclassifica” i professionisti. Via anche al catalogo dati sul Pnrr
Analisi
Spazio, Colao fa il punto sul Pnrr: i progetti verso la milestone 2023
FORUM PA 2022
Ecosistema territoriale sostenibile: l’Emilia Romagna tra FESR e PNRR
Il Piano
Innovazione, il Mise “centra” gli obiettivi Pnrr: attivati 17,5 miliardi
Analisi
PNRR: raggiunti gli obiettivi per il primo semestre 2022. Il punto e qualche riflessione
Analisi
PNRR: dal dialogo tra PA e società civile passa il corretto monitoraggio dei risultati, tra collaborazione e identità dei luoghi
Webinar
Comuni e PNRR: un focus sui bandi attivi o in pubblicazione
Analisi
Formazione 4.0: cos’è e come funziona il credito d’imposta
PA e Sicurezza
PA e sicurezza informatica: il ruolo dei territori di fronte alle sfide della digitalizzazione
PA e sicurezza
PNRR e servizi pubblici digitali: sfide e opportunità per Comuni e Città metropolitane
Water management
Water management in Italia: verso una transizione “smart” e “circular” 
LE RISORSE
Transizione digitale, Simest apre i fondi Pnrr alle medie imprese
Prospettive
Turismo, cultura e digital: come spendere bene le risorse del PNRR
Analisi
Smart City: quale contributo alla transizione ecologica
Decarbonizzazione
Idrogeno verde, 450 milioni € di investimenti PNRR, Cingolani firma
Unioncamere
PNRR, imprese in ritardo: ecco come le Camere di commercio possono aiutare
I fondi
Industria 4.0: solo un’impresa su tre pronta a salire sul treno Pnrr

Articoli correlati

Articolo 1 di 3