Airbus clock/internal time
Thread Starter
Join Date: Nov 2000
Location: Worldwide
Posts: 102
Likes: 0
Received 0 Likes
on
0 Posts
Airbus clock/internal time
Having some problems with our aircraft clock and internal time.
Every time we set the aircraft clock selector to GPS we get the right time in but incorrect month and date in 1992. This combined gives the ACARS problems when determining the time like in flight log, instead of number 0 it displays letter A and for 1- B so for 10:00 it would display A0:00 etc. Also FMGS displays message Check data base cycle while database is valid. We tried switching the clock ourselves manually to INT and setting date this helped with the ACARS so no letters replacing numbers but still check database cycle message all the time.
It seems strange to me that the clock dosnt show the exact time taken from GPS and if INT selected with correct date set still problems.
Would setting the internal clock via SET sector help?
Every time we set the aircraft clock selector to GPS we get the right time in but incorrect month and date in 1992. This combined gives the ACARS problems when determining the time like in flight log, instead of number 0 it displays letter A and for 1- B so for 10:00 it would display A0:00 etc. Also FMGS displays message Check data base cycle while database is valid. We tried switching the clock ourselves manually to INT and setting date this helped with the ACARS so no letters replacing numbers but still check database cycle message all the time.
It seems strange to me that the clock dosnt show the exact time taken from GPS and if INT selected with correct date set still problems.
Would setting the internal clock via SET sector help?
Join Date: Sep 2004
Location: France
Age: 47
Posts: 161
Likes: 0
Received 0 Likes
on
0 Posts
I think that the answer is in your SOP. In my FCOM PRO-NOR-SOP-06 P 4/18 it says :
"The ADIRS outputs are used by many of the aircraft's systems: Set the selectors to NAV at least 12 min after aircraft power up. This is to avoid an incorrect date initialization."
Some msn are affected by this procedure, anyway try to set the ADIRS to NAV 12 minutes after aircraft powe up , this should solve your problem.
"The ADIRS outputs are used by many of the aircraft's systems: Set the selectors to NAV at least 12 min after aircraft power up. This is to avoid an incorrect date initialization."
Some msn are affected by this procedure, anyway try to set the ADIRS to NAV 12 minutes after aircraft powe up , this should solve your problem.
Last edited by Citation2; 14th Sep 2012 at 12:34.
...still looking for some reference. Our affected aircraft have a note in the TLB but so far I didn't manage to find an official statement from Airbus.
On the affected aircraft the ATSU date output is immediately scrambled (time show like B1:21 instead of 01:21) as the clock is switched to GPS. Other aircraft can use GPS time just fine.
Also the MSN of the affected aircraft don't seem consecutive, some are older, some brand new.
On the affected aircraft the ATSU date output is immediately scrambled (time show like B1:21 instead of 01:21) as the clock is switched to GPS. Other aircraft can use GPS time just fine.
Also the MSN of the affected aircraft don't seem consecutive, some are older, some brand new.
As a NG driver with a background in software development, I really ask myself how on earth this can happen?
This appears to be either: A failure in the ADIRU s/w to ignore an input if its not in a mode in which it can handle it properly. Or a poorly written output formatting routine that doesn't recognize invalid internal data and attempts to format it to the output, no matter what. Or both.
And why is this not caught during QA?
It got through QA because the procedure (just don't use GPS input) was sufficient for a pass. If it said, "Pat your head, whistle and face Mecca" it would have passed as well.
Join Date: Mar 2011
Location: engineer at large
Posts: 1,409
Likes: 0
Received 0 Likes
on
0 Posts
fortran is fortran! 
in diving into the box, the programming seems to keep building over the years, rather than start over and revise the coding.
I have found several instances, where calculations have been added in several places, and are in conflict with each other, and rather than fix the conflicts, a workaround is added.
Look at 10.8, fully vetted and approved, yet a disaster installed....10.8a fixed somethings, but added other conflicts...
in diving into the box, the programming seems to keep building over the years, rather than start over and revise the coding.
I have found several instances, where calculations have been added in several places, and are in conflict with each other, and rather than fix the conflicts, a workaround is added.
Look at 10.8, fully vetted and approved, yet a disaster installed....10.8a fixed somethings, but added other conflicts...
Join Date: Jun 2012
Location: VTVJM
Age: 68
Posts: 102
Likes: 0
Received 0 Likes
on
0 Posts
I think that the answer is in your SOP. In my FCOM PRO-NOR-SOP-06 P 4/18 it says :
"The ADIRS outputs are used by many of the aircraft's systems: Set the selectors to NAV at least 12 min after aircraft power up. This is to avoid an incorrect date initialization."
Some msn are affected by this procedure, anyway try to set the ADIRS to NAV 12 minutes after aircraft powe up , this should solve your problem.
"The ADIRS outputs are used by many of the aircraft's systems: Set the selectors to NAV at least 12 min after aircraft power up. This is to avoid an incorrect date initialization."
Some msn are affected by this procedure, anyway try to set the ADIRS to NAV 12 minutes after aircraft powe up , this should solve your problem.
Maybe they have changed it...
Thread Starter
Join Date: Nov 2000
Location: Worldwide
Posts: 102
Likes: 0
Received 0 Likes
on
0 Posts
Interesting reading guys& gals thanks keep the info coming.
Problems Im having are on the A318 . Indeed as mentioned above we have the Statement about 12min in FCOM however this dosnt help. We just permanently fly with clock on INT and correct date/time set. However still get check database cycle on MCDU even though all correct. To add to issues airshow also started thinking it was wintertime last week.
Problems Im having are on the A318 . Indeed as mentioned above we have the Statement about 12min in FCOM however this dosnt help. We just permanently fly with clock on INT and correct date/time set. However still get check database cycle on MCDU even though all correct. To add to issues airshow also started thinking it was wintertime last week.
Join Date: Dec 2010
Location: Iceland
Age: 60
Posts: 48
Likes: 0
Received 0 Likes
on
0 Posts
This is a common problem with the A320 series MMRs, kept us busy for a few nights!
Essentially; "The MMR expects to be connected to the GPS network for at least 3 minutes every 512 weeks (approx 9 years) to update the internally stored initialisation date. Therefore, if the difference between the initialisation date and the date provided by the GPS satellites is greater than 512 weeks, the MMR believes itself to have been powered down for longer than is acceptable and the GPS-week-rollover algorithm, which is not equipped for such an event, calculates a date in error"
The "connected to the GPS network" cannot be done on-wing.
Depending on your MMR manufacturer, there are two TFUs from Airbus;
Thales MMR: 34.36.31.009
Rockwell Collins MMR: 34.36.33.001.
With the Thales MMR there is a 'quick fix' that resets the GPS date and fixes the issue, by taking a 'Healthy' MMR from another aircraft (instructions in the TFU).
Essentially; "The MMR expects to be connected to the GPS network for at least 3 minutes every 512 weeks (approx 9 years) to update the internally stored initialisation date. Therefore, if the difference between the initialisation date and the date provided by the GPS satellites is greater than 512 weeks, the MMR believes itself to have been powered down for longer than is acceptable and the GPS-week-rollover algorithm, which is not equipped for such an event, calculates a date in error"
The "connected to the GPS network" cannot be done on-wing.
Depending on your MMR manufacturer, there are two TFUs from Airbus;
Thales MMR: 34.36.31.009
Rockwell Collins MMR: 34.36.33.001.
With the Thales MMR there is a 'quick fix' that resets the GPS date and fixes the issue, by taking a 'Healthy' MMR from another aircraft (instructions in the TFU).
Last edited by T.R Haychemu; 17th Sep 2012 at 12:43.
Join Date: Aug 2009
Location: Takeshima
Age: 55
Posts: 99
Likes: 0
Received 0 Likes
on
0 Posts
Many suns ago a senior colleague flew a A330 from KUL to ADL despatched under MEL with a wing tip breaker fault. This was despatchable for 10 days after which the system locks out, meaning repair must be made within 10 days.
After landing at ADL and getting to sleep at the layover hotel he was frantically awakened by the station manager who wanted to know why he had brought a broken aircraft to ADL! To cut a long story short, the aircraft was AOG due to the WTB locking out entirely! The engineers at ADL and maintenance control at KUL couldn't figure out; neither did the Airbus technical representatives. The station manager, in all his wisdom, thought the inbound crew had f**ked up the system during the flight from KUL to ADL! The inbound skipper was none too pleased to have been woken rudely and accused of f**king up the aircraft. After much discussion, the skipper wryly asked if anybody had messed with the aircraft clock! Voila, somebody did....the outbound f/o was resetting the
clock and caused the date and month setting to slew forward by more than 10 days! That caused the total lock out of the WTB! Eureka! The aircraft time base was tied up with the cockpit clock. Oopsy!
All the engineering brainiacs sheepishly covered up the whole episode as a " one off " , " transient " problem. AI glossed over it and all the aviation " conspiracy sceptics" pooh poohed it to consign that incident as urban myth at the behest of their patrons and paymasters.
After landing at ADL and getting to sleep at the layover hotel he was frantically awakened by the station manager who wanted to know why he had brought a broken aircraft to ADL! To cut a long story short, the aircraft was AOG due to the WTB locking out entirely! The engineers at ADL and maintenance control at KUL couldn't figure out; neither did the Airbus technical representatives. The station manager, in all his wisdom, thought the inbound crew had f**ked up the system during the flight from KUL to ADL! The inbound skipper was none too pleased to have been woken rudely and accused of f**king up the aircraft. After much discussion, the skipper wryly asked if anybody had messed with the aircraft clock! Voila, somebody did....the outbound f/o was resetting the
clock and caused the date and month setting to slew forward by more than 10 days! That caused the total lock out of the WTB! Eureka! The aircraft time base was tied up with the cockpit clock. Oopsy!
All the engineering brainiacs sheepishly covered up the whole episode as a " one off " , " transient " problem. AI glossed over it and all the aviation " conspiracy sceptics" pooh poohed it to consign that incident as urban myth at the behest of their patrons and paymasters.
Last edited by gerago; 17th Sep 2012 at 20:33.
The inbound skipper was none too pleased to have been woken rudely and accused of f**king up the aircraft. After much discussion, the skipper wryly asked if anybody had messed with the aircraft clock! Voila, somebody did....
Windows/Excel is not (should not) be a benchmark for proper software development and function. Particularly in any applications where life safety is a factor.
And the whole 32-bit 2038 year is (or should be) a non issue. Properly written and compartmentalized software (object oriented for all the s/w geeks out there) hides the internal implementation of the time counter from the user. Nobody should be reading the clock variable directly, but calling the function that returns the proper value. Which, if written correctly, will correct for the overflow.
An earlier poster alluded to some of the problems with avionics s/w (Fortran style development). These include the heavy use of global variables: We can't fix something because we don't know who reads the 'broken' value, expecting it to be broken. So we have to add yet another function/variable to return a value usable to other routines (with its own quirks and anomalies, of course).
I've worked in the avionics engineering field alongside some 'so called' software engineers who continue to propagate spaghetti code. Some is due to management's refusal to get it fixed properly, but patch it and push it out the door. So they do the best they can. But some of it is due to their view of software as some magical 'thing' that stands aside from all other disciplines in the industry. Which no one else could possibly understand.
And the whole 32-bit 2038 year is (or should be) a non issue. Properly written and compartmentalized software (object oriented for all the s/w geeks out there) hides the internal implementation of the time counter from the user. Nobody should be reading the clock variable directly, but calling the function that returns the proper value. Which, if written correctly, will correct for the overflow.
An earlier poster alluded to some of the problems with avionics s/w (Fortran style development). These include the heavy use of global variables: We can't fix something because we don't know who reads the 'broken' value, expecting it to be broken. So we have to add yet another function/variable to return a value usable to other routines (with its own quirks and anomalies, of course).
I've worked in the avionics engineering field alongside some 'so called' software engineers who continue to propagate spaghetti code. Some is due to management's refusal to get it fixed properly, but patch it and push it out the door. So they do the best they can. But some of it is due to their view of software as some magical 'thing' that stands aside from all other disciplines in the industry. Which no one else could possibly understand.
