PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 5th Sep 2019, 18:30
  #2193 (permalink)  
Notanatp
 
Join Date: Jul 2019
Location: Mass
Posts: 23
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by MurphyWasRight
Not exact match to MCAS, at least in Lion AIr case the AOA value was in range..
The "bad packet check" is not possible in this case since there is (with a singe input) no way to check the data.

For the Ethiopian case the essentially maxed out value might have been detectable as unreasonable, although I don't know that as a fact.

Gets back to specification, adding a "reasonableness" filter can add robustness but can also cause problems if not correctly specified or implemented. It also adds complexity and testing overhead.
The AoA indicator in JT610 was north of 20 degrees when sitting on the ground at zero airspeed. Surely that was enough to trigger a sanity check of inputs. Even in flight, something more than 20 degrees (particularly when it had never been less than 20 degrees, much less in a valid range) would have been an unambiguous indication of bad input (I assume the 737 will stall well below 20 degrees AoA).

The exact parameters of the optimal input checking for MCAS (i.e., rejecting a many invalid conditions as possible while minimizing the rejection of valid conditions) could be subject to some discussion and judgment. But AoA of 20 degrees seems like a no-brainer. At most, it might have required that the FCC "remember" a period of AoA history so it could determine, at the point where the algorithm became active (A/P disengaged, flaps retracted) that the AoA had never been in a valid range.

The bigger issue seems to be that the programmers never questioned the absence of any input validation requirement at all. I fully expect someone to quibble with my assertion that >20 degrees is clearly invalid, but what about 75 degrees? What about readings that are pegged at exactly the same number for a period of time (e.g., frozen or jammed sensor)? Or that suddenly jump from a reasonable number to an out-of-range number?

I just think somebody forgot to ask the question: what is the valid range of inputs and what are the error cases? It wouldn't have taken any time at all to include some kind of basic sanity checks.
Notanatp is offline