A330 ZFW/ZFCG DISAGREE

[Romasik]

Could someone enlighten me, what this ECAM message means?
Ok, FCOM says: "One FCMC detects that the ZFW or ZFCG data from FMGEC 1 and FMGEC 2 disagree". Still doesn't make much sense to me. Disagree with what?:confused:

[EIU_EEC]

In 320 FM1/FM2 GW message on scratchpad in mcdu means 2 tons of weight difference between onside ans offside fmgc..may be same sort for 330.

[9.G]

it's a daily business, just check the ZFW and CG reinsert it and move on. If it comes up again simply clear it. :ok:

[Romasik]

Well, we clear it, we reinsert it - no problem:) But, the question remains: what data does the FCMC compare with inserted data? How does the aicraft know what is right or wrong???

[nitpicker330]

Jesus it's an Airbus so who knows what it's thinking or doing.

Try cycling the Left Landing light, that usually fixes most problems on the Bus!!

Who knows what is connected to what in this thing.

Seriously we see this message a lot after entering the MACZFW/ZFW when we get the loadsheet and the data is always checked ok twice to make sure of no finger trouble....

So who knows........:bored:

[cav-not-ok]

isn't it the MACZFW and ZFW?

[nitpicker330]

Yes sorry, on holidays and far away from work!! Brain slip :ok:

[mutley320]

Have you already entered a "planned" ZFW ? If so , i think it is just questioning why you have changed this again as you enter the actual value from the loadsheet.

[CONF iture]

"One FCMC detects that the ZFW or ZFCG data from FMGEC 1 and FMGEC 2 disagree".
Still doesn't make much sense to me. Disagree with what?
With each other.
Confirm that the ZFW and ZFCG values from each FMGC are the same as the loadsheet value.
Maybe the figures inserted through one MCDU are different from the one previously inserted through the other unit.

[Romasik]

BTW, today we gave it a try: entered completely crazy CG data (30% instead of 21% from the loadsheet) and DIDN'T GET ANY MESSAGE... And the stab trim set itself based on that figure from the moon...:ooh:
So, it doesn't protect from the crew entry mistakes. What the hell is the meaning and the purpose???

[Romasik]

With each other.
Confirm that the ZFW and ZFCG values from each FMGC are the same as the loadsheet value.
Maybe the figures inserted through one MCDU are different from the one previously inserted through the other unit.

We only insert it in one MCDU and sometimes get the message...

[Romasik]

mutley320

Have you already entered a "planned" ZFW ? If so , i think it is just questioning why you have changed this again as you enter the actual value from the loadsheet.

Nope. We don't enter anything in advance. Only the actual data from the loadsheet.

[CONF iture]

Did you notice if the message is showing after you inserted the fuel figure but the fuel is not yet on board ?
I understand you have the on ground auto trim setup option, would you have an option for the aircraft to estimate its CG through the landing gear ?
I believe the best option would be to directly question Airbus through your management. This is a very interesting question.

[Romasik]

Did you notice if the message is showing after you inserted the fuel figure but the fuel is not yet on board ?
I understand you have the on ground auto trim setup option, would you have an option for the aircraft to estimate its CG through the landing gear ?
I believe the best option would be to directly question Airbus through your management. This is a very interesting question.

The fuel is done, ready to go, inserting ZFW/ZFWCG and sometimes getting the message, sometimes not. Today absolutely wild CG didn't trigger any message... and the stab trim set itself automatically accordingly that wild entry.
Looks like there is nothing there to measure the actual CG. We only enter the starting point and then the FCMC calculates CG change with fuel movement and carries on the initial entry mistake, if any. But the ECAM message and its explanation in the FCOM are totally confusing and don't fall in line with my understanding of the system.

[CONF iture]

Unfortunately it's easier to get the answer on the forum rather then through management
I see and it is a pity. Airbus will not consider a pilot's question, but they have to reply to a chief pilot. We can get very reliable information on a forum but the manufacturer is the only one to exactly know what is in the beast.

[TyroPicard]

It is just a communication error between computers... On the ground the pilots are the source of ZFW + ZFWCG information for FMGEC's and therefore the FCMC's, which send the GW values back to FMGEC....so it is important to cross check the correct value each side.
Once airborne the FE portion of the FMGEC does some smart calculations to cross check the GW values and warns you if there is an error.

These glitches happen - the important question is what should you check?

[Uplinker]

Interesting stuff.

I've only seen this after I've done a manual loadsheet on an A330, and got the ZFW index and %MAC figures slightly wrong or misread them in the badly lit cockpit, and which would have led to an incorrect THS setting for T/O.

However, the very senior training captain I was with once when it happened, didn't know what it meant !!

[A33Zab]

the important question is what should you check?

Check the 'Abnormal and emergency procedures' ATA 28 section in FCOM

it says:

"Confirm that the ZFW and ZFCG values from each FMGC are the same as the loadsheet value."

[nitpicker330]

Strange as only some of our new A330's give this message.

Our SOP is to insert 25/ZFW and Block Fuel as we setup the Perf initially from the Flight Plan.

Then later with the loadsheet we enter the actual data into the PF's and the PM checks his CDU at the same time as we move through final setup.

The message then pops up instantly the data is inserted even though both screens show the same figures???

I've never seen an error.

[A33Zab]

The entered values are used for GW/GWCG calculation by FMGEC and FCMC.

The FCMC calculations are used for CG control and is the primary source for FM and FG.
The FMGEC values is the backup source for FM, FG and is primarly used for AFT CG monitoring.
(as watchdog for FCMC CG control)

Now if there is any difference between the ZFW/ZFCG values in FCMC and FMGEC (No W&B system fitted),
this message will be triggerd to check and confirm by reentering the values.

http://i474.photobucket.com/albums/rr101/Zab999/CW_CG_zps6a522af9.jpg

[Uplinker]

Just out of interest, A33Zab, where does that diagram come from?

[A33Zab]

A330 AMM ATA22-62 AutoFlight FE COMPUTATION

[Uplinker]

Thanks.....

[CONF iture]

No W&B system fitted
Can you tell us more about that one, is it an option ?

[A33Zab]

Not that I'm aware off,
however there is a connection on LGCIUs reserved for optional W&B.
Freighter and/or MRTT ??

[Romasik]

A33Zab:

Nice diagramm, but it's not answering the post question. FCMC takes over CG calculation only after initial ZFCG and ZFW entered by pilots. It does't have anything to compare these values with (unless aicraft if fitted with weight and balance system).
Also I can't see why data in two FMGSs could be different. They are cyncronized and once your enter numbers in one of them they immediatelly pop up in the other one.
Today we did it again: this time entered ZFW and ZFWCG well outside aircraft limitations. And - no effect. Not a single message! How nice for such an advanced aircraft...

[Bpalmer]

I've had this message several times on A330 and found that a reset of the FCMC's has always fixed the problem.
You've got a 50/50 chance of getting the correct one the first time.
Usually as soon as the reset button for the offending FCMC is pulled the message will clear.

[DozyWannabe]

It's for cross-checking the data that ends up in the FMGECs against each other. It's not for checking the entered data against max/min values or anything else along those lines - it is an internal comparison only.

[johnriney]

A330 AMM ATA22-62 AutoFlight FE COMPUTATION

[Romasik]

It's for cross-checking the data that ends up in the FMGECs against each other. It's not for checking the entered data against max/min values or anything else along those lines - it is an internal comparison only.

The data in both FMGECs is synchronized. They don't compute the CG/ZWF initial data. It's a pure mechanical entry and there is no reason for them to be different like any other pilot input. Yet the message comes quite often.

[DozyWannabe]

Normally, yes. I suspect the cross-check is to highlight a failure of the computer software or hardware, should one exist.

[TyroPicard]

Romasik
Also I can't see why data in two FMGSs could be differentThat is not necessarily the case. The error could be at the FCMC end, or the data may not have been sent correctly, or got lost on the way.....
Just re-enter the ZFW + CG, or reset the FCMC's and then re-enter the data.

[Romasik]

This message comes too often to be a failure. And, BTW, there is a NORMAL SOP for that case:
"‐ Check the loadsheet CG, against the ECAM CG. In case there is a discrepancy of more than 2 %, check that the ZFW and the ZFWCG have been correctly inserted in the MCDU, then rely on the ECAM CG. If the difference is less than 2 %, no further action is required. Rely on the ECAM CG."
Once again, it says to check that the ZFW and ZFWCG are correctly inserted, which is totally irrelevant. As I already said, you may enter complete BS outside the aircraft limitations and in most cases get no message. So, the original post question remains open...

[TyroPicard]

My last attempt....
Each FCMC receives ZFW and ZFWCG from both FMGEC 1+2 - two independent values which should be the same.
Each FCMC compares the values it receives from FMGEC 1 with the values it received from FMGEC 2
If a FCMC detects a disagreement between the values it has been sent, it gives you an ECAM message.
IT HAS NOTHING TO DO WITH LIMITATIONS.......OR BS VALUES.
please excuse the shouting.....

[Romasik]

TyroPicard:

Still I don't see any sense. The data entered into each FMGEC is identical. Why should it in turn supply FCMC with different data and not once in a while but quite often? What kind of processing is going on with a simple entry of CG and ZWF? It's just what it is and doesn't require any processing. As long as aircraft by itself is not capable of calculating the actual CG and weight, all calculations around the initial pilot data entry are useless.

[A33Zab]

all calculations around the initial pilot data entry are useless.

useless?


FG and FCPC control laws affected.
Vs1g speed calculation affected.
Wrong TO THS setting.
FM predictions and speeds affected.
PFD characteristic speed accuracy affected.
Optimum CG control by FCMC affected.
SD permanent data GW/GWCG unaccurate.

probably forgetting a few...

[Romasik]

A33Zab:

Come on!:) I mean, there is nothing that any aircraft computer can do to alter initial pilot entry of ZFW/ZFWCG. Whatever you enter, even complete BS - will be used as a starting point for data processing. And I don't see any reason why this starting point would become different in FMGEC1 and FMGEC2.

[Microburst2002]

ZFW ZFCG DISAGREE
Disagreement between pilot entered values and FCMC values
From DSC FUEL


In my opinion, since zfw can only be pilot entered but fuel quantity can also be FCMC sensed, a difference between pilot entered FOB and or ZFW/ZFCG in INIT B page can lead to a difference between GW/GWCG calculated by FCMC and FMC. However the caution refers to ZF values which are obviously independent of fuel and can only be pilot entered...

[Romasik]

Microburst2002:

I also see only fuel traces in this story. In particular the message often comes when there was no fuel taken on turnaround, i.e. fuel distribution may be not standard.

[Old Grouch]

The FCMC calculations are used for CG control and is the primary source for
FM and FG.
The FMGEC values is the backup source for FM, FG and is primarly
used for AFT CG monitoring.
(as watchdog for FCMC CG control)




I remember coming across this a long, long time ago. If memory serves me right, isn’t it the case that the FCMC used the pilot-entered ZFWCG and calculates the GWCG by taking the actual fuel mass/distribution onboard on a per-tank basis, whereas the FMGC used the pilot-entered ZFWCG and calculates the GWCG by assuming a standard fuel distribution for any given FOB? A non-standard fuel distribution would, of course, result in a different fuel CG effect and hence, a difference between the GWCG outputs from the FCMC and FMGC.



Also, had you already entered a BLOCK figure in INIT B when the message appeared?

[Romasik]

I remember coming across this a long, long time ago. If memory serves me right, isn’t it the case that the FCMC used the pilot-entered ZFWCG and calculates the GWCG by taking the actual fuel mass/distribution onboard on a per-tank basis, whereas the FMGC used the pilot-entered ZFWCG and calculates the GWCG by assuming a standard fuel distribution for any given FOB? A non-standard fuel distribution would, of course, result in a different fuel CG effect and hence, a difference between the GWCG outputs from the FCMC and FMGC.



Also, had you already entered a BLOCK figure in INIT B when the message appeared?


It slowly starting making some sense:)
Normally the BLOCK fuel is already there. Then we enter ZFW/ZFWCG and finally get the message.

[Old Grouch]

Normally the BLOCK fuel is already there. Then we enter ZFW/ZFWCG and finally
get the message.

The time it happened to me, we had done exactly the same.

I'm fairly confident that it's something to do with the difference between the actual FOB and the pilot-entered BLOCK figure in INIT B, and the consequent difference in the result of a particular calculation that the FCMC and FMGC each do. I just can't, for my life, remember the precise definition. :ugh:

One thing that doesn't help is the lack of (clear) information from Airbus regarding this - it's just a case of us knowing the logic that the computers use and what is done with what figure. Cue the discussion that the airplane is a flying computer program. :E

[nitpicker330]

1/ loud "ding" ECAM. Scares ya, now read the ECAM.

FCOM 3 says the message:-----


FUEL ZFW ZFWCG DISAGREE

This caution is triggered in case of disagree between ZFW or ZFCG values from FMGC 1 and 2.
– FMGC VALUES. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONFIRM Confirm that the ZFW and ZFCG values from each FMGC are the same as the loadsheet values



2/ both crew double check their respective CDU's contain correct info as per loadsheet.
3/ Breath
4/ move along........these things happen.:ok:

[Microburst2002]

The way I look at it, there is no ZFW nor ZFCG computation. They are always pilot entered. There is no way that those values differ from FMGC computed ones because the FMGC does mot compute any ZF values.

The FMGC only computes GW values (and TO and LDG) bases on ZF and block fuel pilot entered inputs

Now, if there is a difference between FCMC computed GW and/or GWCG (which use pilot entered ZFW, ZFCG and FCMC sensed fuel quantity) and FMGEC's (which also use pilot entered ZFW & ZFCG)... Why does it trigger a ZFW/ZFCG discrepancy? It is clearly a fuel related discrepancy, that of pilot entered block and sensed quantity, and even the ECAM is a FUEL one.

Is there any ECAM alerting from a difference between FCMC and FMC fuel quantity?

[Old Grouch]

The way I look at it, there is no ZFW nor ZFCG computation. They are
always pilot entered.


Absolutely correct. Perhaps I wasn't clear earlier. When I said "...and the consequent difference in the result of a particular calculation that the FCMCs and FMGCs each do", I meant a calculation that uses ZFW/ZFWCG values to derive another value (the GW/GWCG), not a calculation that reults in in the ZFW/ZFWCG. The ZFW/ZFWCG are indeed always pilot-entered and, of course, are the starting point of the calculations.


It is clearly a fuel related discrepancy

I quite agree. Incidentally, when we got this message, like Romasik says, we had indeed not uplifted any fuel on a turnaround.

We can apply the relevant procedure, but without knowing the 'thought process' of the system behind the message, it's difficult to gain a full understanding of it and its background.

[Old Grouch]

Thank you for the additional info, A33Zab. For the record, we did not do an autoland prior to having the message.

[Microburst2002]

Hmmm

Quite complicated isaue, isn't it

Is pilot entered block fuel ever used for any computation?

[Old Grouch]

Is pilot entered block fuel ever used for any computation?

I no longer have my A330 manuals and I can't seem to find the full set online. I don't want to rely on memory and potentially also mix it up with any A320-specific information that I was also on, so I wouldn't like to give a precise answer, which would be conter-productive, if wrong. In other words, take what I say with a pinch of salt.

Anyway, from what I could find/remember:

"The FMGC computes the FPLN predictions, based on the entered BLOCK fuel, and estimates the EXTRA fuel value." - this is before engine start.

"After engine start, the FMGC will stop using the pilot-entered block fuel and will compute its predictions based on the FOB indicated by the FCMC"

Perhaps the same before/after-engine-start logic applies to the FMGC GW/GWCG calculation? I.e. the BLOCK value is used in the FMGC GW/GWCG calculation before engine start? If so, a difference of sufficient mangitude between the actual FOB and the BLOCK values would result in differing FCMC and FMGC GW/GWCG values and hence the message.

Apoligies if I am talking rubbish here.

EDIT: Perhaps Mr DozyWannabe has some info?

[DozyWannabe]

Alas I don't have any specifics on this system right now.

[Romasik]

Regarding the fuel figures. We always enter the exact value displayed on ECAM (well, maximum +/- 50 kg) and still get the message...

[Old Grouch]

Regarding the fuel figures. We always enter the exact value displayed on ECAM (well, maximum +/- 50 kg) and still get the message...

So more or less back to square one. :ugh:


Alas I don't have any specifics on this system right now.


Then your quest awaits, Sir!

Joking aside and rather off-topic, this reminds me a lot of the 'CG DISAG (FUEL)' message that one could get on the MD11. Similarly to the Airbuses, the setup here was that the loadsheet ZFW/ZFWCG values are entered in the WEIGHT INIT page (the MD11 equivalent of INIT B. Infact, the MD11 CDU interface is a lot like the Airbus MCDU one, albeit rather more basic, e.g. no colours) and are then used by the FSC (Fuel System Controller) to calculate and display the GW/GWCG on the SD.

The important difference, of course, is that in addition to the ZFW/ZFWCG, the loadsheet TOW/TOCG are also entered in the FMS. Now, if one entered wrong TOW/TOCG values, which were sufficiently different to the FSC-derived GW/GWCG (there is some tolerance; to account for taxi fuel, for one), after start-up, one would get the aforementioned 'CG DISAG (FUEL)' message, defined as:

CG DISAG (FUEL) - Disagreement between the aircraft CG displayed on the SD and the CG entered in the FMS. Confirm fuel load and entered data.

This would happen more often if doing a manual loadsheet (ours were drop-line type), as the 'CG change due to fuel' measurement on a manual loadsheet is, ofcourse, less precise than that of a computer loadsheet or the FSC calculation.

So in summary of the above, on the MD11, there is a clear opportunity for a weight/CG discrepancy. Where is discrepancy arising on the A330?
Perhaps it's just a case of a momentary lapse of communication between the FMGECs/FCMCs? Or a case of a GWCG based on an assumed/standard fuel distribution in the FMGECs vs actual/non-standard fuel distribution in the FCMCs?

Uplinker, I got your post in a notification email, but it seems that you've deleted it from the forum?

[Romasik]

Where is discrepancy arising on the A330?
... Or a case of a GWCG based on an assumed/standard fuel distribution in the FMGECs vs actual/non-standard fuel distribution in the FCMCs?


Looks like having the most sense.
As an additional factor it could also be a case of french english. They should have hired a team of native speakers to take part in creating/maintaining aircraft/human interface. I never thought that reading simple phrases in english english, like:
CG DISAG (FUEL) - Disagreement between the aircraft CG displayed on the SD and the CG entered in the FMS. Confirm fuel load and entered data.
would give so much pleasure compare to the respective Airbus FCOM phrase:)

[Old Grouch]

That's all certainly true. The writing style and logic of the FCOMs certainly has its distinct 'flavour'. :)

[Romasik]

Here we are. Got it from Aeroflot pilot's forum:

Description
1) What are the conditions to trigger the "FUEL: ZFW/ZFCG DISAGREE" message?

2) How can be triggered a spurious "FUEL: ZFW/ZFCG DISAGREE" message?

Solution
1) The conditions for the FCMC to trigger the ECAM warning "FUEL: ZFW/ZFCG DISAGREE" are the following:
1- the value of ZFW sent by the FMS differs between side 1 and side 2 of more than 100 lbs,
or
2- the value of ZFWCG sent by the FMS differs between side 1 and side 2 of more than 0.025 %,
or
3- during the initialization/re-initialization process, the status of ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2 seconds.

2) Investigation of the spurious cases of ECAM warnings "FUEL: ZFW/ZFCG DISAGREE" on A330/A340 basic aircrafts showed that when a ZFW/ZFWCG is inserted on one MCDU, each FMS will send these values to their onside FCMC with a boolean set to high (to indicate to the FCMC to init/re-init the values) during a few seconds. But, the setting/resetting of the high position for this boolean is not synchronized between both FMSs. A delta of more than 4 s may be observed.
And because of the 3rd condition, the FCMC issues the message.

This FMS/FCMC interface issue is addressed in the FMS "Release 1A" (R1A) standard.

[Uplinker]

Uplinker, I got your post in a notification email, but it seems that you've deleted it from the forum?

Hi Old Grouch. Not intentionally; My PC, or the Pprune site were doing really weird things to my attempted posts the other day - putting them in the middle of the thread instead of at the end etc. If you can, please would you repost my post?

[Old Grouch]

Investigation of the spurious cases of ECAM warnings "FUEL: ZFW/ZFCG
DISAGREE" on A330/A340 basic aircrafts showed that when a ZFW/ZFWCG is inserted
on one MCDU, each FMS will send these values to their onside FCMC with a boolean
set to high (to indicate to the FCMC to init/re-init the values) during a few
seconds. But, the setting/resetting of the high position for this boolean is not
synchronized between both FMSs. A delta of more than 4 s may be observed.
And
because of the 3rd condition, the FCMC issues the message.


Excellent, thank you for that. So something akin to "a momentary lapse of communication".

Hi Old Grouch. Not intentionally; My PC, or the Pprune site were doing really
weird things to my attempted posts the other day - putting them in the middle of
the thread instead of at the end etc. If you can, please would you repost my
post?

Certainly, here we go:

Yes; pilot entered block fuel is used to make initial calculations according to the flight plan and winds.

This gives a gross error check; that the FMGEC (A330) agrees with the paper flight plan that fuel on board will be sufficient, given the winds, to complete the flight with sufficient reserve.

Later after engine start, the system refines its predictions based on actual fuel on board.

In our company we enter an estimated ZFW/ZFWCG after inputting the flight plan and winds. I've had the ECAM caution in question when taxying away after a turnaround in which we uploaded fuel, and after engine start (obviously). But ONLY when we have done a manual load sheet. I am trying to remember what we do differently with data inputs when we do a manual loadsheet. Perhaps we enter the estimates on one MCDU and the actuals on the other? Then if the FMGEC's don't talk to each other properly, we get the discrepancy and the caution?

Thank you, everybody who contributed. :)

[Magnetic Iron]

2- the value of ZFWCG sent by the FMS differs between side 1 and side 2 of more than 0.025 %

For me this is the common reason that is why I do not pay too much attention to this software glitch

[Microburst2002]

However, the FCOM DES FUEL ECAM warnings says that the caution is triggered by discrepancy between FMC and FCMC, not between FMC1 and 2... Why is it all so confusing??

[Old Grouch]

The way I understood/presumed it to be (not being a software engineer, it is pure speculation on my part, apologies if it is rubbish), is that it comes down to this:

during the initialization/re-initialization process, the status of ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2 seconds.


But, the setting/resetting of the high position for this boolean is not synchronized between both FMSs


So, let's take it step-by-step:
-Presumably, prior to a ZFW/CG entry in INIT B, each FCMC stores either a blank or a '0' value for this data. Let's call this value 'x'

-A 'boolean' setting tells the FCMCs whether ZFW/CG data (let's call this ZFW/CG value 'y') from the FMGCs is being sent to them for their initialisation. If this 'boolean' setting is signalling an initialisation, the respective FCMC accepts it as given and stores the new value.

-If the 'boolean' status is not signalling an initialisation, because, according to the quote above, it is not synchronised between the FMGCs, (the following is pure speculation on my part) as a safeguard, the respective FCMC does not accept the new value, e.g. because it could be a spurious/uncommanded signal.

-So, in one of the FCMCs, the previously-stored value 'x' does not equal the newly-sent, but rejected, FMGC value 'y', which triggers the message.

[DozyWannabe]

For me this is the common reason that is why I do not pay too much attention to this software glitch

Judging by the info Old Grouch unearthed, it's not a glitch so much as a redundancy safety feature that sometimes gets triggered with real-world values.

@OG - As a software engineer, I think it looks like you've got a good, succinct description there - not rubbish at all!

[Old Grouch]

Hi DozyWannabe,


Judging by the info Old Grouch unearthed


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

As a software engineer, I think it looks like you've got a good, succinct description there - not rubbish at all!

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.

[DozyWannabe]

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.

[Old Grouch]

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:

1- the value of ZFW sent by the FMS differs between side 1 and side 2 of more than 100 lbs,
or
2- the value of ZFWCG sent by the FMS differs between side 1 and side 2 of more than 0.025 %,
or
3- during the initialization/re-initialization process, the status of ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2 seconds.

[Old Grouch]

DW, how do you interpret point 3?


3- during the initialization/re-initialization process, the status of
ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2
seconds.


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.

[DozyWannabe]

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.)

[Old Grouch]

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?

[DozyWannabe]

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.

[Old Grouch]

That's very interesting, thanks for the info. http://images.ibsrv.net/ibsrv/res/src:www.pprune.org/get/images/smilies/smile.gif

[Natstrackalpha]

I see and it is a pity. Airbus will not consider a pilot's question, but they have to reply to a chief pilot. We can get very reliable information on a forum but the manufacturer is the only one to exactly know what is in the beast.

-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.

[A33Zab]

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.

[CONF iture]

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.
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 ?

[A33Zab]

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 (http://www.airbus.com/worldwide/)

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

[CONF iture]

Thank you A33

[Uplinker]

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

[DozyWannabe]

...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.

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.