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

#71

Post by rocqua » Mon, Feb 04, 2019, 7:40 PM UTC

BlackFly wrote: post #10

rocqua wrote: post #5

Earlier quoted context omitted.

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 man…

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…

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.

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

#72

Post by loeg » Mon, Feb 04, 2019, 7:40 PM UTC

twtw wrote: post #56

loeg wrote: post #51

Earlier quoted context omitted.

Drivers aren't trained to follow checklists and usually don't have dozens of seconds to respond to mechanical emergencies. Cars also don't fall out of the sky if they break down. It's not a great metaphor.

> have dozens of seconds to respond 12 minutes, in this case.

Yeah, I figured it's usually many minutes but didn't want to underplay the stress and difficulty of following a checklist in an extreme emergency. In contrast, car major mechanical failures generally resolve themselves extremely quickly.

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

#73

Post by kelnos » Mon, Feb 04, 2019, 7:48 PM UTC

BlackFly wrote: post #10

rocqua wrote: post #5

Earlier quoted context omitted.

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 man…

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…

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.

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

#74

Post by cmurf » Mon, Feb 04, 2019, 7:52 PM UTC

poof131 wrote: post #39

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…

From the article: "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 pilots to control them manually. That feature was disabled on the Max when M.C.A.S. was activated — another change that pilots w…

There's a Faustian bargain made by accepting so much abstraction from the true nature of an airplane by using software, and yet also that abstraction is not absolute. Pilots are made responsible for knowing all of the aircraft's behaviors, with full abstraction (normal mode), as well as partial abstractions (error and failure modes, of which there can be quite a few for a specific made/model, many of which must be inferred rather than being clearly displayed). If pilots get confused, however complicated and unintuitive the system behavior, they are blamed.

The more "piloting" computers are doing, it seems appropriate that they will be increasingly, properly, accused of the equivalent of "pilot error". And yet here is Boeing, taking more and more piloting responsibility, while still blaming the pilots when that doesn't work out. It's a deification of engineering: when things go properly and safely, praise engineering; when things fail, blame the pilots.

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

#75

Post by sokoloff » Mon, Feb 04, 2019, 7:55 PM UTC

sokoloff wrote: post #58

twtw wrote: post #50

Earlier quoted context omitted.

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.

And these large wheels have small bell/clackers on them so you get a distinctly audible signal in addition to the large black wheels with white stripes on them.

Here's a video of the wheels in motion: https://vimeo.com/34501723

Disregard the text on the video description as it's blatantly wrong (describing that the trim tabs still move without the wheels moving; wrong on two accounts: the trim doesn't move without the wheels moving and the 737 uses a jackscrew for horizontal stabilizer trim rather than trim tabs [which is why the pilot can't simply override the aerodynamic force as they could with a trim tab])

Jackscrew operation: https://www.youtube.com/watch?v=rxPa9A-k2xY

The 7-3 has balance tabs to make the control forces lighter in the event of a hydraulics failure, but these are not trim tabs in any sense of the word.

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

#76

Post by twtw » Mon, Feb 04, 2019, 8:26 PM UTC

CydeWeys wrote: post #67

poof131 wrote: post #41

Earlier quoted context omitted.

> 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.

It's still more Boeing's fault than anyone else's though. They were the ones who made this change and then tried to hide it to the fullest extent possible, so that it wouldn't trigger mandatory retraining.

> and then tried to hide it to the fullest extent possible

I haven't seen any evidence of this. It's definitely not supported by this NYTimes article.

Do you have a source?

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

#77

Post by rocqua » Mon, Feb 04, 2019, 8:55 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…

As I read the article, it seemed like before, step 1 would suffice before. If this is not the case with MCAS, it could at the very least throw the pilot's diagnostics. "Is it runaway stabilizers? Well, no response from holding the control column firmly so I guess not. Lets check other things".

Sure, the correct response is to follow the checklist, but should we really rely on pilots always knowing the correct response? Especially when that goes against their previous experience? Not that I am defending these pilots not knowing the checklists, instead I am arguing we should take into account learning from experience rather than theory.

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

#78

Post by rocqua » Mon, Feb 04, 2019, 8:58 PM UTC

lozenge wrote: post #69

peteradio wrote: post #52

Earlier quoted context omitted.

Who knows? Have you ever been taught an undocumented procedure by the expert and been told to use it regardless of what the manual states? Happens all the time? Is a pilot in a position to affect Boeing beauracracy?

Sorry but how could Boeing design any plane if they can't assume pilots will follow the manual or any checklists?

By including features in the manual. The alternative is that they don't, people rely on the features, they change the features without notifying anyone, and when shit goes wrong they can say "It wasn't documented: shouldn't do that".

The real question here is how commonly this feature was used. If it was common, then not putting it in the manual is a big problem!

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

#79

Post by Animats » Mon, Feb 04, 2019, 9:35 PM UTC

kirykl wrote: post #57

Animats wrote: post #36

Earlier quoted context omitted.

Using only one sensor at a time, there's no "sensors disagree" fault to tell the pilot there's a problem. Or to tell the flight control system it shouldn't be taking drastic action based on that sensor. Airbus uses three angle of attack sensors and compares them. They've had at least one crash when two sensors failed in a consistent way.[1] The vulnerability of aircraft flight control systems to bad AOA data is well…

There wasn't a "sensors disagree" alert in the Lion Air plane because they didn't have installed the optional AOA Disagree indicator. As comparison, Southwest had the indicator but has now also installed an enhanced AOA Disagree indicator as a result of the Lion incident https://theaircurrent.com/aviation-safety/southwest-airlines...

That's not a feature which should be a extra cost option.

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

#80

Post by kelnos » Mon, Feb 04, 2019, 9:36 PM UTC

extrapickles wrote: post #62

eternalny1 wrote: post #2

Boeing should face some major fines for this, and additional regulation is going to be needed to make sure this doesn't happen in the future. This all seems to come down to the fact they wanted to avoid having to retrain pilots ($$$), so these automation changes were kept in the dark. The crew before them dealt with this same problem but they successfully cut out the trim system. They got lucky and they should have b…

From what I can tell, the previous crew did not get lucky, they just followed the checklist which would have solved the issue in this case. Auto-trim beyond the elevator authority is not a problem as the pilots can take manual control of the trim by grabbing the trim wheel (its in a very obvious spot on the 737). The actual fix is hard as adding another alarm can get tricky from a UX perspective during an emergency.…

There already is another alarm: an optional "angle-of-attack disagree" indicator that Lion Air was apparently too cheap to install.

Now, that wouldn't have directly pointed to what was wrong, but it would have been pretty suggestive.

(I would suggest, though, that having an optional configuration that lacks robustness for a system that can automatically point the plane toward the ground... a really poor choice of options.)