Originally Posted by
HighWind
I you remove the code for MCAS then it can't generate a runaway
But the Flight Control System have been connected to the trim for decades, and a bit-flip in other functions of the Flight Control Computers might be able to generate a 'continues' runaway. (Way easier to diagnose quickly, than a intermittent runaway)
I see MCAS as a change that changed the reliability of the FCS from being several magnitudes better than specified by DAL C, to about the limit of DAL C.
You can't complain when a DAL C design, changes from e.g. DAL B to DAL C reliability following a design change. (The same could have happened due to e.g. a die shrink )
Using one AoA sensor might sufficient for DAL C, but not for the required DAL A.
IMO the fundamental issue with the MAX (and this is not a problem with the NG) is that for MCAS to operate, the FCC must have a relay that inhibits the pilots column trim cutout switches. Previously NG pilots had an intuitive and effective way to inhibit computer generated runaway trim - just pull or push the yoke. IMO this obviates specific need for high reliability on the NG FCC, because there is no equivalent relay.
Way back in previous discussions, we saw an incredibly complex diagram of relays for the stabiliser trim. It seems that neither Boeing (nor the FAA) tested this fully before launch. That's what happens when you over-complicate things, and the consequences are clear. The MAX is a new aircraft, where previously unanticipated failure modes arise (and not just MCAS).
To fix the new problem on the MAX, while using the existing FCCs, a fail-neutral option is the chosen option, since DAL A is not feasible with the 737 architecture. The solution noted by the Seattle Times would be done in addition to whatever fixes are made to MCAS, and produce a slightly better outcome than the NG for runaway trim cases.