Posts by user "JPI33600" [Posts: 10 Total up-votes: 0 Pages: 1]

JPI33600
June 17, 2025, 10:01:00 GMT
permalink
Post: 11904160
Not an avionics specialist, but electronics / software engineer here, with extensive experience in hardware fault tracking, protocol monitoring and software debugging in embedded systems : mods, feel free to delete this post if I am completely out of track (and thank you for the huge amount of work you've done trying to keep this discussion clean).

After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first.

Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming):

1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead?

2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case?

The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust.

Does it make sense or is it pure fantasy?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Electrical Failure  FBW  RAT (All)  RAT (Deployment)  Thread Moderation

JPI33600
June 17, 2025, 14:52:00 GMT
permalink
Post: 11904368
Originally Posted by syseng68k
EDML: "No. The throttle position sensors (dual per engine) are part of the FADEC. The throttle position data is not transmitted through the ARINC busses of the aircraft".

To clarify, you are saying that the throttle position sensors are wired directly to the FADEC, and nothng else ?.
In his reply to your question above, EDML said that tdracer explained this specific wiring in a comment of the old thread (I had missed this detail too), and indeed, this is what he said:

The thrust lever inputs are hardwired (resolvers connected to the thrust levers, powered by the FADEC), other aircraft communications on the 787 are on an ethernet based network.
For reference, this is the permalink of the said comment .

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): ARINC  FADEC

JPI33600
June 17, 2025, 16:41:00 GMT
permalink
Post: 11904452
Question to avionics specialists again. Below is the main drawing of the TCMA subsystem, included in the patent document . I can't stop scratching my head about the link I have circled in red in the center of the image. AFAICS, this link shunts the internal RUN path of TCMA entirely : the RUN signal is supplied by the RUN contact of relay assembly 52, then goes through the common and RUN contacts of relay 22, then goes through the common and RUN contacts of relay 28, then exits TCMA subsystem 18 by wire 124, and... we're back to square 1, because of the link. So TCMA subsystem 18 doesn't actually control the OPEN relay 118 of the HPSOV, only the CLOSED relay 100, and in the case where relay 22 and/or 28 are activated, both coils of HPSOV could even be energized at the same time.

Obviously enough, this isn't a real circuit diagram, but shouldn't this link be removed from the patent drawing?


Odd link in TCMA patent drawing

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): High Pressure Shutoff Valve  RUN/CUTOFF

JPI33600
June 18, 2025, 16:12:00 GMT
permalink
Post: 11905370
Once again, a question for people who know: what happens if voltage is applied to CLOSED coil of HPSOV when OPEN coil was already energized (dual conflicting inputs)?

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): High Pressure Shutoff Valve

JPI33600
June 19, 2025, 11:34:00 GMT
permalink
Post: 11905954
The RAT is an electrical generator, not a hydraulic pump. How many times does this need to be said?
To make things clear, just check this B787-related alert service bulletin dated 25 Nov 2014 (my bold):

This service bulletin provides instructions to replace the Ram Air Turbine (RAT) Pump and Control Module
Assembly to prevent failure of the hydraulic pump at low air speed. The RAT Assembly provides an emer-
gency source of electrical and hydraulic power
for the primary flight control if the left, center and right main
hydraulic systems fail. Loss of the RAT Pump and Control Module Assembly could lead to loss of control
of the airplane when emergency power from RAT Assembly is needed. If this change is not incorporated
on the RAT Assembly and hydraulic power is lost on the left, right and center main hydraulic systems, then
the RAT Assembly may not provide sufficient hydraulic power which could result in the loss of many critical
control systems that are necessary for safe flight.


787 RAT hydraulic pump location

Last edited by Senior Pilot; 19th June 2025 at 11:40 . Reason: Image

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Generators/Alternators  Hydraulic Failure (All)  RAT (All)  RAT (Electrical)

JPI33600
June 21, 2025, 15:52:00 GMT
permalink
Post: 11907864
Originally Posted by EDLB
Some assumed numbers about normal biotreatment.
https://www.biobor.com/wp-content/up...ation-IATA.pdf

If we assume 50 tonnes fuel load a 100ppmw biotreatment will be 5kg of biocide total in all tanks.

The GEnx-1B will burn about 4,5kg/s fuel each on a take off run (give or take a bit) so 9kg/s in both donks for about 20s until rotate.

So the total nominal biocide dose could be pumped in about half a second through both engines on take off power if it where not mixed at all and arrives in both engines at the same time.

This gives you an idea that with the nominal amount of biocide dose not much could have happened. If biocide is the source of this dual EFATO than an extreme overdose in addition to wrong application preventing mixture with the fuel had to be the case.
This sounds convincing, but I have read the investigation report on Jetstar Airways serious incident (VHVKJ) with great attention, and if I understand it right, things may be a bit more subtle:

First, the problem involves the valves (notably but not exclusively FMV and FSV), not the combustion of the product:
It is highly probable that Residue primarily composed of magnesium salts accumulated in FMV spool and FSV spool, which meter engine combustion fuel, restricted movement of spools, caused inadequate fuel metering, thereby led to engine rpm oscillation that occurred from the first flight after conducting biocide treatment.
Second, the doses apparently don't need to be that high to result in a problem. A x10 dose seems sufficient:
Investigation into similar cases revealed that there were six cases reported in which both engines could not start in twin engine aircraft, and one case each in which all engines could not start in four-engine aircraft and engine thrust could not be adjusted. Any of these cases were presumed to have been caused by concentration ratio of biocide (Kathon FP1.5) that was set at higher values (about 1,000 ppm) than specified ones during biocide treatments.
Third, the main cause of the incident seems to be associated with magnesium salts dissolving in water instead of fuel:
From the biocide test result, it is probable that Magnesium salts contained in biocide did not dissolve in fuel, but dissolved in water contained in fuel and were accumulated in spools as crystals through the engine fuel system.
Fourth, and despite the report indicating that ( my bold ) "In this serious incident, it is highly probable that, when the Aircraft was descending for landing, there occurred oscillation in rpm of each engine causing both engines to temporarily fall below idle at separate times because Residue primarily composed of magnesium salts accumulated in spools impeded movement of spools that involved in fuel metering of both engines.", it should be noted that the reported "rpm oscillations" of left and right engines were close to each other in time:



These "rpm oscillations", leading to substantial loss of thrust, could as well have occurred simultaneously, and 81 seconds (for the RH engine) is an awfully long time. According to the report, Kathon FP1.5 is not used anymore for biocide treatment, but another contributor ( nachtmusak , who seems to be a petrol specialist) suggested that other products may have similar effects .

Therefore, regarding the case we are discussing at large (thanks again, mods!), I think we shouldn't overlook the hypothesis of fuel contamination by biocide, since it is a single point of failure (among a very limited number of SPoFs) from a system analysis point of view.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): EFATO  Fuel (All)  Thread Moderation

JPI33600
June 21, 2025, 17:23:00 GMT
permalink
Post: 11907918
Originally Posted by Gary Brown
In the Japan descent case also discussed above it was 100 x the correct dose....
Huh??? I can't find any indication of that dose in the report:
(5) From the results of the interview with the CS who was in charge of biocide treatment work, it is probably that the CS calculated according to the AMM so that the recommended final concentration ratio in the tanks would be about 100 ppm, and additionally loaded the treated fuel as described in 2.7 (11).
According to the AMM calculation formula, the concentration ratio of the additional biocide treated fuel is calculated to be about 250 ppm in the left tank and about 285 ppm in the right tank. However, there was no record of the calculation of the concentration ratio of the biocide and the dosage amount. It is desirable to keep these records because they are considered to be important for traceability of maintenance work.
So it seems they didn't keep any record of the quantity, but they think they did it as prescribed. Is there a public source for the numbers you gave?

Subjects: None

JPI33600
June 21, 2025, 18:20:00 GMT
permalink
Post: 11907962
Originally Posted by JustusW
This is the type of software we are usually subject to in our everyday lives basically everywhere. Your phone, your fridge, your oven, your water heater, your car, etc. pp. ad nauseam.

In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with.

(...)

Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine.

Enter the FPGA.

While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check.
Can you provide a source for this? I ask because when I look for info about FADECs generally and FADEC 3 more specifically, I find this kind of documentation (notice the mention of FADECs in the lower left corner):



... which is part of a larger Powerpoint presentation by Ansys , explaining that these products are developed with SCADE development workbench, generating either Ada or C code, and that the resulting code runs under a microkernel realtime operating system:



Now, obviously enough, a CPU can be embedded in an application-specific FPGA, but it would still execute machine code. And from my experience in other embedded systems development, current CISC or RISC CPUs have more than enough computation power to implement command and control on a modern turbofan.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): FADEC

JPI33600
July 12, 2025, 09:33:00 GMT
permalink
Post: 11920418
Well, speaking of fuel-cut switches, I read NM-18-33 SAIB with attention, and as a not-that-fluent english speaker, I stumbled on this sentence (my bold):

If the locking feature is disengaged , the switch can be moved between the two positions without lifting the switch during transition, and the switch would be exposed to the potential of inadvertent operation.
I could hardly figure what the "disengaged" word meant in this context, so I did a Google search for the switch part numbers (especially "766AT614-3D") to figure the difference between them, and a page from this chinese web site was part of the results.

And while I was painfully crawling the thread, I noticed the following picture about an "undesirable condition":
Incorrect tab lock position on fuel cut-off switch
Incorrect lock tab position on fuel cut-off switch

If this incorrect mounting is actually possible, it would possibly remain unnoticed from the pilots (normal "pull-up then move" action is unaffected), but it would cancel the protective function of the so-called "locking tab", and even limit the travel of the switch handle in both directions, making it more vulnerable to an undesired change of state.

The photos above seem convincing enough, but I'd be very grateful for an informed opinion on this assembly mistake. Even if this is possible, the probability of both switches being unexpectedly snapped seems very remote to say the least, but not as remote as previously estimated.







Subjects (links are to this post in the relevant subject page so that this post can be seen in context): Fuel (All)  Fuel Cutoff  Fuel Cutoff Switches  SAIB NM-18-33  Special Airworthiness Information Bulletin

JPI33600
July 12, 2025, 21:20:00 GMT
permalink
Post: 11920840
Originally Posted by Sailvi767
It’s very easy to tell if the switch is wearing or defective.
I beg to differ: not from a pilot's point of view who didn't read the bulletin. Please see below about the recommended "tug".

Not a pilot, but electronics engineer here: I finally understood what's wrong with the "defective" switches: on such a switch, if you raise it up (to change its position) and you turn it slightly clockwise or counterclockwise before releasing it, it will operate normally, but the detents are now "crossing" the lock tab, and this one doesn't prevent a move-it-without-raising-it-first action anymore. As far as I can tell from the position of the switches, you have to extend your arm sideways and put some effort in your wrist to activate these switches: chances are that such a movement results in some amount of rotation.

It’s also the norm for everyone operating the switches to give them a tug to insure they are in the detents.
Agreed, but this "test" won't tell you if the detents are aligned or misaligned with the lock tab.

It’s simply inconceivable that both switches failed in exactly the same way at almost exactly the same time and no pilot who flew the aircraft in the last year or so noticed the issues.
If both switches are "defective" ones (remember, that doesn't mean they don't do their job, only that some specific action may put them in a state where protection against unwanted action is lost), the same action from the same pilot may well put both switches in the dangerous configuration.

By the way, I find that the "check" recommended in the bulletin for a switch suspected from being "defective" is incredibly misleading. It will possibly detect a switch where the cap has already been turned, resulting in a misalignment of the lock tab with the detents, but it won't detect a switch waiting for a turn to put it in the dangerous configuration. The "check" should be "pull on the cap to raise it, try to turn it clockwise or counterclockwise while raised: if it can be turned, it's defective".

Add to that the CVR statement and it’s beyond inconceivable.
On the contrary, according to the above scenario, anything interacting with the switches (which are close to each other) can move them unexpectedly (the "iPhone falling" case), and the CVR statement would reflect the surprise of a pilot who actually didn't do anything wrong.

May I add that I consider the probability of such a scenario as very very thin, but I wanted to emphasize the fact that we must keep our minds open, instead of jumping to conclusions too early.

Subjects (links are to this post in the relevant subject page so that this post can be seen in context): CVR  Fuel (All)  Fuel Cutoff Switches  Fuel Cutoff Switches (detent)