[scarier]

Heh, I think I did a poor job of expressing myself. You're absolutely right that an intermittent/erratic trim operation is a failure, and potentially a serious one. I'm thankful that you, as a flight control engineer, are as concerned about it as you are (for hopefully obvious reasons). Out of curiosity, how probabilistic is your failure mode analysis? I'm wondering what the relative likelihood of an intermittent uncommanded actuation compared to the neutral-to-extreme runaway failure that most pilots expect. I've never been in a sim where the operator console had trim failure options other than "stuck at current position" or "runaway to extreme limits," but I wouldn't be surprised if they should've included other failure modes.

Yeah, that seems like an eminently reasonable way to design a trim system. I don't think the MCAS concept is fundamentally unsound, but it blows my mind that they didn't design it with that kind of mindset.

Oh man, I wish more software was built to the standards of aerospace control system best practices...

[WalterBright]

> probabilistic

I don't remember the numbers, but one had to show that the likelihood of failure was less than 1 flight in XXXX where XXXX was a very large number.

> I wish more software was built to the standards of aerospace control system best practices...

I am much more ambitious. The Deepwater Horizon disaster, the Fukushima nuke plant failure, the Toyota acceleration failure, etc., are all designed with an utter disregard for lessons that aviation learned long ago. To wit:

1. a failure of one subsystem shall not propagate to another (zipper effect)

2. a failure of one subsystem shall not compromise the whole

3. once any such failure is detected, that subsystem shall be assumed to be compromised by demons, and must not be allowed to continue

4. you cannot educate people into not making mistakes

5. if you punish people who make mistakes, they will conceal mistakes instead of being forthcoming about fixing them

Those principles have strongly influenced all my engineering work since, and I've tried to propagate them among my colleagues (with mixed results).

[WalterBright]

For example, the good old `assert` in software. Asserts are to detect impossible states, and hence if an assert trips, the software is in an unknown state, and what it will do next is unpredictable. Therefore, an assert must go directly to jail, not pass Go, and not collect $200.

I get pushback all the time on this,

1. people use assert()'s to validate input

2. people insist that their program can continue operating after an assert trips

3. people insist that their program cannot be allowed to fail, and that they are capable of predicting what their program will do next