Originally Posted by
Water pilot
I would put this in the software error category of failing to anticipate bad input, much like code that gets a packet that says that the remainder is 450 bytes long which then reads 450 bytes from the stream without verifying that there are actually that many bytes left in the stream. Anything that reads external data has to be able to anticipate bad input and do something appropriate in response. Just pretending that bad input is impossible or that somebody else will respond to it for you is not good design.
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.