[_Codemonkeyism]

Key take away

"There is absolutely no reason to require your pilots to require a MAX simulator to begin flying the MAX,” the Boeing employee replied. "Once the engines are started, there is only one difference between NG and MAX procedurally, and that is that there is no OFF position of the gear handle. Boeing does not understand what is to be gained by a three-hour simulator session, when the procedures are essentially the same.”

[Athas]

I still think it's interesting to reflect on the mindset that leads to this conclusion. As far as I have been able to determine (although I'm not in the aerospace field), the 737 MAX is procedurally identical to the NG, except when something breaks. The failure modes are slightly different, with potentially lethal results. As a computer scientist, I'm not accustomed to thinking about functional equivalence in the presence of hardware failure, and maybe this Boeing employee was not sufficiently drilled on the need to consider such aspects for aeroplanes. It is of course the fault of Boeing corporate culture and internal procedures that this can be overlooked.

[salawat]

>As a computer scientist, I'm not accustomed to thinking about functional equivalence in the presence of hardware failure...

How are you not?

I mean, I get it 90% of the time we screw up the programming somehow, but as a computer scientist, I never ignore the possibility of hardware failure. Memory goes bad. Devices fail. Networks die. Semiconductors transiently in strange ways if you don't take the right precautions...

It's the entire impetus behind GIGO. If you shove garbage into a perfectly working software system; (corrupt data from a malfunctioning input source), you still get out garbage.

It's why life and safety critical automation is so fundamentally different from lower stakes programming tasks where "reboot the damn thing" is a viable option.

If your sensor goes bad, and you're in the air, you can't do squat to fix it. You have to detect the error, and fail the system gracefully by taking it out of the loop, informing the operator of the system failure, and most importantly, never allow that system to do anything that could jeopardize the ability of the operator to continue operating.

This is or at least I thought it was basic Control Systems 101...

[Athas]

> How are you not?

I research compilers and type systems. If the RAM dies while the compiler is running, you rerun the compiler on a new machine. A lot of computer science abstracts away the notion of hardware failure, because otherwise it becomes enormously cumbersome to talk about anything. This is fine as long as you don't actually build real high-reliability systems with the same approach.

[acqq]

>> How are you not?

> I research compilers and type systems.

I hope it's obvious that the software you work on is not supposed to be run during the flight.

The critical software is supposed to do as little as possible, and everything is expected to be in already compiled (and thoroughly verified) state.

And even for the product of yours, as soon as it is not used only for the research but as a production compiler which produces a firmware for the plane, it would have to be proven much more than what is expected from it while it is just an artifact of a research.

In short, even if you are lucky to just do the research, you should be aware (and thankful) that the critical software has other expectations. Including how it responds to failed sensors: different response to the external inputs is a fundamentally different software, even if you never thought about it before.

[gknoy]

I think his main point was that for most of us, hardware failure is considered an adequate excuse for why something works -- most of us are not expected to have software that _continues working_ when things break.

[acqq]

The "failures" of the sensors are simply the "less common" inputs. The proper control software should simply be written for all possible inputs, which include inputs from faulty sensors, and the result of the processing should not have some catastrophic consequences.

Compare to the web app that awaits the username, but when the username is not the "most common" (e.g. contains some new unicode symbols, or is of zero lengh) it allows catastrophic security failure and intrusion.

[chopin]

A great deal of procedures focus on failure scenarios. If these are different, then the MAX is procedurally different from the NG.

[tragomaskhalos]

Yes - this seems to me to be the same erroneous thinking that lead to the Ariane 5 maiden flight loss, caused by an integer overflow. There again the thinking was "this is effectively the same vehicle as its predecessor, therefore we do not need to test it thoroughly".

[skissane]

Similar thinking contributed to Therac-25 as well - the software worked safely on the old hardware, of course it will be safe on the updated hardware.

[bumby]

I suppose it depends on the field in which you work, but many safety-critical fields have an expectation that hardware failures are captured and mitigated and there are various tools to capture these design decisions and ensure they are tested. One example tool in this case would be a software fault analysis (FTA) or failure-mode-effects analysis (FMEA) that looks at a broken sensor input value as a failure mode.[1]

It's been my experience, however, that these sorts of design tools are more unfamiliar to software groups than hardware bubbas. It's not uncommon to simply see "software fails" as a failure mode which isn't very helpful. I'd be curious what the HN community's experience is with software as it relates to design tools like FTAs, FMEAs, hazard analyses, etc.

[1] https://standards.nasa.gov/standard/nasa/nasa-gb-871913

[Angostura]

The other key take away I had was:

> "Boeing knew the approach might be questioned [Calling MCAS a simple addition to Speed Trim], so it sought input from its FAA-designated authorized representative (AR) "to ensure this strategy is acceptable” for certification.

> "After speaking with the [AR], concurrence was provided that we can continue to use the MCAS nomenclature internally...while still considering MCAS to be an addition to the Speed Trim function,” the memo said. "This will allow us to maintain the MCAS nomenclature while not driving additional work due to training impacts and maintenance manual expansions

I can imagine some Boeing employees being uncomfortable, but having it run past the FAA would have relieved that. Pretty shocking regulatory lapse. I know nothing about the AR system - is this a Boeing employee, or someone who works full-time for the FAA?

[salawat]

The FAA basically picks a Boeing employee and says "you represent and answer to us now."

The employee however, is still managed, and reports first to Boeing management. They're a glorified liaison/paperwork interface. This was different than before as I understand it, because the FAA used to become the direct report for their Designated Engineering Representatives under the old system. This meant there was no management layer running interference between the rep and the regulator.

I might be misremembering that though.

[sseth]

I believe with AR even the picking is done by Boeing. unlike DER. One huge downside of this is that the informal interactions between FAA and Boeing engineers are almost non-existent, leading to even greater lack of technical knowledge on the FAA side.

[simion314]

>I can imagine some Boeing employees being uncomfortable, but having it run past the FAA would have relieved that.

There were some emails released where a Boeing employee boosted about he used "jedi mind tricks" on the FAA people.

[makomk]

It's not that shocking except in hindsight. The speed trim system is, from what I can tell, incredibly similar to MCAS at least on paper. They both adjust the stabilizer trim in order to ensure the legally-required amount of force is needed to move the stick in certain scenarios, both activate 5 seconds after the last manual trim input when flaps are up and autopilot is off, and both rely on non-redundant sensors. The only difference is the exact combination of sensors used and the exact obscure scenario they're designed to protect against.

[pbhjpbhj]

I read here previously, I think it was here, that the primary difference was that after repeated counteraction by the crew the speed-trim system would give up, whereas MCAS doubles down and reduces the time between its attempts to force trim "correction", literally wearing pilots down physically until the system wins and the plane crashes.

Another post showed how AoA sensors (IIRC) has systematic errors causing MCAS to operate when corrections weren't required. As you say, lack of redundant sensors.

[Angostura]

Thank you for that explanation

[passer_byer]

The term for this is regulatory capture. That is why staff at the FAA share in the culpability of these tragic events.