Qantas emergency landing
Join Date: Aug 2003
Location: Sale, Australia
Age: 80
Posts: 3,832
Likes: 0
Received 0 Likes
on
0 Posts
Copy of post by Zeke over on D & G.
TO: A318/A319/A320/A321/A330/A340/A340-500/A340-600 Operators
SUBJECT: A330 in-flight incident
OUR REF: SE 999.0083/08/LB dated 14 Oct 08
CLASSIFICATION: INFORMATION-FLIGHTS OPS
AFFECTED AIRCRAFT: All A330/A340/A340-500/A340-600 in service aircraft
--------------------------------------------------------------
Notice:
This OIT/FOT covers an operational issue.
It is the Operators' responsibility to distribute this OIT/FOT, or the information contained in this OIT/FOT, to all A330/A340/A340-500/A340- 600
flight crews without delay.
--------------------------------------------------------------
1. PURPOSE
The aim of this OIT is to:
- Update operators on the in-flight incident, which occurred on an A330
aircraft on Oct 07th.
- Advise A330/A340 operators about OEBs issuance and associated MMEL
operational procedure impact.
2. EVENT DESCRIPTION
As the incident is subject to a formal ICAO Annex 13 investigation led by the Australian Transport Safety Bureau (ATSB), the updated data about the
incident included in this OIT have been approved for release by the ATSB.
The A330 aircraft was flying from Singapore to Perth. The aircraft has then been diverted to Learmonth (Australia).
The preliminary analysis of the DFDR, Post Flight Report (PFR) and BITE
(Built-In Test Equipment) data allows to establish the following preliminary sequence of events:
The A/C was flying at FL 370 with Autopilot and Auto thrust system engaged
without any reported or recorded anomaly, when the IRS 1 Fault has been
triggered and the Autopilot automatically disconnected.
From this moment, the crew flew manually the aircraft to the end of the flight except for a short duration of few seconds.
From the time the IRS 1 Fault has been triggered, the recorded parameters of the ADR part of ADIRU 1 include erroneous and temporary wrong values in a random manner. These values are spike values and not sustained values. ADIRUs 2 and 3 seemed to have operated normally.
This abnormal behaviour of the ADIRU 1 led to several consequences as
follows:
- unjustified stall & overspeed warning
- loss of attitude information on Captain Primary Flight Display
(PFD).
- several ECAM system warnings.
About 2 minutes after the initial IRS Fault, the ADIRU spikes generated very high, random and temporary values of the angle of attack leading to:
1/ the flight control laws commanding nose-down aircraft movements (A/C
pitch attitude decreased from 2° nose-up to 8° nose-down and vertical load
factor changed from 1g to -0,8g.
2/ the Flight Control Primary Computer (FCPC) "F/CTL PRIM 1 PITCH
FAULT" ECAM WARNING was triggered
The crew timely response led to recover the A/C trajectory within seconds. During the recovery, the vertical load factor did not exceed 1,6g and the maximum altitude loss was 650 ft.
The DFDR data show that the ADR 1 continued to generate random spikes.
A second nose-down aircraft movement was encountered later on, but with
less important effects in terms of aircraft trajectory. It also led to generate the "F/CTL PRIM 2 PITCH FAULT" ECAM WARNING. This, combined with the previous "F/CTL PRIM 1 PITCH FAULT" ECAM WARNING led to switch from
NORMAL to ALTERNATE law.
The BITE message of the ADIRU 1 does not include failure or maintenance
message. However the PFR also includes other system failure messages which
have been demonstrated as spurious but generated by the ADIRU 1.
Tests performed on the A/C following the incident did not reveal any abnormal results that would allow explaining the reason for the event.
At this stage of the investigation, the analysis of available data indicates ADIRU 1 abnormal behaviour is likely at the origin of the event.
The type of ADIRU, which is involved, is NORTHROP GRUMMANN (previously
LITTON), PN 465020-0303-0316.
3. OPERATIONAL RECOMMENDATIONS for A330/A340 fitted with NORTHROP
GRUMMANN - LITTON ADIRU
Pending final resolution, Airbus will issue an OEB 74-1 that will instruct the crew to select OFF the whole ADIRU in case of IR failure, instead of switching OFF only the IR part.
The aim of the following procedure is to isolate both the IR and ADR when
an IR is detected faulty in order to prevent the ADR from providing erroneous data to the other aircraft systems.
PROCEDURE:
- If one IR is self detected faulty or if the ATT red flag is displayed on the Captain or First Officer PFD the supplying IR and ADR must be disconnected.
NAV IR 1(2)(3) FAULT or ATT flag displayed on CAPT (F/O) PFD
-IR 1(2)(3) pb ______________OFF
-ADR 1(2)(3) pb _____________OFF
IF IR 3 NOT AFFFECTED
-ATT HDG SWTG _______________CAPT (F/O) ON 3
-AIR DATA HDG SWTG __________CAPT (F/O) ON 3
- In case of dispatch under MMEL and an IR failure in flight, either detected by an IR 1+2 (1+3)(2+3) FAULT or with ATT red flag displayed on CAPT or F/O PFD, the supplying IR and ADR must be disconnected.
ATT flag displayed on CAPT (F/O) PFD or,
NAV IR 1+2(1+3)(2+3) FAULT
-IR 1(2)(3) pb ____________OFF
-ADR 1(2)(3) pb ___________OFF
SPD BRK____________________DO NOT USE
IF CG AFT 32%:
- T TANK MODE _______FWD
Note: In case of failure of IR 1 and IR 2 failure, the Inertial and Air Data from ADIRU 3 should be provided on Captain side.
Note: To isolate an ADIRU, IR mode rotary selector (OFF; NAV; ATT) remains
in the NAV position so that Inertial and Air Data be disconnected from other systems without de-energizing the ADIRU (NAV mode may be recovered if IR or ADR unduly selected OFF).
4. MMEL IMPACTS for A330/A340 fitted with NORTHROP GRUMMANN - LITTON ADIRU
In case of dispatch under MMEL 01-34-10-01-A), the associated MMEL
operational procedure is amended as follows:
IR (affected) pb sw____________________ OFF
ADR (associated) pb sw _________________OFF
IR (affected) mode rotary sel___________OFF
- If IR 1 (2) is affected:
ATT HDG sel ____________________ CAPT ON 3 (F/O ON 3)
AIR DATA sel ____________________CAPT ON 3 (F/O ON 3)
This will be reflected in MMEL Temporary Revisions:
TR N°02-34/01Z ISSUE 01 for A330
TR N°02-34/01Z ISSUE 01 for A340
5. FOLLOW-UP PLAN
Airbus is working together with the ATSB and the supplier to identify the
ADIRU failure mode.
Additionally, as the same ADIRU PN standard is fitted on single aisle family aircraft, Airbus is currently checking if temporary measures are also required on these aircraft types.
However initial investigation result seems to indicate that single aisle family aircraft flight control system is more robust against this ADIRU failure mode.
OEB 74-1 (A330 family) and 88-1 (A340 family) will be issued in the coming
days.
Specific follow-up of this OIT will be provided through OIT revision when
pertinent information related to investigation results is available
TO: A318/A319/A320/A321/A330/A340/A340-500/A340-600 Operators
SUBJECT: A330 in-flight incident
OUR REF: SE 999.0083/08/LB dated 14 Oct 08
CLASSIFICATION: INFORMATION-FLIGHTS OPS
AFFECTED AIRCRAFT: All A330/A340/A340-500/A340-600 in service aircraft
--------------------------------------------------------------
Notice:
This OIT/FOT covers an operational issue.
It is the Operators' responsibility to distribute this OIT/FOT, or the information contained in this OIT/FOT, to all A330/A340/A340-500/A340- 600
flight crews without delay.
--------------------------------------------------------------
1. PURPOSE
The aim of this OIT is to:
- Update operators on the in-flight incident, which occurred on an A330
aircraft on Oct 07th.
- Advise A330/A340 operators about OEBs issuance and associated MMEL
operational procedure impact.
2. EVENT DESCRIPTION
As the incident is subject to a formal ICAO Annex 13 investigation led by the Australian Transport Safety Bureau (ATSB), the updated data about the
incident included in this OIT have been approved for release by the ATSB.
The A330 aircraft was flying from Singapore to Perth. The aircraft has then been diverted to Learmonth (Australia).
The preliminary analysis of the DFDR, Post Flight Report (PFR) and BITE
(Built-In Test Equipment) data allows to establish the following preliminary sequence of events:
The A/C was flying at FL 370 with Autopilot and Auto thrust system engaged
without any reported or recorded anomaly, when the IRS 1 Fault has been
triggered and the Autopilot automatically disconnected.
From this moment, the crew flew manually the aircraft to the end of the flight except for a short duration of few seconds.
From the time the IRS 1 Fault has been triggered, the recorded parameters of the ADR part of ADIRU 1 include erroneous and temporary wrong values in a random manner. These values are spike values and not sustained values. ADIRUs 2 and 3 seemed to have operated normally.
This abnormal behaviour of the ADIRU 1 led to several consequences as
follows:
- unjustified stall & overspeed warning
- loss of attitude information on Captain Primary Flight Display
(PFD).
- several ECAM system warnings.
About 2 minutes after the initial IRS Fault, the ADIRU spikes generated very high, random and temporary values of the angle of attack leading to:
1/ the flight control laws commanding nose-down aircraft movements (A/C
pitch attitude decreased from 2° nose-up to 8° nose-down and vertical load
factor changed from 1g to -0,8g.
2/ the Flight Control Primary Computer (FCPC) "F/CTL PRIM 1 PITCH
FAULT" ECAM WARNING was triggered
The crew timely response led to recover the A/C trajectory within seconds. During the recovery, the vertical load factor did not exceed 1,6g and the maximum altitude loss was 650 ft.
The DFDR data show that the ADR 1 continued to generate random spikes.
A second nose-down aircraft movement was encountered later on, but with
less important effects in terms of aircraft trajectory. It also led to generate the "F/CTL PRIM 2 PITCH FAULT" ECAM WARNING. This, combined with the previous "F/CTL PRIM 1 PITCH FAULT" ECAM WARNING led to switch from
NORMAL to ALTERNATE law.
The BITE message of the ADIRU 1 does not include failure or maintenance
message. However the PFR also includes other system failure messages which
have been demonstrated as spurious but generated by the ADIRU 1.
Tests performed on the A/C following the incident did not reveal any abnormal results that would allow explaining the reason for the event.
At this stage of the investigation, the analysis of available data indicates ADIRU 1 abnormal behaviour is likely at the origin of the event.
The type of ADIRU, which is involved, is NORTHROP GRUMMANN (previously
LITTON), PN 465020-0303-0316.
3. OPERATIONAL RECOMMENDATIONS for A330/A340 fitted with NORTHROP
GRUMMANN - LITTON ADIRU
Pending final resolution, Airbus will issue an OEB 74-1 that will instruct the crew to select OFF the whole ADIRU in case of IR failure, instead of switching OFF only the IR part.
The aim of the following procedure is to isolate both the IR and ADR when
an IR is detected faulty in order to prevent the ADR from providing erroneous data to the other aircraft systems.
PROCEDURE:
- If one IR is self detected faulty or if the ATT red flag is displayed on the Captain or First Officer PFD the supplying IR and ADR must be disconnected.
NAV IR 1(2)(3) FAULT or ATT flag displayed on CAPT (F/O) PFD
-IR 1(2)(3) pb ______________OFF
-ADR 1(2)(3) pb _____________OFF
IF IR 3 NOT AFFFECTED
-ATT HDG SWTG _______________CAPT (F/O) ON 3
-AIR DATA HDG SWTG __________CAPT (F/O) ON 3
- In case of dispatch under MMEL and an IR failure in flight, either detected by an IR 1+2 (1+3)(2+3) FAULT or with ATT red flag displayed on CAPT or F/O PFD, the supplying IR and ADR must be disconnected.
ATT flag displayed on CAPT (F/O) PFD or,
NAV IR 1+2(1+3)(2+3) FAULT
-IR 1(2)(3) pb ____________OFF
-ADR 1(2)(3) pb ___________OFF
SPD BRK____________________DO NOT USE
IF CG AFT 32%:
- T TANK MODE _______FWD
Note: In case of failure of IR 1 and IR 2 failure, the Inertial and Air Data from ADIRU 3 should be provided on Captain side.
Note: To isolate an ADIRU, IR mode rotary selector (OFF; NAV; ATT) remains
in the NAV position so that Inertial and Air Data be disconnected from other systems without de-energizing the ADIRU (NAV mode may be recovered if IR or ADR unduly selected OFF).
4. MMEL IMPACTS for A330/A340 fitted with NORTHROP GRUMMANN - LITTON ADIRU
In case of dispatch under MMEL 01-34-10-01-A), the associated MMEL
operational procedure is amended as follows:
IR (affected) pb sw____________________ OFF
ADR (associated) pb sw _________________OFF
IR (affected) mode rotary sel___________OFF
- If IR 1 (2) is affected:
ATT HDG sel ____________________ CAPT ON 3 (F/O ON 3)
AIR DATA sel ____________________CAPT ON 3 (F/O ON 3)
This will be reflected in MMEL Temporary Revisions:
TR N°02-34/01Z ISSUE 01 for A330
TR N°02-34/01Z ISSUE 01 for A340
5. FOLLOW-UP PLAN
Airbus is working together with the ATSB and the supplier to identify the
ADIRU failure mode.
Additionally, as the same ADIRU PN standard is fitted on single aisle family aircraft, Airbus is currently checking if temporary measures are also required on these aircraft types.
However initial investigation result seems to indicate that single aisle family aircraft flight control system is more robust against this ADIRU failure mode.
OEB 74-1 (A330 family) and 88-1 (A340 family) will be issued in the coming
days.
Specific follow-up of this OIT will be provided through OIT revision when
pertinent information related to investigation results is available
Join Date: Jul 2008
Location: South East CTR
Posts: 10
Likes: 0
Received 0 Likes
on
0 Posts
This seems much like the Malaysian Airlines B777-200 on 3 August 2005 (Flight MH 124) from Perth to Kuala Lumpur:
Read more about that here
From that incident, the FAA report contains:
Read more about that here
From that incident, the FAA report contains:
Since [AD 2005-10-03] was issued, we received a recent report of a
significant nose-up pitch event on a Boeing Model 777-200 series airplane
while climbing through 36,000 feet altitude. The flight crew disconnected
the autopilot and stabilized the airplane, during which time the airplane
climbed above 41,000 feet, decelerated to a minimum speed of 158 knots,
and activated the stick shaker. A review of the flight data recorder shows
there were abrupt and persistent errors in the outputs of the ADIRU. These
errors were caused by the OPS using data from faulted (failed) sensors.
This problem exists in all software versions after P/N 3470-HNC-100-03,
beginning with P/N 3477-HNC-100-04 approved in 1998 and including the
versions mandated by AD 2005-10-03. While these versions have been
installed on many airplanes before we issued AD 2005-10-03, they had not
caused an incident until recently, and the problem was therefore unknown
until then. OPS using data from faulted sensors, if not corrected, could
result in anomalies of the fly-by-wire primary flight control, autopilot,
auto-throttle, pilot display, and auto-brake systems, which could result
in high pilot workload, deviation from the intended flight path, and
possible loss of control of the airplane. ................
significant nose-up pitch event on a Boeing Model 777-200 series airplane
while climbing through 36,000 feet altitude. The flight crew disconnected
the autopilot and stabilized the airplane, during which time the airplane
climbed above 41,000 feet, decelerated to a minimum speed of 158 knots,
and activated the stick shaker. A review of the flight data recorder shows
there were abrupt and persistent errors in the outputs of the ADIRU. These
errors were caused by the OPS using data from faulted (failed) sensors.
This problem exists in all software versions after P/N 3470-HNC-100-03,
beginning with P/N 3477-HNC-100-04 approved in 1998 and including the
versions mandated by AD 2005-10-03. While these versions have been
installed on many airplanes before we issued AD 2005-10-03, they had not
caused an incident until recently, and the problem was therefore unknown
until then. OPS using data from faulted sensors, if not corrected, could
result in anomalies of the fly-by-wire primary flight control, autopilot,
auto-throttle, pilot display, and auto-brake systems, which could result
in high pilot workload, deviation from the intended flight path, and
possible loss of control of the airplane. ................
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
So thats a major change from Airbus :
The requested actions after an IR1 FAULT used to be :
- ATT HDG SWTG .. CAPT ON 3
- IR1 ..... OFF
But it is now :
- IR1 ..... OFF
- ADR1 ..... OFF
- ATT HDG SWTG .. CAPT ON 3
- AIR DATA HDG SWTG . CAPT ON 3
There is more information in the audio file of the same ATSB media release
2008/43: Qantas Airbus A330 Accident Media Conference
AP disconnected at the initial IR1 FAULT ECAM MSG
Aircraft climbed 200 feet due to pilot input
AP was reengaged
Aircraft went back to FL370
AP disconnected again and was never reengaged
Only about one minute later the aircraft suddenly pitch down.
It must be a big question mark for Airbus why a single faulty ADR allowed the AOA protection to take control of the aircraft.
Aircraft was under manual control but the protection prevailed !?
The more complex a system, the more automatism, the more ambitious the more chance for the unexpected !
The requested actions after an IR1 FAULT used to be :
- ATT HDG SWTG .. CAPT ON 3
- IR1 ..... OFF
But it is now :
- IR1 ..... OFF
- ADR1 ..... OFF
- ATT HDG SWTG .. CAPT ON 3
- AIR DATA HDG SWTG . CAPT ON 3
Originally Posted by bsieker
As to the Autopilot: The ATSB media release said that the pilots hand-flew the aircraft from the time of the first incident (which was a slight pitch-up and the AP disconnect), except for a few seconds. The ATSB does not tell us when those few seconds were, in particular whether or not it was during the two following, more severe nose-down upsets
2008/43: Qantas Airbus A330 Accident Media Conference
AP disconnected at the initial IR1 FAULT ECAM MSG
Aircraft climbed 200 feet due to pilot input
AP was reengaged
Aircraft went back to FL370
AP disconnected again and was never reengaged
Only about one minute later the aircraft suddenly pitch down.
It must be a big question mark for Airbus why a single faulty ADR allowed the AOA protection to take control of the aircraft.
Aircraft was under manual control but the protection prevailed !?
The more complex a system, the more automatism, the more ambitious the more chance for the unexpected !
Join Date: May 2000
Location: Worldwide
Posts: 340
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by CONF iture
It must be a big question mark for Airbus why a single faulty ADR allowed the AOA protection to take control of the aircraft. Aircraft was under manual control but the protection prevailed
!?
AP/FD ___________________OFF
A/THR____________________OFF
Faulty ADR(s) __________ OFF
Remaining Air Data______ CONFIRM
Until we have the final report I am unable to confirm if the crew did/did not follow the UNRELIABLE SPEED INDIC/ADR CHECK PROC and turn off the erroneous ADR output. They received spikes in airspeed giving STALL/OVERSPEED warnings and all the other symptoms of a faulty ADR, and you WILL get a nose down/up bias until that ADR is turned off.
I am still not convinced the GNADIRU was faulty, problems with the output of the GNADIRU unit in the past have been traced back to things like the racking of the box (e.g. hitting the shelf above causing excessive vertical g), or a probe/sensor/air data module failure.
Please do not jump to conclusions.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Zeke,
Airbus had never thought before QF72 that switching OFF a faulty ADR was a top priority, they have changed their mind since, at least for that type of ADIRU.
Switching OFF a faulty ADR, in the UNRELIABLE SPEED INDICATION / ADR CHECK PROC has never been a top priority. It had to come up at the right time, but not before a thorough analysis by the crew was performed.
As you mention the first two lines of the UNRELIABLE SPEED INDICATION memory items, note that switching OFF a faulty ADR is NOT one of these items.
Actually it is mentioned only on the second page of one of the longest procedure figuring in the Quick Reference Handbook.
Applying the UNRELIABLE SPEED INDICATION memory items was considered enough to maintain a safe conduct of the flight, just enough to grab the QRH and read through that long abnormal procedure where, eventually, the faulty ADR would be switched OFF.
I would guess the QRH was not open on the table for a minute when the AOA protection decided to take control ...
Airbus had never thought before QF72 that switching OFF a faulty ADR was a top priority, they have changed their mind since, at least for that type of ADIRU.
Switching OFF a faulty ADR, in the UNRELIABLE SPEED INDICATION / ADR CHECK PROC has never been a top priority. It had to come up at the right time, but not before a thorough analysis by the crew was performed.
As you mention the first two lines of the UNRELIABLE SPEED INDICATION memory items, note that switching OFF a faulty ADR is NOT one of these items.
Actually it is mentioned only on the second page of one of the longest procedure figuring in the Quick Reference Handbook.
Applying the UNRELIABLE SPEED INDICATION memory items was considered enough to maintain a safe conduct of the flight, just enough to grab the QRH and read through that long abnormal procedure where, eventually, the faulty ADR would be switched OFF.
I would guess the QRH was not open on the table for a minute when the AOA protection decided to take control ...
Join Date: Dec 2007
Location: Situation room
Age: 79
Posts: 13
Likes: 0
Received 0 Likes
on
0 Posts
OK,it is clear now
ilot manualy flew and climb initialy than received wrong stall signal and pushed too fast...
Now the question is:
who will pay the compensation for injured?
Qantas because of pilot's action or Airbus because of computer glich?
kremlin,thanks
ilot manualy flew and climb initialy than received wrong stall signal and pushed too fast...Now the question is:
who will pay the compensation for injured?
Qantas because of pilot's action or Airbus because of computer glich?
kremlin,thanks
Last edited by ulaula123; 19th Oct 2008 at 14:32.
Join Date: May 2000
Location: Worldwide
Posts: 340
Likes: 0
Received 0 Likes
on
0 Posts
CONF iture,
The start of the UNRELIABLE SPEED INDIC/ADR CHECK PROC assumes worst case, problem at rotation, this was far from being the worst case. They had a lot of altitude on their side. This was far more manageable than when it happens at rotation. The procedure covers all phases of flight, including the cruise in clean configuration.
Switching off the ADR still is not a top priority, flying the aircraft is. This event went over something like 5-10 minutes, not seconds. I am sure you have been thrown false overspeed or stall warnings in the simulator at altitude, and trained not to blindly follow them, cross check them first.
I am well aware of what the checklist says, and in what order. I put the .... in to indicate a break. All I was demonstrating was the existing procedure for dealing with "unjustified stall & overspend warning" would lead you to turning off the ADR. The tools are in the QRH, so are the symptoms to look out for.
I note you did not realise this until I raised it, which makes me think Airbus is right putting it in the OEB for people who not make this connection with the UNRELIABLE SPEED INDIC/ADR CHECK PROC QRH procedure.
The start of the UNRELIABLE SPEED INDIC/ADR CHECK PROC assumes worst case, problem at rotation, this was far from being the worst case. They had a lot of altitude on their side. This was far more manageable than when it happens at rotation. The procedure covers all phases of flight, including the cruise in clean configuration.
Switching off the ADR still is not a top priority, flying the aircraft is. This event went over something like 5-10 minutes, not seconds. I am sure you have been thrown false overspeed or stall warnings in the simulator at altitude, and trained not to blindly follow them, cross check them first.
I am well aware of what the checklist says, and in what order. I put the .... in to indicate a break. All I was demonstrating was the existing procedure for dealing with "unjustified stall & overspend warning" would lead you to turning off the ADR. The tools are in the QRH, so are the symptoms to look out for.
I note you did not realise this until I raised it, which makes me think Airbus is right putting it in the OEB for people who not make this connection with the UNRELIABLE SPEED INDIC/ADR CHECK PROC QRH procedure.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Zeke
I put the .... in to indicate a break
May I remind you the crew got at most one minute, and not five to ten (?) but only a minute after they came back at 370 and before the protection took control for NO good reason whatsoever.
The total duration of the event between the initial NAV IR FAULT ECAM MSG and the first upset which is the one that matters, was at most two minutes.
Dealing with the AP disconnection + requested ECAM actions after an IR fault can easily take one out of these two minutes.
Switching off the ADR still is not a top priority, flying the aircraft is.
Of course switching OFF the faulty ADR is NOW a top priority, why do you think Airbus, in that very short period of only one week, decided to modify the checklist in that direction ?
Is it just for fun ?
Anyway, I read your posts and I have the feeling it could not have happened to you ... Good for you !
I wont argue that you may well be above average.
But it is also possible you dont realize the nature of the fault described as random spikes which has nothing to see with the typical steady fault encountered during a simulator ride. Even the system itself did not diagnostic the faulty ADR
Still, you look surprised they did not switch OFF that faulty ADR before the upset.
I am not surprised and I would not have done any better.
To put it in simple words :
A faulty ADR was not supposed to trigger a protection and take away the control from the pilot but it did !?
Did you know that ?
Airbus didnt.
I note you did not realise this until I raised it, which makes me think Airbus is right putting it in the OEB for people who not make this connection with the UNRELIABLE SPEED INDIC/ADR CHECK PROC QRH procedure.
Beside that, Airbus dont publish a Telex or the coming OEB to simply emphasize a known procedure, but to MODIFY it !
Last edited by CONF iture; 19th Oct 2008 at 23:06.
Join Date: May 2000
Location: Worldwide
Posts: 340
Likes: 0
Received 0 Likes
on
0 Posts
CONF iture,
It would appear the protections came on for good reason, because of the ADIRU generated high angle of attack. It would also appear the protections responded the way they should have in response to the angle of attack generated by the ADIRU.
The output from one ADR was not correct, "the recorded parameters of the ADR part of ADIRU 1 include erroneous and temporary wrong values in a random manner" from the time the AP was disconnected.
The procedures for dealing with "unreliable speed" and "unjustified stall & overspeed warnings" is listed in the QRH, they may not come up on ECAM as the ADIRU cannot detect unreliable speed. The procedure calls for the faulty ADR to be turned off after the speeds have been cross checked.
FCOM 3 also says in case of simultaneous failure of ADR and IR (same ADIRU), the ADR FAULT procedure should be applied BEFORE the IR FAULT procedure (where you would turn off the failed ADR as part of the procedure). That is listed at the start of the NAV IR FAULT, and NAV ADR FAULT FCOM 3 procedures.
Did you know the QRH and FCOM 3 references to turning off the failed ADR before making your posts ?
I will be keen to see the ATSB report when it is issued.
It would appear the protections came on for good reason, because of the ADIRU generated high angle of attack. It would also appear the protections responded the way they should have in response to the angle of attack generated by the ADIRU.
The output from one ADR was not correct, "the recorded parameters of the ADR part of ADIRU 1 include erroneous and temporary wrong values in a random manner" from the time the AP was disconnected.
The procedures for dealing with "unreliable speed" and "unjustified stall & overspeed warnings" is listed in the QRH, they may not come up on ECAM as the ADIRU cannot detect unreliable speed. The procedure calls for the faulty ADR to be turned off after the speeds have been cross checked.
FCOM 3 also says in case of simultaneous failure of ADR and IR (same ADIRU), the ADR FAULT procedure should be applied BEFORE the IR FAULT procedure (where you would turn off the failed ADR as part of the procedure). That is listed at the start of the NAV IR FAULT, and NAV ADR FAULT FCOM 3 procedures.
Did you know the QRH and FCOM 3 references to turning off the failed ADR before making your posts ?
I will be keen to see the ATSB report when it is issued.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Zeke,
Whatever I can say beside, thanks for giving me the reply.
But lets go back in the Arena
Except from a REAL case of potential stall I dont see anything else as a good reason to send crew and pax head butting the ceiling.
What kind of "protection" is it ?
To me youre drifting away from reality :
1- There was no real case of approaching stall
2- Your commentaries remind me the guy seating in the simulator but on the instructors seat, the clever seat, the guy who has the power to freeze the situation at any time.
You now pretend the key was in the FCOM 3
But is it the way you teach or are teach, to open FCOM 3 before dealing with the ECAM actions and before referring to the Quick Reference Handbook Abnormal Procedure ?
Im getting seriously confused here
Referring to Flight Crew Operation Manual is actually a good idea, but only when time permits was it the case before the first upset ?
By the way, what was the initial ECAM message again ?
Before going any further, Please, face the following questions :
1- Did Airbus modify the checklist in the last Telex Info Ops ?
2- Why ?
Whatever I can say beside, thanks for giving me the reply.
But lets go back in the Arena
It would appear the protections came on for good reason, because of the ADIRU generated high angle of attack. It would also appear the protections responded the way they should have in response to the angle of attack generated by the ADIRU.
What kind of "protection" is it ?
To me youre drifting away from reality :
1- There was no real case of approaching stall
2- Your commentaries remind me the guy seating in the simulator but on the instructors seat, the clever seat, the guy who has the power to freeze the situation at any time.
You now pretend the key was in the FCOM 3
But is it the way you teach or are teach, to open FCOM 3 before dealing with the ECAM actions and before referring to the Quick Reference Handbook Abnormal Procedure ?
Im getting seriously confused here
Referring to Flight Crew Operation Manual is actually a good idea, but only when time permits was it the case before the first upset ?
By the way, what was the initial ECAM message again ?
Before going any further, Please, face the following questions :
1- Did Airbus modify the checklist in the last Telex Info Ops ?
2- Why ?
Join Date: Dec 2005
Location: No. Cal, USA
Age: 72
Posts: 112
Likes: 0
Received 0 Likes
on
0 Posts
Airbus is working together with the ATSB and the supplier to identify the ADIRU failure mode. Additionally, as the same ADIRU PN standard is fitted on single aisle family aircraft, Airbus is currently checking if temporary measures are also required on these aircraft types.
However initial investigation result seems to indicate that single aisle family aircraft flight control system is more robust against this ADIRU failure mode.
However initial investigation result seems to indicate that single aisle family aircraft flight control system is more robust against this ADIRU failure mode.
Join Date: Dec 2005
Location: No. Cal, USA
Age: 72
Posts: 112
Likes: 0
Received 0 Likes
on
0 Posts
Leave closed-loop artificial intelligence for solving engineering problems like smart bombs, railway yard traffic, nuclear power stations and kitchen refrigerators with 17" plasma screens bleating interactive instructions on how to use a broom, all of which have produced catastrophic outcomes that are totally blameless.
grumpyoldgeek
Of course you're right, 
This fancy stuff has indeed advanced not only passenger comfort but safety as well. We haven't quite reached perfection yet but we're still trying. That's what science is all about. Fortunately in aviation we have safety engineers watching over this quite closely and advancing their art and concepts as well.
From my vantage the most important lesson learned is the lesson learned and applied.
The day we don't learn from our mistakes signifies a loss of confidence in the profession
Secondly, any pronouncement of unsuitability should also include a risk analysis of other ways
This fancy stuff has indeed advanced not only passenger comfort but safety as well. We haven't quite reached perfection yet but we're still trying. That's what science is all about. Fortunately in aviation we have safety engineers watching over this quite closely and advancing their art and concepts as well.
From my vantage the most important lesson learned is the lesson learned and applied.
The day we don't learn from our mistakes signifies a loss of confidence in the profession
Join Date: Oct 2001
Location: Gatwick
Posts: 1,980
Likes: 0
Received 0 Likes
on
0 Posts
Cattletruck
The automatics in this event appear to have acted correctly and very quickly. They diagnosed a fault and disconnected automatic control. That is exactly what the system is designed to do. The human element then entered the loop, to diagnose what the problem was and take corrective action.
Automatics? correctly?
Litebulbs
Well, if you are referring to the initial degradation of the DGFCS that dropped out the APLT, then true, but the pitch up, and of more concern the pitch down were grossly abnormal behavior of the FBW control system, and appear to have exceeded the normal gains in the flight control system. By a wide margin.
An A330 manually flown to a condition that invokes alpha protection does not react with that high a pitch rate, [caveat: at least in the simulator and from the flight test data of the aircaft used to derive the MQTG]
The crew input to the controls will not normally derive the rates that have occurred in this event, including dual inputs. I personally know the PIC of this aircraft, have done so for many years, and I would be surprised if the crew input was an issue.
Excessive gain has occurred in the FCS before... as while the controls are primarily a PID negative feedback system (including anti windup), they do have lookup tables for gains in relation to the proportional response signal. There is, as mentioned, no AI in the control system. gain issues have previously been involved with lateral control, which couple to yaw, and pitch.
Awaiting the final report....
The automatics in this event appear to have acted correctly and very quickly. They diagnosed a fault and disconnected automatic control. That is exactly what the system is designed to do. The human element then entered the loop, to diagnose what the problem was and take corrective action.
Well, if you are referring to the initial degradation of the DGFCS that dropped out the APLT, then true, but the pitch up, and of more concern the pitch down were grossly abnormal behavior of the FBW control system, and appear to have exceeded the normal gains in the flight control system. By a wide margin.
An A330 manually flown to a condition that invokes alpha protection does not react with that high a pitch rate, [caveat: at least in the simulator and from the flight test data of the aircaft used to derive the MQTG]
The crew input to the controls will not normally derive the rates that have occurred in this event, including dual inputs. I personally know the PIC of this aircraft, have done so for many years, and I would be surprised if the crew input was an issue.
Excessive gain has occurred in the FCS before... as while the controls are primarily a PID negative feedback system (including anti windup), they do have lookup tables for gains in relation to the proportional response signal. There is, as mentioned, no AI in the control system. gain issues have previously been involved with lateral control, which couple to yaw, and pitch.
Awaiting the final report....
Lightbulb's globe blown?
Lightbulbs,
From the ATSB media conference (off their website):
All I'll say to your comment that:
is... absolute nonsense! The automatics made a concerted attempt to maim/kill everybody on board that A330 by bunting the aircraft not once but twice, so violently that people ended up with their heads breaking the overhead lockers!
From the ATSB media conference (off their website):
About 2 minutes after the initial fault, ADIRU 1 generated very high, random and incorrect values for the aircrafts angle of attack.
These very high, random and incorrect values of the angle attack led to the flight control computers commanding a nose-down aircraft movement, which resulted in the aircraft pitching down to a maximum of about 8.5 degrees, the triggering of a Flight Control Primary Computer pitch fault.
The crew's timely response led to the recovery of the aircraft trajectory within seconds. During the recovery the maximum altitude loss was 650 ft.
The Digital Flight Data Recorder data show that ADIRU 1 continued to generate random spikes and a second nose-down aircraft movement was encountered later on, but with less significant values in terms of aircraft's trajectory.
These very high, random and incorrect values of the angle attack led to the flight control computers commanding a nose-down aircraft movement, which resulted in the aircraft pitching down to a maximum of about 8.5 degrees, the triggering of a Flight Control Primary Computer pitch fault.
The crew's timely response led to the recovery of the aircraft trajectory within seconds. During the recovery the maximum altitude loss was 650 ft.
The Digital Flight Data Recorder data show that ADIRU 1 continued to generate random spikes and a second nose-down aircraft movement was encountered later on, but with less significant values in terms of aircraft's trajectory.
The automatics in this event appear to have acted correctly and very quickly.
Capn Bloggs
Not so fast.
The first priority in aircraft performance is to protect the aircraft (else everybody is lost)
All I'll say to your comment that:
is... absolute nonsense! The automatics made a concerted attempt to maim/kill everybody on board that A330 by bunting the aircraft not once but twice, so violently that people ended up with their heads breaking the overhead lockers!
Quote:
The automatics in this event appear to have acted correctly and very quickly.
The automatics in this event appear to have acted correctly and very quickly.
The first priority in aircraft performance is to protect the aircraft (else everybody is lost)
Join Date: Oct 2001
Location: Gatwick
Posts: 1,980
Likes: 0
Received 0 Likes
on
0 Posts
Bloggs
The automatic i.e. no pilot intervention (simplistically) worked. The fault ended its authority. If the autopilot still had authority do deal with the problem that it had detected, it would have voted the incorrect source of data out and disconnected that input into the EFCS, then carried on flying normally. It is not designed to do this, that is what pilots are for. You open the loop and let them decide what is the next course of action using the relevant documentation to understand what fault is being displayed and isolate it.
It appears Airbus are making changes to how you would deal with the information presented if this fault reoccurred. Don't blame the pilots OR the aircraft.
It appears Airbus are making changes to how you would deal with the information presented if this fault reoccurred. Don't blame the pilots OR the aircraft.