The Federal Aviation Administration’s (FAA) En Route Automation Modernization (ERAM) development continues, slowly but surely.
The entire ERAM program was a disaster that the FAA had been in denial about for years. In 2009 they were proclaiming the program on time and on budget.
When they started trying to use ERAM at Salt Lake Center (ZLC) they found it was unstable and bug ridden. But they had no way to test it other than on live air traffic. So they did.
Because timelines were clearly more important to the FAA than safety, in spite of all the problems they went ahead with their plans to deploy ERAM at other facilities (including mine – Minneapolis Center or ZMP).
However, in the spring of 2010, it finally came to light how bad ERAM really was, and for a few months the FAA took a break from live testing of the system to work on fixing its many problems. Then a few months later they started running it again on live traffic at its two keysites, Salt Lake Center (ZLC) and Seattle Center (ZSE).
But after continued testing and development, by spring of 2011, according to an Independent Operational Assessment (IOA), the system still wasn’t ready for further deployment. The controllers’ union (NATCA) agreed with that assessment.
What was the FAA’s response to that critical assessment? – declare an In Service Decision (ISD) which meant it could be deployed at other facilities.
Some time ago I believed NATCA was setting itself up to be a fall guy/patsy for the failures of ERAM. But when the FAA finally asked NATCA for real collaboration with the ERAM program the final nail was put in the coffin.
The instant the FAA asked NATCA to collaborate on ERAM, NATCA was placed in a lose/lose situation – they couldn’t claim to be a critical part of the National Airspace System (NAS) and yet not get involved with ERAM when the FAA conceded they needed help from its controller workforce.
But apparently NATCA also saw the program as an opportunity to be used for political gain. NATCA believed they could step in and save ERAM, and thereby show how incompetent the FAA was and how smart they were. Unfortunately they didn’t consider how messed up the ERAM program was.
When NATCA got the opportunity to become partners with the lemons that were ERAM, they decided to make lemonade.
However, that immediately turned NATCA’s involvement with ERAM into a conflict of interest. They suddenly needed ERAM to succeed as much as the FAA did. It was no longer about safety, but politics.
Today neither the FAA nor NATCA is willing to openly admit how much development ERAM still needs, as both have underlying political motives at heart; neither considers the controllers who have to work with it nor the overall safety of the air traffic system.
Case in point, for some time both Salt Lake Center (ZLC) and Seattle Center (ZSE) have been running versions of ERAM neither the FAA nor NATCA is will to run full time at other facilities because of all the known bugs (the known bug count is somewhere around 1000!).
But nonetheless, last month my facility ran the same version of ERAM on live air traffic two separate times for a total of 3 days. But it was only on the weekend, and apparently people who fly on airplanes through ZMP’s airspace on the weekend don’t really count…
Don’t get me wrong – ERAM has made a lot of progress since the FAA last tried running it on live air traffic back in 2009. But any air traffic computer system that has over 1000 known bugs isn’t fit for use on live air traffic. If there are that many known bugs, one can only speculate as to the number of latent (unknown) bugs still in the software.
I’ve been accused of being an ERAM “hater” because of my views on it from the management side of the FAA, and more recently from the air traffic controllers’ union (NATCA) side.
As is typical of people wanting to avoid addressing facts, that’s a gross oversimplification that ignores my complaints and concerns about ERAM.
The truth is that I’m not opposed to ERAM. What I object to, and have always objected to, is the way the ERAM program has progressed from its very inception. It’s another one of the FAA’s many repeated examples of how not to upgrade a system that’s critical to how air traffic controllers do their jobs.
ERAM is an overly ambitious program, the likes of which the FAA has historically proved unable to successfully manage. As proof consider the disastrous Advanced Automation System (AAS) including the Initial Sector Suite System (ISSS) in the 1980-90s and the problems with the Standard Terminal Automation Replacement System (STARS) program of late 1990’s/early 2000s.
Obviously the FAA thinks more of its ability as an organization to successfully manage these major programs than they’ve repeatedly demonstrated the ability (or lack thereof) in the past.
I take my job, and its inherent safety critical aspects very seriously.
When the FAA first started running ERAM on live traffic by any standard it was alpha software. It was unsafe and shouldn’t have been used on live air traffic, a fact that was eventually conceded, but not before it was used for many hours on the unsuspecting flying public.
Since then it has been improved, but the last time my facility ran ERAM (last month) the version of the software we ran had over 1000 known bugs. By any reasonable standard it still can only be considered beta software.
ERAM was put into use well before it was ready, forcing air traffic controllers into the unfortunate position of working with and around its many shortcomings and problems. Today that situation still exists.
Since air traffic uses many analogies with pilots, because of its current state controllers have been forced to act as “test pilots” with ERAM. Test pilots volunteer for that duty, but controllers haven’t been given a choice to “test fly” ERAM.
Most pilots wouldn’t be comfortable flying an aircraft they didn’t think was airworthy. But pilots are given the final authority as to whether or not to fly their aircraft. Controllers on the other hand don’t have that choice, and many have very little confidence in the “airworthiness” of ERAM.
At the very least, no test pilot would put passengers in aircraft they were testing, but that’s exactly what the FAA has been doing with ERAM.
The software wasn’t tested adequately before acceptance and there was no way to fully test the software other than on live air traffic. The fact that testing could only be performed on live air traffic was itself a fundamental design flaw of ERAM.
Additionally the design of ERAM clearly didn’t consider the things controllers need to do their jobs more safely and efficiently. As I don’t know what tools the technicians use to keep that system running, I can only assume the same is true for the tools ERAM gives them.
What I do know is that whatever analysis (if any) was put into the examination of how controllers work and what tools would help them do their jobs better is absent from ERAM’s design.
One of the long-running FAA managers’ catchphrases for those criticising their system “upgrades” is that controllers are resistant to change.
While that’s true (controllers don’t want to re-learn how to do their jobs), it’s also true that I would love (like most other controllers) to have tools to enable me to do my job better.
Instead most often what we get are tools that make parts of our jobs more difficult. Parts of ERAM actually make routine parts of controllers’ jobs more tedious.
Most notably, with ERAM, dropping a data tag on an aircraft that a controller is no longer required to monitor is a two step process instead of the current single step process.
Because attention to detail is important in air traffic control, distractions of any form are undesirable for controllers working air traffic. However, ERAM has many ways that it creates distractions for controllers.
Bugs in ERAM are a distraction. Wondering if and when ERAM will crash is a distraction.
But a new “feature” in ERAM also creates distractions for controllers.
Air traffic control is highly compartmentalized. Controllers are delegated a specific section of airspace they are responsible for keeping airplanes moving safely and efficiently in.
There are numerous rules to make sure that the responsibility for keeping aircraft separated in a section of airspace falls on a single controller to avoid confusion. Controllers cannot let aircraft enter another’s airspace without permission, and can only give control instructions to aircraft in their airspace.
However, for contingent safety reasons should they notice, controllers are also responsible for pointing out problems they see in adjacent sections of airspace. But under the current HOST system though there are few ways for a controller to see or know for sure what is occurring in adjacent airspace.
Thus, in general controllers work their own airspace, separate their own traffic and assume the controllers working adjacent airspace are doing the same; a prudent and reasonable expectation.
But instead of adding tools to ERAM to help controllers better work their own airspace, ERAM added the “feature” of AOI (Area of Interest), expanding the areas in which controllers would be alerted to problems outside their airspace, adding more responsibility for controllers to monitor their “neighbor’s” airspace as well as their own. The claim is that the AOI will help controllers work more efficiently near their sector boundaries, but because of the way the air traffic rules are written it also expands their responsibility outside their sector.
Although to a casual observer it might make sense to have more eyes watching traffic, it starts to blur the lines of compartmentalized responsibility that is one of the cornerstones of air traffic control. The end effect is that the ERAM AOI has the potential to distract controllers from monitoring traffic within their own sector.
That’s not to mention the various known bugs, little glitches and quirks of ERAM that will be around for some time to come. The expectation clearly is that controllers will get used to them and work around them. They’re distractions nonetheless, and those distractions are detrimental to safety.
It was clear that the FAA has always driven more by timelines and budget than safety when it came to ERAM deployment, but now the controllers’ union has political motives as well with regards to ERAM, so they’re both willing to roll the dice and run ERAM on live traffic even though they know it’s not ready.
If ERAM is ready for use on live traffic, then why doesn’t the FAA and NATCA just use it at all the facilities 24/7?
The answer is obvious: because they know it’s not ready.
But they’re running it at more and more facilities nonetheless.
You can’t have your cake and eat it too.
If both the FAA and NATCA are willing to run ERAM full time at some facilities and part-time at others, how can they argue it’s not safe to use? Air traffic and the people on the aircraft flying at facilities with less traffic, and at busier facilities on the overnight shifts and on the weekends are no less important than those flying elsewhere and at other times.
If it’s “safe enough” (i.e. “close enough for government work”) then I say just turn it on and let the chips fall where they may. Otherwise we still shouldn’t be running it on live traffic.