PPRuNe Forums - View Single Post - Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Old 31st Mar 2019, 06:59
  #479 (permalink)  
safetypee
 
Join Date: Dec 2002
Location: UK
Posts: 2,453
Likes: 0
Received 9 Likes on 5 Posts
Most of Pprune ‘software’ analysis are based on the values of AoA recorded by the FDR.
Where exactly in the sensing and computational system is the FDR value take from ?

If the FDR records the vane output then this implies that this is the value which the FGC uses; I assume that there are exceptions to this - transmission error, interference. Thus MCAS (and other FGS functions) can malfunction; but not always - not every aircraft / flight - why not.
However, if the FDR samples ‘some universal bus’, then the origin of the corrupt AoA is less clear, as might be the random nature.

Is there a situation where the FGC receives the correct vane value, but subsequent internal computation corrupts the AoA value used by MCAS, which is then widely available; FDR, air-data, stick-shake (most from within the FGC), i.e. the corruption is associated with the ‘new’ software specific to the 737 Max.

Could this add weight to an argument as to why previous variants of 737 apparently do not experience many AoA problems - false stick-shake, but why two 737 Max have (check relative probabilities, failure rates).

What evidence is required to judge this, starting of course with the FDR pickoff.


Curtain Twitcher #484
The reported ‘porpoising’ after takeoff could be consistent with stick-shake and apparent unreliable airspeed, as per Lion and system based theory.








Last edited by safetypee; 31st Mar 2019 at 10:04. Reason: typo
safetypee is offline