The FAA is finally taking a break from its thoughtless, irresponsible and reckless pursuit of testing its next generation enroute air traffic control display software on the flying public.
Within the last few days, apparently the FAA has decided to stop running the new software on live traffic and make an “assessment” of the program, although certainly not by its own accord.
Since last year, the FAA has been routinely running its En Route Automation Modernization (ERAM software), still under development, on live traffic, with many known critical bugs at three key sites, including including Salt Lake Center (ZLC), Seattle Center (ZSE), and Minneapolis Center (ZMP).
In spite of the fact that the FAA and the program contractor, Lockheed Martin, knew of many significant bugs with the software, the FAA opted to run the software nonetheless, often playing down the seriousness of the problems.
New versions of software addressed a few of the significant bugs while at the same time ignoring most of them. That fact didn’t prevent the FAA from trying the latest versions on live air traffic anyway.
And predictably, the bugs that hadn’t been fixed in the latest software versions inevitably cropped up again, in some cases leading to a shutdown of the ERAM software with a fallback to the legacy HOST software.
What was the FAA’s primary motive for testing software that they knew had significant bugs? Apparently in part to meet timelines and deadlines for the software deployment which is falling further behind schedule, as well as ensuring that the program’s contractor, Lockheed Martin, gets cash bonuses built into the contract.
Under pressure from the controller’s union, NATCA, who started telling congressmen and senators about the problems with ERAM, and those controllers helping work on the project, some of whom were becoming increasingly frustrated by the lack of progress in correcting significant known bugs with the software, (and this writer would like to believe some other negative publicity) the FAA eventually agreed to stop running it on live air traffic for the time being and instead make an assessment of the program.
The FAA knew that the more opposition grew to the program the harder it was going to be to “fly under the radar” and continue with its reckless approach. Many of the critical problems they have had with ERAM weren’t corrected in spite of numerous software updates, negating the FAA’s claim that the program was progressing satisfactorily.
A large part of the problem was that the ERAM software clearly wasn’t developed to the point of being ready for use to separate live air traffic when the FAA started using it for exactly that. Even if all the critical known bugs were magically fixed today, ERAM still probably wouldn’t be ready for use with real air traffic, but it certainly would be a lot more suitable for that task than it currently is.
I have no doubt that the FAA would have continued with its “damn the torpedoes” approach were it not for increasing opposition from the controller workforce and its union.
Unfortunately for the FAA, the more controllers that were exposed to running the ERAM program, the more visibility the problems got, none of which were going away.
That sorry state of the software was only going to lead to bad publicity that the FAA didn’t want.
It was months too late for the FAA to stop the current course of the entire ERAM program deployment, and I have no doubt that the FAA would never have stopped to make an assessment of the ERAM program on its own. After all, they seemed to think everything was going fine.
The state of development for the entire ERAM program is obviously well behind where it should be, and although lots of others recognized that fact, as an organization the FAA was either in denial or oblivious. Considering what happened with the Initial Sector Suite System (ISSS) program decades ago, it’s obvious the FAA has learned nothing over the years (or has simply forgotten).
The only acceptable and responsible course of action now is for the FAA to force Lockheed Martin to correct all the known critical bugs before the ERAM software is accepted for further use in separating live air traffic.
Anything short of that will inevitably put us right back where we started, and likely back into the same dangerous and faulty cycle.
However, knowing the FAA I believe that this assessment will likely result in a decision which will amount to merely “trying to do better”, rather than a real commitment to fix the known problems before further using the flying public as beta testers/guinea pigs for the ERAM software.
That’s because the FAA has already demonstrated that it’s willing to run faulty software because they’re more concerned about the ERAM deployment schedule than anything else.
They’re panicking because the clock is ticking. The HOST software contract has already been extended. The ERAM program schedule continues to slip. Failing to hold Lockheed Martin to a higher standard isn’t going to make the ERAM problems go away, but is conducive to staying (more) on schedule, in spite of the fact that it puts the flying public at risk.
The FAA has always assumed (and will continue to assume) that air traffic controllers will be able to work around ERAM’s deficiencies and keep airplanes separated nonetheless.
Keep in mind that none of this precludes the FAA from continuing to run/test the ERAM software; it merely won’t be used on live traffic for the time being at the key sites.
Testing of ERAM in the background will continue, and will likely reduce the margins of safety and increase controller workload by forcing them to work live traffic on its outdated DARC/EBUS backup computers without flight plan processing so that ERAM can use the interfaces between the various facility computer systems.
But unlike ERAM, at least the DARC/EBUS software properly tracks radar targets…