Originally Posted by
MurphyWasRight
My bold in quote, main point is things are not necessarily as simple as it seems;
As they say, "the perfect is the enemy of the good." My main point is that they could have done something--less than perfect, less even than pretty good--but they did nothing. That tells me that the programmers were asleep at the switch. I cannot imagine that they were given marching orders to build this, the orders didn't specify any input validation, they proposed doing something, and the proposal was rejected.
Originally Posted by
MurphyWasRight
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.
I feel you are nit picking here. First, the DFDR data from the two accidents suggests that the normal, stationary reading for the vanes is somewhere around zero. I'm sure someone else on the thread can comment knowledgeably, but its looks to me like a stationary reading of more than 20 degrees is a pretty strong sign of a problem. Beyond that, the AoA signal surely becomes valid at some point during the take off roll, so the FCC could mark it as invalid if it's outside a reasonable range before rotation.
Originally Posted by
MurphyWasRight
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.
The purpose of the state history is to decide whether to disable MCAS due to a suspected AoA error. The consequences of incorrectly disabling MCAS are not the same as the consequences of incorrectly relying on flight data to take affirmative action and move controls. So I think you are overstating the risk and verification requirements. Mostly, they'd need to make sure references to the AoA history doesn't disable MCAS in the normal cases where it is supposed to activate.
Originally Posted by
MurphyWasRight
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.
If you aren't trying to design the perfect set of input filters, then you aren't going to get bogged down "getting agreement on valid/invalid values." They didn't do nothing because it was taking too much time to agree on doing everything or because it was going to cost too much to do anything at all. And the simplest input validation (e.g., AoA > [pick a number]) would have had negligible impact on the code or testing.
I don't know why they didn't cross check sensors. Maybe the changes were perceived as too invasive and someone made the conscious decision that the risk of screwing that up was greater than the potential gain. Maybe the reason for not cross checking sensors will eventually come out when the full story is told. But whatever the reason was, that was not a reason to do nothing. Again, I think they did nothing because they just didn't think of it.