AF447

[takata]

augustusjeremy:
I know you didn't post it... but what do you think is a guess and what is indeed documented ?
How can you get a fault of a inertial reference unit out of conflicting raw air data ? Isn't inertial reference data independent from air data ?
And isn't this fault detected by simple comparison involving INERTIAL DATA only ?
This is a mess...

Well, indeed, I didn't posted it but I'm sure it is mostly documented and very difficult to decode without the full data stream and maintenance experience... I think that Mandala 499 (the original poster on Airliners.net) is quoted out of context and this list posted like that without the discussion concerning its meaning isn't complete. The first post concerning the decoding was from Pihero:

Pihero:
After a lot of research through dozens - if not hundreds of pages - from the A330 manuals, coming from different sources, Mandala 499 and I have managed to identify the meaning of the ACARS messages.
To explain it simply is not easy. Let's just say that the messages represent two of the functions of the CMC - Central Maintenance Computer - of the airplane :
1/- A report from the flight warning computer on what is showing on the instrument panels : PFDs, ECAM...etc...
2/- A report from the different BITEs that are present in each system, comparators...etc... They are , I repeat once again, totally transparent to the flight crew, but for us they could give a better picture of what is happening.
I confess I had a terrible problem sorting things out as I started with the assumption that the messages came out on the ground telex machine in their order of detection...It is not so, and thanks to Mandala's good work, we've arrived at a logical linkage of all the messages.
I also had to very carefully take Zeke's caution as to wheter these messages are genuine failures or just transients. I now believe that these faults / failures are for real and there was no indication - or logical explanation - of a return to normal functions.
So I propose that first we'd introduce you to the messages as they appeared on the initial summary document, then Mandala would walk you through what we think was the actual chain of events.
Bear with us, it's quite interesting.
So here is the decode of all the messages in the order of the first summary :

0210Z

A/P OFF : The AFS monitors the air data from the ADRs. Any brutal variation of CAS, ALT, Mach causes the A/P to disengage : here, as the pitot system is suspect, a variation of 20kt or Mach.04 for .45 second is enough to disconnect both FDs and the A/P.
Reactive windshear detection: with the ADRs been rejected by the AFS,, AoA is not accessible any more.
F/CTL Alternate Law : is normally a result of the "ADR DISAGREE" condition. The flight Control Laws revert , from "Normal Law" to "Alternate Law 2". The Prims are in charge of the voting and elimination of a duff ADR, but it takes them 10 seconds to do so (threshold is 16 kt / 10 sec.
Flight Director Flag on captain's PFD
Flight Director Flag on F/O's PFD
Auto Throttle OFF (These last three should have appeared at the same time as the A/P OFF warning.)
TCAS Fault : Result of the loss of the associated ADR (for altitude data)
Speed Limit Flag on Captain's PFD
Speed Limit Flag on F/O's PFD ( these two result of rejected Airspeed information by the EFCS, might be a sign of the PROT LOST, which hasn't been indicated)
Rudder Travel Limiter Fault is normally a result of the "ADR DISAGREE" condition.
EFCS 1 Fault on Maintenance Status
EFCS 2 Fault on Maintenance Status
Probe-Pitot 1+2 / 2+3 / 1+3 / (9DA. Relates to Heating element PITOT 1
Primary Flight Computer #2 (ADIRU1 signal to Prim 2)

0211Z

FPV Flag on Captain's PFD
FPV Flag on F/O's PFD
Speed or Mach function on ISIS (Suspect loss of ADIRU 3 for ISIS MACH )
IR2 Fault (Discrete data streams = Pitot, Static , TAT, OAT to ADIRU 2)

0212Z

ADR DISAGREE : TOOK IT A LONG TIME TO APPEAR NOW !

0213Z

Primary Flight Computer #1 Fault (Crew manipulation suspected, on ADR DISAGREE C/L )
Secondary Flight Computer #1 Fault ------Idem----------------------
ADR2 Fault on Maintenance Status Another very late message
Intermittent Fault on FMGEC #1

0214Z

Cabin Vertical speed Advisory. We now believe that this advisory message is just a result of ADR data

There is a glaring conclusion : there is no way that the ACARS have been transmitted in the order of the summary.
Firstly because we find a 0212z event in the middle of the 0211 ones, and the same for two 0213Z's between 0214z messages...
Secondly, it is also obvious that the ADR DISAGREE message/warning is too late in view of all the happenings that should have been its consequences .
But looking at the system, we can see in fact the trouble-shooting "reasoning" of the system facing multiple incoherent data at the same time.
The explanation will come in the second part, in which we deal with the time tags and propose one - for us the most logical - chain of events.

See this post and below:
AF A332 Crash (F-GZCP) - Part 19 — Civil Aviation Forum | Airliners.net

[jcarlosgon]

cpdlcads
On the 330/340 you can put ''aoa'' into the ACMS on MCDU 3 and this gives a direct readout of aoa typically 2.2 - 2.4 degrees nose up at fl 370 M.81. Now if only AB would copy that info to the PFD, and better still to a separate instrument on the instr panel....

Latest S/Ns have this:

"A backup speed scale and a backup altitude scale replace simultaneously the normal speed and altitude scales when all the three ADRs are switched OFF. This enables the flight crew to fly at a safe speed and altitude in case of an unreliable speedlaltitude indication.
The backup speed scale information is based on the angle-of-attack, and depends on the slatlflap configuration.
The backup altitude scale displays the GPS altitude."

FCOM 1.31.40 pg 32

Sorry, not able to post the image.

[takata]

Squawk_ident:
Is it downloaded from a computer inside the company maintenance building or an on-board system or computer. I understand that SATCOM being expensive, only the "headers" are sent and the rest is stored until further treatment. But retrieve from where?

From F-GZCP on-board system...
It is lost and we are left with our best guesses. From comparisons with other similar incidents documented with other ACARS sequences, be sure that the investigators and Airbus will get much more data than we actually have. But from what we have, there is no reason to believe that F-GZCP crashed at 0214Z.
Something else much more critical happened to her, starting with the failure of the Satcom system (my best guess here would be a double engine flame-out; they would be left to radio com and the aircraft had radio issues before departure).

S~
Olivier

[takata]

jcarlosgon:
Latest S/Ns have this:
"A backup speed scale and a backup altitude scale replace simultaneously the normal speed and altitude scales when all the three ADRs are switched OFF.

Yes, you are right. All late aircraft are delivered with standard new BUSS (Back Up Speed Scale). A380, future A350, got it also, and it could be retrofited to older aircraft as well. The pilots from Air France asked for it for their long haul fleet following the numerous speed issues (but the retrofiting is very expensive also).

There is a paper from Joelle Barthe talking about it (at the end):
http://aviationtroubleshooting.*****...le-barthe.html

S~
Olivier

[Hyperveloce]

Hi there
In the Air Caraïbes case (I am a bit monomaniac but we have a real time sequence described there, not seen through the ACARS):
22h22mn59s: CAS & Mach plunged from 273 to 85 kts, from Mach 0.80 to 0.26, altitude dropped from 35000 ft to 34700 ft.
in the same instant: FD1/2 and A/P 2 disengaged, red ECAM msg "AUTO FLT AP OFF" (master warning+cavalry charge), and 6 new ECAM msg, among them (in the order given by the report): F/CTL ADR DISAGREE, F/CTL ALTN LAW, F/CTL RUD TRV LIM FAULT, AUTO FLT REAC W/S DET FAULT,... The SPD LIM (and red flag) are also displayed on the two PFD.
the next event in the chronology occurred at 22h23mn36s (STALL), but these msg appeared at 22h22mn59s to the pilots in a matter of a few seconds.
Jeff

[PK-KAR]

A little time to explain...

I think some explanations is due from this "crosslinkage"...

Indeed, what is the source of this detail? Was it obtained from the original transmissions, or?

There was a post on eurocokpit, and there was a link providing "their" own translation of the ACARS... http://www.eurocockpit.com/images/PFR447.php
This was then put into the original ACARS headers list available at http://www.eurocockpit.com/images/acars447.php (this was the one that got everyone going).

Someone came with the answer to my question at last.

Be warned! There's no way of guaranteeing the content source (linked above) is correct.

Bye Bye dual/triple pitot failure hypothesis...

More reading needs to be done because NAV ADR DISAGREE came up, which shouldn't put the A/P and A/T off, but an 2 ADR fault would. Intermitten failures??? Dunno yet.

Any more messages preceding 0210Z sculling around anywhere

I haven't found any either

A single pitot failure unlikely downs an A330.

Correct... neither should a dual or triple Pitot failure. The reordered ACARS is only an attempt to piece together a possible sequence of events between 0210 and 0214 UTC... beyond that, it's speculation... but, speculation with some basis can be good for discussion, baseless ones are not... which caused the original AF447 topic here to be locked, and this one opened under heavy moderation (but the mods seemed to have been overwhelmed some of the time... they can't be everywhere at all times)... I've monitored this topic and the one at a.net but has so far refrained from posting on this one until someone put up that reordered ACARS list.

This is way too much reading into this ACARS sequence. ACARS are only triggered for post-flight maintenance once landed. They are not a kind of FDR giving the full data flow involved behind each events, neither they are a sequential explanation of the in flight cockpit events.

Agree and disagree...
Agree in that the ACARS is not the FDR, and the CMCs rely on various sampling rates of the components... intermitten failures can be missed, faulty or rogue items can go back online in sync and the CMC wouldn't report if it went and returned quickly. And there reason why one should not rely on this as an absolute factual basis of the chain of events is in the order in which it was listed... the timestamps has 1 minute resolutions... which is clearly not good enough (but then, can't win it all can we?)... and heck, I resequenced it to make sense TO ME!

Disagree in that... what else do we have? If stuff like that aren't useful, then why did it take >100 pages of what seemingly was running around in circles (at least about 10 pages worth continuously at one time)... The stuff can be useful for discussion purposes, and may allow some of us to get a better idea in the meantime. The list and the work done on it is far far from finished... and might never be... They can find the FDR and CVR tomorrow and provide information whether the understanding from the list is correct or totally wrong... but then, I guess we can't just sit and wait in the forums can we?

I for one would be disappointed the stuff to be used by Doombus or Glorybus preachers for their own agendas...

There are quite a bit of background discussions leading to the reordered list... so when just looking at the list, one must take extreme care, otherwise...

How can you get a fault of a inertial reference unit out of conflicting raw air data ? Isn't inertial reference data independent from air data ?

And isn't this fault detected by simple comparison involving INERTIAL DATA only ?

A mess indeed... but look at the Qantas case, the preliminary report if I understand correctly reveal some potential problem linkage between the ADR and IR part of the boxes... which needs to be looked at....

Sorry, not able to post the image.

U mean this?

That BUSS ???

But from what we have, there is no reason to believe that F-GZCP crashed at 0214Z.

Agree... that's why the list was worked at... the simplest conclusion is that it was unlikely the plane hit the water (whether in 1 piece or nor) at 0214Z. The chain of events listed, and other cases such as the Air Caraibes F-OFDF incident, indicate that although the situation in the flight deck may be one of total confusion, the chain of events one can extrapolate/depict from the ACARS indicate that something else must have happened afterwards...

In the Air Caraïbes case (I am a bit monomaniac but we have a real time sequence described there, not seen through the ACARS):

Yes, but that case is no way a twin of F-GZCP, a cousin at best... more work on the ACARS list is needed to even have a fair comparison of the two cases. I'm not rushing because I do not want to fall into the trap of railroading objectivity...

In the mean time, I'll drop into this topic once in a while...

PK-KAR (a.k.a. MDL499 "On the other place")

[takata]

Hyperveloce:
In the Air Caraïbes case...

Air Caraïbes is the best documented sequence to understand what happened into the cockpit, but this is not fully comparable to what would be the ACARS sequence of this flight. Then, the difference should be notable in term of what would be triggered by the CMC (Central Maintenance Computer) e.g. when or what ACARS will be triggered and time stamped?

Some may be triggered by pilot fault clearance thru ECAM procedures (like NAV ADR DISAGREE). This is obvious from other reports when ECAMS warnings are showing by intermitence when speed (IAS DISAGREE) or other probes are showing large fluctuations. Each warning doesn't mean an ACARS is automaticaly triggered as it may be cleared by itself.

Beside, there is some difference with AF447 about the initial flight parameters (lower speed at Mach 0.80 and A/THR already OFF before the event). The TAT probes also seems to be frozen and the event didn't last more than 2 minutes. But other parameters are the same: altitude, weight (206 t), flying in tropical weather.

S~
Olivier

[PJ2]

takata;

they would be left to radio com and the aircraft had radio issues before departure).

Interesting - could you help out?...I don't recall reading this, (which just means, "I don't recall"); do we know what the nature of the issues was? Thanks!

they would be left to radio com and the aircraft had radio issues before departure).

Precisely.

As I mentioned early in the thread, with only the ACARS messages in hand, the investigative process would logically take each message in turn, look upstream to try to determine which fault might result from previous fault(s) to see what would generate the message, and downstream, to try to develop likely scenarios which might result from upstream failures and the "consequent" messages we see . This appears to be the approach taken with the work quoted from the Airliners.net forum - it will be interesting and helpful to see what the investigators come up with to see how close this is.

The temptation is to over-analyze is absolutely the case here - no wonder this is a mess. There is the latent problem too, to fall into the hind-sight bias trap if sufficient caution and suspension of judgement isn't exercised when examining the Air Caraibe and other incidents. That doesn't mean these incidents are to be dismissed - that would be equally inappropriate.

Thursday will hopefully be helpful with new information and not just a summary of what we have heard already.

[cpdlcads]

jcarlosgon post no 2599:

Yes but you have to turn off the 3 adrs to get this bu sdp scale/gps alt.
What I'd like is a permanent aoa readout

[Hyperveloce]

Originally Posted by PK-KAR

Yes, but that case is no way a twin of F-GZCP, a cousin at best... more work on the ACARS list is needed to even have a fair comparison of the two cases. I'm not rushing because I do not want to fall into the trap of railroading objectivity...

I don't get this because the two Air Caraïbes incidents occurred with two A330-200, and F-GZCP was an A330-203.
Jeff

[takata]

Hi PK-KAR,

Disagree in that... what else do we have?

Well, so you don't disagree.
My words, "too much reading" were about one intrepretation of your A.net post, not directed at your intrepretation of the ACARS, something I don't consider meaningless and, a contrario, very usefull as I was working on it myself.

Good job, you, Pihero and helpers.
S~
Olivier

[EGMA]

Quote: ADR DISAGREE : TOOK IT A LONG TIME TO APPEAR NOW !

Not surprising; there must be a built in time lag to be able to sample speed trends; otherwise we be seeing ADR DISAGREE with every bit of turbulence.

Re my earlier post on pitot icing and safetypee's helpful comments, a possible senario could be:-

(1) Icing of the pitot drains causes an apparent speed increase, a/c slows toward the stall.

(2) PHC 'catches up' with deicing the pitots, speed decreases.

(3) Software senses imminent stall; pitch down.

(4) Cascade of ACARS messages ...

I don't know what the time lag is on the ADR sampling is, but this could be happening in that time. It could also account for other occurences, such as Qantas.

I'm not saying this is what happened, but it fits what little evidence we have.

[takata]

Hi PJ2

PJ2:

they would be left to radio com and the aircraft had radio issues before departure).

Interesting - could you help out?...I don't recall reading this, (which just means, "I don't recall"); do we know what the nature of the issues was? Thanks!

This little detail was missed by a lot of people. When Eurocockpit investigated to find out the complete ACARS listing (not only the AIRMAN headers), they went into further details about the flight and posted this fact to prove AF/BEA they finaly found the good documents:

In Eurocockpit, June 19th paper:

Pour confirmer que nous avons bien trouvé les bons documents, nous indiquerons par exemple que l'avion est parti sous tolérance technique suite à un échange de RMP (boîtier de contrôle des radios), et qu'il est parti avec le RMP3 INOP, ce qui est par ailleurs parfaitement conforme à la MEL.

F-GZCP had a replacement of her Radio Management Panel (RMP) before departure and her RMP3 was listed INOP before the flight, but still in conformity with the MEL. It would be interesting to know if her last communication in flight with the Brazilian ATC @ 0133Z was made via SATCOM or radio.

S~
Olivier

[takata]

Hi Jeff

Hyperveloce:
I don't get this because the two Air Caraïbes incidents occurred with two A330-200, and F-GZCP was an A330-203.

Mandala meant the case is a cousin, not the aircraft. Do you know that Sarkozy is now flying one of this Air Caraibes A330 in place of his A319 considered too small for his big ego?
S~
Olivier

[augustusjeremy]

really a mess

A mess indeed... but look at the Qantas case, the preliminary report if I understand correctly reveal some potential problem linkage between the ADR and IR part of the boxes... which needs to be looked at....

PJ2,

The qantas case might be explained from IR1 providing wrong data to the calculations of the ADR1 output. AOA, calculated airspeed, etc all probably have an inertial component in their calculation/correction.

The opposite (an IR1 fault beginning with an ADR1) is apparently much harder to demonstrate.

What puzzles me the most in this AF447 case is that IR2 fault reporting...This is what is making me refuse to accept that the problem came - at least exclusively - from the pitot/static system.

It is not logical to have inertial data validated by air data - hence the name, inertial.

[takata]

@ augustusjeremy: IR and ADR
I have read (but I can't remember where) that the AOA function is slightly corrected by speed data (may be in the Quantas report). This would trigger a fault on this function without invalidating the AOA and could explain also the false stall warnings when the whole probe-static line is in trouble.

S~
Olivier

[augustusjeremy]

IR1 ?

This would trigger a fault on this function

You mean IR1 or AOA calculation itself ?

The qantas 72 has an IR1 fault reported.

If the AOA includes speed data, and if speed data includes inertial data - which I believe is correct - then an IR1 fault would indeed explain their problems with the AOA.

[Squawk_ident]

Do you know that Sarkozy is now flying one of this Air Caraibes A330 in place of his A319 considered too small for his big ego?

Correct. F-OPTP (they've received the new F-GOTO now) has left the Air Caraïbes fleet last month. And it is insulting for our President to say that he has a big ego. He has a Very Big Ego. And the pitot have been changed on this one.

[PK-KAR]

TATADRAOATIR *bangs head on table*

I don't get this because the two Air Caraïbes incidents occurred with two A330-200, and F-GZCP was an A330-203.

Not the aircraft... but the circumstances surrounding the events of interest!

My words, "too much reading" were about one intrepretation of your A.net post, not directed at your intrepretation of the ACARS, something I don't consider meaningless and, a contrario, very usefull as I was working on it myself.

OK then... and yes... reading it (even the translated version made by whoever) requires care due to context... that one is a big one... Context...

---
OK, now everyone is wondering about ADR, IR and AoA...
I wonder if the AoA estimator now links the ADR and IR together? Shouldn't, but then, perhaps someone can provide the details?

[takata]

augustusjeremy:
If the AOA includes speed data, and if speed data includes inertial data - which I believe is correct - then an IR1 fault would indeed explain their problems with the AOA.

My understanding is that ADR is not in charge of AOA calculation, because when ADRs are off, you still have an AOA displayed. If ADR is not doing the math, only the IR is left to do it as all the air data stream is directed to ADIRUs.
Or I'm wrong somewhere.

The ADRs provide a number of outputs to many systems and a blockage of the pitot and/or static systems may also lead to the following:
· SPD LIM flag on PFD
· Alpha floor activation (because AOA outputs from the sensors are
corrected by speed inputs)
· Wind shear warning (due to Mach input)
· Flap load-relief activation
· Flap auto-retraction from 1+F to 1
· Alpha lock on slats retraction (due to the speed logic part of the alpha lock function)
· ALTI DISCREPANCY on ECAM
· RUD TRV LIM FAULT ON on ECAM