Maybe I am missing the point here but the AOA's didn't fail. Why is that so difficult to understand.

The AOA's became fixed due to ice because water enter the sensor housing due to inappropriate ground equipment being used.

The AOA's presented their signal output to onboard systems after they froze at 32,000 until the end. You cannot pre-empt that scenario. You cannot detect that event you can only at best warn of discrepencies between the 3 signal sources.

But the dilema of selecting which of the three is faulty has been at the root of previous accidents. Not just involving air data sensors (Korean air 747 adi)

I was using "failure" as a general term in the sense that they were not providing correct information as opposed to the sense that they had completely ceased to function.

Why would they be warned? Strictly speaking, the probes did not fail and it's not an anomaly according to CD 25. They were blocked but they kept working. Not as designed, for sure but there was no (love that Airbusspeak) unequivocal indication of failure. Even the intelligent systems would have problems deciding which data is correct, let alone unintelligent ones, like computers. Two of three agreed so it was simple task. Of course, monday morning quarterbacks now know better, quoting aviation laws while having no basic understanding of the way things work once we slip the surly bonds of earth. 'Tis a pity PBL's plea for the better solution will have to go unanswered.

Subtle failures are not Airbus specific problem; they are aviation specific. Aeroperu 603 had similar problem: blocking of all static ports due to non-standard (transparent) masking tape used to protect static port during washing and not being removed afterwards. Everything worked perfectly during takeoff roll, troubles began when trapped static pressure lost semblance to actual static pressure and the crew was bombarded by the warning for faults that were non-existent. At one point they got stick shaker and overspeed simultaneously and finally, exhausted with battle fell victim to assumption that ATC alt readout is correct one. Do we blame Boeing for that?

I do agree that having one ADC outvoted for considerable period of time, let's say 15 sec, would be nice to have annunciated via ECAM. However, aeroplane is designed to work perfectly fine with 2 out of 3 operative, it's flyable with all 3 failed and Airbus philosophy is to reduce the nuisance warnings as much as possible so this might go against their grain. IIRC if the aroplane was CAT III DUAL at takeoff, outvoting of ADC would change that to CAT III SINGLE. Yes it's subtle but it's on FMA part of PFD. I tought it was a joke when on introduction to Airbus I was told that FMA is primary flight instrument but was quickly persuaded otherwise. That's also the place where USE MANUAL PITCH TRIM is displayed.

Regarding CHECK GW, it was drummed into me that it's to be taken very seriously because it can be result of either:

1. entering wrong ZFW - most often and easily corrected
2. being secretly grossly overloaded - not a chance for European scheduled operation
3. FACs preparing to turn their little electronic backs on you - very unlikely yet possible. Good luck with this one.

I was mere line F/O, not allowed to go anywhere near flight testing. Lucky me for having instructors that understood Airbus very well and regarded "smart aeroplane" merely sales pitch BS.
They never interfered and that's where the real troubles begun. When the aeroplane started tumbling, all protections went off and only G protection ws recovered before making the water contact. I find neither crew performance nor end result satisfactory.

The AoA sensors most definitely did fail. They did not provide correct information about the AoA; those that froze provided incorrect information.

The usual definitions of "failure" have something about not fulfilling the intended function.

Now, you may like to argue, given what you said, that they were not faulty. I would argue they were not faulty, for example. The reason they were not faulty is that a known requirement for correct operation was violated; they were used outside of the intended and prescribed environmental parameters. I use the word "fault" to mean the cause(s) of a failure while operating inside the requirements.

I think you can detect it, under certain assumptions. Assuming that other sensors (pitots and static ports) are working correctly, you can detect it precisely the way that Airbus says that crew can detect it from the instrument readings. The question is whether you would want to go that route with the systems; assuming that the pitot-static systems are working correctly is not universally valid, as we have learnt from the Birgenair and Aeroperu accidents, the A320 rainstorm-contamination incidents, and the ice-particle-icing incidents with A330/A340 series aircraft.

PBL

So we made successful descent into semantics, namely what does "failure" actually mean.

My viewpoint is that CS 25, applied to measuring systems, refers to failure in strict sense: measured output being nonexistent or obviously out of realistic range (e.g. AoA of 400 degrees). Those can be easily detected without any crosschecking. Failure in broader sense of "not fulfilling the intended function" might be impossible to detect without being aware of the big picture and realizing which details don't fit. Despite its shortcomings, I do maintain that this task is (for the time being) better left to head mounted computer.

Now you've mentioned them, there is very significant difference between Birgenair and Aeroperu. Despite having only one pitot blocked, Birgenair crew has inexplicably decided to put its faith into the only datum in cockpit that was wrong. Simple crosschecking of two remaining ASIs would show that no1 ASI was at fault, if its failure during T/O wasn't hint enough. Aeroperu crew was deprived of each and every source of static pressure so simple crosscheck wouldn't do. That they were bombarded by alerts for faults that were nonexistent did not help their situational awareness at all.

Sorry for my naive question but 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 ? If agree that it was very difficult to diagnose the AoA sensor problem alone, but when compared with the great many inputs from other systems I would venture to say that the crew might have been warned in an unequivocal manner...

Some interesting and more relevant posts just above ;)

atakacs Why? What would a line Airbus crew do with such a message? What would they do differently, in say conducting an Approach Brief and landing having received such a message?

NoD

That was my point re: human factors. Despite there being a logical path to determining where the technical fault lay, the fact that it was the Captain's instrument that was wrong and he was the handling pilot at the time created a fixation on the reading of that instrument. This was compounded by the extra warnings they were getting (specifically the audible overspeed warning) seeming to confirm what that instrument was saying. The sensory overload precluded the FO from cross-checking his ASI with the standby ASI and correctly diagnosing the fault.

It's drilled into pilots from their first flight - trust your instruments over all else. When the instruments provide unreliable information you're in a very dangerous situation and need to get out of it as quickly as possible. What the report about the ANZ A320 incident seems (quite reasonably) to be saying is that in a test flight condition you need to presume that the information you are given may not be correct and give yourself an extra margin of safety accordingly - this was not done.

I've been wondering the same thing
 

Quote: Mickjoebill "?How do they do that?"
Anyone have an answer?

For what it's worth, as I read the report, they didn't actually detect fresh water in the sensors. Instead, they recreated how rinse water could have entered them, then proved that if that happened, it would freeze at altitude. Why they wrote "fresh water" and not just "water" is beyond me. Unless it had something to do with the report being translated from French (assuming it was).

Re the "fresh water", please give me the page in the English-language report and I'll try to make sense of the corresponding French text.

'I haven't waded (no pun intended) through the entire report yet.

CJ

Something to do with saline having a lower freezing point perhaps?

Thought it was quite strange going off the CVR that the german crew say twice that they have run out of time at altitude to do the low speed tests so they will do it at altitude on the climb out enroute back to Germany or not at all. Though the Air NZ pilot isn't shown on the CVR as replying to this it did appear at the time as that's what they were intending to do.

Then ATC get them to slow up at low level on the approach back into PPG and while slowing the Air NZ pilot suggests they continue to slow enough to get the low speed tests done as well.

Shows how easily a crew can be swayed into a situation that up until that point they had agreed they wouldn't get themselves into.

Well I guess any pilot might be interested to know about a discrepancy in the sensor readings. Personally I don't think the aircrew should be insulated from known / detected problems for it's own good...

Christiaan,

The reference to fresh water is on page 90 of the English version of the report (with further ones on pages 91 and 96).

As a line Airbus yourself, you would take great care to confirm and even maybe to correct all the limit speeds as displayed on the speed tape by using your QRH ...

AoA sensors are much more than "stall warning devices"

In the Perpignan case, the crew would have politely proceed for a full stop.
Does it make a difference ?

Don't rush or bend the rules.
 

Let us remember this was a Post Lease Handover from XL Airways back to the original Owner.

The Owner had their people sitting in the A/c and seemed to have accepted the flight planning and profiles themselves.
This is all usually discussed in detail prior.
So at least 5 "qualified" Pilots/Examiners/Engineers were ALL in agreement!

The PF - acting as a TRE on both Boeing and Airbus at the time clearly had no idea of what he was flying himself into finally.

The technical failure of the A of A sensors was overlooked or not discovered in time.

The PF elected to perform a series of Checks outside of recommended profiles. I come back to the others who also seemed in agreement including Managers on the ground.

The PF seems to have accepted or initiated these Checks, even if not originally planned, but perhaps as a last minute decision to "Check Off some boxes"..

No doubt there was huge financial and time pressure on this Handover. Remember XL Germany was/is a small operator and even small contract fines on such Handovers can be very costly. Plus they were happy to get rid of the A/c ASAP.

So the slices began to line up.

Lesson learned by me.

Regarding ATC Involvement :
 

Let’s look at this with an open mind; ATC was not responsible for this accident, but is one of the holes in the cheese barrier.

Why ? is easy for us (ATC) to understand per perhaps not for all pilots here. So let me explain, so that , at least to those reading this, you might avoid the same fate in the future if you find yourself in a similar situation.

ATC in Europe is multi-layer . Like pancakes belonging to different entities.. For us , TWR, APP, en-route are totally different things . Coordination through the pancakes / entities involves a lot of work. Today many TWR controllers are basically trained for TWR duties only and are not in the loop of what are the procedures done en-route. So much so that they even can belong to different companies with different procedures. An example : In Germany TWR controllers in say, Dortmund, will belong to the TTC company, the middle low level radar centre (until FL240) above it will be located in Bremen, 100 of Kms away, and belonging to the DFS, and the airspace above that will be controlled from Maastricht, in another country belonging to Eurocontrol.

For us ‘ ATC” is not a generic term. And for a pilot Asking “ ATC” or getting approval from “ ATC” means in fact getting approval for the airspace that controller is responsible for, not for the whole flight profile. To a pilot it means differently of course. The telephone conversation between the TWR controller in Perpignan and the Capt is revealing of the misunderstanding to that effect.

Perpignan is a very large airport with very little traffic, like many today in Europe. EAS is one of the main local employer . Relations EAS-ATC are close and everyone wants to help, and assuming the local flexibility will extend further, But what is feasible in that local environment, especially with very low traffic, is not necessarily transposable elsewhere.

The flight plan issue is another good example. It would appear that the XL Captain counted on EAS to do the proper FPL paperwork while EAS expected the Capt or XL Ops to do this. As a result a few ( more than one ) PLNs were filed that day , none of them correctly, in the sense than none described what was intended in reality.

Performing test flights maneuvers in European en-route controlled airspace is very much traffic dependant. Asking this at he time they asked in a busy Bordeaux sector ( Gaillac) was not going to work . Not in France, not in anywhere in core continental Europe for that matter . I have many times in my career authorized Flight tests, but refused a lot too. It depends on the traffic , period. I do not have to provide an alternative neither( I would not know where to send the aircraft to.) if I am busy, my priorities are to separate and expedite the other traffic, and keep the frequency clear, not to engage in Flight tests negotiations on the R/T. Not an excuse, just explaining how we work.

So if you have to perform flight tests , or acceptance tests maneuvers, if it is long ( say more than 10-15 min ), make an airspace reservation request a day or 2 before, like manufacturers and large airlines do,. You will be assigned a reserved airspace and a dedicated frequency to work for as long as you want .
If it is for a short duration, make a RMK in Flied 18 of the PLN indicating what maneuvers you want to perform, and call ( or have your Ops call ) the supervisor of the en route ACC in which airspace (FIR) you intend to perform the tests, and get his approval . He might, like I always did, suggest a quite time period, or an area, where your chances to get what you want are better. The TWR controller is not the best person to do this with.

There is unfortunately far too little “ bridges” between ATC and Flight OPS. ATC is there to help, but certain things are not always feasible as they used to when traffic was lower and available airspace bigger. I find it personally disturbing to see more and more accidents recently where ATC was one of the “holes” in the cheese. Closing a hole is most of the time very easy, but unfortunately afterwards, always afterwards.

I have not read about the 'fresh water' but surely it is a reasonable conclusion to draw that if it is deduced that 2 out of 3 probes 'failed' and it was again 'reasonably' assumed that freezing of water was the cause of this unlikely event, that it would be 'fresh water'?

I come back to the point I and others have made. Because of the 'trust' that appears to have been ingrained into AB pilots in the past (although I suspect people are slightly more wary now) that the wonder jet will protect you, it appears that this crew 'assumed' the same mental state. The low speed protections will activate. These protections, despite the denial of some, incorporate AoA readings. AoA readings/inputs are TOTALLY un-necessary for the operation of an aircraft, AB included. Why fight the simple suggestion that when a system vital in the mantra of the aircraft operation is compromised, that the crew are told CLEARLY and UNEQUIVOCALLY? Then they can resort to relying on basic flying skills (if they have any - see other thread) to fly to a safe landing. Is this not 'a reasonable technical discussion'? Certainly not a 'requirement' that is 'currently infeasible'.

I hope the AB training system, which has been so faulty over history, being behind many aircraft losses, has finally caught up. "It's an aeroplane, Brian". "Aeroplanes bite fools."

atakacs,

No, there isn't. The general opinion of such things is that it wouldn't do much good, and maybe quite a lot of harm.

First, think what would happen if it failed.

Then, how it can fail. You might think of building in redundancy, but in fact one Byzantine fault can take out arbitrary levels of redundancy, as shown in one shuttle attempted flight (scrubbed during launch) when the entire 4-processor FCC partitioned itself inside seconds into 3-1, then 2-1-1, then 1-1-1-1 (info, and the observation of consequences for redundant architectures, courtesy of Kevin Driscoll).

PBL

PBL