PPRuNe Forums - View Single Post - Insufficient information?
View Single Post
Old 6th May 2022, 23:20
  #5 (permalink)  
MechEngr
 
Join Date: Oct 2019
Location: USA
Posts: 866
Received 215 Likes on 119 Posts
Training avoidance was not the fundamental cause and neither was the lack of documentation. The first plane to encounter the problem landed safely after a 90 minute flight and they had neither special training nor any documentation regarding MCAS.

Since this particular failure mode was not identified as one that a typical pilot could not handle and had the same symptoms as any other electrical failure that would drive the trim system, no different training was identified. Apparently the simulators of the NG did not include the ability to falsify the AoA sensor data, so how could that training have been done?

The main problem seems to be the entire lack of ever having a trim-runaway on the NG - so no examples of crews being unable to handle it and no impetus to emphasize how it might manifest. As a result neither the design review process understood it to be a deadly threat and neither did those responsible for training. Maybe there was a case of runaway? If so, I have never seen it discussed in any of the thousands of replies or the accident reports or the Congressional report. To which I say - it was still identified as a potential problem without a defeatable cause as evidenced by the NG and the MAX having trim motor cutout switches.

It seems like more systems level information should be available, but all of MCAS was exposed 4 months before the second crash.

This is a big general problem with sophisticated automation - that the operator might have to not only know what the system is doing externally (as in the engine RPM) but also what the automation is doing and why it is doing it and what limits there are on the automation ability to cope with variances in the reported sensor values from the actual values, and then what the automation will do if an unobservable sensor provides information that is: accurate; might be a bit in error; might be largely in error; or might no longer function.

In most automation the first and last case are handled well; the second case falls under the first case with users remarking that the result isn't as good as expected, and the third case is what gets people killed. Deviations in either a few sensors or, because of damage, potentially a group of sensors, rapidly generates millions to trillions of possible outcomes.

MCAS is a stand-out. Many planes have had automation problems that lead to deadly crashes, but usually they weren't back-to-back from different initiators. In MCAS one was the miscalibrated AoA sensor on one plane and the suspected collision removal of the sensor vane on the other. In most automation failures the response has been to improve training and, when there is a software change, the operators are lucky and the software gets there before the next event.

MCAS wasn't to reduce cost. It was a small patch to a small trim problem just like STS is. It was based on STS, but because it had to operate under manual control to tweak the response to manual control it could not be shut off by manual control as STS can be. Sure, they could have designed an entire new plane for the hindsight cost, but then a person could buy a new car because the fuel tank is empty. In addition, a new plane would require all new training for all the pilots in the airlines buying 737s, which is exactly what the airlines did not want. If there is a blame for penny pinching - the airlines are it - but they also had not seen this problem so it wasn't identified as a requirement there either.

I've seen no indication that anyone had plans to change the simulators to falsify the AoA sensor output to produce the MCAS related crash sequences - without that no one could train for it. I expect they could simulate a trim runaway, but if no one ever heard of one or experienced one on a 737 why would that be emphasized?

I expect the same goes for the throttle response - if it has never caused a problem why tell pilots about it when more pressing issues might be dealt with in that amount of time or in generating pages for the manual? I do recall that, following the obliteration of an engine in midair that ruined a jet and killed a passenger, pilots were cautioned against conducting experiments. It also solved a mystery about a similar development failure on a test stand that the engine maker had tried but had been unable to diagnose or reproduce. See National Airlines, Inc., Flight 27, N60NA.

As an engineer, I have thanks for anyone looking at how the system is supposed to work. I could not always imagine all the potential interactions and found such questions to either be gratifying (I had accounted for it) or helpful (I had a new case to avoid.)
MechEngr is offline