A330 ZFW/ZFCG DISAGREE
Join Date: Apr 2012
Location: London
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
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.
Judging by the info Old Grouch unearthed
As a software engineer, I think it looks like you've got a good, succinct description there - not rubbish at all!
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by DozyWannabe; 21st Jan 2013 at 20:45.
Join Date: Apr 2012
Location: London
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by Old Grouch; 21st Jan 2013 at 20:20.
Join Date: Apr 2012
Location: London
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
ZFW/ZFWCG sent by the FMS differs between side 1 and side 2 during more than 2
seconds.
BTW, DW, a well-written and detailed post.
Last edited by Old Grouch; 21st Jan 2013 at 20:28.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.)
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.)
Last edited by DozyWannabe; 21st Jan 2013 at 20:49.
Join Date: Apr 2012
Location: London
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
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?
So, do you see yourself as becoming ain Airbus fuel system specialist, as well as a FCTL one?
Last edited by Old Grouch; 21st Jan 2013 at 21:35.
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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. 
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.
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.
Join Date: Jan 2012
Location: Not far from the edge of the Milky Way Galaxy in the Orion Arm.
Posts: 510
Likes: 0
Received 0 Likes
on
0 Posts
Whatever, CONFiture
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.
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.
Join Date: Jun 2009
Location: somewhere
Posts: 451
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Last edited by A33Zab; 28th Jan 2013 at 09:12.
Join Date: Jan 2005
Location: W of 30W
Posts: 1,916
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by A33Zab
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.
The latest softwareupgrades didn't solve the issue, they have re-opened the investigation by gathering information from SAR recordings.
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 ?
Join Date: Jun 2009
Location: somewhere
Posts: 451
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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
U
Join Date: Jul 2002
Location: UK
Posts: 3,093
Likes: 0
Received 0 Likes
on
0 Posts
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.
Last edited by DozyWannabe; 31st Jan 2013 at 13:57.
