Narrative:

At approximately XA30z I started working ocean 21 sectors. During my briefing I was informed oceans 21 was running on a new build (T-17). I was also informed that the T-17 build had a radar adaptation built into it and that ZNY was testing the adaptation. During my first 45 minutes on position I coordinated several flight southwest bound into my airspace. During coordination on all of these flights there were issues including a cpar (conflict prediction and reporting) failure and on every flight after coordination was complete a magenta box remained around the approved altitude. The magenta box is supposed to go away once a probe and coordination is complete. This was a huge red flag for me. I raised my concerns to both the flm and 2 sme's in the area. My concerns were ignored by the flm and both sme's agreed that something wasn't right. I was now working under article 65. At approximately XB30z I was called by for coordination on air carrier X and air carrier Y; both aircraft were southbound and routed with only a one minute time difference. Standard separation is 10 minutes. Air carrier X was requesting FL370; air carrier Y was requesting FL390. Air carrier X was probed at FL370 and oceans 21 stated there was no procedural conflict and the altitude was clean. I then probed air carrier Y at FL370 even though the aircraft was requesting FL390 just to see if oceans 21 was as unreliable as my gut told me. Sure enough oceans 21 stated there was no procedural conflict and that FL370 was a safe altitude for air carrier Y even though air carrier X was only a minute in front on the same route and also at FL370. Air carrier X was then coordinated at FL390; which according to oceans 21 was a clean altitude. At this point I had no faith in the system and am just relying on experience and my own nonradar traffic scan to separate airplanes. Approximately 2 minutes after coordinating both flights I notice air carrier Z enter my airspace at FL370. Oceans 21 then sent me a conflict alert that air carrier Z and air carrier X are in conflict. This is only 2 minutes after the same system informed me that FL370 was a safe altitude for air carrier X. Standard separation on crossing traffic is 15 minutes; these 2 airplanes would have crossed with about a minute. Air carrier X was moved to FL350. FL350 was chosen after a visual traffic search of both my airspace and adjacent sectors. No separation was ever lost but this is an extremely dangerous situation that should never happen again. Testing experimental software on live traffic is not acceptable! I feel my concerns were ignored and only my experience as a controller stopped a severe separation error from occurring. I was later informed by an sme that when there is a new build for oceans 21 and a local adaptation is added there is no testing of that adaptation; they just go live with it; once again testing unproven and unreliable software on live traffic. Test any build or adaptation before going live. Controllers should be heavily involved in this testing. Flm's should listen to the controllers and not the techs. We are the ones who know this system; trust our opinion when we say something isn't right.

Related reports:

Google
 

Original NASA ASRS Text

Title: ZNY Oceanic Controller reported the Oceanic ATC system failed to operate properly in Conflict Prediction and Reporting (CPAR). Reporter stated a new software version was in use without adequate testing.

Narrative: At approximately XA30z I started working Ocean 21 sectors. During my briefing I was informed Oceans 21 was running on a new build (T-17). I was also informed that the T-17 build had a radar adaptation built into it and that ZNY was testing the adaptation. During my first 45 minutes on position I coordinated several flight southwest bound into my airspace. During coordination on all of these flights there were issues including a CPAR (Conflict Prediction and Reporting) failure and on every flight after coordination was complete a magenta box remained around the approved altitude. The magenta box is supposed to go away once a probe and coordination is complete. This was a huge red flag for me. I raised my concerns to both the FLM and 2 SME's in the area. My concerns were ignored by the FLM and both SME's agreed that something wasn't right. I was now working under article 65. At approximately XB30z I was called by for coordination on Air Carrier X and Air Carrier Y; both aircraft were southbound and routed with only a one minute time difference. Standard separation is 10 minutes. Air Carrier X was requesting FL370; Air Carrier Y was requesting FL390. Air Carrier X was probed at FL370 and Oceans 21 stated there was no procedural conflict and the altitude was clean. I then probed Air Carrier Y at FL370 even though the aircraft was requesting FL390 just to see if Oceans 21 was as unreliable as my gut told me. Sure enough Oceans 21 stated there was no procedural conflict and that FL370 was a safe altitude for Air Carrier Y even though Air Carrier X was only a minute in front on the same route and also at FL370. Air Carrier X was then coordinated at FL390; which according to Oceans 21 was a clean altitude. At this point I had no faith in the system and am just relying on experience and my own nonradar traffic scan to separate airplanes. Approximately 2 minutes after coordinating both flights I notice Air Carrier Z enter my airspace at FL370. Oceans 21 then sent me a conflict alert that Air Carrier Z and Air Carrier X are in conflict. This is only 2 minutes after the same system informed me that FL370 was a safe altitude for Air Carrier X. Standard separation on crossing traffic is 15 minutes; these 2 airplanes would have crossed with about a minute. Air Carrier X was moved to FL350. FL350 was chosen after a visual traffic search of both my airspace and adjacent sectors. No separation was ever lost but this is an extremely dangerous situation that should never happen again. Testing experimental software on live traffic is not acceptable! I feel my concerns were ignored and only my experience as a controller stopped a severe separation error from occurring. I was later informed by an SME that when there is a new build for Oceans 21 and a local adaptation is added there is no testing of that adaptation; they just go live with it; once again testing unproven and unreliable software on live traffic. Test any build or adaptation before going live. Controllers should be heavily involved in this testing. FLM's should listen to the controllers and not the techs. We are the ones who know this system; trust our opinion when we say something isn't right.

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.