Fiumi di inchiostro e di bit ci hanno giustamente inondato a seguito dei disastri aerei che hanno coinvolto due aeromobili Boeing 737 MAX, aerei di concezione modernissima e praticamente nuovi di zecca.

Proprio a seguito di questo eccesso mediatico è possibile che la maggior parte dei lettori si sia perso il motivo principale delle catastrofi, ormai assodato per la prima, altamente probabile per la seconda.

Poiché è un problema di ingegneria del software, di interazione uomo-macchina e di documentazione tecnica, è molto interessante descriverlo nella maniera più breve e concisa possibile.

Tre premesse tecniche:

Leggi anche:

L'IA? È pericolosa come una guerra nucleare

Sibille e Mentecatti Artificiali

Windows 11, riportare in vita il menu Start di W10

Ex designer di Microsoft demolisce il menu Start di Windows 11

1) Le ali di un aereo spingono verso l'alto, e permettono all'aereo di volare, solo a partire da una certa velocità; se un aereo che sta volando tranquillamente scende sotto questa velocità cade in verticale, improvvisamente e senza nessun preavviso, come un ferro da stiro. Questo fenomeno, incubo di qualsiasi pilota, si chiama stallo, e la velocità a cui questo avviene si definisce velocità di stallo.

2) La velocità di cui si parla è quella relativa all'aria, non al suolo, quindi è influenzata da eventi imprevedibili come un cambio di velocità del vento; non è misurabile da strumenti come il GPS o il radar, che misurano invece la velocità assoluta rispetto al terreno.

3) Per questo motivo esistono sensori multipli che, misurando la velocità dell'aria in vari punti dell'aereo, scattano in maniera "rumorosa" appena ci si avvicina alla velocità di stallo.

Visto che gli aerei (e non solo) sono ormai comandati dal software, e i comandi dei piloti sono solo uno degli input che il software analizza, come si deve realizzare un avviso di stallo imminente nell'abitacolo del pilota con qualcosa che sia meno rozzo di un sirena assordante e una luce rossa lampeggiante?

E' semplice: integrandolo nell'interfaccia utente del pilota, già molto complessa, e asservendolo al software di bordo. E qui, pare, è nato il problema.

Si noti che quanto segue è il miglior riassunto possibile elaborato dall'autore senza avere accesso diretto alla documentazione tecnica e ai carteggi intercorsi tra Boeing e IATA. Potrebbero quindi esserci imprecisioni, incompletezze o errori, di cui eventualmente l'autore si scusa e che promette di correggere ove esistenti.

Tutti sanno che negli aeromobili esiste il pilota automatico, che permette all'aereo di volare senza l'interazione del pilota, sulla base di parametri preimpostati. Quando il pilota ha il controllo manuale dell'aeromobile, questo automatismo è disinserito.

Visto che è sempre il software che controlla l'aereo, è più preciso riassumere affermando che il software ignora gli input dei comandi quando è attiva la modalità pilota automatico, e invece li elabora e dà loro la precedenza quando è attiva la modalità volo manuale.

Nel Boeing 737 MAX l'allarme di stallo si è evoluto in un sottosistema software con un nome preciso: Maneuver Characteristics Augmentation System (MCAS), che è stato integrato nel software di bordo in questo modo: in modalità pilota automatico, MCAS partecipa a determinare le azioni del software di bordo come input supplementare; in volo manuale invece MCAS non è disinserito, non è nemmeno attivo solo come allarme, ma mantiene la sua funzione automatica, senza che di questo il pilota abbia particolare evidenza.

Pur trattandosi di una novità, sembra che questo fatto non fosse nemmeno spiegato a sufficienza nel manuale di aggiornamento, destinato ai piloti che avessero già esperienza di volo su modelli simili di aereo e dovessero essere addestrati al volo sul nuovo modello.

MCAS, pare ormai assodato, non è stato in grado di reagire bene al malfunzionamento di uno dei sensori di velocità dell'aria di cui era dotato. Pare che MCAS non abbia rilevato il malfunzionamento di un singolo sensore, e che quindi abbia "pensato" che l'aereo stesse per entrare in condizioni di stallo.

Cosa deve fare, da sempre, un pilota in questi casi? Deve aumentare a tutti i costi la velocità dell'aeromobile; il modo più sicuro per farlo è farlo scendere, in modo che acquisti velocità.

In totale automatismo, come era progettato, il sottosistema software MCAS ha fatto questo, e si è quindi instaurata una lotta tra i piloti (che cercavano di risalire, non comprendendo da cosa era dovuta la pericolosa ed errata manovra) e MCAS (che cercava di scendere per salvare l'aeromobile).

Ha vinto il software. Anzi, ha stravinto.

La questione di fondo è se i piloti conoscessero davvero l'esistenza dell'MCAS, in particolare il fatto che era attivo anche durante il volo manuale e che, se necessario, doveva essere disattivato a parte. Sicuramente, i fatti lo hanno ahimè dimostrato, l'interfaccia utente del software non lo rendeva abbastanza evidente, e la documentazione non lo ha evidenziato in maniera sufficiente.

Così si scopre che due tragedie non sono state causate dal malfunzionamento di un sensore o del software dell'aeromobile nel suo complesso, ma a scelte precise (apparentemente ragionevoli ma errate) della progettazione del software di bordo e della documentazione per i piloti.

A questo punto, a coloro che specificatamente si occupano di sviluppo e integrazione di software di grandi dimensioni, vorrei porre due domande.

1) Le metodologie e le prassi di progettazione e di testing (non di sviluppo) sono affidabili in contesti di questa complessità? L'ordine di grandezza è di 100 milioni di linee di codice.

2) Lo stato dell'arte della progettazione delle interfacce utente di questi software è sufficiente per gestire in maniera sicura decisioni gravi e improvvise, quali la necessità di "strappare di mano" i comandi ai piloti?

In questo caso, verrebbe da concludere, le risposte dovrebbero essere ambedue negative.