[acqq]

> The training says to stop that by throwing the stab trim cutoff switches. They're prominently located on the center console.

Not so. First: before Lion Air accident, nobody knew there is a new device that can move the controls that way under these conditions (in that phase of flight etc). The whole device was kept secret by Boeing. Second: the pilots had the trained reflexes what they are to do, and with these, there are more steps to try to overcome such movements before the decision to use the switch. And that’s exactly what the pilots did: attempted the steps before. Which seemed to help, but MCAS kept misbehaving. As the seconds matter, then it was to late.

[WalterBright]

In the Lion Air crash, they struggled with the issue for 11 minutes, not a few seconds. The Ethiopian one, over 6 minutes.

The reason the stab trim cutoff switches are there is so the pilot can stop runaway trim. The switches are prominently placed.

I expect the failure of the pilots to throw those switches to be prominent in the eventual NTSB report on the accidents.

The second accident would be especially perplexing because surely the pilots would have known about the Lion Air crash. If I was a 737MAX pilot, I'd be keenly interested in other crashes in the same aircraft, so I could ensure it wouldn't happen to me. Wouldn't you?

[acqq]

How your “11 minutes” claim fits to this:

https://www.nytimes.com/interactive/2019/03/13/world/boeing-...

Have you seen the graphs? There are 20 seconds intervals. They “fight” the plane, then something (the investigation is still on what) makes it worse again.

That’s what confused the pilots: the misbehavior repeats after they think the plane returned to normal.

[WalterBright]

Yes, I've seen the graph. They had minutes, not seconds.

[acqq]

In which they thought each time „it‘s OK now.“ That‘s not what they were trained for, that a device can turn itself against them on again and again.

[WalterBright]

I beg to differ. If I had an intermittent failure that would nose the airplane down, you bet I'd turn it off. I wouldn't want it to happen when I was close to the ground. I would have shut it down the second time it happened.

It's like if an engine is on fire, and I shut down the engine, and the fire goes out. There's no way I'm going to think "It's OK now, I can restart the engine." No way in hell.

[acqq]

I think you still observe this with the benefit of the hindsight of what you know already killed 350 people.

However:

https://news.ycombinator.com/item?id=19420964

"pilots and aviation experts say that what happened on the Lion Air flight doesn’t look like a standard stabilizer runaway, because that is defined as continuous uncommanded movement of the tail."

"On the accident flight, the tail movement wasn’t continuous; the pilots were able to counter the nose-down movement multiple times."

"In addition, the MCAS altered the control column response to the stabilizer movement. Pulling back on the column normally interrupts any stabilizer nose-down movement, but with MCAS operating that control column function was disabled."

And do you really agree with the simplified interpretation like:

https://news.ycombinator.com/item?id=19424761

"two pilots fell out of the sky to their deaths and it simply never occurred to them to try pulling back hard."

I still believe that the way the airplane behaved in these two cases was exactly the opposite of what the pilots have been trained in their flights and in the simulators, and that the behavior was counter intuitive and unexpected to them and that that is the only reason they weren't able to save themselves.

Good UI is not trivially obvious. And it really makes a difference between the life and the death in certain use cases. And thinking about something in the safety of your armchair is very different from "having the plane that is doing exactly what you don't expect and then you die." The plane behaving the very way you haven't been trained in the simulations before.

Finally, I believe that all the issues reported here

https://www.seattletimes.com/business/boeing-aerospace/faile...

contributed to the manifestation that turned out to be deadly:

"The safety analysis:

- Understated the power of the new flight control system, which was designed to swivel the horizontal tail to push the nose of the plane down to avert a stall. When the planes later entered service, MCAS was capable of moving the tail more than four times farther than was stated in the initial safety analysis document.

- Failed to account for how the system could reset itself each time a pilot responded, thereby missing the potential impact of the system repeatedly pushing the airplane’s nose downward.

- Assessed a failure of the system as one level below “catastrophic.” But even that “hazardous” danger level should have precluded activation of the system based on input from a single sensor — and yet that’s how it was designed."

Interestingly and tangentially, the software people particularly like to blame the user. I've worked in many teams wit more people almost automatically dismissing any user input. But the users are, in fact, typically right in a sense that they often have the real world problems that are simply not recognized by the designers/developers assuming infinite knowledge and the infinite time the user has.

[chopin]

Problem is it seems that it is necessary to offload the stabilizer to be able to trim back. That means pushing the yoke probably being already close to the ground.

[WalterBright]

> Problem is it seems that it is necessary to offload the stabilizer to be able to trim back.

The stabilizer trim motors are very powerful and do not need to be offloaded in order to work.