Originally Posted by
Notanatp
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.
My bold in quote, main point is things are not necessarily as simple as it seems;
1:AoA sensor is not active until enough airflow to move the vane, so position with zero airspeed is meaningless. This complicates any input validation since it would require airspeed to turn on any checks.
2: Introducing state (history) can greatly complicate verification since the code must be exercised to reach and respond at to least a subset of all possible states. It also complicates the code which of course adds to risk of bugs.
3: It would have taken some time to code and significantly more time to verify. The greatest schedule impact however might have been getting agreement on valid/invalid values, keeping in mind that MCAS is supposed to respond to somewhat extreme conditions. Even then the checking would not cover all cases, had the Lion AIr sensor chain had less offset it could have triggered MCAS with a totally valid input.
What is shocking is that the second sensor was not used as a cross check, "both must be within x%" is much more robust than any attempt to filter a single input.
As a final note one possible factor in the Air france tragedy was that due to reasonableness checking the stall warning was disabled at low airspeeds only to trigger as the crew lowered the nose, increasing airspeed (while still stalled).
This at a minimum would cause confusion and likely discourage lowering the nose; it yells at me when I do this == don't do that.