PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 3rd Nov 2019, 15:13
  #3712 (permalink)  
infrequentflyer789
 
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Notanatp
The Aviation Week article doesn't provide a copy of the 2015 e-mail. Natalie Kitroeff posted the Fazio's' PPT slide onTwitter but it is heavily redacted, partially obscured by a big blue circle with a quote pull-out, and generally difficult to read.

1) Has anyone seen a cleaner copy of this e-mail and if so, would you please post it?

2) Any idea why so much stuff was redacted? It doesn't look like they were redacting names, phone numbers and e-mail addresses. Rather, it looks like they redacted substantive comments.

3) I haven't seen any substantive reporting about this e-mail. It is mentioned in NYT, Seattle Times and Aviation Week articles, but just to mention that Muilenburg got hit with it at the House hearing. Has anyone seen any more in-depth reporting on this e-mail? E.g., when did Boeing become aware of the e-mail, who sent and received it, and are they still employed at Boeing, what was the context of the thread?

4) Why has the reaction to this been so much more subdued than the reaction to the Forkner e-mail about the simulator running rampant? There hasn't even been much discussion here. I know there are the optics attached to Forkner's language, but the AoA Disagree issue cuts to the heart of some of the engineering errors.

5) At the time of the e-mail, Boeing believed that it had AoA Disagree functionality built in, as it was in the NG (they didn't discover the bug making it dependent on the optional AoA Indicator until much later). Assuming the FCC processors detect the disagree condition, or that it is input to the FCC, the response to this e-mail couldn't have been "it's too hard for MCAS software to detect AoA disagree." Was the problem that the disagree state was not readily available to the FCC in MCAS 1.0? What other possible reason could there have been not to detect this condition in the MCAS software?

6) Also, focus on vulnerability to a single AoA failure should have provoked some kind of more general discussion of the ability to detect invalid inputs and limits on outputs, which was never added. I continue to be mystified by the failure to do even the most coarse filtering, and this e-mail makes it even worse.
1,2) Redactions are either those done by Boeing legal team as part of discovery, in which case they'll have the clean copy, and solid legal reasons for the redaction (most likely trade secrets, personal info, irrelevance), or they were done by the House Committee before the hearing possibly to remove swear words or personal info. My bet is on the former, but either way what's behind the black isn't public, anyone who has it won't be posting it.

3,4) The email (or rather the slide of it) is reported other places including Forbes & Daily Mail - various hits on google, but it isn't as sensational or even as damaging as Forkner really, and it is not as relevant, see below. If anything it helps Boeing - "see, our engineers can speak up freely".

5,6) It is critically important, I think, that at the time of the email MCAS was still in original form not the production psycho-dive form. This may also explain the more muted media interest - Forkner was discussing the (lethal) change to MCAS, this email wasn't. In terms of your point 6, this email is evidence of input validation process being carried out, in some depth. In the context of original g-dependent MCAS I doubt the "vulnerable" comment refers to a dive (spiral, maybe?), and may refer to MCAS failing to activate when it should, rather than erroneous activation.

From the fragments we have, my take on the email (quotes in italics) is as follows:

"Stab rapid reversal on PSIM model" (subject line), "stab motor deceleration characteristics" - we are considering effect of rapid MCAS activate/deactivate, on the whole electric system including actuator, my guess is "PSIM" refers to the commonly used circuit simulation software
"notes from a blade out evaluation", "first order lag filter to AOA would reduce the amplitude of the oscillation" - source considered is AOA vane oscillation / flutter, possibly due to vibration after blade-off
"Pilot modes are typically..." - and we are considering possibility of PIO as well
"Are we vulnerable to single AOA..." - in context, can this possible problem be triggered by one AOA vane fluttering, or are there checks on that

I think some of the other slides are more interesting, particularly the original plans for an MCAS (unavailable?) alert, and the MCAS "coordination sheet" with "MCAS shall not interfere with dive recovery" as a requirement (notably, from 2018, after the change). That requirement clearly wasn't met.

In the end, the biggest significance of this email may be that it dates to before MCAS was changed. Surely if there were similar engineering discussions from after the change, they'd have put those up instead. If we therefore conclude that there were no such discussions, then that in itself speaks volumes about the process around the change in MCAS (not the process around the original design). We already know from JATR report that safety assessments and certification documents were not updated to reflect the change to MCAS, it is quite possible there was limited knowledge or discussion of it even within Boeing.
infrequentflyer789 is offline