Narrative:

I was working oceanic sectors combined on the mid shift. Aircraft X traversed my airspace into vancouver's airspace; with a flight plan route through vancouver's airspace directly into anchorage's airspace. Once this aircraft left my airspace it was not to return according to the [ZOA] flight plan. Upon entering vancouver's airspace; the data block turned grey; as all aircraft outside of your airspace are gray. If you right click on an aircraft's airplane symbol when they are outside of your airspace it will either a) bring up a pop-up route clearance window; which means that the aircraft will in fact enter your airspace or B) it will drop/raise the aircraft's data tag. My personal technique is to right click on aircraft as soon as possible when they leave my airspace in order to reduce clutter on my screen. I right clicked aircraft X's symbol and the data tag was removed from my screen. That instantly tells me that the aircraft has left my airspace and will not return. A couple of minutes later I received an ads position report with an out-of-conformance next waypoint for aircraft X. This occurrence happens all the time. What happens is that we send an ads aircraft to another facility/sector on his flight plan route and then that facility/sector turns or vectors the aircraft immediately inside their own airspace. Now; when that aircraft turns; the ads still pings back down to our oceanic sector and tells us that the aircraft is now heading off of the filed route we sent him to the other facility/sector with. Is this a cause for alarm? No. It's their airspace and they can turn aircraft at will. These messages get discarded as we do not need them; nor care what the aircraft is doing in the other facility/sector. When I received this message for aircraft X; I clicked process to open the position report. Within the position report window I see a bad second fix that is made up of a large lat/long strand from aircraft X's ads. I then clicked enter but it won't enter with the bad information so I closed the position report. I then deleted the message from my sector queue. About 20 minutes later I probed aircraft Y; on track J; a climb from FL310 to FL320. There was no conflict from the conflict probe function. I sent aircraft Y a message asking when he could accept FL320. I received his response of 'any time' and issued aircraft Y a climb to FL320. It was discovered later that aircraft X was in fact on the same track as aircraft Y was; track J. That night track J entered vancouver's airspace at kanua and then came back into our airspace at ornai. Our system showed aircraft X's flight plan as exiting at kanua and never coming back; but vancouver did have the proper flight plan of aircraft X coming back into our oceanic airspace at ornai. Just recently a letter of agreement was added that allowed vancouver to not have to call our facility back to transfer an aircraft in this exact situation! Well; we thought the aircraft left and atop's software put the flight plan into a cancellation state. In this state we stop receiving messages for this aircraft. Vancouver knows he's coming back to us but no longer has to inform us of such an act. Low and behold; the aircraft enters our airspace without any visual representation or controller knowledge and flies for hundreds of miles without a single message to alert our facility or controllers. When the aircraft Y climbed to FL320; he broke minimum separation standards with the aircraft X at FL320. They both flew at FL320 all the way to anchorage center's airspace where they entered with four minutes separation (ten minutes was needed) and no transfer on the aircraft X at all. It was also discovered that the incorrect flight plan was entered via flight data personnel several hours prior to all of this occurring. It just so happened that the two flight plans for aircraft X were matched up until the kanua fix. In one flight plan; after leaving our airspace; the flight never comes back. In the otherflight plan; after leaving our airspace; the aircraft is suppose to return to us from a facility that is no longer required to inform us. More awareness and diligence from the flight data personnel to enter a correct flight plan from the beginning is needed. Any time that an aircraft's control is transferred between facilities/sectors there needs to be some sort of coordination; period. This coordination could be automated. Between vancouver and oakland's oceanic there is no automated means so any and all coordination is completed via a verbal phone call. Had vancouver called and informed us of aircraft X's return to the ocean it would have caught the incorrect flight plan in our system and allowed a save to occur. If procedurally we were made to open all out-of-conformance position reports for ads aircraft leaving our airspace and actually plot the random lat/long coordinates; then I suggest a function with a button on the position report window be built into the atop software; so that we as controllers can open a position report and hit the 'plot' button and; when we do; a plotted line is displayed on our screen of the way points that the aircraft's ads is reporting. A fast; clear; and concise depiction of what that aircraft is doing based on his ads reporting.open all out-of-conformance position reports for ads aircraft leaving our airspace and actually plot the random lat/long coordinates... Then I suggest a function with a button on the position report window be built into the atop software. So that we as controllers can open a position report and hit the 'plot' button; and when we do; a plotted line is displayed on our screen of the way points that the aircraft's ads is reporting. A fast; clear; and concise depiction of what that aircraft is doing based on his ads reporting.

Related reports:

Google
 

Original NASA ASRS Text

Title: A ZOA Oceanic controller reported loss of separation when there was confusion as to which of two flight plans was accurate. ZOA had one clearance while Vancouver held another.

Narrative: I was working oceanic sectors combined on the mid shift. Aircraft X traversed my airspace into Vancouver's airspace; with a flight plan route through Vancouver's airspace directly into Anchorage's airspace. Once this aircraft left my airspace it was not to return according to the [ZOA] flight plan. Upon entering Vancouver's airspace; the data block turned grey; as all aircraft outside of your airspace are gray. If you right click on an aircraft's airplane symbol when they are outside of your airspace it will either A) bring up a pop-up route clearance window; which means that the aircraft will in fact enter your airspace OR B) it will drop/raise the aircraft's data tag. My personal technique is to right click on aircraft as soon as possible when they leave my airspace in order to reduce clutter on my screen. I right clicked Aircraft X's symbol and the data tag was removed from my screen. That instantly tells me that the aircraft has left my airspace and will not return. A couple of minutes later I received an ADS position report with an out-of-conformance next waypoint for Aircraft X. This occurrence happens ALL the time. What happens is that we send an ADS aircraft to another facility/sector on his flight plan route and then that facility/sector turns or vectors the aircraft immediately inside their own airspace. Now; when that aircraft turns; the ADS still pings back down to our oceanic sector and tells us that the aircraft is now heading off of the filed route we sent him to the other facility/sector with. Is this a cause for alarm? No. It's their airspace and they can turn aircraft at will. These messages get discarded as we do not need them; nor care what the aircraft is doing in the other facility/sector. When I received this message for Aircraft X; I clicked PROCESS to open the position report. Within the position report window I see a bad second fix that is made up of a large lat/long strand from Aircraft X's ADS. I then clicked ENTER but it won't enter with the bad information so I closed the position report. I then deleted the message from my sector queue. About 20 minutes later I probed Aircraft Y; on Track J; a climb from FL310 to FL320. There was no conflict from the conflict probe function. I sent Aircraft Y a message asking when he could accept FL320. I received his response of 'any time' and issued Aircraft Y a climb to FL320. It was discovered later that Aircraft X was in fact on the same track as Aircraft Y was; Track J. That night Track J entered Vancouver's airspace at KANUA and then came back into our airspace at ORNAI. Our system showed Aircraft X's flight plan as exiting at KANUA and never coming back; but Vancouver did have the proper flight plan of Aircraft X coming back into our oceanic airspace at ORNAI. Just recently a Letter of Agreement was added that allowed Vancouver to NOT have to call our facility back to transfer an aircraft in this exact situation! Well; we thought the aircraft left and ATOP's software put the flight plan into a cancellation state. In this state we stop receiving messages for this aircraft. Vancouver knows he's coming back to us but no longer has to inform us of such an act. Low and behold; the aircraft enters our airspace without any visual representation or controller knowledge and flies for hundreds of miles without a single message to alert our facility or controllers. When the Aircraft Y climbed to FL320; he broke minimum separation standards with the Aircraft X at FL320. They both flew at FL320 all the way to Anchorage Center's airspace where they entered with four minutes separation (ten minutes was needed) and no transfer on the Aircraft X at all. It was also discovered that the incorrect flight plan was entered via flight data personnel several hours prior to all of this occurring. It just so happened that the two flight plans for Aircraft X were matched up until the KANUA fix. In one flight plan; after leaving our airspace; the flight never comes back. In the otherflight plan; after leaving our airspace; the aircraft is suppose to return to us from a facility that is no longer required to inform us. More awareness and diligence from the flight data personnel to enter a correct flight plan from the beginning is needed. ANY time that an aircraft's control is transferred between facilities/sectors there needs to be some sort of coordination; period. This coordination COULD be automated. Between Vancouver and Oakland's oceanic there is no automated means so any and all coordination is completed via a verbal phone call. Had Vancouver called and informed us of Aircraft X's return to the ocean it would have caught the incorrect flight plan in our system and allowed a save to occur. If procedurally we were made to open all out-of-conformance position reports for ADS aircraft leaving our airspace and actually plot the random lat/long coordinates; then I suggest a function with a button on the position report window be built into the ATOP software; so that we as controllers can open a position report and hit the 'PLOT' button and; when we do; a plotted line is displayed on our screen of the way points that the aircraft's ADS is reporting. A fast; clear; and concise depiction of what that aircraft is doing based on his ADS reporting.open all out-of-conformance position reports for ADS aircraft leaving our airspace and actually plot the random lat/long coordinates... then I suggest a function with a button on the position report window be built into the ATOP software. So that we as controllers can open a position report and hit the 'PLOT' button; and when we do; a plotted line is displayed on our screen of the way points that the aircraft's ADS is reporting. A fast; clear; and concise depiction of what that aircraft is doing based on his ADS reporting.

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.