Page Links: Index Page
OldnGrounded
2025-06-16T01:19:00 permalink Post: 11903028 |
The TCMA patent application is at:
https://patents.google.com/patent/US6704630B2/en
Quite a simple system (not) What gets your attention is the fact that you can continue to operate the aircraft without an MMEL entry when one of the two systems (per EEC) that shadow each other... is unserviceable. As it says: "Typically the aircraft is allowed to operate for a limited period of time with just a single operative processing subsystem." That 787 was not long out of maintenance. I note that, unless I missed it, the patent application doesn't address a mechanism for determining whether an aircraft is actually on the ground. I suppose that will depend on some of those "several other digital inputs."
Via the execution of software package
130
, each of the processing subsystems
20
a
and
20
b
monitors the position of thrust lever
36
, engine power level,
and several other digital inputs provided from the aircraft
via digital ARINC data buses
46
.
I'm still looking for identification of the relevant inputs for TCMA on the GEnx-1B. If anyone has suggestions, please share. |
Lead Balloon
2025-06-16T23:04:00 permalink Post: 11903859 |
I preface this post by acknowledging all the previous posts in this, and the now-closed thread, about the TCMA, in particular the excellent posts by tdracer. (Ditto the noise analyses by Kraftstoffvondesibel and First Principal.)
I also note that the primary source of the information on which I’m basing my post is the content of Boeing’s patent application which, of course, does not contain any of the actual wiring diagrams or modification details of the TCMA, even assuming it has been implemented. (I understand from the now-closed thread, that there is an unresolved question as to whether a petition for an exemption from the TCMA requirement had been successful.) The point of my post is to get other’s thoughts on one of the design principles of the TCMA system proposed in the patent application. The ostensibly simple and elegant concept is described in the schematic of the system at figure 1 of the patent application. A copy of figure 1 is below. The TCMA is the part of the schematic inside the dotted box numbered 16 , sitting with the EEC (others would call it the FADEC) in the solid box numbered 18 . The heart of the TCMA comprises two switch relays, numbered 22 and 28 in the schematic, wired in series. Each of those switch relays is controlled by its own, dedicated engine control malfunction software, identified as the blobs numbered 130 . (The patent application identifies component 34 as a dedicated processor and 32 as the diode connected to the switch relays, but that is evidently a mistake. Component 34 is the diode and I can’t find a component number 32 anywhere in the schematics.) Each relay switch and its controlling software is described as a ‘channel’, one A and one B. Both channels run continuously, monitoring throttle position (36 in the schematic) versus engine data fed from ARINC data bus lines (46 in the schematic) and “dedicated input sensors” not shown in the schematic. Those sensors presumably detect things like weight on wheels and perhaps RADALT. This design is said to achieve redundancy, because if only one ‘channel’ detects the engine is producing excessive thrust while the throttle is set to idle, that channel will set its switch relay to CUTOFF and that is enough to change the state of the high pressure fuel shut off valve (58 in the schematic). No more motion lotion. In the words of the patent application: Both channels are “always actively monitoring engine function and independently have the capability of shutting down the engine.” That arrangement wrinkled my crusty old avtech brow. In my mind – and this is why I’m seeking other’s thoughts – the advantage of redundancy arising from the two channels, either or both of which can shut the engine down, is not without risk. If it is possible for one of the channels to have some ‘glitch’ or hardware failure such that it does not detect an actual out of envelope condition justifying immediate shut down, with the other channel detecting the condition and shutting the engine down, it inexorably follows – does it not – that it is possible for one (or both) of the channels to have a ‘glitch’ or hardware failure that results in a shut down when there is no out of envelope condition? Further, even if there are completely separate, duplicated sensors telling each channel things like the position of the throttle and whether or not there is weight on wheels, there remains the possibility of a combination of sensor failures/disconnects resulting in one channel being ‘convinced’ that an out of envelope condition exists, with a consequential cutoff of fuel to the engine. I of course acknowledge the valid observations made about the remote probabilities of these kinds of glitches and failures. I’ve heard rumours that there was much resistance to the mandating of TCMA systems. Having seen many, many strange faults caused by random shorts, open circuits, liquid ingress and other foreign objects, I can understand why there was that resistance. Every time you add something to a system and that added thing has electronic components and software and electrical connections and data inputs, you add risk of that thing malfunctioning or working perfectly but with erroneous inputs. In this case, there are effectively two added new things: two channels, each one of which has the ability to shut off the motion lotion to the engine to which they are strapped. I make no comment on whether TCMA systems, if fitted, have anything to do with this tragedy. My profound condolences to the families and friends of those killed or injured. My thoughts also go out to the many people who will be agonising over the potential causes and responsibility for it. And thanks to those who are working out the causes. ... ![]() 7 users liked this post. |
EDML
2025-06-17T10:13:00 permalink Post: 11904168 |
Not an avionics specialist, but electronics / software engineer here, with extensive experience in hardware fault tracking, protocol monitoring and software debugging in embedded systems : mods, feel free to delete this post if I am completely out of track (and thank you for the huge amount of work you've done trying to keep this discussion clean).
After I have read the whole thread, I think most of the community agrees about a lack of engine thrust being the cause of the crash. Searching in that direction, I'm trying to "think out of the box", discarding the usual suspects (birds ingestion, TCMA, human mistake...), and to find a plausible single point of failure among the various subsystems involved. I was thinking of reversing the causality of the event, i.e. exploring a case where the engines would have behaved unexpectedly because of a major electrical failure, instead of the already explored case where both powerplants went AWOL first. Therefore, I have a couple questions for tdracer / fdr / other informed contributors (BTW, fantastic contribution guys, please keep the good info coming): 1. From the scarce info available, is it reasonable to conclude that the engines were totally shut down? Could they have just been set to idle or reduced thrust instead? 2. In the second case, if (and that's a big IF) a major electrical failure happened first (which could have triggered RAT deployment), and considering this plane is a FBW aircraft, could there exist a case where the FADECs would command idle thrust -- or significant thrust reduction -- because they receive invalid input data from the throttle controls? Kind of a garbage in-garbage out case? The associated scenario would be: major electrical fault (with subsequent RAT deployment) -> major protocol disturbance on ARINC/AFDX buses -> FADECs detect invalid data from the controls -> FADECS enter some kinf of safe mode and command reduced or idle thrust. Does it make sense or is it pure fantasy? 1 user liked this post. |
syseng68k
2025-06-17T10:21:00 permalink Post: 11904174 |
EDML: "No. The throttle position sensors (dual per engine) are part of the FADEC. The throttle position data is not transmitted through the ARINC busses of the aircraft".
To clarify, you are saying that the throttle position sensors are wired directly to the FADEC, and nothng else ?. 1 user liked this post. |
Lead Balloon
2025-06-17T11:18:00 permalink Post: 11904217 |
Thanks for that,
Luc Lion
.
What are the probabilities of a crew member spilling a cup of coffee over the centre console, causing a current path between the instrument lighting buss and the trim up command wire from the control column trim thumbswitch and the ARINC connector to the FMS controller, and what will the effects of those current paths be ? (It is for this reason, among others, that 'fluid spill' protection has been built into some instrument consoles.) It's the second bit - the almost completely unpredictable range of effects - that presents the more substantial challenge. Last edited by Lead Balloon; 17th Jun 2025 at 11:29 . 1 user liked this post. |
EDML
2025-06-17T11:26:00 permalink Post: 11904222 |
EDML: "No. The throttle position sensors (dual per engine) are part of the FADEC. The throttle position data is not transmitted through the ARINC busses of the aircraft".
To clarify, you are saying that the throttle position sensors are wired directly to the FADEC, and nothng else ?. 1 user liked this post. |
JPI33600
2025-06-17T14:52:00 permalink Post: 11904368 |
EDML: "No. The throttle position sensors (dual per engine) are part of the FADEC. The throttle position data is not transmitted through the ARINC busses of the aircraft".
To clarify, you are saying that the throttle position sensors are wired directly to the FADEC, and nothng else ?.
The thrust lever inputs are hardwired (resolvers connected to the thrust levers, powered by the FADEC), other aircraft communications on the 787 are on an ethernet based network.
|
Someone Somewhere
2025-06-18T13:08:00 permalink Post: 11905228 |
I (and I think everyone else here) have been assuming that the FADEC does in fact have a dedicated permanent-magnet alternator, as is the case on the Airbuses (confirmed by FCOM) and surely the 737.
I have been told elsewhere that this is not the case. A read of the draft FCOM available online for the 777 & 787 makes no mention of a FADEC generator, but then neither does the 737 manuals. Is this simply a case of "Boeing thinks you don't need to know"? It has been proposed that the primary source of power for the FADECs is actually the flight control PMGs, mounted on the engine gearbox, but that this power goes to the avionics bay, has failover switching gear, and comes back to the EEC. Can anyone shed concrete light on this (e.g. a source that clearly states there is both an EEC alternator and a flight control PMG on the accessory gearbox)? Alternator and generator seem to be used interchangeably in this context. I don't think you'll find an actual wire list for it (or it won't be useful) as apparently most/all of the data is via an ARINC bus. I attempted to PM this but your inbox is full. [SLF with an electrical background and some exposure to ground-side critical facilities power] Last edited by Someone Somewhere; 18th Jun 2025 at 13:32 . 1 user liked this post. |
212man
2025-06-18T13:22:00 permalink Post: 11905242 |
I (and I think everyone else here) have been assuming that the FADEC does in fact have a dedicated permanent-magnet alternator, as is the case on the Airbuses (confirmed by FCOM) and surely the 737.
I have been told elsewhere that this is not the case. A read of the draft FCOM available online for the 777 & 787 makes no mention of a FADEC generator, but then neither does the 737 manuals. Is this simply a case of "Boeing thinks you don't need to know"? It has been proposed that the primary source of power for the FADECs is actually the flight control PMGs, mounted on the engine gearbox, but that this power goes to the avionics bay, has failover switching gear, and comes back to the EEC. Can anyone shed concrete light on this (e.g. a source that clearly states there is both an EEC alternator and a flight control PMG on the accessory gearbox)? Alternator and generator seem to be used interchangeably in this context. It's not quite that, but there is a list of received channels for a GEnx 787 in the FDR report into one of the original battery fires . I don't think you'll find an actual wire list for it (or it won't be useful) as apparently most/all of the data is via an ARINC bus. I attempted to PM this but your inbox is full. [SLF with an electrical background and some exposure to ground-side critical facilities power]
(h) Aircraft Supplied Electrical Power.
(1) The Engine Control System must be designed so that the loss or interruption of electrical power supplied from the aircraft to the Engine Control System will not - (i) Result in a Hazardous Engine Effect, (ii) Cause the unacceptable transmission of erroneous data. The effect of the loss or interruption of aircraft supplied electrical power must be taken into account in complying with CS-E 50(c)(1). |
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. |
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 . 4 users liked this post. |
EXDAC
2025-06-28T15:54:00 permalink Post: 11912544 |
It's not clear to me that 787 EAFR even requires an external DFDAU. The GE EAFR does not - "Provides Flight Data Acquisition function of ARINC 664 p7 data parameters – No need for a Digital Flight Data Acquisition Unit (DFDAU)." ref https://www.geaerospace.com/sites/de...rder-3254F.pdf 1 user liked this post. |
Innaflap
2025-06-30T14:42:00 permalink Post: 11913673 |
I am not aware of any requirement for a DFDAU (or equivalent) to store any data. I say "or equivalent" because in B717 the DFDAU is not an LRU. It is a functional partition of the VIA.
It's not clear to me that 787 EAFR even requires an external DFDAU. The GE EAFR does not - "Provides Flight Data Acquisition function of ARINC 664 p7 data parameters \x96 No need for a Digital Flight Data Acquisition Unit (DFDAU)." ref https://www.geaerospace.com/sites/de...rder-3254F.pdf |
Page Links: Index Page