In the event people are visiting to see more updates on En Route Automation Modernization (ERAM), I’ll try and make this short.
ERAM, the replacement computer/display system for enroute center controllers, is still experiencing problems and the FAA continues to use it on live air traffic. In other words, not much has changed.
The most critical ERAM bugs that I’m aware of (outside of outright display failures/lockups – big red “X”s) involve data block/tracking issues, some of which haven’t been corrected even though they’ve been known of for some time. The absolute worst tracking bug is when a data block drops off a target and the accompanying flight plan is simultaneously deleted. Other critical tracking bugs involve data blocks tracking on the wrong target.
One thing that has changed since I last wrote about ERAM is that I’ve since had the “opportunity” to work with it on live traffic. Needless to say the experience didn’t change my opinion about the program.
We were told in advance to not “experiment” with ERAM while using it (presumably because of the myriad problems we might encounter). Apparently it’s true that we’re really not testing the software any more right now; we’re just using it, while trying to not use it so much that we break it. (Maybe at this juncture the FAA figures there are enough known bugs already and they don’t want to find more.)
Many of those involved with the ERAM project continue to believe and/or give outward appearances that things are going fine in spite of the persistent problems. In fact, controllers are hearing less and less of the bugs in the software as time goes by, which has the added effect of making it appear that things are going better than they really are.
I guess it’s the old, “No news is good news” theory…
During the Initial Operational Capability (IOC) or first run on live traffic at Minneapolis Center (ZMP) they provided controllers with a list of known major bugs in ERAM, but they’re now no longer providing that information before live runs. (Perhaps the list is too long…) Either way it’s obvious that the FAA doesn’t think controllers need to know about the deficiencies of the system they’re supposed to use to keep airplanes separated (or doesn’t want to advertise them anyway).
ZMP had two operational runs with ERAM the first week of March and not surprisingly we experienced some repeats of some of the most significant ERAM bugs.
Mind you, most of the bugs we experienced weren’t new bugs; they were existing bugs they already knew about.
Instead of fixing the known bugs before running ERAM on more live traffic, the FAA continues to run software they know is faulty more often.
“Idealists” like me would like to believe that the FAA and Lockheed Martin would want to fix those known bugs once they were discovered before running the same versions on more live traffic.
But that’s not how the ERAM program is progressing at all. That’s because the FAA and Lockheed Martin have agendas that don’t prioritize the safety of the flying public.
First, fixing all the bugs before running it more would take more time and cause the program to fall further behind schedule.
Another reason the FAA is now running software builds with known bugs on live traffic at the various key sites is to avoid refresher training for controllers as per the Memorandum of Understanding (MOU) between the FAA and the air traffic controllers’ union, NATCA.
The MOU says that:
“Basic and supplemental ERAM training shall be provided to all BUEs prior to implementation of ERAM at each facility. If more than forty-five (45) days elapses between the time BUEs complete ERAM training and the actual implementation of ERAM at the facility, ERAM refresher training shall be provided prior to implementation.”
Apparently IOC equates to “implementation” in the MOU (although I don’t see that definition in the MOU).
So there you have it: the FAA is now rushing ERAM into use at least in part so that it doesn’t have to re-train its controller workforce per the MOU.
Now that the Winter Olympics are over, Seattle Center (ZSE) is now also back in the ERAM game as a key site again. ZSE just ran an extended live run less than a week ago that predictably also had its share of problems, simply because they were running the same software build everyone knew had existing bugs.
In spite of all the problems, the FAA continues to press towards an In Service Decision (ISD) after which the non-key sites (the rest of the enroute centers) can move towards their own IOCs, in spite of the fact that the longest period any of the key sites have run ERAM is for 8 days (and that under very controlled conditions).
So we’ve established that the FAA isn’t fixing significant/critical known bugs before running the ERAM software more often. They’re telling controllers to tip-toe around ERAM while using it to create the illusion that things are going well, in spite of the many known bugs. They’re withholding more and more information as time goes by and the project continues to go badly.
It’s obvious that the FAA is sticking with their approach that prioritizes the deployment schedule (which for the record continues to slip further and further behind), saving money on training, and pretty much anything else, over safety.
It’s just business as usual for the FAA…