Posts about: "FADEC" [Posts: 231 Pages: 12]

Yes. Thank you tdracer. All those postulating TCMA / FADEC faults please read and understand this clear explanation.

Then, ask yourselves which extraordinarily low probability bundle of previously unrevealed faults could spontaneously manifest themselves on both engines simultaneously.

Also ask yourselves why these faults manifested at that critical phase of flight and not during taxiing or take-off roll when some of the TCMA sensors would have been primed.

After reading tdracers informative post this morning, I too was musing: Why is all this attention being given to TCMA.

Of course, when the probable cause is profoundly unclear, our continuing distrust of latent technical systems comes to the fore .... as sadly, the shadow of MCAS still looms large in our imaginations

Not 757 - it was a 767. Second time it happened in about 12 months.

Determined to be an ergonomics problem with the switch layout in the flightdeck.

Early 767s (JT9D and CF6-80A) had a supervisory "EEC" (Electronic Engine Control - Boeing still uses "EEC" to identify what most people call the FADEC on modern engines). The procedure if an EEC 'failed' was to switch both EECs off (to prevent excessive throttle stagger - unlike FADEC, the engine could operate just fine with a supervisory EEC failed).

Problem was that the EEC ON/OFF switch was located on the aisle stand - right above the fuel cutoff switches. Turned out 'muscle memory' was when the pilot reached down there, it was usually to turn the fuel ON or OFF - which is what they did. Fortunately realizing what he'd done wrong, the pilot quickly restored the switches to RUN and both engines recovered. And yes, they continued on to their destination (RAT was still deployed since there is no way to retract it in-flight).

Previous event was with JT9D engines (United IIRC). In that case, only one engine recovered (second engine went into an unrecoverable stall), they simply came back around and did a single engine landing.

Realizing the ergonomic issue, the EECs were relocated to the pilot's overhead (retrofit by AD).

To the best of my knowledge, there hasn't been a repeat of an inadvertent dual engine shutdown since the EEC switches were relocated. It's also very difficult to 'accidentally' move the switches as there is a locking detent - the switch must be pulled out slightly before it can be moved to CUTOFF.

OK, another hour spent going through all the posts since I was on last night...
I won't quote the relevant posts as they go back ~15 pages, but a few more comments:

TAT errors affecting N1 power set: The FADEC logic (BTW, this is pretty much common on all Boeing FADEC) will use aircraft TAT if it agrees with the dedicated engine inlet temp probe - but if they differ it will use the engine probe . The GE inlet temp probe is relatively simple and unheated, so (unlike a heated probe) a blocked or contaminated probe will still read accurately - just with greater 'lag' to actual temperature changes.

TCMA - first off, I have to admit that this does look rather like an improper TCMA activation, but that is very, very unlikely. For those who don't know, TCMA is a system to shutdown a runaway engine that's not responding to the thrust lever - basic logic is an engine at high power with the thrust lever at/near idle, and the engine not decelerating. However, TCMA is only active on the ground (unfamiliar with the 787/GEnx TCMA air/ground logic - on the 747-8 we used 5 sources of air/ground - three Radio Altimeters and two Weight on Wheels - at least one of each had to indicate ground to enable TCMA). TCMA will shutdown the engine via the N2 overspeed protection - nearly instantaneous. For this to be TCMA, it would require at least two major failures - improper air ground indication or logic, and improper TCMA activation logic (completely separate software paths in the FADEC). Like I said, very, very unlikely.

Fuel contamination/filter blockage: The fuel filters have a bypass - if the delta P across the filter becomes excessive, the filter bypasses and provides the contaminated fuel to the engine. Now this contaminated fuel could easy foul up the fuel metering unit causing a flameout, but to happen to two engines at virtually the same time would be tremendous unlikely.

Auto Thrust thrust lever retard - the TO lockup in the logic makes this very unlikely (it won't unlock below (IIRC) 400 ft., and even that requires a separate pilot action such as a mode select change or thrust lever movement). And if it did somehow happen, all the pilot needs to do is push the levers back up.

Engine parameters on the FDR: I don't know what exactly is on the 787 FDR with regards to engine parameters, but rest assured that there is plenty of engine data that gets recorded - most at one/second. Getting the FDR readout from a modern FDR is almost an embarrassment of riches. Assuming the data is intact, we'll soon have a very good idea of what the engines were doing

TCMA is on both the Trent 1000 and GEnx-1B 'basic' - it was required for certification. There is no reason for TCMA to be listed in the MMEL as the only 'functional' portion is the via the electronic overspeed protection system (which is required for dispatch - no MEL relief) - the rest is software resident in the FADEC.

Another hour spent sifting through the stuff since last night (my sympathies to the mods ). A few more comments:

"Real time engine monitoring" is typically not 'real time' - it's recorded and sent in periodic bursts. Very unlikely anything was sent from the event aircraft on this flight.

Commanded engine cutoff - the aisle stand fuel switch sends electrical signals to the spar valve and the "High Pressure Shutoff Valve" (HPSOV) in the Fuel Metering Unit, commanding them to open/close using aircraft power. The HPSOV is solenoid controlled, and near instantaneous. The solenoid is of a 'locking' type that needs to be powered both ways (for obvious reasons, you wouldn't want a loss of electrical power to shut down the engine). The fire handle does the same thing, via different electrical paths (i.e. separate wiring).

As I've noted previously, a complete loss of aircraft electrical power would not cause the engines to flameout (or even lose meaningful thrust) during takeoff. In the takeoff altitude envelope, 'suction feed' (I think Airbus calls it 'gravity feed') is more than sufficient to supply the engine driven fuel pumps. It's only when you get up to ~20k ft. that suction feed can become an issue - and this event happened near sea level.

Not matter what's happening on the aircraft side - pushing the thrust levers to the forward stop will give you (at least) rated takeoff power since the only thing required from the aircraft is fuel and thrust lever position (and the thrust lever position resolver is powered by the FADEC).

The TCMA logic is designed and scrubbed so as to be quite robust - flight test data of the engine response to throttle slams is reviewed to insure there is adequate margin between the TCMA limits and the actual engine responses to prevent improper TCMA activation. Again, never say never, but a whole lot would have had to go wrong in the TCMA logic for it to have activated on this flight.

Now, if I assume the speculation that the RAT deployed is correct, I keep coming up with two potential scenarios that could explain what's known regarding this accident:
1) TCMA activation shutdown the engines
or
2) The fuel cutoff switches were activated.
I literally can come up with no other plausible scenarios.

In all due respect to all the pilots on this forum, I really hope it wasn't TCMA. It wouldn't be the first time a mandated 'safety system' has caused an accident (it wouldn't just be Boeing and GE - TCMA was forced by the FAA and EASA to prevent a scenario that had never caused a fatal accident) - and there would be a lot embarrassing questions for all involved. But I personally know many of the people who created, validated, and certified the GEnx-1B TCMA logic - and can't imagine what they would be going through if they missed something (coincidentally, one of them was at my birthday party last weekend and inevitably we ended up talking about what we used to do at Boeing (he's also retired)). Worse, similar TCMA logic is on the GEnx-2B (747-8) - which I was personally responsible for certifying - as well as the GE90-115B and the 737 MAX Leap engine - the consequences of that logic causing this accident would be massive.

The only aircraft inputs to TCMA is air/ground and thrust lever positions - everything else is the FADEC and its sensors (primarily N1). Even if air/ground was compromised somehow, it would take other issues before TCMA could possibly be activated. Possible on one engine (although remote) - but two engines at the same time - almost literally imposssible (unless of course it's software error).
The 'good' news is that even a cursory check of the FDR will indicate if TCMA activated, so we'll soon know.

I hate to disappoint you, but the people (like me) who design, test, and certify aircraft are not idiots. We design for failures. Yes, on rare occasion, something gets missed (e.g. MCAS), but we know that aircraft power systems sometimes fail (or suffer short term interuptions) and we design for that. EVERY VALVE IN THE FUEL SYSTEM MUST BE POWERED TO CHANGE STATE!!!! If electrical power is lost, they just stay where they are. The engine fuel valve must be powered open, and it must be powered closed. Same with the spar valve. The pilot moves a switch, that provides electrical signals to the spar valve and the engine fuel valve to open or close. It's not complicated and has been in use for decades.
TCMA (not TCAM) - Thrust Control Malfunction Accommodation - is a FADEC based system. It's resident in the engine FADEC (aka EEC) - the ONLY inputs from the aircraft that go into the TCMA is air/ground (to enable) and thrust lever position (to determine if the engine is doing what it's being commanded to do. The FADEC has the ability to shutdown the engine via the N2 overspeed protection system - this is separate from the aircraft run/cutoff signal, although it uses the same HPSOV to effect the shutdown. That same system is used by TCMA to shutoff fuel if it determines the engine is 'running away'.

Hint, you might try going back a few pages and reading where all this has been posted previously.

Keeping track of this thread is tiring - again, my sympathies to the mods, as tiring as I find it, it must be far worse for them )
Apologies for a few terse posts last night, but a couple of inane posts (by a usual suspect) really set me off. I've never used the 'ignore' function, but I may need to revisit that.

I posted this previously, but it was about 70 pages ago, so I understand not going back that far, or forgetting that tidbit amongst all the noise.
In short, I'm not familiar with the specific air/ground logic on the 787/GEnx-1B - the logic I posted (3 radio altimeters, 2 Weight on Wheels, at least one of each must indicate 'on-ground) is for the 747-8 (which I'm intimately familiar with). I have a vague recollection of a discussion with my GEnx-1B counterpart 10 or more years ago that suggested that the 787 was not as complex as the 747-8, but I don't recall any details. Basic FADEC logic (BTW, as someone else noted - it's "Full Authority", not "Autonomous") is to default to 'air' if in doubt, as it's considered to be 'safer'.
The only real hardware in the TCMA system is the N2 overspeed shutdown system - which goes through a BITE style functional test on every engine start. Everything else is in software - with the only aircraft inputs being Air/Ground and thrust lever position.

As I've posted previously, the FADEC is powered by a dedicated Permanant Magnet Alternator (PMA) - aircraft power is used only as a backup for starting or if the PMA fails. If the FADEC determines it is running on aircraft power with engine running (i.e. the PMA has failed), it sets a 'No Dispatch" fault message.

I'm not familiar with the details of how the FADEC s/w is coded (it's the responsibility of the engine manufacturer - in this case GE). Boeing provides specific requirements as to the aircraft/engine interface (documented in an "Interface Control Document" - ICD).
My understanding is that GE uses an automated coding system that takes logic diagrams of what we want the s/w to do and turns that into the s/w code - again don't know details (my expertise is engine control and engine/aircraft interface - not s/w development).
The FADEC is a dual channel device (most of the sensors are also duplicated between channels), but both channels use the same s/w (Rolls did a thing many years ago where the channels used different s/w - it was mess and caused all sort of problems - I don't think anyone else has tried that since).

FADEC software is classified as "Design Assurance Level A" (aka DAL 'A') - flight critical - same thing as FBW software. There are specific requirements for the creation, testing, and certification of DAL A software and it's quite exhaustive (those requirements are documented in an FAA/EASA approved s/w requirements document (DO-160 IIRC). Yes, it is possible for something designed and certified to DAL A to have 'bugs' (and yes it has happened), although those 'bugs' have nearly always been traced to requirements errors - not the actual incorporation of those requirements.
It's also worth noting that the GEnx-1B has millions of hours of operation. Nothing is 'impossible' - even a 10-9 event will happen given enough opportunities - but the odds are very low of it happening.
Then again, all of the plausible explanations for dual engine power loss that would explain this accident are of a very low probability.

As I noted previously, the FADEC is a dual channel device. It's long been the case that dispatch is allowed with a single FADEC channel failed (this goes back to the original PW4000/CF6-80C2 as installed on the 747-400 and 767.
The MMEL says something like "4 installed, 3 required" (referring to individual FADEC channels) - so you can dispatch for a short time with one FADEC channel failed. Yes, if the remaining channel of faulted FADEC fails, the engine will fail - but the FADEC reliability is such that the probability of losing the remaining channel (and hence the engine) is sufficiently small as to be acceptable.

Both channels can operate TCMA, so a single channel failure has not overall effect on the system.

Again, 'channel out' dispatch is nothing new - it's been the case since 1989 (when the PW4000/767 entered service).

No, it doesn't.
There are already 'dual-path power redundancy for FADEC' - dedicated engine driven FADEC power supply, and aircraft supplied 'backup' power. Again, there is no known way that an aircraft issue could cause the FADEC to lose power.

I'd rack this up to more AI generated nonsense.

Edited to add - others have beat me to the punch...

Have to admit, that made me chuckle

Repeating myself (again), but ALL the TCMA logic is resident in the FADEC. It takes aircraft inputs of air/ground (again, not familiar with the specifics of the air/ground logic used on the 787/GEnx-1B, so don't ask), thrust lever position, and what the engine is actually doing (mainly N1) to determine if the engine is 'out of control'.
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. Default mode for the FADEC if aircraft inputs are lost or invalid is "Air", as that is generally considered to be the 'safe' choice.
But even assuming some aircraft fault caused the FADECs to falsely believe the aircraft was 'on-ground', it would still take a pretty major error in the TCMA logic for it to actually trigger and shutdown the engine (especially lacking an associated thrust lever movement to idle). Never say never, but we're getting pretty far out on the probability tree for all these things to happen.

Yes. Thank you tdracer. All those postulating TCMA / FADEC faults please read and understand this clear explanation.

Then, ask yourselves which extraordinarily low probability bundle of previously unrevealed faults could spontaneously manifest themselves on both engines simultaneously.

Also ask yourselves why these faults manifested at that critical phase of flight and not during taxiing or take-off roll when some of the TCMA sensors would have been primed.

I’m not a 787 driver so for fear of looking dumb in front of those that are this still confuses me. Even IF they’ve mis-selected the flap setting (I still don’t think it’s been cemented on here that there is in fact a FMS/flap setting disagreement warning but i believe there is), had the wrong de-rated take off settings, selected flaps instead of gear up the 787 with massive high bypass engines, FBW and full envelope protections surely cannot let itself be put in such a low energy/high alpha regime as we saw in the videos IF it has both fans functioning normally, surely?

the pilots may have messed up royally and numerous times so those holes lined up but the plane is the final block in the chain and a 21st century all digital entirely clean sheet design was sold as being immune to such catastrophic outcomes from a few minor (consequential yes) and fairly common errors- aren’t all the protections and our procedures designed after decades of mistakes?

im having a hard time squaring how a fully functioning modern bird like this could allow for this outcome and almost whatever the pilots did outside of unbelievable inputs and the pilots are are a bit of a red herring IMO

DO-178 unless propulsion systems are for some reason different from displays and flight controls.

I have been on the fringes of dissimilar hardware and dissimilar software designs (MD-11 flight controls). Sometimes it is necessary but there is a huge overhead in both development and test.

Edit to add - Even with dissimilar processor and software the requirements for both will trace up to some common high level system requirements specification. There is a non zero probability that those top level requirement were inadequate or included an error.

Adding to your response TD, there is no time in this event where a high AOA arose prior to the final moments, around 13 seconds after the problem has occurred. AOA, intake separation is not a factor.

Going back to your prior comments on FADEC and TCMA; these are independent systems to each engine, however the event indicates a symmetric loss, and the potential of water ingress from a failed E/E sealing from the main cabin services remains a single causation that could result in multiple failures at the same moment. The last time I assessed issues in the E/E bay related to unauthorised inflight access to the fwd E/E of a B777 it was sobering how many irreversible conditions could arise. The B744 water inundation cases I was involved in were both on TO, the QF event was during deceleration. We are looking at vectors that come from outside of the normal assumptions in the SSA's, water fits that bill.

Yes. Thank you tdracer. All those postulating TCMA / FADEC faults please read and understand this clear explanation.

Then, ask yourselves which extraordinarily low probability bundle of previously unrevealed faults could spontaneously manifest themselves on both engines simultaneously.

Also ask yourselves why these faults manifested at that critical phase of flight and not during taxiing or take-off roll when some of the TCMA sensors would have been primed.

After reading tdracers informative post this morning, I too was musing: Why is all this attention being given to TCMA.

Of course, when the probable cause is profoundly unclear, our continuing distrust of latent technical systems comes to the fore .... as sadly, the shadow of MCAS still looms large in our imaginations

tdracer:

"What sort of 'confirmation' do you have in mind - the regulator mandate that resulted in TCMA basically says we can't take credit for the flight crew"

I had just that in mind, as any automated action that could shut down both engines really should have pilot confirmation, imho, but looks like the regulators may not have considered all possible scenarios.

Another question, maybe a complete red herring: Is the TCMA a completely self contained module with it's own processor and software, (possibly the best option) or is it part the FADEC software package, perhaps just a task in a real time multitasking system ?. If the latter, that would open a whole rabbit warren of possibilities.

From all the evidence thus far, it looks like the RAT did deploy, plus other data, which means there was likely a complete electrical power failure. The idea that all four generators and controls would fail at once doesn't make sense, so that doesn't leave much else as the next step.