737 MAX 8 Ethiopian si schianta subito dopo il decollo da Addis Abeba


Dico la mia.

Sabato 9 marzo sera c'era un volo ET che imbarcava di fianco al mio. Guardo i passeggeri con curiosità e nostalgia, pensando ai vari voli fatti con ET, ad Addis e ad altri ricordi etiopici. Una decina di ore più tardi, collegandomi per curiosità ad internet mentre ancora in volo, leggo la notizia e non posso non pensare che forse qualcuna delle persone che mi erano vicine potevano essere in coincidenza su NBO. (Ed infatti credo proprio lo fossero, viste le nazionalità delle vittime.)

Ovviamente succede a tutti di essere sfiorati da queste situazioni nella vita. Abbiamo letto la ben più significativa esperienza di Londonfog con la tragedia di Lockerbie. E comunque, quando succede, lascia un segno.

Io voglio solo dire che, per motivi miei, sono particolarmente colpito dalla vicenda. E nonostante questo, ci terrei a sottolineare una cosa. La Boeing ci ha regalato aeroplani magnifici che hanno scritto la storia dell'aviazione e che hanno dato benefici enormi alla mobilità a lungo raggio. Io posso solo immaginare il livello di stress ed il desiderio di venire a capo di questa vicenda da parte di chi ci è coinvolto direttamente, per non parlare dei dubbi e dei rimorsi. Ecco, invece delle speculazioni e dei pettegolezzi su cause, effetti, responsabilità, mi piacerebbe sentire un incoraggiamento ai lavoratori Boeing: sappiamo che state lavorando per farci viaggiare sempre più in sicurezza e che costruire aerei è una sfida meravigliosa e talvolta tragica; abbiamo fiducia che ci darete delle risposte e delle certezze come avete sempre fatto finora, come fanno tutti quelli che lavorano nel settore con professionalità, onestà e dedizione.

E adesso vi saluto e vado ad imbarcarmi.
Beh, da un punto di vista umano credo che i professionisti di Boeing siano i primi ad essere molto provati. Dopo la nota sulle prime indagini che avrebbe sottolineato la correlazione con l'incidente Lion Air a maggior ragione. E' assolutamente umano logorarsi chiedendosi cosa si poteva fare in più, perché non ci si è posti un dubbio in più, non si è fatto un test in più ecc... E sarà durissima ripartire per i singoli (sicuramente saranno supportati personalmente al meglio), a livello tecnico Boeing ha tutte le capacità per venire a capo del problema.

Dal punto di vista esterno le indagini faranno il loro corso, Boeing si prenderà una bella bastonata più o meno pesante in base a cosa emergerà in concreto ma alla fine verrà voltata la pagina e si andrà avanti.
 
Prenderanno una bastonata, ma magari riceveranno un aiuto per stare in piedi, magari negoziato in cambio di un aiuto ad Airbus per la restituzione dei prestiti per l'A380 la cui produzione verra' chiusa.

Su cosa potevano fare di diverso l'articolo del Seattle Times e' pieno di suggerimenti. Ditemi se ho capito bene, come al solito da strainesperto da correggere:

- usare entrambi i sensori di angolo di attacco per avere ridondanza
- calibrarli e testarli automaticamente quando si e' a terra (l'aereo Lion Air era rotto gia' prima, solo che l'equipaggio del volo prima l'ha sfangata)
- modificare il sofware in modo che non si comporti in modo incrementale ad ogni correzione del pilota, che gestisca meglio le situazioni anomale e sia piu' affidabile
- e soprattutto, anche se non dover ricertificare i piloti per il nuovo mezzo sarabbe tanto attraente per le compagnie, dirgli che la bestia che hanno sotto e' diversa e insegnargli bene ad usarlo

Poi piu' sul lungo termine ci auguriamo che il prossimo workhorse narrow body, destinato ad essere venduto in migliaia di esemplari, e su cui ciascuno di noi volera' ennemila volte lo progettino da scratch con i requisiti e materiale e del 21esimo secolo in modo che vada dritto ove possibile intrinsecamente invece di adattare ancora la famiglia 737 aggiungendo elettronica per correggerne l'assetto.
 
In un’azienda come la Boeing (ma vale per tutte le aziende) ci sono progettisti, tecnici e operai che per dovere o per passione costruiscono aeroplani, e poi ci sono gli amministratori, che sempre per dovere o per passione guardano ai soldi. Servono entrambi in un’azienda, nel senso che un’azienda con ottimi progettisti e pessimi amministratori non sta in piedi, e lo stesso per un’azienda con ottimi amministratori e pessimi progettisti/tecnici. Ma l’equilibrio tra le due parti è sempre sottile e delicato.
 
E', come al solito, presto per saltare a conclusioni.

Ma, se dovessero veramente finire come sembra finire, ossia con due aerei perduti a causa dello stesso problema, il vero peccato originale per Boeing, secondo me, e' quello di aver portato all'estremo - e oltre - il modello 737. A un aereo figlio degli anni '60, un aereo costruito per motori con un diametro di 1.25 metri (tale era il fan del JT8D) e' stato infilato un motore, il LEAP, con fan di diametro doppio, 2.5 metri. E per fare questo s'e' dovuto spostare i motori, alzarli, complicare l'aerodinamica e creare software troppo complicati. E ancora non stiamo vedendo il 737-10MAX, che a quella bastardizzazione aggiunge quella della fusoliera extra-long e limitazioni all'angolo di decollo... Se veramente si arrivera' a decidere che, si, l'MCAS ha causato la perdita di entrambi i Lion Air e Ethiopian, a Boeing le mazzate dovrebbero arrivare per non aver deciso che era il momento di fare cio' che non hanno fatto in quasi 40 anni, ossia progettare un nuovo narrowbody.
 
E', come al solito, presto per saltare a conclusioni.

Ma, se dovessero veramente finire come sembra finire, ossia con due aerei perduti a causa dello stesso problema, il vero peccato originale per Boeing, secondo me, e' quello di aver portato all'estremo - e oltre - il modello 737. A un aereo figlio degli anni '60, un aereo costruito per motori con un diametro di 1.25 metri (tale era il fan del JT8D) e' stato infilato un motore, il LEAP, con fan di diametro doppio, 2.5 metri. E per fare questo s'e' dovuto spostare i motori, alzarli, complicare l'aerodinamica e creare software troppo complicati. E ancora non stiamo vedendo il 737-10MAX, che a quella bastardizzazione aggiunge quella della fusoliera extra-long e limitazioni all'angolo di decollo... Se veramente si arrivera' a decidere che, si, l'MCAS ha causato la perdita di entrambi i Lion Air e Ethiopian, a Boeing le mazzate dovrebbero arrivare per non aver deciso che era il momento di fare cio' che non hanno fatto in quasi 40 anni, ossia progettare un nuovo narrowbody.

È che se avessero fatto come dici tu, avrebbero perso quei 4/5000 ordini, spalmati in 5 anni e più, che sarebbero andati dritti dritti a Tolosa, A220 compreso.
 
È che se avessero fatto come dici tu, avrebbero perso quei 4/5000 ordini, spalmati in 5 anni e più, che sarebbero andati dritti dritti a Tolosa, A220 compreso.

Non sono d'accordo. Se avessero iniziato il design di un nuovo aereo per tempo (diciamo in un qualsiasi anno tra il lancio del 737NG ad oggi) avrebbero avuto un anti-NEO in tempo utile. Inoltre nulla impediva a Boeing di comprare il programma CS, prevenendo la mossa di Airbus. Ma la decisione e' stata quella di risparmiare soldi creando un aereo, come si sta scoprendo ora, con difetti seri.
 
Ad ogni modo, a me fa molta più paura e mi sembra molto meno rispondente alla sicurezza areonautica, il fatto che Boeing annunci una nuova release a breve (del tipo “ci siamo quasi, massimo 10 giorni ed è pronta”), con il fiato sul collo di vari soggetti e l’opinione pubblica mondiale che sta a guardare, per far ripartire la giostra quanto prima.

Non sono un informatico, ma ho la sensazione che sia il peggior modo di operare per ritoccare/riscrivere un software.

Ciao.
Io di professione sono un Analista Programmatore.
Tento di dare una mia personale risposta, limitatamente al mio campo d'azione, per così dire...

Un modo giusto, unico, oppure standard, oppure anche "globale" per fixare un programma, sfortunatamente non esiste.

Io non lavoro per una grande azienda, il nostro software può vantare, per così dire, circa 700 installazioni.
A volte capita che, facendo uscire una nuova release del programma, si ricevano poi in assistenza una serie di richieste legate direttamente proprio all'ultimo rilascio.
Allora, per chi non è del mestiere, potrebbe giustamente venire da pensare: ma cavolo!??!!? ma voi le cose prima di rilasciarle, non le provate?
Posso assicurare che noi le cose le proviamo, eccome se lo facciamo!

Però ed è la cosa più difficile per tutti da capire, noi compresi, è che nel nostro mondo esiste una lotta perenne fra algoritmi e dati.
Lo stesso programma, identico alla virgola, può generare un errore da un cliente e non generare il medesimo errore da nessun'altra parte...

Come si può spiegare questa cosa?
In 2 modi:
1) uno o più algoritmi sono errati, ma non in assoluto, sono errati quando entrano in contatto con alcuni dati; i programmatori, i tester e tutta la filiera di rilascio non sono mai incappati e nemmeno hanno mai avuto idea del fatto che potessero esistere delle simili condizioni.
2) tutti gli algoritmi sono corretti, anche in assoluto (posso accettare questa condizione), ma uno o più di loro fallisce in modo catastrofico entrando in contatto con dati errati. Questo perchè la produzione del dato non è sempre necessariamente opera del programma che poi lo va a gestire; a volte i dati sono prodotti da strumenti/elementi esterni. Pur avendo precise specifiche ed ovviamente avendole testate tutte, quando si va in produzione, accade a volte che al programma arrivi roba strana, malformata e/o lacunosa.

Un esempio reale: lo scorso giovedì ho installato una nuova release da un mio cliente.
Dalla versione 2019.01++ è passato alla versione 2019.01+++ (poca roba di differente, davvero poca).
Venerdì mattina il cliente segnala un problema.
L'errore è in un punto del programma che è sotto test da 6 mesi ed è già stato dichiarato stabile e può passare in produzione.
L'ultima release da me installata, lo giuro, non ha subito alcun genere di modifica; il codice sorgente è lo stesso, identico alla virgola, rispetto alla release precedente!

Perchè è andato in errore allora?

Un altro fornitore, il quale fornisce il dato su cui il nostro programma poi agisce, ha modificato qualcosa.
A noi non era stato detto e comunque, a posteriori, anche se ci avessero comunicato la modifica, l'avremmo approvata serenamente perchè era poco più di una banalità.

Questa banalità ha mandato tutto in crash... dopo 6 mesi di test e collaudi... un errore catastrofico e sistemico...

L'altro fornitore in alcuni casi anzichè inviare valori coerenti, invia dei valori nulli (e questo fatto per noi è fuori specifica).
Lui non sa di inviare valori null fuori specifica ma di fatto questa cosa accade!
Noi non sappiamo di ricevere valori null, perchè essendo fuori specifica ed avendo impostato sia il DB che il nostro SW in modo tale che questa condizione non si crei, non siamo in alcun modo ricettivi in tal senso.
Ma il valore null viene prodotto e viaggia inosservato per tutto il canale di comunicazione ed arriva a destinazione senza colpo ferire.
Il risultato finale è un crash totale di quella parte di programma.

E la risoluzione di tutto questo non è immediata.
A volte ci vuole tempo solo per capire cosa succede.
Una volta capito questo, serve altro tempo per capirne il perchè, ovvero la causa scatenante; in particolar modo quando il dato errato non è sempre, tutte le volte, errato!
Poi ci vuole tempo per studiare la strategia d'azione.
Altro tempo per creare la correzione, FACENDO ENORME ATTENZIONE A NON PRODURRE DELLE REGRESSION !!! Ovvero a non creare un qualcosa che corregge questo problema ma che poi va a scassare qualcos'altro da qualche altra parte = ciò che prima funzionava bene e che funzionava bene anche in caso di errore, con la correzione deve continuare a funzionare !!!
Infine serve altro tempo per mettersi lì a testare, ritestare, collaudare e ricollaudare lo specifico problema in primis ed il generale infine.

Non oso nemmeno pensare a cosa voglia dire fare tutto ciò in materia di Aviazione Civile...

SE è davvero un problema software del MCAS che ha causato ben 2 incidenti fatali, allora non mi meraviglio affatto che la soluzione software al problema si faccia attendere.

Anche perchè coi dati di quest'ultimo incidente dovranno come minimo ripartire dall'analisi iniziale del problema e verificare se ciò che hanno scoperto finora, incrociato coi nuovi dati, regge e garantisce di aver trovato il vero perchè del problema, oppure solo di una sua parte...

Tutto nella mia umilissima e minima esperienza.
 
https://www.seattletimes.com/busine...-max-system-implicated-in-the-lion-air-crash/

Alcuni passaggi interessanti, l'articolo è lungo, ma vale la pena di essere letto

As Boeing hustled in 2015 to catch up to Airbus and certify its new 737 MAX, Federal Aviation Administration (FAA) managers pushed the agency’s safety engineers to delegate safety assessments to Boeing itself, and to speedily approve the resulting analysis.
But the original safety analysis that Boeing delivered to the FAA for a new flight control system on the MAX — a report used to certify the plane as safe to fly — had several crucial flaws.

Boeing engineers authorized to work on behalf of the FAA developed the System Safety Analysis for MCAS, a document which in turn was shared with foreign air-safety regulators in Europe, Canada and elsewhere in the world.
The document, “developed to ensure the safe operation of the 737 MAX,” concluded that the system complied with all applicable FAA regulations.

The FAA, citing lack of funding and resources, has over the years delegated increasing authority to Boeing to take on more of the work of certifying the safety of its own airplanes.
Early on in certification of the 737 MAX, the FAA safety engineering team divided up the technical assessments that would be delegated to Boeing versus those they considered more critical and would be retained within the FAA.
But several FAA technical experts said in interviews that as certification proceeded, managers prodded them to speed the process. Development of the MAX was lagging nine months behind the rival Airbus A320neo. Time was of the essence for Boeing.

The original Boeing document provided to the FAA included a description specifying a limit to how much the system could move the horizontal tail — a limit of 0.6 degrees, out of a physical maximum of just less than 5 degrees of nose-down movement.
That limit was later increased after flight tests showed that a more powerful movement of the tail was required to avert a high-speed stall, when the plane is in danger of losing lift and spiraling down.

After the Lion Air Flight 610 crash, Boeing for the first time provided to airlines details about MCAS. Boeing’s bulletin to the airlines stated that the limit of MCAS’s command was 2.5 degrees.That number was new to FAA engineers who had seen 0.6 degrees in the safety assessment.
“The FAA believed the airplane was designed to the 0.6 limit, and that’s what the foreign regulatory authorities thought, too,” said an FAA engineer. “It makes a difference in your assessment of the hazard involved.”

The bottom line of Boeing’s System Safety Analysis with regard to MCAS was that, in normal flight, an activation of MCAS to the maximum assumed authority of 0.6 degrees was classified as only a “major failure,” meaning that it could cause physical distress to people on the plane, but not death.

But when the consequences are assessed to be more severe, with a “hazardous failure” requirement demanding a more stringent probability of one in 10 million, then a system typically must have at least two separate input channels in case one goes wrong.Boeing’s System Safety Analysis assessment that the MCAS failure would be “hazardous” troubles former flight controls engineer Lemme because the system is triggered by the reading from a single angle-of-attack sensor.
“A hazardous failure mode depending on a single sensor, I don’t think passes muster,” said Lemme.

Boeing has pointed out that the pilots flying the same plane on the day before the crash experienced similar behavior to Flight 610 and did exactly that: They threw the stabilizer cutoff switches, regained control and continued with the rest of the flight.
However, pilots and aviation experts say that what happened on the Lion Air flight doesn’t look like a standard stabilizer runaway, because that is defined as continuous uncommanded movement of the tail.
On the accident flight, the tail movement wasn’t continuous; the pilots were able to counter the nose-down movement multiple times.

That stance allowed the new jet to earn a common “type rating” with existing 737 models, allowing airlines to minimize training of pilots moving to the MAX.Dennis Tajer, a spokesman for the Allied Pilots Association at American Airlines, said his training on moving from the old 737 NG model cockpit to the new 737 MAX consisted of little more than a one-hour session on an iPad, with no simulator training.
Minimizing MAX pilot transition training was an important cost saving for Boeing’s airline customers, a key selling point for the jet, which has racked up more than 5,000 orders.
 
Ciao.
Io di professione sono un Analista Programmatore.
Tento di dare una mia personale risposta, limitatamente al mio campo d'azione, per così dire...

Un modo giusto, unico, oppure standard, oppure anche "globale" per fixare un programma, sfortunatamente non esiste.


Posso assicurare che noi le cose le proviamo, eccome se lo facciamo!

Però ed è la cosa più difficile per tutti da capire, noi compresi, è che nel nostro mondo esiste una lotta perenne fra algoritmi e dati.
Lo stesso programma, identico alla virgola, può generare un errore da un cliente e non generare il medesimo errore da nessun'altra parte...

Come si può spiegare questa cosa?
.


Quì non si tratta di errore nel SW.
Non c'è nessun errore. Il sistema ha funzionato correttamente per come è stato progettato.
Non è una questione di qualcosa di imprevisto che ha mandato in tilt il sistema, non è un problema di SW corrotto, non si tratta di "bug".
Questi sitemi devono gestire pochi dati e in base a delle caratteristiche predefinite calcolare una risposta, non sono sistemi con infinite variabili.
Se un semplice tecnico come me è in grado di capire che il sistema è lacunoso e poco ridondante per come è stato ideato progettato e per come è stato realizzato, sicuramente ne erano consapevoli ingegneri e tecnici sia del progettista sia della AA che avrebbe dovuto verificare.
L'unica spiegazione, escludendo che ci sia stata una epidemia di cretinismo dovuta alle scie chimiche, è che la sicurezza sia stata messa nel cassetto e l'unico altro elemento (il profitto, la competizione, il raggiungimento dell'obiettivo) sia stato il fine ultimo che ha portato a questi risultati.
Purtroppo ho avuto modo in passato di avere a che fare con alcuni di questi "giovani" rampanti pseudo manager il cui unico credo era appunto raggiungere l'obiettivo. E non parlo di fare le cose nei tempi previsti, no questo era solo il mezzo per il vero obiettivo (il loro, la carriera, il soddisfare il loro ego) fregandosene di procedure, sicurezza, norme.
In uno scenario più grande e complesso che vede un colosso globale come Boeing uno stato come gli USA e una AA come FAA che è sempre stata il riferimento mondiale per normative e rgolamentazioni, non è troppo complottistico pensare che "la parte politica" abbia preso il sopravvento sulla parte tecnica.
E se tanto mi da tanto, alla luce di questo cosa pensare di altri prodotti di questo costruttore e forse anche di altri?
Un esempio, passato in sordina perchè fortunatamente non ha creato "danni"
http://avherald.com/h?article=4c2fe53a&opt=0
Tutto bene quì?
In dettaglio quì potrebbe entrare in gioco un piccolo sistema che in caso un motore resti alla max thrust con manetta al minimo, il motore venga automaticamente spento. (TCMA Thrust Control Malfunction Accommodation.) Immaginiamo uno scenario simile anzichè in atterraggio come è accaduto, avvenga oltre la V1.
Sto seguendo questa vicenda, con tutte le difficoltà del caso a reperire info. Nella speranza che una analisi dell'accaduto qualcuno la stia facendo e pubblichi risultati.
Nel frattempo, anche questa macchina rientra all'interno delle mie personali prescrizioni di aeronavigabilità. Con questa io non volo.
 
Ultima modifica:
Quì non si tratta di errore nel SW.
Non c'è nessun errore. Il sistema ha funzionato correttamente per come è stato progettato.
Non è una questione di qualcosa di imprevisto che ha mandato in tilt il sistema, non è un problema di SW corrotto, non si tratta di "bug".
Questi sitemi devono gestire pochi dati e in base a delle caratteristiche predefinite calcolare una risposta, non sono sistemi con infinite variabili.
Se un semplice tecnico come me è in grado di capire che il sistema è lacunoso e poco ridondante per come è stato ideato progettato e per come è stato realizzato, sicuramente ne erano consapevoli ingegneri e tecnici sia del progettista sia della AA che avrebbe dovuto verificare.
L'unica spiegazione, escludendo che ci sia stata una epidemia di cretinismo dovuta alle scie chimiche, è che la sicurezza sia stata messa nel cassetto e l'unico altro elemento (il profitto, la competizione, il raggiungimento dell'obiettivo) sia stato il fine ultimo che ha portato a questi risultati.
Purtroppo ho avuto modo in passato di avere a che fare con alcuni di questi "giovani" rampanti pseudo manager il cui unico credo era appunto raggiungere l'obiettivo. E non parlo di fare le cose nei tempi previsti, no questo era solo il mezzo per il vero obiettivo (il loro, la carriera, il soddisfare il loro ego) fregandosene di procedure, sicurezza, norme.
In uno scenario più grande e complesso che vede un colosso globale come Boeing uno stato come gli USA e una AA come FAA che è sempre stata il riferimento mondiale per normative e rgolamentazioni, non è troppo complottistico pensare che "la parte politica" abbia preso il sopravvento sulla parte tecnica.
E se tanto mi da tanto, alla luce di questo cosa pensare di altri prodotti di questo costruttore e forse anche di altri?
Un esempio, passato in sordina perchè fortunatamente non ha creato "danni"
http://avherald.com/h?article=4c2fe53a&opt=0
Tutto bene quì?
In dettaglio quì potrebbe entrare in gioco un piccolo sistema che in caso un motore resti alla max thrust con manetta al minimo, il motore venga automaticamente spento. (TCMA Thrust Control Malfunction Accommodation.) Immaginiamo uno scenario simile anzichè in atterraggio come è accaduto, avvenga oltre la V1.
Sto seguendo questa vicenda, con tutte le difficoltà del caso a reperire info. Nella speranza che una analisi dell'accaduto qualcuno la stia facendo e pubblichi risultati.
Nel frattempo, anche questa macchina rientra all'interno delle mie personali prescrizioni di aeronavigabilità. Con questa io non volo.

Ciao.

Io non volevo sostenere il fatto che si tratti o non si tratti di un problema SW legato strettamente al MCAS...

Stavo rispondendo a questo post:

"Originariamente inviato da Fewwy Visualizza il messaggio
Ad ogni modo, a me fa molta più paura e mi sembra molto meno rispondente alla sicurezza areonautica, il fatto che Boeing annunci una nuova release a breve (del tipo “ci siamo quasi, massimo 10 giorni ed è pronta”), con il fiato sul collo di vari soggetti e l’opinione pubblica mondiale che sta a guardare, per far ripartire la giostra quanto prima.

Non sono un informatico, ma ho la sensazione che sia il peggior modo di operare per ritoccare/riscrivere un software."

in merito ai tempi ed alle modalità con cui, PROBABILMENTE, chi di dovere ha dovuto approcciarsi per rilasciare una determinata fix...

Ho citato MCAS come esempio per dire che a volte anche un "programmino semplice semplice", in caso di problemi di natura non propriamente cristallina, potrebbe generare una mole di lavoro non indifferente per la sua risoluzione definitiva.
 
Ciao.

Io non volevo sostenere il fatto che si tratti o non si tratti di un problema SW legato strettamente al MCAS...

.

il mio intervento non era una risposta a te, ho solo preso spunto dal tuo post e dalla tua domanda e più in generale al fatto che potrebbe sembrare che il tutto sia strettamente legato semplicemente ad un problema di SW.
Non è li la questione, non si tratta di un "bug" o una svista. Un nuovo SW significa ripensare completamente la logica di funzionamento, non correggere un errore nel programmare inserendo una virgola in più o meno nello specifico, ma non è quì il punto.
La questione è la sicurezza.
Quanto ci vuole a progettare una nuova macchina per contrastare sul mercato il mio competitor? La risposta attuale è "il più breve tempo possibile". La risposta giusta invece è "il più breve tempo possibile necessario"
 
E', come al solito, presto per saltare a conclusioni.

Ma, se dovessero veramente finire come sembra finire, ossia con due aerei perduti a causa dello stesso problema, il vero peccato originale per Boeing, secondo me, e' quello di aver portato all'estremo - e oltre - il modello 737. A un aereo figlio degli anni '60, un aereo costruito per motori con un diametro di 1.25 metri (tale era il fan del JT8D) e' stato infilato un motore, il LEAP, con fan di diametro doppio, 2.5 metri. E per fare questo s'e' dovuto spostare i motori, alzarli, complicare l'aerodinamica e creare software troppo complicati. E ancora non stiamo vedendo il 737-10MAX, che a quella bastardizzazione aggiunge quella della fusoliera extra-long e limitazioni all'angolo di decollo... Se veramente si arrivera' a decidere che, si, l'MCAS ha causato la perdita di entrambi i Lion Air e Ethiopian, a Boeing le mazzate dovrebbero arrivare per non aver deciso che era il momento di fare cio' che non hanno fatto in quasi 40 anni, ossia progettare un nuovo narrowbody.

Concordo al 100%, stamattina stavo pensando esattamente alla stessa cosa.
 
Un effetto collaterale di questa vicenda potrebbe essere vedere prima, e magari in piu' versioni, il 797.

Ovviamente siamo nel campo delle speculazioni e dell'ampliamento a dismisura del perimetro del topic.
 
Ci terrei solamente a fare i complimenti a tutti per come stia procedendo il thread.
Se paragono lo stesso thread presente su airliners.net c'è un potpourri di flaming, spam e compagnia bella lungo 2600 posts.
Qui in solamente 500 posts siamo stati capaci di comunicare molto di più.


Inviato dal mio Redmi 5 Plus utilizzando Tapatalk