Page Links: First Previous 1 2 Last Index Page
Lead Balloon
2025-06-19T03:13:00 permalink Post: 11905692 |
Thanks
Capn Bloggs
and
BuzzBox
. My apologies
Shep69
. I'm recalibrated re the minimum autopilot engagement height.
Subjects: None |
Lead Balloon
2025-06-19T12:45:00 permalink Post: 11905991 |
The discussion about the fuel control switch design is interesting so far as it goes, but I'm more interested in the physical arrangements under the bracket to which they're fitted and the associated connection and wiring arrangements. No doubt the arrangements are designed so as to reduce to 'vanishingly small' the probabilities of any common shorts to the wrong places, but who knows, for sure, how the switches and connections and wiring were installed in the accident aircraft, or whether there was a piece of swarf or other FOD that ended up somewhere that it should not have been (i.e. anywhere on the aircraft) during manufacture or maintenance.
Subjects: Fuel (All) Fuel Cutoff 3 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 . Subjects: Fuel (All) Fuel Cutoff Parameters TCMA (Activation) TCMA (All) 3 users liked this post. |
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. Subjects: FADEC Fuel (All) Fuel Cutoff TCMA (All) 2 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.
Subjects: FADEC TCMA (All) 1 user 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. Subjects: ARINC Engine Failure (All) FADEC TCMA (All) TCMA (Shutdown) 2 users liked this post. |
Lead Balloon
2025-06-20T11:17:00 permalink Post: 11906849 |
I have read through all the first thread and much of the second before commenting; SLF here, albeit with a lot of flights in a lot of commercial, emergency and non-commercial aircraft but with a relevant background and expertise in collision reconstruction and looking for holes in Swiss Cheese.
.... One of the engineering experts has noted that a specific engine control circuit board must be powered down every 51 days or can cause problems, and even more so at 249 days when it has the capacity to cut both engines simultaneously. ... Subjects: Dual Engine Failure Engine Failure (All) Generators/Alternators |
Lead Balloon
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. Subjects: FADEC TCMA (Activation) TCMA (All) 2 users liked this post. |
Lead Balloon
2025-06-20T11:27:00 permalink Post: 11906863 |
Looking at the GE Aerospace website they appear to offer a remote monitoring service;
If this was on AI 171 presumably they would already know what happened. https://www.geaerospace.com/commerci...ital-solutions Recall that the various search 'arcs' for MH370 were calculated on the basis of attempts by the engine monitoring systems to transmit data via satellite. The system involved did not transmit the data continuously. Maybe that's changed, but if it has not, I wonder how often any data would have been transmitted after the engines started on the (very) short AI 171 flight. Subjects: None 3 users liked this post. |
Lead Balloon
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.
Subjects: FADEC Fuel (All) Fuel Cutoff TCMA (All) 4 users liked this post. |
Lead Balloon
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? 4 users liked this post. |
Lead Balloon
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. 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. Subjects: FADEC Fuel (All) Fuel Contamination TCMA (All) Takeoff Roll 1 user liked this post. |
Lead Balloon
2025-06-21T13:25:00 permalink Post: 11907749 |
The gear tilt position is not definitive evidence crew had selected gear up. I've speculated another cause for this non-normal gear tilt is that C hydraulics failed around time of rotation. This would explain the gear remaining in the forward tilt position. There are reasons why the crew may have not selected gear up,
see earlier post.
Therefore we cannot determine wow or air/ground logic from an assumed gear retraction.
First, whilst it may be that every system that monitors and makes decisions about whether the aircraft is 'in the air' does so on the basis of exactly the same sensor inputs, that may not be true and I'd appreciate someone with the expert knowledge on the 78 to confirm or refute the correctness of the assumption, particularly in relation to, for example, FADEC functions compared with undercarriage control functions. Secondly and probably more importantly, what happens if one of the sensors being used to determine 'in air' versus 'on ground' gives an erroneous 'on ground' signal after - maybe just seconds after - every one of those sensors has given the 'in air' signal? Reference was made earlier in this thread to a 'latched' in air FADEC condition that resulted in engine shut downs after the aircraft involved landed and was therefore actually on the ground. But what if some sensor failure had resulted in the aircraft systems believing that the aircraft was now on the ground when it was not? I also note that after the 2009 B737-800 incident at Schiphol – actually 1.5 kms away, where the aircraft crashed in a field during approach - the investigation ascertained that a RADALT system suddenly sent an erroneous minus 8’ height reading to the automatic throttle control system. The conceptual description of the TCMA says that the channels monitor the “position of thrust lever” – no surprises there – “engine power level” – no surprises there – and “several other digital inputs via digital ARINC data buses”. WoW should of course be one of those "digital inputs" and be a 1 or 0. But I haven't seen any authoritative post about whether the change in state on the 78 requires only one sensor to signal WoW or if, as is more likely, there are (at least) two sensors – one on each MLG leg – both of which have to be ‘weight off’ before a weight off wheels state signal is sent. Maybe a sensor on each leg sends inputs to the ARINC data and the systems reading the data decide what to do about the different WoW signals, as between 00, 01, 10 and 11. There is authoritative information to the effect that RADALT is also one of the “digital inputs” to the TCMA. The RADALTs presumably output height data (that is of course variable with height) and I don’t know whether the RADALT hardware involved has a separate 1 or 0 output that says that, so far as the RADALT is concerned, the aircraft to which it is strapped is, in fact, ‘in the air’ at ‘some’ height, with the actual height being so high as to be irrelevant to the systems using that input (if that input is in fact generated and there are, in fact, systems that use that 1 or 0). If we now consider the ‘worst case scenario will be preferred’ concept that apparently applies to the TCMA design so as to achieve redundancy, the number of sensor inputs it’s monitoring to decide whether, and can change its decision whether, the aircraft is on the ground, becomes a very important matter. The TCMA is only supposed to save the day on the ground, if the pilots select idle thrust on a rejected take off but one or both of the engines fail to respond. In the ‘worst case’ (in my view) scenario, both TCMA channels on both engines will be monitoring/affected by every WoW sensor output and every RADALT output data and, if any one of them says ‘on ground’, that will result in both engines’ TCMAs being enabled to command fuel shut off, even though the aircraft may, in fact, be in the air. Of course it’s true that the TCMA’s being enabled is not, of itself, sufficient to cause fuel cut off to an engine. That depends on a further glitch or failure in the system or software monitoring engine power and thrust lever position, or an actual ‘too much thrust compared to thrust lever position’ situation. But I can’t see why, on balance, it’s prudent to increase the albeit extraordinarily remote risk of an ‘in air’ TCMA commanded engine or double engine shut down due to multiple sensor failure – just one in-air / on-ground sensor and one of either the thrust lever sensor/s or engine power sensor/s – or, in the case of an actual in air ‘too much thrust compared to thrust lever position situation’, why that ‘problem’ could not be handled by the crew shutting down the engine when the crew decides it’s necessary. Once in the air, too much thrust than desired is a much better problem to have than no thrust. The latter is precisely what would happen if all ‘on ground / in air’ sensors were functioning properly and some ‘too much thrust’ condition occurred. Hopefully the design processes, and particularly the DO-178B/C software design processes done by people with much bigger brains than mine, have built in enough sanity checking and error checking into the system, followed by exhaustive testing, so as to render my thoughts on the subject academic. Last edited by Lead Balloon; 21st Jun 2025 at 14:02 . Subjects: ARINC FADEC Fuel (All) Fuel Cutoff Gear Retraction MLG (All) MLG Tilt TCMA (Air-ground Logic) TCMA (All) 4 users liked this post. |
Lead Balloon
2025-06-21T23:27:00 permalink Post: 11908149 |
Let us assume a simple, hypothetical WoW sensor arrangement: One sensor per main landing gear. One of those sensors is indicating weight OFF wheels and the other is indicating weight ON wheels. What does the TCMA in each engine interpret that ostensibly contradictory sensor information to mean? (Note: For the time being, ignore the question whether the information is erroneous. It may be true.) Are both engine TCMA's in the 'in the air' state, are both 'on the ground', or is one 'on the ground' and the other 'in the air'? Given the purpose of the TCMA, I would have thought that any 'doubt' in this case would be resolved in favour of the 'on ground' state for both TCMAs. But maybe it's the other way around. Maybe any 'doubt' would be resolved in favour of both TCMA's being in the 'in the air' state. I have difficulty in envisaging any advantage in the TCMA system being designed such that one engine's TCMA is in the 'in the air' state and the engine's 'on the ground'. Whichever the design and outcome, there will be benefits and there will be risks. Subjects: Gear Retraction TCMA (All) 3 users liked this post. |
Lead Balloon
2025-06-22T00:29:00 permalink Post: 11908185 |
This was already addressed in one of tdracer's posts about the TCMA system: the air/ground decision is made by the aircraft itself (using multiple redundant inputs and voting logic), and only a single air/ground binary state is provided to the EEC(FADEC). Further, he also stated that the EEC assumes "air", as that is the safer state given the nature of its operations.
Based on this, both engines will get the same air/ground indication from the aircraft and hence will always make the same TCMA decisions (subject to their individual throttle positions and thrust outputs). I will suggest some amendments to your last sentence, though: Based on this, both engines Let's not lose sight of the fact that a 787 has had a TCMA 'commanded' double engine shut down, luckily only during the landing roll. That double shut down was not in circumstances of a rejected take-off where one or both engines delivered 'too much' thrust despite thrust levers being set to idle or 'low power'. Some might say incredible. But it's fact. The best designed systems and software sometimes do strange, unexpected things even when everything is working 'properly', and even stranger things when some defect or damage occurs. Subjects: TCMA (Air-ground Logic) TCMA (All) 2 users liked this post. |
Lead Balloon
2025-06-22T04:12:00 permalink Post: 11908275 |
Yes, all true. And I didn't think your earlier post was incredible, just that it was an exercise not intended to explain
everything
about air/ground logic. I think that, in the real world, it's most likely that the air/ground decision will take inputs from other sensors, not just WoW. Radio altimeters seem the most likely choice and we've been told they've been used on earlier Boeings (which I think I already knew or assumed). I'd certainly feel safer with that arrangement.
Subjects: TCMA (Air-ground Logic) TCMA (All) 2 users liked this post. |