Posts about: "FADEC" [Posts: 231 Pages: 12]

the answer to that was already provided earlier

I preface this post by acknowledging all the previous posts in this, and the now-closed thread, about the TCMA, in particular the excellent posts by tdracer. (Ditto the noise analyses by Kraftstoffvondesibel and First Principal.)

I also note that the primary source of the information on which I’m basing my post is the content of Boeing’s patent application which, of course, does not contain any of the actual wiring diagrams or modification details of the TCMA, even assuming it has been implemented. (I understand from the now-closed thread, that there is an unresolved question as to whether a petition for an exemption from the TCMA requirement had been successful.)

The point of my post is to get other’s thoughts on one of the design principles of the TCMA system proposed in the patent application.

The ostensibly simple and elegant concept is described in the schematic of the system at figure 1 of the patent application. A copy of figure 1 is below.

The TCMA is the part of the schematic inside the dotted box numbered 16 , sitting with the EEC (others would call it the FADEC) in the solid box numbered 18 .

The heart of the TCMA comprises two switch relays, numbered 22 and 28 in the schematic, wired in series. Each of those switch relays is controlled by its own, dedicated engine control malfunction software, identified as the blobs numbered 130 . (The patent application identifies component 34 as a dedicated processor and 32 as the diode connected to the switch relays, but that is evidently a mistake. Component 34 is the diode and I can’t find a component number 32 anywhere in the schematics.)

Each relay switch and its controlling software is described as a ‘channel’, one A and one B. Both channels run continuously, monitoring throttle position (36 in the schematic) versus engine data fed from ARINC data bus lines (46 in the schematic) and “dedicated input sensors” not shown in the schematic. Those sensors presumably detect things like weight on wheels and perhaps RADALT.

This design is said to achieve redundancy, because if only one ‘channel’ detects the engine is producing excessive thrust while the throttle is set to idle, that channel will set its switch relay to CUTOFF and that is enough to change the state of the high pressure fuel shut off valve (58 in the schematic). No more motion lotion. In the words of the patent application: Both channels are “always actively monitoring engine function and independently have the capability of shutting down the engine.”

That arrangement wrinkled my crusty old avtech brow. In my mind – and this is why I’m seeking other’s thoughts – the advantage of redundancy arising from the two channels, either or both of which can shut the engine down, is not without risk. If it is possible for one of the channels to have some ‘glitch’ or hardware failure such that it does not detect an actual out of envelope condition justifying immediate shut down, with the other channel detecting the condition and shutting the engine down, it inexorably follows – does it not – that it is possible for one (or both) of the channels to have a ‘glitch’ or hardware failure that results in a shut down when there is no out of envelope condition?

Further, even if there are completely separate, duplicated sensors telling each channel things like the position of the throttle and whether or not there is weight on wheels, there remains the possibility of a combination of sensor failures/disconnects resulting in one channel being ‘convinced’ that an out of envelope condition exists, with a consequential cutoff of fuel to the engine.

I of course acknowledge the valid observations made about the remote probabilities of these kinds of glitches and failures.

I’ve heard rumours that there was much resistance to the mandating of TCMA systems. Having seen many, many strange faults caused by random shorts, open circuits, liquid ingress and other foreign objects, I can understand why there was that resistance. Every time you add something to a system and that added thing has electronic components and software and electrical connections and data inputs, you add risk of that thing malfunctioning or working perfectly but with erroneous inputs. In this case, there are effectively two added new things: two channels, each one of which has the ability to shut off the motion lotion to the engine to which they are strapped.

I make no comment on whether TCMA systems, if fitted, have anything to do with this tragedy.

My profound condolences to the families and friends of those killed or injured. My thoughts also go out to the many people who will be agonising over the potential causes and responsibility for it. And thanks to those who are working out the causes.

...

You'd be half right (or if you prefer, half wrong). Each channel of the FADEC has its own thrust lever position resolver. In other Boeing aircraft, there is a single resolver per engine, with dual electrical coils (i.e. electrically isolated but mechanically connected). But in order to go for full compliance with a (in my opinion) rather extreme FAA position regarding 'single failures' and 25.901(c), the 787 thrust lever actually has dual load paths, feeding to different thrust lever resolvers for each channel.

There are eight air ground sensors. Two truck tilt sensors and two strut compression sensors on each main gear.

I'm honestly mystified by the obsession with TCMA. The FADECs control almost every aspect of the engines, so there must be numerous ways they could cause a failure or uncommanded shutdown. So, even if we assume that the engines failed due to faults in the FADECs, why assume that TCMA would be involved? Surely it's more logical to simply posit that some unspecified bug in the FADEC software caused the failure. That bug could be related to TCMA, but it could just as easily involve any one of the dozens of other subroutines that likely exist.

Various posters seem to assume that all it takes is an incorrect air/ground signal, and the engines would shut down. But in fact it would also require the FADECs to read the thrust levers as being at or near idle... AND the engines failing to respond to closure of the fuel metering valve. I've read the entirety of both threads, and I haven't seen anyone even attempt to explain how a malfunction within the airframe could cause both of those things to occur on both engines (or even one engine!).

There is at least one thing common to the TCMA on each engine: The TCMA software.

My recollection may be inaccurate, but wasn't there something in the software for 787 generator control units that would cause generator shut down if the aircraft was 'powered up' for a continuous 248 days? Same software, so all 4 generators would shut down. Is my recollection inaccurate?

What we do know, for sure, is that the TCMAs have the same 'authority' and effect as the fuel cut-off switches. The difference is that the crew control the latter.

We have two donks individual fuel supply cut simultaneous in split seconds. There is no rudder activity visible for any thrust asymmetry during this timeframe. TCMA is implemented via the FADECs which are independent for each engine with their own power source from each engine. TCMA is designed to shut down its engine if its power lever is in retard position and the engine is still powering with too much thrust. In addition the airplanes ground sensors must indicate that it is on the ground. For each thrust leaver there are two independent position sensors. It is similar redundant designed as in modern car acceleration pedals. A dual redundancy in each thrust leaver. For TCMA to shut down two fuel supplies within split seconds we have to assume that 4 thrust leaver sensors malfunctioned and the ground sensing logic failed at the same time. The probability that this happens is nil (may be 1 in every 10exp15 hours) which would be about 10 times the age of our universe.
Unless there is a software error in the FADEC TCMA system which only came to light on this flight. But there seem to be nothing special on this flight until rotation. If there is a software error I expect, that we get false single engine shut downs first. And that would already made the news if it happened during rotation.

The wiring between the two (per engine) FADEC channels is separate and isolated from each other. In the areas potentially subject to cross engine rotor burst damage, that wiring is physically separated by a considerable distance. About the only place where the Channel A and B thrust lever resolver wiring is close proximity is in the thrust lever quadrant. We've been designing FADEC aircraft for 40 years - and the requirements for isolation are detailed and well understood.

I've repeatedly posted I don't know the details of the 787/GEnx-1B FADEC air/ground logic - and I know even less about the 787 air/ground system architecture. That being said, I think the whole air/ground is a bit of a red herring - even with a false air/ground indication, it's going to take a very major flaw in the FADEC logic for TCMA to activate without several other things happening (such as the thrust levers being moved to idle - which all by itself is going to make for a bad day if it's done at rotation).

No it won't, each engine has an independent power supply dedicated to the FADEC.
This has been answered many times.
(B787 LAE not a jockey)

And so the wheel starts again. That was covered by tdracer in the earlier thread: Both channels of FADEC and thus TCMA run the same software from the one and only source code.

And that may be both AC and DC power supply.

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.

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

Yes. Other aircraft systems get the information through the FADECs (including the DFDRs) but the FADECs itself are isolated including independent alternators (PMG). There are two FADECs per engine and each has it's own throttle position sensor. That was explained by tdracer at some point in the old thread.

I think you may be inferring something that isn't actually true. It certainly isn't true in my case. Wanting to explore the details of a function known to be designed to shut down engines, in a case where unexplained shutdown of engines appears to be a likely cause or contributing factor, doesn't suggest that we are assuming TCMA is involved. It's just exploring the details of a a function that is designed to do that and doesn't put on a light, smoke and sound show, or produce obvious debris and residue, when it does.

I think those of us who are persistently trying to learn the details of the sensor inputs to and logic of TCMA (I prefer that characterization to "obsessed with") understand quite well the points you make here — at least those of us whose interest survives in this new thread. However, I at least, and I believe others as well, have also come to the tentative conclusions that (a) the accident aircraft had engines providing little to no useful thrust from nearly the first moments after rotation, and (b) the only possible reasons for that which have been considered here so far involve the sudden and approximately simultaneous shutdown of those engines, most likely by interruption of fuel flow (because that's one of the very few things we know that can do that without producing big bangs, flames and smoke, etc.).

I don't agree that it's more logical to posit that something we don't know about has shut down the engines rather than something that we do know about that is intended to shut down engines. Do you know of other routines/subroutines in the FADEC that shut down fuel supply?

I certainly don't assume that and I haven't seen posts from others (that I consider serious and reasonably well-informed) that "seem to assume" that.

Yes, we know that.

Right, and you won't see a serious attempt to do that until we know, at least, what specific sensor inputs the TCMA function uses to determine the air/ground state of the aircraft and the logic that uses those to make the determination.

Many years ago I maintained a Hawker 1000 business jet equipped with PW305 engines with FADEC. The fuel control did not have a separate switch to control fuel flow to shut down the engines. Shutdown was accomplished by pressing a release on the power levers allowing the lever to be pulled past the idle stop all the way to the cutoff position.

One day upon returning from a flight, the crew pulled both power levers to cutoff. The right engine shutdown immediately as expected, but the left engine kept running. By the time we in maintenance got out to the airplane, the engine finally shutdown by itself.

Troubleshooting found the cause of the problem. The cutoff position of the power lever closed a micro switch that sent a ground to the FADEC. That ground went through two discrete wires. One went directly to one input on the FADEC. The other went through a squat switch on the main gear leg to a second input on the FADEC. The engine would only shutdown immediately if both inputs went to ground simultaneously. If only one input went to ground, the FADEC would delay shutdown for 30 seconds. This was to protect against an inadvertent movement of the power lever to the cutoff position in flight causing an immediate shutdown.

The squat switch on the left gear leg had failed in the open position, causing the problem.

I am wondering if more modern FADEC engines have similar protections against immediate shutdown in the air? I can see why the designers of the Hawker implemented the system the way they did, because the shutdown command was integral to the power lever, and it potentially could be pulled to the cutoff position in flight by an inadvertent release of the locking mechanism that would normally prevent it from going past the idle stop, whereas modern FADEC engines like found on the 787 have a discrete locking switch.

But, if a similar protection against immediate shutdown does exist in the 787, would the engines keep running for a period of time (in the air) even if the fuel control switch was accidentally or deliberately moved to \x93off\x94?

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 .

JPI33600:

Thanks. From that I assume that the thrust resolver signal is fed to the FADEC alone ?. The reason for the clarification was that it was not clear if the signal is fed to other subsystems, which could affect the analysis.

That is certainly typical. The FADEC/EEC/ECU includes the resolver angles in its output data for consumption by other systems such as displays and flight controls.

CALLOUT TO MAINTENANCE CREW!

Can we please have a productive discussion on maintenance, to examine a new area and avoid the hamster wheel? Can someone from turnaround crew working on 787's generally (or ex A-I staff) comment on what standard checks are performed in the allocated time?

PAX have reported cabin issues on the inbound flight, (and other A-I flights), from no aircon for the whole flight to unresponsive screens etc. TDRacer has explained that the FADEC is shielded from other electrical systems. However, is there ANY correlation with these cabin malfunctions and the crash other than 'poor maintenance' we can find here? E.g. what if one of Air Canada's 787's entered YYZ with the packs malfunctioning - what inspection and maintenance would be performed? C ould a maintenance engineer working on fixing the packs do something to trigger a later plane-wide power loss? Or could non-functioning cabin electrics give us a clue as to other more fatal issues present? Could the system isolation protections have failed somehow? E.g. water ingress?

*Each time I post this, it gets ignored, but it's an unexplored area and my view is maintenance may have played a large part in this crash, - please help to narrow it down. Thanks.