TYLER DURDEN
zerohedge.com
I seguenti tweet [formattati in testo continuo, NdT] di Trevor Sumner, Amministratore Delegato di Perch Experience, su quello che è realmente successo ai Boeing 737 Max, potrebbero essere uno dei migliori riassunti degli eventi che hanno portato ai due recenti incidenti aerei, e potrebbero anche chiarire perché la risposta di “software upgrade” di Boeing è una farsa.
La MIGLIORE analisi di ciò che sta realmente accadendo in merito al Boeing 737 Max è di mio cognato @davekammeyer, che è un pilota, un ingegnere informatico e anche un profondo pensatore. In conclusione, non incolpate il software che è solo il cerotto che copre le magagne di molte altre forze in azione di tipo ingegneristico ed economico.
Alcune persone hanno definito le tragedie dei 737 MAX un errore di software. Ecco la mia risposta: non è stato un problema di software. E’ stato un
* Problema economico. I motori 737 consumavano troppo carburante, perciò avevano deciso di installare motori più efficienti, con pale più grandi e di realizzare il 737 MAX.
* Problema strutturale. Volevano usare la cellula del 737 per motivi economici, ma, con motori più grandi, avevano bisogno di più altezza dal suolo. Il progetto del 737 non può essere, in pratica, modificato con l’allungamento del carrello principale di atterraggio. La soluzione era montare [i motori] più in alto e più in avanti.
* Problema aerodinamico. La struttura del velivolo, con i motori montati diversamente, non aveva una maneggevolezza sufficientemente affidabile ad angoli di attacco (AoA) elevati per essere certificabile. Boeing ha deciso di creare il sistema MCAS per correggere elettronicamente le carenze di manovrabilità dell’aeromobile.
Durante lo sviluppo del MCAS, c’era stato un:
* Problema di ingegneria dei sistemi. Boeing voleva la soluzione più semplice possibile che si adattasse all’architettura dei sistemi esistenti, che richiedesse la minima rieleborazione ingegneristica e il minimo addestramento per i piloti e gli addetti alla manutenzione.
Il modo più semplice per farlo era aggiungere alcune funzionalità al sistema già esistente, l’Elevator Feel Shift (EFS). Proprio come il sistema EFS, il MCAS si basa su sensori non ridondanti per decidere quanto trim da aggiungere. A differenza del sistema EFS, il MCAS è in grado di effettuare grosse modifiche al trim per abbassare il muso dell’aereo.
Su entrambi gli sfortunati voli, c’era un:
* Problema di sensore. La palettina che rileva l’angolo di attacco sul 737 MAX sembra non essere molto affidabile e ha dato letture errate. Sul volo LionAir, questo fatto era stato aggravato da un
* Problema delle pratiche di manutenzione. L’equipaggio precedente aveva riscontrato lo stesso problema e non aveva registrato l’inconveniente nel registro di manutenzione. Questo era stato a sua volta aggravato da un
* Problema di addestramento dei piloti. In LionAir, i piloti non erano mai stati nemmeno informati dell’esistenza del MCAS e, all’epoca del volo etiopico, era stato emesso un comunicato (AD) di emergenza, ma nessuno si era mai addestrato al simulatore di volo per far fronte a questa emergenza.
Tutto questo era stato poi aggravato da un
* Problema economico. Boeing vende un pacchetto aggiuntivo che include una palettina per l’angolo di attacco in più, e una spia di disaccordo [sulla lettura dell’AoA], che consente ai piloti di sapere che si sta verificando il problema. Entrambi i 737 MAX precipitati erano stati consegnati senza questa miglioria. Nessun 737 MAX con questo optional si è mai schiantato.
Tutto questo è stato aggravato da un
* Problema di esperienza del pilota. Se i piloti avessero correttamente e rapidamente identificato il problema ed avessero preso il controllo manuale del trim impazzito, non si sarebbero schiantati.
Qui non c’è un problema di software. I computer e il software hanno eseguito i loro compiti in base alle loro specifiche e senza errori. Solo che le specifiche erano di merda. Ora, il modo più veloce che ha Boeing per risolvere questo pasticcio è chiamare i ragazzi del software, in modo che tirino fuori un altro cerotto.
Sono un ingegnere informatico e talvolta veniamo chiamati a risolvere carenze meccaniche, elettriche o aerodinamiche, perché il metallo è già stato tagliato o gli stampi sono già stati realizzati o il chip è già uscito dalla fabbrica, quindi quel problema non può essere risolto.
Ma il software può sempre essere trasferito al server di aggiornamento o riflashato. Quando però la pezza del software si stacca in un vento da 500 nodi, è allettante dare la colpa solo al cerotto.
Tyler Durden
Fonte: zerohedge.com
Link: https://www.zerohedge.com/news/2019-03-17/best-analysis-what-really-happened-boeing-737-max-pilot-software-engineer
18.03.2019
