PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 19th Mar 2019, 07:20
  #262 (permalink)  
ecto1
 
Join Date: Nov 2018
Location: madrid
Posts: 47
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by FCeng84
LEOCh,

Very good questions and excellent example diagram. Most of the focus in this and other threads related to how MCAS behaves with an AOA sensor that is failed to a very high value (or with a large positive bias) describes MCAS activating for its full increment in one shot. MCAS actually schedules its airplane nose down stabilizer motion over a range of AOA starting at the activation value and extending as AOA goes higher. If you transition through this AOA range quickly (faster than the stab can run to keep up with the schedule) the whole MCAS increment goes in as one continuous trim event. If AOA increases slowly, however, MCAS will put in a little stabilizer at a time to keep up with the MCAS stab vs. AOA schedule. The MCAS trim will go in at the same 0.27 deg/sec rate but the trim will start and stop as needed depending on AOA time history.

FCeng84
Exactly, MCAS will help with certification, but will NOT help at all in real life scenarios (considering flawless operation). It will make the task of setting a high angle of attack without stalling (say, recover from a dive with not much altitude to work with) a lot harder than without MCAS. That itself is a huge problem that did not surface yet fully (outside these forums). It's simply too slow to do something in the background that helps the pilot (and will make instead a very annoying extra oddity to deal with).

That's crime nš1.

Crime nš2 is to ignore 100% of software tools available to perform the most basic sanity checks on input data or output results.

Crime nš3 is not to install a "MCAS active" light or message or aural warning (blinking when actually trimming and steady over the pauses).

2 and 3 could be fixed by software, but MCAS is doomed because of 1.
ecto1 is offline