AF447
Per Ardua ad Astraeus
Join Date: Mar 2000
Location: UK
Posts: 18,579
Likes: 0
Received 0 Likes
on
0 Posts
aguadalte - an even more confusing post! It has got gyros - it hasn't got gyros - it has got gyros.....
If I may divert momentarily, it is important here to differentiate between a gyroscope, which is a rate sensor, and a rate sensor (eg QRS or LRG), which is NOT a gyroscope. A gyroscope will maintain its attitude in a space frame and thus enable 'attitude' to be directly physically determined. A rate sensor, as in ISIS, can only offer displacement information FROM a known attitude, and requires a lot of software to produce the new 'attitude'. It lacks the vital 'rigidity' which the gyroscope has.
Back to 447 - I'm still not clear if we have an answer to what the software would have shut down or permitted in the way of information to the crew. Have we established BEYOND DOUBT that loss of pressure inputs to an ADIRU render that ADIRU unusable for attitude, either because it lacks some feed or because the system determines it to be 'unusable'? If the answer is yes, then we move on the the John Wayne scenario where the good captain is holding a torch in his clenched teeth and shining it on his only remaining attitude indicator. Does this definitely still function, or has HAL decided it too should be shut down because it has either faulty attitude inputs from the ADIRUs or faulty pressure inputs? I've been searching for info on the Qantas and Air Caribe 'upsets' to see what they 'lost' on the panel - anyone point me please?
Even with a better understanding of the systems, we are still basically in the dark as to what the software programmes are doing.
If breakup of the airframe did indeed occur, we really should be going BACK to how it got to that position in the first place, rather than discussing flat spins, VS failure modes etc. We need those recorders!
If I may divert momentarily, it is important here to differentiate between a gyroscope, which is a rate sensor, and a rate sensor (eg QRS or LRG), which is NOT a gyroscope. A gyroscope will maintain its attitude in a space frame and thus enable 'attitude' to be directly physically determined. A rate sensor, as in ISIS, can only offer displacement information FROM a known attitude, and requires a lot of software to produce the new 'attitude'. It lacks the vital 'rigidity' which the gyroscope has.
Back to 447 - I'm still not clear if we have an answer to what the software would have shut down or permitted in the way of information to the crew. Have we established BEYOND DOUBT that loss of pressure inputs to an ADIRU render that ADIRU unusable for attitude, either because it lacks some feed or because the system determines it to be 'unusable'? If the answer is yes, then we move on the the John Wayne scenario where the good captain is holding a torch in his clenched teeth and shining it on his only remaining attitude indicator. Does this definitely still function, or has HAL decided it too should be shut down because it has either faulty attitude inputs from the ADIRUs or faulty pressure inputs? I've been searching for info on the Qantas and Air Caribe 'upsets' to see what they 'lost' on the panel - anyone point me please?
Even with a better understanding of the systems, we are still basically in the dark as to what the software programmes are doing.
If breakup of the airframe did indeed occur, we really should be going BACK to how it got to that position in the first place, rather than discussing flat spins, VS failure modes etc. We need those recorders!
Join Date: Oct 2006
Location: Gone Flying...
Age: 63
Posts: 270
Likes: 0
Received 0 Likes
on
0 Posts
my mistake was their mistake?
This is very important, once Back-Up Speed Scale and Altitude are only displayed when ALL ADIRU's are switched OFF. The old procedure (for the stand-by horizon equipped aircraft), would call for the trouble-shooting of the IR fault, and in case of all confirmed to be faulted, one would be advised to switch off those connected to Captn PFD and FO PFD, i.e., IR1 and 2. This would allow the aircraft to revert to Alternate Law.
I have committed here a HUGE error! And I would like to apologize for that.
In the above said statement I said ALL ADIRU's are switched OFF and I meant to say ALL ADR's! (post #1907, now corrected to prevent others to be misinformed).
I studied the system again and noticed my mistake.
This led me to think that it is a common mistake in recurrent flight simulator sessions, to see flight crews, switching off one system, when they're actually thinking on another. (That is why we have the "confirmation" philosophy of asking for PF to visually confirm PNF actions, before switching of guarded or important systems when handling an emergency procedure)
I wouldn't like to speculate on that, (for the sake and honor to our fellow death colleagues) but, it now poses a reasonable doubt to me and a reasonable explanation for their lost of control of the aircraft.
Till now, I was strongly convinced that the failure of all IR's were responsible for the crash. Now I have a stronger and stronger (seasick) sensation that Human Factor was.
I'm sorry for being (as far as I remember) the first one to bring this speculative "explanation" for this accident. I do know that accidents have multi-causes. But, what if, instead of switching off the ADR part of the ADIRUS, they have inadvertently switched off the ADIRUS (or the IR part of the ADIRU's), in response to a Unreliable Speed Indication Check-List?
We all know how disturbing is to fly in turbulence.
Was the junior FO seated on the left seat?
Would the ISIS still give them attitude indication?
Last edited by aguadalte; 19th Jun 2009 at 13:01.
Join Date: Sep 1999
Posts: 541
Likes: 0
Received 0 Likes
on
0 Posts
h3dxb, thanks for the technical description - ISIS.
Can you establish what the purpose of the temperature sensors is, and if these are internal to ISIS or require an external temperature input.
Is there a difference / switching routine between a failed input – e.g. ADIRS off, ARINC 429, and a working bus (but with corrupt data) i.e. a triple sensor might vote out a system by comparison (IAS) – a 'failed' system, but a dual sensor might pass erroneous data (TAT).
Can you establish what the purpose of the temperature sensors is, and if these are internal to ISIS or require an external temperature input.
Is there a difference / switching routine between a failed input – e.g. ADIRS off, ARINC 429, and a working bus (but with corrupt data) i.e. a triple sensor might vote out a system by comparison (IAS) – a 'failed' system, but a dual sensor might pass erroneous data (TAT).
Join Date: Mar 2009
Location: Middle East
Age: 52
Posts: 214
Likes: 0
Received 0 Likes
on
0 Posts
SAFETYPEE
Gents:
there is no description for the temp sensors in any manual. It looks like its for health monitoring of the sensors.
as there is also no CAS or TAT indicated no need for a temp input. the IAS is taken direct from the standby system.
When a part of the ISIS failed than this partial function is inop (degraded) not the whole ISIS.
except Powerloss >200ms this instrument is working.
BOAC
The answer is NO. ADIRU= AD+IRU
Actually 2 boxes in one. The IRU part works seperately from the ADR Part. U can switch off the ADR part , but when U switch off the IRU, the box is switched off.
Once more ISIS is an Instrument which stands alone. And yes there is a lot of Software inside and ****ty expensive as well.
Have a good one, in 12 hrs I'm back on duty, and when it's a smooth day like today, I'll have time for yr questions
h3dxb, thanks for the technical description - ISIS.
Can you establish what the purpose of the temperature sensors is, and if these are internal to ISIS or require an external temperature input.
Is there a difference / switching routine between a failed input – e.g. ADIRS off, ARINC 429, and a working bus (but with corrupt data) i.e. a triple sensor might vote out a system by comparison (IAS) – a 'failed' system, but a dual sensor might pass erroneous data (TAT).
Can you establish what the purpose of the temperature sensors is, and if these are internal to ISIS or require an external temperature input.
Is there a difference / switching routine between a failed input – e.g. ADIRS off, ARINC 429, and a working bus (but with corrupt data) i.e. a triple sensor might vote out a system by comparison (IAS) – a 'failed' system, but a dual sensor might pass erroneous data (TAT).
there is no description for the temp sensors in any manual. It looks like its for health monitoring of the sensors.
as there is also no CAS or TAT indicated no need for a temp input. the IAS is taken direct from the standby system.
When a part of the ISIS failed than this partial function is inop (degraded) not the whole ISIS.
except Powerloss >200ms this instrument is working.
BOAC
Have we established BEYOND DOUBT that loss of pressure inputs to an ADIRU render that ADIRU unusable for attitude, either because it lacks some feed or because the system determines it to be 'unusable'? If the answer is yes
Actually 2 boxes in one. The IRU part works seperately from the ADR Part. U can switch off the ADR part , but when U switch off the IRU, the box is switched off.
Once more ISIS is an Instrument which stands alone. And yes there is a lot of Software inside and ****ty expensive as well.
Have a good one, in 12 hrs I'm back on duty, and when it's a smooth day like today, I'll have time for yr questions
I notice that many posters tend to peel the onion way too deep in discussing how and why planes are designed to break apart.
The investigation is still wide open to a myriad of possible causes some remote and some more probable. As debris is found and analyized by the Airbus structural experts the probability increases or decreases for the various theories. But they will remain as theories (using up all kinds of thread pages in this forum) until/(unless the main wreckage on the bottom of the sea is found and photographed.
Thus most of the effort in examining the recovered pieces is to get clues as to where the big stuff lies on the seabed. So I would suggest to devote more speculation, if any, to that end since we really need more hard data or we are just filling these pages with the same old rehash.
let's see how long this post lasts
The investigation is still wide open to a myriad of possible causes some remote and some more probable. As debris is found and analyized by the Airbus structural experts the probability increases or decreases for the various theories. But they will remain as theories (using up all kinds of thread pages in this forum) until/(unless the main wreckage on the bottom of the sea is found and photographed.
Thus most of the effort in examining the recovered pieces is to get clues as to where the big stuff lies on the seabed. So I would suggest to devote more speculation, if any, to that end since we really need more hard data or we are just filling these pages with the same old rehash.
let's see how long this post lasts
Join Date: Mar 2001
Location: us
Posts: 694
Likes: 0
Received 0 Likes
on
0 Posts
GreatBear (post 1881), I think the June 16 position of the ships is centered on where the floating wreckage has drifted, which may be some distance from the area of impact.
The plot of the wreckage recovered June 6.
The plot of the wreckage recovered on June 7.
The plot of the recovery of the bodies, the last recovery (the 50th body I believe) being on June 16th, which is where the Brazilian Navy now has most of its recovery flotilla.
The plots appear to show a north and then a west drift. The center of the search (as of June 16) is about where 145 [km] appears on the third chart.
Without an identifying coda or index, the numbering system lacks obvious coherence. Of note are items 9 and 11 near the bottom of the June 7 chart. Did these drift south or do these represent the first pieces of the plane to come off? (The square at the bottom of the frame in the charts for June 6 and 7 is the last reported position.)
The plot of the wreckage recovered June 6.
The plot of the wreckage recovered on June 7.
The plot of the recovery of the bodies, the last recovery (the 50th body I believe) being on June 16th, which is where the Brazilian Navy now has most of its recovery flotilla.
The plots appear to show a north and then a west drift. The center of the search (as of June 16) is about where 145 [km] appears on the third chart.
Without an identifying coda or index, the numbering system lacks obvious coherence. Of note are items 9 and 11 near the bottom of the June 7 chart. Did these drift south or do these represent the first pieces of the plane to come off? (The square at the bottom of the frame in the charts for June 6 and 7 is the last reported position.)
Join Date: Apr 2009
Location: Petaluma
Posts: 330
Likes: 0
Received 0 Likes
on
0 Posts
I certainly appreciate the focus on data, especially as it relates to Box/Pilot interface. My understanding of ACARS suggests to me a system that is designed not specifically to do what most folks here would like to see it do. It is not a streaming super computer. Its computing and tx formats are designed for a non-critical logging and storage of mx demands to be addressed later, at arrival.
Given the grand exposure to very limited evidence, the number and span if hypotheses is narrow. ACARS, pieces of debris, and an interesting record of possible precedent failures. Other than a short term at medical school, I am wholly unprepared and incompetent to consider the humanity as evidence.
A precedent record of pitot issues is a start, and what remains of the air data might be foundation for considering a high altitude high speed upset occurring at or near a/p disconnect. The parameters for reversion to hand control seem rather wide at M.80, (see PJ2 description of AltLaw), even with healthy pitots, the amount of control available to a surprised Command Pilot seems large. It is apparent with the evidence that at a/p disconnect, the roll control was a range of 60 degrees, albeit applied at a rate that wouldn't disagree with a/p limits, (load). This rate and range is what presents to me a potential for a very quick disconnect by an a/p that might have been doing a grand job, conveying no issues to the crew, but at a/s cue loss could be an enormous challenge to format change, autos to hand. Any roll or turbulence induced yaw or pitch excursions, without cues in a dark and flickering cockpit suddenly requiring hand control inputs may have begun a rapid upset. The VS was found virtually unblemished. The Rudder has a severe tear at its proximal swing with the aft fuselage, but remained fully and consistently attached to its mate.
A loss of the VS and Rudder as a result of the initial upset, some combination of yaw, pitch, and roll either coordinated or not may have begun the out of control descent. As the a/c would have been decelerating from its max. speed after upset, the remaining airframe would have been giving up its structure (in some unknown sequence) and created a cone of ballistic dependent debris on the Ocean's surface below. Deployed or not, the spoiler panel shows severe damage that suggests to me extreme aerodynamic loading, flutter and separation. The suggestion from its appearance is that similar loads occurred elsewhere on the a/c, enhancing the theory of an aerodynamically destructive descent. The debris collected is light and flat, with high area to mass ratio. It travelled more slowly through the air than heavier material, and most likely further.
Without a functional tail, the only other over water accident I am familiar with had the fuselage and wing structures descend immediately into the water in virtually a vertical and inverted entry, an MD-80.
I appreciate the technical nature of this thread. It is an extremely informative and enlightening enterprise.
Will Fraser
Given the grand exposure to very limited evidence, the number and span if hypotheses is narrow. ACARS, pieces of debris, and an interesting record of possible precedent failures. Other than a short term at medical school, I am wholly unprepared and incompetent to consider the humanity as evidence.
A precedent record of pitot issues is a start, and what remains of the air data might be foundation for considering a high altitude high speed upset occurring at or near a/p disconnect. The parameters for reversion to hand control seem rather wide at M.80, (see PJ2 description of AltLaw), even with healthy pitots, the amount of control available to a surprised Command Pilot seems large. It is apparent with the evidence that at a/p disconnect, the roll control was a range of 60 degrees, albeit applied at a rate that wouldn't disagree with a/p limits, (load). This rate and range is what presents to me a potential for a very quick disconnect by an a/p that might have been doing a grand job, conveying no issues to the crew, but at a/s cue loss could be an enormous challenge to format change, autos to hand. Any roll or turbulence induced yaw or pitch excursions, without cues in a dark and flickering cockpit suddenly requiring hand control inputs may have begun a rapid upset. The VS was found virtually unblemished. The Rudder has a severe tear at its proximal swing with the aft fuselage, but remained fully and consistently attached to its mate.
A loss of the VS and Rudder as a result of the initial upset, some combination of yaw, pitch, and roll either coordinated or not may have begun the out of control descent. As the a/c would have been decelerating from its max. speed after upset, the remaining airframe would have been giving up its structure (in some unknown sequence) and created a cone of ballistic dependent debris on the Ocean's surface below. Deployed or not, the spoiler panel shows severe damage that suggests to me extreme aerodynamic loading, flutter and separation. The suggestion from its appearance is that similar loads occurred elsewhere on the a/c, enhancing the theory of an aerodynamically destructive descent. The debris collected is light and flat, with high area to mass ratio. It travelled more slowly through the air than heavier material, and most likely further.
Without a functional tail, the only other over water accident I am familiar with had the fuselage and wing structures descend immediately into the water in virtually a vertical and inverted entry, an MD-80.
I appreciate the technical nature of this thread. It is an extremely informative and enlightening enterprise.
Will Fraser
Last edited by Will Fraser; 19th Jun 2009 at 15:31.
Join Date: Jun 2009
Location: in a plasma cocoon
Age: 53
Posts: 244
Likes: 0
Received 0 Likes
on
0 Posts
Some contributions state that the ADR and the IRU parts of the ADIRU are independant from each other, that you can switch off one of them to let the other operate in a normal way. This lead some contributors to say that a complete anemometric failure does not account for an IRU failure as reported by the ACARS messages.
But what do we learn from the Qantas incident ?
Use ATT HDG switching as appropriate."
is that to say that when an ADR is faulty, the corresponding IR should be switched off ? (another directive acknowledges that a faling ADIRU can be difficult to switch off)
can we truely say that the ADR and the IRU parts are independant ?
And the ISIS can fail through its mach meter function.
Given these facts, a failure chain starting from a severe icing of the Pitots probes, statics ports and possibly barometric pressure sensors would seem relevant to explain the sequence of fault reports ?
Jeff
But what do we learn from the Qantas incident ?
"An A330 aircraft experienced a sudden nose down order while in cruise. This order was preceded by an automatic autopilot disconnection and triggering of the “NAV IR1 FAULT” Electronic Centralised Aircraft Monitor (ECAM) Caution. Investigations highlighted that at time of the event the Air Data Reference 1 (ADR) part of ADIRU1 was providing erroneous and temporary wrong parameters in a random manner. This abnormal behaviour of the ADR1 led to several consequences such as unjustified stall and over speed warnings, loss of attitude information on Captain Primary Flight Display (PFD) and several ECAM warnings."
(source: http://atis.casa.go.kr/ASMS_AD/file/...008-0203-E.pdf )
is that to say that a faulty ADR can generate a "NAV IR1 FAULT" ?
in such a case, what is the procedure ? :
"Turn off the affected IR.
Turn off the corresponding ADR.
Use AIR DATA switching as appropriate.
(source: http://atis.casa.go.kr/ASMS_AD/file/...008-0203-E.pdf )
is that to say that a faulty ADR can generate a "NAV IR1 FAULT" ?
in such a case, what is the procedure ? :
"Turn off the affected IR.
Turn off the corresponding ADR.
Use AIR DATA switching as appropriate.
Use ATT HDG switching as appropriate."
is that to say that when an ADR is faulty, the corresponding IR should be switched off ? (another directive acknowledges that a faling ADIRU can be difficult to switch off)
can we truely say that the ADR and the IRU parts are independant ?
And the ISIS can fail through its mach meter function.
Given these facts, a failure chain starting from a severe icing of the Pitots probes, statics ports and possibly barometric pressure sensors would seem relevant to explain the sequence of fault reports ?
Jeff
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Till now, I was strongly convinced that the failure of all IR's were responsible for the crash.
Join Date: Apr 2007
Location: Dartmouth, Devon U.K.
Age: 90
Posts: 162
Likes: 0
Received 0 Likes
on
0 Posts
Ranamin...Quote:
http://www.atsb.gov.au/publications/...70_interim.pdf
In-flight upset
154 km west of Learmonth, WA
7 October 2008
VH-QPA
Airbus A330-303
Thanks for the pointer Ranamin. I found that report most interesting and was rather disturbed by the following statements in it:-
Scenario where AOA spikes could influence flight controls.
The aircraft manufacturer advised that the AOA processing algorithms would prevent most types of erroneous AOA inputs provided by the ADIRUs having an influence on flight control commands. This included situations such as an AOA ‘runaway’ (or a continuous divergence from the correct value), single AOA spikes and most situations where there were multiple AOA spikes. However, the manufacturer identified that, in a very specific situation, the PRIMs could generate an undesired nose-down elevator command. This specific situation involved multiple AOA data spikes with the following properties:
• there were at least two short duration, high amplitude spikes
• the first spike was shorter than 1 second
• the second spike occurred and was still present 1.2 seconds after the detection of the first spike.
Simulation studies.
As part of the investigation, the manufacturer reported that it had performed simulation studies concerning the filtering of AOA spikes by a PRIM. The simulation studies confirmed that the input of two AOA spikes which met the conditions listed above, were not effectively filtered by the PRIM, and could lead to undesired nose-down elevator commands. The aircraft manufacturer advised that the 10-degree elevator command associated with the first in-flight upset, was the result of 4 degrees of alpha prot and the 6 degree authority of the anti pitch-up compensation. The 10-degree command was close to the worst possible scenario that could arise from the design limitation in the AOA processing algorithm.
Relevance to other aircraft types.
The manufacturer advised that the AOA processing algorithms used by A330 aircraft were also used by A340 aircraft. However, different algorithms were in use on other Airbus types, which were reported to be more robust to AOA spikes. The manufacturer advised that AOA spikes matching the above scenario would not have caused a pitch-down event on Airbus aircraft other than an A330 or A340.
http://www.atsb.gov.au/publications/...70_interim.pdf
In-flight upset
154 km west of Learmonth, WA
7 October 2008
VH-QPA
Airbus A330-303
Thanks for the pointer Ranamin. I found that report most interesting and was rather disturbed by the following statements in it:-
Scenario where AOA spikes could influence flight controls.
The aircraft manufacturer advised that the AOA processing algorithms would prevent most types of erroneous AOA inputs provided by the ADIRUs having an influence on flight control commands. This included situations such as an AOA ‘runaway’ (or a continuous divergence from the correct value), single AOA spikes and most situations where there were multiple AOA spikes. However, the manufacturer identified that, in a very specific situation, the PRIMs could generate an undesired nose-down elevator command. This specific situation involved multiple AOA data spikes with the following properties:
• there were at least two short duration, high amplitude spikes
• the first spike was shorter than 1 second
• the second spike occurred and was still present 1.2 seconds after the detection of the first spike.
Simulation studies.
As part of the investigation, the manufacturer reported that it had performed simulation studies concerning the filtering of AOA spikes by a PRIM. The simulation studies confirmed that the input of two AOA spikes which met the conditions listed above, were not effectively filtered by the PRIM, and could lead to undesired nose-down elevator commands. The aircraft manufacturer advised that the 10-degree elevator command associated with the first in-flight upset, was the result of 4 degrees of alpha prot and the 6 degree authority of the anti pitch-up compensation. The 10-degree command was close to the worst possible scenario that could arise from the design limitation in the AOA processing algorithm.
Relevance to other aircraft types.
The manufacturer advised that the AOA processing algorithms used by A330 aircraft were also used by A340 aircraft. However, different algorithms were in use on other Airbus types, which were reported to be more robust to AOA spikes. The manufacturer advised that AOA spikes matching the above scenario would not have caused a pitch-down event on Airbus aircraft other than an A330 or A340.
Join Date: Jan 2008
Location: US/EU
Posts: 694
Likes: 0
Received 0 Likes
on
0 Posts
Investigators Determine Air France Disaster Caused By Plane Crash
Once again, The Onion, in its tasteless and irreverent style, comments on the media bloviators covering this accident:
Investigators Determine Air France Disaster Caused By Plane Crash | The Onion - America's Finest News Source
Investigators Determine Air France Disaster Caused By Plane Crash | The Onion - America's Finest News Source
Join Date: Jan 2008
Location: Herts, UK
Posts: 748
Likes: 0
Received 0 Likes
on
0 Posts
I am in agreement here that seeing the VS break off so cleanly is quite disturbing. I would love to see pics of other mfg's VS failures. It is much more preferred to see (as in the MD-11 crash you mentioned) that the critical pieces are robust.
Seems its a matter of damned if you do & damned if you don't with some people - what do you really want a structure to do, play strip-poker or Russian roulette?
Join Date: Dec 2008
Location: Portugal
Posts: 62
Likes: 0
Received 0 Likes
on
0 Posts
Do we have proof the A/C lost ALT indications? Or just the Speed? Because Speed ind loss will not afect Alt indication. On the other hand, Alt ind loss would alter the speed. Plus, the Speed (pitot) sensor is more prone to weather influence (dynamics) than Static (vacuum actuation and flushed) sensors. Any problem in any of these sensors would fail the ADR part of ADIRU. And in fact ALL we know is that an ADIRU reported faulty in the IR part (#2), as well as an ADR DYSAGREE, which can be due to Alt, Spd, or both.Just because we discuss many scenarios does not necessarily make it true, unless YOU'RE THERE!Looks like an established fact that speed sensors caused it (by reading most of the threads in this Forum), and what is most strange is the lack of self-defense from AIRBUS part on the subject.We should all show a bit more respect for the families involved, the professionals involved, and WAIT FOR THE INVESTIGATION TO FINISH!But I have to keep stopping myself to come here, this was just a reminder!
Join Date: Apr 2008
Location: Cape Verde Islands
Posts: 6
Likes: 0
Received 0 Likes
on
0 Posts
p51guy reply from capeverde2008
Quote - "NO COMMERCIAL AIRCRAFT SHOULD GO WITHIN 100nm LATERALLY of CB - ICTZ (Tropical Cumulo-Nimbus clouds) activity.....for any reason...FULL STOP. NEVER, EVER, don't even think about it.... or trying to overfly it. That is from MANY years experience and many grey hairs of wisdom!!"
"I guess you never fly through Texas with thunderstorms as big then. You would have to deviate over Oklahoma with those parameters." p51guy quote
Yes, T-storms big enough to power Africa for a few days!
Yes, deviate over Oklahoma, whole of Central Africa if necessary! Fuel divertion, turn back....it really is 'lives' at stake. Plan well, be cautious and arrive alive....
Rgds, capeverde2008
"I guess you never fly through Texas with thunderstorms as big then. You would have to deviate over Oklahoma with those parameters." p51guy quote
Yes, T-storms big enough to power Africa for a few days!
Yes, deviate over Oklahoma, whole of Central Africa if necessary! Fuel divertion, turn back....it really is 'lives' at stake. Plan well, be cautious and arrive alive....
Rgds, capeverde2008
Join Date: Jun 2009
Location: Somewhere out there
Age: 39
Posts: 65
Likes: 0
Received 0 Likes
on
0 Posts
ir + tcas
The answer is NO. ADIRU= AD+IRU
Actually 2 boxes in one. The IRU part works seperately from the ADR Part. U can switch off the ADR part , but when U switch off the IRU, the box is switched off.
Actually 2 boxes in one. The IRU part works seperately from the ADR Part. U can switch off the ADR part , but when U switch off the IRU, the box is switched off.
In the qantas flight maybe the IR1 problems led to erroneous ADR1 "conclusions", including AOA (please correct me if wrong).
Another question:
Could someone already "decipher" the TCAS fault... How does it relate to "doppler", if it really does ? Is it related to the "antenna" or to distance/speed calculation (then it would need at least ground speed, I suppose).
Editing: Someone already stated that in the AI docs the TCAS is indeed 34-43 and not "doppler"
Last edited by augustusjeremy; 19th Jun 2009 at 17:01.
Join Date: Jan 2008
Location: Los Angeles
Posts: 27
Likes: 0
Received 0 Likes
on
0 Posts
Without a functional tail, the only other over water accident I am familiar with had the fuselage and wing structures descend immediately into the water in virtually a vertical and inverted entry, an MD-80.
24V
Last edited by 24victor; 19th Jun 2009 at 17:00. Reason: Corrected to clarify trim control lost
Join Date: Jan 2008
Location: Atlanta, GA, USA
Posts: 349
Likes: 0
Received 0 Likes
on
0 Posts
Harry Mann - "pulled structure out!!"
No, it failed cleanly and very suddenly - this is shown by the damage to the lower rudder which nevertheless remained attached to the VS implying it was levered backward against the tail cone and shattered under sudden longitudinal compression. This in turn implies that the forward attachment failed very suddenly and explosively, the way composites do, and you can see this in the exposed cross-hatch "brushy" damage in the VS internal structure (seen from below).
I still believe that either the VS failed on its own in turbulence, or as a result of a lightning strike traveling down the aluminum fuselage and exiting at the VS front root, destroying structure there. The latter is more consistent with subsequent computer systems failures.
-drl
No, it failed cleanly and very suddenly - this is shown by the damage to the lower rudder which nevertheless remained attached to the VS implying it was levered backward against the tail cone and shattered under sudden longitudinal compression. This in turn implies that the forward attachment failed very suddenly and explosively, the way composites do, and you can see this in the exposed cross-hatch "brushy" damage in the VS internal structure (seen from below).
I still believe that either the VS failed on its own in turbulence, or as a result of a lightning strike traveling down the aluminum fuselage and exiting at the VS front root, destroying structure there. The latter is more consistent with subsequent computer systems failures.
-drl
Join Date: Jun 2009
Location: Dorset
Posts: 31
Likes: 0
Received 0 Likes
on
0 Posts
I have been involved with the design and integration of the software on a number of avionic embedded systems; from a Fault Detection, Recovery and Reporting perspective I have some observations and some questions.
1. Only reporting 'own' failures to ACARS: IIRC on A320 there was an Airbus requirement on avionic systems that they had to have a 90% confidence level for detecting and reporting an internal failure, down to 'sub-system' level. In order to avoid a 'cascade' of messages, it is obviously important not to generate a maintenance message when the fault is known to be external to that particular system. This is possibly significance with the the IR2 message and the TCAS FAULT message; these should not have been generated because of an external ADR problem, but because of internally detected faults. A question for an ISIS expert, would high 'g' loads cause an ISIS system to consider that outputs from its gyros or accelerometers were 'out of spec'? A question for a TCAS expert, what would cause TCAS to generate an ACARS message, a GPS derived value (such as speed or rate of change of heading) out of spec? An earlier post referred to TCAS using Doppler to determine relative speed between aircraft; would 'unbelievable' changes in relative speed cause an internal fault to be flagged?
2. Delay on ACARS messages: Once an Airbus avionic system detects a fault it should immediately mark its outputs as Invalid/Unavailable to its 'users' (including CFDS). However, there may be a significant delay before the system can determine if this fault is a 'hard' internal failure. Its recovery process might include retrying an input a number of times, resets (of sub-elements of the system, or the complete system) or diagnostics (such as running loop-back tests on the ARINC 429 Input Port). So depending on the type of detected fault there might be a significant delay before a system is confident in reporting a failure. For example, the loss of an external communication link for a minute or so may not be considered a 'hard' failure, loss for 10 minutes or so might be.
3. Timing sequence of ACARS messages: As pointed out in other posts, ACARS primary purpose is to provide maintenance data to Ground Crew. There is no particular urgency to providing maintenance data to the ground (as opposed to ASAP for fault information to the flight crew). As it is an inefficient use of processing power to provide data at a rate faster than it is needed, an aircraft system could be designed to schedule a task every couple of minutes to check the system's internal fault log to see if a maintenance message should be composed and sent to ACARS. So the sequence on messages generated by different systems could be quite random.
4. Failures unlikely to be caused by lightning: It is unlikely that any of the ACARS failure messages were due to damage by lightning as it is likely that the system's vulnerable processing capability (CPU, RAM, etc.) would also have been affected to such an extent that the system would not be able to compose and send any messages to the ACARS. It is an important 'fact' that the reporting systems are still running; the failure they are reporting is unlikely to be due to lightning, power supply loss, fire or being shaken to destruction.
5. Setting fault detection levels: Avionic system designers are well aware of the difficulties in getting the right balance between 'nuisance false fault reports' and 'not detecting marginal faults'. The limits within the software that are used to flag a fault on sensor input values (max/min, rate of change, comparison) are based on the 'expected' range of values during aircraft operation; persistent input values that are outside the aircraft's operational limits should be considered as more likely to be an internal fault and hence flagged as such. A system that flags itself as failed and needing maintenance might in fact be working, it is just that what its sensors are telling it is 'unbelievable'!
1. Only reporting 'own' failures to ACARS: IIRC on A320 there was an Airbus requirement on avionic systems that they had to have a 90% confidence level for detecting and reporting an internal failure, down to 'sub-system' level. In order to avoid a 'cascade' of messages, it is obviously important not to generate a maintenance message when the fault is known to be external to that particular system. This is possibly significance with the the IR2 message and the TCAS FAULT message; these should not have been generated because of an external ADR problem, but because of internally detected faults. A question for an ISIS expert, would high 'g' loads cause an ISIS system to consider that outputs from its gyros or accelerometers were 'out of spec'? A question for a TCAS expert, what would cause TCAS to generate an ACARS message, a GPS derived value (such as speed or rate of change of heading) out of spec? An earlier post referred to TCAS using Doppler to determine relative speed between aircraft; would 'unbelievable' changes in relative speed cause an internal fault to be flagged?
2. Delay on ACARS messages: Once an Airbus avionic system detects a fault it should immediately mark its outputs as Invalid/Unavailable to its 'users' (including CFDS). However, there may be a significant delay before the system can determine if this fault is a 'hard' internal failure. Its recovery process might include retrying an input a number of times, resets (of sub-elements of the system, or the complete system) or diagnostics (such as running loop-back tests on the ARINC 429 Input Port). So depending on the type of detected fault there might be a significant delay before a system is confident in reporting a failure. For example, the loss of an external communication link for a minute or so may not be considered a 'hard' failure, loss for 10 minutes or so might be.
3. Timing sequence of ACARS messages: As pointed out in other posts, ACARS primary purpose is to provide maintenance data to Ground Crew. There is no particular urgency to providing maintenance data to the ground (as opposed to ASAP for fault information to the flight crew). As it is an inefficient use of processing power to provide data at a rate faster than it is needed, an aircraft system could be designed to schedule a task every couple of minutes to check the system's internal fault log to see if a maintenance message should be composed and sent to ACARS. So the sequence on messages generated by different systems could be quite random.
4. Failures unlikely to be caused by lightning: It is unlikely that any of the ACARS failure messages were due to damage by lightning as it is likely that the system's vulnerable processing capability (CPU, RAM, etc.) would also have been affected to such an extent that the system would not be able to compose and send any messages to the ACARS. It is an important 'fact' that the reporting systems are still running; the failure they are reporting is unlikely to be due to lightning, power supply loss, fire or being shaken to destruction.
5. Setting fault detection levels: Avionic system designers are well aware of the difficulties in getting the right balance between 'nuisance false fault reports' and 'not detecting marginal faults'. The limits within the software that are used to flag a fault on sensor input values (max/min, rate of change, comparison) are based on the 'expected' range of values during aircraft operation; persistent input values that are outside the aircraft's operational limits should be considered as more likely to be an internal fault and hence flagged as such. A system that flags itself as failed and needing maintenance might in fact be working, it is just that what its sensors are telling it is 'unbelievable'!