Hi DozyWannabe,

I think the credit goes to Romasik, who found the info at the Aeroflot pilots' forum. :)

Thank you. I suppose that it's a case of looking at a situation logically, almost 'mathematically'...? I still don't know if what I suggested applies to our A330 situation, though.

Fair point - good catch, Romasik!

I'm deep into speculation here, but if (presuming I recall correctly), the two FMGC units have different software - in order to provide extra redundancy - then the occasional 4s discrepancy in calculating and transmitting the values between the two causes the "initialise" signal* to be set outside the 2s limitation required by the FCMCs.

I think I might be able to elaborate a little - but again, this is speculation - buyer beware! Regardless of the initialisation values, FCMC1 and FCMC2 have a current value which we'll call y1 and y2.

FMGC1 and FMGC2 each have a value and an "initialise" switch, which we'll call x1 and i1 for FMGC1, x2 and i2 for FMGC2. These are the values that are cross-checked against each other, and one of the causes of the ECAM message is if these values are not equal for more than 2s. If there's a discrepancy in calculation or transmission time between the two FMGCs, it seems that it can take up to 4s for one to "catch up" with the other.

The FCMCs will not 'blindly' update their "y" values with the "x" values sent from their respective FMGC unless the "i" value is true. So for argument's sake let's say FMGC1 transmits x1 and i1 to FCMC1 where i1 is "true", but there's a delay of over 2s before FMGC2 does the same.

Because i1 is true, FCMC1 will accept the value and set y1 to the same value as x1. If more than 2s passes before FMGC2 transmits x2 and i2, then y2 will still have the previous value - and because (x1,i1) and (x2,i2) are different (which will also make y1 and y2 different), ECAM will throw the error message.

Obviously I can't say for certain if this is indeed the cause of the issue, but as a working hypothesis it seems valid.

* - for non-techies, "boolean" is essentially 1 or 0, effectively yes/no or true/false.

EDIT: the above also certainly makes sence. I think the FCOM description of the message that Microburst2002 reminded us of, i.e. "the FCOM DES FUEL ECAM warnings says that the caution is triggered by discrepancy between FMC and FCMC, not between FMC1 and 2..." is a rather basic description of the process behind the warning, which, for the sake of simplicity, only addresses points 1 and 2 in Romasik's post and doesn't address the more technical third point:

DW, how do you interpret point 3?

In light of that, would you agree that a difference between the statuses (which I presume to mean the initialisation booleans) themselves, due to "a discrepancy in calculation or transmission time between the two FMGCs", would also be a trigger?

BTW, DW, a well-written and detailed post.

Cheers OG,

As I said, everything I'm posting is speculative, as I don't have hard data in front of me. That aside, I suspect the term "status" refers to both the x and i values coming from the FMGCs. The software will be polling values in real time and if there's a discrepancy in either for more than 2s, then the error condition will be triggered.

Regarding Microburst2002's post, the discrepancy being checked is of the statuses (x,i) coming from the FMGC/FMS - one side versus the other. Where FCMC seems to come into it is that it will not accept those values as being an initial setting without the "i" switch being set to true, regardless of which side we're talking about.

(NB : I got a bit mixed up in the post above - just corrected it.)

So all in all, we can attribute the spurious message to "the computers not talking to each other for a bit" :}:}

So, do you see yourself as becoming ain Airbus fuel system specialist, as well as a FCTL one?

If we were being pedantic it's more accurate to say that the computers are talking, but one isn't saying what the other wants to hear for a short period of time. :8

As for your other question, I'd never presume to consider myself either! I'm merely an enthusiast who has the benefit of a (non-aviation related) software engineering qualification on the one hand, but far more importantly on the other I've had the privilege of corresponding with people who really know their stuff and have very kindly shared a chunk of their information and experience with me.

That's very interesting, thanks for the info. http://images.ibsrv.net/ibsrv/res/sr...lies/smile.gif

Whatever, CONFiture
 

-Not necessarily, take the case of DC ESS failure causing a supposed Comms failure in the A320 family. It took BA to figure out that Comms were recoverable - much to the surprise of Airbus. (who by the way make a lovely aircraft) but it was not in the AOM, FCOM, QRH, or, on ECAM.

Jampot, you must realise, that just because something is or is not written does not mean that you can or cannot fly an aeroplane, even if it is an airbus.

FUEL ZFW/ZFCG DISAGREE
 

TFU 28:40:00:002 refers. (A330/A340) TFU 28:51:00:024 (A345/6)

It is caused by a synchronisation issue (transmission time) between FCMC and FM.
The latest softwareupgrades didn't solve the issue, they have re-opened the investigation by gathering information from SAR recordings.

Confirming of the entered data will in most of the cases solve this nuisance issue.
There is a workaround attached if the message returns after confirmation

Check your Tech support dept. for details.

Romasik had good reasons to investigate then ...
I had also noticed lately some unusual appearance of such ECAM message on different aircrafts, but none of the crew members or engineers on the spot could make sense of it.
What is a TFU ?
Where can we consult them ?

TFU = Technical Follow Up.

It is a centralized Airbus database with reported technical issues, updated on a regular base with findings, interim actions, workarouds and final status.

I don't know how your organization is constructed, ask your flight technical dept or chief / engineering pilot,
they should know about it and also how to gain access to this documents (webbased AIRBUS WORLD and/or AIRMAN web),
or contact the Airbus local customer support representative

I cannot post the relevant TFU myself because it depends on type variants and the software status of your aircraft.

Thank you A33

I accidentally transposed two digits of the EZFW this morning, (e.g. 114.4 instead of 141.4) and got an immediate 'ZFWCG/ZFW disagree' caution. So the aircraft must have a look-up table to compare ZFWCG/ZFW figures, and reject any that don't make sense.


U

Spot on. To give a general example, nowhere in the respective manuals of the B747, DC-10 or A300 explains or promotes the use of asymmetric thrust to provide directional control in the event of total hydraulic failure, but it has been done by line crews who were out of "official" solutions with varying degrees of success (including a somewhat hairy but safe landing in the case of the DHL A300 over Iraq, and a famous recovery of a "worst case scenario" in which most onboard survived in the case of the UAL DC-10 at Sioux City).

Ultimately an aircraft is a tool for the end users (in this case pilots) to use in whatever way is necessary to perform their jobs. By and large they are engineered well enough to provide solutions outside of normal operating parameters should it be necessary.