Live data from Hacker News

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

nytimes.com

21–30 of 83 posts

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

#21
post #9
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…

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?

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

#22
From the article: "In designing the 737 Max, Boeing decided to feed M.C.A.S. with data from only one of the two angle of attack sensors at a time, depending on which of two, redundant flight control computers — one on the captain’s side, one on the first officer’s side — happened to be active on that flight."

They created a single point of failure that way. Why?

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

#23
post #15

There's something called the "Swiss Cheese Theory" of accidents. ( https://en.wikipedia.org/wiki/Swiss_cheese_model ) In a mostly-robust system, different layers catch and defend against the errors of other layers in the system. For a major accident to occur, holes in multiple layers have to line up that day. In this case we have four holes that lined up that day - a plane model with a possible rare software bug, an…

Still, to have a system on board that, with one sensor malfunctioning, repeatedly trims you down (unless you switch the cutout switch or physically arrest the trim-wheel), is pretty tough. By the way - in small airplanes, you can overcome trim with elevator pressure. That's not necessarily the case on a passenger jet; and not only because it's much bigger, but because the trim works differently [1]. I wonder whether…

Yeah, when the trim is a giant screw changing the angle of the whole stabilizer, rather than just a little tab, it's a whole different ballgame.

There are plenty of single components on an airliner whose failure can cause a stabilizer trim runaway. Different airliners handle it differently. On a 737 can you can cut out automatic control, and use wheels connected to the stabilizer jackscrew with metal cables. On other airliners, you can cut out automatic control, then switch second electric control system and use it manually. A 737 stabilizer runway isn't an instant thing, and is a loud event in the cockpit.

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

#24
post #22

From the article: "In designing the 737 Max, Boeing decided to feed M.C.A.S. with data from only one of the two angle of attack sensors at a time, depending on which of two, redundant flight control computers — one on the captain’s side, one on the first officer’s side — happened to be active on that flight." They created a single point of failure that way. Why?

Cost cutting. The article points that picture quite clearly. They created the whole MCAS system to mitigate problems with the aircraft's design in a very short span of time, and needed the whole thing to be cheap.

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

#25
Here's a video from a few years ago of two student pilots handling a trim runaway in a 737 simulator.

https://www.youtube.com/watch?v=3pPRuFHR1co&t=154

You'll notice that it's a loud, physical event, with a very simple solution.

This happened over twenty times in the accident flight, and the pilots never disabled the problematic automatic stabilizer system.

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

#26
post #8
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…

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 be expected to do one thing with increasing desperation is essentially arguing that they will not be able to respond to a whole host of emergencies causing uncommanded nose-down.

Second,

> Information from the flight data recorder shows that the plane’s nose was pitched down more than two dozen times during the brief flight, resisting efforts by the pilots to keep it flying level ... The standard checklist for dealing with that sort of emergency on the previous version of the 737 focuses on flipping the stabilizer trim cutout switches and using the manual wheels to adjust the stabilizers. [emph mine]

your argument essentially hinges on the assumption that pulling hard back on the stick is a sufficient solution for all the problems that may happen with a plane with the exception of a fault with MCAS (the new system). I don't think that is accurate. Even prior to the the 737 max! It sounds there were a lot of things that would require further action that pulling back on the stick.

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

#27
post #21
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…

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.

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

#28
If it affects flight stability especially in an emergency, then pilots should be trained to understand what it affects. Period. Not doing so to save money or get more sales is beyond stupid. Watch Air Disasters to see what happens when highly trained pilots fail to do the right thing because they hadn't trained to deal with what went wrong because the problem was something different than what they knew. Flying is easy when things are working, pilot training is the difference between dealing with an emergency or being dead.

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

#29
post #22

From the article: "In designing the 737 Max, Boeing decided to feed M.C.A.S. with data from only one of the two angle of attack sensors at a time, depending on which of two, redundant flight control computers — one on the captain’s side, one on the first officer’s side — happened to be active on that flight." They created a single point of failure that way. Why?

By having each redundant flight computer hooked to completely different sensors, in case of a bad sensor the crew can bypass not only the sensor, but also any computation done with that sensor.

It's not a single point of failure as we think if it - if it starts acting up, you can easily disable the automatic stabilizer system, per the procedures. 737 stabilizer runaways take several seconds to take effect, and are recoverable afterword. Later you can switch flight computers and then be using clean data, though you are supposed to leave the stabilizer system off for the remainder of the flight.

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

#30
post #18
post #14

Earlier quoted context omitted.

But the difference is not only do the pilots of a commercial airliner have vastly more training and experience than your average driver, but they literally have a list of things to try (and extensive training on following the list) in the case of a malfunction like an uncommanded nose-down. Imagine that the failure that caused the nose-down wasn't a failed AOA sensor giving bad readings to MCAS, but some other reason…

More training and experience is a problem as previous plane model behaved differently. 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. And you are writing this after many, many accidents that root cause was pilot not exactly knowing what o…

> 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 quickly determine if something else is wrong

This isn't an extra burden. Pilots aren't doing root cause analysis for failures while they are responding to them. They are trained to try actions in a specific order until something works. It's not like the checklist used to have one action on it and now it has two - the solution in this case was a standard action on the standard checklist.

Pilots do not look around, say "ah, electrical short in elevator actuator" or "ah, bad angle of attack sensor" and then take a single action.

Post reply on HN