Narrative:

I noticed that the altimeter for frm was old; so I made a change to eram reporting frm altimeter as missing and subsequently reported this to the southeast as out of service. This is normal and AWOS do fail at times. I noticed that the altimeter reading for frm was not only incorrect; it was yesterday's altimeter. It had the same time and the altimeter reading. I verified on my aisr that I had not received a new altimeter for the last 6 hours and I also confirmed with the ZMP weather unit that they had not received a new altimeter for frm for the last 24 hours. Eram somehow put yesterday's 1655 altimeter back in some time before today. As a result; this will cause the controllers to issue an incorrect altimeter setting for landing aircraft/or low flying aircraft near frm; which is very dangerous and creates a safety issue. Please resolve this software issue immediately. I received an error from eram in the flight plan correction box on an A330. In an attempt to figure out what was wrong with the flight plan; I re-entered the flight plan into eram to generate an error message. The error message stated 'invalid message type.' we have written this type of problem up with the eram team in the past. I believe that the eram team has been diligently trying to solve this and many other eram issues. However; we are not getting written direction on how to handle this problem and the other eram problems. I feel that I am 'flying by the seat of my pants' with handling these eram messages; where in host we had clear written direction on how to handle these issues. In reference to the flight plan for the A330; I suspect that the problem is the route of flight. I have many questions. 1) does eram recognize all fixes across the globe? 2) what does eram do when these fixes are duplicated? 3) is there a way for eram to tell flight data specialist what fix it is having an issue with? 4) if the route is the issue; why are we getting the error message that reads 'invalid message type' if in fact it is a route problem? This is misleading there are two issues here: 1) we need written direction; even if it for the interim; until we get eram figured out; on how to handle the eram error messages in flight data. 2) we need new written instructions (policies; procedures; orders) from management detailing our job responsibilities when it involves an eram error message. With regards to the altimeter issue and eram issue; this is probably a software programming issue that will need correction. With regards to the eram error message issue; we need direction from eram software engineers and FAA management on how to handle these eram issues. We need new written policies and procedures so that we have a clear understanding of our job responsibilities.

Related reports:

Google
 

Original NASA ASRS Text

Title: ZMP Controller described an ERAM failure to update the altimeter as required. The reporter presented a number of questions regarding ERAM and its functionality.

Narrative: I noticed that the altimeter for FRM was old; so I made a change to ERAM reporting FRM altimeter as missing and subsequently reported this to the southeast as out of service. This is normal and AWOS do fail at times. I noticed that the altimeter reading for FRM was not only incorrect; it was yesterday's altimeter. It had the same time and the altimeter reading. I verified on my AISR that I had not received a new altimeter for the last 6 hours and I also confirmed with the ZMP weather unit that they had not received a new altimeter for FRM for the last 24 hours. ERAM somehow put yesterday's 1655 altimeter back in some time before today. As a result; this will cause the controllers to issue an incorrect altimeter setting for landing aircraft/or low flying aircraft near FRM; which is very dangerous and creates a safety issue. Please resolve this software issue immediately. I received an error from ERAM in the flight plan correction box on an A330. In an attempt to figure out what was wrong with the flight plan; I re-entered the flight plan into ERAM to generate an error message. The error message stated 'invalid message type.' We have written this type of problem up with the ERAM team in the past. I believe that the ERAM team has been diligently trying to solve this and many other ERAM issues. However; we are not getting written direction on how to handle this problem and the other ERAM problems. I feel that I am 'flying by the seat of my pants' with handling these ERAM messages; where in HOST we had clear written direction on how to handle these issues. In reference to the flight plan for the A330; I suspect that the problem is the route of flight. I have many questions. 1) Does ERAM recognize all fixes across the globe? 2) What does ERAM do when these fixes are duplicated? 3) Is there a way for ERAM to tell Flight Data specialist what fix it is having an issue with? 4) If the route is the issue; why are we getting the error message that reads 'invalid message type' if in fact it is a route problem? This is misleading There are two issues here: 1) We need written direction; even if it for the interim; until we get ERAM figured out; on how to handle the ERAM error messages in flight data. 2) We need new written instructions (policies; procedures; orders) from management detailing our job responsibilities when it involves an ERAM error message. With regards to the Altimeter issue and ERAM issue; this is probably a software programming issue that will need correction. With regards to the ERAM Error message issue; we need direction from ERAM software engineers and FAA management on how to handle these ERAM issues. We need new written policies and procedures so that we have a clear understanding of our job responsibilities.

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.