Modernization, the FAA Way

Federal Aviation Administration (FAA) enroute air traffic controllers started using a system called ERIDS (En Route Information Display System – the FAA loves acronyms) a few years ago.  ERIDS is a computer system installed at each sector (radar position) that can access and display a variety of information controllers need while they’re working.

Unfortunately ERIDS was poorly designed and uses inferior or obsolete technology.

The idea of merging all the information controllers need into a single source is fantastic.  But ERIDS is so horribly implemented that it’s hardly an improvement over previous methods used to do the same thing.

I don’t know how ERIDS was developed; it just simply showed up at our facility one day after we had had a few computer instructional courses on how to use it.

Immediately I saw the shortcomings of not only the ERIDS interface but of the entire ERIDS system.

Prior to ERIDS controllers would access the information they needed from a variety of reference books/manuals.  Controllers access the information in ERIDS on a touch computer screen.

A lot of the information containted within ERIDs is critical to the safety of air traffic control.  The most important information it contains is approach plates (diagrams of instrument approaches for pilots that they need to land in bad weather) and Notices to Airman (NOTAMs).

NOTAMs detail safety hazards and outages at and around airports, including such things as tall towers with lights out and runway closures as well as other equipment and/or airport problems that might affect the safety of an landing aircraft.  Controllers are responsible for ensuring that aircraft get pertinent NOTAMs at their destination airport so it’s important safety-critical information.

The first significant shortcoming of ERIDS is that the display is too small without enough resolution to display some documents full screen so that they are legible.  Approach plates cannot be viewed in their entirety on the ERIDS screen at a size that is readable.

Secondly ERIDS is a single task system.  It can only display one piece of information at a time, even though controllers often need to access multiple information on different pages within ERIDS.  There is a “back” button in ERIDS that steps backwards through the history of pages displayed, but only a single page of information can be loaded into ERIDS and displayed at one time.

It is impossible for instance to switch back and forth between two different pages of information as there is no “forward” button; only a “back” button.  And once the “back” button is pressed, the previous page of information cannot be accessed directly again.

That means for instance if a controller needs to access two different approach plates for two different airports for two different aircraft landing at the same time (something that happens all the time) and easily switch back and forth between them, ERIDS is useless.

Also, there is only a single ERIDS display at each sector, even though busy sectors are worked by two or even three controllers.  That means controllers have to share the ERIDS display, swinging it around the sector on its mouting arm.  And because of its inability to display more than one page of information, any member of the sector team accessing information essentially eliminates the previous controller’s information, so the previous controller would have to look it up his information again if he needed it.

Preemptive multitasking (the ability to have the computer switch from one task to another) has been a common feature in home PCs since Windows 95 operating system (available in 1995).  But ERIDS (deployed by the FAA over 10 years later) is only a single-task system.  It’s  a glaring example of a system design that lags well behind current technology.

Theoretically a huge advantage to a amalgamated computerized information system like ERIDS woud be the ability to search the many documents contained therein for information.  But the search function in ERIDS works poorly, often displaying irrelevant results so controllers don’t use it, and is so tedious to use they usually instead choose to search the various documents manually.  This turns the computerized databases into simple electronic versions/scans of books.

Additionally the only way to type into ERIDS is with its touch screen keyboard.  But the ERIDS touch screen interface has delays built into the typing interface to prevent/false duplicate keystrokes (a common feature of touch screen keyboards), so it’s time-consuming to type anything of length into ERIDS.

Finally, intuitively one would assume that since a computer database can be easily and instantly updated that information in ERIDS would be accurate and real-time.

Unfortunately that isn’t the case.  Information such as the aircraft call sign database (all air
carriers/airlines have “call signs” and abbreviations that controllers use:  Northwest Airlines is NWA and called “Northwest” on the radios; British Airways is “BWA” and is called “Speedbird”) in ERIDS is only updated every so often, so new call signs are usually not included until the database is updated, sometimes months after the call sign is in use.

As recently noted in a local document in response to an ATSAP report, ERIDS is apparently only a “near real-time” system,  which appears to be a contradiction of the statement on the FAA’s own website:

The ERIDS provide real-time access to air traffic control information not currently available from the Host Computer System (HCS) and makes this auxiliary information readily available to controllers.

( I’m sure the FAA would play semantic games here claiming that what they meant is that ERIDS provides “real-time access” to “near real time” information.  But don’t most data systems have “real time access” and what would be the point of having real time access to non-real time data in a time critical application like air traffic control anyway?)

That means that critical time-sensitive information such as NOTAMs isn’t accurate in ERIDS.  The “workaround” fix is that controllers need to check the old style paper strip NOTAMs, a system ERIDs was supposed to replace, with the NOTAMs in ERIDS.  With ERIDS controllers now need to use two separate systems and reconcile the two.

Finally, it’s notable that an FAA report on the efficiency of ERIDS (a report that appears biased anyway as they didn’t interview the people who actually use ERIDS every day – air traffic controllers; instead only interviewing FAA supervisors) still shows that accessing information in ERIDS is not easier or faster than using paper reference materials.

Our expectation for the simulation task was that ERIDS access times would be much faster than searching for information in paper reference manuals.  It was surprising that (ZJX) partipants were generally not faster to access information using ERIDS.

So why have I gone on and on about ERIDS and its shortcomings?

It’s because the FAA is currently working on ERAM (En Route Automation Modernization), a computer system replacement for the radar displays enroute controllers use.  (Never mind the fact that the FAA is deploying ERAM despite the fact that the system is riddled with bugs and problems that are a detriment to safety.)

As it seems clear that there was little useful input from controllers during the development of ERIDS and it’s a system that could have been extremely useful and efficient had it been designed and built properly (but isn’t/wasn’t), I can only assume that ERAM, which also was built with very little controller involvement as well, will probably end up with a similar result.

Instead of being a useful tool to help controllers do their job better and more efficiently, it will probably be a system that falls far short of what it could have/should have been.

So far in our training I have seen little in ERAM that will make me do my job better or more efficiently.  If anything, there are some “features” in ERAM that I believe will do exactly the opposite (like having to make two computer entries to drop an aircraft tag leaving my sector instead of one like we do now).

Call me a visionary, but doesn’t it make sense that when designing a new system you would consult with and involve the very people who the system is being built for (the experts who know exactly what they need to do their job better)?

No wonder why the FAA has problems with modernization projects.  They routinely fail to significantly (if at all) involve the experts (its own employees) when designing new systems.

3 comments

  1. Until you non-retired guys get a contract anybody that DOES offer ideas and suggestions how to improve anything involving the effin-A-A is a traiter to the cause. They broke it, they can fix it, and demonstrate their collective ineptitude along the way.

    It’s kinda funny reading your stuff, because I can hear your voice as I read along. Not like I understand shit about the computer stuff, but the stuff concerning work is pretty good.

    Time for a bloody mary. Have a good one!

  2. In a previous life, I was one of the software engineers who designed and developed ERIDS. I am not, and never have been, an FAA employee, so I guess I can be considered something of an impartial observer.

    The ERIDS system was developed starting in 2001, installed at three ARTCCs as a prototype in 2002, and went through an iterative set of revisions based upon feedback from air traffic controllers at those centers as well as a design team made up of NATCA members. In 2005 it went through formal testing and approval by the FAA and was ultimately deployed in 2006 and 2007. Owing to the complexities of installing a system in a working air traffic control center, it takes at least two years to deploy a system throughout the 20 ARTCCs – there just isn’t enough manpower to do it any faster.

    From what others told me, ERIDS was on the fast track compared to other systems its size and complexity. Nevertheless, any information technology project that takes six years to complete, is going to be somewhat dated by the time it is fully implemented. The development cycle could have been sped up a little, but probably at the cost of a number of features. I think speeding up the process of getting new systems out is something the FAA wrestles with constantly, but making changes, even subtle ones, to the existing systems (while they are being used to keep aircraft separated) is frought with risk, and thus the tendency is to proceed cautiously.

    Access to NOTAMS is one of the features added late in the software development process. From what I recall, they are available in the system pretty much as soon as they are entered, I think by FAA personnel in Virgina.

    You’re right, the distinction between “real time” and “near real time” is semantic. IMHO ERIDS delivers information in real-time, but much of the data (for instance approach plates, acronyms, and call signs) isn’t (and really couldn’t be) updated in real-time. Most of it comes from sources outside the FAA and there is always going to be an inherent delay in distributing it. Could it be sped up ? Perhaps, but ERIDS is getting it on the same 56-day cycle that it has always been distributed.

    Early on, one of the biggest challenges was those touch screen monitors. We were told from the start that given the sheer amount of computer hardware already contained in the controller consoles, it would be unrealistic to place another keyboard or monitor anywhere. The touchscreen mounted on the adjustable arm seemed like the best compromise; we tried out larger screens, but again they were ruled out as interfering too much with the sightlines of and access to other systems already in place.

    I could go on, but what I’m trying to say is that ERIDS had the involvement of a lot of controllers (I worked closely with at least a dozen active controllers). There were a lot of constraints put upon us, mostly in the name of safety, but from what I can tell, ERIDS improved things.

  3. Thanks for the comment, ERIDS developer!

    Most of what you wrote confirmed my points about how the FAA develops its new technologies.

    I did want to address a couple of things you wrote more specifically though.

    any information technology project that takes six years to complete, is going to be somewhat dated by the time it is fully implemented.

    I think “somewhat dated” is an huge understatement. Six years time when talking about computer systems is a lifetime! (For example see Moore’s Law.)

    but from what I can tell, ERIDS improved things.

    I beg to differ. Every day I work with ERIDS I work and have to work around its inherent limitations.

    I’ll stand by what I wrote and challenge anyone who is willing to defend a poor or inferior system.

    ERIDS was a great idea that was horribly implemented. The greatest disappointment is that it could have been so much better.

    I don’t think you’re impartial either; it’s a project I’m sure you worked hard on and you would be thus hard-pressed want to concede it was poorly done. (Unless of course you don’t care about the work that you do.)

    Don’t get me wrong; I don’t blame the people that are tasked with developing systems for air traffic controllers with limited knowledge and input of what those people do.

    Most of the FAA managers overseeing those programs are in the same position; they have no idea what controllers working in the field need to do their jobs better or more efficiently.

    But don’t make excuses for the FAA taking too long to develop a system that was poorly designed and probably based upon inferior or outdated technology and concepts. (Contractors are very good at selling ignorant FAA managers those systems.)

    By the time controllers see most of those systems they’re so far along in development that significant changes are impossible. You admitted that the design input for ERIDS from controllers came after the system was already developed and installed at several facilities!

    Once the FAA commits the time and money they inevitably do developing any system for air traffic it will be used whether it’s an improvement or not.

    The long list of workarounds the FAA has created to address the shortcomings of ERIDS, not to mention the other inherent limitations of a single user/single task system for use by teams of air traffic controllers prove it’s an inferior and inadequate product.

    Don’t take it as a personal affront: I’m sure you did your best, just like most FAA employees and contractors do every day.

    But the FAA managers who have oversight of these programs don’t care whether or not they actually help controllers do their jobs better because at the end of the day it doesn’t affect them at all. They have no incentive to develop these systems the way they should.

    There were a lot of constraints put upon us, mostly in the name of safety…

    There were constraints I’m sure. I just suspect they were more related to expediency than safety.

    All these systems should have design input from the very beginning by the experts who will use them; not years after the systems are developed so that significant change is impossible.

    As long as the FAA continues to develop its systems for air traffic control largely behind controllers’ backs without their input until it’s too late, the result will always be inferior or inadequate tools that are a waste of taxpayer dollars.

    Now here comes ERAM…

Leave a Reply

Your email address will not be published. Required fields are marked *