PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 3rd Aug 2019, 08:37
  #1719 (permalink)  
GordonR_Cape
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Notanatp
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.

As for the rest of the reporting, I cannot find it now but I've read one account of the test that said all three test pilots recovered the airplane if it was assumed they recognized the problem within 3 seconds (the time to respond to an autopilot runaway pitch trim). The FAA wasn't satisfied with that so it ran additional tests were it allowed the failure to go longer before being recognized, and one of the three pilots either couldn't recover or didn't recovery fast enough. My understanding is that it was on the basis of this addition test where it was assumed that only an exceptional pilot would have recovered, therefore, the catastrophic classification. Has anyone else seen this account, and if it is correct, then doesn't it sound like this is rigged against Boeing?
The Seattle Times article explains the story quite well, although we may never have all of the details. The link may be paywalled, though most of the content was posted previously (Edit: by Zeffy on 1 Aug) on this thread: https://www.seattletimes.com/busines...ight-controls/

The starting point for the retrospective FAA analysis is not what could go wrong, but rather that we already know something did go terribly wrong, so zoom on in each of the possible failure modes that could lead to this specific condition. Once we start from that perspective, no error in the FCC is ever acceptable, no matter how improbable. Fixing software does not add weight to an aircraft, and does not impact on the fuel efficiency, unlike hardware where there are permissible tradeoffs. AFAIK if there is a known catastrophic software fault, it must be eliminated.

IMO your estimates of bit-flipping probability are backwards. Since we are a-priori interested only in these 5 bits, the size of RAM is irrelevant. For this evaluation, the probability of each bit being flipped is the only important parameter. These may or may not be independent, and this scenario is still extremely unlikely, but not to the extent that you calculate.

AFAIK the 3 second and 1 second limits are not assumptions, but mandated by FAA regulations. Allowing the runaway to continue for more than 3 seconds seems an entirely rational test, knowing what we do about the recent crashes, and the difficulty of detecting runaway trim.

IMO this does not sound rigged at all, merely being tested properly, the way it should have been done. Boeing have not resisted, but seem to accept that this is the right way to fix the problem.
GordonR_Cape is offline