Boeing 737 Stick Shake

[safetypee]

What is the architecture and logic of the 737 MAX stick-shake, stall warning system?
Information from discussions about the recent accident indicates that the combination of vane and stick-shaker are independent for each side of the aircraft; the respective side of the aircraft drives the same-side stick-shake.
Is this view confirmed by the wiring configuration; does the MAX installation differ from previous versions?

The accident view relates an ‘errant vane’ to the highest AoA, and thus is the reason for a ‘false’ stick-shake, but only on one side of the aircraft.
This view also implies that with serviceable vanes, then they track sufficiently close to give stick-shake on both control columns ‘near simultaneously’.
Conversely if an ‘errant vane’ is the lowest AoA, then in the event of real high AoA, only one stick-shake will operate (the higher, correct AoA).

Are these views correct; logical ?

(If so then there may be a ‘hole’ in the latest emergency trim checklist - what if the ‘errant’ vane gives a low AoA)

[Mad (Flt) Scientist]

(If so then there may be a ‘hole’ in the latest emergency trim checklist - what if the ‘errant’ vane gives a low AoA)

Not a B737-specific reply, but.

The reason for the two independent shakers architecture is to assure the reliability of stall warning, which typically has to meet 1e-7 per FH or better. Thus the absence of a shaker on one side is implicitly catered for in the design - it is assumed that EITHER shaker achieves the required function of stall warning. Thus a low reading vane, which effectively means loss of shaker on that side, is the reason for the architecture and requires no additional inflight procedures. You still have a working shaker in such a case.

Of course, it's a non-dispatchable condition, because you are then down to a single-string stall warning architecture, and that DOESN'T meet 1e-7 at all.

[FCeng84]

The architecture described above is correct and the same for all 737 models. Because the left and right columns are mechanically linked and the stick shakers are loud it may be difficult to determine which one has activated if only one does. I don’t know the crew procedures well enough to know if the two pilots are expected to recognize when only one is going.

[safetypee]

Thanks MFS, FCEng.
Thus as I understand this ‘commonly used’ architecture provides ‘fail safe’ stick-shaker operation at the expense of an erroneous high AoA input, which I assume is part of the high reliability requirement - AoA inputs have to be robust.
It is this rare failure case which enters the debate on MCAS, and use of AoA in other systems.
If other systems drills are predicated on the same architecture of ‘no immediate effect for stick-shake’ (low reading AoA), there may still be many other disagreement alerts and system consequences.

[Machinbird]

It seems to me that inappropriate activation of a stick shaker can be used to identify an AOA malfunction on the affected side of a 737, even if you are not equipped with AOA compare capability.
Any pilot worth his salt should know when he is in a potential high AOA situation, and when he is not. If you are straight and level at 250 knots or above, you should not be experiencing a stick shaker.
How well are AOA system failures handled in emergency procedures?
Continuing a flight with a continuous stick shaker makes it likely that a subsequent actual need for stick shaker may not be reacted to if triggered on the opposite side. However, the crew of the preceding Lion Air flight did not disable the stick shaker.
Disabling the stabilizer electric trim and staying out of RVSM airspace seems to have been the limit of their cockpit procedures.

[safetypee]

A further thought on the certification of a ‘commonly used’ architecture. Whilst ‘the highest AoA wins’ logic provides a fail-safe solution for ensuring stall warning, it still leaves a potential hazard of the flight crew responding (nose down) to an erroneous stick-shake; worst case shortly after lift-off.
Would a ‘commonly used’ safety case considered the availability of airspeed to cross check / monitor the overall flight situation ? If so, the probability of a false pilot response would be reduced, providing sufficient overall level of safety in conjunction with a highly reliable vane system.

This might cover Machinbird’s operational view, where all available instruments are used to clarify the situation, in a ‘commonly used’ design.
As much as I agree with the airmanship, common sense, ‘salt’, view, I doubt that these are acceptable terms in certification, but it does question design assumptions of human capability after system failure.

Following-on from the above; a difference with the specific system in 737 MAX is that because AoA is used in ADC corrections, an AoA disagree will also trigger an IAS disagree (and ALT disagree), increasing the pilots’ mental demand in resolving the overall situation by comparing speed - but airmanship and ‘salt’ still apply (even if the data corrections are minor).
If so then the certification argument for the 737 MAX is not equivalent to a ‘commonly used’ safety case.

This difference might be seen in the crew’s actions in the Lion incident and accident flights, where the focus of attention appeared to be on air-data, UAS, and establishing which seed display was correct. Sick-shake was a lesser concern, either because of the attention on airspeed due to the IAS disagree alert, or that stick-shake had been encountered on previous flights.

A further supposition if the coincident AirData disagree alerts mentally superseded the AoA disagree alert. If the the Air Data alerts were removed to improve the safety case, a erroneous AoA input and AoA disagree alert might be considered valid, particularly because of the erroneous low speed display overlaying the EFIS speed scale, suggests a stall.
If so, using an AoA disagree alert could increase the hazard of inappropriate crew response to an erroneous high AoA, because the EFIS display ‘confirms’ high AoA - remove both. (Catch 22, close-coupled systems, intractable) - dust off Eric Hollnagel’s views on safety.

All of which might have its roots in grandfather rights, and ‘genetic deficiencies’ in grandfather-design and certification thinking, possibly due to the intermix of old aircraft and modern digital systems within the same design organisation. Current designers were not born when 737 first certificated (1967).
‘Children of the digital designers line’ !

[Machinbird]

A further thought on the certification of a ‘commonly used’ architecture. Whilst ‘the highest AoA wins’ logic provides a fail-safe solution for ensuring stall warning, it still leaves a potential hazard of the flight crew responding (nose down) to an erroneous stick-shake; worst case shortly after lift-off. Unfortunately, this is not just of academic concern as the following example attests: Kenya Airways 431 Summary (https://www.tailstrike.com/300100.html)

My view of the value of Angle of Attack has been formed by my past experience as a Naval Aviator flying jets off aircraft carriers at night: Following a rather violent catapult launch, we were hurled into the inkwell off the bow of the ship and we had but seconds to determine if the launch had been successful or not. You rotated the aircraft, retracted the gear, scanned the airspeed and angle of attack and hopefully found that you were flying. If you weren't flying, the rudder pedal shaker would be massaging your foot and if the RADALT was decreasing, you were beginning to think about jettisoning external fuel tanks, rotating a bit more, and ejection from the aircraft.

The problem with AOA is that it has always been the poor stepchild of the airline beancounters who are asking why do you need it if you have been flying successfully without it for so long?
In our present newer highly automated flying machines, AOA is becoming an integral part of the flight control architecture and air data computers systems, and a pilot really needs to know if their AOA system is working properly. You can clue pilots in to a problem with their AOA using a compare system, and that should be a base level of instrumentation/warning for aircraft that use AOA in any way as part of the flight control architecture or as part of the static pressure correction system. The bean counters should not be given a choice in this regard. The possibility of inappropriate aircrew response should be handled by developing specific procedures and training crews in their use.

Pilots can be trained to handle systems that are not exactly like those they have encountered before, e.g. the Airbus C* control system, but they need to be told the differences.
Installing the MCAS system on top of the STS and assuming that there was no need to alert aircrews to a difference was a mistake.
STS at least looked for pilot intent by sensing the control column position and inhibiting contrary STS trim activation. MCAS may have been inserted on top of the STS system, but it was not constrained by control column position and thus promoted an accident.

[Derfred]

I suspect that MCAS not being constrained by control column position was a deliberate decision. Possibly because if it was, that would defeat the purpose of it’s existence. Just pondering...

[Machinbird]

I suspect that MCAS not being constrained by control column position was a deliberate decision. Possibly because if it was, that would defeat the purpose of it’s existence.
No disagreement there. But the resulting design reeks of not having been adequately studied from a safety standpoint. We aren't talking complicated. A single point of failure causing undesired system performance should be obvious to even the most junior Electrical Engineer.

When flying any of the 6 different jets in my logbook in manual flight, I would have regarded any uncommanded activation of the aircraft trim system as akin to having a rattlesnake in the cockpit. In those days, that was a defensible boundary. Today, with STS /MCAS (Boeing) and C*(Airbus), that easily defended perimeter is no more.
All I can say to those of you who are still flying heavy iron is to absolutely know how to effectively and quickly stop any undesired trim activation on your aircraft, and to be alert for any inappropriate long trim activations.
It would be a very sad thing to learn from the CVR that JT610's crew wasn't certain of the exact procedure to disable their electric pitch trim system. From their communications with ATC, they acknowledged a flight control problem!

[gums]

Aye, ‘bird!

more later, but I am increasingly looking at certification considerations by Big B.

Gums sends...