Narrative:

I was loading the boeing 737 FMC in preparation for departure from fll. We were filed over our usual routing that consisted of the arkes 1 RNAV departure (ARKES1.arkes); J85 orl. After entering the SID; I attempted to add J85 as the outbound route to orl. The FMC gave an invalid entry error message. I determined that the leg from arkes to orl was a straight-line route by reference to our paper charts; so I entered a direct route rather than J85; and verified the route on the legs page of the FMC. The flight proceeded uneventfully. Having run into problems like this before with the current FMC database (active through june; 2009) I discussed this problem with the company that handles the FMC database development for our fmcs. It is a well-known fact that the memory of our FMC hardware is now too small to store the full complement of navigational data required to support current operations. This has been true for many years. Although expansion units are available; the company has elected to not install them; and instead selectively deletes navigational data to shrink the database enough that it will fit in our units. Apparently; in the development of the current database load during this database shrinking process; we eliminated some information that the developer thought was nonessential that had not been excluded from previous loads. Specifically; if a particular route had multiple fixes along a straight line; they did not identify the intermediate fixes as being attached to that airway. For example; arkes is an intermediate fix on the straight line J85 segment enroute to orl. Since that section of J85 is straight; ge decided that including arkes; as one of the fixes on J85 in the database was nonessential data; and eliminated it. Arkes is still in the database; it's just that the FMC doesn't know that arkes is a fix on J85. Hence; the invalid entry error message when I tried to take J85 from arkes to orl. The same problem exists with many fir boundary fixes. Those fixes are usually part of straight-line routes; and indicate when you cross international boundaries. Since they don't usually require a turn when you hit them; it was decided their presence on the airway was nonessential data; and could be deleted. Examples of this include the nosat fir boundary on UB879 enroute to cancun; the misis exit waypoint on UJ18 departing cancun; and apparently many others. Due to the update cycle; it will be at least the july database load before this could be fixed. I have passed this information on to the senior check airman on the boeing 737; and suggested a memo be sent to the boeing 737 pilots; advising them of these issues; but he declined to do so. I believe that it is time to purchase the memory expansion units for our fmcs. We fly these aircraft every day; many times each day. There comes a point when work-arounds (like manually deleting database information for each new database load) begin to impact safe operations. That time is now; especially when the vendor doing the database massaging to shoehorn it into our ancient FMC units apparently doesn't understand how important it is for a pilot to know when he or she is crossing an fir boundary. Certainly at a minimum; all of the pilots should be informed of this issue so they know they must manually add fir boundary fixes to their FMC routes if they want to know when they will cross the boundary.

Google
 

Original NASA ASRS Text

Title: B737 First Officer reports waypoints being deleted by the FMC database supplier in order to fit in the limited memory of older B737's. The deletion criterion results in FIR boundaries being routinely deleted from the database.

Narrative: I was loading the Boeing 737 FMC in preparation for departure from FLL. We were filed over our usual routing that consisted of the ARKES 1 RNAV DEPARTURE (ARKES1.ARKES); J85 ORL. After entering the SID; I attempted to add J85 as the outbound route to ORL. The FMC gave an INVALID ENTRY error message. I determined that the leg from ARKES to ORL was a straight-line route by reference to our paper charts; so I entered a direct route rather than J85; and verified the route on the LEGS page of the FMC. The flight proceeded uneventfully. Having run into problems like this before with the current FMC database (active through June; 2009) I discussed this problem with the company that handles the FMC database development for our FMCs. It is a well-known fact that the memory of our FMC hardware is now too small to store the full complement of navigational data required to support current operations. This has been true for many years. Although expansion units are available; the company has elected to not install them; and instead selectively deletes navigational data to shrink the database enough that it will fit in our units. Apparently; in the development of the current database load during this database shrinking process; we eliminated some information that the developer thought was nonessential that had not been excluded from previous loads. Specifically; if a particular route had multiple fixes along a straight line; they did not identify the intermediate fixes as being attached to that airway. For example; ARKES is an intermediate fix on the straight line J85 segment enroute to ORL. Since that section of J85 is straight; GE decided that including ARKES; as one of the fixes on J85 in the database was nonessential data; and eliminated it. ARKES is still in the database; it's just that the FMC doesn't know that ARKES is a fix on J85. Hence; the INVALID ENTRY error message when I tried to take J85 from ARKES to ORL. The same problem exists with many FIR boundary fixes. Those fixes are usually part of straight-line routes; and indicate when you cross international boundaries. Since they don't usually require a turn when you hit them; it was decided their presence on the airway was nonessential data; and could be deleted. Examples of this include the NOSAT FIR boundary on UB879 enroute to Cancun; the MISIS exit waypoint on UJ18 departing Cancun; and apparently many others. Due to the update cycle; it will be at least the July database load before this could be fixed. I have passed this information on to the Senior Check Airman on the Boeing 737; and suggested a memo be sent to the Boeing 737 pilots; advising them of these issues; but he declined to do so. I believe that it is time to purchase the memory expansion units for our FMCs. We fly these aircraft every day; many times each day. There comes a point when work-arounds (like manually deleting database information for each new database load) begin to impact safe operations. That time is now; especially when the vendor doing the database massaging to shoehorn it into our ancient FMC units apparently doesn't understand how important it is for a pilot to know when he or she is crossing an FIR boundary. Certainly at a minimum; all of the pilots should be informed of this issue so they know they must manually add FIR boundary fixes to their FMC routes if they want to know when they will cross the boundary.

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.