Hacker News Reader

Comment by wycy | Hacker News Reader

I still don't think I'd trust it.

While it's probably true that they fixed the software to never again produce this kind of error, I don't like the idea of software being used to correct the fundamental physics that the airframe is dynamically unstable. While the software probably does a good job of correcting it under a wide range of normal operating conditions, can it deal with evolving or abnormal operating conditions? Will the software still be able to compensate if the pitch-up moment is artificially increased by, e.g. the roof turning into a scoop, or flaps jamming, or a small piece of wing trim breaking? Would Aloha Airlines Flight 243 still have landed safely after the roof came off, becoming a scoop, if it were instead a 737Max?

View on HN

737MAX is not nor never has been dynamically/aerodynamically unstable. Full stop. No airliner is permitted to be unstable by FAA regulations. At no point in the flight envelope will the aircraft pitch up into a stall without pitch-up inputs, thus it is not unstable.

MCAS was used to augment flight stick characteristics, namely to simulate a linear relationship between flight-stick input force and pitch-up/AoA. This was, and always has been, about single-certification and pilot UX, not anything about the stability of the airplane. Having stick forces be somewhat lower than expected at high AoA does not make the plane unstable. The linear relationship is considered ideal, but many planes such as the 757 have a similar non-linear relationship. MCAS is not anti-stall.

Granted, this has widely been mis-reported. The real issue is that the MCAS system was made dramatically more powerful, and thus dangerous, over the course of development. Without a concomitant change to the reliability of MCAS inputs (namely the AoA sensors), this resulted in disaster.

https://www.seattletimes.com/business/boeing-aerospace/as-th...

Wait, wasn't MCAS used to fix two completely different flying issues, and weren't the changes introduced in the MCAS software twice, for two different points in the flight? Wasn't at least one crash caused by MCAS activation in the phase of the flight that was not even described in most of MCAS explanations initially (which reflected the decision behind the initial introduction of MCAS, not the later modifications)?

Therefore I believe the interpretation that MCAS "just augments" is too simplified from what it really was supposed to do. And the current "fixes" as they are implemented (still as to keep the "water not wet" there) could still leave plane as not behaving as it should, neither with MCAS active, nor when it is not active when it was supposed to be.

MCAS was introduced to handle slackening Control surface response force at high AoA in high speed high AoA situations (Wind-up turns) and low speed high AoA situations (generally landing). That type of slackening would normally disqualify an airframe from use as a Civil Transport aircraft according to the FAA final report on the matter.

>737MAX is not nor never has been dynamically/aerodynamically unstable. Full stop.

Correct in the jargonic sense. Incorrect in the colloquial. MCAS was necessary because the MAX was not compliant with Stick force response curves in high AoA flight regimes, and would experience a reversal in the pressures required to bring the plane up to a stall.

So yes, it was not aerodynamically unstable, but in the layman sense there is an instability or undesired quirk being compensated for.

I know we're all pedants here, but lets be productively pedantic.

I've said this elsewhere in the thread, but stabilizing a dynamically unstable system is half of the reason why control theory remains an active research area instead of a mathematical backwater; this kind of set up is extremely common for aerospace systems. Software is hard to get right - which is why aerospace software has traditionally faced much higher bars for verification than 'traditional' software (and is much more expensive as a result!) The same is true of hardware, which I think many HN commentators forget; the cost of a bolt or connector that is aerospace-grade is typically many times that of a conventional or automotive-grade part, due mostly to extensive testing+verification required for safety.

Most of the scenarios you're describing are dealt with in a few ways:

1. Building systems with sufficient margin to account for this kind of uncertainty; even with passively stable aircraft, these margins exist. Feedback control typically increases these margins.

2. Extensive verification under a wide range of input conditions; this is more challenging (how can you enumerate every possible failure condition?), but usually boils down to some kind of Monte-Carlo sampling or worst-case analysis when those cases can be identified. Here's [0] a neat paper that does this in a more sample-efficient way.

[0] https://arxiv.org/abs/1709.06645

I was under the impression that this was never a software problem, just that they are attempting to fix the problem with software.

If you get a faulty AoA sensor, or maintenance installs it poorly, there is nothing the software can do to fix that.

The problem was dual AoA sensors were sold as an additional feature instead of a base requirement.

Since the problem was not caused by software, the best you can do with software is to try and build some workarounds.

I think the only way to fix this with software would be to use the other AoA sensor from the secondary MCAS, making the backup system no longer fully redundant, but that's just a guess.

Would be interested in feedback if this is accurate.

At any rate, the software will never be 100%. The biggest change in regards to safety is that pilots are now aware they can turn the MCAS off. Which is the necessary knowledge that would have prevented both crashes.

Reply on news.ycombinator.com