Air Traffic Control (ATC) may appear to be a strange topic for a workshop on computational semiotics, particularly on new media. Contemporary and most planned future ATC systems are splendidly innocent of semantics, let alone semiotics. The new UK ATC system, due to be introduced in autumn 2001, will rely on ‘Flight Strips’ – printed paper slips in plastic holders, a technology developed half a century ago. Equally, the airlines struggle to communicate with a radio system established in the 1930s. Data links have been ‘under development’ for at least 40 years. Many modern airliners have a data link for company communications, but ATC hesitates to add another gadget to the overloaded cockpit.

This is not a suitable place for the usual discussion of the pressure of ever expanding commercial air traffic on the contemporary ATC system. Nor, for the sake of overseas participants returning by air, is it the time to discuss the many incidents of near or actual breakdowns of communication and their occasionally tragic results (Cushing 19??).

Essentially, a current ATC system divides the volume of airspace for which it is responsible into sectors, defined by an area on the map and an upper and lower height

Limit. Areas around airports have special procedures, which do not matter at this point. Each sector is controlled by a Planner, who has ‘Flight Strips’ which say when aircraft intend to pass over specific points on their routes and at what level. From these strips, he checks that aircraft will not pass over the same beacon at too close a time interval at the same level. If they plan to do so, he decides to alter the level of one or the other. (This choice, critical to the present system, has often been computer simulated, without much success. In part this is because controllers make decisions based on a vast repertoire of experience. In part it is because different controllers make different decisions in the same context.) The planner checks his actions with the next sectors. A second controller, the Executive, watches the radar and talks to the aircraft, greeting them, changing their levels as the planner has planned, sometimes turning them, waiting till a problem is past and heading them back to their track, and passing them on to the next sector.

In reality, the two controllers work very closely together, sharing tasks spontaneously, and communicating with gestures as much as words. The basic training for controllers takes three years, and it takes a further six months for a controller to reach a level of familiarity to be able to work a sector. If he moves to the next sector, it will take him another six months to become sufficiently familiar with the new sector. If he takes a fortnight’s leave, it will take him two or three days to get up to speed. At the start of a shift it takes ten to thirty minutes to absorb the current situation, and controllers need a break after about two hours. This is a very stressful, inefficient and, frankly, an inhuman way to use human beings.

A few years ago, I decided, as a mental exercise, to see what would happen if I tried to re-design the ATC interface. I soon realised that this required looking at ATC as a whole. Most of what controllers do at the moment is based on tradition, on the demands of early equipment, and on adaptations of equipment originally designed for other purposes (usually from the military, but in the case of Flight data Processing, from the computer industry).

TASK DEFINITION

The primary purpose of air traffic control is to allow aircraft to fly from airport to airport without hitting each other, and preferably without spilling the passengers’ drinks, throwing them against the cabin roof or frightening them to death.

TASK ANALYSIS

Air Traffic can be considered as a set of four dimensional trajectories, each corresponding to an aircraft which takes off from a runway, climbs and turns towards its destination, flies at an economic level until it descends and turns to land on another runway. ATC is charged, primarily, with ensuring that these trajectories never approach within defined limits (roughly five nautical miles – about eight kilometres - horizontally and one thousand feet - about 300 metres – vertically at a given time). This task is known as conflict avoidance, and controllers love it.

Technically, it is possible to devise a completely computer-based system for air traffic control, but this option is unacceptable to human beings in general, particularly airline bosses and ministers of transport.

If controllers are included in the system, they must perform a useful function. It is accepted that it is practically impossible for the controller to sit passively observing a system until an emergency arises, than spring into action to resolve it. (Under the present system, controllers believe that they are aware of all the traffic in their sectors all the time. This is in fact untrue, but ‘loss of the picture’ is an ever-present concern under the present system. The consequences of failing to notice a potential collision are so severe that controllers are constantly stressed by the possibility.)

For traffic control purposes, we can simplify the aircraft’s trajectories into four-dimensional straight-line segments. It is relatively easy for a computer system to compare these segments to identify any future infringements of separation standards.

Controllers are very poor at detecting future potential conflicts, allowing themselves vast margins of safety in some instances, and failing in others (Lafon-Milon,1978). They are however very good at solving conflicts, often clearing up several conflicts with a simple, economic order. (Under the present system, they apparently rely on remembering what happened on previous days, rather than trying to predict current trajectories. Unfortunately this requires traffic to fly down a restricted set of pre-defined routes, which both costs the airlines money, and increases the risks that potential conflicts will occur.)

TASK ALLOCATION

Detailed Task analyses of the current ATC system have been performed, in one case amounting to some 12,000 pages of detailed specification. It is important to avoid these, since they are essentially historic and legal documents. None of these are based on any rational theory of task allocation.

In principle, it should now be possible to develop a truly user-oriented system, where the controller is provided with a satisfying job (which he can perform well) and the computer system does the rest.

The tasks the controllers most like are resolving conflicts and handling emergencies. They are also good at resolving problems caused by aircraft deviating from their planned flight paths, for whatever reason.

(Because traffic is ‘tidal’, varying from light to heavy over quite short periods, and because controllers are humanly unreliable, it is necessary to have back-up systems in place to maintain safety if the controller cannot act in time. Because controllers are human, it is necessary that the back-up system should not be as ‘good’ as the controllers, but it must be safe.).

INTERFACE DEFINITION

Although there are many potentially interesting interface technologies in development, we will, for the purposes of this paper, assume that we have a standard IBM-PC VGA display, driven by a computer system, and a standard keyboard for input. (These are not ideal tools, but they are relatively well understood. A mouse-and-pointer interface might be better, but even this was not available in the primitive programming language I had available.) We will reserve speech and hearing on the human side, and sound generation and voice recognition on the computer side for ‘out of context’ operations.

A CRT display provides an input to the human visual system. As an extreme example, it could simply list the current positions and potential conflicts in terms of the X, Y, Z and T co-ordinates for each aircraft. There is no way in which a human operator could absorb the information in this form. The designers of the American AAAS system displays prided themselves that their system consoles could display a quarter of a million characters of text. The AAAS failed at the first test.

The contemporary solution to displaying the four-dimensional trajectories is, essentially, to show the Executive an X, Y plane, with the Z co-ordinate of the aircraft points displayed as a three digit code, for the present time (T=0). The planner visualises and, in theory, extrapolates the information he sees. (In reality, he recognises patterns from previous days). The Planner’s strips, in principle, show the X, Y dimensions reduced to a finite set of points (beacons), arranged on each strip in time order, with time T and height Z in figures. The strips themselves may be arranged in different ways, for example, in height order under the next beacon, and may be picked up and compared by the Planner. Most Planners believe that they maintain a ‘picture’ of their airspace, but in reality, they develop a sort of ritual switching of attention between pairs of strips, based, again, on their experience of previous days. Much of the printed information on the strips they already know by heart – BA253 is a Boeing 727 which always enters at beacon XXX, at 25000 feet (FL250) at about 1323, and should land at Gatwick about 17 minutes later. If any of this changes the controller is considerably disturbed.

Recent display developments include a Conflict and Risk display, (Figure 1) which shows points of minimum separation between pairs of aircraft with time along the horizontal axis and height along the vertical axis, and shows. The points are numbered, so the controller must refer to a list to find the call-signs of the aircraft displayed, then search the display to find the aircraft involved, and estimate their future state where conflicts are involved. (The system actually '‘knows'’ this but does not tell the controller!) Controllers love this display because, when it is blank, they know they haven’t overlooked something (Prosser et al, 1991).

Anther innovation is the so-called "stripless" system, where the information in the flight strip is included in an enlarged label attached to the aircraft symbol on the display. This eliminates the need to find the relevant strip, but, because the label is so big, means that only one or two can be displayed at any time. A reduced label is shown for most aircraft, which has to be opened to read the full data. Controllers can use further point-and-click menus to tell the system that they intend to change an aircraft’s trajectory, but have to instruct the aircraft by voice radio, and monitor its actions by eye alone(Graham et al,1994)

One apparently obvious often suggested and never successful display innovation is the 3-D display. Most suggested versions have been 2-D perspective versions, with a moveable viewing point. In practice the absence of cognitive cues for depth perception make these difficult to use. (Bisseret,1995) Even where some approach to ‘true’ 3D has been developed, it has never shown a significant improvement over the classic 2D map-style display. The Z (height) dimension is inherently different from the X, Y dimensions. Controllers view airspace more as a series of separate, superposed planes, as an architect views a building, with height changes being small and temporary features – similar to climbing a staircase from floor to floor (Lafon-Milon, 1981).

Although other approaches have been suggested (Falzon, 1982), it seems inevitable that the basic display will represent aircraft at their X, Y positions. Figure 2 shows how the necessary information on an aircraft can be displayed using features of the symbol to represent relevant features of the aircraft. Photographic realism is neither necessary nor desirable. The actual number and position of aircraft engines, for example, is of little interest for the purpose of this display. The use of colour coding for height is based on an existing convention, in which alternate flight levels are assigned to eastbound and westbound traffic, which can be shown to reduce the number of potential conflicts significantly. In the contemporary system, finding all the aircraft at Flight Level 350 (35,000 feet) implies reading or remembering three digits for each aircraft on the screen. The revised system says that all aircraft at the same cruising level will be the same colour.

Figure 4 provides an example of the basic ‘rest picture’. The text coding on the right is an ‘aide-memoire’ for training, and would not normally be visible in an operational display.

Additional symbology would be added to indicate aircraft that were wandering off their predefined track, failed to make planned manoeuvres, or made unplanned manoeuvres. This symbology would also indicate the urgency and potential consequences of the deviation.

It is a curious aspect of the current system that the aspect most relevant to Air Traffic control – potential future conflicts – is not actually shown to the controllers. They may have a short term conflict alert, which gives them a last-minute warning by highlighting two aircraft in immediate danger, or a CARD, which tells them that conflicts will occur, but not where or how.

Contrary to most system design, controllers do not perceive a conflict, then solve it. They perceive a group of related aircraft, which have several potential conflicts, then, decide on a few actions which solve all the potential conflicts.

The display should therefore draw attention to multiple conflicts. The simplest way of doing this is to link the aircraft involved, using lines that become more intense as the conflict becomes more urgent.

The controller can then chose which aircraft to modify, or the system can present him with a candidate, based on pre-defined criteria. These could be, for example, to take the most urgent conflict and select the aircraft involved in most conflicts, or the one which climbs or descends, or the one with furthest to go.

The display should then give the controller the necessary information about the aircraft that he will modify. In the X, Y plane this will be the future trajectory. An additional display gives the flight profile of the aircraft, drawn as a height and distance plot, with blocks marking where other aircraft either conflict with this one or will conflict if its flight level is altered. (Figure 5) Conflicting aircraft are shown by their trajectories up to the point of closest approach, which is linked to the corresponding point on the target aircraft’s trajectory – this provides the controller with valuable cues on the strategy to adopt to solve the conflicts.

At this point, the plot thickens.

Looking at the display, the controller decides to, say, move the aircraft to a lower flight level. He taps "F" (for flight level), then "-" (for down 2,000 feet to the next cruising level).

The display immediately shows him what will be the result of doing this.

If he doesn’t like it, he can try climbing instead, or start again and try changing a heading, or slowing down the aircraft.

Each order that he types is mirrored on the display. Unsolved or additional conflicts appear and disappear as he develops his solution. He may include delays (T++ means ‘in two minutes time")

When he has a solution, the final leg will be red, indicating that the aircraft has not been returned to track. He types "T" and a series of "+" to tell the aircraft to return to normal navigation after one, two or more minutes.

He now has a complete trajectory, solving all the conflicts concerned, which he accepts.

The system then sends this trajectory via data-link directly to the aircraft. The aircraft may show or tell the change to the aircrew, in any symbolism or language of their choice, as many times as they wish. Equally, other flights in the region may treat this as an ‘information’ message.

The controller is, by then, working on the next set of problems.

Twenty-six students, following a postgraduate course in the ergonomics of computer systems, were given a one hour lecture on ATC, followed by a short film describing a modern system. Each student was then given familiarisation training for the QWERTY keyboard used, followed by 20 short ‘coached’ exercises showing typical situations. They were then presented with an exercise of one-hour duration, in which aircraft entered at random to maintain a total of 40 aircraft in simultaneous random flight, in a 100 by 60 NM area. Twenty of the twenty-six subjects maintained separation faultlessly for the period. Aircraft entry rate was 230-260 aircraft per hour. Since the simulation was accelerated when there were no outstanding conflicts, the average time to complete the exercise was 24 minutes, during which an average of 48 orders, taking 14 seconds each to develop solved 53 conflicts.

None of these students had any experience in ATC, and none was a native English speaker.

It is not possible to make a comparison with conventional displays, since the upper limit of performance for expert controllers in ideally laid out sectors using conventional route and beacon systems is about one tenth of the traffic level handled by novices in this situation.

This paper demonstrates that, by designing a task to suit human abilities, then designing an interface to facilitate the designed task, a vast increase in efficiency can be achieved.

Although the specific task examined here is Air Traffic control, the methods demonstrated, based on relatively simple reasoning, are equally applicable to many other dynamic control systems.

Although much of this paper is devoted to explaining the reasoning and empirical development of the images provided on the display, the use of the display to carry out a form of dialog with the user is of more general importance.

The deliberate simplification and restriction of the interface display, and the minimisation of the windows employed, allowing a continuous direct interaction, is a primary element of this system.

a

This paper demonstrates that it is possible, using conventional, even primitive, interface equipment, to develop interfaces which

• allow a ‘natural’ style of interaction to perform a complex task,
• are easy to learn
• are more efficient than traditional interfaces.