Originally Posted by
GlobalNav
The use of a single AoA sensor at a time, for a function that can do what it did in these two crash scenarios is the problem. ......Furthermore, I don't know what the hazard classification was approved for MCAS, but it should be Catastrophic, which means that software associated with its function should be at Design Assurance Level A. Not sure what the software DAL is, but to modify Level A software and get the modification approved is not trivial (time-consuming and expensive).
Before, they were thinking the pilots can easily turn the Stab Trim off if they saw trim putting the nose down in a strange way. ... Now, due to the crashes, the severity is redefined, from a Human Factors viewpoint.
As for the announced fix (summary so far), they really need to publish the source code section involved and/or block diagram schematics instead of simply trying to paraphrase ambiguously what the system is capable of doing. I know that's unprecedented, but for pete's sake, this is crazy, them running around with loose english phrasing of how persistent MCAS will be from now on, when it will re-engage, you know, all the state transition diagram logic would be nice to know. ....... For some, it may be enough to know that 2 AoA vane sensors will be compared (finally, right?!), and I might have designed it so MCAS function would still work if one AoA vane malfunctioned by using [AoA = Pitch Angle - Flight Path Angle] as a tie-breaker to determine which AoA vane is sick. I guess just getting rid of MCAS on AoA disagrees is OK here since having no MCAS isn't much of safety problem. They kill MCAS on AoA disagrees, fine.....