ADIRU's
The real concern would now logically be, determining how one wayward ADIRU managed to disable and bypass a multitude of protections designed to prevent such a flight disturbance.
The following protections appear to have been ineffective in this instance,
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.
yes its concerning even so given command/monitor systems involved and would have thought cross checking between adirus may have voted out the dud info.
I'm as surprised as anyone such an excursion can happen to the extent it did.
over to you mr airbus........
And Mr Boeing also - since it sounds awfully similar to 9M-MRG (200503722)
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).
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 :
Quote:
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
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
I'm afraid you're not correct here.
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 ...
How much time do you have to confirm the necessary action and is it covered in training?
How much time do you have to confirm the necessary action and is it covered in training?
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 ...
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 ...
OK, than why the necessity in this event to get ground engineers involved in this?
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)
It was actually fed erronious data from the aircraft's first IRS unit. It then indicated a high angle of attrack (erroniously) and put the aircraft into a dive.
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.
The following protections appear to have been ineffective in this instance,
*Load factor limitation
The load factor limitation probably worked.
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.
Quote:
*Pitch attitude correction
Didn't this work? PRIM was given (wrong) High AoA values, and lowered the nose accordingly.
Quote:
*High speed protection
How is this relevant? I'm not aware that MMO was reached/exceeded ...
Quote:
*Maneuver load alleviation(MLA)
MLA only becomes active when stick deflection is more than 8 degrees aft, and load is higher than 2G. Its purpose is to to alleviate structural load of the outer wing surfaces, while maintaining load factor. This is probably irrelevant here. The major upsets were downwards.
Quote:
*Turbulence damping function
Turns out now there was no turbulence.
Quote:
*System redundancy
This is interesting. As others have pointed out, there are 3 ADIRUs. Are there really no cross-checks to detect a failure in one?
Bernd
Last edited by bsieker : 14th October 2008 at 23:40.
Reason: Spelling
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
Location: not the @r$& end of the earth but can see it from here.
Posts: 324
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.
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 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.
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!).
Linear Mode
