Implementation of the FAA Advanced Automation System will be the first major ... This effort is currently known as the Advanced Automation System (AAS) (Benel ...
Computerization and Automation: Upgrading the American Air Traffic Control System Arthur A. Simolunas1 and Howard S. Bashinski2 IFederal Aviation Administration,Washington, D.C., USA 2CTA Incorporated, Denver, Colorado, USA
Introduction Implementation of the FAA Advanced Automation System will be the first major human interface change in the air traffic control system since the original automation program. Replacing flight progress strips with electronic displays will require significant human engineering effort. The implementation of more complex safety-related functions also will require considerable design efforts due to the system's inherent reliability and availability requirements. New commands and procedures, in addition, will be necessary. This report describes the FAA developmental approach of using user teams to ensure an effective computer-human interface. Since the 1960's, the United States Federal Aviation Administration (FAA) has been implementing a series of automation upgrades for the Air Traffic Control (ATC) System. This effort is currently known as the Advanced Automation System (AAS) (Benel, Dancy, Dehn, Gutmann, & Smith, 1989). These developments were formally initiated in 1988 and will continue into the next century. They will result in a major re-alignment of the ATC system's functions and locations, including implementation of advanced systems for both the en-route and terminal functions. Generally, any large-scale undertaking involves unexpected issues and challenges; the AAS is no exception. Particular challenges to AAS include the enhancement of complex command-and-control systems through automation, the large scale of the project (AAS will eventually require over one billion lines of software source code), and the system's accuracy and reliability requirements. Although many specific design areas are affected, the change from paper flight-progress strips to electronic flight-data entries is worth particular attention. This process is critical to the controller's job and has required much effort. This paper addresses the following electronic flight-data issues associated with developing automated A TC systems: • Application of automation to those controller tasks currently requiring complex cognitive processing (automated reasoning) • Problems associated with the "hidden" complexities of ATC automation • Role of the users (controllers) in the development of A TC automation • Prospects for increasing automation in the future
NATO ASI Series, Vol. F73 Automation and Systems Issues in Air Traffic Control Edited by lohn A. Wise et al. © Springer-Verlag Berlin Heidelberg 1991
32
Overview The FAA always has implemented changes in the ATC system progressively to minimize the impact on operations, and the AAS continues to use this approach. Training and transition requirements are important to these progressive changes. The first segment of the AAS program, the Initial Sector Suite System (ISSS), will be the fIrst significant change to the controller computer-human interface (CHI) since the implementation of the original National Airspace En-Route Plan View Display (PVD). In ISSS, the situation display (containing the processed radar returns and heading, speed, and altitude information) will remain basically the same as in PVD. The controllers, however, will face new data-entry devices, including new keyboards and trackballs. Most signifIcantly, electronic displays, which will replace paper flight-process strips, will require new commands and operational procedures. Extensive adaptive-display capabilities and intra-sector operations also will affect the controller CHI signifIcantly. The initial NAS automation did not extensively change the controller functions, and the improvements focused on relieving the controller of routine duties. Processing flight-plans and combining separate data sources onto a single situation display, for example, relieved the controllers of the task of manipulating multiple data bases, and aided their thinking and perceiving processes. Although these improvements did automate some decision processes, they were routine and easily implemented; the number of variables was constrained, the data were unambiguous, and safety implications were minimal. The controllers, however, still performed the basic task of separating aircraft. Since the initial implementation, a number of functional, primarily safety-related improvements have been added to help the controller detect such problem situations as the impending violations of separation standards. Identifying false alarms and problems undetected by the system, however, continues to be the controller's responsibility. These new functions will help create a system that can apply automated reasoning across a large number of "fuzzy" variables with complex databases. Several factors challenge the adequacy of operational concepts and procedures; for example, response times are more critical for traffic-separation functions than for the earlier controller-aiding functions. As automation is applied to aircraft separation, the algorithms become more complex, datareliability requirements more critical, and system fault-tolerance requirements more exacting. The AAS program provides the platform for the next generation of automation improvements. In the past, detailed-specifIcation developments in routine controller automation were flawed; thus, the FAA and its prime contractor, the International Business Machines Corporation (ffiM®), are attempting to enlist the expertise of the controllers themselves in the development of the system. An operational user team (the Sector Suite Requirements Validation Team (SSRVT)) will work closely with the contractor and will be involved actively in all phases of the system-development process. Although many automated flight-processing functions resulted in a control decision, such as posting flight plans or handing-off aircraft between sectors or facilities, most were limited to computerizing basic manual functions and composing data for video display. Very few of the complex aircraft-separation functions were truly automated for making control decisions, and automated reasoning using imperfect real-world information was minimal (post & Sage, 1990). The addition of new computerized tools and services for the controllers increased productivity and presented a more integrated picture of the air traffic situation; however, it did not produce the commands and instructions that separate aircraft.
33
Basically, the FAA intended to reduce the controllers' data-entry load and aid their interpretation of the resulting display. First, a computer database was developed and flight strips were printed in an effort to computerize the flight plan processing system. Next, radar "blips" were electronically labeled with a data block displaying speed, heading, and altitude. This improvement, however, did not reduce the controller's responsibility for separating aircraft. Subsequent upgrades to the system also used this workload reduction approach. The AAS will extend this computerization. In the place of paper flight strips, the flight data display will project electronically the recorded clearances and other control instructions. The system will automatically update the presentation in real time and allow manual changes as necessary. Other new features include techniques that minimize clutter and reduce data density, such as the time-sharing of data field and logical filters for routine information on both graphical and tabular displays. The controller, in addition, will have access to an electronic display of maps and charts. The chart information will be layered and filtered to minimize the cluttered appearance of paper charts. Features such as color, variable brightness, shading, blinking, and inverse video, as well as new technologies such as icons, menus, and pointers, will improve the display interpretation (Hopkin, 1989). The controllers will be able to adjust these features individually and save them as "preference sets." These advanced features, however, cannot replace the controller decision process. In general, they are tools to aid the controller in the basic ATC task of separating aircraft. In fact, although the purpose of computerization is to improve safety and enhance controller productivity, it sometimes results in additional work for the controller. Electronic flight data displays, for example, will require new controller commands and interactive techniques that are very different from manual sorting and marking paper flight progress strips. It cannot be taken for granted, therefore, that computerization will cause a reduction in the controller's tasks. Arguably, some complex automated decision processing has already been instituted. Conflict Alert (CA), Mode-C Intruder (MCI) detection, and En-Route Minimum SAfe Altitude WArning (MSAW), which calculate possible airspace utilization conflicts, are presently being developed and implemented. These "attention tools" strictly aid the controller in the decision-making process. As with former new systems, the FAA will enhance AAS functionality in increments. The enhancement will take into consideration safety issues as well as minimize training and transition problems. Accordingly, the new electronic flight data display will approximate the current paper/manual protocol and syntax. An interesting exception to this computerization is the "implied commands" in which the controller will select a displayed object and the system automatically will proceed to the object's next logical state. For example, if the object is in a "handoff' state, the system will assume that the implied command is to "accept handoff." Automated reasoning probably will be first applied to the basic controller tasks in 1998, with the Automated En-Route Air Traffic Control System (AERA). The initial implementation, AERA-l, will predict problems based on known intentions and assist with control and coordination tasks (Elsaesser, Gisch, Hines & Swedish, 1984). True automated reasoning probably will not be accomplished until the completion of AERA-2 and AERA-3 after the turn of the century (Coleman, Guntherse, Murphy, Rooney, Shannon, Sheppard, Stewart & Tuttle, 1986; Rockman, 1989). AERA-2 and AERA-3 will add the complex resolution processes required to process ambiguous, imprecise, incomplete, and inconsistent information.
34
Automation Complexity Converting the paper flight progress strips to a computerized display has required major human engineering effort. Progranuning any basic function is more complex than it seerp.s, and the AAS programs is not an exception. AAS's complexity, however, is not surprising, since its safety-critical environment requires extensive failure modes. Automating a manual function, in addition, can be very deceptive from an overall design perspective. Developing a basic program to replicate a function merely represents a subset of the total progranuning effort. The complexity of the relationships between functions, the establishment of failure modes, the design of software that recognizes failures and alerts the controller, and the fault avoidance and fault tolerant approaches must be considered as well. These ancillary problems are seldom obvious to the software designer and are not usually resolved until late in the testing phase of a procurement. While developing a specification and reviewing design documentation, the operational user often overlooks this sophistication. The software complexity appears not only in the "application" programs, which are the basic controller functions, but also in the software which controls the process. One method of fault avoidance is to use commercially available software which, after extended use, has. been thoroughly debugged. Unfortunately, commercial software may not have the fault tolerant and detection features necessary for the ATC environment; thus, additional monitor and mode management software will be required, resulting in further software complexity. These programs, in addition, affect air traffic control response times, which must operate at a very high functional availability; for example, critical functions must have availabilities approaching 0.9999999, which amounts to about 3 seconds per year of down time. To achieve the required fault tolerance, the system must be capable of fault detection and, in turn, fault isolation. The system must then reconfigure into a fail-safe mode if redundant elements are available, or, if necessary, a fail-soft mode retaining the critical A TC functions. During these fault situations, the system must notify the controller and retain the information necessary for timely maintenance actions. These recovery procedures require significantly more software than necessary to replicate air traffic control functions. Obviously, computerization of routine functions, even in the formative stages, is a highly complicated operation. In order to perform controller reasoning functions, the system would require more reliability, better response times, and better alerts to allow the "traffic manager" to perform problem resolution verification. This confirmation procedure, of course, will result in additional system complexity and software development magnitude. Another complicating factor is the enormous human database storage and retrieval capability necessary to perform the resolution process. The machine speed and capacity required to replicate this capability may be even greater than anticipated. In addition, the human logarithms used to perform this function are not well understood. Recognizing their complexity, the FAA instituted an early evaluation of developing systems. An independent test system will be implemented close to ffiM's development facility. In addition, ffiM has agreed to furnish early versions of software builds, so that FAA operational personnel, both controller and maintenance personnel, can exercise the system in an unstructured manner. In previous automation procurements, unstructured environments were necessary to discover system flaws. Scripted factory testing did not explore the areas often traveled in the real world, and discovery processes were delayed until after the operational and test evaluation phase or even after field implementation. During these latter stages, problems were difficult to correct. The FAA, therefore, considers it imperative to involve operational personnel at the earliest date possible.
35
Controller Involvement in the Development Process To ensure operational suitability and controller acceptance of AAS, the FAA has employed controllers as advisors to the development process. The controllers are divided into "user teams" which specialize in a broad technical or operational area, such as CHI and testing issues or en-route and terminal operations. The user teams have been involved from the beginning and will continue to provide technical support throughout system implementation. There are several important issues associated with user input in the development of automated systems; for example, although the controllers will use the system, the program specialists will actually manage the development. The benefit of user input, therefore, must be weighed against the constraints imposed by budgets and schedules. Also, the ultimate audience is the design engineer, and the information must be presented in an engineering context. Finally, considering the complexities of the system, the user teams must maintain a high level of proficiency throughout its development. The AAS User Teams are service organizations to the AAS Program Office; thus, the Program Office must manage the interaction between IBM and the Air Traffic organization. The user teams develop the operational and functional requirements and present them first to the Program Office, which assesses their programmatic impact. Requirements that are clearly safety issues are readily incorporated and passed on to IBM which also receives user input in the form of design guidance. Because the controllers' operational and functional input eventually affects system design, this information must be presented in a useful way to the design engineer. The substance and the format of the information is important, for a controller discussion of operational requirements can sometimes resemble sheer anarchy. In order to focus these efforts, initial user teams developed detailed concepts of operations for the various segments of AAS. The resulting "ops concepts" are rigorous, systematic, and detailed descriptions of the controllers' job in each of the AAS segments (Ammerman, Fairhusrt, Hostetler, & Jones, 1988). In an hierarchical manner, air traffic activities are traced through sub-activities, tasks, and task elements. The ops concepts describe the criticality and frequency of all tasks, and include cognitive and sensory attributes for highly critical tasks; in addition, they describe all inputs and outputs necessary for the controller to perform each task. In effect, the ops concepts are detailed CHI task analyses that completely describe the controller's job (phillips, Bashinski, Ammerman, & Fligg, 1988). The operational concepts provide a framework for controller input and feedback on the various AAS segments. With respect to electronic flight data, the task requirements are specified comprehensively, and can be referenced to functional and software specifications. In this way, the system designers have a reference point for user team input. The ops concepts also offer a basis for developing operational test requirements for electronic flight data and determining operational suitability (Davies & Bashinski, 1987). The controllers' commitment to long-term involvement is important to the FAA's user team program. Although the specific makeup of the various teams will inevitably change, some members have served since the inception of the teams, a period of over eight years. This consistency has allowed the teams to maintain a high degree of expertise in their respective AAS design areas. Expansion of the teams to meet the increasing demands for controller input, however, has freshened the overall team perspective. Furthermore, as the design matures and enters the test phase, the controllers must have a broader exposure to the systems.
36 The need for a high level of expertise in the area of electronic flight data is especially critical. As software' and other design constraints arise, the controllers must continually reevaluate the operational requirements of electronic flight data. In some cases, special intensive working groups are formed to resolve design issues. This approach is used often with respect to controller interaction with the electronic data. The controllers must determine whether the electronic system meets all requirements of today's manual system and takes advantage of automation benefits. Ultimately, the goal of controller involvement is to help mitigate risks associated with operational suitability and controller acceptance. These risks are especially great in areas undergoing major changes in current operations, such as in the transition from paper to electronic flight data in the ATC environment. User involvement must be somewhat systematic, however, with the procuring agency in clear control of the interaction between the users and the development contractor. Finally, trade-offs must occur between the depth and the breadth of user involvement.
Future Shock We have discussed some of the issues associated with automating the U.S. ATC system, particularly with respect to electronic flight data. Unfortunately, the future outlook shows that these issues will become even more difficult to resolve as the system moves from "computerization" to true automation. Additionally, new issues, particularly those concerning the changes in the air traffic controller's role, undoubtedly will arise. The previously discussed AERA system was conceived as a follow-up to AAS. Gradually, AERA will replace the cognitive controller tasks with automated performance. In comparison to AERA, the early AAS segments represent "simple" computerization of manual tasks. AERA will provide capabilities, such as prediction and planning, that are now the sole responsibility of the controller. In AERA, flight data ultimately will become superfluous; that is, controllers will not need any visual history/status on the aircraft because the system will access specific data after informing the controller that a decision must be made. As systems become more and more capable of accurately making safety-critical decisions, the controller's job may become an example of "management by exception." Such advances will further increase the accuracy and reliability requirements for the future. Systems that are nearly 100% reliable are reasonably expected, especially when air safety is. an issue. Managers and planners must understand the technical challenges of meeting this type of goal so that they can implement reasonable development plans. Providing significant resources for front-end research, development, and technical validation will be increasingly important. Because the controller's role is likely to undergo significant change, the controller must maintain a high level of involvement in the development of future advances. Dearly, the controller is the single most important resource in determining the operational requirements of controlling air traffic. All of the challenges discussed in the paper must be resolved before more advanced automated systems are implemented. Considering the past difficulties of computerization, we can expect that many risks to the automation process will not be fully identifiable during the
37
planning phases. The planners and managers, therefore, must locate potential problem areas as early as possible and apply enough resources to advance planning and technical analyses.
Conclusions Automated reasoning, implemented in the latter stages of AAS, will produce new and possibly unanticipated levels of system complexity. These functions will require an extremely high degree of fault tolerance not already designed into the basic system architecture. Previously, requirements were recognized and detailed only during development; thus, the contractor and the user need to establish new levels of understanding. It will be tempting, however, either to reduce the necessary requirements or to add requirements that are "nice to have." In order that the contractor avoids penalty for imperfect specification and the user receives an acceptable operational system, they must exert exceptional understanding and management. To achieve this goal, the design and development phases must include the operational user. The customer, in addition, must periodically perform independent evaluations during the development phase. Regardless of specification requirements, the operational suitability and stability of the system must be established prior to the operational test and evaluation phase. Field controllers in the Sector Suite Requirements Validation Team (SSRVT) have been highly productive. The formation of this team has led to the establishment of user groups in control areas besides the en-route. Also, employing user-experts for the entire course of development significantly helps to mitigate programmatic and technical risks in the CHI area. A clear technical framework for user involvement, such as detailed operational concepts, and long-term participation by individual team members is important to such an effort The issues discussed in this paper are only a subset of those encountered by developers of large, complex command-and-control-type systems. The problems are programmatic as well as technical, and will require innovation and ingenuity to achieve true automated decision capability.
References Ammerman, H. L., Fairhurst, W. S., Hostetler,C. M., & Jones, G.W.(1988). FAA Air Traffic Control Operations Concepts: Vols. I-Vrn (Report No. DOT/FANAP-87-01). Washington, DC: Federal Aviation Administration. Benel, R. A., Dancey, R. D., Dehn, J. D., Gutmann, J. C., & Smith, D. M. (1989). Advanced Automation System Design. IEEE Proceedings: Air Traffic Control, 77(11), 1653-1660. Coleman, B., Gunthersen, N., Murphy, E., Rooney, P., Shannon, R., Sheppard, S., Stewart, L., & Tuttle, B. (1986). AERA 2 Operations Concept (Contract No. DTF-AOI-85-Y01034). Englewood, CO: CTA INCORPORATED. Davies, D. K., & Bashinski, H. S. (1987). Human Engineering Evaluations in Real Life: Operational Suitability Assessment During ATC Design Development. Human Factors
Society Bulletin, 30(5), 1-3
38
Elsaesser, C., Gisch, A. H., Hines, A. L., & Swedish, W. J. (1984),). Description of AERA 1 Capabilities (MitreTech.Report No. MTR-84W88). McLean, V A: The Mitre Corporation. Hopkin, V. D. (1989). Man-machine Interface Problems in Designing AirTraffic Control Systems. IEEE Proceedings: Air Traffic Control, 77(11), 1634-1642. Phillips, M. D., Bashinski, H. S., Ammerman, H. L., & Fligg, C. M, Jr. (1988). A Task Analytic Approach to Dialogue Design. *1. M. Helander (Ed.), Handbook of Computerhuman Interaction (pp. 835-857). North-Holland: Elsevier. Post, S., & Sage, A. P. (1990). An Overview of Automated Reasoning. IEEE Transactions: Systems, Man and Cybernetics, 20(1), 202-224. Rockman, M. J. (1989). Automated Decision-making in the Air Traffic Control Process: VoU System Overview (Report No. DOT/FANADS-89-0l). Washington, DC: Federal Aviation Administration.
