Posts about: "TLA (Thrust Lever Angle)" [Posts: 6 Pages: 1]

In general, we can classify computer errors into 3 categories:

1. Errors in system design, specifications, or algorithms. These are cases where the computer does exactly what it was designed to do, but the design itself was flawed or inadequate, or had unforeseen consequences. This would include things like MCAS on the 737 MAX.
2. Software errors. These are cases where the computer does exactly what the code tells it to do, but not what the designers wanted it to do. This results from mistakes in writing the actual code, and this is usually what we'd refer to as a "bug." This includes things like race conditions, loops that fail to terminate, incorrect type conversion, etc.
3. Hardware malfunctions. These are cases where the computer does something different from what the code instructs. It can involve memory corruption or data bus corruption. It can result in a system that appears to work, but returns incorrect outputs, e.g. a calculator saying 2+2=5. It can also cause the computer to execute valid instructions, but at an inappropriate time. It can result from manufacturing defects in components, cosmic rays (SEU or SEE), radiofrequency interference (HIRF), moisture ingress, failed solder joints, and numerous other things.

As I said previously, I think we can rule out category 3 in this case. Hardware malfunctions are essentially random events. They're inherently unpredictable since there's little to no relationship between what the system was supposed to do and what it actually does. It would be astronomically improbable for the same failure to occur on both engines at the same moment.

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:

• Airplane on ground
• Thrust higher than commanded by thrust lever angle (TLA) for some period of time

It's reasonable to assume that the first condition is common to both engines. But that still leaves the second. To my knowledge, there's no plausible scenario that would cause that condition to be met on both engines simultaneously. Each thrust lever has 2 resolvers which are wired directly to the corresponding FADECs. That means the signals don't pass through any common component. An incorrect reading from one resolver could conceivably trigger TCMA, but I don't see any reason why that would happen to both engines simultaneously.

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.

Why should it? It\x92s part of the FADEC as are the TLA sensors.

To be less subtle- someone cuts off switches, unknown to PF and possibly PM, with throttles off idle... Would do nothing.

Worst case, at next idle TLA, engine shuts down. I bet eyes go to cutoff switches after a scan, surely EICAS/ECAM has a Captain Obvious alert set.

Runaway RPM or locked RPM, some FADECS latch at 86 or so % N1- you'd still need TLA of idle for the cut off switch to work.

Volcanic ash, loss of all engines, desire the simultaneous FADEC reset of cycling the cutoffs- just coordinate with PM for idle TLA.

Other jets have this standard, today.

I'd say the throttle needing to be at idle is one heck of a CRM/TEM-based reason. Dual resolvers can fail, but throttles no longer get locked by jammed cable runs to the FCU on the engine. A resolver bypass would possibly be required in extremis 10 to the minus 6 to 9th case.

Who flies the throttles in normal? PF
Who typically performs the steps, including idle TLA of shutdown/restart in flight? PM.

Agreed, but that knowledge does nothing to convince anyone that TLA is not involved in the response to fuel cut off.

This has all been answered in previous posts, but I'll repeat it for those you don't want to look back through something like 150 pages:

Thrust Lever Angle (TLA) is measured directly by the FADEC, using a resolver hardwired to and excited by the FADEC. Both FADEC channels have their own resolver input - on most Boeing aircraft it's a common resolver with two sets of electrically isolated windings, however on the 787 it actually uses two mechanically separate resolvers. The resolver is basically read as "sine" and "cosine" which is converted in the angle. This also makes error detection easy, using the sine squared + cosine squared relationship. Any other aircraft systems that use TLA use the TLA signal relayed back to the aircraft by the FADEC.

The fuel control switch is a two-position multiple pole 'latching' switch - you have to pull it out slightly over detent to move it between the RUN and CUTOFF positions (on other aircraft there is an interposing relay for some of the functions. not sure about the implementation on the 787). Moving the switch to cutoff sends a DC signal to both the High Pressure ShutOff Valve (HPSOV) in the fuel control and the spar valve commanding them to close. HPSOV is solenoid actuated and is near instantaneous, Spar Valve takes ~one second to change positions (yes, this is different than some other airframers that only send the signal to one valve or the other, but it's been standard Boeing design practice since the early 1970s). Both the HPSOV solenoid and the Spar Valve are designed to stay in their last commanded position if airframe power is lost. Moving the switch to CUTOFF also sends a 'reset' signal to the FADEC - meaning the FADEC will be offline for roughly one second. On the 787 (and 777 and 747-8), there is a brief pause (~0.25 seconds) before the shutdown signal is sent to the engine to allow the electrical system to reconfigure to prevent a brief interrupt of electrical power to the rest of the aircraft.

Pulling the Fire Handle does the same thing as the fuel condition switch - via separate wiring (physically isolated from the fuel switch wiring to help protect from things like rotor burst damage), with the exception of the FADEC reset (since there is no requirement to be able to restart the engine after a Fire Handle shutdown).

There is absolutely no TLA input into either the fuel conditions switch or the Fire Handle - you can shutdown the engine via either regardless of Thrust Lever Angle.

All this is standard Boeing design practice (and except for the no-break electrical power transfer) has been for at least 50 years. This is enforced by the Boeing "Design Requirements and Objectives" - DR&O - compliance with is demonstrated by an audit after the final design freeze.

An unresolved difference in TLA between the channels is quite unlikely - the fault detection algorithm is quite good (sine squared plus cosine squared) - but it can happen. In the old days, we'd default to the higher TLA, but since the feds became preoccupied with Uncontrollable High Thrust, we tend to select the lower value. Worst case would be to default to idle. The fuel switch discrete doesn't really get used except for engine start - if it falsely indicates shutdown (on one or both channels), the FADEC won't do anything if the engine is already running. All this will set maintenance faults - and associated EICAS Status messages (L/R ENGINE CONTROL or ENGINE C1). I doubt that would be recorded on the DFDR - it would go to the QAR but that's unlikely to survive a crash. It would also be logged in the FADEC NVM - but again no guarantee that would survive either (although when the Lauda 767 crashed due to the thrust reverser deployment, the DFDR was destroyed but the FADEC NVMs both survived - much of what we know about that crash came from the FADEC NVM.)

Again, not familiar with the specifics of the 787, but on the 747-400/-8, one pole of the fuel switch feeds EICAS - which uses it in various message logic - and sends it out to any other aircraft systems that use it. There is "Digital Flight Data Acquisition Unit) DFDAU (pronounced Daff Du) that takes all the various system digital signals, sorts them and provides them to the DFDR and QAR. The 787 has something similar to the DFDAU but I don't recall what it's called.