PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 31st Mar 2019, 04:17
  #478 (permalink)  
CurtainTwitcher
 
Join Date: Jul 2014
Location: Harbour Master Place
Posts: 662
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Water pilot
The pilots reported that they could not trust any instruments, so it was much more complex than the clean MCAS scenario that we have considered so far. Cascades of errors are common in the failure of software systems as the first failure can put the system outside of the testing envelope. From following this thread it looks like the MAX had a glass cockpit (screens instead of analog gauges) that the other models did not have, is that correct? I have actually done almost exactly that sort of programming and it is not as simple as it sounds.
This is a very fast moving thread, it is difficult to keep up with this in conjunction with the previous Lion Air one. Lots of good information came out.

It was not a "clean MCAS" scenario [take to mean an approach to aerodynamic stall] as you rightly point out.
We know from the first accident the MCAS nose down trim activation was a ONE consequence of erroneous data from an Angle Of Attack vane. The other consequences of the erroneous data were:
  • IAS Disagree (airspeed is an AoA dependant value, visual warning)
  • Stick shaker activation (tactile and audible warning)
  • Elevator Feel Differential warning (visual)
  • Almost certainly multiple other visual warnings
Note, these warnings were from lift off.

If you want to get a sense of what the crew faced, this is a 5 minute loop of the 737 stick shaker. The Lion Air crew had this for the entire 11 minutes of flight. I've posted this video multiple times to demonstrate just one of the difficulties the crew were faced with.

Particularly in the Lion Air case, when the MCAS was unknown, all the crew would be able to comprehend for the first seconds of flight is the aircraft is that the aircraft was actually still flying, and not in fact stalling. Once they came to terms with a pitch attitude and takeoff thrust set that kept them flying, it was then a case of trying to figure out what is going on. They probably understood they needed to run the airspeed unreliable checklist and felt they had things under enough control to make a safe landing.

The really insidious part is the MCAS was silently sitting there armed due to the AoA erroneous data, but inactive until the flaps were retracted. Once they retracted the flaps, MCAS became active and the fight between it and the crew began, the crew searching the checklist for a solution, not realising what was wrong. They went from being able to fly straight and level to having some weirdly inconsistent pitch issue simply by retracting the flaps. Nothing in the IAS disagree checklist cautions against moving the flap lever. There shouldn't be a connection from their system knowledge. We now know the crew tried to find a checklist to cover this problem until the end of the flight. They probably had the target attitude and thrust for straight and level flight at 5,000' as per inflight performance for unreliable airspeed, but the aircraft just kept fighting them. Remember they still had the stick shaker and all the other associated warning until the end.

Why is the Ethiopian accident different? MCAS appears to have become active very soon after takeoff, as reported by porpoising from the Tower and other aircraft on the ground. The answer as to why MCAS activation happened sooner than for Lion Air has not been publicly revealed.
CurtainTwitcher is offline