Narrative:

First thing in the morning a supervisor split sector 68 to get currency time. I was paged and told to relieve the supervisor on sector 68. Due to a NOTAM for aircraft to file around edmonton centers airspace sector 68 was quite a bit busier. When I plugged in for a relief briefing; but before the relief briefing button had been hit the supervisor explained an automation problem in which aircraft X was westbound sector that flight data planning (fdp) assigned a new code to because the code he was on was already in use. This is a fairly common occurrence. The code aircraft X was on was the code delegated for aircraft Y so microprocessor-en route automated radar tracking system (mearts) auto acquired the aircraft Y data tag to the aircraft X limited data block. The supervisor was asking me if I knew the best way to fix the problem; concerned if they track dropped the data block it would just continue to require until they were able to establish comms with aircraft X and assign a new code. In asking the supervisor where aircraft Y was or coming from it was answered that he was unsure; but in looking at the flight plan was possibly in sector 7 or 8. So while the supervisor; per my suggestion; called vancouver [sector X] and requested they issue the new code to aircraft X I walked over and checked with sector 7 and 8 to make sure they weren't working aircraft Y and didn't now have a limited data block flying through their airspace. This is something that mearts should not do; but checked just to make sure. When I returned to the sector to proceed with a relief briefing aircraft X's new code had been issued and the target was tagged up correctly. Then at this point aircraft Y checked on frequency; but the supervisor working the position was unaware where he was or why he was calling. In a quick scan of my own I noticed a limited data block on a xyyy code in oakland oceanic airspace; approaching the sec 68 southern fir. I pointed out the limited to the supervisor and then checked the strip board and found the strip for aircraft Y in the hampton bay and verified indeed the limited data block was aircraft Y based on fir coordinate fix time and altitude. The supervisor issued the beacon code to aircraft Y; then started a briefing. After taking over control of the sector and scanning traffic I noticed that another flight westbound on aircraft Z approximately 8-9 minutes behind the point aircraft Y was crossing aircraft Z. It was clear the supervisor was unaware that aircraft Y was entering the airspace non-radar from oakland; and I don't believe realized the potential non-radar traffic situation. Based on oceanic procedural separation standard between two non-radar aircraft of 50 nm lateral it is possible that technically a procedural loss of separation occurred. Except the separation is between a radar aircraft and a non-radar aircraft; so if you add the protected airspace of them together is it 27.5 nm based on oceanic standards? In which case radar identification occurred before the aircraft were that close. Sector 68 being an offshore control area in which domestic non-radar separations standards can be applied it could be argued that only 8 nm lateral was needed based on GPS point to point. In which case radar identification was established well before then. Since both aircraft were controller pilot datalink communication (cpdlc) connected and once aircraft Y was radar identified 20 nm ATD longitudinal separation could be established in the event either aircraft temporarily dropped off radar in the known unreliable radar coverage area along and south of aircraft Z between 140W and hmptn. Given the aircrafts altitude it was likely they would remain in radar coverage. It is easy to miss that these flights are entering your airspace non-radar since the fix posting on the strip is very similar to that of aircraft entering the airspace in radar from vancouver [sector Y].given the current setup only diligence in paying very close attention to route of flight and coordinated fixes to not overlook non radars is the only way I see to prevent in the future. At one point in time airspace and procedures was working on establishing fixes along the sec 68 and oakland oceanic common boundary and notaming that aircraft must file over one of the fixes. This would greatly help the non-radar flights stand out. Ultimately the expansion of advanced technologies and oceanic procedures (atop) to take over sector 68 would basically eradicate the potential of a re-occurrence.

Google
 

Original NASA ASRS Text

Title: ZAN Controller described problems associated with non-radar and radar aircraft; and separation requirements. Controller was unsure of what standard applied to the aircraft involved.

Narrative: First thing in the morning a supervisor split sector 68 to get currency time. I was paged and told to relieve the supervisor on sector 68. Due to a NOTAM for aircraft to file around Edmonton Centers airspace Sector 68 was quite a bit busier. When I plugged in for a relief briefing; but before the relief briefing button had been hit the supervisor explained an automation problem in which Aircraft X was westbound sector that Flight Data Planning (FDP) assigned a new code to because the code he was on was already in use. This is a fairly common occurrence. The code Aircraft X was on was the code delegated for Aircraft Y so Microprocessor-En Route Automated Radar Tracking System (MEARTS) auto acquired the Aircraft Y data tag to the Aircraft X limited data block. The supervisor was asking me if I knew the best way to fix the problem; concerned if they track dropped the data block it would just continue to require until they were able to establish comms with Aircraft X and assign a new code. In asking the supervisor where Aircraft Y was or coming from it was answered that he was unsure; but in looking at the flight plan was possibly in sector 7 or 8. So while the supervisor; per my suggestion; called Vancouver [Sector X] and requested they issue the new code to Aircraft X I walked over and checked with sector 7 and 8 to make sure they weren't working Aircraft Y and didn't now have a limited data block flying through their airspace. This is something that MEARTS should not do; but checked just to make sure. When I returned to the sector to proceed with a relief briefing Aircraft X's new code had been issued and the target was tagged up correctly. Then at this point Aircraft Y checked on frequency; but the supervisor working the position was unaware where he was or why he was calling. In a quick scan of my own I noticed a limited data block on a XYYY code in Oakland Oceanic airspace; approaching the sec 68 southern FIR. I pointed out the limited to the supervisor and then checked the strip board and found the strip for Aircraft Y in the Hampton bay and verified indeed the limited data block was Aircraft Y based on FIR coordinate fix time and altitude. The supervisor issued the beacon code to Aircraft Y; then started a briefing. After taking over control of the sector and scanning traffic I noticed that another flight westbound on Aircraft Z approximately 8-9 minutes behind the point Aircraft Y was crossing Aircraft Z. It was clear the supervisor was unaware that Aircraft Y was entering the airspace non-radar from Oakland; and I don't believe realized the potential non-radar traffic situation. Based on Oceanic procedural separation standard between two non-radar aircraft of 50 nm lateral it is possible that technically a procedural loss of separation occurred. Except the separation is between a radar aircraft and a non-radar aircraft; so if you add the protected airspace of them together is it 27.5 nm based on oceanic standards? In which case radar identification occurred before the aircraft were that close. Sector 68 being an offshore control area in which domestic non-radar separations standards can be applied it could be argued that only 8 nm lateral was needed based on GPS point to point. In which case radar identification was established well before then. Since both aircraft were Controller Pilot Datalink Communication (CPDLC) connected and once Aircraft Y was radar identified 20 nm ATD longitudinal separation could be established in the event either aircraft temporarily dropped off radar in the known unreliable radar coverage area along and South of Aircraft Z between 140W and HMPTN. Given the aircrafts altitude it was likely they would remain in radar coverage. It is easy to miss that these flights are entering your airspace non-radar since the fix posting on the strip is very similar to that of aircraft entering the airspace in radar from Vancouver [sector Y].Given the current setup only diligence in paying very close attention to route of flight and coordinated fixes to not overlook non radars is the only way I see to prevent in the future. At one point in time airspace and procedures was working on establishing fixes along the sec 68 and Oakland Oceanic common boundary and NOTAMing that aircraft must file over one of the fixes. This would greatly help the non-radar flights stand out. Ultimately the expansion of Advanced Technologies and Oceanic Procedures (ATOP) to take over sector 68 would basically eradicate the potential of a re-occurrence.

Data retrieved from NASA's ASRS site 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.