Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark • Hacker News Board

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#41

Post by poof131 » Mon, Feb 04, 2019, 4:33 PM UTC

twtw wrote: post #37

CydeWeys wrote: post #32

Earlier quoted context omitted.

Their response would have worked to return to level flight in non-MAX variants of the plane, though. Regardless of what the manual or checklist says, they had years of experience flying 737s that behaved in a specific way, they developed an unconscious/intuitive mental model of the plane based on those behaviors (that is faster and quicker to react than consulting checklists), and then a significant and deadly change…

The point is that their response may have worked for this particular fault, but would not have worked in general. There is a reason that there are more procedures than "pull back on the stick" - pilots do not know what the fault is. > they developed an unconscious/intuitive mental model of the plane If the plane has a fault, it's frequently not going to behave like their unconscious model says it should. In the happy…

> Take it up with the FAA and the airlines?

Sure. It's not just Boeings fault. I believe the FAA will course correct from this and probably all changes to flight controls will need to be reported to pilots. More lessons written in blood.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#42

Post by twtw » Mon, Feb 04, 2019, 4:35 PM UTC

callmeal wrote: post #35

twtw wrote: post #26

Earlier quoted context omitted.

I do not think this is a good analogy. Firstly, there is no single equivalent to "slamming on the brakes" for uncommanded nose-down. This could be caused by a variety of faults, and pilots are trained to respond in a fashion that will be effective for even those in which the first thing to try doesn't work. There is a standard procedure in place to use in this type of situation - arguing that the pilots should only b…

>Firstly, there is no single equivalent to "slamming on the brakes" for uncommanded nose-down. Actually in the "old" version, there is. From TFA: Older 737s had another way of addressing certain problems with the stabilizers: Pulling back on the yoke, or control column, one of which sits immediately in front of both the captain and the first officer, would cut off electronic control of the stabilizers, allowing the p…

And yet the pilots of the previous flight flipped the cutout switches.

EDIT: ... Presumably because it's literally the second thing on the list of things to do in the case of a runaway stabilizer.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#43

Post by rootusrootus » Mon, Feb 04, 2019, 4:36 PM UTC

lolc wrote: post #21

CydeWeys wrote: post #9

Earlier quoted context omitted.

One hopes that in the fix version of the software that goes out, they'll retain that backwards-compatible manual override again. It seems like a flat-out mistake that MCAS, which solely takes input from a single non-redundant sensor, overrides manual inputs silently .

From a UX perspective what should have happened is the plane telling the pilots: "I've detected the danger of a stall and corrected for it!" with the pilots being able to answer either "Ooops thank you!" but also "Don't do this for the rest of the flight!" I'm a bit baffled about how the previous flight had the problem, apparently misdiagnosed but resolved it, and the new crew had the same problem but was unable reso…

I would guess the previous flight's pilots had the same initial 'pull back' impulse but then reverted to their training and followed the checklist after that.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#44

Post by LoSboccacc » Mon, Feb 04, 2019, 4:39 PM UTC

CydeWeys wrote: post #8

rocqua wrote: post #6

Earlier quoted context omitted.

One interface change was the effect of 'pulling hard back on the stick' in case of runaway stabilizers. That worked with the old system, but not with MCAS. This seems to be exactly the interface change that lead to the crash.

To use a car analogy ... You can always override cruise control by stomping hard on the brake (like to avoid an imminent crash). That's how it's always worked and you've gotten used to this, and done it on occasion when warranted. Now imagine that the next generation of adaptive cruise-control/"auto-pilot"/whatever comes out, and stomping on the brakes no longer does anything. You have to first disable the cruise con…

> That's how it's always worked and you've gotten used to this

but still, instead of going trough the full checklist they stopped and tried repeatedly whatever fixed the issue in the past/on the simulator.

a more complete analogy:

"follow these ten step do diagnose a bug on the software"

"but last time it was just a compilation flag, I'll check the compilation flags"

"bug persists"

"last time it was just a compilation flag, I'll check compilation flags"

"bug persists"

"last time it was just a compilation flag, I'll check the compilation flags"

"system halts"

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#45

Post by ansible » Mon, Feb 04, 2019, 4:40 PM UTC

llukas wrote: post #33

twtw wrote: post #30

Earlier quoted context omitted.

> Pilot trained this situation and plane did X and now does Y - you don't really see the problem? - now pilot has extra burden to quickly determine if something else is wrong as plane behaves differently than pilot was trained to. The pilots did not train for a specific root cause of a fault. They trained for a symptom (uncommanded nose down), and the procedure for that situation was unchanged. > extra burden to quic…

They did train recovery scenario on simulator and know how plane should behave (based on old model knowledge) - now it behaves differently. All you wrote is they should ignore it as not important detail and stick to the checklist. Unexpected situations are always extra cognitive burden.

> Unexpected situations are always extra cognitive burden.

From my perspective, it is a human factors issue that Boeing failed to consider.

Yes, the emergency procedure remained the same, but even well-trained pilots are still people. And changing the behavior of the system in such situations was not well-advised.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#46

Post by ansible » Mon, Feb 04, 2019, 4:44 PM UTC

CydeWeys wrote: post #27

lolc wrote: post #21

Earlier quoted context omitted.

From a UX perspective what should have happened is the plane telling the pilots: "I've detected the danger of a stall and corrected for it!" with the pilots being able to answer either "Ooops thank you!" but also "Don't do this for the rest of the flight!" I'm a bit baffled about how the previous flight had the problem, apparently misdiagnosed but resolved it, and the new crew had the same problem but was unable reso…

Yes, there should definitely be visual and auditory warnings as well when MCAS is engaged. When the autopilot is doing something so important as struggling to prevent a stall (and in its mind, failing, because of the faulty AoA sensor), it definitely needs to be raising alarms. Also, given how important the AoA data apparently is, it may not be displayed prominently enough. In clear weather, level flight flying, it s…

Having yet one more thing beeping / talking at you in an emergency situation isn't always the right design decision...

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#47

Post by twtw » Mon, Feb 04, 2019, 4:46 PM UTC

rocqua wrote: post #6

del82 wrote: post #4

Based only on what I read in this article, I can kind of see Boeing's point? From what I understand, the procedure/checklist for an uncommanded nose down didn't change from the old to the new version, even with the addition of MCAS. So from the Pilot's perspective, there is nothing that they should do differently in the new vs. the older 737s when this happens-- follow the checklist, which will (eventually) cause you…

One interface change was the effect of 'pulling hard back on the stick' in case of runaway stabilizers. That worked with the old system, but not with MCAS. This seems to be exactly the interface change that lead to the crash.

For reference, here is the runaway stabilizer memory item (the "checklist") for 737:

1. Control column ............................. Hold firmly

2. Autopilot (if engaged) ..................... Disengage

3. IF the runaway stops:

------------------------ [done]

4. IF the runaway continues:

STAB TRIM CUTOUT switches (both) ...... CUTOUT

IF the runaway continues:

Stabilizer trim wheel ............ Grasp and hold

EDIT:

It's #4 that's of interest here. People saying that the interface changed are saying that it's fine if pilots stop after #1, even when dealing with runaway stabilizer for 12 minutes.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#48

Post by dingaling » Mon, Feb 04, 2019, 4:49 PM UTC

PedroBatista wrote: post #31

Someone1234 wrote: post #20

Makes one wonder if the FAA is too close to Boeing. Not only did they green light this but they also put considerable pressure on EASA to do the same. The FAA's first priority should be safety, not Boeing's bottom line or their ability to more quickly deploy an aircraft update. Pilots are pretty unhappy about this M.C.A.S. situation. They're literally expected to fly an aircraft, and not even being told how that airc…

The revolving door between FAA and cushy positions at Boeing is not a secret. The shortcuts Boeing has been making with the blessing ( or willful omission of the FAA ) have been discussed but with many interests in the middle, like strong competition from Airbus, geopolitics, internal politics, States outbidding each other to create more jobs, national ego, and straight up greed. "Word on the street", is that Boeing…

The 737 models of two generations ago ( 300 / 400 / 500 ) had several fatal accidents in the 1990s due to runaway rudders. That dented Boeing's reputation with users but not with the FAA.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#49

Post by Someone1234 » Mon, Feb 04, 2019, 5:03 PM UTC

twtw wrote: post #47

rocqua wrote: post #6

Earlier quoted context omitted.

One interface change was the effect of 'pulling hard back on the stick' in case of runaway stabilizers. That worked with the old system, but not with MCAS. This seems to be exactly the interface change that lead to the crash.

For reference, here is the runaway stabilizer memory item (the "checklist") for 737: 1. Control column ............................. Hold firmly 2. Autopilot (if engaged) ..................... Disengage 3. IF the runaway stops: ------------------------ [done] 4. IF the runaway continues: STAB TRIM CUTOUT switches (both) ...... CUTOUT IF the runaway continues: Stabilizer trim wheel ............ Grasp and hold EDIT: It…

Accurate but irrelevant. This assumes the pilots knew they were dealing with a runaway stabilizer, and considering M.C.A.S. wasn't behaving similar to their previous training/experience/simulations with Runaway Stabilizers, it isn't clear they'd know they should follow this checklist. Now had they been actually trained on M.C.A.S. inc. faults, they may have known to do exactly this and we wouldn't even be discussing it.

This has been discussed in great detail on other flight forums.

Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark

#50

Post by twtw » Mon, Feb 04, 2019, 5:07 PM UTC

Someone1234 wrote: post #49

twtw wrote: post #47

Earlier quoted context omitted.

For reference, here is the runaway stabilizer memory item (the "checklist") for 737: 1. Control column ............................. Hold firmly 2. Autopilot (if engaged) ..................... Disengage 3. IF the runaway stops: ------------------------ [done] 4. IF the runaway continues: STAB TRIM CUTOUT switches (both) ...... CUTOUT IF the runaway continues: Stabilizer trim wheel ............ Grasp and hold EDIT: It…

Accurate but irrelevant. This assumes the pilots knew they were dealing with a runaway stabilizer, and considering M.C.A.S. wasn't behaving similar to their previous training/experience/simulations with Runaway Stabilizers, it isn't clear they'd know they should follow this checklist. Now had they been actually trained on M.C.A.S. inc. faults, they may have known to do exactly this and we wouldn't even be discussing…

It's not really possible to not know that you are dealing with a runaway stabilizer. MCAS (and every other automatic system to adjust trim) causes large physical wheels at the side of the pilot's knee to spin.