Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
1–10 of 83 posts
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#2Boeing 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 been more vocal in expressing the fault outside of just a post-flight note about it.
The fact that the 737 can auto-trim itself beyond manual elevator authority, due to a SINGLE faulty AOA sensor, is mind-boggling and scary.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#3> 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.
The one thing that seriously surprised me was that an automated system that is able to point the airplane towards the ground is intentionally fed by a single, non-redundant sensor.
Everything else I've read about various safety systems that limit or override the pilot has explanations about how redundant sensors are used. And how the system does switch itself off in case the sensors don't give consistent results.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#4Based 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 to flip the Stabilizer Trim Cutout Switches, and that will fix the problem.
So the interface didn't change, and the procedure's the same. Should Boeing and airlines update training every time they change something "under the hood", even when the procedure for pilots is the same? How about when they make software updates to already-flying models?
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#5> 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. The one thing that seriously surprised me was that an automated system that is able to point the airplane towards the ground is…
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.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#6Based 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.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#7Based 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.
That's fair, but what does the checklist say? I mean, say there are a thousand different malfunctions that could cause an uncommanded nose-down. This one happens to be #359, but the pilots don't know that, they just know that they're pointed at the ground. Maybe it used to be the case that the first item on the checklist (pull back on the stick) fixed problem #359, and now it's the second. But there are several hundred other malfunctions that might have caused the problem that also aren't solved by pulling back on the stick, so the next move is to go to the next item on the checklist, right?
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#8Based 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.
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 control by pressing a button on the steering wheel, and only then will inputs to the brake pedal do anything.
And then you don't tell drivers about this change.
You can totally see how, right in the lead-up to a fatal accident, a driver is going to be focused solely on stomping on that brake pedal in increasing panic, wondering right up to the moment of death why that's not doing anything. They won't consider the cruise control off button because it's not their most immediate need (braking is), and they've never needed to use it before.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#9> 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. The one thing that seriously surprised me was that an automated system that is able to point the airplane towards the ground is…
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.
Re: Behind the Lion Air Crash, a Trail of Decisions Kept Pilots in the Dark
#10> 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. The one thing that seriously surprised me was that an automated system that is able to point the airplane towards the ground is…
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 as public documentation... but it may have been intuition earned through experience overriding standard procedure.