37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 341815 |
Time | |
Date | 199607 |
Day | Sun |
Local Time Of Day | 1801 To 2400 |
Place | |
Locale Reference | atc facility : zzz |
State Reference | US |
Altitude | msl bound lower : 32000 msl bound upper : 3200 |
Environment | |
Flight Conditions | VMC |
Light | Night |
Aircraft 1 | |
Controlling Facilities | artcc : zzz |
Operator | general aviation : personal |
Make Model Name | Falcon 900 |
Operating Under FAR Part | Part 91 |
Navigation In Use | Other Other |
Flight Phase | descent other |
Route In Use | enroute : direct enroute airway : zzz |
Flight Plan | IFR |
Person 1 | |
Affiliation | Other |
Function | flight crew : captain oversight : pic |
Qualification | pilot : atp pilot : commercial |
Experience | flight time last 90 days : 200 flight time total : 14000 flight time type : 1000 |
ASRS Report | 341815 |
Person 2 | |
Affiliation | Other |
Function | other personnel other |
Qualification | pilot : flight engineer pilot : commercial pilot : cfi pilot : atp |
Experience | flight time last 90 days : 210 flight time total : 25000 flight time type : 1100 |
ASRS Report | 341814 |
Events | |
Anomaly | aircraft equipment problem : less severe altitude deviation : crossing restriction not met other anomaly other |
Independent Detector | other controllera other flight crewa |
Resolutory Action | other other |
Consequence | Other |
Supplementary | |
Primary Problem | Aircraft |
Air Traffic Incident | other |
Narrative:
I am a DA90/50 instructor pilot/examiner, and I am appalled by my findings in this incident in which I was a deadheading pilot on the jumpseat having been relieved as captain half way en route. What appalls me is that I am also a instructor at the training center, had no recollection of knowing the reasoning behind the 'trap' built into the honeywell system, called our resident expert avionics instructor immediately afterwards and was shocked to learn this was not only a 'trap' to which honeywell and dassault falcon jet are aware, but that their blatant disregard for safety and sensibility is incredible when I learned that our instructors have been arguing against this built-in trap for 9 yrs to no avail. I have about 4000 hours in the FALCON900, of which about 1000 hours plus are in the aircraft. The incident: we were swbound in ZZZ airspace approximately 100 NM northeast of aabb intersection, on radar vectors with a subsequent clearance 'RNAV direct aabb' with a descent clearance to 'cross aabb at FL240.' we were in a slow descent on VNAV out of about FL350 descending when I was alerted from a 'catnap' on the jumpseat to what appeared to me to be a distressful call from ATC questioning our vertical speed and whether we would make the crossing restr. As the captain flying replied to ATC I observed both pilots navigating on FMS with about 106 mi displayed on the multi-function display which was in my clear view, showing the aircraft navigating direct to aabb. The captain had replied there would be no problem making the restr. Approximately 20 mi farther, on an off-airway RNAV direct route and descending through what I recollect to be FL320, the same controller came on the radio in a rather angry attitude asking if we were really going to make the crossing restr, and to increase the descent rate. The captain informed him we would make the restr and that we showed approximately 80 NM to go. The controller did not reply. A conversation took place in the cockpit as to whether the FMS was wrong or whether the controller had us confused with another aircraft, or 'what his problem was.' the PF's verified all 3 FMS system in acceptable agreement. We did not have time to verify aabb by the FMS procedure of place-bearing-distance, and latitude longitude is not displayed on the chart. The controller interrupted in a very disturbed manner, informing us we missed the restr by about 8000 ft and that we were now south of aabb, further introducing confusion, and concern into the cockpit as we scrambled to sort out this conflicting data, and now attempt to follow new instructions with turning vectors and a barrage of verbal abuse from the controller, I informed the crew to report a dual IRS navigation failure as they did not agree with the controller who later gave us our position while I directed the crew to switch to VOR for the remainder of the trip. The captain could not use the VOR as we were proceeding to a fix not a VOR on a direct RNAV route when the 'apparent' failure occurred. The trip proceeded to conclusion without further incident. During the remainder I took readings from the FMS and the global navigation system which were consistently 50 plus mi different, logging them for a maintenance write-up. At our destination, the first officer discovered the problem. The very dangerous error and hidden honeywell 'trap.' we entered aabb manually as it was not defined in the database. In so doing, the first officer gave me the wrong distance for place-bearing-distance, giving me the distance between VOR's instead of the mileage between VOR and fix. When it did not look right I checked the chart myself and pointed out his error to him, and proceeded to correct the defined fix error. I was unable to correct the error to my amazement getting errors 'fix used by active flight path. Not to worry, I deleted the fix from the active flight path and reentered it, only I found I was unable to now delete and correct it for reasons undetermined, abided by the age old adage, 'fly the aircraft, and fall back to raw data when the FMS programming is consuming too much distracting time in busy airspace or high workload periods.' the flight was completed with no problems, and since aabb was long past at trips end, it was equally forgotten after a long tiring trip from YYY, and after a busy descent in congested airspace. When we checked what the first officer remembered, sure enough the incorrect fix with correct place-bearing and wrong distance was still in the database, exactly 50 plus mi too far from the 'place' VOR! The honeywell trap!!! There is no way honeywell makes the pilot aware that the fix he chose was manmade and not from the database! Now let's analyze the features of the honeywell FMS. When one enters speed/altitude as opposed to letting the computer generate these, the system displays these inputs as larger point size characters, signifying that someone, not the computer entered these figures. When one creates a fix that is not in the database, an asterisk appears next to the name on the flight path page in the current active flight path only. Subsequent selection of the fix by name gives no notification of how this fix was created database or pilot input, nothing! No asterisk. No enlarged character size. Nothing! It was also my incorrect understanding that the fix would disappear from memory as does the flight path when created on the active flight path page, so therefore I was not concerned that I ignored the error and could not correct it for whatever reason. The system in the DA90 is admittedly different from that in the B757 although they share many similarities. Conclusion and immediate prevention suggestions. Pilots: try to know and remember all the equipment limitations. Try to remember to clear out all erroneous waypoints. The PF this incident trip had no idea the fix did not come from the database, different pilot, different day. Clear out all waypoints in the 'files clear' function as a matter of habit. Check all waypoints always. This is not always possible in a high workload environment, busy approach/descent, especially with current honeywell design. Backup FMS with raw data VOR/NDB on the PNF instruments. This is not always possible such as in the incident flight as we were on a 'vector then an RNAV direct route to a fix, even difficult if defined by cross radials, and not a recommended way to navigation. Increase descent rate and investigate backup navigation verification immediately upon ATC query of a navigation discrepancy between aircraft and ATC. Controllers: better use of terminology and queries! A better choice of words might have been 'confirm you position 20 mi north of abc, which I show on radar.' long term suggestion: force the arrogant honeywell/falcon jet to modify the equipment to display something that would key the pilot in to the fact that the fix is man-made as suggested earlier in this document before someone is killed!
Original NASA ASRS Text
Title: ACFT EQUIP PROB. AN ERRONEOUS WAYPOINT HAD BEEN INSERTED INTO THE FMS BY A PREVIOUS FLC, BUT WHEN THE RPTR FLC CALLED UP THE WAYPOINT, THERE WAS NO DISTINCTION BTWN DATABASE INFO OR FLC INSERTED INFO. CTLR HAD ASSIGNED A XING ALT RESTR AND REPEATEDLY ASKED FLC IF THEY WOULD MAKE IT. SINCE THE WAYPOINT FIX TO WHICH THEY WERE GOING WAS IN ERROR, THEY WERE MISLED AND WERE 50 MI OFF ON THE FIX XING.
Narrative: I AM A DA90/50 INSTRUCTOR PLT/EXAMINER, AND I AM APPALLED BY MY FINDINGS IN THIS INCIDENT IN WHICH I WAS A DEADHEADING PLT ON THE JUMPSEAT HAVING BEEN RELIEVED AS CAPT HALF WAY ENRTE. WHAT APPALLS ME IS THAT I AM ALSO A INSTRUCTOR AT THE TRAINING CTR, HAD NO RECOLLECTION OF KNOWING THE REASONING BEHIND THE 'TRAP' BUILT INTO THE HONEYWELL SYS, CALLED OUR RESIDENT EXPERT AVIONICS INSTRUCTOR IMMEDIATELY AFTERWARDS AND WAS SHOCKED TO LEARN THIS WAS NOT ONLY A 'TRAP' TO WHICH HONEYWELL AND DASSAULT FALCON JET ARE AWARE, BUT THAT THEIR BLATANT DISREGARD FOR SAFETY AND SENSIBILITY IS INCREDIBLE WHEN I LEARNED THAT OUR INSTRUCTORS HAVE BEEN ARGUING AGAINST THIS BUILT-IN TRAP FOR 9 YRS TO NO AVAIL. I HAVE ABOUT 4000 HRS IN THE FALCON900, OF WHICH ABOUT 1000 HRS PLUS ARE IN THE ACFT. THE INCIDENT: WE WERE SWBOUND IN ZZZ AIRSPACE APPROX 100 NM NE OF AABB INTXN, ON RADAR VECTORS WITH A SUBSEQUENT CLRNC 'RNAV DIRECT AABB' WITH A DSCNT CLRNC TO 'CROSS AABB AT FL240.' WE WERE IN A SLOW DSCNT ON VNAV OUT OF ABOUT FL350 DSNDING WHEN I WAS ALERTED FROM A 'CATNAP' ON THE JUMPSEAT TO WHAT APPEARED TO ME TO BE A DISTRESSFUL CALL FROM ATC QUESTIONING OUR VERT SPD AND WHETHER WE WOULD MAKE THE XING RESTR. AS THE CAPT FLYING REPLIED TO ATC I OBSERVED BOTH PLTS NAVING ON FMS WITH ABOUT 106 MI DISPLAYED ON THE MULTI-FUNCTION DISPLAY WHICH WAS IN MY CLR VIEW, SHOWING THE ACFT NAVING DIRECT TO AABB. THE CAPT HAD REPLIED THERE WOULD BE NO PROB MAKING THE RESTR. APPROX 20 MI FARTHER, ON AN OFF-AIRWAY RNAV DIRECT RTE AND DSNDING THROUGH WHAT I RECOLLECT TO BE FL320, THE SAME CTLR CAME ON THE RADIO IN A RATHER ANGRY ATTITUDE ASKING IF WE WERE REALLY GOING TO MAKE THE XING RESTR, AND TO INCREASE THE DSCNT RATE. THE CAPT INFORMED HIM WE WOULD MAKE THE RESTR AND THAT WE SHOWED APPROX 80 NM TO GO. THE CTLR DID NOT REPLY. A CONVERSATION TOOK PLACE IN THE COCKPIT AS TO WHETHER THE FMS WAS WRONG OR WHETHER THE CTLR HAD US CONFUSED WITH ANOTHER ACFT, OR 'WHAT HIS PROB WAS.' THE PF'S VERIFIED ALL 3 FMS SYS IN ACCEPTABLE AGREEMENT. WE DID NOT HAVE TIME TO VERIFY AABB BY THE FMS PROC OF PLACE-BEARING-DISTANCE, AND LATITUDE LONGITUDE IS NOT DISPLAYED ON THE CHART. THE CTLR INTERRUPTED IN A VERY DISTURBED MANNER, INFORMING US WE MISSED THE RESTR BY ABOUT 8000 FT AND THAT WE WERE NOW S OF AABB, FURTHER INTRODUCING CONFUSION, AND CONCERN INTO THE COCKPIT AS WE SCRAMBLED TO SORT OUT THIS CONFLICTING DATA, AND NOW ATTEMPT TO FOLLOW NEW INSTRUCTIONS WITH TURNING VECTORS AND A BARRAGE OF VERBAL ABUSE FROM THE CTLR, I INFORMED THE CREW TO RPT A DUAL IRS NAV FAILURE AS THEY DID NOT AGREE WITH THE CTLR WHO LATER GAVE US OUR POS WHILE I DIRECTED THE CREW TO SWITCH TO VOR FOR THE REMAINDER OF THE TRIP. THE CAPT COULD NOT USE THE VOR AS WE WERE PROCEEDING TO A FIX NOT A VOR ON A DIRECT RNAV RTE WHEN THE 'APPARENT' FAILURE OCCURRED. THE TRIP PROCEEDED TO CONCLUSION WITHOUT FURTHER INCIDENT. DURING THE REMAINDER I TOOK READINGS FROM THE FMS AND THE GLOBAL NAV SYS WHICH WERE CONSISTENTLY 50 PLUS MI DIFFERENT, LOGGING THEM FOR A MAINT WRITE-UP. AT OUR DEST, THE FO DISCOVERED THE PROB. THE VERY DANGEROUS ERROR AND HIDDEN HONEYWELL 'TRAP.' WE ENTERED AABB MANUALLY AS IT WAS NOT DEFINED IN THE DATABASE. IN SO DOING, THE FO GAVE ME THE WRONG DISTANCE FOR PLACE-BEARING-DISTANCE, GIVING ME THE DISTANCE BTWN VOR'S INSTEAD OF THE MILEAGE BTWN VOR AND FIX. WHEN IT DID NOT LOOK RIGHT I CHKED THE CHART MYSELF AND POINTED OUT HIS ERROR TO HIM, AND PROCEEDED TO CORRECT THE DEFINED FIX ERROR. I WAS UNABLE TO CORRECT THE ERROR TO MY AMAZEMENT GETTING ERRORS 'FIX USED BY ACTIVE FLT PATH. NOT TO WORRY, I DELETED THE FIX FROM THE ACTIVE FLT PATH AND REENTERED IT, ONLY I FOUND I WAS UNABLE TO NOW DELETE AND CORRECT IT FOR REASONS UNDETERMINED, ABIDED BY THE AGE OLD ADAGE, 'FLY THE ACFT, AND FALL BACK TO RAW DATA WHEN THE FMS PROGRAMMING IS CONSUMING TOO MUCH DISTRACTING TIME IN BUSY AIRSPACE OR HIGH WORKLOAD PERIODS.' THE FLT WAS COMPLETED WITH NO PROBS, AND SINCE AABB WAS LONG PAST AT TRIPS END, IT WAS EQUALLY FORGOTTEN AFTER A LONG TIRING TRIP FROM YYY, AND AFTER A BUSY DSCNT IN CONGESTED AIRSPACE. WHEN WE CHKED WHAT THE FO REMEMBERED, SURE ENOUGH THE INCORRECT FIX WITH CORRECT PLACE-BEARING AND WRONG DISTANCE WAS STILL IN THE DATABASE, EXACTLY 50 PLUS MI TOO FAR FROM THE 'PLACE' VOR! THE HONEYWELL TRAP!!! THERE IS NO WAY HONEYWELL MAKES THE PLT AWARE THAT THE FIX HE CHOSE WAS MANMADE AND NOT FROM THE DATABASE! NOW LET'S ANALYZE THE FEATURES OF THE HONEYWELL FMS. WHEN ONE ENTERS SPD/ALT AS OPPOSED TO LETTING THE COMPUTER GENERATE THESE, THE SYS DISPLAYS THESE INPUTS AS LARGER POINT SIZE CHARACTERS, SIGNIFYING THAT SOMEONE, NOT THE COMPUTER ENTERED THESE FIGURES. WHEN ONE CREATES A FIX THAT IS NOT IN THE DATABASE, AN ASTERISK APPEARS NEXT TO THE NAME ON THE FLT PATH PAGE IN THE CURRENT ACTIVE FLT PATH ONLY. SUBSEQUENT SELECTION OF THE FIX BY NAME GIVES NO NOTIFICATION OF HOW THIS FIX WAS CREATED DATABASE OR PLT INPUT, NOTHING! NO ASTERISK. NO ENLARGED CHARACTER SIZE. NOTHING! IT WAS ALSO MY INCORRECT UNDERSTANDING THAT THE FIX WOULD DISAPPEAR FROM MEMORY AS DOES THE FLT PATH WHEN CREATED ON THE ACTIVE FLT PATH PAGE, SO THEREFORE I WAS NOT CONCERNED THAT I IGNORED THE ERROR AND COULD NOT CORRECT IT FOR WHATEVER REASON. THE SYS IN THE DA90 IS ADMITTEDLY DIFFERENT FROM THAT IN THE B757 ALTHOUGH THEY SHARE MANY SIMILARITIES. CONCLUSION AND IMMEDIATE PREVENTION SUGGESTIONS. PLTS: TRY TO KNOW AND REMEMBER ALL THE EQUIP LIMITATIONS. TRY TO REMEMBER TO CLR OUT ALL ERRONEOUS WAYPOINTS. THE PF THIS INCIDENT TRIP HAD NO IDEA THE FIX DID NOT COME FROM THE DATABASE, DIFFERENT PLT, DIFFERENT DAY. CLR OUT ALL WAYPOINTS IN THE 'FILES CLR' FUNCTION AS A MATTER OF HABIT. CHK ALL WAYPOINTS ALWAYS. THIS IS NOT ALWAYS POSSIBLE IN A HIGH WORKLOAD ENVIRONMENT, BUSY APCH/DSCNT, ESPECIALLY WITH CURRENT HONEYWELL DESIGN. BACKUP FMS WITH RAW DATA VOR/NDB ON THE PNF INSTS. THIS IS NOT ALWAYS POSSIBLE SUCH AS IN THE INCIDENT FLT AS WE WERE ON A 'VECTOR THEN AN RNAV DIRECT RTE TO A FIX, EVEN DIFFICULT IF DEFINED BY CROSS RADIALS, AND NOT A RECOMMENDED WAY TO NAV. INCREASE DSCNT RATE AND INVESTIGATE BACKUP NAV VERIFICATION IMMEDIATELY UPON ATC QUERY OF A NAV DISCREPANCY BTWN ACFT AND ATC. CTLRS: BETTER USE OF TERMINOLOGY AND QUERIES! A BETTER CHOICE OF WORDS MIGHT HAVE BEEN 'CONFIRM YOU POS 20 MI N OF ABC, WHICH I SHOW ON RADAR.' LONG TERM SUGGESTION: FORCE THE ARROGANT HONEYWELL/FALCON JET TO MODIFY THE EQUIP TO DISPLAY SOMETHING THAT WOULD KEY THE PLT IN TO THE FACT THAT THE FIX IS MAN-MADE AS SUGGESTED EARLIER IN THIS DOCUMENT BEFORE SOMEONE IS KILLED!
Data retrieved from NASA's ASRS site as of July 2007 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.