In Search of the Future of Air Traffic Control

Note: Because aviators worldwide specify altitude and separation requirements in nautical miles and feet, those units have been retained in this article rather than converted to their metric equivalents, as is IEEE Spectrum's policy.

By the year 2015, if the U.S. air transportation system does not change in any significant way, there could be a major aviation accident every seven to 10 days.

This projection, reported by Neil Planzer, director of Air Traffic System Requirements Service for the Federal Aviation Administration (FAA), Washington, D.C., is based on the anticipated growth of air traffic, combined with an accident rate that has been statistically flat for the past 15 years and, without much effort, is expected to remain at that level [ Fig. 1]. Planzer made the projection in May at the "Communicating for Safety" Conference in Chandler, Ariz.

Because weekly accidents are well beyond what a traveling public is willing to tolerate; and because the current air traffic control system [see "Air traffic control upgrades around the world "], on which the safety of air travel depends, has been rapidly losing reliability due to aging equipment and accompanying maintenance problems; and because air traffic-controlled­caused delays cost the airline industry an estimated US $5.5 billion annually, the FAA has for the past two decades been scrambling to replace, modernize, and improve it.

So far, success has been minimal.

Watching today's skies

The U.S. air traffic control system is organized around three types of facilities [ Fig. 2] and a bevy of acronyms: airport towers, which monitor aircraft on the ground and give take-off and landing clearances; terminal radar approach control (Tracon) facilities, which handle aircraft ascending and descending to and from airports; and en route centers, which handle aircraft flyingbetween airports at the higher altitudes.

Defining Terms

Signals from the radar that scans the skies for aircraft are processed at the Tracons and the en route centers, where controller displays and the computers that feed them information form the heart of the air traffic control system. At the Tracons, the computer system used is the automated radar terminal system (ARTS), and its displays are data entry and display subsystems (DEDSs) at most facilities or the newer full digital ARTS displays (FDADs). At the en routecenters, the computers, called the Hosts, send information to the computer display channels or display channel complex rehosts, which are other large computers that drive plan view displays (PVDs).

Both the PVDs and the DEDSs are 1960s-designed displays. The FDAD, in use at some of the busiest Tracons, is a '80s' microprocessor-based system. All these displays look basically the same--a round tube of about 0.56 meter in diameter, with a dark background and green text [ Fig. 3, top]. The PVDs and DEDs (but not the newer FDADs) confront the same reliability problems.

Much of this equipment had been expected to be on a scrap heap by now. The PVDs installed by Raytheon Co., Lexington, Mass., in the early '70s had an anticipated lifetime of 10­15 years; those in the centers today are now at least 10 years past this estimate.

These displays fail regularly--according to controllers and technicians. At each en routecenter, which may have 30 to 60 PVDs in operation, it is not unusual to replacetwo to four of these units a day. When a PVD goes dark, the controller at that station rushes to another screen and urges the controller there to alter his or her display to include aircraft previously tracked on the failed display.

PVDs slipping out of adjustment also cause the size and clarity of the alphanumeric type they display to vary--fuzzy type makes controllers confuse 3s and 8s, which can lead to errors, an Indianapolis controller told IEEE Spectrum. And the units themselvesare unstable. Their aging ceramic connectors are brittle and falling apart. Insulation on the wires is brittle, too. The vibration caused in moving a display, as is necessary when a replacement must be brought in, often disables it when fragile connections are broken.

Meanwhile, the Host and ARTS computers that drive the displays are problematically obsolete as well. The Host computer computes radar tracks, maintains a database of flight plans, and issues safety warnings--such as aconflict alert, when two craft are in danger of violating separation standards, and aminimum safe altitude warning, when an aircraft is at risk of hitting terrain. It contains half a million lines of Jovial code and assembly language that was first installed in 1972 and ported from IBM 9020 onto IBM 3083 computers, starting in 1985.

But Host has at most only 16MB of RAM, a serious limitation. And it badly needs replacing. (The ARTS computers in the Tracons are also severely limited in memory, but those are scheduled for replacement.) "The Host software is our biggest problem," a controller from Chicago told Spectrum . "There are so many patches, no one knows how it works. We can't change anything; no one dares touch it, because if we break it, we're gone."

In the mid-'80s, a multibillion dollar effort was started to update both the en route centers and the Tracons by replacing their displays and computers with networked workstations. (Airport towers use feeds from Tracon computers for radar tracking of airborne craft; they use separate surface-monitoring equipment for aircraft on the pavement.)That 10-year effort failed and has, for the most part, been abandoned. Called the Advanced Automation System, the program was sunk by unrealistic specifications and human factors difficulties, among other problems. New efforts to help controllers and pilots are under way, but have yet to make an impact on the present system.

As to what the main features of an air traffic control system for the '90s should be, system developers, controllers, and some FAA officials are agreed. It should have controller workstations with high-resolution bit-mapped displays that can distinguish information by color. It should not drop planes and vital traffic control information from displays (as happens today when computer capacity is exceeded). And it should not go dark on a regular basis. What's more, it should be based on commercial off-the-shelf (COTS) hardware, making it upgradable and expandable, so that when controller tools intended to increase safety and efficiency, presently in the prototype stage, are completed, they can easily be ported to this new system--a transfer that is out of the question with current hardware.

This system is still merely a dream for most of the 14 500 U.S. controllers employed at the more than 200 en route centers and Tracons. But at one, just one, FAA control facility, it is a reality.

The future--today

Welcome to High Desert Tracon, one of the 185 civilian terminal radar approach control facilities under the aegis of the FAA in the U.S. air traffic control system. Unlike most air traffic control facilities, the main control room here, on Edwards Air Force Base in California, does not look like a relic from an old war movie. It resembles instead the flight deck of the Starship Enterprise [ , middle].

At every controller workstation is a high-resolution 2048-by-2048-pixel Sony 20-inch color monitor [ ]. Colored text distinguishes the planes being handled by the controller at that workstation (cyan) from planes in the area being handled by other controllers (green), and identifies hand-offs, which are transfers of responsibility from one controller to another (white), and emergencies (red). The workstation allows controllers to bring up maps directly on the display from a large and expandable database, or to draw their own.

Controllers can also use touch panels on the right and left of the display as function keys to facilitate theirtraining.

But probably the most important feature to the controllers is that, unlike the PVDs and DEDs, these graphics display processors (GDPs) do not go blackbecause of frequent internal failures or problems with the computers that process radar information. Data collected from 10 radars sited to monitor the Tracon's vast airspace is fed to a bank of 30 networked workstationsbuilt by Sun Microsystems Inc., Mountain View, Calif. If one of the Sun workstations fails, the system may degrade as the other units are stressed, but it does not go down.

The road from the PVDs previously in use at High Desert Tracon to the graphics display processors of today was, compared to most air traffic control system upgrades, a smooth and short one, thanks to the air traffic control facility's unique position as a joint civil and military responsibility.

Although identified as a terminal radar approach control facility, High Desert Tracon is somewhat of a hybrid, having some characteristics of an en route center. It covers a far greater airspace than typical Tracons, with 25 000 square miles, in contrast with less than 1000 square miles.

In addition to handling approaches and departures for five airports--Palmdale, William J. Fox, andSouthern California International, along with Edwards Air Force Base and the Navy's China Lake facility--it acts like an en route center by directing civilian traffic passing through its airspace, routing it if necessary around restricted airspace reserved for the Department of Defense. It also coordinates closely with military air traffic control facilities nearby, passing airspace into Navy and Air Force control when necessary for military maneuvers and taking it back when those operations are completed.

High Desert Tracon also used a different radar information processor. Other Tracon facilities in the United States today use ARTS, resolving targets and feeding the resulting radar data and some flight information to the displays. But the original ARTS systems were configured to accept only one radar feed. (ARTS is a special-purpose Sperry computer manufactured in the '70s; later versions can accept multiple radars.)

Since High Desert Tracon's extensive airspace has long required multiple radars, the facility back in 1981 was assigned a Mosaic direct access radar channel (M-DARC) computer as a radar processor. Similar DARC computers, produced by Raytheon in the late '70s, are used at en route centers as a backup for the main Host computers at the centers. DARC can handle multiple radars, but it is purposely limited in order to be effectively "bullet-proof" and able to always work in an emergency--it lacks the conflict alert and minimum safe altitude warning functions and is unable to manage automated hand-offs.Until recently, High Desert Tracon simply did without those controller tools.

Tracking military activity

While High Desert Tracon was experiencing problems similar to those of other air traffic control facilities--failing PVDs and a central computer at its maximum (adding a new feature meant deleting an old one)--it had one additional problem not faced by the others. The DARC system was simply not capable of accurately tracking the high-performance military aircraft whizzing through High Desert Tracon's airspace.

Since this last failing was, in essence, a Department of Defense (DOD) problem, even though one faced by a civilian facility, High Desert Tracon in 1988 turned to the department for a solution. In 1989 the Tracon was granted funding for a conceptual design and functional specification, said Robert Cox, a technical consultant to the DOD, who was assigned to High Desert Tracon from Computer Sciences Corp., in Falls Church, Va. Full funding for the basic system was granted in 1991, and the actual design effort began in September of that year, with BDM Air Safety Management Corp., a unit of BDM International Inc., McLean, Va., chosen as the contractor. The project was tagged "Rehost."

The development process turned out to be a textbook case of how to design an air traffic control system for the '90s. According to a recent publication bythe National Transportation Safety Board, "The ingenuity associated with development of the High Desert Tracon system deserves consideration as a model for future air traffic development and procurement programs."

"They did it right," said Steven Zaidman to Spectrum . "They involved controllers at every stage." Zaidman is director of systems architecture and investment analysis for the FAA.

Explained Phillip Stange, airway facilities manager for Edwards Air Force Base: "We did not go to a vendor and buy hardware, as the FAA does. We wanted to get the software done, and then figure out what to run it on." (The decision to use Unix workstations was made early on.)

The baseline system cost $10.8 million; the second software release, an additional $1.7 million; and the third software release, now being implemented,$2.3 million more. These figures include the cost of all hardware, software development, documentation, testing, and training for High Desert Tracon and for two military control facilities on Edwards Air Force Base.

At the start, the Western/Pacific Region of the FAA and the Department of Defense immediately established a product team that included representatives from the controller workforce, the FAA and DOD maintenance workforce, and Tracon and DOD management. The team started prototyping systems and testing the interface on controllers assigned to the facilities.

The input from these people led to the addition of touch screens to accelerate training and thus smooth out the transition from old to new systems. Their recommendations also resulted in a forgiving system for entering flight plan information (previous systems would reject information--like the call sign of an aircraft, itsassigned altitude, or aircraft type--if controllers failed to key it in according to a predetermined order) and the color switch to cyan from a darker blue that was used initiallyfor crucial aircraft information (the darker blue proved to cause eye strain).

Because controllers were involved in the design process throughout, acceptance when the system was complete was immediate. "We told the workforce," Stange said, "that if they wanted something upside down and purple, we'd give it a try."

Input from controllers continues today. Their suggestions are collected in a binder available to all, commented on, and then discussed by the Rehost configuration management board, representing facility management. Changes agreed upon are passed on to software developer BDM and to local system specialists, FAA employees who handle software maintenancefor inclusion in a future software release. (Air traffic control software at other FAA facilities may be changed only in minor ways, if at all; faced with massive, complex code written in ancient languages, some systems specialists are fearful that significant changes would bring the entire system down.)

From Host to Rehost and Ollie

One of BDM's key contributions, according to Robin Deyoe, BDM vice president, was a high-speed aircraft tracker design, adapted from a radar tracker that BDM had created for a classified Department of Defense program. Current FAA radar processors use a single radar chosen from a predefined set of radars to monitor each aircraft. Each of these radars updates itselfapproximately every 6 seconds in the Tracon environment, 12 seconds in the en route center environment.

The BDM system takes information from multiple radars updating at different times, each with varying inaccuracies, and uses a Kalman filter algorithm to combine varied radar inputs to distinguish the true position of the aircraft. (A Kalman filter is a method for providing an optimal estimate of variables in the presence of noise by generating recursion formulas.)

The resulting software, called Rehost, is written in C. The first version's capabilities were equal to, or better than, those in standard FAA systems, and followed defined protocols for information transfer between FAA facilities. It was certified by the FAA in 1993. Currently, the third major software upgrade of Rehost is being mounted.

The switch to commercial off-the-shelf equipment required a sea change in the way acquisitions are conducted, Spectrum was told by High Desert Tracon's Stange. Instead of procuring a huge computer, installing it, and leaving it in place for 20 years, purchasing off-the-shelf equipment required constantly upgrading it--manufacturers cannot be expected to support any one piece of hardware for more than five years.

"If you were going to install hundreds of these, from coast to coast, it'd take three to four years," said Brent Shively, air traffic manager for High Desert Tracon. "And as soon as you were done, you would have to go back to the beginning and start upgrading immediately." High Desert Tracon is now upgrading its Sun MicrosystemsSparc 470 workstations to Sparc 1000s.

While High Desert Tracon's Rehost has indeed proved to be successful, it is not the only modern air traffic control system in existence in the United States. There is also Ollie.

Ollie, Spectrum has learned, is a PC-based air traffic control display, developed secretly by engineers at the FAA's Atlantic City, N.J., technical center. Like Rehost, it uses a Sony 20-inch color monitor, and is reportedly a drop-in replacement for displays at facilities that use the ARTS-IIIe computer (the top-of-the-line ARTS system). It is called Ollie after Oliver North, because it is kept in back rooms and is not expected to see the light of day. Said James Allerdice, National Safety Commit tee chairman of the National Air Traffic Controllers Association (Natca): "[Ollie] is fieldable and attainable now, but it is politically incorrect."

There is also a PC-based controller workstation in operation at Washington National Airport, installed to improve surveillance of the sky over the White House after the crash on the south lawn of a Cessna 150 private aircraft in September 1994. "This screen doesn't fail," unlike the displays used in the rest of the facility, one of the Washington National controllers told Spectrum . "We've heard the FAA has more of these systems in storage. We tried to get them, but they said no." The FAA's Planzer responds that this system is monitoring airspace that is only several acres in size. "To extend that to say it could be used to control 1000 square miles is a quantum leap," he said.

None of these solutions may be right for all U.S. control facilities. Rehost's users stress that it is a site-specific solution, and would certainly require adaptation to other sites if rolled out on a system-wide level. "This is not a complete system," Shively said. "It is an evolving system. It is not an answer to everything, but it is not a bad start."

Meanwhile, replacements for the displays at the other U.S. control facilities are planned. They are of two types. One is the display system replacement (DSR) being developed by Lockheed Martin Corp., Bethesda, Md., for en route facilities. This system will replace the dumb PVDs with smart workstations but will leave the radar processing computers untouched. The other is the standard terminal automation replacement system (Stars) for terminal radar approach controlfacilities, being developed by Raytheon. Stars will replace both the displays and the radar processors with a distributed computing system.

Whether these systems will be as good or better than Rehost or Ollie is subject to debate. Both arose from the dismantling of the Advanced Automation System program, a more-than-10-year effort that was restructured by former FAA administrator David R. Hinson.

Montage of mistakes

The Advanced Automation System was an ambitious effort to replace the aging controller workstations, display processors, and Host computers--and greatly increase their functionality. Included in the plan was a phase-out of the ARTS systems because the Tracons were to be consolidated with the en route centers. The consolidation idea was later dropped.

A design competition started the program off in 1984. The contract, initially for $2.5 billion,was awarded to IBM Corp.'s Federal Systems Divisionin 1988, with the expectation that the first group of workstations would be installed in Seattle, Wash., in 1992.

Almost immediately, though, the schedule began slipping. By the end of 1992, well over $1 billion had been spent, and still the project, with some 1000 software engineers working on it, was in no way near completion. Moreover, the project was by then under the stewardship of Loral Space and Communications Ltd., New York City, which had purchased theIBM division.

At that point, only a limited number of workstations could work together simultaneously, and even then the system would continue running for only a few hours at a time, said David Spencer, a senior staff member at the Lincoln Laboratory at the Massachusetts Institute of Technology, in Lexington. Estimated costs for completion soon climbed to $7.6 billion.

In 1994, Hinson, the FAA adminstrator at that time, canceled most of the program.

What to blame for the debacle? Unrealistic specificationsset by the FAA, for one. IBM was charged with giving at least minimal system functions a 99.99999 percent availability--3 seconds of downtime a year. The requirement was justified because of the planned consolidation of some 200 Tracons into the 20 en route centers, which would increase the impact of system failures. But the reliability numbers were retained even when the consolidation plan was dropped, Spencer said.

Another requirement, that flight strip data be integrated into the system on the display screen, proved to be a human factors nightmare. Flight strips contain printed information about flight origins, destinations, and clearances, and are currently stacked in racks next to the displays, serving as a physical reminder of aircraft status. Controllers scrawl new information on them and consider them the backup of last resort, if all automated systems fail [ Fig. 5].

Reproducing these flight strips on a computer screen without burdening the humancontroller with excessive keystrokes for data entry turned out to be impossible. As implemented in the integrated sector suite system, the display component of the Advanced Automation System,the flight strips had numerous fields, separating information for interpretation by the computer. Because the fields had each to be so small to fit the required number on the display, it was difficult to quickly position the cursor correctly for data entry.

In addition, Spencer pointed out, a 20-inch screen is smaller than the metal rack used todayto hold paper flight strips, and therefore when a lot of aircraft were being handled by one controller, not all electronic strips could be displayed simultaneously. (Eurocontrol, the 22-member agency working to standardize air traffic control operations in Europe, has recently launched a long-term research project at its experimental center in Brétigny-sur-Orge, France, to determine alternative ways of electronically portraying flight data, without simulating paper strips.)

A combination of problems caused the Advanced Automation System to be delayed and eventually canceled, believes Martin Pozesky, who was associate administrator for system engineering and development at the FAA until the mid-'90s and these days is an aviation consultant in Potomac, Md. He puts the blame on human factors problems.

(Not surprisingly, there are a number of human factors issues that must be dealt with in creating an air traffic control workstation. The setup must be such that the controller's eyes rarely have to wander away from the screen, while the number of keystrokes needed for any function must be kept low. Also, aircraft status--under the controller's jurisdiction, not under the controller's jurisdiction, experiencing an emergency, and so on--must be easily distinguishable.)

Pozesky also targets early architectural problems and networking problems--all of which caused huge parts of the project to have to be rewritten. "Neither the government nor IBM did enough development work before they awarded production contracts with large numbers of people charging to the program," Pozesky told Spectrum . "At one point, they [IBM] had 1500 people on the program. And eventually, everything had to be redone. Some of the problems--like the electronic flight strip problem--were never solved."

A 1994 analysis done by the General Accounting Office blamed the failure on the fact that the "FAA did not recognize the technical complexity of the effort, realistically estimate the resources required, adequately oversee its contractors' activities, or effectively control system requirements."

Spectrum has heard reports of hardware problems as well. "We expected the software to be the tall pole in the tent," said one aviation expert. "But the word I get after three martinis with these guys is that IBM wasn't able to produce the level of hardware that they needed." IBM had been designing the Advanced Automation System in Ada to run on the company's own Unix workstations.

"[The Advanced Automation System] was a disaster," said Steven Zaidman, of the FAA. "We shot for the moon. We tried to do advanced technology, computer replacements, new procedures, new software, and new decision support services all at once. We didn't realize the full scope of human factors. We put too much risk in the program in terms of pushing technology too fast. We underestimated the magnitude of the change."

Said the FAA's Planzer, speaking in May at the "Communicating for Safety" conference held in Chandler, Ariz.: "The failure...came from the inability of the FAA to control its wants and determine its needs."

Some think that the FAA simply tried to solve the wrong problem. According to Michael Baiada, a United Airlinespilot who is also an aviation consultant, the FAA attempted to computerize its current control process, rather than start from the ultimate goal--the separation of aircraft--and evaluate how one can achieve that goal.

Another reason for the failure of the system may have been bad timing. "The FAA began either five years early or five years late, where technology was concerned," said John J. Fearnsides, senior vice president and general manager of Mitre Corp., Bedford, Mass., and director of Mitre's Center for Advanced Aviation System Development.

"Had they started five years earlier, their approach would have been appropriate; had they started five years later, they would have had the information to understand that the proper way to build a system like this is in an evolutionary way: replace current systems, then add new functions and capabilities--don't do it all at once," he concluded.

One step at a time

These days the FAA has accepted that change in its air traffic control system must be evolutionary. First, the job is to develop new computer systems that perform today's functions but are, unlike current hardware, expandable. Then, advanced automation capabilities can begin to be added. The FAA has also embraced commercial off-the-shelf equipment for future systems.

With these new goals in view, the Advanced Automation System devolved after its cancelation in 1994into a pair of downscaled programs. One was the display system replacement (DSR) system, for new controller workstations in the en route centers. The other was, in the Tracons, the standard terminal automation replacement system (Stars), for newcontroller workstations and an accompanying distributed computing system (replacing the current ARTS radar tracking system).

The objectives of these two programs are similar: to replace the radar displays and, in the case of Stars, the computers that drive them, with networked workstations similar in function to the old systems, but functionallyexpandable. Both programs, the FAA's Zaidman told Spectrum , will use commercial off-the-shelf equipment.

"That is a big feature of our new acquisition system," he said. "We need to be more risk averse. We've learned not to push the boundaries of science. There are perfectly good commercial standards out there that are maintainable and supportable; made-to-order systems are not cost-effective for us." Zaidman indicated that both DSR and Stars will be similar to High Desert Tracon's Rehost, using Sony high-resolution monitors and a similar human-computer interface.

Refining the software

The DSR software has its roots in the aborted Advanced Automation System project (with simplified requirements and more realistic reliability specifications). It is written in approximately 391 000 lines of Ada and C code on an AIX operating system, IBM'S version of Unix, of which 214 000 lines are reused from the aborted project.

According to Lincoln Laboratory's Spencer, the display component of the Advanced Automation System software on which DSR is based was reviewed by the Center for Naval Analyses, Alexandria, Va., as part of an overall assessment of the program. The team at the center expressed concern that the software might not be salvageable or reusable.

But, Spencer said, given risks, delays, and additional costs involved in starting over, the FAA was very interested in fixing the software it already had. In 1994 MIT's Lincoln Laboratory and the Software Engineering Institute of Carnegie Mellon University, Pittsburgh, teamed up to perform a technical audit of the software and determined that, with changes they recommended, the software could be made usable and would be reasonably maintainable.

DSR when complete will support up to 198 IBM 6000 RISC (reduced­instruction-set computer) workstations at each of the 20 en route centers, with 16MB of memory in each. It will be, said Judy Gan, a spokesman for Lockheed Martin, the prime contractor for the system, "a platform on which you can start placing new applications for optimizing the air traffic control system." The design was accepted by the FAA in March; testing continues. The first DSR units are scheduled to become operational at the Seattle en route center in October 1998; according to Gan, the FAA may beat this date, based on early acceptance test completion by the contractor. The final workstations are due to be turned on in mid-2000.

Stars [ Fig. 6] is slated for installation at 172 FAA Traconfacilities. The $2.23 million program is based on Raytheon's existing AutoTrac air traffic management system, which is now in use at a number of air traffic control facilities outside the United States. For Stars, AutoTrac is to be augmented with improved safety functions and other tools.

Being written in C, Stars will run on Sun UltraSparc Unix workstations. Like Rehost at High Desert Tracon, it will use Kalman filter­based tracking to resolve information frommultiple radars. The first units are scheduled to be installed and begin testing in Boston in late 1998; the final sites are to be completed by 2007.

Still, there are concerns about Stars. As Ben Phelps, national safety coordinator for Natca, the air traffic controllers union, told Spectrum , "Stars changes nothing. It doesn't interface with half the new things coming on line. It's just a new box--the FAA is spending a lot of money on a project that changes nothing."

There is also some skepticism among controllers over whether Stars' implementation dates will even come close to being met, as well as fear that Stars will turn into another Advanced Automation System, delaying new controller workstations for another decade. In a March report, the General Accounting Office, too, expressed concerns about the attainability of the schedule and potential cost increases.

A quick fix

While the Advanced Automation System debacle set the effort to replace controller workstations back 10 years, failures at the five busiest U.S. en route centers became so frequent as to be intolerable and a threat to safety. Radar information being sent to the PVDs at the five centers is processed for display by '60s-vintage IBM 9020E computers. (The remaining 15 centers use a Raytheon computer as a display processor.)

Over and above total failures, memory overloads would cause the IBM 9020Es to regularly drop aircraft off the displays and switch data from one aircraft to another, said Marvin Smith, director of air traffic control for Embry-Riddle Aeronautical University, Daytona Beach, Fla. So recently a $63.9 million Band-Aid was developed--the display channel complex rehost (DCCR), a more modern IBM ES/9121 mainframe that translates information from the Host to the PVD.

This interim system was first installed in Chicago in mid-1996. As of last May, five systems (Chicago's, as well as those in Cleveland, Fort Worth, New York City, and Washington, D.C.) were operational, well ahead of schedule, according to Lockheed Martin, the prime contractor.

Early reports are positive. According to Wanda Geist, a former Chicago Center head of the Professional Airways Systems Specialists (PASS), the union that represents the engineers and technicians who install and maintain U.S. air traffic control equipment, as of May there had been no DCCR-triggered outages since the system started operation in December 1996. In comparison, in 1995 the Chicago Center reported to a Congressional hearing six major outages of the 9020E during the first three quarters of 1995.

While Stars takes over from the controller workstations and accompanying radar display processors in the Tracons, and while DSR will eliminate the PVDs and display processor in the en route centers, the Host computers stay put. They are not scheduled for replacement under the reformulated modernization plan.

"We desperately need something that replaces that piece of junk Host," Natca's Phelps told Spectrum .

Baiada, the United Airlines pilot and industry consultant, indicated that the current strategy of replacing Host peripherals like the PVD and the DCCR before replacing the IBM 3083s that are the Hosts is a mistake. In his view, it will force engineers to lower the capability of the peripherals because of the limitations inherent in the Host.

"This will propagate these limitations forward into the new system," Baiada said.

Mitre has, at the request of the FAA, begun looking at how a Host replacement ought to be designed. The project, said Fearnsides, involves "replacement of the mainframe, modernizing the operating system, and changing all the software out of Jovial.

"An entirely new architecture is needed, which may mean moving away from a central computer to a more distributed client-server system. That would enable the FAA to upgrade the host in bite-sized chunks, rather than recoding all at once the 1-1/2 million lines of code that got us into trouble in the first place."

Radars and radios

In the decade that the computer and controller workstation replacement effort of the Advanced Automation System was floundering, some new pieces of the air traffic control system were fielded.

A new generation of surveillance radar has been installed nationwide. Airport towers and Tracons use airport surveillance radars (ASRs) to monitor the surrounding skies and airport surface detection equipment (ASDE) to monitor the runways. En route centers depend on long-range air route surveillance radars (ARSRs) to watch over their airspace.

The ASR-9 terminal radar was installed at over 100 sites between 1989 and 1995. Its predecessor, the ASR-8, was the first ASR to use discrete transistors; the ASR-9 became the first one to use ICs. The ASR-9 has better resolution (3 milliradians across the beam compared with 5 milliradians for the ASR-8, allowing it to track a target within 300 feet at 20 miles). It is a Doppler radar and uses a technique known as moving target detection and can better distinguish aircraft from ground clutter.

The next radar, the ASR-11, under contract with Raytheon, is due to provide up to 213 radars between 1999 and 2007. This would be the first fully digital radar. When digital display systems become available, the ASR-9 and ASR-11 will be digitally interfaced with the new displays.

Bringing ASR-9 into the system has not been trouble-free. Initial problems--the detection of phantom aircraft and losing track of planes during parallel approaches and departures--are expected to be mitigated by the addition in 1998 of a processor augmentation card developed by Lincoln Laboratory in 1996.

In addition to failures within the radar itself, some of its problems appear to stem from the air traffic control systems' communications links. Indeed, since the system moved in 1992 to a digital communications network running across lines leased from MCI Communications Corp., Washington, D.C., links from all kinds of radar and communications sites have reportedly been a problem. (MCI won the contract for all government services under a Congressional mandate that approved the move; previous air traffic communications systems were analog, leased from AT&T Corp.)

Natca's Phelps told Spectrum that aggregating all FAA equipment used in critical safety endeavors, 17 percent of failures between May 1996 and May 1997 were caused by MCI line failure. For ASR-9, 30 percent of the failures during that same time period were attributable to the MCI contract."To have any single cause of failure that high is unacceptable," Phelps said.

Reports Eric Lindholm, a controller in the Miami Center and Natca's southern region ocean representative, one problem is that power spikes, which might temporarily degrade but not disable the analog system, bring the digital system down entirely. Besides communications, power supplies and archaic grounding methods have also caused problems, Lindholm said.

The ASDE-3 ground surveillance radar, which uses digital signal processing (unlike the ASDE-2, which dates back to the '60s and used an analog scan converter), is designed to penetrate fog, rain, and other weather conditions. It can do so because it combines frequency agility, circular polarization of the antenna, a narrow antenna beamwidth, a short transmit pulse, and other techniques to minimize backscatter by rain. It has been installed at 29 airports so far, with 11 still to go.

ASDE-3 is a high-resolution radarthat uses pulses at 16 frequencies instead of just one. (Northrop Grumman Corp.'s Norden Systems Division, Norwalk, Conn., is the prime contractor.) Its installation was delayed for approximately four years because of changes in specifications, disputes over features, and manufacturing problems.

The accompanying airport movement safety system (Amass) software, which performs basic collision detection from ASDE information, has been under development since 1991. So writes the former Department of Transportation inspector general, Mary Schiavo, in her recent book, Flying Blind, Flying Safe . But development delays have led to the project being popularly called "A-MESS." The first production system is currently scheduled to be delivered this summer, with a total of 39 systems to be deployed by mid-2000.

For the en route centers, the ARSR-4 long-range radar has just begun its rollout to 44 U.S. locations. It is the FAA's first all solid-state three-dimensional radar.

Furthermore, in the past three years, 21 new voice switching and communications systems (VSCSs) [ Fig. 7], manufactured by Harris Corp., Melbourne, Fla., have been installed in the centers. New voice communications switches for the Tracons are under contract with Litton Industries Inc./Denro Inc., in Beverly Hills, Calif., and Gaithersburg, Md., respectively.

The radios themselves are now on a gradual upgrade schedule, most dating back to the late '60s or early '70s. It is not yet clear, Zaidman said, whether the FAA will continue upgrading all its analog radios to more modern analog systemsor plan a transition to digital radios. To date, the FAA has not requested funding for such radios.

The new switches, which allow controllers to move from one radio frequency to another by touching a flat-panel display, have greatly improved reliability and ease of communications. As Embry-Riddle's Smith explained, when a controller touches the section of the panel that indicates what other controller he wishes to contact or frequency he wishes to use, the voice switching and communications system automatically finds a route and makes the connection. Previously, the controller had to flip switches and was limited in connections he could make.

Said a controller from Houston Center: "It may be just a Band-Aid, with the same communications system at the core, but we love it. It is solid state, so it just doesn't go down." It is more flexible, too; if a PVD fails, a controller previously had to keep his headset plugged into his original communications port, straining to see his planes on another display. With the voice switching and communications system, he can simply unplug his headset and move to a working display, and with a few touches on the radio switching panel, reconfigure that system to his original group of frequencies.

But new radars and communications switches--and the controller workstations being developed--only maintain the status quo . According to the FAA's Planzer, such programs "are not solutions to anything but maintenance woes. However, they are the infrastructure platform [on which] to add automation."

By replacing aging equipment, these programs prevent air safety from degrading, but they do not reduce the accident rate, and they certainly do not address the pressing need to increase capacity. "It is the adding of automation such as the conflict probe [computer software that will look ahead as much as 20 minutes to identify impending separation violations] that will assist in lowering the accident rate," Planzer said.

Trying to save lives

In the early '90s, one important safety improvement did make it into U.S. airspace--the traffic alert and collision avoidance system (TCAS). Since 1993, TCAS II has been required for all aircraft with 30 or more passengers flying in U.S. airspace; TCAS I has been required for aircraft with as few as 10 seats since 1995.

TCAS II uses a cockpit display to identify traffic within 5 to 40 miles of the aircraft (depending on pilot settings). It sounds alerts when impending separation violations, orconflicts as the FAA puts it, are detected, and recommends resolution of conflicts (climb or dive). (TCAS I issues traffic advisories only.)

Plans for TCAS III, which was to add left and right turn commands, have been dropped; a TCAS IV, which would incorporate Global Positioning System technology, is now envisioned. While some early versions of TCAS II had problems--excessive false alarms, in particular--most of those problems have been resolved.

At first, controllers were skeptical about the collision avoidance technology. The thought of having airplanes unexpectedly diving or climbing into airspace that controllers were using for separation of other aircraft was worrisome. However, TCAS proved workable, pilots seem pleased with it, and this year Natca lifted its resolution objecting to it.

More recently, another program to increase safety, the long-awaited terminal doppler weather radar (TDWR), began its rollout. This high-resolution radar is intended to detect all types of wind shear in an airport terminal area and give warnings so controllers can direct pilots to avoid it. Such advisories, it is hoped, will prevent wind shear disasters like the 1985 Delta crash at Dallas­Fort Worth Airport that killed 136 people.

Although 47 TDWRs have been purchased, installation has been sluggish. The radar must be sited some 8 to 12 miles from the airport, and land acquisition in some cases has proved difficult. To date, 26 TDWRs have been commissioned and 15 more have been accepted, which happens when the FAA satisfactorily completes testing. Five of the radars were delayed because of siting issues; three of those now have land, two are still on hold.

According to James Evans, head of the Weather Sensing Group at Lincoln Laboratory, the TDWR is saving lives, with a large number of wind shear alerts being passed on to pilots, who can then decide to abort a landing and go around the airport at a higher--and therefore safer--altitude.

But the controllers' perspective is different. They perceive TDWR as being so unreliable as to be useless, and have nicknamed it "Thunderstorms Destroy Weather Radar." They say that reliability figures are meaningless because such numbers do not indicate whether or not the systems are working during storms.

TDWR was designed to have a probability of microburst detection of at least 90 percent with a system availability of 99.9 percent, which would, according to Evans, reduce wind shear­caused crashes from once every other year to once every 20 years. (A microburst is a rapid downdraft that, as it approaches the ground, fans out in all directions. It is the most serious form of wind shear, a term that refers to any rather small volume of air with internal changes in wind speed and direction.) That rate, Evans said, is pretty good, considering the system must analyze complicated images before issuing its warnings.

Current TDWR availability has been 90 percent, with the probability of successful microburst detection when it is operating at 95 percent. Figures on availability during thunderstorms were not available, however, although Evans said TDWR provided timely warnings of 85 microbursts at Washington National Airport during the summer of 1996.

In recent testimony before the House Committee on Appropriations' Subcommittee on Transportation and Related Agencies, Jack Johnson, president of the Professional Airways Systems Specialists, urged discontinuance of the fielding of TDWR, a system that is "not ready" and that has "been plagued by outages nationwide."

From the FAA's viewpoint, current TDWR availability is not satisfactory. Problems are attributed to telephone lines and power quality, among other causes. According to an FAA spokesman, recent software changes have been sent to the field to make the TDWR systems more tolerant of telephone line problems.

Another technology that currently appears to be causing more problems than it solves is automated weathersensing and reporting. The automated surface observing system (ASOS), manufactured by AAI/System Management Inc., Cockeysville, Md., combines existing weather sensors with Motorola 68000 processors.

The system reports ceiling, visibility, present weather, temperature, dew point, wind direction and speed, and pressure. In addition, freezing rain sensors have been procured and are deployed at some locations. So far the system has replaced human observers at some 152 airports, and plans call for it to cover a total of 538 FAA locations, including 233 airports that previously did not have any weather observation service.

According to Robert Brown, deputy chairman of the National Safety Committee for the Allied Pilots Association (APA), Arlington, Texas, a collective bargaining agent for American Airlines pilots,and other sources, these systems sometimes give completely inaccurate information--reporting winds from the wrong direction (north instead of south) or incorrectly indicating that runway visibility meets visual flight rules (VFR) guidelines.

The problem, Phelps indicated, is that these systems use old sensors and underpowered computers (equivalent to an IBM XT), and they have a narrow range of observation--they look straight up in a circle with a diameter of 10 feet at an altitude of 25 000 feet. They are unable to even tell the difference between rain and snow, and, if they happen to catch a break in the clouds during an observation, will report airport conditions as clear, even when the airport is effectively socked in.

They also break downfrequently, said Calvin Smith, weather systems representative for Natca, and the only backup is the controller. "And it's a little hard for us to come out of the tower with a thermometer," Smith said. This situation can stymie commercial pilots of certain turbine-engine­powered airplanes, who are by regulation prevented from taking off without temperature information.

A new automated weather system in the works is the integrated terminal weather system (ITWS). It uses adata-fusion approach to take information from TDWR and other radar and sensors and process the data into a composite picture that will be displayed on Tracon computers and could be data-linked to pilots.

For example, ITWS can take radar information that indicates a mass of water falling, combine that data with temperature and humidity, and calculate evaporation, and therefore cooling. Cool air descending rapidly can create a microburst--hence, ITWS can predict microbursts. A prototype developed by Lincoln Laboratory has been in operation at three airports since 1994. Raytheon was awarded a development contract for this system in January, and is expecting operational deployment to start in 2002.

Betting on the future

There are bright spots in the air traffic control picture. One technology, in the testing phase, seems to have everyone's hopes up as something that could increase safety and capacity. That technology is the Center-Tracon Automation System (CTAS) [ Fig. 8]. CTAS computers include tools to improve air traffic operations from departure point to touchdown.

CTAS was developed at NASA's Ames Research Laboratory in Moffet Field, Calif., in cooperation with Natca. It began in the mid-'80s with three or four researchers employed on an in-house project supported by the NASA basic research budget, recalled Ames senior scientist for air traffic management Heinz Erzberger. The initial plan was to look at problems with aircraft delays and cockpit procedures, as well as problems informally identified by (San Francisco) Bay Tracon and Denver (en route) Center controllers.

"The FAA didn't have anything to do with it," Phelps told Spectrum . "That's why it works."

The FAA came on the scene onlyin 1991, with a letter of understanding and some funding to continue CTAS research. At that point, the CTAS group, then numbering 20 researchers, had been able to demonstrate software driven by live radar data, transmitted from the Denver center. (Today, nearly 50 engineers and programmers are assigned to the CTAS project at NASA, and many more are working on it at the FAA and at its contractor companies.)

All CTAS automation has a common logical core, Erzberger explained. It computes aircraft trajectories approximately 40 minutes into the future, starting at the aircraft's current position, then factoring in the aircraft's intent as contained in itsflight plan, along with a model of the performance capabilities of individual aircraft, including lift, drag, and thrust, and atmospheric conditions.

Such trajectory calculations, Erzberger said, can be used to look ahead for conflicts (conflict probe), determine appropriate spacing for traffic arriving at an airport, and produce other controller tools. CTAS is written in C and C++, an object-oriented language, with some 400 000 lines of code, and runs on Sun UltraSparcworkstations and other Unix-based computers. The system interfaces with existing air traffic control computers to obtain relevant flight plan and track data.

CTAS Build 1, which began testing in 1992, is called traffic management advisor (TMA). This is a flow control product that helps traffic management coordinators (who determine aircraft flow into busy airports by issuing orders for speed restrictions and increased trailing distances between aircraft). TMA is now in operational prototype at Atlanta, Denver, Los Angeles, and Miami airports.

CTAS Build 2, now in the development phase, sends CTAS data from the Unix processors through the existing en route center computers (the Host computer system), which distributes it to the PVDs, telling controllers how much delay each aircraft has to absorb and counts down the delay as the aircraft is vectored--that is, as it is ordered into a series of zigzag turns to increase its travel time. This interface was designed by the FAA.

"This was excruciating to develop," said Erzberger, "as it involved the Jovial software [in the Host computers]. We do not have the Hosts do any processing, they merely pass the data on to the display processors. We couldn't send it to the display processor directly; there is no local-area network for these devices."

Build 2 also has a feature called final approach spacing tool (FAST), used in the Tracon environment. FAST looks at traffic approximately 40 miles from the airport and determines the best runway to use and most efficient landing sequence of aircraft. That information is displayed on the data tag that accompanies radar returns on the Tracon controller displays as, for example "3, 13R," meaning third in line for landing, assigned to runway 13 right. The CTAS Build 2 tools are operational at the Dallas­Fort Worth Tracon and the Fort Worth Center, using NASA prototype code.

"With the new display systems, with local-area networks that use standard communications protocols," Erzberger said, "CTAS integration will be much simplified."

Spectrum has heard much praise for CTAS--a rare thing in air traffic control system development. Said Dick Swauger, national technology coordinator for Natca: "I never thought you could develop anything that could make a good controller better. A weak controller, sure, but not a good controller. Then I saw CTAS. It's like having a top controller at your side, whispering in your ear. And it does make good controllers better."

According to Ray Ellison, who is a controller at Phoenix Tower and Tracon representative to the CTAS development team, controllers love the CTAS tools being tested--TMA and FAST. During a recent test at Dallas­Forth Worth Airport, CTAS was able to increase aircraft operations during normal conditions from a non-CTAS maximum of 102 operations per hour to more than 120 operations per hour.

An advanced version of FAST, which suggests headings and speeds, is running in a laboratory environment but has not as yet been tested in the field. Said Jack Ryan, vice president, air traffic management, of the Air Transport Association, an organization that represents commercial airlines: "The FAA refuses to test it citing a cost-benefit analysis that they won't show me." An FAA spokesman indicated that this advanced version, called Active FAST, needs the new generation of color displays to be operational.

Also looming on the horizon are automatic dependent surveillance and a technique that goes by the shorthand name ofdata link.

Automatic dependent surveillance (ADS) is based on the Global Positioning System (GPS). It makes use of the GPS receivers aboard aircraft that give pilots navigation information. ADS would take the GPS information, along with the aircraft's velocity, and digitally transmit it by satellite or some form of radio data link to ground control facilities. There the signal would be captured and displayed on controllers' workstations.

ADS-B is a broadcast version of ADS that could be read by other aircraft, giving pilots a situational display of traffic around them that is much more accurate than that provided by TCAS. (ADS-B traffic display systems have already been built and demonstrated in Sweden and by MIT's Lincoln Lab, and they are being developed by Seagull Technology Inc., Los Gatos, Calif., for the U.S. Forest Service for use in fighting fires.)

To be used for air traffic control, the accuracy of the existing civilian GPS signal would be enhanced by the wide-area augmentation system (WAAS), currently being developed by Hughes Electronics Co., El Segundo, Calif. This network of 24 ground reference stations, master processing stations, satellite communications links, and related software will correct clock, satellite location, ionospheric delay, and other errors in the GPS pseudorange measurements. The system's job is to compare known GPS receiver locations to the GPS-determined location of those positions, and then broadcast corrections for use by aircraft and other receivers.

Standard civilian GPS locates targets in a horizontal domain of 100 meters 70 percent of the time, compared with some 300 meters for ground-based radar surveillance systems; WAAS would bring that figure down to 7.6 meters, said a Hughes spokesman.

In testing, according to J. David Powell, professor of aeronautics and astronautics at Stanford University, GPS with a WAAS prototype system using 18 reference stations throughout the United States proved to be accurate to better than 3 meters (horizontally) 95 percent of the time.

GPS navigation is tailor-made for the ocean environment, where radar coverage is not available, and a $300 million program has been launched. (Today, aircraft flying over the oceans avoid conflicts by flying in predetermined corridors that are 100 miles apart over the Pacific and 60 miles apart over the Atlantic. Powell indicated that, given enough time and experience with ADS-B, separation standards could eventually be reduced.)

The first operational WAAS is scheduled to start up in early 1999, with nationwide rollout to be completed in 2001. A future version of differential GPS, the local-area augmentation system (LAAS), would enable even more accurate corrections for aircraft near airports. At present, it is still being tested and refined. Tests of a prototype system by Stanford University in 1995 demonstrated 100 automatic landings by a United Airlines B-737 with navigation accuracies better than 50 cm.

The idea of GPS-based surveillance makes some controllers nervous, however. "GPS isn't as wonderful as we think it is," Embry-Riddle's Smith said. "But it is the best thing that has come along in a long time. It works, and sooner or later we can anticipate that it will get through all the politics and will be certified. People will have to use it because the alternatives are too expensive."

One impetus for implementing GPS-WAAS is the problem that the FAA is facing with its aging very high-frequency omnidirectional range (VOR) navigation system. The 1000 VORs gridding the United States are beginning to fail and require replacement. Moving to GPS would lead to huge cost-savings in replacing the old VOR system.

Whether GPS-WAAS could permit the FAA also to abandon its radar surveillance is subject to debate. Said Jerry Welch, group leader of the air traffic automation group for MIT's Lincoln Laboratory: "The FAA's current position is that it will eventually get rid of that also as a cost-saving measure, but they have not conclusively shown that that is feasible."

Miami Center controller Lindholm, said that nondirectional beacons (NDBs), which are also ground-based navigation aids, may be phased out as well. Most experts agree that GPS-WAAS will allow elimination of en route radar surveillance. But, because of safety implications, GPS is not expected to replace terminal surveillance radars.

ADS when implemented on a large scale could also enable aircraft separation standards--now kept at 5 miles horizontally in the en route environment--to be reduced. According to L. Lane Speck, director of air traffic program integration for the FAA, the 5-mile standard comes from the technical limits of the radar, which completes a scan every 12 seconds. At the edge of radar ranges (250 miles), aircraft less than 5 miles apart could theoretically swap positions on radar monitors. Moving to satellite-based separation could end that limitation, although some in the industry are concerned that the delay times in satellite communication would compromise safety.

Less talk, more data

A continual complaint of controllers and pilots alike, and one that has been proven in accident analyses to have an impact on safety, is frequency congestion. Because controllers are talking rapidly to as many as 25 to 30pilots at a time, there is often no time available for standard readback of clearance information. For instance, a typical clearance might be: "TWA 242, descend and maintain flight level 350" (35 000 feet).Pilots then simply say "Roger," even if unsure that they heard a number correctly.Amistake might not be caught until the controller sees the blip on his screen zooming past the assigned altitude--or the plane crashes into a mountain.

The apparent solution to frequency congestion is adigital data link, which digitally transmits standard information--like speed, altitude, and heading assignments--from the controller keyboard to a display in the cockpit. Voice radio communications would be saved for anomalies.

"I'd love data link," an Indianapolis controller told Spectrum . "Half my conversations are bringing a pilot onto my frequency and then sending him off; if I could do that without talking, it would help me handle more planes. It also would eliminate misunderstandings. I send a lot of pilots to flight level 230 (23 000 feet); if a pilot reads back 330, I'm so used to hearing 230 that I just don't notice until I see him busting up into someone else's airspace."

While nearly everyone agrees data link is a good idea, implementation is not as obvious. One suggestion is to use the current aircraft communications and reporting system (Acars), a commercial service run by Aeronautical Radio Inc. (Arinc), Annapolis, Md., which airline management relies on to send messages such as connecting gate information to cockpit crews. Some control data, for example, predeparture clearances (time to start engines, push back from gate) have been moved to Acars at some airports.

But using Acars as currently implemented for real-time air traffic control communication would be a bad idea, said Ross Sagun, chairman of the Air Line Pilots Association's (ALPA's) Air Traffic Control Committee, Herndon, Va. "Acars is behind me [in the cockpit]; I often don't see messages for 10 minutes."

Another possibility is expansion of the Mode S transponders, used aboard aircraft to emit a 56-bit burst of data once per second at 1090 MHz. These are used to track aircraft from the ground as a replacement for the standard Mode C transponder and to identify aircraft to collision avoidance (TCAS) systems. (Mode S transponders can be selectively interrogated, relieving radar system capacity.)

It may be that neither Acars nor Mode S has enough bandwidth for extensive and rapid data transfer (though each have supporters), so other data link implementations are being considered. There are a number of technical options. For one, should the signal be transmitted by satellite or from the ground? At what frequency? Would a viable solution be time-division multiple-access (TDMA) coding? (In TDMA several data streams are transmitted simultaneously at one frequency, witheach stream sent in bursts in particular time slots and then reassembled at the end.)

"People are duking these issues out right now," Lincoln Lab's Spencer said.

There are also human factors concerns. In a recent report, the National Research Council, Washington, D.C., indicated that data link "may reduce the amount of information available to flight crews, often relayed via nonverbal cues in voice communications, and may have a deleterious effect on the development of teamwork between controllers and flight crews." The report also stated that the reduction of "party line" information (overheard transmissions between other pilots and controllers on the same frequency) may cause problems for pilots.

Data link must be intimately integrated with controller workstations, for a separate terminal would take controllers eyes from their radar displays too often for safety's sake. So full implementation must wait until the display system replacement and the standard terminal automation replacement system are in place. Then, theoretically, these systems could be upgraded with data link capability.

Free flight

Such technologies as CTAS, ADS, and data link are, it is hoped, leading to an evolution in air traffic control to a safer, more productive, airspace--reducing ground holds and other delays that are symptomatic of a system straining its capacity and economically burdensome for the airlines. But the evolution may create a revolution. That revolution has been termed free flight [ Fig. 9].

"The pieces are coming together one at a time, and they all add up to free flight," John Sorensen, president of Seagull Technology, a firm under contract to NASA to define operational concepts for free flight, told Spectrum .

According to Task Force 3 of RTCA Inc., Washington, D.C.,which defined free flight in a 1995 report, free flight is a "safe and efficient flight operating capability under instrument flight rules in which [pilots] have the freedom to select their path and speed in real time. Air traffic restrictions are only imposed to ensure separation, to preclude exceeding airport capacity, to prevent unauthorized flight through special use airspace (for example, airspace restricted for military operations), and (otherwise) to ensure safety in flight." (RTCA, formerly called the Radio Technical Commission for Aeronautics, is a nonprofit organization that recommends standards and offers guidance to the aviation industry.)

Other groups, according to a brochure describing free flight and developed by Natca, call free flight "electronic VFR [visual flight rules]." That is, it confers on aircraft under instrument flight rules the same freedom of movement as those under visual flight rules today.

According to Natca's Karl Grundmann, a member of the RTCA free flight committee, free flight is simply "the next generation of air traffic control that makes use of technology to create a more flexible, user-friendly system."

Pilots throughout the world think free flight is a great idea, if implemented correctly. Airline managers are enamored of the concept because it has the potential of saving billions. Supporting free flight is, today, the only politically correct path to take. As U.S. Senator Slade Gorton (R-Wash.), chair of the Senate's Subcommittee on Aviation, under the Committee on Commerce, Science, and Transportation, told Spectrum: "Some form of free flight should be the goal of the air traffic control system in this country. The potential savings of time and fuel could be of tremendous benefit to the aviation industry. In addition, if planes burn less fuel because of less time spent in the air, they also produce less pollution."

To accomplish free flight, the role of the air traffic controller must be changed to that of separation manager, said United Airlines' Baiada, who was an early proponent of the concept.

"Separation is the job we want the controllers to do," he said. "I have no qualms telling the controller where I'm going, and when and if I make changes, but unless I will conflict with another aircraft, they should not be able to restrict my flight path."

"Controllers," said Seagull Technology'sSorensen, "are skeptical--they see a situation where they still have responsibility, but can no longer put planes in a line and maintain control."

The RTCA task force made 46 recommendations for moving toward free flight. Most of the near-term recommendations are procedural, according to David Watrous, RTCA president--for example, increasing the use of direct routing (allowing pilots to fly from airport to airport rather than zigzagging over very high-frequency omnidirectional range transmitters ).

Some equipment changes are also required to enable controllers to handle aircraft that, instead of flying in a row, are in more complex patterns. New equipment should include implementing a conflict probe capability, that is, computer software that looks ahead several minutes, taking into consideration both aircraft location and intent to identify potential future conflicts. Called a user request evaluation tool (URET), such a system has been evaluated at the Indianapolis Center running on a Digital Equipment Corp. Alpha computer system.

URET, under development by Mitre Corp. for use in en route airspace, uses flight plan, radar tracking, and weather information, along with a database of aircraft performance characteristics to predict aircraft trajectories and identify aircraft problems up to 20 minutes in the future. Such equipment should also incorporate CTAS, data link, a follow-on to automatic dependent surveillance calledADS-B, and satellite-based navigation. RTCA's Government/Industry Free Flight Steering Committee not long ago recommended the implementation of URET, CTAS, and data link as near-term free flight initiatives.

Landing in parallel

System capacity can also be increased by extending the use of simultaneous approaches on parallel runways, now conducted at 22 airports, to facilities with parallel but more tightly spaced runways. A tool for doing this is the precision runway monitor (PRM) or similar systems under development. Designed by AlliedSignal Inc., Morristown, N.J., the PRM uses a high-speed scanning radar and a dedicated display to track simultaneous instrument approaches to parallel runways at less than the 4300 feet apart of the current standard. A PRM prototype was tested at Raleigh/Durham Airport in North Carolina; the first operational system is slated to be turned on in Minneapolis later this year.

"Without technological enhancements to the terminal environment, like PRM, free flight is an eight-lane freeway that leads to a single car garage," commented Steve Lenertz, a controller at the Minneapolis Tracon, speaking recently at "Communicating for Safety," an annual conference sponsored by Natca, Embry-Riddle, and others.

CTAS and PRM both increase the number of aircraft that can land at an airport in a given time. Such tools are necessary for free flight, Natca's Swauger said, because the airspace controlled by en route centers "will achieve freedom only when flow in and out of airports is improved."

Nonetheless, some question exists as to whether all this technology is needed for free flight. Baiada argues that ADS, GPS, and data link are not requirements for, but enhancements to, free flight. "The key to free flight implementation is ground-based automation tools to help the controller," Baiada said, including computerized conflict probe and time-based sequencing as implemented by the CTAS' FAST software.

It is also debatable whether full free flight is actually needed. Some think that widespread implementation of CTAS and conflict probe tools will increase system efficiency so greatly that the desire for free flight will evaporate.

Other questions concerning the implementation of free flight remain. As Natca's Grundmann pointed out: what happens when the automation fails? The system should not be automated beyond the ability of humans to recover it, he said.

Free flight technology and concepts are scheduled to undergo a two-year test called "HAlaska," starting in 1999 in Hawaii and Alaska. Senator Gorton told Spectrum that it may take as long as 10 years beyond that test to implement such capability.

Will these new air traffic control technologies be designed, tested, manufactured, installed, and operating reliably in the United Statesbefore airspace congestion reaches critical levels and accident tolls mount? The FAA's track record is not good, but recent changes in program management and acquisition procedures have raised hopes. The clock is ticking.