37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 690988 |
Time | |
Date | 200603 |
Local Time Of Day | 1201 To 1800 |
Place | |
Locale Reference | intersection : bebop |
State Reference | US |
Altitude | msl single value : 33000 |
Environment | |
Flight Conditions | VMC |
Light | Daylight |
Aircraft 1 | |
Controlling Facilities | artcc : zoa.artcc |
Operator | other |
Make Model Name | Stratotanker 135 |
Navigation In Use | other |
Flight Phase | cruise : level |
Route In Use | enroute airway : r464.airway |
Flight Plan | IFR |
Person 1 | |
Affiliation | government : military |
Function | flight crew : first officer |
Qualification | pilot : atp |
Experience | flight time last 90 days : 100 flight time total : 4000 flight time type : 2000 |
ASRS Report | 690988 |
Person 2 | |
Affiliation | government : military |
Function | flight crew : captain oversight : pic |
Events | |
Anomaly | non adherence : clearance other spatial deviation |
Independent Detector | other controllerb |
Resolutory Action | flight crew : became reoriented flight crew : overcame equipment problem flight crew : overrode automation |
Supplementary | |
Problem Areas | Flight Crew Human Performance Chart Or Publication ATC Human Performance Aircraft |
Primary Problem | Aircraft |
Narrative:
On preflight; route was verified point by point; and total distance was verified as correct for the route. On coast-out; time for bebop was passed as XA42; estimate for barrt XB12. At this point we progressively checked the FMS point-to-point against the chart. Oakland oceanic (san francisco radio) did query us several times (which should have been our first hint something was wrong). We were under air carrier X (he was at FL340; within 1 NM on whole route) and we talked to him several times. Because he was data linked; he gave no position reports; which would have also showed there was an error in our system. We gave progressive required position reports from our FMS data. Oakland did verify our times several times; apparently because they saw the problem with our first report (this was confirmed by them over the phone later). At point bandy; we were looking through the FMS timing pages and noticed points bradr and bitta had the same time estimate; which caused us to rechk the latitudes/longitudes closer. We found the software had shifted the latitudes/longitudes after point baart; so each point actually had the next point's latitude/longitude. The system corrected itself at point bitta; the last point on the route. Both points showed the same latitude/longitude in the FMS. At this point we corrected the problem and revised our time to oceanic control. No loss of separation or conflicts occurred. Causes: 1) software that loads rtes skipped a latitude/longitude but kept all point names when loading. This will be passed to software developers for analysis as soon as possible. The aircraft database is correct but rtes are loaded separately to include names and latitudes/longitudes. It was verified as occurring again on 2 other legs on the same trip. 2) when we verified point; we did not closely enough verify the associated latitudes/longitudes. Because of the layout of the FMS page; it showed 2 points at a time with the latitude/longitude and; therefore; was not immediately obvious the points were offset (the latitude/longitude displayed should have corresponded to the lower named point; but incorrectly were shifted to the upper point). 3) oceanic control apparently recognized the problem; but provided no assistance. They confirmed when we called them they knew there was a problem with our first report. 4) because appropriate plotting charts were not available; we did not plot our route; but checked our points against the pacific chart. Because we were on course and the waypoints were correctly displayed on the FMS; the error was not obvious. It took 2 qualified pilots and 20 mins to figure out the problem once it was discovered. Recommendations: 1) correct FMS software to show only 1 point with associated latitude/longitude. 2) correct route software to correctly load points. 3) brief crews to progressively check route latitudes/longitudes/distances on oceanic flts; at one time; before flight. Even checking latitudes/longitudes and distance in-flight did not readily reveal error. 4) if oceanic control sees a problem; they should assist crews to prevent a problem; rather than just verify bad times.
Original NASA ASRS Text
Title: KC135 ENRTE OVER THE PACIFIC HAD FMS PROBS AFTER VERIFYING THE ENTIRE RTE PRIOR TO FLT.
Narrative: ON PREFLT; RTE WAS VERIFIED POINT BY POINT; AND TOTAL DISTANCE WAS VERIFIED AS CORRECT FOR THE RTE. ON COAST-OUT; TIME FOR BEBOP WAS PASSED AS XA42; ESTIMATE FOR BARRT XB12. AT THIS POINT WE PROGRESSIVELY CHKED THE FMS POINT-TO-POINT AGAINST THE CHART. OAKLAND OCEANIC (SAN FRANCISCO RADIO) DID QUERY US SEVERAL TIMES (WHICH SHOULD HAVE BEEN OUR FIRST HINT SOMETHING WAS WRONG). WE WERE UNDER ACR X (HE WAS AT FL340; WITHIN 1 NM ON WHOLE RTE) AND WE TALKED TO HIM SEVERAL TIMES. BECAUSE HE WAS DATA LINKED; HE GAVE NO POS RPTS; WHICH WOULD HAVE ALSO SHOWED THERE WAS AN ERROR IN OUR SYS. WE GAVE PROGRESSIVE REQUIRED POS RPTS FROM OUR FMS DATA. OAKLAND DID VERIFY OUR TIMES SEVERAL TIMES; APPARENTLY BECAUSE THEY SAW THE PROB WITH OUR FIRST RPT (THIS WAS CONFIRMED BY THEM OVER THE PHONE LATER). AT POINT BANDY; WE WERE LOOKING THROUGH THE FMS TIMING PAGES AND NOTICED POINTS BRADR AND BITTA HAD THE SAME TIME ESTIMATE; WHICH CAUSED US TO RECHK THE LATITUDES/LONGITUDES CLOSER. WE FOUND THE SOFTWARE HAD SHIFTED THE LATITUDES/LONGITUDES AFTER POINT BAART; SO EACH POINT ACTUALLY HAD THE NEXT POINT'S LATITUDE/LONGITUDE. THE SYS CORRECTED ITSELF AT POINT BITTA; THE LAST POINT ON THE RTE. BOTH POINTS SHOWED THE SAME LATITUDE/LONGITUDE IN THE FMS. AT THIS POINT WE CORRECTED THE PROB AND REVISED OUR TIME TO OCEANIC CTL. NO LOSS OF SEPARATION OR CONFLICTS OCCURRED. CAUSES: 1) SOFTWARE THAT LOADS RTES SKIPPED A LATITUDE/LONGITUDE BUT KEPT ALL POINT NAMES WHEN LOADING. THIS WILL BE PASSED TO SOFTWARE DEVELOPERS FOR ANALYSIS ASAP. THE ACFT DATABASE IS CORRECT BUT RTES ARE LOADED SEPARATELY TO INCLUDE NAMES AND LATITUDES/LONGITUDES. IT WAS VERIFIED AS OCCURRING AGAIN ON 2 OTHER LEGS ON THE SAME TRIP. 2) WHEN WE VERIFIED POINT; WE DID NOT CLOSELY ENOUGH VERIFY THE ASSOCIATED LATITUDES/LONGITUDES. BECAUSE OF THE LAYOUT OF THE FMS PAGE; IT SHOWED 2 POINTS AT A TIME WITH THE LATITUDE/LONGITUDE AND; THEREFORE; WAS NOT IMMEDIATELY OBVIOUS THE POINTS WERE OFFSET (THE LATITUDE/LONGITUDE DISPLAYED SHOULD HAVE CORRESPONDED TO THE LOWER NAMED POINT; BUT INCORRECTLY WERE SHIFTED TO THE UPPER POINT). 3) OCEANIC CTL APPARENTLY RECOGNIZED THE PROB; BUT PROVIDED NO ASSISTANCE. THEY CONFIRMED WHEN WE CALLED THEM THEY KNEW THERE WAS A PROB WITH OUR FIRST RPT. 4) BECAUSE APPROPRIATE PLOTTING CHARTS WERE NOT AVAILABLE; WE DID NOT PLOT OUR RTE; BUT CHKED OUR POINTS AGAINST THE PACIFIC CHART. BECAUSE WE WERE ON COURSE AND THE WAYPOINTS WERE CORRECTLY DISPLAYED ON THE FMS; THE ERROR WAS NOT OBVIOUS. IT TOOK 2 QUALIFIED PLTS AND 20 MINS TO FIGURE OUT THE PROB ONCE IT WAS DISCOVERED. RECOMMENDATIONS: 1) CORRECT FMS SOFTWARE TO SHOW ONLY 1 POINT WITH ASSOCIATED LATITUDE/LONGITUDE. 2) CORRECT RTE SOFTWARE TO CORRECTLY LOAD POINTS. 3) BRIEF CREWS TO PROGRESSIVELY CHK RTE LATITUDES/LONGITUDES/DISTANCES ON OCEANIC FLTS; AT ONE TIME; BEFORE FLT. EVEN CHKING LATITUDES/LONGITUDES AND DISTANCE INFLT DID NOT READILY REVEAL ERROR. 4) IF OCEANIC CTL SEES A PROB; THEY SHOULD ASSIST CREWS TO PREVENT A PROB; RATHER THAN JUST VERIFY BAD TIMES.
Data retrieved from NASA's ASRS site as of January 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.