Tra il 2018 e il 2019, due aerei di linea precipitano a pochi minuti dal decollo.
Non c’è alcun sabotaggio, né errore umano, e nemmeno un improvviso cedimento strutturale: la colpa è di un sensore da poche centinaia di dollari e un software progettato per correggere un errore che, in realtà, non esisteva.

BUG ARCHEOLOGY — EPISODIO 23

“Per quanto la tecnologia possa essere sofisticata, la natura non sarà mai ingannata” – Richard Feynman

👶 Introduzione per chi parte da zero

Il Boeing 737 MAX era la nuova evoluzione del best seller dei cieli: il 737, l’aereo passeggeri più venduto nella storia.
Per competere con i nuovi Airbus A320neo, più efficienti e silenziosi, Boeing scelse di montare motori più grandi e più pesanti sul suo vecchio 737.

Il problema fu che quei motori, per ragioni aerodinamiche, modificarono il comportamento dell’aereo in certe condizioni: tendeva a impennarsi.

Così nacque il MCAS, Maneuvering Characteristics Augmentation System: un software che, se l’aereo mostrava un angolo d’attacco troppo alto, abbassava automaticamente il muso: praticamente una sorta di cerotto digitale applicato ad un difetto meccanico.

E, così, bastò un sensore difettoso perché il software decidesse che l’aereo stava stallando quando, in realtà, volava perfettamente.

I. Il sintomo: due decolli, due cadute

Lion Air 610 — 29 ottobre 2018

Pochi minuti dopo il decollo da Giacarta, il 737 MAX inizia a immergersi ripetutamente.
I piloti tirano il muso in su, il software lo spinge giù.
Una lotta invisibile, asimmetrica, persa in partenza.
Dopo undici minuti, l’aereo colpisce il mare.

Ethiopian Airlines 302 — 10 marzo 2019

Anche qui assistiamo a stessa sequenza, stessa dinamica, stesso algoritmo.

La fiducia nella “nuova era” del 737 MAX si autodistrusse non in 37 secondi, come per Ariane 5, ma in due tragedie gemelle, separate da pochi mesi.

II. L’origine: il compromesso nascosto

Boeing non poteva cambiare radicalmente il 737: avrebbe richiesto una nuova certificazione, anni di sviluppo, miliardi di dollari; così scelse la strada dell’adattamento: estendere il modello esistente, mantenere la stessa formazione per i piloti, evitare costi.

Il problema era aerodinamico:

• I nuovi motori erano troppo grandi.
• Dovevano essere montati più in avanti e più in alto.
• Questo cambiava il centro di spinta e favoriva l’impennamento in certe manovre.

MCAS nacque per nascondere il difetto, rendendo il comportamento del MAX “simile” alle versioni precedenti.

Un software progettato per mascherare un cambiamento strutturale mettendo una toppa digitale a un compromesso meccanico.

III. Il bug tecnico: il sensore unico che comandava tutto

Il MCAS si basava su un solo sensore: l’Angle of Attack (AoA).
Se questo sensore forniva un valore errato — per guasto, ghiaccio, impatto con un volatile — il sistema concludeva che l’aereo stava entrando in stallo.

E reagiva drasticamente: spingere il muso verso il basso, in modo ripetuto e progressivo.

Perché un solo sensore?

Perché aggiungerne un secondo avrebbe comportato:

• più controlli,
• più integrazione,
• più addestramento,
• più costi.

Un singolo punto di fallimento venne accettato come rischio “calcolato”; ed il software, convinto di salvare l’aereo, lo trascinò invece verso il suolo.

IV. Il contesto: l’automazione che soppianta il pilota

Nelle intenzioni originali, il MCAS era quasi invisibile: il pilota non doveva saperne nulla, né notarne la presenza.

La filosofia era chiara: l’automazione decide, il comandante corregge solo se necessario.

Ma in volo reale:

• il sistema poteva attivarsi più volte,
• con una forza crescente,
• senza alcun allarme dedicato,
• senza che i piloti sapessero come disattivarlo rapidamente.

Boeing temeva che, informando i piloti dell’esistenza del MCAS, le autorità avrebbero richiesto ulteriori certificazioni.
Così ovviamente non solo lo nascose, ma ne minimizzò le conseguenze.

L’automazione diventò padrona e non l’assistente della situazione.

V. La scoperta: la ricostruzione post-mortem

Le scatole nere rivelarono la stessa dinamica in entrambi gli incidenti:

• angolo d’attacco falsamente altissimo,
• attivazione automatica del MCAS,
• abbassamento manuale del muso,
• nuova attivazione del MCAS,
• perdita di controllo.

Il software non era semplicemente “bucato”: obbediva perfettamente alle specifiche.

L’errore non era nel codice, ma nel contesto che lo circondava.
Un software progettato per essere “silenzioso” finì per diventare un attore fatale.

VI. Le implicazioni morali e legali

Il caso Boeing 737 MAX divenne uno spartiacque.
Emersero documenti interni dove ingegneri esprimevano dubbi, ignorati in nome della competitività contro Airbus.

Negli Stati Uniti, Boeing fu accusata di:

• occultamento di informazioni,
• pressioni regolatorie,
• difetti nella cultura interna di sicurezza.

Le famiglie delle vittime denunciarono un quadro impietoso che sottolineava un fallimento organizzativo sistemico e non un semplice errore.

Il MCAS non era un bug: era la manifestazione software di una catena di compromessi.

VII. I danni: non solo economici

I due incidenti causarono 346 vittime.
La flotta mondiale dei 737 MAX venne messa a terra per oltre 20 mesi.
Boeing perse decine di miliardi in:

• risarcimenti,
• cancellazioni di ordini,
• fiducia.

Ma il danno più grande fu simbolico: la credibilità del marchio Boeing, un tempo sinonimo di affidabilità assoluta, venne incrinata come mai nella sua storia.

VIII. Contromisure: riscrivere la cultura del volo

Dopo gli incidenti, vennero introdotte correzioni radicali:

Tecniche

• Uso di due sensori AoA con logica di confronto.
• Limitazione dell’autorità del MCAS.
• Maggiori controlli dei piloti.
• Nuovi alert obbligatori in cabina.

Organizzative

• Revisione dei processi FAA e Boeing.
• Maggior trasparenza sui sistemi automatizzati.
• Separazione più netta tra chi progetta e chi certifica.

Per la prima volta in decenni, gli algoritmi dei sistemi di volo finirono sotto scrutinio pubblico.

IX. Lezioni filosofiche: la fiducia cieca nell’automazione

Il caso 737 MAX non parla solo di software aeronautico.
Parla del nostro tempo, dominato da macchine sempre più autonome e invisibili.

Tre lezioni emergono:

1. La ridondanza è una virtù morale prima che tecnica.
2. Ogni algoritmo porta con sé una scelta politica: cosa privilegiare, cosa sacrificare.
3. Un errore di design può diventare errore epistemologico: confondere il modello (il sensore) con il reale (l’aereo).

Il MCAS credeva ai numeri perché era stato istruito a farlo.
Il mondo reale, però, non è sempre fedele ai suoi sensori.

X. Epilogo: archeologia di un sensore

Scavando nell’eredità del 737 MAX non troviamo solo un valore errato, o un algoritmo troppo aggressivo.
Troviamo la prova di una cultura industriale che voleva che il software fosse invisibile, e che l’automazione passasse inosservata agli occhi di piloti e regolatori.

Come nel caso Therac-25, come nell’Ariane 5, il vero errore non fu tecnico: fu la convinzione che il software potesse risolvere un problema strutturale senza lasciare cicatrici.

MCAS nacque per obbedire, non per ingannare.

XI. Coda: il ritorno dei sensori che mentono

Oggi viviamo in un mondo di dispositivi che leggono il mondo per noi: auto autonome, sistemi medici, algoritmi che pilotano droni, modelli di AI che prendono decisioni sulla base di segnali numerici.

E ogni volta che un sensore misura male, ogni volta che un algoritmo interpreta troppo, ritorna l’eco del 737 MAX.

“Un singolo bit può costare una vita.”
Ma il costo reale è sempre la fiducia che riponiamo nelle macchine che progettano al posto nostro.

Il limite non è la tecnologia: è nella cultura che la produce.

🧰 Bug Survival Kit – 737 MAX Edition

📚 Libri consigliati

• Normal Accidents — Charles Perrow (edizione inglese)
  → Sui sistemi complessi che falliscono in modi imprevedibili.
• La caffettiera del masochista, Il design degli oggetti quotidiani — Don Norman
  → Per capire come l’usabilità sia un atto etico.
• Flying Blind — Peter Robison (edizione inglese)
  → Una ricostruzione investigativa della crisi Boeing.

🔧 Strumenti utili

• DO-178C — standard per il software aeronautico critico.
• Fault Tree Analysis (FTA) — per analizzare rischi sistemici.
• NASA Human Factors Guidelines — per progettare automazioni che rispettino il pilota.