2025-06-20T05:20:00
permalink Post: 11906598
Assuming there is some credence to the article, dual engine failure due to water contamination is the leading theory.
Last edited by Lookleft; 20th Jun 2025 at 05:57 .
2025-06-20T05:30:00
permalink Post: 11906603
TCMA things, imagination and evidence
You may be surprised to know that TCMA doesn't require that, it just requires a differential between commanded and actual thrust.
It has never triggered during takeoff until now. Maybe it still hasn't been. We'll see. Given there is an actual example of a 787 in the wild shutting down both of it's engines when it shouldn't (ANA), I'm surprised how complacent people are that this couldn't be the cause..Software can always have weird corner failures that could never have been thought of or tested.
It has never triggered during takeoff until now. Maybe it still hasn't been. We'll see. Given there is an actual example of a 787 in the wild shutting down both of it's engines when it shouldn't (ANA), I'm surprised how complacent people are that this couldn't be the cause..Software can always have weird corner failures that could never have been thought of or tested.
Note that the thrust lever actuators are wired to the FADECs, and that the TCMA gets the T/L position from that. For TCMA to trigger, it has to determine that its FADEC (on that engine) failed to achieve a commanded reduction in thrust. So we're either looking at a weird, unprecedented edge case, or a FADEC failure, or both.
Just so I have this clear, are you saying that the implementation of the TCMA functionality involved
no
new components being added to the pre-existing FADEC? Are you saying, in effect, that the two switch relays described in the TCMA patent application, which relays and their configuration achieves the described two channel redundancy, were already there as components or are mere depictions of what the software does itself?
Originally Posted by
Lead Balloon
I am not suggesting you are wrong and, as I've said before, the descriptions and schematic in the patent application are just 'big hands / small maps' concepts. However, if TCMA functionality "is simply a bit of software in the FADECs", merely sending a 1 or 0 or other signal into a point in the pre-existing FADEC that already had control over fuel cutoff (with the TCMA software merely monitoring data busses, rather than direct sensor outputs, to work out thrust lever position and whether or not the aircraft is 'on the ground' for TCMA purposes) I for one would really like to know that for sure and get my head around the implications.
With a MCAS crash, it required a hardware problem with an AOA sensor, used as input to a correctly working MCAS, to cause the aircraft to behave erratically. With a correctly working TCMA, I believe it'd require two hardware problems to get TCMA to shut down the engine, as there'd have to be an implausible thrust lever reading, and a FADEC/engine failure to process it within the TCMA allowed range ("contour"?). On both engines, separately and simultaneously.
That leaves a software problem; it's not hard to imagine. The issue is, at this point it's just that: imagination. I could detail a possible software failure chain, but without examining the actual code, it's impossible to verify. We simply don't have the evidence.
I could just as well imagine a microwave gun frying the electronics on both engines. An escaped hamster under the floor peeing on important contacts. A timed device installed by a psychopathic mechanic. There's no evidence for that, either.
This process is a way to psychologically cope with the unexplained accident, but because it lacks evidence, it's not likely to identify the actual cause. We've run the evidence down to "most likely both engines failed or shut off close to rotation, and the cause for that is inside the aircraft". Since the take-off looked normal until that failure, we have no clues as to the cause hidden inside the aircraft. We need to rely on the official investigation to discover and analyse sufficient evidence. The post-crash fire is going to make that difficult.
"Both engines failed or shut off close to rotation" explains all of the evidence : it explains an unremarkable take-off roll, loss of lift, absence of pronounced yaw, loss of electrical power, loss of the ADS-B transponder, RAT deployment, the noise of the RAT banging into place and revving up, emergency signs lighting up, a possible mayday call reporting loss of thrust/power/lift, and a physically plausible glide from a little over 200 ft AAL to the crash site
It explains what we saw on the videos, what the witness reported, where the aircraft ended up, and the ensuing sudden catastrophe.
I don't believe we have evidence for anything else right now—I'd be happily corrected on that.
-----
Edit: the evidence of the crash photo with the open APU inlet door, and the main gear bogeys tilted forward, are also explained by the dual engine failure/shut off.
Last edited by Musician; 21st Jun 2025 at 06:48 . Reason: more evidence
17 users liked this post.
2025-06-20T05:47:00
permalink Post: 11906608
I don't have any direct knowledge, but yes, that's my understanding based primarily on tdracer's comments. It also just makes sense. I'm pretty confident that all the necessary hardware already existed because of the need for N2 overspeed protection. A failure in one FADEC channel could drive the FMV fully open, leading to an overspeed and uncontained engine failure. For regulatory purposes, it would be unacceptable to have a single point of failure with catastrophic consequences, so it would be necessary to make the inactive FADEC channel capable of cutting off fuel in that case.
The air/ground signal would've already been present as well. It would be needed for switching between ground idle, flight idle, and approach idle. Tdracer has discussed that as well, in past threads.
The air/ground signal would've already been present as well. It would be needed for switching between ground idle, flight idle, and approach idle. Tdracer has discussed that as well, in past threads.
Re air/ground input to the TMCA, I am more interested in whether that is hardwired from the sensors / systems involved or - as appears to be the case just based upon what I've read here - read from ARINC or other format data.
2 users liked this post.
2025-06-20T06:18:00
permalink Post: 11906620
TCMA can't be disabled electrically. It's just software, and all of the hardware involved serves other functions which are still needed while in the air. For example, the FADECs would command the HPSOV closed in case of N2 overspeed. That would have the exact same effect as TCMA.
4 users liked this post.
2025-06-20T07:31:00
permalink Post: 11906655
If power failed first?
If power failed first,
What happens to TCMA sensors like Weight on Wheels? Radio altimeter? Is there one Weight on Wheels per engine? Is there one radio altimeter per engine? If not, why not? Are the TCMA sensors directly powered as part of FADEC? If not, why not?
Is it possible that there was a noticeable loss of thrust caused by loss of fuel pumps and the pilot responded by cycling thrust to zero and back, trying to clear the problem, inadvertently triggering the TCMA?
What happens to TCMA sensors like Weight on Wheels? Radio altimeter? Is there one Weight on Wheels per engine? Is there one radio altimeter per engine? If not, why not? Are the TCMA sensors directly powered as part of FADEC? If not, why not?
Is it possible that there was a noticeable loss of thrust caused by loss of fuel pumps and the pilot responded by cycling thrust to zero and back, trying to clear the problem, inadvertently triggering the TCMA?
1 user liked this post.
2025-06-20T10:01:00
permalink Post: 11906794
Engineer not a pilot. Experience in analog front ends, A2D and R2D conversion and embedded systems generally but no specific knowledge of the 787 or GEnx.
I like everyone else have no evidence that TMCA played a role but given that it is one of the few systems with the ability to cut fuel to the engines, here are some thoughts on how signal processing could have extended the window of when TMCA could bite. In particular, I'm looking at the time immediately after the nose lifts up when something may have physically shifted onboard.
I'll phrase it as a number of questions but realise that the few people who can answer may not be able to for now.
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Q1: Am I correct in that assumption that when on the ground, overspeed with respect to EITHER resolver A OR resolver B can trigger TMCA?
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
Q2: When the nosewheel lifts off but the MLG is still on the ground and RadALT is close to ground, will G still be true?
Next, it is common when data fusing multiple inputs that there is a desire to clean up a signal before it is sampled digitally. This can remove effects such as switch bounce. The inclusion of low pass filters or hysteresis will generally add a propogation delay.
Q3: Is there a slow filter (Tc>=1s) in the ground/air logic which could have caused a slight delay before G became false after takeoff further extending the opportunity of TMCA to activate?
Q4: Does TMCA act almost instantly or does it wait for the fault condition to stay asserted for a period of time before acting?
At that point, the total energy of the system would have comprised of the kinetic energy of the aircraft travelling at Vr, the rotational inertia of the engines and the potential energy of whatever fuel is beyond the cutoff valves.
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
It would still need a mechanism for at least one throttle input to each FADEC to misbehave at the same time. Resolvers are fed with an excitation signal to the rotor and take back two orthogonal signals (Cos and Sin) from stator windings. Usually, the excitation comes directly from the resolver-to-digital (R2D) circuit but sometimes an external signal source is used. I would hope that in an aircraft system, each channel would be kept independent of everything else.
Q6: Does the excitation signal for the 4 throttle resolvers (2 per side) come from 4 independent (internal) sources?
My last thought for a single point of failure between both throttles would be a short between two wires or connection points carrying resolver signals, one from each side. Whether this could be caused by swarf wearing within a wiring loom, a foreign object moving about, crushed wires or even stretching of adjacent wires, I have absolutely no idea.
Q7: Do resolver signals from left or right, either channel A or B, run next to each other in a loom at any point?
I like everyone else have no evidence that TMCA played a role but given that it is one of the few systems with the ability to cut fuel to the engines, here are some thoughts on how signal processing could have extended the window of when TMCA could bite. In particular, I'm looking at the time immediately after the nose lifts up when something may have physically shifted onboard.
I'll phrase it as a number of questions but realise that the few people who can answer may not be able to for now.
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Q1: Am I correct in that assumption that when on the ground, overspeed with respect to EITHER resolver A OR resolver B can trigger TMCA?
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
Q2: When the nosewheel lifts off but the MLG is still on the ground and RadALT is close to ground, will G still be true?
Next, it is common when data fusing multiple inputs that there is a desire to clean up a signal before it is sampled digitally. This can remove effects such as switch bounce. The inclusion of low pass filters or hysteresis will generally add a propogation delay.
Q3: Is there a slow filter (Tc>=1s) in the ground/air logic which could have caused a slight delay before G became false after takeoff further extending the opportunity of TMCA to activate?
Q4: Does TMCA act almost instantly or does it wait for the fault condition to stay asserted for a period of time before acting?
At that point, the total energy of the system would have comprised of the kinetic energy of the aircraft travelling at Vr, the rotational inertia of the engines and the potential energy of whatever fuel is beyond the cutoff valves.
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
It would still need a mechanism for at least one throttle input to each FADEC to misbehave at the same time. Resolvers are fed with an excitation signal to the rotor and take back two orthogonal signals (Cos and Sin) from stator windings. Usually, the excitation comes directly from the resolver-to-digital (R2D) circuit but sometimes an external signal source is used. I would hope that in an aircraft system, each channel would be kept independent of everything else.
Q6: Does the excitation signal for the 4 throttle resolvers (2 per side) come from 4 independent (internal) sources?
My last thought for a single point of failure between both throttles would be a short between two wires or connection points carrying resolver signals, one from each side. Whether this could be caused by swarf wearing within a wiring loom, a foreign object moving about, crushed wires or even stretching of adjacent wires, I have absolutely no idea.
Q7: Do resolver signals from left or right, either channel A or B, run next to each other in a loom at any point?
4 users liked this post.
2025-06-20T11:02:00
permalink Post: 11906835
Engineer not a pilot. Experience in analog front ends, A2D and R2D conversion and embedded systems generally but no specific knowledge of the 787 or GEnx.
I like everyone else have no evidence that TMCA played a role but given that it is one of the few systems with the ability to cut fuel to the engines, here are some thoughts on how signal processing could have extended the window of when TMCA could bite. In particular, I'm looking at the time immediately after the nose lifts up when something may have physically shifted onboard.
I'll phrase it as a number of questions but realise that the few people who can answer may not be able to for now.
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Q1: Am I correct in that assumption that when on the ground, overspeed with respect to EITHER resolver A OR resolver B can trigger TMCA?
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
Q2: When the nosewheel lifts off but the MLG is still on the ground and RadALT is close to ground, will G still be true?
Next, it is common when data fusing multiple inputs that there is a desire to clean up a signal before it is sampled digitally. This can remove effects such as switch bounce. The inclusion of low pass filters or hysteresis will generally add a propogation delay.
Q3: Is there a slow filter (Tc>=1s) in the ground/air logic which could have caused a slight delay before G became false after takeoff further extending the opportunity of TMCA to activate?
Q4: Does TMCA act almost instantly or does it wait for the fault condition to stay asserted for a period of time before acting?
At that point, the total energy of the system would have comprised of the kinetic energy of the aircraft travelling at Vr, the rotational inertia of the engines and the potential energy of whatever fuel is beyond the cutoff valves.
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
It would still need a mechanism for at least one throttle input to each FADEC to misbehave at the same time. Resolvers are fed with an excitation signal to the rotor and take back two orthogonal signals (Cos and Sin) from stator windings. Usually, the excitation comes directly from the resolver-to-digital (R2D) circuit but sometimes an external signal source is used. I would hope that in an aircraft system, each channel would be kept independent of everything else.
Q6: Does the excitation signal for the 4 throttle resolvers (2 per side) come from 4 independent (internal) sources?
My last thought for a single point of failure between both throttles would be a short between two wires or connection points carrying resolver signals, one from each side. Whether this could be caused by swarf wearing within a wiring loom, a foreign object moving about, crushed wires or even stretching of adjacent wires, I have absolutely no idea.
Q7: Do resolver signals from left or right, either channel A or B, run next to each other in a loom at any point?
I like everyone else have no evidence that TMCA played a role but given that it is one of the few systems with the ability to cut fuel to the engines, here are some thoughts on how signal processing could have extended the window of when TMCA could bite. In particular, I'm looking at the time immediately after the nose lifts up when something may have physically shifted onboard.
I'll phrase it as a number of questions but realise that the few people who can answer may not be able to for now.
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Q1: Am I correct in that assumption that when on the ground, overspeed with respect to EITHER resolver A OR resolver B can trigger TMCA?
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
Q2: When the nosewheel lifts off but the MLG is still on the ground and RadALT is close to ground, will G still be true?
Next, it is common when data fusing multiple inputs that there is a desire to clean up a signal before it is sampled digitally. This can remove effects such as switch bounce. The inclusion of low pass filters or hysteresis will generally add a propogation delay.
Q3: Is there a slow filter (Tc>=1s) in the ground/air logic which could have caused a slight delay before G became false after takeoff further extending the opportunity of TMCA to activate?
Q4: Does TMCA act almost instantly or does it wait for the fault condition to stay asserted for a period of time before acting?
At that point, the total energy of the system would have comprised of the kinetic energy of the aircraft travelling at Vr, the rotational inertia of the engines and the potential energy of whatever fuel is beyond the cutoff valves.
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
It would still need a mechanism for at least one throttle input to each FADEC to misbehave at the same time. Resolvers are fed with an excitation signal to the rotor and take back two orthogonal signals (Cos and Sin) from stator windings. Usually, the excitation comes directly from the resolver-to-digital (R2D) circuit but sometimes an external signal source is used. I would hope that in an aircraft system, each channel would be kept independent of everything else.
Q6: Does the excitation signal for the 4 throttle resolvers (2 per side) come from 4 independent (internal) sources?
My last thought for a single point of failure between both throttles would be a short between two wires or connection points carrying resolver signals, one from each side. Whether this could be caused by swarf wearing within a wiring loom, a foreign object moving about, crushed wires or even stretching of adjacent wires, I have absolutely no idea.
Q7: Do resolver signals from left or right, either channel A or B, run next to each other in a loom at any point?
What happens when the 2 disparate processes that form TCMA disagree?
2025-06-20T11:04:00
permalink Post: 11906838
Let me try to answer the questions about which I have some knowledge, as an aerospace engineer:
(I am not sufficiently informed to answer Q4,6 and 7, at the moment)
Yes, overspeed on either resolver channel A or B alone will trip the TMCA fuel-cut logic
G is a single Boolean that FADEC derives from Weight-On-Wheels (MLG and NW) and radio-altimeter. Iit stays \x93ground\x94 until all WOW sensors go inactive (i.e.
every
wheel is off the runway) and the RadALT exceeds its airborne threshold.
That's very unlikely. Ground/air logic uses small hysteresis (tens to a few hundred ms), but not in the multi-second range
Let's do the math very quickly:
Kinetic energy with a weight of 200,000kg, at Vr = 150kn = 77m/s: E_kin = 600MJ
Rotational energy of a GEnX engine is hard to calculate as I don't find reliable values for the rotary inertia. I found some for a GE90 and could roughly estimate 100MJ of rotational energy for each engine. However, I seriously doubt that this energy could be effectively used to gain thrust, as the thrust will drop very quicjkly after the fuel is cut off.
the required potential energy for a 100ft climb of a 200,000kg 787 is around 70MJ.
This ignores aerodynamic drag, still, 100 ft of climb remains energetically feasible.
However, it as been pointed out several times that the actual climb was higher than 100ft. Already for 200ft I would doubt the validity of my statement above.
(I am not sufficiently informed to answer Q4,6 and 7, at the moment)
Q1: Am I correct in that assumption that when on the ground, overspeed with respect to EITHER resolver A OR resolver B can trigger TMCA?
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
We have been told that the logic (ie true or false) signal G is determined from the Weight-on-wheels sensors and the RadALT. It is reasonable to suppose that the designers still wanted TMCA to function after a hard landing where some landing gear components had failed.
At that point, the total energy of the system would have comprised of the kinetic energy of the aircraft travelling at Vr, the rotational inertia of the engines and the potential energy of whatever fuel is beyond the cutoff valves.
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
Q5: Would this total energy have been sufficient to get the aircraft 100ft into the air?
Kinetic energy with a weight of 200,000kg, at Vr = 150kn = 77m/s: E_kin = 600MJ
Rotational energy of a GEnX engine is hard to calculate as I don't find reliable values for the rotary inertia. I found some for a GE90 and could roughly estimate 100MJ of rotational energy for each engine. However, I seriously doubt that this energy could be effectively used to gain thrust, as the thrust will drop very quicjkly after the fuel is cut off.
the required potential energy for a 100ft climb of a 200,000kg 787 is around 70MJ.
This ignores aerodynamic drag, still, 100 ft of climb remains energetically feasible.
However, it as been pointed out several times that the actual climb was higher than 100ft. Already for 200ft I would doubt the validity of my statement above.
2 users liked this post.
2025-06-20T11:11:00
permalink Post: 11906846
Lead Balloon:
A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate far more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications.
Getting back to the point, if the TMCA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TMCA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where.
A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate far more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications.
Getting back to the point, if the TMCA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TMCA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where.
Last edited by syseng68k; 20th Jun 2025 at 13:35 . Reason: Spelling
1 user liked this post.
2025-06-20T11:21:00
permalink Post: 11906856
Lead Balloon:
A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It\x92s really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate for more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications.
Getting back to the point, if the TCMA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TCMA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where.
A bit of background on real time computing might help here. Apologies if some of this is tldr, obvious, or a simplification.. The FADEC must monitor the local environment, calculate and control, various aspects of engine operation. eg: baro pressure, temperature, fuel, speed control, overtemp, as well as respond to external commands (speed, start / stop etc) and provide operating status reports in real time, to other parts of the a/c. It\x92s really is a complex, semi autonomous system in it\x92s own right. In the old analog days, there might have been several individual hardware subsystems / black boxes, to do that, but since the advent of low cost reliable computing, more and more of that functionality has been delegated to software processes. Hardware function is abstracted into software space, a single black box replacing many. All those tasks that used separate hardware in the past, now run as individual software processes, at microsecond rate, sequentially. A sleight of hand making it appear as though there are separate computers, one for each item. Some critical tasks require microsecond response times, while others can wait seconds or longer. The way that is managed is by assigning a priority to each task, which ensures that all tasks have access to the processor as needed. Hence, the title, Real Time Systems. The task set shares processor, memory and other hardware, but there is great effort and process expended to encapsulate / isolate individual tasks, even though some of them will need to communicate with each other. Done right, that kind of system design can improve reliability due to far less hardware, and lowers cost and weight. However, it does concentrate for more design complexity into a much smaller abstract space, and needs a rigorous development process for safety critical applications.
Getting back to the point, if the TCMA function is resident on the FADEC, then it\x92s likely that it is just one software task of many running on a single set of FADEC hardware. Pretty opaque and no idea how we can begin to analyse that here. Iirc, tdracer said elsewhere that the various TCMA input qualifiers are handled by the airframe (?) , with a single yes / no input to the FADEC, but need to verify that. Really important to define what does what and where.
2 users liked this post.
2025-06-20T11:38:00
permalink Post: 11906873
We have an authoritative answer to that question, but only if the TCMA implemented in the FADEC used on the 787 engines functions in the way described in conceptual documents: If one of the two TCMA 'channels' for an engine 'thinks' the shut off criteria are satisfied but the other channel doesn't, the channel which 'thinks' the shut off criteria are satisfied 'wins' and the fuel shut off valve for that engine is therefore given a shut off signal.
4 users liked this post.
2025-06-20T11:50:00
permalink Post: 11906887
Engineer not a pilot. Experience in analog front ends, A2D and R2D conversion and embedded systems generally but no specific knowledge of the 787 or GEnx.
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a logic signal fron the aircraft that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
The logic would seem to be something of the form
If (G AND (N2>A OR N2>B)) Then CutOffFuel()
where G is true when the aircraft is on the ground,
A is an envelope defined by throttle resolver channel A and
B is an envelope defined by throttle resolver channel B
Step 2 being set throttle to zero.
As an engineers and not a pilot, it seems that momentarily setting throttle back to zero and back to full might be done to attempt to clear thrust problems, thus causing TMCA to shut down both engines.
Anyone know enough to say whether this is plausible?
2025-06-20T12:08:00
permalink Post: 11906904
We have an authoritative answer to that question, but only if the TCMA implemented in the FADEC used on the 787 engines functions in the way described in conceptual documents: If one of the two TCMA 'channels' for an engine 'thinks' the shut off criteria are satisfied but the other channel doesn't, the channel which 'thinks' the shut off criteria are satisfied 'wins' and the fuel shut off valve for that engine is therefore given a shut off signal.
Are these values recorded in the FDR?
Are values from the FADEC recorded?
2025-06-20T12:20:00
permalink Post: 11906917
And each FADEC is unique to the engine in which it is hosted. So whilst these may be "autonomous" they still rely on data external to the engine itself such as WoW and Rad Alt where they hold more "sway" than they do in the flight deck.
Are these values recorded in the FDR?
Are values from the FADEC recorded?
Are these values recorded in the FDR?
Are values from the FADEC recorded?
4 users liked this post.
2025-06-20T13:25:00
permalink Post: 11906973
TCMA
And each FADEC is unique to the engine in which it is hosted. So whilst these may be "autonomous" they still rely on data external to the engine itself such as WoW and Rad Alt where they hold more "sway" than they do in the flight deck.
Are these values recorded in the FDR?
Are values from the FADEC recorded?
Are these values recorded in the FDR?
Are values from the FADEC recorded?
I’d like to add a complimentary test to user989’s logic on TCMA faults.
Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll?
Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely.
They may be out there but you’d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with ‘aircraft on ground’ found during maintenance or engines not responding to thrust lever position and so on.
Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let’s confine this thread to fact based technical discussion and debate.
Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it.
3 users liked this post.
2025-06-20T13:45:00
permalink Post: 11906985
Thanks to tdracer's explanation on TMCA (albeit 747 not 787), we know that TMCA is a logic block within the FADEC whose only external inputs are a
logic signal from the aircraft
that indicates whether it is on the ground or not and throttle position as determined by two independent resolvers per throttle side.
Do we know this? If we do, I've missed it. And whether the FADECs receive signals independently from the sensors used to determine the air/ground state of the aircraft \x97 radio altimeters, WoW switches, something else I don't know about \x97 or receive a predetermined state or forwarded signals from another source is crucial to understanding possible failure conditions and the likelihood of simultaneous shutdown by TCMA in both engines. I think.
1 user liked this post.
2025-06-20T13:47:00
permalink Post: 11906986
Indeed, thanks to you for your most informative reply! Great to know we're much on the same page.
I'll strive for brevity here. [Fail, sorry!]
Aha! Very misleading by FR24! Maybe they can devise a way to show where data is missing.
Sorry, I got confused about this ^^^, when you wrote this:
but I'm assuming reliable within the 25ft granularity that the 787 creates, which mostly is neither here nor there, but in this case, not so helpful!
Yes, got it, but wasn't what I was meaning to ask, sorry. My bad. I'm about over this TMCA stuff because it sounds like it's Trade Secret so a lot of guesswork, but the question I was intending was:
If the TMCA did activate and shut off the fuel for whatever reason, what causes the TMCA/FADEC Hardware (and Software) to Reset, since it's independently powered off the engine-driven PMG after engine start? There is so much here that is just so unclear. I haven't seen anything about a Reset input anywhere, and since it's supposed to work only when on the ground, that's not really necessary, as the engine will eventually spool down. At some point before that, the PMG output voltage will go to low enough that the FADEC/TMCA should be forced into a Hardware Reset. That's all fine on the ground, but in the air, the engine will windmill, potentially until.... Is the PMG output fed through a switch/relay that cuts the FADEC/TMCA supply at low (i.e. windmill) RPM, so that a Pilot-activated Engine Off/On cycle can reconnect the Aircraft FADEC Supply link, thus Rebooting the FADEC so that it reopens the Fuel Shutoff valve(s)? It all seems so "awkward". And potentially fatal. Is this a scenario that the designers considered? (Who can answer that one?
)
Just now, I realise that if this is roughly what happens, then maybe the engines did commence a restart just before impact, due to the plane being deliberately mushed/stalled to the ground as softly as possible, thereby reducing the windmill RPM. And maybe the engines restarting interfered with that planned landing.
Or maybe I've got this all wrong. I'm hoping someone will tell us all.
Thankfully, Yes. Hope this Reply gets through too.
I'll strive for brevity here. [Fail, sorry!]
However, the datagrams that FR24 actually received were correct. They contain the GPS position of AI171 and its unadjusted barometric altitude, as determined by its onboard instruments. This data is as reliable as the instruments themselves are.
It's uncertain because the 787 rounds all altitudes it sends to the nearest multiple of 25. The altitudes sent were from 575 ft to 625 ft.,
The RAT deploying is a consequence of a dual engine shutdown. It says nothing about whether the TMCA was involved.
If the TMCA did activate and shut off the fuel for whatever reason, what causes the TMCA/FADEC Hardware (and Software) to Reset, since it's independently powered off the engine-driven PMG after engine start? There is so much here that is just so unclear. I haven't seen anything about a Reset input anywhere, and since it's supposed to work only when on the ground, that's not really necessary, as the engine will eventually spool down. At some point before that, the PMG output voltage will go to low enough that the FADEC/TMCA should be forced into a Hardware Reset. That's all fine on the ground, but in the air, the engine will windmill, potentially until.... Is the PMG output fed through a switch/relay that cuts the FADEC/TMCA supply at low (i.e. windmill) RPM, so that a Pilot-activated Engine Off/On cycle can reconnect the Aircraft FADEC Supply link, thus Rebooting the FADEC so that it reopens the Fuel Shutoff valve(s)? It all seems so "awkward". And potentially fatal. Is this a scenario that the designers considered? (Who can answer that one?
)
Just now, I realise that if this is roughly what happens, then maybe the engines did commence a restart just before impact, due to the plane being deliberately mushed/stalled to the ground as softly as possible, thereby reducing the windmill RPM. And maybe the engines restarting interfered with that planned landing.
Or maybe I've got this all wrong. I'm hoping someone will tell us all.
[Now I just hope your post is still there as I post this.
]
]
1 user liked this post.
2025-06-20T13:57:00
permalink Post: 11906991
The excellent #724 post by user989 really should be seen as the defining statement on what is currently known.
I\x92d like to add a complimentary test to user989\x92s logic on TCMA faults.
Regardless of whether the \x91aircraft on ground\x92 signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn\x92t TCMA activate during taxiing or the takeoff roll?
Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely.
They may be out there but you\x92d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with \x91aircraft on ground\x92 found during maintenance or engines not responding to thrust lever position and so on.
Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let\x92s confine this thread to fact based technical discussion and debate.
Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it.
I\x92d like to add a complimentary test to user989\x92s logic on TCMA faults.
Regardless of whether the \x91aircraft on ground\x92 signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn\x92t TCMA activate during taxiing or the takeoff roll?
Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely.
They may be out there but you\x92d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with \x91aircraft on ground\x92 found during maintenance or engines not responding to thrust lever position and so on.
Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let\x92s confine this thread to fact based technical discussion and debate.
Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it.
Also during this period, the Rad Alt may not have been giving useful values given its proximity to the ground
These two factors alone could increase the possibility of an error quite considerably.....
2 users liked this post.
2025-06-20T16:51:00
permalink Post: 11907131
... The generally held theory for each engine\x92s FADEC failure (due to a common software error related to a ground-air sensing failure) is not supported by the cumulative hours over many years without such a failure. So, if you then look around for another component that can shut down two engines simultaneously you end up with the fuel shut-off valves (FSOV). Why? On each engine It is fail-safed to close off fuel-feed flows by a spring that is held
open
by a solenoid. If that solenoid loses electrical power, the FSOV closes and the engine shuts down after a short period.
18 users liked this post.
2025-06-20T22:41:00
permalink Post: 11907374
The excellent #724 post by user989 really should be seen as the defining statement on what is currently known.
I’d like to add a complimentary test to user989’s logic on TCMA faults.
Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll?
Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely.
They may be out there but you’d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with ‘aircraft on ground’ found during maintenance or engines not responding to thrust lever position and so on.
Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let’s confine this thread to fact based technical discussion and debate.
Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it.
I’d like to add a complimentary test to user989’s logic on TCMA faults.
Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll?
Such a fault occurring spontaneously in just the few seconds after rotation is way way down the probability table. Such a fault occurring spontaneously on both separate (think ETOPS) engine control systems is surely vanishingly unlikely.
They may be out there but you’d have to ask if TCMA is implicated where are the lower consequence precursor events in the 787 fleet? These might be spurious TCMA action on one engine or faults with ‘aircraft on ground’ found during maintenance or engines not responding to thrust lever position and so on.
Change Analysis would ask what happened differently in the few seconds after rotation on this flight that separates it from all other 787 takeoffs and why at that particular time ?The interim report will provide some answers until then please let’s confine this thread to fact based technical discussion and debate.
Re-reading this I did briefly consider suggesting engine overshoot of thrust lever positions and FADEC shut down on N1 overspeed but that leaves a lot of WHY and WHY both engines questions so I dismissed it.
But I'd posit these points (without making any assertions about the probabilities of the scenarios).
There is a flaw in the logic arising from the categorical assertion that the 'aircraft on ground' signal 'would have been correct' during the take off roll: "Regardless of whether the ‘aircraft on ground’ signal was incorrect after rotation it would have been correct during the takeoff roll. IF there was an unrevealed fault in a thrust lever position signal THEN why didn’t TCMA activate during taxiing or the takeoff roll?"
What IF the 'aircraft on ground' signal into the TCMA systems was INcorrect during taxi and the take off roll, thus disabling the TCMA functionality during that phase of the flight, making no difference in any event because the engines were operating normally in accordance with the thrust lever settings? In that case, any error in, for example, the thrust lever signals and engine signals to the TCMAs would not have had any consequence. Maybe the signal reversed and stayed INcorrect after take-off. Of course, that's why we are all craving to find out from what source/s the TCMAs get the 'on ground/in air' input/s and what other systems use the same source/s.
And I reiterate the point that the TCMA is "just software". I haven't seen anyone dispute the suggestion that the thing 'common' to all 4 channels of the TCMA is 4 copies of software.
In the earlier thread there was a statement about the 'obsession' of some with TCMA. I'm not 'obsessed' with it, but confess a prejudice towards trying to find a cause that is not a result of crew error. I therefore also have an attraction towards fuel contamination, but have difficulty in believing that fuel contamination would result in such a 'clean', immediate and simultaneous reduction in thrust from both engines after they'd operated normally during the take off roll.
1 user liked this post.