Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Old 8th Nov 2019, 18:49
  #3821 (permalink)  
 
Join Date: Dec 2018
Location: Florida
Posts: 98
Talking

Originally Posted by Lake1952 View Post
https://flightaware.com/live/flight/BOE1

Edited to note : The test flights all show up on flightaware.com as BOE1. There is a new extensive flight test today, Nov 7, although my original post was about the Nov 2 flight. You can see the history of the test flights on this site.
If you look at yesterday's flight track log, it looks a bit like an electrocardiogram in atrial flutter! Must have tried to stall a dozen times.
Lake1952 is offline  
Old 8th Nov 2019, 20:06
  #3822 (permalink)  
Thread Starter
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 625
Originally Posted by GordonR_Cape View Post

This story is almost a textbook example of hubris and nemesis. If MCAS had not been included on the MAX, none of this would be happening. The MAX would never have been grounded, and would be flying today with the same 'relative' level of safety as the NG series.
Yes, very likely, assuming, of course, that the pitchup tendency at some attitudes and corners of the envelope isn't worse than we now know.

OldnGrounded is offline  
Old 8th Nov 2019, 20:10
  #3823 (permalink)  
Thread Starter
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 625
Originally Posted by Lake1952 View Post
If you look at yesterday's flight track log, it looks a bit like an electrocardiogram in atrial flutter! Must have tried to stall a dozen times.
And we don't know exactly what led to or what terminated all those rapid descents. I'm sure there are plenty of reasonable guesses, of course . . .
OldnGrounded is offline  
Old 8th Nov 2019, 21:13
  #3824 (permalink)  
 
Join Date: Apr 2015
Location: Northumberland
Posts: 51
Originally Posted by Lake1952 View Post
If you look at yesterday's flight track log, it looks a bit like an electrocardiogram in atrial flutter! Must have tried to stall a dozen times.
Tbf AF is more predictable than the 737 Max.
nonfrequentflyer_NCL is offline  
Old 8th Nov 2019, 22:11
  #3825 (permalink)  
 
Join Date: Jun 2009
Location: florida
Age: 77
Posts: 1,128
Salute!

Some interesting thots Gordon and Grounded.

Mods cut off the Tech Log, But I'll post here and save the draft if this thread continues to be political and managment stuff and no serious tech discussion.

There could be more aero characteristics than the AoA vs stick force gradient. Yeah, it's nice to have the same "feel" as other planes ( not just the 737, although many Airbus planes do not have any such "feel"). The beast must be very "slippery", huh? By that I mean little "speed" stability. Checking out in Cessnas, Chipmunks, Champs, etc. , we old farts and many newbies learned the effects of changes in AoA upon control forces, and that speed can make it harder or easier to move the controls.

Somewhere along the line Boeing added STS, and the system doesn't seem to be an aerodynamic feature, but a sfwe feature that also does not seem to be directly AoA dependent, just speed. So why not implement something like MCAS and let the basic plane aero design alone? Hmmm....

Gums ponders....
gums is offline  
Old 8th Nov 2019, 22:29
  #3826 (permalink)  
 
Join Date: Jul 2002
Location: In the sticks
Posts: 7,095
Being reported that Southwest have removed the Max from their flight schedule until March 6th.

Also now being reported that American Airlines have removed the Max until March 5th

Last edited by LTNman; 8th Nov 2019 at 22:43.
LTNman is offline  
Old 8th Nov 2019, 23:09
  #3827 (permalink)  
 
Join Date: Mar 2010
Location: L.A.
Age: 52
Posts: 556
Originally Posted by Uplinker View Post
Quite so.

Also, I don’t understand why the software issue is/was so difficult. In the USA they have all the software expertise of Silicon Valley; e.g, Apple etc. So why - if it is true - did Boeing use cheap freelance software writers, and not tap into the excellent home grown talent they have?
The original 737 hardware was the 286 processor, and they were still using it in the NG.
If the same is true for the Max, the number of Silicon Valley techies who understand this antiquated system (both hardware and software) is limited.

Silver

silverstrata is offline  
Old 9th Nov 2019, 00:00
  #3828 (permalink)  
 
Join Date: Mar 2015
Location: Washington state
Posts: 210
By contrast, the 737 Max had two separate computers. One operated the flight systems and another was available if the first one failed, with the roles switching on each flight. But they interacted only minimally.

Boeing decided to make the two systems monitor each other so that each computer can halt an erroneous action by the other. This change is an important modernization that brings the plane more in line with the latest safety technology but raised highly complex software and hardware issues.
What Boeing is trying to do here is really hard, even leaving out the fact that they are using a 286 (which is not ancient, you damn whippersnappers!), a homebrew 'operating system', and have probably zero institutional memory of the baseline code. The estimate “Where before you may have had 10 scenarios to test, I could see that being 100" is off by several orders of magnitude. I know, I did this kind of stuff and it is some of the most frustrating programming you can imagine. (It is a constant war between "data corruption" and "everything locks up"; anyone can understand the theory of critical sections but in practice...) It sounds so simple in the boardroom and looks so neat on the whiteboard but in real life it is a nightmare. I was part of a team that was pretty familiar with this sort of issue and a new major release would take about two years to get properly tested and even after release for the next three months or you could count on getting a call in the middle of the night about data corruption. (I won't go much further but lets just say I have concerns about our financial system as well other data critical enterprises such as elections.)

The plan to have computer #1 inspect computer #2 and halt it if it thinks it is in error is about as asinine as swapping the roles of the computers each flight. As someone who moved onto playing with real world systems with big things that sometimes stop moving, the last thing you want when trying to figure out what went wrong is a system that swaps which processor/sensor is in use based on some unknown criteria. Flight #1 exhibits a critical problem, test Flight #2 shows 'no trouble found', Flight #3 goes back to the bad processor and crashes. What frigging genius came up with that? Oh, the same genius who swapped the 'active' AOA indicator for MCAS.

However, aside from that, what they are talking about is not only really hard, but now you have to test scenarios of erronious computer shutdown at any frigging time during the duration of the flight. This is really the same rancid logic behind MCAS; a solution for an extremely rare event now creates its own problem in much more common situations. How many benign problems are in the processing code that are now going to trigger this 'kill' subroutine? What happens if the two computers get into a war with each other? How robust is the communication line between the computers, which was probably never designed to deal with the amount of data that now has to be transferred?

No wonder they did not want to completely document what they did.

In my opinion, the right solution for their computer failure scenario is to figure out how to enable the pilot to resolve it, not to try to come up with a patched together failsafe computer system that wasn't designed to be failsafe from the beginning. I have no idea whether this involves more indicator lights (I know, I know), or some sort of manual override, or some kind of hardware solution (like physically preventing the computer from misconfiguring the plane) but the right solution is surely not to create an exponentially more complex computer system in a hurry.
Water pilot is offline  
Old 9th Nov 2019, 00:32
  #3829 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 459
To add to that Water pilot,

It seems that the FAA and other regulators want not only documentation of the changes, but also supporting evidence of Boeing's optimistic classifications of risks of failures to changes.

Boeing do not seem yet to understand that the old days of Boeing saying we classify the risk as (a rung or two lower than it should be) X, so we comply by doing Y&Z - stamp please!
They seem surprised that the risk must be accurately classified and not "accountantly" classified, as it all ways should have been.

The Boeing management think they made just a few simple errors in the past, but overall they have and still do exceptional work and everyone should just let the couple of errors slide. We know better so just let us do our thing - trust me.
Bend alot is offline  
Old 9th Nov 2019, 01:05
  #3830 (permalink)  
Psychophysiological entity
 
Join Date: Jun 2001
Location: Tweet Rob_Benham Famous author. Well, slightly famous.
Age: 80
Posts: 4,761
. . . In my opinion, the right solution for their computer failure scenario is to figure out how to enable the pilot to resolve it, . . .
In my suggested, quick cut followed by four stage reintroduction, the last item to be reinstated is MCAS, but wait, can that specific software be divorced from the autopilot and indeed, STS? I assume it can't or there would be no need to ferry the MAX at snail's pace with a notch of flap down.

It seems the only way to inhibit MCAS would be by say, selecting a menu line saying as much, but that in itself is just a few lines of glitch-vulnerable code.

I get the feeling that the only safe design is for MCAS to be a quite separate black box with readily interruptible hard-wiring to the tail.
Loose rivets is offline  
Old 9th Nov 2019, 03:06
  #3831 (permalink)  
 
Join Date: Dec 2001
Location: Brisvegas
Posts: 2,766
the right solution for their computer failure scenario is to figure out how to enable the pilot to resolve it, . . .
They could make the (manual) electric trim switches on the control column override MCAS trim input. Oh wait...
Icarus2001 is offline  
Old 9th Nov 2019, 03:39
  #3832 (permalink)  
 
Join Date: Aug 2007
Location: Alabama
Age: 54
Posts: 365
Originally Posted by Icarus2001 View Post
They could make the (manual) electric trim switches on the control column override MCAS trim input. Oh wait...
Sorry but i disagree, first of all we need to classify if MCAS is a stall warning or a stall identification system, once we define that we can define what are the actions required. According to certification a pilot should be able to disable a stall id system and such system should not be prone to a single failure. That is not the case of MCAS. To off it pilots loose all electrical controls on the stab, and MCAS is prone to single AoA failure, that is the reason why it was classified as a augmentation system...when in my opinion is a stall ID system... cutting corners to solve major issue
FrequentSLF is offline  
Old 9th Nov 2019, 04:17
  #3833 (permalink)  
 
Join Date: Feb 2006
Location: USA
Posts: 432
Seattle Times

https://www.seattletimes.com/busines...x-assumptions/

After Lion Air crash, Boeing doubled down on faulty 737 MAX assumptions
Nov. 8, 2019 at 6:42 pm Updated Nov. 8, 2019 at 7:57 pm

By Dominic Gates
Seattle Times aerospace reporter

Seven weeks after the crash of a Boeing 737 MAX operated by Lion Air killed 189 people in Indonesia, the jetmaker made a detailed presentation to the Federal Aviation Administration (FAA) justifying its design of the flight control system that had repeatedly pushed the jet’s nose down.

It concluded, in an exculpatory phrase repeated on multiple slides, that there was “No process violation or non-compliance” in how the jet was certified by the regulators.

But in hindsight, details in the December 2018 slide presentation reveal serious holes in the original evaluation of the Maneuvering Characteristics Augmentation System (MCAS) flight-control software.

Equally troubling, despite clear indications from the previous month’s Lion Air tragedy that the pilots had not responded as Boeing’s safety analyses assumed, the presentation reiterated the same assumptions and never approached the question of whether the MAX should still be flying.

Flaws in the original safety analysis of MCAS are apparent now after a second crash involving an Ethiopian Airlines MAX in March, and a great deal of reporting on what went wrong on both flights. That December presentation reveals Boeing’s thinking soon after the first crash and indicates both a substantial effort to deflect blame and a missed opportunity to reevaluate before the second crash happened.

The presentation shows that Boeing in its original certification of the MAX:
  • Presented MCAS to the FAA as not being a “new and novel” technology — and thus not requiring deeper scrutiny. The justification given was a doubtful comparison with the 767 tanker.
  • Did not consider in its safety assessment the effect of multiple system failures and how this would affect the reactions of the pilots.
  • Used questionable math to downgrade the system’s risk classification below a level that would have required more redundancy with at least two sensors to activate it.
  • Made a key safety assessment prior to a major change in the design of MCAS, and did not reevaluate the system again before certification.
Dismissed one scenario in which an MCAS failure was assessed as “catastrophic,” sticking — despite the Lion Air experience — to its prior assumption that “appropriate flight crew action” would save the aircraft.

Boeing’s message to the FAA that December — which formed the basis of multiple public statements by CEO Dennis Muilenburg since — was that MCAS had been certified using the company’s standard processes and was compliant with all FAA regulations.

In a statement Friday, Boeing reiterated: “The FAA considered the final configuration and operating parameters of MCAS during MAX certification, and concluded that it met all certification and regulatory requirements.”

Peter Lemme, a former Boeing flight-controls engineer and avionics expert, describes this as the company’s “stay-the-course, admit-no-fault mentality.”

“Boeing failed to properly reassess the situation, doubling down on their assumptions instead of immediately disabling MCAS to remove any chance of further disaster,” Lemme wrote on his blog devoted to analysis of the MAX crashes.

As a result, Boeing and the FAA maintained their position that the MAX was safe until forced to ground the jet 12 weeks later after another 157 people died in a similar crash in Ethiopia.

A flawed process
The U.S. House Transportation and Infrastructure Committee, which displayed one slide from Boeing’s presentation during an appearance by CEO Muilenburg at a hearing last week, provided all 43 slides in the document at the request of the Seattle Times. The presentation is titled “MCAS Development and Certification Overview.”

It notes that MCAS was not evaluated as an individual system that was “new/novel on the MAX.” The significance of this term is that the FAA is required to be closely involved in the testing and certification of any new and novel features on an aircraft.

Though MCAS was new on the MAX version of the 737, Boeing argued that it wasn’t new and novel because a similar system “had been previously implemented on the 767” tanker for the Air Force.

Yet MCAS on the MAX was triggered by just one of the jet’s two angle-of-attack sensors, whereas MCAS on the 767 tanker compared signals from both sensors on the plane. When asked after the second crash to explain why the airliner version lacked this same redundancy, Boeing’s response was that the architecture, implementation, and pilot interface of the KC-46 tanker MCAS were so different that the two systems shared little but the acronym.

Laying out how Boeing originally assessed MCAS internally, the December 2018 presentation tells how first a standard preliminary risk assessment was done — it’s called a Functional Hazard Assessment (FHA) — by pilots in flight simulators.

They did not simulate the real-world scenario that occurred in the crash flights when a single sensor failed and prompted the cascade of warnings in the cockpit. Instead, the pilots simply induced the horizontal tail, also known as the stabilizer, to swivel as MCAS would have moved it to pitch the nose down in a single activation.

The pilots successfully demonstrated that they could then recover the aircraft. They did so simply by pulling back on the control column. They didn’t even have to use what Boeing later described as the final step to stopping MCAS: hitting the cut-off switches that would have killed electrical power to the stabilizer.

“Accumulation or combination of failures leading to unintended MCAS activation were not simulated nor their combined flight deck effects,” Boeing said in the presentation.

Those pilots also did not simulate the crash flight scenario of MCAS misfiring multiple times — in the case of Lion Air, 27 times before the plane nose-dived into the sea.

Boeing notes in the presentation that much later, in June 2016 during flight tests of the MAX, its engineers did discuss this scenario of “repeated unintended MCAS activation” with its test pilots. They concluded that this would be “no worse than single unintended activation.

As proof that discussion occurred, Boeing’s presentation mentions an internal email summary. Yet Boeing concedes that the discussion and its conclusion apparently never made it to the ears of the FAA. Boeing said it was “not documented in formal certification” papers.
The initial FHA classified an erroneous activation of MCAS during the normal phases of flight as a “major” risk.

This is a significant yet relatively low-level risk category, signifying an event that could cause some upset inside the aircraft but would not typically lead to serious injuries or damage. A manufacturer must do detailed calculations to prove that the chance of such a failure happening is less than one in 100,000.

This classification of MCAS proved fateful. It meant that Boeing did not go on to conduct two more detailed analyses of MCAS — a Fault Tree Analysis and a Failure Modes and Effects Analysis — for the system safety assessment it sent to the FAA.

It also meant that MCAS could be designed with just a single sensor.

This is despite the fact that the same FHA established that a similar MCAS malfunction during an extreme, high-speed, banked turn would be a “hazardous” risk. This is a much more serious risk category where some serious injuries and fatalities could be expected. It’s one level short of “catastrophic,” in which the plane is lost with multiple fatalities. The probability of a “hazardous” failure has to be demonstrated as less than 1 in 10 million.

Lemme notes that a “hazardous” classification typically requires that redundancy be designed into the system, with a comparison of at least two sensors being used to activate it.

However, Boeing avoided this for MCAS.

It argued that since the probability of a MAX airliner getting into such an extreme, high-speed, banked turn was just one in 1,000 and that the chance of an MCAS “major” malfunction was less than 1 in 100,000, the combination meant the chance of both together happening was less than 1 in 100 million — which “meets the Hazardous integrity requirements.”

A report on the certification of the MAX released last month by an international panel of air-safety regulators, the Joint Authorities Technical Review (JATR), states that this mathematical discounting of the risk “is not a standard industry approach.”

An FAA safety engineer, who asked for anonymity because he spoke without agency approval, explained why that’s questionable math. He offered the example of how aviation engineers work out the probability of an engine failure complicated by an added factor of ice forming around the engine.

They don’t consider that an aircraft will encounter icing in, say, one of 500 flights and then combine that probability with whatever system failure is in question to produce a lower probability. Instead, they just assume that icing will happen, because sometime it definitely will.

On Friday, Boeing said that it calculated the probability according to an accepted method, adding that “recently there has been discussion of revising this practice but no new standards have been set.”

The presentation also describes how a separate analysis was done of multiple system failures on the 737 MAX, which would have included MCAS.

However, this was “completed prior to the design change to MCAS,” when Boeing decided in March 2016 to extend the system’s operation to low-speed normal flight. The presentation states, “reevaluation of design change not required,” per Boeing’s process.

As a result, Boeing conceded that the version of MCAS included in the system safety assessment sent to the FAA “was not updated to reflect certified design.”

However, it assured the FAA that it had done a new post-Lion Air assessment of the redesigned MCAS, which concluded that a revised analysis “would have included the same crew action that is already considered” and so wouldn’t have changed the outcome.

On Friday, Boeing in a statement said that despite this admitted glitch in the documentation, “Boeing informed the FAA about the expansion of MCAS to low speeds, including by briefing the FAA and international regulators on multiple occasions about MCAS’s final configuration.”

One scenario in the multiple system failure analysis is on the slide the House committee displayed during last week’s hearing.

It shows that when engineers analyzed the case of one angle of attack sensor not working and the second giving an erroneous signal, the combined effect on all systems, not just MCAS, was “deemed potentially catastrophic.”

However, again Boeing concluded this was “acceptable” because of the expectation of “appropriate crew action” to counter the emergency, plus the calculation that such a dual angle-of-attack failure was “extremely remote,” specifically that it would occur in less than one in a billion flights.

However, for MCAS to go haywire required only one angle-of-attack failure, a much higher probability.

Boeing knew that such an event had happened twice on successive Lion Air flights just seven weeks earlier, both on the crashed flight and on the prior flight.

And it knew that the crew action it had expected hadn’t occurred, even on the prior flight when the pilots managed to recover.

Nevertheless, Boeing’s presentation both justified its original analysis and reiterated its position: if MCAS failed, the crew would save the plane and all on board.

The presentation also solves one small mystery. Boeing notes how the FAA agreed with it to remove all mention of MCAS from the pilot manuals and pilot training.

So why was the acronym MCAS listed in the glossary at the back of the pilot manual, though nowhere else?

That was a mistake, Boeing said, “left behind from earlier drafts” before mention of MCAS was excised.

Dominic Gates: 206-464-2963 or [email protected]; on Twitter: @dominicgates.
Zeffy is offline  
Old 9th Nov 2019, 05:45
  #3834 (permalink)  
 
Join Date: Jan 2013
Location: Seattle Area
Posts: 154
I don't know why the other new thread about Congress raising concerns about the Max and 787 was closed, but here is the letter from the House Transportation and Infrastructure Committee to the FAA. It's a bit of thread drift, but related. Hopefully I'm not repeating some transgression.

https://transportation.house.gov/imo...g%20covers.pdf
Dave Therhino is offline  
Old 9th Nov 2019, 07:29
  #3835 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 11,037
Originally Posted by silverstrata View Post
The original 737 hardware was the 286 processor, and they were still using it in the NG.
Intel 80286: 1982
Boeing 737: 1968

DaveReidUK is online now  
Old 9th Nov 2019, 07:40
  #3836 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 421
Originally Posted by DaveReidUK View Post
Intel 80286: 1982
Boeing 737: 1968
The Boeing 737 Classic (-300 onwards) was introduced in 1984. That is the benchmark for the FCCs, not the -200 model.
GordonR_Cape is online now  
Old 9th Nov 2019, 08:23
  #3837 (permalink)  
 
Join Date: Jul 2007
Location: Switzerland
Age: 74
Posts: 94
Originally Posted by Dave Therhino View Post
I don't know why the other new thread about Congress raising concerns about the Max and 787 was closed, but here is the letter from the House Transportation and Infrastructure Committee to the FAA. It's a bit of thread drift, but related. Hopefully I'm not repeating some transgression.

https://transportation.house.gov/imo...g%20covers.pdf
I wonder how much longer the insurance companies will wait to revoke their contracts regarding Max, NG (pickle forks) and Dreamliner so obviously not meeting safety standards.
clearedtocross is offline  
Old 9th Nov 2019, 10:13
  #3838 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 459
Originally Posted by clearedtocross View Post


I wonder how much longer the insurance companies will wait to revoke their contracts regarding Max, NG (pickle forks) and Dreamliner so obviously not meeting safety standards.
Insurance for passengers on airlines is very restricted.

So with the clout of Boeing, I doubt much will be said by insurance companies.

Do not forget the FAA "certified" the aircraft not Boeing.
Bend alot is offline  
Old 9th Nov 2019, 11:13
  #3839 (permalink)  
 
Join Date: Jul 2007
Location: Switzerland
Age: 74
Posts: 94
Originally Posted by Bend alot View Post
Insurance for passengers on airlines is very restricted.

So with the clout of Boeing, I doubt much will be said by insurance companies.

Do not forget the FAA "certified" the aircraft not Boeing.
This may be true for normal pax insurance for a „normal“ aircraft. But how about product liability? The FAA will not cough up a single dime for a now known design deficiency by B, neither for the hardware or 3rd party damage.
clearedtocross is offline  
Old 9th Nov 2019, 11:38
  #3840 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 459
Originally Posted by clearedtocross View Post


This may be true for normal pax insurance for a „normal“ aircraft. But how about product liability? The FAA will not cough up a single dime for a now known design deficiency by B, neither for the hardware or 3rd party damage.
Boeing were adamant the aircraft was correctly certified (it did have the FAA "tick") and the FAA will tick again when the pressure is enough it seems.

Correct the FAA will never cough up a dime.

A VERY staggered release to re certification may by in years not months.
Bend alot is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service - Do Not Sell My Personal Information

Copyright © 2018 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.