Air Traffic Control: Complete and Enforced Architecture Needed for FAA
Systems Modernization (Chapter Report, 02/03/97, GAO/AIMD-97-30).

GAO reviewed the Federal Aviation Administration's (FAA) air traffic
control (ATC) modernization effort, focusing on: (1) whether FAA has a
target architecture and associated subarchitectures, to guide the
development and evolution of its ATC systems; and (2) what, if any,
architectural incompatibilities exist among ATC systems and the effect
of these incompatibilities.

GAO found that: (1) FAA lacks a complete systems architecture, or
overall blueprint, to guide and constrain the development and
maintenance of the many interrelated systems comprising its ATC
infrastructure; (2) FAA is developing one of the two principal
components of a complete systems architecture, the "logical" description
of FAA's current and future concept of ATC operations as well as
descriptions of the ATC business functions to be performed, the
associated systems to be used, and the information flows among systems;
(3) however, FAA is not developing, nor does it have plans to develop,
the second essential component, the ATC-wide "technical" description
which defines all required information technology and telecommunications
standards and critical ATC systems' technical characteristics; (4) the
lack of a complete and enforced systems architecture has permitted
incompatibilities among existing ATC systems and will continue to do so
for future systems; (5) overcoming these incompatibilities means "higher
than need be" system development, integration, and maintenance costs,
and reduced overall systems performance; (6) because there are no
standards for programming languages or open systems, ATC systems'
software has been written in many different application programming
languages, often exhibiting proprietary system characteristics; (7) this
not only increases software maintenance costs but also effectively
precludes sharing software components among systems; (8) without a
technical architecture specifying the information technology standards
and rules, the opportunity to share software will likely be lost; (9) in
some cases, system incompatibilities exist because the technology and
standards now available to permit system integration and
interoperability did not exist or were only emerging when the systems
were designed and developed; (10) other system incompatibilities are the
result of FAA's failure to adopt and effectively enforce a technical
architecture; (11) by failing to formulate a complete systems
architecture, FAA permits and perpetuates inconsistency and
incompatibility; (12) as a result, future ATC system development and
maintenance will continue to be more difficult and costly than it need
be and system performance will continue to be suboptimal; (13) FAA's
management structure for developing, maintaining, and enforcing an ATC *

--------------------------- Indexing Terms -----------------------------

 REPORTNUM:  AIMD-97-30
     TITLE:  Air Traffic Control: Complete and Enforced Architecture 
             Needed for FAA Systems Modernization
      DATE:  02/03/97
   SUBJECT:  Systems design
             Systems compatibility
             Cost control
             Air traffic control systems
             Federal procurement
             Navigation aids
             Systems conversions
             Requirements definition
             Computer software
             Information technology
IDENTIFIER:  FAA National Airspace System Plan
             FAA Host Computer Program
             FAA Peripheral Adapter Module Replacement Item
             FAA Advanced Automation System
             FAA Voice Switching and Control System
             FAA Integrated Terminal Weather System
             FAA Aviation Weather Observing System
             FAA Initial Sector Suite System
             FAA Air Route Surveillance Radar-4
             FAA Display Channel Complex Rehost Project
             FAA Display System Replacement
             Software Capability Maturity Model
             NAVSTAR Global Positioning System
             FAA Capital Investment Plan
             FAA Wide Area Augmentation System
             FAA Standard Terminal Automation Replacement System
             FAA Oceanic Display and Planning System
             FAA Air Traffic Control Modernization Program
             FAA Air Traffic Control System
             
******************************************************************
** This file contains an ASCII representation of the text of a  **
** GAO report.  Delineations within the text indicating chapter **
** titles, headings, and bullets are preserved.  Major          **
** divisions and subdivisions of the text, such as Chapters,    **
** Sections, and Appendixes, are identified by double and       **
** single lines.  The numbers on the right end of these lines   **
** indicate the position of each of the subsections in the      **
** document outline.  These numbers do NOT correspond with the  **
** page numbers of the printed product.                         **
**                                                              **
** No attempt has been made to display graphic images, although **
** figure captions are reproduced.  Tables are included, but    **
** may not resemble those in the printed version.               **
**                                                              **
** Please see the PDF (Portable Document Format) file, when     **
** available, for a complete electronic file of the printed     **
** document's contents.                                         **
**                                                              **
** A printed copy of this report may be obtained from the GAO   **
** Document Distribution Center.  For further details, please   **
** send an e-mail message to:                                   **
**                                                              **
**                                            **
**                                                              **
** with the message 'info' in the body.                         **
******************************************************************


Cover
================================================================ COVER


Report to the Secretary of Transportation

February 1997

AIR TRAFFIC CONTROL - COMPLETE AND
ENFORCED ARCHITECTURE NEEDED FOR
FAA SYSTEMS MODERNIZATION

GAO/AIMD-97-30

Air Traffic Control

(511488)


Abbreviations
=============================================================== ABBREV

  AAS - Advanced Automation System
  AND - Office of Communication, Navigation, and Surveillance Systems
  AOAS - Advanced Oceanic Automation System
  ARA - Associate Administrator for Research and Acquisitions
  ARINC - Aeronautical Radio Incorporated
  ARTS - Automated Radar Terminal System
  ATC - air traffic control
  ATCSCC - Air Traffic Control System Command Center
  ATM - Air Traffic Management
  ATS - Associate Administrator for Air Traffic Services
  AUA - Office of Systems Development
  CIO - Chief Information Officer
  CIP - Capital Investment Plan
  CSA - corporate systems architecture
  CTAS - Center TRACON Automation System
  DOT - Department of Transportation
  DSR - Display System Replacement
  EDARC - Enhanced Direct Access Radar Channel
  FAA - Federal Aviation Administration
  FDDI - Fiber Distributed Data Interface
  FDP - flight data processing
  GPS - Global Positioning System
  HCS - Host Computer System
  HID/LAN - Host Interface Device/Local Area Network
  IPT - Integrated Product Team
  NAS - National Airspace System
  NAS-DD-1000 - NAS Level 1 Design Document
  NAS-SR-1000 - NAS System Requirements Specification
  NAS-SS-1000 - NAS System Specification
  NIMS - NAS Infrastructure Management System
  ODAPS - Oceanic Display and Planning System
  PAMRI - Peripheral Adapter Module Replacement Item
  RE&D - Research, Engineering, and Development
  SE-CMM - Systems Engineering Capability Maturity Model
  SEI - Software Engineering Institute
  SQL - Structured Query Language
  STARS - Standard Terminal Automation Replacement System
  TMS - Traffic Management System
  TRACON - terminal radar approach control
  WAAS - Wide Area Augmentation System

Letter
=============================================================== LETTER


B-271527

February 3, 1997

The Honorable Federico Peï¿½a
Secretary of Transportation

Dear Mr.  Secretary: 

This report describes the need for a Federal Aviation Administration
(FAA)-wide systems architecture in modernizing Air Traffic Control
(ATC), and assesses FAA's efforts to develop and utilize one. 

This report contains recommendations to you.  The head of a federal
agency is required by 31 U.S.C.  720 to submit a written statement on
actions taken on these recommendations.  You should send your
statement to the Senate Committee on Government Affairs and the House
Committee on Government Reform and Oversight within 60 days after the
date of this report.  You must also send the written statement to the
House and Senate Committees on Appropriations with the agency's first
request for appropriations made over 60 days after the date of this
report. 

We are providing copies of this report to interested congressional
committees and subcommittees, the Director of the Office of
Management and Budget, the Administrator of the Federal Aviation
Administration, and other interested parties.  Copies will also be
made available to others upon request.  Please call me at (202)
512-6412 if you have any questions concerning the report.  Other
contributors to this report are listed in appendix III. 

Sincerely yours,

Dr.  Rona B.  Stillman
Chief Scientist for Computers
 and Telecommunications


EXECUTIVE SUMMARY
============================================================ Chapter 0


   PURPOSE
---------------------------------------------------------- Chapter 0:1

Effectively and efficiently designing and constructing a building
requires a complete blueprint that defines the building's features,
functions, and systems as well as how these components interrelate
and how they are to be crafted, including applicable building codes,
rules, and standards.  Effective and efficient modernization of an
organization's computer systems requires no less.  Accordingly, the
Congress has emphasized in law the importance of agencies' Chief
Information Officers (CIO) developing and implementing system
blueprints, commonly called architectures, to guide current and
future systems development and evolution.\1

Because of the size, complexity, and importance of FAA's air traffic
control (ATC) modernization, we reviewed it to determine (1) whether
FAA has a target architecture(s), and associated subarchitectures, to
guide the development and evolution of its ATC systems; and (2) what,
if any, architectural incompatibilities exist among ATC systems, and
the effect of these incompatibilities. 


--------------------
\1 The 1996 Clinger-Cohen Act, P.  L.  No.  104-106, section 5125,
110 Stat.  684 (1996). 


   BACKGROUND
---------------------------------------------------------- Chapter 0:2

A systems architecture is a blueprint to guide and constrain the
development and evolution (i.e., maintenance) of a collection of
related systems.  A systems architecture can be viewed as having both
a logical and technical component.  At the logical level, the
architecture provides a high-level description of the organizational
mission being accomplished, the business functions being performed
and the relationships among functions, the information needed to
perform the functions, and the flow of information among functions. 

At the technical level, the architecture provides the rules and
standards needed to ensure that the interrelated systems are built to
be interoperable,\2 portable,\3 and maintainable.  These include
specifications of critical aspects of the component systems'
hardware, software, communication, data, security, and performance
characteristics. 

Since 1981, FAA has spent about $23 billion to modernize its aging
air traffic control (ATC) system.  It plans to spend about $11
billion more through the year 2003, with additional systems to be
undertaken through the year 2015.  Through this enormous investment,
FAA plans to put in place a vast "system of systems" that will allow
it to safely and efficiently keep pace with burgeoning traffic
volumes.  Successfully doing so, however, requires that
interdependent ATC systems are architecturally consistent (i.e., can
work together effectively and efficiently, and be developed,
operated, and maintained cost effectively). 

FAA's Associate Administrator for Research and Acquisitions is
primarily responsible for managing ATC systems acquisitions, while
ATC systems operations and maintenance responsibility falls under
FAA's Associate Administrator for Air Traffic Services. 


--------------------
\2 Interoperability is the ability of disparate systems to work
together efficiently and effectively over a network. 

\3 Portability is the degree to which a computer program can be
transferred from one hardware configuration and/or software
environment to another. 


   RESULTS IN BRIEF
---------------------------------------------------------- Chapter 0:3

FAA lacks a complete systems architecture, or overall blueprint, to
guide and constrain the development and maintenance of the many
interrelated systems comprising its ATC infrastructure.  To FAA's
credit, it is developing one of the two principal components of a
complete systems architecture, namely the "logical" description of
FAA's current and future concept of ATC operations as well as
descriptions of the ATC business functions to be performed, the
associated systems to be used, and the information flows among
systems.  However, FAA is not developing, nor does it have plans to
develop, the second essential component--the ATC-wide "technical"
description which defines all required information technology and
telecommunications standards and critical ATC systems' technical
characteristics (i.e., hardware, software, communications, data
management, security, performance). 

The lack of a complete and enforced systems architecture has
permitted incompatibilities among existing ATC systems and will
continue to do so for future systems.  Overcoming these
incompatibilities means "higher than need be" system development,
integration, and maintenance costs, and reduced overall systems
performance.  To illustrate, because there are no specified standard
data communication protocols,\4 existing systems have implemented
different communication protocols.  To make them work together,
expensive interfaces (hardware and software) acting as protocol
translators are required, complicating and slowing communications. 
Similarly, because there are no standards for programming languages
or open systems, ATC systems' software has been written in many
different application programming languages, often exhibiting
proprietary system characteristics.  This not only increases software
maintenance costs but also effectively precludes sharing software
components among systems.  For example, two ATC systems perform
flight data processing functions, one for traffic in the continental
U.S.  and the other for traffic over the oceans.  Since about 40
percent of the functions that these systems perform are the same,
their replacements could potentially share a significant amount of
software, avoiding duplicative development and saving money. 
However, without a technical architecture specifying the information
technology standards and rules, the opportunity to share software
will likely be lost. 

In some cases, system incompatibilities exist because the technology
and standards now available to permit system integration and
interoperability did not exist or were only emerging when the systems
were designed and developed.  However, other system incompatibilities
are the result of FAA's failure to adopt and effectively enforce a
technical architecture.  By failing to formulate a complete systems
architecture and using this to guide the development and evolution of
its modernized systems, FAA permits and perpetuates inconsistency and
incompatibility.  As a result, future ATC system development and
maintenance will continue to be more difficult and costly than it
need be and system performance will continue to be suboptimal. 

FAA's management structure for developing, maintaining, and enforcing
an ATC systems architecture is not effective.  The Office of Systems
Architecture and Investment Analysis, which reports to the Associate
Administrator for Research and Acquisitions, is responsible for
developing and maintaining the logical ATC systems architecture, but
no FAA organizational entity is responsible for developing and
maintaining the technical ATC architecture.  As a result, there is no
complete technical architecture and no coordinated effort underway to
produce one.  Additionally, FAA does not effectively enforce the only
ATC architecture it has, the NAS (logical ATC) architecture. 
Instead, processes now in place at FAA permit the acquisition of
architecturally non-compliant systems without special waiver of
architectural standards.  Until FAA assigns responsibility and
authority and provides resources for developing, maintaining, and
enforcing a complete ATC systems architecture to a single FAA
organizational entity, FAA will continue to develop systems that
require more effort and cost more than is necessary. 


--------------------
\4 Data communication protocols are sets of rules that govern
communications among computer systems. 


   PRINCIPAL FINDINGS
---------------------------------------------------------- Chapter 0:4


      AN ARCHITECTURE IS THE
      CENTERPIECE OF SOUND SYSTEMS
      DEVELOPMENT AND MAINTENANCE
-------------------------------------------------------- Chapter 0:4.1

As systems have become increasingly complex and critical, the need
for a systems architecture to ensure interoperability and cost
effective maintenance has been generally recognized.  For example,
the Software Engineering Institute at Carnegie Mellon University
advocates systems architectures to guide systems design and
implementation.  Additionally, leading private and public sector
organizations are using systems architectures to guide
mission-critical system acquisition, development, and maintenance. 


      FAA IS DEVELOPING A LOGICAL
      ARCHITECTURAL COMPONENT FOR
      ATC MODERNIZATION AND
      EVOLUTION
-------------------------------------------------------- Chapter 0:4.2

FAA is currently developing a logical ATC architecture as part of its
National Airspace System (NAS)\5 architecture.  Among other things,
the NAS architecture describes FAA's current and future concept of
ATC operations, requirements in terms of business functions to be
performed, associated systems to be used, relationships among these
functions and systems, information needed to perform these functions,
and flow of information among the functions and systems.  This
high-level systems blueprint also provides a roadmap, or transition
plan, for its ATC systems over a 20-year period. 


--------------------
\5 FAA's Pilot/Controller Glossary defines the NAS as the common
network of U.S.  airspace; air navigation facilities, equipment, and
services; airports or landing areas; aeronautical charts,
information, and services; rules, regulations, and procedures;
technical information; and manpower and material.  Included are
system components shared jointly with the military. 


      FAA LACKS A TECHNICAL
      ARCHITECTURAL COMPONENT TO
      GUIDE AND CONSTRAIN ATC
      MODERNIZATION AND EVOLUTION
-------------------------------------------------------- Chapter 0:4.3

FAA lacks the second component of a systems architecture, the
technical architecture that defines the standards and rules that will
be used to implement the logical architecture.  The NAS architecture
explicitly states that "it is not intended to define detailed
performance, characteristics, or interfaces of physical systems."
Instead, FAA is allowing each of the 10 ATC system development teams
to choose these characteristics for its systems independently. 

Technical architecture guidance is vital in ensuring the proper
integration of FAA's many interdependent systems and simplifying
system maintenance.  Despite this, 7 of the 10 ATC modernization
systems development teams that are developing new systems are doing
so without a technical architecture.  Moreover, although the other
three are cooperatively developing similar architectures for their
systems, these architectures are not completely compatible, and the
incompatibilities are not justified by careful, documented analysis. 
For example, all three architectures specify C and C++ as acceptable
programming languages, but one architecture also specifies Ada as an
acceptable language.  Further, one technical architecture specifies
the ethernet protocol, while another specifies the Fiber Distributed
Data Interface (FDDI) protocol.  These two protocols are not
compatible. 

At the same time, still other FAA organizations are independently
attempting to develop pieces of a technical architecture (e.g.,
software guidance, security guidance), but these efforts neither
individually nor collectively constitute a complete ATC-wide
technical architecture.  Without a single, unified technical
architecture, compatibility and interoperability across and among all
ATC systems is highly unlikely. 


      WITHOUT A TECHNICAL ATC
      ARCHITECTURE, COSTLY SYSTEM
      INCOMPATIBILITIES HAVE
      RESULTED AND WILL CONTINUE
-------------------------------------------------------- Chapter 0:4.4

A technical architecture specifies the information technology and
communication standards that will be used to build systems, including
communication protocols and programming languages, and facilitates
the migration to compatible, vendor-independent operating
environments.  A vendor-independent environment is one whose critical
interfaces and characteristics are in the public domain (i.e., not
unique to a particular vendor or group of vendors).  Because FAA
developed its ATC systems without a technical architecture and relies
upon vendor-unique environments, it continues to spend time and money
to overcome system incompatibilities and may lose opportunities to
share software components among systems and avoid duplicative
development and maintenance. 

One example is the 30-year-old Host Computer System, which is the
centerpiece of ATC operations.\6 This system receives data from
numerous other systems, including aircraft surveillance radars and
weather detection systems, and processes it for use by controllers in
tracking aircraft.  If all of these feeder systems used standard,
architecturally defined communications protocols and data formats,
then there would be no need to convert protocols and data formats for
the Host.  However, with no unifying technical architecture, these
feeder systems use a number of different, incompatible communication
protocols and data formats that must be converted into formats
understandable by the Host.  To perform this extensive conversion,
FAA spent over $38 million to acquire a dedicated system, the
Peripheral Adapter Module Replacement Item (PAMRI).\7

Additionally, it spends millions annually to maintain PAMRI.\8

Another example of suboptimization caused in part by the absence of a
technical architecture is the proliferation of ATC systems'
application programming languages.  Currently, software applications
associated with 54 ATC systems are written in 53 programming
languages.  Software written in multiple languages is more difficult
and expensive to maintain because it requires more training and
support software for programming staff.  Without a technical
architecture limiting language choices, FAA continues to introduce
additional languages as new systems are developed, which complicates
maintenance even further and drives up its costs. 

Incompatibilities among ATC systems also preclude software reuse,
which could potentially save systems development and maintenance time
and money.  Specifically, some ATC systems perform like or similar
functions, each in a different airspace environment.  For example,
FAA officials told us that about 40 percent of the functions
performed as part of en route airspace flight data processing (FDP)
are identical to functions performed in oceanic airspace FDP. 
However, without a technical architecture specifying the information
technology standards and rules, the oceanic and en route replacement
systems are not likely to implement common standards and the
opportunity to share software components will be lost. 


--------------------
\6 FAA plans to begin replacement of the Host Computer System in
fiscal year 1999. 

\7 This cost does not include FAA internal costs (e.g., project
management, testing) associated with acquiring PAMRI because FAA was
unable to provide these costs. 

\8 FAA could not provide the full cost of maintaining PAMRI. 
Instead, FAA officials stated that about $200,000 is spent annually
to maintain PAMRI hardware, and about $500,000 is spent annually to
maintain PAMRI software at three sites.  However, they could not
provide the annual cost to maintain PAMRI software at the other 26
sites where PAMRI is operational.  We did not evaluate these costs. 


      FAA LACKS AN EFFECTIVE
      MANAGEMENT STRUCTURE FOR
      DEVELOPING AND ENFORCING AN
      ATC SYSTEMS ARCHITECTURE
-------------------------------------------------------- Chapter 0:4.5

If a systems architecture is to be effectively developed, maintained,
and enforced, some organizational entity must (1) be assigned the
responsibility and held accountable for doing so, (2) be given
sufficient resources to accomplish the task, (3) have expertise in
information technology, and (4) have organizational and/or budgetary
authority over all systems development and maintenance activities. 
One model for implementing this is embodied in the Clinger-Cohen Act,
which requires that major federal departments and agencies establish
CIOs that report to the department/agency head and are responsible
for developing, maintaining, and facilitating the implementation of
systems architectures. 

FAA does not have an effective management structure for developing,
maintaining, and enforcing a logical systems architecture.  An
organization under the Associate Administrator for Research and
Acquisitions is responsible for developing and maintaining FAA's
logical architecture.  However, this office is not responsible for
enforcing the logical architecture (nor could it effectively do so
because it has no budgetary or organizational authority over the
teams developing and maintaining ATC systems).  With no organization
in FAA responsible for enforcing a logical systems architecture, FAA
has attempted to encourage use of the logical architecture through
its investment process, which stipulates that architectural
conformance be considered as one of four criteria before an ATC
system is approved for funding.  This process does not ensure
architectural conformance since noncompliant ATC projects could be
funded (on the basis of the other three criteria) without an
effective waiver process. 

FAA also lacks an effective management structure for developing,
maintaining, and enforcing a technical ATC systems architecture.  No
organization in FAA is responsible for the technical ATC
architecture.  Instead, FAA has permitted a "hodge podge" of
independent efforts scattered across its ATC modernization
organization to emerge with no central guidance and coordination.  As
a result, there is no ATC-wide technical architecture, and it is
unlikely that FAA will produce one in the near future. 

Until the authority, responsibility, and resources to develop,
maintain, and enforce a complete ATC systems architecture is clearly
assigned to a single FAA organizational entity, FAA will continue to
build incompatible and unnecessarily expensive and complex ATC
systems. 


   RECOMMENDATIONS
---------------------------------------------------------- Chapter 0:5

GAO recommends that the Secretary of Transportation direct the FAA
Administrator to ensure that a complete ATC systems architecture is
developed and enforced expeditiously and before deciding on the
architectural characteristics for replacing the Host Computer System. 

GAO also recommends that the Secretary of Transportation direct the
FAA Administrator to establish an effective management structure for
developing, maintaining, and enforcing the complete ATC systems
architecture.  Specifically, the Administrator should (1) assign the
responsibility and accountability needed to develop, maintain, and
enforce a complete ATC systems architecture to a single FAA
organizational entity, (2) provide this single entity with the
resources, expertise, and budgetary and/or organizational authority
needed to fulfill its architectural responsibilities, and (3) direct
this single entity to ensure that every ATC project conforms to the
architecture unless careful, thorough, and documented analysis
supports an exception.  Given the importance and the magnitude of the
information technology initiative at FAA, GAO recommends that a
management structure similar to the department-level CIOs as
prescribed in the Clinger-Cohen Act be established for FAA. 


   AGENCY COMMENTS AND GAO'S
   EVALUATION
---------------------------------------------------------- Chapter 0:6

Department of Transportation (DOT) and FAA officials generally agreed
with GAO's conclusions and recommendations, which require FAA to
define and enforce a complete ATC-wide systems architecture.  At the
same time, however, the officials stated that (1) FAA's informal
mechanisms for attaining system compatibility (e.g., informal
communication among system development teams and circulation of
individual system specifications among these teams for review and
comment) are sufficient and are working well; and (2) the
architectural definition efforts underway within both individual
development teams and these teams' parent organizations, which are
described in this report, will effectively augment these informal
processes. 

The many examples provided in this report in which FAA incurs added
costs to compensate for system incompatibilities arising from the
lack of an ATC architecture provide clear evidence that FAA's
informal mechanisms have been neither sufficient nor have been
working well; and there is no logical rationale to support or explain
the position that the efforts of the individual teams will somehow
coalesce into an effective approach to ATC-wide architectural
definition and enforcement.  It is clear that effectively modernizing
a system of systems as technologically complex, expensive,
interdependent, and safety-critical as the ATC system requires more
than stovepipe architectures linked and enforced by informal
communications.  Accordingly, GAO strongly recommends that FAA
formally define and enforce an ATC-wide systems architecture. 


INTRODUCTION
============================================================ Chapter 1

The Federal Aviation Administration's (FAA) primary mission is to
ensure safe, orderly, and efficient air travel in the national
airspace.  FAA's ability to fulfill this mission depends on the
adequacy and reliability of the nation's air traffic control (ATC)
system, a vast network of computer hardware, software, and
communications equipment.\1

Sustained growth in air traffic and aging equipment have strained the
current ATC system, limiting the efficiency of ATC operations.  This
pattern is likely to continue as the number of passengers traveling
on U.S.  airlines is expected to grow from about 580 million in 1995
to nearly 800 million by 2003, an increase of 38 percent. 

To address these trends, in 1981 FAA embarked on an ambitious ATC
modernization program.  FAA estimates that it will spend about $20
billion to replace and modernize ATC systems between 1982 and 2003. 
Our work over the years has chronicled many FAA failures in meeting
ATC projects' cost, schedule, and performance goals.\2 As a result,
we designated FAA's ATC modernization as a high-risk information
technology initiative in our 1995 report series on high-risk
programs.\3


--------------------
\1 The ATC system is a major component of the National Airspace
System (NAS). 

\2 Air Traffic Control:  Status of FAA's Modernization Program
(GAO/RCED-95-175FS, May 26, 1995), Air Traffic Control:  Status of
FAA's Modernization Program (GAO/RCED-94-167FS, April 15, 1994), and
Air Traffic Control:  Status of FAA's Modernization Program
(GAO/RCED-93-121FS, April 16, 1993). 

\3 High-Risk Series:  An Overview (GAO/HR-95-1, February 1995). 


   OVERVIEW OF ATC
---------------------------------------------------------- Chapter 1:1

The ATC system of the late 1970s was a blend of several generations
of automated and manual equipment, much of it labor-intensive and
obsolete.  In addition, FAA forecasted increased future demand for
air travel brought on by airline deregulation of the late 1970s.  At
that time, FAA recognized that it could increase ATC operating
efficiency by increasing automation.  It also anticipated that
meeting the demand safely and efficiently would require improved and
expanded services, additional facilities and equipment, improved work
force productivity, and the orderly replacement of aging equipment. 
Accordingly, in December 1981, FAA initiated its plan to modernize,
automate, and consolidate the existing ATC system by the year 2000. 

This ambitious modernization program includes the acquisition of new
radars and automated data processing, navigation, and communication
equipment in addition to new facilities and support equipment.  The
modernization, including new systems, facility upgrades, and support
equipment is now estimated to cost over $34 billion through the year
2003.  The Congress will have provided FAA with approximately $23
billion of the $34 billion through fiscal year 1997.  The ATC systems
portion alone, excluding facility upgrades and support equipment,
totals over $20 billion of the planned $34 billion investment.  The
$20 billion will provide, in total, about 170 new systems, but
additional systems are being planned through the year 2015.  The
modernization is still far from complete as nearly $6 billion of the
$20 billion still remains to be spent after 1997 on portions of 73
systems. 


      ATC FACILITIES
-------------------------------------------------------- Chapter 1:1.1

Automated information processing and display, communication,
navigation, surveillance, and weather resources permit air traffic
controllers to view key information, such as aircraft location,
aircraft flight plans, and prevailing weather conditions, and to
communicate with pilots.  These resources reside at, or are
associated with, several ATC facilities--the Air Traffic Control
System Command Center (ATCSCC), flight service stations, air traffic
control towers, terminal radar approach control (TRACON) facilities,
and air route traffic control centers (en route centers).  These
facilities' ATC functions are described below. 

  -- The ATCSCC in Herndon, Virginia, coordinates operations between
     the en route centers by combining traffic flow information from
     each.  This information allows the ATCSCC to provide a snapshot
     of the traffic flows across the United States that is in turn
     used to ensure that airports do not exceed capacities. 

  -- About 90 flight service stations provide pre-flight and
     in-flight services, such as flight plan filing and weather
     report updates, primarily for general aviation aircraft. 

  -- Airport towers control aircraft on the ground, before landing,
     and after take-off when they are within about 5 nautical miles
     of the airport, and up to 3,000 feet above the airport.  Air
     traffic controllers rely on a combination of technology and
     visual surveillance to direct aircraft departures and
     approaches, maintain safe distances between aircraft, and
     communicate weather-related information, clearances, and other
     instructions to pilots and other personnel. 

  -- Approximately 180 TRACONs sequence and separate aircraft as they
     approach and leave busy airports, beginning about 5 nautical
     miles and ending about 50 nautical miles from the airport, and
     generally up to 10,000 feet above the ground, where en route
     centers' control begins. 

  -- Twenty en route centers control planes over the continental
     United States in transit and during approaches to some airports. 
     Each en route center handles a different region of airspace,
     passing control from one to another as respective borders are
     reached until the aircraft reaches TRACON airspace.  Most of the
     en route centers' controlled airspace extends above 18,000 feet
     for commercial aircraft.  En route centers also handle lower
     altitudes when dealing directly with a tower, or when agreed
     upon with a TRACON. 

  -- Two en route centers--Oakland and New York--also control
     aircraft over the ocean.  Controlling aircraft over oceans is
     radically different from controlling aircraft over land because
     radar surveillance only extends 175 to 225 miles offshore. 
     Beyond the radars' sight, controllers must rely on periodic
     radio communications through a third party--Aeronautical Radio
     Incorporated (ARINC), a private organization funded by the
     airlines and FAA to operate radio stations--to determine
     aircraft locations.  See figure 1.1 for a visual summary of the
     ATC facilities that control aircraft. 


   Figure 1.1:  ATC Facilities
   That Control Aircraft

   (See figure in printed
   edition.)



   (See figure in printed
   edition.)


      ATC INFRASTRUCTURE IS AN
      ENORMOUS AND COMPLEX SYSTEM
      OF SYSTEMS
-------------------------------------------------------- Chapter 1:1.2

The ability of FAA's systems to interoperate, both within and across
facilities, as one integrated system of systems is essential to ATC
operations.\4 Each of the five facilities highlighted above contain
numerous interrelated systems.  For example, the en route centers
alone rely on over 50 systems to perform mission-critical information
processing and display, navigation, surveillance, communications, and
weather functions.  Examples include the systems that display
aircraft situation data for air traffic controllers, the system that
collects and displays data from various weather sources, radars for
aircraft surveillance, radars for wind and precipitation detection,
ground-to-ground and ground-to-air communications systems, and
systems to back-up primary systems. 

In addition, systems from different facilities also interact with
each other so that together they can successfully execute the total
ATC process.  For example, controllers' displays currently integrate
data on aircraft position from surveillance radars with data on
flight destination from flight planning data systems.  The ability of
these systems to interoperate and continually exchange data in
real-time is safety critical.  Figure 1.2 depicts the five key air
traffic control facilities (left section), the interaction between
systems both within and between facilities (middle section), and the
complexity of the systems associated with just one type of
facility--the en route centers (right section--these systems are
described in appendix I). 


   Figure 1.2:  ATC Infrastructure
   Is a Complex System of Systems

   (See figure in printed
   edition.)



   (See figure in printed
   edition.)



--------------------
\4 Interoperability is the ability of disparate systems to work
together efficiently and effectively over a network. 


      PAST MODERNIZATION EFFORTS
      HAVE BEEN PLAGUED BY
      PROBLEMS
-------------------------------------------------------- Chapter 1:1.3

Over the past 15 years, FAA's modernization program has experienced
substantial cost overruns, lengthy schedule delays, and significant
performance shortfalls.  To illustrate, the long-time centerpiece of
this modernization program--the Advanced Automation System (AAS)--was
restructured in 1994 after estimated costs tripled from $2.5 billion
to $7.6 billion and delays in putting significantly
less-than-promised system capabilities into operation were expected
to run 8 years or more.  Similarly, increases in costs for three
other ATC projects\5 have ranged from 51 to 511 percent, and schedule
delays have averaged almost 4 years.  For example, the per-unit cost
estimate for the Voice Switching and Control System increased 511
percent, and the first site implementation was delayed 6 years from
the original estimate. 

Shortfalls in performance have affected AAS, as well as other
projects.  For example, the critical Initial Sector Suite System
component of AAS, which was intended to replace controllers'
workstations at en route centers, faced so many technical problems
that it was severely scaled back.  In addition, difficulties in
developing the Air Route Surveillance Radar-4 software and
integrating it with other ATC systems delayed its implementation for
years. 

GAO's work over the years has highlighted weaknesses in FAA's
management of the modernization that have caused cost, schedule, and
performance problems.  First, FAA did not historically manage its
acquisition of major systems in accordance with Office of Management
and Budget Circular A-109\6 and its own acquisition policies.  For
example, FAA did not analyze its mission needs, did not adequately
specify ATC systems requirements, and performed flawed or limited
analyses of alternatives for achieving those needs.  This is contrary
to our finding that successful public and private organizations tie
decisions on information technology investments to explicit and
quantifiable mission improvements.\7 Second, some systems did not
meet agency specifications.  Finally, FAA has provided inadequate
oversight of contractor performance.  Additionally, GAO recently
reported that FAA's organizational culture has been an underlying
cause of the agency's acquisition problems, encouraging employee
behavior that did not reflect a strong commitment to mission focus,
accountability, coordination, and adaptability.\8


--------------------
\5 The three projects and their respective percentage change in unit
costs are the Voice Switching and Control System (511 percent), the
Integrated Terminal Weather System (129 percent), and the Aviation
Weather Observing System (51 percent). 

\6 Major Systems Acquisition, Executive Office of the President,
Office of Management and Budget (April 5, 1976). 

\7 Executive Guide:  Improving Mission Performance Through Strategic
Information Management and Technology (GAO/AIMD-94-115, May 1994). 

\8 Aviation Acquisition:  A Comprehensive Strategy Is Needed for
Cultural Change at FAA (GAO/RCED-96-159, August 22, 1996). 


      ATC MODERNIZATION WILL
      PROCEED UNDER NEW
      ACQUISITION MANAGEMENT
      SYSTEM
-------------------------------------------------------- Chapter 1:1.4

Because of the past problems with FAA modernization efforts, the
Congress enacted legislation in October 1995 that directed FAA to
design and implement a new acquisition management system.\9 The Act
directed the FAA to develop and implement an acquisition system that
would address the unique needs of the agency.  At a minimum, the
system was to provide for more timely and cost-effective
acquisitions.  To help achieve this goal, the Act exempted FAA from
most federal procurement and personnel laws and regulations.  On
April 1, 1996, in response to the act, the FAA Administrator began
implementation of FAA's new system. 

The new acquisition management system is intended to improve
coordination and mission focus by strengthening the "front-end" of
the acquisition process.  Specifically, the developers and operators
are expected to work together to analyze mission needs and
alternatives before senior management makes capital investment
decisions and assigns projects to development teams. 


--------------------
\9 Department of Transportation and Related Agencies Appropriations
Act 1996, P.  L.  No.  104-50, sec.  348, 109 Stat.  436, 460 (1995). 


      FAA ORGANIZATIONS
      RESPONSIBLE FOR SYSTEMS
      DEVELOPMENT AND MAINTENANCE
-------------------------------------------------------- Chapter 1:1.5

Two major FAA organizations play key roles in the development and
evolution of ATC systems--the Office of the Associate Administrator
for Research and Acquisitions (ARA) and the Office of the Associate
Administrator for Air Traffic Services (ATS).  Briefly, ARA is
responsible for developing and fielding ATC systems, while ATS is
responsible for operating, maintaining, and enhancing ATC systems. 
Cross-functional integrated product teams (IPT) residing in ARA are
responsible for ATC systems development. 

ARA manages the research, development, and acquisition of
modernization projects.  According to the Associate Administrator for
ARA, only one-half of the total systems development budget is spent
by ARA, while the other one-half is spent by ATS implementing system
enhancements.  Within ARA, two groups are responsible for acquiring
systems, while the others handle cross-cutting management functions
(e.g., budget formulation and program evaluation).  These two groups
are the Office of Systems Development (AUA) and the Office of
Communication, Navigation, and Surveillance Systems (AND). 

Five IPTs reside in AUA and are organized by ATC business areas
(i.e., en route, terminal, weather and flight service, air traffic
management, oceanic).  Five IPTs reside in AND and are organized by
ATC functional areas (i.e., infrastructure, communications,
surveillance, GPS/navigation, aircraft/avionics).  IPTs are
responsible for research, development, and acquisition as well as for
ensuring that new equipment is delivered, installed, and working
properly.  For example, the en route IPT comprises product teams for
the Display Channel Complex Rehost, the Display System Replacement,
the Voice Switching and Control System, and several other en route
systems.  Each IPT includes systems and specialty engineers,
logistics personnel, testing personnel, contract personnel, and
lawyers as well as representatives from the organizations responsible
for operating and maintaining the ATC equipment. 

The second major organization involved with ATC systems is ATS.  ATS
is responsible for directing, coordinating, controlling, and ensuring
the safe and efficient utilization of the national airspace system. 
Organizations within ATS are responsible for planning, operating,
maintaining, and enhancing ATC systems.  Responsibility for managing
projects is transferred from ARA to ATS once a system has been
installed and is operational. 

The FAA Technical Center is the ATC system test and evaluation
facility and supports ATC systems' research, engineering, and
development.  See figure 1.3 for a visual summary of the ATC
modernization management structure. 


   Figure 1.3:  ATC Modernization
   and Maintenance Organizational
   Chart

   (See figure in printed
   edition.)



   (See figure in printed
   edition.)

\a ATS is currently being reorganized. 


   OBJECTIVES, SCOPE, AND
   METHODOLOGY
---------------------------------------------------------- Chapter 1:2

The objectives of our review were to determine (1) whether FAA has a
target architecture(s), and associated subarchitectures, to guide the
development and evolution of its ATC systems, and (2) what, if any,
architectural incompatibilities exist among systems and what is the
effect of these architectural incompatibilities. 

To determine whether FAA has a target architecture(s), and associated
subarchitectures, to guide the development and evolution of its ATC
systems, we

  -- researched current literature and interviewed systems
     architecture experts to identify the key components of a
     complete systems architecture;

  -- analyzed FAA's National Airspace System Architecture (versions
     1.5 and 2.0) and interviewed officials responsible for
     developing this architecture to determine whether the proposed
     systems architecture is complete and comprehensive;

  -- reviewed additional FAA efforts to develop systems
     architectures, including the Corporate Systems Architecture;

  -- interviewed the 10 IPTs responsible for ATC systems development
     to determine how architectural considerations are incorporated
     in development efforts;

  -- reviewed the NAS System Requirements Specification
     (NAS-SR-1000), the NAS Level 1 Design Document (NAS-DD-1000),
     and the NAS System Specification (NAS-SS-1000) to determine
     whether existing guidance constitutes the components of a
     systems architecture;

  -- interviewed ARA organizations responsible for developing
     software, communications, data management, and security guidance
     about existing guidance and efforts to improve this guidance;

  -- interviewed FAA's Chief Information Officer (CIO) to determine
     what role the CIO plays in the development of FAA's systems
     architecture and whether this role is consistent with recently
     passed legislation; and

  -- analyzed FAA's current structure and processes associated with
     architectural development and enforcement. 

To determine what, if any, architectural incompatibilities exist
among systems and what is the effect of these architectural
incompatibilities, we

  -- acquired and analyzed information on the hardware, operating
     systems, application languages, database management,
     communications, and security characteristics of seven existing
     and under development ATC systems to identify architectural
     incompatibilities;

  -- reviewed key technical documents associated with some of these
     systems, including interface control documents and technical
     briefings;

  -- analyzed the cost, schedule, and performance impacts of the
     architectural incompatibilities that exist among ATC systems;

  -- interviewed the Director of Operational Support to obtain ATC
     maintenance concerns and to obtain his opinion about system
     incompatibilities; and

  -- identified the application languages used in 54 operational ATC
     systems. 

We performed our work at the Federal Aviation Administration in
Washington D.C., and the FAA Technical Center in Atlantic City, New
Jersey, from March 1996 through January 1997.  Our work was performed
in accordance with generally accepted government auditing standards. 

Department of Transportation (DOT) and FAA officials, including the
FAA Deputy Director for Architecture and System Engineering, the FAA
Chief Scientist for Software Engineering, and the FAA Chief Engineer
for Air Traffic Systems Development, provided oral comments on a
draft of this report.  Their comments have been addressed in the
Agency Comments and Our Evaluation sections at the end of chapters 3
and 4 and as appropriate in the body of the report. 


SYSTEMS ARCHITECTURE OVERVIEW
============================================================ Chapter 2

Over the last decade, as computer-based systems have become larger
and more complex, the importance of and reliance on systems
architectures has grown steadily.  These comprehensive "construction
plans" or "blueprints" systematically detail the full breadth and
depth of an organization's mission-based modus operandi, first in
logical terms, such as defining business functions, providing
high-level descriptions of information systems and their
interrelationships, and specifying information flows; and second in
technical terms, such as specifying hardware, software, data,
communications, security, and performance characteristics.  Without a
systems architecture to guide and constrain a modernization program,
there is no systematic way to preclude inconsistent system design and
development decisions, and the resulting suboptimal performance and
added cost associated with these incompatible systems.  This is why
leading public and private sector organizations strongly endorse
defining and enforcing systems architectures as an integral and vital
aspect of modernizing their information systems. 


   SYSTEMS ARCHITECTURES HAVE
   EMERGED AS THE CENTERPIECE OF
   SYSTEM DEVELOPMENT PROGRAMS
---------------------------------------------------------- Chapter 2:1

We found that leading organizations in the private sector and in
government use systems architectures to guide mission-critical
systems development and to ensure the appropriate integration of
information systems through common standards.\1 In addition, experts
in academia have also championed the systems architecture approach. 
For example, the Software Engineering Institute (SEI) at Carnegie
Mellon University includes the development and evolution of a systems
architecture as a key process area in its Systems Engineering
Capability Maturity Model (SE-CMM).\2 The SE-CMM states that the
systems architecture should detail both logical and technical system
elements, their relationships, interfaces, and system requirements,
and should guide the system design and implementation. 

Congress has also recognized the importance of systems architectures
as a means to improve the efficiency and effectiveness of federal
information systems by enacting the 1996 Clinger-Cohen Act.  The act,
among other provisions, requires that department-level CIOs develop,
maintain, and facilitate integrated systems architectures. 


--------------------
\1 Executive Guide:  Improving Mission Performance Through Strategic
Information Management and Technology (GAO/AIMD-94-115, May 1994). 

\2 A Systems Engineering Capability Maturity Model\SM , Version 1.1,
Carnegie Mellon University, Software Engineering Institute,
(SECMM-95-01, CMU/SEI-95-MM-003, November 1995). 


   OVERVIEW OF A SYSTEMS
   ARCHITECTURE'S CONTENT
---------------------------------------------------------- Chapter 2:2

Reflecting the general consensus in the industry that large, complex
systems development efforts should be guided by explicit
architectures, in 1992, GAO issued a report defining a comprehensive
framework for designing and developing systems architectures.\3 This
framework divides systems architectures into two principal
components--a logical component and a technical component.  The
logical component is essential to ensure that an agency's information
systems support accomplishing a specific mission(s), while the
technical component provides the detailed guidance needed to develop
and evolve these systems. 

At the logical level, the architecture includes a high-level
description of the organization's mission, functional requirements,
information requirements, systems, information flows among systems,
and interfaces between systems.  The logical architecture is derived
from a strategic information systems planning process that clearly
defines the organization's current and future missions and concepts
of operations.  It then defines the business functions required to
carry out the mission and the information needed to perform the
functions.  Finally, it describes the systems that produce the
information.  An essential element of the logical architecture is the
definition of the component interdependencies (i.e., information
flows, system interfaces).  Once the logical architecture is defined,
an organization knows its portfolio of desired systems and has a
clear understanding of how these systems will collectively carry out
the organization's objectives.  The purpose of the logical
architecture is to ensure that the systems meet the business needs of
the organization. 

The technical level details specific information technology and
communications standards and approaches that will be used to build
systems, including those that address critical hardware, software,
communications, data management, security, and performance
characteristics.  The purpose of the technical architecture is to
ensure that systems are interoperable, function together efficiently,
and are cost-effective over their life cycles (i.e., including
maintenance costs).  Figure 2.1 displays the key logical and
technical components of a systems architecture. 

   Figure 2.1:  Key Logical and
   Technical Components of A
   Systems Architecture

   (See figure in printed
   edition.)


--------------------
\3 Strategic Information Planning:  Framework for Designing and
Developing System Architectures (GAO/IMTEC-92-51, June 1992). 


LACK OF A COMPLETE ATC SYSTEMS
ARCHITECTURE IMPACTS ATC
MODERNIZATION'S COST AND
PERFORMANCE
============================================================ Chapter 3

FAA lacks a complete systems architecture to guide the development
and evolution of its ATC systems modernization.  While FAA has made
good progress over the last 2 years in defining a logical ATC systems
architecture, FAA has not adequately addressed its need for a
technical ATC systems architecture. 

The lack of an ATC systemwide technical architecture has caused, and
will continue to cause, incompatibilities among the ATC systems, such
as differences in communications protocols\1 and application
languages, that require additional development, integration, and
maintenance resources to overcome.  The incompatibilities also make
it difficult to share application software among systems and to
migrate to vendor-independent\2 operating environments, thereby
effectively foreclosing two opportunities to reduce system
development and maintenance costs. 


--------------------
\1 Sets of rules that govern communications among computer systems. 

\2 A vendor-independent environment uses hardware and software with
characteristics that conform to specifications in the public domain
(that is, that are not unique to a particular vendor or group of
vendors). 


   FAA IS MAKING GOOD PROGRESS IN
   DEFINING A LOGICAL ATC SYSTEMS
   ARCHITECTURE
---------------------------------------------------------- Chapter 3:1

FAA is currently defining a logical ATC systems architecture that
describes FAA's concept of operations, business functions, high-level
descriptions of information systems and their interrelationships, and
information flows among systems.  This high-level systems blueprint
provides a roadmap that is to guide ATC systems over the next 20
years. 


      FAA'S NATIONAL AIRSPACE
      SYSTEM ARCHITECTURE INCLUDES
      A BROAD-BASED AND
      EVOLUTIONARY LOGICAL ATC
      ARCHITECTURE
-------------------------------------------------------- Chapter 3:1.1

FAA is defining a comprehensive and evolutionary logical ATC systems
architecture in its National Airspace System (NAS) architecture. 
Among other things, the architecture provides a description of the
future aviation, air traffic management, and air navigation system in
terms of services, functions, and ATC systems.  Specifically, it
describes FAA's concepts of operations, requirements in terms of the
business functions to be performed, associated systems to be used,
the relationships between these functions and systems, the
information needed to perform these functions, and the flow of
information among the functions and systems.  In addition, it
provides a roadmap for evolving the ATC systems through the year
2015. 

The goals of the logical architecture are to (1) provide the aviation
community with a cohesive and collaborative means to influence the
NAS evolution, (2) provide a foundation for FAA acquisition
decisions, and (3) provide the aviation community with insight into
the timing of major changes to NAS.  According to FAA, the NAS
architecture is intended to eliminate "stovepiped" development by
defining an evolution towards target architectures that represent
coordinated and integrated operational concepts and a comprehensive
system of systems view.  The NAS architecture is not intended to
provide the details needed to actually design and build these systems
(i.e., details that would be provided by the technical architecture). 

FAA issued version 2.0 of the NAS architecture in October 1996 and
subsequently released it for industry and government comment.  The
first complete version of the architecture is scheduled to be
completed in December 1997. 


      SUMMARY OF THE NAS
      ARCHITECTURE'S FIVE
      PRINCIPAL COMPONENTS
-------------------------------------------------------- Chapter 3:1.2

The NAS architecture is divided into five key parts--concepts of
operations, service and functional requirements, systems and
programs, roadmap, and issues.  Each is briefly discussed below.\3

  -- Concepts of Operations:  This section describes an evolving
     series of concepts of operations through the year 2015 and
     emphasizes the migration to a free-flight environment.  The
     current concept of operations relies on analog voice
     communications between controllers and pilots, and ground-based
     radar surveillance to control aircraft.  A free-flight
     environment is one in which the pilots are free to select their
     own routes and speed in real time.  In this environment, air
     traffic restrictions would be imposed only to ensure minimum
     aircraft separation, preclude exceeding airport capacity,
     prevent unauthorized flight through special-use airspace, and
     ensure safety.  A free-flight environment relies less on voice
     communications and ground-based radar systems and more on
     aircraft position displays in the cockpit and satellite
     surveillance and navigation technologies, such as the Global
     Positioning System (GPS).  The transition from the current to
     the free-flight concept of operations will be evolutionary. 
     Mid-term concepts of operations will define FAA's evolution
     methodically and gradually to a free-flight environment. 

  -- Service and Functional Requirements:  This section describes
     services and associated functional requirements that are
     required to carry out the concepts of operations.  The service
     requirements include air traffic (i.e., flight planning, flight
     support, aircraft navigation and guidance, traffic management,
     separation, data information management, and communication
     management), airport, security, safety, certification,
     infrastructure, and administrative and acquisition support
     services.  These service requirements are further broken down by
     functional requirements (e.g., provide forecasted weather
     information, provide air traffic flow information) and specify
     existing systems and describe future NAS systems (e.g., Host
     Computer System and Display System Replacement, respectively). 

  -- Systems and Programs:  This section describes the systems
     associated with each functional area (i.e., communications,
     weather, automation, surveillance, maintenance and support,
     navigation) and business area (i.e., en route, terminal, tower,
     oceanic, air traffic management) of the proposed architecture. 
     For each of the functional areas the following information is
     provided:  (1) listing of systems through the year 2015, (2)
     current programs and schedules from the Capital Investment Plan
     (CIP) and the Research, Engineering, and Development (RE&D)
     plan, and (3) transition strategy and diagrams.\4 In addition,
     this section provides systems drawings (i.e., high-level wiring
     diagrams) of the various business areas for the 1995 and 2005
     time frames.  Appendix I provides a simplified block diagram for
     the near- and mid-term en route business area's systems
     environment, which is very complex (i.e., includes many systems
     that interact in many ways). 

  -- Roadmap:  This section provides a transition plan for replacing
     systems, replacing existing infrastructure, and introducing new
     capabilities.  The NAS architecture roadmap presents a proposed
     architecture in several functional areas (e.g., navigation,
     surveillance) and describes a transition strategy to migrate
     from the current systems environment to the proposed
     architecture.  For example, for the navigation functional area,
     it describes a gradual transition strategy to a satellite-based
     navigation system.  Specifically, it describes the deployment
     schedule for the primary system, Wide Area Augmentation System
     (WAAS), the schedule for decommissioning existing systems, and
     the additional system deployment schedules to support the
     far-term concept of operations.  The roadmap describes the
     changes in ATC systems through time as they evolve to support
     free-flight. 

  -- Issues:  This section provides a collection of papers on
     outstanding issues whose resolutions should have the greatest
     potential impacts on the future of ATC systems.  These issues
     are the "forks in the road" where a decision is needed to define
     a particular roadmap to the future.  For example, one paper
     presents a series of unanswered questions on performance and
     backup requirements for future ATC surveillance.  Another
     recommends the need for a free-flight action plan that is to
     guide FAA's transition to a free-flight environment. 

The interrelationships among the NAS architecture's services,
functional areas, and associated systems are quite complex, as any
one system may support multiple functional and service areas.  For
example, the Host Computer System (HCS) is an automation system
located in the en route facilities that supports several business
areas ( i.e., the en route business area by processing data from many
different radar systems and air traffic management (ATM) business
area by providing flight track data to select ATM systems).  Figure
3.1 shows the relationships between the NAS architecture air traffic
services, business areas, functional areas, and related systems. 

   Figure 3.1:  NAS Architecture
   Air Traffic Services, Business
   Areas, Functional Areas, and
   Related Systems

   (See figure in printed
   edition.)



--------------------
\3 This summary is based on version 1.5 of the NAS Architecture,
which was issued in March 1996.  Version 2.0 descriptions of these
five parts are consistent with this summary. 

\4 The CIP and RE&D plans provide lists of ongoing and future
projects scheduled for development and research respectively.  Both
are updated annually. 


   FAA HAS NO TECHNICAL SYSTEMS
   ARCHITECTURE
---------------------------------------------------------- Chapter 3:2

FAA's efforts to develop and evolve its "system of ATC systems" is
not guided and constrained by an ATC-wide technical architecture, and
FAA does not have an effective strategy for developing one.  In 1995,
FAA recognized the importance of such an architecture by including
the development of an FAA corporate architecture in its 1996 Capital
Investment Plan.  However, FAA decided to drop this effort from FAA's
1997 plan in favor of other investment priorities.  As a result, the
IPTs have been left to proceed individually in setting architectural
standards and developing and evolving systems.  This has resulted in
three IPTs cooperatively developing similar but not identical
architectures for their respective areas, while others are proceeding
without one.  At the same time, still other FAA organizations are
independently attempting to develop pieces (e.g., software guidance,
security guidance) of a technical architecture, but these efforts are
not coordinated and neither individually nor collectively constitute
a complete ATC-wide technical architecture.  Without an ATC-wide
technical architecture, FAA's ATC systems have and will continue to
suffer from costly and inefficient incompatibilities. 


      PAST EFFORT TO DEVELOP A
      TECHNICAL SYSTEMS
      ARCHITECTURE WAS ABANDONED
-------------------------------------------------------- Chapter 3:2.1

The concept of a technical systems architecture is not new to FAA. 
In FAA's January 1996 Capital Investment Plan, FAA planned to develop
a technical architecture, called the corporate systems architecture
(CSA).  According to FAA plans, the CSA was to be a blueprint for
achieving an open systems environment\5 and was to be used to "guide,
coordinate, and integrate the acquisition, development and
implementation of automated data processing equipment,
telecommunications, automated information systems and data bases, and
associated support services" across FAA.  However, the CSA effort was
abandoned in favor of other funding priorities.  FAA's CIO, who was
tasked to develop the CSA, told us that the CSA was not funded in
1996 because its sponsors and developers could not convince FAA top
management of its importance in providing benefits like cheaper
development, integration, and maintenance costs, and better systems
performance. 


--------------------
\5 An open systems environment is one that is based on
vendor-independent, publicly available standards.  An open system
environment supports portable and interoperable applications through
standard services, interfaces, data formats, and protocols. 


      IPT ARCHITECTURAL EFFORTS
      ARE LIMITED AND DO NOT
      CONSTITUTE AN ATC-WIDE
      TECHNICAL ARCHITECTURE
-------------------------------------------------------- Chapter 3:2.2

In the absence of an overall ATC technical systems architecture, the
IPTs are left to their own devices in formulating guidance to build
systems.  As a result, three IPTs have cooperatively developed
similar but not identical technical architectures.  The other seven
IPTs are developing ATC systems, which include such major systems as
the Standard Terminal Automation Replacement System (STARS) and the
Wide Area Augmentation System (WAAS), without a technical
architecture.  (See figure 3.2 for a summary of architectural
guidance used by the 10 IPTs.)

With respect to the latter seven, officials for one IPT could not
cite any technical architectural guidance being used, while officials
for another IPT cited the NAS architecture, and officials for the
other five cited the NAS "1,000-series" documents.\6

However, neither the NAS architecture nor the NAS "1,000 series"
constitutes a technical architecture.  The NAS architecture is a
logical architecture that provides no technical details, and the NAS
"1,000 series" documents are neither a logical nor technical
architecture.  In fact, the Deputy Director for the Office of System
Architecture and Investment Analysis, stated that the NAS "1,000
series" documents are "shelfware" and not useful in guiding future
systems development.  In commenting on a draft of this report,
Systems Architecture and Investment Analysis officials stated that
they plan to issue a revision to the NAS "1,000 series" documents in
October 1997. 

Each of the three IPTs using their own, cooperatively developed
technical architectures are described below. 

  -- ATM IPT:  This IPT was the first to develop a technical
     architecture, which is called the ATM Domain Environment
     Definition Document.  It provides guidelines and standards for,
     among other things, operating systems, communication protocols,
     data management, security, coding, and testing.  ATM officials
     stated that they created this document to facilitate system
     integration and ATM software application migration among the
     systems they are developing, which include the Traffic
     Management System (TMS) and the Center TRACON Automation System
     (CTAS). 

  -- En route IPT:  This IPT's architecture governs development of
     such systems as the Display System Replacement (DSR) and the
     Host Interface Device/Local Area Network (HID/LAN).  The
     architecture contains a systems development model and a
     standards profile, including data interchange, communications,
     security, and programming language standards. 

  -- Infrastructure IPT:  This IPT's architecture is for its NAS
     Infrastructure Management System (NIMS), which is this IPT's
     primary system.  The NIMS architecture includes both logical and
     technical components.  It includes a standards profile that
     contains the same general categories of standards as the ATM and
     en route technical architectures. 

While the three IPTs tried to achieve architectural compatibility,
they have not been fully successful.  For example, all three
architectures specify C and C++ as acceptable programming languages,
but the en route architecture also specifies Ada as an acceptable
language.  Also, although the ATM, en route, and infrastructure
architectures all specify compliance to the Structured Query Language
(SQL)-92 to access data, the en route architecture acknowledges that
the SQL-92 standard will have to be modified at times to meet FAA's
real-time, mission-critical requirements.  Currently, FAA has no plan
for doing this consistently across all three systems environments. 
Further, the ATM technical architecture specifies the ethernet
protocol and the en route architecture specifies the Fiber
Distributed Data Interface (FDDI) protocol.  These two protocols are
not compatible.  FAA officials told us that they are aware of
inconsistencies and that they plan to resolve them, but have not
defined the plan, scheduled its implementation, or allocated
resources for the effort. 


   Figure 3.2:  Architecture
   Guidance Used by the 10 IPTs to
   Guide Ongoing and Future
   Development

   (See figure in printed
   edition.)

\a Four of these five IPTs mentioned additional guidance that will
supplement the "1,000 series" documents.  This additional guidance
included the NAS architecture, international standards/agreements,
interface requirements documents and standards referenced in system
specifications, and FAA's Strategic Plan, Capital Investment Plan,
Communications System Plan, Telecommunications Strategic Plan, and
system/interface/operational requirements documents.  None of these,
either collectively or individually, provide the technical systems
architecture details that are necessary to guide ATC systems
development. 


--------------------
\6 The NAS "1,000 series" documents include the NAS System
Requirements Specification (NAS-SR-1000), the NAS Level 1 Design
Document (NAS-DD-1000), and the NAS System Specification
(NAS-SS-1000).  These documents reflect the NAS requirements
baseline, the NAS allocated baseline, and the NAS system design,
respectively. 


      OTHER ATC MODERNIZATION
      ORGANIZATIONS HAVE BEGUN TO
      DEVELOP PARTS OF OPTIONAL
      TECHNICAL SYSTEMS
      ARCHITECTURES
-------------------------------------------------------- Chapter 3:2.3

In addition to these IPT-specific technical architectures, three
other ARA offices (i.e., Office of Systems Architecture and
Investment Analysis, Office of Information Technology, Acquisition
Policy Branch) have initiated efforts that relate to, but neither
individually nor collectively constitute a complete technical
architecture.  These efforts have begun to address data management,
security, and software process and product standards; however, they
are limited in scope, are incomplete, and will not be mandated for
use across all ATC systems.  Each is discussed below. 

  -- The Office of Systems Architecture and Investment Analysis is
     adding a draft section on data management to the logical
     architecture that describes the current state of data exchange
     between ATC systems.  However, this section does not define
     specific standards (e.g., standards for data elements and naming
     conventions), and FAA officials have not established milestones
     for doing so.  This office is also planning to develop guidance
     addressing how security controls (e.g., hardware and software
     solutions) will be implemented to satisfy security requirements. 
     However, this effort has not been approved by FAA management,
     and therefore remains unfunded.  Also, this office has created a
     menu of architectural standards (e.g., data management, data
     interchange, communication protocol, application development,
     and security standards) to increase IPTs' awareness of what
     standards exist for the IPTs to use at their own discretion. 

  -- The Office of Information Technology is initiating efforts to
     improve software acquisition processes, has trained the IPTs on
     software process improvement, and has established a Software
     Engineering Process Group to champion process improvement
     activities.  However, these initiatives do not specify software
     product standards, such as standard programming languages and
     development tools, or standards for software structure, both of
     which are critical to modernizing ATC systems cost effectively. 
     Moreover, FAA cannot yet demonstrate specific and measurable
     process improvements. 

  -- The Acquisition Policy Branch has begun an initiative to develop
     systems engineering guidance for IPTs' optional use.  Because
     this guidance is early in its development and a complete draft
     does not yet exist, FAA would not provide us a copy for review. 


   LACK OF A TECHNICAL SYSTEMS
   ARCHITECTURE MEANS COSTLY
   SYSTEM INCOMPATIBILITIES
---------------------------------------------------------- Chapter 3:3

The lack of a complete systems architecture has produced
architectural differences and incompatibilities among ATC systems,
such as different communication protocols and proprietary operating
environments, and will continue to do so for future systems. 
(Examples of these differences for key systems in the current and
near-term en route environment are provided in appendix II.) Further,
the significance of these incompatibilities will increase as FAA
moves to a more networked systems environment.  Overcoming these
incompatibilities means "higher than need be" system development,
integration, and maintenance costs, and reduced overall systems
performance.  Additionally, because many existing systems are largely
proprietary, opportunities for application software reuse among
systems is effectively precluded and options for migrating
applications to new hardware and software platforms are restricted. 


      HETEROGENOUS COMMUNICATIONS
      PROTOCOLS AND DATA FORMATS
      REQUIRE EXPENSIVE SYSTEM
      INTERFACES
-------------------------------------------------------- Chapter 3:3.1

A system interface is hardware and software that acts as an
interpreter to interconnect different systems and allow for the
exchange of data.  The more similar the communications and data
features of the systems that are to communicate, the less complicated
this interface.  Conversely, the more disparate the systems, the more
complicated the interface.  Communications and data management
subarchitectures are essential to standardize communication protocols
and data formats, respectively, so that system interfaces are less
costly and easier to implement. 

As described in chapter 1, system interoperability in the ATC system
of systems is essential for FAA to successfully perform its mission. 
However, fundamental differences in how the systems communicate have
made exchanging data between systems more difficult and expensive
because it requires the development and maintenance of costly
interfaces to interconnect systems.  This can be seen in the en route
business area, where a system known as the Peripheral Adapter Module
Replacement Item (PAMRI) operates as a collection of systems
interfaces.  Specifically, PAMRI's primary function is to convert
differing protocols from feeder systems, like aircraft surveillance
radars and weather detection systems, so that data from these systems
can be used by the Host Computer System (HCS), the centerpiece
information processing system in the en route centers.\7 To perform
this function, FAA spent over $38 million\8 to develop PAMRI and it
spends millions\9 annually to maintain it. 

In addition to protocol conversion, PAMRI also performs data
conversion of its disparate feeder systems.  This conversion is
necessary to remedy the data inconsistencies among ATC systems that
feed HCS.  These data inconsistencies extend beyond just those
systems that interface with HCS.  For example, FAA has hired a
contractor to write an interface so that the Center TRACON Automation
System (CTAS) can talk to the Automated Radar Terminal System (ARTS)
IIIE.\10 The cost of this interface is estimated at $1 million.  In
effect, this interface is a "mini-PAMRI."

Although some of the systems incompatibilities arise from the fact
that FAA's current ATC systems span several generations of computer
systems, other incompatibilities are the result of FAA's failure to
adopt and enforce a systems architecture.  According to a July 1996
FAA report baselining the ATC data management environment,\11 ATC
data inconsistencies have resulted from a lack of data standards and
policies across the ATC systems. 


--------------------
\7 FAA plans to begin replacement of the Host Computer System in
fiscal year 1999. 

\8 This cost does not include FAA internal costs (e.g., project
management, testing) associated with acquiring PAMRI because FAA was
unable to provide these costs. 

\9 FAA could not provide the full cost of maintaining PAMRI. 
Instead, FAA officials stated that about $200,000 is spent annually
to maintain PAMRI hardware, and about $500,000 is spent annually to
maintain PAMRI software at three sites.  However, they could not
provide the annual cost to maintain PAMRI software at the other 26
sites where PAMRI is operational.  We did not evaluate these costs. 

\10 CTAS performs flight arrival scheduling.  To do this, it must
receive flight track data from ARTS IIIE. 

\11 Analysis of Current Information Management Practices for
Representative Systems Across NAS Domains (Draft), MITRE, July 1996. 


      MYRIAD OF APPLICATION
      LANGUAGES MAKES MAINTENANCE
      MORE COSTLY AND DIFFICULT
-------------------------------------------------------- Chapter 3:3.2

Systems written in many application programming languages are more
difficult and expensive to modify and maintain than systems written
in fewer languages.  For example, for each language, programming
staff must be trained and provided support software (compilers,
debuggers, program libraries, etc.),\12 and both the training and
suite of support software must be updated and maintained.  A software
subarchitecture is essential to standardize the languages to be used
and to institutionalize process standards or methodologies for
designing, coding, testing, and documenting software projects. 

Software applications associated with 54 operational ATC systems have
been written in 53 programming languages (these 53 include 19
assembly languages).\13 Since most of the ATC languages are obsolete,
there is no readily available cadre of newly trained programmers and
current and future maintenance becomes even more difficult and
costly.  For example, the Automated Radar Terminal Systems (ARTS) are
written in Ultra, an obsolete assembly language.  Furthermore, no
restrictions are currently being placed on application language
choices for new systems development.  For example, a new system that
is currently being developed, the Display System Replacement (DSR),
is to be written in three programming languages--Ada, C, and
assembly.  Ada is not used in any other existing ATC system. 

AUA officials told us that the five AUA IPTs are primarily using C,
C++, and Ada to develop new ATC systems.  However, we found three
additional languages and several versions of assembly language also
being used to develop new ATC systems. 

Software maintenance is a significant FAA expense.  To illustrate,
the software for the Host Computer System (HCS), its backup--the
Enhanced Direct Access Radar Channel (EDARC)--and PAMRI cost $63.6
million annually to maintain.\14 Until a software subarchitecture is
developed that is based on a systematic analysis of the needs of
current and planned operating environments and defines the languages
to be used in developing ATC systems, FAA will continue to experience
language proliferation and be faced with difficult and costly
software maintenance. 


--------------------
\12 A compiler is a program that translates the source code written
by the programmer into object code that can be executed.  A debugger
is a program that aids in identifying and correcting program errors. 
A program library is a collection of routines that a programmer can
use, as needed, without having to write them anew. 

\13 Assembly is a low-level programming language in which each
statement corresponds directly to a single machine instruction and is
thus specific to a given processor.  Assembly languages are used by
FAA to meet their stringent real-time requirements.  Although modern
compilers associated with high-order languages (e.g., C, C++) are
capable of meeting some real-time requirements, many are not
available for FAA's legacy systems with unique operating systems and
others do not meet FAA's stringent reliability and fault tolerant
requirements. 

\14 The $63.6 million includes $22.6 million for FAA software
maintenance and $41 million for contracted software maintenance. 


      ATC MODERNIZATION PLANS FOR
      EVOLVING TO AN OPEN SYSTEMS
      ENVIRONMENT REQUIRE A
      RIGOROUSLY DEVELOPED AND
      COMPLETE SYSTEMS
      ARCHITECTURE
-------------------------------------------------------- Chapter 3:3.3

FAA plans to migrate its highly proprietary ATC systems to open
operating environments.  An open environment is one that is based on
vendor-independent, publicly available standards.  If properly
planned and implemented, an open system environment supports portable
and interoperable applications through standard services, interfaces,
data formats, and protocols.  Although the plan to evolve to an open
environment is a wise one, important choices have to be made
consistently across ATC systems to derive the expected benefits
(e.g., portable applications, system interoperability).  In
particular, the open system standards for the collective system of
systems must be carefully and thoroughly analyzed in light of
systemwide requirements, and the most appropriate standards must be
selected.  The rigor associated with developing a systems
architecture can ensure such analysis. 

Currently, this systemwide analysis is not occurring.  Instead, most
of the IPTs that are implementing open systems standards are doing so
independently.  Such a nonstandard migration approach may result in
different open system options being selected, perpetuating
architectural incompatibilities that require additional costs to
overcome.  For example, future FAA systems are to provide information
to controllers through networked workstations.  Two open systems
protocol standards that IPTs could independently choose for passing
information--ethernet and token-ring--are incompatible. 

Evolution to an open systems environment would also allow FAA to
share software among systems with common functionality.  For
instance, FAA officials told us that 40 percent of the en route
flight data processing (FDP) functionality is identical to the
oceanic FDP functionality.\15 This 40 percent equates roughly to
about 60,000 lines of code.  To their credit, FAA officials told us
that the oceanic and en route IPTs have agreed to look at
opportunities to share software between the replacement systems that
perform FDP functions.  However, without a guiding systems
architecture that specifies specific open systems standards, FAA will
likely not develop the oceanic and en route replacement systems that
are to perform the FDP functions to common standards, thus precluding
the opportunity to share software components. 


--------------------
\15 Currently, the HCS performs FDP functions in the en route
business area and the Oceanic Display and Planning System (ODAPS)
performs FDP in the oceanic business area.  In the future, the
HCS-Replacement and the Advanced Oceanic Automation System (AOAS)
will perform the FDP functions in their respective environments. 


   CONCLUSIONS
---------------------------------------------------------- Chapter 3:4

Because it has no complete and comprehensive systems architecture to
guide and constrain the ATC systems modernization program, FAA
continues to spend nearly $2 billion annually on "stovepipe" systems
in an environment where system interoperability is an absolute
necessity.  To achieve interoperability, FAA is forced to develop and
maintain costly system interfaces and incurs higher than need be
system development and maintenance costs and reduced systems
performance. 


   RECOMMENDATION
---------------------------------------------------------- Chapter 3:5

We recommend that the Secretary of Transportation direct the FAA
Administrator to ensure that a complete ATC systems architecture is
developed and enforced expeditiously and before deciding on the
architectural characteristics for replacing the Host Computer System. 


   AGENCY COMMENTS AND OUR
   EVALUATION
---------------------------------------------------------- Chapter 3:6

In commenting on a draft of this report, DOT and FAA officials
generally agreed with our recommendation, which requires FAA to
define and enforce a complete ATC-wide systems architecture.  At the
same time, however, the officials stated that (1) FAA's informal
mechanisms for attaining system compatibility (e.g., informal
communication among system development teams and circulation of
individual system specifications among these teams for review and
comment) are sufficient and are working well; and (2) the
architectural definition efforts underway within individual
development teams and these teams' parent organizations, once
completed, will effectively augment these informal processes. 

The many examples provided in the report in which FAA incurs added
costs to compensate for system incompatibilities arising from the
lack of an ATC architecture provide clear evidence that FAA's
informal mechanisms are neither sufficient nor working well; and
there is no logical rationale to support or explain FAA officials'
view that the efforts of the individual teams will somehow coalesce
into an effective approach to ATC-wide architectural definition and
enforcement.  It is clear that effectively modernizing a system of
systems as technologically complex, expensive, interdependent, and
safety-critical as the ATC system requires more than stovepipe
architectures linked and enforced by informal communications. 
Accordingly, we strongly recommend that FAA formally define and
enforce an ATC-wide systems architecture. 

The officials also stated that most of FAA's legacy systems pre-date
the advent of architectural standards, and that it is thus system age
rather than FAA's lack of a systems architecture that is primarily to
blame for existing system incompatibilities.  As stated explicitly in
the report, some incompatibilities exist because some systems
pre-date currently available technology and standards.  However,
other system incompatibilities are the result of FAA's failure to
adopt and effectively enforce a technical architecture.  Furthermore,
until FAA completes and enforces its systems architecture, similar
incompatibilities will recur in new ATC systems. 

The officials also commented that formally prescribed and enforced
architectural standards could inhibit product team flexibility and
creativity in acquiring ATC systems.  They added that while they
support the use of standards and are trying to move in that
direction, they prefer a less formal approach to standards
implementation and enforcement.  This position has no merit.  A well
planned architecture that is enforced in a thoughtful and disciplined
manner ensures compatibility and interoperability among different
systems without unduly constraining internal system characteristics. 
The lack of such an architecture fosters not innovation but
incompatibility and waste. 


FAA LACKS AN EFFECTIVE MANAGEMENT
STRUCTURE AND PROCESS TO DEVELOP
AND ENFORCE A SYSTEMS ARCHITECTURE
============================================================ Chapter 4

FAA's current approach to ATC architectural development, maintenance,
and enforcement is not effective.  The office that is responsible for
developing and maintaining the NAS, or logical systems architecture,
has no budgetary or organizational authority to enforce it, and no
FAA organizational entity is responsible for developing and enforcing
an ATC-wide technical architecture.  As a result, ATC projects can be
funded that do not comply with the ATC logical architecture
(deviations are not supported by a documented waiver justifying the
noncompliance) and there is no complete ATC technical architecture. 
Until FAA assigns a single organizational entity the responsibility
and authority needed to develop, maintain, and enforce an ATC logical
and technical systems architecture, FAA will not effectively address
ATC system incompatibilities. 


   FAA LACKS AN EFFECTIVE
   MANAGEMENT STRUCTURE TO
   DEVELOP, MAINTAIN, AND ENFORCE
   A SYSTEMS ARCHITECTURE
---------------------------------------------------------- Chapter 4:1

If a complete systems architecture is to be effectively developed,
maintained, and enforced, some organizational entity must (1) be
assigned the responsibility and be held accountable for doing so, (2)
be given sufficient resources to accomplish the task, (3) have
expertise in information technology, and (4) have organizational
and/or budgetary authority over all systems development and
maintenance activities.  One model for implementing this is embodied
in the Clinger-Cohen Act,\1 which requires that major federal
departments and agencies establish CIOs that report to the
department/agency head and are responsible for developing,
maintaining, and facilitating the implementation of systems
architectures. 


--------------------
\1 The 1996 Clinger-Cohen Act, P.  L.  No.  104-106, section 5125,
110 Stat.  684 (1996). 


      FAA'S LOGICAL ARCHITECTURE
      MANAGEMENT STRUCTURE IS NOT
      EFFECTIVE
-------------------------------------------------------- Chapter 4:1.1

FAA does not have an effective management structure for developing,
maintaining, and enforcing a logical ATC systems architecture.  The
Office of Systems Architecture and Investment Analysis, which is
under the Associate Administrator for Research and Acquisitions, is
responsible for developing and maintaining the logical ATC
architecture (i.e., the NAS architecture), and has made good progress
over the last 2 years in developing and maintaining one (see chapter
3).  However, this office is not responsible for enforcing the
logical architecture and cannot enforce it because it has neither
organizational nor budgetary authority over the IPTs that develop ATC
systems or the units that maintain them.  (See figure 4.1 for the
Office of Systems Architecture and Investment Analysis'
organizational position in relation to the Administrator, CIO, IPTs,
and maintenance activities.)


   Figure 4.1:  Office of Systems
   Architecture and Investment
   Analysis' Relative
   Organizational Position

   (See figure in printed
   edition.)



   (See figure in printed
   edition.)

\a ATS is currently being reorganized. 

FAA officials say that they use the capital investment planning
process to enforce the logical architecture.  Under this process,
various FAA organizations, including the CIO, evaluate and compare
competing NAS projects and choose projects to be funded.  Four
criteria are considered in scoring competing investment options and
deciding among them:  (1) sponsor (i.e., user) support; (2) mission
importance; (3) technology maturity/NAS architecture conformance; and
(4) cost effectiveness.  Each criterion carries a standard weighting
factor that is to be consistently applied to all proposed projects in
producing a project score:  sponsor support and technology
maturity/NAS architecture conformance each carry a weight of 20
percent, while mission importance and cost effectiveness each carry a
weight of 30 percent.  According to FAA, projects that do not conform
to the NAS architecture can be approved under this process.  While
deviations from the architecture may sometimes be warranted, the
decision to waive the requirement for architectural conformance
should be made only after careful, thorough, and documented analysis. 
FAA's investment process does not require such analysis. 

FAA has drafted new acquisition management guidance that modifies the
above described capital investment planning process.  FAA officials
stated that the new process will require that ATC projects conform to
the logical architecture and that waivers to this requirement will be
granted only with convincing and documented justification.  This is
not the case.  The draft guidance permits each team to choose its
investment criteria and does not even require that architectural
conformance be among them.  As a result, this draft guidance does not
constitute an effective approach to architectural enforcement. 


      FAA'S TECHNICAL ARCHITECTURE
      MANAGEMENT STRUCTURE IS NOT
      EFFECTIVE
-------------------------------------------------------- Chapter 4:1.2

FAA also lacks an effective management structure for developing,
maintaining, and enforcing a technical ATC systems architecture.  No
organization in FAA is responsible for technical ATC architecture. 
Instead, FAA has permitted a "hodge podge" of independent efforts
scattered across its ATC modernization organization to emerge with no
central guidance and coordination.  For example, the Office of
Systems Architecture and Investment Analysis is developing systems
security guidance and a menu of architectural standards, while other
offices have initiated efforts to develop additional technical
architecture guidance (see chapter 3).  As a result, there is no
ATC-wide technical architecture, and it is unlikely that FAA will
produce one in the near future. 


   CONCLUSIONS
---------------------------------------------------------- Chapter 4:2

Until the authority, responsibility, and resources to develop,
maintain, and enforce a complete ATC systems architecture are clearly
assigned to a single FAA organizational entity, FAA will continue to
build incompatible and unnecessarily expensive and complex ATC
systems. 


   RECOMMENDATION
---------------------------------------------------------- Chapter 4:3

We recommend that the Secretary of Transportation direct the FAA
Administrator to establish an effective management structure for
developing, maintaining, and enforcing the complete ATC systems
architecture.  Specifically, the Administrator should (1) assign the
responsibility and accountability needed to develop, maintain, and
enforce a complete ATC systems architecture to a single FAA
organizational entity, (2) provide this single entity with the
resources, expertise, and budgetary and/or organizational authority
needed to fulfill its architectural responsibilities, and (3) direct
this single entity to ensure that every ATC project conforms to the
architecture unless careful, thorough, and documented analysis
supports an exception.  Given the importance and the magnitude of the
information technology initiative at FAA, we recommend that a
management structure similar to the department-level CIOs as
prescribed in the Clinger-Cohen Act be established for FAA. 


   AGENCY COMMENTS AND OUR
   EVALUATION
---------------------------------------------------------- Chapter 4:4

In commenting on a draft of this report, DOT and FAA officials
generally agreed with our conclusions and recommendations.  However,
the FAA Deputy Director for Architecture and System Engineering
stated that FAA is drafting a revision to its investment management
policy that, once approved, will change the capital investment
planning process and associated investment decision criteria
described in our report.  Our review of this draft guidance disclosed
that it does not require that every ATC project conform to the
logical architecture.  Instead, the draft guidance permits each team
to choose its investment criteria and does not require that
architectural conformance be among them. 


SIMPLIFIED BLOCK DIAGRAMS FOR THE
NEAR-TERM AND MID-TERM EN ROUTE
CENTERS' SYSTEMS ENVIRONMENT
=========================================================== Appendix I

   Figure I.1:  Near-Term
   Environment

   (See figure in printed
   edition.)

Explanatory Notes to Simplified Block Diagram for the Near-term En
Route Centers' Systems Environment

                     (Systems Within the En Route Center and
                                 Their Functions)

----------  ------------------  ------------------------------------------------
ADAS        AWOS Data           Collects surface observations data from AWOS and
            Acquisition System  ASOS and distributes these data to weather
                                processing and display systems.

AMCCWS      ARTCC (Air Route    Provides capability for real-time and nonreal-
            Traffic Control     time monitoring of en route center systems,
            Center)             remote control of equipment and facilities,
            Maintenance         communications/coordination, and system
            Control Center      security.
            Workstation

BUEC        Backup Emergency    Provides backup air-to-ground radio voice
            Communications      communications service in the event of a failure
                                of the primary or secondary air-to-ground radio
                                system.

CCU         Central Control     Provides flight data input/output print
            Unit                capability.

CDC         Computer Display    Provides display capability that will be
            Channel             replaced by DSR.

CRD         Computer Readout    Provides display capability that will be
            Display             replaced by DSR.

DCC         Display Channel     Provides display capability that will be
            Complex             replaced by DCCR, which will in turn be replaced
                                by DSR.

DCCR        Display Channel     Provides display capability that will replace
            Complex Rehost      DCC.

DG          Display Generator   Provides character and image display capability
                                that will be replaced by DSR.

DMN         Data Multiplexing   Provides an inter-facility multiplexed data
            Network             transmission network.

DSRCE       Down-Scoped Radio   Controls local and remote air-to-ground radios.
            Control Equipment

DVRS        Digital Voice       Make legal recordings of all voice
            Recorders           communications between air traffic controllers
                                and pilots.

EDARC       Enhanced Direct     Provides a backup to HCS for radar processing,
            Access Radar        and radar track and display processing.
            Channel

FDIO        Flight Data Input/  Provides flight data input/output capability by
            Output              transferring flight data inter-/intrafacility.

FSDPS       Flight Service      Provides the processing capability to support
            Data Processing     AFSS workstations and automated pilot briefings,
            System              and maintains a national flight service
                                database.

HCS         Host Computer       Processes radar surveillance data, associates
            System              flight plans with tracks, processes flight
                                plans, performs conflict alerts, and processes
                                weather data.

MDT         Maintenance Data    Provides capability for data entry and display
            Terminal            and provides a standard serial data interface to
                                connect to a RMS.

MPS         Remote Maintenance  Provides capability for real-time monitoring and
            and Monitoring      alarm notification, certification parameter data
            System              logging, automatic record keeping and
                                information retrieval, and trend analysis,
                                failure anticipation, remote control of
                                equipment and facilities, diagnostic and fault
                                isolation, remote adjustments, and system
                                security.

MWP         Meteorologist       Provides weather data processing and display.
            Weather Processor

MVR         Multi-Channel       Make legal recordings of all voice
            Voice Recorders     communications between air traffic controllers
                                and pilots.

NARACS      National Radio      Provides minimum essential command, control, and
            Communications      communications capabilities to direct the
            System              management, operation, and reconstitution of the
                                National Airspace System during a national or
                                local emergency.

PAMRI       Peripheral Adapter  Provides interfacing capability to HCS.
            Module Replacement
            Item

PSN         Packet Switch       Provides communication network for transmitting
            Network             data via addressed packets.

PUP         Principal User      Provides the capability to request and display
            Processor           NEXRAD weather data.

PVD         Plan View Display   Provides aircraft situation display capability
                                for the controller that is to be replaced by
                                DSR.

RCE         Radio Control       Controls local and remote air-to-ground radios.
            Equipment

RCU         Remote Control      Provides FDIO remote print capability.
            Unit

RCOM        Recovery            Provides National Radio Communications System
            Communications      emergency communications essential during and
                                after earthquakes, hurricanes, and tornadoes.

VSCS        Voice Switching     Provides air-to-ground and voice communication
            and Control System  services and ground-to-ground voice
                                communication services between controllers,
                                other ATC personnel, and others at the same and
                                different en route centers and other ATC
                                facilities.
--------------------------------------------------------------------------------
                     (Oceanic ATC Systems Within an En Route
                                     Center)

----------  ------------------  ------------------------------------------------
DOTS        Dynamic Ocean       Provides track generation and traffic display as
            Track System        part of the Oceanic Traffic Planning System.

ODAPS       Oceanic Display     Oceanic system that displays aircraft position
            and Planning        based on extrapolations from flight plans.
            System
--------------------------------------------------------------------------------
                      (Traffic Management Unit (TMU) Systems
                            Within an En Route Center)

----------  ------------------  ------------------------------------------------
ASD         Aircraft Situation  Provides a display showing the location of
            Display             aircraft across the country that is used for
                                strategic planning purposes.

TMS         Traffic Management  Provides national level management and
            System              monitoring of the airspace system, including air
                                traffic flow, aircraft operations, and en route
                                sector and airport utilization and loading.
--------------------------------------------------------------------------------
                  (Systems and Facilities Outside but
                  Interfacing With an En Route Center)

----------------------------------  ----------------------------------
AFSS                                Automated Flight Service Station

AFSSWS                              Automated Flight Service Station
                                    Workstation

ARSR-1                              Air Route Surveillance Radar -1

ARSR-2                              Air Route Surveillance Radar -2

ARSR-3                              Air Route Surveillance Radar -3

ARSR-4                              Air Route Surveillance Radar -4

ARTS                                Automated Radar Terminal System

ASOS                                Automated Surface Observing System

ATCBI-4                             Air Traffic Control Beacon
                                    Interrogator -4

ATCBI-5                             Air Traffic Control Beacon
                                    Interrogator -5

ATCT                                Airport Traffic Control Tower

AWOS                                Automated Weather Observing System

AWP                                 Aviation Weather
                                    processor

CD                                  Common Digitizer

DUATS                               Direct User Access Terminal System

ETMS                                Enhanced Traffic Management System

FAATC                               FAA Technical Center

GMCCWS                              General NAS Maintenance Control
                                    Center Workstation

IFCN                                Interfacility Flow Control Network

LCU                                 Local Control Unit

LINCS                               Leased Interfacility NAS
                                    Communications System

LDRCL                               Low Density Radio Communications
                                    Link

MODE-S                              Mode Select

NAWPF                               National Aviation Weather
                                    Processing Facility

NEXRAD                              Next Generation Weather Radar

RCAG                                Remote Center Air-to-Ground

RCL                                 Radio Communications Link

RMS                                 Remote Monitor System

TDLS                                Tower Data Link Service

Telco                               Telecommunications

TRACON                              Terminal Radar Approach Control

VNTSC                               Volpe National Transportation
                                    Systems Center

WMSCR                               Weather Message Switching Center
                                    Replacement
----------------------------------------------------------------------
   Figure I.2:  Mid-Term
   Environment

   (See figure in printed
   edition.)


Explanatory Notes to Simplified Block Diagram for the Mid-term En
Route Centers' Systems Environment

                     (Systems Within the En Route Center and
                                 Their Functions)

----------  ------------------  ------------------------------------------------
ADAS        Automated Weather   Collects surface observation data from AWOS and
            Observing System    automated surface observing system (ASOS) and
            (AWOS) Data         distributes these data to weather processing and
            Acquisition System  display systems.

ADL         Aeronautical Data   Provides the capability to transfer data in
            Link                digital form between the aircraft and the ground
                                or between aircraft by means other than voice
                                communications.

CTAS        Center Terminal     Maximizes use of airport capacity by providing
            Radar Approach      decision aids to en route and terminal
            Control (TRACON)    controllers.
            Automation System

CWSU        Center Weather      This is the area in the en route center where
            Service Unit        the meteorologists perform their functions using
                                the various systems that provide them with
                                weather information.

DLP         Data-Link           Supports networked aeronautical
            Processor           telecommunications services within United States
                                domestic and oceanic airspace.

DSP         Departure           Calculates departure sequence, from push-back to
            Sequencing Program  time over fix, and includes runway
                                configuration, gate position, aircraft
                                performance, and flow restrictions, for a group
                                of airports. Displays departure sequence lists
                                in towers and at the Traffic Management Unit
                                (TMU).

DSR         Display System      Provides modern ATC workstations to support
            Replacement         programs like Weather and Radar Processor
                                (WARP), Automated En Route Air Traffic Control
                                (AERA), CTAS, and Data Link. Provides new
                                controller data entry and display devices.
                                Provides an interface capability with the Host
                                computer and system and the Enhanced Direct
                                Access Radar Channel (EDARC).

DUATS       Direct User Access  Provides the pilot with convenient access to
            Terminal System     pre-flight aeronautical and weather information
                                to plan the flight. Also allows pilots to input
                                instrument flight rules (IFR), International
                                Civil Aviation Organization (ICAO), or Visual
                                Flight Rules (VFR) flight plans into the system
                                .

EDARC       Enhanced Direct     Provides a backup to the host computer system
            Access Radar        (HCS) for radar processing, and radar track and
            Channel             display processing.

ETMS        Enhanced Traffic    Provides national monitoring, prediction,
            Management System   planning, re-routing, "ground hold", and flow
                                management.

GEO         Geostationary       Provides satellite-based air-to-ground and
            Satellite           ground-to-ground communications capability.

GPS         Global Positioning  Provides global navigation signals for use in
            System              determining 4-D (dimensional) time/position
                                data.

GW          Gateway             Communications system interface between the En
                                Route Center and external systems.

HOST        Host Computer       Will process radar surveillance data, associate
Replace-    System Replacement  flight plans with tracks, process flight plans,
ment                            perform conflict alerts, and process weather
                                data.

ICSS        Integrated          Provides voice communication services between
            Communication       controllers and aircraft (air-to-ground), and
            Switching Systems   between controllers and other personnel within
                                or among different ATC facilities, such as
                                towers, TRACONs, and Flight Service Stations
                                (ground-to-ground).

ITWS        Integrated          Provides integration of terminal area weather
            Terminal Weather    products and displays.
            System

MODE-S      Mode Select         Provides addressable-beacon interrogation and
                                reply.

MODE-S D/   Mode Select Data    Provides the capability for digital
L           Link                communications between aircraft, various air
                                traffic control functions, and weather databases
                                through a digital interface with the ATC
                                automation system.

MPS         Maintenance         Provides capabilities for real-time monitoring
            Processor           and alarm notification, certification parameter
            Subsystem           data logging, automatic record keeping and
                                information retrieval and trend analysis,
                                failure anticipation, remote control of
                                equipment and facilities, diagnostic and fault
                                isolation, remote adjustments, and system
                                security.

NADIN PSN   National Airspace   Provides a packet-switched wide-area data
            Data Interchange    communications network which interconnects major
            Network (Packet     ATC facilities.
            Switch Network)

NEXRAD      Next Generation     Provides precipitation, wind velocity, and
            Radar               turbulence data sensing and processing.

OASIS       Operational and     Replaces several systems, (the Flight Service
            Supportability      Automation System, Aviation Weather Processor,
            Implementation      and the Flight Service Data Processing System).
            System

TACAN       Tactical Air        Provides line-of-sight ultra high frequency
            Navigation          (UHF) bearing and range data to aircraft.

TFM LAN     Traffic Flow        Provides communciations system for ATC traffic
            Management Local    flow managment personnel responsible for
            Area Network        management and monitoring of current air traffic
                                flow, aircraft operations, en route sector and
                                airport utilization and loading, and future
                                system utilization.

TRACON      Terminal Radar      ATC facilities that sequence and separate
            Approach Control    aircraft as they approach and leave busy
                                airports, beginning about 5 nautical miles and
                                ending about 50 nautical miles from the airport,
                                and generally up to 10,000 feet above the
                                ground, where en route centers' control begins.

UBI         User Benefits       Host computer system interface device and en
            Infrastructure      route center local area network that establishes
                                a common interface to the host computer and an
                                updated telecommunications infrastructure.

VHF TDMA    Very High           Provides digital communications capability using
            Frequency Time      the VHF radio band.
            Division Multiple
            Access

VOR DME     Very High           The VOR supports determination of aircraft
            Frequency           position and airway definition by transmitting
            Omnidirectional     azimuth signals. The DME provides slant range
            Range with          between the aircraft and the DME locations.
            Distance Measuring
            Equipment

VSCS        Voice Switching     Provides a voice communications system which
            and Control System  performs the intercom, interphone, and air/
                                ground voice connectivity and control functions
                                needed for ATC operations in an en route center.

WAAS        Wide Area           Transmits wide area differential corrections for
            Augmentation        GPS signals. Provides the capability to use GPS
            System              for precision runway approach guidance.

WARP        Weather And Radar   Collects, processes and disseminates NEXRAD and
            Processor           other weather information to controllers,
                                traffic management specialists, pilots, and
                                meteorologists. It will provide a mosaic product
                                of multiple NEXRAD information to DSR for
                                display with aircraft targets.
--------------------------------------------------------------------------------
                  (Systems and Facilities Outside but
                  Interfacing With an En Route Center)

----------------------------------  ----------------------------------
ADS-B                               Automated Dependent Surveillance-
                                    -Broadcast

ADTN                                Aeronautical Data Transmission
                                    Network

AOC                                 Airline Operations Center

ARINC PSN                           Aeronautical Radio Inc. Packet
                                    Switched Network

ARSR-4                              Air Route Surveillance Radar-4

ASR                                 Airport Surveillance Radar

FMS                                 Flight Management System

NAVAID                              Navigational Aid System

NAWPF                               National Aviation Weather
                                    Processing Facility

NEXRAD                              Next Generation Weather Radar

NOCC                                National Operational Control
                                    Center

NWS                                 National Weather Service

OCC                                 Operational Control Centers

ODMS                                Operational Data Management System

SMA                                 Surface Movement Advisor

STARS                               Standard Terminal Automation
                                    Replacement System

TCAS                                Traffic Alert and Collision
                                    Avoidance System

TMP                                 Traffic Management Processor

WMSCR                               Weather Message Switching Center
                                    Replacement
----------------------------------------------------------------------

ARCHITECTURAL CHARACTERISTICS OF
CURRENT AND NEAR-TERM KEY ENROUTE
SYSTEMS
========================================================== Appendix II

Existing
and near-                                           Database
term                      Operating    Application  management
systems      Hardware     system       languages    system       Communications
-----------  -----------  -----------  -----------  -----------  ---------------
Host         IBM 3083     FAA unique   Jovial,      NAS unique   370 channel
Computer     mainframe    which has    BAL,         version of
System       with some    evolved      Fortran,     data base
(HCS)        special      from early   PL/1         management
             micro-code   IBM DOS                   and/or
                                                    COMPOOL
                                                    management

Peripheral   IBM 3710     N/A          N/A          N/A          RS-232, RS-
Adapter                                                          422, byte
Module                                                           parallel, bit
Replacement                                                      serial (modem)
Item                                                             for incoming
(PAMRI)\a                                                        radar

Computer     FAA unique   FAA unique   FAA unique   FAA unique   370 Channel
Display      (Custom      (Custom      (Custom      (Custom
Channel      Raytheon     Raytheon     Raytheon     Raytheon
(CDC)        product)     operating    language)    data
                          system)                   management
                                                    software)

Display      Highly       FAA unique   Jovial,      FAA unique   370 Channel
Channel      modified     (running     Assembly     (Custom
Complex      IBM System   prototype                 data
(DCC)        360/65 with  of HCS                    management
             Model 50 I/  operating                 software)
             O            system)
             Controller

Direct       FAA unique   FAA unique   FAA unique   FAA unique   To Host through
Access       (Custom      (Custom      (Custom      (Custom      PAMRI, RS-422
Radar        made         Raytheon     Raytheon     Raytheon     for input from
Channel      Raytheon     operating    language)    data         RDDU
(DARC)       product      system)                   management
             based on                               software)
             Motorola
             68000
             processors)

Display      IBM RS/      IBM AIX      Ada, C,      Oracle       TCP/IP, ISO/
System       6000         version      Assembly                  OSI version B0
Replacement  workstation  3.2.5 with   language                  with FAA
(DSR)        s            kernel                                 options, Frame
                          modificatio                            Relay (ANSI
                          ns for                                 617, 618), IEEE
                          real-time                              802.3 CSMA/CD,
                          performance                            IEEE 802.5
                                                                 token ring, 370
                                                                 channel, RS-
                                                                 422, IEEE 488,
                                                                 VSCS interface

Weather and  Sun Ultra    Sun Solaris  ANSI C       none         TCP/IP, ISO
Radar        Enterprise   (at least                              8802.3
Processor    5000 server  version
(WARP)                    2.5)
--------------------------------------------------------------------------------
\a PAMRI is a hardware/firmware data/protocol converter. 


MAJOR CONTRIBUTORS TO THIS REPORT
========================================================= Appendix III


   ACCOUNTING AND INFORMATION
   MANAGEMENT DIVISION,
   WASHINGTON, D.C. 
------------------------------------------------------- Appendix III:1

Randolph C.  Hite, Senior Assistant Director
Keith A.  Rhodes, Technical Assistant Director
Madhav S.  Panwar, Senior Technical Advisor
David A.  Powner, Senior Information Systems Analyst
Robert C.  Reining, Senior Information Systems Analyst


*** End of document. ***