37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 787611 |
Time | |
Date | 200805 |
Place | |
Locale Reference | intersection : eddna |
State Reference | AZ |
Altitude | msl bound lower : 7800 msl bound upper : 8000 |
Environment | |
Flight Conditions | VMC |
Light | Daylight |
Aircraft 1 | |
Controlling Facilities | tracon : p50.tracon |
Operator | common carrier : air carrier |
Make Model Name | B737 Undifferentiated or Other Model |
Operating Under FAR Part | Part 121 |
Flight Phase | descent : approach |
Route In Use | arrival star : maier |
Flight Plan | IFR |
Person 1 | |
Affiliation | company : air carrier |
Function | flight crew : captain oversight : pic |
Experience | flight time last 90 days : 150 flight time type : 8000 |
ASRS Report | 787611 |
Events | |
Anomaly | aircraft equipment problem : less severe other anomaly other |
Independent Detector | other flight crewa |
Resolutory Action | none taken : anomaly accepted |
Supplementary | |
Problem Areas | Aircraft |
Primary Problem | Aircraft |
Narrative:
Due to the new software update that requires you to change altitudes; so that they comply with the charted values; the aircraft and crew can easily make mistakes; ie; changing the speed at eddna to 210 KTS at 8000K instead of what comes up in the box 210B and 8000B. In this case a slight deviation in altitude occurred. The aircraft started down a little early before eddna thus crossing it at 7800 ft in order to make kucoo at 6000 ft. Altitude hold was pressed; but by that time we captured eddna. The bottom line is that we should not have to re-input all the altitudes and speeds because of the software change. I have also noticed that when ATC requests a lower speed at a location; ie; 250 KTS at raddy into sea vice 280 KTS; the mcdu will not accept it unless you change every other point to that point with the updated speed; and the descent speed also. This never used to be an issue. You were just able to plug in the speed in the box; and it would let you. Now both pilots could be heads down struggling to understand why the box will not accept the input. It seems as though the new update has added more work with automation which can lead to errors.
Original NASA ASRS Text
Title: B737 CAPT DETAILS THE COMPLICATIONS ASSOCIATED WITH FMS SOFTWARE UPGRADES AND DIFFERENCE BETWEEN SOFTWARE DATA AND PUBLISHED PROCEDURES.
Narrative: DUE TO THE NEW SOFTWARE UPDATE THAT REQUIRES YOU TO CHANGE ALTS; SO THAT THEY COMPLY WITH THE CHARTED VALUES; THE ACFT AND CREW CAN EASILY MAKE MISTAKES; IE; CHANGING THE SPD AT EDDNA TO 210 KTS AT 8000K INSTEAD OF WHAT COMES UP IN THE BOX 210B AND 8000B. IN THIS CASE A SLIGHT DEV IN ALT OCCURRED. THE ACFT STARTED DOWN A LITTLE EARLY BEFORE EDDNA THUS XING IT AT 7800 FT IN ORDER TO MAKE KUCOO AT 6000 FT. ALT HOLD WAS PRESSED; BUT BY THAT TIME WE CAPTURED EDDNA. THE BOTTOM LINE IS THAT WE SHOULD NOT HAVE TO RE-INPUT ALL THE ALTS AND SPDS BECAUSE OF THE SOFTWARE CHANGE. I HAVE ALSO NOTICED THAT WHEN ATC REQUESTS A LOWER SPD AT A LOCATION; IE; 250 KTS AT RADDY INTO SEA VICE 280 KTS; THE MCDU WILL NOT ACCEPT IT UNLESS YOU CHANGE EVERY OTHER POINT TO THAT POINT WITH THE UPDATED SPD; AND THE DSCNT SPD ALSO. THIS NEVER USED TO BE AN ISSUE. YOU WERE JUST ABLE TO PLUG IN THE SPD IN THE BOX; AND IT WOULD LET YOU. NOW BOTH PLTS COULD BE HEADS DOWN STRUGGLING TO UNDERSTAND WHY THE BOX WILL NOT ACCEPT THE INPUT. IT SEEMS AS THOUGH THE NEW UPDATE HAS ADDED MORE WORK WITH AUTOMATION WHICH CAN LEAD TO ERRORS.
Data retrieved from NASA's ASRS site as of May 2009 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.