Narrative:

We experienced multiple failures that most likely stemmed from a primary failure of flight management and guidance computer (FMGC) #1. Below is the chain of events based on the time stamp in the 'last leg maintenance report.' we first experienced a data hit: 'invalid disk'/mddu.' I noticed that the multipurpose disk drive unit (mddu) panel light came on (it lit up unexpectedly). I thought it said; 'ready' - then; 'invalid disk.'after obtaining an updated ATIS I changed the runway on the #1 FMGC from runway 1C to runway 19C in iad. After the insert key was pushed; the captain's map was lost and FMGC #1 froze up. The message in scratch pad said to wait. FMGC #2 displayed 'independent operation' in the scratch pad. The flight mode annunciator's (FMA's) displayed 1fd2; and remained so for the duration of the flight. We referred to the aircraft operating manual and the system reset procedures; then attempted to reset the #1 multipurpose control & display unit (mcdu) circuit breaker (circuit breaker) on the overhead panel 49. This procedure restored the ACARS functions but not the FMGC. It appeared that we could only get the status page for the FMGC. Thus; no other buttons such as rad/navigation etc would function. Note: we subsequently received a 'GPWS terr' ECAM and secured it per the ECAM procedure. Later we tried a second attempt to reset the #1 mcdu which also failed. We then notified maintenance control via ACARS. We discussed the navigation/ILS tuning to ensure we would have the ILS information displayed on both sides and figured out that if just the captain's side was hard tuned then the first officer would lose the autotune function. If the first officer had his side autotuned; the captain's side would not display any ILS frequencies. We elected to hard tune both ILS receivers to 111.3 for runway 19C. After descent and nearing approach; the first officer's navigation was selected to auto to ensure auto updating for his FMGC data.once we were put on a vector to intercept the final approach course; both ILS receivers were again hard tuned. Note: prior to localizer intercept the first officer was flying with the autopilot on. When we started to intercept the final approach course the autopilot began to turn right versus left on the intercept. In other words; our raw data was showing that we needed to turn opposite of the flight director course information. We were getting ambiguous information at a critical time on both sides. I asked ATC if they were showing us lined up on the ILS - but got no answer. Therefore; the first officer turned his flight director off and followed raw data. I switched him back to autotune and took the hard tuning out of my side in an attempt to ensure we were getting accurate ILS information. We then picked up a visual to runway 19C shortly after approach handed us off to the tower. As we approached the marker the first officer called for managed speed and gear down. Then we received a 'landing elevation fault' message. The system status panel showed the elevation was zero as it should have been; so I focused on the final checklist and SOP call outs. The first officer then pointed out that he did not have a 'speed bug' on the tape. I concurred; as I did not show the magenta speed bug either. He flew the remainder of the approach without approach speed bug reference and we used the adjusted vls +5 knot speed that was displayed in the mcdu; about 140 KTS. On landing rollout; the pressurization outflow valve failed closed and a cabin attendant pr ECAM was displayed and directed us to manually open the outflow valve; which we did. Once fully open; the ECAM cleared and we taxied to the gate. Upon gate arrival maintenance control was briefed in detail. They advised they had received reports of bugs since the last FMGC software update was installed and that the problems should be corrected on the next update cycle. They also said that; based on the data he downloaded from our inbound flight; it appeared we actually experienced a dualfmgc failure or full failure of #1 and a partial failure of #2 FMGC. In my view; this is a real safety concern; we fully did not expect for the erroneous flight director commands when trying to establish on the ILS. I also fail to understand why I could not hard tune my side and leave the first officer's side in auto. Again; both had to be hard tuned in order to get the identifier. Otherwise; the failed side of the FMGC would not get any ILS information. The multiple failures of cabin pressure etc. Compounded our workload at a very critical time; not to mention at the end of a red eye flight!

Google
 

Original NASA ASRS Text

Title: An Airbus Captain described multiple anomalies apparently related to the failure of either one or both FMGCs per Maintenance. The flight crew ad libbed the use of the remaining navigation devices until in VMC on approach to their destination where they made a safe landing and turned the jet over to Maintenance.

Narrative: We experienced multiple failures that most likely stemmed from a primary failure of Flight Management and Guidance Computer (FMGC) #1. Below is the chain of events based on the time stamp in the 'last leg maintenance report.' We first experienced a data hit: 'invalid disk'/MDDU.' I noticed that the Multipurpose Disk Drive Unit (MDDU) panel light came on (it lit up unexpectedly). I thought it said; 'Ready' - then; 'invalid disk.'After obtaining an updated ATIS I changed the runway on the #1 FMGC from Runway 1C to Runway 19C in IAD. After the insert key was pushed; the Captain's map was lost and FMGC #1 froze up. The message in scratch pad said to wait. FMGC #2 displayed 'independent operation' in the scratch pad. The Flight Mode Annunciator's (FMA's) displayed 1FD2; and remained so for the duration of the flight. We referred to the Aircraft Operating Manual and the system reset procedures; then attempted to reset the #1 Multipurpose Control & Display Unit (MCDU) Circuit Breaker (CB) on the overhead panel 49. This procedure restored the ACARS functions but not the FMGC. It appeared that we could only get the status page for the FMGC. Thus; no other buttons such as RAD/NAV etc would function. Note: We subsequently received a 'GPWS TERR' ECAM and secured it per the ECAM procedure. Later we tried a second attempt to reset the #1 MCDU which also failed. We then notified Maintenance Control via ACARS. We discussed the NAV/ILS tuning to ensure we would have the ILS information displayed on both sides and figured out that if just the Captain's side was hard tuned then the First Officer would lose the autotune function. If the First Officer had his side autotuned; the Captain's side would not display any ILS frequencies. We elected to hard tune both ILS receivers to 111.3 for Runway 19C. After descent and nearing approach; the First Officer's NAV was selected to auto to ensure auto updating for his FMGC data.Once we were put on a vector to intercept the final approach course; both ILS receivers were again hard tuned. Note: Prior to LOC intercept the First Officer was flying with the autopilot on. When we started to intercept the final approach course the autopilot began to turn right versus left on the intercept. In other words; our raw data was showing that we needed to turn opposite of the Flight Director course information. We were getting ambiguous information at a critical time on both sides. I asked ATC if they were showing us lined up on the ILS - but got no answer. Therefore; the First Officer turned his Flight Director off and followed raw data. I switched him back to autotune and took the hard tuning out of my side in an attempt to ensure we were getting accurate ILS information. We then picked up a visual to Runway 19C shortly after approach handed us off to the Tower. As we approached the marker the First Officer called for managed speed and gear down. Then we received a 'landing elevation fault' message. The system status panel showed the elevation was zero as it should have been; so I focused on the final checklist and SOP call outs. The First Officer then pointed out that he did not have a 'speed bug' on the tape. I concurred; as I did not show the magenta speed bug either. He flew the remainder of the approach without approach speed bug reference and we used the adjusted VLS +5 knot speed that was displayed in the MCDU; about 140 KTS. On landing rollout; the pressurization outflow valve failed closed and a CAB PR ECAM was displayed and directed us to manually open the outflow valve; which we did. Once fully open; the ECAM cleared and we taxied to the gate. Upon gate arrival Maintenance Control was briefed in detail. They advised they had received reports of bugs since the last FMGC software update was installed and that the problems should be corrected on the next update cycle. They also said that; based on the data he downloaded from our inbound flight; it appeared we actually experienced a dualFMGC failure or full failure of #1 and a partial failure of #2 FMGC. In my view; this is a real safety concern; we fully did not expect for the erroneous Flight Director commands when trying to establish on the ILS. I also fail to understand why I could not hard tune my side and leave the First Officer's side in auto. Again; both had to be hard tuned in order to get the identifier. Otherwise; the failed side of the FMGC would not get any ILS information. The multiple failures of cabin pressure etc. compounded our workload at a very critical time; not to mention at the end of a red eye flight!

Data retrieved from NASA's ASRS site as of July 2013 and automatically converted to unabbreviated mixed upper/lowercase text. This report is for informational purposes with no guarantee of accuracy. See NASA's ASRS site for official report.