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?

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.

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

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.

i think yes. Just no indications and no protections?
Anyone with solid definite answers plz :O

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

Can we work with the questions in post # 3? or is more information needed to clarify?

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

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.

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

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.

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.

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 correct 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]

Oh man ....im so confused now.......
and 2 conflicting answers. Will a sim instructor plz stand up ?! :)

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

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

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.

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

I would hope you would :)

PBL

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