ATC System Design - Points to Ponder

Introduction
This paper has been produced to consider, in overview, those aspects that are important for the controller and that are often only addressed following the signing of a supplier contract. The author has seen this happen too often, resulting in additional cost for the contract and unforeseen extra effort for development with concomitant delays for the implementation.

Air Traffic Control is facing increasing traffic pressures, and in many States, coping with equipment requiring updating or replacing. This paper addresses the problems concerned with the means to update/replace systems from an operational point of view.

Industry now has the hardware upon which to use more sophisticated software, however there has been a trend to add all sorts of functionality, windows and control “aids” without the essential operational needs being carefully investigated to the required depth.

Developments over the past few years in the computer and display arenas have almost adopted an exponential curve. Typically, an Air Traffic Control modernisation programme is measured in years from concept to operation. It is hard to imagine the future changes from what is not currently possible to what will be “Off The Shelf” in three or four years time. This almost revolutionary environment means that the problems facing the system designer are very challenging.

The issue of “Safety Management” has been raised. The question for the designer is how to incorporate this essential requirement into the planning of the new system. How should the operational input be organised and to what extent? The same can be said of the human factors and engineering disciplines. In the final analysis, it is the controller who will determine the acceptability or otherwise of the new system since it is their ATC Licence and their ultimate responsibility.

The detailed design of the displays will depend upon the controller population, the environment within which the controller works, medical requirements, the traffic patterns, civil/military relationships, geography, and airspace design. All these, and more, will have an effect upon the final design.

HMI design should be as flexible as possible subject to the fundamental rules governing the human factors aspects relating to consoles, lighting, sound, and displays.

Overall Design Considerations
Software/Hardware Constraints
The first, and probably the most important aspect for the designer to identify, will be the constraints that could affect the outcome of the HMI definition. All hardware and software tools will have limitations that will constrain the system design to a variable extent. If the proposed system is to provide solid support to the controller, and is going to be acceptable to the majority of the controller population, a serious and detailed examination of research studies’ results must be undertaken. As a note of caution, some studies will have been constrained themselves by their hardware / software or their control environment, so the results may be less than pertinent if the designer is using a less / more constrained development tool in a markedly differing environment. Research results are only as good as the equipment permits them to be. The designer will have to additionally assess the value of these results according to the control environment within which they will be used – are the controllers regularly tested for colour blindness?

Whilst research results can provide a good view of the fundamental design needs, it will be essential to “trial” these aspects in detail to ensure that they are applicable in a real operational context. It is likely that some form of verification tool will be needed to address this question.

Operational Input
It is essential that at the first stages of conceptual HMI design, the designer closely and continuously involves the controller as the control task is often reliant upon subtle interchanges between the controller and the system and controller to controller relationships. To ensure a successful result arising from the development efforts, the development team must include the three main sources of expertise, viz. Human Factors, Operations and Engineering. There are many detailed questions that should be asked at this early stage – inter alia;

· How is traffic presently controlled?

· What data is currently used?

· What are the current weaknesses in the system and procedures?

· What benefits can be implemented that are cost beneficial?

· Are these benefits “off the shelf” or development?

· Is there planned to be a change to the task patterns in the operations room?

· Is there a new control room planned and will the lighting be changed?

· What is the console design, has it been identified?

· What data is presented on paper – strips, maps, notes etc

The above questions, amongst many others relating to the existing operational software and paper ware functionality, will provide a design foundation for the new or upgraded system. The clear identification of the existing system is of fundamental importance as it is from this “safe” foundation that comparisons may be made with the proposed new system in order to identify safety management considerations, control procedure changes and training requirements. Large changes equal problems that require careful consideration, analysis and planning.

Over specification
During the above phase, it is likely that a “wish list” will be compiled, where the engineering or operational staff will call for all sorts of functions, tools and toys. It is here that the System / HMI designer must introduce a clear discipline of “operational need” if only to avoid unnecessary costs in the implementation of facilities that will never be used in real life. “Just because the function is possible, it is not essential to incorporate it into the system design”. Operational realism must be one of the primary objectives.

Initial Development Path
It must be stressed that the initial phase of “Operational Assessment” is fundamental to the process of development since a thorough understanding of the current processes will form the foundation. It is from this first stage that all changes can be identified. The second stage is the overview of the identified weaknesses and the development of a future operational concept. From this stage, it will be possible to identify the areas where change should occur; the result will be contained in “Statements of Need” where a broad argument is made for the upgrading existing equipment or the introduction of new functionalities. This will be the first “solid” evidence to be presented to the management for their approval.

Detail Description

The development process now evolves into a more detailed review of each “Statement of Need”, as approved, to prepare the “Safety Cases” and “Operational Requirements”. The “Operational Requirements” will spell out in detail the means to achieve the task through the detailed description of, inter alia, the data to be made available for display, the rules for its display and the manipulation of such data. The associated “Safety Cases” will identify the acceptability of system failure, the “fail soft” procedures and address the possibility of data presentation enabling control mistakes to be avoided etc.

This Safety Case document is in the form of a review of the ORs, the answers will form the basis from which an appreciation of the future system can be detailed and the requirements for the new or upgraded system can be identified. It will cover, inter alia:

• A review of the present ATC system;
• A comparison of the present versus future operational concept;
• An overview of fail-soft procedures together with an identification of areas of concern,
• The future organisation of operational services in respect of the future requirements – both civil and military.

The understanding of the operational objectives and requirements will include a description of the operational task in terms of the present system, and the operational requirements in respect of the various elements of the entire ATC system.

Prototyping and Evaluation

It is during the above phase that some form of demonstrable scenario tool should be used. These can be just graphical colour drawings, simple computer generated moving pictures, up to full simulations using fast-time mathematical modeling or real-time simulation. Since there is bound to be an overlap between the operational definition and the engineering description, these prototypes and simulations are likely to be essential to specify the priority of operational or engineering need.

It has been found that the use of animation software can provide the necessary focus for detailed discussion where all the “subtleties” of the Air Traffic Controllers’ task can be analysed. Following this process in practice, it has been found that this methodology can also provide an early view of the probable software events that will be required in the development of the function.