FADEC issues - are there any?
 

The furore around the Air India tragedy has me tinking about the reliability of current FADEC systems and having been out of the saddle for a few years now, maybe some current pilots/engineers will have a view?

Can a modern jet lose all thrust due to an electrical problem? We know that the RAF Heli crash on The Mull raised some issues but that was quite a time ago now and aircraft such as the B787 and latest generation Airbus will be different but the debate about the AI event makes me wonder.

Electrical failures may cause all sort of issues depending on their nature but for a fault to cause total loss seems pretty worrying to say the least.

FADEC has been a thing since Concorde, and digital FADEC has been a thing since way before the 787, indeed was a thing on the “good old” 747-400 and 767/757. It is very well proven technology and barring some sort of coding issue (which I know nothing about as I am a very simple man but would be the only area I’d even begin to consider a potential weakness/source of failure) the power supply to the FADEC in any airliner is incredibly robust, with literally any of the power sources on the aircraft able to power it, which would only be necessary if the permanent magnet alternator that normally powers it failed. For that to happen simultaneously to both engines is such a remote likelihood that we may as well worry about meteorite strikes.

Thanks, so it is the power supply to it we need to worry about rather than the system itself?

I think Speed_Trim_Fail said the exact opposite.......

Power.

Timmy
I began working engine controls in 1984, and did little else until I retired near the end of 2016. When I started out, my boss decided he wanted me to be a 'hydromechanical guru' (I have really good mechanical aptitude) and made sure I got lots of training on the details and subtleties of hydromechanical controls. But within a few years, it became quite obvious that FADEC was taking over and doing strictly hydro stuff was a dead end, so I soon expanded into FADEC.
The last big commercial turbofan engine that wasn't FADEC was the CF6-80C2 - and even that was turned into a FADEC control when Boeing told GE they wouldn't put throttle cables in the 747-400, so if they wanted on, they needed to create a FADEC version.
ETOPS was becoming a big thing about the same time - and the full FADEC PW4000 and CF6-80C2 engines were being certified for use on the 767. Hydro controls tend to give warnings that something is 'wearing out' - electronics don't generally do that, they either work or the don't, so the impact of FADEC on the shutdown rates was exhaustively worked. As a starting point, we looked at the historical rates of hydro control caused shutdowns and Loss of Thrust Control (LOTC), and targeted reliabilities that would mirror those rates for FADEC with necessary shutdown/LOTC rates to meet the ETOPS requirements. But as it turned out, FADEC was way, way more reliable - which contributed in no small way to the impressive engine reliability that has allowed up to 330 minute ETOPS (engine shutdown rates are so low, that now days, more attention is given to impact of ETOPS on the rest of the aircraft than to the engines themselves.

The reliability of the FADEC electronics is so good that they've implemented "Time Limited Dispatch" - which allows extended dispatch with certain 'loss of redundancy' faults - up to and including losing a complete FADEC channel. The hardware is tested and certified for high levels of electromagnetic interference (e.g. radar) and lightning effects.

Software is developed to DO-178 standards as "Level A" - i.e. flight critical. Yes, sometimes s/w errors get through, but most of those are really requirements errors, not coding errors as such.

There have been a few issues that came up over the years. As the newer generations of integrated circuits have gotten smaller and more powerful, something called "Single Event Upset" became a concern - this is where a high energy cosmic particle hits a CPU or memory chip and causes a bit to change state. Now these particles are so small that they can pass right through the earth without hitting something, and with the older circuitry hardware the electrical charges were strong enough that even if a particle hit, it wouldn't have enough energy to change the bit state - but the newer stuff occasionally had an issue that could cause an LOTC. So the newer FADECs run constant checksum type checks - looking for SEU caused discrepancies and if one is detected, the channel automatically resets.

To date (with the jury still out on the recent 787 crash), no major incidents or accidents have been traced to a FADEC engine control system issue since FADEC became widespread over 35 years ago. Yes, there is the odd shutdown or LOTC event due to a FADEC problem, but the rate is much lower than it was with the older hydromechanical control systems.

Would be interesting to know if there are any common nodes that both left and right throttle angles and ARINC busses encounter from the cockpit to the individual FADECs. There certainly is major redundancy designed in but something seems to have powered down both engines. Makes one think it is not a FADEC issue but somewhere in the overall system.

Howdy
 

As I understand the potential, this is a .25 Megawatt system. The third loss of (two) generators melted the Emergency Batteries in the aft EEBay., with arcing present.

Dunno any more than that... (From PPRune 12 Dec. 2012)

In that thread the Captain had more to say. Worth a read.

Understood the batteries are in a titanium closet now, but the current and load must-have been sumthin

Regards, bb. ( Somewhat curious )

Re AI171, if the APU started, when and how long to regain flight controls and instruments? Quickly enough to power up and climb???? I don't believe that was flare....would Fadec have come in on standby power???? If the Emergency Batteries burned up here as in United/New Orleans, the APU won't start.... Is Fadec in any way APU reliant. Sorry for all the questions ....when one knows little, he has many too many questions??

FADEC has its own Permanent Magnet Alternator to power it, so it runs if there’s NO other power available, it’s all internal to the FADEC. tdracer has covered this several times.

IF the RAT was deployed, flight controls are powered, there is no appreciable switchover time from the normal hydraulics. It deploys in a second. I’ve done in-flight RAT checks on three types and the transition is imperceptible. Note, much older designs, so it’s likely to be better in the 787.

Thanks.
 

What powers (turns) the alternator?? If the generator(s) go off line, and the emergency batteries (Thales) are inop, how does the APU start? The batteries were destroyed when two generators failed in the United incident. Panel? EICAS??

Isn't the RAT intended to support descent and safe landing??
Not save a TO?
How resilient is the RAT to overload when in flow with arcing and shorting in the Main Generation system??
.
Thanks GF

TDRACER May have to answer these,I’m just a pilot, but here goes.

The PMA is driven off the engine’s accessory gearbox. During engine start, there’s little rotation, so it’s powered by A/C or a dedicated battery. Once the started, it shifts to the gearbox driven PMA. Yes, it’s unpowered IF the gearbox fails but the engine won’t run for other reasons like no oil pressure, no fuel pressure, high or low.

i can’t say for the 787, but the APU usually has a dedicated start battery near the APU to power the APU FADEC during start, and the APU starter.

The RAT is for anytime it’s needed by the emergency conditions causing its deployment. As long as the airspeed is sufficient, it matters not if it TO, climbing, descending or landing. They’re certfied to provide the needed services. Usually when the speed decays, the electrical drops off giving priority to hydraulics to power the flight controls. That’s all specific to the design. There’s lots of configurations for the RAT, just hydraulics, hydraulics and a generator, just a generator that is large enough to drive an aircraft pump for flight controls. If you have serious arcing on the buses powered by the RAT, well it just isn’t your day. Usually, the RAT only powers the essential AC & DC buses and is separated from the Main load buses.

As I said somewhere in this dreary vale of tears, loss of all generators and loss of all engines will look much the same. Especially in a dark simulator. The first thing to look for is what is the engine indications and feel like. Loss of all engines means loss of all generators, but not vice versa.

If a RAT-equipped plane lost all electrics but will hand thrust (or one inop) on lift-off the RAT is required to enable a return. Admittedly, the crew will have a job of work, need to be smooth as the flight controls are not as responsive esp OEI, but they’ll be flight controls, avionics on the captain’s side, comms.

If you're going to quote a post, it would be nice to have a link to the original for context.

On the face of it, it reads as... rubbish.

Generally speaking the loads on the batteries are tightly specified; the capacity of the full system is irrelevant because most loads are shed, not moved to the battery. Only the various standby/battery buses get moved to the battery, and the battery is designed to handle them. It's not a ~10kW battery suddenly being loaded to 750kW. (edit: just because a battery is designed for a load does not mean it will never fail at that load... but it doesn't mean that a generator failure causes a battery to operate outside its certified limits)

The A320 manual claims "about 8 seconds" for emergency electrical, but that includes sequentially:

• deploying the RAT
• the RAT spinning up in airflow
• pressurising the blue hydraulics enough to open the priority valve (i.e. flight controls are satisfied)
• spinning up the hydraulic EMER GEN
• Generator controller being satisfied and putting the EMER GEN on line

During that time, batteries and static inverter power the flight computer(s?) and hydraulic pressure is probably somewhat available from a winding down or windmilling engine (on green and/or yellow) and the accumulators.

787 should be faster because the generator is directly on the RAT shaft.

I haven't seen a figure for the cutout speed on the 787 flight control PMGs - it seems possible that they're comparable to FADEC alternators and work down to 10-15%. If so, the airplane is likely controllable on windmilling alone with windmilling L/R hydraulics and PMGs, but I think you would need RAT or batteries for instruments beyond standby or any radios.

The whole thread
 

https://www.pprune.org/rumours-news/...rgency+landing

Only thirty four posts

There is one crash, when the FADECs on an A400 military transporter switched off three of four engines.

Looks entirely unrelated to batteries. Without seeing an incident report, I would say parallel arcing fault, and inadequately designed protection. Lack of differential protection alluded to in the last comment probably doesn't help, though it shouldn't really be necessary if you can make everything soft start and your circuits are small relative to the generator. It might not interact well with the DC portion of the large motor systems, depending on how that's implemented. Unfortunately, all the Boeing drawings are just big-black-box.

Fault containment on ground switchboards is heavy. I doubt the situation is too different on an aircraft. Steel or distance to segregate different portions of the switchboard so that a fault in one part cannot cause a fault in the other. Aircraft have long had separate left/right electrical panels because of this.

(edit: energy released from arc flash is almost entirely due to power available and the operation time of the protection; connected load is irrelevant)

You also often have reclosers set to reset 3-5x then not further close into a fault, but that doesn't seem to be a thing in aviation

You won't start an APU without a battery or large AC power (i.e. not RAT). This is part of why the 737 must have the APU running when in ETOPS conditions, because otherwise loss of two generators or engine+offside generator means you are relying on ~30min battery. Combined reliability of cold-soaked already-loaded battery + APU start is not great. A RAT negates this because you have instruments/radios indefinitely.

The general design of electrical systems is simply to isolate energy from faults. If there is a major bus fault, the generator and bus-ties to that bus should disconnect clearing the fault. You can't really do this internally to a battery which is why battery fires are harder to deal with.

The emergency bus(es) don't backfeed into the normal buses, so if a fault is present in a normal bus, switching the emergency bus to an alternate source of supply (offside or RAT/EMER GEN) will physically disconnect it from the original faulty supply.

If the fault exists in the emergency bus, you shed the emergency bus and rely on the redundancies present in the other two+ buses of that type.

For reference, here's the relatively simple setup on the A320:


https://cimg4.ibsrv.net/gimg/pprune....00feeed285.png

"If the fault exists in the emergency bus, you shed the emergency bus and rely on the redundancies present in the other two+ buses of that type."

The Emergency bus fault is what got the Yuasas to thermal runaway, and eliminate the APU from being started...the New Orleans diversion started with "Battery Fire" on the panel. In. 2013, the fleet was grounded. Then the Stainless box and Titanium belly hot remnant dump. We don't know how many fires aloft there were. Boeing had to own at least three. This thread adds three, and further Boeing secrecy. In AI 171, we will find out if the generator fail And loss of the Electrical system and/or the two engines loss brought her down....a quarter of a million watts. Yikes

"Bang", cabin lights flashing, no aircon, etc etc....likely none of this is software... The Batteries are now made by Thales. Like the pitots were on 447....

Design? Spec sheet? QA? Bean counters? The Dream is the most beautiful aircraft, she has issues ....

That is the sort of thing I was wondering. In the Air India case, could a cascade of problems cause someting like that?

The "arcing" comments above are alarming.

The A400M crash was caused by incorrect software installation. That airframe was a trials aircraft, so a rather different scenario than a certificated in-service civil airliner.

The PMG is the primary source of power to the FADEC, ship power as a backup or during engine start / ground operations.

After the A400M crash, we got some urgent inquiries from the FAA and a few operators as to how we make sure the same thing didn't happen on a Boeing FADEC airliner.
I basically responded that - until/unless Airbus and Rolls release details - it was impossible to answer the question since we don't know what they did wrong. I then included a brief outline of the steps that Boeing takes to validate that software is 'airworthy'. **
At least at the time I'd retired, Rolls/Airbus had not released anything public indicating how the FADEC s/w error occurred (my suspicion was that it was a silly QA type error, and they were too embarrassed to make it public - not unlike the Alaska 737MAX Door incident).
Does anyone know if a proper accident report was ever released?

** Boeing has specific procedures for FADEC software before it's used for flight. First off, the new software is checked in our Propulsion Integration Lab (aka "PIL") using a standard battery of tests - plus specific conditions intended to test whatever new logic or functionality is included in the new s/w. Assuming it checks out in the PIL, it's installed on one engine for an actual aircraft flight test. After a normal flight cycle has been successful completed, it can be installed 'cross wing' for subsequent flights.
There is also the capability to 'trim' software for specific flight test purposes - for example to raise the max N1 limits to allow testing at power settings above the normal max ratings, or in the specific case of TCMA, it's routinely disabled during the initial flight testing of a new engine type until we have adequate 'real world' data to validate the TCMA limits. Software trims are treated the same as new software loads - tested in the PIL, then installed on a single engine for a flight, before it can be installed cross-wing.

Note that FADEC s/w is also certified Part 33 - which includes all the DO-178 testing and validations - normally before we install it on an aircraft. During a flight test program, sometimes we get FADEC s/w that hasn't been formally Part 33 certified, but has gone through all the necessary validations and testing for Part 33, it just hasn't been signed off (there are some other specific steps when that happens). FADEC software should never, ever appear on a revenue passenger flight until it has both Part 33 and Part 25 certifications.

BTW, a number of 'checksum' checks are performed during the FADEC software (or trim) loading to ensure the s/w load isn't somehow corrupted.

A much better thread than that another one, very useful info. Thanks to all. :)
I had forgotten about the A400 3 engine loss event, may read up on it again. Sorry to hear that RR/AB kept mum about that.

Grounding
 

There was a great deal of Pprune input after the fleet was grounded (sic).... The focus was on the aft E+E Bay, and the architecture of the Lithium Ion (Yuasa designed/built) batts.

It was thought that the batteries spontaneously went into thermal runaway, I don't recall discussion about generators or the "Generator Control Units". In any case Boeing at some stage installed the Thales batteries, they had a new feature, the patent on "inflection point"... Which made them the clear choice.... Battery fires were patent, I think the EEbays, fore and aft, may have had summat part in this crash.... The APU door suggests it had been selected in some form or fashion... Did it come on line??

There was a Diamond twin star had a fadec shut down. Smaller yes, but just as pertinent

https://www.defensedaily.com/sudden-...uncategorized/
.

https://download.aopa.org/epilot/200...0diamondsb.pdf

FADEC issues on bizjets are more common as they are not designed and certified to the same level as commercial airliners. In this case, the FADECs were run off aircraft power - no dedicated generator - so when the aircraft power glitched, it quit. That design would never pass muster on a Part 25 commercial airliner.
There was another bizjet crash 10 or 15 years ago when the pilots somehow managed to move the thrust levers 'too far' during takeoff and the thrust lever resolvers went 'out of range' high, so the FADECs defaulted to idle. We immediately had to demonstrate to the Feds why that would never happen on a Boeing. Thrust lever resolvers are normally designed to operate between about 5 and 85 degrees (since the resolver basically works by comparing 'sine' and 'cosine' to determine the angle - so the resolution gets lousy near zero and 90.
For Boeing installed FADECs, we don't have the resolver go 'out of range' if exceeds the maximum angle - rather we keep it valid, and if goes past 90 it just goes down the back side of the sine/cosine curve.

The Diamond is not bizjet, it’s a light piston twin with FADECs. I’d love the details on that bizjet event. The GE Passports and RR Pearl engines (Global Express 7500 and 6500, respectively) should meet FAR 33 and 25 specs. They both operate the same as other Part 25 FADECs , off a PMA after start. Those engines did the new high thrust, high altitude shutdown tests.

What I find interesting is that at least in the patent of the TCMA, the TCMA copies running on channels A and channel B of the FADEC can trigger the fuel cut-off independently.

Do we know how the throttle position input looks like? There must be at least two sensors (potentiometers? resolvers?) per throttle lever. Do channels A and B of the FADEC receive both (or all) throttle inputs and validate them? Or is a sensor fault expected to be handled by the two FADEC channels disagreeing?

If for some reason each channel gets only one input, or TCMA is a separate process and does not use the validated throttle position but rather one of the raw inputs, then a single throttle sensor fault could trigger the fuel cutoff. It is still very unlikely that it happens to both engines simultaneously, unless indeed there is some short-circuit.

If the TCMA only activates if the throttle is at idle, it further requires that one of the throttle sensors shorts to what would be the idle position. If the rest of the FADEC detects a disagreement, the final command to the engine might not be idle (but e.g. keep current thrust), so at some point the TCMA will trigger as you hit the ceiling of the falling thrust contour.

Interesting. So with your reference to the CF6 getting FADEC on the 744, did RR also go FADEC on the RB211 on the 744 and 767? (I understand the RB211 was interchangeable etween those two). Sadly RR did not install FADEC on the RB211-535 on the 757.

Thank you TD for a very detailed and informative reply. TT

FWIW and I'm happy to cop flack on any mistakes made, I posted this on the Air India 787 thread, with some deletions of material irrelevant to this thread:

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

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.
....
https://cimg4.ibsrv.net/gimg/pprune....813c12f306.png

Yaw/FBW
 

The first video showed Yaw right. Later, the video was chopped and the Yaw was missing . FBW has OEI recovery.
Another poster disagreed and offered as evidence no visible Rudder input. Assuming some manner of auto flight response, wouldn't that demonstrate operable FADEC? Thinking I occupy no more than a seat in the tenth percentile of posters, I think personally there is clutching at straws. The procuring cause of loss of engine power had to be loss of electrical power. The possibilities are patent beginning in P100 with a fire, in flight test. Then six on board fires, an occurrence the FAA at the time required a single fire onboard was one in one billion for the fleet. I personally believe the emergency batteries ran away due some charging issue.

This bird has switching and glitching issues...

Survivor 11A::: "There was a bang, we felt like we were suspended, the engines began racing, then we hit
Something... " I believe him... His observations suggest our crew managed an attempt at climb, but ran out of room.

I don't really understand this. FADECs don't command the rudder; flight computers do. Flight computers also command the FADEC to increase/decrease thrust for thrust asymmetry protection, not the FADEC doing it itself.

...and it is an express certification condition that the latter cannot lead to the former. Hence FADEC alternators, FADEC powered thrust lever angle resolvers, suction feed etc.

The batteries are basically not used while engine(s) are running.

I can't comment on presence/absence of yaw.

FADEC has nothing to do with flight controls.

Total loss of electrical power should not result in the engines shutting down (absent some other defect like the fuel suction pumps not working).

The consensus of publicly-expressed ostensibly-expert opinion is that there is no asymmetric power-related yaw after take-off but, even if there were due to one engine not delivering 'sufficient' thrust, the other engine should have been capable of delivering enough thrust for the aircraft to climb away.

The consensus of publicly-expressed ostensibly-expert opinion is that the bang and revving heard by the survivor was likely the RAT deploying and revving up.

Everything points to the immediate cessation of motion lotion to both engines, shortly after take-off. If that happened, the question of course resolves to: Why?

And a PS to my earlier post about the schematic in the TCMA patent application: Apparently the TCMA can be triggered even when the thrust lever is not set to idle. There's an envelope of engine thrust delivered compared with thrust lever position, outside of which envelope - 'too much' thrust delivered compared with thrust lever position - the TCMA is designed to trigger fuel shut off to the engine to which it is fitted, provided the aircraft is not in the air. There remains uncertainty as to how TCMA decides whether the aircraft is not in the air. My understanding is that there's a combination of sensor inputs, like the obvious weight on/off wheels as well as RADALT, but I can't find any authoritative statement of what those are and whether just one or both (or all have) to be in the 'in air' or 'not in the air' state to disable or enable the TCMA function.

The fuselage was headed directly away from the camera on the video. The camera was biased to the runway by some angle. The heading therefore would reflect the same angle.

If fuel starvation, one would predictably fail some time earlier than the other. The 777 from Beijing showed a similar close failure on the dry approach to LHR? Not trying to link FADEC to auto flight recovery from OEI. Perhaps the flow of fuel was somewhat intermittent. Perhaps the obstruction cleared at some point, allowing the engines to stop sputtering and regain thrust. Then again, perhaps the RAT was causing the "Racing" sound.... I think the answer is to be found in some simpler solution than cosmic rays, and "vanishingly small" goblins. Fuel starvation of some description...... Lack of fuel pressure, cavitation, blockage, or some more complex issue, of course. Fuel, Air, Compression, Thrust .....
Or, more precisely, Air, Compression, Fuel, Thrust (and Fan)

Complexity fosters Perplexity

Incident: LATAM B773 near Belo Horizonte on Dec 20th 2018, electrical failures

I think this is probably the only unthinkable total power loss on a Wide Body ETOPS Boeing Twin (not engine failure induced) that happened to a LATAM 777 - An amazing demonstration of airmanship from the crew, and a demonstrated design feat of the Boeing allowing the aircraft to continue flying at or near TO weight and then land (albeit heavy) even though they had lost all normal sources of electrical power, and then some ...

357 pax and crew safely disembarked without injury.

It is also worth noting that FADEC is a concept (or system) of many many independent and redundant engine control components from the EEC and Thrust Levers, to the Dedicated Alternators, FMU's, VSB/VBV actuators and so on. They are all independent of the aircraft power sources hence the engines will operate just fine even in a situation such as this.

Edited to add: Refer to the previous pprune forum (https://www.pprune.org/rumours-news/...l-failure.html)

It's been stated that the FADECs have nothing to do with the rudder. That is true for the 787, but it's not always true. The 777 will automatically apply rudder to correct for an engine failure, but only if it knows the engine has failed. It relies on the data coming from the FADEC. That might be the cause of the confusion.

The 787 will do the same but it does not rely on data from the FADEC. It uses the IRS to detect the yaw. In fact, it will correct for anything that causes uncommanded yaw, not just engine failure.

It would seem the discussion has yawed away from a patent fault of some magnitude, a failing or failed generation system and a seemingly unsolved switching resolution. In an aircraft with a known history of failed generators, emergency landings and diversions, not to mention onboard fires, perhaps we are looking through a microscope at an elephant. Gnats eye view as it were ....Does the Rat not drop into the airstream for other than TEI ??

DEI??

Have also stumbled across this one too in relation to AI171. The final report (https://sistema.cenipa.fab.mil.br/ce...DEZ18_Ing..pdf) contains IMO interesting details re Boeing not sharing it's "777 Electrical Power Systems Safety Analysis Document" integrally with the in this case Brazilian investigation due to export policy restrictions in force of the aircraft's State of Design. This document mapped failures of the electrical system and the probability of their occurrence. According to Boeing, the said document had an electrical failure of the kind in this incident assessed as "Class II Hazardous", while its probability was calculated as 9.6x10-8 (a little bit less than 1 in a billion of hours). The Brazilian investigation assessed that taking into account the level of risk, the probability of this type of failure should be less than 1x10-7 (a failure in 10 million flight hours).


https://cimg8.ibsrv.net/gimg/pprune....eff483b85d.png


Coming back to AI171, it would be interesting if a similar power systems safety analysis report that Boeing must have produced for the 787 would have mapped an electrical failure that would have encompassed the loss of trust on both engines (as seems to have occurred to AI171) and if so what kind of risk assessment would have been allotted.

According to the FAA AC 25.1309-1B, at least the "Arsenal Draft" that Boeing referenced in it's 2004-2009 type certification programme for the 787, the condition as apparently shown by AI171 should have been classified as "catastrophic failure" (i.e. "failure conditions which would result in multiple fatalities, usually with the loss of the airplane") and by consequence be assessed as "Extremely improbable" (less than 1X10-9 (1 in 1 billion flight hours).

Given the "export restrictions" cited in the Brazilian 777 electrical failure incident, its IMO unlikely that the Indian AAIB will ever be able to lay its hands on Boeing's "787 Electrical Power Systems Safety Analysis Document"....

Bugbear, please stop with the scattergun approach to this problem.
The other thread was closed due to ridiculous and frankly laughable posts from people who have no idea how complex aircraft systems work.
Let's not do that here eh.

That's a common problem - some of the various documents that get produced during the certification process - System Safety Assessments and Failure Mode and Effects Analysis as examples - contain a great deal of detailed design details that are considered company proprietary and are subject to export restrictions. In fact, after reviewing the documents, the FAA is supposed to either return or destroy them.
I went to Shanghai as part of a team meeting with the Chinese CAAC regarding their approving the 747-8 for use by Chinese operators. We could show them pitch charts, and specify which documents were relevant, but we could not give them hard copies of the presentations or documents due to the export restrictions. Same thing with the Russian authorities (although they came to Seattle instead of our going to Moscow). In one case, they wanted to see a specific fault tree analysis - we were able to copy it from the document and display it on the screen, but couldn't provide them a hard copy (although I wouldn't be very surprised if someone took a discrete picture of the screen while it was being displayed.
In other another case, we provided a copy of the cert document to the Boeing cert office - they were supposed to scrub it as necessary before giving a copy to the foreign authority - but I stopped caring about it after we gave it to the cert people, so I don't know details.

Has there ever been a case of double engine failure of a Part 25 or CAR 4b design on takeoff or initial climb where system failure was the root cause? I can’t recall one.