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

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?

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:

For reference, this is the permalink of the said comment .

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

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)?

To make things clear, just check this B787-related alert service bulletin dated 25 Nov 2014 (my bold):



787 RAT hydraulic pump location

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:
Second, the doses apparently don't need to be that high to result in a problem. A x10 dose seems sufficient:
Third, the main cause of the incident seems to be associated with magnesium salts dissolving in water instead of fuel:
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.

Huh??? I can't find any indication of that dose in the report:
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?

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.

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):

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 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.

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.

Agreed, but this "test" won't tell you if the detents are aligned or misaligned with the lock tab.

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".

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.