Page Links: First Previous 2 3 4 5 6 7 8 9 10 11 12 13 14 Next Last Index Page
| EDML
2025-06-19T22:39:00 permalink Post: 11906453 |
Even if it's possible - there is not enough time to do so in this phase of the flight. Doing a full restart of one engine will take 1-2min. That means it will need a couple thousand feet.
2 users liked this post. |
| neila83
2025-06-19T22:43:00 permalink Post: 11906457 |
You may be surprised to learn that aircraft sometimes need full thrust on the ground.
TCMA requires that the pilot pulls the thrust levers back to idle, and that the engine fails to spool down to idle as commanded. Only then will it shut off the engine (on the ground). Pilots try to avoid pulling the thrust levers back to idle when they're taking off. For that reason, TCMA has never triggered during take-off before. 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. 4 users liked this post. |
| ams6110
2025-06-19T23:04:00 permalink Post: 11906466 |
I also wonder about this theory that one of the pilots called for reject and pulled the thrust levers back, and the other overruled him and continued the takeoff. Is this plausible? CRM aside, if max braking and spoilers are triggered in this scenario, it doesn't seem so to me. Last edited by ams6110; 19th Jun 2025 at 23:15 . Reason: typo correction |
| user989
2025-06-19T23:26:00 permalink Post: 11906480 |
Summary of main theories
DISCLAIMER: Poster (a) is one of the (apparently quite numerous) lawyers following this thread; (b) a long-time forum lurker and aviation enthusiast who loves studying FCOMs for fun (to each his own, I guess); (c) has followed and read this thread from the start.
What I cannot do is add new theories or uncover any new facts the actual experts have not already thought of. However, since summarizing and structuring information is one thing lawyers tend to regularly do (and sometimes even do well), here is my attempt at a useful contribution to this thread: an attempt to summarize the main theories discussed here since day one (which I think hasn't been done for quite some time) in the hope that a birds-eye view will be helpful to those who have not read everything since the beginning or might even trigger some new flash of inspiration for someone more knowledgable than me. I have focused on the cons since there does not seem to be enough evidence to come to any positive conclusion. I shall try to be concise and to refrain from personal evaluations of my own. Of course, no disrespect whatsoever is intended towards all those who have contributed to this thread and to the individual theories, one or combinations of which may turn out to have led to this tragic outcome. That arguments can be made against every single theory that has been propagated seems to be the result of the highly improbable and unusual nature of this deplorable event and certainly not due to any lack of knowledge or reasoning skills in this forum. DEAR MODS: If I have distorted anything or if, meaning well, should have achieved the opposite \x96 I guess you know where the delete button is\x85 Anyway, here goes: A. Misconfiguration or wrong takeoff data Widely refuted, since
Still brought up from time to time. However, widely disregarded due to
It should be pointed out that the question of "RAT in or out" was for a while the most contentious in this thread. C. Low-altitude capture Still argued, even if refuted by many since
Various possible reasons for this have been discussed: I. Bird strike/FOD
1. Loss of electric fuel pumps
Suction feed would have provided sufficient fuel pressure.
2. Fuel contamination
No other aircraft affected, no measures taken at airport. Simultaneous flameout due to contaminated fuel very unlikely.
3. Vapour lock
Unlikely to occur in this scenario. Even if (momentarily) no sufficient fuel pressure from the center tank, the engines would have been fed by the wing tanks.
III. Improper maintenance
Unclear which maintenance measures could possibly have been performed that would have resulted in simultaneous loss of both engines. No apparent relationships between malfunctions reported by previous passengers and essential systems. IV. Large-scale electrical fault (e.g. due to water in E&E bay) The engines will continue to run if electrical power is lost. FADECs are powered independently. V. Shutdown of engines by TCMA A parallel is drawn to the ANA incident. However, this would require not only a fault in the air/ground logic but also a sensed discrepancy between T/L position (not necessarily idle) and thrust output on both engines simultaneously. VI. (Inadvertent) shutdown by flight crew
1. Spontaneous execution of memory items (fuel control switches OFF, then ON; deploy RAT) due to assumed engine malfunction
In contrast to mistakenly shutting down the wrong engine after having correctly diagnosed the problem as per SOP, this would require not only a simple error in execution but a counter-intuitive unilateral action immediately after takeoff against basic principles of SOP or CRM.
2. No indications whatsoever of an intentional shutdown for nefarious reasons
(Would also be inconsistent with the content of the alleged mayday call.)
VII.
Malfunction/mishandling of the fuel cutoff switches (most recent)
1.
Wear or improper operation of the switches, so that they do not lock but can shift back into the OFF position.
Argued to be impossible due to robust switch design, preventing switch release in any other than a locked position.
Actuation of the switches by an item placed before them which was pushed onto the switches by retarding thrust levers seems equally unlikely due to force required to pull the switches out of the locked position.
2.
Spilled drink leading to short in the wiring
Hardly conceivable that before takeoff open liquid containers would be placed anywhere where they could spill onto the pedestal.
29 users liked this post. |
| skwdenyer
2025-06-20T00:36:00 permalink Post: 11906509 |
A good round-up of dominant themes, including this:
We know there has been a bug in the Generator Control Unit software (an overflowing counter) that could lead to simultaneous shut down of all generators and a total loss of all AC power (the 248 days bug). In the interests of completeness, we should perhaps also consider the possibility of some other previously-unknown software issue capable of creating an uncommanded dual engine shutdown. TCMS is the most likely candidate due to the deliberate separation of other systems from being able to achieve this outcome. The question then isn't whether there's some odd combination of input faults that would confuse TCMS into believing it were on the ground, but rather whether there's any way in which the software side could crash in such a way as to create an anomalous state within the system leading to engine failure. For instance, another overlooked software counter with an unwelcome failure mode. Or even just a "dirty power supply" (cf all the reports of dodgy passenger-side electrics on this a/c) leading to spurious inputs and unexpected consequences. Whatever is the cause will likely turn out to be have been a very low-probability event. But unless we have a TCMS expert who can state canonically that (say) the WoW sensor electrically disables TCMS when airborne (as opposed to merely being an input to the TCMS logic) then we cannot say with certainty that multiple inputs would have to have failed / been corrupted in order to reach the end state of this flight. 4 users liked this post. |
| Lead Balloon
2025-06-20T00:49:00 permalink Post: 11906514 |
SLF but I think this makes sense. If pulling from takeoff thust back to idle with WoW would cause TCMA activation, we'd see engine shutdowns on every rejected takeoff.
I also wonder about this theory that one of the pilots called for reject and pulled the thrust levers back, and the other overruled him and continued the takeoff. Is this plausible? CRM aside, if max braking and spoilers are triggered in this scenario, it doesn't seem so to me. Last edited by Lead Balloon; 20th Jun 2025 at 00:59 . 3 users liked this post. |
| ignorantAndroid
2025-06-20T01:22:00 permalink Post: 11906524 |
In the interests of completeness, we should perhaps also consider the possibility of some other previously-unknown software issue capable of creating an uncommanded dual engine shutdown. TCMS is the most likely candidate due to the deliberate separation of other systems from being able to achieve this outcome. The question then isn't whether there's some odd combination of input faults that would confuse TCMS into believing it were on the ground, but rather whether there's any way in which the software side could crash in such a way as to create an anomalous state within the system leading to engine failure. For instance, another overlooked software counter with an unwelcome failure mode. Whatever is the cause will likely turn out to be have been a very low-probability event. But unless we have a TCMS expert who can state canonically that (say) the WoW sensor electrically disables TCMS when airborne (as opposed to merely being an input to the TCMS logic) then we cannot say with certainty that multiple inputs would have to have failed / been corrupted in order to reach the end state of this flight. 3 users liked this post. |
| bbofh
2025-06-20T02:27:00 permalink Post: 11906541 |
Not necessarily "Groundless"??
- at Minus 8 feet (A Significant Disservice to the TCMA's G/A sensing?)
https://asn.flightsafety.org/reports...738_TC-JGE.pdf The radio altimeter During the approach, the left radio altimeter system indicated -8 feet , although the aircraft was at a considerably greater height than that. The Board\x92s investigation has not uncovered a reason for this change in the radio height to -8 feet. A Boeing 737-800 (flight TK1951) operated by Turkish Airlines was flying from Istanbul Atat\xfcrk Airport in Turkey to Amsterdam Schiphol Airport, on 25 February 2009. As this was a \x91Line Flight Under Supervision\x92, there were three crew members in the cockpit, namely the captain, who was also acting as instructor, the first officer who had to gain experience on the route of the flight and who was accordingly flying under supervision, and a safety pilot who was observing the flight. There were also four cabin crew members and 128 passengers on board. During the approach to runway 18 Right (18R) at Schiphol airport, the aircraft crashed into a field at a distance of about 1.5 kilometres from the threshold of the runway. This accident cost the lives of four crew members, including the three pilots, and five passengers, with a further three crew members and 117 passengers sustaining injuries. Shortly after the accident, the initial investigation results indicated that the left radio altimeter system had passed on an erroneous altitude reading of -8 feet to the automatic throttle control system (the auto-throttle). In response to this, the Board had a warning sent to Boeing on 4 March 2009. This asked for extra attention to be paid to the \x91Dispatch Deviation Guide\x92 for the Boeing 737-800, which is a manual of additional procedures and warnings for maintenance crews and pilots to consult before the aircraft is flown. This warning, which was added in 2004, states that with radio altimeter(s) inoperative, the associated autopilot or auto-throttle must not be used for the approach and landing...... More GRIST for the electric 787's software Glitch-Mill? (see my prior post above) Not really "INOP" if it's feeding in -8 feet? For those unfamiliar with this accident, the RADALT flaw caused the auto-throttle to enter its "flare/retard" mode quite early in the approach and the aircraft stalled into a field well short. I am not sure how one could extrapolate this into a post-take-off TCMA equivalent Ground/Air misadventure. Radar altimeters have considerable authority when it comes to CAT 3 ILS ops. It has an interface with the EEC, but to what extent? 2 users liked this post. |
| skiingman
2025-06-20T03:37:00 permalink Post: 11906561 |
- at Minus 8 feet (A Significant Disservice to the TCMA's G/A sensing?)
https://asn.flightsafety.org/reports...738_TC-JGE.pdf More GRIST for the electric 787's software Glitch-Mill? (see my prior post above) Not really "INOP" if it's feeding in -8 feet? For those unfamiliar with this accident, the RADALT flaw caused the auto-throttle to enter its "flare/retard" mode quite early in the approach and the aircraft stalled into a field well short. I am not sure how one could extrapolate this into a post-take-off TCMA equivalent Ground/Air misadventure. Radar altimeters have considerable authority when it comes to CAT 3 ILS ops. It has an interface with the EEC, but to what extent? The entire autoflight, autothrottle, and radio altimeter scheme for the 787 was developed many decades after the system at play in that 737 incident, and I expect that modern rules on hazards and misleading information would not allow a system as described in that report to be certified in the 787 era. There are many faults in RA systems that can result in incorrectly low altitude displayed. The report for example discusses antenna corrosion. RA LRUs going all the way back to the 1960s had several internal monitors that would drive "flag" and "autoflight enable" output discretes, but a loss of antenna isolation could sometimes result in a "locked" low altitude indication without a fault detected. In that era of federated avionics, aircraft equipped with dual RAs usually also had a separate comparator box that would compare the outputs and alert the crew if the values diverged - even if the RA LRU hadn't "flagged" the indicator. I am surprised that comparator output wasn't checked by the autothrottle system. I am curious if anyone knows the backstory on the 787 being equipped with two RA systems vs three on previous Boeing widebody models. |
| Lead Balloon
2025-06-20T03:41:00 permalink Post: 11906563 |
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. 2 users liked this post. |
| Someone Somewhere
2025-06-20T04:18:00 permalink Post: 11906574 |
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?
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. It uses existing thrust-lever-angle inputs, existing N1 inputs, and (presumably) existing WoW inputs, does software stuff inside the ECU, and if necessary uses the existing overspeed cutout outputs to stop the engine. 3 users liked this post. |
| Lead Balloon
2025-06-20T04:31:00 permalink Post: 11906582 |
That is interesting. I'll wait for ignorantA's or tdracer's confirmation (though not suggesting you are wrong, Someone Somewhere). The 'bottom line' would nonetheless seem to remain that the TCMA software, at least, is common to both TCMA 'channels' in the FADEC on both of the engines. Not one piece of software, but presumably two (or four?) identical copies of the same software. Of course, given the stringency of the DO-170B and C software development process and the brains that work on this stuff, the probabilities of the TCMA software directing a shutdown when the conditions for it do not exist are extraordinarily remote.
1 user liked this post. |
| ignorantAndroid
2025-06-20T04:57:00 permalink Post: 11906593 |
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?
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.
That is the implication I have heard all along, particularly from tdracer's posts.
It uses existing thrust-lever-angle inputs, existing N1 inputs, and (presumably) existing WoW inputs, does software stuff inside the ECU, and if necessary uses the existing overspeed cutout outputs to stop the engine. 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. 4 users liked this post. |
| Musician
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. 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. |
| Lead Balloon
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. 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. |
| skwdenyer
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. |
| Furr
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? 1 user liked this post. |
| ignorantAndroid
2025-06-20T08:53:00 permalink Post: 11906736 |
Categories 1 and 2 would be common to both engines, so they both remain plausible. For category 2, it would be impossible to identify the issue without analyzing the complete source code. Since we don't have access to that code, this is a dead end. It could be the cause, but we won't be able to figure it out. Looking at how the FADECs are designed to work isn't going to be very useful here, since by definition, they'd be doing something they weren't supposed to. Category 1 is a bit different. There are 2 functions we know of that can close the fuel shutoff valve: TCMA and N2 overspeed protection. We don't have the complete specifications, but the basic logic of both functions has been described. If we assume that one of these was the cause, then the conditions for one of those functions must have been met. The conditions for TCMA, at least as it's been described in this thread, are:
As for the overspeed protection, as far as I know, there's only one condition: N2 greater than a certain value. That reading comes from sensors that are inside each engine and wired directly to the FADECs. I don't see any way this could affect both engines simultaneously either, but it still seems a bit more likely than something involving TCMA since it only requires 2 separate, simultaneous failures rather than 3 or more. For the sake of accuracy, I should also note that not everything fits neatly into one of my 3 categories. For example, let's say we have a machine that's programmed to shut down if any one of 3 parameters goes above a certain value. If one of those values gets corrupted by a faulty memory chip, the machine could shut down unnecessarily. If we add more parameters to the list, the probability of an inadvertent shutdown increases since there are more critical areas in memory. As another example, consider a case where corruption of the CPU's program counter causes it to inadvertently jump to a particular subroutine. If we add more subroutines that can trigger a shutdown, we make the machine more vulnerable, albeit to a very small degree. Changes like these are sometimes referred to as "increasing the surface area." Due to those types of scenario, I will admit that the existence of something like TCMA probably makes an engine ever-so-slightly more likely to fail. Whether the benefit is worth the cost could be debated. In any case, I still find it pretty unlikely that any of this will turn out to have been a factor in this accident. Last edited by ignorantAndroid; 20th Jun 2025 at 09:11 . 9 users liked this post. |
| Someone Somewhere
2025-06-20T09:07:00 permalink Post: 11906746 |
In general, we can classify computer errors into 3 categories:
I am slightly surprised that they went for a contour-type design rather than more of a "thrust lever below 5% for >2 seconds, N1 above 50%" type check, if the concern is solely around RTO/landing. 1 user liked this post. |
| Innaflap
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? What happens when the 2 disparate processes that form TCMA disagree? |
Page Links: First Previous 2 3 4 5 6 7 8 9 10 11 12 13 14 Next Last Index Page