ERAM Under the Radar

It’s been a while since my last entry, mostly because all has been pretty quiet on the En Route Automation Modernization (ERAM) front, at least at my facility (Minneapolis ARTCC or ZMP), and I’ve been otherwise occupied with other summer projects.

Sometime in April some of the centers began testing version 2 of the ERAM software, which also involved some firmware updates to hardware. We’ve gone to our backup computer system (EBUS/DARC) several times on the overnight/midshift since then to accomplish more ERAM testing in the background (as have many other facilities), but as far as I know no facility has started using ERAM to separate live traffic again yet.

Salt Lake Center is still slated to be the first enroute center to start running ERAM again on live air traffic, but with the increase in summer air traffic and given the problems with ERAM previously the FAA may have finally learned its lesson and be hesitant to roll the dice with ERAM again, at least at this time of year.

Later in May apparently in spite of the fact that ZMP is a keysite for ERAM, it was decided that our facility was not going to be part of the Initial Operational Testing and Evaluation (IOT&E) process, which gets us off the hook for any live runs with ERAM, at least for the time being.

Due to the problems with the way the FAA and the ERAM contractor (Lockheed Martin) were reporting and/or fixing bugs with the ERAM software previously, they’ve been working on changing that process.

They’re acknowledging that in the process of fixing bugs many of them would get worse, and/or they would create new bugs, so the end result was that they wouldn’t make any net progress. Of course that’s common knowledge to anyone who was paying attention at the time, but it didn’t seem to phase those in the FAA overseeing the project.

They continued to test the faulty software on the flying public until word of how poorly the project was progressing got out, eventually including a report and recommendations from the Department of Transportation Inspector General.

Right now it sounds like they’re trying to optimize the Problem Reporting (PR) system for ERAM and how they determine whether or not ERAM is suited for use on live traffic.

Previously the FAA and the ERAM contractor, Lockheed Martin, weren’t too concerned with either, and although they should have had reasonable error reporting, correction and assessment processes in place when they started the ERAM project they obviously didn’t. All of them should have existed well before they started testing the system on the flying public regardless.

At some point the FAA is going to start testing ERAM on live air traffic again. Hopefully when they do so ERAM will be in a state more suited for the task than it was the last time the FAA tried using it for that.

In the meantime ERAM development continues quietly “under the radar” so to speak…

2 comments

It’s easy for system architects to see signs of a sick project in ERAM, and the urge is to say “can it,” like the failed AAS that was finally canned in 1994. At about $2 billion (2010 dollars) ERAM has eaten up a lot less than AAS did, at $3.7 billion (1994 dollars).

That would be a tough call for users, who really need improvements to a creaky system designed nearly 40 years ago. One thing users might help with is an absolute cap on new requirements. Requirements on this project should have been frozen 6-7 years ago, but apparently they are still changing.

Freezing requirements is what makes it possible for a project to work. Requirements creep, as architects call it, undermines a project, raising the cost and vastly increasing the likelihood of collapse.

You can’t expect Lockheed to fight requirements creep; they make profit on it. They should never have gotten the contract. AAS was built by IBM Federal Systems. By early 1990s FedSys was a money loser, and IBM threw in the towel, selling to Loral, who sold to Lockheed. The same organization that failed at AAS is now building ERAM.