This appears to answer the question of why, given that there is a "memory item" for dealing with runaway trim that would have helped, it wasn't followed by the crew:
> “They didn’t seem to know the trim was moving down,” the third source said. “They thought only about airspeed and altitude. That was the only thing they talked about.”
If this is true, not only did the pilots not realize the trim was the cause of the dive and try to fix it, it seems that they didn't even realize the trim wheel was moving.
"Runaway trim" would be something they trained for, but has a presentation so vastly different (of a visibly spinning trim wheel causing quick descent) as to not be recognizably the same emergency to these pilots.
Of course, this crew had no way of knowing that there was a system on the plane that could slowly make erroneous trim changes over a long period with autopilot off, and it makes sense that they might miss it happening while focusing on their stall alerts and speeds and trying to come up with an explanation and also trying to retain control.
Was the trim wheel not visibly spinning out of their control? Simply because the symptoms are different should mean that stopping it via taking manual control is a recurring option.
Exactly. It was not "runaway" in the sense of "continuously doing the same." Something was happening, from the point of view of the pilot and co-pilot "at random." (Not to mention that on the previous models exactly such pattern was effectively impossible to happen). The faulty non-redundant sensor was producing false reading and that was the input to the to the pilots completely unknown MCAS which then moved the nose down based on the difference between the input and MCAS' expected target, turning "the correction" on only from time to time.
The presence of the third, off-duty pilot on the flight before additionally explains even better how in that case the crash was avoided. While the pilot and co-pilot were at the controls, the third one, looking from behind, didn't have the direct duties to do, so he had enough time to both just observe everything that was going on and the less immediate stress to allow him to come to the solution that worked.
Like when one programmer spends half an hour on something "not working" and complains to the colleague who just takes a look and immediately sees what the first one hasn't for half an hour. Additionally the movement of the trim wheel is actually easier to follow from the place in the back (see https://news.ycombinator.com/item?id=19440045 ).
And there's also a possibility that the false sensor reading and MCAS together produced a slightly different differential signal which resulted in more obvious manifestation of the problem. Possibly both elements contributed to the lucky outcome in that previous flight.
In the old times of civil aviation there was the third person on duty in the cockpit, the "flight-engineer." As the planes got more computerized controls, they started to be certified to fly with two-pilot crews. The computerized systems, when working, do reduce the chance of the crash and overall number of accidents did decrease simply because the humans were on the average less often in control, and therefore there was less chance to do anything wrong.
The problem is when the unreported computerized controls secretly depend on the single sensor that can be faulty. And when they actively confuse the pilot and ruin the flight instead of helping him.
Yes. The ratcheting sound is deliberate, so the pilots don't need to see the wheels spin to know the trim is running. Also note that there's a white stripe on the wheel so it's easy to see it is running.
You'll note in that video, the left-hand pilot has a headset on, presumably the right-hand pilot does too. Headsets are seen in other videos [1] of the cockpit.
So even if the spinning trim wheels make noise, they may not have heard it.
(My google image search shows some pilots wearing two-ear headsets, some wearing one-ear headsets, some wearing two-ear headsets with side not on their ear, and some not wearing headsets. But some of those are pilots posing for photos, and presumably pilots don't let people visit the cockpit during critical stages of the flight)
I don't understand do you think they're listening to music or something?
Having a headset on doesn't stop you hearing noises in a cockpit. How did you think all the other verbal alarms and callouts worked if they can't hear anything?
If the deliberate clack of the trim wheel also goes into the headphones then why are we having a discussion about whether headphones stopped them hearing the deliberate clack of the trimwheel?
Noise cancelling headphones would still let you something clicking right in front of you. In fact, open-back noise cancelling headphones would be better to wear than something that just muffles the noise if you need to hear your environment but just want to cut out the hum of the engines.
I'd imagine that that would be less common (or at least, they would use headphones with a lesser effect) with commercial jets. They're far enough from the engines that the noise should be pretty tollerable.
I doubt it would have been "out of control", it would have just been slow changes over time as trim increased. The pilots might not have been fighting it much either, if they thought that airspeed was the problem, and not pitch.
Thanks! Page 23 of the PDF or 14 as printed at the bottom. Sadly it's hard to compare with the previous flight (pg. 25 or 16) as for it they published the graph of the whole flight instead of only the part until the (at the time still secret) MCAS was turned off (or probably more correctly, the motor controlled by the MCAS, which actually steered the "trim").
Part of the problem is that the MCAS system has a 20-second delay after the last time the pilot touched controls for the flaps, and it adjusts itself to a new position and then stops. There are no other indicators that it's happening, and since it's noncontinuous and has a delay, it would be easy to miss the only visual sign of the trim wheel readjusting itself once, especially since the wheel itself is by the pilot's thigh outside of forward line of sight.
In a normal runaway trim situation, by comparison, the trim wheel continues obviously spinning as long as the problem is going on, so it only takes a single glance at any time to notice it.
I'm not sure that's accurate. Other descriptions of the MCAS system state that it will continually modify the trim on the horizontal stabilizer for up to 10 seconds at a time.
To summarise; MCAS will trim the Stabilizer down for 10 seconds (2.5 deg nose down) and pause for 5 seconds and repeat if the conditions (high angle of attack, flaps up and autopilot disengaged) continue to be met. Using electric pitch trim will only pause MCAS, to deactivate it you need to switch off the STAB TRIM SUTOUT switches.
Well, the point is that the experience from MCAS trying to be clever and subtle is very different from what one would expect in an old-school runaway trim situation caused by, say, a stuck relay.
Easy to chase down a wrong line of inquiry when the symptoms only appear sporadically and can be temporarily stopped by a whole range of actions that won't permanently fix it.
To my understanding, the trim wheels are moving frequently for small adjustments -- and it's possible to switch the wheel movement off if this becomes too annoying.
Also not a pilot but I don't think you can switch the wheel off. You can, however, disable the electric motors that spin the wheel, which is what the checklist for runaway trim tells you to do, and what was supposed to have been done here.
The spinning wheels are directly connected to the stab trim via cables. If the trim motors fail, the pilots can turn those wheels by hand (there's a folding crank on them) to manually adjust the trim.
It's running for 10 seconds at a time for 2.5 units of trim out of a possible ~15. That's quite a big trim change. I find it hard to believe that it's not noticed because of the 'boiling a frog' situation.
It not possible to disable wheel movement. It's mechanically linked to the jackscrew.
The Lion Air directive has instructions on page 41 of their preliminary report that include:
5. If the runaway continues after the autopilot is disengaged:
STAB TRIM CUTOUT switches (both) ... CUTOUT
If the runaway continues:
Stabilizer trim wheel .... *Grasp and hold*
This may be an overabundance of caution, or to cover other runaway events, but it reads like "you may need to physically fight the computer even when it has been disabled". Not exactly heartening.
EDIT: A comment below points out haptic feedback to disengage as a reason to grab-and-hold.
That's incorrect, these have haptic feedback, once you grasp it, it's not going to fight you. It looks for resistance and if it sees the resistance it doesn't continue.
Really? Here's a video of someone doing it, and it certainly looks like it tries to fight you (and the trim motor continues running) but there's a clutch that starts slipping:
This is not true, on the released FDR data, it shows clearly that the pilot flying corrected the MCAS system's trim down adjustments at every cycle (each 10 seconds) for most of the level flight. So at least the PF must have been aware of this. It's a bit weird if they didn't talk about it though, maybe it was obvious to both pilots and they were concentrating on if they were keeping altitude and airspeed at all (the most important factors that would keep them flying).
This got my attention too. For at least 6 minutes, the crew were coping with the problem - the aircraft was holding altitude and speed, if erratically, and they must have been getting the trim back to approximately where it should have been, or else MCAS would have driven the stabilizer to the point where it overrode the elevator authority.
In about the last minute of that recording, the pattern changes: the pilot trim inputs decreased and became much shorter, and the stick forces changed from going up and down to a sustained, high, back-force.
The article says that near the end, the captain handed over control to the 1st officer so he could look for answers. I am speculating wildly here, but could that coincide with the change in the pattern of the pilot's responses? Could it be that the 1st officer did not attempt to re-trim, or did not do it completely? Did he try to trim manually, but perhaps could not because of the load on the stabilizer? [1]. IIRC, according to Dominic Gates, it would only take two cycles of MCAS intervention until the stabilizer had reached a point where full nose-up elevator could not keep the airplane level.
The chart was published in one of Dominic Gates' Seattle Times articles, but I am not in a position to find it right now...
Anyone who's ever piloted an aircraft would try to re-trim against pitch forces. It's inconceivable that the pilot for some reason just failed to do that. I'm not sure exactly what force it takes to get full nose up elevator at flying speed but it will be in the range of dozens of kilograms.
I personally wonder if there is potentially a thermal cut-off on the trim motor which could have been activated by this trimming and re-triming. Or even an outright failure of some part of the system.
I just had a better look through the graphs in the report and I can see exactly what you are talking about. There is a clear pattern of trimming against the MCAS, then just before the speed increases and the altitude decreases the pattern changes. There are still nose up trim commands but much shorter. At that point the pitch trim position changes and never recovers to the same point where the aircrafts height and speed had previously been relatively stable.
Also notable is that engines spool-up about the same point to what looks like full takeoff thrust.
They must have identified an issue just after going flaps 0 because there is no other reason to go to back to flaps 5 (which incidentally disables MCAS). Why on earth they didn't drop flaps again and head back to the airport is a bit of a mystery to me.
I can't imagine the Captain handing control of a aircraft which was obviously a handful to a co-pilot and then looking straight down at the checklist, surely he'd have given guidance about the trim and waited to ensure the co-pilot was handling the aircraft?
I'm just wondering: it looks like the absolute trim angle is not visible anywhere in the cockpit? The trim wheel takes multiple revolutions to adjust trim between min/max limits, so looking at the wheel itself, you can only every see changes, not values. Unless you notice the change while it happens, you won't have any indication as to the unusual trim angle?
Thinking about that I wonder whether there was even a measurement signal that the computers could rely on to determine the current state of the trim angle in absolute terms.
Given how the MCAS did incremental changes without stopping before reaching the mechanical limits, I do imagine that there might have been no hardware feedback to assess the current trim state, thereby making it impossible hardware-wise to limit MCAS to a sensible (and safe) range of angles.
[edit] Looking at the lion air crash report [1] p.14 ff it seems like also the black box only recorded trim changes, not absolute trim state.
Yes, thinking about that, not having any pilot-visible indication would be quite some point of failure at lift-off.
Still wondering whether MCAS and other automatation systems have a representation of that position indication. I can't currently come up with an idea of how to implement that in an easy, yet error-resilient way. Usually you would initially drive into a reference position, then integrate the motor's actions to arive at an absolute value, but integration would potentially add up subsequent errors, and obviously you can't re-do the referencing step while in the air.
A potentiometer (or something fancier) directly attached to the stabilizer would do it. I'm not sure if they do have one or not. They rate of movement on the stab trim is different depending on the source of the trim change so it's possible they have a PWM controller with some feedback.
Or just use an angle sensor on the control surfaces? You now have two measurements: What the computer is telling the hardware to set the angle to, what the angle actually is.
These two are very different but very important pieces of information.
That's the most amazing revelation to me so far. The same plane had an identical uncontrolled-dive problem the day before, which required an emergency power cut to the improperly-engaged motor, and somehow that incident didn't ground the plane or even result in any effective advisory to the next crew.
Further, the Bloomberg story reports:
"The Indonesia safety committee report said the plane had had multiple failures on previous flights and hadn’t been properly repaired."
Only if the faulty sensor was listed as "critical." Boeing didn't declare it as such and reported to nobody the way it was used in the unreported MCAS.
That the MCAS even exists and that a single faulty sensor was enough to mess with the flight erratically enough to confuse the pilots was somehow acknowledged by Boeing only after the first crash. It took the second crash for most observers to recognize that just blaming the pilot or maintenance won't keep the planes from not crashing.
Even if they didn't know about the MCAS, they still knew the plane had had an uncontrolled-dive problem from an unknown cause. How is it responsible to fly it without understanding the issue?
Boeing is still fully culpable, but the airline should have debugged the issue before using the plane again.
> How is it responsible to fly it without understanding the issue?
There is not only "the issue" there are a lot of "issues" happening all the time. The problem is even knowing which are "too serious." That the single faulty sensor which didn't affect anything on the previous planes could mean the difference between the life and death was specifically not reported by Boeing.
How it is responsible to certify the plane without properly analyzing the MCAS implementation?
> That the single faulty sensor which didn't affect anything on the previous planes could mean the difference between the life and death was specifically not reported by Boeing.
We're not talking about a faulty sensor, we're talking about an uncontrolled dive. The airline is not at fault for not connecting the two, but that only means they had information of an uncontrolled dive from an unknown cause, and still flew the plane.
> How it is responsible to certify the plane without properly analyzing the MCAS implementation? (...) And how it is responsible to claim "everything is OK everywhere" after the two crashes?
It's not, but that's whataboutism. Boeing's neglect doesn't excuse the FAA, and the FAA's neglect doesn't excuse the airline.
Or at the very least, entered into the aircraft maintenance log. Back in my flying days, we had to enter every issue, large or small, into the aircraft maintenance logbook, and we also had to check it before each new flight to see what other crews had experienced, and whether the fault was signed off as 'fixed' or an 'up' fault that we could take into the air with us on the next flight.
I believe the tighter turnaround times of flights these day may either mean this step is rushed too quickly or omitted altogether...
It wasn’t clear to me from the article if this was the exact same plane or merely same type.
But the hiding of this information on the initial reports of that incident suggest there might be some fear of corporate culpability. Perhaps the pilots DID log it and it was ignored and the plane was turned around and flown again with a faulty AoA and without passing on the “lessons learned”. Will be interesting as we learn more.
The same plane had an identical uncontrolled-dive problem
the day before, [...] and somehow that incident didn't
ground the plane or even result in any effective advisory
to the next crew.
This is the problem with the Boeing blame-the-pilots-for-not-switching-the-stab-trim-cutout-switches approach.
If the pilots fear near misses will be called pilot error, and they'll be called incompetent/dangerous or punished for endangering passengers, that would do a lot to discourage near miss reporting.
Not sure that follows, either theoretically or practically. Non-reporting of any observed aircraft issues puts their fellow pilots, and all other passengers, in grave risk.
A tiny shred of mutual respect for other flight crews, or for human life of passengers in general, should easily overwhelm any concern an anomaly report will harm their record.
In this case, the prior crew could've reported the problem, and their successful resolution. There's little risk of an actual malfunction requiring the emergency disengagement of normal systems being mislabeled "pilot error", especially when they made a proper recovery according to trained procedures.
For all I know, the crew did make this report, but the report failed to have the necessary impacts, in either grounding/fixing the plane or reminding followup crews of relevant emergency procedures. If that incident or prior failures weren't reported, or were reported but not acted upon, then the fault for that lies with some mix of the crews, the airline, and relevant regulators – in addition to any other failures by Boeing.
Just to be clear this is not "an uncontrolled dive problem". The amount of misreporting on this incident is maddening. When trim is adjusted you can feel it in the controls as the control stalk will put increasing pressure against you because of the trimmed controls. If you get increasing pressure on your controls the correct response is to adjust the trim to stop it. This is not a problem for any competent pilot.
Your comment reads like you're blaming it on the incompetence of pilots, although I don't think that's what you mean. Can you clarify your comment a bit more?
"The cause of the Lion Air crash has not been determined, but the preliminary report mentioned the Boeing system, a faulty, recently replaced sensor and the airline’s maintenance and training.
On the same aircraft the evening before the crash, a captain at Lion Air’s full-service sister carrier, Batik Air, was riding along in the cockpit and solved the similar flight control problems, two of the sources said. His presence on that flight, first reported by Bloomberg, was not disclosed in the preliminary report."
I wonder if it would be useful to have a mission control style setup that could be used in an emergency. So the pilot has a problem, the plane broadcasts data, humans analyse the problem, and then give advice to the pilot. The staff would specialise in an aircraft type, and do regular simulated training.
I'm trying to imagine the horror the pilots (and passengers) were feeling. Imagine your car slowly starting to shift sideways into incoming traffic, and no matter how hard you pull the steering wheel, you can't get it back. Horrifying.
This is why I refuse to listen to these things when they're released. The thought of eavesdropping in on someone's frantic hopeless fight for survival just doesn't sit right with me.
Agreed. It reminds me of the final scene of Grizzly Man, when Herzog listens to the audio recording of the bear enthusiast and his girlfriend being mauled to death. Herzog puts the headphones down, visibly shaken, and comments (paraphrasing): nobody should have to listen to that.
The girlfriend was on location and apparently the one who turned on the camera (but did not remove the lens cap, making it an audio-only recording). She was killed and partially eaten together with Treadwell.
Edit: The tape is actually owned by Jewel Palovak who this scene is also with; She's a former girlfriend of Treadwell, not his (or his girlfriends) mother.
This is the scene you're referencing [1]. You can actually see his hand shaking while listening to this. His reaction alone is enough for me not to want to hear it.
On an episode of "Air Disasters" they mentioned that sometimes pilots from the same airline are asked to listen to such recordings as part of investigations, to comment on airline specific procedures and training.
Being from the same airline, these pilots often are at least acquainted with the crew they are hearing die. The show said that sometimes after listening it shakes the pilots up enough that they soon retire from flying.
> They had control of the aircraft. The controls were never inoperative.
I think you're missing the point. In hindsight it's easy to say "this is what you could/should have done", and some are knowledgeable or lucky enough to either find the solution themselves, or have someone tell them before it's too late.
In two instances this wasn't the case. The pilots weren't able to regain control of the aircraft. And that lack of control, with the full knowledge of impending doom, must be a terrifying feeling.
One of the factors that has been quickly glossed over is the low level of experience of some of the pilots in both the Indonesian and Ethopian accidents. In the USA, due to much higher levels of experience pilots have been correcting for the MCAS actions effectively and complaining about it to NASA (in order to avoid being branded as whistle-blowers by their airlines).
You think people using the provided incident reporting anonymity scheme are... Incompetent?
Or you yourself are actually incompetent because you thought that you should comment about this without knowing that NASA runs ASRS which is exactly what this is for?
That has not been glossed over at all, people bring it up all the time, especially in reference to Lion Air. But it's not a unifying factor in the two cases. Ethiopian Airlines has a very good safety track record and I have not seen it reported that they operate with more inexperienced pilots than elsewhere.
How would it even be possible for US pilots to sustainably have „much higher levels of experience“? Do non-US pilots fly only two days a week? Do they all die before age 40?
This stereotype of dingy third-world airlines with incompetent, untrained pilots borders on racism. At the very least, one should notice that flying the world’s newest airliner in significant numbers is incompatible with one‘s preconceptions.
The first officer in Ethiopian Airlines Flight 302 was confirmed to have 350 flight hours, which is much lower then the US standard for the large carriers.
Southwest Airlines, for example requires:
> Flight Experience: 2,500 hours total or 1,500 hours Turbine total. Additionally, a minimum of 1,000 hours in Turbine aircraft as the Pilot in Command* is preferred. Southwest considers only Pilot time in fixed-wing aircraft. This specifically excludes simulator, WSO, RIO, FE, NAV, EWO, etc. "Other Time" will not be considered.
> Minimum of 1,500 hours of total documented flight time.
> Minimum of 1,000 hours of fixed wing turboprop or turbofan time.
> 90% of the flight time logged in powered lift category aircraft (e.g. AV-8B, F-35B, and V-22) will be credited to the Delta Air Lines 1,000 hour fixed wing turboprop/turbofan requirement.
> Minimum of 250 hours PIC in an aircraft categorized as an airplane.
> The flight time logged in a powered lift category aircraft cannot be credited towards PIC aircraft time in accordance with 14 C.F.R. 61.159.
> Minimum of 50 hours of fixed wing multi-engine time.
These are all pilot qualifications. The first officer was new and had ~200 flight hours. The pilot/captain had over 8000 flight hours. [0]
Look at Ethiopian Airlines own job postings![1]
>Qualifications:
Must hold a current and valid JAA/FAA or ICAO ATPL/CPL
A current 777 type rating
Minimum Flight time
*3500 hours* jet time
*2500 hours* Pilot in command on jet aircraft
Command time in excess of 500 hours on 777
These are the minimum FAA requirements. Major airlines have higher requirements, while regionals have lower requirements.
The US is unique because flying is far more affordable and common, especially when compared to the alternative of going to a university, even a reasonable state school.
They only introduced that rule in 2013 as your link states, and it doesn't seem like most other places bother with such high requirements.[0]
"On Ethiopian flight 302, the first officer may have had just 200 hours, but the captain, a 29-year old career Ethiopian Airlines pilot, had a very respectable 8,000 hours under his belt. There’s no indication, at this point in the investigation, that crew experience may have been a factor in the accident."
I still don't see why you are harping on the experience angle when there seems to be much more evidence that the weird Boeing "secret" anti-stall system(MCAS) seems to be in play, since Boeing is trying to come up with an update for it...Also the general maintenance issues that seems to have occurred before at least one of the flights where the same issue was noted and/or the faulty sensors were ignored by groundcrew.
"French air accident investigation agency BEA said on Tuesday the flight data recorder in the Ethiopian crash that killed 157 people showed “clear similarities” to the Lion Air disaster. Since the Lion Air crash, Boeing has been pursuing a software upgrade to change how much authority is given to the Manoeuvring Characteristics Augmentation System, or MCAS, a new anti-stall system developed for the 737 MAX.
Some U.S. pilots have complained they were unaware of the new system, which is mentioned in the index of the aircraft’s full manual but not the text, according to a version seen by Reuters. Airlines have some discretion to customize the manuals.
The cause of the Lion Air crash has not been determined, but the preliminary report mentioned the Boeing system, a faulty, recently replaced sensor and the airline’s maintenance and training."
> They only introduced that rule in 2013 as your link states
The major carriers were always stricter. The 2013 rule changed to address a problem at the regional carriers.
> and it doesn't seem like most other places bother with such high requirements.[0]
Which I explicitly stated in my original post:
>>> The European carriers, on the other hand, do not have such strict requirements.
> I still don't see why you are harping on the experience angle
I weren't. I pointed out a specific misunderstanding in the comment I've responded to.
>>>> How would it even be possible for US pilots to sustainably have „much higher levels of experience“? Do non-US pilots fly only two days a week? Do they all die before age 40?
"When it was rolled out, MCAS took readings from only one sensor on any given flight, leaving the system vulnerable to a single point of failure. One theory in the Lion Air crash is that MCAS was receiving faulty data from one of the sensors, prompting an unrecoverable nose dive.
In the software update that Boeing says is coming soon, MCAS will be modified to take readings from both sensors. If there is a meaningful disagreement between the readings, MCAS will be disabled."
can't be right, airlines literally don't hire pilots with lower than required hours. they'd be sued into oblivion and their license to operate taken away if they did that. it's an ironclad rule afaik
Hypothetically, aspiring US pilots could be required to spend years flying cargo, or working abroad, or in the military, or paying $$$$ for training, to rack up the required flight hours to be eligible for US passenger jobs.
(I have no idea if this is the case or not - I'm merely saying it's possible)
Typically, it takes at least 2 years for a pilot to earn enough hours to get hired on at a regional airline in the US. Add on several more years of jet experience before you can be qualified to work at a major airline or one of the larger cargo companies like UPS or FedEx.
The U.S. is more wealthy and has a large private aviation community because private individuals can afford to buy and are permitted to fly their own small planes. As s result, it is easier for Americans to build up experience as aviators before going to work for an airline.
The other thing the US has is the 2 largest airforces in the world (The US Air Force, and the US Navy). This provides the opportunity for pilots to get a lot of flight time in jets without having to pay for it via flights schools or private aviation.
Training in simulators costs money. Just flying doesn’t prepare you for dealing with these rare situations, because most of it is autopilot/by the book.
I think your comment is out of line to accuse someone of racism. This airline has a bad record of aviation accidents, yet you would rather censure someone for simply not sharing your opinion.
No, these airlines do not have bad safety records, unless you go back into ancient history. They are licensed to fly anywhere in the world. Their safety rating is better than easyjet, Ryanair, Spirit, and Southwest: https://www.airlineratings.com/safety-rating-tool/
The continued insistence against easily checked facts proves my point.
So in other words according to your theory, Boeing has made a plane that is only safe in the hands of the best pilots? Better start cancelling thousands of orders then since by definition, at least 50% of pilots will be below average.
Should be fine for any pilot qualified by US standards. Not sure about other countries.
I have anecdotally heard that some other countries train pilots as "button pushers" without really understanding what the plane is doing or having a solid understanding of flight principles.
I don’t think there have been any reported cases where US pilots dealt with similiar MCAS issues. In fact, I’ve only seen three likely MCAS repeated nose down situations: the Lion air flight prior to the crash, the Lion crash, and the Ethiopian crash.
There was only one report I’ve seen in the NASA database related to the MAX going nose down. However, it doesn’t even appear that event was related to MCAS, as MCAS supposedly is only enabled in manual mode, and that situation happened when the plane was in autopilot. Further, the plane only dove once, not repeatedly as in Lion and Ethiopian.
A significant difference, too, is the US operators opted for the supplemental alerting package (a paid upgrade) for MCAS (see "AOA DISAGREE"). This might have made the difference on the two accident aircraft had they had that same package.
The thing I don't understand about that MCAS system is why it would continue to drive the nose of the plane down even when the pilot is reefing on the stick to pull up. The cruise control in my car automatically disengages when I hit the brakes, it doesn't continue to accelerate to keep the car going 60 while I am jamming on the brakes, in an emergency, I don't have time to find the off switch. Similarly, I would think that in an emergency, it should automatically disengage if the pilot pulls hard on the stick, in an emergency, the pilot doesn't have time to read the manual to find the off switch for the thing. It seems crazy to me that they wouldn't have a safety override like that.
Flight augmentation systems work a different way. Those take into consideration all inputs and average it out. Same when two pilots give different instructions.
> Same when two pilots give different instructions.
That's only true for Airbus (and probably contributed to the loss of Air France 447, https://en.wikipedia.org/wiki/Air_France_Flight_447). In Boeing airplanes, the movement of the two yokes is synchronized.
No, the failure mode is not two pilots consciously fighting against each other.
The failure mode is two pilots who are UNAWARE they are commanding contradicting inputs.
Airbus negligently averages these inputs. This is legacy tech debt because the physical design didn’t leave room to link the two controls.
Now they are stuck because they feel they can’t change and have some planes that (dangerously) average the inputs, and some that are physically linked.
When controls are physically linked, if one pilot thinks he should nose up, and the other tries to nose down, they can yell “what are you doing” at each other and this create an accurate mental model of what the other is intending.
Think of this every time you fly Airbus.
It’s very similar to debugging a production technology issue. Imagine you decide to restore the database to a snapshot from 1 hour ago, and at the same time someone else tries to restore to an earlier snapshot from 12 hours ago.
Should the system average these inputs and restore from 6.5 hours ago? No, obviously not.
>Now they are stuck because they feel they can’t change and have some planes that (dangerously) average the inputs, and some that are physically linked.
This is a really weird way to construe the situation. The accident report doesn't conclude that the handling of dual inputs was a factor, and it's clear from the transcripts that it wasn't. Airbus has no reason to change this.
Merely linking sidesticks would be pointless in any case, since sidesticks don't have an identifiable position (but are used with brief movements away from center). It's hardly any easier for a pilot to passively observe the movements of his own sidestick than it is just to look over at the other pilot's stick.
Did AF447 not have this warning? One of the contributing factors to the crash was the copilot continuing to pull back on the stick even as the pilot attempted to push the nose down to get out of the stall.
I answered further up but: yes, it did. The DUAL INPUT alarms were audible in the cockpit voice recording. However, unbeknowst to the captain, the co-pilot used priority takeover on his side. (This was always visible on the panel + there was an audible "Priority right" warning around the end)
I'm not sure where you're getting the "unbeknownst" from. In the cockpit voice recorder transcripts attached to the official accident reports, it seems that the pilots were aware of who had control at any given point in time.
I remember right before the impact with the water the captain finally realizing why his controls aren't doing anything and asking the co-pilot to finally let go of his stick. IIRC they never did throttle up however. Ultimately the co-pilot got tunnel vision and thought for some reason they were in an overspeed condition for most of the incident and failed to communicate that effectively with the rest of the crew. He made a couple of comments about it, but nobody else realized that he was attempting to correct for an overspeed condition in the middle of a dead stall, even when the airspeed indicator came back it seemed wrong to him because he thought they were going too fast.
The copilot actually suggested to use the airbrakes at one point.
Neither Bonin nor Robert, nor the third crew member (Marc
Dubois, the captain) who entered the cockpit 90 seconds
into the episode, recognized that the aircraft had stalled
despite multiple cues. In the confusion, Bonin
misinterpreted the situation as meaning that the plane was
flying too fast and actually reduced the thrust and moved
to apply the speedbrakes – the opposite of what was
required to recover from the stall. Robert overruled him
and attempted to take control, but Bonin continued to try
and fly the plane. He and Robert made simultaneous and
contradictory inputs, without realizing that they were
doing so. By the time the crew worked out what was going
on, there was insufficient altitude left to recover, and
AF447 crashed into the ocean, with the loss of all 228
passengers and crew.
But I've had the stick back the whole time!
At last, Bonin tells the others the crucial fact whose
import he has so grievously failed to understand himself.
I know what the Popular Mechanics article says, but I cannot find any confirmation of the key points in the official accident report, which I take to be much more reliable.
Page 28: The right-seat co-pilot Bonin says "j’ai l’impression qu’on a une vitesse de fou non qu’est-ce que vous en pensez ? "(I feel like we're speeding like crazy, what do you think?")
Page 31: Same co-pilot "mais je suis à fond à cabrer depuis tout à l’heure " (But I've pulling back completely for a while), and this while the cockpit is screaming "Dual Input" (so this means that the other pilot was inputting as well, thus "unbeknownst" in my original comment).
Same page, right after, the captain says, "non non non ne remonte plus là" (No, no, no, don't pull back any further".
If you read the entire transcript, it's clear that there was persistent confusion as to who was in control, despite the dual-input warnings. AF447 is widely considered to be a failure in CRM, and a failure to recognize that they were in an aerodynamic stall (again, despite the warnings).
They didn't trust the plane with the information it was providing, which is probably why they ignored these warnings.
>Page 31: Same co-pilot "mais je suis à fond à cabrer depuis tout à l’heure " (But I've pulling back completely for a while), and this while the cockpit is screaming "Dual Input" (so this means that the other pilot was inputting as well, thus "unbeknownst" in my original comment).
Perhaps you didn't notice this, but immediately after the point in the transcript you refer to, there's an exchange between the pilots where they establish who's in control (see "vas-y tu as les commandes" at 2 h 13 min 46,0). There is no way to be sure, but it seems probable that this exchange was prompted by the dual input warnings.
>They didn't trust the plane with the information it was providing, which is probably why they ignored these warnings.
There is no indication that they ignored the dual input warnings.
Linking the control sticks doesn't magically resolve problems caused by a breakdown in cockpit discipline. If both pilots are going for the controls at the same time, you're going to have problems. The warning system seems to have done its job, insofar as it prompted the pilots to figure out who was in control.
Oh, I don't think I alluded to linking the control sticks... perhaps you intended to respond to another comment?
As for the dual input thing, there are 6 instances of the the warning. We can't really know what the pilots were thinking, but I believe page 31, from when Bonin says, "je suis à fond à..."... and then Robert à "attends moi j’ai des j’ai des commandes moi hein" a little later, "alors donne moi les commandes à moi les commandes", and 4 warnings Dual Input between them (in the space of about a minute and a half)...
I think it's fair to say that it wasn't super clear who was in control.
I'll make no comments about which system is better since I have no direct experience of flying in such environments (have only piloted small aircraft with mirrored controls, but with clear "Commande à droite/gauche" to establish PF, with my instructor). But à priori, I would imagine both systems work fine if used well.
If they're mechanically linked, the captain would at least feel the first officer countering their inputs -- giving a prompt that they need to communicate their intentions more clearly!
I'll defer to a pilot to say whether they are mechanically linked -- it sounds like they are on Boeing aircraft but possibly not on Airbus?
They're mechanically linked on Boeing aircraft. On the 757, and I believe the rest, the mechanical link has a detent. With enough force, the pilot can move it out of the detent and move the controls independently of the copilot. The reason for this is if one side or the other is jammed, the pilot can still fly it.
No, the captain would not, because only one pilot has their hands on the controls in any given instance (with the possible exception of rotation at takeoff).
It's quite clear that wasn't sufficient. "Brief moments" during critical points in an emergency can matter enormously. From the recorder transcript:
> As the plane approaches 10,000 feet, Robert tries to take back the controls, and pushes forward on the stick, but the plane is in "dual input" mode, and so the system averages his inputs with those of Bonin, who continues to pull back. The nose remains high.
02:13:40 (Bonin) Mais je suis à fond à cabrer depuis tout à l'heure!
But I've had the stick back the whole time!
02:13:42 (Captain) Non, non, non... Ne remonte pas... non, non.
No, no, no... Don't climb... no, no.
02:13:43 (Robert) Alors descends... Alors, donne-moi les commandes... À moi les commandes!
Descend, then... Give me the controls... Give me the controls!
> Bonin yields the controls, and Robert finally puts the nose down. The plane begins to regain speed. But it is still descending at a precipitous angle. As they near 2000 feet, the aircraft's sensors detect the fast-approaching surface and trigger a new alarm. There is no time left to build up speed by pushing the plane's nose forward into a dive. At any rate, without warning his colleagues, Bonin once again takes back the controls and pulls his side stick all the way back.
See in particular 2 h 13 min 39,7 and 2 h 13 min 40,6. Both of the pilots at the controls thought that they needed to climb. The captain realizes the mistake, but he's not at the controls, so linked sticks would have made zero difference to his perception of the situation. The accident report concludes that the stall was probably unrecoverable by this point anyway.
The section I'm citing is right there on page 31 of your second link. See 2 h 13 min 39,7. More dual input at 2 h 14 min 03,2. Crash at 2 h 14 min 28,4.
That is the point where both pilots at the controls still think that they need to climb. The captain, who realizes the mistake, is not at the controls, so whether or not the side sticks were linked would have made no difference to his perception of the situation.
The official report does not identify the side sticks as a factor in the accident.
If you think you can do a better job of identifying the cause of the accident than the professionals who investigated it, you should explain clearly why.
With regard to dual input, it's clear from the transcript that the pilots noticed the dual input alarms.
The same applies to the trim in a 737 and any other transport class aircraft. If you move the control column in the opposite direction of trim, the electric trim and autopilot trim will cut out. The same applies to the autopilot in all types I've flown, it disconnects if you override it manually (except for CWS mode, but that's known and expected)
I don't fly the 737, so I haven't read the aircraft specific books and systems overviews, but I expect this override behavior is very confusing in the MCAS scenario. Because any pilot would counteract a nose-down force by pulling on the yoke. The MCAS would then stop moving the trim, and the pilot would think (as would be true in any other situation) that the override worked. But MCAS didn't stop because of the override, it stops because it always does that after a few seconds and will re-activate 10 seconds later (or 20, didn't read a definitive number on this).
The confusing thing is that 95% of the unwanted trim movements are caused by the autopilot, so at this point the pilot would think the situation is under control and probably disconnect the autopilot if the movement didn't already,
The other 5% (or probably less) of unwanted trim movements are trim runaway, which is either a stuck switch (2 actually, you depress two switches at once to make it move, pressing 1 does nothing) or an electrical problem.
In both cases pulling back works and stops it. If it stays "stopped" you think autopilot and leave it disconnected. If it keeps moving continuously you think trim runaway and flip the trim cutout switches or pull the circuit breaker (this one is usually marked bright orange so you can find it quickly in planes without cutout switches)
But in the MCAS case, and without MCAS knowledge (which apparently nobody had) you would not expect it to start moving again later. You would have concluded "autopilot" of the above two scenarios, and after disconnect would think you're safe. So now when it starts moving again, your first idea is that the autopilot did not disconnect which leads to even more confusion in the cockpit.
The LionAir flight that was saved by the jumpseater got lucky in the sense that this guy was not flying, not debugging the autopilot, and did see the trim move because he has no instruments to scan and the trim is right in front of his face (in the middle between the two pilots). If you conclude that the issue is the trim, then any pilot would decide to go for the cut-out switches. It's just that concluding the trim is the issue, without knowing MCAS, under high pressure and with the wrong (autopilot) conclusion already on your mind is not very likely.
Why didn't the pilots adjust the trim manually? I don't understand how any pilot would consider increasing control pressure to be normal and not automatically respond by manually adjusting the trim.
> It's just that concluding the trim is the issue, without knowing MCAS, under high pressure and with the wrong (autopilot) conclusion already on your mind is not very likely.
Since MCAS and autopilot are two different things and MCAS is only active when autopilot is off I think it is faulty to assume that something that disables autopilot would disable MCAS--but in the heat of the moment I can see room for confusion.
The point in that the Lion Air pilots had no way to know of the very existence of MCAS, and therefore thought that the autopilot is the only system on the plane capable of issuing intentional trim changes, and therefore that disabling it would stop them.
> why it would continue to drive the nose of the plane down even when the pilot is reefing on the stick to pull up
well this other crash was caused by a pilot puling up a plane all the way to its ceiling and stalling it, so there's that, so things can go wrong whether if you do and if you don't allow for easy control overrides.
the trick seems to find the right balance to relinquish control only when appropriate, so it seems that proper documentation, checklists, training and maintenance are crucial.
instead looks like to have had deficiencies in all those elements, one way or another (except the checklist itself which wasn't followed).
The AF 447 crash is one of the reasons MCAS was created. It's the exact scenario MCAS was designed to prevent: High altitude, high-speed, nose-up stall. This was more likely than the NG and dinosaur generations of 737 due to the engine relocation forward and up (causing a pitch-up moment due to thrust).
AF 447 should never have happened. The copilot crashed the plane, and the pilot and pilot on break had no indication or feedback that he was holding the stick back (crashing the plane by causing a stall). There was no feedback, and the controls deferred to his inputs when the pilot was trying the opposite command (which would have saved the flight). On top of this, the stall warning buzzer was turning off when they were so deep into the stall that the airspeed dropped below a certain threshold, and every time the nose was pitched down and airspeed increased, the buzzer came on again.
Airbus has a controls feedback, stall buzzer parameters, and training problem. 447 should never have gone down.
There was both an audio and a visual indication of DUAL INPUT (light on the panel + "dual input" announced verbally). The co-pilot commanded priority take-over (from the pilot, who had just second previously done the same) without announcing it. This would have been clear if they looked at the panel that shows which side has priority, but in that confusion, their attention would've been elsewhere (airspeed and bank angle mostly).
>There was no feedback, and the controls deferred to his inputs when the pilot was trying the opposite command (which would have saved the flight).
I've never seen a reliable source for the claim that the two pilots at the controls were pushing the stick in opposite directions for any extended period of time. What's the primary source for this info?
MCAS strikes me as the low airspeed variety of stall risk case. The high airspeed case is rare, and trained for aerobatics and flight instructors. The low airspeed case is taught on day 2 to student pilots, both power on and power off varieties. MCAS is reported to not take airspeed into account, therefore it must apply a one size fits all correction, which if useful for low airspeed approach to stall would seem to be overly aggressive for high airspeed.
AF 447 airspeeds were regularly below 60 kt. That's not a high airspeed stall. The final report is ~223 pages long, it's rather complicated to summarize, BEA blame practically everyone for something including weather, software, simulators, training, and pilots. As a pilot, some of the Airbus system behaviors in this case really piss me off to read, just how aggregiously badly designed it is when it gets confused, papered over by dumping the consequences of failed automation and the ensuing alternate laws onto the pilots. The pilots' job is system admin and troubleshooter. If they fail, they will be partly blaimed no matter what, because that's the job.
From the AF 447 final report: a) Both pilots were shocked by the autopilot disconnect. b) Reconnect of autopilot prior to 30 seconds of stabilized airspeed indication can result in pitch runaway and an unsafe condition. c) stall warning sounded continuously for 54s, neither pilot referenced the warning or stall buffeting. d) absence of any training, at high altitude, in manual aeroplane handling and in the procedure for ”Vol avec IAS douteuse” which you allude to. e) theoretical training for the pilots associated the buffet with stall and overspeed, even though in reality buffet is only encountered with stall. e) when there are no (software) protections left, the aeroplane no longer possesses positive longitudinal static stability even on approach to stall.
It's just crazy, only somehow partly neutralized by the statistical fact air travel is still really safe!
AF 447, last recorded values were a pitch attitude of 16.2 degrees nose-up, roll of 5.3 degrees to the left, a vertical speed of -10,912 ft/min, ground speed of 107 kt, and full power. And for the last 11 seconds "sink rate" and "pull up" warnings sounded. No emergency transmission sent (quite common).
What I don't understand whenever I read anything related to the MCAS system is why does it not check if the plane is in a dangerous nose dive using other sensors the plane might have? Does the average plane not have a gyroscope? My sub 500 dollar phone has both a gyroscope and an inertial measurement unit (accelerometer).
I agree, but I see the reasoning. MCAS failure leads to runaway trim for which there is an established and well known procedure to fix--in the checklist almost 50 years. For a problem with trim you flip the trim cutout switch. Doesn't matter if the problem stems from MCAS, autopilot, crossed wires, the magentic pole flipping, jammed electric motor, whatever.
It's like explaining to a computer user that rebooting will fix aproblem--they don't need to know the exact cause but just how to recover from it.
It's worse than this. MCAS is designed to only look at one of the two AoA sensors. If this happens to be faulty, it doesn't know, because it's not comparing the sensor to the other one. Instead of a system which can notice and account for disagreeing sensors and fail gracefully, we have a system which is a designed single point of failure and fails... lethally.
You can't handle faults with only two sensors since you won't know which one to trust. At least three would be needed for a minimal level of redundancy.
Electronic gyroscopes measure rotational speed. In order to measure orientation you need to integrate over time and align it with a reference frame, typically by estimating gravity using the accelerometer. An inertial measurement unit has both of these.
Cheap phones often don't have gyroscopes but still are able to rotate your screen orientation based on the accelerometer.
The spinning-disk ones kind of do, they aim to keep their orientation, but they also need gravity or so for initial alignment/realignment (otherwise things would get funky when you make a trip around the earth, since technically your plane is upside down if it would fly halfway around the earth ..)
Note that AoA and the angle of the airframe body (relative to the horizon) may not be the same. Even if the airframe is pointing downwards (below the horizon) or really high up doesn't mean the wings have a sufficient AoA to generate lift.
No, because you can stall a wing at any attitude realtive to the horizon. It isn't about the pitch of the airplane, it's about the relative airflow over the wings.
So if you're falling quickly the airflow comes from "below" which causes a high angle of attack even if the nose is pointing level compared to the horizon.
I'm doubtful. Consider this: the aircraft can experience a downward acceleration (eg. due to turbulences) without being in a stall. Measuring the AoA is still the most reliable way (assuming the sensor itself is reliable) to detect impeding stall.
That's a very interesting thought. How would you do it? You can only sense the acceleration - if it's lower than 1G you're falling. The angular momentum doesn't actually tell you anything in an aircraft.
I wonder if it's possible to estimate the local air speed based on ground speed (GPS) and local weather data (can we measure wind speed at altitude?).
Pitch (q) is not the same as angle of attack (alpha). You can detect q with a gyro, but not alpha. I use this helpful graphic with my students: https://i.stack.imgur.com/A62jW.pngyQ.jpg
Best book I've ever read on the root cause ("tight coupling") of accidents: https://en.wikipedia.org/wiki/Normal_Accidents
From its Wikipedia entry:
>"Normal Accidents: Living with High-Risk Technologies" is a 1984 book by Yale sociologist Charles Perrow, which provides a detailed analysis of complex systems from a sociological perspective. It was the first to "propose a framework for characterizing complex technological systems such as air traffic, marine traffic, chemical plants, dams, and especially nuclear power plants according to their riskiness." Perrow argues that multiple and unexpected failures are built into society's complex and tightly coupled systems. Such accidents are unavoidable and cannot be designed around.
His analysis also applies to anesthesia disasters, I learned the hard way during my 38 years in the O.R. Highly recommended.
I think this perspective on accidents needs far more emphasis.
Many accidents are unavoidable and not the result of some person failing to do some thing.
The world isn't a story, people don't have much agency, and events do not happen because people want them to.
These "narrative explanations" are mythological just-so stories that attribute the complex interaction of systems to individuals, organizations, etc. in naive agency-based ways.
Yes, but, its no excuse for relaxing operational rigor. Those who fail to learn from history are doomed to repeat it. And if you repeatedly ignore the lessons of experience then you are to blame.
This is the issue I have with the media - moreso than any particular bias, media loves to paint a narrative when, in truth, random events are more likely to blame (though in fairness this is a human flaw borne from the heuristic value of narrative). Accidents happen in complex systems - rather than burning the people involved at the stake, we should recognize the inherent complexity of safety hurtling an aluminum tube full of humans through the air at just below the speed of sound, review the accident in a calm and sober fashion, and make the necessary changes to prevent a similar accident in the future
the more I grow, the less I understand why medias.. if twitter and facebook are dopamine abusers, traditional medias are also a kind of drug, mild intensity, but drug still
Oh, let's be calm and sober about this, and passively accept the existence of accidents rather than re-examine organizational, business, or economic premises. So much easier to blame the media.
Craven excuse-making and responsibility avoidance at its worst.
No. You chose to start out pointing the finger of blame at the media and adding a vague statement about fixing the issue is mere lip service.
You now go to the opposite extreme, employing the fallacy of the excluded middle and emotive language like 'brutal punishment' to invalidate an argument that was never made.
Your dishonesty only highlights the weakness of your position.
The HN discussion of this issue is fairly revealing in that it points towards the people on this site wanting a simple explanation with a short list of people to punish, when it is more likely a long list of small details with many people who might have made relatively minor mistakes or simply not foreseen the issue in question. Working in IT (and also formerly at Boeing, so there's some crossover in experience), I find this unsurprising, as IT systems become more and more complex the answers are not "theres a bug in Vendor X's product" or "system Y was misconfigured" but a long litany of small errors, oversights or unforeseen issues that culminated in some larger issue. It does not help that many of these people are unwilling to adjust their conclusions based on emerging evidence. Fortunately in aviation there is a culture of understanding all the details of accidents, identifying all the possible improvements and implementing them. I suspect that the IT industry is on the verge of a crisis as I don't see this sort of attitude prevalent in it, which is funny because lots of the terminology and some of the techniques are common, just not the culture.
For context, I'm a licensed pilot and my father spent most of his career working at Transport Canada, basically Canada's FAA. So this is one of those topics I probably know more than the average HNer about.
What I've noticed more broadly is that there are lots of people on HN with high general intelligence who believe it automatically translates to specific domain knowledge in aviation, medicine, etc., when if quizzed they would likely know far less than they believe they do.
So when it comes to quality improvement, for example, they likely haven't spent time at a car factory, or at a Boeing plant, and understand it via bastardized analogies (i.e. Kaizen in software development really isn't the same as in manufacturing) rather than domain expertise. Deep domain expertise is difficult to obtain unless you're really immersed in an industry.
The desire to "make someone pay" when errors happen is antithetical to a culture of quality improvement. The accident report for the Lion Air incident actually paints a picture of a complex failure rather than simply being the fault of the software, but that doesn't really get reported on.
Hence my issue with the media. Inflammatory headlines and speculation cause people to believe they know more than they actually do about something, and the public pressure drives action that may be totally inappropriate.
Do you feel this way about repeat occurrences? Is this an appeal to the reader's sense of fate/destiny?
I work in telecom. When a aReallyBadThing happens, a post-mortem has to be compiled, and steps are taken to ensure that aReallyBadThing doesn't happen again. There are unavoidable perils in telecom, like backhoe operators, weather, train derailments, and malicious actors. However, there are events which do not repeat because people figure out that a software/firmware package is coded to do something wrong, a component fails under certain conditions, an operator does something that they shouldn't, or maintenance isn't done correctly or on time.
I cannot recommend this book enough. I will also point out that some sections of it are highly entertaining. In fact, the tanker collision chapter is laugh-out-loud funny.
I can see how a single instance of a particular accident type might be unavoidable, but every subsequent accident attributable to the same cause(s) is absolutely avoidable.
>The manufacturer has said there is a documented procedure to handle the situation. A different crew on the same plane the evening before encountered the same problem but solved it after running through three checklists, according to the November report.
How did the pilots not think about trim controls... This is BASIC piloting. If you are experiencing pressure on the control stick you adjust trim. How were the pilots this inept?
The book "Aviation Psychology: Practice and Research" by Klaus-Martin Goeters is an eye opener on the problems that the architects of complex control systems that interface with humans must take into account.
And the kind of problem that MCAS exhibited is clearly explained in the book.
The book doesn't talk only about control system design, but also about training, hiring, etc.
>> On the same aircraft the evening before the crash, a captain at Lion Air’s full-service sister carrier, Batik Air, was riding along in the cockpit and solved the similar flight control problems, two of the sources said. His presence on that flight, first reported by Bloomberg, was not disclosed in the preliminary report.
Like that bug that there's only one person in the company who knows about and how to fix it, but she's always working on something else? That's just awful.
Wow. This is a failure from so many parties. The pilots for not knowing the correct procedure. Boeing (who should bear the majority of the blame) for allowing sensors that are not properly redundant, purchasing sensors that appear to fault on a regular basis, not properly training, and not making sure that a problem that was well understood can never happen again, the airline for not informing the next crew of problems from previous flights, the regulators of the United States and Ethiopia for allowing these mistakes to happen.
We should look at the root cause, which is Boeing installing much more powerful engines on an old frame that wasn't designed for it. They haven't properly done it.
The previous flight had exactly the same issue. This is what that pilot wrote in the logs;
After parking, the PIC informed the engineer about the aircraft problem and entered IAS (Indicated Air Speed) and ALT (altitude) Disagree and FEEL DIFF PRESS (Feel Differential Pressure) light problem on the Aircraft Flight Maintenance Log (AFML).
The PIC also reported the flight condition through the electronic reporting system of the company A-SHOR. The event was reported as follows:
Airspeed unreliable and ALT disagree shown after takeoff, STS also running to the wrong direction, suspected because of speed difference, identified that CAPT instrument was unreliable and handover control to FO. Continue NNC of Airspeed Unreliable and ALT disagree. Decide to continue flying to CGK at FL280, landed safely runway 25L.
STS is the speed trim system. The pilot didn’t explicitly note that they set STAB TRIM to CUT OUT to correct the problem, perhaps because he thought it was obvious?
But then reading the log of the previous flight;
After three automatic AND trim occurrences, the SIC commented that the control column was too heavy to hold back.
At 14:25:46 UTC, the PIC declared “PAN PAN” to the Denpasar Approach controller due to instrument failure and requested to maintain runway heading.
At 14:28:28 UTC, the PIC moved the STAB TRIM switches to CUT OUT. The PIC re-engaged the STAB TRIM switches to NORMAL, but almost immediately the problem re-appeared. The PIC then moved the STAB TRIM switches back to CUT OUT and continued with manual trim without auto-pilot until the end of the flight.
This implies it took almost three minutes for the previous crew to figure out the STAB TRIM needed to be CUT OUT after finding the trim is so wrong that they can’t hold the stick back.
Clearly this is not a memory item for these pilots.
I haven't checked but I'd bet STS is speed trim system (Aka Mach trim). Interesting that he came up with a reasonable mental model of what was wrong even though Boeing hadn't given them any details.
MCAS problems weren't a memory item for any pilot, the memory item is Runaway Stabilizer and exhibits different behaviour to MCAS.
Which is to say that they'll be receiving sim training for Runaway Stabilizer, learn what to expect (wheel moves continuously, hard nose down, etc), and then in real life have MCAS cause the same issue but in a substantively different way (change, delay, change, delay, etc).
Without the benefit of hindsight why not try the Memory Item: Engine Surge / Stall or Uncommanded Roll? Both of which could exhibit as an uncommanded nose down.
The reality of the situation is that some pilots immediately went straight for Runaway Stabilizer whereas others did not. That's a problem. That's a TRAINING problem. The type rating should have included additional training against the Runaway Stabilizer Memory Item for MCAS so "I've seen this before" is second nature.
Isn't the root problem still related to the fact that the AoA sensors were returning wrong information and the MCAS was simply reacting to that in a dangerous and non-obvious way?
I guess the pilots should be aware of this type of system reaction but still it seems like something that should be fixed at a higher level than training (indicators, backup AoA sensors, detecting dangerous descent after trigging nose down, etc).
There's never just one cause of an airline accident. That was one of the causes, but alone it wouldn't have been sufficient. Fixing the problems at all levels is how you achieve high reliability.
Seems like it would have been sufficient to cause the crash, or are you saying that if the pilots let MCAS do its thing that the plane would not have crashed?
3. Boeing design changes (MCAS used to be disabled automatically if the pilot applied sufficient counter-input, this feature was removed in the -MAX series, requiring the pilot to explicitly disable the system using a separate button)
Take away any 1 of those causes and the plane doesn't crash. They all had to happen at the same time for these two tragedies to occur.
FAA pushed much of the safety analysis to Boeing engineers due to lack of funding and external pressures to help Boeing speed through certification.
The safety analysis was performed on incorrect data. The initial safety report said the MCAS system could lower the nose by 0.6 degrees. After flight testing, that value was increased to 2.5 degrees but the safety analysis was never updated to reflect the new parameters. Additionally, the MCAS system could reset each time the pilot attempted to override, and it could change 2.5 degrees for each reset. So effectively it was unbounded. The numbers on the safety report did not reflect the actual system. If the real numbers had been updated, the problem likely would have been caught sooner.
Presumably so that the pilot can be blamed for not knowing the procedure to manually disable the automatic system that is flying the plane into the ground.
Those fixes are inarguably lower level than training. Not just to be pedantic but the whole reason Boeing is in this mess is because they figured all the lower level things could sort out issues, without engaging higher level fixes.
I'm skeptical of the amount of automation the big manufacturers are pushing. They're creating wildly more complex system interactions in the process.
> skeptical of the amount of automation the big manufacturers are pushing
We need to come to terms with automation as a civilization, lots of things that had a human in the loop will no longer have that person in 0-15 years. We don't realize how important these people are, esp their inaction and delay are very important at damping oscillations. As these automated systems start interacting they will have similar results as the MCAS but without pilot agency.
Look at the panic stops built into financial markets, what systems should have similar that currently do not?
I agree it is a training problem, but it also seems the case that some pilots understand the fundamentals of flight and how a plane operates than others. So when a plane misbehaves, some pilots may have an intuitive sense of what to do, while others are stuck pattern matching and running through checklists.
To make a terrible analogy that trivializes the complexity of flying a jet (because I can't think of a better one), it's like the difference between a chef who knows how to combine ingredients to get the desired result and a cook who only knows how to follow a recipe.
I agree with this and want to expand: Following a recipe == auto pilot; reacting to deviations from the expected / working with new realities == chef (not cook).
The whole point of still having humans in the cockpit, aside from being slightly cheaper than automation right now, is the ability to react to and correct for the unexpected. I agree that this is a terrible engineering design, but that it's only one of the contributing factors. Disasters (nearly always) happen when a string of things go wrong, and safety is about making sure every one of them goes right so that the chances of failure are as close to eliminated as possible.
One of the issues I'm perceiving with the Strings Of Things that Go Wrong / Swiss Cheese model is that as we fix more and more of the ~more likely~ faults to appear, the faults that will continue to appear will be of the less likely variety, so to say more obscure corner cases.
The problem is that training cannot efficiently prepare somebody to identify and fix obscure corner cases while under pressure.
The reason some of this automation exists is because modern airplanes have, extremely rough corner cases.
In particular, the very thing that is causing the MAX incidents is one of those features that is designed to ADD stability.
The main issue however is that the system is both reading too few external sensors, and is also not reacting to contradictory human inputs.
An ideally designed system might have the following features:
* Read data from ALL installed sensors that might be applicable.
* If data from sensors is not within a reasonable bound,
scream bloody murder about that for a human to make a decision.
* If human input contradicts the intended direction of the plane,
scream bloody murder about that for a human to make a decision.
Potential decisions might include designating one or more inputs as faulty, or entirely disabling the function in question. Such an operating mode SHOULD be an exception and should be very obvious for anyone looking at the plane / systems.
One wonders, when the prior flight landed with the stab trim system switched off, who switched it back on before the next departure? And was there no question raised as to why it was off?
It's not normal to have that system switched off at any time. There are even guards over the switches to ensure they are only operated deliberately.
They should have given the incoming pilots a thorough briefing of: this is what went wrong, this is how the previous pilots worked around it, this is what we did to remedy.
It probably is a memory item, but it's not something they got to immediately, and I'm guessing here because runaway trim symptoms are slightly different to what MCAS was doing.
This happened to me a while ago involving trim, and I'll try and go through my thought process and why it takes a little while in the cockpit to figure things out:
- Autopilot is engaged, holding a heading of X, altitude of Y and I've got a power setting for speed Z
- My hands are off the stick, and I'm planning the next 20 mins of the flight.
- The nose has slowly started creeping downwards, I don't notice until I look up a few seconds later
- I glance at the altimeter and see we're now Y-300ft, and descending at 500ft/min.
- I check the altitude hold on the autopilot flight director; see yes, it is still set to Y, and am rather confused, as the stick is fairly pulled back to pull the airplane up (autopilot), so the pitch hasn't changed that much.
- Airspeed is slow, and I'm even more confused - how are we both descending and slowing down.
- Glance over to the passenger, she's fast asleep, a bit restless but not touching the yoke or rudder.
- ATC comes over the radio asking if we're descending and what our intentions are.
- It's only been about 30 seconds but we're now Y-900feet, at a decent rate of of -1400ft, the AoA indicator is starting to beep as we're now in the warning arc, speed is Z-20kts.
- Unsure of what's actually happening, I push in full mix/throttle to keep our airspeed up.
- I grab the stick (already fairly back) and attempt to get us level.
- Tell ATC over the radio I'm having difficulties with the autopilot as I disengage it.
- Feel an immediate / tremendous force on the stick pulling it forwards, have to use both hands to keep it back.
- I'm now wondering if the elevator control is broken.
- Try to start trimming it back (electronic trim), but a warning flashes on the instrument panel.
- Electronic trim usage also immediately disables the autopilot completely, so the wings are now rocking too, giving a weird sensation as I feel like I'm fighting the controls.
- Reach over to the trim wheel, realise the passengers knee is propped on it.
- Move her leg out of the way, and start wheeling it back and feel pressure easing on the stick.
- Keep trying to use the electronic trim and it kicks in, and I can see the trim position on the panel (set pretty far forward).
- Aircraft is now finally level, airspeed is increasing. Elevators / pitch control feels normal.
- Set airspeed for best rate of climb, and tell ATC I'll level off at my previous altitude. Put us into a climb.
- Re-engage the autopilot and all seems well
That was about a minute and a half. I went from 8500ft to around 6800ft in what felt like a few seconds, and it's only after I was in the climb that I realised her shuffling was knocking the trim wheel around. She had been probably doing it for the better part of an hour, and the autopilot had been opposing her inputs. I didn't pick up on the airspeed changes as we're a slow plane flying into a strong headwind so I expected to not be flying the usual speeds.
I pored over the Pilot Operating Handbook that day, and also the Garmin G3X/GFC500 to figure out what was happening and to understand the systems. The trim wheel itself doesn't disengage the autopilot, only the electric trim control does. When the servo motors can't engage (too much force), the system just shows a red X on the instrument display where the control display would be. Etc etc.
The 737MAX pilots don't have that luxury, as they're told it's just a 737 type.
Go through the above scenario, but have no knowledge of the fact that theres something moving the trim. You do not have the luxury of altitude, nor airspeed. The sensors are providing weird inputs. Plus, everything is happening around 10x faster, not a slow build up. You reset the trim, all is well for a few seconds and bam, nose down again. Reset again, it happens again. If I don't know about the MCAS, the 5 sec delay etc, my immediate thought is a faulty computer and I'll try and restart it. And so forth.
Thank you for a pilot's perspective. Here's my bit of confusion though. Once you realized the stab trim was the issue, you were able to reset it and get back to normal flight. Had the problem recurred that flight, you'd probably have recognized it immediately.
In the Lion flight, the pilots realize the stab trim is off because they correct it. Once they realize that, regardless of what keeps setting the stab trim to pitch down, and even if they've forgotten there's cut-out switches, why don't they keep resetting the stab back to 0? And how do they not eventually notice the stab wheels turning?
It's almost as if the pilots weren't even aware of the stab wheels and stab indicator, and how those related to the electronic trim switch and the stabilizer itself. But I can't beleive that.
The thing that would be most helpful is knowing what their mental model of the plane was, but I'm not sure the investigation will be able to tell us that.
- I’ve just taken off, and am going through the after take off checklist: Set the airspeed, power, climb rate, heading, talking to ATC, planning the next stage of the flight
- Perhaps I’ve just raised the flaps and the plane starts behaving erratically
- My first / immediate thought is that my previous action led to an undesired aircraft state.
- I work from that point on
- I touch the electronic trim as habit, which resets the system briefly, and all seems well for a few seconds. I don’t know that the system reset itself.
- It goes all weird again all on its own
- Now I’m even more confused
Etc
Edit: I'm a low time private pilot flying a LSA, I genuinely don't know the procedures or processes in place for a 737, but I can empathise with their situation as I know how quickly things can go start going amiss in a plane.
I think that, not being a pilot, I can't really understand, but thank you again for the perspective.
Edit: one last thing though - when the plane isn’t behaving as expected, why isn’t the first thing to check that all the control surfaces and the throttle are where you expect them to be?
Of course - generally the expectation is that control surfaces will not move on their own accord, unless specifically asked to; either directly by the pilot by moving the yoke/stick, trim wheel, rudder etc, or indirectly by setting the autopilot, which in turn moves those controls.
If they move on their own accord - usually via autopilot - it's because they are trying to maintain a reference point the pilot asked them to.
When they move on their own accord, outside of any pilot inputs or settings, without the pilot knowing / understanding why, that's where the issues start happening.
Air France AF447 entering Alternate Law, Lion Air MCAS activating etc.
The initial course of action is always to return to stable flight, disabling whatever systems you perceive to be changing the control surfaces. When you just don't know which system is causing the issue, then you're just fighting the end result (eg nose down), not the underlying system issue (eg MCAS preventing stall by enforcing trim).
To find the cause of the end result (eg nose down), you work backwards to see what happened - because, chances are, you as a pilot made an erroneous setting / configuration somewhere to cause an undesirable aircraft state, not the system itself, as you are taught the system works under your command, plus no system acts to down an aircraft - they are all there to prevent an aircraft from getting into an undesirable state. You go back to the last known working configuration, and work from there to diagnose.
Long winded answer, but yes, you do check control surfaces, but they only show an undesirable aircraft state which can be corrected (eg pull back on the stick), but it doesn't solve for the what and why, and thus preventing getting back into that undesirable state. Trim is also one of those ones right at the bottom to check, as it's for fine-tuning an aircrafts pitch - where an elevator can move an aircraft up or down tens of degrees in a seconds, trim usually only moves the pitch tenths of degrees.
This is also where SOP's and training come in too - some airlines would have "set landing trim" on the final leg of the approach, others might have it on the base leg. Some companies require stall training in the sim once a year, other airlines don't even have sims. Some airlines are okay with reverse thrust on landing, others want to avoid wear and tear on the engine and want you to slam the brakes. The aircraft manufacturer would have their "recommended" training, and modify it in accordance to company practices / requirements, legal / regulatory frameworks etc.
From what I understand, and this is just from reading the news and forums, there was no knowledge or training about the MCAS system. The closest thing is a runaway trim, and again this probably differs from airline to airline.
All aircraft, pilots have a checklist of things - takeoff, landing, recovering from various undesirable aircraft states etc. Occasionally you do hit an edge case where a lack of knowledge and training collide with a background-running aircraft system acting out of the ordinary.
Again - I'm just a private pilot so do take the above with a grain of salt, Airline Transport Pilots have far more training and experience, and can probably provide a far better insight to the behaviour of larger jets, difference between companies, SOP's etc.
> - My first / immediate thought is that my previous action led to an undesired aircraft state.
FYI This is shown in the Lion air preliminary report.
They select flaps 0 (from flaps 5) and a few seconds later reselect flaps 5. Unfortunately a while after that they decide to go to flaps 0 again. With any flaps selected the MCAS system is disabled.
Yeah, I can imagine. I mentioned elsewhere, the previous flight managed to develop a reasonable mental model (they thought that the Mach Trim System was responding to a wrong airspeed input). Saying that, failing to guess what's going wrong shouldn't result in a big hole in the ground.
This is pretty interesting if you haven't seen it before:
I had an autopilot/trim issues once on the approach right after FAF in solid IMC (later turned out that one of wires got loose). Similar symptoms as above. I didn’t debug anything, simply killed AP, and hand flew the rest of the approach. It was exactly the response my instrument instructor trained me to do and he was very happy when I discussed it with later.
Are the logs you're referencing a public resource? Would be interesting to look at.
>This implies it took almost three minutes for the previous crew to figure out the STAB TRIM needed to be CUT OUT after finding the trim is so wrong that they can’t hold the stick back.
I've seen a number of references to difficulty that pilots encounter managing forces of the flight controls in airliners. It seems strange to me that modern aircraft of that size would be designed in a way that aerodynamic forces on control surfaces would be allowed to translate back to control inputs in a manner that could overpower a pilot. I would think there would be some kind of scaled assist mechanism (ala power steering) in scenarios where there is a mechanical/hydraulic link. I'm guessing fly by wire scenarios wouldn't have this problem?
The scaled assistance you're referring to is the hydraulic system.
Airplanes are supposed to be light-touch because you need very fine movement control to balance the aircraft while landing. Think of the work required to move a pencil. That's about the level of effort a plane is supposed to require. But with the trim working against the pilot, the control required could be more like lifting a 50lb sack.
Yes, most pilots can lift a 50lb sack. Can you lift and hold a 50lb sack for, say, an hour? Not many people can.
(Without hydraulics, the forces would simply toss the pilot's body around. No possibility of control.)
Also worth noting that the reason we don't simply scale the forces down to the point a pilot could easily handle them is that above manouvering speed an aircraft can be damaged by full control deflection.
Good point. This is something I bet most non-pilots don't know. A pilot can actually damage or destroy an airplane through control inputs alone. In fact there was a case of a pilot intentionally destroying his airliner by rapidly slamming the rudder back and forth, but I can't find the flight reference now. And there are other examples, such as AA flight 587 where the large control inputs were causal in the crash that killed all aboard.
Again we are seeing a more systematic issue that commercial pilots don’t have stick and rudder skills. Automation has taken over 95% of the job. They push the throttles up to take off power, pull back on the stick, and then punch the auto-pilot and sit back and enjoy the ride. Then they don’t fly or input anything into flying until landing where they again fly the plane for the last 3-5 minutes of the flight. I would be interested to see the experience level/age of the pilots. As I think the retiring generation of pilot was much more equipped to deal with this type of issue. Then the new generation of pilot. I included an article lamenting this decreased skill we are seeing. It’s refering to the Miracle on the Hudson. But I think it applies here as well. [1]
Afaik autopilot has always played a large role, I used to have a few beers, amoungst company, with a retired SA first officer or engineer - someone in the cockpit anyway, they basically mastered sleeping upright once they reached desired altitude, helpful as they were all hungover as fuck. I'm sure they were all capable though. Autopilot handled 95% of flight even back then - 20 years ago I'd gather given his age. Wasn't a bullshiter about anything else so I'd (I at least) take his account as accurate, esp when hearing about the arms cargo etc.. and meeting other pilots that would visit
This is rather inflammatory at best, and pretty derogatory to the vast majority of pilots who spend upwards of $100,000 to gain the skills necessary for an ATPL, spending anywhere from 1000-2500 hours flying aircraft older than yourself using technology that predates WW2, and even WW1 in some cases. Stick and rudder skills is all you have to get through the first 100 or so hours of your flying career.
What you're seeing is a consequence of companies willing to skimp on training and certifications, pressuring authorities and manufacturers to find workarounds, and keeping the folks actually flying the thing in the dark about it.
The MAX has larger engines than previous 737s, and they are in a slightly different position. As a result, the plane has a tendency to pitch its nose up. To keep that from getting out of control if pilots flying manually aren’t attentive, MCAS automatically pushes the nose down if the sensor says the nose is too high.
In other words, Boeing fixed a hardware flaw with software. I am no aeronautical engineer, but this seems wrong to me. The hardware needs to be correct in and of itself. The software layer should be for enhancing the capabilities of the hardware, not for fixing fundamental flaws in hardware.
Not a really a hardware flaw--a design choice/hardware compromise so that existing 737 infrastructure could be used. The low ground clearance of a 737 is one of its main selling points. It's customers have a large investment in infrastructure around this capability--Think of things like loading ramps, luggage carts, servicing vehicles, etc.
So in other words they designed it this way in order to make the 737 MAX is cheaper to operate, and therefore easier to sell. That's terrible. Boeing traded off safety for profits.
Yes cost is a factor. The alternative might not be feasible economically. I don't think the failure here was reusing the 737 design, but the downstream due diligence of implying no significant changes. I also think airline training is a factor--both Boeing for the new systems and the airliners because runaway stabilizer trim has been in the aircraft emergency checklist for over 50 years and every pilot should know it. That same procedure would have saved these planes.
Sacrificing safety in order to reduce cost is unjustifiable. When you design a multi-layer system, the higher layers should be for enhanced functionalities, not for fixing flaws in lower layers. Boeing designed flawed hardware (yes, it was intentional but that doesn't mean it is not a flaw) and tried to fix the flaw in software.
Then Boeing supplied a flight manual that a pilot described as 'inadequate and almost criminally insufficient', in order to convince customers that moving from older 737s to the MAX does not require extensive retraining. All in all, there is ample evidence that Boeing put profits above safety.
> I also think airline training is a factor--both Boeing for the new systems and the airliners because runaway stabilizer trim has been in the aircraft emergency checklist for over 50 years and every pilot should know it. That same procedure would have saved these planes.
While training is absolutely one (of many) factors in these crashes, it's worth noting that while the runaway stabilizer checklist response would save this plane, the symptoms of this runaway MCAS issue DO NOT MATCH those of a "normal" runaway stabilizer as pilots train on it in simulator.
Essentially, pilots are being called upon to recall a trained response based on input which is significantly different from any that they've seen in training. Other flight logs on Lion Air prior to the crash show that even when the pilots correctly hit upon flipping the stabilizer trim cut out, it took them minutes to realize that was the solution, and they only fully confirmed that when they tried turning it back on, experienced another pushover, and then cut it out for good.
Boeing's assertion that there was no need for additional simulator training for the Max series is clearly incorrect -- even in non-fatal incidents pilots have demonstrably and in multiple cases not been able to correctly recognize the MCAS runaway as a kind of Stabilizer Runaway without spending time searching for and running multiple checklists.
What's more, this software fix depends on 1 out of 1 sensor inputs. There's no redundancy or conflict detection, if the pilot is flying the plane it uses the sensor on the left, if the copilot is flying the plane it uses the sensor on the right. This is a safety-critical system with absolutely no redundancy at all.
(Boeing would sell you a third AoA sensor and the AoA Disagree readout as an optional upgrade though! So it's not like they didn't think about it, they just didn't care enough to include it in the base spec.)
AvE over on youtube has some speculation about what caused these crashes, and sums it up with: This was clearly a training issue, but now everyone is talking about it and every pilot is going to have this at the top of their mind. Would I hesitate to get on a Max 8 right now? Not for a second, pardner.
It's like how right after a bad health dept report is probably one of the safest times to go to a particular restaurant.
This problem specifically only manifests when the autopilot is off. It's designed to prevent the pilots from stalling out the airplane without realizing it, which only happens in manual flight. Enabling the autopilot cuts out MCAS.
> “They didn’t seem to know the trim was moving down,” the third source said. “They thought only about airspeed and altitude. That was the only thing they talked about.”
If this is true, not only did the pilots not realize the trim was the cause of the dive and try to fix it, it seems that they didn't even realize the trim wheel was moving.
"Runaway trim" would be something they trained for, but has a presentation so vastly different (of a visibly spinning trim wheel causing quick descent) as to not be recognizably the same emergency to these pilots.
Of course, this crew had no way of knowing that there was a system on the plane that could slowly make erroneous trim changes over a long period with autopilot off, and it makes sense that they might miss it happening while focusing on their stall alerts and speeds and trying to come up with an explanation and also trying to retain control.
reply