43RD ANNUAL CONFERENCE, Hong Kong, China (SAR), 22-26 March 2004WP No. 89Produce a Definition of Controller ToolsPresented by SC1 |
Introduction
1.1. As modern ATC systems have evolved, system functionalities have expanded from the traditional paper based or procedural aspects of control. The application of automation has allowed for the introduction of computer based tools that assist a controller in achieving the objectives of ATS.
1.2. Some of these tools now form part of what is considered the “safety net”, or a series of defences against possible failings of traditional systems. Other tools provide additional functionality that allow a controller to enhance the management of air traffic. There are a wide variety of possible functional enhancements that potentially are only limited by the skills and knowledge of system designers.
1.3. The introduction and usage of these tools can also potentially have a negative effect on a controller’s workload. Often the well meaning intentions of software engineers and system designers are misguided and tools that were intended to help can sometimes hinder those asked to use them.
1.4. To allow for clear policy to be developed on the implementation and usage of tools, the purpose of this paper is to produce a definition of Controller Tools (CTs).
Discussion
2.1. Air traffic control systems are continually being asked to cope with increasing air traffic, often increasing controllers’ workload and pushing ATC systems to the limits of their capabilities. In response to these demands, ATC systems are being produced that allow for automation of some of the tasks undertaken by the controller, in an attempt to allow them to cope with the greater demands of higher traffic levels. Similarly, the commercial models that airlines utilise means they are constantly seeking savings through efficiencies and demanding more flexibility, reliability and increased capacity of the ATS providers. These factors combined mean that the controllers have to rely more and more on tools that assist them in their day to day operations.
2.2. The concept of CTs is not a new one. In comparing the early ATS systems of procedural control or primary radar service with those of today, one could argue that flight data processors, automated coordination facilities and electronic strips are all examples of tools that have been developed to assist controllers in their primary tasks. These tools, however, were developed to manage tasks that could justifiably be replaced by automated systems.
2.3. The development of faster computers and more reliable technology now means that tools can be developed that are not necessarily replacing time consuming or repetitive tasks. CTs are now being developed that enhance a controllers ability to effectively manage their traffic, to increase capacity through scheduling or flow control, and to provide a greater level of safety. Most recently, the introduction of conflict detection systems and conflict “probes” has allowed the potential concepts of free flight to be realistically examined.
2.4. Whilst all of these concepts, in some way or another, enhance the controller’s ability to perform their tasks, it is important to distinguish between the different roles that these tools fulfil. There are two clear distinctions:
Type 1: Safety net functions: A safety net is an airborne and/or ground based function, the sole purpose of which is to alert the pilot or controller of the imminence of collision of aircraft, aircraft and terrain/obstacles, as well as penetration of dangerous airspace (IFATCA Manual)
Type 2: Controller Tools: These are tools that assist a controller in meeting the objectives of ATS but do not replace the need for controller decision making processes.
2.5. What is difficult, however, is to classify the wide variety of tools available into an individual category. MSAWS, for example, certainly forms part of the safety net functions. However, if its functionality were expanded to provide information on the avoidance of sensitive areas, then it could be considered as a type 2 controller tool. Similarly, a conflict probe provides warnings of conflicts but it also allows a controller to prepare clearances or instructions to prevent the conflict. From these and other examples, it seems that it is not so much the core system that would determine its classification but the way in which the functionality was applied or used that determined how a tool was classified. It is also possible to consider that some airborne tools could be considered as CTs, however this is considered beyond the scope of this paper.
2.6. On the other hand, flow control software provides information to a controller on the future nature of traffic. A controller can choose to respond to this information in a variety of ways, determined by operational aspects, environmental aspects or even staffing levels. Vortex advisory systems provide information on the likely presence of wake vortices. Based on this information, a controller can chose to manage their traffic in different ways depending on their evaluation of the timeliness, accuracy and relevance of the information. In these and other examples, information is provided to a controller that does not necessarily dictate immediate action for safety purposes. The information is intended to be presented in a manner that is easily recognisable and assessable and allows a controller to evaluate it to enhance the decision making process.
2.7. What is different between the two types is the purpose behind the tool. A safety net function is integral to an ATS system and designed to form a “last line of defence” against incidents or accidents. Such functions cannot be considered when developing a safety case for the introduction of new procedures or separations. They must not be considered as enhancing the ATS system; just ensuring the final integrity and safety of air traffic management.
2.8. A controller tool, on the other hand, provides assistance to a controller in managing air traffic. They allow controllers to perform their tasks in a better or more efficient way, generally increasing the capacity of traffic that can be managed, or providing a better level of service to airspace users. CTs can be considered when developing safety cases as it is often the presence of software enhancements that allow for new procedures to be developed. An example is a conflict detection system that allows aircraft to operate on flexible routes rather than laterally separated tracks in Oceanic airspace. A safety case would be built on the premise that the software were operational – without it there could be no case developed.
2.9. The distinctions are summarised in the following diagram:
Conclusions
3.1. CTs have evolved as ATS systems have developed and additional functionalities have been conceived and implemented.
3.2. Initially, repetitive or time consuming tasks were replaced through the introduction of tools, but technology has allowed for the development of tools that replace or enhance controller tasks.
3.3. There are two types of ATM Systems classified according to their functional usage, rather than their core design. Those that form a “last line of defence” (Satey Nets) against incidents and accidents and those that assist a controller in making decisions.
3.4. Safety net functions shall not be used to form part of a safety case for the development of new procedures or separations.
Recommendations
It is recommended that:
4.1. Controller Tool be defined as:
Controller Tools (CTs) are functions of an ATM system that enhance a controllers’ ability to meet the objectives of ATS. They provide information that assists controllers in the planning and execution of their duties, rather than dictating a course of action.
References
ICAO Doc 4444.
WP 88 Buenos Aires 2003.
Professional and Technical Manual of IFATCA.
IFATCA Manual.
Last Update: September 29, 2020