Narrative:

When I picked up our flight plan; I noticed we had a note that the most recent database was installed in the FMC's. I knew we have had problems with database storage so we might have some issues with waypoints during the flight. We were filed with an arrival at bwi for the OTT6 (nottingham six) coming in over csn VOR. We arrived at the airplane late; due to problems with the crew van transportation. When I came back to the cockpit the first officer indicated that the FMC database didn't have the OTT6 arrival to bwi and didn't have any of the arrival waypoints in it. I indicated we should just get going; and we could load them in flight as we would have plenty of time then. The takeoff and climb out were uneventful. We began to load the waypoints for the OTT6 arrival and my first officer had the entire arrival loaded when we were given a direct clearance to ott VOR. Later ATC changed our arrival to give us direct csn; and the RAVNN3 arrival. This arrival has many more waypoints and each one has a crossing restriction altitude. My first officer was having problems getting the waypoints to load as none of them were in the database. We discussed this and he was able to load sacco but not fimbo. I had him bring sacco into the scratch pad and confirmed it was a place/bearing/distance waypoint csn/096/22. I had him load the 22NM distance so we would reach the 16;000 ft restriction early. He could then change the distance given and use the same place and bearing; which he did csn/096/25 for fimbo. For the other two waypoints he used ott as the place. He built rexee as ott/276/14 and we discussed he could build udude as ott/276/22. We then put in all the altitude restrictions. The first officer indicated he would stay in raw data from csn to make sure everything was working correctly. Shortly before reaching csn ATC cleared us to 'descend via the RAVNN3 arrival'. We started down at the top of descent point. All indications were that the VNAV path was correct; and we checked our information at csn; sacco and fimbo. The first officer indicated that it all looked correct and he was going to set up the outbound radial from ott to help identify ravnn; to which I told him that was a good idea because we looked good so far. As we approached udude; things were still looking good for our VNAV path. However; upon passing udude; the next waypoint; rexee disappeared from the ehsi display and ott moved closer to us. My reaction and the first officer's were the same; 'where did the waypoint go?' at that point I am guessing we were about 6 to 7 miles from ott at around 277 KTS and approximately 12;000 ft. ATC ask us if we were going to make ott at 9;000 ft because he thought we might be unable. We told him we would do our best. He indicated it would not be a problem as long as we made ravnn by 6;000 ft. I had already selected flch; full speedbrakes and bugged the airspeed to 250 KTS. We crossed ott at about 800 to 900 ft above the 9;000 ft altitude. We subsequently easily made the ravnn altitude. We were very confused as to what had happened. We had both checked the order; distances and altitudes; and neither one of us can determine what went wrong. We discussed this later that day over dinner and still have no idea what happened. As with most cases it is usually operator error and it may have been in this case. But we can't [identify] what we did wrong. In the future if I have one of our B757's with the limited database capability that is not for the area of operation I am dispatching to; I will see if there is time to get the correct database installed. If that is not feasible; I will require the pilot not flying to monitor raw data to ensure all is correct with the arrival or departure. The problem with doing this is a reduction in situational awareness by not having the map capability of the ehsi for the pilot not flying. Although this seems a bit conservative; I believe this will prevent the error we experience.however by using this method of operation; I think we are doing our pilots a disservice in operating in this manner. We need to spend the money to update the FMC's and the databases on these aircraft. I feel we are taking a step backward in our technology with this aircraft. I know we are all supposed to be able to operate the aircraft in this manner anyway; but we are asking ourselves for more headaches and potential violations because we will not upgrade our equipment to the environment we operate this aircraft in on a day to day basis.

Google
 

Original NASA ASRS Text

Title: A B757 Captain reported that his B757 FMC database did not contain the BWI RAVNN3 Arrival and so his First Officer attempted to build the arrival using manual bearing distance fixes. The aircraft crossed a fix high amid a high cockpit workload.

Narrative: When I picked up our flight plan; I noticed we had a note that the most recent database was installed in the FMC's. I knew we have had problems with database storage so we might have some issues with waypoints during the flight. We were filed with an arrival at BWI for the OTT6 (Nottingham Six) coming in over CSN VOR. We arrived at the airplane late; due to problems with the crew van transportation. When I came back to the cockpit the First Officer indicated that the FMC database didn't have the OTT6 arrival to BWI and didn't have any of the arrival waypoints in it. I indicated we should just get going; and we could load them in flight as we would have plenty of time then. The takeoff and climb out were uneventful. We began to load the waypoints for the OTT6 arrival and my First Officer had the entire arrival loaded when we were given a direct clearance to OTT VOR. Later ATC changed our arrival to give us direct CSN; and the RAVNN3 arrival. This arrival has many more waypoints and each one has a crossing restriction altitude. My First Officer was having problems getting the waypoints to load as none of them were in the database. We discussed this and he was able to load SACCO but not FIMBO. I had him bring SACCO into the scratch pad and confirmed it was a Place/Bearing/Distance waypoint CSN/096/22. I had him load the 22NM distance so we would reach the 16;000 FT restriction early. He could then change the distance given and use the same Place and Bearing; which he did CSN/096/25 for FIMBO. For the other two waypoints he used OTT as the Place. He built REXEE as OTT/276/14 and we discussed he could build UDUDE as OTT/276/22. We then put in all the altitude restrictions. The First Officer indicated he would stay in raw data from CSN to make sure everything was working correctly. Shortly before reaching CSN ATC cleared us to 'descend via the RAVNN3 arrival'. We started down at the Top of Descent point. All indications were that the VNAV path was correct; and we checked our information at CSN; SACCO and FIMBO. The First Officer indicated that it all looked correct and he was going to set up the outbound radial from OTT to help identify RAVNN; to which I told him that was a good idea because we looked good so far. As we approached UDUDE; things were still looking good for our VNAV path. However; upon passing UDUDE; the next waypoint; REXEE disappeared from the EHSI display and OTT moved closer to us. My reaction and the First Officer's were the same; 'where did the waypoint go?' At that point I am guessing we were about 6 to 7 miles from OTT at around 277 KTS and approximately 12;000 FT. ATC ask us if we were going to make OTT at 9;000 FT because he thought we might be unable. We told him we would do our best. He indicated it would not be a problem as long as we made RAVNN by 6;000 FT. I had already selected FLCH; full speedbrakes and bugged the airspeed to 250 KTS. We crossed OTT at about 800 to 900 FT above the 9;000 FT altitude. We subsequently easily made the RAVNN altitude. We were very confused as to what had happened. We had both checked the order; distances and altitudes; and neither one of us can determine what went wrong. We discussed this later that day over dinner and still have no idea what happened. As with most cases it is usually operator error and it may have been in this case. But we can't [identify] what we did wrong. In the future if I have one of our B757's with the limited database capability that is not for the area of operation I am dispatching to; I will see if there is time to get the correct database installed. If that is not feasible; I will require the pilot not flying to monitor raw data to ensure all is correct with the arrival or departure. The problem with doing this is a reduction in situational awareness by not having the MAP capability of the EHSI for the pilot not flying. Although this seems a bit conservative; I believe this will prevent the error we experience.However by using this method of operation; I think we are doing our pilots a disservice in operating in this manner. We need to spend the money to update the FMC's and the databases on these aircraft. I feel we are taking a step backward in our technology with this aircraft. I know we are all supposed to be able to operate the aircraft in this manner anyway; but we are asking ourselves for more headaches and potential violations because we will not upgrade our equipment to the environment we operate this aircraft in on a day to day basis.

Data retrieved from NASA's ASRS site as of April 2012 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.