Cockpit voice recorder of Lion Air jet depicts pilots' frantic search for fix
reuters.com
reuters.com
> “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.
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.
The trim wheels moving also makes a sound?
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)
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?
I wear earplugs all day in a metal fabrication workshop.
The earplugs certainly don’t prevent you from hearing anything.
[0] https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
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.
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.
It not possible to disable wheel movement. It's mechanically linked to the jackscrew.
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.
https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
This is the future I look forward to. AI/ML/Autopilot/Companies moving fast and breaking things.... Boeing took that one literally.
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...
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.
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?
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.
[1] https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
You can see it on the copilot's side here by the trim wheel.
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.
These two are very different but very important pieces of information.
https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
AIUI, runaway trim has always been a possibility and the trim wheel design helps to surface that it’s happening.
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.
[1] - https://reports.aviation-safety.net/2018/20181029-0_B38M_PK-...
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).
If you'll excuse the expression, everyone is going to get poop on them after this one is over.
1. Faulty MCAS
2. Insufficient pilot training
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.
4. Insufficient regulatory over site
5. Failed safety analysis
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.
What was the reasoning behind this change?
I'm skeptical of the amount of automation the big manufacturers are pushing. They're creating wildly more complex system interactions in the process.
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?
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.
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.
The problem is that training cannot efficiently prepare somebody to identify and fix obscure corner cases while under pressure.
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.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.
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.
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.
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?
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.
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.
This is pretty interesting if you haven't seen it before:
>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?
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.)
The recent crash is by Ethiopian Arilines. NOT Lion Air.
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."
Lots of blame to go around here.
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.
Boeing is still fully culpable, but the airline should have debugged the issue before using the plane again.
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?
https://www.nytimes.com/2019/03/19/business/boeing-elaine-ch...
And how it is responsible to claim "everything is OK everywhere" after the two crashes?
https://www.barrons.com/articles/faa-not-grounding-boeing-73...
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.
I believe the tighter turnaround times of flights these day may either mean this step is rushed too quickly or omitted altogether...
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.
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.
"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."
His analysis also applies to anesthesia disasters, I learned the hard way during my 38 years in the O.R. Highly recommended.
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.
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.
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.
The consequences of reckless software interlocks and poorly trained operators has been known for a long time now.
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.
So in case of two equally strong and equally determined pilots you still get averaging of opposing control inputs.
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.
Why? They're not falling out of the sky so the system obviously works. Stop being a fanboy.
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.
Is there a case where the averaging of inputs has been proved catastrophic?
On an Airbus, in case of dual input the pilots get a voice alarm and a warning lights up right in front of them.
Also the stick has a switch to take priority, in case the other pilot continues to give dual input.
Source: https://www.vanityfair.fr/actualites/articles/vol-af-447-rio...
I'm not sure what you mean by "throttle up". They were at full TOGA thrust.
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.
https://www.popularmechanics.com/flight/a3115/what-really-ha...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.
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.
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.
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?
Mistakes happen. Part of aviation safety is preventing that from becoming fatal.
That's not what the accident report concludes.
There's a clearly audible "dual input" alarm to prevent dual inputs. Dual control inputs only occurred for brief moments during the AF flight.
> 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 (Robert) Remonte... remonte... remonte... remonte...
Climb... climb... climb... climb...
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.
The crash occurred less than a minute later.
https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/f-cp09060...
https://www.bea.aero/docspa/2009/f-cp090601.en/pdf/annexe.01...
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 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.
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.
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.
https://en.wikipedia.org/wiki/Air_France_Flight_447#Third_in...
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).
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.
Well, AF477 shows that sometimes you need it.
Source (in French): https://www.vanityfair.fr/actualites/articles/vol-af-447-rio...
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?
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).
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.
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.
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.
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.
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 ..)
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 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?).
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.
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.
See: https://www.wsj.com/articles/what-you-need-to-know-about-fly...
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.
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.
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.
(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.)
https://www.seattletimes.com/business/boeing-aerospace/inves...
It's like how right after a bad health dept report is probably one of the safest times to go to a particular restaurant.
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.
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.
Feels freaky like it is a living animal kept alive in an aquarium.
edit> https://www.quora.com/Why-are-black-boxes-put-into-water-aft...
They shouldn't have to do this routinely.
Also pilots should be made aware of the characteristics of the resulting mode of stabilizer trim runaway.
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.
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.
https://swa.pilotcredentials.com/index.php?a=qualifications
Delta requires:
> 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.
https://www.deltajobs.net/pilot_qualifications.htm
United requires:
> Minimum of 1,000 hours of fixed-wing turbine time
https://www.united.com/ual/en/us/fly/company/career/pilot.ht...
The European carriers, on the other hand, do not have such strict requirements.
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
[0]https://www.ethiopianairlines.com/corporate/media/media-rela...[1]https://www.ethiopianairlines.com/corporate/careers/vacancy
https://www.faa.gov/news/press_releases/news_story.cfm?newsI...
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.
"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.
[0]https://thepointsguy.com/news/how-much-experience-do-pilots-...
And FTA this thread is about:
"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."
So yeah, blame the flight crew... /s
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."
https://www.nytimes.com/2019/03/21/business/boeing-safety-fe...
(I have no idea if this is the case or not - I'm merely saying it's possible)
The continued insistence against easily checked facts proves my point.
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.
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.