"Boeing said that selecting full reverse too quickly upon landing before the aircraft has fully transitioned to ground mode could cause the system to activate."
That sounds like apple's "you are holding it wrong" when "antenagate" happened. Not something I want to hear from an aircraft company where people's lives depend on it working.
Reading between the lines, and having read other comments here, I can interpret Boeing’s remark as “if the pilots or the on-board software try to reverse engines when it still is really, really dangerous, the Thrust Control Malfunction Accommodation system (TCMA) will try to make matters less bad, in some cases by shutting down the engines instead”.
They may have to fine-tune that system, but from a safety perspective, this event had a good ending, and making its decision system more complex also carries risks, so, maybe, nothing has to change.
I'm having a hard time thinking up an alternative choice of words that is similarly clear and concise.
I also think that the phrase "too X" is polysemous. Depending on how it's used, it may imply a notion of blame. But it can also just be a way of describing an incompatibility. "This clearance is too low for that truck" and "This truck is too tall for that clearance" are entirely equivalent statements, IMO. Neither implies that the truck or the bridge is wrong, just that the driver would be wrong to try and drive under it.
Even further out there, when describing a timing-based bug that isn't known to be 100% deterministic as, "If X is happens too quickly after Y, Z might happen" seems to me like it's just a much more straightforward way of saying, "If X happens within some unspecified interval after Y, then Z might happen." Nine syllables shorter, same meaning.
There's a further implication that an instruction, but not a failsafe, exists to prevent the given condition. E.g. "do not reverse thrust until ground mode has fully activated." but no check to actually prevent the crew from doing so.
I'm not a lawyer; couldn't tell you where the fault would split in that case, but if my hunch about the lack of a failsafe for a given instruction is correct... it's still a surprise to me. I'd expect existing avionics production procedures to catch this sort of thing.
>> I'd expect existing avionics production procedures to catch this sort of thing.
The older I get, the more I believe your expectation is wrong. Lessons learned are rarely transferred to new people who were not present when the lesson was initially learned.
I've even worked at companies that try to compile a database of "lessons learned", but they never instruct anyone to read through the whole thing. Even if they did, when confronted with a large amount of material how much of it actually sticks?
The we move on to more procedural methods like fault-tree analysis, FMEA, etc... That's great and can help a lot, but it's still a GIGO process and new people need to learn how to do it well. There are always new people learning new things.
In software, we usually encode lessons learned as tests and static analysis. There is a reasonable level of success on that.
Aviation usually encode them on checklists. They have a much higher degree of success (probably because of culture, not medium), but failures happen some times too.
Aircraft are very different from cell phones. There are a number of things you can do as a pilot that will cause them to crash or stall especially if something unusual like a sensor or engine failure occurs. Pilots spend a lot of time in simulators practicing how to fly the plane in a variety of such situations as well as under normal operating conditions.
Or as my neighbor says: "I've dealt with hundreds of engine fires!" (He flies A320s.)
That sounds like apple's "you are holding it wrong" when "antenagate" happened. Not something I want to hear from an aircraft company where people's lives depend on it working.