Narrative:

I was working sector 32 radar when I received a call from salt lake sector 15 (ZLC15) on the shout line 'hand off'. I got off a ZMP line I was about to answer and the ZLC15 controller said hand off on a citation V and then say again. I advised I did not see anybody flashing and he replied must be an eram's anomaly. I said radar. The aircraft was not showing as handing off to me from my side. I had a limited data block only and the ZLC15 controller was showing the aircraft data block in hand off status to my sector. By the time coordination was accomplished; the aircraft was entering my sector. I believe this happened because the ZLC15 controller thought a data block was in hand off status and; as most controllers will do in the normal environment; waited until the last minute to call. This is a regular occurrence because usually when a receiving controller hears hand off he will immediately accept the data block before even answering the line. Since the data block was not on my scope it caused a delay in the acceptance of radar. I feel this is a system deviation on eram. The only recommendation is that eram is being used as an active system with too many anomalies (known and unknown) which can cause undo pressure and distractions to controllers. The political wheel is in charge of this; with little regard to the safety issues that can occur with a given chain of events. This is only one example of an eram problem that can cause a deviation or worse. In this case; the aircraft was climbing through the altitude of another that I was working and potentially could have been an issue. There has been hand off issues with eram for well over a year. When I brought this up to management several months ago and the fact that this causes me to pay additional time and attention on problem aircraft which is a distraction; his reply was that is what we pay you for! Training is inadequate and sporadic on this system. As an example; I was briefed 3 to 4 weeks ago on a series of work around issues for eram; I was briefed last week on a second bunch of issues and workarounds. I was then asked to work eram live and quite honestly did not remember any issues/workarounds from the first briefing and maybe one from the second. The briefing was a fast succession of when this happens do this. I have talked to several controllers that had the same issues. I doubt many would pass a test on the majority of eram functions and workarounds. The FAA briefs us on how we should break the chain in many situations that lead to errors yet the way we are running this system provides many ways for the links in the chain to be broken. My recommendation would be to take a closer look at how the continuing anomalies in eram can cause enough of a distraction to effect the methodologies and expectations that controllers have of an operating system and cause the controller to spend time in areas that take away from the safe operation of their sector.

Related reports:

Google
 

Original NASA ASRS Text

Title: ZDV Controller described a failed hand off event claiming the ERAM equipment has entirely too many anomalies to be in use with live traffic.

Narrative: I was working Sector 32 RADAR when I received a call from Salt Lake Sector 15 (ZLC15) on the shout line 'Hand off'. I got off a ZMP line I was about to answer and the ZLC15 Controller said hand off on a Citation V and then say again. I advised I did not see anybody flashing and he replied must be an ERAM's anomaly. I said RADAR. The aircraft was not showing as handing off to me from my side. I had a limited Data Block only and the ZLC15 Controller was showing the aircraft Data Block in hand off status to my sector. By the time coordination was accomplished; the aircraft was entering my sector. I believe this happened because the ZLC15 Controller thought a Data Block was in hand off status and; as most controllers will do in the normal environment; waited until the last minute to call. This is a regular occurrence because usually when a receiving controller hears hand off he will immediately accept the Data Block before even answering the line. Since the Data Block was not on my scope it caused a delay in the acceptance of RADAR. I feel this is a system deviation on ERAM. The only recommendation is that ERAM is being used as an active system with too many anomalies (known and unknown) which can cause undo pressure and distractions to controllers. The political wheel is in charge of this; with little regard to the safety issues that can occur with a given chain of events. This is only one example of an ERAM problem that can cause a deviation or worse. In this case; the aircraft was climbing through the altitude of another that I was working and potentially could have been an issue. There has been hand off issues with ERAM for well over a year. When I brought this up to management several months ago and the fact that this causes me to pay additional time and attention on problem aircraft which is a distraction; his reply was that is what we pay you for! Training is inadequate and sporadic on this system. As an example; I was briefed 3 to 4 weeks ago on a series of work around issues for ERAM; I was briefed last week on a second bunch of issues and workarounds. I was then asked to work ERAM live and quite honestly did not remember any issues/workarounds from the first briefing and maybe one from the second. The briefing was a fast succession of when this happens do this. I have talked to several controllers that had the same issues. I doubt many would pass a test on the majority of ERAM functions and workarounds. The FAA briefs us on how we should break the chain in many situations that lead to errors yet the way we are running this system provides many ways for the links in the chain to be broken. My recommendation would be to take a closer look at how the continuing anomalies in ERAM can cause enough of a distraction to effect the methodologies and expectations that controllers have of an operating system and cause the controller to spend time in areas that take away from the safe operation of their sector.

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