Qantas emergency landing
Join Date: Feb 2006
Location: Brisbane
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
Latest
For what it's worth (I know, I know . . .)
Latest from the Sydney Morning Herald :
Computer sent Qantas jet into dive: investigators
A computer fault caused the autopilot system to be overridden, sending a Qantas plane into a mid-air plunge over Western Australia last week, authorities said tonight.
The air data computer - or inertial reference system - for the Airbus A330-300 sent erroneous information to the flight control computer causing the autopilot to disconnect, the Australian Transport Safety Bureau (ATSB) said.
More than 70 people on Qantas flight QF72 from Singapore to Perth were injured last Tuesday when the Airbus, carrying 303 passengers and 10 crew, suddenly dropped altitude.
People were hurled around the cabin and the pilot was forced to make an emergency landing in Western Australia's north.
Australian Transport Safety Bureau investigation director Julian Walsh said the faulty unit continued to feed "erroneous and spike values'' to its primary computers.
"This led to several consequences, including false stall and overspeed warnings,'' he said.
"About two minutes after the initial fault (the air data inertial reference system) generated very high and incorrect values for the aircraft's angle of attack.''
This led to the flight control computers commanding the aircraft to pitch down, Mr Walsh said.
"The crew's timely response led to the recovery of the aircraft's trajectory within seconds, and during the recovery, the maximum altitude lost was 650 feet.''
Mr Walsh said analysis of the digital flight recorder showed the faulty air data system continued to generate false information, leading to a second, less serious "nose down aircraft movement''.
The ATSB is expected to provide a preliminary factual report within three weeks.
There had been suggestions the incident may lead to the grounding of Airbus A330-300 models.
Mr Walsh today said that would be a matter for regulatory authorities.
"However, the information we have at hand indicates that this is a fairly unique event,'' he said.
"These aircraft have been operating over many hundreds of thousands of hours over many years, and this type of event has not been seen before.''
"It's probably unlikely there will be a recurrence, but obviously we won't dismiss that, and it's important that we investigate to find out what led to the (fault) and reduce the chance of that happening in the future.''
Mr Walsh said Airbus had provided advice to airlines operating the A330-300 that would minimise risk in the very unlikely event of a similar incident occurring again.
Latest from the Sydney Morning Herald :
Computer sent Qantas jet into dive: investigators
A computer fault caused the autopilot system to be overridden, sending a Qantas plane into a mid-air plunge over Western Australia last week, authorities said tonight.
The air data computer - or inertial reference system - for the Airbus A330-300 sent erroneous information to the flight control computer causing the autopilot to disconnect, the Australian Transport Safety Bureau (ATSB) said.
More than 70 people on Qantas flight QF72 from Singapore to Perth were injured last Tuesday when the Airbus, carrying 303 passengers and 10 crew, suddenly dropped altitude.
People were hurled around the cabin and the pilot was forced to make an emergency landing in Western Australia's north.
Australian Transport Safety Bureau investigation director Julian Walsh said the faulty unit continued to feed "erroneous and spike values'' to its primary computers.
"This led to several consequences, including false stall and overspeed warnings,'' he said.
"About two minutes after the initial fault (the air data inertial reference system) generated very high and incorrect values for the aircraft's angle of attack.''
This led to the flight control computers commanding the aircraft to pitch down, Mr Walsh said.
"The crew's timely response led to the recovery of the aircraft's trajectory within seconds, and during the recovery, the maximum altitude lost was 650 feet.''
Mr Walsh said analysis of the digital flight recorder showed the faulty air data system continued to generate false information, leading to a second, less serious "nose down aircraft movement''.
The ATSB is expected to provide a preliminary factual report within three weeks.
There had been suggestions the incident may lead to the grounding of Airbus A330-300 models.
Mr Walsh today said that would be a matter for regulatory authorities.
"However, the information we have at hand indicates that this is a fairly unique event,'' he said.
"These aircraft have been operating over many hundreds of thousands of hours over many years, and this type of event has not been seen before.''
"It's probably unlikely there will be a recurrence, but obviously we won't dismiss that, and it's important that we investigate to find out what led to the (fault) and reduce the chance of that happening in the future.''
Mr Walsh said Airbus had provided advice to airlines operating the A330-300 that would minimise risk in the very unlikely event of a similar incident occurring again.
Join Date: Apr 2001
Location: UK
Posts: 7
Likes: 0
Received 0 Likes
on
0 Posts
The crew were on the radio to the engineers and were told to reset the flight computers after an initial elevator warning -they were all turned OFF !
It will be routinely covered over as with many things at qantas.
It will be routinely covered over as with many things at qantas.
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
It will be interesting to see when the detailed reports come out if the ADIRU failure mode is established and if it is similar in any way. They are probably very similarly designed and might use identical third-party components.
From these two events it would seem that both aircraft are susceptible to ADIRU failure (and I suspect that may well extend to other Airbus and Boeing models).
It would appear that we can at least put to bed the usual FBW and "computer error" speculation - the flight computers had dud inputs from their instruments, and in that case you are always potentially going to get undefined behaviour.
If you trawl through accident reports for jet upsets following instrument failure you will find the same problem occurs with flesh and blood pilots. Even when the pilots have multiple redundant instruments (some of which are reading correct) they have sometimes ended up trusting the wrong ones (fatally).
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
If one read between the lines of the last MEDIA RELEASE 2008/43 14 October 2008
It could be possible that after an initial NAV IR 1 FAULT ECAM MSG
the crew did not select an alternate ATTITUDE source as reference, as requested by ECAM procedure ... ?
Therefore :
It could be possible that after an initial NAV IR 1 FAULT ECAM MSG
the crew did not select an alternate ATTITUDE source as reference, as requested by ECAM procedure ... ?
Therefore :
The faulty Air Data Inertial Reference Unit continued to feed erroneous and spike values for various aircraft parameters to the aircrafts Flight Control Primary Computers
Join Date: Mar 2005
Location: 30 West
Posts: 210
Likes: 0
Received 0 Likes
on
0 Posts
1 )sorry to burst everyones bubble but 1 faulty ADIRU doesn't do jack to the bus much less command a climb and descent ,
you get a master caution , single chime amber and it tells you to check your alt , hdg and att on the PFD , as if thats not enough most of the readings can be regained via the AIR DATA switch button .
2 ) THat OZ article said 1 ADIRU was faulty and that led to AP disconnect ??? what a Load of Bull !!! and EVEN if that were the case in point EVEN after disconnecting AP ??? so what ? she aint going to climb or plunge !
you get a master caution , single chime amber and it tells you to check your alt , hdg and att on the PFD , as if thats not enough most of the readings can be regained via the AIR DATA switch button .
2 ) THat OZ article said 1 ADIRU was faulty and that led to AP disconnect ??? what a Load of Bull !!! and EVEN if that were the case in point EVEN after disconnecting AP ??? so what ? she aint going to climb or plunge !
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by airfranz
you get a master caution , single chime amber and it tells you to check your alt , hdg and att on the PFD , as if thats not enough most of the readings can be regained via the AIR DATA switch button
The answer to an Inertial Reference System fault is through the ATT HDG SWITCHING and if you don't proceed in time and accordingly that's where it's getting messy ...
The answer to an Inertial Reference System fault is through the ATT HDG SWITCHING and if you don't proceed in time and accordingly that's where it's getting messy ...
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
How much time do you have to confirm the necessary action and is it covered in training?
The thing is to take the time necessary to adequately read the ECAM MSG and the requested action to be able to manipulate the appropriate switch.
Better take 45 sec and do it well than 2 sec and hit the wrong switch.
But the best way to learn is still to do the mistake a few times in the simulator ...
It is actually part of the training plan.
The thing is to take the time necessary to adequately read the ECAM MSG and the requested action to be able to manipulate the appropriate switch.
Better take 45 sec and do it well than 2 sec and hit the wrong switch.
But the best way to learn is still to do the mistake a few times in the simulator ...
The thing is to take the time necessary to adequately read the ECAM MSG and the requested action to be able to manipulate the appropriate switch.
Better take 45 sec and do it well than 2 sec and hit the wrong switch.
But the best way to learn is still to do the mistake a few times in the simulator ...
Join Date: Apr 2005
Location: Stockholm Sweden
Age: 74
Posts: 569
Likes: 0
Received 0 Likes
on
0 Posts
In the cruise one ADIRU is connected to one AP to fly the plane. If this ADIRU gives faulty information the AP will follow it until disconnected.
A year ago I was trying to troubleshoot an ADIRU problem on an A319. The crew had seen the problem and selected the AHSI to nbr 3, but had not connected the AP to nbr 3 ADIRU. I can't remember exactly what it was, but it took a lot of detective work to confirm what actually happened. The crew thought that they had selected AP to ADIRU 3, but had actually only selected the display, not the AP, so when the fault reoccured they assumed that two ADIRU were at fault.
In the end there was no ADIRU fault at all, the fault was in an ADM (air data module)
A year ago I was trying to troubleshoot an ADIRU problem on an A319. The crew had seen the problem and selected the AHSI to nbr 3, but had not connected the AP to nbr 3 ADIRU. I can't remember exactly what it was, but it took a lot of detective work to confirm what actually happened. The crew thought that they had selected AP to ADIRU 3, but had actually only selected the display, not the AP, so when the fault reoccured they assumed that two ADIRU were at fault.
In the end there was no ADIRU fault at all, the fault was in an ADM (air data module)
Join Date: Jan 2005
Location: France
Posts: 2,315
Likes: 0
Received 0 Likes
on
0 Posts
Sure, my first reaction was:
How the f*ck was an ADIRU allowed to feed coherent spurious data to the rest of the system under ANY circumstances?
But then I had to admit it does seem to be just about the first time ever that this happened.
So add one more person to the list of those who will be following the ATSB reports with a lot of interest.
CJ
How the f*ck was an ADIRU allowed to feed coherent spurious data to the rest of the system under ANY circumstances?
But then I had to admit it does seem to be just about the first time ever that this happened.
So add one more person to the list of those who will be following the ATSB reports with a lot of interest.
CJ
Join Date: Jul 2007
Location: Germany
Posts: 556
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Acute Instinct
The following protections appear to have been ineffective in this instance,
*Load factor limitation
In clean configuration (which we assume in cruise) the aircraft can handle up to -1G. That'll pin you to the ceiling quite thoroughly if you're not strapped in. All within the designed load limits.
Even with slats extended, the negative limit is 0G, which will render everything weightless, and can cause considerable havoc.
*Pitch attitude correction
*High speed protection
*Maneuver load alleviation(MLA)
*Turbulence damping function
*System redundancy
Bernd
Last edited by bsieker; 14th Oct 2008 at 21:40. Reason: Spelling
Join Date: Jan 2001
Location: UK
Posts: 2,044
Likes: 0
Received 0 Likes
on
0 Posts
I might suggest that many of the posts above whilst "technically correct" from an FCOM point of view, really have an incomplete idea of how an Airbus works.
I've a few thousand hrs driving them, and would never pretend to really understand what goes on under the hood
The interactions between systems are far more complex than our FCOMs lead us to believe, as numerous incidents have shown (some in our airline)... where investigations show FCOMs as incorrect, and even Airbus taking sometime to work out what/how happened (I have one Flight Control query in with them via my airline and am told we might hear their response early next year!).
This incident seems a very rare (isolated?) one, and suggest we leave the ATSB and Airbus to figure it out. Exactly where an ADIRU 1 feeds into the the FCCs, in various laws/modes, and with which switch selections will be interesting
NoD
I've a few thousand hrs driving them, and would never pretend to really understand what goes on under the hood
The interactions between systems are far more complex than our FCOMs lead us to believe, as numerous incidents have shown (some in our airline)... where investigations show FCOMs as incorrect, and even Airbus taking sometime to work out what/how happened (I have one Flight Control query in with them via my airline and am told we might hear their response early next year!).This incident seems a very rare (isolated?) one, and suggest we leave the ATSB and Airbus to figure it out. Exactly where an ADIRU 1 feeds into the the FCCs, in various laws/modes, and with which switch selections will be interesting
NoD
Join Date: Jul 2008
Location: Skating away on the thin ice of a new day.
Posts: 1,116
Received 13 Likes
on
8 Posts
airfranz
you are jumping to conclusions before the investigation has concluded.They are only saying what they do know.
What they are not saying is that the adiru fault was the one and only problem.It may have been the root cause but I am sure its not the only issue.
Very early days yet.
What they are not saying is that the adiru fault was the one and only problem.It may have been the root cause but I am sure its not the only issue.
Very early days yet.
Join Date: Nov 2007
Location: Australia
Posts: 29
Likes: 0
Received 0 Likes
on
0 Posts
It's an eerie coincidence that the incident involving the MAS B777 and the QF A330 both occurred on the same route (although the aircraft were travelling in opposite directions to one another) and implicated ADIRU failures on both occasions.
The ATSB analysis of the B777 incident determined that:
The ATSB analysis of the B777 incident determined that:
The incident was triggered by a second accelerometer failure in the
aircraft's air data inertial reference unit (ADIRU). This unit is designed
to be highly redundant and fault-tolerant but the first failed
accelerometer's failure mode was not one that had been anticipated during
unit design and development. (It had been assumed that a failure would
always result in zero voltage output, but this failed device was producing a
high output value.) The twin failures exposed a latent software fault, which
resulted in the unit feeding incorrect aircraft acceleration data to other
flight control systems.
Boeing B777-200 aircraft first entered service in 1995 and this is the first
reported instance of the particular software fault, which was apparently
present in the unit's original design, affecting operation of an aircraft.
The incident highlights the fact that software testing can never eliminate
all risk.
What exactly happened in the case of the A330 we will find out in due course. The high degree of redundancy built into aircraft electronic hardware and software creates complexity that may be beyond the capacity of its designers to fully comprehend. It can also harbour defects that, as in the case of the B777, take years to manifest themselves.
aircraft's air data inertial reference unit (ADIRU). This unit is designed
to be highly redundant and fault-tolerant but the first failed
accelerometer's failure mode was not one that had been anticipated during
unit design and development. (It had been assumed that a failure would
always result in zero voltage output, but this failed device was producing a
high output value.) The twin failures exposed a latent software fault, which
resulted in the unit feeding incorrect aircraft acceleration data to other
flight control systems.
Boeing B777-200 aircraft first entered service in 1995 and this is the first
reported instance of the particular software fault, which was apparently
present in the unit's original design, affecting operation of an aircraft.
The incident highlights the fact that software testing can never eliminate
all risk.
Join Date: Jun 2008
Location: Australia
Age: 68
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
A 330Flight Control Primary Computer Dispatch Limitations
Hot off the press...
http://www.casa.gov.au/airworth/airw...0/a330-084.pdf
"During evaluation of specific engine failure cases at take-off on Airbus flight Simulators, it has been evidenced that with FCPC1 inoperative, in the worst case, when FCPC2 and FCPC3 resets occur during rotation at take off, a transient loss of elevator control associated with a temporary incorrect flight control law reconfiguration could occur. It leads to a movement of the elevators to the zero position, which induces a pitch down movement instead of a pitch up movement needed to lift off. In addition, it leads to a limitation of the pilot authority in pitch axis and limits the capacity to counter the pitch down movement during this flight
phase, which constitutes an unsafe condition."http://www.casa.gov.au/airworth/airw...0/a330-084.pdf
"During evaluation of specific engine failure cases at take-off on Airbus flight Simulators, it has been evidenced that with FCPC1 inoperative, in the worst case, when FCPC2 and FCPC3 resets occur during rotation at take off, a transient loss of elevator control associated with a temporary incorrect flight control law reconfiguration could occur. It leads to a movement of the elevators to the zero position, which induces a pitch down movement instead of a pitch up movement needed to lift off. In addition, it leads to a limitation of the pilot authority in pitch axis and limits the capacity to counter the pitch down movement during this flight
Join Date: Feb 2004
Location: Australia
Posts: 1,307
Likes: 0
Received 0 Likes
on
0 Posts
one auto pilot engaged at altitude, all that triple redundancy is for approach and auto land.one a/p one adiru feeding it.
On an Airbus, even if one ADIRU is plugged into the A/P, wouldn't there be data sharing via databusses to that ADIRU? (if not for "ADC" data such as AOA, then, say, IRU data, such as attitude?)
I'm also wondering how aircraft computers process "spiking". Obviously the spiking on this particular aircraft was not large or rapid enough to be considered ridiculous and the value rejected.
Just curious.
Thanks.
NSEU