I agree, sounds very dangerous and something I never want to experience in my future a a pilot

Indeed not. One of my pals made his name a few decades ago by trying to show when and how one could reduce fail-live to fail-stop (as it is called).

Sorry, reasoning like that just doesn't work. Let's take it step by step.

(a) various values of parameters must cohere for the FADEC to issue a command.

Indeed so, conditions very often satisfied. One can even imagine that the code is such that the FADEC has been proved to have this property when the code retains its integrity and has executed properly (two big assumptions).

(b) these parameters will never line up in an acceptable range when the FADEC [fails in some way].

An enormous amount of effort goes into attempting to demonstrate properties such as this. In practical terms, for real code of size about 100,000 LOC, one cannot do it, although we are getting closer than we were twenty years ago.

(c) thus the FADEC looks to its other channel for help

You hope. Or maybe not, because it doesn't "know" anything is wrong. The two channels may even "believe" they agree with each other, even though both have different real values.

(d) if that is also screwed up, the FADEC drops off-line and you have reduced to fail-stop.

Except when the FADEC "believes" (wrongly) that it is correct and functioning and agreeing, and continues on as before.

I'll make you an offer. Let us carry on with this division of failure into steps. You make suggestions (such as above; four steps); I indicate the difficulties with those steps. You then address these difficulties; I indicate further difficulties with your solutions. You then ..... and so on. Let us suppose we stop after, say, 1000 pages. I have at that point no further difficulties to bring up.

I sell this document to an engine manufacturer. If it really does what it seems to do, I imagine it would be worth something in the order of an eight-figure sum. After all, that is only what an engine costs. You can have 90% of it (you will have done the real work; I will only have run interference).

Will you go for it?

PBL

Of course I wouldn't pay for it if I can already convince the regulators that what I already offer is extremely improbable to screw up.

The numbers don't lie :)

Two points.

First, no one has "convinced the regulators" with any numbers that FADEC SW is "extremely improbable to screw up". "Extremely improbable" is a technical term in certification and is taken to be a probability less than or equal to 10^(-9) per operational hour. The highest you can validate through testing, practically is O(10^(-5)) per op hour, four orders of magnitude too coarse.

This is of course known (although not as well known as it should be). The reliability requirements in certification only apply to HW. DO178B is a "process standard", not a "product standard". It doesn't specify quality of product, but only what steps shall be taken during a development process. It doesn't look as if DO178C will be much different in this regard.

The issue of how one can validate HW-run-by-SW to a high-reliability level when one does not - cannot - validate the SW to anything like that level is a contradiction which people working in the industry just have to ignore. There are even quite a few people working actively on the standards who don't understand the contradiction, let alone take it seriously. It's quite a problem.

Second, you missed my point. Developing a verification suite for any piece of used SW of that size is the Holy Grail for the critical-SW industry, and that is what I described. There is no doubt that a major engine manufacturer would be prepared to fork out such sums of money for a guaranteed solution to the SW verification problem. They have already forked out many times this amount in very partial work along these lines which they believe is somewhat helpful.

But solving the SW verification problem won't solve everything. It won't solve the Byzantine problems described by Driscoll et al. Things won't be perfect, even if the code is guaranteed to be so semantically.

PBL

Hmmm Hardware run by software. To illustrate the point about unpredictable errors:

On November 3rd, 1973 National Airlines DC-10-10 N60NA "Barbara" was flying from San Francisco to Miami. The experienced crew began discussing how the auto-throttle would respond if the circuit breakers for the N1 Tachometers were pulled. They decided to try it, and see what happened.

They pulled the circuit breakers on the N1 tachs for all three engines while in auto-throttle speed mode. Nothing happened.

They then commanded a 5 kt speed reduction, and the throttles reduced slightly, and that was all.

They then disconnected the auto-throttle, in preparation for resetting the circuit breakers, disconnected the auto-throttle and reset the circuit breakers.

On doing this, the right hand engine underwent an uncontrolled overspeed, disintegrating the fan, removing the entire right cowl, severing the hydraulics, electrics and control cables, and penetrating the right hand fuel tank. The debris also impacted the fuselage and the centre engine, punctured the 6th window forward of the S3 door and the passenger seated next to this window was ejected in the subsequent explosive decompression. :eek: :sad:

I see that even the use of smileys in my posts don't show up in quotes :)

Actually the certification standards take consideration of past historical experience in rates.

When new technology comes along like FADECS Then it is reviewed for its likley effect both good and bad and the regulation modified accordingly. Areas of interest in modification are those that are expected to be no better than 10-7 in freedom from risk of catastrophe. Other areas of postulated risk in your fail soft scenarios don't typically show up in the regulated basis. Else the regulatory change process would never get a modification updated in our lifetime.

Sorry, and thanks for the heads-up. It didn't get picked up by my editor, and neither did this one, so I added it by hand.

Your comment is apt, but I can't tell if it is meant to be an addition to the comment of mine you quoted, or whether you are expressing mild scepticism. I'll just say that I am actively involved in certification standards for critical SW and my quoted comment states a problem I have been tasked to rectify in guidelines for the general standard, for its German application. I hope my colleagues will have comparative success with DO178 also.

PBL

Fair enough on the smiley not remaining through a quote (damn software glitch) :)

I tend not to use a lot of words but the smiley was only intended to indicate a devlil's avocate approach for balance to the discussion. The same with my follow up comments.

I also have spent countless hours, days, years in drafting updated regulations, In the end all gets considered, but the time spent in consideration is balanced against about where we think it contributes in overall risk. In spite of this attempt at prioritization it takes years to achieve any kind of consensus.

Hopefully somewhere in all the posts above the orginal question has garnered enough from the discussion to be answered.

Smiley rendering - off topic
 

Not showing smileys is an artifact of the rendering. The usual characters expressing smileys are suppressed, including their spacing, and a glyph is substituted. Putting the cursor around the glyph doesn't pick up the original (invisible) characters, so they don't get pasted into the quote. And the glyph doesn't get picked up because it is not a character. I don't understand the phenomenon completely but it is close to unavoidable, I would think.

PBL

I saw this failure , Fadec A+B fault when I was positioning a while back .
First I heard a loud banging from the engine and the Captain called me into the F/D to give my thoughts .
ECAM keep pinging Fadec A , Fadec B , Fadec A+B ...it was abit confused .
All parameters for the engine were spurious but thrust symmetric and constant as confirmed by Flight controls page , and responded normally to TL's .

Just a personal opinion
 

Some years ago a captain performed a cautionary in flight shut down (IFSD) of an engine on a 320, in result of an ENG 1+2 FADEC FAULT spurious message.

As a fleet manager, I asked him why did he do that, instead of operating normally or at least kept the engine running at idle, as apparently, full engine control was available.

The reply was: “could not be sure of engine condition”.

To me, shutting down an engine when not called by ECAM or QRH procedure, must be based on very solid grounds, and substantiated on erratic or loss of governing capability.

I’ve always interpreted the “lack” of precise procedural action on this case, related to the multitude of possibilities left over for the extend possibilities of the failure itself.

So, to resume my point: if the engine speed can be commanded and no erratic behaviour is present, continue normal operation. If not, evaluate the possibility to operate at idle, if any abnormal is noted, then perform the precautionary IFST,in accordance with the manufactor procedure.

Cheers, C.