PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 15th Feb 2019, 17:53
  #70 (permalink)  
safetypee
 
Join Date: Dec 2002
Location: UK
Posts: 2,455
Likes: 0
Received 9 Likes on 5 Posts
MFS,
Re the pilots even in the accident flight were able to maintain control for many minutes after the failure (which was apparently pre-existing at takeoff) very strongly suggests that the required ability to initially counter the failure was plainly present.

From a pilots viewpoint there could have been two unrelated failures.
First, from take off, indications that airspeed was unreliable, and given the concerns identified in #66 the crew managed to fly the aircraft; although there may have been some expectation from the preceding flight / tech log.

Second, after selecting flaps up, aircraft control was increasingly difficult due to incorrect MACS trim input. The crew might have related this to unreliable airspeed, non indicated change in speed felt as a change in trim, and / or need to change speed; alternatively they might have related this to STS as did the previous crew, but elected not to disable the trim because STS (trim) should have been overridden by back stick cutout.
The crew were having to managing two separate failures; unreliable airspeed and a trim malfunction.

In certification terms the single initiating factor appears to be AoA. In the first instance immediately after takeoff the situation would be similar to previous certifications - crew intervention based on instrument indications and tactile alerting. However, in the second instance there was no clear indication of the nature of the failure, the consequences, or action required.

Thus the crew’s ability after take off should not be taken as the ability to manage the second scenario, even if the initiator was the same - the indications and effects were completely different and should have been assessed so in the certification process.


safetypee is online now