L’INCIDENTE DELLA FUNIVIA DI STRESA

E di come la sicurezza deve passare attraverso processi precisi e invalicabili

L’incredulità, gli occhi sbarrati di fronte alle prime notizie.
I brividi veri, quelli che ti scuotono fin dentro le ossa, quando ti rendi conto che potrebbe non essere stata una tragedia imprevedibile, ma c’è il tragico sospetto che sia stata frutto di decisioni od omissioni umane. 

Ero indeciso se scrivere queste parole. 

Non sono un esperto di funivie, non voglio sputare sentenze già troppo proclamate da ogni dove. 

Non voglio condannare e puntare il dito, non spetta a me. 

Vorrei solo analizzare le possibili soluzioni in termini di procedure.

Non quelle “a caldo”. Quelle saranno una danza di controlli a tappeto. 

Abbiamo oltre 1477 impianti a fune in Italia.

In quanti altri luoghi potrebbe ancora accadere?


Quanti altri boati immensi e innaturali potrebbero interrompere la quiete di quei paesi? 

Si susseguiranno verifiche, analisi, manutenzioni straordinarie. 

Se qualcun altro (e mi auguro proprio di no) aveva avuto la malaugurata idea di omettere dei controlli di sicurezza del genere, si sarà spaventato a morte pensando alle ben più gravi conseguenza a cui sarebbe andato incontro. 

Quindi, come ti dicevo, non importa molto la soluzione “a caldo”, ma quella a freddo, quando si saranno calmate le acque. 

Quando il boato assordante avrà finito di riecheggiare nelle nostre orecchie e ci sarà un altro problema all’ordine del giorno. 

Le soluzioni a lungo termine: quelle che davvero possono evitare le disgrazie

Facciamo una piccola premessa. 

Com’è fatta una funivia?


La faccio semplice, semplicissima, senza usare termini eccessivamente tecnici.
C’è un cavo grande come un braccio, il cavo PORTANTE.

Quello non si romperà “mai”, perché è progettato per resistere a forze molto superiori e viene controllato periodicamente. 

Quel cavo rimane fisso, con la funivia letteralmente appesa. 

E infatti non si è rotto quello. 

Poi ci sono i cavi TRAENTI

Sono quelli più sottili che si vedono di fianco. Tirano su e giù la funivia, attaccati ai motori veri e propri. Se quei cavi si rompono è un potenziale pericolo, perché la funivia potrebbe cominciare a scorrere sul cavo portante (ed è quello che è presumibilmente è successo a Stresa). 

Per evitare questo scenario c’è il FRENO

Ganasce che si agganciano con forza al cavo traente quando la funivia è ferma alle stazioni e che vengono rilasciate quando si deve muovere. 

Freno che in caso di pericolo diventa protagonista. 

In caso di brusche accelerazioni, calo di tensione, interruzione della corrente elettrica, guasti… diventa un FRENO DI EMERGENZA che blocca immediatamente la cabina, scongiurando la tragedia. 

Durante le operazioni di manutenzione però il freno potrebbe dare fastidio. Per questo c’è una FORCHETTA che tiene aperte le ganasce. 

SOLO CON LE CABINE VUOTE
SOLO PER IL TEMPO NECESSARIO per fare i controlli.

Solo-con-le-cabine-vuote.

Queste cinque parole mi rimbombano in testa e sono come cinque pugni in faccia. Fanno un male cane. 

A Stresa questa forchetta si sospetta che sia stata lasciata inserita, tenendo aperte le ganasce e impedendo il funzionamento del freno di emergenza, per evitare lavori di manutenzione e tenere fermo l’impianto.
Se questo è vero, da chi è stato fatto e perché, lo determineranno le doverose e minuziose indagini, ma per quello che ho da dire io in questo momento, è sufficiente questa ipotesi.  

Però… non è questo TUTTO il problema, c’è dell’altro. 

Poi, sembra sempre al momento come ipotesi credibile, che la reale causa scatenante è stata la rottura del cavo traente (che andrà comunque indagata perché un cavo non si deve rompere così), ma da sola non avrebbe causato nulla se non l’intervento del freno di emergenza. 

Ed è peggio. 

IL VERO PROBLEMA: la soluzione “a freddo”

Prima di tutto, sarà che sono abituato a pensar male per via del mio lavoro, ma la vera domanda che si fa anche un non addetto ai lavori è:

Quante altre funivie, in Italia e nel Mondo, hanno funzionato per anni con la “forchetta” inserita? 

Quante altre stragi sono state evitate per miracolo? 

E quante altre stragi potrebbero accadere se non si fa nulla? 


Questi pensieri, come ti dicevo, porteranno ad una soluzione “a caldo” che tappezzerà di controlli e verifiche la maggior parte degli impianti e che “metterà la strizza” a chi poteva avere avuto la stessa idea di queste persone.

Ma purtroppo queste sono le classiche lacrime del coccodrillo.

Quel sentimento forte, pesante come un macigno, che porta a voler spaccare tutto e agire immediatamente per impedire che una cosa così orribile possa ricapitare. 

Poi però passa il tempo, quel tempo che ha il potere di sfumare i contorni, di lenire le ferite. Quel tempo che ti permette di sopravvivere. 

Purtroppo è lo stesso tempo che permette che queste disgrazie ricapitino. Magari non nello stesso modo. 

Ma permettere che ricapitino. 

E chiunque abbia un’attività, un’azienda ha il dovere, verso se stesso prima di tutto, e poi verso i suoi dipendenti e clienti, di fare il possibile per limitare le probabilità che accadano questi errori.


PREVENIRE QUESTI ERRORI NEL FUTURO

L’errore umano può capitare. 

Gli esseri umani prima o poi sbagliano, questo è scontato nell’ambito della Safety: ci sono tabelle per ogni attività umana di un pilota, macchinista, che prevedono esattamente ogni quante ore una persona ignorerà un cicalino, una spia rossa, un allarme. 

È matematico, probabilistico: anche involontariamente, un uomo sbaglia. 

Il problema è quando non si tratta di errore ma di scelta consapevole

In questo caso sembra che non ci sia una soluzione. 

C’è lo sdegno, la vergogna, la difficoltà nel capire le dinamiche che hanno spinto ad un gesto così irresponsabile. 

Ma non è vero che non esiste una soluzione. 

Ce ne sono addirittura due. 



LA SOLUZIONE TECNOLOGICA 

In termini tecnici, una funivia dove è installata questa “FORCHETTA” è un 

sistema DEGRADATO

le sue funzionalità di sicurezza non sono presenti o comunque non sono garantite a livello di efficacia, per cui il sistema è pericoloso.
Siccome in caso di una funivia si tratta ancora di sistemi elettromeccanici, viene considerata un “Sistema Semplice”, per il quale si può raggiungere quella che è chiamata Sicurezza di Prodotto o PRODUCT ASSURANCE

Tramite analisi, progettazioni, simulazioni si riesce a rendere il sistema, se non matematicamente, almeno probabilisticamente sicuro. 

Gli incidenti nei sistemi elettromeccanici sono molto rari e il più delle volte causati dagli errori umani di cui abbiamo parlato. 

Posso immaginare quindi che la prima soluzione sarà di tipo tecnologico e meccanico. 

Verrà proprio impedito l’utilizzo di questa famigerata “FORCHETTA”, oppure verrà trovato un altro sistema per far viaggiare la funivia solo con cabine vuote in caso di manutenzione

Oppure dovrà essere modificato il sistema di blocco delle ganasce: facendo come succede in ambito avionico o in altri sistemi, quando questa forchetta è inserita (SE verrà mantenuta nella forma attuale), ci dovrà essere un segnale sonoro, visivo, meccanico che lo evidenzi in maniera inequivocabile, a prova di incapace. 

Hai presente le famose strisce rosse “REMOVE BEFORE FLIGHT” appese fuori da un aereo prima del decollo, da rimuovere appunto prima del volo?

Ecco, quello è il concetto. 

Potrebbe esserci un suono forte e inequivocabile causato dalla presenza della forchetta, oppure andrà fissata ad un grosso cartello o un altro dispositivo rosso, ingombrante e impossibile da ignorare. 

Ci potrebbe essere un sistema di blocco delle porte per evitare che salgano passeggeri. 

In poche parole: 


il sistema degradato deve essere segnalato o reso impossibile da usare, volenti o nolenti

LA SOLUZIONE SOFTWARE

Nel mondo dei sistemi basati su Firmware o Software Embedded, sempre più presenti nelle nostre vite, questo non basta!

Nel campo del codice, che oramai pervade ogni ambito, compreso quello delle funivie immagino così come tutti i sistemi elettromeccanici, purtroppo questo non è sufficiente. La soluzione del “Remove before flight” non è applicabile agli infiniti guasti che possono capitare a un’applicazione con una componente informatica. 

È complessa e con troppi livelli di profondità.
 

Milioni e milioni di righe di codice. 

Applicazioni e programmi che interagiscono tra loro. 

Le variabili da controllare sarebbero quasi infinite e questo le rende davvero difficili da gestire e dominare. 

Ancora peggio se, come purtroppo nel caso della funivia, si travalica il confine dell’errore umano. 

E si precipita nell’inferno della scelta consapevole. 

Tutto si può manomettere se c’è il dolo, l’intenzione pianificata di compiere un gesto preciso. 

Aspetta. So cosa stai pensando. 

Mi hai fatto leggere tutto questo articolo, arrivare fin qua… per dirmi che non esiste una soluzione efficace??” 

La soluzione esiste, non preoccuparti.



LA SICUREZZA DI PROCESSO 

Dopo le soluzioni “a caldo” di cui abbiamo parlato, pian piano si tornerà alla normalità. 

Ma per non rendere inutile tutto questo dolore bisognerebbe intervenire in maniera definitiva, agendo sul PROCESSO

Una cosa del genere non deve accadere perché a bloccarla ci devono essere una serie di impedimenti, diciamo burocratici per intenderci, per evitare che si ripeta in futuro. 

Più il sistema è complesso, più è all’avanguardia e implica quindi la presenza di un software, più la probabilità dell’errore diventa una scheggia impazzita e incontrollabile. 

I sistemi e le procedure che la gestiscono non possono essere gli stessi che a fatica tengono a bada i sistemi elettromeccanici. 

Per questo motivo, bisogna passare dal concetto di Sicurezza di Prodotto a quello di Sicurezza di Processo, in inglese PROCESS ASSURANCE.

 I concetti di base sono pochi e fondamentali: 

1) Controlli incrociati

La regola è molto semplice: uno fa, un altro controlla. 

Il famoso concetto che quattro occhi vedono meglio di due

Con un continuo controllo incrociato, in cui tutti hanno le stesse responsabilità, le probabilità di errore e di sabotaggio, si riducono notevolmente. 

In ambito avionico, si fa da sempre così ed è anche per quello che ci sono due piloti: per controllarsi a vicenda. 

2) Checklist

Ognuno di noi ha la sua esperienza, le sue conoscenze, le sue idee. 

Come si fanno i controlli, cosa si controlla e in quale ordine? 

Ognuno di noi farebbe controlli diversi. 

Da qui nasce la necessità di un deus ex machina che porti alla soluzione predefinita e ottimale. 

Per cui ecco le checklist: liste di controlli da fare e da spuntare, precise, ingegnerizzate, uguali per tutti, in tutto il mondo. 

A prova di errore, a prova di distrazione e stress, a prova di imbecille. L’unico modo per essere sicuri che i controlli vengano fatti, sempre nello stesso modo, da chiunque. 

Rimanendo sempre nell’ambito delle strette procedure che regolamentano gli strumenti degli aerei, ci sono checklist ben precise da seguire per ogni fase del volo (e prima di iniziare il volo). Ci sono lunghe check-list (così lunghe da essere veri e propri quaderni) solo per le operazioni anormali, ovvero come gestire situazioni di emergenza. 

È tutto prestabilito e ben poco è lasciato alla volontà del pilota. 

3) Verifiche indipendenti

L’ultimo passaggio è quello di Enti di Verifica esterni, autonomi, che facciano controlli casuali, a campione, improvvisi. 

Controlli non solo e non tanto tecnici, ma appunto di processo
Verifiche che siano state seguite le procedure, documentate le ispezioni, utilizzate le checklist, svolte le verifiche incrociate, firmati i verbali.

LA PROCESS ASSURANCE APPLICATA AL SOFTWARE

Questa strada ci rende più confidenti anche per il SOFTWARE, visto che tutte queste tecniche sono esattamente quelle che si usano per tutto quello che riguarda il SAFETY-CRITICAL (quindi come in questi casi dove è a rischio la vita delle persone), così come nei sistemi BUSINESS-CRITICAL dove i guasti possono provocare rallentamenti, disagi, perdita di dati ed economiche ma non mettono a rischio altri esseri umani.

Aumenteranno i controlli periodici, le ispezioni di organi ed enti indipendenti, le verifiche incrociate di personale esterno, gli organi di controllo, i bollini, i sigilli, le procedure ecc. rendendo di fatto molto difficile che si ripetano avvenimenti del genere. 

Questa è la vera, unica strada che l’aumento della complessità dei sistemi, soprattutto quelli moderni basati sul Software rende necessario: non è più sufficiente la striscia rossa “REMOVE BEFORE FLIGHT“, bisogna accompagnare la inesorabile conversione dei sistemi elettromeccanici in sistemi automatizzati e robotizzati, pieni di software.

Anche nella tua attività, nella tua azienda, puoi proteggerti da danni sia di business che di sicurezza. 

I secondi sono terribili e ti distruggono anche a livello personale e umano. 

Ma i primi non sono meno importanti.
Se il tuo prodotto o servizio viene bloccato da un problema al software come lo risolvi?

Non si tratta della vite o del pezzo di macchinario che puoi trovare e sostituire.
Il software è impalpabile, sfugge dal tuo controllo ed è molto complesso riconoscere e risolvere una sua anomalia.

Può causarti un danno d’immagine.
Può bloccare per giorni la tua produzione con danni economici che ti lascio solo immaginare…

Ma la strada del software può essere regolamentata e resa sicura, con processi determinati e precisi.

Quella che io chiamo la strada “dall’acciaio al bit“, tramite la lunga, faticosa PROCESS ASSURANCE

Prima di arrivare alla tanto chiacchierata ma ancora lontana Intelligenza Artificiale, Robot ecc., un sano e robusto processo, dei controlli periodici rigorosi, degli audit indipendenti e improvvisi sono e saranno per lungo tempo gli unici rimedi per evitare guai di questo genere, e questo vale per qualunque sistema o dispositivo, sia basato sul vecchio “acciaio”, che quelli nuovi e moderni oramai pieni di linee di codice Software. 

Per il disastro di Stresa io, come anche tu, non posso fare nulla. 

Possiamo però fare qualcosa per la tua attività, per prevenire qualsiasi tipo, più o meno grave, di incidente di percorso.

[VIDEO] 5° Comandamento: NON UCCIDERE (col software)

Lo dice anche la “Bibbia” DO-178, nel suo Quinto comandamento… 

il software non deve uccidere nessuno!


 
In questa breve presentazione, che ho tenuto all’Istituto Aeronautico Vinci di Gallarate, ho voluto spiegare ai giovani studenti e futuri piloti o controllori di volo alcuni dei concetti di base che stanno dietro la produzione e la certificazione del Software Aeronautico attraverso la rigida Certificazione Safety-Critical.

E per fare questo passo attraverso l’analisi dell’incidente dei due Boeing 737 Max in Indonesia e in Etiopia perché presentano degli aspetti molto interessanti per chiunque abbia a che fare con la produzione di software di qualunque tipo, anche se non critico.

Perché ti dovrebbe interessare anche se non fai Software Critico?

Infatti, se guardi il video, scoprirai che in realtà i veri motivi dell’incidente… non hanno a che fare con problematiche di tipo tecnico o non sono dovute a errori di piloti ma

sono errori gravi di progettazione, formazione e di tempistiche di ingresso nel mercato che potrebbe compiere qualunque azienda, anche la tua.

https://youtu.be/xS1tJ4-v594

Guardati il video e poi fammi sapere cosa ne pensi… e lascia un commento!

Nel mio canale YouTube trovi altri video!
Software Sicuro Channel

Scrivici per ogni tuo dubbio, curiosità e perplessità:
assistenza@softwaresicuro.it

Un software da 500 milioni di dollari?

No, il titolo non è una provocazione ma un caso reale che ti spiegherò fra poco: tu pagheresti 


un aggiornamento software 500 milioni di dollari?

 
E che cosa dovrebbe mai combinare di buono (o di cattivo!) la nuova versione di un applicativo per costare così tanto?  Ma soprattutto, come si è arrivati in soli 30 minuti a un disastro del genere in un’azienda americana, Knight Capital, che è stata sull’orlo della bancarotta per questo motivo ed è stata costretta a reperire in poche ore ingenti risorse economiche, licenziare alcuni dipendenti e vendere degli edifici di proprietà a causa di questo tracollo finanziario provocato da un software?

Read More

Christine, la macchina (a guida autonoma) infernale

Come forse avrai letto, a Marzo 2018 un’auto a guida autonoma di Uber ha investito una donna di 49 anni in Arizona, uccidendola


Esatto: come nei migliori (e peggiori) film di fantascienza se non horror, una macchina dotata di intelligenza artificiale apparentemente è impazzita e ha ucciso un essere umano, uno dei peggiori incubi dell’evoluzione tecnologica dell’uomo. La cosa come immagini ha creato grande scalpore e polemiche, provocando la sospensione di qualunque test su strada. 


In questo articolo, cerco di spiegarti in maniera semplice cosa è successo, di chi è precisamente la colpa (e non è quello che raccontano i giornali, neanche la stampa specializzata!), qual è l’errore di fondo e cosa c’entra un vecchio col cappello. 


Capirai perché tutto questo ha a che fare con i progetti software, con il gioco del poker e soprattutto comprenderai che, molto probabilmente, c’entri anche tu. Sì, proprio TU.


Ma andiamo con ordine. 

Read More

Incidenti aerei del Boeing 737 MAX: le vere cause segrete

“A fool with a tool, is a more powerfool fool”

Oramai è sulla bocca di tutti: un secondo aereo 737 MAX della Boeing è caduto nel giro di pochi mesi in Etiopia, pochi mesi dopo quello di fine 2018 in Indonesia. A questo si è aggiunto poi un mancato incidente sullo stesso identico aereo etiope, il giorno prima, che è stato evitato per puro caso dall’intervento di pilota a riposo che si trovava per caso nello stesso aereo e che è corso in cabina per evitare una tragedia, fornendo una delle chiavi di volta per comprendere meglio le due tragedie.

Non è mia abitudine commentare incidenti appena avvenuti, perché le indagini per stabilirne le vere cause possono durare anche mesi: ma questa volta forse forse si sa già chi potrebbe essere il colpevole: infatti, in tutti gli incidenti sia quelli realmente accaduti che in quello mancato, si è evidenziato come i piloti stessero combattendo invano contro i sistemi a bordo del loro stesso aereo:  precisamente, lottavano contro un sistema “demoniaco” di stabilizzazione chiamato M.C.A.S., basato su un software di correzione delle manovre potenzialmente pericolose che paradossalmente ha contribuito a creare i presupposti delle due tragedie.

Bene, abbiamo finalmente il responsabile?

Il software ha veramente ammazzato centinaia di persone?

Gli aerei non sono più sicuri?

Forse, ma la realtà invece è molto diversa da quella che appare in prima istanza. E la lezione imparata oggi, può essere utile anche a te e alla tua azienda…

Seguimi in queste considerazioni in cui cercherò di non scendere troppo nel tecnico e vedrai che questa analisi ti sarà molto utile, qualunque tipo di software tu stia producendo.

Cosa è successo?

Allora, al di là del motivo originario per cui sia successo un fenomeno del genere, appare evidente dalle scatole nere e dall’episodio dell’incidente mancato che l’aereo sembrava essere completamente impazzito: dai cambi di quota repentini, dalle manovre effettuate dai piloti, dalle loro voci registrate nel cockpit sembrava proprio che l’avionica di bordo avesse deciso di puntare l’aereo con decisione verso terra, quasi a scansare un imminente pericolo.

Il problema è che questo pericolo non c’era e che puntare verso terra subito dopo il decollo, ancora a bassa quota e bassa velocità, è molto intuitivamente una cosa molto pericolosa… e se fatta in maniera repentina e più volte, può provocare una tale instabilità e perdita di quota da provocare i disastri poi avvenuti.

Ma perché quindi questo tipo specifico di aereo ogni tanto (troppo spesso!) impazzisce, fa quello che vuole, punta il muso verso terra ammazzando tutti? E perché i piloti sono impotenti in tutto questo?

Soprattutto: è vero che non potevano fare nulla per evitare il disastro? Qui ci sono molti, molti dubbi…

Aereo o bus?

Parte tutto da una famosa diatriba ben nota tra addetti ai lavori o appassionati di aerei: Boeing o Airbus?

Il motivo del contendere è un oggetto ben preciso: UN JOYSTICK.

Esatto: gli Airbus da molti anni non si guidano più con la classica cloche a due mani che tutti conoscono, ma con un joystick identico a quello dei videogiochi. Quando è stato introdotto il concetto di Fly-by-Wire, il controllo degli elementi di comando di un aereo tramite sistemi elettronico e non più solamente meccanico-idraulici, è stato un salto quantico, nella sensazione di guida di un aereo e nell’avionica in generale, con un sacco di critici e un crescente numero di appassionati, le cui opinioni ovviamente si ribaltano radicalmente nel momento in cui si parla del Boeing che invece ha una cloche di guida più tradizionale:

Ma anche l’avionica di un Airbus è molto diversa: per non farla troppo lunga e tecnica, esiste una cosa in tutti gli aerei chiamata “INVILUPPO”, che rappresenta una specie di cuscinetto di sicurezza intorno alla posizione dell’aereo, una zona di prudenza in cui il velivolo deve sempre trovarsi per essere in una condizione stabile senza rischi. Un insieme di dati complessi di velocità, inclinazione, accelerazione con dei limiti che non devono mai essere oltrepassati per non mettere in pericolo l’aereo stesso e il suo equipaggio.

Ecco, la grande differenza tra i due colossi dell’aria è che negli Airbus, l’avionica di bordo esercita un controllo molto forte  per assicurare che l’aereo si trovi sempre correttamente all’interno dell’inviluppo e che soprattutto evitare che il pilota faccia mai, neanche volontariamente, delle azioni o delle manovre pericolose, a meno di disabilitare volontariamente alcune funzionalità del cosiddetto “pilota automatico”.

Di fatto, l’aereo guida quasi sempre da solo, scegliendo in ogni condizione la manovra migliore per evitare (in teoria) qualunque tipo di problema. Questo fatto, secondo alcuni, rende i piloti di Airbus così abituati all’aereo che manovri quasi sempre da solo ed eviti autonomamente qualunque rischio, da diventare pigri e disimparare come si guida veramente un velivolo manualmente, tanto da essere chiamati “bus drivers”, guidatori di (Air)bus.

Un pilota Boeing invece, con la cloche tradizionale, prima di tutto ha una sensazione tattile e visiva di quello che sta facendo lui e il co-pilota, visto che le cloche si muovono insieme. Ma soprattutto, anche se alcuni sistemi elettronici di ausilio alla guida sono stati introdotti pure in questi aerei, può escludere istantaneamente il pilota automatico con una semplice pressione sui comandi più decisa del solito, e riprendere totale controllo dell’aereo. Questo significa ovviamente esserne anche capaci e infatti i piloti di Boeing normalmente vengono ritenuti più abili proprio a guidare l’aereo in maniera manuale e a “sentirne” il comportamento, visto che lo praticano molto più spesso, piuttosto che fidarsi e lasciarlo pilotare da solo.

In prima istanza, estremizzando verrebbe da dire che gli Airbus sono più sicuri perché automatici e i Boeing invece necessitano di piloti migliori… in maniera MOLTO superficiale, potremmo per un momento anche dire così.

Ok, ma… non è successo ESATTAMENTE il contrario? Non è stato un aereo Boeing a cadere e per colpa di un sistema automatico? Quindi il contrario di quello che uno si sarebbe aspettato, no?

Beh, ma è PROPRIO quello il problema…

Cos’è il M.C.A.S. e perché non è ancora il vero colpevole

Allora, il nuovo Boeing 737 MAX, come suggerisce il nome stesso, era la versione più grande dello stesso modello di aereo di grande successo e dalla grandissima affidabilità, dotato anche di più potenti.

Il problema è che la potenza dei motori, la loro posizione, i cambiamenti introdotti potevano creare delle situazioni di pericolo, di uscita dal famoso “inviluppo”, in particolari condizioni di volo a bassa velocità e angoli di volo elevati che potevano portare ad uno stallo del velivolo. Per evitare questo grave tipo di pericolo, la Boeing ha avuto la grandissima pensata (!!!) di introdurre un sistema anti-stallo elettronico chiamato M.C.A.S. (Maneuvering Characteristics Augmentation System), molto simile a quelli presenti negli aerei Airbus.

Lo scopo era preciso e anche lodevole, anche se diabolico nella sua attuazione: far volare senza pericolo il nuovo MAX ai piloti già addestrati con il vecchio 737 NG.

Sembra tutto ok, no? Un sistema per rendere i nuovi velivoli più sicuri… andando un po’ a inseguire Airbus nell’automatizzare i sistemi di volo e a ridurre il carico di lavoro e la richiesta di maggior abilità dei piloti.

Allora è vero che il software ha fallito? No: sono stati dei sensori.

La colpa è dei sensori… anzi no

Per funzionare, questo sistema M.C.A.S. ha bisogno, tra gli altri dati, dell’Angolo di Attacco (AoA) forniti da alcuni sensori… che detta in maniera molto semplice indicano l’inclinazione dell’aereo. Bene, sono stati questi dispositivi ad avere avuto un malfunzionamento e ad aver dato indicazioni del tutto errate che hanno fatto impazzire l’autopilota.

In poche parole, i sensori segnalavano che l’aereo si era impennato in maniera pericolosa… e cercavano di ributtare giù il muso. Peccato che non fosse vero, l’aereo stava volando dritto… e come in un vero incubo, il software di bordo continuava a far perdere quota all’aereo nonostante i ripetuti interventi del pilota per rialzarlo.

Vi immaginate che incubo? Siete alla guida di un aereo pieno di passeggeri che impazzisce e vuole precipitare verso terra… voi provate a raddrizzarlo per decine e decine di volte ma niente, punta inesorabile verso la morte.

Finalmente: colpa dei sensori? E no, c’è un motivo per il crash… e ancora una volta non sarà quello definitivo.

Un problema di soldi (o di progetto)

Questo sistema M.C.A.S.aveva in realtà a sua volta un meccanismo di diagnosi interna di tutte le sue componenti, inclusi questi sensori di angolo di attacco, chiamato DLC. Una volta che questo sistema avesse segnalato un problema, i piloti sapevano (in teoria…) che avrebbero dovuto disinserirlo (attenzione che torneremo su questo punto) e tornare a guidare in maniera manuale, come erano stati addestrati a fare.

Peccato che questo dispositivo fosse… opzionale e costoso, per cui alcune compagnie aeree più “povere”, non l’hanno acquistato. E guarda caso, sia gli aerei della flotta Indonesiana che di quella Etiope non erano dotati di questo sistema di diagnosi e di allarme, per cui i piloti si sono trovati in balia di un aereo che faceva di testa sua, inventandosi una situazione di pericolo che non c’era e anzi andandola a creare. Tutto questo per una questione di soldi.

Certo uno potrebbe dire: ma cavoli, in un sistema così delicato e potenzialmente salva-vita, non dovrebbe essere integrato di default un sistema di auto-diagnosi che vada a verificare che tutto funzioni correttamente, dai sensori agli attuatori, dai computer al display?

Per cui anche il costruttore ha le sue colpe… avrebbe dovuto rendere il nuovo sistema di guida automatico sicuro in tutte le situazioni, anche in quelle di guasto.

Facciamo il punto della situazione prima di annunciare chi è… il “maggiordomo”, il colpevole vero di questi tristissimi incidenti.

La catena di eventi scatenanti

Quindi, abbiamo questa catena di eventi che sembra piuttosto chiara:

  • l’aereo 737 MAX è più grande e monta motori più veloci di quelli precedenti
  • essendo più potente, potrebbe creare situazioni in cui l’impennata del muso provocherebbe situazioni di grave instabilità di volo (stallo)
  • per evitare questo problema ed evitare stress (e nuovo addestramento) ai piloti, è stato introdotto un sistema anti-stallo chiamato M.C.A.S.
  • i sensori dell’Angolo di Attacco (A.o.A.) erano guasti e fornendo informazioni inventate, facevano intervenire a sproposito il M.C.A.S. facendo precipitare l’aereo nonostante le correzioni disperate dei piloti
  • esisteva un sistema di diagnostica di tali sensori che avrebbe avvertito i piloti di disinserire il M.C.A.S.  ma le compagnie aeree indonesiani ed etiope non l’hanno comprato perché troppo caro

Sembra tutto chiaro, ma io come in un giallo ho disseminato degli indizi per il colpevole finale, quello vero.

Infatti, se sei stato attento, ti sarà venuta in mente la domanda fatidica:

Perché i piloti non hanno disinserito il M.C.A.S.?

Eh già, questa è la VERA domanda. Quella fatidica.

La possibilità di disinserire quella trappola mortale c’era, ma i piloti non l’hanno utilizzata nei due voli fatidici. Mentre nel volo etiope del giorno precedente, un pilota a riposo tra i passeggeri ha capito cosa stava succedendo e si è precipitato in cabina per salvare piloti, aereo e passeggeri. Un eroe? No: semplicemente UN PILOTA INFORMATO E ADDESTRATO.

Infatti, i piloti di entrambi gli aerei precipitati, così come molti altri piloti Boeing in giro per il mondo, avevano uno o più di questi gravi problemi di addestramento:

  • NON SAPEVANO CHE ERA STATO INTRODOTTO IL M.C.A.S.
  • NON SAPEVANO COME FUNZIONAVA E QUANDO SCATTAVA
  • NON NE CONOSCEVANO LE REAZIONI ANOMALE IN CASO DI GUASTO
  • NON SAPEVANO NEANCHE COME DISINSERIRLO!!

Vabbè, dirai, cose da PAZZI!! Sembra una follia totale, un film horror, sapere che banalizzando,

bastava schiacciare un bottone, premere un pulsante per disinserire il software mortale M.C.A.S.

Brivido di terrore.

E veniamo all’ultimissima domanda: perché i piloti non sono stati addestrati??

La fretta di arrivare sul mercato

Esatto: è presto per la conferma definitiva, ma sembra che il mancato o scarso addestramento sia stata una strategia precisa per far diventare velocemente operativi i nuovi piloti sul mercato.

Infatti, alcune voci di CBS News raccontano che

ai piloti sono stati fatti soltanto 56 minuti di formazione su un iPAD per il nuovo 737 MAX

Allucinante.

Hanno preso un aereo sicuro, storicamente affidabile, dei piloti bravi e competenti, che sapevano pilotare in condizioni anche rischiose in modalità manuale… e gli hanno infilato dentro un nuovo sistema, un software, un “tool” che doveva rendere la loro vita più facile, ma li ha ammazzati perché non ne sapevano niente. Roba che mi provoca i brividi freddi solo a pensarci.

Ancora una volta, così come per il sistema di diagnosi DLC non acquistato, per risparmiare i costi… i tempi… per comprimere il famigerato TTM (Time to Market), il vero killer di queste due tragedie.

E tu? Lo sai benissimo, se hai letto altri articoli miei, che ti tirerò in mezzo con una bella “lezione” su quanto appreso oggi da applicare alla tua azienda.

La (mancanza di) cultura uccide

Pensaci un attimo, quante volte nella tua azienda, nel tuo team per problemi di budget e/o di tempo:

  • hai introdotto dei cambiamenti in azienda senza informare tutti?
  • hai acquistato un tool senza comprare il corso adeguato?
  • hai cambiato delle procedure senza informare e formare tutte le persone coinvolte?
  • hai magari migliorato dei processi ma senza coinvolgere chi ne era affetto?

Ecco: tutte queste volte, tu hai potenzialmente corso il rischio di:

  • di AMMAZZARE I TUOI CLIENTI, se il tuo software è SAFETY-CRITICAL
  • di FAR FALLIRE I TUOI CLIENTI (E TU CON LORO), se il tuo sistema è BUSINESS-CRITICAL

Conclusioni

Ti è piaciuto questo articolo? Scopri la mia newsletter gratuita dove periodicamente troverai:

  • analisi dettagliate di incidenti critici (apparentemente) causati dal software
  • strategie ottimali per produrre software Safety- e Business-Critical
  • consigli su come adottare delle tecniche sicure ed efficaci nei tuoi progetti

Lascia la tua email per avere immediatamente accesso alla mia newsletter:

5° Comandamento Software: NON UCCIDERE

Il software è uno dei prodotti più complessi mai prodotti dall’uomo, senza paragoni. Non esiste prodotto letterario, programma scientifico, opera architettonica che possa eguagliare il numero di ore/uomo o anni/uomo necessari a produrre un software di grande complessità come quello che equipaggia un moderno aereo, un’automobile di ultima generazione, il computer o smartphone che state utilizzando, un social come Facebook.

Ed il software è talmente complesso che spesso sbaglia… anzi, uccide.

 

Il software uccide le persone, brucia capitali enormi, fa saltare in aria le aziende, crea irreparabili danni di immagine

 

Nel 1982, si sospetta che la CIA abbia volutamente introdotto un bug (errore software) all’interno del codice di controllo della condotta di gas transiberiana in Russia. Per motivi di contro-spionaggio, gli USA hanno deciso di far esplodere tale condotta una volta operativa con il risultato di provocare la più grande esplosione non-nucleare della storia.

Read More

La tua azienda sta producendo pessimo software, bruciando prezioso budget in una spirale che presto ti manderà gambe all’aria. Te ne sei già accorto? E cosa stai facendo per evitarlo?
Tech Nerd theme designed by Siteturner