ERAM Habituation

It’s been a while since my last FAA En Route Automation Modernization (ERAM) update, mostly because where I’m sitting it’s been pretty quiet on the ERAM development front.

That’s not to say that ERAM still doesn’t have its share of critical bugs, and it’s still likely not ready for deployment at the busier facilities elsewhere in the country.

I have heard of bugs that were corrected re-appearing in newer ERAM versions still, a problem they’ve been having from the very beginning.

ERAM also still has the potential to crash both an adjacent facility’s HOST computer system, as well as an adjacent ERAM computer system.

But both Salt Lake Center (ZLC) and Seattle Center (ZSE), the two key sites for ERAM, have been making extended continuous runs on ERAM, and we’re not hearing much about how that’s been going at all, even though my facility (Minneapolis ARTCC or ZMP) will be the next facility to run ERAM.

Maybe it’s been going great there.  Maybe all the critical bugs in ERAM have been corrected.  But considering the number of problems ERAM was having a year ago I highly doubt it.

So why aren’t we hearing more about what’s going on with ERAM at those facilities?

I believe it’s primarily due to habituation.

Have you ever walked into a room that had a peculiar odor?  After remaining in the room a while you won’t notice that odor anymore.

That’s a form of habituation.

Here’s the scientific definition:

1. The gradual decline of a response to a stimulus resulting from repeated exposure to the stimulus.

Air traffic controllers get habituated to working with defective equipment and procedures; it happens all the time.

They’ll initially notice and complain about the problems but they’ll invent and/or be ordered to use workarounds to address those problems.  Eventually those workarounds just become a way of doing business, in spite of the fact that the equipment and/or procedure is broken.

Often those procedures and equipment remain broken, never to be fixed.

Air traffic controllers are a pragmatic lot.  They have a pretty straightforward job to do:  keep the airplanes safely apart.

In spite of the faulty equipment and procedures controllers know they still have to do their jobs.

Although they’ll initially complain about faulty equipment and procedures, after a while they’ll give up and just deal with it.

The workarounds are always easier than trying to get the FAA to actually fix/correct a problem.

Of course once the controllers stop complaining about problems and filing reports on them, the FAA often chooses to believe they’ve been magically fixed, when they’re really just “out of sight, out of mind”.  Thus the problems go on forever without ever being addressed.

If controllers object to being forced to use new equipment and procedures that don’t work, the FAA simply accuses them of  “being resistant to change”.  Although controllers may be resistant to change, there isn’t a single controller I know that wouldn’t love to have better tools to make doing his job easier.  (The only caveat is that they want those tools to work properly.)

Ultimately controllers come to learn that complaining won’t change anything in the FAA, because those tasked with making decisions about using the faulty equipment and procedures don’t actually have to use them to accomplish their jobs.  Using the faulty equipment and/or procedures always becomes the air traffic controllers’ problem.

The managers in the FAA making decisions to start using the faulty equipment have completely different priorities than air traffic controllers, and they know that controllers are (generally) a smart lot and will figure out how to use the crappy equipment and procedures that are forced upon them (and always have).

If they don’t and something goes wrong, they can always use the air traffic controller as a scapegoat:  he failed to perform.

That’s why the FAA “formally accepted” ERAM from its contractor, Lockheed Martin, before it was ready for use in air traffic.  To those managers in the FAA, staying on schedule and budget was infinitely more important than whether or not the equipment worked.

Now the taxpayer is on the hook for paying for the numerous fixes ERAM needs before it can be used to safely separate airplanes.

After using ERAM for a while the controllers at ZLC and ZSE will become habituated to its problems.

They’ll figure out ways to deal with the more critical problems and ignore the rest of them.

It’s very similar to what happened with URET (User Request Evaluation Tool).  The FAA started deploying this paper flight strip replacement system to the enroute centers sometime around 1997, completing its deployment in 2006.

Most controllers like URET because it relieves them from the tedium of managing paper flight strips.

URET also has much improved route amendment functionality over the previous typed “6-7-10” amendment controllers used to have to do.

But years later it still doesn’t work that well for some things, and still has numerous bugs in it that have yet to be corrected.

URET has this functionality called “conflict probe”.  It’s supposed to continuously detect whether or not aircraft are predicted to get too close together.  In such a case URET flags those flights for a controller’s attention.

However, the conflict probe only works accurately and in a timely manner maybe 85% of the time.  It sometimes creates false alerts (creating a distraction to controllers), or doesn’t create an alert when it should.

However, the FAA has made sure to tell controllers that URET is only a “tool” to keep airplanes separated; if URET is wrong controllers have to recognize that fact and ignore it.  The FAA has made it clear that it’s not legal for controllers to use URET to separate airplanes, and if a controller trusts URET and it’s wrong and aircraft get too close together it’s the controller’s fault.  (Remember what Otter said to Flounder?…)

URET also still doesn’t work in non-radar areas (areas without radar coverage, and yes, Virginia, there are still non-radar areas in the continental U.S.).  That’s because it lacks fix posting and time information (information controllers use in a non-radar environment to keep airplanes separated), only displaying aircraft position graphically.

And the FAA knows those graphical route displays aren’t accurate enough to be used to keep airplanes safely separated.  Because of that, URET can’t be used for separating airplanes.  It’s just a tool.

In those non-radar areas the controllers have to use paper flight strips to determine where airplanes are.

It also doesn’t work very well in other situations, including the fact that with URET there was no way to indicate whether an aircraft was on a controller’s frequency or not, a problem which was highlighted after the Northwest 188 incident.

(To date, despite promises, the FAA has yet to develop a tool for controllers specifically made for that purpose.  It’s still the controllers’ problem to figure out which workaround to use to indicate an aircraft is on their frequency.)

Old flights sometimes magically reappear in the URET aircraft list.  Some flights in URET don’t probe their routes which in turn disables the conflict probe on that flight.

URET bugs have contributed to operational errors at my facilities while controllers were trying to address the problem.  It’s the same peril that any new equipment like ERAM has:  while controllers are coping with the equipment problems they go “heads down” and are distracted from keeping the airplanes apart.

It’s what happened to Eastern Airlines Flight 401 that crashed in the Everglades in 1972 when the crew was distracted by troubleshooting a problem and didn’t realize their autopilot had disengaged.

But after years of using URET, the controller workforce has become habituated to its problems and shortcomings.  They rarely file automation discrepancy reports on the URET bugs and ignore the inaccurate conflict probes.

The computer code for URET is included in ERAM so it will have the same shortcomings and problems URET already has, but has been rebranded the En Route Decision Support Tool (EDST).

The FAA’s solution to the known equipment and procedural problems like those in URET is akin to the old doctor joke:  Patient:  “Doctor, it hurts when I do this.”  Doctor:  “Then don’t do that.”

The FAA is almost always more interested in “mitigation” schemes than actually addressing the problem itself.

If a controller is distracted by his defective equipment and he fails to keep airplanes apart it’s his fault; not the fault of the faulty equipment.  The FAA tells controllers of known bugs and problems and simply says, work around them and don’t get distracted by them.  That’s because it’s a lot easier (and cheaper) than actually fixing the problem.

The FAA loves to play semantic games with controllers dealing with defective equipment and/or procedures, calling them “workload” issues and not safety issues.  However, addressing problems increases controller workload, and increased workload can lead to “task saturation”.  Once that happens a controller is no longer safely working air traffic.

Workload aside, defective equipment and procedures are a distraction nonetheless.

Now that ZLC and ZSE are running ERAM the FAA is getting close to an In Service Decision (ISD), after which they will start running ERAM on live traffic at other facilities (including mine).

They still need to test and correct the problems with the non-Hosted Terminal functionality in ERAM, and my facility will be tasked with that job.

It’s a major known shortcoming of ERAM they discovered after the FAA had already accepted it.  More issues like that are likely to follow.

Although I have no doubt that ERAM is working better than it was the last time the FAA started using on it live traffic, I’m also sure that it has a long way to go before it’s suitable for use nationwide.

But over time more and more controllers will become habituated to ERAM’s shortcomings, just like they already have with so much of the FAA’s equipment and procedures.  In turn the FAA will think everything is working fine.

I think it’s already happening.