You have to pull the switches out (against a spring) to be able to move them over a notch and flip them. Not really something you can just mistake for another switch or bump into by accident.
I'd liken it to turning off the ignition by turning the key while driving your car. Possibly something that could happen if you're really fatigued, but requires quite a mental lapse.
Is it possible to rest the switch on the notch? Does the switch make contact if the switch is in the RUN position but the switch is not completely down?
That is, is it possible they flipped the switches over to RUN but did not seat the switches properly, and instead leaving them on top of the notch, with later vibration causing the switches to disengage?
Just trying to think of some semi-plausible non-active causes.
?? One pilot to other: why cut-off. Other: Did not do it
08:08:52 Engine 1 run
08:08:52 Engine 2 run
1 second to switch them both off and then 4 seconds to switch them both on. No one admitted to switch them off. They are probably going with fine comb over the audio and also the remains of the chared switches.
Looks like the engines react very quickly to cut-off so it is not clear whether the question about the cut-off is prompted by a glance to the switches or the feel of the airplane.
The big question is whether the switches were moved or something made it seem as if the switches were moved.
Well in the murder-suicide scenario it makes sense for the culprit to turn them off as quickly as possible. The longer time to turn them on could plausibly be a struggle or simply needing to fly the plane while reaching for each switch individually.
> Looks like the engines react very quickly to cut-off so it is not clear whether the question about the cut-off is prompted by a glance to the switches or the feel of the airplane.
The workload is pretty high during the takeoff phase. The engines react right away when fuel flow is stopped. The engine displays can have some lag before data is updated.
Relighting an engine at low speed is not feasible - most need 230-250kts IAS before attempting the operation.
Maybe you could do it if the APU was still running and could provide compressed air, but it takes about 20-30 seconds to start up amd then probably 5-10 more to spool up to full thrust. I am speculating here a bit, but the pilot did not have enough time to save the plane even if he did everyting right and as fast as humanly possible.
All this aside is overshadowed by the limited amount of time the pilot flying (I would assume the captain in this case since there was only one ATPL pilot in the cockpit) had to troubleshoot the issue of a dual engine failure - as this is what would have felt to him - during takeoff.
My bad. I assumed it was the captain since the report says the FO only has a CPL license. And I was a bit surprised he could fly on a comercial airplane with only that kind of license and not an ATPL one.
Did you mean to say you can activate the switches with one hand simultaneously? That is probably what the above commenter assumed you meant. Since lifting and twisting two switches simultaneously with one hand seems challenging.
snypher: You can do them with one hand. [Ed. This is ambiguous and could be read as "one hand, simultaneously". In fact, doing it with one hand non-simultaneously would be a weird claim to make of a simple knob. See also ajb's comment below.]
zihotki: Really? They are not close together and have a spring mechanism. [Ed. Seems to believe snypher is claiming simultaneous operation.]
Context is both these switches being turned off with a 1 second gap. Doing it with one hand simultaneously would possibly explain it, otherwise it doesn’t seem relevant.
What I gathered from comments here is it's not a simple flick of the switch and it actually takes some effort to turn them off. Can you really do it twice within the span of 1 second?
You pull it out and flip it. It’s not easy to do inadvertently. But it’s also not convoluted—you want to be able to quickly cutoff if there is an engine fire.
I wonder if they could theoretically rest on top of the notch, not fully locked into either position and flip accidentally. No idea how the switches behave when not all the way up or down, but the notch looks pretty long and flat so it could be possible.
It could be defective switch springs, fatigue-induced muscle memory error, or something else. The pilot who did it saying he did not may not have realized what he did. It's pretty common under high workload when you flip the wrong switch or move a control the wrong way to think that you did what you intended to do, not what you actually did.
That said Boeing could take a page out of the Garmin GI275. When power is removed it pops up a "60s to shutdown dialog" that you can cancel. Even if you accidentally press SHUTDOWN it only switches to a 10s countdown with a "CANCEL" button.
They could insert a delay if weight on wheels is off. First engine can shutdown when commanded but second engine goes on 60s delay with EICAS warning countdown. Or just always insert a delay unless the fire handle is pulled.
Still... that has its own set of risks and failure modes to consider.
If its both engines you're fucked anyway if its shortly after takeoff.
But I'm an advocate of KISS. At a certain point you have to trust the pilot is not going to something extremely stupid/suicidal. Making overly complex systems to try to protect pilots from themselves leads to even worse issues, such as the faulty software in the Boeing 737-MAX.
Was thinking this same thing. A minute feels like a long time to us (using a Garmin as the example said) but a decent number of airplane accidents only take a couple minutes end to end between everything being fine and the crash. Building an insulation layer between the machine and the experts who are supposed to be flying it only makes it less safe by reducing control.
Proposed algorithm: If the flight computer thinks the engine looks "normal", then blare an alarm for x seconds before cutting the fuel.
I wonder if there have been cases where a pilot had to cut fuel before the computer could detect anything abnormal? I do realize that defining "abnormal" is the hardest part of this algorithm.
The incident with Sully landing in the Hudson is an interesting one related to this. They had a dual birdstrike and both engines were totally obliterated and had no thrust at all, but it came up later in the hearing that the computer data showed that one engine still had thrust due to a faulty sensor, so that type of sensor input can't really be trusted in a true emergency/edge case, especially if a sensor malfunctions while an engine is on fire or something.
As a software engineer myself I think it's interesting that we feel software is the true solution when we wouldn't accept that solution ourselves. For example typically in a company you do code reviews and have a release gating process but also there's some exception process for quickly committing code or making adjustments when theres an outage or something. Could you imagine if the system said "hey we aren't detecting an outage, you sure about that? why don't you go take a walk and get a coffee, if you still think there's an outage in 15 minutes from now we will let you make that critical change".
If the computer could tell perfectly whether the engine “looks normal” or not, there wouldn’t be any need for a switch. If it can’t, the switch most likely needs to work without delay in at least some situations.
In safety-critical engineering, you generally either automate things fully (i.e. to exceed human capabilities in all situations, not just most), or you keep them manual. Half-measures of automation kill people.
But humans can't tell perfectly either and would be responding to much of the same data that automation would be.
I wonder if they could have buttons that are about the situation rather than the technical action. Have a fire response button. Or a shut down on the ground button.
But it does seem like half measure automation could be a contributing factor in a lot of crashes. Reverting to a pilot in a stressful situation is a risk, as is placing too much faith in individual sensors. And in a sense this problem applies to planes internally or to the whole air traffic system. It is a mess of expiring data being consumed and produced by a mix of humans and machines. Maybe the missing part is good statistical modelling of that. If systems can make better predictions they can be more cautious in response.
If the warning period is short enough is it possible it's always beneficial or is 2-3 seconds of additional fuel during a undetected fire more dangerous?
First, the fire handles would override any delay and cut fuel (and other things) immediately.
Second: the window of time where you don't have enough altitude (aka time) to restart is relatively small. So this could easily be a temporary protection.
It is difficult to find exact data on this but restart to significant thrust seems to be in the 30-60s range. If you run the numbers on climb rate and glide time the possible danger zone is relatively small, a few minutes after takeoff at most.
Is this an extremely rare event? Yes. But most other accident causes are also rare, regardless of whether they are pilot error or mechanical.
For example: you might think no pilot would deploy the thrust reversers in flight but system protection errors and/or mechanical failures have conspired to allow it and a bunch of people paid in blood to learn that reverser deployment in flight at altitude was actually unrecoverable - contrary to conventional wisdom at the time. It turned out everyone was flying around with a "kill everyone now" mechanism. In some cases with a much lower margin of safety than previously believed due to the aforementioned "conventional wisdom" that if it happened it wouldn't be a big deal.
Know what else isn't normally a big deal (relatively speaking)? Accidental shutdown of both engines. Because a single engine shutdown is easily recovered and the aircraft can fly on one engine. And dual engine shutdown is easily recovered with a restart if you have enough altitude. But it turns out there's a small window after takeoff where it is fatal.
Somewhat relatedly shutting down the wrong engine in an engine failure scenario is so common they explicitly train crews to slow down and not immediately shut down an engine after failure because rushing just leads to dual engine loss.
Delay is probably worse - now you're further disassociating the effect of the action from the action itself, breaking the usual rule: if you change something, and don't like the effect, change it back.
There is a relatively short window where dual engine shutdown is unrecoverable. Once you have a bit of altitude (and these jets climb at 2000-3000fpm) you have time for a restart and as thrust comes back sink rate will decrease even on one engine.
My proposal is during this window if dual engine shutdown is commanded don't do it. Treat it like it is happening - show the EICAS message, give the alert, but don't actually do the shutdown until the window has passed. This gives the pilots 10 seconds of startle factor then a bit of time to flip the switch back on.
Single engine shutdown would still behave as today so sure if one engine eats a fan blade shut it down. Not that it matters, the engine computer is going to cut fuel in that case anyway.
Insert a delay only for shutting down the remaining engine and only for X seconds after transition to air mode. A delay that the fire handle overrides.
Just a tiny bit of insurance. There aren't any emergency scenarios at low altitude where engine shutdown works but pulling the fire handle does not. You are coming right back to land at the airport no matter what.
Shutting off both engines would display "ENG SHUTDOWN" in yellow text (caution) on the EICAS. If only one engine was shut down, it would say "ENG SHUTDOWN L" or "ENG SHUTDOWN R".
Any of these would trigger an unmistakable audible "BLEEP BLEEP BLEEP" to draw your attention to the screen so that you could see what the caution was. These messages are right next to the engine N1 indications anyway, so it would be immediately obvious that one or more of the engines was spooling down.
I'm doing it all the time while rebasing commits or force pushing to my branch. Sometimes I would just click the wrong buttons and end up having to stay late to clean the mess. It's a great thing I'm not a pilot. I would be dead by now.
This is a place that puts "Hacker" in the name despite the stigma in the mainstream. Given the intended meaning of the term, I would naturally expect this to be a place where people can speculate and reason from first principles, on the information available to them, in search of some kind of insight, without being shamed for it.
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.
For me it's mainly about intent/unearned confidence.
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.
For the record I don't think the designers of the switch or Boeing are idiots. The switches have guard notches and the throttle quad has metal guard edges to help prevent accidental activation.
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.
The benefit being elimination of the small window after takeoff where accidental dual engine shutdown is unrecoverable.
Obviously before implementing something like this the proper engineering and failure analysis has to be done.
I don't think most think they know better but it's frankly fun to speculate and this is a casual space rather than the serious bodies tasked with actually chewing over this problem in earnest.
First I am a pilot. Not commercial or jet rated but I like to think I have a tiny bit more insight than average.
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.
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.
(Different user here) Hacker News' "culture" is one of VC tech bros trying to identify monopolies to exploit, presumably so they can be buried with all their money when they die. There's less critical thinking here than you'd find in comments sections for major newspapers.
If Boeing only had the foresight to hire an army of HN webshitters to design the cockpit, this disaster could have been averted.
All the controls would be on a giant touchscreen, with the fuel switches behind a hamburger button (that responded poorly and erratically to touch gestures). Even a suicidal pilot wouldn't be able to activate it.
Yeah, people shouldn't bat ideas around and read replies from other people about why those ideas wouldn't work. Somebody might learn something, and that would be bad.
Is it possible it could have been an accident or a mistake by one of the pilots? How intention-proofed are engine cutoffs?