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