Il software del 737: quando un baco mette a rischio le vite
Quando ho cominciato a scrivere software, quasi 45 anni fa, esisteva il linguaggio macchina e poco di più: Fortran, Basic, Pascal, C. L’applicazione era abbastanza ristretta ad ambienti scientifici, didattici e commerciali. Tecnicamente parlando la distanza tra uomo e macchina era molto più ridotta allora e, per fare un esempio, i controlli fly-by-wire sugli aerei erano da pochi anni presenti su aerei commerciali e peraltro comunque ancora sotto il controllo totale dei piloti. Nel tempo ovviamente la tecnologia elettronica e l’informatica aviatoria (in breve: navionica), si sono evolute a grande velocità e nello stesso modo è cresciuta la fiducia in taali sistemi di controllo da parte degli esseri umani.
Ad oggi non esiste un aereo che non sia controllato da software, ovviamente dedicato, in quasi ogni funzione. La crescita della potenza di calcolo e la riduzione concomitante di spazi, peso e volumi degli elaboratori ha portato ad una sempre maggiore distanza tra uomo e macchina, qualcosa di indubbiamente utile e prezioso, senza cui oggi molti aerei farebbero davvero fatica a volare.
Ma… anche per la tecnologia esistono sempre due facce della stessa medaglia, come di hanno dimostrato le recenti, multiple disgrazie occorse ai velivoli precipitati a causa di un difetto di progettazione del software, i Boeing 737.
La causa, ormai credo ampiamente assodata di questi incidenti è in un software che prende il controllo dell’aereo, in particolare per gestire velocità e angolo di attacco, due informazioni che provengono da altrettanti sensori e che sono vitali per mantenere un aereo in volo.
In parole semplici, un aereo vola grazie alla cosiddetta “portanza”, ovvero alla differenza tra le pressioni dell’aria sopra e sotto l’ala. Quando la pressione sulla superficie inferiore è maggiore di quella sulla superficie superiore e la differenza tra le due è sufficiente a compensare il peso dell’aereo, ecco che questo “decolla”. Senza scendere troppo in particolari di cui non sono particolarmente ferrato, diciamo che maggiore è la velocità di un aereo, maggiore è la portanza. La velocità di cui parliamo però non è strettamente riferita al suolo, quanto a quella relativa nell’aria. Quindi, come sa chiunque abbia fatto volare un aquilone, con un vento contrario alla direzione di moto, è sufficiente una velocità relativa al suolo inferiore, in quanto il vento che si muove contro l’aereo va a sommare la propria velocità a quella dell’aereo che si muove appunto in direzione contraria. Per questo motivo (e per tanti altri), molto spesso è sufficiente una velocità inferiore a quella nominale per consentire un decollo o un volo.
L’altra grandezza che entra in azione è proprio l’angolo di attacco, ovvero l’angolo con cui il velivolo affronta la sua “salita” nell’aria, una dimensione che va ad influenzare fortemente la portanza, determinando un diverso flusso di aria intorno alle superfici alari.
Il software che ha causato gli incidenti sui 737 pare avesse un serio problema di calcolo proprio nel considerare il vento relativo e la velocità rispetto al suolo, calcolando in modo erroneo la velocità minima di sostentamento proprio perchè non teneva in adeguata considerazione la velocità del vento rispetto all’aereo. Sulla base di questi calcoli errati il software sarebbe intervenuto sull’angolo di attacco in modo totalmente incontrollabile dai piloti, cosa che ha determinato lo schianto dell’aereo.
Un errore di progettazione del software anche marchiano se vogliamo, ma che non sapremo mai da cosa sia stato davvero causato, se da una incompetenza nel campo degli analisti che hanno redatto le specifiche o se da un’errata scrittura da parte dei programmatori. Fatto sta che, qualora fosse davvero quello ipotizzato il problema, non si tratterebbe di un errore da poco, e comunque totalmente umano.
Perchè ricordiamoci che, per quanto complesso, il software viene sempre scritto da esseri umani. Ma se a fallire è quello di un telefono, al massimo potremo non riuscire a comunicare in determinate occasioni. Quando a fallire è invece un sistema di controllo del volo purtroppo, come si è visto, la gente muore.
Con il crescere della penetrazione del software all’interno delle attività umane, cresce obbligatoriamente la responsabilità di chi lo scrive e progetta, così come cresce la possibilità di interazioni sconosciute tra software magari prodotti da società diverse.
Molti anni fa, per fare un esempio, nell’epoca dello “scudo stellare” fortemente voluto dall’amministrazione americana, uno dei primi esperimenti per verificare se un raggio laser di sufficiente potenza poteva essere usato per intercettare un missile balistico, accadde un episodio al limite dell’assurdo che fortunatamente non ebbe conseguenze, se non coprire di ridicolo la squadra ce se n’era occupata. L’esperimento infatti consisteva nel colpire con un laser proiettato da terra (a sostanzialmente bassa potenza, appunto per evitare pericoli) uno specchio posto su uno shuttle in orbita. In breve, l’esperimento fallì miseramente e il laser non si avvicinò neppure al bersaglio. Nell’analizzare i motivi per cui ciò fosse accaduto, si venne a scoprire che il software di controllo era stata sviluppato da Esercito e Marina, che si erano occupati di due aspetti diversi della progettazione. Orbene, il problema, facilmente individuato con poche analisi, era che la parte sviluppata dall’Esercito “ragionava” in miglia terrestri, mentre quella sviluppata dalla Marina ragionava in miglia appunto marine… se si considera che un miglio terrestre corrisponde a circa 1610 metri mentre quello marino a 1852 metri, il motivo del fallimento risulta immediatamente chiaro.
Un errore ancora sciocco, se visto a posteriori ma concettualmente simile a quello del sistema di controllo dei 737: in entrambi i casi è stato dato per scontato qualcosa che non lo è affatto.
In buona sostanza: questione di consapevolezza.