Anyone who’s been paying attention might wonder as an enroute center controller why I’ve been criticizing ERAM so much lately.
After all, ERAM is the next generation enroute center tool that one would assume is supposed to help air traffic controllers do their jobs better.
I made the following statement back in this entry:
Anything the FAA could offer to controllers to decrease their workload and provide them help in reducing the potential for mistakes would be welcome.
If indeed I believed ERAM was going to make my job easier, that might be true.
Although there is lots of underlying capability for future expansion, ERAM doesn’t really include any new tools for controllers.
We’re not guessing about what ERAM has in store for us. We’ve already had our ERAM training in preparation to use it on live traffic.
And so far we’re not wild about what we’re seeing.
The first thing that many controllers noticed when we got our initial training on ERAM was that doing some simple things, like removing the display of a data block (the information tag for an aircraft displayed on the radar screen), was going to be more time consuming in ERAM than with the current system.
Controllers scan their radar display screen continuously while they’re working, looking for things to do. Primarily they’re looking for aircraft that have the potential to come too close together, but there are a lot of other job functions controllers also have to complete.
Each aircraft has a data block on it that displays basic information on the flight including call sign, altitude and airspeed, and controllers only display data blocks on aircraft in or about to enter their own sectors. As I noted here, air traffic control is very compartmentalized, and controllers only separate and work airplanes within a strictly defined area. Other controllers have responsibilities for their own sections of airspace.
Because of that controllers don’t want to see aircraft data blocks that they aren’t responsible for because it’s more information they have to mentally process during their visual scans of their radar displays. So they only display the data blocks on aircraft they need to on their screen.
Once an aircraft transits a controller’s sector and leaves his airspace he removes the data block from his screen.
In ERAM it takes two computer entries to drop that data block instead of a single entry that is currently required. (That’s because ERAM now adds another type of data block for aircraft, and selecting a data block first displays the alternate data block, then the next selection actually removes it from the display.)
So what’s the big problem with two whole computer entries? After all it can’t possibly take that much extra time or effort.
But doubling the amount of time it takes to do a single task, no matter how small, is a reduction in efficiency. That’s simple math.
And it’s significant in that it shows that ERAM just doesn’t appear like it was designed by and for controllers.
Air traffic control work is mainly about efficiency and prioritization. The routine tasks controllers do need to be done as efficiently as possible, because that leaves controllers time to do the non-routine tasks. Controllers prioritize those tasks and re-prioritize continuously.
But ERAM, by design, makes many simple tasks like this more difficult, without adding any features that will really help controllers do their primary job (which is keeping aircraft separated) better.
Controllers know what they need to do their jobs, and probably would have some good ideas about what tools they could use to do their jobs better. There are a lot of “features” (some would call them “gizmos”) in ERAM undoubtedly, but very few that actually will enable controllers to actually work traffic better and more efficiently.
At the very least, controllers would like to see the basic functionality and capability of their current tools replicated, and an equal or better replication at that.
ERAM has a lot of features that people who think they know what air traffic controllers might need (or what has a gee-whiz factor); not what they actually need.
That’s because the contractors sold ERAM to FAA managers who have no idea how controllers work every day. They were wowed by the gee-whiz features, and didn’t really know or care about what controllers actually needed.
Remember the FAA’s problem with NORDO aircraft that I blogged about recently?
Our current enroute radar display system, the Display System Replacement (DSR) that was salvaged from the wreckage of the FAA and IBM’s early 1980’s-90’s Initial Sector Suite System (ISSS) project didn’t/doesn’t have a tool intended for controllers to indicate which aircraft are on frequency.
Neither does the User Request Evaluation Tool (URET) which they added more recently.
But after some recent events that hit the headlines, the FAA has mandated this problem be addressed as a “National Security Issue”. (Never mind that it’s another example of the FAA reacting to bad press.)
Now the FAA wants controllers to choose their own method to indicate which aircraft are on frequency, using something that weren’t intended for that purpose (a hammer to do the work of a wrench), simply because they failed to provide controllers with a tool to specifically do that.
ERAM coincidentally, doesn’t have a tool designed for this purpose either. So the brand new, “next generation” enroute computer system, although adding lots of features controllers don’t need, by the FAA’s own recent mandate, by design doesn’t provide one they do need, also proving that the FAA really doesn’t know (or care about) what controllers need to do their jobs.
But probably the scariest thing about ERAM is its reliability and stability. Running air traffic on a system that could crash at any time isn’t something any controller is going to be happy about.
One of the most unsettling things for a radar controller is for him to realize that his radar display is no longer functioning properly. Without a functioning radar display a radar controller is blind. A broken display is indicated by a big red “X” depicted across the screen, something we’ve heard has already happened time and time again during the Salt Lake City eight day test that only started last Saturday.
Even worse yet than the bugs and instability themselves is that we know that in an effort to create positive spin on the program development the FAA is intentionally withholding knowledge of many of the problems from controllers. For instance we hear an ERAM test resulted in hundreds of problems, but are told by our managers that the test went well.
Controllers have been told to look at ERAM in a positive light because looking at it negatively isn’t going to help. The FAA expects us to smell manure and delude ourselves into thinking it smells like roses.
Undoubtedly controllers are pretty set in their ways. Controllers know how their current equipment works, and how to use it to accomplish their duties safely and efficiently. They know its limitations and capabilities.
But ERAM changes that entire dynamic. It takes controllers out of their comfort zone, and forces them to think about a lot of things they don’t currently think about.
Working with new equipment is like regressing back to the days when controllers first learned their trade. It forces experienced controllers to relearn parts of their job, parts of their jobs they currently perform without much thought.
Gaining familiarity with the new system over time will help that. But it’s not going to change the poor replications of functions they use or need (like dropping the data blocks with two entries).
ERAM is forcing controllers to change the way they work, and not necessarily for the better.
Of course right now the buggy ERAM software is a bigger problem regardless.