Go Back  PPRuNe Forums > Flight Deck Forums > Tech Log
Reload this Page >

FADEC failure

Wikiposts
Search
Tech Log The very best in practical technical discussion on the web

FADEC failure

Thread Tools
 
Search this Thread
 
Old 13th Jun 2010, 07:55
  #1 (permalink)  
Thread Starter
 
Join Date: May 2007
Location: Europe
Posts: 99
Likes: 0
Received 0 Likes on 0 Posts
FADEC failure

For an A320, what happens if both fadec fail for an engine.
According to FCOM you will have no engine indications, but engine runs.
The question is: Do you still have engine control?
TO MEMO is offline  
Old 13th Jun 2010, 16:37
  #2 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
Describe the failure condition.

Typically the FADECs are failed safe. i.e. if they don't trust themselves and their inputs any longer they latch the FCU at the last known trustworthy condition of flight. The pilot always has the option of turning off the fuel if the thrust is too much for conditions.
lomapaseo is offline  
Old 13th Jun 2010, 19:26
  #3 (permalink)  
Thread Starter
 
Join Date: May 2007
Location: Europe
Posts: 99
Likes: 0
Received 0 Likes on 0 Posts
According with FCOM 3, FADEC fail you will have no engine indications (all amber crosses) but engine runs. One must use the ECAM system pages, such as hydraulic and bleed to confirm that engine is operating. It also states that if the engine is not operating, you should set master switch off.
But it has no further gidance for "if the engine is running".

So lets suppose that you have ENG 2 FADEC A FAULT. Later inflight fadec B fails also. So you end up with ENG 2 FADEC FAIL. You have all amber crosses and you know the engine will not quit just because you lost FADEC.

The question is: Is the engine responsive to Throttle lever movement?
Is there any relationship between TLA and the engine HMU? If not possible, that would mean cutting the engine for descent.

Cheers
TO MEMO is offline  
Old 13th Jun 2010, 23:34
  #4 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
My understanding is that the engine will not be responsive to throttle (a schematic would probably show this). Anybody?

If it's a single engine failure then yes to cutting the engine for descent.
lomapaseo is offline  
Old 14th Jun 2010, 00:43
  #5 (permalink)  
 
Join Date: Apr 2010
Location: in the flight deck
Posts: 89
Likes: 0
Received 0 Likes on 0 Posts
i think yes. Just no indications and no protections?
Anyone with solid definite answers plz

Last edited by Neupielot; 15th Jun 2010 at 02:32.
Neupielot is offline  
Old 14th Jun 2010, 03:49
  #6 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
The original question "what happens what FADECs fail?" is ill-posed.

They can fail because the units fall off the airplane. In that case, there is unlikely to be anything resembling engine control.

I am guessing that TO MEMO really meant something like the following: what can you expect in the way of functioning engine control if you see such-and-such an ECAM message?

Could one maybe rephrase the question in this form? That way, it is likely to have a definitive answer. If not, then not.

PBL
PBL is offline  
Old 14th Jun 2010, 12:00
  #7 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
PBL

Can we work with the questions in post # 3? or is more information needed to clarify?
lomapaseo is offline  
Old 14th Jun 2010, 12:10
  #8 (permalink)  
 
Join Date: Jun 2010
Location: england
Posts: 64
Likes: 0
Received 0 Likes on 0 Posts
you are still in control of the plane but have not readings and are unaware of position and altitude
the plane can be controlled if you are a good guesser
notify the ATC immediatly and wait for further instuctions for gliding to an airport
A321COBI is offline  
Old 14th Jun 2010, 12:47
  #9 (permalink)  
 
Join Date: May 2000
Location: Glorious West Sussex
Age: 76
Posts: 1,020
Likes: 0
Received 0 Likes on 0 Posts
If both FADEC channels on one engine fail, the FADEC can no longer control the thrust. Nothing else will either.
ECAM:
T/L.... IDLE
ENG PARAMETERS...CHECK (as described above) I suggest also look at the rudder trim position?
IF ABNORMAL shut it down (which I assume means not at idle?).

If ECAM presents FADEC FAULT caution it might just be spurious - which you can determine from the presence/absence of indications.
TyroPicard is offline  
Old 14th Jun 2010, 14:16
  #10 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by lomapaseo
Can we work with the questions in post # 3? or is more information needed to clarify?
Much more information is needed to clarify, probably more than anyone here has.

There are, say, about 100,000 lines of source code (LOC) in typical FADECs on a modern engine. The highest quality level known to have been attained in code for a critical system is about one error in 25,000 LOC, and more typical quality levels are of the order of 1 in 1,000 LOC. So you can expect a few to about a hundred errors in FADEC code. Now, you can't tell what executing code through those errors is going to do to the behavior of the FADEC. The manufacturer has to have performed an appropriate a hazard analysis. That will presumably demarcate what kit behavior the FADEC can possibly influence and what not.

Such a failure may or may not raise an ECAM message. Tyropicard says what happens if you lose both channels, assuming a fail-stop scenario. With a fail-live scenario it could be different.

That is the glory of digital electronics. It makes hazard analysis extremely hard, indeed in many cases combinatorially infeasible.

PBL
PBL is offline  
Old 14th Jun 2010, 19:16
  #11 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
PBL

Such a failure may or may not raise an ECAM message. Tyropicard says what happens if you lose both channels, assuming a fail-stop scenario. With a fail-live scenario it could be different.
well now that you have introduced the term fail-stop scenario and fail-live scenario could you tell us the difference relative to what gets displayed on the screen to the pilot? because that's all he knows regardless of what you call it.
lomapaseo is offline  
Old 14th Jun 2010, 19:35
  #12 (permalink)  
 
Join Date: Mar 2007
Location: Here and there
Posts: 2,781
Likes: 0
Received 1 Like on 1 Post
I had a dual fadec channel fault in the sim a number of years ago shortly after a colleague had experienced this on the line. The engine failed with no ecam activation.The other unforeseen consequence was the beta target was not available so it was back to dead foot dead engine.
tubby linton is offline  
Old 14th Jun 2010, 19:35
  #13 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by lomapaseo
well now that you have introduced the term fail-stop scenario and fail-live scenario could you tell us the difference relative to what gets displayed on the screen to the pilot?
No, I can't. There is no oracle which is telling you in reality how the system failed. There are only failure behaviors. The issues are way too complex for a short message on a general-interest bulletin board.

Besides the issues of correctness of code, there are others. Here is a fundamental paper describing some of them: Driscoll et al on Byzantine Failures. Kevin and Ken Hoyme (who no longer works in the industry) are the designers of the Boeing 777 AIMS.

Notice that the authors say that a major commercial aircraft was within days of losing its airworthiness certificate. Indeed, when one knows which aircraft this was, this would have been very serious indeed.

PBL
PBL is offline  
Old 14th Jun 2010, 19:40
  #14 (permalink)  
 
Join Date: Jun 2010
Location: england
Posts: 64
Likes: 0
Received 0 Likes on 0 Posts
PBL is correct
far to complex for a general-interest bulletin board
the inner workings are confusing and cannot be simply explained and often dont even make sense
This is something you learn of in pilot training [which I did]
A321COBI is offline  
Old 15th Jun 2010, 02:35
  #15 (permalink)  
 
Join Date: Apr 2010
Location: in the flight deck
Posts: 89
Likes: 0
Received 0 Likes on 0 Posts
Oh man ....im so confused now.......
I had a dual fadec channel fault in the sim a number of years ago shortly after a colleague had experienced this on the line. The engine failed with no ecam activation
and
ECAM:
T/L.... IDLE
ENG PARAMETERS...CHECK
2 conflicting answers. Will a sim instructor plz stand up ?!
Neupielot is offline  
Old 15th Jun 2010, 08:40
  #16 (permalink)  
 
Join Date: Oct 2009
Location: UK
Posts: 1,270
Likes: 0
Received 0 Likes on 0 Posts
Hi Neupielot,

This problem highlights one of the drawbacks of being a "slave to ECAM".

If you have an engine failure with a FADEC 1 (2) Fault, then you have to diagnose the problem by being a pilot and look at how the aircraft is performing, investigate other systems pages, recognise that you have an engine failure and I would suggest the simplest solution is call for the QRH "ENG 1(2) STALL" which say:
T/L.... IDLE
ENG PARAMETERS...CHECK
If Abnormal
- ENG MASTER (affected engine) ....Off
Initially there is no ECAM procedure for this problem, but once the Engine Master is put to off, the Rest of the ECAM procedure will be displayed.
rudderrudderrat is offline  
Old 15th Jun 2010, 09:39
  #17 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Contrary to what I suggested above, let me indeed try to put a little more meat on this issue. For it seems to me that discussants still imagine they can figure out definitively what happens from some entry in some manual somewhere.

Fail-stop means the channel goes dead. No traffic. Tyropicard's contribution said what happens then.

Let's consider fail-live.

If your FADEC sends the signal to reduce fuel flow, your engine is going to idle back.

If your FADEC sends the signal to send fuel flow to max, your engine is going to go to max thrust.

If the FADEC sends oscillating signals to put fuel flow at min, then at max, then at min, then at max,.... with a frequency of X Hertz, then ..... well, somebody who designed the system can maybe tell us what your engine is going to do. Does it depend on the value of X?

Then there are the infinitely varied other signal behaviors that can occur.

PBL
PBL is offline  
Old 15th Jun 2010, 16:34
  #18 (permalink)  
 
Join Date: Sep 2002
Location: La Belle Province
Posts: 2,179
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by PBL
Let's consider fail-live.

If your FADEC sends the signal to reduce fuel flow, your engine is going to idle back.

If your FADEC sends the signal to send fuel flow to max, your engine is going to go to max thrust.

If the FADEC sends oscillating signals to put fuel flow at min, then at max, then at min, then at max,.... with a frequency of X Hertz, then ..... well, somebody who designed the system can maybe tell us what your engine is going to do. Does it depend on the value of X?

Then there are the infinitely varied other signal behaviors that can occur.

PBL
Well, for the first two, that somewhat assumes that this strangely failed FADEC is going to continue to respect the scheduled limitations for idle and max fuel flows respectively. I wouldn't put a whole lot of hope into that, personally. A run down to stop or a runaway to firewall and beyond sound just as likely to me.

The oscillatory behaviour sounds a lot like a bode test, something done to certify engine response. usually that's constrained by input dynamics (how fast can you slam the throttle back and forward?) and by input signal filtering. With neither a constraint here, there's no guarantee anything good might happen. And, again, who says it'll stop at idle and max thrust levels.

I agree 100% with the last sentence, and the sentiment you expressed earlier regarding the difficulty of even the designers understanding failure modes in complex systems, never mind trying to reverse engineer it from a very cursory descripotion in an AFM or operating manual.
Mad (Flt) Scientist is offline  
Old 15th Jun 2010, 17:03
  #19 (permalink)  
PBL
 
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Mad (Flt) Scientist
Well, for the first two, that somewhat assumes that this strangely failed FADEC is going to continue to respect the scheduled limitations for idle and max fuel flows respectively. I wouldn't put a whole lot of hope into that, personally.
MFS, I wouldn't suggest this is likely. I don't think any failure behavior is likely, otherwise the FADEC wouldn't be certified.

The point is that the FADEC is driven by program code. One output is a max-it! signal. Another output is an idle-it! signal. They are generated by execution sequences (paths through the program) which come from max-it! inputs and idle-it! inputs respectively. But how does one know they only come from those inputs? The third example is of a behavior which likely cannot be produced by a valid (intended) execution path through the program. But there are those invalid paths as well, very likely.

For programs of, say, 100,000 LOC, one mostly doesn't know that for sure, even if one has done a lot of checking. The company which produces the demonstrably highest-quality code in critical systems has never produced a completely error-free program of a size over about 10,000 LOC, although they regularly produce larger programs that are demonstrably free of run-time errors (data going out of bounds, and so on).

And as for a likelihood that things will be OK or not, there are no statistical techniques which are trustworthy and which will enable you to predict it, when the likelihoods are as low (for failure) as required for critical systems.

My example was only intended to show those who think that computers are like car brakes: if things don't work right, there are only a small number of ways it can have gone wrong, so you check all those out and sure'nuff you find the problem. With computer code of 100,000 LOC, if things don't work right, there are more ways it can have gone wrong than there are atoms in the universe.

And that is only code errors. If one worries about so-called Byzantine failures (see the Driscoll reference), then the outputs cannot be necessarily regarded as the output of any execution sequence through the FADEC program at all.

In other words, people who answer this is going to happen when your FADEC fails are either giving very incomplete and thereby not necessarily very useful information, or are giving precise answers under restricted conditions (Tyropicard), or just don't understand issues well enough to hedge their answers with appropriately restrictive conditions. I'll leave it to others to classify the answers so far on this thread!

It may be that certain restricted conditions cover a majority of actual failure cases. If so, may I suggest it would be wise to say "your FADEC failure is likely to be of this-and-this type, and such failures may be indicated/handled this way......"

Originally Posted by Mad (Flt) Scientist
I agree 100% with the last sentence, and the sentiment you expressed earlier regarding the difficulty of even the designers understanding failure modes in complex systems, never mind trying to reverse engineer it from a very cursory descripotion in an AFM or operating manual.
I would hope you would

PBL
PBL is offline  
Old 15th Jun 2010, 17:20
  #20 (permalink)  
 
Join Date: Mar 2002
Location: Florida
Posts: 4,569
Likes: 0
Received 1 Like on 1 Post
PBL

Let's consider fail-live.

If your FADEC sends the signal to reduce fuel flow, your engine is going to idle back.

If your FADEC sends the signal to send fuel flow to max, your engine is going to go to max thrust.

If the FADEC sends oscillating signals to put fuel flow at min, then at max, then at min, then at max,.... with a frequency of X Hertz, then ..... well, somebody who designed the system can maybe tell us what your engine is going to do. Does it depend on the value of X?

Then there are the infinitely varied other signal behaviors that can occur.

PBL
OK, now you have explained what you mean by the live and and failure modes

So in the dead mode the results and expected response by the crew are then obvious.

The fail-live mode sounds like a horror story for the crew so we really don't want that.

But there are various parameters that need to be satsfied for the FADEC to issue a command to the engine and suposedly these parameters will never line up in an acceptable range when the FADEC loses all sense of reason, thus the FADEC looks to its other channel for help and if that is also fecked up the FADEC just drops off the line and you are back to fail-dead.

I don't think that we can imagine a computer response named "Hal" in any case
lomapaseo is offline  


Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.