Comment by linuxftw | Hacker News Reader

Comment by linuxftw | Hacker News Reader

Do we actually have the raw data from the sensor in the flight recorder, or do we have the flight computer's account of that sensor's data?

> IF AOA > 15 AND AOA < 25 THEN RUNAWAY_TRIM();

And if the AOA is frozen at 16 due to some fault? What is a loss of signal interpreted as? Does it use last-known value? 0? 100?

How often does the AOA get sampled? Is there any attempt to smooth the data? Was the data corrupted (bit errors) during transmission/reception? Perhaps there's a flaw in the hardware (or microcode) protocol implementation of the data bus (or whatever it would be in this case) doesn't disregard packets with parity errors? Or perhaps it only checks for 1 bit of parity and it needs to check for 3? Or perhaps it's sending int64 and the flight computer is expecting int32.

It's all so simple to make completely uneducated guesses.

When Boeing made such obvious mistakes such as "don't re-command full-nose down after reset" that should have been caught be any competent user acceptance / QA testing, I have to call the entire engineering effort into question. I cannot assume they did even 1 thing correct in this system, and it really needs to have an independent review of the entire system hardware and software implementation.

You seem to be arguing multiple sides here.

Philip Greenspun's speculation is a plausible concern, that is all it needs to be a valuable point, that type of data limit handling ought to be considered as the system is looked at. I read his post that he was talking a specific simple example, all the other types of things you mention could also be looked at. How the AoA sensors failed, any potential issues with signal handling, and especially what happened with the Lion Air AoA sensor repaired in Florida need to be investigated, that sensor repair sure seems to be. (BTW data handling in aviation is pretty interesting,

Greenspun is a fairly unique combination of EE/CS/past MIT lecturer/geek and experienced pilot, including holding an ATP certificate and flying for regional airlines.

The system as implemented could not have a "re-command full-nose down after reset". To start with there is not really a "reset" for MCAS. The pilot's only way to fully disabling MCAS continuing to do bad things is via STAB TRIM cutout switches. The STAB TRIM cutout switches are required to handle lots of other problems. e.g. runaway full nose down trim. The stabilizer trim system itself is a dumb as a rock, and has no idea where the trim should be set to if the power is restored to it. I suspect the only likely sensible behavior of the trim system itself is that it makes no automatic change. If MCAS is driving the trim wrong and if it was possible to remove the MCAS input to the trim system then the pilot should be able to reset the trim they want (with then hopefully functioning electric trim switches), or allow the autopilot to do it (outside of MCAS the A/P is the other automatic system that manages the stabilizer trim). The problem is that was not anywhere in Boeing's plans here, there was no way to separate MCAS going nuts and commanding extreme trim changes, from the actual stabilizer trim system.

However I do agree with your sentiment about (all the other) bad mistakes. In my view when a seemingly largely self-regulated group goes off and designs something with so many glaring issues (single AoA sensor source, lack of documentation and training, not even having a standard AoA disagree alert, etc.) and other possible issues (rationale of extension of MCAS trim authority, trim wheel forces needed to crank mechanical trim at stabilizer trim limits, Boeing slowness in responding to issues etc.) then everything needs to be looked at. My hope is there are very thorough investigations, of the actual systems, of all the proposed remedies (which separately, I am not convinced are enough), of Boeing, and of the failure of FAA oversight here. And I hope that is done as fast as possible, and as slow as really needed.

From the article:

> all of the problems could potentially have been avoided by changing [code-snippet]

IMO, this implies the problem was a simple, single software problem. Firstly, that's in inaccurate assumption. Secondly, even if that assumption wasn't implied, one can't just say 'ooh, modify this if statement' with any authority because one does't know what the underlying algorithm looks like in the first place.

> The system as implemented could not have a "re-command full-nose down after reset".

For brevity, my comment lacked certain detail. The MCAS system was reset after pilots used the trim switches on the column. However, the MCAS did not account for this, and it's overall authority was allowed to point the plane full nose-down. See [1].

> In my view when a seemingly largely self-regulated group goes off and designs something with so many glaring issues

This is the point I'm mostly trying to make. When I read a column or comment that says "Oh, it was just the sensors" or "Oh, it was just the simple software problem," that's really helping Boeing's narrative. It's not just a simple mistake, it's a total failure of Boeing and regulators and cannot be understated.

1: https://www.seattletimes.com/business/boeing-aerospace/faile...

> not even having a standard AoA disagree alert

Sorry to nitpick on one thing here; but I don't know that having an AoA disagree alert would be that useful. There was already an airspeed disagree alert, and AoA disagree strongly implies airspeed disagree, because AoA is involved in the airspeed calculation. Furthermore, knowing an AoA sensor is broken wouldn't be super useful without a workable procedure to do something about it; in the Ethiopia crash, the procedure followed was insufficient to regain control.

AoA disagree does not imply airspeed disagree. Indicated airspeed is purely a pitot and static pressure driven measurement. AoA is there largely as part of the anti-stall warning system, e.g. driving the stick shaker/pusher. An important point of having AoA sensors is to provide a stall warning systems that is independent of IAS, you don't want these systems crossed with each other.

B737 airspeed disagree I believe just requires 5 knots disagreement for more than 5 seconds between left/right IAS. No AoA involved.

There may be some confusion happening due to the events in the Lion Air B737 Max. The maintenance crew tried to address what they believed were ADIRU/ADR issues in previous flights... including as a possible source of erratic airspeed indications and airspeed disagree warnings. So there are some discussions of airspeed disagree in relation to that aircraft. There may be a lot going on there we don't know about yet, with say faulty ADIRU/ADR causing multiple problems. The ADIRU has inputs from the AoA vane but does not use that in calculating airspeed, it is using that to drive stick shakers/pushers and optional display AoA, and unfortunately in these cases to also drive MCAS.

Having a AoA disagree indication (and/or full AoA display option) might have allowed more prompt diagnosis of problems, but only if pilots were aware of and trained on MCAS. And even then, yes it's a minor point. I was not intending to claim that itself is a deep solution here, just not having a disagree warning as standard was a bad decision. The entire system, and overall approach taken by Boeing seems tragically deeply flawed.

I think the Ethiopian preliminary report says they were in IAS disagree for the whole flight too. I don't know what caused the IAS disagree. It played a role in the crash, since its checklist disallowed lowering flaps (which would have disabled MCAS) or throttling back (which would have avoided surpassing Vmo, which likely made manual retrim impossible).

Ah now my addled brain finally wakes up, well maybe. What may be happening here is the ADIRU is doing AoA based static port compensation. It will normally be a small correction, and I was trying to keep that out of the discussion because I thought there there have been reports of erratic airspeed in previous Lion Air flights and that was not jiving with small changes of airspeed I was expecting (and now I'm going to reread the Lion Air preliminary report to check what was reported). But to start with you only need 5 knots to trip the IAS disagree, so sure I'll expect it could trigger that (and also possibly an altitude disagree). But potentially more intersting is what does that usually small static compensation change do when the ADIRU thinks the AoA is really out of whack, does it keep applying the "correction" or does it ignore it? So that question circles back to be similar to what Greenspun is asking in the original article.

Reply on news.ycombinator.com