Posts about: "FADEC" [Posts: 194 Pages: 10]

DIBO
2025-06-16T22:56:00
permalink
Post: 11903856
Originally Posted by syseng68k
Another question, maybe a complete red herring: Is the TCMA a completely self contained module with it's own processor and software, (possibly the best option) or is it part the FADEC software package, perhaps just a task in a real time multitasking system ?
the answer to that was already provided earlier
Originally Posted by tdracer
There is no reason for TCMA to be listed in the MMEL as the only 'functional' portion is the via the electronic overspeed protection system (which is required for dispatch - no MEL relief) - the rest is software resident in the FADEC.

3 users liked this post.

Lead Balloon
2025-06-16T23:04:00
permalink
Post: 11903859
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.

...

7 users liked this post.

tdracer
2025-06-17T02:43:00
permalink
Post: 11903928
Originally Posted by Lead Balloon
Back to the subject of the TCMA, in order for the four channels (A and B for engine 1 and A and B for engine 2) to be truly independent, there would have to be, for example, four, separate weight on wheels sensors and two, separate throttle position sensors per throttle. I would be extraordinarily surprised if that's what has been implemented, but will happily stand correct.
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.

5 users liked this post.

dragon6172
2025-06-17T03:04:00
permalink
Post: 11903933
Originally Posted by tdracer
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.

3 users liked this post.

ignorantAndroid
2025-06-17T04:46:00
permalink
Post: 11903963
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!).

9 users liked this post.

Lead Balloon
2025-06-17T05:22:00
permalink
Post: 11903979
Originally Posted by ignorantAndroid
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.

4 users liked this post.

EDLB
2025-06-17T05:38:00
permalink
Post: 11903988
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.






7 users liked this post.

tdracer
2025-06-17T06:11:00
permalink
Post: 11903996
Originally Posted by Lead Balloon
Thanks tdracer and EXDAC for the info re the throttle position resolvers (and I'm aware of what is " well understood by those who specify, design, test, and certify critical aircraft systems", EXDAC). But do the separate resolver outputs involve physically separated wiring through separate looms and connectors and, if there are any earths or power connections involved, are they at separate points and, in the case of power connections, on separate busses? Duplicated, supposedly completely independent, "designed, tested and certified critical aircraft systems" occasionally have a common, single point of failure, not as a consequence of bad theoretical design but, rather, physical implementation.

And what of the weight on wheel sensor inputs to the 4 TCMA channels (2 per engine)? 4 separate sensors with 4 separated sets of wiring in different looms through different connectors?
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).

6 users liked this post.

TURIN
2025-06-17T06:26:00
permalink
Post: 11904001
Originally Posted by hawkeye red
Just a quick question to any B787 jockey out there\x85will a total electrical failure initiate a full engine shutdown\x85???
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)

7 users liked this post.

mechpowi
2025-06-17T07:24:00
permalink
Post: 11904022
Originally Posted by TURIN
I'm pretty sure the software is written independently. Same as Airbus, you don't want the same software error on duplicate critical systems.
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.

7 users liked this post.

Buster15
2025-06-17T07:37:00
permalink
Post: 11904033
Originally Posted by TURIN
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 that may be both AC and DC power supply.
EDML
2025-06-17T10:13:00
permalink
Post: 11904168
Originally Posted by JPI33600
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?
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.

1 user liked this post.

syseng68k
2025-06-17T10:21:00
permalink
Post: 11904174
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 ?.

1 user liked this post.

EDML
2025-06-17T11:26:00
permalink
Post: 11904222
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 ?.
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.

1 user liked this post.

OldnGrounded
2025-06-17T13:44:00
permalink
Post: 11904315
Originally Posted by ignorantAndroid
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?
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.).

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

Various posters seem to assume that all it takes is an incorrect air/ground signal, and the engines would shut down.
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.

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.
Yes, we know that.

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


Last edited by OldnGrounded; 17th Jun 2025 at 13:46 . Reason: Formatting

5 users liked this post.

JRBarrett
2025-06-17T13:50:00
permalink
Post: 11904318
Originally Posted by ignorantAndroid
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!).
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?


4 users liked this post.

JPI33600
2025-06-17T14:52:00
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 .
syseng68k
2025-06-17T15:40:00
permalink
Post: 11904406
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.

2 users liked this post.

EXDAC
2025-06-17T15:45:00
permalink
Post: 11904410
Originally Posted by syseng68k
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.


Last edited by EXDAC; 17th Jun 2025 at 16:09 .

3 users liked this post.

Bristolhighflyer
2025-06-17T16:46:00
permalink
Post: 11904457
CALLOUT TO MAINTENANCE CREW!

Originally Posted by T28B

(1) Based on a passenger's comments on line, a variety of things - passenger side - weren't working as expected. How many other things that "needed attention" could be worked on in the interval between arrival from the previous flight and the takeoff that ended up in the tragic crash?
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.

3 users liked this post.