Sì, finalmente, in un’intervista fatta in un ambito apparentemente lontano da quello tecnico (si tratta di una MasterClass per il mondo Luxuryorganizzata da Matteo Rivolta di RiFRA, cucine da sogno), sono riuscito forse per la prima volta a fare capire a un pubblico non necessariamente “tecnico” qual è la mia vera missione, personale in primis e aziendale di conseguenza:
insegnare alle aziende come fare a proteggere il proprio Brand, la propria Reputazione dai potenziali, catastrofici danni tecnici, economici e di immagine provocati da un’introduzione non correttamente pianificata e gestita del Software Embedded
soprattutto laddove per motivi storici sia presente una forte cultura e competenza in ambito elettro-meccanico, ma manchi o sia in formazione lo sviluppo di codice.
Si tratta prima di tutto di un CAMBIAMENTO CULTURALE: ci sono grossi cambiamenti da attuare non soltanto a livello di tecnologia, di tool, ma soprattuto di cultura aziendale, di processi, di persone.
Chi è Matteo Rivolta e cos’è RiFRA
Matteo Rivolta è conosciuto come un imprenditore ed innovatore del suo settore colui che ha internazionalizzato Rifra, inizialmente nata da Giovanni Rivolta, artigiano brianzolo che avviò nel 1930 la sua prima bottega a Macherio.
Le sue cucine sono state definite come “le più belle al mondo”…
Cosa c’entra tutto questo con il Software?
Devi guardare l’intervista per scoprirlo… ma vedrai che il Lusso e la Reputazione sono intimamente legate, così come il Software potrebbe dare danni ingenti alla tua azienda.
Come faccio ad ascoltare l’intervista?
Clicca qui sotto ed ascolta la mia intervista insieme a Laura Spinelli, presentatrice di “Storie di Imprenditori”, in cui discutiamo della necessità di produrre Software di Qualità e del perchè il Brand deve seguire tutto il processo di sviluppo.
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
A questa fondamentale (e direi UNICA!) conferenza per tutti coloro che utilizzano il prestigioso e robusto linguaggio ADA, parteciperanno tutti i maggiori esperti al mondo di Software Quality & Reliable Software Technologies.
Perché devi assolutamente partecipare a questa conferenza
Ancora una volta, perchè si tratta
dello stato dell’arte del Linguaggio Ada e Reliable Software, dove i massimi esperti parleranno delle più recenti Tecniche, dei Toolpiù moderni, dei Metodi più sicuri
4 giorni di eventi virtuali, dove partecipare senza muoverti da casa: come ti dicevo per l’altra conferenza, quando ti ricapita un’opportunità del genere?
Oltre a me ci saranno esperti universitari, ricercatori e altre aziende che utilizzano il linguaggio Ada e in generale tecnologie per il Reliable Software Tutte aziendi appartenenti a settori Automotive, Medicale, Industriale, Elettronico.
Il mio intervento, su: Software Testing: Manual or Automatic activity? 6 keys to higher Quality Software sarà:
Giovedì 10 Giugno – ore 13:45
Mi ripeto: è una bella occasione, non te la perdere!
Come posso avere maggiori informazioni e soprattutto ISCRIVERMI?
Per avere l’agenda completa, informazioni dettagliate su come iscriversi, vai direttamente su questa pagina:
quest’anno sono onorato di essere stato invitato come speaker alla prestigiosa conferenza “Virtual Software Testing Symposium” organizzata da Vector Informatik, azienda con cui collaboro da oltre 10 anni. A questa speciale giornata parteciperanno tutti i maggiori esperti al mondo di Software Quality, Continuous Integration & Development, AGILE, DevOps e tanti altri argomenti correlati.
Perché devi assolutamente partecipare a questa conferenza
Semplicemente, perchè si tratta
dello stato dell’arte del Software Testing, dove i massimi esperti parleranno delle più recenti Tecniche, dei Toolpiù moderni, dei Metodi più sicuri
per migliorare la Qualità del Software, la Sicurezza dei prodotti che vendi e diminuire i Tempi e i Costi. Tutto insieme, nella stessa giornata, senza muoverti da casa: quando ti ricapita un’opportunità del genere?
Oltre a me e agli altri esperti colleghi di Vector Informatik, parteciperanno come oratori anche nostri clienti e partner di aziende al top come: GS Lab, Schneider Electric, Roche Diabetes Care, Nippon Seiki, Innovative Vehicle Institute, INFINEON, NVIDIA appartenenti a settori Automotive, Medicale, Industriale, Elettronico. Mi ripeto: è una bella occasione, non te la perdere!
Quali argomenti verranno trattati
Ecco quali sono i temi della giornata: – Unit, Integration, System Test – Prevenzione ed Identificazione dei Bug – AGILE, DevOps ed altre metodologie – Continuous Development, Integration & Testing – Architettura, Modellazione, Simulazione & Testing – Certificazione Functional Safety IEC-61508, DO-178C, ISO-26262, ASPICE
Come posso ricevere l’agenda dettagliata e soprattutto ISCRIVERMI?
Per avere l’agenda completa, informazioni dettagliate su come iscriversi e il mio REPORT speciale sull’Automazione del TEST Software vai su questa pagina:
in questi lunghi anni di lavoro nel campo del Software, per applicazioni critiche o meno, mi sono spesso scontrato con una realtà molto semplice anche se disarmante:
certi manager o imprenditori, erano talmente in alto mare nel processo di Sviluppo Software, da essere scoraggiati dal fare anche solo un minimo cambiamento.
Esatto: arrugginiti oramai da anni di cattive abitudini, di fretta di andare sul mercato, di fasi importanti es. di test saltate, di pressioni dai manager o dai clienti, da ritenere oramai di fatto impossibile adottare un Processo di Sviluppo Software di Qualità, per via dei troppi cambiamenti da affrontare.
Bisogna però darsi un punto di partenza, il primo cambiamento: da che cosa si può iniziare a cambiare in meglio?
LA PRIMA MOSSA DA FARE NEL 2021?
Ho parlato in questi anni con decine di clienti, ho sentito gli sfoghi anche recenti di manager e imprenditori: ho ri-analizzato tutta la catena di procedure e attività del M.E.D.S. (Method for Efficient Development of Software) e degli altri standard di qualità e certificazione come il DO-178C, ISO-26262, IEC-61508 ecc. e ho identificato quella che secondo me è la radice di tutto, il singolo cambiamento che si porta dietro tutto il resto, il primo passo verso il cambiamento:
Quando uno ha i Requisiti ben fatti, scritti con formalità e in maniera ingegnerizzata, poi si portano dietro tutto il resto, come per magia. E’ il primo passo: ma diventa poi una reazione a catena che rende molto più lineare e ingegnerizzato tutto il resto.
Se tu pensi invece ancora di poter fare senza…
SENZA UN “REQUISITO PERFETTO”?
Senza dei requisiti ben fatti, non funziona più niente, non ha mai funzionato né mai funzionerà nulla.
SENZA REQUISITI PERFETTI:
NON riesci a MODELLARE e SIMULARE precocemente
NON riesci a SVILUPPARE correttamente
NON riesci a TESTARE su tutto il Ciclo di Vita
NON riesci a soddisfare il M.E.D.S. (Method for Efficient Development of Software)
NON riesci a fare AGILE, LEAN DEVELOPMENT
NON riesci a SODDISFARE IL CLIENTI
NON riesci a CERTIFICARE SAFETY-CRITICAL come DO-178C, ISO-26262, IEC-61508 ect
Per questo motivo, ho pensato di creare un vero e proprio corso su misura, dedicato solo ai Requisiti. E da quest’anno, l’ho ancora migliorato: ecco il corso REQUISITO PERFETTO ADVANCED.
REQUISITO PERFETTO ADVANCED
Non perdere tempo, vai a vedere subito questa pagina, dove troverai:
Ognuno di noi ha un Maestro, un “guru”, una persona che nella vita ci ha dato tanto, tantissimo in termini di cultura, di passione, di conoscenza: per me è senza dubbio Vance Hilderman, ora CTO e fondatore di AFuzion, ma in passato mio collega in Artisan Software e poi in Vector Software.
Vance è unico: con il suo approccio umile, cortese e sempre allegro, ha la proprietà magica di rendere comprensibile a chiunque una materia complessa, ostica e delicata come la Certificazione Avionica Safety-Critical: invece di annoiarsi, nelle sue lezioni non solo si impara ma si ride, ci si diverte con i suoi esempi e storie di vita reale, si fanno quiz. E le ore e i giorni di formazione volano: gli studenti (manager, dirigenti, imprenditori) da tutto il mondo sono contenti e hanno imparato di più da lui in poche ore che in anni di esperienza.
In questa intervista, Anna Chiara Cesari e Massimo Bombino di Software Sicuro provano a farsi raccontare da Vance alcuni momenti fondamentali:
– cosa sta succedendo nel mondo, in questo periodo così critico per via del COVID
– cosa stanno facendo le aziende per tutelarsi e reagire
– come la transizione “Dall’acciaio al bit”, dai dispositivi elettromeccanici al firmware, può essere gestita e dominata
– come la Certificazione può aiutare le aziende a raggiungere mercati più ampi
– cosa possono fare le aziende per poter ripartire di slancio appena possibile
Ecco l’intervista
In questo video, Vance ci parla soprattutto della MasterClass di (NON) Programmazione C/C++ Embedded & Realtime, un prestigioso corso di studi in 12 lezioni online, che è perfetto in questo periodo per aumentare le competenze del proprio team aziendale in termini di Progettazione Firmware Embedded e livellare verso l’alto le capacità degli sviluppatori, analisti e tester.
Grazie ai suoi prestigiosi docenti:
Massimo Bombino – CEO & Founder di Software Sicuro, una delle maggiori autorità a livello italiano di Sviluppo Software Embedded & Safety-Critical
Vance Hilderman – CTO di AFuzion, esperto di Certificazione Avionica e di Safety-Critical, con esperienza a livello mondiale
Niroshan Rajadurai – VP di GitHub, guru nel campo degli RTOS (Real-Time Operating Systems), Security, Continuous Integration
Roberto Bagnara – CEO di BUGSENG, membro del MISRA e maggior esperto di Analisi Statica in Italia
Maurizio Menegotto – CEO di Lauterbach Italia, autorità nel campo del Debugging, Emulazione Hardware
e agli argomenti trattati, questa MasterClassè la scelta strategica giusta e il miglior investimento che tu possa fare in questo periodo.
Ecco qua dove potrai trovare maggiori informazioni:
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.
Se passi davanti a un negozio IKEA, ti potrà capitare di trovare questo strano dispositivo.
È una scatola di plexiglas trasparente, contenente una poltrona IKEA, uno strano braccio robotico con due grandi pistoni che spingono la sedia e un contatore. È una specie di esperimento di simulazione di una persona di 80 kg. seduto e in piedi, ripetuto per migliaia e migliaia di volte.
Probabilmente hai guardato il bancone, hai visto un numero come 999.999-1.000.000- … e hai fatto un po’ di matematica mentale…
“Probabilmente io e la mia famiglia potremmo sederci e alzarci in media 10 volte al giorno, 3.650 totali all’anno … quindi questa sedia durerà almeno 300 anni “
E con la giusta fiducia nella sua robustezza, hai deciso di comprarla.
Ora pensiamo a un software critico per la sicurezza: ti potrebbe essere richiesto di certificare secondo il severo standard DO-178C, fino al livello A. Bene, guardando questa o altre normative di sicurezza correlate, potresti trovare che associato al livello A, hai una probabilità di errore 10E-9 ore di volo. Ok, ancora matematica… significa:
1 miliardo di ore senza problemi, o meglio 115.740 anni
Centoquindicimila anni! Sembra abbastanza buono, non è vero? Tranne il fatto che… per il software, in realtà non funziona così. Cosa significa veramente DAL-A? Letteralmente, significa Design Assurance Level: garanzia del DESIGN.
Ma la vera probabilità di un guasto del software è molto più alta … alcuni esperti dicono che la probabilità è 1 ovvero il 100%! Potresti essere abbastanza sicuro che il tuo software fallirà! Pensa al tuo sistema operativo desktop o mobile … puoi immaginare un’app per il tuo smartphone o computer che resista migliaia di anni senza crash o bug?
E pensi che il software avionico possa essere reso così solido per millenni? Possa davvero essere rilasciato fin dall’inizio totalmente senza bug?
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 ilM.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:
Se ci sei passato, saprai benissimo che la Certificazione Avionica Safety-Critical del Software ha una brutta fama… quella di letteralmente un bagno di sangue.
Sono tantissime le cose che devi fare di più rispetto a un normale progetto… vediamo alcune tanto per intenderci:
Avere un processo formale, rigido e ben definito
Rispettare formalmente tutte le fasi del ciclo di vita e le transizioni fra di esse
Soddisfare tutti gli obiettivi richiesti tramite attività, documenti, evidenze, checklist
Dotarsi dei migliori strumenti nonché di fornitori o sub-contractor adeguati
In poche parole… questo vuol dire solamente tre cose:
SOLDI, SOLDI e ancora SOLDI
E ovviamente tempi molto più lunghi, ritardi che si dilatano in maniera esponenziale così come i rischi di insuccesso e via discorrendo.
Esiste una via più rapida ed efficiente alla Certificazione Avionica?
E’ possibile riuscire ad essere più efficienti , senza sacrificare nessuno degli obiettivi Safety-Critical? Si possono accorciare i tempi, senza scordare nessuno degli obblighi dati dagli standard? Come si possono contenere i costi e rimanere compliant? Come ci può aiutare in tutto questo il M.E.D.S. (Method for Efficient Development of Software)?
Ne parlerò a Monaco, alla conferenza Aerospace Testing Europe durante la Aerospace Tech Week:
Come ogni anno, sono invitato a presentare delle soluzioni più efficienti per la Certificazione Avionica (e di conseguenza tutte le altre), quest’anno mi concentrerò su un compito apparentemente “impossibile”: dimostrare proprio come la Metodologia AGILE, che in teoria mal si presta al mondo “sicuro”, in realtà se ben usata può aiutare le aziende come la tua a vincere la sfida col Software Certificato, aiutandoti a essere più snello e rapido senza nessun sacrificio sulla Safety.
In poche parole, come il M.E.D.S. riesce a mettere insieme il Safety- e il Business-Critical.
Scopri la mia “sfida” impossibile partecipando alla mia presentazione a Monaco il 7 Marzo alle 14!
