Talk:Ethiopian Airlines Flight 302/Archive 2

Archive 1

Archive 2

Archive 3

Archive 4

Additional comments, Prelim Report

"We need someone else to draw the conclusion from Boeing manuals to avoid it being original research afik. Thoughts??"

I agree that we need WP:RS cites for any informational statements put in the article. It takes a lot of time to find good sources on the Internet that can be used, but I don't have excess time of my own to do that research, so it will have to be done by other editors. When I comment about how such systems work, I do so to help other editors to know what to look for in their research quiries, which is required to satisfy the WP:RS rule.

"I think we are all seeing that overspeed is a key factor here. Whether it turns out to be a primary or contributing cause remains to be seen."

I agree, the excessive high speed greatly reduced their ability to get the HS back to where it should have been, for normal flight. However, as to that pilot error (to properly control the speed) being classified as Primary or Contributing, we will have to wait for the final report. I do not recommend any editor inserting statements like that even if a WP:RS source can be found prior to the Final Rpt being released, since it would be irresponsible for any press article to make statements like that, EVEN IF the source is one that has traditionally been treated as a Wiki RS for other issues.

"...could find no reference to position of the "arm" switch or anything else about airspeed and AT other than the original text quoted, after left Autopilot was engaged, "at 05:39:42, Level Change mode was engaged. The selected altitude was 32000 ft. Shortly after the mode change, the selected airspeed was set to 238 kt." From the data both left and right N1% seem to stay above 90% as best I can eyeball it until the final sharp dive commences. The more I have looked into this it seems the most glaring issue - was the AT in fact on or off (and when), did the pilots know the AT actual state, and if it was on why did it not throttle back when 238kt was exceeded? Sounds like this needs to be addressed. I don't see any obvious edits to the article (since it would be original research) so if anyone has any ideas please say. Otherwise, we wait. Greenbe (talk) 00:52, 25 April 2019 (UTC)"

The AT switches HAVE TO BE IN THE 'armed' position for the ATs to be engaged. If those switches are in the off position, then all thrust changes can only come from manual movement of the thrust levers by the pilots.

IF the ATs were in the TOGA mode originally, they would have remained in that mode "IF" the button was not punched after the pilot dialed in the airspeed of 238kts. THAT is one possible explanation. The other is that they selected the "Level Change" VNav mode, to command the plane to climb to FL 320. IMHO, that was improper because that mode is a "pitch" mode, not a speed mode. The result is that the ATs did not pull back at all, since there still was no command to reduce thrust.

"Six seconds after the autopilot engagement, there were small amplitude roll oscillations accompanied by lateral acceleration, rudder oscillations and slight heading changes. These oscillations continued also after the autopilot was disengaged."

Those lateral movements could come ONLY from the pilot moving the rudder pedals (though yaw dampers can move the rudders, their authority is very limited and usually only comes into play at cruise altitudes, IN RESPONSE TO detected yawing which can occur in all swept-wing aircraft at high MACH speeds). The APs are NOT connected to the rudder during regular, normal AP operations. ONLY when the two or three APs are ON and BOTH FCCs are engaged and comparing data, during a CAT III AP approach, will the APs command rudder movements too.

"I presume he had difficulty reaching even the column trim switches, as he later asks the copilot to try trimming: At 05:41:46, the Captain asked the First-Officer if the trim is functional. (Likely he meant column trim, but this is not confirmed.)"

I think neither of the yoke trim switches worked then, because that was AFTER they had turned off the two pedestal switches, and BEFORE they had turned them back on again. Once they turned them back on again, they COULD HAVE saved the plane "IF" they had continuously trimed ANU until the HS was back to the proper position, AND THEN turned those switches OFF again, while manually pulling the thrust levers back to idle trust position. Why they did not do that is a mystery to me. If it was because of "pilot overload," then I would attribute that to a great deficiency in proper training of how to deal with a "runaway stabilizer" emergency, regardless of why it was happening. IMHO, the MANUAL trim would not work because of the excessive high-speed air load on the HS.

"Before Mcas activated, they already had AP induced oscillations..."

How can anyone know that was caused by the AP?

"Struggling to fly straight and level, the pilots became overloaded or startled. Misleading and contradicting warnings confused them and they lost overview of the situation."

I think that is a reasonable speculation. The most important question then, is "WHY?" My answer is that their sim and ground school training was terribly deficient. The more experience and training a pilot gets, as to possible emergency situations and how to handle them properly, the less likely they will be overwhelmed and unable to make proper decisions at critical times, even when the pressure piles on them. BOTH of the MAX crashes would not have happened, IMHO, if those pilots had been properly and thoroughly trained on how to handle that kind of emergency. EditorASC (talk) 18:18, 27 April 2019 (UTC)

"About why the overspeed warning went unnoticed, I can only guess any of: 1) panic and fatigue caused tunnel vision 2) stick-shaker and repeated nose-down pitching suggesting low speed, thus ignoring airspeed as unreliable 3) reliance on AT, expecting it to be engaged."

Why do you think it went "unnoticed?" That is an assumption which won't stand for pilots that have considerable experience in flying jet aircraft. As the actual speed increases, noise level in the cockpit also increases. If a pilot suspects his IAS is giving erroneous information, that does not mean he thinks the plane is at low speed while the cockpit sound level has increased significantly, consistent with very high ACTUAL speed.

"Repeated nose-down pitching suggesting low speed."

Not to an experienced jet pilot. To the contrary, the speed effect of gravity on jet aircraft is incredibly powerful. That is why pilots can keep increasing the speed during descent from a cruise altitude simply by lowering the nose by only 2 degrees AND -- even though the thrust of all engines has been reduced to flight idle.

The overspeed clacker sounded for over two minutes, until the end of the FDR recording; the left IAS reached 458 kts & the right IAS read 500 kts.

"reliance on AT, expecting it to be engaged."

Since N1 of both engines remained at 94% the entire flight, either it WAS still engaged in the TOGA mode, OR the pilots had advanced the thrust levers manually to TO thrust, and never adjusted the thrust levers after that.EditorASC (talk) 19:49, 28 April 2019 (UTC)

@EditorASC:

"I think neither of the yoke trim switches worked then, because that was AFTER they had turned off the two pedestal switches, and BEFORE they had turned them back on again."

I should have cited the line before the cut-out: "At 05:40:27, the Captain advised the First-Officer to trim up with him.". This 10 second trim ends with the cut-out.

"Once they turned them back on again, they COULD HAVE saved the plane "IF" they had continuously trimed ANU until the HS was back to the proper position, AND THEN turned those switches OFF again, while manually pulling the thrust levers back to idle trust position. Why they did not do that is a mystery to me."

Note: there is agreement that the cut-out happened, as the cvr recorded the correct procedure: "At 05:40:35, the First-Officer called out “stab trim cut-out” two times. Captain agreed and First Officer confirmed stab trim cut-out.", but the pilots turning the cut-out back on is only a "likely" scenario, based on circumstancial evidence: "At 05:43:04, the Captain ... said that pitch is not enough. At 05:43:11, two momentary manual electric trim inputs are recorded in the ANU direction."

There were longer inputs before, so these two inputs seem irrational. Did the pilot's thumb switches fail? He asked the copilot to trim before for some reason. Or the trim motor was stalled, and he gave up trying? 5 seconds later the Mcas activation caught them off-guard, 5 more seconds and they fly up from their seats, column back-pressure decreases. A lot happened in these 10 seconds that decided the fate of the airplane, and there is very little information about it.

This was much more than a runaway trim. The Mcas failure is different in crucial points:

• Runaway Trim is stopped by the TRIM COLUMN CUTOUT switch in the 737 NG when the pilot pulls enough on the yoke, giving time to resolve the issue. Mcas overrides this switch by design: it's purpose is to increase the necessary back-pressure to pull back the yoke when AoA is high (and the lift generated by the big engine nacelles create significant pitch-up force). Sources I read also say "in turns", therefore the weird name of "Manouvering Characteristics" and not "Pitch" or "Stall Characteristics". There is no software failsafe built in to limit or disable Mcas with extreme column forces.
• Runaway Trim is continuous, easy to identify. Mcas can confuse the pilot: stops after 10 seconds or electrim trim inputs, but starts again after a delay of 5 seconds.
• Speed Trim System present in the 737 NG operates the trim at low speed (0.6 degrees per second) when flaps are up. Mcas always at high speed (2.5/s), regardless of flaps, airspeed, altitude, pitch. It takes 40 seconds from level flight to nose-down, with the effect slowly building up, delaying reaction.
• The 737 NG has separate trim cut-out switches for electric trim (pilot) and automatic trim (AP/STS, Mcas on the Max). A mistrim can potentially be fixed without re-enabling the faulty automated system.

The runaway trim was only the second issue, preceded by "flight control problems" that started a minute earlier. The report only states "small amplitude ... oscillations", and the articles I read do not go into detail either. Based on the acceleration graphs from the FDR I think the pilot had serious trouble controlling the plane even before the trim runaway. After the runaway was stopped it took about a minute to counter the oscillations with both pilots holding the yoke.

This was a failure mode possibly unknown even to Boeing. I believe experienced pilots, who have been in a real emergency, or very difficult simulator trainings, thus able to keep composure would have been able to save these planes, but many pilots would become the victim of this emergency. Not all pilots are fighter pilots.

"How can anyone know that was caused by the AP?"

Right. I've rewritten to express more explicitly the whole interpretation is one possibility/speculation.

"The most important question then, is "WHY?" My answer is that their sim and ground school training was terribly deficient."

Another answer is that one of the primary design targets of the Max was minimal pilot training costs, thus no simulator training or documentation for Mcas failure modes, which have less failsafes, but many times more authority than AP/STS trim. This design principle goes even deeper: many design compromises led to the creation of Mcas in this way. It uses a critical flight control just to make it harder to pull on the yoke, instead of safer alternatives: The Elevator Feel Shift module or a stick pusher. Mcas would not even be necessary if the landing gears were taller and the engines under the wing, but that would require a re-design of the fuselage and possibly different type certificate. There's a series of causes, some of which affect more passengers than the training procedures of one airline.

For me the important question is how the "human-machine interface" can be safer for resolving such situations. While researching this accident I was surprised to realise if some instrument fails there is no logic in the FCC to identify the source of the fault. All it does is disconnect the AP, and leave the pilot with confusing readings. In these accidents the confusion was compounded with misleading disagree lights (the raw airspeed and ALT readings were the same on both sides, only the ADIRU computed values differed), and the lack of the real cause, the AoA disagree light (economic decision). With proper checks in the FCC these misleading warnings can be eliminated. In many cases (like ET302) the failing sensor can be identified from the impossible jump of the value. The pilot should be able to switch over to the other sensor, thus disabling the erroneous stick shaker, reducing stress significantly.

Going further, I could hardly believe how the Mcas behaves. From the top of my head I've listed 7 safety constraints in a previous answer, all of them missing from the original Mcas... The software update statement mentions only one (disagree) of these, and 2 more I did not list.

There's a lot that can be done to prevent this accident in design and training as well.

"Why do you think it went "unnoticed?"" [the overspeed warning]

The report doesn't show either the pilot or the copilot calling out speed readings or the overspeed clacker, but it shows the copilot noticed Master Caution: "At 05:42:51, the First-Officer mentioned Master Caution Anti-Ice.", a more subtle warning. Why overspeed is not mentioned, then? The report skipped many parts of the CVR, but if there was an overspeed callout, I would expect it to be included, unless left out intentionally. Is this a sign of tunnel-vision caused by the overload or shock of pilots? Or they haven't been in an overspeed simulation, and did not recognize the meaning of the clacker?

— Aron Manning (talk) 03:27, 30 April 2019 (UTC)

"I just came across this I downloaded a copy before it too "disappears"."

@Greenbe: You can read the original article on linkedin. Well written and thorough, but rushes to a judgement, while ignoring the unexplained mysteries, the human factor, and most importantly an engineering review of the erroneous Mcas system and the brand new sensors that failed. He is a B787 pilot, thus his loyalty to Boeing is understandable. He also "provides investment research and analytic support for investors in the airline and related industries" at "Ionosphere Capital", so there is a conflict of interest. The gaps he jumps over might reveal great lessons on the "Human-Machine Interface", pilot workload limits and cockpit psychology. Apart from that the timeline is a valuable work. It's also worth to look at the comments for more balanced interpretations.

IMHO talking about the mistakes of pilots is acceptable and respectful as long as it is not a judgment. To make mistakes is human, especially in a life-threatening situation. Judging these mistakes from our comfort would be pretentious and disrespectful, but understanding them is necessary to learn the lessons. The problem with the phrase 'pilot error' is: it's strongly attached to a final judgement that ignores all other errors. It reflects a very limited view on reality, as all accidents are an accumulation of errors. Ignoring the non-pilot errors would be unjust, and dangerous for future flights, as these errors will resurface sooner or later, when all the contributing factors are present.

"What I was trying to get at is whether the overspeed situation was a result of the plane's automation fighting with itself or the pilot's actions (or inaction)."

@Greenbe: IMO the simplest - but possibly not the right -, answer for the uncontrolled speed is mental overload, or shock. As I imagine the cockpit environment, the pilots were fighting for survival, and all their focus was concentrated on leveling an erratically flying plane. Possibly the copilot wanted to enable A/T SPD mode after selecting 238 kts, but was distracted or did not push the button properly as the cockpit was quite bumpy. Throughout the flight it was hard to judge the speed with the unreliable airspeed indicator, the up-down fluctuation, and the stick shaker's rattle shadowing the overspeed clacker. Possibly the pilots 1) did not notice the warning, or 2) ignored it as unreliable. For me the question is 1) what events caused such tunnel vision and why they lost awareness of speed, or 2) what did they see on the instruments, and what they read into it. The prelim report curiously lacks any communication concerning speed, possibly only the final report will reveal more.

"The lack of speed control is very troubling and would seem to have fallen victim to inattention due to pilot distraction/workload. The pilot not flying (pilot monitoring) should have been alerting the pilot flying repeatedly over the excessive speed, yet this report makes no mention of this advice, and even when overspeed."

"When a pilot experiences a stall warning like a stick shaker, his reaction is to lower the nose and increase the speed. He wants to build a margin to an eventual stall. If he simultaneously has “Unreliable airspeed” warning, the built margin will be larger. In both of these cases, the pilots are flying faster than normal at the low altitudes they flew (5,000ft pressure altitude for JT610, 9,000ft for ET302). This is to build a safety margin while sorting out stall warning and flight control problems."

"The throttles are left at 94% thrust for the whole flight. This is higher than normal but this is a high takeoff. At 7,600ft it is a full 2,200ft higher than Denver, which is the US Benchmark for high takeoffs. And with Stick Shaker and IAS disagree you keep high thrust and fly a slow climb ..."

A Senior Captain commented on the article Greenbe mentioned: "why do we move so quickly to seek retribution from the front line operators who constitute the last line of defense. That’s where all the readily available data is recorded, CVR, FDDR etc. If we had recorders from the manufacturer design workshops and executive boardrooms perhaps the playing field would level out a little."

To level the field I'd add that the uncontrolled speed might not bear that much weight in the investigation. The safety assessment and certification of Mcas is scrutinized:

• It is widely known (obvious from the FDR data) that it has no checks for sensor failure, yet it has unlimited authority over the stabilizer, operates the trim motor at fast speed (2.5 degree / 9.26 sec, 4 times faster than a Runaway Trim with flaps up).
• Peter Lemme pointed out Mcas overrides the primary safety switch for Runaway Trim ("aft column cutout" / "COLUMN TRIM CUTOUT"), which stops a nose-down trim when the pilot pulls back the yoke. Lemme emphasized this difference (which would have saved both planes) "is not highlighted in the FAA Airworthiness Directive. It even implies that it will work".
• Additionally the 737 NG has a separate Auto Pilot "STAB TRIM CUTOUT" switch between the wheels, which can disable AP and STS trim runaway without disabling the pilots trim thumb switches. In the Max this switch became a backup "B/U" for the other switch, thus both switches disable both the pilot and automatic trim by cutting power to the trim motor. I don't believe this was mentioned in the 2 hour differential course.
• Stabilizer authority greatly increases with airspeed, but Mcas ignores this in the formula, commanding fast and long trim movements even at high speed. JT610 pitched from level flight to unrecoverable nose-dive in 30 seconds, ET302 in 10 seconds as a result.

These reports paint a picture of a critical system that lacks redundancy, multiple safety layers, and was not prepared for the whole flight envelope. This design slipped through multiple levels of the company, and the FAA certification. Boeing refutes any claims this design is unsafe, and does it's best to prove it's the pilots' responsibility to disable this "system", although it's existence and potential was not disclosed, even the EAD only hints of its existence, without describing its dangers.

To augment this picture:

• The failure of multiple relatively new sensors does not happen by chance. Lemme shows design weaknesses of the AoA sensor on diagrams and a youtube tinkerer "AvE" disassembled a similar sensor although from a different aircraft type.
• The Lion Air plane had more sensor issues, this can point to a signaling unreliability.
• Lemme speculates Mcas runs in one instance, like STS does. Both being FBW "augmentations" using a critical control, safety requirements would necessitate that 2 independent implementations run at the same time and validate output consistency. Doubt this is part of the software update.
• One non-critical sensor's failure caused incorrect, misleading and overwhelming warnings, unreliable critical instruments, unnecessary stress and workload. The failing sensor was automatically identifiable by the impossible jump to 74.5 degrees in 3/4 sec. Sensor failures are many times identifiable from erratic readings with moderately complex logic. By switching to the backup with pilot confirmation all the confusion is avoided. In this price category it is a naturally occurring thought that such safety features are undoubtedly part of the design, but this is not the case. There is room to make the planes safer, more resilient to failures, and more survivable in emergencies.

References

Additional comments, Prelim Report

"We need someone else to draw the conclusion from Boeing manuals to avoid it being original research afik. Thoughts??"

I agree that we need WP:RS cites for any informational statements put in the article. It takes a lot of time to find good sources on the Internet that can be used, but I don't have excess time of my own to do that research, so it will have to be done by other editors. When I comment about how such systems work, I do so to help other editors to know what to look for in their research quiries, which is required to satisfy the WP:RS rule.

"I think we are all seeing that overspeed is a key factor here. Whether it turns out to be a primary or contributing cause remains to be seen."

I agree, the excessive high speed greatly reduced their ability to get the HS back to where it should have been, for normal flight. However, as to that pilot error (to properly control the speed) being classified as Primary or Contributing, we will have to wait for the final report. I do not recommend any editor inserting statements like that even if a WP:RS source can be found prior to the Final Rpt being released, since it would be irresponsible for any press article to make statements like that, EVEN IF the source is one that has traditionally been treated as a Wiki RS for other issues.

"...could find no reference to position of the "arm" switch or anything else about airspeed and AT other than the original text quoted, after left Autopilot was engaged, "at 05:39:42, Level Change mode was engaged. The selected altitude was 32000 ft. Shortly after the mode change, the selected airspeed was set to 238 kt." From the data both left and right N1% seem to stay above 90% as best I can eyeball it until the final sharp dive commences. The more I have looked into this it seems the most glaring issue - was the AT in fact on or off (and when), did the pilots know the AT actual state, and if it was on why did it not throttle back when 238kt was exceeded? Sounds like this needs to be addressed. I don't see any obvious edits to the article (since it would be original research) so if anyone has any ideas please say. Otherwise, we wait. Greenbe (talk) 00:52, 25 April 2019 (UTC)"

The AT switches HAVE TO BE IN THE 'armed' position for the ATs to be engaged. If those switches are in the off position, then all thrust changes can only come from manual movement of the thrust levers by the pilots.

IF the ATs were in the TOGA mode originally, they would have remained in that mode "IF" the button was not punched after the pilot dialed in the airspeed of 238kts. THAT is one possible explanation. The other is that they selected the "Level Change" VNav mode, to command the plane to climb to FL 320. IMHO, that was improper because that mode is a "pitch" mode, not a speed mode. The result is that the ATs did not pull back at all, since there still was no command to reduce thrust.

"Six seconds after the autopilot engagement, there were small amplitude roll oscillations accompanied by lateral acceleration, rudder oscillations and slight heading changes. These oscillations continued also after the autopilot was disengaged."

Those lateral movements could come ONLY from the pilot moving the rudder pedals (though yaw dampers can move the rudders, their authority is very limited and usually only comes into play at cruise altitudes, IN RESPONSE TO detected yawing which can occur in all swept-wing aircraft at high MACH speeds). The APs are NOT connected to the rudder during regular, normal AP operations. ONLY when the two or three APs are ON and BOTH FCCs are engaged and comparing data, during a CAT III AP approach, will the APs command rudder movements too.

"I presume he had difficulty reaching even the column trim switches, as he later asks the copilot to try trimming: At 05:41:46, the Captain asked the First-Officer if the trim is functional. (Likely he meant column trim, but this is not confirmed.)"

I think neither of the yoke trim switches worked then, because that was AFTER they had turned off the two pedestal switches, and BEFORE they had turned them back on again. Once they turned them back on again, they COULD HAVE saved the plane "IF" they had continuously trimed ANU until the HS was back to the proper position, AND THEN turned those switches OFF again, while manually pulling the thrust levers back to idle trust position. Why they did not do that is a mystery to me. If it was because of "pilot overload," then I would attribute that to a great deficiency in proper training of how to deal with a "runaway stabilizer" emergency, regardless of why it was happening. IMHO, the MANUAL trim would not work because of the excessive high-speed air load on the HS.

"Before Mcas activated, they already had AP induced oscillations..."

How can anyone know that was caused by the AP?

"Struggling to fly straight and level, the pilots became overloaded or startled. Misleading and contradicting warnings confused them and they lost overview of the situation."

I think that is a reasonable speculation. The most important question then, is "WHY?" My answer is that their sim and ground school training was terribly deficient. The more experience and training a pilot gets, as to possible emergency situations and how to handle them properly, the less likely they will be overwhelmed and unable to make proper decisions at critical times, even when the pressure piles on them. BOTH of the MAX crashes would not have happened, IMHO, if those pilots had been properly and thoroughly trained on how to handle that kind of emergency. EditorASC (talk) 18:18, 27 April 2019 (UTC)

"About why the overspeed warning went unnoticed, I can only guess any of: 1) panic and fatigue caused tunnel vision 2) stick-shaker and repeated nose-down pitching suggesting low speed, thus ignoring airspeed as unreliable 3) reliance on AT, expecting it to be engaged."

Why do you think it went "unnoticed?" That is an assumption which won't stand for pilots that have considerable experience in flying jet aircraft. As the actual speed increases, noise level in the cockpit also increases. If a pilot suspects his IAS is giving erroneous information, that does not mean he thinks the plane is at low speed while the cockpit sound level has increased significantly, consistent with very high ACTUAL speed.

"Repeated nose-down pitching suggesting low speed."

Not to an experienced jet pilot. To the contrary, the speed effect of gravity on jet aircraft is incredibly powerful. That is why pilots can keep increasing the speed during descent from a cruise altitude simply by lowering the nose by only 2 degrees AND -- even though the thrust of all engines has been reduced to flight idle.

The overspeed clacker sounded for over two minutes, until the end of the FDR recording; the left IAS reached 458 kts & the right IAS read 500 kts.

"reliance on AT, expecting it to be engaged."

Since N1 of both engines remained at 94% the entire flight, either it WAS still engaged in the TOGA mode, OR the pilots had advanced the thrust levers manually to TO thrust, and never adjusted the thrust levers after that.EditorASC (talk) 19:49, 28 April 2019 (UTC)

@EditorASC:

"I think neither of the yoke trim switches worked then, because that was AFTER they had turned off the two pedestal switches, and BEFORE they had turned them back on again."

I should have cited the line before the cut-out: "At 05:40:27, the Captain advised the First-Officer to trim up with him.". This 10 second trim ends with the cut-out.

"Once they turned them back on again, they COULD HAVE saved the plane "IF" they had continuously trimed ANU until the HS was back to the proper position, AND THEN turned those switches OFF again, while manually pulling the thrust levers back to idle trust position. Why they did not do that is a mystery to me."

Note: there is agreement that the cut-out happened, as the cvr recorded the correct procedure: "At 05:40:35, the First-Officer called out “stab trim cut-out” two times. Captain agreed and First Officer confirmed stab trim cut-out.", but the pilots turning the cut-out back on is only a "likely" scenario, based on circumstancial evidence: "At 05:43:04, the Captain ... said that pitch is not enough. At 05:43:11, two momentary manual electric trim inputs are recorded in the ANU direction."

There were longer inputs before, so these two inputs seem irrational. Did the pilot's thumb switches fail? He asked the copilot to trim before for some reason. Or the trim motor was stalled, and he gave up trying? 5 seconds later the Mcas activation caught them off-guard, 5 more seconds and they fly up from their seats, column back-pressure decreases. A lot happened in these 10 seconds that decided the fate of the airplane, and there is very little information about it.

This was much more than a runaway trim. The Mcas failure is different in crucial points:

• Runaway Trim is stopped by the TRIM COLUMN CUTOUT switch in the 737 NG when the pilot pulls enough on the yoke, giving time to resolve the issue. Mcas overrides this switch by design: it's purpose is to increase the necessary back-pressure to pull back the yoke when AoA is high (and the lift generated by the big engine nacelles create significant pitch-up force). Sources I read also say "in turns", therefore the weird name of "Manouvering Characteristics" and not "Pitch" or "Stall Characteristics". There is no software failsafe built in to limit or disable Mcas with extreme column forces.
• Runaway Trim is continuous, easy to identify. Mcas can confuse the pilot: stops after 10 seconds or electrim trim inputs, but starts again after a delay of 5 seconds.
• Speed Trim System present in the 737 NG operates the trim at low speed (0.6 degrees per second) when flaps are up. Mcas always at high speed (2.5/s), regardless of flaps, airspeed, altitude, pitch. It takes 40 seconds from level flight to nose-down, with the effect slowly building up, delaying reaction.
• The 737 NG has separate trim cut-out switches for electric trim (pilot) and automatic trim (AP/STS, Mcas on the Max). A mistrim can potentially be fixed without re-enabling the faulty automated system.

The runaway trim was only the second issue, preceded by "flight control problems" that started a minute earlier. The report only states "small amplitude ... oscillations", and the articles I read do not go into detail either. Based on the acceleration graphs from the FDR I think the pilot had serious trouble controlling the plane even before the trim runaway. After the runaway was stopped it took about a minute to counter the oscillations with both pilots holding the yoke.

This was a failure mode possibly unknown even to Boeing. I believe experienced pilots, who have been in a real emergency, or very difficult simulator trainings, thus able to keep composure would have been able to save these planes, but many pilots would become the victim of this emergency. Not all pilots are fighter pilots.

"How can anyone know that was caused by the AP?"

Right. I've rewritten to express more explicitly the whole interpretation is one possibility/speculation.

"The most important question then, is "WHY?" My answer is that their sim and ground school training was terribly deficient."

Another answer is that one of the primary design targets of the Max was minimal pilot training costs, thus no simulator training or documentation for Mcas failure modes, which have less failsafes, but many times more authority than AP/STS trim. This design principle goes even deeper: many design compromises led to the creation of Mcas in this way. It uses a critical flight control just to make it harder to pull on the yoke, instead of safer alternatives: The Elevator Feel Shift module or a stick pusher. Mcas would not even be necessary if the landing gears were taller and the engines under the wing, but that would require a re-design of the fuselage and possibly different type certificate. There's a series of causes, some of which affect more passengers than the training procedures of one airline.

For me the important question is how the "human-machine interface" can be safer for resolving such situations. While researching this accident I was surprised to realise if some instrument fails there is no logic in the FCC to identify the source of the fault. All it does is disconnect the AP, and leave the pilot with confusing readings. In these accidents the confusion was compounded with misleading disagree lights (the raw airspeed and ALT readings were the same on both sides, only the ADIRU computed values differed), and the lack of the real cause, the AoA disagree light (economic decision). With proper checks in the FCC these misleading warnings can be eliminated. In many cases (like ET302) the failing sensor can be identified from the impossible jump of the value. The pilot should be able to switch over to the other sensor, thus disabling the erroneous stick shaker, reducing stress significantly.

Going further, I could hardly believe how the Mcas behaves. From the top of my head I've listed 7 safety constraints in a previous answer, all of them missing from the original Mcas... The software update statement mentions only one (disagree) of these, and 2 more I did not list.

There's a lot that can be done to prevent this accident in design and training as well.

"Why do you think it went "unnoticed?"" [the overspeed warning]

The report doesn't show either the pilot or the copilot calling out speed readings or the overspeed clacker, but it shows the copilot noticed Master Caution: "At 05:42:51, the First-Officer mentioned Master Caution Anti-Ice.", a more subtle warning. Why overspeed is not mentioned, then? The report skipped many parts of the CVR, but if there was an overspeed callout, I would expect it to be included, unless left out intentionally. Is this a sign of tunnel-vision caused by the overload or shock of pilots? Or they haven't been in an overspeed simulation, and did not recognize the meaning of the clacker?

— Aron Manning (talk) 03:27, 30 April 2019 (UTC)

"I just came across this I downloaded a copy before it too "disappears"."

@Greenbe: You can read the original article on linkedin. Well written and thorough, but rushes to a judgement, while ignoring the unexplained mysteries, the human factor, and most importantly an engineering review of the erroneous Mcas system and the brand new sensors that failed. He is a B787 pilot, thus his loyalty to Boeing is understandable. He also "provides investment research and analytic support for investors in the airline and related industries" at "Ionosphere Capital", so there is a conflict of interest. The gaps he jumps over might reveal great lessons on the "Human-Machine Interface", pilot workload limits and cockpit psychology. Apart from that the timeline is a valuable work. It's also worth to look at the comments for more balanced interpretations.

IMHO talking about the mistakes of pilots is acceptable and respectful as long as it is not a judgment. To make mistakes is human, especially in a life-threatening situation. Judging these mistakes from our comfort would be pretentious and disrespectful, but understanding them is necessary to learn the lessons. The problem with the phrase 'pilot error' is: it's strongly attached to a final judgement that ignores all other errors. It reflects a very limited view on reality, as all accidents are an accumulation of errors. Ignoring the non-pilot errors would be unjust, and dangerous for future flights, as these errors will resurface sooner or later, when all the contributing factors are present.

"What I was trying to get at is whether the overspeed situation was a result of the plane's automation fighting with itself or the pilot's actions (or inaction)."

@Greenbe: IMO the simplest - but possibly not the right -, answer for the uncontrolled speed is mental overload, or shock. As I imagine the cockpit environment, the pilots were fighting for survival, and all their focus was concentrated on leveling an erratically flying plane. Possibly the copilot wanted to enable A/T SPD mode after selecting 238 kts, but was distracted or did not push the button properly as the cockpit was quite bumpy. Throughout the flight it was hard to judge the speed with the unreliable airspeed indicator, the up-down fluctuation, and the stick shaker's rattle shadowing the overspeed clacker. Possibly the pilots 1) did not notice the warning, or 2) ignored it as unreliable. For me the question is 1) what events caused such tunnel vision and why they lost awareness of speed, or 2) what did they see on the instruments, and what they read into it. The prelim report curiously lacks any communication concerning speed, possibly only the final report will reveal more.

"The lack of speed control is very troubling and would seem to have fallen victim to inattention due to pilot distraction/workload. The pilot not flying (pilot monitoring) should have been alerting the pilot flying repeatedly over the excessive speed, yet this report makes no mention of this advice, and even when overspeed."

"When a pilot experiences a stall warning like a stick shaker, his reaction is to lower the nose and increase the speed. He wants to build a margin to an eventual stall. If he simultaneously has “Unreliable airspeed” warning, the built margin will be larger. In both of these cases, the pilots are flying faster than normal at the low altitudes they flew (5,000ft pressure altitude for JT610, 9,000ft for ET302). This is to build a safety margin while sorting out stall warning and flight control problems."

"The throttles are left at 94% thrust for the whole flight. This is higher than normal but this is a high takeoff. At 7,600ft it is a full 2,200ft higher than Denver, which is the US Benchmark for high takeoffs. And with Stick Shaker and IAS disagree you keep high thrust and fly a slow climb ..."

A Senior Captain commented on the article Greenbe mentioned: "why do we move so quickly to seek retribution from the front line operators who constitute the last line of defense. That’s where all the readily available data is recorded, CVR, FDDR etc. If we had recorders from the manufacturer design workshops and executive boardrooms perhaps the playing field would level out a little."

To level the field I'd add that the uncontrolled speed might not bear that much weight in the investigation. The safety assessment and certification of Mcas is scrutinized:

• It is widely known (obvious from the FDR data) that it has no checks for sensor failure, yet it has unlimited authority over the stabilizer, operates the trim motor at fast speed (2.5 degree / 9.26 sec, 4 times faster than a Runaway Trim with flaps up).
• Peter Lemme pointed out Mcas overrides the primary safety switch for Runaway Trim ("aft column cutout" / "COLUMN TRIM CUTOUT"), which stops a nose-down trim when the pilot pulls back the yoke. Lemme emphasized this difference (which would have saved both planes) "is not highlighted in the FAA Airworthiness Directive. It even implies that it will work".
• Additionally the 737 NG has a separate Auto Pilot "STAB TRIM CUTOUT" switch between the wheels, which can disable AP and STS trim runaway without disabling the pilots trim thumb switches. In the Max this switch became a backup "B/U" for the other switch, thus both switches disable both the pilot and automatic trim by cutting power to the trim motor. I don't believe this was mentioned in the 2 hour differential course.
• Stabilizer authority greatly increases with airspeed, but Mcas ignores this in the formula, commanding fast and long trim movements even at high speed. JT610 pitched from level flight to unrecoverable nose-dive in 30 seconds, ET302 in 10 seconds as a result.

These reports paint a picture of a critical system that lacks redundancy, multiple safety layers, and was not prepared for the whole flight envelope. This design slipped through multiple levels of the company, and the FAA certification. Boeing refutes any claims this design is unsafe, and does it's best to prove it's the pilots' responsibility to disable this "system", although it's existence and potential was not disclosed, even the EAD only hints of its existence, without describing its dangers.

To augment this picture:

• The failure of multiple relatively new sensors does not happen by chance. Lemme shows design weaknesses of the AoA sensor on diagrams and a youtube tinkerer "AvE" disassembled a similar sensor although from a different aircraft type.
• The Lion Air plane had more sensor issues, this can point to a signaling unreliability.
• Lemme speculates Mcas runs in one instance, like STS does. Both being FBW "augmentations" using a critical control, safety requirements would necessitate that 2 independent implementations run at the same time and validate output consistency. Doubt this is part of the software update.
• One non-critical sensor's failure caused incorrect, misleading and overwhelming warnings, unreliable critical instruments, unnecessary stress and workload. The failing sensor was automatically identifiable by the impossible jump to 74.5 degrees in 3/4 sec. Sensor failures are many times identifiable from erratic readings with moderately complex logic. By switching to the backup with pilot confirmation all the confusion is avoided. In this price category it is a naturally occurring thought that such safety features are undoubtedly part of the design, but this is not the case. There is room to make the planes safer, more resilient to failures, and more survivable in emergencies.

References

April 19th, 2018 Update from The Aviation Herald

The April 19th, 2018 update from The Aviation Herald has some new information regarding the currency of the material in the Flight Operations Manual which was in use by Ethiopian Airlines at the time of the crash. If AH's assertions are correct, that part of the FOM was a year out of date as it did not include the Boeing update.

The author, Simon Hradecky, states "...only very cursory knowledge about the stab trim runaway procedure exists amongst the flight crew of Ethiopian Airlines even 5 months after the EAD was distributed. In particular, none of the conditions suggesting an MCAS related stab trim runaway was known with any degree of certainty."

If true, this clearly implicates Ethiopian Airlines crew training as a factor in the outcome of the incident.

I've added a reference to the section on the Preliminary Report.

-df DWmFrancis (talk)

Interpretation of the Preliminary Report

The preliminary report contains, in the appendices page 26 and 27, part of the flight data as extracted from the FDR presented as graphs. From these graphs can be seen that the AOA sensor signal became erroneous immidiately after lift-off. Approximately one minute into the flight, after flap retraction, the automatic trim system is enabled. Data shows the system to act upon the erroneous AOA signal, but also clearly indicates that manual trim (trim as commanded by the pilots through the trim switches on both control wheels) has priority. The manuaul trim commands interrupt and are countering the automatic nose down inputs from the automatic system. From about two minutes after take off the stabilizer position stops to follow opposing manual and automatic command inputs. This concurs with the CVR recording indicating that the stab trim cut-out switches are used to stop stabilizer movement. About the same time the aircraft exceeds Vmo, the maximum allowable airspeed for the airframe. During the next two-and -a-half minute the flight is continued with a lot of manual elevator up input to counter for the now 'frozen' but seriously mistrimmed down stabilizer setting. With the stabilizer trim in cut-out the only way to remedy this situation is manual trim. The CVR transcript suggests that the first officer tried to do so but failed. This failure may have to do with an additional technical issue, but operating the stabilizer in this way quite strenuous, the more so if the other pilot is not available to handle the second crank of the manual trim wheels. In the same time interval, some 2.5 minutes, no attempt seems to be made to keep the flights speed in the normal range. Speed is allowed to increase to well above Vmo, increasing the airloads on the stabilizer and thus possibly further impairing manual control. Approximately 5 minutes after lift-off, two very short manual nose up trim commands are issued, after 5 seconds followed by an automatic nose down command. The stabilizer position follows through on these commands, thus strongly suggesting that the cutout switches, by this time, are reset to normal. At the end of the last automatic (nose down) movement of the stabilizer a short lapse in applied back-pressure to the yoke can be observed, resulting in an immidiate pich down. By this time the airspeed is close to 400kts, meaning that compressibility effects are shifting the effectivenes of pitch control over the aircraft away from the elevators towards the stabilizer as a whole. With the stabilizer mistrimmed nose down, the nose continues to drop and speed increases even further.

@92.110.148.249: "a short lapse in applied back-pressure to the yoke can be observed, resulting in an immidiate pich down" — the pitch down is result of the 5 second, 1.3 degrees automatic nose down trim by Mcas. The decreased pull on the yoke (8° to 5°) happened a few seconds later, while the pilots experienced negative G. Detailed reply below. — Aron Manning (talk) 03:35, 17 April 2019 (UTC)

The data suggests that the crew handled the initial runaway stabilizer situation correctly. Also returning the stab trim cut-out switches to their normal positions can be explained from Boeings suggestion, following the earlier 8max crash, as an attempt to use electrical trim to reset the stabilizer to an appropriate setting for the actual flight conditions. However, in order for this scheme to work a simultanouos manual nose up input of sufficient duration should have been issued. With this vital action not accomplished the automatic system, still acting upon erroneous AOA data, was allowed to worsen the situation further. The significant overspeed that had accumulated over the previous 2.5min robbed the crew of any elevator effectiveness that might have saved the flight. Why the crew allowed the overspeed to accumulate is yet unknown. Reducing power seems obvious, although fear for an additional pitch down moment may have been an argument. — Preceding unsigned comment added by 92.110.148.249 (talk) 15:32, 9 April 2019 (UTC)

[IP User amended the above and re-signed] 92.110.148.249 (talk) 19:02, 9 April 2019 (UTC)

Do you have anything that is not original research that can improve the article ? MilborneOne (talk) 15:48, 9 April 2019 (UTC)

@MilborneOne: There are lots of sources but apparently we are not allowed to quote them. Where is there a written rule on this? and many more can be found. If you want a section on this you should reinstate the the section I already wrote that was deleted and we can clean it up and summarize. The key points are the thrust remained 94% and was unchanged the whole flight, this is called out in the prelim report for the first time. Why that happened is unknown, but since that is what the investigation is focusing on it can be written. I think it is becoming clear that until the full sequence is better understood the B737 Max will remain grounded.Greenbe (talk) 01:04, 10 April 2019 (UTC)

I tried to do that. WikiHannibal (talk) 08:53, 10 April 2019 (UTC)

@WikiHannibal: @92.110.148.249: Your point about Bloomberg saying the captain called for 238 kts yet that is not in the prelim report seems correct, report just says that 238 kts was selected not by who. The captain had called for the autopilot to be engaged earlier by calling "Command" which is in the report. Since Bloomberg state they are quoting a group of 737 captains analyzing the prelim report you can correct it is a mistake (as you did), but if they are quoting a confidential source with access to more data then need to be more careful (if it is a super important point, which I do not think this is .... yet). Crew interactions have yet to be dissected.

I re-read sections of the prelim report and have realized they do not mention autothrottle. Random online info says TO/GA switch is usually set for takeoff which engages autothrottle - that setting is also not mentioned in prelim report for reason unknown. You can start to read the sequence as they either expected the automation to reduce %N1 at some point, or they "forgot" that when autopilot disengaged on its own (or some other caution) that autothrottle would disengage and the speed setting would be ignored ... or something like that. Most of 92.110.148.249's summary is reasonable I think but the statement "The data suggests that the crew handled the initial runaway stabilizer situation correctly" is of course a very controversial topic. I reviewed the Boeing/FAA AD from November and it also says stab trim should stay in cutoff "for remainder of flight", as does QRH checklist. I don't think you can escape with the word "initial". But .... it's not so simple. We don't have the full CVR transcript, only a few select items that the prelim report mentioned. Greenbe (talk) 21:08, 10 April 2019 (UTC)

@DonFB: I took your suggestion and added speed select on autopilot and tried to restructure it to make if flow better. If you can see further improvements please edit.

Neither the Bloomberg article, nor the Prelim Rpt says the autopilot was controlling the Airspeed of the plane. They shouldn't say that because the Air Speed is automatically controlled thru the FCC (Flight Control Computer) and NOT thru the AP computer, provided the AT switch is armed (switch is in the "On" position on the MCP) and the pilot has activated the FCC to engage the auto-throttles in one mode or another. Apparently, the AT system was put into the TOGA mode at the start of the TO roll and was never changed after that. Dialing in a specific speed on the MCP will not take the ATs out of the TOGA mode and put them into the Speed mode, if the switch is not pressed after dialing in that speed. Note that when the AP was disengaged, that did not change the apparent TOGA mode of the ATs, which is why the plane was flying way too fast.EditorASC (talk) 16:17, 22 April 2019 (UTC)

My earlier commented-out remark/question in the body of the article (seen here) was intended to request clarification, because that version of the article said: "the throttles did not move for the entire flight, even though the selected airspeed was set to 238kt (274 miles per hour)". That wording, for me, raised the question of where or in what manner "the selected airspeed was set" if the throttles were not moved. I made the request because, though I'm following the article, I have not scrutinized the Preliminary Report to be able to make the clarification. The explanation immediately above (by EditorASC) may be correct, but the clarification I'd like (as a proxy for general readers) would be just a few words, indicating how or on what device the 238kt speed was set. DonFB (talk) 18:20, 22 April 2019 (UTC)

The "device" was the Mode Control Panel (MCP). To take the ATs out of the TOGA mode after TO, a desired speed must be dialed into the speed control window (which has two alternatives, IAS and MACH), AND THEN the speed control button must be punched to activate that desired speed. If the pilots failed to punch that button, the speed would remain in the last selected mode, which was likely that of TOGA, since the FDR showed the RPMs remained at 94% the entire short flight. Boeing has a fairly good view of the MCP (at the top of the glare shield) for the 737 MAX here [1]There also is a Youtube tutorial that might prove to be helpful [2]EditorASC (talk) 06:45, 24 April 2019 (UTC)

The above interpretation is based solely on the priliminary report as published by the Etheopian Accident Investigation Bureau in the light of general principles of flight handling and some specific B737 characteristics. As usual, the preliminary report describes the facts known at this. With the available data a seemingly fairly complete picture of what happened can be drawn. It does not answer the question of why it happenend.92.110.148.249 (talk) 15:20, 10 April 2019 (UTC)

"...but also clearly indicates that manual trim (trim as commanded by the pilots through the trim switches on both control wheels) has priority."

That is not what is meant by the phrase "manual trim." MANUAL TRIM is when the pilots try to move the HS by manually cranking the two trim wheels in the cockpit, that are located on both sides of the center pedestal.EditorASC (talk) 18:07, 11 April 2019 (UTC)

@EditorASC:@92.110.148.249: The prelim report uses the term "manual electric trim" in a number of places, that is clearly what 92.110.148.249 means as per the brackets. The question remains: Can we have a paragraph trying to tie together some of the key items from the report?

"Also returning the stab trim cut-out switches to their normal positions can be explained from Boeings suggestion, following the earlier 8max crash, as an attempt to use electrical trim to reset the stabilizer to an appropriate setting for the actual flight conditions." Is there any reference link to support this statement? Greenbe (talk) 19:11, 11 April 2019 (UTC)

I think your guess is probably correct (that was how 92.110.148.249 interpreted the Prelim comments). This kind of problem is created when the writers of that Prelim Rpt invented some different nomenclature that is inconsistent with that which Boeing uses in its FOM NNC checklist procedures, or in the subsequent Boeing November bulletin.

Boeing does not combine the word "manual" with "electric trim." When Boeing uses the term "manual trim," it is talking about the pilots manually cranking the two cockpit wheels that are connected via cables to the HS.

As to a Boeing "suggestion," I haven't run across anything like that. From page 33 (last page of the ET302 Prelim Report):

"Electric stabilizer trim can be used to neutralize control column pitch forces before moving the STAB TRIM CUTTOUT switches to CUTTOUT. Manual stabilizer trim [means the MANUAL moving of the stab trim wheels in the cockpit, by the pilots cranking those two wheels with their hands] can be used after the STAB TRIM CUTTOUT switches are moved to CUTTOUT."

I find nothing in that bulletin that suggests the STAB TRIM CUTTOUT switches should be turned back on again, once they have been moved to the CUTTOUT position. However, I do think Boeing should add some statements which strongly emphasizes that pilots should countermand unwanted HS trim with their yoke electric trim switches, until they get the HS back to the position they want, and then IMMEDIATELY move the CUTTOUT switches to the CUTTOUT position.EditorASC (talk) 22:08, 13 April 2019 (UTC)

a short lapse in applied back-pressure to the yoke can be observed, resulting in an immidiate pich down
— User:92.110.148.249

I suggest revising this. According to the preliminary report, page 10:

"At 05:43:20, approximately five seconds after the last manual electric trim input, an AND (Aircraft Nose Down) automatic trim command occurred and the stabilizer moved in the AND direction from 2.3 to 1.0 unit in approximately 5 seconds. The aircraft began pitching nose down. Additional simultaneous aft column force was applied, ..."

The FDR data diagram on page 26 shows "Pitch Attitude Disp" starts decreasing from ca. 3 degrees at 05:43:22, while the mcas Nose Down trim is active between :20 and :25 seconds. 3 seconds later at 05:43:25 the "Ctrl Column Pos" starts to move from ca. 8 degrees to 5°, the same time as the "Accel Vert (g)" fell from 1.0g (level flight) to -0.4g (nosedive). The sudden negative G environment and stronger forces on the elevator control surface might be the cause for the column position moving forward. — Aron Manning (talk) 03:35, 17 April 2019 (UTC)

@EditorASC:@Aron Manning: I think we are all seeing that overspeed is a key factor here. Whether it turns out to be a primary or contributing cause remains to be seen. The issue I have is that we can discuss all day on the talk page, but are there any sources out there that talk about A/T setting, TOGA, and whether the autopilot disengaging itself leads to A/T being disengaged? I've searched a fair bit but not so far. Leeham talks about overspeed but not the connection to A/T setting (or lack thereof). We need someone else to draw the conclusion from Boeing manuals to avoid it being original research afik. Thoughts?? Greenbe (talk) 00:13, 23 April 2019 (UTC)

I just now covered that in my reply to DonFB (talk), Scroll back up a ways and you should find it. And no, the AP disengaging will not cause the AT to disengage too, because the AP does not control the ATs. The FCC controls the ATs, provided the "arm" switch for the ATs is in the armed ("on") position. EditorASC (talk) 07:27, 24 April 2019 (UTC)

@EditorASC:@Aron Manning: I rescanned the prelim report PDF just now and could find no reference to position of the "arm" switch or anything else about airspeed and AT other than the original text quoted, after left Autopilot was engaged, "at 05:39:42, Level Change mode was engaged. The selected altitude was 32000 ft. Shortly after the mode change, the selected airspeed was set to 238 kt." From the data both left and right N1% seem to stay above 90% as best I can eyeball it until the final sharp dive commences. The more I have looked into this it seems the most glaring issue - was the AT in fact on or off (and when), did the pilots know the AT actual state, and if it was on why did it not throttle back when 238kt was exceeded? Sounds like this needs to be addressed. I don't see any obvious edits to the article (since it would be original research) so if anyone has any ideas please say. Otherwise, we wait. Greenbe (talk) 00:52, 25 April 2019 (UTC)

I agree re: OR. I finally looked at the Prelim, and it's impossible to state, based only on that source, exactly by what means the 238kt was set (or attempted to be set). Will need sourcing that explains what, if anything, the investigators conclude or theorize in their final report about the speed setting. I didn't regard the question as hugely important (though maybe it is); I just thought there might be an answer at this time to my curiosity in an existing source that could be edited in, but the Prelim does not have it. DonFB (talk) 01:36, 25 April 2019 (UTC)

@EditorASC: What is the AT behavior with +20 kts (on right side) IAS DISAGREE? None of the articles I found mentions the relation between the two:

"The throttles are left at 94% thrust for the whole flight." ... "And with Stick Shaker and IAS disagree you keep high thrust and fly a slow climb" — Aron Manning (talk) 04:07, 26 April 2019 (UTC)

@EditorASC:@Aron Manning: I like Bjorn and think he has very interesting insights. However, in this case I found a B737 manual/checklist online that said something like "set thrust levers to 75% and 5 degree nose up attitude" in case of IAS uncertainty while you work the problem. So not sure about the "high thrust" statement, clearly if they had gone to 75% they would have had more margin.Greenbe (talk) 01:02, 28 April 2019 (UTC)

@Greenbe: My thoughts:

To understand the situation and the pilots' workload the "Accel Vert (g)" graph gives a strong insight. Throughout the whole flight after the stick-shaker activation Vertical Acceleration goes up and down in 3-5 second periods many times reaching 0.4 or 1.6 G, according to the FDR.

Mentour Pilot's simulator demonstration shows the pilot had to hold "firmly", probably hug the column to keep the airplane level. I presume he had difficulty reaching even the column trim switches, as he later asks the copilot to try trimming:

"At 05:41:46, the Captain asked the First-Officer if the trim is functional." (Likely he meant column trim, but this is not confirmed.)

The pilot was struggling to keep the plane straight and level: until 05:41:05 the "Accel Lat (g)" graph shows fluctuations between +-0.1g in 3 second periods, "Roll Attitude Disp" shows fluctuations between -3 and +6 degrees, sometimes more. "Six seconds after the autopilot engagement, there were small amplitude roll oscillations accompanied by lateral acceleration, rudder oscillations and slight heading changes. These oscillations continued also after the autopilot was disengaged."

"At 05:40:44, the Captain called out three times “Pull-up” and the First-Officer acknowledged.", between 05:40:46-:59 the FDR shows the copilot's "Ctrl Column Pos-R" is the same as "Ctrl Column Pos-L", 05:40:51-:57 the "Vert Accel" is almost constant 1.0).

After the pilot asked the copilot to help, around 05:41:05 the oscillations ceased, but the pilot was still struggling to keep it level. The vertical acceleration graph is going up and down until the end of the recording.

"At 05:41:30, the Captain requested the First-Officer to pitch up with him and the First-Officer acknowledged."

Between 05:41:52-:54 the right column shows less back-pressure, at this time the copilot was trying to hand-crank the trim wheel: "At 05:41:46, the Captain asked the First-Officer if the trim is functional. The First-Officer has replied that the trim was not working and asked if he could try it manually. The Captain told him to try. At 05:41:54, the First-Officer replied that it is not working."

After 05:41:54 the copilot's "Ctrl Column Pos-R" closely follows "Ctrl Column Pos-L" on the diagram (at 05:42:47 even showing higher force). Possibly the copilot was also holding the yoke with both hands from this time. The vertical acceleration graph shows smaller fluctuations.

"At 05:42:30, ATC instructed ET-302 to turn right heading 260 degrees and the First-Officer acknowledged."

From 05:42:30-05:43:07 the plane gradually rolls from 12 to 24 degrees bank.

At 05:42:51 the Master Caution warning gives them a tip, and they realize the source of the warnings: "At 05:42:54, both pilots called out “left alpha vane”."

As the plane rolled, around 05:43:07 the climb rate has decreased to zero.

"At 05:43:04, the Captain asked the First Officer to pitch up together and said that pitch is not enough."

"At 05:43:11, ... two momentary manual electric trim inputs are recorded in the ANU direction. The stabilizer moved in the ANU direction from 2.1 units to 2.3 units."

• Before Mcas activated, they already had oscillations (is this how turbulence looks like on the FDR?), IAS disagree, and the rattle of the stick-shaker. From the currently available data it seems to me the cockpit environment turned threatening very suddenly. Struggling to fly straight and level, the pilots became overloaded or startled. Misleading and contradicting warnings confused them and they lost overview of the situation. This is only one explanation among many.
• The report has no information about the extent of the "control issues". My reading of the FDR data is they were on a roller-coaster ride, possibly panicked, all their focus on keeping control of the airplane, both pilots firmly holding the yoke for the last ca. 2 minutes.
• About why the overspeed warning went unnoticed, I can only guess any of: 1) panic and fatigue caused tunnel vision 2) stick-shaker and repeated nose-down pitching suggesting low speed, thus ignoring airspeed as unreliable 3) reliance on AT, expecting it to be engaged.
• The oscillations preceding Mcas (6 seconds after AP activation) are suspicious. I find it possible the investigation might reveal deeper electronic issues.
• One sensor failure causing this many warnings and erratic behavior is also a shortcoming of the FCC design and a contributing factor to the excessive speed by confusing and overloading the pilots.
• At the end Mcas pitched down the airplane 40 degrees in 5 seconds by trimming down 1.3 degrees 1) contrary to maximum nose-up elevator input 2) out of the trim range possible with electric manual trim 3) at high airspeed (very sensitive trim) 4) and level flight (not a stall indirectly deducible) 5) with invalid input data: 74.5° AoA (falling like a brick; in comparison the max AoA on AF447's FDR was 41.5°) 6) from clearly faulty sensor (reading jumped from 35.7° to 74.5° in ¾ seconds) 7) that disagrees with the right AoA sensor at 11.1°. As sensors are expected to fail, basic design principles necessitate checking these parameters/constraints, but Mcas does not do so. This is a major contributing factor imo.
• There are many other contributing factors, as for all accidents. Blaming only one factor - as usually done by the media and in the conclusion of an investigation - is a gross oversimplification. The culture of blaming does not support understanding and learning from the mistakes. The purpose I believe is to find and document all contributing factors: how did the sensor fail, why the overspeed clacker went unnoticed, why the big vertical fluctuations, why did the trim move between 1.1 and 0.8 on the final dive, ...

— Aron Manning (talk) 04:07, 26 April 2019 (UTC)

Boeing ceo dropping clear hint when it comes to the blame game: "there was erroneous angle-of-attack information...and we know that ultimately that there were actions, or actions not taken, that contributed to the final outcome." https://www.bizjournals.com/wichita/news/2019/04/24/boeing-ceo-nothing-slipped-through-in-original-737.html He's a lifer at the company, but I'm surprised no call yet for him to vacate in light of what's been revealed about how that plane was designed. DonFB (talk) 03:10, 28 April 2019 (UTC)

@DonFB: The previous "apology" was written by a professional, but this ... he starts to sound like the FAA admin Daniel Elwell, who started the Senate hearing repeatedly telling "737 max is a fly-by-wire aircraft".

@Aron Manning: All true and correct. Remains to be seen if someone tries to blame the pilots for not following IAS disagree checklist or blames the plane for overwhelming the pilots. My vote is the ADIRU broke, not the AoA vane or electrical output from same. If you read the history in both prelim reports on all the service codes there were many spurious failures including an AoA that tested fine on ground, was replaced as precaution, and coded again on the next flight. That is why I zeroed on the data spike - if a spike is only consistent with a shear (rather than stuck-at) they will eventually find the part. If it is physically intact (ie no shear), then you start to look at the ADIRU for the root cause. I will look at all your links below later, but so far I think the reporting, analysis and characterization of both prelim reports has been woefully inadequate. This thing is much more complex than just a single piece of code overreacting. Plus I want to see the in-person live testimony of the third pilot on the Lion Air flight - that third set of eyes with lower workload will have the best perspectiveGreenbe (talk) 01:47, 28 April 2019 (UTC)

Yes, also a possibility. — Aron Manning (talk) 02:43, 28 April 2019 (UTC)

I've added aviation article sources to this section on the page from leehamnews.com, theaircurrent.com, satcom.guru, please review.
Unfortunately all *.guru domains are blacklisted by: "\b[_\-0-9a-z]+\.guru\b" on MediaWiki:Spam-blacklist.
Whitelisting requested: MediaWiki_talk:Spam-whitelist#satcom.guru
— Aron Manning (talk) 02:54, 27 April 2019 (UTC)

General info here:

WP:Spam_blacklist

Make request here:

MediaWiki_talk:Spam-whitelist

DonFB (talk) 03:39, 27 April 2019 (UTC)

Thank you.

@EditorASC:@Aron Manning:@DonFB: I just came across this I downloaded a copy before it too "disappears". I actually think it was pretty consistent at the technical level with a lot of what has been said on this talk section so far. One key thing it brings that we were all looking for was to understand whether some kind of auto-throttle was engaged. He goes in depth on this on pg 5. To summarize, he is saying that when they selected Level Change mode on the AP-L it is a pitch mode which means the auto-throttles remain engaged since TOGA was pushed at takeoff setting at 94% N1 but that is not connected directly to AP, and when AP-L disengaged itself auto-throttle likely remained at 94% N1 throughout the flight. They needed to fly manually targeting the pitch "flight-director" symbol on the primary flight display to maintain 238kts. Clearly they were not able to maintain that amount of pitch-up consistently as they were fighting a the automatic nose down trim hence increase in speed.

I want to make it clear by adding this reference I personally am NOT saying I believe it was pilot error. The big picture statistics do not support that for reasons I'll get into later. However, I cannot find fault with his basic chronology of events, actions and reactions. I would not be comfortable editing the main article based solely on this reference, but if you folks can point to additional supporting references (be it Boeing manuals or other analysis) that supports some of these key points I think we can edit citing this and 1-2 additional sources, with some disclaimers that no official sources have endorsed his view (yet). Greenbe (talk) 01:10, 2 May 2019 (UTC)

I haven't read the whole thing, but in what I've read, it twice mentions that they set 238kts in the "airspeed window" (example: "which the pilots had set in the airspeed window"). If the "airspeed window" is part of the Autopilot module, that would seem to answer the question of where/on what device 238kt was set: the Autopilot. Therefore (maybe), it might be possible, without any additional referencing, to make a small edit to the article to simply state that they "set 238 knots in the autopilot." Is there any other module where they could set the speed? But I would not recommend that the article, at this point, include the intricate details about autopilot/autothrottle/TOGA/runaway stabilizer/etc/etc. Perhaps, after the final report is issued, that kind of information could be added. DonFB (talk) 01:40, 2 May 2019 (UTC)

Hmm, I just noticed EditorASC's comments above (that I'd seen but forgot) in which he said, "The 'device' was the Mode Control Panel (MCP)." I defer to his knowledge, and would only reiterate my feeling that the article, right now, probably should not try to include a lot of speculative technical details (even if referenced) about events in the cockpit. DonFB (talk) 02:01, 2 May 2019 (UTC)

I assumed 238kt was set in the MCP. What I was trying to get at is whether the overspeed situation was a result of the plane's automation fighting with itself or the pilot's actions (or inaction). But clearly if the A/P mode selected did not affect the throttle setting then it is ultimately the pilot's responsibility to curtail the speed. If they pin the crash on overspeed then it points to pilots, if they pin it on MCAS or inadequate checklist then it points back to Boeing. Problem is they are going to try and un-ground the Max long before we have any updates to either prelim report I think so this will become a big story eventually, and it will get political. Anyway I agree we cannot edit until we get more references, especially official ones or reputable reporting with multiple sources in the investigation, FAA or Boeing. My scanning of Boeing's own accident data (for all manufacturers over 60 years) shows almost no fatalities in the last ~11 new passenger jet series introductions so what has happened is unprecedented in the last two decades for new series.Greenbe (talk) 23:08, 2 May 2019 (UTC)

References

Argument over black box analysis

The part where Ethiopia refused to send the flight recorders to the United States, and the fact that Germany was unable to do it as well? As those really noteworthy? Tigerdude9 (talk) 13:39, 1 May 2019 (UTC)

Not noteworthy. Just tell us where it was actually done. 82.132.225.36 (talk) 19:30, 1 May 2019 (UTC)

Additional Comments about proposed analysis section

"The report gives only a hint about the extent of it: 'Six seconds after the autopilot engagement, there were small amplitude roll oscillations accompanied by lateral acceleration, rudder oscillations and slight heading changes. These oscillations continued also after the autopilot was disengaged.'"

So what? Those do not indicate a CONTROL problem. There is no available evidence so far to show they did not have complete and proper responses to any inputs they made with their ailerons, spoilers and rudders. The fact that such oscillations were recorded by the FDR, does NOT indicate those were caused by anything other than pilots inputs to those controls. It would be a CONTROL problem along the lateral (roll) axis ONLY IF the pilots made inputs to those controls and did not get the appropriate response as would be expected. There is nothing in the FDR tracings to indicate they ever had any control problem, OTHER THAN a pitch axis control problem (which was caused entirely by the MCAS software algorithm response, regardless of what triggered that deadly response).

Erroneous warning information problems (AOA position, stick shaker and other EICAS warning lights and sounds, etc.) are NOT CONTROL problems. They are false information problems, or they are accurate warning information problems, like that presented with the overspeed warnings. But, they are NOT CONTROL problems.

"They would lose grasp of the yoke, but the FDR chart 1 shows column positions going from 8 to 5 degrees, not zero. As I demonstrated in the prev reply 0.4g accel compared to the cockpit is very violent. To reiterate: 6 storey fall in 3 seconds. If they hit the roof with their heads with 0.4g, almost half of their weight, I speculate they would be knocked out flat, if not with open skulls."

Why are you repeating his absurd conclusions? You think he was justified in making statements that were obviously not true? Because you spent so much time reading all those articles, we should rely on idiotic statements by authors like him who don't know what the hell they are talking about? I really don't get why you keep kicking that dead horse.

Your speculations about what happens to properly strapped in pilots during strong G-forces are as wrong as his. I have been thru severe turbulence over the Pacific that was able to break open some of the passenger overhead bins, but it never forced my hands off the control yoke.

There is nothing in the Prelim report that the pilots had any CONTROL problem other than the pitch axis control, that started only after MCAS began trimming the HS towards the full AND position. The actuation of ONE stick shaker (that the other one did not activate too, is an indication the one that did activate, was because of some computer error), is NOT a CONTROL problem. It is an erroneous information problem. The pilots still had control with their yokes, whether or not a stick shaker is activating. I have been thru years and years of sim training which required me to continue to fly the plane in a proper manner in spite of a stick shaker activating continuously. While irritating, the stick shaker does not reduce a pilots ability to manipulate the control column as he desires.

"It still boils down to his not knowing what the hell he is talking about. — EditorASC"

"I'd prefer avoiding ad hominem attacks."

Then I think you should try breaking out some books on the subject of logical discourse and pay particular attention to the chapters that list all the known logical fallacy (erroneous) arguments. You will find that refuting a false statement made by another is quite proper and since I attacked his idiotic ARGUMENT, not his person, it did not amount to an Ad Hominem attack. If I had said HE was an idiot, without mentioning the idiotic argument he proffered, then you would have a valid point. But, since it was his argument I attacked, you do not.

"@EditorASC: Why the caps, what's the problem?"

If there IS a problem, it is with you, not I. It should be obvious I choose to use CAPS as my form of EMPHASIS. It is a legitimate way to indicate emphasis. The others are Bold, Italics, or underlining. Since CAPS is the easiest and quickest way to indicate I want to emphasize a word or phrase, other than long sentences or paragraphs, then that is my choice. In normal verbal conversations, one can clearly indicate desired emphasis by his tone and volume of voice. But, since that cannot be done in written communications, it is legitimate to use one of those four methods indicated. The choice of what kind of emphasis lies with the author, not with the reader. You complain about getting off on irrelevant side tracks. That can be avoided by not wasting time complaining about how another author chooses to communicate his thinking.

"Anyway, this cherry-picked editorial exaggeration is not the focus of the article. We have veered off the topic, and spent too much effort with it."

To refresh your memory, YOU asked me what my opinion was about that author's comments. I responded truthfully, but now it becomes "cherry-picked editorial exaggeration?" If you don't really want my opinion then please don't ask me what I think about the comments of another author. EditorASC (talk) 12:06, 10 May 2019 (UTC)

References