Go Back  FlyerTalk Forums > Travel&Dining > TravelBuzz
Reload this Page >

737-Max 8 safety concerns

Old Jul 20, 2019, 7:49 pm

737-Max 8 safety concerns

Old Jun 24, 2019, 7:20 am
  #361  
A FlyerTalk Posting Legend
 
Join Date: Feb 2000
Location: Cambridge
Posts: 63,556
Originally Posted by jrl767
YOUR assumption, maybe ...
It is supported by the actual experience with the 737 Max where the in-house Boeing simulation never envisioned AoA sensor defect which leads to MCAS to continuously intervene.

They only realized that was a test scenario AFTER lots of fatalities.

This is despite the fact that AoA sensors are critical to MCAS and has a known failure rate which is much higher than the 1-in-10,000,000 that the classification for MCAS required.
Plato90s is offline  
Old Jun 24, 2019, 8:47 am
  #362  
FlyerTalk Evangelist
 
Join Date: Nov 2013
Location: Los Angeles
Posts: 12,550
Originally Posted by Plato90s
It is supported by the actual experience with the 737 Max where the in-house Boeing simulation never envisioned AoA sensor defect which leads to MCAS to continuously intervene.

They only realized that was a test scenario AFTER lots of fatalities.
Given the number of flights that never saw an AoA sensor failure, real life testing isn't likely to have led them to identify it as a failure mode to put in the simulator. Paper analysis should have recognized the failure mode, with real life testing to verify the behavior of the aircraft with a simulated AoA sensor failure.
chrisl137 is offline  
Old Jun 24, 2019, 9:30 am
  #363  
FlyerTalk Evangelist
 
Join Date: Nov 2009
Location: SEA (the REAL Washington); occasionally in the other Washington (DCA area)
Programs: DL PM 1.57MM; AS MVPG 100K
Posts: 21,309
Originally Posted by chrisl137
... analysis should have recognized the failure mode
this is the first part of the answer

the more important part of the answer is that the engineers and the analysts and the decision-makers (at all levels, and in all organizations) should NEVER have considered redundant AoA sensor input as anything less than a safety-critical element of the system
Originally Posted by chrisl137
... real life testing to verify the behavior of the aircraft with a simulated AoA sensor failure.
it’s very easy to simulate a sensor failure in either flight test or the simulator by pulling the circuit breaker

if I remember correctly, this would be considered a hazardous flight test condition and would probably have been a minimum-crew flight (pilots only, maybe a Test Director in the jump seat, no onboard observers); the preflight briefing would would go over both setup (to ensure stable flight conditions prior to pulling the breaker) and recovery procedures
DenverBrian likes this.
jrl767 is offline  
Old Jun 24, 2019, 11:29 am
  #364  
 
Join Date: Jan 2011
Location: Mountain Time Zone
Programs: AS Million Miler/Marriott Lifetime Titanium/ IGH Ambassador
Posts: 5,980
Originally Posted by jrl767

this is the first part of the answer

the more important part of the answer is that the engineers and the analysts and the decision-makers (at all levels, and in all organizations) should NEVER have considered redundant AoA sensor input as anything less than a safety-critical element of the system

its very easy to simulate a sensor failure in either flight test or the simulator by pulling the circuit breaker

if I remember correctly, this would be considered a hazardous flight test condition and would probably have been a minimum-crew flight (pilots only, maybe a Test Director in the jump seat, no onboard observers); the preflight briefing would would go over both setup (to ensure stable flight conditions prior to pulling the breaker) and recovery procedures
In the AF a "red X" condition
edgewood49 is offline  
Old Jun 24, 2019, 12:25 pm
  #365  
 
Join Date: Dec 2018
Location: Somewhere between BHX and HUY
Programs: Flying Blue Plat, Eurobonus Silver, ALL Gold
Posts: 1,663
Makes you wonder what other common malfunctions were not tested, nor even envisioned.
Maestro Ramen is offline  
Old Jun 24, 2019, 12:28 pm
  #366  
Ambassador: Emirates Airlines
 
Join Date: Sep 2004
Location: Manchester, UK
Posts: 18,556
There's very good article giving the history of MCAS on the 737 Max,

https://www.seattletimes.com/seattle...st-safeguards/

Early in the development of the 737 MAX, engineers gathered at Boeing’s transonic wind tunnel in Seattle to test the jet’s aerodynamics using a scale model with a wingspan comparable to that of an eagle.

The testing in 2012, with air flow approaching the speed of sound, allowed engineers to analyze how the airplane’s aerodynamics would handle a range of extreme maneuvers. When the data came back, according to an engineer involved in the testing, it was clear there was an issue to address.

Engineers observed a tendency for the plane’s nose to pitch upward during a specific extreme maneuver. After other efforts to fix the problem failed, the solution they arrived at was a piece of software — the Maneuvering Characteristics Augmentation System (MCAS) — that would move a powerful control surface at the tail to push the airplane’s nose down.

This is the story, including previously unreported details, of how Boeing developed MCAS, which played a critical role in two airliners nose-diving out of the sky, killing 346 people in Ethiopia and off the coast of Indonesia.

Continues...
Reading that, Boeing will be lucky survive with some of the lawsuits that will be heading their way
osamede likes this.
DYKWIA is offline  
Old Jun 24, 2019, 2:56 pm
  #367  
 
Join Date: Jan 2011
Location: Mountain Time Zone
Programs: AS Million Miler/Marriott Lifetime Titanium/ IGH Ambassador
Posts: 5,980
Originally Posted by DYKWIA
There's very good article giving the history of MCAS on the 737 Max,

https://www.seattletimes.com/seattle...st-safeguards/



Reading that, Boeing will be lucky survive with some of the lawsuits that will be heading their way
Boeing very well could be headed for the toilet and frankly the current management failed miserably and then lack the "balls" to just admit it and fall on their preverbal swords. No they tried to hide behind the FAA who is also now tarnished over this. When they moved the engines forward then raised the front wheel strut oh well history tells that tale. They should back this damn plane out of production maybe retro fit the existing planes and discount the ^*&*%**&^ out of them, for I am not flying a Max not today not tomorrow. Old AF saying "there are a lot of old FP, but few old bold FP"
edgewood49 is offline  
Old Jun 24, 2019, 3:24 pm
  #368  
 
Join Date: Nov 2007
Location: Colorado
Programs: UA Gold (.85 MM), HH Diamond, SPG Platinum (LT Gold), Hertz PC, National EE
Posts: 5,582
Originally Posted by DYKWIA
There's very good article giving the history of MCAS on the 737 Max,

https://www.seattletimes.com/seattle...st-safeguards/



Reading that, Boeing will be lucky survive with some of the lawsuits that will be heading their way
If 2008 showed us anything, it's that ultra large companies aren't going anywhere, tax payers will keep them afloat. So Boeing will be fine, just as GM did. Any of my opinions are for OMNI as to whether those decisions were correct or not.
COSPILOT is offline  
Old Jun 24, 2019, 7:31 pm
  #369  
A FlyerTalk Posting Legend
 
Join Date: Feb 2000
Location: Cambridge
Posts: 63,556
This is a truly shocking part, if true.

For example, there is a cutout switch in the control column so that when a pilot pulls or pushes in the opposite direction to a runaway stabilizer, it cuts electric power to the stabilizer. When MCAS is active, this cutout switch doesnt work, which could surprise a pilot who didnt know about the system.
(bolding mine)

That's is unconscionable. If the software actively TAKES AWAY a pilot's ability to control the aircraft and does so without notification - it's the opposite of safe.

The secrecy with which MCAS is designed to operate means that Boeing has made a sham out of its claim of safety being the top priority.

Time to market was its top priority.



Originally Posted by chrisl137
Given the number of flights that never saw an AoA sensor failure, real life testing isn't likely to have led them to identify it as a failure mode to put in the simulator. Paper analysis should have recognized the failure mode, with real life testing to verify the behavior of the aircraft with a simulated AoA sensor failure.
Not true - AoA sensor failures is a known issue including the 2008 Airbus crash

https://www.bloomberg.com/news/artic...lure-data-show

The failure to even test that scenario reflects the poor assumptions of Boeing's design team and why they should NOT be trusted when they claim it's safe via software-simulations Boeing controls.

Take the 737-Max out and do a full batter of FLIGHT tests before re-certifying it.
DenverBrian likes this.
Plato90s is offline  
Old Jun 24, 2019, 7:57 pm
  #370  
 
Join Date: Feb 2002
Location: BNA
Programs: HH Gold. (Former) UA PP, DL PM, PC Plat
Posts: 8,138
Originally Posted by Plato90s
This is a truly shocking part, if true.
It is not true. The author is confusing two different systems. (Or, if he understands it, he's presenting it in a way which leads others to be confused.

An unschedule MCAS activation can be overridden several ways by the pilots.

1. The easiest way to is use the primary electric trim switches, a set of which is on the outboard horn of each control wheel. These are the trim switches which a pilot uses to trim the aircraft when he is hand-flying. When either of these switches are activated during an MCAS activation, the MCAS activation is stopped and remains inhibited until five seconds after the trim switches are released. This would be the natural response to an airplane that is suddenly nose-heavy due to an unscheduled MCAS activation.

2. The primary and backup trim cutout switches below the throttles on the center console. Either of these switches will disable all electric trim including MCAS. These switches are used in the stabilizer runaway procedure (memory items) to disable all electric trim inputs.

3. Physically holding either of the trim wheels to prevent rotation. This is not something a pilot would normally do but it would work.

4. Extending the flaps. MCAS is inhibited with flaps extended.

What the article is talking about is the trim brake which is activated when control column movement opposes electric trim inputs. The trim brake does not stop MCAS because MCAS could not do its intended job if it did which is to increase the nose-down pitching moment at high angles-of-attack. By definition, you're going to be holding back-pressure in those situations and it is the job of MCAS to increase the amount of required back pressure. The trim brake is not something that a pilot would intentionally use to stop trim input. It works in the background to stop other scheduled trim inputs, generally from the speed trim system, when they aren't needed.
EmailKid, ajGoes and nancypants like this.
LarryJ is offline  
Old Jun 24, 2019, 8:43 pm
  #371  
A FlyerTalk Posting Legend
 
Join Date: Feb 2000
Location: Cambridge
Posts: 63,556
Originally Posted by LarryJ
It is not true. The author is confusing two different systems. (Or, if he understands it, he's presenting it in a way which leads others to be confused.

An unschedule MCAS activation can be overridden several ways by the pilots.

1. The easiest way to is use the primary electric trim switches, a set of which is on the outboard horn of each control wheel. These are the trim switches which a pilot uses to trim the aircraft when he is hand-flying. When either of these switches are activated during an MCAS activation, the MCAS activation is stopped and remains inhibited until five seconds after the trim switches are released. This would be the natural response to an airplane that is suddenly nose-heavy due to an unscheduled MCAS activation.

2. The primary and backup trim cutout switches below the throttles on the center console. Either of these switches will disable all electric trim including MCAS. These switches are used in the stabilizer runaway procedure (memory items) to disable all electric trim inputs.

3. Physically holding either of the trim wheels to prevent rotation. This is not something a pilot would normally do but it would work.

4. Extending the flaps. MCAS is inhibited with flaps extended.

What the article is talking about is the trim brake which is activated when control column movement opposes electric trim inputs. The trim brake does not stop MCAS because MCAS could not do its intended job if it did which is to increase the nose-down pitching moment at high angles-of-attack. By definition, you're going to be holding back-pressure in those situations and it is the job of MCAS to increase the amount of required back pressure. The trim brake is not something that a pilot would intentionally use to stop trim input. It works in the background to stop other scheduled trim inputs, generally from the speed trim system, when they aren't needed.
Not being a pilot, I would say that you have outlined actions which makes sense... once the pilot knows that there is a hidden software (MCAS) which is activating and controlling the aircraft.

If the operator knows about the software - dealing with it becomes much more straightforward.

But MCAS, as deployed, is malware. It's hidden from the operators and runs in a way which is NOT documented properly at all.

The highlighted portion illustrates the point that a powerful software function is altering the functions in an undocumented and unanticipated manner.

As you noted, 737 pilot does NOT expect to have to hold the trim wheels which suddenly start rotating on its own. Since pilots are human beings instead of robots, unexpected behavior which is outside the expected parameters creates confusion. The entire situation would have been avoided if Boeing hadn't focused on secrecy in order to get quick-certification without pilot retraining.

That's why, IMO, the blood of 300+ people are on the hands of Boeing executives and employees.

If they truly feel no guilt and no responsibility and believe the company line of "well, the pilots could have saved the plane"... then they are (IMO) monsters.
Mykal, DenverBrian and osamede like this.
Plato90s is offline  
Old Jun 24, 2019, 10:09 pm
  #372  
 
Join Date: Feb 2002
Location: BNA
Programs: HH Gold. (Former) UA PP, DL PM, PC Plat
Posts: 8,138
Originally Posted by Plato90s
Not being a pilot, I would say that you have outlined actions which makes sense... once the pilot knows that there is a hidden software (MCAS) which is activating and controlling the aircraft.
As a 737 pilot, I disagree.

None of the corrective actions, other than extending flaps, require knowledge of MCAS. Extending flaps, though it would work, is not part of the applicable procedures and is not how a crew should respond to an unschedule MCAS activation.

Unscheduled MCAS presents as a runaway stabilizer and the existing runaway stabilizer procedure is how it should be handled. The longer you delay applying the appropriate procedure(s), the farther the stabilizer runaway (regardless of cause) progresses and the more difficult it will be to recover. A stabilizer runaway event is not the time to delay while considering the possible causes. The first items on the checklist are called "Immediate Action Items" for a reason. They need to be accomplished promptly to prevent the situation from deteriorating further.
ajGoes likes this.
LarryJ is offline  
Old Jun 25, 2019, 12:32 am
  #373  
FlyerTalk Evangelist
 
Join Date: Nov 2013
Location: Los Angeles
Posts: 12,550
Originally Posted by Plato90s
Not true - AoA sensor failures is a known issue including the 2008 Airbus crash
Any sensor failure should be an identifiable issue, but given aircraft reliability requirements they aren't likely to show up during flight testing unless forced. Which is why I pointed out that it would be identified as a failure mode by analysis and then flight tested (as jrl767 pointed out, by pulling a breaker, though it would also be a good idea to insert a fake sensor in the circuit so a range of anomalous values could be forced)
chrisl137 is offline  
Old Jun 25, 2019, 4:32 am
  #374  
Ambassador: Emirates Airlines
 
Join Date: Sep 2004
Location: Manchester, UK
Posts: 18,556
Originally Posted by LarryJ
Unscheduled MCAS presents as a runaway stabilizer and the existing runaway stabilizer procedure is how it should be handled. The longer you delay applying the appropriate procedure(s), the farther the stabilizer runaway (regardless of cause) progresses and the more difficult it will be to recover. A stabilizer runaway event is not the time to delay while considering the possible causes. The first items on the checklist are called "Immediate Action Items" for a reason. They need to be accomplished promptly to prevent the situation from deteriorating further.
How would a runaway stabilizer be identified? The nose starting to pointing down (or up) and the trim wheel turning? If so, then it must be horrific if there are other thing going on at the same time (stall stick shaker / overspeed clacker).
DYKWIA is offline  
Old Jun 25, 2019, 7:15 am
  #375  
FlyerTalk Evangelist
 
Join Date: Nov 2009
Location: SEA (the REAL Washington); occasionally in the other Washington (DCA area)
Programs: DL PM 1.57MM; AS MVPG 100K
Posts: 21,309
Originally Posted by chrisl137
Any sensor failure should be an identifiable issue, but given aircraft reliability requirements they aren't likely to show up during flight testing unless forced. Which is why I pointed out that it would be identified as a failure mode by analysis and then flight tested (as jrl767 pointed out, by pulling a breaker, though it would also be a good idea to insert a fake sensor in the circuit so a range of anomalous values could be forced)
that would probably occur in the developmental lab or the simulator, NOT in actual flight testing, as you want to minimize the number of hazardous conditions that involve the jet and the flight crew ...
ajGoes likes this.
jrl767 is offline  

Thread Tools
Search this Thread

Contact Us - Manage Preferences - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service -

This site is owned, operated, and maintained by MH Sub I, LLC dba Internet Brands. Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Designated trademarks are the property of their respective owners.