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.