37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 1035754 |
Time | |
Date | 201209 |
Local Time Of Day | 0001-0600 |
Place | |
Locale Reference | ZZZ.TRACON |
State Reference | US |
Environment | |
Flight Conditions | VMC |
Light | Dawn |
Aircraft 1 | |
Make Model Name | A320 |
Operating Under FAR Part | Part 121 |
Flight Phase | Final Approach Initial Approach |
Flight Plan | IFR |
Component | |
Aircraft Component | FMS/FMC |
Person 1 | |
Function | Pilot Flying First Officer |
Events | |
Anomaly | Aircraft Equipment Problem Critical |
Narrative:
We experienced multiple failures that most likely stemmed from a primary failure of FMGC number 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 mddu panel light came on/lit up. I thought it said; 'ready;' then; 'invalid disk.' after obtaining an updated ATIS a little less then a hour before arrival; captain changed the runway on the number 1 FMGC; from runway 1 to runway 19. After the insert key was pushed; the captain's map was lost and FMGC number 1 froze up. The message in scratch pad said to wait. FMGC number 2 displayed 'independent operation' in the scratch pad. The FMA's displayed 1fd2; and remained so for the duration of the flight. We referred to the flight manual and the system reset procedures. We then attempted to reset the number 1 mcdu 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 attempted a second attempt to reset the number 1 mcdu which also failed. Maintenance was notified via ACARS of the situation. We also briefed the navigation/ILS tuning to ensure we would have the ILS information displayed on both sides. 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 vs. Left on the intercept. In other words; our raw data was showing that we needed to turn opposite of the FD course information. We were getting ambiguous information at a critical time on both sides. With the runway visually acquired; the first officer turned his FD off and followed raw data. On final about 1;500 ft AGL we received a 'landing elevation fault.' the system status panel showed the elevation was zero; captain elected to wait till after rollout to deal with cabin attendant pr ECAM and focused on the final checklist and SOP call outs. When managed speed selected on final; we did not have a 'speed bug' on the tape. We flew the remainder of the approach without approach speed bug reference and we used the adjusted vls plus 5 KT 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 landing; maintenance was briefed in detail. Maintenance told me they have received reports of bugs since the last FMGC software update was installed. I was informed that this should be corrected on the next update cycle. Maintenance also said that based on the data he downloaded from our inbound flight; it appeared we actually experienced a dual FMGC failure or full failure of number 1 and a partial failure of number 2 FMGC. The multiple failures of cabin pressure; etc compounded our workload at a very critical time and not to mention at the end of a red eye flight. Good review of standby navigation procedures and anomalies.
Original NASA ASRS Text
Title: An A320 crew was notified after flight that the FMGC failure they had experienced in flight is believed caused by a 'bug' in a recent software update.
Narrative: We experienced multiple failures that most likely stemmed from a primary failure of FMGC Number 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 MDDU panel light came on/lit up. I thought it said; 'Ready;' then; 'Invalid Disk.' After obtaining an updated ATIS a little less then a hour before arrival; Captain changed the runway on the Number 1 FMGC; from Runway 1 to Runway 19. After the insert key was pushed; the Captain's map was lost and FMGC Number 1 froze up. The message in scratch pad said to wait. FMGC Number 2 displayed 'Independent Operation' in the scratch pad. The FMA's displayed 1FD2; and remained so for the duration of the flight. We referred to the Flight Manual and the system reset procedures. We then attempted to reset the Number 1 MCDU 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 attempted a second attempt to reset the Number 1 MCDU which also failed. Maintenance was notified via ACARS of the situation. We also briefed the NAV/ILS tuning to ensure we would have the ILS information displayed on both sides. 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 vs. left on the intercept. In other words; our raw data was showing that we needed to turn opposite of the FD course information. We were getting ambiguous information at a critical time on both sides. With the runway visually acquired; the First Officer turned his FD off and followed raw data. On final about 1;500 FT AGL we received a 'landing elevation fault.' The system status panel showed the elevation was zero; Captain elected to wait till after rollout to deal with CAB PR ECAM and focused on the final checklist and SOP call outs. When managed speed selected on final; we did not have a 'speed bug' on the tape. We flew the remainder of the approach without approach speed bug reference and we used the adjusted VLS plus 5 KT 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 landing; Maintenance was briefed in detail. Maintenance told me they have received reports of bugs since the last FMGC software update was installed. I was informed that this should be corrected on the next update cycle. Maintenance also said that based on the data he downloaded from our inbound flight; it appeared we actually experienced a dual FMGC failure or full failure of Number 1 and a partial failure of Number 2 FMGC. The multiple failures of cabin pressure; etc compounded our workload at a very critical time and not to mention at the end of a red eye flight. Good review of standby navigation procedures and anomalies.
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.