[flagged]
You don't have to like that culture and you also don't have to participate in it. Making a throwaway account to complain about it is not eusocial behaviour, however. If you know something to be wrong with someone else's reasoning, the expected response is to highlight the flaw.
If someone is speculating about how such a problem might be solved while not trying to conceal their lack of direct experience, I'm fine with it, but not everyone is.
If someone is accusing the designers of being idiots, with the fix "obvious" because reasons, well, yeah, that's unhelpful.
As far as we know this is the first accidental dual engine cutoff at low altitude; with just a bit more altitude (not sure of how much exactly) the engine that had restarted and was ramping would have started producing enough thrust to arrest their descent. That makes the margin of "unrecoverable" a lot smaller than you might initially think.
Bottom line is it is worth considering implementing some protection here:
1. It can be done in software without a lot of complexity
2. The transition to "air mode" is relatively reliable.
3. The failure scenario is the system doesn't provide the protection but because the failure we protect against is very rare that is acceptable
4. It typically fails "safe": allowing shutdown without delay and worst case is a delay in shutdown.
5. The fire handle overrides delay; if things are going so wrong the delay matters the engine isn't coming back and pulling the fire handle is likely already part of your checklist.
Obviously before implementing something like this the proper engineering and failure analysis has to be done.
The modal HN reader now is a tech employee or freelancer.
This is not "reasoning from first principles". In fact, I don't think there is any reasoning in the comment.
There is an implication that an obvious solution exists, and then a brief description of said solution.
I am all for speculation and reasoning outside of one's domain, but not low quality commentary like "ugh can't you just do what garmin did".
This is not a throwaway, I'm a lurker, but was compelled to comment. IMHO HN is not the place for "throwaway" ad hominems.
It literally is. Accidental/malicious activation can be catastrophic, therefore it must be guarded against. First principles.
The shutoff timer screen given as an example is a valid way of accomplishing it. Not directly applicable to aircraft, but that's not the point.
> "ugh can't you just do what garmin did"
That's your dishonest interpretation of a post that offers reasonable, relevant suggestions. Don't tell me I need to start quoting that post to prove so. It's right there.
The point of what GI275 does is as a backup instrument you are much more likely to need it when the electrical system fails or is turned off due to fire. Yet if it just remains on until shutdown pilots would frequently forget to turn it off on the ground, resulting in its battery being worn out. Because it is considered critical it delays its own shutdown. Long enough for you to notice in flight but not so long it wears out the battery (which might result in only a few minutes of power in a real emergency).
My entire point was that engine restarts take some time. If both engines eat a blade or catch fire you are screwed anyway so whether or not the fuel cutoff switch does anything at 1500ft is irrelevant. But that is so rare I don't think we have any events on record. So it might be worth inserting a delay - enough to account for standard climb rates to achieve enough altitude to make restart likely or at least possible. The delay would only be for the second engine shutdown and only for time T after going into air mode. And if the system gets it wrong, thinking the other engine is shutdown when it is not pulling the fire handle would override any delay - and pulling the fire handle is part of any engine failure or departed aircraft procedure I know of. In other words you wouldn't even need to change the QRH or emergency checklists in most cases.
I noted that engineering for aviation is complex and everything has failure modes to consider. Privately I went through several iterations of this idea and discarded them for problems with failure modes and complexity. What I proposed is boiled down to the minimal thing that would have saved this flight.
The other thing I'll say is there is a reason the computer will auto-extend some flaps/slats at slow speed even if you put the handle to zero. And there's a reason auto-throttle provides protection. And with the exception of the 737 the computer auto-starts the APU on dual engine failure. And any attempt to deploy thrust reversers in the air is ignored. And stick pushers exist for good reason.
We put in all kinds of measures to override human decisions to prevent mistakes and errors.