Posts about: "TCMA (All)" [Posts: 279 Pages: 14]

Very grateful for that background. Your last sentence is an excellent SITREP!

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.

I perfectly understand that there is much talking about TCMA here.
There is no direct evidence of what caused the crash but several indirect evidences point towards a near simultaneous shutdown of both engines without any visual clue of a catastrophic mechanical mishap. This leads to suspecting near simultaneous fuel starvation of both engines.
As the purpose of TCMA is shutting down the High Pressure Shut-Off Valve (HPSOV) and thus the fuel feed of an engine, it's normal to collect information on TCMA, on how it works, and on what data feeds it.

However, I hardly understand why there is no similar discussion about the spar valves and the systems that control their opening and closure.

I understand that the B787 spar valves are located in the MLG well, or at least are maintained from within that well.
If the engine shutdown happened when the gear retraction was commanded, that's a location commonality (although it's very unlikely that a mechanical problem happened in both wells at the same time).
Also I understand that there are several systems that command the opening or closing of the spar valves:
- opening: "Engine control panel switch" set to "START", or "Fuel control switch" set to "RUN"
- closing: "Engine fire handle" pulled out. (I wonder if "Fuel control switch" set to "CUTOFF" also closes the spar valve).
Are there direct wires running from these controls to the valves or is there a pair of control units receiving these signals and controlling the valve actuators?
If the latter is true, where are these control units? I guess that the likely location is the aft EE bay. Are they beside each other?

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?

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.

Emphasis added.

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.

You mention here the a/c roll and after rotation but there is also a short period during take-off where the wheels are in the process of leaving the runway. There is also the situation where the MLG was suspended at an angle. What was the WoW value at this stage?

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

Yours is very good logic, as far as it goes.

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.

I might have missed the thing, but as the gear up sequence did start we can be quite sure that the WoW logic had the aircraft \x94in air\x94 (not on ground).

This probably makes the theory of the TCMA halt a little? Gear up would be inhibited from not being in air.

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.

There has been another incident of a TCMA equivalent function shutting down both engines. An airBaltic airbus a220 in July 2021 (YL- AAQ) had both PW1500 engines shut down by \x93TCM\x94 logic in the FADEC immediately upon landing.

This seems to have been caused by a mismatch between actual and commanded thrust caused by rapid throttle movement that was \x93saved up\x94 until TCM was subsequently activated by its air/ground logic.

A description can be found on flightglobal but I have too few posts to include a url - So google a220 revised software engine shutdown

TCMA continues to be one of the few (very unlikely) causes of/contributors to simultaneous shutdown of both engines. So far, though, I don't think we've seen a credible scenario explaining the possibility that TCMA was triggered in this accident. I'm not sure I understand your speculation.

In the scenario you are considering, it's clear that the air/ground state would be wrongly "understood" by the TCMA function. But we don't have, AFAIK , a credible theory for how that might happen. Surely it would have to result from either incorrect signals from the relevant sensors or a failure of the related logic in the FADEC TCMA function, or a combination of those. Indeed, I don't think we yet know exactly which sensor readings that logic depends on or how those readings are fed to the FADEC. Does your speculation include any thoughts about this?

Also, the FADEC TCMA function has to "believe" that the engine is operating at high power and not responding to thrust lever operation. In your proposed scenario, is this also a logic failure \x97 in both FADECs? Or false inputs from both TLs? Or are both engines actually operating at higher than commanded power levels?

Or do I misunderstand your post?

Further to the (logical in my view) points you make in response to AAKEE's ostensibly logical conclusion that the commencement of undercarriage retraction (if it did commence) is conclusive of the aircraft being 'in the air' for aircraft systems purposes, including TCMA purposes, I make the following points:

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.

Let me try and summarise one possible scenario and then link in some of the better posts provide evidence relating to it:

• In error, PF reduces power to idle and/or reverse at a speed after V1 (either deciding to reject, or for some unexplained reason e.g. the recent BA incident at LGW)
• Decision is changed to continue take-off, thrust levers moved to TOGA
• Let's say the thrust inputs are similar to NM985 and TCMA is triggered; and engines shut down around the time of rotation
• A/C rotates achieving a maximum speed in the region of 184kts

Relevant "ruling out" questions, with links to posts that add new information:

Q: Would the a/c have enough kinetic energy a 184kts to climb to 100-150ft agl and then reach its final position if the engines had failed at, or just, before rotation?
A: Theoretically possible - see calculation here . NB, the a/c actually flew 1.5km from the end of the runway and 2.3km from the likely point of rotation.

Q: Doesn't the forward position of the gear mean that power failed after the pilots had selected gear up?
A: Inconclusive - had hydraulic power had been lost prior to rotation, the gear could also be in this position - explanation here

Q: If the throttle levers were brought to idle during take-off, would the A/C have applied autobrake, reversers and speedbrake?
A: Yes, although there is a built in delay before reverser and speedbrake actually deploy - see here .

Q: Is the ADS-B data consistent with this scenario?
A: Yes, e.g. the Flightradar data shows the aircraft decelerating rapidly (12 knots in 4.2 seconds) from close to rotation. However, it's not clear how accurate this data is. For one, the altitude data is +/- 25 feet, second, while I was under the impression FR would have received airspeed data from the a/c sensors, this post suggests maybe not.

Q: Does TCMA activation require the thrust levers to be at idle or does it function when the thrust levels are above idle, but where the actual thrust is above that commanded?
A: No, the latter is true (i.e. idle is not required) - confirmed here - there are of course many protections against false activation

Q. Did AI171 have the same software version / logic paths as NH-985
A. Unknown. That a/c had Trent 1000s so to some extent the software is different, but we understand the TCMA logic is broadly the same regardless of engine. I have not seen a post clarifying whether the TCMA software has been updated /changed via SB since 2019 to account for this incident.

Be grateful if posters could refrain from speculative responses "e.g. I think this is unlikely because I feel x". I am not opining on how likely this sequence of events is, simply trying to summarise whether or not this theory has been ruled in or out.

I also recommend this post for a summary to read before posting. .

This has been setting a bit wrong with me for the entirety of the thread. When people say "software" they have an image in their head, and in this case the image is rather unhelpful if not outright wrong.
When we say "Software" we mean things like this:
This is the type of software we are usually subject to in our everyday lives basically everywhere. Your phone, your fridge, your oven, your water heater, your car, etc. pp. ad nauseam.

In case of the Safran FADEC 3 this is not actually what we're dealing with. It uses something called an FPGA (Field Programmable Gate Array) which is a very different beast to what we are used to dealing with.

In a normal computer we simply translate code like above into something less human readable but instead interpretable by a microchip or the like. This "machine code" is then run sequentially and does whatever it is meant to do (hopefully). If we were to expand our little happy check above with another condition then our computer would sequentially check these conditions. This opens up a lot of hoopla about timing, especially when interacting with the real world.

Let's say you want to track N1 and N2 in an engine. You'd have to make a measurement, that value would have to go through an AD converter, which writes it to some (likely volatile) storage, where it is then accessed by some sort of (C)PU, transferred to yet another piece of volatile memory and then used in the computation. This takes time because you can't do those things within the same clock cycle.

Unsurprisingly this is rather inconvenient when dealing with the real world and especially when dealing with volatile physical processes that need monitoring. Like a modern turbine engine.

Enter the FPGA.

While it is programmable what that actually means is that (at a very high level) you can build a thing called a truth table, that means a definitive mathematical mapping of input states to output states. Unlike our sequential CPU driven system an FPGA will be able to perform its entire logic every time it is asked to do so. We don't have to wait for our happy check to perform any other check.

This is very useful for our Turbine Engine, because now we can verify that N2 is smaller than X without delaying our check that the Throttle Control Lever setting is within acceptable distance to N1 and N2, while also creating the appropriate output for all the different bypasses and bleed valves in a modern engine, and so on. The Safran FADEC 3 does this "up to 70 times per second" as per the vendor.

In order to be manageable the actual FADEC consists of multiple different pieces, many of which are FPGAs. At least two are used for so called "input conditioning". This is where we deal with converting messy real world values from sensors subject to real physics into nice and clean numbers. Here our values from the Throttle Control Levers come in, the signal from our N1 and N2 sensors, WOW signal, and on, and on, and on.

This is then changed into logic level signals provided to a different set of FPGAs. Lacking an actual schematic I suspect that this is what sometimes is referred to as "channels". The channel could consist of both a signal conditioning stage and then a logic stage or (more likely) redundant signal conditioning stages feed separately into separate FPGA "channels" are evaluated and then the end result is likely put into yet another FPGA for control output generation.

Why is this important?

Because it is basically impossible for a "bug" to exist in this system. These systems are the epitome of a dumb computer. They do _precisely_ what they are meant to do. The TCMA is simply a set of conditions evaluated just like any other condition in those FPGAs. If there is an "error" then it is in the requirements that lead to the truth table used by these devices but never in the truth table itself. In fact these types of computation device are used precisely because of that very property.

So when people say "the FADEC software" (ie TCMA) has "failed" or "has a bug" what they're really saying is: A bit of a mouth full, granted, but an important mouth full. This simply wouldn't be someone missing a semicolon somewhere in a thousand lines of code.

Regards,
Justus

tdracer was detailing the inputs to TCMA on a 74 and has said repeatedly that he doesn't know the details of that function on 787s. I'm sure of that because I misread his original post and based a post of mine on the misreading. The inputs he described were multiple WoW switches and multiple RAs, with inputs from each group required to determine that the aircraft is on the ground to enable TCMA-initiated shutdown. It seems likely that the 787 is similar, but that hasn't been established here. I've been looking but haven't found the details yet.

Whilst you\x92re right to highlight the type of software in a FADEC, it should also be recalled that after the dual uncommanded engine shutdown event on the Baltic CS300, the FAA mandated updated FADEC software for all of a family of P&W engines. FADEC s/w can contain what we\x92d call bugs (whether they\x92re mistakes of coding or mistakes of logic in the design assumptions).

"it is basically impossible for a "bug" to exist in this system." This is not my experience.There are a lot of bugs in hardware and FPGAs. The guys doing this are real experts and bugs are less common than in software. But they do exist and they can be difficult to reproduce and subtle to diagnose. For someone new to FPGA it can be very intimidating because everything is parallel. It requires a different way of thinking. You can execute 1000 instructions simultaneously.Then various tricks to speed things up or reduce glitches add complexity. For example you may want to count in gray code or one hot instead of binary. Writing bug free FPGA code is very challenging. We cannot assume the FPGA code is free of bugs.

I will just comment here that FPGAs contain many logic blocks which have around them routing channels which allow these logic blocks to be connected up in various ways, some of the logic is asynchronous, some of it is synchronous and thus uses clock signals to advance the state of the logic according to a combination on input signals, asynchronous logic outputs and signals fed back from other logic blocks.

All of this is created by writing software using something like VHDL (VHSIC Hardware Description Language where VHSIC stands for Very High Speed Integrated Circuit) with the output of the compiler for this software being an object file that contains the connection information for the on-FPGA routing. However, this process requires careful simulation, not just of the logical behaviour of the FPGA being designed but also of the ability of the programmable routing on the FPGA to get the required signals to where they are required with the necessary set-up delays so that the next clock edge does not allow a glitch where a signal changes state during the period when it must be static so that it propagates correctly through the logic blocks. With clock signals that form a clock tree across the device the skew on the clock signals must be carefully checked so that the lowest skew requirements are always met, there may be more margin for the less critical parts of the system.

Now, I am sure that the state of the art has moved on a lot since I was heavily involved in this sort of engineering but I can say that when my colleagues were prototyping ASICs (which are application specific devices that are not programmable like an FPGA) using FPGAs because it can be reprogrammed to cure bugs found in the code that created it I am absolutely sure that it is possible for a latent bug to exist in what has been built despite extensive testing being carried out. I well remember sitting down with an FPGA designer and a software engineer and showing them a situation where one of my radio devices was not being commanded to transmit, they refused to believe me until we captured their output signals in the failed state and I was thus able to prove to them that it was their logic and code that was failing and that my radio system was fully working except it couldn't possibly transmit when its enable line was inactive.

I would therefore never state that an FPGA-based FADEC is infallible. The devil will be in the detail of the functions contained within the devices and how they interact with each other and how the original logical functions are described and specified and then coded and checked for logical errors before getting on to the actual physical reality of the FPGA manufacturer's design and development system that bolts on to the back of the source code. If the FPGA devices are being pushed anywhere near the edge of their performance envelope, just like an aircraft things can go wrong. If a design begins with a device that is only just large enough in terms of how many logic blocks and routing channels are available for the logic required it's almost a certainty that development will take it to this area of its performance and a lot of tweaking may be needed which means that even more testing will be needed to be reasonable sure that it does what it is supposed to.

I don't think ‘worst case scenario will be preferred’ is the philosophy they use. The way tdracer explained it, there can't be any single failure that leads to uncommanded high thrust on the ground. Presumably, each FADEC channel is treated as a single 'fault isolation area.' That's why the inactive channel has to be able to effect a shutdown in case the active channel causes a runaway.

For the sake of argument, imagine if every air/ground sensor had to say 'ground' to enable TCMA. That should still meet the 'no single failure' requirement since you'd need at least 2 failures to get a runaway engine: the original thrust control problem, and a faulty air/ground sensor.

IIRC, he said that the 747-8 looks at weight on wheels, gear truck tilt, and radio altimeters. At least one of each has to say 'ground' for TCMA to be enabled.