Hacker News new | ask | show | jobs
by rocqua 2696 days ago
There is one more technical surprise in this article for me. Pulling hard back on the control collumn would override the stabilizer runaway in old versions, but not MCAS. That is a major interface difference between the old and new planes.

It sounds like the old flight manual stated one of two possible methods for dealing with runaway stabilizers. Because the second method (hard back on the control) wasn't in the manual, changes to that way weren't taken into account. Hence a non backwards compatible change slipped through.

2 comments

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 resolve it. How's it possible that the plane takes corrective action without telling the pilots? It's not like getting close to a stall is a routine occurrence, is it?

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.
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 should be really obvious if this is drastically wrong.

When anything in a 737 moves the stabilizers, physical wheels in the cockpit loudly turn right next to the pilots. In the case of a stabilizer runaway, it's really obvious. (See https://www.youtube.com/watch?v=3pPRuFHR1co&t=154)

MCAS is just one of many different systems on a 737 that can automatically adjust the stabilizer. Because there are so many things that could be the cause of the problem, the checklist procedure for any runaway is just to cutout automatic control of the stabilizers.

Here is Boeing official update to all 737 MAX operators after the crash, which boils down to saying "follow the checklist, dummies".

http://www.avioesemusicas.com/wp-content/uploads/2018/10/TBC...

Thanks. So that blaring and the wheels turning is what we assume happened 24 times in that cockpit before the crash?

If I understand this right the pilots must have known the plane did adjust stabilizers, but they didn't have a way of finding out why it did it. And per checklist they shouldn't have cared for the why, but just cut-out the automatic control.

Southwest has added enhanced AOA indicators to its Max fleet as a result [0].

Lion Air didn't even have the basic (optional) AOA Disagree alert[1]

[0]https://theaircurrent.com/aviation-safety/southwest-airlines...

[1]https://www.reuters.com/article/us-indonesia-crash-boeing-ao...

It makes you wonder why such a seemingly important alert is optional. Cars these days can't come without seat belts, brakes, ABS, traction control, ESC, and more, but apparently seemingly essential safety features on planes are optional??
Having yet one more thing beeping / talking at you in an emergency situation isn't always the right design decision...
From the Semver perspective, change to an undocumented (and therefore not public) feature is not a major change. The point is that their safety documentation doesn't change from one system to the next.

Anyone who was "doing it by the book" was not pulling up on the stick.

Now, maybe Boeing was suggesting via side channels that there were alternate ways to solve certain problems and those side channels should qualify as public documentation... but it may have been intuition earned through experience overriding standard procedure.

That ignores the fact that people will rely on undocumented behavior anyway, and a responsible developer should keep that in mind.

With a normal software library, you might make the decision to cause breakage anyway, even if it inconveniences users of your library. Or you might not, because you believe the inconvenience will be too great, and instead just document the behavior and make it a part of the API.

With an airliner control system, you need to be a bit more careful, since a pilot depending on undocumented behavior may do so in a way that could cost lives if that behavior is changed. Is the pilot correct to depend on that behavior? No. But that's irrelevant when lives are at stake.

This is a classic case of 'work to spec' vs 'work to practice'. Yes, people should go of the official documentation rather than what works in practice, but it is obtuse to presume everyone will do it in the same way.

Normally, I'd say that those who ignored the spec deserve less consideration. However, when that involves giving less consideration to 100+ passengers as well, that changes.