Airbus crash/training flight
Join Date: Jul 2008
Location: UK
Age: 69
Posts: 475
Likes: 0
Received 0 Likes
on
0 Posts
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)
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)
Originally Posted by SPA83
Has the crew been warned about AoA probes failure ? : NO
Is this an anomaly according to CS 25 ? : YES
Is this an anomaly according to CS 25 ? : YES
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?
Originally Posted by CONFiture
As soon as the AoA data show a discrepancy , it is a the most common sense duty for the manufacturer to clearly advise the crew. At this point the crew will proceed as politely as possible to the end of the flight.
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.
Originally Posted by CONFiture
Even better, the crew should be able by a single switch to disable all protection features, making sure they won’t interfere based on faulty information.
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Safety Concerns
Maybe I am missing the point here but the AOA's didn't fail.
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.
Originally Posted by Safety Concerns
You cannot pre-empt that scenario. You cannot detect that event you can only at best warn of discrepencies between the 3 signal sources.
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.
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...
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes
on
0 Posts
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
atakacs
I would venture to say that the crew might have been warned in an unequivocal manner...
NoD
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Clandestino
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.
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.
Join Date: Jan 2008
Location: USA
Posts: 100
Likes: 0
Received 0 Likes
on
0 Posts
I've been wondering the same thing
Quote: Mickjoebill "?How do they do that?"
Anyone have an answer?
Anyone have a thought on how the investigators differentiate between fresh water that entered the sensor before the flight and sea water (if any) that entered between the time of the crash and the recovery?
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).
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
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
'I haven't waded (no pun intended) through the entire report yet.
CJ
Join Date: May 2003
Location: 'round here
Posts: 394
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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?
Last edited by atakacs; 20th Sep 2010 at 09:00. Reason: typo
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by NoD
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?
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 ?
Join Date: Sep 2010
Location: Nepal
Posts: 16
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Pegase Driver
Join Date: May 1997
Location: Europe
Age: 74
Posts: 3,689
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
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."
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."
Join Date: Sep 2000
Location: Bielefeld, Germany
Posts: 955
Likes: 0
Received 0 Likes
on
0 Posts
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
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 ?
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