PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 18th Mar 2019, 16:28
  #255 (permalink)  
PEI_3721
 
Join Date: Mar 2006
Location: England
Posts: 997
Likes: 0
Received 6 Likes on 3 Posts
A challenge for Boeing via investigators is to identify how ‘AoA’ came to dominate these accidents, whilst apparently using the same / similar AoA probe on older 737s.
Some confusion for Ppruners is not knowing where the FDR AoA value is taken from -
737MAX Stab Trim architecture
The implication is that something other than the probe / probe output might contribute to the problem - wiring. Whilst the mechanism involves AoA, exactly where an error originates and interacts with MACS system is not known. If the error is not in the computation, then more attention is required on the Max probe failure rate and the aircraft wiring / build standard.

MCAS enhances stability to meet certification requirements. Any other (unidentified) failures affecting MCAS (input or computation) could similarly invalidate the certification; failures might be acceptable for rare occurrences and a safe recovery, but not so for frequent failures, MEL, or a high probe failure rate.

Whether the aircraft can be recovered safely with trim malfunction is central to these accidents. Thus the integrity of the overall trim system (tail jack stall) may require reassessment, including crews’ ability to fly a runaway trim recovery procedure (irrespective of MACS).
The FAA should re-evaluate the trim runway procedure because in these accidents the crew were apparently unable to recover from a severe trim malfunction.
Would the failure and procedure discussed in Boeing advice on "aerodynamically relieving airloads" using manual stabilizer trim still be considered tenable.
Should there be an altitude limit to allow time for recovery, or is the procedure so unrealistic that any cause, risk of failure should similarly be improved.
PEI_3721 is offline