37000 Feet | Browse and search NASA's Aviation Safety Reporting System |
|
Attributes | |
ACN | 791793 |
Time | |
Date | 200806 |
Local Time Of Day | 1201 To 1800 |
Place | |
Locale Reference | navaid : boy.vor |
State Reference | WY |
Altitude | msl single value : 35000 |
Environment | |
Flight Conditions | VMC |
Light | Daylight |
Aircraft 1 | |
Controlling Facilities | artcc : zlc.artcc |
Operator | common carrier : air carrier |
Make Model Name | A320 |
Operating Under FAR Part | Part 121 |
Flight Phase | cruise : level |
Flight Plan | IFR |
Person 1 | |
Affiliation | government : faa |
Function | controller : radar |
Qualification | controller : radar |
Experience | controller radar : 16 controller time certified in position1 : 16.02 |
ASRS Report | 791793 |
Events | |
Anomaly | other anomaly other |
Independent Detector | other controllera |
Resolutory Action | none taken : anomaly accepted |
Supplementary | |
Problem Areas | FAA Navigational Facility |
Primary Problem | Navigational Facility |
Situations | |
ATC Facility | computer equipment : zlc.artcc |
Narrative:
We were working sectors 16 and 15 combined. I was training a developmental controller on the D side (radar assistant) when the sector team received information that we needed to provide 40 mi in trail spacing to ZDV on 3 aircraft (X; Y; and Z). Aircraft X; the first aircraft -- destination was boston; aircraft Y and aircraft Z -- destination jfk. The previous sector controller (sector 18) had given a rerte to these 3 aircraft onto the CAN1 traffic management route for arrs to east coast cities; but had inadvertently issued all 3 of them direct cesna intersection. That controller asked us to put the 3 aircraft back on their original route of direct rap.J158.abr direct cesna. We initiated turns on the 3 aircraft to get the 40 mi in trail required spacing and then we issued the clearance 'direct rap.J158.abr..cesna as filed.' I instructed the developmental to put the amendment in using uret; by left clicking on the route of flight; typing in the new amended routing and enter key for the first aircraft which was aircraft Y. Next; since we had to do the same amendment on the other 2 aircraft; I instructed the developmental to use the host keyboard 'recall' button function. At that point; all one needs to do is change the computer identify number and enter; and the amendment will process for next aircraft; thus making a longer amendment easier and quicker to input. We did that on the next 2 aircraft (aircraft X and aircraft Z). The problem arose when 3 hours later in ZBW's airspace; aircraft X inquired about his arrival route to bos. The ZBW controller said 'you're going to boston? I show you going to kennedy.' the information in the flight plan showed aircraft X landing at jfk; instead of bos. I was apprised of the situation later that evening and we figured out what had happened. When one uses the uret route amendment; it functions as a 6-7-10 amendment in the host system; but uret; for some reason; is currently programmed to add a down arrow at the destination airport; something that is inherently not needed and presents a safety issue as here described. The down arrow is a function that allows a controller to change the destination airport; and in host; there is no verification message given. If I change the destination in uret a verification message pops up asking me to verify a change of destination; in host it just accepts the destination change because of the down arrow. The problem occurred because we utilized the 'recall' button on the host keyboard after using the uret route amendment function. (Using uret as a 6-7-10 amendment puts a copy of that amendment in the recall message in host.) when we changed computer identify numbers of the second aircraft (aircraft X) the amendment went through and changed destination on aircraft X to jfk. If the down arrow had not been there; the message would have said 'jfk cannot merge' and we would have caught the problem. In speaking with other controllers; no one remembers the down arrow in uret route amendments until now. Whether it is a new program that has been recently added without controllers' knowledge or has been something that has been there for 10 yrs; I cannot tell. If it has been there the whole 10 yrs; then I am certain this situation has happened several times in the past but somebody has caught the problem and fixed the destination and not found out what occurred. We (controllers in general) all use the uret to host recall function. Perhaps this was a 1-TIME specific situation but it has serious consequences to the integrity of the NAS/host ATC system. We (the controllers) need to be apprised of the problem immediately; but nothing so far has been done. We are telling every controller we work with; but I believe it is a national uret problem and other ctrs need to know about this problem and then the fix needs to be input.
Original NASA ASRS Text
Title: ZLC CTLR EXPERIENCED HOST VS. URET SOFTWARE ANOMALY THAT RESULTED IN ONE ACFT INDICATING THE WRONG DESTINATION ARPT.
Narrative: WE WERE WORKING SECTORS 16 AND 15 COMBINED. I WAS TRAINING A DEVELOPMENTAL CTLR ON THE D SIDE (RADAR ASSISTANT) WHEN THE SECTOR TEAM RECEIVED INFO THAT WE NEEDED TO PROVIDE 40 MI IN TRAIL SPACING TO ZDV ON 3 ACFT (X; Y; AND Z). ACFT X; THE FIRST ACFT -- DEST WAS BOSTON; ACFT Y AND ACFT Z -- DEST JFK. THE PREVIOUS SECTOR CTLR (SECTOR 18) HAD GIVEN A RERTE TO THESE 3 ACFT ONTO THE CAN1 TFC MGMNT RTE FOR ARRS TO EAST COAST CITIES; BUT HAD INADVERTENTLY ISSUED ALL 3 OF THEM DIRECT CESNA INTXN. THAT CTLR ASKED US TO PUT THE 3 ACFT BACK ON THEIR ORIGINAL RTE OF DIRECT RAP.J158.ABR DIRECT CESNA. WE INITIATED TURNS ON THE 3 ACFT TO GET THE 40 MI IN TRAIL REQUIRED SPACING AND THEN WE ISSUED THE CLRNC 'DIRECT RAP.J158.ABR..CESNA AS FILED.' I INSTRUCTED THE DEVELOPMENTAL TO PUT THE AMENDMENT IN USING URET; BY L CLICKING ON THE RTE OF FLT; TYPING IN THE NEW AMENDED ROUTING AND ENTER KEY FOR THE FIRST ACFT WHICH WAS ACFT Y. NEXT; SINCE WE HAD TO DO THE SAME AMENDMENT ON THE OTHER 2 ACFT; I INSTRUCTED THE DEVELOPMENTAL TO USE THE HOST KEYBOARD 'RECALL' BUTTON FUNCTION. AT THAT POINT; ALL ONE NEEDS TO DO IS CHANGE THE COMPUTER IDENT NUMBER AND ENTER; AND THE AMENDMENT WILL PROCESS FOR NEXT ACFT; THUS MAKING A LONGER AMENDMENT EASIER AND QUICKER TO INPUT. WE DID THAT ON THE NEXT 2 ACFT (ACFT X AND ACFT Z). THE PROB AROSE WHEN 3 HRS LATER IN ZBW'S AIRSPACE; ACFT X INQUIRED ABOUT HIS ARR RTE TO BOS. THE ZBW CTLR SAID 'YOU'RE GOING TO BOSTON? I SHOW YOU GOING TO KENNEDY.' THE INFO IN THE FLT PLAN SHOWED ACFT X LNDG AT JFK; INSTEAD OF BOS. I WAS APPRISED OF THE SITUATION LATER THAT EVENING AND WE FIGURED OUT WHAT HAD HAPPENED. WHEN ONE USES THE URET RTE AMENDMENT; IT FUNCTIONS AS A 6-7-10 AMENDMENT IN THE HOST SYS; BUT URET; FOR SOME REASON; IS CURRENTLY PROGRAMMED TO ADD A DOWN ARROW AT THE DEST ARPT; SOMETHING THAT IS INHERENTLY NOT NEEDED AND PRESENTS A SAFETY ISSUE AS HERE DESCRIBED. THE DOWN ARROW IS A FUNCTION THAT ALLOWS A CTLR TO CHANGE THE DEST ARPT; AND IN HOST; THERE IS NO VERIFICATION MESSAGE GIVEN. IF I CHANGE THE DEST IN URET A VERIFICATION MESSAGE POPS UP ASKING ME TO VERIFY A CHANGE OF DEST; IN HOST IT JUST ACCEPTS THE DEST CHANGE BECAUSE OF THE DOWN ARROW. THE PROB OCCURRED BECAUSE WE UTILIZED THE 'RECALL' BUTTON ON THE HOST KEYBOARD AFTER USING THE URET RTE AMENDMENT FUNCTION. (USING URET AS A 6-7-10 AMENDMENT PUTS A COPY OF THAT AMENDMENT IN THE RECALL MESSAGE IN HOST.) WHEN WE CHANGED COMPUTER IDENT NUMBERS OF THE SECOND ACFT (ACFT X) THE AMENDMENT WENT THROUGH AND CHANGED DEST ON ACFT X TO JFK. IF THE DOWN ARROW HAD NOT BEEN THERE; THE MESSAGE WOULD HAVE SAID 'JFK CANNOT MERGE' AND WE WOULD HAVE CAUGHT THE PROB. IN SPEAKING WITH OTHER CTLRS; NO ONE REMEMBERS THE DOWN ARROW IN URET RTE AMENDMENTS UNTIL NOW. WHETHER IT IS A NEW PROGRAM THAT HAS BEEN RECENTLY ADDED WITHOUT CTLRS' KNOWLEDGE OR HAS BEEN SOMETHING THAT HAS BEEN THERE FOR 10 YRS; I CANNOT TELL. IF IT HAS BEEN THERE THE WHOLE 10 YRS; THEN I AM CERTAIN THIS SITUATION HAS HAPPENED SEVERAL TIMES IN THE PAST BUT SOMEBODY HAS CAUGHT THE PROB AND FIXED THE DEST AND NOT FOUND OUT WHAT OCCURRED. WE (CTLRS IN GENERAL) ALL USE THE URET TO HOST RECALL FUNCTION. PERHAPS THIS WAS A 1-TIME SPECIFIC SITUATION BUT IT HAS SERIOUS CONSEQUENCES TO THE INTEGRITY OF THE NAS/HOST ATC SYS. WE (THE CTLRS) NEED TO BE APPRISED OF THE PROB IMMEDIATELY; BUT NOTHING SO FAR HAS BEEN DONE. WE ARE TELLING EVERY CTLR WE WORK WITH; BUT I BELIEVE IT IS A NATIONAL URET PROB AND OTHER CTRS NEED TO KNOW ABOUT THIS PROB AND THEN THE FIX NEEDS TO BE INPUT.
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.