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