157 aboard Ethiopian Airlines flight to Nairobi involved in fatal crash

Gordon_R

Executive Member
Joined
Jul 5, 2009
Messages
5,624
Interesting from the NYT

https://www.nytimes.com/2019/03/14/world/boeing-737-max-ethiopian-airlines.html

Big concerns regarding the speed of the aircraft.



Can anyone shed some light? I don't think the MCARS changes the engine speeds? Or could the pilots have been increasing thrust to compensate for a perceived stall?
The auto-pilot has different controls, and the auto-throttle might still have been engaged during the 'climb' phase of the flight. Else pilots were on manual, and overwhelmed by distractions such as stick-shaker and stall warning...
 

Grant

Honorary Master
Joined
Mar 27, 2007
Messages
44,711
The auto-pilot has different controls, and the auto-throttle might still have been engaged during the 'climb' phase of the flight. Else pilots were on manual, and overwhelmed by distractions such as stick-shaker and stall warning...
i suspect pilots can become easily overwhelmed by a multitude of urgent warnings being triggered simultaneously
 

FlashSA

Executive Member
Joined
Oct 19, 2007
Messages
7,741
I had a great Twitter thread unrolled:
https://threadreaderapp.com/thread/1106934362531155974.html

Here is the unroll:

1of x: BEST analysis of what really is happening on the #Boeing737Max issue from my brother in law @davekammeyer, who’s a pilot, software engineer & deep thinker. Bottom line don’t blame software that’s the band aid for many other engineering and economic forces in effect.
Some people are calling the 737MAX tragedies a #software failure. Here's my response: It's not a software problem. It was an

* Economic problem that the 737 engines used too much fuel, so they decided to install more efficient engines with bigger fans and make the 737MAX.
This led to an

* Airframe problem. They wanted to use the 737 airframe for economic reasons, but needed more ground clearance with bigger engines.The 737 design can't be practically modified to have taller main landing gear. The solution was to mount them higher & more forward.
This led to an

* Aerodynamic problem. The airframe with the engines mounted differently did not have adequately stable handling at high AoA to be certifiable. Boeing decided to create the MCAS system to electronically correct for the aircraft's handling deficiencies.
During the course of developing the MCAS, there was a

* Systems engineering problem. Boeing wanted the simplest possible fix that fit their existing systems architecture, so that it required minimal engineering rework, and minimal new training for pilots and maintenance crews.
The easiest way to do this was to add some features to the existing Elevator Feel Shift system. Like the #EFS system, the #MCAS relies on non-redundant sensors to decide how much trim to add. Unlike the EFS system, MCAS can make huge nose down trim changes.
On both ill-fated flights, there was a:
* Sensor problem. The AoA vane on the 737MAX appears to not be very reliable and gave wildly wrong readings. On #LionAir, this was compounded by a
* Maintenance practices problem. The previous crew had experienced the same problem and didn't record the problem in the maintenance logbook. This was compounded by a:
* Pilot training problem. On LionAir, pilots were never even told about the MCAS, and by the time of the Ethiopian flight, there was an emergency AD issued, but no one had done sim training on this failure. This was compounded by an:
* Economic problem. Boeing sells an option package that includes an extra AoA vane, and an AoA disagree light, which lets pilots know that this problem was happening. Both 737MAXes that crashed were delivered without this option. No 737MAX with this option has ever crashed.
All of this was compounded by a:

* Pilot expertise problem. If the pilots had correctly and quickly identified the problem and run the stab trim runaway checklist, they would not have crashed.
Nowhere in here is there a software problem. The computers & software performed their jobs according to spec without error. The specification was just shitty. Now the quickest way for Boeing to solve this mess is to call up the software guys to come up with another band-aid.
I'm a software engineer, and we're sometimes called on to fix the deficiencies of mechanical or aero or electrical engineering, because the metal has already been cut or the molds have already been made or the chip has already been fabed, and so that problem can't be solved.
But the software can always be pushed to the update server or reflashed. When the software band-aid comes off in a 500mph wind, it's tempting to just blame the band-aid.
 

Gordon_R

Executive Member
Joined
Jul 5, 2009
Messages
5,624
Thanks @FlashSA

Its called the Swiss cheese theory. A lot of holes have to line up for an aircraft to fall out of the sky.

Many of those issues were on the ground long before takeoff, in boardrooms and design offices, and during the certification process.

There is plenty of blame to go around, much more so on Boeing than the poor pilots IMO...
 

ForceFate

Honorary Master
Joined
May 18, 2009
Messages
14,261
I had a great Twitter thread unrolled:
https://threadreaderapp.com/thread/1106934362531155974.html

Here is the unroll:

1of x: BEST analysis of what really is happening on the #Boeing737Max issue from my brother in law @davekammeyer, who’s a pilot, software engineer & deep thinker. Bottom line don’t blame software that’s the band aid for many other engineering and economic forces in effect.
Some people are calling the 737MAX tragedies a #software failure. Here's my response: It's not a software problem. It was an

* Economic problem that the 737 engines used too much fuel, so they decided to install more efficient engines with bigger fans and make the 737MAX.
This led to an

* Airframe problem. They wanted to use the 737 airframe for economic reasons, but needed more ground clearance with bigger engines.The 737 design can't be practically modified to have taller main landing gear. The solution was to mount them higher & more forward.
This led to an

* Aerodynamic problem. The airframe with the engines mounted differently did not have adequately stable handling at high AoA to be certifiable. Boeing decided to create the MCAS system to electronically correct for the aircraft's handling deficiencies.
During the course of developing the MCAS, there was a

* Systems engineering problem. Boeing wanted the simplest possible fix that fit their existing systems architecture, so that it required minimal engineering rework, and minimal new training for pilots and maintenance crews.
The easiest way to do this was to add some features to the existing Elevator Feel Shift system. Like the #EFS system, the #MCAS relies on non-redundant sensors to decide how much trim to add. Unlike the EFS system, MCAS can make huge nose down trim changes.
On both ill-fated flights, there was a:
* Sensor problem. The AoA vane on the 737MAX appears to not be very reliable and gave wildly wrong readings. On #LionAir, this was compounded by a
* Maintenance practices problem. The previous crew had experienced the same problem and didn't record the problem in the maintenance logbook. This was compounded by a:
* Pilot training problem. On LionAir, pilots were never even told about the MCAS, and by the time of the Ethiopian flight, there was an emergency AD issued, but no one had done sim training on this failure. This was compounded by an:
* Economic problem. Boeing sells an option package that includes an extra AoA vane, and an AoA disagree light, which lets pilots know that this problem was happening. Both 737MAXes that crashed were delivered without this option. No 737MAX with this option has ever crashed.
All of this was compounded by a:

* Pilot expertise problem. If the pilots had correctly and quickly identified the problem and run the stab trim runaway checklist, they would not have crashed.
Nowhere in here is there a software problem. The computers & software performed their jobs according to spec without error. The specification was just shitty. Now the quickest way for Boeing to solve this mess is to call up the software guys to come up with another band-aid.
I'm a software engineer, and we're sometimes called on to fix the deficiencies of mechanical or aero or electrical engineering, because the metal has already been cut or the molds have already been made or the chip has already been fabed, and so that problem can't be solved.
But the software can always be pushed to the update server or reflashed. When the software band-aid comes off in a 500mph wind, it's tempting to just blame the band-aid.
Makes a lot of sense. This is also common in other manufacturing sectors.
 

Sollie

Expert Member
Joined
Apr 20, 2005
Messages
2,476
I had a great Twitter thread unrolled:
https://threadreaderapp.com/thread/1106934362531155974.html

Here is the unroll:
....
* Sensor problem. The AoA vane on the 737MAX appears to not be very reliable and gave wildly wrong readings.
...
* Economic problem. Boeing sells an option package that includes an extra AoA vane, and an AoA disagree light, which lets pilots know that this problem was happening. Both 737MAXes that crashed were delivered without this option. No 737MAX with this option has ever crashed.
Thanks. That is also what I agree with in my own analysis, except perhaps for how software handles these failures and the logical sequencing - overriding pilot decision. Much of the argument would be moot as to what a bug is. The few line sof code may be perfect, but the implementation ill advised. But then again we should have never even gotten there in the first place and it would not have been that difficult either.

In simplistic terms, this equates to the war that was lost for want of a nail. We need some form of redundancy, it's not a foreign concept. I really question some of these design decisions. Ideally for a critical system you need at least three inputs (always an odd number) in a type of vote system, to reach quorum. Ideally these imputs should be seperate locations. One failure - no biggie. Two, alert the crap out of the world - and ffs, don't override pilot decision.

In my days where I was advising clients on computer solutions, I guaranteed them certain features with their new system much to the chagrin of sales people and management: power supply failures due to fans being mechanical, disk failures for the same reason. Where they were literally spending millions, a few thousand rand could make those failures a non-issue. In a different way lives were also depending on availability. Electronics will fail even though lasting for a long time. To succeed, plan for failure.
 
Top