Originally Posted by
safetypee
This disagreement probably stems from the proposed MCAS modification.
With a dual system (pre mod) where each stick is independently associated with an AoA input, it should be possible to inhibit one side without loss of function.
In the initial situation the crew do not know if the stick-shake is valid or false, ie. which vane is inaccurate. After crosschecking airspeed for stall conditions it should be possible to identify and inhibit the faulty side, which should leave the unaffected side to provide any subsequent alert.
The crew can operate without distraction and still retain the stall alerting function.
However, if the MCAS modification 'cross-wires' the stick-shake functions as a result of having to use both FGCs and both AoA inputs for MCAS fault detection, then identification of a faulty stick-shake is more difficult, and inhibiting one side may also affect all stall alerting.
The debate then is to what degree is the shaker distracting vs the loss of stall alerting. It might be possible to retain one stick so that a subsequent valid stall would add shake the errant system so that the cumulative, change in alerting is recognisable.
A further complication in the Max is that AoA input to the ADC provides speed (and alt) corrections. There will be a difference in airspeed with erroneous AoA input or failure, but comparing with the standby ASI it should be possible to identify a faulty system. However, if by inhibiting one AoA this also affects both ADC (as per FGC hypothesis above) then both EFIS airspeed display will have an error. Thus the debate to inhibit AoA or not must additionally consider inaccurate speed together with with distraction.
The options are further complicated if shake can be inhibited independently of AoA, but if inhibited which system is the valid one ?
I believe the 737 stick-shaker and stall alert are operated by the ADIRUs directly. Earlier I wondered how the FGCs used the two inputs and was surprised to see they are bypassed to operate those alarms directly. Perhaps I misread it, but it makes a great deal of sense to push that function as early in the sensor chain as possible to decrease the number of links and the ability to fail.
I do agree that figuring out the desired failure handling is not easy. It has to be one that sorts false inputs from true inputs and tells the pilots what has gone wrong. Still it's been possible to shut down the remaining operating engine when the stress levels get too high, so it's clear that solving this general problem is not easy.
What is clear is that the outcome possible under the previous version will never happen again; that is, there won't be a chance that under an AoA disagree situation that an MCAS or, possibly, even STS correction to trim will be allowed. So now it's shifted to the more esoteric argument about how to automate proper handling of false information that looks exactly like true information. Anyone who comes to the certain solution for that problem will clean up in the stock market.