    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. ***