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 6th Aug 2019, 19:14
  #1801 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 58
Posts: 419
Originally Posted by HighWind View Post
I you remove the code for MCAS then it can't generate a runaway
But the Flight Control System have been connected to the trim for decades, and a bit-flip in other functions of the Flight Control Computers might be able to generate a 'continues' runaway. (Way easier to diagnose quickly, than a intermittent runaway)
I see MCAS as a change that changed the reliability of the FCS from being several magnitudes better than specified by DAL C, to about the limit of DAL C.

You can't complain when a DAL C design, changes from e.g. DAL B to DAL C reliability following a design change. (The same could have happened due to e.g. a die shrink )
Using one AoA sensor might sufficient for DAL C, but not for the required DAL A.
IMO the fundamental issue with the MAX (and this is not a problem with the NG) is that for MCAS to operate, the FCC must have a relay that inhibits the pilots column trim cutout switches. Previously NG pilots had an intuitive and effective way to inhibit computer generated runaway trim - just pull or push the yoke. IMO this obviates specific need for high reliability on the NG FCC, because there is no equivalent relay.

Way back in previous discussions, we saw an incredibly complex diagram of relays for the stabiliser trim. It seems that neither Boeing (nor the FAA) tested this fully before launch. That's what happens when you over-complicate things, and the consequences are clear. The MAX is a new aircraft, where previously unanticipated failure modes arise (and not just MCAS).

To fix the new problem on the MAX, while using the existing FCCs, a fail-neutral option is the chosen option, since DAL A is not feasible with the 737 architecture. The solution noted by the Seattle Times would be done in addition to whatever fixes are made to MCAS, and produce a slightly better outcome than the NG for runaway trim cases.
GordonR_Cape is online now  
Old 6th Aug 2019, 20:50
  #1802 (permalink)  
 
Join Date: May 2013
Location: Milan
Age: 32
Posts: 135
BOE001 from Seattle https://fr24.com/BOE001/21973bf9

Flying right now
anto125 is offline  
Old 6th Aug 2019, 21:59
  #1803 (permalink)  
 
Join Date: Jun 2019
Location: Tana
Posts: 0
I haven't been following either the investigation or this thread too closely, so pardon if this has already been discussed. As far as I understand, MCAS only activates if the flaps are 0. If it has already activated, is it disabled if you set FLAPS 1? And if so, is it disabled after you SELECT Flaps 1 or when the actual flaps are in the FLAPS 1 position? Does anyone know?
UltraFan is offline  
Old 6th Aug 2019, 22:21
  #1804 (permalink)  
Thread Starter
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 604
Originally Posted by UltraFan View Post
I haven't been following either the investigation or this thread too closely, so pardon if this has already been discussed. As far as I understand, MCAS only activates if the flaps are 0. If it has already activated, is it disabled if you set FLAPS 1? And if so, is it disabled after you SELECT Flaps 1 or when the actual flaps are in the FLAPS 1 position? Does anyone know?
The only people who could possibly know what actually happens are a very small number of Boeing test pilots. And I doubt if they do.
OldnGrounded is offline  
Old 6th Aug 2019, 23:04
  #1805 (permalink)  
 
Join Date: Mar 2006
Location: Vance, Belgium
Age: 57
Posts: 166
Originally Posted by Notanatp View Post
What is the basis for your statement that flipping five bits "is the standard procedure for this category of tests"?
Originally Posted by Seattle Times
...
This was standard testing that’s typically done in certifying an airplane, but this time it was deliberately set up to produce specific effects similar to what happened on the Lion Air and Ethiopian flights.
...
During the tests, 33 different scenarios were artificially induced by deliberately flipping five bits on the microprocessor, an error rate determined appropriate by prior analysis. For all five bits, each 1 became a 0 and each 0 became a 1. This is considered a single fault, on the assumption that some cause, whether cosmic rays or something else, might flip all five bits at once.
For these simulations, the five bits flipped were chosen in light of the two deadly crashes to create the worst possible combinations of failures to test if the pilots could cope.
(my emphasis)

About the bit selection ; 1 bit for MCAS status "engaged" (disabling the control column switches), 1 bit for nose down pitch trim command, and 3 bits for undetailed "complications" (for instance: airspeed disagree warning).
The later description of how the scenario unrolled clearly shows that it's the first 2 bits plus a 3 seconds startling delay that are critical for dooming the plane in 1 occurrence over 3.
Luc Lion is offline  
Old 7th Aug 2019, 00:44
  #1806 (permalink)  
 
Join Date: Jan 2008
Location: Hanoi
Posts: 39
Originally Posted by Notanatp View Post
Interestingly, none of the reporting has said just how likely the test scenario was to occur in flight, other than to say it was "esoteric," or "theoretical," or "extremely improbable."

The test simulated the effect of 5 bits being simultaneously flipped in the FCC's memory due to cosmic rays or some other unnamed cause. The 5 bits were independent. One bit was flipped to tell the FCC that MCAS was active when it wasn't (this disabled the yoke cut-off switches). Another bit told the FCC to incorrectly issue a nose-down trim command. The other 3 bits weren't described but apparently were necessary to create the runaway trim scenario.

Assuming a 5-bit event, the odds of these 5 specific bits being flipped depends on the size of the memory. If the FCC has 1-megabyte of RAM, then the odds of those particular 5 bits being flipped in a 5-bit event should be on the order 10**-32. I don't know how frequently the FAA estimates a 5-bit event will occur on an aircraft with a 1-meg memory, but even if it approaches 1 (i.e., it can be expected to happen each flight), the likelihood of this particular 5-bit event occurring on any single flight is on the order 10**-32. You could fly all the 737 Max's that will ever be made 3 times a day for a billion years, and you'd still be looking at probabilities on the order of 10**-16.
No competent implementor of high safety software (or hardware) does not use hardware AND software protection against memory corruption (where hardware protection is available - sometimes it is not depending on your hardware limitations), unless the hardware and software on this aircraft are being audited against grandfathered safety standards from the 1960's then the failure you describe must be a failure which would be deemed unacceptable . . .

Bit level corruption in any part of memory would be detected and the corrupt data not acted upon, the action taken when the corruption is detected being defined by the system requirements and the safety rating (largely), e.g. is the system fail safe, fail functional for example. There are many well understood mechanisms which are used to perform this function to varying levels of integrity (because not all safety cases require the most computationally and physically expensive solution).

No competent implementor of high safety software will create the software in which critical data is co-located in the manner described. This kind of design would be explicitly illegal and that set of rules would be strictly enforced, usually both by manual independent review of the software and by automated software analysis. Given that observation the likelyhood of an external stimulus causing this kind of issue must be well outside the statistical risk where it is in any way likely, ever, to happen (not that that would stop the protection being used under ALARP, and bearing in mind memory corruption happens for many reasons which are not as 'sci fi' as high energy particle bit flips (you guys - really - back to reality eh ?))

All of the high safety critical software work I have done assumes data corruption (by whatever means) is possible and must be protected against, in all types of memory, within the processor control registers themselves, within off chip peripheral devices, everything. In the type of software my team creates there is no 'human' to stop the system from killing people. Perhaps my expectations of the quality that the aviation industry claims to enforce is very misplaced . . . from where I'm sitting today it's looking fairly shoddy and second rate at best . . .

The FAA should turn Boeings safety and design records over to a genuinely independent review body who are not part of the aviation cabal to see what they think . . . Clearly the FAA are not capable of this kind of work, and clearly Boeing do not do it (well enough) to be allowed to self certify.

When the Chinook FADEC software was handed over for independent analysis the company doing the analysis thought they had been supplied with the wrong software and stopped analysing it, the quality was unacceptable. The same happened to Toyota, and . . . and . . . and . . .

I'd put a shiny tenner on the table betting that this is exactly what would happen in this case, I might even stretch to a crisp twenty, but that will never happen, Money is more important than peoples lives.

Lastly, the means by which complex software fails are often very, very subtle and complex, and with the greatest respect way, way, way beyond anything the masses on here are even vaguely capable of even conceptualising from what I can see.
fergusd is offline  
Old 7th Aug 2019, 01:48
  #1807 (permalink)  
 
Join Date: Feb 2019
Location: shiny side up
Posts: 431
No competent implementor of high safety software will create the software in which critical data is co-located in the manner described. This kind of design would be explicitly illegal and that set of rules would be strictly enforced, usually both by manual independent review of the software and by automated software analysis.
FERGUSD...concur 10000% (did not include your entire post in quote,but yes)

Redundancy is there for a reason...the complex algorithm to combine resources...and determine the correct solution....lemming talk. (statically indeterminate)

Hopefully, that Boeing provided that info in a press release, well, perhaps blame the messenger, BUT if this is really the path...damn.
Smythe is offline  
Old 7th Aug 2019, 13:23
  #1808 (permalink)  
 
Join Date: Apr 2008
Location: Paris
Age: 70
Posts: 272
Originally Posted by fergusd View Post
No competent implementor of high safety software (or hardware) does not use hardware AND software protection against memory corruption (where hardware protection is available - sometimes it is not depending on your hardware limitations), unless the hardware and software on this aircraft are being audited against grandfathered safety standards from the 1960's then the failure you describe must be a failure which would be deemed unacceptable . . .

Bit level corruption in any part of memory would be detected and the corrupt data not acted upon, the action taken when the corruption is detected being defined by the system requirements and the safety rating (largely), e.g. is the system fail safe, fail functional for example. There are many well understood mechanisms which are used to perform this function to varying levels of integrity (because not all safety cases require the most computationally and physically expensive solution).

---snip------
Lastly, the means by which complex software fails are often very, very subtle and complex, and with the greatest respect way, way, way beyond anything the masses on here are even vaguely capable of even conceptualising from what I can see.
70% of the people here seem to be engineers watching in bemusement, at how the FAA pretends to check designs which are pretend-safe, and journalists who have seen it all and expect worse to come, knowing as you say that money is more important than people.

For me, who have been both, the interesting part in this has been realising that the pilots have been conditioned to ignore the faults of their systems, which as you state they mostly don't comprehend intuitively, just as most engineers cannot fly a plane.

The interesting part of AF447 was watching the industry realize that perfectly ordinary first world pilots cannot competently hand-fly a plane, and then as an industry do ... nothing. I expect that after the MCAS fix, the US airframe industry aka. Boeing will similarly revert to business as usual.

Edmund
edmundronald is offline  
Old 7th Aug 2019, 14:46
  #1809 (permalink)  
 
Join Date: Jan 2008
Location: Hanoi
Posts: 39
Originally Posted by edmundronald View Post
For me, who have been both, the interesting part in this has been realising that the pilots have been conditioned to ignore the faults of their systems, which as you state they mostly don't comprehend intuitively, just as most engineers cannot fly a plane.
It is very rare that complex software exhibits faults which are intuitively comprehensible, even if you wrote the software ;-)

fergusd is offline  
Old 7th Aug 2019, 22:33
  #1810 (permalink)  
Thread Starter
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 604
Originally Posted by Fly Aiprt View Post
We understand that the MCAS and associated software are in the process of being fixed, or scrutinized, or...
Has any info leaked as to the status of the other issues, especially the manual trim wheels ?
In a Reuters story from a couple of weeks ago, it was reported that the trim wheels are on the list of things EASA wants resolved before return to service:

As Boeing targets October, FAA official says no timeline for 737 MAX

[. . .]
The European Aviation Safety Agency has handed the FAA and Boeing a list of its own concerns that it wants addressed before the MAX re-enters service, people familiar with the matter said.

It includes the behavior of the autopilot - which EASA believes may take the aircraft too close to a stall before automatically cutting out - as well as the physical force needed by pilots to move a backup wheel that is part of the trim system and extra training to help crew cope with simultaneous alarms.
OldnGrounded is offline  
Old 7th Aug 2019, 22:52
  #1811 (permalink)  
 
Join Date: Mar 2015
Location: antipodies
Posts: 64
Originally Posted by OldnGrounded View Post
In a Reuters story from a couple of weeks ago, it was reported that the trim wheels are on the list of things EASA wants resolved before return to service:
Spurious alarms should be always treated as a serious event that could be catastrophic !
If the manufacturer cannot resolve then the craft should be grounded!
phylosocopter is offline  
Old 8th Aug 2019, 09:05
  #1812 (permalink)  
 
Join Date: Mar 2015
Location: antipodies
Posts: 64
Originally Posted by Maninthebar View Post
I fear that taking this course might result in the grounding of a significant proportion of current models.
yes that would ground a significant proportion and properly so
automatics MUST fail cleanly to a defined and trained for state ! in many cases they don't and aircraft and people are lost because of this.
its just not good enough to dump the mess onto the pilot with incorrect information and alarms active. Now is the time for the regulators to say enough is enough , define a manual reversion state and displays and mandate training for that state.
phylosocopter is offline  
Old 8th Aug 2019, 17:00
  #1813 (permalink)  
 
Join Date: Aug 2019
Location: Rocket City
Posts: 4
Originally Posted by Ian W View Post
This is true, But that doesn't excuse avoiding regression testing. The new use might just have some operational assumptions such as parameters that the designer of the legacy system believed 'would never be exceeded' - and all the people who knew of those parameters and the operational assumptions that drove them are long retired.
But what gets tested in regression testing? Regression testing isn't usually a full formal qualification test, it's a subset of the most important functions. If you get that list wrong, or don't exercise it fully you can miss things.

A full qualification test on one box/software item could take months. That's why they only do regression tests along with testing the new functions.

Say the issue was an assumption that some parameter wouldn't be exceeded. The regression test suite developed isn't going to exceed that either. They are just going to run the same suite as the last time, and the time before that. Only if new functionality is considered important enough will it be added to the regression test. The code could go through a dozen updates without the regression suite being changed.
ST Dog is offline  
Old 8th Aug 2019, 17:55
  #1814 (permalink)  
 
Join Date: Aug 2019
Location: Rocket City
Posts: 4
Originally Posted by HighWind View Post
It seems like FAA/Boeing have delivered evidence to EASA to confirm that the manual trim wheel is usable in ‘certain corners of the envelope’, in situations where the trim forces are too high for the electrical trim.
The question is if Boeing knew that the manual trim forces were too high for an average pilot..
EASA wasn't talking about going ANU when at the AND limit, and vice versa. Electric works for those cases
It's about going AND past the AND limit switch or ANU past the ANU limit switch.
The manual wheel gives access to the range that the thumb switch can't reach.

I've seen nothing to suggest that you can't add AND with the wheel past the limit switch (or further ANU past the upper limit).
ST Dog is offline  
Old 9th Aug 2019, 02:44
  #1815 (permalink)  
 
Join Date: Mar 2019
Location: On the Ground
Posts: 148
Originally Posted by ST Dog View Post

I've seen nothing to suggest that you can't add AND with the wheel past the limit switch (or further ANU past the upper limit).
But why would you want to? You want to get the airplane back IN trim, not further OUT of trim. A functional trim system needs to make it possible for the pilots to get the plane back in trim.
Takwis is online now  
Old 9th Aug 2019, 06:30
  #1816 (permalink)  
 
Join Date: Mar 2015
Location: Washington state
Posts: 210
The MAX grounding is really hitting home around here. I needed to get a speciality marine part and was informed by the manufacturer that they were out of stock so I would normally be SOL for about three months -- but the good news (for us) is that because of the Boeing slowdown the fabricators are looking for work and the marine orders which are usually way back in the queue are getting done -- the upshot is my part will be available next week! So if you are a manufacturer who needs high quality work done in stainless or aluminum, call around in the Seattle area and stock up with good old American machine know-how while you have a chance. Lots of good shops are apparently looking for business and these guys know about quality.
Water pilot is offline  
Old 9th Aug 2019, 07:38
  #1817 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,982
Originally Posted by Takwis View Post
But why would you want to?
You wouldn't.

The poster was simply correcting a misunderstanding about that EASA document (which doesn't specifically mention trim forces at all).
DaveReidUK is offline  
Old 9th Aug 2019, 13:37
  #1818 (permalink)  
 
Join Date: Aug 2017
Location: London
Posts: 86
If you've got friends asking what MCAS is all about, this BBC article is a pretty good explanantion for non-technical people:

What went wrong inside Boeing's cockpit?
https://www.bbc.co.uk/news/resources...deadly_crashes

It's a bit out of date now - doesn't contain all the detailed discussion on software, trim wheels, other problems, that we've had in this thread, but it's a good starting point with pics and animations.
PerPurumTonantes is offline  
Old 9th Aug 2019, 20:43
  #1819 (permalink)  
 
Join Date: Aug 2019
Location: Rocket City
Posts: 4
Originally Posted by Takwis View Post
But why would you want to? You want to get the airplane back IN trim, not further OUT of trim. A functional trim system needs to make it possible for the pilots to get the plane back in trim.
Because the full range, isn't available with electric. To get the rest of the way you use the wheel.
That was the whole point of the EASA note.

IE. full range is +/- 10 but electric only goes +/-8. the limit switches stop electric trim so you can't accidentally get too far with the switch. If you really need the rest of the range the wheel give it to you.
ST Dog is offline  
Old 13th Aug 2019, 18:24
  #1820 (permalink)  
 
Join Date: Mar 2019
Location: Farnborough Hants
Posts: 83
I've just come across an article in the July 2018 edition of the the Professional Body's magazine of my "chosen" profession.
I quote:
" Defence News reported earlier this year (2018) that the US Army had stopped taking deliveries of the AH-64E Apache attach helicopters from Boeing in February. The US Army explained that 'the service is not confident in the durability of what it deems a "critical safety item" - a strap pack nut that holds very large bolts, that subsequently hold the rotor blades on the helicopter'
(snip)
'Clearly these items are safety critical components and for Boeing (the manufacturers) not to have extended its investigation of the testing of other safety critical components, particularly the whole rotor assembly is concerning' "

So is Boeing really placing safety at the top of its agenda on both (or either) military and commercial products?
Paul Lupp 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.