The only affected models were 737s with the 766AT613-3D fuel control switch. The bulletin recommended that other models be inspected and any defects reported. It's unclear if any 787s were discovered to have the issue. Also the preliminary report mentions that the switches were replaced in 2019 and 2023, after the 2018 bulletin.
Here is the full SAIB on the Boeing fuel control switches. This report lists the part 4TL837-3D as the switch used on 787s, and is the part mentioned in the preliminary report on the accident.
The SAIB does single out the part 766AT613-3D, but that's for suggesting a replacement for it as 766AT614-3D.
Per the Honeywell catalog for 4TL837-3D, if is a Snap Action toggle switch. The base model doesn't have a locking mechanism, which is available as an option
still, it at least shows that there's been issues with the locking mechanism in the past. inadvertently bumping something that was assumed to be locked is a simpler theory; i find it hard to believe that a murder suicider would take this route, when the china nosedive option is easier, faster, and has a higher chance of success.
The preliminary report says the switches were triggered a second apart, so it would have to have been faulty switches and two inadvertent bumps. That seems unlikely to me.
Within a second apart. If I read the report right. The time resolution of the recorder?
And yes, it does sound like it was probably intentional. I would still like to see an engineering review of the switch system. Are they normally open or normally closed, In the end the switch instructs the FADEC to cut the fuel, but where does the wiring go in the meantime? what software is in the path? would the repair done before the flight be in that area?(pilot defect report for message STABS POS XCDR), and perhaps compromised the wires?
It's interesting to try to imagine a device that would prevent that, without causing more issues.
My preliminary idea is a "fuel bladder" for take-off that inflates with enough fuel to get the plane to a recoverable altitude, maybe a few thousand feet?
It’s a pointless exercise though - if one of the pilots wants to crash the plane, there’s almost nothing that can possibly be done. Only if someone can physically restrain them and remove them from the controls.
There’s always going to be many ways they could crash the plane, such a feature wouldn’t help. The pilots are the only people you can’t avoid fully trusting on the plane.
It's only pointless if we assume crashing was the intended result of the pilot. If the switches failed, or the pilot activated the switches by mistake, it's worth considering options for handling the inputs.
There's a balance of accidents to be found, I think. There are likely cases where fuel does need to be cut off to both engines, and preventing that would lead to accidents that might have been recoverable. This case shows that cutting off fuel to both engines during takeoff is likely unrecoverable. There have been cases where fuel is cutoff to the wrong engine, leading to accidents. Status quo might be the right answer, too.
So basically we need software that can 100% autonomously fly a plane. Software that is extremely reliable and trustworthy, basically. Software with multiple fallback options. Multiple AI agents verifying every action this software takes. Plus, ground-based teams monitoring the agents and the autonomous flight software.
> Again, it’s probably pointless but it’s an interesting thought exercise.
Coming up with ad-hoc solutions is easy, especially the less you know about a complex system and its constraints. I'd say it's not an interesting exercise unless you consider why a solution might not exist already, and what its trade-offs and failure modes are. Otherwise, all you're doing is throwing pudding against a wall, which can of course be fun.
That’s the whole fun part - come up with an “obvious” solution and the try to figure out the problems or risks it would cause.
For example, an obvious solution is that the switch can't be changed from "RUN" to "CUTOFF" when the throttle isn't at idle - this could be done with a mechanical detent because they're right next to each other. Simple!
But now you've introduced additional failure modes - throttle sticks wide open and the engine is vibrating and needs to be shut down - so maybe you make it that the shutdown switch can work for ONE engine at any throttle position, but if TWO get turned off, both throttles have to be off, but that introduces ...
Or you simply interlock the engine cutoff with the thrust lever position, any position other than idle prevents shutdown. This all goes through the flight computers already.
If there’s a fire or similar problem the fire handles will cut off fuel without the normal shutdown procedure, but the normal switches only need to be used at idle thrust.
I wonder if Airbus has this logic, since their philosophy is to override the pilot commands if they’d endanger the aircraft (which has its own issues of course) where’s Boeing will alert the pilots and still perform the action. I don’t have access to that information.
According to AI, Airbus places these switches on the overhead panel, so that alone would make it harder to inadvertently move them. Apparently, Airbus "protections do not extend to mechanical or FADEC‑controlled systems like the engine‑fuel shutoff valves. If you deliberately pull and flip the ENG MASTER lever to OFF, the FADEC will immediately close the LP and HP fuel valves and the engine will flame out. If you then return the lever to RUN (and you meet relight conditions), it will automatically relight."
As another commenter said the Airbus engine start/stop controls are located behind the thrust levers, and according to the A350 operations manual which I got my hands on there are two conditions required for the FADEC to command engine shut down: Run switch to off, thrust lever to idle.
So if that's correct on an Airbus aircraft you can't just switch off the engines when they're commanded to produce thrust. This also seems to be backed up by the difference in the guards for those controls in the Airbus cockpits.
The wings hosts the engine and a good portion of the fuel is quite a bit back from the nose in a big plane like 787. The engines lost power and hit just 180 knots just 4 seconds after the plan lifted off. The plane could have just easily broken up differently where the nose crashed in a different spot than where the fire would likely start.
At such a slow speed and altitude they could even have well crashed inside the airport perimeter and got a quicker/ better emergency response from the fire units at the airport.
Attempting this during takeoff or landing when the pilot monitoring is fully engaged and closely observing would be most difficult to execute .
Yes, the S.A.I.B. was about the switch, which is used in many airplanes,
and _should_ be checked and replaced. But they didn't. Because it wasn't mandatory. So my guess is those 50-70€ per switch were too expensive for the airline?
They reported that they replaced the whole middle console twice, so I cannot accept the 'it's pricey' or 'it's non-mandantory' as an excuse.
Hackers gona hack, so I'd like to get my hands on those switches, or better the whole fuel control panel. The pictures don't let me see or feel if a loose front panel could lift those shiny glowy locking knobs up by, say, 2.3mm and therefore unlock those switches, for example.
Only picture I could find online about this malfunctioning switch:
which looks like a really nasty 'mechanical inadequacy': half of the locking mechanism is the shiny glowy knobs. And they could _turn_. WTHolyF!? What where they smoking when designing or reviewing this?
In this fine post here, if you can read chinese or click the translation button on your browser:
(CAVE: I'm not inside boeing's tech support system so I cannot verify this from the original maintainance manual, since they seem to be practically guarded as trade secrets...)
I tried to order some of those switches (766AT613-3D and 766AT614-3D) and hope they get delivered ... this year. Anyone here got their hands on those switches to test their feel when handling or their resiliency?
(My hypothesis is:
Hand on throttle, Hand pushes throttle full forward to start, Hand rests on throttle while accellerating, then pilot does the routine rotate and plane takes of and all is fine and Hand lets go of throttle, Hand falls on both switches directy behind the throttle: Click-click-WTF?-BOOM.)
Of Course almost anyone involved in the airplane industry would prefer this to be a clear-cut case of 'pilot error' or 'Terrorism/Insanity' - but that doesn't exnorate the manufacturer or owner of building and flying an airplane where the engines can be shut off while taking off, IMHO.
As an aside, I especially like the disclaimers on the last page of Honeywells catalogue (this one: https://www.farnell.com/datasheets/2604543.pdf)
- don't use it for anything safety-of-live related.
- if it breaks because we delivered junk, we'll replace the switch - nothing else.
(I'm paraphrasing. Some laywers migth find a way to get out of this. I hope Boeing doesn't.).
Correction, I quoted the wrong price:
Honeywell's 4TL837-3D, which is the switch in the 787s according to the SAIB "EASA_SIB_NM-18-33_1-1.pdf", costs about 1300€. MIL-spec &c. certifications are costly.
Still cheap enough to not risk killing hundreds of people with the flick of a wrist.
Sorry about that.
Ah, yes, I know this of course, and I somehow temporarily imagined some kind of madness where the earth's sunny side is permanently pointing towards the sun.
Still flaky with double ID3 tags (front/back) or issues parsing metadata (so it fails decoding), but the issues with variable block size were solved. Most FLAC I handle on a large system play fine.
There are other issues related to streaming the FLAC via Range requests depending if it is WebAudio, <audio> or directly in a tab, however this applies to all audio/media in general.
A lot of tagging programs add them as they just get appended or prepended to the file regardless their content. Sometimes one program reads a format but writes in the other, I have personally found a FLAC in the wild with ID3v2 at the front, ID3 at the back (corrupt) and FLAC metadata as well. The FLAC metadata inside was wrong, the valid one was outside at the front (sadly it was a broken JIS encoding).
There is no sane approach to media. Between legacy formats, legacy tagging, and all kinds of implementation specific bugs, you are in for a ride if you want to cater to more than one decoder out there :)
