PBL,
I think BOAC get it very well.
Understand, the voting system is not at stake.
And Please, forget about the 5 sensors, far enough complexity already, simplicity taste much better.

The all issue is that the vote is transparent to the pilots, and this is wrong.
Keep the guys in the loop !

CONF iture

As I see it, the simplest method of keeping the pilots in the loop would be a separate algorithim monitoring discrepancies between all AoA sensors on an Error/Time basis. Side slip errors should reasonably be accounted for, and even if you were to get an occasional AoA disagree warning in that situation, you at least get the option of being the judge and jury.

It is a while since I have read this sort of research, and I have only skimmed the references tonight, but I think I can explain the discrepancy. I am sure PBL will correct me if I have misunderstood (and any correction is welcome).

The general result is 3m + 1 redundancy to cope with m failures, however Lamport also showed that this could be reduced to 2n + 1 (this is PBLs "5 sensors") for digital systems, if the values are cryptographically signed. That makes it impossible for a faulty processor to corrupt a value and pass it on without the change being detected. Consider the byzantine generals form the analogy communicating by emails with digital signatures - the traitors cannot corrupt what they pass on.

The proof is at the very end of Lamports paper and the discussion is a bit limited (looks like the sort of thing you add into a paper then end up almost cutting back out again in order to get within word/page limits) - there is almost more on it in his comments on the page pointing to the paper.


For what it's worth, my own take on it is that there probably were, and are, people who are aware of and understand these results, at both A and B, and the level of redundancy is designed in knowing its limitations. Triple-redundant design is really only there to cope with a single failure, which in most cases it can. Chance of single failure is then supposed to be made small enough that the chance of uncorrelated double failure is acceptably low.

What bites us then is the correlated / common-mode failures. Same frozen fuel in the pipes to both engines, all static ports taped over, all pitot ports sticking into the same ice etc.

More redundancy doesn't solve these kind of issues.

Going back to the incident under discussion, how much AOA redundancy would you really need to prevent it ? PBL has raised that 5-way at least is needed for two failed (misreporting) sensors, but is that enough ?

My take:

1. the dodgy aircraft washing corrupted 2 out of 3 sensors
2. assume that failure rate carries on across the aircraft, however many sensors we have (reasonable ?)
2. therefore we have to cope with m (lying sensors) = 2/3 * n (total sensors)
3. we also know that n must be >= 2m+1

So we need to solve: n >= 2m +1 where m = 2n/3 (oh, and n > 0)

Good luck with that one.

Couple of questions (being as I am more on the sliderule side of things...):

- given the test being conducted, shouldn't the tailplane trim be entirely expected ? Isn't the whole point of the test to reduce the speed so the a/c pitches up to hold altitude (on A or B) right until the envelope protections kick in (A) or stick shaker (B) ?

- or put another way, how would you / could you do this test without the a/c trimming up ?

- and if the trim was expected, surely recovery with that trim would have been planned ? [ assuming you plan for a test failure... ]


Also, I think that from other posts you think the a/c should have flagged "AoA disagree" or similar, at an earlier stage ?

Presumably that's on the basis that you wouldn't test (or would abort test of) AoA protections when faced with reported AoA disagree, right ? ... but then, you wouldn't conduct a lets-see-if-we-can-stall test at 10k less than specified altitude, right ?

[ Note that I'm not at odds with the idea of flagging the disagree, just not sure it would have made any difference here ]

If the AoA sensor disagree had been flagged, then at least the "question" would have been raised about the desirability of doing what they did.

mm43;
Perhaps but I would like to offer a thought: How far does such a regression continue for similar problems and their cockpit indications and the "expected" pilot response, especially in line operations?

The Report already suggests that this "test flight" was not a requirement of any law and was an informal arrangement; the flight was being conducted as a Test Flight but the crew was not familiar with the procedures and didn't adhere to the Airbus test flight requirements.

Some have already said that the Airbus approach is too complicated, that the stream of cautions/warnings when something goes wrong can already overwhelm. As a few have observed, in ordinary line ops, two malfunctioning AoA sensors would not have made a difference to bread-and-butter flight. I agree.

The question about the desirability of doing what they did was raised the moment they reversed their decision to do the Alpha exercise on the way to Germany, and instead elected to do it below 3000ft while on final approach. Nobody among the seven participants raised the question.

Under such decision-making processes, how many dozens/hundreds of other aircraft system abnormal-performance circumstances should be covered before it is enough? What system could be the next "culprit"? Not disagreeing or agreeing with anything suggested but asking the question.

Someone else mentioned pitch problems and trim being the first thing to look at - the motion of the trim wheel in the A320 is easily seen; the wheel is very easy to roll forward or backward and it changes the trim quite quickly. I can't recall if the report addresses this possbility for a potential recovery.

infrequentflyer789;

Thanks for taking a moment to contribute. Perhaps its best to leave it at that unless of course corrections/edits are needed.

CONF iture;
A very important point is being missed here and I disagree with you that the point has been understood...some are not getting it, or if they are, they're saying, "yes, but..." and ignoring the implications of the question.

Without addressing the very issues raised regarding this set of circumstances, how do you propose to "keep the guys in the loop"? What is the "correct" infomation and how is it obtained?

Further, you urge keeping it simple and then ask for more complexity to be loaded onto the pilot. If not this system which it is proposed "has a warning", which next system requires the same, to accomplish the same purpose? How does the designer make that decision and why?

My question to mm43 above applies equally to your suggestion. How much and how far would you decide to "keep the guys in the loop!"; what would be the ECAM actions or aircraft restrictions and upon what would such outcomes of such failure be based?

Given the complexity of such systems as flight controls, engine control and ELAC/SEC/FAC or PRIM performance to name just a few, the same claims (keep the guys informed) could be made for many cases in flight near/at extreme performance limits - a place where no line crew has any business being. What then, are the arguments in this case for increasing complexity of warning presentation, analysis and appropriate response for the crew? At some point downstream, the complexity of training and ensuring high standards of response must be considered. Airbus already hides all Class 3 Maintenance messages, the fault-message inclusion of which I'm sure was an engineering decision based upon a failure mode analysis.

I think that is why the discussion took the turn it did...because it is more relevant than we thought, it isn't that simple and perhaps under line operations perhaps for these reasons, isn't necessary but understanding why, is important.

The goal as you say is to keep it simple. Perhaps this is exactly what is happening.

PJ2

infrequentflyer789,
As the test conducted is based on AoA data, I would positively assume NOBODY would carry on, even at 14000 feet, if the system was clearly advising that AoA sensors do not agree.

Page 29 is a good reading regarding your question on the trim.

PJ2,
Thanks for your comment ... I'll have to come back later.

An expert system-concept
 

PBL
Actually there is another more reasonable way to cue the crew (and the flight control computers) that something is amiss.

How did the BEA determine that the two AOA sensors were frozen? Simple-they were not changing after the aircraft reached altitude.
There are a multitude of ways to cross check instrument indications and to alert the crew that something is wrong. In the case of AOA, airspeed vs AOA checks, AOA variation over time, test control inputs, noise in the AOA signal, and no doubt many more checks that I haven't mentioned. In the old days with single indicating systems, a prudent pilot was always questioning what he was being presented.
These same methods can be used to check a whole range of indications for validity. Would AF447 have been lost if there were an expert system monitoring the airspeed indications and noting that all 3 indications appeared to be bonkers just from an energy balance standpoint? Suppose both the computers and aircrew were advised that something was wrong with all three airspeed signals? Would that have made a difference in the outcome? (I know, sheer speculation at this point).

Voting algorithms still have a place for sorting out the best information to use of 3 inputs on modern airliners but are essentially defenseless against common mode failures.

An expert system to monitor the system inputs would not be a part of the core flight control system. If it were, it would slow down the process and make the problems of certification of flight control software an order of magnitude more complicated.
The expert system would be an add-on system which would have to be integrated into the total aircraft system. Its purpose would be to look for anomalous input data using a wide range of screening methods. It would then apply a confidence factor to any critical information being input into the flight control system. If the confidence factor in any critical input was too low, it would not be used for flight control, and the system would degrade as necessary to maintain control.
I do not expect such an expert system to be retrofitted into present aircraft, at least not anytime soon, but I believe such an approach promises a reasonable way around the voting algorithm limitations problem.

infrequentflyer789 - a quick look only, and I'll come back with more time to your queries, but just to say that I am trying to isolate HF here - there were obviously big issues in that department - but am looking primarily at how crews can/should be notified when a system which is at the heart of the protections built into an aircraft has malfunctioned such that the protections are not there. This purely as a pilot now - my 'engineering days' are well behind me.

Again leaving HF aside, it has been argued that the RadAlt #1 failure on the AMS 737 should have been more readily flagged to the crew - the 'subtle' inference of the failure was not appreciated by many 737 operators. This may, of course, have been addressed by changes in emphasis during training. As said above, we do not know what was or was not 'flagged' to the AF 447 crew.

- I still take my slide rule out of its dusty box occasionally and AMAZE my sons and grandchildren - "you did what?!!!":)

Machinbird,

I think there already are expert systems monitoring aircraft "looking for anomalous data using a wide variety of screening methods": the pilots. Like any other system they have limits and in this case they were exceeded. Their 'diagnostic bandwidth' was occupied/unavailable.

It is comparatively easy to take an example like one working and two frozen probes and figure out some logical/procedural way of discounting the false readings, specific to this actual failure mode. What is not easy (or indeed possible in our current understanding, as PBL points out) is to have a process which will always return valid data when 2 out of 3 of the inputs are misbehaving in some way.

The other point is why not have some sort of alert such as "AOA DISAGREE", which has been suggested in this discussion? Given the above, unless you had a forest of probes all over the aircraft, connected to a server farm in the hold, you're going to get that message as soon as there's the slightest difference between any of the sensors. Also, the QRH would probably say something like: "Lack of and/or false stall warnings may be experienced...", amongst other things. Would it have made a difference in this case, as other warnings were disregarded/went unnoticed?

I agree with NoD in that I can't see a pressing need for a change in the aircraft systems in relation to this accident. They performed as per the manual. The crew put themselves in a position where recovery from a manoeuvre was in doubt, by overriding safety limits and being apparently unaware of the secondary effects of what they were attempting, e.g. trim. They did receive a message to check the weight, which should have led them to question some of the speeds displayed but this was ignored due overload.

This is a very interesting accident from the HF POV, where there was a "crew" made of 1 FO & 2 captains who, under what appears to be considerable commercial and time pressure, elected to follow a path which ultimately led them to disaster. A lot to learn, here.

The 'traditional' method of conducting stalling tests is to establish a computed (I do not mean electronically) stall speed. No further trim movement is then applied once this speed plus xxx kts is achieved TO AVOID EXCESSIVE tail trim which could hamper the recovery. I do not know how you would achieve this on the 'bus, but I assume it is built into the airtest schedule.

Agree on all of that, but we are straying into HF and my point is that the choice was not presented clearly to this crew. Regarding altitude, this is outwith this discussion here, since a major upset would have taken place at any altitude.

Fullwings - I think machinbird had all your points covered?

'Actually there is another more reasonable way to cue the crew (and the flight control computers) that something is amiss' - the point is that the evidence was staring the FCC/ADIRUs in the face - they just 'didn't really' make an issue of it.

'a process which will always return valid data' - not demanded?

'An expert system to monitor the system inputs would not be a part of the core flight control system. If it were, it would slow down the process and make the problems of certification of flight control software an order of magnitude more complicated' - an acknowledgement that we are way off this target. MB's 'expert system' is acknowledged to be way in the future.

'In the old days with single indicating systems, a prudent pilot....' - I have several instances in my flying career where this happened, and my multi-function algorithms rejected the suspicious data. We have way to go to get software as intelligent as the human mind (E&OE excepted, of course). Take away the perceived need for intelligent analysis because 'this system is perfect and will look after you' and the walls (and aircraft) can come tumbling down. Oh dear - I'm into HF...................:)

Still carry a small circular version almost daily - to prove that the Supermarket is trying to screw me with the " Specials ". iPhone ? Wot's that ?

Slide Rule ?? there's posh for you. Once had a Flt. Eng. who sat there in flight completing his log with a Chinese Abacus.

Knew how to use it, too.

( sorry, thought it was about time for a short break )

Howdy all. So much emotion in the thread and induced in me by this accident , and most especially the comments about AA965 Cali crash of 1995, a tragedy I am very familiar with.
Where to start in my first post here.
What a complete shame the waste of lives aboard the doomed flight and the sorrowful impact on the lives of those related to the crash victims, as well as colleagues of the flight crew.
Have waded thru many fatal crashes/investigations since I began flying way back in 1968 at age 15 in PA-28's to retirement just over 2 years ago from the left seat of the B777.
Having read thru the entire thread and most of the official reports, I suppose as good a place as any to start would be the last interactions with ATC the crew had. I have read some potshots taken at ATC in some of the posts and the perceived lack of cooperation of ATC with the requests by the crew in flight. No need to rehash the option the crew had of properly filing the type of flight plan they perhaps may have intended to apparently haphazardly attempt.

So I start with....
I don't recall reading any comments about the Captain's outlandish (IMO) behavior and outright disregard of the direct request/instruction/directive of ATC regarding speed assignment during their descent....

At 15 h 33 min 34, descending to FL 130, the crew contacted Perpignan
Approach. They were cleared to descend to FL 120 towards the PPG VOR. The
approach controller asked them to reduce speed to 250 kt and to plan a hold at the PPG VOR. They were number two on approach. One minute later, the crew requested radar vectoring. The approach controller asked them to turn left on heading 090 and reduce speed to 200 kt.

The controller instructs an additional reduction of 50 knots in about a minute, suggesting to meshe may be getting a little pressed somewhere for traffic separation for whatever reason.

Then about 5 minutes later....

"At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt."
So far, nearly 6 minutes to reduce speed to 215 knots?? I know, whats the rush, let that controller fly his desk and radar, us pilots, we got the responsibility and the heavy metal.....

Note that: " At 15 h 36 min 47 s, the airplane was level at FL120."
Is the A320 so slippery that even at say VNE and level at FL120 it would be a task to slow to 200kts in a little over 2 minutes?

At around 15 h 39 min, the approach controller asked the crew to descend towards flight
level 60. The airplane was then slightly below flight level 100 and its speed was 215 kt.

At around 15 h 40 min, the approach controller asked the crew to turn to the right on heading
190 and to maintain 180 kt. The Captain made a right turn. The airplane speed was 215 kt.
What I am seeing here is a pilot who just is not going to cooperate and fly ATC IFR directed speed. As in, "Don't bother me, I have more important stuff to do than help YOU (controller) with your separation duties". I seem to recall that the rules give a pilot plus or minus 10kts from assigned speed, maybe my memory is faulty.
So the intrepid pilot TRE! and crew continue...
"The aeroplane reached 5,000 ft altitude at 15 h 42. Its speed was then around 210 kt".
At 15 h 42 min 14, the approach controller asked for the aeroplane’s speed.
The Co-pilot answered initially that it was falling, then at 15 h 42 min 25 said
that it was 180 kt. The aeroplane speed was then slightly above 190 kt and the selected speed went from 180 kt to 157 kt. The approach controller asked them to maintain 180 kt and to descend to 2,000 ft.

They then did their fateful controlled deceleration to about one half of the assigned 180 knots w/o even the slightest consideration of informing the controller, after all she might have been just another "empty kitchen". I don't suggest that was the Captain's opinion of said controller. But his "who cares" attitude of slowing to requested speeds, then halving his assigned speed well outside the IAF w/o communication with ATC.... did he know that there was no IFR aircraft behind him that might be affected by his speed reduction? Any disregard for rules and common sense/courtesy beginning to be displayed here??

Won't begin to address the unbelievable flight situation he then quite voluntarily and seemingly non-chalantly dived headlong into; in an aircraft he was supposedly immenently knowledgable of and skilled in flying from A to B in all weather, day or night and surely well aware of the many dizzyingly frenetic flight law changes he was about to encounter which would snuff his and 6 other lives and affect so many more.

For ExSp33db1rd

Electronic Chinese Abacus

PJ2,

I did? Deary me! Not any more.

Somehow I was thinking (3 x n) +1 = 5 when n =2. Maybe it was when I wrote it, but it's not any longer. It's 7, as Kevin said.

It makes the point stronger.

infrequentflyer789 saw how to rescue me (very gracious!) but truth is it was a cognitive slip. Yes, Leslie points out that you can use digital signatures to reduce the number, but no one trying to build Byzantine-failure-tolerant devices is trying to do that.

The issue being batted around here is more or less as follows. Trying to be completely fault-tolerant (of Byzantine faults as well as others) is currently not on. There are a couple of busses which are being designed to tolerate special classes of Byzantine faults, but they are at the research level. So the question is: what kinds of fault can be tolerated using existing methods?

And here the danger is that one collects a list of phenomena, and says: we can tolerate this one like this, and this on like this, and ....... and here are two AoA sensors which are frozen, and we can tolerate this situation like this, and ..... and one ends up with a list without rhyme or much reason. It is possible to do each one after the other. But one is continually shutting the door after the horse has bolted, and the next door will not be where they have already been shut. That is no way to design fault-detecting or fault-tolerant systems.

What is needed is a description of a class of phenomena and how they are to be tolerated. Or many classes, and their mitigations. And I don't see that yet arising out of this discussion.

PBL

You'd want stronger evidence to fire an automatic protection than for sounding a warning.

Further, I think it would probably help some readers a lot to read PBL's posts replacing the word "algorithm" with "rule".

For example, if you decided to treat no change as evidence of failure, how would that work in the cruise with a sensor that fails in such a way as to start producing random readings, or to diverge from the facts steadily? Such a rule would be defeated by what might be the most likely non-obvious failure case (a/c in the cruise and therefore maintaining a steady AoA, one or two units fail actively). Obviously there'd be some change, but even a functioning-but-frozen unit would be expected to have a noise term.

It seems that PBL has already posted an objection to the "Expert Computer" concept. I guess I'm reading too slowly to keep up with all the twists and turns.:}
The key to the expert system is a cross checking of data types, not just comparing identical data types. Much better resistance to common mode failures this way.
Quote:
Originally Posted by atakacs
... is there some "über"computer checking in real time that all sensor readings are within reasonable value respective to each other, and provide a clear ECAM message if not ?

So in response to this objection, let me propose an architecture that perhaps makes sense.
Two computers-physically separated in the aircraft, reading the identical inputs and performing identical calculations on the data using the "expert knowledge base". Any discrepancy in outputs causes the system to disconnect from the system and advise the crew. Result-reversion back to basic Airbus that everyone is familiar with. How the information is presented to the aircrew is important to avoid over-reaction/under-reaction. This will require significant development work, but should result in usable advisories to the crew.

FullWings
In the old days, you had one altimeter and one airspeed to look at. Today when you look at these indications in a modern aircraft, you are looking at a computer selected presentation of multiple identical sensors as chosen by the computers. If the crew's "diagnostic bandwidth" was exceeded (which probably isn't too hard in today's complex aircraft), it is an indication that they could have used some help.

Supposing an expert system noted that there was a discrepancy between gross weight and AOA or between airspeed and AOA. First it could observe the output of the 3 AOA sensors and note that two of them didn't make sense in the context of airspeed and gross weight. Next it could observe the output of the sensors for a change in output and if the same two sensors that seemed aberrant before showed no change, it could advise the crew of a possible AOA malfunction involving two sensors and request a small test maneuver. If still no response by the two affected sensors to the test maneuver, then they would be locked out of the control system and the crew would either be advised or would authorize the lockout. Result-the one remaining good AOA sensor is used for all AOA inputs. There is no reason that similar procedures could not be applied to all sensor data.

Did they ? ... report is not that affirmative.

Also, Appendix 18 mentions that such message would not ensure that line pilots will become aware of the fact the lower indicated airspeed limits are inaccurate.

What was needed is a clear AOA DISAGREE ECAM MESSAGE and there is absolutely no complexity to be added for such message to be triggered as the system has already been through the necessary analyze to SILENTLY unvote one ADR.

- let's take that one stage further. The more I look at this the more stupid the AB 'protection' algorithms/rules/ whatever you want to call them appear.

The system 'knows' that the AoA of the 2 sensors is incorrect v IAS and weight. Supposedly it asks the crew to 'check the GW'. Maybe it does, maybe it doesn't; maybe they do, maybe they don't. With a Gallic shrug the system now ignores this anomaly and also 'ignores' the fact that 1 sensor is well past the point at which 'protection' would normally have been triggered. What does it do? NOTHING. Not a peep. Aviation has in all my time worked on the assumption that given 'choices', it should be the safest option that should be chosen. Not by AB. "We will ignore this fact". "2 outvotes 1 and that is that". As far as 'protection' is concerned, we effectively have here a torn condom (French letter?).

OK - we all accept this is an 'oddball' occurrence, unlikely to re-occur in normal operations. BUT the thing that bothers me as a potential AB passenger, and should be worrying the AB crews, is how many other 'protection' software systems use the same policy? Let's seriously hope they find AF447.

PBL;

Thanks for your response. I wasn't at a point of understanding so as to know whether it was "5" or "7" (or "21") and naively asked the question using Kevin's work. The important point is made, which is, it isn't possible to resolve this failure without the quality of thought and perception understood as "discernability"...a computer cannot "discern/decide" as such activity is not an algorithm. I am not familiar with the technical terms which might be used to describe this but one might view this quality as a "gestalt"....computers cannot "gestalt", they can only do zeroes and ones at extremely high speeds without anticipatory or recollective powers of perception. For me that's one way of putting it - I'm sure there are others.

So, (to Machinbird's point), one altimeter, one airspeed indicator, etc etc "worked" because discernability/decideability was not a problem; the pilot decided, (for better or worse). I'm not sure the problem highlighted is so much a "bandwidth" problem as a discerning/decideability problem. I think this is true because, as others have said (and I agree), the failure of two AoA sensors would be a non-issue for a line crew, (and this may indeed have been the thought process behind not including such failures in warnings to the crew...who knows?). In these specific circumstances, a line-crew would have all the necessary indications for successfully completing the flight.

I wonder what the ACARS maintenance messages were, if any, regarding the AoA's? Notwithstanding the low risk to normal flight, surely two u/s AoA sensors would be NO-GO.

PJ2

PJ2,

a major issue is: looking at discrepant readings from multiple sensors, and deciding which of them are more or less the same and which of them are more or less different.

I believe you are right that this is a form of "gestalt" and that you are equally right that there are hard technical results that say that this cannot reliably be performed in general with fewer resources than 3n+1 (or fewer if perfectly-reliable digital signatures are assumed, as pointed out by iff789).

Machinbird has put a lot of thought into his architectural construction, but what is missing is the crucial insight that you can't "climb the ladder" to get out of the constraint. 2 systems is about the worst one can propose: you can't tell which one is right and which one is wrong, and if you dump the data on the pilots to decide, that is the worst possible scenario for them: debug and decide on the fly. Better have three. Then, when it goes wrong (two of them are wrong but agree, as with the Perpignan AoA sensors), the pilots get even more data dumped into their laps and have likely even less chance of sorting it out. And so on.

The Perpignan pilots had, according to the BEA, data "dumped into their laps" which we, sitting in our comfortable chairs before our comfortable computers with a pleasant glass of 2009 Josephshöfer Riesling in our comfortable hands can easily see from the BEA report were anomalous.

Tom Sheridan at MIT researched such issues, and Dave Woods (who proposed the concept "mode confusion") et al. has shown how this work applied in detail to aeronautics, and people such as Sidney Dekker have carried this further. Summary: you can't dump the system state into operators' laps and imagine they can save the day. They mostly can't.

It's between a rock and a hard place. Had someone said, before the Perpignan accident "you know, if two AoA sensors agree, falsely, then it is probably because ...... and we can handle it with ......." and persuaded everyone to go along, then that crew would have been saved. So let's consider doing that. Everyone predict the next twenty type-XXX accidents, suggest the obvious ways they could have been avoided, and write a letter to the manufacturer of type-XXX suggesting they implement those countermeasures.

If you think that is a silly idea, then we are on the same wavelength, because I think it would be silly too. But the people suggesting that Perpignan could have been avoided if only the aircraft had show this-and-this-and-this are still 19 accidents away from this recognition.

PBL

PJ2,

I wanted to come back on your earlier comment

The "correct" information would be AOA DISCREPANCY ECAM MESSAGE obtained the same way the system did already proceed to reject one of the ADR, so no additional complexity.

As you know, the following ECAM MESSAGES already exist :
HDG DISCREPANCY
ATT DISCREPANCY
ALTI DISCREPANCY
Or even that one which is very nice :
FLAP/MCDU DISAGREE
They don’t load the pilots, do they ?
They are just a great help to let the pilots know something is wrong.
AOA DISCREPANCY would follow the same path, even more necessary that the system can take an option based on the different AoA readings, and that option, as seen through Perpignan, could be a wrong one.

The associated ECAM action would be pretty simple : Get your QRH out and check your speed limits. If they match the speed tape, just fine, but if they don’t, adjust !
I agree that in line ops Valpha prot and Valpha max don’t matter, but S, F or VLS do matter. You are in serious unknown territory if 20 knots below your real S speed your slats are still retracted.

The philosophy is the following :
It is not sane that a system takes an option without mentioning it especially when it is a known fact that that option could be a wrong one.
Let the guys know , they will thank you for that.

In Perpignan, the guys and the plane would be still around as such an ECAM MESSAGE would have put a STOP to the obvious lack of preparation.

PJ2, in my view "to keep it simple" is to tell the truth but not to hide under the carpet, and if they have to get rid of one ECAM MESSAGE before inserting the AOA DISCREPANCY, they should keep the ENG MINOR FAULT ... for the PFR.

CONF iture;

In my note to which you link I make a point which I think you have not fully considered.

To be sure, I wouldn't disagree with any of your comments as stated, as they all "make sense" in that they are, if I may use the term in a respectful manner, "motherhood" statements.

In response to the suggestion (to now include "AoA DISCR" as an ECAM message), who wouldnt' want "more warnings", etc? Perhaps it will be made one, who knows? But then what?

Let's take the TAM A320 accident case. Some argued that the thrust levers were closed by the PF but that the resolvers (six for each thrust lever) were somehow "at fault" leaving the commanded thrust at the "CLB" setting. Others examine the DFDR and see that the TLA for the #2 Thrust Lever remained in the CLB position and did what a wide-open throttle does - commanded almost full-thrust from the engine. The maximum discrepancy between two TRAs (Thrust Resolver Angles) is 0.25deg. Do we warn the crew if the angle exceeds this limit? In the TAM case, we might argue this, or not.

Two very different scenarios with vastly different antecedents and solutions. Do we warn the crew? If so, how?

More critically, (at Sao Paulo), what then, would be the meaning of a "THR LVR DISCR" ECAM message? Too soft an attention-getter when in fact the thrust levers were actually 25degrees apart? In that case, do we warn on engine thrust instead?

Another example....

I have had the very occasional touchdown which was so smooth on a damp runway, (not the right technique, I know) that the spoilers did not deploy, rendering the reverse thrust unavailable. That's a bad situation and I knew exactly how to fix it immediately, but using the present arguments, do we now created an ECAM message, "#1, #4 WHL SPN DISCR" or some such message? Again, how to warn the crew, this time in a time-critical operation on a slippery runway. Do we warn the crew? How? Firm landings and proper technique, supported by a "runway distance to go" computer is another solution. Which to choose? Why, and does it work for all circumstances, (the Southwest B737 accident at Midway, for example?).

One might consider the thought that it is remarkable that this all works as well as it does, given all.

I am not being facetious or cheeky here - if you're going to ask questions about one system and take as a single example the Perpignan case as support for all solutions, the question then has to be asked about all systems equally, under all possible scenarios. We are approaching Vast circumstances and Vast responses.

The more important question is, "What makes sense for one system but not for another, and why?"

The critical point in this entire portion of the discussion acknowledges this very point while advancing an argument of which many seem to remain in denial - that "more warnings" does not resolve the original problem, and that next time, (as per PBLs post, part of which is reproduced below), it will be something else. At what point do we cease, if you will, painting devils on the wall and start recognizing some of the limitations of such work?

PJ2

That highlights the Airbus philosophy in regard to the algorithims used to "protect" their aircraft. It clearly demonstrates that because 2 out of 3 AoA sensors polled provided the same values, "something else" must be wrong. Application of Machinbird's Common Mode Rejection (CMR) method would have detected (eons earlier) that 2 AoA sensors already had invalid outputs, i.e. each sensor's output value failed to change with time. Demonstrating that the Alpha Protections principles around which the computed performance of the aircraft is based, are not infallible.

Yet strangely, as it had already been "polled out", the remaining AoA sensor provided the ultimate stall warning - something the "polled in" sensors were unable to do. Strange? Not really, as to me it reveals that irrespective of the AOA sensors polled status, they are all used in a logic OR sense so that either will provide a stall warning.

Now we come to the trim! This is a case where the crew hadn't thought through the "what ifs" should something go wrong at the Alpha(Prot) point of the flight. Airbus law change "memory item" - check THS position! Else, the following applies -

• If you want to go up, pull back on the yoke.
• If you want to go down, pull back a little more.
• If you want to go down real fast and spin around and around and around, just keep pulling back.

PJ2
Information overload is a modern "fact of life", and understandably the ability to filter out the non essential stuff is a must. We know the warnings given to the AF447 crew, 10 in the first tranche (probably within seconds) and not all of those were "essential". Sadly, when the recorders are recovered, we will most likely see a sequence of events not dissimilar to this XL misadventure.

Forewarned is forearmed.

mm43

I think this message gets to the heart of the discussion.

Are we really talking about the design of the aircraft to prevent this accident :eek: Surely not? The reasons behind this accident are so clear, and nothing to do with the "design", that I feel any such discussion is futile.

However, if the outline of this accident could be (even partially) translated into a "normal ops" flight, then that might produce lessons worth addressing. I have repeatedly asked above for a credible scenario where this this accident does relate to normal ops, and have not seen much of an answer? i.e. my request would be please do not propose solutions that address this accident in isolation.

NoD

That part of learning curve is something IR pilot has to get over quickly. It is only intended to make sure that he understands that when it comes to flight, instruments are more reliable than human senses. Next obligatory step is understanding the way the instruments can turn their backs on pilot and learning not to trust them blindly but to keep crosschecking. TC-GEN on her last flight apparently started doing what no transport aeroplane is capable of; accelerating while climbing with low thrust. It is severely tragic that the crew didn't realize that basic fact and accordingly disregarded readout of ASi No1 and alerts connected with it. IIRC report mentions that the pilots' 757 systems knowledge was quite deficient.

Once again, RA did not fail-dead, it failed-live with realistic readout. Realistic during taxi, take off and landing, that is. It's just the aeroplane wasn't taught to check RA vs baro so didn't find it odd. As mentioned before, teaching it would only increase complexity and introduce a host of new problems, most of them insolvable. Do we really need something more readily apparent than the number that shows your vertical distance to ground going to zero with the aeroplane still flying? It's written in pretty large numbers on the bottom of the ADI, just above heading index where it's easily crosschecked yet it didn't make much difference to sysop who even forgot the maxim of flying in heavier than air machines: speed is life.

It does not! It detects discrepancy between the two but is unable to determine whether weight or AoA is wrong. Only intelligent enough system can resolve that and currently only one that is (occasionally) up to job is human brain.

Regarding the 7 probes needed to satisfactory deal with two of them freezing, there is an easy way to defeat that "engineering" solution. Just wash the aeroplane with all 7 unprotected. If water penetrates 3 of 7 probes, the system will be compromised and if it gets into 4, it will be totally f-ed up.

There is a simple and cost effective solution, though:

Follow the rules. If you don't understand why you have to follow some of them, take comfort in knowledge that there is enormous chance that someone smarter than you wrote it to prevent you from killing yourself, others or both.

Put appropriate (and that's really appropriate) covers over anything that needs to be covered while washing the aeroplane.

Don't use forklift to get CF6 onto wing with pylon attached.

Don't ever put your altitude selector below airport elevation.

Check the results of your FMA actions against basic flight instruments. Don't hesitate to use big red button if you don't like what you see.

If lost in descent - level off immediately.

Use appropriate margin every time you go flying. Things don't always go as planned and you might find yourself needing every last inch of it.

etc.

etc.

Oh, I found interesting post, made day after the accident:

Don't kid yourself. The FAA SAFO regarding checking your FOQA data carefully on non-revenue (placement/ferry) flights wasn't written without good reason.

NoD,
I think you’re a bit too eager to blame the crew but don’t realize how during a "normal approach" level at 3000 AGL you could end up 20 knots below your minimum clean speed just because the system did not deem necessary to warn you that maybe something was wrong … isn’t it a matter of concern for you ?

PBL,
You seem to take that event a bit lightly, being on that QF flight would have felt probably differently. But the point is : Why do you compare with the different events you mention, would you develop a bit more ?

PJ2,
Once again, I'll have to come back later, sorry.

CONF To get a "normal ops" accident we need to mutiply the probablilities of:

1. The maint error leading to double AoA water ingress / freezing.
2. Nobody noticing the speed tape discrepencies / PFR / Check GW messages
3. The aircraft being stalled on a Line Flight

1 is very low P, 3 is also very low P, and in fact in this case just removed the FBW active protections and left it with a "Stall Warning" which worked as design - which is the bottom line in most types.

2 is more interesting, but my best guess would be the anomaly would not last more than 1 or 2 sectors... either by PFR or crew observation.

So my view is that the circs leading to a similar accident in normal Ops is very small, smaller probably that what certification requirements dictate / require of the design. We got an accident, which again should be prevented, since the P of 3 was 1 - the crew deliberately (almost) stalled the aircraft [I cannot recall if it actually did stall].

I have tried to avoid blaming the "crew", but have said I feel the root cause was HF. Some of that HF was the position / task the crew were given / found themselves in. To re-iterate, the basic rules of the test were:

• Flown by a "Test" crew
• Flown above 12,000'
• The Min Speed deduced from the table in the schedule
• The aircraft not flown significantly lower than that Min Speed
• The purpose of the test understood, and the "what if's" briefed

Adhering to (just) one of those factors and no accident.

Bottom line: this was a test to determine if the AoA sensors / systems were working. If you are going to stake your life on the fact that they are working, there is little point in doing the test? All in all, the approach to the test(s) was a box ticking exercise, and if people undertake check/test flying in that manner, it will bite :{

NoD

PJ2, I'm not fooling myself or for that matter trying to fool anyone else. My point is that the last crew of D-AXLA did exactly what most (well, hopefully most) of us consider unthinkable. Thanks for the link, it would be even nicer if it were published (and complied with) before Pinnacle. Good old blood priority.

Why would anyone worth his aeronautical salt go below his minimum clean speed? Calculating it is as easy as 2xGW (t) + 85. Are you talking about flying sysops here? Ones completely dependent on computers and therefore unable to realize when electrons go squirrely and try to lead them onto the paths better not trodden?

Go check page 49 of the report (pg 50 of PDF).

While Vapp was slightly distorted by faulty AoA readings, Valpha prot and Valpha max went down to severely unlikely (for 1g flight) values. Seems as no one was paying attention to speed strip and how prot and max strips (colloquially known as snakes, as in: "Beware of the snakes!") got so far away from Vls.

Funnily, I've found an explanation regarding my question about stab that didn't move in normal law on the same page. Go figure.

+1 on what Clandestino posted about no attention being paid to the speed indication. I live under the approach path to the south runways at DFW airport about 12 miles out. Every day, dozens of MD-80's of the big carrier based there fly overhead when they are landing the south arrivals. At least half a dozen instances occur every day of a sudden ROAR and thunder of a pair of Pratt & W JT8's screaming off idle as the autothrottle system is late to discover an excursion of probably 10-20kts speed bleed off during level off from the intermediate approach descent. So many MD80 pilots forget SO frequently that the throttles are somewhat sluggish in the 80 to come off idle and that a pilot ...gasp...might actually manual advance the throttles slightly just before level off.
The MD80 has been in a rash of cruise flight upsets over the years due to inattention of crews and autothrottle "handled" power management.

Clandestino;
Precisely. As shown in the Report, a stall speed of 85kts decreasing to 70kts was/is unlikely. There is some commonality here with the AMS Turkish accident (re unrealistic airspeeds not being comprehended) and I think it might be worth studying to see if there are material similarities. Not suggesting anything, just curious.

Re the link to the SAFO recommending examination of FOQA data from Non-revenue flights, that SAFO was actually the second one on the subject. The first was SAFO 07006, entitled, "Safety During Positioning Flights"; It was published about 3 years after the Pinnacle accident.

Obviously without specifics, I can state categorically that review of FOQA data on non-revenue flights is especially important for any operation running a FOQA Program.

PJ2

Causation
 

Would suggest that the resultant flightpath was a UA with out of trim conditions due to the change of control laws occurring at a time where the crew were unable to retain situational awareness of the control laws & energy state.

Do agree with NoD that the accident has reaffirmed a lesson that apparently went poorly heeded, that flight test is a program where abnormal system behaviors are expected to occur.

FDR

Early on the system knew something was wrong with the AoA sensors / Why it did NOT tell the pilots ?
AoA sensors are not TPHs.

By mentioning minimum clean speed I was not exactly thinking about green dot but I can see what you mean, so I’d better rephrase it :
Whatever might think NoD, one can get much closer from a stall if 20 knots below the real S speed, the airplane is still in clean config.

Beside the point, not too sure what you mean but what’s wrong with slowing down below green dot … ?

PJ2,
I would go for the simple answer : Common sense should prevail

Something is ironic here, airplanes are supposedly designed to simplify their operation, but are getting so much more complex from the inside. I am amazed to consider how little I do know on my type. Accident reports teach me more than FCOMs … Why is that ?
Complexity leads to malfunctions.
Malfunctions bring "warnings".

Regarding the TAM accident, I’ve already made my position clear here. I have not changed it. It is based on what I think is common sense, at least mine.

But it is erroneous to state that every situation or accident will lead to a "warning" in order to resolve the original problem :

• Spoilers deployment is such a critical item for the deceleration capability. Yes, it has been assigned to the automation but fortunately it is still the PNF duty to visually confirm their deployment. The best warning is the PNF call.
  
• To mention only one accident case, I’ll go back to the AF A340 in Toronto.
  What kind of ECAM WARNING could have prevented the overrun if the airplane touched down half way of a WET WET WET 9000 feet runway … ?
  I personally don’t see any.

Well, to an extent... it correctly outvoted AoA 3 and disregarded it, ironically the 1 correct value.

The philosophy of what and when to tell the crew is no doubt part of the design and certification. I do note that except for the very latest A320 series aircraft, there is not an IAS disagree message. Interestingly, there is a (effectively) an AoA disagree, but (in a similar but not identical fashion to IAS) only when 1 ADR has already been rejected i.e. the AoA logic is with 3 values, then reject the anomalous one, when you are then down to 2 and they differ, ECAM Warning (ADR disagree).

I do not know if you fly Airbus, or even any modern complex electronic / FBW aircraft? I would be wary of adding ECAM messages for every failure under the sun. It is quite easy to overwhelm a crew with numerous messages, or just hide down a priority list the real failuire, or solution to it (look at the BA A319 Elec AAIB report, where a single switch selection was required to restore screens, but it was on page 2). Contrary to popular opinion, the Airbus does leave some things to crew diagnosis, since they have the "big overview".

In this we agree 100% I think we just disagree on whether this accident should have been warned against/prevented?

NoD

NoD - I don't believe any of us question your assertion that this accident was an unlikely candidate for recurrence nor that human error was a major cause of it.

What I believe ConF and I are expressing surprise at is the apparent 'disdain' (for want of a better word) that the system directs at what is its core safety feature. I appreciate that you appeared (#1277) to play down the importance of AoA in the AB operation, but to we 'outside' observers we have been repeatedly fed ?proganda? about how the aircraft is unstallable, which we now know to be not true. You know - "you just pull back on the stick and it looks after you" etc. - how many times have I heard that? From what I gather the a/c produces reams of 'writing' about other system failures. Where would this crew have been if they had not attempted the stall check but had a hard terrain warning and had done just that? Surely the first they might have known would be excessive pitch, low speed and a few hundred feet above the hard stuff?

I do not believe either of us want a plethora of 'green writing' for every fault, but I certainly would like to know if my machine had such queries about its significant inputs and I would like to think that such a warning would have changed my plans for the way I flew the rest of the flight.

- yes - in my case I do. 'Against' yes, 'prevented' - who knows?

BOAC... I am not disagreeing with all you say ;)

Pretty poorly placed! However, to get in this situation:

1. They would require a double, identical AoA failure (as happened here) that outvoted, ironically, the "good" AoA sensor. Probably not allowed for in design certification.
2. Happen on the 1st sector post the maint error that caused 1 above (I now see there was a "vote" occurred, so there would have been a Status Message/PFR post flight)
3. A Hard GPWS Warning (or Windshear requring full backstick).

I might add for others who keep saying the crew should have been warned, even in the exceptional test profile they were doing. I might say, if my life relied on it, I might check the AoA sensors were working prior doing the test (pretty easy to do) ;)

It is not as simple as adding an "AOA Disagree" message. It is deeper than that... if you are going to add an "AOA Disagree", maybe an "IAS Disagree" might be an idea? There is one, but only on some more recent variants, and in this case would not have triggered...

NoD

You might have missed the very subtle point in the report: aeroplane was washed contrary to procedures, without protective AoA covers fitted and that's whah caused 2 of 3 AoA probes to froze - literally. FBW airbi that are washed properly are so unlikely to stall in normal, and some not-so-normal operation like windshear and hard EGPWS, that they can be considered unstallable for all practical purposes.
Exactly. That design certification assumptions are invalidated by operating or handling contrary to approved procedures should be basic aeronautical knowledge. What happened to that?

-no. I think YOU may have missed the point I am making about the software architecture.

I wonder why most of the blame is attributed to the pilots, when the report states: "...a rinse with fresh water was performed on Monday 24 November 2008, without following the rinsing task procedure in the aeroplane cleaning procedure, and notably without any protection for the angle of attack sensors."

As far as I understand this is the main cause, pilot errors came only after that, caused (again as far as I understand) by lack of failure information presented to them ("The system surveillance did not warn the crew of this blockage...") and system design which made it difficult to recover from the first stall ("The changes of law that followed did not allow the auto-trim system to move from the nose-up position").

I don't say the crew is entirely not to blame, but they it seems as the automation failed first and foremost.